[FFmpeg-devel] [RFC] Seeking API

[Michael Niedermayer]

On Thu, Jan 22, 2009 at 02:42:04PM -0800, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Thu, Jan 22, 2009 at 12:46:42PM -0800, Baptiste Coudurier wrote:
> >> Hi Michael,
> >>
> >> Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> Do we need a new API for seeking?
> >>> I think we do
> >>>
> >>> * currently seeking happens based on >=X or <=X this is not truely ideal
> >>>   for a normal player, for example at position 100sec and seeking 10sec
> >>>   forward we would prefer 109 over 200sec likely but not 99sec over 200sec
> >>> * seeking in relation to a single specific stream makes little sense, rather
> >>>   seeking should happen relative to the set of streams that is presented
> >>>   to the user (= the ones not disabled by AVStream.discard)
> >>>
> >>> Are there other issues? requirements?
> > 
> >> Yes, I'd like a new AVSEEK_FLAG_FRAMENUM for containers supporting it
> >> (mov/mp4/r3d)
> > 
> > This also needs a stream_index  and could be done by the user app with
> > ts= st.index_entries[frame_num].timestamp;
> 
> True, but aren't we defining an API to simplify _usage_ ?

yes but wont many programs that seek by frame num want/mess with AVIndex
anyway?


> 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);

and this still skiped one issue, namely that AVSEEK_FLAG_FRAME will with this
API not seek to the wanted frame unless the active set selected by
AVStream.discard is just that single stream.
We can add yet another flag to override this of course ...


> 
> >> Not sure if this is much related to seeking:
> >> I'd like containers to export the AVIndex feature usage and add pts to
> >> AVIndexEntry, also a way to generate the full AVIndexEntry and have the
> >> possibility to export it as file to be loaded later.
> >>
> > 
> >> Also user needs to specify if he wants to seek by dts or pts and
> >> therefore what timestamp value refers to.
> > 
> > Is there any use case in which the user wants to seek by dts?
> 
> Not sure, currently, mpeg ps demuxer add dts to index entries, same for mov.
> So either you add pts to index entries but with reordering, binary
> search is difficult.

seeking in many demuxers will need to be reworked if we want to improve
things.
also dts&pts in mpeg-ps only have to be stored once every 0.5 sec or so
which is a bigger issue than reordering.


> Or you add dts and export first_dts value, so it is possible to seek to
> first dts.
> 

> In all case "timestamp" value needs clarification.

all timestamps where intended to be presentation timestamps
i felt that:
    "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."
was makeing that clear
do you have some suggestion to improve this?
i could rename ts to pts ...


> 
> Also "pos" needs clarification, I propose to use pos as position which
> enable byte seeking to and then call av_read_frame, for containers
> supporting byte seeking (mpeg ps, mpeg ts), with rules like next
> containing access unit.

patch welcome


> 
> Containers should export the information when supporting byte seeking
> (mov/mp4 does not).

yes, pkt.pos should be required when byte seeking is supported.
doc patch welcome as well

( i think little harm is done if such doc stuff is commited already before
  the actual implementation, would simplify team work )

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20090123/a529bfc7/attachment.pgp>