Le meilleur système neuronal de masquage de perte de paquets du INTERSPEECH 2022 Audio Deep PLC Challenge de Microsoft a obtenu un PLCMOS de 4,28 sur une échelle de 1 à 5, contre 2,90 en insérant simplement du silence et 4,51 pour l’original propre (Microsoft, article du INTERSPEECH 2022 Audio Deep PLC Challenge). Deux ans plus tard, lorsque le même défi est passé à l’audio en bande complète et à des rafales de pertes allant jusqu’à 3 secondes, les gagnants ex aequo n’ont pu faire passer la qualité globale que de 2,37 à 3,49, très en dessous des 4,01 obtenus par la voix propre (Microsoft, article du ICASSP 2024 Audio Deep PLC Challenge). Le problème n’est pas rare : Google a indiqué que 99% des appels Duo devaient composer avec des pertes de paquets, de la gigue ou du retard, et qu’un appel sur dix perdait plus de 8% de son audio (Google Research, blog WaveNetEQ 2020). Le masquage est la couche silencieuse qui sous-tend les tendances commerciales de nos statistiques VoIP et UCaaS, et il complète le tableau côté opérateurs de nos statistiques de qualité vocale cellulaire (MOS). Nous avons agrégé des données issues des articles des défis de Microsoft Research, de l’IETF et de l’ITU-T, du W3C, de Google Research, des développeurs d’Opus de Xiph.Org, de Meta Engineering, de la documentation de Microsoft Learn et de Twilio, ainsi que d’études PLC évaluées par des pairs listées dans la méthodologie.
TL;DR
- 99% des appels Google Duo ont dû gérer des pertes de paquets, de la gigue ou du retard ; 10% ont perdu plus de 8% de l’audio total (Google Research, blog WaveNetEQ 2020).
- Microsoft Teams classe un flux audio Poor lorsque la perte de paquets moyenne dépasse 0,1, soit 10% (Microsoft Learn, CQD Stream Classification 2026).
- G.711 avec son masquage de l’Appendix I a un facteur de robustesse aux pertes de paquets de 25,1, contre 4,3 sans masquage (ITU-T G.113, 09/2024).
- Gagnant du PLC neuronal : PLCMOS 4,28 contre 2,90 pour le remplissage par des zéros et 4,51 pour la voix propre (Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge).
- Le PLC hybride de l’équipe Opus s’est classé premier sur la précision des mots (0,882) et deuxième au classement général lors du défi 2022 (Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022).
- Avec des rafales allant jusqu’à 3 secondes, 2 des 8 systèmes éligibles ont obtenu un score inférieur à celui de l’audio dégradé non traité sur la qualité globale P.804 (Microsoft, article du ICASSP 2024 Deep PLC Challenge).
- Le PLCMOS atteint une corrélation de Pearson par modèle d’environ 0,97 avec les notes humaines ; sur des données alignées sur la référence, PESQ obtient 0,52 (Diener et al., article PLCMOS 2023).
- La FEC intégrée LBRR d’Opus couvre 1 trame à environ 2/3 du débit normal ; DRED couvre jusqu’à 1 seconde à environ 1/50 (IETF draft-ietf-mlcodec-opus-dred-07, août 2026).
- Opus a besoin d’au moins 19 kbps pour encoder la FEC intégrée avec 10% de perte de paquets, d’après la propre comparaison MLow de Meta (Meta Engineering, MLow 2024).
- Opus 1.6 a réduit ses modèles DRED d’environ 3 fois, à 600 kB contre 1 800 kB (Xiph.Org, démo d’Opus 1.6, décembre 2025).
1. Quelle quantité d’audio est perdue et où les plateformes placent la limite
Un paquet, dans ce contexte, est une petite tranche d’audio (souvent 20 ms) envoyée sur le réseau. Lorsqu’il arrive trop tard ou pas du tout, le récepteur a deux choix : jouer du silence, ou masquer le trou en synthétisant quelque chose qui ressemble à la parole manquante. Les données de Google montraient que 99% des appels Duo devaient composer avec des pertes de paquets, de la gigue ou du retard (Google Research, Improving Audio Quality in Duo with WaveNetEQ 2020). Le masquage n’est donc pas un cas marginal : il tourne dans presque tous les appels.
Les plateformes ne s’accordent pas sur le seuil à partir duquel la perte passe du bruit de fond à un vrai problème. Microsoft Teams place sa limite Poor à 10% de perte moyenne, Twilio à 5%, et Microsoft avertit explicitement qu’une étiquette Poor ne signifie pas que les utilisateurs ont réellement perçu un problème de qualité, car sa pile média corrige les pertes (Microsoft Learn, Stream Classification in CQD 2026). Cette réserve résume tout l’argument en faveur d’un meilleur masquage : plus le PLC va loin, plus une plateforme peut relever son seuil d’alarme.
| Métrique | Valeur | Source |
|---|---|---|
| Part des appels Google Duo devant composer avec des pertes de paquets, de la gigue ou du retard | 99% | Google Research, blog WaveNetEQ 2020 |
| Part des appels Duo perdant plus de 3% de leur durée audio totale | 20% | Google Research, blog WaveNetEQ 2020 |
| Part des appels Duo perdant plus de 8% de leur durée audio totale | 10% | Google Research, blog WaveNetEQ 2020 |
| Taux moyen de perte de paquets au-dessus duquel Teams classe un flux audio Poor | Au-dessus de 0,1 (10%), appliqué uniquement aux flux de plus de 500 paquets | Microsoft Learn, CQD Stream Classification 2026 |
| Niveau de perte de paquets qui déclenche l’étiquette d’appel high_packet_loss de Twilio | Au-dessus de 5% | Twilio Voice Insights, Details: Call Tags |
| MOS estimé en dessous duquel Twilio étiquette low_mos un appel via navigateur ou SDK mobile | En dessous de 3,5 | Twilio Voice Insights, Details: Call Tags |
| Taux de perte moyen dans l’ensemble de test du Deep PLC Challenge utilisé pour évaluer Opus DRED | 18,4%, avec des rafales allant jusqu’à une seconde | Valin et al., article DRED (arXiv 2212.04453 v3, 2024) |
Données les plus récentes disponibles : Google Research, 2020. Aucune grande plateforme n’a publié de distribution des pertes au niveau des appels plus récente. Teams rapporte l’indicateur associé « Ratio Concealed Samples Avg » par flux, où 0,1 signifie que 10% des trames audio contenaient des échantillons masqués (Microsoft Learn, CQD dimensions and measures 2026), mais Microsoft ne publie pas de valeurs sur l’ensemble de son parc. Les équivalents côté navigateur, concealedSamples et concealmentEvents, sont définis dans l’API de statistiques WebRTC du W3C (Candidate Recommendation Draft, 25 septembre 2025).
2. Le masquage des codecs classiques dans le modèle E de l’ITU-T
Avant les réseaux de neurones, masquer voulait dire répéter ou extrapoler la dernière période de pitch correcte. Le modèle de planification de l’ITU-T (le modèle E) note la capacité d’un codec à survivre aux pertes avec le facteur de robustesse aux pertes de paquets, Bpl : un simple nombre dont une valeur élevée signifie que la qualité se dégrade plus lentement à mesure que les paquets disparaissent. G.711 avec l’algorithme de masquage de son Appendix I a un Bpl de 25,1, soit près de six fois les 4,3 de G.711 sans masquage (ITU-T G.113 09/2024, Tableau I.4).
Ce que cet écart signifie en pratique est plus clair avec des chiffres. En utilisant l’équation 7-29 de l’ITU-T G.107 (06/2015), Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl), G.711 (Ie = 0) avec 5% de perte aléatoire (BurstR = 1) donne 95 x 5 / (5 + 4,3) = 51,1 points de dégradation sans masquage, et 95 x 5 / (5 + 25,1) = 15,8 avec masquage. Soustraits de la note par défaut de R = 93,2, cela donne R 42,1 contre R 77,4, que la formule de l’Annexe B de G.107 convertit en un MOS estimé d’environ 2,2 contre 3,9 (notre calcul ; toutes les autres entrées du modèle E laissées à leur valeur par défaut). Le masquage seul fait passer un appel avec 5% de perte de médiocre à acceptable.
| Métrique | Valeur | Source |
|---|---|---|
| G.711 (64 kbit/s, paquets de 10 ms) sans masquage : facteur de robustesse aux pertes de paquets Bpl en cas de perte aléatoire | 4,3 | ITU-T G.113 (09/2024), Tableau I.4 |
| G.711 avec l’algorithme de masquage de l’Appendix I de G.711 : Bpl en cas de perte aléatoire | 25,1 | ITU-T G.113 (09/2024), Tableau I.4 |
| G.729 Annex A avec détection d’activité vocale (8 kbit/s, paquets de 20 ms, masquage natif) : Ie et Bpl | Ie 11, Bpl 19,0 | ITU-T G.113 (09/2024), Tableau I.4 |
| G.711 avec paquets de 20 ms, 8 paquets perdus en une seule rafale à 2% de perte (rapport de rafale 7,84) : dégradation effective Ie-eff | 10 | ITU-T G.113 (09/2024), Tableau I.6 |
| G.722 à 64 kbit/s avec le masquage haute qualité de l’Appendix III de G.722 : Bpl large bande (écoute des deux oreilles) | 7,1 | ITU-T G.113 (09/2024), Appendix IV |
| EVS en mode super large bande à 24,4 kbit/s : Bpl en bande complète | 11,4 | ITU-T G.113 (09/2024), Appendix V |
| Facteur de notation R du modèle E lorsque toutes les entrées sont à leur valeur par défaut | 93,2 | ITU-T G.107 (06/2015) |
Contexte : les valeurs de Bpl ne sont comparables qu’au sein d’une même échelle (bande étroite, large bande ou bande complète). G.113 ne liste aucune valeur pour Opus, si bien que l’audio WebRTC fondé sur Opus doit être évalué avec d’autres outils (voir section 5).
3. Masquage neuronal contre silence : le Deep PLC Challenge de 2022
Le défi INTERSPEECH 2022 a évalué le PLC neuronal sur des profils de pertes réels, à partir de traces enregistrées lors d’appels Microsoft Teams et avec une règle stricte de temps réel : une latence algorithmique totale d’au plus 20 ms. Son résultat principal est l’ampleur de l’écart entre le gagnant et l’absence de traitement. Le système gagnant a obtenu -0,55 sur l’échelle de comparaison (CMOS, où 0 signifie indiscernable de l’original propre), contre -1,23 pour le remplissage par des zéros (Microsoft, article du INTERSPEECH 2022 Audio Deep PLC Challenge).
L’intelligibilité raconte une histoire plus modeste. La précision des mots, mesurée comme 1 moins le taux d’erreur sur les mots d’un système de reconnaissance vocale, n’est passée que de 0,86 avec le silence à 0,88 pour le gagnant, contre 0,97 pour la voix propre. Les auditeurs perçoivent le masquage comme une grande amélioration, mais le système de reconnaissance a tout de même manqué 12% des mots avec le système gagnant, contre 3% sur la voix propre, un constat à garder à l’esprit à côté de nos statistiques sur le taux d’erreur sur les mots en reconnaissance vocale.
| Métrique | Valeur | Source |
|---|---|---|
| Parole de référence propre : PLCMOS (1 à 5) et précision des mots | 4,51 et 0,97 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| Base de référence par remplissage par des zéros (silence à la place des paquets perdus) : PLCMOS, CMOS et précision des mots | 2,90, -1,23 et 0,86 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| Système gagnant (équipe #12, U-Net dans le domaine temporel, environ 2,36M de paramètres) : PLCMOS, CMOS et précision des mots | 4,28, -0,55 et 0,88 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| Système éligible le moins bien classé (équipe #6) contre la base de référence par remplissage par des zéros : CMOS | -1,31 contre -1,23 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| PLC hybride génératif et prédictif de l’équipe Opus : précision des mots et rang sur cette métrique | 0,882, premier ; deuxième sur le CMOS et au classement général | Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| Même système : calcul par tranche de 10 ms de parole sur un processeur de portable (Intel i7-10810U) | 1,3 à 1,4 ms, soit environ 13% à 14% d’un cœur | Valin et al. 2022 |
Note sur les valeurs aberrantes : un système classé a obtenu sur le CMOS un score inférieur à celui de la base de référence en silence, ce qui rappelle qu’un générateur mal réglé peut sonner pire qu’un trou. L’ensemble en aveugle était pondéré en faveur des rafales courtes : 504 de ses 966 extraits avaient une rafale maximale allant jusqu’à 120 ms. Les chiffres du système hybride proviennent de Valin et al., dont le masquage a ensuite été livré dans Opus 1.5 (voir section 7).
4. Longues rafales : là où le masquage décroche encore (ICASSP 2024)
L’édition 2024 a volontairement durci la tâche : audio 48 kHz en bande complète, noté avec la méthode multidimensionnelle ITU-T P.804 (Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge), et des rafales de pertes allant jusqu’à 3 secondes. Même le meilleur système n’a comblé qu’environ les deux tiers de la distance entre l’audio dégradé et l’audio propre : la qualité globale est passée de 2,37 à 3,49, contre 4,01 pour la voix propre ((3,49 - 2,37) / (4,01 - 2,37) = 68%) (Microsoft, article du ICASSP 2024 Audio Deep PLC Challenge).
La colonne la plus parlante est la discontinuité, le score P.804 pour les ruptures et les accrocs audibles (plus c’est élevé, plus c’est fluide). Elle est passée de 2,47 à 3,90 pour le meilleur système, un bond supérieur à celui de toute autre dimension. Le masquage répare d’abord les trous que remarquent les auditeurs, tandis que la parole synthétisée coûte encore en naturel. La précision des mots montre aussi ce compromis : l’un des gagnants ex aequo a reconnu 0,81 des mots, légèrement en dessous des 0,83 de l’audio dégradé intact, signe qu’une parole inventée peut induire en erreur un système de reconnaissance davantage que le silence.
| Métrique | Valeur | Source |
|---|---|---|
| Qualité globale P.804 (1 à 5) : voix propre, audio dégradé non traité et gagnants ex aequo (1024K et NWPU & ByteAudio) | 4,01, 2,37 et respectivement 3,49 et 3,44 | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Score de discontinuité P.804 : propre, dégradé et meilleur système (1024K) | 4,55, 2,47 et 3,90 | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Précision des mots : propre, dégradé, 1024K et NWPU & ByteAudio | 0,98, 0,83, 0,81 et 0,84 | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Systèmes éligibles ayant un score inférieur à celui de l’audio dégradé non traité sur la qualité globale P.804 | 2 sur 8 (2,11 et 2,17) | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Bande passante audio et méthode de test d’écoute de l’édition 2024 | Bande complète, 48 000 Hz ; notation multidimensionnelle ITU-T P.804 et taux d’erreur sur les mots | Microsoft Research, page du ICASSP 2024 Deep PLC Challenge |
Contexte : un neuvième système a obtenu 2,91 au global mais a dépassé la limite de latence et a été classé comme non abouti. Les organisateurs notent que les systèmes de l’époque de 2022 « pourraient ne pas bien fonctionner pour des séquences de pertes plus longues », ce qui est exactement le point où le codage de redondance (section 6) prend le relais.
5. Noter le masquage : pourquoi les métriques de qualité génériques passent à côté
Les erreurs de masquage sont brèves, intermittentes et souvent plausibles, ce que les métriques de qualité généralistes n’ont précisément pas été conçues pour détecter. Sur des données alignées sur la référence, PESQ a atteint une corrélation de Pearson par modèle de seulement 0,52 avec les notes humaines attribuées aux systèmes de PLC, et STOI seulement 0,21, tandis que PLCMOS a atteint 0,98 (Diener et al., article PLCMOS, Microsoft, Interspeech 2023). Une métrique qui classe mal les systèmes peut orienter tout un domaine de recherche dans la mauvaise direction.
PLCMOS fonctionne sans référence propre, ce qui compte pour les vrais appels où l’audio d’origine n’est jamais disponible côté récepteur. Sa faiblesse est la précision au niveau du fichier : 0,85 par extrait contre 0,97 par système, de sorte qu’il classe les algorithmes bien mieux qu’il ne juge un appel isolé. La même tension traverse la notation de la parole synthétique, traitée dans nos statistiques MOS sur le naturel de la parole synthétique.
| Métrique | Valeur | Source |
|---|---|---|
| PLCMOS contre notes humaines : corrélation de Pearson et corrélation de rang par modèle | Environ 0,97 et environ 0,95 | Diener et al., article PLCMOS 2023 |
| DNSMOS (métrique générale de suppression du bruit) : corrélation de Pearson par fichier contre par modèle | 0,52 contre 0,85 | Diener et al., article PLCMOS 2023 |
| PESQ contre PLCMOS sur des données alignées sur la référence : corrélation de Pearson par modèle | 0,52 contre 0,98 | Diener et al., article PLCMOS 2023 |
| STOI (métrique d’intelligibilité) : corrélation de Pearson par modèle | 0,21 | Diener et al., article PLCMOS 2023 |
| Votes humains dans le principal jeu d’entraînement de PLCMOS (LibriSpeech Basic) | 333 740 | Diener et al., article PLCMOS 2023 |
| Fichiers de test dans la batterie de tests d’écoute des codecs d’apprentissage automatique de l’IETF | 100 de parole propre, 90 avec bruit ou réverbération, 20 avec locuteurs qui se chevauchent | IETF draft-ietf-mlcodec-test-battery-00, juin 2026 |
Contexte : dans l’étude préliminaire d’étiquetage de PLCMOS, les notes issues du crowdsourcing étaient corrélées à celles des experts à environ 0,83 PCC (IC à 95% : [0,78, 0,87]). Le projet de batterie de tests de l’IETF présente encore ses scénarios de perte de paquets comme « Détails à définir (TBD) », il n’existe donc pas encore de test de perte standard pour les codecs neuronaux.
6. Codage de redondance : payer des bits pour éviter le masquage
Le masquage devine ; la redondance envoie une sauvegarde. La correction d’erreurs directe (FEC) consiste à joindre aux paquets suivants une copie de moindre qualité de l’audio précédent, de sorte qu’un paquet perdu puisse être reconstruit plutôt qu’inventé. Le compromis est la bande passante. La FEC intégrée classique d’Opus (LBRR) ne couvre qu’une seule trame à environ 2/3 du débit normal, tandis que Deep REDundancy (DRED) transporte jusqu’à une seconde ou plus à environ 1/50 du débit normal (IETF draft-ietf-mlcodec-opus-dred-07, août 2026).
L’ancienne approche RED montre l’ampleur de l’effet. Dans un test Chrome à 20% de perte, l’envoi d’une trame précédente dans chaque paquet a fait passer la part d’audio masqué de 18% à 4%, et deux trames précédentes l’ont ramenée à 0,7% (webrtcHacks, RED: Improving Audio Quality with Redundancy 2020). Le coût : l’audio est passé d’environ 30 kbps à 60 kbps avec une copie et à 90 kbps avec deux. DRED existe pour obtenir une protection similaire sans doubler le débit.
| Métrique | Valeur | Source |
|---|---|---|
| FEC intégrée LBRR d’Opus : profondeur de redondance et coût en débit | 1 trame ; environ 2/3 du débit Opus normal | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Opus DRED : profondeur de redondance et coût en débit | Jusqu’à une seconde ou plus par paquet ; environ 1/50 du débit normal | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Évaluation de DRED : redondance transportée par paquet et nombre de fois où chaque trame est envoyée | 1,04 seconde ; 52 copies | Valin et al., article DRED (arXiv 2212.04453 v3, 2024) |
| Débit de la condition de test LBRR dans l’évaluation de DRED (base de 24 kb/s plus LBRR) | 40 kb/s au total, LBRR en moyenne d’environ 16 kb/s | Valin et al., article DRED 2024 |
| Part d’audio masqué à 20% de perte dans Chrome : sans RED, avec une trame précédente et avec deux trames précédentes | 18%, 4% et 0,7% | webrtcHacks, test RED de Hancke 2020 |
| Part d’audio masqué à 60% de perte aléatoire : sans RED, avec une et avec deux trames précédentes | 60%, 32% et 18% | webrtcHacks, test RED de Hancke 2020 |
| Débit minimal d’Opus pour encoder la FEC intégrée avec 10% de perte de paquets | 19 kbps (comparaison du fournisseur lui-même) | Meta Engineering, blog du codec MLow 2024 |
| Débit des échantillons MLow de Meta avec 30% de perte de paquets côté récepteur | 14 kbps (affirmation du fournisseur lui-même) | Meta Engineering, blog du codec MLow 2024 |
Contexte : les chiffres de webrtcHacks proviennent d’un test de laboratoire de 2020 réalisé par un seul auteur (la mesure publique de RED dans Chrome la plus récente disponible). Les chiffres de Meta proviennent de sa propre annonce de MLow et n’ont pas été reproduits de manière indépendante. Toutes les différences de DRED dans le test d’écoute P.808 de l’article (966 énoncés, 10 auditeurs chacun) ont été jugées significatives à p < 0,05.
7. Déployer le masquage : calcul, empreinte et normes
Un modèle de masquage n’a d’intérêt que s’il tient sur le téléphone le moins cher de l’appel. Le Deep PLC d’Opus 1.5 coûte environ 1% d’un cœur de processeur de portable avec des taux de perte élevés et ajoute environ 1 MB à la bibliothèque (Xiph.Org, démo d’Opus 1.5, mars 2024, chiffres des développeurs eux-mêmes). La contribution de l’équipe au défi 2022 nécessitait 13% à 14% d’un cœur (section 3), même si les deux chiffres ont été mesurés différemment et ne constituent pas une comparaison strictement équivalente.
La couche des normes, en revanche, bouge à peine. Les règles audio de WebRTC (RFC 7874, 2016) imposent Opus et G.711 mais ne fixent aucune exigence de masquage ou de FEC, laissant la qualité sous perte entièrement à chaque implémentation. Opus 1.6 a continué à réduire les modèles : ses réseaux DRED sont environ 3 fois plus petits que dans la version 1.5 (Xiph.Org, démo d’Opus 1.6, décembre 2025).
| Métrique | Valeur | Source |
|---|---|---|
| Deep PLC d’Opus 1.5 : taille ajoutée à la bibliothèque et coût CPU | Environ 1 MB ; environ 1% d’un cœur de portable avec des pertes élevées ; nécessite une complexité de décodeur de 5 ou plus | Xiph.Org, démo d’Opus 1.5 2024 (chiffres des développeurs eux-mêmes) |
| DRED d’Opus 1.5 : taille ajoutée à la bibliothèque, coût à l’exécution et surcoût en débit | Environ 2 MB ; environ 1% ; environ 12 à 32 kb/s | Xiph.Org, démo d’Opus 1.5 2024 (chiffres des développeurs eux-mêmes) |
| Vocodeur neuronal FARGAN utilisé pour synthétiser la parole masquée et redondante : complexité | 600 MFLOPS, 1/5 de LPCNet | Xiph.Org, démo d’Opus 1.5 2024 |
| Taux de perte dans les tests WebRTC d’Opus 1.5 (PLCMOS v2) | 0% à 90% par pas de 10% ; DRED maintiendrait la qualité à 90% de perte | Xiph.Org, démo d’Opus 1.5 2024 (affirmation des développeurs eux-mêmes) |
| Taille du modèle DRED d’Opus 1.6 contre Opus 1.5 | 600 kB contre 1 800 kB | Xiph.Org, démo d’Opus 1.6, décembre 2025 |
| Tailles de trame d’Opus, longueur des paquets et plage de débit | Trames de 2,5 à 60 ms ; paquets jusqu’à 120 ms ; 6 à 510 kbit/s | IETF RFC 6716 (2012) |
| Délai algorithmique d’Opus | 5 ms à 65,2 ms | IETF RFC 6716 (2012) |
| Codecs que les points de terminaison WebRTC doivent prendre en charge | Opus et G.711 (PCMA et PCMU) ; aucune exigence de PLC ou de FEC | IETF RFC 7874 (2016) |
Contexte : les RFC 6716 et RFC 7874 ont plus de trois ans mais restent les normes en vigueur (RFC 6716, RFC 7874). Le projet DRED, s’il est approuvé, mettrait à jour la RFC 6716 avec une couche de redondance neuronale.
Résumé : le masquage de perte de paquets audio WebRTC en chiffres
| Métrique | Valeur | Source |
|---|---|---|
| Appels Google Duo devant composer avec des pertes de paquets, de la gigue ou du retard | 99% | Google Research, blog WaveNetEQ 2020 |
| Appels Duo perdant plus de 8% de leur audio | 10% | Google Research, blog WaveNetEQ 2020 |
| Seuil Poor de Teams pour la perte de paquets audio moyenne | Au-dessus de 0,1 (10%) | Microsoft Learn, CQD Stream Classification 2026 |
| Seuil de l’étiquette high_packet_loss de Twilio | Au-dessus de 5% | Twilio Voice Insights, Details: Call Tags |
| Facteur de robustesse Bpl de G.711 : sans masquage contre masquage de l’Appendix I | 4,3 contre 25,1 | ITU-T G.113 (09/2024) |
| G.729 Annex A avec détection d’activité vocale : Bpl | 19,0 | ITU-T G.113 (09/2024) |
| PLCMOS du défi 2022 : remplissage par des zéros, gagnant et voix propre | 2,90, 4,28 et 4,51 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| Précision des mots du défi 2022 : remplissage par des zéros, gagnant et voix propre | 0,86, 0,88 et 0,97 | Microsoft, article du INTERSPEECH 2022 Deep PLC Challenge |
| Calcul du PLC hybride de l’équipe Opus par tranche de 10 ms de parole | 1,3 à 1,4 ms (13% à 14% d’un cœur) | Valin et al. 2022 |
| Qualité globale P.804 du défi 2024 : dégradé, meilleur système et voix propre | 2,37, 3,49 et 4,01 | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Systèmes du défi 2024 ayant un score inférieur à celui de l’audio dégradé non traité | 2 sur 8 | Microsoft, article du ICASSP 2024 Deep PLC Challenge |
| Corrélation de Pearson par modèle de PLCMOS avec les notes humaines | Environ 0,97 | Diener et al., article PLCMOS 2023 |
| Corrélation de Pearson par modèle de PESQ et STOI sur des systèmes de PLC | 0,52 contre 0,21 | Diener et al., article PLCMOS 2023 |
| Profondeur de redondance de LBRR contre DRED | 1 trame contre jusqu’à une seconde ou plus | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Débit de redondance de DRED par rapport à Opus normal | Environ 1/50 | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Audio masqué à 20% de perte : sans RED contre RED à deux trames | 18% contre 0,7% | webrtcHacks, test RED de Hancke 2020 |
| Débit minimal de la FEC intégrée d’Opus avec 10% de perte | 19 kbps (comparaison du fournisseur lui-même) | Meta Engineering, blog du codec MLow 2024 |
| Coût CPU du Deep PLC d’Opus 1.5 | Environ 1% d’un cœur de portable | Xiph.Org, démo d’Opus 1.5 2024 |
| Taille du modèle DRED d’Opus 1.6 contre 1.5 | 600 kB contre 1 800 kB | Xiph.Org, démo d’Opus 1.6 2025 |
Méthodologie et sources
- Microsoft Research, article du INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge (Diener et al., 2022) : arxiv.org/pdf/2204.05222
- Microsoft Research, article du ICASSP 2024 Audio Deep Packet Loss Concealment Challenge (2024) : arxiv.org/html/2402.16927v1
- Microsoft Research, page du programme ICASSP 2024 Audio Deep PLC Challenge : microsoft.com
- Diener et al., PLCMOS: a data-driven non-intrusive metric for the evaluation of packet loss concealment algorithms (Interspeech 2023) : arxiv.org/pdf/2305.15127
- Valin et al., Real-Time Packet Loss Concealment With Mixed Generative and Predictive Model (2022) : arxiv.org/pdf/2205.05785
- Valin et al., DRED: Deep REDundancy Coding of Speech Using a Rate-Distortion-Optimized Variational Autoencoder (arXiv v3, 2024) : arxiv.org/pdf/2212.04453
- IETF, Deep Audio Redundancy (DRED) Extension for the Opus Codec, draft-ietf-mlcodec-opus-dred-07 (août 2026) : ietf.org
- IETF, ML codec listening test battery, draft-ietf-mlcodec-test-battery-00 (juin 2026) : ietf.org
- IETF RFC 6716, Definition of the Opus Audio Codec (2012) : rfc-editor.org
- IETF RFC 7874, WebRTC Audio Codec and Processing Requirements (2016) : rfc-editor.org
- W3C, Identifiers for WebRTC’s Statistics API (Candidate Recommendation Draft, 25 septembre 2025) : w3.org
- ITU-T G.113 (09/2024), Transmission impairments due to speech processing : itu.int
- ITU-T G.107 (06/2015), The E-model : itu.int
- Google Research, Improving Audio Quality in Duo with WaveNetEQ (avril 2020) : research.google
- Microsoft Learn, Stream Classification in Call Quality Dashboard (mis à jour en juin 2026) : learn.microsoft.com
- Microsoft Learn, Dimensions and measures available in Call Quality Dashboard (mis à jour en juillet 2026) : learn.microsoft.com
- Twilio, Voice Insights Details: Call Tags : twilio.com
- Meta Engineering, MLow: Meta’s low bitrate audio codec (juin 2024) : engineering.fb.com
- Xiph.Org, démo d’Opus 1.5 (mars 2024) et démo d’Opus 1.6 (décembre 2025) : opus-codec.org/demo/opus-1.5, opus-codec.org/demo/opus-1.6
- webrtcHacks, RED: Improving Audio Quality with Redundancy (Philipp Hancke, août 2020) : webrtchacks.com
- Note sur les données : la seule distribution des pertes au niveau des appels d’une grande plateforme est le chiffre Duo de 2020 de Google, et les mesures de masquage RED sont un test de 2020 réalisé par un seul auteur ; les deux sont donc signalés comme les données les plus récentes disponibles. L’exemple du modèle E en section 2 est notre propre calcul à partir de l’équation 7-29 et de l’Annexe B de l’ITU-T G.107 avec les valeurs Bpl de G.113, en laissant toutes les autres entrées à leur valeur par défaut ; c’est une estimation, pas une mesure. Les scores des défis ne sont pas comparables d’une édition à l’autre : 2022 utilisait de l’audio en large bande, PLCMOS et CMOS avec des rafales allant jusqu’à 1 seconde, alors que 2024 utilisait de l’audio en bande complète, P.804 et des rafales allant jusqu’à 3 secondes. Dans l’article de 2022, PLCMOS était corrélé au CMOS à environ 0,95 de Pearson, alors que la version ultérieure de PLCMOS rapporte environ 0,97 sur un autre jeu d’évaluation. Les chiffres de Xiph.Org et de Meta sont les affirmations des développeurs eux-mêmes. Les seuils de Teams (10%) et de Twilio (5%) divergent par conception, car chaque fournisseur les ajuste à sa propre pile média. Le projet DRED (qui expire en février 2027) et le projet de batterie de tests de l’IETF, dont les scénarios de perte de paquets sont encore indéfinis, peuvent changer avant leur publication en tant que RFC.
Dernière mise à jour : 24 octobre 2026. Nous actualisons ce tour d’horizon chaque trimestre, et la prochaine révision est attendue lorsque le groupe de travail mlcodec de l’IETF publiera la prochaine version du projet Opus DRED et des scénarios de perte de paquets de la batterie de tests.