[FFmpeg-devel] [PATCH] First shot at AVCHD seeking via new seeking API

[Ivan Schreter]

Michael Niedermayer wrote:
> On Sat, Sep 05, 2009 at 09:52:49PM +0200, Ivan Schreter wrote:
>   
>> Hi Michael,
>>
>> Michael Niedermayer wrote:
>>     
>>> On Sun, Aug 30, 2009 at 10:11:21AM +0200, Ivan Schreter wrote:
>>> [...]
>>>   
>>>       
>>>> BTW, I found out that pure seeking routine time can be reduced about 
>>>> factor 3 for full-HD AVCHD files, when using higher initial step size 
>>>> (32KB) for back-off. I will investigate how this step size could be 
>>>> automagically determined optimally.
>>>>     
>>>>         
>>> the initial size should be at least ByteIOContext.buffer_size which is 
>>> 32kb
>>> by default
>>>
>>>   
>>>       
>> So I suppose something like this should be more suitable, right?
>>
>> Index: libavformat/seek.c
>> ===================================================================
>> --- libavformat/seek.c  (revision 19773)
>> +++ libavformat/seek.c  (working copy)
>> @@ -342,8 +342,10 @@
>>
>>     // Find keyframes in all active streams with timestamp/position just 
>> before
>>     // and just after requested timestamp/position.
>> -    step = 1024;
>> -    curpos = pos;
>> +    step = 32768;
>>     
>
> i think it should be ByteIOContext.buffer_size, not 32768, yes i meant
> that litterally
>   

So like this, then:

Index: libavformat/seek.c
===================================================================
--- libavformat/seek.c  (revision 19788)
+++ libavformat/seek.c  (working copy)
@@ -342,8 +342,8 @@

     // Find keyframes in all active streams with timestamp/position 
just before
     // and just after requested timestamp/position.
-    step = 1024;
-    curpos = pos;
+    step = s->pb->buffer_size;
+    curpos = FFMAX(pos - step / 2, 0);
     for (;;) {
         url_fseek(s->pb, curpos, SEEK_SET);
         search_hi_lo_keyframes(s,

I also addressed the comment from Reimar regarding FFMAX.

I suppose, you are OK with me committing incremental improvements on 
seek.[ch] to svn, now that it's disabled?

I also would like to commit the new read_seek2 and read_seek routines in 
lavf/mpeg.c (basically same as in mpegts), similarly disabled as now in 
lavf/mpegts.c, so interested people can test. Would that be OK?


>
>   
>> +    curpos = pos - step / 2;
>> +    if (curpos < 0)
>> +        curpos = 0;
>>     for (;;) {
>>         url_fseek(s->pb, curpos, SEEK_SET);
>>         search_hi_lo_keyframes(s,
>>
>> Interestingly, for AVCHD files with high resolution, starting with yet 
>> higher initial step (on the order of 128-256 KB) produces even better 
>> performance. I suppose, this depends on key frame distance in the file and 
>> frame sizes. I didn't find a good metrics yet for determining the best 
>> backoff initial step size. But this can be addressed later as performance 
>> optimization.
>>     
>
> yes, the whole also depends on hd seek & throughput timings, if your kernel
> prereads, ...
> some heuristic like keeping track of how often on average the step is doubled
> and starting from a little below that likely could help but as you say thats
> for fututre optimizations
>
>   

Good idea with the tracking of average backoff step. I'll try it on 
occassion.

Regards,

Ivan