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

Michael Niedermayer michael at niedermayer.cc
Fri Apr 28 22:24:44 EEST 2023


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230428/a5724d6a/attachment.sig>


More information about the ffmpeg-devel mailing list