En los últimos años, el sector del streaming de vídeo ha experimentado un enorme interés por los protocolos de streaming de vídeo de baja latencia. La mayor parte del interés se centra en la transmisión de vídeos con un retardo inferior a cinco segundos, comparable al de los sistemas de televisión en directo. Conseguir un retardo tan bajo es fundamental para retransmitir deportes en directo, juegos, aprendizaje en línea y aplicaciones de vídeo interactivas, entre otros.
DESARROLLO DE LA TECNOLOGÍA DE STREAMING DE BAJA LATENCIA
Los retrasos en las tecnologías convencionales de streaming OTT en directo, como HLS y DASH, son mucho mayores. Están causados por segmentos relativamente largos (4-10 segundos) y un modelo de entrega basado en segmentos, que requiere la entrega completa de cada segmento multimedia antes de la reproducción. Combinado con las estrategias de almacenamiento en búfer utilizadas por los clientes de streaming HLS o DASH, esto suele producir retrasos de 10-30 segundos, o incluso más.
Para combatir los retrasos, las recientes evoluciones de las normas HLS y DASH, conocidas como Low-Latency HLS (LL-HLS) y Low-Latency DASH (LL-DASH), han introducido dos herramientas clave:
- Codificación de vídeo en trozos. Se trata de una estrategia de codificación que produce segmentos de vídeo estructurados como secuencias de subsegmentos o trozos mucho más cortos.
- Transferencia de segmentos fragmentados. Se trata de un modo de transferencia HTTP que permite la transmisión de trozos de vídeo más cortos a los clientes de streaming en cuanto se generan.
Un cliente de streaming puede unirse a un flujo en directo de baja latencia desde cualquier punto de acceso al flujo (SAP) que el transcodificador en directo ponga a su disposición en los límites de segmento o de trozo. Una vez conectado, el reproductor sólo tiene que almacenar en el búfer el último fragmento de vídeo generado por el codificador antes de descodificarlo y renderizarlo. Teniendo en cuenta que cada segmento puede dividirse en varios chunks (normalmente de 4 a 10), esto reduce significativamente el retardo.
Actualmente existen en el mercado varias implementaciones de servidores y reproductores de baja latencia, tanto de código abierto como patentados, entre ellos uno de Brightcove. Muchas de ellas han demostrado un menor retardo en la transmisión cuando sólo se utiliza un flujo de una tasa de bits y cuando transmiten a través de conexiones de red de alta velocidad. Sin embargo, su rendimiento en entornos de despliegue más complejos y realistas no ha sido bien estudiado.
COMPROBACIÓN DEL RENDIMIENTO DEL STREAMING DE BAJA LATENCIA
En nuestro artículo publicado en ACM Mile-High-Video 2023 (enlace de próxima publicación), así como en una presentación en Facebook@Scale, informamos de algunos resultados tras probar el rendimiento de los sistemas de vídeo de baja latencia.
En primer lugar, desarrollamos un banco de pruebas de evaluación para los sistemas LL-HLS y LL-DASH. A continuación, evaluamos varios reproductores de baja latencia utilizando este banco de pruebas, incluidos Dash.js, HLS.js, Shaka player y Theo player. También evaluamos varios de los últimos algoritmos de adaptación de bitrate con optimizaciones para reproductores en directo de baja latencia. La evaluación se basó en una serie de experimentos de streaming en directo. Estos experimentos se repitieron utilizando idénticos contenidos de vídeo, perfiles de codificación y condiciones de red (emuladas mediante el uso de trazas de redes del mundo real).
La tabla 1 muestra nuestros perfiles de codificación de vídeo en directo para generar el flujo DASH/HLS multibitrate y de baja latencia.
| Rendición | Resolución de vídeo (píxeles) | Códec de vídeo y perfil | Bitrate (kbps) |
|---|---|---|---|
| bajo | 768 x 432 | H.264 principal | 949 |
| mediados de | 1024 x 576 | H.264 principal | 1854 |
| alta | 1600 x 900 | H.264 principal | 3624 |
| top | 1920 x 1080 | H.264 principal | 5166 |
Tabla 1. Perfiles de codificación de vídeo en directo
La figura 1 muestra los flujos de trabajo de nuestros bancos de pruebas de streaming DASH y HLS de baja latencia.
Figura 1. Configuración del sistema utilizado para evaluar los reproductores de baja latencia.
La figura 2 muestra el ancho de banda disponible en nuestra red móvil LTE emulada. El ancho de banda de descarga de los reproductores de baja latencia está controlado por nuestra herramienta de emulación de red y las trazas de red.
Figura 2. Ancho de banda disponible de las redes móviles LTE emuladas (Verizon y T-Mobile) Ancho de banda disponible de redes móviles LTE emuladas (Verizon y T-Mobile)
En nuestros experimentos se capturaron y analizaron diversas métricas de rendimiento del sistema (tasa de bits media de los flujos, cantidad de datos multimedia descargados, latencia de los flujos), así como estadísticas de almacenamiento en búfer y conmutación de flujos.
Estos resultados se han utilizado posteriormente para describir las diferencias observadas en el rendimiento de los reproductores y sistemas LL-HLS y LL-DASH.
En las figuras siguientes se muestran algunos gráficos de nuestro estudio.
Figura 3. Dinámica de los cambios de bitrate notificados por los reproductores LL-HLS y LL-DASH.
Figura 4. Comparación de las variaciones de latencia notificadas por los reproductores LL-HLS y LL-DASH.
Estadísticas de rendimiento - Red LTE de T-Mobile
| Jugador/Algoritmo | Velocidad de bits media [kbps] | Altura media [píxeles] | Latencia media [segundos] | Latencia var. [segundos] |
Velocidad var. [%] | Número de interruptores | Eventos intermedios | Proporción tampón [%] | MBs cargados | Objetos cargados |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.js por defecto | 2770 | 726 | 3.06 | 0.21 | 10.4 | 93 | 38 | 7.99 | 352.2 | 256 |
| DASH.js LolP | 3496 | 853 | 5.65 | 4.59 | 22.7 | 70 | 53 | 21.96 | 369.4 | 210 |
| DASH.js L2all | 3699 | 908 | 4.14 | 3.18 | 19.9 | 5 | 19 | 7.99 | 368 | 147 |
| Jugador Shaka (guión) | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| Reproductor THEO (guión) | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.js por defecto 2020 | 1763 | 562 | 10.08 | 10.91 | 8.1 | 26 | 2 | 9.8 | 130.7 | 589 |
| HLS.js LolP 2020 | 1756 | 560 | 5.97 | 0.2 | 6.1 | 24 | 0 | 0 | 148.1 | 688 |
| HLS.js L2all 2020 | 1752 | 560 | 6 | 0.23 | 5.9 | 34 | 0 | 0 | 133.1 | 686 |
| HLS.js por defecto 2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| Jugador Shaka (HLS) | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
Tabla 2. Estadísticas de rendimiento - Red LTE de T-Mobile
EVALUACIÓN DEL RENDIMIENTO DEL STREAMING DE BAJA LATENCIA
Mientras que LL-HLS y LL-DASH funcionaron bien en entornos de red sin restricciones, tuvieron problemas en redes con poco ancho de banda o muy variables (típicas de los despliegues móviles). Los efectos observados incluían retrasos muy variables, incapacidad para evitar el almacenamiento en búfer y frecuentes cambios de ancho de banda o incapacidad para utilizar el ancho de banda de red disponible. Algunos reproductores simplemente cambiaron a la transmisión sin baja latencia en condiciones de red tan difíciles.
Por muy prometedoras que sean LL-HLS o LL-DASH en teoría, aún queda margen para que estas tecnologías maduren.
En Brightcove, seguimos trabajando en las mejores implementaciones de algoritmos para clientes de secuencias de baja latencia, así como en optimizaciones del codificador y del servidor. Pretendemos que nuestra compatibilidad con la retransmisión de secuencias de baja latencia sea altamente escalable, fiable y esté totalmente preparada para el prime time.
Este blog fue escrito originalmente por Yuriy Reznik en 2021 y ha sido actualizado para mayor precisión y exhaustividad.
