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

Michael Niedermayer michaelni
Sun Sep 6 02:21:41 CEST 2009


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


> +    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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20090906/64ab6503/attachment.pgp>



More information about the ffmpeg-devel mailing list