Moonfire NVR, a security camera network video recorder
Go to file
Scott Lamb 23d77693de read sample files from dedicated threads
Reading from the mmap()ed region in the tokio threads could cause
them to stall:

*   That could affect UI serving when there were concurrent
    UI requests (i.e., not just requests that needed the reads in
    question anyway).
*   If there's a faulty disk, it could cause the UI to totally hang.
    Better to not mix disks between threads.
*   Soon, I want to handle RTSP from the tokio threads (#37). Similarly,
    we don't want RTSP streaming to block on operations from unrelated
    disks.

I went with just one thread per disk which I think is sufficient.
But it'd be possible to do a fixed-size pool instead which might improve
latency when some pages are already cached.

I also dropped the memmap dependency. I had to compute the page
alignment anyway to get mremap to work, and Moonfire NVR already is
Unix-specific, so there wasn't much value from the memmap or memmap2
crates.

Fixes #88
2021-06-04 19:50:13 -07:00
.cargo keep frame poiners in release mode 2019-07-20 15:33:12 -07:00
.github adjust support instructions 2021-04-27 11:08:54 -07:00
.vscode mass markdown reformatting 2021-04-01 12:32:31 -07:00
design fix broken toc link 2021-05-15 21:54:53 -07:00
docker dockerfile tweaks 2021-03-27 21:35:44 -07:00
guide read sample files from dedicated threads 2021-06-04 19:50:13 -07:00
misc update lnav config to support newer+older styles 2021-03-12 13:40:37 -08:00
screenshots Prepare v0.6.3 release 2021-03-31 15:21:09 -07:00
server read sample files from dedicated threads 2021-06-04 19:50:13 -07:00
ui Bump ssri from 6.0.1 to 6.0.2 in /ui 2021-04-19 20:52:59 -07:00
.dockerignore start a new React-based UI (#111) 2021-02-17 19:42:32 -08:00
.gitignore start a new React-based UI (#111) 2021-02-17 19:42:32 -08:00
AUTHORS upgrade copyright notices 2020-03-01 22:53:41 -08:00
CHANGELOG.md Prepare v0.6.3 release 2021-03-31 15:21:09 -07:00
CONTRIBUTING.md adjust support instructions 2021-04-27 11:08:54 -07:00
LICENSE.txt shorten per-file copyright headers 2021-02-17 15:39:17 -08:00
README.md really fix backward link in README 2021-04-26 22:21:39 -07:00
release.bash release script fixes 2021-03-12 13:33:08 -08:00

README.md

CI

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.

list view screenshot live view screenshot

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