Moonfire NVR, a security camera network video recorder
Go to file
Scott Lamb 3b0dc5368e Write using the shiny new schema
There's a lot of work left to do on this:

* important latency optimization: the recording threads block
  while fsync()ing sample files, which can take 250+ ms. This
  should be moved to a separate thread to happen asynchronously.

* write cycle optimizations: several SQLite commits per camera per minute.

* test coverage: this drops testing of the file rotation, and
  there are several error paths worth testing.

* ffmpeg oddities to investigate:

  * the out-of-order first frame's pts
  * measurable delay before returning packets
  * it sometimes returns an initial packet it calls a "key" frame that actually
    has an SEI recovery point NAL but not an IDR-coded slice NAL, even though
    in the input these always seem to come together. This makes playback
    starting from this recording not work at all on Chrome. The symptom is
    that it loads a player-looking thing with the proper dimensions but
    playback never actually starts.

  I imagine these are all related but haven't taken the time to dig through
  ffmpeg code and understand them. The right thing anyway may be to ditch
  ffmpeg for RTSP streaming (perhaps in favor of the live555 library), as
  it seems to have other omissions like making it hard/impossible to take
  advantage of Sender Reports. In the meantime, I attempted to mitigate
  problems by decreasing ffmpeg's probesize.

* handling overlapping recordings: right now if there's too much time drift or
  a time jump, you can end up with recordings that the UI won't play without
  manual database changes. It's not obvious what the right thing to do is.

* easy camera setup: currently you have to manually insert rows in the SQLite
  database and restart.

but I think it's best to get something in to iterate from.

This deletes a lot of code, including:

* the ffmpeg video sink code (instead now using a bit of extra code in Stream
  on top of the SampleFileWriter, SampleIndexEncoder, and MoonfireDatabase
  code that's been around for a while)

* FileManager (in favor of new code using the database)

* the old UI

* RealFile and friends

* the dependency on protocol buffers, which was used for the config file
  (though I'll likely have other reasons for using protocol buffers later)

* even some utilities like IsWord that were just for validating the config
2016-02-03 23:22:37 -08:00
debian Construct HTTP responses incrementally. 2016-01-14 22:41:49 -08:00
design Write using the shiny new schema 2016-02-03 23:22:37 -08:00
src Write using the shiny new schema 2016-02-03 23:22:37 -08:00
.gitignore Initial commit, with basic functionality. 2016-01-01 22:06:47 -08:00
CMakeLists.txt Write using the shiny new schema 2016-02-03 23:22:37 -08:00
LICENSE.txt Initial commit, with basic functionality. 2016-01-01 22:06:47 -08:00
README.md Write using the shiny new schema 2016-02-03 23:22:37 -08:00

Introduction

Moonfire NVR is an open-source security camera network video recorder, started by Scott Lamb slamb@slamb.org. Currently it is basic: it saves H.264-over-RTSP streams from IP cameras to disk as .mp4 files and provides a simple HTTP interface for listing and viewing fixed-length segments of video. It does not decode, analyze, or re-encode video frames, so it requires little CPU. It handles six 720p/15fps streams on a Raspberry Pi 2, using roughly 5% of the machine's total CPU.

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.

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.

Downloading

See the github page (in case you're not reading this text there already). You can download the bleeding edge version from the commandline via git:

$ git clone https://github.com/scottlamb/moonfire-nvr.git

Building from source

There are no binary packages of Moonfire NVR available yet, so it must be built from source. It requires several packages to build:

  • CMake version 3.1.0 or higher.
  • a C++11 compiler, such as gcc 4.7 or higher.
  • ffmpeg, including libavutil, libavcodec (to inspect H.264 frames), and libavformat (to connect to RTSP servers and write .mp4 files). Note ffmpeg versions older than 55.1.101, along with all versions of the competing project libav, does not support socket timeouts for RTSP. For reliable reconnections on error, it's strongly recommended to use ffmpeg >= 55.1.101.
  • libevent 2.1, for the built-in HTTP server. (This might be replaced with the more full-featured nghttp2 in the future.) Unfortunately, the libevent 2.0 bundled with current Debian releases is unsuitable.
  • gflags, for commandline flag parsing.
  • glog, for debug logging.
  • gperftools, for debugging.
  • googletest, for automated testing. This will be automatically downloaded during the build process, so it's not necessary to install it beforehand.
  • re2, for parsing with regular expressions.
  • libuuid from (util-linux)[https://en.wikipedia.org/wiki/Util-linux].
  • SQLite3.

On Ubuntu 15.10 or Raspbian Jessie, the following command will install most pre-requisites (see also the Build-Depends field in debian/control):

$ sudo apt-get install \
               build-essential \
               cmake \
               libavcodec-dev \
               libavformat-dev \
               libavutil-dev \
               libgflags-dev \
               libgoogle-glog-dev \
               libgoogle-perftools-dev \
               libre2-dev \
               libsqlite3-dev \
               pkgconf \
               uuid-dev

libevent 2.1 will have to be installed from source. In the future, this dependency may be replaced or support may be added for automatically building libevent in-tree to avoid the inconvenience.

Once prerequisites are installed, Moonfire NVR can be built as follows:

$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install

Alternatively, if you do have a sufficiently new apt-installed libevent installed, you may be able to prepare a .deb package:

$ sudo apt-get install devscripts dh-systemd
$ debuild -us -uc

Installation

Moonfire NVR should be run under a dedicated user. It keeps two kinds of state:

  • a SQLite3 database, typically <1 GiB. It should be stored on flash if available.
  • the "sample file directory", which holds the actual samples/frames of H.264 video. This should be quite large and typically is stored on a hard drive.

Both are intended to be accessed only by Moonfire NVR itself. However, the interface for adding new cameras is not yet written, so you will have to manually create the database and insert cameras with the sqlite3 commandline tool prior to starting Moonfire NVR.

Before setting up a camera, it may be helpful to test settings with the ffmpeg commandline tool:

$ ffmpeg \
      -i "rtsp://admin:12345@192.168.1.101:554/Streaming/Channels/1" \
      -c copy \
      -map 0:0 \
      -rtsp_transport tcp \
      -flags:v +global_header \
      test.mp4

Once you have a working ffmpeg commandline, set up Moonfire NVR as follows:

$ sudo addgroup --system moonfire-nvr
$ sudo adduser --system moonfire-nvr --home /var/lib/moonfire-nvr
$ sudo mkdir /var/lib/moonfire-nvr
$ sudo -u moonfire-nvr -H mkdir db sample
$ uuidgen | sed -e 's/-//g'
b47f48706d91414591cd6c931bf836b4
$ sudo -u moonfire-nvr sqlite3 db/db
sqlite3> .read path/to/schema.sql
sqlite3> insert into camera (
    ...>     uuid, short_name, description, host, username, password,
    ...>     main_rtsp_path, sub_rtsp_path, retain_bytes) values (
    ...>     X'b47f48706d91414591cd6c931bf836b4', 'driveway',
    ...>     'Longer description of this camera', '192.168.1.101',
    ...>     'admin', '12345', '/Streaming/Channels/1',
    ...>     '/Streaming/Channels/2', 104857600);
sqlite3> ^D

See the schema SQL file's comments for more information. Note that the sum of retain_bytes for all cameras should be somewhat less than the available bytes on the sample file directory's filesystem, as the currently-writing sample files are not included in this sum. Be sure also to subtract out the filesystem's reserve for root (typically 5%).

If a dedicated hard drive is available, set up the mount point:

$ sudo vim /etc/fstab
$ sudo mount /var/lib/moonfire-nvr/sample

Moonfire NVR can be run as a systemd service. Create /etc/systemd/system/moonfire-nvr.service:

[Unit]
Description=Moonfire NVR
After=network-online.target

[Service]
ExecStart=/usr/local/bin/moonfire-nvr \
    --sample_file_dir=/var/lib/moonfire-nvr/sample \
    --db_dir=/var/lib/moonfire-nvr/db \
    --http_port=8080
Type=simple
User=moonfire-nvr
Nice=-20
Restart=on-abnormal
CPUAccounting=true
MemoryAccounting=true
BlockIOAccounting=true

[Install]
WantedBy=multi-user.target

Note that the HTTP port currently has no authentication; it should not be directly exposed to the Internet.

Complete the installation through systemctl commands:

$ sudo systemctl daemon-reload
$ sudo systemctl start moonfire-nvr.service
$ sudo systemctl status moonfire-nvr.service
$ sudo systemctl enable moonfire-nvr.service

See the systemd documentation for more information. The manual pages for systemd.service and systemctl may be of particular interest.

While Moonfire NVR is running, logs will be written to /tmp/moonfire-nvr.INFO.

Getting help and getting involved

Please email the moonfire-nvr-users mailing list with questions, bug reports, feature requests, or just to say you love/hate the software and why.

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

C++ code should be written using C++11 features, should follow the Google C++ style guide for consistency, and should be automatically tested where practical. But don't worry about this too much; I'm much happier to work with you to refine a rough draft patch than never see your contribution at all!

License

This file is part of Moonfire NVR, a security camera digital video recorder. Copyright (C) 2016 Scott Lamb slamb@slamb.org

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two.

You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.