Chapter

1
Datacasting e Desenvolvimento de Servios e Aplicaes para TV Digital Interativa
Valdecir Becker, Carlos Piccioni, Carlos Montez, Gnter H. Herweg Filho

Abstract This short course introduces the interactive digital TV services and applications development. The main concepts around interactive digital TV, and the technology overview, are showed. It encloses since datacasting concepts until the applications development tools. Resumo Este minicurso introduz o tema desenvolvimento de servios e de aplicaes para TV digital interativa. Traz os principais conceitos envolvidos no tema e oferece uma viso geral sobre os componentes e fases envolvidos no processo. Abrange desde conceitos como datacasting at as ferramentas usadas no desenvolvimento dos aplicativos.

1.1. Apresentao
O presente minicurso enfoca um tema que usualmente no faz parte dos currculos de graduao: a TV digital interativa. O desenvolvimento de servios e aplicaes para TV digital interativa um tema relativamente novo, com pouca literatura consolidada a respeito. O principal objetivo oferecer uma viso geral sobre os conceitos adjacentes ao desenvolvimento de aplicaes para essa nova mdia, alm de abordar as tecnologias envolvidas. Para tanto, enfatizaremos os aspectos sociais e tcnicos relevantes tanto para entender a TV digital e a concepo dos servios e das aplicaes, assim como os aspectos estritamente tcnicos de desenvolvimento, programao e publicao. So abordados temas usuais no desenvolvimento de temas para televiso, as ferramentas necessrias para desenvolver e transmitir as aplicaes e os temas tericos que interligam os dois aspectos anteriores. O enfoque do minicurso tcnico, explicando conceitos e descrevendo as tecnologias envolvidas, porm sem desconsiderar a evoluo

e o alcance social da TV e os conceitos e recursos de interatividade, fundamentais para entender o que pode vir a ser TV interativa brasileira.

1.2. Televiso e internet

A televiso brasileira tem mais de meio sculo de vida. Quando, no final da dcada de 1940, Assis Chateaubriand iniciou as negociaes com a americana RCA para importar a televiso para o pas, pouca gente sabia o que era essa nova tecnologia. O prprio Chateaubriand inicialmente a considerava uma forma de ganhar dinheiro, mas no dia da inaugurao saudou o mais subversivo instrumento de comunicao deste sculo (Loredo 2000). No entanto, os anunciantes demoraram muito a acreditar no novo veculo (...) impedindo que Chateaubriand tivesse o esperado retorno do seu investimento (Loredo 2000). Loredo (2000) lembra que quando comearam as transmisses da televiso brasileira ningum sabia o que era fazer televiso. Tudo era uma interrogao. Estvamos todos ali aprendendo de improviso. A Tupi, tanto no Rio como em So Paulo, era a universidade da televiso brasileira, abrindo um caminho promissor para as futuras geraes. Apesar dessa incgnita do que era fazer televiso, esse novo meio de comunicao evoluiu e se tornou na principal fonte de informao da populao brasileira. Pesquisas mostram que mesmo as classes sociais mais privilegiadas e com acesso a outros meios de comunicao, como os estudantes universitrios, tm na TV a principal fonte de informao (Agncia Estado 2005). Esse papel comeou a se delinear ainda na dcada de 1970, com o fortalecimento da Rede Globo e com a criao do Padro Globo de Qualidade, que uniformizou as programaes de todas as afiliadas da rede (Bial 2005). Alm disso, a televiso tem ainda uma peculiaridade inexistente nas outras tecnologias, a exceo do rdio: ela conversa com as pessoas, incentivando-as a agirem (Crocomo 2004). Isso a torna uma ferramenta de coao e de incentivo a ao, permitindo que a sociedade reaja a um determinado impulso visto na TV. Essa caracterstica fundamental para estimular o processo de alfabetizao digital atravs da TV digital, pretendido pelo governo no Sistema Brasileiro de TV Digital (SBTVD). Machado (2003) explica que a televiso ... um dispositivo audiovisual atravs do qual uma civilizao pode exprimir a seus contemporneos os seus prprios anseios e dvidas, a suas crenas e descrenas, as suas inquietaes, as suas descobertas e os vos da imaginao. (...) a televiso e ser aquilo que ns fizermos dela. Dessa forma podemos concluir que a televiso reflexo da sociedade e de seus anseios. Alm disso, a televiso tem uma relao dialtica com as pessoas. Na medida em que a sociedade se informa atravs dela, passa tambm a ser influenciada. Entender esse conceito extremamente importante quando desenvolvemos programas para a televiso, e agora, com a interatividade, aplicativos. Por outro lado, a internet, com pouco mais de 10 anos de vida no pas, tambm j tem uma histria de mudanas e adaptaes, tanto a realidade brasileira como s novas possibilidades de mercado, advindas com a evoluo da tecnologia digital. Os primeiros contedos que foram oferecidos na internet nada tinham de novo. Eram

simples adaptaes e transcries do que j existia em meio impresso. Com o passar do tempo, a abordagem e a arquitetura da informao foram se adaptando as caractersticas do novo meio, fazendo surgir produtos multimdia e hipermdia s possveis em meios interativos. nesse contexto que surge no Brasil a televiso digital interativa, com todas as adversidades e incertezas de qualquer nova mdia. Segundo Becker e Montez (2005), a televiso interativa uma nova mdia porque quebra os paradigmas da televiso analgica de unidirecionalidade da informao e da passividade do telespectador. Atravs dessa nova tecnologia, possvel interagir com a programao sem necessitar de uma terceira mdia, como o telefone ou a internet. Atravs do canal de interatividade, a televiso passa a ter uma forma de contato direto com os telespectadores, que deixam de simplesmente assistir a televiso para passar tambm a us-la, tornando-se um usurio. Isso torna o telespectador ativo, usando a TV como uma ferramenta potencial resolvedora de problemas (BBC 2004) A TV digital oferece opes muito superiores a TV analgica (com circulao unidirecional da informao, conhecida atualmente) (Srivastava 2002). A capacidade de transmisso de dados (datacasting), que possibilita a interatividade em diferentes nveis, traz potenciais benefcios e facilidades atualmente disponveis apenas na internet (Whitaker 2001). Isso tem impactos diretos na circulao da informao, que pode-se tornar muito mais abrangente, atingindo setores da sociedade atualmente excludos (Casttles, 2003). Alm disso, provoca conseqncias ainda no delineadas em inmeros outros temas, como direitos autorais, comrcio eletrnico e novos requisitos de segurana dos sistemas. Tambm pode se tornar uma ferramenta poderosa de educao a distancia, entretenimento, notcias, governo eletrnico e novos servios (Piccioni et. al. 2003), no disponveis atualmente ou ainda sequer imaginados (Becker e Moraes 2003). Tudo isso tende a permitir o uso da TV como ferramenta para a aquisio de informao, substituindo a forma passiva com que o telespectador recebia informaes transmitidas unidirecionalmente (Becker e Montez 2004). Porm, a simples juno da linguagem da internet com a televiso no representa nenhum atrativo especial para o telespectador, por que o comportamento do telespectador difere drasticamente do internauta (Nielsen 2000). Enquanto que o primeiro apenas recebe informaes de forma passiva, sem interferir, o segundo determina os rumos da navegao. Assim, a internet caracteriza-se como um meio muito rico em informaes baseado em um alto grau de iniciativa e participao: as pessoas criam sua prpria experincia atravs de um fluxo de cliques que seguem os hipertextos. Segundo Becker e Montez (2005), a interatividade, resultante, principalmente, da juno das linguagens da TV e da internet, pode ser dividida em sete nveis. No ltimo nvel, o usurio se confunde com o atual emissor de contedo. Essa possibilidade foi amplamente estudada por Crocomo (2004), que conclui ser plenamente possvel para o telespectador produzir e enviar contedo televisivo para as emissoras. O grau dessa participao e a agilidade vo depender dos recursos tecnolgicos envolvidos. Para Pagani (2003), essas novas possibilidades s so possveis pela convergncia de tecnologias, basicamente a TV, o computador pessoal e o telefone. Relacionando Pagani (2003) e Crocomo (2004), possvel perceber uma relao clara entre a evoluo

tecnolgica e as novas possibilidades de contedo televisivo e formatos de interatividade na TV.

1.3. Panorama mundial das aplicaes interativas

