You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test convert_yuv_to_rgb_1920x1080 ... bench: 1,362,640.00 ns/iter (+/- 23,317.00)
93
91
test convert_yuv_to_rgb_512x512 ... bench: 174,687.50 ns/iter (+/- 7,185.75)
92
+
test convert_rgb8_to_yuv_1920x1080 ... bench: 369,210.00 ns/iter (+/- 53,579.00)
93
+
test convert_rgb8_to_yuv_512x512 ... bench: 52,333.59 ns/iter (+/- 4,818.80)
94
94
```
95
95
96
96
### Compile Features
97
97
98
98
-`source` - Uses the bundled OpenH264 source; works out of the box (default).
99
99
-`libloading` - You'll need to provide Cisco's prebuilt library.
100
100
101
-
102
101
### FAQ
103
102
104
103
-**How does `openh264-sys2` differ from `openh264-sys`?**
105
104
106
-
We directly ship OpenH264 source code and provide simple, hand-crafted compilation via `cc` in `build.rs`. Our`openh264-sys2` crate should compile via `cargo build` out of the box on most platforms, and cross-compile via `cargo build --target ...` as
107
-
long as the environment variable `CXX` is properly set.
105
+
We directly ship OpenH264 source code and provide simple, hand-crafted compilation via `cc` in `build.rs`. Our `openh264-sys2` crate should compile via `cargo build` out of the box on most platforms, and cross-compile via `cargo build --target ...` as long as the environment variable `CXX` is properly set.
108
106
109
107
-**Which exact OpenH264 version does this use?**
110
108
111
109
See [this file](https://github.com/ralfbiedert/openh264-rust/tree/master/openh264-sys2/upstream/VERSION) for the upstream URL and Git hash used on latest master.
112
110
113
111
-**I need to fix an important OpenH264 security hole, how can I update the library?**
114
112
115
-
Cisco's OpenH264 library is contained in `openh264-sys2/upstream`. Updating is as simple as [pulling their latest source](https://github.com/cisco/openh264),
116
-
and running `update_openh264.sh` (and, if APIs changed, `regen-bindings.bat`).
113
+
Cisco's OpenH264 library is contained in `openh264-sys2/upstream`. Updating is as simple as [pulling their latest source](https://github.com/cisco/openh264), and running `update_openh264.sh` (and, if APIs changed, `regen-bindings.bat`).
117
114
118
115
119
116
-**I heard Rust is super-safe, will this make decoding my videos safe too?**
120
117
121
-
No. Below a thin Rust layer we rely on a _very complex_ C library, and an equally complex standard. Apart from Rust being a
122
-
much nicer language to work with, depending on this project will give you _no_ additional safety guarantees as far as video
123
-
handling is concerned. FYI, this is _not_ making a statement about OpenH264, but about the realities of securing +50k lines
124
-
of C against attacks.
118
+
No. Below a thin Rust layer we rely on a _very complex_ C library, and an equally complex standard. Apart from Rust being a much nicer language to work with, depending on this project will give you _no_ additional safety guarantees as far as video handling is concerned. FYI, this is _not_ making a statement about OpenH264, but about the realities of securing +50k lines of C against attacks.
125
119
126
120
127
121
-**Feature X is missing or broken, will you fix it?**
- Make sure you have the command `nasm` somewhere in your PATH for your current platform (should be a single, standalone
135
-
executable you don't even need to install). If found by `build.rs` it should be used automatically for an up to 3x speed
136
-
boost for encoding / decoding.
137
-
- Also compile your project with `target-cpu=native` for a 3x speed boost for YUV-to-RGB conversion (e.g., check
138
-
our `.cargo/config.toml` how you can easily do that for your project. Note this only works if you are an application,
139
-
not a library wrapping us).
128
+
- Make sure you have the command `nasm` somewhere in your PATH for your current platform (should be a single, standalone executable you don't even need to install). If found by `build.rs` it should be used automatically for an up to 3x speed boost for encoding / decoding.
129
+
- Also compile your project with `target-cpu=native` for a 3x speed boost for YUV-to-RGB conversion (e.g., check our `.cargo/config.toml` how you can easily do that for your project. Note this only works if you are an application, not a library wrapping us).
140
130
141
131
142
132
-**Decoder::decode() returned an error, is this a bug?**
143
133
144
-
Maybe. Probably not. Some encoders can write data OpenH264 doesn't understand, and if _all_ frames fail this could either
145
-
be your encoder doing exotic things, OpenH264 not having implemented a certain feature, or
146
-
us having a bug.
134
+
Maybe. Probably not. Some encoders can write data OpenH264 doesn't understand, and if _all_ frames fail this could either be your encoder doing exotic things, OpenH264 not having implemented a certain feature, or us having a bug.
147
135
148
-
If only _some_ frames fail the most likely reasons are your encoder injecting _some_ special
149
-
packets or transmission errors. In other words, unless you have a controlled setup you should not terminate on
150
-
the first error(s), but simply continue decoding and hope for the decoder to recover.
136
+
If only _some_ frames fail the most likely reasons are your encoder injecting _some_ special packets or transmission errors. In other words, unless you have a controlled setup you should not terminate on the first error(s), but simply continue decoding and hope for the decoder to recover.
151
137
152
-
FWIW, we consider OpenH264's `h264dec` the reference decoder. If you can get it to emit YUV it would be a bug
153
-
if we can't. However, any stream / frame it fails on is pretty much a _wontfix_ for us.
138
+
FWIW, we consider OpenH264's `h264dec` the reference decoder. If you can get it to emit YUV it would be a bug if we can't. However, any stream / frame it fails on is pretty much a _wontfix_ for us.
154
139
155
140
156
141
-**What's the deal with the `source` and `libloading` features?**
157
142
158
143
See [this issue](https://github.com/ralfbiedert/openh264-rs/issues/43).
159
144
160
-
161
145
### Contributing
162
146
163
147
PRs are very welcome. Feel free to submit PRs and fixes right away. You can open issues if you want to discuss things, but due to time restrictions on my side the project will have to rely on people contributing.
@@ -168,19 +152,18 @@ Especially needed:
168
152
-[ ] User-pluggable and color conversions
169
153
-[ ] WASM investigation (either patch, or evidence it can't be fixed)
170
154
-[ ] Feedback which platforms successfully built on
171
-
-[ ] Faster RGB-to-YUV conversion similar to the current SIMD YUV-to-RGB one.
172
-
-[x] Faster YUV-to-RGB conversion (done in [#66](https://github.com/ralfbiedert/openh264-rs/pull/66))
173
155
174
-
Big shout-out to all the [contributors](https://github.com/ralfbiedert/openh264-rs/graphs/contributors) who have filed
175
-
PRs so far.
156
+
Big shout-out to all the [contributors](https://github.com/ralfbiedert/openh264-rs/graphs/contributors) who have filed PRs so far.
176
157
177
158
Special thanks to:
178
159
179
-
- Jannik Schleicher for addressing the long-standing issue of faster YUV-to-RGB conversion, which resulted in a more than 3x speedup.
180
-
160
+
- Jannik Schleicher for 3x faster YUV-to-RGB conversion.
161
+
- Charlie Zheng for 14x faster RGB-to-YUV conversion.
0 commit comments