Static binaries of FFmpeg, for multiple OS & CPU combinations, built from source in a GitHub Actions workflow.

To download binaries, visit the releases page.

The GitHub Actions workflows and other scripts in this repo are covered by the Apache license. Please see the workflow source, API client source, version script source, and see the Apache license for license details.

The resulting FFmpeg binaries are built using GPL libraries, and are therefore published under the GPL license. Please see the releases page for binaries, and see FFmpeg's GPL license for license details.

FFmpeg and its key dependencies are all built from source and linked statically. Each run of the GitHub Actions workflow logs the MD5 sums of the binaries, and it places the MD5 sums into the release notes. You can see how they were built, and you can verify that they haven't been tampered with. The sums in the workflow logs, release notes, and the binaries should all match. You can read the details in the workflow source.

Minimal third-party GitHub Actions have been used in this workflow, to protect against supply-chain attacks. The following actions are used:

• mxschmitt/action-tmate: Used only on failure to debug failed builds, and only if debug is configured at the repo level.

Update the version numbers as needed in the version file, then create a tag on the new commit. Full builds will be triggered, and binaries will be attached to a release on the new tag.

Tag names should follow the form of $FFMPEG_VERSION-$WORKFLOW_RELEASE_NUMBER. For example, the first time we release a build based on FFmpeg n4.4, the tag should be "n4.4-1". If we need to update the dependencies, or change the configuration, or make any other changes to the workflow that don't change the FFmpeg version, the next release would be "n4.4-2". When FFmpeg n4.5 is released upstream, we could update to that and then tag "n4.5-1".

You can do these steps on your actual device, or on a virtual device or container to avoid polluting your system.

1. Set up a build environment (packages, tools, etc) similar to what is done in the workflow source for your OS.
2. If you are using Linux or macOS, run export SUDO=sudo.
3. If you are using Linux, run export RUNNER_OS=Linux.
4. If you are using macOS, run export RUNNER_OS=macOS.
5. If you are using Linux, run export RUNNER_OS=Windows.
6. Set a temp path for GITHUB_ENV, for example export GITHUB_ENV=/tmp/github.env.
7. Create a build folder. For example, mkdir -p build. It does not need to be in the git working directory.
8. Change into that build directory.
9. Create a symlink to the repo root called repo-src to emulate the structure used by the workflow. For example, if build is inside the repo, use ln -s ../ repo-src.
10. Run the build scripts in [build-scripts][] in numerical order.

You can run the above steps automatically in an Ubuntu Docker container with:

docker build -t static-ffmpeg-binaries /path/to/static-ffmpeg-binaries
docker run -v /path/to/static-ffmpeg-binaries:/src static-ffmpeg-binaries /src/build.sh