Synchronize with meh/rust-ffmpeg-sys

[rib]

I ended up doing a detailed comparison of the meh/rust-ffmpeg-sys repo and this one to try and understand the differences and determine which one to use.

While doing this I basically ended up creating a branch that cherry picked all the the changes that brought this repo into sync with the meh/rust-ffmpeg-sys repo. (and I did a similar thing going the other way for a few changes that were missing from the meh/rust-ffmpeg-sys repo: meh/rust-ffmpeg-sys@master...rib:rust-ffmpeg-sys-meh-zmwangx-sync)

Although some of the latter Cargo.toml or README.md tweaks might not make sense to take, I figured I'd share the branch in case it's helpful to review.

Ideally it seems like it could be good if we could consolidate these two projects if possible.

It would also be great if this repo could also be set up as a fork of meh/rust-ffmpeg-sys repo while it's currently particularly tricky to track down the various developments being done by different people across these rust-ffmpeg repos on Github because Github sees this (and zmwangx/rust-ffmpeg) as completely unrelated projects.

[jwiesler]

Hey, I forked the sys crate and the ffmpeg-next crate and merged most of the current merge requests of both crates (including yours). If you have no problem with using a non crates.io crate, you can use this one. I will keep merging pull requests because these repositories seem mostly abandonded.

[rib]

@jwiesler I think at the moment the original repos from @meh are receiving some changes so it could be good to check those out more closely. I would also recommend forking from meh's repos ideally because it's quite awkward that @zmwangx didn't use github to originally fork from meh and so the github network view isn't able to relate this back to the original projects from meh. (so it could be nice to avoid perpetuating this rift by forking from meh instead now that it looks like these repos aren't being developed any more)

These are the original repos:

https://github.com/meh/rust-ffmpeg-sys
https://github.com/meh/rust-ffmpeg

For reference in case it's useful you might also want to take a look at meh/rust-ffmpeg#142 too

[jwiesler]

I'd like to switch to the original crate but since they are so out of sync I don't really want to switch right now. Furthermore, the issue you mentioned is inactive (duh) since over two months.
I just started those forks to allow people using the current version of the crate to keep using it without having to change everything in their code base because the apis do not match or features are missing.

And I dont know if I can just change the forking point to meh's repos because I definitely don't want to redo everything.

[rib]

Yeah, even though there's not been any update to that PR I think @kornelski has cherry picked a few things separately. It's also tricky to tell but quite a lot of the changes that have been done here have already been folded back into meh's branch by @meh and @kornelski.

Unfortunately though it's all kind of a tangle to unravel which is a real shame for anyone wanting to try and pick up the pieces.

I did spend quite a bit of time/effort reconciling the branches in that PR referenced above - you could consider starting with that perhaps, since it's already based on meh's branch. (If you're based on zmwangx's branch I think you'll also be missing a whole bunch of work done over on meh's branch since around December last year). But yeah, there were some notable API breakages with rust-ffmpeg so it is a kind of a difficult situation now. There's a slim chance that my branch included the API changes you depend on, and is also based on meh's branch.

When it comes to the rust-ffmpeg-sys branch I think at this point meh's branch has everything so we can pretty much just switch back to using that.

[rib]

Just checking the commits to meh's branch since I made that PR at the beginning of March it does actually looks like quite a few things have been cherry picked across, including the packet APIs like send_packet and receive_frame (those were some of the APIs I found I was depending on in zmwangx's branch) so maybe it's not too tricky to switch at this point - if you're lucky maybe it's API compatible for what you depend on?

@jwiesler If it's not API compatible maybe it's worth opening an issue just to let @meh and @kornelski know what's currently blocking you from switching over from this branch and they might be able to help if there's some change that still hasn't been cherry picked back.