small updates to the top-level README

This commit is contained in:
Scott Lamb 2021-01-21 16:30:46 -08:00
parent 31801e20c3
commit 436217f4d5

View File

@ -37,32 +37,27 @@ make this possible:
pre-encoded H.264 streams in both "main" (full-sized) and "sub" (lower pre-encoded H.264 streams in both "main" (full-sized) and "sub" (lower
resolution, compression quality, and/or frame rate) varieties. The "sub" resolution, compression quality, and/or frame rate) varieties. The "sub"
stream is more suitable for fast computer vision work as well as 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 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 drives costing about $100), so we can afford to keep many camera-months of
both streams on disk. both streams on disk.
* decoding and analyzing only select "key" video frames (see * off-loading on-camera analytics to an inexpensive USB or M.2 neural network
[wikipedia](https://en.wikipedia.org/wiki/Video_compression_picture_types)). accelerator.
* off-loading expensive work to a GPU. Even the Raspberry Pi has a
surprisingly powerful GPU.
* using [HTTP Live Streaming](https://en.wikipedia.org/wiki/HTTP_Live_Streaming) * using [HTTP Live Streaming](https://en.wikipedia.org/wiki/HTTP_Live_Streaming)
rather than requiring custom browser plug-ins. rather than requiring custom browser plug-ins.
* taking advantage of cameras' built-in motion detection. This is * taking advantage of on-camera analytics. This is the lowest CPU usage option,
the most obvious way to reduce motion detection CPU. It's a last resort although many cameras' analytics aren't as good as what can be done on the NVR,
because these cheap cameras' proprietary algorithms are awful compared to they're hard to experiment with, and even when they use modern ML-based
those described on [changedetection.net](http://changedetection.net). approaches, their built-in models can't be retrained.
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 # Documentation
* [License](LICENSE.txt) — GPLv3 * [License](LICENSE.txt) — GPLv3
* [Building and installing](guide/install.md) * [Installing](guide/install.md)
* [Building from source](guide/build.md)
* [UI Development](guide/developing-ui.md) * [UI Development](guide/developing-ui.md)
* [Troubleshooting](guide/troubleshooting.md) * [Troubleshooting](guide/troubleshooting.md)
* [Wiki](https://github.com/scottlamb/moonfire-nvr/wiki) has notes on * [Wiki](https://github.com/scottlamb/moonfire-nvr/wiki) has notes on
several camera models. several camera models. Please add yours!
# <a name="help"></a> Getting help and getting involved # <a name="help"></a> Getting help and getting involved