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

[Michael Niedermayer]

On Tue, Jul 07, 2009 at 11:59:29PM +0200, Ivan Schreter wrote:
> Hi,
>
> 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090708/7a7c7192/attachment.pgp>