[truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0

[microchip]

Summary of the bug: Trying to strip Atmos from TrueHD results in spamfest in terminal
How to reproduce: Run it on any video containing TrueHD+Atmos audio

% ffmpeg -i input -vn -c:a copy -bsf:a truehd_core output.thd

[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241380 >= 241380
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241385 >= 241385
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241390 >= 241390
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241395 >= 241395
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241400 >= 241400
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241405 >= 241405
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241410 >= 241410
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241415 >= 241415
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241420 >= 241420
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241425 >= 241425
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241430 >= 241430
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241435 >= 241435
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241440 >= 241440
[truehd @ 0x1d768440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 241445 >= 241445

ffmpeg version N-117812-gbbb0fdedb7
built on 17-november-2024

[Balling]

I checked a file I had (.m2ts). ​https://disk.yandex.ru/i/_bIh8MxWs5J_6A

It does not happen on it and Atmos is stripped. Please provide actual sample file.

[microchip]

The reported messages only appear if you output to .thd extension (audio-only TrueHD file). If using something else like mkv or mp4, they do not appear. In both cases (output to .thd audio only file or mkv/mp4 container) the Atmos is stripped. I guess this is normal when outputting to .thd ?

[Balling]

I outputed to thd without ac3 stream, yes.

[Balling]

Please provide the sample file.

[Balling]

This is not a bug, mkv container has only millisecond precision timestamps and there are 1200 frames per second in TrueHD, the time stamps will have to be identical. It is what it is. On the other hand mkv actually does not have dts or pts, it has only durations, so maybe you have to offset the dts when they come out the same, but that is a cosmetic issue.

"e.g. TrueHD packets have a duration < 1ms,
so different packets will end up with the same timestamp when using
1/1000)"
From here:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210521002954.1684-1-michael.dirks@xaymar.com/

[Balling]

ffmpeg -i mzero_truehd_sample.mkv -c:a copy fawfafa.thd

prints

[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 97 >= 97
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 102 >= 102
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 107 >= 107
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 112 >= 112
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 117 >= 117
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 122 >= 122
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 127 >= 127
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 132 >= 132
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 137 >= 137
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 142 >= 142
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 147 >= 147
[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 152 >= 152



(data cut here)

[truehd @ 0000029225d65e80] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 63227 >= 63227

so each of them has a difference of 5 just like in your example, the fix here is to use (see link on patchwork above)

The default value of 1/1000 is good for most use-cases, but there might
be scenarios where it is not (e.g. TrueHD packets have a duration < 1ms,
so different packets will end up with the same timestamp when using
1/1000). If the user has set a timestamp precision, then that should be
honoured; but if not, then we might use a different value than 1/1000
(in the future; I know that currently no code path that makes use of
this exists).

I doubt this will be implemented.