[Beta Support]: Camera live view timeout is too short #21383
Replies: 2 comments 1 reply
-
|
Based on the information available, I don't have specific documentation about configuring the timeout duration for Frigate's live view player before it falls back to low-bandwidth mode(1). However, from the documentation, I can confirm that Frigate uses "smart streaming" by default, which attempts to load streams using MSE (Media Source Extensions) technology first, and falls back to jsmpeg (low-bandwidth mode) when there are "initial timeout, a low bandwidth condition that would cause buffering of the stream, or decoding errors"(1). The documentation notes that "if you are using continuous streaming or you are loading more than a few high resolution streams at once on the dashboard, your browser may struggle to begin playback of your streams before the timeout"(1). When this happens, you can use the "Reset" link/button to try loading your high resolution stream again(1). For cameras that take longer to establish connections (like your Tuya camera), the current workaround mentioned in the documentation is to use the Reset option after the stream has been established in go2rtc(1). The timeout value itself doesn't appear to be a user-configurable setting in the available documentation. This would be a feature request rather than a bug, as the current behavior is working as designed - it's just that the timeout may be too short for slower-connecting streams like Tuya sources. 📚 Sources: Have another question? Just tag @inkeep. |
Beta Was this translation helpful? Give feedback.
-
|
Since you're using the beta, you can configure the timeout in a dropdown in You should also look at the browser console, as it will report the errors that are being fired that causes the fallback to jsmpeg. EDIT: Based on your console log above, I'll push an improvement for the next build that will cause the browser's MediaSource setup to wait longer. Your initial fallback to jsmpeg is very early in the logic (before the configurable timeout is even used) and is caused by your configuration where the stream is not pre-loaded or used anywhere in Frigate. |
Beta Was this translation helpful? Give feedback.
-
|
@hawkeye217 thanks a lot! I have just updated to the latest 0.17.0-rc1 and here's my feedback: Even after raising the UI timeout to 10s, it's still not enough. I got it to work once, but I think I was just lucky. Before raising the timeout: After raising the timeout to 10s: I made some tests in go2rtc itself, and it usually takes 10-12s to fully open the WebRTC stream. I recommend we bump the maximum to 15s. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Checklist
Describe the problem you are having
I have a Tuya-based camera using the new Tuya source in go2rtc, and it indeed takes a while to load. I don't feed it into Frigate or have it preloaded elsewhere, so it takes some seconds for the connection to be established.
Frigate never waits long enough for the connection to be established, and always goes into low-bandwidth mode. Unless the camera is already preloaded in go2rtc. Or if I press the reload button while the camera is already streaming, which is the same thing.
The live stream works fine through other players like go2rtc's embedded and Advanced Camera Card.
Steps to reproduce
chrome_vkewXdonWx.mp4
Version
0.17.0-430cebe
In which browser(s) are you experiencing the issue with?
Google Chrome 143.0.7499.148
Frigate config file
docker-compose file or Docker CLI command
Not relevant.Relevant Frigate log output
Relevant go2rtc log output
Operating system
Home Assistant OS
Install method
Home Assistant Add-on
Network connection
Wireless
Camera make and model
INQMEGA IL-HIP291-1M
Screenshots of the Frigate UI's System metrics pages
Not relevant.
Any other information that may be helpful
I think this issue can be reproduced with any camera that uses Tuya source in go2rtc.
Browser console logs:
Beta Was this translation helpful? Give feedback.
All reactions