FFmpeg Builds for Windows: Essentials or Full, gyan or BtbN

You went to install FFmpeg on Windows and the download page handed you a decision instead of a file: essentials or full, static or shared, gyan.dev or BtbN. Nothing on that page tells you which one your machine can actually run, or which one contains the codec you came for. Most people hedge by grabbing the biggest zip, and a few of them end up with a binary that won't start on their hardware.

Quick answer: Of the FFmpeg builds published for Windows, gyan.dev's release-essentials is the right download for most people, including anyone enabling video export in Krita or Blender, because it carries the commonly used external libraries and runs on Windows 7 64-bit and up. The full build only adds the long tail (libbluray, OpenCL, Vulkan), links a Windows 10 DLL, and expects an SSE4.1 CPU, while BtbN supports nothing older than Windows 10 22H2. If you'd rather not re-make that choice on every laptop, CI runner, and server you deploy to, FFmpeg Micro runs one managed FFmpeg toolkit behind one API call so every caller gets the same codec set.

"Full" doesn't mean more codecs. It means more external libraries.

The common belief is that full is the safe default because it has everything, and that essentials is the stripped-down version you'll regret. Half of that is true: full does contain more. But the thing it contains more of is third-party libraries, not codecs. gyan.dev states it directly: essentials carries the commonly used libraries, full adds most of the remainder, and every variant contains all the internal components available for Windows.

So the widely repeated claim that you need the full build for ProRes or DNxHD is wrong. Those are native FFmpeg encoders compiled into libavcodec, and they're in the essentials zip you already downloaded. Same for native AAC, GIF, PNG, and the whole MPEG family. H.264 and H.265 come from libx264 and libx265, which are external, but both sit in gyan's essentials build too.

What's genuinely only in full is the stuff you'd know you needed: libbluray for Blu-ray structures, OpenCL and Vulkan for GPU filters, and the less common demuxers and audio libraries. gyan himself has put it that way in the long-running VideoHelp thread where these questions actually get answered. If you don't need those, essentials is the pick.

The four gyan links, decided

Requirements, not features, are what should drive this choice, because a build that doesn't launch is worse than one missing a filter. Here's the whole decision in one table.

Two requirement details decide it for older machines. The release-essentials build runs on Windows 7 64-bit but ships without OpenCL and Vulkan. Release-full and release-full-shared link against a Windows 10 DLL and will not start on Windows 7, and full expects SSE4.1, which rules out pre-2008 Core 2 and most Atom chips. That's the trap in grabbing the biggest zip.

Static versus shared is a simpler question than it looks. The static builds give you one self-contained ffmpeg.exe with no DLLs to place, which is what you want for a CLI tool, a script, or a PATH entry. Shared exists for people compiling against FFmpeg's libraries from their own program. If you aren't writing C, you don't want shared.

Git master is worth a note: it's built from the current development tree, so a fix can be in it weeks before a release. The cost is that upstream behavior changes land in your build without a version number to blame, which is exactly how people discover flag removals the hard way. Our notes on what to re-test before an FFmpeg upgrade apply doubly to a master build.

gyan or BtbN: freshness versus pinning

gyan.dev and BtbN are the only two Windows builders FFmpeg itself points people to. ffmpeg.org's download page ships no official Windows binary at all and sends Windows users to those two, which is why both names keep showing up and why neither one is "the official build."

The real difference between them is dependency policy. gyan builds against the latest libvpx available at build time. BtbN clamps libvpx to an older commit, because the newer libvpx header isn't installed alongside the static lib and FFmpeg's configure then quietly disables the VP9 encoders. Practical read: if you encode VP9 or WebM and want current libvpx behavior, gyan is the one tracking it. If you want a build matrix that barely moves, BtbN's pinning is a feature.

BtbN's variant names are a licensing matrix, and one of them will burn you. The gpl builds include libx264 and libx265. The lgpl builds drop the GPL-only libraries, so there is no libx264 in them, and -c:v libx264 fails outright with an unknown encoder rather than falling back to anything. The nonfree builds add fdk-aac and cannot be redistributed. Each has a -shared counterpart. Unless you have a specific license constraint, gpl is the one you want, and the project README is explicit that the minimum supported Windows version is 10 22H2 with no guarantees below that.

Audit the build you already have

Before you download anything, check what's on the machine, because the install you're about to replace may already be fine. Two flags answer it. ffmpeg -buildconf prints the exact configure flags the binary was compiled with, so you can see whether --enable-libx264 or --enable-opencl is in there. ffmpeg -codecs lists what libavcodec actually knows how to encode and decode, which is the list that matters at runtime. Both are documented in the FFmpeg manual.

ffmpeg -hide_banner -buildconf | findstr libx264
ffmpeg -hide_banner -codecs | findstr prores

That's also your fastest answer when a command works for a colleague and fails for you. Nine times out of ten the difference isn't the command, it's the binary.

The build you picked is not the build your server has

Here's the part the download pages never raise. You just made a careful choice for one Windows machine. Your CI runner made a different one, your Linux box made a third, and your teammate on a Mac made a fourth. The popular setup-ffmpeg GitHub Action pulls Windows binaries from gyan.dev, Linux from johnvansickle.com, and macOS from evermeet.cx: three builders with three dependency policies inside a single pipeline.

Codec-availability drift is a real class of "works on my machine" bug, and it fails in ways that don't look like a build problem. A BtbN lgpl build has no libx264. A distro's ffmpeg-free package has the patent-encumbered encoders stripped, so the same -c:v libx264 that runs locally dies on the server. An essentials build has no OpenCL, so your GPU filter chain falls back or errors. -buildconf can diagnose every one of those. It can't fix any of them, because the fix is a different binary on every host, maintained forever.

That's the case for not having a build at all. FFmpeg Micro is one managed FFmpeg toolkit behind one REST API: the same codec set for your laptop, your CI job, your n8n or Make workflow, and your production server, with nobody choosing a zip. You can read the request shape in the API docs, and the free tier gives you 200 tokens (about 33 minutes of input video) with no card.

Pitfalls that cost people an afternoon

Most bad outcomes here come from four specific mistakes, and all of them are avoidable before you click download.

FAQ

Do I need the full FFmpeg build for H.264?

No. gyan's essentials build includes libx264 and libx265, so H.264 and H.265 encoding work with release-essentials. The build where libx264 is genuinely missing is BtbN's lgpl variant.

Which FFmpeg build works on Windows 7?

gyan's release-essentials is the Windows 7 build, on 64-bit only, without OpenCL and Vulkan support. Release-full and release-full-shared link a Windows 10 DLL and won't start on Windows 7, and BtbN supports nothing older than Windows 10 22H2.

Does FFmpeg publish an official Windows binary?

FFmpeg publishes no official Windows binary. The project's own download page lists source tarballs and points Windows users at two third-party builders, gyan.dev and BtbN, which is why there is no single canonical ffmpeg.exe to download.

Which FFmpeg build should I use for Krita or Blender?

The release essentials build from gyan.dev is enough for Krita, Blender, and similar apps that call FFmpeg for video export. Those programs need an ffmpeg.exe on disk with the common encoders, and nothing in the full build changes what they can render.

Is the git master build safe to use?

A git master build is safe in the sense that it's built from the same upstream tree a release comes from, but it moves without version numbers, so deprecations and removals can arrive mid-week. Use a release build unless you specifically need a fix that hasn't shipped yet, and re-test your encoding commands after every update if you do.

If you want to find out whether a command behaves the same on a single managed toolkit before you commit to maintaining your own, run it in the playground against FFmpeg Micro's build, then sign up free and point your pipeline at it instead of a zip file.