padrões de middleware para tv digital - NCC

PADRÕES DE MIDDLEWARE PARA TV DIGITAL
Rafael V. Coelho
Fundação Universidade Federal do Rio Grande (FURG) – Rio Grande - RS
[email protected]
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.
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.
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 340.000
receptores com MHP na Itália. Um estudo
feito em 2003 mostrou que 700.000
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
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 GingaNCL é 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
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] www.ginga.org.br
[3] http://www.ncl.org.br/
[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] http://java.sun.com