[MPlayer-dev-eng] [PATCH] OSD through EOSD

[Nicolas George]

Le quintidi 25 thermidor, an CCXVIII, Reimar Döffinger a écrit :
> Uh, the problem with using EOSD only is hardware-based overlays like
> XvMC that I am quite convinced can't support EOSD.

XvMC supports OSD. It means it has some sort of draw_alpha sent to
vo_draw_text. Actually, they are called draw_osd_IA44 and draw_osd_AI44.
These functions can draw a grayscale alpha overlay on top of the video. With
very little work, these functions can be used to render EOSD objects in
grayscale. And with a little more work, they probably can be adapted to
support color too.

The same could apply for the other VOs that support OSD in a specific way
(except aa).

I see a three-step progress: first OSD -> EOSD is optional, then XvMC
draw_osd_IA44 is adapted to draw EOSD, then OSD and EOSD are completely
merged.

> Not to mention the reason for why the alpha is the way it is
> and why chroma is not touched (performance).

I am pretty sure too that transparency + premultiplied value is better,
performance wise, than opacity + raw value. But just for readability's sake,
do not call it alpha or a if it is not alpha.

> As such, a full replacement does not seem the right goal, except
> if you mean optionally.
> Working on displaying the SPU part only rather all of the OSD might
> be better, since that needs to be modified anyway.
> But as long as you keep my two point above in mind, do as you think
> is best.

I will keep these points in mind, and I intend to be extra careful to avoid
any regression.

> Tab slipped in.

This patch was not intended to be applied in the official tree: I did not
pay any attention to details such as alphabetical order or tabs. I will of
course be careful for any real patch I may send in the future.

> Not sure what exactly this does, but keep in mind:
> 1) uint8_t a = -srca[...] is a "simpler" way to convert alpha

Indeed, the 256 is completely useless with a & 0xFF just after.

> 2) The osd actually does source * alpha + color, I don't think
>    this can be 100% reproduced with EOSD (not that it may be a good
>    idea, however I suspect that calculation is more complicated
>    than necessary).

Indeed, "source * k + c" is more expressive than "(1-a) * source + a * value",
since c can overflow while a * value can not. But AFAIK, the current OSD
code does not use it.

I have tested my patch: the timestamp/message, the text subtitles and the
progress bar are correctly displayed. I can not test every variant of SPU
and cousins, but they come from "real" alpha channels, so they should not
overflow.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100813/31b2f576/attachment.pgp>