[vlc-devel] [PATCH 0/6] WIP libvlc surface rendering size update
remi at remlab.net
Mon Jan 28 12:27:58 CET 2019
Well... If I had to pick names now, I would pick vlc_surface and vlc_video_surface instead of vout_window and vout_display_window. But I did not have the benefit of hindsight way back when, and I cannot be bothered to mass-rename now.
Le 28 janvier 2019 10:57:04 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>On 27/01/2019 10:45, Rémi Denis-Courmont wrote:
>> Changing the chroma asynchronously, outside a display configuration
>>>> 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
>> have not changed/relaxed in any way.
>>>> As such LibVLC would not be able to control them, at least not with
>>>> of the existing window provider plugins, including but not limited
>>>> dummy one.
>>> Technically it doesn't belong in the "window" which is just a host
>>> video rendering but doesn't know about it. Right now this kind of
>>> is handled internally in the display modules.
>> The window is an abstraction of the windowing system, not just a
>> has other responsibilities, notably tracking potential fullscreen
>> Compare the audio output which abstracts the audio system. It does
>> play sound, but also tracks available devices, volume and mute even
>> 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
>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
>>> thread. Just like with ReportSize().
>> No. That is not in scope of the dummy plugin or the dummy type. Dummy
>> the name implies, a placeholder for when there really is no window
>and none of
>> the abstracted window properties are relevant to the display.
>> include splitters and the dummy output. Border line users include
>> FrameBuffer, and maybe MMAL and iOS.
>> For backward compatibility with unmaintained crap like the ASCII art
>> 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
>> 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...
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel