[FFmpeg-devel] [RFC] Seeking API

Michael Niedermayer michaelni
Thu Jan 22 19:28:53 CET 2009


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?


> I believe the rationale is that is that it allows processing of 
> separate streams separately, even if the result is to render them at 
> the same time.

I have difficulty seeing in how far this is related to the seeking API.
I surely could understand if a user app wanted to pull a frame for
a specific stream out of the demuxer and surely could understand if
it wanted to receive packets with specific delays to cancel buffering
but i cannot see how one wanted to seek 2 streams to unneccesarily
different times.


> 
> For example, a player might want to buffer video or audio packets, or 
> pre-render them, and in the end it's the player that handles 
> synchronization.

of course


> Specifically it might want to seek at keyframes on each tracks, and 
> start playing the most in advance track, and unpause the other ones as 
> presentation times match.

Iam still not seeing how this is related to the seeking API.
If a demuxer supports outputting frames the way you describe it surely
could with the suggested API.
And if there was a API by which the user app could indicate from which
stream it wants the next packet and the demuxer supported that then
it surely could pull frames the way it prefers.


> 
> 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?


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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/481675f8/attachment.pgp>



More information about the ffmpeg-devel mailing list