add vp9 support

[mrienstra]

Add vp9 encoder using --enable-libvpx as per https://trac.ffmpeg.org/wiki/CompilationGuide/macOS#Additionallibraries

Minor (I can back this out), I moved --enable-libx264 below --enable-gpl as that seemed more idiomatic. [edit: never mind, looked upstream, putting it back to support easier comparison to upstream]

Tested locally. I didn't include artifacts as I don't have cargo installed, saw rav1e encoder will not be available warning, not sure which version of rust is needed. [edit: looked upstream, looks like this warning is not meaningful w/o --enable-librav1e]

I can add artifacts if you'd prefer.

Using this build, I was able to use "smart cut" with a vp9 + aac .mkv file, which prior had not been possible, for obvious reasons.

Edit: According to the sources below, libvpx is already available in all the other static binaries supplied by https://github.com/mifi/ffmpeg-builds:
darwin-x64: https://evermeet.cx/ffmpeg/
linux-x64: https://johnvansickle.com/ffmpeg/release-readme.txt
win32-x64: https://www.gyan.dev/ffmpeg/builds/#libraries

Edit: Comparison of the various builds: https://gist.github.com/mrienstra/f6cf49b530f14a072cd6d56354fcba04 -- thinking it might be wise to bring the darwin-arm64 build a little closer to the other 3, to reduce the likelihood of issues like the one this PR is addressing -- something that is broken when using darwin-arm64, but works everywhere else.

[mifi]

Cool! The reason why I can't just blindly enable everything is that App Store is quite strict so they will reject apps that are using many of the APIs like libxcb for example, so that's why this build has been stripped down to minimum. But I think we could probably add vp9 support, I just need to do some more testing

[mrienstra]

Makes sense @mifi! They aren't exactly well-known for being consistent, but for what it's worth: the darwin-x64 build (which passed App Store review) includes quite a few ffmpeg libraries the darwin-arm64 build does not, and in theory they should be fine with those libs being in both builds. You can see those in the gist I shared above.

[mifi]

Actually I don’t use the darwin-x64 (https://evermeet.cx/ffmpeg/) build in losslesscut. That’s the build that failed App Store review, and it’s the reason why i made this repo. darwin-x64 is built by github actions in this repo. darwin-arm64 is built by me locally on my M2 mac using the script in this repo (because github doesn’t support arm64 runners yet)

Btw i dont think it’s enough to simply append --enable-libvpx - we’d also have to build libvpx first, similar to libx264 (see the upstream forked repo)

[mrienstra]

Re: not using evermeet.cx build: ah, gotcha, I see that now in mifi/lossless-cut package.json#L14, I was basing that on mifi/ffmpeg-builds v5.1.2 release notes which shows evermeet.cx as the source for darwin-x64.

Re: building libvpx: Seemed fine without it for me, but maybe that's one of those "it works on my machine" things, maybe it's using a local libvpx from a prior ffmpeg build or something, dunno.

I went ahead and changed that, so this PR is now building libvpx as per upstream. Tested locally, working as expected with LosslessCut.

Might be possible to use cirruslabs/tart, looks do-able via Cirrus CI, which is free for open-source repos. Ran across in actions/runner-images#2187, haven't tried it myself. Using a Cirrus Runner with GitHub Actions would be a lot more plug-n-play, but doesn't look like there's a "free for open source" option for that.

[mifi]

yes it probably used your local libvpx on your computer. i had the same problem back in the day when trying to get this to work for app store. everytthing needs to be statically built into the library.

it would be cool if we could build this using github actions on arm macos, but i don't have time to look into that now

thanks!