af282c309e
This was causing Firefox to fail to play multipart .mp4s which trimmed away a prefix. In the developer console, it said NS_ERROR_DOM_MEDIA_METADATA_ERR without giving any RESULT_DETAIL, making it a pain to diagnose. Given that the stss is supposed to be needed for seeking, I'm surprised it didn't have any immediately obvious impact on Chrome or VLC. Maybe they just took longer to seek than otherwise necessary. The bug was that when keeping track of the "next frame num" while constructing the .mp4, I appended the number in the underlying recording, not the number post-trimming. That meant following segments used the wrong numbers. In some cases, it caused it to exceed the total number of samples in the generated .mp4, which seems to be what Firefox was complaining about. Running the result through "ffmpeg -i bad.mp4 -c copy -f mp4 good.mp4" just trimmed away the most obviously invalid ones, leaving others that didn't point to the frames they meant to. That was enough to make Firefox start playing the file. /shruggie The existing tests were all with a single segment, so I added a new one to catch this. I also added a Debug implementation to recording::Segment and mp4::Segment. |
||
|---|---|---|
| design | ||
| ffmpeg | ||
| guide | ||
| src | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE.txt | ||
| prep.sh | ||
| 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: just a table with links to one-hour
segments of video. Although the backend supports generating .mp4 files for
arbitrary time ranges, you have to construct URLs by hand. There's also no
support for motion detection, no authentication, and no config UI.
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, bug reports, feature requests, or just to say you love/hate the software and why.
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.