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

[Reimar Döffinger]

Hi,
On Wed, Apr 19, 2006 at 11:32:13PM +0400, Evgeniy Stepanov wrote:
> 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 ?

I mean
void ass_find_sub(unsigned long long timecode) {}
in ass.c vs.
#define ass_find_sub(l)
in ass.h

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

You misunderstood. Not a full image, just the same size as
ass_draw_bitmap. Or more precisely, the idea is: move everything except
the ass_draw_bitmap function out of vf_ass and into libass.
There, place all ass_draw_bitmap calls by something along the lines
vf->control(vf, VFCTRL_PERIODIC_UPDATE, &struct_with_draw_params);
(a helper function similar to af_control_any_rev might be helpful).
I guess this is not a requirement, but with the current design I fear it
might be very hard to extend. I also admit, that with my proposed
changes, we almost get a second vf_osd...

Greetings,
Reimar Döffinger