[FFmpeg-devel] Seeking api and gsoc

[Baptiste Coudurier]

Hi,

On 04/05/2010 04:13 PM, 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.
>
> 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.

I agree with Michael Niedermayer that audio only is not enough.
However I'm very interested in seeking accuracy.

I'm thinking of index building.
- libavformat API would provide avformat_build_index, 
avformat_load_index, avformat_save_index.

This would create an AVIndex (will need extension to contain pts and 
maybe more information like data offset within the PES or TS packet for 
MPEG PS/TS files) array and helpers functions to deal with it.

Extending demuxers (AVInputFormat) to provide build_index functions 
could be one solution.

The process should be fast obviously.

Support for MPEG TS/PS files is a priority (other formats like mkv and 
mp4 have index and should be easier to support later, but should be 
taken into consideration) and MP3.

As for sample accuracy seeking, are you talking about compressed data as 
well ? It should be a matter of gathering frame size and timestamps then 
offset the decoded data.

Suggestions are welcome and you are free to propose a good system of 
course :)

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org