[FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

Werner Robitza werner.robitza at gmail.com
Sun Feb 10 20:37:11 EET 2019


On Sat, Feb 9, 2019 at 11:59 PM Jean-Baptiste Kempf <jb at videolan.org> wrote:
>
> On Sat, 9 Feb 2019, at 11:59, Werner Robitza wrote:
> > Then the only consequence can be to remove these options or support
> > for these libraries altogether, because you'll find plenty of guides
> > and recommendations on how to build ffmpeg with non-free libs on the
> > Internet – even supplied by members who are very active in the FFmpeg
> > community. It is certainly your prerogative to be against explicit
> > advertising, but where do you draw the line? Has there been any
> > precedent with this, or is this going to be decided on a case-by-case
> > basis?
> >
> > The only consequence would be a formula that is not owned and
> > controlled by FFmpeg, and people will continue to build non-free
> > binaries.
>
> But then, it is not the project, doing it, but someone else.

The project won't be building non-free binaries and ship those to
people. It's the users who will do it on their machine.

> To come back to the main topic, you can have a full FFmpeg in homebrew with all the libraries activated by default, if you want, without any issue.

No, that's not the case.

> I therefore do not see at all the need for options.

They are needed since not everyone wants or needs a full-featured
ffmpeg with all third-party libraries. There can be sane defaults,
like there have been for years, and some libraries can be enabled
optionally.

> Those options are just for non-free cases, and to be honest, I don't see why FFmpeg should advertise those.

That is not correct. The following options/dependencies are not
present in Homebrew core:

chromaprint, fdk-aac, game-music-emu, libbs2b, libcaca, libgsm,
libmodplug, librsvg, libssh, libvidstab, libvmaf, openh264, openssl,
srt, two-lame, wavpack, webp, zeromq, zimg


More information about the ffmpeg-devel mailing list