GHC 2020-08-07

7 comments.

, https://git.io/JJXmV in zmwangx/rust-ffmpeg
codec: implement modern send/receive encoding and decoding APIs
===============================================================

See https://github.com/FFmpeg/FFmpeg/blob/n4.3.1/libavcodec/avcodec.h#L84-L196.

Deprecate the old APIs in v4.4.0.

, https://git.io/JJXUy in zmwangx/rust-ffmpeg
Sorry about the confusion, already merged my cherry picks in f88f1a981c4cc8509d8be5f46e722c97056f4657 (thought you gave me the signal to merge that branch when you deleted your branch), which is effectively your rebased version with a couple of rustfmt fixes.

, https://git.io/JJXUS in zmwangx/rust-ffmpeg
No problem, I already merged the branch into master (assuming you agree that "Tolerate bindgen using u64 instead of usize" isn't necessary).

, https://git.io/JJPAD in zmwangx/rust-ffmpeg
Oh, you force pushed a few minutes ago, so the `std::os::raw` comment is obselete.

> The as _ code allows it to work when cross-compiled for ARM, which happens to pick slightly different types.

Is this still an issue when you factor in the `size_t_is_usize` fix, since `u64` is no longer part of signatures?

, https://git.io/JJPAy in zmwangx/rust-ffmpeg
Thanks, I cherry-picked most of your changes to the [kornelski/miscfixes](https://github.com/zmwangx/rust-ffmpeg/tree/kornelski/miscfixes) branch. Applied some rustfmt style fixes while cherry-picking. You forgot to include the `nb_streams` method in  04bf7ff, so fixed that too.

A couple things:

- 61f5292 More robust C types: not convinced. I'm not sure whether `std::os::raw` is more idiomatic than `libc` (I've heard conflicting accounts), but given that bindgen generates `libc` types I think it's a safer bet.

- 2a678aa Add Send trait to resampling::Context already in;

- cba4671 Tolerate bindgen using u64 instead of usize: I believe I fixed it on the bindgen side (`size_t_is_usize`).

, https://git.io/JJPAS in zmwangx/rust-ffmpeg-sys
I know the `libc++`/`libstdc++` situation on macOS, I didn't realize `libavcodec` and `libavfilter` link to the C++ runtime in `Libs.private` though. I hardly ever bother with static linking on macOS so this slipped my mind.

The fix is very far from ideal though. This should definitely be fixed upstream. The easiest "fix" might be patching `libavcodec.pc` and `libavfilter.pc` directly, which can be done from the Homebrew formula for instance (but as a former Homebrew maintainer I can safely say this isn't a patch Homebrew would accept).

Btw, even with the patch `--features static` doesn't work for me on macOS — it fails during the linking stage with tons of undefined symbols, and I care too little about static linking to track them down...

, https://git.io/JJPaE in zmwangx/rust-ffmpeg-sys
Thanks for the heads up, I cherry-picked most fixes. Two problems:

- I don't understand https://github.com/meh/rust-ffmpeg-sys/commit/6ee9c566dca93fe0738636e7aa073205f0589f79.

  - Why do you need to link to `libc++`/`libstdc++`?
  - The `pkg_config` crate already takes care of printing `cargo:rustc-link-search`, `cargo:rustc-link-lib`, etc., so not sure why there's custom code to print those again.

- https://github.com/meh/rust-ffmpeg-sys/pull/70 just isn't right... I rewrote the thing in d5b361d.