<html><head></head><body>Hi,<br><br>Once you go back to CPU, there should be no decoder device anymore. More generally, if you change regime, to CPU or to another GPU API family, you can't expect the decoder device to work. It won't match anyway.<br><br>Of course, you should anyway avoid that situation because performance will fundamentally suck, no matter the VLC core design.<br><br><div class="gmail_quote">Le 24 septembre 2019 14:55:04 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">On 2019-09-24 11:41, Steve Lhomme wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 2019-09-23 19:11, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Le maanantaina 23. syyskuuta 2019, 18.01.09 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> Use the one from the vout thread if it exists.<br><br> Later the video context will come from the decoder (if any).<br></blockquote>I still don't get why the VD should care/know about the decoder device <br>at all.<br>If even VD knows about the decoder device, then what's the point of the<br>distinct video context?<br></blockquote>The hint has to work both ways. If a VAAPI decoder uses a VADisplay and <br>the VD uses another one it may not work at all (not sure if the same <br>value would be used if the default display is used in both cases).<br><br>With D3D it's the same thing, with external rendering we want the VD to <br>use the D3D device provided by the host (otherwise it just cannot work). <br>That means the decoder should also use this device. And it knows about <br>this device/hint through the "decoder device". I agree that the VD may <br>read that external D3D device on itself without using the "decoder <br>device" at all. Given the "decoder device" may not be created at all <br>(it's created only on demand which won't happen for AV1 playback for <br>example) maybe I should not rely on it at all and get the host D3D <br>device by other means.<br><br>(there are also possibilities to use a different D3D device for decoding <br>and rendering which I have local support for, but that's besides the point)<br><br>So IMO it all comes down to VAAPI and whether the VADisplay value must <br>be created once and used in the decoder and the VD.<br></blockquote><br>I forgot an important case. When using a GPU decoder, a CPU filter, then <br>a GPU filter and then the display. If we don't store the "decoder <br>device" (in the filter (chain) owner) the CPU>GPU filter will need to <br>create a new "decoder device" when we could use a cached one, matching <br>the one used to initialize the VD (via the video context). We will <br>likely need to recreate a VD when we shouldn't have to.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I think in all cases the VADisplay created for the decoder will be <br>pushed in the video context when creating the display. So in all cases <br>it should match on both sides.<br><br>I'll modify my patch (and working branches) accordingly.<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><br></blockquote><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>