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