[FFmpeg-devel] Seeking api and gsoc

[Michael Chinen]

On Tue, Apr 6, 2010 at 2:31 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Tue, Apr 06, 2010 at 01:13:01AM +0200, Michael Chinen wrote:
> > 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.
>
> If a file is constant bitrate seeking is fast, if its not and it has
> timestamps or an index seeking is fast too.
> If a file is variable bitrate and has no index nor timestamps seeking
> is slow or inaccurate. I belive that in this last case its ultimately
> the user applications decission if it wants it fast or accurate.
>
> The way i understand you, is that the project you suggest would be
> about guessing which are constant bitrate files.
> Iam sure our code is pretty bad in identifying constant bitrate and
> using this during seeking currently. And its surely welcome to improve
> this but thats not a project worth 5kusd.
> Or to say it differently id very happily implement that for half and
> that still would be overpaied
> the only thing one needs to do is to seek to 5 random spots in the file
> where
> we expect packet starts if it where cbr and if we find packet starts there
> then we can assume its cbr and use the appropriate fast seeking by cbr
>
I think there has been a misunderstanding.  I should make it clear that
besides simply determining cbr/vbr, I wanted to also implement both fast and
sure seeking options to work with all types, including vbr.  I gave the cbr
examples because they are an easy example.  In the case of mp3 for both with
TOC and without, and when the 'fast' methods are used, we can also express
uncertainty in some curve that maps probability to number of samples away
from the target that the seeked frame could be.  The thing is for vbr using
stuff like TOC or index is different for each format, so there is some work
there to go through all vbr formats.  There may also be trends for each vbr
format like mp3 that can be taken advantage of to get a narrower estimate on
uncertainty.  Clients could then say they'd like to know the seek error
range at 95% certainty.

I'm not interested in talking about how much a project would be worth, but I
want to have the opportunity to contribute a solid summer's work to a good
project and have rent and food problems solved during that period.  I
understand that there is concern about some gsoc students just doing it for
the money, doing the minimum amount of work to get their mentors to press
the 'pass' button and collect their midterm payment.  I think it is a valid
concern, and find this behavior myself very troubling (and confusing, since
a summer internship pays much more!)  Still, I would appreciate it if the
price evaluations would stay on the administrative side.
As I said, I'm open to your suggestions, and would like to incorporate my
motivations as tightly as possible.

Or to say it differently, instead of saying I need a project worth 3000
dollars more, tell me how I can expand my current idea to integrate with
other ideas, or tell me that it isn't something that the group wants.  I was
hoping to present my motivations and ideas to see if and how they resonate
with the ffmpeg community, and then together come up with a proposal that
sounds good to the both of us.    Your comments have been good for showing
me where I need clarify.  I appreciate Baptiste's suggestions about how to
focus on certain priorities and formats.  I'm still hopeful.  Keep em
coming.


Michael