ANTNIO CARLOS ALBUQUERQUE DE OLIVEIRA JOO PAULO LOPES DE LACERDA

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAES INTERATIVAS PARA O MIDDLEWARE GINGA

ARACAJU 2008

UNIVERSIDADE FEDERAL DE SERGIPE DEPARTAMENTO DE COMPUTAO CINCIA DA COMPUTAO

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAES INTERATIVAS PARA O MIDDLEWARE GINGA

ANTNIO CARLOS ALBUQUERQUE DE OLIVEIRA JOO PAULO LOPES DE LACERDA

ARACAJU 2008

UNIVERSIDADE FEDERAL DE SERGIPE DEPARTAMENTO DE COMPUTAO CINCIA DA COMPUTAO

A TV DIGITAL NO BRASIL E O DESENVOLVIMENTO DE APLICAES INTERATIVAS PARA O MIDDLEWARE GINGA

Trabalho de Concluso de Cursos apresentado por Antnio Carlos Albuquerque de Oliveira e Joo Paulo Lopes de Lacerda como requisito para obteno de grau em bacharel em Cincia da Computao na Universidade Federal de Sergipe

Orientador: Prof. Dr. Hendrik Teixeira Macedo

ARACAJU 2008

RESUMO

A televiso um dos maiores meios de comunicao do mundo, como tambm uma grande fonte de informao, entretenimento e cultura. Com a chegada da TV Digital alm dos benefcios trazidos com a imagem e o som de alta definio, o usurio deixar de ser um mero espectador e passar a interagir com a programao, podendo tambm usufruir de uma variedade de servios computacionais atravs da TV. Em 2006, o governo brasileiro criou o SBTVD (Sistema Brasileiro de Televiso Digital), baseado no padro Japons. Como o padro brasileiro chegou depois dos internacionais, este pde inovar utilizando tecnologias mais recentes. Alm disto, o SBTVD tambm inovou no seu Middleware, o Ginga, que possibilita a execuo de aplicaes interativas atravs do ambiente de apresentao GingaNCL e do ambiente de execuo Ginga-J. Este trabalho traz um estudo sobre o SBTVD e seu Middleware, um guia de desenvolvimento para aplicaes na TV digital e por fim um estudo de caso com a implementao de uma aplicao demonstrando parte do potencial desse novo veiculo.

Palavras-chave: televiso digital interativa, SBTVD, middleware de TV

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

SUMRIO

1. INTRODUO ....................................................................................................................8 2. SISTEMA DE TELEVISO DIGITAL INTERATIVA ................................................10 2.1. TRANSMISSO 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 aplicao ..............................................................................................13 2.4.2. Middleware.............................................................................................................14 2.4.3. Camada de Codificao e Decodificao ...............................................................15 2.4.4. Camada de Transporte ............................................................................................15 2.4.5. Camada de Transmisso e Recepo......................................................................16 2.5. PADRES MUNDIAIS DE TV DIGITAL INTERATIVA ..........................................16 2.5.1. ATSC - Padro Americano.....................................................................................16 2.5.2. DVB - Padro Europeu...........................................................................................18 2.5.3. ISDB - Padro Japons ...........................................................................................18 2.6. SURGIMENTO DA TV DIGITAL NO BRASIL..........................................................19 2.7. PADRO BRASILEIRO DE TV DIGITAL .................................................................20 2.7.1. Middleware.............................................................................................................20 2.7.2. Camada de Codificao e Decodificao ...............................................................21 2.7.3. Camada de Transporte ............................................................................................22 2.7.4. Camada de Transmisso e Recepo......................................................................22 3. O GINGA E SUA ARQUITETURA.................................................................................24 3.1. O AMBIENTE GINGA-NCL ........................................................................................25 3.1.1. Lua ..........................................................................................................................27 3.1.2. Edio 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. INOVAES DO GINGA ............................................................................................34 4. GUIA DE DESENVOLVIMENTO DE UM APLICATIVO PARA TV DIGITAL.....36 4.1. APLICAES NO AMBIENTE GINGA-NCL............................................................39 4.2. APLICAES NO AMBIENTE GINGA-J ..................................................................40 4.2.1. O ciclo de vida da Xlet ...........................................................................................40 4.2.2. Ambiente Grfico ...................................................................................................42 5. ESTUDO DE CASO ...........................................................................................................44 5.1. SISTEMAS DE RECOMENDAO ...........................................................................44 5.2. APLICAO AUTOCANAL.......................................................................................45 6. CONCLUSO.....................................................................................................................48 REFERNCIAS BIBLIOGRFICAS .................................................................................49 APNDICE A TUTORIAL DE DESENVOLVIMENTO DE UM APLICATIVO EM JAVATV ..................................................................................................................................53 APNDICE B - CDIGO DE IMPLEMENTAO DA APLICAO AUTOCANAL ..................................................................................................................................................62

iv

LISTA DE FIGURAS

Figura 1 - Componentes da TV Digital ....................................................................................12 Figura 2 - Arquitetura em camadas dos padres para TVDI....................................................17 Figura 3 - Arquitetura em camadas do SBTVD .......................................................................21 Figura 4 - Arquitetura do Ginga ...............................................................................................25 Figura 5 - Representao das APIs do Ginga-J.......................................................................29 Figura 6 - Dimenses de desenvolvimento de aplicativos para TV digital ..............................36 Figura 7 - Diagrama com as opes de desenvolvimento ........................................................38 Figura 8 Display exibindo vrias Xlets .................................................................................39 Figura 9 - Estados de um Xlet ..................................................................................................41 Figura 10 - Modelo de display de imagem em camadas ..........................................................42 Figura 11 Localizao Espacial da aplicao AutoCanal......................................................46 Figura 12 - Diagrama das opes de desenvolvimento de aplicao AutoCanal.....................46 Figura 13 - Interface da aplicao AutoCanal ..........................................................................47

LISTA DE ABREVIATURAS

AAC - Advanced Audio Coding ABERT - Associao Brasileira de Emissoras de Rdio e Televiso 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 Televiso 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 televiso Digital SDTV - Sistema de Televiso Digital SECAM - Squentiel Couleur Avec Memoire STB - Set Top Box TS - Transport Strems TVD - TV Digital VCEG - Video Coding Experts Group XML - Extensible Markup Language

vii

1. INTRODUO

A televiso hoje um dos maiores meios de comunicao do mundo, proporcionando para o telespectador fonte de informao, entretenimento e cultura. Seguindo a tendncia mundial do movimento de digitalizao como nos diversos meios de comunicao, a televiso est passando por um processo de substituio de suas plataformas analgicas por plataformas e tecnologias digitais. Esta mudana est provocando uma onda de impacto em todo o mundo como tambm no Brasil. Com a tecnologia de TV Digital, h um ganho considervel em termos de resoluo da imagem (alta definio) e qualidade de som alm de possibilitar a transmisso de vrios programas em um nico canal. Entretanto, a principal caracterstica da TV Digital a capacidade de permitir interatividade entre o usurio telespectador e a emissora de programao. Atividades como acessar menu de programao da emissora, realizar compras de produtos (t-commerce), acessar contas bancrias, participar de enquetes, votar, escolher um melhor ngulo de viso em transmisses de eventos esportivos, rever filmes e programas, selecionar msicas para escutar, enviar e receber e-mails, jogar, etc., passam a fazer parte do conjunto de recursos interativos possveis. O desenvolvimento de todas essas aplicaes s possvel graas a uma camada de software intermedirio presente na arquitetura dos padres dos sistemas de televiso digital chamada de middleware. O middleware tem como finalidade oferecer um servio padronizado para as aplicaes, escondendo as peculiaridades e heterogeneidades das camadas inferiores (tecnologias de compresso, de transporte e de modulao) viabilizando assim o desenvolvimento das aplicaes de forma independente do hardware dos fabricantes dos terminais de acesso ao sinal digital (set top boxes). Atualmente existem trs padres mundiais de televiso digital: na Europa, o DVB (Digital Vdeo Broadcast) [DVB, 2008], nos Estados Unidos o ATSC (Advanced Television System Committee) [ATSC, 2008] e no Japo o ISBD (Integrated Service Digital Broadcasting)[DiBEG, 2008], cada um utilizando um

middleware especifico. O Brasil adotou como base o padro japons dando origem assim ao SBTVD (Sistema Brasileiro de Televiso Digital). O SBTVD possui como middleware, o Ginga, que permite o desenvolvimento de aplicaes digitais interativas tanto na linguagem declarativa NCL (Nested Context Language) quanto de forma no-declarativa na linguagem Java atravs de dois subsistemas lgicos denominados, respectivamente, de Ginga-NCL e Ginga-J. Nesse contexto, o trabalho tem o objetivo de documentar os aspectos relativos ao sistema brasileiro de televiso digital e da plataforma Ginga. Outro objetivo disseminar a cultura de pesquisa e desenvolvimento dessas aplicaes no Departamento de Computao da Universidade Federal de Sergipe. Para isto ser proposto um estudo de caso de um Sistema de Recomendao 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 Televiso Digital, mostrando alguns conceitos sobre televiso digital, em seguida ser apresentado os padres utilizados mundialmente e por fim mostrar como surgiu o SBTVD e sua arquitetura utilizada. No captulo trs ser mostrado o padro de middleware Ginga adotado com enfoque ao estudo das API (Application Programming

Interface) para o desenvolvimento das aplicaes. O capitulo quatro mostrar um guia de como desenvolver aplicaes interativas para TV Digital e o captulo cinco mostrar um estudo de caso de um sistema de recomendao com base nesse guia. Por fim as concluses so apresentadas no captulo seis.

2. SISTEMA DE TELEVISO DIGITAL INTERATIVA

