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

[Ivan Schreter]

Michael Niedermayer wrote:
> On Tue, Jul 07, 2009 at 11:59:29PM +0200, Ivan Schreter wrote:
>   
>> [...]
>> 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?
>>     
>
> all demuxers should be fixed ...
>   
100% agree. But I don't know if it is realistic in medium term to get 
it, except if there are in reality only very few demuxers, which don't 
work correctly.

> marking which are fixed is a little odd but chould be done too if its
> clear that the flag will be droped again later
>   
That's why I'm asking for other suggestions. Dropping the flag later 
will effectively mean API change, so it might be problematic.

*@demuxer maintainers:* are you sure seeking in your demuxer works 
correctly (PTS-exact)?

I've quickly checked short samples of following formats in tests/data as 
working: avi (with various contained codecs), wmv, mp4, rm, dv, flv, 
mov, nut.

And these as not working due to various reasons: mpg, mkv, mxf, sgi.

I've fixed mpeg-ts, which I intend to commit after review.

I suppose, if MPEG video format is fixed, then we don't need to have 
such a flag - simply assume in the editor the seeking works.

Regards,

Ivan