[FFmpeg-devel] [RFC] Meaning of timestamp in seeking routines
Wed Jul 8 23:13:49 CEST 2009
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
> 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
I've quickly checked short samples of following formats in tests/data as
working: avi (with various contained codecs), wmv, mp4, rm, dv, flv,
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.
More information about the ffmpeg-devel