Stream gets closed with "DTS is not monotonically increasing"

[rudyryk]

Which version are you using?

v1.0.3-5-gc1cc320 (from #2289)

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

Stream is dropped after several seconds with "DTS is not monotonically increasing" error.

Describe how to replicate the issue

1. Start the server
2. Publish stream with RTMP push strategy
3. Read the stream using the same RTMP link, e.g. with FFMPEG
4. Wait for 20-30 seconds (sometimes less or more)
5. Stream is dropped with "Input/output error" from FFMPEG and "DTS is not monotonically increasing" on MediaMTX side

Did you attach the server logs?

Yes

2023/09/11 19:30:43 INF [RTMP] [conn 1.2.3.4:44336] is reading from path 'stream/x09rc2-4', 2 tracks (H264, MPEG-4 Audio)
2023/09/11 19:30:52 INF [RTMP] [conn 1.2.3.4:44336] closed (DTS is not monotonically increasing, was 1h22m41.79s, now is 1h22m41.79s)
2023/09/11 19:30:56 INF [RTMP] [conn 1.2.3.4:55464] opened
2023/09/11 19:30:57 INF [RTMP] [conn 1.2.3.4:55464] is reading from path 'stream/x09rc2-4', 2 tracks (H264, MPEG-4 Audio)
2023/09/11 19:30:57 INF [RTMP] [conn 1.2.3.4:55464] closed (DTS is not monotonically increasing, was 1h22m46.56s, now is 1h22m46.56s)
2023/09/11 19:31:01 INF [RTMP] [conn 1.2.3.4:39664] opened
2023/09/11 19:31:01 INF [RTMP] [conn 1.2.3.4:39664] is reading from path 'stream/x09rc2-4', 2 tracks (H264, MPEG-4 Audio)
2023/09/11 19:31:16 INF [RTMP] [conn 1.2.3.4:39664] closed (DTS is not monotonically increasing, was 1h23m5.46s, now is 1h23m5.46s)

Did you attach a network dump?

No

[rudyryk]

Update: this actually happened on specific camera and specific firmware version, so most likely not a bug. But as far as I know not monotonically increasing DTS is a common thing on streams and FFMPEG displays warnings but does not interrupt, so I thought there might be possible to send warnings here as well.

[kingprawn22]

I'm also seeing this same issue, but only when I push a stream to the server using Apple's 'Hardware (H.264)' encoder in OBS on my Macbook. If I use 'Software (x264)', the stream works fine. If I change to 'Hardware (HEVC)', the stream remains connected, but viewing it results in no video. Could using a video encoder other than x264 be cause this issue for you also?

[kingprawn22]

I've not been able to figure this out. I've tried to use a separate ffmpeg process to accept all incoming rtmp streams and convert to x264 so that MediaMTX can then deal with the stream, but I've not been able to set it up in a way that works for me. I run a project that accepts connections from a wide variety of streamers, and I need them to be able to use whichever video encoder works for them, instead of telling them to use one that this software supports. Therefore, I'll need to switch to a different streaming solution.

[aler9]

This is a duplicate of #1002. Anyway, it's useless to open this kind of threads without providing any network dump, making impossible to replicate the issue.

[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.