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

[David Holm]

Arpi 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.
>
>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
>
I think OSD/Subtitle support should be queried...
The DXR3 has subpicture support which would be perfect for handling 
this, other drivers that don't need to handle it should receive a stream 
with the OSD/Subtitle already applied, instead of the driver developer 
coding a draw_alpha, since most drivers except the hardware ones most 
probably will just convert it to the surface format used.

Also, there should be a global yuv2rgb rgb2yuv library, it's not funny 
to implement conversion routines over and over again, and say I need 
BGR24->Yuv420p(ffmpeg), instead of implementing it in my device I would 
add it to rgb2yuv so the next guy who needs it won't have to do it.

Also, don't you think the best solution would be if the libvo2 device 
told mplayer which formats it support and then mplayer handle pixel 
conversion as needed... one bonus of this is that people won't implement 
their own (perhaps) slow conversion routines just to get their device 
working and then forget about asm 3dnow/sse etc optimization.

Something else, if possible libvo2 should be queried whether it wants 
mplayer to scale the codec output or not... Most devices surely wants 
output scaled to the used resolution, but hardware devices might do that 
automatically (like the dxr3)

I would be happy to start a conversion of dxr3 to libvo2 still keeping 
the libvo version current for normal users. I love MPlayer and would do 
anything to benefit it's development.

I also have another request, when libvo2 is complete and all devices has 
been converted, can't it be renamed to libvo as well as renaming libao2 
to libao??

>
>- handling input events (key, mouse events (mouse is required for dvd menus))
>
A mouse shouldn't be required, most "normal" dvd's have just arrow keys 
on their remotes you know ;)...

>
>- 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
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>