
<html><head></head><body>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.<br><br><div class="gmail_quote">Le 28 janvier 2019 10:57:04 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On 27/01/2019 10:45, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Changing the chroma asynchronously, outside a display configuration <br>change<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">control, is out of question. That is a "privilege" of the upstream<br>pipeline, currently the decoder.<br></blockquote>I disagree.<br></blockquote>Chroma (pixel format) cannot change downstream. That has already been<br>determined in the context of asynchronous decoding, and especially<br>asynchronous hardware decoding failure.<br></blockquote><br>OK. I don't think changing the chroma dynamically is needed here.<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I am not interested in reopening the topic since decoder-imposed constraints<br> have not changed/relaxed in any way.<br><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">As such LibVLC would not be able to control them, at least not with any<br>of the existing window provider plugins, including but not limited to the<br>dummy one.<br></blockquote>Technically it doesn't belong in the "window" which is just a host for the<br>video rendering but doesn't know about it. Right now this kind of property<br>is handled internally in the display modules.<br></blockquote> The window is an abstraction of the windowing system, not just a window. It<br> has other responsibilities, notably tracking potential fullscreen targets.<br><br> Compare the audio output which abstracts the audio system. It does not just<br> play sound, but also tracks available devices, volume and mute even if there<br> is no audio track.<br></blockquote><br>I'm still uneasy with this whole thing. Maybe the name window doesn't <br>work well. In the case of "surface rendering" it's not a window in the <br>windowing system term, but it still close to what we get from our window.<br><br>In the longer run I think we need more work in that area. For example <br>the d3d11 module is just a rendering engine specialized in rendering to <br>a D3D11 SwapChain. But the exact same engine can be done to render to a <br>D3D11 context. Same with D3D9. It seems that it could be split in 2 <br>layers. The swapchain probably belonging to the window, but they're not <br>compatible between D3D11/D3D9.<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">It could be possible for wdummy to listen on a structure (which I added in a<br>patch) and when it changes (via libvlc) it pushes these changes to the vout<br>thread. Just like with ReportSize().<br></blockquote> No. That is not in scope of the dummy plugin or the dummy type. Dummy is, as<br> the name implies, a placeholder for when there really is no window and none of<br> the abstracted window properties are relevant to the display. Legitimate users<br> include splitters and the dummy output. Border line users include KMS,<br> FrameBuffer, and maybe MMAL and iOS.<br><br> For backward compatibility with unmaintained crap like the ASCII art output,<br> we do pass the size on, but that's pretty much it.<br><br> If you need to define a new windowing type/protocol, use a different type. I am<br> pretty damn sure that I already pointed out that out when the OpenGL callbacks<br> were being added...<br></blockquote><br>Or maybe another window module that's specialized for OpenGL rendering <br>(and possibly others). "wdummy" is currently forced by the OpenGL <br>callback, so it could be set to something else that would listen to <br>special variables. Not too sure how to signal these variables though...<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>