[MPlayer-dev-eng] Direct3D OSD discussion

[Jim Hauxwell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Reimar,

I was not aware of the reference code to do the osd blending, so I've
taken a look at this and basically copied what it does.

I've attached a patch which follows the exact blend rules

((dst * srca) >> 8) + src

it uses a constant color to pass the multiplication for src, so its actually

(1.0f * src) + (dst * srca) where srca is a float

As a side effect you can change the color of the subtitles by changing
the DWORD value in this line,

IDirect3DDevice9_SetRenderState(priv->d3d_device, D3DRS_BLENDFACTOR,
0xFFFFFFFF);

for red choose 0xFFFF0000, for example


Jim


> On Tue, Nov 25, 2008 at 06:08:04PM +0000, Jim Hauxwell wrote:
>>> I don't think so. Also
>>> +            if(srca[x]){
>>> +                dst[x]=(~srca[x] << 8) | src[x];
>>> +            }
>>> Why ~srca[x]? I think it should be -srca[x] (a quicker way of writing
>>> ~srca[x]+1).
>>
>> No, I wrote what I wrote,
>>
>> -srca[i] gives the incorrect answer.  If you take the value 0x0 then
>> this gets transformed to 0x0 and not 0xFF which is the correct result.
> 
> Why do you think that 0xFF would be the correct result?
> Due to the if, for your code the result is 0, too, btw.
> Also, with your code, the final alpha value will never be 0xFF actually, thus
> the OSD is never completely opaque.
> 
>> This is a bug in vo_gl.c, not my code.
>>
>> If you need a small test then I'll knock up the four or so lines to
>> prove it.
> 
> Sure, prove it because I don't think it is a good way (without a
> specification right and wrong is a bit difficult to say, the differences
> are almost never visible).
> 
>>> Note that for blending that matches the other vos, one of your blend
>>> settings should be D3DBLEND_ONE (the one that applies to the OSD
>>> texture).
>> Again, this is not a bug in my patch.  The others vos (well gl anyway)
>> uses a two pass blend, mine is a single pass, so this is the correct
>> blending.
> 
> I can't see how single or two pass has any relevance (except that
> vo_gl.c current implementation of two-pass can not do "correct"
> alpha-blending due to discarding the alpha).
> The point is that the OSD rendering formula for MPlayer (as seen in
> osd_template.c) is:
>             if(srca[x]) dstbase[x]=((dstbase[x]*srca[x])>>8)+src[x];
> (note that this is the C code which is somewhat broken, the asm code
> does the clamping to [0,255] before writing back, it isn't noticed
> usually because currently src is 0 when when srca > 1)
> Alpha-blending as you do it is _not_ the same thing, e.g. if you do
>   for (int i = h * stride - 1; i >= 0; i--)
>   {
>     if (srca[i]) srca[i] = 0xff;
>     if (src[i]) src[i] = 90;
>   }
> The effect will be different from anything you can get with
> alpha-blending.
> This is not important enough to justify a huge workaround, but I do not
> see why it would be a good idea to make vo_direct3d's behave
> different than all of the rest of MPlayer on purpose.
> 
> Greetings,
> Reimar Döffinger
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkslBMACgkQhrNWoHjgI1A7DQCgpuSIQisJLs8SmqNuRRCrghuz
9igAoMhbPp9UZnU7eBThNxrzWUfpxVuy
=cXSh
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff7.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081126/c427c774/attachment.txt>