Comprensión de las soluciones de medios de transmisión de baja latencia

La baja latencia es una aspiración universal en los medios de comunicación. Cuando una compañía como Wowza produce el gráfico perfecto para explicar las tecnologías de streaming de baja latencia, hay que quitarse el sombrero ante ellas, y usar el gráfico, con atribución, y algunas modificaciones menores. Presento dicho gráfico como Figura 1; vamos a discutir en el orden designado por los números resaltados que he añadido.

Las mejores cámaras PTZ para la transmisión en vivo

Sólo para asegurarnos de que todos estamos en la misma página, la latencia en el contexto de la transmisión en vivo significa el retraso de vidrio a vidrio. El primer vidrio es la cámara en el evento en vivo real, el segundo es la pantalla que estás viendo. La latencia es el retardo entre el momento en que aparece en la cámara y el momento en que aparece en tu teléfono. Contribuyen a la latencia factores como el tiempo de codificación (en el evento), el tiempo de transporte a la nube, el tiempo de transcodificación en la nube (para crear la escalera de codificación), el tiempo de entrega y, lo que es más importante, cuántos segundos almacena tu reproductor antes de empezar a jugar.

La capa superior muestra las aplicaciones típicas y sus requisitos de latencia. Las aplicaciones más populares que faltan en la baja latencia y en la latencia casi en tiempo real son los sitios de juego y de subastas.

Antes de sumergirnos en nuestra discusión tecnológica, entiendan que cuanto menor sea la latencia de su transmisión en vivo, menos resistente es la transmisión a las interrupciones de ancho de banda. Por ejemplo, usando la configuración predeterminada, una transmisión HLS se reproducirá durante más de 15 segundos de ancho de banda interrumpido, y si se restablece en ese punto, el espectador puede no saber nunca que hubo un problema. Por el contrario, una transmisión de baja latencia dejará de reproducirse casi inmediatamente después de una interrupción. Por lo tanto, el beneficio del tiempo de inicio de la baja latencia siempre necesita ser balanceado contra el negativo de las interrupciones en la reproducción. Si no necesitas absolutamente una baja latencia, puede que no valga la pena sacrificar la resistencia para conseguirla.

Dicho esto, es útil dividir la latencia en tres categorías, como sigue.

Audio + Video + IT. Nuestros editores son expertos en la integración de audio/video e IT. Obtenga diariamente información, noticias y redes profesionales. Suscríbete a Pro AV Today .

Ahora que conocemos las categorías, veamos la manera más eficiente de entregar el nivel necesario de baja latencia.

El número 2 muestra que el HLS y el MPEG-DASH de Apple desplegados con sus ajustes predeterminados dan como resultado unos 30 segundos de latencia. Los números son simples; si usas tamaños de segmento de diez segundos y requieres que tres segmentos estén en el buffer del reproductor antes de que comience la reproducción, estás a treinta segundos. En realidad, Apple cambió sus requerimientos de diez a seis segundos hace unos años, y la mayoría de los productores de DASH usan segmentos de 4 a 6 segundos, por lo que el número por defecto está realmente más cerca de los 20 segundos.

Aún así, el número 3, HLS Sintonizado y DASH Sintonizado, muestra una latencia de alrededor de 6-8 segundos. En esencia, afinar significa cambiar de segmentos de 10 segundos a segmentos de 2 segundos que, aplicando la misma matemática, entrega los 6-8 segundos de latencia. Por lo tanto, cuando la latencia es agradable de tener, se puede cortar la latencia de forma drástica sin tiempo de desarrollo o costo, o un aumento significativo del riesgo de entrega.

Cuando la baja latencia es necesaria como ventaja competitiva, no basta con reducir el tamaño de los segmentos, sino que hay que implementar una verdadera tecnología de baja latencia. Aquí, hay dos clases; tecnologías HTTP como HLS de baja latencia y CMAF de baja latencia para DASH, y soluciones basadas en otras tecnologías, como WebSockets y WebRTC.

Para la mayoría de los productores con aplicaciones de esta clase, las tecnologías HTTP de baja latencia ofrecen la mejor combinación de asequibilidad, compatibilidad con versiones anteriores, flexibilidad y conjunto de características. Por lo tanto, cubriré el HLS de baja latencia y el CMAF de baja latencia para DASH en esta sección, y otras tecnologías en la siguiente.

Todos los sistemas de baja latencia basados en HLS/DASH/CMAF funcionan de la misma manera básica, como se muestra en la figura 2. Es decir, en lugar de esperar a que se codifique un segmento completo, lo que normalmente lleva entre 6 y 10 segundos (parte superior de la figura 2), el codificador crea trozos mucho más cortos que se transfieren a la CDN tan pronto como se completan (parte inferior de la figura 2).

Por ejemplo, si su codificador estuviera produciendo segmentos de seis segundos, tendría al menos seis segundos de latencia; el triple de eso si se requiriera que el espectador recibiera los tres segmentos normales antes de comenzar la reproducción. Sin embargo, si su codificador expulsara trozos cada 200 milisegundos y el reproductor estuviera configurado para iniciar la reproducción inmediatamente, la latencia debería ser mucho, mucho menor. Una ventaja fundamental de este esquema es la compatibilidad hacia atrás; como los segmentos se siguen creando, los reproductores que no son compatibles con el esquema de baja latencia deberían poder seguir reproduciendo los segmentos, aunque con mayor latencia. Estos segmentos también están disponibles instantáneamente para presentaciones VOD desde la transmisión en vivo.

Más allá de estas ventajas, las tecnologías HTTP de baja latencia soportan la mayoría de las características de sus hermanos de latencia normal, incluyendo el cifrado, la inserción de publicidad y el subtitulado, que no son universalmente soportadas en las tecnologías basadas en WebRTC y WebSockets. Es probable que pueda implementar su tecnología de baja latencia seleccionada utilizando su infraestructura de reproducción y entrega existente, minimizando los costos de desarrollo y otras tecnologías.

Hay dos estándares principales para el HTTP Adaptive Streaming, HLS y DASH, además de un formato de contenedor unificador, CMAF. Una vez que Apple anunció su solución HLS de baja latencia, desplazó instantáneamente varios esfuerzos de base y se convirtió en la tecnología elegida para entregar baja latencia a HLS. Aunque la especificación es aún relativamente nueva, ya está respaldada por proveedores de tecnología como Wowza y WMSPanel con su producto Nimble Streamer.

Existe un estándar DVB para DASH de baja latencia y el Foro de la Industria DASH ha aprobado varios modos de baja latencia para DASH que se incluirán en sus próximas directrices de interoperabilidad. De acuerdo con todas estas especificaciones, los desarrolladores de codificadores y reproductores y las redes de distribución de contenidos han estado trabajando durante varios años para garantizar la interoperabilidad, de modo que todas las aplicaciones de baja latencia de DASH/CMAF deberían empezar a funcionar.

Como ejemplo, Harmonic y Akamai demostraron juntos CMAF de baja latencia hasta NAB e IBC 2017, mostrando la entrega en directo de OTT con una latencia inferior a cinco segundos. Desde entonces, Harmonic ha integrado la funcionalidad DASH de baja latencia en sus productos basados en dispositivos (Packager XOS y Electra XOS) y soluciones SaaS (VOS Cluster y VOS260). Muchos otros proveedores de codificadores y reproductores han hecho lo mismo.

Tanto si elige implementar HLS de baja latencia o baja latencia para DASH, o ambas, la transición desde su arquitectura de entrega de HLS y/o DASH existente debería ser relativamente fluida y barata.

La WebRTC es típicamente el motor de un paquete integrado que incluye el codificador, el reproductor y la infraestructura de entrega. Ejemplos de soluciones de streaming a gran escala basadas en WebRTC incluyen Real Time de Phenix, Limelight Realtime Streaming, y Millicast de CoSMo Software and Influxis (Figura 3). También puede acceder a la tecnología WebRTC en herramientas como el Motor de Transmisión Wowza, el Software CoSMO, y el Servidor Red 5 Pro. Los tiempos de latencia de las tecnologías de esta clase van desde 0,5 segundos para el 71% de los flujos (Phenix), por debajo de 500 milisegundos (Red5 Pro), hasta menos de un segundo (Limelight). Si necesitas una latencia de menos de dos segundos, WebRTC es una opción que debes considerar.

Si necesita comunicaciones en tiempo real, es probable que tenga que implementar una solución basada en WebRTC o en Websockets. WebRTC fue formulada para comunicaciones de navegador a navegador y es compatible con todos los principales navegadores de escritorio, en Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 y BlackBerry 10, por lo que debería funcionar sin descargas en cualquiera de estas plataformas. Como su nombre lo indica, WebRTC es un protocolo para entregar transmisiones en vivo a cada espectador, ya sea de par a par o de servidor a par.

