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

[Rémi Denis-Courmont]

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 
>> 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...
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190128/61da3d86/attachment.html>