Virtualização de estúdios móveis na produção de conteúdos audiovisuais em direto

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Virtualização de Estúdios Móveis na Produção de Conteúdos Audiovisuais em Direto Miguel Ferreira da Cunha Poeira Mestrado Integrado em Engenharia Informática e Computação Orientador: Ademar Manuel Teixeira de Aguiar Supervisor: Alexandre Ulisses F. Almeida e Silva 13 de junho de 2016 © Miguel Poeira, 2016 Virtualização de Estúdios Móveis na Produção de Conteúdo Audiovisuais em Direto Miguel Ferreira da Cunha Poeira Mestrado Integrado em Engenharia Informática e Computação Aprovado em provas públicas pelo Júri: Presidente: Professor António Miguel Pontes Pimenta Monteiro Vogal Externo: Professor José Manuel de Castro Torres Orientador: Professor Ademar Manuel Teixeira de Aguiar ____________________________________________________ 13 de julho de 2016 Resumo A produção de eventos televisivos em direto, pela sua natureza distribuída, requerem a disponibilização dos mais variados recursos em locais geograficamente distintos, elevando bastante os custos de produção. À medida que a performance e o custo-eficácia das redes IP aumentam, as equipas de produção poderão beneficiar destes avanços tecnológicos para produzir e realizar, em tempo real, produções com a qualidade esperada num ambiente profissional. Da mesma forma, a evolução das tecnologias de virtualização na cloud e a investigação realizada para desenvolver soluções que fornecem ambientes resilientes e controlados, permite que esta camada tecnológica possa ser considerada para suportar operações time-critical, tal como a produção de conteúdos audiovisuais em direto. Esta dissertação aborda a produção de conteúdos televisivos em direto, propondo uma arquitetura de alto nível para a virtualização da produção de conteúdos utilizando estúdios móveis. Utilizando a transmissão de vídeo e áudio descomprimido através do protocolo RTP, pretende-se demonstrar que a produção televisiva de conteúdos audiovisuais em direto pode aproveitar as potencialidades que a cloud oferece. De forma a demonstrar essas potencialidades para realizar operações de forma distribuída, o protótipo desenvolvido permite, em tempo real, receber áudio e vídeo, transportá-los descomprimidos numa rede local e gerar versões de baixa resolução para uma interface web, a partir da qual o realizador as poderá visualizar. O trabalho realizado demonstra a possibilidade de estender a arquitetura utilizada a outras operações na cadeia de produção televisiva, como, por exemplo, a comutação entre várias entradas de vídeo e áudio, aproximando-se do tão idealizado “IP Studio”. Abstract Live TV production, due to its distributed nature, requires broadcasters to deploy equipment and human resources to several different places, increasing production’s costs. As the performance and cost-effectiveness of IP networks grow, broadcasters can use this to handle realtime production-quality video and audio that is expected in a professional environment. Similarly, the evolution of virtualization’s technologies on the cloud and the efforts developed in order to provide solutions of virtualized, elastic, controllable cloud environments, it enables that this technologic stack may be considered for time-critical applications, such as a live TV production. This master thesis proposes a high architecture for virtualizing live TV production. By using an extended version of the RTP protocol to transport audio and video uncompressed feeds through IP networks, it ought to show that live TV production can be virtualized into the cloud, taking advantage of its benefits. While using cloud’s benefits to perform time-critical operations in a distributed manner, the developed prototype allows a live remote production team to receive audio and video streams, multicast them locally at an uncompressed quality and publish them as web feeds to an external web interface. The work developed shows an architecture that can be potentially used to perform other operations that may occur in a live TV workflow, such as video switching, getting closer of the so coveted “IP Studio”. Agradecimentos Gostaria de agradecer a todos os que tornaram esta dissertação possível, desde a MOG Technologies e os seus colaboradores, ao meu orientador, Professor Ademar Aguiar, por aceitarem este desafio. Tenho que agradecer, com especial atenção, ao Eng. Pedro Ferreira, ao Eng. Alexandre Ulisses e ao Eng. Daniel Costa pela disponibilidade que demonstraram, pelo espírito crítico e pelo conhecimento transmitido, que permitiu, sem dúvida, enriquecer esta dissertação. Ao Eng. Victor Fernandes, que contribuiu criticamente para o melhoramento da informação visual presente nesta dissertação. Um agradecimento especial ao Eng. Pedro Santos, que acompanhou de perto todo o desenvolvimento da dissertação, pela paciência, dedicação, empenho e interesse que demonstrou. Miguel Poeira xvi Figura 35: Utilização da memória RAM por cada container Docker. 53 Figura 36: Previsão da utilização de CPU. 54 Figura 37: Buffering do leitor DASH. 54 xvii Lista de Tabelas Tabela 1: Escalamento dos nós tendo em conta o fluxo de dados da Figura 26. 42 Tabela 2: Características das máquinas de teste. 50 Tabela 3: Características dos vídeos de teste. 50 Tabela 4: Carga medida à entrada de um Input Distributor. 51 Tabela 5: Tráfego para o Vídeo #3. 51 xix Abreviaturas e Símbolos API Application Programming Interface CRUD Create, Read, Update, Delete DASH Dynamic Adaptative Streaming over HTTP ES Elementary Stream HD High Definition HTTP Hypertext Transfer Protocol IP Internet Protocol JT-NM Joint Task Force on Networked Media MCR Master Control Room MPD Media Presentation Description MPEG-TS MPEG Transport Stream MPTS Multiple Program Transport Stream NMOS Networked Media Open Specifications OB Outside Broadcasting PAT Program Association Table PCR Program Control Room PES Packetized Elementary Stream PID Packet ID PMT Program Map Table PTP Precision Time Protocol QoE Quality of Experience QoS Quality of Service REST Representational State Transfer RFC Request for Comments RTCP RTP Control Protocol RTP Real-time Transport Protocol SD Standard Definition SDI Serial Digital Interface SLA Service-Level Agreement SMPTE Society of Motion Picture and Television Engineers xx SPTS Single Program Transport Stream TCP Transmission Control Protocol UDP User Datagram Protocol VOD Video on Demand XML eXtensible Markup Language Capítulo 1 Introdução A origem dos programas televisivos pode ser abrangida por uma de três grandes categorias: produção remota, em estúdio ou pré-produzido. Aqui existe, logo à partida, a grande diferença de que as duas primeiras compreendem emissões em direto, enquanto a terceira categoria abrange programas previamente gravados. Não obstante, a produção de um programa televisivo, qualquer que seja a sua natureza, requer uma gestão logística e tecnológica de crescente complexidade [1]. 1.1 Contexto A produção de eventos televisivos em direto, pela sua própria natureza, requer requisitos bastante restritos: a entrega de vídeo e áudio com o mínimo de atraso possível, mantendo os requisitos de qualidade e segurança que a indústria televisiva requer para garantir a qualidade de experiência (QoE, em inglês) aos telespectadores. Figura 1:OB Van. Introdução 2 O método atual, que vários autores chamam de tradicional, baseia-se na produção remota com base em camiões de produção móveis, ou como é chamado na gíria, Outside Broadcasting (OB) vans [2], [3]. Uma OB van, como a da Figura 1, pode custar vários milhões de dólares [2], principalmente devido à grande quantidade e diversidade de equipamento que contém. Em muitos casos pode ser necessária a utilização de várias unidades, principalmente pela natureza distribuída dos eventos em direto [4], como por exemplo a cobertura de um ato eleitoral. Esta necessidade, assim como a ligação satélite que permite a conexão entre a OB van e o estúdio televisivo, eleva os custos e a complexidade da produção televisiva [5]. Apesar de um estúdio de produção moderno já utilizar extensivamente o protocolo IP, a sua utilização permite principalmente guardar e arquivar materiais multimédia para que estes estejam disponíveis ao longo de toda a cadeia de produção [6]. Da mesma forma, esta infraestrutura permitiu servir os espetadores com serviços de video on demand (VOD) como o Netflix e o Hulu [6]. Apesar disso, esta é apenas uma pequena parte do workflow na produção televisiva. Com o desenvolvimento da arquitetura dos serviços cloud e o aparecimento de frameworks para desenvolver e operar operações time-critical, como a produção televisiva de eventos em direto, e o aumento da performance das redes, passa a ser possível pensar num IP Studio, onde todo o workflow destes eventos possa estar virtualizado na cloud, aproveitando todos os benefícios que esta oferece, apesar dos riscos inerentes à Quality of Service (QoS). 1.2 Enquadramento Esta dissertação foi realizada em ambiente empresarial, na empresa MOG Technologies, que desenvolve soluções para, principalmente, ambientes de pós-produção. A MOG está no mercado do broadcasting há mais de 10 anos a fornecer soluções que permitem a interoperabilidade entre equipamentos utilizados na indústria. Esta dissertação enquadra-se na área de investigação da empresa, com o intuito de abranger outras áreas da produção televisiva no seu leque de produtos. 1.3 Motivação e Objetivos Com a virtualização da cobertura televisiva de eventos em direto pretende-se eliminar (ou pelo menos reduzir) a utilização da OB van e das ligações por satélites e substituí-las por uma aplicação distribuída na cloud suportada pela transmissão de vídeo sobre IP [2], [7]. Assim, as várias streams que resultam da cobertura do evento serão enviadas, via IP, para uma aplicação distribuída na cloud. Essa aplicação será responsável por fornecer ao realizador uma interface, através de uma aplicação web, que lhe permita comutar entre as várias streams de entrada, mais comumamente chamada de Vision Mixer. Introdução 3 O trabalho a realizar visa desenvolver um protótipo de uma aplicação distribuída que permita controlar as várias streams, assim como a sincronização de cada stream (apesar do assincronismo da transmissão de vídeo/áudio por IP). Adicionalmente, deve ser possível visualizar este protótipo através de uma aplicação web. Sendo uma aplicação distribuída na cloud, espera-se que exista modularidade e expansibilidade, de forma a ajustar a solução aos mais diferentes e variados cenários. Para tal, será necessário implementar uma arquitetura modular e genérica, que permita a interação entre os vários intervenientes e componentes de um estúdio móvel. É, também, essencial que, tratando-se de um método que visa substituir o atualmente utilizado, se garanta a fiabilidade e qualidade que estes últimos oferecem. 1.4 Estrutura da Dissertação Para além da introdução, este documento possui mais 7 capítulos. No capítulo 2 analisamse os modelos de cloud, de que forma a virtualização permite servir os diferentes tipos de modelos, Hypervisors e Containers Engines e quais as vantagens de ter um produto modular na cloud. No capítulo 3 é estudada a camada de transporte do modelo TCP/IP, compreendendo as diferentes possibilidades de transmissão de dados sobre IP. O capítulo 4 propõe-se a analisar a produção de Televisão Digital, explicando qual o ciclo de vida dos conteúdos numa cadeia de produção televisiva, de forma a se analisar os vários workflows e de que forma é feito o transporte dos conteúdos. No capítulo 5 revê-se casos de estudo na produção audiovisual em direto sobre IP, assim como se estuda o trabalho existente para permitir a interoperabilidade na transição de SDI para IP. Termina com as conclusões que podemos extrair. O capítulo 6 explica as restrições e problemas do método atual na produção móvel de eventos em direto, analisando os requisitos que uma possível solução terá que garantir. Assim, propõe uma arquitetura modular para uma aplicação distribuída na cloud. Com base na arquitetura proposta, apresenta-se o protótipo desenvolvido e as decisões arquiteturais por detrás do mesmo. O capítulo 7 apresenta o conjunto de testes de validação e aceitação que foram realizados, de forma a validar o protótipo desenvolvido, assim como se analisa o resultado desses testes e se discute a sua exequibilidade. A dissertação termina com o capítulo 8, onde é feita uma apreciação geral do trabalho realizado, o cumprimento dos objetivos e se perspetiva trabalho futuro. Capítulo 2 Computação na Cloud A computação na cloud é um serviço on-demand que permite desenvolver, distribuir e gerir aplicações, providenciando a cada aplicação um ambiente estável e isolado, sem que esta tenha conhecimento que está a correr sobre hardware virtual. A tecnologia por detrás de cada serviço cloud pode ser bastante variada, desde software proprietário a soluções open-source. Apesar disso, os princípios e capacidades de um e outro caso são semelhantes: máquinas virtuais podem ser planeadas, criadas e configuradas em ambientes perfeitamente isolados uns dos outros; o hardware que suporta essas máquinas é, em verdade, mais poderoso do que aquilo a que a máquina virtual tem acesso, dado que várias máquinas virtuais podem correr na mesma máquina física [8]. A cloud baseia-se num modelo por camadas, onde cada camada corresponde a um maior nível de abstração oferecido à sua camada superior (Figura 2) [8]:  A camada do servidor são os elementos que são realmente físicos numa cloud.  A camada da infraestrutura abstrai os elementos físicos através da virtualização do hardware, utilizando máquinas virtuais. Esta camada fornece ferramentas para criar, gerir, iniciar e parar máquinas virtuais.  A camada da plataforma utiliza as ferramentas da camada da infraestrutura de forma a simplificar a configuração e criação da infraestrutura necessária (memória, processamento, entre outros) de uma forma automática.  A camada da aplicação permite implementar e manter uma aplicação na cloud de uma forma centralizada, permitindo que esta possa ser administrada remotamente. Utiliza a camada da plataforma de forma a prover-se de elasticidade para se adaptar à sua maior ou menor utilização. Isto é: num período de grande utilização, por exemplo, a camada da aplicação reserva mais recursos, de forma a manter a QoE do utilizador final inalterada. Transmissão de dados sobre IP 12 3.1 A camada de Transporte O Transmission Control Protocol (TCP) é um protocolo orientado à conexão da camada de transporte do modelo TCP/IP. O TCP fornece a garantia de que todos os pacotes entre um emissor e um recetor são entregues de forma ordenada. Ao estabelecer a ligação, o TCP estabelece um pré-acordo Three-Way Handshake, assegurando uma conexão entre o emissor e o recetor. Durante a transferência de dados, o recetor vai enviando mensagens de Acknowledgement, confirmando a receção de um pacote de dados. Cada pacote de dados é anotado com um número sequencial, permitindo ao recetor reconstruir, se necessário, a ordem correta dos pacotes de dados. O User Datagram Protocol (UDP), por sua vez, é um protocolo não orientado à conexão. Isto significa que o UDP não garante a entrega de todos os pacotes de dados, nem a sua ordenação, já que os pacotes de dados são independentes entre si. Ao contrário do TCP, o UDP transfere cada pacote de dados uma vez. Os pacotes que chegarem corrompidos ao recetor são descartados, sem que o emissor tenha sequer conhecimento. O UDP é um protocolo mais simples, indicado para aplicações que necessitam de uma transmissão rápida dos dados. A ausência de estruturas de controlo complexas permitem ao UDP eliminar o overhead que está inerente ao TCP, garantindo-lhe alta eficiência. Apesar do protocolo UDP não garantir a entrega dos pacotes de dados, esta tarefa pode ser delegada, se necessário, à aplicação. Assim, o UDP constitui uma alternativa ao TCP, principalmente onde o serviço das camadas inferiores são bastantes confiáveis, como uma rede local. 3.2 Real-time Transport Protocol O Real-time Transport Protocol (RTP) [16] é um protocolo da camada 5 do modelo TCP/IP utilizado para entregar áudio e vídeo sobre redes IP. Enquanto o RTP é utilizado para transmitir streams multimédia, o RTP Control Protocol (RTCP) é utilizado, em simultâneo, para monitorizar estatísticas da transmissão, QoS e controlo de sessões. Figura 6: Formato de um pacote RTP. Transmissão de dados sobre IP 13  Version (2 bits): indica a versão do protocolo RTP.  Padding (1 bit): indica a existência de padding no final do payload do pacote RTP.  Extension (1 bit): se ativo, indica a existência de extensão no cabeçalho do pacote.  CSRC count (4 bits): indica o número de identificadores Contributing Source presentes após o cabeçalho fixo.  Market (1 bit): permite a definição, por parte de perfis, de eventos, como, por exemplo, o fim de uma frame ou o modo de varrimento da stream.  Payload Type (7 bits): indica o tipo de dados presentes no payload do pacote, tendo em conta os vários perfis existentes.  Sequence Number (16 bits): número de sequência controlado pelo emissor, permitindo a ordenação sequencial de pacotes.  Timestamp (32 bits): referência temporal dados dados transportados no payload do pacote; pacotes diferentes contento informação do mesmo frame devem ter o mesmo timestamp.  Synchronization Source (32 bits): indica a fonte de contribuição do Timestamp e do Sequence Number; todos os pacotes de um mesmo SSRC fazem parte da mesma linha temporal.  Contributing Source (32 bits, cada): indica os SSRC de todas as fontes contribuidoras para o conteúdo do payload do pacote. O protocolo RTP fornece informação dos timestamps dos pacotes, números de sequência e do formato de codificação dos dados. Para além disso, o cabeçalho dos pacotes RTP contém um campo destinado à extensão do cabeçalho, com novos campos personalizados, tornando o RTP num protocolo flexível e facilmente extensível. A existência do timestamp e do número de sequência nos cabeçalhos do RTP permite a um recetor reconstruir a sequência correta de pacotes, assim como estimar quantos pacotes foram perdidos. Apesar de ter sido desenhado para ser independente de que protocolo é utilizado no transporte, as implementações de RTP focam-se na utilização do protocolo UDP, em detrimento do TCP, devido ao seu propósito real-time, isto é, entrega dos dados da forma mais rápida possível. Transmissão de dados sobre IP 14 3.3 Dynamic Adaptative Streaming over HTTP O Dynamic Adaptative Streaming over HTTP (DASH) [17] é uma técnica de streaming de conteúdo multimédia utilizando um servidor de Hypertext Transfer Protocol (HTTP), que faz parte da camada 7 do modelo OSI. Apesar do DASH ser agnóstico às camadas por baixo da camada da aplicação, este utiliza o protocolo TCP para transporte dos dados. Ao partir o conteúdo multimédia em pequenos segmentos, o DASH permite servir o cliente com pequenos segmentos de informação, em diferentes representações, permitindo que essas representações sejam selecionadas de acordo com características como a largura de banda disponível, a resolução do ecrã, o tipo de dispositivo e as preferências do utilizador. Figura 7: Arquitetura geral do DASH. Na prática, o servidor disponibiliza o conteúdo em vários bit rates diferentes. No início de uma sessão, um cliente DASH requer ao servidor um Media Presentation Description (MPD), um manifesto em eXtensible Markup Language (XML) que descreve o conteúdo disponível (e os metadados a ele associado). À medida que o cliente DASH vai fazendo buffering e reproduzindo o conteúdo, vai também analisando a variação da largura de banda da rede e, dependendo do resultado dessa análise, decide quais os próximos segmentos a descarregar (com maior ou menor bit rate) de forma a manter um buffering adequado. Uma latência reduzida é obtida utilizando segmentos de pequena duração e um número reduzido de segmentos em buffer. No caso oposto, uma maior estabilidade pode ser conseguida utilizando um buffer com mais segmentos. Esta troca entre estabilidade e latência baixa deve ser analisada caso a caso: num cenário em direto (live) normalmente pretende-se priorizar o pequeno desfasamento entre o tempo de origem e o tempo de transmissão, enquanto num cenário VOD a estabilidade da transmissão (sem pausas) será o principal objetivo. Em resumo, o DASH utiliza um algoritmo que adapta o streaming ao bit rate máximo que as condições de rede permitem, de forma a entregar ao utilizador conteúdo com o QoE esperado. Transmissão de dados sobre IP 15 3.4 Difusão da informação A difusão da informação numa rede pode ter diversos intervenientes, dependendo do diferente número de recetores a que uma mensagem se destina. Se uma mensagem tiver como destinatário um único nó numa rede, então trata-se de uma comunicação unicast. No caso da mensagem se destinar a ser difundida por todos os elementos da rede, então temos um timo de comunicação em broadcast, um “anúncio” para a rede. Figura 8: Unicast, multicast e broadcast. O multicast, por sua vez, refere-se à técnica de enviar mensagens para todos os nós na rede que se mostraram interessados em receber mensagens desse tópico. Para tal, todos os nós interessados devem enviar mensagens join e leave para se juntarem, ou saírem, de um grupo (endereço) multicast. Por sua vez, um emissor pode enviar uma mensagem para esse endereço multicast, possibilitando a difusão da mensagem a todos os nós interessados sem que o emissor tenha conhecimento prévio de quantos recetores existem na rede. Isto permite que ao longo da execução de um determinado sistema, os recetores entrem em e saiam do grupo, sem que o emissor tenha que alterar o seu modo de funcionamento. Da mesma forma, reduz complexidade do lado do emissor, ao não o obrigar a gerir os recetores existentes. Capítulo 4 Produção Televisiva Digital Durante muito tempo os consumidores estavam satisfeitos por utilizar um hardware específico para uma única função. Mas a aplicação da tecnologia digital à produção, distribuição e consumo de conteúdos multimédia permitiu que este conteúdo pudesse ser consumido em qualquer lugar, a qualquer hora e em qualquer dispositivo [1]. Figura 9: Triângulo da indústria multimédia [1]. A produção de televisão digital num cenário multiplataforma requer a resposta a desafios tecnológicos, criativos e de negócio, o chamado “triângulo da indústria multimédia” (Figura 9). Produção Televisiva Digital 18 Esta perspetiva implica construir uma infraestrutura multiplataforma de produção de conteúdos que suporte a distribuição das mais variadas tecnologias para diferentes plataformas, onde, cada uma delas, contém funcionalidades e propósitos distintos [1]. A infraestrutura de um estúdio de produção televisiva é, na verdade, um sistema de sistemas que se devem integrar e cuja interoperabilidade entre os diferentes dispositivos deve ser assegurada [1]. Aliás, a grande diversidade de equipamentos, formatos, arquiteturas e, generalizando, diferentes formas de operar das várias tecnologias presentes num estúdio de produção televisiva, elevam os custos e o overhead na produção [5], [8]. Esta dificuldade em introduzir novas tecnologias na cadeia de produção impede os broadcasters de aceder a novos mercados de uma forma eficaz e eficiente: o custo de suportar um novo canal de distribuição e preenchê-lo com conteúdos é elevado; como tal, o preço do espaço publicitário aumenta para um valor mais elevado do que aquele que os anunciantes, dos quais o canal depende, estão dispostos a pagar. Desta forma, gera-se uma dependência cíclica na supply chain [8]. 4.1 Ciclo de Vida dos Conteúdos O ciclo de vida dos conteúdos multimédia compreende quatro fases essenciais: criação, montagem, distribuição e consumo [1] (Figura 10). Figura 10: Ciclo de vida genérico para conteúdos televisivos [1]. Inicialmente os conteúdos (vídeo, áudio, gráficos) são produzidos (criação); de seguida, devem ser montados de forma a se obter a visão idealizada para determinado programa (montagem); o sinal deve, então, ser transmitido para os vários canais de consumo (distribuição) e, finalmente, consumido pelos vários dispositivos que o utilizador final possui. No âmbito desta dissertação, analisemos com mais detalhe as duas primeiras fases. Seja áudio, vídeo ou elementos gráficos, todos eles contribuem para a criação de uma “história” e de uma experiência imersiva. A criação significa, tal como a própria palavra indica, a conceção criativa de uma ideia. Para tal, um estúdio de produção necessita de estar devidamente equipado (câmaras, microfones, luzes, por exemplo) e configurado (ligações entre equipamentos e aplicações que os controlam e gerem, por exemplo) [1]. Produção Televisiva Digital 19 Isto significa que o desafio de criar um programa novo, original, que cative a audiência, está não só relacionado com a conceção criativa da ideia, mas também com as capacidades que o estúdio de produção disponibiliza. Concluindo: os broadcasters enfrentam o desafio de produzir conteúdo de alta qualidade com acesso a recursos limitados. Dessa forma, é importante que os workflows e a infraestrutura permitam, de forma eficiente, a criação de conteúdo multimédia para as várias plataformas de consumo. 4.2 Workflows e Infraestrutura Apesar da infraestrutura de um estúdio de produção televisiva ser bastante complexa, as interações de alto nível podem ser descritas como mostra a Figura 11. Os conteúdos chegam ao estúdio de produção de forma remota, ou foram gravados previamente e já estão armazenados. O grafismo é produzido, o áudio e o vídeo são misturados no Program Control Room (PCR). No Master Control Room (MCR) são adicionadas as legendas, logótipos e os anúncios publicitários. O sinal do programa é, então, modulado e transmitido [1]. Figura 11: Diagrama funcional da infraestrutura de produção televisiva [1]. Apesar das interações na infraestrutura de um estúdio de produção televisiva parecerem triviais, a necessidade dos broadcasters de atingirem um público alargado é um desafio de articulação de conteúdos, equipas e equipamentos. Interessa, portanto, compreender quais os workflows que permitem a produção de conteúdos multiplataforma, para os vários ecrãs, formatos e dispositivos existentes. Produção Televisiva Digital 20 4.2.1 Workflow Linear Num workflow linear (Figura 12) o conteúdo é criado e formatado de forma independente para cada canal específico. Isto significa não só esforços redobrados para produzir o mesmo conteúdo para diferentes canais, como também duplicação de recursos ao longo da cadeia de produção. Figura 12: Produção independente e específica a cada plataforma e canal [1]. Um workflow linear implica uma produção específica a cada plataforma e canal de distribuição, ou seja, para cada nova plataforma ou canal de distribuição é necessário replicar a infraestrutura existente. Esta redundância deve-se, principalmente, à falta de interoperabilidade do equipamento existente e da pouca flexibilidade da infraestrutura na adoção de novas tecnologias, workflows e formatos [5]. 4.2.2 Workflow Convergente Obviamente que um workflow linear não é escalável, pois à medida que novas tecnologias (plataformas, canais de distribuição, formatos, codecs) vão aparecendo, não só a infraestrutura necessária se torna insustentável, como os recursos despendidos estão a ser utilizados ineficientemente. Assim, torna-se necessário reduzir a duplicação de tarefas, o que, por sua vez, implica compreender quais as tarefas e processos que são comuns aos vários canais de distribuição. Produção Televisiva Digital 21 Figura 13: Produção multiplataforma através de um workflow convergente [1]. Um workflow convergente (Figura 13) assenta no princípio de “create once, use everywhere”, isto é, o conteúdo é criado uma única vez e utilizado nos diferentes canais de distribuição. Para tal, a infraestrutura deve ser facilmente configurada para se adaptar às diferentes necessidades de cada canal. A eficiência deste processo de produção multiplataforma provém de esforços de engenharia de software em conseguir resolver os problemas de forma inteligente (“work smarter, not harder”, em inglês). Em verdade, é disso que se trata a produção convergente: construir uma infraestrutura para produzir conteúdos para os vários canais de distribuição sem grande esforço adicional. Ao eliminar a repetição tarefas redundantes e ao automatizar processos repetitivos, o aumento da eficiência na produção permite reduzir o “time to air”, ao mesmo tempo que maximiza a utilização de recursos [1]. O workflow convergente para produção multiplataforma consiste em três processos fundamentais, tal como a Figura 14 mostra. No processo de produção obtém-se o áudio, vídeo, grafismos, produz-se o conteúdo final a partir desse conteúdo e criam-se os templates para os diferentes canais de distribuição. De seguida, todo o conteúdo é gravado numa base de dados, onde é feita a gestão de conteúdos. Na fase de conversão, os conteúdos são formatados de acordo com a plataforma a que se destinam e comprimidos para serem transmitidos. Produção Audiovisual sobre IP 28 A VISION Cloud, para além de tirar proveito da arquitetura e escalabilidade da cloud, permite, ainda, o acesso ao mesmo conteúdo em simultâneo por diferentes utilizadores e em diferentes codificações. 5.1.2 IP-Studio-Link O IP-Studio-Link [5] é uma placa eletrónica reconfigurável, equipada com várias interfaces de vídeo, aúdio e dados comuns à produção televisiva. Apesar dos autores reconhecerem que a gestão e supervisão de um estúdio televisivo poderá ser realizada totalmente através de software e que a cloud pode permitir que todos os sinais de áudio e vídeo possam estar disponíveis em qualquer parte do estúdio, o trabalho por eles desenvolvido foca-se apenas na utilização da Ethernet/IP para o transporte das streams. Outras operações, como o switching de vídeo, são realizadas por um mixer externo (físico). Resumindo, o IP-Studio-Link apenas converte os sinais de vídeo, áudio e sincronização em pacotes IP e vice-versa, utilizando um switch de 1Gb/s em conjunto com o Precision Time Protocol (PTP). 5.1.3 IP-Studio O IP-Studio [23] é um protótipo que permite criar interfaces entre os vários equipamentos presentes num estúdio de produção televisivo, materializando o modelo de dados proposto pela JT-NM [24] e que o Networked Media Open Specification (NMOS) especifica. A ideia geral do IP-Studio é que tudo na cadeia de produção televisiva é importante e, portanto, deve ser registada para poder ser utilizada mais tarde, seja áudio, vídeo, metadados ou outras informações. O IP-Studio foi testado com sucesso, pela estação televisiva BBC, nos Glasgow Commonwealth Games 2014 [25], onde foi produzido um cenário multi-câmara”IP-end-to-end”. A produção do evento foi distribuída pelos vários locais onde o evento se realizou, em Glasgow. O vídeo era entregue desde Glasgow para Londres, onde era acrescentado os comentários e o mixing de áudio. Para além disso, também era produzida uma versão DASH que era disponibilizada no website da BBC. Para a produção deste evento live, de forma distribuída, dentro do IP-Studio foi utilizado o protocolo RTP para transmitir dados multimédia entre os vários nós, enquanto o MPEG-DASH foi utilizado para obter dados multimédia pré-gravados, devido a ser um serviço em que a latência não é crítica e se privilegia a confiabilidade dos dados. A sincronização dos vários nós foi obtida utilizando o Precision Time Protocol. Todos os nós presentes na rede eram facilmente monitorizados utilizando uma dashboard web que permitia obter estatísticas como a latência, Produção Audiovisual sobre IP 29 jitter, erros, pacotes perdidos, entre outros dados de interesse, de forma a manter a emissão estável. O IP-Studio conseguiu minimizar a quantidade de equipamento que necessitou de ser instalado no local do evento, dada a natureza distribuída da produção. Consequentemente, a necessidade de recursos humanos foi, obviamente, menor. 5.1.4 Stagebox O Stagebox [2] é uma solução desenvolvida para ser integrada em workflows de produção em direto, assim como em tarefas de pós-produção, como edição e armazenamento de vídeo. O Stagebox utiliza uma placa física onde é feito o ingest de vídeo, aliviando o processamento de vídeo não comprimido para hardware. O sincronismo entre streams é obtido utilizando o PTP. O Stagebox foi testado em três eventos em direto, reduzindo, com sucesso, o número de formatos que foram precisos suportar e proporcionando uma redução de custos significativa ao reduzir a necessidade de destacar equipamento e recursos humanos para o local onde decorreu o evento. 5.2 SMPTE 2022-6 O SMPTE ST 2022-6 [26] é um standard publicado pela SMPTE, pertencente à família de standards SMPTE ST 2022 (ainda em desenvolvimento) que permite a utilização da tecnologia IP na indústria de broadcasting. O ST 2022-6 define o transporte de SDI sobre IP utilizando o protocolo RTP, pelo que é apelidado de “SDI over IP”. Ao encapsular o payload do SDI em pacotes IP, o ST 2022-6 permite empacotar o sinal SDI em vários pacotes de 1376 bytes cada, transmitir através de uma rede Ethernet, receber os pacotes e voltar a reconstruir o sinal SDI. O que, apesar de permitir interoperabilidade com outros equipamentos que utilizem SDI, significa que não existe separação entre as várias streams existentes no SDI [27]. Imagine-se, por exemplo, que se pretende modificar o áudio que faz parte de uma stream SDI que é transportada com o vídeo correspondente. Nesse caso, será necessário ter que lidar com o vídeo e todo o overhead que este trará para o sistema, quando apenas se pretende modificar o áudio. Ou seja, ao não existir separação entre os vários conteúdos presentes no SDI, não existe flexibilidade no transporte de apenas uma parte do conteúdo. Produção Audiovisual sobre IP 30 5.3 RTP Payload Format for Uncompressed Video O RFC 4175 [28] é uma norma que especifica o perfil para o transporte de vídeo não comprimido sobre RTP. O RFC 4175 acrescenta uma extensão de 16 bits denominada de “Extended Sequence Number” que estende o já existente número de sequência. A combinação destes dois valores fazem com que seja possível um número com alcance de 32 bits, permitindo enviar e receber pacotes a uma taxa bastante elevada. Para pacotes de, pelo menos, 1000 bytes, a uma taxa de débito de cerca de 1 Gbps, o número de sequência dos pacotes RTP (sem a extensão) esgotar-se-ia em 0.5 segundos, o que pode ser problemático para ambientes em que a latência é maior que meio segundo. 5.4 Arquitetura de Referência JT-NM Esta arquitetura de referência, idealizada por um consórcio formado entre a European Broadcasting Union, a SMPTE e a Video Services Forum, denominado de Joint Task Force on Networked Media (JT-NM) Reference Architecture v1.0 [24], reúne boas-práticas, recomendações e frameworks para que possa existir interoperabilidade entre equipamentos de diferentes fabricantes na transição do SDI para o IP. O JT-NM define um modelo conceptual (incompleto na Figura 20, focando apenas os aspetos necessários e relevantes tendo em conta o âmbito desta dissertação) que permite mapear os workflows de forma a existir a desejada interoperabilidade. No “coração” das operações está a rede, tipicamente Ethernet. Os Nodes estão ligados à rede e são eles que criam a infraestrutura existente, seja com capacidade de processamento, armazenamento ou interfaces para outros nós. Os Devices, que podem ser virtuais ou físicos, aprovisionados em nós existentes na rede, são agregações funcionais de Capabilities, aptidões, para realizar determinadas Tasks. Um Device pode ser uma câmara de filmar, um adaptador de SDI para IP ou um mixer de áudio, por exemplo. Um Source é um conceito abstrato que representa a origem de dados provenientes de um Device. Um Device pode fornecer vários Sources, por exemplo, uma câmara de vídeo fornece um Source de áudio e outro de vídeo. Os Sources materializam-se em Flows, que são sequência de Grains de um mesmo Source. Um Source pode fornecer diferentes Flows, por exemplo um Source de vídeo pode fornecer um Flow uncompressed (sem compressão) e um Flow codificado em H.264. Produção Audiovisual sobre IP 31 Figura 20: Modelo conceptual simplificado da arquitetura de referência do JT-NM [24]. Um Grain, por sua vez, é o elemento atómico que representa um elemento de uma essência, como um frame de vídeo, ou samples de áudio correspondentes a um frame, por exemplo. Cada Grain é constituído pelo conteúdo que transporta (vídeo, áudio ou metadados) e por um timestamp no qual ele foi criado. O timestamp deve ser derivado do relógio presente no Node, que está sincronizado com os restantes Nodes da rede, com uma precisão ao nível dos nanosegundos, utilizando o Precision Time Protocol [29]. Figura 21: Relação entre Sources, Flows e Grains [23]. Produção Audiovisual sobre IP 32 A flexibilidade deste modelo conceptual permite situações como a da Figura 21. Com uma base temporal comum, é possível mapear Grains de Flows do mesmo Source de vídeo. Da mesma forma, a sincronização entre o áudio e o vídeo é independente do Flow de vídeo que é utilizado. Para trocarem Flows entre si, os Devices devem registar-se como disponibilizadores de output (Sender) e como interessados em determinado input (Receiver). Um Sender pode ser, por exemplo, uma câmara e um Receiver um monitor. Para que esta informação esteja devidamente articulada e possa ser utilizada para a definição de workflows, são definidos 3 blocos fundamentais sobre quais este modelo de dados assenta: Timing, Identity e Discovery & Registration. Cada Node na rede deve, após o seu aprovisionamento, registar-se a si e aos Devices, Sources, Flows, Senders e Receivers que disponibiliza, de forma que outros nós os possam descobrir e obter a informação apropriada sobre cada um (Discovery & Registration). Da mesma forma, cada elemento presente na infraestrutura deve ser fácil e unicamente identificável, de forma a poder ser referenciado e utilizado. As relações entre recursos devem ser feitas expressamente, com recurso aos identificadores (Identity). Por fim, a utilização de timestamps, ao nível dos Grains, permite manter a consistência das operações realizadas e, consequentemente, a assegurar que os Flows estão corretamente alinhados (Timing). 5.5 NMOS O JT-NM descreve um modelo conceptual de interoperabilidade, que apenas reúne uma arquitetura de referência e uma coleção de boas práticas. Como tal, o Networked Media Open Specifications (NMOS), criado pela Advanced Media Workflow Association, pretende ser uma família de especificações que pretende criar frameworks que permitam a interoperabilidade pretendida pelo JT-NM. O NMOS baseia-se no modelo conceptual de dados proposto pelo JT-NM, de forma a adicionar identidade e relações entre o conteúdo e os equipamentos. Independentemente da tarefa específica que cada Node desempenha, a visão lógica de um Node segundo o NMOS (Figura 22) permite criar um nível de abstração suficiente para garantir a modularidade e expansibilidade esperadas para se adaptar a diferentes necessidades. Produção Audiovisual sobre IP 33 Figura 22: Visão lógica do Node proposto pelo NMOS [30]. O NMOS não especifica como cada Node deve funcionar internamente (a cinza na Figura 22), apenas especificando quais as interfaces que devem ser expostas. Cada Node deve expor transações HTTP realizadas por uma API REST, de forma a permitir controlar o modelo de dados presente em cada Node. Isto permite à lógica de controlo do Node receber ordens e tomar as ações necessárias. Estas transações estão descritas na especificação “AMWA NMOS Discovery and Registration Specification (IS-04)” 7 proposta pelo NMOS. 5.5.1 RTP NMOS Para transportar conteúdo entre Senders e Receivers, o NMOS especifica o mapeamento de identificadores de Flow e Source, assim como timestamps, nos cabeçalhos do RTP. Ao não especificar nenhum formato para o conteúdo do RTP, o NMOS pretende ser agnóstico quanto ao codec utilizado. Isto significa que o NMOS incentiva a utilização da transmissão multimédia via RTP sem modificação dos RFCs existentes. Segundo o NMOS, o primeiro e o último pacote de cada Grain devem conter as extensões ao cabeçalho RTP. As extensões são essenciais à coesão do modelo proposto e permitem: a) prover os pacotes RTP com informação que lhes dê significado ao nível aplicacional; b) sincronizar Flows. O Sync Timestamp dá uma referência absoluta na qual uma essência de um Grain foi captura ou reproduzida. Dois Grains de áudio e vídeo coincidentes devem partilhar o mesmo Sync Timestamp, que se deve manter inalterado independentemente do processamento que o Grain sofre. 7 https://github.com/AMWA-TV/nmos-discovery-registration Produção Audiovisual sobre IP 34 O Origin Timestamp fornece uma referência absoluta em que a essência de um Grain foi criada (isto é, capturada). Esta relação está intimamente relacionada com a geração de Flows provenientes de um mesmo Source. No caso de uma captura de direto, por exemplo, o Origin Timestamp coincide com o Sync Timestamp. O Flow Identifier é uma referência de identidade, pois referencia a que Flow o Grain pertence. Da mesma forma, o Source Identifier identifica o Source do qual o Flow atual deriva, permitindo compreender qual a sua origem. 5.5.2 Sincronização Com o mapeamento que o NMOS propõe, a tarefa de sincronizar vários Flows torna-se trivial. Como cada Grain tem uma referência de tempo comum, é possível sincronizar, quando necessário, os vários Flows intervenientes. Analisemos, por exemplo, a Figura 23. À medida que, quer a essência de vídeo, quer a essência de áudio vão sendo adquiridas, o dispositivo de captura gera timestamps que são estarão associados aos Grains resultantes. À medida que os Grains vão sendo transportados na rede, o dispositivo que os recebe, vai-os colocando num buffer ordenado pelo timestamp. Daí, o relógio utilizado para a apresentação (Presentation Clock) dos Flows de vídeo e áudio deve ter um deslocamento do relógio original (Master Clock) de forma a compensar os atrasos introduzidos pelo processamento (decoding de vídeo, por exemplo) e pela transmissão na rede. Figura 23: Exemplo de sincronização. A identidade de cada Grain é assegurada pelo par Flow ID/Synchronization Timestamp. Isto significa que, por exemplo, na criação de um novo Flow, como num processo de encoding, não é perdida a relação temporal de Flows pertencentes à mesma Source. Produção Audiovisual sobre IP 35 Na prática, a identidade de cada Grain permite sincronizar facilmente Flows provenientes de Sources live, não só entre si, mas também com Flows que já se encontram armazenados e vão ser diferidos. 5.6 Conclusão Tal como se pôde verificar, apesar de existir um interesse alargado em evoluir a produção televisiva para tecnologias suportadas pelo IP e pela cloud, não existe uma solução que permita, simultaneamente, aproveitar as vantagens que ambos oferecerem. A utilização da cloud tem-se focado bastante no armazenamento de conteúdo multimédia, apesar de [14] indicar o cloud-based transcoding como umas das potenciais aplicações da cloud no domínio da produção televisiva. Apesar disso, nenhum dos casos de estudo analisados utiliza a cloud para esses efeitos. Por outro lado, protótipos como o IP-Studio-Link e o Stagebox mostraram-se funcionais, mas baseados em placas físicas para ações que podiam ser virtualizadas e, portanto, realizadas na cloud, num ambiente resiliente, controlável, adaptativo e elástico. Da mesma forma, esses protótipos são opções muito específicas para determinados worklflows e ambientes, não proporcionando a modularidade e expansibilidade que seria de esperar para um ambiente tão dinâmico e abrangente como a produção televisiva. É importante referir que o IP-Studio é uma proposta interessante sob o ponto de vista da abstração dos componentes que compõe a produção, testando uma framework que permite a interoperabilidade entre esses mesmos componentes e cuja arquitetura pode ser a base para uma aplicação distribuída servida como SaaS. O JT-NM e a concretização que o NMOS cria podem ser pontos de partida para o desenvolvimento do tão cobiçado “full IP Studio”, pelo que será bastante interessante tentar compreender o rumo que ambos irão tomar e se a indústria convergirá nas suas especificações. Capítulo 6 Virtualização da Produção Móvel A cobertura de um evento remoto pode ser algo simples como uma simples câmara ligada a uma OB van, as várias câmaras distribuídas pelo recinto do evento, ou, até mesmo, um cenário complexo com várias OB vans. A possível complexidade que a produção de eventos em direto possibilita, principalmente grandes eventos, resultam não só num desafio tecnológico, como também num desafio logístico [2]. Apesar da tecnologia IP já estar bastante presente em pós-produção file-based, em cenários de produção live o SDI predomina por completo as soluções disponíveis [1]. Com a tendência na indústria de broadcasting em utilizar soluções de software baseadas em IP [13], a capacidade de realizar a produção de eventos em direto utilizando um ambiente cloud controlado por software pode significar reduzir custos e, simultaneamente, flexibilizar a produção. Interessa, portanto, analisar a metodologia atual e compreender de que forma se pode tirar partido da tecnologia IP em produção live. 6.1 Contexto e Método Atual Na cobertura de eventos televisivos em direto, como por exemplo um jogo de futebol, existem vários intervenientes, nem sempre geograficamente próximos, que trabalham em conjunto: as várias câmaras espalhadas pelo recinto, as entrevistas rápidas junto ao recinto, a produção responsável por adicionar gráficos e animações que tornam a experiência de visualização mais rica e intuitiva e os comentadores e analistas, que acompanham o evento em direito, e que podem estar tanto no recinto como no estúdio. Virtualização da Produção Móvel 44  O output será MPEG-TS, entregue por RTP, com apenas o PES de vídeo, nas mesmas condições das streams de input. 6.4.2 Implementação Da aplicação proposta na Figura 26, o protótipo desenvolvido focou-se na validação da arquitetura proposta, através do desenvolvimento do Input Distributor, do Proxy Transcoder e do Output (Figura 28). O formato de entrada e de saída das streams na aplicação será o mesmo, MPEG-TS transportado por RTP, possibilitando cenários mais complexos, como por exemplo ter várias aplicações encadeadas em cascata. Por sua vez, as versões de baixa resolução serão servidas pelo Proxy Transcoder em MPEG-DASH. A escolha dos Nodes a desenvolver permite testar a arquitetura e a sua validade, nomeadamente:  Testar o input na cloud, encapsulado em MPEG-TS, uma tecnologia largamente utilizada na indústria de broadcasting.  Testar a transmissão de vídeo uncompressed e a respetiva sincronização.  Testar as operações de demux e decode e de encode e mux em ambientes virtualizados.  Validar as especificações propostas pelo NMOS.  Estudar métricas como capacidade de processamento, utilização da memória entre outras. Figura 28: Contextualização do protótipo desenvolvido. Virtualização da Produção Móvel 45 Para desenvolver os Nodes de forma modular e isolada, foi escolhida a tecnologia Docker, devido às vantagens que esta possibilita e que foram discutidas no capítulo 2.2. Assim, cada nó é um container Docker com base no Ubuntu Server 14.04 LTS 8 . Esta decisão permite aproximar o ambiente de desenvolvimento ao possível ambiente de produção, tendo em conta que vários serviços cloud já possibilitam, atualmente, o aprovisionamento direto de containers Docker nas suas infraestruturas. Para cada stream MPEG-TS de input é aprovisionado um container Docker com o Input Distributor e outro container com o Proxy Transcoder correspondente. O fluxo de dados (Figura 29) mostra, alto nível, o ciclo de vida do conteúdo: é recebido por RTP MPEG-TS no Input Distributor, enviado por RTP para um endereço multicast que o Proxy Transcoder pode subscrever para gerar uma versão proxy, enquanto o Output pode subscrever para voltar a devolver o Flow como MPEG-TS transportado por RTP. Para a transmissão de vídeo sem compressão ,o NMOS incita à utilização do RFC 4175, já analisado no capítulo 5.3. Adicionalmente, estão também presentes os cabeçalhos específicos do NMOS. Figura 29: Fluxo de dados de uma stream na aplicação. A escolha de um endereço multicast para cada Flow, ao contrário do que vária literatura sugere (por exemplo, [2], [3], [21]) permite, mais facilmente, não só possíveis melhoramentos na rede, como também facilita a filtragem dos pacotes. Ao analisarmos mais detalhadamente a Figura 29 e percebendo as várias transformações que o conteúdo vai sofrendo, conseguimos compreender a necessidade de vários módulos comuns ao longo dos diferentes Nodes. 8 http://releases.ubuntu.com/14.04/ Virtualização da Produção Móvel 46 Figura 30: Visão aprofundada do fluxo de dados. No Input Distributor a stream (compatível com a norma RFC 2250 [31]) é recebida pelo RTP Receiver (utilizando a biblioteca JRTP 9 ) e os pacotes RTP são desempacotados (novamente utilizando a biblioteca JRTP) pelo RTP Unpacker. Os metadados presentes nos cabeçalhos dos pacotes RTP permitem reordená-los (se necessário), utilizando o número de sequência. De notar que o RTP Receiver utiliza um fila de prioridade (ordenada pelo número de sequência do RTP) para ordenar pacotes que cheguem fora de ordem ou repetidos. O demuxing dos pacotes TS presentes no payload dos pacotes RTP é feito utilizando a biblioteca FFMPEG 10 , obtendo-se, também, metadados relativos à informação que as várias tabelas do MPEG-TS possuem. A partir daí, as essências são tratadas separadamente. Quer o vídeo, quer o áudio, ambos não comprimidos, são transformados em Grains, resultantes da associação com os metadados disponíveis. Para que os Grains possam ser transmitidos entre os vários Nodes, é necessário voltar a empacotá-los em pacotes RTP (RTP Packer). Os pacotes que daí originam possuem os cabeçalhos propostos pelo NMOS. No Node Proxy Transcoder, um módulo RTP Receiver é instanciado para receber o par de Flows (áudio e vídeo) que subscreveu. De seguida, acontece o processo inverso de desempacotar um pacote RTP e transformá-lo num Grain. O vídeo, por sua vez, volta a ser comprimido de forma a ser gerada uma versão de baixa resolução para a web. 9 http://research.edm.uhasselt.be/~jori/page/index.php 10 https://www.ffmpeg.org/ Virtualização da Produção Móvel 47 Na geração do MPEG-DASH, o MPD é gerado de forma a obter chunks de curta duração (2 segundos), de forma a minimizar o atraso em relação ao “real-time”. O Output realiza as operações inversas do Input Distributor: recebe os Flows que subscreveu por RTP, recuperando os metadados transportados e, portanto, reconstruindo os respetivos Grains. O vídeo volta a ser comprimido, multiplexado em MPEG-TS e enviado para o exterior da cloud utilizando RTP. Figura 31: Repetição de tarefas ao longo do fluxo de dados. Compreende-se, portanto, que existem várias operações que vão sedo repetidas ao longo do ciclo de vida da aplicação, tal como a Figura 31 mostra: cores iguais assinalam o mesmo módulo, enquanto os módulos a cinza são módulos únicos. Estas operações estão maioritariamente relacionadas com interfaces de enviar e receber conteúdo por RTP, pelo que não só podem ser reaproveitadas para os Nodes já definidos, como também para possíveis novos Nodes que expandirão as atuais funcionalidades. 6.4.3 Interface Web Foi, também, desenvolvida uma interface web simples, de forma a poder observar as streams proxy. Para tal, foi utilizado o leitor Dash.JS 11 . Este leitor tem a restrição de apenas reproduzir vídeo com uma amostragem 4:2:0 e um espaço de cor em 8 bits, pelo que o vídeo foi convertido no Proxy Transcoder segundo estas restrições. 11 https://github.com/Dash-Industry-Forum/dash.js Virtualização da Produção Móvel 48 Figura 32: Interface Web. A interface desenvolvida (Figura 32) apresenta as streams proxy, ao mesmo tempo que fornece estatísticas do buffering realizado pelo leitor. Para além disso, do lado direito podemos observar o relógio, que marca os minutos e segundos, permitindo verificar possíveis atrasos entre as várias streams. Capítulo 7 Resultados e Discussão Neste capítulo pretende-se estudar métricas relativas aos testes utilizados para garantir o QoS do protótipo desenvolvido, de forma a validar a arquitetura e consequente implementação. Apresenta-se o ambiente de teste, a metodologia utilizada, os resultados e a discussão dos mesmos, avaliado a escalabilidade da solução. 7.1 Ambiente de Teste e Metodologia Na realização dos testes, foi utilizado um cenário de testes como mostra a Figura 33. No “PC”, foi utilizada uma interface de linha de comandos do FFMPEG para transmitir as streams MPEG-TS de teste por RTP. No “Host” foi instalado o Docker Engine, de forma a ser possível correr containers Docker. Este ambiente pretende ser um ambiente de teste e desenvolvimento. Ao correrem sobre o engine do Docker, os containers não têm conhecimento se estão todos a correr na mesma máquina física, aproximando este ambiente de um ambiente virtualizado sobre o qual a aplicação deve correr. Na Tabela 2 estão descritas as principais características de ambas as máquinas. Figura 33: Cenário de testes. Resultados e Discussão 50 Tabela 2: Características das máquinas de teste. PC Host CPU Intel Core I7-4770 @ 3.4GHz 2x Intel Xeon CPU E5640 @ 2.67GHz Memória RAM 8 GB 32 GB DDR3 1333 MHz Placa de Rede Intel Ethernet I217-LM 2x NetXtreme II BCM5716 Gigabit Ethernet Sistema Operativo Windows 10 Enterprise Ubuntu Server 14.04 LTS O Maximum Transmission Unit (MTU) da rede é de 1500 bytes, com IGMP e multicast ativo. Foram realizados testes com três vídeos diferentes, cujas principais características estão descritas na Tabela 3. A utilização de vídeos onde as imagens têm de altura 1088 pixéis deve-se à maior performance por parte da biblioteca libx264 que o FFMPEG utiliza para o encoding e decoding de vídeo H.264. Tabela 3: Características dos vídeos de teste. Vídeo #1 Vídeo #2 Vídeo #3 Tamanho em Disco 206 MB 2.41 GB 34.6 MB Duração 4 min 27 seg 53 min 56 seg 31 seg Dimensões 1920x1088 1920x1088 1920x1088 Espaço de Cor 4:2:0 4:2:0 4:2:0 Profundidade de Cor 8 bits 8 bits 8 bits Modo de Varrimento progressivo progressivo progressivo 7.2 Métricas e Resultados Para analisar a performance do protótipo desenvolvido, foram monitorizadas as seguintes métricas:  Largura de banda utilizada.  Utilização do CPU.  Utilização da memória RAM. Resultados e Discussão 51 À entrada da cloud, em cada Input Distributor, a carga medida encontra-se na Tabela 4. Apesar destes valores serem relativamente baixos, é de realçar que o valor de entrada pode ter valores bastante variáveis. Tabela 4: Carga medida à entrada de um Input Distributor. Vídeo #1 Vídeo #2 Vídeo #3 Média (Mbit/s) 7.70 7.92 7.64 Máxima (Mbit/s) 12.25 18.14 17.84 Analisemos, para o vídeo #3, por exemplo, as métricas estipuladas, de forma a compreender a exequibilidade da arquitetura proposta e do protótipo desenvolvido. A Tabela 5 apresenta os pacotes enviados e recebidos para cada um dos módulos. 7.2.1 Largura de Banda Utilizada Tabela 5: Tráfego para o Vídeo #3. Input Distributor Proxy Transcoder Output Recebidos 29 650 1 923 978 1 923 978 Enviados 1 923 978 - 29 650 Ao analisar a Tabela 5, compreende-se que não existiu perda de pacotes da transmissão entre os componentes, isto é, todos os pacotes enviados pelo Input Distributor foram recebidos pelo Proxy Transcoder e pelo Output. De notar que apesar do número de pacotes recebidos pelo Input Distributor e enviados pelo Output serem o mesmo, não teria forçosamente de acontecer, pois os pacotes podem ter tamanhos diferentes. Sabendo que o vídeo #3 tem 31 segundos de duração e que o foram transferidos 1 923 978 pacotes, obtemos 62 064 pacotes por segundo. Como cada pacote tem 1300 bytes de payload mais 40 bytes de header (RTP/UDP/IPv4), um pacote tem 1340 bytes de tamanho. Dessa forma, cada Flow de vídeo implica cerca de, em média, 83 165 760 bytes por segundo, ou seja, aproximadamente 665 Mbits/s. 7.2.2 Utilização do CPU Quanto à utilização do CPU por parte dos containers Docker, que está espelhada na Figura 34, é necessário notar que os três nós analisados realizam operações computacionais bastante exigentes. Daí que cada nó necessite de 2 cores, apesar de, em média, não os usar por completo. Resultados e Discussão 52 Figura 34: Utilização do CPU por cada container Docker. De notar, ainda, que tanto no Proxy Transcoder como no Output, o valor máximo que a utilização atingiu ultrapassou a utilização de 2 cores, pelo que a quantidade de processamento disponibilizada a cada nó é crítica. 7.2.3 Utilização da memória RAM A utilização da memória RAM pode ser observada na Figura 35. Ao analisarmos os dados obtidos, podemos concluir não só que os containers Docker são bastante leves em termos de recursos utilizados (tal como tinha sido estudado no capítulo 2.2), como também sugere a baixa necessidade de memória RAM para os processos que estão a ser realizados nos nós. De notar que a utilização da memória RAM está diretamente relacionada com a capacidade de processamento do nó. Ou seja, se a capacidade de processamento de um nó for limitada, tendo em conta as medições do capítulo 7.2.2, a utilização da memória RAM aumentará, dado que será necessário manter um buffering de dados maior. Resultados e Discussão 53 Figura 35: Utilização da memória RAM por cada container Docker. 7.3 Escalabilidade Tendo em conta os resultados observados, denota-se que este cenário pode ser escalado, apesar da utilização do CPU ser uma componente crítica e que poderá precisar de melhoramentos de forma a reduzir a quantidade de recursos necessários. Atente-se na Figura 36, que analisa, em detalhe as necessidades de CPU, onde são considerados vários cenários de input (eixo horizontal), considerando apenas 1 Output Node. Se para uma stream MPEG-TS de input é necessário o processamento equivalente a 5 cores do CPU para a totalidade do sistema, isto significa que o dimensionamento da carga é crítico para garantir a escalabilidade do sistema. De forma a avaliar se é possível relaxar estas necessidades de CPU, é importante analisar qual o buffering existente no leitor de DASH, presente na Figura 37. Em média, o leitor contém 1.85 segundos de buffering, o que significa que pode ser legítimo sacrificar velocidade de processamento em prol de baixar os requisitos necessários para a aplicação. Ainda assim, está-se a diminuir a confiabilidade Referências 60 [13] C. C. Koh, “Next-Generation Techniques to Protect and Secure Realtime IP Media Transport,” SMPTE Motion Imaging J., vol. 122, no. 5, pp. 32–38, Jul. 2013. [14] J. Footen and M. Ananthanarayanan, “Service-Oriented Architecture and Cloud Computing in the Media Industry,” SMPTE Motion Imaging J., vol. 121, no. 2, pp. 22–30, Mar. 2012. [15] M. Abdelbaky, J. Diaz-Montes, M. Parashar, M. Unuvar, and M. Steinder, “2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing (UCC),” 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing (UCC). pp. 368–371, 2015. [16] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RFC 3550: RTP: A Transport Protocol for Real-Time Applications,” IETF, 2003. . [17] T. Stockhammer, “Dynamic adaptive streaming over HTTP--: standards and design principles,” Proc. Second Annu. ACM Conf. …, 2011. [18] Mpeg-2, “Generic coding of moving pictures and associated audio information -- Part 1: Systems,” ISO/IEC 13818-1, Ed. 2, vol. 2000, 2000. [19] T. S. ETSI, “Transport of MPEG-2 TS based DVB services over IP based networks,” 2007. [20] G. Fernando, D. Hoffman, V. Goyal, and M. R. Civanlar, “RTP Payload Format for MPEG1/MPEG2 Video.” [21] T. Kojima, J. J. Stone, J.-R. Chen, and P. N. Gardiner, “A Practical Approach to IP Live Production,” SMPTE Motion Imaging J., vol. 124, no. 2, pp. 29–40, Mar. 2015. [22] Michael Goldman, “What’s the Best IP Video Path Forward?” [Online]. Available: https://www.smpte.org/publications/past-issues/January-2015. [Accessed: 12-Mar-2016]. [23] P. J. Brightwell, J. D. Rosser, R. N. J. Wadge, and P. N. Tudor, “The IP Studio,” SMPTE Motion Imaging J., vol. 123, no. 2, pp. 31–36, Mar. 2014. [24] European Broadcasting Union, Society of Motion Picture and Television Engineers, and Video Services Forum, “Joint Task Force on Networked Media - Reference Architecture v1.0.” 2015. [25] A. Rawcliffe, “Covering the Glasgow 2014 Commonwealth Games using IP Studio,” BBC R&D White Pap. WHP289, 2015. [26] SMPTE, “ST 2022-6: Transport of High Bit Rate Media Signals over IP Networks (HBRMT),” 2012. [27] M. Laabs, “SDI Over IP—Seamless Signal Switching in SMPTE 2022-6 and a Novel Multicast Routing Concept,” EBU Tech. Rev. Q, vol. 4, p. 2012, 2012. [28] L. Gharai and C. Perkins, “RTP Payload Format for Uncompressed Video.” [29] T. Committee, IEEE Std 1588-2008, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, vol. 2008, no. July. 2008. Referências 61 [30] A. M. W. Association, “Networked Media Open Specification,” 2016. [Online]. Available: https://github.com/AMWA-TV/nmos. [31] D. Hoffman, G. Fernando, V. Goyal, and M. Civanlar, “RTP payload format for MPEG1/MPEG2 video,” 1997.