drop ffmpeg support

* switch the config interface over to use Retina and make the test
  button honor rtsp_transport = udp.

* adjust the threading model of the Retina streaming code.

  Before, it spawned a background future that read from the runtime and
  wrote to a channel. Other calls read from this channel.

  After, it does work directly from within the block_on calls (no
  channels).

  The immediate motivation was that the config interface didn't have
  another runtime handy. And passing in a current thread runtime
  deadlocked. I later learned this is a difference between
  Runtime::block_on and Handle::block_on. The former will drive IO and
  timers; the latter will not.

  But this is also more efficient to avoid so many thread hand-offs.
  Both the context switches and the extra spinning that
  tokio appears to do as mentioned here:
  https://github.com/scottlamb/retina/issues/5#issuecomment-871971550

  This may not be the final word on the threading model. Eventually
  I may not have per-stream writing threads at all. But I think it will
  be easier to look at this after getting rid of the separate
  `moonfire-nvr config` subcommand in favor of a web interface.

* in tests, read `.mp4` files via the `mp4` crate rather than ffmpeg.
  The annoying part is that this doesn't parse edit lists; oh well.

* simplify the `Opener` interface. Formerly, it'd take either a RTSP
  URL or a path to a `.mp4` file, and they'd share some code because
  they both sometimes used ffmpeg. Now, they're totally different
  libraries (`retina` vs `mp4`). Pull the latter out to a `testutil`
  module with a different interface that exposes more of the `mp4`
  stuff. Now `Opener` is just for RTSP.

* simplify the h264 module. It had a lot of logic to deal with Annex B.
  Retina doesn't use this encoding.

Fixes #36
Fixes #126

guide/build.md

@@ -168,15 +168,6 @@ Linux VM and filesystem overlay.
 
 To build the server, you will need the following C libraries installed:
 
-*   [ffmpeg](http://ffmpeg.org/) version 2.x or 3.x, including `libavutil`,
-    `libavcodec` (to inspect H.264 frames), and `libavformat` (to connect to
-    RTSP servers and write `.mp4` files).
-
-    Note ffmpeg library versions older than 55.1.101, along with all versions of
-    the competing project [libav](http://libav.org), don't support socket
-    timeouts for RTSP. For reliable reconnections on error, it's strongly
-    recommended to use ffmpeg library versions >= 55.1.101.
-
 *   [SQLite3](https://www.sqlite.org/), at least version 3.8.2.
     (You can skip this if you compile with `--features=bundled` and
     don't mind the `moonfire-nvr sql` command not working.)
@@ -213,7 +204,7 @@ On macOS with [Homebrew](https://brew.sh/) and Xcode installed, try the
 following command:
 
 ```console
-$ brew install ffmpeg node
+$ brew install node
 ```
 
 Next, you need Rust 1.56+ and Cargo. The easiest way to install them is by

guide/troubleshooting.md

@@ -11,7 +11,6 @@ need more help.
     * [Camera stream errors](#camera-stream-errors)
 * [Problems](#problems)
     * [Server errors](#server-errors)
-        * [Problems reading video from cameras](#problems-reading-video-from-cameras)
         * [`clock_gettime failed: EPERM: Operation not permitted`](#clock_gettime-failed-eperm-operation-not-permitted)
         * [`Error: pts not monotonically increasing; got 26615520 then 26539470`](#error-pts-not-monotonically-increasing-got-26615520-then-26539470)
         * [Out of disk space](#out-of-disk-space)
@@ -88,8 +87,7 @@ Moonfire NVR names a few important thread types as follows:
 *   `main`: during `moonfire-nvr run`, the main thread does initial setup then
     just waits for the other threads. In other subcommands, it does everything.
 *   `s-CAMERA-TYPE` (one per stream, where `TYPE` is `main` or `sub`): these
-    threads write video data to disk. When using `--rtsp-library=ffmpeg`, they
-    also read the video data from the cameras via RTSP.
+    threads receive video from the cameras (via RTSP) and write it to disk.
 *   `sync-PATH` (one per sample file directory): These threads call `fsync` to
 *   commit sample files to disk, delete old sample files, and flush the
     database.
@@ -210,14 +208,13 @@ W20201228 21:27:11.402 s-driveway-sub moonfire_base::clock] writing 37 bytes too
 ### Camera stream errors
 
 Warnings like the following indicate that a camera stream was lost due to some
-error and Moonfire NVR will try reconnecting shortly. In this case,
-`End of file` means that the camera ended the stream. This might happen when the
-camera is rebooting or if Moonfire is not consuming packets quickly enough.
-In the latter case, you'll likely see a `getting next packet took PT...S!`
-message as described above.
+error and Moonfire NVR will try reconnecting shortly. `Stream ended` might
+happen when the camera is rebooting or if Moonfire is not consuming packets
+quickly enough. In the latter case, you'll likely see a
+`getting next packet took PT...S!` message as described above.
 
 ```
-W20210309 00:28:55.527 s-courtyard-sub moonfire_nvr::streamer] courtyard-sub: sleeping for PT1S after error: End of file
+W20210309 00:28:55.527 s-courtyard-sub moonfire_nvr::streamer] courtyard-sub: sleeping for PT1S after error: Stream ended
 (set environment variable RUST_BACKTRACE=1 to see backtraces)
 ```
 
@@ -225,13 +222,6 @@ W20210309 00:28:55.527 s-courtyard-sub moonfire_nvr::streamer] courtyard-sub: sl
 
 ### Server errors
 
-#### Problems reading video from cameras
-
-Moonfire NVR is switching its RTSP handling from ffmpeg to a pure-Rust
-library developed by Moonfire NVR's author. If it doesn't read camera
-data successfully, please try restarting with `--rtsp-library=ffmpeg` to see
-if the problem goes away. Then please file a bug!
-
 #### `clock_gettime failed: EPERM: Operation not permitted`
 
 If commands fail with an error like the following, you're likely running