[MPlayer-dev-eng] Colored subtitles

[Alban Bedel]

Hi Jindrich Makovicka,

on Thu, 07 Nov 2002 13:09:48 +0100 you wrote:

> Alban Bedel wrote:
> 
> >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 ;)
> >
> Well, it's about 50% bandwidth increase in the case of YV12 but on the 
> other hand it solves the problem with subtitles which were getting the 
> colors of the movie behind them. This annoys me on the current version 
> more than the disability to choose my favourite subtitle color.
> 
> >>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 ;)
> >  
> >
> Implementing OSD as a video filter is a nice idea but there are issues 
> at least with SDL & X11 drivers. vo_SDL needs access to subtitles to 
> display them in the black bands, and X11 accepts only YUV  formats. So 
> for (current) vo_X11 we would have to convert the subs to YV12, render 
> them and pass the result to vo_X11 which converts it to RGB => loss of 
> the quality and performance.
We don't have to care about this hack in vo_sdl as vf_expand can do same
thing. imho it should 
> Furthermore, vo_aa needs its own subtitle support, for obvious reasons. 
> (I would say that AA is marginal and nobody will eventually miss the 
> subtitles, but I can be wrong ;)

I don't think so (as i'm/was more or less maintaing vo_aa ;) I thought about this a bit
deeper today. Bcs we have to solve the dr problem also. Actually dr is disabled by
default bcs of the osd :(((

We have 3 case for the vo :
	1/ it support some kind of "encoded" subtitle. Obviously for the mpeg vo wich
	    support spu but also for vo aa (it can use hw acceleration to draw txt ;)
	2/ the vo have a surface that can be used to draw an unscaled overlay.
	    All (yuv) overlay based vo should be able to provide this (tdfxfb, xmga,
	    dxr2, etc but not xv afaict). 
	    Colorspace and resolution may not be the same than the video (usely it will
	    be a TEMP or STATIC RGB image).
	3/ Nothing of the above. Then we have to restrict the dr to TEMP or save/restore
	    the modified parts if that is possible.

My idea is to have a second filter chain for the subtitles wich is then joined with the
video filter chain with a special video filter (or in vo_expand if this isn't too messy).
We could treat the subs as just-another-mp-image-format and reuse parts of the
vf stuff or write a brand new kind of filter. But this filter chain have to accept
mp_image as input data (for spu encoding/ocr) and it also end with the vo.
It seems to me that we should really treat the subs like special video codec,
after all a subtitle decoder produce a video.
Finnaly with such approch we don't have to touch anything in the old code, just
reuse it to write something consistant and flexible like we have for audio and video.
Then adding color support or any other fancy feature will be easy and clean.

	Albeu