Re: [FFmpeg-devel] [PATCH 16/21] fftools/ffmpeg: rework audio-decode timestamp handling

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 16/21] fftools/ffmpeg: rework audio-decode timestamp handling
Date: Fri, 28 Apr 2023 21:24:44 +0200
Message-ID: <20230428192444.GF275832@pb2> (raw)
In-Reply-To: <168268747635.3843.467810343388947412@lain.khirnov.net>

[-- Attachment #1.1: Type: text/plain, Size: 2107 bytes --]

On Fri, Apr 28, 2023 at 03:11:16PM +0200, Anton Khirnov wrote:
> 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?

28224000 is an option, so is AV_TIME_BASE. Neither contain 90khz though 
which is the mpeg-ps/ts "timebase". But i have the feeling if we keep adding
things then we will hit 32bit soon. 
28224000 is better for exactly representing timestamps, AV_TIME_BASE may be
easier for debuging.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".