[vlc-devel] Rant about VLC video outputs

[Rémi Denis-Courmont]

Le lundi 26 janvier 2009 23:07:43 Laurent Aimar, vous avez écrit :
>  It seems to me that vout_thread_t contains way too much. It does the vout
> module management AND the vout thread management. I thing there should be 2
> objects for that:
>  - a vout_thread_t that does the generic vout works (wait for the right
> time, filters managment, video heaps, subtitles(at least some part), mouse,
> etc).
> - a vout_display_t (whatever the name) that would be implemented by a 
> module and that does ONLY the specific video output part (x11 calls, or gl
> calls ...)

Hmm yeah, from an architectural perspective that makes sense, and it 
would "force" a cleaner design. We'd have to keep "events" in the display 
part though, which is not self-evident. For instance, X11 will normally 
deliver the window events to the X11 connection that created the window. That 
same window is also needed to send X11 images.

> > * The use of pf_init and pf_end in addition to pf_open and pf_close is
> > confusing. pf_open is supposed to probe, and pf_init is supposed to
> > initialize the buffers. That does not work too well, since some errors
> > are only detected in pf_init (verified with the X11 output). When this
> > happens, there is no video at all.
>
>  It is there for when a heavy change in the configuration is needed, ie the
> one that changes the video buffer but not the widget (like resize for an
> X11 only module, without xv support).
>  Now, a simple pf_control that would only control the vout_display_t would
> be enought I think.

I suspect this does not work with the current window provider system - you 
need to release (-> destroy) the window and then request (-> create) a new 
one. We don't have a resize window function, although we could do it so that 
pf_open request the window, pf_init resizes, pf_end does nothing in that 
regard, and pf_close releases the window. Not sure about is error handling, 
like too big/too small window request. This gets back to the issue that 
pf_init failure cannot trigger plugin fallback, since it's past 
module_Need()/pf_open.

> > * vout_thread_t.pf_manage seems to suffer from the same problem as
> > demux_t.pf_demux, but worse. It can -obviously- not sleep, but I suspect
> > it does not get called if there is no new picture. If that is true, then
> > we could not implement say XDamage, which would precisely make sense when
> > there is no new picture for an extended period of time. Then again, mouse
> > seems to work on a static DVD menu, so I guess I'm wrong.
>
>  The vout thread workaround this problem by repeating the last picture
> regularly when too much time have elapsed. It is probably needed for
> displaying subtitles anyway.

Might well be, though that's also a little bit hackish.

> > * I wonder if we distinguish HWND providers from XID providers. At least,
> > in theory, one could have an X11 output on Windows. To split hairs
> > further, one could in principle use the D3D output against libwine. In
> > these case, using the same vout_RequestWindow() API does not work.
>
>  ?

HWND Win32 window handle, and X11 window ID. vout_RequestWindow() assumes they 
are interchangeable, which only works because we don't currently mix them on 
any platform.

> > * I am suspicious about the new invmem plugin being a dummy codec rather
> > than a dummy demux. rawvideo is a demux.
>
>  I don't know what it does. If it is to inject data, doing it as a demux
> would be cleaner BUT a bit slower (you would have a copy from the demux
> output to a picture_t).

Could it not create a picture_t that reference the inbound ES block_t as 
private data (if that were a critical performance hit anyway)? I don't see a 
fundamental need to copy, but I might be missing something.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary