Re:FFmpeg Drawtext Filter for Overlays, Scrolling Text, Time...
by fireattack on Friday October 23, 2020 @03:22AM
(#24866837)
If compression ratio or filesize isn't a priority, NVENC definitely is good enough to consider. The speed is just too good.
It can do 300fps+ (for simply transcoding. Burning in subtitles probably will slow it down a little ibt) already on my very dated GPU, likely would be even faster on newer ones.
Re:FFmpeg Drawtext Filter for Overlays, Scrolling Text, Time...
by ethanwillis on Friday October 23, 2020 @04:30AM
(#24867197)
What some people might not know is that the transcoding results and quality are hardware dependent. You will get different results depending on whether you're using NVENC, intel's on chip stuff, actual encoding hardware, etc.
Edit: Obviously it's more complicated than this. But I think this is one of the reasons behind the need for things like Netflix's VMAF
Re:FFmpeg Drawtext Filter for Overlays, Scrolling Text, Time...
by izacus on Friday October 23, 2020 @04:43AM
(#24867255)
Also generations of hardware matter - earlier GeForces and Intel CPUs have a worse encoding block than newer generations.
In any case, they massively lag behind software encoding.
Re:FFmpeg Drawtext Filter for Overlays, Scrolling Text, Time...
by fireattack on Friday October 23, 2020 @05:09AM
(#24867408)
I mean, obviously it would be the case for NVENC. Old(er) versions don't even support B frames.
But I guess you can call it "firmware" or "software" dependant too, because they don't really use/support the same version of NVENC to begin with.
And I doubt the result is significantly different, if any, for software encoders like x264 - of course assuming you use the exactly same version and parameter.
You're going to have to reencode it, which is a lossy and CPU-intensive process (unless you manage to get hardware encoding working with your video card, which is possible but very fiddly IME).
> Is it a super cpu intensive process that takes a long time for let's say a typical 2 hour movie?
There are a lot of compute/filesize tradeoffs that you can make. If you don't mind a file that's 2-3x larger than your original then you can do it fairly quickly (say 1/3 of realtime). If you don't mind an effectively uncompressed video (so tens or hundreds of gigabytes) then you can do it as fast as your disks will write. If you want something similar to the original without sacrificing too much quality then it'll probably be slower than realtime.