You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR: Publish several paths dynamically into mediamtx and try load them in a single webpage at the same time using iframes and MediaMTX's webrtc webpage.
Description:
I am encountering an intermittent issue where some RTSP camera streams fail to load in the browser via WebRTC. This seems to happen randomly.
My Setup:
User Interaction: A user selects one or more RTSP cameras to view.
Dynamic Path Publishing: For each selected camera, a unique ID is generated, and a new path is published to MediaMTX using the REST API. This dynamic publishing is a requirement, as paths cannot be pre-defined.
Browser Display: A grid (matrix) is displayed in the browser. Each cell in the grid contains an <iframe> that loads the MediaMTX WebRTC player page for a specific camera stream (e.g., http://mediamtx-server/mystream_unique-id).
Expected Behavior:
All selected camera streams should load and play successfully in their respective iframes with low latency.
Actual Behavior:
Most of the time, the setup works perfectly. However, intermittently, one or more camera streams fail to load. There's no discernible pattern to these failures; sometimes it rarely occurs, other times it might happen for multiple streams consecutively.
This issue occurs even when MediaMTX and the browser are running on the same machine, suggesting it's unlikely to be related to STUN/TURN server configurations or general network issues between client/server.
Client-Side:
No JavaScript console errors are observed in the browser when a stream fails to load.
Server-Side (MediaMTX):
When a stream fails to load, the only logs available are similar to:
[WebRTC] [session <session_id>] closed: deadline exceeded while waiting connection
I have attached MediaMTX server logs (set to debug level) with confidential information (IPs, credentials) redacted. Due to the confidential nature of the data, providing a network dump is not feasible at this time.
My two cents would be that this might be related to some kind of race condition in MediaMTX's webrtc server.
Uh oh!
There was an error while loading. Please reload this page.
Which version are you using?
1.12.2
Which operating system are you using?
Linux amd64 standard
Describe how to replicate the issue
TL;DR: Publish several paths dynamically into mediamtx and try load them in a single webpage at the same time using iframes and MediaMTX's webrtc webpage.
Description:
I am encountering an intermittent issue where some RTSP camera streams fail to load in the browser via WebRTC. This seems to happen randomly.
My Setup:
Expected Behavior:
All selected camera streams should load and play successfully in their respective iframes with low latency.
Actual Behavior:
Most of the time, the setup works perfectly. However, intermittently, one or more camera streams fail to load. There's no discernible pattern to these failures; sometimes it rarely occurs, other times it might happen for multiple streams consecutively.
This issue occurs even when MediaMTX and the browser are running on the same machine, suggesting it's unlikely to be related to STUN/TURN server configurations or general network issues between client/server.
Client-Side:
No JavaScript console errors are observed in the browser when a stream fails to load.
Server-Side (MediaMTX):
When a stream fails to load, the only logs available are similar to:
[WebRTC] [session <session_id>] closed: deadline exceeded while waiting connection
I have attached MediaMTX server logs (set to debug level) with confidential information (IPs, credentials) redacted. Due to the confidential nature of the data, providing a network dump is not feasible at this time.
My two cents would be that this might be related to some kind of race condition in MediaMTX's webrtc server.
Server logs
mediamtx-logs.txt
Network dump
No response
The text was updated successfully, but these errors were encountered: