Live streaming works on Local Network but does not work on Remote Network - Ring Plugin 12.0.0

[JOMA519]

Streaming Issue

I'm hoping you can help me out, please! I can't figure out this issue. I have home bridge all setup on a clean install of Ventura on a Mac mini (wired connection). I can't seem to get my ring doorbell to connect in home view or live view when I'm not on my local area network.

I get the following error in homebridge when I'm trying to access my live stream on my home app using cellular data:
[homebridge-ring] From Ring (Front Door): exited with code 1 and signal null.

Here are my config details:

• node.js version 20.5.1
• npm version 9.8.0
• ring plugin version 12.0.0
• homebridge version 1.6.1
• The ring plug-in is the only thing I'm using in homebridge. All my other devices are HomeKit native.

My MacMini is set to not sleep.

I have reset my two Apple tv's and my two HomePods as some users have said to restart. I've restarted my router.

Any help or suggestions would be greatly appreciated! I have looked at past issues and discussion but there is no clear suggestions on how to fix.

Proposed Solution

I'm guessing the only two options left to try:

• tweaking config.json files?
• possibly opening up ports on router but I have never had to do this before.

Environment

Homebridge

What operating system are you on?

Mac

Relevant log output

No response

Honesty Time

• I swear this is worth your time!

[tsightler]

Other than what is already written in the Wiki page about this, there's not much else to suggest. From the plugin perspective there's no difference between streaming locally vs streaming to a device on LTE as the plugin simply streams to the local home hub and it's up to the home hub to get that data to the client.

You should verify that whatever device you have designated as the Home Hub is definitely working and is on the same network with Home Bridge and that there are no ports being blocked by firewall rules or anything else and that you have no firewalls or VPNs or anything that would impact DNS or UDP traffic.

Note that using Homekit with the Ring plugin over LTE is very demanding on both the local network, due to all of the hops, and on the LTE network itself so it depends on having near perfect network connectivity through the entire path, which is quite complex. In the end, this is all outside of the control of the plugin.

[JOMA519]

Hi, really appreciate the response and getting back to me. I have installed scrypted and the live video stream works perfectly on my 5G cellular connection.

For now, I have hidden the doorbell device if in Homebridge so it doesn’t show up on HomeKit.

I really would prefer not to have use scrypted as I Don’t need hksv features and having another service to maintain. However this will work for now.

This leads me to believe that it is something within the plug-in that needs to be fixed. Not sure if anyone else is experiencing this.

Thank you again for your time.

[GiffelDK]

I am experiencing the same problem, used to work just fine over LTE but now it only works over WiFi, very strange.
Other cameras (non Ring) still work just fine over LTE.

[tsightler]

This leads me to believe that it is something within the plug-in that needs to be fixed. Not sure if anyone else is experiencing this.

Well, I'm not sure how accurate this belief is. Comparing what this plugin does to the advanced capabilities implemented in Scrypted's video pipeline is quite unfair. This plugin simply forwards unmodified video packets from Ring to Homekit, via Homebridge, that is pretty much all of the capabilities it has. Scrypted provides an entire video processing pipeline which has been highly optimized to work across a wide range of devices and network conditions and supports advanced features such as adaptive bitrate negotiation with Homekit.

Of course that doesn't mean that this plugin couldn't be improved, as far as I can tell, Homebridge basically leaves it up to the plugin to implement all advanced features. I spent some time looking at other Homebridge camera plugins, and they pretty much all have people that complain about streaming over LTE/5G, but some plugins have implemented options to try to overcome this.

For example, by far the most sophisticated seems to be the Unifi Protect plugin, which offers a detailed explanation of the issues, as well as several advanced options to try to improve the situation. These options are mostly about doing things like forcing the use of the low quality stream from the camera (Unifi cameras offer three streams of different quality levels/bitrates) or even transcoding to a more optimized stream pattern. You can read the details in the troubleshooting section of that project, which is a good background on Homekit video streaming in general.

This plugin currently has no such options, it negotiates the stream with Ring, and forwards that stream as-is to Homekit, with some audio transcoding where required, and assumes that the network on the other end can deal with it. If it can't, and packets are dropped along the way, then the stream will fail.

