From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 0C7C145C24 for ; Sat, 25 Mar 2023 22:17:16 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B5FB068CA7F; Sun, 26 Mar 2023 00:17:13 +0200 (EET) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4619668C76A for ; Sun, 26 Mar 2023 00:17:06 +0200 (EET) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 32PMH4aW011217-32PMH4aX011217 for ; Sun, 26 Mar 2023 00:17:05 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id F11DDA1542 for ; Sun, 26 Mar 2023 00:17:04 +0200 (EET) Date: Sun, 26 Mar 2023 00:17:03 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20230325003718.GR375355@pb2> Message-ID: References: <20230321123729.74124-1-martin@martin.st> <20230325003718.GR375355@pb2> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 1/2] libavformat: Improve ff_configure_buffers_for_index for excessive deltas X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sat, 25 Mar 2023, Michael Niedermayer wrote: > On Tue, Mar 21, 2023 at 02:37:28PM +0200, Martin Storsj=F6 wrote: >> Previously, the ff_configure_buffers_for_index function had >> upper sanity limits of 16 MB (1<<24) for buffer_size and >> 8 MB (1<<23) for short_seek_threshold. >> >> However, if the index analysis showed a need for even larger >> buffer sizes (for a really badly interleaved file), over the >> sanity limits, we previously didn't increase the buffer sizes >> at all. >> >> Instead, if the file shows a need for really large buffers and >> short_seek_threshold, just set them to the maximum sanity limit; >> while it might not be enough for all cases in the file, it might >> be enough for most of it. >> >> This can happen e.g. with a mov file with some tracks containing >> some samples that belong in the start of the file, at the end of >> the mdat, while the rest of the file is mostly reasonably interleaved; >> previously those samples caused the maximum pos_delta to skyrocket, >> skipping any buffer size enlargement. >> >> Signed-off-by: Martin Storsj=F6 >> --- >> libavformat/seek.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) > > I think, if iam not too tired ATM that > instead of taking the maximum it would be better to ignore the cases > which are above the maximum, so the value would be optimal for the > cases that it can help Sure, I guess that could be reasonable too - I can update the patch with = that. For the tricky file in my case, this algorithm currently observes mostly = deltas around 2-32 MB here, but with a few outliers around 2 GB. So the 2 = GB outliers clearly are irrelevant regardless of whether we keep the limit = at the current 16 MB or raise it a little bit. This heuristic algorithm currently does observe some differences over 32 = MB - but even with the buffer size set to the maximum of 16 MB, it's quite = enough to avoid most of the seeking. One thing I noted is that this function is called with time_tolerance set = to 1 second - but shouldn't it be quite enough to just have time_tolerance = set to 0? I.e. check exactly the next sample in the other tracks (since = that's what's going to be read in most cases), instead of checking a = sample 1 second in the future in other tracks? // 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".