add macOS + ARM binaries from osxexperts.net

[jack445]

I have heard that Apple will soon release ARM based Macbooks. Which version of FFmpeg will run in this scenario ? Will the Linux based binary for ARM64 will be compatible with ARM64 Macbooks ?

[derhuerst]

I'm not sure which (ARM) architecture the MacBooks will have, but AFAIK almost all new high-end processors are ARM64. It would be cool if tested this with the ffmpeg binaries and report findings here as soon as they're out.

[jack445]

Thank you, I will also test from my side once I get an ARM based Mac and update any found issues here.

[bobpaul]

There's more to this than just processor architecture. Each OS has its own executable file format, Kernel API, library format, linking system, etc. The latter 2 don't matter as much with these static builds, though I think the linux "static" builds still link to the local glibc.

Linux uses the ELF executable format whereas iOS and OSX use MACH-O executable format with fat binary support. Apple used the fat binary support back when they switched from PowerPC to Intel by having developers build executable files that contained executables for both PowerPC and Intel processors. At some point they deprecated the PowerPC platform and xcode stopped building the PowerPC support. My expectation is that they'll do the same for ARM. For the next several years we'll have fat MACH-O binaries that include both ARM and Intel code and eventually they'll remove support for the Intel computers.

But there's no chance that the Linux binary will run on Mac without something to provide ELF support and mapping the Linux Kernel API calls to OSX API calls. For an example of such a system, look at the WINE project which attempts to make Windows executables run on Unix systems.

tl;dr - None of the existing binaries will run on OSX ARM, but there's a near 100% likelihood that there will be a single binary that runs on both OSX ARM and OSX Intel, but these can't be built until Apple ships the necessary toolchain.

[jack445]

There's more to this than just processor architecture. Each OS has its own executable file format, Kernel API, library format, linking system, etc. The latter 2 don't matter as much with these static builds, though I think the linux "static" builds still link to the local glibc.

Linux uses the ELF executable format whereas iOS and OSX use MACH-O executable format with fat binary support. Apple used the fat binary support back when they switched from PowerPC to Intel by having developers build executable files that contained executables for both PowerPC and Intel processors. At some point they deprecated the PowerPC platform and xcode stopped building the PowerPC support. My expectation is that they'll do the same for ARM. For the next several years we'll have fat MACH-O binaries that include both ARM and Intel code and eventually they'll remove support for the Intel computers.

But there's no chance that the Linux binary will run on Mac without something to provide ELF support and mapping the Linux Kernel API calls to OSX API calls. For an example of such a system, look at the WINE project which attempts to make Windows executables run on Unix systems.

tl;dr - None of the existing binaries will run on OSX ARM, but there's a near 100% likelihood that there will be a single binary that runs on both OSX ARM and OSX Intel, but these can't be built until Apple ships the necessary toolchain.

Thank you for providing this detailed information. It was very helpful. I think we could rebuild ffmpeg on ARM based Mac to have an executable compatible for only ARM Mac. But as you said, It will be great if we could compile a binary that runs on both OSX ARM and OSX Intel. Although the toolchain for this is not yet available, but do you have more information on the process that is used to make such a binary. For example - How the executable was made earlier that was compatible for both PowerPC and Intel ?

[bobpaul]

@jack445 So at WWDC, apple announced Rosetta2 which will allow almost all x86-64 Mac binaries to run on the "Apple silicon" (aka ARM based) Macs. So the existing MacOS binaries will most likely just work. But here's more information on building a "universal binary" that contains both Intel and ARM: https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon

Ultimately it's something that will be solved by https://evermeet.cx/ffmpeg/ and https://ffmpeg.zeranoe.com/builds/ Since the new version of XCode was released during the WWDC, I don't think it will be very long before at least one of them publishes universal binaries.

[jack445]

@jack445 So at WWDC, apple announced Rosetta2 which will allow almost all x86-64 Mac binaries to run on the "Apple silicon" (aka ARM based) Macs. So the existing MacOS binaries will most likely just work. But here's more information on building a "universal binary" that contains both Intel and ARM: https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon

Ultimately it's something that will be solved by https://evermeet.cx/ffmpeg/ and https://ffmpeg.zeranoe.com/builds/ Since the new version of XCode was released during the WWDC, I don't think it will be very long before at least one of them publishes universal binaries.

Thank you. Your information is very helpful. I will keep an eye on the links that you have provided for the universal builds.

[skufly]

Hi, do you have any new information about this topic? Thanks

[stefcarlens]

Any update on this?
FWW https://www.osxexperts.net already supplies FFmpeg for Apple Silicon.
But I need a script so I can build it myself.

[derhuerst]

FWW https://www.osxexperts.net already supplies FFmpeg for Apple Silicon.
But I need a script so I can build it myself.

Have you tried the script mentioned on that site?

I'm not sure I trust them by using their binaries for ffmpeg-static, but the build script looks very reasonable.

[stefcarlens]

Why do you not trust the provided FFmpeg files? That site (and evermeet - but that one apparently is going to stop his service) is for years one of best providers for decent FFmpeg macOS builds.

I did not compile myself yet because I do not have my Mac Mini M1 yet (probably end of the week).

[derhuerst]

Why do you not trust the provided FFmpeg files? That site (and evermeet - but that one apparently is going to stop his service) is for years one of best providers for decent FFmpeg macOS builds.

Okay, I didn't know that.

I did not compile myself yet because I do not have my Mac Mini M1 yet (probably end of the week).

Let me know if it works!

[stefcarlens]

