[FFmpeg-devel] [RFC] Seeking API

[Michael Niedermayer]

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?

Below is a suggestion for a new API, ive not thought much about how
implementable this is for demuxers yet though.

/**
 * 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).
 * else all timestamps are in 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 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, int64_t min_ts, int64_t ts, int64_t max_ts, int flags);

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/20090122/eb6b4728/attachment.pgp>