Comment by sneak
1 year ago
I assume it’s to leverage a) cheap/scalable cloud storage and b) offsite storage for security/ease of access.
1 year ago
I assume it’s to leverage a) cheap/scalable cloud storage and b) offsite storage for security/ease of access.
Probably, but I'd like to hear the author's take on a key design decision rather than guess. This is also not the only option to achieve some fraction of that goal—another approach would be for the camera hub to encrypt and upload directly to a cloud object storage API (AWS S3 and competitors) and give the client presigned URLs to access it.
My NVR's based on the assumption that you want to record continuously (as called out in the schema design doc here [1]) rather than trust event detection to be perfectly reliable. I've set up other systems in parallel that are based on a different assumption (e.g. Frigate) but have found they miss things, so this is the design I'm comfortable with.
If you are also constrained on upstream bandwidth, continuous recording means you must buy a local hard drive. It costs $100–$200 to buy one that can hold many camera-months of video at good quality, which I find pretty reasonable.
Some folks might want to also upload stuff off-site in case the NVR itself is stolen or destroyed, but I haven't felt the need. There are a bunch of missing features from my system I'd like to add when I have time; that one doesn't make my top 10. YMMV.
[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...
I haven't designed Privastead for continuous recording/streaming. It's mainly to receive motion/event-triggered videos and occasional live streaming. The usage model is more like Ring cameras.
That didn't answer my question.
4 replies →
The server only stores encrypted videos until they're fetched by the app. It can't decrypt the videos and hence is not meant as a storage space for decrypted videos.