Looking at the script it should compile fine. Except you need to change the arch flag.

--arch=x86_64

to

--arch=arm64

[derhuerst]

Looking at the script it should compile fine.

But does it? Can someone with an M1 confirm?

[ssut]

I've successfully built FFmpeg on my M1 Mac Mini, and have uploaded the build script to https://github.com/ssut/ffmpeg-on-apple-silicon.

ffmpeg version git-2020-12-09-8d19b3c Copyright (c) 2000-2020 the FFmpeg developers
  built with Apple clang version 12.0.0 (clang-1200.0.32.27)
  configuration: --prefix=/Volumes/tempdisk/sw --extra-cflags=-fno-stack-check --arch=arm64 --cc=/usr/bin/clang --enable-fontconfig --enable-gpl --enable-libopus --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-libfreetype --enable-libx264 --enable-libx265 --enable-libvpx --enable-libaom --enable-libvidstab --enable-version3 --pkg-config-flags=--static --disable-ffplay --enable-postproc --enable-nonfree --enable-runtime-cpudetect --enable-cross-compile --cc=/usr/bin/clang
  libavutil      56. 62.100 / 56. 62.100
  libavcodec     58.115.102 / 58.115.102
  libavformat    58. 65.100 / 58. 65.100
  libavdevice    58. 11.103 / 58. 11.103
  libavfilter     7. 92.100 /  7. 92.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
$ lipo -archs ffmpeg
arm64

[derhuerst]

Great! Can you upload the binary? I will create an ffmpeg-static release then.

[ssut]

Great! Can you upload the binary? I will create an ffmpeg-static release then.

As @stefcarlens claimed here ssut/ffmpeg-on-apple-silicon#1, it is not fully statically linked and does not support all the features that OSXExperts' build supports. I will try to build it again and let you know when it's done.

[stefcarlens]

I noticed the osxexperts now have Apple Silicon compiled version with the ARM NEON patch. This makes a huge difference in speed when converting to HEVC. Without that patch x265 is terrible slow and about unusable.
Anyone know were to find this patch?

[coolaj86]

Also, for those that download the Apple Silicon builds either with a browser (as opposed to from the Terminal), you'll want to remove the quarantine bit:

xattr -r -d com.apple.quarantine ffmpeg

And to check you have the correct one is in your PATH:

which ffmpeg
~/.local/bin/ffmpeg

file ~/.local/bin/ffmpeg
/Users/aj/.local/bin/ffmpeg: Mach-O 64-bit executable arm64

[c4b4d4]

Is there any straight-fordward solution to make this module work on M1 arm-based machines? I'm interested in using it inside an Electron App, so any robust solution would make my Electron App more complicated.

[derhuerst]

@kzka90

Regarding Electron:

There's a long discussion in an Electron-based project that used to use ffmpeg-static, but there are several hurdles with the Electron build process. But if you don't use an entirely deterministic/offline build system (they use Flatpack/Flathub), it should be doable. If you have more questions about this, please open a new Issue.

Regarding M1 support:

Someone needs to provide or point me towards reasonably full-featured, static arm64 macOS builds and I'll integrate them into ffmpeg-static. I don't have an M1 Mac, so I can't test if the limitations mentioned above are still in effect.

[Otoris]

@derhuerst I'm new to to FFMPEG stuff. What is missing from this build provided by OSX experts to add support for arm64 M1 Macs? https://www.osxexperts.net

I'm happy to test it with my M1 MacBook Pro and/or submit a PR, I just need a pointer in the right direction for implementation with this library haha.

[derhuerst]

AFAIK the osxexperts.net build script doesn't produce a statically linked binary, so you can't use it without having all the relevant libraries in places where they can be found (e.g. local directories or specific system paths).

You could check if such a binary works standalone, outside of the build directory and with a system that lacks those libraries.

@ssut Do you have an update on #49 (comment) ? 🙂

[stefcarlens]

The builds from osxexperts.net are 100% static. You can use them everywhere. Not sure why you think there are not.
They provide scripts for both Intel and ARM.

[derhuerst]

Because you said so a while ago. 😉

I have never checked though. This issue is just me directing people who want to know about M1 support to comments that other people made about it. 😄

[stefcarlens]

I just checked and the website offers two scripts for creating static builds. One for Intel and one for ARM.
However, they do not explain how to apply the x265 NEON patch which is definitely needed - otherwise without that patch encoding to HEVC is terrible slow on ARM (almost 10x times slower).

But they do offer an ARM build including that patch. Would be great if they share how to patch x265 though.

[derhuerst]

Let's add the osxexperts.net binaries then!

[maxiicodes]

Any updates on this?

[derhuerst]

No updates. Nobody has started working on this.

[emyarod]

I can open a PR but I will need some help with some of the details around releasing etc

[fxbrit]

Also, for those that download the Apple Silicon builds either with a browser (as opposed to from the Terminal), you'll want to remove the quarantine bit:

xattr -r -d com.apple.quarantine ffmpeg

hi! do you have any indication of why that's necessary? I maintain a project on osx and we are facing the same issue with M1 releases.

[name99-org]

Also, for those that download the Apple Silicon builds either with a browser (as opposed to from the Terminal), you'll want to remove the quarantine bit:

xattr -r -d com.apple.quarantine ffmpeg

hi! do you have any indication of why that's necessary? I maintain a project on osx and we are facing the same issue with M1 releases.

You can get some idea of what quarantine is doing and why here:
https://eclecticlight.co/2021/12/11/explainer-quarantine/