[vlc-devel] Rant about VLC video outputs

[Rémi Denis-Courmont]

	Hello all,

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 
suxxor thread).

* 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 
locking rules.

* 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.

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