A TV Digital interativa uma fuso da TV tradicional com tecnologias de computao, de forma que o telespectador possa dispor de sinal de alta qualidade, bem como interagir com a aplicao, interferindo diretamente na programao que est recebendo. Este captulo abordar alguns conceitos sobre a televiso digital e os seus componentes. Sero vistos os padres mundiais de televiso digital, incluindo o padro brasileiro juntamente com a descrio das camadas de sua arquitetura.

2.1. TRANSMISSO NA TV DIGITAL

Para compreender como funciona o sistema digital de televiso necessrio entender o funcionamento do atual sistema analgico utilizado nas transmisses. Em um sistema de televiso analgica preto e branco a imagem formada por variaes 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 televiso analgica a cores o procedimento semelhante, porm alm de processar o sinal referente ao nvel de preto (sinal de luminncia) ainda capta outro sinal referente cor (sinal de crominncia) [SILVA, 2003]. Na transmisso digital, cada nvel de intensidade de preto transformado em cdigo binrio, zeros (0) e uns (1), a mesma utilizada em computadores. Como na televiso digital existem vrios tipos de cores e tonalidades, h um conjunto de bits para representar todas estas variaes [SILVA, 2003]. Estes recursos trazem uma transmisso de melhor qualidade. Antes, para chegar at os receptores dentro de suas casas, parte do sinal poderia sofrer interferncias ou parte dele poderia ser refletido por diversos obstculos provocando rudos, chuviscos e sobreposio de imagens. O sistema digital transmitido de forma binria (zero ou um), proporcionando um sinal de alta qualidade de som e imagem. Na recepo do sinal digital ou o sinal chega com 10

perfeio ou no chega, caso haja interferncia o sinal no ser exibido. Estas transmisses so feitas via area, com o uso de satlite, ou terrestre, por ondas ou cabos [SILVA, 2003]. No sistema digital alm de melhorar a qualidade, tanto pela representao precisa da informao como pela eliminao de rudos, tem-se ainda a possibilidade de armazenamento, processamento e a possibilidade de uma maior compresso das informaes, apresentando assim qualidades de portabilidade, mobilidade e interatividade [SILVA, 2003].

2.2. O CONCEITO DE INTERATIVIDADE

Segundo STEUER [1992], interatividade mede o quanto um usurio pode influenciar na modificao imediata, na forma e no contedo de um ambiente computacional. O termo conceituado como uma varivel baseada no tempo de resposta do estmulo. Portanto, livros, jornais e TV aberta so caracterizados como meios pouco interativos; ao contrrio de teleconferncia, e-mail e videogame. A interatividade a troca entre o usurio e um sistema computacional por meio de um terminal dotado de tela de visualizao [KOOGAN & HOUAISS, 1999]. Desta forma, o usurio pode interagir alterando a forma e o contedo do ambiente mediado em tempo real. O sistema de televiso brasileiro que conhecemos hoje meramente reativo, pois os telespectadores apenas reagem aos estmulos oferecidos pela emissora. Na TV verdadeiramente interativa, o telespectador se comunica com a emissora atravs de um canal de interatividade (canal de retorno). Na TV digital, interatividade se traduz na possibilidade do usurio influenciar na forma e no contedo do que est assistindo, poder se comunicar e realizar intervenes atravs dos servios e aplicaes disponveis. Entretanto, alguns autores mais puristas dizem que estas formas de interatividade ainda so meramente reativas, ou seja, reagem s opes determinadas pelo emissor. Sugerindo a criao de mais alguns nveis de interatividade para que ela se torne pr-ativa, possibilitando ao usurio enviar vdeos s emissoras e, desta forma, passar a contribuir com o contedo 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 televiso digital temos que partir de um modelo genrico (Figura 1). Esse modelo composto de trs partes: (1) um transmissor ou difusor que responsvel por prover servios de entretenimento e interao para os usurios; (2) um canal de difuso que responsvel pela entrega correta dos dados e (3) um receptor que recebe o contedo televisivo e possibilita ainda a interao com o transmissor [SOUZA, 2004].

Figura 1 - Componentes da TV Digital

O contedo televisivo que pode ser fluxos de udio, vdeo ou dados so transmitidos por milhares de estaes e recebidos por aparelhos digitais de televiso ou pelos STB (Set Top Box). Esse aparelho responsvel por fazer a converso do sinal digitalizado para TV analgica alm de possuir um canal de retorno para fornecer a interatividade entre o emissor e telespectador. Ele constitudo por componentes de software (sistema operacional e ambiente que executa os programas interativos) e hardware especfico [FERNANDEZ, 2004]. O canal de retorno (canal de interao) quem possibilita a comunicao entre o receptor e o difusor. De acordo com a existncia ou no do canal de retorno, foram classificados nveis de interatividade que podem ser divididos em: Interatividade local: no utiliza o canal de retorno. Podem ser realizadas interaes como: configurao de legendas, jogos residentes e acesso ao guia de programao eletrnica.

12

Interatividade remota: utiliza o canal de retorno. Podem ser realizadas interaes como: comrcio eletrnico, acesso a contas bancrias, servios de sade e aplicaes para educao distncia. o Unidirecional: permite ao receptor apenas o envio de dados (upload). Por exemplo: a compra de um determinado produto, votaes e pesquisas de opinio. o Bidirecional: alem de enviar dados, permite ao receptor fazer o carregamento de dados (download) utilizados pelos aplicativos. Por exemplo: navegao na internet, e-mail, chat, jogos on-line e a comunicao entre os usurios.

2.4. ARQUITETURA DO SISTEMA DE TV DIGITAL INTERATIVA

Um sistema de televiso digital interativa pode adotar e integrar um conjunto de diferentes tecnologias de hardware e software para implementar suas funcionalidades. Considerando essa diversidade de solues, diversos rgos de padronizao concentraram esforos na especificao de padres [FERNANDEZ, 2004]. A arquitetura de um sistema de televiso digital interativa dividido em 5 camadas, so elas: (1) aplicao; (2) middleware; (3) codificao; (4) transporte; (5) transmisso. A idia central da arquitetura em camadas cada uma oferecer servios para a camada superior e usar os servios oferecidos pela inferior. A seguir, estas camadas tero as suas funcionalidades descritas.

2.4.1. Camada de aplicao

a camada responsvel pela captura e formatao dos sinais de udio e vdeo, bem como a execuo dos aplicativos multimdias desenvolvidos. Desta forma segue uma lista de possveis aplicaes com uma breve descrio.

EPG (Eletronic Porgram Guide): programa de guia para contedos digitais. Com ele, o telespectador pode navegar pelo conjunto de programaes e servios 13

oferecidos e escolher o que mais lhe agradar. Ele pode selecionar um canal convencional ou resolver comprar um vdeo pr-armazenado para assistir.

T-GOVERN: so servios governamentais via TV. Oferece servios importantes, evitando o deslocamento a cartrios ou postos de informao, 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: aplicao muito importante e que ajudar bastante no processo de incluso digital.

Vdeo sob demanda: o consumidor tem acesso a um acervo de vdeos que podem ser escolhidos e apresentados sob sua demanda, na hora em que lhe for mais conveniente.

Console de Jogos: possibilita o uso da televiso para jogos, permitindo que os adversrios estejam em rede ou que a prpria televiso seja o adversrio.

2.4.2. Middleware

O middleware utilizado para mover informaes entre programas ocultando do programador diferenas de protocolos de comunicao, plataformas e dependncias do sistema operacional. geralmente constitudo por mdulos dotados com APIs de alto nvel que proporcionam a sua integrao com aplicaes desenvolvidas em diversas linguagens de programao e interfaces de baixo nvel que permitem a sua independncia relativamente ao dispositivo. O uso do middleware facilita a portabilidade das aplicaes, 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 Codificao e Decodificao

Camada responsvel pela remoo de redundncias nos sinais de udio e vdeo, reduzindo assim a taxa de bits necessria para transmitir essas informaes [MENDES, 2007]. A compresso de udio e vdeo permite reduzir a quantidade de dados (taxa de bits) necessria para representar vdeos digitais, diminuindo os custos de transmisso e armazenamento dos mesmos. Compreende o modulo codificador e decodificador de udio/vdeo [MANUEL, 2007]. O codificador recebe como entrada o sinal de udio/vdeo digital no comprimido, disponibilizado pelo emissor, realiza a compresso e gera como sada um fluxo elementar de udio/vdeo 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 decodificao e disponibiliza em sua sada o sinal de udio/vdeo reconstrudo [FUNTEL, 2006]. Esta camada permite a transmisso em diferentes resolues e taxas de compresso. Dentre eles esto o HDTV/1080i (1920 colunas por 1080 linhas entrelaadas) e o HDTV/720p (1280 colunas por 720 linhas progressivas) para imagens de alta definio; o SDTV/480p (720 colunas por 480 linhas progressivas) para definio padro; e o LDTV/OneSeg (320 colunas por 240 linhas) para dispositivos mveis.

2.4.4. Camada de Transporte

A camada de transporte que faz a multiplexao e demultiplexao dos fluxos elementares de udio, vdeo e dados. A idia da multiplexao agrupar udio, vdeo e dados em um nico fluxo a serem transmitidos e demultiplex-los quando este fluxo chegar no receptor.

15

2.4.5. Camada de Transmisso e Recepo

Tambm denominada de camada fsica essa camada responsvel por levar as informaes digitais do estdio da emissora at a casa dos telespectadores. Contudo, as informaes no podem ser enviadas diretamente pelo sistema de comunicao sem antes sofrer uma modulao no envio, e uma demodulao na recepo [MENDES, 2007]. A modulao necessria devido s caractersticas dos enlaces, que enfrentam problemas de atenuao por perda de energia do sinal transmitido, rudos e distores de atraso. Esses problemas so relacionados com a freqncia do sinal usada no sistema de comunicao. O processo de modulao resolve este problema alterando alguma caracterstica de uma onda portadora de acordo com o sinal da informao a ser transmitido [MONTEZ & BECKER, 2005].

