Any reason to use QuickSync over DXVA? Not too well versed in this area. Great work!
Edit: Will this beta be available on Linux/Debian?
There are significant differences between using QuickSync vs. DXVA.
DXVA uses a mixture of software and hardware for decoding. Basically, DXVA has software codecs that are capable to offload certain operations to be performed by a GPU.
The amount of work that is done by the GPU depends on the graphics driver implementation.
With Intel GPUs, the amount of work done by the GPU is rather high, so it is not too far away from using QSV directly - so for a decoding-only scenario it's an acceptable choice to use DXVA instead.
But for transcoding, we don't only need decoding, we also need encoding. Typically encoding is the much harder part of this process. Also the IO plays a significant role. Copying memory back and forth to the GPU takes its toll. So the ideal scenario is to have both parts done by the GPU board:
- Send the input stream to the GPU board
- Receive the fully transcoded stream from the GPU board
This is not possible with DXVA. DXVA cannot even do encoding - just decoding.
That's one reason why we have both, QSV and DXVA decoding options.
(note: the scenario described above - QSV transcoding without memory copying - is not yet implemented)
For Nvidia GPU boards, the situation is different:
- DXVA with Nvidia boards is not integrated as good as with Intel drivers
Less work is done by the hardware here
- Here, it's much better to use the NVDEC api for decoding
(also the same as above applies: it's best to use NVDEC/NVENC together)
- BUT: NVDEC instances are very limited. On most Nvidia boards, only a single instance of NVDEC is supported
This limit does not apply to DXVA decodings, though!
- Conclusion: In this case, you would configure NVDEC as the top priority and DXVA at the second position to be used in case no more NVDEC instances are available
(note: check of and fallback-to-next based on instance counts is not implemented yet)