muxer error: DTS is not monotonically increasing #1002
Comments
|
Hello, this is camera-specific, you have to provide either a working RTSP URL or a video sample. |
|
It is a private hls stream. How do I upload a video sample? |
|
Just checking on this error, can this be fixed. |
|
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). |
|
Ok sure. Here is a sample that has incorrect dts. |
|
The file you provided makes the muxer close with error |
|
Here found the perfect stream with the error. http://170.178.189.66:1935/live/Stream1/playlist.m3u8 This should help you. |
|
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: This is my video captured from nginx rtmp gateway: Video info by ffmpeg: |
|
I appear to be having a similar error. I am publishing a rtmp stream from OBS and trying to watch it HLS. 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?
|
|
I am also having this issue also with https. Any ideas on how to fix? |
|
I too am experiencing this muxer error. All is well in |
|
Ah yeah setting Encoder to Software (x264) in OBS has fixed this for me. Thanks @FlantasticDan |
|
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. |
|
Can confirm this issue as well, even on |
|
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. |
|
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 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.... |
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. |
|
I am occasionally seeing this with a LL-HLS proxy on a stream that's been going for some hours to a Chrome browser. 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 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: HLS and path config section on proxy |
|
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. |
|
@aler9 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 |
|
@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: |
aler9
changed the title
|
关于你提到的非线性增长的问题，我在使用opencv读取rtmp视频流的时候遇到，我尝试去掉音频，发现解决了问题。我的推流代码： |
|
I've observed this issue with both OBS It seems to occur when the following is true:
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 |
|
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 |
|
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?) |
|
Same problem here DTS is monotonically increasing for video streams encoded by every encoder listed above, but I do see errors like I have no experience with Golang, but hope these information help. MediaMTX version: v1.4.2 |
|
I see the same issue with these settings OBS 30.0.2 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. |
|
Hello, MediaMTX LOG: Recording files: |
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). |
|
@xaionaro you are right. @aler9 mathematically, the condition mentioned here dts <= d.prevDTSis checking for Update: I tested my use case of saving a video and making that syntactical change actually fixed the issue for me. |
|
I came here because I encountered the same problem. The |
Foe some reason in the code the monotonical increasing did forbid having the same value as before, while purely mathematical definition of a "monotonical increasing" does allow to have the same value. Fixing it. ITS: bluenviron/mediamtx#1002 Signed-off-by: Dmitrii Okunev <xaionaro@dx.center>
Foe some reason in the code the monotonical increasing did forbid having the same value as before, while purely mathematical definition of a "monotonical increasing" does allow to have the same value. Fixing it. ITS: bluenviron/mediamtx#1002 Signed-off-by: Dmitrii Okunev <xaionaro@dx.center>
|
Hello everyone, I merged the @xaionaro patch (bluenviron/mediacommon#119) that converts the check from 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. |
|
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. |
|
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? |
|
@aler9 thanks for spending time explaining this. It is an insightful post!
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 :) |
regarding the QSV HEVC, we discovered that there's a bug inside the SPS parser, discussion is here: #3285
absolutely yes, but i'd like to avoid adding an additional option in the configuration file and automatically detect such situations. |
|
This issue is being locked automatically because it has been closed for more than 6 months. |
and others
Which version are you using?
v0.19.2
Which operating system are you using?
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
Did you attach the server logs?
no
Did you attach a network dump?
no
The text was updated successfully, but these errors were encountered: