VoIP I: Explorando ST2110 y ST2022

Desde el momento en el que a la hora de abordar cualquier nuevo proyecto audiovisual la infraestructura IP no es únicamente una opción más si no la primera opción, debemos aterrizar la teoría en la práctica. Porque, en principio, no hay diferencia entre la teoría y la práctica, pero lo cierto es que sí.

Por Yeray Alfageme

 

La infraestructura IP proporciona, simplificándolo todo a dos palabras, mayor flexibilidad y escalabilidad. Las soluciones SDI tradicionales tienen a su favor la madurez y solidez que da el tiempo y la experiencia, pero son rígidas y tozudas. Por ejemplo, si se necesita pasar de SD a HD – aunque parezca que estamos hablando del siglo pasado es más común de lo que creemos- gran parte de la infraestructura SDI-SD de 270 Mbps no es compatible con señales SDI-HD de 1.485 Gbps, y este fue el problema que muchos encontraron tiempo atrás. Lo mismo se plantea al pasar a UHD. Implementar definiciones de 4K u 8K con infraestructura SDI en la que hay que multiplicar por 4, o incluso por 16, el cableado y la capacidad de conmutación lo hacen prácticamente inviable.

IP, como ya sabemos, es agnóstico respecto al formato a transmitir en dicha infraestructura. Todo son datos. No hay que modificar el cableado, los puertos de la matriz (de hecho, ni siquiera hay matriz), e incluso se pueden mezclar señales de diferentes formatos en el mismo equipo. A nadie se le ocurre que tener en una red IP señales SD, HD, 25 fps o slow-motion pueda ser un problema. Eso en SDI es impensable.

 

ST2022

La SMPTE es una gran defensora del IP y lleva tiempo trabajando duro para ofrecer una estandarización que establezca un marco de trabajo tanto para fabricantes como para integradores y ya en 2007 lanzaron ST2022. Este fue el primer conjunto de normas y lo que pretendió fue establecer unos requisitos, de la forma más sencilla posible, para poder desplegar infraestructura IP para broadcast.

Ya en 2012 la versión ST2022-6 establecía el uso de protocolos standard de Internet para encapsular señales SDI dentro de paquetes IP. Básicamente, cada señal SDI se dividía en un encapsulado RTP (Real Time Protocol) dentro de una trama UDP (User Datagram Packet) y luego dentro del payload, la parte de datos, de un paquete IP. Aunque este concepto funciona bien, no optimiza el uso del ancho de banda ya que requiere de más de un 20% de overhead para las cabeceras y colas de los paquetes.

Por poner un ejemplo, de una señal SDI-SD paquetizada en IP siguiendo ST2022-6 tan solo el 76% de la información es vídeo mientras que el resto, casi un 25%, son datos auxiliares, cabeceras y colas de paquetes, e información TRS (Timing Reference Signals). Para solucionarlo llega ST2110.

 

ST2110

ST2110 propone solucionar estas ineficiencias, al menos parcialmente, eliminando el timing de la ecuación como una señal separada. Los datos de clocking van embebidos dentro de las tramas IP correspondientes a las señales, ya sean SDI, MADI o AES, en el caso del audio estas dos últimas.

Aunque Ethernet es el medio preferido para las redes IP no debemos confundir IP con Ethernet, no es lo mismo. Ethernet consiste en las especificaciones propias de las capas 1, física, y 2, enlace, del modelo ISO de siete capas y, por ejemplo, se pueden implementar enlaces IP a través de este o WIFI, por poner el ejemplo más claro y diferencial.

Tanto ST2022 como ST2110 pueden ser implementados en cualquier protocolo de transporte IP existente, aunque es evidente las ventajas que el Ethernet ofrece. En primer lugar, es el más extendido, casi diría que el único, medio de facto en redes corporativas y todo el equipamiento es compatible con él, ya sea fibra o cobre. Además, al ser un medio físico, cableado me refiero, evita latencias añadidas que se sufren en otros medios como el WIFI, además de aumentar la fiabilidad. Estos delays y fiabilidad no son críticos en entornos de intercambio de ficheros ya que son soportados por los protocolos de transporte, pero en vídeo en tiempo real son críticos.

 

Eliminando el TRS para ganar ancho de banda

Ethernet es asíncrono, es decir cada paquete es transmitido por la red en un instante diferente y no tiene que esperar al siguiente ciclo de reloj para transmitirse ya que, directamente, este reloj no existe. Esto hace que el medio sea más rápido y flexible, pero a la vez obliga a que se reconstruya la trama completa cuando los paquetes son recibidos “a destiempo”.

Al quitar el TRS, ST2110 reduce el ancho de banda necesario, o incrementa la cantidad de señales a transmitir, según como se mire, entre un 16% y un 40%, dependiendo de si es audio o vídeo. Esto de eliminar el sincronismo a todo aquellos que venimos del “broadcast antiguo” nos da mucho miedo, ya que el reloj es una de las cosas más importantes en cualquier sistema y tanto líneas como campos, frames, muestras de audio y metadatos tienen que estar perfectamente sincronizados. ¿Y ahora qué hacemos?

Para lograr esta sincronización ST2110 utiliza el protocolo IEE 1588:2008, comúnmente conocido como PTP (Precision Timing Protocol). Un dato curioso: PTP es un contador que mide el número exacto de nanosegundos que han tenido lugar desde la media noche del 1 de enero de 1970, fecha y tiempo conocido como Epoch y usado como momento de referencia en muchos sistemas informáticos. Cada paquete ST2110 incluye en su metadata el valor PTP en la cabecera RTP otorgándole el sincronismo deseado. Una solución sencilla a la par que elegante y funcional.

La navaja de Ocam: la solución más sencilla siempre es la mejor.

 

 

Sincronizando el audio

El mismo concepto de PTO visto para cada trama de vídeo es aplicable a cada muestra de audio. Los paquetes de audio se juntan en paquetes similares a los AES67. Cada paquete se firma con un valor PTP para poder reordenarlos al ser recibidos. Lo mismo ocurre con la metadata y los datos de control, todos con su PTP.

Para que todo esto funcione debe haber una referencia PTP maestra y como todos los paquetes de datos, ya sean de vídeo, audio o metadata están generados por la cámara, el mezclador el micrófono o cualquier otra fuente de datos de manera independiente pero referenciados a este PTP pueden ser procesados independientemente y en paralelo, lo que aumenta la capacidad de proceso y minimiza el tiempo necesario.

 

Un PTP para controlarlos a todos

Dentro de una red puede haber más de una fuente PTP, pero solo una de ellas será la llamada “Grandmaster”. En cada uno de estos relojes hay un algoritmo llamado BMC (Best Máster Clock) que decide cuál de ellos es el mejor. Criterios como si está o no vinculado con una señal GPS, incluso preferencias elegidas por el administrador de sistema, establecen qué reloj de todos ellos será el grandmaster y los controlará a todos.

Esto permite extender los límites de nuestra red tal y como lo imaginamos, ya que parte de la información, por ejemplo, el audio, puede ser procesado dentro del hardware de control porque requiere de menos capacidad de proceso, pero el vídeo HDR es procesado con recursos en la nube, que son más flexibles y menos costosos. A raíz de ello ha aparecido una gran cantidad de softwares que, simulados a la nube, disponen de licencias de pago por uso, lo cual permite ganar esa flexibilidad necesaria para nuestras producciones. Conectando esto con el pasado: en un entorno lineal SDI esto era casi impensable.

 

Optimizando recursos e innovando más fácilmente

EL modelo SaaS (Software as a Service), que básicamente es el uso de software como un servicio pagando por el mismo solo cuando sea necesario, es un cambio de paradigma que en el mundo IP es natural pero que cambia las reglas del juego del equipamiento audiovisual. Pay-as-you-Go es la panacea para todas las productoras para adecuar su equipamiento a las necesidades de cada momento, en un negocio como el nuestro en el que la carga de trabajo es tan variable.

Así mismo, la innovación se hace mucho más fácil. Una mesa de mezclas, ya sea de vídeo o audio, tenía un formato dado por herencia y necesidades operacionales, pero cambiarla requería sustituirlo todo. Ahora es mucho más fácil. Por ejemplo, implementar controles táctiles sobre pantallas que hoy son una mesa de mezclas, mañana un multiviewer y pasado un servidor de repeticiones, requiere muy poco esfuerzo y muchas ventajas. De nuevo, ganamos flexibilidad de una manera más barata y con menos recursos.

 

Conclusiones

La migración a una infraestructura IP ofrece grandes beneficios, principalmente flexibilidad y escalabilidad, pero para aprovecharlos los sistemas conectados a dicha red IP deben entenderse entre sí. Por ello, los protocolos y estándares son aún más necesarios que en entornos lineales, ya que se usan equipos IT estándar que, sin estos estándares, no serían capaces de combinarse.

Tanto ST2022-7 como ST2110-40 son las últimas versiones de estos protocolos, que ya son maduros y que todos los sistemas de broadcast IP cumplen garantizando la interoperabilidad entre ellos, un gran dolor de cabeza en el pasado.

Ahora que tenemos la interoperabilidad, la flexibilidad y la escalabilidad ¿qué nos impide movernos de SDI a IP? Nada…