PADRÕES DE MIDDLEWARE PARA TV DIGITAL

Transcrição

1 PADRÕES DE MIDDLEWARE PARA TV DIGITAL Rafael V. Coelho Fundação Universidade Federal do Rio Grande (FURG) Rio Grande - RS rafaelvc2@gmail.com Resumo. Este trabalho discute os tipos de Middleware usados para os principais Sistemas de Televisão Digital do mundo. Incluindo os padrões americano, europeu e japonês. As principais características de cada um destes padrões são esclarecidas no decorrer do artigo. Palavras-chave: TV Digital, Middleware 1. INTRODUÇÃO A principal meta deste artigo é a de esclarecer todo o funcionamento e arquitetura proposta por cada um dos principais padrões de middleware utilizados para a composição de um Sistema Digital de Televisão no mundo, inclusive no Brasil. Será também explicado, o funcionamento, qual a estrutura da arquitetura de um Sistema Digital de Televisão e quais os principais componentes contidos neste. Além disso, serão explicados os tipos de Middleware utilizados nos padrões de TV Digital. Outra meta deste trabalho é fazer uma relação entre os padrões de TV Digital mundo a fora e o modelo brasileiro. 2. A ARQUITETURA DE UM SISTEMA DIGITAL DE TELEVISÃO Para que haja um entendimento sobre os padrões de middleware utilizados, é preciso especificar qual a arquitetura de um Sistema de televisão Digital e como seus componentes internos se relacionam. Similarmente ao modelo OSI em Redes de Computadores, a arquitetura de SDTV também é dividida em camadas. Estas são independentes e cada camada superior deve utilizar os serviços oferecidos pela inferior e, ao mesmo tempo, proporcionar serviços a camada superior a mesma. As camadas são diferenciadas no transmissor e no receptor. Primeiramente, é feita a captura de vídeo, áudio e dados através de uma câmera ou de um arquivo de streaming. Este sinal é codificado (camada de middleware) e é feita a compressão dos dados do programa (camada de compressão) para que possam ser transmitidos. Depois da multiplexação dos dados comprimidos em fluxo de transporte (camada de transporte). Este fluxo codificado é adequado (modulação) ao meio de transmissão (camada de modulação). A camada mais alta do transmissor é a camada de Transmissão, na qual transmitido o sinal da TV. Enquanto isto, no receptor, o sinal da TV deve ser sintonizado (camada de recepção), demodulado e decodificado em fluxo de transporte (camada de demodulação), o programa em questão deve ser demultiplexado (camada de transporte), descomprimido (camada de descompressão) e finalmente extraídos pelo Middleware. A função do middleware é a de possibilitar que aplicações possam ser escritas de modo mais independente possível do hardware e do sistema operacional, permitindo que uma mesma aplicação possa ser carregado e executado em diferentes equipamentos receptores. É importante ressaltar que acima da camada de middleware, existe a camada de aplicação onde são colocadas as aplicações para TV - Interativa, por exemplo. Além disso, para que possa ser visto em uma TV analógica, deve ser utilizado um SET-TOP BOX que transforma os sinais digitais em sinais específicos para a TV analógica.

