Files
spacedrive/.github/scripts/ffmpeg-macos
Vítor Vasconcellos 1c7855ded6 [ENG-630] Windows ffmpeg + libheif custom build (#871)
* Initial Windows ffmpeg + libheif custom build

* Add build steps for most of ffmpeg deps

* FFmpeg deps and libheif

* Fix libheif build

* Fix libvpx and dlfcn + attempt to fix rav1e

* Rework the whole ffmpeg-windows build system
 - New system based on https://github.com/BtbN/FFmpeg-Builds
 - Add new ffmpeg-windows workflow
 - Rename macos ffmpeg workflow
 - Adapt macos setupt script due to above name change

* Forgot to update update the workflow name

* Strip all libs from debug symbols

* Add docs

* Add libde265 deps, required by libheif
 - Make x265, svtav1 and dav1d as shared deps (used by both ffmpeg and libheif)

* Add missing libheif to Linux setup script

* Fix libx265 build script

* Forgot to point x265 ninja install to the correct directory

* Remove libaom and libsvt-av1
 - dav1d and rav1d are our default AV1 decoders/encoders
 - Quote subshell executions
 - Make libweb shared

* Forgot to remove libaom and libsvt-av1 build steps

* Fix typo

* Try force webp to link against static libs

* Revert libwebp to a static build

* Dumb typo

* Modify windows script to download our ffmpeg build (WIP)

* Fix dlls output folder structure

* Fix dumb mistake

* Remove unused ffbuild_enabled

* Enable core's heif feature on Windows
 - Fix windows ffmpeg build not including the headers
 - Fix windows setupt script incorrect download loagic
 - Implement build_arg to pass which repo ref to use when cloning

* Fix windows setup script

* Fix workflow artifact path
 - Make ffmpeg-windows dockerfile respect the FFMPEG_VERSION env

* Fix Windows setup script incorrect logic for downloading ffmpeg builds

* Error out when workflow_runs is empty

* Fix dumb mistake

* Manually define ffmpeg version for windows script

* Fix ffmpeg windows build extract logic

* Fix prop access in windows setup script

* Revert back to a web request because nightly.link does a redirect before serving the artifact content

* Fix windows setup script

* Do not use nightly.link in Github CI

* Fix windows setup script

* Should finally fix window setup script
 - Update ffmpeg-windows deps
 - Should fix ffmpeg-windows failing to build due to mingw changes in new base image

* Fix libxz failing to build due to doxygen

* Fix windows setup-script not executing till the end

* Fix LASTEXITCODE not defined

* Remove libjxl, deps are not being compiled

* Fix dll and lib copy logic

* Move final copy dll logic to external script

* Use main for libjxl

* Change brotli from stable to main
 - Attempt to fix libjxl

* Attempt fix lib copy again

* Split copy_dll logic to avoid cache burst in docker

* Missing file

* Change how to export build files from shared deps

* Replace rsync with cp

* Fix copy

* Fix dir not existing

* Fix pkgconfig

* Remove superflous files from exported ffmpeg for windows
 - Adjust dav1d to not build tools and examples
 - Adjust windows setup-script to point linker to the libs directory

* Fix dav1d meson config args

* Fix dumb mistake

* WORK PLZ

* Fix .lib file location
 - Strip all dlls

* Formatter
2023-06-10 15:23:37 +00:00
..

FFMpeg.framework

Build instructions

To build FFMpeg.framework a docker or podman installation is required. It is recomended to enable BuildKit in docker.

Just run the following inside this directory:

$> docker build -o . .

or

$> podman build -o . .

After some time (it takes aroung 15min in Github CI) a directory named ffmpeg will show up with both a x86_64 and arm64 directory inside, both will have a FFMpeg.framework for their respective architecture.

How does the build process work?

The FFMpeg.framework is built inside an Alpine Linux container that contains a copy of osxcross, which is a cross toolchain that enables building native macOS binaries on Linux. Most of the build process is similar to how you would do it in macOS. The main advantage of using osxcross is that it handles the configuration for both x86 and arm64 and all the required compiling tools without the need for Xcode and with a more direct and easier managment of macOS SDKs. Any required macOS dependencies are handled by a MacPorts-compatible package manager.