muxer error: DTS is not monotonically increasing

[barlowd55]

Which version are you using?

v0.19.2

Which operating system are you using?

• [ x] Linux amd64 standard

Describe the issue

The HLS muxer on proxied mode keeps on stuttering. More like the HLS Muxer gets destroyed with an error - (muxer error: DTS is not monotonically increasing) and then starts again when the client requests again. It keeps on going and the stream gets disconnected and then connects again.

Describe how to replicate the issue

1. Start the server
2. Use HLS stream (tested on 2 such instances) on proxied mode. Keep fmp4 segment option, rest is default
3. Test with any client

Did you attach the server logs?

no

Did you attach a network dump?

no

[aler9]

Hello, this is camera-specific, you have to provide either a working RTSP URL or a video sample.

[barlowd55]

It is a private hls stream. How do I upload a video sample?

[barlowd55]

Just checking on this error, can this be fixed.

[aler9]

as i already said, you have to provide either a working RTSP URL or a video sample (for instance, by recording your stream with ffmpeg and the -c copy option, then posting the sample).

[barlowd55]

Ok sure.

Here is a sample that has incorrect dts. Archive.zip

[aler9]

The file you provided makes the muxer close with error muxer error: unsupported, not with error muxer error: DTS is not monotonically increasing - are you sure that the sample was taken from your original stream? i'm interested into widening support for streams with non-standard PTS / DTS, but i have to understand exactly what i'm dealing with.

[barlowd55]

Here found the perfect stream with the error.

http://170.178.189.66:1935/live/Stream1/playlist.m3u8

This should help you.

[Kiennh]

Dear @aler9

Are there any update for this issue, I have facing same problem with video streaming from mobile phone with profile h264 high.

Output from rtmp-simple-server:

2022/07/27 14:22:24 INF [RTMP] [conn [::1]:51127] is publishing to path 'live/xyz', 1 track
2022/07/27 14:22:24 INF [HLS] [muxer live/xyz] created automatically
2022/07/27 14:22:24 INF [HLS] [muxer live/xyz] is converting into HLS
2022/07/27 14:22:26 INF [HLS] [muxer live/xyz] destroyed (muxer error: DTS is not monotonically increasing, was 2.492s, now is 2.491s)
2022/07/27 14:22:26 INF [HLS] [muxer live/xyz] created automatically
2022/07/27 14:22:26 INF [HLS] [muxer live/xyz] is converting into HLS
2022/07/27 14:22:29 INF [HLS] [muxer live/xyz] destroyed (muxer error: DTS is not monotonically increasing, was 2.961s, now is 2.927s)
2022/07/27 14:22:29 INF [HLS] [muxer live/xyz] created automatically

This is my video captured from nginx rtmp gateway: h264_high_err_dts.flv.zip

Video info by ffmpeg:

Input #0, flv, from 'h264_high_err_dts.flv':
  Duration: 00:01:42.63, start: 0.000000, bitrate: 1297 kb/s
  Stream #0:0: Audio: aac (HE-AAC), 44100 Hz, stereo, fltp
  Stream #0:1: Video: h264 (High), yuv420p(progressive), 720x1480, 30 fps, 30 tbr, 1k tbn

[Guesswhoitis]

I appear to be having a similar error. I am publishing a rtmp stream from OBS and trying to watch it HLS. Server is running locally. OBS is streaming to endpoint rtmp://localhost:1935 my stream key is "test".

Attempt to watch in firefox at URL http://localhost:8888/test/. Firefox keeps showing buffering symbol.

Console output of server attached.

Though when pushing using RTSP from larix broadcaster on my phone I am able to view it in firefox using the same endpoint

Is this a setup issue?

[Spengreb]

I am also having this issue also with https. Any ideas on how to fix?

[FlantasticDan]

I too am experiencing this muxer error. All is well in v0.18.5 but updating to v0.19.x causes the issue to surface when using identical NVENC encoder settings to stream via RTMP in OBS v27.2.4.

[Spengreb]

Ah yeah setting Encoder to Software (x264) in OBS has fixed this for me. Thanks @FlantasticDan

[F0xin1]

I'm experiencing a similar issue. I'm using the ffmpeg encoder in OBS (StreamFX), but I get this error when I'm not streaming with x264. I found that changing the key frame interval to zero does allow the stream to load, though the stream quality comes out poor.

[instinctualjealousy]

Can confirm this issue as well, even on v0.20.0. Using v0.18.5 for now as GPU encoding is a necessity for me.

[aler9]

v0.20.2 includes a fix that should solve the issue with most configurations. I'm leaving this issue opened since i'm not sure that all cases were covered.

[F0xin1]

Still running into this issue, though it's probably related to my setup. I'm currently using the 'StreamFX' plugin for OBS that gives me FFMPEG options for streaming, in which I've adjusted some settings to achieve a low latency stream that currently works with RTSP. I tried adjusting some of the HLS settings in the YML file, though I have left it as default for this (minus changing hlsVariant to lowLatency), and I am noticing a new warning appear when trying to resolve the stream in VLC/Chrome:

2022/11/05 21:40:22 INF [HLS] listener opened on :443
2022/11/05 21:40:28 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:28 INF [path portal] [rtsp source] started
2022/11/05 21:40:29 INF [path portal] [rtsp source] ready: 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:29 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:30 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.3s, now is 1.299666667s)
2022/11/05 21:40:32 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:32 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:32 WAR [path portal] [rtsp source] expected FU-A packet, got STAP-A packet
2022/11/05 21:40:34 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.8s, now is 1.799666667s)
2022/11/05 21:40:38 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:38 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:38 WAR [path portal] [rtsp source] expected FU-A packet, got SEI packet
2022/11/05 21:40:40 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.733s, now is 1.732666667s)
2022/11/05 21:40:45 INF [path portal] [rtsp source] stopped

[kevinjacb]

I faced this issue recently, but after another look at my code, I realized the thread I was running this on was being called repeatedly. I don't know if this will help anybody, but check your threads....

[chungnyul]

Still running into this issue, though it's probably related to my setup. I'm currently using the 'StreamFX' plugin for OBS that gives me FFMPEG options for streaming, in which I've adjusted some settings to achieve a low latency stream that currently works with RTSP. I tried adjusting some of the HLS settings in the YML file, though I have left it as default for this (minus changing hlsVariant to lowLatency), and I am noticing a new warning appear when trying to resolve the stream in VLC/Chrome:

2022/11/05 21:40:22 INF [HLS] listener opened on :443
2022/11/05 21:40:28 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:28 INF [path portal] [rtsp source] started
2022/11/05 21:40:29 INF [path portal] [rtsp source] ready: 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:29 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:30 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.3s, now is 1.299666667s)
2022/11/05 21:40:32 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:32 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:32 WAR [path portal] [rtsp source] expected FU-A packet, got STAP-A packet
2022/11/05 21:40:34 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.8s, now is 1.799666667s)
2022/11/05 21:40:38 INF [HLS] [muxer portal] created (requested by 76.18.138.4)
2022/11/05 21:40:38 INF [HLS] [muxer portal] is converting into HLS, 2 tracks (H264, MPEG4Audio)
2022/11/05 21:40:38 WAR [path portal] [rtsp source] expected FU-A packet, got SEI packet
2022/11/05 21:40:40 INF [HLS] [muxer portal] destroyed (muxer error: DTS is not monotonically increasing, was 1.733s, now is 1.732666667s)
2022/11/05 21:40:45 INF [path portal] [rtsp source] stopped

It's a similar disorder.

I am testing with windows v0.20.4, and the program used for playback is VLC.

When configured with the HLS default option, it works normally, but when changing to the Low Latency option according to the guide, the following error occurs.

2022/12/16 10:31:03 INF [HLS] [muxer mystream] created (requested by 192.168.1.130)
2022/12/16 10:31:03 INF [HLS] [muxer mystream] is converting into HLS, 2 tracks (H264, MPEG4-audio)
2022/12/16 10:31:07 INF [HLS] [muxer mystream] destroyed (muxer error: DTS is not monotonically increasing, was 4.605211111s, now is 4.605211111s)

[gofaster]

I am occasionally seeing this with a LL-HLS proxy on a stream that's been going for some hours to a Chrome browser. The source is running rtsp-simple-server 0.20.4, streaming a raspberry pi camera. This source is wifi connected. The proxy is running 0.20.4, connecting to the source via rtsp/tcp. This proxy is on wired ethernet.

Another process (NVR) that is connected to the source rtsp/tcp at the same time consumes the stream normally.

Refreshing or the HLS URL in the browser or loading it in a new tab fails with the same DTS is not monotonically... error on the proxy. A RTSP connection to the proxy and stream works without error.

If I restart rtsp-simple-server on the source - the proxy and browser recover automatically and the HLS stream resumes without intervention.

Log snippet from the proxy:

[...]
Dec 18 08:28:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:28:44 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:28:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:28:44 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:28:45 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:28:45 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:28:55 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:28:55 INF [path frontdoor] [rtsp source] stopped
Dec 18 08:29:01 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:01 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:01 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:01 INF [path frontdoor] [rtsp source] started
Dec 18 08:29:01 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:01 INF [path frontdoor] [rtsp source] ready: 1 track (H264)
Dec 18 08:29:01 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:01 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:02 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:02 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:04 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:04 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:04 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:04 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:05 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:05 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:07 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:07 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:07 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:07 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:08 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:08 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:12 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:12 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:12 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:12 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:13 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:13 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:21 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:21 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:21 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:21 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:22 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:22 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:32 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:32 INF [path frontdoor] [rtsp source] stopped
Dec 18 08:29:38 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:38 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:38 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:38 INF [path frontdoor] [rtsp source] started
Dec 18 08:29:38 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:38 INF [path frontdoor] [rtsp source] ready: 1 track (H264)
Dec 18 08:29:38 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:38 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:39 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:39 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:41 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:41 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:41 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:41 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:42 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:42 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:44 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:44 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:44 WAR [path frontdoor] [rtsp source] invalid FU-A packet (non-starting)
Dec 18 08:29:44 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:44 WAR [path frontdoor] [rtsp source] invalid FU-A packet (non-starting)
Dec 18 08:29:45 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:45 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:49 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:49 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:49 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:49 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:50 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:50 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:29:58 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:58 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:29:58 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:58 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:29:59 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:29:59 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:30:09 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:09 INF [path frontdoor] [rtsp source] stopped
Dec 18 08:30:15 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:15 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:30:15 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:15 INF [path frontdoor] [rtsp source] started
Dec 18 08:30:15 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:15 INF [path frontdoor] [rtsp source] ready: 1 track (H264)
Dec 18 08:30:15 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:15 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:30:16 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:16 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:30:18 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:18 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:30:18 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:18 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:30:19 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:19 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
Dec 18 08:30:21 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:21 INF [HLS] [muxer frontdoor] created (requested by 192.168.0.74)
Dec 18 08:30:21 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:21 INF [HLS] [muxer frontdoor] is converting into HLS, 1 track (H264)
Dec 18 08:30:22 rpi4b-1 rtsp-simple-server[27912]: 2022/12/18 08:30:22 INF [HLS] [muxer frontdoor] destroyed (muxer error: DTS is not monotonically increasing, was 0s, now is 0s)
[...]

HLS and path config section on proxy

# HLS parameters
hlsDisable: no
hlsAddress: :8888
hlsAlwaysRemux: no
hlsVariant: lowLatency
hlsSegmentCount: 7
hlsSegmentDuration: 1s
hlsPartDuration: 200ms
hlsSegmentMaxSize: 50M
hlsAllowOrigin: '*'
hlsEncryption: yes
hlsServerKey:  pathTo.key
hlsServerCert: pathTo.cer
hlsTrustedProxies: []

# Path parameters
paths:
  frontdoor:
    source: rtsp://user:pass@xxx.xxx.xxx.xxx:8554/cam
    sourceProtocol: tcp
    sourceAnyPortEnable: no
    sourceFingerprint:
    sourceOnDemand: yes
    sourceOnDemandStartTimeout: 10s
    sourceOnDemandCloseAfter: 10s
    sourceRedirect:
    disablePublisherOverride: no
    fallback:
    publishUser:
    publishPass:
    publishIPs: []
    readUser: user
    readPass: pass
    readIPs: []
    runOnInit:
    runOnInitRestart: no
    runOnDemand:
    runOnDemandRestart: no
    runOnDemandStartTimeout: 10s
    runOnDemandCloseAfter: 10s
    runOnReady:
    runOnReadyRestart: no
    runOnRead:
    runOnReadRestart: no

[kotori2]

I'm still getting this error with OBS NVENC HEVC option. I'm just recording my screen so it shouldn't be a camera issue. Version: MediaMTX v0.23.5 with all default settings.

