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.
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 theAVFMT_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 thenullenc.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.