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

[Arpi]

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.

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

A'rpi / Astral & ESP-team

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