[FFmpeg-devel] Seeking api and gsoc

[Michael Niedermayer]

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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/20100406/c2e8a7c8/attachment.pgp>