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

[Evgeniy Stepanov]

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. In fact, the second is much more popular. 
Saying that .ass is the standard way is not entirely correct, because most 
people define ASS standard by how Vobsub implements it and not by what is 
written in some .doc file.

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

[...]

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