Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delay is getting higher and higher #3759

Closed
1 of 13 tasks
BlockCnFuture opened this issue Sep 11, 2024 · 3 comments · Fixed by #3772
Closed
1 of 13 tasks

delay is getting higher and higher #3759

BlockCnFuture opened this issue Sep 11, 2024 · 3 comments · Fixed by #3772
Labels
bug Something isn't working hls

Comments

@BlockCnFuture
Copy link

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
Copy link

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

@aler9 aler9 added bug Something isn't working hls labels Sep 15, 2024
@aler9
Copy link
Member

aler9 commented Sep 15, 2024

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.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working hls
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants