[MPlayer-dev-eng] [PATCH] OSD through EOSD
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Aug 13 09:01:24 CEST 2010
On Fri, Aug 13, 2010 at 01:09:39AM +0200, Nicolas George wrote:
> Le sextidi 26 thermidor, an CCXVIII, Reimar Döffinger a écrit :
> > What else to call it? It is alpha, it just has a special optimized
> > representation.
>
> Maybe "transparency", since it is exaactly that. Well, that is a minor point
> anyway.
No, see below.
> > And the value is not pre-multiplied, it is clamped to avoid overflow.
>
> In osd_template, the formula is:
> out = ((in * srca) >> 8) + src
> AFAIK, that means that srca = 1 - alpha (×256) and src = alpha * value.
No, first you missed the srca != 0 check before that. 0 means full
transparency, thus calling it transparency would not be any better
than calling it alpha.
Secondly, maybe it would be more correct if src would be alpha*value,
but that is not the case in general, at least not for data from
spudec.c. Unless of course I missed the pre-multiplications being done
somewhere, in which case it is only the PGS subtitles that are wrong.
It wouldn't be hard to fix, I just don't think there's much of a point,
I'm in favour of making the OSD stuff fast and simple and leave the
better accuracy for EOSD.
> > As said it does not overflow due to explicit clamping.
> > This means the current blending is actually incorrect for most cases.
> > Which is why I said that it may not be a good idea to try to match
> > the OSD behaviour too much, still this should be a difference.
> > And it is also why I think your method of calculating dm is
> > over-complicated: I involves one division per without (I think)
> > actually gaining any accuracy over e.g. v == a ? 255 : v.
>
> I wanted to get my patch working as exactly like the old renderers as
> possible, assuming, against all evidence, that they were doing the right
> thing. You are certainly right about it not being actually necessary nor
> desirable.
I am mostly saying your way of making it work "exactly like the old
renderers" seems to be based on assumptions that just aren't true,
thus you end up with rather slow code without any benefit as far as
the rendering is concerned.
More information about the MPlayer-dev-eng
mailing list