[MPlayer-dev-eng] Documenting and extending the subtitles system
Uoti Urpala
uoti.urpala at pp1.inet.fi
Tue Feb 24 20:47:55 CET 2009
On Tue, 2009-02-24 at 19:29 +0100, Reimar Döffinger wrote:
> 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).
That too, but I think it's still useful to consider the libass case (and
remember that at least currently it does not necessarily need full RGB).
> > 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.
I'm not sure exactly what you're suggesting; if you mean only adding a
flag to EOSD that tells whether to apply a particular bitmap with the
above formula then that is not enough to avoid creating additional
bitmaps. When we have an antialiased glyph and its border we want to
render them as
color = (1 - glyph_alpha - border_alpha) * video_color
+ glyph_alpha * glyph_color + border_alpha * border_color.
If you only have the operation above then you need a bitmap for the sum
of glyph_alpha and border_alpha. So at least you'd need to be able to
specify repeated application of the formula to arbitrary arguments (not
just original video) and use the results as new arguments (for example
first calculate the sum, darken original video based on that bitmap,
then do the addition for glyph and border - not necessarily the most
efficient way but would work).
More information about the MPlayer-dev-eng
mailing list