FFmpeg Compilation Guide
This page contains a list of resources which describe the necessary steps required for compiling FFmpeg from scratch.
The following page provides generic compilation and installation instructions: Generic compilation guide
Attention: If you are using gcc-4.2 please read ticket 1464 first, and try to update your compiler. A message to that effect is printed on running configure off the master branch.
- CompilationGuide/MinGW – MinGW Compilation Guide for compiling FFmpeg with Windows/MinGW/MSYS.
- CompilationGuide/CrossCompilingForWindows – Cross compiling for Windows is sometimes easier than using MSYS+MinGW.
- CompilationGuide/WinRT - Compiling FFmpeg for Windows Apps (Windows 10 and Windows 8.1)
- CompilationGuide/MSVC - Compiling FFmpeg using MSVC (see also the instructions on the reference web page)
- How to compile FFmpeg for Raspberry Pi (Raspbian)
- How to compile FFmpeg for Android
- How to cross-compile FFmpeg for MIPS
- How to compile FFmpeg for Haiku
There are numerous avenues to extract maximum performance out of FFmpeg when it is built from source. The following list describes some of them:
- If using GCC, consider adding -ftree-vectorize to --extra-cflags. Most recent versions of GCC do not miscompile FFmpeg with the auto-vectorizer enabled, and can easily reap a general 1-2% increase in performance from a FATE run (make fate-rsync; make fate), with gains varying across the codebase and compiler version. However, the project does not currently maintain a list of compiler versions under which the vectorizer works correctly, since even recent releases like 4.8.0 had problems. Therefore, configure by default disables the auto-vectorizer on GCC, and it must be enabled by the user explicitly if desired, such as via the method outlined above. It is highly advised to test at least a FATE run to ensure that things work correctly when the auto-vectorizer is turned on.
- If using GCC/Clang, consider adding -march=native to --extra-cflags to make slightly better use of your hardware. Alternatively, for a more general solution, examine the --arch and --cpu options. Gains are variable, and usually quite small. However, this is usually even more safe than the above, and is thus listed here.
- Depending on your use case, --enable-hardcoded-tables may be a useful option. It results in an increase of approximately 15% in the size of libavcodec, the main library impacted by this change. It enables savings in table generation time, done once at codec initialization, since by hardcoding the tables, they do not need to be computed at runtime. However, the savings are often negligible (~100k cycles is a typical number) especially when amortized over the entire encoding/decoding operation. By default, this is not enabled. Improvements are being made to the runtime initialization, and so over time, this option will have an impact on fewer and fewer codecs.
- Other options may be found by examining ./configure --help.