How to install FFmpeg from a mirror that publishes no binaries

A GitHub mirror with no release attached

FFmpeg describes itself as a collection of libraries and tools to process multimedia content such as audio, video, subtitles and related metadata, and the copy hosted on GitHub is a mirror of https://git.ffmpeg.org/ffmpeg.git. That one fact decides what this repository is for. It is not archived, the last push landed on 2026-09-29, and the default branch is master, but no GitHub releases exist for it, so there is no tagged archive and no compiled binary sitting beside the source. Anyone who arrives wanting an installer, a Windows build or an official download finds nothing here. What lives here is the tree that produces ffmpeg, ffplay and ffprobe, and the work starts at the configure script.

The README prints no install command, only file names

Not one line of the README is something you can paste into a shell. Where to get the project and how to build it is signposted by the tree itself: INSTALL.md, INSTALL, configure, Makefile and the ffbuild/ directory all sit at the top level, and the Makefile opens by pulling in a file the tree listing never shows.

MAIN_MAKEFILE=1
include ffbuild/config.mak

Those two lines are the whole explanation for why a fresh clone is not a working build. The top-level Makefile delegates to ffbuild/config.mak, and the repository listing gives you the directory without its contents. Read INSTALL.md first, then configure, then make. If you were promised that the ffmpeg binary is one command away, that command is not on this page, and the README does not summarise the dependencies or the switches that INSTALL.md covers.

Seven libraries, and a link order the build will not guess

Decoding, container handling, filtering, colour conversion and device access are seven separate libraries, and the boundary between them is the part worth knowing. libavformat implements streaming protocols, container formats and basic I/O access. libavcodec provides implementation of a wider range of codecs. libavfilter alters decoded audio and video through a directed graph of connected filters, so a filter works on decoded frames rather than on a file. libswresample implements audio mixing and resampling, libswscale implements color conversion and scaling, libavdevice abstracts access to capture and playback devices, and libavutil carries hashers, decompressors and miscellaneous utility functions. The Makefile then orders them for the linker, avutil first and swscale last, with a comment saying $(FFLIBS-yes) needs to be in linking order. Get that order wrong in your own program and the link fails outright rather than the code misbehaving quietly.

The three front ends, and the small tools nobody explains

Adoption splits here, and this is the real fork in the road. Most people take the ffmpeg binary, described as a command line toolbox to manipulate, convert and stream multimedia content, and never touch the libraries underneath. ffplay is a minimalistic multimedia player and ffprobe is a simple analysis tool to inspect multimedia content, and both exist to look at what ffmpeg produced. Teams embedding the pipeline in an application link the seven libraries instead, which means owning decode, the filter graph and output inside one process, along with every configure switch that decided what got compiled in. The same README also names additional small tools such as aviocat, ismindex and qt-faststart, then never says what any of them does. A reader weighing the binary against libavcodec cannot close that gap from this page.

tiny_psnr and tiny_ssim put a number on the output

The build measures itself. The top-level Makefile names seven test tools, audiogen, videogen, rotozoom, tiny_psnr, tiny_ssim, base64 and audiomatch, and turns each into a host program under tests/ next to doc/print_options. Two of them, tiny_psnr and tiny_ssim, compare a produced file against something and report a figure, while the generators produce the material to compare. A vpath entry for %/fate_config.sh.template tells you each test target is expected to bring its own configuration template. So a change to a codec or a filter here is not settled by argument, it is settled by comparison, and the reference files are yours to supply. How to invoke any of it is not covered in the README, so treat the harness as something you read inside tests/ rather than as a documented entry point.

cl.exe cannot write dependency files, so ffbuild/mscl writes them

Windows builds carry an extra program. A comment in the Makefile states that cl.exe cannot write make dependency files directly and that the mscl helper converts its -showIncludes output into .d files. When the dependency flags for CC, CXX, OBJCC, HOSTCC or AS contain -showIncludes, the Makefile substitutes the wrapper for that compiler, adds ffbuild/mscl to the host programs, and builds it from compat/windows/mscl.c. On a toolchain that never passes that flag, none of this fires and the wrapper stays out of the way. Two consequences follow. An MSVC build is not a single compiler invocation, because a helper gets built first, and compat/w32pthreads.h is deliberately excluded from header dependency scanning. Port this tree to another build system and you inherit that work: the wrapper is Makefile-specific, not a general answer.

Patches go to ffmpeg-devel, and GitHub pull requests are ignored

The review path is not GitHub, and the wording leaves no room for doubt: patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email, and GitHub pull requests should be avoided because they are not part of the review process and will be ignored. That sentence decides what a local change is worth. A patch carried on this mirror gets no review here, and with nothing published as a release and the canonical history living at git.ffmpeg.org, keeping it applied across upstream history becomes your job. The last push to this repository was on 2026-09-29 and the project is not archived, so the tree is not standing still. The top level carries RELEASE and Changelog files, and this mirror offers no published release to pin a build against.

LGPL by default, GPL wherever the optional components reach in

Licence is where repository metadata actively misleads. The licence field on this mirror reads NOASSERTION, while the README says the codebase is mainly LGPL-licensed with optional components licensed under GPL and points to the LICENSE file for detail. Four licence texts sit at the top level for exactly that reason: COPYING.GPLv2, COPYING.GPLv3, COPYING.LGPLv2.1 and COPYING.LGPLv3, alongside LICENSE.md. Which copy governs your build depends on the optional components you enable, and the README does not enumerate them, so the question cannot be settled from the repository page. Read LICENSE and the configure options for the build you intend to ship before treating the output as LGPL, because nothing in the metadata will tell you which one applies. What an install lays down is short by comparison: DATA_FILES in the Makefile is only the presets/*.ffpreset files and doc/ffprobe.xsd, so the ffprobe output schema does ship with the build and a script can validate against it.

Editorial conclusion

Adopt FFmpeg as a source dependency when your team needs the seven libav libraries inside its own build and can absorb a mailing-list-driven upgrade path with no release to pin against. Do not adopt it as a download: this mirror publishes nothing binary and documents no install command. Before shipping anything built from it, read the LICENSE file and work out which optional GPL components your configure options pull in, because the repository metadata answers neither question.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository