Re: Re: libvo2 api/design problem

Hi,

> > > I'd prefere #1, but would extend the vo_info_t structure by

the problem is that no such thing called vo_info_t
there is now module_t which is common for all module types
(i didn't like the common info_t thingie, but i ack it's required for
nice config and plugin management code).

> > > a special requirements field and put there a VO_NEED_X11 or something
> > > like that.
> > 
> > Me too.
> I'd like to see smthg like VO_X11_CAPS wich mean that the vo can
> optionaly use a provided window (like tdfx_vid, mga?, etc).
> These won't fail if a window isn't avaible.
> And VO_NEED_X11 for the vo's wich always need a window (x11,xv,etc).
> 
> Imho smtgh in the lines of vo_xover could be intersting too. This is for
> vo's wich use an overlay with colorkey (pretty common in our case).
> I'm too lazy to try to explain xover, so below is some g1 psedo-code.

yes, we definitly need something like this.
Nick's vosub_*.c in g1 tried to implement the same as you in vo_xover (but
he added support for vosub into vo_vesa and vo_fbdev too).
We need to define a standard way of linking overlay and parent drivers, so
every overlay-type driver (be it mga, tdfx, vidix or even dxr3) could be
used with "parent" drivers: x11 (xover), vesa, fbdev, svgalib etc.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu