[MPlayer-dev-eng] About the future - libvo2...

[Arpi]

Hi,

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

> 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:

libvo1:
query_format()
init()

libvo2:
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.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu