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 4D3544084A for ; Fri, 28 Apr 2023 13:11:26 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F075568BFBC; Fri, 28 Apr 2023 16:11:23 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 44BF968BF70 for ; Fri, 28 Apr 2023 16:11:18 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 6126D2404EC for ; Fri, 28 Apr 2023 15:11:17 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NN4QxJhM-_8D for ; Fri, 28 Apr 2023 15:11:16 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 7D1AF240177 for ; Fri, 28 Apr 2023 15:11:16 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 5D6ED1601B2; Fri, 28 Apr 2023 15:11:16 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20230428114217.GE275832@pb2> References: <20230427142601.2613-1-anton@khirnov.net> <20230427142601.2613-16-anton@khirnov.net> <20230428114217.GE275832@pb2> Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 28 Apr 2023 15:11:16 +0200 Message-ID: <168268747635.3843.467810343388947412@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 16/21] fftools/ffmpeg: rework audio-decode timestamp handling 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Michael Niedermayer (2023-04-28 13:42:17) > On Thu, Apr 27, 2023 at 04:25:56PM +0200, Anton Khirnov wrote: > > Stop using InputStream.dts for generating missing timestamps for decoded > > frames, because it contains pre-decoding timestamps and there may be > > arbitrary amount of delay between input packets and output frames (e.g. > > dependent on the thread count when frame threading is used). It is also > > in AV_TIME_BASE (i.e. microseconds), which may introduce unnecessary > > rounding issues. > > > > > New code maintains a timebase that is the inverse of the LCM of all the > > samplerates seen so far, and thus can accurately represent every audio > > if the LCM fits in int32 > > This can hit some pathologic cases though > consider a 192khz stream that starts with a damaged packet thats read as 11.197 khz > lcm of 192000 and 11197 > 2^31 so the whole stream will then be stuck with 11.197khz > that seems like a bad choice > the code should favor standard sample rates as well as the higher sample rate if > the lcm is not representable > > also if lets say there are 48khz and 48.001khz where again lcm doesnt work > then a multiple of 48khz may be a better choice than either itself Thank you, there are good points. I'm wondering if just picking the LCM of all common samplerates (28224000 = lcm(192000, 44100)) wouldn't be sufficient for all these pathological cases. Or do you have a better general algorithm in mind? Maybe fall back on AV_TIME_BASE instead? > also what happens if the audio timestamps are known more precissely than > the audio sample rate ? I'm not sure that is very relevant in real-world uses cases, but I've added this snippet which should address this: // keep the frame timebase if it is strictly better than // the samplerate-defined one if (frame->time_base.num == 1 && frame->time_base.den > tb_new.den && !(frame->time_base.den % tb_new.den)) tb_new = frame->time_base; -- Anton Khirnov _______________________________________________ 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".