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

[Uoti Urpala]

On Thu, 2008-09-18 at 00:18 +0200, Michael Niedermayer wrote:
> On Mon, Sep 15, 2008 at 11:32:59PM +0300, Uoti Urpala wrote:
> > On Mon, 2008-09-15 at 16:52 +0300, Ivan Kalvachev wrote:
> > > So the stuff I don't understand.
> > > 
> > > 1. Is "Block's timecode" the only PTS that this packet have?
> > 
> > Yes.
> 
> No, it is not and you know that as you admited already that there are
> other time related fields that are not removed by matrska-ass
> ill quote the spec for ivan and others:

I think you misinterpret Ivan's question; at least you interpret it
differently from how I did. I think he meant the properties of the
Matroska format. "Block's timecode" is the (only) PTS value a packet in
Matroska has, and is what a demuxer will place in the pts field of a
packet. It is not the only timing-related information stored for a
packet - and that is obvious, as BlockDuration was listed right next to
it in Ivan's mail. So your interpretation of the question (asking
whether there can be any other timing information corresponding to a
packet) doesn't make much sense, as the answer is obvious.

> I really honestly think, uoti you are going a little too far with this
> missinformation compaign.

"Misinformation campaign"? What exactly are you calling
"misinformation"? Even if you honestly misunderstood the above case that
alone doesn't excuse your claims of a "campaign".

> Matroska picks 2 of the timestamp fields and removes them from the ass
> lines, the other timestamps are not changed or removed, this still results
> in a codec & container timestamp mix, that surely will not become any
> less problematic if your idioitc suggestion of changing the "packet"

It's spelled "idiotic", idiot.

> timestamp without fixing the bitstream is applied.

Timing inside the packet is rather rare. So even duration changes are
likely to work (and not fail too bad even in some cases where timing
inside packets is used). But the more important point is that changing
the starting timestamp WILL work. The Matroska format does not have any
absolute timestamps inside the packet.

>  That is no matter
> which of the suggested systems is used, in all cases do the ass packets
> need to be edited if timestamps change.

False. Is this really an honest mistake or are you intentionally lying?
You should know better. Matroska packets never need to be edited when
changing the starting time. With most subtitles editing duration will
also work from OK to perfect.

> aurel wants to move the 2 timestamps that matroska removes from standard
> .ass back where the .ass spec says they should be.

Where the spec says they should be in .ass files.

Having packets with unused timestamps left from .ass files would not be
so bad. Trying to _use_ absolute timestamps from inside the bitstream
for the timing of the packets is stupid.

> The format aurel wants is described in the specification of .ass files,
> it is not his format. Also exactly this format is used in nut.

You want to use it for nut. Has anyone else agreed? And is it used in
reality?

> convertion between .ass and .mkv will need convertion of the format
> whereever it is done, doing it in the mkv demuxer means nut and other
> formats like avi could use the packets directly.

No it doesn't automatically mean the same packets could be used. Only IF
those containers actually pick the same format. And if you pick the
stupid format they have good reason not to use the same one. Also for
good SSA/ASS support you need to support embedded fonts too. So you need
more than just the subtitle format for a container to have proper
support at all.

> > > 3. If "Block's timecode" is stored in AVPacket.pts and "Block's duration" is stored in AVPacket.convergence_duration, doesn't that mean we have everything we need for muxing?
> > 
> > Aurelien's use of convergence_duration was mistaken and he should have
> > used another field (probably waited for a patch adding display_duration
> > to be applied); but yes, all the information should be available in the
> > packet fields, and having it in the bitstream is completely redundant
> > for an internal format. 
> 
> So you propose that a .ass demuxer removes these fields?
> The fact that .ass and .mkv use a different format leaves no choice
> either one converts or the internal format is ambigous.
> Now if one must convert why should that be the .ass and not mkv demuxer?

Because the Matroska format is the one that is better suited for
packets. The Matroska format allows keeping ReadOrder information (which
a .ass muxer can keep when writing a complete file, but to store it in
individual packets needs the per-packet field). It does not require
bitstream conversion when changing starting timestamps (even if there
somehow appeared multiple containers with ".ass format" packets it could
still require more conversions if there's code that changes timestamps).
The ".ass format" requires at least parsing anyway to get the display
duration, and when used in a container with its own pts, to resolve
conflicts between the redundant information in the packet and the
container-level pts. If you call a function to do that parsing it can do
conversion just as well.

If you use an internal format without ReadOrder then users of your
Matroska demuxer cannot access information that was in the original
packets, and you cannot easily remux Matroska files without losing
information. IMO those alone are much more of a practical problem than
some "convert_packet_to_format_xyz(pkt);" lines in some (de)muxers.