[vlc-devel] Decoder/Display implementation selection

[Jai Luthra]

On Thu, Jul 04, 2019 at 09:51:01AM +0200, Steve Lhomme wrote:
>On 2019-07-04 9:23, Thomas Guillem wrote:
>>If the dec-dev succeed to load one of these backend, it is very likely that 
>>the hw decoder will succeed too. So we don't have your problem on Linux.
>
>The HW may be loadable but the codec/profile not supported. For example as 
>things are now NVDec only handles H264. So if you pick that automatically all 
>the time, without knowing the codec, you'd never load the VDPAU dec-dev even 
>though it can do HEVC (you can extend that to 10 bits, 4:4:4, etc instead of 
>just the codec).
>
>We still need to be able to iterate between all the HW decoders before we pick 
>one.
>
>NVDec being a decoder, that means once it's started, it might eat data before 
>it selects a profile or realize it cannot handle it. We should fallback to 
>lavc then. But from what I understand restarting the decoder will lose the 
>bits it has already eaten ?

NVDec has a 'get device capabilities' API we can use to check if the given 
codec+chroma+bitdepth is supported by the device.

If we probe bitdepth and chroma using the SPS in fmt_in.p_extra, then we can 
call this api from the OpenDecoder callback itself, and fail there if the 
profile isn't supported without eating up packets.

Although I'm not sure if p_extra is always populated, but usually demux module 
does that?

>(we could also support QSV decoders in the future which might support more 
>codec/profiles than DXVA, so the issue is not just with NVDec)

I believe QSV can also tell if it can handle a profile or not via the 
MFXVideoDECODE_Init call.

>>If the user force one backend, it will try that backend and fallback to SW if 
>>the backend can't be loaded.
>
>OK with that. There might still be a problem when falling back from NVDec/QSV 
>to lavc.
>
>>On Windows, you have
>>- D3D11
>>- D3D9
>>- NVDEC
>>
>>But you need to load lavc to know the correct backend, is that right ? What I 
>>would do:
>
>It's the same as with VAAPI/VDPAU. lavc starts processing data and then ask 
>for frames to decode to, with various VLD (including cuda, which we don't 
>support for now). NVDec/QSV would be separate from that.