A televiso interativa comeou a se delinear no final da dcada de 1990. Desde ento inmeras emissoras tm iniciado a transmisso de aplicaes e de servios interativos, com foco em diversos tipos de interatividade. De uma maneira geral, a interatividade sem canal de retorno a que tem feito mais sucesso. Por outro lado, aplicaes de email, banco e comrcio eletrnicos ainda no deram o resultado esperado. Bernardo (2002) divide os servios oferecidos pela televiso interativa em 10 tipos: EPG, Comrcio eletrnico, Banco eletrnico, E-mail, Internet, Portais de televiso interativa, Aplicaes transversais aos canais, Programas interativos, Publicidade interativa. A seguir faremos uma anlise de cada um desses servios. 1- EPG (Electronic Program Guide) uma relao com a programao dos diversos canais disponveis, com datas e horrios de inicio e trmino de cada programa. Muito comum na TV por assinatura, onde o operador da rede disponibiliza os dados sobre todas as emissoras disponveis naquele pacote. Na TV aberta mais comum cada emissora oferecer o seu EPG. No necessita de canal de interatividade, uma vez que a atualizao feita por broadcast. o maior sucesso da TV digital. 2- Comrcio eletrnico a possibilidade de fazer compras usando a televiso. O servio no difere muito do que conhecido atualmente na internet; apenas oferece a comodidade da televiso com canal de interatividade para a realizao das compras. Comumente est aliado publicidade interativa. 3- Banco eletrnico tambm muito semelhante aos servios oferecidos na internet, o acesso ao banco atravs da TV foi uma grande aposta na Europa, porm at agora com poucos resultados. Como o servio similar internet, a estrutura necessria por parte dos bancos tambm similar, precisando apenas ser replicada para esse novo meio de comunicao. 4- E-mail o acesso ao correio eletrnico tambm est no nvel das apostas na maioria dos pases que j adotaram a TV digital. Da mesma forma como o banco eletrnico, a estrutura de servidores e clientes similar a internet, necessitando apenas uma adaptao dos softwares clientes. 5- Internet o acesso internet sem a necessidade de um PC uma das principais apostas da televiso digital. O uso de um set top box, uma linha telefnica e a televiso como monitor h anos seduz os idealizadores da TV digital. Porm, at o momento no h registros de um sucesso absoluto dessa tecnologia, mesmo porque nos pases pioneiros na implantao da TV digital a internet uma constante na vida das pessoas. O Brasil aposta fortemente nessa possibilidade para levar a internet s pessoas que no tem condies de adquirir um computador. 6- Portais de televiso interativa tambm conhecidos como walled gardens, so portais que disponibilizam uma relao dos contedos oferecidos por uma

determinada emissora. Normalmente representam um resumo dos servios e aplicaes que a emissora detentora do canal oferece. 7- Aplicaes transversais aos canais so servios oferecidos pela TV digital mas que no esto atrelados a nenhum canal especificamente, como acontece com os portais. Normalmente so aplicaes de utilidade pblica ou de governo eletrnico, sem nenhuma vinculao com os contedos audiovisuais transmitidos pelos canais normais de televiso. 8- Programas interativos so aplicativos diretamente relacionados ao contedo audiovisual, completando-o ou muitas vezes, alterando-o. So os aplicativos que mais aproximam a televiso do conceito ideal de televiso interativa, onde o usurio est englobado na emisso da programao. So inmeros os exemplos de sucessos de programas interativos, principalmente em transmisses esportivas, programas infantis, educao, programas jornalsticos e de entretenimento. O mais comum nesse tipo de aplicativo o oferecimento de informaes adicionais programao, que completam a mesma ou que permitem que a ela seja alterada na origem. 9- Publicidade interativa uma extenso do comercio eletrnico na TV, permite que os produtos anunciados sejam comprados na mesma hora. Na Europa esse tipo de anncio comea a ter somas significativas nos faturamentos das empresas de comunicao, com interesse principalmente por produtos esportivos e alimentcios. 10- Jogos e outras aplicaes apesar de pode ser includo nos itens seis ou sete, os jogos representam um conjunto de aplicaes de enorme sucesso em algumas plataformas de televiso. Especialmente desenhados para a resoluo da TV, especialistas apontam uma possvel convergncia entre os game consoles e os set top boxes com canal de interatividade e acesso a internet. Na Inglaterra surgiu um novo mercado de empresas totalmente dedicadas ao desenvolvimento desse tipo de aplicao. De uma maneira resumida podemos identificar uma srie de servios que ainda no deram a resposta comercial esperada pelos seus idealizadores. Fazendo uma relao entre eles, pode-se perceber uma caracterstica comum: esto presentes na internet e foram simplesmente portados para a televiso. A pergunta que no feita na Europa, onde a internet plenamente disseminada, : se tem na internet, por que algum vai querer usar a televiso para fazer a mesma coisa? Vale lembrar que a TV tem recursos muito mais limitados que qualquer computador pessoal, como resoluo de monitor, processamento, memria e armazenamento. Por outro lado, tem uma penetrao muito maior no Brasil do que a internet, o que a torna um meio atrativo para levar informaes adicionais a pessoas atualmente fora do mundo digital.

1.4. Definio de servios

Na difuso terrestre no Brasil, atualmente, em uma faixa de freqncia VHF ou UHF de 6 MHz so transmitidas as informaes necessrias para que um televisor consiga reproduzir o que atualmente conhecido como canal. Dessa forma, o que ocorre quando o telespectador troca de canal em televisores analgicos, a sintonia de uma dessas

faixas de freqncia e exibio das informaes audiovisuais transportadas, em PAL-M, no ecr (display) da televiso. A televiso digital por sua vez, parte do seguinte princpio: digitalizao da informao audiovisual para sua difuso. Essa abordagem traz uma srie de vantagens em relao televiso analgica. A primeira com relao possibilidade de se aplicar diversas tcnicas de compresso de vdeo e udio nas informaes a serem transmitidas, ou seja, mais informao significativa pode ser difundida em comparao com a tecnologia atual. A segunda grande vantagem que, como toda informao digitalizada antes da transmisso, qualquer outro tipo de dado digital alm do vdeo e udio tambm pode ser difundido. Dessa forma, possvel a difuso de aplicativos a serem executados no receptor de TV digital. Assim, as portas para a interatividade na televiso digital so abertas. Outras vantagens tambm podem ser citadas: mecanismos de recuperao de erros podem ser aplicados, de forma que pequenas alteraes em alguns bits causados por interferncias no sinal possam ser detectadas e revertidas. Outra caracterstica da TV digital a consistncia da imagem reproduzida no televisor: na TV digital no existe chuvisco ou fantasmas como na televiso analgica: a qualidade da imagem exibida permanece constante at que a ao de interferncias eletromagnticas gere um nmero de erros dentro dos limites possveis de correo. Tal interferncia em um sinal de TV analgico causaria os problemas citados acima. Porm, caso a interferncia sobre o sinal na TV digital ultrapasse esses limites aceitveis, a informao digital a ser tratada pelos decodificadores passa a ser indecifrvel, causando geralmente o congelamento da imagem e a interrupo do som. As principais etapas da construo do sinal digital so ilustradas de forma simplificada na Figura 1.1. A primeira etapa a codificao de vdeo, udio e dados segundo padres adotados por um sistema de TV digital. Todos os sistemas de TV digital abertos (DVB, ATSC e ISDB) adotam o padro MPEG-2 Video (ISO/IEC 138182, 1995). Esse padro de codificao e compresso prev taxas em torno de 4 a 6 Mbits por segundo para um fluxo de vdeo em qualidade SD, ou Standard Definition, que a qualidade similar a de um canal de televiso analgica. O fluxo de dados de sada de cada codificador denominado de fluxo elementar. Dessa forma so produzidos fluxos elementares de udio, vdeo e dados, que so direcionados ao multiplexador, responsvel por multiplexar todos os fluxos elementares em um nico fluxo de bits, denominado fluxo de transporte. Esse mecanismo de multiplexao tambm segue um padro bem definido, conhecido como MPEG-2 Systems: Transport Stream (ISO/IEC 13818-1, 2000), e adotado pelos trs sistemas abertos de TV digital. A Figura 1.1 ilustra apenas um codificador de vdeo, um de udio e um de dados alimentando o multiplexador. Porm, a limitao de quantos fluxos elementares podem ser multiplexados em um mesmo fluxo de transporte determinada pela taxa mxima de entrada (bitrate) do modulador. Apesar da informao ser codificada digitalmente, h a necessidade de uma etapa de modulao para a difuso terrestre, via satlite ou cabo. Na modulao terrestre a ser adotada no Brasil, por exemplo, o fluxo de transporte

modulado na mesma faixa de freqncia de 6 MHz utilizada por um canal na TV analgica.

Figura 1.1: Etapas na construo do sinal digital.

Os parmetros utilizados na modulao determinam a taxa mxima de transmisso, ou seja, a taxa de sada do multiplexador. Geralmente esses parmetros buscam o melhor equilbrio entre uma alta taxa de transmisso e uma significativa robustez no sinal. Em sistemas de difuso terrestre DVB, por exemplo, a taxa de transmisso geralmente utilizada de 19.2 Mbits por segundo. Ou seja, como um fluxo elementar de vdeo MPEG-2 em qualidade SD pode ter uma taxa menor que dessa, e a taxa de um fluxo de udio relacionado ao vdeo relativamente menor, possvel a multiplexao de 4 fluxos de vdeo e 4 de udio em um fluxo de transporte a ser modulado e difundido em uma mesma faixa de freqncia que atualmente ocupado por um nico canal na televiso analgica. Devido a essas caractersticas, a televiso digital traz novas nomenclaturas ao que atualmente conhecido como canal na televiso analgica. Como, em uma mesma faixa de freqncia de 6 MHz ocupado por um canal analgico no Brasil, possvel difundir um ou mais conjuntos de mdias audiovisuais, o conceito de canal por faixa de freqncia torna-se obsoleto: possvel organizar logicamente fluxos de vdeo e udio (e tambm dados) em um fluxo de transporte de forma que eles sejam reconhecidos como canais virtuais pelo set top box, nomenclatura definida pelo ATSC, ou como servios, segundo o DVB. Dessa forma, quando o receptor sintonizar e isolar determinado sinal em uma faixa de freqncia de 6 MHz, ao invs de imediatamente exibir o que seria um canal na televiso analgica, ele deve seguir os passos inversos da Figura 1.1: demodular o sinal,

extraindo dele o fluxo de transporte, e a partir dele determinar os servios ou canais virtuais contidos no mesmo. A seleo de qual servio ser exibido realizada por parte do telespectador. Aps determinado servio ser selecionado, seus respectivos fluxos de vdeo e udio (e em alguns casos dados) so direcionados aos respectivos decodificadores, sendo apresentados ao telespectador, que percebe o servio de forma similar a um canal na televiso analgica.

1.5. Difuso de dados - Datacasting

Na seo anterior foram apresentadas algumas diferenas entre a televiso analgica e a digital. Uma delas a possibilidade de transportar outros tipos de dados digitais no mesmo sinal utilizado para a transmisso de vdeo e udio. A capacidade de difundir dados digitais que no sejam fluxos de udio e vdeo nesse sinal conhecida como datacasting, e o pilar da interatividade na televiso digital. o datacasting que permite s aplicaes e demais dados correlacionados serem transmitidos. 1.5.1. MPEG-2 Systems: Transport Streams Os sistemas abertos de televiso digital adotam o padro MPEG-2 Systems Transport Stream para a multiplexao dos fluxos elementares, como citado anteriormente. Para um melhor entendimento dos mecanismos de datacasting necessrio primeiro compreender como funciona este padro de multiplexao. Primeiramente, podem ser multiplexados dois tipos de estruturas de dados em um fluxo de transporte: os fluxos elementares empacotados (PES - Packetized Elementary Streams) e as sees. Os fluxos elementares empacotados nada mais so que os fluxos gerados pelos codificadores de vdeo e udio (e em alguns casos, dados) divididos em pacotes. Cada pacote contm informaes adicionais (timestamps de sincronismo, por exemplo) a respeito de uma unidade de informao que transporta, como por exemplo, um frame de vdeo ou determinado intervalo de udio. As sees, por sua vez, so estruturas que foram primeiramente utilizadas pelo MPEG-2 Systems para o transporte de tabelas contendo informaes necessrias para a identificao correta de quais servios esto presentes em um fluxo de transporte, assim como seus fluxos elementares. Tais tabelas so conhecidas como PSI (Program Specific Information), e foram estendidas pelos sistemas de TV digital abertos de forma a incorporar mais informaes a respeito dos servios de um determinado fluxo de transporte. As sees possuem uma sintaxe mais simples em relao as PES, e no transportam informaes temporais ou de sincronismo. Tanto as sees como as PES so fragmentadas em pacotes de transporte no processo de multiplexao: esses pacotes de transporte so as unidades fundamentais de um fluxo de transporte. Cada pacote possui um tamanho fixo de 188 bytes. Os primeiros 4 bytes de cada pacote so destinados a um cabealho e os 184 bytes restantes para a carga do pacote. Em algumas situaes, o cabealho de um pacote de transporte pode ser estendido de forma ocupar um nmero varivel de bytes, podendo inclusive preencher os 188 bytes do pacote.

A informao mais importante do cabealho de um pacote de transporte o PID (Packet Identification). Pacotes transportando determinado fluxo de vdeo, por exemplo, contm o mesmo PID, assim como pacotes carregando sees de uma tabela PSI possuem em comum outro valor de PID. Dessa forma, o decodificador pode filtrar os pacotes de determinado PID de forma a reconstruir determinado fluxo elementar ou tabela. A Figura 1.2 ilustra um fluxo de transporte contendo sees e PES multiplexadas. Os pacotes com PID igual a zero contm sees que transportam a tabela conhecida como PAT, ou Program Association Table, uma das PSIs definidas pelo MPEG-2 Systems. A PAT geralmente a primeira tabela alvo dos receptores: ela que contm as informaes bsicas sobre os servios do fluxo de transporte. Os pacotes que transportam a PAT sempre possuem o PID igual a zero. Isso se deve pelo seguinte motivo: quando o receptor comear a tratar um fluxo de transporte, a princpio no vai ter informaes suficientes sobre quais e quantos servios esto presentes no fluxo de transporte, assim como em que pacotes esto sendo transportados seus fluxos elementares. Dessa forma, o ponto de partida do set top box filtrar os pacotes de PID igual a 0 de forma a encontrar a PAT e assim localizar as informaes a respeito dos servios.

Figura 1.2: Exemplo de um fluxo de transporte contendo as tabelas PSI bsicas, assim como fluxos elementares de vdeo e udio.

Caso o servio desejado seja o Servio 2, como ilustra a Figura 1.2, o receptor passa a procurar por outra tabela, nos pacotes de PID 200, indicado pela PAT: a PMT, ou Program Map Table. Todo servio possui uma PMT relacionada, responsvel por indicar quais fluxos elementares fazem parte do servio. Por exemplo, na Figura 1.2, fazem parte do Servio 2 um fluxo de vdeo transportado nos pacotes de PID 201, um de udio nos de 202, e por fim dados nos pacotes de PID 203. A partir desse ponto, o receptor passa a filtrar os pacotes com esses identificadores, reconstruindo os fluxos

elementares a partir da carga dos pacotes, e os direciona aos respectivos decodificadores. 1.5.2. Mecanismos de Datacasting Como j apresentado, o MPEG-2 Systems o padro de fato de multiplexao dos sistemas de TV digital abertos. Dessa forma, os mecanismos de datacasting na TV digital fazem uso das facilidades e estruturas desse padro: existem basicamente quatro mecanismos, ou reas de aplicao (Tektronix, 2002): Data Piping, Data Streaming, MPE ou Multiprotocol Encapsulation e os Carrossis (ETSI TR 101 202, 2003) (ATSC A/91, 2001), sendo esses ltimos divididos em Carrossis de Dados e Carrossis de Objetos. 1.5.3. Data Piping O data piping o mecanismo mais simples de datacasting. Baseia-se na insero de dados brutos diretamente na carga dos pacotes de transporte. A tarefa de um encapsulador de dados nessa abordagem gerar pacotes de transporte, com um valor do PID conhecido pela aplicao destinatria, inserindo os dados nos 184 bytes da carga de cada pacote antes de envi-los ao multiplexador. O receptor, por sua vez, precisa apenas filtrar os pacotes com o PID determinado e extrair de sua carga os dados transmitidos. A vantagem dessa abordagem simplista do data piping reside no baixo custo de hardware e software necessrios para a implementao, e recomendado para solues de datacasting proprietrias. J a desvantagem do data piping a falta de estruturas sintticas mais poderosas para o encapsulamento de dados, problema resolvido nos outros mecanismos de datacasting. 1.5.4. Data Streaming O data streaming por sua vez pode ser definido como uma rea de datacasting onde dados so continuamente empacotados em PES antes de serem difundidos. Ao contrrio do data piping, o data streaming permite datacasting sncrono devido ao uso das estampilhas de tempo no cabealho das PES. Essa a sua grande vantagem em relao as outras formas de difuso de dados. O datacasting via PES, devido a essa capacidade de sincronizao, geralmente empregado em aplicaes que requisitam forte acoplamento dos dados com outros fluxos elementares. 1.5.5. Multiprotocol Encapsulation O Multiprotocol Encapsulation, MPE, empregado no transporte de datagramas de protocolos de rede da terceira camada do modelo ISO/OSI (Tektronix, 2002). A estrutura utilizada para esse transporte denominada de seo de datagrama, derivada das sees privadas, que por sua vez so sees de propsito geral do MPEG-2 Systems (de forma que outros tipos de dados alm de tabelas possam ser difundidos por essas estruturas). Sistemas abertos de TV digital otimizaram a sintaxe das sees de datagrama de forma a facilitar o transporte de datagramas IP. Dessa forma, facilitado o uso do canal de difuso para oferecer servios de internet (downstream).

Staffans (2004) aponta o IP datacasting atravs do MPE como soluo para diversas aplicaes utilizando o canal de difuso da televiso digital, principalmente no que se refere recepo mvel. A grande diferena com relao aos dois meios de datacasting apontados at ento, o data piping e o data streaming reside no fato de que no MPE do tipo IP datacasting os dados podem ser facilmente endereados a um set top box (unicast) ou a grupos de terminais de acesso (multicast). No que isso no seja possvel com os dois tipos anteriores, mas o endereamento, nesse ltimo caso, uma caracterstica intrnseca ao protocolo IP (e conseqentemente, ao IP datacasting). Outra diferena com relao ao data streaming atravs das PES que as sees de datagrama no contm informaes temporais. Dessa forma, qualquer tentativa de sincronizao deve ser de responsabilidade da implementao. 1.5.6. Carrossis Os carrossis, por fim, so protocolos de difuso de dados definidos pelo padro DSM-CC (Digital Storage Media, Command and Control) (ISO/IEC 13818-6, 1996), a sexta parte do conjunto de especificaes MPEG-2. O DSM-CC foi originalmente desenvolvido com o objetivo de fornecer funes semelhantes s presentes em aparelhos de vdeo cassete para o controle de fluxos de udio e vdeo de um fluxo de transporte (Fairhurst, 2005). Posteriormente o DSM-CC foi estendido e dividido em vrias partes, com o intuito de fornecer, entre outras, funes como seleo, acesso e controle de fontes distribudas de vdeo e suporte para a transmisso de dados atravs de fluxos de transporte (Schwalb, 2003) (Morris, 2005). Dividido em vrias partes, o DSM-CC pode ser visto como um conjunto de ferramentas, apresentando vrias configuraes e funcionalidades. Dessa forma, vrios sistemas, como os de televiso digital, adotam apenas algumas de suas partes. Os mecanismos de carrossel de dados e carrossel de objetos do DSM-CC so dois dos mecanismos mais utilizados para a difuso de dados nos sistemas DVB e ATSC. Dessa forma, sero apresentados em mais detalhes nas prximas sees. O protocolo denominado carrossel de dados foi desenvolvido com o intuito de possibilitar a difuso de dados, de forma peridica, para set top boxes. A idia bsica desse protocolo de mdulos de dados difundidos ciclicamente, de modo que, quando o receptor necessitar determinado mdulo, deve apenas aguardar o instante de sua prxima repetio no fluxo de dados. Um mdulo, em um carrossel de dados, definido como um item simples e completo de dados. Por exemplo, um nico arquivo de texto ou vrios outros arquivos de texto podem ser definidos como um mdulo. Cada mdulo dividido em um ou mais blocos, e cada bloco inserido na carga de uma estrutura denominada Download Data Block, ou DDB, que encapsulada em sees privadas. Os carrossis de objetos baseiam-se nas definies dos carrossis de dados, porm passam a tratar a informao na forma de objetos. Para a difuso de dados, dois objetos so de maior importncia em um carrossel deste tipo: objetos do tipo arquivo e do tipo diretrio. Com esses dois tipos de objetos possvel formar um sistema de

