[MPlayer-dev-eng] Documenting and extending the subtitles system

[Nicolas George]

Hi.

I would like to try and document somehow how the subtitles and OSD work in
mplayer, in order, maybe, to open the way to new support, especially DVB
subtitles.

I will describe here what I understand is going on, and I would be grateful
if people who actually know confirmed or corrected it. After that, assuming
I am not too wrong, I will describe a few ideas to help make things better.


First of all, the DOCS/tech/osd.txt file is completely obsolete: it predates
libass and ignores it completely, and it was never actually implemented.

There are currently two incompatible mechanisms to overlay something on the
video: OSD (the old one) and EOSD (the more recent one).

* OSD dates back to 2001 without major change. Its features are:

  - Rendering is done in a lot of video output drivers, or in the expand
    filter.

  - Overlaid stuff is stored as an almost-static list of objects in a global
    variable.

  - Overlaid objects have a type field describing their origin. For each
    displayed frame, the OSD system loops on all origins, queries global
    variables and updates the objects.

  - The origin field also implies the format of the OSD object, and thus the
    way to render it:

    - SPU objects are rendered by a call to the spudec subsystem;

    - text objects are in fact made of a gray map (1 octet per pixel) plus a
      bitmap mask (1 octet by pixel as a boolean).

  - A lot of image formats are supported, but for planar formats, only the
    first plane is affected, which is why very saturated colors bleed
    through subtitles.

* EOSD was added for libass. Its features are:

  - Rendering is done in the ass video filter or in a few video output
    drivers.

  - Overlaid stuff is pulled from libass, and may be send through, and will
    sometime travel along VFCTRL_DRAW_EOSD.

  - Overlaid objects are made of an alpha map (1 octet per pixel) and an
    uniform RGBA color.

  - Only YUV420P supported (and I did not understand how subsampling is
    handled in my_draw_bitmap).


Now for possible evolutions. I think that EOSD is almost suitable to use for
all OSD, but two things are missing: full color support and separation from
libass.

For full color support, the changes could be pretty small: the EODS objects
are currently an alpha mask and an unique color, it would be enough to
replace the unique color by a complete color image.

If this color image is stored in the target color space, and the alpha
channel is prescaled for all the subsamplings of the pixel formats, it would
probably be just as efficient as the current version, and support all pixel
formats automatically.

There is one point I am not sure though: would this be OK for the OpenGL
people?

As for separating EOSD from libass, this is not much either, and it would
lead to a much cleaner design anyway. What we need is a well-isolated EOSD
subsystem with:

- an input API, for anyone (libass among others) to add or remove EOSD
  objects;

- a callback API, for anyone to get notification of significant events (such
  as timestamps expiration);

- an output API, for the output drivers or video filters to get the active
  objects and help them to overlay them.


That's all for now: I will wait for some possible feedback before ranting
any longer.

Regards,

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