[MPlayer-dev-eng] [PATCH] SSA/ASS subtitles support

[Evgeniy Stepanov]

On Wednesday 19 April 2006 17:59, Reimar Döffinger wrote:
> The stub functions in ass.c might be cleaner to do via defines in
> ass.h (wouldn't cause useless function calls etc.), not sure about
> it though.

You mean ass_find_sub, ass_change_track ?
Or STRVAL, COLORVAL, etc. ?
Don't understand your idea.

> The utf8 conversion functions (ass_utils.c) are, to be honest,
> butt-ugly. But that is simple to fix later on. Though one comment
> on it, why do you pass a pointer to utf8_charlen instead of just the char?

No idea ;) I've taken them from openldap and didn't change much.

> Two things I was wondering about but couldn't find out myself:
> 1) do the changes to demux_mkv.c cause any problems for the current
> subtitle code? I.e. if this patch is applied, will there be any
> differences between what the old and the new subtitle code support
> except the extended things like color, positioning etc.?

Old code should work exactly as it did before. Some info is passed from 
demuxer to the new code, but nothing is modified.

> 2) how difficult would it be to make a vo support this? I think for this
> it would be preferable if only the ass_draw_bitmap was in the filter
> and the rendering would be done some place outside, with the
> ass_draw_bitmap function being called via a VF_ message. Such a drawing
> function would be easy to implement in the vos as well, and vf_vo could
> pass such a message on to the vo if none of the filters accepted it.
> Thus there shouldn't be any need for special cases.
> Or is there too much data that the other functions currently in vf_ass
> need and is only available there?

We can render subtitles from somewhere before decode_video() into an alpha 
buffer, and blend it into image later (in vf_ass or some vo_). But would not 
blending a large (full video dimensions in the worst case) image be too 
slow ? What is the possible gain of this ?