[FFmpeg-devel] [RFC] Seeking API

[Michael Niedermayer]

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 
> GNU/Linux.
> 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.

ROTFL

[...]

> 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
seeking API.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090123/336419c2/attachment.pgp>