aplicaÇÃo dos padrÕes mpeg-7 e mpeg-21 em tv digital
DESCRIPTION
O objetivo deste trabalho é o estudo da plataforma de televisão digital para o desenvolvimentode uma aplicação de loja virtual que faça uso dos padrões MPEG-7 e MPEG-21. Estaaplicação de televisão digital servirá como uma ligação entre os elementos do padrão MPEG-7, utilizado para gerar metadados sobre arquivos multimídia, e os elementos do padrãoMPEG-21, que servirá para o encapsulamento e o controle de acesso à arquivos multimídia.A aplicação será desenvolvida com o uso da API Java TV, por causa da sua alta portabilidadeentre sistemas de televisão digital, e também com o emulador XleTView, que será utilizadopara testar as aplicações durante o processo de desenvolvimento. Ao final deste estudo, seráfeita uma análise da viabilidade de implantação desta aplicação na plataforma de televisãodigital.TRANSCRIPT
UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA
Trabalho de Graduação Interdisciplinar
Paulo Henrique Martins e Roger Tadeu dos Santos
Aplicação dos Padrões MPEG-7 e MPEG-21 em TV Digital
São Paulo 2007
PAULO HENRIQUE MARTINS E ROGER TADEU DOS SANTOS
APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL
Trabalho de Conclusão de Curso de Ciência da Computação da Universidade Presbiteriana Mackenzie, apresentado como requisito parcial para a obtenção do Grau de Bacharel em Ciência da Computação.
ORIENTADOR: Prof. Dr. Ismar Frango Silveira
São Paulo 2007
UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA
CIÊNCIA DA COMPUTAÇÃO
Termo de Julgamento de Defesa de Trabalho de Graduação Interdisciplinar Aos trinta dias do mês de novembro na Universidade Presbiteriana Mackenzie, presente a
Comissão Julgadora, integrada pelos senhores Professores, abaixo discriminados, iniciou-se a
apresentação do Trabalho de Graduação Interdisciplinar do Grupo de Trabalho formado pelos
alunos abaixo e concluída a argüição, procedeu-se ao julgamento na forma regulamentar,
tendo a Comissão Julgadora atribuído às seguintes notas aos Candidatos.
Título do Trabalho: Aplicação dos padrões MPEG-7 e MPEG-21 em TV Digital
ALUNOS Número Matrícula
Média da Banca
Nota Orientador Média Desconto
por atraso Nota Final
Paulo Henrique Martins 3040296-4
Roger Tadeu dos Santos 3042936-6
COMISSÃO JULGADORA NOTA
Orientador Ismar Frango Silveira Titular 1 Titular 2 Suplente
Média Obtida pelo Grupo de Trabalho Para constar, é lavrado o presente termo que vai assinado pela Comissão Julgadora e pelo Coordenador de TGI. São Paulo, Comissão Julgadora ____________________________________________________________ Professor ____________________________________________________________ Professor ____________________________________________________________ Professor Coordenador de TGI ____________________________________________________________ Professor
Aos nossos pais, amigos e a todos aqueles que apoiaram no desenvolvimento deste trabalho.
AGRADECIMENTOS
Agradecemos a todos aqueles que nos deram força, acreditaram em nosso potencial e
contribuíram, direta ou indiretamente para o desenvolvimento deste trabalho.
A todos os professores do Mackenzie que sempre atenderam nossas dúvidas de forma
atenciosa sempre que precisamos.
Ao nosso orientador Ismar Frango que sempre nos atendeu e guiou com muita
paciência desde o princípio.
RESUMO
O objetivo deste trabalho é o estudo da plataforma de televisão digital para o desenvolvimento
de uma aplicação de loja virtual que faça uso dos padrões MPEG-7 e MPEG-21. Esta
aplicação de televisão digital servirá como uma ligação entre os elementos do padrão MPEG-
7, utilizado para gerar metadados sobre arquivos multimídia, e os elementos do padrão
MPEG-21, que servirá para o encapsulamento e o controle de acesso à arquivos multimídia.
A aplicação será desenvolvida com o uso da API Java TV, por causa da sua alta portabilidade
entre sistemas de televisão digital, e também com o emulador XleTView, que será utilizado
para testar as aplicações durante o processo de desenvolvimento. Ao final deste estudo, será
feita uma análise da viabilidade de implantação desta aplicação na plataforma de televisão
digital.
Palavras-chave: Televisão Digital, MPEG-7, MPEG-21, Metadados, Interação Humano-Computador
ABSTRACT
The goal of this work is to study the digital television platform for the development of an
online store application that makes use of MPEG-7 and MPEG-21 standards. This digital
television application will be a connection between the MPEG-7 elements, used to generate
metadata about multimedia files, and the MPEG-21 elements, that will serve to encapsulates
and control the access to multimedia files. The application will be developed using the Java
TV API because of it’s highly portability between digital television systems and also with the
XleTView emulator which will be used to test the applications during the development
process. By the end of the study, an analysis will be made to evaluate the implementation
viability of his application in a digital television platform.
Keywords: Digital Television, MPEG-7, MPEG-21, Metadata, Human-Computer Interaction
Lista de Ilustrações FIGURA 1: FOTOS TIRADAS POR EDWARD MUYBRIDGE – QUANDO VISTAS SEQÜENCIALMENTE, DÃO A IMPRESSÃO
DE MOVIMENTO ................................................................................................................................................ 14 FIGURA 2: COMPARAÇÃO ENTRE ÁREA DA TELEVISÃO COMUM (4:3) COM O PADRÃO HDTV (16:9) ...................... 18 FIGURA 3: ETAPAS PARA CONVERTER UM VÍDEO ANALÓGICO EM UM SINAL DE TV DIGITAL .................................. 21 FIGURA 4: PROCESSO DE TRANSMISSÃO E RECEPÇÃO DE DADOS DA TV DIGITAL.................................................... 23 FIGURA 5: ESTRUTURA DO MODELO FUNCIONAL DE UM MIDDLEWARE .................................................................... 29 FIGURA 6: PILHA DE SOFTWARE EM UM RECEPTOR DE TELEVISÃO DIGITAL ............................................................. 34 FIGURA 7: CICLO DE VIDA DE UM XLET .................................................................................................................... 35 FIGURA 8: MODELO DE EXIBIÇÃO DASE .................................................................................................................. 38 FIGURA 9: MODELO DE EXIBIÇÃO ARIB ................................................................................................................... 39 FIGURA 10: EXEMPLO DE ORDEM DE APRESENTAÇÃO EM RELAÇÃO À ORDEM DE CODIFICAÇÃO ............................ 45 FIGURA 11: LOGO MPEG DESCRITO PELA ANOTAÇÃO MPEG-7.............................................................................. 51 FIGURA 12: EXEMPLO DE APLICAÇÃO DE DESCRIÇÃO EM UMA CENA DE VÍDEO, RETIRADO DE (MARTINEZ;
KOENEN; PEREIRA, 2002) .......................................................................................................................... 52 FIGURA 13: ORGANIZAÇÃO DAS FERRAMENTAS DE ACORDO COM A FUNCIONALIDADE .......................................... 54 FIGURA 14: EXEMPLO DO USO DOS ELEMENTOS DA DIGITAL ITEM DECLARATION LANGUAGE .............................. 57 FIGURA 15: IMAGEM DA JANELA DE LOG .................................................................................................................. 62 FIGURA 16: IMAGEM DA XLET EM EXECUÇÃO SOBRE O VÍDEO ................................................................................. 63 FIGURA 17: INTERFACES DE EXIBIÇÃO DE DETALHES E CONFIRMAÇÃO DE COMPRA ................................................ 64 FIGURA 18: INTERFACES DE RESULTADO DA CONFIRMAÇÃO DE COMPRA: SUCESSO E ERRO .................................... 65 FIGURA 19: PACOTE CLIENTE .................................................................................................................................... 66 FIGURA 20: PACOTE DE APRESENTAÇÃO ................................................................................................................... 68 FIGURA 21: PACOTE DE INTERFACE GRÁFICA DA CAMADA DE APRESENTAÇÃO ....................................................... 69 FIGURA 22: PACOTE DE NEGÓCIOS ............................................................................................................................ 71 FIGURA 23:PACOTE DE INGRAÇÃO ............................................................................................................................ 72 FIGURA 24: PACOTE DE DADOS ................................................................................................................................. 74 FIGURA 25: PRIMEIRA PARTE DO DIAGRAMA DE SEQÜÊNCIA DA ATIVAÇÃO DE UM ANÚNCIO ................................. 75 FIGURA 26: SEGUNDA PARTE DO DIAGRAMA DE SEQÜÊNCIA DA ATIVAÇÃO DE UM ANÚNCIO ................................. 76 FIGURA 27: DIAGRAMA DE SEQÜÊNCIA DE UM CENÁRIO DE COMPRA ...................................................................... 77 FIGURA 28: MODELAGEM DO CONTEÚDO DE UM PRODUTO ...................................................................................... 84 FIGURA 29: DIGITAL ITEM DE UM PRODUTO FEITO COM DID E DII .......................................................................... 85 FIGURA 30: REGRA APLICADA À EXIBIÇÃO DE DIGITAL ITEM CONTENDO O VÍDEO DE UM PRODUTO DIGITAL
VENDIDO .......................................................................................................................................................... 86
Lista de Tabelas TABELA 1: COMPARAÇÃO ENTRE OS PADRÕES DE TELEVISÃO DIGITAL ................................................................... 25 TABELA 2: SUPORTE A FORMATOS MULTIMÍDIA DA API JMF .................................................................................. 61
Sumário
INTRODUÇÃO ...................................................................................................................................................... 12
CAPÍTULO 1 – A TELEVISÃO DIGITAL ........................................................................................................ 14 1.1 - SISTEMAS DE TELEVISÃO ............................................................................................................................. 15
1.1.1 - Televisão Analógica ............................................................................................................................ 15 1.1.2 - Televisão Digital ................................................................................................................................. 17
1.2 – PADRÕES DE TRANSMISSÃO DIGITAL ........................................................................................................... 21 1.2.1 - Padrões para Codificação e Compressão .......................................................................................... 21 1.2.2 - Padrão para Multiplexação e Transporte .......................................................................................... 21 1.2.3 - Padrões para Modulação e Transmissão ........................................................................................... 22
1.3 - ARQUITETURA DA TELEVISÃO DIGITAL INTERATIVA .................................................................................. 23 1.4 - PADRÕES DE TELEVISÃO DIGITAL ................................................................................................................. 24
1.4.1 - ATSC (Advanced Television Systems Committee) .............................................................................. 25 1.4.2 - DVB (Digital Vídeo Broadcasting) ..................................................................................................... 26 1.4.3 - ISDB (Integrated Services Digital Broadcasting) .............................................................................. 26 1.4.4 - Padrão Brasileiro ................................................................................................................................ 27
1.5 - MIDDLEWARES ............................................................................................................................................. 28 1.5.1 – Blocos Fundamentais ......................................................................................................................... 30
1.5.1.1 – DAVIC .......................................................................................................................................................... 30 1.5.1.2 – HAVi ............................................................................................................................................................. 31 1.5.1.3 - Java TV API ................................................................................................................................................... 33 1.5.1.4 – Microsoft TV ................................................................................................................................................. 35
1.5.2 - Padrões ................................................................................................................................................ 36 1.5.2.1 – MHP .............................................................................................................................................................. 36 1.5.2.2 – DASE ............................................................................................................................................................. 37 1.5.2.3 – ARIB ............................................................................................................................................................. 38 1.5.2.4 – Ginga ............................................................................................................................................................. 40
CAPÍTULO 2 – MPEG .......................................................................................................................................... 41 2.1 - PADRÕES....................................................................................................................................................... 41 2.3 - MPEG-1 ....................................................................................................................................................... 42 2.4 - MPEG-2 ....................................................................................................................................................... 43
2.4.1 - Camada de compressão ...................................................................................................................... 43 2.4.2 - Camada de Sistemas ............................................................................................................................ 46
2.5 - MPEG-4 ....................................................................................................................................................... 47 2.6 - MPEG-7 ....................................................................................................................................................... 47
2.6.1 - Sistemas MPEG-7................................................................................................................................ 49 2.6.2 - MPEG-7 Description Definition Language ........................................................................................ 50 2.6.3 - MPEG-7 Visual ................................................................................................................................... 51 2.6.4 - MPEG-7 Áudio .................................................................................................................................... 53 2.6.5 - MPEG-7 Multimedia Description Schemes ........................................................................................ 53 2.6.6 - MPEG-7 Description Tools................................................................................................................. 53
2.7 - MPEG-21 ..................................................................................................................................................... 54 CAPÍTULO 3 – DESENVOLVIMENTO DA APLICAÇÃO ........................................................................... 59
3.1 – O EMULADOR .............................................................................................................................................. 59 3.1.1 – Suporte à vídeos .................................................................................................................................. 60 3.1.2 – Modificações no Emulador................................................................................................................. 61
3.2 – A APLICAÇÃO ............................................................................................................................................... 62 3.3 – DESENVOLVIMENTO DA XLET ..................................................................................................................... 65
3.3.1 - Pacote org.tgi.store.view ..................................................................................................................... 66 3.3.2 - Pacote org.tgi.store.presentation ........................................................................................................ 67 3.3.2 - Pacote org.tgi.store.business .............................................................................................................. 71 3.3.3 – Pacote org.tgi.store.integration ......................................................................................................... 72 3.3.4 – Pacote org.tgi.store.data .................................................................................................................... 74 3.3.5 – Pacote de utilidades org.tgi.store.util ................................................................................................ 74 3.3.6 – Diagrama de Seqüência para a ativação de um anúncio .................................................................. 74 3.3.7 – Diagrama de Seqüência para a compra de um produto .................................................................... 76
3.4 – O USO DOS PADRÕES MPEG-7 E MPEG-21................................................................................................ 77 3.4.1 – MPEG-7 .............................................................................................................................................. 78 3.4.2 – MPEG-21 ............................................................................................................................................ 83
CAPÍTULO 4 – CONCLUSÃO E TRABALHOS FUTUROS ......................................................................... 88
12
Introdução Com o surgimento da televisão digital, além do grande avanço na qualidade da
imagem, a interatividade entre a televisão e o telespectador se torna possível, fazendo com
que este, passe a ser um usuário, permitindo a criação de diversas funcionalidades que não
eram possíveis com o uso da televisão analógica.
A idéia do trabalho é o desenvolvimento de uma aplicação para a televisão digital que
funcionasse como uma loja virtual, na qual fossem exibidos anúncios para os produtos em um
canto da tela, buscando não interferir na programação que estaria sendo exibida em
determinado momento. Em uma situação ideal, o produto que estivesse sendo anunciando na
loja virtual, teria alguma relação com a programação, para incentivar o usuário, que
possivelmente poderia ver o produto em uso antes de mesmo de comprá-lo.
O uso das funcionalidades de interatividade desta plataforma permite que o usuário
compre aquilo que está vendo e também que ele veja o produto em uso no próprio programa
de televisão ou através de vídeos adquiridos em tempo real, fotos do produto, entre outros.
Desta forma abre-se a possibilidade de emissoras de televisão e lojas interessadas em formar
parcerias, obterem outra fonte de renda, trazendo a ação da compra para uma nova plataforma,
explorando as novas funcionalidades que são oferecidas, e sem interromper a programação da
emissora.
Seria uma grande diferença em comparação à televisão analógica, onde grande parte
do lucro das emissoras é proveniente de propagandas e anúncios que são intercalados com a
programação da emissora, interferindo assim, em sua exibição. Assim, interagir com a
televisão digital ficaria muito mais parecido com o que é possível evidenciar em websites
acessados por computadores, onde o usuário pode navegar pela propaganda, obter mais
informações sobre ele, ver mais fotos e comprá-lo.
Há uma dificuldade também em não deixar essa propaganda ser invasiva demais,
interferindo o programa de televisão. No momento da compra, também seria necessário um
código de segurança para garantir que é o usuário responsável pelo acesso a loja virtual que
está efetuando a compra. Essa segurança é útil também para famílias, impedindo que crianças
comprem produtos sem o conhecimento dos pais.
A aplicação que será desenvolvida neste trabalho, focará no uso dos padrões MPEG-7
e MPEG-21. Estes padrões conterão todas as informações necessárias para a exibição do
anúncio, porém, é necessário o desenvolvimento de uma aplicação para televisão digital
baseada na JAVA TV API, já que os STBs desenvolvimentos até o presente momento não
13
possuem suporte à tais padrões. Esta aplicação realizará a integração entre os padrões MPEG
e o programa de televisão sendo exibido, além de operações como sincronização de anúncio,
entre outras. Será apresentada toda a parte relativa à engenharia de software desta aplicação, e
também os modelos propostos para utilização dos padrões MPEG-7 e MPEG-21.
O uso desses padrões MPEG é um grande desafio, uma vez que há poucos estudos já
realizados com a utilização dos mesmos, pois estão parcialmente definidos ou sujeitos a
alterações devido ao crescente desenvolvimento da plataforma de televisão digital e outros
dispositivos multimídia.
14
Capítulo 1 – A Televisão Digital O local onde hoje se encontra a Universidade de Stanford na Califórnia, já foi um dia
uma fazenda pertencente a um milionário chamado Leland Stanford. Apaixonado por cavalos
de corrida, Leland se sentia perturbado por uma questão: Os cavalos, quando trotam, tiram as
quatro patas do chão ao mesmo tempo ou não? Intrigado, Leland Stanford contratou, em
1872, o cientista Edward Muybridge para resolver a questão. O cientista então instalou 12
câmeras fotográficas rudimentares, uma na frente da outra, que eram disparadas
seqüencialmente, acompanhando o movimento do cavalo.
Figura 1: Fotos tiradas por Edward Muybridge – quando vistas seqüencialmente, dão a impressão de movimento
As fotos comprovaram que os cavalos tiram as quatro patas do chão ao mesmo tempo
durante o trote. Mas acabaram ficando famosas pela idéia de movimento que dão quando
vistas seqüencialmente. Mais tarde, iriam inspirar os estudos de outros inventores, como o
fisiologista francês Étienne-Jules Marey, que inventou em 1887, a cronofotografia. Ou
Thomas Edison, inventor do filme perfurado e do cinetoscópio em 1890. Em 1895, os irmãos
Auguste e Louis Lumiere inventaram o cinematógrafo – uma ancestral das filmadoras como
conhecemos hoje.
Assim como o vídeo, a televisão também não pode ser atribuída a um só inventor. Em
fevereiro de 1924, John Logie Baird faz a primeira demonstração de televisão analógica. O
sistema completo, com a transmissão analógica surgiu pouco depois, em 1927, demonstrado
por Philo Farnsworth.
A partir de 1935, a televisão passou a ser oficialmente transmitida na Alemanha e na
França, sendo a Torre Eiffel o principal posto transmissor francês. A rede inglesa BBC foi
15
fundada em 1936. Londres, na época, usava imagens com definição de 450 linhas. Uma das
primeiras grandes transmissões foi a dos jogos olímpicos de Berlim, em 1936. Durante a
Segunda Grande Guerra, a Alemanha foi o único país europeu que manteve suas transmissões
no ar. As transmissões em Paris só voltariam em outubro de 1944, e em Londres, somente em
junho de 1946, com a exibição, pela BBC, do desfile da vitória.
Apesar das primeiras imagens coloridas terem sido realizadas em 1929, por Hebert
Eugene Ives, as transmissões regulares em cores só começaram em 1954, nos Estados Unidos,
através da rede NBC. Nessa época que surgiu o padrão NTSC (National Television Standards
Comittee), para decidir como a exibição da transmissão a cores seria feita e de modo a não
inutilizar os 10 milhões de aparelhos em preto e branco da época.
No Brasil, a primeira transmissão foi realizada na década de 1950, pela TV Tupi,
primeiro canal de televisão do país, fundado por Assis Chateaubriand. A primeira transmissão
em cores no Brasil só veio a ocorrer em 1962.
1.1 - Sistemas de Televisão
1.1.1 - Televisão Analógica
Para que seja possível compreender as melhorias e novas funcionalidades disponíveis
na televisão digital é necessário saber mais sobre o funcionamento da televisão analógica.
Há 3 padrões de televisão analógica disponíveis em larga escala atualmente, e que
lentamente estão sendo substituídos por sinais digitais: NTSC (National Television System
Committee), PAL (Phase Alternation Line) e SECAM (Séquentiel Couleur Avec Memoire).
Tais padrões especificam número de linhas horizontais e verticais (quantidade de pontos),
número de quadros exibidos por segundo, em resumo, a qualidade da imagem sendo
transmitida. Nestes 3 padrões, a proporção da imagem exibida é de 4:3.
O padrão NTSC é utilizado nos países da América do Norte, alguns países da América
Central e do Sul, Japão, etc. O vídeo é composto por 30 quadros por segundo e com 525
linhas horizontais. Já o padrão SECAM é utilizado na França e em alguns de seus países
vizinhos, utilizando 25 quadros por segundo e 625 linhas horizontais. Similarmente ao
SECAM, o padrão PAL também usa 25 quadros por segundo e 625 linhas horizontais e é
adotado na Europa ocidental e no Brasil, entre outras regiões. Com as 100 linhas a mais, a
resolução da imagem nos padrões PAL e SECAM é maior, dando mais nitidez e detalhes aos
quadros do que o padrão NTSC é capaz de fornecer.
Todos estes padrões usam uma técnica para redução do efeito flickering (cintilação na
tela perceptível aos olhos humanos), que consiste em dividir os quadros em dois conjuntos,
16
combinando as linhas pares e as linhas ímpares em cada um (Fischer, 04). Essas linhas são
transmitidas seqüencialmente de forma entrelaçada, resultando em uma taxa de atualização de
quadros mais rápida, dobrando a quantidade de quadros por segundo. Desta forma, o padrão
NTSC consegue exibir 60 quadros por segundo enquanto os padrões PAL e SECAM
conseguem uma taxa de 50 quadros por segundo. Em ambos os casos, a transiçao de quadros
segundo a segundo torna-se mais suave aos olhos humanos, dando melhor sensação de
movimento da imagem (Zimet, 2002).
Houve ainda padrão de televisão analógica, o MUSE (Multiple sub-nyquist sampling
Encoding system), desenvolvido pela NHK (Nippon Hoso Kyokay) nos anos 80, que usava
uma técnica de filtragem do sinal para diminuir a banda utilizada, e com isso, poder aumentar
a qualidade da imagem. Seu nome comercial era Hi-Vision. Este padrão utilizava transmissão
via satélite e possuía 1125 linhas de definição e proporção de 1.66:1, o que o difere bastante
das outras opções em televisão analógica. Ainda assim, este padrão possuía imagem um tanto
borrada, mas pode ser considerado um grande avanço tecnológico para a época. O Japão
anunciou que as transmissões com este padrão seriam encerradas em meados de 2007.
Em todos os padrões apresentados, algumas linhas não são visíveis, nos padrões com
625 linhas, 50 linhas não são visíveis, nos padrões com 525 linhas, entre 38 e 42 linhas não
são visíveis e no padrão de 1125 linhas, 90 ou 55 não são visíveis. As linhas restantes servem
para sincronismo ou funcionalidades extras como closed caption (Fischer, 2004).
Na televisão analógica dois sinais são responsáveis pela imagem: o sinal de
luminosidade e o de croma. O sinal de luminosidade define o brilho e o contraste da imagem,
enquanto o croma fica responsável por torná-la colorida a imagem. Esta separação faz com
que televisões antigas monocromáticas ainda sejam compatíveis com sinal de televisão
analógica com imagem colorida.
A transmissão do sinal da televisão analógica ocorre através de ondas aéreas enviadas
por uma estação de televisão, em determinadas freqüências, que são pré-estabelecidas. Um
sinal de televisão analógica, composto por som e vídeo, necessita de uma banda de 6 MHz
para ser transmitido. Estas freqüências são organizadas em bandas da seguinte maneira:
• 54 a 88 MHz para os canais VHF 2 a 6
• 174 a 216 MHz para os canais VHF 7 a 13
• 470 a 890 MHz para canais UHF 14 a 83
Dentro desses canais, o vídeo é transmitido em um sinal AM, de amplitude modulada,
e o áudio é transmitido em um sinal FM, de freqüência modulada.
17
A qualidade da imagem na televisão analógica é limitada não só devido à tecnologia
da época, que não disponibilizava aparelhos de televisão com alta definição, mas também pela
falta de uma alta compressão dos dados. Na citação a seguir, o autor previa a necessidade de
utilizar-se compressão no sinal de televisão, visando um avanço da tecnologia, que já estava
em estudo desde aquela época (Lynch, 1985). “Broadcast television will still be analog as it arrives at the home receiver, but along the transmission
path from the studio transmitter to the home receiver a digital link will be used, such as is a communications
satellite link, and herein will be a logical place for compression.”
1.1.2 - Televisão Digital
As pesquisas em torno do desenvolvimento de uma televisão digital iniciaram-se em
1970 pelos cientistas da Sony e da NHK (Nippon Hoso Kyokay), uma empresa de transmissão
televisiva do Japão, com o intuito de melhorias na qualidade de áudio e vídeo das
transmissões, de forma a tentar alcançar a qualidade de um filme de 35 mm. Nasce aí o
conceito de HDTV - high definition television - um formato de televisão onde o número de
linhas que compõem as imagens é altamente ampliado. Logo se viu, entretanto, que essa
tarefa não seria simples. Um único canal de 6 MHz não iria suportar o tráfego da programação
nessa qualidade. A solução só chegaria na década de 90, com a criação de um padrão de
compressão de vídeo que está em uso até hoje, o MPEG, que significa Moving Picture
Experts Group. Fazendo uso de sofisticadas técnicas de compressão, foi possível obter um
vídeo com uma qualidade muito boa em um tamanho muito menor.
A grande diferença da televisão digital está justamente na forma de transmissão,
digitalizada. A televisão, como é transmitida hoje em dia, faz uso de um sinal analógico,
transmitidos pelo ar em ondas eletromagnéticas que ocupam completamente uma freqüência
de 6 MHz. A transmissão digital continuará usando esse espaço de 6 MHz, transmitindo os
canais pelo ar. A diferença é que os dados passam a ser digitalizados. Isso permite um uso
melhor da mesma faixa de freqüência, através da compressão do conteúdo, permitindo o
tráfego de até 19 Mbits/segundo. Dessa forma, será possível que uma emissora transmita, por
exemplo, até 4 programações distintas. Mas ela pode ocupar esse espaço com imagens, áudio
e dados, por exemplo. A própria emissora é quem define o que será transmitido.
A digitalização permitirá um transporte maior de informações, e, com isso, o vídeo e o
áudio poderão possuir uma melhor qualidade. A começar pelo tamanho da tela de vídeo. Hoje
em dia, usa-se a proporção 4:3, entretanto, com a difusão das televisões widescreen e com a
18
melhoria da qualidade dos vídeos transmitidos, a resolução 16:9, com proporções de cinema,
tende a se tornar padrão.
Figura 2: Comparação entre área da televisão comum (4:3) com o padrão HDTV (16:9)
O vídeo transmitido na maior qualidade, recebe o nome de HDTV (High Definition
Television). Com tela em formato 16:9, usa áudio estéreo 5.1 e qualidade de imagem que
pode ser de 720 linhas x 1280 pixels/linha ou 1080 linhas x 1920 pixels/linha. O vídeo no
formato EDTV (Enhanced Definition Television) também segue padrão de 16:9 e áudio 5.1,
porém o tamanho da tela é bem inferior, sendo de 480 linhas x 720 pixels/linha. É
considerado o padrão médio entre o HDTV e o SDTV (Standard Definition Television), o
formato padrão, com resolução 4:3, tela de tamanho 480 linhas x 680 pixels/linha e 60
quadros por segundo. Além desses, ainda há o LDTV (Low Definition Television), um padrão
voltado para dispositivos móveis. Com 30 quadros por segundo, o LDTV possui tela com
tamanho de apenas 240 linhas x 320 pixels/linha (Fernandes et al., 2004).
A transmissão de dados também irá permitir uma maior interatividade do usuário com
a televisão. Ele poderá votar em enquetes realizadas pelos programas, saber mais informações
da atração ou da programação do canal e até mesmo comprar produtos relacionados com o
que estiver sendo transmitido.
Por esse motivo a televisão digital não deve ser encarada como apenas uma melhoria
da televisão analógica, e sim como uma mudança de paradigma. Ela é uma nova plataforma,
com novas funcionalidades e com potencial para revolucionar a forma que a sociedade assiste
televisão, pois adicionará interatividade.
Diversas tecnologias têm surgido nos últimos anos de forma a tentar reproduzir, na
televisão analógica, as vantagens que a televisão digital trará. Empresas de transmissão de
19
canais pagos já possuem suas versões digitais que exibem dados sobre a programação para os
telespectadores. A LG lançou recentemente uma televisão que contém internamente um disco
rígido de 80GB que consegue gravar a programação para ser exibida posteriormente.
Nos Estados Unidos há uma espécie de televisão interativa chamada TiVo (Gartner,
2005). Trata-se de um aparelho instalado no televisor que permite não só que os usuários
gravem e assistam seus programas favoritos na hora que quiserem, mas também que criem
uma programação de acordo com seus gostos. É possível, por exemplo, criar um canal só de
desenhos. O aparelho se encarrega de verificar a programação dos canais disponíveis e gravar
o que se adequar aos filtros definidos pelo próprio usuário. Através de uma linha telefônica, o
TiVo também se conecta à internet. Dessa forma, ele consegue trazer para a televisão
informações personalizadas pelo usuário.
Algumas promessas da televisão digital já são uma realidade em alguns lugares do
mundo, mas são conseguidas através de aparelhos anexados às televisões com HDs internos
para armazenamento dos vídeos e que assim, conseguem simular essa tecnologia que está por
vir, na trasmissão analógica convencional. A televisão de alta definição, por sua vez, também
já é uma realidade no Japão, onde, em 1º de dezembro de 2000, a NHK, que iniciou as
pesquisas da tecnologia, fez a primeira transmissão em HDTV. Entretanto há elementos que
ainda não conseguem ser reproduzidos com a transmissão analógica. Principalmente no que
diz respeito à interação do usuário com o que está sendo transmitido.
Com a transmissão digital, será possível o envio de diversos canais de vídeo e áudio.
Assim, será possível escolher se o filme será transmitido dublado ou legendado, e ainda o
idioma das legendas. Em um show ou jogo de futebol, haverá a disponibilidade de vários
ângulos de câmera para que o telespectador escolha a que mais lhe agradar. A interatividade
estará presente na própria programação, mesmo sem a necessidade de envio de um sinal de
retorno, ou seja, informação vinda das casas dos telespectadores à emissora. Para uso de todas
as funcionalidades prometidas pela televisão digital, entretanto, é necessária a existência de
uma forma de retornar o sinal. O consenso atual é que a forma escolhida seria a internet. A
televisão - ou o Set-Top-Box, aparelho que reproduz o sinal digital nos televisores
convencionais - teria que ser conectado à linha telefônica, ou a redes domésticas conectadas à
internet.
Há três formas de transmissão do sinal: transmissão terrestre, através de cabo ou a
transmissão via satélite. No caso do cabo, esse retorno do sinal pode ser realizado sem o uso
da internet. O cabo já vem sendo usado há algum tempo na televisão analógica e suporta
atualmente uma banda de até 550 MHz. Nos sistemas de transmissão analógica via cabo
20
atuais, o sinal é embaralhado e decodificado nas residências. O embaralhamento é feito para,
por exemplo, limitar a quantidade de canais de um usuário. Um sinal é inserido na
transmissão, levemente deslocado da freqüência e o sinal é retirado com o uso do
decodificador. A televisão digital utiliza uma forma mais segura que o embaralhamento: a
codificação. O sinal é enviado codificado e decodificado nas residências através do uso de
uma chave apropriada. Caso não haja chave para decodificação, ao invés de um sinal
embaralhado, a televisão pode exibir propagandas ou uma tela qualquer. O sistema de
transmissão via cabo, porém, apresenta grandes desvantagens, como o alto custo e a
dificuldade de implantação em regiões remotas, bem como sua disseminação local.
Para essas regiões mais afastadas das grandes cidades, a transmissão por satélite
apresenta uma ótima solução. Ela é eficaz porque o satélite possui uma área de alcance muito
maior que as antenas de transmissão terrestre. Os dados são enviados e recebidos ao satélite
com o uso de antenas chamadas “parabólicas de satélite”. Os satélites de televisão mantém-se
em órbita geossíncrona em relação à Terra, o que quer dizer que o movimento deles
acompanha o movimento de rotação da Terra. Dessa forma, as parabólicas para recepção de
sinal de televisão por satélite só precisam ser ajustadas uma vez que continuarão recebendo o
sinal.
Porém é a transmissão terrestre que deverá ser usada para a transmissão digital, graças
ao seu baixo custo. Além disso, não há necessidade de se pagar assinaturas às emissoras.
Através de grandes antenas, os sinais são transmitidos por ondas de radiofreqüência pelo ar e
podem ser captados nas residências através de receptores apropriados, assim como é
transmitido o sinal de televisão analógica pública.
Além da forma de transmissão, é necessário também realizar a escolha do padrão de
televisão digital a ser usado (Fernandes et al., 2004). O padrão escolhido decidirá o método a
ser usado em cada uma das três etapas principais da transmissão digital.
• A codificação do sinal, que converterá o áudio e vídeo para sinais digitais. É
consenso entre os três padrões de que a codificação usada nessa etapa será em
vídeo MPEG.
• A multiplexação é a segunda etapa. Ela se encarrega de transformar os sinais que
foram digitalizados de áudio, vídeo e dados em um único feixe digital.
• A modulação é a etapa que se encarrega de converter o feixe digital gerado na
multiplexação em um ou mais sinais que poderiam ser transmitidos usando uma
das três formas descritas (terrestre, satélite ou cabo).
21
1.2 – Padrões de transmissão digital
Na figura a seguir, são representadas as interações entre as diversas estapas para que a
transmissão do sinal digital seja efetuada a partir de um vídeo analógico:
Figura 3: Etapas para converter um vídeo analógico em um sinal de televisão digital
1.2.1 - Padrões para Codificação e Compressão
É a etapa responsável por converter o vídeo analógico para arquivos de áudio e vídeo
digitais. Todos os sistemas já definiram como padrão para codificação e compressão do vídeo
o MPEG-2, criado em 1992 pelo Moving Picture Experts Group. Ele se divide, na verdade em
um grupo de padrões de compressão de vídeo, áudio, identificação de objetos multimídia,
entre outros. O MPEG, estabelece um conjunto de padrões, entre os quais se encontram o
MPEG-2, MPEG-4, MPEG-7 e MPEG-21, estes dois últimos provendo algumas
funcionalidades úteis para a televisão digital e que serão utilizadas neste trabalho.
Uma das características do MPEG é o fato de o custo de codificação ser muito maior
que o custo de decodificação. Assim, num sistema de televisão, por exemplo, o maior custo
cabe às emissoras transmissoras do vídeo, enquanto a decodificação pode ser feita num
receptor mais barato. Detalhes sobre o padrão MPEG, sua codificação e suas funcionalidades
serão explorados no capítulo 2.
1.2.2 - Padrão para Multiplexação e Transporte
As informações de áudio, vídeo e outros dados são agrupadas em fluxos de programa.
A multiplexação se encarrega de converter todos os fluxos de programa em um único fluxo de
transporte denominado Transport Stream, usando padrão MPEG-2 TS. Cada pacote gerado
pela multiplexação possui tamanho fixo de 188 bytes. Isso ocorre para facilitar o processo de
tratamento de erros, além de aumentar a velocidade do processamento. Cada pacote possui
22
obrigatoriamente um header de no mínimo 4 bytes. Cada header possui um campo
denominado PID (Packet Identifier), usado para a indentificação do pacote. Os bytes
posteriores são a carga do pacote ou PES (Packetized Elementary Stream).
Como os pacotes possuem tamanho fixo, o primeiro byte de cada pacote é chamado
“byte de sincronismo” e é usado na verificação de erros. Assim, ele verifica o byte encontrado
a cada 188 bytes e confere para ver se é o valor fixo correspondente ao byte de sincronismo.
Os pacotes de transporte estão sujeitos a erros ou interferências. Quando esses erros
são detectados, um bit do pacote é alterado de forma a informar o demultiplexador que aquele
pacote contém erros. Esse bit se encontra no header do pacote e é usado especificamente para
a deteccção de erros.
Uma seqüência de pacotes resultante de uma multiplexação pode ser multiplexada
novamente. Caberá ao receptor fazer o processo inverso, demultiplexar a seqüência e entregar
os itens corretos para seus respectivos decodificadores.
1.2.3 - Padrões para Modulação e Transmissão
A modulação se encarrega de deixar o feixe de dados gerado na multiplexação em um
ou mais sinais que possam ser transmitidos. Há dois métodos principais de modulação: o 8-
VSB e o COFDM.
O padrão 8-VSB (Eight Vestigial Side Band) usa uma única portadora e um único eixo
de modulação para simplificar os circuitos do receptor. Uma portadora é um sinal analógico
em forma de onda que representa a informação a ser transmitida. O fluxo de bits resultante da
multiplexação é embaralhado, de forma a espalhar melhor a energia, sem concentrar muito em
determinados pontos. É feita uma codificação para correção de erros e os bits são entrelaçados
para evitar a perda de vários segmentos inteiros.
O COFDM (Coded Orthogonal Frequency-Division Multiplexing) usa um sistema de
multiportadoras. Assim, a modulação quebra um fluxo de dados em diversos fluxos paralelos,
com taxas menores e usa diversas subportadoras para transmitir todos os fluxos de dados
simultaneamente. Para fazer essa transmissão, o espaçamento de freqüência das ondas das
portadoras é feito de forma que uma seja ortogonal a outra, de forma que uma não consiga
interferir na outra.
A modulação COFDM usa ainda um sistema de detecção de erros. A modulação é
comumente feita usando transformada rápida de Fourier. Uma das vantagens que ele
apresenta sobre a modulação 8-VSB é no que diz respeito à transmissão em cidades com
23
grandes diferenças geográficas, como São Paulo, com densidade de edifícios, produzindo
padrões de sombra e multipercurso, que são prejudiciais à propagação UHF.
1.3 - Arquitetura da Televisão Digital Interativa
A arquitetura de um sistema de televisão digital é composta por camadas, tanto do
lado do provedor de serviços de televisão, quanto do lado cliente. Estas camadas apenas se
comunicam com as camadas diretamente superiores ou inferiores a elas, e cada padrão de
televisão digital implementa cada camada da sua própria maneira, já que o único consenso
entre os padrões foi a adoção de um padrão MPEG, que atende às expectativas de compressão
necessárias para a transmissão de vídeos de alta definição com baixo consumo de banda. A
figura abaixo representa tais camadas (Paes, Antoniazzi, 2005) e (Fernandes et al., 2004):
Figura 4: Processo de transmissão e recepção de dados da Televisão Digital
Do lado do provedor de serviços, o conteúdo é produzido e enviado à camada de
middleware através de aplicações próprias para o broadcast. Em seguida, o corre a
compressão desse conteúdo, e a multiplexação feita pela camada de transporte. Nesta etapa,
áudio, vídeo e dados viram um único elemento, que será chamado de serviço. Este serviço
será enviado para modulação e transmitido de acordo com o meio de transmissão adotado.
No lado cliente, tais camadas são implementadas dentro de um computador
denominado STB (Set-Top-Box), que pode estar embutido dentro da própria televisão. O STB
24
possui memória, processador, disco de armazenamento e uma série de componentes também
presentes em microcomputadores.
Tal aparelho tem a função de realizar a receptação deste sinal de televisão digital, seja
qual for o meio de transmissão, e realizar a demodulação, transformando-o para a forma
lógica novamente. Em seguida, esses dados são demultiplexados, separando áudio, vídeo e
dados novamente, descomprimidos e então o sistema operacional e o middleware processam
essa informação. As informações de áudio e vídeo serão enviadas a um Controlador de Mídia
presente no middleware, que será responsável pela apresentação dessas informações ao
usuário, e os outros dados serão enviados a um subsistema denominado SI (Service
Information), responsável por disponibilizar aplicações aos usuários, exibir dados como
legenda, imagens estáticas, etc. Há ainda o Gerador de Carrossel, que é responsável por
estabelecer uma fluxo de dados entre o provedor de serviços e o STB, enquanto o serviço
estiver sintonizado. O gerador recebe este nome porque os fluxos de dados que geram o
sistema de arquivos precisam ser re-transmitidos ciclicamente, a fim de que seja possível a um
STB que sintonizou o serviço receber este sistema de arquivos, mesmo após o início da
difusão (Fernandes et al., 2004)
Para o maior aproveitamento da interatividade disponível nesta plataforma, é
necessário que o STB tenha um canal de retorno, ou seja, uma conexão com a internet, ou
com linha telefônica (há diversas outras maneiras propostas em (Oliveira, Albuquerque, 2005)
para que o STB possa enviar informações ao prestador de serviços, e não somente receber, o
que possibilita uma infinidade de novas aplicações para o cliente.
1.4 - Padrões de televisão digital
Atualmente há três padrões fazendo uma disputa pelos mercados dos países que ainda
não definiram o futuro de sua televisão digital. Todos os padrões adotam a tecnologia de
compressão de áudio de vídeo e de multiplexação do MPEG, devido à necessidade de
transferências de elevadas quantidades de dados. Como pode ser visto na tabela, todos estes
padrões utilizam a codificação MPEG-2 mas alguns padrões já estudam o uso codificações
diferentes como o MPEG-4 para obter taxas de compressão ainda maiores.
A tabela a seguir (Peng, 2002) compara alguns importantes aspectos dos padrões
DVB, ATSC e ISDB.
25
Tabela 1: Comparação entre os padrões de televisão digital
Padrão Tipo Codificação do vídeo
Codificação do áudio
Banda utilizada
Taxa de transmissão (Mbps)
Países que adotaram
DVB DVB-S MPEG-2 MPEG-2/1 Digital Sound
8 Mhz 38 Europa, Austrália, Rússia, Taiwan, etc
DVB-T 24 15 (disp. móveis)
DVB-C 38 ATSC ATSC-T MPEG-2 AC-3 6 Mhz 19.28 América do
Norte, México, Argentina, etc
ATSC-C 38.57
ISDB ISDB-S MPEG-2 MPEG-2 AAC
34,5 Mhz 52 Japão, Brasil ISDB-T 5,6 Mhz 21.47
4.06 (disp. móveis)
ISDB-C 6 Mhz 31.644
1.4.1 - ATSC (Advanced Television Systems Committee)
O padrão foi adotado nos Estados Unidos, Canadá, Coréia do Sul, entre outros países.
Tem como intuito a melhoria na implementação da transmissão televisiva de alta definição, a
HDTV. Vêm sendo desenvolvido desde 1987 e está em uso nos Estados Unidos desde 1998.
Por ter sido o padrão pioneiro, este ainda tem problemas que já foram consertados nos outros,
principalmente no que diz respeito à transmissão para dispositivos móveis, que é o principal
ponto fraco deste padrão. Foi desenvolvido de forma a não sofrer interferência das
transmissões NTSC - as transmissões analógicas. Usa a modulação 8-VSB, o que garante uma
taxa de transmissão de aproximadamente 19,8Mbps (ATSC, 2004). O sinal de áudio usa
codificação Dolby AC-3 e o sinal de vídeo usa codificação MPEG-2 Vídeo, na qualidade de
HDTV.
Para a camada de middleware, que é a camada que faz a interação do software de
televisão digital com o hardware da Set-Top-Box, o ATSC usa o padrão DASE (DTV
Application Software Enviroment), que suporta a execução de aplicações JavaTV em seu
modelo procedural e, no seu modelo declarativo, faz uso de uma linguagem chamada ACAP
(Advanced Common Application Platform), que possui um formato parecido com a
linguagem HTML.
Entre os seus formatos de exibição de vídeo estão o 1080i e o 720p, ambos formatos
de vídeo em alta qualidade com tela de proporções 16:9. O formato 1080i exibe em uma tela
26
de 1080 pixels verticais por 1920 pixels horizontais. O formato de 720p possui uma tela de
exibição menos - de 720 pixels verticais por 1280 pixels horizontais -, entretanto, possui uma
taxa de atualização da tela de 60 quadros por segundo - duas vezes maior que o formato
1080i.
1.4.2 - DVB (Digital Vídeo Broadcasting)
O padrão DVB já é adotado pela Europa, Austrália, Índia, África do Sul, entre outros
países. Iniciado em 1993, a partir de uma equipe de 300 membros, entre fabricantes,
emissoras de televisão, desenvolvedores de software e orgãos de regulamentação. Por padrão,
funciona transmitindo em um canal de 7Mhz, mas possui também suporte a canais de 6Mhz e
8 Mhz. Através da modulação COFDM (Coded Orthogonal Frequency Division
Multiplexing), este padrão permite taxas de transmissão que variam entre 3,74Mbps e
23,75Mbps. (DVB, 2004)
Com formatos que variam de 240 a 1080 linhas, este padrão permite que seja
simultaneamente feita transmissão de HDTV e transmissão para dispositivos móveis. O
enfoque do DVB é diversificar a quantidade de programas e serviços. Assim, o padrão
permite uma maior quantidade de operadoras de transmissão.
O áudio é codificado em formato MPEG2-BC e o vídeo usa MPEG-2 Video na
qualidade standard.
O padrão de middleware é chamado MHP (Multimedia Home Plataform) e permite
funcionalidades como o uso de um canal de retorno, permitindo o feedback das residências às
emissoras de televisão. Assim como o padrão DASE, do ATSC, este padrão de middleware
permite o uso de aplicações JavaTV em seu modelo procedural e o uso de uma linguagem
parecida com o HTML em seu modelo declarativo, o DVB-HTML.
1.4.3 - ISDB (Integrated Services Digital Broadcasting)
O padrão japonês de televisão digital. Foi criado em 1997, pelo grupo DiBEG (Digital
Broadcasting Experts Group). Surgiu a partir do padrão europeu DVB, sendo muito parecido
com ele. Destaca-se principalmente na área da transmissão digital para dispositivos móveis
(ISDB, 1998).
Usa o mesmo padrão de modulação do DVB, o COFDM, que permite uma taxa de
transmissão de dados entre 3,65Mbps e 23,23 Mbps. Possui melhorias em relação ao DVB no
que diz respeito à interferência dos sinais móveis com a transmissão de televisão em alta
27
qualidade. O áudio é codificado em padrão MPEG-2 ACC (Advanced Audio Coding) e o
vídeo é codificado em MPEG-2 Video, com qualidade HDTV.
O middleware adota uma plataforma denominada ARIB (Association of Radio
Industries and Business), que usa em seu modelo declarativo uma linguagem semelhante ao
XML, denominada BML (Broadcast Markup Language).
1.4.4 - Padrão Brasileiro
Alguns países, entretanto, não pretendem aderir a nenhum dos padrões já existentes,
criando seu próprio. A China é um exemplo, desenvolvendo atualmente o DMB-T (Digital
Media Broadcasting Terrestrial).
O Brasil é outro país que pretendia, ao invés de escolher um dos padrões, desenvolver
um padrão próprio para o mercado brasileiro. A Sociedade de Engenharia de Televisão (SET)
começou em novembro de 2003 a criação do que foi chamado SBTVD (Sistema Brasileiro de
Televisão Digital) e, depois renomeado para ISDTV (International System for Digital TV).
A tecnologia brasileira seguia bem adiantada. Os sistemas “SORCER” e “MI-
SBTVD” foram desenvolvidos pela Pontifícia Universidade Católica do Rio Grande do Sul
(PUC-RS) e pelo Instituto Nacional de Telecomunicações (Inatel) para realizar a modulação
da televisão digital brasileira. O middleware recebia o nome de “Ginga” e já estava
desenvolvido, sendo uma unificação do sistema declarativo “Maestro”, desenvolvido pela
Pontifícia Universidade Católica do Rio de Janeiro (PUC-RJ) com o sistema procedural
“FlexTV”, desenvolvido pela Universidade Federal da Paraíba (UFPB).
Os padrões de codificação de áudio e vídeo ainda não estavam definidos, e ainda assim
o sistema apresentava ótimos resultados em comparação com os demais apresentados.
Entretanto, o governo brasileiro anunciou em 2006 que o padrão que seria adotado nas
transmissões digitais de televisão no Brasil seria o padrão japonês, o ISDB. A escolha gerou
críticas pelo fato de ser um padrão que privilegia em alguns aspectos as emissoras de
televisão. É o padrão, porém, que obteve os melhores resultados nas pesquisas da Anatel.
As promessas são para que em 10 anos o sistema digital esteja completamente
implantado no país. A transmissão analógica, entretanto, ainda deverá permanecer por mais
algum tempo. Os televisores atuais ainda não possuem capacidade de executar a transmissão
digital. Assim, têm-se a necessidade de uso de um aparelho que possa codificar o sinal digital
para ser transmitido nas televisões, o Set-Top-Box, enquanto as televisões ainda não saírem
de fábrica com a funcionalidade deste aparelho. Por um tempo, entretanto, a televisão digital
28
seria transmitida juntamente com a televisão analógica, para que a nova tecnologia possa se
firmar gradativamente.
Alguns outros grandes problemas ainda não têm solução aparente. Para uso completo
de todas as funcionalidades esperadas, por exemplo, seria necessário o retorno do sinal, das
residências às emissoras de televisão. Num país onde apenas 20% da população têm acesso à
Internet, uma grande parcela - especialmente a mais pobre - não poderia usufruir de todas as
funcionalidades prometidas.
As mudanças com a chegada da televisão digital também atingem a gravação dos
programas. Com programas sendo transmitidos em qualidade altíssima, os equipamentos de
gravação teriam que ser melhorados para conseguir melhor qualidade de imagem. As câmeras
atualmente usadas nas gravações não suportariam a qualidade da imagem que seria
apresentada.
1.5 - Middlewares
Middleware é um termo genérico usado para representar softwares que interagem com
o sistema operacional, hardware e alguns protocolos de comunicação, trabalhando como
mediadores dessas funcionalidades para outras aplicações. Suas principais funções são:
• Esconder a distribuição do sistema para o usuário;
• Esconder a heterogeneidade de componentes de hardware, sistemas operacionais e
protocolos de comunicação;
• Fornecer interfaces de alto nível para desenvolvedores, de modo a facilitar o
processo de desenvolvimento.
No caso da televisão digital, existem diferentes padrões, cada um fornecendo STBs
diferentes, onde as características de hardware e até mesmo o sistema operacional dos
mesmos variam (levando em consideração que a única característica igual entre os padrões é a
adoção ao padrão MPEG), a taxa de transferência e a freqüência utilizada pelos padrões
também, enfim, há muita heterogeneidade entre eles, tornando este ambiente propício ao uso
de middleware, pois desenvolver uma aplicação portável entre vários padrões de televisão
digital sem middlewares geraria um elevado custo e perda de tempo, análogo a desenvolver
uma aplicação em C++ e outra em Java com a mesma funcionalidade. A própria
interatividade da televisão digital, com imagens, textos, gráficos, faz com que o middleware
se torne necessário, para que os desenvolvedores não se preocupem com as camadas mais
baixas da plataforma.
29
Para facilitar o desenvolvimento de aplicações nesta plataforma, e tornar as aplicações
mais portáveis, os STBs devem prover uma API (Application Programming Interface)
genérica bem definida, com o intuito de abstrair um pouco dessa heterogeneidade presente
para outras aplicações (Fernandes et al., 2004).
Os benefícios do uso de um middleware não se fazem necessários só no front-end
(STBs), mas também no back-end em características como: conversão de conteúdo Web para
televisão, proxy, segurança, gerenciamento do assinante, etc. (Paes, Antoniazzi, 2005)
Devido a essa grande quantidade de benefícios, os órgãos que projetam os padrões de
televisão digital também desenvolvem seu próprio middleware, de forma com que este
funcione melhor com as características pré-estabelecidas no padrão. Desta forma, o padrão
DVB desenvolveu o middleware MHP (Multimedia Home Platform), o ATSC desenvolveu o
DASE (DTV Application Software Environment) e o ISDB desenvolveu o ARIB (Association
of RadioIndustries and Businesses).
A figura de (Paes, Antoniazzi, 2005) apresenta a estrutura do modelo funcional do
middleware para televisão Digital.
Figura 5: Estrutura do modelo funcional de um middleware
• Porting Layer – camada entre os drivers e o Middleware;
• Network Layer – responsável pelo gerenciamento do transporte, comandos e
controles da rede;
30
• Security – integra a autenticação do usuário com os propósitos do CAS e DRM
(Digital Rigths Management);
• Kernel – é o cérebro do STB. Gerencia os arquivos do sistema, a memória e
acodificação de audio e vídeo;
• Presentation Control – atua na experiência do usuário que assiste a televisão;
• Application Management Layer – gerencia o conteúdo, os serviços da plataforma
interativa e os aplicativos.
Considerando que cada padrão tem o seu middleware, a tarefa do desenvolvedor de
aplicações para tal plataforma é a facilidade; porém, portar um software entre estes
middlewares pode ter uma tarefa mais complicada, e o software pode precisar de alguns
ajustes. Para facilitar um pouco esta tarefa, estes middlewares usam diversas funcionalidades
de outros blocos fundamentais. Destacam-se: DAVIC, HAVi e Java TV, cujos detalhes serão
explicados a seguir. Assim, a tarefa de portar aplicações entre diferentes padrões de televisão
digital é ligeiramente facilitada.
1.5.1 – Blocos Fundamentais
1.5.1.1 – DAVIC
DAVIC (Digital Audio-Visual Council) é uma associação de diversas empresas do
setor áudio-visual, órgãos de pesquisa, órgãos do governo e prestadores de serviços de
telecomunicações e televisão criada em 1994 e que durante 5 anos desenvolveu um padrão
para a interoperabilidade de comunicação multimídia e difusão de dados áudio-visuais
interativos. (DAVIC, 1999)
Seu objetivo era facilitar o desenvolvimento de aplicações áudio-visuais e sua
interoperabilidade especificando padrões de interfaces e protocolos a serem utilizados. Sua
última especificação, a 1.5, passou a englobar aplicações e serviços para televisão interativa.
As APIs definidas nesta especificação abrangem controle de acesso, filtragem de
informações, notificação, acesso a informações do serviço e controle de sintonização
(Fernandes, 2004). Para oferecer suporte à televisão interativa, a especificação apenas
acrescentou protocolos na parte de rede e controle, sem nenhuma modificação nas APIs ou
outros protocolos de níveis mais alto. Suas principais APIs são (DAVIC, 1999):
• MPEG-2 Section Filter API – serve para acessar dados anexos ao MPEG-2, como
metadados de outros padrões MPEG por exemplo;
31
• Resource Notification API – serve para o gerenciamento de recursos em um
ambiente limitado, como um STB por exemplo;
• MPEG Component API – serve para representar os componentes básicos do
MPEG
• Tuning API – provê um mecanismo para seleção de serviços através da
sintonização de diferentes streams MPEG-2
• Conditional Access API – prove uma interface de acesso à algumas funções
específicas como EPG(Eletronic Program Guide) com a possibilidade de controle
desse acesso
• Media Player API – fornece controle da execução do vídeo em tempo real,
baseado na JMF (Java Media Framework)
• DSM-CC User-to-Network API – fornece uma aplicação para controlar sessões de
usuários
A especificação ainda conta com uma extensão de API para tratamento de interface
para o usuário, utilizando o pacote AWT já disponível na API do Java.
1.5.1.2 – HAVi
HAVi (Home Audio Video interoperability) é uma iniciativa de 8 grandes fabricantes
de produtos eletrônicos que visa fornecer uma especificação para a interoperabilidade entre
dispositivos de áudio e vídeo dispostos em uma rede doméstica. Propõe uma rede onde
dispositivos de áudio e vídeo tenham controle sobre outros dispositivos de áudio e vídeo,
independentemente da configuração do dispositivo ou outro elemento de rede (HAVI, 1999).
Desta forma, qualquer elemento desta rede terá a possibilidade de exercer controle sobre outro
elemento.
Com esta arquitetura é possível fazer com que dispositivos de diferentes marcas
interajam entre si, já que é uma arquitetura de especificação aberta, independente de
plataforma ou linguagem de programação. Assim, é possível fazer dispositivos se
comunicarem, mesmo sem utilizarem o mesmo sistema operacional ou linguagem de
programação, por exemplo. Basta que todos implementem uma versão desta arquitetura e
usem a API definida pela especificação.
A rede escolhida para suportar dados multimídia e troca de comandos entre os
dispositivos foi a IEEE-1394, também conhecida como Firewire. Este tipo de rede tem a
capacidade de transportar 400Mb/s e tem a vantagem de suportar comunicação síncrona,
tornando possível que dados multimídia sejam transferidos em tempo real. Versões desta rede
32
utilizando tecnologia wireless, linhas telefônicas, entre outras, foram previstas desde o
começo da especificação HAVi, possibilitando que adaptações para as mesmas possam ser
desenvolvidas.
HAVi é uma arquitetura de software distribuído que implementa elementos como
controle de rede, abstração de dispositivo, comunicação entre dispositivos e ainda a interface
para o usuário (HAVI, 1999), que juntos, formam uma API para a interoperabilidade desta
arquitetura. Os elementos de software sao:
• 1394 Communication Media Manager – possibilita comunicação síncrona e
assíncrona
• Messaging System – responsável pela troca de mensagens entre elementos
• Registry – provê services de busca de outros elementos, bem como a detecção de
suas propriedades
• Event Manager – serviço que dispara eventos
• Stream Manager – gerencia as transferências de áudio e vídeo da rede
• Resource Manager – facilita o compartilhamento e agendamento de ações
• DCM (Device Control Module) – representa um dispositivo na rede e expõe sua
API
• FCM (Functional Component Module) – representa cada função disponível em um
DCM
• DCM Manager – responsável pela instalação e desinstalação de dispositivos na
rede
• Applications – aplicações precisam ser conhecidas pela rede antes de interagirem
Além destes elementos de software, a arquitetura apresenta alguns elementos de software
especiais para lidar com a interface com o usuário. São eles:
• DDI (Data Driven Interaction) – serve como protocolo e é utilizado entre
aplicações e DCMs quando uma interface precisa ser exibida lado a lado com umo
próprio display do aparelho
• Havlet – usada para desenhar interface para o usuário na tela de um dispositivo
Um bom exemplo de uso desta arquitetura, do lado cliente, é uma solicitação de
agendamento para gravação de conteúdo televisivo, feito a partir da televisão, para um DVD-
Recorder. Porém, se na hora da gravação a televisão estiver desligada desta rede, o gravador
poderá buscar outro dispositivo capaz de auxiliá-lo a realizar esta tarefa.
33
1.5.1.3 - Java TV API
Em março de 1998, a Sun Microsystems anunciou a Java TV API, definindo uma
plataforma totalmente Java para televisão digital (Morris et al., 2005). Parte deste trabalho foi
padronizar o uso de APIs já existentes para o uso na televisão digital, como a JMF (Java
Multimedia Framework), que é usada para o gerenciamento do fluxo de áudio de vídeo, e a
outra parte deste trabalho foi criar novos pacotes que atendessem às necessidades de
características específicas da plataforma que foram surgindo à medida em que a tecnologia de
televisão digital e o conceito de interatividade envolvido, evoluía. Atualmente, esta API é
distribuída com o pacote J2ME.
Oferece uma plataforma de desenvolvimento bastante rica em recursos específicos
para os recentes avanços tecnológicos em televisão digital, podendo acessar e controlar
algumas funcionalidades da mesma, assim como controle de acesso, seleção de conteúdo,
controle de canais, streaming de áudio e vídeo, acesso aos canais de entrada e saída de dados,
informações do serviço (análogo ao canal de televisão) e ainda proporcionar a criação de
elementos visuais por cima do vídeo que está sendo exibido para o telespectador. Um serviço
é caracterizado por um conjunto de informações (Service Information) e as informações sobre
os serviços disponíveis são armazenadas em um banco de dados específico (SI Database)
(Fernandes et al., 2004).
Além disso, acrescentará funcionalidades como sincronização de conteúdo interativo
da televisão digital com o vídeo e o áudio de um determinado programa de televisão, e
também o controle do ciclo de vida de uma aplicação, que poderá existir ao mesmo tempo em
que os programas de televisão, como anúncios, por exemplo. Desta forma é possível que o
telespectador aproveite ao máximo os novos recursos da televisão da era digital, alcançando
níveis de interatividade com tal meio de comunicação até então desconhecidos.
No lado do software, a Java TV API necessita de um sistema operacional real-time
com uma plataforma Java para ser executada. Em um nível mais elevado, um software
desenvolvido para um receptor de televisão digital pode utilizar os pacotes da Java TV API, e
ser executado sobre a plataforma Java. Sendo assim, o desenvolvedor tem a oportunidade de
oferecer ao telespectador conteúdo interativo, como anúncios de produtos, informações extras
sobre a programação, seleção de legendas, entre outras inúmeras novidades existentes nesta
plataforma. Em um nível mais baixo, o sistema operacional real-time contém diversos drivers
e bibliotecas específicas de suporte ao hardware, bem como a estrutura necessária para a
execução da máquina virtual Java e outras bibliotecas incorporadas pela plataforma Java.
34
Uma característica importante da plataforma Java sobre este tipo de hardware é que ela
encapsula todas as funcionalidades que o sistema operacional expõe para o controle do
hardware.
No lado do hardware, a Java TV API roda sobre um hardware muito específico e
limitado, se comparado a um computador, que é o receptor de televisão digital. Este receptor
lida com o sinal de vídeo e de dados de acordo com o meio de transmissão e realiza tarefas
como sintonização, mudança de canal e demultiplexação dos dados. A Java TV API
proporciona uma abstração ao hardware do receptor, fornecendo pacotes suficientes para o
controle de tais operações, deixando que o desenvolvedor se preocupe apenas com o software
em si, e não com detalhes específicos da plataforma ou drivers para o controle do hardware.
Esta abstração é fundamental para o sucesso desta API, já que diferentes padrões de televisão
digital foram desenvolvidos, e continuam sendo aprimorados, gerando assim, algumas
derivações dos mesmos em uma grande escala. Tais padrões serão implantandos nestes
receptores, e cada um terá suas particularidades, e caberá ao fabricante do receptor adotá-lo e
adaptá-lo às especificações Java. Esta característica, há tempos está presente nos
computadores, como por exemplo, uma aplicação desenvolvida em Java sobre um sistema
operacional Mac é capaz de ser executada, da mesma forma, sobre um sistema operacional
Windows. A máquina virtual é residente no receptor e pode ser usada por outros blocos
fundamentais (Paes, Antoniazzi, 2005).
A figura abaixo caracteriza este ambiente de hardware e software para a Java TV API
quando implementada em um receptor de televisão digital. (Fernandes et al., 2004)
Figura 6: Pilha de software em um receptor de televisão digital
35
Uma aplicação desenvolvida com a Java TV API é chamada xlet. Semelhante ao
Applet na web e ao Midlet nos dispositivos móveis, um xlet não precisa estar previamente
armazenado no STB para que seja executado, pois ele pode ser enviado da mesma forma
como o vídeo pelo canal de difusão, e posteriormente executado.
A figura a seguir mostra o ciclo de vida de uma aplicação xlet dentro de um STB.
(Fernandes et al., 2004)
Figura 7: Ciclo de vida de um xlet
Ao ser descarregado para o STB, a xlet encontra-se no estado Loaded. A seguir, pode
ser inicializada por um gerente de aplicação, que passa um objeto XletContext para a xlet, que
define seu contexto de execução, que por sua vez, possibilita que a xlet notifique o gerente de
aplicação sobre mudanças de estado, num mecanismo semelhante ao de callbacks adotados
em diversas plataformas. Após sua inicialização a xlet fica no estado Paused, onde ainda está
inoperante, e não retém informações do serviço. Neste estado, a xlet pode ser ativada e entrar
em execução com todas as suas funcionalidades, passando para o estado Active, e em qualquer
estado a xlet pode ser destruída.
O objetivo da Sun Microsystems ao desenvolver esta API é fazer com que as
necessidades dos fabricantes, desenvolvedores e distribuidores de conteúdo (canais de
televisão) sejam atendidas à medida que estes procuram por soluções seguras e portáveis, pois
diferentes tipos de receptores são desenvolvidos para trabalharem com diferentes padrões de
televisão digital. Alguns padrões de televisão digital já adotam esta API, tornando-a um
grande recurso para desenvolvedores de aplicações interativas.
1.5.1.4 – Microsoft TV
A Microsoft também faz um importante trabalho no desenvolvimento para a
plataforma de televisão digital. Eles possuem uma plataforma toda baseada em softwares
36
próprios e buscam oferecer seu produto como uma alternativa à utilização da televisão digital
com outras APIs. Ao contrário da Java TV API é uma plataforma privada, e não de código
aberto. Por outro lado, é uma solução para integrar as diferentes tecnologias necessárias para
se ter um ambiente de televisão digital adequado, pois ao invés de usar APIs de interface
gráfica em conjunto com Java TV API, seria possível usar apenas as APIs da própria
Microsoft. Desta forma, o desenvolvedor encontra menos flexibilidade, porém mais facilidade
no desenvolvimento da aplicação.
Esta plataforma pode ser utilizada com diferentes meios de transmissão em que o sinal
de televisão digital é capaz de ser transmitido e possui funcionalidades como suporte à vídeos
de alta resolução, gravação de vídeo no formato digital e aquisição de vídeos sob demanda.
1.5.2 - Padrões
1.5.2.1 – MHP
MHP (Multimedia Home Platform) é o middleware desenvolvido pelo padrão de
televisão digital europeu, o DVB (DVB, 2004). Este middleware define uma interface
genérica entre as aplicações e o ambiente no qual essas aplicações são executadas, por
exemplo o STB, criando uma abstração entre as aplicações e o ambiente (hardware e
software) em que elas residem. Desta maneira as aplicações com base em MHP, serão
compatíveis com STBs, televisões com sistema digital integrado e computadores multimídia.
O MHP estende os padrões DVB para broadcast e serviços interativos em todos os
tipos de transmissão de sinal: cabo, terrestre, satélite, etc.
Sua arquitetura é definida em 3 camadas (DVB, 2004):
• Aplicações: como EPG, informações do serviço, jogos, e-commerce, transações
seguras e aplicações educacionais;
• Softwares de sistema: como o gerenciador de aplicações (ou navigator), outras
APIs, protocolos de transporte e máquinas virtuais, como a JVM;
• Recursos: como o processamento do MPEG, gráficos, entrada e saída de dados e
unidade de processamento.
Este middleware é baseado numa plataforma chamada DVB-J, em sua forma
procedural, que utiliza a máquina virtual Java. Toda aplicação baseada em MHP nesta forma,
deve usar softwares do sistema para acessar os recursos da plataforma através de APIs
especificadas. Dentre estas APIs estão os principais blocos fundamentais já descritos:
DAVIC, HAVi, Java TV. Na sua forma mais simples, a declarativa, dá suporte à uma
37
linguagem declarativa baseada em HTML, denominada DVB-HTML (Paes, Antoniazzi,
2005).
O MHP possui três tipos de perfis para implementação das plataformas de
serviços(Paes, Antoniazzi, 2005):
• Enhanced Broadcast – suporte a recepção de áudio, vídeo e serviços de download
de aplicações de interatividade apenas local, pois não tem o canal de retorno,
também chamadas de one-way services. Possui suporte a DVB-HTML;
• Interactive Broadcast – possui todas as características do perfil Enhanced
Broadcast, com a vantagem de implementar um canal de retorno, deixando de ter
interatividade apenas local, podendo de comunicar com o serviço de broadcast ou
não; A comunicação é feita com a utilização do protocolo IP;
• Internet Access – possui todas as características do perfil Interactive Broadcast,
com a vantagem de poder se conectar à Internet. Desta forma, serviços como e-
mail tornam-se possíveis nesta plataforma.
Na primeira versão do middleware, 1.0, apenas os dois primeiros perfis estavam
disponíveis. Só na versão 1.1 surgiu o Internet Access.
1.5.2.2 – DASE
DASE(DTV Application Software Environment) é o middleware desenvolvido para o
padrão de televisão digital americano ATSC (ATSC, 2004). O middleware DASE interage
com a camada de transporte, de modo a transformar a informação recebida pelo broadcast em
saída de vídeo e áudio para a televisão acoplada.
Assim como as aplicações MHP, as aplicações DASE possuem forma declarativa e
procedural. Na forma declarativa as aplicações podem ser escritas em HTML, XHTML ou
mesmo XML e conter folhas de estilos, scripts, etc. E na forma procedural a aplicação pode
ser uma xlet da API Java TV e conter outros arquivos.
O middleware DASE possui um subsistema chamado DAE (Declarative Application
Environment) para realizar o processamento das aplicações declarativas. Este subsistema tem
um componente chave chamado DCDE (Declarative Content Decoding Engine) que atua
como analisador sintático XDML e interpretador de scripts e estilos. Já para as aplicações
procedurais, existe um subsistema chamado PAE (Procedural Declarative Application
Environment) para realizar tal tarefa, como por exemplo, a JVM.
A arquitetura proposta por esta especificação é basicamente composta por:
• DASE Content Model – são as aplicações DASE;
38
• DASE Environment Model – representa o sistema DASE.
O sistema DASE é constituído pelos elementos a seguir especificados, direta ou
indiretamente com base nos mecanismos fornecidos pelo receptor (ATSC, 2004):
• Entrada de dados – o sistema deve suportar entrada de dados por parte do usuário;
• Áudio – o sistema deve suportar decodificação e apresentação do áudio em tempo
real;
• Vídeo – o sistema deve suportar decodificação e exibição do vídeo em tempo real;
• Gráficos – o sistema deve suportar decodificação e exibição de imagens estáticas,
ou seja, conteúdo visual que não seja vídeo, de acordo com resoluções pré-
estabelecidas;
• Modelo de exibição – o sistema deve apresentar o seguinte modelo de exibição:
Figura 8: Modelo de exibição DASE
No sistema de segurança do DASE, uma aplicação somente poderá executar algumas
operações privilegiadas se a aplicação fizer a chamada através da API do middleware e este,
através de uma política de segurança local, conceder a permissão.
1.5.2.3 – ARIB
ARIB (Association of Radio Industries and Businesses) é o middleware desenvolvido
pelo o padrão de televisão digital japonês ISDB (ISDB, 1998) para que seja efetuada a
comunicação entre sistema operacional, hardware e aplicações. Neste middleware foi criada
uma linguagem de marcação chamada BML (Broadcast Markup Language), que possui
estrutura semelhante à linguagem XML, para fazer o papel das aplicações declarativas.
No ARIB o modelo de exibição é mais elaborado, como na figura a seguir (Paes,
Antoniazzi, 2005):
39
Figura 9: Modelo de exibição ARIB
Em resumo, o sistema ARIB é especificado da seguinte maneira (Paes, Antoniazzi,
2005):
• Serviços de conteúdo – apresentar legendas com superposição sobre o vídeo, como
definido no modelo de exibição; permitir assistir vídeo, áudio ou outras
informações interativas; considera as possibilidades de serviços e até mesmo o
público que irá adquirir os serviços;
• Serviços de acessibilidade – permitir agendamento de gravação através do EPG;
acesso dos controles pelo usuário, etc;
• Serviços de extensões – define a possibilidade de expandir as especificações no
futuro, considerando o estilo dos serviços, novas codificações, sistemas de acesso
e receptores;
• Interoperabilidade – permitir recepção de dados em qualquer STB que implemente
o middleware, por mais comum que seja; considera a integração com sistemas de
comunicações como alta prioridade;
• Capacidade de Controle – considera a flexibilidade de controle do sistema usando
a eficiência da capacidade de transmissão; considera as funções automáticas de
controle de recepção, como funções de emergência por exemplo;
• Erros de apresentação no display – sempre que possível, tratar os erros de
sobreposição de elementos visuais ou até mesmo áudio em uma faixa de tempo
suficientemente pequena para que o usuário não perceba.
Por enquanto pouquíssimos países são adeptos desta plataforma, portanto ela está
sendo reformulada de forma a ficar mais parecida com o MHP (Morris et al., 2005). Um dos
motivos que faz este padrão ser menos aceito no mercado pode ser a falta de aplicações do
tipo procedural, que restringem basante o ambiente do desenvolvedor.
40
1.5.2.4 – Ginga
Ginga é o nome do middleware desenvolvido para trabalhar com o padrão brasileiro de
televisão digital, e destinado à transmissão terrestre. É o resultado do trabalho em conjunto de
diversos centros de pesquisa, destacando-se as universidades Pontifícia Universidade Católica
do Rio de Janeiro (PUC-Rio) e Universidade Federal da Paraíba (UFPB).
Este middleware também possui sua forma declarativa e sua forma procedural, assim
como é possível identificar nos outros middlewares apresentados. Na sua forma declarativa, é
denominado Ginga-ncl e define uma linguagem declarativa chamada NCL, capaz de
endereçar funcionalidades relativamente simples, no que diz respeito à interatividade,
sincronismo de objetos de mídia, suporte à diferentes tipos de dispositivos, entre outros.
Possui um mecanismo decodificador para esta linguagem NCL, suporte à navegação
XHTML, incluindo CSS e um interpretador ECMAScript, além de um mecanismo para
interpretar scripts LUA. (Filho et al, 2007)
Já em sua forma procedural, há um subsistema denominado Ginga-J, que se baseia na
linguagem Java para prover suas funcionalidades. Seu ambiente de execução é uma Máquina
Virtual Java (JVM) e aplicações sobre este middleware tem acesso à todos os recursos do
STB, além de possuir suporte à comunicações do tipo Bluetooth, Wi-fi, Ethernet, entre outras
formas. Provê funcionalidades básicas como acesso a fluxo de dados de baixo nível,
processamento do fluxo elementar de dados, componentes de interface, comunicação,
gerenciamento, persistência e acesso condicional.
Para prover compatibilidade com outros middlewares de outros padrões de televisão
digital, o Ginga é dividido em um conjunto de três APIs : A Verde, a Amarela e a Azul. A
API Verde é compatível com GEM (Globally Executable MHP), a API Amarela é usada para
satisfazer necessidades específicas para o mercado brasileiro e pode criar aplicações
compatíveis com middlewares como MHP através de uma adaptação do software para a API
Verde, desde que essas ferramentas de adaptação sejam enviadas anteriormente ao STB. Já a
API Azul produz aplicações que só são capazes de executar em um ambiente com middleware
Ginga.
41
Capítulo 2 – MPEG MPEG (Moving Picture Experts Group) é o nome dado a uma família de padrões ISO
(International Organization for Standardization) que são usados para a codificação de
elementos áudio-visuais em um formato digital e comprimido. Tal família inclui os padrões
MPEG-1, MPEG-2, MPEG-4, MPEG-7 e MPEG-21 que serão vistos sob mais detalhes ao
longo deste capítulo. Esta família é constantemente atualizada para a adaptação às novas
tecnologias que surgem com o tempo e não só os padrões já existentes são atualizados, mas
também são criados novos padrões.
2.1 - Padrões
O Moving Picture Coding Experts Group iniciou seus trabalhos em 1988. O padrão
MPEG-2 foi iniciado em 1991 e publicado em 1995, sendo uma evolução do MPEG-1. O
MPEG-2 é descrito pelas especificações ISO/IEC 13818, que definem a forma de compressão
para o fluxo de dados do sistema (ISO, 2000a), para a compressão do vídeo (ISO, 2000b) e
para a compressão do áudio (ISO, 1998). A camada de compressão de fluxo de dados MPEG-
2 Systems segue as recomendações H.222.0 (ITU, 2000a) e a camada de compressão de vídeo
MPEG-2 Video segues as recomendações H.262 (ITU, 2000b) no âmbito do ITU-T
(International Telecommunication Union - Telecommunication Standardization Sector).
O objetivo do MPEG-2 é prover uma taxa de vídeo adequado para os sistemas de
televisão. Assim, a taxa de vídeo varia entre 1,5 Mbps e 30 Mbps, sendo até 15Mbps
adequados para o padrão SDTV e acima de 15 indicado para o padrão de HDTV.
O padrão MPEG-4 foi finalizado em 1998 e se tornou padrão internacional em 2000.
O surgimento desse novo padrão tornou-se necessário como forma de permitir a transmissão
pela internet de vídeos com a qualidade do MPEG-2, em arquivos menores. A portabilidade
criada com o MPEG-4 permite que os filmes sejam executados nos mais diversos tipos de
aparelhos, de celulares a televisores.
Para garantir essa interoperabilidade, diversas empresas, como Apple, IBM, Philips,
HP, Cisco, Sun, entre outras, se uniram para a criação do ISMA (Internet Streaming Media
Alliance), que define os padrões dos players que deverão rodar o MPEG-4. Devido à
capacidade do MPEG-4 de manter a qualidade do vídeo, mesmo a baixas taxas de
transmissão, o padrão também é usado em algumas transmissoras de televisão via satélite.
42
O padrão MPEG-4 faz uso de um padrão de compressão denominado H.264, que
possibilita a apresentação da mesma qualidade do vídeo MPEG-2, porém usando apenas um
terço de taxa de dados.
O padrão MPEG-7, formalmente conhecido como Multimedia Content Description
Interface ou Interface para Descrição de Conteúdo Multimídia, disponibiliza ferramentas para
a descrição de conteúdo multimídia através de anotações em XML. Dessa forma é possível,
por exemplo, fazer com que a letra de uma música seja sincronizada com a própria música.
Assim como o MPEG-7, o MPEG-21 utiliza as anotações em XML embutidas dentro do
vídeo de forma bem semelhante. O MPEG-21, entretanto possui uma segurança maior, além
de outras funcionalidades, como proteger os direitos autorais dos vídeos e monitoria dos
estados de transmissão.
2.3 - MPEG-1
Aprovado inicialmente em 1991, o padrão MPEG-1 define a codificação de elementos
audiovisuais para mídias de armazenamento com capacidade de transferência de até 1,5Mbit/s
de dados. MPEG-1 foi o primeiro resultado dos esforços do grupo MPEG.
Este padrão foi definido em 5 partes. São elas (MPEG1, 1996) :
• Sistemas: caracteriza a combinação de uma ou mais streams de dados das partes de
áudio e vídeo definidas neste padrão juntamente com uma sincronização temporal,
tendo como resultado uma única stream. Desta maneira, facilita-se o
armazenamento e transmissão dos dados digitais;
• Vídeo: originou-se do padrão H.261 (definido na International Telecommucation
Union- ITU) e representa a codificação de vídeos de 625 e 525 linhas (similares
aos padrões de televisão analógica) em taxas de até 1,5Mbit/s. Nesta parte são
definidas algumas técnicas para se atingir um elevado nível de compressão do
vídeo, como selecionar uma resolução apropriada para o sinal, utilizar algoritmos
de compensação de movimento para reduzir a redundância temporal e por último a
aplicação da Transformada Discreta de Cosseno para compactar ainda mais os
quadros de interpolação e predição;
• Áudio: especifica uma compressão de seqüência de áudio mono ou estéreo.
Amostras de áudio são transferidas à um codificador, que caracteriza realiza
processos de filtragem e reamostragem do áudio de entrada, e com a ajuda da
codificação de Huffman cria símbolos de amostragem, compactando o áudio sem
que ruídos sejam adicionados. É dividido em três camadas, onde as duas primeiras
43
especificam áudio de qualidade elevada, porém com alta complexidade no
momento da compressão, enquanto a terceira também consegue atingir alta
qualidade de maneira mais simplificada, sendo esta, mais usada em aplicações
digitais;
• Testes de conformidade: define testes de conformidade de streams com as partes
definidas acima;
• Software: uma implementação das três primeiras partes com código fonte fechado.
Tecnologias como Vídeo CDs (VCDs) e MPEG-1 Layer III (mais conhecido como
MP3) são os pontos fortes deste padrão. Este último vem sendo usado para comprimir áudio e
é a única parte deste padrão que ainda é encontrada com alta freqüência em dispositivos
digitais (como MP3 players, celulares, etc), devido ao seu baixo custo de armazenamento e
fidelidade para com o áudio original. A perda de qualidade do MP3 é praticamente
imperceptível.
2.4 - MPEG-2
Um arquivo no formato MPEG-2 divide-se em duas camadas. A camada de
compressão e a camada de sistema. A camada de sistema é a responsável pela multiplexação
do vídeo, ideal para a transmissão. A camada de compressão cuida da codificação e
compressão dos dados de áudio e vídeo.
2.4.1 - Camada de compressão
Os vídeos nada mais são do que um conjunto de imagens exibidas seqüencialmente.
Cada frame de um vídeo pode ser representado por três matrizes, sendo uma de luminância e
duas matrizes de crominância. A luminância é a componente do vídeo que contém somente as
informações de brilho – o preto e branco. A crominância contém as informações sobre as
cores da imagem. As informações de um quadro podem ser separadas nas linhas pares ou
ímpares que o compõem, em campos denominados top field e bottom field.
Uma figura codificada através de MPEG-2 pode representar um único quadro ou um
campo codificado. Se um sinal de vídeo contém figuras que representem campos, ele é
chamado de vídeo entrelaçado. Se o sinal de vídeo contiver figuras que representem apenas
quadros, ele é chamado de vídeo progressivo.
A principal diferença entre o vídeo entrelaçado e o vídeo progressivo é que, no vídeo
entrelaçado, a cada novo frame de vídeo, apenas metade dos pixels são atualizados,
44
redesenhando apenas as linhas pares ou as ímpares – o top field ou o bottom field. Já no vídeo
progressivo, todas as linhas são atualizadas.
O olho humano é mais sensível a mudanças no brilho do que na cromaticidade. Por
isso a divisão do frame em uma matriz de luminância e duas de cromância é feita. As matrizes
de cromância acabam então, sofrendo uma compressão maior do que a matriz de luminância.
O habitual método de compressão usado é o Discrete Cosine Transform (DCT), ou
transformada discreta de Cosseno. A técnica reduz as componentes de alta-freqüência da
imagem, uma vez que o olho humano é mais sensível a reconstruções de componentes de
baixa-freqüência.
As imagens podem ser codificadas em três tipos diferentes de frames. Os Intra-Coded
Frames (I-frames) são codificados usando apenas informações contidas no próprio frame
original, não havendo dependência com frames anteriores ou posteriores. Como cada frame
pode ser considerado como uma imagem, a compressão de um I-frame é semelhante à
realizada em uma imagem de padrão JPEG, por exemplo. Os Predictive-Coded Frames (P-
frames) são codificados de forma preditiva em relação a um quadro I-frame ou a um quadro
P-frame anterior. Ou seja, há pelo menos um macrobloco presente no quadro que possui uma
dependência com algum macrobloco de outra figura. Já os Bidirectionally-Predictive-Coded
Frames (B-frames) são codificados de forma preditiva em relação aos quadros I-frame ou P-
frame anteriores ou posteriores. Dessa forma, pelo menos um macro bloco de um quadro B-
frame possui dependência com algum quadro posterior a ele. Logo, para uma codificação B-
frame, é necessário que o quadro posterior ao qual ele possui essa dependência já tenha sido
codificado (Cavendish, 2005).
Cada frame codificado possui o parâmetro temporal_reference, que funciona como um
contador, utilizado para que o decodificador consiga detectar eventuais perdas de frames.
Os algoritmos que realizam a compressão MPEG buscam reduzir a redundância
temporal que existe entre os frames consecutivos. Eles tentam, por exemplo, eliminar
elementos que são iguais em dois frames seqüenciais. O método consiste em calcular o erro
de predição entre os blocos nas imagens atuais e nas imagens anteriores.
Outro tipo de compressão possível é usando a predição por compensação de
movimento. É feita uma estimativa de movimento entre as imagens do vídeo e a codificação
gera uma translação de pixels entre as imagens. Esse método é feito realizando a comparação
de macrobloco de uma figura com macroblocos pertencentes a figuras vizinhas. O macrobloco
da figura vizinha que mais se identificar com o do frame que está sendo codificado será usado
como referência na operação de predição. Um vetor de movimento indicando a diferença de
45
localização do macrobloco entre os dois frames é criado e transmitido junto com o
macrobloco codificado. Também é transmitida junto com o macrobloco, a posição em relação
ao macrobloco anterior, a indicação do método de predição e quais blocos de cromância e
luminância foram codificados.
Para facilitar a decodificação, a ordenação dos frames no fluxo é diferente da ordem
que os frames devem ser exibidos. Essa ordem garante que as figuras usadas como referência
pelos outros quadros sejam sempre recebidas antes dos quadros que as utilizam. Para a
exibição de um frame que usa codificação P-frame em referência a outro frame I-frame, é
necessário que o decodificador já tenha recebido o I-frame antes de decodificar o P-frame
(Cavendish, 2005).
Figura 10: Exemplo de ordem de apresentação em relação à ordem de codificação
A Figura 10 ilustra como deve ser a ordem. Como os frames 2 e 3 utilizam codificação
B-frame, que necessita dos frames posteriores para serem usados como referência (no caso, o
frame 4), o decodificador recebe primeiramente o frame 4 e depois os frames 2 e 3, que
possuem referência a ele.
46
2.4.2 - Camada de Sistemas
Definida no MPEG-2 Systems - recomendações H.222.0 (ITU, 2000a) – a camada de
sistemas é responsável pela divisão e encapsulamento dos fluxos gerados na compressão em
pacotes e pela multiplexação desses pacotes. Além disso, mantém a sincronização entre os
fluxos de mídias diferentes e pelo transporte da informação de referência do relógio utilizado
no codificador.
Existem duas formas de multiplexação. O fluxo de programa (Program Stream)
otimiza a decodificação para ambientes com menor ocorrência de erros e contém só um
conjunto de fluxos elementares (como áudio, vídeo ou dados). É o fluxo utilizado, por
exemplo, em sistemas de armazenamento, como os DVDs. O fluxo de transporte (Transport
Stream) pode conter mais de um conjunto de fluxos elementares e é otimizado para ambientes
onde a ocorrência de erros é mais freqüente, como nas transmissões de televisão digital, muito
suscetíveis a ruídos.
Após a compressão, os fluxos elementares de vídeo são divididos em pacotes em uma
subcamada chamada PES (Packetized Elementary Stream). Essa camada realiza a
identificação dos pacotes através de um parâmetro Stream_ID. A camada PES ainda realiza
uma sincronização intra e intermídia, através da colocação de marcadores de tempo
(timestamps) nos fluxos de PES e nos fluxos de sistemas. As timestamps inseridas no fluxo de
sistemas na subcamada de multiplexação permitem ao decodificador a recuperação da
referência de tempo em relação ao relógio usado no codificador. Esses timestamps são
denominados System Clock Reference (SCR) para os fluxos de transporte e Program Clock
Reference (PCR) para os fluxos de programa e são definidos em termos de um relógio de
sistema comum denominado System Time Clock (STC). Os valores dessas marcas de tempo
SCR e PCR indicam o instante em que o último bit desses campos entra no decodificador
(Cavendish, 2005).
Após o empacotamento desses dados nas PES, alguns pacotes são escolhidos e
recebem novos marcadores de tempo. Entre esses timestamps, destacam-se o Presentation
Time Stamp (PTS), que indica o tempo em que a unidade de apresentação deve ser exibida, e
o Decoding Time Stamp (DTS), que indica o tempo em que a unidade de apresentação deve
ser entregue ao respectivo decodificador. O DTS é usado quando é necessária uma
reordenação dos quadros pelo decodificador.
47
2.5 - MPEG-4
O MPEG-4 utiliza o padrão H.264, desenvolvido pela ITU-T Video Coding Experts
Group (VCEG) em conjunto com a Moving Pictures Experts Group (MPEG). Ele foi criado
com o intuito de fornecer uma qualidade de vídeo tão boa quanto a apresentada pelo MPEG-2,
mas gerando arquivos com apenas metade do tamanho. A implementação, entretanto, não
poderia ser muito complexa para não tornar o processo de codificação extremamente caro.
Para atingir seu objetivo, o MPEG-4 possui algumas diferenças em relação à
compressão. Ele permite, por exemplo, o uso de até 32 frames de referência, contra apenas 1
ou 2 frames nos métodos anteriores. Isso permite a geração de arquivos muito menores e
melhorias até na qualidade de imagem.
A técnica de predição por compensação de movimento também evoluiu bastante,
permitindo blocos com tamanho 4x4 e 16x16 e precisão de movimento dos blocos de até ¼ de
pixel. A performance também é amplamente melhorada nos efeitos de fade in e fade out.
Além disso, usa sistemas chamados de flexible macroblock reordering (ordenação dos
macroblocos flexível) e arbitrary slice ordering (ordenação arbitrária de fatias) para
reestruturar a maneira como os macroblocos são apresentados na imagem.
O H.264 ainda utiliza de duas técnicas de codificação denominadas “Codificação
aritmética binária adaptável segundo o contexto” (context-adaptive binary arithmetic coding,
CABAC) e “Codificação de comprimento variável adaptável segundo o contexto” (context-
adaptive variable-length coding, CAVLC), que usam algoritmos inteligentes para comprimir
streams de vídeo com perdas quase mínimas.
Há diversos novos meios de se evitar erros na codificação e decodificação também.
Entre eles, pode-se destacar a partição de dados, que permite separar pedaços mais
importantes e menos importantes da imagem em pacotes separados, permitindo que se faça
um controle maior de erros naqueles pedaços mais importantes. Usa também redundant slices,
(fatias redundantes) que permite que um codificador crie uma imagem extra – geralmente de
menor qualidade - de uma região de um frame, para ser usada se a representação preliminar
original do frame estiver corrompida.
Essas técnicas permitem que o MPEG-4 tenha um desempenho muito superior ao
MPEG-2, apresentando uma qualidade de vídeo semelhante – e, por vezes, até superior – com
arquivos que têm metade ou menos da metade do tamanho.
2.6 - MPEG-7
48
Seguindo os mesmos princípios do MPEG-4, o grupo MPEG iniciou um projeto de
outro padrão, o MPEG-7. Seu intuito era de estabelecer descrições (ou anotações) para
conteúdos multimídia de forma a possibilitar que buscas, filtragens e outros processamentos
similares fossem realizados de forma mais rápida e eficiente. Tais anotações também são
chamadas de metadados.
Este padrão provê diversas ferramentas para auxiliar na descrição e gerenciamento do
conteúdo, organização e navegação. A descrição do conteúdo pode ser transmitida ou
acessada por um dispositivo ou programa de computador, e pode ter diferentes interpretações
dependendo do contexto da informação.
O MPEG-7 não está focado em apenas uma aplicação em particular, ao invés disso, os
elementos contidos no MPEG-7 dão suporte à uma larga escala de aplicações possíveis, pois
são bastante genéricas (MPEG7, 2004). A necessidade de uma ferramenta de descrição em
conteúdos multimídia está diretamente relacionada com a necessidade que as novas
tecnologias tem com relação à eficiência e rapidez.
Um grande conjunto de ferramentas de descrição são definidas, e ainda uma
linguagem própria, com sintaxe semelhante à linguagem de marcação XML, que possibilita
aos desenvolvedores expandir a funcionalidade do padrão. Há também uma série de outras
ferramentas de sistema relativas à distribuição final das anotações MPEG-7, que realizam a
preparação dos dados para a transmissão (Martinez et al, 2002).
As ferramentas de descrição são representadas por elementos com metadados,
estruturas e relacionamentos, definidos como descritores e esquemas de descrição. A
descrição de um conteúdo multimídia é feita através de descritores que possibilitam a
indexação e classificação das informações. O padrão MPEG-7 fornece ferramentas para
descrição de regiões estáticas, regiões temporais e até mesmo regiões dinâmicas, que se
movem, no caso de vídeos.
A especificação deste padrão, assim como nos outros padrões MPEG, também está
definida em partes, cujas principais são: sistema, Description Definition Language (DDL),
vídeo, áudio e Multimedia Description Schemes (MDS). Antes de explicar cada uma delas é
preciso conhecer cada uma das definições a seguir, retiradas de (Martinez, 2002) de acordo
com definições presentes na especificação do padrão:
• Descriptor (descritor) – representa uma característica. Um descritor define a
sintaxe e a semântica de uma representação de uma característica;
• Description Scheme (esquema de descrição) – define a estrutura e o significado da
relação entre componentes que podem ser descritores ou outro esquema descrição;
49
• Description Definition Language (DDL, linguagem própria para definição de
descrições) – uma linguagem para definição ou alteração de descritores e
esquemas de descrição, provendo a possibilidade de expansão do padrão de acordo
com as necessidades do desenvolvedor;
• System Tools (ferramentas de sistema) – Ferramentas de apoio à multiplexação,
sincronização, transmissão e codificação (forma de texto e binária) das descrições
de maneira eficiente e proteção à propriedade intelectual.
A especificação define também uma implementação do software de referência da
especificação do padrão. Tal software é baseado em uma normalização com respeito ao
processo de decodificação, isto é, qualquer software produzido para trabalhar com este padrão
deve apresentar os mesmos resultados que o software de referência. Além disso, a
especificação define testes de conformidade e padrões para o uso e extração de descrições. Os
testes de conformidade, presentes em todos os padrões MPEG, especificam os métodos para
testes das descrições MPEG-7 para verificar se estão de acordo com o padrão, e os padrões
para uso e extração de descrições fornecem informações para extração de descrições das
streams MPEG e para o uso das ferramentas de descrição, utilizando o software de referência
mas também com outras abordagens (MPEG7, 2004).
2.6.1 - Sistemas MPEG-7
Esta parte especifica ferramentas de sistema para a preparação de descrições MPEG-7
para o transporte e armazenamento, viabilizando a sincronização com o conteúdo multimídia
de forma eficiente, além de atualizações e construção de descrições dinâmicas. Sistemas
MPEG-7 dispõe de todas as características necessárias para a representação de conteúdos
multimídia com descrições multiplexadas.
A entidade capaz de tratar tais informações são comumente chamadas de terminais (ou
MPEG-7 terminal) e podem ser representadas por aplicações independentes ou partes de um
outro sistema. A arquitetura desses terminais é dividida em três camadas: aplicação,
normalização (que é responsável pela sincronização e gerenciamento das descrições) e
distribuição (que é responsável pela abstração do meio transmissão e armazenamento
proporcionado por este padrão), conforme definido na especificação ISO do padrão (MPEG7,
2004). A distribuição herda características de outros padrões como o MPEG-4 e o MPEG-2
como o conceito de elementary streams. Essas streams consistem em pequenas partes
consecutivas de dados, que são individualmente acessados, chamados de access units
(unidades de acesso) e dentro dessas unidades estão as descrições e definições de esquemas
50
referentes ao padrão. Há também uma camada no sistema responsável por reagrupar essas
pequenas unidades para reconstituir os dados de descrições (Martinez, 2002).
Outra característica importante do sistema é a utilização do formato BiM (Binary
Formato for MPEG-7) para a representação binária das descrições MPEG-7, que
originalmente são feitas em XML, que por sua vez não foi feita para trabalhar com sistemas
de tempo-real, por exemplo, conteúdo multimídia. O formato BiM possibilita a compressão e
distribuição streaming de documentos XML.
2.6.2 - MPEG-7 Description Definition Language
As principais ferramentas usadas na implementação das anotações MPEG-7 são:
Description Definition Language (DDL), Description Schemes (DSs) e Descriptors (Ds).
DDL constitui a parte principal do padrão MPEG-7, pois fornece elementos descritivos onde
os usuários podem criar seus próprios esquemas de descrição e descritores para expandir a
usabilidade do padrão de acordo com suas necessidades. Representa a modelagem do
conteúdo multimídia em forma de linguagem de texto.
Com a DDL é possível representar relações conceituais, espaciais, temporais e
estruturas de elementos, pois sua modelagem é bastante completa em termos de referências e
relações entre esquemas de descrição e descritores.
Em resumo, DDL define as regras gramaticais de uma linguagem derivada do XML
(eXtensible Markup Language), com sua própria sintaxe e semântica para expressar e
combinar esquemas de descrição e descritores (MPEG7, 2004). Também é importante lembrar
que é possível alterar definições já existentes de esquemas de descrição e descritores.
Esta é uma linguagem legível tanto para seres humanos quanto para máquinas, porém
as máquinas necessitarão de um analisador sintático, capaz de validar o conteúdo e a estrutura
de um documento DDL, bem como os tipos de dados definidos na especificação da
linguagem. Também deverão ser capazes de validar descrições MPEG-7 de acordo com seus
respectivos esquemas de descrição (MPEG7, 2004).
O uso de esquemas XML proporciona à linguagem DDL a facilidade de
interoperabilidade necessária para a extensão dos descritores e esquemas de descrição.
Também é possível que outras aplicações baseadas em XML utilizem o MPEG-7 para
estender suas funcionalidades com descrição de conteúdos multimídia.
Abaixo segue um exemplo de uso da linguagem DDL para anotação do logo MPEG,
retirado de (Martinez, 2002): <Mpeg7 xmlns=“http://www.mpeg7.org/2001/MPEG-7_Schema” xml:lang=“en”
51 type=“complete”> <ContentDescription xsi:type=“ContentEntityType”> <MultimediaContent xsi:type=“ImageType”> <Image> <MediaLocator> <MediaUri> http://www.tilab.org/mpeg/mpeg_logo-anim_l.gif </MediaUri> </MediaLocator> <CreationInformation”> <Creation> <Title xml:lang=“en”>The animated MPEG Logo</Title> <Creator> <Role href=“urn:mpeg:mpeg7:cs:RoleCS:AUTHOR”> <Name xml:lang=“en”>Author</Name> </Role> <Agent xsi:type=“OrganizationType”> <Name>MPEG</Name> </Agent> </Creator> </Creation> <RelatedMaterial> <MediaLocator> <MediaUri>http://www.tilab.com/mpeg/</MediaUri> </MediaLocator> </RelatedMaterial> </CreationInformation> </Image> </MultimediaContent> </ContentDescription> </Mpeg7>
Código DDL da descrição do logo MPEG a seguir
Figura 11: Logo MPEG descrito pela anotação MPEG-7
2.6.3 - MPEG-7 Visual
Especifica ferramentas de descrição de elementos visuais, como vídeo e imagens
estáticas. Ferramentas de descrição visuais consistem em estruturas básicas e descritores
visuais, que são baseados em características semelhantes que possibilitam a identificação de
similaridades em vídeos e imagens. Também são usados para filtragens e buscas baseadas em
diversas características como cor, textura, formas, movimento e localização. Cada uma destas
categorias tem desde descritores básicos até os mais avançados e específicos. Esses
descritores são classificados em genéricos e específicos de aplicação. Os específicos de
aplicação podem, por exemplo, ser utilizados em aplicações com processamento de imagem,
52
como localização de veículos e reconhecimento de faces (Martinez, 2002). Já os genéricos são
classificados em (MPEG7, 2004):
• Básicos – interpolação, coordenadas 2D, visões 2D e 3D, temporal, etc;
• Cor – cor dominante, estrutura de cor, espaço de cor, etc;
• Textura – textura homogênea ou heterogênea, navegação por textura;
• Forma – baseados em região, contorno ou formas 3D;
• Movimento – movimento de câmera, trajetórias, etc;
• Localização – localização regional e especial-temporal;
Figura 12: Exemplo de aplicação de descrição em uma cena de vídeo, retirado de (MARTINEZ; KOENEN; PEREIRA, 2002)
53
2.6.4 - MPEG-7 Áudio
Especifica ferramentas de descrição de elementos de áudio, como música e fala.
Descritores desse tipo são considerados de baixo nível quando se referem à características
paramétricas, temporais, e de espectros dos sinais de áudio (também conhecido como MPEG-
7 Audio Framework) e de alto nível quando são mais específicos para uma determinada
aplicação, usados em situações como anotar o timbre ou melodia de um instrumento,
conteúdo falado ou até mesmo reconhecimento de som (MPEG7, 2004). Os descritores de
áudio de alto nível são classificados em (Martinez, 2002) :
• Combinação de áudio (descreve a semelhança espectral dos sons);
• Combinação de Timbre (identificação, busca e filtragem);
• Busca por melodia (descritores de melodia simples e completos);
• Reconhecimento de som e indexação;
• Fala
2.6.5 - MPEG-7 Multimedia Description Schemes
Especifica os descritores e esquemas de descrição para características genéricas e
descrições multimídia, incluindo esquemas de descrição de áudio, vídeo, e de outros tipos
(Martinez, 2002). São basicamente, modelos de objetos multimídia e do universo que
representam. Especificam tipos de descritores que podem ser usados em uma determinada
descrição, e as relações entre esses descritores ou entre outros esquemas de descrição.
Para criar descrições MPEG-7 de qualquer conteúdo multimídia, a primeira etapa é
criar um wrapper (esquema ao qual será atribuída a descrição) para a descrição utilizando as
ferramentas de esquema. As diferentes ferramentas utilizadas para criação de descrições usam
elementos básicos genéricos, que representam o alicerce do MPEG-7 para extensão da
linguagem fornecida.
2.6.6 - MPEG-7 Description Tools
MPEG-7 Description Tools define um conjunto padronizado de descritores e
esquemas de descrição, baseado em suas funcionalidades, porém nada impede de mesclar
vários descritores e esquema de descrição de funcionalidades diferentes em um processo de
anotação, desde que faça algum sentido lógico, através da ferramenta Schema Tools (ou
ferramentas de esquema). São basicamente agrupados em (Martinez, 2002):
• Elementos Básicos – entidades genéricas utilizadas por outras ferramentas de
descrição;
54
• Ferramentas de esquema – disponibiliza as ferramentas de descrição para as
aplicações;
• Ferramentas de descrição de conteúdo – representa informação perceptível, como
aspectos estruturais, conceituais, audiovisuais, etc;
• Ferramentas de gerenciamento de conteúdo – especifica características da mídia,
criação e uso da mesma;
• Ferramentas de organização de conteúdo – permite criar e modelar conjuntos de
conteúdo multimídia e descrições;
• Ferramentas de acesso e navegabilidade – especifica particionamento e
decomposição de conteúdo multimídia para facilitar a navegação;
• Ferramentas de interação com o usuário – descreve preferências do usuário e
mantém um histórico de uso do conteúdo multimídia.
Figura 13: Organização das ferramentas de acordo com a funcionalidade
2.7 - MPEG-21
O formato MPEG havia alcançado seus objetivos de compressão de formatos de mídia
com boa qualidade e utilizando pouco espaço. Entretanto, a mídia somente não basta para
divulgar algumas informações. O MPEG-21 surge com o objetivo de transportar mais do que
vídeo em um arquivo de mídia. Isso permite um uso mais específico do conteúdo de mídia,
baseado, por exemplo, nas preferências do usuário ou nas capacidades do dispositivo. Com
55
isso é possível fazer um controle sobre quem acessa a mídia, permitindo um maior controle
sobre os direitos autorais de um item digital.
Há muitas semelhanças entre o MPEG-7 e o MPEG-21, principalmente no que diz
respeito às ferramentas de descrição que os dois sistemas adotam. O MPEG-21 é focado em
estabelecer a relação entre um item digital e aquele que o usa. Entende-se por item digital a
combinação de recursos como vídeo, imagens, textos, metadados (que podem ser usados para
identificação do conteúdo) e a estrutura que descreve a relação entre esses recursos. Um
usuário é qualquer um que possa interagir com aquele conteúdo, incluindo o criador, o
distribuidor, o detentor dos direitos autorais e o consumidor final.
Entretanto, por ser um formato ainda em desenvolvimento, várias partes do padrão
ainda não estão completamente definidas. Dentre as partes que já possuem especificação
definida, podemos citar:
• Multimedia Framework: Define os elementos para a inclusão correta dos recursos
de multimídia, assim como a integração, criação, manipulação, controle, e
distribuição desses itens digitais;
• Digital Item Declaration: Define uma série de termos e conceitos que serão usados
para definir itens digitais;
• Digital Item Identification: Identifica o item digital e suas partes;
• Intellectual Property Management and Protection: Framework que funcionará
como uma forma de proteção de direitos de propriedade intelectual em um arquivo
áudio-visual;
• Rights Expression Language: Define uma linguagem, baseada nos termos do
Rights Data Dictionary, que pode declarar direitos e permissões para arquivos
áudio-visuais, permitindo maior controle no uso desses arquivos e em sua
distribuição, publicação e consumo;
• Rights Data Dictionary: Define uma série de termos bem estruturados e integrados
que visam atender todas as necessidades do Rights Expression Language;
• Digital Item Adaptation: Provê mecanismos de descrição de informações
relacionadas a um ambiente e a um formato que podem ser utilizadas em um
mecanismo de adaptação, possibilitando acesso transparente a itens digitais;
• Reference Software: Define softwares que implementam as funcionalidades
previstas em MPEG-21;
• File Format: Define um formato de arquivo para o MPEG-21, de forma que seja
compatível com os demais formatos MPEG.
56
Como é possível verificar, o formato MPEG-21 está se direcionando para o uso e
manipulação de itens digitais. Para definir um item digital que será usado no padrão MPEG-
21, é necessário seguir algumas normas. A Digital Item Declaration (DID - Declaração de
item digital) - ISO/IEC 21000-2 - define a estrutura e organização que deve ser seguida em
um item digital (Burnett et al, 2003). O objetivo é definir termos e conceitos que definem o
que é um item digital. Para isso, é usada a Digital Item Declaration Language (DIDL), que
define um XML com flexibilidade suficiente para representação de complexos itens digitais.
A DIDL é composta de alguns elementos, podendo citar:
• Contêiner: Permite o agrupamento de itens ou outros contêineres. Os contêineres
podem formar pacotes lógicos – úteis no transporte de dados ou na organização
dos elementos de um item digital;
• Item: É o agrupamento de componentes ou subconjuntos que são ligados a
descritores relevantes. Podem conter diversas opções de configuração para que um
item possa ser personalizado. Um item pode ou não conter subitens. Se um item
contém um subitem, ele é chamado de “compilação”. Se ele não contém, ele é
chamado de “entidade”. Um item é, na verdade, uma representação declarativa de
um item digital;
• Componente: Associa um recurso a todos os seus descritores relevantes. Esses
descritores contém informações relacionadas à uma instância do recurso ou à parte
dela. Os descritores comumente contêm informações estruturais sobre o recurso –
tais como tamanho, informações de decriptação, pontos de início etc – mas não
informações descritivas sobre o recurso;
• Âncora: Faz a ligação entre descritores e fragmentos, correspondendo à
localização específica de um recurso ou de parte dele;
• Descritor: Associa informações com um elemento. Essa informação pode ser
baseada em texto ou pode ser outro componente – como uma imagem;
• Condição: Descreve o elemento como sendo opcional e faz um link dele com as
condições que afetam a sua inclusão. Múltiplos predicados inseridos em uma
mesma condição geram uma conjunção (relação AND). Múltiplas condições
associadas geram uma disjunção (relação OR);
• Escolha: Designa uma série de seleções que podem afetar a configuração de um
item;
57
• Seleção: Descreve uma decisão que afeta uma ou mais condições em um item.
Pode retornar um predicado sendo verdadeiro, falso ou indefinido;
• Anotação: Uma anotação descreve informações sobre outro elemento do modelo
sem alterar ou adicionar qualquer coisa ao elemento. As anotações podem ter o
formato de afirmações, descrições e âncoras;
• Afirmação: Descreve a configuração de estado de uma escolha completa ou
parcial, definindo valores para alguns predicados associados com alguma seleção
para uma escolha como sendo verdadeiros, falsos ou indefinidos;
• Recurso: Qualquer objeto – vídeo, áudio, texto, imagem – individualmente
identificável. Pode ser também potencialmente um objeto físico. Os recursos
devem ser localizados por endereços que não sejam ambíguos;
• Fragmento: Designa um ponto específico ou um intervalo de um recurso;
• Indicação: É um valor textual literal que contém uma informação mas não é um
recurso. Exemplos de indicações podem ser: uma descrição ou uma informação de
identificação;
• Predicado: É uma declaração que pode ser verdadeira, falsa ou indefinida.
Um exemplo do uso dos elementos definidos no Digital Item Declaration Language
pode ser visto na figura a seguir (Burnett et al, 2003):
Figura 14: Exemplo do uso dos elementos da Digital Item Declaration Language
58
O MPEG-21 ainda é composto por um Digital Item Identification – Identificação de
Item Digital, cuja função inclui identificar os itens digitais e suas partes, o endereço de IP
relacionado aos itens digitais e os esquemas de descrição. Além disso o Digital Item
Identification especifica como usar os identificadores para relacionar os itens digitais com as
informações contidas em suas respectivas descrições em metadados. Digital Item
Identification também indica como devem ser identificados os diferentes tipos de Itens
digitais.
Outra preocupação é com os direitos autorais dos arquivos de mídia. MPEG-21
estabelece um framework para o Intellectual Property Management and Protection (IPMP).
Para isso, ele faz uso de um Right Expression Language (REL), que permite declarar direitos
e permissões usando os termos definidos em um Right Data Dictionary (RDD). O RDD forma
a base de todas as expressões definidas no REL. O RDD e o REL provêem mecanismos para
controlar o uso dos recursos digitais na publicação, distribuição e uso desses recursos – áudio,
filme, livros, jogos, softwares e qualquer outra criação em formato digital – com o objetivo de
proteger o conteúdo e os direitos autorais especificados.
Por ser um formato muito recente, muito ainda vêm sendo discutido em relação a
novas funcionalidades que o MPEG-21 pode vir a apresentar. Um exemplo é o Digital Item
Adaptation, que especifica um conjunto de ferramentas de descrição para auxiliar a adaptação
de itens digitais.
59
Capítulo 3 – Desenvolvimento da Aplicação A proposta do trabalho é oferecer um método diferenciado para a apresentação de
produtos de uma loja virtual para televisão digital. Partindo da idéia de que os produtos serão
mostrados ao decorrer da programação, e de que o fluxo de dados MPEG será constante
durante a exibição da programação do canal, os produtos seriam extraídos do próprio vídeo,
baseado nos padrões MPEG-7 e MPEG-21. Para que tal operação seja possível, é necessário
que o lado do provedor de serviços tenha a capacidade de codificação do vídeo com os
padrões apresentados e o lado do usuário (STB) tenha a capacidade de decodificação.
3.1 – O Emulador
O emulador utilizado, o XleTView, disponível em http://xletview.sourceforge.net,
encontra-se em fase bastante inicial. Sua versão atual mais estável que pode ser encontrada no
site oficial do emulador é a 0.3.6, que apresenta uma implementação parcial, que deixa de
lados diversos elementos necessários para o desenvolvimento total da aplicação de loja virtual
sugerida. Um exemplo dessa ausência de funcionalidade é a falta da simulação de um fluxo de
dados MPEG, como aconteceria em um STB, sendo assim, impossível obter um vídeo em
tempo real, ou seja, para que o emulador rode vídeos é necessário que o vídeo esteja presente
por inteiro no disco local. Também não estão presentes decodificadores para os padrões
MPEG-7 e MPEG-21, portanto não seria possível extrair do vídeo, metadados MPEG-7 e
MPEG-21 ou mesmo fazer uso de ferramentas MPEG-21 para controle multimídia, de acesso,
entre outros.
O XleTView permite a visualização de xlets Java sobre o middleware MHP no
computador e é distribuído e desenvolvido pela GNU General Public License (GPL).
Desta forma é impossível desenvolver a aplicação da maneira desejada utilizando este
emulador, ou seja, recebendo os dados já decodificados do formato MPEG-7 e MPEG-21,
onde o STB será o encarregado de separar estes dados e disponibilizá-los para a aplicação.
Devido a esta restrição outros emuladores que possuem implementação de algum padrão de
televisão digital foram pesquisados, como o Cardinal Studio da Cardinal Systems e o
AltiComposer da Alticast, mas como todos estes são soluções comerciais e disponibilizam
apenas versões de demonstração que duram por 30 dias, também não foi possível a sua
utilização para desenvolvimento do sistema. Ainda assim, o que aparentou ser o mais
completo foi o AltiComposer e segundo sua descrição no site oficial, não implementa
60
decodificação de MPEG-7 nem MPEG-21. A implementação destes padrões está diretamente
associada ao suporte de padrões MPEG do padrão de televisão digital, no caso, o MHP.
Segundo o site oficial do projeto XleTView, na versão 0.3.6, de 2004, das 373 classes
e interfaces listadas referentes às implementações das APIs DAVIC, HAVi, DVB-MHP e
JavaTV, apenas 245 estão completamente implementadas, 1 tem um bug conhecido, 15 estão
sob implementação e 112 ainda não foram implementadas. Enquanto a versão mais atual,
listada como não-estável, a versão 0.3.7 de 2005, apresenta 247 classes completamente
implementadas, 1 com bug conhecido, 16 sob implementação e 109 ainda não implementadas.
Desde esta última versão, nenhuma atualização foi feita, o que sugere que o projeto foi
descontinuado.
A versão escolhida para o desenvolvimento da aplicação foi a XleTView 0.3.7, que,
mesmo sendo a última, já está defasada e não suporta diversas funcionalidades que estavam
nos planos da implementação inicial. Esta versão foi levemente modificada para facilitar a
depuração da aplicação.
3.1.1 – Suporte à vídeos
O suporte à multimídia na versão do emulador XleTView utlizada, é limitado aos
formatos de áudio e vídeo suportados pela API JMF versão 2.1.1. A API JMF – Java Media
Framework – permite a decodificação de conteúdo multimídia dentro de uma aplicação Java.
A conversão é necessária porque o número de formatos que a API JMF consegue suportar é
baixíssimo, e sendo assim, alguns formatos de vídeo mais populares foram deixados de lado,
como MPEG-2, MPEG-4, Windows Media, Real Media, entre outros, até porque alguns são
formatos proprietários, como é o caso do Windows Media.
A tabela a seguir apresenta os formatos que podem ser lidos pelo JMF. Os que
estiverem marcados com a letra “D” podem ser lidos e apresentados, e os que estiverem
marcados com a letra “E” podem ser ainda codificados no devido formato. Se o formato pode
ser lido de um arquivo (input), ele estará marcado com “read”. Se ele pode ser escrito a partir
da aplicação, ele estará marcado com “write”. A linha da tabela marcada em cinza escuro
representa o o tipo de vídeo utilizado na compressão.
61
Tabela 2: Suporte a formatos multimídia da API JMF
Formato
JMF 2.1.1 JMF 2.1.1 Versão
independente de plataforma
Versão Windows
AVI (.avi) Leitura/escrita Leitura/escrita Audio: 8-bit mono/stereo linear D,E D,E
Audio: 16-bit mono/stereo linear D,E D,E Audio: DVI ADPCM compressed D,E D,E
Audio: G.711 (U-law) D,E D,E Audio: A-law D D
Audio: GSM mono D,E D,E Audio: ACM** - D,E
Video: Cinepak D D Video: MJPEG (422) D D,E
Video: RGB D,E D,E Video: YUV D,E D,E
Video: VCM** - D,E MPEG-1 Video (.mpg) - Apenas leitura
Multiplexed System stream - D Video-only stream - D
MPEG Layer II Audio (.mp2) Apenas leitura Leitura/escrita MPEG layer 1, 2 audio D D,E
O formato utilizado nesta aplicação foi o Cinepak, convertido com o software RAD
Video Tools disponível para download em http://www.radgametools.com/bnkmain.htm. A
princípio, a intenção era de utilizar o formato MPEG-2, por ser mais próximo da realidade
quanto aos padrões de televisão digital, porém, com a versão da JMF utilizada pelo emulador
(que pouco difere da versão mais recente no quesito compatibilidade de formatos) não é
possível a decodificação do formato. O formato Cinepak tem baixa taxa de compressão se
comparado ao MPEG-2, e a perda de qualidade também é maior: um vídeo de 1 minuto e 53
segundos compactado com o codec Windows Media Video (extensão .wmv) ocupava 2.53MB
de espaço em disco, quando convertido para MPEG-2, passou a ocupar aproximadamente
23MB sem perda de qualidade perceptível, e quando convertido utilizando-se o Cinepak,
ficou com 77MB e houve uma perceptível redução de qualidade.
3.1.2 – Modificações no Emulador
Algumas modificações foram feitas na versão 0.3.7 do emulador XletTView. Isso
ocorreu porque esta versão, que estava disponível no repositório de códigos do projeto, não
era considerada versão estável e para distribuição, portanto continha um mecanismo de
depuração que gerava um histórico de todas as ações do emulador no próprio console onde era
62
executado, e este mecanismo não estava acompanhado de código-fonte, apenas de códigos
intermediários Java.
Para contornar este problema, foi criada uma janela para o armazenamento de
mensagens das xlets, apenas para guardar a saída da aplicação, separando-a da saída do
emulador. Este mecanismo foi o mais próximo de uma depuração que foi possível chegar
neste trabalho, se tratando de uma xlet, cujos arquivos binários são carregados em tempo de
execução e não são percebidos pela ferramenta de desenvolvimento utilizada. A figura a
seguir mostra o funcionamento da janela durante a execução da xlet da loja virtual.
Figura 15: Imagem da janela de log
3.2 – A aplicação
Para explicar como a aplicação funciona, bem como seu comportamento dentro de um
STB, é necessário entender suas funcionalidades primeiro. Já se sabe que a aplicação é uma
loja virtual para televisão digital, porém, uma aplicação para tal plataforma difere de uma em
plataformas mais convencionais para este tipo de aplicação, como por exemplo computadores
pessoais ou smart phones. É possível perceber melhor essa diferença analisando variáveis
como resolução da tela do dispositivo utilizado, poder computacional, e até o foco da
plataforma em questão: em uma televisão digital o foco na tela será, na maior parte das vezes,
o vídeo que estará sendo exibido e não a loja virtual, enquanto em um computador pessoal, o
foco na tela geralmente será a loja virtual.
No caso da televisão digital a aplicação deve ser mínima, estritamente relacionada com
a sua funcionalidade e sem quaisquer outros recursos que poderiam ser considerados de
importância secundária. Baseado nisso, a aplicação, do ponto de vista do usuário contém
apenas uma interface que varia de conteúdo e tamanho de acordo com comandos do usuário.
São considerados comandos, toques nos botões do controle remoto. O usuário que desejar
63
visualizar os produtos da loja, deverá primeiramente ativar a exibição de anúncios, que poderá
ser feita a qualquer momento, através de uma possível aplicação para a configuração do
serviço, ou ainda, através do botão azul do controle remoto. O usuário saberá da interação
com o botão azul e sua relação com a loja virtual através de propagandas do próprio serviço
durante a programação, ou através de um alerta sonoro ou um discreto alerta visual na tela,
notificando-o a respeito de uma possível interação.Desta forma, quando houver um anúncio
da loja disponível naquele intervalo de tempo, a aplicação exibirá sobre o vídeo, uma pequena
interface, alertando-o da existência de um produto à venda, como na figura a seguir.
Figura 16: Imagem da xlet em execução sobre o vídeo
Nesta interface, será possível visualizar uma miniatura da foto do produto, caso esteja
disponível, bem como seu nome e uma breve descrição, acompanhados com um botão
vermelho e um botão verde, respectivamente simbolizando ações para ver mais detalhes do
produto e partir para a compra imediatamente. Ambas as cores, neste modelo, estão
diretamente ligadas às cores dos botões no controle, para facilitar a interação do usuário com
a aplicação.
64
Também é possível visualizar na figura anterior o remoto existente no emulador. É
importante lembrar que um controle remoto para televisão digital deve ter mais botões do que
o normal para facilitar a interação com o usuário e o controle de aplicações na tela. No caso
desta xlet, os botões coloridos servirão para ações dentro da aplicação e acarretarão em uma
transição nas formas da interface do programa enquanto o botão com o texto “exit” terá a
função de desligar a exibição de propagandas daquele determinado serviço (comumente
chamado de canal na televisão analógica), ou seja, invocar um método de destruição da xlet
responsável pela loja que ainda reside no STB, para que este dê continuidade no ciclo de vida
desta xlet.
Quando o usuário aperta o botão vermelho referente à tela de mais informações, a
mesma interface tem o tamanho aumentado e seu conteúdo atualizado com uma foto maior do
produto caso esteja disponível, sua descrição completa, preço de compra pela televisão digital
e opção de compra. Tanto a foto versão miniatura quanto a foto grande do produto podem ou
não aparecer não só devido a ela existir ou não para determinado produto, mas também por
possíveis erros nas decodificações dos padrões MPEG-7 e MPEG-21 envolvidos.
Figura 17: Interfaces de exibição de detalhes e confirmação de compra
Se o usuário deseja comprar o produto, basta apertar o botão verde, a qualquer
momento da exibição do anúncio, que ele será remetido à interface de compra, com um
simples formulário, semelhante à formulários encontrados freqüentemente na web, onde ele
deverá usar um código único por assinante previamente cadastrado com a fornecedora do
sinal de televisão digital. Para este campo do formulário, apesar de o código ser confidencial
do usuário, alguns fatores foram levados em consideração para que o campo não funcionasse
65
de modo análogo ao campo de senha em um formulário web: o fato de que apertar os botões
numéricos do controle de televisão digital, inutiliza funcionalidades de troca de canal durante
o tempo em que o campo detém o foco na tela e ter que digitar duas vezes aumentaria ainda
mais esse tempo, e também que este campo só terá validade no local onde se encontra o
respectivo STB, ou seja, o usuário só poderá utilizar seu código no local onde está cadastrada
a sua assinatura. Para esta aplicação, o ideal é que houvesse assinatura de televisão digital à
cabo, pois o mesmo cabo serviria para transmissão do sinal de televisão e para transmissão de
dados pela internet, que será necessário no momento da compra, já que estes dados precisam
ser retornados ao provedor de serviço de televisão.
Esta comunicação com o serviço ocorre de forma totalmente transparente para o
usuário sob as condições citadas, e realiza a autenticação no servidor, que retorna uma
resposta ao usuário pelo mesmo canal de comunicação, realizando assim, a operação de
autenticação e validação da compra. Esta ação pode gerar erro, caso o formulário não tenha
sido preenchido corretamente ou o serviço tenha recusado a requisição, ou pode finalizar a
compra caso o serviço tenha validado a compra. Em caso de validação da compra, neste
modelo, o valor deverá ser descontado na próxima fatura do usuário.
Figura 18: Interfaces de resultado da confirmação de compra: sucesso e erro
3.3 – Desenvolvimento da Xlet
Para compreender como a aplicação funciona em um nível mais baixo, neste item
serão apresentados trechos de código da aplicação xlet e seu significado perante a modelagem
do problema, ou seja, para que foi utilizado no desenvolvimento da loja virtual.
A aplicação da loja virtual foi desenvolvida sob os moldes de uma xlet descrita pela
API Java TV e com base em uma modelagem UML (Booch et al., 1998) de 5 camadas. São
elas: cliente, apresentação, negócios, integração e dados. O código fonte do programa foi
organizado de forma semelhante à organização em camadas, separando-as em pacotes, cada
um com sua respectiva estruturação interna. Esta estruturação será apresentada a seguir, na
mesma ordem em que são apresentadas as camadas.
66
Alguns padrões de programação GoF (Freeman et al., 2001) e também alguns padrões
extraídos da Java Enterprise Edition (Alur et al., 2003) foram utilizados e serão explicados à
medida em que forem apresentados.
Em seguida, serão apresentados diagramas de seqüência para demonstrar como
funciona a execução inicial do programa até o momento da exibição de um anúncio e também
de um evento de compra gerado pelo usuário.
3.3.1 - Pacote org.tgi.store.view
Neste pacote, encontra-se apenas a classe principal da aplicação denominada Store.
Esta classe representa a xlet em si e portanto é a base da loja virtual. Para esta classe ser
considerada uma xlet, é necessário que a interface Xlet do pacote xjavax.tv.xlet, definida na
implementação da API Java TV do emulador, seja implementada, e com base nos métodos
herdados desta interface, a xlet será informada sobre qualquer mudança de estado gerada pelo
gerente de aplicações dentro do STB e dessa forma, poder finalizar seus componentes antes de
ser reciclada pelo STB, ou seja, passar para o estado Destroyed ou apenas ter sua execução
interrompida.
Figura 19: Pacote cliente
Nos testes realizados, foi possível concluir que a xlet é carregada dinamicamente pelo
STB. Em outras palavras, o STB, no momento em que recebe a xlet pelo fluxo de dados de
entrada, não conhece sua implementação, mas pode tentar carregá-la, fazendo-a passar para o
estado Loaded e executá-la através da interface já conhecida e padrão para xlets
implementada na API Java TV. O mesmo acontece com quaisquer outras classes que são
utilizadas no decorrer da execução da xlet.
Por exemplo, quando a xlet tentar acessar um objeto cuja definição não está disponível
dentro do próprio STB, supõe-se que esta classe tenha sido enviada junto com a xlet no fluxo
de dados, e então o STB tenta carregá-la dinamicamente assim como fez com a própria xlet.
67
Esse é o esquema de funcionamento do emulador XleTView e talvez gere algum pequeno
atraso na execução da aplicação, que pode se tornar quase imperceptível dependendo do poder
computacional do STB e do tamanho do respectivo arquivo em disco.
Essa busca por definições de classe dinamicamente ocorre, no caso da aplicação da
loja virtual, quando a xlet se comunica com as classes da camada de apresentação.
A xlet se comunica com classe StoreController da camada de apresentação assim que
passa para o estado Active, para informar, através de seu contexto de execução, a instância do
gerenciador de execução da mídia, no caso uma instância de Player. Outras operações
importantes que a xlet faz assim que passa para este estado, são os registros junto às classes
StoreController e ProductEventManager que fazem a classe receber eventos da camada de
apresentação, para que seja possível atualizar a interface da aplicação. Para isso, a xlet
implementa as interfaces AnnounceListener e ProductListener, que são explicadas na próxima
camada. O registro nada mais é do que uma referência ao objeto da xlet que uma classe
gerenciadora de eventos possui.
3.3.2 - Pacote org.tgi.store.presentation
Este pacote reúne as classes da camada de apresentação e é nesta camada que se
concentra a maior parte das classes desta aplicação.
68
Figura 20: Pacote de apresentação
Por se tratar de uma aplicação onde a parte visual é extremamente importante, pois não
se deseja interferir excessivamente na exibição do vídeo, há bastante lógica de interface e é
nesta camada que é feita a comunicação com a camada de negócios para a efetuação da
respectiva lógica. Esta camada é uma ponte entre a camada cliente e de negócios, e está mais
relacionada com a camada cliente do que com a camada de negócios.
A classe mais importante é a StoreController que é uma thread que é implementada
utilizando-se o padrão GoF Singleton (Freeman et al., 2001), para que haja apenas uma
instância desta thread. Esta thread é disparada assim que a xlet entra no estado Active, e tem a
função de solicitar à camada de negócios uma listagem dos anúncios dos produtos descritos
no arquivo MPEG-7 recebido pelo fluxo de entrada de dados, e também de sincronizar a
exibição de anúncios com o vídeo transmitido pelo canal. Para isto, esta thread verifica o
exibição do vídeo a cada segundo. Isto é feito através de uma referência ao objeto do
gerenciador de execução da mídia, que por sua vez é recebida pela classe Store, e analisa em
sua lista de anúncios se algum dos anúncios pertence àquele segundo.
69
É importante ressaltar que esta lista é administrada da seguinte forma: assim que a
thread encontra um anúncio para começar a ser exibido naquele instante de tempo, este
anúncio é removido da lista, pois não aparecerá novamente e a thread pausa a sua execução
por uma quantidade de tempo estipulada no próprio anúncio. Também é importante ressaltar
que nesta lista, os anúncios estão organizados por ordem cronológica. Estas duas medidas
foram tomadas para que a execução do programa não necessitasse de muito processamento
por parte do STB, ou seja, a fim de otimizar a aplicação.
A classe StoreController ainda implementa o padrão GoF Observer (Freeman et al.,
2001), semelhante ao mecanismo de “listeners” encontrado no pacote java.awt.event. Esta
classe mantém uma lista de objetos que implementam a interface AnnounceListener do pacote
org.tgi.store.presentation.event. Desta forma, quando a thread encontra um anúncio para
exibição naquele segundo, ela gera eventos do tipo AnnounceEvent, e os envia para todos os
itens desta lista, avisando que o anúncio deve ser exibido. Então a thread pausa, e quanto
retorna, gera outro evento para que os anúncios sejam escondidos.
Figura 21: Pacote de interface gráfica da camada de apresentação
70
Já no pacote org.tgi.store.presentation.ui encontram-se componentes visuais, que
derivam da API HAVi para televisão digital, pois a mesma implementa componentes de
forma padronizada, e cada STB tem a sua implementação desta API, ou seja, podem haver
componentes que sejam visualmente diferentes de um STB para outro. Por isso, estes
componentes foram criados.
No pacote org.tgi.store.presentation.ui.layout encontram-se os components visuais
personalizados para a exibição do anúncio. A classe StoreLayoutManager, que também adota
o padrão GoF Singleton (Freeman et al., 2001), é responsável pela criação de novas instâncias
de AnnounceContainer, que nada mais é do que um contêiner visual, que engloba
componentes que representam o texto, a imagem e os botões do anúncio. A maneira como
será exibida esses componentes dentro do contêiner dependerá da instância de StoreLayout.
A classe abstrata StoreLayout e todas as classes que a implementam fazem parte de
um padrão GoF do tipo comportamental, denominado Strategy (Freeman et al., 2001). Cada
uma das classes que implementam esta interface, dispõem de componentes visuais diferentes
para representar o anúncio, ou seja, são maneiras diferentes de representar um mesmo tipo de
dado na tela. Neste caso são utilizadas para ilustrar as etapas de visualização do anúncio,
visualização de detalhes do produto, autenticação e compra ou ainda mensagens de erro ou
sucesso na compra. Todas fazem uso da classe LineBreakHelper do pacote
org.tgi.store.presentation.ui.helper para auxiliar na quebra de linha dos textos exibidos no
contêiner, de acordo com o tamanho dos componentes, realizando uma tarefa simples, mas
que não estava implementada por padrão.
A classe AnnounceContainer também implementa a interface ProductListener e se
registra em ProductEventManager (outro Singleton), num mecanismo igual ao da classe
StoreController que implementa o padrão GoF Observer (Freeman et al., 2001). Só que desta
vez, os eventos são gerados quando o usuário pressiona um botão do controle remoto, e este
evento do botão acarreta em uma alteração na interface, como por exemplo, apertar o botão
vermelho para visualizar a interface de detalhes do produto. No momento em que o
AnnounceContainer recebe um evento desse tipo, é chamada a instância de
StoreLayoutManager para a geração de um novo StoreLayout, e em seguida este é associado
ao contêiner, redesenhando a interface na tela. AnnounceContainer também guarda uma
instância de LayoutState, que é um padrão GoF chamado State (Freeman et al., 2001) “hard-
coded”, ou seja, implementado diretamente via código e não através de uma hierarquia de
classes. Este LayoutState representa o estado que a interface do anúncio se encontra no
71
momento em que é gerado um evento, pois o mesmo botão pode gerar diferentes ações
dependendo do StoreLayout atual.
3.3.2 - Pacote org.tgi.store.business
É neste pacote que se concentra a lógica de negócio da aplicação. A principal
funcionalidade aqui, é receber requisições e tratá-las de forma correta aplicando a lógica
necessária.
Figura 22: Pacote de negócios
Toda vez que uma a thread da classe StoreController, da camada de apresentação, é
instanciada pela primeira vez, as informações sobre anúncios são solicitadas à classe
StoreFacade, que por sua vez, também utiliza o padrão GoF Singleton (Freeman et al., 2001),
para manter apenas uma instância de si mesma. O principal motivo para se ter apenas uma
instância dessa classe deve-se ao fato de a aplicação inteira estar armazenada no STB, onde há
apenas um usuário, e não múltiplos usuários acessando de forma concorrente, como em um
servidor web.
A classe StoreFacade, após receber a requisição da listagem dos anúncios, solicita à
camada seguinte, mais precisamente à qualquer classe que deriva de DataAccess da camada
de persistência. O resultado dessa solicitação é então processado e armazenado em objetos do
tipo AnnounceBO que utilizam o conceito do padrão Java EE Business Object (Alur et al.,
2003).
A classe AnnounceBO tem a responsabilidade de armazenar as informações,
representando a entidade anúncio de forma coesa, e seus objetos podem então ser repassados
72
para a camada de apresentação, onde é utilizado como um dos atributos de classes como
AnnounceEvent e ProductEvent, que pertencem ao mecanismo do padrão GoF Observer
(Freeman et al., 2001). Sendo assim, qualquer classe que se registrar para receber eventos dos
tipos citados, também irá receber, como atributo, uma instância da classe AnnounceBO,
possibilitando que classes da camada de apresentação tenham acesso às informações do
produto.
Outra funcionalidade desta classe, que foi deixada de lado nesta aplicação, é a
validação da compra. O método checkUser() da classe StoreFacade, do modo como foi
implementado apenas valida qualquer requisição. Esta validação não foi implementada pois
necessita da uma comunicação com o canal de retorno, que ainda não foi implementado nesta
versão do emulador.
Esta classe também poderia ser responsável por se comunicar com o SI para obter
informações temporais que poderiam ser utilizadas na sincronização dos anúncios com a
propaganda, mas as classes do pacote org.dvb.si e as classes referentes ao SI da API Java TV
também não foram implementadas no emulador.
3.3.3 – Pacote org.tgi.store.integration
Dentro do pacote org.tgi.store.integration, encontram-se as classes referentes a camada
de integração. Pra acesso aos dados foi utilizado o padrão Java EE Data Access Object,
também conhecido como DAO (Alur et al., 2003), com a seguinte estrutura: a interface
DataAccess é a interface comum de acesso aos dados, e as classes que implementam esta
interface provém acesso aos dados de forma específica.
Figura 23:Pacote de ingração
73
A classe utilizada para efetivo acesso aos dados foi a XmlDataAccess, que é
apropriada para ler especificadamente os dados de produtos relativos à anúncios da aplicação,
que provém do schema criado para MPEG-7 e descrito no próximo item deste capítulo. Sendo
assim, esta classe lê os dados do arquivo XML e transforma-os em objetos do respectivo tipo
definido na camada de dados, neste caso o tipo Product, para devolver à classe solicitante do
acesso aos dados, neste caso a StoreFacade.
A leitura dos dados referentes ao MPEG-7 e armazenado em estrutura XML, é feita
através da API Simple API for XML, também conhecida como SAX, que pode ser
considerada uma API rápida e eficiente neste caso, pois devido a baixa complexidade do
XML resultante, uma API com mais funcionalidades acarretaria em perda de desempenho da
aplicação. Com o auxílio do padrão Java EE Data Access Object (Alur et al., 2003), outras
formas de leitura ao arquivo XML poderiam ser implementadas, expandindo-as facilmente
para outros tipos de dados e não só para produtos. Até mesmo outra fonte de dados que não
fosse o MPEG-7 poderiam ser implementadas e tratadas. Nesta aplicação os tipos de dados
que são lidos do XML são definidos via código, proporcionando pouca flexibilidade para a
obtenção do produto, que deixa o acesso aos dados mais rápido já que se espera um XML
derivado do schema de produtos definido.
Algumas considerações devem ser feitas quanto ao XML. Como a localização do
anúncio na tela é definida também pelo XML, possíveis problemas como se o tamanho da tela
da televisão digital e o tamanho do anúncio forem incompatíveis com a localização do
mesmo, não serão responsabilidade desta camada e serão tratados mais à frente, quando os
dados relativos ao anúncio chegarem na camada de apresentação. E como o tempo de exibição
também é definido via XML, a verificação e validação destes dados é praticamente
inexistente, pois este processo feito item a item, pode retardar uma exibição de anúncio o
suficiente para que ele não apareça. Assim, o sistema considera desde o início, que o arquivo
XML contenha dados corretos para a exibição das propagandas. Um dado incorreto muitas
vezes não acarretaria em uma exceção, erro ou mensagem tratada pelo sistema.
Possíveis erros na montagem do arquivo XML podem ser citados: em relação ao
tempo de exibição, um anúncio poderia estar configurado para ser exibido no momento em
que outro anúncio já estivesse em exibição, e desta forma ele seria automaticamente
descartado e não seria exibido ao usuário. Erros nos valores da posição do anúncio da tela,
como anúncios que ficam fora da área de exibição, ou seja, ultrapassam os limites da tela, são
automaticamente corrigidos pela aplicação no momento da exibição do anúncio.
74
3.3.4 – Pacote org.tgi.store.data
Este pacote tem a funcionalidade de representar entidades relacionadas com o
conteúdo XML do MPEG-7 recebido. No caso da aplicação deste trabalho, a entidade produto
é representada pela classe Product. Esta classe é utilizada apenas pela camada de integração e
não se estende às outras camadas da aplicação pois para tal funcionalidade foi criada a classe
AnnounceBO.
Figura 24: Pacote de dados
3.3.5 – Pacote de utilidades org.tgi.store.util
Este pacote contém apenas a classe Debug para a geração de um histórico de
mensagens para a depuração da aplicação, e faz o uso de uma das modificações feitas no
emulador que é a janela para armazenamento de mensagens de xlets.
3.3.6 – Diagrama de Seqüência para a ativação de um anúncio
O diagrama UML (Booch et al., 1998) a seguir é um diagrama de seqüência e foi
utilizado para demonstrar quais classes e quais métodos precisam ser utilizados até que um
anúncio possa ser exibido na tela, ou seja, representa a seqüência de ativação de um anúncio.
Relações de ordem de execução também são representadas através deste diagrama, que possui
uma característica temporal de representação de ações na aplicação na forma de linhas
verticais para o tempo decorrido e de linhas horizontais para a chamada de métodos.
75
Para representar esta seqüência, que não faz parte de nenhuma ação do usuário, mas
sim da execução inicial da aplicação e que ocorre de forma automática, o diagrama poderá ser
subdividido em duas partes. Também podemos perceber que é considerada apenas a execução
da xlet em si, e não das operações do STB de carregamento da mesma no sistema.
Na primeira parte, a xlet Store apenas realiza inicialização de variáveis internas e
recupera a instância do gerenciador de mídias em execução dentro do emulador e repassa à
camada de apresentação. Em seguida a xlet inicia o serviço de busca de anúncios, ou seja,
instancia a thread StoreController, cujo papel é solicitar à classe StoreFacade que ela realize
a busca de anúncios para exibição, e verificar a cada segundo se existem anúncios a serem
feitos naquele intervalo de tempo. A classe StoreFacade, por sua vez, delega a tarefa de busca
de dados ao XmlStoreDataAccess que apenas adapta o schema MPEG-7 de produtos e os
transforma em objetos Product. Estes objetos do tipo Product quando retornados à classe
StoreFacade, são encapsulados em objetos do tipo AnnounceBO.
E por último, a classe StoreController gera um evento de exibição de anúncio
AnnounceEvent. Para esta última chamada, vale lembrar, que ocorre apenas quando um
anúncio foi encontrado para determinado intervalo de tempo, e que apenas é feita para outros
objetos que estão previamente registrados para recebê-los, seguindo a idéia do padrão GoF
Observer (Freeman et al., 2001).
Figura 25: Primeira parte do diagrama de seqüência da ativação de um anúncio
76
Na segunda parte deste diagrama, ocorre a exibição de componentes visuais na tela, já
que se considera o cenário onde uma ocorrência de anúncio foi encontrada para determinado
instante. A partir desse momento, a xlet é avisada através de um mecanismo de eventos e
solicita à classe que gerencia componentes visuais para exibição de anúncios,
StoreLayoutManager, que crie um componente visual que atenda às especificações do
produto em questão, ou seja, crie um anúncio para um produto. Esse conjunto de componentes
visuais está contido em AnnounceContainer e é definido por StoreLayout. Com essa criação e
inicialização do objeto AnnounceContainer, o anúncio deve ser repassado à xlet, que é a única
classe que contém referência para a tela de exibição do usuário, podendo assim, anexar o
anúncio à tela.
Figura 26: Segunda parte do diagrama de seqüência da ativação de um anúncio
3.3.7 – Diagrama de Seqüência para a compra de um produto
O diagrama de seqüência a seguir, representa o cenário de compra de um
produto através de um anúncio na loja virtual.
77
Figura 27: Diagrama de seqüência de um cenário de compra
Neste cenário, o anúncio envia ao seu ativador, ou seja, a thread StoreController, que
é responsável por eventos de ativação de anúncio, as informações contidas no campo para
preenchimento do código de assinante, que o usuário deverá preencher para que valide sua
intenção de compra. A StoreController faz apenas uma validação básica nesse código, como
por exemplo, se o campo foi realmente preenchido com a quantidade certa de caracteres, e
repassará à StoreFacade. A classe StoreFacade de fato se encarregará da lógica de negócio
referente à compra. É nesta parte que deveria ocorrer uma chamada ao serviço com o código
de assinante para efetiva validação da compra, através do canal de retorno, porém, por
motivos já explicados, é impossível fazer esta operação através do emulador utilizado.
Em seguida, o próprio AnnounceContainer se encarrega de atualizar seus componentes
visuais de acordo com seu estado interno, para mostrar a resposta da solicitação de compra.
3.4 – O Uso dos padrões MPEG-7 e MPEG-21
A aplicação desenvolvida neste trabalho nada mais é do que um elo de ligação entre o
MPEG-7 e o MPEG-21, pois utiliza dados vindos de ambos para gerar um produto final: a
loja virtual para televisão digital. Nos próximos itens serão destacados os modos com os quais
cada padrão foi utilizado.
78
É importante ressaltar que MPEG-7 e MPEG-21 são independentes do formato de
codificação de vídeo e áudio utilizado, e o resultado da codificação do vídeo com os seus
metadados dar-se-á a partir da combinação de ambos. Por exemplo, o padrão MPEG-7,
quando utilizado em conjunto com o MPEG-4 (referente ao conteúdo de áudio e vídeo), pode
ser chamado de MPEG-47.
Através das ferramentas de descrição e linguagem de declaração de itens digitais
presentes nesses formatos de vídeo, é possível, através do MPEG-7 classificar os itens, e com
o uso do MPEG-21 também seria possível o anexo de imagens ou vídeos demonstrativos do
produto junto com o vídeo principal da programação.
3.4.1 – MPEG-7
A partir da Description Definition Language do MPEG-7, será obtido o XML de onde
os produtos e seus dados serão retirados para o uso no programa. A flexibilidade
proporcionada pelo MPEG-7 permite a passagem desse tipo de dados junto com o vídeo. O
MPEG-7, entretanto, ainda é um formato recente e com algumas funcionalidades a serem
definidas.
A complexidade da Description Definition Language se deve à alta flexibildade, à
grande variedade de descritores diferentes, à longa estrutura hierárquica a se seguir, entre
outros fatores. Por conta dessa complexidade e das indefinições ainda presentes no formato,
não foi possível usar propriamente um arquivo MPEG-7. Os programas de anotações para
vídeo ainda estão em fases iniciais de desenvolvimento, não permitindo gerar as estruturas
necessárias para o uso no programa. Entretanto, é certo que essa estrutura é possível de ser
obtida e por isso, foi simulada de forma a funcionar da maneira mais próxima da estrutura que
é esperada em um arquivo MPEG-7. Entre os programas que foram usados para a tentativa de
criação de anotações em MPEG, pode-se citar o IBM Multimedia Annotation Tool, da IBM,
em sua versão 1.1, que, devido a diversos erros na geração do arquivo, não pôde ser explorado
com maiores detalhes. Já o Semantic Video Annotation Tool, SVAT, permitiu a criação de
um arquivo MPEG-7 simples que serviu de base para o desenvolvimento do schema de XML
que foi usado no programa.
Entre outros programas para trabalhar com MPEG-7, pode-se citar o Caliph e Emir,
que trabalham na criação de metadados para arquivos de imagem. Entretanto, são tags
específicas para anotação de imagem, não sendo genérico o suficiente para especificar um
produto, por exemplo.
79
Maior do que a dificuldade de obter um arquivo MPEG-7 foi a dificuldade de
manipular o arquivo de vídeo corretamente na aplicação. Por ser uma tecnologia muito
recente, as bibliotecas de manipulação do vídeo ainda não existem, impedindo que o
programa trabalhasse com MPEG-7 da forma que era desejada. A escolha foi, portanto, partir
de uma situação ideal, considerando que o arquivo já tivesse sido tratado e o vídeo e o arquivo
descritivo XML com a descrição dos produtos da loja já estivessem devidamente separados.
Com o avanço do padrão MPEG-7 e com a disseminação da televisão digital,
softwares e bibliotecas que dão suporte à MPEG-7, ou maior nível de compatibilidade, vão
conseqüentemente surgir, possibilitando a manipulação desses arquivos de forma a chegar
facilmente na situação inicial com a qual se inicia a aplicação.
Devido à dificuldade na geração de um arquivo MPEG-7, o arquivo de Description
Definition Language, também foi simulado. A aplicação lê o arquivo como se fosse um XML
comum. O código a seguir é um exemplo de header para esse tipo de arquivo que foi montado
na simulação do programa: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg7:schema:2001 Mpeg7-2001.xsd "> <DescriptionMetadata> <Version>1.1</Version> <LastUpdate>2007-05-20T20:13:15</LastUpdate> <Comment> <FreeTextAnnotation>FrangoStore Movie</FreeTextAnnotation> </Comment> <PrivateIdentifier>TestId</PrivateIdentifier> </DescriptionMetadata>
Os elementos pertencentes à DescriptionMetaData são dados referentes ao
componente multimídia. Cada nó do arquivo XML do MPEG-7 deve seguir um schema
definido e bem estruturado, de forma que o XML final possa ser lido sem problemas por
qualquer decodificador. Na ausência de um schema adequado para o uso na aplicação, pois os
schemas encontrados, mesmo os que lidavam com informação genérica, tratavam apenas de
elementos que de fato apareciam no vídeo e não de elementos externos ao mesmo, a
alternativa foi a criação de um schema próprio, que satisfizesse as necessidades de metadados
do programa. A criação deste schema também favorece a incorporação de aplicações básicas
na definição básica do padrão, já que novas plataformas como a televisão digital favorecem o
desenvolvimento e a expansão destes padrões.
80
<Description xsi:type="ContentEntityType"> <DescriptionMetadata> <PublicIdentifier></PublicIdentifier> <PrivateIdentifier>PID_1</PrivateIdentifier> <CreationTime>2007-05-20</CreationTime> </DescriptionMetadata> <Semantics> <AbstractionLevel dimension="0"/> <complexType name="FrangoStore"> <complexContent> <sequence> <complexType name="produto"> <attribute name="id" type="nonNegativeInteger" use="required"/> <attribute name="start" type="nonNegativeInteger" use="required"/> <attribute name="length" type="nonNegativeInteger" use="required"/> <complexContent> <sequence> <element name="name" type="mpeg7:TextualType"/> <element name="shortdescription" type="mpeg7:TextualType"/> <element name="description" type="mpeg7:TextualType"/> <element name="image" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element> <element name="imageLarge" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element> <element name="price" type="float"> <attribute name="currency" type="mpeg7:TextualType" use="required"/> </element> <element name="layout" minOccurs="0"> <complexType> <attribute name="transparency" type="float" use="optional"/> <attribute name="positionX" type="nonNegativeInteger" use="optional"/> <attribute name="positionY" type="nonNegativeInteger" use="optional"/> <attribute name="height" type="nonNegativeInteger" use="required"/> <attribute name="width" type="nonNegativeInteger" use="required"/> </complexType> </element> </sequence> </complexContent> </complexType> </sequence> </complexContent> </complexType> </Semantics> </Description>
A declaração desse esquema permite que o programa consiga ler a partir de um
arquivo, a especificação de um produto para uso na loja.
81
Um exemplo do tipo de XML que pode ser feito seguindo essa declaração:
<FrangoStore> <produto id="72" start="2" length="8"> <name>Camisa Social DG</name> <shortdescription>Camisa Social Dolce Gabbana</shortdescription> <description>Camisa social Dolce Gabbana de mangas longas, botão na frente, punhos com botões duplos e motivo listrado. Made in Italy.</description> <image video="false">prod3.jpg</image> <imageLarge video="false">prod3_large.jpg</imageLarge> <price currency="R$">319.90</price> <layout transparency="0.3" positionX="500" positionY="20" height="100" width="200"></layout> </produto> </FrangoStore>
A aplicação desenvolvida é capaz de ler sem maiores problemas o XML citado através
da API SAX. O esquema de montagem do XML segue também o que foi definido no DDL
anterior, seguindo as regras de tipos e nomes dos campos, além da hierarquia.
O contêiner externo frangostore engloba todos os produtos que serão usados no
programa. Cada produto é definido junto com um id, que é um campo numérico para controle
do produto pela loja. Além disso, outros itens essenciais para a definição de um produto é o
tempo de início e duração do anúncio na loja, definidos respectivamente nos atributos start e
length.
Cada produto engloba também uma série de variáveis que caracterizam-no. Entre os
campos pertencentes a um produto, temos name, que é o nome do produto na loja,
shortdescription, que é uma descrição curta do produto para exibição no anúncio não
selecionado e description, que é uma descrição mais detalhada que é exibida quando o usuário
desejar ver mais informações do produto.
O elemento image indica o endereço de uma imagem para exibição no anúncio, se
existir uma imagem. Se um produto não possuir uma imagem, este campo pode vir vazio e o
anúncio será exibido somente com a descrição. Este elemento ainda possui um atributo
booleano video, que indica se será mostrado uma imagem ou vídeo no anúncio. Já o elemento
imageLarge é utilizado para especificar o endereço de uma segunda imagem ou trecho de
vídeo, que poderão ser utilizados na tela de exibição de detalhes do anúncio.
Um valor de ponto flutuante é definido no elemento price, que ainda possui o atributo
currency, que indica em qual moeda aquele valor está sendo cobrado.
Um elemento mais complexo é o elemento layout, que possui diversos atributos, que
podem definir a transparência do layout (transparency), posição do anúncio na horizontal,
82
posição do anúncio na vertical (positionX e positionY), altura e largura do anúncio (width e
height).
Cada um desses elementos precisa ser especificado com detalhes no schema do
MPEG-7. O contêiner produto, por exemplo, foi especificado como um complexType, pois ele
encapsula todos os elementos relacionados com o produto. Cada elemento deve ser detalhado,
incluindo a definição de seus atributos e seus respectivos tipos.
<element name="image" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element>
O código acima, por exemplo, define o elemento image do XML de produtos. A tag
element indica que é um novo elemento que está sendo especificado, que receberá o nome
definido no atributo name e que possuirá o tipo definido em type. O nó attribute, dentro de
element indica que o elemento ainda conterá um atributo com nome definido em name e tipo
definido em type. O atributo use indica se este será um atributo opcional ou obrigatório. No
caso da definição de uma imagem para o anúncio, por exemplo, era necessário definir um
campo de texto que indique o nome da imagem ou vídeo a ser exibido no anúncio do
programa. E era necessária também uma variável booleana obrigatória que indicará se o
conteúdo daquele elemento é uma imagem ou um vídeo.
O schema, então, define um trecho do XML como exemplificado abaixo: <image video="true">pizza1.avi</image>
Entretanto não é possível garantir a integridade dos dados presentes no XML antes da
execução da aplicação, pois mesmo que ele esteja compatível segundo o schema definido,
dados contidos nele podem ser inválidos do ponto de vista da aplicação, como a posição do
anúncio. Considera-se, portanto que ele está correto quanto aos dados apresentados.
Entretanto, uma interface para a criação de um arquivo XML para ser usado na aplicação é
uma tarefa simples e uma validação dos dados, para garantir que todos os valores estejam no
formato certo e de forma consistente, poderia ser feita nesse processo de geração do arquivo.
Para exemplificação do funcionamento do programa, o XML usado foi escrito manualmente,
com dados que se encaixavam na aplicação. A geração do MPEG-7, portanto, é uma etapa
crucial para o funcionamento da aplicação.
83
3.4.2 – MPEG-21
A utilização do formato MPEG-21 é bastante prejudicada pela constante atualização
ou até mesmo indefinição de várias partes do padrão, cujo progresso pode ser verificado
através do site oficial dos padrões MPEG. No site oficial é possível conferir um cronograma
das publicações das especificações que já foram realizadas. Também é possível observar que
atualmente menos da metade das partes do padrão que foram propostas, já possuem
especificação. Isto se deve ao fato do constante trabalho focado nas primeiras partes, pois elas
servirão de base para as conseguintes.
Sendo assim, fabricantes de hardware e softwares em geral, como por exemplo, os
fabricantes de STBs, ainda não optaram pela adoção deste padrão. A rápida mudança de
tecnologias, como a migração de televisões analógicas para televisões digitais, bem como a
variedade de dispositivos receptores de sinal de televisão digital disponíveis, impulsiona o
avanço dos padrões MPEG. Há padrões de televisão digital que utilizam MPEG-2 para o
vídeo, enquanto outros utilizam MPEG-4, e é essa divergência de padrões que o MPEG-21
procura resolver, proporcionando interoperabilidade entre os padrões em diferentes
plataformas. Daí tem-se idéia da complexidade da especificação do padrão e das constantes
atualizações que serão necessárias com o desenvolvimento de qualquer outro padrão MPEG.
Então, o uso deste padrão trata-se de uma modelagem conceitual do que ele realmente
representaria na loja virtual. Este modelo usará algumas das principais partes do padrão
MPEG-21 que já foram publicadas até agora e que estão passíveis de atualização, que são:
Digital Item Declaration, Digital Item Identification, Digital Item Adaptation, Rights
Expression Language e Rights Data Dictionary.
O modelo definido para esta aplicação será um item digital denominado Produto, que
representará a entidade produto da loja virtual. Um item digital desse tipo, deverá conter todas
as informações necessárias para que a aplicação da loja virtual, que reside no STB, seja capaz
de exibir um anúncio ao usuário.
O item digital terá imagens do produto, como miniaturas que serão usadas para o
anúncio inicial e imagens maiores que serão exibidas em maior tamanho para a melhor
visualização do mesmo, além de metadados MPEG-7 informando detalhes como preço do
produto, descrição, se possui imagens relacionadas ou não, entre outros. Este item digital
também terá componentes que poderão ser opcionais para a exibição do anúncio, como vídeos
de utilização do mesmo, por exemplo, ou então áudios e vídeos para o caso de o produto da
loja virtual ser necessariamente digital, e não um objeto físico, externo ao sistema. Um
84
modelo do que seria um produto, do ponto de vista de um item digital, é representado na
figura a seguir:
Figura 28: Modelagem do conteúdo de um produto
Diversos conceitos definidos em Digital Item Declaration, DID, serão utilizados nesta
parte, para a estruturação do item digital, como contêiner, item, descritor, componente e
recursos. Um contêiner poderá conter um ou mais itens, que por sua vez, serão itens digitais
da entidade produto, ou seja, em um só arquivo MPEG-21, diversos produtos poderão ser
armazenados e transferidos. Desta forma, também pode ser feita uma categorização por
contexto em que aparecem, por exemplo, um contêiner pode ser utilizado para cada programa
de televisão que é transmitido. Cada item digital terá seu descritor, onde estarão os metadados
no formato MPEG-7 referente ao produto o qual representa, e também terá estruturas internas
denominadas componente que representarão uma associação entre descritores e recursos, ou
seja, conteúdos multimídia presentes no item digital, que poderão ser opcionais ou não. No
caso do componente, o descritor seguirá a parte Digital Item Adaptation da especificação do
padrão MPEG-21, pois esta descrição, ao contrário do padrão MPEG-7 que trata da descrição
do conteúdo multimídia, trata de informações sobre a manipulação desse conteúdo
multimídia, encapsulado em recursos, como bit rate, métodos de criptografia utilizados,
conjunto de caracteres, entre outros.
A parte Digital Item Identification, DII, que trata da identificação do item digital,
também tem grande utilidade nesta aplicação, pois servirá para atribuir nomes únicos aos
componentes do item digital. Estes identificadores são atribuídos pelo provedor de serviços de
televisão digital de acordo com um sistema interno de nomenclatura. Neste caso,
85
identificadores são escolhidos para representar hierarquia entre os componentes de um item
digital, e também para representar um produto perante a loja virtual. Cada produto recebe uma
identificação única, e cada componente do item digital que o representa, recebe uma
identificação padronizada, de acordo com a identificação única do item digital e uma
funcionalidade atribuída a cada componente.
Esta estruturação, bem como a identificação do produto é representada na figura a
seguir:
Figura 29: Digital Item de um produto feito com DID e DII
A parte da especificação Rights Expression Language pode ser usada pelo provedor de
serviços de televisão digital, para definir diferentes métodos de acesso ao item digital. Desta
maneira, é possível fazer com que a aplicação da loja virtual e o serviço de exibição de
anúncios sejam exibidos apenas para usuários que contrataram este serviço perante o provedor
de serviços, por exemplo. Também é possível a criação de regras mais complexas para a
visualização deste item digital, ou de apenas partes dele.
Uma regra mais complexa para um item digital pode ser a validação do STB para a
exibição de um anúncio, ou seja, verificar se a aplicação da loja virtual está disponível no
STB, e até mesmo verificar a identificação do próprio STB por questões de segurança, para
saber se o item digital foi enviado para o STB correto, já que o sinal de televisão digital é
distribuído através da difusão.
Outra possível, e importante regra, é para a definição do acesso a conteúdo protegido
dentro de um item digital. Este conteúdo interno pode ser considerado um produto digital, no
86
contexto da loja virtual, sendo imagens, outros vídeos, filmes, ou músicas. Para representar
essa hierarquia interna, de apenas partes de um item digital possuírem regras de utilização,
convém a adoção de termos comuns, definidos na parte Rights Data Dictionary da
especificação do MPEG-21.
Nesta parte estão presentes conjuntos de termos únicos e consistentes, que representam
relacionamentos ontológicos entre regras presentes em um item digital, e o conteúdo sobre o
qual a regra infere. Assim, esta parte age como um complemento à Rights Expression
Language, provendo uma associação lógica para as regras. Um exemplo de uma regra de
acesso à um produto digital pode ser visto na figura a seguir:
Figura 30: Regra aplicada à exibição de item digital contendo o vídeo de um produto digital vendido
Na aplicação desenvolvida para este trabalho, o papel do padrão MPEG-21 é implícito.
Como os metadados MPEG-7 e as imagens do produto, estão contidos no item digital
derivado do MPEG-21, descrito acima, e partindo do princípio de que o emulador utilizado
não consegue simular fluxo de dados, ou seja, a captação de dados do STB através do meio de
transmissão escolhido, e de que o emulador também não é capaz de interpretar padrões
MPEG, especialmente padrões mais recentes como o MPEG-21, é essencial o estabelecimento
de uma condição ideal para que o desenvolvimento se torne viável.
Nesta condição ideal considera-se que ambos os componentes MPEG-7 e multimídia,
que são relativos a um item digital, que neste caso é o produto, tenham sido extraídos do
arquivo MPEG-21 que supostamente foi enviado pelo SI e posteriormente, recebido e
armazenado temporariamente no STB. Este STB deveria ter a implementação do software de
referência do padrão MPEG-21 que está especificado em uma das partes deste padrão, mas
encontra-se em constante atualização. Sendo assim, o STB teria a capacidade de extrair
recursos do item digital, e disponibilizá-los em uma memória local, dentro do próprio sistema
de arquivos, para quaisquer aplicações residentes no STB. Ainda assim, de acordo com a
87
identificação do item digital, seria possível iniciar a execução de uma determinada xlet. Por
exemplo, se o STB identifica que o item digital é um produto de loja virtual, e o mesmo
contém a aplicação loja virtual, o STB simplesmente executa-a. Nesta situação, é necessária
uma alta compatibilidade entre STB e xlet, que se pode alcançar através da adoção aos
padrões MPEG-7 e MPEG-21, para que o STB faça a relação entre item digital e aplicação.
88
Capítulo 4 – Conclusão e Trabalhos futuros
O desenvolvimento de aplicações para televisão digital com recursos de fins não-
comerciais e plataformas de código aberto é bastante prejudicado pela escassez dos mesmos.
Poucos estão disponíveis, e os que estão disponíveis de forma livre, são incompletos ora na
implementação da API Java TV ora na implementação de um padrão de televisão digital.
Pesquisas em tecnologias recentes são agravadas devido a funcionalidades que ainda não
foram completamente definidas ou que sofrem mudanças com uma freqüência elevada, assim
como evidenciado nesta pesquisa, já que, apesar de existirem padrões de televisão digital
definidos, o desenvolvimento de softwares para tais padrões encontra-se em estado primário.
A escassez de material acadêmico, livros em especial, sobre os padrões MPEG-7 e
MPEG-21 também é um fator prejudicial. Apesar de contar com diversas fontes, a maior parte
delas tratam de uma introdução ao assunto. Isto se dá pois ambos os padrões são
relativamente recentes, principalmente o padrão MPEG-21, que ainda não possui sua
especificação completa, mas apenas a sua base, que ocasionalmente ainda sofrerá mudanças
devido a novas plataformas como televisão digital estarem em ascensão. Com esta plataforma,
diferentes dispositivos terão acesso ao sinal de televisão digital, bem como sua inovadora
interatividade com o telespectador, que por sua vez deixa de ter o papel passivo de apenas
assistir, para se tornar um usuário do sistema. Diversas formas de interatividade surgem a
partir daí, e essa foi a questão explorada com os padrões MPEG-7 e MPEG-21 nesta pesquisa.
Ao contrário dos outros padrões MPEG, o padrão MPEG-7 propõe um complemento para
outros padrões, e não um novo método de codificação de vídeo. O mesmo acontece com o
MPEG-21 que propõe uma maneira de interação entre todos os outros padrões.
A interação entre padrões MPEG proposta pelo padrão MPEG-21 pode ser facilmente
aplicada à televisão digital, já que os padrões de televisão digital se baseiam em compressões
de vídeo MPEG para otimizar a transferência de dados. Porém estes recursos não podem ser
explorados na prática pela falta de ferramentas de desenvolvimento capacitadas para realizar
estas operações. Isto também ocorre com o padrão MPEG-7, cujas ferramentas de
desenvolvimento não são totalmente compatíveis com a especificação.
Com o emulador utilizado, o XleTView, também foi inviável a construção do sistema
da forma como era desejada, pois o emulador carece de diversas implementações da API Java
TV e também do middleware MHP, no qual se baseia. Sendo assim, funcionalidades como a
validação de uma compra na loja virtual que necessitariam da utilização do canal de retorno
89
também não puderam ser testadas, pois o emulador não suporta tal funcionalidade. A
tendência é que a disseminação da televisão digital acarretará na melhoria das condições de
desenvolvimento para aplicações voltadas à tecnologia, com o surgimento de ferramentas que
possibilitarão a implementação de aplicações para tal plataforma.
A precariedade do emulador também nos impossibilitou tirar maiores conclusões sobre
o desempenho do aplicativo. A configuração do computador também influencia na execução
do aplicativo. Sendo assim, espera-se que, rodado num STB, a aplicação não tenha quaisquer
problemas em relação ao desempenho, pois um STB deve ter poder computacional suficiente
para decodificar vídeos digitais e realizar todas as suas outras operações, além de deixar um
restante de sua capacidade para aplicações disponíveis pelas próprias emissoras
Diversas possibilidades para continuações desta pesquisa se abrem. A implementação
do software em um emulador mais avançado, que tenha suporte à funcionalidades como a
comunicação com o canal de retorno, ou a simulação de transmissão de dados de vídeo são
necessárias. Com a comunicação com o canal de retorno é possível a implementação da
validação de uma compra com o servidor, e outras aplicações que necessitem de uma troca de
dados mútua. Já com o suporte à simulação de transmissão de dados de vídeo, é possível
recuperar dinamicamente metadados disponíveis à medida em que são transmitidos,
simulando um ambiente real de televisão digital. Outra opção seria a implementação do item
digital proposto, que no momento da realização desta pesquisa, era inviável. É possível ainda,
fazer um estudo de usabilidade em interfaces de televisão digital, já que se encontram
precárias e as que foram usadas neste trabalho foram totalmente ou parcialmente criadas.
90
Referências Referências Bibliográficas
ALUR, DEEPARK; CRUPI, JOHN; MALKS, DAN. Core J2EE Patterns: Best Practices and Design Strategies, 2/e. New Jersey: Prentice Hall, 2003 ATSC. Advanced Television Systems Committee. Disponível em http://www.atsc.org. Acesso em 25 fev, 2004. BOOCH, GRADY; RUMBAUGH, JAMES; JACOBSON, IVAR.; The Unified Modeling Language User Guide. Addison-Wesley, 1998. BURNETT, I.; WALLE, R. V.; HILL, K.; BORMANS, J.; PEREIRA, F.; MPEG-21: Goals and Achievements. California: IEEE Computer Society, 2003. CAVENDISH, S. A. Algoritmo de Ajuste Elástico para Vídeo em Fluxos MPEG-2. Dissertação (Mestrado em Ciência da Computação), Pontifícia Universidade Católica do Rio de Janeiro, Brasil, 2005 DAVIC. DAVIC 1.4.1 Specification Part 9: Information Representation. Disponível em: http://www.davic.org/Download/Spec1_2/part09.pdf. Acesso em 30 mar, 1999 DVB. Digital Video Broadcasting Project. Disponível em http://www.dvb.org. Acesso em 25 fev, 2004. FERNANDES, J.; LEMOS, G.; SILVEIRA, G. Introdução à Televisão Digital Interativa: Arquitetura, Protocolos, Padrões e Práticas. Apresentado na Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação, JAI-SBC, Salvador, 2004. FISCHER, W. Digital Television: A practical Guide for Engineers. Springer, Berlin, 2004. FILHO, G. L. S.; LEITE, L. E. C.; BATISTA, C. E. C. F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Departamento de Informática, Universidade Federal da Paraíba , 2007 FREEMAN, E.; FREEMAN. E.; SIERRA, K.; BATES B. Head First: Design Patterns. Sebastopol: O`Reilly, 2001. GARTNER, J. TiVo, the Starving Actor. In: MIT Digital Review, September. Disponível em: http://www.technologyreview.com/BizTech/14734/. Acesso em 24 mar, 2005. HAVI, HAVi, the A/V digital network revolution. Disponível em: http://www.havi.org/pdf/white.pdf - Acesso em 11 jul, 1999. ISDB. ISDB-T - Terrestrial Integrated Services Digital Broadcasting (ISDB-T): Specification of Channel Coding, Framing Structure and Modulation., 1998. LYNCH, T. J., Data Compression: Techniques and Application. New York: Van Nostrand Reinhold, 1985. MARTINEZ, J. M.; KOENEN, R.; PEREIRA, F. MPEG-7: Overview of MPEG-7 Description Tools. California: IEEE Computer Society, 2002. MARTINEZ, J. M.. MPEG-7: the generic Multimedia Content Description Standard. California: IEEE Computer Society, 2002
91
MATHWORLD. Wolfram Mathworld. Disponível em : http://mathworld.wolfram.com/ -Acesso em 20 mai, 2007. MORRIS, S.; SMITH-CHAIGNEAU, A. Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Oxford: Focal Press, 2005 MPEG1. MPEG-1: Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-1/mpeg-1.htm. Acesso em 24 abr, 1996. MPEG7. MPEG-7 Overview. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm. Acesso em 2 mai, 2004. OLIVEIRA, E. C. R.; ALBUQUERQUE, C. V. N. TV Digital Interativa: Padrões para uma nova era. Disponível em: http://www.ic.uff.br/~celio/papers/eri05.pdf - Acesso em 11 jul, 2005. PAES, A.; ANTONIAZZI, R. Padrões de Middleware para TV Digital. Universidade Federal Fluminense, Niterói, 2005. PENG, C. Digital Television Applications. Dissertação (Doutorado em Ciência da Computação), Helsinki University of Technology, Finlândia, 2002. ZIMET, L. Digital Processing of Analog Television. Department of Electrical Engineering, Stanford University, 2002. Bibliografia Complementar
BURNETT, I. S.; PEREIRA, F.; WALLE, R. V.; KOENEN, R. The MPEG-21 Book. Chichester : John Wiley & Sons Ltd, 2006. CAPDA. TV Digital Interativa. Subgrupo de Trabalho 2 do CAPDA - Comitê das Atividades de Pesquisa e Desenvolvimento na Amazônia, 2004. CHIQUITO, J. G.; ARANTES, D. S.; COSTA, M. H. M. Considerações sobre o relatório final da SET/ABERT para definição do padrão de televisão digital no Brasil. Departamento de Comunicações, Unicamp, São Paulo, 2000. ERONEN, L. and VUORIMAA, P.. User interfaces for digital television: a navigator case study. Disponível em: from http://portal.acm.org/citation.cfm?id=345346. Acesso em 14 mar, 2000. HERIGSTAD, D. and WICHANKY, A.. Designing user interfaces for television. Disponível em: http://portal.acm.org/citation.cfm?id=286645 – Acesso em 22 mar, 1998. KIM, H.; MOREAU, N.; SIKORA, T. MPEG-7 Audio and Beyond: Audio Content Indexing and Retrieval. Chichester : John Wiley & Sons Ltd, 2005. KOSCH, H. Distributed Multimedia Database Technologies Supported by MPEG-7 and MPEG-21. London: CRC Press, 2004. LIU, P.; HSU, L. Queries of Digital Content Descriptions in MPEG-7 and MPEG-21 XML documents, 2001. LOUREIRO, J. A. Interfaces de Programação para o Desenvolvimento de Aplicações para TV Digital. Trabalho de Graduação, Universidade Federal de Pernambuco, 2004.
92
MHP. An Introduction to MHP - White Paper. Disponível em: http://www.mhp.org/about_mhp/WP02%20(MHP).pdf. Acesso em 12 mar, 2005. MPEG. The MPEG handbook. Oxford: Focal Press, 2001 MPEG2. MPEG-2 : Generic coding of moving pictures and associated audio information. Disponível em : http://www.chiariglione.org/mpeg/standards/mpeg-2/mpeg-2.htm. Acesso 25 abr, 2000. MPEG4. Overview of the MPEG-4 standard. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm. Acesso em 3 mai, 2002. MPEG21. MPEG-21 Overview. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm. Acesso em 2 mai, 2002. PAWLAN, M.. Introduction to Digital TV Applications Programming. Disponível em: http://java.sun.com/developer/technicalArticles/javatv/apiintro/index.html. Acesso em 02 fev, 2001. PENG, C. and VUORIMAA, P. A digital television navigator. Disponível em: http://portal.acm.org/citation.cfm?id=376335 – Acesso em 22 mar, 2000. PIMENTEL, C. A. F. Uma análise do uso do padrão MPEG-7 pela ferramenta IBM Annotation Tool, 2006. SILVA, F. P. R.; SOUSA, A. H. S.; LEMOS, G. Aplicações para TV Digital Interativa. Departamento de Informática, Universidade Federal da Paraíba, João Pessoa, 2004. SIVARAMAN, G.; CESAR, P.; VUORIMAA, P. System software for digital television applications. Tokyo: IEEE, 2001. SUWELACK, S., GANTES, F. and HERNÁNDEZ, A.. Introduction to MPEG-21. Disponível em: http://emfs1.eps.hw.ac.uk/~ceeet1/b39si2/winner05-MPEG21.pdf. Acesso em 04 abr, 2005. ZIMET, L. Digital Processing of Analog Television. Department of Electrical Engineering, Stanford University, 2002.
93
Anexo