Infraestrutura de Estúdios – Transição SDI para IP

NAB 2017 –  “O OLHAR DOS ESPECIALISTAS DA SET”

Este ano, a transição nos estúdios do SDI (Serial Digital Interface) para o IP (Internet Protocol), como forma principal de movimentar os sinais através da infraestrutura, ganhou ainda mais força. Com ela, o aumento na flexibilidade e escalabilidade dos sistemas podem ajudar a indústria de mídia a desenvolver novos negócios e a permanecer competitiva

por José Antonio Garcia e Raphael Barbieri

Um impedimento que ocorria nesta transição é o fato de existirem múltiplas abordagens tecnológicas introduzidas no mercado, dificultando ainda mais a decisão de aplicar a transição. O SDI tem sido utilizado por anos como uma forma comum de conexão de vídeo sem compressão nos estúdios, possibilitando que cada equipamento se conecte com outros que suportem o mesmo padrão, independente do fabricante ou do modelo.
A Aliança para Soluções de Mídia IP (AIMS) constatou que a indústria de mídia deve manter esta abordagem de utilizar apenas uma única interface padronizada para a conexão de vídeo, como uma transição do SDI para IP, assegurando que continue a interoperabilidade no transporte do sinal.
O IP é um protocolo flexível por natureza, mas esta mesma flexibilidade pode trazer riscos se os fornecedores de tecnologia não estiverem alinhados.
Iniciada em dezembro de 2015, a aliança AIMS conta hoje com grande adesão entre fabricantes, emissoras, produtoras de mídia e órgãos de tecnologia e regulamentação.
Felizmente, a indústria tem hoje um calendário robusto de desenvolvimento técnico para o IP, entregando o mesmo nível de interoperação do SDI (figura a seguir).
Os 74 membros do Fórum de Serviços de Vídeo (VSF), com o suporte de organizações como SMPTE e EBU, têm desenvolvido uma série de recomendações para atingir a padronização do IP. Estas recomendações têm sido testadas, validadas, normatizadas e apoiadas por fabricantes e emissoras, que juntos têm encontrado soluções que permitem uma verdadeira interoperação.
Atualmente, as seguintes camadas tem o objetivo de definir cada uma das etapas necessárias para a completa adoção da tecnologia IP.

Networking Ethernet: RTP/IP
É a camada básica de rede, com sólida padronização feita pelo grupo de trabalho em ethernet para Rede local IEEE 802.3 e pelo IETF (Internet Engineering Task Force) para interconexões de redes IP.

Timing and Synchronization: PTP / SMPTE-2059
É a camada utilizada para permitir o sincronismo entre as diversas fontes de áudio/vídeo. Assim um sistema IP não requer a distribuição da referência “black burst”. O Precision Time Protocol (PTP) é utilizado para o sincronismo de relógios em uma rede de computadores, conforme definido na IEEE 1588, através de uma relação Mestre-Escravo entre os diversos relógios da rede.
A SMPTE-2059-2 define um perfil para o protocolo PTP, específico para o sincronismo de equipamentos broadcast, na qual um equipamento escravo é sincronizado em no máximo 5 segundos e com uma precisão de um (1) microssegundo ou menor.

Media Transport
Família SMPTE – 2110
Com o suporte da aliança AIMS, o SMPTE iniciou em janeiro de 2016 os trabalhos para desenvolvimento de um conjunto de padrões (documentados como SMPTE 2110) especificando o transporte, sincronismo e descrição dos fluxos separados das essências elementares (i.e. vídeo, áudio e dados) sobre IP, com o propósito de produção ao vivo e baseado em recomendações do Fórum para Serviços de Vídeo, VSF TR-03 e TR-04.
A SMPTE 2110 está se tornando, de fato, a norma para o transporte sobre IP baseado e se constitui das seguintes partes:
ST 2110-10  – System Timing and Definitions
ST 2110-20 – Uncompressed Active Video
ST 2110-21 –  Timing Model for Uncompressed Active Video
ST 2110-30 –  PCM Digital Audio
ST 2110-31 –  AES3 Transparent Transport (for non-PCM)
ST 2110-40 –  Ancillary Data
ST 2110-50 –  Interoperation of ST 2022-6 streams

