[MPlayer-dev-eng] Documenting and extending the subtitles system

[Reimar Döffinger]

On Tue, Feb 24, 2009 at 08:04:35PM +0200, Uoti Urpala wrote:
> On Tue, 2009-02-24 at 09:33 +0100, Reimar Döffinger wrote:
> > On Tue, Feb 24, 2009 at 12:36:41AM +0100, Nicolas George wrote:
> > > The ass_image_t has only one global field for the color, so apart from
> > > splitting the overlay into one object per color, which is an awful waste, I
> > > do not see how.
> > 
> > If it was one object per colour that would not be particularly wasteful
> > and IMO not work the effort.
> > But with full alpha-blending you would actually need 8 steps, namely
> > with the colours
> > black, red, green, blue, cyan, magenta, yellow, white
> 
> The libass glyph+border case would not require this because all the
> occurring colors can be represented as a mix of the two original colors.

I thought this was about representing generic images (and doing real
alpha-blending with transparency).

> However the need to adjust the bitmap applied first based on the alpha
> of the second bitmap probably still makes it impractical.

Not sure if that really is so much of an issue.
It could be avoided by just adding a mode that allows to do
src + alpha * color instead of alpha-blending.
>From the OpenGL side I am not sure if/how well glBlendFunc works in
display lists, and from the VDPAU side if changing the blending function
will cost performance.
It would allow additional effects though (and might be slow in software
due to requiring clamping if done properly).

> > and the coefficients (those stored in the bitmap, r, g, b, a stand for
> > the desired overall blending value and assuming I did not miscalculate):
> > a8 = FFMIN3(ar, ag, ab);
> > a7 = FFMIN(ar, ag) - a8;
> > a6 = FFMIN(ar, ab) - a8;
> > a5 = FFMIN(ag, ab) - a8;
> > a4 = FFMAX(0, ab - FFMAX(ar, ag));
> > a3 = FFMAX(0, ag - FFMAX(ar, ab));
> > a2 = FFMAX(0, ar - FFMAX(ag, ab));
> > a1 = 1 - (1 - a) / ((1 - a8) * (1 - a7) * (1 - a6) * (1 - a5) * (1 - a4) * (1 - a3) * (1 - a2))
> 
> That's missing some scaling factors to account for the order in which
> the bitmaps are applied

Yes, a7, a6, a5 must be divided by (1 - a8) and
a4, a3, a2 must be divided by (1 - a8) * (1 - FFMAX3(a5, a6, a7))
(that uses that out of a7, a6, a5 and a4, a3, a2 respectively at most
one is not 0), which also simplifies a1 to
a1 = 1 - (1 - a) / ((1 - a8) * (1 - FFMAX3(a7, a6, a5)) * (1 - FFMAX3(a4, a3, a2)))