I've been using it for continuous recording of my cameras. It would be working flawlessly except for the piss poor firmware of my Reolink cameras firmware causing their rtsp server to choke.

Have you tried Neolink to make Reolink RTSP little better?

I have a reolink E1 hooked to my Homeassistant, the rstp stream seems to crash from time to time. I had never heard of neolink, would it help on this case?

I use blueiris which barely works because I'm overloading it with 9 reolinks at 4k. I'd like to figure out my bottleneck but it works enough barely that it's not worth mucking with it.

Curious - does having 4k (compared to 2k or 1080p) make a huge difference for security cameras for surveillance on a property like a home?

It depends on the application. 4K on a camera that's high up and covers a lot of area is good because you see more pixels on objects. Also stuff like identifying people's faces or license plates. 4K for a camera that is close up, like say a doorbell, is IMO less useful.

4K to FHD is the difference difference being able to see someone’s face, or not. Or being able to read a license plate, or to.

Digital zoom also can be more useful.

What I’ve learned from clients is to get the best resolution cameras you can and PoE cameras only if the use case remotely is safety or security.

Mine are all high up in second floor so it does make a difference.

Frigate recently bundled an instance of go2rtc which can connect to Reolink cameras via http/flv and re-stream as RTSP. This solved my issues with Reolink.

go2rtc also works nicely for on demand transcoding of my H265-only cams to H264 to view the live stream in Firefox.

Wait, what now? I have mine set to retain 3 full days of continuous.

Perhaps this has improved, but when I tried it out a few months ago I found that the playback for continuous recording was extremely basic and didn't have features like easy-to-use variable speed scrub to make it practical to search for things. I might try it out again today because I would like to go to something that doesn't have to run on Windows, but my use case is more around continuous recording with around a month of history than event detection.

Space management for rolling retention is also a new feature in Frigate and very basic, I don't think it has a way to do different retention policies by camera group and alarm.

I believe you can trigger recording with mqtt, so you could make an automation for it. You could try to bump this https://github.com/blakeblackshear/frigate/issues/2590#issue.... You could even try to use ai to write the feature.

There's only been one incident where I would have liked continuous, I've tweaked events to be more than enough.

Ah yes, you are right. I’ll never actually look at the continuous unless I’m robbed, so it doesn’t bother me. Person and animal detection is really good, so you’d have to be very motivated to want to slop around in the space between.

A better UI for recordings viewing and seeing times of activity are coming in the future.

Frigate already supports customizing recording retention per camera for 24/7 and event based recordings.

You can also set different retention periods based on the type of objects that were detected.

>which seems like very basic functionality but ends up as a low priority for a lot of these

for security based purposes, why would you want to save all of that data that is not changing? you'll just end up fast-forwarding to the interesting bits anyways if you have to go to the footage.

Neither motion or object detection are really that reliable, in any system I've worked with. The norm in commercial systems has long been to record continuously and use motion/object detection/other classifiers to annotate the recording. That gives you the opportunity to search for events, like thefts, that may not have been detected by classification. You also have access to footage well before and after the detected event, which is often absolutely critical to answering useful questions (e.g. how did someone get past the fence?). Common patterns like 10 seconds before/30 seconds after just aren't always sufficient.

Unfortunately consumer devices are almost always cloud-based, where storage but especially upstream bandwidth are much more costly considerations, so recording only on detection has become the norm in the consumer world.

External triggers are also an important feature in commercial systems that a lot of open source projects miss---but Frigate isn't guilty of this one, it can receive triggers by MQTT, which is the same thing I do right now with Blue Iris. That's the big thing that has me optimistic about Frigate going forward. Because motion and object detection are so inconsistent, triggering VMS events based on access control systems and intrusion sensors is often a much more reliable (and even easier to maintain) approach.

One of the niftiest ways I've seen this done was some software I used circa 2000 (I don't remember the name). It would create a variable-rate timelapse by saving a frame every time the image changed more than $x percent, calculated as the sum of differences of pixels from the previous frame, or thereabouts.

If someone was walking across the yard it would save every frame. The movement of the sun would move shadows enough to trigger a new image every few minutes. A bug flying past was small enough that it wouldn't trigger anything. The result was you could get a short video of everything interesting that happened through the day: shadows of trees sliding over the ground, every frame of the car pulling out of the driveway, shadows sliding over the ground some more, cat walks across the yard then lays down, shadows pan around more while the cat sits still, cat gets up and walks away, shadows pan around until the delivery guy comes...

It was an incredibly low-CPU way to see everything that happened without missing anything, and without having to fine-tune the motion detection very much. You just mask out any areas with constant motion, then adjust the slider for how much change triggered the next frame, which would let you adjust how fast the timelapse would go during the boring parts.

I've always wondered why the technique never became widespread.

That sounds incredibly useful, and it doesn't sound like it should be particularly hard to implement in modern systems. Maybe it just needs a term so people can search and advertise it.

Being able to buffer a video signal so that data can be saved from before a triggering event happened is not a new idea. One of Sony's cameras FS700 I think, could only record a few seconds at 240fps, and then stop. But it had a end trigger mode where it would just keep a buffer so you could press the button after the event (think after you see the lightning strike), and then it would just dump the contents of the buffer up to the point you hit stop. Same thing for sports, hit the button at the catch. Much easier than anticipating starting in time.

Essentially, the same concept, just need enough of a buffer to allow for the pre-roll which wouldn't be a lot at the lower bitrate IP data coming from the cameras

Because sometimes these systems don't detect those changes. Continuous recording with object detection and tagging solves this problem.

My solution for this at the moment is to run a a separate NVR using continuous recording in parallel with a Frigate instance.

- Redundant disks/mirroring on the NVR

- Replication of Frigate's Event Database and Recordings to remote network storage

I primarily use Frigate as a general event index, with 'active-objects' as its recording criteria, and look at the NVR when there may be gaps in Frigate's coverage.

I've also been writing my own software to integrate with Frigate to help make better sense of activity and events at a macro level, compared to its current user interface.

I'm currently using Frigate for continuous recording and it's great and I don't feel like I'm missing any features. What are some features that are missing?

Not really. Blue Iris has too many features that aren't really needed, and the lack of Linux support makes it a non starter in many cases. Also, the AI features on BI are far worse.