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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
