Re: [FFmpeg-devel] [PATCH 2/2] aviobuf: Avoid clearing the whole buffer in fill_buffer

From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/2] aviobuf: Avoid clearing the whole buffer in fill_buffer
Date: Fri, 24 Mar 2023 23:41:08 +0200 (EET)
Message-ID: <c685b9e8-9a7a-1caa-5471-54e2d32a3387@martin.st> (raw)
In-Reply-To: <3a3dd093-eb11-f21-9d79-e4882eb59b6@passwd.hu>

On Fri, 24 Mar 2023, Marton Balint wrote:

>
>
> On Fri, 24 Mar 2023, Martin Storsjö wrote:
>
>> On Fri, 24 Mar 2023, Marton Balint wrote:
>>
>>>  I am uneasy about complicating an already complicated and hard-to-follow
>>>  AVIO layer with heuristics which activate on magic behaviour. And we all
>>>  know how long temporary solutions last :)
>>>
>>>  I guess we could add some new parameter to AVIOContext end enable this
>>>  data-shifting behaviour explicitly when you reconfigure the buffer size
>>>  for index in the MOV demuxer. But is it worth it? How significant is the
>>>  "improvement" this patch provides over the previous one in the series?
>>
>> With the 2.6 GB, 40 minute mov file I'm looking at, originally, due to the 
>> issue fixed in patch 1/2, the buffer size was never increased from the 
>> original 32 KB, so when reading the file linearly, we would do many tens of 
>> thousands of seek requests, giving absolutely abysmal performance. (I saw a 
>> server side log number saying 120 000 requests.)
>>
>> With patch 1/2 applied, while reading the bulk of the file, it does ~170 
>> seeks. So nothing terrible, but it still feels unnecessarily inefficient to 
>> do >4 seeks per minute due to the fact that the aviobuf layer is throwing 
>> away good data that it already had buffered.
>>
>> In this case, it used a buffer size of 16 MB, and calculating 2.6 GB / 16 
> MB 
>> ends up very near 170. So every time the 16 MB aviobuf buffer gets full and 
>> aviobuf clears it, we end up doing a seek backwards.
>
> Thanks for the details. Patch/1 already made the significant improvement,

Yeah - can I get someone to approve that one too? :-)

> so yeah, I am not sure about Patch/2 knowing it is not the "right" way.

Yeah, I'm a bit on the fence myself. On one hand, it's been a pet peeve of 
mine for years, that we throw away the buffered data regularly like this, 
but the implementation maybe isn't the best. So for the practical 
performance issue it's probably not essential - it's just an annoying wart 
that is left :-)

// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".