Hmm this is an entirely different issue. If faac made a breaking API change, one needs to talk to Libav upstream (which is not the same thing as FFmpeg upstream — Libav hates FFmpeg) if they want to continue the support. I have no problem removing the option from ffmbc and [email protected], though. We can always add it back if there's an uproar, and I doubt it.
For the record, please refer to https://ffmpeg.org/ffmpeg-all.html#libx264_002c-libx264rgb for FFmpeg's libx264 options. You can always specify an `x264` option with `x264opts` in case there's no native FFmpeg binding available.
https://trac.ffmpeg.org/wiki/Encode/H.264 is a beginner-friendly tutorial and IMO it's sufficient for most people.
> Or vendoring x264 in ffmpeg?
Sure, that's a solution too. However, since only one user — who only stumbled on this when following an online tutorial — ever raised this issue, I would like to see a bit more justification before taking the heavy-handed approach. AKAIK FFmpeg's x264 bindings are already very complete, so if you want to compile x264 with FFmpeg, you might as well just use FFmpeg in the first place.
The difference is that the official binary build of x264 is compiled with lavf support, while ours isn't, for very good reason actually: lavf, i.e., libavformat, is part of FFmpeg, so making x264 depend on FFmpeg would introduce a circular dependency.
I compared our build of x264 and the official binary build. The difference isn't in avisynth support (which enabled in both); the difference is the official build is compiled with lavf support (that is, libavformat), while ours isn't.
As such, I'm afraid this PR does not fix #20172, and IMO basically isn't useful for anything. @ilovezfs
Building x264 with lavf (i.e., libavformat, which is part of FFmpeg) presents a challenge because it would introduce a circular dependency. Probably hard to achieve in Homebrew unless we vendor an FFmpeg inside x264.