[MPlayer-dev-eng] Re: [MPlayer-users] color of subtitles

[Michael Niedermayer]

Hi

On Saturday 02 November 2002 20:36, Jindrich Makovicka wrote:
[...]
> >>you mean fonts as 24-bit pixmaps?
> >yes
> >
> >>isn't it overkill?
> >perhaps, but it could look really nice :)))
>
> I would postpone this, as I don't want to rewrite all the vo stuff at
> once and keeping both (freetype vs old bitmap) font engines working is a
> pretty tedious work. This is also the main reason why I still didn't
> write the support fur multiple font styles & sizes.
hmm, i dont understand why the palete based method requires less rewrites, 
imho it needs more (all the MMX code for example, and i wont do that) for the 
true-color variant the rendering code is the same so the MMX code could be 
reused IMHO

>
> >>>i would suggest the following approch for color subs:
> >>>1. generate pictures of all chars & colors in RGB32
> >>>2. convert these to the same colorspace as the output buffer
> >>
> >>maybe it would be enough to do these two in draw_alpha_buf
> >
> >yes, good idea, it seems the osd/sub/font stuff is different now relative
> > to the last time i looked at it ...
> >
> >btw, note, 2. can be done easiely with the swscaler
> >
> >>>3. simply render them (the nice sideeffect is that all formats except
> >>>RGB15/16) can be handled by the same osd render function, so there is
> >>> less code to optimize and its simpler & faster IMHO
> >>
> >>what do you mean by "simply" ? in yv12 and yuy2 you still have to deal
> >>with the chroma subsampling (it can't be done sooner because chroma
> >>depends on the x&y position).
> >
> >?!
> >if u have a font in YV12 and render it into an YV12 buffer then the
> > operation is identical to 3 gray font + gray buffers, except that the u &
> > v buffers are 1/4 the size
> >for YUY2 font & YUY2 buffer its just 1 buffer with 2 bytes per pixel
>
> The main issue I encountered was that without a proper y/u/v alignment
> the osd looks ugly. Before putting the buffer on the screen, you don't
> know how they'll be aligned, it depends on the x and y position mod 2.
> (see the patch and the xmod & ymod params, there's also some kind of
> antialiasing of u & v).
hmm, perhaps just restricting the position to x y %2==0 might be acceptable

btw
 if (srcp[0]) { pal_idx = srcp[0]; cnt++; }
 if (srcp[1]) { pal_idx = srcp[1]; cnt++; }
 if (srcp[srcstride]) { pal_idx = srcp[srcstride]; cnt++; }
 if (srcp[srcstride+1]) { pal_idx = srcp[srcstride+1]; cnt++; }

 s = pal[pal_idx];
 d = *dst;
    
 d -= 128;
 s -= 128;
   
 d = (d*(4-cnt)+s*cnt)/4;

 *dst = d+128;

appears very broken to me
 pal_idx= (srcp[0] + srcp[1] + srcp[srcstride] + srcp[srcstride+1] + 2)>>2;
 *dst += pal[pal_idx];
might be better, if i understand the intended meaning of the code correctly
but it might require some change to pal[]

Michael