[MPlayer-dev-eng] Colored subtitles

Alban Bedel albeu at free.fr
Thu Nov 7 11:16:12 CET 2002


Hi Jindrich Makovicka,

on Wed, 06 Nov 2002 18:28:29 +0100 you wrote:

> Alban Bedel wrote:
> 
> >Imho color space conversion should be done only once. Converting all the time
> >is a waste of cpu time (even if you have too much idle time there's some better way
> >to use it ;)
> >
> It's done once per subtitle. I don't think that pre-rendering all 
> characters in all thinkable colors is a good idea. It also means you 
> need to pass the information about used video format to yet another 
> layer of code and you need another bunch of functions for various 
> colorspaces which will render into the osd buffer.
You'r right, it's better so.

> >>Stuff that (probably) works: xv (YV12) x11 (tested with 32bit), sdl (32bit)
> >>Stuff that surely doesn't work: spudec, aalib, anything yuy2 & uyvy
> >>
> >>Interface changes: vo_draw_text and vo_remove_text now have one more 
> >>argument for desired image format, vo_draw_alpha_yv12 has additional 
> >>args for more layers.
> >>    
> >>
> >I think that it must be done in some other way. First I still want the old osd that
> >only use the Y plane as it's faster. And i don't think that it's a good idea to modify
> >the existing vo_draw_alpha_* funcs as most of them (all ?) are optimized for x86.
> >
> My code is still not optimized and I don't see any special performance drop. There
> is more source data but the amount of written data is the same.

With RGB the amount of data is the same, but not with YUV. Dunno what kind of cpu
you have but it really matter when you have a slow cpu (and i have one ;)

> >Imho we should keep the existing stuff in the vo as is. Write some _new_ drawing
> >funcs that support colors, etc. Use this in the expand filter as an alternative osd
> >mode. Then it could be added to the vo wich really need a special osd support
> >via control.
> >
> This means duplicating of osd.c and sub.c (and probably spudec). One 
> version for color, one for mono.
I see what you mean. It then perhaps a better idea to rethink the subtitle stuff
from the ground.  Shouldn't we rather try to integrate the subtitles properly in
libmpdemux and libmpcodecs. That would make sense imho we could then have
a proper color support and subtitle filters for convertion, spu encoding, spell
checking, etc (add more sub fans dreams here ;)
	Albeu



More information about the MPlayer-dev-eng mailing list