
<html><head></head><body>Hi,<br><br>Provided that there is 0 or 1 avcodec-hw plugin for any given decoder device, we can obviously obsolete the avcodec-hw option.<br><br>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.<br><br><div class="gmail_quote">Le 4 juillet 2019 09:23:26 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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