arquivo simples. Dessa forma, o set top box pode acessar arquivos de um sistema de arquivos que est sendo difundido em um carrossel de objetos como se os mesmos estivessem disponveis localmente. Devido a essa caracterstica, o carrossel de objetos pode ser definido como um sistema de arquivos de difuso. Os carrossis de objetos so a escolha natural para a difuso de dados delimitados armazenados na forma de arquivos, como ocorre na maioria dos sistemas de arquivos atuais. Dessa forma, tambm a soluo mais empregada na difuso de aplicaes assim como seus recursos.

1.6. Concepo de aplicaes

Como j foi visto, no momento em que a TV interativa quebra os paradigmas da unidirecionalidade da TV e da inrcia do telespectador, ela no representa uma simples evoluo tecnolgica, mas uma nova mdia, com problemas e especificidades diferentes das da TV analgica (Becker e Montez 2005). Uma das principais questes referentes a esse tema o contedo desse meio, que deve passar por um processo de adaptao para conviver com os novos servios oferecidos graas a inmeras revolues e convergncias tecnolgicas, alm da digitalizao da transmisso dos sinais audiovisuais. Mesmo aps quase oito anos da implantao dos primeiros canais digitais de radiodifuso na Inglaterra e parte da Europa, poucas emissoras tm programas interativos na grade de programao. Programas estes ainda com uma interatividade restrita apenas a reao a algum estmulo prvio, com pouca iniciativa por parte do telespectador (Gawlinski 2004). Esse um dos principais motivos pela pouca aceitao inicial da TV digital nos pases em que ela foi implantada, levando com que as pessoas no faam distino entre as novas potencialidades da TV digital interativa e no vejam motivos para adquirir um set top box ou uma TV digital (Maclin 2001). Como a programao interativa ainda uma incgnita, com apostas que vo desde a crena de que a TV interativa no ser mais do que um consumo interativo, at utopias que prevem a total democratizao ou desregulamentao do setor de radiodifuso (Becker et. al. 2004) um estudo mais aprofundado sobre a participao do telespectador na programao da televiso brasileira pode contribuir para clarear alguns pontos da programao dessa nova mdia. Alm disso, torna-se pertinente analisar as iniciativas das emissoras no que se refere a participao direta e indireta do telespectador na programao (Becker e Montez 2004). Isso pode ajudar a delinear que programas a populao gostaria de ver na televiso. A anlise sobre a aceitao por parte do pblico pode ser feita relacionando o tempo em que os programas ficaram no ar e se tiveram uma segunda edio ou segunda temporada. Afinal, para um programa ficar no ar na televiso brasileira, exceo feita TV pblica, pouco representativa do ponto de vista da audincia, preciso uma boa receita publicitria. E os anunciantes s apiam os programas que tm aceitao popular. Apesar dessas indefinies, possvel se espelhar no que deu certo nos pases pioneiros na implantao da TV digital e na histria da TV brasileira para definir o escopo e o alcance das primeiras aplicaes a serem desenvolvidas no pas. Tomando como base que na Europa os principais sucessos esto nas aplicaes especialmente desenvolvidas para televiso, e no simplesmente copiadas da internet, e que no Brasil

quase 90% da populao no tem acesso internet, as aplicaes e servios da TV digital devem estar voltados para pblicos alvo especficos. Apesar de Crocomo (2004) dizer que h um preceito jornalstico segundo o qual a televiso para todos, a maioria dos programas tem pblico alvo bem definido, que pode variar entre faixa etria, poder aquisitivo e formao intelectual e cultural. Uma das poucas excees a essa segmentao da programao est nos programas jornalsticos, principalmente os telejornais, que tem uma abrangncia maior. Esse dado precisa ser levado em considerao quando pensarmos em aplicaes e servios para a TV digital brasileira. Pelos estudos em andamento no contexto do SBTVD, o pas dever ter uma srie de modelos de set top boxes, variando inclusive os recursos disponveis. Para a alfabetizao digital o governo exige que tenham no mnimo interatividade local, o que quer dizer que pode ter set top boxes no mercado sem canal de interatividade. Isso tem impacto direto no desenvolvedor de aplicaes. A mesma aplicao deve ser atrativa tanto para quem tem canal de interatividade de banda larga, linha discada ou mesmo para quem sequer tem canal de interatividade. Portanto, as aplicaes devem ser desenvolvidas com pblico alvo especfico, que varia principalmente segundo o poder aquisitivo de comprar um set top box mais potente e de manter um canal de interatividade. Isso falando em aplicaes. Se estendermos o raciocnio para o desenvolvimento de servios, precisamos englobar ainda as pessoas sem set top box, ou seja, que ainda no tem TV digital, que assistem a televiso pelo sinal analgico. Tendo visto isso, cabe ainda ressaltar a diferena entre TV interativa e internet na TV. Como vimos, em todos os momentos em que se fala em TV, fala-se em udio e vdeo. E at o momento no h nada que indique que na TV interativa v ser diferente. Dessa forma, no existe televiso sem vdeo. A TV interativa agrega inicialmente (no podemos nos esquecer da evoluo das linguagens e da prpria tecnologia) alguns recursos interativos ao vdeo, que passam a interagir com ele. So as aplicaes correlacionadas com o vdeo, que no tem razo de existir seno atreladas a um determinado programa televisivo. Numa evoluo desse tipo de aplicao, espera-se que estas possam se tornar cada vez mais relevantes, com a interatividade e a autonomia sobre o vdeo aumentando consideravelmente. Por outro lado, as aplicaes aqui chamadas de internet na TV so aquelas que atualmente existem da rede mundial de computadores e so simplesmente adaptadas televiso. So descorrelacionadas do vdeo, existindo, portanto, independente dos programas audiovisuais em transmisso. Como vimos na seo 1.3, esse tipo de aplicao no obteve grande sucesso na Europa. Identificados o contexto da concepo dos servios e aplicaes interativos, apresentamos agora algumas caractersticas consideradas essenciais em cada servio e aplicao para TV digital interativa: 1. Realidade nacional o desenvolvedor de aplicaes deve compreender que existem set top boxes com diferentes especificidades e pessoas que vem televiso pelo sinal analgico. 2. Usabilidade avanada a sociedade brasileira pouco alfabetizada, com pouqussimo acesso a computadores pessoais e a internet. Isso requer uma

interface simples e intuitiva, usando a linguagem atual da televiso, conhecida e compreendida por todos. 3. Compreenso imediata a aplicao deve ser imediatamente compreendida como tal pelo usurio, que no a deve confundir com GC ou qualquer outro recurso audiovisual. Quando a mesma for sinalizada ou se aparecer na tela automaticamente, o usurio deve ter cincia de que se trata de uma aplicao interativa e que ele tem a liberdade de interagir ou no. 4. Pblico alvo especfico assistir televiso uma experincia coletiva; interagir com a televiso uma experincia individual. Apenas uma pessoa tem o controle remoto na mo. Alm disso, nem todo mundo que assiste a televiso naquele momento est disposto a interagir. 5. Compreenso do pblico alvo alm de identificar o pblico alvo do servio ou da aplicao, extremamente importante entender o que esse pblico espera de uma aplicao interativa, e caso no espere nada ou desconhea essa nova funcionalidade, o que o atraia interatividade. 6. Agregao de valor informao a aplicao interativa deve trazer uma experincia a mais para o usurio, no possvel com o simples uso do udio e do vdeo. 7. Relevncia e pertinncia o contedo da aplicao deve estar condizente com o servio todo, acrescentando informaes a este, sem destoar do tema central apresentado pelo audiovisual. 8. Curiosidade do usurio o usurio da televiso digital deve se sentir incentivado a interagir, tendo certeza de que ser uma experincia agradvel sob todos os aspectos. Para isso, um dos recursos muito usados o despertar da curiosidade no telespectador, agora usurio, que dessa forma se sente incentivado a participar. 9. Foco no mercado a televiso analgica brasileira custeada pela publicidade. Nada indica que a digital seja diferente. Portanto, a aplicao deve ser interessante o suficiente para atrair anncios para ela prpria ou para o servio no qual est embutida. 10. Ineditismo a aplicao ou o servio no precisam totalmente inditos, uma vez que atingir esse grau de qualidade em todas as aplicaes extremamente difcil. Em todo caso, deve tender para tal, pelo menos em cada situao em que a aplicao ou o servio forem transmitidos, at atingir uma receita de sucesso e manter o programa no ar por mais tempo.