2023/06/20 03:39:01 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:39:01 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:39:12 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 11.417s, now is 11.416666667s)
2023/06/20 03:39:14 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:39:14 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:39:25 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 10.417s, now is 10.416666667s)
2023/06/20 03:39:30 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:39:30 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:39:37 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 7.6s, now is 7.599666667s)
2023/06/20 03:39:46 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:39:46 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:40:02 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.584s, now is 16.583666667s)
2023/06/20 03:40:11 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:40:11 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:40:15 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 4.133s, now is 4.132666667s)
2023/06/20 03:40:24 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:40:24 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:40:40 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.084s, now is 16.083666667s)
2023/06/20 03:40:49 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:40:49 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:41:05 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.15s, now is 16.149666667s)
2023/06/20 03:41:14 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:41:14 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:41:30 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.15s, now is 16.149666667s)
2023/06/20 03:41:39 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:41:39 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:41:55 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.15s, now is 16.149666667s)
2023/06/20 03:42:04 INF [HLS] [muxer REDACTED] created (requested by 192.168.50.186)
2023/06/20 03:42:04 INF [HLS] [muxer REDACTED] is converting into HLS, 2 tracks (H265, MPEG4-audio-gen)
2023/06/20 03:42:20 INF [HLS] [muxer REDACTED] destroyed (muxer error: unable to extract DTS: DTS is not monotonically increasing, was 16.084s, now is 16.083666667s)

[curlydoggy]

@aler9

2128

This is a continuation of the above issue. Currently, about six samples from various cameras are raised to about 10 minutes. I extracted the image through the command below, and I attach the command just in case.

ffmpeg -i [rtsp url] -acodec copy -vcodec copy c:/sample.mp4

And I attach the video together, but the size of the video zip file is too large, so I replace it with the Google drive address. Thank you. Please give me quick feedback.

https://drive.google.com/file/d/1dgU__r5sKyyD5NeRoq9yKudhvYn29HxA/view?usp=sharing

[curlydoggy]

@aler9 Is this problem related to camera image resolution or frame? I think it's currently set at 1080p for about 30 frames, but I thought lowering this to about 720p 15 frames would solve the problem

[aler9]

@curlydoggy thanks for providing the samples but some kind of conversion must have happened since i'm able to stream them to the server without triggering the error:

ffmpeg -stream_loop -1 -re -i sample5.mp4 -c copy -f rtsp rtsp://localhost:8554/p1

2023/08/08 11:03:58 INF [RTSP] [session 3a98f4fd] created by 127.0.0.1:57428
2023/08/08 11:03:58 INF [RTSP] [session 3a98f4fd] is publishing to path 'p1', 1 track (H264)
2023/08/08 11:04:00 INF [HLS] [muxer p1] created (requested by ::1)
2023/08/08 11:04:00 INF [HLS] [muxer p1] is converting into HLS, 1 track (H264)

[1040242795]

关于你提到的非线性增长的问题，我在使用opencv读取rtmp视频流的时候遇到，我尝试去掉音频，发现解决了问题。我的推流代码： ffmpeg -stream_loop -1 -re -i video/21.mp4 -c:v libx264 -s 640x640 -r 30 -an -f flv rtmp://127.0.0.1:1935/live -c 编码格式， -r 帧率 -an 去除音频

[darfink]

I've observed this issue with both OBS 27.2.4 & 29.1.3.

It seems to occur when the following is true:

• OBS x264 Apple Hardware Encoder is used (with B-frames enabled).
• Reading from MediaMTX with RTMP or SRT (and HLS?).

If B-frames are disabled in OBS, it works.

Obviously, the above is not a desired solution since B-frames allows for both higher quality and lower bandwidth.

Since RTSP does not exhibit this issue, I suspect MediaMTX does not properly mux incoming h264 streams with b-frames.

NOTE: I experience no issues when using OBS with HEVC/h265 & B-frames.

EDIT: This might provide a clue as to what's causing the issue: OBS Videotoolbox H264

[VanderBieu]

i was able to reproduce this error on OBS using Apple Hardware encoder h264 ,Apple Software and Hardware encoder hevc. Apple Software encoder h264 worked fine. So it might be something awkward with apple encoder I guess?

[VanderBieu]

i was able to reproduce this error on OBS using Apple Hardware encoder h264 ,Apple Software and Hardware encoder hevc. Apple Software encoder h264 worked fine. So it might be something awkward with apple encoder I guess?

My OBS version is 29.1.3

[xaionaro]

Do I understand correctly this is still an unsolved problem? (and there is even no patch I can apply manually or just an ugly workaround to make it work?)

[foraphe]

Same problem here The problem happens when I relay my SRT video stream encoded using Intel's QSV encoders (both AVC and HEVC) from srt-live-server to MediaMTX. AMD's AMF encoders and software encoders (x264 & x265) work without problems. But when I stream to MediaMTX directly, QSV AVC, both AMF encoders and software encoders work, QSV HEVC still doesn't.

DTS is monotonically increasing for video streams encoded by every encoder listed above, but I do see errors like Packet corrupt (stream = 0, dts = 0), concealing xxx DC, xxx AC, xxx MV errors in I frame(the three values marked xxx are the same), PPS id out of range: 0 and Error parsing NAL unit #1 a few times when I read the AMF or software encoded stream from srt-live-server using ffmpeg. For QSV encoders these errors can last much longer, for a few seconds until ffmpeg starts recognizing the stream. Maybe it's the problem with buffering? I guess that srt-live-server's internal buffer is so small that the first frame(s) in its buffer don't contain enough data to successfully decode (maybe the keyframes required for that frame to decode have been removed from the buffer) and MediaMTX's demuxer doesn't like these corrupted frames, so it refuses to continue.

I have no experience with Golang, but hope these information help.

MediaMTX version: v1.4.2 OBS Studio version: 30.0.2 ffmpeg version: 2023-11-22-git-0008e1c5d5-full_build from gyan.dev Hardware devices used: RDNA2 iGPU for AMF, Xe-HPG for QSV

[carstenwinsnes]

I see the same issue with these settings

OBS 30.0.2 Apple Hardware Encoder B-Frames (enabled)

The issue is resolved when disabling B-Frames (all other settings the same), but given the OBS defaults (enabled B-Frames) this is not ideal. Also as mentioned above, B-Frames have some very nice benefits.

[Ric06]

Hello, I encounter exactly the same errors with an RTMP stream from DJI M30 Drone. Autosave is interrupted every few seconds. I tried with MediaMTX docker versions 1.4.2 and 1.6.0, same results.

MediaMTX LOG: 2024/03/19 12:25:45 INF [path 1581F4BND22B400CTWG1/live2] [record] recording 1 track 2024/03/19 12:25:46 ERR [path 1581F4BND22B400CTWG1/live2] [record] DTS is not monotonically increasing, was 7.935s, now is 7.935s 2024/03/19 12:25:48 INF [path 1581F4BND22B400CTWG1/live2] [record] recording 1 track 2024/03/19 12:25:49 ERR [path 1581F4BND22B400CTWG1/live2] [record] DTS is not monotonically increasing, was 10.938s, now is 10.938s 2024/03/19 12:25:51 INF [path 1581F4BND22B400CTWG1/live2] [record] recording 1 track 2024/03/19 12:25:51 ERR [path 1581F4BND22B400CTWG1/live2] [record] DTS is not monotonically increasing, was 12.971s, now is 12.971s 2024/03/19 12:25:53 INF [path 1581F4BND22B400CTWG1/live2] [record] recording 1 track 2024/03/19 12:25:54 ERR [path 1581F4BND22B400CTWG1/live2] [record] DTS is not monotonically increasing, was 15.946s, now is 15.946s 2024/03/19 12:25:56 INF [path 1581F4BND22B400CTWG1/live2] [record] recording 1 track 2024/03/19 12:25:56 ERR [path 1581F4BND22B400CTWG1/live2] [record] DTS is not monotonically increasing, was 17.982s, now is 17.982s

Recording files: -rw-r--r-- 1 root root 106956 Mar 19 12:25 2024-03-19_12-25-43-939628.mp4 -rw-r--r-- 1 root root 143516 Mar 19 12:25 2024-03-19_12-25-51-930456.mp4 -rw-r--r-- 1 root root 121772 Mar 19 12:25 2024-03-19_12-25-56-950044.mp4 -rw-r--r-- 1 root root 118636 Mar 19 12:25 2024-03-19_12-25-58-968299.mp4 -rw-r--r-- 1 root root 119116 Mar 19 12:26 2024-03-19_12-26-01-935886.mp4 -rw-r--r-- 1 root root 143836 Mar 19 12:26 2024-03-19_12-26-06-954012.mp4 -rw-r--r-- 1 root root 165372 Mar 19 12:26 2024-03-19_12-26-18-955981.mp4 -rw-r--r-- 1 root root 122220 Mar 19 12:26 2024-03-19_12-26-20-977656.mp4 -rw-r--r-- 1 root root 121884 Mar 19 12:26 2024-03-19_12-26-23-946786.mp4

[adriano-peniche]

For situations like @Ric06 mentioned, where the DTS is the same, removing the '=' here, in mediacommon dts_extractor function did the trick. I've tested it, and it doesn't seem to cause any issues with HLS muxing or recording.

[xaionaro]

For situations like @Ric06 mentioned, where the DTS is the same, removing the '=' here, in mediacommon dts_extractor function did the trick. I've tested it, and it doesn't seem to cause any issues with HLS muxing or recording.

Purely mathematically this still will be monotonically increasing. A typo in the code? May be let's do a PR, so that some member of the project will take a look into the fix? (since there are >100 issues, but only 3 PRs).

[rsm-23]

@xaionaro you are right. @aler9 mathematically, the condition mentioned here

dts <= d.prevDTS

is checking for monotonically decreasing instead of strictly monotonically decreasing. Even if dts is equal to d.prevDTS it is still monotonically increasing (mathematically). And as @adriano-peniche has mentioned, I am going to test this out with my use-case (where I am facing this error) and would like to create a PR for this fix.

Update: I tested my use case of saving a video and making that syntactical change actually fixed the issue for me.

[nonibytes]

I came here because I encountered the same problem. The if check should be dts < d.prevDTS, not dts <= d.prevDTS

[aler9]

Hello everyone,

I merged the @xaionaro patch (https://github.com/bluenviron/mediacommon/pull/119) that converts the check from dts <= d.prevDTS to dts < d.prevDTS, since multiple people mentioned that it solve the issue in some cases, but let me explain why this error happens and why the patch won't solve the issue for every possible stream.

MediaMTX has been conceived as a real-time media router - minimizing latency is pivotal, therefore a series of algorithms that require queues or buffers, and are present inside VLC, FFmpeg and GStreamer, cannot be implemented inside the server as they would increase latency.

Each frame of a video stream has two timestamps, DTS and PTS. Some protocols allow to route both of them (MPEG-TS, SRT, UDP, RTMP), others route PTS only (WebRTC and RTSP). Therefore, when a stream is converted from, for instance, RTSP to RTMP, the PTS needs to be filled by scratch since it's not available.

In FFmpeg, PTS is computed by putting frames into a buffer, waiting some time and then increasing it gradually. This is a technique that cannot be replicated here for the reason explained above. In its place, another algorithm was conceived from scratch (https://github.com/bluenviron/mediacommon/blob/main/pkg/codecs/h264/dts_extractor.go), it works by analyzing each H264 unit and extracting the Picture Order Count (POC) field. This is compared with the expected POC (that starts from zero minus the number of B-frames), their difference corresponds to the difference between PTS and DTS. Since we know the DTS, then PTS is obtained.

This algorithm works with about 90% of streams, the problem is that there are some streams that are generated in such a bad way that they declare the wrong number of B-frames, consequently the expected POC is wrong and the DTS is wrong. The DTS is subjected to some coherence checks, and this leads to the error mentioned in this issue.

Therefore, changing the check from strictly monotonically to monotonically won't solve the issue, since in case of a bad stream (like the ones generated through QSV HEVC), the DTS will be computed in a wrong way and will certainly result in a negative DTS difference.

The algorithm can be definitely improved, but at the moment i don't know how to do it. I spent a lot of time reading H264 and H265 specifications and i did not find a better approach.

[aler9]

I think it's better to close this issue since there are a lot of unrelated cases here, some of which have already been fixed, while others are not. If the problem persists, feel free to open other issues, each one dedicated to the specific encoder or hardware.

[mikko-kepit]

That might explain why some encoders have started working with MediaMTX by disabling B-frames.

Can you link or point to more information about issues with QSV HEVC encoding?

[xaionaro]

@aler9 thanks for spending time explaining this. It is an insightful post!

The algorithm can be definitely improved, but at the moment i don't know how to do it. I spent a lot of time reading H264 and H265 specifications and i did not find a better approach.

Might be a stupid thought, but it feels like the best approach would be to enable dependency injection (and make the POC-based bufferless solution as one of the available solutions). People may implement different solutions for different use-cases and few (the most successful ones) will prevail. I'm pretty sure some people would prefer to have a buffer, for example :)

[aler9]

Can you link or point to more information about issues with QSV HEVC encoding?

regarding the QSV HEVC, we discovered that there's a bug inside the SPS parser, discussion is here: #3285

I'm pretty sure some people would prefer to have a buffer, for example :)

absolutely yes, but i'd like to avoid adding an additional option in the configuration file and automatically detect such situations.

[github-actions[bot]]

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.