[FFmpeg-devel] [RFC] Seeking API
Fri Jan 23 17:46:54 CET 2009
On Fri, Jan 23, 2009 at 05:07:52PM +0100, Fran?ois Revol wrote:
> > On Thu, Jan 22, 2009 at 06:24:59PM +0100, Fran?ois Revol wrote:
> > > > * 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)
> > >
> > > I agree to disagree.
> > > For once, the BeOS API does allow seeking individual tracks, so
> > > does
> > > Haiku.
> > BeOS is a video player?
> It has a Media Kit API that exposes demuxer and codec addons to native
> apps, allowing to build a media player from it, much like gstreamer in
> But since it's a generic API, not only for media players it puts the
i wouldnt call a API that cant interface to one of the more widely
available (de)muxer systems efficiently as generic
> seek(t0+0) read(track0)
> seek(t1+0) read(track1)
> seek(t0+1) read(track0)
> seek(t1+1) read(track1)
> Very efficient.
> but it was abysmally slow.
really? didnt you say it is "very efficient" ?
> > > It might also be wanted by a video editing app might want to
> > > extract
> > > specific frames to display them and audio data at specific point to
> > > show them, without having to close/reopen the file each time or
> > > care if
> > > the others tracks has been seeked too.
> > Do you speak about seeking or something else?
> yes, separate parts of the program (2 threads or not) asking for things
> out of order.
ffplay also has a few threads that ask for things out of order, namely the
video & audio decoders, it does not seem its causing a problem, also oddly
we dont need multiple demuxer instances for it, we dont even need a different
And id like to repeat that i agree that demuxers should be able to accept
a hint for which stream to pull a frame out when possible.
Its the per stream and mutually independant seeking you ask about that
i see no sense in. And to say it straight i dont give a damn what the beos
API does or if lavf can interface to it easily.
What i do care about are
1. APIs that are actually used (mplayer, xine, vlc, gstreamer, ...)
2. Actual use cases, that is a case where a user application independant
of poor design choices would want to seek streams differently.
Nothing in your reply even comes close to either of these ...
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel