FFmpeg - What does non monotonically increasing dts mean?

Question

Observations - Part - I

I saw a suggestion elsewhere to run the following command to see if there's something wrong with my .mp4.

ffmpeg -v error  -i ~/Desktop/5_minute_sync_output_15mn.mp4 -f null - 2>error.log

When I run the above command, I see a whole bunch of the logs on the lines of what's shown below.

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 15635 >= 15635

This, from searching and reading up quite a bit, I understand that the decoding timestamp isn't in sequential order.

Observations - Part II

But, inspecting the frames of the same mp4 using the following command and some post processing, I don't see pkt_dts within the frames_info json being out of order for either of the video or audio streams.

ffprobe -loglevel panic -of json -show_frames ~/Desktop/5_minute_sync_output_15mn.mp4

This makes me doubt my initial understanding in Observations - Part - I

Are these 2 things not related? Any help on this will be greatly appreciated.

Outclass

Monotonically increasing means strictly increasing. You can't have two packets with the same value or a value lower than the previous one. Does it apply to the ffprobe output? – Sterile

Okay. The monotonic part makes sense. When I ffprobe it as shown in the second command in my Part II Observations, all pkt_dts values are strictly increasing. Not sure why. – Outclass

Hi guys, anyone out there who can help me understand these logs? I can't make sense of it. I'm seeing it on a consistent basis with other files too. – Outclass

Here I am trying to find if I should worry about this or not :( – Worl

Answer 1

---

This message is not about the input file's validity, it is from the output format not accepting non monotonous dts. Many input formats support non monotonous dts (grep -r AVFMT_TS_NONSTRICT FFmpeg) so it is not necessarily a problem with the file.

The null format does not need any timestamps as indicated by the AVFMT_NOTIMESTAMPS:

https://github.com/FFmpeg/FFmpeg/blob/ce8f77a903e1108bde774d5e0e59d8cd24f18c46/libavformat/nullenc.c#L36

However, the dts check still happens unless AVFMT_TS_NONSTRICT is set in the nullenc.c flags:

https://github.com/FFmpeg/FFmpeg/blob/ce8f77a903e1108bde774d5e0e59d8cd24f18c46/libavformat/mux.c#L563

This seems to be an oversight, it does not make sense to check the validity of the timestamps passed to the null format. Other formats that do not actually encode the data, like the hash format, also have the AVFMT_TS_NONSTRICT flag.

Cooee

Look like someone else was annoyed by the spammy logs back in 2015 and submitted a patch to add the AVFMT_TS_NONSTRICT flag to nullenc.c. I guess it wasn't merged. Shame. – Viradis

@ollie Right, currently the check for equality is wrong, so I still get with media-video/ffmpeg-6.0-r3:0/58.60.60::gentoo: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f37e418bcc0] All samples in data stream index:id [1:-2147483648] have zero duration, stream set to be discarded by default. Override using AVStream->discard or -discard for ffmpeg command. [hevc @ 0x55ee39edb300] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 10657898 >= 10657898 – Elastance