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

[Reimar Döffinger]

On Mon, Feb 23, 2009 at 04:07:37PM +0100, Nicolas George wrote:
>   - Overlaid stuff is stored as an almost-static list of objects in a global
>     variable.

There is no reason for it to be static or almost-static, though I may
misunderstand what you mean.

>     - 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).

Uh, no, no boolean. It is a luminance and a alpha bitmap, though alpha
is represented in a way that allows faster software rendering, and alpha
is first applied to the source then the luminance is added.

>   - 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.

No, this is just an optimization of the software renderer. Hardware
renderers as in vo_gl, vo_direct3d or vo_vdpau will not do this.

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

No, VOCTRL_DRAW_EOSD will contain the data, VFCTRL_DRAW_EOSD is only a
notification that it is now time to draw the OSD. On the vo side,
VOCTRL_GET_EOSD_RES is also used to get rendering parameters like
margins etc.
The reason all this is only done for the vo is that there is only one
filter that implements EOSD rendering, so there was no need to factor
this stuff out at the filter level.

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

You are again mixing up restrictions of the implementation (and only
that in vf_ass) and the concept.
vf_ass does not support anything else because nobody saw the need to
support anything else, not because there are any particular issues.
And subsampling is not handled in my_draw_bitmap because that function
operates on copies of the U,V planes that are not subsamples (AFAICT).

> 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.

For performance/simplicity reasons, yes.
I think you can do full-colour rendering with what is already there
though, even if it would be quite tricky (I did not actually research
this yet though).

> 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?

Depends on what you consider the "target colorspace". It should not be
required to be the same one as whatever the actual video uses.