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 is mostly just "cargo fix --edition" + Cargo.toml changes.
There's one fix for upgrading to NLL in db/writer.rs:
Writer::previously_opened wouldn't build with NLL because of a
double-borrow the previous borrow checker somehow didn't catch.
Restructure to avoid it.
I'll put elective NLL changes in a following commit.
It should reduce compile time / memory usage to put quite a bit of the code
into a separate crate. I also intend to limit visibility of some things to
only within the db crate, but that's for a future change. This is the smallest
move that will compile.
* the "lib: {}" print didn't do anything. It turns out that the pkg-config
crate emits the necessary metadata for linking automatically. I had the
wrong format and didn't notice because something else did it correctly.
* gcc::Config is deprecated; the new name is Build.
* and the crate is now called cc, version 1.0.
Stuff found while looking at #11. Still haven't figured that issue out.
This significantly improves safety of the ffmpeg interface. The complex
ABIs aren't accessed directly from Rust. Instead, I have a small C
wrapper which uses the ffmpeg C API and the C headers at compile-time to
determine the proper ABI in the same way any C program using ffmpeg
would, so that the ABI doesn't have to be duplicated in Rust code.
I've tested with ffmpeg 2.x and ffmpeg 3.x; it seems to work properly
with both where before ffmpeg 3.x caused segfaults.
It still depends on ABI compatibility between the compiled and running
versions. C programs need this, too, and normal shared library
versioning practices provide this guarantee. But log both versions on
startup for diagnosing problems with this.
Fixes#7
