El mejor sistema neuronal de ocultación de pérdida de paquetes en el Audio Deep PLC Challenge de INTERSPEECH 2022, de Microsoft, obtuvo un PLCMOS de 4,28 en una escala de 1 a 5, frente a 2,90 por simplemente insertar silencio y 4,51 por el original limpio (Microsoft, artículo del INTERSPEECH 2022 Audio Deep PLC Challenge). Dos años después, cuando el mismo desafío pasó a audio de banda completa y ráfagas de pérdida de hasta 3 segundos, los ganadores compartidos solo lograron subir la calidad global de 2,37 a 3,49, todavía muy por debajo de los 4,01 que obtuvo la voz limpia (Microsoft, artículo del ICASSP 2024 Audio Deep PLC Challenge). El problema no es raro: Google informó que el 99% de las llamadas de Duo tenían que lidiar con pérdida de paquetes, jitter o retardo, y que una de cada diez llamadas perdía más del 8% de su audio (Google Research, blog de WaveNetEQ 2020). La ocultación es la capa silenciosa que sostiene las tendencias de negocio de nuestras estadísticas de VoIP y UCaaS y complementa el panorama del lado de los operadores en nuestras estadísticas de calidad de voz celular (MOS). Reunimos datos de artículos de los desafíos de Microsoft Research, del IETF y la ITU-T, del W3C, de Google Research, de los desarrolladores de Opus en Xiph.Org, de Meta Engineering, de la documentación de Microsoft Learn y Twilio, y de estudios sobre PLC revisados por pares que figuran en la metodología.
TL;DR
- El 99% de las llamadas de Google Duo tenían que manejar pérdida de paquetes, jitter o retardo; el 10% perdía más del 8% del audio total (Google Research, blog de WaveNetEQ 2020).
- Microsoft Teams marca un flujo de audio como Poor cuando la pérdida media de paquetes supera 0,1, es decir, el 10% (Microsoft Learn, CQD Stream Classification 2026).
- G.711 con la ocultación de su Apéndice I tiene un factor de robustez ante la pérdida de paquetes de 25,1, frente a 4,3 sin ocultación (ITU-T G.113, 09/2024).
- Ganador del PLC neuronal: PLCMOS 4,28 frente a 2,90 del relleno con ceros y 4,51 de la voz limpia (Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge).
- El PLC híbrido del equipo de Opus quedó primero en precisión de palabras (0,882) y segundo en la clasificación global del desafío de 2022 (Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022).
- Con ráfagas de hasta 3 segundos, 2 de 8 sistemas elegibles puntuaron por debajo del audio con pérdidas sin procesar en calidad global P.804 (Microsoft, artículo del ICASSP 2024 Deep PLC Challenge).
- PLCMOS alcanza una correlación de Pearson por modelo de alrededor de 0,97 con las valoraciones humanas; en datos alineados con la referencia, PESQ llega a 0,52 (Diener et al., artículo de PLCMOS 2023).
- El FEC en banda LBRR de Opus cubre 1 trama a cerca de 2/3 de la tasa de bits regular; DRED cubre hasta 1 segundo a cerca de 1/50 (IETF draft-ietf-mlcodec-opus-dred-07, agosto de 2026).
- Opus necesita al menos 19 kbps para codificar FEC en banda con un 10% de pérdida de paquetes, según la propia comparación de Meta con MLow (Meta Engineering, MLow 2024).
- Opus 1.6 redujo sus modelos DRED unas 3 veces, a 600 kB desde 1.800 kB (Xiph.Org, demostración de Opus 1.6, diciembre de 2025).
1. Cuánto Audio Se Pierde y Dónde Trazan la Línea las Plataformas
Un paquete, en este contexto, es una pequeña porción de audio (a menudo de 20 ms) enviada por la red. Cuando llega demasiado tarde o no llega, el receptor tiene dos opciones: reproducir silencio u ocultar el vacío sintetizando algo que suene como la voz faltante. Los datos del propio Google mostraron que el 99% de las llamadas de Duo tenían que lidiar con pérdida de paquetes, jitter o retardo (Google Research, Improving Audio Quality in Duo with WaveNetEQ 2020). Por lo tanto, la ocultación no es un caso límite: se ejecuta en casi todas las llamadas.
Las plataformas discrepan sobre el punto en que la pérdida deja de ser ruido de fondo y se vuelve un problema. Microsoft Teams fija su línea Poor en una pérdida media del 10%, Twilio en el 5%, y Microsoft advierte expresamente que una etiqueta Poor no significa que los usuarios percibieran realmente un problema de calidad, porque su pila de medios corrige la pérdida (Microsoft Learn, Stream Classification in CQD 2026). Esa salvedad es todo el argumento a favor de una mejor ocultación: cuanto más rinde el PLC, más alto puede fijar una plataforma su umbral de alarma.
| Métrica | Valor | Fuente |
|---|---|---|
| Proporción de llamadas de Google Duo que deben lidiar con pérdida de paquetes, jitter o retardo | 99% | Google Research, blog de WaveNetEQ 2020 |
| Proporción de llamadas de Duo que pierden más del 3% de la duración total del audio | 20% | Google Research, blog de WaveNetEQ 2020 |
| Proporción de llamadas de Duo que pierden más del 8% de la duración total del audio | 10% | Google Research, blog de WaveNetEQ 2020 |
| Tasa media de pérdida de paquetes por encima de la cual Teams clasifica un flujo de audio como Poor | Por encima de 0,1 (10%), aplicada solo a flujos de más de 500 paquetes | Microsoft Learn, CQD Stream Classification 2026 |
| Nivel de pérdida de paquetes que activa la etiqueta de llamada high_packet_loss de Twilio | Por encima del 5% | Twilio Voice Insights, Details: Call Tags |
| MOS estimado por debajo del cual Twilio etiqueta como low_mos una llamada de navegador o SDK móvil | Por debajo de 3,5 | Twilio Voice Insights, Details: Call Tags |
| Tasa media de pérdida en el conjunto de prueba del Deep PLC Challenge usado para evaluar Opus DRED | 18,4%, con ráfagas de hasta un segundo | Valin et al., artículo de DRED (arXiv 2212.04453 v3, 2024) |
Datos disponibles más recientes: Google Research, 2020. Ninguna gran plataforma ha publicado una distribución de pérdidas por llamada más nueva. Teams informa por flujo el indicador relacionado “Ratio Concealed Samples Avg”, donde 0,1 significa que el 10% de las tramas de audio contenían muestras ocultadas (Microsoft Learn, CQD dimensions and measures 2026), pero Microsoft no publica valores de toda su flota. Los equivalentes del lado del navegador, concealedSamples y concealmentEvents, están definidos en la API de estadísticas de WebRTC del W3C (borrador de Recomendación Candidata, 25 de septiembre de 2025).
2. Ocultación Clásica de Códecs bajo el Modelo E de la ITU-T
Antes de las redes neuronales, ocultar significaba repetir o extrapolar el último periodo de tono bueno. El modelo de planificación de la ITU-T (el modelo E) puntúa qué tan bien sobrevive un códec a la pérdida mediante el factor de robustez ante la pérdida de paquetes, Bpl: un número simple en el que un valor mayor indica que la calidad decae más despacio a medida que desaparecen paquetes. G.711 con el algoritmo de ocultación de su Apéndice I tiene un Bpl de 25,1, casi seis veces los 4,3 de G.711 sin ocultación (ITU-T G.113 09/2024, Tabla I.4).
Lo que esa diferencia significa en la práctica queda más claro con números. Usando la Ecuación 7-29 de la ITU-T G.107 (06/2015), Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl), G.711 (Ie = 0) con un 5% de pérdida aleatoria (BurstR = 1) da 95 x 5 / (5 + 4,3) = 51,1 puntos de degradación sin ocultación, y 95 x 5 / (5 + 25,1) = 15,8 con ella. Restados de la calificación predeterminada de R = 93,2, eso es R 42,1 frente a R 77,4, que la fórmula del Anexo B de G.107 convierte en un MOS estimado de alrededor de 2,2 frente a 3,9 (cálculo propio; todas las demás entradas del modelo E se dejaron en su valor predeterminado). Solo con la ocultación, una llamada con un 5% de pérdida pasa de mala a aceptable.
| Métrica | Valor | Fuente |
|---|---|---|
| G.711 (64 kbit/s, paquetes de 10 ms) sin ocultación: factor de robustez ante la pérdida de paquetes Bpl con pérdida aleatoria | 4,3 | ITU-T G.113 (09/2024), Tabla I.4 |
| G.711 con el algoritmo de ocultación del Apéndice I de G.711: Bpl con pérdida aleatoria | 25,1 | ITU-T G.113 (09/2024), Tabla I.4 |
| G.729 Anexo A con detección de actividad de voz (8 kbit/s, paquetes de 20 ms, ocultación nativa): Ie y Bpl | Ie 11, Bpl 19,0 | ITU-T G.113 (09/2024), Tabla I.4 |
| G.711 con paquetes de 20 ms, 8 paquetes perdidos en una sola ráfaga con un 2% de pérdida (razón de ráfaga 7,84): degradación efectiva Ie-eff | 10 | ITU-T G.113 (09/2024), Tabla I.6 |
| G.722 a 64 kbit/s con la ocultación de alta calidad del Apéndice III de G.722: Bpl en banda ancha (escuchando con ambos oídos) | 7,1 | ITU-T G.113 (09/2024), Apéndice IV |
| EVS en modo de banda superancha a 24,4 kbit/s: Bpl en banda completa | 11,4 | ITU-T G.113 (09/2024), Apéndice V |
| Factor de calificación R del modelo E cuando todas las entradas están en su valor predeterminado | 93,2 | ITU-T G.107 (06/2015) |
Contexto: los valores de Bpl solo son comparables dentro de la misma escala (banda estrecha, banda ancha o banda completa). G.113 no incluye ningún valor de Opus, por lo que el audio WebRTC basado en Opus debe juzgarse con otras herramientas (véase la sección 5).
3. Ocultación Neuronal frente a Silencio: el Deep PLC Challenge de 2022
El desafío de INTERSPEECH 2022 evaluó el PLC neuronal con patrones de pérdida reales, usando trazas grabadas de llamadas de Microsoft Teams y una regla estricta de tiempo real: latencia algorítmica total de 20 ms como máximo. Su resultado principal es el tamaño de la brecha entre el ganador y no hacer nada. El sistema ganador obtuvo -0,55 en la escala de comparación (CMOS, donde 0 significa indistinguible del original limpio), frente a -1,23 del relleno con ceros (Microsoft, artículo del INTERSPEECH 2022 Audio Deep PLC Challenge).
La inteligibilidad cuenta una historia más modesta. La precisión de palabras, medida como 1 menos la tasa de error de palabras de un reconocedor de voz, subió solo de 0,86 con silencio a 0,88 con el ganador, frente a 0,97 de la voz limpia. Los oyentes perciben la ocultación como una gran mejora, pero el reconocedor seguía fallando el 12% de las palabras con el sistema ganador, frente al 3% con voz limpia, un patrón que conviene tener presente junto a nuestras estadísticas de tasa de error de palabras en el reconocimiento de voz.
| Métrica | Valor | Fuente |
|---|---|---|
| Voz limpia de referencia: PLCMOS (1 a 5) y precisión de palabras | 4,51 y 0,97 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| Línea base de relleno con ceros (silencio en lugar de los paquetes perdidos): PLCMOS, CMOS y precisión de palabras | 2,90, -1,23 y 0,86 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| Sistema ganador (equipo n.º 12, U-Net en el dominio del tiempo, unos 2,36 M de parámetros): PLCMOS, CMOS y precisión de palabras | 4,28, -0,55 y 0,88 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| Sistema elegible peor clasificado (equipo n.º 6) frente a la línea base de relleno con ceros: CMOS | -1,31 frente a -1,23 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| PLC híbrido generativo y predictivo del equipo de Opus: precisión de palabras y posición en esa métrica | 0,882, primero; segundo en CMOS y en la clasificación global | Valin et al., Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| Mismo sistema: cómputo por cada 10 ms de voz en una CPU de portátil (Intel i7-10810U) | 1,3 a 1,4 ms, alrededor del 13% al 14% de un núcleo | Valin et al. 2022 |
Nota sobre el valor atípico: un sistema clasificado puntuó por debajo de la línea base de silencio en CMOS, un recordatorio de que un generador mal ajustado puede sonar peor que un vacío. El conjunto ciego estaba cargado hacia ráfagas cortas: 504 de sus 966 clips tenían una ráfaga máxima de hasta 120 ms. Las cifras del sistema híbrido provienen de Valin et al., cuya ocultación se incorporó después a Opus 1.5 (véase la sección 7).
4. Ráfagas Largas: Donde la Ocultación Aún Falla (ICASSP 2024)
La edición de 2024 hizo la tarea deliberadamente más difícil: audio de banda completa a 48 kHz, valorado con el método multidimensional ITU-T P.804 (Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge), y ráfagas de pérdida de hasta 3 segundos. Incluso el mejor sistema cerró solo cerca de dos tercios de la distancia entre el audio con pérdidas y el audio limpio: la calidad global subió de 2,37 a 3,49, frente a 4,01 de la voz limpia ((3,49 - 2,37) / (4,01 - 2,37) = 68%) (Microsoft, artículo del ICASSP 2024 Audio Deep PLC Challenge).
La columna más reveladora es la de discontinuidad, la puntuación de P.804 para cortes y fallos audibles (más alto significa más fluido). Subió de 2,47 a 3,90 en el mejor sistema, un salto mayor que el de cualquier otra dimensión. La ocultación arregla primero los huecos que los oyentes notan, mientras que la voz sintetizada sigue costando naturalidad. La precisión de palabras muestra el mismo equilibrio: uno de los coganadores reconoció 0,81 de las palabras, algo por debajo de los 0,83 del audio con pérdidas sin tocar, una señal de que la voz inventada puede confundir a un reconocedor más que el silencio.
| Métrica | Valor | Fuente |
|---|---|---|
| Calidad global P.804 (1 a 5): voz limpia frente a audio con pérdidas sin procesar frente a los ganadores compartidos (1024K y NWPU & ByteAudio) | 4,01 frente a 2,37 frente a 3,49 y 3,44 | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Puntuación de discontinuidad P.804: limpio frente a con pérdidas frente al mejor sistema (1024K) | 4,55 frente a 2,47 frente a 3,90 | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Precisión de palabras: limpio frente a con pérdidas frente a 1024K frente a NWPU & ByteAudio | 0,98 frente a 0,83 frente a 0,81 frente a 0,84 | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Sistemas elegibles con puntuación por debajo del audio con pérdidas sin procesar en calidad global P.804 | 2 de 8 (2,11 y 2,17) | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Ancho de banda del audio y método de la prueba de escucha de la edición de 2024 | Banda completa, 48.000 Hz; valoración multidimensional ITU-T P.804 más tasa de error de palabras | Microsoft Research, página del ICASSP 2024 Deep PLC Challenge |
Contexto: un noveno sistema obtuvo 2,91 en la puntuación global, pero no cumplió el límite de latencia y quedó listado como no finalizado. Los organizadores señalan que los sistemas de la era de 2022 “podrían no rendir bien con secuencias de pérdida más largas”, que es exactamente donde toma el relevo la codificación de redundancia (sección 6).
5. Puntuar la Ocultación: Por Qué las Métricas Genéricas de Calidad No la Captan
Los errores de ocultación son breves, intermitentes y a menudo verosímiles, que es precisamente lo que las métricas de calidad de uso general no fueron diseñadas para detectar. En datos alineados con la referencia, PESQ alcanzó una correlación de Pearson por modelo de solo 0,52 con las valoraciones humanas de sistemas de PLC, y STOI apenas 0,21, mientras que PLCMOS alcanzó 0,98 (Diener et al., artículo de PLCMOS, Microsoft, Interspeech 2023). Una métrica que ordena mal los sistemas puede llevar a todo un campo de investigación en la dirección equivocada.
PLCMOS funciona sin una referencia limpia, lo que importa en llamadas reales, donde el audio original nunca está disponible en el receptor. Su debilidad es la precisión por archivo: 0,85 por clip frente a 0,97 por sistema, de modo que ordena algoritmos mucho mejor de lo que juzga una sola llamada. La misma tensión atraviesa la puntuación de la voz sintética, tratada en nuestras estadísticas de MOS de naturalidad de la voz sintética.
| Métrica | Valor | Fuente |
|---|---|---|
| PLCMOS frente a valoraciones humanas: correlación de Pearson por modelo y correlación de rangos | Alrededor de 0,97 y alrededor de 0,95 | Diener et al., artículo de PLCMOS 2023 |
| DNSMOS (métrica general de supresión de ruido): correlación de Pearson por archivo frente a por modelo | 0,52 frente a 0,85 | Diener et al., artículo de PLCMOS 2023 |
| PESQ frente a PLCMOS en datos alineados con la referencia: correlación de Pearson por modelo | 0,52 frente a 0,98 | Diener et al., artículo de PLCMOS 2023 |
| STOI (métrica de inteligibilidad): correlación de Pearson por modelo | 0,21 | Diener et al., artículo de PLCMOS 2023 |
| Votos humanos en el principal conjunto de entrenamiento de PLCMOS (LibriSpeech Basic) | 333.740 | Diener et al., artículo de PLCMOS 2023 |
| Archivos de prueba en la batería de pruebas de escucha de códecs de aprendizaje automático del IETF | 100 de voz limpia, 90 con ruido o reverberación, 20 con voces superpuestas | IETF draft-ietf-mlcodec-test-battery-00, junio de 2026 |
Contexto: las valoraciones colaborativas se correlacionaron con las de expertos en alrededor de 0,83 de PCC (IC del 95%: [0,78; 0,87]) en el estudio previo de etiquetado de PLCMOS. El borrador de la batería de pruebas del IETF todavía enumera sus escenarios de pérdida de paquetes como “Details TBD”, así que aún no existe una prueba de pérdida estándar para códecs neuronales.
6. Codificación de Redundancia: Pagar Bits para Evitar la Ocultación
La ocultación adivina; la redundancia envía un respaldo. La corrección de errores hacia adelante (FEC) consiste en adjuntar una copia de menor calidad del audio anterior a los paquetes posteriores, de modo que un paquete perdido pueda reconstruirse en lugar de inventarse. El precio es el ancho de banda. El FEC en banda clásico de Opus (LBRR) cubre solo una trama a cerca de 2/3 de la tasa de bits regular, mientras que Deep REDundancy (DRED) transporta hasta un segundo o más a cerca de 1/50 de la tasa de bits regular (IETF draft-ietf-mlcodec-opus-dred-07, agosto de 2026).
El enfoque RED, más antiguo, muestra la magnitud del efecto. En una prueba en Chrome con un 20% de pérdida, enviar una trama anterior en cada paquete redujo la proporción de audio ocultado del 18% al 4%, y dos tramas anteriores la redujeron al 0,7% (webrtcHacks, RED: Improving Audio Quality with Redundancy 2020). El costo: el audio pasó de unos 30 kbps a 60 kbps con una copia y a 90 kbps con dos. DRED existe para lograr una protección similar sin duplicar la tasa de bits.
| Métrica | Valor | Fuente |
|---|---|---|
| FEC en banda LBRR de Opus: profundidad de la redundancia y costo en tasa de bits | 1 trama; cerca de 2/3 de la tasa de bits regular de Opus | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Opus DRED: profundidad de la redundancia y costo en tasa de bits | Hasta un segundo o más por paquete; cerca de 1/50 de la tasa de bits regular | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Evaluación de DRED: redundancia transportada por paquete y número de veces que se envía cada trama | 1,04 segundos; 52 copias | Valin et al., artículo de DRED (arXiv 2212.04453 v3, 2024) |
| Tasa de bits de la condición de prueba LBRR en la evaluación de DRED (24 kb/s de base más LBRR) | 40 kb/s en total, con LBRR en promedio de unos 16 kb/s | Valin et al., artículo de DRED 2024 |
| Proporción de audio ocultado con un 20% de pérdida en Chrome: sin RED frente a una trama anterior frente a dos tramas anteriores | 18% frente a 4% frente a 0,7% | webrtcHacks, prueba de RED de Hancke 2020 |
| Proporción de audio ocultado con un 60% de pérdida aleatoria: sin RED frente a una frente a dos tramas anteriores | 60% frente a 32% frente a 18% | webrtcHacks, prueba de RED de Hancke 2020 |
| Tasa de bits mínima de Opus para codificar FEC en banda con un 10% de pérdida de paquetes | 19 kbps (comparación del propio proveedor) | Meta Engineering, blog del códec MLow 2024 |
| Tasa de bits de las muestras MLow de Meta con un 30% de pérdida de paquetes en el receptor | 14 kbps (afirmación del propio proveedor) | Meta Engineering, blog del códec MLow 2024 |
Contexto: las cifras de webrtcHacks provienen de una prueba de laboratorio de un solo autor de 2020 (la medición pública más reciente disponible de RED en Chrome). Las cifras de Meta proceden de su propio anuncio de MLow y no se han replicado de forma independiente. Todas las diferencias de DRED en la prueba de escucha P.808 del artículo (966 locuciones, 10 oyentes cada una) se informaron como significativas con p < 0,05.
7. Llevar la Ocultación a Producción: Cómputo, Tamaño y Estándares
Un modelo de ocultación solo importa si cabe en el teléfono más barato de la llamada. El Deep PLC de Opus 1.5 cuesta alrededor del 1% de un núcleo de CPU de portátil con tasas de pérdida altas y añade cerca de 1 MB a la biblioteca (Xiph.Org, demostración de Opus 1.5, marzo de 2024, cifras de los propios desarrolladores). La propuesta del equipo para el desafío de 2022 necesitaba del 13% al 14% de un núcleo (sección 3), aunque las dos cifras se midieron de forma distinta y no son una comparación estricta en igualdad de condiciones.
La capa de estándares, en cambio, apenas se mueve. Las reglas de audio de WebRTC (RFC 7874, 2016) exigen Opus y G.711, pero no fijan ningún requisito de ocultación ni de FEC, y dejan la calidad bajo pérdida enteramente en manos de cada implementación. Opus 1.6 siguió reduciendo los modelos: sus redes DRED son unas 3 veces más pequeñas que en 1.5 (Xiph.Org, demostración de Opus 1.6, diciembre de 2025).
| Métrica | Valor | Fuente |
|---|---|---|
| Deep PLC de Opus 1.5: tamaño añadido a la biblioteca y costo de CPU | Cerca de 1 MB; alrededor del 1% de un núcleo de portátil con pérdida alta; requiere complejidad del decodificador 5 o superior | Xiph.Org, demostración de Opus 1.5 2024 (cifras de los propios desarrolladores) |
| DRED de Opus 1.5: tamaño añadido a la biblioteca, costo en tiempo de ejecución y sobrecarga de tasa de bits | Cerca de 2 MB; alrededor del 1%; unos 12 a 32 kb/s | Xiph.Org, demostración de Opus 1.5 2024 (cifras de los propios desarrolladores) |
| Vocoder neuronal FARGAN usado para sintetizar la voz ocultada y redundante: complejidad | 600 MFLOPS, 1/5 de LPCNet | Xiph.Org, demostración de Opus 1.5 2024 |
| Tasas de pérdida en las pruebas WebRTC de Opus 1.5 (PLCMOS v2) | 0% a 90% en pasos del 10%; se informa que DRED mantiene la calidad con un 90% de pérdida | Xiph.Org, demostración de Opus 1.5 2024 (afirmación de los propios desarrolladores) |
| Tamaño del modelo DRED de Opus 1.6 frente al de Opus 1.5 | 600 kB frente a 1.800 kB | Xiph.Org, demostración de Opus 1.6, diciembre de 2025 |
| Tamaños de trama, duración de paquete e intervalo de tasa de bits de Opus | Tramas de 2,5 a 60 ms; paquetes de hasta 120 ms; 6 a 510 kbit/s | IETF RFC 6716 (2012) |
| Retardo algorítmico de Opus | 5 ms a 65,2 ms | IETF RFC 6716 (2012) |
| Códecs que deben soportar los endpoints WebRTC | Opus y G.711 (PCMA y PCMU); sin requisito de PLC ni de FEC | IETF RFC 7874 (2016) |
Contexto: la RFC 6716 y la RFC 7874 tienen más de tres años, pero siguen siendo los estándares vigentes (RFC 6716, RFC 7874). El borrador de DRED, si se aprueba, actualizaría la RFC 6716 con una capa neuronal de redundancia.
Resumen: Ocultación de Pérdida de Paquetes en Audio WebRTC en Cifras
| Métrica | Valor | Fuente |
|---|---|---|
| Llamadas de Google Duo que deben lidiar con pérdida de paquetes, jitter o retardo | 99% | Google Research, blog de WaveNetEQ 2020 |
| Llamadas de Duo que pierden más del 8% de su audio | 10% | Google Research, blog de WaveNetEQ 2020 |
| Umbral Poor de Teams para la pérdida media de paquetes de audio | Por encima de 0,1 (10%) | Microsoft Learn, CQD Stream Classification 2026 |
| Umbral de la etiqueta high_packet_loss de Twilio | Por encima del 5% | Twilio Voice Insights, Details: Call Tags |
| Factor de robustez Bpl de G.711: sin ocultación frente a ocultación del Apéndice I | 4,3 frente a 25,1 | ITU-T G.113 (09/2024) |
| G.729 Anexo A con detección de actividad de voz: Bpl | 19,0 | ITU-T G.113 (09/2024) |
| PLCMOS del desafío de 2022: relleno con ceros frente a ganador frente a limpio | 2,90 frente a 4,28 frente a 4,51 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| Precisión de palabras del desafío de 2022: relleno con ceros frente a ganador frente a limpio | 0,86 frente a 0,88 frente a 0,97 | Microsoft, artículo del INTERSPEECH 2022 Deep PLC Challenge |
| Cómputo del PLC híbrido del equipo de Opus por cada 10 ms de voz | 1,3 a 1,4 ms (13% a 14% de un núcleo) | Valin et al. 2022 |
| Calidad global P.804 del desafío de 2024: con pérdidas frente a mejor frente a limpio | 2,37 frente a 3,49 frente a 4,01 | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Sistemas del desafío de 2024 con puntuación por debajo del audio con pérdidas sin procesar | 2 de 8 | Microsoft, artículo del ICASSP 2024 Deep PLC Challenge |
| Correlación de Pearson por modelo de PLCMOS con las valoraciones humanas | Alrededor de 0,97 | Diener et al., artículo de PLCMOS 2023 |
| Correlación de Pearson por modelo de PESQ frente a STOI en sistemas de PLC | 0,52 frente a 0,21 | Diener et al., artículo de PLCMOS 2023 |
| Profundidad de redundancia de LBRR frente a DRED | 1 trama frente a hasta un segundo o más | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Tasa de bits de redundancia de DRED respecto a Opus regular | Cerca de 1/50 | IETF draft-ietf-mlcodec-opus-dred-07, 2026 |
| Audio ocultado con un 20% de pérdida: sin RED frente a RED de dos tramas | 18% frente a 0,7% | webrtcHacks, prueba de RED de Hancke 2020 |
| Tasa de bits mínima de FEC en banda de Opus con un 10% de pérdida | 19 kbps (comparación del propio proveedor) | Meta Engineering, blog del códec MLow 2024 |
| Costo de CPU del Deep PLC de Opus 1.5 | Cerca del 1% de un núcleo de portátil | Xiph.Org, demostración de Opus 1.5 2024 |
| Tamaño del modelo DRED de Opus 1.6 frente al de 1.5 | 600 kB frente a 1.800 kB | Xiph.Org, demostración de Opus 1.6 2025 |
Metodología y Fuentes
- Microsoft Research, artículo del INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge (Diener et al., 2022): arxiv.org/pdf/2204.05222
- Microsoft Research, artículo del ICASSP 2024 Audio Deep Packet Loss Concealment Challenge (2024): arxiv.org/html/2402.16927v1
- Microsoft Research, página del programa del 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 (agosto de 2026): ietf.org
- IETF, ML codec listening test battery, draft-ietf-mlcodec-test-battery-00 (junio de 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 (borrador de Recomendación Candidata, 25 de septiembre de 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 (abril de 2020): research.google
- Microsoft Learn, Stream Classification in Call Quality Dashboard (actualizado en junio de 2026): learn.microsoft.com
- Microsoft Learn, Dimensions and measures available in Call Quality Dashboard (actualizado en julio de 2026): learn.microsoft.com
- Twilio, Voice Insights Details: Call Tags: twilio.com
- Meta Engineering, MLow: Meta’s low bitrate audio codec (junio de 2024): engineering.fb.com
- Xiph.Org, demostración de Opus 1.5 (marzo de 2024) y demostración de Opus 1.6 (diciembre de 2025): opus-codec.org/demo/opus-1.5, opus-codec.org/demo/opus-1.6
- webrtcHacks, RED: Improving Audio Quality with Redundancy (Philipp Hancke, agosto de 2020): webrtchacks.com
- Nota sobre los datos: la única distribución de pérdidas por llamada de una gran plataforma es la cifra de Duo de Google de 2020, y las mediciones de ocultación con RED son una prueba de 2020 de un solo autor, por lo que ambas se señalan como los datos disponibles más recientes. El ejemplo del modelo E de la sección 2 es un cálculo propio a partir de la Ecuación 7-29 y el Anexo B de ITU-T G.107 con los valores de Bpl de G.113, dejando todas las demás entradas en su valor predeterminado; es una estimación, no una medición. Las puntuaciones de los desafíos no son comparables entre ediciones: la de 2022 usó audio de banda ancha, PLCMOS y CMOS con ráfagas de hasta 1 segundo, mientras que la de 2024 usó audio de banda completa, P.804 y ráfagas de hasta 3 segundos. En el artículo de 2022, PLCMOS se correlacionó con CMOS en alrededor de 0,95 de Pearson, mientras que la versión posterior de PLCMOS informa alrededor de 0,97 en un conjunto de evaluación distinto. Las cifras de Xiph.Org y Meta son afirmaciones de los propios desarrolladores. Los umbrales de Teams (10%) y Twilio (5%) discrepan por diseño, porque cada proveedor los ajusta a su propia pila de medios. El borrador de DRED (que caduca en febrero de 2027) y el borrador de la batería de pruebas del IETF, cuyos escenarios de pérdida de paquetes siguen sin definir, pueden cambiar antes de publicarse como RFC.
Última actualización: 24 de octubre de 2026. Actualizamos este informe trimestralmente, y la próxima revisión se espera cuando el grupo de trabajo mlcodec del IETF publique la siguiente revisión del borrador de Opus DRED y de los escenarios de pérdida de paquetes de la batería de pruebas.