2.5. PADRES MUNDIAIS DE TV DIGITAL INTERATIVA

Atualmente, existem trs padres mundiais de sistema de televiso digital interativa reconhecidos, sendo estes: o europeu DVB, o americano ATSC; e o japons ISDB. Estes sistemas adotam diferentes padres para modulao do sinal de difuso; transporte de fluxos elementares de udio, vdeo, dados e aplicaes; codificao e qualidade de udio e vdeo; e servios de middleware. Logo abaixo, temos a Figura 2, que representa uma viso arquitetural em camadas das opes de padres para um sistema de televiso digital interativa. Em seguida, nos tpicos seguintes, esto descritos os padres mundiais de TV Digital, identificando os componentes bsicos adotados por eles.

2.5.1. ATSC - Padro Americano

o padro norte-americano de sistema de televiso digital, especificado pelo comit ATSC. Em funcionamento nos Estados Unidos desde novembro de 1998 esse padro utiliza a 16

modulao 8-VSB [SPARANO, 2000]. Define dois modelos tcnicos de transmisso: via cabo (ATSC-C) e via rdio-difuso (ATSC-T), sendo o modelo de transmisso a cabo o mais difundido. A multiplexao e codificao de vdeo so feitas sobre o padro MPEG-2, j a codificao de udio realizada atravs do padro Dolby AC-3 [ATSC, 2001].

Figura 2 - Arquitetura em camadas dos padres para TVDI

Entre os pontos positivos deste padro est caracterstica 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 padres conseguem ter acesso as informaes e programaes do padro ATSC [SILVA, 2003]. Esse padro privilegia a transmisso de alta qualidade (HDTV), contudo no d suporte transmisso de televiso digital para terminais mveis, sendo um dos seus grandes pontos negativos [ANATEL, 2004].

17

2.5.2. DVB - Padro Europeu

O padro DVB adotado na Europa no incio da dcada de 90 est presente na Unio Europia, Austrlia e Nova Zelndia. O DVB pode ser usado para sistemas de alta definio (HDTV High Definition Television) e sistemas mveis de baixa definio (LDTV Low Definition Television). No entanto, alguns estudos apontam que o funcionamento no satisfatrio quando ocorrem transmisses simultneas para sistemas de alta definio e sistemas mveis [FERNANDEZ, 2004]. Os principais padres de transmisso adotados pelo DVB so: DVB-T: (transmisso terrestre por radiodifuso); DVB-C (transmisso via cabo); DVB-S (transmisso via satlite); DVB-MC (transmisso via microondas operando em freqncias de at 10GHz); e DVB-MS (transmisso via microondas operando em freqncias acima de 10GHz) [FERNANDEZ, 2004]. Na camada de codificao, o sinal de udio codificado usando a recomendao MPEG2-BC e o sinal de vdeo codificado usando a recomendao MPEG-2 Vdeo [ISO, 1996b]. Na camada de transporte usado o padro MPEG-2 Sistemas [ISO, 1996a]. Para este padro foi desenvolvido um middleware prprio: o MHP (Multimedia Home Plataform). Seu ambiente de execuo baseado no uso de uma mquina virtual Java e um conjunto de APIs.

2.5.3. ISDB - Padro Japons

Criado em 1999 por vrias empresas e operadoras de televiso, o ISDB o padro de transmisso terrestre japons, sendo adotado somente por aquele pas. Existem trs formas de transmisso do ISDB, o ISDB-S (transmisso via satlite), o ISDB-T (transmisso terrestre por radiodifuso) e o ISDB-C (transmisso via cabo) e todos os trs dispem do mesmo processamento digital [SILVA, 2003]. O ISDB utiliza a modulao COFDM (Coded Orthogonal Frequency

Division Multiplex) [BAHAI, 2004]. A multiplexao e a codificao de vdeo, como

18

nos dois padres anteriores, tambm so realizadas em MPEG-2, j a codificao de udio utiliza o MPEG-2 ACC [ISO, 1997]. O middleware do ISDB se chama ARIB, nome adotado da organizao responsvel por criar a sua padronizao, a ARIB (Association of Radio Industries and Businesses). o mais novo dentre os trs principais padres e seu grande diferencial o suporte a mltiplos nveis de transmisso, podendo ser usado, por exemplo, para prover simultaneamente recepo de baixa taxa de dados sob condies mveis excepcionalmente difceis, taxa de dados intermediria (SDTV) para recepo esttica e alta taxa de dados (HDTV) para boas condies de recepo [FERNANDEZ, 2004].

2.6. SURGIMENTO DA TV DIGITAL NO BRASIL

No final da dcada de 80, Estados Unidos, Europa e Japo j se encontravam adiantados em relao aos estudos de TV de alta definio. Diante do progresso desses pases, o Brasil decidiu tambm concentrar esforos no estudo tecnolgico da televiso. Em 1991, o governo brasileiro, atravs do Ministrio das Comunicaes, estabeleceu a Comisso Assessora para Assuntos de Televiso (Com-TV) encarregada de estudar e analisar a TV de alta definio que estava sendo desenvolvida em alguns pases. Os estudos evoluram de tal modo que culminaram nos sistemas de TV digital [LOPES, 2007]. Ento, em 1994, a Associao Brasileira de Emissoras de Rdio e Televiso (Abert) e a Sociedade Brasileira de Engenharia de Televiso e Telecomunicaes (Set) uniram-se formando o Grupo Tcnico Abert/Set de TVD. A misso desse grupo acompanhar o desenvolvimento da TVD no mundo com o objetivo de colaborar no processo de definio do padro 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 comeou a ser realizados testes com o padro japons. Em 2003 intensificaram-se as discusses sobre TVD. Somente em 26 de novembro de 2006, aps inmeros debates sobre qual padro deveria ser adotado ou se deveria ser desenvolvido um padro nacional que o Brasil assinou um decreto de lei n 4.901. Instituindo o padro 19

japons como modelo a ser implantado no pas. Porm, com algumas inovaes, principalmente, na camada de middleware e de codificao. Embora, no Brasil, exista discrdia entre alguns rgos (governo, emissoras, pesquisadores, entre outros) sobre qual padro deveria ser adotado, o governo brasileiro tomou sua deciso, por considerar o padro japons o que melhor atendia as necessidades do pas. Como por exemplo: a dispensa de pagamento de royalties; o comprometimento do governo japons em colaborar, na medida do possvel, com o desenvolvimento de uma indstria eletroeletrnica nacional; a transmisso de contedo a dispositivos mveis e portteis. Segundo Agencia de Noticias do Planalto, o cronograma de implantao prev que at dezembro de 2013 o novo sistema digital j estar funcionando em todo territrio brasileiro e que modelo analgico ter suas transmisses encerradas em julho de 2016 [LOPES, 2007].

2.7. PADRO BRASILEIRO DE TV DIGITAL

Como apresentado anteriormente, o SBTVD e sua arquitetura (Figura 3) foi baseado no padro japons, tendo suas principais mudanas na camada de codificao e de middleware. No Brasil utilizada a tcnica de compresso de vdeo mais recente e mais eficiente chamada de H.264 [RICHARDSON, 2003], diferentemente dos outros padres mundiais que utilizam a tcnica MPEG-2 e na camada de middleware o Brasil desenvolveu e adotou o Ginga. A seguir ser descrito os padres 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 aplicaes, as declarativas e as procedurais, chamadas respectivamente de Ginga-NCL [SOARES, 2007] e o Ginga-J [LEMOS, 2007]. O captulo seguinte dedicado a um estudo mais detalhado sobre este middleware. 20

Figura 3 - Arquitetura em camadas do SBTVD

2.7.2. Camada de Codificao e Decodificao

Para compresso de vdeo, o sistema brasileiro inovou ao definir o padro H.264, tambm conhecido como MPEG-4 Part 10 ou AVC (Advanced Video Coding), no lugar do padro 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 vdeos por um mesmo canal usado pelo MPEG-2. O padro 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 verso final, formalmente chamada por ISO/IEC 1449610), foi lanada em Maio de 2003 [MANUEL, 2007]. Este padro permite formatos de transmisso com diferentes resolues e taxas de compresso. Dentre eles esto o HDTV/1080i e o HDTV/720p para imagens de alta definio; o SDTV/480p para definio padro; e o LDTV/OneSeg para dispositivos mveis.

21

Para compresso de udio foi adotado o MPEG-4 AAC (Advanced Audio Coding), tambm conhecido como MPEG-2 Part 7 ou MPEG-4 Part 3. Este formato uma evoluo da Camada-3 do MPEG-1 udio (tambm denominada MP3). O AAC consegue taxa de compresso bem superior que seu antecessor. Uma das caractersticas desse sistema a propriedade de anlise da redundncia da informao entre vrios fluxos. Permite tambm 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 padro MPEG-2 System. Este padro adiciona aos fluxos elementares de udio principal e vdeo principal informaes para suas exibies sincronizadas. A sincronizao realizada seguindo o paradigma de eixo do tempo (timeline) pela adio de carimbos de tempo (timestamp) a conjuntos de amostras codificadas de vdeo e udio baseado em um relgio compartilhado. A gerao de fluxos de dados tambm so determinadas pelo padro [BARBOSA & SOARES, 2008]. No receptor, essa seqncia de pacotes ser demultiplexada e as seqncias elementares de bits sero reconstrudas e entregues aos seus respectivos decodificadores. Utilizando informaes contidas no cabealho dos pacotes de transporte, possvel a realizao de operaes como sincronizao do aparelho receptor, deteco e sinalizao de erros [FERNANDEZ, 2004].

2.7.4. Camada de Transmisso e Recepo

O padro utilizado pelo sistema brasileiro na camada de transmisso o COFDM modulando em QAM (Quadrature Amplitude Modulation) ou PSK (Phase Shift Keying) [RODRIGUES & GOMES, 2004]. O COFDM uma tcnica de modulao baseada no OFDM (Orthogonal Frequency Division Multiplex) o qual utiliza subportadoras ortogonais para

22

modular os sinais, diferindo no acrscimo da codificao, de onde se acrescenta o C ao OFDM [RODRIGUES & GOMES, 2004]. O acrscimo da codificao de canal tem como objetivo corrigir os erros produzidos na transmisso. Embora sua complexidade seja elevada, COFDM possui melhor desempenho sob canais em condies realmente desafiadoras [RODRIGUES & GOMES, 2004].

23

3. O GINGA E SUA ARQUITETURA

Ginga a camada de software intermedirio (middleware) que permite o desenvolvimento de aplicaes interativas para a TV Digital de forma independente da plataforma de hardware dos fabricantes de terminais de acesso (set top boxes). Sendo compatvel com as definies internacionais ITU, o Ginga foi desenvolvido com o objetivo de levar em considerao as ltimas inovaes tecnolgicas e as necessidades de incluso digital no pas, objetivos estes que no seriam alcanados caso fosse adotado qualquer um dos middlewares j existentes. O Ginga define uma API padro, que todo exibidor acoplado ao sistema deve obedecer, para reportar seus eventos e serem comandados por aes geradas pelo formatador. Exibidores de terceiros fabricantes, incluindo a os browsers HTML, usualmente necessitam de um mdulo adaptador para realizar essas funes e se integrarem ao Ginga [TELEMDIA, 2008]. Por ser mais recente, o sistema brasileiro de TV digital teve por obrigao procurar as alternativas tecnolgicas atuais. Entre elas estava concepo de um middleware no qual a convivncia dos ambientes declarativo e procedural fosse a mais eficiente possvel em termos de custo e desempenho. O Ginga d suporte a aplicaes para TV digital e tem como foco: o sincronismo de mdia na sua forma mais ampla, tendo a interatividade do usurio como caso particular; a adaptabilidade do contedo a ser apresentado; e o suporte a mltiplos dispositivos de interao e exibio [TELEMDIA, 2008]. A arquitetura da implementao de referncia do middleware Ginga (Figura 4) pode ser dividida em trs mdulos: o Ginga-CC (Common Core), o ambiente de apresentao Ginga-NCL (declarativo) e o ambiente de execuo Ginga-J (procedural). O Ginga-CC (Ginga-Common Core ou Ginga-Ncleo Comum) oferece o suporte necessrio aos ambientes declarativo e procedural, e tem como funes principais a exibio

24

dos vrios objetos de mdia, o controle do plano grfico, 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 apresentao para aplicaes declarativas escritas na linguagem NCL (Nested Context Language). NCL uma aplicao XML (eXtensible Markup Language) com facilidades para a especificao de aspectos de interatividade, sincronismo espao-temporal entre objetos de mdia, adaptabilidade, suporte a mltiplos dispositivos e suporte produo ao vivo de programas interativos no-lineares. Por ser uma aplicao XML, a linguagem NCL possui uma separao estrita entre contedo e estrutura, NCL no define qualquer mdia por ela mesma. Ao invs, ela a cola que mantm a mdia junta com uma apresentao multimdia. Porm, um documento NCL somente define como os objetos de mdia so estruturados e relacionados, no tempo e no
1

Como a sintonizao de um canal especfico de TV pode ser realizada em qualquer instante, o Carrossel DSM-CC envia ciclicamente dados que no tenham relao temporal por meio de carimbos de tempo. O recebimento desses dados independente do instante de sintonizao.

25

espao. Como uma linguagem de cola, ela no restringe ou prescreve o contedo do tipo de objeto de mdia [SOARES, 2007]. Objetos de vdeo (MPEG etc.), udio (AAC etc.), imagem (JPEG, GIF etc.) e texto (TXT, HTML etc.) so exemplos de objetos de mdia. Entre esses objetos ressaltam-se os objetos de vdeo e udio que, no SBTVD, so tratados por exibidores em hardware [TELEMDIA, 2008]. Outro objeto importante no sistema brasileiro aquele baseado em XHTML. NCL no substitui XHTML, mas a complementa naquilo que ela incapaz de cumprir como uma linguagem declarativa. Diferente do XHTML a linguagem NCL no mistura a definio do contedo de um documento com sua estruturao. Dependendo do browser embutido no Formatador NCL ser determinado qual objeto XHTML ter suporte. De acordo com essa escolha, teremos compatibilidade com os padres europeu, americano ou japons [TELEMDIA, 2008]. Durante a exibio dos contedos dos vrios objetos de mdia, eventos so gerados. Eventos podem gerar aes (de sincronismo) em outros objetos de mdia, tais como parar, iniciar ou pausar suas apresentaes. Assim, os eventos devem ser reportados pelos diversos exibidores ao Formatador NCL que, por sua vez, gerar aes a serem aplicadas em outros objetos de mdia, fazendo com que as relaes de sincronismo entre os objetos de mdia existentes sejam respeitadas [TELEMDIA, 2008]. O Formatador NCL o responsvel por receber um documento NCL e controlar sua apresentao, fazendo com que as relaes de sincronismo entre os objetos de mdia existentes sejam respeitadas. O ambiente declarativo , por si s, muito restrito. Aplicaes que utilizem uma linguagem declarativa devem ter seu foco no sincronismo, sendo o foco da linguagem NCL exatamente esse, e no a interatividade, visto que a interatividade tratada como uma decorrncia do sincronismo [SOARES, 2007]. Em NCL um documento XHTML um tipo de elemento de mdia. De forma semelhante, linguagens imperativas podem ser adicionadas e usadas como ns de mdia. Em especfico, a Ginga-NCL deve oferecer suporte a duas linguagens procedurais pela especificao, Lua e Java. Lua a linguagem de script da NCL e a Java deve seguir as especificaes do Ginga-J [CRUZ , 2008].

26

3.1.1. Lua

Lua uma linguagem de programao de extenso projetada para dar suporte programao procedural e oferece facilidades para a descrio de dados. A linguagem tambm oferece um bom suporte para programao orientada a objetos, programao funcional e programao orientada a dados. Lua foi planejada para ser utilizada por qualquer aplicao que necessite de uma linguagem de script leve e poderosa [IERUSALIMSCHY, 2007]. Por ser uma linguagem de extenso, Lua no possui a noo de um programa principal: ela somente funciona embarcada em um programa cliente anfitrio, chamado de programa hospedeiro ou simplesmente de hospedeiro. Esse programa hospedeiro pode invocar funes para executar um pedao de cdigo Lua, pode escrever e ler variveis Lua e pode registrar funes C para serem chamadas pelo cdigo Lua [IERUSALIMSCHY, 2007]. Lua funciona como uma mquina virtual (engine) acoplada ao Formatador NCL. Isso significa que, alm de sintaxe e semntica, Lua fornece uma API que permite a troca de dados com aplicaes. importante tambm destacar a integrao entre Lua e Java, atravs 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]. Alm disso, o LuaJava permite que a manipulao do ambiente de Lua a partir de Java, tornando-se, assim, parte da ponte entre os ambientes declarativo e procedural do middleware Ginga [TELEMDIA, 2008]. O uso de Lua oferece vantagens: alm de ser um projeto de cdigo aberto e desenvolvido em C, Lua combina programao procedural com poderosas construes para descrio de dados, baseadas em tabelas associativas e semntica extensvel; Lua tipada dinamicamente, interpretada a partir de bytecodes, e tem gerenciamento automtico de memria com coleta de lixo. Destaca-se pelo alto desempenho e baixo consumo de recursos apresentados, quando comparada com outras linguagens interpretadas. Essas caractersticas fazem de Lua uma linguagem ideal para configurao, automao (scripting) e prototipagem rpida [MORENO, 2006].

27

3.1.2. Edio em Tempo Real

No contexto de TV digital, a apresentao e a autoria de documentos hipermdia so 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 no s alguns contedos so desconhecidos, como tambm alguns relacionamentos espao/temporais entre objetos de mdia podem, ainda, no ter sido definidos [MORENO, 2006]. Muitos ambientes de autoria dispem de um emulador de visualizao em tempo real. O emulador permite ao autor visualizar a apresentao de um documento durante seu processo de criao. Entretanto, quando o documento editado, pode ser necessrio reiniciar a apresentao, para que o resultado seja constatado. Diferente desse cenrio, a edio ao vivo requer outros requisitos. Para atender estes requisitos um sistema de TV digital interativa, e conseqentemente seu ambiente de autoria, deve prover meios para se definir uma especificao inicial do documento. Como tambm, deve prover meios para modificar essa especificao em tempo de apresentao no ambiente do cliente telespectador [GUIMARES, 2007].

3.2. O AMBIENTE GINGA-J

Ginga-J foi desenvolvido pela Universidade Federal da Paraiba para prover uma infraestrutura de execuo de aplicaes baseadas em linguagem Java, chamadas de Xlet, com facilidades especificamente voltadas para o ambiente de TV digital. As Xlets no precisam estar previamente armazenadas no STB, pois podem ser enviadas pelo canal de difuso. Ou seja, o modelo Xlet baseado na transferncia de cdigo executvel pelo canal de difuso para o STB e posterior carga e execuo do mesmo, de forma automtica ou manual. Uma Xlet bastante similar a um Applet na Web ou MIDlet em celulares e outros dispositivos mveis [FERNANDEZ, 2004]. 28

Buscando controlar as Xlets, cada STB possui um Gerente de Aplicaes (Application Manager) instalado. Um gerente de aplicaes lida com os estados de cada Xlet, permitindo iniciar sua execuo, destruir, pausar e retomar sua execuo. Esses estados so necessrios, pois uma aplicao pode ser pausada momentaneamente se esta for ocultada por um vdeo de TV; ou ainda pode ser destruda caso o usurio 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 memria). O ambiente de execuo Ginga-J define um conjunto de APIs representadas abaixo (Figura 5) que podem ser divididas em trs partes: as APIs vermelhas, inovaes que do suporte s aplicaes brasileiras, em especial as de incluso social; as APIs amarelas, tambm inovaes brasileiras, mas que podem ser exportadas para os outros sistemas; e as APIs verdes, que seguem o ncleo comum do padro GEM. [SOFTWARE PUBLICO, 2008]

Figura 5 - Representao das APIs do Ginga-J

As aplicaes Ginga-J diferente das aplicaes JAVA destinada a desktops, devem obedecer a um conjunto de APIs mais restritivas e que foram definidas objetivando dar suporte ao desenvolvimento de aplicaes para TV digital. Na sua verso atual o Ginga-J segue as especificaes do GEM (Globally Executable MHP) e ITU J.200, J.201 e J.202 sendo portanto compatvel com os demais 29

midllawares de TV digital que seguem essas especificaes. O GEM baseado no middleware MHP e especifica um conjunto de APIs para serem usadas no desenvolvimento de aplicaes 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 extenso para a plataforma Java para sustentar a produo de contedo interativo de forma procedural para a televiso digital. A principal finalidade da API Java TV fornecer um conjunto de mtodos, classes e interfaces para facilitar a construo de aplicativos destinados a serem executados atravs de plataformas de recepo de televiso digital independentes das tecnologias utilizadas na rede de transmisso [ABNT 00:001.85006/4]. Cada servio Java TV caracterizado por um conjunto de informaes que descrevem o contedo do servio (SI - Service Information). As informaes sobre os servios disponveis so armazenadas em uma base de dados de informaes de servios (SI Database). A API Java TV prov uma abstrao que permite aplicaes obterem informaes sobre os diversos servios disponveis de forma independente do hardware e dos protocolos adotados. Desta forma, uma aplicao pode ser reusada em uma variedade de ambientes [FERNANDEZ, 2004]. A JavaTV suporta um alto nvel de interatividade, grficos de qualidade e seu processamento pode ser executado dentro de uma Set Up Box, desde que esta esteja equipada com a Mquina Virtual JAVA, necessria para interpretar os bytecodes gerados. Com o uso de JavaTV, programas de televiso tradicionais e interativos so caracterizados como um conjunto de servios individuais. Cada servio pode representar um programa de televiso convencional, no somente contendo udio e vdeo, como tambm um servio pode se tornar interativo, contendo udio, vdeo, dados e aplicaes associadas [FERNANDEZ, 2004].

30

Utilizando-se de sua arquitetura a API JavaTV capaz de executar funcionalidades, como: Fluxo de udio e vdeo: Alm do fluxo de vdeo e udio vindos da emissora, possvel gerar na aplicao outros fluxos; Acesso a dados no canal de transmisso: no JavaTV pode-se receber dados para as aplicaes; Interatividade com aplicaes: Os aplicativos que usam esta API podem processar dados e retorn-los atravs de um canal de retorno; Gerenciamento do ciclo de vida das aplicaes: permitindo que aplicaes coexistam com o contedo convencional de TV e possibilitando a troca de canal sem que a aplicao deixe de existir. A API JavaTV tem vrias bibliotecas, que so responsveis por prover a estrutura bsica do sistema. As bibliotecas esto dispostas da seguinte forma: javax.tv.carousel: prov acesso a arquivos broadcast e diretrios de dados atravs de APIs que trabalham com o pacote java.io; javax.tv.graphics: permite que Xlets possam obter seu repositrio principal; javax.tv.locator: prov uma forma para referenciar dados ou programas acessveis pela API JavaTV; javax.tv.media: define uma extenso para JMF (Java Media Framework) com a finalidade de gerenciar mdia em tempo real; javax.tv.media.protocol: prov acesso a um fluxo de dados broadcast genrico; javax.tv.net: permite acesso a datagramas IP (Internet transmitidos num stream broadcast; javax.tv.service: prov mecanismos para acessar a base de dados; javax.tv.util: suporta a criao e o gerenciamento de eventos do timer; javax.tv.xlet: prov interfaces para o desenvolvimento de aplicaes e para a comunicao entre as aplicaes e o gerenciador. Protocol)

31

Java TV tem sido amplamente adotado por organizaes de padronizao, tornando-o um forte candidato a padro mundial para contedo de televiso digital interativa. Temos como exemplo, as diversas implementaes de middleware que adotaram o modelo Java TV, com ligeiras diferenas entre si.

3.2.2. API DAVIC

O sistema DAVIC (Digital Audio Visual Council) um conjunto de especificaes que apresenta alguns requisitos de sistemas audiovisuais para prover interoperabilidade fim-a-fim. Assim, esses padres podem ser utilizados nos sistemas de televiso digital para fornecer contedo ao usurio final e tambm para permitir interatividade com o mesmo usurio [ABNT 00:001.85-006/4]. O sistema DAVIC tem suas prprias API, e portanto ele tambm pode ser considerado como um middleware de alto nvel (apesar de ser comum para ele operar em conjunto com um middleware de nvel mais baixo). A seguir so listados os pacotes que so parte da API DAVIC includos 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 usurio. Prov uma extenso ao pacote java.awt, permitindo, assim, suporte a controle remoto, transparncia, entre outros; 32

O principal objetivo de uma interface de usurio oferecer um ambiente operacional fcil de usar. A arquitetura HAVi permite que os usurios controlem dispositivos de forma familiar, atravs de um controle remoto ou de uma tela frontal. A seguir so listados os pacotes que so parte do HAVi API includos 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 padro MHP, o DVB incluiu alguns pacotes para estender as funcionalidades oferecidas pelo JavaTV, HAVi e DAVIC. Essas funcionalidades incluram API de Informaes de Servio, Intercomunicao entre Xlets, persistncia etc. Algumas das funcionalidades tambm foram includas na GEM. A seguir so listados os pacotes que so parte da API DVB includos 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 responsvel por permitir um caminho de comunicao entre os ambientes Ginga-NCL e o Ginga-J, pois atravs dela que aplicaes declarativas podem executar chamadas a aplicaes procedurais e vice-versa. Essa comunicao pode ser feita em duas direes. Em uma direo, possibilita ao ambiente declarativo chamar uma Xlet do Ginga-J como um simples objeto de mdia procedural NCLet ou atravs de um objeto de mdia procedural NCLua (script LUA), cujos mtodos referenciam mtodos do Ginga-J. Na direo contrria, atravs de funes do Ginga-J que podem monitorar eventos do NCL e podem tambm alterar elementos e atributos do NCL atravs de relaes ou de comandos de edio NCL. Isso similar ao que pode ser feito por objetos NCLua.

3.4. INOVAES DO GINGA

As funcionalidades inovadoras do Ginga-J, providas por suas APIs, permitem o desenvolvimento de aplicaes avanadas, explorando a integrao com outros dispositivos tais como telefones celulares, PDAs, etc. Essa integrao foi motivada por um outro nmero: o Brasil correntemente possui 79,5 milhes 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 interao (para responder a enquetes de maneira individual, por exemplo), etc. Uma vez que essas funcionalidades so todas implementadas utilizando protocolos comuns tais como Bluetooth, USB, Wi-Fi, etc., o Ginga compatvel com diversos dispositivos [MENDES, 2007]. H tambm a possibilidade de atualizao do middleware em tempo de execuo, tornando possvel receber atualizaes ou correes atravs de um canal de retorno ou pela emissora e corrigir as falhas, sem a necessidade de conhecimento do usurio.

34

Outra inovao do middleware brasileiro a ponte entre o ambiente declarativo e o procedural, no qual uma aplicao pode alterar e/ou executar uma aplicao de outro ambiente. possvel a gravao de aplicativos no middleware para serem executados posteriormente. Essa funcionalidade ser bastante til para a utilizao na educao, pois o professor poder salvar uma aplicao para ser executada com os alunos em um horrio 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 exigncias da incluso digital.

35

4. GUIA DE DESENVOLVIMENTO DE UM APLICATIVO PARA TV DIGITAL

Este guia visa mostrar as opes e os passos necessrios que o desenvolvedor de aplicaes para TV Digital deve determinar antes de iniciar a implementao. As opes para o desenvolvimento de aplicativos podem ser representadas ao longo de trs dimenses (Figura 6): (1) nveis de interatividade (interatividade local ou remota); (2) o desenvolvedor (emissora ou usurio); e (3) o ambiente de execuo.

Ambiente

Ginga-NCL Ginga-J

Emissora Usurio Int. Remota Int. Local

Nveis de Interatividade

Desenvolvedor
Figura 6 - Dimenses de desenvolvimento de aplicativos para TV digital

A TV Digital mais do que uma imagem e um som de alta definio. Com ela possvel desenvolver, para a televiso, aplicativos com capacidade computacional, como os de desktops, que permitem armazenar e processar informaes, e desde que exista um canal de retorno possibilitando a construo de aplicaes interativas. Essas aplicaes podem ser desenvolvidas tanto pelas emissoras de televiso quanto pelos usurios. Caso seja desenvolvida por uma emissora, a aplicao ser enviada ao set top box atravs do canal de transmisso. No caso de ser desenvolvida por um usurio esta ter que ser enviada ao set top box atravs de uma entrada externa (porta USB, porta de rede, carto de memria, etc). 36

