MLow: Metas Audio-Codec für niedrige Bitraten

 (engineering.fb.com)
2 Punkte von GN⁺ 2024-06-14 | 1 Kommentare | Auf WhatsApp teilen
  • Meta hat den neuen Audio-Codec MLow für niedrige Bitraten entwickelt, um die Qualität von Echtzeit-Anrufen in WhatsApp, Instagram und Messenger auch in langsamen Netzwerken und auf älteren Geräten aufrechtzuerhalten
  • Das bisherige Opus arbeitet bei 6 kbps im NarrowBand-Modus, wodurch sich Sprachfrequenzen nur unzureichend abbilden lassen; verschlechtert sich das Netzwerk während eines Videoanrufs, sinkt die dem Audio zugewiesene Bitrate noch weiter
  • ML-basierte Audio-Codecs können bei niedrigen Bitraten gute Qualität liefern, verursachen aber hohe Rechenkosten und eignen sich deshalb oft eher für aktuelle, leistungsstarke Mobilgeräte
  • MLow erreicht bei 6 kbps WideBand einen POLQA MOS von 3,9 und damit ungefähr die doppelte Qualität von Opus mit 1,89, bei einer 10 % geringeren Rechenkomplexität als Opus
  • Für Anrufe in Instagram und Messenger ist der Codec bereits vollständig ausgerollt, für WhatsApp läuft die Verteilung; außerdem lässt sich bei niedrigen Bitraten FEC effizienter einbauen, was die Wiederherstellung von Audio bei Paketverlust verbessert

Warum Meta einen neuen Codec entwickelt hat

  • Meta-Apps einschließlich WhatsApp, Instagram und Messenger bieten Milliarden von Menschen Funktionen für Echtzeitkommunikation (RTC)
  • In RTC sind Audio- und Video-Codecs zentrale Komponenten, die erfasste Daten komprimieren, über das Internet übertragen und Gespräche in Echtzeit ermöglichen
  • Rohes Audio in einem typischen Anruf liegt bei 48-kHz-Abtastung, 16 Bit und Mono bei 768 kbps; moderne Codecs können das auf 25–30 kbps komprimieren
  • Bei der Komprimierung kann durch Informationsverlust die Qualität sinken, aber gute Codecs nutzen die Eigenschaften von Audiosignalen und Wissen aus der Psychoakustik, um Qualität, Bitrate und Komplexität auszubalancieren
  • Opus ist ein bekanntes Open-Source-Codec, das 2012 veröffentlicht wurde, und Meta hat Opus bislang für seine RTC-Anforderungen eingesetzt

Einschränkungen bei niedrigen Bitraten und auf älteren Geräten

  • In Metas RTC-Umgebung im großen Maßstab lässt sich direkt beobachten, wie sich unterschiedliche Netzwerkbedingungen auf das Gesprächserlebnis auswirken
  • Ein erheblicher Teil der Anrufe leidet über die gesamte Dauer oder in einzelnen Abschnitten unter schlechter Netzverbindung
    • Das Modul zur Bandbreitenschätzung (BWE) erkennt die Netzwerkqualität
    • Wenn die Netzwerkqualität sinkt, muss die Codec-Bitrate reduziert werden, um Überlastung zu vermeiden und den Audiostrom aufrechtzuerhalten
    • Bei Videoanrufen bleibt unter schlechten Netzwerkbedingungen noch weniger Spielraum für Audio
  • Der niedrigste Betriebspunkt von Opus liegt bei 6 kbps; dabei arbeitet es im NarrowBand-Modus mit 0–4 kHz
    • Dieser Bereich erfasst nicht ausreichend alle Frequenzen der menschlichen Stimme
    • Dadurch klingt Sprache weniger klar und weniger natürlich
  • ML-basierte Audio-Codecs wie Encodec, das Meta im Oktober 2022 vorgestellt hat, liefern selbst bei sehr niedrigen Bitraten klare Audioqualität
    • Allerdings sind die Rechenkosten hoch, sodass sie oft nur auf leistungsstarken und teuren Mobilgeräten stabil laufen
    • Nutzer von Geräten mit geringer Leistung haben unter niedrigen Bitraten weiterhin mit Audioqualitätsproblemen zu kämpfen
  • Mehr als 20 % der Meta-Anrufe finden auf ARMv7-Geräten statt; allein bei WhatsApp werden täglich zig Millionen Anrufe auf Geräten geführt, die mehr als zehn Jahre alt sind

