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

[Rémi Denis-Courmont]

Le sunnuntaina 27. tammikuuta 2019, 10.30.18 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.

Push buffer do not solve the problem of synchronizing the parameter change with 
the video output picture FIFO. It simplifies the problem insofar as we no 
longer need to synchronize with picture allocation, yes, but that is not 
enough.

Currently, only user overrides can change asynchronously (zoom/size, fill, user 
crop, user aspect); not even decoded crop or aspect can change without 
resetting the video output, as you found out
(4.0.0-dev-395-g17efaa77b8).

But even if/when it gets fixed for the decoder case, that does not make it work 
for display-driven changes. Asynchronous changes from both upstream and 
downstream would lead to deadlocks and/or potentially infinite loops when 
updating the conversion filter chain between the upstream output and the 
downstream input.

For display, parameter changes are only processed upon an event from the user 
interface or from the window provider, not truly asynchronously.

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

Chroma (pixel format) cannot change downstream. That has already been 
determined in the context of asynchronous decoding, and especially 
asynchronous hardware decoding failure.

I am not interested in reopening the topic since decoder-imposed constraints 
have not changed/relaxed in any way.

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

The window is an abstraction of the windowing system, not just a window. It 
has other responsibilities, notably tracking potential fullscreen targets.

Compare the audio output which abstracts the audio system. It does not just 
play sound, but also tracks available devices, volume and mute even if there 
is no audio track.

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

No. That is not in scope of the dummy plugin or the dummy type. Dummy is, as 
the name implies, a placeholder for when there really is no window and none of 
the abstracted window properties are relevant to the display. Legitimate users 
include splitters and the dummy output. Border line users include KMS, 
FrameBuffer, and maybe MMAL and iOS.

For backward compatibility with unmaintained crap like the ASCII art output, 
we do pass the size on, but that's pretty much it.

If you need to define a new windowing type/protocol, use a different type. I am 
pretty damn sure that I already pointed out that out when the OpenGL callbacks 
were being added...

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