moonfire-nvr/ffmpeg/Cargo.toml

[package]
name = "moonfire-ffmpeg"
version = "0.0.1"
authors = ["Scott Lamb <slamb@slamb.org>"]
readme = "../README.md"
edition = "2018"
#links = "ffmpeg"

[lib]
path = "lib.rs"

[dependencies]
libc = "0.2"
log = { version = "0.4", features = ["release_max_level_info"] }
parking_lot = { version = "0.10", features = [] }

[build-dependencies]
cc = "1.0"
pkg-config = "0.3"
use my own ffmpeg crate 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 2017-09-20 21:06:06 -07:00			`[package]`
			`name = "moonfire-ffmpeg"`
			`version = "0.0.1"`
			`authors = ["Scott Lamb <slamb@slamb.org>"]`
			`readme = "../README.md"`
upgrade to 2018 Rust edition 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. 2018-12-28 12:21:49 -06:00			`edition = "2018"`
use my own ffmpeg crate 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 2017-09-20 21:06:06 -07:00			`#links = "ffmpeg"`

			`[lib]`
			`path = "lib.rs"`

			`[dependencies]`
			`libc = "0.2"`
upgrade deps 2018-01-30 22:05:39 -08:00			`log = { version = "0.4", features = ["release_max_level_info"] }`
upgrade deps 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. 2020-04-18 15:44:35 -07:00			`parking_lot = { version = "0.10", features = [] }`
use my own ffmpeg crate 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 2017-09-20 21:06:06 -07:00
			`[build-dependencies]`
minor cleanups to ffmpeg build setup * 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. 2017-10-23 21:07:07 -07:00			`cc = "1.0"`
use my own ffmpeg crate 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 2017-09-20 21:06:06 -07:00			`pkg-config = "0.3"`