MyFavMirrors/moonfire-nvr
1
0
Fork 0
mirror of https://github.com/scottlamb/moonfire-nvr.git synced 2024-12-25 22:55:55 -05:00
Code Issues Packages Projects Releases Wiki Activity
Moonfire NVR, a security camera network video recorder
229 Commits 11 Branches 26 Tags 16 MiB
Rust 85.1%
TypeScript 14.7%
HTML 0.1%
f01f523c2c
Go to file
Scott Lamb f01f523c2c refine 1->3 upgrade process 
In hindsight, the "post_tx" step in the upgrade process introduced in
e7f5733 doesn't make sense. If the procedure fails at this stage, nothing says
it still needs to be completed. If the sample file dirs have to be updated
after the database, then there should be another database version to mark that
it's fully completed, and indeed that's the purpose version 3 serves. So get
rid of the Upgrader trait and just go back to a simple run function per
version.

In the case of the sample file dir metadata, it actually can happen before the
database transaction; the stuff written to the database later just needs to be
consistent with what it finds if there's an existing metadata file from a
half-completed update.

For safety, ensure there are no unexpected directory contents before
upgrading 1->2, and ensure the metadata matches before upgrading 2->3.
2018-03-01 09:47:56 -08:00
db refine 1->3 upgrade process 2018-03-01 09:47:56 -08:00
design schema version 2: support sub streams 2018-02-03 22:15:54 -08:00
ffmpeg initial split of database to a separate crate 2018-02-20 23:15:39 -08:00
guide knob to reduce db commits (SSD write cycles) 2018-02-22 16:35:34 -08:00
src refine 1->3 upgrade process 2018-03-01 09:47:56 -08:00
ui-src schema version 2: support sub streams 2018-02-03 22:15:54 -08:00
.gitignore add a basic Javascript UI 2017-10-21 21:54:27 -07:00
Cargo.lock initial split of database to a separate crate 2018-02-20 23:15:39 -08:00
Cargo.toml initial split of database to a separate crate 2018-02-20 23:15:39 -08:00
LICENSE.txt Initial commit, with basic functionality. 2016-01-01 22:06:47 -08:00
package.json schema version 2: support sub streams 2018-02-03 22:15:54 -08:00
prep.sh fix instructions for building UI 2017-10-23 21:10:58 -07:00
README.md 3rd try at screenshot in README 2017-10-21 22:03:12 -07:00
screenshot-small.png add a basic Javascript UI 2017-10-21 21:54:27 -07:00
screenshot.png add a basic Javascript UI 2017-10-21 21:54:27 -07:00
webpack.config.js add a basic Javascript UI 2017-10-21 21:54:27 -07:00
yarn.lock add a basic Javascript UI 2017-10-21 21:54:27 -07:00

README.md

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.

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 no support for motion detection, no authentication, and no config UI.

screenshot

This is version 0.1, the initial release. 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 salient motion detection. It's way too early to make promises, but it seems possible to build a full-featured hobbyist-oriented multi-camera NVR that requires nothing but a cheap machine with a big hard drive. I welcome help; see Getting help and getting involved below. 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 3 TB drives costing about $100), so we can afford to keep many camera-months of both streams on disk.
  • decoding and analyzing only select "key" video frames (see wikipedia.
  • off-loading expensive work to a GPU. Even the Raspberry Pi has a surprisingly powerful GPU.
  • using HTTP Live Streaming rather than requiring custom browser plug-ins.
  • taking advantage of cameras' built-in motion detection. This is the most obvious way to reduce motion detection CPU. It's a last resort because these cheap cameras' proprietary algorithms are awful compared to those described on changedetection.net. Cameras have high false-positive and false-negative rates, are hard to experiment with (as opposed to rerunning against saved video files), and don't provide any information beyond if motion exceeded the threshold or not.

Documentation

Getting help and getting involved

Please email the moonfire-nvr-users mailing list with questions, or just to say you love/hate the software and why. You can also file bugs and feature requests on the github issue tracker.

I'd welcome help with testing, development (in Rust, JavaScript, and HTML), user interface/graphic design, and documentation. Please email the mailing list if interested. Pull requests are welcome, but I encourage you to discuss large changes on the mailing list or in a github issue first to save effort.