Técnicas de Interatividade para TV Digital
Bruno Borsato de Souza Lima, Bruno Felipe Cardoso, Gabriel Paduan Silva & Gustavo Andrade
Swerts INATEL – Instituto Nacional de Telecomunicações – Santa Rita do Sapucaí – MG – Brasil
Abstract – In order to examine how the production of
interactive content posted on Brazilian digital TV works,
this work comprehends the entire process from end to
end. All the steps since the tools for creation and debug,
encapsulation and transmission of the data from the
broadcasting station to the final user and, finally, the
software present on the receiver which enables the
service will be covered. With highlights to the features
and factors in favor to the use of this technology in
relation to its competitors.
Resumo – De forma a analisar o funcionamento da
produção de conteúdo interativo veiculado na TV digital
brasileira, o presente trabalho compreende todo o
processo de fim a fim. Serão abordados os passos desde
as ferramentas para criação e depuração,
encapsulamento e transmissão dos dados desde a
emissora até o usuário final e, finalmente, o software
presente no receptor e que possibilita o serviço. Destaca-
se deste software, as características e fatores relevantes
ao uso desta tecnologia em relação às concorrentes.
Palavras-chave: TV Digital, interatividade, Ginga, middleware.
I. INTRODUÇÃO
Recentemente, em dezembro de 2007, iniciou-se a
implantação do Sistema Brasileiro de Televisão Digital
(SBTVD), trazendo consigo algumas características
inovadoras e não permitidas no sistema analógico de
transmissão. Entre elas podemos destacar a possibilidade de
multiprogramação, mobilidade e, principalmente,
interatividade.
O advento da TV digital interativa proporciona ao
telespectador diferentes maneiras de se relacionar com o
conteúdo exibido, permitindo a compra de produtos,
participação em enquetes e muito mais por meio do controle
remoto. Este novo conceito que vem sendo introduzido é
conhecido como TV 2.0 (Designcoletivo, 2007) e, tal qual
na Web 2.0 (O'Reilly, 2005), propicia um cenário cada vez
mais colaborativo, envolvendo um grande número de
usuários. Além disso, um novo modelo de negócios que
abrirá novas prospecções é o T-Commerce, nome dado ao
comércio eletrônico realizado através da TV.
A fim de que todas estas funcionalidades sejam suportadas,
uma especificação sólida, resultado de anos de trabalho e
pesquisas realizadas pela Universidade Federal da Paraíba
(UFPB) e pela Pontifícia Universidade Católica do Rio de
Janeiro (PUC-Rio) foi concebida e denominada Ginga
(Ginga, 2006). Por contemplar um conjunto de tecnologias e
inovações brasileiras, este middleware tornou-se uma das
mais avançadas especificações disponíveis e, ao mesmo
tempo, a mais adequada à realidade do país.
II. INTERATIVIDADE NA TV
II.1 Criando a Interatividade
Antes de discorrer sobre interatividade na televisão, é
conveniente fazer uma breve introdução sobre o
funcionamento da TV Digital, pois os tópicos a serem
abordados na sequência são possíveis única e
exclusivamente no sistema digital.
II.1.1 Princípios de TV Digital
Neste novo sistema de transmissão toda a informação a ser
transmitida deve estar no formato digital, o que proporciona
uma melhor integridade do sinal recebido em comparação
com o sistema analógico. Como os sinais de áudio e o vídeo
são analógicos, estes devem ser previamente digitalizados e
comprimidos antes de serem transmitidos. A compressão
reduz a taxa de dados do sinal digitalizado eliminando
redundâncias e detalhes pouco perceptíveis aos olhos
humanos, permitindo que até mesmo sinais em alta
definição sejam transmitidos.
Uma grande vantagem de se lidar com informação apenas
no formato digital é que, embora a taxa de bits permitida
pelo meio seja limitada, as técnicas de digitalização e
compressão de áudio e vídeo empregadas nos sistemas
digitais permitem um ajuste arbitrário da taxa de dados
utilizada para representar a informação. Assim, tornou-se
possível multiplexar, em um único canal, informações
adicionais como, por exemplo: áudio SAP, closed captions,
outro sinal de vídeo e, o alvo deste trabalho, interatividade.
II.1.2 Geração
Antes de o conteúdo interativo ser multiplexado no canal
digital e transmitido, ele precisa ser devidamente gerado, ou
melhor, programado. Na sequência, ele será empacotado e
serializado para transmissão.
Tal como um programa, o conteúdo interativo precisa ser
escrito segundo uma linguagem de programação pré-
estabelecida que o receptor compreenda e seja capaz de
processar. A linguagem de programação a ser utilizada, os
recursos que estarão disponíveis e a estrutura a ser seguida
são pontos contidos na especificação do middleware para o
qual a aplicação será desenvolvida.
II.1.3 DSM-CC
O padrão DSM-CC (Digital Storage Media – Command and
Control) é parte integrante do padrão MPEG-2 (ISO/IEC
13818-6, 1998) e foi inicialmente desenvolvido com o
intuito de controlar fontes de vídeo em rede. Desde então,
foi evoluído e acabou por se tornar um conjunto geral de
protocolos para prover serviços multimídia e aplicações,
através de uma conexão banda larga (Morris & Smith-
Chaigneau, 2005). Dentre as funcionalidades suportadas
pelo DSM-CC pode-se destacar, entre outras, o download de
dados, acesso a arquivos remotos, controle de feixe de mídia
e sincronismo com conteúdo de mídia.
A fim de que o usuário consiga acessar os dados
transportados por meio do padrão DSM-CC, os
radiodifusores utilizam um formato de envio cíclico das
informações, permitindo assim que a unidade receptora seja
capaz de adquirir as informações em qualquer momento,
durante o período de transmissão. Esta forma de envio é
conhecida como carrossel.
No DSM-CC, dois tipos de carrossel são especificados: o
carrossel de dados e o carrossel de objetos. Dentro de ambas
as estruturas, os arquivos a serem transmitidos são divididos
em blocos, os quais recebem o nome de módulos. Estes
módulos são enviados em sequência e, dependendo da
aplicação, alguns módulos podem ser enviados com mais
frequência do que outros, de modo a se otimizar o acesso do
lado do cliente.
II.1.4 Multiplexação
A fim de permitir o transporte de várias informações através
do mesmo canal, os sistemas de televisão digital fazem uso
de técnicas de multiplexação proporcionando um melhor
aproveitamento da banda disponível, embora ainda seja
possível que uma única informação esgote a vazão do canal.
A multiplexação empregada é baseada na divisão do tempo
(TDM – Time Division Multiplexing). Embora a técnica
adotada determine como será compartilhado o acesso ao
meio, ela não especifica como os dados serão agrupados e
efetivamente transmitidos. Este impasse foi resolvido com a
introdução do padrão de transmissão e armazenamento de
áudio, vídeo e dados conhecido como Transport Stream
(TS), parte integrante do padrão MPEG-2 (ISO/IEC 13818-
1, 1996).
O TS é indicado para situações que exijam rápida
sincronização do receptor com a informação e ambientes
com alta incidência de erros, cenário típico de sinal
radiodifusão. Em um TS, os feixes de áudio, vídeo e dados
são organizados formando unidades denominadas serviços.
II.1.5 Apresentação
Uma vez irradiado o sinal de televisão, é papel do receptor
(Set-top Box) apresentar este sinal na tela para o usuário
final. Para fazê-lo, é preciso antes sintonizar o sinal
transmitido na frequência correta do canal e demodulá-lo.
Após este processo, o receptor tem disponível uma
estimativa do sinal de entrada do transmissor da emissora de
televisão. Na sequência, é preciso extrair (demultiplexar) do
TS o serviço presente em sua estrutura (bem como os dados
referentes a ele) e encaminhar os feixes de áudio e vídeo
para os seus respectivos decodificadores. Caso uma
interatividade esteja presente, seus dados são encaminhados
para o middleware instalado no receptor para a correta
decodificação e apresentação.
II.2 Definição de Middleware
Middleware é um termo que se refere aos sistemas de
software que rodam entre as aplicações e o sistema
operacional. O objetivo do middleware é facilitar o
desenvolvimento de aplicações, assim como fornecer um
modelo de programação mais produtivo para os
programadores de aplicativos.
Sua principal função é transportar informações e dados entre
programas de diferentes protocolos de comunicação,
plataformas e dependências do sistema operacional. É
geralmente constituído por módulos dotados de APIs
(Application Programming Interface) de alto nível que
proporcionam a sua integração com aplicações
desenvolvidas em diversas linguagens de programação e
interfaces de baixo nível, que permitem a sua independência
em relação ao dispositivo.
II.3 Padrões de Middlewares mais Difundidos
II.3.1 MHP
O middleware europeu MHP (Multimedia Home Platform) é
um padrão aberto DVB (Digital Video Broadcasting). Com
estudos iniciados em 1994, a primeira versão desta
especificação foi lançada em 23 de Fevereiro 2000 através
do órgão ETSI (European Telecommunications Standards
Institute). Até o momento já foram publicadas pelo ETSI
três diferentes versões do MHP: MHP 1.0, MHP 1.1 e, o
mais atual, MHP (ETSI TS 102 727, 2010).
O padrão MHP oferece suporte a dois tipos de aplicações:
DVB-HTML (declarativa) e DVB-J (procedural).
Entretanto, o desenvolvedor não precisa se prender a apenas
uma das linguagens para o desenvolvimento, uma vez que
devido a um meio virtual conhecido como ponte – a qual
permite a comunicação entre os aplicativos – é possível
programar conteúdos híbridos, isto é, fazendo uso de
elementos de ambas as linguagens.
II.3.2 DASE
Desenvolvido pelo órgão ATSC, o middleware norte-
americano de TV digital DASE (DTV Application Software
Environment) foi concebido em sua primeira versão (DASE
nível 1 ou DASE-1) com suporte a conteúdos de natureza
declarativa e procedural, porém, restritos apenas à
interatividade local – uma vez que o canal de retorno não
estava previsto pelo sistema. Todavia, foram lançadas outras
duas instâncias sendo: DASE-2 e DASE-3. Estas novas
versões solucionaram alguns problemas, tais como:
segurança, integração com a Internet, interação pela rede,
etc.
II.3.3 ARIB
O middleware do padrão japonês ISDB-T recebeu o mesmo
nome da organização pela qual foi padronizado: ARIB
(Association of Radio Industries and Broadcast). Assim
como nos outros sistemas, esta especificação oferece suporte
aos ambientes declarativo e procedural, utilizando,
respectivamente, as linguagens BML (Broadcast Markup
Language) e Java. Contudo, não é possível estabelecer uma
ponte entre aplicativos utilizando linguagens diferentes.
Por outro lado, destaca-se neste padrão o suporte ao
conteúdo interativo em plataformas móveis e portáteis de
recepção do sinal de TV digital. Tal característica não está
presente em nenhum outro padrão discutido anteriormente,
sendo este um dos fatores relevados durante a análise das
possíveis opções para a escolha do SBTVD.
 III. GINGA
Desenvolvido e adotado pelo padrão de televisão digital
brasileira, o middleware Ginga pode ser subdividido em:
Ginga-NCL, Ginga-J e Ginga Common Core.
III.1 GINGA-NCL
Sendo a inovação totalmente brasileira do SBTVD e o único
ambiente obrigatório em receptores portáteis (Cruz, 2008),
Ginga-NCL é o subsistema lógico do middleware Ginga
responsável pelo processamento de documentos NCL, sendo
elas, aplicações puramente declarativas ou não.
III.2 GINGA-J
Construído de forma compatível com o middleware MHP
(Damasceno, 2008) (seção 2.3.1), Ginga-J é o ambiente
imperativo que suporta Xlets (nome dado a aplicações
criadas com a linguagem Java).
Ele se divide em três módulos: API Núcleo Ginga-J, API
Específica Ginga-J e Máquina Virtual Java, os quais
definem as inovações do padrão brasileiro, a ponte entre
aplicativos Java e NCL, além da compatibilidade com o
middleware europeu.
III.3 GINGA-CC
O Ginga Common Core é uma camada base que contém
módulos comuns a ambas as máquinas anteriores: Ginga-
NCL e Ginga-J.
O sistema de camadas do middleware Ginga garante que
apenas o Ginga-CC possa sofrer alterações mediante
modificações da plataforma de hardware onde o middleware
se encontra embarcado. Isso proporciona além de uma
abstração de hardware uma abstração também na plataforma
de software (acessível através de APIs).
III.4 Implementações do Ginga
A TV digital estreou no Brasil no dia 2 dezembro de 2007,
mas apenas em julho de 2008, é que foram aparecer os
primeiros modelos de receptores equipados com middleware
Ginga. No inicio de 2010 foram lançados os primeiros
televisores que, além do conversor digital, também
contavam com capacidades interativas já integradas no
aparelho.
No caso dos dispositivos portáteis e telefones celulares, o
lançamento do primeiro modelo comercial equipado com o
middleware brasileiro foi em julho de 2010.
III.5 Portando o Ginga
Os fabricantes de receptores têm liberdade para escolher os
elementos do seu hardware e dimensioná-los segundo o
desempenho e funcionalidade desejado para o equipamento.
Em vista das peculiaridades do hardware que equipa cada
receptor, surge a necessidade de “portar” o middleware.
Como cada aparelho utiliza um processador baseado em um
núcleo diferente e com um set de instruções incompatível
com outras arquiteturas, seções do código fonte do
middleware precisam ser reescritas ou adaptas para rodar
apropriadamente em cada receptor. Além disso, se um
equipamento estiver equipado com um hardware
semelhante, mas rodando um sistema operacional diferente,
o “porte” ainda assim é necessário, devido à
incompatibilidade de drivers e particularidades entre
sistemas.
IV. FERRAMENTAS DE EDITORAÇÃO
Para a elaboração de um software, é necessária a utilização
de, pelo menos, uma linguagem de programação, que por
sua vez executará toda uma lógica (algoritmo) que o
desenvolvedor utilizou para a criação do seu programa. Para
a interatividade digital, duas são as linguagens de
programação utilizadas atualmente: Java e NCL (Nested
Context Language – Linguagem de Contexto Aninhado).
IV.1 JAVA
Java foi uma linguagem criada com a intenção direta para o
desenvolvimento orientado a objetos. Esta característica
proporciona velocidade na elaboração e manutenção do
código, maior segurança no tratamento dos dados
compartilhados e maior facilidade na reutilização do
programa.
Java é escrito na forma procedural, o que advém do conceito
de chamadas de procedimentos, também conhecidas como
métodos, funções, rotinas e sub-rotinas.
IV.2 NCL
Ao contrário de Java, NCL não é compilável, sendo definida
como uma linguagem declarativa, onde cada procedimento
(tag) em seu código descreve o que vai acontecer e não
como funciona. A linguagem NCL veio para suprir a
necessidade da criação de documentos hipermídia adotando
o modelo NCM (Nested Context Model – Modelo de
Contexto Aninhado).
O modelo conceitual NCM tem a função de aumentar o
poder e flexibilidade de um documento hipermídia,
apresentando os conceitos estruturais, de eventos e
relacionamentos entre os dados, tendo forte atuação em sua
representação e tratamento.
NCL pode ser utilizada junto com sua linguagem script,
Lua, para que juntas possam proporcionar mais recursos ao
programador na elaboração de suas implementações.
IV.2.1 Lua
A linguagem de extensão Lua, do tipo script, é imperativa e
procedural, utilizada no interior de outras linguagens para
que possa expandir aplicações. Como a linguagem raiz não é
capaz de realizar as ações de execução de aplicações
multimídias e tratamento de dados através da interação com
o usuário, é necessário que se faça uso da inserção de scripts
(Tavares, 2009).
IV.3 ECLIPSE e NETBEANS
Eclipse e NetBeans são ambientes de desenvolvimento
integrado (IDE – Integrated Development Environment –
Ambiente de Desenvolvimento Integrado) que
proporcionam ao programador a codificação de várias
linguagens em uma única ferramenta. Isto é possível graças
ao fato destes softwares aceitarem a instalação de serviços
agregados, denominados plug-ins.
Estas IDEs apresentam importantes características que disponibilizar, para os mais variados profissionais que
concede ao desenvolvedor uma maior agilidade na trabalham com interatividade, meios de agilizar e facilitar a
codificação e na procura e manutenção de erros. criação e difusão de aplicativos e conteúdos. Desta forma,
contribuiu-se para a compreensão da cadeia de transmissão e
IV.4 COMPOSER
recepção da interatividade, evidenciando o transporte da
A ferramenta de editoração de programas interativos aplicação até o receptor do telespectador e sua apresentação
Composer, criada pelo Laboratório TeleMídia (Neto, Soares, na tela da TV.
Rodrigues, & Barbosa, 2007), pertencente ao departamento
de informática da Universidade Pontifícia Católica do Rio VI. REFERÊNCIAS
de Janeiro (PUC-RJ), proporciona para o desenvolvedor a
Ginga. (2006). Acesso em 11 de Agosto de 2010, disponível
facilidade de criação de softwares com pouca ou nenhuma
em Ginga Digital TV Middleware Specification:
experiência em linguagem NCL.
http://www.ginga.org.br/
IV.5 NCL ECLIPSE
(2007). Acesso em 15 de Agosto de 2010, disponível em
O NCL Eclipse é um plug-in desenvolvido para a IDE Designcoletivo:
Eclipse com a mesma função da visão de desenvolvimento http://www.desigcoletivo.com/tecnologia/tv-digital-tv-20
textual oferecido pelo Composer, porém, apresenta
Cruz, V. M. (2008). Ginga-NCL para Dispositivos
facilidades como: cor diferenciada em palavras reservadas,
Portáteis. Rio de Janeiro.
marcação de erros, marcação de variáveis, execução e
compilação, auto complete e organização. Damasceno, J. R. (2008). Middleware Ginga. Niterói.
Os usuários desta ferramenta, ao contrário do Composer, ETSI TS 102 727. (2010). Digital Video Broadcasting
necessitam ter o domínio da linguagem NCL, visto que, todo (DVB); Multimedia Home Platform (MHP) Specification
o desenvolvimento é feito em linhas de código, sem opção, 1.2.2.
até o momento, da utilização do desenvolvimento visual.
ISO/IEC 13818-1. (1996). Information technology - Generic
IV.6 GingaRAP e GingaFrEvo coding of moving pictures and associated audio
information: Systems.
Para atender as necessidades do mercado de TV digital,
composto por emissoras, estúdios e empresas especializadas, ISO/IEC 13818-6. (1998). Information technology - Generic
o projeto GingaFrEvo (Framework de Evolução) e coding of moving pictures and associated audio information
GingaRAP estão em fase final de desenvolvimento. - Part 6: Extensions for DSM-CC.
IV.6.1 GingaRAP Morris, S., & Smith-Chaigneau, A. (2005). Interactive TV
Standards: A Guide to MHP, OCAP, and JavaTV. Focal
Ferramenta para desenvolvimento de aplicações tanto para o
Press.
lado do cliente (telespectador) quanto para o lado servidor
(emissoras e estúdio), apresentando os seguintes projetos em Neto, C., Soares, L., Rodrigues, R., & Barbosa, S. (2007).
sua composição: GingaSuite e GingaWaC (Watching and Construindo Programas Audiovisuais Interativos Utilizando
Commenting Paradigm - WaC). a NCL 3.0 e a Ferramenta Composer. Rio de Janeiro:
TeleMídia.
IV.6.2 GingaFrEvo
O'Reilly, T. (2005). What is Web 2.0. Acesso em 13 de
O projeto GingaFrEvo tem como objetivo preparar o
Agosto de 2010, disponível em O'REILLY:
middleware Ginga para adaptações que podem surgir em
http://oreilly.com/web2/archive/what-is-web-20.html
função de futuras tecnologias, sendo dividido em:
GingaMPB, GingaCDN, GingaForAll e GingaAiyê. Tavares, L. A. (2009). Desenvolvendo Aplicações para TV
Digital em NCL e Lua. Santa Rita do Sapucaí.
V. CONCLUSÃO
Em um primeiro momento, este documento abordou as
evoluções dos sistemas de transmissão televisiva no Brasil,
desde sua versão analógica até a digital, com o intuito de
embasar o leitor para os conceitos de interatividade. Na
sequência, os middlewares já implantados no mundo foram
brevemente discutidos antes de focar o Ginga. O
middleware brasileiro em relação ao middleware europeu
MHP, ao americano DASE e ao japonês ARIB, apresentou
inovações relevantes através de uma concepção de camadas
mais bem definidas e pouco acopladas. Outra vantagem
percebida está no atendimento das necessidades nacionais de
inclusão digital da população, assim como a utilização das
linguagens de programação Java, NCL e Lua.
Por fim, constatou-se também a profunda preocupação por
parte dos criadores do middleware brasileiro em