Unfortunately, I no longer have a device that can act as a Home Hub or I would look into it myself (it doesn't seem possible to use an iPad as a Home Hub anymore). Maybe I'll look at picking up a Homepod Mini just for development purposes, but, overall, I'd suggest that you should just use the tools that do work.

[JOMA519]

I can definitely appreciate and understand how complex this stuff is. I do appreciate the ring plugin in homebridge as I can use this for my alarm.

I agree with your suggestion and will continue to use Scrypted and HomeKit together.

Thanks again for getting back to me on this and the work that you do. Maybe future updates will be able to support live streaming video for my use case and I would be happy to test out if needed.

[arolnick1]

im having the same issue:
snapshots work on 5g. streaming does not.
Activating stream for Front Door (1.275s)
[9/5/2023, 7:17:37 PM] [Ring] Streaming active for Front Door (1.296s)
[9/5/2023, 7:17:37 PM] [Ring] Received stream data from Front Door (1.299s)
[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): Input #0, sdp, from 'pipe:':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: opus, 48000 Hz, stereo, s16
Stream mapping:
Stream #0:0 -> #0:0 (opus (libopus) -> opus (libopus))

[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): Output #0, rtp, to 'rtp://127.0.0.1:53832?pkt_size=188':
Metadata:
encoder : Lavf59.16.100
Stream #0:0: Audio: opus, 24000 Hz, mono, s16, 24 kb/s
Metadata:
encoder : Lavc59.18.100 libopus
size= 0kB time=00:00:00.00 bitrate=N/A speed= 0x
[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): [rtp @ 000002a9c8a515c0] Packet size 180 too large for max RTP payload size 176
av_interleaved_write_frame(): Invalid argument

[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): size= 0kB time=00:00:00.05 bitrate= 4.2kbits/s speed=3.88x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): Conversion failed!

[9/5/2023, 7:17:37 PM] [Ring] connectionStateChange: closed
[9/5/2023, 7:17:37 PM] [Ring] From Ring (Front Door): exited with code 1 and signal null
[9/5/2023, 7:17:37 PM] [Ring] iceConnectionStateChange: closed
[9/5/2023, 7:17:37 PM] [Ring] Return Audio (Front Door): stopped gracefully
[9/5/2023, 7:17:41 PM] [Ring] Used cached snapshot for Backyard
[9/5/2023, 7:17:41 PM] [Ring]

[tsightler]

@arolnick1 Thanks for including the logs, it is interesting that the error you get is from ffmpeg as it is only used for audio. I wonder if it is caused by the fact that, when requesting a stream over LTE, HomeKit requests 60ms audio frame size instead of 20ms, which causes the RTP packets to be larger.

Currently (and it has been this way for a long time), the ffmpeg output is coded for pkt_size=188, which would be a 176 byte maximum RTP data size, exactly what the error message says. However, I'm thinking that a 60ms frame size might produce packets that are slightly larger than this as the 20ms packets seem to be around 60-70 bytes, so 3x longer frame size might produce packets larger than 176 bytes.

I'm not sure how comfortable you are with editing files directly, but if you can find the Homebridge plugin directory on your system where homebridge-ring is installed, you might try editing the lib/camera-source.js file, on line 209, change the pkt_size=188 with pkt_size=288 and save the file, then restart and see if it helps or if the error message changes.

[arolnick1]

You got it! It works. You’re a great help. Thank you.

…

On Sep 5, 2023, at 8:46 PM, tsightler ***@***.***> wrote: @arolnick1 <https://github.com/arolnick1> Thanks for including the logs, it is interesting that the error you get is from ffmpeg as it is only used for audio. I wonder if it is caused by the fact that, when requesting a stream over LTE, HomeKit requests 60ms audio frame size instead of 20ms, which causes the packets to be larger. Currently (and it has been this way for a long time), the ffmpeg output is coded for pkt_size=188, which would be a 176 byte maximum for RTP packet size, exactly what the error message says. However, I'm thinking that a 60ms might produce packets that are slightly larger than this as the 20ms packets seem to be around 60-70 bytes, so 3x longer frame size might produce packets just larger than this. I'm not sure how comfortable you are with editing files directly, but if you can find the Homebridge plugin directory on your system where homebridge-ring is installed, you might try editing the lib/camera-source.js file, on line 209, change the pkt_size=188 with pkt_size=288 and save the file, then restart and see if it helps or if the error message changes. — Reply to this email directly, view it on GitHub <#1303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A77VP5DLBRVDRJOVS5MKJM3XY7BYHANCNFSM6AAAAAA37TGLNY>. You are receiving this because you were mentioned.