2 Os padrões MPEG são usados para codificação e compressão de dados multimídia. O tipo MPEG-1 foi criado para vídeos codificados até 1,5 Mbps com qualidade VHS, e áudio codificado com 192 Kbps por canal. MPEG-2 é baseado em MPEG-1, mas mais otimizado. Ele é capaz de codificar vários vídeos entre 4 e 9 Mbps para TV ou entre 15 e 100 Mbps para HDTV. Já o padrão MPEG-4 representa conteúdos de mídia na forma de objetos. Com isso, pode ser feita tanto no servidor quanto no transmissor, a manipulação dos dados, removendo ou inserindo objetos. Além disso, cada padrão de televisão digital deve ter o seu tipo de codificação do sinal de áudio. O Dolby AC-3 é utilizado no ATSC, o MPEG-1 e MPEG-2 são utilizados no DVB e o MPEG-2 AAC é utilizado no ISDB. A camada de transporte é que faz a multiplexação dos dados. Nesta camada é feito o agrupamento de áudio, vídeo e dados em um único fluxo MPEG-TS (Transport Stream) numa mesma base de tempo. Como são utilizados pequenos pacotes para encapsular os fluxos, torna-se fácil a ressincronização de um vídeo para o caso de ocorrerem perdas de pacote no MPEG-TS. A modulação é o processo pelo qual a onda transmitida é alterada de acordo com o sinal da informação a ser transmitida. Permitindo assim que o conteúdo do sinal de mensagens não seja tão vulnerável a ruídos. Os padrões utilizados hoje em dia são COFDM (Coded Orthogonal Frequency Division Multiplexing) pelo ISDB (padrão japonês) e pelo DVB (padrão europeu). Já o padrão americano (ATSC) utiliza 8-VSB (8 L-Vestigial Side Band Modulation) para modular o sinal. 3. PADRÕES DE MIDDLEWARE As aplicações de TV Digital (DTV) podem ser divididas em aplicações procedurais e aplicações declarativas. Linguagens não declarativas podem seguir diferentes paradigmas. Têm-se assim as linguagens procedurais baseadas em módulos, orientadas a objetos. Numa programação procedural, devemos informar ao computador cada passo a ser executado. O programador possui, assim, um maior poder sobre o código, sendo capaz de estabelecer todo o fluxo de controle e execução de seu programa. Nas linguagens declarativas, existe um nível maior de abstração, usualmente ligadas a um domínio ou objetivo específico. O programador fornece apenas o conjunto das tarefas a serem realizadas, não estando preocupado com os detalhes de como o executor da linguagem (interpretador ou compilador) realmente implementará essas tarefas. 3.1 DASE O middleware DASE ou DTV Application Software Enviroment é utilizado no padrão de TV Digital Norte-Americano ATSC. Este middleware permite que serviços interativos sejam executados normalmente por qualquer receptor. O padrão DASE é um esforço do Advanced Television System Committee (ATSC) que permite aos criadores de conteúdo aperfeiçoado e interativo as especificações necessárias para que os aplicativos e dados executem uniformemente em todos os modelos e marcas de receptores. Uma aplicação DASE é um conjunto de informações que são processadas por um ambiente de aplicação para fornecer interatividade com o usuário final ou alterar o estado do ambiente da aplicação. O conteúdo da aplicação pode ser de natureza declarativa ou procedural. As aplicações declarativas tem como objetivo, principal, a apresentação de dados de forma estática. Fazem uso de várias tecnologias web, como linguagens baseadas em tags, XHTML, CSS (Cascading Style Sheets) e DOM (Document Object Model), fluxos de áudio e vídeo. Já os aplicativos procedurais são aqueles que incluem algum processamento lógico. Sendo implementados através de código escrito na linguagem de programação Java[1]. Sendo assim, este tipo de aplicação é capaz de processar tarefas mais complexas dinamicamente.

