RTSP Streaming Issue From UniFi Protect

Since the ability to add custom channels was added I have been using that feature to view my security cameras (UniFi Protect) from my TVs - this worked great up until the Protect 2.0 version was released and since then it's been very problematic. When accessing any camera's stream from the guide the image will come up frozen with a spinner on screen in the timeline for about 5 minutes then it will play the delayed stream for some time before the image freezes. I have tried disabling the RTSP stream for a camera and re-creating it, changing the frame rate and quality but nothing helps. I would reach out to Ubiquiti but the RTSP stream will play without issue in any other player I throw at it. I looked for others who might have had this issue on here but found none and can't imagine I am the only one but maybe so.

The following is in the diagnostic logs when I try to stream a camera.

2022/07/15 12:34:42.341135 [TNR] Opened connection to M3U-Cameras for ch1000 Kevin’s Driveway
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22493, current: 3749; changing to 22494. This may result in incorrect timestamps in the output file.
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22494, current: 7498; changing to 22495. This may result in incorrect timestamps in the output file.
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22495, current: 11247; changing to 22496. This may result in incorrect timestamps in the output file.
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22496, current: 14996; changing to 22497. This may result in incorrect timestamps in the output file.
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22497, current: 18745; changing to 22498. This may result in incorrect timestamps in the output file.
2022/07/15 12:34:43.774418 [HLS] ffmpeg: rtsp-1000:  [mpegts @ 0000000001bde5c0] Non-monotonous DTS in output stream 0:0; previous: 22498, current: 22494; changing to 22499. This may result in incorrect timestamps in the output file.
2022/07/15 12:36:46.738741 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] max delay reached. need to consume packet
2022/07/15 12:36:46.741648 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] RTP: missed 2 packets
2022/07/15 12:38:38.747381 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] max delay reached. need to consume packet
2022/07/15 12:38:38.753544 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] RTP: missed 12 packets
2022/07/15 12:39:26.698993 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] max delay reached. need to consume packet
2022/07/15 12:39:26.698993 [HLS] ffmpeg: rtsp-1000:  [rtsp @ 00000000012824c0] RTP: missed 1 packets

Submitted diagnostic 809407fa-46b4-4f7f-bfdb-9084334810c6

1 Like

Same experience. Thought it was me. Thank you for posting

1 Like

When Protect 2.0 was released, the RTSP feeds were changed to default to RTSPS, which few third-party apps support. If you go to the Settings > Advanced section for the camera in the Protect web UI, you will see something like:

rtsps://10.0.1.1:7441/GZ8f5xlnRjB8P577?enableSrtp

To get the regular RTSP address to use, you need to change it to:

rtsp://10.0.1.1:7447/GZ8f5xlnRjB8P577

(This is just an example from my own Protect setup. Substitute your Protect's IP address and cameras' endpoint as appropriate. Note the change in protocol and port, as well as the removal of the query parameter in the URL.)

Also note: the Protect 2.x application uses different audio codecs than 1.x; even though the new codecs used are part of the RTSP standard, not all third-party apps support them. I am not sure if Channels does, as I use Homebridge to get my cameras and doorbell on the TV instead of creating a Custom Channel for them.

I should have said in my original post but I did know about this and have updated my RTSP links some time ago, they would fail immediately had not. Thanks for pointing it out though.

I did a quick-and-dirty test with one of my cameras, and experienced the same as you (frozen image and constant spinner). I believe this is related to the audio codec changes with Protect 2.x, but would need to check out the logs more to see.

Have you submitted diagnostic logs after trying to access a camera on a client? That would probably be the best option for trying to narrow down what is actually happening.

I did, noted it above at the end of my post. Glad you were able to confirm it as well, feeling a little less crazy now :slight_smile: .

1 Like

Same issue here. Following along.
Thought it was just me as well. :slight_smile:
Thanks for posting.

If it helps a developer that might come along this is what the stream looks like in VLC..
image

@maddox @tmm1 Any help for us? :slight_smile:

Same – when I try to stream it looks like it's caching more and more video (minutes!) but never the audio. Maybe the problem is the audio codec causing Channels DVR to just wait "forever" for audio that's never coming?

Short of the developers responding and possibly fixing this issue with the audio codec any work around ideas? Was wondering if I could feed the camera stream through something else to transcode it..

@kevnel1 are you using Apple TV clients? If so you are probably better off installing Scrypted and add have them available as Homekit cameras. This way you can just say "show me the back yard camera" and have it pop up on screen at any time.

Rather than Scrypted, Homebridge + homebridge-unifi-protect is quite awesome. It fully integrates with HomeKit, including secure video, doorbell notifications, two-way audio, etc ... As an added bonus, you can run it directly on the UDM/NVR.

Possible fix in next DVR build

1 Like

Scrytped offers the same functionality, I've tried both and prefer Scrypted myself.

Not my video but it is accurate...

Still having the same issue after upgrading to that release. Diagnostic submitted: 4826e311-b872-492e-b347-f6072b4d72b6

I have this setup but the TV I want to watch from does not have an AppleTV attached.

Did you also update to the latest beta version of the Android TV/Fire TV device?

I did not, good catch! It IS working now!

3 Likes