[vlc-devel] Decoder/Display implementation selection

[Rémi Denis-Courmont]

Hi,

Provided that there is 0 or 1 avcodec-hw plugin for any given decoder device, we can obviously obsolete the avcodec-hw option.

Stand-alone non-avcodec decoders need to have higher priority than avcodec otherwise, they will never be used - unless the intent is not to use them automatically at all. However, slice-based decoders should be added to libavcodec rather than stand-alone, IMO.

Le 4 juillet 2019 09:23:26 GMT+03:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>Hi,
>
>While I'm working on the push implementation it has become clear that 
>there's a growing issue of how the user is going to select the 
>implementation it wants.
>
>Right now the user can select the display module and the avcodec-hw 
>module. Now we're adding a "decoder device" to the mix. Once one is 
>picked, the avcodec-hw should be the matching one, otherwise extra 
>conversions will be needed. But what if the picked one is not possible
>? 
>Fallback to software ? Meaning the decoder device is forgotten ?
>Meaning 
>the display module won't get it ? When rendering externally that could 
>be a problem as the decoder device already picked the information about
>
>the external renderer, which must be matched when rendering in the 
>display module.
>
>There's also the question of the NVDecoder which a GSoC student is 
>working on. It's not a avcodec-hw module but should be able to be
>picked 
>by the user in the list of HW decoders. It could be coupled with a 
>"decoder device" if that's what the user will select in the future, 
>instead of the "avcodec-hw" module. If that's the case we should be
>able 
>to make the switch soon, I have "decoder device" for D3D11 and 
>DXVA2/D3D9 ready to be merged, the others already exist in master.
>
>That means it would replace the "avcodec-hw" selection. Should this 
>parameter go away and the HW decoder picked is only the one 
>corresponding to the "decoder device" ? And fallback to software if
>none 
>is found. But still carrying the original decoder device in the video 
>context up to the display ? (see the external rendering coherence issue
>
>above)
>
>The default behavior should not be an issue. It could select the
>decoder 
>device based on the OS and if the implementation is available. It's bit
>
>heavier than the current ffmpeg VLD flavor selection as we need to open
>
>system resources to know if the HW acceleration is available (and yet
>we 
>don't know exactly the codec/profile needed). On the other hand right 
>now we open a whole display module and then check the VLD flavor works.
>
>So it would probably be done faster anyway.
>
>The display selection should not change. If the HW decoder doesn't
>match 
>the display selected by the user (or automatically selected) some 
>conversion should be done. If the mix is not possible too bad.
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190704/5daeff38/attachment.html>