Definido o nvel de interatividade e o desenvolvedor, deve-se ento definir o ambiente de execuo. Como visto no captulo anterior, o Ginga oferece dois ambientes de execuo: o ambiente para aplicaes declarativas Ginga-NCL e o ambiente para aplicaes nodeclarativo Ginga-J. Linguagens de programao declarativas so linguagens de alto nvel de abstrao, usualmente ligadas a um domnio ou objetivo especfico. Nelas, o programador fornece apenas o conjunto das tarefas a serem realizadas, no estando preocupado com os detalhes de como o executor da linguagem (interpretador, compilador ou a prpria mquina virtual de execuo) realmente implementar essas tarefas. Linguagens declarativas resultam em uma declarao do resultado desejado, ao invs da sua decomposio em uma implementao algortmica, e portanto normalmente no necessitam de tantas linhas de cdigo para definir certa tarefa [BARBOSA & SOARES, 2008]. Numa programao no-declarativa, devemos informar cada passo a ser executado. Pode-se afirmar que, em uma especificao seguindo o paradigma no-declarativo, o programador possui um maior poder sobre o cdigo, sendo capaz de estabelecer todo o fluxo de controle e execuo de seu programa [BARBOSA & SOARES, 2008]. O universo das aplicaes de um sistema de TV digital pode ser particionado em um conjunto de aplicaes declarativas e um conjunto de aplicaes no-declarativas. Linguagens declarativas normalmente so focadas em um domnio ou um objeto especfico, pois praticamente impossvel uma linguagem declarativa de propsito geral. Quando o foco do problema no casa com o foco da linguagem, sua resoluo, embora no seja impossvel, pode ser muito difcil. Neste caso recomenda-se o uso de uma linguagem no-declarativa [BARBOSA & SOARES, 2008]. Com o desenvolvedor, nvel de interatividade e o ambiente de execuo definidos, podemos, agora, definir o passos seguintes para criao destes aplicativos. O diagrama ilustrado na Figura 7 representa as opes de desenvolvimento disponveis em cada ambiente. No ambiente Ginga-NCL, podemos criar objetos que sero exibidos atravs do Formatador NCL. Esses objetos tambm chamados de n de contedo podem ser: (1) um objeto de mdia que faz associao a um elemento de mdia como vdeo, udio, imagem, texto, etc.; (2) um objeto XHTML que faz associao a um elemento XHTML; (3) um objeto Lua que associa um elemento para dar suporte programao no-declarativa utilizando scripts Lua. 37

Figura 7 - Diagrama com as opes de desenvolvimento

No ambiente de execuo das Xlets, o Ginga-J, devemos definir a quantidade de Xlets necessrias. Esta quantidade depende do nmero de funcionalidades distintas que sero implementadas para solucionar o problema. recomendado criar uma Xlet para cada funcionalidade especfica como visto na ilustrao 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 APIs tero suas classes implementadas. Nos tpicos seguintes deste captulo descrito os conceitos dos objetos NCL e do funcionamento dos Xlets utilizadas.

38

Figura 8 Display exibindo vrias Xlets

4.1. APLICAES NO AMBIENTE GINGA-NCL

Aplicativos para o Ginga-NCL so construdos sob a forma de documentos hipermdia. Esses documentos obedecem formatao da linguagem NCL e so compostos por ns e elos. Os ns so os objetos e os elos so responsveis por fazer a ligao entre os ns. Todo objeto deve ter o seu comportamento determinado. Para isto, a sua declarao, deve definir o que se quer tocar, como, quando e onde. O que tocar: quando iniciamos a construo de um programa audiovisual interativo a primeira coisa que consideramos o seu contedo, ou seja, quais vdeos, udios, imagens, textos e outros tipos de mdias ou programas sero apresentados. Onde tocar: com o contedo definido, podemos associar uma mdia a uma regio. Esta associao feita atravs de um descritor. Para isso, devemos indicar as posies

39

e as dimenses dos ns num local especfico atravs de elementos denominados regies. Como tocar: os descritores tambm so utilizados para definir a forma como a mdia dever ser apresentada. Por exemplo, podemos definir para um udio o seu volume; para uma imagem o seu grau de transparncia. Quando tocar: define o momento em que um n ser apresentado em relao aos outros. Esta relao feita atravs dos elos, que so utilizados para estabelecer o sincronismo entre os ns e para definir a interao do programa.

4.2. APLICAES NO AMBIENTE GINGA-J

4.2.1. O ciclo de vida da Xlet

A idia bsica de uma Xlet funcionar como uma mquina de estados em cima da mquina virtual que a est executando. As Xlets implementam a interface Javax.tv.xlet.Xlet que prov um ciclo de vida para a aplicao atravs da implementao de seus mtodos. Cada mtodo da interface prov uma transio a um estado da aplicao [MONTEZ, 2005]. As aplicaes Xlet podem se encontrar nos estados representados pela mquina de estados ilustrada na Figura 9. Quando a classe Java inicial de uma aplicao carregada ela entra no estado Carregada. O estado Carregada significa que a aplicao j foi carregada mas ainda no foi iniciada. No momento seguinte o Gerenciador de Aplicaes sinaliza a Xlet para que ele seja iniciado (chamando seu mtodo initXlet). Aps iniciado ele entra no estado Pausada. Uma aplicao neste estado est minimizando o uso de recursos para maximizar sua sobrevivncia, e est pronta para executar. No estado Em Execuo a aplicao est funcionando plenamente, e no estado Destruda j liberou todos os recursos e terminou sua execuo.

40

Figura 9 - Estados de um Xlet

Segue abaixo uma breve descrio dos mtodos da interface Javax.tv.xlet.Xlet que devem ser implementados para a construo de um Xlet [SUN, 2000]. initXlet: neste mtodo que as variveis e as instncias de objeto so inicializados. Nele o parmetro contexto do mtodo passado para a Xlet onde fica gravado caso seja requisitado no futuro. Este mtodo chamado somente uma vez no ciclo de vida da Xlet. startXlet: Mtodo chamado para fazer a aplicao executar sua funo principal, este mtodo deve implementar todos procedimentos necessrios para que a aplicao entre no estado de execuo. pauseXlet: Neste mtodo a aplicao deve parar de prover seus servios e entrar no estado de espera. destroyXlet: Neste mtodo devem ser implementados todos os procedimentos necessrios para que a Xlet termine sua execuo de forma correta. Geralmente usado para remover componentes grficos 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 aplicao do resto da mquina virtual. Um objeto XletContext passado a uma Xlet quando ele inicializado. atravs desta interface que o Gerenciador de Aplicaes controla o estado de um Xlet. Entre outras, o contexto permite a Xlet descobrir informaes a respeito do ambiente de execuo. [MONTEZ et al, 2005] 41

A interface XletContext define os seguintes mtodos [SUN, 2000]: notifyDestroyed: Este mtodo sinaliza ao Gerenciador de Aplicaes que a Xlet entrou no estado Destruda aps a Xlet ter completado sua execuo e estar pronto para ser destrudo. notifyPaused: Este mtodo sinaliza ao Gerenciador de Aplicaes que a Xlet entrou no estado Pausada. Deve-se entrar neste estado quando a Xlet no for prover um servio por um curto perodo de tempo getXletProperty: Este mtodo possibilita a Xlet obter informaes sobre o ambiente de execuo resumeRequest: Este mtodo sinaliza ao Gerenciador de Aplicaes que a Xlet deseja entrar no estado Em Execuo

4.2.2. Ambiente Grfico

Para a TV Digital, um modelo de display de imagem em camadas usado para o desenvolvimento de aplicaes e encontrado na maioria dos ambientes de desenvolvimento de aplicaes multimdia (Figura 10).

Figura 10 - Modelo de display de imagem em camadas

42

Este modelo o que melhor cumpre com as exigncias do ambiente de desenvolvimento de aplicaes para TV interativa. So definidos trs camadas conceituais de imagem: a camada de imagem de fundo de tela (background), a camada de vdeo e a camada grfica que exibe ao usurio a interface da aplicao. As camadas so sobrepostas para produzir a imagem vista pelo usurio final. No pacote HAVi que define componentes para a interface grfica, o componente principal que representa um dispositivo fsico de exibio o HScreen. Todo HScreen possui objetos HScreenDevice. Estes objetos representam as camadas de exibio. Tipicamente, todo HScreen ter uma das seguintes subclasses do HScreenDevice [KLIMCUK, 2008]. HBackgroundDevice: representa a camada de background HVideoDevice: representa a camada de vdeo HGraphicsDevice: representa a camada grfica

Quando se trabalha em aplicaes 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 grficos podem ser inseridos e exibidos. Em Xlets permitido o uso dos tradicionais componentes AWT, como java.awt.Container ou java.awt.Componet, porm, HAVi disponibiliza uma verso mais adaptada deste componentes para serem usados em ambientes de Xlets, que so, 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 atravs da implementao de um estudo de caso. A proposta do trabalho considera a implementao de um sistema de recomendao de programao de televiso baseado no tempo gasto pelo telespectador assistindo um determinado canal. Este captulo mostrar uma introduo aos sistemas de recomendao mostrando seus conceitos e em seguida ser descrito o funcionamento da aplicao AutoCanal.

5.1. SISTEMAS DE RECOMENDAO

Com o surgimento da televiso digital e da internet, a quantidade de informaes e a facilidade de acesso do uso das mesmas aumentaram, fazendo com que as pessoas se deparassem com uma diversidade muito grande de opes. Essa sobrecarga de informaes muitas vezes deixa o usurio com dificuldades em obter informaes sobre os seus programas favoritos. Para minimizar as duvidas e necessidades que temos frente escolha entre alternativas surgem ento os sistemas de recomendao que tem o objetivo de recomendar itens a um usurio atravs de uma filtragem de informaes relevantes baseadas no seu perfil de interesse [ELISEO & SILVIO]. O processo de coleta desse perfil se d de maneira implcita e explicita. No processo de coleta explicita o perfil construdo diretamente pelo usurio, este indica espontaneamente o que lhe importante. Na modalidade implcita o sistema gera o perfil enquanto o mesmo opera o sistema, atravs de aes do usurio infere-se informaes sobre suas necessidades e preferncias [ELISEO & SILVIO]. A filtragem de informaes citada anteriormente uma tarefa comum em ambientes onde o fluxo de informao grande. Filtragem de informao o nome utilizado para escrever uma variedade de processos que envolvem a entrega de informao para as pessoas

