Av1an
Av1an copied to clipboard
master-of-zen
Add Hardware Encoder Support
Would be great to be able to use the Target Quality mode from av1an together with Hardware Encoders like NVEnc, QSV and co.
Rigaya has direct binaries for the encoder for NVEnc, QSVEnc, VCEEnc so it should work pretty much the same as with SvtAv1EncApp and co.
And yes, I know that hardware encoders are less efficient, but for huge batch conversions just CPU encoding is too slow for me.
The point of Av1an seems to be to split up and chunk videos for multi-threading CPU encodes to do them faster. What is the point of having Av1an handle hardware encoders that can encode AV1 at 150-250 fps already?
Just with plain ffmpeg or the actual binary it's impossible to do scene based encoding based on VMAF. You would need to split it in the scenes manually, do the probes manually and then set the correct crf (or equivalent) rate factor for that scene.
Av1an already has all of that implement. Not only that, but the scene splitting and analysis also needs to run on the CPU and is multithreaded here.
Yes for hardware encoders you want a larger minimum chunk size but in theory it should work fine as well. Although of course you will need to limit the parallel encode threads to one or two depending on the hardware encoders.
If you argue like that you can also say that Av1an should not have implemented SVT-AV1 support as it also doesn't benefit from Av1an on most consumer CPU with default settings as it can scale pretty well across many threads.
That last point is silly because SVT-AV1 doesn't really scale past a 12 core CPU so any high end ryzen, any threadripper, EPYC, or modern Xeon wouldn't be utilized. This was the point of Av1an.
Hardware encoding should only be utilized for live streams. Besides VMAF being outdated and obsolete as a metric, if you care about hitting high quality, you're not using a hardware encoder.
To top it off, each GPU encoder setup is different, not just APIs, but how many encoder engines exist, how many streams are allowed. How much VRAM is there to decode and encode that amount.
A lot of stuff has to be put into this for benefiting a niche use case that seems fruitless.
I've also been of the opinion that av1an should add Rigaya's hardware encoders to av1an for target quality encoding. They'd be able to leverage av1an's framework quite well regardless of them being inferior to software encoding.
I've also been of the opinion that av1an should add Rigaya's hardware encoders to av1an for target quality encoding. They'd be able to leverage av1an's framework quite well regardless of them being inferior to software encoding.
For me, the main overhead of av1an is vmaf calculation - but sure, hw encoding is getting better (and is quite acceptable on nVidia and Intel) and might speed up av1an a bit w/o burdening the cpu.
I'd like to add that hw DECODING would be useful, too - and would combine with hw encoding if that should be implemented. https://github.com/master-of-zen/Av1an/issues/833
The point of Av1an seems to be to split up and chunk videos for multi-threading CPU encodes to do them faster.
Another point of av1an is to fix svt's non-existent scene detection (--scd 1 was removed some time ago) - svt seems to be designed for chunked encoding, no matter how much parallelization.