34个版本
| 0.6.2 | 2024年8月1日 |
|---|---|
| 0.6.1 | 2024年6月25日 |
| 0.6.0 | 2024年4月5日 |
| 0.5.0 | 2024年1月8日 |
| 0.0.0 | 2018年9月1日 |
#4 in 视频
2,604次每月下载
在 14 个Crates（13个直接） 中使用
6.5MB
102K SLoC
OpenH264 Rust API
OpenH264的惯用和底层绑定，在Rust中在这两者之间进行转换
示例API
解码一些H.264比特流到YUV
use openh264::decoder::Decoder;
use openh264::nal_units;
let h264_in = include_bytes!("../tests/data/multi_512x512.h264");
let mut decoder = Decoder::new()?;
// Split H.264 into NAL units and decode each.
for packet in nal_units(h264_in) {
// On the first few frames this may fail, so you should check the result
// a few packets before giving up.
let maybe_some_yuv = decoder.decode(packet);
}
并将相同的YUV编码回H.264
use openh264::encoder::Encoder;
let mut encoder = Encoder::new()?;
// Encode YUV back into H.264.
let bitstream = encoder.encode(&yuv)?;
平台支持
在各个平台上的测试结果
| 平台 | 编译 | 单元测试 |
|---|---|---|
x86_64-pc-windows-msvc |
✅ | ✅ |
x86_64-pc-windows-gnu |
✅ | ✅ |
x86_64-unknown-linux-gnu |
✅ | ✅ |
x86_64-apple-darwin |
✅ | ✅ |
i686-unknown-linux-gnu |
✅ | ✅ |
i686-pc-windows-msvc |
✅ | ✅ |
i686-pc-windows-gnu |
✅ | ✅ |
armv7-unknown-linux-gnueabihf |
✅ | - |
aarch64-unknown-linux-gnu |
✅ | - |
aarch64-apple-darwin |
✅ | - |
aarch64-pc-windows-msvc |
✅ | - |
aarch64-linux-android |
🆗1 | - |
wasm32-unknown-unknown |
❌2 | - |
✅ 立即工作；🆗 需要常规的恶作剧；❌ 不受支持。
1 通过 cargo build --target <平台>，需要设置 CXX 变量，并需要 libc++_shared.so。
2 未知是否可以工作，欢迎调查
性能
在i9-9900K，Windows 10上测试，单线程解码和编码
-- Default --
test decode_yuv_single_1920x1080 ... bench: 9,243,380 ns/iter (+/- 497,200)
test decode_yuv_single_512x512_cabac ... bench: 1,841,775 ns/iter (+/- 53,211)
test decode_yuv_single_512x512_cavlc ... bench: 2,076,030 ns/iter (+/- 7,287)
test encode_1920x1080_from_yuv ... bench: 38,657,620 ns/iter (+/- 793,310)
test encode_512x512_from_yuv ... bench: 6,420,605 ns/iter (+/- 1,003,485)
-- If `nasm` available --
test decode_yuv_single_1920x1080 ... bench: 4,265,260 ns/iter (+/- 89,438)
test decode_yuv_single_512x512_cabac ... bench: 901,025 ns/iter (+/- 21,902)
test decode_yuv_single_512x512_cavlc ... bench: 1,618,880 ns/iter (+/- 53,713)
test encode_1920x1080_from_yuv ... bench: 13,455,160 ns/iter (+/- 862,042)
test encode_512x512_from_yuv ... bench: 4,011,700 ns/iter (+/- 2,094,471)
-- Color Conversion --
test convert_yuv_to_rgb_1920x1080 ... bench: 7,226,290 ns/iter (+/- 110,871)
test convert_yuv_to_rgb_512x512 ... bench: 907,340 ns/iter (+/- 28,296)
编译特性
source- 使用捆绑的OpenH264源代码；立即工作（默认）。libloading- 你需要提供思科预构建的库。
常见问题解答
-
openh264-sys2与openh264-sys有何不同？我们直接提供OpenH264源代码，并在
build.rs中通过cc提供简单、手动编译。我们的openh264-sys2Crate 应该在大多数平台上通过cargo build立即编译，并通过cargo build --target ...跨编译，只要正确设置环境变量CXX。 -
此使用哪个确切的OpenH264版本？
请参阅此文件以获取最新master分支中使用的上游URL和Git哈希。
-
我需要修复一个重要的OpenH264安全漏洞，我该如何更新库？
Cisco的OpenH264库包含在
openh264-sys2/upstream中。更新操作非常简单，只需拉取他们的最新源代码，然后运行update_openh264.sh（如果API有所更改，还需运行regen-bindings.bat）。 -
我听说Rust非常安全，这会让我的视频解码也变得更安全吗？
不。在我们的Rust层下面，我们依赖于一个非常复杂的C库和同样复杂的标准。尽管Rust是一种更好的工作语言，但依赖本项目不会为您提供关于视频处理的任何额外安全保证。请注意，这并不是关于OpenH264的声明，而是关于保护+50k行C代码免受攻击的现实。
-
功能X缺失或损坏，你会修复它吗？
目前我只有时间实现我需要的功能。然而，我会很高兴接受扩展API或修复错误的PR；请见下文。
-
我能获得性能提升吗？
请确保您的当前平台上的PATH中存在
nasm命令（应该是一个单独的独立可执行文件，您甚至不需要安装它）。如果被build.rs找到，它应该被自动用于获得高达3倍的速度提升。 -
Decoder::decode()返回了错误，这是bug吗？
可能。可能不是。一些编码器可以写入OpenH264无法理解的 数据，如果所有帧都失败，这可能是您的编码器做了奇异的事情，OpenH264没有实现某些功能，或者我们有一个bug。
如果只有一些帧失败，最可能的原因是您的编码器注入了一些特殊的包或传输错误。换句话说，除非您有一个受控的设置，否则您不应该在第一个错误发生时终止，而应该继续解码并希望解码器恢复。
顺便说一句，我们认为OpenH264的
h264dec是参考解码器。如果您能使其输出YUV，那么如果我们无法输出，就是一个bug。然而，对于任何它失败的流/帧，对于我们来说基本上是一个“不会修复”的问题。 -
关于
source和libloading功能的争论是什么？请参阅这个问题。
贡献
PR非常受欢迎。请随时提交PR和修复程序。如果您想讨论某些事情，可以打开问题，但由于我这边的时间限制，该项目将不得不依赖于人们的贡献。
特别需要
- BT.601 / BT.709 YUV <-> RGB转换
- 更快的YUV到RGB转换
- WASM调查（修补或证明它无法修复的证据）
- 反馈哪些平台成功构建
变更日志
- v0.6 - 编码器支持动态分辨率；API清理。
- v0.5 - 现在可以使用内置源或Cisco的预构建库。
- v0.4 - 更新构建系统，删除未使用的API。
- v0.3 - 将一些API更改为更好地反映OpenH264的行为。
- v0.2 - 添加编码器；
asm功能提供2倍-3倍速度提升。 - v0.1 - 首次发布，仅包含解码器。