FFmpeg Compilation Guide

This page contains a list of resources which describe the necessary steps required for compiling FFmpeg from scratch or with the help of build scripts and/or package managers.

All platforms

Read the Generic compilation guide, regardless of your platform. It provides generic compilation and installation instructions, including the use of configure .

• CompilationGuide/vcpkg – vcpkg also aims to be portable accross all platforms. For windows it uses MinGW/MSYS compilation toolchain.

Linux

Alternative ways to obtain/compile ffmpeg under Linux:

macOS

Windows

• 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 MSYS+MSVC, see also:
  • ​ Instructions on the reference web page
  • ​ Roxlu’s guide

Using external scripts or tools:

• ​ Media Autobuild Suite – Automatically build FFmpeg under Windows
• ​ Linuxbrew, which can be used with Windows Subsystem for Linux (WSL)
• ​ Chocolatey – a package manager for Windows with an FFmpeg package

Other Platforms

Performance Tips

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/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 .

MinGW/FFmpeg installation guide

Contents

Introduction

In order to compile FFmpeg on Windows, you need to install the MinGW environment and a few tools which are strictly required. The following sections give some indications for installing some of the required components.

Tip: The ​ Media Autobuild Suite can automatically build FFmpeg under Windows with several external dependencies. You can still follow this guide if you want to manually compile FFmpeg.

Note that the only strict requirement for compiling a plain vanilla version of FFmpeg (no external libraries) is MinGW (compilation environment) and Git required for downloading and updating the source code.

Also note that sometimes it is easier to cross compile, see the Cross Compiling guide, which also may contain some hints/clues for compiling the various dependencies you’d need using MinGW, too.

Some Windows-specific compilation information can be found in the ​ official documentation.

Installing Requirements

MinGW

You have two options for a compiler:

Both offer working gcc s for Windows. The first tends to be slightly more up to date than the latter, and offers more library compatibility, like DirectShow headers, so preferably use MinGW-w64.

The MinGW package provides gcc and headers.

Option 1: MinGW-w64

This project does not have downloadable compilers by default; you’ll probably want the ​ «mingw-builds» project, which provides pre-built compilers.

To use MinGW-w64, install Msys using the MinGW setup, as above, but only check the «msys for developers option». Then ​ install a MinGW-w64 compiler. ​ Here is an example.

Then configure your PATH appropriately, for instance mine looks like this:

In this case, the MINGW_PATH would be:

To access DirectShow input devices you have to use MinGW-w64 as the compiler (or cross compiler), as straight MinGW headers don’t have this functionality.

To install libraries you’d either use

The latter if you wanted to install something to your MINGW_PATH itself.

Option 2: MinGW «mainline»

Go to ​ http://www.mingw.org and look for the «Download» page.

The recommended way to install MinGW/MSys is through the automated installer, mingw-get-setup.exe .

This will download most of the basic core packages. It will usually install in C:\MinGW but you can define the installation path when configuring. Note down this path (that we will call as «MinGW path» or MINGW_PATH later in this guide).

Once you install MinGW you should see in the Windows menu the «MinGW» entry with the option «MinGW shell». Click on it and it will launch a terminal with a bash shell. This is supposed to be a GNU/Unix environment, and you’re supposed to know a bit of UNIX commands for getting through it. Alternatively, or in case the MinGW entry is missing, you need to manually launch the MINGW_PATH/msys/1.0/msys.bat file.

MinGW adopts a mounting mechanism to make Windows directories appear like native UNIX-like paths. Check the output of the mount command, and familiarize yourself with the mapping mechanism. In the rest of the guide, when not explicitly specified, we’ll use the UNIX mapped paths.

Note that by default the user home will be placed in MINGW_PATH/msys/1.0/home/USER , and that will be your working directory of the msys shell.

Finally, you need to edit the system environment PATH variable, adding the MINGW_PATH/bin directory. This will allow both the system and the msys shell to find programs provided by MinGW. This can be done for example with:

Msys provides shell utilities like make and bash . Choose either MSys or MSYS2.

Option 1: MSYS

Then run its console. You will be able to then run configure (assuming you’ve installed a gcc to your PATH already).

Option 2: MSYS2

Then run the mingw32_shell.bat or mingw64_shell.bat command in the MSYS2 installation home. Be careful not to run the MSYS2 Shell as this will result in FFmpeg’s configure saying building an MSYS binary is not recommended and exiting.

Now install requisite packages:

Alternatively, you can also install GCC from MSYS2 system itself, and not need any of the MinGW-w64 instructions above:

MSYS2 comes with a package management system called pacman adopted from Arch Linux, and allows to easily install binary packages from the commandline. To compile FFmpeg, you need to install the mingw-w64 GCC environment (either in the i686 or x86_x64 flavor). Use one of the commands:

This installs «gcc.exe» commands that are actually built for MSYS2 but are the windows gcc compilers. Configure and make as normal.

If you use MSYS2 many packages can be easily installed by using pacman (for example pacman -S pkg-config ).

Unfortunately the gcc.exe it provides seems to create binary’s that require files like «libgcc_s_dw2-1.dll» and «libwinpthread-1.dll» (etc.?) to accompany your executable, so can cause some difficulty there. You can remove some files to remove dependencies on things like «libbzip2.dll» see ​ https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=3688 and possibly avoid the libgcc.dll requirement by using «-static» at linking time.

MinGW Installation Style

It is a good norm to keep the locally installed packages separated from the MinGW/MSys packages. For this reason we recommend to use /usr/local for locally installed files. That means that packages will be configured with —prefix=/usr/local . For removing the local packages it will be sufficient to erase the /usr/local directory.

This should also avoid conflicts with MinGW/MSys.

Git is the source code control system used by FFmpeg, and you need it for downloading and updating the source code.

The official Git project site ​ is here. The recommended installation way is through the ​ Git for Windows project.

The autoinstaller will create a separate Msys environment for Git. In order to be able to let your MinGW and msysgit coexist on the same system you need some tuning in the Windows environment. Indeed the msysgit installer will modify some of the environment values set by the MinGW install, and you may need to manually restore them.

In particular, you need to:

• Fix the HOME variable, so that it will point to $MINGW_PATH/msys/1.0/home/$USER

• Edit the path, so that the git bin and cmd paths are located after the corresponding MinGW bin directory.

YASM is a non-strict requirement; it allows for optimized compilation so it is recommended to install it. The easiest way to install it for Windows is by simply downloading the ​ binary provided.

You’ll have to choose between the versions provided (e.g. 32 vs 64 bit), download and install it in /usr/local/bin or in /bin .

Since the name of the binary is usually suffixed with the program version (e.g. it is named yasm-1.1.0-win32.exe ), you need to create a copy named yasm , so it can be invoked by using simply yasm .

Alternatively you may install the source version and compile it.

In case the system is complaining about a missing MSVCR100.dll file when trying to run yasm, you may need to install the Microsoft Visual C++ 2010 SP1 Redistributable Package from Microsoft.

SDL is required for ffplay and the SDL output device. You need the ​ 1.2 version.

Once installed in the MINGW_PATH , the FFmpeg configure should be able to auto-detect it.

Note that SDL flags, as issued by sdl-config/pkg-config, contain the -mwindows flag which will prevent applications to log on console. As a workaround you’ll need to remove that flag, e.g. by editing the sdl-config script or the SDL pkg-config file in lib.

libx264

​ libx264 can be compiled and installed in the MinGW+MSys environment.

If you want libx264.dll files (instead of static) you should use the —enable-shared configure option.

The only way I was able to figure out how to get this to work was to add —extra-ldflags=L../libx264_unpacked_dir —extra-cflags=-I../libx264_unpacked_dir to my ffmpeg configure line, after successfully building libx264.

lib.exe

