[FFmpeg-cvslog] r15206 - in trunk/libavformat: matroskadec.c matroskaenc.c

[Aurelien Jacobs]

Michael Niedermayer wrote:

> On Fri, Sep 05, 2008 at 12:47:06PM +0300, Uoti Urpala wrote:
> > On Fri, 2008-09-05 at 03:10 +0200, Michael Niedermayer wrote:
> > > convergence_duration of 10 means that in 10 timebase units from now the
> > > output of the decoder when started with this frame will match what it
> > > would have been when started from the very first frame.
> > > 
> > > that is if 5 minutes ago there was a subtitle that has a display duration
> > > of 7 min then convergence_duration could be 2min for the current
> > > subtitle packet because if we stat decoding now we will be missing this
> > > subtitle and thus output will differ for 2 min. Of course if this past

I understand what you're aiming at, but I don't understand how this could
work. If I seek in the file, and read a subtitle packet with
convergence_duration = 2min, how do I know that I have to seek back 5min
to find the first subtitle packet which must be displayed at this point ?
And how is the demuxer supposed to generate this 2min value, if it don't
know there is a relevant subtitle packet starting 5min ago ?

I honestly have no idea how this convergence_duration could be useful
regarding subtitles.

To be sure I understand correctly, could you please tel me the the value
of convergence_duration for subtitles packet A and B in the following
situations ?

case 1:
  A: start=2 end=4
  B: start=6 end=10

case 2:
  A: start=2 end=6
  B: start=4 end=10

case 3:
  A: start=2 end=10
  B: start=4 end=6

> > BTW how do you expect this to work in practice for subtitles (I assume
> > you do expect it could work in some case since subtitles are explicitly
> > mentioned in the documentation)? This is a field in a demuxer packet,
> > but typically there is no packet right after a seek where you could set
> > it. 
> 
> > Do you expect the demuxer to generate a dummy packet whose only
> > meaningful information is the value of this field? 
> 
> no, the idea was more to preserve this information when remuxing
> maybe this isnt the best way, if you have a better idea we surely
> can remove this field again
> Similar to this field we also could add a display duration that would
> then match the maroska-ass durations.

Then I guess I will propose a patch to add a display_duration field.

> Without such fields muxers would have to extract this information from
> the codec specific bitstream

When the codec bitstream is able to contains this information, which is
not always the case.

Aurel