[FFmpeg-devel] obseve PTS overflow when seeking
michaelni at gmx.at
Wed Aug 22 01:55:39 CEST 2012
On Tue, Aug 21, 2012 at 12:08:08PM +0200, Wolfram Gloger wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> > mpegts calls av_add_index_entry() directly
> Hrmpf, you're right. But that is marked FIXME as it unconditionally
> adds keyframe entries where TS really has no such markers. I actually
> don't see the point of this unless for some basic timestamp caching.
> So I think either that call should be removed from mpegts.c (my
> preference), or mpegts should advertise the AVFMT_GENERIC_INDEX flag.
removing the call would make the seek code significantly slower,
this is especially an issue with a slow transport protocol
> > the index would become present during the first seek for mpegts
> > so this would stop working for subsequent seeks
> Ok how about taking the pragmatic approach and at the end of
> ff_gen_search, _if_ a wraparound was detected, simply flush the index?
> Also, for all formats with wrapping timestamps, declare the index only
> 'locally defined' (it obviously makes no sense otherwise anyway).
> > Its very possible that it might work out with ffmpeg_opt.c but thats
> > not the only application that uses libavformat
> > seeking ~5 seconds before starttime (thats what you will likely get
> > when pressing the left arrow in some players at the begin) should not
> > seek to the end of the file
> I agree but the players should handle that. ffmpeg API should somehow
> _allow_ seeking to the end of the file, no?
one can seek to starttime + duration or even something like INT64_MAX
> > yes but its a half-solution, it may work with a single timestamp
> > wrap, it wont help with general discontinuities.
> True. ffmpeg.c handles general discontinuities (or tries to).
> Pushing that into libavformat may be desirable but is much more
> > also i suspect the correction would be needed at more places,
> > especially the seeking code and index would need changes too
> Overflow detect could flush the index, too. After all, timestamp wrap
> is a rare event and therefore performance is not an issue.
If you have a file with a wrap then it happens every time
you seek in that file
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel