Você está na página 1de 72

ANTÔNIO CARLOS ALBUQUERQUE DE OLIVEIRA

JOÃO PAULO LOPES DE LACERDA

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAÇÕES


INTERATIVAS PARA O MIDDLEWARE GINGA

ARACAJU
2008
UNIVERSIDADE FEDERAL DE SERGIPE
DEPARTAMENTO DE COMPUTAÇÃO
CIÊNCIA DA COMPUTAÇÃO

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAÇÕES


INTERATIVAS PARA O MIDDLEWARE GINGA

ANTÔNIO CARLOS ALBUQUERQUE DE OLIVEIRA


JOÃO PAULO LOPES DE LACERDA

ARACAJU
2008
UNIVERSIDADE FEDERAL DE SERGIPE
DEPARTAMENTO DE COMPUTAÇÃO
CIÊNCIA DA COMPUTAÇÃO

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAÇÕES


INTERATIVAS PARA O MIDDLEWARE GINGA

Trabalho de Conclusão de Cursos apresentado por


Antônio Carlos Albuquerque de Oliveira e João
Paulo Lopes de Lacerda como requisito para
obtenção de grau em bacharel em Ciência da
Computação na Universidade Federal de Sergipe

Orientador: Prof. Dr. Hendrik Teixeira Macedo

ARACAJU
2008
RESUMO

A televisão é um dos maiores meios de comunicação do mundo, como também é uma grande
fonte de informação, entretenimento e cultura. Com a chegada da TV Digital além dos
benefícios trazidos com a imagem e o som de alta definição, o usuário deixará de ser um mero
espectador e passará a interagir com a programação, podendo também usufruir de uma
variedade de serviços computacionais através da TV. Em 2006, o governo brasileiro criou o
SBTVD (Sistema Brasileiro de Televisão Digital), baseado no padrão Japonês. Como o
padrão brasileiro chegou depois dos internacionais, este pôde inovar utilizando tecnologias
mais recentes. Além disto, o SBTVD também inovou no seu Middleware, o Ginga, que
possibilita a execução de aplicações interativas através do ambiente de apresentação Ginga-
NCL e do ambiente de execução Ginga-J. Este trabalho traz um estudo sobre o SBTVD e seu
Middleware, um guia de desenvolvimento para aplicações na TV digital e por fim um estudo
de caso com a implementação de uma aplicação demonstrando parte do potencial desse novo
veiculo.

Palavras-chave: televisão digital interativa, SBTVD, middleware de TV

i
ABSTRACT

Television is one of the biggest media in the world, it is also a large source of information,
entertainment and culture. With the arrival of Digital TV than those benefits with high
definition image and sound, the user will no longer be a mere spectator and will interact with
the programming, can now also enjoy a variety of computing services through the TV.
Coordinated by the Brazilian government, was produced the SBTVD (Brazilian System
Digital Television), based on the Japanese standard. As the Brazilian standard came after the
international, this could innovate using latest technologies. In addition, the SBTVD also
innovated in its Middleware, the Ginga, which allows the execution of interactive applications
through the presentation environment Ginga-NCL and the execution environment Ginga-J.
This work brings a study on the SBTVD and its Middleware, a guide for development of
applications for digital TV and finally a case study with the implementation of an application
demonstrating part of the potential of this new vehicle.

Keywords: Interactive digital television, SBTVD, middleware de TV

ii
SUMÁRIO

1. INTRODUÇÃO ....................................................................................................................8
2. SISTEMA DE TELEVISÃO DIGITAL INTERATIVA ................................................10
2.1. TRANSMISSÃO NA TV DIGITAL .............................................................................10
2.2. O CONCEITO DE INTERATIVIDADE.......................................................................11
2.3. COMPONENTES DA TV DIGITAL INTERATIVA ...................................................12
2.4. ARQUITETURA DO SISTEMA DE TV DIGITAL INTERATIVA ............................13
2.4.1. Camada de aplicação ..............................................................................................13
2.4.2. Middleware.............................................................................................................14
2.4.3. Camada de Codificação e Decodificação ...............................................................15
2.4.4. Camada de Transporte ............................................................................................15
2.4.5. Camada de Transmissão e Recepção......................................................................16
2.5. PADRÕES MUNDIAIS DE TV DIGITAL INTERATIVA ..........................................16
2.5.1. ATSC - Padrão Americano.....................................................................................16
2.5.2. DVB - Padrão Europeu...........................................................................................18
2.5.3. ISDB - Padrão Japonês ...........................................................................................18
2.6. SURGIMENTO DA TV DIGITAL NO BRASIL..........................................................19
2.7. PADRÃO BRASILEIRO DE TV DIGITAL .................................................................20
2.7.1. Middleware.............................................................................................................20
2.7.2. Camada de Codificação e Decodificação ...............................................................21
2.7.3. Camada de Transporte ............................................................................................22
2.7.4. Camada de Transmissão e Recepção......................................................................22
3. O GINGA E SUA ARQUITETURA.................................................................................24
3.1. O AMBIENTE GINGA-NCL ........................................................................................25
3.1.1. Lua ..........................................................................................................................27
3.1.2. Edição em Tempo Real...........................................................................................28
3.2. O AMBIENTE GINGA-J ..............................................................................................28
3.2.1. API JavaTV ............................................................................................................30
3.2.2. API DAVIC ............................................................................................................32
3.2.3. API HAVi ...............................................................................................................32
3.2.4. API DVB ................................................................................................................33
3.3. A PONTE ENTRE O GINGA-NCL E O GINGA-J .......................................................34

iii
3.4. INOVAÇÕES DO GINGA ............................................................................................34
4. GUIA DE DESENVOLVIMENTO DE UM APLICATIVO PARA TV DIGITAL.....36
4.1. APLICAÇÕES NO AMBIENTE GINGA-NCL............................................................39
4.2. APLICAÇÕES NO AMBIENTE GINGA-J ..................................................................40
4.2.1. O ciclo de vida da Xlet ...........................................................................................40
4.2.2. Ambiente Gráfico ...................................................................................................42
5. ESTUDO DE CASO ...........................................................................................................44
5.1. SISTEMAS DE RECOMENDAÇÃO ...........................................................................44
5.2. APLICAÇÃO AUTOCANAL.......................................................................................45
6. CONCLUSÃO.....................................................................................................................48
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................49
APÊNDICE A – TUTORIAL DE DESENVOLVIMENTO DE UM APLICATIVO EM
JAVATV ..................................................................................................................................53
APÊNDICE B - CÓDIGO DE IMPLEMENTAÇÃO DA APLICAÇÃO AUTOCANAL
..................................................................................................................................................62

iv
LISTA DE FIGURAS

Figura 1 - Componentes da TV Digital ....................................................................................12


Figura 2 - Arquitetura em camadas dos padrões para TVDI....................................................17
Figura 3 - Arquitetura em camadas do SBTVD .......................................................................21
Figura 4 - Arquitetura do Ginga ...............................................................................................25
Figura 5 - Representação das API’s do Ginga-J.......................................................................29
Figura 6 - Dimensões de desenvolvimento de aplicativos para TV digital ..............................36
Figura 7 - Diagrama com as opções de desenvolvimento ........................................................38
Figura 8 – Display exibindo várias Xlets .................................................................................39
Figura 9 - Estados de um Xlet ..................................................................................................41
Figura 10 - Modelo de display de imagem em camadas ..........................................................42
Figura 11 – Localização Espacial da aplicação AutoCanal......................................................46
Figura 12 - Diagrama das opções de desenvolvimento de aplicação AutoCanal.....................46
Figura 13 - Interface da aplicação AutoCanal ..........................................................................47

v
LISTA DE ABREVIATURAS

AAC - Advanced Audio Coding


ABERT - Associação Brasileira de Emissoras de Rádio e Televisão
ACATS - Advisory Committee on Advanced Television
ADTV-LAB - Advanced Digital Television Broadcasting Laboratory
API - Application Programming Interface
ARIB - Association of Radio Industries and Businesses
ARIB STD-B24 - Data Coding and Transmission Specification for Digital Broadcasting
ATSC - Advanced Television Systems Committee
AVC - Advanced Video Coding
BML - Broadcast Markup Language
CC - Common Core
COFDM - Coded Orthogonal Frequency Division Multiplex
DASE - DTV Application Software Environment
DTV - Digital Television
DVB - Digital Video Broadcasting
EPG - Electronic Program Guide
FCC - Federal Communications Commission
FDM - Frequency Division Multiplexing
GEM - Globally Executable MHP
HAVi - Home Audio Video Interoperability
HD-MAC - High Definition – MAC
HDTV - High Definition Television
ISDB - Integrated Services Digital Broadcasting
ISTVD - Sistema Internacional de Televisão Digital
IP - Internet Protocol
JDK - Java Development Kit
JMF - Java Media Framework
JVM - Java Virtual Machine
JVT - Joint Video Team
LDTV - Low Definition Television
MAC - Multiplexed Analog Components

vi
MHP - Multimedia Home Platform
NCL - Nested Context Language
NTSC - National Television System Committee
OFDM - Orthogonal Frequency Division Multiplex
PAL - Phase Alternation Line
PS - Program Streams
PSK - Phase Shift Keying
QAM - Quadrature Amplitude Modulation
SBTVD - Sistema Brasileiro de televisão Digital
SDTV - Sistema de Televisão Digital
SECAM - Séquentiel Couleur Avec Memoire
STB - Set Top Box
TS - Transport Strems
TVD - TV Digital
VCEG - Video Coding Experts Group
XML - Extensible Markup Language

vii
1. INTRODUÇÃO

A televisão é hoje um dos maiores meios de comunicação do mundo, proporcionando


para o telespectador fonte de informação, entretenimento e cultura. Seguindo a tendência
mundial do movimento de digitalização como nos diversos meios de comunicação, a televisão
está passando por um processo de substituição de suas plataformas analógicas por plataformas
e tecnologias digitais.

Esta mudança está provocando uma onda de impacto em todo o mundo como também
no Brasil. Com a tecnologia de TV Digital, há um ganho considerável em termos de resolução
da imagem (alta definição) e qualidade de som além de possibilitar a transmissão de vários
programas em um único canal. Entretanto, a principal característica da TV Digital é a
capacidade de permitir interatividade entre o usuário telespectador e a emissora de
programação.

Atividades como acessar menu de programação da emissora, realizar compras de


produtos (t-commerce), acessar contas bancárias, participar de enquetes, votar, escolher um
melhor ângulo de visão em transmissões de eventos esportivos, rever filmes e programas,
selecionar músicas para escutar, enviar e receber e-mails, jogar, etc., passam a fazer parte do
conjunto de recursos interativos possíveis.

O desenvolvimento de todas essas aplicações só é possível graças a uma camada de


software intermediário presente na arquitetura dos padrões dos sistemas de televisão digital
chamada de middleware. O middleware tem como finalidade oferecer um serviço padronizado
para as aplicações, escondendo as peculiaridades e heterogeneidades das camadas inferiores
(tecnologias de compressão, de transporte e de modulação) viabilizando assim o
desenvolvimento das aplicações de forma independente do hardware dos fabricantes dos
terminais de acesso ao sinal digital (set top boxes).

Atualmente existem três padrões mundiais de televisão digital: na Europa, o DVB


(Digital Vídeo Broadcast) [DVB, 2008], nos Estados Unidos o ATSC (Advanced
Television System Committee) [ATSC, 2008] e no Japão o ISBD (Integrated
Service Digital Broadcasting)[DiBEG, 2008], cada um utilizando um
middleware especifico. O Brasil adotou como base o padrão japonês dando origem assim ao
SBTVD (Sistema Brasileiro de Televisão Digital).

O SBTVD possui como middleware, o Ginga, que permite o desenvolvimento de


aplicações digitais interativas tanto na linguagem declarativa NCL (Nested Context
Language) quanto de forma não-declarativa na linguagem Java através de dois subsistemas
lógicos denominados, respectivamente, de Ginga-NCL e Ginga-J.

Nesse contexto, o trabalho tem o objetivo de documentar os aspectos relativos ao


sistema brasileiro de televisão digital e da plataforma Ginga. Outro objetivo é disseminar a
cultura de pesquisa e desenvolvimento dessas aplicações no Departamento de Computação da
Universidade Federal de Sergipe. Para isto será proposto um estudo de caso de um Sistema de
Recomendação para representar as funcionalidades e o potencial de desenvolvimento do
middleware Ginga.

O trabalho está dividido da seguinte forma: no capitulo dois será abordado o Sistema
Internacional de Televisão Digital, mostrando alguns conceitos sobre televisão digital, em
seguida será apresentado os padrões utilizados mundialmente e por fim mostrará como surgiu
o SBTVD e sua arquitetura utilizada. No capítulo três será mostrado o padrão de middleware
Ginga adotado com enfoque ao estudo das API (Application Programming
Interface) para o desenvolvimento das aplicações. O capitulo quatro mostrará um guia de
como desenvolver aplicações interativas para TV Digital e o capítulo cinco mostrará um
estudo de caso de um sistema de recomendação com base nesse guia. Por fim as conclusões
são apresentadas no capítulo seis.

9
2. SISTEMA DE TELEVISÃO DIGITAL INTERATIVA

A TV Digital interativa é uma fusão da TV tradicional com tecnologias de


computação, de forma que o telespectador possa dispor de sinal de alta qualidade, bem como
interagir com a aplicação, interferindo diretamente na programação que está recebendo. Este
capítulo abordará alguns conceitos sobre a televisão digital e os seus componentes. Serão
vistos os padrões mundiais de televisão digital, incluindo o padrão brasileiro juntamente com
a descrição das camadas de sua arquitetura.

2.1. TRANSMISSÃO NA TV DIGITAL

Para compreender como funciona o sistema digital de televisão é necessário entender o


funcionamento do atual sistema analógico utilizado nas transmissões.

Em um sistema de televisão analógica preto e branco a imagem é formada por


variações da cor preta, ou seja, o ponto é preenchido com uma intensidade determinada que
pode ser mais escura ou mais clara até chegar no branco de acordo com a amplitude do sinal.
Em um sistema de televisão analógica a cores o procedimento é semelhante, porém além de
processar o sinal referente ao nível de preto (sinal de luminância) ainda capta outro sinal
referente à cor (sinal de crominância) [SILVA, 2003].

Na transmissão digital, cada nível de intensidade de preto é transformado em código


binário, zeros (0) e uns (1), a mesma utilizada em computadores. Como na televisão digital
existem vários tipos de cores e tonalidades, há um conjunto de bits para representar todas
estas variações [SILVA, 2003].

Estes recursos trazem uma transmissão de melhor qualidade. Antes, para chegar até os
receptores dentro de suas casas, parte do sinal poderia sofrer interferências ou parte dele
poderia ser refletido por diversos obstáculos provocando ruídos, chuviscos e sobreposição de
imagens. O sistema digital é transmitido de forma binária (zero ou um), proporcionando um
sinal de alta qualidade de som e imagem. Na recepção do sinal digital ou o sinal chega com

10
perfeição ou não chega, caso haja interferência o sinal não será exibido. Estas transmissões
são feitas via aérea, com o uso de satélite, ou terrestre, por ondas ou cabos [SILVA, 2003].

No sistema digital além de melhorar a qualidade, tanto pela representação precisa da


informação como pela eliminação de ruídos, tem-se ainda a possibilidade de armazenamento,
processamento e a possibilidade de uma maior compressão das informações, apresentando
assim qualidades de portabilidade, mobilidade e interatividade [SILVA, 2003].

2.2. O CONCEITO DE INTERATIVIDADE

Segundo STEUER [1992], interatividade “mede” o quanto um usuário pode


influenciar na modificação imediata, na forma e no conteúdo de um ambiente computacional.
O termo é conceituado como uma variável baseada no tempo de resposta do estímulo.
Portanto, livros, jornais e TV aberta são caracterizados como meios pouco interativos; ao
contrário de teleconferência, e-mail e videogame.

A interatividade é a troca entre o usuário e um sistema computacional por meio de um


terminal dotado de tela de visualização [KOOGAN & HOUAISS, 1999]. Desta forma, o
usuário pode interagir alterando a forma e o conteúdo do ambiente mediado em tempo real.

O sistema de televisão brasileiro que conhecemos hoje é meramente reativo, pois os


telespectadores apenas reagem aos estímulos oferecidos pela emissora. Na TV
verdadeiramente interativa, o telespectador se comunica com a emissora através de um canal
de interatividade (canal de retorno).

Na TV digital, interatividade se traduz na possibilidade do usuário influenciar na


forma e no conteúdo do que está assistindo, poder se comunicar e realizar intervenções
através dos serviços e aplicações disponíveis.

Entretanto, alguns autores mais puristas dizem que estas formas de interatividade
ainda são meramente reativas, ou seja, reagem às opções determinadas pelo emissor.
Sugerindo a criação de mais alguns níveis de interatividade para que ela se torne pró-ativa,
possibilitando ao usuário enviar vídeos às emissoras e, desta forma, passar a contribuir com o
conteúdo transmitido. Tendo como exemplo o que acontece hoje na Internet com o advento da
Web 2.0 [MONTEZ & BECKER, 2005].

11
2.3. COMPONENTES DA TV DIGITAL INTERATIVA

Para analisarmos um sistema de televisão digital temos que partir de um modelo


genérico (Figura 1). Esse modelo é composto de três partes: (1) um transmissor ou difusor que
é responsável por prover serviços de entretenimento e interação para os usuários; (2) um canal
de difusão que é responsável pela entrega correta dos dados e (3) um receptor que recebe o
conteúdo televisivo e possibilita ainda a interação com o transmissor [SOUZA, 2004].

Figura 1 - Componentes da TV Digital

O conteúdo televisivo que pode ser fluxos de áudio, vídeo ou dados são transmitidos
por milhares de estações e recebidos por aparelhos digitais de televisão ou pelos STB (Set Top
Box). Esse aparelho é responsável por fazer a conversão do sinal digitalizado para TV
analógica além de possuir um canal de retorno para fornecer a interatividade entre o emissor e
telespectador. Ele é constituído por componentes de software (sistema operacional e ambiente
que executa os programas interativos) e hardware específico [FERNANDEZ, 2004].

O canal de retorno (canal de interação) é quem possibilita a comunicação entre o


receptor e o difusor. De acordo com a existência ou não do canal de retorno, foram
classificados níveis de interatividade que podem ser divididos em:

• Interatividade local: não utiliza o canal de retorno. Podem ser realizadas interações
como: configuração de legendas, jogos residentes e acesso ao guia de programação
eletrônica.

12
• Interatividade remota: utiliza o canal de retorno. Podem ser realizadas interações
como: comércio eletrônico, acesso a contas bancárias, serviços de saúde e aplicações
para educação à distância.

o Unidirecional: permite ao receptor apenas o envio de dados (upload). Por


exemplo: a compra de um determinado produto, votações e pesquisas de
opinião.

o Bidirecional: alem de enviar dados, permite ao receptor fazer o carregamento


de dados (download) utilizados pelos aplicativos. Por exemplo: navegação na
internet, e-mail, chat, jogos on-line e a comunicação entre os usuários.

2.4. ARQUITETURA DO SISTEMA DE TV DIGITAL INTERATIVA

Um sistema de televisão digital interativa pode adotar e integrar um conjunto de


diferentes tecnologias de hardware e software para implementar suas funcionalidades.
Considerando essa diversidade de soluções, diversos órgãos de padronização concentraram
esforços na especificação de padrões [FERNANDEZ, 2004].

A arquitetura de um sistema de televisão digital interativa é dividido em 5 camadas,


são elas: (1) aplicação; (2) middleware; (3) codificação; (4) transporte; (5) transmissão. A
idéia central da arquitetura em camadas é cada uma oferecer serviços para a camada superior
e usar os serviços oferecidos pela inferior. A seguir, estas camadas terão as suas
funcionalidades descritas.

2.4.1. Camada de aplicação

É a camada responsável pela captura e formatação dos sinais de áudio e vídeo, bem
como a execução dos aplicativos multimídias desenvolvidos. Desta forma segue uma lista de
possíveis aplicações com uma breve descrição.

• EPG (Eletronic Porgram Guide): programa de guia para conteúdos digitais.


Com ele, o telespectador pode navegar pelo conjunto de programações e serviços

13
oferecidos e escolher o que mais lhe agradar. Ele pode selecionar um canal
convencional ou resolver comprar um vídeo pré-armazenado para assistir.

• T-GOVERN: são serviços governamentais via TV. Oferece serviços importantes,


evitando o deslocamento a cartórios ou postos de informação, e consultas sobre a
disponibilidade de programas do governo.

• T-COMMERCE ou comercio televisivo: o consumidor passa a ter a oportunidade de


adquirir produtos anunciados diretamente pela TV, sem a necessidade de acessar o site
da empresa ou se deslocar até as lojas.

• Internet: aplicação muito importante e que ajudará bastante no processo de inclusão


digital.

• Vídeo sob demanda: o consumidor tem acesso a um acervo de vídeos que podem ser
escolhidos e apresentados sob sua demanda, na hora em que lhe for mais conveniente.

• Console de Jogos: possibilita o uso da televisão para jogos, permitindo que os


adversários estejam em rede ou que a própria televisão seja o adversário.

2.4.2. Middleware

O middleware é utilizado para mover informações entre programas ocultando do


programador diferenças de protocolos de comunicação, plataformas e dependências do
sistema operacional. É geralmente constituído por módulos dotados com APIs 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 relativamente ao
dispositivo.

O uso do middleware facilita a portabilidade das aplicações, permitindo que sejam


transportadas para qualquer receptor digital (ou Set Top Box) que suporte o middleware
adotado. Essa portabilidade é primordial em sistemas de TV digital, pois existe diversos tipos
de receptores digitais [MONTEZ & BECKER, 2005].

14
2.4.3. Camada de Codificação e Decodificação

Camada responsável pela remoção de redundâncias nos sinais de áudio e vídeo,


reduzindo assim a taxa de bits necessária para transmitir essas informações [MENDES, 2007].

A compressão de áudio e vídeo permite reduzir a quantidade de dados (taxa de bits)


necessária para representar vídeos digitais, diminuindo os custos de transmissão e
armazenamento dos mesmos. Compreende o modulo codificador e decodificador de
áudio/vídeo [MANUEL, 2007].

O codificador recebe como entrada o sinal de áudio/vídeo digital não comprimido,


disponibilizado pelo emissor, realiza a compressão e gera como saída um fluxo elementar de
áudio/vídeo que é fornecido a camada de transporte. O decodificador recebe como entrada
este fluxo elementar codificado a partir do demultiplexador da camada de transporte, realiza
sua decodificação e disponibiliza em sua saída o sinal de áudio/vídeo reconstruído [FUNTEL,
2006].

Esta camada permite a transmissão em diferentes resoluções e taxas de compressão.


Dentre eles estão o HDTV/1080i (1920 colunas por 1080 linhas entrelaçadas) e o
HDTV/720p (1280 colunas por 720 linhas progressivas) para imagens de alta definição; o
SDTV/480p (720 colunas por 480 linhas progressivas) para definição padrão; e o
LDTV/OneSeg (320 colunas por 240 linhas) para dispositivos móveis.

2.4.4. Camada de Transporte

A camada de transporte é que faz a multiplexação e demultiplexação dos fluxos


elementares de áudio, vídeo e dados. A idéia da multiplexação é agrupar áudio, vídeo e dados
em um único fluxo a serem transmitidos e demultiplexá-los quando este fluxo chegar no
receptor.

15
2.4.5. Camada de Transmissão e Recepção

Também denominada de camada física essa camada é responsável por levar as


informações digitais do estúdio da emissora até a casa dos telespectadores. Contudo, as
informações não podem ser enviadas diretamente pelo sistema de comunicação sem antes
sofrer uma modulação no envio, e uma demodulação na recepção [MENDES, 2007].

A modulação é necessária devido às características dos enlaces, que enfrentam


problemas de atenuação por perda de energia do sinal transmitido, ruídos e distorções de
atraso. Esses problemas são relacionados com a freqüência do sinal usada no sistema de
comunicação. O processo de modulação resolve este problema alterando alguma característica
de uma onda portadora de acordo com o sinal da informação a ser transmitido [MONTEZ &
BECKER, 2005].

2.5. PADRÕES MUNDIAIS DE TV DIGITAL INTERATIVA

Atualmente, existem três padrões mundiais de sistema de televisão digital interativa


reconhecidos, sendo estes: o europeu DVB, o americano ATSC; e o japonês ISDB. Estes
sistemas adotam diferentes padrões para modulação do sinal de difusão; transporte de fluxos
elementares de áudio, vídeo, dados e aplicações; codificação e qualidade de áudio e vídeo; e
serviços de middleware.

Logo abaixo, temos a Figura 2, que representa uma visão arquitetural em camadas das
opções de padrões para um sistema de televisão digital interativa. Em seguida, nos tópicos
seguintes, estão descritos os padrões mundiais de TV Digital, identificando os componentes
básicos adotados por eles.

2.5.1. ATSC - Padrão Americano

É o padrão norte-americano de sistema de televisão digital, especificado pelo comitê


ATSC. Em funcionamento nos Estados Unidos desde novembro de 1998 esse padrão utiliza a

16
modulação 8-VSB [SPARANO, 2000]. Define dois modelos técnicos de transmissão: via
cabo (ATSC-C) e via rádio-difusão (ATSC-T), sendo o modelo de transmissão a cabo o mais
difundido. A multiplexação e codificação de vídeo são feitas sobre o padrão MPEG-2, já a
codificação de áudio é realizada através do padrão Dolby AC-3 [ATSC, 2001].

Figura 2 - Arquitetura em camadas dos padrões para TVDI

Entre os pontos positivos deste padrão está à característica de utilizar uma camada de
software em interface aberta, o DASE (DTV Application Software
Environment)[DASE, 2008]. O DASE define uma camada de software, o middleware,
no qual os receptores de outros padrões conseguem ter acesso as informações e programações
do padrão ATSC [SILVA, 2003].

Esse padrão privilegia a transmissão de alta qualidade (HDTV), contudo não dá


suporte à transmissão de televisão digital para terminais móveis, sendo um dos seus grandes
pontos negativos [ANATEL, 2004].

17
2.5.2. DVB - Padrão Europeu

O padrão DVB adotado na Europa no início da década de 90 está presente na União


Européia, Austrália e Nova Zelândia. O DVB pode ser usado para sistemas de alta definição
(HDTV – High Definition Television) e sistemas móveis de baixa definição
(LDTV – Low Definition Television). No entanto, alguns estudos apontam que o
funcionamento não é satisfatório quando ocorrem transmissões simultâneas para sistemas de
alta definição e sistemas móveis [FERNANDEZ, 2004].

Os principais padrões de transmissão adotados pelo DVB são: DVB-T: (transmissão


terrestre por radiodifusão); DVB-C (transmissão via cabo); DVB-S (transmissão via satélite);
DVB-MC (transmissão via microondas operando em freqüências de até 10GHz); e DVB-MS
(transmissão via microondas operando em freqüências acima de 10GHz) [FERNANDEZ,
2004].

Na camada de codificação, o sinal de áudio é codificado usando a recomendação


MPEG2-BC e o sinal de vídeo é codificado usando a recomendação MPEG-2 Vídeo [ISO,
1996b]. Na camada de transporte é usado o padrão MPEG-2 Sistemas [ISO, 1996a].

Para este padrão foi desenvolvido um middleware próprio: o MHP (Multimedia


Home Plataform). Seu ambiente de execução é baseado no uso de uma máquina virtual
Java e um conjunto de API’s.

2.5.3. ISDB - Padrão Japonês

Criado em 1999 por várias empresas e operadoras de televisão, o ISDB é o padrão de


transmissão terrestre japonês, sendo adotado somente por aquele país. Existem três formas de
transmissão do ISDB, o ISDB-S (transmissão via satélite), o ISDB-T (transmissão terrestre
por radiodifusão) e o ISDB-C (transmissão via cabo) e todos os três dispõem do mesmo
processamento digital [SILVA, 2003].

O ISDB utiliza a modulação COFDM (Coded Orthogonal Frequency


Division Multiplex) [BAHAI, 2004]. A multiplexação e a codificação de vídeo, como

18
nos dois padrões anteriores, também são realizadas em MPEG-2, já a codificação de áudio
utiliza o MPEG-2 ACC [ISO, 1997].

O middleware do ISDB se chama ARIB, nome adotado da organização responsável


por criar a sua padronização, a ARIB (Association of Radio Industries and
Businesses).

É o mais novo dentre os três principais padrões e seu grande diferencial é o suporte a
múltiplos níveis de transmissão, podendo ser usado, por exemplo, para prover
simultaneamente recepção de baixa taxa de dados sob condições móveis excepcionalmente
difíceis, taxa de dados intermediária (SDTV) para recepção estática e alta taxa de dados
(HDTV) para boas condições de recepção [FERNANDEZ, 2004].

2.6. SURGIMENTO DA TV DIGITAL NO BRASIL

No final da década de 80, Estados Unidos, Europa e Japão já se encontravam


adiantados em relação aos estudos de TV de alta definição. Diante do progresso desses países,
o Brasil decidiu também concentrar esforços no estudo tecnológico da televisão.

Em 1991, o governo brasileiro, através do Ministério das Comunicações, estabeleceu a


Comissão Assessora para Assuntos de Televisão (Com-TV) encarregada de estudar e
analisar a TV de alta definição que estava sendo desenvolvida em alguns países. Os estudos
evoluíram de tal modo que culminaram nos sistemas de TV digital [LOPES, 2007].

Então, em 1994, a Associação Brasileira de Emissoras de Rádio e Televisão


(Abert) e a Sociedade Brasileira de Engenharia de Televisão e Telecomunicações (Set)
uniram-se formando o Grupo Técnico Abert/Set de TVD. A missão desse grupo é
acompanhar o desenvolvimento da TVD no mundo com o objetivo de colaborar no processo
de definição do padrão a ser adotado no Brasil [LOPES, 2007].

A partir de 1998, foram iniciados testes com os modelos europeu e norte-americano e


somente em 1999 começou a ser realizados testes com o padrão japonês. Em 2003
intensificaram-se as discussões sobre TVD. Somente em 26 de novembro de 2006, após
inúmeros debates sobre qual padrão deveria ser adotado ou se deveria ser desenvolvido um
padrão nacional é que o Brasil assinou um decreto de lei nº 4.901. Instituindo o padrão
19
japonês como modelo a ser implantado no país. Porém, com algumas inovações,
principalmente, na camada de middleware e de codificação.

Embora, no Brasil, exista discórdia entre alguns órgãos (governo, emissoras,


pesquisadores, entre outros) sobre qual padrão deveria ser adotado, o governo brasileiro
tomou sua decisão, por considerar o padrão japonês o que melhor atendia as necessidades do
país. Como por exemplo: a dispensa de pagamento de royalties; o comprometimento do
governo japonês em colaborar, “na medida do possível”, com o desenvolvimento de uma
indústria eletroeletrônica nacional; a transmissão de conteúdo a dispositivos móveis e
portáteis.

Segundo Agencia de Noticias do Planalto, o cronograma de implantação prevê que até


dezembro de 2013 o novo sistema digital já estará funcionando em todo território brasileiro e
que modelo analógico terá suas transmissões encerradas em julho de 2016 [LOPES, 2007].

2.7. PADRÃO BRASILEIRO DE TV DIGITAL

Como apresentado anteriormente, o SBTVD e sua arquitetura (Figura 3) foi baseado


no padrão japonês, tendo suas principais mudanças na camada de codificação e de
middleware. No Brasil é utilizada a técnica de compressão de vídeo mais recente e mais
eficiente chamada de H.264 [RICHARDSON, 2003], diferentemente dos outros padrões
mundiais que utilizam a técnica MPEG-2 e na camada de middleware o Brasil
desenvolveu e adotou o Ginga. A seguir será descrito os padrões adotados em cada camada da
arquitetura do sistema brasileiro.

2.7.1. Middleware

Desenvolvido em universidades brasileiras, o middleware do SBTVD é o Ginga que


foi definido para duas classes de aplicações, as declarativas e as procedurais, chamadas
respectivamente de Ginga-NCL [SOARES, 2007] e o Ginga-J [LEMOS, 2007]. O capítulo
seguinte é dedicado a um estudo mais detalhado sobre este middleware.

20
Figura 3 - Arquitetura em camadas do SBTVD

2.7.2. Camada de Codificação e Decodificação

Para compressão de vídeo, o sistema brasileiro inovou ao definir o padrão H.264,


também conhecido como MPEG-4 Part 10 ou AVC (Advanced Video Coding), no
lugar do padrão MPEG-2 utilizado nos outros sistemas de TV Digital, pois o H.264 permite
obter a mesma qualidade do MPEG-2 com a metade da taxa de bits. Assim, o seu uso permite
transmitir uma quantidade duas vezes maior de vídeos por um mesmo canal usado pelo
MPEG-2.

O padrão H.264 foi desenvolvido pela ITU-T Video Coding Experts Group
(VCEG) em conjunto com a ISO/IEC MPEG que formaram uma parceria conhecida por
Joint Video Team (JVT). A versão final, formalmente chamada por ISO/IEC 14496-
10), foi lançada em Maio de 2003 [MANUEL, 2007].

Este padrão permite formatos de transmissão com diferentes resoluções e taxas de


compressão. Dentre eles estão o HDTV/1080i e o HDTV/720p para imagens de alta
definição; o SDTV/480p para definição padrão; e o LDTV/OneSeg para dispositivos móveis.

21
Para compressão de áudio foi adotado o MPEG-4 AAC (Advanced Audio
Coding), também conhecido como MPEG-2 Part 7 ou MPEG-4 Part 3. Este formato é uma
evolução da Camada-3 do MPEG-1 Áudio (também denominada MP3).

O AAC consegue taxa de compressão bem superior que seu antecessor. Uma das
características desse sistema é a propriedade de análise da redundância da informação entre
vários fluxos. Permite também acomodar até 48 fluxos de áudio e até 15 programas distintos.
Pode ser transmitido em 2 ou 5.1 canais [SILVA, 2003].

2.7.3. Camada de Transporte

Na camada de transporte foi adotado o padrão MPEG-2 System. Este padrão adiciona
aos fluxos elementares de áudio principal e vídeo principal informações para suas exibições
sincronizadas. A sincronização é realizada seguindo o paradigma de eixo do tempo (timeline)
pela adição de carimbos de tempo (timestamp) a conjuntos de amostras codificadas de vídeo e
áudio baseado em um relógio compartilhado. A geração de fluxos de dados também são
determinadas pelo padrão [BARBOSA & SOARES, 2008].

No receptor, essa seqüência de pacotes será demultiplexada e as seqüências


elementares de bits serão reconstruídas e entregues aos seus respectivos decodificadores.
Utilizando informações contidas no cabeçalho dos pacotes de transporte, é possível a
realização de operações como sincronização do aparelho receptor, detecção e sinalização de
erros [FERNANDEZ, 2004].

2.7.4. Camada de Transmissão e Recepção

O padrão utilizado pelo sistema brasileiro na camada de transmissão é o COFDM


modulando em QAM (Quadrature Amplitude Modulation) ou PSK (Phase
Shift Keying) [RODRIGUES & GOMES, 2004].

O COFDM é uma técnica de modulação baseada no OFDM (Orthogonal


Frequency Division Multiplex) o qual utiliza subportadoras ortogonais para

22
modular os sinais, diferindo no acréscimo da codificação, de onde se acrescenta o “C” ao
OFDM [RODRIGUES & GOMES, 2004].

O acréscimo da codificação de canal tem como objetivo corrigir os erros produzidos


na transmissão. Embora sua complexidade seja elevada, COFDM possui melhor desempenho
sob canais em condições realmente desafiadoras [RODRIGUES & GOMES, 2004].

23
3. O GINGA E SUA ARQUITETURA

Ginga é a camada de software intermediário (middleware) que permite o


desenvolvimento de aplicações interativas para a TV Digital de forma independente da
plataforma de hardware dos fabricantes de terminais de acesso (set top boxes).

Sendo compatível com as definições internacionais ITU, o Ginga foi desenvolvido


com o objetivo de levar em consideração as últimas inovações tecnológicas e as necessidades
de inclusão digital no país, objetivos estes que não seriam alcançados caso fosse adotado
qualquer um dos middlewares já existentes.

O Ginga define uma API padrão, que todo exibidor acoplado ao sistema deve
obedecer, para reportar seus eventos e serem comandados por ações geradas pelo formatador.
Exibidores de terceiros fabricantes, incluindo aí os browsers HTML, usualmente necessitam
de um módulo adaptador para realizar essas funções e se integrarem ao Ginga [TELEMÍDIA,
2008].

Por ser mais recente, o sistema brasileiro de TV digital teve por obrigação procurar as
alternativas tecnológicas atuais. Entre elas estava à concepção de um middleware no qual a
convivência dos ambientes declarativo e procedural fosse a mais eficiente possível em termos
de custo e desempenho.

O Ginga dá suporte a aplicações para TV digital e tem como foco: o sincronismo de


mídia na sua forma mais ampla, tendo a interatividade do usuário como caso particular; a
adaptabilidade do conteúdo a ser apresentado; e o suporte a múltiplos dispositivos de
interação e exibição [TELEMÍDIA, 2008].

A arquitetura da implementação de referência do middleware Ginga (Figura 4) pode


ser dividida em três módulos: o Ginga-CC (Common Core), o ambiente de apresentação
Ginga-NCL (declarativo) e o ambiente de execução Ginga-J (procedural).

O Ginga-CC (Ginga-Common Core ou Ginga-Núcleo Comum) oferece o suporte


necessário aos ambientes declarativo e procedural, e tem como funções principais a exibição

24
dos vários objetos de mídia, o controle do plano gráfico, o tratamento de dados obtidos do
carrossel de objetos DSM-CC1, o tratamento do canal de retorno, entre outras.

Figura 4 - Arquitetura do Ginga

3.1. O AMBIENTE GINGA-NCL

Ginga-NCL foi desenvolvido pela PUC - Rio visando prover uma infra-estrutura de
apresentação para aplicações declarativas escritas na linguagem NCL (Nested Context
Language). NCL é uma aplicação XML (eXtensible Markup Language) com
facilidades para a especificação de aspectos de interatividade, sincronismo espaço-temporal
entre objetos de mídia, adaptabilidade, suporte a múltiplos dispositivos e suporte à produção
ao vivo de programas interativos não-lineares.

Por ser uma aplicação XML, a linguagem NCL possui uma separação estrita entre
conteúdo e estrutura, NCL não define qualquer mídia por ela mesma. Ao invés, ela é a cola
que mantém a mídia junta com uma apresentação multimídia. Porém, um documento NCL
somente define como os objetos de mídia são estruturados e relacionados, no tempo e no

1
Como a sintonização de um canal específico de TV pode ser realizada em qualquer instante, o
Carrossel DSM-CC envia ciclicamente dados que não tenham relação temporal por meio de carimbos de tempo.
O recebimento desses dados é independente do instante de sintonização.

25
espaço. Como uma linguagem de cola, ela não restringe ou prescreve o conteúdo do tipo de
objeto de mídia [SOARES, 2007].

Objetos de vídeo (MPEG etc.), áudio (AAC etc.), imagem (JPEG, GIF etc.) e texto
(TXT, HTML etc.) são exemplos de objetos de mídia. Entre esses objetos ressaltam-se os
objetos de vídeo e áudio que, no SBTVD, são tratados por exibidores em hardware
[TELEMÍDIA, 2008].

Outro objeto importante no sistema brasileiro é aquele baseado em XHTML. NCL não
substitui XHTML, mas a complementa naquilo que ela é incapaz de cumprir como uma
linguagem declarativa. Diferente do XHTML a linguagem NCL não mistura a definição do
conteúdo de um documento com sua estruturação. Dependendo do browser embutido no
Formatador NCL será determinado qual objeto XHTML terá suporte. De acordo com essa
escolha, teremos compatibilidade com os padrões europeu, americano ou japonês
[TELEMÍDIA, 2008].

Durante a exibição dos conteúdos dos vários objetos de mídia, eventos são gerados.
Eventos podem gerar ações (de sincronismo) em outros objetos de mídia, tais como parar,
iniciar ou pausar suas apresentações. Assim, os eventos devem ser reportados pelos diversos
exibidores ao Formatador NCL que, por sua vez, gerará ações a serem aplicadas em outros
objetos de mídia, fazendo com que as relações de sincronismo entre os objetos de mídia
existentes sejam respeitadas [TELEMÍDIA, 2008].

O Formatador NCL é o responsável por receber um documento NCL e controlar sua


apresentação, fazendo com que as relações de sincronismo entre os objetos de mídia
existentes sejam respeitadas.

O ambiente declarativo é, por si só, muito restrito. Aplicações que utilizem uma
linguagem declarativa devem ter seu foco no sincronismo, sendo o foco da linguagem NCL
exatamente esse, e não a interatividade, visto que a interatividade é tratada como uma
decorrência do sincronismo [SOARES, 2007].

Em NCL um documento XHTML é um tipo de elemento de mídia. De forma


semelhante, linguagens imperativas podem ser adicionadas e usadas como nós de mídia. Em
específico, a Ginga-NCL deve oferecer suporte a duas linguagens procedurais pela
especificação, Lua e Java. Lua é a linguagem de script da NCL e a Java deve seguir as
especificações do Ginga-J [CRUZ , 2008].

26
3.1.1. Lua

Lua é uma linguagem de programação de extensão projetada para dar suporte à


programação procedural e oferece facilidades para a descrição de dados. A linguagem
também oferece um bom suporte para programação orientada a objetos, programação
funcional e programação orientada a dados. Lua foi planejada para ser utilizada por qualquer
aplicação que necessite de uma linguagem de script leve e poderosa [IERUSALIMSCHY,
2007].

Por ser uma linguagem de extensão, Lua não possui a noção de um programa
principal: ela somente funciona embarcada em um programa cliente anfitrião, chamado de
programa hospedeiro ou simplesmente de hospedeiro. Esse programa hospedeiro pode
invocar funções para executar um pedaço de código Lua, pode escrever e ler variáveis Lua e
pode registrar funções C para serem chamadas pelo código Lua [IERUSALIMSCHY, 2007].

Lua funciona como uma máquina virtual (engine) acoplada ao Formatador NCL.
Isso significa que, além de sintaxe e semântica, Lua fornece uma API que permite a troca de
dados com aplicações. É importante também destacar a integração entre Lua e Java, através
da biblioteca LuaJava, que permite o acesso a qualquer classe de Java a partir de Lua, de
forma similar ao que acontece com ECMAScript [ECMA, 2008]. Além disso, o LuaJava
permite que a manipulação do ambiente de Lua a partir de Java, tornando-se, assim, parte da
ponte entre os ambientes declarativo e procedural do middleware Ginga [TELEMÍDIA,
2008].

O uso de Lua oferece vantagens: além de ser um projeto de código aberto e


desenvolvido em C, Lua combina programação procedural com poderosas construções para
descrição de dados, baseadas em tabelas associativas e semântica extensível; Lua é tipada
dinamicamente, interpretada a partir de bytecodes, e tem gerenciamento automático de
memória com coleta de lixo. Destaca-se pelo alto desempenho e baixo consumo de recursos
apresentados, quando comparada com outras linguagens interpretadas. Essas características
fazem de Lua uma linguagem ideal para configuração, automação (scripting) e prototipagem
rápida [MORENO, 2006].

27
3.1.2. Edição em Tempo Real

No contexto de TV digital, a apresentação e a autoria de documentos hipermídia são


normalmente tratadas em fases distintas. Embora, muitas vezes essas fases precisam ser
tratadas de forma conjunta. Como, por exemplo, temos o caso dos programas editados ao
vivo, onde inicialmente não só alguns conteúdos são desconhecidos, como também alguns
relacionamentos espaço/temporais entre objetos de mídia podem, ainda, não ter sido definidos
[MORENO, 2006].

Muitos ambientes de autoria dispõem de um emulador de visualização em tempo real.


O emulador permite ao autor visualizar a apresentação de um documento durante seu processo
de criação. Entretanto, quando o documento é editado, pode ser necessário reiniciar a
apresentação, para que o resultado seja constatado.

Diferente desse cenário, a edição ao vivo requer outros requisitos. Para atender estes
requisitos um sistema de TV digital interativa, e conseqüentemente seu ambiente de autoria,
deve prover meios para se definir uma especificação inicial do documento. Como também,
deve prover meios para modificar essa especificação em tempo de apresentação no ambiente
do cliente telespectador [GUIMARÃES, 2007].

3.2. O AMBIENTE GINGA-J

Ginga-J foi desenvolvido pela Universidade Federal da Paraiba para prover uma infra-
estrutura de execução de aplicações baseadas em linguagem Java, chamadas de Xlet, com
facilidades especificamente voltadas para o ambiente de TV digital.

As Xlets não precisam estar previamente armazenadas no STB, pois podem ser
enviadas pelo canal de difusão. Ou seja, o modelo Xlet é baseado na transferência de código
executável pelo canal de difusão para o STB e posterior carga e execução do mesmo, de
forma automática ou manual. Uma Xlet é bastante similar a um Applet na Web ou MIDlet em
celulares e outros dispositivos móveis [FERNANDEZ, 2004].

28
Buscando controlar as Xlets, cada STB possui um Gerente de Aplicações (Application
Manager) instalado. Um gerente de aplicações lida com os estados de cada Xlet, permitindo
iniciar sua execução, destruir, pausar e retomar sua execução. Esses estados são necessários,
pois uma aplicação pode ser pausada momentaneamente se esta for ocultada por um vídeo de
TV; ou ainda pode ser destruída caso o usuário troque de canal. A Xlet precisa ser notificada
quando seu estado muda (por exemplo, quando é pausada) e, assim, pode lidar com seus
recursos (ex. liberar memória).

O ambiente de execução Ginga-J define um conjunto de API’s representadas abaixo


(Figura 5) que podem ser divididas em três partes: as APIs vermelhas, inovações que dão
suporte às aplicações brasileiras, em especial as de inclusão social; as APIs amarelas, também
inovações brasileiras, mas que podem ser exportadas para os outros sistemas; e as APIs
verdes, que seguem o núcleo comum do padrão GEM. [SOFTWARE PUBLICO, 2008]

Figura 5 - Representação das API’s do Ginga-J

As aplicações Ginga-J diferente das aplicações JAVA destinada a desktops, devem


obedecer a um conjunto de APIs mais restritivas e que foram definidas objetivando dar
suporte ao desenvolvimento de aplicações para TV digital.

Na sua versão atual o Ginga-J segue as especificações do GEM (Globally


Executable MHP) e ITU J.200, J.201 e J.202 sendo portanto compatível com os demais

29
midllawares de TV digital que seguem essas especificações. O GEM é baseado no
middleware MHP e especifica um conjunto de APIs para serem usadas no desenvolvimento
de aplicações para a TV digital, incluindo as APIs provenientes de pacotes da Sun JavaTV,
DAVIC [DAVIC, 1999] e HAVI [HAVi, 2001].

3.2.1. API JavaTV

A API Java TV é uma extensão para a plataforma Java para sustentar a produção de
conteúdo interativo de forma procedural para a televisão digital. A principal finalidade da API
Java TV é fornecer um conjunto de métodos, classes e interfaces para facilitar a construção de
aplicativos destinados a serem executados através de plataformas de recepção de televisão
digital independentes das tecnologias utilizadas na rede de transmissão [ABNT 00:001.85-
006/4].

Cada serviço Java TV é caracterizado por um conjunto de informações que descrevem


o conteúdo do serviço (SI - Service Information). As informações sobre os serviços
disponíveis são armazenadas em uma base de dados de informações de serviços (SI
Database). A API Java TV provê uma abstração que permite aplicações obterem informações
sobre os diversos serviços disponíveis de forma independente do hardware e dos protocolos
adotados. Desta forma, uma aplicação pode ser reusada em uma variedade de ambientes
[FERNANDEZ, 2004].

A JavaTV suporta um alto nível de interatividade, gráficos de qualidade e seu


processamento pode ser executado dentro de uma Set Up Box, desde que esta esteja
equipada com a Máquina Virtual JAVA, necessária para interpretar os bytecodes gerados.
Com o uso de JavaTV, programas de televisão tradicionais e interativos são caracterizados
como um conjunto de serviços individuais. Cada serviço pode representar um programa de
televisão convencional, não somente contendo áudio e vídeo, como também um serviço pode
se tornar interativo, contendo áudio, vídeo, dados e aplicações associadas [FERNANDEZ,
2004].

30
Utilizando-se de sua arquitetura a API JavaTV é capaz de executar funcionalidades,
como:

• Fluxo de áudio e vídeo: Além do fluxo de vídeo e áudio vindos da emissora, é


possível gerar na aplicação outros fluxos;

• Acesso a dados no canal de transmissão: no JavaTV pode-se receber dados


para as aplicações;

• Interatividade com aplicações: Os aplicativos que usam esta API podem


processar dados e retorná-los através de um canal de retorno;

• Gerenciamento do ciclo de vida das aplicações: permitindo que aplicações


coexistam com o conteúdo convencional de TV e possibilitando a troca de
canal sem que a aplicação deixe de existir.

A API JavaTV tem várias bibliotecas, que são responsáveis por prover a estrutura
básica do sistema. As bibliotecas estão dispostas da seguinte forma:

• javax.tv.carousel: provê acesso a arquivos broadcast e diretórios de dados


através de APIs que trabalham com o pacote java.io;

• javax.tv.graphics: permite que Xlets possam obter seu repositório principal;

• javax.tv.locator: provê uma forma para referenciar dados ou programas


acessíveis pela API JavaTV;

• javax.tv.media: define uma extensão para JMF (Java Media Framework)


com a finalidade de gerenciar mídia em tempo real;

• javax.tv.media.protocol: provê acesso a um fluxo de dados broadcast genérico;

• javax.tv.net: permite acesso a datagramas IP (Internet Protocol)


transmitidos num stream broadcast;

• javax.tv.service: provê mecanismos para acessar a base de dados;

• javax.tv.util: suporta a criação e o gerenciamento de eventos do timer;

• javax.tv.xlet: provê interfaces para o desenvolvimento de aplicações e para a


comunicação entre as aplicações e o gerenciador.

31
Java TV tem sido amplamente adotado por organizações de padronização, tornando-o
um forte candidato a padrão mundial para conteúdo de televisão digital interativa. Temos
como exemplo, as diversas implementações de middleware que adotaram o modelo Java TV,
com ligeiras diferenças entre si.

3.2.2. API DAVIC

O sistema DAVIC (Digital Audio Visual Council) é um conjunto de


especificações que apresenta alguns requisitos de sistemas audiovisuais para prover
interoperabilidade fim-a-fim. Assim, esses padrões podem ser utilizados nos sistemas de
televisão digital para fornecer conteúdo ao usuário final e também para permitir interatividade
com o mesmo usuário [ABNT 00:001.85-006/4].

O sistema DAVIC tem suas próprias API, e portanto ele também pode ser considerado
como um middleware de alto nível (apesar de ser comum para ele operar em conjunto com
um middleware de nível mais baixo). A seguir são listados os pacotes que são parte da API
DAVIC incluídos no Ginga-J [ABNT 00:001.85-006/4]:

• org.davic.media
• org.davic.resources
• org.davic.mpeg
• org.davic.mpeg.sections
• org.davic.net
• org.davic.net.dvb
• org.davic.net.tuning

3.2.3. API HAVi

HAVi (Home Audio Video Interoperability) é uma API que permite ao


programador criar elementos para a interface com o usuário. Provê uma extensão ao pacote
java.awt, permitindo, assim, suporte a controle remoto, transparência, entre outros;

32
O principal objetivo de uma interface de usuário é oferecer um ambiente operacional
fácil de usar. A arquitetura HAVi permite que os usuários controlem dispositivos de forma
familiar, através de um controle remoto ou de uma tela frontal. A seguir são listados os
pacotes que são parte do HAVi API incluídos no Ginga-J API [ABNT 00:001.85-006/4]:

• org.havi.ui

• org.havi.ui.event

3.2.4. API DVB

Ao desenvolver o middleware padrão MHP, o DVB incluiu alguns pacotes para


estender as funcionalidades oferecidas pelo JavaTV, HAVi e DAVIC. Essas funcionalidades
incluíram API de Informações de Serviço, Intercomunicação entre Xlets, persistência etc.
Algumas das funcionalidades também foram incluídas na GEM. A seguir são listados os
pacotes que são parte da API DVB incluídos no Ginga-J [ABNT 00:001.85-006/4]:

• org.dvb.application

• org.dvb.dsmcc
• org.dvb.event
• org.dvb.io.ixc
• org.dvb.io.persistent
• org.dvb.lang
• org.dvb.media
• org.dvb.net
• org.dvb.net.tuning
• org.dvb.net.rc
• org.dvb.test
• org.dvb.ui

33
3.3. A PONTE ENTRE O GINGA-NCL E O GINGA-J

A ponte é responsável por permitir um caminho de comunicação entre os ambientes


Ginga-NCL e o Ginga-J, pois é através dela que aplicações declarativas podem executar
chamadas a aplicações procedurais e vice-versa. Essa comunicação pode ser feita em duas
direções.

Em uma direção, possibilita ao ambiente declarativo chamar uma Xlet do Ginga-J


como um simples objeto de mídia procedural NCLet ou através de um objeto de mídia
procedural NCLua (script LUA), cujos métodos referenciam métodos do Ginga-J.

Na direção contrária, através de funções do Ginga-J que podem monitorar eventos do


NCL e podem também alterar elementos e atributos do NCL através de relações ou de
comandos de edição NCL. Isso é similar ao que pode ser feito por objetos NCLua.

3.4. INOVAÇÕES DO GINGA

As funcionalidades inovadoras do Ginga-J, providas por suas APIs, permitem o


desenvolvimento de aplicações avançadas, explorando a integração com outros dispositivos
tais como telefones celulares, PDAs, etc. Essa integração foi motivada por um outro número:
o Brasil correntemente possui 79,5 milhões de telefones celulares. Um telefone celular pode
ser utilizado como um canal de retorno para o ambiente de TV, ou usado como um controle
remoto, ou ainda como um dispositivo de interação (para responder a enquetes de maneira
individual, por exemplo), etc. Uma vez que essas funcionalidades são todas implementadas
utilizando protocolos comuns tais como Bluetooth, USB, Wi-Fi, etc., o Ginga é compatível
com diversos dispositivos [MENDES, 2007].

Há também a possibilidade de atualização do middleware em tempo de execução,


tornando possível receber atualizações ou correções através de um canal de retorno ou pela
emissora e corrigir as falhas, sem a necessidade de conhecimento do usuário.

34
Outra inovação do middleware brasileiro é a ponte entre o ambiente declarativo e o
procedural, no qual uma aplicação pode alterar e/ou executar uma aplicação de outro
ambiente.

É possível a gravação de aplicativos no middleware para serem executados


posteriormente. Essa funcionalidade será bastante útil para a utilização na educação, pois o
professor poderá salvar uma aplicação para ser executada com os alunos em um horário mais
conveniente, ou simplesmente poder aplicar quantas vezes desejar, sem a necessidade de
esperar o programa ser exibido novamente pela emissora. Essa funcionalidade foi
desenvolvida para atender uma das exigências da inclusão digital.

35
4. GUIA DE DESENVOLVIMENTO DE UM APLICATIVO PARA TV DIGITAL

Este guia visa mostrar as opções e os passos necessários que o desenvolvedor de


aplicações para TV Digital deve determinar antes de iniciar a implementação. As opções para
o desenvolvimento de aplicativos podem ser representadas ao longo de três dimensões (Figura
6): (1) níveis de interatividade (interatividade local ou remota); (2) o desenvolvedor (emissora
ou usuário); e (3) o ambiente de execução.

Ambiente

Ginga-NCL

Ginga-J

Níveis de
Emissora Interatividade

Usuário Int. Remota Int. Local

Desenvolvedor

Figura 6 - Dimensões de desenvolvimento de aplicativos para TV digital

A TV Digital é mais do que uma imagem e um som de alta definição. Com ela é
possível desenvolver, para a televisão, aplicativos com capacidade computacional, como os de
desktops, que permitem armazenar e processar informações, e desde que exista um canal de
retorno possibilitando a construção de aplicações interativas.

Essas aplicações podem ser desenvolvidas tanto pelas emissoras de televisão quanto
pelos usuários. Caso seja desenvolvida por uma emissora, a aplicação será enviada ao set top
box através do canal de transmissão. No caso de ser desenvolvida por um usuário esta terá que
ser enviada ao set top box através de uma entrada externa (porta USB, porta de rede, cartão de
memória, etc).

36
Definido o nível de interatividade e o desenvolvedor, deve-se então definir o ambiente
de execução. Como visto no capítulo anterior, o Ginga oferece dois ambientes de execução: o
ambiente para aplicações declarativas Ginga-NCL e o ambiente para aplicações não-
declarativo Ginga-J.

Linguagens de programação declarativas são linguagens de alto nível de abstração,


usualmente ligadas a um domínio ou objetivo específico. Nelas, 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, compilador ou a própria máquina virtual de
execução) realmente implementará essas tarefas. Linguagens declarativas resultam em uma
declaração do resultado desejado, ao invés da sua decomposição em uma implementação
algorítmica, e portanto normalmente não necessitam de tantas linhas de código para definir
certa tarefa [BARBOSA & SOARES, 2008].

Numa programação não-declarativa, devemos informar cada passo a ser executado.


Pode-se afirmar que, em uma especificação seguindo o paradigma não-declarativo, o
programador possui um maior poder sobre o código, sendo capaz de estabelecer todo o fluxo
de controle e execução de seu programa [BARBOSA & SOARES, 2008].

O universo das aplicações de um sistema de TV digital pode ser particionado em um


conjunto de aplicações declarativas e um conjunto de aplicações não-declarativas. Linguagens
declarativas normalmente são focadas em um domínio ou um objeto específico, pois é
praticamente impossível uma linguagem declarativa de propósito geral. Quando o foco do
problema não casa com o foco da linguagem, sua resolução, embora não seja impossível,
pode ser muito difícil. Neste caso recomenda-se o uso de uma linguagem não-declarativa
[BARBOSA & SOARES, 2008].

Com o desenvolvedor, nível de interatividade e o ambiente de execução definidos,


podemos, agora, definir o passos seguintes para criação destes aplicativos. O diagrama
ilustrado na Figura 7 representa as opções de desenvolvimento disponíveis em cada ambiente.

No ambiente Ginga-NCL, podemos criar objetos que serão exibidos através do


Formatador NCL. Esses objetos também chamados de “nó de conteúdo” podem ser: (1) um
objeto de mídia que faz associação a um elemento de mídia como vídeo, áudio, imagem,
texto, etc.; (2) um objeto XHTML que faz associação a um elemento XHTML; (3) um objeto
Lua que associa um elemento para dar suporte à programação não-declarativa utilizando
scripts Lua.

37
Figura 7 - Diagrama com as opções de desenvolvimento

No ambiente de execução das Xlets, o Ginga-J, devemos definir a quantidade de Xlets


necessárias. Esta quantidade depende do número de funcionalidades distintas que serão
implementadas para solucionar o problema. É recomendado criar uma Xlet para cada
funcionalidade específica como visto na ilustração da Figura 8.

De posse da quantidade de Xlets suficientes para solucionar o problema, o


desenvolvedor precisa definir, de acordo com as funcionalidades oferecidas (expostas nos
itens 3.2.x), quais API’s terão suas classes implementadas.

Nos tópicos seguintes deste capítulo é descrito os conceitos dos objetos NCL e do
funcionamento dos Xlets utilizadas.

38
Figura 8 – Display exibindo várias Xlets

4.1. APLICAÇÕES NO AMBIENTE GINGA-NCL

Aplicativos para o Ginga-NCL são construídos sob a forma de documentos


hipermídia. Esses documentos obedecem à formatação da linguagem NCL e são compostos
por nós e elos. Os nós são os objetos e os elos são responsáveis por fazer a ligação entre os
nós.

Todo objeto deve ter o seu comportamento determinado. Para isto, a sua declaração,
deve definir o que se quer tocar, como, quando e onde.

• O que tocar: quando iniciamos a construção de um programa audiovisual interativo a


primeira coisa que consideramos é o seu conteúdo, ou seja, quais vídeos, áudios,
imagens, textos e outros tipos de mídias ou programas serão apresentados.

• Onde tocar: com o conteúdo definido, podemos associar uma mídia a uma região.
Esta associação é feita através de um descritor. Para isso, devemos indicar as posições

39
e as dimensões dos nós num local específico através de elementos denominados
regiões.

• Como tocar: os descritores também são utilizados para definir a forma como a mídia
deverá ser apresentada. Por exemplo, podemos definir para um áudio o seu volume;
para uma imagem o seu grau de transparência.

• Quando tocar: define o momento em que um nó será apresentado em relação aos


outros. Esta relação é feita através dos elos, que são utilizados para estabelecer o
sincronismo entre os nós e para definir a interação do programa.

4.2. APLICAÇÕES NO AMBIENTE GINGA-J

4.2.1. O ciclo de vida da Xlet

A idéia básica de uma Xlet é funcionar como uma máquina de estados em cima da
máquina virtual que a está executando. As Xlets implementam a interface Javax.tv.xlet.Xlet
que provê um ciclo de vida para a aplicação através da implementação de seus métodos. Cada
método da interface provê uma transição a um estado da aplicação [MONTEZ, 2005].

As aplicações Xlet podem se encontrar nos estados representados pela máquina de


estados ilustrada na Figura 9. Quando a classe Java inicial de uma aplicação é carregada ela
entra no estado Carregada. O estado Carregada significa que a aplicação já foi carregada mas
ainda não foi iniciada. No momento seguinte o Gerenciador de Aplicações sinaliza a Xlet para
que ele seja iniciado (chamando seu método “initXlet”). Após iniciado ele entra no estado
Pausada. Uma aplicação neste estado está minimizando o uso de recursos para maximizar sua
sobrevivência, e está pronta para executar. No estado Em Execução a aplicação está
funcionando plenamente, e no estado Destruída já liberou todos os recursos e terminou sua
execução.

40
Figura 9 - Estados de um Xlet

Segue abaixo uma breve descrição dos métodos da interface Javax.tv.xlet.Xlet que
devem ser implementados para a construção de um Xlet [SUN, 2000].

• initXlet: É neste método que as variáveis e as instâncias de objeto são


inicializados. Nele o parâmetro contexto do método é passado para a Xlet onde
fica gravado caso seja requisitado no futuro. Este método é chamado somente
uma vez no ciclo de vida da Xlet.

• startXlet: Método chamado para fazer a aplicação executar sua função


principal, este método deve implementar todos procedimentos necessários para
que a aplicação entre no estado de execução.

• pauseXlet: Neste método a aplicação deve parar de prover seus serviços e


entrar no estado de espera.

• destroyXlet: Neste método devem ser implementados todos os procedimentos


necessários para que a Xlet termine sua execução de forma correta. Geralmente
é usado para remover componentes gráficos da tela, liberar recursos com E/S
de dados ou salvar dados pertinentes.

Toda Xlet deve possuir um contexto que de uma maneira geral serve para isolar a
aplicação do resto da máquina virtual. Um objeto XletContext é passado a uma Xlet quando
ele é inicializado. É através desta interface que o Gerenciador de Aplicações controla o estado
de um Xlet. Entre outras, o contexto permite a Xlet descobrir informações a respeito do
ambiente de execução. [MONTEZ et al, 2005]

41
A interface XletContext define os seguintes métodos [SUN, 2000]:

• notifyDestroyed: Este método sinaliza ao Gerenciador de Aplicações que a


Xlet entrou no estado Destruída após a Xlet ter completado sua execução e
estar pronto para ser destruído.

• notifyPaused: Este método sinaliza ao Gerenciador de Aplicações que a Xlet


entrou no estado Pausada. Deve-se entrar neste estado quando a Xlet não for
prover um serviço por um curto período de tempo

• getXletProperty: Este método possibilita a Xlet obter informações sobre o


ambiente de execução

• resumeRequest: Este método sinaliza ao Gerenciador de Aplicações que a


Xlet deseja entrar no estado Em Execução

4.2.2. Ambiente Gráfico

Para a TV Digital, um modelo de display de imagem em camadas é usado para o


desenvolvimento de aplicações e encontrado na maioria dos ambientes de desenvolvimento de
aplicações multimídia (Figura 10).

Figura 10 - Modelo de display de imagem em camadas

42
Este modelo é o que melhor cumpre com as exigências do ambiente de
desenvolvimento de aplicações para TV interativa. São definidos três camadas conceituais de
imagem: a camada de imagem de fundo de tela (background), a camada de vídeo e a camada
gráfica que exibe ao usuário a interface da aplicação. As camadas são sobrepostas para
produzir a imagem vista pelo usuário final.

No pacote HAVi que define componentes para a interface gráfica, o componente


principal que representa um dispositivo físico de exibição é o HScreen. Todo HScreen
possui objetos HScreenDevice. Estes objetos representam as camadas de exibição.
Tipicamente, todo HScreen terá uma das seguintes subclasses do HScreenDevice
[KLIMCUK, 2008].

• HBackgroundDevice: representa a camada de background

• HVideoDevice: representa a camada de vídeo

• HGraphicsDevice: representa a camada gráfica

Quando se trabalha em aplicações desenvolvidas em Java da forma tradicional,


geralmente é criado um container principal como o java.awt.Frame. Para API HAVi, um
componente equivalente ao Frame, é a HScene, que serve como um container principal
disposto em uma determinada área da tela. Nele componentes gráficos podem ser inseridos e
exibidos. Em Xlets é permitido o uso dos tradicionais componentes AWT, como
java.awt.Container ou java.awt.Componet, porém, HAVi disponibiliza uma versão mais
adaptada deste componentes para serem usados em ambientes de Xlets, que são,
org.havi.ui.Hcontainer e org.havi.ui.Hcomponent.

43
5. ESTUDO DE CASO

O estudo das funcionalidades e teste do middleware Ginga será feito através da


implementação de um estudo de caso. A proposta do trabalho considera a implementação de
um sistema de recomendação de programação de televisão baseado no tempo gasto pelo
telespectador assistindo um determinado canal. Este capítulo mostrará uma introdução aos
sistemas de recomendação mostrando seus conceitos e em seguida será descrito o
funcionamento da aplicação AutoCanal.

5.1. SISTEMAS DE RECOMENDAÇÃO

Com o surgimento da televisão digital e da internet, a quantidade de informações e a


facilidade de acesso do uso das mesmas aumentaram, fazendo com que as pessoas se
deparassem com uma diversidade muito grande de opções. Essa sobrecarga de informações
muitas vezes deixa o usuário com dificuldades em obter informações sobre os seus programas
favoritos.

Para minimizar as duvidas e necessidades que temos frente à escolha entre alternativas
surgem então os sistemas de recomendação que tem o objetivo de recomendar itens a um
usuário através de uma filtragem de informações relevantes baseadas no seu perfil de interesse
[ELISEO & SILVIO].

O processo de coleta desse perfil se dá de maneira implícita e explicita. No processo


de coleta explicita o perfil é construído diretamente pelo usuário, este indica espontaneamente
o que lhe é importante. Na modalidade implícita o sistema gera o perfil enquanto o mesmo
opera o sistema, através de ações do usuário infere-se informações sobre suas necessidades e
preferências [ELISEO & SILVIO].

A filtragem de informações citada anteriormente é uma tarefa comum em ambientes


onde o fluxo de informação é grande. Filtragem de informação é o nome utilizado para
escrever uma variedade de processos que envolvem a entrega de informação para as pessoas

44
que realmente necessitam delas. São aplicadas duas técnicas de filtragem nos sistemas de
recomendação: filtragem baseada em conteúdo e filtragem colaborativa [ELISEO & SILVIO].

Na filtragem baseada em conteúdo apenas as preferências do próprio usuário são


utilizadas na filtragem. Esta técnica tem como objetivo aprender sobre as características da
descrição dos itens de informação relevantes e não relevantes para um usuário, para que possa
fazer um julgamento da relevância de novos itens de acordo com as preferências desse usuário
Na filtragem colaborativa há uma formação de uma comunidade de usuários que interagem
com o sistema fornecendo avaliações. Os sistemas colaborativos se baseiam na similaridade
entre os usuários que são membros da comunidade. A idéia básica é fornecer recomendação
de documentos a um usuário de acordo com a opinião de outros usuários de preferências
similares [IVAN, 2002].

5.2. APLICAÇÃO AUTOCANAL

A aplicação AutoCanal consiste num único Xlet que implementa a interface


Javax.tv.xlet.Xlet da API JavaTV e que possui objetos da API HAVi instanciados
para implementar a interface gráfica.

Com o objetivo de auxiliar possíveis programadores, foi criado um tutorial de


desenvolvimento de aplicações utilizando a API JavaTV que pode ser visto no apêndice A.

As características da Aplicação AutoCanal segundo, as dimensões definidas


anteriormente estão refletidas na ilustração da figura 11. O nível de interatividade, o
desenvolvedor e o ambiente utilizados estão em destaque.

Já as opções de desenvolvimento da aplicação AutoCanal, segundo o diagrama


ilustrado anteriormente estão refletidas na figura 12. Nele os nós utilizados (cada nó
representa uma das opções de desenvolvimento) estão destacados na coloração vermelha.

Na aplicação AutoCanal (Figura 13) o processo de recomendação foi simplificado. Na


recomendação da informação (canal) ao usuário a filtragem é obtida através de um histórico
de preferências do próprio usuário e não de comparações feitas por um conjunto de usuários.

45
Ambiente

Ginga-NCL

Ginga-J

Níveis de
Emissora Interatividade

Usuário Int. Remota Int. Local

Desenvolvedor

Figura 11 – Localização Espacial da aplicação AutoCanal

Figura 12 - Diagrama das opções de desenvolvimento de aplicação AutoCanal

46
Segundo a comunidade de IA Sistemas de Recomendação são sistemas de informação
que coletam indicadores da preferência dos usuários e utilizam técnicas de Filtragem de
Informação (FI) para fornecer uma visão personalizada da informação. Na aplicação
AutoCanal foi apenas considerada informações do próprio usuario para realizar a
recomendação.

Esta aplicação possibilita ao usuário assistir três canais diferentes (de forma simulada),
os quais podem ser trocados pelo controle remoto através dos botões 1, 2 e 3. A medida que o
usuário vai assistindo os canais a aplicação guarda informações (canal e hora) para
posteriormente sugerir uma programação ao usuário de acordo com o seu histórico. Nesta
aplicação é simulado tanto a transmissão dos canais como o tempo.

No método iniciarControleCustomizado() é implementado um loop


infinito que contem uma thread sleep, com uma pausa de 1 segundo (simulando 1 hora).
A cada loop é registrado o canal que o usuário está assistindo através da classe
AutoProgramacao, como também é verificado se o usuário está assistindo o canal favorito da
hora seguinte. Caso o canal atual seja diferente do canal favorito, será exibida uma mensagem
informando que breve haverá uma mudança automática de canal e caso seja desejado cancelar
esta mudança a tecla vermelha deve ser pressionada.

Figura 13 - Interface da aplicação AutoCanal

47
6. CONCLUSÃO

Após realizar um levantamento sobre os padrões utilizados e as novas formas de


utilização da TV digital, ficou fácil constatar que essa nova tecnologia trará inúmeras
melhorias. Além de benefícios como imagem e som de alta definição, a possibilidade de
assistir a programação através de dispositivos móveis e a televisão poder realizar atividades
computacionais (armazenar e processar informações) vistas antes em dispositivos como
computadores pessoais. A TV digital traz, como principal contribuição, a interatividade,
proporcionando ao usuário a capacidade de enviar informações, o que o faz deixar de ser um
mero telespectador quando este era apenas um receptor de informações.

A TV Digital no Brasil ainda encontra-se em estagio inicial, diferente de outros países


onde já existem padrões definidos há alguns anos. Entretanto, este atraso pode ser encarado de
uma forma positiva, pois possibilitou a construção de um sistema mais maduro (o SBTVD se
baseou no padrão japonês). Isso possibilitou a utilização de tecnologias mais modernas, como
por exemplo, a compactação de vídeo H.264.

Além do levantamento realizado sobre o SBTVD e seu middleware Ginga foi criado
um guia para o desenvolvimento de aplicativos para TV digital. Através da leitura deste guia
um desenvolvedor terá conhecimento de quais são os ambientes de desenvolvimento
disponíveis e quais são os passos que devem ser seguidos a fim de construir um aplicativo
suportado pelo middleware brasileiro.

No estudo de caso, inicialmente, pretendia-se implementar um sistema de


recomendação baseado em conteúdo no qual uma programação seria sugerida ao usuário com
base num histórico de informações filtradas a partir dos programas assistidos anteriormente
(ex.: atores, gênero, horário etc). Entretanto, foi criado um sistema de recomendação
simplificado.devido a algumas restrições. Entre estas restrições podemos citar o fato das
especificações do Ginga-J não terem sido lançadas até o presente momento e o fato do
Xletview (emulador de aplicações Java para TV digital) não oferece suporte a algumas
bibliotecas necessárias.

Por fim, este trabalho vem servir de referência para que outros alunos e profissionais
interessados neste tema possam compreender melhor o funcionamento do SBTVD e assim
nortear no desenvolvimento de aplicativos para TV digital.
48
REFERÊNCIAS BIBLIOGRÁFICAS

[ABNT 00:001.85-006/4] Projeto de Norma ABNT 00:001.85-006/4 - Televisão digital


terrestre - Codificação de dados e especificações de transmissão para transmissão digital
– Parte 4: Ginga-J - Ambiente para a execução de aplicações procedurais.

[ANATEL, 2004] ANATEL, Agência Nacional de Telecomunicações. TV Digital. Brasília,


2004.

[ATSC, 2008] Advanced Television Systems Committee. Disponível em www.atsc.org e


acessado em junho de 2008.

[BAHAI, 2004] Bahai, S; Saltzberg, R; Ergen, M. Multi Carrier Digital Communications:


Theory and Applications of OFDM, Springer, 2004.

[BARBOSA & SOARES, 2008] BARBOSA, Simone; SOARES, Luiz. TV Digital no Brasil
se faz com Ginga: Fundamentos, Padrões, Autoria Declarativa e Usabilidade. Rio de Janeiro,
RJ: Editora PUC-Rio, 2008.

[CRUZ, 2008] CRUZ, Vitor Medina; MORENO, Marcio Ferreira; SOARES, Luis Fernando
Gomes. TV Digital para Dispositivos Portáteis – Middlewares. PUC-RIO. Janeiro 2008.

[DASE, 2008] Standard A/100 - DTV Application Software Environment – Level 1 (DASE-
1). Disponível em www.atsc.org e acessado em junho de 2008.

[DAVIC, 1999] DAVIC 1.4.1 Specification Part 9: Information Representation.

[DiBEG, 2008] Digital Broadcasting Experts Group. Disponível em www.dibeg.org e


acessado em junho de 2008.

[DVB, 2008] Digital Video Broadcasting Project. Disponível em www.dvb.org e acessado em


junho de 2008.

[ECMA, 2008]. Standard ECMA-262 ECMAScript. Language Specification. 3rd edition


Disponível em http://www.ecma-international.org/publications/standards/Ecma-262.htm e
acessado em julho de 2008

[ELISEO & SILVIO, 2005] Sistemas de Recomendação. XXV Congresso da Sociedade


Brasileira de Computação. Unisinos - São Leopoldo/RS, julho de 2005.

49
[FERNANDEZ, 2004] FERNANDEZ, J.; LEMOS, Guido.; SILVEIRA, G. Introdução à
Televisão Digital Interativa: Arquitetura, Protocolos, Padrões e Práticas. In JAI-SBC.
Salvador, 2004.

[FUNTEL, 2006] Fundo para o Desenvolvimento Tecnológico das Telecomunicações.


Arquitetura de Referencia: Sistema Brasileiro de Televisão Digital Terrestre, 10 de
Fevereiro de 2006

[GUIMARÃES, 2007] GUIMARÃES , Rodrigo. Composer: um ambiente de autoria de


documentos NCL para TV digital interativa. Dissertação de Mestrado. PUC Rio de Janeiro,
2007.

[HAVi, 2001]. HAVi v1.1 - Home Audio Video Interoperability Version 1.1. Disponível em
www.havi.org e acessado em junho de 2008.

[IERUSALIMSCHY, 2007] IERUSALIMSCHY, Roberto; FIQUEREIDO, Luiz; CELES,


Waldemar. Manual de Referência de Lua 5.1. PUC-Rio, 2008.

[ISO, 1996a]. ISO/IEC 13818-1 - Information Technology – Generic Coding of Moving


Pictures and Associated Audio Information – Part 1: Systems (MPEG-2 Systems), 1996.

[ISO, 1996b]. ISO/IEC 13818-2 - Information Technology – Generic Coding of Moving


Pictures and Associated Audio Information – Part 2: Video (MPEG-2 Video), 1996.

[ISO, 1997]. ISO/IEC 13818-7 - Information Technology – Generic Coding of Moving


Pictures and Associated Audio Information: Advanced Audio Coding, 1997.

[IVAN, 2002] Ivan Romero Teixeira. Um Método de Aprendizagem Ativa em Sistemas de


Filtragem Colaborativa. Universidade Federal de Pernambuco. Recife, 2002

[KLIMCUK, 2008] KLIMCUK, Tomás. Development environment for development of


graphical user interface of iDTV. Master thesis. Faculty of Electrial Engineering. Prague,
2008.

[KOOGAN & HOUAISS, 1999] KOOGAN, HOUAISS. Enciclopédia e dicionário


ilustrado. 4.ed. Rio de Janeiro. Seifer, 1999.

[LEMOS, 2007] LEMOS, Guido; LEITE, Luiz; BATISTA, Carlos. Ginga-J: The
Procedural Middleware for the Brazilian Digital TV System. JCBS. no. 1; Vol. 13; Mar.
2007

50
[LOPES, 2007] LOPES, Denise. Sistema Brasileiro de TV Digital: Caminhos percorridos e
implantação. V Congresso Nacional de História da Mídia. São Paulo, 2007.

[MANUEL, 2007] MANUEL, Edson. Codificação de vídeo H.264 – Estudo de codificação


mista de macroblocos. Dissetação de Mestrado. Universidade Federal de Santa Catarina.
Florianópolis, 2007.

[MENDES, 2007] MENDES, Luciano Leonel. Artigo: SBTVD – Uma Visão sobre a TV
Digital No Brasil. T&C Amazônia Ano V, Numero 12, Outubro de 2007.

[MONTEZ & BECKER, 2005] MONTEZ, Carlos; BECKER, Valdecir. TV Digital


Interativa: conceitos, desafios e perspectivas para o Brasil. 2ª Ed. Florianópolis: Editora da
UFSC, 2005.

[MONTEZ, 2005] MONTEZ, Carlos; BECKER, Valdecir; FILHO, Günter H. Herweg.


Datacasting e Desenvolvimento de Serviços e Aplicações para TV Digital Interativa.
2005.

[MORENO, 2006] MORENO, Márcio Ferreira. Um Middleware Declarativo para Sistemas


de TV Digital Interativa. Dissertação de Mestrado. abr. 2006. Rio de Janeiro: PUC-Rio.

[RICHARDSON, 2003] Richardson, Iain. H.264 and MPEG-4 Video Compression Video
Coding for Next-generation Multimedia. John Wiley & Sons Ltd, The Atrium, Southern
Gate, Chichester, 2003.

[RODRIGUES & GOMES, 2004] RODRIGUES, Ana; GOMES, Regina. Modulação


COFDM – Uma proposta atrativa para os padrões de TV Digital. Revista Digital Online. Vol
3. Agosto de 2004

[SILVA, 2003] SILVA, Jones Q. TV Digital Interativa. Monografia. Universidade do Vale


do Rio dos Sinos. São Leopoldo, 2003.

[SOARES, 2007] SOARES, Luiz; RODRIGUES, Rogério; MORENO, Márcio. Ginga-NCL:


the Declarative Environment of the Brazilian Digital TV System. JCBS. no. 1; Vol. 13;
Mar. 2007.

[SOFTWARE PUBLICO, 2008] Disponível na internet em


http://www.softwarepublico.gov.br/dotlrn/clubs/ginga/one-community?page_num=3 e
acessado em 01/08/2008.

51
[SOUZA, 2004] SOUZA, Vinicius Barros. Set Top Box para TV Interativa. Monografia.
Universidade Federal Fluminense. Niteroi, 2004.

[SPARANO, 2000] Sparano, D. What Exactly is 8-VSB Anyway?. The Guide to Digital
Television, 3ª ed. Silbergleid & Pescatre org, Miller Freeman Inc, March 2000.

[STEUER, 1992] STEUER, J. Defining Virtual Reality: Dimensions Determining


Telepresence. Journal of Communication, v. 42, n. 4, 1992.

[SUN, 2000] Java TV 1.0 - Java TV API Technical Overview: The Java TV API White
Paper. Version 1.0, Sun Microsystems. November 2000.

[TELEMÍDIA, 2008]. Laboratório de Telemídia. Ambiente para Desenvolvimento de


Aplicações Declarativas para a TV Digital. Laboratório Telemídia. Departamento de
Informática. PUC-RIO. Disponível na Internet em
http://www.ncl.org.br/documentos/MDIC2007.pdf e acessado em 10/07/2008

[TONIETO, 2006] TONIETO, Márcia. Sistema Brasileiro de TV Digital - SBTVD - Uma


análise política e tecnológica na inclusão social. Fortaleza, 2006. Dissertação de Mestrado –
Centro de Ciências e Tecnologia, Universidade Estadual do Ceará.

52
APÊNDICE A – TUTORIAL DE DESENVOLVIMENTO DE UM APLICATIVO EM
JAVATV

Este apêndice apresenta um guia de desenvolvimento de um aplicativo para TV


Digital utilizando a API JavaTV. Informando as ferramentas utilizadas e o que precisa ser
configurado antes de iniciar o desenvolvimento. Faz uma breve descrição das API’s
utilizadas, explica o ciclo de vida de uma Xlet, demonstra com exemplos práticos como
construir uma Xlet e por fim ensina a executá-la utilizando o Xletview.

1. FERRAMENTAS UTILIZADAS

1.1. Java (IDE + JDK)

Java Development Kit (JDK) significa Kit de Desenvolvimento Java, e é um conjunto


de utilitários que permitem criar sistemas de software para a plataforma Java. É composto por
compilador e bibliotecas.

IDE, do inglês Integrated Development Environment ou Ambiente


Integrado de Desenvolvimento, é um programa de computador que reúne características e
ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este
processo.

Para o desenvolvimento de aplicações Java é bastante recomendável o uso de uma


IDE. As duas mais famosas são Eclipse e Netbeans.

Os exemplos dados para a elaboração deste guia serão baseados na IDE Eclipse.

1.2. Xletview

O XletView, ver interface na Figura 1, é uma ferramenta que emula Xlets para TV
Digital em um computador. Possui código aberto (Open Source), recursos multimídias

53
implementados para utilização dos componentes HAVi, é baseado no padrão MHP e fornece
uma maneira fácil e rápida de testar as aplicações.

Como é programado totalmente em Java, pode ser executado tanto em uma plataforma
Linux ou Windows, bastando para isso utilizar o Java 2 Standard Development Kit para
compilar Xlets e executar o XleTView. A versão utilizada deste emulador foi a 0.3.6 em
conjunto com o JMF 2.1.1. O Xletview possui muita limitações, não dá suporte a todas as
funcionalidades oferecidas pela API JavaTV, como também é bastante limitada para
reproduzir a maioria das codificações de vídeo.

Figura 1 – Interface do Xletview

Dica: é recomendado executar o Xletview através da linha de comando “java -jar


xletview.jar”, pois desta forma é possível ver no terminal o resultado de comandos como
“System.out.println()” e mensagens de erro.

54
2. CONFIGURANDO O AMBIENTE DE DESENVOLVIMENTO

A fim de fornecer acesso às bibliotecas necessárias para a construção de aplicativos


em JavaTV devemos informar o caminho onde estas se encontram, ou seja, devemos importar
o arquivo “javatv.jar” referente a biblioteca da API JavaTV. Para que a aplicação possa
referenciar as bibliotecas do MHP, HAVi, DAVIC e JMF é necessário importar o arquivo
“xletview.jar”.

Para realizar esta operação, no Eclipse, após ter um projeto criado, vá a propriedades,
escolha a opção “Java Build Path”, na aba “Libraries” clique em “Add External JARs” e
adicione as bibliotecas “javatv.jar” e “xletview.jar”.

3. IMPLEMENTANDO UMA XLET

A partir deste ponto podemos dar início a implementação de uma Xlet. No Exemplo
01 temos um código que serve de estrutura base para a implementação de um simples Xlet.

Temos em seguida exemplos que mostram os códigos utilizados para a inserção de


texto, botão, imagem, som, vídeo e eventos em um Xlet, estes códigos devem ser utilizados
em conjunto com o Exemplo 01.

/**
* Esta é uma implementação simples de um Xlet.
* Serve de esqueleto para a construção de aplicações
* mais elaboradas. Pois toda Xlet deve ter esta estrutura.
*/

//Outros pacotes Java podem ser referenciados


import java.awt.Color ;
import java.awt.Font ;

//Referenciando a API JavaTV


import javax.tv.xlet.*;

//Referenciando a API HAVI


import org.havi.ui.HstaticText;

/**
* Este Xlet implementa a interface Javax.tv.xlet.Xlet
* e todos os métodos são herdados desta interface.
*/
public class SimplesXlet implements Xlet {

55
private XletContext context;

public SimplesXlet() {
/**
* Toda Xletdeve ter um construtor padrão onde nada
* deve ser feito. Qualquer inicialização deve ser
* feita no método initXlet() ou em startXlet(). Desta
* forma o middleware pode controlar a inicialização
* de uma forma mais previsível. *
*/
}

public void initXlet(XletContext context) throws


XletStateChangeException {
/**
* Inicializa o Xlet. É neste método que o contexto da
* xlet deve ser passado para futuras referências.
* É o lugar onde as inicializações devem ser feitas,
* a não ser que tenha um custo computacional muito alto.
* O controle de exeção XletStateChangeException deve ser
* referenciado para o caso de ocorre um erro na inicialização.
*/
this.context = context;
}

public void startXlet() throws XletStateChangeException {


/**
* Ativa o Xlet. Neste ponto a Xletpode ser mostrado
* na tela e começar a interação com o usuário ou realizar
* outra tarefa. Este tipo de tarefa não deve ser feita
* no initXlet().
*
* Como em iniXlet o controle de exeção
XletStateChangeException
* deve ser referenciado para o caso de ocorre um erro
* ao ativar o Xlet.
*/
}

public void pauseXlet() {


/**
* Pausa o Xlet. Aqui a Xletdeve liberar recursos
* para que não sejam usados de forma desnecessária
* e deve ser removido da tela.
*/
}

public void destroyXlet(boolean unconditional) throws


XletStateChangeException {
/**
* Destroi o Xlet. O parâmetro booleano diz ao método
* se a Xletdeve obedecer esta requisição. Se o valor
* for verdadeiro a Xletdeve ser terminado. Caso
* contrário, a Xletpode informar que não foi destruído
* lançando XletStateChangeException
*/
}
}
Exemplo 01 – Estrutura básica de um Xlet

56
3.1. Inserindo Texto

Para inserir um texto você deve:

a) Importar bibliotecas

import javax.tv.xlet.Xlet;
import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;
import org.havi.ui.HScene;
import org.havi.ui.HState;
import org.havi.ui.HStaticText;
import java.awt.Color;
import java.awt.Font;

b) Criar os objetos e variáveis

private HScene scene;


private HStaticText texto;;

c) Definir os parâmetros dos objetos

texto = new HStaticText();


texto.setBounds(600,510,70,50);
texto.setFont(new Font("Tiresias",Font.BOLD,60));
texto.setForeground(Color.YELLOW);
texto.setBackground(new Color(200,200,200,100));
texto.setTextContent("Meu Texto!", HState.ALL_STATES);

d) Adicionar o objeto a cena

scene.add(texto);

3.2. Inserindo Botão

Para inserir um botão você deve:

a) Importar bibliotecas

import javax.tv.xlet.Xlet;
import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;
import org.havi.ui.HDefaultTextLayoutManager;
import org.havi.ui.HScene;
import org.havi.ui.HTextButton;
import java.awt.Color;
import java.awt.Font;
import java.awt.event.KeyListener;

57
b) Implementar a classe KeyListener

public class SimplesXlet implements Xlet, KeyListener

c) Criar os objetos e variáveis

private HScene scene;


private HTextButton botao1;
private HTextButton botao2;
private HDefaultTextLayoutManager manager;

d) Definir os parâmetros dos objetos

botao1 = new HTextButton();


botao1.setTextContent("Botao 1", 1);
botao1.setLocation(400, 200);
botao1.setSize(100, 50);
botao1.setForeground(Color.blue);
botao1.setBackground(Color.red);
botao1.setFont(new Font("Tiresias",Font.BOLD,20));
botao1.setTextLayoutManager(manager);
botao1.setFocusTraversal(botao2, botao2,botao2,botao2);
//Objetos que pedirem foco da aplicação precisam necessariamente
receber o KeyListener.
botao1.addKeyListener(this);
botao1.requestFocus();

botao2 = new HTextButton();


botao2.setTextContent("Botao 1", 1);
botao2.setLocation(400, 200);
botao2.setSize(100, 50);
botao2.setForeground(Color.blue);
botao2.setBackground(Color.red);
botao2.setFont(new Font("Tiresias",Font.BOLD,20));
botao2.setTextLayoutManager(manager);
botao2.setFocusTraversal(botao1, botao1, botao1, botao1);
botao2.addKeyListener(this);

e) Adicionar o objeto a cena

scene.add(botao1);
scene.add(botao2);

3.3. Inserindo Imagem

Para inserir uma imagem você deve:

a) Importar bibliotecas

import javax.swing.ImageIcon;
import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;
import org.havi.ui.HContainer;
import org.havi.ui.HIcon;

58
import java.awt.Image;

b) Criar os objetos ou variáveis

private HContainer container = new HContainer();


private Image imagem;
private HIcon icone = null;

c) Definir os parâmetros dos objetos

imagem = new ImageIcon("c:/imagens/imagem.gif").getImage();


icone = new HIcon(imagem);
icone.setSize(100,50);
icone.setLocation(300,150);
icone.setVisible(true);

d) Adicionar o objeto a cena

container.add(icone);

3.4. Inserindo Som

Para inserir som você deve:

a) Importar bibliotecas

import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;
import org.havi.ui.HContainer;
import org.havi.ui.HSound;

b) Criar os objetos ou variáveis

private HSound som = new HSound();


private String SOM_URL;

c) Definir os parâmetros dos objetos

SOM_URL = "file://c://sons//som.mp3";
try{
som.load(SOM_URL);
}
catch (Exception e) {
e.printStackTrace();
}
som.play();

3.5. Inserindo Vídeo

59
Para inserir vídeo você deve:

a) Importar bibliotecas

import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;
import org.havi.ui.HContainer;
import org.havi.ui.HScene;
import javax.media.ControllerListener;
import javax.media.Manager;
import javax.media.MediaException;
import javax.media.MediaLocator;
import javax.media.Player;
import java.awt.Component;
import java.io.IOException;

b) Criar os objetos ou variáveis


private HScene scene;
private HContainer contVideo;
private String VIDEO_URL = "";
private Player player;
private MediaLocator mediaLocator;
private Component componente;

c) Definir os parâmetros dos objetos

VIDEO_URL = "file://C://Videos//video.avi";

try {
mediaLocator = new MediaLocator(VIDEO_URL);
player = Manager.createRealizedPlayer(mediaLocator);
player.addControllerListener((ControllerListener) this);
}
catch (IOException e) {
e.printStackTrace();
}
catch (MediaException e) {
e.printStackTrace();
}

contVideo = new HContainer(0,0,720,515);


contVideo.setVisible(true);

d) Adicionar o objeto a cena

scene.add(contVideo);
scene.repaint();

3.6. Inserindo Eventos

Para inserir eventos você deve:

60
a) Importar bibliotecas

import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import javax.tv.xlet.Xlet;

b) Implementar a classe KeyListener

public class SimplesXlet implements Xlet, KeyListener

//Veja no arquivo "remote_control.xml" o nome dos KeyEvent de cada


botão

public void keyPressed(KeyEvent evento)


{
switch(evento.getKeyCode()){
case KeyEvent.VK_UP: {
//Executar ação para o botão seta pra cima
break;
}
default: {
break;
}
}
}

public void keyReleased(KeyEvent arg0) {}

public void keyTyped(KeyEvent arg0) {}

4. EXECUTANDO UM XLET

Após a implementação do Xlet, objetivando a sua execução, devemos compilá-lo, ou


seja, gerar o arquivo “.class”. Para isso clique em “Build Project” que se encontra dentro do
menu “Project” da barra de menus do Eclipse. Em seguida, com o arquivo compilado vá ao
Xletview e realize o seguinte procedimento:

i. No menu “Applications”, selecione “Manage applications”

ii. Na janela que se abre, escolha “New Application”

