Steaming fails with ffmpeg exit code 0 about homebridge-unifi-protect

[ChadHydro]

And of course, thanks for the awesome plugin!

[erictaylor]

I just tested with my AppleTV 4k on tvOS 14 beta and found that a 1920x1080 stream is requested and works perfectly fine with no issues when Enable.StreamOnly.Low is set. However, the stream fails to load when that setting is missing.

[hjdhjd]

Thanks for the compliments...alright, let's troubleshoot this. Let's start with disable two-way audio on the doorbell.

Set the Disable.TwoWayAudio feature option. If we can get the doorbell working as a camera first, then we can look into getting two-way audio working.

Also...I assume you meant a UDM-Pro, not a UDM above, correct? I don't believe Protect exists for UDM.

[ouchkilljoys]

Seeing the same issue on my side

Setup includes

• iOS device on iOS 14 Beta 6
• Unifi Cloud Key Gen 2+
• Unraid running HomeBridge in a docker container

Error I receive

[UniFi Protect] Doorbell: HomeKit video stream request received: 1280x720, 30 fps, 299 kbps.
[UniFi Protect] Doorbell: ffmpeg exited with code: 0 and signal: null (Error)

[UniFi Protect] Doorbell: Stopped video stream.

If i set the option
Enable.StreamOnly.Low
Stream works fine

[erictaylor]

I do in fact mean a UDM Pro.

I set Disable.TwoWayAudio and:

1. iOS fails to load stream and timeout happens after 30 seconds. No ffmpeg error!
2. Home app via macOS fails to load stream and timeout happens after 30 seconds. No ffmpeg error.
3. tvOS fails to load stream, timeout after 30 seconds. No ffmpeg error.

tvOS requested 1920x1080, other two requested 1280x720.

Will report back adding Enable.StreamOnly.Medium and Low results with Disable.TwoWayAudio also enabled.

TLDR; Still now streaming, but Disable.TwoWayAudio has stopped the ffmpeg error.

[hjdhjd]

Please try the settings I suggested above and report back. We'll track this down.

Also - did you have this issue in the last version?

[erictaylor]

Results of Disabled.TwoWayAudio and Enable.StreamOnly.Medium:

• iOS (v13.6.1) - Stream take a 3-4 seconds to load, no errors, no freezing! (720 requested).
• Home app on macOS - Steam takes 3-4 seconds to load, no errors, no freezing! (720 requested).
• tvOS (v14 beta) - Stream only takes 1-2 seconds to load, no errors, no freezing! (1080 requested).

---

Also - did you have this issue in the last version?

Do you mean the plugin version? I'm currently on [email protected].

[hjdhjd]

@erictaylor Appreciate the info...but let’s slow things down and only test on one platform. If it works on one, it should work on all. That’ll simplify some things.

So the key questions:

1. Did you have this issue in 3.4.0? If you didn’t test that version, please install it and give it a shot:

npm -g uninstall homebridge-unifi-protect2
npm -g install [email protected]

2. What’s your networking setup at home (firewalls, networks, etc.)?

I wouldn’t worry too much about the other StreamOnly settings right now. Let’s focus on what is/was working and what wasn’t. The only relevant setting I would try is disabling two-way audio.

[hjdhjd]

@erictaylor No beta versions of iOS or tvOS are supported...only production releases of iOS and UniFi Protect are supported.

[hjdhjd]

Streaming taking 3-4 seconds to load is quite reasonable, and well within the norm..it’s highly dependent on your WiFi environment when it comes to the doorbell. You’re going to get the fastest response time on a local network from a hardwired camera connection. Not a bug. 😄

[erictaylor]

1. Never had version 3.4.0. I will give it a go and report back the results.
2. Setup is a UniFi Dream Machine Pro with UniFi AP's and UniFi PoE switch. Firewall rules are pretty much default rules from unifi's setup. Nothing specific really.
3. Only beta software I have is tvOS currently, and I fully understand it's not officially supported.

[hjdhjd]

Let me know how 3.4.0 works, with just the default options. Assuming you haven’t setup a separate network for IoT, I hope it’ll “just work”.

[erictaylor]

Results of v3.4.0 with default settings:

• No ffmpeg errors, but stream fails to load and times out.

I added Enable.StreamOnly.Medium to v3.4.0 and the streams started working again.

[hjdhjd]

This sounds and feels like a network or CPU power issue. How’s your Pi connected to the network? How much traffic is going over WiFi?

The key insight here is the shift to a lower quality stream. That lowers the network utilization substantially.

There seems to be another challenge related to two-way audio, and we’ll get to troubleshooting that.

Have you looked closely at your network setup? That said...a medium (or low for that matter) quality stream is still plenty good for this purpose.

[erictaylor]

This sounds and feels like a network or CPU power issue. How’s your Pi connected to the network? How much traffic is going over WiFi?

The key insight here is the shift to a lower quality stream. That lowers the network utilization substantially.

My Raspberry Pi running Homebridge is powered by the POE hat and hard wired in my networking rack.

The Doorbell reports 100% (-62 dBm). WiFi health I think overall is fine.

There seems to be another challenge related to two-way audio, and we’ll get to troubleshooting that.

Sounds good. Two way audio would be nice but far more important to me to have the camera feed working. So I can live with no two-way audio for some time.

Have you looked closely at your network setup? That said...a medium (or low for that matter) quality stream is still plenty good for this purpose.

Yeah Medium seems to be working fine. I could even lower to Low if needed.

---

I appreciate your help @hjdhjd! Would you advice staying on 3.4.0 for the moment, or should I go back the latest and manually disable two way audio for now?

[hjdhjd]

Yeah, you’re good to move up to 3.5.1...is there a combination that works with two-way audio enabled in 3.5.1?

For what it’s worth...I’ve got 20 cameras, and a very overbuilt WiFi environment (think 10 APs)...I have no issues with the Doorbell even when I put it in more remote areas streaming at high quality. Our biggest delta is I run homebridge on a pretty decent server, and you’re running on a Pi. Do you have another environment (a Mac would do) that you can run homebridge on?

[hjdhjd]

Thanks for providing a lot of detail...I want to help optimize the setup, and even more so, ensure the defaults are sane for everyone so they don’t need to experiment. 😄

[erictaylor]

Yeah, you’re good to move up to 3.5.1...is there a combination that works with two-way audio enabled in 3.5.1?

Yes. Setting Enable.StreamOnly.Low worked but only when pulling the stream up on tvOS 14 beta with no issues. Trying to pull the stream up on iOS will cause the stream to error after a couple seconds.

For what it’s worth...I’ve got 20 cameras, and a very overbuilt WiFi environment (think 10 APs)...I have no issues with the Doorbell even when I put it in more remote areas streaming at high quality. Our biggest delta is I run homebridge on a pretty decent server, and you’re running on a Pi. Do you have another environment (a Mac would do) that you can run homebridge on?

I'll try running a copy on my 2019 MacBook Pro this weekend and see what results I can get and report back.

[ChadHydro]

I'm also seeing this on my end. I have ~10 cameras and the streams never begin. FWIW it did used to work although not sure if it was broken via an update. Enable.StreamOnly.Low did not work for me

[hjdhjd]

Thanks @ChadHydro. Your bug report however isn't very specific and I need a lot more specificity and detail before I can help.

What cameras specifically?
What's your exact setup?
What versions used to work?
What conditions are you exactly trying to stream in?

Without all that as a starting point, there's not much I can do. 😄

[ChadHydro]

My apologies

I've got 7 Flexes, 3 Bullets, 1 Dome, and 1 Doorbell.

Not sure if it did work or not on the last version, I'm on 3.5.1 the latest at the moment. I'm streaming it to my phone or computer. My config is very basic, just username and password. I get the snapshots just fine, homebridge discovers all of my cameras just fine

[hjdhjd]

Are you streaming locally over WiFi or over cellular? Does the Protect app work correctly when you try to use it?

If you aren't sure when it stopped working, you might want to go back and try older versions and see which is the last one that worked correctly for you. You can install prior versions by uninstalling the plugin and then installing it by using:

npm -g install homebridge-unifi-protect2@version where version is a version number. It may be a little tedious, but it'll help track this down, assuming you're certain it worked in a prior version.

[ChadHydro]

Doesn't matter where I stream it, wifi or cellular. Protect works perfectly. Good idea about trying older versions. Unfortunately, went all the way back to 3.4.0 and got the same result

[hjdhjd]

What environment are you running homebridge in?

And just to add...you mentioned it used to work, so I'm confused...did it used to work? 😄

[ChadHydro]

It's on an ubuntu VM running on Proxmox. Also, other homebridge plugins work fine.

Yep, definitely worked! I was using camera-ffmpeg previously as I had tried this plugin previously but wasn't able to make it work but tried it again and it worked.

Sorry for the run around, lemme try debugging this and I'll get back to you

[ChadHydro]

Ok, I was able to restore things to a functional state by reverting to an older version of my VM (from 4 days ago).

Seems the biggest difference is that it's on homebridge 1.1.2 (vs 1.1.3) and Homebridge Config UI X 4.27.0. This plugin is up to date at 3.5.1

I don't know if any of those details are causative

[hjdhjd]

They are, actually!

Homebridge 1.1.3 contains a new way to determine what IP address should be used to respond to streaming requests. If you're doing this in a VM environment, you may have issues in determining which IP address should be used when dealing with streaming.

There's a long story here, but the TL;DR version is this: Homebridge 1.1.3 and beyond now decide which IP address to use on multi-homed environments like VMs/Docker/etc. If you're having no issues in 1.1.2 and issues in 1.1.3...it may be a bug in how Homebridge is determining which IP address to use.

I'll be shipping an update later today as well. My suggestion: try the new update, with homebridge 1.1.3. If there's an issue then revert to 1.1.2...and raise an issue report with the homebridge team. We've been working behind the scenes on this issue for a couple of weeks.

Thanks!

[ChadHydro]

Sounds great! Will do. Thanks for hanging in there with me

[hjdhjd]

v3.6.0 is out...give it a try. Closing this one. Feel free to open a new issue if needed. Thanks!

[ChadHydro]

FYI, the update fixed my issues! Thanks!

[github-actions]

This issue is locked to prevent necroposting on closed issues. Please create a new issue for related support requests, bug reports, or feature suggestions.