Arlo RTSP streams die after 10 seconds

[brianschrameck]

Which version are you using?

v0.21.1

Which operating system are you using?

• [ ] Linux amd64 standard
• [x] 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 am trying to proxy an RTSP stream from an Arlo Pro 2 camera to Scrypted. Normally these cameras expect to connect to an Arlo base station, but I have them connected instead to my normal WiFi and am running a reverse engineered base station using https://github.com/Meatballs1/arlo-cam-api.

When connecting using Scrypted directly to the cameras, I am able to stream successfully using UDP for any amount of time. However, audio doesn't work.

When sticking the camera behind a proxy via rtsp-simpler-server, audio and video works but stops after approximately 10 seconds. This occurs using either UDP or TCP from Scrypted to the proxy.

VLC shows the same behavior, but keeps retrying the connection and eventually reconnects.

Apparently these cameras want RTCP responses very often and will kill the stream if they don't get them. It's not clear how often RTCP responses are sent back to the camera from the proxy, or if they are even being sent at all as I don't see anything in the logs.

If it matters, my cameras are on a separate VLAN, but firewall is open between the two for the cameras right now.

I also noticed that the cameras request port 0 on the server, so wondering if that might be tripping things up at all. I know that when enabling audio on Scrypted I get an error with port 0 being specified.

Describe how to replicate the issue

This is very likely an issue specific to the Arlo hardware, but here is the config I am using:

1. start the server with the following proxy config:

   paths:
   deck:
   source: rtsp://192.168.3.148/live
   sourceOnDemand: yes
   sourceAnyPortEnable: yes

2. Connect to the stream using RTSP client of your choice.
3. Observe the stream being closed around 10 seconds in.

Did you attach the server logs?

yes

Did you attach a network dump?

no

[brianschrameck]

Looks like this is a problem with whatever RTSP parser is being used by the server (I'm guessing ffmpeg?).

Was able to get this working using gstreamer:

  driveway:
    runOnDemand: gst-launch-1.0 rtspsrc location=rtsp://192.168.3.152/live name=arlo latency=0
      arlo. ! rtph264depay ! queue ! scrypted.sink_0
      arlo. ! rtpmp4gdepay ! queue ! scrypted.sink_1
      arlo. ! rtpopusdepay ! queue ! scrypted.sink_2
      rtspclientsink location=rtsp://192.168.1.72:8554/driveway name=scrypted
    runOnDemandRestart: yes

[aler9]

Hello, the RTSP parser is written from scratch, there's no FFmpeg. This issue may be solved if you provide:

1) a server log with logLevel: debug

2) a network dump, that can be generated in this way:

