[MPlayer-dev-eng] About the future - libvo2...
nickols_k at mail.ru
Tue Nov 6 14:01:58 CET 2001
On Tue, 6 Nov 2001 14:19:37 +0200 (CEST), you wrote:
> > >
> > > So. We shouldn't delay it more. We should begin to design and implement.
> > >
> > IMHO - right way is to have two branch simultaneously: livo and libvo2.
> > It makes replacement much easy.
> it's done - as you can see, there are #ifdef USE_LIBVO2 over teh source.
> we should add a --with-libvo2 option to configure to make switching easier.
When I tried to do that - I get a lot of errors ;)
> > IMHO - libvo2 requires major changes too:
> > For example vo2_vesa ;)
> > I planed to add some hw acceleration into this driver in the future.
> > But in libvo stuff - function query_format is called before init.
> > But for implementing -vo vesa:radeon for format query driver should now subdevice
> > before calling query_format. Else it will not able to answer correctly for this query.
> > As I found vo2 will have the same logic.
> > Therefore it would be better to add something like: preinit() function
> > to parse subdevice then perform control(QUERY_FORMAT) call.
> hmm. it was planned so. i know this problem, so libvo2 usage:
> init() - inits the device
> control() calls - query features, set parameters etc
> start() - opens a window / enable device, allocates buffers.
> so, really init() is renamed to start(), and init() now means your preinit.
> maybe we should change names to preinit/init to avoid confusion.
I guess - current stuff of libvo2 is not final edition and will be expanded in the
> A'rpi / Astral & ESP-team
> mailto:arpi at thot.banki.hu
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
Best regards! Nick
More information about the MPlayer-dev-eng