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

[Ivan Kalvachev]

On 9/10/08, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.

Soft telecine is implemented by the combined use of repeat_first_field
and top_field_first in progressive picture. It only increase the
duration(1/fps) by 50%.
There is no way to specify duration.
Handling of subtitles is very different (in DVB and DVD).