892427592e
* switch from json to toml. I think this will be more user-friendly. It allows comments and has less punctuation. Fewer surprises than yaml (which has e.g. the "Norway problem"). I might have stayed with JSON if I could see a good serde json library that allows comments, but hson is unmaintained and serde-json strictly follows the spec. * switch from camelCase to snake_case. Seems more idiomatic for TOML and matches the Rust source. * forbid unknown keys. Better to spot errors sooner. * rename "trust_forward_hdrs" to "trust_forward_headers". Nothing else is abbreviated.
Introduction
Moonfire NVR is an open-source security camera network video recorder, started
by Scott Lamb <slamb@slamb.org>. It saves H.264-over-RTSP streams from
IP cameras to disk into a hybrid format: video frames in a directory on
spinning disk, other data in a SQLite3 database on flash. It can construct
.mp4 files for arbitrary time ranges on-the-fly. It does not decode,
analyze, or re-encode video frames, so it requires little CPU. It handles six
1080p/30fps streams on a Raspberry Pi
2, using
less than 10% of the machine's total CPU.
Help wanted to make it great! Please see the contributing guide.
So far, the web interface is basic: a filterable list of video segments, with support for trimming them to arbitrary time ranges. No scrub bar yet. There's also an experimental live view UI.
 |
 |
There's no support yet for motion detection, no https/TLS support (you'll need a proxy server, as described here), and only a console-based (rather than web-based) configuration UI.
Moonfire NVR is currently at version 0.7.1. Until version 1.0, there will be no compatibility guarantees: configuration and storage formats may change from version to version. There is an upgrade procedure but it is not for the faint of heart.
I hope to add features such as video analytics. In time, we can build a full-featured hobbyist-oriented multi-camera NVR that requires nothing but a cheap machine with a big hard drive. There are many exciting techniques we could use to make this possible:
- avoiding CPU-intensive H.264 encoding in favor of simply continuing to use the camera's already-encoded video streams. Cheap IP cameras these days provide pre-encoded H.264 streams in both "main" (full-sized) and "sub" (lower resolution, compression quality, and/or frame rate) varieties. The "sub" stream is more suitable for fast computer vision work as well as remote/mobile streaming. Disk space these days is quite cheap (with 4 TB drives costing about $100), so we can afford to keep many camera-months of both streams on disk.
- off-loading on-NVR analytics to an inexpensive USB or M.2 neural network accelerator and hardware H.264 decoders.
- taking advantage of on-camera analytics. They're often not as accurate, but they're the best way to stretch very inexpensive NVR machines.
Documentation
- Contributing
- License — GPL-3.0-or-later with GPL-3.0-linking-exception for OpenSSL.
- Change log / release notes.
- Guides
- Design documents
- Wiki has hardware recommendations, notes on several camera models, etc. Please add more!