3 Existe ainda uma categoria de aplicações híbridas, que permite uma mistura de conteúdo de aplicativos tanto declarativos como procedurais. O ambiente de aplicativos DASE fornece browser para conteúdo de aplicações declarativas e uma Máquina Virtual Java. Este tipo de middleware não especifica a implementação de um set-top box específico. 3.2 MHP O padrão MHP é o middleware usado no padrão de TV Digital Europeu DVB. O padrão MHP consiste de uma combinação de suportes à broadcast e à Internet, oferecendo uma API acessível a todos que desejam desenvolver aplicações, receptores e aparelhos de TV. No perfil Enhanced, não é oferecido suporte a canal de retorno e conexão IP. Executa as aplicações via difusão (broadcast). Já o perfil Interactive suporta a um canal de retorno e conexão IP, permitindo assim a possibilidade de interatividade remota. O ultimo perfil disponibilizado pelo Middleware MHP é o Internet Access que suporta aplicações web, além de aplicações desenvolvidas em Java. Este último perfil só foi disponibilizado na versão MHP 1.1. Todos os perfis possuem suporte a aplicações interativas desenvolvidas com a DVB-J que representa um conjunto de funções de alto nível, estruturas de dados e protocolos que representam uma interface padrão para o desenvolvimento de software independente de plataforma de hardware. Duas importantes diferenças entre o MHP 1.0 e o MHP 1.1 são que a nova especificação permite a possibilidade de armazenar localmente aplicações e plug-ins recebidos por difusão, além do acréscimo da DVB-HTML API, uma interface de programação de aplicações baseadas em HTML. Existem dois tipos de aplicações suportadas pelo padrão MHP: DVB-HTML (apresentada através de conteúdo hipermídia) e DVB-J (representadas através de conteúdo compilado na linguagem Java). O MPH é dividido em três camadas: recursos (hardware embutidos), software (aplicações) e interface das aplicações (interoperabilidade). Na camada de recursos estão incluídos os recursos de hardware embutidos na televisão ou set-top-box. Recursos disponíveis incluem hardware de decodificação MPEG, dispositivos de entrada e saída de dados, CPU, memória e sistemas de geração de imagem. Já na camada de software, as aplicações não acessam diretamente os recursos de hardware. Ela traz uma visão abstrata dos recursos disponíveis. Este isolamento entre hardware e software cria portabilidade. Esta camada também inclui um gerenciador de aplicações, que é responsável por controlar o ciclo de vida das aplicações. Finalmente, na camada de Interface das Aplicações, é mantida a interoperabilidade das diversas aplicações MHP desenvolvidas, utilizando principalmente a DVB-J API, aplicações estas orientadas a objeto e baseadas na linguagem de programação Java. Em 2004, uma pesquisa demonstrou que foram registradas vendas de receptores com MHP na Itália. Um estudo feito em 2003 mostrou que receptores estavam funcionando na Coréia do Sul. Isso sem contar que também é o padrão da Alemanha e da Suécia. Com isto, nota-se a abrangência do padrão MHP na Europa e em outros Países como a Coréia do Sul. 3.3 ARIB O padrão de middleware ARIB (Association of Radio Industries and Business) é utilizado no padrão Japonês ISDB. Neste sistema, áudio, vídeo e todos os serviços de dados são multiplexados e transmitidos via broadcasting de rádio, em um TS (Transport Stream) especificado pelo MPEG-2. Canais para a interatividade das comunicações são disponibilizados através dos canais interativos da rede. O sistema de transmissão de dados que utiliza o armazenamento dos pacotes como um fluxo de pacotes no PES (Packetized Elementary Stream) é usado para aplicações em tempo real, que necessitam de sincronização na decodificação e reprodução dos diferentes tipos de mídia. A estrutura lógica do display ARIB é composta, respectivamente, de plano de

4 vídeo, plano de figura, plano de controle, plano de gráficos e textos e plano de legendas. Além disso, existe o sistema de transmissão de dados, no qual os dados serão transmitidos inúmeras vezes. Este serviço é especificado como carrossel de dados. Outra facilidade proporcionada pelo ARIB é que ele permite adicionar EPG (Electronic Program Guide), índice e funções de gravação automática para melhorar a seleção da programação. Facilitando assim a programação pessoal do usuário. 3.4 Ginga O padrão de camada de software intermediário Ginga[2] foi o primeiro middleware opensource desenvolvido no Brasil com o intuito de prover funções de interatividade para TV Digital e foi lançado no dia 3 de Julho de 2007 no Auditório Principal do Instituto Militar de Engenharia Praia Vermelha, Rio de Janeiro. O Middleware Ginga foi uma iniciativa realizada pelo Laboratório TeleMídia do Departamento de Informática da PUC - Rio em conjunto com o Laboratório LAVID da Universidade Federal da Paraíba. Este padrão brasileiro é divido em Ginga-NCL[3] e Ginga-J. O Laboratório TeleMídia foi responsável pelo Ginga-NCL que é uma infra-estrutura de apresentação para aplicações declarativas escritas na linguagem Nested Context Language (NCL). NCL é uma aplicação XML com facilidades para a especificação de aspectos de interatividade e sincronismo espaço-temporal entre objetos de mídia. Enquanto isso, o Laboratório LAVID foi responsável por desenvolver o Ginga-J que é a infra-estrutura de apresentação para aplicações procedurais (Java Xlet). E é através desta que pode ser implementada aplicações de maior complexidade que provê a interação com o usuário. Existe uma ponte (bridge) entres os módulos Ginga-NCL e Ginga-J que é disponibilizado pela arquitetura Ginga. Além destes dois módulos citados acima, também existe o módulo Common Core que é a camada de software que dá suporte para os outros módulos através de uma série de codecs e procedimentos para obter dados do MPEG-TS ou do canal de retorno que permite a possibilidade de interatividade. Ginga-NCL. O subsistema lógico Ginga- NCL é composto por uma série de módulos. O mais importante módulo é o NCL Formatter, já que este é responsável por receber um documento NCL e controlar a sua apresentação, tentando garantir que relacionamentos entre objetos de mídia sejam respeitados. Os documentos NCL são providos por uma estrutura chamada private base que corresponde um canal de TV. A partir da linguagem NCL, os objetos envolvidos são descritos e a sincronização entre eles é obtida. Além de especificar o espaço temporal dos mesmos. Os objetos são descritos em documentos NCL que por sua vez são executados pelo Formatador NCL. Os tipos de objetos suportados depende diretamente do NCL player embutido no Formatador NCL. Um destes players é o decoder/player implementado em hardware pelo receptor. Outros módulos do Ginga-NCL merecem destaque. O XHTML-based user agent é composto por um interpretador stylesheet (CSS) e um interpretador ECMAScript. E o módulo LUA engine é responsável por interpretar scripts LUA. LUA[4] é uma linguagem de programação leve e poderosa, projetada para estender aplicações. Seus scripts são acoplados a programas maiores que precisam ler e executar programas escritos pelos usuários. Ginga-J. A arquitetura Ginga-J é composta de cinco camadas: Hardware, Sistema Operacional, Implementação Ginga e Java Virtual Machine (JVM), API Ginga-J e Xlets. Dentre as camadas que compõem a arquitetura Ginga-J, merece destaque a de aplicações. Aplicações para TV Digital, principalmente com enfoque interativo são chamados de Xlets. São similares a Applets em java, mas não são iguais. Xlets são aplicações desenvolvidas em Java TV[5] que é uma API que estende a plataforma Java. Foi

5 desenvolvida pela Sun Microsystems[6] para prover acesso e funcionalidades num receptor de televisão digital. A Sun Microsystems fornece um emulador para simular uma TV Digital em um desktop, chamado XletView. Este é baseado no middleware MHP e é Open Source. Desta forma, as aplicações (Xlets) desenvolvidos podem ser testados de forma rápida e fácil. Para implementar um Xlet, devem ser implementados um número pequeno de métodos que controlam o ciclo de vida do mesmo. 4. CONCLUSÃO A televisão analógica está caindo em desuso. A televisão digital surgiu com o objetivo de ter uma melhor qualidade de imagem e som. Faz melhor uso da largura de banda, tem a transmissão do sinal livre de ruídos. Com isso, possibilita a existência da televisão de alta definição além de permitir a interatividade que é a área de mais rápido desenvolvimento atualmente e de maior interesse. Onde se captava um único programa por canal, poderão existir vários programas (sistema de múltiplos programas). Existem ainda outras vantagens que não serão abordadas neste trabalho. Como exemplos pode-se citar o T-commerce, o comércio eletrônico pela TV, e o T-Banking, serviços bancários também pelo monitor de TV. Isto sem falar na TV interativa que é uma das áreas de maior atratividade e de progresso rápido. Um sistema de transmissão de TV Digital consiste de uma estação transmissora (head-end), um meio físico sobre o qual o sinal de vídeo é transmitido, que pode ser o ar, cabos ou mesmo satélites, e um receptor ou Terminal de Acesso que recebe o sinal transmitido, o decodifica e o exibe. Para garantir a compatibilidade entre estes elementos e permitir que o vídeo possa ser exibido nos destinos, é necessário que sejam padronizada a comunicação entre estes elementos através de padrões. Os padrões mais consolidados são o padrão de TV Digital Norte-Americano ATSC que utiliza o middleware DASE, o padrão Europeu DVB que utiliza o Middleware MHP e o padrão Japonês ISDB que utiliza o Middleware ARIB. Além destes, é importante ressaltar o padrão brasileiro de Middleware Ginga que foi uma iniciativa realizada pelo Laboratório TeleMídia do Departamento de Informática da PUC - Rio em conjunto com o Laboratório LAVID da Universidade Federal da Paraíba. REFERÊNCIAS [1] DEITEL H., DEITEL P. (2005). Java: Como Programar. Prentice-Hall, Edição 6. [2] [3] [4] Ierusalimschy R. (2006). Programming in Lua. Lua.org, Edição 2. [5] Bart Calder, et al, JavaTV API Technical Overview: The JavaTV API Whitepaper, 2000 [6]