<html><head></head><body>I disagree and I don't think that's what was said in the workshop at all.<br><br><div class="gmail_quote">Le 19 septembre 2019 14:22:33 GMT+03:00, Thomas Guillem <thomas@gllm.fr> 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">I agree with this commit and with what Steve said. For me, that is exactly what we planned in the workshop.<br>And yes, maybe we should change the name of the decoder device.<br><br>On Thu, Sep 19, 2019, at 12:53, 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-19 10:51, Alexandre Janniaux wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Hi,<br><br>VAAPI display is intended to link the client decoder/encoder to the<br>hardware that will run the actual processing. On a classical X11<br>windowed system, it would have to go through the X11 connection,<br>meaning through the window system. So it makes sense to link the<br>decoder device to the windowing system.<br><br>For transcoding, you don't have the window, but you still have to<br>indicate where you want to decode and where you want to encode.<br>For the most common use case, the ideal situation is having both<br>at the same place, meaning that they share and use a common decoder<br>device.<br><br>The window=NULL case would likely create a decoder device on top of<br>a DRM connection, which could be used by the filter chain (opengl,<br>vulkan), the decoder (VAAPI) and the encoder (VAAPI).<br><br>In my opinion, solutions like splitting vout_window doesn't make<br>much sense as it is exactly what decoder device is for. The main<br>questions gravitate around the type of decoder device that we<br>want. VAAPI seems to cache the VADisplay corresponding to the<br>display/DRM connector used. Same for EGL, so maybe we can have<br>X11/Wayland/DRM decoder device instead of VAAPI one ?<br></blockquote>Not sure what you mean by cache here. The VADisplay is at least used to <br>check whether the codec+profile is supported by the device. It is really <br>tied to the hardware device. So whatever you have on the window/display <br>side you want to match the hardware device with what is used for <br>displaying. That's what the hint is for.<br><br>(in D3D the hint is used to make sure the same device is used on both <br>sides, if they mismatch the copy/render API's don't work and we need to <br>do the copy ourself)<br><br>Now I think what you mean is that the translation from XID to VADisplay <br>or Wayland to VADisplay or DRM to VADisplay is currently done in the <br>decoder device, but it doesn't have to be. There could be a XID "decoder <br>device/hint", a Wayland "decoder device/hint" and a DRM "decoder <br>device/hint". The VAAPI decoder could use each of them and translate <br>them to VADisplay by itself (the translation currently done in the VAAPI <br>decoder device).<br><br>That would be a shift compared to what we said so far: --dec-dev will <br>replace the --avcodec-hw option (which doesn't work with nvdec for <br>example). For now the --dec-dev is used to tell "I want to use this <br>decoder API in the pipeline". It works because there is a one to one <br>correspondence between the "decoder device" and the video context types. <br>What you propose is that there is no such correspondence anymore. That <br>would leave the possibility to select both the decoder/filter API type <br>and the buffering type.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Regards,<br>--<br>Alexandre Janniaux<br>Videolabs<br><br>On Thu, Sep 19, 2019 at 09:19:13AM +0200, Steve Lhomme wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">On 2019-09-19 8:40, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">It's called "decoder device" because it's for the decoder.<br></blockquote> The name itself is not correct. As explained, it is also used by filters to<br> create video context from scratch (that will output pictures compatible with<br> the "decoder device" used by the display module). We could call it "output<br> device" or even "output adapter" since it seems to always be tied to a<br> display adapter.<br><br> In the case of transcoding it's actually the device used by the encoder,<br> that the decoder needs to try to match.<br><br> As Alexandre reminded, it's mostly a hint for the decoder (and filters) to<br> match the output. So we could also call it "device hint".<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">And the decoder device does not have to come from a window. That's not how it's going to work for transcoding.<br></blockquote> It doesn't have to in most cases. But for devices like VAAPI it needs to<br> know the type and ID of the window so the decoder can actually be used (not<br> sure if there are encoders for VAAPI and if they can use a dummy VADisplay<br> value). See the Open() of the VAAPI decoder device [1]. No window => no<br> "decoder device". No "decoder device" => no decoder.<br><br> We actually designed the "decoder device" during the workshop because of<br> that. I did not originally go that way since on Windows I never need to know<br> the window (and in fact I can't know the adapter from the HWND).<br><br> [1] <a href="https://code.videolan.org/videolan/vlc/blob/master/modules/hw/vaapi/decoder_device.c#L223">https://code.videolan.org/videolan/vlc/blob/master/modules/hw/vaapi/decoder_device.c#L223</a><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Le 19 septembre 2019 09:30:30 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;">On 2019-09-19 8:11, Steve Lhomme wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">On 2019-09-18 18:16, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">Le keskiviikkona 18. syyskuuta 2019, 17.13.18 EEST Steve Lhomme a<br></blockquote></blockquote>écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">The decoder device ("dec-dev") should be tied to the lifecyle of<br></blockquote></blockquote></blockquote>the<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">window.<br></blockquote>Well, no. It's tied to an enabled window, which is longer than a<br></blockquote></blockquote>vout,<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">but<br>shorter than a window.<br></blockquote> I can change it to:<br> The decoder device ("dec-dev") should be tied to the lifecyle of an<br> enabled window.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">And AFAIK, the vout should not know about the decoder or decoder<br>device at<br>all. It should use the video context only.<br></blockquote>And how do you plan to convey this decoder device instance to the<br>decoder/filters without going through the vout ?<br></blockquote>For the record, the decoder device is created with a vout_window_t,<br>because in some cases (VAAPI for example) it needs to know about which<br>window is used. This vout_window_t is created and stored by the vout.<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> --<br> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.<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><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><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><br><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><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>