HTTP Live Streaming ( HLS para abreviar ) es un protocolo de transmisión de red de medios de transmisión basado en HTTP propuesto por Apple. es parte de los sistemas de software QuickTime X y iPhone de Apple. Funciona dividiendo todo el flujo en pequeños archivos basados en HTTP para su descarga, solo unos pocos a la vez. Mientras se reproduce un flujo de medios, el cliente puede optar por descargar el mismo recurso a diferentes velocidades desde muchas fuentes alternativas diferentes, lo que permite que la sesión de transmisión se adapte a diferentes velocidades de datos.
Al iniciar una sesión de transmisión, el cliente descarga un archivo M3U (m3u8) extendido que contiene metadatos para encontrar transmisiones de medios disponibles.
HLS solo solicita paquetes HTTP básicos, y HLS puede pasar a través de cualquier firewall o servidor proxy que permita el paso de datos HTTP. También es fácil usar redes de entrega de contenido para entregar flujos de medios.
Explicación detallada del protocolo HLS
El protocolo HLS estipula
- El formato del paquete de video es TS.
- El formato de codificación del video es H264 y el formato de codificación del audio es MP3, AAC o AC-3.
- Además del propio archivo de video TS, también se define el archivo m3u8 (archivo de texto) utilizado para controlar la reproducción.
La lógica para que el cliente reproduzca el flujo de video HLS es realmente muy simple. Primero, descargue el archivo de índice de primer nivel, que registra la dirección del archivo de índice de segundo nivel (Alternativo-A, Alternativo-B, Alternativo-C) , y luego el cliente descarga el archivo de índice de segundo nivel. El archivo de índice de primer nivel y la dirección de descarga del archivo TS se registran en el archivo de índice de segundo nivel, para que el cliente pueda descargar los archivos de video TS en orden y reprodúzcalos continuamente.
Archivo de índice de primer nivel
HLS proporciona una dirección m3u8 y el navegador Safari de Apple puede abrir directamente la dirección m3u8, por ejemplo:
https://dco4urblvsasc.cloudfront.net/811/81095_ywfZjAuP/game/index.m3u8
Android不能直接打开，需要使用html5的video标签，然后在浏览器中打开这个页面即可，譬如：
```css
<!-- livestream.html -->
<video width="640" height="360"
autoplay controls autobuffer
src="https://dco4urblvsasc.cloudfront.net/811/81095_ywfZjAuP/game/index.m3u8"
type="application/vnd.apple.mpegurl">
</video>
Y después de abrir el archivo m3u8, el contenido es el siguiente:
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1064000
1000kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=564000
500kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=282000
250kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2128000
2000kbps.m3u8
El ancho de banda especifica la tasa de bits del flujo de video.
PROGRAM-ID es inútil y no necesita preocuparse.
La siguiente línea de cada #EXT-X-STREAM-INF es la ruta del archivo de índice secundario, que puede ser una ruta relativa o un camino absoluto. Los ejemplos usan rutas relativas. Este archivo registra las rutas del archivo de índice secundario de transmisiones de video con diferentes tasas de bits. El cliente puede juzgar su propio ancho de banda de red actual para decidir qué transmisión de video reproducir. También puede cambiar sin problemas a la transmisión de video que coincida con el ancho de banda cuando cambia el ancho de banda de la red.
Archivo de índice secundario
#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXTINF:10,
2000kbps-00001.ts
#EXTINF:10,
2000kbps-00002.ts
#EXTINF:10,
2000kbps-00003.ts
#EXTINF:10,
... ...
#EXTINF:10,
2000kbps-00099.ts
#EXTINF:10,
2000kbps-00100.ts
#ZEN-TOTAL-DURATION:999.66667
#ZEN-AVERAGE-BANDWIDTH:2190954
#ZEN-MAXIMUM-BANDWIDTH:3536205
#EXT-X-ENDLIST
El archivo secundario es en realidad responsable de dar la dirección de descarga del archivo ts, y aquí también se usa una ruta relativa.
-
La primera línea de cada archivo M3U de EXTM3U
debe ser esta etiqueta, que proporciona una función de marcado -
EXT-X-PLAYLIST-TYPE
#EXT-X-PLAYLIST-TYPE: VOD significa que la transmisión de video actual es una transmisión bajo demanda, lo que significa que se han generado todos los archivos ts del video. -
EXT-X-VERSION
se utiliza para marcar la versión del protocolo. Aquí hay 3, entonces aquí se usa la tercera versión del protocolo HLS, esta etiqueta solo puede tener 0 o 1. Si no se escribe, significa que se usa la versión 1. -
EXT-X-TARGETDURATION
#EXT-X-TARGETDURATION especifica la duración máxima de los archivos de segmentos en el flujo de video actual, es decir, la duración de estos ts segmentos no puede ser mayor que el valor de #EXT-X-TARGETDURATION. -
El número de secuencia de inicio del segmento EXT-X-MEDIA-SEQUENCE
. Cada sector tiene un número de secuencia único y el número de secuencia entre sectores adyacentes es +1. Este número seguirá aumentando para asegurar la continuidad del flujo. -
EXTINF
ts La duración real del segmento. duración : duración de los medios
#EXTINF <duration>,<title>
- EXT-X-ENDLIST
#EXT-X-ENDLIST El símbolo del final del archivo, que indica el final del video, ya no se agregan archivos multimedia al archivo de la lista de reproducción. Este signo también indica que la transmisión actual no es una transmisión en vivo.
modo de juego
La característica de VOD a pedido es que todos los archivos de índice y los archivos ts se pueden obtener en el punto de tiempo actual, y las direcciones de todos los archivos ts se registran en el archivo de índice secundario. Este modo permite a los clientes acceder a todo el contenido. El ejemplo anterior es una estructura m3u8 en modo bajo demanda.
El modo en vivo es para generar archivos M3u8 y ts en tiempo real. Su archivo de índice siempre cambia dinámicamente. Al reproducir, necesita descargar el archivo de índice secundario continuamente para obtener el último archivo ts generado para reproducir el video. Si no hay una marca #EXT-X-ENDLIST al final de un archivo de índice secundario, significa que es una transmisión de video en vivo.
Cuando el cliente está reproduciendo un video en modo VOD, solo necesita descargar el archivo de índice de primer nivel y el archivo de índice de segundo nivel una vez para obtener las direcciones de descarga de todos los archivos ts. no es necesario descargar ningún archivo de índice. Debe descargar los archivos ts secuencialmente y reproducirlos. Pero es ligeramente diferente en el modo en vivo, porque el nuevo archivo ts también se genera durante la reproducción, por lo que el cliente descarga el archivo de índice secundario una vez, luego descarga el archivo ts y luego descarga el archivo de índice secundario (esta vez el archivo de índice secundario). El archivo de índice se ha reescrito para registrar la dirección de descarga del archivo ts recién generado), y luego descargue el nuevo archivo ts y reprodúzcalo repetidamente.
Principales escenarios de aplicación de HLS
Multiplataforma : la principal solución de transmisión en vivo para PC es RTMP, y también hay algunas bibliotecas que pueden reproducir HLS, como jwplayer, y hay muchos complementos de hls basados en osmf. Entonces, de hecho, si elige un protocolo que puede cruzar PC/Android/IOS, es HLS.
Requisitos estrictos de estabilidad en IOS : HLS es, por supuesto, el más estable en IOS, y su estabilidad no es peor que la de RTMP en PC-flash.
Método de distribución de CDN amigable : en la actualidad, CDN también es el protocolo básico para RTMP, pero la base de la distribución de HLS es HTTP, por lo que el acceso y la distribución de CDN serán más perfectos que RTMP. Puede cambiar entre varios CDN y RTMP también, pero es posible que necesite una prueba de acoplamiento.
Simple : HLS es muy simple como protocolo de transmisión de medios y Apple lo admite perfectamente. El soporte de Android para HLS será cada vez más perfecto. En cuanto a DASH/HDS, no parece haber una razón especial, al igual que Linux se ha vuelto popular y abierto, y es difícil que otros sistemas se utilicen ampliamente.
HLS y RTMP
RTMP se refiere al RTMP (Protocolo de mensajes en tiempo real) de Adobe, que se usa ampliamente en la transmisión en vivo de baja latencia, y también es el protocolo estándar real para conectar codificadores y servidores. Tiene la mejor experiencia de visualización y la mejor estabilidad en PC (Flash) .
HLS es principalmente para solucionar algunos problemas existentes en el protocolo RTMP . Por ejemplo, el protocolo RTMP no utiliza la interfaz HTTP estándar para transmitir datos, por lo que el cortafuegos puede bloquearlo en algunos entornos de red especiales. Sin embargo, HLS transmite datos debido al protocolo HTTP utilizado
RTMP es un protocolo con estado, y es difícil expandir sin problemas el servidor de video, porque el estado debe mantenerse para cada cliente que reproduce la transmisión de video. HLS se basa en un protocolo sin estado (HTTP). El cliente solo usa y descarga archivos TS ordinarios almacenados en el servidor en orden, y el equilibrio de carga es tan simple como el equilibrio de carga de los servidores de archivos HTTP ordinarios.
Además , el propio protocolo HLS realiza la adaptación de la tasa de bits y los dispositivos con diferentes anchos de banda pueden cambiar automáticamente a la reproducción de video que mejor se adapte a su propia tasa de bits.
Sin embargo, HLS también tiene algunos problemas, por ejemplo, el retraso de video del protocolo HLS es relativamente grande, básicamente más de 10 segundos, mientras que el retraso del protocolo RTMP puede llegar a los 3 o 4 segundos.
Análisis del protocolo TS, parte 1 (PAT)
Análisis del protocolo TS, parte 2 (PMT)
Análisis del protocolo TS, parte 3 (PES)
Análisis del protocolo TS, parte 4 (campo de adaptación)