FFmpeg stops updating at 13:14:21

[ajkq]

Which version are you using?

v0.18.0

Which operating system are you using?

• Linux amd64 standard (Debian 11)

Describe the issue

FFmpeg stops updating at 13:14:21 when accessing only the video stream
from a camera providing both audio and video through rtsp-simple-server.
(Ref. MWE "Proxied video").

When accessing both video+audio with ffmpeg (omitting
-allowed_media_types video), it outputs the same log messages but the
video keeps updating. (Ref. MWE "Proxied audio+video").

The issue is not exhibited when accessing the camera streams directly
with ffmpeg, bypassing rtsp-simple-server. (Ref. MWE "Direct
video"/"Direct audio+video").

Adding the ffmpeg input parameter -correct_ts_overflow 0 when
accessing the streams through rtsp-simple-server is a valid workaround.
(Ref. MWE "Proxied video without overflow correction"/"Proxied
audio+video without overflow correction").

Replication steps: (minimal working example)

For all examples, first start the server with the following configuration:

protocols: [tcp]
rtmpDisable: yes
hlsDisable: yes
logFile: server.log
logLevel: debug
logDestinations: [file]
rtspAddress: :8555

paths:
  test:
    source: rtsp://iptv:iptv@cam3.lab.test/axis-media/media.amp
    sourceProtocol: udp
    readUser: iptv
    readPass: iptv

./rtsp-simple-server server.yml

Then, run the example commands with John Van Sickle's static ffmpeg 5.0.1 build:

Proxied video

FFmpeg stops updating at 13:14:21 when accessing only the video stream
from a camera providing both audio and video through rtsp-simple-server.

FFREPORT=file=ffreport-server-v.log:level=40 ./ffmpeg -progress \
udp://127.0.0.1:50001 -nostdin -nostats -rtsp_transport tcp \
-allowed_media_types video -i rtsp://iptv:iptv@localhost:8555/test \
-c copy -f null -

FFmpeg starts outputting the following lines after 13:14:21.
Log file: ffreport-server-v.log

[null @ 0x6acd140] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4289560132 >= -5398164
[null @ 0x6acd140] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4289560132 >= -5389164
[null @ 0x6acd140] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4289560132 >= -5380165
...

Progress stops updating:

nc -lu 50001 | grep -B11 -m2 progress=continue

frame=887168
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=47661779256
out_time_ms=47661779256
out_time=13:14:21.779256
dup_frames=0
drop_frames=0
speed=0.947x
progress=continue
frame=887174
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=47661779256
out_time_ms=47661779256
out_time=13:14:21.779256
dup_frames=0
drop_frames=0
speed=0.947x
progress=continue

Direct video

The issue is not exhibited when accessing the camera streams directly
with ffmpeg, bypassing rtsp-simple-server.

FFREPORT=file=ffreport-direct-v.log:level=40 ./ffmpeg -progress \
udp://127.0.0.1:50003 -nostdin -nostats -rtsp_transport tcp \
-allowed_media_types video \
-i rtsp://iptv:iptv@cam3.lab.test/axis-media/media.amp \
-c copy -f null -

No warnings logged.
Log file: ffreport-direct-v.log

No issues, progress keeps updating:

nc -lu 50003 | grep -B11 -m2 progress=continue

frame=886318
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50281736478
out_time_ms=50281736478
out_time=13:58:01.736478
dup_frames=0
drop_frames=0
speed=   1x
progress=continue
frame=886323
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50282236467
out_time_ms=50282236467
out_time=13:58:02.236467
dup_frames=0
drop_frames=0
speed=   1x
progress=continue

Proxied video without overflow correction

Adding the ffmpeg input parameter -correct_ts_overflow 0 when
accessing the streams through rtsp-simple-server is a valid workaround.

FFREPORT=file=ffreport-server-v-corr.log:level=40 ./ffmpeg -progress \
udp://127.0.0.1:50001 -nostdin -nostats -correct_ts_overflow 0 \
-rtsp_transport tcp -allowed_media_types video \
-i rtsp://iptv:iptv@localhost:8555/test -c copy -f null -

No warnings logged.
Log file: ffreport-server-v-corr.log

Progress keeps updating:

nc -lu 50001 | grep -B11 -m2 progress=continue

frame=1613815
fps=20.24
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=79749120600
out_time_ms=79749120600
out_time=22:09:09.120600
dup_frames=0
drop_frames=0
speed=   1x
progress=continue
frame=1613821
fps=20.24
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=79749720578
out_time_ms=79749720578
out_time=22:09:09.720578
dup_frames=0
drop_frames=0
speed=   1x
progress=continue

Proxied audio+video

When accessing both video+audio with ffmpeg (omitting
-allowed_media_types video), it outputs the same log messages but the
video keeps updating.

FFREPORT=file=ffreport-server-av.log:level=40 ./ffmpeg -progress \
udp://127.0.0.1:50002 -nostdin -nostats -rtsp_transport tcp \
-i rtsp://iptv:iptv@localhost:8555/test -c copy -f null -

FFmpeg starts outputting the following lines after 13:14:21.
Log file: ffreport-server-av.log

[null @ 0x5c10000] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4293085212 >= -1873085
[null @ 0x5c10000] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4293085212 >= -1864085
[null @ 0x5c10000] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4293085212 >= -1855085
...

Progress keeps updating:

nc -lu 50002 | grep -B11 -m2 progress=continue

frame=886742
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50297925531
out_time_ms=50297925531
out_time=13:58:17.925531
dup_frames=0
drop_frames=0
speed=   1x
progress=continue
frame=886747
fps=17.63
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50298437531
out_time_ms=50298437531
out_time=13:58:18.437531
dup_frames=0
drop_frames=0
speed=   1x
progress=continue

Direct audio+video

The issue is not exhibited when accessing the camera streams directly
with ffmpeg, bypassing rtsp-simple-server.

FFREPORT=file=ffreport-direct-av.log:level=40 ./ffmpeg -progress \
udp://127.0.0.1:50004 -nostdin -nostats -rtsp_transport tcp \
-i rtsp://iptv:iptv@cam3.lab.test/axis-media/media.amp \
-c copy -f null -

No issues logged.
Log file: ffreport-direct-av.log

Progress keeps updating:

nc -lu 50004 | grep -B11 -m2 progress=continue

frame=885967
fps=17.62
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50270213813
out_time_ms=50270213813
out_time=13:57:50.213813
dup_frames=0
drop_frames=0
speed=   1x
progress=continue
frame=885972
fps=17.62
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=50270725781
out_time_ms=50270725781
out_time=13:57:50.725781
dup_frames=0
drop_frames=0
speed=   1x
progress=continue

Proxied audio+video without overflow correction

Adding the input parameter -correct_ts_overflow 0 when accessing the
streams through rtsp-simple-server is a valid workaround.

FFREPORT=file=ffreport-server-av-corr.log:level=40 ./ffmpeg \
-progress udp://127.0.0.1:50002 -nostdin -nostats \
-correct_ts_overflow 0 -rtsp_transport tcp \
-i rtsp://iptv:iptv@localhost:8555/test -c copy -f null -

No warnings logged.
Log file: ffreport-server-av-corr.log

Progress keeps updating:

nc -lu 50002 | grep -B11 -m2 progress=continue

frame=1613045
fps=20.25
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=79674546219
out_time_ms=79674546219
out_time=22:07:54.546219
dup_frames=0
drop_frames=0
speed=   1x
progress=continue
frame=1613050
fps=20.25
stream_0_0_q=-1.0
bitrate=N/A
total_size=N/A
out_time_us=79675058219
out_time_ms=79675058219
out_time=22:07:55.058219
dup_frames=0
drop_frames=0
speed=   1x
progress=continue

Did you attach the server logs?

yes

Server run reproducing the issue: server.log

Server run with -correct_ts_overflow 0: server-corr.log

Did you attach a network dump?

no

[aler9]

Hello, this is caused by a negative offset between timestamp contained into the RTP-Info header and timestamp contained in the first RTP packet. I checked the code again and i found some additional things related to the RTP-Info header that needed to be changed:

• time in rtptime was truncated to seconds, and this caused negative offsets at the beginning of the stream
• an additional initial delay of 1/10 second was added in order to fully eliminate negative offsets
• sequence number was increase by one

With these changes i was able to run a ffmpeg reader indefinitely. Please try this nightly release and let me know if it works for you too.

[link removed]

[aler9]

added in v0.18.4.

[ajkq]

Thanks! I tested v0.18.4, issue is gone.

[github-actions]

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.