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

[Steve Lhomme]

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
>