[vlc-devel] [PATCH 0/6] WIP libvlc surface rendering size update

[Steve Lhomme]

> On January 25, 2019 at 11:11 PM Rémi Denis-Courmont <remi at remlab.net> wrote:
> 
> 
> Le perjantaina 25. tammikuuta 2019, 18.06.49 EET Steve Lhomme a écrit :
> > As the API suggests we'll also need to tell what's the chroma and
> > colorimetry of the display so the core can adapt. It may change dynamically
> > when the source changes.
> 
> The chroma can only be changed safely by the display plugin upon a control 
> request. And even then, it is an utterly insane thing to do, as it was never 
> attempted/tested, and there are no ways to ensure that it won't unrecoverably 
> break the rendering pipeline, such as if creating a conversion chain or 
> rebuilding shaders fails.

We're not talking any chroma here, and only for OpenGL (for now). There is indeed some work to be done so the chroma conversion between the decoder/filter output and the display are adapted. In push that should be much easier as the decoder/filter pools won't be affected by what happens in the display.

> Changing the chroma asynchronously, outside a display configuration change 
> control, is out of question. That is a "privilege" of the upstream pipeline, 
> currently the decoder.

I disagree.

> As for monitor properties, should they ever be supported by the core, they 
> would fall under the control of the window provider just like the display 
> size. 

I agree. If it's like unplugging/plugging a monitor it would happen together anyway.

> As such LibVLC would not be able to control them, at least not with any 
> of the existing window provider plugins, including but not limited to the 
> dummy one.

Technically it doesn't belong in the "window" which is just a host for the video rendering but doesn't know about it. Right now this kind of property is handled internally in the display modules.

It could be possible for wdummy to listen on a structure (which I added in a patch) and when it changes (via libvlc) it pushes these changes to the vout thread. Just like with ReportSize().

> VLC does not even support changing the monitor PAR (yet). Colorimetry would 
> require not only core changes but entirely new filters.

It can be done in Direct3D11 (the code is ready) and I believe with OpenGL through libplacebo which can also do it dynamically.

We're talking about a libvlc API that is constrained to a couple of known vouts.

Although we should have colorimetry conversion filters that is currently done in these display modules. This is not good when transcoding HDR to SDR and vice versa.