- Meta a conçu un nouveau codec audio à faible débit binaire, MLow, afin de maintenir la qualité des appels en temps réel sur WhatsApp, Instagram et Messenger, même sur des réseaux lents et des appareils anciens
- Opus fonctionne en NarrowBand à 6 kbps, ce qui ne permet pas de restituer suffisamment les fréquences de la voix ; quand le réseau se dégrade pendant un appel vidéo, le débit alloué à l’audio diminue encore davantage
- Les codecs audio basés sur le ML peuvent offrir une bonne qualité à faible débit, mais leur coût de calcul est élevé, ce qui les rend souvent mieux adaptés aux appareils mobiles récents et performants
- À 6 kbps en WideBand, MLow atteint un POLQA MOS de 3,9, soit une qualité environ deux fois supérieure au 1,89 d’Opus, avec une complexité de calcul 10 % plus faible qu’Opus
- Le codec est déjà déployé intégralement sur les appels Instagram et Messenger, et son déploiement est en cours sur WhatsApp ; à faible débit, il permet aussi d’intégrer plus efficacement du FEC, ce qui améliore la récupération audio en cas de perte de paquets
Pourquoi Meta a créé un nouveau codec
- Les applications Meta, dont WhatsApp, Instagram et Messenger, fournissent des fonctions de communication en temps réel (RTC) à des milliards d’utilisateurs
- Dans le RTC, les codecs audio et vidéo sont des composants essentiels : ils compressent les données capturées pour les transmettre sur Internet tout en maintenant l’appel en temps réel
- L’audio brut d’un appel standard représente 768 kbps avec un échantillonnage à 48 kHz, 16 bits, en mono ; les codecs modernes peuvent le compresser jusqu’à 25 à 30 kbps
- La compression entraîne une perte d’information qui peut dégrader la qualité, mais un bon codec équilibre qualité, débit et complexité en exploitant les caractéristiques du signal audio et les connaissances en psychoacoustique
- Opus est un codec open source largement connu, publié en 2012, que Meta utilisait jusqu’ici pour ses besoins RTC
Les contraintes du faible débit et des anciens appareils
- À l’échelle de l’infrastructure RTC de Meta, il est possible d’observer directement l’effet de conditions réseau très variées sur l’expérience d’appel
- Une part importante des appels subit une mauvaise connexion réseau sur tout ou partie de la communication
- Le module d’estimation de bande passante (BWE) détecte la qualité du réseau
- Quand cette qualité baisse, il faut réduire le débit du codec pour éviter la congestion et maintenir le flux audio
- En appel vidéo, la marge disponible pour l’audio se réduit encore davantage lorsque le réseau se détériore
- Le point de fonctionnement minimal d’Opus est 6 kbps, où il passe en mode NarrowBand, soit 0 à 4 kHz
- Cette plage ne capture pas suffisamment toutes les fréquences produites par la voix humaine
- La voix paraît donc moins claire et moins naturelle
- Les codecs audio fondés sur le ML, comme Encodec présenté par Meta en octobre 2022, offrent une très bonne clarté même à très bas débit
- Mais leur coût de calcul élevé fait qu’ils ne s’exécutent souvent de manière fiable que sur des appareils mobiles performants et coûteux
- Les utilisateurs d’appareils d’entrée de gamme continuent donc de souffrir de problèmes de qualité audio à faible débit
- Plus de 20 % des appels de Meta ont lieu sur des appareils ARMv7, et sur WhatsApp, des dizaines de millions d’appels sont encore passés chaque jour depuis des appareils vieux de plus de 10 ans
Performances de MLow et état du déploiement
- Meta a commencé à développer ce nouveau codec fin 2021 et, après près de deux ans de développement et de tests, a présenté Meta Low Bitrate audio codec, ou MLow
- À 6 kbps en WideBand, il atteint un POLQA MOS de 3,9, contre 1,89 pour Opus, soit environ deux fois mieux
- Sa complexité de calcul est 10 % plus faible que celle d’Opus
- Sur l’échelle MOS (Mean Opinion Score) de 1 à 5, MLow prend un net avantage sur Opus dans les plages de faible débit, et sa qualité atteint un plateau plus rapidement
- Il est déjà déployé sur l’ensemble des appels Instagram et Messenger, et son déploiement est activement en cours sur WhatsApp
- Meta a aussi constaté qu’une meilleure qualité audio se traduit par une hausse de l’engagement des utilisateurs
Le FEC en situation de perte de paquets
- Pouvoir encoder un audio de haute qualité à faible débit permet aussi d’utiliser plus efficacement les stratégies de Forward Error Correction (FEC)
- Par rapport à Opus, MLow laisse de la marge pour intégrer du FEC même à des débits plus faibles
- Cette caractéristique contribue à améliorer la qualité audio en cas de perte de paquets
- L’article présente un exemple à 14 kbps avec une perte de paquets côté réception atteignant 30 %
- Opus ne peut pas encoder de FEC in-band à ce débit
- Pour encoder du FEC in-band avec 10 % de perte de paquets, Opus a besoin d’au moins 19 kbps
- Cette contrainte nuit à la récupération audio
Structure interne de MLow
- MLow repose sur les concepts traditionnels des codecs CELP (Code Excited Linear Prediction)
- Les principales améliorations portent sur la génération de l’excitation, la quantification des paramètres et la méthode de codage
- L’encodeur prend en entrée un signal PCM brut et le sépare en bande basse fréquence et bande haute fréquence
- Chaque bande est encodée séparément, mais avec des informations partagées pour améliorer la compression
- La sortie est ensuite davantage compressée via un range encoder, ce qui produit la charge utile encodée
- Le décodeur reçoit cette charge utile et exécute l’opération inverse pour reconstruire le signal audio de sortie
- Grâce à une optimisation par sous-bandes, MLow peut encoder la bande haute fréquence avec très peu de bits
- Cette architecture lui permet de fournir de l’audio SuperWideBand, c’est-à-dire à 32 kHz d’échantillonnage, même à des débits plus faibles
Et ensuite
- MLow améliore nettement la qualité audio sur les appareils peu puissants tout en préservant le chiffrement de bout en bout des appels
- Comme il permet d’ajouter plus efficacement de l’information audio redondante à faible débit, les travaux se poursuivent pour améliorer la récupération audio sur les réseaux à forte perte de paquets
1 commentaires
Avis sur Hacker News
Les nouveaux codecs à bas débit sont impressionnants, mais dans la plupart des scénarios où Meta voudrait les utiliser, ils ne semblent pas forcément très utiles en pratique
Pour réduire la latence dans les communications en temps réel, la fréquence d’envoi des paquets doit être assez élevée, et à partir d’un certain point, la surcharge UDP, IP et des couches inférieures finit par dominer la charge utile réelle
Par exemple, (S)RTP au-dessus d’UDP/IP ajoute une surcharge totale de 40 octets : au minimum 12 octets pour RTP, 8 octets pour UDP et 20 octets pour IPv4. À 50 paquets par seconde, soit 20 ms de délai de sérialisation, la seule surcharge atteint 16 kbps
Si l’on descend à 25 paquets par seconde, la surcharge tombe à 8 kbps, mais elle représente tout de même une part importante du débit total
Là où ce type de codec brille vraiment, c’est dans les communications à commutation de circuits autour de 2 kbps, comme certains téléphones satellites, ou dans les systèmes VoIP conscients du protocole utilisant de la compression d’en-têtes, comme LTE/5G IMS, où la majeure partie des 40 octets par trame correspond à des en-têtes prévisibles
Des paquets de 100 ms augmentent beaucoup la latence, mais à ce niveau-là, les économies apportées par le codec deviennent significatives. Des systèmes plus sophistiqués peuvent ajuster le codec et le nombre d’échantillons par paquet selon les conditions du moment
Le système sur lequel je travaille utilise un codec fixe avec 60 ms d’audio par paquet, ce qui n’est pas idéal, mais il fonctionne bien mieux à faible bande passante que des paquets de 20 ms
Meta dispose aussi d’une distribution très large de serveurs de relais, ce qui lui laisse de la marge pour ajouter un peu de délai d’échantillonnage. Ils peuvent relayer via des équipements de contenu présents chez de nombreux FAI, ce qui réduit la latence réseau par rapport à des services concurrents dont la capacité mondiale d’hébergement de relais est plus limitée. Le P2P ne fonctionne pas toujours, et il n’offre pas non plus toujours une latence inférieure à celle d’un relais proche
Les messages vocaux et les appels WhatsApp, en particulier, ont une part d’usage importante dans des pays où les réseaux sont intermittents et peu fiables. Si l’on résiste mieux à la perte de paquets et à la gigue, on peut aussi s’appuyer sur des protocoles avec moins de surcharge liée à la correction d’erreurs, à la fragmentation et aux accusés de réception
Il n’est pas exagéré de penser que cette technologie peut réduire sensiblement la consommation totale de bande passante liée à l’audio, tout en maintenant ou en améliorant la fiabilité et la qualité perçue
En observant un appel WhatsApp actif avec Wireshark, j’ai vu environ 380 paquets UDP transmis de l’émetteur au récepteur pendant un appel d’une minute, ainsi que quelques paquets TCP vers le serveur WhatsApp. Cela met la surcharge de transport autour de 2,2 kbps
Pour expliquer pourquoi : ici, le ptime initial, c’est-à-dire la taille audio par paquet, est fixé à 20 ms, mais maxptime est fixé à 150 ms. Le client peut l’utiliser de manière opportuniste, en tenant compte de la latence des deux côtés et de la bande passante disponible, afin de réduire le nombre de paquets envoyés
Image : https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Les codecs vocaux couramment utilisés dans les systèmes radio, comme AMBE+2, sonnent assez mal et gèrent aussi beaucoup moins élégamment la perte de paquets que les nouveaux codecs
C’est peut-être du bluff, mais vu que Meta est l’un des plus grands fournisseurs d’appels audio et vidéo sur appareils à faible bande passante, cela paraît peu probable
Je ne vois pas sur quoi on se fonde pour dire que Meta se serait trompé tout seul depuis le début
Par exemple, si le chiffrement de bout en bout interdit le mixage côté serveur, on peut mettre les données de plusieurs flux dans un seul paquet. Les appels audio chiffrés de bout en bout sont désormais assez répandus, et Facebook semble bien placé pour faire du multiplexage personnalisé dans ses propres produits
Suis-je le seul à avoir l’impression que Meta redevient cool en partageant beaucoup de travaux de recherche, d’open source ou avec des poids ouverts
La réputation de Facebook était au plus bas, mais on dirait qu’ils ont désormais regagné un peu de terrain
La réputation de Facebook en tant que réseau social n’est peut-être pas brillante, mais celle de Meta comme entreprise d’ingénierie me semble assez élevée
C’est un peu comparable à IBM. Comme fournisseur de solutions matérielles ou logicielles, ils ne paraissent pas forcément excellents, mais leurs activités de recherche et de microélectronique restent assez impressionnantes
Microsoft Research sort aussi des choses vraiment remarquables, mais cela ne veut pas dire que le même Microsoft ne met pas de publicités dans le menu Démarrer de son système d’exploitation
Il y a quelques années, quand j’étais adolescent, j’ai observé cette dissonance intéressante chez Microsoft, et cela ne me surprend pas du tout qu’au sein de Facebook il y ait à la fois des équipes qui font des choses formidables comme zstandard, et des personnes totalement distinctes travaillant avec des objectifs complètement différents. Cette dissonance entre divisions existe probablement dans la plupart des entreprises de plus de quelques centaines de personnes
En revanche, je suis très négatif sur l’attitude de Meta en matière de vie privée, de sécurité et de responsabilité sociale
CassandraDB et (Py)Torch me viennent à l’esprit
L’absence totale de mention ou de comparaison avec Codec2 rend immédiatement suspectes la valeur réelle et la motivation de ce travail
Ce domaine n’a pas besoin d’un codec audio supplémentaire enfermé dans de la propriété intellectuelle
https://jmvalin.ca/demo/lpcnet_codec/
Je me demande s’il est meilleur que ce qu’utilise Google Meet
Même sur une connexion Internet lente, saccadée au point d’être presque inutilisable, Google Meet remplissait son rôle pour les appels audio, là où d’autres services concurrents échouaient. Par exemple, je l’ai testé sur une très mauvaise connexion Internet dans une île isolée aux Philippines
Cela dit, à ma connaissance, la technologie de Google Meet n’est publiée nulle part
Avec seulement quelques exemples publiés, nous ne pouvons guère en juger davantage
Pas de comparaison avec Pied Piper non plus
Je m’écarte un peu du sujet, mais pourquoi les appels téléphoniques ordinaires sont-ils aujourd’hui plus difficiles à comprendre que le μ-law 8 kHz 8 bits et l’ADPCM des années 90 ?
Correction : j’ai remplacé « le son est pire » par « plus difficiles à comprendre »
Ce n’est pas terrible pour la musique, mais c’est assez convenable pour la voix, et surtout c’est très constant. Dans les années 90, les appels étaient presque entièrement en commutation de circuits sur le dernier tronçon, et sur les lignes numériques ils étaient multiplexés au niveau des échantillons. Les lignes T1 et supérieures fonctionnaient ainsi
La latence était donc très faible et le jitter nul. Par rapport aux appels commutés en analogique de bout en bout, il y avait une latence mesurable, mais difficile à percevoir en pratique, et comme l’échantillonnage numérique se faisait près des deux extrémités, le bruit était nettement plus faible. La commutation de circuits signifie aussi qu’aucun échantillon n’est perdu. Soit la connexion est établie, soit elle ne l’est pas, avec parfois des cas où seul un sens fonctionne
Les appels modernes utilisent généralement des échantillons de 20 ms sur un réseau à commutation de paquets, ce qui ajoute du délai d’échantillonnage, du jitter et un tampon de jitter. Le codec lui-même fait aussi plus qu’un simple ADC/DAC avec une loi logarithmique, donc il y a un délai d’encodage et de décodage. La plupart des codecs utilisent bien moins de bits par échantillon que le μ-law, et cela n’est pas gratuit
HD Voice (G.722.2 AMR-Wideband) a une bande passante en fréquence bien plus large et sonne donc bien mieux que GSM, Opus et la plupart des codecs à faible bande passante. Mais la latence demeure. Certains diront qu’un délai de 20 à 100 ms n’est pas perceptible, mais si on fait écouter en A/B un appel à 0 ms et un appel à 20 ms de latence, les gens diront que l’appel à 0 ms est meilleur
En 2013, je suis passé d’un téléphone à clapet à un iPhone, et la différence était énorme. Je me suis immédiatement mis à utiliser des écouteurs ou le haut-parleur, alors que j’étais adolescent à l’époque
La plupart des appels des années 90 n’utilisaient pas l’ADPCM, mais simplement le PCM. C’est probablement là que vient la confusion
Et il n’y avait pas non plus de sans-fil. Il y avait un solide fil de cuivre entre mon micro et le combiné de l’autre personne. Le sans-fil — téléphone mobile, Wi‑Fi, téléphone sans fil — est intrinsèquement moins fiable
Les anciens téléphones avaient un retour local (sidetone), mais beaucoup d’apps VoIP n’en ont pas
Enfin, l’usage du haut-parleur est aujourd’hui très répandu, or il se marie mal avec le retour local et ajoute beaucoup d’évanouissement par trajets multiples audio
L’absence de mention de NoLACE rend les échantillons de comparaison un peu moins utiles : https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Ce serait bien que Meta en fasse don au monde, pour réduire les entraves des patent trolls et nous rapprocher de l’avenir dont nous devrions bénéficier
Est-ce qu’ils vont le publier, ou est-ce juste de la démonstration d’ingénierie ? Je ne trouve aucune autre référence à MLow en dehors de cet article de blog
Facebook/Meta AI Research fait des choses remarquables, et en publie une bonne partie. Je n’aime pas Facebook, mais je reconnais qu’ils sont très innovants dans le domaine de l’IA
L’article dit : « nous sommes très heureux de ce que nous avons accompli ces deux dernières années : développer un nouveau codec et le déployer avec succès auprès de milliards d’utilisateurs dans le monde »
Question sincère : pourquoi faudrait-il optimiser pour moins de 10 kbit/s ?
Obtenir ce niveau à 6 kbit/s est vraiment impressionnant, mais la LTE prend déjà en charge 32 kbit/s et plus, et dans cette plage il y a AMR-WB ou Opus. Opus dispose aussi, à ces débits, d’une correction d’erreurs directe intrabande, donc les pertes de paquets ne sont pas si critiques.
Cela pourrait être utile pour des usages comme le satellite direct vers mobile.
Supposer qu’il existe une bande passante supérieure à 32 kbit/s est une mauvaise hypothèse.
Réduire le débit du codec audio utilisé permet de passer plus d’appels dans le mois avec le même forfait data.
Cela dit, dans cette zone, les gains diminuent à cause de la surcharge RTP, UDP et IP. J’en parle plus en détail dans un autre commentaire que j’ai posté.
Ce domaine est actuellement dominé par AMBE, qui est atroce selon toutes les métriques mesurables et mériterait d’être brûlé dans les flammes les plus profondes de l’enfer pour être effacé de l’histoire.
Si l’on a besoin d’une faible latence stable, comme pour un appel téléphonique, le débit que l’on peut obtenir devient très faible.
Par exemple, un Wi‑Fi en limite de portée ou une connexion LTE avec une seule barre de signal.
Dans ces cas-là, un test de débit peut annoncer quelques mégabits, mais si l’on veut une faible latence stable, la bande passante réellement utilisable sera probablement de l’ordre du kilobit.
Je me demande quel serait le rendu par rapport à G.729.
Dans l’entreprise où je travaillais il y a 20 ans, il y avait un codec G.729 modifié qui restait assez correct même en descendant sous les 8 kbit/s. On l’utilisait pour de la VoIP sur Internet par accès commuté, donc vraiment à très faible bande passante.
Il s’est avéré qu’une partie des aspects les plus intéressants se trouvait dans le tampon de gigue et la manière de gérer les buffers. Une connexion instable transmet les paquets quand elle le peut, et il faut du savoir-faire pour gérer l’écart entre l’expérience réseau et l’expérience utilisateur. Dans les télécommunications, il faut gérer correctement l’expérience utilisateur.