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

[Michael Niedermayer]

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.


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


[...]
> > > Why don't you keep the ReadOrder field in demux packets and strip it in .ass 
> > > muxer?
> > 
> > That's not only .ass muxer. It's about all container muxers... And even if
> > you strip ReadOrder in all the muxers, when you try demuxing the result
> > you don't have any ReadOrder that you can use in libass.
> 
> A .ass muxer would use the ReadOrder field to order the lines in its
> output so the information would be kept. You seem to assume that other
> containers would not have the ReadOrder information; but do you have any
> reason for such an assumption except that you proposed a format without
> it yourself? Is there any container that actually specifies an ASS
> storage format without ReadOrder? For all I know every format that adds
> ASS support could have ReadOrder.

nut does not have ReadOrder.


> 
> > > It indeed improves user experience. For instance, if I did not catch a phrase, 
> > > I scroll 10 seconds back, and there is a rather high probability that I will 
> > > get to a point after the subtitle packet but still in the subtitle time frame.
> > 
> > I absolutely agree about this. This is a desirable feature to have.
> > But buffering is not the appropriate solution for this. That's the demuxer's
> > job to provide the relevant subtitle packets after a seek.
> 
> Implementing that at the demuxer level is more work. Not that I'm
> against you implementing it in the lavf demuxer, but it's still useful
> to have it in libass too.

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.
And demxuers that need it could set a flag indicating that they cannot
gurantee availablity of all subs after seeking so lavf would then buffer
subtitles and not only ass and not only for matroska.


> 
> > So I've just improved the demuxer, which now achieve this. Unfortunately,
> > it only works for indexed subtitle packets, and most matroska files don't
> > contain subtitle index. So this will generally only works for the parts
> > of file which were already played (and thus indexed). Note that it is not
> > worse than your buffering solution.
> > 
> > So have a look at attached patch. It's a bit different from the previous
> > one. It flush the libass buffer after a seek (to be sure that no subtitles
> > are left, even if we seek to a very close position where the current
> > subtitle still have to be displayed).
> 
> You're still using the packet format that keeps all timestamp
> information inside the codec data. That's wrong; so at least the
> mpcommon.c changes shouldn't be there.

libavformat will likely output CODEC_ID_SSA in a format that conforms
to the ASS/SSA specs. They include the start and stop 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.

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- 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/19986d97/attachment.pgp>