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

[Felix Buenemann]

On Tuesday, 6. November 2001 00:19, you wrote:
> I think it's time to begin working on libvo2.
yes.
> [don't worry, porting drivers libvo->vo2 will be few-minutes work]
I'm sure it won't ;) many drivers need a rewrite badly.
>
> Major planned features are done, at least they are on their way:
> - cache (was erquired for network streaming)
> - libmpdemux
> - mencoder
may I add one very interesting here:
- playback audio from seperate file (mp3, wma, etc), this will also be needed 
for mencoder sooner or later and of course for microdvd style divx.
>
> Still on top TODO list:
> - libvo2
> - codec selection (find the best libvo-codec pair, apply conversions etc)
my idea is to enhance codecs.conf by a priority field represented by an 
integer, so codec selection can fal back from one to another, also 
availability of a codec should be taken better into codec consideration, eg. 
auto-fallback to next suitable codec if a needed dll isn'z found.

> - subtitle stuff (dvd subs, update only if changed, sub under the image
> etc) they are really one -> libvo2.
yes we need some uniform libvo2 code to render images with indexed or alpha 
transparency, it needed for vobsub, dvd sub (basically the same), aswell as 
microdvd, dvd, vcd and svcd menues and might aswell be used for various other 
osd or subtitle stuff (if we support all these we definitly kick ass! :)

We also should create enhancements to input core to allow for mouse control 
and stuff which will sooner or later be needed for menu support or maybe an X 
independent gui that is rendered into the visual or a kewl mouse/keyboard 
enabled osd menu for configuring various mplayer stuff.
>
> So. We shouldn't delay it more. We should begin to design and implement.
>
> 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...
>

with libvo2 a have great degree of modularity in mind this means for me:
supply all common stuff in software (scaling, osd, cropping, subs, input 
layer, colorspace conversions, postprocessing) but at the same time allow all 
of these functions to be overriden with vo specifc functions maybe using 
function pointers for all of this that may be filled during vo init and if 
not default one from libvo2 core will be used. This would also allow to 
switch each of this features off if unwanted.

Also we should rework communication layer between mplayer and vo, thousands 
of single globals are ugly and flags are unflexible, maybe using global 
structs like one for aos and one vos where each of them has multiple members 
that can be set or queried by vos, this also makes it easier to free stuff 
after use (multi file, runtime vo switching, etc).

> How?
> - libvo2 drivers should be very simple. they shoule provide requested
> amount of surfaces and allow codecs/libvo2 core to render things into it

yes, method of modularity described above should significantly reduce code 
bloat of vos and keep em as simple as possible.

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

yea and also provide software fallbacks in libvo2 core, current postproc code 
already gives us quite good base for it, eg. vo x doesn only support yuy2, so 
we simply do the convert instead of failing like it is currently.

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

yes, see above, we also should make input core optional so not all putput 
driver also have to care about input.
maybe even support some sort of "libinput" that would allow different plugins 
for alls sorts of input, like keyboard, ir etc only prob that comes up here 
is that sometimes input handling is quite knitted together with video output 
so I'm not sure it's possible to clearly seperate it.

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

could you describe in mre detail what of these means what?

>   it should handle colorspace conversions, scaling, croping etc. too.
yea teapot2rgb etc ;) see above again.
>
> i'm stopped here.
> we should find out:
> - osd/subtitles thing
> - handling input events (key, mouse events (mouse is required for dvd
> menus)) 
yes see above, I'm quoting quite bad today :)

> - codecs selection, choosing the best codec+conversion+vo mode.
> - resolution switching (finding the best mode for drivers which can do
> that)

yes and supply unified helper code (== aspect calc etc) in libvo2 core so no 
every vo needs to reimplement the wheel.

we also shoudl allow something like doing downscaling via software and 
upscaling via hardware as needed with many xv drivers for example.

>
> i hope this mail started a long, interesting thread and at the end we will
> change default vo to libvo2 :)
hope so too, I'm interested what ideas other vo developer have.

btw. maybe also some configuration file for each vo (well packed together in 
one big file divided by sections or something like that a bit like 
codecs.conf) would be nice to configure eg. if vo xy will use it's inbuild 
osd funtionalyity, which is but looks ugly, or use libvo2 inbuild code, same 
could for example apply for scaling etc,etc,...).
>
> A'rpi / Astral & ESP-team

-- 
Best Regards,
	Atmos

--no sig yet, suffered a system crash :(--