- Meta creó MLow, un nuevo códec de audio de baja tasa de bits, para mantener la calidad de las llamadas en tiempo real de WhatsApp, Instagram y Messenger incluso en redes lentas y dispositivos antiguos
- El Opus existente funciona en modo NarrowBand a 6 kbps, por lo que no logra capturar suficientemente las frecuencias de la voz; además, cuando la red empeora durante una videollamada, se reduce aún más la tasa de bits asignada al audio
- Los códecs de audio basados en ML pueden ofrecer buena calidad a bajas tasas de bits, pero suelen ser adecuados para dispositivos móviles modernos de alto rendimiento debido a su alto costo computacional
- MLow, con WideBand a 6 kbps, alcanza POLQA MOS 3.9, casi el doble de calidad que el 1.89 de Opus, y su complejidad computacional es 10% menor que la de Opus
- Ya se implementó por completo en las llamadas de Instagram y Messenger, y se está desplegando en WhatsApp; al permitir incluir FEC de forma más eficiente a bajas tasas de bits, favorece la recuperación de audio en situaciones de pérdida de paquetes
Por qué Meta creó un nuevo códec
- Las apps de Meta, incluidas WhatsApp, Instagram y Messenger, ofrecen funciones de comunicación en tiempo real (RTC) a miles de millones de personas
- En RTC, los códecs de audio y video son componentes clave que comprimen los datos capturados para transmitirlos por internet y mantener las llamadas en tiempo real
- El audio sin procesar de una llamada típica, con muestreo de 48 kHz, 16 bits y mono, es de 768 kbps, y los códecs modernos pueden comprimirlo hasta 25~30 kbps
- En el proceso de compresión puede haber pérdida de información y degradación de calidad, pero un buen códec usa las características de la señal de audio y conocimientos de psicoacústica para equilibrar calidad, tasa de bits y complejidad
- Opus es un códec open source ampliamente conocido, publicado en 2012, y Meta lo ha usado hasta ahora para los requisitos de RTC
Restricciones de las bajas tasas de bits y los dispositivos antiguos
- En el entorno RTC a gran escala de Meta, se puede observar directamente cómo distintas condiciones de red afectan la experiencia de llamada
- Una proporción considerable de llamadas experimenta mala conexión de red durante toda la llamada o en algunos tramos
- El módulo de estimación de ancho de banda (BWE) detecta la calidad de la red
- Cuando la calidad de la red empeora, hay que reducir la tasa de bits del códec para evitar congestión y mantener el flujo de audio
- En las videollamadas, bajo malas condiciones de red, queda aún menos margen disponible para el audio
- El punto mínimo de funcionamiento de Opus es 6 kbps y, en ese caso, opera en modo NarrowBand de 0~4 kHz
- Ese rango no captura suficientemente todas las frecuencias que produce la voz humana
- Como resultado, la voz se oye menos clara y menos natural
- Los códecs de audio basados en ML, como Encodec, presentado por Meta en octubre de 2022, ofrecen audio claro incluso con tasas de bits muy bajas
- Sin embargo, su costo computacional es alto, por lo que a menudo solo funcionan de forma estable en dispositivos móviles potentes y costosos
- Los usuarios de dispositivos de bajas especificaciones siguen sufriendo problemas de calidad de audio en condiciones de baja tasa de bits
- Más del 20% de las llamadas de Meta se realizan en dispositivos ARMv7, y en WhatsApp se hacen decenas de millones de llamadas al día desde dispositivos de más de 10 años
Rendimiento de MLow y estado de despliegue
- Meta comenzó a desarrollar el nuevo códec a fines de 2021 y, tras casi dos años de desarrollo y pruebas, presentó Meta Low Bitrate audio codec, es decir, MLow
- Su calidad con WideBand a 6 kbps es POLQA MOS 3.9, casi el doble que el 1.89 de Opus
- Su complejidad computacional es 10% menor que la de Opus
- En la comparación de MOS (Mean Opinion Score) en una escala de 1 a 5, MLow muestra una gran ventaja sobre Opus en rangos de baja tasa de bits, y su calidad se satura más rápido que la de Opus
- Ya se aplicó a todas las llamadas de Instagram y Messenger, y se está desplegando activamente en WhatsApp
- También se confirmó que una mejor calidad de audio contribuye a mejorar la participación de los usuarios
FEC en situaciones de pérdida de paquetes
- Si se puede codificar audio de alta calidad a bajas tasas de bits, también se puede usar de forma más efectiva una estrategia de Forward Error Correction (FEC)
- En comparación con Opus, MLow deja margen para incluir FEC incluso a tasas de bits más bajas
- Esta característica ayuda a mejorar la calidad del audio en situaciones de pérdida de paquetes
- Hay una comparación de muestras en una situación de gran pérdida de paquetes del lado receptor, de 30%, a 14 kbps
- Opus no puede codificar FEC in-band con esa tasa de bits
- Para que Opus codifique FEC in-band con 10% de pérdida de paquetes, necesita al menos 19 kbps
- Esta restricción juega en contra de la recuperación de audio
Estructura interna de MLow
- MLow se basa en el concepto de códec tradicional CELP (Code Excited Linear Prediction)
- Sus principales mejoras están en la generación de excitación, la cuantización de parámetros y el método de codificación
- El codificador recibe audio PCM sin procesar como señal de entrada y lo divide en una banda de baja frecuencia y una de alta frecuencia
- Cada banda se codifica por separado, pero se usa información compartida para lograr una mejor compresión
- La salida pasa por un codificador de rango (range encoder) para una compresión adicional, y se genera el payload codificado
- El decodificador recibe el payload y realiza el proceso inverso para producir la señal de audio de salida
- MLow puede codificar la banda de alta frecuencia con muy pocos bits gracias a la optimización por bandas divididas
- Gracias a esta estructura, puede ofrecer SuperWideBand, es decir, audio con muestreo de 32 kHz, incluso a tasas de bits más bajas
Trabajo posterior
- MLow mejora significativamente la calidad del audio en dispositivos de bajas especificaciones, a la vez que mantiene el cifrado de extremo a extremo de las llamadas
- Como permite incluir audio redundante de forma eficiente a bajas tasas de bits, se sigue trabajando para mejorar la recuperación de audio en redes con fuerte pérdida de paquetes
1 comentarios
Opiniones de Hacker News
Los nuevos códecs de baja tasa de bits son sorprendentes, pero en la mayoría de los escenarios en los que Meta querría usarlos, puede que en realidad no sean tan útiles
Para reducir la latencia en comunicaciones en tiempo real, la frecuencia de envío de paquetes debe ser bastante alta, y a partir de cierto punto el overhead de UDP, IP y las capas inferiores termina dominando más que la carga útil real
Por ejemplo, (S)RTP sobre UDP/IP agrega un overhead total de 40 bytes: RTP tiene un mínimo de 12 bytes, UDP 8 bytes e IPv4 20 bytes. Con 50 paquetes por segundo, es decir, con una latencia de serialización de 20 ms, solo el overhead ya es de 16 kbps
Si se reduce a 25 paquetes por segundo, el overhead baja a 8 kbps, pero aun así representa una gran proporción de la tasa de transmisión total
Donde estos códecs realmente brillan es en comunicaciones conmutadas por circuito de alrededor de 2 kbps, como algunos teléfonos satelitales, o en sistemas VoIP conscientes del protocolo que usan compresión de encabezados, donde la mayoría de los 40 bytes por frame son predecibles, como en IMS sobre LTE/5G
Un paquete de 100 ms aumenta bastante la latencia, pero a ese nivel el ahorro del códec empieza a tener sentido. Un sistema más sofisticado podría ajustar el códec y la cantidad de muestras por paquete según las condiciones actuales
El sistema con el que trabajo usa un códec fijo y 60 ms de audio por paquete, así que no es ideal, pero funciona mucho mejor con bajo ancho de banda que con paquetes de 20 ms
Meta tiene una distribución muy amplia de servidores de reenvío, así que también puede permitirse agregar un poco más de latencia de muestreo. Puede reenviar desde equipos de contenido ubicados dentro de varios ISP, lo que le permite reducir la latencia de red frente a servicios competidores con capacidad limitada de hosting de reenvío a nivel mundial. P2P tampoco funciona siempre, ni siempre tiene menor latencia que pasar por un servidor de reenvío cercano
En particular, los mensajes de voz y las llamadas de WhatsApp tienen una cuota considerable en países con redes intermitentes y poco confiables. Si es más resistente a la pérdida de paquetes y al jitter, también puede depender de protocolos con menos overhead de corrección de errores, fragmentación y acuses de recibo
No es descabellado pensar que esta tecnología puede reducir bastante el consumo total de ancho de banda generado por el audio, manteniendo o incluso mejorando la confiabilidad y la calidad percibida
Al observar una llamada activa de WhatsApp con Wireshark, durante una llamada de 1 minuto se enviaron unos 380 paquetes UDP del emisor al receptor, y algunos paquetes TCP al servidor de WhatsApp. Con eso, el overhead de transmisión es de unos 2.2 kbps
Para agregar el motivo: aquí el ptime inicial, es decir, el tamaño de audio por paquete, se configura en 20 ms, pero maxptime se configura en 150 ms. El cliente puede usar esto de forma oportunista, considerando la latencia de ambos lados y el ancho de banda disponible, para reducir la cantidad de paquetes transmitidos
Imagen: https://www.twilio.com/content/dam/twilio-com/global/en/blog...
Los códecs de voz usados comúnmente en sistemas de radio, como AMBE+2, suenan bastante mal y no manejan la pérdida de paquetes con la misma elegancia que los códecs nuevos
Podría ser puro humo, pero dado que Meta es uno de los mayores operadores que ofrecen llamadas de voz y video en dispositivos de bajo ancho de banda, no parece muy probable
No sé en qué se basan para pensar que Meta estuvo equivocándose a sí misma todo este tiempo
Por ejemplo, si el servidor no puede hacer la mezcla por el cifrado de extremo a extremo, se podrían incluir datos de varios flujos en un solo paquete. Las llamadas de audio cifradas de extremo a extremo ya están bastante extendidas, y Facebook parece estar en una buena posición para hacer multiplexación personalizada en sus propios productos
¿Soy el único al que le parece que Meta volvió a verse genial al compartir tanta investigación, open source o trabajos con pesos públicos?
La reputación de Facebook estaba por el piso, pero ahora parece haber recuperado algo de terreno
Puede que la reputación de Facebook como red social no brille, pero creo que la reputación de Meta como empresa de ingeniería es bastante alta
Es algo parecido a IBM. Puede que no parezca tan excelente como proveedor de soluciones de hardware o software, pero sus áreas de investigación y microelectrónica siguen siendo bastante geniales
Microsoft Research también produce cosas realmente geniales, pero eso no significa que la misma Microsoft no ponga anuncios en el menú Inicio de su sistema operativo
Hace unos años, cuando era adolescente, vi esa divergencia interesante en Microsoft, y no me sorprende en absoluto que dentro de Facebook coexistan departamentos que hacen cosas geniales como zstandard y personas completamente separadas que trabajan hacia objetivos totalmente distintos. Probablemente en la mayoría de las empresas de más de unos cientos de personas exista este tipo de divergencia entre departamentos
Pero tengo una visión muy negativa de la postura de Meta sobre privacidad, seguridad y responsabilidad social
Me vienen a la mente CassandraDB y (Py)Torch
La falta total de mención o comparación con Codec2 hace que el valor real y la motivación de este trabajo resulten inmediatamente sospechosos.
En este espacio no hace falta otro códec de audio más atado a propiedad intelectual.
https://jmvalin.ca/demo/lpcnet_codec/
Me pregunto si esto es mejor que lo que usa Google Meet.
Incluso con Internet lento, que se corta tanto que casi no sirve, Google Meet logró cumplir el objetivo de una llamada de audio, mientras que otros servicios competidores fallaron. Por ejemplo, lo probé con una conexión pésima en una isla remota de Filipinas.
Sin embargo, hasta donde sé, la tecnología de Google Meet no está publicada en ningún lado.
Viendo solo algunos ejemplos publicados, nosotros tampoco podemos juzgar mucho más que eso.
Tampoco lo compararon con Pied Piper.
Me salgo un poco del tema, pero ¿por qué las llamadas telefónicas comunes de hoy son más difíciles de entender que el μ-law de 8 kHz y 8 bits y ADPCM de los 90?
Editado: cambié “suena peor” por “es más difícil de entender”.
No es muy bueno para música, pero funciona más o menos bien para voz y, sobre todo, es muy consistente. En las llamadas de los 90, casi todo el último tramo era conmutado por circuitos y, en las líneas digitales, se multiplexaba muestra por muestra. T1 y superiores funcionaban así.
Por eso la latencia era muy baja y el jitter era cero. En comparación con una llamada analógica conmutada por circuitos de punta a punta, había una latencia medible, pero era difícil percibirla en la práctica, y como el muestreo digital se hacía cerca de ambos extremos, había mucho menos ruido. La conmutación por circuitos también significa que no se perdían muestras. O la conexión estaba, o no estaba; a veces podía funcionar en un solo sentido.
Las llamadas modernas normalmente usan muestras de 20 ms sobre una red conmutada por paquetes, así que se suman latencia de muestreo, jitter y búfer de jitter. El códec en sí también hace más que simplemente ADC/DAC con un logaritmo, por lo que hay latencia de codificación y decodificación. La mayoría de los códecs usan muchos menos bits por muestra que μ-law, y ese costo no sale gratis.
HD Voice (G.722.2 AMR-Wideband) tiene una banda de paso de frecuencias mucho más amplia, así que suena mucho mejor que GSM, Opus y la mayoría de los códecs de bajo ancho de banda. Aun así, la latencia sigue ahí. Algunos dirán que no se perciben 20 a 100 ms de latencia, pero si alguien escucha una prueba A/B entre una llamada con 0 ms y otra con 20 ms de latencia, dirá que la de 0 ms es mejor.
En 2013 cambié de un teléfono tipo flip a un iPhone, y la diferencia fue enorme. Enseguida empecé a usar auriculares o el altavoz; en ese entonces yo era adolescente.
La mayoría de las llamadas de los 90 no usaban ADPCM, sino simplemente PCM. Probablemente la confusión viene de ahí.
Y tampoco se usaba inalámbrico. Había un cable de cobre firme desde mi micrófono hasta el auricular de la otra persona. Lo inalámbrico —celulares, Wi‑Fi, teléfonos inalámbricos— es intrínsecamente menos confiable.
Los teléfonos antiguos tenían sidetone, pero muchas apps de VoIP no.
Por último, ahora el uso del altavoz está muy extendido, y el altavoz no combina bien con el sidetone y agrega mucho desvanecimiento por trayectorias múltiples de audio.
La falta de mención a NoLACE hace que las muestras comparativas sean un poco menos útiles: https://opus-codec.org/demo/opus-1.5/
https://datatracker.ietf.org/wg/mlcodec/documents/
Sería bueno que Meta donara esto al mundo, para reducir las trabas de los trolls de patentes y poder avanzar hacia el futuro que deberíamos estar disfrutando.
¿Van a publicar esto, o es solo una presumida de ingeniería? No puedo encontrar ninguna otra referencia sobre MLow aparte de este post del blog.
Facebook/Meta AI Research hace cosas geniales y publica una buena parte de ellas. No me gusta Facebook, pero puedo reconocer que es muy innovador en el campo de la IA.
El texto dice: “Estamos muy contentos con lo logrado durante los últimos dos años: desarrollar un nuevo códec y desplegarlo con éxito a miles de millones de usuarios en todo el mundo”.
Pregunta honesta: ¿por qué habría que optimizar para menos de 10 kbps?
Lograr esta calidad a 6 kbps es realmente impresionante, pero incluso LTE ya soporta 32 kbps o más, y en ese rango existen AMR-WB u Opus. Opus también tiene corrección de errores hacia adelante dentro de banda a estas tasas de bits, así que la pérdida de paquetes no es tan crítica.
Quizá podría ser útil para casos como satélite directo al celular.
Suponer que hay más de 32 kbps de ancho de banda es una mala suposición.
Si reduces la tasa de bits del códec de audio que usas, puedes hablar durante más tiempo al mes con el mismo plan de datos.
Dicho eso, en este ámbito los beneficios disminuyen por la sobrecarga de RTP, UDP e IP. Hay más detalles en otro comentario que hice.
Este espacio actualmente lo domina AMBE, que es terrible en todas las métricas medibles y debería ser quemado en las llamas más profundas del infierno y borrado de la historia.
Si necesitas latencia baja y estable, como en una llamada telefónica, el rendimiento que puedes obtener se reduce mucho.
Por ejemplo, Wi-Fi en el límite de cobertura o una conexión LTE con una sola barra de señal.
En esos casos, una prueba de velocidad puede decir que obtienes varios megabits, pero si quieres baja latencia estable, el ancho de banda realmente utilizable probablemente esté en el orden de los kilobits.
Me pregunto cómo sonaría comparado con G.729.
En una empresa donde trabajé hace 20 años tenían un códec G.729 modificado que seguía sonando bastante bien incluso por debajo de 8 kbps. Lo usábamos para VoIP sobre Internet de acceso telefónico, así que era realmente de bajo ancho de banda.
Resultó que parte de lo más interesante estaba en el búfer de jitter y en la forma de administrar el búfer. Una conexión inestable entrega paquetes cuando puede, y hace falta técnica para gestionar la diferencia entre la experiencia de red y la experiencia del usuario. En comunicaciones hay que gestionar bien la experiencia del usuario.