[MPlayer-dev-eng] [PATCH] libass: fix parsing of tracks extracted from containers

[Aurelien Jacobs]

On Sun, 7 Sep 2008 12:38:50 +0400
Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:

> On Sunday 07 September 2008 05:08:39 Uoti Urpala wrote:
> > On Sun, 2008-09-07 at 01:23 +0200, Aurelien Jacobs wrote:
> > > BTW, if you really think this information should get out of the
> > > demuxer, could you propose a way to do it ?
> > > I don't think that putting it in a separate field in AVPacket is an
> > > acceptable idea, because this is a matroska specific field.
> >
> > One possibility is to revert your changes to the packet format and go
> > back to the one Matroska natively uses. IMO there is no reason to think
> > your "each packet stored exactly like a line in monolithic .ass files"
> > is any more valid a format than the one used by Matroska. That format is
> > the one used for practically all embedded ASS subs, and AFAIK it does
> > not have any technical problems that your version would fix. You seem to
> > have just decided that you must change the way ASS is stored when muxed
> > as a packet stream, with little practical benefit or justification for
> > your change. You could supply a separate function to convert to your
> > desired format if you want.
> >
> > I remember two arguments you've used to justify your format change: that
> > the Matroska version is "not real ASS" and that other container formats
> > wouldn't use the same one. I see no reason why each packet would have to
> > exactly match one line in an .ass file. Nor do I see a reason for other
> > containers to use a format different from Matroska (has any container
> > actually picked such a different format?); and even if they did, with
> > practically all existing files being in Matroska format wanting to use
> > another as the default seems weird.
> 
> I completely agree with this. There is no reason to prefer .ass format to the 
> one used in Matroska containers.

Well, let's see.
Here we have 2 different formats. One which can contain the subtitle display
duration through the mean of start time and end time (aka .ass format) and
one which can't store this information (aka matroska's ass format).
Matroska is the only container which can store display duration by itself.
So matroska's ass format can't be used in any other container. So it just
can't be used as a kind of universal format.
The only format left is standard .ass format (unless you can show me another
more popular format which can store display duration by itself).
I don't say that standard .ass is perfect or anything, but that's the least
worst format we have which contains display duration, and no one came up
with anything better up to now.

> Why don't you keep the ReadOrder field in demux packets and strip it in .ass 
> muxer?

That's not only .ass muxer. It's about all container muxers... And even if
you strip ReadOrder in all the muxers, when you try demuxing the result
you don't have any ReadOrder that you can use in libass.

> > Buffering cannot give a 100% perfect solution, but it can give an
> > improvement.
> 
> It indeed improves user experience. For instance, if I did not catch a phrase, 
> I scroll 10 seconds back, and there is a rather high probability that I will 
> get to a point after the subtitle packet but still in the subtitle time frame.

I absolutely agree about this. This is a desirable feature to have.
But buffering is not the appropriate solution for this. That's the demuxer's
job to provide the relevant subtitle packets after a seek.
So I've just improved the demuxer, which now achieve this. Unfortunately,
it only works for indexed subtitle packets, and most matroska files don't
contain subtitle index. So this will generally only works for the parts
of file which were already played (and thus indexed). Note that it is not
worse than your buffering solution.

So have a look at attached patch. It's a bit different from the previous
one. It flush the libass buffer after a seek (to be sure that no subtitles
are left, even if we seek to a very close position where the current
subtitle still have to be displayed).
It avoids any possible duplicate subtitle, but when you seek back to a
previously played position you will still get instantaneously the relevant
subtitle. So there is no regression AFAICT.
Note that you can also verify this by not using libass. The basic, text
only, subtitle renderer has no kind of buffering and no duplicate detection,
but it still display subtitles correctly after a back seek.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ass_flush.diff
Type: text/x-patch
Size: 2940 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080909/b6ec3eff/attachment.bin>