[FFmpeg-devel] obseve PTS overflow when seeking

[Michael Niedermayer]

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

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
> ambitious.
> 
> > 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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120822/34932a3d/attachment.asc>