bluenviron/mediamtx

delay is getting higher and higher

BlockCnFuture opened this issue · 3 comments

BlockCnFuture commented

Which version are you using?

v1.9.0

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

I use webrtc to receive rtsp live stream from mediamtx in browser and finds that the delay is getting higher and higher.

Describe how to replicate the issue

Only use rtsp and api. Except following settings, all other settings are default.
Open two windows in the browser and access http://localhost:8889/my_camera/.

Then I find that the delay is getting larger and larger by time, and the delay in different windows is different. The test found that this problem exists whether local network or public network. When first loaded, it is real-time. As time goes by, the delay becomes larger and larger. The following is the configuration I modified:

webrtcAdditionalHosts: [7.6.1.**8]
webrtcLocalUDPAddress: :3478
webrtcLocalTCPAddress: :3478

paths:
my_camera:
source: rtsp://admin:******@192.168.3.33:554/Streaming/Channels/1?transportmode=unicast

img

Did you attach the server logs?

C:\Users\sswoc\Downloads\mediamtx_v1.9.0_windows_amd64>mediamtx mediamtx.yml
2024/09/11 19:54:13 INF MediaMTX v1.9.0
2024/09/11 19:54:13 INF configuration loaded from C:\Users\sswoc\Downloads\mediamtx_v1.9.0_windows_amd64\mediamtx.yml
2024/09/11 19:54:13 INF [path my_camera] [RTSP source] started
2024/09/11 19:54:13 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2024/09/11 19:54:13 INF [WebRTC] listener opened on :8889 (HTTP), :3478 (ICE/UDP), :3478 (ICE/TCP)
2024/09/11 19:54:13 INF [API] listener opened on 0.0.0.0:9997
2024/09/11 19:54:13 INF [path my_camera] [RTSP source] ready: 2 tracks (H264, G711)
2024/09/11 19:54:42 INF [WebRTC] [session 40b30118] created by ...:2964
2024/09/11 19:54:42 INF [WebRTC] [session 40b30118] peer connection established, local candidate: host/udp/..1*.1*/3478, remote candidate: prflx/udp/192.168.3.16/58934
2024/09/11 19:54:42 INF [WebRTC] [session 40b30118] is reading from path 'my_camera', 2 tracks (H264, G711)
2024/09/11 19:57:45 INF [WebRTC] [session b18fb645] created by [::1]:52105
2024/09/11 19:57:45 INF [WebRTC] [session b18fb645] peer connection established, local candidate: host/udp/.1.1*.14*/3478, remote candidate: prflx/udp/192.168.3.25/59439
2024/09/11 19:57:45 INF [WebRTC] [session b18fb645] is reading from path 'my_camera', 2 tracks (H264, G711)
2024/09/11 19:57:51 INF [WebRTC] [session 15f9b1bb] created by [::1]:52105
2024/09/11 19:57:51 INF [WebRTC] [session 15f9b1bb] peer connection established, local candidate: host/udp/192.168.3.25/3478, remote candidate: prflx/udp/192.168.3.25/51225
2024/09/11 19:57:51 INF [WebRTC] [session 15f9b1bb] is reading from path 'my_camera', 2 tracks (H264, G711)
2024/09/11 19:57:57 INF [WebRTC] [session b18fb645] closed: peer connection closed

yes

Did you attach a network dump?

no

moenodedev commented

Were the correct images attached? The screenshots show port 8888 which is HLS.

aler9 commented

This is related to HLS, not to WebRTC or RTSP, and is caused by the fact that browsers automatically pause videos when their window is in the background or minimized. When the video is resumed, playback is resumed from the last rendered frame, not from the current time.

github-actions commented

This issue is mentioned in release v1.9.1 🚀
Check out the entire changelog by clicking here