Hola a todos y bienvenidos al canal Stop Refactoring.
En este número, analizamos en detalle los protocolos relacionados con la transmisión en vivo , incluidos: HTTP-FLV, HLS, RTMP, Web-RTC, RTSP, etc.
Presentaremos en detalle cómo funcionan estos protocolos, sus escenarios de aplicación y las razones del retraso.
Discutimos en este orden
1, RTMP, HTTP-FLV
2, HLS
3, Web-RTC
4, RTSP
RTMP, protocolo HTTP-FLV
Tanto RTMP como HTTP-FLV se basan en la encapsulación FLV.
RTMP se usa generalmente para transmisión en vivo , y HTTP-FLV generalmente se usa para visualización en vivo .
Hablemos primero de RTMP El protocolo RTMP es un protocolo que puede enviar y extraer flujos .
La dirección RTMP comienza con rtmp:// y la dirección de transmisión es la misma que la dirección de reproducción.
Sin embargo, debido a que el navegador ha abandonado el reproductor Flash y se dice que puede haber algunos problemas inestables con alta concurrencia, RTMP generalmente solo se usa para escenarios como la transmisión desde fuentes en vivo y la transmisión a CDN en vivo .
El protocolo RTMP requiere un software de servicio de transmisión específico , como SRS, Nginx con complementos RTMP, etc.
Como se discutió en el principio de funcionamiento de la transmisión en vivo en el pasado, este tipo de software de servicio de transmisión de medios es en realidad una estación de transferencia de datos de audio y video. Generalmente, los datos solo se sobrescriben cíclicamente en la memoria y no se escribirán en el disco. .
El retraso del protocolo RTMP es relativamente bajo, alrededor de 1-3 segundos.
La comunicación RTMP se establece en el canal de conexión largo TCP.Al encapsular datos de audio y video, los segmentos se ven obligados a limitar el tamaño de cada paquete de datos.
El corte obligatorio también garantiza el rendimiento en tiempo real hasta cierto punto. Existe cierta capacidad para resistir redes débiles, porque cada paquete de datos no será demasiado grande, por lo que cuando un paquete de datos no se verifica, el costo de reenviar no será demasiado grande, pero también porque la fusión de paquetes de datos aumentará la presión de la CPU. por lo que hay un cierto consumo de rendimiento.
También hay algunas variantes del protocolo RTMP, como RTMPT, RTMPS, etc., que no se discutirán aquí.
Analicemos nuevamente el protocolo HTTP-FLV .
La dirección comienza con http://, que se basa en el protocolo HTTP. HTTP-FLV puede entenderse simplemente como la versión del protocolo HTTP de RTMP . Las funciones y los principios de funcionamiento son similares, y la función de datos de segmento RTMP HTTP-FLV mencionada anteriormente también está disponible.
Sin embargo, el protocolo HTTP-FLV generalmente solo se puede usar para la visualización en streaming .
El retraso del protocolo HTTP-FLV también es relativamente bajo, entre 1 y 3 segundos , pero la experiencia real muestra que el retraso de HTTP-FLV es ligeramente mayor que el de RTMP, pero HTTP-FLV es más adecuado para escenarios de juego que RTMP.
La transmisión en vivo HTTP-FLV generalmente debe reproducirse agregando un complemento. Por ejemplo, la página web debe importar flv.js antes de que el navegador pueda reproducirlo. Transmisión en vivo de HTTP-FLV, aquí debemos agradecer al flv.js de código abierto de la estación B, que promueve la popularización de HTTP-FLV en los navegadores.
El protocolo HTTP-FLV requiere un software de servicio de transmisión específico , como Nginx con el complemento HTTP-FLV.
Vale la pena mencionar que el complemento HTTP-FLV de Nginx incluye la función RTMP, por lo que, en general, el servicio de medios de transmisión HTTP-FLV, la transmisión push usa el protocolo RTMP y la transmisión pull usa el protocolo HTTP-FLV.
La solución más popular ahora es que la fuente de transmisión en vivo impulsa la transmisión usando el protocolo RTMP, y el reloj de transmisión en vivo usa el protocolo HTTP-FLV.
protocolo HLS
El protocolo HLS generalmente solo se usa para la visualización de transmisión, pero estrictamente hablando, el protocolo HLS no es un protocolo de transmisión.
Funciona simplemente descargando archivos estáticos a través del protocolo HTTP .
La diferencia es que el archivo del protocolo HLS consta de dos partes , una es múltiples archivos de video fragmentados .ts con una duración de solo unos segundos, y el otro es el archivo de índice .m3u8 que registra las direcciones de estos archivos de video , y estos archivos estáticos se escriben directamente en el disco.
Más específicamente, la dirección de visualización de HLS comienza con http:// y termina con .m3u8. De hecho, esta dirección es la dirección del archivo de índice. Una vez que el cliente obtiene el archivo de índice, puede descargar el archivo de video fragmentado correspondiente y comenzar jugarlo.
Dado que el protocolo HLS en realidad solicita archivos a través del protocolo HTTP, y los archivos relacionados con HLS se escriben directamente en el disco, no requiere ningún software de servicio de transmisión especial y los servicios HTTP como Nginx son suficientes .
El protocolo HLS se puede usar para visualización bajo demanda y en vivo . Es adecuado para una variedad de escenarios de reproducción. Generalmente, se puede reproducir agregando un complemento. Por ejemplo, se puede reproducir una página web agregando un HLS. js. Los dispositivos Apple admiten de forma nativa el protocolo HLS.
En el escenario bajo demanda , es decir, en el escenario de la visualización ordinaria de videos en línea.
El archivo de índice .m3u8 registrará las direcciones de todos los archivos de video fragmentados. HLS tiene ventajas más obvias en escenarios bajo demanda .
Dado que los archivos relacionados de HLS son archivos estáticos sin estado y el tamaño de cada archivo es limitado, los efectos del equilibrio de carga y la aceleración de CDN son más evidentes.
Los videos a pedido del protocolo HLS se reproducirán más rápido que los videos .mp4 y .flv, y los saltos de video durante la carga serán más fluidos.
En el escenario de transmisión en vivo , el software de transcodificación puede generar directamente archivos relacionados con HLS en el disco y el cliente puede descargar los archivos a través del servicio HTTP.
Además, también se puede agregar un complemento RTMP a Nginx, y el software de transcodificación envía la transmisión a Nginx a través del protocolo RTMP, y luego Nginx genera archivos relacionados con HLS.
Entre ellos, se recomienda más la última solución , porque es más fluida para la transición de la etapa inicial de I+D y la CDN en vivo posterior al acoplamiento.
Además, los archivos relacionados con HLS en la escena de transmisión en vivo son algo diferentes de los que se encuentran bajo demanda .
Los datos de transmisión de video se empaquetarán en un archivo de video fragmentado con el sufijo .ts cada pocos segundos, y el archivo de índice .m3u8 se actualizará sincrónicamente cada vez que se genere un nuevo archivo de video .
Y hay un límite superior para la cantidad de archivos de video fragmentados . Cuando se alcanza el límite superior, el archivo de video más antiguo se eliminará de forma predeterminada y el archivo de índice .m3u8 se actualizará.
Por lo tanto, en el escenario de transmisión en vivo, el cliente también necesita volver a adquirir constantemente el archivo de índice .m3u8.
El protocolo HLS no tiene ventajas en escenarios de transmisión en vivo.
Aunque la transmisión en vivo del protocolo HLS también puede adaptarse a muchos escenarios de reproducción, debido a la necesidad de generar archivos estáticos, el retraso de transmisión en vivo es muy grande , alrededor de 5-30 segundos.Si usa un CDN en vivo, debido al nodo de borde sincronización y otros problemas, el retraso de la transmisión en vivo puede incluso ser posible. Alcanzará aproximadamente 1 minuto.
Por supuesto, el protocolo HLS también tiene ciertas ventajas: en transmisión en vivo, es decir, transmisión en vivo a pedido, o transmisión grabada, es decir, transmisión en vivo a pedido, teóricamente solo necesita modificar el archivo de índice.
Además, el archivo de índice .m3u8 del protocolo HLS admite la indexación , es decir, se pueden integrar múltiples direcciones de visualización como alta definición, definición estándar y suave en un archivo de índice. El reproductor puede cambiar automáticamente entre diferentes direcciones de visualización de acuerdo con el ancho de banda actual, y el "automático" de la mayoría de los reproductores web también se debe a esto.
Aquí hay un pequeño punto de conocimiento del protocolo HLS.
Dado que los archivos de video y los archivos de índice del protocolo HLS se escriben directamente en el disco, si se procesan varias transmisiones en vivo al mismo tiempo durante mucho tiempo, se producirá una presión de escritura excesiva en el disco , el disco mecánico puede dañarse. y la vida útil de la unidad de estado sólido acelerará el deterioro.
En este caso, es mejor montar una sección de espacio de memoria como ubicación de escritura de archivos relacionados con HLS, lo que no causará una presión de escritura excesiva en el disco.
Como complemento, el protocolo HLS es un estándar introducido por Apple. Similar al protocolo HLS, también existe el protocolo MPEG-DASH. Los principios de funcionamiento de HLS y MPEG-DASH son similares, pero algunos estándares son diferentes, así que gané No ampliar aquí.
Protocolo WebRTC
El protocolo WebRTC en realidad no está diseñado para escenarios de transmisión en vivo.WebRTC es un protocolo de video/llamada de voz punto a punto.
Dado que WebRTC se basa en UDP, una vez que se establece la comunicación, los datos se enviarán continuamente en un flujo, por lo que la demora será menor que RTMP.
En algunos escenarios de transmisión en vivo altamente interactivos , como transmisión en vivo con bienes, etc., WebRTC se usará como protocolo de transmisión y visualización. El retraso de WebRTC teóricamente puede llegar a 1 segundo.
El protocolo WebRTC admite flujos de inserción y extracción. La dirección generalmente comienza con webrtc://, y las direcciones de flujo de inserción y extracción son generalmente las mismas.
Aunque WebRTC es un protocolo punto a punto, si se aplica en una escena de transmisión en vivo, es necesario construir un servidor WebRTC como un servicio de transmisión , y el software del servicio de transmisión puede usar SRS.
Por cierto, SRS es un software de servicio de transmisión de medios de código abierto relativamente popular desarrollado en China. En la actualidad, 4.0 ha incluido protocolos convencionales como RTMP, HLS, WebRTC y HTTP-FLV.
Protocolo RTSP
RTSP generalmente no se usa para escenarios de transmisión en vivo , y RTSP generalmente se usa para ver y enviar transmisiones de video en tiempo real de dispositivos de hardware como cámaras y monitoreo.
Aunque el protocolo RTSP también admite flujos push/pull, y admite TCP, conmutación UDP y muchas otras ventajas.
Pero la versatilidad es insuficiente, especialmente los navegadores actuales no admiten la reproducción RTSP.
Resumir
Lo anterior es una introducción a los protocolos de transmisión en vivo de uso común. Los retrasos mencionados son retrasos de comunicación puros . Si desea ver todo el proceso de transmisión en vivo, el retraso se amplificará aún más.
Debido a que la demora de transmisión en vivo incluye demora de inserción, demora de transcodificación y demora de extracción, incluso si se utiliza WebRTC como protocolo de inserción y extracción, la demora final será de unos segundos.
En cuanto al problema del retraso en la transmisión en vivo, aunque los acuerdos anteriores juegan un papel clave, a menudo no juegan un papel absoluto.
La reducción del retraso de la transmisión en vivo implicará muchos problemas. Por ejemplo, cuestiones detalladas como la prohibición de fotogramas B, la aceleración de hardware de la GPU, el almacenamiento en caché de fotogramas I en los servicios de transmisión de medios, las restricciones de velocidad de bits, etc., se analizarán en detalle más adelante.