[FFmpeg-devel] obseve PTS overflow when seeking
donmoir at comcast.net
Wed Aug 22 00:55:12 CEST 2012
----- Original Message -----
From: "Wolfram Gloger" <wmglo at dent.med.uni-muenchen.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Tuesday, August 21, 2012 6:08 AM
Subject: Re: [FFmpeg-devel] obseve PTS overflow when seeking
> 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.
>> 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?
>> 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.
Michael says: "i think the sane solution for timestamp wraps and
to simply remove them."
Yes, please do !
o - It should be all packets have monotonic timestamps and consistent index
o - Ideally, it should be that all packets have and an actual display time
in them that is user friendly and these timestamps should correspond with
those in the index entries.
o - Currently, the official way to get an actual display timestamp, is to
call av_frame_get_best_effort_timestamp after a frame has been sucessfully
decoded. The problem with this is that avcodec_decode_video2 becomes the
bottleneck for frame dropping. That is, decoding the video can be much
slower than the actual display of a image. Displaying an image on todays
hardware is very quick. This can cause all kinds of problems and was a
problem with several players I tested. I have to jump thru hoops to overcome
this and leads to additional complexity.
o - I saw a flag somewhere to seek on PTS instead of DTS and just adds more
So it's not just about seeking. It should be about reducing difficulty using
More information about the ffmpeg-devel