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

[Michael Niedermayer]

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:
> > On Tue, Sep 09, 2008 at 06:39:58PM +0300, Uoti Urpala wrote:
> > > On Tue, 2008-09-09 at 16:32 +0200, Aurelien Jacobs wrote:
> > > > Here we have 2 different formats. One which can contain the subtitle display
> > > > duration through the mean of start time and end time (aka .ass format) and
> > > > one which can't store this information (aka matroska's ass format).
> > > 
> > > Actually we have only one existing muxed format: the Matroska one. What
> > > you called the ".ass" format and wanted to use internally in demuxer
> > > packets is only used in complete .ass files that are read as a unit. It
> > > is a bad choice as a demuxer packet format because it contains the start
> > > and end time as absolute timestamps (and you even tried to use it so
> > > that the timestamp inside the codec data overrode the demuxer packet
> > > pts).
> > 
> > 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.
Either the stored bitstream does not contain the timing but the container does
(like in matroska-ass) in that case really no ambiguity can exist, there are
just one set of timestamps and durations no matter how they are passed through
the player.

Or the timing info is just in the bitstream but not in the container like in
mpeg-ps/ts, again only one set of timestamps, no ambiguity.

So whats left is a container that can store them at container level and also
has them in the bitstream, but this case just doesnt match up to your comment
because the case you speak about, that is them mismatching will not go away.
If they do mismatch then they do mismatch. The player likely would use the
container level timestamps in that case and ignore the bitstream.


> 
> > > > Matroska is the only container which can store display duration by itself.
> > > > So matroska's ass format can't be used in any other container. So it just
> > > > can't be used as a kind of universal format.
> > > 
> > > Matroska's format is used in at least one type of file. Your proposed
> > > format is used in zero types of files. 
> > 
> > nut always uses unchanged codec packets whenever that is possible, 
> > that implicates unchanged .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.

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.


> 
> Alternatively you can view the ".ass spec" as describing codec AND
> container (it describes complete file structure after all), and the
> timestamps belong to the ".ass container" part, not the ".ass codec"
> part.
> 
> > 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
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.


> 
> > buffering subtitles does make sense, doing it in a specific subtitle decode,
> > that is libass does not make sense. A generic solution should be used, it
> > surely should be possible to do this in libavformat.
> 
> Any "generic" solution needs the timing data to be available. So you
> need to parse subtitle formats that keep it inside codec data. Again it
> makes sense to internally use formats that keep the information in
> demuxer packet fields.

Iam not against adding a AVPacket.display_duration as said several times.


[...]
> 
> > If mplayer decides not to support standard compliant SSA/ASS that would
> > be sad, but that is the decission of the mplayer developers/mplayer
> > leader or libass maitainer.
> 
> MPlayer does support "standard compliant SSA/ASS" in the sense of what
> is described in "the .ass spec". That means complete .ass files.
> "mplayer -sub subtitles.ass videofile" works.
> 

> MPlayer's internal demuxer packet format will keep timing information in
> packet fields, not inside codec data.

If you say it.


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


> 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
   wouldnt be true if the percent of duration changes where done as you
   proposed)
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
3. doing it in the demuxer layer.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080910/19bb8c31/attachment.pgp>