Open wolverin-a opened 6 months ago
I looked at the statistics through ffprobe: data comes directly from the camera evenly, through the mediamtx with pauses and accelerations
since the situation is hopeless, I decided to post rtsp links, maybe this will help
From the camer over Nat-router rtsp://94.31.247.14:5541/cam
From the mediamtx rtsp://593358:Zlbl9NMh96@87.249.58.76:10502/02c00081491be26a
updated to version 1.8.1, for which "h264: support 4K videos encoded with tune=zerolatency" and "various performance improvements" are specified, but there is no difference
Hi! I'm experiencing similar issues with version 1.8.3 on amd64 running in a Docker container.
I'm pushing 4 video streams from ffmpeg to mediamtx, using RTSP in TCP mode, and consuming the streams over HLS and WebRTC.
Interestingly, I'm pushing from localhost in this test, so I'm really wondering where the packets get lost 😅
I'll keep testing and hopefully have more to report later.
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [conn [::1]:55070] opened
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [conn [::1]:55078] opened
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [conn [::1]:55068] opened
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [conn [::1]:55080] opened
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 72bb2d3a] created by [::1]:55068
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 1e6c8c87] created by [::1]:55080
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 675053b5] created by [::1]:55070
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 72bb2d3a] is publishing to path 'live/stream1', 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream1] created automatically
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream1] is converting into HLS, 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 1e6c8c87] is publishing to path 'live/stream3', 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream3] created automatically
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream3] is converting into HLS, 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session 675053b5] is publishing to path 'live/stream2', 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream2] created automatically
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream2] is converting into HLS, 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session d6695592] created by [::1]:55078
mediamtx-1 | 2024/06/19 07:42:43 INF [RTSP] [session d6695592] is publishing to path 'live/stream4', 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream4] created automatically
mediamtx-1 | 2024/06/19 07:42:43 INF [HLS] [muxer live/stream4] is converting into HLS, 2 tracks (Opus, H264)
mediamtx-1 | 2024/06/19 07:42:45 INF [WebRTC] [session e2f829b2] created by 127.0.0.1:59868
mediamtx-1 | 2024/06/19 07:42:45 INF [WebRTC] [session e2f829b2] peer connection established, local candidate: host/udp/192.168.39.1/8189, remote candidate: prflx/udp/10.0.0.23/52514
mediamtx-1 | 2024/06/19 07:42:45 INF [WebRTC] [session e2f829b2] is reading from path 'live/stream1', 2 tracks (H264, Opus)
mediamtx-1 | 2024/06/19 07:44:48 WAR [RTSP] [session 72bb2d3a] 11 RTP packets lost
mediamtx-1 | 2024/06/19 07:44:48 WAR [RTSP] [session 675053b5] 8 RTP packets lost
mediamtx-1 | 2024/06/19 07:45:07 WAR [RTSP] [session 72bb2d3a] 5 RTP packets lost
mediamtx-1 | 2024/06/19 07:45:07 WAR [RTSP] [session 675053b5] 3 RTP packets lost
mediamtx-1 | 2024/06/19 07:45:08 WAR [RTSP] [session 1e6c8c87] 3 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:17 WAR [RTSP] [session 72bb2d3a] 30 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:17 WAR [RTSP] [session 675053b5] 22 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:18 WAR [RTSP] [session 1e6c8c87] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:48:29 WAR [RTSP] [session 72bb2d3a] 3 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:30 WAR [RTSP] [session 1e6c8c87] 2 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:31 WAR [RTSP] [session 72bb2d3a] 7 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:32 WAR [RTSP] [session 675053b5] 8 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:32 WAR [RTSP] [session 1e6c8c87] 6 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:33 WAR [RTSP] [session 72bb2d3a] 11 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:34 WAR [RTSP] [session 675053b5] 9 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:34 WAR [RTSP] [session 1e6c8c87] 7 RTP packets lost
mediamtx-1 | 2024/06/19 07:48:37 WAR [RTSP] [session 72bb2d3a] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:48:38 WAR [RTSP] [session 675053b5] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:48:53 WAR [RTSP] [session 72bb2d3a] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:48:54 WAR [RTSP] [session 675053b5] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:48:54 WAR [RTSP] [session 1e6c8c87] 1 RTP packet lost
mediamtx-1 | 2024/06/19 07:50:57 WAR [RTSP] [session 72bb2d3a] 65 RTP packets lost
mediamtx-1 | 2024/06/19 07:50:57 WAR [RTSP] [session 675053b5] 17 RTP packets lost
mediamtx-1 | 2024/06/19 07:51:33 WAR [RTSP] [session 72bb2d3a] 10 RTP packets lost
mediamtx-1 | 2024/06/19 07:52:02 WAR [RTSP] [session 72bb2d3a] 24 RTP packets lost
mediamtx-1 | 2024/06/19 07:54:13 WAR [RTSP] [session 1e6c8c87] 16 RTP packets lost
mediamtx-1 | 2024/06/19 07:54:13 WAR [RTSP] [session 72bb2d3a] 10 RTP packets lost
mediamtx-1 | 2024/06/19 07:54:13 WAR [RTSP] [session 675053b5] 10 RTP packets lost
mediamtx-1 | 2024/06/19 07:54:14 WAR [RTSP] [session d6695592] 12 RTP packets lost
mediamtx-1 | 2024/06/19 07:57:14 WAR [RTSP] [session 72bb2d3a] 18 RTP packets lost
mediamtx-1 | 2024/06/19 07:57:14 WAR [RTSP] [session 675053b5] 20 RTP packets lost
mediamtx-1 | 2024/06/19 07:57:15 WAR [RTSP] [session 1e6c8c87] 3 RTP packets lost
mediamtx-1 | 2024/06/19 07:57:15 WAR [RTSP] [session d6695592] 13 RTP packets lost
mediamtx-1 | 2024/06/19 07:59:08 WAR [RTSP] [session 72bb2d3a] 13 RTP packets lost
mediamtx-1 | 2024/06/19 07:59:11 WAR [RTSP] [session 72bb2d3a] 15 RTP packets lost
mediamtx-1 | 2024/06/19 07:59:28 WAR [RTSP] [session 72bb2d3a] 71 RTP packets lost
We see the same issue with RTSP proxy on version 1.8.3. We would provide logs but they only say "RTP packets lost"
I've done a bit of digging. I was wondering where that error message came from. It seems to be generated in gortsplib, more specifically here - which surprised me, because this seems to be when using UDP, and I thought I was using TCP.
It turns out that I was using the wrong ffmpeg
flags (I'm using tee
, and I therefore had to specify the rtsp_transport=tcp
flag within the tee
output block).
Now that I'm using TCP, the issue disappeared and I don't have frame corruption and hiccups anymore.
So if you can switch to TCP, I obviously recommend it, it'll fix that issue :)
If you have to use UDP, unfortunately I haven't found a fix, sorry!
... I wanted to try and help others, so I switched back to UDP to reproduce the issue.
Then, I identified the socket to which the RTP packets were sent (with tcpdump -peni any udp
- warning, this generates a lot of output). Apparently it's on UDP port 8000:
17:42:04.704718 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 1540: ::1.22014 > ::1.8000: UDP, length 1472
17:42:04.704727 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 1540: ::1.26900 > ::1.8000: UDP, length 1472
17:42:04.704727 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 1540: ::1.22014 > ::1.8000: UDP, length 1472
17:42:04.704734 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 1540: ::1.22014 > ::1.8000: UDP, length 1472
17:42:04.704736 lo In ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 1540: ::1.26900 > ::1.8000: UDP, length 1472
I tried to use ss
to find that socket; unfortunately it didn't work (perhaps because I'm running MediaMTX in a container). Instead, I checked /proc/net/udp
(no match) and /proc/net/udp6
(match!). This file has port numbers in hexadecimal; port 8000 is 1F40
and indeed I had a line like that one:
$ grep 1F40 /proc/net/udp6
10893: 00000000000000000000000000000000:1F40 00000000000000000000000000000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 28483833 2 0000000039f8d5d2 4398
The last value is the number of drops (probably because the receive buffer wasn't big enough).
I checked the value of net.core.rmem_max
(the default value for all receive buffers of all kinds) and it was 256 KiB. I increased it to 100MB with sysctl net.core.rmem_max=100000000
, restarted MediaMTX, and then the problem was gone - no more RTP packet lost.
Certainly, a 100MB receive buffer might be a bit excessive, but I wanted to check if this would help or not - and clearly, it did!
Don't forget to restart MediaMTX after increasing the sysctl value, and of course, make sure that you set that sysctl value permanently so that it persists across reboots.
That being said, it's likely that the issue reported by @wolverin-a is different, alas (since their receive buffer was already 16 MiB apparently).
I hope that will still help others!
Which version are you using?
v1.8.0
Which operating system are you using?
Debian 10 amd64 E3-1230v5, 32 GB RAM WAN 1000 mBit/s
Describe the issue
Hello. I'm using your app as a video proxy. All paths are added via the API.
Describe how to replicate the issue
But additionally, I specified the following parameters in the configuration file
and added in /etc/sysctl.conf
Did you attach the server logs?
yes
But it still causes the loss of RTP packets and sometimes I see it in the logs
iptraf on an interface that deals only with video proxies
Did you attach a network dump?
yes
on proxy (iphost) with mediamtx 10502 to my vlc 60515 network card MTU 1500