avbuild: a script for building FFmpeg on nearly every target

A build script for the targets nobody packages FFmpeg for

avbuild is described as a tool to build ffmpeg for almost all platforms, and the project description gives the list: iOS, android, ohos, raspberry pi, win32, uwp, linux, macOS. The README puts it more simply: it's a tool to build ffmpeg for almost all platforms.

The interesting part is which targets those are. The set is not the set of platforms with good FFmpeg packages. It is the set where a developer needs a custom build: a mobile app embedding FFmpeg, a Windows Phone or UWP app, an OpenHarmony device, a legacy Raspberry Pi OS. On desktop Linux and macOS you would normally use a distribution package, and on iOS and Android you normally use a vendor SDK that ships FFmpeg already.

So the audience is a developer who has hit the case where none of those routes exists, or where the packaged build has the wrong configuration.

The primary language is Shell, and the repository layout is what you would expect from a shell-driven tool: avbuild.sh at the root, a set of config scripts that select the build configuration, config-lite.sh, config-lavfilters.sh, config-lite-lto.sh, config-gpl-lite.sh and config-wasm.sh, a patches directory, and a tools directory holding helper scripts such as tools/mklibffmpeg.sh for producing a single shared library.

The licence is LGPL-3.0, with a LICENSE file at the repository root. The last push was on 2026-10-11 and the repository is not archived, and the project has no GitHub releases, so the prebuilt packages on SourceForge are the distribution channel.

The build matrix is the honest part of the documentation

The most useful thing in the README is the build matrix, because it is a table of what works rather than a claim that everything works.

The rows are the compiler toolchain and the columns are the targets: Linux, Android, macOS, iOS, RPi, Win32, WinStore and WinPhone. The cells are letter codes, and the README explains them. A is Apple clang. H is a host build, where clang means open source clang. C is a cross build, with the examples given being building win32 from Linux or macOS using mingw, and building rpi from Windows, Linux or macOS using gcc and clang. A question mark means in plan. An empty cell means the combination will not be supported.

So the matrix says, for example, that Clang plus LLD can host-build Linux, cross-build Android, and cross-build Win32 with either mingw or VCRT120, while Apple clang plus a host build covers macOS and iOS, and GCC gives you host builds for Linux and macOS and cross builds for Win32 and RPi. Apple silicon support shows as A+H for macOS under the Clang and Clang+LLD rows.

This table is more informative than a feature list because it tells you the shape of the support. Host builds dominate, cross builds are available for the mobile and embedded targets, and a handful of cells are explicitly unsupported or planned.

The README also documents a separate set of supported features, and two of them carry real consequences. GPU decoders and encoders are enabled where possible, and the nvidia driver version is not limited, with nvcuvid, nvdec and nvenc supported from 8.0 to 13.0 in a single binary. A binary carrying every NVIDIA encoder across nine driver generations is a large artefact, and it is worth knowing that the project chooses breadth there rather than size.

Prebuilt packages, and the recommended lite variant

You do not have to run the build at all. The README offers downloads of prebuilt packages, with a lite build of the FFmpeg master branch marked as recommended, and links for Android, Apple as an FFmpeg.xcframework, Linux, VS2022 Desktop, VS2022 UWP and a Clang Windows Desktop build.

The recommended variant is the lite build of the master branch, and the naming convention in the file names makes the shape of the outputs clear: the target, the FFmpeg version, the compiler, and the lite or full variant, all in one archive name. The Apple package is an XCFramework, which is the format a modern iOS and macOS app embeds, and the Windows ones come as both a 7-zip archive and a tarball depending on the toolchain.

The homepage points at the SourceForge files area rather than a project site, and the FFmpeg releases and other variants live in the same place. The SourceForge layout is unusual for a GitHub project, and it is where the binaries actually are.

The build status of the project's own CI is published for Linux, android, macOS, iOS, raspberry pi with legacy operating systems, and Windows, with badges for GitHub Actions, Azure Pipelines and CircleCI. Three CI systems for one project is a sign of a build that spans a lot of environments, and it also means a failing badge in one cell is a real signal rather than noise.

One thing the README does not do is promise anything about the age of the prebuilt packages. If you need a specific FFmpeg version, a specific configuration or a recent security fix, the SourceForge directory is the place to look, and the build script is the way to get exactly what you need.

Forking it for your own configuration, through GitHub Actions variables

The section on forking and custom builds by GitHub Actions is the part that turns avbuild from a download into a build system you own, and the mechanism is environment variables set in the repository settings rather than edits to a script.

