Re char: this is not an rpi-specific problem, but rather, an arm problem. I've noticed this before when building a ffmpeg-next revdep on Launchpad (same errors on both armhf and arm64), I didn't bother to deal with it then since I thought it would take a fair bit of effort fixing everything for arm. Turns out this is the only problem... The proper fix is to use `std::os::raw::c_char` or `libc::c_char`. I've pushed d4c64458db38c98a1de4c461ac666e682456b218. Please resolve the conflict.
Re rpi specific formats: okay this one got confusing. These symbols aren't in the upstream source code. I have an rpi 3B (or 3B+? can't recall) so I checked the source packages, and again couldn't find anything. Then I scoured the Internet and finally located the rpi-specific patches in https://archive.raspberrypi.org/debian/pool/main/f/ffmpeg/ffmpeg_4.1.6-1~deb10u1+rpt1.debian.tar.xz:
```console
$ tar xOf ffmpeg_4.1.6-1~deb10u1+rpt1.debian.tar.xz | grep AV_PIX_FMT_RPI
+ { "rpi", rpi_init, HWACCEL_RPI, AV_PIX_FMT_RPI4_8 },
+ { "rpi", rpi_init, HWACCEL_RPI, AV_PIX_FMT_RPI4_10 },
+ *fmt++ = AV_PIX_FMT_RPI4_8;
+ *fmt++ = AV_PIX_FMT_RPI4_10;
+ { AV_PIX_FMT_RPI4_8, MKTAG('S', 'A', 'N', 'D') },
+ { AV_PIX_FMT_RPI4_10, MKTAG('S', 'N', 'D', 'B') },
+ (format == AV_PIX_FMT_RPI4_8 || format == AV_PIX_FMT_RPI4_10);
+ case AV_PIX_FMT_RPI4_8:
+ case AV_PIX_FMT_RPI4_10:
+ .pix_fmt = AV_PIX_FMT_RPI4_8,
+ .pix_fmt = AV_PIX_FMT_RPI4_10,
+ case AV_PIX_FMT_RPI4_8:
+ case AV_PIX_FMT_RPI4_10:
+ case AV_PIX_FMT_RPI4_8:
+ case AV_PIX_FMT_RPI4_10:
+ [AV_PIX_FMT_RPI] = {
+ [AV_PIX_FMT_RPI4_10] = {
+ [AV_PIX_FMT_RPI4_8] = {
+ AV_PIX_FMT_RPI,
+ AV_PIX_FMT_RPI4_8,
+ AV_PIX_FMT_RPI4_10,
+ case AV_PIX_FMT_RPI4_8:
+ case AV_PIX_FMT_RPI4_10:
+ return (format >= AV_PIX_FMT_SAND128 && format <= AV_PIX_FMT_RPI4_10);
+ return (frame->format == AV_PIX_FMT_SAND128 || frame->format == AV_PIX_FMT_RPI4_8);
+ return (frame->format == AV_PIX_FMT_RPI4_10);
```
Okay, this is it. Only problem: my raspbian's `/etc/apt/sources.list` points at http://raspbian.raspberrypi.org/raspbian/, which [only has `7:4.1.6-1~deb10u1`](http://raspbian.raspberrypi.org/raspbian/pool/main/f/ffmpeg/), not http://archive.raspberrypi.org/debian where this rpi-specific `7:4.1.6-1~deb10u1+rpt1` can be found.
I then found some rather confusing explanations of this dual-repo situation online, but bottom line is I'm probably not gonna nuke my current installation by changing the source, and the wimpy 3B would probably take forever and more to compile Rust crates anyway.
Then after a fruitless search for a non-ancient raspbian docker image, I decided to just run an arm64v8/debian:buster image through qemu-aarch64 on an x64 box of mine, and replace the apt sources with the archive.raspberrypi.org one to obtain the rpi-specific version. After waiting for a long time for apt to replace packages with rpi-specific ones, then even longer for qemu'ed rustc, I was eventually able to confirm that your patch works...
Okay, what I'm saying is that it's rather annoying for me to test the compatibility through emulation, and when I merge this I'd be shouldering the responsibility for an arch (plus a set of downstream patches no less) that I'm personally not interested in targeting. So the question is would you mind being the rpi-compatibility "contact person" in the future? That is to say, if and when the rpi patches change and lead to a need for further massages here, you'll be the one cooking up the patch, and I'll just trust your patch without validating myself?