Comment by rahimnathwani
4 days ago
-c:v h264_nvenc
This is useful for batch encoding, when you're encoding a lot of different videos at once, because you can get better encoding throughput.
But in my limited experiments a while back, I found the output quality to be slightly worse than with libx264. I don't know if there's a way around it, but I'm not the only one who had that experience.
IIRC they have improved the hardware encoder over the generations of cards, but yes NVENC has worse quality than libx264. NVENC is really meant for running the compression in real-time with minimal performance impact to the system. Basically for recording/streaming games.
So counterintuitive that nvenc confers worse quality than QSV/x264 variants, but it is both in theory and in my testing as well.
But for multiple streams or speed requirements, nvenc is the only way to fly.
Why's that counterintuitive? It makes intuitive sense to me that an approach optimized for throughput would make trade-offs that are less optimized for quality.
Co-signing. Encode time was faster with nvenc, but quality was noticeably worse even to my untrained eye.
Fascinating, it didn't occur to me quality could take a hit, I thought the flag merely meant "perform h264 encoding over here"
Edit: relevant docs from ffmpeg, they back up your perception, and now I'm left to wonder how much I want to learn about profiles in order to cut up these videos. I suppose I'll run an overnight job to reencode them from Avi to h264 at high quality, and make sure the scene detect script is only doing copys, not reencoding, since that's the part I'm doing interactively, there's no real reason I should be sitting at the computer while its transcoding.
Hardware encoders typically generate output of significantly lower quality than good software encoders like x264, but are generally faster and do not use much CPU resource. (That is, they require a higher bitrate to make output with the same perceptual quality, or they make output with a lower perceptual quality at the same bitrate.)
[0] https://trac.ffmpeg.org/wiki/HWAccelIntro
Cutting videos with copy can result in some weird playback issues if the cuts aren't on keyframes.
For manually cutting up videos, I use LosslessCut, which I think uses ffmpeg under the hood and is really helpful for finding and cutting on keyframes.
Yes. The reason is that there's many ways to encode a video, you can choose to spend a lot of compute in order to get the best quality, or the best size efficiency. Fixed function hardware encoders by nature have much less freedom in how they encode, and additionally are expected to be faster, or even real time.
It’s crude, but you can overcome the degraded quality imparted by gpu accelerated encoding by specifying a higher video bitrate.
Find a complex short scene in your cpu encoded video, extract it, ffprobe it to get average video bitrate, and take the same clip in raw and try gpu accelerated encoding at +20% bitrate. From there, iterate.
For a friend’s use-case that I helped with, +30% video bitrate bump overcame the degraded vquality.
Edit: strangely enough, if memory serves, after the correcting +30% was applied the actual ffprobe bitrates between the videos were very similar, maybe a 10% or less difference. Someone smarter than me can work that logic out.