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

[Uoti Urpala]

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

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

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

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

> libavformat will likely output CODEC_ID_SSA in a format that conforms
> to the ASS/SSA specs. They include the start and stop times.

Again: you cannot output packets in "the .ass spec format", unless you
output a complete file at once. So far nobody has been stupid enough to
try using absolute timestamps in codec packets because they make sense
for a complete file. Please don't be the first.

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

> 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". And
there would be nothing "ridiculous" about converting to a format that
keeps timing information in packet fields.