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

[Uoti Urpala]

On Sun, 2006-06-04 at 12:02 +0200, Reimar Döffinger wrote:
> 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

The difference here mainly seems to be when the bitmaps are created. The
current way of creating them at the end of the main loop outside the
filter chain is certainly wrong; even if there are no filters which
would affect the timestamps, the bitmaps will be rendered even if the
next frame will be dropped and you can only get the correct (next)
timestamp if you rely on knowing it before reading the frame from the
demuxer. I think they should be rendered in vf_ass as part of the filter
chain, or if there's a reason to avoid having a filter appear in the
chain at all then the special case for them should be at the _end_ of
the chain (and in any case at least between decoding a frame and calling
vo flip).

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

Now it renders the bitmaps using sh_video->pts as the time _after_ vo
flip has already been called for the image with that pts, so it's wrong
even if there are no special filters. But as I mentioned above
sh_video->pts is currently somewhat wrong anyway, unless you use the
-correct-pts option in the patch I posted earlier.