[vlc-devel] Rant about VLC video outputs
rem at videolan.org
Mon Jan 26 22:29:41 CET 2009
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,
> - 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
> > * 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
> > * 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.
More information about the vlc-devel