iii. Informe o nome da sua aplicação, o caminho onde se encontra o arquivo “.class” e
o arquivo “.class” propriamente dito. Salve e feche a janela.

Para executar a Xlet, basta abrir o menu "Applications" e clique no nome que foi dado.

61
APÊNDICE B - CÓDIGO DE IMPLEMENTAÇÃO DA APLICAÇÃO AUTOCANAL

A CLASSE PRINCIPAL - AUTOCANALXLET

/**
* @author João Paulo Lacerda - jplacerda@gmail.com
* Antônio Carlos Albuquerque - antonioc.albuquerque@gmail.com
*
* A Xlet AutoCanalXlet possibilita ao usuário assistir três canais
* (de modo simulado) diferentes que podem ser trocados no controle
* remoto nos botões 1, 2 e 3.
* A medida que o usuário vai assistindo os canais a aplicação vai
* guardando informações para posteriormente sugerir a programação
* ao usuário de acordo com o seu histórico.
*/

//Importando a AWT
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Component;
import java.awt.Font;
import java.awt.Graphics;
import java.awt.Rectangle;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;

//Importando a API JMF


import javax.media.ControllerEvent;
import javax.media.ControllerListener;

//Importando a API JavaTV


import javax.tv.xlet.Xlet;
import javax.tv.xlet.XletContext;
import javax.tv.xlet.XletStateChangeException;

//Importando a HAVi
import org.havi.ui.HContainer;
import org.havi.ui.HDefaultTextLayoutManager;
import org.havi.ui.HScene;
import org.havi.ui.HSceneFactory;
import org.havi.ui.HScreen;
import org.havi.ui.HState;
import org.havi.ui.HStaticText;
import org.havi.ui.HTextButton;
import org.havi.ui.HTextLayoutManager;
import org.havi.ui.event.HRcEvent;

/**
* Esta Xlet implementa a interface Javax.tv.xlet.Xlet e
* a java.awt.event.KeyListener.
*/
public class AutoCanalXlet implements Xlet, KeyListener {

private XletContext context;


private HScene scene;
private HContainer container = new HContainer();

62
private HStaticText nr_canal;
private HStaticText hora_text;
private HStaticText mudarCanal;
private VideoPlayer canal_01 = new VideoPlayer(1);
private VideoPlayer canal_02 = new VideoPlayer(2);
private VideoPlayer canal_03 = new VideoPlayer(3);
private Component videoComp_01, videoComp_02, videoComp_03;
private AutoProgramacao autoProgramacao = new AutoProgramacao();
private int canal = -1;
private boolean cancelar = true;
private boolean continuar = true;

/**
* Toda Xletdeve ter um construtor padrão onde nada deve ser feito.
* Qualquer inicialização deve ser feita no método initXlet() ou
* em startXlet(). Desta forma o middleware pode controlar a
* inicialização de uma forma mais previsível.
*/
public AutoCanalXlet() {}

/**
* Inicializa o Xlet. É neste método que o contexto da Xletdeve
* ser passado para futuras referências. É o lugar onde as
* inicializações devem ser feitas a não ser que tenha um custo
* computacional muito alto.
* O controle de exeção XletStateChangeException deve ser
* referenciado para o caso de ocorre um erro na inicialização.
*/
public void initXlet(XletContext context) throws
XletStateChangeException {
System.out.println("initXlet");
this.context = context;
scene = HSceneFactory.getInstance().getFullScreenScene(

HScreen.getDefaultHScreen().getDefaultHGraphicsDevice());
if (scene == null)
throw new XletStateChangeException("Impossivel criar
HScene");
}

/**
* Ativa o Xlet. Neste ponto a Xlet pode ser mostrado na tela e
* começar a interação com o usuário ou realizar outra tarefa.
* Este tipo de tarefa não deve ser feita no initXlet().
*
* Como em iniXlet o controle de exeção XletStateChangeException deve
* ser referenciado para o caso de ocorre um erro ao ativar o Xlet.
*/
public void startXlet() throws XletStateChangeException {
System.out.println("startXlet");

videoComp_01 = canal_01.getPlayer().getVisualComponent();
videoComp_02 = canal_02.getPlayer().getVisualComponent();
videoComp_03 = canal_03.getPlayer().getVisualComponent();

videoComp_01.setBounds(0,0,720,500);
videoComp_02.setBounds(0,0,720,500);
videoComp_03.setBounds(0,0,720,500);

nr_canal = new HStaticText();

63
nr_canal.setBounds(20,510,40,50);
nr_canal.setFont(new Font("Tiresias",Font.BOLD,60));
nr_canal.setForeground(Color.YELLOW);
nr_canal.setBackground(new Color(200,200,200,100));

hora_text = new HStaticText();


hora_text.setBounds(580,510,130,50);
hora_text.setFont(new Font("Tiresias",Font.BOLD,50));
hora_text.setForeground(Color.YELLOW);
hora_text.setBackground(new Color(200,200,200,100));

mudarCanal = new HStaticText();


mudarCanal.setBounds(80,510,480,50);
mudarCanal.setFont(new Font("Tiresias",Font.BOLD,25));
mudarCanal.setForeground(Color.red);
mudarCanal.setBackground(new Color(200,200,200,100));
mudarCanal.setVisible(false);

container.setVisible(true);
container.add(nr_canal);
container.add(hora_text);
container.add(mudarCanal);
container.setBounds(scene.getBounds());

scene.add(container);
scene.addKeyListener(this);
scene.setVisible(true);
scene.requestFocus();

iniciarControleCustomizado();
}

/**
* Pausa o Xlet. Aqui a Xletdeve liberar recursos para que não
* sejam usados de forma desnecessária e deve ser removido da tela.
*/
public void pauseXlet() {
System.out.println("pauseXlet");
}

/**
* Destroi o Xlet. O parâmetro booleano diz ao método se o Xlet
* deve obedecer esta requisição. Se o valor for verdadeiro o Xlet
* deve ser terminado. Caso contrário, a Xletpode informar que não
* foi destruido lançando XletStateChangeException
*/
public void destroyXlet(boolean arg0) throws XletStateChangeException
{
System.out.println("destroyXlet");
if (scene != null) {
scene.setVisible(false);
scene.removeAll();
scene.dispose();
scene = null;
}
canal_01.close();
canal_02.close();
canal_03.close();
continuar = false;
context.notifyDestroyed();
}

64
/**
* No método iniciarControleCustomizado() é implementado um loop
* infinito que contem o método sleep, com uma pausa de 1 segundo
* (simula 1 hora), com o objetivo de emular o tempo.
* A cada loop é registrado o canal que o usuário está assistindo
* através da classe AutoProgramacao, como também é verificado se
* o usuário está assistinto o canal favorito da hora seguinte.
* Caso o canal atual seja diferente do canal favorito, será exibida
* uma mensagem informando que breve haverá uma mudança automática
* de canal e que caso deseje cancelar esta mudança a tecla vermelha
* deve ser pressionada.
*/
public void iniciarControleCustomizado()
{
String hora_minuto = null;
int canal_preferido = -1;
while (continuar) {
for (int hora = 0; hora < 24; hora++ ) {
if ( canal > 0 ) {
autoProgramacao.pontuarCanal(canal, hora);
canal_preferido =
autoProgramacao.getCanal(canal, hora+1);
if ( canal != canal_preferido ) {
mudarCanal.setVisible(true);
System.out.println("canal: " + canal + "
DIFERENTE DE canal_preferido: " + canal_preferido);
mudarCanal.setTextContent("Mudança
prevista para o Canal: " + canal_preferido + " às " +
Integer.toString(hora) + ":00 \n Aperte o botão vermelho para cancelar." ,
HState.ALL_STATES);
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
mudarCanal.setVisible(false);
if ( cancelar )
setCanal(canal_preferido);
cancelar = true;
}
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//Atualiza a hora
hora_text.setTextContent(Integer.toString(hora) +
":00", HState.ALL_STATES);
}
}
}

/**
* Este método muda o canal (o vídeo que está sendo exibido) de
* acordo com o valor passado no parâmetro.
* @param canal
*/
public void setCanal(int canal) {
this.canal = canal;

65
System.out.println("setCanal: " + canal);
//Atualiza o canal
nr_canal.setTextContent(Integer.toString(canal),
HState.ALL_STATES);
canal_01.pause();
canal_02.pause();
canal_03.pause();
container.remove(videoComp_01);
container.remove(videoComp_02);
container.remove(videoComp_03);
if (canal == 1) {
container.add(videoComp_01);
canal_01.start();
}
if (canal == 2) {
container.add(videoComp_02);
canal_02.start();
}
if (canal == 3) {
container.add(videoComp_03);
canal_03.start();
}
}

/**
* Este método responde aos eventos do controle remoto. Caso o botão
* 1, 2 ou 3 seja pressionado será chamado o método setCanal().
*/
public void keyPressed(KeyEvent e) {
System.out.println("keyPressed: " + e.getKeyChar());

if(e.getKeyChar() == HRcEvent.VK_1) setCanal(1);

if(e.getKeyChar() == HRcEvent.VK_2) setCanal(2);

if(e.getKeyChar() == HRcEvent.VK_3) setCanal(3);

if(e.getKeyChar() == HRcEvent.VK_COLORED_KEY_0) cancelar =


false;

if(e.getKeyChar() == HRcEvent.VK_ESCAPE){
try {
destroyXlet(true);
} catch (XletStateChangeException e1) {
e1.printStackTrace();
}
}
}

public void keyReleased(KeyEvent arg0) {}

public void keyTyped(KeyEvent arg0) {}


}

A CLASSE AUTOPROGRAMACAO

66
/**
* @author João Paulo Lacerda - jplacerda@gmail.com
* Antônio Carlos Albuquerque -
antonioc.albuquerque@gmail.com
*
* Esta classe implementa a inteligência artificial da aplicação.
* Nela é criada uma matriz de 3 por 24. O 3 representa o número de canais
* e o 24 o intervalo de tempo, neste caso é o número de horas .
* Todos os valores da matriz iniciam com valor 0 e podem ser incrementados
* de acordo com o canal que o usuário assiste em determinada hora. Criando
* assim um sistema de pontuação que possibilita a aplicação saber qual
* o canal favorito do usuário em uma determinada hora.
*/

public class AutoProgramacao {

private int[][] tempo_canal = new int[24][3];

//O construtor atribui o valor 0 a todos elementos da martiz


public AutoProgramacao()
{
for(int t = 0; t < 24; t++){
for(int c = 0; c < 3; c++){
tempo_canal[t][c] = 0;
}
}
}

//Incrementa em 1 o valor do campo da matriz correspondente


public void pontuarCanal(int canal, int tempo) {
tempo_canal[tempo][canal-1]++;
System.out.println("pontuarCanal => canal: " + canal + "
pontos: " + tempo_canal[tempo][canal-1]);
}

/**
* Retorna o canal preferido, o canal de maior pontuação, em uma
* determinada hora.
* @param canal - é o canal que está sendo assistido
* @param hora - é a hora que se deseja obter o canal favorito.
*/
public int getCanal(int canal, int hora)
{
if ( hora == 24 ) hora = 0;

int pontos = tempo_canal[hora][canal-1];


int cnl = canal-1;

for ( int c = 0; c < 3; c++ ){


if ( tempo_canal[hora][c] > pontos ) {
pontos = tempo_canal[hora][c];
cnl = c;
}
}
return cnl + 1;
}
}

67
A CLASSE VIDEOPLAYER

/**
* Classe VideoPlayer
* Esta classe instancia o player para
* exibir os vídeos que simulam os canais.
*/

import java.awt.Component;
import java.awt.event.KeyAdapter;
import java.awt.event.KeyEvent;
import java.io.IOException;
import javax.media.*;
import javax.media.protocol.*;
import javax.tv.xlet.*;
import org.havi.ui.*;
import org.havi.ui.event.HRcEvent;

public class VideoPlayer implements ControllerListener {

private String VIDEO_URL = "";


private Player player;
private MediaLocator mediaLocator;

public Player getPlayer() {


return player;
}

//Cria o player de acordo com o número do canal passado


public VideoPlayer(int canal)
{
System.out.println("createVideo: canal " + canal);

if ( canal == 1)
VIDEO_URL = "file://D://Videos//New_Drawing.avi";
else if ( canal == 2)
VIDEO_URL = "file://D://Videos//New_Drawing.avi";
else if ( canal == 3)
VIDEO_URL = "file://D://Videos//Sample.mov";
else
System.out.println("Nenhum canal foi criado");

try {
mediaLocator = new MediaLocator(VIDEO_URL);
player = Manager.createRealizedPlayer(mediaLocator);
player.addControllerListener(this);
}
catch (IOException e) {
e.printStackTrace();
}
catch (MediaException e) {
e.printStackTrace();
}
}

68
//Verifica se o player está instanciado, caso esteja a exibição
//do vídeo será iniciada novamente quando chegar no seu fim
public void controllerUpdate(ControllerEvent ctEvent) {
if(player == null){
return;
}
else if (ctEvent instanceof EndOfMediaEvent) {
player.setMediaTime(new Time(0));
player.start();
}
}

public Component getVisualComponent() {


if (player != null)
return player.getVisualComponent();
else
return null;
}

//Inicia o vídeo
public void start() {
System.out.println("start");
if(player != null)
player.start();
}

//Pausa o vídeo
public void pause() {
System.out.println("pause");
if(player != null)
player.stop();
}

//Fecha e desaloca o vídeo


public void close(){
System.out.println("close");
if(player != null) {
player.close();
player = null;
}
}
}

69