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

[Ivan Kalvachev]

On 9/13/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 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.


I'd like to this problem to be solved on purely technical merits.
However I'm not really into (de)muxing field and I would need quite an
effort to grok all of it.

So could somebody give nice explanation with _examples_ of both
methods and the differences associated in them.


So far from the thread I get the idea that the new method is removing
start_time from withing the packet and is replacing it with pts from
the packet where subtitle is located. That there is attempt to do the
same with the duration. That ReadOrder is equal to line number.