FFmpeg 9.1's native AAC encoder finally beats FDK — after 15 years

What happened

FFmpeg 9.1 landed with what most changelog readers would treat as a one-liner — 'native AAC encoder quality improvements' — and what the Hydrogenaudio community has spent the last two weeks confirming is one of the most consequential audio-codec shifts in a decade. In double-blind ABX listening tests at roughly 96 kbps VBR, FFmpeg's native `aac` encoder now outranks `libfdk_aac`, the Fraunhofer-derived encoder that has been the de facto quality ceiling for open-source AAC since 2012.

The work was led by Lynne, an FFmpeg maintainer who has been quietly rewriting the psychoacoustic model, the window-switching decision logic, and the two-loop rate/distortion search that assigns bits to spectral coefficients. The previous native encoder was, to put it gently, a punchline. For years the standard advice on any encoding forum was 'don't use `-c:a aac`, install `libfdk_aac`, and if your distro won't ship it, build FFmpeg yourself with `--enable-nonfree`.' Debian, Fedora, Arch's official repos, and Homebrew all refused to package FDK-AAC because Fraunhofer's license permits source distribution but attaches patent grants that conflict with GPL and with most distros' redistribution policies.

Hydrogenaudio's forum thread — the closest thing audio engineering has to peer review — walks through ABX results on classical, pop, and pathological samples (Castanets, harpsichord, glockenspiel, the usual codec-killers). The native encoder ties or wins on most, with occasional losses on sharp transients where FDK's SBR tuning still edges ahead. At 128 kbps CBR the gap narrows to statistical noise, which is the point: two encoders now compete for the top slot, and one of them ships in every distro by default.

Why it matters

AAC is not a glamorous codec. It's what your podcast host transcodes to, what YouTube serves inside its video containers, what Apple Music and Spotify use for their lossy tiers, what every HLS stream on the internet defaults to. The practical universe of 'audio encoding at scale' has been running on a codec whose best open implementation was legally awkward to ship — which meant CI pipelines, Docker images, and serverless transcoders either bundled a non-free binary, added a manual build step, or quietly accepted worse audio.

The economic angle here is easy to miss. Fraunhofer's FDK code was originally released as part of Android's AOSP tree in 2012, and the license (BSD-ish, but with a patent-non-grant clause) was tolerable for Google's purposes and no one else's. Every audio SaaS that has processed hundreds of millions of files — Descript, Riverside, Anchor before Spotify bought it, every white-label podcast platform — has been running FDK-AAC under a commercial patent license from Via LA (formerly Via Licensing), the AAC patent pool. Those patents began expiring in waves starting around 2017, and the pool's grip has been loosening ever since. The FFmpeg native encoder catching up isn't a coincidence with that timeline; it's the natural output of a rewrite that no longer has to tiptoe around implementation details lifted from reference documents.

The technical wins are worth reading in the merge history. Lynne's psychoacoustic changes replaced a fragile per-band masking curve with a windowed model that tracks temporal masking across frames — the reason transient handling improved. The bit allocator now uses a proper Lagrangian rate-distortion loop instead of the previous heuristic ladder, which is why VBR modes finally converge to a target bitrate without the wild swings that made `-q:a` unreliable. And crucially, the encoder is now GPL-clean, no patent-encumbered lookup tables, no reference-implementation cargo — which means it can ship in every downstream package without carveouts.

Community reaction on the Hydrogenaudio thread is measured, which is the highest praise that forum offers. Kamedo2, who runs the community's annual multi-format listening tests, called it 'the first time in fifteen years I'd recommend the native encoder without an asterisk.' There's still work to do — HE-AAC v2 (with SBR + PS for very low bitrates) is not yet at parity, and the encoder doesn't expose all of FDK's tuning knobs — but for the 96–192 kbps range where 95% of production traffic lives, the question is settled.

What this means for your stack

If you run a transcoding pipeline, the immediate action is boring and valuable: pin FFmpeg 9.1, drop `libfdk_aac`, retest your reference set. A `ffmpeg -c:a aac -b:a 128k` command that produced audibly worse output than the non-free path last month now produces equal or better output, from a binary your distro will actually update through apt or dnf. The follow-on savings compound: no more custom Docker layers that compile FFmpeg with `--enable-nonfree`, no more license review with legal every time you add a new region or SKU, no more explaining to a new engineer why the local dev image differs from CI.

For HLS and DASH stream packagers, the win is subtler but real. Most CDN-adjacent packagers (Shaka, Bento4, MediaConvert wrappers) accept whatever encoder FFmpeg exposes. Switching to the native encoder removes a supply-chain node — one fewer binary that a compromised mirror could substitute — and lets you use the same FFmpeg build for both ingest and playout without maintaining two variants. If you're on AWS MediaConvert or Google Transcoder API you don't get to choose, but if you're running your own pipeline (which everyone eventually does once transcoding cost exceeds the eng cost of owning it), this is a straight upgrade.

For game audio, embedded, and mobile developers, the licensing story is what actually matters. Shipping an app that includes FDK-AAC has been a legal-gray-zone question forever; the App Store has always been fine with it, Google Play has always been fine with it, but corporate legal departments at large publishers routinely blocked it. A GPL-clean encoder inside FFmpeg's LGPL-buildable core means the compliance conversation gets much shorter, especially for teams that build FFmpeg statically into their app.

Looking ahead

The interesting question is what this does to Opus adoption. Opus has been the technically superior codec for streaming since 2013 and has never displaced AAC because AAC is what every hardware decoder in every phone, car, and set-top box already implements. With a properly-licensed, high-quality AAC encoder now ubiquitous, the last political argument for switching to Opus — 'AAC's open implementations are bad' — evaporates, and AAC's hardware moat probably locks in for another decade. The winner of this release is not Lynne, or FFmpeg, or Fraunhofer; it's the hardware-decoder installed base, which just got a software encoder worthy of it.