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

[Steve Lhomme]

On 27/01/2019 10:45, Rémi Denis-Courmont wrote:
> 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.

OK. I don't think changing the chroma dynamically is needed here.

>
> I am not interested in reopening the topic since decoder-imposed constraints
> have not changed/relaxed in any way.
>
>
>>> 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.

I'm still uneasy with this whole thing. Maybe the name window doesn't 
work well. In the case of "surface rendering" it's not a window in the 
windowing system term, but it still close to what we get from our window.

In the longer run I think we need more work in that area. For example 
the d3d11 module is just a rendering engine specialized in rendering to 
a D3D11 SwapChain. But the exact same engine can be done to render to a 
D3D11 context. Same with D3D9. It seems that it could be split in 2 
layers. The swapchain probably belonging to the window, but they're not 
compatible between D3D11/D3D9.

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

Or maybe another window module that's specialized for OpenGL rendering 
(and possibly others). "wdummy" is currently forced by the OpenGL 
callback, so it could be set to something else that would listen to 
special variables. Not too sure how to signal these variables though...