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

Rémi Denis-Courmont remi at remlab.net
Mon Aug 20 17:15:36 CEST 2018


Le maanantaina 20. elokuuta 2018, 15.28.31 EEST Steve Lhomme a écrit :
> > 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.

The documentation is wrong. The current vout architecture has always assumed 
that sample and crop A/R can change, also display size, display fill and zoom 
(it only prints an error message, and then ignores the failure). Those video 
outputs that cannot really handle them will invalidate their pictures. There 
are IMO no sane ways to handle failures here anyway, nor any justifications to 
allow them.

The problem is, invalidating pictures breaks direct rendering. We can always 
discuss whether some legacy display plugins could be switched to indirect 
rendering, or removed. However the OpenGL display cannot invalidate pictures. 
And so any such property must be supported by the OpenGL display at the very 
least.

-- 
Реми Дёни-Курмон
http://www.remlab.net/





More information about the vlc-devel mailing list