Ability to bundle/find/download binaries built by Cisco

[torokati44]

Hi!

I'm looking into using this crate for a Rust project (https://ruffle.rs).

However, out of an abundance of caution, I'm not comfortable with either us, or our users, building OpenH264 from source, as the result of that is no longer covered by Cisco's generous licensing.

See http://www.openh264.org/faq.html:

This gives the community the best of all worlds - a team can choose to use the source code, in which case the team is responsible for paying all applicable license fees, or the team can use the binary module distributed by Cisco, in which case Cisco will cover the MPEG LA licensing fees.

Would you consider adding a "safe" option, which doesn't build from source, only acquires/finds/loads the binaries built by Cisco itself?

[ralfbiedert]

Generally yes, but as always it depends on the details.

You mean something like downloading the library at build time, deploy it to target, then libloading into it, right? This might produce some hiccups [1], but maybe their artifacts could be rehosted some other place.

I probably don't have time to fully implement this myself, but I'd accept PRs for it and assist a bit. In any case, this needs some thought on how to make both the 'source', and the the 'libloading' case nice to maintain.

I'd be up for a discussion / call if someone wants to work on this.

[1] Apparently Cisco's deployment infrastructure isn't the best, which might cause other (security, build) issues:

[torokati44]

You mean something like downloading the library at build time, deploy it to target, then libloading into it, right?

Actually, the license requires that the binary is not distributed, but downloaded during/after installation, on the users' machine, directly from Cisco. This is presumably how they can count the number of "deployments" after which they need to pay the license fees to MPEG LA. And this is what Firefox does too, AFAIK.

Apparently Cisco's deployment infrastructure isn't the best, which might cause other (security, build) issues:

Yeah, I'm not happy about this either, but: cisco/openh264#909 (comment)

I probably don't have time to fully implement this myself, but I'd accept PRs for it and assist a bit.

That's completely understandable. In the end, I might go with a fully custom solution, both for the binary acquisition part and the binding generation part, instead of contributing here - sorry about that, it's just easier that way. 😶

I mostly just wanted to bring your attention to the licensing terms, and to the fact that this is a potential blocker for many for using this crate.

[torokati44]

FWIW the libloading integration built into rust-bindgen (using --dynamic-loading) makes this fairly trivial.

[ralfbiedert]

FWIW the libloading integration built into rust-bindgen (using --dynamic-loading) makes this fairly trivial.

Interesting, thanks! Just had a quick look and it appears to produce something. Will give this an hour tomorrow and see where I end up.

[ralfbiedert]

There's a version now on master that you can use like so:

let api = OpenH264API::from_source();
let config = DecoderConfig::default();
let mut decoder = Decoder::with_config(api, config)?;
// ...

or

let api = unsafe { OpenH264API::from_blob(r"/path/to/openh264.dll")? };
let config = DecoderConfig::default();
let mut decoder = Decoder::with_config(api, config)?;
// ...

If you want to use the raw API only (-sys) there's a similar API surface for that.

The whole downloading / SHAnanigans isn't implemented (yet), and there's some discussion needed how that should work. Cisco's FAQ states it should happen during installation, but I haven't read the actual license text if that literally means installation or just some time after installation.

Also should we download / SHA-check in this lib (piles up dependencies, build time, storage paths), or should API-users handle that themselves?

Anyway, feedback welcome.

[ralfbiedert]

The library can now be used transparently either from source, or through Cisco's precompiled binary. I've also added some SHA checks to minimize UB accidents.

I didn't add downloading and bunzipping (up for discussion) to keep dependencies somewhat in check.

Closing for now, feel free to file follow-up issues.

[torokati44]

This is excellent, thank you so much!

Although, as I said, I'll likely end up not relying on this crate; instead, using it as inspiration/reference - which I'll happily acknowledge.
I almost feel bad for "making you do all this for nothing", but actually, IMHO this crate is still better now than it was before, so others may find better use of it.

[ralfbiedert]

No worries, and thanks for pointing me to do the --dynamic-loading which I wasn't aware of.