1.7. Arquitetura de set top boxes e middlewares

As sees 1.4 e 1.5 deram os subsdios bsicos para o entendimento das tecnologias de base para a difuso de dados na TV digital. O datacasting serve como base para interatividade no momento em que dados difundidos possam ser usados por aplicaes residentes no set top box, ou possam ser as prprias aplicaes difundidas. Nesta seo sero apresentados os conceitos bsicos necessrios para o incio do desenvolvimento de aplicaes e de como estas se inserem na arquitetura dos sistemas de TV digital.

Um set top box possui arquitetura semelhante de um microcomputador. A princpio, possui uma menor capacidade de processamento e armazenamento, porm conta com componentes de hardware especficos para um ambiente de televiso digital, como sintonizador, demodulador, demultiplexador, decodificadores de mdia, entre outros. Alguns inclusive podem ser implementados por software. A Figura 1.3 ilustra a arquitetura bsica de um set top box sem canal de retorno (ETSI ES 201 812, 2003).

Figura 1.3: Arquitetura bsica de um set top box.

O surgimento desses receptores de TV Digital com capacidade de processamento fez surgir no mercado uma nova atividade: desenvolvimento (ou programao) de aplicaes interativas. Os desenvolvedores desse novo tipo de aplicao, a princpio, teriam de resolver um srio problema. Como no razovel supor-se que todos os receptores digitais ou set top boxes so exatamente iguais, haveria necessidade de implementar diversas verses de aplicaes interativas. Alm disso, essas aplicaes, de alguma forma, precisariam ser difundidas simultaneamente e cada set top box selecionaria a aplicao adequada para ser executada nele. Essa abordagem atrapalharia o desenvolvimento de novos tipos de set top boxes, e seria de difcil implementao. Felizmente, no h necessidade de empregar essa abordagem ineficiente. Sistemas de TV digital interativa adotam uma camada de middleware que esconde as peculiaridades e complexidades no apenas do hardware, mas tambm do sistema operacional, device drivers, softwares e hardwares responsveis pela decodificao do sinal (Figura 1.4). Um middleware intermedeia toda a comunicao entre a aplicao e o resto dos servios oferecidos pelas camadas inferiores. 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.

EPG

T-Gov

T-Commerce

Internet

Jogos interativos API de smart card

API Grfica

API de Canal de retorno

middleware
tecnologias de compresso e modulao Transporte (MPEG-2 TS) sistema operacional, device drivers hardware, dispositivos

Figura 1.4: Middleware como uma plataforma de programao de aplicaes.

Apesar de ser representado na Figura 1.4 como apenas um bloco, um middleware costuma ser formado por uma pilha de softwares. Esses softwares oferecem APIs (Application Program Interface Interface de Programao de Aplicaes, representado na Figura 1.3) padronizadas e, juntos, se constituem em uma plataforma de programao para aplicaes interativas. No final dos anos 1990, quando os principais middlewares comearam a ser definidos, vrias bibliotecas e APIs para aplicaes multimdia e para dispositivos embutidos (embedded) j existiam. Esses padres j existentes foram prontamente adotados pelos middlewares recm-criados. Dentre estes, destacam-se HAVi e DAVIC. Alm disso, simultaneamente houve uma iniciativa da SUN em propor uma biblioteca Java que facilitasse a adoo desse padro em ambientes de TV digital. O JavaTV, resultado desse esforo, tambm foi adotado pelos principais middlewares de TV digital. Esses padres JavaTV, HAVi e DAVIC que ajudam a compor as APIs dos middlewares de TV digital, so descritos a seguir de forma sucinta. 1.7.1. JavaTV Um programa Java que pode ser difundido, recebido, executado remotamente em set top box, em conformidade com a biblioteca JavaTV, recebe o nome de Xlet (Figura 1.5).
As Xlets so recebidas e executam fazendo chamadas padronizadas s APIs

Xlets APIs JavaTV

Gerente de Aplicaes

Mquina Virtual Java (JVM) Sistema Operacional e Hardware Figura 1.5: Xlets, Gerente de Aplicaes e mquina virtual Java.

Para manipular esse tipo de aplicao, o JavaTV prov a API javax.tv.xlet. Outras APIs importantes do JavaTV so: javax.tv.service.guide com facilidades para suportar EPGs; javax.tv.service.selection para selecionar servios ou programas de televiso; e javax.tv.graphics para lidar com grficos. Buscando controlar as Xlets, cada set top box 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), se desejar. Mais sobre Xlets ser visto na seo 1.8.1. 1.7.2. HAVi O HAVi (Home Audio Video Interoperability) um padro especificado por uma organizao homnima, formada por grandes companhias de produtos de consumo audiovisuais. Foi originalmente criado para prover um padro para interoperabilidade entre dispositivos e equipamentos digitais audiovisuais. O objetivo principal era o de facilitar o oferecimento mtuo de servios entre esses dispositivos, tais como TVs, DVD players e DV camcorders. Esse padro foi adotado pelos sistemas de TV digital, principalmente por prover um conjunto APIs com suportes especficos para televiso, tais como funes para lidar com ecrs e grficos de TV. Esses componentes so resumidamente botes, campos de textos, campos de entrada de textos, dentre outros, que facilitam o desenvolvimento das interfaces interativas das aplicaes. 1.7.3. DAVIC DAVIC (Digital Audio Visual Council), por sua vez, foi uma associao criada em 1994, que teve uma durao de apenas cinco anos, mas que conseguiu agregar 222 companhias espalhadas em 25 pases. A API DAVIC fornece acesso a funcionalidades especficas de um ambiente de TV digital (como filtro de sees, por exemplo), alm do gerenciamento de recursos escassos nesse ambiente (como componentes de hardware especficos). As extenses DVB foram criadas de forma a suprir as necessidades no cobertas por essas outras APIs e detectadas como necessrias no MHP (Multimedia Home Platform). Algumas especificaes do DVB foram fortemente influenciadas pelo DAVIC, tais como o DVBC (padro para transmisso de TV a cabo) e DVB-RCC (canal de retorno por cabo) 1.7.4. MHP, OCAP, DASE e ARIB No final dos anos 1990, o grupo DVB comeou a especificar seu padro de middleware, que, em 2000, deu origem plataforma MHP 1.0 e, abril de 2001, MHP 1.1. O MHP busca oferecer um ambiente de TV interativa aberto e interopervel, para receptores e set top boxes de TV digital. Seu ambiente de execuo baseado no uso de uma mquina virtual Java e APIs JavaTV. Essas APIs possibilitam aos programas escritos em Java o acesso a recursos e facilidades do receptor digital de forma padronizada. Uma

aplicao DVB usando API Java denominada aplicao DVB-J. A especificao MHP 1.1 introduziu a possibilidade de usar uma linguagem de programao semelhante ao HTML denominada DVB-HTML. Aplicaes DVB-J e DVB-HTML possuem a capacidade de fazer download de aplicaes interativas, atravs de um canal de interatividade; armazenar aplicaes em memria persistente (ex. disco rgido); acessar leitores de smart cards; e controlar aplicaes de internet, tais como navegador web. O OCAP (OpenCable Applications Platform) um middleware voltado para sistemas de TV a cabo norte-americano. Sua primeira verso foi liberada em 2001, e seguida pela verso OCAP 2.0, em abril de 2002. Nessa ltima verso houve uma preocupao em definir APIs mais prximas possvel das especificaes MHP. O ATSC, sistema norte-americano, desenvolveu o DASE como sua camada de middleware. De forma similar ao MHP, o DASE adota uma mquina virtual Java como mecanismo que facilita a execuo de aplicaes interativas. Tambm de forma similar ao MHP, o DASE permite o uso de linguagens declarativas, usadas na web, como HTML e JavaScript O middleware do sistema japons ISDB padronizado pela organizao ARIB. Esse middleware formado por alguns padres, como o ARIB STD-B24 (Data Coding and Transmission Specification for Digital Broadcasting) que define uma linguagem declarativa denominada BML (Broadcast Markup Language). Essa linguagem, baseada na linguagem padro de servios web XML (Extensible Markup Language), usada para especificao de servios multimdia para TV digital. Outra especificao do middleware o ARIB-STD B23 (Application Execution Engine Platform for Digital Broadcasting), que baseada na especificao MHP, atravs da adoo do padro GEM, que mostrado na seqncia. 1.7.5. GEM A necessidade de padronizao uma questo recorrente em sistemas computacionais; e em sistemas de TV Digital no diferente. Padronizao facilita a portabilidade e interoperabilidade entre componentes do sistema, reduzindo os custos de sua implantao no mercado. Como exemplo, a adoo padronizada de MPEG-2 TS na camada de transporte, em sistemas de TV digital, no s possibilitou o emprego de componentes de hardware e software j existentes, como tambm facilitou o desenvolvimento, testes e depurao de novos componentes. Desenvolvedores de sistemas que utilizam tais componentes tambm acabam se beneficiando com a reduo de seus riscos, j que muitos destes componentes foram usados e testados ao longo de anos em aplicaes multimdia. Alm disso, caso essa padronizao fosse estendida a outros sistemas de TV digital existentes, em um mbito mundial, esses benefcios tenderiam a se ampliar devido reduo de custos, causada pela maior escala de produo e do aumento da concorrncia. Com a camada de middleware no diferente. A indstria de TV geralmente uma indstria globalizada, e a possibilidade de desenvolver aplicaes interativas e contedo que possam ser portados facilmente em sistemas de diferentes pases um forte atrativo.

A partir da dcada de 1990, com o surgimento dos primeiros sistemas de TV Digital, em um primeiro momento houve um movimento no sentido de cada organizao desenvolver o seu prprio padro de middleware (MHP, DASE, ARIB, OCAP, etc.). Contudo, a identificao de vrias caractersticas em comum, tal como a adoo de APIs de JavaTV, HAVi, etc., e o reconhecimento das vantagens de uma padronizao entre os middlewares levou a diversos esforos no sentido de harmonizar esses padres. Por ser o padro de middleware mais maduro, o MHP foi escolhido como referncia para essa tentativa de estabelecimento de conformidade. Contudo, o MHP possui diversas especificidades do DVB e, por conseguinte, sua utilizao pura e simples no adequada em sistemas de outros pases que adotam, por exemplo, ATSC ou ARIB. Por conseguinte, GEM (Globally Executable MHP) (ETSI TS 102 819 2005) foi criado para facilitar a criao de especificaes de middlewares baseados em MHP. A primeira verso da especificao do GEM, foi publicada em fevereiro de 2003 (GEM 1.0) e atualmente existe uma verso rascunho que foi publicada em maio de 2005 (TS 102 819 V1.2.1, 2005). As especificaes GEM listam partes das especificaes MHP que podem ser encontradas em um mercado especfico. Contudo, ela pode ser substituda onde necessrio, desde que sua funcionalidade seja equivalente original (equivalentes funcionais). Isso necessrio devido s caractersticas especficas de cada sistema. Por exemplo, as tabelas de sinalizao do ATSC so incompatveis com as do DVB. Outro exemplo citado de equivalente funcional o fato do ARIB B.23 usar carrossel de dados do DSM-CC em vez de carrossel de objetos como feito no MHP. importante observar que GEM no simplesmente um subconjunto do MHP. Cada padro de middleware que usa GEM, o faz de forma personalizada, adicionando extenses e, tambm, colocando restries na especificao bsica do GEM (Figura 1.6).

ARIB B.23

ACAP

GEM

MHP

OCAP

.
Figura 1.6: Relacionamento do GEM com os outros middlewares (ETSI TS 102 819 2005).

A Figura 1.6 tambm mostra o ACAP um padro criado com objetivo de tentar harmonizar os sistemas norte-americanos de transmisso terrestre (DASE) e por cabo (OCAP). Essa busca de harmonizao culminou na adoo do GEM como base de implementao desses middlewares.

1.8. Desenvolvimento de aplicaes para TV digital

Como vimos nos captulos anteriores, existem vrias arquiteturas de middleware predominantes no mercado mundial, e cada uma delas com suas prprias peculiaridades. Infelizmente no existe um padro mundial no que diz respeito ao desenvolvimento de aplicaes para televiso digital. Para cada arquitetura uma nova forma de estruturao e, s vezes, um novo padro de desenvolvimento. No entanto, as arquiteturas abordadas neste captulo tm muito em comum, pois todas tm a mesma base tecnolgica: Java e MPEG, e nelas que focaremos a anlise e explicao do desenvolvimento dos aplicativos. As aplicaes para televiso digital podem ser desenvolvidas usando linguagem Java ou HTML, porm a segunda opcional e no suportado por alguns set top boxes. Por este motivo os exemplos deste captulo sero exclusivamente aplicativos escritos em Java. Todavia, o fato da aplicao ser escrita nesta linguagem, no implica que ela seja considerada como uma aplicao Java normal. Aplicaes para TV digital usam um conjunto de APIs diferente, por vezes mais enxutas e com modificaes, e por outras com APIs exclusivas para desenvolvimento para a televiso digital. No contexto da arquitetura de software do ambiente em que a aplicao executa, podemos destacar trs elementos que participam ativamente do processo de execuo de uma aplicao. Todo sistema que capaz de executar aplicaes para TV digital, deve prover um gerenciador de aplicaes, que responsvel por detectar e instanciar uma nova aplicao emitida pelo operador, e disponibilizar para aplicao um contexto, que outro elemento da arquitetura e que ser detalhado mais adiante. O terceiro elemento da arquitetura a prpria aplicao, o foco deste captulo. 1.8.1. Introduo a Xlets Uma aplicao para televiso digital chamada de Xlet. Ela forma o conceito bsico de aplicao em todos os sistemas baseados no JavaTV, como os abordados por este captulo. A idia bsica de uma Xlet funcionar como uma mquina de estados em cima da mquina virtual que a est executando. Desta maneira duas Xlets podem coexistir na mesma mquina virtual sem que uma interfira na outra, bastando para isso um gerenciamento dos estados de cada uma, e neste ponto que o contexto se torna importante neste ciclo. As Xlets implementam a interface 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. Os mtodos da interface a serem implementados, initXlet, startXlet, pauseXlet e destroyXlet, so detalhados mais adiante. Existem quatro estados principais em que uma Xlet pode estar: carregada, parada, em

execuo e destruda. Os estados no carregada e invlido tambm so considerados em alguns contextos. A figura 1.7 mostra a mquina de estados de uma Xlet, com seus possveis estados e os mtodos invocados para que ocorra a transio entre eles.

Carregada initXlet() Pausada startXlet() Em execuo destroyXlet()

Figura 1.7: Ciclo de vida da Xlet.

destroyXlet()

pauseXlet()

Destruda

Inicialmente o receptor recebe a sinalizao de uma nova aplicao, o ciclo de vida da Xlet ento comea e caracterizado como no carregada. A partir deste ponto, o gerenciador da aplicao, que est no receptor, deve detectar a classe principal e criar uma instncia dela. Feito isso, o estado passa a ser caracterizado como carregada. Uma aplicao que j foi carregada est apta a ser inicializada pelo mtodo initXlet, que executa suas tarefas e deixa a aplicao no estado pausada. Neste ponto, a Xlet j est pronta para ser executada, pois j carregou e inicializou todos os elementos que eram necessrios para comear a executar. O mtodo startXlet chamado e a aplicao de fato comea a funcionar. O mtodo destroyXlet chamado toda vez que a aplicao termina suas tarefas. Vejamos a interface Xlet:
Public interface Xlet{ public void initXlet( XletContext ctx ); throws XletstateChangeException; public void startXlet(); throws XletstateChangeException; public void pauseXlet(); public void destroyXlet( Boolean uncondicional); throws XletstateChangeException; }

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 em execuo. durante este estado que a Xlet gerencia seus componentes internos, manipula os objetos previamente criados e est apta a escutar todos os eventos internos e externos a aplicao.

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. Sua condio somente satisfeita se o parmetro condicional for verdadeiro. pauseXlet: Sinaliza a aplicao para esta parar de prover seu servio e entrar para o estado de pausa. initXlet: Mtodo com funo parecida a de um construtor de classe, toda instncia de objetos ou variveis podem ser inicializados dentro do escopo deste mtodo, um container pode ser criado para exibir interfaces grficas ou conexes de rede necessrias podem ser abertas, em outras palavras, prepara a aplicao para ser executada. InitXlet chamado somente uma vez no ciclo de vida da Xlet. neste mtodo que a aplicao recebe como parmetro o contexto. 1.8.2. O XletContext O contexto implementa a interface XletContext que faz parte do pacote Xlet, e de uma maneira geral serve para isolar a aplicao do resto da mquina virtual. Entre outras, o contexto permite a Xlet descobrir informaes a respeito do ambiente de execuo atravs do mtodo getXletProperty(). possvel para o contexto acessar propriedades do sistema em que a aplicao est executando. Grande parte dessas propriedades podem ser usadas por aplicaes desenvolvidas em JavaTV, MHP e OCAP. Vejamos a interface XletContext:
Public interface XletContext{ public static final String ARGS = javax.tv.xlet.args; public void notifyDestroyed(); public void notifyPaused(); public void resumeRequest(); public Object getXletProperty( String key ); }

Tambm possvel ao contexto notificar ao middleware sobre alteraes no estado da Xlet, os mtodos do contexto que tratam desta questo so importantes para o caso de haver mais de uma Xlet executando ao mesmo tempo na mquina virtual do sistema, notifyDestroyed() e notifyPaused() informam ao receptor que controla a aplicao, que ela deseja terminar e parar a execuo, respectivamente, assim, o controlador pode saber exatamente em que estado cada aplicao est e evita que ocorra alguma mudana de estado no permitida. O mtodo resumeRequest() usado para informar ao controlador que a aplicao saiu do estado pausada para entrar em novamente no estado em execuo. 1.8.3. Desenvolvimento de aplicativos Quando se desenvolve aplicaes para televiso digital interativa, sempre se deve ter em mente que Xlets so aplicativos feitos para executar em um ambiente televisivo, onde recursos de imagem, como vdeos e interfaces grficas, reinam e devem ser um dos requisitos melhor aproveitados em uma aplicao. Devido a este fato, daremos nfase na

