Autores: Li Chenguang, Kuang Jianxin, Chen Jianping
Epílogo:
Según el "Informe estadístico sobre el estado de desarrollo de Internet de China" publicado por el Centro de información de la red de Internet de China, en junio de 2022, la cantidad de usuarios de transmisiones web en vivo en mi país alcanzó los 716 millones, lo que representa el 68,1 % del total de usuarios de Internet. La razón principal es que durante la epidemia de 2020, la cantidad de personas que trabajan desde casa y disfrutan del ocio y el entretenimiento ha aumentado, y la transmisión interactiva en vivo de los nuevos medios se ha convertido en uno de los métodos de ocio y entretenimiento más importantes para la mayoría de los internautas.
Con la continua expansión y mejora de la cadena de la industria de la transmisión en vivo, la división del trabajo en cada eslabón de la cadena de la industria relevante se ha aclarado gradualmente y el número de participantes en cada eslabón ha aumentado gradualmente, para satisfacer las diferentes necesidades de empleo y liderar a un aumento en el número de empleados relacionados, la mejora y transformación de las industrias tradicionales se potenciará a través de la transmisión en vivo. E integre e innove con alta tecnología para optimizar el modelo comercial de las industrias tradicionales, como transmisión en vivo con bienes, transformación de nuevos medios publicitarios, etc.
La rica cultura tradicional, las noticias, los deportes competitivos, la ley, el intercambio de conocimientos y otros contenidos se pueden mostrar y difundir de manera más eficiente en forma de transmisión en vivo interactiva móvil, que no solo permite que el contenido de transmisión en vivo de alta calidad logre una difusión explosiva, sino que también permite los usuarios tienen más Hay más oportunidades de experimentar, aprender e incluso participar activamente en la interacción de transmisión en vivo, a fin de lograr una situación en la que todos ganan tanto para el lado de la oferta de contenido como para la difusión de la demanda.
Se puede decir que la tecnología de transmisión en vivo de latencia ultrabaja se está embarcando en un nuevo camino de desarrollo. InfoQ se unirá al equipo de transmisión en vivo de video de Volcano Engine para lanzar la serie "La evolución de la tecnología de transmisión en vivo de latencia ultrabaja", que lo llevará a explorar la evolución de la tecnología de transmisión en vivo de latencia ultrabaja, revelar los desafíos y avances detrás de él, y su impacto en la futura industria de la transmisión en vivo.
En el artículo de hoy, hablemos sobre el pasado y el presente de la tecnología de transmisión en vivo de latencia ultrabaja ~
Factores como las actualizaciones de la infraestructura de red, las iteraciones de la tecnología de transmisión de audio y video y el código abierto de WebRTC han hecho que los retrasos en los servicios de audio y video disminuyan gradualmente, lo que hace que la tecnología de transmisión en vivo de latencia ultrabaja sea una dirección de investigación candente. Los servicios de audio y video en tiempo real están en auge en el campo de Internet para consumidores y están penetrando gradualmente en el campo de Internet industrial. Después de experimentar la primera ronda de brotes de dividendos de la industria, la eficiencia de la escena de la industria de audio y video en tiempo real de China se profundizó gradualmente y entró en una etapa de crecimiento racional.
La selección de indicadores de retraso depende en gran medida del grado de acoplamiento de la interacción entre los usuarios y los productores de contenido, y los escenarios son ricos y variados.
En estos escenarios extremos, se espera que el retraso del lado del usuario sea lo más pequeño posible. El modo de baja latencia cercano a la comunicación en tiempo real puede maximizar el sentido de participación del usuario, interactuar sin problemas con los productores de contenido y movilizar lo que ven los usuarios. La positividad resultante. Por ejemplo, en los enlaces clave de PK, entrega de obsequios, clasificaciones sindicales y actividades gratificantes en el show de presentadores, los jugadores de gran valor agregado en ambos lados de la competencia esperan observar en tiempo real la reacción de sus propios presentadores después los obsequios se deslizan en la lista, para brindar apoyo al equipo de toma de decisiones de operación de fondo o seguimiento La estrategia de actividad proporciona la retroalimentación de información por primera vez.
La siguiente figura refleja la consideración integral del papel de la tecnología de transmisión en vivo de baja latencia desde la perspectiva de la tecnología/producto/operación; el impacto de los cambios tecnológicos en todo el ciclo ecológico positivo desde factores integrales externos e internos.
(1) Limitaciones de la tecnología de transmisión en vivo estándar tradicional
1. El problema del retraso del protocolo RTMP
El protocolo RTMP es el protocolo de transmisión en vivo más tradicional. El presentador usa el protocolo RTMP para enviar datos de audio y video codificados en H.264/5 y AAC al servidor CDN del proveedor de la nube para su reempaquetado y distribución. El retraso de extremo a extremo es generalmente controlado dentro de 3 a 7 segundos. El problema es que hay defectos en la escalabilidad de RTMP y hay ciertas dificultades técnicas para investigar más a fondo el retraso. En el caso del protocolo RTMP: Para cumplir con la reducción de demora, el búfer de descarga del reproductor debe comprimirse, lo que provocará un problema de congelación significativo, haciendo que la reproducción se vea y se sienta incómoda (la demora cae por debajo de los 2 segundos).
2. Las deficiencias de la tecnología tradicional de transmisión en vivo en escenarios interactivos en tiempo real
Hay una diferencia significativa entre el retraso del video y el retraso de la interacción de bombardeo, y la interacción del contenido del chat problemático no coincide con el ritmo de la imagen de transmisión del video;
La forma de interacción entre la audiencia y el presentador es única, y la transmisión de contenido unidireccional no puede ser bidireccional (no se puede resolver de manera significativa antes de la introducción de la tecnología RTC).
La limitación de la conducción unidireccional se manifiesta en el primer aspecto: la transmisión de flujo continuo en el extremo del espectador no se puede ajustar de forma adaptativa según las condiciones de la red. Los usuarios solo pueden realizar la transmisión de medios de transmisión a una velocidad de bits fija y no pueden lograr una percepción dinámica. En escenarios donde las condiciones de la red cambian en tiempo real (como redes débiles, conmutación de estación base móvil, etc.), la transmisión de velocidad de bits unidireccional fija tiene una alta probabilidad de causar pérdida de fotogramas y congelamiento Otros factores afectan la experiencia de visualización; por otro lado, cuando las condiciones de la red son mejores, la transmisión de tasa de bits fija no puede aumentar dinámicamente la tasa de bits de transmisión de video (una calidad de imagen más alta brinda una experiencia más cómoda )
En la escena de transmisión en vivo interactiva donde coexisten la transmisión en vivo y la escena conectada al micrófono, el presentador usa el RTMP tradicional para impulsar la transmisión. Cuando se encuentre con la escena PK conectada al micrófono, habrá un problema de cambio entre la transmisión push/local. transmisión conectada al micrófono/transmisión conectada al micrófono del servidor. El cambio hará que la audiencia tenga un problema de congelación momentánea; si se adopta la solución de transmisión en vivo de latencia ultrabaja basada en la tecnología de transmisión en vivo webRTC, este tipo de transmisión push- El problema del interruptor de combinación de lógica de micrófono conectado se puede resolver de manera más amigable (solo es necesario cambiar el reenvío del servidor: la lógica de distribución de suscribirse al canal de flujo, no implica el cambio de programación de derivación del flujo de datos de medios de transmisión push).
3. La diferencia entre la transmisión en vivo de latencia ultrabaja y la transmisión en vivo estándar
La transmisión en vivo de latencia ultrabaja es un nuevo tipo de aplicación que ha surgido en los últimos años. Escenarios como la transmisión en vivo de comercio electrónico y la transmisión en vivo de eventos tienen las características de alta simultaneidad y baja latencia. El retraso de 3 a 20 segundos de la transmisión en vivo tradicional es difícil de satisfacer sus necesidades, pero los requisitos para la interacción en tiempo real no son tan buenos. como las aplicaciones típicas de audio y video en tiempo real, como las videoconferencias, no es necesario reducir la latencia por debajo de los 400 ms. Con este fin, la transmisión en vivo de latencia ultrabaja integra la arquitectura técnica de la transmisión en vivo tradicional y el audio y video en tiempo real, y se da cuenta de la demora de extremo a extremo entre los dos aprendiendo unos de otros. Aunque no existe una ruta técnica estándar para los fabricantes de transmisión en vivo de latencia ultrabaja, se puede resumir aproximadamente como la transformación del protocolo de transmisión, la arquitectura de red y el protocolo de transmisión.En el proceso de aplicación real, los fabricantes equilibrarán los factores de costo y rendimiento. como métricas para elegir entre diferentes protocolos y arquitecturas de red.
La diferencia absoluta del protocolo de la capa de transporte (optimización de la confiabilidad basada en el protocolo UDP, que proporciona una base para contramedidas de red débil)
La transmisión en vivo tradicional FLV/RTMP utiliza el protocolo TCP (o protocolo QUIC), que es un protocolo de transmisión confiable que sacrifica la transmisión en tiempo real a cambio de la integridad de los datos. En un entorno de red débil, la conexión de "apretón de manos de tres vías" antes de la transmisión de datos traerá un gran retraso. Como protocolo de transmisión poco confiable, UDP tiene la mayor ventaja de un alto rendimiento en tiempo real, pero no garantiza la llegada y secuenciación de datos. Los productos de audio y video en tiempo real (como RTM **** transmisión en vivo de latencia ultra baja ) a menudo usan el protocolo UDP y optimizan la capa de protocolo y la capa de algoritmo encima para mejorar la confiabilidad y la lógica de transmisión.
Optimización del protocolo UDP :
El protocolo UDP aparece a menudo en aplicaciones prácticas junto con el protocolo RTP/RTCP. RTP es responsable de la transmisión de datos, y el número de serie, el tipo de puerto, la marca de tiempo y otros campos en el encabezado del protocolo pueden proporcionar una base lógica para agrupar, ensamblar y clasificar los paquetes de datos; RTCP, como protocolo de control de RTP, es responsable de las estadísticas sobre la calidad de transmisión de RTP Feedback, y proporciona parámetros de control para contramedidas de red débil.
(2) Evolución de la tecnología de transmisión en vivo de latencia ultrabaja
El proceso de evolución de la tecnología de transmisión en vivo basado en el desarrollo de escenarios comerciales ( línea principal retrasada )
Evolución del propio protocolo RTM
a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp" a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime" a=extmap:21 "uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range" a=extmap:22 "uri:webrtc:rtc:rtp-hdrext:video:frame-type" a=extmap:23 "uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp" a=extmap:27 "uri:webrtc:rtc:rtp-hdrext:audio:aac-config"a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:Tiempo de composición"
a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range
a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:tipo de cuadro
a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp
a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config
RTP usa el encabezado de extensión privada RTP para transportar el valor DTS/CTS, y cada trama del paquete de datos RTP transporta el valor DTS de la trama a través del encabezado de extensión RFC5285-Header-Extension, y el primer paquete RTP y VPS/SPS/PPS El paquete de cada trama pasa el RFC5285: el encabezado de extensión de extensión de encabezado lleva el valor CTS de la trama, y la marca de tiempo de la trama actual se calcula mediante PTS = DTS + CTS. Se utiliza para iniciar la sincronización rápida de audio y video y la sincronización precisa de audio y video de la lógica de control de reproducción del reproductor .
El encabezado de extensión lleva el número de secuencia de inicio/fin de la trama: si se pierden los primeros paquetes de la primera trama, la retransmisión puede iniciarse rápidamente de acuerdo con el número de secuencia de inicio para acelerar la primera trama; si los últimos paquetes de el cuadro actual se pierde, luego el número de secuencia final inicia rápidamente la retransmisión, lo que reduce la demora y la tartamudez .
El tipo de trama transportada por el encabezado de extensión: si se transporta y analiza el tipo de trama correcto, el cliente no necesita analizar los metadatos; al mismo tiempo, en una situación de red débil, el cliente puede omitir la trama B y directamente decodificar el cuadro P, acelerando la salida del cuadro y reduciendo posibles bloqueos .
El encabezado de extensión lleva la información del marco de referencia del marco P: si ocurre una situación de red débil, el cliente puede omitir la decodificación **** del marco B de acuerdo con la relación del marco de referencia especificada por el encabezado de extensión y su marca de tiempo correspondiente para reducir la aparición de tartamudeo .
Para acelerar la interacción de señalización, la CDN puede devolver directamente las capacidades de audio y video admitidas al cliente sin consultar la información de los medios bajo ciertas condiciones; en este momento, la descripción de los medios del SDP no contendrá una configuración específica de audio y video. detalles En el nivel de audio, el AnswerSDP no contiene la información de encabezado requerida para la decodificación aac en este momento; en este momento, necesitamos adoptar el modo de encabezado de extensión RTP para transportar AAC-Config para que el cliente analice y procese la acción de decodificación por sí mismo al recibir el paquete RTP, que es reducir la señal Reducir el tiempo de interacción y aumentar la tasa de éxito de la transmisión .
Parte de implementación del estándar de señalización MiniSDP (Douyin)
Señalización CDN asíncrona de regreso al origen
RTP lleva componentes de encabezado de extensión
1. Trasplante de protocolo WebRTC en reproductor de transmisión en vivo
La transmisión en vivo de baja latencia RTM se basa en la tecnología WebRTC, y la construcción de la transmisión punto a punto basada en el estándar WebRTC generalmente tiene los siguientes pasos:
Las partes de la comunicación deben llevar a cabo la negociación de medios, y la especificación detallada de la sesión es la interacción SDP (Protocolo de descripción de sesión);
Luego realice una negociación interactiva de direcciones de red (consulte la dirección IP real del par) para prepararse para construir un canal de transmisión de medios;
Cuando las condiciones anteriores estén listas, entrará en la transmisión de datos de medios punto a punto punto a punto final.
El cliente-servidor de la parte de señalización se desarrolla por separado, utilizando el modo de mensaje estándar SDP; la parte de transmisión de medios utiliza el marco WebRTC de código abierto y el motor de medios de audio y video en tiempo real desarrollado por Byte para la transmisión de medios.
2. Actualización del protocolo de señalización RTC **** (protocolo de compresión MiniSDP )
https://github.com/zhzane/mini_sdp
El SDP estándar es relativamente largo (alrededor de 5-10 KB), lo que no favorece una transmisión rápida y eficiente. En escenarios de transmisión en vivo, afectará especialmente el tiempo del primer cuadro. MiniSDP realiza una compresión de alto rendimiento en el protocolo de texto SDP estándar, convierte SDP nativo en un formato binario más pequeño y permite que se transmita a través de un paquete UDP.
Reduzca el tiempo de interacción de señalización, mejore la eficiencia de transmisión de la red, reduzca el tiempo de renderizado del primer cuadro de transmisión en vivo y mejore los indicadores estadísticos de QoS, como la segunda tasa de apertura/tasa de éxito de la transmisión.
| acuerdo de juego | Señalización RTM-HTTP | Señalización RTM-MiniSDP | FLV |
|---|---|---|---|
| Tiempo del primer cuadro (vista previa) | 600ms | 510ms | 350ms |
| Tasa de éxito de transmisión (versión preliminar) | 97,50% | 98,00% | 98,70% |
3. Optimización asincrónica de regreso a la fuente de CDN para señalización RTM ****
Reduzca el tiempo de interacción de la señalización RTM y el tiempo de renderizado del primer cuadro de la transmisión RTM.
En el proceso original, cuando la memoria caché del servidor falla, debe esperar a que la fuente obtenga los datos antes de devolver el AnswerSDP con la información de AacConfig. El cliente envía STUN después de recibir AnswerSDP y el servidor solo puede comenzar a enviar datos después de recibir STUN. (Como se muestra a la izquierda en la figura a continuación); en el caso de back-to-source asíncrono: el servidor ya no espera el resultado de back-to-source y devuelve directamente AnswerSDP, después de lo cual el back-to-source y Los procesos de establecimiento de conexión WebRTC proceden de forma síncrona. Espere hasta que la conexión WebRTC se establezca con éxito y los datos se devuelvan a la fuente, y los datos RTP se enviarán de inmediato. (Como se muestra a la derecha en la siguiente figura)
4. Optimización de la congelación de reproducción de video (la congelación de 100 segundos se reduce en 4 segundos en promedio)
Mejore el tiempo de visualización per cápita, cambie la estrategia de encuadre/decodificación del motor RTC, prohíba la pérdida de fotogramas del RTC en modo de baja latencia y mejore la congelación de la reproducción de video en vivo.
| grupo de prueba | La reproducción de video se congela durante 100 segundos (escena de la sala en vivo) |
|---|---|
| Estrategia JitterBuffer predeterminada de RTM | 8.3s |
| RTM mejoró la estrategia JitterBuffer non-drop frame | 3,6 s |
En la escena RTC tradicional, la prioridad es garantizar el retraso, y todo el enlace desencadenará varias pérdidas de tramas (incluidos, entre otros, el módulo de decodificación, el módulo de red), y la escena de transmisión en vivo de FLV dará prioridad a garantizar la Experiencia de visualización (sin pérdida de fotogramas, buen efecto de sincronización de audio y vídeo). Si RTM quiere reducir el retraso y obtener beneficios qoe, la estrategia de control de transmisión debe personalizarse y los puntos de modificación de lógica personalizados son los siguientes:
Para garantizar que el jitterbuffer no sea bloqueado por otras operaciones de la API, como la descodificación lenta de la solución suave o el dequeuinputbuffer de la solución dura, la capa del kernel tiene una capa de lógica de sincronización de audio y video obligatoria para garantizar que el audio y experiencia de reproducción de video;
Al mismo tiempo, la capa superior está monitoreando la longitud del búfer del módulo de red y el módulo de decodificación, y tiene la lógica ascendente correspondiente:
Al juzgar que la solución dura no se puede resolver, hay demasiados dec_cache_frames, se informa un error y se degradará a la solución suave;
El jitterbuffer es anormal y hay demasiados frame_lists en el caché, lo que activa la lógica anormal del reproductor, informa un error y extrae la transmisión nuevamente.
5. Optimización de la lógica de control de reproducción RTM
Para mejorar la penetración de la visualización y transmisión móvil, la solución de kernel unificado de RTC tiene fallas inherentes (el decodificador de hardware MediaCodec tarda mucho tiempo en inicializarse); el módulo de decodificación de video RTM se migra del kernel RTC al kernel de reproducción TTMP, y el Módulo de decodificación de video FLV (MediaCodec Evite la reinicialización); reduce significativamente el tiempo de procesamiento del primer cuadro de la plataforma Android y mejora la tasa de éxito de la transmisión.
Lógica general del núcleo RTC
Lógica de control de transmisión central RTM mejorada
Lo anterior es todo el contenido de la evolución de la tecnología de transmisión en vivo de latencia ultrabaja "Evolución".En el segundo "capítulo práctico", nos centraremos en cómo implementar la tecnología de transmisión en vivo de latencia ultrabaja a gran escala. Por favor sigue prestando atención~