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

[Michael Niedermayer]

On Sun, Sep 07, 2008 at 06:23:11PM +0300, Uoti Urpala wrote:
> On Sun, 2008-09-07 at 15:33 +0200, Aurelien Jacobs wrote:
> > Uoti Urpala wrote:
> > > > > But it SHOULD get out of the container. That is information stored in
> > > > > the file, and the application using the demuxer should be able to access
> > > > > it. If it can't that is a deficiency in the demuxer.
> > > > 
> > > > Why ???
> > > > There are many more information read by the demuxer that are never
> > > > exported to the outside world. Because many information are dedicated
> > > > to the demuxer itself, so that it can properly extract or relate other
> > > > data.
> > > > And ReadOrder is exactly one of those information dedicated to the
> > > > demuxer itself. Its goal is to allow the demuxer to re-order sub
> > > > packets in their original order. This is only useful for specific
> > > > demuxers aiming at extracting a bit-exact copy of the original ass
> > > > file.
> > > 
> > > Why do you think the *demuxer* would have to be a specific one created
> > > for that task? Why can an application with that goal not be using the
> > > lavf demuxer? Any reason except the lavf demuxer currently being too
> > > limited for such tasks?
> > 
> > Well, if you think it can be useful to anyone, it could be implemented
> > in the lavf demuxer. It would simply have to ensure that the packets
> > it output are properly ordered.
> 
> Are you talking about changing the order of output packets instead of
> giving the value of the ReadOrder field? I don't think that would work.
> 
> > I simply have never seen a use case for this.
> 
> I have compared .ass files extracted from an .mkv file with versions
> that didn't go through muxing.
> 
> And even if you thought lavf users wouldn't need it, dropping the
> information when you remux mkv->mkv is bad unless you can be sure nobody
> anywhere has a use for it (which I think they do).

If readorder contains information that is usefull for a realistic case
Then we can try to find a way to export it.
Though that requires some realistic use case to be found first.


> 
> > Most containers don't have a duration field to specify the display
> > duration of each subtitle packets. This duration have to be part
> > of the packet data itself so that it can be muxed in any container.
> 
> Those containers do not have subtitle support as good as Matroska. I

Considering that matroska has to buffer _all_ subtitles somewhere
be that now the decoder, demuxer or a intermediate layer so they
are more often correctly displayed after seeking.
I really must say that iam not aware of a single other container that
has such limitation. (not counting some subs hacked into avi)
mov certainly does not, it has a index that provides the needed information
about which subtitles are needed after seeking.
Nut has back pointers and convergence duration that achives the same.
iam not sure what mpeg-ps/ts does but i suspect it either limits the
display_duration or requires them to be repeated at gop boundaries.



> think your proposal to move all timing information to the codec level to
> avoid the container limitations is problematic. It is the opposite of
> what is done with audio and video. Audio has an implicit duration based

mpeg2 video does have a duration field in its bitstream, quite well known
for things like telecine.
vorbis packets also contain their duration.
...


[...]

> IMO a better solution would be to keep timing information in
> demuxer-level fields and out of codec data. Conversion functions can be
> provided for the case where you need to push the timing information to
> the codec level because the container has no better place for it.

There are 2 big problems here
1. its all based on your false assumtation that this information is not
   in codec packets.
2. its based on the assumtion that there are just start and end time.
   Iam not sure if there really is no subtitle format that cannot apply
   some effects at intermediat times, and these times would be in the
   codec bitstream, it would be rater messy to attempt to move this to
   demuxer packets.

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/ae2a322c/attachment.pgp>