NetEQ es una de las tecnologías centrales de audio y video de WebRTC. Tiene efectos obvios en la mejora de la calidad de VoIP. Este artículo presentará los conceptos relacionados, los antecedentes y los principios del marco de trabajo de NetEQ de audio en WebRTC y las prácticas de optimización relacionadas desde una perspectiva más macro. y en lenguaje sencillo.
Autor |
Revisión de Liang Yi | un tailandés
¿Por qué NetEQ "vernáculo"?
Solo busque, podemos encontrar muchos artículos sobre audio NetEQ en WebRTC en Internet. Por ejemplo, los siguientes artículos son muy buenos materiales de aprendizaje y referencias. Especialmente en 2013, la tesis de maestría de Wu Jiangrui de la Universidad de Xidian, "Investigación sobre tecnología NetEQ en WebRTC Speech Engine", presentó los detalles de la implementación de NetEQ con gran detalle y fue citada en muchos artículos.
- "Investigación sobre la tecnología NetEQ en WebRTC Speech Engine"
- Algoritmo NetEQ
- NetEQ relacionado con el audio en WebRTC
La mayoría de estos artículos han realizado un análisis muy completo de los detalles de NetEQ desde una perspectiva más "académica" o "algorítmica", por lo que aquí quiero hablar sobre mi comprensión personal desde una perspectiva más macro. La lengua vernácula es más fácil de aceptar por todos. No es necesario luchar por una fórmula matemática. Si no tiene una línea de código, puede hacer que su pensamiento sea claro. Si tiene alguna comprensión incorrecta, no dude en Haznos saber.
Comprensión de la pérdida, fluctuación y optimización de paquetes
En el campo de la comunicación de audio y video en tiempo real, especialmente en oficinas móviles (4G), oficinas en el hogar y aulas en línea (WIFI) bajo la epidemia, el entorno de red se ha convertido en el factor más crítico que afecta la calidad de audio y video. mala calidad de la red, no importa lo buena que sea. Los algoritmos de audio y video parecen ser una gota en el agua. El rendimiento de la red de mala calidad incluye principalmente retraso, desorden, pérdida de paquetes y jitter . Quien pueda manejar y equilibrar este tipo de problemas puede obtener una mejor experiencia de audio y video. Dado que el retraso básico de la red está determinado por la elección del enlace, la capa de programación del enlace debe optimizarse para resolverlo; y el desorden no es mucho en la mayoría de las condiciones de la red, y el grado de desorden no es muy serio. así que a continuación analizaremos principalmente la pérdida de paquetes y el jitter.
La fluctuación se refiere a la velocidad repentina y la lentitud de la transmisión de datos en la red. La pérdida de paquetes se refiere a que el paquete de datos se transmite a través de la red y se pierde debido a varias razones. Después de varias retransmisiones, se recibe correctamente como un paquete de recuperación y el la retransmisión también falla o Si el paquete de recuperación está desactualizado, causará una pérdida real de paquetes, y el algoritmo PLC para la recuperación de la pérdida de paquetes es necesario para generar algunos datos falsos de la nada para compensar. La pérdida de paquetes y el jitter están unificados en la dimensión de tiempo. Lo que viene después de un tiempo es el jitter, y lo que viene después de mucho tiempo es un paquete de retransmisión. Lo que sea que venga después de toda una vida es "verdadera pérdida de paquetes". Nuestro objetivo es tratar de reducir la probabilidad de que los paquetes de datos se conviertan en "verdadera pérdida de paquetes".
La optimización, intuitivamente hablando, es un indicador de datos determinado, después de una operación feroz, se ha actualizado de xxx a xxx. Pero creo que juzgar la calidad de la optimización no puede quedarse en esta dimensión. La optimización es "conocerse a sí mismo y al enemigo". Usted es sus propias necesidades de producto. Esa es la capacidad del algoritmo existente. La combinación de usted mismo y la otra es la mejor optimización, independientemente del algoritmo. Ya sea simple o complejo, siempre que se adapte perfectamente a las necesidades de su producto, es el mejor algoritmo. "Un buen gato es un buen gato que puede atrapar un ratón. "
NetEQ y módulos relacionados
La procedencia de NetEQ
"Documento original de GIPS NetEQ" , esta es la documentación original de NetEQ proporcionada por GIPS Company ( traducción al chino ), que presenta lo que es NetEQ y una breve descripción de su desempeño. NetEQ es esencialmente un JitterBuffer de audio (búfer de fluctuación), el nombre es muy apropiado, Network Equalizer (ecualizador de red). Todo el mundo sabe que Audio Equalizer es un efector que se utiliza para ecualizar el sonido, y NetEQ aquí es un efector que se utiliza para ecualizar la fluctuación de la red. Y GIPS también registró una marca comercial para este nombre, por lo que NetEQ (TM) se ve en muchos lugares.
En el documento oficial anterior, hay un mensaje muy importante, "Minimizar el impacto del retraso causado por el búfer de fluctuación", que muestra que uno de los objetivos de diseño de NetEQ es: "Perseguir una latencia extremadamente baja" . Esta información es fundamental y proporciona pistas importantes para nuestra posterior optimización.
Posición de NetEQ en el proceso de QoS de comunicación de audio y video
Para los usuarios comunes, siempre que la red esté conectada, WIFI y 4G se pueden usar para la comunicación de audio y video. Se pasa una llamada, y cuando ve gente y escucha el sonido, está bien. Es una cuestión simple, pero no se fija en la implementación subyacente. Es así de simple. El número de archivos de código relacionados solo para el motor de código abierto WebRTC es de unos 200 000. No sé si alguien ha calculado el número de líneas de código, debería ser del orden de decenas de millones. No sé cuántos codificadores perdieron el cabello por esta razón :).
La siguiente imagen es una abstracción y simplificación del proceso de comunicación de audio y video realmente más complicado. A la izquierda está el lado de envío (transmisión): después de la recopilación, codificación, encapsulación y envío; el medio se transmite a través de la red; a la derecha está el lado de recepción (transmisión): recepción, desempaquetado, decodificación y reproducción; aquí es el enfoque en QoS (Calidad de servicio), Calidad del servicio) y la relación con el flujo principal de datos push-pull. Se puede ver que la función QoS está dispersa en varias posiciones en el proceso de comunicación de audio y video, lo que conduce a una comprensión más completa de la QoS después de comprender todo el proceso. Parece que hay más funciones de QoS en el lado de envío a la izquierda. Esto se debe a que el propósito de QoS es resolver el problema de la experiencia del usuario en el proceso de comunicación. Para resolver el problema, la mejor manera es encontrar la fuente del problema y resolverlo desde la fuente. Es una mejor solución. Pero siempre hay algunos problemas que no se pueden resolver desde la fuente. Por ejemplo, en un escenario de reunión de varias personas, la red de una persona en el lado receptor está rota, lo que no puede afectar la experiencia de reunión de otras personas, y no puede haber "una rata mierda que rompe una olla de papilla ". Circunstancias, la fuente no se puede contaminar. Por lo tanto, el flujo de recepción también debe realizar la función QoS. En la actualidad, la función necesaria en el lado de recepción es el JitterBuffer, incluido el video y el audio. Este artículo se centra en el análisis del audio JitterBuffer - NetEQ.
Principio NetEQ y la relación entre módulos relacionados
La imagen de arriba es una abstracción del flujo de trabajo de NetEQ y sus módulos relacionados. Incluye principalmente 4 partes, entrada NetEQ, salida NetEQ, módulo de solicitud Nack de retransmisión de audio y módulo de sincronización de audio y video. ¿Por qué deberían incluirse el módulo de solicitud Nack y el módulo de sincronización de audio y vídeo en el análisis de NetEQ? Porque estos dos módulos dependen directamente de NetEQ y se influyen mutuamente. Las líneas de puntos en la figura identifican la información de otros módulos de los que depende cada módulo y la fuente de esta información. A continuación, presentaré todo el proceso.
1. La primera es la parte de entrada de NetEQ:
Después de recibir un paquete de Socket UDP inferior, desde el paquete UDP analizado hasta el paquete de activación RTP, coincidiendo con *** C y después de PayloadType para encontrar el canal de audio recibido correspondiente, y desde InsertPacketInternalla entrada del módulo receptor a NetEQ.
Es probable que el paquete RTP de audio recibido tenga redundancia RED. De acuerdo con el estándar RFC2198 o algún formato de encapsulación patentado, descomprímalo y restaure el paquete original. El paquete original duplicado será ignorado. El paquete de datos RTP original decodificado se insertará en la memoria caché del búfer de paquetes de acuerdo con un algoritmo determinado. Después del número de secuencia recibido, con cada uno de los paquetes originales, por UpdateLastReceivedPacketla función que actualiza la solicitud de retransmisión de Nack al módulo, el módulo activa los modos Nack o la recepción de paquetes a través del temporizador RTP llama a GetNackListla función para generar una solicitud de retransmisión a NACK RTCP El formato del el paquete se envía al lado de la transmisión.
Al mismo tiempo, después de resolver cada paquete original, se obtiene el único tiempo de recepción en el eje del tiempo. También se puede calcular la diferencia de tiempo de recepción entre el paquete y el paquete. Esta diferencia de tiempo de recepción dividida por el tiempo de empaque de cada paquete es utilizado por NetEQ internamente. IAT (tiempo de llegada) para la estimación de la fluctuación . Por ejemplo, si la diferencia de tiempo entre dos paquetes es de 120 ms y el tiempo de empaquetado es de 20 ms, el valor IAT del paquete actual es 120/20 = 6. Una vez que el módulo de estimación de fluctuación de la red central (DelayManager) procesa el valor IAT de cada paquete, se obtiene el nivel objetivo final (TargetLevel) y finaliza la parte de procesamiento de entrada de NetEQ.
2. A continuación, se encuentra la parte de salida de NetEQ:
Se emite por el aparato de reproducción que reproduce la sincronización del hilo del hardware de audio activada por cada 10 ms. El aparato de reproducción obtendrá GetAudioInternaluna longitud de datos de 10 ms desde la interfaz interna de reproducción NetEQ.
Ingrese a la GetAudioInternalsiguiente función, el primer paso es decidir cómo manejar la solicitud de datos actual, la tarea al módulo de decisión operativa para completar, y antes del módulo de decisión basado en los datos actuales y el estado de la operación, el tipo de operación da el juicio final. En NetEQ se definen varios tipos de operaciones: normal, aceleración, desaceleración, fusión, estiramiento (compensación de pérdida de paquetes) y mute . El significado de estas operaciones se describirá en detalle más adelante. Con el tipo de operación de toma de decisiones, que nuevamente se elimina del búfer de paquetes (búfer de paquetes) de una parte de los paquetes RTP de entrada al decodificador abstracto, el decodificador por la DecodeLoopcapa abstracta al decodificador de llamada real para la función de decodificación, y el Datos de audio PCM decodificados en el DecodedBufferinterior. Luego es el inicio de realizar diferentes operaciones, cada operación es NetEQ, que han logrado diferentes algoritmos de procesamiento de señal digital de audio (el DSP), acción "normal" además del uso directo DecodedBufferen los datos decodificados, las otras operaciones son datos decodificados vinculados para procesamiento secundario del DSP, el resultado del procesamiento se colocará primero en el búfer de algoritmo y luego se insertará en el búfer de sincronización. El búfer de sincronización es un búfer circular con un diseño inteligente. Almacena datos que se han reproducido y datos que no se han reproducido después de la decodificación. Los datos que se acaban de insertar del búfer del algoritmo se colocan al final del búfer de sincronización, como se muestra en la figura de arriba. Finalmente, los primeros datos decodificados se toman del Sync Buffer, se envían al módulo de mezcla externo y luego se envían al hardware de audio para su reproducción después de la mezcla.
Además, se puede ver en la figura que el módulo de decisión (BufferLevelFilter) combinará la longitud del búfer en el búfer de paquetes del búfer de paquetes actual y la longitud de los datos almacenados en el búfer de sincronización, y obtendrá el nivel de búfer actual. del audio después de filtrar por el algoritmo. El módulo de sincronización de audio y video utilizará el nivel de búfer de audio actual y el nivel de búfer de video actual, combinado con la marca de tiempo del último paquete RTP y la marca de tiempo obtenida por el paquete SR del audio y video, para calcular el grado de asincronía de audio y video, y finalmente configúrelo en NetEQ a través de SetMinimumPlayoutDelay El nivel de agua objetivo mínimo en el interior se usa para controlar TargetLevel para lograr la sincronización de audio y video.
Módulo interno NetEQ
Módulo de estimación de jitter NetEQ (DelayManager)
1. Parte de estimación de la fluctuación de fase estacionaria:
Acumule el valor IAT de cada paquete de acuerdo con una cierta proporción (la proporción se determina mediante el cálculo de la parte del factor de olvido a continuación), y agréguelo al histograma de las estadísticas IAT a continuación, y finalmente calcule 0.95 del valor acumulado desde la izquierda. a la derecha Ubicación, el valor de IAT en esta ubicación se utiliza como el valor de estimación de IAT de fluctuación final. Por ejemplo, en la figura siguiente, suponiendo que el nivel de agua objetivo TargetLevel es 9, significa que la duración de los datos de la caché objetivo será de 180 ms (asumiendo que la duración del empaquetado es de 20 ms).
2. Cálculo del factor de olvido de la fluctuación constante:
El factor de olvido es un coeficiente que se usa para controlar cuánto se agrega el valor IAT del paquete actual al histograma anterior. El proceso de cálculo utiliza una fórmula aparentemente más complicada. Después del análisis, su esencia es la curva amarilla a continuación, lo que significa que al principio, el factor de olvido es pequeño, y se usarán valores de IAT de paquetes más actuales para acumular.A medida que pasa el tiempo, el factor de olvido se hará gradualmente más grande y se usarán menos valores de IAT de paquetes actuales para acumular. Este proceso es un poco complicado. Desde el punto de vista de la ingeniería, se puede simplificar en una línea recta, porque básicamente converge al valor objetivo de 0.9993 en aproximadamente 5 segundos después de la prueba. De hecho, este 0.9993 es el factor más importante afectando la estimación de jitter Muchas optimizaciones también modifican directamente este coeficiente para ajustar la sensibilidad de la estimación.
3. Estimación de la fluctuación de fase de pico:
Hay un detector de picos PeakDetector en DelayManager para identificar picos. Si los picos se detectan con frecuencia, entrará en el estado de estimación de jitter de picos y tomará el pico más grande como resultado de la estimación final, y una vez que entre en este estado, continuará durando durante 20 segundos, independientemente de la fluctuación actual. ¿Ha vuelto a la normalidad? A continuación se muestra un diagrama esquemático.
Módulo de decisión de operación de NetEQ (DecisionLogic)
La lógica de decisión básica simplificada del módulo de toma de decisiones se muestra en la siguiente figura, que es relativamente concisa y no necesita explicación. A continuación, se ofrece una explicación del significado de los siguientes tipos de operaciones:
- ComfortNoise: se utiliza para generar un ruido confortable, que suena más cómodo en un estado silencioso que una simple bolsa silenciosa;
- Expandir (PLC): compensación de pérdida de paquetes, el módulo de algoritmo más importante de la nada, resuelve el problema de la falta de datos cuando se produce una "pérdida real de paquetes" y los usuarios profesionales fraudulentos;
- Fusionar: Si los datos fueron falsificados por Expand la última vez, para que suene más cómodo, realizaré un algoritmo de fusión con paquetes de datos normales;
- Acelerar: algoritmo de reproducción acelerada que cambia la voz sin cambiar el tono;
- PreemptiveExpand: un algoritmo de reproducción en ralentización que cambia la voz y no cambia el tono;
- Normal: decodificación y reproducción normales, no se introducen datos falsos adicionales;
Puntos de optimización del módulo relacionados con NetEQ
Optimización anti-jitter de NetEQ
- Dado que el objetivo de diseño de NetEQ es "una latencia muy baja", no se puede combinar bien. Para escenarios de latencia no muy baja, como videoconferencias, aulas en línea y transmisiones en vivo, la sensibilidad debe ajustarse, principalmente en relación con el módulo de estimación de jitter. .La sensibilidad;
- En la escena de transmisión en vivo, dado que la sensibilidad de retardo puede estar por encima del segundo nivel, la función StreamMode debe habilitarse (parece que se eliminó en la nueva versión) y los parámetros deben adaptarse;
- Con el objetivo de lograr una latencia extremadamente baja, el búfer de paquetes original es demasiado pequeño, lo que es fácil de eliminar y debe ajustarse más grande de acuerdo con las necesidades comerciales;
- También hay algunas empresas que identifican activamente las condiciones de la red de acuerdo con sus propios escenarios comerciales, y luego establecen directamente el nivel mínimo de TargetLevel para controlar el nivel de agua NetEQ de manera simple y grosera.
Optimización contra la pérdida de paquetes de NetEQ:
- El mecanismo de activación de solicitud de pérdida de paquetes Nack del WebRTC original se activa mediante paquetes, lo que deteriorará el efecto de retransmisión en una red débil y se puede cambiar a un activador de temporización para resolverlo;
- Habrá retransmisión en el escenario de pérdida de paquetes, pero si el búfer es demasiado pequeño, la retransmisión también se descartará. Por lo tanto, para mejorar la eficiencia de la retransmisión, agregar la función de reserva de retardo ARQ puede reducir significativamente la tasa de estiramiento;
- La optimización del nivel de algoritmo de comparación es optimizar el algoritmo del PLC para la compensación de pérdida de paquetes, ajustar el mecanismo de estiramiento NetEQ existente y optimizar el efecto auditivo;
- Después de habilitar la función Dtx de Opus, el búfer de audio se hará más grande en el escenario de pérdida de paquetes, y la lógica de procesamiento relacionada con Dtx debe optimizarse por separado.
La siguiente es una comparación de los efectos después de que se activa la función de reserva de demora ARQ. La tasa de estiramiento promedio se reduce en un 50% y la demora aumentará en consecuencia:
Optimización de la sincronización de audio y video:
- El algoritmo original de sincronización de audio y video WebRTC P2P no es un problema, pero la arquitectura actual generalmente tiene un servidor de reenvío de medios (SFU), y el algoritmo de generación de paquetes SR del servidor puede no ser completamente correcto debido a algunas restricciones o errores, lo que resulta en falla Sincronización normal, para evitar errores de generación de paquetes SR, es necesario optimizar el método de cálculo del módulo de sincronización de audio y video, y el nivel del agua se utiliza como referencia principal para la sincronización, es decir, el tiempo de búfer de audio y se garantiza que el video sea del mismo tamaño en el extremo receptor. La siguiente es una comparación de los efectos de optimización:
- También existe un problema de sincronización de audio y video. De hecho, no es causado por el mecanismo de sincronización de audio y video, pero el rendimiento del dispositivo no puede procesar la decodificación y reproducción del video a tiempo, lo que resulta en la acumulación de los datos de vídeo y el audio y el vídeo resultantes no están sincronizados. Este tipo de problema se puede comparar con la tendencia de la duración fuera de sincronización y la tendencia de la duración de la decodificación y reproducción de video. El grado de coincidencia entre los dos será muy alto, como se muestra en la siguiente figura:
para resumir
NetEQ, como la función principal del lado de recepción de audio , básicamente incluye todos los aspectos, por lo que muchas, muchas tecnologías de comunicación de audio y video tendrán sus rastros. Aprovechando el hecho de que WebRTC ha sido de código abierto durante casi 10 años, NetEQ se ha convertido en Espero que este artículo en lengua vernácula pueda ayudarlo a comprender mejor NetEQ.
Palabras finales del autor: ¡La demanda no se detiene, la optimización es infinita!
"Tecnología de Video Cloud" Su cuenta pública de tecnología de audio y video más destacada, publica artículos técnicos prácticos desde la primera línea de Alibaba Cloud cada semana, e intercambia e intercambia con ingenieros de primera clase en el campo del audio y video.