44

que realmente necessitam delas. So aplicadas duas tcnicas de filtragem nos sistemas de recomendao: filtragem baseada em contedo e filtragem colaborativa [ELISEO & SILVIO]. Na filtragem baseada em contedo apenas as preferncias do prprio usurio so utilizadas na filtragem. Esta tcnica tem como objetivo aprender sobre as caractersticas da descrio dos itens de informao relevantes e no relevantes para um usurio, para que possa fazer um julgamento da relevncia de novos itens de acordo com as preferncias desse usurio Na filtragem colaborativa h uma formao de uma comunidade de usurios que interagem com o sistema fornecendo avaliaes. Os sistemas colaborativos se baseiam na similaridade entre os usurios que so membros da comunidade. A idia bsica fornecer recomendao de documentos a um usurio de acordo com a opinio de outros usurios de preferncias similares [IVAN, 2002].

5.2. APLICAO AUTOCANAL

A aplicao 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 grfica. Com o objetivo de auxiliar possveis programadores, foi criado um tutorial de desenvolvimento de aplicaes utilizando a API JavaTV que pode ser visto no apndice A. As caractersticas da Aplicao AutoCanal segundo, as dimenses definidas anteriormente esto refletidas na ilustrao da figura 11. O nvel de interatividade, o desenvolvedor e o ambiente utilizados esto em destaque. J as opes de desenvolvimento da aplicao AutoCanal, segundo o diagrama ilustrado anteriormente esto refletidas na figura 12. Nele os ns utilizados (cada n representa uma das opes de desenvolvimento) esto destacados na colorao vermelha. Na aplicao AutoCanal (Figura 13) o processo de recomendao foi simplificado. Na recomendao da informao (canal) ao usurio a filtragem obtida atravs de um histrico de preferncias do prprio usurio e no de comparaes feitas por um conjunto de usurios.

45

Ambiente

Ginga-NCL Ginga-J

Emissora Usurio Int. Remota Int. Local

Nveis de Interatividade

Desenvolvedor
Figura 11 Localizao Espacial da aplicao AutoCanal

Figura 12 - Diagrama das opes de desenvolvimento de aplicao AutoCanal

46

Segundo a comunidade de IA Sistemas de Recomendao so sistemas de informao que coletam indicadores da preferncia dos usurios e utilizam tcnicas de Filtragem de Informao (FI) para fornecer uma viso personalizada da informao. Na aplicao AutoCanal foi apenas considerada informaes do prprio usuario para realizar a recomendao. Esta aplicao possibilita ao usurio assistir trs canais diferentes (de forma simulada), os quais podem ser trocados pelo controle remoto atravs dos botes 1, 2 e 3. A medida que o usurio vai assistindo os canais a aplicao guarda informaes (canal e hora) para posteriormente sugerir uma programao ao usurio de acordo com o seu histrico. Nesta aplicao simulado tanto a transmisso dos canais como o tempo. No mtodo 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 usurio est assistindo atravs da classe AutoProgramacao, como tambm verificado se o usurio 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 mudana automtica de canal e caso seja desejado cancelar esta mudana a tecla vermelha deve ser pressionada.

Figura 13 - Interface da aplicao AutoCanal

47

6. CONCLUSO

Aps realizar um levantamento sobre os padres utilizados e as novas formas de utilizao da TV digital, ficou fcil constatar que essa nova tecnologia trar inmeras melhorias. Alm de benefcios como imagem e som de alta definio, a possibilidade de assistir a programao atravs de dispositivos mveis e a televiso poder realizar atividades computacionais (armazenar e processar informaes) vistas antes em dispositivos como computadores pessoais. A TV digital traz, como principal contribuio, a interatividade, proporcionando ao usurio a capacidade de enviar informaes, o que o faz deixar de ser um mero telespectador quando este era apenas um receptor de informaes. A TV Digital no Brasil ainda encontra-se em estagio inicial, diferente de outros pases onde j existem padres definidos h alguns anos. Entretanto, este atraso pode ser encarado de uma forma positiva, pois possibilitou a construo de um sistema mais maduro (o SBTVD se baseou no padro japons). Isso possibilitou a utilizao de tecnologias mais modernas, como por exemplo, a compactao de vdeo H.264. Alm do levantamento realizado sobre o SBTVD e seu middleware Ginga foi criado um guia para o desenvolvimento de aplicativos para TV digital. Atravs da leitura deste guia um desenvolvedor ter conhecimento de quais so os ambientes de desenvolvimento disponveis e quais so 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 recomendao baseado em contedo no qual uma programao seria sugerida ao usurio com base num histrico de informaes filtradas a partir dos programas assistidos anteriormente (ex.: atores, gnero, horrio etc). Entretanto, foi criado um sistema de recomendao simplificado.devido a algumas restries. Entre estas restries podemos citar o fato das especificaes do Ginga-J no terem sido lanadas at o presente momento e o fato do Xletview (emulador de aplicaes Java para TV digital) no oferece suporte a algumas bibliotecas necessrias. Por fim, este trabalho vem servir de referncia 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

REFERNCIAS BIBLIOGRFICAS

[ABNT 00:001.85-006/4] Projeto de Norma ABNT 00:001.85-006/4 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para transmisso digital Parte 4: Ginga-J - Ambiente para a execuo de aplicaes procedurais. [ANATEL, 2004] ANATEL, Agncia Nacional de Telecomunicaes. TV Digital. Braslia, 2004. [ATSC, 2008] Advanced Television Systems Committee. Disponvel 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, Padres, 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 Portteis Middlewares. PUC-RIO. Janeiro 2008. [DASE, 2008] Standard A/100 - DTV Application Software Environment Level 1 (DASE1). Disponvel 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. Disponvel em acessado em junho de 2008. [DVB, 2008] Digital Video Broadcasting Project. Disponvel em www.dvb.org e acessado em junho de 2008. [ECMA, 2008]. Standard ECMA-262 ECMAScript. Language Specification. 3rd edition Disponvel em http://www.ecma-international.org/publications/standards/Ecma-262.htm e acessado em julho de 2008 [ELISEO & SILVIO, 2005] Sistemas de Recomendao. XXV Congresso da Sociedade Brasileira de Computao. Unisinos - So Leopoldo/RS, julho de 2005. www.dibeg.org e

49

[FERNANDEZ, 2004] FERNANDEZ, J.; LEMOS, Guido.; SILVEIRA, G. Introduo Televiso Digital Interativa: Arquitetura, Protocolos, Padres e Prticas. In JAI-SBC. Salvador, 2004. [FUNTEL, 2006] Fundo para o Desenvolvimento Tecnolgico das Telecomunicaes. Arquitetura de Referencia: Sistema Brasileiro de Televiso Digital Terrestre, 10 de Fevereiro de 2006 [GUIMARES, 2007] GUIMARES , Rodrigo. Composer: um ambiente de autoria de documentos NCL para TV digital interativa. Dissertao de Mestrado. PUC Rio de Janeiro, 2007. [HAVi, 2001]. HAVi v1.1 - Home Audio Video Interoperability Version 1.1. Disponvel em www.havi.org e acessado em junho de 2008. [IERUSALIMSCHY, 2007] IERUSALIMSCHY, Roberto; FIQUEREIDO, Luiz; CELES, Waldemar. Manual de Referncia 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 Mtodo de Aprendizagem Ativa em Sistemas de Filtragem Colaborativa. Universidade Federal de Pernambuco. Recife, 2002 [KLIMCUK, 2008] KLIMCUK, Toms. Development environment for development of graphical user interface of iDTV. Master thesis. Faculty of Electrial Engineering. Prague, 2008. [KOOGAN & HOUAISS, 1999] KOOGAN, HOUAISS. Enciclopdia e dicionrio 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 implantao. V Congresso Nacional de Histria da Mdia. So Paulo, 2007. [MANUEL, 2007] MANUEL, Edson. Codificao de vdeo H.264 Estudo de codificao mista de macroblocos. Dissetao de Mestrado. Universidade Federal de Santa Catarina. Florianpolis, 2007. [MENDES, 2007] MENDES, Luciano Leonel. Artigo: SBTVD Uma Viso sobre a TV Digital No Brasil. T&C Amaznia 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. Florianpolis: Editora da UFSC, 2005. [MONTEZ, 2005] MONTEZ, Carlos; BECKER, Valdecir; FILHO, Gnter H. Herweg. Datacasting e Desenvolvimento de Servios e Aplicaes para TV Digital Interativa. 2005. [MORENO, 2006] MORENO, Mrcio Ferreira. Um Middleware Declarativo para Sistemas de TV Digital Interativa. Dissertao 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. Modulao COFDM Uma proposta atrativa para os padres 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. So Leopoldo, 2003. [SOARES, 2007] SOARES, Luiz; RODRIGUES, Rogrio; MORENO, Mrcio. Ginga-NCL: the Declarative Environment of the Brazilian Digital TV System. JCBS. no. 1; Vol. 13; Mar. 2007. [SOFTWARE PUBLICO, 2008] Disponvel na internet em e

http://www.softwarepublico.gov.br/dotlrn/clubs/ginga/one-community?page_num=3 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. [TELEMDIA, 2008]. Laboratrio de Telemdia. Ambiente para Desenvolvimento de Aplicaes Declarativas para a TV Digital. Laboratrio Telemdia. Departamento de Informtica. PUC-RIO. Disponvel na Internet em

