[FFmpeg-devel] obseve PTS overflow when seeking

[Don Moir]

----- 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.
> Agree?
>
>> 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
> 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.
>
> Regards,
> Wolfram.

Michael says: "i think the sane solution for timestamp wraps and 
discontinuities is
to simply remove them."

Yes, please do !

o - It should be all packets have monotonic timestamps and consistent index 
entries.

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

So it's not just about seeking. It should be about reducing difficulty using 
ffmpeg.

Don