1) Download wireshark (https://www.wireshark.org/) 2) Start capturing on the interface used for exchanging RTSP (if the server and the target software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card) 3) Start the server and replicate the issue 4) Stop capturing, save the result in .pcap format 5) Attach

[aler9]

Apparently these cameras want RTCP responses very often and will kill the stream if they don't get them. It's not clear how often RTCP responses are sent back to the camera from the proxy, or if they are even being sent at all as I don't see anything in the logs.

RTCP receiver reports are sent only when protocol is UDP and at a fixed interval of 10 seconds.

[brianschrameck]

RTCP receiver reports are sent only when protocol is UDP and at a fixed interval of 10 seconds.

That's exactly what's happening then, this makes a lot of sense. It's the same problem FFmpeg runs into. Other clients like VLC and GStreamer don't send RTCP at all and these cameras happily chug along indefinitely without any RTCP, but once they receive RTCP they must expect to receive them at very regular intervals. How often, I'm not sure.

I haven't looked at the code, but assuming it's just on a simple timer I'm going to try adjusting the RTCP interval and see what happens.

[aler9]

The interval is defined here:

https://github.com/aler9/gortsplib/blob/9b14285018bc737d1abb5f02118ceab3b1171609/client.go#L329

But since you mentioned that GStreamer is able to pull the stream correctly, i'd like to find out how GStreamer does that in order to integrate the feature into the server. In order to do that, we need a network dump.

[brianschrameck]

It actually looks like the camera is killing the connection the second it receives any RTCP at all. Attached a pcap from rtsp-simple-server. rtspss-arlo.pcap.zip

[brianschrameck]

i'd like to find out how GStreamer does that in order to integrate the feature into the server

GStreamer doesn't send any RTCP, do you still want the capture for it anyway?

[aler9]

GStreamer usually sends RTCP reports, otherwise it couldn't work with most cameras. Furthermore, from the network dump you provided, it seems that it's the server that tears down the connection, not the camera.

Please provide

1. a network dump of the communication between GStreamer and the camera
2. a server log with logLevel: debug

[brianschrameck]

Attached. You're right, I do see the RR here with GStreamer around 10 seconds. Missed it the first time I looked at a tcpdump. gstreamer.zip

[aler9]

@brianschrameck the main difference between the server log and the GStreamer log is that the server writes RTCP reports with a period of 10 seconds, while GStreamer writes them with a period of 5 seconds.

The 5 secs period is the default one:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/rtpmanager/gstrtpsession.c#L219 https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/rtpmanager/rtpstats.h#L189

(RTP_STATS_MIN_INTERVAL * GST_SECOND) = 5 * GST_SECONDS

We can lower the RTCP report period of the server to 5 secs.

Just one thing, can you attach a server log with this configuration?

logLevel: debug
paths:
  behindGarage:
    source: rtsp://original-url

You attached a server log with runOnInit, and i can't explain why the server sends the TEARDOWN request before the connection is closed.

[brianschrameck]

Attached, sorry for the delay. capture.zip

[aler9]

i've finally understood why the server sends a TEARDOWN request: the camera suddenly stops sending packets, and after 10 seconds the server detects a timeout and closes the connection.

here's a nightly release of the server with interval between RTCP reports lowered to 5 seconds. Please test it and let me know if it solves the issue. [link removed]

[keeppy]

While sending RTSP RECORD stream with my android client There are disconnection errors after connected.

mediamtx-0.21.5 ~ mediamtx-0.22.0 ==> error

2023/04/10 12:13:30 INF rtsp-simple-server 2023/04/10 12:13:30 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP) 2023/04/10 12:13:30 INF [RTMP] listener opened on :1935 2023/04/10 12:13:30 INF [HLS] listener opened on :8888 2023/04/10 12:13:30 INF [WebRTC] listener opened on :8889 (HTTP) 2023/04/10 12:13:38 INF [RTSP] [conn 39.7.230.208:45944] opened 2023/04/10 12:13:38 INF [RTSP] [session 1eff0010] created by 39.7.230.208:45944 2023/04/10 12:13:38 INF [RTSP] [conn 39.7.230.208:45944] closed (connection is linked to another session) 2023/04/10 12:13:38 INF [RTSP] [session 1eff0010] destroyed (not in use) 2023/04/10 12:13:43 INF [RTSP] [conn 39.7.230.208:45946] opened 2023/04/10 12:13:43 INF [RTSP] [session 958e4acd] created by 39.7.230.208:45946 2023/04/10 12:13:43 INF [RTSP] [conn 39.7.230.208:45946] closed (connection is linked to another session) 2023/04/10 12:13:43 INF [RTSP] [session 958e4acd] destroyed (not in use) 2023/04/10 12:13:49 INF [RTSP] [conn 39.7.230.208:45948] opened 2023/04/10 12:13:50 INF [RTSP] [session b8dcff7c] created by 39.7.230.208:45948 2023/04/10 12:13:50 INF [RTSP] [conn 39.7.230.208:45948] closed (connection is linked to another session) 2023/04/10 12:13:50 INF [RTSP] [session b8dcff7c] destroyed (not in use) 2023/04/10 12:14:02 INF [RTSP] [conn 39.7.230.208:45950] opened 2023/04/10 12:14:02 INF [RTSP] [session 9e11d2ce] created by 39.7.230.208:45950 2023/04/10 12:14:02 INF [RTSP] [conn 39.7.230.208:45950] closed (connection is linked to another session) 2023/04/10 12:14:02 INF [RTSP] [session 9e11d2ce] destroyed (not in use)

mediamtx-0.21.4 ==> OK

2023/04/10 12:23:32 INF rtsp-simple-server 2023/04/10 12:23:32 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP) 2023/04/10 12:23:32 INF [RTMP] listener opened on :1935 2023/04/10 12:23:32 INF [HLS] listener opened on :8888 2023/04/10 12:23:44 INF [RTSP] [conn 39.7.230.208:45952] opened 2023/04/10 12:23:44 INF [RTSP] [session 46e51228] created by 39.7.230.208:45952 2023/04/10 12:23:44 INF [RTSP] [session 46e51228] is publishing to path 'stream1', with TCP, 2 tracks (H264, MPEG4-audio)

[brianschrameck]

i've finally understood why the server sends a TEARDOWN request: the camera suddenly stops sending packets, and after 10 seconds the server detects a timeout and closes the connection.

here's a nightly release of the server with interval between RTCP reports lowered to 5 seconds. Please test it and let me know if it solves the issue.

This build works for me!

[aler9]

FIxed in v0.23.0

[github-actions[bot]]

This issue is being locked automatically because it has been closed for more than 6 months. Please open a new issue in case you encounter a similar problem.