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

David Holm dholm at telia.com
Tue Nov 6 12:22:25 CET 2001 

I came up with some more ideas while showering...

David Holm wrote:

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

It should also be queried for PXLFMT... And that means adding support 
for PXLFMT_SUBPIC since that is the format used by dvd's (RLE encoded 
pixmaps consisiting of max 4 colours/subpic selected from a palette of 
16 colors of which one color is transparent).

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

Another thing, libvo2 should have a device configuration scheme...
how about something like this:
struct vo_options libvo2::get_options();
struct vo_options {
        int num_options = 2;
        char *options[] = {"Fullscreen","Devicename"};
        char option_types[] = {'b', 's' }; (where b = bool, s = string, 
and so on
        void *options = "0x0/dev/device\0"
}

I think libao2 should have this too... this makes it easy as hell to add 
options complying ONLY to that device and has no restrictions whatsoever...
then of course int libvo2::set_options( struct vo_options );

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

You probably thought of this, I wrote it just in case ;)... I want to be 
able to use lirc, not lirc+$$$wireless mouse

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

I don't want to inpose on your role as project leader but things like 
these should be discussed here thoroughly and then the person in charge 
writes a tech-SPEC, post's it and waits for feedback, after discussion 
of the SPEC it's set as the standard to be used, that will make it clean 
and hopefully work for most cases...


Another thing, we discussed that pluggable gui system a few posts back, 
I don't know who is in charge of gui, but I could take care of the 
pluggable gui system (discussing, spec, implementation, etc) since I 
have a good deal of experience on pluggable modules...
I could do this right after I've released the first public dxr3 patch...




Do you use C++ code in mplayer or is it constrained to C only?

//David Holm

More information about the MPlayer-dev-eng mailing list