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.

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.