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

[Uoti Urpala]

On Sat, 2008-09-13 at 21:14 +0200, Michael Niedermayer wrote:
> On Thu, Sep 11, 2008 at 02:01:38AM +0300, Uoti Urpala wrote:
> > On Thu, 2008-09-11 at 00:31 +0200, Aurelien Jacobs wrote:
> > > So virtually every muxer would need to rebuild .ass format (or anything
> > > containing display_duration) except matroska.
> > > On the other hand, when using standard .ass as an interchange format
> > > between muxers/demuxers/decoders, only matroska has to do some specific
> > > handling.
> > 
> > Currently the Matroska format can be muxed unmodified into at least one
> > container.
> 
> The matroska format can only be muxed into matroska, there is currently
> no other container in which it could be muxed
> 
> 
> > Any other format can be muxed into zero.
> 
> The .ass one can be muxed into most containers, it may not be supported
> by many players of course but thats something else. compare that to
> the matroska format which can NOT be stored as is.

It technically "can be muxed", with the theoretical possibility that
something could play it back. That doesn't make it either semantically
correct according to the containers's specs or working in practice.
You've been talking about the format as if it was universal and known to
require less conversion between containers. But that's not true
currently, and there is no strong reason to believe it would become true
in the future. You can still need conversion even if the format doesn't
directly require functionality missing from the container, and possibly
MORE conversion as you'll also need to convert everything muxed to/from
Matroska.

> Also a format following the .ass spec stored in .avi is much more
> likely to be supported than one which replaces 2 fields by duration
> and ReadOrder

Currently neither is supported, and I see no reason why people would be
more likely to implement the former.

"Following the .ass spec" is a somewhat misleading way to describe the
format, it's not like it would really be any more spec compliant even if
the packet format was copied from a line format in the spec.

> > Even if the other
> > containers do not use the Matroska format that doesn't mean they'd all
> > use whatever other format you pick. So there's no guarantee that any
> > other format would result in less rebuilding, and at the moment it would
> > certainly result in more. A format that keeps the values in demuxer
> > packet fields without duplicating them in bitstream is better for
> > program architecture.
> 
> if, if, if then ...

My point was exactly that your assumptions of "universality" are based
on hypothetical behavior of other containers and wishful thinking.

IF multiple other containers add support for SSA/ASS, IF they all use
the same format, THEN maybe it'll require less conversion...

> well normally codecs are stored with a minimum of reformatting
> There are various practical reasons why, mjpeg in avi really are jpegs
> one of course could remove parts of their header because they are
> redundantly storing the width & height.
> mpeg1, 2, 4, h264, ... also contain various fields that are redundant
> and that could be removed when they are stored in avi, asf, nut, mkv
> then mp3 stored the samplerate in its header, still this part of the
> header is not removed in containers that have their own samplerate
> in the header.

Those fields are not removed, but they are normally ignored. You don't
use codec-level timestamps even if the codec has them, and you don't
play mp3 at the samplerate stored inside the bitstream.

Let's assume there was a format like your proposed one, but stored in a
Matroska-like container with all timing information stored at the
container level. Changing the values in the bitstream timing fields
would never have any effect. Players would make sure to feed the packets
to decoders in a way that ensured they used the container timing, not
the bitstream values. If you muxed it to .ass files you'd have to
rewrite the time fields. Now a format like this would be similar to your
examples above, and I would have no strong objections to the format
itself; though it could not store the ReadOrder information, which would
be unfortunate in the current situation when most of the existing tracks
are in Matroska format and you couldn't mux them without losing
information.

It's when you start making the timing information inside the bitstream
semantically important that the format really becomes problematic.
Storing absolute timestamps in the codec bitstream is a bad idea. And if
you start reinterpreting the meaning of the fields, like only using the
difference from start to end as duration, then you could just as well
rewrite them to a different format.