[vlc-devel] Rant about VLC video outputs
rem at videolan.org
Mon Jan 26 19:47:38 CET 2009
This is just a list of thoughs on the current state of the video ouput
subsystem. These came mostly while writing the (still very incomplete) XCB
video output. I do not expect, nor do I want, a rework of the video outputs
one week before the feeature freeze. But I'd rather brain dump on the mailing
list that forget about these.
* The developper documentation is way out of date, and mostly helpless. This
is probably not specific to video output ;)
* Xlib sucks. As of yesterday, I can count six plugins using Xlib: X11,
XVideo, GLX, GGI, global hotkeys and screen access, and I might be missing
some. Then we can add Qt4 (indirectly). About everyone of them installs its
own error handler, which is process-wide... Great design from the 80's :(
* Using vout_thread_t for OpenGL providers is confusing. The OpenGL module
needs to emulate what the video output core does. Of course, this is not
maintained properly and results in bugs. Up to recently, GLX was failing an
assertion... IMHO, we should have a custom object structure for these, and
remove the OpenGL callbacks from vout_thread_t.
* There is some confusing overlap between picture heaps and video format
fields. Laurent hinted he would clean that up later.
* pf_control is used from callbacks and third party threads. This requires the
video output plugin to handle mutual exclusion internally. This is
inconsistent with all other object types that I know. Also, this has
accounted for deadlocks and infinite callback loops (I won't regret the
* A bunch of parameters are set somehow (hopefully by the video output core
thread), and then signaled via a change bits mask to the Manage function. I
wondered why this is not done directly via pf_control. Then I realized
pf_control was for asynchronous requests (see previous comment).
* Generally speaking there seem to be way too many public parameter inside the
vout_thread_t. It is not very clear who sets and gets what and under what
* Snapshots are really poorly designed. For instance, if more than one thread
requests a snapshot simultaneously, boom. Olivier partially fixed this today.
On the other hand, it added to the vout_thread_t mess (see previous comment).
* X11 screen access seems not to use shared memory (MIT-SHM). This may
*partially* account for its horrible performance.
* 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.
I assume that was meant to handle recycling inspite of different input
formats, but I am not sure if that makes so much sense. Calling pf_end then
pf_init will cause flickering anyway.
* 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.
* Screen-saver preemption should perhaps be done directly by the video
outputs... ? In most cases, the preemption is dependent on the platform
consistent with the video output. Also, it makes no sense to prevent
screensaving when using say the vmem plugin.
* As a side note to the previous comment, our implementation of DBUS inhibit
seems to suck (and possibly the DBUS inhibit RPC interface too).
* 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.
* We could extend invmem resp vmem to support shared memory, so we could read
from Xvfb resp write to something else than a HWND/XID ?
And for 1.0:
* Static image DVD menus seem to be broken again.
* I am suspicious about the new invmem plugin being a dummy codec rather than
a dummy demux. rawvideo is a demux.
More information about the vlc-devel