[vlc-devel] [PATCH] vout: create/release the decoder device when the window is enabled/disabled

Rémi Denis-Courmont remi at remlab.net
Thu Sep 19 14:08:31 CEST 2019


I disagree and I don't think that's what was said in the workshop at all.

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


More information about the vlc-devel mailing list