The variables are named and their purpose is stated. FF_VER takes master or a version such as 8.0 or 6.1. LINUX_SYSROOT_ID takes any characters and is used to update the sysroot cache. LLVM_VER takes an LLVM version such as 22, used by the Linux and Windows builds, with available versions listed at apt.llvm.org. VCVER is the msvcrt version, with 14.28.29333 given as an example, used by the Windows clang build. WINSDKVER is the Windows SDK version, with 10.0.22621.0 as an example, also used by the Windows clang build. VC_LTL_VER is the VC-LTL5 version, for example 5.1.1, used by the Windows build with LTL.

The process is then to fork the repository, set those variables in the GitHub repository settings, edit the workflow files, which are build.yml and build_gpl.yml, removing jobs you do not want such as the SourceForge upload, and then download the FFmpeg binaries from the workflow artifacts. The README adds that you can request that your configuration be added, and that if it is not accepted you customise it yourself.

The two msvcrt and Windows SDK downloads are hosted on SourceForge as dep files, which means the toolchain components are not vendored in the repository. That is convenient for a fork and it is a supply chain consideration for a build that ends up in a shipped binary.

The TODO section lists a single item, Azure pipeline and GitHub action support for vs2022 combined with WSL, which tells you the Windows-on-Linux path was still in progress.

Linking statically, and where the dependencies come from

There is a short section on linking static FFmpeg libraries, and the warning in it is the kind of thing that costs a day if you do not know it in advance.

When you link static libraries into your program, all dependencies must be specified in your linker flags. The dependencies can be found in a dep.7z archive hosted on the SourceForge files area under the dep directory.

That is the whole content of the section, and it is enough. The failure mode it prevents is specific: a static link that resolves the FFmpeg symbols and then fails on a third-party library that FFmpeg itself needed, with a linker error naming a symbol you never asked for. The fix is to enumerate the dependencies, and the archive is where the list lives.

The configuration scripts at the repository root are worth a look before you run anything, since they are where the build variants are defined. There is a lite configuration, a lite configuration with link time optimisation, a GPL lite configuration, a configuration with lavfi filters enabled, and a WebAssembly configuration. The presence of a GPL variant and an LTO variant tells you the author expects people to need specific licence and optimisation combinations rather than one default.

The patches directory is the other part of the project that matters for anyone building a product. FFmpeg patches are how you carry a fix or a feature that upstream does not have yet, and a fork that keeps its own patches is a fork you have to maintain when you move to a newer FFmpeg.

Where avbuild is the wrong tool

The first wrong-tool case is a desktop Linux, macOS or Windows build. Every mainstream distribution packages FFmpeg, and for a server application or a desktop tool the packaged build is a dependency you can pin in a package manager rather than a script you have to run on every build machine. The project covers those targets, but covering a target and being the right choice for it are different things.

The second is a team that needs a reproducible, auditable dependency. avbuild is a shell script that fetches toolchains, patches FFmpeg and produces a binary. The configuration is expressed in environment variables and edited workflow files, and the outputs are archives on SourceForge. That is a fine arrangement for a developer, and a poor fit for an organisation that has to answer where a shipped binary came from and whether it can be rebuilt in a year.

The third is a project that needs a specific codec set rather than a broad one. The lite build is the recommended artifact, and the feature list says GPU decoders and encoders are enabled if possible, with the NVIDIA generations from 8.0 to 13.0 in one binary. If your licence requirements are narrow, that breadth is not what you want, and the configuration scripts are where you would cut it down.

The fourth is a mobile project that has not exhausted the vendor route. If you are building an iOS or Android app, the platform SDK options and the commercial FFmpeg distributions exist and come with support, and a build script maintained outside your organisation is a worse deal than a licence that comes with a support contract.

The fifth is a team without a build engineer. avbuild expects someone who can read a toolchain matrix, set variables for a cross-compiler and a sysroot, and deal with a link error caused by a missing dependency. That is a real skill, and the README is written for someone who has it.

Editorial conclusion

avbuild fits a developer who needs FFmpeg built for a specific target, especially a mobile or embedded target where the toolchain setup is the hard part, and who is prepared to patch and maintain a build script. It is the wrong choice for a desktop Linux or macOS build you can get from a distribution package, and for a team that needs a reproducible, auditable dependency with a supported channel. Before adopting it, read the build matrix entry for your compiler and host pair rather than assuming the cell is filled, and check the dependency list in dep.7z, because every dependency has to be named in your linker flags when you link statically.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. Project website
4. README
5. wang-bin/avbuild on GitHub