[FFmpeg-devel] Seeking api and gsoc

[Michael Chinen]

On Mon, Apr 5, 2010 at 6:15 PM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Mon, Apr 05, 2010 at 12:49:07AM +0200, Michael Chinen wrote:
> > Hello,
> >
> > I may be interested in participating in GSoC 2010 with ffmpeg.  I hope
> this
> > is the right place to start talking.
> >
> > I have noticed the seeking api project idea, and also that it seems to
> exist
> > from a previous year, unfinished.  I could not find info on what the
> state
> > is.  Is there some info page about this?
> >
> > I would personally be interested in making sample-accurate seeking
> available
> > for audio.  I realize this is not exactly what the seeking api project
> is,
> > so I wanted to ask what would be acceptable in terms of a project.
>  Besides
> > the basic index-building implementation, I would also be interested in
> > implementing a functionality for building a 'probable' index as the file
> is
> > decoded, and an api that lets the client see how likely it is that the
> guess
> > will be valid.  For certain audio files, it may not be possible to
> quickly
> > build an index, but it may be possible to make guesses with increasing
> > certainty while the file is decoded from the start position, (for
> example,
> > one might say the file is seekable on a fixed size framerate by noticing
> the
> > frame size doesn't change after the first 10 seconds and we are at
> > approximately the right place in the file.)  These are my initial
> thoughts
> > about a GSoC project and I would like to hear how they sound to the
> ffmpeg
> > community.  My scope of personal interest is for audio, but if audio
> seeking
> > alone is not enough for a project, I would submit a project that also
> > handles video; however, I think focusing on audio may be ambitious enough
> > giving the amount of testing required for the various formats out there.
>
> audio seeking alone certainly is not ok as project.
>
also exact seeking in pure raw audio only files like mp3 should in theory
> alraedy work. That is by linear reading ahead and keeping an index for
> the past.
>
Thank you for the reply.

What you say about theory is certainly true, but I am suggesting that in
real time practice it is subobtimal.  Seeking functions should be fast as
possible, as soon as possible.  It is a bad case if you have to read the
file up to the point you wish to seek to.  If I'm not misunderstanding your
method, it will not be fast enough for real time usage until a first pass is
made.

Consider the case when you have a medium or large audio file and want to
seek into the future, near the middle or end of the file.  This linear
reading from start to end will require too much time, and the user will have
to wait this long to effect a seek.  For certain file types, like wav or
flac, we can simply use something like fseek to get to the right place using
the fixed frame size.  Other types require more robust probabilistic/trial
and error methods like the ones I suggested in my initial email.

It's true that the client could still do this, so maybe that's the real
issue here.  However, it would be pretty hard work to do it right, and since
its a general feature, I thought it might warrant itself as a gsoc project.
If the consensus is that it isn't enough work then I would appreciate input
on how to expand the project appropriately.  Also, if no devs think its a
good idea, I will of course do significant rethinking.

My initial thought was that the feature, with proper testing, refactoring,
documentation, and cleanup would be a sizable amount of work, and that
submitting a more ambitious project runs the risk of a result that had the
feature implemented, but lacking in the testing/refactoring/docs area,
making the feature not shiny enough for comfortable deployment.  In this
case I would be happy to continue development after gsoc, but I thought that
from the administrative side safe, well-polished gsoc results are preferred
to those which risk becoming almost-there projects that require cleanup or
cause destabilization.

Michael