[vlc-devel] [PATCH 1/6] decoder: add code to send 3d metadata to the output modules to be handled

[Steve Lhomme]

On 14/08/2018 11:56, Steve Lhomme wrote:
> On 13/08/2018 18:02, Rémi Denis-Courmont wrote:
>> Le lundi 13 août 2018, 17:44:41 EEST Steve Lhomme a écrit :
>>> From: "Mohammed (Shaan) Huzaifa Danish" <shaan3 at gmail.com>
>>>
>>> This is because we don't want a new vout everytime the video stereo 
>>> mode
>>> changes.
>> Either you recreate the video output, or there is a 
>> change-source-$property
>> control request that all video outputs (or all video windows, depending)
>> implement.  You cannot just change a property silently, AFAIK.
>
> OK, I'll look at changing this property dynamically then.
>
>>
>> And I don't think that the latter is even realistic here. We cannot 
>> switch
>> (almost) all video output to invalid-pictures just for stereoscopy.
>
> IMO the current code is not correct either. Why would we need a new 
> vout when the orientation changes if it can handle dimension changes 
> dynamically (they can all do AFAIK) ? Same thing for the SAR.
>
> Also testing the other way around I found out that changing the vout 
> dynamically like that fails the hardware decoder. In D3D the context 
> is created by the vout and shared with the VA, if the vout disappears 
> and the VA remains unchanged the new vout will have a different 
> context and it won't work (black screen). Technically right now as 
> soon as the VA is created the vout cannot changed, unless the VA is 
> recreated. It will hopefully be fixed when we use a push model from 
> the decoder to the vout.

On the other hand it may be good to switch to another vout if the 
current one can handle the new source formats. For example OpenGL may 
support row/column sequential stereo when D3D11 doesn't. Technically 
it's the same with 360 formats (projection_mode), except in that case we 
know beforehand so we pick the one when the file starts.

There's also a problem with signaling the source stereo format change. 
It may arrive to the vout before the actual picture(s) that have the 
change arrived. This is not going to look nice. So the detection should 
be done by the vout (either internally or in the core which will do the 
signaling). For now it's probably better to do it in the vout. But not 
all vout can handle such change dynamically or only some of them. To 
handle this, I added a bitfield in vout_display_info_t that the vout 
must fill with the source formats it can change automatically during 
playback. If a bit is not set then a new vout is created as it is now 
(with the VA issue mentioned above).

This approach may be used for other things that the vout can handle 
without having to recreate a new one (this would also fix the VA context 
issue going with the vout). In the future we may even reconfigure the 
pool on the fly and never recreate a vout at all for those who support 
that. All the checks done in vout_update_format() could be checked with 
the vout. Not that it's not dynamic as the display info are settled when 
the vout is created. So we just read "static" values from the decoder 
thread.

>
> In many cases the 3D mode is tagged inside the codec and not the 
> container, so we only get the information when we call 
> DecodeSidedata() in lavc. But it needs a frame, which is too late 
> because the decoder/vout has already been created. It's a design issue 
> in lavc, it should pass the extra data of the frame it wants to output 
> when calling get_format(). Otherwise these extra data can only be 
> handled dynamically in the decoder/vout.
>
>>
>> -- 
>> Rémi Denis-Courmont
>>
>>
>> _______________________________________________
>> 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