explicao de recursos e aplicativos que exploram as APIs grficas disponveis para o desenvolvimento. As APIs disponveis para o desenvolvimento de Xlets, como comentado anteriormente, so diferentes das APIs do Java tradicional. No MHP usada uma verso reduzida da API AWT do Java SE, como definida em Java 1.1.8, e juntamente com a API HAVi UI formam o conjunto de recursos grficos de uma Xlet. Para exibio de vdeos a API JMF( Java Media Framework ) da suporte ao padro. O incio da implementao deve estar baseado na classe que implementa a interface Xlet, pois ela a classe inicial da aplicao. Tal classe prov um construtor pblico e sem argumentos, que geralmente no declarado no corpo na classe, pois o gerenciamento feito pelo middleware mais bem aproveitado se as funes do construtor ficarem a cargo dos mtodos initXlet() e startXlet(). O primeiro mtodo a ser chamado depois que a aplicao foi carregada e instanciada o initXlet() , que, como j mencionado, tambm prov o contexto para a Xlet, o XletContext, que passado como parmetro na chamada do mtodo. O mtodo startXlet() pode ser considerado como o par do mtodo pauseXlet(), j que tudo o que um inicia, o outro deve parar e vice versa. Geralmente torna os componentes visuais visveis ao usurio e invocado se deseja que a aplicao comece a executar suas funes. Todos os componentes visuais implementados pelas APIs grficas so apresentados por padro na camada grfica de representao. No MHP existem trs camadas que representam dispositivos de hardware, camada de background, de vdeo e a camada grfica.
Camada de Background

Camada de Vdeo

Camada Grfica

Figura 1.8: Camadas de apresentao no MHP.

A camada de background usada quando se deseja uma imagem esttica que sirva de fundo para a aplicao. A camada de vdeo reproduz o fluxo de vdeo vindo do operador e a camada grfica, que se sobrepe a todas as outras, mostra os componentes grficos que caracterizam uma aplicao. Quando se trabalha em aplicaes desenvolvidas em Java da forma tradicional, geralmente criado um container principal como o java.awt.Frame para podermos inserir componentes grficos e exib-los na tela. Para Xlets, um componente equivalente

ao Frame, a HScene, que serve como um container principal disposto em uma determinada rea da tela, para que componentes grficos sejam 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. Um dos cuidados bsicos ao se desenvolver interfaces grficas para televiso no tamanho da visualizao da tela, uma vez que duas possveis formas sero consideradas, tamanho de tela 4:3 ou 16:9 que corresponde transmisso de alta definio (HDTV High definition television). Muitas vezes a soluo pode ser a de usar uma definio intermediria 14:9, que contemplaria uma razovel visualizao em telas 4:3 e 16:9. Anlise do projeto Em um ambiente de TV digital, onde os recursos de hardware disponveis so mais escassos, deve se levar em conta aspectos como processamento, tamanho da aplicao, e ao fato da aplicao ser acessada por um sistema de carrossel onde a latncia gigantesca. Escolher uma abordagem orientada a componentes tem algumas vantagens, pois componentes so implementados de forma a desempenhar um papel especfico dentro de um sistema e, de certa forma, serem substituveis facilmente. Um componente pode desempenhar vrios servios dentro do sistema, porm isto torna alto o nvel de acoplamento, ou seja, alta dependncia entre os componentes. Estes fatores podem comprometer o fator tempo de processamento, que geralmente crtico, por outro lado, beneficia o fator tamanho e tempo de latncia da aplicao. Para se tomar tais decises, preciso conhecer muito bem a estratgia de gerenciamento das aplicaes feita pelo middleware que pode, por vezes, beneficiar uma estratgia de implementao de baixa latncia e por outras uma estratgia de otimizao de processamento. 1.8.4. Um exemplo Para um primeiro exemplo, normal esperarmos alguma funcionalidade que seja visual para podermos ter certeza do funcionamento da Xlet, no exemplo a seguir faremos o uso de tais recursos, como tambm aplicar alguns dos conceitos vistos at agora e introduzir de forma prtica outros recursos necessrios para se desenvolver uma aplicao para televiso digital. Dividiremos o exemplo a seguir em sees e ao final de cada seo daremos uma breve explicao do cdigo apresentado. Devido ao fato de que o emulador de distribuio gratuita que usaremos para executar as Xlets, o XletView, juntamente com a principal e mais completa ferramenta de emulao de Xlets, IRT, estarem baseadas em MHP, os recursos utilizados sero preferencialmente otimizados para tal, ressaltando que a maior parte dos recursos que sero apresentados podem ser aplicados para qualquer plataforma apresentada neste captulo. Vejamos o exemplo:

public class Exemplo1 extends HContainer implements Xlet, KeyListener{

Declarao da classe que entende HContainer e implementa as interfaces Xlet e KeyListener, o que possibilita para a classe controlar eventos do controle remoto ou de teclado.
private HScene cena; private XletContext ctx; private HStaticText texto; private HDefaultTextLayoutManager manager; private HTextButton botao1, botao2; private Font fonte = new Font("Tiresias",Font.PLAIN,21);

Declarao de todas as variveis da classe, dois botes, um campo de texto, a cena, o contexto e o formato da fonte utilizada na aplicao. recomendado para televiso que a fonte utilizada seja a Tiresias e com um tamanho mnimo 21.
public void initXlet(XletContext context) throws XletStateChangeException { ctx = context; cena = HSceneFactory.getInstance().getDefaultHScene(); setBounds(cena.getBounds()); manager = new HDefaultTextLayoutManager(); }

Este foi o corpo do mtodo initXlet(). Notem que no foi declarado nenhum construtor para classe e que o trabalho que seria realizado por ele foi transferido para dentro do corpo do mtodo initXlet(). Uma parte importante neste trecho de cdigo foi a da obteno da cena. Normalmente a cena precisa ser devidamente configurada para se adaptar as peculiaridades da aplicao, porm usaremos para exemplo a cena default, obtida atravs da HSceneFactory que a entidade responsvel por devolver instncias da cena.
public void startXlet() throws XletStateChangeException { cena.setVisible(false); texto = new HStaticText("", 10,150,700,200,fonte, Color.black,new DVBColor(255, 255, 255, 200),manager ); botao1 = new HTextButton("OK", 200,400,150,50,fonte, Color.white,Color.red,manager); botao2 = new HTextButton("Cancela", 400,400,150,50,fonte, Color.white, Color.blue ,manager); cena.add(this); cena.addBefore(botao1, this); cena.addBefore(botao2, this); cena.addBefore(texto, this);

At este momento foram inicializados os componentes que fazem parte da cena, um campo de texto esttico e dois botes. Note que tais componentes foram adicionados atravs do mtodo addBefore(), este mtodo uma das diferenas entre HContainer e Container. Ele controla a ordem de visualizao na cena, neste caso os componentes devem aparecer na frente do container, para que o fundo pintado por paint(), no se sobreponha aos componentes.
String aux = revelaConfiguracoes(); texto.setTextContent(aux, HState.ALL_STATES); otao1.setVisible(true); botao2.setVisible(true);

texto.setVisible(true); botao1.setFocusTraversal(null, null,botao2,botao2); botao2.setFocusTraversal(null,null,botao1,botao1); botao1.addKeyListener(this); botao2.addKeyListener(this); botao1.requestFocus(); cena.setVisible(true); }

Aqui termina a implementao do mtodo startXlet(), todos os componentes foram ditos visveis atravs do mtodo setVisible(), isto importante para garantir a visualizao deles na tela. Nas linhas seguintes foi definido a navegao entre os botes atravs de setFocusTransversal(), que informa a aplicao qual o componente que deve obter o foco no caso de eventos nos botes direcionais do controle remoto ou teclado. Este mtodo foi derivado de setMove(), que especifica o foco para qualquer ao de controle remoto ou teclado. Tambm foi adicionado um listener a cada boto, para tratar dos eventos gerados por eles.
public void pauseXlet() { System.out.println("Estado de Pausa"); cena.setVisible(false); }

Neste caso, o mtodo pauseXlet apenas torna a cena invisvel, pois nenhum outro recurso precisa ser parado, como alguma thread ou entrada e sada de dados.
public void destroyXlet(boolean arg0) throws XletStateChangeException { System.out.println("Estado de Pausa"); ctx.notifyDestroyed(); } public void paint( Graphics g ){ g.setColor( new DVBColor( 0,0,0,100)); g.fillRect(0,0,720,576); super.paint(g); }

O mtodo paint() muito conhecido em ambientes Java tradicionais. Ele foi mantido na API AWT para TV digital e pode ser muito til para aproveitar todo potencial grfico de uma aplicao. Neste caso ele pinta um fundo preto transparente que permite que a camada de vdeo seja visualizada no para o caso de haver um vdeo em execuo. A transparncia nas cores um recurso muito importante no desenvolvimento das Xlets e pode ser conseguido com a classe DVBColor que possui um parmetro para transparncia, alm dos parmetros RGB normais.
public String revelaConfiguracoes(){ String conf = ""; conf += "Dimensoes da cena: " + cena.getBounds(); conf += "\n" + "Dimensoes do Container: " + getBounds(); conf += "\n" + "Numero de componentes na Cena: " + cena.getComponentCount(); return conf; } public void keyTyped(KeyEvent e) {} public void keyPressed(KeyEvent e) { if( e.getKeyCode() == HRcEvent.VK_ENTER ){ if(botao1.isSelected()){

System.out.println("Acao OK"); } else{ System.out.println("Acao Cancela");} } } public void keyReleased(KeyEvent e) {} }