lib.exe is required for creating .dll.a import stub libraries, so that you can link to the DLLs from MSVC (Microsoft Visual Studio compiler, bundled with it), if you are planning on creating a DLL style FFmpeg build and need/want to do that.

lib.exe is a Microsoft tool used for creating DLL files. It is bundled together with Visual Studio. Microsoft Visual Studio Express download is available for free. Once installed you’ll need to add the directory where lib.exe is located to the system path.

dlltool.exe (which is part of binutils) may be used instead of lib.exe . The downside in this case is that the import libraries break if you use the linker optimization option in MSVC (which is enabled by default).

DirectShow

DirectShow SDK is required for DirectShow capture, supported through the dshow input device. DirectShow support is enabled only through mingw-64 compilation.

For more detailed information related to DirectShow check the dshow section in the FFmpeg manual.

OpenAL

Required for acquiring from the audio device using the ​ OpenAL framework.

Download and install the SDK (the file named like «OpenAL11CoreSDK.zip»), then configure with —enable-openal (you may need to add —extra-cflags and —extra-ldflags for specifying where OpenAL libraries and headers are placed). Note that you may also need to move all the headers in the include dir to a separate «AL» directory, which is where FFmpeg will look for the OpenAL headers.

pkg-config

pkg-config is a program used by many software libraries (FFmpeg included) for determining the compilation flags to use. It is not installed by default by MinGW, so you need to manually install it.

There is also a related MinGW FAQ:

pkg-config can be found at one of these addresses:

At this point you need to install the following packages:

• GLib (Binaries)
• gettext-runtime (Binaries)
• pkg-config (Binaries)

gettext-runtime contains the intl.dll (GNU Internationalization Library) which is required by pkg-config.

Configuring FFmpeg

To configure a basic build you just need to run ./configure in the FFmpeg source directory.

Once you installed all the necessary packages (MinGW is the only strict requirement for building FFmpeg, git is required to update your FFmpeg source), you need to open a MinGW shell, change directory to where you checked out the FFmpeg sources, and configure and make FFmpeg the usual way.

Note that under MinGW, configuring can be painfully slow.

Windows Compilation Tips

• You may want to use ​ Dependency Walker for troubleshooting dependency issues. depends.exe is similar in purpose to ldd .

• Working with a Windows native terminal can be painful, especially if you have a non-US/EN keyboard and you have no means to type special characters like ‘

  ‘. ​ AutoHotKey is a nice FLOSS project which allows to compose shortcuts and do other nifty things.

More Resources

You can find many resources dedicated to FFmpeg in Windows in:

At this address you can find a MinGW environment used for MPlayer, as well as FFmpeg builds:

The following project has a script for cross compiling lots of FFmpeg dependencies, and may contain hints as to how to get them working with mingw:

Ffmpeg windows build mingw

This helper script lets you cross compile a windows-based 32 or 64-bit version of ffmpeg/mplayer/mp4box.exe, etc, including their dependencies and libraries that they use. Note that I do offer custom builds, price negotiable. Ping me at rogerdpack@gmail.com and I’ll do the work for you 🙂

