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

[David Holm]

Arpi wrote:

>Hi,
>
>>>- 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.
>>
>
>Agree. Same for DVB card, and also matrox G400 crtc2 and opengl.
>They all are able to display transparent overlay images.
>
>>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.
>>
>Yes. Michael done a good job with this. Almost all converters and scalers
>are ready to use.
>The best would be:
>A general library which provides an init and convert function, init sets
>surface sizes and colorspaces (and does internal stuff of converters, like
>building tables, convert palette etc) and a convert function which does the
>actual conversion/scaling. It should have an option to choose between speed
>and quality.
>
>>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.
>>
>
>no. my plan:
>video codec -> libvo2 core -> libvo2 driver
>
>libvo2 core will contain all scaling, conversion etc routine, it will query
>codecs and vo drivers for supported features and calculates the best
>buffering method and conversion, allowing overrides by user.
>
ok, this is kinda what I meant... I didn't know there was a libvo2 core, 
I haven't looked at is much since you told me that is was far from 
finished...

>
>
>>Something else, if possible libvo2 should be queried whether it wants 
>>mplayer to scale the codec output or not... Most devices surely wants 
>>
>mplayer won't do scaling and such thing. i want to left mplayer out of this.
>
That makes sense, especially since lots of hardware actually have 
hw-scaling these days...

>
>
>>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??
>>
>why should it be renamed? i see no sense of it. they are different API,
>shouldn't have the same name.
>
since they are compiled into MPlayer and not loaded as devices I only 
see it as confusing with libao2 (and libvo2 when libvo will no longer 
exist), and I get flashbacks to the old and FREQUENT question "What 
happened to MPEG-3?"

>
>
>btw. about libao2... it also need some development. the control() interface,
>resampling, sample format conversion is not implemented at all.
>
>>>- 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 ;)...
>>
>i don't have normal dvds :)
>but i thought they have trackball as some new video recorders :)
>
still, I would prefer if it would work perfectly with just lirc...

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