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

[Michael Niedermayer]

On Fri, Sep 05, 2008 at 04:36:58PM +0200, Aurelien Jacobs wrote:
> 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 ?

You dont know that, but the demuxer may know it from other information.
(in nut that would be the index or back pointers)

The convergence_duration tells you that when you do start decoding at a
keyframe (subtitle video or otherwise) that the output from the decoder
will not be correct for convergence_duration.
That way a player can avoid displaying (and possibly even decoding) video
while the subtitles arent fully available. The subtitle display_durations
would due to possible overlappings not be sufficient for this.

and as i said alternative solutions are welcome, iam in no way
particularely attached to this design if someone knows a simpler one ...



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

If the demuxer doesnt know it it can set it to AV_NOPTS_VALUE, the player
then would have to guess how far back it has to look for a subtitle or it
could just start decoding and hoping nothing too important is missing for
too long.


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

if we assume that there are no previous packets, that is A is the first
then A has a convergence_duration of 0 for all 3
and B has -2,2,6 for the 3 (the first could also be 0 instead of -2 for
sake of simplicity)


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

yes, though it is always much better if the codec bitstream does contain
this information because if not X->avi/asf/mpeg-ps/ts->Y will loose it.

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/ffmpeg-cvslog/attachments/20080905/9ec3c9a1/attachment.pgp>