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 EBA6F40B08 for ; Mon, 27 Dec 2021 06:00:11 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6918168AF2D; Mon, 27 Dec 2021 08:00:09 +0200 (EET) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E2DC368A61A for ; Mon, 27 Dec 2021 08:00:03 +0200 (EET) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4JMn7l12ghzQk3D for ; Mon, 27 Dec 2021 07:00:03 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Message-ID: <6d544206-3e40-9de7-d3d9-8c84b89494ca@gyani.pro> Date: Mon, 27 Dec 2021 11:29:59 +0530 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20211226160044.5913-1-ffmpeg@gyani.pro> <20211226235117.GV2829255@pb2> From: Gyan Doshi In-Reply-To: <20211226235117.GV2829255@pb2> Subject: Re: [FFmpeg-devel] [PATCH v3] avformat/mov: add option max_stts_delta 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: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2021-12-27 05:21 am, Michael Niedermayer wrote: > On Sun, Dec 26, 2021 at 09:30:44PM +0530, Gyan Doshi wrote: >> Very high stts sample deltas may occasionally be intended but usually >> they are written in error or used to store a negative value for dts correction >> when treated as signed 32-bit integers. >> >> This option lets the user set an upper limit, beyond which the delta is clamped to 1. >> Values greater than the limit if negative when cast to int32 are used to adjust onward dts. >> >> Unit is the track time scale. Default is UINT_MAX - 48000*10 which >> allows upto a 10 second dts correction for 48 kHz audio streams while >> accommodating 99.9% of uint32 range. >> --- >> v3 changes: >> >> factored out loop >> simplified correction logic > this looks more sane now > i guess this cannot be easily split into a seperate patch ? No, all stts corrections depend on context of earlier corrections. > [...] >> @@ -2965,11 +2967,34 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom) >> sc->stts_data[i].count= sample_count; >> sc->stts_data[i].duration= sample_duration; >> >> - av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n", >> + av_log(c->fc, AV_LOG_TRACE, "sample_count=%u, sample_duration=%u\n", >> sample_count, sample_duration); >> >> - duration+=(int64_t)sample_duration*(uint64_t)sample_count; >> - total_sample_count+=sample_count; >> + /* STTS sample offsets are uint32 but some files store it as int32 >> + * with negative values used to correct DTS delays. >> + There may be abnormally large values as well. */ >> + if (sample_duration > c->max_stts_delta) { >> + // assume high delta is a correction if negative when cast as int32 >> + int32_t delta_magnitude = (int32_t)sample_duration; >> + av_log(c->fc, AV_LOG_WARNING, "Too large sample offset %u in stts entry %u with count %u in st:%d. Clipping to 1.\n", >> + sample_duration, i, sample_count, st->index); >> + sc->stts_data[i].duration = 1; >> + corrected_dts += (delta_magnitude < 0 ? (int64_t)delta_magnitude : 1) * sample_count; >> + } else { >> + corrected_dts += sample_duration * sample_count; >> + } >> + >> + current_dts += sc->stts_data[i].duration * sample_count; >> + >> + if (current_dts > corrected_dts) { >> + int64_t drift = (current_dts - corrected_dts)/sample_count; > division by 0 A sample count of 0 is nonsensical. Sent a separate patch for 0 values in stts. Will rebase this one on top. Regards, Gyan _______________________________________________ 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".