[FFmpeg-devel] [RFC] Meaning of timestamp in seeking routines

[Ivan Schreter]

Hi,

until now, old seeking API didn't specify, whether the timestamp is PTS 
or DTS. Common sense dictates, it must be PTS, but I'm unsure, if this 
is really the case. At least MPEG-TS currently even disregards key 
frames and seeks as it likes.

According to older discussion regarding new seeking API, the seeking 
routine should take timestamp as PTS (i.e., at this PTS, the decoder 
must be synchronized in all active streams).

However, new seeking API is currently only emulated via old seeking API, 
which still has this ambiguity.

Some other programs, e.g., kdenlive nonlinear video editor, need to 
position the stream exactly by PTS. Current workaround is simply 
positioning the stream one second in the past, in the hope this is 
enough and decoder synchronizes in this one second. Apart from this 
being obviously broken (as one second might be too low), it is also CPU 
hog, since unnecessarily too many frames are decoded. Especially when 
working with AVCHD material, seek times are in seconds (which makes the 
video editor practically unusable).

My question now: How to address this, so at least for formats supporting 
exact PTS-based seek, this overhead can be reduced?

One straight-forward possibility is to introduce a flag, which will be 
set on AVInputFormat.flags, such as AVFMT_EXACTSEEK, to indicate exact 
seeking capability to the user of lavf. Then, such workarounds can be 
dropped for this format.

Opinions? Other suggestions?

If nobody objects, I'd implement the AVFMT_EXACTSEEK flag.

Thanks & regards,

Ivan