Leistung und Rollout von MLow

  • Meta begann Ende 2021 mit der Entwicklung des neuen Codecs und stellt nach fast zwei Jahren Entwicklung und Tests den Meta Low Bitrate audio codec, kurz MLow, vor
  • Bei 6 kbps WideBand erreicht er eine Qualität von POLQA MOS 3,9, also etwa doppelt so viel wie Opus mit 1,89
  • Die Rechenkomplexität ist 10 % geringer als bei Opus
  • Im Vergleich auf der MOS-Skala (Mean Opinion Score) von 1 bis 5 zeigt MLow bei niedrigen Bitraten einen deutlichen Vorsprung vor Opus und erreicht die Qualitätssättigung schneller
  • Für alle Anrufe in Instagram und Messenger ist er bereits ausgerollt, für WhatsApp wird er aktiv verteilt
  • Es wurde außerdem bestätigt, dass bessere Audioqualität zu höherem Nutzerengagement führt

FEC bei Paketverlust

  • Wenn sich hochwertige Audioqualität bereits bei niedrigen Bitraten kodieren lässt, kann auch die Strategie für Forward Error Correction (FEC) effektiver eingesetzt werden
  • MLow bietet im Vergleich zu Opus selbst bei niedrigeren Bitraten noch Spielraum, FEC einzubauen
  • Diese Eigenschaft hilft, die Audioqualität bei Paketverlust zu verbessern
  • Es gibt einen Beispielvergleich für eine Situation mit 30 % Paketverlust auf der Empfängerseite bei 14 kbps
  • Opus kann bei dieser Bitrate kein In-Band-FEC kodieren
    • Damit Opus bei 10 % Paketverlust In-Band-FEC kodieren kann, sind mindestens 19 kbps erforderlich
    • Diese Einschränkung wirkt sich nachteilig auf die Audio-Wiederherstellung aus

Interne Struktur von MLow

  • MLow basiert auf dem Konzept traditioneller CELP(Code Excited Linear Prediction)-Codecs
  • Die wichtigsten Verbesserungen liegen bei Erzeugung des Erregersignals, Parameterquantisierung und Kodierungsverfahren
  • Der Encoder nimmt das rohe PCM-Audio als Eingangssignal und teilt es in ein niederfrequentes und ein hochfrequentes Band auf
  • Jedes Band wird separat kodiert, nutzt aber gemeinsame Informationen für eine bessere Komprimierung
  • Die Ausgabe wird über einen Range Encoder zusätzlich komprimiert und als kodierte Nutzlast erzeugt
  • Der Decoder nimmt die Nutzlast entgegen, führt den umgekehrten Prozess aus und erzeugt das Audiosignal als Ausgabe
  • Durch split-band optimization kann MLow das hochfrequente Band mit sehr wenigen Bits kodieren
  • Dank dieser Struktur kann auch bei noch niedrigeren Bitraten SuperWideBand, also Audio mit 32-kHz-Abtastung, bereitgestellt werden

Weitere Arbeit

  • MLow steigert die Audioqualität auf leistungsschwachen Geräten deutlich und bewahrt gleichzeitig die Ende-zu-Ende-Verschlüsselung von Anrufen
  • Da sich zusätzliche Audioinformationen bei niedrigen Bitraten effizient unterbringen lassen, wird weiter daran gearbeitet, die Audio-Wiederherstellung in Netzwerken mit starkem Paketverlust zu verbessern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-14
