re: General security camera discussion (was "Unifi Protect security cameras")

quote:

---

As for the surveillance obsession, I'm trying to build a business out of it so I kind of have to be obsessed. Not sure if those of you who pop into this thread are quite this interested, but in case you are I'll update once I've started my open source Protect clone that will work with any ONVIF cam.

---

I pop in because I'm a Unifi fan and because I'd rather someone else troubleshoot all these security cameras. I've never felt the need for security cameras around the house where I live but I'm sure that will change one day.

quote:

---

my open source Protect clone that will work with any ONVIF cam.

---

So I have assembled a small team of devs to help with this and figured I'd bump the thread to get some feedback since I'm already kind of bumping heads with one of them.

I've expanded my desired feature set to solve what I believe are some unaddressed issues in the current state of the market. Many/most of these issues might actually be addressed, but in these cases the solution costs many thousands of dollars. I believe they can be solved with an open source application.


1. Shitty UIs.

Nothing comes close to the Protect vertical-scrolling timelapse feature IMO (I believe the Nest app does similar). Searching and playing back recordings is a pain in most apps. I will try to clone Protect.


2. Limited options for upgrades/expansion.

With a typical consumer or small business NVR, you have a set # of channels and that's that. If you end up needing more later on, you either have to replace it with a larger one and either lose all your recordings or it's a huge pain to save them, or you can add a second NVR and deal with the pain of a split system forever. Ubiquiti has plans to solve this problem via what they call "stacking" NVRs, but this feature has been "coming soon" for more than 2 years. There is a similar problem with most VMS software that runs on a computer. At some point adding another camera will cause it to run out of resources, and you have the same decision to make.

I think this problem can be solved with a peer-to-peer architecture. You can start with an NVR as cheap and low-powered as a Raspberry Pi recording from one camera, and if you add cameras and the Pi runs out of resources, you can just add another and join it to the p2p network. They would then cooperatively balance the load, and offer storage redundancy at the same time. This would of course also work with something like a NUC, or a desktop PC, rack server, etc., and you can mix and match your hardware and there should be no real limit to growth. If you add a machine with a GPU, the network would intelligently shift any object detection that you may have running over to that node.

Additionally, a p2p architecture makes it easy to merge two distinct sites by simply running an instance in "the cloud" and connecting both networks to it.


3. Time-based recording deletion sucks.

If you have 1 week of storage capacity, you're going to want to see what happened 8 days ago. If you have 1 month of capacity, you're going to want to see something that happened 5 weeks ago. This happens over and over if you deal with enough surveillance video, and I think we can do it in a smarter way.

Surveillance video, like a lot of time-series data, still has a lot of value after lossy compression. So instead of a hard cutoff before which you have no video whatsoever, we can just delete the high quality version and leave a low quality one. This method alone can stretch a month of high quality recordings into a month of high quality recordings and a year of low quality recordings.

I typically like to record 24/7 with motion and other events highlighted, just because it's often useful to prove that something *didn't* happen at a given time. But after a while that's less valuable, so we can only keep the video where something happened. This can stretch a month of high quality video into a month of 24/7 video and 2 or 12+ months of high quality event video, depending on activity.


4. Data redundancy and durability options are limited.

With typical NVRs you have the option of no redundancy or RAID, and backups are a pain in the arse. I'm sure there are high dollar VMS systems with nicer backup systems, but again you will pay dearly for that and it is unlikely that they offer the type of system that I'll propose.

The main problem IMO with using standard redundancy and backup options is they just treat data as data, but not all surveillance video is created equal. I will create a rule-based system which assigns a sort of importance value to each segment of video. Inputs might include the camera, whether there is motion, whether a particular object was detected, how old the footage is, etc., and the output of the ruleset will be a number which approximates how many copies of the video segment should be stored. Maybe you have a camera for which you want 3 copies when people are detected, 2 copies of 24/7 footage for a week, and 1 copy of older footage. The result is highly durable important video, and a long tail of video of lesser importance and durability.

And of course with the p2p architecture your nodes can figure out the best place to store a given piece of video, whether it's across multiple machines on site, in the cloud, or at another site. Backups and recovery become seamless and automatic.



I realize this is a lot, so if you made it to the end congrats.

And I realize a lot of home users don't care about this stuff, but I think an open system as described above can offer a lot of value to businesses of all sizes. I also think that if I or a 3rd party would offer a NUC type of device with 4 or 8 cameras, a lot of consumers would go for that, especially if it would eliminate the decision of "should I get the 16 channel just in case" since you could just stack a second box and automatically support more cameras, more storage, and added data safety.

Anyway, thoughts would be appreciated, even if just a to encourage me to possibly spend a few thousand hours of my life on this