[tsightler]

Great, thanks for providing the logs, that helped a LOT! I'll submit a PR for the next version and perhaps that will help others with this issue as well.

[JOMA519]

arolnick1, thanks for submitting the logs. I wasn't quite sure how to do that.

I will definitely try out the next version when that comes out :).

[tsightler]

@arolnick1 I don't know if you'd be willing to test, but it would be interesting to know if completely removing the ?pkt_size=188 from the end of the URL, vs just changing the value, also works. Part of me thinks we don't need to set this at all.

[tsightler]

You got it! It works. You’re a great help. Thank you.

@arolnick1 One thing I need to ask, while the stream works with this change, does the audio actually work? As I don't currently have any device that can act as a Home Hub I can only fake the request for 60ms audio packets. However, when I do this over my local network, the stream works, but I get no audio. I'm hopeful that this is because Homekit requests 20ms, but I'm forcing the response to 60ms, and it doesn't like this, but honestly, I can't understand why it would be so sensitive, so my worry is that it is breaking audio in all cases.

[arolnick1]

The audio def works from the doorbell pro and the floodlight cam.

…

On Sep 8, 2023, at 1:41 PM, tsightler ***@***.***> wrote: You got it! It works. You’re a great help. Thank you. @arolnick1 <https://github.com/arolnick1> One thing I need to ask, while the stream works with this change, does the audio actually work? As I don't currently have any device that can act as a Home Hub I can only fake the request for 60ms audio packets. However, when I do this over my local network, the stream works, but I get no audio. I'm hopeful that this is because Homekit requests 20ms, but I'm forcing the response to 60ms, and it doesn't like this, but honestly, I can't understand why it would be so sensitive, so my worry is that it is breaking audio in all cases. — Reply to this email directly, view it on GitHub <#1303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A77VP5FYDKB2MBWB7CMZ25LXZNKFFANCNFSM6AAAAAA37TGLNY>. You are receiving this because you were mentioned.

[tsightler]

v12.0.1 has been released which attempts to address this issue. Testing would be appreciated, specifically, does streaming over LTE/5G work, and, assuming it does, are there any issues with audio. If you still have issues, please describe them clearly and also include if you are using bridged or unbridged mode for cameras (they currently use different audio codecs). Basically, this new version updates the Opus audio processing when used via LTE/5G to largely match the audio pipeline used in Scrypted, so hopefully the experience should be similar, at least it seems to fix the ffmpeg crash.

[JOMA519]

Hi @tsightler, version 12.0.1 seems to be working for me on 5G and both video and quality are great. Thank you so much for the updated release!! I’ll keep testing and let you know if I encounter any other issues.

[tsightler]

Thanks for the update @JOMA519, that sounds promising. I'll leave this open for a few more days and see if there are any other reports.

[Interloper156]

Yeah, not working for me I'm afraid. Both HOOBS and Homebridge same error. 'Live stream for Front Cam appears to be inactive'. Only does this when on cellular data, local wifi network fine. 12.0.1.

[tsightler]

@Interloper156 I'm sorry to know that it doesn't work for you but most problems with streaming outside of the local network are not related to the plugin directly. The specific issues discussed here was related to a crash in ffmpeg due to a specific behavior when used over WAN but, that should be fixed in the current release, but, without debug logs, there's not much that can be done for any specific case.

[oliveira131]

I have the same issue. In my case the problem is the -application argument as voip or lowdelay in ffmpeg.

I submitted a change request to the array defined parameters in camera-source.ts.... waiting for revision...
#1316

The change is simple, I attached this patch that you can test if it solves something, just run it (git apply) in /usr/lib/node_modules/homebridge-ring or wherever the directory contains the plugin files.

doorbell-remote_relative.patch

[tsightler]

It's extremely unlikely that #1282 would be related as that is only regarding how homebridge-ring negotiates the WebRTC connection between itself and Ring's media server and that process is the same in call cases.

I would prefer to keep this specific issue focused on the stated problem, vs adding additional problems with no other context, as that just adds confusion. If you are having issues with local streaming I'd ask that you please open a new issue and provide full logs and setup details there vs commenting here.