1e314e09d0
* API change: in update signals, allow setting a start time relative
to now. This is an accuracy improvement in the case where the client
has been retrying an initial request for a while. Kind of an obscure
corner case but easy enough to address. And use a more convenient
enum representation.
* in update signals, choose `now` before acquiring the database lock.
If lock acquisition takes a long time, this more accurately reflects
the time the caller intended.
* in general, make Time and Duration (de)serializable and use them
in json types. This makes the types more self-describing, with
better debug printing on both the server side and on the client
library (in moonfire-playground). To make this work, base has to
import serde which initially seemed like poor layering to me, but
serde seems to be imported in some pretty foundational Rust crates
for this reason. I'll go with it.
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.6.3. 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 https://spdx.org/licenses/GPL-3.0-linking-exception.html for OpenSSL.
- Change log / release notes.
- Guides
- Design documents
- Wiki has hardware recommendations, notes on several camera models, etc. Please add more!