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

[Nick Kurshev]

Hello, Arpi!
On Tue, 6 Nov 2001 01:19:27 +0200 (CEST), you wrote:

> Hi,
> 
> I think it's time to begin working on libvo2.
> [don't worry, porting drivers libvo->vo2 will be few-minutes work]
> 
> Major planned features are done, at least they are on their way:
> - cache (was erquired for network streaming)
> - libmpdemux
> - mencoder
> 
> Still on top TODO list:
> - libvo2
> - codec selection (find the best libvo-codec pair, apply conversions etc)
> - subtitle stuff (dvd subs, update only if changed, sub under the image etc)
> they are really one -> libvo2.
> 
> 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.

> Design? Yes. libvo1's bigges problem: was not designed for our needs.
> it was inherited from mpeg2dec with libmpeg2 in old days, and modified
> a bit by lots of patches, but the basic design didn't changed.
> 
> We should first design libvo2 API, to meet all of our needs.
> I started this work few months ago, but it is far from being completed.
> If the basic design is ok, we should port a few drivers. For a good
> starting point, port x11 and xv. one of them is available for everyone.
> Later we could port dvb or dxr3 to see how hardware decoder support works.
> 
> Ok, I'll summarize my ideas, plans for libvo2 here. Please comment it, tell
> me if you don't agree of you need more or you want to do something in
> different way. Most of libvo drivers are done by YOU guys, not me, so you
> know them better than me!
> 
> What should it solve:
> - direct rendering
> - colorspace conversion, flipping, scaling, crop, postprocessing(?)
> - support for hardware decoders (dvb, dxr3)
> - implement a general control() interface for special and not-so-special
>   features, settings
> - work together with the gui (allow gui to control window position, size etc)
> - simpler driver programming, in other words: less redundancy. move common,
>   general code to libvo2 core, not copy driver by driver...
> 
> How?
> - libvo2 drivers should be very simple. they shoule provide requested amount
> of surfaces and allow codecs/libvo2 core to render things into it
> - they should implement various mandatory and optional control() functions.
> for example, get number of surfaces, quesy a colorspace for support will be
> mandatory, but fullscreen switching and other special features are optional.
> - we should allow optinaly that drivers implement given core functions, like
> subtitle rendering (for opengl and hardware decoders with overlay supp)
> - libvo2 core should control the whole buffering thing, depending on
>    - user option (single/double/triple/auto buffering selected)
>    - libvo driver abilities (does it supports hw doublebuffer etc)
>    - codecs requirements (there are 3 type of codecs in viewpoint of
>      buffering: single temporal, single static, PPB-type)
>   it should handle colorspace conversions, scaling, croping etc. too.
> 
> i'm stopped here.
> we should find out:
> - osd/subtitles thing
> - handling input events (key, mouse events (mouse is required for dvd menus))
> - codecs selection, choosing the best codec+conversion+vo mode.
> - resolution switching (finding the best mode for drivers which can do that)
> 
> i hope this mail started a long, interesting thread and at the end we will
> change default vo to libvo2 :)
> 
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.

That's all for now.

> A'rpi / Astral & ESP-team
> 
> --
> mailto:arpi at thot.banki.hu
> http://esp-team.scene.hu
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


Best regards! Nick