Der neue AAC-Encoder in FFmpeg 9.1

 (hydrogenaudio.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der native AAC-Encoder von FFmpeg wurde umfassend neu geschrieben, einschließlich Rate Control, RDO sowie PNS, TNS, I/S und M/S. Ziel ist eine Qualität, die sich direkt mit externen AAC-Encodern vergleichen lässt.
  • Die neue Implementierung verhält sich nahezu wie striktes CBR; ein echtes VBR-Verfahren auf Basis von -q:a wird nicht empfohlen.
  • In Vergleichen mit Zimtohrli und ViSQOL erzielte der neue nmr-Encoder im Bereich von 64 bis 256 kbps meist bessere Ergebnisse als fdk-aac und Apple AAC; Opus bleibt in einem separaten Vergleich jedoch weiterhin überlegen.
  • PNS, TNS, I/S und M/S werden innerhalb der RDO-Schleife ausgewählt. Wenn ein Downmix zu erwarten ist, wird zur Wahrung der Phase die Nutzung von -aac_is 0 -aac_pns 0 empfohlen.
  • Ab 128 kbps gab es viele positive Bewertungen, doch 64-kbps-Stereo, einige TNS-Samples und Sprachinhalte bleiben Bereiche, die weitere Prüfung benötigen.

Umfassende Neufassung des FFmpeg-AAC-Encoders

  • Der AAC-Encoder von FFmpeg wurde einschließlich Rate Control, RDO, PNS, TNS, I/S und M/S umfassend neu geschrieben.
  • Der Rewrite-PR wurde als Kandidat für das Merging geteilt; später wurde im Thread das tatsächliche Merging bestätigt.
  • Tests sind nach einem Build aus dem Quellcode oder nach einem Update der BtbN Nightly Builds möglich.
  • Der neue Encoder kann über den Codec aac genutzt werden.
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • I/S deaktivieren: -aac_is 0
    • PNS deaktivieren: -aac_pns 0

Qualitätsmetriken und Vergleichsziele

  • Für den Vergleich wurden Googles Zimtohrli, ViSQOL sowie Hörtests verwendet.
    • Bei Zimtohrli ist niedriger besser.
    • Bei ViSQOL ist höher besser.
  • In der Tabelle wurde der neue Encoder als nmr bezeichnet und mit den bisherigen FFmpeg-8.1-Modi fast und twoloop, fdk-aac, Apple AAC sowie libopus verglichen.
  • Repräsentative Ergebnisse:
    • 64 kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128 kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256 kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • Bei hohen Bitraten sättigt Zimtohrli, daher wurde ViSQOL als Tiebreaker verwendet; nach diesem Kriterium liegt der neue Encoder in den Vergleichen vor allen außer Opus.

CBR-orientiertes Design und Coding-Tools

  • Der neue Encoder ist nahezu ausschließlich auf CBR ausgelegt, mit sehr geringen Bitratenschwankungen.
    • Das Bitbudget-Ziel hilft der Kodierqualität.
    • Ein echtes VBR-Verfahren auf Basis von -q:a wird nicht empfohlen.
  • Im Vergleich zeigte sich, dass andere Encoder außer TNS kaum Coding-Tools verwenden. Der neue Encoder wurde zunächst nur mit TNS verglichen, danach wurden PNS, I/S und M/S neu implementiert.
  • Laut Reverse Engineering nutzt qaac keine perzeptive Optimierung, sondern eine Bitzuweisungskurve und Bandenergien mit Präferenz für hohe Frequenzen.
    • Der neue Encoder verwendet für RDO eine ähnliche Kurve mit masked band energy.
  • Alle Coding-Tools – PNS, TNS, I/S und M/S – werden innerhalb der RDO-Schleife ausgewählt.
    • Es werden keine festen Heuristiken oder willkürlichen Bitraten-Cutoffs verwendet.
    • Verfügbare Tools werden abhängig von der RDO-Entscheidung angewandt.
  • Bei hohen Bitraten schalten sich Tools wie I/S und PNS selbst ab, wenn der Encoder alleine gut genug arbeitet, um die Bitrate zu halten.

Decoder-Kompatibilität und Hinweise zu Downmixes

  • Der AAC-Decoder von FFmpeg hat ein Problem bei der Verarbeitung von Stereo-PNS; derselbe Bug könnte auch in anderen AAC-Decodern existieren, weshalb der Encoder ihn umgeht.
    • Da bisherige Encoder PNS nicht verwendet haben, ist dieses Problem bislang nicht aufgefallen.
  • Wenn ein Downmix vorgesehen ist oder die Ausgabe möglicherweise downmixed wird, wird die Verwendung von -aac_is 0 -aac_pns 0 empfohlen.
    • Ziel ist es, die Phase des ursprünglichen Signals zu erhalten.
  • Dass im Spektrogramm viele Lücken sichtbar sind, ist beabsichtigtes Verhalten.
    • Maskierte Bänder werden auf 0 gesetzt oder per PNS verarbeitet.
    • Wenn benachbarte Bänder groß genug sind, sodass das fehlende Band schwer wahrnehmbar ist, wird bevorzugt, die hörbaren Bänder besser zu kodieren, statt alle Bänder schlecht zu kodieren.

Samplerate und Cutoff-Strategie

  • Der Encoder ist vor allem für 48-kHz-Audio optimiert.
    • 44,1 kHz und 96 kHz funktionieren ebenfalls.
    • Für die höchste Qualität wird die Nutzung von 48 kHz empfohlen.
  • Die veröffentlichten Benchmarks wurden hauptsächlich bei 44,1 kHz durchgeführt, während die per Gehör getunten Daten bei 48 kHz lagen.
    • Ein Teil der Windowing-/Transient-Logik ist an 48 kHz gebunden.
    • Da sich das Timing bei 44,1 kHz nicht stark unterscheidet, wurde dies unverändert beibehalten.
  • Später wurde die Bandbreitenstrategie angepasst.
    • 128 kbps werden auf 16 kHz begrenzt.
    • 160 kbps und mehr werden auf 18 kHz begrenzt.
    • Bei 192 kbps pro Kanal wurde die Änderung vorgenommen, das gesamte Spektrum ab 20 kHz zu kodieren.
  • Bei 64-kbps-Stereo gibt es nicht viel Spielraum; ein stärkerer Einsatz von PNS kann das Stereobild beschädigen.
    • Bei 64 kbps könnten auch 15 kHz zu hoch sein, daher wurde ein erneuter Test mit 12-kHz-Cutoff erbeten.
    • Bei Mono ist kein Workaround für den Decoder-Bug nötig, sodass PNS deutlich stärker genutzt werden kann.

Testumfang und Debug-Statistiken

  • Die Entwicklerseite testete mit einer Musiksammlung von 3000 Tracks.
    • Sprachinhalte wurden nur sehr begrenzt getestet und könnten weitere Optimierung benötigen.
  • Beim Beenden gibt der Encoder zusätzliche Statistiken aus.
    • Beispiel: Qavg: 207.975 Tr: 5.3% TNS(L): 4.8% TNS(S): 36.9% M/S: 3.9% I/S: 10.0% PNS: 5.1%
  • Bedeutung der Statistiken:
    • Qavg: durchschnittlicher Lambda-Wert; je höher, desto schwieriger ist es, die Rate zu halten.
    • Tr: Short Blocks
    • TNS(L): TNS-Nutzungsrate in Long Frames
    • TNS(S): TNS-Nutzungsrate in Short Frames
    • M/S: Nutzungsrate von Mid/Side Coding
    • I/S: Nutzungsrate von Intensity Stereo Coding
    • PNS: Nutzungsrate von Perceptual Noise Substitution
  • Wer störende Artefakte entdeckt, kann zur Analyse das ursprüngliche Eingangssample zusammen mit dieser Statistikzeile bereitstellen.

Erste Nutzertests und verbleibende Probleme

  • Ein Nutzer testete mit einem einzelnen Stück, Burn the Boats, bei 64 kbps, 134 kbps und 200 kbps.
    • 64 kbps seien gut, hätten aber leichte Artefakte.
    • 134 kbps und 200 kbps klängen sehr gut.
  • In einem anderen Test gab es zum 64-kbps-Sample The Tower das Feedback, dass der neue nmr-Encoder im Vergleich zum bisherigen twoloop stärker smeary und metallic wirke.
    • Auch der bisherige twoloop habe Probleme mit einem Collapse am Anfang sowie allgemeinem Noise und Roughness.
  • Beim Sample fatboy_30sec war bei 192 kbps bei 6,836 s und 10,480 s ein Ticking Sound zu hören; nach Resampling auf 48 kHz kam ein Tick bei 14,125 s hinzu.
    • Wird TNS mit -aac_tns 0 abgeschaltet, verschwindet das Ticking.
    • Es folgte die Bitte, die Werte von TNS_PG_C1_SHORT in libavcodec/aacenc_tns.c auf 3.2, 4.2 und 5.0 zu erhöhen und dies zu prüfen.
  • Ein Nutzer bewertete Fraunhofer AAC bei 64 kbps und 16-kHz-Cutoff als besser klingend; der neue Encoder habe metallic geklungen.
    • Derselbe Nutzer bewertete den neuen Encoder bei höheren Bitraten über 128 kbps als gut funktionierend.
    • Zugleich wurde geäußert, dass ein breit zugänglicher AAC-Encoder innerhalb des nativen FFmpeg nun ausreichend brauchbar geworden sei.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Ein Beispiel dafür, wie stark Opus ist
    Diese Arbeit an sich ist wertvoll, und bessere Encoder für alte Codecs sind eindeutig ein Gewinn, aber wenn man sich in diesem Benchmark die Opus-Werte ansieht, übertrifft es selbst bei 64 kbps alle AAC-Encoder

    • Der größte Vorteil eines guten AAC-Encoders ist nicht Effizienz, sondern Kompatibilität
      Fast 20 Jahre lang war RTMP mit H.264-Video und AAC-Audio de facto der Standard für Live-Streaming-Video, mit kaum Unterstützung für andere Codecs
      Wenn man einen Stream an YouTube oder Twitch sendet, sendet man am Ende H.264 und AAC; auch OBS erlaubt im Streaming-Modus gar keine Auswahl anderer Video- oder Audio-Codecs und geht davon aus, dass Streamer H.264 und AAC verwenden
    • Bis ich den Artikel gelesen habe, war ich kurz verwirrt, ob mit Opus nicht ein Modell, sondern der Encoder gemeint ist
    • Die Wahl eines verlustbehafteten Audio-Codecs ist inzwischen kaum noch etwas, worüber man nachdenken muss
      Man nimmt einfach Opus, und wenn man Opus aus irgendeinem Grund nicht nutzen kann, nimmt man aus Kompatibilitätsgründen AAC mit sehr hoher Bitrate
      Man muss nicht recherchieren, welchen Encoder und Modus man wählen sollte, um gute Qualität zu bekommen
      Trotzdem ist es großartig, dass es einen hochwertigen Standard-AAC-Encoder gibt, aber ich verstehe nicht so recht, warum er hauptsächlich auf konstante Bitrate ausgelegt ist
    • [https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...](https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_bitrate+latency_comparison.svg)
    • Das größte Problem von Opus sehe ich in der unzureichenden Spezifikation: https://nothings.org/stb/stb_opus.html
      Dadurch wird Opus in Spielen oder Store-Distributionen, bei denen bestimmte Lizenzprobleme auftreten können, kaum verwendet

  • Ich bin gespannt, wie die tatsächliche Leistung sein wird
    Der bisherige AAC-Encoder von FFmpeg hatte eine schlechte Ausgabequalität und oft störende zwitschernde Artefakte, sodass man auf jedem Rechner für Videoaufnahmen den Apple-Core-Audio-Encoder installieren musste, um brauchbaren Klang zu bekommen
    In A/B/X-Vergleichen war eine 320-kbps-MP3 besser als eine mit FFmpeg encodierte 320-kbps-AAC und etwa vergleichbar mit einer per Core Audio encodierten 256-kbps-AAC
    Wenn die Installation von Core Audio nun nicht mehr nötig ist, ist das eine große Verbesserung, und Leute, die mit Tools wie OBS Bildschirmaufnahmen oder Streaming machen, könnten beim nächsten Update eine deutlich bessere Audioqualität bekommen

    • Im Zusammenhang mit Apple Core Audio ist qaac nützlich
      Es wrappet die iTunes-Windows-DLLs zu einem eigenständigen Encoding-Tool mit CLI und funktioniert meines Wissens auch unter Wine auf Linux: https://web.archive.org/web/20250814194428/https://www.andre...
      Für hochwertiges AAC-Encoding braucht man nicht unbedingt einen Mac oder eine vollständige iTunes-Installation
    • Ich habe den FDK-AAC-Encoder verwendet und wusste nicht, dass der Apple-Encoder auch auf Nicht-Apple-Systemen möglich ist
      Als ich früher FDK AAC und Apple AAC bei 192 kbps verglichen habe, konnte ich keinen Unterschied hören, aber der bisherige FFmpeg-AAC-Encoder brach bei dieser Bitrate ein
    • In der Kennzahlentabelle des Hydrogenaudio-Diskussionsthreads erzielt der neue Encoder bessere Werte als Core Audio
      Allerdings auf Basis konstanter Bitrate
      Core Audio hat mit TVBR auch einen variablen Bitraten-Modus, den der neue Encoder nicht hat
      Wenn TVBR nutzbar ist, könnte Core Audio daher weiterhin die Spitze bleiben, aber ich erwarte, dass der neue FFmpeg-Encoder ebenfalls ausreichend gut wird, wenn mehr Leute Problemsamples finden, beitragen und so beim Tuning helfen
    • Wenn einem Qualität wichtig ist, frage ich mich, warum man keinen verlustfreien Codec verwendet
      Oder man nimmt einfach Opus; das ist auch für Sprache gut und funktioniert heutzutage fast überall
    • Ich verstehe nicht, warum Apple an proprietären Codecs festhält
      Wenn Apple H.265 nicht übernommen hätte, würden wir vielleicht in einer AV1-Utopie leben

  • Interessant ist die Stelle: „FFmpegs AAC-Decoder hat einen Bug bei der Verarbeitung von Stereo-PNS, und andere AAC-Decoder könnten ihn ebenfalls haben, daher wird er im Encoder umgangen. Andere Encoder haben PNS nicht verwendet, deshalb wurde das bisher nicht entdeckt“
    Ich weiß nicht, was PNS ist, aber es dürfte irgendeinen sehr speziellen Use Case von jemandem 20 Jahre lang geplagt haben

    • Es gab zwei Probleme
      Das eine: Wenn man TNS über PNS verwendet, wird das eingefügte Rauschen durch TNS geformt, aber derjenige, der das Rauschen erzeugt, ist nicht der Encoder, sondern der Decoder, was keinen Sinn ergibt
      Dadurch ging PNS kaputt; das größere Problem war jedoch, dass bei Verwendung von PNS zusammen mit bestimmten Stereo-Tools das Rauschen identisch in beide Kanäle durchsickerte und das Stereo-Imaging ruinierte
      Deshalb ist es am besten, PNS nur dann zu aktivieren, wenn die betreffenden Bänder in beiden Kanälen vollständig aus Rauschen bestehen oder ausreichend untonal sind und maskiert werden
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Ein hervorragendes Update, bei dem die Details gut aufbereitet sind
    Opus ist großartig und hat seinen Platz, aber AAC wird nicht verschwinden

  • Es gibt die Passage: „Der Encoder ist hauptsächlich für 48-kHz-Audio optimiert. Akzeptiert es. Wir haben 2026, Resampling ist kostenlos und 48 kHz ist der Standard. 44,1 kHz funktioniert auch, 96 kHz funktioniert auch, aber wenn ihr die beste Qualität wollt, nutzt 48 kHz.“ Ist 48 kHz heutzutage wirklich der Standard?

    • Am nächsten an einem tatsächlichen „Standard“ ist meiner Meinung nach AES5-2018, „Recommended Practice for Professional Digital Audio“
      Im Abstract wird für Produktion, Verarbeitung und Austausch von Audioprogrammen mit PCM eine Samplingfrequenz von 48 kHz empfohlen; außerdem werden 44,1 kHz für einige digitale Consumer-Anwendungen, 32 kHz für übertragungsbezogene Anwendungen und 96 kHz für Anwendungen mit höherer Bandbreite oder weniger strengen Anti-Aliasing-Filtern anerkannt
      Persönlich fühlt sich 44,1 kHz für mich wie ein kleines, lästiges Erbe an
    • AAC hat die merkwürdige Eigenschaft, dass sich die Fenstergröße je nach Samplingrate ändert
      Da sich 20-ms- und 60-ms-Fenster für das menschliche Ohr sehr unterschiedlich anhören, müssen sämtliche psychoakustischen Parameter des Encoders für jede Samplingrate vollständig neu optimiert werden
      Bei Opus ist dieses Problem natürlich gelöst
    • 48 kHz macht die Ausrichtung von Bild und Ton deutlich einfacher
      Zum Beispiel wird nach dem Schnitt die Lippensynchronisation leichter
    • Soweit ich weiß, geht der Opus-Codec davon aus, dass alle Eingaben 48 kHz haben, und resampelt die Eingabe dorthin
    • Fast alle DACs laufen standardmäßig mit 48 kHz, weil das Betriebssystem das als vernünftigen Default wählt

  • Ein besserer neuer FFmpeg-AAC-Encoder ist willkommen, aber in den Details gibt es zwei ziemlich große Einschränkungen
    Er unterstützt nur konstante Bitrate und ist nur für 48-kHz-Sampling optimiert
    Dass kein qualitätsbasiertes Encoding mit variabler Bitrate möglich ist, ist eine große Lücke, und wenn man bedenkt, dass CD-Audio weltweit 44,1 kHz hat, wirkt auch das wie ein großes Versäumnis

    • Ich verstehe nicht, warum man bei Audio-Encoding variable Bitrate braucht
      Audio mit variabler Bitrate klingt furchtbar und spart auch nicht besonders viel Bitrate
    • Mit -q:a kann man „echte“ variable Bitrate verwenden, aber die Metriken liegen ein paar Prozent niedriger
      Trotzdem ist das schwer wahrzunehmen, und meiner Meinung nach gewinnt es weiterhin
      Die Benchmarks wurden hauptsächlich bei 44,1 kHz durchgeführt, während die per Gehör getunten Daten 48 kHz hatten, weshalb ein Teil der Windowing- und Transienten-Logik an 48 kHz gebunden ist
      Sie wurde aber auch auf 44,1 kHz ausreichend gut übertragen, und die Timing-Unterschiede sind nicht groß, deshalb wurde es so belassen

  • Interessant ist, wie viel davon vom Gehör des Entwicklers selbst abhängt
    Das ist zugleich beunruhigend und ziemlich cool, denn die Beurteilung von Audioqualität ist so subjektiv

    • Für die Tabellen und Vergleiche wurden „Googles neues Zimtohrli, ViSQOL und mein Gehör“ verwendet
    • Bei Audio läuft es normalerweise so
      Musepack war eine Zeit lang auch in einer Nische beliebt; es war ein einfacher, aber sehr gut getunter Codec
      Bei Lautsprechern und Kopfhörern ist es genauso: Die Leute denken, es gehe um die Qualität der Bauteile, tatsächlich entscheiden aber vor allem das allgemeine Verständnis der Audiophysik und die Fähigkeit zum guten Tuning

  • Eine sehr erfreuliche Ergänzung
    Hoffentlich kann er jetzt fdk-aac ersetzen

  • Jemand hat den vielleicht besten AAC-Encoder aller Zeiten gebaut, und die erste Reaktion ist, dass ein Maintainer darüber streitet, ob es 48 kHz oder 44 kHz sind – das ist wirklich Old Internet

    • So zynisch muss man das nicht sehen
      Der Autor hat nicht mit der tatsächlich am häufigsten verwendeten Samplingrate getestet, daher wäre es für jedes ernsthafte Projekt absurd, eine jahrzehntealte funktionierende Pipeline komplett umzustellen
      Es ist völlig nachvollziehbar, zu warten, bis ausreichend validiert wurde

  • Als ich früher mit ffmpeg Songs für den iPod nano encodiert habe, waren die Dateien kaputt
    Während der Wiedergabe kamen alle paar Sekunden Pops und Klicks dazwischen; ich frage mich, ob das jetzt behoben ist