[FFmpeg-devel] [RFC] Meaning of timestamp in seeking routines
Wed Jul 8 03:46:23 CEST 2009
On Tue, Jul 07, 2009 at 11:59:29PM +0200, Ivan Schreter wrote:
> until now, old seeking API didn't specify, whether the timestamp is PTS or
> DTS. Common sense dictates, it must be PTS,
yes, its supposed to 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?
all demuxers should be fixed ...
marking which are fixed is a little odd but chould be done too if its
clear that the flag will be droped again later
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel