Continuous live stream on dashboard and camera groups

[kensand]

Please upvote this if you would like to see this feature added! The code is already written!

This is important so maintainers can gauge support for the feature.

If you have another idea for how this can be implemented, perhaps in a less easily misconfigured manner, please comment below. One idea I had was to enable continuous live streams on a per-camera basis.

---

Per #12684 and #12682, continuous live streams of cameras on the dashboard and camera groups is not directly supported by Frigate. Cameras only begin streaming if Automatic Live View is enabled in the settings page and once motion is detected. If Automatic Live View is disabled, snapshot views of the cameras on the dashboard and camera groups will only update once per minute.

For my personal use case, I have both the bandwidth and server resources to support a continuous live stream for all my cameras, so I prefer to be able to view these live streams continuously regardless of whether there is ongoing motion.

The suggested workarounds for this issue are:

1. Use birdseye in continuous mode. However, this is not the same quality as individual cameras and cannot be rearranged/resized according to user preferences. Additionally, this does not enable users to enlarge a camera of interest simply by clicking on it. It also spins up another ffmpeg process, albeit one that should be rather efficient.
2. Reduce motion threshold on the live streaming cameras to 1, causing them to always be active. This has the desired effect, but does not allow users to reasonably configure objection detection as all detectors are always active, further using up resources.

Some other downsides to not having this feature:

1. Cameras with motion detection disabled cannot be live streamed at all, even with the Automatic Live View enabled. The only way to do it would be to use birdseye mode, which has its own downsides listed above.
2. Motion under the motion detection threshold will not cause the cameras to be made active.
3. Motion detection may be masked for the camera, but a user may still want to be able to monitor it in realtime; for example, the wind on a flag or traffic on a roadway.
4. A camera may have a hardware issue that causes it to continue responding to stream requests but not to update the image, which would not be readily apparent to the user.

Frigate maintainers have expressed concerns about the possibility of misconfiguration with this setting, which would cause a greater use of system resources and bandwidth. While I can't say I agree with this opinion, I understand it. I will note that I personally spent over an hour trying to figure out why live streams weren't working, and that I had to dive into the frontend code to understand the problem. At a minimum, I think this needs to be added to the FAQ and/or live stream page in the docs (which I plan to make a separate PR for).

In the meantime, I will be maintaining my own Frigate fork containing #12684, if anyone else needs this feature. It should automatically sync with the upstream repo using the Github pull app

[danielpmorris87]

This would be an awesome feature to have. Id love to use the Frigate UI when I am working/gaming but I am forced to use Home Assistant for continuous viewing.

[nicoleise]

If your premise is correct, then I would like this feature also. I thought Frigate already had a fallback behavior for cameras where motion isn't enabled, since the live mechanism seems to depend on it.

Your second list suggests that the most relevant way to implement this would be on a per-camera basis.

So, under config under each camera an optional entry like always-live-on-dashboard: True. If true, and if no motion is configured, or if motion is configured but not currently detected, the camera would display a live feed but without the accenting frame and icons associated with motion. Those highlights could still be shown if motion is detected, if for example this option is used on a motion enabled camera to ensure that the view is live even if the motion of interest isn't detected.

To provide a specific use case example: We will have some cameras that aren't used for automations and are situated in areas you can't get to or from without being picked up by several other motion enabled cameras. Some of these will overlook our backyard, the playground-ish area for the kids and our fields in hilly terrain. In other words, motion would likely frequently be triggered by stuff we don't care about, like plants moving, tractors in the field, shadows from clouds, etc. It would likely not be triggered by what we actually want, for example the kids in the playground, because of the distance to those events.

We cannot set up motion in a way that would work. For example, a large tractor in the field in the foreground is of no interest, while a small camouflaged hunter 1 km away is of high interest. We don't care about a person on the ride on lawn mower, but we'd like to be able to see that our kids are ok in their playground area if we're inside cooking and they're outside playing. But that's a partially obstructed view at around 70 m distance. We don't care about the horses themselves, but if the fence is suddenly drooping, we'd be very interested.

So we'd like to simply be able to see that camera live (together with other cameras) under certain circumstances, but we wouldn't want/need (mostly irrelevant) motion events to clog up events.

I thought non motion cameras in Frigate would already exhibit this behavior om dashboards, so I can only support the suggestion.

[kensand]

I thought Frigate already had a fallback behavior for cameras where motion isn't enabled, since the live mechanism seems to depend on it.

Unfortunately no; if motion isn't enabled, the image on the dashboard and camera groups only update once every minute, regardless of the AutoLive setting or any configuration.

Your second list suggests that the most relevant way to implement this would be on a per-camera basis.

So, under config under each camera an optional entry like always-live-on-dashboard: True. If true, and if no motion is configured, or if motion is configured but not currently detected, the camera would display a live feed but without the accenting frame and icons associated with motion. Those highlights could still be shown if motion is detected, if for example this option is used on a motion enabled camera to ensure that the view is live even if the motion of interest isn't detected.

I'm open to doing so; right now the PR I have open (and my own fork) takes a simpler route though, and just changes the AutoLive toggle into a dropdown allowing users to choose between three settings:

• Auto mode (default) - begin streaming when activity (motion) is detected.
• Static mode - update camera images on the live dashboard once per minute.
• Continuous mode - stream cameras regardless of activity.

This mode affects all cameras visible to the user and regardless of camera group or dashboard.

Adding an additional configuration on a per-camera basis as you describe would definitely add some work and complexity, but I would be happy to update my PR if the maintainers prefer it.

---

Thanks for your feedback and additional use case. Hopefully the maintainers will take it into account 😃

[NickM-27]

I think it's important to define what a non motion camera is. There is no requirement for object detection or alerts to be setup. Motion detection is enabled by default so unless you are explicitly disabling motion detection (different from object detection) on the camera then the live view will work the same as any other case.

[dopeytree]

Is birdseye mode still a thing in 0.14?

[NickM-27]

Yes

[pschroee]

I really like this feature. I want to setup a dedicated pc with frigate installed. The pc should auto login and open frigate in firefox in kiosk mode. I want to see the live view of the cameras all times. The pc, on which frigate is installed, has the resources to always show the livestreams of the cameras.
For the concerns of misconfiguration, you can add a warning label to the setting or you have to set config entry (e.g. ui -> enable continuous live view).

[conorlap]

+1 for this, would be very useful to have ability to configure this!

[saket424]

@kensand
I would like the complete opposite of the problem you are addressing and so having the ability to configure whether we want a camera stream to render all the time or the stream to render just on demand would be excellent. Assume you have 30 cameras and all you care is on demand live view and no recording or object detection is necessary. Currently my measurements indicate that frigate subscribes to all 30 streams and pulls a copy of the feeds even when there is no one actively viewing the feeds. Go2rtc is frugal with bandwidth and only pulls when someone requests to view or analyze the feeds. I would like that frugality to also carryover to frigate. I hope I articulated my point.

[NickM-27]

Frigate always decodes the streams for a number of features that require it. Using frigate without detection and without recording is a very uncommon use case for Frigate

[bill-web7]

I also spent hours debugging my frigate installation because it isn't live and honestly I couldn't conceive this is the intended behavior. As far as I'm concerned this is a duh feature and live should be the default. The maintainers arguments sound like they are worried about people using a Tamagotchi to run 20 cameras. I really appreciate the work they are doing but this is 2024. In my 30 years as a C/C++ programmer and CTO I always fought against the "we know best" mindset on display here. The most obvious first test people will perform is to check if they are at least getting live video. I wonder how many people gave up on frigate and HA because of this frustration when that simple expectation was not met.
So it seems that my only solution is to use frigate for recording and HA camera for live feeds. Seems like a bigger waste of resources than the proposed solution.

[NickM-27]

I said a separate feature needs to be implemented first before this can be considered, nowhere did I say this would not be addressed. Also, I am not making a decision only stating my personal opinion

[kensand]

I said a separate feature needs to be implemented first before this can be considered, nowhere did I say this would not be addressed.

So, as a maintainer, you are making the decision not to merge the existing implementation I provided. My implementation works and is relatively tidy, and I am happy to hide the functionality behind additional settings and warnings, but the decision not to merge is squarely within your purview. The requirement that another feature (multistream) be implemented first is effectively moving goalposts.

Also, I am not making a decision only stating my personal opinion

You may feel you are voicing your opinion, but by default, a maintainer's opinion is a decision, unless overridden by other maintainers.

It's disappointing, but at least I am free to maintain my fork. I truly would love to be proven wrong about your decision though 😄

[hawkeye217]

As another maintainer of Frigate, I'll jump in here to say that we certainly see the interest in this feature and we have discussed how to best implement something like it. As I mentioned on your original PR, a more granular approach to this feature is preferable so that users have the ability to stream none, some, or all of their cameras continuously rather than none or all.

As we've mentioned several times, a one-size-fits-all approach is not feasible because of the support issues that it would lead to. Many users are unaware of the server and client requirements for continuous streaming, and as volunteers to the project, we don't want to (nor do we have the time to) field dozens of support requests for users who would enable continuous streaming and then say "my 5 year old tablet doesn't work with Frigate, it's a bug". Many users run Frigate on under-powered SBCs or older processors, so additional documentation will be necessary to help users understand server and client requirements. I hope you can see and appreciate the support aspect of this feature.

Additionally, as @NickM-27 mentioned, we'd like to provide users with granular control and the ability to choose any stream from their cameras for the live option. A continuous streaming feature makes more sense in that context.

I've begun implementing this feature already and hope that it can be a part of Frigate 0.16. When it's merged in dev, feel free to test and give your feedback.

[kensand]

As another maintainer of Frigate, I'll jump in here to say that we certainly see the interest in this feature and we have discussed how to best implement something like it.

I appreciate you jumping in. Is there somewhere those discussions are visible, or are they made via private channels? I would like to know what was proposed and would be acceptable to the maintainers as a whole, if possible.

As I mentioned on your original PR, a more granular approach to this feature is preferable so that users have the ability to stream none, some, or all of their cameras continuously rather than none or all.

I would be happy to implement a granular approach, if I had reason to believe that it would have an additional likelihood of being merged, but it seemed your concern over supporting foot-shooting users trumped that approach as well; wouldn't it be just as likely for someone to set a granular config as what I had in the original implementation?

As we've mentioned several times, a one-size-fits-all approach is not feasible because of the support issues that it would lead to.

Please clarify what you mean by "one-size-fits-all". Are you referring to this not being granular on a per-camera basis? Or that providing continuous live streams on the dashboard/camera groups are not applicable to all users? or something else?

Many users are unaware of the server and client requirements for continuous streaming, and as volunteers to the project, we don't want to (nor do we have the time to) field dozens of support requests for users who would enable continuous streaming and then say "my 5 year old tablet doesn't work with Frigate, it's a bug". Many users run Frigate on under-powered SBCs or older processors, so additional documentation will be necessary to help users understand server and client requirements. I hope you can see and appreciate the support aspect of this feature.

As I have said before, I understand your concern, but I don't agree with it. I believe the lack of this feature is likely causing more confusion for users than including it with gratuitous warnings would, as @bill-web7 and others in this discussion have noted.

Additionally, as @NickM-27 mentioned, we'd like to provide users with granular control and the ability to choose any stream from their cameras for the live option. A continuous streaming feature makes more sense in that context.

I've begun implementing this feature already and hope that it can be a part of Frigate 0.16. When it's merged in dev, feel free to test and give your feedback.

When you write "I've begun implementing this feature", are you referring to the multi-stream feature or continuous live stream feature, or both?

I agree continuous live streaming does make more sense in the context of having multiple streams - I use sub-streams via separate camera configurations for recording vs streaming. However, the lack of live streaming is still an issue for me regardless of the multi-stream implementation, and I am trying to gauge whether I should embark on writing a PR for granular, per-camera-enabled continuous live stream in the meantime.

Thank you for the additional background though, it is appreciated.

[bill-web7]

Following Akin's First Law I provide a few simple numbers from my setup. Following the suggestion of NickM I tried different values of:
motion:
threshold:
and recorded the effect on CPU use and Network throughput out. Each of the 10 cameras was setup to use the low res stream. I included only cameras where there is very little movement at this time of day. I setup 2 consumers, one wired windows system and one iphone on wifi. I also made sure to turn off everything I could think of on the HA PC. I waited a minute after restarting Frigate for things to settle.

Threshold CPU % Throughput out Comment
30 (default?) 22-24 0.100 - 0.290 MB/s Some cameras didn't update for at lease 30 seconds.
1 (min) 28-32 0.400 - 0.580 MB/s This setting gave me what I wanted to see; each second updated.
100 21-22 0.089 - 0.096 MB/s Some cameras took long to startup.

Thanks to NickM for his suggestion it allows me to get on with my HA integration as in now have what I expected to see. I feel especially dumb not thinking of looking in the docs for a way to set the threshold. Especially since I have written at least 100,000 lines of C++ code using OpenCV.

[hua-bing]

I like this feature. And I would vote for making it as the default. Personally I thought there are issues with my cameras and/or setups when I saw some cameras did not update and spent a lot of time to only find out that it is an expected behavior.
I am also not sure if birdview needs to exist if there is live stream from the snapshot. It might be a tradition to have a birdview for a surveillance system. However, the birdview is a little bit hard to use (and redundant when live stream is available from snapshot view). I often find myself clicking on birdview cameras trying to get to the camera view.

[NickM-27]

Many use birdseye view for showing on a TV or tablet that isn't powerful enough to display all the different streams in the webui. Birdseye is not shown in the webui by default