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

[Uoti Urpala]

On Wed, 2008-09-10 at 17:26 +0200, Michael Niedermayer wrote:
> On Wed, Sep 10, 2008 at 03:24:33PM +0300, Uoti Urpala wrote:
> > On Wed, 2008-09-10 at 13:32 +0200, Michael Niedermayer wrote:
> > > The start display time of the subtitle should equal the packet pts,
> > > the duration equals the difference between the start and end times in the
> > > packet thus it really is a relative timestamp.
> > 
> > I'm not quite sure what you're trying to say here. Do you mean that you
> > want to have packets that contain absolute start time and absolute end
> > time, but that players should reinterpret the meaning of those fields to
> > specify only a duration calculated as the difference of the values? And
> > the absolute values might be completely wrong (so there would be lots of
> > ways to express the same duration)? If so I hope you reconsider that
> > idiocy...
> 
> It seems you do not understand things too well.

Based on your mail on ffmpeg-devel it seems that my above interpretation
was correct, and you really do want to use a format with such semantics
for SSA/ASS.

> > There is only one existing format for codec packets: the format Matroska
> > uses. The spec for ".ass" describes complete files, not codec packets.
> > You can not use that unchanged.
> 
> the .ass spec can be used as unchanged as any other codec spec can be used
> unchanged in a container, that is split in packets and store it.
> the change of removing specific information is not acceptable in nut.

.ass is no "codec". And as I already said, if you insist on interpreting
everything in terms of multimedia containers, you can view the
timestamps as parts of the ".ass container" which should not be included
when you want to mux the codec part into another container.

> odd but didnt you just argue that ReadOrder has to be preserved and here
> now you argue that the timestamps should be removed, coverted or otherwise
> butchered?
> This kind of argumentation is somewhat inconsistent, not that i mind.

Are you being stupid or misunderstanding deliberately? ReadOrder
information should be preserved and timing information should be
preserved. I have not argued in favor of anything that would lose
information. I want timing information to be stored in a form that makes
sense for demuxer packets, not "removed" (that would be absurd).
 
> > > nut does not have ReadOrder.
> > 
> > Just to make it gratuitously incompatible with Matroska? Or because you
> > were confused by the nonexistent ".ass codec format"? If you can't use
> > the Matroska format directly at least design a sane one (adding a
> > duration field to the Matroska format is an obvious choice, and allows
> > lossless conversion between the containers).
> 
> no, nut uses the format as described in the .ass spec. We will not mess
> with it in any way beyond the minimum needed to store it. Its the same with

You earlier said that you would NOT use the semantics given for lines in
the .ass spec. Instead of interpreting the first two fields as the start
and stop time you would interpret their difference as duration from the
start time given at demuxer level. If you do that you're not using
semantics compatible with lines in .ass files any more. Couldn't you
just as well specify that the first field should be interpreted as
duration and second as ReadOrder? That would give a more practical
result (no need to pointlessly calculate the difference), would allow
keeping ReadOrder, and would have no disadvantages over the "difference"
format (no decoder could interpret either format the same way as lines
from .ass files anyway, and the differences would be no harder to
handle).

> all other codecs as well. The insanity that some other containers do
> like buthering h.264 in mp4 and this LATM-ac3. No thank you, i do not want
> such "fixes", iam sure LATM and the other wrapers had some kind of arguments
> in their favor for some situations but overall such minor fixes end up
> creating a huge mess.

The Matroska format is the most "standard" codec version there is, not
any part taken from the spec for .ass files.

> > > One could of course convert the standard ASS packets in demux_lavf.c to the
> > > butchered mplayer-ass, i wouldnt object to that but its a little ridiculous.
> > 
> > There's no reason to call it "butchered". Your only reason for calling
> > it that seems to be your confusion about the ".ass spec format".
> 
> no not really, its more because the format is neither compliant .ass nor a
> clean and generic representation of a subtitle, its a butchered mix that
> ended up that way not by design but by sheer luck of which changes where
> done to the source.

What you call "compliant .ass" would not be a good subtitle codec syntax
(which ever version you mean here, the one with absolute timestamps or
your modified version that uses those fields to store a difference). I
think they way they created a codec from .ass was OK.

> > And
> > there would be nothing "ridiculous" about converting to a format that
> > keeps timing information in packet fields.
> 
> Its not ridiculous to extract this information, its also not ridiculous
> to convert subtitles to a easily useable format
> ridiculous is to
> 1. call that ass (it could be called mplayer-ass, matroska-ass but later

It's the only ASS codec format used in practice, so I don't think it's
that ridiculous. Not that I consider the exact terminology that
important.

> 2. do the job halfway or actually less than that, by just extracting the
>    start & end time, while leaving the actual text and intermediate times
>    in the packet

I'm not sure what you mean by "leaving the actual text". What would
qualify as "not leaving"? Turning it to pictures? I think that's a
completely separate issue from extracting timing information.

Leaving intermediate times in the packet could perhaps be called
"halfway", but I think that's an issue which doesn't have too much
practical significance.

> 3. doing it in the demuxer layer.

You don't actually need to do any conversion at the moment since in
practice all ASS/SSA subs come from Matroska which already stores them
in that format. If lavf becomes the only source of a different format
then I think making the conversion in the lavf demuxer wrapper is as
good a place as any. If there were multiple sources then creating a more
generic architecture could be worthwhile.