Improve README Organization and Clarity
The current README has a ton of great information, but itβs a bit hard to navigate and might feel overwhelming, especially for people new to FFmpeg or this project. Iβd like to suggest a few ways we can make it more organized and easier to follow:
Add a proper introduction Start with a brief explanation of what FFmpeg Static Auto-Builds is and why someone might use it.
Reorganize the content Split the README into clear sections like: Overview Auto-Builds Details Release Policy How to Build Targets, Variants, and Addins Package List
Add a Table of Contents Include a TOC at the beginning so people can jump straight to the section they need.
Make it easier to read Use formatting like bold text, bullet points, and tables to highlight key points and make the dense sections easier to scan.
Add simple examples Include some examples of common use cases or commands to show people how to get started quickly.
These changes will make the README much easier to understand and more helpful for everyone, especially new users. Iβd be happy to work on this and submit a PR if this sounds good!
π FFmpeg Static Auto-Builds
Effortless daily builds of FFmpeg for Windows and Linux
This repository provides pre-built static binaries of FFmpeg for Windows (x86_64) and Linux (x86_64), including the latest release branch and master. These builds are designed to simplify the setup process, allowing you to quickly get started with FFmpeg without the hassle of manual compilation.
π Features
- Static builds for easy deployment and use.
- Support for Windows 7+ and RHEL/CentOS 8+ systems.
- Daily auto-builds for cutting-edge updates.
- Tailored builds with different targets, variants, and addins for specific needs.
π Table of Contents
- Supported Platforms
- Auto-Builds
- Release Retention Policy
- Package List
- Building FFmpeg
- Prerequisites
- Build Instructions
- Targets, Variants, and Addins
β Supported Platforms
Windows
- Target: Windows 7 and newer (UCRT required).
- Minimum supported version: Windows 10 22H2.
- No guarantees for anything older than Windows 10.
Linux
- Target: RHEL/CentOS 8 (glibc-2.28 + linux-4.18) and newer.
π Auto-Builds
FFmpeg builds are automatically compiled daily at 12:00 UTC (GitHub's interpretation of the time). These builds include the latest features and fixes from FFmpeg's master and release branches.
Release Retention Policy
- Monthly builds: The last build of each month is retained for 2 years.
- Daily builds: The most recent 14 daily builds are kept.
- "Latest" build: A special floating build pointing to the most recent version is always available.
π¦ Package List
All included dependencies can be found in the scripts.d directory. Each file corresponds to its respective package.
π οΈ Building FFmpeg
If you'd like to build FFmpeg yourself, follow the steps below:
Prerequisites
- bash
- docker
Build Instructions
-
Build the Docker image
./makeimage.sh target variant [addin [addin] [addin] ...] -
Build FFmpeg
./build.sh target variant [addin [addin] [addin] ...] -
Locate the build output
- On success, the resulting
.zipfile will be in theartifactsdirectory.
- On success, the resulting
Targets, Variants, and Addins
Available Targets
| Target | Description |
|---|---|
win64 |
x86_64 Windows |
win32 |
x86 Windows (manual builds only, no auto-builds) |
linux64 |
x86_64 Linux (glibc>=2.28, linux>=4.18) |
linuxarm64 |
ARM64 (aarch64) Linux (glibc>=2.28, linux>=4.18) |
Notes for linuxarm64:
- The following dependencies are not supported due to architecture limitations or cross-compiling restrictions:
davs2andxavs2libmfxandlibva(Intel QSV-related libraries)
Available Variants
| Variant | Description |
|---|---|
gpl |
Includes all dependencies, even those requiring full GPL. |
lgpl |
Excludes GPL-only libraries (e.g., libx264, libx265). |
nonfree |
Adds fdk-aac to all GPL dependencies. |
gpl-shared |
Shared libraries (libav*) with GPL dependencies. |
lgpl-shared |
Shared libraries with LGPL dependencies. |
nonfree-shared |
Shared libraries with nonfree dependencies. |
Optional Addins
- Specify additional options during the build:
- Release Branches:
4.4,5.0,5.1,6.0,6.1,7.0 - Debug Mode:
debug(keeps debug symbols, increases size by ~250MB). - LTO Mode:
lto(enables-flto=auto, experimental, may not work on Windows).
- Release Branches:
π€ Contributing
Contributions to improve this project are welcome!
If youβd like to help, feel free to open an issue or submit a pull request.
π Learn More
For more information on FFmpeg, visit the official documentation.
I just want the most complete variant for windows, which on of these has the most features?
Available Variants
Variant Description
gplIncludes all dependencies, even those requiring full GPL.lgplExcludes GPL-only libraries (e.g.,libx264,libx265).nonfreeAddsfdk-aacto all GPL dependencies.gpl-sharedShared libraries (libav*) with GPL dependencies.lgpl-sharedShared libraries with LGPL dependencies.nonfree-sharedShared libraries with nonfree dependencies.
The "nonfree" variant has the most features because it includes all GPL dependencies (like in the "gpl" variant) and adds fdk-aac, which is a high-quality AAC encoder that is not available in the pure GPL variant.
So, if you want the most complete version with the widest range of features, go with "nonfree".
As newbie to this project, it would be good to mention that one has to download this project as zip(there are "packages" but they are quite old), install docker on the machine(in my case, ubuntu server 22, it was apt install docker docker.io docker-buildx), then run the make image script, warn that this will take soooo long to complete, then to run the build script. Also the addins seem pointless.
You do not need to download anything as a zip file, not sure how you get that idea. If you want to build yourself, you clone the repo via git. Unless you mean the final artifacts for download? The windows ones are indeed zip files for compatibility.
I also don't understand what's supposed to be pointless about the addins? They do exactly what they say.
I can't possibly make the readme a full tutorial on how to do basic shell/docker things. If you want to do more than just download the released artifacts, some existing knowledge is expected.
And yes, depending on how fast your CPU is, it can take a while. On my home-machine it's roughly half an hour for a full build from scratch, with the woarm ones taking significantly longer due to clang being huge.
git or zip download, there is little difference. all i meant is that one needs to get the whole project locally, somehow, there is no command to run that handles it all.
addins, i meant that as i understand it, not using them builds the latest version, using addin pins specific ffmpeg version, if i understand it. so maybe just make it a third optional argument instead of variadic because it is confusing....or maybe i do not understand what they mean at all..
If you want to do more than just download the released artifacts i do not know what that means
as for build time, i am running this on cheap contabo vps with 6gb ram and 4x vCPU AMD EPYC 7282 and build image takes 2 hours and not yet even finished(as i am stuck on that xvid svn). hence the warning how slow this process is. i though it would be few minutes.
That's literally what the addins are, just that there can be more than one. And I'm not sure if 6GB of RAM is enough to build all the dependencies. You might run out of RAM halfway through. Usually I'd aim for 2~4GB per build process, which defaults to one process per CPU core (nproc output).
well, i might have underestimated what is required here. will handle it accordingly in the future. basically all i want is to have a fully-featured ffmpeg for a service that handles encoding videos and don't want to get stuck on some missing functionality(which happened to me with avif).
Then just grab a gpl build. The literal only thing not included there is fdk-aac, due to its weird license.
How do I update the libraries after updating dependencies? Running build.sh uses the already downloaded ones.
make or pull a new image. Also, why do you ask this in this issue randomly?
make or pull a new image. Also, why do you ask this in this issue randomly?
Sorry, probably not the best place, but since it was about improving the README, I thought it would make for a good addition.