UNIVERSIDADE PRESBITERIANA MACKENZIE

FACULDADE DE COMPUTAO E INFORMTICA

Trabalho de Graduao Interdisciplinar

Paulo Henrique Martins e Roger Tadeu dos Santos

Aplicao dos Padres MPEG-7 e MPEG-21 em TV Digital

So Paulo
2007

PAULO HENRIQUE MARTINS E ROGER TADEU DOS SANTOS

APLICAO DOS PADRES MPEG-7 E MPEG-21 EM TV DIGITAL

Trabalho de Concluso de Curso de Cincia da

Computao da Universidade Presbiteriana
Mackenzie, apresentado como requisito parcial
para a obteno do Grau de Bacharel em
Cincia da Computao.

ORIENTADOR: Prof. Dr. Ismar Frango Silveira

So Paulo
2007

UNIVERSIDADE PRESBITERIANA MACKENZIE

FACULDADE DE COMPUTAO E INFORMTICA
CINCIA DA COMPUTAO
Termo de Julgamento de Defesa de Trabalho de Graduao Interdisciplinar
Aos trinta dias do ms de novembro na Universidade Presbiteriana Mackenzie, presente a
Comisso Julgadora, integrada pelos senhores Professores, abaixo discriminados, iniciou-se a
apresentao do Trabalho de Graduao Interdisciplinar do Grupo de Trabalho formado pelos
alunos abaixo e concluda a argio, procedeu-se ao julgamento na forma regulamentar,
tendo a Comisso Julgadora atribudo s seguintes notas aos Candidatos.

Ttulo do Trabalho: Aplicao dos padres MPEG-7 e MPEG-21 em TV Digital

ALUNOS

Nmero
Mdia
Nota
Matrcula da Banca Orientador

Paulo Henrique Martins

3040296-4

Roger Tadeu dos Santos

3042936-6

Mdia

Desconto Nota
por atraso Final

COMISSO JULGADORA
Orientador Ismar Frango Silveira
Titular 1
Titular 2
Suplente
Mdia Obtida pelo Grupo de Trabalho

NOTA

Para constar, lavrado o presente termo que vai assinado pela Comisso Julgadora e pelo
Coordenador de TGI.
So Paulo,
Comisso 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 fora, acreditaram em nosso potencial e
contriburam, direta ou indiretamente para o desenvolvimento deste trabalho.
A todos os professores do Mackenzie que sempre atenderam nossas dvidas de forma
atenciosa sempre que precisamos.
Ao nosso orientador Ismar Frango que sempre nos atendeu e guiou com muita
pacincia desde o princpio.

RESUMO
O objetivo deste trabalho o estudo da plataforma de televiso digital para o desenvolvimento
de uma aplicao de loja virtual que faa uso dos padres MPEG-7 e MPEG-21. Esta
aplicao de televiso digital servir como uma ligao entre os elementos do padro MPEG7, utilizado para gerar metadados sobre arquivos multimdia, e os elementos do padro
MPEG-21, que servir para o encapsulamento e o controle de acesso arquivos multimdia.
A aplicao ser desenvolvida com o uso da API Java TV, por causa da sua alta portabilidade
entre sistemas de televiso digital, e tambm com o emulador XleTView, que ser utilizado
para testar as aplicaes durante o processo de desenvolvimento. Ao final deste estudo, ser
feita uma anlise da viabilidade de implantao desta aplicao na plataforma de televiso
digital.

Palavras-chave: Televiso Digital, MPEG-7, MPEG-21, Metadados, Interao HumanoComputador

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 its 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 Ilustraes
FIGURA 1: FOTOS TIRADAS POR EDWARD MUYBRIDGE QUANDO VISTAS SEQENCIALMENTE, DO A IMPRESSO
DE MOVIMENTO................................................................................................................................................ 14
FIGURA 2: COMPARAO ENTRE REA DA TELEVISO COMUM (4:3) COM O PADRO HDTV (16:9) ...................... 18
FIGURA 3: ETAPAS PARA CONVERTER UM VDEO ANALGICO EM UM SINAL DE TV DIGITAL .................................. 21
FIGURA 4: PROCESSO DE TRANSMISSO E RECEPO 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 TELEVISO DIGITAL ............................................................. 34
FIGURA 7: CICLO DE VIDA DE UM XLET .................................................................................................................... 35
FIGURA 8: MODELO DE EXIBIO DASE .................................................................................................................. 38
FIGURA 9: MODELO DE EXIBIO ARIB ................................................................................................................... 39
FIGURA 10: EXEMPLO DE ORDEM DE APRESENTAO EM RELAO ORDEM DE CODIFICAO ............................ 45
FIGURA 11: LOGO MPEG DESCRITO PELA ANOTAO MPEG-7.............................................................................. 51
FIGURA 12: EXEMPLO DE APLICAO DE DESCRIO EM UMA CENA DE VDEO, RETIRADO DE (MARTINEZ;
KOENEN; PEREIRA, 2002) .......................................................................................................................... 52
FIGURA 13: ORGANIZAO 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 EXECUO SOBRE O VDEO ................................................................................. 63
FIGURA 17: INTERFACES DE EXIBIO DE DETALHES E CONFIRMAO DE COMPRA ................................................ 64
FIGURA 18: INTERFACES DE RESULTADO DA CONFIRMAO DE COMPRA: SUCESSO E ERRO.................................... 65
FIGURA 19: PACOTE CLIENTE .................................................................................................................................... 66
FIGURA 20: PACOTE DE APRESENTAO ................................................................................................................... 68
FIGURA 21: PACOTE DE INTERFACE GRFICA DA CAMADA DE APRESENTAO ....................................................... 69
FIGURA 22: PACOTE DE NEGCIOS ............................................................................................................................ 71
FIGURA 23:PACOTE DE INGRAO ............................................................................................................................ 72
FIGURA 24: PACOTE DE DADOS ................................................................................................................................. 74
FIGURA 25: PRIMEIRA PARTE DO DIAGRAMA DE SEQNCIA DA ATIVAO DE UM ANNCIO ................................. 75
FIGURA 26: SEGUNDA PARTE DO DIAGRAMA DE SEQNCIA DA ATIVAO DE UM ANNCIO ................................. 76
FIGURA 27: DIAGRAMA DE SEQNCIA DE UM CENRIO DE COMPRA ...................................................................... 77
FIGURA 28: MODELAGEM DO CONTEDO DE UM PRODUTO ...................................................................................... 84
FIGURA 29: DIGITAL ITEM DE UM PRODUTO FEITO COM DID E DII .......................................................................... 85
FIGURA 30: REGRA APLICADA EXIBIO DE DIGITAL ITEM CONTENDO O VDEO DE UM PRODUTO DIGITAL
VENDIDO .......................................................................................................................................................... 86

Lista de Tabelas
TABELA 1: COMPARAO ENTRE OS PADRES DE TELEVISO DIGITAL ................................................................... 25
TABELA 2: SUPORTE A FORMATOS MULTIMDIA DA API JMF .................................................................................. 61

Sumrio
INTRODUO ...................................................................................................................................................... 12
CAPTULO 1 A TELEVISO DIGITAL ........................................................................................................ 14
1.1 - SISTEMAS DE TELEVISO ............................................................................................................................. 15
1.1.1 - Televiso Analgica ............................................................................................................................ 15
1.1.2 - Televiso Digital ................................................................................................................................. 17
1.2 PADRES DE TRANSMISSO DIGITAL ........................................................................................................... 21
1.2.1 - Padres para Codificao e Compresso .......................................................................................... 21
1.2.2 - Padro para Multiplexao e Transporte .......................................................................................... 21
1.2.3 - Padres para Modulao e Transmisso ........................................................................................... 22
1.3 - ARQUITETURA DA TELEVISO DIGITAL INTERATIVA .................................................................................. 23
1.4 - PADRES DE TELEVISO DIGITAL ................................................................................................................. 24
1.4.1 - ATSC (Advanced Television Systems Committee) .............................................................................. 25
1.4.2 - DVB (Digital Vdeo Broadcasting) ..................................................................................................... 26
1.4.3 - ISDB (Integrated Services Digital Broadcasting) .............................................................................. 26
1.4.4 - Padro 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 - Padres ................................................................................................................................................ 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

CAPTULO 2 MPEG .......................................................................................................................................... 41

2.1 - PADRES....................................................................................................................................................... 41
2.3 - MPEG-1 ....................................................................................................................................................... 42
2.4 - MPEG-2 ....................................................................................................................................................... 43
2.4.1 - Camada de compresso ...................................................................................................................... 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
CAPTULO 3 DESENVOLVIMENTO DA APLICAO ........................................................................... 59
3.1 O EMULADOR .............................................................................................................................................. 59
3.1.1 Suporte vdeos .................................................................................................................................. 60
3.1.2 Modificaes no Emulador................................................................................................................. 61
3.2 A APLICAO ............................................................................................................................................... 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 Seqncia para a ativao de um anncio .................................................................. 74
3.3.7 Diagrama de Seqncia para a compra de um produto.................................................................... 76

3.4 O USO DOS PADRES MPEG-7 E MPEG-21................................................................................................ 77

3.4.1 MPEG-7 .............................................................................................................................................. 78
3.4.2 MPEG-21 ............................................................................................................................................ 83
CAPTULO 4 CONCLUSO E TRABALHOS FUTUROS ......................................................................... 88

12

Introduo
Com o surgimento da televiso digital, alm do grande avano na qualidade da
imagem, a interatividade entre a televiso e o telespectador se torna possvel, fazendo com
que este, passe a ser um usurio, permitindo a criao de diversas funcionalidades que no
eram possveis com o uso da televiso analgica.
A idia do trabalho o desenvolvimento de uma aplicao para a televiso digital que
funcionasse como uma loja virtual, na qual fossem exibidos anncios para os produtos em um
canto da tela, buscando no interferir na programao que estaria sendo exibida em
determinado momento. Em uma situao ideal, o produto que estivesse sendo anunciando na
loja virtual, teria alguma relao com a programao, para incentivar o usurio, 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 usurio
compre aquilo que est vendo e tambm que ele veja o produto em uso no prprio programa
de televiso ou atravs de vdeos adquiridos em tempo real, fotos do produto, entre outros.
Desta forma abre-se a possibilidade de emissoras de televiso e lojas interessadas em formar
parcerias, obterem outra fonte de renda, trazendo a ao da compra para uma nova plataforma,
explorando as novas funcionalidades que so oferecidas, e sem interromper a programao da
emissora.
Seria uma grande diferena em comparao televiso analgica, onde grande parte
do lucro das emissoras proveniente de propagandas e anncios que so intercalados com a
programao da emissora, interferindo assim, em sua exibio. Assim, interagir com a
televiso digital ficaria muito mais parecido com o que possvel evidenciar em websites
acessados por computadores, onde o usurio pode navegar pela propaganda, obter mais
informaes sobre ele, ver mais fotos e compr-lo.
H uma dificuldade tambm em no deixar essa propaganda ser invasiva demais,
interferindo o programa de televiso. No momento da compra, tambm seria necessrio um
cdigo de segurana para garantir que o usurio responsvel pelo acesso a loja virtual que
est efetuando a compra. Essa segurana til tambm para famlias, impedindo que crianas
comprem produtos sem o conhecimento dos pais.
A aplicao que ser desenvolvida neste trabalho, focar no uso dos padres MPEG-7
e MPEG-21. Estes padres contero todas as informaes necessrias para a exibio do
anncio, porm, necessrio o desenvolvimento de uma aplicao para televiso digital
baseada na JAVA TV API, j que os STBs desenvolvimentos at o presente momento no

13
possuem suporte tais padres. Esta aplicao realizar a integrao entre os padres MPEG
e o programa de televiso sendo exibido, alm de operaes como sincronizao de anncio,
entre outras. Ser apresentada toda a parte relativa engenharia de software desta aplicao, e
tambm os modelos propostos para utilizao dos padres MPEG-7 e MPEG-21.
O uso desses padres MPEG um grande desafio, uma vez que h poucos estudos j
realizados com a utilizao dos mesmos, pois esto parcialmente definidos ou sujeitos a
alteraes devido ao crescente desenvolvimento da plataforma de televiso digital e outros
dispositivos multimdia.

14

Captulo 1 A Televiso Digital

O local onde hoje se encontra a Universidade de Stanford na Califrnia, j foi um dia
uma fazenda pertencente a um milionrio chamado Leland Stanford. Apaixonado por cavalos
de corrida, Leland se sentia perturbado por uma questo: Os cavalos, quando trotam, tiram as
quatro patas do cho ao mesmo tempo ou no? Intrigado, Leland Stanford contratou, em
1872, o cientista Edward Muybridge para resolver a questo. O cientista ento instalou 12
cmeras fotogrficas rudimentares, uma na frente da outra, que eram disparadas
seqencialmente, acompanhando o movimento do cavalo.

Figura 1: Fotos tiradas por Edward Muybridge quando vistas seqencialmente, do a impresso de movimento

As fotos comprovaram que os cavalos tiram as quatro patas do cho ao mesmo tempo
durante o trote. Mas acabaram ficando famosas pela idia de movimento que do quando
vistas seqencialmente. Mais tarde, iriam inspirar os estudos de outros inventores, como o
fisiologista francs tienne-Jules Marey, que inventou em 1887, a cronofotografia. Ou
Thomas Edison, inventor do filme perfurado e do cinetoscpio em 1890. Em 1895, os irmos
Auguste e Louis Lumiere inventaram o cinematgrafo uma ancestral das filmadoras como
conhecemos hoje.
Assim como o vdeo, a televiso tambm no pode ser atribuda a um s inventor. Em
fevereiro de 1924, John Logie Baird faz a primeira demonstrao de televiso analgica. O
sistema completo, com a transmisso analgica surgiu pouco depois, em 1927, demonstrado
por Philo Farnsworth.
A partir de 1935, a televiso passou a ser oficialmente transmitida na Alemanha e na
Frana, sendo a Torre Eiffel o principal posto transmissor francs. A rede inglesa BBC foi

15
fundada em 1936. Londres, na poca, usava imagens com definio de 450 linhas. Uma das
primeiras grandes transmisses foi a dos jogos olmpicos de Berlim, em 1936. Durante a
Segunda Grande Guerra, a Alemanha foi o nico pas europeu que manteve suas transmisses
no ar. As transmisses em Paris s voltariam em outubro de 1944, e em Londres, somente em
junho de 1946, com a exibio, pela BBC, do desfile da vitria.
Apesar das primeiras imagens coloridas terem sido realizadas em 1929, por Hebert
Eugene Ives, as transmisses regulares em cores s comearam em 1954, nos Estados Unidos,
atravs da rede NBC. Nessa poca que surgiu o padro NTSC (National Television Standards
Comittee), para decidir como a exibio da transmisso a cores seria feita e de modo a no
inutilizar os 10 milhes de aparelhos em preto e branco da poca.
No Brasil, a primeira transmisso foi realizada na dcada de 1950, pela TV Tupi,
primeiro canal de televiso do pas, fundado por Assis Chateaubriand. A primeira transmisso
em cores no Brasil s veio a ocorrer em 1962.

1.1 - Sistemas de Televiso

1.1.1 - Televiso Analgica
Para que seja possvel compreender as melhorias e novas funcionalidades disponveis
na televiso digital necessrio saber mais sobre o funcionamento da televiso analgica.
H 3 padres de televiso analgica disponveis em larga escala atualmente, e que
lentamente esto sendo substitudos por sinais digitais: NTSC (National Television System
Committee), PAL (Phase Alternation Line) e SECAM (Squentiel Couleur Avec Memoire).
Tais padres especificam nmero de linhas horizontais e verticais (quantidade de pontos),
nmero de quadros exibidos por segundo, em resumo, a qualidade da imagem sendo
transmitida. Nestes 3 padres, a proporo da imagem exibida de 4:3.
O padro NTSC utilizado nos pases da Amrica do Norte, alguns pases da Amrica
Central e do Sul, Japo, etc. O vdeo composto por 30 quadros por segundo e com 525
linhas horizontais. J o padro SECAM utilizado na Frana e em alguns de seus pases
vizinhos, utilizando 25 quadros por segundo e 625 linhas horizontais. Similarmente ao
SECAM, o padro PAL tambm usa 25 quadros por segundo e 625 linhas horizontais e
adotado na Europa ocidental e no Brasil, entre outras regies. Com as 100 linhas a mais, a
resoluo da imagem nos padres PAL e SECAM maior, dando mais nitidez e detalhes aos
quadros do que o padro NTSC capaz de fornecer.
Todos estes padres usam uma tcnica para reduo do efeito flickering (cintilao na
tela perceptvel 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 so
transmitidas seqencialmente de forma entrelaada, resultando em uma taxa de atualizao de
quadros mais rpida, dobrando a quantidade de quadros por segundo. Desta forma, o padro
NTSC consegue exibir 60 quadros por segundo enquanto os padres PAL e SECAM
conseguem uma taxa de 50 quadros por segundo. Em ambos os casos, a transiao de quadros
segundo a segundo torna-se mais suave aos olhos humanos, dando melhor sensao de
movimento da imagem (Zimet, 2002).
Houve ainda padro de televiso analgica, o MUSE (Multiple sub-nyquist sampling
Encoding system), desenvolvido pela NHK (Nippon Hoso Kyokay) nos anos 80, que usava
uma tcnica 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 padro utilizava transmisso
via satlite e possua 1125 linhas de definio e proporo de 1.66:1, o que o difere bastante
das outras opes em televiso analgica. Ainda assim, este padro possua imagem um tanto
borrada, mas pode ser considerado um grande avano tecnolgico para a poca. O Japo
anunciou que as transmisses com este padro seriam encerradas em meados de 2007.
Em todos os padres apresentados, algumas linhas no so visveis, nos padres com
625 linhas, 50 linhas no so visveis, nos padres com 525 linhas, entre 38 e 42 linhas no
so visveis e no padro de 1125 linhas, 90 ou 55 no so visveis. As linhas restantes servem
para sincronismo ou funcionalidades extras como closed caption (Fischer, 2004).
Na televiso analgica dois sinais so responsveis 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 responsvel por torn-la colorida a imagem. Esta separao faz com
que televises antigas monocromticas ainda sejam compatveis com sinal de televiso
analgica com imagem colorida.
A transmisso do sinal da televiso analgica ocorre atravs de ondas areas enviadas
por uma estao de televiso, em determinadas freqncias, que so pr-estabelecidas. Um
sinal de televiso analgica, composto por som e vdeo, necessita de uma banda de 6 MHz
para ser transmitido. Estas freqncias so 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 vdeo transmitido em um sinal AM, de amplitude modulada,

e o udio transmitido em um sinal FM, de freqncia modulada.

17
A qualidade da imagem na televiso analgica limitada no s devido tecnologia
da poca, que no disponibilizava aparelhos de televiso com alta definio, mas tambm pela
falta de uma alta compresso dos dados. Na citao a seguir, o autor previa a necessidade de
utilizar-se compresso no sinal de televiso, visando um avano 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 - Televiso Digital

As pesquisas em torno do desenvolvimento de uma televiso digital iniciaram-se em
1970 pelos cientistas da Sony e da NHK (Nippon Hoso Kyokay), uma empresa de transmisso
televisiva do Japo, com o intuito de melhorias na qualidade de udio e vdeo das
transmisses, de forma a tentar alcanar a qualidade de um filme de 35 mm. Nasce a o
conceito de HDTV - high definition television - um formato de televiso onde o nmero de
linhas que compem as imagens altamente ampliado. Logo se viu, entretanto, que essa
tarefa no seria simples. Um nico canal de 6 MHz no iria suportar o trfego da programao
nessa qualidade. A soluo s chegaria na dcada de 90, com a criao de um padro de
compresso de vdeo que est em uso at hoje, o MPEG, que significa Moving Picture
Experts Group. Fazendo uso de sofisticadas tcnicas de compresso, foi possvel obter um
vdeo com uma qualidade muito boa em um tamanho muito menor.
A grande diferena da televiso digital est justamente na forma de transmisso,
digitalizada. A televiso, como transmitida hoje em dia, faz uso de um sinal analgico,
transmitidos pelo ar em ondas eletromagnticas que ocupam completamente uma freqncia
de 6 MHz. A transmisso digital continuar usando esse espao de 6 MHz, transmitindo os
canais pelo ar. A diferena que os dados passam a ser digitalizados. Isso permite um uso
melhor da mesma faixa de freqncia, atravs da compresso do contedo, permitindo o
trfego de at 19 Mbits/segundo. Dessa forma, ser possvel que uma emissora transmita, por
exemplo, at 4 programaes distintas. Mas ela pode ocupar esse espao com imagens, udio
e dados, por exemplo. A prpria emissora quem define o que ser transmitido.
A digitalizao permitir um transporte maior de informaes, e, com isso, o vdeo e o
udio podero possuir uma melhor qualidade. A comear pelo tamanho da tela de vdeo. Hoje
em dia, usa-se a proporo 4:3, entretanto, com a difuso das televises widescreen e com a

18
melhoria da qualidade dos vdeos transmitidos, a resoluo 16:9, com propores de cinema,
tende a se tornar padro.

Figura 2: Comparao entre rea da televiso comum (4:3) com o padro HDTV (16:9)

O vdeo transmitido na maior qualidade, recebe o nome de HDTV (High Definition

Television). Com tela em formato 16:9, usa udio estreo 5.1 e qualidade de imagem que
pode ser de 720 linhas x 1280 pixels/linha ou 1080 linhas x 1920 pixels/linha. O vdeo no
formato EDTV (Enhanced Definition Television) tambm segue padro de 16:9 e udio 5.1,
porm o tamanho da tela bem inferior, sendo de 480 linhas x 720 pixels/linha.
considerado o padro mdio entre o HDTV e o SDTV (Standard Definition Television), o
formato padro, com resoluo 4:3, tela de tamanho 480 linhas x 680 pixels/linha e 60
quadros por segundo. Alm desses, ainda h o LDTV (Low Definition Television), um padro
voltado para dispositivos mveis. Com 30 quadros por segundo, o LDTV possui tela com
tamanho de apenas 240 linhas x 320 pixels/linha (Fernandes et al., 2004).
A transmisso de dados tambm ir permitir uma maior interatividade do usurio com
a televiso. Ele poder votar em enquetes realizadas pelos programas, saber mais informaes
da atrao ou da programao do canal e at mesmo comprar produtos relacionados com o
que estiver sendo transmitido.
Por esse motivo a televiso digital no deve ser encarada como apenas uma melhoria
da televiso analgica, e sim como uma mudana de paradigma. Ela uma nova plataforma,
com novas funcionalidades e com potencial para revolucionar a forma que a sociedade assiste
televiso, pois adicionar interatividade.
Diversas tecnologias tm surgido nos ltimos anos de forma a tentar reproduzir, na
televiso analgica, as vantagens que a televiso digital trar. Empresas de transmisso de

19
canais pagos j possuem suas verses digitais que exibem dados sobre a programao para os
telespectadores. A LG lanou recentemente uma televiso que contm internamente um disco
rgido de 80GB que consegue gravar a programao para ser exibida posteriormente.
Nos Estados Unidos h uma espcie de televiso interativa chamada TiVo (Gartner,
2005). Trata-se de um aparelho instalado no televisor que permite no s que os usurios
gravem e assistam seus programas favoritos na hora que quiserem, mas tambm que criem
uma programao de acordo com seus gostos. possvel, por exemplo, criar um canal s de
desenhos. O aparelho se encarrega de verificar a programao dos canais disponveis e gravar
o que se adequar aos filtros definidos pelo prprio usurio. Atravs de uma linha telefnica, o
TiVo tambm se conecta internet. Dessa forma, ele consegue trazer para a televiso
informaes personalizadas pelo usurio.
Algumas promessas da televiso digital j so uma realidade em alguns lugares do
mundo, mas so conseguidas atravs de aparelhos anexados s televises com HDs internos
para armazenamento dos vdeos e que assim, conseguem simular essa tecnologia que est por
vir, na trasmisso analgica convencional. A televiso de alta definio, por sua vez, tambm
j uma realidade no Japo, onde, em 1 de dezembro de 2000, a NHK, que iniciou as
pesquisas da tecnologia, fez a primeira transmisso em HDTV. Entretanto h elementos que
ainda no conseguem ser reproduzidos com a transmisso analgica. Principalmente no que
diz respeito interao do usurio com o que est sendo transmitido.
Com a transmisso digital, ser possvel o envio de diversos canais de vdeo e udio.
Assim, ser possvel 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 vrios
ngulos de cmera para que o telespectador escolha a que mais lhe agradar. A interatividade
estar presente na prpria programao, mesmo sem a necessidade de envio de um sinal de
retorno, ou seja, informao vinda das casas dos telespectadores emissora. Para uso de todas
as funcionalidades prometidas pela televiso digital, entretanto, necessria a existncia de
uma forma de retornar o sinal. O consenso atual que a forma escolhida seria a internet. A
televiso - ou o Set-Top-Box, aparelho que reproduz o sinal digital nos televisores
convencionais - teria que ser conectado linha telefnica, ou a redes domsticas conectadas
internet.
H trs formas de transmisso do sinal: transmisso terrestre, atravs de cabo ou a
transmisso via satlite. 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 televiso analgica e suporta
atualmente uma banda de at 550 MHz. Nos sistemas de transmisso analgica via cabo

20
atuais, o sinal embaralhado e decodificado nas residncias. O embaralhamento feito para,
por exemplo, limitar a quantidade de canais de um usurio. Um sinal inserido na
transmisso, levemente deslocado da freqncia e o sinal retirado com o uso do
decodificador. A televiso digital utiliza uma forma mais segura que o embaralhamento: a
codificao. O sinal enviado codificado e decodificado nas residncias atravs do uso de
uma chave apropriada. Caso no haja chave para decodificao, ao invs de um sinal
embaralhado, a televiso pode exibir propagandas ou uma tela qualquer. O sistema de
transmisso via cabo, porm, apresenta grandes desvantagens, como o alto custo e a
dificuldade de implantao em regies remotas, bem como sua disseminao local.
Para essas regies mais afastadas das grandes cidades, a transmisso por satlite
apresenta uma tima soluo. Ela eficaz porque o satlite possui uma rea de alcance muito
maior que as antenas de transmisso terrestre. Os dados so enviados e recebidos ao satlite
com o uso de antenas chamadas parablicas de satlite. Os satlites de televiso mantm-se
em rbita geossncrona em relao Terra, o que quer dizer que o movimento deles
acompanha o movimento de rotao da Terra. Dessa forma, as parablicas para recepo de
sinal de televiso por satlite s precisam ser ajustadas uma vez que continuaro recebendo o
sinal.
Porm a transmisso terrestre que dever ser usada para a transmisso digital, graas
ao seu baixo custo. Alm disso, no h necessidade de se pagar assinaturas s emissoras.
Atravs de grandes antenas, os sinais so transmitidos por ondas de radiofreqncia pelo ar e
podem ser captados nas residncias atravs de receptores apropriados, assim como
transmitido o sinal de televiso analgica pblica.
Alm da forma de transmisso, necessrio tambm realizar a escolha do padro de
televiso digital a ser usado (Fernandes et al., 2004). O padro escolhido decidir o mtodo a
ser usado em cada uma das trs etapas principais da transmisso digital.

A codificao do sinal, que converter o udio e vdeo para sinais digitais.

consenso entre os trs padres de que a codificao usada nessa etapa ser em
vdeo MPEG.

A multiplexao a segunda etapa. Ela se encarrega de transformar os sinais que

foram digitalizados de udio, vdeo e dados em um nico feixe digital.

A modulao a etapa que se encarrega de converter o feixe digital gerado na

multiplexao em um ou mais sinais que poderiam ser transmitidos usando uma
das trs formas descritas (terrestre, satlite ou cabo).

21
1.2 Padres de transmisso digital
Na figura a seguir, so representadas as interaes entre as diversas estapas para que a
transmisso do sinal digital seja efetuada a partir de um vdeo analgico:

Figura 3: Etapas para converter um vdeo analgico em um sinal de televiso digital

1.2.1 - Padres para Codificao e Compresso

a etapa responsvel por converter o vdeo analgico para arquivos de udio e vdeo
digitais. Todos os sistemas j definiram como padro para codificao e compresso do vdeo
o MPEG-2, criado em 1992 pelo Moving Picture Experts Group. Ele se divide, na verdade em
um grupo de padres de compresso de vdeo, udio, identificao de objetos multimdia,
entre outros. O MPEG, estabelece um conjunto de padres, entre os quais se encontram o
MPEG-2, MPEG-4, MPEG-7 e MPEG-21, estes dois ltimos provendo algumas
funcionalidades teis para a televiso digital e que sero utilizadas neste trabalho.
Uma das caractersticas do MPEG o fato de o custo de codificao ser muito maior
que o custo de decodificao. Assim, num sistema de televiso, por exemplo, o maior custo
cabe s emissoras transmissoras do vdeo, enquanto a decodificao pode ser feita num
receptor mais barato. Detalhes sobre o padro MPEG, sua codificao e suas funcionalidades
sero explorados no captulo 2.

1.2.2 - Padro para Multiplexao e Transporte

As informaes de udio, vdeo e outros dados so agrupadas em fluxos de programa.
A multiplexao se encarrega de converter todos os fluxos de programa em um nico fluxo de
transporte denominado Transport Stream, usando padro MPEG-2 TS. Cada pacote gerado
pela multiplexao possui tamanho fixo de 188 bytes. Isso ocorre para facilitar o processo de
tratamento de erros, alm de aumentar a velocidade do processamento. Cada pacote possui

22
obrigatoriamente um header de no mnimo 4 bytes. Cada header possui um campo
denominado PID (Packet Identifier), usado para a indentificao do pacote. Os bytes
posteriores so 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 verificao 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 esto sujeitos a erros ou interferncias. Quando esses erros
so detectados, um bit do pacote alterado de forma a informar o demultiplexador que aquele
pacote contm erros. Esse bit se encontra no header do pacote e usado especificamente para
a detecco de erros.
Uma seqncia de pacotes resultante de uma multiplexao pode ser multiplexada
novamente. Caber ao receptor fazer o processo inverso, demultiplexar a seqncia e entregar
os itens corretos para seus respectivos decodificadores.

1.2.3 - Padres para Modulao e Transmisso

A modulao se encarrega de deixar o feixe de dados gerado na multiplexao em um
ou mais sinais que possam ser transmitidos. H dois mtodos principais de modulao: o 8VSB e o COFDM.
O padro 8-VSB (Eight Vestigial Side Band) usa uma nica portadora e um nico eixo
de modulao para simplificar os circuitos do receptor. Uma portadora um sinal analgico
em forma de onda que representa a informao a ser transmitida. O fluxo de bits resultante da
multiplexao embaralhado, de forma a espalhar melhor a energia, sem concentrar muito em
determinados pontos. feita uma codificao para correo de erros e os bits so entrelaados
para evitar a perda de vrios segmentos inteiros.
O COFDM (Coded Orthogonal Frequency-Division Multiplexing) usa um sistema de
multiportadoras. Assim, a modulao 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 transmisso, o espaamento de freqncia das ondas das
portadoras feito de forma que uma seja ortogonal a outra, de forma que uma no consiga
interferir na outra.
A modulao COFDM usa ainda um sistema de deteco de erros. A modulao
comumente feita usando transformada rpida de Fourier. Uma das vantagens que ele
apresenta sobre a modulao 8-VSB no que diz respeito transmisso em cidades com

23
grandes diferenas geogrficas, como So Paulo, com densidade de edifcios, produzindo
padres de sombra e multipercurso, que so prejudiciais propagao UHF.

1.3 - Arquitetura da Televiso Digital Interativa

A arquitetura de um sistema de televiso digital composta por camadas, tanto do
lado do provedor de servios de televiso, quanto do lado cliente. Estas camadas apenas se
comunicam com as camadas diretamente superiores ou inferiores a elas, e cada padro de
televiso digital implementa cada camada da sua prpria maneira, j que o nico consenso
entre os padres foi a adoo de um padro MPEG, que atende s expectativas de compresso
necessrias para a transmisso de vdeos de alta definio com baixo consumo de banda. A
figura abaixo representa tais camadas (Paes, Antoniazzi, 2005) e (Fernandes et al., 2004):

Figura 4: Processo de transmisso e recepo de dados da Televiso Digital

Do lado do provedor de servios, o contedo produzido e enviado camada de

middleware atravs de aplicaes prprias para o broadcast. Em seguida, o corre a
compresso desse contedo, e a multiplexao feita pela camada de transporte. Nesta etapa,
udio, vdeo e dados viram um nico elemento, que ser chamado de servio. Este servio
ser enviado para modulao e transmitido de acordo com o meio de transmisso adotado.
No lado cliente, tais camadas so implementadas dentro de um computador
denominado STB (Set-Top-Box), que pode estar embutido dentro da prpria televiso. O STB

24
possui memria, processador, disco de armazenamento e uma srie de componentes tambm
presentes em microcomputadores.
Tal aparelho tem a funo de realizar a receptao deste sinal de televiso digital, seja
qual for o meio de transmisso, e realizar a demodulao, transformando-o para a forma
lgica novamente. Em seguida, esses dados so demultiplexados, separando udio, vdeo e
dados novamente, descomprimidos e ento o sistema operacional e o middleware processam
essa informao. As informaes de udio e vdeo sero enviadas a um Controlador de Mdia
presente no middleware, que ser responsvel pela apresentao dessas informaes ao
usurio, e os outros dados sero enviados a um subsistema denominado SI (Service
Information), responsvel por disponibilizar aplicaes aos usurios, exibir dados como
legenda, imagens estticas, etc. H ainda o Gerador de Carrossel, que responsvel por
estabelecer uma fluxo de dados entre o provedor de servios e o STB, enquanto o servio
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 possvel a um
STB que sintonizou o servio receber este sistema de arquivos, mesmo aps o incio da
difuso (Fernandes et al., 2004)
Para o maior aproveitamento da interatividade disponvel nesta plataforma,
necessrio que o STB tenha um canal de retorno, ou seja, uma conexo com a internet, ou
com linha telefnica (h diversas outras maneiras propostas em (Oliveira, Albuquerque, 2005)
para que o STB possa enviar informaes ao prestador de servios, e no somente receber, o
que possibilita uma infinidade de novas aplicaes para o cliente.

1.4 - Padres de televiso digital

Atualmente h trs padres fazendo uma disputa pelos mercados dos pases que ainda
no definiram o futuro de sua televiso digital. Todos os padres adotam a tecnologia de
compresso de udio de vdeo e de multiplexao do MPEG, devido necessidade de
transferncias de elevadas quantidades de dados. Como pode ser visto na tabela, todos estes
padres utilizam a codificao MPEG-2 mas alguns padres j estudam o uso codificaes
diferentes como o MPEG-4 para obter taxas de compresso ainda maiores.
A tabela a seguir (Peng, 2002) compara alguns importantes aspectos dos padres
DVB, ATSC e ISDB.

25
Tabela 1: Comparao entre os padres de televiso digital
Padro

Tipo

Codificao Codificao
do vdeo
do udio

Banda
utilizada

DVB

DVB-S
DVB-T

MPEG-2

MPEG-2/1
Digital Sound

8 Mhz

AC-3

6 Mhz

DVB-C
ATSC-T MPEG-2

ATSC

ATSC-C

ISDB

ISDB-S
ISDB-T

ISDB-C

Taxa de
transmisso
(Mbps)
38
24
15 (disp.
mveis)
38
19.28
38.57

MPEG-2

MPEG-2
AAC

34,5 Mhz
5,6 Mhz

6 Mhz

52
21.47
4.06 (disp.
mveis)
31.644

Pases que
adotaram
Europa,
Austrlia,
Rssia,
Taiwan, etc
Amrica do
Norte,
Mxico,
Argentina,
etc
Japo, Brasil

1.4.1 - ATSC (Advanced Television Systems Committee)

O padro foi adotado nos Estados Unidos, Canad, Coria do Sul, entre outros pases.
Tem como intuito a melhoria na implementao da transmisso televisiva de alta definio, a
HDTV. Vm sendo desenvolvido desde 1987 e est em uso nos Estados Unidos desde 1998.
Por ter sido o padro pioneiro, este ainda tem problemas que j foram consertados nos outros,
principalmente no que diz respeito transmisso para dispositivos mveis, que o principal
ponto fraco deste padro. Foi desenvolvido de forma a no sofrer interferncia das
transmisses NTSC - as transmisses analgicas. Usa a modulao 8-VSB, o que garante uma
taxa de transmisso de aproximadamente 19,8Mbps (ATSC, 2004). O sinal de udio usa
codificao Dolby AC-3 e o sinal de vdeo usa codificao MPEG-2 Vdeo, na qualidade de
HDTV.
Para a camada de middleware, que a camada que faz a interao do software de
televiso digital com o hardware da Set-Top-Box, o ATSC usa o padro DASE (DTV
Application Software Enviroment), que suporta a execuo de aplicaes 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 exibio de vdeo esto o 1080i e o 720p, ambos formatos
de vdeo em alta qualidade com tela de propores 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
exibio menos - de 720 pixels verticais por 1280 pixels horizontais -, entretanto, possui uma
taxa de atualizao da tela de 60 quadros por segundo - duas vezes maior que o formato
1080i.

1.4.2 - DVB (Digital Vdeo Broadcasting)

O padro DVB j adotado pela Europa, Austrlia, ndia, frica do Sul, entre outros
pases. Iniciado em 1993, a partir de uma equipe de 300 membros, entre fabricantes,
emissoras de televiso, desenvolvedores de software e orgos de regulamentao. Por padro,
funciona transmitindo em um canal de 7Mhz, mas possui tambm suporte a canais de 6Mhz e
8 Mhz. Atravs da modulao COFDM (Coded Orthogonal Frequency Division
Multiplexing), este padro permite taxas de transmisso que variam entre 3,74Mbps e
23,75Mbps. (DVB, 2004)
Com formatos que variam de 240 a 1080 linhas, este padro permite que seja
simultaneamente feita transmisso de HDTV e transmisso para dispositivos mveis. O
enfoque do DVB diversificar a quantidade de programas e servios. Assim, o padro
permite uma maior quantidade de operadoras de transmisso.
O udio codificado em formato MPEG2-BC e o vdeo usa MPEG-2 Video na
qualidade standard.
O padro de middleware chamado MHP (Multimedia Home Plataform) e permite
funcionalidades como o uso de um canal de retorno, permitindo o feedback das residncias s
emissoras de televiso. Assim como o padro DASE, do ATSC, este padro de middleware
permite o uso de aplicaes 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 padro japons de televiso digital. Foi criado em 1997, pelo grupo DiBEG (Digital
Broadcasting Experts Group). Surgiu a partir do padro europeu DVB, sendo muito parecido
com ele. Destaca-se principalmente na rea da transmisso digital para dispositivos mveis
(ISDB, 1998).
Usa o mesmo padro de modulao do DVB, o COFDM, que permite uma taxa de
transmisso de dados entre 3,65Mbps e 23,23 Mbps. Possui melhorias em relao ao DVB no
que diz respeito interferncia dos sinais mveis com a transmisso de televiso em alta

27
qualidade. O udio codificado em padro MPEG-2 ACC (Advanced Audio Coding) e o
vdeo 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 - Padro Brasileiro

Alguns pases, entretanto, no pretendem aderir a nenhum dos padres j existentes,
criando seu prprio. A China um exemplo, desenvolvendo atualmente o DMB-T (Digital
Media Broadcasting Terrestrial).
O Brasil outro pas que pretendia, ao invs de escolher um dos padres, desenvolver
um padro prprio para o mercado brasileiro. A Sociedade de Engenharia de Televiso (SET)
comeou em novembro de 2003 a criao do que foi chamado SBTVD (Sistema Brasileiro de
Televiso Digital) e, depois renomeado para ISDTV (International System for Digital TV).
A tecnologia brasileira seguia bem adiantada. Os sistemas SORCER e MISBTVD foram desenvolvidos pela Pontifcia Universidade Catlica do Rio Grande do Sul
(PUC-RS) e pelo Instituto Nacional de Telecomunicaes (Inatel) para realizar a modulao
da televiso digital brasileira. O middleware recebia o nome de Ginga e j estava
desenvolvido, sendo uma unificao do sistema declarativo Maestro, desenvolvido pela
Pontifcia Universidade Catlica do Rio de Janeiro (PUC-RJ) com o sistema procedural
FlexTV, desenvolvido pela Universidade Federal da Paraba (UFPB).
Os padres de codificao de udio e vdeo ainda no estavam definidos, e ainda assim
o sistema apresentava timos resultados em comparao com os demais apresentados.
Entretanto, o governo brasileiro anunciou em 2006 que o padro que seria adotado nas
transmisses digitais de televiso no Brasil seria o padro japons, o ISDB. A escolha gerou
crticas pelo fato de ser um padro que privilegia em alguns aspectos as emissoras de
televiso. o padro, porm, que obteve os melhores resultados nas pesquisas da Anatel.
As promessas so para que em 10 anos o sistema digital esteja completamente
implantado no pas. A transmisso analgica, entretanto, ainda dever permanecer por mais
algum tempo. Os televisores atuais ainda no possuem capacidade de executar a transmisso
digital. Assim, tm-se a necessidade de uso de um aparelho que possa codificar o sinal digital
para ser transmitido nas televises, o Set-Top-Box, enquanto as televises ainda no sarem
de fbrica com a funcionalidade deste aparelho. Por um tempo, entretanto, a televiso digital

28
seria transmitida juntamente com a televiso analgica, para que a nova tecnologia possa se
firmar gradativamente.
Alguns outros grandes problemas ainda no tm soluo aparente. Para uso completo
de todas as funcionalidades esperadas, por exemplo, seria necessrio o retorno do sinal, das
residncias s emissoras de televiso. Num pas onde apenas 20% da populao tm acesso
Internet, uma grande parcela - especialmente a mais pobre - no poderia usufruir de todas as
funcionalidades prometidas.
As mudanas com a chegada da televiso digital tambm atingem a gravao dos
programas. Com programas sendo transmitidos em qualidade altssima, os equipamentos de
gravao teriam que ser melhorados para conseguir melhor qualidade de imagem. As cmeras
atualmente usadas nas gravaes no suportariam a qualidade da imagem que seria
apresentada.

1.5 - Middlewares
Middleware um termo genrico usado para representar softwares que interagem com
o sistema operacional, hardware e alguns protocolos de comunicao, trabalhando como
mediadores dessas funcionalidades para outras aplicaes. Suas principais funes so:

Esconder a distribuio do sistema para o usurio;

Esconder a heterogeneidade de componentes de hardware, sistemas operacionais e

protocolos de comunicao;

Fornecer interfaces de alto nvel para desenvolvedores, de modo a facilitar o

processo de desenvolvimento.

No caso da televiso digital, existem diferentes padres, cada um fornecendo STBs

diferentes, onde as caractersticas de hardware e at mesmo o sistema operacional dos
mesmos variam (levando em considerao que a nica caracterstica igual entre os padres a
adoo ao padro MPEG), a taxa de transferncia e a freqncia utilizada pelos padres
tambm, enfim, h muita heterogeneidade entre eles, tornando este ambiente propcio ao uso
de middleware, pois desenvolver uma aplicao portvel entre vrios padres de televiso
digital sem middlewares geraria um elevado custo e perda de tempo, anlogo a desenvolver
uma aplicao em C++ e outra em Java com a mesma funcionalidade. A prpria
interatividade da televiso digital, com imagens, textos, grficos, faz com que o middleware
se torne necessrio, para que os desenvolvedores no se preocupem com as camadas mais
baixas da plataforma.

29
Para facilitar o desenvolvimento de aplicaes nesta plataforma, e tornar as aplicaes
mais portveis, os STBs devem prover uma API (Application Programming Interface)
genrica bem definida, com o intuito de abstrair um pouco dessa heterogeneidade presente
para outras aplicaes (Fernandes et al., 2004).
Os benefcios do uso de um middleware no se fazem necessrios s no front-end
(STBs), mas tambm no back-end em caractersticas como: converso de contedo Web para
televiso, proxy, segurana, gerenciamento do assinante, etc. (Paes, Antoniazzi, 2005)
Devido a essa grande quantidade de benefcios, os rgos que projetam os padres de
televiso digital tambm desenvolvem seu prprio middleware, de forma com que este
funcione melhor com as caractersticas pr-estabelecidas no padro. Desta forma, o padro
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 televiso Digital.

Figura 5: Estrutura do modelo funcional de um middleware

Porting Layer camada entre os drivers e o Middleware;

Network Layer responsvel pelo gerenciamento do transporte, comandos e

controles da rede;

30

Security integra a autenticao do usurio com os propsitos do CAS e DRM

(Digital Rigths Management);

Kernel o crebro do STB. Gerencia os arquivos do sistema, a memria e

acodificao de audio e vdeo;

Presentation Control atua na experincia do usurio que assiste a televiso;

Application Management Layer gerencia o contedo, os servios da plataforma

interativa e os aplicativos.

Considerando que cada padro tem o seu middleware, a tarefa do desenvolvedor de

aplicaes para tal plataforma a facilidade; porm, 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 sero
explicados a seguir. Assim, a tarefa de portar aplicaes entre diferentes padres de televiso
digital ligeiramente facilitada.

1.5.1 Blocos Fundamentais

1.5.1.1 DAVIC
DAVIC (Digital Audio-Visual Council) uma associao de diversas empresas do
setor udio-visual, rgos de pesquisa, rgos do governo e prestadores de servios de
telecomunicaes e televiso criada em 1994 e que durante 5 anos desenvolveu um padro
para a interoperabilidade de comunicao multimdia e difuso de dados udio-visuais
interativos. (DAVIC, 1999)
Seu objetivo era facilitar o desenvolvimento de aplicaes udio-visuais e sua
interoperabilidade especificando padres de interfaces e protocolos a serem utilizados. Sua
ltima especificao, a 1.5, passou a englobar aplicaes e servios para televiso interativa.
As APIs definidas nesta especificao abrangem controle de acesso, filtragem de
informaes, notificao, acesso a informaes do servio e controle de sintonizao
(Fernandes, 2004). Para oferecer suporte televiso interativa, a especificao apenas
acrescentou protocolos na parte de rede e controle, sem nenhuma modificao nas APIs ou
outros protocolos de nveis mais alto. Suas principais APIs so (DAVIC, 1999):

MPEG-2 Section Filter API serve para acessar dados anexos ao MPEG-2, como
metadados de outros padres 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 bsicos do

MPEG

Tuning API prov um mecanismo para seleo de servios

atravs da

sintonizao de diferentes streams MPEG-2

Conditional Access API prove uma interface de acesso algumas funes

especficas como EPG(Eletronic Program Guide) com a possibilidade de controle
desse acesso

Media Player API fornece controle da execuo do vdeo em tempo real,

baseado na JMF (Java Media Framework)

DSM-CC User-to-Network API fornece uma aplicao para controlar sesses de

usurios

A especificao ainda conta com uma extenso de API para tratamento de interface
para o usurio, utilizando o pacote AWT j disponvel na API do Java.

1.5.1.2 HAVi
HAVi (Home Audio Video interoperability) uma iniciativa de 8 grandes fabricantes
de produtos eletrnicos que visa fornecer uma especificao para a interoperabilidade entre
dispositivos de udio e vdeo dispostos em uma rede domstica. Prope uma rede onde
dispositivos de udio e vdeo tenham controle sobre outros dispositivos de udio e vdeo,
independentemente da configurao 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 possvel fazer com que dispositivos de diferentes marcas
interajam entre si, j que uma arquitetura de especificao aberta, independente de
plataforma ou linguagem de programao. Assim, possvel fazer dispositivos se
comunicarem, mesmo sem utilizarem o mesmo sistema operacional ou linguagem de
programao, por exemplo. Basta que todos implementem uma verso desta arquitetura e
usem a API definida pela especificao.
A rede escolhida para suportar dados multimdia e troca de comandos entre os
dispositivos foi a IEEE-1394, tambm conhecida como Firewire. Este tipo de rede tem a
capacidade de transportar 400Mb/s e tem a vantagem de suportar comunicao sncrona,
tornando possvel que dados multimdia sejam transferidos em tempo real. Verses desta rede

32
utilizando tecnologia wireless, linhas telefnicas, entre outras, foram previstas desde o
comeo da especificao HAVi, possibilitando que adaptaes para as mesmas possam ser
desenvolvidas.
HAVi uma arquitetura de software distribudo que implementa elementos como
controle de rede, abstrao de dispositivo, comunicao entre dispositivos e ainda a interface
para o usurio (HAVI, 1999), que juntos, formam uma API para a interoperabilidade desta
arquitetura. Os elementos de software sao:

1394 Communication Media Manager possibilita comunicao sncrona e

assncrona

Messaging System responsvel pela troca de mensagens entre elementos

Registry prov services de busca de outros elementos, bem como a deteco de

suas propriedades

Event Manager servio que dispara eventos

Stream Manager gerencia as transferncias de udio e vdeo da rede

Resource Manager facilita o compartilhamento e agendamento de aes

DCM (Device Control Module) representa um dispositivo na rede e expe sua

API

FCM (Functional Component Module) representa cada funo disponvel em um

DCM

DCM Manager responsvel pela instalao e desinstalao de dispositivos na

rede

Applications aplicaes precisam ser conhecidas pela rede antes de interagirem

Alm destes elementos de software, a arquitetura apresenta alguns elementos de software

especiais para lidar com a interface com o usurio. So eles:

DDI (Data Driven Interaction) serve como protocolo e utilizado entre

aplicaes e DCMs quando uma interface precisa ser exibida lado a lado com umo
prprio display do aparelho

Havlet usada para desenhar interface para o usurio na tela de um dispositivo

Um bom exemplo de uso desta arquitetura, do lado cliente, uma solicitao de

agendamento para gravao de contedo televisivo, feito a partir da televiso, para um DVDRecorder. Porm, se na hora da gravao a televiso 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 maro de 1998, a Sun Microsystems anunciou a Java TV API, definindo uma
plataforma totalmente Java para televiso digital (Morris et al., 2005). Parte deste trabalho foi
padronizar o uso de APIs j existentes para o uso na televiso digital, como a JMF (Java
Multimedia Framework), que usada para o gerenciamento do fluxo de udio de vdeo, e a
outra parte deste trabalho foi criar novos pacotes que atendessem s necessidades de
caractersticas especficas da plataforma que foram surgindo medida em que a tecnologia de
televiso digital e o conceito de interatividade envolvido, evolua. Atualmente, esta API
distribuda com o pacote J2ME.
Oferece uma plataforma de desenvolvimento bastante rica em recursos especficos
para os recentes avanos tecnolgicos em televiso digital, podendo acessar e controlar
algumas funcionalidades da mesma, assim como controle de acesso, seleo de contedo,
controle de canais, streaming de udio e vdeo, acesso aos canais de entrada e sada de dados,
informaes do servio (anlogo ao canal de televiso) e ainda proporcionar a criao de
elementos visuais por cima do vdeo que est sendo exibido para o telespectador. Um servio
caracterizado por um conjunto de informaes (Service Information) e as informaes sobre
os servios disponveis so armazenadas em um banco de dados especfico (SI Database)
(Fernandes et al., 2004).
Alm disso, acrescentar funcionalidades como sincronizao de contedo interativo
da televiso digital com o vdeo e o udio de um determinado programa de televiso, e
tambm o controle do ciclo de vida de uma aplicao, que poder existir ao mesmo tempo em
que os programas de televiso, como anncios, por exemplo. Desta forma possvel que o
telespectador aproveite ao mximo os novos recursos da televiso da era digital, alcanando
nveis de interatividade com tal meio de comunicao at ento 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 nvel mais elevado, um software
desenvolvido para um receptor de televiso 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 contedo interativo, como anncios de produtos, informaes extras
sobre a programao, seleo de legendas, entre outras inmeras novidades existentes nesta
plataforma. Em um nvel mais baixo, o sistema operacional real-time contm diversos drivers
e bibliotecas especficas de suporte ao hardware, bem como a estrutura necessria para a
execuo da mquina virtual Java e outras bibliotecas incorporadas pela plataforma Java.

34
Uma caracterstica importante da plataforma Java sobre este tipo de hardware que ela
encapsula todas as funcionalidades que o sistema operacional expe para o controle do
hardware.
No lado do hardware, a Java TV API roda sobre um hardware muito especfico e
limitado, se comparado a um computador, que o receptor de televiso digital. Este receptor
lida com o sinal de vdeo e de dados de acordo com o meio de transmisso e realiza tarefas
como sintonizao, mudana de canal e demultiplexao dos dados. A Java TV API
proporciona uma abstrao ao hardware do receptor, fornecendo pacotes suficientes para o
controle de tais operaes, deixando que o desenvolvedor se preocupe apenas com o software
em si, e no com detalhes especficos da plataforma ou drivers para o controle do hardware.
Esta abstrao fundamental para o sucesso desta API, j que diferentes padres de televiso
digital foram desenvolvidos, e continuam sendo aprimorados, gerando assim, algumas
derivaes dos mesmos em uma grande escala. Tais padres sero implantandos nestes
receptores, e cada um ter suas particularidades, e caber ao fabricante do receptor adot-lo e
adapt-lo s especificaes Java. Esta caracterstica, h tempos est presente nos
computadores, como por exemplo, uma aplicao desenvolvida em Java sobre um sistema
operacional Mac capaz de ser executada, da mesma forma, sobre um sistema operacional
Windows. A mquina 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 televiso digital. (Fernandes et al., 2004)

Figura 6: Pilha de software em um receptor de televiso digital

35
Uma aplicao desenvolvida com a Java TV API chamada xlet. Semelhante ao
Applet na web e ao Midlet nos dispositivos mveis, um xlet no precisa estar previamente
armazenado no STB para que seja executado, pois ele pode ser enviado da mesma forma
como o vdeo pelo canal de difuso, e posteriormente executado.
A figura a seguir mostra o ciclo de vida de uma aplicao 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 aplicao, que passa um objeto XletContext para a xlet, que
define seu contexto de execuo, que por sua vez, possibilita que a xlet notifique o gerente de
aplicao sobre mudanas de estado, num mecanismo semelhante ao de callbacks adotados
em diversas plataformas. Aps sua inicializao a xlet fica no estado Paused, onde ainda est
inoperante, e no retm informaes do servio. Neste estado, a xlet pode ser ativada e entrar
em execuo com todas as suas funcionalidades, passando para o estado Active, e em qualquer
estado a xlet pode ser destruda.
O objetivo da Sun Microsystems ao desenvolver esta API fazer com que as
necessidades dos fabricantes, desenvolvedores e distribuidores de contedo (canais de
televiso) sejam atendidas medida que estes procuram por solues seguras e portveis, pois
diferentes tipos de receptores so desenvolvidos para trabalharem com diferentes padres de
televiso digital. Alguns padres de televiso digital j adotam esta API, tornando-a um
grande recurso para desenvolvedores de aplicaes interativas.

1.5.1.4 Microsoft TV
A Microsoft tambm faz um importante trabalho no desenvolvimento para a
plataforma de televiso digital. Eles possuem uma plataforma toda baseada em softwares

36
prprios e buscam oferecer seu produto como uma alternativa utilizao da televiso digital
com outras APIs. Ao contrrio da Java TV API uma plataforma privada, e no de cdigo
aberto. Por outro lado, uma soluo para integrar as diferentes tecnologias necessrias para
se ter um ambiente de televiso digital adequado, pois ao invs de usar APIs de interface
grfica em conjunto com Java TV API, seria possvel usar apenas as APIs da prpria
Microsoft. Desta forma, o desenvolvedor encontra menos flexibilidade, porm mais facilidade
no desenvolvimento da aplicao.
Esta plataforma pode ser utilizada com diferentes meios de transmisso em que o sinal
de televiso digital capaz de ser transmitido e possui funcionalidades como suporte vdeos
de alta resoluo, gravao de vdeo no formato digital e aquisio de vdeos sob demanda.

1.5.2 - Padres
1.5.2.1 MHP
MHP (Multimedia Home Platform) o middleware desenvolvido pelo padro de
televiso digital europeu, o DVB (DVB, 2004). Este middleware define uma interface
genrica entre as aplicaes e o ambiente no qual essas aplicaes so executadas, por
exemplo o STB, criando uma abstrao entre as aplicaes e o ambiente (hardware e
software) em que elas residem. Desta maneira as aplicaes com base em MHP, sero
compatveis com STBs, televises com sistema digital integrado e computadores multimdia.
O MHP estende os padres DVB para broadcast e servios interativos em todos os
tipos de transmisso de sinal: cabo, terrestre, satlite, etc.
Sua arquitetura definida em 3 camadas (DVB, 2004):

Aplicaes: como EPG, informaes do servio, jogos, e-commerce, transaes

seguras e aplicaes educacionais;

Softwares de sistema: como o gerenciador de aplicaes (ou navigator), outras

APIs, protocolos de transporte e mquinas virtuais, como a JVM;

Recursos: como o processamento do MPEG, grficos, entrada e sada de dados e

unidade de processamento.

Este middleware baseado numa plataforma chamada DVB-J, em sua forma

procedural, que utiliza a mquina virtual Java. Toda aplicao baseada em MHP nesta forma,
deve usar softwares do sistema para acessar os recursos da plataforma atravs de APIs
especificadas. Dentre estas APIs esto 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 trs tipos de perfis para implementao das plataformas de
servios(Paes, Antoniazzi, 2005):

Enhanced Broadcast suporte a recepo de udio, vdeo e servios de download

de aplicaes de interatividade apenas local, pois no tem o canal de retorno,
tambm chamadas de one-way services. Possui suporte a DVB-HTML;

Interactive Broadcast possui todas as caractersticas do perfil Enhanced

Broadcast, com a vantagem de implementar um canal de retorno, deixando de ter
interatividade apenas local, podendo de comunicar com o servio de broadcast ou
no; A comunicao feita com a utilizao do protocolo IP;

Internet Access possui todas as caractersticas do perfil Interactive Broadcast,

com a vantagem de poder se conectar Internet. Desta forma, servios como email tornam-se possveis nesta plataforma.

Na primeira verso do middleware, 1.0, apenas os dois primeiros perfis estavam

disponveis. S na verso 1.1 surgiu o Internet Access.

1.5.2.2 DASE
DASE(DTV Application Software Environment) o middleware desenvolvido para o
padro de televiso digital americano ATSC (ATSC, 2004). O middleware DASE interage
com a camada de transporte, de modo a transformar a informao recebida pelo broadcast em
sada de vdeo e udio para a televiso acoplada.
Assim como as aplicaes MHP, as aplicaes DASE possuem forma declarativa e
procedural. Na forma declarativa as aplicaes podem ser escritas em HTML, XHTML ou
mesmo XML e conter folhas de estilos, scripts, etc. E na forma procedural a aplicao 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 aplicaes declarativas. Este subsistema tem
um componente chave chamado DCDE (Declarative Content Decoding Engine) que atua
como analisador sinttico XDML e interpretador de scripts e estilos. J para as aplicaes
procedurais, existe um subsistema chamado PAE (Procedural Declarative Application
Environment) para realizar tal tarefa, como por exemplo, a JVM.
A arquitetura proposta por esta especificao basicamente composta por:

DASE Content Model so as aplicaes DASE;

38

DASE Environment Model representa o sistema DASE.

O sistema DASE constitudo 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 usurio;

udio o sistema deve suportar decodificao e apresentao do udio em tempo

real;

Vdeo o sistema deve suportar decodificao e exibio do vdeo em tempo real;

Grficos o sistema deve suportar decodificao e exibio de imagens estticas,

ou seja, contedo visual que no seja vdeo, de acordo com resolues prestabelecidas;

Modelo de exibio o sistema deve apresentar o seguinte modelo de exibio:

Figura 8: Modelo de exibio DASE

No sistema de segurana do DASE, uma aplicao somente poder executar algumas

operaes privilegiadas se a aplicao fizer a chamada atravs da API do middleware e este,
atravs de uma poltica de segurana local, conceder a permisso.

1.5.2.3 ARIB
ARIB (Association of Radio Industries and Businesses) o middleware desenvolvido
pelo o padro de televiso digital japons ISDB (ISDB, 1998) para que seja efetuada a
comunicao entre sistema operacional, hardware e aplicaes. Neste middleware foi criada
uma linguagem de marcao chamada BML (Broadcast Markup Language), que possui
estrutura semelhante linguagem XML, para fazer o papel das aplicaes declarativas.
No ARIB o modelo de exibio mais elaborado, como na figura a seguir (Paes,
Antoniazzi, 2005):

39

Figura 9: Modelo de exibio ARIB

Em resumo, o sistema ARIB especificado da seguinte maneira (Paes, Antoniazzi,

2005):

Servios de contedo apresentar legendas com superposio sobre o vdeo, como

definido no modelo de exibio; permitir assistir vdeo, udio ou outras
informaes interativas; considera as possibilidades de servios e at mesmo o
pblico que ir adquirir os servios;

Servios de acessibilidade permitir agendamento de gravao atravs do EPG;

acesso dos controles pelo usurio, etc;

Servios de extenses define a possibilidade de expandir as especificaes no

futuro, considerando o estilo dos servios, novas codificaes, sistemas de acesso
e receptores;

Interoperabilidade permitir recepo de dados em qualquer STB que implemente

o middleware, por mais comum que seja; considera a integrao com sistemas de
comunicaes como alta prioridade;

Capacidade de Controle considera a flexibilidade de controle do sistema usando

a eficincia da capacidade de transmisso; considera as funes automticas de
controle de recepo, como funes de emergncia por exemplo;

Erros de apresentao no display sempre que possvel, tratar os erros de

sobreposio de elementos visuais ou at mesmo udio em uma faixa de tempo
suficientemente pequena para que o usurio no perceba.

Por enquanto pouqussimos pases so 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 padro ser menos aceito no mercado pode ser a falta de aplicaes 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 padro brasileiro de
televiso digital, e destinado transmisso terrestre. o resultado do trabalho em conjunto de
diversos centros de pesquisa, destacando-se as universidades Pontifcia Universidade Catlica
do Rio de Janeiro (PUC-Rio) e Universidade Federal da Paraba (UFPB).
Este middleware tambm possui sua forma declarativa e sua forma procedural, assim
como possvel identificar nos outros middlewares apresentados. Na sua forma declarativa,
denominado Ginga-ncl e define uma linguagem declarativa chamada NCL, capaz de
enderear funcionalidades relativamente simples, no que diz respeito interatividade,
sincronismo de objetos de mdia, suporte diferentes tipos de dispositivos, entre outros.
Possui um mecanismo decodificador para esta linguagem NCL, suporte navegao
XHTML, incluindo CSS e um interpretador ECMAScript, alm 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 execuo uma Mquina
Virtual Java (JVM) e aplicaes sobre este middleware tem acesso todos os recursos do
STB, alm de possuir suporte comunicaes do tipo Bluetooth, Wi-fi, Ethernet, entre outras
formas. Prov funcionalidades bsicas como acesso a fluxo de dados de baixo nvel,
processamento do fluxo elementar de dados, componentes de interface, comunicao,
gerenciamento, persistncia e acesso condicional.
Para prover compatibilidade com outros middlewares de outros padres de televiso
digital, o Ginga dividido em um conjunto de trs APIs : A Verde, a Amarela e a Azul. A
API Verde compatvel com GEM (Globally Executable MHP), a API Amarela usada para
satisfazer necessidades especficas para o mercado brasileiro e pode criar aplicaes
compatveis com middlewares como MHP atravs de uma adaptao do software para a API
Verde, desde que essas ferramentas de adaptao sejam enviadas anteriormente ao STB. J a
API Azul produz aplicaes que s so capazes de executar em um ambiente com middleware
Ginga.

41

Captulo 2 MPEG
MPEG (Moving Picture Experts Group) o nome dado a uma famlia de padres ISO
(International Organization for Standardization) que so usados para a codificao de
elementos udio-visuais em um formato digital e comprimido. Tal famlia inclui os padres
MPEG-1, MPEG-2, MPEG-4, MPEG-7 e MPEG-21 que sero vistos sob mais detalhes ao
longo deste captulo. Esta famlia constantemente atualizada para a adaptao s novas
tecnologias que surgem com o tempo e no s os padres j existentes so atualizados, mas
tambm so criados novos padres.

2.1 - Padres
O Moving Picture Coding Experts Group iniciou seus trabalhos em 1988. O padro
MPEG-2 foi iniciado em 1991 e publicado em 1995, sendo uma evoluo do MPEG-1. O
MPEG-2 descrito pelas especificaes ISO/IEC 13818, que definem a forma de compresso
para o fluxo de dados do sistema (ISO, 2000a), para a compresso do vdeo (ISO, 2000b) e
para a compresso do udio (ISO, 1998). A camada de compresso de fluxo de dados MPEG2 Systems segue as recomendaes H.222.0 (ITU, 2000a) e a camada de compresso de vdeo
MPEG-2 Video segues as recomendaes H.262 (ITU, 2000b) no mbito do ITU-T
(International Telecommunication Union - Telecommunication Standardization Sector).
O objetivo do MPEG-2 prover uma taxa de vdeo adequado para os sistemas de
televiso. Assim, a taxa de vdeo varia entre 1,5 Mbps e 30 Mbps, sendo at 15Mbps
adequados para o padro SDTV e acima de 15 indicado para o padro de HDTV.
O padro MPEG-4 foi finalizado em 1998 e se tornou padro internacional em 2000.
O surgimento desse novo padro tornou-se necessrio como forma de permitir a transmisso
pela internet de vdeos 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 criao do ISMA (Internet Streaming Media
Alliance), que define os padres dos players que devero rodar o MPEG-4. Devido
capacidade do MPEG-4 de manter a qualidade do vdeo, mesmo a baixas taxas de
transmisso, o padro tambm usado em algumas transmissoras de televiso via satlite.

42
O padro MPEG-4 faz uso de um padro de compresso denominado H.264, que
possibilita a apresentao da mesma qualidade do vdeo MPEG-2, porm usando apenas um
tero de taxa de dados.
O padro MPEG-7, formalmente conhecido como Multimedia Content Description
Interface ou Interface para Descrio de Contedo Multimdia, disponibiliza ferramentas para
a descrio de contedo multimdia atravs de anotaes em XML. Dessa forma possvel,
por exemplo, fazer com que a letra de uma msica seja sincronizada com a prpria msica.
Assim como o MPEG-7, o MPEG-21 utiliza as anotaes em XML embutidas dentro do
vdeo de forma bem semelhante. O MPEG-21, entretanto possui uma segurana maior, alm
de outras funcionalidades, como proteger os direitos autorais dos vdeos e monitoria dos
estados de transmisso.

2.3 - MPEG-1
Aprovado inicialmente em 1991, o padro MPEG-1 define a codificao de elementos
audiovisuais para mdias de armazenamento com capacidade de transferncia de at 1,5Mbit/s
de dados. MPEG-1 foi o primeiro resultado dos esforos do grupo MPEG.
Este padro foi definido em 5 partes. So elas (MPEG1, 1996) :

Sistemas: caracteriza a combinao de uma ou mais streams de dados das partes de

udio e vdeo definidas neste padro juntamente com uma sincronizao temporal,
tendo como resultado uma nica stream. Desta maneira, facilita-se o
armazenamento e transmisso dos dados digitais;

Vdeo: originou-se do padro H.261 (definido na International Telecommucation

Union- ITU) e representa a codificao de vdeos de 625 e 525 linhas (similares
aos padres de televiso analgica) em taxas de at 1,5Mbit/s. Nesta parte so
definidas algumas tcnicas para se atingir um elevado nvel de compresso do
vdeo, como selecionar uma resoluo apropriada para o sinal, utilizar algoritmos
de compensao de movimento para reduzir a redundncia temporal e por ltimo a
aplicao da Transformada Discreta de Cosseno para compactar ainda mais os
quadros de interpolao e predio;

udio: especifica uma compresso de seqncia de udio mono ou estreo.

Amostras de udio so transferidas um codificador, que caracteriza realiza
processos de filtragem e reamostragem do udio de entrada, e com a ajuda da
codificao de Huffman cria smbolos de amostragem, compactando o udio sem
que rudos sejam adicionados. dividido em trs camadas, onde as duas primeiras

43
especificam udio de qualidade elevada, porm com alta complexidade no
momento da compresso, enquanto a terceira tambm consegue atingir alta
qualidade de maneira mais simplificada, sendo esta, mais usada em aplicaes
digitais;

Testes de conformidade: define testes de conformidade de streams com as partes

definidas acima;

Software: uma implementao das trs primeiras partes com cdigo fonte fechado.

Tecnologias como Vdeo CDs (VCDs) e MPEG-1 Layer III (mais conhecido como
MP3) so os pontos fortes deste padro. Este ltimo vem sendo usado para comprimir udio e
a nica parte deste padro que ainda encontrada com alta freqncia 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
imperceptvel.

2.4 - MPEG-2
Um arquivo no formato MPEG-2 divide-se em duas camadas. A camada de
compresso e a camada de sistema. A camada de sistema a responsvel pela multiplexao
do vdeo, ideal para a transmisso. A camada de compresso cuida da codificao e
compresso dos dados de udio e vdeo.

2.4.1 - Camada de compresso

Os vdeos nada mais so do que um conjunto de imagens exibidas seqencialmente.
Cada frame de um vdeo pode ser representado por trs matrizes, sendo uma de luminncia e
duas matrizes de crominncia. A luminncia a componente do vdeo que contm somente as
informaes de brilho o preto e branco. A crominncia contm as informaes sobre as
cores da imagem. As informaes de um quadro podem ser separadas nas linhas pares ou
mpares que o compem, em campos denominados top field e bottom field.
Uma figura codificada atravs de MPEG-2 pode representar um nico quadro ou um
campo codificado. Se um sinal de vdeo contm figuras que representem campos, ele
chamado de vdeo entrelaado. Se o sinal de vdeo contiver figuras que representem apenas
quadros, ele chamado de vdeo progressivo.
A principal diferena entre o vdeo entrelaado e o vdeo progressivo que, no vdeo
entrelaado, a cada novo frame de vdeo, apenas metade dos pixels so atualizados,

44
redesenhando apenas as linhas pares ou as mpares o top field ou o bottom field. J no vdeo
progressivo, todas as linhas so atualizadas.
O olho humano mais sensvel a mudanas no brilho do que na cromaticidade. Por
isso a diviso do frame em uma matriz de luminncia e duas de cromncia feita. As matrizes
de cromncia acabam ento, sofrendo uma compresso maior do que a matriz de luminncia.
O habitual mtodo de compresso usado o Discrete Cosine Transform (DCT), ou
transformada discreta de Cosseno. A tcnica reduz as componentes de alta-freqncia da
imagem, uma vez que o olho humano mais sensvel a reconstrues de componentes de
baixa-freqncia.
As imagens podem ser codificadas em trs tipos diferentes de frames. Os Intra-Coded
Frames (I-frames) so codificados usando apenas informaes contidas no prprio frame
original, no havendo dependncia com frames anteriores ou posteriores. Como cada frame
pode ser considerado como uma imagem, a compresso de um I-frame semelhante
realizada em uma imagem de padro JPEG, por exemplo. Os Predictive-Coded Frames (Pframes) so codificados de forma preditiva em relao 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
dependncia com algum macrobloco de outra figura. J os Bidirectionally-Predictive-Coded
Frames (B-frames) so codificados de forma preditiva em relao aos quadros I-frame ou Pframe anteriores ou posteriores. Dessa forma, pelo menos um macro bloco de um quadro Bframe possui dependncia com algum quadro posterior a ele. Logo, para uma codificao Bframe, necessrio que o quadro posterior ao qual ele possui essa dependncia j tenha sido
codificado (Cavendish, 2005).
Cada frame codificado possui o parmetro temporal_reference, que funciona como um
contador, utilizado para que o decodificador consiga detectar eventuais perdas de frames.
Os algoritmos que realizam a compresso MPEG buscam reduzir a redundncia
temporal que existe entre os frames consecutivos. Eles tentam, por exemplo, eliminar
elementos que so iguais em dois frames seqenciais. O mtodo consiste em calcular o erro
de predio entre os blocos nas imagens atuais e nas imagens anteriores.
Outro tipo de compresso possvel usando a predio por compensao de
movimento. feita uma estimativa de movimento entre as imagens do vdeo e a codificao
gera uma translao de pixels entre as imagens. Esse mtodo feito realizando a comparao
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 referncia na operao de predio. Um vetor de movimento indicando a diferena de

45
localizao do macrobloco entre os dois frames criado e transmitido junto com o
macrobloco codificado. Tambm transmitida junto com o macrobloco, a posio em relao
ao macrobloco anterior, a indicao do mtodo de predio e quais blocos de cromncia e
luminncia foram codificados.
Para facilitar a decodificao, a ordenao dos frames no fluxo diferente da ordem
que os frames devem ser exibidos. Essa ordem garante que as figuras usadas como referncia
pelos outros quadros sejam sempre recebidas antes dos quadros que as utilizam. Para a
exibio de um frame que usa codificao P-frame em referncia a outro frame I-frame,
necessrio que o decodificador j tenha recebido o I-frame antes de decodificar o P-frame
(Cavendish, 2005).

Figura 10: Exemplo de ordem de apresentao em relao ordem de codificao

A Figura 10 ilustra como deve ser a ordem. Como os frames 2 e 3 utilizam codificao
B-frame, que necessita dos frames posteriores para serem usados como referncia (no caso, o
frame 4), o decodificador recebe primeiramente o frame 4 e depois os frames 2 e 3, que
possuem referncia a ele.

46

2.4.2 - Camada de Sistemas

Definida no MPEG-2 Systems - recomendaes H.222.0 (ITU, 2000a) a camada de
sistemas responsvel pela diviso e encapsulamento dos fluxos gerados na compresso em
pacotes e pela multiplexao desses pacotes. Alm disso, mantm a sincronizao entre os
fluxos de mdias diferentes e pelo transporte da informao de referncia do relgio utilizado
no codificador.
Existem duas formas de multiplexao. O fluxo de programa (Program Stream)
otimiza a decodificao para ambientes com menor ocorrncia de erros e contm s um
conjunto de fluxos elementares (como udio, vdeo 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 ocorrncia de erros mais freqente, como nas transmisses de televiso digital, muito
suscetveis a rudos.
Aps a compresso, os fluxos elementares de vdeo so divididos em pacotes em uma
subcamada chamada PES (Packetized Elementary Stream). Essa camada realiza a
identificao dos pacotes atravs de um parmetro Stream_ID. A camada PES ainda realiza
uma sincronizao intra e intermdia, atravs da colocao de marcadores de tempo
(timestamps) nos fluxos de PES e nos fluxos de sistemas. As timestamps inseridas no fluxo de
sistemas na subcamada de multiplexao permitem ao decodificador a recuperao da
referncia de tempo em relao ao relgio usado no codificador. Esses timestamps so
denominados System Clock Reference (SCR) para os fluxos de transporte e Program Clock
Reference (PCR) para os fluxos de programa e so definidos em termos de um relgio 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).
Aps o empacotamento desses dados nas PES, alguns pacotes so 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 apresentao deve ser exibida, e
o Decoding Time Stamp (DTS), que indica o tempo em que a unidade de apresentao deve
ser entregue ao respectivo decodificador. O DTS usado quando necessria uma
reordenao dos quadros pelo decodificador.

47
2.5 - MPEG-4
O MPEG-4 utiliza o padro 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 vdeo to boa quanto a apresentada pelo MPEG-2,
mas gerando arquivos com apenas metade do tamanho. A implementao, entretanto, no
poderia ser muito complexa para no tornar o processo de codificao extremamente caro.
Para atingir seu objetivo, o MPEG-4 possui algumas diferenas em relao
compresso. Ele permite, por exemplo, o uso de at 32 frames de referncia, contra apenas 1
ou 2 frames nos mtodos anteriores. Isso permite a gerao de arquivos muito menores e
melhorias at na qualidade de imagem.
A tcnica de predio por compensao de movimento tambm evoluiu bastante,
permitindo blocos com tamanho 4x4 e 16x16 e preciso de movimento dos blocos de at de
pixel. A performance tambm amplamente melhorada nos efeitos de fade in e fade out.
Alm disso, usa sistemas chamados de flexible macroblock reordering (ordenao dos
macroblocos flexvel) e arbitrary slice ordering (ordenao arbitrria de fatias) para
reestruturar a maneira como os macroblocos so apresentados na imagem.
O H.264 ainda utiliza de duas tcnicas de codificao denominadas Codificao
aritmtica binria adaptvel segundo o contexto (context-adaptive binary arithmetic coding,
CABAC) e Codificao de comprimento varivel adaptvel segundo o contexto (contextadaptive variable-length coding, CAVLC), que usam algoritmos inteligentes para comprimir
streams de vdeo com perdas quase mnimas.
H diversos novos meios de se evitar erros na codificao e decodificao tambm.
Entre eles, pode-se destacar a partio de dados, que permite separar pedaos mais
importantes e menos importantes da imagem em pacotes separados, permitindo que se faa
um controle maior de erros naqueles pedaos mais importantes. Usa tambm redundant slices,
(fatias redundantes) que permite que um codificador crie uma imagem extra geralmente de
menor qualidade - de uma regio de um frame, para ser usada se a representao preliminar
original do frame estiver corrompida.
Essas tcnicas permitem que o MPEG-4 tenha um desempenho muito superior ao
MPEG-2, apresentando uma qualidade de vdeo semelhante e, por vezes, at superior com
arquivos que tm metade ou menos da metade do tamanho.

2.6 - MPEG-7

48
Seguindo os mesmos princpios do MPEG-4, o grupo MPEG iniciou um projeto de
outro padro, o MPEG-7. Seu intuito era de estabelecer descries (ou anotaes) para
contedos multimdia de forma a possibilitar que buscas, filtragens e outros processamentos
similares fossem realizados de forma mais rpida e eficiente. Tais anotaes tambm so
chamadas de metadados.
Este padro prov diversas ferramentas para auxiliar na descrio e gerenciamento do
contedo, organizao e navegao. A descrio do contedo pode ser transmitida ou
acessada por um dispositivo ou programa de computador, e pode ter diferentes interpretaes
dependendo do contexto da informao.
O MPEG-7 no est focado em apenas uma aplicao em particular, ao invs disso, os
elementos contidos no MPEG-7 do suporte uma larga escala de aplicaes possveis, pois
so bastante genricas (MPEG7, 2004). A necessidade de uma ferramenta de descrio em
contedos multimdia est diretamente relacionada com a necessidade que as novas
tecnologias tem com relao eficincia e rapidez.
Um grande conjunto de ferramentas de descrio so definidas, e ainda uma
linguagem prpria, com sintaxe semelhante linguagem de marcao XML, que possibilita
aos desenvolvedores expandir a funcionalidade do padro. H tambm uma srie de outras
ferramentas de sistema relativas distribuio final das anotaes MPEG-7, que realizam a
preparao dos dados para a transmisso (Martinez et al, 2002).
As ferramentas de descrio so representadas por elementos com metadados,
estruturas e relacionamentos, definidos como descritores e esquemas de descrio. A
descrio de um contedo multimdia feita atravs de descritores que possibilitam a
indexao e classificao das informaes. O padro MPEG-7 fornece ferramentas para
descrio de regies estticas, regies temporais e at mesmo regies dinmicas, que se
movem, no caso de vdeos.
A especificao deste padro, assim como nos outros padres MPEG, tambm est
definida em partes, cujas principais so: sistema, Description Definition Language (DDL),
vdeo, udio e Multimedia Description Schemes (MDS). Antes de explicar cada uma delas
preciso conhecer cada uma das definies a seguir, retiradas de (Martinez, 2002) de acordo
com definies presentes na especificao do padro:

Descriptor (descritor) representa uma caracterstica. Um descritor define a

sintaxe e a semntica de uma representao de uma caracterstica;

Description Scheme (esquema de descrio) define a estrutura e o significado da

relao entre componentes que podem ser descritores ou outro esquema descrio;

49

Description Definition Language (DDL, linguagem prpria para definio de

descries) uma linguagem para definio ou alterao de descritores e
esquemas de descrio, provendo a possibilidade de expanso do padro de acordo
com as necessidades do desenvolvedor;

System Tools (ferramentas de sistema) Ferramentas de apoio multiplexao,

sincronizao, transmisso e codificao (forma de texto e binria) das descries
de maneira eficiente e proteo propriedade intelectual.

A especificao define tambm uma implementao do software de referncia da

especificao do padro. Tal software baseado em uma normalizao com respeito ao
processo de decodificao, isto , qualquer software produzido para trabalhar com este padro
deve apresentar os mesmos resultados que o software de referncia. Alm disso, a
especificao define testes de conformidade e padres para o uso e extrao de descries. Os
testes de conformidade, presentes em todos os padres MPEG, especificam os mtodos para
testes das descries MPEG-7 para verificar se esto de acordo com o padro, e os padres
para uso e extrao de descries fornecem informaes para extrao de descries das
streams MPEG e para o uso das ferramentas de descrio, utilizando o software de referncia
mas tambm com outras abordagens (MPEG7, 2004).

2.6.1 - Sistemas MPEG-7

Esta parte especifica ferramentas de sistema para a preparao de descries MPEG-7
para o transporte e armazenamento, viabilizando a sincronizao com o contedo multimdia
de forma eficiente, alm de atualizaes e construo de descries dinmicas. Sistemas
MPEG-7 dispe de todas as caractersticas necessrias para a representao de contedos
multimdia com descries multiplexadas.
A entidade capaz de tratar tais informaes so comumente chamadas de terminais (ou
MPEG-7 terminal) e podem ser representadas por aplicaes independentes ou partes de um
outro sistema. A arquitetura desses terminais dividida em trs camadas: aplicao,
normalizao (que responsvel pela sincronizao e gerenciamento das descries) e
distribuio (que responsvel pela abstrao do meio transmisso e armazenamento
proporcionado por este padro), conforme definido na especificao ISO do padro (MPEG7,
2004). A distribuio herda caractersticas de outros padres como o MPEG-4 e o MPEG-2
como o conceito de elementary streams. Essas streams consistem em pequenas partes
consecutivas de dados, que so individualmente acessados, chamados de access units
(unidades de acesso) e dentro dessas unidades esto as descries e definies de esquemas

50
referentes ao padro. H tambm uma camada no sistema responsvel por reagrupar essas
pequenas unidades para reconstituir os dados de descries (Martinez, 2002).
Outra caracterstica importante do sistema a utilizao do formato BiM (Binary
Formato for MPEG-7) para a representao binria das descries MPEG-7, que
originalmente so feitas em XML, que por sua vez no foi feita para trabalhar com sistemas
de tempo-real, por exemplo, contedo multimdia. O formato BiM possibilita a compresso e
distribuio streaming de documentos XML.

2.6.2 - MPEG-7 Description Definition Language

As principais ferramentas usadas na implementao das anotaes MPEG-7 so:
Description Definition Language (DDL), Description Schemes (DSs) e Descriptors (Ds).
DDL constitui a parte principal do padro MPEG-7, pois fornece elementos descritivos onde
os usurios podem criar seus prprios esquemas de descrio e descritores para expandir a
usabilidade do padro de acordo com suas necessidades. Representa a modelagem do
contedo multimdia em forma de linguagem de texto.
Com a DDL possvel representar relaes conceituais, espaciais, temporais e
estruturas de elementos, pois sua modelagem bastante completa em termos de referncias e
relaes entre esquemas de descrio e descritores.
Em resumo, DDL define as regras gramaticais de uma linguagem derivada do XML
(eXtensible Markup Language), com sua prpria sintaxe e semntica para expressar e
combinar esquemas de descrio e descritores (MPEG7, 2004). Tambm importante lembrar
que possvel alterar definies j existentes de esquemas de descrio e descritores.
Esta uma linguagem legvel tanto para seres humanos quanto para mquinas, porm
as mquinas necessitaro de um analisador sinttico, capaz de validar o contedo e a estrutura
de um documento DDL, bem como os tipos de dados definidos na especificao da
linguagem. Tambm devero ser capazes de validar descries MPEG-7 de acordo com seus
respectivos esquemas de descrio (MPEG7, 2004).
O uso de esquemas XML proporciona linguagem DDL a facilidade de
interoperabilidade necessria para a extenso dos descritores e esquemas de descrio.
Tambm possvel que outras aplicaes baseadas em XML utilizem o MPEG-7 para
estender suas funcionalidades com descrio de contedos multimdia.
Abaixo segue um exemplo de uso da linguagem DDL para anotao 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>
Cdigo DDL da descrio do logo MPEG a seguir

Figura 11: Logo MPEG descrito pela anotao MPEG-7

2.6.3 - MPEG-7 Visual

Especifica ferramentas de descrio de elementos visuais, como vdeo e imagens
estticas. Ferramentas de descrio visuais consistem em estruturas bsicas e descritores
visuais, que so baseados em caractersticas semelhantes que possibilitam a identificao de
similaridades em vdeos e imagens. Tambm so usados para filtragens e buscas baseadas em
diversas caractersticas como cor, textura, formas, movimento e localizao. Cada uma destas
categorias tem desde descritores bsicos at os mais avanados e especficos. Esses
descritores so classificados em genricos e especficos de aplicao. Os especficos de
aplicao podem, por exemplo, ser utilizados em aplicaes com processamento de imagem,

52
como localizao de veculos e reconhecimento de faces (Martinez, 2002). J os genricos so
classificados em (MPEG7, 2004):

Bsicos interpolao, coordenadas 2D, vises 2D e 3D, temporal, etc;

Cor cor dominante, estrutura de cor, espao de cor, etc;

Textura textura homognea ou heterognea, navegao por textura;

Forma baseados em regio, contorno ou formas 3D;

Movimento movimento de cmera, trajetrias, etc;

Localizao localizao regional e especial-temporal;

Figura 12: Exemplo de aplicao de descrio em uma cena de vdeo, retirado de (MARTINEZ; KOENEN; PEREIRA, 2002)

53
2.6.4 - MPEG-7 udio
Especifica ferramentas de descrio de elementos de udio, como msica e fala.
Descritores desse tipo so considerados de baixo nvel quando se referem caractersticas
paramtricas, temporais, e de espectros dos sinais de udio (tambm conhecido como MPEG7 Audio Framework) e de alto nvel quando so mais especficos para uma determinada
aplicao, usados em situaes como anotar o timbre ou melodia de um instrumento,
contedo falado ou at mesmo reconhecimento de som (MPEG7, 2004). Os descritores de
udio de alto nvel so classificados em (Martinez, 2002) :

Combinao de udio (descreve a semelhana espectral dos sons);

Combinao de Timbre (identificao, busca e filtragem);

Busca por melodia (descritores de melodia simples e completos);

Reconhecimento de som e indexao;

Fala

2.6.5 - MPEG-7 Multimedia Description Schemes

Especifica os descritores e esquemas de descrio para caractersticas genricas e
descries multimdia, incluindo esquemas de descrio de udio, vdeo, e de outros tipos
(Martinez, 2002). So basicamente, modelos de objetos multimdia e do universo que
representam. Especificam tipos de descritores que podem ser usados em uma determinada
descrio, e as relaes entre esses descritores ou entre outros esquemas de descrio.
Para criar descries MPEG-7 de qualquer contedo multimdia, a primeira etapa
criar um wrapper (esquema ao qual ser atribuda a descrio) para a descrio utilizando as
ferramentas de esquema. As diferentes ferramentas utilizadas para criao de descries usam
elementos bsicos genricos, que representam o alicerce do MPEG-7 para extenso da
linguagem fornecida.

2.6.6 - MPEG-7 Description Tools

MPEG-7 Description Tools define um conjunto padronizado de descritores e
esquemas de descrio, baseado em suas funcionalidades, porm nada impede de mesclar
vrios descritores e esquema de descrio de funcionalidades diferentes em um processo de
anotao, desde que faa algum sentido lgico, atravs da ferramenta Schema Tools (ou
ferramentas de esquema). So basicamente agrupados em (Martinez, 2002):

Elementos Bsicos entidades genricas utilizadas por outras ferramentas de

descrio;

54

Ferramentas de esquema disponibiliza as ferramentas de descrio para as

aplicaes;

Ferramentas de descrio de contedo representa informao perceptvel, como

aspectos estruturais, conceituais, audiovisuais, etc;

Ferramentas de gerenciamento de contedo especifica caractersticas da mdia,

criao e uso da mesma;

Ferramentas de organizao de contedo permite criar e modelar conjuntos de

contedo multimdia e descries;

Ferramentas de acesso e navegabilidade especifica particionamento e

decomposio de contedo multimdia para facilitar a navegao;

Ferramentas de interao com o usurio descreve preferncias do usurio e

mantm um histrico de uso do contedo multimdia.

Figura 13: Organizao das ferramentas de acordo com a funcionalidade

2.7 - MPEG-21
O formato MPEG havia alcanado seus objetivos de compresso de formatos de mdia
com boa qualidade e utilizando pouco espao. Entretanto, a mdia somente no basta para
divulgar algumas informaes. O MPEG-21 surge com o objetivo de transportar mais do que
vdeo em um arquivo de mdia. Isso permite um uso mais especfico do contedo de mdia,
baseado, por exemplo, nas preferncias do usurio ou nas capacidades do dispositivo. Com

55
isso possvel fazer um controle sobre quem acessa a mdia, permitindo um maior controle
sobre os direitos autorais de um item digital.
H muitas semelhanas entre o MPEG-7 e o MPEG-21, principalmente no que diz
respeito s ferramentas de descrio que os dois sistemas adotam. O MPEG-21 focado em
estabelecer a relao entre um item digital e aquele que o usa. Entende-se por item digital a
combinao de recursos como vdeo, imagens, textos, metadados (que podem ser usados para
identificao do contedo) e a estrutura que descreve a relao entre esses recursos. Um
usurio qualquer um que possa interagir com aquele contedo, incluindo o criador, o
distribuidor, o detentor dos direitos autorais e o consumidor final.
Entretanto, por ser um formato ainda em desenvolvimento, vrias partes do padro
ainda no esto completamente definidas. Dentre as partes que j possuem especificao
definida, podemos citar:

Multimedia Framework: Define os elementos para a incluso correta dos recursos

de multimdia, assim como a integrao, criao, manipulao, controle, e
distribuio desses itens digitais;

Digital Item Declaration: Define uma srie de termos e conceitos que sero 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 proteo 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 permisses para arquivos
udio-visuais, permitindo maior controle no uso desses arquivos e em sua
distribuio, publicao e consumo;

Rights Data Dictionary: Define uma srie de termos bem estruturados e integrados
que visam atender todas as necessidades do Rights Expression Language;

Digital Item Adaptation: Prov mecanismos de descrio de informaes

relacionadas a um ambiente e a um formato que podem ser utilizadas em um
mecanismo de adaptao, 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
compatvel com os demais formatos MPEG.

56

Como possvel verificar, o formato MPEG-21 est se direcionando para o uso e

manipulao de itens digitais. Para definir um item digital que ser usado no padro MPEG21, necessrio seguir algumas normas. A Digital Item Declaration (DID - Declarao de
item digital) - ISO/IEC 21000-2 - define a estrutura e organizao 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 representao de complexos itens digitais.
A DIDL composta de alguns elementos, podendo citar:

Continer: Permite o agrupamento de itens ou outros contineres. Os contineres

podem formar pacotes lgicos teis no transporte de dados ou na organizao
dos elementos de um item digital;

Item: o agrupamento de componentes ou subconjuntos que so ligados a

descritores relevantes. Podem conter diversas opes de configurao para que um
item possa ser personalizado. Um item pode ou no conter subitens. Se um item
contm um subitem, ele chamado de compilao. Se ele no contm, ele
chamado de entidade. Um item , na verdade, uma representao declarativa de
um item digital;

Componente: Associa um recurso a todos os seus descritores relevantes. Esses

descritores contm informaes relacionadas uma instncia do recurso ou parte
dela. Os descritores comumente contm informaes estruturais sobre o recurso
tais como tamanho, informaes de decriptao, pontos de incio etc mas no
informaes descritivas sobre o recurso;

ncora: Faz a ligao entre descritores e fragmentos, correspondendo

localizao especfica de um recurso ou de parte dele;

Descritor: Associa informaes com um elemento. Essa informao pode ser

baseada em texto ou pode ser outro componente como uma imagem;

Condio: Descreve o elemento como sendo opcional e faz um link dele com as
condies que afetam a sua incluso. Mltiplos predicados inseridos em uma
mesma condio geram uma conjuno (relao AND). Mltiplas condies
associadas geram uma disjuno (relao OR);

Escolha: Designa uma srie de selees que podem afetar a configurao de um

item;

57

Seleo: Descreve uma deciso que afeta uma ou mais condies em um item.
Pode retornar um predicado sendo verdadeiro, falso ou indefinido;

Anotao: Uma anotao descreve informaes sobre outro elemento do modelo

sem alterar ou adicionar qualquer coisa ao elemento. As anotaes podem ter o
formato de afirmaes, descries e ncoras;

Afirmao: Descreve a configurao de estado de uma escolha completa ou

parcial, definindo valores para alguns predicados associados com alguma seleo
para uma escolha como sendo verdadeiros, falsos ou indefinidos;

Recurso: Qualquer objeto vdeo, udio, texto, imagem individualmente

identificvel. Pode ser tambm potencialmente um objeto fsico. Os recursos
devem ser localizados por endereos que no sejam ambguos;

Fragmento: Designa um ponto especfico ou um intervalo de um recurso;

Indicao: um valor textual literal que contm uma informao mas no um

recurso. Exemplos de indicaes podem ser: uma descrio ou uma informao de
identificao;

Predicado: uma declarao 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 Identificao de
Item Digital, cuja funo inclui identificar os itens digitais e suas partes, o endereo de IP
relacionado aos itens digitais e os esquemas de descrio. Alm disso o Digital Item
Identification especifica como usar os identificadores para relacionar os itens digitais com as
informaes contidas em suas respectivas descries em metadados. Digital Item
Identification tambm indica como devem ser identificados os diferentes tipos de Itens
digitais.
Outra preocupao com os direitos autorais dos arquivos de mdia. 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 permisses usando os termos definidos em um Right Data Dictionary (RDD). O RDD forma
a base de todas as expresses definidas no REL. O RDD e o REL provem mecanismos para
controlar o uso dos recursos digitais na publicao, distribuio e uso desses recursos udio,
filme, livros, jogos, softwares e qualquer outra criao em formato digital com o objetivo de
proteger o contedo e os direitos autorais especificados.
Por ser um formato muito recente, muito ainda vm sendo discutido em relao a
novas funcionalidades que o MPEG-21 pode vir a apresentar. Um exemplo o Digital Item
Adaptation, que especifica um conjunto de ferramentas de descrio para auxiliar a adaptao
de itens digitais.

59

Captulo 3 Desenvolvimento da Aplicao

A proposta do trabalho oferecer um mtodo diferenciado para a apresentao de
produtos de uma loja virtual para televiso digital. Partindo da idia de que os produtos sero
mostrados ao decorrer da programao, e de que o fluxo de dados MPEG ser constante
durante a exibio da programao do canal, os produtos seriam extrados do prprio vdeo,
baseado nos padres MPEG-7 e MPEG-21. Para que tal operao seja possvel, necessrio
que o lado do provedor de servios tenha a capacidade de codificao do vdeo com os
padres apresentados e o lado do usurio (STB) tenha a capacidade de decodificao.

3.1 O Emulador
O emulador utilizado, o XleTView, disponvel em http://xletview.sourceforge.net,
encontra-se em fase bastante inicial. Sua verso atual mais estvel que pode ser encontrada no
site oficial do emulador a 0.3.6, que apresenta uma implementao parcial, que deixa de
lados diversos elementos necessrios para o desenvolvimento total da aplicao de loja virtual
sugerida. Um exemplo dessa ausncia de funcionalidade a falta da simulao de um fluxo de
dados MPEG, como aconteceria em um STB, sendo assim, impossvel obter um vdeo em
tempo real, ou seja, para que o emulador rode vdeos necessrio que o vdeo esteja presente
por inteiro no disco local. Tambm no esto presentes decodificadores para os padres
MPEG-7 e MPEG-21, portanto no seria possvel extrair do vdeo, metadados MPEG-7 e
MPEG-21 ou mesmo fazer uso de ferramentas MPEG-21 para controle multimdia, de acesso,
entre outros.
O XleTView permite a visualizao de xlets Java sobre o middleware MHP no
computador e distribudo e desenvolvido pela GNU General Public License (GPL).
Desta forma impossvel desenvolver a aplicao 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 aplicao.
Devido a esta restrio outros emuladores que possuem implementao de algum padro de
televiso digital foram pesquisados, como o Cardinal Studio da Cardinal Systems e o
AltiComposer da Alticast, mas como todos estes so solues comerciais e disponibilizam
apenas verses de demonstrao que duram por 30 dias, tambm no foi possvel a sua
utilizao para desenvolvimento do sistema. Ainda assim, o que aparentou ser o mais
completo foi o AltiComposer e segundo sua descrio no site oficial, no implementa

60
decodificao de MPEG-7 nem MPEG-21. A implementao destes padres est diretamente
associada ao suporte de padres MPEG do padro de televiso digital, no caso, o MHP.
Segundo o site oficial do projeto XleTView, na verso 0.3.6, de 2004, das 373 classes
e interfaces listadas referentes s implementaes das APIs DAVIC, HAVi, DVB-MHP e
JavaTV, apenas 245 esto completamente implementadas, 1 tem um bug conhecido, 15 esto
sob implementao e 112 ainda no foram implementadas. Enquanto a verso mais atual,
listada como no-estvel, a verso 0.3.7 de 2005, apresenta 247 classes completamente
implementadas, 1 com bug conhecido, 16 sob implementao e 109 ainda no implementadas.
Desde esta ltima verso, nenhuma atualizao foi feita, o que sugere que o projeto foi
descontinuado.
A verso escolhida para o desenvolvimento da aplicao foi a XleTView 0.3.7, que,
mesmo sendo a ltima, j est defasada e no suporta diversas funcionalidades que estavam
nos planos da implementao inicial. Esta verso foi levemente modificada para facilitar a
depurao da aplicao.

3.1.1 Suporte vdeos

O suporte multimdia na verso do emulador XleTView utlizada, limitado aos
formatos de udio e vdeo suportados pela API JMF verso 2.1.1. A API JMF Java Media
Framework permite a decodificao de contedo multimdia dentro de uma aplicao Java.
A converso necessria porque o nmero de formatos que a API JMF consegue suportar
baixssimo, e sendo assim, alguns formatos de vdeo mais populares foram deixados de lado,
como MPEG-2, MPEG-4, Windows Media, Real Media, entre outros, at porque alguns so
formatos proprietrios, 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 aplicao, ele estar marcado com write. A linha da tabela marcada em cinza escuro
representa o o tipo de vdeo utilizado na compresso.

61
Tabela 2: Suporte a formatos multimdia da API JMF

Formato
AVI (.avi)
Audio: 8-bit mono/stereo linear
Audio: 16-bit mono/stereo linear
Audio: DVI ADPCM compressed
Audio: G.711 (U-law)
Audio: A-law
Audio: GSM mono
Audio: ACM**
Video: Cinepak
Video: MJPEG (422)
Video: RGB
Video: YUV
Video: VCM**
MPEG-1 Video (.mpg)
Multiplexed System stream
Video-only stream
MPEG Layer II Audio (.mp2)
MPEG layer 1, 2 audio

JMF 2.1.1
Verso
independente de
plataforma
Leitura/escrita
D,E
D,E
D,E
D,E
D
D,E
D
D
D,E
D,E
Apenas leitura
D

JMF 2.1.1
Verso Windows
Leitura/escrita
D,E
D,E
D,E
D,E
D
D,E
D,E
D
D,E
D,E
D,E
D,E
Apenas leitura
D
D
Leitura/escrita
D,E

O formato utilizado nesta aplicao foi o Cinepak, convertido com o software RAD
Video Tools disponvel para download em http://www.radgametools.com/bnkmain.htm. A
princpio, a inteno era de utilizar o formato MPEG-2, por ser mais prximo da realidade
quanto aos padres de televiso digital, porm, com a verso da JMF utilizada pelo emulador
(que pouco difere da verso mais recente no quesito compatibilidade de formatos) no
possvel a decodificao do formato. O formato Cinepak tem baixa taxa de compresso se
comparado ao MPEG-2, e a perda de qualidade tambm maior: um vdeo de 1 minuto e 53
segundos compactado com o codec Windows Media Video (extenso .wmv) ocupava 2.53MB
de espao em disco, quando convertido para MPEG-2, passou a ocupar aproximadamente
23MB sem perda de qualidade perceptvel, e quando convertido utilizando-se o Cinepak,
ficou com 77MB e houve uma perceptvel reduo de qualidade.

3.1.2 Modificaes no Emulador

Algumas modificaes foram feitas na verso 0.3.7 do emulador XletTView. Isso
ocorreu porque esta verso, que estava disponvel no repositrio de cdigos do projeto, no
era considerada verso estvel e para distribuio, portanto continha um mecanismo de
depurao que gerava um histrico de todas as aes do emulador no prprio console onde era

62
executado, e este mecanismo no estava acompanhado de cdigo-fonte, apenas de cdigos
intermedirios Java.
Para contornar este problema, foi criada uma janela para o armazenamento de
mensagens das xlets, apenas para guardar a sada da aplicao, separando-a da sada do
emulador. Este mecanismo foi o mais prximo de uma depurao que foi possvel chegar
neste trabalho, se tratando de uma xlet, cujos arquivos binrios so carregados em tempo de
execuo e no so percebidos pela ferramenta de desenvolvimento utilizada. A figura a
seguir mostra o funcionamento da janela durante a execuo da xlet da loja virtual.

Figura 15: Imagem da janela de log

3.2 A aplicao
Para explicar como a aplicao funciona, bem como seu comportamento dentro de um
STB, necessrio entender suas funcionalidades primeiro. J se sabe que a aplicao uma
loja virtual para televiso digital, porm, uma aplicao para tal plataforma difere de uma em
plataformas mais convencionais para este tipo de aplicao, como por exemplo computadores
pessoais ou smart phones. possvel perceber melhor essa diferena analisando variveis
como resoluo da tela do dispositivo utilizado, poder computacional, e at o foco da
plataforma em questo: em uma televiso digital o foco na tela ser, na maior parte das vezes,
o vdeo que estar sendo exibido e no a loja virtual, enquanto em um computador pessoal, o
foco na tela geralmente ser a loja virtual.
No caso da televiso digital a aplicao deve ser mnima, estritamente relacionada com
a sua funcionalidade e sem quaisquer outros recursos que poderiam ser considerados de
importncia secundria. Baseado nisso, a aplicao, do ponto de vista do usurio contm
apenas uma interface que varia de contedo e tamanho de acordo com comandos do usurio.
So considerados comandos, toques nos botes do controle remoto. O usurio que desejar

63
visualizar os produtos da loja, dever primeiramente ativar a exibio de anncios, que poder
ser feita a qualquer momento, atravs de uma possvel aplicao para a configurao do
servio, ou ainda, atravs do boto azul do controle remoto. O usurio saber da interao
com o boto azul e sua relao com a loja virtual atravs de propagandas do prprio servio
durante a programao, ou atravs de um alerta sonoro ou um discreto alerta visual na tela,
notificando-o a respeito de uma possvel interao.Desta forma, quando houver um anncio
da loja disponvel naquele intervalo de tempo, a aplicao exibir sobre o vdeo, uma pequena
interface, alertando-o da existncia de um produto venda, como na figura a seguir.

Figura 16: Imagem da xlet em execuo sobre o vdeo

Nesta interface, ser possvel visualizar uma miniatura da foto do produto, caso esteja
disponvel, bem como seu nome e uma breve descrio, acompanhados com um boto
vermelho e um boto verde, respectivamente simbolizando aes para ver mais detalhes do
produto e partir para a compra imediatamente. Ambas as cores, neste modelo, esto
diretamente ligadas s cores dos botes no controle, para facilitar a interao do usurio com
a aplicao.

64
Tambm possvel visualizar na figura anterior o remoto existente no emulador.
importante lembrar que um controle remoto para televiso digital deve ter mais botes do que
o normal para facilitar a interao com o usurio e o controle de aplicaes na tela. No caso
desta xlet, os botes coloridos serviro para aes dentro da aplicao e acarretaro em uma
transio nas formas da interface do programa enquanto o boto com o texto exit ter a
funo de desligar a exibio de propagandas daquele determinado servio (comumente
chamado de canal na televiso analgica), ou seja, invocar um mtodo de destruio da xlet
responsvel pela loja que ainda reside no STB, para que este d continuidade no ciclo de vida
desta xlet.
Quando o usurio aperta o boto vermelho referente tela de mais informaes, a
mesma interface tem o tamanho aumentado e seu contedo atualizado com uma foto maior do
produto caso esteja disponvel, sua descrio completa, preo de compra pela televiso digital
e opo de compra. Tanto a foto verso miniatura quanto a foto grande do produto podem ou
no aparecer no s devido a ela existir ou no para determinado produto, mas tambm por
possveis erros nas decodificaes dos padres MPEG-7 e MPEG-21 envolvidos.

Figura 17: Interfaces de exibio de detalhes e confirmao de compra

Se o usurio deseja comprar o produto, basta apertar o boto verde, a qualquer

momento da exibio do anncio, que ele ser remetido interface de compra, com um
simples formulrio, semelhante formulrios encontrados freqentemente na web, onde ele
dever usar um cdigo nico por assinante previamente cadastrado com a fornecedora do
sinal de televiso digital. Para este campo do formulrio, apesar de o cdigo ser confidencial
do usurio, alguns fatores foram levados em considerao para que o campo no funcionasse

65
de modo anlogo ao campo de senha em um formulrio web: o fato de que apertar os botes
numricos do controle de televiso digital, inutiliza funcionalidades de troca de canal durante
o tempo em que o campo detm o foco na tela e ter que digitar duas vezes aumentaria ainda
mais esse tempo, e tambm que este campo s ter validade no local onde se encontra o
respectivo STB, ou seja, o usurio s poder utilizar seu cdigo no local onde est cadastrada
a sua assinatura. Para esta aplicao, o ideal que houvesse assinatura de televiso digital
cabo, pois o mesmo cabo serviria para transmisso do sinal de televiso e para transmisso de
dados pela internet, que ser necessrio no momento da compra, j que estes dados precisam
ser retornados ao provedor de servio de televiso.
Esta comunicao com o servio ocorre de forma totalmente transparente para o
usurio sob as condies citadas, e realiza a autenticao no servidor, que retorna uma
resposta ao usurio pelo mesmo canal de comunicao, realizando assim, a operao de
autenticao e validao da compra. Esta ao pode gerar erro, caso o formulrio no tenha
sido preenchido corretamente ou o servio tenha recusado a requisio, ou pode finalizar a
compra caso o servio tenha validado a compra. Em caso de validao da compra, neste
modelo, o valor dever ser descontado na prxima fatura do usurio.

Figura 18: Interfaces de resultado da confirmao de compra: sucesso e erro

3.3 Desenvolvimento da Xlet

Para compreender como a aplicao funciona em um nvel mais baixo, neste item
sero apresentados trechos de cdigo da aplicao xlet e seu significado perante a modelagem
do problema, ou seja, para que foi utilizado no desenvolvimento da loja virtual.
A aplicao 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. So
elas: cliente, apresentao, negcios, integrao e dados. O cdigo fonte do programa foi
organizado de forma semelhante organizao em camadas, separando-as em pacotes, cada
um com sua respectiva estruturao interna. Esta estruturao ser apresentada a seguir, na
mesma ordem em que so apresentadas as camadas.

66
Alguns padres de programao GoF (Freeman et al., 2001) e tambm alguns padres
extrados da Java Enterprise Edition (Alur et al., 2003) foram utilizados e sero explicados
medida em que forem apresentados.
Em seguida, sero apresentados diagramas de seqncia para demonstrar como
funciona a execuo inicial do programa at o momento da exibio de um anncio e tambm
de um evento de compra gerado pelo usurio.

3.3.1 - Pacote org.tgi.store.view

Neste pacote, encontra-se apenas a classe principal da aplicao denominada Store.
Esta classe representa a xlet em si e portanto a base da loja virtual. Para esta classe ser
considerada uma xlet, necessrio que a interface Xlet do pacote xjavax.tv.xlet, definida na
implementao da API Java TV do emulador, seja implementada, e com base nos mtodos
herdados desta interface, a xlet ser informada sobre qualquer mudana de estado gerada pelo
gerente de aplicaes 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 execuo
interrompida.

Figura 19: Pacote cliente

Nos testes realizados, foi possvel 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, no conhece sua implementao, mas pode tentar carreg-la, fazendo-a passar para o
estado Loaded e execut-la atravs da interface j conhecida e padro para xlets
implementada na API Java TV. O mesmo acontece com quaisquer outras classes que so
utilizadas no decorrer da execuo da xlet.
Por exemplo, quando a xlet tentar acessar um objeto cuja definio no est disponvel
dentro do prprio STB, supe-se que esta classe tenha sido enviada junto com a xlet no fluxo
de dados, e ento o STB tenta carreg-la dinamicamente assim como fez com a prpria xlet.

67
Esse o esquema de funcionamento do emulador XleTView e talvez gere algum pequeno
atraso na execuo da aplicao, que pode se tornar quase imperceptvel dependendo do poder
computacional do STB e do tamanho do respectivo arquivo em disco.
Essa busca por definies de classe dinamicamente ocorre, no caso da aplicao da
loja virtual, quando a xlet se comunica com as classes da camada de apresentao.
A xlet se comunica com classe StoreController da camada de apresentao assim que
passa para o estado Active, para informar, atravs de seu contexto de execuo, a instncia do
gerenciador de execuo da mdia, no caso uma instncia de Player. Outras operaes
importantes que a xlet faz assim que passa para este estado, so os registros junto s classes
StoreController e ProductEventManager que fazem a classe receber eventos da camada de
apresentao, para que seja possvel atualizar a interface da aplicao. Para isso, a xlet
implementa as interfaces AnnounceListener e ProductListener, que so explicadas na prxima
camada. O registro nada mais do que uma referncia ao objeto da xlet que uma classe
gerenciadora de eventos possui.

3.3.2 - Pacote org.tgi.store.presentation

Este pacote rene as classes da camada de apresentao e nesta camada que se
concentra a maior parte das classes desta aplicao.

68

Figura 20: Pacote de apresentao

Por se tratar de uma aplicao onde a parte visual extremamente importante, pois no
se deseja interferir excessivamente na exibio do vdeo, h bastante lgica de interface e
nesta camada que feita a comunicao com a camada de negcios para a efetuao da
respectiva lgica. Esta camada uma ponte entre a camada cliente e de negcios, e est mais
relacionada com a camada cliente do que com a camada de negcios.
A classe mais importante a StoreController que uma thread que implementada
utilizando-se o padro GoF Singleton (Freeman et al., 2001), para que haja apenas uma
instncia desta thread. Esta thread disparada assim que a xlet entra no estado Active, e tem a
funo de solicitar camada de negcios uma listagem dos anncios dos produtos descritos
no arquivo MPEG-7 recebido pelo fluxo de entrada de dados, e tambm de sincronizar a
exibio de anncios com o vdeo transmitido pelo canal. Para isto, esta thread verifica o
exibio do vdeo a cada segundo. Isto feito atravs de uma referncia ao objeto do
gerenciador de execuo da mdia, que por sua vez recebida pela classe Store, e analisa em
sua lista de anncios se algum dos anncios pertence quele segundo.

69
importante ressaltar que esta lista administrada da seguinte forma: assim que a
thread encontra um anncio para comear a ser exibido naquele instante de tempo, este
anncio removido da lista, pois no aparecer novamente e a thread pausa a sua execuo
por uma quantidade de tempo estipulada no prprio anncio. Tambm importante ressaltar
que nesta lista, os anncios esto organizados por ordem cronolgica. Estas duas medidas
foram tomadas para que a execuo do programa no necessitasse de muito processamento
por parte do STB, ou seja, a fim de otimizar a aplicao.
A classe StoreController ainda implementa o padro GoF Observer (Freeman et al.,
2001), semelhante ao mecanismo de listeners encontrado no pacote java.awt.event. Esta
classe mantm uma lista de objetos que implementam a interface AnnounceListener do pacote
org.tgi.store.presentation.event. Desta forma, quando a thread encontra um anncio para
exibio naquele segundo, ela gera eventos do tipo AnnounceEvent, e os envia para todos os
itens desta lista, avisando que o anncio deve ser exibido. Ento a thread pausa, e quanto
retorna, gera outro evento para que os anncios sejam escondidos.

Figura 21: Pacote de interface grfica da camada de apresentao

70
J no pacote org.tgi.store.presentation.ui encontram-se componentes visuais, que
derivam da API HAVi para televiso digital, pois a mesma implementa componentes de
forma padronizada, e cada STB tem a sua implementao 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 exibio do anncio. A classe StoreLayoutManager, que tambm adota
o padro GoF Singleton (Freeman et al., 2001), responsvel pela criao de novas instncias
de AnnounceContainer, que nada mais do que um continer visual, que engloba
componentes que representam o texto, a imagem e os botes do anncio. A maneira como
ser exibida esses componentes dentro do continer depender da instncia de StoreLayout.
A classe abstrata StoreLayout e todas as classes que a implementam fazem parte de
um padro GoF do tipo comportamental, denominado Strategy (Freeman et al., 2001). Cada
uma das classes que implementam esta interface, dispem de componentes visuais diferentes
para representar o anncio, ou seja, so maneiras diferentes de representar um mesmo tipo de
dado na tela. Neste caso so utilizadas para ilustrar as etapas de visualizao do anncio,
visualizao de detalhes do produto, autenticao 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

continer, de acordo com o tamanho dos componentes, realizando uma tarefa simples, mas
que no estava implementada por padro.
A classe AnnounceContainer tambm implementa a interface ProductListener e se
registra em ProductEventManager (outro Singleton), num mecanismo igual ao da classe
StoreController que implementa o padro GoF Observer (Freeman et al., 2001). S que desta
vez, os eventos so gerados quando o usurio pressiona um boto do controle remoto, e este
evento do boto acarreta em uma alterao na interface, como por exemplo, apertar o boto
vermelho para visualizar a interface de detalhes do produto. No momento em que o
AnnounceContainer

recebe

um

evento

desse

tipo,

chamada

instncia

de

StoreLayoutManager para a gerao de um novo StoreLayout, e em seguida este associado

ao continer, redesenhando a interface na tela. AnnounceContainer tambm guarda uma
instncia de LayoutState, que um padro GoF chamado State (Freeman et al., 2001) hardcoded, ou seja, implementado diretamente via cdigo e no atravs de uma hierarquia de
classes. Este LayoutState representa o estado que a interface do anncio se encontra no

71
momento em que gerado um evento, pois o mesmo boto pode gerar diferentes aes
dependendo do StoreLayout atual.

3.3.2 - Pacote org.tgi.store.business

neste pacote que se concentra a lgica de negcio da aplicao. A principal
funcionalidade aqui, receber requisies e trat-las de forma correta aplicando a lgica
necessria.

Figura 22: Pacote de negcios

Toda vez que uma a thread da classe StoreController, da camada de apresentao,

instanciada pela primeira vez, as informaes sobre anncios so solicitadas classe
StoreFacade, que por sua vez, tambm utiliza o padro GoF Singleton (Freeman et al., 2001),
para manter apenas uma instncia de si mesma. O principal motivo para se ter apenas uma
instncia dessa classe deve-se ao fato de a aplicao inteira estar armazenada no STB, onde h
apenas um usurio, e no mltiplos usurios acessando de forma concorrente, como em um
servidor web.
A classe StoreFacade, aps receber a requisio da listagem dos anncios, solicita
camada seguinte, mais precisamente qualquer classe que deriva de DataAccess da camada
de persistncia. O resultado dessa solicitao ento processado e armazenado em objetos do
tipo AnnounceBO que utilizam o conceito do padro Java EE Business Object (Alur et al.,
2003).
A classe AnnounceBO tem a responsabilidade de armazenar as informaes,
representando a entidade anncio de forma coesa, e seus objetos podem ento ser repassados

72
para a camada de apresentao, onde utilizado como um dos atributos de classes como
AnnounceEvent e ProductEvent, que pertencem ao mecanismo do padro GoF Observer
(Freeman et al., 2001). Sendo assim, qualquer classe que se registrar para receber eventos dos
tipos citados, tambm ir receber, como atributo, uma instncia da classe AnnounceBO,
possibilitando que classes da camada de apresentao tenham acesso s informaes do
produto.
Outra funcionalidade desta classe, que foi deixada de lado nesta aplicao, a
validao da compra. O mtodo checkUser() da classe StoreFacade, do modo como foi
implementado apenas valida qualquer requisio. Esta validao no foi implementada pois
necessita da uma comunicao com o canal de retorno, que ainda no foi implementado nesta
verso do emulador.
Esta classe tambm poderia ser responsvel por se comunicar com o SI para obter
informaes temporais que poderiam ser utilizadas na sincronizao dos anncios com a
propaganda, mas as classes do pacote org.dvb.si e as classes referentes ao SI da API Java TV
tambm no 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 integrao. Pra acesso aos dados foi utilizado o padro Java EE Data Access Object,
tambm 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 provm acesso aos dados de forma especfica.

Figura 23:Pacote de ingrao

73
A classe utilizada para efetivo acesso aos dados foi a XmlDataAccess, que
apropriada para ler especificadamente os dados de produtos relativos anncios da aplicao,
que provm do schema criado para MPEG-7 e descrito no prximo item deste captulo. 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
atravs da API Simple API for XML, tambm conhecida como SAX, que pode ser
considerada uma API rpida e eficiente neste caso, pois devido a baixa complexidade do
XML resultante, uma API com mais funcionalidades acarretaria em perda de desempenho da
aplicao. Com o auxlio do padro 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 no s para produtos. At mesmo outra fonte de dados que no
fosse o MPEG-7 poderiam ser implementadas e tratadas. Nesta aplicao os tipos de dados
que so lidos do XML so definidos via cdigo, proporcionando pouca flexibilidade para a
obteno do produto, que deixa o acesso aos dados mais rpido j que se espera um XML
derivado do schema de produtos definido.
Algumas consideraes devem ser feitas quanto ao XML. Como a localizao do
anncio na tela definida tambm pelo XML, possveis problemas como se o tamanho da tela
da televiso digital e o tamanho do anncio forem incompatveis com a localizao do
mesmo, no sero responsabilidade desta camada e sero tratados mais frente, quando os
dados relativos ao anncio chegarem na camada de apresentao. E como o tempo de exibio
tambm definido via XML, a verificao e validao destes dados praticamente
inexistente, pois este processo feito item a item, pode retardar uma exibio de anncio o
suficiente para que ele no aparea. Assim, o sistema considera desde o incio, que o arquivo
XML contenha dados corretos para a exibio das propagandas. Um dado incorreto muitas
vezes no acarretaria em uma exceo, erro ou mensagem tratada pelo sistema.
Possveis erros na montagem do arquivo XML podem ser citados: em relao ao
tempo de exibio, um anncio poderia estar configurado para ser exibido no momento em
que outro anncio j estivesse em exibio, e desta forma ele seria automaticamente
descartado e no seria exibido ao usurio. Erros nos valores da posio do anncio da tela,
como anncios que ficam fora da rea de exibio, ou seja, ultrapassam os limites da tela, so
automaticamente corrigidos pela aplicao no momento da exibio do anncio.

74
3.3.4 Pacote org.tgi.store.data
Este pacote tem a funcionalidade de representar entidades relacionadas com o
contedo XML do MPEG-7 recebido. No caso da aplicao deste trabalho, a entidade produto
representada pela classe Product. Esta classe utilizada apenas pela camada de integrao e
no se estende s outras camadas da aplicao 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 contm apenas a classe Debug para a gerao de um histrico de
mensagens para a depurao da aplicao, e faz o uso de uma das modificaes feitas no
emulador que a janela para armazenamento de mensagens de xlets.

3.3.6 Diagrama de Seqncia para a ativao de um anncio

O diagrama UML (Booch et al., 1998) a seguir um diagrama de seqncia e foi
utilizado para demonstrar quais classes e quais mtodos precisam ser utilizados at que um
anncio possa ser exibido na tela, ou seja, representa a seqncia de ativao de um anncio.
Relaes de ordem de execuo tambm so representadas atravs deste diagrama, que possui
uma caracterstica temporal de representao de aes na aplicao na forma de linhas
verticais para o tempo decorrido e de linhas horizontais para a chamada de mtodos.

75
Para representar esta seqncia, que no faz parte de nenhuma ao do usurio, mas
sim da execuo inicial da aplicao e que ocorre de forma automtica, o diagrama poder ser
subdividido em duas partes. Tambm podemos perceber que considerada apenas a execuo
da xlet em si, e no das operaes do STB de carregamento da mesma no sistema.
Na primeira parte, a xlet Store apenas realiza inicializao de variveis internas e
recupera a instncia do gerenciador de mdias em execuo dentro do emulador e repassa
camada de apresentao. Em seguida a xlet inicia o servio de busca de anncios, ou seja,
instancia a thread StoreController, cujo papel solicitar classe StoreFacade que ela realize
a busca de anncios para exibio, e verificar a cada segundo se existem anncios 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, so encapsulados em objetos do tipo AnnounceBO.
E por ltimo, a classe StoreController gera um evento de exibio de anncio
AnnounceEvent. Para esta ltima chamada, vale lembrar, que ocorre apenas quando um
anncio foi encontrado para determinado intervalo de tempo, e que apenas feita para outros
objetos que esto previamente registrados para receb-los, seguindo a idia do padro GoF
Observer (Freeman et al., 2001).

Figura 25: Primeira parte do diagrama de seqncia da ativao de um anncio

76
Na segunda parte deste diagrama, ocorre a exibio de componentes visuais na tela, j
que se considera o cenrio onde uma ocorrncia de anncio foi encontrada para determinado
instante. A partir desse momento, a xlet avisada atravs de um mecanismo de eventos e
solicita classe que gerencia componentes visuais para exibio de anncios,
StoreLayoutManager, que crie um componente visual que atenda s especificaes do
produto em questo, ou seja, crie um anncio para um produto. Esse conjunto de componentes
visuais est contido em AnnounceContainer e definido por StoreLayout. Com essa criao e
inicializao do objeto AnnounceContainer, o anncio deve ser repassado xlet, que a nica
classe que contm referncia para a tela de exibio do usurio, podendo assim, anexar o
anncio tela.

Figura 26: Segunda parte do diagrama de seqncia da ativao de um anncio

3.3.7 Diagrama de Seqncia para a compra de um produto

O diagrama de seqncia a seguir, representa o cenrio de compra de um
produto atravs de um anncio na loja virtual.

77

Figura 27: Diagrama de seqncia de um cenrio de compra

Neste cenrio, o anncio envia ao seu ativador, ou seja, a thread StoreController, que
responsvel por eventos de ativao de anncio, as informaes contidas no campo para
preenchimento do cdigo de assinante, que o usurio dever preencher para que valide sua
inteno de compra. A StoreController faz apenas uma validao bsica nesse cdigo, 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 lgica de negcio
referente compra. nesta parte que deveria ocorrer uma chamada ao servio com o cdigo
de assinante para efetiva validao da compra, atravs do canal de retorno, porm, por
motivos j explicados, impossvel fazer esta operao atravs do emulador utilizado.
Em seguida, o prprio AnnounceContainer se encarrega de atualizar seus componentes
visuais de acordo com seu estado interno, para mostrar a resposta da solicitao de compra.

3.4 O Uso dos padres MPEG-7 e MPEG-21

A aplicao desenvolvida neste trabalho nada mais do que um elo de ligao entre o
MPEG-7 e o MPEG-21, pois utiliza dados vindos de ambos para gerar um produto final: a
loja virtual para televiso digital. Nos prximos itens sero destacados os modos com os quais
cada padro foi utilizado.

78
importante ressaltar que MPEG-7 e MPEG-21 so independentes do formato de
codificao de vdeo e udio utilizado, e o resultado da codificao do vdeo com os seus
metadados dar-se- a partir da combinao de ambos. Por exemplo, o padro MPEG-7,
quando utilizado em conjunto com o MPEG-4 (referente ao contedo de udio e vdeo), pode
ser chamado de MPEG-47.
Atravs das ferramentas de descrio e linguagem de declarao de itens digitais
presentes nesses formatos de vdeo, possvel, atravs do MPEG-7 classificar os itens, e com
o uso do MPEG-21 tambm seria possvel o anexo de imagens ou vdeos demonstrativos do
produto junto com o vdeo principal da programao.

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 sero retirados para o uso no programa. A flexibilidade
proporcionada pelo MPEG-7 permite a passagem desse tipo de dados junto com o vdeo. 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 hierrquica a se seguir, entre
outros fatores. Por conta dessa complexidade e das indefinies ainda presentes no formato,
no foi possvel usar propriamente um arquivo MPEG-7. Os programas de anotaes para
vdeo ainda esto em fases iniciais de desenvolvimento, no permitindo gerar as estruturas
necessrias para o uso no programa. Entretanto, certo que essa estrutura possvel de ser
obtida e por isso, foi simulada de forma a funcionar da maneira mais prxima da estrutura que
esperada em um arquivo MPEG-7. Entre os programas que foram usados para a tentativa de
criao de anotaes em MPEG, pode-se citar o IBM Multimedia Annotation Tool, da IBM,
em sua verso 1.1, que, devido a diversos erros na gerao do arquivo, no pde ser explorado
com maiores detalhes. J o Semantic Video Annotation Tool, SVAT, permitiu a criao 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 criao de metadados para arquivos de imagem. Entretanto, so tags
especficas para anotao de imagem, no sendo genrico 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 vdeo corretamente na aplicao. Por ser uma tecnologia muito
recente, as bibliotecas de manipulao do vdeo ainda no existem, impedindo que o
programa trabalhasse com MPEG-7 da forma que era desejada. A escolha foi, portanto, partir
de uma situao ideal, considerando que o arquivo j tivesse sido tratado e o vdeo e o arquivo
descritivo XML com a descrio dos produtos da loja j estivessem devidamente separados.
Com o avano do padro MPEG-7 e com a disseminao da televiso digital,
softwares e bibliotecas que do suporte MPEG-7, ou maior nvel de compatibilidade, vo
conseqentemente surgir, possibilitando a manipulao desses arquivos de forma a chegar
facilmente na situao inicial com a qual se inicia a aplicao.
Devido dificuldade na gerao de um arquivo MPEG-7, o arquivo de Description
Definition Language, tambm foi simulado. A aplicao l o arquivo como se fosse um XML
comum. O cdigo a seguir um exemplo de header para esse tipo de arquivo que foi montado
na simulao 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 so dados referentes ao

componente multimdia. 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 ausncia de um schema adequado para o uso na aplicao, pois os
schemas encontrados, mesmo os que lidavam com informao genrica, tratavam apenas de
elementos que de fato apareciam no vdeo e no de elementos externos ao mesmo, a
alternativa foi a criao de um schema prprio, que satisfizesse as necessidades de metadados
do programa. A criao deste schema tambm favorece a incorporao de aplicaes bsicas
na definio bsica do padro, j que novas plataformas como a televiso digital favorecem o
desenvolvimento e a expanso destes padres.

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 declarao desse esquema permite que o programa consiga ler a partir de um

arquivo, a especificao de um produto para uso na loja.

81
Um exemplo do tipo de XML que pode ser feito seguindo essa declarao:
<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, boto na
frente, punhos com botes 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 aplicao desenvolvida capaz de ler sem maiores problemas o XML citado atravs
da API SAX. O esquema de montagem do XML segue tambm o que foi definido no DDL
anterior, seguindo as regras de tipos e nomes dos campos, alm da hierarquia.
O continer externo frangostore engloba todos os produtos que sero usados no
programa. Cada produto definido junto com um id, que um campo numrico para controle
do produto pela loja. Alm disso, outros itens essenciais para a definio de um produto o
tempo de incio e durao do anncio na loja, definidos respectivamente nos atributos start e
length.
Cada produto engloba tambm uma srie de variveis que caracterizam-no. Entre os
campos pertencentes a um produto, temos name, que o nome do produto na loja,
shortdescription, que uma descrio curta do produto para exibio no anncio no
selecionado e description, que uma descrio mais detalhada que exibida quando o usurio
desejar ver mais informaes do produto.
O elemento image indica o endereo de uma imagem para exibio no anncio, se
existir uma imagem. Se um produto no possuir uma imagem, este campo pode vir vazio e o
anncio ser exibido somente com a descrio. Este elemento ainda possui um atributo
booleano video, que indica se ser mostrado uma imagem ou vdeo no anncio. J o elemento
imageLarge utilizado para especificar o endereo de uma segunda imagem ou trecho de
vdeo, que podero ser utilizados na tela de exibio de detalhes do anncio.
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 transparncia do layout (transparency), posio do anncio na horizontal,

82
posio do anncio na vertical (positionX e positionY), altura e largura do anncio (width e
height).
Cada um desses elementos precisa ser especificado com detalhes no schema do
MPEG-7. O continer 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 definio de seus atributos e seus respectivos tipos.
<element name="image" type="mpeg7:TextualType">
<attribute name="video" type="boolean" use="required"/>
</element>

O cdigo 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 obrigatrio. No
caso da definio de uma imagem para o anncio, por exemplo, era necessrio definir um
campo de texto que indique o nome da imagem ou vdeo a ser exibido no anncio do
programa. E era necessria tambm uma varivel booleana obrigatria que indicar se o
contedo daquele elemento uma imagem ou um vdeo.
O schema, ento, define um trecho do XML como exemplificado abaixo:
<image video="true">pizza1.avi</image>

Entretanto no possvel garantir a integridade dos dados presentes no XML antes da

execuo da aplicao, pois mesmo que ele esteja compatvel segundo o schema definido,
dados contidos nele podem ser invlidos do ponto de vista da aplicao, como a posio do
anncio. Considera-se, portanto que ele est correto quanto aos dados apresentados.
Entretanto, uma interface para a criao de um arquivo XML para ser usado na aplicao
uma tarefa simples e uma validao dos dados, para garantir que todos os valores estejam no
formato certo e de forma consistente, poderia ser feita nesse processo de gerao do arquivo.
Para exemplificao do funcionamento do programa, o XML usado foi escrito manualmente,
com dados que se encaixavam na aplicao. A gerao do MPEG-7, portanto, uma etapa
crucial para o funcionamento da aplicao.

83
3.4.2 MPEG-21
A utilizao do formato MPEG-21 bastante prejudicada pela constante atualizao
ou at mesmo indefinio de vrias partes do padro, cujo progresso pode ser verificado
atravs do site oficial dos padres MPEG. No site oficial possvel conferir um cronograma
das publicaes das especificaes que j foram realizadas. Tambm possvel observar que
atualmente menos da metade das partes do padro que foram propostas, j possuem
especificao. Isto se deve ao fato do constante trabalho focado nas primeiras partes, pois elas
serviro de base para as conseguintes.
Sendo assim, fabricantes de hardware e softwares em geral, como por exemplo, os
fabricantes de STBs, ainda no optaram pela adoo deste padro. A rpida mudana de
tecnologias, como a migrao de televises analgicas para televises digitais, bem como a
variedade de dispositivos receptores de sinal de televiso digital disponveis, impulsiona o
avano dos padres MPEG. H padres de televiso digital que utilizam MPEG-2 para o
vdeo, enquanto outros utilizam MPEG-4, e essa divergncia de padres que o MPEG-21
procura resolver, proporcionando interoperabilidade entre os padres em diferentes
plataformas. Da tem-se idia da complexidade da especificao do padro e das constantes
atualizaes que sero necessrias com o desenvolvimento de qualquer outro padro MPEG.
Ento, o uso deste padro trata-se de uma modelagem conceitual do que ele realmente
representaria na loja virtual. Este modelo usar algumas das principais partes do padro
MPEG-21 que j foram publicadas at agora e que esto passveis de atualizao, que so:
Digital Item Declaration, Digital Item Identification, Digital Item Adaptation, Rights
Expression Language e Rights Data Dictionary.
O modelo definido para esta aplicao ser um item digital denominado Produto, que
representar a entidade produto da loja virtual. Um item digital desse tipo, dever conter todas
as informaes necessrias para que a aplicao da loja virtual, que reside no STB, seja capaz
de exibir um anncio ao usurio.
O item digital ter imagens do produto, como miniaturas que sero usadas para o
anncio inicial e imagens maiores que sero exibidas em maior tamanho para a melhor
visualizao do mesmo, alm de metadados MPEG-7 informando detalhes como preo do
produto, descrio, se possui imagens relacionadas ou no, entre outros. Este item digital
tambm ter componentes que podero ser opcionais para a exibio do anncio, como vdeos
de utilizao do mesmo, por exemplo, ou ento udios e vdeos para o caso de o produto da
loja virtual ser necessariamente digital, e no um objeto fsico, 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 contedo de um produto

Diversos conceitos definidos em Digital Item Declaration, DID, sero utilizados nesta
parte, para a estruturao do item digital, como continer, item, descritor, componente e
recursos. Um continer poder conter um ou mais itens, que por sua vez, sero itens digitais
da entidade produto, ou seja, em um s arquivo MPEG-21, diversos produtos podero ser
armazenados e transferidos. Desta forma, tambm pode ser feita uma categorizao por
contexto em que aparecem, por exemplo, um continer pode ser utilizado para cada programa
de televiso que transmitido. Cada item digital ter seu descritor, onde estaro os metadados
no formato MPEG-7 referente ao produto o qual representa, e tambm ter estruturas internas
denominadas componente que representaro uma associao entre descritores e recursos, ou
seja, contedos multimdia presentes no item digital, que podero ser opcionais ou no. No
caso do componente, o descritor seguir a parte Digital Item Adaptation da especificao do
padro MPEG-21, pois esta descrio, ao contrrio do padro MPEG-7 que trata da descrio
do contedo multimdia, trata de informaes sobre a manipulao desse contedo
multimdia, encapsulado em recursos, como bit rate, mtodos de criptografia utilizados,
conjunto de caracteres, entre outros.
A parte Digital Item Identification, DII, que trata da identificao do item digital,
tambm tem grande utilidade nesta aplicao, pois servir para atribuir nomes nicos aos
componentes do item digital. Estes identificadores so atribudos pelo provedor de servios de
televiso digital de acordo com um sistema interno de nomenclatura. Neste caso,

85
identificadores so escolhidos para representar hierarquia entre os componentes de um item
digital, e tambm para representar um produto perante a loja virtual. Cada produto recebe uma
identificao nica, e cada componente do item digital que o representa, recebe uma
identificao padronizada, de acordo com a identificao nica do item digital e uma
funcionalidade atribuda a cada componente.
Esta estruturao, bem como a identificao do produto representada na figura a
seguir:

Figura 29: Digital Item de um produto feito com DID e DII

A parte da especificao Rights Expression Language pode ser usada pelo provedor de
servios de televiso digital, para definir diferentes mtodos de acesso ao item digital. Desta
maneira, possvel fazer com que a aplicao da loja virtual e o servio de exibio de
anncios sejam exibidos apenas para usurios que contrataram este servio perante o provedor
de servios, por exemplo. Tambm possvel a criao de regras mais complexas para a
visualizao deste item digital, ou de apenas partes dele.
Uma regra mais complexa para um item digital pode ser a validao do STB para a
exibio de um anncio, ou seja, verificar se a aplicao da loja virtual est disponvel no
STB, e at mesmo verificar a identificao do prprio STB por questes de segurana, para
saber se o item digital foi enviado para o STB correto, j que o sinal de televiso digital
distribudo atravs da difuso.
Outra possvel, e importante regra, para a definio do acesso a contedo protegido
dentro de um item digital. Este contedo interno pode ser considerado um produto digital, no

86
contexto da loja virtual, sendo imagens, outros vdeos, filmes, ou msicas. Para representar
essa hierarquia interna, de apenas partes de um item digital possurem regras de utilizao,
convm a adoo de termos comuns, definidos na parte Rights Data Dictionary da
especificao do MPEG-21.
Nesta parte esto presentes conjuntos de termos nicos e consistentes, que representam
relacionamentos ontolgicos entre regras presentes em um item digital, e o contedo sobre o
qual a regra infere. Assim, esta parte age como um complemento Rights Expression
Language, provendo uma associao lgica para as regras. Um exemplo de uma regra de
acesso um produto digital pode ser visto na figura a seguir:

Figura 30: Regra aplicada exibio de item digital contendo o vdeo de um produto digital vendido

Na aplicao desenvolvida para este trabalho, o papel do padro MPEG-21 implcito.

Como os metadados MPEG-7 e as imagens do produto, esto contidos no item digital
derivado do MPEG-21, descrito acima, e partindo do princpio de que o emulador utilizado
no consegue simular fluxo de dados, ou seja, a captao de dados do STB atravs do meio de
transmisso escolhido, e de que o emulador tambm no capaz de interpretar padres
MPEG, especialmente padres mais recentes como o MPEG-21, essencial o estabelecimento
de uma condio ideal para que o desenvolvimento se torne vivel.
Nesta condio ideal considera-se que ambos os componentes MPEG-7 e multimdia,
que so relativos a um item digital, que neste caso o produto, tenham sido extrados do
arquivo MPEG-21 que supostamente foi enviado pelo SI e posteriormente, recebido e
armazenado temporariamente no STB. Este STB deveria ter a implementao do software de
referncia do padro MPEG-21 que est especificado em uma das partes deste padro, mas
encontra-se em constante atualizao. Sendo assim, o STB teria a capacidade de extrair
recursos do item digital, e disponibiliz-los em uma memria local, dentro do prprio sistema
de arquivos, para quaisquer aplicaes residentes no STB. Ainda assim, de acordo com a

87
identificao do item digital, seria possvel iniciar a execuo de uma determinada xlet. Por
exemplo, se o STB identifica que o item digital um produto de loja virtual, e o mesmo
contm a aplicao loja virtual, o STB simplesmente executa-a. Nesta situao, necessria
uma alta compatibilidade entre STB e xlet, que se pode alcanar atravs da adoo aos
padres MPEG-7 e MPEG-21, para que o STB faa a relao entre item digital e aplicao.

88

Captulo 4 Concluso e Trabalhos futuros

O desenvolvimento de aplicaes para televiso digital com recursos de fins nocomerciais e plataformas de cdigo aberto bastante prejudicado pela escassez dos mesmos.
Poucos esto disponveis, e os que esto disponveis de forma livre, so incompletos ora na
implementao da API Java TV ora na implementao de um padro de televiso digital.
Pesquisas em tecnologias recentes so agravadas devido a funcionalidades que ainda no
foram completamente definidas ou que sofrem mudanas com uma freqncia elevada, assim
como evidenciado nesta pesquisa, j que, apesar de existirem padres de televiso digital
definidos, o desenvolvimento de softwares para tais padres encontra-se em estado primrio.
A escassez de material acadmico, livros em especial, sobre os padres MPEG-7 e
MPEG-21 tambm um fator prejudicial. Apesar de contar com diversas fontes, a maior parte
delas tratam de uma introduo ao assunto. Isto se d pois ambos os padres so
relativamente recentes, principalmente o padro MPEG-21, que ainda no possui sua
especificao completa, mas apenas a sua base, que ocasionalmente ainda sofrer mudanas
devido a novas plataformas como televiso digital estarem em ascenso. Com esta plataforma,
diferentes dispositivos tero acesso ao sinal de televiso 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 usurio do sistema. Diversas formas de interatividade surgem a
partir da, e essa foi a questo explorada com os padres MPEG-7 e MPEG-21 nesta pesquisa.
Ao contrrio dos outros padres MPEG, o padro MPEG-7 prope um complemento para
outros padres, e no um novo mtodo de codificao de vdeo. O mesmo acontece com o
MPEG-21 que prope uma maneira de interao entre todos os outros padres.
A interao entre padres MPEG proposta pelo padro MPEG-21 pode ser facilmente
aplicada televiso digital, j que os padres de televiso digital se baseiam em compresses
de vdeo MPEG para otimizar a transferncia de dados. Porm estes recursos no podem ser
explorados na prtica pela falta de ferramentas de desenvolvimento capacitadas para realizar
estas operaes. Isto tambm ocorre com o padro MPEG-7, cujas ferramentas de
desenvolvimento no so totalmente compatveis com a especificao.
Com o emulador utilizado, o XleTView, tambm foi invivel a construo do sistema
da forma como era desejada, pois o emulador carece de diversas implementaes da API Java
TV e tambm do middleware MHP, no qual se baseia. Sendo assim, funcionalidades como a
validao de uma compra na loja virtual que necessitariam da utilizao do canal de retorno

89
tambm no puderam ser testadas, pois o emulador no suporta tal funcionalidade. A
tendncia que a disseminao da televiso digital acarretar na melhoria das condies de
desenvolvimento para aplicaes voltadas tecnologia, com o surgimento de ferramentas que
possibilitaro a implementao de aplicaes para tal plataforma.
A precariedade do emulador tambm nos impossibilitou tirar maiores concluses sobre
o desempenho do aplicativo. A configurao do computador tambm influencia na execuo
do aplicativo. Sendo assim, espera-se que, rodado num STB, a aplicao no tenha quaisquer
problemas em relao ao desempenho, pois um STB deve ter poder computacional suficiente
para decodificar vdeos digitais e realizar todas as suas outras operaes, alm de deixar um
restante de sua capacidade para aplicaes disponveis pelas prprias emissoras
Diversas possibilidades para continuaes desta pesquisa se abrem. A implementao
do software em um emulador mais avanado, que tenha suporte funcionalidades como a
comunicao com o canal de retorno, ou a simulao de transmisso de dados de vdeo so
necessrias. Com a comunicao com o canal de retorno possvel a implementao da
validao de uma compra com o servidor, e outras aplicaes que necessitem de uma troca de
dados mtua. J com o suporte simulao de transmisso de dados de vdeo, possvel
recuperar dinamicamente metadados disponveis medida em que so transmitidos,
simulando um ambiente real de televiso digital. Outra opo seria a implementao do item
digital proposto, que no momento da realizao desta pesquisa, era invivel. possvel ainda,
fazer um estudo de usabilidade em interfaces de televiso digital, j que se encontram
precrias e as que foram usadas neste trabalho foram totalmente ou parcialmente criadas.

90

Referncias
Referncias Bibliogrficas
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. Disponvel 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 Elstico para Vdeo em Fluxos MPEG-2. Dissertao
(Mestrado em Cincia da Computao), Pontifcia Universidade Catlica do Rio de Janeiro, Brasil,
2005
DAVIC. DAVIC 1.4.1 Specification Part 9: Information Representation. Disponvel em:
http://www.davic.org/Download/Spec1_2/part09.pdf. Acesso em 30 mar, 1999
DVB. Digital Video Broadcasting Project. Disponvel em http://www.dvb.org. Acesso em 25 fev,
2004.
FERNANDES, J.; LEMOS, G.; SILVEIRA, G. Introduo Televiso Digital Interativa: Arquitetura,
Protocolos, Padres e Prticas. Apresentado na Jornada de Atualizao em Informtica do Congresso
da Sociedade Brasileira de Computao, 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 Informtica, Universidade Federal da Paraba , 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. Disponvel em:
http://www.technologyreview.com/BizTech/14734/. Acesso em 24 mar, 2005.
HAVI, HAVi, the A/V digital network revolution. Disponvel 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. Disponvel 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. Disponvel em: http://www.chiariglione.org/mpeg/standards/mpeg-1/mpeg-1.htm.
Acesso em 24 abr, 1996.
MPEG7. MPEG-7 Overview. Disponvel em: http://www.chiariglione.org/mpeg/standards/mpeg7/mpeg-7.htm. Acesso em 2 mai, 2004.
OLIVEIRA, E. C. R.; ALBUQUERQUE, C. V. N. TV Digital Interativa: Padres para uma nova era.
Disponvel em: http://www.ic.uff.br/~celio/papers/eri05.pdf - Acesso em 11 jul, 2005.
PAES, A.; ANTONIAZZI, R. Padres de Middleware para TV Digital. Universidade Federal
Fluminense, Niteri, 2005.
PENG, C. Digital Television Applications. Dissertao (Doutorado em Cincia da Computao),
Helsinki University of Technology, Finlndia, 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 Amaznia, 2004.
CHIQUITO, J. G.; ARANTES, D. S.; COSTA, M. H. M. Consideraes sobre o relatrio final da
SET/ABERT para definio do padro de televiso digital no Brasil. Departamento de Comunicaes,
Unicamp, So Paulo, 2000.
ERONEN, L. and VUORIMAA, P.. User interfaces for digital television: a navigator case study.
Disponvel 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. Disponvel 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 Programao para o Desenvolvimento de Aplicaes para TV Digital.
Trabalho de Graduao, Universidade Federal de Pernambuco, 2004.

92

MHP. An Introduction to MHP - White Paper. Disponvel 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. Disponvel
em : http://www.chiariglione.org/mpeg/standards/mpeg-2/mpeg-2.htm. Acesso 25 abr, 2000.
MPEG4. Overview of the MPEG-4 standard. Disponvel em:
http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm. Acesso em 3 mai, 2002.
MPEG21. MPEG-21 Overview. Disponvel em: http://www.chiariglione.org/mpeg/standards/mpeg21/mpeg-21.htm. Acesso em 2 mai, 2002.
PAWLAN, M.. Introduction to Digital TV Applications Programming. Disponvel 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. Disponvel em:
http://portal.acm.org/citation.cfm?id=376335 Acesso em 22 mar, 2000.
PIMENTEL, C. A. F. Uma anlise do uso do padro MPEG-7 pela ferramenta IBM Annotation Tool,
2006.
SILVA, F. P. R.; SOUSA, A. H. S.; LEMOS, G. Aplicaes para TV Digital Interativa. Departamento
de Informtica, Universidade Federal da Paraba, Joo Pessoa, 2004.
SIVARAMAN, G.; CESAR, P.; VUORIMAA, P. System software for digital television applications.
Tokyo: IEEE, 2001.
SUWELACK, S., GANTES, F. and HERNNDEZ, A.. Introduction to MPEG-21. Disponvel 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