Meinungen auf Hacker News

  • Neue Low-Bitrate-Codecs sind beeindruckend, aber in den meisten Szenarien, in denen Meta sie einsetzen will, wirken sie in der Praxis möglicherweise gar nicht so nützlich
    Um bei Echtzeitkommunikation die Latenz niedrig zu halten, muss die Paketfrequenz recht hoch sein, und ab einem gewissen Punkt dominiert der Overhead von UDP, IP und unteren Schichten gegenüber der eigentlichen Nutzlast
    Zum Beispiel hat (S)RTP über UDP/IP mindestens 12 Byte für RTP, 8 Byte für UDP und 20 Byte für IPv4, also insgesamt 40 Byte Overhead. Bei 50 Paketen pro Sekunde, also 20 ms Serialisierungsverzögerung, sind allein das 16 kbps Overhead
    Reduziert man auf 25 Pakete pro Sekunde, sinkt der Overhead auf 8 kbps, macht aber immer noch einen großen Anteil der gesamten Übertragungsrate aus
    Wirklich glänzen würde ein solcher Codec bei leitungsvermittelter Kommunikation mit etwa 2 kbps, wie bei manchen Satellitentelefonen, oder bei protokollbewussten VoIP-Systemen wie LTE/5G IMS, die Header-Kompression nutzen, bei der der Großteil der 40 Byte pro Frame vorhersehbar ist

    • Latenz ist kritisch, aber wenn die verfügbare Bandbreite niedrig ist, lässt sich der Overhead schon stark reduzieren, indem man 2 bis 5 Samples à 20 ms bündelt
      100-ms-Pakete erhöhen die Verzögerung deutlich, aber dann wird die Einsparung durch den Codec relevant. Ausgereiftere Systeme können den Codec und die Anzahl der Samples pro Paket je nach aktuellen Bedingungen anpassen
      Das System, mit dem ich arbeite, nutzt einen festen Codec und 60 ms Audio pro Paket, ist also nicht ideal, funktioniert aber bei niedriger Bandbreite deutlich besser als 20-ms-Pakete
      Meta hat eine sehr breite Verteilung von Forwarding-Servern, sodass es sich auch etwas zusätzliche Sampling-Latenz leisten kann. Sie können über Content-Equipment innerhalb vieler ISPs weiterleiten und so die Netzwerklatenz gegenüber konkurrierenden Diensten senken, deren weltweite Forwarding-Hosting-Kapazität begrenzt ist. P2P funktioniert auch nicht immer und hat nicht grundsätzlich eine niedrigere Latenz als der Weg über einen nahegelegenen Forwarding-Server
    • Wenn man sich den Umfang von Sprache/Audio ansieht, den Meta bereits bei Facebook, Facebook Live, Instagram und WhatsApp verarbeitet, ist diese Einschätzung wahrscheinlich falsch
      Besonders WhatsApp-Sprachnachrichten und -Anrufe haben in Ländern mit sporadischen und wenig zuverlässigen Netzwerken einen erheblichen Marktanteil. Wenn das System robuster gegenüber Paketverlust und Jitter ist, kann es auch auf Protokolle mit weniger Overhead für Fehlerkorrektur, Fragmentierung und Empfangsbestätigungen setzen
      Man kann durchaus davon ausgehen, dass diese Technik den gesamten Bandbreitenverbrauch durch Audio deutlich senken kann, während Zuverlässigkeit und wahrgenommene Qualität erhalten bleiben oder sich verbessern
      Als ich einen aktiven WhatsApp-Anruf in Wireshark betrachtet habe, wurden während eines einminütigen Anrufs etwa 380 UDP-Pakete vom Sender zum Empfänger und ein paar TCP-Pakete an WhatsApp-Server übertragen. Damit liegt der Übertragungs-Overhead bei ungefähr 2,2 kbps
      Zur Begründung: Die anfängliche ptime, also die Audiogröße pro Paket, ist hier auf 20 ms gesetzt, maxptime aber auf 150 ms. Der Client kann das opportunistisch nutzen, um unter Berücksichtigung der Latenz auf beiden Seiten und der verfügbaren Bandbreite die Zahl der übertragenen Pakete zu reduzieren
      Bild: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
    • Ein weiterer interessanter Einsatzbereich für solche Ultralow-Bitrate-Sprachkompression sind digitale Funksysteme
      Sprachcodecs wie AMBE+2, die in Funksystemen häufig verwendet werden, klingen ziemlich schlecht und gehen im Vergleich zu neuen Codecs auch nicht elegant mit Paketverlust um
    • Dem Blogpost zufolge ist das praktische Forschung, mit der Meta seine eigenen Dienste verbessern will
      Es könnte übertriebenes Marketing sein, aber angesichts der Tatsache, dass Meta einer der größten Anbieter von Sprach- und Videoanrufen auf Geräten mit geringer Bandbreite ist, scheint das eher unwahrscheinlich
      Ich weiß nicht, worauf die Annahme beruhen soll, Meta habe sich die ganze Zeit selbst etwas vorgemacht
    • Ich kenne keine Konfiguration, die Multiplexing genau so unterstützt, wie ich es mir vorstelle, aber es wäre auch ein interessanter Anwendungsfall, wenn ein Server mehrere eingehende Audiostreams hat, die er nicht mischen darf
      Zum Beispiel, wenn der Server wegen Ende-zu-Ende-Verschlüsselung nicht mixen darf, könnte ein einzelnes Paket Daten mehrerer Streams enthalten. Ende-zu-Ende-verschlüsselte Audioanrufe sind inzwischen recht verbreitet, und Facebook scheint gut positioniert zu sein, um in seinen Produkten eigenes Multiplexing umzusetzen

  • Geht es nur mir so, oder wirkt Meta wieder cool, seit sie so viel Forschung und Open Source beziehungsweise Arbeit mit offenen Gewichten teilen
    Facebooks Ruf war am Boden, aber inzwischen scheint er sich ein Stück weit erholt zu haben

    • Ich habe denselben Eindruck
      Der Ruf von Facebook als sozialem Netzwerk mag nicht glänzend sein, aber den Ruf der Engineering-Firma Meta halte ich für ziemlich hoch
      In gewisser Weise ist das ähnlich wie bei IBM. Als Anbieter von Hardware- oder Softwarelösungen wirken sie vielleicht nicht besonders großartig, aber ihre Forschungs- und Mikroelektronikbereiche sind immer noch ziemlich beeindruckend
    • Die Forschungsabteilung und die Produktabteilungen sind nicht dasselbe
      Microsoft Research bringt ebenfalls wirklich coole Dinge hervor, aber das heißt nicht, dass dasselbe Microsoft keine Werbung im Startmenü seines Betriebssystems platziert
      Vor ein paar Jahren habe ich als Teenager diese interessante Diskrepanz bei Microsoft gesehen, und es überrascht mich überhaupt nicht, dass es innerhalb von Facebook gleichzeitig Abteilungen gibt, die tolle Dinge wie zstandard machen, und völlig andere Leute, die auf ganz andere Ziele hinarbeiten. Solche Diskrepanzen zwischen Abteilungen dürfte es vermutlich in den meisten Unternehmen geben, sobald sie mehr als ein paar Hundert Beschäftigte haben
    • Ich sehe sehr positiv, wie Meta Forschung teilt und Software als Open Source veröffentlicht
      Aber Metas Haltung zu Privatsphäre, Sicherheit und gesellschaftlicher Verantwortung sehe ich sehr negativ
    • Man sollte sich nicht täuschen lassen. Am Ende werden mächtige Akteure Wege finden, Nutzer für Kleingeld auszubeuten
    • Meta hat eine Geschichte darin, Systeme als Open Source zu veröffentlichen, die es für den Betrieb seiner eigenen Dienste gebaut hat
      CassandraDB und (Py)Torch fallen mir dazu ein

  • Dass Codec2 überhaupt nicht erwähnt oder verglichen wird, lässt den tatsächlichen Wert und die Motivation dieser Arbeit sofort fragwürdig erscheinen
    In diesem Bereich braucht es nicht noch einen weiteren an geistige Eigentumsrechte gebundenen Audio-Codec

  • Ich frage mich, ob das besser ist als das, was Google Meet verwendet
    Selbst bei langsamem Internet, das fast unbenutzbar stark aussetzte, erfüllte Google Meet den Zweck eines Audioanrufs, während andere konkurrierende Dienste scheiterten. Getestet etwa auf einer abgelegenen Insel auf den Philippinen mit extrem schlechtem Internet
    Allerdings ist die Technik von Google Meet meines Wissens nirgends veröffentlicht

    • Wenn dieser Werbebeitrag keinen Code enthält, lässt sich das kaum testen
      Anhand der wenigen veröffentlichten Beispiele können wir auch nur ungefähr so weit urteilen

  • Auch kein Vergleich mit Pied Piper

    • Der Weissman-Score mag vielleicht im 5er-Bereich liegen, aber ich habe nie eine echte Implementierung gesehen. Nutzt es middle-out compression?

  • Etwas off-topic, aber warum sind normale Telefonate heute schwerer zu verstehen als 8 kHz 8-bit μ-law und ADPCM aus den 90ern?
    Edit: „klingt schlechter“ in „ist schwerer zu verstehen“ geändert

    • Das hängt davon ab, um welche Art von Anruf es geht. μ-law hat einen schlechten Frequenzgang und einen ordentlichen Dynamikumfang
      Für Musik ist es nicht besonders gut, für Sprache aber ganz brauchbar, und vor allem ist es sehr konsistent. Telefonate in den 90ern waren auf der letzten Strecke fast vollständig leitungsvermittelt, und auf digitalen Leitungen wurden sie sampleweise gemultiplext. T1 und höher funktionierten so
      Dadurch war die Latenz sehr niedrig und der Jitter bei 0. Verglichen mit einem beidseitig analogen leitungsvermittelten Gespräch gab es zwar messbare Verzögerung, sie war aber praktisch kaum wahrnehmbar; weil nahe an beiden Enden digital abgetastet wurde, war das Rauschen deutlich geringer. Leitungsvermittlung bedeutet auch, dass keine Samples verloren gehen. Entweder die Verbindung steht oder nicht; gelegentlich funktioniert nur eine Richtung
      Moderne Anrufe verwenden normalerweise 20-ms-Samples über paketvermittelte Netze, wodurch Sampling-Verzögerung, Jitter und Jitter-Puffer hinzukommen. Auch der Codec selbst macht mehr als nur ADC/DAC mit Logarithmus und hat daher Encoding- und Decoding-Latenz. Die meisten Codecs verwenden pro Sample deutlich weniger Bits als μ-law, und dieser Preis ist nicht kostenlos
      HD Voice (G.722.2 AMR-Wideband) hat einen viel breiteren Durchlassbereich und klingt daher deutlich besser als GSM, Opus und die meisten Low-Bandwidth-Codecs. Trotzdem bleibt die Latenz. Manche werden sagen, 20–100 ms Verzögerung seien nicht spürbar, aber wenn man jemandem einen A/B-Vergleich zwischen einem Gespräch mit 0 ms und einem mit 20 ms Latenz vorspielt, wird er sagen, dass das 0-ms-Gespräch besser ist
    • Die Hörmuschel-Lautsprecher heutiger Handys sind leiser als früher, sodass man die Lautstärke schwer hochdrehen kann, wenn die Gegenseite nicht klar ins Mikrofon spricht
      2013 bin ich von einem Klapphandy auf ein iPhone umgestiegen, und der Unterschied war enorm. Ich habe sofort Earbuds oder die Freisprechfunktion benutzt, und damals war ich ein Teenager
    • Mit zunehmendem Alter lässt das Gehör nach
    • Paketvermittlung verwirft Pakete, Leitungsvermittlung verwirft den Verbindungsversuch selbst. Wenn alle Leitungen belegt sind, kommt die Verbindung nicht zustande
      Die meisten Telefonate in den 90ern nutzten nicht ADPCM, sondern schlicht PCM. Vermutlich kommt daher die Verwechslung
      Außerdem wurde kein Funk verwendet. Von meinem Mikrofon bis zum Hörer der Gegenseite führte eine solide Kupferleitung. Funk, also Mobiltelefonie, Wi‑Fi und Schnurlostelefone, ist von Natur aus weniger zuverlässig
      Frühere Telefone hatten Sidetone, viele VoIP-Apps hingegen nicht
      Und schließlich ist die Nutzung von Freisprechen heute weit verbreitet; Freisprechen passt nicht gut zu Sidetone und fügt viel Mehrwege-Fading im Audio hinzu

  • Da NoLACE nicht erwähnt wird, sind die Vergleichssamples etwas weniger nützlich: https://opus-codec.org/demo/opus-1.5/

    • Das ist wirklich großartig, und ich schätze sehr, wie viel Arbeit Xiph in die Standardisierung steckt
      https://datatracker.ietf.org/wg/mlcodec/documents/
      Wenn Meta das der Welt schenkt, wäre es gut, weil es Patent-Trollen weniger Ansatzpunkte gäbe und wir uns in die Zukunft bewegen könnten, die uns zustehen sollte

  • Wird das veröffentlicht, oder ist das nur Engineering-Prahlerei? Außer diesem Blogpost finde ich keine weiteren Referenzen zu MLow
    Facebook/Meta AI Research macht beeindruckende Arbeit und veröffentlicht einen beträchtlichen Teil davon. Ich mag Facebook nicht, aber man kann anerkennen, dass sie im AI-Bereich sehr innovativ sind

    • Wenn gemeint ist, dass sie den Algorithmus in einem Produkt implementiert haben, dann scheint es so
      Im Text steht, man sei „sehr zufrieden mit dem, was wir in den letzten zwei Jahren erreicht haben – von der Entwicklung eines neuen Codecs bis hin zur erfolgreichen Auslieferung an Milliarden von Nutzern weltweit“

  • Ehrliche Frage: Warum sollte man auf unter 10 kbps optimieren?
    Dass sie bei 6 kbps dieses Niveau erreicht haben, ist wirklich beeindruckend, aber selbst LTE unterstützt bereits 32 kbps und mehr, und in diesem Bereich gibt es AMR-WB oder Opus. Opus hat bei dieser Bitrate auch In-Band-Forward-Error-Correction, sodass Paketverluste nicht so fatal sind.
    Für Anwendungen wie Satellit-direkt-aufs-Handy könnte es vielleicht nützlich sein.

    • Der Abschnitt „Motivation für die Entwicklung eines neuen Codecs“ im Artikel beantwortet diese Frage direkt.
      Anzunehmen, dass mehr als 32 kbps Bandbreite verfügbar sind, ist eine schlechte Annahme.
    • Es gibt Milliarden Menschen ohne LTE. Meta ist kein Unternehmen, das nur in der westlichen Welt tätig ist.
    • Metas Anwendungsfall sind OTT-Anwendungen über das Internet, und üblicherweise wird nach übertragenen Bytes abgerechnet.
      Wenn man die Bitrate des verwendeten Audio-Codecs senkt, kann man mit demselben Datentarif im Monat länger telefonieren.
      Allerdings nehmen die Vorteile in diesem Bereich wegen des Overheads von RTP, UDP und IP ab. Mehr dazu steht in einem anderen Kommentar von mir.
    • Nützlich ist es.
      Dieser Bereich wird derzeit von AMBE fest beherrscht, und AMBE ist nach allen messbaren Kriterien furchtbar und gehört in den tiefsten Flammen der Hölle verbrannt und aus der Geschichte getilgt.
    • Internetverbindungen haben normalerweise eine Kurve zwischen Durchsatz und Latenz.
      Wenn man wie bei einem Telefonat stabile niedrige Latenz braucht, ist der erreichbare Durchsatz sehr gering.
      Beispiele wären WLAN am Rand der Reichweite oder eine LTE-Verbindung mit nur einem Balken Empfang.
      In solchen Fällen kann ein Speedtest zwar ein paar Megabit anzeigen, aber wenn man stabile niedrige Latenz will, liegt die tatsächlich nutzbare Bandbreite vermutlich eher im Kilobit-Bereich.

  • Ich frage mich, wie es im Vergleich zu G.729 klingen würde.
    In einer Firma, bei der ich vor 20 Jahren gearbeitet habe, gab es einen modifizierten G.729-Codec, der auch unter 8 kbps noch ziemlich gut klang. Er wurde für VoIP über Einwahl-Internet verwendet, also wirklich mit sehr geringer Bandbreite.
    Wie sich herausstellte, lagen einige der interessanteren Aspekte beim Jitter Buffer und der Art des Buffer-Managements. Instabile Verbindungen liefern Pakete, wenn sie können, und es braucht Technik, um die Differenz zwischen Netzwerkerlebnis und Nutzererlebnis zu managen. In der Telekommunikation muss man das Nutzererlebnis richtig managen.