La baja latencia es una aspiración universal en los medios. Cuando una empresa como Wowza produce el gráfico perfecto para explicar las tecnologías de transmisión de baja latencia, debe quitarse el sombrero y usar el gráfico, con atribución y algunas modificaciones menores. Presento dicho gráfico como Figura 1; discutamos en el orden designado por los números resaltados que he agregado.
1. Aplicaciones para baja latencia
GUÍA DE PRODUCTO
Las mejores cámaras PTZ para transmisión en vivo
Solo 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 vaso es la cámara en el evento en vivo real, el segundo es la pantalla que estás mirando. La latencia es el retraso entre el momento en que aparece en la cámara y el momento en que aparece en su 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, fundamentalmente, cuántos segundos almacena el reproductor en búfer antes de comenzar a jugar.
La capa superior muestra las aplicaciones típicas y sus requisitos de latencia. Las aplicaciones populares que faltan debido a la latencia baja y la latencia casi en tiempo real son los sitios de apuestas y subastas.
Antes de sumergirse en nuestra discusión sobre tecnología, comprenda que cuanto menor sea la latencia de su transmisión en vivo, menos resistente será la transmisión a las interrupciones del ancho de banda. Por ejemplo, con la configuración predeterminada, una transmisión HLS se reproducirá durante más de 15 segundos de ancho de banda interrumpido y, si se restaura en ese momento, es posible que el espectador nunca sepa 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 baja latencia siempre debe equilibrarse con lo negativo de las paradas en la reproducción. Si no necesita absolutamente una baja latencia, puede que no valga la pena sacrificar la capacidad de recuperación para obtenerla.
Dicho esto, es útil dividir la latencia en tres categorías, de la siguiente manera.
BOLETÍN PROAudio + Video + IT. Nuestros editores son expertos en la integración de audio / video y TI. Obtenga información, noticias y contactos profesionales diarios. Suscríbase a Pro AV hoy.
- Agradable tener - Más rápido siempre es mejor, pero si está transmitiendo en vivo una reunión de la Junta de Educación o un partido de fútbol de la escuela secundaria, puede decidir que la solidez de la transmisión es más importante que la baja latencia, especialmente si muchos espectadores miran con conexiones de baja tasa de bits.
- Ventaja competitiva - En algunos casos, la latencia baja proporciona una ventaja competitiva, o la latencia lenta significa una desventaja competitiva. Observará en el gráfico que la latencia típica de la televisión por cable es de alrededor de cinco segundos. Si su servicio de transmisión está compitiendo con el cable, debe estar en ese rango, con una latencia más baja que brinde una ventaja competitiva modesta.
- Comunicaciones en tiempo real - Si tiene un sitio de apuestas o subastas, o si su aplicación requiere comunicaciones en tiempo real, es absolutamente necesario que ofrezca una latencia baja.
- Guía de comparación de transmisión en vivo
- Cómo predecir el éxito del códec
Ahora que conocemos las categorías, veamos la forma más eficaz de ofrecer el nivel necesario de baja latencia.
2/3 Es bueno tener baja latencia
El número 2 muestra que Apple HLS y MPEG-DASH implementados con su configuración predeterminada dan como resultado aproximadamente 30 segundos de latencia. Los números son simples; Si usa tamaños de segmento de diez segundos y necesita que haya tres segmentos en el búfer del reproductor antes de que comience la reproducción, está en treinta segundos. En realidad, Apple cambió sus requisitos de diez segundos a seis segundos hace unos años, y la mayoría de los productores de DASH usan segmentos de 4-6 segundos, por lo que el número predeterminado está realmente más cerca de los 20 segundos.
Aún así, el número 3, HLS Tuned y DASH Tuned, muestra una latencia de alrededor de 6-8 segundos. En esencia, la sintonización significa cambiar de segmentos de 10 segundos a segmentos de 2 segundos que, aplicando las mismas matemáticas, ofrecen los 6-8 segundos de latencia. Por lo tanto, cuando es bueno tener latencia, puede reducir la latencia drásticamente sin tiempo ni costo de desarrollo, o con un riesgo de capacidad de entrega significativamente mayor.
4. Ventaja competitiva: tecnologías HTTP de baja latencia
Cuando se necesita una latencia baja como ventaja competitiva, no basta con recortar el tamaño de los segmentos; Tendrá 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 funciones. Por lo tanto, cubriré HLS de baja latencia y 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 hasta que se codifique un segmento completo, lo que generalmente demora entre 6 y 10 segundos (parte superior de la Figura 2) , el codificador crea fragmentos 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; triplica eso si el espectador necesitara recibir los tres segmentos normales antes de que comience la reproducción. Sin embargo, si su codificador expulsó fragmentos cada 200 milisegundos y el reproductor estaba configurado para iniciar la reproducción de inmediato, la latencia debería ser mucho, mucho menor. Un beneficio clave de este esquema es la compatibilidad con versiones anteriores; Dado que aún se están creando segmentos, los reproductores que no sean compatibles con el esquema de baja latencia deberían poder reproducir los segmentos, aunque con una latencia más larga. 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 admiten la mayoría de las funciones de sus hermanos de latencia normal, incluido el cifrado, la inserción de publicidad y los subtítulos, que no son compatibles universalmente con las tecnologías basadas en WebRTC y WebSockets. Es probable que pueda implementar su tecnología de baja latencia seleccionada utilizando su reproductor existente y la infraestructura de entrega, minimizando el desarrollo y otros costos de tecnología.
Elegir una tecnología HTTP de baja latencia
Hay dos estándares principales para 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, instantáneamente desplazó varios esfuerzos de base y se convirtió en la tecnología elegida para ofrecer baja latencia a HLS. Aunque la especificación es todavía relativamente nueva, ya es compatible con 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 que DASH se incluyan en sus próximas pautas de interoperabilidad. De acuerdo con todas estas especificaciones, los desarrolladores de codificadores y reproductores y las redes de distribución de contenido han estado trabajando durante varios años para garantizar la interoperabilidad de modo que todas las aplicaciones de baja latencia DASH / CMAF comiencen a funcionar.
Como ejemplo, Harmonic y Akamai juntos demostraron CMAF de baja latencia desde NAB e IBC 2017, mostrando la entrega OTT en vivo 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.
Ya sea que elija implementar HLS de latencia baja o latencia baja para DASH, o ambos, la transición de su arquitectura de entrega HLS y / o DASH existente debe ser relativamente fluida y económica.
5. Comunicaciones en tiempo real
WebRTC suele ser el motor de un paquete integrado que incluye el codificador, el reproductor y la infraestructura de entrega. Ejemplos de soluciones de transmisión a gran escala basadas en WebRTC incluyen Real Time de Phenix, Limelight Realtime Streaming y Millicast de CoSMo Software e Influxis (Figura 3). También puede acceder a la tecnología WebRTC en herramientas como Wowza Streaming Engine, CoSMO Software y Red 5 Pro Server. Los tiempos de latencia para las tecnologías de esta clase oscilan entre 0,5 segundos para el 71% de las transmisiones (Phenix), menos de 500 milisegundos (Red5 Pro) y menos de un segundo (Limelight). Si necesita una latencia de menos de dos segundos, WebRTC es una opción que debe considerar.
Si necesita comunicaciones en tiempo real, es probable que deba implementar una solución basada en WebRTC o Websockets. WebRTC se formuló para las comunicaciones de navegador a navegador y es compatible con los principales navegadores de escritorio, en Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 y BlackBerry 10, por lo que debería ejecutarse sin descargas en ninguna de estas plataformas. Como su nombre indica, WebRTC es un protocolo para entregar transmisiones en vivo a cada espectador, ya sea de igual a igual o de servidor a igual.
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 usar para transmitir datos. Esta conexión se puede utilizar para admitir la entrega de video y otras comunicaciones, por lo que es conveniente si su aplicación necesita interactividad. Al igual que las implementaciones de WebRTC, los servicios que utilizan WebSockets se ofrecen normalmente como un servicio que incluye reproductor y CDN, y puede utilizar cualquier codificador que pueda transportar transmisiones al servidor a través de RTMP o WebRTC. Los ejemplos incluyen nanoStream Cloud de Nanocosmos y Streaming Cloud de Wowza con latencia ultrabaja. Wowza reclama una latencia inferior a 3 segundos para su solución, mientras que Nanocosmos reclama alrededor de un segundo, vidrio a vidrio.
Otras tecnologías de baja latencia
Existe una cuarta categoría de productos mejor denominada "otros" que utilizan diferentes tecnologías para proporcionar baja latencia. Esta categoría incluye THEO Technologies High Efficiency Streaming Protocol (HESP), un protocolo de transmisión adaptable HTTP patentado que, según THEO, ofrece una latencia inferior a 100 milisegundos al tiempo que reduce el ancho de banda en aproximadamente un 10% en comparación con otras tecnologías de baja latencia. HESP usa codificadores y CDN estándar, pero requiere soporte personalizado en el empaquetador y el reproductor (Figura 4). Puede leer más sobre HESP en un informe técnico disponible para descargar aquí.
Aquí hay una lista de preguntas que debe considerar al decidir qué tecnología de baja latencia implementar y cómo hacerlo.
¿Construir o comprar?
Si implementa la tecnología usted mismo, asegúrese de responder todas las preguntas que se enumeran a continuación antes de elegir una tecnología. Si elige un proveedor de servicios, utilícelos para comparar los diferentes proveedores de servicios.
¿Está eligiendo un estándar o un socio?
Anteriormente, describimos las diferentes tecnologías para lograr una baja latencia, pero las implementaciones varían de un proveedor de servicios a otro. Por lo tanto, no toda la implementación de LL HLS incorporará la entrega de ABR, al menos no al principio. La mayoría de las aplicaciones tradicionales de tipo broadcast probablemente migrarán hacia estándares basados en HTTP como HLS / DASH / CMAF de baja latencia, mientras que las aplicaciones que requieran una latencia ultrabaja como apuestas y 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 la tecnología que realmente implementa.
¿Puede escalar y a qué costo?
Una de las ventajas de las tecnologías basadas en HTTP es que escalan a precios estándar utilizando la mayoría de las CDN. Por el contrario, 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 costosos de entregar que HLS / DASH / CMAF. Al comparar proveedores de servicios, determine el costo total del evento, incluido el ingreso, la transcodificación, el ancho de banda, la creación de archivos VOD, configuraciones únicas o por evento, y similares.
¿Problemas relacionados con la implementación?
Haga las siguientes preguntas relacionadas con la implementación y el uso de la tecnología.
- ¿Cuál es la latencia que se puede lograr a una escala relevante para el tamaño de su audiencia y la distribución geográfica?
- ¿Existen limitaciones de calidad? - Algunas tecnologías pueden estar limitadas a determinadas resoluciones máximas o perfiles H.264.
- ¿Pasarán los paquetes a través de un cortafuegos? Los sistemas basados en HTTP utilizan protocolos HTTP, que son compatibles con los cortafuegos. Otros utilizan UDP, que puede que no atraviese los cortafuegos automáticamente. Si es UDP, ¿hay canales secundarios para entregar a los espectadores bloqueados?
- ¿Qué plataformas son compatibles? Probablemente computadoras y dispositivos móviles, pero ¿qué pasa con los STB, dongles, dispositivos OTT y televisores inteligentes?
- ¿Puede el sistema escalar para alcanzar el número de espectadores objetivo? ¿Es la infraestructura de CDN privada y, de ser así, puede entregarse a todos los espectadores relevantes en todos los mercados relevantes? ¿Cuáles son los costos anticipados de escalar?
- ¿Puedes usar tu propio reproductor o tienes que usar el reproductor del sistema? Si es el suyo, ¿qué cambios se requieren y cuánto costará?
- ¿Qué se necesita para la reproducción móvil? ¿Se reproducirán las transmisiones en un navegador o se requiere una aplicación? Si se requiere una aplicación (o es deseable), ¿hay SDK disponibles?
- ¿Qué codificadores puede utilizar el sistema? La mayoría debería usar cualquier codificador que admita conexiones RTMP en el transcodificador en la nube, pero verifique si se necesitan otros protocolos.
- ¿Se puede reutilizar el contenido para VOD o será necesario volver a codificarlo? No es un gran problema, ya que cuesta alrededor de $ 20 / hora de video para transcodificar a una escala de codificación razonable, pero es costoso para transmisiones frecuentes.
- ¿Cuáles son las opciones de redundancia y cuáles son los costos? Para transmisiones de misión crítica, querrá saber cómo duplicar el flujo de trabajo de codificación / transmisión en caso de que algún componente del sistema falle durante el evento. ¿Se admite esta redundancia y cuál es el costo?
¿Qué funciones están disponibles y a qué escala?
Habrá una amplia variedad de ofertas de funciones de los diferentes proveedores, que pueden incluir o no:
- Transmisión ABR - ¿Cuántas transmisiones y existen limitaciones de resolución o velocidad de bits relevantes?
- ¿Qué pasa con las funciones de DVR? ¿Pueden los espectadores detener y reiniciar la reproducción sin perder ningún contenido?
- Sincronización de video - ¿Puede el sistema sincronizar todos los espectadores en el mismo punto de la transmisión? Las transmisiones pueden desplazarse sobre ubicaciones y dispositivos, y sin esta capacidad, los usuarios de algunas conexiones pueden tener una ventaja para las subastas o los juegos de azar.
- ¿Qué protección de contenido está disponible? Si eres un productor de contenido premium, es posible que necesites un verdadero DRM. Otros pueden arreglárselas con la autenticación u otras técnicas similares.
- ¿Hay subtítulos disponibles? Los subtítulos son obligatorios por ley para algunas transmisiones, pero generalmente son beneficiosos para todos.
- ¿Qué pasa con la inserción publicitaria u otro esquema de monetización? ¿El proveedor de tecnología / servicios lo admite?
En general, si usted es una tienda de transmisión que busca igualar o superar los tiempos de transmisión en el rango de 5 a 6 segundos, una tecnología HTTP basada en estándares es probablemente su mejor opción, ya que se acercará más a admitir el mismo conjunto de características que usted ' que estás usando actualmente, como protección de contenido, 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 cualquier caso, hacer las preguntas enumeradas anteriormente debería ayudarlo a identificar la tecnología y / o el proveedor de servicios que mejor se adapte a sus necesidades.
