shaka-project/static-ffmpeg-binaries

1. This repository is a release-engineering project for producing and publishing prebuilt, static FFmpeg binaries. It is not an application runtime; the main “product” is the generated FFmpeg/ffprobe binaries attached to GitHub Releases.

2. The core build pipeline is scripted in shell and centered around build.sh plus the numbered scripts in build-scripts/. Those scripts represent the dependency chain in build order: packages/tooling setup, then codec/library dependencies (libvpx, svt-av1, x264, x265, lame, opus, mbedtls), then the final FFmpeg build, and finally a static-link verification step.

3. versions.txt is the primary configuration input for the build. It defines the source versions that the workflow and scripts use when compiling FFmpeg and its dependencies. get-version.sh reads version information for tagging/release naming, so versioning is part of the build control plane.

4. The repository is designed around a GitHub Actions CI/CD boundary. The workflows under .github/workflows/ split responsibilities: release.yaml appears to drive the full release build and publication flow, build.yaml and test.yaml handle CI validation, while settings.yaml, sync-labels.yaml, and update-issues.yaml support repository automation and issue hygiene.

5. The build matrix is explicitly modeled in build-matrix.json, which likely enumerates the supported OS/CPU combinations. This is what makes the output a multi-platform artifact set rather than a single binary package.

6. Platform detection and environment handling are part of the build system. is-alpine.sh suggests special-case logic for Alpine Linux, while the README’s local-build instructions show that the scripts expect runner-style environment variables such as RUNNER_OS, SUDO, and GITHUB_ENV.

7. There is a clear source-to-artifact flow: upstream source archives are fetched, codec libraries are compiled statically, FFmpeg is linked against them, and the resulting binaries are placed under a build/ output directory. The README specifically calls out build/ffmpeg/ffmpeg and build/ffmpeg/ffprobe as the final outputs.

8. Reproducibility and tamper detection are part of the architecture. The workflow records MD5 sums of the produced binaries, and those sums are included both in workflow logs and in release notes. This creates three consistency points: build logs, published release metadata, and the downloadable artifacts.

9. The repository also contains a small patching layer, such as ffmpeg-nvenc-jammy.patch, which indicates that the FFmpeg source is occasionally adapted for specific platform/toolchain combinations before compilation.

10. The release process is tag-driven. A tag of the form FFMPEG_VERSION-WORKFLOW_RELEASE_NUMBER triggers a release build, and increasing the suffix allows dependency or build-configuration changes without changing the upstream FFmpeg version. That means tags are both version markers and release orchestration inputs.

11. The security posture is intentionally minimal in terms of third-party automation. The README notes only limited use of external GitHub Actions, with mxschmitt/action-tmate reserved for failed builds and only when debug is enabled. This reflects an architecture that prefers local shell scripts and repository-owned workflow logic over opaque build actions.

12. For an architecture diagram, the important boundaries are: upstream source inputs and version metadata on one side; GitHub Actions orchestration in the middle; the shell-based dependency build pipeline and FFmpeg compilation as the processing core; and GitHub Releases plus checksum metadata as the distribution/output layer.