http://www.ncl.org.br/documentos/MDIC2007.pdf e acessado em 10/07/2008 [TONIETO, 2006] TONIETO, Mrcia. Sistema Brasileiro de TV Digital - SBTVD - Uma anlise poltica e tecnolgica na incluso social. Fortaleza, 2006. Dissertao de Mestrado Centro de Cincias e Tecnologia, Universidade Estadual do Cear.

52

APNDICE A TUTORIAL DE DESENVOLVIMENTO DE UM APLICATIVO EM JAVATV

Este apndice 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 descrio das APIs utilizadas, explica o ciclo de vida de uma Xlet, demonstra com exemplos prticos 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 utilitrios que permitem criar sistemas de software para a plataforma Java. composto por compilador e bibliotecas. IDE, do ingls Integrated Development Environment ou Ambiente

Integrado de Desenvolvimento, um programa de computador que rene caractersticas e ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este processo. Para o desenvolvimento de aplicaes Java bastante recomendvel o uso de uma IDE. As duas mais famosas so Eclipse e Netbeans. Os exemplos dados para a elaborao deste guia sero 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 cdigo aberto (Open Source), recursos multimdias

53

implementados para utilizao dos componentes HAVi, baseado no padro MHP e fornece uma maneira fcil e rpida de testar as aplicaes. 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 verso utilizada deste emulador foi a 0.3.6 em conjunto com o JMF 2.1.1. O Xletview possui muita limitaes, no d suporte a todas as funcionalidades oferecidas pela API JavaTV, como tambm bastante limitada para reproduzir a maioria das codificaes de vdeo.

Figura 1 Interface do Xletview

Dica: recomendado executar o Xletview atravs da linha de comando java -jar xletview.jar, pois desta forma possvel 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 necessrias para a construo 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 aplicao possa referenciar as bibliotecas do MHP, HAVi, DAVIC e JMF necessrio importar o arquivo xletview.jar. Para realizar esta operao, no Eclipse, aps ter um projeto criado, v a propriedades, escolha a opo 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 incio a implementao de uma Xlet. No Exemplo 01 temos um cdigo que serve de estrutura base para a implementao de um simples Xlet. Temos em seguida exemplos que mostram os cdigos utilizados para a insero de texto, boto, imagem, som, vdeo e eventos em um Xlet, estes cdigos devem ser utilizados em conjunto com o Exemplo 01.

/** * Esta uma implementao simples de um Xlet. * Serve de esqueleto para a construo de aplicaes * 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 mtodos so herdados desta interface. */ public class SimplesXlet implements Xlet {

55

private XletContext context; public SimplesXlet() { /** * Toda Xletdeve ter um construtor padro onde nada * deve ser feito. Qualquer inicializao deve ser * feita no mtodo initXlet() ou em startXlet(). Desta * forma o middleware pode controlar a inicializao * de uma forma mais previsvel. * */ } public void initXlet(XletContext context) throws XletStateChangeException { /** * Inicializa o Xlet. neste mtodo que o contexto da * xlet deve ser passado para futuras referncias. * o lugar onde as inicializaes devem ser feitas, * a no ser que tenha um custo computacional muito alto. * O controle de exeo XletStateChangeException deve ser * referenciado para o caso de ocorre um erro na inicializao. */ this.context = context; } public void startXlet() throws XletStateChangeException { /** * Ativa o Xlet. Neste ponto a Xletpode ser mostrado * na tela e comear a interao com o usurio ou realizar * outra tarefa. Este tipo de tarefa no deve ser feita * no initXlet(). * * Como em iniXlet o controle de exeo 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 no sejam usados de forma desnecessria * e deve ser removido da tela. */ } public void destroyXlet(boolean unconditional) throws XletStateChangeException { /** * Destroi o Xlet. O parmetro booleano diz ao mtodo * se a Xletdeve obedecer esta requisio. Se o valor * for verdadeiro a Xletdeve ser terminado. Caso * contrrio, a Xletpode informar que no foi destrudo * lanando XletStateChangeException */ } } Exemplo 01 Estrutura bsica de um Xlet

56

3.1.

Inserindo Texto

Para inserir um texto voc deve: a) Importar bibliotecas

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

b) Criar os objetos e variveis

private HScene scene; private HStaticText texto;;

c) Definir os parmetros 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 Boto

Para inserir um boto voc deve: a) Importar bibliotecas

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

57

b) Implementar a classe KeyListener

public class SimplesXlet implements Xlet, KeyListener

c) Criar os objetos e variveis

private private private private HScene scene; HTextButton botao1; HTextButton botao2; HDefaultTextLayoutManager manager;

d) Definir os parmetros 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 aplicao 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 import import import import javax.swing.ImageIcon; javax.tv.xlet.XletContext; javax.tv.xlet.XletStateChangeException; org.havi.ui.HContainer; org.havi.ui.HIcon;

58

import java.awt.Image;

b) Criar os objetos ou variveis

private HContainer container = new HContainer(); private Image imagem; private HIcon icone = null;

c) Definir os parmetros 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 import import import javax.tv.xlet.XletContext; javax.tv.xlet.XletStateChangeException; org.havi.ui.HContainer; org.havi.ui.HSound;

b) Criar os objetos ou variveis

private HSound som = new HSound(); private String SOM_URL;

c) Definir os parmetros dos objetos

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

3.5.

Inserindo Vdeo 59

Para inserir vdeo voc deve: a) Importar bibliotecas

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

b) Criar os objetos ou variveis

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

c) Definir os parmetros 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 boto public void keyPressed(KeyEvent evento) { switch(evento.getKeyCode()){ case KeyEvent.VK_UP: { //Executar ao para o boto seta pra cima break; } default: { break; } } } public void keyReleased(KeyEvent arg0) {} public void keyTyped(KeyEvent arg0) {}

4. EXECUTANDO UM XLET

Aps a implementao do Xlet, objetivando a sua execuo, 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. ii. iii. No menu Applications, selecione Manage applications Na janela que se abre, escolha New Application Informe o nome da sua aplicao, 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

APNDICE B - CDIGO DE IMPLEMENTAO DA APLICAO AUTOCANAL

A CLASSE PRINCIPAL - AUTOCANALXLET

/** * @author Joo Paulo Lacerda - jplacerda@gmail.com * Antnio Carlos Albuquerque - antonioc.albuquerque@gmail.com * * A Xlet AutoCanalXlet possibilita ao usurio assistir trs canais * (de modo simulado) diferentes que podem ser trocados no controle * remoto nos botes 1, 2 e 3. * A medida que o usurio vai assistindo os canais a aplicao vai * guardando informaes para posteriormente sugerir a programao * ao usurio de acordo com o seu histrico. */ //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 private private private private private private private private private private

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

/** * Toda Xletdeve ter um construtor padro onde nada deve ser feito. * Qualquer inicializao deve ser feita no mtodo initXlet() ou * em startXlet(). Desta forma o middleware pode controlar a * inicializao de uma forma mais previsvel. */ public AutoCanalXlet() {}

/** * Inicializa o Xlet. neste mtodo que o contexto da Xletdeve * ser passado para futuras referncias. o lugar onde as * inicializaes devem ser feitas a no ser que tenha um custo * computacional muito alto. * O controle de exeo XletStateChangeException deve ser * referenciado para o caso de ocorre um erro na inicializao. */ 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 * comear a interao com o usurio ou realizar outra tarefa. * Este tipo de tarefa no deve ser feita no initXlet(). * * Como em iniXlet o controle de exeo 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 no * sejam usados de forma desnecessria e deve ser removido da tela. */ public void pauseXlet() { System.out.println("pauseXlet"); } /** * Destroi o Xlet. O parmetro booleano diz ao mtodo se o Xlet * deve obedecer esta requisio. Se o valor for verdadeiro o Xlet * deve ser terminado. Caso contrrio, a Xletpode informar que no * foi destruido lanando 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 mtodo iniciarControleCustomizado() implementado um loop * infinito que contem o mtodo 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 usurio est assistindo * atravs da classe AutoProgramacao, como tambm verificado se * o usurio 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 mudana automtica * de canal e que caso deseje cancelar esta mudana 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("Mudana prevista para o Canal: " + canal_preferido + " s " + Integer.toString(hora) + ":00 \n Aperte o boto 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 mtodo muda o canal (o vdeo que est sendo exibido) de * acordo com o valor passado no parmetro. * @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 mtodo responde aos eventos do controle remoto. Caso o boto * 1, 2 ou 3 seja pressionado ser chamado o mtodo 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 Joo Paulo Lacerda - jplacerda@gmail.com * Antnio Carlos Albuquerque antonioc.albuquerque@gmail.com * * Esta classe implementa a inteligncia artificial da aplicao. * Nela criada uma matriz de 3 por 24. O 3 representa o nmero de canais * e o 24 o intervalo de tempo, neste caso o nmero de horas . * Todos os valores da matriz iniciam com valor 0 e podem ser incrementados * de acordo com o canal que o usurio assiste em determinada hora. Criando * assim um sistema de pontuao que possibilita a aplicao saber qual * o canal favorito do usurio 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 pontuao, 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 vdeos que simulam os canais. */ import import import import import import import import import java.awt.Component; java.awt.event.KeyAdapter; java.awt.event.KeyEvent; java.io.IOException; javax.media.*; javax.media.protocol.*; javax.tv.xlet.*; org.havi.ui.*; 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 nmero 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 exibio //do vdeo 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 vdeo public void start() { System.out.println("start"); if(player != null) player.start(); } //Pausa o vdeo public void pause() { System.out.println("pause"); if(player != null) player.stop(); } //Fecha e desaloca o vdeo public void close(){ System.out.println("close"); if(player != null) { player.close(); player = null; } } }

69