Producción a distancia: Contribución flexible a través de IP

Producción a distancia; contribución flexible a través de IP

Una miniguía sobre las consideraciones clave que las organizaciones deben tener en cuenta en sus operaciones de producción a distancia, por Geoff Bowen, Arquitecto Jefe de Tecnología, Appear. 

Disponible en la Guía Esencial de Broadcast Bridge de este mes .

El concepto de producción remota -trasladar el contenido bruto generado en un evento in situ a las instalaciones principales para su producción y gestión- ha ido ganando rápidamente popularidad en el mundo de la radiodifusión. Los contenidos móviles/in situ también han ido ganando popularidad con la posibilidad de ofrecer a los espectadores una serie de eventos deportivos y otras transmisiones in situ a través de las opciones tradicionales de transmisión por aire, cable y streaming.

Paralelamente a la expansión de los portales de consumo, la gama de formatos de contenido en uso se está ampliando con la contribución de HDR 1080p y UHD que se está convirtiendo en algo común para los principales eventos deportivos e incluso los despliegues de producción 8K, ya sea en vivo o en pruebas.

Cuando llegó el COVID-19, las cadenas se enfrentaron a un doble dilema: sus espectadores querían aún más contenidos generados a distancia para sentirse más conectados mientras tenían que quedarse en casa, pero las cadenas necesitaban mantener a su propio personal a salvo mientras generaban ese aumento de contenidos que los consumidores demandaban.

La seguridad del personal impulsó dos cambios tecnológicos clave: En primer lugar, una rápida aceleración de los despliegues de producción a distancia. Los Juegos Olímpicos de 2021 en Tokio fueron un buen ejemplo. Las emisoras enviaron un 39% menos de personas de lo que sería habitual para un evento de este tipo, y gran parte de la producción se realizó en sus instalaciones principales o a través de una empresa de producción remota, que a su vez tuvo que operar en el lugar con menos personal. El envío de menos personas no sólo mantuvo la seguridad del personal de transmisión, sino que los organismos de radiodifusión notaron inmediatamente una reducción drástica de los costes, ya que la cantidad de equipos in situ cayó en picado y la necesidad de transporte, alojamiento y otros gastos in situ también se redujeron. El aumento del volumen de emisiones in situ para los espectadores también se hizo más viable gracias a la posibilidad de centralizar la producción, lo que permite utilizar el mismo equipo de producción para gestionar varios eventos en el mismo día.

El segundo cambio clave fue que las propias instalaciones contaban con un personal mucho más reducido, gracias a la posibilidad de utilizar conexiones domésticas a Internet, tecnologías de compresión y herramientas de acceso remoto seguro para que el personal pudiera realizar eficazmente las operaciones y las funciones de ingeniería desde casa. Estos flujos de trabajo "en casa" requerían un cambio de las tecnologías de compresión que se utilizaban en las redes gestionadas hacia códecs de menor velocidad de bits, protegidos por mecanismos ARQ como SRT, Zixi y RIST, que permiten que el contenido tolere las pérdidas de paquetes que se esperan en las conexiones domésticas de Internet, además de proporcionar conjuntos de herramientas para el cifrado y el cruce de cortafuegos con una configuración mínima.

Aunque el despliegue de la producción remota sigue creciendo, muchas emisoras siguen desconcertando sus opciones porque no es tan sencillo como muchos quieren hacer creer. Todo depende de la infraestructura de telecomunicaciones que esté en juego para cada evento. Los estadios deportivos tradicionales no son un problema: habrá enlaces de fibra dedicados con todo el ancho de banda de alta velocidad que se necesite. Pero, ¿qué pasa con las ubicaciones no tradicionales? El problema es que no todos los sitios son iguales: algunos siguen teniendo una infraestructura muy fiable, como un estadio deportivo de un equipo profesional con fibra dedicada, mientras que otros ofrecen diferentes tipos de conexiones que pueden diferir mucho en el nivel de ancho de banda y la cantidad de equipos que pueden conectarse a la vez. Nadie quiere conectar sus fuentes de vídeo y audio a una conexión de Internet inestable y acabar con un producto inutilizable (y con posibles sanciones por no proporcionar los requisitos de cobertura contratados). Obviamente, antes de planificar un evento a distancia es necesario hacer un poco de trabajo para determinar cómo se gestionarán las fuentes y el backhaul.

Para los locales e instalaciones con acceso a una conectividad IP de gran ancho de banda y alta fiabilidad, la contribución de contenidos puede aprovechar los códecs que ofrecen un rendimiento de latencia extremadamente bajo, como JPEG XS, que ha visto una rápida adopción recientemente. La latencia de codificación y decodificación de JPEG XS puede ser tan baja que un flujo de trabajo de ida y vuelta entre dos sedes puede introducir menos de un fotograma de retardo en comparación con una entrega completamente sin comprimir, lo que lo hace ideal para producciones con talentos en múltiples ubicaciones geográficas, ya que el flujo de conversación es más natural, o como una herramienta para lograr los flujos de trabajo de "cristal a cristal" de menor latencia.

Todavía hay consideraciones que van más allá de la selección del códec y la tasa de bits. Actualmente, el vídeo comprimido en JPEG XS puede transportarse en un flujo de trabajo SMPTE ST2110 encapsulado como SMPTE 2110-22, en el que el vídeo, el audio y los datos auxiliares se transportan como flujos de esencia separados, especificados como VSF-TR08, o dentro de un flujo de transporte MPEG, en el que las esencias se multiplexan en un único flujo, especificado como VSF-TR-07.

La naturaleza basada en la esencia de SMPTE ST2110 tiene beneficios deseables en los flujos de trabajo de producción. Sin embargo, puede ser complejo de manejar y supervisar y, por lo general, requiere un equipo especializado tanto en el sitio de envío como en el de recepción en términos de PTP para proporcionar la sincronización de los flujos de esencia, por lo general a partir de un reloj maestro bloqueado por GNSS y tejidos de conmutación conscientes de PTP. Esto puede presentar desafíos como el posicionamiento de la antena con línea de visión a los satélites en edificios o ubicaciones subterráneas. En ubicaciones con SDI hand off, el aprovisionamiento de la infraestructura IP puede ser prohibitivo en cuanto a costes y espacio, especialmente para los pequeños paquetes flyaway y, como tal, puede impulsar una decisión tecnológica para utilizar el método de encapsulación basado en el flujo de transporte TR-07. Una implementación de codificador y decodificador cuidadosamente diseñada puede adaptarse para mantener las características de baja latencia del códec JPEG XS, lo que permite utilizar TS sin penalización de latencia sobre ST2110.

Los despliegues basados en la norma SMPTE ST-2110 suelen utilizar la redundancia de rutas diversas SMPTE ST2022-7 para protegerse contra la pérdida de paquetes y los fallos de las rutas dentro del tejido IP. Esto también requiere una planificación (y pruebas) para considerar el efecto de la pérdida total de una ruta. ¿Puede la ruta alternativa entregar el contenido sin pérdida de paquetes, o necesitamos aplicar un grado de FEC para proteger contra niveles bajos de pérdida en este escenario?

Si no se dispone de diversos caminos, un flujo de trabajo de un solo extremo puede exigir el uso de un mecanismo de protección contra la pérdida de paquetes de baja latencia, como FEC. Aunque hay que tener en cuenta una sobrecarga de ancho de banda, esto no aumenta la latencia de forma apreciable como pueden hacerlo los mecanismos basados en ARQ.

¿Es la red subyacente capaz de utilizar la multidifusión para la entrega a múltiples puntos finales desde un único codificador? Si se requiere la entrega de unidifusión, ¿puede el codificador entregar múltiples instancias de unidifusión de la señal codificada sin necesidad de servicios externos de NAT o replicación?

Además, las plataformas en la nube son cada vez más populares para los flujos de trabajo de producción en directo, inicialmente impulsadas por la necesidad durante la pandemia y ahora madurando con los conjuntos de herramientas de software que se alinean con las capacidades de las soluciones basadas en hardware on prem. La contribución del vídeo lineal a los flujos de trabajo en la nube ha utilizado tradicionalmente códecs de menor tasa de bits, como AVC, HEVC o NDI, aumentados por ARQ a través de la Internet pública. Sin embargo, el aumento de la disponibilidad y la reducción del coste de los circuitos de gran ancho de banda de los locales y las instalaciones de radiodifusión permiten ahora utilizar códecs de latencia ultrabaja, como JPEG XS, como método de contribución en tierra a la nube.

Si se dispone de un ancho de banda fiable pero limitado, códecs más complejos como AVC o HEVC permitirían transportar más contenidos a velocidades de bits más bajas manteniendo niveles muy altos de calidad visual. La contrapartida es la latencia, ya que los flujos de trabajo AVC / HEVC de baja latencia ampliamente admitidos añaden aproximadamente 700 ms de retraso a una ruta de codificación/decodificación en comparación con un flujo de trabajo sin comprimir o JPEG XS.

Se puede conseguir una latencia aún más baja con implementaciones de códecs de latencia ultrabaja como HEVC ULL. Este enfoque no produce un GOP tradicional con tramas I/IDR, P y B. No se utilizan tramas Intra completas. En su lugar, el codificador utiliza GDR (Gradual Decoder Refresh) en lugar de IDR (Instantaneous Decoder Refresh). Esta técnica se denomina a menudo "stripe refresh". Aunque este enfoque permite flujos de trabajo con una latencia de extremo a extremo de menos de 200 ms, tampoco aprovecha la eficiencia de la codificación basada en GOP y, por tanto, necesita funcionar a tasas de bits más altas en comparación con los codificadores AVC o HEVC tradicionales. Aun así, consume mucho menos ancho de banda que los sistemas basados en JPEG XS o JPEG 2000.

Todavía no hay un estándar definido para HEVC ULL que permita la interoperabilidad entre proveedores, por lo que, al menos por ahora, se requiere el mismo codificador y decodificador del proveedor.

Incluso cuando se garantiza un ancho de banda fiable y gestionado, las funciones de contribución que utilizan la Internet pública pueden constituir una estrategia de continuidad rentable y, por tanto, pueden utilizarse para complementar los despliegues gestionados.

Muchas redes de contribución gestionadas se dedican al transporte de medios y, como tales, tienden a no utilizar la protección de contenidos, favoreciendo el uso más eficiente del ancho de banda y la menor latencia posible. Sin embargo, existen numerosos casos de uso en los que los contenidos atraviesan un tejido IP privado pero de uso mixto, como una red troncal de TI corporativa. En estas circunstancias, puede ser deseable, o incluso obligatorio, aplicar un cifrado al contenido para evitar su posible interceptación. Existen numerosas técnicas para lograrlo, desde el simple cifrado protegido por una frase de paso hasta las claves de sesión cifradas RSA para cada receptor.

Se requieren múltiples tipos de entrega de señales en el borde de compresión. Muchas instalaciones y camiones utilizan ahora un núcleo de enrutamiento IP ST2110 sin comprimir y una capa de control NMOS, mientras que otros utilizan SDI. A menudo, la solución de contribución necesita dar servicio a ambas formas de entrega dentro del mismo flujo de trabajo, dependiendo de lo que esté disponible en una ubicación determinada, lo que requiere una solución de contribución con E/S flexible que abarque la conectividad SDI eléctrica y óptica y la conectividad IP capaz de soportar E/S UHD sin comprimir. Otros flujos de trabajo pueden no descodificar una señal comprimida a banda base y, por tanto, requieren herramientas para transcodificar el contenido y realizar el procesamiento en el dominio comprimido, vigilar los flujos de medios, proporcionar NAT y capacidades de conversión de multidifusión / unidifusión.

Antes de planificar un flujo de trabajo de producción in situ o en la nube, pregunta qué tipos de conexiones están disponibles y qué tipo de ancho de banda se puede esperar de cada una. Si está basado en IP, averigua si existen copias de seguridad en caso de que fallen las conexiones principales. Otro paso fundamental es determinar el nivel de seguridad de esas conexiones. Si son visibles para los hackers, pueden ser fácilmente interrumpidas.

Un equipo que puede ayudar a mitigar los problemas de ancho de banda es una plataforma de compresión de buena calidad, que proporciona funciones de compresión y descompresión de baja latencia para facilitar el transporte de vídeo por IP. Algunos equipos de vídeo remoto incluyen codificadores superficiales, pero estos codificadores pueden no estar a la altura cuando se presentan problemas de velocidades IP variables u otros problemas de ancho de banda, y pueden no tener un nivel cómodo de seguridad IP física o capacidad de cifrado de contenidos. Los codificadores autónomos, aunque es cierto que aumentan la cantidad de equipos que van a la ubicación in situ, suelen ser la mejor opción para la conexión de equipos, la conexión IP y los altos niveles de seguridad y herramientas de protección de contenidos.

Al seleccionar una plataforma de codificación, asegúrese de que tiene la versatilidad necesaria para manejar la tasa de bits disponible, la capacidad de resolución de vídeo, la capacidad y la interconexión necesaria para la conexión disponible. Una buena plataforma ofrecerá soporte de formatos interoperables, APIs de control, soluciones de encriptación, modelos de redundancia física y de contenido, y también debería proporcionar sólidas capacidades de firewall y de control de tráfico. Appear ha hecho de todas estas necesidades un "must" en nuestra cartera de soluciones.

Ficha de datos de la plataforma X