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

Thu Sep 19 14:14:49 CEST 2019

On Thu, Sep 19, 2019, at 14:08, Rémi Denis-Courmont wrote:
> I disagree and I don't think that's what was said in the workshop at all.

We decided to do like VAAPI, that is the most "complexe" case and will cover all others case.

There is a VaDisplay, created from X11/Wayland or via DRM. That is our decoder device. A decoder device is created via a window (X11/Wayland) or without (DRM).

Then there is VaContext, tied to the decoded video format. That is our video context.

One instance of our decode device could be used by several instances of video context. In parallel or not. This will happen when the decoder module is reloaded due to a format change spotted by the packetizer.

> 
> 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é. 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190919/616eb4de/attachment.html>