Both a "cargo update" and a bump of major versions of a few deps.
I left a few alone:
* base64 because some of the deps depend on 0.11 (and 0.9), so I don't
want to pull in a third version (0.12).
* ring because libpasta depends on this version and I don't want to pull
in two of them.
* time because it's not trivial. Last I checked, time 0.2 couldn't even
do what I wanted at all.
I also made tokio use parking_lot, since I pull it in anyway.
This reduces the binary size noticeably on my macOS machine (#70):
unstripped stripped
1 before switching to clap 11.1 MiB 6.7 MiB
2 after switching to clap 11.4 MiB 6.9 MiB
3 without regex 10.1 MiB 5.9 MiB
A couple reasons for this:
* the docopt crate is "unlikely to see significant future evolution",
and the wider docopt project is "mostly unmaintained at this point".
clap/structopt is more full-featured, has more natural subcommand
support, etc.
* it may allow me to shrink the binary (#70). This change alone seems
to be a slight regression, but it's a step toward getting rid of
regex, which is pretty large. And I feel less ridiculous now that I
don't have two parsing crates anyway; prettydiff was pulling in
structopt.
There are some behavior changes here:
* misc --help output changes and such as you'd expect from switching
argument-parsing libraries
* I properly used PathBuf and OsString for stuff that theoretically
could be non-UTF-8. I haven't tested that it actually made any
difference. I'm also still storing the sample file dirname as "text"
in the database to avoid causing a diff when not doing a schema
change.
db/writer.rs used the word "unflushed" in two ways:
* something which has been communicated to the LockedDatabase object but
not yet committed to disk with SQLite.
* a video sample (aka video frame) which has been written to the sample
file but not yet included in the video index. This happens because the
duration of a frame isn't known until the following frame. These are
always also unflushed in the other sense of the word (as unfinished
recordings are never committed). But they can't be seen by clients at
all, where indexed but uncommitted video frames can.
Replace the latter with "unindexed" to make things more clear. And a
couple minor other style cleanups.
When compiled with cargo build --features=analytics and enabled via
moonfire-nvr run --object-detection, this runs object detection on every
sub stream frame through an Edge TPU (a Coral USB accelerator) and logs
the result.
This is a very small step toward a working system. It doesn't actually
record the result in the database or send it out on the live stream yet.
It doesn't support running object detection at a lower frame rate than
the sub streams come in at either. To address those problems, I need to
do some refactoring. Currently moonfire_db::writer::Writer::Write is the
only place that knows the duration of the frame it's about to flush,
before it gets added to the index or sent out on the live stream. I
don't want to do the detection from there; I'd prefer the moonfire_nvr
crate. So I either need to introduce an analytics callback or move a
bunch of that logic to the other crate.
Once I do that, I need to add database support (although I have some
experiments for that in moonfire-playground) and API support, then some
kind of useful frontend.
Note edgetpu.tflite is taken from the Apache 2.0-licensed
https://github.com/google-coral/edgetpu,
test_data/mobilenet_ssd_v2_coco_quant_postprocess_edgetpu.tflite. The
following page says it's fine to include Apache 2.0 stuff in GPLv3
projects:
https://www.apache.org/licenses/GPL-compatibility.html
Benefits:
* Blake3 is faster. This is most noticeable for the hashing of the
sample file data.
* we no longer need OpenSSL, which helps with shrinking the binary size
(#70). sha1 basically forced OpenSSL usage; ring deliberately doesn't
support this old algorithm, and the pure-Rust sha1 crate is painfully
slow. OpenSSL might still be a better choice than ring/rustls for TLS
but it's nice to have the option.
For the video sample entries, I decided we don't need to hash at all. I
think the id number is sufficiently stable, and it's okay---perhaps even
desirable---if an existing init segment changes for fixes like e5b83c2.
I want to start returning the pixel aspect ratio of each video sample
entry. It's silly to duplicate it for each returned recording, so
let's instead return a videoSampleEntryId and then put all the
information about each VSE once.
This change doesn't actually handle pixel aspect ratio server-side yet.
Most likely I'll require a new schema version for that, to store it as a
new column in the database. Codec-specific logic in the database layer
is awkward and I'd like to avoid it. I did a similar schema change to
add the rfc6381_codec.
I also adjusted ui-src/lib/models/Recording.js in a few ways:
* fixed a couple mismatches between its field name and the key defined
in the API. Consistency aids understanding.
* dropped all the getters in favor of just setting the fields (with
type annotations) as described here:
https://google.github.io/styleguide/jsguide.html#features-classes-fields
* where the wire format used undefined (to save space), translate it to
a more natural null or false.
* As discussed in #48, say "The Moonfire NVR Authors" at the top of
every file rather than whoever created that file. Have one AUTHORS
file listing everyone.
* Consistently call it a "security camera network video recorder" rather
than "security camera digital video recorder".
These apparently were silent until 92c532d mass-upgraded deps.
Apparently eslint returned status 0 despite errors before and now
returns 1.
Most of these were handled by its "--fix" option; I manually took care
of the remaining two:
/Users/slamb/git/moonfire-nvr/ui-src/lib/views/RecordingsView.js
140:1 error This line has a length of 82. Maximum allowed is 80 max-len
/Users/slamb/git/moonfire-nvr/ui-src/lib/views/StreamSelectorView.js
72:1 error This line has a length of 82. Maximum allowed is 80 max-len
Looks like I basically had to do this to keep up. With nodejs version 12
(current LTS), the version of fsevents I installed wouldn't build. A
"yarn upgrade" by itself resulted in a new problem as described in #69.
Conversely, the new versions don't install with nodejs 8. So I bit the
bullet and upgraded all the dev dependency stuff and the nodejs at once.
nodejs 10 seems capable of running either the old or new, fwiw.
I'm a little sad that this seems to have made the UI bundle 5% larger.
Before, "yarn build" said 350 KiB. After, 369 KiB. A little bit in
several places. For example, jquery-ui.bundle.js went from 156 KiB (in
2 chunks) to 160 KiB (in 1 chunk) for some reason.
Apparently WebPack builds in "terser", which is what the cool kids use.
Just go with the default and simplify the configuration as well as
installing fewer node modules.
"babel-minify-webpack-plugin" wasn't actually being used, and
babel-minify is still in beta anyway.
uglifyjs, according to https://github.com/webpack/webpack/issues/7923,
doesn't support ES6 and depends on a package which is no longer
maintained.
* simplify it. Go from six checked-in config files + one local one to
three checked-in configs + commandline options. I find it less
confusing to have the options plumbed through fewer layers.
* support developing against a https production server, as described in
guide/developing-ui.md.
* fix the source map. The sourceMap parameter in prod.config.js as far
as I can tell evaluated to false when run with production config, and
anyway UglifyJS seems to be incompatible with the specified
cheap-module-source-map. Use source-map instead.
The multipart stream / hanging GET approach worked in a prototype for a
single stream, but Chrome has a per-host limit of six connections. If I
try streaming all my cameras at once, I hit that limit. I can't open all
the streams, much less additional connections to load init segments and
such. Websockets apparently has a much higher limit of 256.
Let's follow the Google Style Guide, in which private variables are
simply suffixed with "_". It's a sign, not a cop, but that's fine.
I'd rather keep things simple, and code review should suffice for
catching uses of a private variable outside the class.
This is effective both for Chrome's "Save As" dialog and for curl -OJ.
It makes the filename like 20190717135519-driveway-main.mp4 rather than
view.mp4 (Chrome) or view.mp4?s=33-36&ts=true (Curl).
The reqwest one is particularly notable because it means not having two
versions of hyper/http/tokio/futures/bytes. It also drops a number of
transitive deps; with some work I think I could stop depending on regex
now.
This doesn't take much advantage of async fns so far. For example, the
with_{form,json}_body functions are still designed to be used with
future combinators when it'd be more natural to call them from async
fns now. But it's a start.
Similarly, this still uses the old version of reqwest. Small steps.
Requires Rust 1.40 now. (1.39 is a requirement of async, and 1.40 is a
requirement of http-serve 0.2.0.)
xenial is too old for 6fb346c to work. From comparing release dates, I
think it's reasonable to guess people won't have trouble running
something newer. In particular, there have been two major Raspbian
releases since then, so current Pi systems will be more bionic-like than
xenial-like.
https://wiki.ubuntu.com/Releases
* xenial (LTS) was relesed 2016-04-21
* bionic (LTS) was released 2018-04-26
https://en.wikipedia.org/wiki/Raspbian
* stretch was released 2017-08-17
* buster was released 2019-06-24
https://www.debian.org/releases/
* stretch was released 2017-06-17
* buster was released 2019-07-06
(interesting that Raspbian buster was released before Debian buster)
The codec -> codecpar move was sufficiently long ago (libavformat
57.5.0 on 2016-04-11) that I think we can just get away with requiring
the new version. Let's try it.
But if someone complains, AVCodecParameters and AVCodecContext look
sufficiently similar we could probably just use one or the other based on
the version we're compiling with.
I'm getting deprecation warnings for std::sync::ONCE_INIT, and I'm
not sure when std::sync::Once::new() became a const fn. Just as easy to
switch to parking_lot.
This addressed a deprecation warning on nightly (will be in Rust 1.38).
Use parking_lot instead, which in theory is faster (although I doubt
it's significant here).
Now the test actually has a recording and garbage with matching files.
This caught a few problems in the upgrade procedure:
* it didn't work with foreign keys enabled because the new recording
table was set up after the new camera table, and the old recording
table was destroyed after the old camera table. And now I enable
foreign keys all the time. Reorder the procedure to fix.
* the pathname manipulation in the v2 to v3 procedure was incorrect
since my introduction of nix because I gave it a &[u8] with the
trailing nul, where I should have used CStr::from_bytes_with_nul.
* it wasn't removing garbage files. It'd be most natural to do this
in the v2 to v3 upgrade (with the rename) but I historically removed
the table when upgrading to v2. I can't redefine the schema now, so
do it unnaturally.
I'm considering also renaming all uuid-like files on upgrade to v4/v5
to clean up this mess automatically for installations that have
already done this upgrade.
The immediate motivation is that Cargo.lock referred to a commit version
in a PR branch of my nix fork that no longer exists. (I didn't know, but
it makes sense, that "git push -f" not only forcibly updates the branch
to refer to a new commit but also gets rid of orphaned commits.) Use a
moonfire branch that I'll keep stable until I'm ready to move on.
I also updated parking_lot and rusqlite to new major versions (nothing
in the interface that I care about has changed) and did a full cargo
update.
This is nicer in a few ways:
* I can use openat so there's no possibility of any kind of a race
involving scanning a different directory than the one used in
other ways (locking, metadata file, adding/removing sample files)
* filename() doesn't need to allocate memory, so it's a bit more
efficient
* dogfooding - I wrote nix::dir.
