[FFmpeg-devel] [RFC] Seeking API

[Michael Niedermayer]

On Tue, Jan 27, 2009 at 04:12:15PM -0800, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Thu, Jan 22, 2009 at 04:10:53PM -0800, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> > [...]
> >>>> Also we could handle FRAMENUM | NEXT_KEYFRAME or PREV_KEYFRAME with the
> >>>> help of min_distance value, which becomes complicated for the user.
> >>>>
> >>>> Needing a stream_index is ok if documented IMHO.
> >>> I dont mind adding FRAMENUM & stream_index but this will make the API
> >>> more complex. see:
> >>>
> >>> /**
> >>>  * Seek to timestamp ts.
> >>>  * Seeking will be done so that the point from which all active streams
> >>>  * can be presented successfully will be closest to ts and within min/max_ts.
> >>>  *
> >>>  * if flags contain AVSEEK_FLAG_BYTE then all timestamps are in byte and
> >>>  * are the file position (this may not be supported by all demuxers).
> >>>  * if flags contain AVSEEK_FLAG_FRAME then all timestamps are in frames
> >>>  * in the stream with stream_index (this may not be supported by all demuxers).
> >>>  * else all timestamps are in units of the stream selected by stream_index or
> >>>  * if its -1 AV_TIME_BASE units.
> >>>  * if flags contain AVSEEK_FLAG_ANY then non keyframes are treated as
> >>>  * keyframes (this may not be supported by all demuxers).
> >>>  *
> >>>  * @param stream_index index of the stream which is used as timebase reference.
> >>>  * @param min_ts smallest acceptable timestamp
> >>>  * @param ts target timestamp
> >>>  * @param max_ts largest acceptable timestamp
> >>>  * @param flags flags
> >>>  * @returns >=0 on success, error code otherwise
> >>>  */
> >>> int av_seek_frame2(AVFormatContext *s, int stream_index, int64_t min_ts, int64_t ts, int64_t max_ts, int flags);
> >> I like it, are min/max_ts allowed to be 0/-1/AV_NOPTS_VALUE ? What
> >> happens in this case ? No limits ?
> > 
> > i see no immedeate problem with allowing the full signed 64bit range
> > the no limit case would then be the INT64_MIN/MAX
> 
> Humm, according to libavformat users, treating negative timestamps as 0
> really improve usability, so should we enforce uint64_t ?

this is because of the crappy API we have now
here is an example:
we are at ts=5, the user wants to seek back by 100
our seek target clearly is -95 but which direction should we pick?
if we pick backward the seek can fail, if we pick forward we might end
up _after_ the target timestamp (that is for example at ts=10.

the new API as suggested by me has min/max acceptable timestamps so the
user can ask for ts=-95 max_ts=4 (gurateeing no mistaken forward seek)
min_ts= INT64_MIN, its the demuxers problem to find the timestamp closest
to -95 that is before ts=4 ...


[...]
> > "the stream you use as timebase reference will be considerd active even if
> > it is marked as not active"
> > A flag is IMHO significantly cleaner than such sideeffects, because
> > writing FLAG_ONLY_SPECIFIED_STREAM_ACTIVE makes it explict what is intended
> 
> Default behaviour should be the most intuitive and used, so
> AVSEEK_FLAG_IGNORE_DISCARDED_STREAMS ? or
> AVSEEK_FLAG_USE/CONSIDER_DISCARDED_STREAMS ?

i think you misunderstand the problem, its not about considering discarded
stream, its about not considering any streams except one.
Anyway this is minor and can be added later or not depending on furthetr
discussions.

[...]

> I suddently have an idea, should we call the new function
> "avformat_seek_file", "avformat_seek" ?
> 
> So plan seems to be:
> 

> - add avformat_seek_file proto

will commit this in a moment so we have some basis to work on.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20090208/4caec57b/attachment.pgp>