[FFmpeg-user] [avi @ 0x9873ba0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1104 >= 1104 [avi @ 0x987d2a0] Application provided invalid, non monotonically increasing dts to muxer only when using tee muxer

[Michael Kohne]

I'm using ffmpeg 4.1 to grab an rtsp stream (includes both H.264 video and
G.711 audio) from a Sony EP580 IP camera.

If I transcode to mpeg4v2 and aac to a single avi file, things seem to work
fine.
This command line will go for as long as I like (I regularly do 15 minutes
at a go).

ffmpeg -min_port 62000 -max_port 62004 -i rtsp://192.168.0.113/media/video1
-codec:v msmpeg4v2 -codec:a ac3 -ar 44100 -map 0 -f avi
/data/PatientData/vidtmp/test.avi


If I instead use the tee muxer to make two avi files:

ffmpeg -min_port 62000 -max_port 62004 -i rtsp://192.168.0.113/media/video1
-codec:v msmpeg4v2 -codec:a ac3 -ar 44100 -map 0 -f tee
"[f=avi]/data/PatientData/vidtmp/one.avi|[f=avi]/data/PatientData/vidtmp/two.avi"

Then within 2 minutes of starting the stream, it fails with the errors:
[avi @ 0x9873ba0] Application provided invalid, non monotonically
increasing dts to muxer in stream 1: 1104 >= 1104
[avi @ 0x987d2a0] Application provided invalid, non monotonically
increasing dts to muxer in stream 1: 1104 >= 1104

I've repeated these tests over and over for a week or so now, so I am
fairly confident that it's not simply that the camera is janky some of the
time. I've also tested using the rtsp stream 'rtsp://
184.72.239.149/vod/mp4:BigBuckBunny_175k.mov'. That stream does not produce
any errors with the tee muxer.

Note that those errors both appear to come from the avi muxers, not the tee
muxer, which is why I find it surprising: if the camera's output causes
this, then why doesn't it happen with the single avi muxer?

Test note: the tee invocation is the simplest command line that I could
come up with that produces the problem. In the real world one avi muxer
goes to a pipe for a live output display, and the other goes to the segment
muxer to produce output files in manageable chunks.

I did also try this with the latest ffmpeg snapshot (as of yesterday
morning), and there was no difference in behavior.

Any clues as to how to debug this would be greatly appreciated.


ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-11)
configuration: --prefix=/data/SHR4634/ffmpeg/build
--extra-cflags=-I/data/SHR4634/ffmpeg/build/include
--extra-ldflags=-L/data/SHR4634/ffmpeg/build/lib --extra-libs='-lm -ldl
-lpthread -lrt' --enable-gpl --enable-nonfree --disable-libfdk_aac
--enable-libmp3lame --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libfreetype --enable-libspeex --enable-libtheora --cpu=i686
--enable-runtime-cpudetect
libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100

OS is CentOS 6, 32 bit.


Michael Kohne

Senior Software Engineer
Office: 215.283.0860 x208
mhkohne at moberg.com

-- 






Celebrating 20 Years

Transforming Neurocritical Care

Moberg 
Research, Inc.

224 S Maple Street, Ambler, PA 19002

24/7 Customer 
Support: 888.662.7246

www.moberg.com <https://www.moberg.com/>