[Ffmpeg-cvslog] Re: r5468 - trunk/libavformat/mov.c

Michael Niedermayer michaelni
Tue Jun 20 01:27:23 CEST 2006


On Tue, Jun 20, 2006 at 12:14:10AM +0200, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Fri, Jun 16, 2006 at 09:52:05PM +0200, Baptiste COUDURIER wrote:
> >> Hi
> >>
> >> Michael Niedermayer wrote:
> >>>> [...]
> >>>> I would need the original timestamp to rescale it to other streams time
> >>>> base unit. I can still revert the scaling and scale it again but like I
> >>>> said it is not accurate/correct.
> >>> no, you rescale from one timebase to another, no AV_TIME_BASE should be
> >>> involved, av_rescale_q() does exactly that ...
> >>>
> >> While I'm working on fixing seek in ni mov files, I was wondering If I
> >> could rewrite the whole reading and seeking code using a sample table
> >> built from header. It will take some memory but all other tables will be
> >> freed after.
> >>
> >> What do you think about that idea ?
> > 
> > hmm you mean to convert the 500 tables in mov to a 
> > AVIndexEntry/av_add_index_entry/av_index_search_timestamp based table
> > iam definitly in favor of that idea ...
> > 
> > [...]
> Great to hear. Patched attached. Code can be disabled to restore old
> demuxer. I still need to handle edit lists.
> Test on all my samples, no regression and seek in non interleaved mov
> works now. What do you think about it ?

ive no objections to it ...

> It might be convenient to avoid pts computation. AVindexEntry would need
> to store dts and pts. Is it a good idea ?

iam not sure, maybe, maybe not ...

> Also I notice that a correspondance between AVPacket and AVIndexEntry
> might be usefull, for example to retrieve distance from keyframe and
> know how many packets need to be decoded to get to the specific timestamp.
> I also got a question. What should be the behaviour of the seek function
> ? If seeking is asked to be on a keyframe, sample returned might have a
> timestamp significantly different from requested timestamp.
> How seek must be done on other streams  ? To the returned sample
> timestamp ? Or to timestamp requested and let player correctly
> decodes/waits until the requested timestamp ?

well, for the AVSEEK_FLAG_BACKWARD case id say that if the user wants
timestamp t then we at least should seek so that the user will receive
a keyframe in every stream before or at t ...

for a forward seek on stream s id say that we should at least ensure that
the user gets a keyframe on every stream prior to the keyframe in s we

these are just the rules which seems to make most sense when thinking
about forward and backward seeking in a normal player, i doubt many demuxers
in ffmpeg actually conform to them ... and maybe iam missing something
and the rules actually arent ideal ...

also note that when we designed nut, rich and others suggested that seeking
should actually be based on a user specified set of streams instead of
streamless (stream_id == -1) or based on a single stream so that in case of
very few keyframes on one stream we wouldnt have "problems" with the
remaining streams


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is

More information about the ffmpeg-cvslog mailing list