HN Debrief

FFmpeg 9.1's new AAC encoder

  • Audio
  • Video
  • Open Source
  • Developer Tools
  • Infrastructure

The post points to a Hydrogenaudio thread about FFmpeg 9.1’s new AAC encoder, which is presented as a ground-up improvement over FFmpeg’s long-weak native AAC path. The author says it was tuned mainly for 48 kHz audio, focuses on constant bitrate operation, and works around long-hidden decoder edge cases around perceptual noise substitution and stereo handling. That framing mattered because plenty of people have treated FFmpeg’s old AAC output as something to avoid, especially for screen recording, streaming, and other video-heavy jobs where AAC is mandatory whether you like it or not.

If your product or workflow emits AAC because platforms, devices, or live video pipelines demand it, FFmpeg’s built-in encoder may finally be good enough to drop extra Apple or Fraunhofer tooling. If you control both ends, this changes less than it sounds, because Opus still wins on codec efficiency and AAC’s value is mostly ecosystem lock-in.

Discussion mood

Positive and practical. People were glad FFmpeg’s native AAC encoder may finally stop being the weak link in common video workflows, but the enthusiasm was tempered by two recurring notes: Opus is still the cleaner technical choice when compatibility allows it, and benchmark scores are not the same thing as human listening tests.

Key insights

  1. 01

    Built-in AAC quality could simplify video stacks

    For people doing recording, transcoding, or live production, the gain is not abstract codec nerd bragging. The old FFmpeg encoder was bad enough that some users installed Apple Core Audio or relied on FDK-AAC just to avoid obvious artifacts. If FFmpeg’s native path is now competitive with Core Audio on common settings, a lot of downstream tools inherit better audio by default and one more proprietary dependency can disappear from production setups.

    Retest any workflow where you pinned Apple AAC or FDK-AAC for quality reasons. You may be able to standardize on stock FFmpeg and remove a fragile install step from build machines, creator laptops, or server images.

      Attribution:
    • ndiddy #1
    • madars #1
    • kderbe #1
    • lesscraft #1
    • winstonwinston #1
  2. 02

    AAC survives because platforms still demand it

    The case for AAC is not that engineers love it more than Opus. Live streaming protocols, ingest requirements, and hardware decode support still make AAC the least risky audio choice in video pipelines. RTMP baked in H.264 plus AAC assumptions, and even where newer protocols allow more video options, the audio side remains conservative because battery life, device support, and ecosystem defaults still favor AAC.

    If you ship to YouTube, Twitch, mobile clients, set-top boxes, or mixed hardware fleets, treat AAC as an interoperability constraint first and a quality decision second. Better native FFmpeg AAC helps exactly those environments.

      Attribution:
    • ndiddy #1
    • someonebaggy #1
    • booi #1
    • philistine #1
    • jshier #1
  3. 03

    The rewrite exposed old decoder bugs

    The interesting engineering detail is that enabling perceptual noise substitution uncovered broken interactions with temporal noise shaping and stereo tools in AAC decoding. That produced nonsense noise behavior and damaged stereo imaging, which is why this feature had effectively stayed dormant. The encoder now has to work around decoder reality, not just the spec, which is a good reminder that mature formats can hide bugs for decades when no one exercises dusty corners of the design.

    If you maintain media code, add weird feature combinations to your test corpus instead of just mainstream files. Dormant spec features can stay broken for years until one implementation finally tries to use them seriously.

      Attribution:
    • lesscraft #1
    • HugoTea #1
  4. 04

    48 kHz tuning matches modern media pipelines

    The author’s focus on 48 kHz lines up with where video, streaming, operating system defaults, and Opus already landed. One commenter added the non-obvious codec reason. In AAC, window size depends on sample rate, so moving between 44.1 and 48 kHz is not just a resampling issue. It changes the psychoacoustic tuning problem. That makes the "optimized for 48 kHz" warning more substantial than it first sounds.

    Use this encoder first in 48 kHz video or streaming pipelines, where it was clearly targeted. If your workload is music archiving or CD-derived 44.1 kHz material, validate before switching blindly.

      Attribution:
    • Joeboy #1
    • pipo234 #1
    • legdoge #1
    • lesscraft #1
    • asveikau #1
  5. 05

    Metric wins are not enough for codec claims

    Several people were skeptical of taking automated scores as the final word, especially for close calls at higher bitrates. The useful correction was that tools like Zimtohrli and ViSQOL are good for development feedback, but they are still proxies. Human listening tests such as ABX and MUSHRA remain the standard for judging whether a new encoder is actually better in practice, particularly once artifacts get subtle.

    Do not rewrite your codec policy from one benchmark chart. For customer-facing quality decisions, run listening tests on your own content, especially if you care about music at higher bitrates.

      Attribution:
    • CharlesW #1 #2
    • pkulak #1
    • ant6n #1

Against the grain

  1. 01

    Opus licensing is less of a blocker

    The claim that Opus stays out of games because its specification blocks certain uses overstates the problem. People working in games said BSD-style licensing is already normal for engine and middleware dependencies, and libopus is not unusual in that respect. That does not erase edge cases around public-domain-only goals, but it weakens the idea that licensing is the main reason Opus is absent from mainstream game audio pipelines.

    If you rejected Opus on assumed licensing risk, recheck the actual constraints of your distribution model and engine stack. The blocker may be tooling, CPU budget, or platform support rather than the license.

      Attribution:
    • a1o #1
    • scratcheee #1
    • duskwuff #1
    • chaosharmonic #1
  2. 02

    Vorbis still has niche strengths

    Opus was treated as the obvious modern answer, but one comment made a narrower case for Vorbis. At transparent bitrates it can still be competitive, its ReplayGain handling is cleaner for some library workflows, and on very weak legacy devices it may cost less battery. That does not make it the best default for new libraries, but it does show that codec choice can still hinge on metadata behavior and decoder efficiency, not just listening tests.

    If you support old portable hardware or care deeply about volume normalization behavior across a personal library, test Vorbis before assuming Opus solves everything. Codec ergonomics can matter as much as nominal quality.

      Attribution:
    • BoingBoomTschak #1
    • jck86 #1
  3. 03

    Music archival users may still wait

    The enthusiasm around this encoder is strongest for video. People who encode music libraries were less convinced because variable bitrate is still missing or unclear, 44.1 kHz is not the optimization target, and AAC users often prefer Apple or FDK workflows for exactly those cases. So the upgrade may be real without yet replacing the established choices for CD-derived collections.

    For music ripping or long-term personal archives, keep your current AAC workflow until this encoder proves itself on 44.1 kHz material and variable bitrate use. The best-case path here is video first, music later.

      Attribution:
    • refulgentis #1
    • binaryturtle #1
    • daneel_w #1

In plain english

AAC ↩
Advanced Audio Coding, a widely supported lossy audio compression format commonly used in video, streaming, and Apple devices.
ABX ↩
A blind listening test method where a listener tries to tell whether an unknown sample matches sample A or sample B.
Core Audio ↩
Apple’s audio framework, which also includes AAC encoding components often used for higher quality AAC output.
FDK-AAC ↩
Fraunhofer’s AAC encoder library, long used as a higher quality AAC option than FFmpeg’s older native encoder.
FFmpeg ↩
A widely used open source toolkit and library set for processing, encoding, decoding, and streaming audio and video.
H.264 ↩
A very common video compression standard used in streaming, video recording, and device playback.
kHz ↩
Kilohertz, a unit of frequency used here to describe audio sample rates such as 44.1 kHz or 48 kHz.
MUSHRA ↩
Multiple Stimuli with Hidden Reference and Anchor, a formal listening test method used to compare audio codec quality.
OBS ↩
Open Broadcaster Software, a popular open source application for recording and live streaming video.
Opus ↩
Anthropic’s higher-end Claude model line, positioned above Sonnet for harder tasks.
ReplayGain ↩
A metadata system that stores volume adjustment values so tracks can play back at a more consistent loudness.
RTMP ↩
Real-Time Messaging Protocol, an older streaming protocol widely used for live video ingest and historically tied to specific codec combinations.

Reference links

Streaming and codec support references

Audio codec implementation and quality references

Tools and apps

  • qaac archived page
    Mentioned as a command line wrapper around Apple AAC components that can be used outside standard Apple environments.
  • Poppy app beta info
    Suggested as an iOS client that treats Opus as a first-class music format for compatible media servers.

Background references