Das beste neuronale System zur Paketverlust-Verschleierung in Microsofts INTERSPEECH 2022 Audio Deep PLC Challenge erzielte einen PLCMOS von 4,28 auf einer Skala von 1 bis 5, gegenüber 2,90 beim bloßen Einfügen von Stille und 4,51 für das saubere Original (Microsoft, Paper zur INTERSPEECH 2022 Audio Deep PLC Challenge). Zwei Jahre später, als dieselbe Challenge auf Vollband-Audio und Verlust-Bursts von bis zu 3 Sekunden umstieg, konnten die gemeinsamen Sieger die Gesamtqualität nur von 2,37 auf 3,49 anheben, immer noch deutlich unter den 4,01, die saubere Sprache erreichte (Microsoft, Paper zur ICASSP 2024 Audio Deep PLC Challenge). Das Problem ist nicht selten: Google berichtete, dass 99% der Duo-Anrufe mit Paketverlust, Jitter oder Verzögerung umgehen mussten und jeder zehnte Anruf mehr als 8% seines Audios verlor (Google Research, WaveNetEQ-Blog 2020). Verschleierung ist die stille Schicht unter den Geschäftstrends in unseren VoIP- und UCaaS-Statistiken und ergänzt das Bild auf Betreiberseite in unseren Statistiken zur Sprachqualität im Mobilfunk (MOS). Wir haben Daten aus Challenge-Papers von Microsoft Research, von IETF und ITU-T, vom W3C, von Google Research, von den Opus-Entwicklern bei Xiph.Org, von Meta Engineering, aus der Dokumentation von Microsoft Learn und Twilio sowie aus begutachteten PLC-Studien zusammengetragen, die in der Methodik aufgeführt sind.
TL;DR
- 99% der Google-Duo-Anrufe mussten mit Paketverlust, Jitter oder Verzögerung umgehen; 10% verloren mehr als 8% des gesamten Audios (Google Research, WaveNetEQ-Blog 2020).
- Microsoft Teams stuft einen Audiostream als Poor ein, wenn der durchschnittliche Paketverlust 0,1 übersteigt, also 10% (Microsoft Learn, CQD Stream Classification 2026).
- G.711 mit der Verschleierung aus seinem Anhang I hat einen Robustheitsfaktor gegen Paketverlust von 25,1, gegenüber 4,3 ohne Verschleierung (ITU-T G.113, 09/2024).
- Sieger beim neuronalen PLC: PLCMOS 4,28 gegenüber 2,90 bei der Nullfüllung und 4,51 bei sauberer Sprache (Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge).
- Das hybride PLC des Opus-Teams belegte bei der Wortgenauigkeit den ersten Platz (0,882) und in der Gesamtwertung der Challenge 2022 den zweiten (Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022).
- Bei Bursts von bis zu 3 Sekunden schnitten 2 von 8 zulässigen Systemen bei der P.804-Gesamtqualität schlechter ab als unverarbeitetes verlustbehaftetes Audio (Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge).
- PLCMOS erreicht eine modellbezogene Pearson-Korrelation von etwa 0,97 mit menschlichen Bewertungen; bei referenzausgerichteten Daten kommt PESQ auf 0,52 (Diener et al., PLCMOS-Paper 2023).
- Die In-Band-FEC LBRR von Opus deckt 1 Frame bei etwa 2/3 der regulären Bitrate ab; DRED deckt bis zu 1 Sekunde bei etwa 1/50 ab (IETF draft-ietf-mlcodec-opus-dred-07, August 2026).
- Opus braucht laut Metas eigenem MLow-Vergleich mindestens 19 kbps, um In-Band-FEC bei 10% Paketverlust zu codieren (Meta Engineering, MLow 2024).
- Opus 1.6 verkleinerte seine DRED-Modelle etwa um den Faktor 3, auf 600 kB von 1.800 kB (Xiph.Org, Opus-1.6-Demo, Dezember 2025).
1. Wie viel Audio verloren geht und wo Plattformen die Grenze ziehen
Ein Paket ist in diesem Zusammenhang ein kleines Stück Audio (oft 20 ms), das über das Netzwerk gesendet wird. Kommt es zu spät oder gar nicht an, hat der Empfänger zwei Möglichkeiten: Stille abspielen oder die Lücke verschleiern, indem etwas synthetisiert wird, das wie die fehlende Sprache klingt. Googles eigene Daten zeigten, dass 99% der Duo-Anrufe mit Paketverlust, Jitter oder Verzögerung umgehen mussten (Google Research, Improving Audio Quality in Duo with WaveNetEQ 2020). Verschleierung ist daher kein Randfall: Sie läuft in fast jedem Anruf.
Die Plattformen sind uneins, ab wann Verlust vom Hintergrundrauschen zum Problem wird. Microsoft Teams zieht seine Poor-Grenze bei 10% durchschnittlichem Verlust, Twilio bei 5%, und Microsoft warnt ausdrücklich, dass ein Poor-Label nicht bedeutet, dass Nutzer tatsächlich ein Qualitätsproblem wahrgenommen haben, weil sein Media-Stack Verluste ausgleicht (Microsoft Learn, Stream Classification in CQD 2026). Dieser Vorbehalt ist das ganze Argument für bessere Verschleierung: Je weiter PLC trägt, desto höher kann eine Plattform ihre Alarmschwelle setzen.
| Metrik | Wert | Quelle |
|---|---|---|
| Anteil der Google-Duo-Anrufe, die mit Paketverlust, Jitter oder Verzögerung umgehen müssen | 99% | Google Research, WaveNetEQ-Blog 2020 |
| Anteil der Duo-Anrufe, die mehr als 3% ihrer gesamten Audiodauer verlieren | 20% | Google Research, WaveNetEQ-Blog 2020 |
| Anteil der Duo-Anrufe, die mehr als 8% ihrer gesamten Audiodauer verlieren | 10% | Google Research, WaveNetEQ-Blog 2020 |
| Durchschnittliche Paketverlustrate, ab der Teams einen Audiostream als Poor einstuft | Über 0,1 (10%), nur bei Streams mit mehr als 500 Paketen angewendet | Microsoft Learn, CQD Stream Classification 2026 |
| Paketverlustniveau, das Twilios Anruf-Tag high_packet_loss auslöst | Über 5% | Twilio Voice Insights, Details: Call Tags |
| Geschätzter MOS, unter dem Twilio einen Browser- oder Mobil-SDK-Anruf mit low_mos markiert | Unter 3,5 | Twilio Voice Insights, Details: Call Tags |
| Durchschnittliche Verlustrate im Testsatz der Deep PLC Challenge, mit dem Opus DRED bewertet wurde | 18,4%, mit Bursts bis zu einer Sekunde | Valin et al., DRED-Paper (arXiv 2212.04453 v3, 2024) |
Neueste verfügbare Daten: Google Research, 2020. Keine große Plattform hat eine neuere Verlustverteilung auf Anrufebene veröffentlicht. Teams meldet pro Stream die verwandte Kennzahl “Ratio Concealed Samples Avg”, wobei 0,1 bedeutet, dass 10% der Audio-Frames verschleierte Samples enthielten (Microsoft Learn, CQD dimensions and measures 2026), doch Microsoft veröffentlicht keine flottenweiten Werte. Die browserseitigen Entsprechungen, concealedSamples und concealmentEvents, sind in der WebRTC-Statistik-API des W3C definiert (Entwurf der Kandidatenempfehlung, 25. September 2025).
2. Klassische Codec-Verschleierung im ITU-T-E-Modell
Vor den neuronalen Netzen bedeutete Verschleierung, die letzte gute Grundperiode zu wiederholen oder fortzuschreiben. Das Planungsmodell der ITU-T (das E-Modell) bewertet mit dem Robustheitsfaktor gegen Paketverlust, Bpl, wie gut ein Codec Verluste übersteht: eine einfache Zahl, bei der ein höherer Wert bedeutet, dass die Qualität mit verschwindenden Paketen langsamer abnimmt. G.711 mit dem Verschleierungsalgorithmus aus seinem Anhang I hat ein Bpl von 25,1, fast das Sechsfache der 4,3 von G.711 ohne Verschleierung (ITU-T G.113 09/2024, Tabelle I.4).
Was diese Lücke in der Praxis bedeutet, wird mit Zahlen klarer. Mit Gleichung 7-29 der ITU-T G.107 (06/2015), Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl), ergibt G.711 (Ie = 0) bei 5% zufälligem Verlust (BurstR = 1) ohne Verschleierung 95 x 5 / (5 + 4,3) = 51,1 Beeinträchtigungspunkte und mit ihr 95 x 5 / (5 + 25,1) = 15,8. Vom Standardwert R = 93,2 abgezogen ergibt das R 42,1 gegenüber R 77,4, was die Formel aus Anhang B von G.107 in einen geschätzten MOS von etwa 2,2 gegenüber 3,9 umrechnet (eigene Berechnung; alle übrigen E-Modell-Eingaben auf ihrem Standardwert belassen). Allein die Verschleierung hebt einen Anruf mit 5% Verlust von schlecht auf akzeptabel.
| Metrik | Wert | Quelle |
|---|---|---|
| G.711 (64 kbit/s, 10-ms-Pakete) ohne Verschleierung: Robustheitsfaktor gegen Paketverlust Bpl bei zufälligem Verlust | 4,3 | ITU-T G.113 (09/2024), Tabelle I.4 |
| G.711 mit dem Verschleierungsalgorithmus aus Anhang I von G.711: Bpl bei zufälligem Verlust | 25,1 | ITU-T G.113 (09/2024), Tabelle I.4 |
| G.729 Anhang A mit Sprachaktivitätserkennung (8 kbit/s, 20-ms-Pakete, native Verschleierung): Ie und Bpl | Ie 11, Bpl 19,0 | ITU-T G.113 (09/2024), Tabelle I.4 |
| G.711 mit 20-ms-Paketen, 8 in einem Burst verlorene Pakete bei 2% Verlust (Burst-Verhältnis 7,84): effektive Beeinträchtigung Ie-eff | 10 | ITU-T G.113 (09/2024), Tabelle I.6 |
| G.722 mit 64 kbit/s mit der hochwertigen Verschleierung aus Anhang III von G.722: Breitband-Bpl (Hören mit beiden Ohren) | 7,1 | ITU-T G.113 (09/2024), Anhang IV |
| EVS im Superbreitband-Modus mit 24,4 kbit/s: Vollband-Bpl | 11,4 | ITU-T G.113 (09/2024), Anhang V |
| E-Modell-Bewertungsfaktor R, wenn alle Eingaben auf ihrem Standardwert stehen | 93,2 | ITU-T G.107 (06/2015) |
Kontext: Bpl-Werte sind nur innerhalb derselben Skala vergleichbar (Schmalband, Breitband oder Vollband). G.113 führt überhaupt keine Opus-Werte auf, daher muss Opus-basiertes WebRTC-Audio mit anderen Werkzeugen beurteilt werden (siehe Abschnitt 5).
3. Neuronale Verschleierung gegenüber Stille: die Deep PLC Challenge 2022
Die INTERSPEECH-2022-Challenge verglich neuronales PLC anhand realer Verlustmuster, mit aus Microsoft-Teams-Anrufen aufgezeichneten Traces und einer harten Echtzeitregel: gesamte algorithmische Latenz von höchstens 20 ms. Ihr Kernergebnis ist die Größe des Abstands zwischen dem Sieger und dem Nichtstun. Das siegreiche System erzielte auf der Vergleichsskala -0,55 (CMOS, wobei 0 vom sauberen Original nicht zu unterscheiden bedeutet), gegenüber -1,23 bei der Nullfüllung (Microsoft, Paper zur INTERSPEECH 2022 Audio Deep PLC Challenge).
Die Verständlichkeit erzählt eine bescheidenere Geschichte. Die Wortgenauigkeit, gemessen als 1 minus die Wortfehlerrate eines Spracherkenners, stieg nur von 0,86 bei Stille auf 0,88 beim Sieger, gegenüber 0,97 bei sauberer Sprache. Zuhörer empfinden die Verschleierung als große Verbesserung, doch der Erkenner verfehlte mit dem siegreichen System weiterhin 12% der Wörter, gegenüber 3% bei sauberer Sprache, ein Muster, das man neben unseren Statistiken zur Wortfehlerrate bei der Spracherkennung im Hinterkopf behalten sollte.
| Metrik | Wert | Quelle |
|---|---|---|
| Saubere Referenzsprache: PLCMOS (1 bis 5) und Wortgenauigkeit | 4,51 und 0,97 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Nullfüllungs-Baseline (Stille anstelle verlorener Pakete): PLCMOS, CMOS und Wortgenauigkeit | 2,90, -1,23 und 0,86 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Siegreiches System (Team Nr. 12, U-Net im Zeitbereich, etwa 2,36 Mio. Parameter): PLCMOS, CMOS und Wortgenauigkeit | 4,28, -0,55 und 0,88 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Am schlechtesten platziertes zulässiges System (Team Nr. 6) gegenüber der Nullfüllungs-Baseline: CMOS | -1,31 gegenüber -1,23 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Hybrides generatives und prädiktives PLC des Opus-Teams: Wortgenauigkeit und Rang in dieser Metrik | 0,882, erster Platz; zweiter bei CMOS und in der Gesamtwertung | Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| Dasselbe System: Rechenaufwand pro 10 ms Sprache auf einer Laptop-CPU (Intel i7-10810U) | 1,3 bis 1,4 ms, etwa 13% bis 14% eines Kerns | Valin et al. 2022 |
Hinweis zum Ausreißer: Ein platziertes System schnitt bei CMOS schlechter ab als die Stille-Baseline, eine Erinnerung daran, dass ein schlecht abgestimmter Generator schlechter klingen kann als eine Lücke. Der Blind-Testsatz war auf kurze Bursts ausgerichtet: 504 seiner 966 Clips hatten einen maximalen Burst von bis zu 120 ms. Die Zahlen des hybriden Systems stammen von Valin et al., deren Verschleierung später in Opus 1.5 ausgeliefert wurde (siehe Abschnitt 7).
4. Lange Bursts: Wo die Verschleierung noch scheitert (ICASSP 2024)
Die Ausgabe 2024 machte die Aufgabe bewusst schwerer: Vollband-Audio mit 48 kHz, bewertet mit der mehrdimensionalen ITU-T-Methode P.804 (Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge), und Verlust-Bursts von bis zu 3 Sekunden. Selbst das beste System schloss nur etwa zwei Drittel des Abstands zwischen verlustbehaftetem und sauberem Audio: Die Gesamtqualität stieg von 2,37 auf 3,49, gegenüber 4,01 bei sauberer Sprache ((3,49 - 2,37) / (4,01 - 2,37) = 68%) (Microsoft, Paper zur ICASSP 2024 Audio Deep PLC Challenge).
Die aufschlussreichste Spalte ist die Diskontinuität, der P.804-Wert für hörbare Brüche und Störgeräusche (höher bedeutet glatter). Sie stieg beim besten System von 2,47 auf 3,90, ein größerer Sprung als in jeder anderen Dimension. Die Verschleierung behebt zuerst die Löcher, die Zuhörer bemerken, während die synthetisierte Sprache weiterhin Natürlichkeit kostet. Auch die Wortgenauigkeit zeigt diesen Zielkonflikt: Einer der Mitsieger erkannte 0,81 der Wörter, etwas weniger als die 0,83 des unberührten verlustbehafteten Audios, ein Hinweis darauf, dass erfundene Sprache einen Erkenner stärker in die Irre führen kann als Stille.
| Metrik | Wert | Quelle |
|---|---|---|
| P.804-Gesamtqualität (1 bis 5): saubere Sprache gegenüber unverarbeitetem verlustbehaftetem Audio gegenüber den gemeinsamen Siegern (1024K und NWPU & ByteAudio) | 4,01 gegenüber 2,37 gegenüber 3,49 und 3,44 | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| P.804-Diskontinuitätswert: sauber gegenüber verlustbehaftet gegenüber bestem System (1024K) | 4,55 gegenüber 2,47 gegenüber 3,90 | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| Wortgenauigkeit: sauber gegenüber verlustbehaftet gegenüber 1024K gegenüber NWPU & ByteAudio | 0,98 gegenüber 0,83 gegenüber 0,81 gegenüber 0,84 | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| Zulässige Systeme mit schlechterem Wert als unverarbeitetes verlustbehaftetes Audio bei der P.804-Gesamtqualität | 2 von 8 (2,11 und 2,17) | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| Audiobandbreite und Hörtestmethode der Ausgabe 2024 | Vollband, 48.000 Hz; mehrdimensionale ITU-T-P.804-Bewertung plus Wortfehlerrate | Microsoft Research, Seite der ICASSP 2024 Deep PLC Challenge |
Kontext: Ein neuntes System erreichte insgesamt 2,91, verfehlte aber das Latenzlimit und wurde als nicht abgeschlossen geführt. Die Veranstalter weisen darauf hin, dass Systeme der Generation von 2022 “bei längeren Verlustfolgen möglicherweise nicht gut abschneiden”, und genau dort übernimmt die Redundanzcodierung (Abschnitt 6).
5. Verschleierung bewerten: Warum generische Qualitätsmetriken sie verfehlen
Verschleierungsfehler sind kurz, sporadisch und oft plausibel, und genau dafür wurden allgemeine Qualitätsmetriken nicht gebaut. Bei referenzausgerichteten Daten erreichte PESQ nur eine modellbezogene Pearson-Korrelation von 0,52 mit menschlichen Bewertungen von PLC-Systemen und STOI lediglich 0,21, während PLCMOS auf 0,98 kam (Diener et al., PLCMOS-Paper, Microsoft, Interspeech 2023). Eine Metrik, die Systeme falsch einordnet, kann ein ganzes Forschungsfeld in die falsche Richtung lenken.
PLCMOS funktioniert ohne saubere Referenz, was bei realen Anrufen zählt, bei denen das Originalaudio beim Empfänger nie vorliegt. Seine Schwäche ist die Präzision auf Dateiebene: 0,85 pro Clip gegenüber 0,97 pro System, sodass es Algorithmen weit besser einordnet, als es einen einzelnen Anruf beurteilt. Dieselbe Spannung zieht sich durch die Bewertung synthetischer Sprache, die wir in unseren Statistiken zum MOS der Natürlichkeit synthetischer Sprache behandeln.
| Metrik | Wert | Quelle |
|---|---|---|
| PLCMOS gegenüber menschlichen Bewertungen: modellbezogene Pearson- und Rangkorrelation | Etwa 0,97 und etwa 0,95 | Diener et al., PLCMOS-Paper 2023 |
| DNSMOS (allgemeine Metrik zur Rauschunterdrückung): dateibezogene gegenüber modellbezogener Pearson-Korrelation | 0,52 gegenüber 0,85 | Diener et al., PLCMOS-Paper 2023 |
| PESQ gegenüber PLCMOS bei referenzausgerichteten Daten: modellbezogene Pearson-Korrelation | 0,52 gegenüber 0,98 | Diener et al., PLCMOS-Paper 2023 |
| STOI (Verständlichkeitsmetrik): modellbezogene Pearson-Korrelation | 0,21 | Diener et al., PLCMOS-Paper 2023 |
| Menschliche Stimmen im wichtigsten PLCMOS-Trainingssatz (LibriSpeech Basic) | 333.740 | Diener et al., PLCMOS-Paper 2023 |
| Testdateien in der Hörtestbatterie des IETF für Codecs mit maschinellem Lernen | 100 saubere Sprache, 90 mit Rauschen oder Nachhall, 20 mit überlappenden Sprechern | IETF draft-ietf-mlcodec-test-battery-00, Juni 2026 |
Kontext: Per Crowdsourcing erhobene Bewertungen korrelierten in der Labeling-Vorstudie zu PLCMOS mit Expertenbewertungen bei etwa 0,83 PCC (95%-KI: [0,78; 0,87]). Der Entwurf der IETF-Testbatterie führt seine Paketverlust-Szenarien weiterhin als “Details TBD”, es gibt also noch keinen Standard-Verlusttest für neuronale Codecs.
6. Redundanzcodierung: Bits zahlen, um Verschleierung zu vermeiden
Verschleierung rät; Redundanz sendet ein Backup. Vorwärtsfehlerkorrektur (FEC) bedeutet, eine qualitativ schlechtere Kopie früheren Audios an spätere Pakete anzuhängen, sodass ein verlorenes Paket rekonstruiert statt erfunden werden kann. Der Preis ist Bandbreite. Die klassische In-Band-FEC von Opus (LBRR) deckt nur einen Frame bei etwa 2/3 der regulären Bitrate ab, während Deep REDundancy (DRED) bis zu eine Sekunde oder mehr bei etwa 1/50 der regulären Bitrate trägt (IETF draft-ietf-mlcodec-opus-dred-07, August 2026).
Der ältere RED-Ansatz zeigt das Ausmaß des Effekts. In einem Chrome-Test bei 20% Verlust senkte das Mitsenden eines vorherigen Frames in jedem Paket den verschleierten Audioanteil von 18% auf 4%, und zwei vorherige Frames senkten ihn auf 0,7% (webrtcHacks, RED: Improving Audio Quality with Redundancy 2020). Der Preis: Das Audio stieg von etwa 30 kbps auf 60 kbps mit einer Kopie und auf 90 kbps mit zwei. DRED existiert, um ähnlichen Schutz zu erreichen, ohne die Bitrate zu verdoppeln.
| Metrik | Wert | Quelle |
|---|---|---|
| Opus-In-Band-FEC LBRR: Redundanztiefe und Bitratenkosten | 1 Frame; etwa 2/3 der regulären Opus-Bitrate | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Opus DRED: Redundanztiefe und Bitratenkosten | Bis zu eine Sekunde oder mehr pro Paket; etwa 1/50 der regulären Bitrate | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| DRED-Evaluierung: pro Paket mitgeführte Redundanz und Anzahl, wie oft jeder Frame gesendet wird | 1,04 Sekunden; 52 Kopien | Valin et al., DRED-Paper (arXiv 2212.04453 v3, 2024) |
| Bitrate der LBRR-Testbedingung in der DRED-Evaluierung (24 kb/s Basis plus LBRR) | 40 kb/s insgesamt, LBRR im Mittel etwa 16 kb/s | Valin et al., DRED-Paper 2024 |
| Verschleierter Audioanteil bei 20% Verlust in Chrome: ohne RED gegenüber einem vorherigen Frame gegenüber zwei vorherigen Frames | 18% gegenüber 4% gegenüber 0,7% | webrtcHacks, RED-Test von Hancke 2020 |
| Verschleierter Audioanteil bei 60% zufälligem Verlust: ohne RED gegenüber einem gegenüber zwei vorherigen Frames | 60% gegenüber 32% gegenüber 18% | webrtcHacks, RED-Test von Hancke 2020 |
| Minimale Opus-Bitrate zum Codieren von In-Band-FEC bei 10% Paketverlust | 19 kbps (Vergleich des Anbieters selbst) | Meta Engineering, MLow-Codec-Blog 2024 |
| Bitrate von Metas MLow-Samples bei 30% empfängerseitigem Paketverlust | 14 kbps (Behauptung des Anbieters selbst) | Meta Engineering, MLow-Codec-Blog 2024 |
Kontext: Die webrtcHacks-Zahlen stammen aus einem Labortest eines einzelnen Autors von 2020 (die neueste verfügbare öffentliche Messung von RED in Chrome). Die Zahlen von Meta stammen aus der eigenen MLow-Ankündigung und wurden nicht unabhängig repliziert. Alle DRED-Unterschiede im P.808-Hörtest des Papers (966 Äußerungen, je 10 Hörer) wurden als signifikant bei p < 0,05 berichtet.
7. Verschleierung in Produktion bringen: Rechenaufwand, Platzbedarf und Standards
Ein Verschleierungsmodell zählt nur, wenn es auf das billigste Telefon im Anruf passt. Das Deep PLC von Opus 1.5 kostet bei hohen Verlustraten etwa 1% eines Laptop-CPU-Kerns und fügt der Bibliothek etwa 1 MB hinzu (Xiph.Org, Opus-1.5-Demo, März 2024, eigene Zahlen der Entwickler). Der Challenge-Beitrag desselben Teams von 2022 benötigte 13% bis 14% eines Kerns (Abschnitt 3), wobei die beiden Zahlen unterschiedlich gemessen wurden und kein strenger Vergleich unter gleichen Bedingungen sind.
Die Standardisierungsebene hingegen bewegt sich kaum. Die Audioregeln von WebRTC (RFC 7874, 2016) schreiben Opus und G.711 vor, stellen aber keine Anforderung an Verschleierung oder FEC und überlassen die Qualität unter Verlust vollständig der jeweiligen Implementierung. Opus 1.6 verkleinerte die Modelle weiter: Seine DRED-Netze sind etwa dreimal kleiner als in 1.5 (Xiph.Org, Opus-1.6-Demo, Dezember 2025).
| Metrik | Wert | Quelle |
|---|---|---|
| Opus-1.5-Deep-PLC: zusätzliche Bibliotheksgröße und CPU-Kosten | Etwa 1 MB; etwa 1% eines Laptop-Kerns bei hohem Verlust; benötigt Decoder-Komplexität 5 oder höher | Xiph.Org, Opus-1.5-Demo 2024 (eigene Zahlen der Entwickler) |
| Opus-1.5-DRED: zusätzliche Bibliotheksgröße, Laufzeitkosten und Bitraten-Overhead | Etwa 2 MB; etwa 1%; etwa 12 bis 32 kb/s | Xiph.Org, Opus-1.5-Demo 2024 (eigene Zahlen der Entwickler) |
| Neuronaler Vocoder FARGAN zur Synthese verschleierter und redundanter Sprache: Komplexität | 600 MFLOPS, 1/5 von LPCNet | Xiph.Org, Opus-1.5-Demo 2024 |
| Verlustraten in den Opus-1.5-WebRTC-Tests (PLCMOS v2) | 0% bis 90% in 10%-Schritten; DRED soll die Qualität bei 90% Verlust halten | Xiph.Org, Opus-1.5-Demo 2024 (eigene Behauptung der Entwickler) |
| Größe des Opus-1.6-DRED-Modells gegenüber Opus 1.5 | 600 kB gegenüber 1.800 kB | Xiph.Org, Opus-1.6-Demo, Dezember 2025 |
| Opus-Framegrößen, Paketlänge und Bitratenbereich | Frames von 2,5 bis 60 ms; Pakete bis 120 ms; 6 bis 510 kbit/s | IETF RFC 6716 (2012) |
| Algorithmische Verzögerung von Opus | 5 ms bis 65,2 ms | IETF RFC 6716 (2012) |
| Codecs, die WebRTC-Endpunkte unterstützen müssen | Opus und G.711 (PCMA und PCMU); keine PLC- oder FEC-Anforderung | IETF RFC 7874 (2016) |
Kontext: RFC 6716 und RFC 7874 sind älter als drei Jahre, bleiben aber die aktuellen Standards (RFC 6716, RFC 7874). Der DRED-Entwurf würde bei Annahme RFC 6716 um eine neuronale Redundanzschicht aktualisieren.
Zusammenfassung: WebRTC-Audio-Paketverlust-Verschleierung in Zahlen
| Metrik | Wert | Quelle |
|---|---|---|
| Google-Duo-Anrufe, die mit Paketverlust, Jitter oder Verzögerung umgehen müssen | 99% | Google Research, WaveNetEQ-Blog 2020 |
| Duo-Anrufe, die mehr als 8% ihres Audios verlieren | 10% | Google Research, WaveNetEQ-Blog 2020 |
| Teams-Poor-Schwelle für den durchschnittlichen Audio-Paketverlust | Über 0,1 (10%) | Microsoft Learn, CQD Stream Classification 2026 |
| Schwelle für das Twilio-Tag high_packet_loss | Über 5% | Twilio Voice Insights, Details: Call Tags |
| G.711-Robustheitsfaktor Bpl: ohne Verschleierung gegenüber Verschleierung aus Anhang I | 4,3 gegenüber 25,1 | ITU-T G.113 (09/2024) |
| G.729 Anhang A mit Sprachaktivitätserkennung: Bpl | 19,0 | ITU-T G.113 (09/2024) |
| PLCMOS der Challenge 2022: Nullfüllung gegenüber Sieger gegenüber sauber | 2,90 gegenüber 4,28 gegenüber 4,51 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Wortgenauigkeit der Challenge 2022: Nullfüllung gegenüber Sieger gegenüber sauber | 0,86 gegenüber 0,88 gegenüber 0,97 | Microsoft, Paper zur INTERSPEECH 2022 Deep PLC Challenge |
| Rechenaufwand des hybriden PLC des Opus-Teams pro 10 ms Sprache | 1,3 bis 1,4 ms (13% bis 14% eines Kerns) | Valin et al. 2022 |
| P.804-Gesamtqualität der Challenge 2024: verlustbehaftet gegenüber bestes System gegenüber sauber | 2,37 gegenüber 3,49 gegenüber 4,01 | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| Systeme der Challenge 2024 mit schlechterem Wert als unverarbeitetes verlustbehaftetes Audio | 2 von 8 | Microsoft, Paper zur ICASSP 2024 Deep PLC Challenge |
| Modellbezogene Pearson-Korrelation von PLCMOS mit menschlichen Bewertungen | Etwa 0,97 | Diener et al., PLCMOS-Paper 2023 |
| Modellbezogene Pearson-Korrelation von PESQ gegenüber STOI bei PLC-Systemen | 0,52 gegenüber 0,21 | Diener et al., PLCMOS-Paper 2023 |
| Redundanztiefe von LBRR gegenüber DRED | 1 Frame gegenüber bis zu einer Sekunde oder mehr | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Redundanz-Bitrate von DRED im Verhältnis zu regulärem Opus | Etwa 1/50 | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Verschleierter Audioanteil bei 20% Verlust: ohne RED gegenüber RED mit zwei Frames | 18% gegenüber 0,7% | webrtcHacks, RED-Test von Hancke 2020 |
| Minimale Opus-In-Band-FEC-Bitrate bei 10% Verlust | 19 kbps (Vergleich des Anbieters selbst) | Meta Engineering, MLow-Codec-Blog 2024 |
| CPU-Kosten des Opus-1.5-Deep-PLC | Etwa 1% eines Laptop-Kerns | Xiph.Org, Opus-1.5-Demo 2024 |
| Größe des Opus-1.6-DRED-Modells gegenüber 1.5 | 600 kB gegenüber 1.800 kB | Xiph.Org, Opus-1.6-Demo 2025 |
Methodik und Quellen
- Microsoft Research, Paper zur INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge (Diener et al., 2022): arxiv.org/pdf/2204.05222
- Microsoft Research, Paper zur ICASSP 2024 Audio Deep Packet Loss Concealment Challenge (2024): arxiv.org/html/2402.16927v1
- Microsoft Research, Programmseite der 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 (August 2026): ietf.org
- IETF, ML codec listening test battery, draft-ietf-mlcodec-test-battery-00 (Juni 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 (Entwurf der Kandidatenempfehlung, 25. September 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 (April 2020): research.google
- Microsoft Learn, Stream Classification in Call Quality Dashboard (aktualisiert im Juni 2026): learn.microsoft.com
- Microsoft Learn, Dimensions and measures available in Call Quality Dashboard (aktualisiert im Juli 2026): learn.microsoft.com
- Twilio, Voice Insights Details: Call Tags: twilio.com
- Meta Engineering, MLow: Meta’s low bitrate audio codec (Juni 2024): engineering.fb.com
- Xiph.Org, Opus-1.5-Demo (März 2024) und Opus-1.6-Demo (Dezember 2025): opus-codec.org/demo/opus-1.5, opus-codec.org/demo/opus-1.6
- webrtcHacks, RED: Improving Audio Quality with Redundancy (Philipp Hancke, August 2020): webrtchacks.com
- Daten-Hinweis: Die einzige Verlustverteilung auf Anrufebene einer großen Plattform ist Googles Duo-Zahl von 2020, und die RED-Verschleierungsmessungen sind ein Test eines einzelnen Autors von 2020, daher werden beide als neueste verfügbare Daten gekennzeichnet. Das E-Modell-Beispiel in Abschnitt 2 ist unsere eigene Berechnung nach Gleichung 7-29 und Anhang B von ITU-T G.107 mit den Bpl-Werten aus G.113, wobei alle übrigen Eingaben auf ihrem Standardwert gehalten wurden; es ist eine Schätzung, keine Messung. Die Challenge-Werte sind zwischen den Ausgaben nicht vergleichbar: 2022 wurden Breitband-Audio, PLCMOS und CMOS mit Bursts bis zu 1 Sekunde verwendet, 2024 dagegen Vollband-Audio, P.804 und Bursts bis zu 3 Sekunden. Im Paper von 2022 korrelierte PLCMOS mit CMOS bei etwa 0,95 Pearson, während die spätere PLCMOS-Version etwa 0,97 auf einem anderen Evaluierungssatz berichtet. Die Zahlen von Xiph.Org und Meta sind Behauptungen der Entwickler selbst. Die Schwellenwerte von Teams (10%) und Twilio (5%) widersprechen sich konstruktionsbedingt, weil jeder Anbieter sie auf seinen eigenen Media-Stack abstimmt. Der DRED-Entwurf (läuft im Februar 2027 ab) und der Entwurf der IETF-Testbatterie, deren Paketverlust-Szenarien noch undefiniert sind, können sich ändern, bevor sie als RFCs veröffentlicht werden.
Zuletzt aktualisiert: 24. Oktober 2026. Wir aktualisieren diese Zusammenstellung vierteljährlich, und die nächste Aktualisierung wird erwartet, wenn die IETF-Arbeitsgruppe mlcodec die nächste Revision des Opus-DRED-Entwurfs und der Paketverlust-Szenarien der Testbatterie veröffentlicht.