The script allows the user to either build on a Linux host (which uses cross compiles to build windows binaries). Windows users can use windows bash or virtualbox. Building on linux takes less time overall. On Windows 10, you can use the bash shell (provided that you’ve installed the Windows Subsystem for Linux as explained here. Building in windows takes longer but avoids the need of deploying a Linux installation for the same purpose. I do have some «distribution release builds» of running the script here: https://sourceforge.net/projects/ffmpegwindowsbi/files

Cross-compiling from a Linux environment:

You can build the project on Linux with a cross compiler toolchain, taking about 2 hours for the «options» build.

Deploy a Linux VM on the host of your choice (> 14.04 for Ubuntu), or natively on an extra computer or a dual boot system, and also, you could even create a VM temporarily, on a hosting provider such as Digital Ocean. Cheapest way: install windows 10 bash shell. Another option: linux on a virtualbox VM. Another option, typically fastest: temporarily rent a box (ex: DigitalOcean https://m.do.co/c/b3030b559d17 )

Download the script by cloning this repository via git:

Now run the script:

Answer the prompts. It should end up with a working, statically-built ffmpeg.exe binary within the » sandbox/*/ffmpeg_git » director(ies).

Another option instead of running ./cross_compile_ffmpeg.sh is to run

Note the «quick» part here which attempts to use the locally installed mingw-w64 package from your distribution for the cross compiler, thus skipping the time-intensive cross-compiler toolchain build step. It’s not as well tested as running the normal one, however, which builds gcc from scratch.

For Mac OSX users, simply follow the instructions for Linux above.

To view additional arguments and options supported by the script, run:

to see all the various options available.

For long running builds, do run them overnight as they take a while.

If you want to build a «shared» build (there’s a command line option for that 🙂 then link it into your MSVC project see https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=5&t=796&p=4095#p4095

Also note that you can also «cross compile» mp4box, mplayer,mencoder and vlc binaries if you pass in the appropriate command line parameters. The VLC build is currently broken, send a PM if you’d want it fixed.

To enable Intel QuickSync encoders (supported on Windows vista and above), which is optional, pass the option —build-intel-qsv=y to the cross-compilation script above. There is also an LGPL command line option for those that want that.

If you want to customize your FFmpeg final executable even further ( to remove features you don’t need, make a smaller build, or custom build, etc.) then edit the script.

1. Add or remove the » —enable-xxx » settings in the build_ffmpeg function (under config_options ) near the bottom of the script. This can enable or disable parts of FFmpeg to suit your requirements.

You may also add new dependencies and libraries to the project as shown:

1. You can write custom functions for new features you want to integrate. Make sure to add them to the build_dependencies() functions and also include the corresponding » —enable-xxx » parameter switches to the build_ffmpeg() function under the config_options .
2. There are some helper methods (quoted under do_XXX clauses. for checking out code, running make only once, etc. that may be useful.

Note that you can optionally create a machine-optimized build by passing additional arguments to the —cflags parameter, such as —cflags=’-march=athlon64-sse2 -O3′ , as inferred by mtune. Google mtune options for references to this. A good reference can be found on Gentoo’s wiki. Take precautions not to use excessive flags without understanding their impact on performance.

One option you cannot use is —cflags=-march=native (the native flag doesn’t work in cross compiler environments). To find an appropriate «native» flag for your local box, do as illustrated here:

On the target machine,run:

Then use the output shown (in this case, core-avx-i , corresponding to Intel’s Sandy-bridge micro-architecture) on the build machine:

Benchmarks prove that modifying the CFLAGS this way (at least using libx264) doesn’t end up helping much speed-wise (it might make a smaller executable?) since libx264 auto detects and auto uses your cpu capabilities anyway, so until further research is done, these options may not actually provide significant or any speedup, while making the executable «undistributable» since it can only be run on certain cpu’s, but it’s fun! Ping me if you get different results than this, as you may be wasting your time using the —cflags= parameter here.

Note that the build scripts fetch stable sources (not mainline) which may contain slightly older/out of date dependency versions, and as such, there may be implied security risks (see CVEs that may not be patched downstream), though FFmpeg itself will be built from git master by default.

Note that if you have wine installed (in linux) you may need to run this command first to disable it (if you are building for a different -march=XX than the building machine, especially), so that it doesn’t auto run files like conftest.exe , etc. during the build (they may crash with an annoying popup prompt otherwise)

See this reference on the issue highlighted above. Failure to apply the workaround will most likely result in hangs (especially during the configure stage) as highlighted in the reference above.

Feedback is welcome, send an email to roger-projects@googlegroups.com

Related projects (similar to this one. ): https://github.com/jb-alvarado/media-autobuild_suite (native’ish windows using msys2) https://github.com/Warblefly/multimediaWin64 (native’ish windows using cygwin) there’s also the «fast» option see above, within this project

Related projects (that do cross compiling with dependency libraries):