[MPlayer-dev-eng] [RFC] EOSD improvements

[Nicolas George]

Hi.

Le quartidi 14 thermidor, an CCXVIII, Reimar Döffinger a écrit :
> 1) I first and mainly only suggested making it work with the current
>    luminance-alpha which should be a good idea anyway and not much effort.

I do not think this is a very attractive idea: although it is possible,
fitting the square-shaped peg of a colored image into the circle-shaped hole
of a luminance+alpha API is tedious code that would become utterly useless
if RGBA support is added, as expected.

In building construction, I believe it is considered a bad idea, when the
foundations are seen to be too shaky for a first-story extension, to build
the extension with strings and sticks and later rebuild stronger
foundations.

> 2) For DVDs I think it's likely to be at least not significantly less
>    efficient, possibly even more efficient to do one render pass per
>    palette - but anyway that was just an additional idea.

DVD subs have only four palette entries, with one supposed to be completely
transparent. DVB subtitles can have much more, up to 256 I believe, and I
have seen with 15 used colors for smooth shaded letters.

Furthermore, if the image arrives not in paletted format but in true-color
RGBA, converting it to paletted format is a very complex and expensive
operation. And using the alpha channel to devise a barycentre with the eight
corners of the color cube is a very ugly hack.

The "constant luminance + full alpha mask" format was designed and optimized
for ASS, as it allows to reuse the alpha mask (glyph shape) with a different
color. As such, it is very efficient, and must be kept.

But it is obviously not very convenient for other uses.

> I thought I said clearly the low-level support is _not_ my concern,
> my concern is that we might end up with working but _useless_ low-level
> support because the high-level stuff (time stamp handling etc.) might
> mean it does not work for any of the cases we want to have it working.
> Or to put it differently: I suggest to implement a as simple as possible
> proof-of-concept that does something useful before starting with API-level
> work.
> Of course I only suggest this because I expect it to be minimal to
> no additional work overall.

Converting anything to the "constant color+alpha mask" format is additional
work, and very unrewarding as it is, since it would become useless once the
API work is done.

Requiring it is a sure way to discourage people, as Uoti did to me when I
tried to push DVB subtitle support eighteen months ago.

What about API work along with a simple-yet-useful feature to show its
usefulness? I can think of two right now:

- A pair of slave command to overlay a bitmap file on top of the running
  video:
  bitmap_add tag filename x y w h
  bitmap_remove tag

- A .srtx overlay video filter: .srtx is the same as .srt, but with the name
  of a bitmap file instead of the text of the subtitle.

The first one would mostly supersedes the current bmovl video filter. The
second would allow quick-and-dirty support for any odd subtitles format by
the means of an external conversion tool.

Both would be very easy to implement if EOSD had a clean public entry point,
but are much harder to implement now.

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/20100802/bcd1746b/attachment.pgp>