WebRTC support for Camera (stream) Components

Feature Requests
#21

Has anyone had any luck with using WebRTC with the new beta 2021.12.0b0 yet? Everything worked perfectly with all previous version of HA but now gives me this error during setup:
This error originated from a custom integration.

Logger: homeassistant.setup
Source: custom_components/webrtc/utils.py:74
Integration: WebRTC Camera (documentation, issues)
First occurred: 7:19:16 PM (1 occurrences)
Last logged: 7:19:16 PM

Error during setup of component webrtc
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/setup.py”, line 229, in _async_setup_component
result = await task
File “/config/custom_components/webrtc/init.py”, line 75, in async_setup
utils.register_static_path(hass.http.app, url_path, path)
File “/config/custom_components/webrtc/utils.py”, line 74, in register_static_path
app’allow_cors’
File “/usr/local/lib/python3.9/site-packages/aiohttp/web_app.py”, line 186, in getitem
return self._state[key]
KeyError: ‘allow_cors’

#22

This is a feature request post. Not a post for the custom WebRTC component. I recommend going to that forum post for that and asking for help.

#23

Am i right in thinking that this is what the November HA Release Notes were referring to?

@allenporter blew our minds this release by adding initial support for WebRTC streams and cameras to Home Assistant.

But had a good reason, he added support for Nest Battery Cameras and Nest battery Doorbell Cameras to Home Assistant! Thanks @allenporter!

I have been following this “scene” for some time, and I wasn’t sure if I got myself confused or if the information available on the topic is indeed sparse and slightly misleading? e.g. the release notes

PS: i guess for the sake of clarity my interest in this is based on using the the Unifi Protect integration and the delays that come with it (i know they are not through any fault of the integration - and I am sure that the moment there is a better approach, the core contributors like @AngellusMortis will try to get it natively implemented - hence my confusion on WebRTC)

Thank you all

PPS: let me know if I can be of any help on the testing side of things

#24

I am not actually a core contributor on the stream stuff. That is @uvjustin and @allenporter. I am one of the devs for the UniFi Protect integration (which is not in core yet).

#25

Realtime camera streaming without any delay - WebRTC - #360 by allenporter explains the difference in what exists now and what the custom component does today.

#26

You should check out low latency HLS.

#27

Yep I am aware. I was referring to core contributors to the Unifi Protect integration :slight_smile:

Thank you for providing the link to that comment. Gave me a better understanding of what work was actually done versus what I thought happened.

I’ve had this on my todo list for some time, life just kept me busy recently.

Thank you both for your answers!

#28

Hey guys,

Any chance I could pick your brain for some information?

I have tried the LL-HLS with the default configuration (from HA stream documentation) and indeed I am seeing an improvement. That is both on HTTP2 via custom domain but also HTTP1.1 via direct IP on local network (both phone and wallpanel).

I was wondering if you could share some more info on the part_duration and segment_duration attributes. The documentation is not very explicit in terms of what is the actual effect of changing the values.

Much appreciated

#29

HLS has segments, while LL-HLS splits these segments further into parts. With LL-HLS, the part_duration should be the main thing that will affect your latency. The defaults should be good for most, and changing it too much may cause things to break, but you could try lowering the part_duration a little to see if it improves latency even further. If you lower it, you can also lower segment_duration a bit because you don’t want to get too many parts in a segment (that results in increased messaging overhead). A good rule of thumb would be to keep the ratio segment_duration/part_duration around 4-8.
I actually haven’t played with the settings extensively myself and I think the defaults are fine (hence the lack of documentation), but if you find out any interesting results please let us know.

#30

Hi folks, Chris posted a great video talking about LL-HLS and the RTSPtoWeb Add-on for folks who want to learn more about the current state of things: Real Time Camera Viewing using RTSPtoWeb and Glance Cards in Home Assistant. - YouTube

1 Like
#31

Is it worth marking this as solved now? I think it’s worth updating that

  • LL HLS is now on by default and should satisfy most users (~4-5s). Maybe a couple more things we want to fix for initial startup latency
  • The rtsp to webrtc add-on now exists and is also an option though has caveats, but can be improved over time.
#32

I unfortunately cannot. While you have done amazing work on RTSP2Web, it is not a viable solution for a large number of users. Including myself or anyone else using the UniFi Protect integration. It cannot transcode AAC audio and largely renders the whole solution useless to anyone with AAC audio.

I also say that RTSP2Web is not viable to use for security cameras at all since it takes easily 10+ seconds for the feed to load. The goal for security cameras would be to tap a push notification and load the feed for the camera playing in near live (subsecond) and load in quickly as well (no more then a few seconds after Lovelace loads).

#33

Got it, I considered these projects to be solved but I realize given unifi protects aren’t working at all I hear you. We updated the certificate handling and now ignore the bad cert. Do you know what is different about the rtsps stream compared to the rtsp stream otherwise that still causes it not to work? I personally won’t be able to do anything about it since I don’t have one, but it certainly seems close to a solution.

Yes, I agree audio re-encoding and stream preloading would be great improvements.

One other angle I’ve thought about is doing a hybrid of stream with pyav and the python webrtc as a fun proof of concept, since it’ll have better stream support in general.

#34

Well, I mean it “works”, but it is not to an acceptable level of working. A security camera feed that takes 10+ seconds to load and has no audio is not very useful.

A WebRTC implementation would have to be on par with the LL-HLS implementation, but with a lower latency to be a good solution.

Again, not trying to discredit any of the awesome work you have done so far, but these things do matter a lot. One of the biggest issues people have with the UniFi Protect native app is a long load time. Likewise, one of the reasons people prefer Scrypted to HA for UniFi Protect cameras is because it puts it into HomeKit easily with allows for crazy fast load times.

#35

Edit: Sure, I’m not feeling discredited, what I mean to say is they are “projects” we should tee up and go solve. I don’t think I worded that clearly. My initial point was to update the status from 2022.02 (e.g. LL HLS is now on by default and the edit says it’s on beta) and you’re right webrtc is not complete yet.

Are unifi protect rtsp urls stable? I’m curious if just setting on demand=false in the config is enough so that they are always preloaded after initially registered.
If so, that one could be straight forward to address.

#36

@AngellusMortis just curious, which method did you land on for accessing your UniFi Protect streams via HA?

I’ve been using WebRTC since well before the LL-HLS default was made earlier this year, but I’m starting to see some slow down in my UniFi Protect live streams via the official app, so I’m troubleshooting with disabling the WebRTC streams to see if that’s causing it.