Os trs ltimos mtodos se referem ao controle de eventos externos. Neste caso necessrio o controle sobre dois botes. Quando o usurio da aplicao apertar o boto do controle remoto que corresponde tecla de confirmao, tecla ok por exemplo, o tratador de eventos deve ser capaz de verificar qual dos botes est com o foco e disparar a ao correspondente.

Figura 1.9: Sada do programa no XletView

1.8.5. Emuladores e ferramentas de desenvolvimento. XletView XletView uma ferramenta de emulao em PC, baseada em Java, para Xlets MHP e est atualmente na verso 0.3.6 e sendo constantemente atualizada. um projeto de software livre licenciado sob a "Gnu Public Licence". Est acessvel para download a partir do site da Fource Forge: http://xletview.sourgeforge.net. Para executar o XletView em um computador recomendvel que voc tenha instalado a Mquina Virtual Java 1.4 ou maior. O XletView usa o JMF2.1.1 (Java Media Framework) para exibio de vdeos e aceita exclusivamente o formato de vdeo AVI (Audio Video Interleaved) compactado com compresso Cinepack.

IRT Middleware baseado na implementao MHP. Por ser usado como middleware em set top boxes, o ambiente de emulao para MHP mais completo do mercado. Foi desenvolvido na Alemanha em parceria com Sua, e pode ser solicitado para download aps o pagamento da licena. Pode ser instalado no PC sob Windows ou Linux para simulao de Xlets MHP. Cardinal Cardinal uma ferramenta de autoria de Xlets. Prov uma maneira simplificada de criao de aplicaes atravs da utilizao de componentes e frameworks. baseado em Java, porm o cdigo gerado fechado. Pode-se obter uma verso para teste no site da desenvolvedora.

1.9. Concluso e continuao dos estudos

Um bom comeo para quem deseja se aprimorar no desenvolvimento de aplicaes para televiso digital ler a bibliografia do captulo, at este momento, um dos livros mais indicados para iniciantes no assunto o livro de Steven Morris. Existem na internet boas fontes de leitura, do bsico ao avanado. No endereo http://interactivetvweb.org/ podese encontrar tutoriais completos sobre televiso digital, MHP, JavaTV e desenvolvimento de aplicaes, incluindo exemplos de cdigo que podem ser obtidos do prprio site. Em (Becker e Montez 2004) pode-se obter uma viso sistmica da televiso digital e a relao das tecnologias envolvidas com a sociedade brasileira. Alm disso, recomendamos tambm o livro O Guia Prtico da Produo de Televiso Interactiva, de Nuno Bernardo, que faz um apanhado geral dos conhecimentos necessrios para identificar as ferramentas e os meios atrelados ao desenvolvimento de produtos para TV interativa. Para ver exemplos do que est sendo produzido pelo mundo afora, um bom site Broadband Bananas (http://www.broadbandbananas.com), que tem uma srie de exemplos de aplicativos produzidos pelas principais emissoras de televiso digitais. Tambm altamente recomendvel uma leitura nas APIs disponveis, como a HAVi e a DAVIC, para ter noo do que possvel ser feito em um ambiente de televiso. Voc pode desenvolver seus aplicativos em alguma IDE Java como o Eclipse (www.eclipse.org), e importar as bibliotecas necessrias, neste caso, importante verificar a API disponvel, que diferente da de Java tradicional, e simul-las em um dos emuladores disponveis, Xletview (http://xletview.sourceforge.net/) e OpenMHP (www.openmhp.org) so boas opes de cdigo livre e podem ser facilmente achadas na internet e integradas ao Eclipse. Mais informaes sobre datacasting pode ser encontrada em trabalhos acadmicos, como (Piccioni 2005) e (Staffans 2004). O primeiro detalha os mecanismos de carrossis de dados e de objetos, assim como implementa um prottipo fim a fim de transmisso de dados. J o segundo introduz o IP Datacasting, que est servindo como base para a difuso de dados em sistemas de TV digital mveis como o DVB-H.

Referncias
Agncia Estado. Web 2. fonte de informaes para universitrios. Disponvel em <http://www.estadao.com.br/educando/noticias/2005/ago/17/93.htm>. Acesso em 4/10/05. ATSC A/91 - Advanced Television Systems Committee. ATSC Recommended Guidelines for the ATSC Data Broadcasting Standard, 2001. BBC, BRITISH Broadcast Corporation. Progress towards achieving digital switchover: a BBC report to the Government. BBC, Londres, 2004. BECKER, Valdecir e MORAES, ureo. Do analgico ao digital: uma proposta de comercial para TV digital interativa. In: III Simpsio Catarinense de Processamento Digital de Imagens. 2003, Florianpolis, 2003. BECKER, Valdecir; VARGAS, Rafael; GUNTER FILHO,; MONTEZ, C. B. Jri Virtual I2TV: Uma Aplicao para TV Digital Interativa baseada em JavaTV e HyperProp. In: WEBMDIA 2004, Ribeiro Preto. 2004. BECKER, Valdecir; MONTEZ, Carlos. TV Digital Interativa: conceitos e tecnologias. In: Minicursos Webmidia 2004. Ribeiro Preto, 2004. BECKER, Valdecir e MONTEZ, Carlos. TV digital interativa: conceitos, desafios e perspectivas para o Brasil. Editora da UFSC, Florianpolis, 2005. BERNARDO, Nuno. O guia prtico da produo de televiso interactiva. Centro Atlntico, Porto, 2002. BIAL, Pedro. Roberto Marinho. Jorge Zahar Editor, Rio de Janeiro, 2005. CASTELLS, Manuel. A sociedade em rede: a era da informao: economia, sociedade e cultura. Paz e Terra, So Paulo, 2003. CROCOMO, Fernando Antonio. TV digital e produo interativa: a comunidade recebe e manda notcias. Trabalho apresentado ao Programa de Ps-graduao em Engenharia de Produo da Universidade Federal de Santa Catarina para o exame de qualificao, requisito parcial para obteno do ttulo de doutor em Engenharia de Produo. Florianpolis, 2004. ETSI ES 201 812 V1.1.1 - European Telecommunications Standards Institute. Digital Video Broadcasting: Multimedia Home Platform Specification 1.0.3, 2003. ETSI TS 102 819 V1.2.1 - GEM Globally Executable MHP: A Guide to Platform Harmonisation, DVB Project Office White Paper on iTV Platform Harmonisation, May 2005. ETSI TR 101 202 - European Telecommunications Standards Institute. Digital Video Broadcasting: Implementation guidelines for Data Broadcasting, 2003. FAIRHURST, G. Data transmission using MPEG-2 and DVB, 2005. URL http://www.erg.abdn.ac.uk/research/future-net/digital-video/dsm-cc.html. ltimo acesso em 3 de outubro. GAWLINSKI, Mark. Interactive television production. Oxford, Focal Press, 2003.

ISO/IEC 13818-2 - International Organization for Standardization. Coding of Moving Pictures and Associated Audio MPEG-2 Video, 1995. ISO/IEC 13818-1 - International Organization for Standardization. Coding of Moving Pictures and Associated udio - MPEG-2 Systems, 2000. ISO/IEC 13818-6 - Organization for Standardization. Coding of Moving Pictures and Associated Audio- Extension for Digital Storage Media Command and Controls, 1996. LORDO, Joo. Era uma vez... a televiso. Alegro, So Paulo, 2000. MACLIN, Bem. What Every Marketer Needs to Know about iTV. New York, eMarketer Analyst Brief, 2001. MACHADO, Arlindo. A televiso levado a srio. Senac So Paulo, So Paulo, 2003. 3 edio. MORRIS, Steven and Smith-Chaigneau, Anthony Interactive television Edited by Elsevier Inc., United States, 2005. standards,

MORRIS, S. MHP interactive, 2005. URL http://www.mhpinteractive.org/tutorial/mhp/index.shtml. ltimo acesso em 3 de outubro. NIELSEN, Jakob. Projetando websites. So Paulo, Campos, 2000. PAGANI, M., Multimedia and Interactive Digital TV: Managing the Opportunities Created by Digital Convergence. IRM Press, 2003. PICCIONI, C. A., Modelo e Implementao de um Servio de Datacasting para Televiso Digital. Dissertao de Mestrado, Universidade Federal de Santa Catarina, 2005. PICCIONI, Carlos A; BECKER, Valdecir; MONTEZ, Carlos; VARGAS, Rafael. Juri virtual: uma aplicao de governo eletrnico usando televiso digital interativa. In: IV Simpsio Catarinense de Processamento Digital de Imagens. 2003. Florianpolis, 2003. SCHWALB, E.M. iTV Handbook: Technologies and Standards. Prentice Hall PTR, 2003. SRIVASTAVA, Hari Om. Interactive TV technology and markets. Boston: Artech House, 2002. STAFFANS, L. Internet protocol datacasting, a technology overview. Masters thesis, Helsinki University of Technology, 2004. Sun Microsystems, Programmers Guide, Santa Clara, California, 2002. Tektronix. A Guide to MPEG Fundamentals and Protocol Analysis, 2002. URL http://www.tek.com/Measurement/App_Notes/25_11418/eng/25W_11418_4.pdf. ltimo acesso em 3 de outubro. WHITAKER, Jerry. Interactive Television Demystified. McGraw-Hill, Nova York, 2001.