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

Arpi arpi at thot.banki.hu
Tue Nov 6 14:02:40 CET 2001


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.

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

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

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


A'rpi / Astral & ESP-team

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



More information about the MPlayer-dev-eng mailing list