moonfire-nvr/ffmpeg/Cargo.toml

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

[lib]
path = "lib.rs"

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

[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"`
			`#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"] }`
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"`