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

[Reimar Döffinger]

Hi,
On Sun, Jun 04, 2006 at 09:54:50AM +0300, Uoti Urpala wrote:
> On Wed, 2006-05-31 at 22:28 +0400, Evgeniy Stepanov wrote:
> > The architecture is now like Reimar suggested: ass_render_frame() produces a 
> > list of bitmaps, that are blended later by vf_ass.
> 
> I think his suggestion wasn't quite that, but rather that vf_ass create
> the list of bitmaps without necessarily blending them to the image,
> which could be done inside the vo instead in some cases.

No, I think he understood me right. Though instead of using the global vo_ass
variable I had thought about using a VF_CONTROL message. But I can't say
which approach really is better. It would have some advantages with
audio filters (inserting the filter when it is needed the first time,
as done with -af volume when there is no hardware mixer available),
but the video filter chain is much less flexible so it might not be worth it here.

> This might
> avoid an extra copy of the frame in case the original image vf_ass gets
> cannot be changed, but the vo needs to do a copy internally anyway and
> that copy can be changed before displaying it.

Hmm. As I understood the code, you can just leave vf_ass out and it
should happen that way. Though I admit I didn't look closely at the
auto-loading code - in the future it would probably have to check if teh
vo already suuports the functionality and not load vf_ass then.

> The way you currently
> implement it won't get the timecodes quite right (though it's hard to
> see when they're not right anyway in the current MPlayer - I intended to
> improve that when CVS went down and will probably continue some time
> after SVN is finally up). You should code it so that the time of current
> frame used by subtitle rendering can be read from the pts argument to
> vf_ass (though that argument isn't yet set in current unpatched
> MPlayer).

Hmm... maybe I misunderstood, but I though vo_ass just contained the
subtitles for the currently rendered frame... Well, I guess it might
break a bit when using filters that introduce a delay, e.g. -vf tile or
-vf ivtc or so.

Btw. the vf_ass variable is defined globally in mplayer.c, but used only
in one place, so I guess it could be moved.

Greetings,
Reimar Döffinger