2024.11.0 WebRTC stream not working
Closed this issue · 40 comments
Version of the custom_component
5.4.0
Configuration
Describe the bug
After HASS upgrade to 2024.11, streams for cameras that exposed via Frigate/Frigate integration are stoped working, only static image. I'm not using Frigate card, only native HASS camera view.
Information about my steup:
- frigate are up and running on a separate host (192.168.1.209 in logs) from homeassistant
- frigate proxy addon are configured on hass and connected to frigate instance
WebRTC is enabled in Frigate Integration. No errors in browser console.
Debug log
2024-11-07 23:02:06.445 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140568319030848] Error handling message: Unknown error (unknown_error) from 192.168.1.30 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 28, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/camera/webrtc.py", line 263, in ws_webrtc_offer
await camera.async_handle_async_webrtc_offer(offer, session_id, send_message)
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 634, in async_handle_async_webrtc_offer
answer = await self.async_handle_web_rtc_offer(offer_sdp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/frigate/camera.py", line 332, in async_handle_web_rtc_offer
answer = await resp.json()
^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 80, in json
return await super().json(*args, loads=loads, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/client_reqrep.py", line 1277, in json
raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 500, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url='http://192.168.1.209:5000/api/go2rtc/webrtc?src=cam_back'
Also, my cameras stream in h265, supposed, webrtc should not work(I may be wrong).
Probably, url in log not accessible (http://192.168.1.209:5000/api/go2rtc/webrtc?src=cam_back)
I seem to be having a similar issue. After upgrade I am only seeing static images when I click my Frigate camera entities. I prefer to use the native camera view but I tried in the Frigate card. In the Frigate card the stream does work.
do you have webrtc enabled in the frigate integration configure menu?
Same issue (static image instead of stream). I just tried checking webrtc enabled and it did not affect the stream in picture entity card. This was working in previous 2024.10 fine with WebRTC integration. I deleted the WebRTC integration because I thought I didn't need it, but added it back now and the stream still doesn't work.
same issue after upgrated HASS to 2024.11
HASS stopped supporting WEBRTC, not it has native and I think integration must be updated
The same implementation still works the same, and multiple users confirmed during the beta that it works without issues
do you have webrtc enabled in the frigate integration configure menu?
Thanks! Once I enabled WebRTC in the configure menu it started to work. For others, perhaps WebRTC is not setup in your frigate config?
However, I thought it used to work with MSE and didn't require WebRTC for the Frigate integration.
Oh yeah, previously I must have been using MSE since HA didn't support Webrtc in native cards even with the HACs integration. The bigger problem here might be the fallback to MSE is not working correctly. (Although we also need to figure out WebRTC is not working for so many of us).
HA does not use MSE in native cards, in the past it used HLS
WebRTC
where and how to enable. only in frigate or hass also ?
It needs to be enabled in Frigate itself (https://docs.frigate.video/configuration/live#webrtc-extra-configuration) as well as in the Frigate configure menu in HA integrations
will try
HA does not use MSE in native cards, in the past it used HLS
Thanks, HLS is what I meant then.
I now have WebRTC working after following your instructions two posts up on enabling WebRTC in Frigate and its integration.
I think this issue can be closed but another issue is the HLS fallback is not working for the Go2RTC streams in a native home assistant card.
tried to enable webrtc - nothing helps.
From homeassistant GUI camera view works, but recordings - do not
I can see images of existing recording - but playback - fails
in Frigate GUI - everything works
From homeassistant GUI camera view works, but recordings - do not
that is an unrelated issue, and a bug in home assistant
A mi tambien me pasa desde que actualizaron ya no puedo ver los videos en la lovelace es un desastre.Me salen los iconos de las grabaciones pero no se reproducen se quedan cargando y no funcionan.
I don't know if this is related but after 24.11 a camera feed can mess up other things on the HA dash. The feeds are working both faster and more consistent but other, very unrelated, things are suffering.
Everything works fine until you ho to a tab with one or more camera feeds. After that this will happen!
- If you are editing dash, gui for edit cards will come up blank, with just the header.
- Trying to access "more information" page on a device, typically light or thermostat, that also will come up blank with just the header menu bar.
- Trying to open device information will result in a completely blank screen. Without even the header.
- Some cards will no longer be able to access any data. E.g. calendar card will show "no object found"
- Trying to reload page will result in a timeout. Can not reach server. This happens both on web, ios&android companion apps. Only way out is to kill app and restart or on webb press stop and reload from start page.
After killing app/web page and restarting again, everything is back to normal again, until you go to a tab with camera feeds and the bug will reappear. Note you don't have to restart anything in the server end, just the client.
This is from the system/loggs
Error from stream worker: Error opening stream (HTTP_NOT_FOUND, Server returned 404 Not Found, rtsps://:@wework-3-eu.stream.iot-11.com:443/v1/bfb0007feb7325bde9ywiw/css6opnhbmf6r7ds32c0qU1BbaAij5hP?signInfo=jRfl7COIsQk_b44JRxkk4LNvnA-eHINxTUJayaH-K5a_FeL8NDLjMxp0HdKLkfNBPSBwLIIcxAUbxcbJSH3XA498i46qtgEcOH4GZhyfddpmCzBU9rjMuMl3fccohiK4cZp_KEScqR6PVIKAV7HTi5S2kffAKCoAY4-WUieOWSE)
tried to enable webrtc - nothing helps. From homeassistant GUI camera view works, but recordings - do not I can see images of existing recording - but playback - fails in Frigate GUI - everything works
I am experiencing the same problems.
I am experiencing the same problems.
According to Hass Core - frigate integration needs to be updated.
@timota We see it too ;-)
tried to enable webrtc - nothing helps. From homeassistant GUI camera view works, but recordings - do not I can see images of existing recording - but playback - fails in Frigate GUI - everything works
Please note there are two issues tangled. I think what is described above (broken media) is a different bug in Home Assistant that is already fixed there (home-assistant/frontend#22755). We just need to wait for a release.
For this issue (live streams):
- It seems like the "fix" here is that instead of having both
webrtcandhlssupport in a single camera entity, the HA stance is now to have two different cameras [one with the webrtc methods, one without, e.g.camera.officeand separatelycamera.office_webrtc]. - An alternative would be to only support
webrtc(get rid of the option), but this would break for anyone without webrtc enabled ingo2rtc
Seems like option 1?
@dermotduffy have you found any example of an integration that "implements" 1?
@dermotduffy have you found any example of an integration that "implements" 1?
The builtin Nest camera (code) appears to follow this pattern. Not really sure what the alternative is if they're going to remove frontend_stream_type. Open to ideas :-)
Probably the right thing to do would be to remove the enable_webrtc option entirely, and just have a FrigateWebRTCCamera class / entity that is disabled by default but can be enabled. That's a roughly equivalent user journey to the current enable_webrtc option and would be a pretty small code change.
Downside of all of this is that anyone with webrtc enabled will need to update anything that refers to their camera entity if they want to use the webrtc one (e.g. automation, Frigate Cards, dashboards, etc).
Maybe the key is to only provide an RTSP link back to Home Assistant?
For example, Tuya integration wasn't changed (apparently) for 2024.11.
https://github.com/home-assistant/core/blob/dev/homeassistant%2Fcomponents%2Ftuya%2Fcamera.py#L82
The only thing this function does is to provide an RTSP link to the camera.
And then I guess HA decides the best way to stream it?
(Sorry, I am really just guessing, this may be completely useless)
For example, Tuya integration wasn't changed (apparently) for 2024.11.
https://github.com/home-assistant/core/blob/dev/homeassistant%2Fcomponents%2Ftuya%2Fcamera.py#L82
Does it actually support webrtc though? Does not have a async_handle_async_webrtc_offer method ...
@dermotduffy I believe Nest is an special case where some cameras can only be streamed over WebRTC, they have no RTSP interface.
Maybe for cameras which has an RTSP interface, providing a native WebRTC handling is unnecessary.
Maybe for cameras which has an RTSP interface, providing a native WebRTC handling is unnecessary.
i.e. there's magic in Home Assistant (via built-in go2rtc) that will have this work out of the box? Let me quickly edit the integration and test...
But option 2 (only provide WebRTC) also seems ok, because HA still manages to play it through HLS if necessary:
(Apparently)
For example, Tuya integration wasn't changed (apparently) for 2024.11.
https://github.com/home-assistant/core/blob/dev/homeassistant%2Fcomponents%2Ftuya%2Fcamera.py#L82Does it actually support
webrtcthough? Does not have aasync_handle_async_webrtc_offermethod ...
Not natively, but that's the thing: it does not need to. HA 2024.11 will feed its RTSP into HA's go2rtc, which then enables WebRTC stream (automatically and transparently).
But option 2 (only provide WebRTC) also seems ok, because HA still manages to play it through HLS if necessary:
... presumably not if the person doesn't have webrtc configured in their Frigate go2rtc instance, though.
... presumably not if the person doesn't have webrtc configured in their Frigate
go2rtcinstance, though.
Oh yeah, you're right. That's a good reason to avoid this option if the RTSP way works (considering both would be "simple" to implement).
Update: Myself and @felipecrs played around and think we have a fix. PR coming soon...
Awesome!
PS: @dermotduffy did everything. I was just giving guesses.
This is now fixed (tested by both myself and @felipecrs ). Will do a new release this weekend.
Please try out the new pre-release (v5.5.0) which includes this fix.
Thanks for the fix—it does work, but the video isn’t smooth, and the sound cuts off after the first second. Compared to how it worked previously, the difference is significant.
yeah it looks like it is using HLS now, not webrtc
edit: I had go2rtc in HA configured to point at my own instance. Once I disabled that it is working using webrtc