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

Steve Lhomme robux4 at ycbcr.xyz
Mon Aug 20 14:28:31 CEST 2018


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.
>
> 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.

I wasn't sure what you meant at first but now that I've implemented it I 
see. The source-change-$property is done during the picture rendering, 
via vout_UpdateDisplaySourceProperties(). It's quite late in the 
pipeline, just before calling the filters. So it is indeed the way we'd 
want to do it, exactly with the picture it belongs too.

The problem is that, the way it's currently done, it does the change 
asynchronously (flagged for the changes to be applied in the next 
vout_ManageDisplay() call). That results in the picture being displayed 
being knowingly not suitable for the old state of the renderer.

Despite the doc of VOUT_DISPLAY_CHANGE_SOURCE_ASPECT and 
VOUT_DISPLAY_CHANGE_SOURCE_CROP "Askthemoduletoacknowledge/refusesource 
change", if they accept or refuse the change is ignored. Also 
vout_UpdateDisplaySourceProperties() doesn't return an error. The way 
the display pictures are marked as invalid is when the vout calls
vout_display_SendEventPicturesInvalid(). But that's not compatible with 
direct rendering the way it's currently done. We don't want to have to 
chose between one or the other. It's also not handled by OpenGL as of now.

The vout_display_SendEventPicturesInvalid() call from the vout (when 
it's allowed) results in the display pool to be destroyed so it's 
recreated the next time it's needed. The converters from the decoder to 
the vout are already recreated.


I think we could allow some vouts to tell if they can manage ASPECT/CROP 
changes on the fly (and stereoscopy), via the vout_display_info_t. Given 
it's done before the filter (and after a picture copy in some cases) it 
can't take a few milliseconds and a lot of vout could cope with that.

In that case vout_UpdateDisplaySourceProperties() would be allowed to 
call VOUT_DISPLAY_CHANGE_SOURCE_ASPECT/VOUT_DISPLAY_CHANGE_SOURCE_CROP 
directly. This would also result in each picture displayed with its 
proper aspect/crop, not the one from the previous state of the vout (no 
need to wait for the next loop).


For stereoscopy we don't have filters that would crop the source (SBS, 
TB) or decimate one eye so calling 
vout_display_SendEventPicturesInvalid() when the stereo changes would be 
useless. The converters chain would end up being the same as before the 
call.


More information about the vlc-devel mailing list