Esta família de padrões (SMPTE 2110) definem um sistema de fluxos essenciais (áudio, vídeo, dados), referenciados entre si por uma base de tempo única da rede. Todos os fluxos descritos devem utilizar Real- Time Transport Protocol (IETF RFC 3550) e as fontes devem assegurar que os datagramas são gerados com um tamanho que não exceda a unidade máxima de transmissão (MTU) da rede com um tamanho de Datagrama IP máximo de 1460 octetos (IPV4 Total Length). Para acomodar vários tipos de rede, é possível outros tamanhos de datagrama, desde que especificados e sinalizados na rede. Aderindo ao MTU, os receptores não necessitam remontar os pacotes IP fragmentados. Fontes e receptores devem suportar a transmissão multicast, incluindo a sinalização IGMP (IETF RFC 3376) e unicast (IETF RFC 79 para IPv4).
A ST 2110-50 é uma recomendação para que haja interoperação com 2 padrões já existentes: SMPTE 2022-6 para vídeo com áudio embarcado e AES 67 para um fluxo de áudio separado e endereçável.

Família SMPTE 2022
O conjunto de normas SMPTE 2022, introduzidas em 2007, definem formatos de transmissão de conteúdos de áudio, vídeo e metadados em formato IP (UDP/ RTP), incluindo protocolos de correção de erro (FEC), transmissão de sinais MPEG2-TS de vídeos comprimido e com taxa constante, transmissão de sinais SDI com alta taxa (HBRMT – Transport of High Bit Rate Media Signals over IP Networks) e formas de comutação sem interrupção de datagramas RTP (seamless switching). Portanto, o conjunto de normas 2022 é um importante avanço tecnológico que permite às emissoras o início da transição para o formato IP.
O uso do formato IP/UDP/RTP provê um cabeçalho padronizado para datagramas de mídias. Isso garante a interoperabilidade entre equipamentos de rede pois a comunicação RTP é suficiente para prover as informações de sequenciamento e sincronismo (timestamps) de pacotes, não necessitando de nenhuma comunicação adicional. A figura a seguir define o formato genérico do datagrama RTP para todos os tipos de mídia.

O SMPTE 2022-6 – HBRMT descreve um protocolo de transporte que pode ser usado em redes IP, para transporte em tempo real de vídeo/áudio, sem compressão. Toda a taxa do SDI, inclusive VANC e HANC (áudio embarcado, Closed Caption, Active Format Description), é mapeada e encapsulada como um só fluxo. O SMPTE ST 2022-6 é um substituto direto do SDI, com um nível equivalente de funcionalidade.
O termo HBRMT é usado para diferenciar de outras aplicações de mídia sobre IP, onde são transportados sinais comprimidos. Os sinais desta norma estão em taxas de 0.27/1.5/3/6/12 Mbps e acima. As conexões podem ser unicast ou multicast.

Para este padrão, já implementado largamente na indústria, é recomendado que continue seu uso como base na interoperação. Por possuir uma taxa idêntica ao do SDI, pode ser uma forma efetiva para criar um sistema híbrido IP/SDI. Dispositivos, tais como servidores de vídeo, CIABs (Channel in a Box) e outros, podem possuir processos internos para alterar o vídeo e remapear o áudio e dados (VANC/HANC). Desta forma, as entradas e saídas podem ser SMPTE ST-2022-6.
Enquanto o SMPTE ST-2022-6 pode ser visto como um substituto do SDI, o SMPTE ST 2110 cria uma flexibilidade, permitindo que o vídeo, áudio e dados sejam separados e sincronizados em toda cadeia de produção. Esta capacidade permite o processo independente dos sinais das fontes – tais como câmeras, satélites, microfones, dados – recombinando os sinais na produção ou no ambiente de playout.
O AES67, recomendado na ST 2110-50, define o transporte de um áudio PCM usando IP, com 24-bit e sem compressão, em 48 e 96 KHz de amostragem. Opera como um equivalente IP ao “áudio discreto”. Isto dá uma solução ideal para sistemas que precisam da compatibilidade do SMPTE 2022-6 e a flexibilidade do áudio discreto. Permitindo maior flexibilidade e capacidades superiores ao do áudio embarcado, e reduzindo o volume de tráfego que precisa ser enviado aos sistemas de processamento de áudio.

SDP (Session Description Protocol)
O SDP é um formato para descrever fluxos e combinações de fluxos RTP. Dispositivos que contém uma ou mais fontes de sinal (senders) devem construir um ou mais objetos SDP como definido em Session Description Protocol (IETF RFC 4566). Estes objetos SDP devem estar disponíveis através da interface de gerenciamento do dispositivo.
O SDP que contém múltiplas mídias declaradas, com o objetivos de rodarem simultâneamente e sincronizadas, devem ser identificadas por um atributo de identificação de fluxo de mídia (“mid”)” e deve possuir um atributo de grupo (“group”) que especifica a semântica de Lip Synchronization (“LS”). Todas as descrições de fluxos devem possuir um atributo media-level “mediaclk” e um atributo media-level “tsrefclk” (IETF RFC 7273).

SDP for Duplicate RTP Streams
Fluxos duplicados RTP podem ser usados para transmissão redundante, para obter alta disponibilidade sistêmica (hitless fail-over). As fontes (Senders) que transmitem estes fluxos duplicados, usando mecanismo de Separate Source Addresses ou Separate Destination Addresses, devem sinalizar a duplicação RTP usando o atributo de grupo (“group”) da sessão, com a semântica “DUP”.
Nota: O SMPTE ST 2022-7 permite os métodos acima que especificam fluxos RTP duplicados, mas também permite fluxos RTP com endereços de fonte e destinos duplicados em redes físicas separadas; este mecanismo não pode ser representado com SDP, portanto o seu uso não é suportado por este padrão.

SDP: Colorimetry e EOTF
Fluxos de vídeo que utilizam ITU-R BT.2020, ou Rec. ITU-R BT.1886 (“gamma”), ou SMPTE ST 2084, devem ter os seus valores sinalizados no SDP.

Registry/Identity/Discovery-AMWA IS-04
Enquanto a SMPTE 2110 está focada no transporte das essências em um mundo IP, uma iniciativa separada e complementar da AMWA (Advanced Media Workflow Association) está definindo como os “media nodes” (e.g. equipamentos) podem ser registrados na rede, bem como os seus serviços e capacidades (registration) e como outros “media nodes” podem encontrá -los na rede (discovery).
Quando utilizamos uma infraestrutura em rede, podemos deixar de utilizar métodos estáticos para gerenciar as conexões entre os equipamentos. Os dispositivos necessitam das capacidades de identificação, descoberta e registro como base para facilitar a interopera ção. O IS-04 é uma parte da especificação NMOS (Network Media Open Specification), onde as empresas desenvolveram APIs para as operações Node, Register e Query, suportando Peer-to-Peer (P2P) e Sistemas de Registro e Descoberta (RDS) que podem ser modular para permitir escalabilidade.
Isto elimina a necessidade de ter tipos de conexões específicas para I/O e de ter conhecimento de quais dispositivos são compatíveis. Um dispositivo pode registrar a suas capacidades de I/O com o serviço de registro, ou na ausência deste, usar a descoberta peerto- peer para encontrar dispositivos compatíveis aos quais podem se conectar.
Através deste mecanismo, podemos conseguir um sistema mais dinâmico que permite uma execução e uma evolução melhorada do fluxo de trabalho. A metodologia abrange de uma simples câmera “plug-n-play” e evolui para grandes sistemas. O IS-04 permite uma simples e rápida configuração do sistema. Este é um exemplo de como uma infraestrutura IP pode ter funcionalidades superiores àquelas possíveis em sistemas SDI.

Conexão (NMOS)
A incubadora AMWA Networked Media está trabalhando em um Gerenciamento de Conexões, com formato aberto e independente de protocolo, em uma especificação de lógica de alto-nível, para o roteamento das Fontes e Destinos. A primeira fase está focada em criar e finalizar conexões entre as fontes e destinos que foram descobertas utilizando o IS-04. As fontes devem criar um “manifesto” descrevendo o fluxo que estão enviando, tal como o SDP (Session Description Protocol) para o fluxo RTP. Para formar a conexão entre os dois nós, um gerenciador de conexões envia ao receptor as informações sobre a fonte, incluindo uma referência sobre o “manifesto”, após isso o receptor interpreta este “manifesto” e inicia o acesso ao fluxo.

Controle de rede
Os trabalhos de controle de fluxo de rede já iniciaram. O grupo de estudos SMPTE TC-32F prepara um relatório com as normas existentes, bem como a análise de gaps com as recomendações de desenvolvimento. Paralelamente, o AMWA (Advanced Media Workflow Association) está desenvolvendo uma API para Redes Definidas por Software (SDN) para o controlador da rede a ser utilizada pela camada de Serviços NMOS (Network Media Open Specification).
Embora ainda seja um trabalho não finalizado, espera- se que a API permita que os serviços NMOS interaja com o controlador de rede, para descobrir a topologia da rede, permitindo o registro de fontes, destinos autorizados e permitir os fluxos autorizados na rede. O nível de controle deve ser tal que, nenhum pacote IP sem autorização possa trafegar na rede. Além disso, os fluxos serão capazes de obter reserva de banda garantida na rede, recebendo uma qualidade de serviço confiável (QoS).

Conclusão
Enquanto a indústria de broadcast se ocupava de evoluir com o SDI coaxial, de 270 Mbps para 3/6 Gbps, o mercado de TI se ocupava com data centers de alta velocidade, escalando a lei de Moore, com redes de 10/25/40/50/100 Gbps, com redes IP e de custos eficazes. Atualmente, a indústria de mídia se depara com grandes quantidades de conteúdos para distribuir, assim como a necessidade de suportar formatos 4K-UHD, com chaveamentos de vídeos com taxas de 12 Gbps e acima. Isto é simplesmente impraticável, ou mesmo impossível de conseguir com os projetos tradicionais de broadcast de roteamento com SDI.
Assim, a indústria de mídia começa a utilizar redes IP e data-centers, com equipamentos já existentes da indústria de TI, para atingir eficiência em sua infraestrutura.
Mais importante, a flexibilidade conseguida com arquitetura baseada em pacotes, dá suporte para a nova realidade de uma produção ágil, com estratégias de distribuição multi-facetadas, com virtualização e com os benefícios da economia da ethernet, comparada ao alto custo de uma interface exclusiva para broadcast, que é o SDI.
Os trabalhos alinhados por toda indústria de mídia, que compõem a aliança AIMS, pavimentam um caminho seguro, para a necessária transição de SDI para IP.

José Antônio S. Garcia é engenheiro e membro da SET e gerente de Engenharia da EBC em São Paulo. Contato: [email protected]

Raphael Barbieri MBA em Gerenciamento de Projetos pela FGV em 2014, graduado em Engenharia de Computação pela UNICAMP em 2007 com ênfase em sistemas e processos industriais. Atua desde 2007 na EITV no estudo e implementação de novas tecnologias de hardware e software para o sistema Brasileiro de TV digital (SBTVD). Membro do Modulo Técnico do Forum SBTVD. Contato: [email protected]