WebSockets es un protocolo en tiempo real que crea y mantiene una conexión persistente entre un servidor y un cliente que cualquiera de las partes puede utilizar para transmitir datos. Esta conexión puede ser utilizada para soportar tanto la entrega de video como otras comunicaciones, por lo que son convenientes si su aplicación necesita interactividad. Al igual que las implementaciones de WebRTC, los servicios que utilizan WebSockets se ofrecen típicamente como un servicio que incluye reproductor y CDN, y se puede utilizar cualquier codificador que pueda transportar flujos al servidor a través de RTMP o WebRTC. Los ejemplos incluyen la nanoStream Cloud de Nanocosmos y la Streaming Cloud With Ultra Low Latency de Wowza. Wowza reclama una latencia de menos de 3 segundos para su solución mientras que Nanocosmos reclama alrededor de un segundo, vidrio a vidrio.

Hay una cuarta categoría de productos que se llama mejor "otros" y que utilizan tecnologías diferentes para proporcionar una baja latencia. En esta categoría se incluye el protocolo de transmisión de alta eficiencia de THEO Technologies (HESP), un protocolo de transmisión adaptable HTTP patentado que, según THEO, proporciona una latencia inferior a 100 milisegundos y reduce el ancho de banda en un 10% aproximadamente en comparación con otras tecnologías de baja latencia. El HESP utiliza codificadores y CDN estándar pero requiere un soporte personalizado en el empaquetador y el reproductor (Figura 4). Puede leer más acerca de HESP en un libro blanco disponible para su descarga, aquí.

A continuación se presenta una lista de preguntas que deben considerarse al decidir qué tecnología de baja latencia se debe implementar y cómo hacerlo.

¿Construir o comprar?

Si implementa la tecnología usted mismo, asegúrese de responder a todas las preguntas que se enumeran a continuación antes de elegir una tecnología. Si elige un proveedor de servicios, utilícelas para comparar los diferentes proveedores de servicios.

¿Está eligiendo un estándar o un compañero?

Hemos esbozado las diferentes tecnologías para lograr una baja latencia arriba, pero las implementaciones varían de un proveedor de servicios a otro. Por lo tanto, no todas las implementaciones de LL HLS incorporarán la entrega de ABR, al menos no al principio. La mayoría de las aplicaciones tradicionales de difusión probablemente migrarán hacia estándares basados en HTTP como HLS/DASH/CMAF de baja latencia, mientras que las aplicaciones que requieren una latencia ultra baja como las apuestas y las subastas gravitarán hacia las otras tecnologías. En cualquier caso, al elegir un proveedor de servicios es más importante determinar si puede cumplir con sus objetivos tecnológicos y comerciales que qué tecnología implementa realmente.

¿Puede escalar y a qué costo?

Una de las ventajas de las tecnologías basadas en el HTTP es que se escalan a precios estándar utilizando la mayoría de las CDN. En cambio, la mayoría de las tecnologías basadas en WebRTC y WebSocket requieren una infraestructura de entrega dedicada implementada por el proveedor de servicios. Por esta razón, los servicios no basados en HTTP pueden ser más caros de entregar que HLS/DASH/CMAF. Cuando se comparan los proveedores de servicios, hay que determinar el costo de la sopa a nueces del evento, incluyendo el ingreso, la transcodificación, el ancho de banda, la creación de archivos VOD, las configuraciones de una sola vez o por evento, y similares.

Haga las siguientes preguntas relacionadas con la aplicación y el uso de la tecnología.

Habrá una amplia variedad de ofertas de características de los diferentes proveedores, que pueden o no incluir:

En general, si usted es una tienda de streaming que busca cumplir o superar los tiempos de emisión en el rango de 5 a 6 segundos, una tecnología HTTP basada en estándares es probablemente su mejor apuesta, ya que estará más cerca de soportar el mismo conjunto de características que está utilizando actualmente, como la protección de contenidos, subtítulos y monetización. Si tiene una aplicación que requiere una latencia mucho menor, probablemente necesitará una solución basada en WebRTC o Websockets, o una tecnología HTTP patentada. En cualquiera de los casos, hacer las preguntas anteriores debería ayudarle a identificar la tecnología y/o el proveedor de servicios que mejor se adapte a sus necesidades.