94
UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA Trabalho de Graduação Interdisciplinar Paulo Henrique Martins e Roger Tadeu dos Santos Aplicação dos Padrões MPEG-7 e MPEG-21 em TV Digital São Paulo 2007

APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Embed Size (px)

DESCRIPTION

O objetivo deste trabalho é o estudo da plataforma de televisão digital para o desenvolvimentode uma aplicação de loja virtual que faça uso dos padrões MPEG-7 e MPEG-21. Estaaplicação de televisão digital servirá como uma ligação entre os elementos do padrão MPEG-7, utilizado para gerar metadados sobre arquivos multimídia, e os elementos do padrãoMPEG-21, que servirá para o encapsulamento e o controle de acesso à arquivos multimídia.A aplicação será desenvolvida com o uso da API Java TV, por causa da sua alta portabilidadeentre sistemas de televisão digital, e também com o emulador XleTView, que será utilizadopara testar as aplicações durante o processo de desenvolvimento. Ao final deste estudo, seráfeita uma análise da viabilidade de implantação desta aplicação na plataforma de televisãodigital.

Citation preview

Page 1: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA

Trabalho de Graduação Interdisciplinar

Paulo Henrique Martins e Roger Tadeu dos Santos

Aplicação dos Padrões MPEG-7 e MPEG-21 em TV Digital

São Paulo 2007

Page 2: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

PAULO HENRIQUE MARTINS E ROGER TADEU DOS SANTOS

APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Trabalho de Conclusão de Curso de Ciência da Computação da Universidade Presbiteriana Mackenzie, apresentado como requisito parcial para a obtenção do Grau de Bacharel em Ciência da Computação.

ORIENTADOR: Prof. Dr. Ismar Frango Silveira

São Paulo 2007

Page 3: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA

CIÊNCIA DA COMPUTAÇÃO

Termo de Julgamento de Defesa de Trabalho de Graduação Interdisciplinar Aos trinta dias do mês de novembro na Universidade Presbiteriana Mackenzie, presente a

Comissão Julgadora, integrada pelos senhores Professores, abaixo discriminados, iniciou-se a

apresentação do Trabalho de Graduação Interdisciplinar do Grupo de Trabalho formado pelos

alunos abaixo e concluída a argüição, procedeu-se ao julgamento na forma regulamentar,

tendo a Comissão Julgadora atribuído às seguintes notas aos Candidatos.

Título do Trabalho: Aplicação dos padrões MPEG-7 e MPEG-21 em TV Digital

ALUNOS Número Matrícula

Média da Banca

Nota Orientador Média Desconto

por atraso Nota Final

Paulo Henrique Martins 3040296-4

Roger Tadeu dos Santos 3042936-6

COMISSÃO JULGADORA NOTA

Orientador Ismar Frango Silveira Titular 1 Titular 2 Suplente

Média Obtida pelo Grupo de Trabalho Para constar, é lavrado o presente termo que vai assinado pela Comissão Julgadora e pelo Coordenador de TGI. São Paulo, Comissão Julgadora ____________________________________________________________ Professor ____________________________________________________________ Professor ____________________________________________________________ Professor Coordenador de TGI ____________________________________________________________ Professor

Page 4: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Aos nossos pais, amigos e a todos aqueles que apoiaram no desenvolvimento deste trabalho.

Page 5: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

AGRADECIMENTOS

Agradecemos a todos aqueles que nos deram força, acreditaram em nosso potencial e

contribuíram, direta ou indiretamente para o desenvolvimento deste trabalho.

A todos os professores do Mackenzie que sempre atenderam nossas dúvidas de forma

atenciosa sempre que precisamos.

Ao nosso orientador Ismar Frango que sempre nos atendeu e guiou com muita

paciência desde o princípio.

Page 6: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

RESUMO

O objetivo deste trabalho é o estudo da plataforma de televisão digital para o desenvolvimento

de uma aplicação de loja virtual que faça uso dos padrões MPEG-7 e MPEG-21. Esta

aplicação de televisão digital servirá como uma ligação entre os elementos do padrão MPEG-

7, utilizado para gerar metadados sobre arquivos multimídia, e os elementos do padrão

MPEG-21, que servirá para o encapsulamento e o controle de acesso à arquivos multimídia.

A aplicação será desenvolvida com o uso da API Java TV, por causa da sua alta portabilidade

entre sistemas de televisão digital, e também com o emulador XleTView, que será utilizado

para testar as aplicações durante o processo de desenvolvimento. Ao final deste estudo, será

feita uma análise da viabilidade de implantação desta aplicação na plataforma de televisão

digital.

Palavras-chave: Televisão Digital, MPEG-7, MPEG-21, Metadados, Interação Humano-Computador

Page 7: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

ABSTRACT

The goal of this work is to study the digital television platform for the development of an

online store application that makes use of MPEG-7 and MPEG-21 standards. This digital

television application will be a connection between the MPEG-7 elements, used to generate

metadata about multimedia files, and the MPEG-21 elements, that will serve to encapsulates

and control the access to multimedia files. The application will be developed using the Java

TV API because of it’s highly portability between digital television systems and also with the

XleTView emulator which will be used to test the applications during the development

process. By the end of the study, an analysis will be made to evaluate the implementation

viability of his application in a digital television platform.

Keywords: Digital Television, MPEG-7, MPEG-21, Metadata, Human-Computer Interaction

Page 8: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Lista de Ilustrações FIGURA 1: FOTOS TIRADAS POR EDWARD MUYBRIDGE – QUANDO VISTAS SEQÜENCIALMENTE, DÃO A IMPRESSÃO

DE MOVIMENTO ................................................................................................................................................ 14 FIGURA 2: COMPARAÇÃO ENTRE ÁREA DA TELEVISÃO COMUM (4:3) COM O PADRÃO HDTV (16:9) ...................... 18 FIGURA 3: ETAPAS PARA CONVERTER UM VÍDEO ANALÓGICO EM UM SINAL DE TV DIGITAL .................................. 21 FIGURA 4: PROCESSO DE TRANSMISSÃO E RECEPÇÃO DE DADOS DA TV DIGITAL.................................................... 23 FIGURA 5: ESTRUTURA DO MODELO FUNCIONAL DE UM MIDDLEWARE .................................................................... 29 FIGURA 6: PILHA DE SOFTWARE EM UM RECEPTOR DE TELEVISÃO DIGITAL ............................................................. 34 FIGURA 7: CICLO DE VIDA DE UM XLET .................................................................................................................... 35 FIGURA 8: MODELO DE EXIBIÇÃO DASE .................................................................................................................. 38 FIGURA 9: MODELO DE EXIBIÇÃO ARIB ................................................................................................................... 39 FIGURA 10: EXEMPLO DE ORDEM DE APRESENTAÇÃO EM RELAÇÃO À ORDEM DE CODIFICAÇÃO ............................ 45 FIGURA 11: LOGO MPEG DESCRITO PELA ANOTAÇÃO MPEG-7.............................................................................. 51 FIGURA 12: EXEMPLO DE APLICAÇÃO DE DESCRIÇÃO EM UMA CENA DE VÍDEO, RETIRADO DE (MARTINEZ;

KOENEN; PEREIRA, 2002) .......................................................................................................................... 52 FIGURA 13: ORGANIZAÇÃO DAS FERRAMENTAS DE ACORDO COM A FUNCIONALIDADE .......................................... 54 FIGURA 14: EXEMPLO DO USO DOS ELEMENTOS DA DIGITAL ITEM DECLARATION LANGUAGE .............................. 57 FIGURA 15: IMAGEM DA JANELA DE LOG .................................................................................................................. 62 FIGURA 16: IMAGEM DA XLET EM EXECUÇÃO SOBRE O VÍDEO ................................................................................. 63 FIGURA 17: INTERFACES DE EXIBIÇÃO DE DETALHES E CONFIRMAÇÃO DE COMPRA ................................................ 64 FIGURA 18: INTERFACES DE RESULTADO DA CONFIRMAÇÃO DE COMPRA: SUCESSO E ERRO .................................... 65 FIGURA 19: PACOTE CLIENTE .................................................................................................................................... 66 FIGURA 20: PACOTE DE APRESENTAÇÃO ................................................................................................................... 68 FIGURA 21: PACOTE DE INTERFACE GRÁFICA DA CAMADA DE APRESENTAÇÃO ....................................................... 69 FIGURA 22: PACOTE DE NEGÓCIOS ............................................................................................................................ 71 FIGURA 23:PACOTE DE INGRAÇÃO ............................................................................................................................ 72 FIGURA 24: PACOTE DE DADOS ................................................................................................................................. 74 FIGURA 25: PRIMEIRA PARTE DO DIAGRAMA DE SEQÜÊNCIA DA ATIVAÇÃO DE UM ANÚNCIO ................................. 75 FIGURA 26: SEGUNDA PARTE DO DIAGRAMA DE SEQÜÊNCIA DA ATIVAÇÃO DE UM ANÚNCIO ................................. 76 FIGURA 27: DIAGRAMA DE SEQÜÊNCIA DE UM CENÁRIO DE COMPRA ...................................................................... 77 FIGURA 28: MODELAGEM DO CONTEÚDO DE UM PRODUTO ...................................................................................... 84 FIGURA 29: DIGITAL ITEM DE UM PRODUTO FEITO COM DID E DII .......................................................................... 85 FIGURA 30: REGRA APLICADA À EXIBIÇÃO DE DIGITAL ITEM CONTENDO O VÍDEO DE UM PRODUTO DIGITAL

VENDIDO .......................................................................................................................................................... 86

Page 9: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Lista de Tabelas TABELA 1: COMPARAÇÃO ENTRE OS PADRÕES DE TELEVISÃO DIGITAL ................................................................... 25 TABELA 2: SUPORTE A FORMATOS MULTIMÍDIA DA API JMF .................................................................................. 61

Page 10: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

Sumário

INTRODUÇÃO ...................................................................................................................................................... 12

CAPÍTULO 1 – A TELEVISÃO DIGITAL ........................................................................................................ 14 1.1 - SISTEMAS DE TELEVISÃO ............................................................................................................................. 15

1.1.1 - Televisão Analógica ............................................................................................................................ 15 1.1.2 - Televisão Digital ................................................................................................................................. 17

1.2 – PADRÕES DE TRANSMISSÃO DIGITAL ........................................................................................................... 21 1.2.1 - Padrões para Codificação e Compressão .......................................................................................... 21 1.2.2 - Padrão para Multiplexação e Transporte .......................................................................................... 21 1.2.3 - Padrões para Modulação e Transmissão ........................................................................................... 22

1.3 - ARQUITETURA DA TELEVISÃO DIGITAL INTERATIVA .................................................................................. 23 1.4 - PADRÕES DE TELEVISÃO DIGITAL ................................................................................................................. 24

1.4.1 - ATSC (Advanced Television Systems Committee) .............................................................................. 25 1.4.2 - DVB (Digital Vídeo Broadcasting) ..................................................................................................... 26 1.4.3 - ISDB (Integrated Services Digital Broadcasting) .............................................................................. 26 1.4.4 - Padrão Brasileiro ................................................................................................................................ 27

1.5 - MIDDLEWARES ............................................................................................................................................. 28 1.5.1 – Blocos Fundamentais ......................................................................................................................... 30

1.5.1.1 – DAVIC .......................................................................................................................................................... 30 1.5.1.2 – HAVi ............................................................................................................................................................. 31 1.5.1.3 - Java TV API ................................................................................................................................................... 33 1.5.1.4 – Microsoft TV ................................................................................................................................................. 35

1.5.2 - Padrões ................................................................................................................................................ 36 1.5.2.1 – MHP .............................................................................................................................................................. 36 1.5.2.2 – DASE ............................................................................................................................................................. 37 1.5.2.3 – ARIB ............................................................................................................................................................. 38 1.5.2.4 – Ginga ............................................................................................................................................................. 40

CAPÍTULO 2 – MPEG .......................................................................................................................................... 41 2.1 - PADRÕES....................................................................................................................................................... 41 2.3 - MPEG-1 ....................................................................................................................................................... 42 2.4 - MPEG-2 ....................................................................................................................................................... 43

2.4.1 - Camada de compressão ...................................................................................................................... 43 2.4.2 - Camada de Sistemas ............................................................................................................................ 46

2.5 - MPEG-4 ....................................................................................................................................................... 47 2.6 - MPEG-7 ....................................................................................................................................................... 47

2.6.1 - Sistemas MPEG-7................................................................................................................................ 49 2.6.2 - MPEG-7 Description Definition Language ........................................................................................ 50 2.6.3 - MPEG-7 Visual ................................................................................................................................... 51 2.6.4 - MPEG-7 Áudio .................................................................................................................................... 53 2.6.5 - MPEG-7 Multimedia Description Schemes ........................................................................................ 53 2.6.6 - MPEG-7 Description Tools................................................................................................................. 53

2.7 - MPEG-21 ..................................................................................................................................................... 54 CAPÍTULO 3 – DESENVOLVIMENTO DA APLICAÇÃO ........................................................................... 59

3.1 – O EMULADOR .............................................................................................................................................. 59 3.1.1 – Suporte à vídeos .................................................................................................................................. 60 3.1.2 – Modificações no Emulador................................................................................................................. 61

3.2 – A APLICAÇÃO ............................................................................................................................................... 62 3.3 – DESENVOLVIMENTO DA XLET ..................................................................................................................... 65

3.3.1 - Pacote org.tgi.store.view ..................................................................................................................... 66 3.3.2 - Pacote org.tgi.store.presentation ........................................................................................................ 67 3.3.2 - Pacote org.tgi.store.business .............................................................................................................. 71 3.3.3 – Pacote org.tgi.store.integration ......................................................................................................... 72 3.3.4 – Pacote org.tgi.store.data .................................................................................................................... 74 3.3.5 – Pacote de utilidades org.tgi.store.util ................................................................................................ 74 3.3.6 – Diagrama de Seqüência para a ativação de um anúncio .................................................................. 74 3.3.7 – Diagrama de Seqüência para a compra de um produto .................................................................... 76

Page 11: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

3.4 – O USO DOS PADRÕES MPEG-7 E MPEG-21................................................................................................ 77 3.4.1 – MPEG-7 .............................................................................................................................................. 78 3.4.2 – MPEG-21 ............................................................................................................................................ 83

CAPÍTULO 4 – CONCLUSÃO E TRABALHOS FUTUROS ......................................................................... 88

Page 12: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

12

Introdução Com o surgimento da televisão digital, além do grande avanço na qualidade da

imagem, a interatividade entre a televisão e o telespectador se torna possível, fazendo com

que este, passe a ser um usuário, permitindo a criação de diversas funcionalidades que não

eram possíveis com o uso da televisão analógica.

A idéia do trabalho é o desenvolvimento de uma aplicação para a televisão digital que

funcionasse como uma loja virtual, na qual fossem exibidos anúncios para os produtos em um

canto da tela, buscando não interferir na programação que estaria sendo exibida em

determinado momento. Em uma situação ideal, o produto que estivesse sendo anunciando na

loja virtual, teria alguma relação com a programação, para incentivar o usuário, que

possivelmente poderia ver o produto em uso antes de mesmo de comprá-lo.

O uso das funcionalidades de interatividade desta plataforma permite que o usuário

compre aquilo que está vendo e também que ele veja o produto em uso no próprio programa

de televisão ou através de vídeos adquiridos em tempo real, fotos do produto, entre outros.

Desta forma abre-se a possibilidade de emissoras de televisão e lojas interessadas em formar

parcerias, obterem outra fonte de renda, trazendo a ação da compra para uma nova plataforma,

explorando as novas funcionalidades que são oferecidas, e sem interromper a programação da

emissora.

Seria uma grande diferença em comparação à televisão analógica, onde grande parte

do lucro das emissoras é proveniente de propagandas e anúncios que são intercalados com a

programação da emissora, interferindo assim, em sua exibição. Assim, interagir com a

televisão digital ficaria muito mais parecido com o que é possível evidenciar em websites

acessados por computadores, onde o usuário pode navegar pela propaganda, obter mais

informações sobre ele, ver mais fotos e comprá-lo.

Há uma dificuldade também em não deixar essa propaganda ser invasiva demais,

interferindo o programa de televisão. No momento da compra, também seria necessário um

código de segurança para garantir que é o usuário responsável pelo acesso a loja virtual que

está efetuando a compra. Essa segurança é útil também para famílias, impedindo que crianças

comprem produtos sem o conhecimento dos pais.

A aplicação que será desenvolvida neste trabalho, focará no uso dos padrões MPEG-7

e MPEG-21. Estes padrões conterão todas as informações necessárias para a exibição do

anúncio, porém, é necessário o desenvolvimento de uma aplicação para televisão digital

baseada na JAVA TV API, já que os STBs desenvolvimentos até o presente momento não

Page 13: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

13

possuem suporte à tais padrões. Esta aplicação realizará a integração entre os padrões MPEG

e o programa de televisão sendo exibido, além de operações como sincronização de anúncio,

entre outras. Será apresentada toda a parte relativa à engenharia de software desta aplicação, e

também os modelos propostos para utilização dos padrões MPEG-7 e MPEG-21.

O uso desses padrões MPEG é um grande desafio, uma vez que há poucos estudos já

realizados com a utilização dos mesmos, pois estão parcialmente definidos ou sujeitos a

alterações devido ao crescente desenvolvimento da plataforma de televisão digital e outros

dispositivos multimídia.

Page 14: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

14

Capítulo 1 – A Televisão Digital O local onde hoje se encontra a Universidade de Stanford na Califórnia, já foi um dia

uma fazenda pertencente a um milionário chamado Leland Stanford. Apaixonado por cavalos

de corrida, Leland se sentia perturbado por uma questão: Os cavalos, quando trotam, tiram as

quatro patas do chão ao mesmo tempo ou não? Intrigado, Leland Stanford contratou, em

1872, o cientista Edward Muybridge para resolver a questão. O cientista então instalou 12

câmeras fotográficas rudimentares, uma na frente da outra, que eram disparadas

seqüencialmente, acompanhando o movimento do cavalo.

Figura 1: Fotos tiradas por Edward Muybridge – quando vistas seqüencialmente, dão a impressão de movimento

As fotos comprovaram que os cavalos tiram as quatro patas do chão ao mesmo tempo

durante o trote. Mas acabaram ficando famosas pela idéia de movimento que dão quando

vistas seqüencialmente. Mais tarde, iriam inspirar os estudos de outros inventores, como o

fisiologista francês Étienne-Jules Marey, que inventou em 1887, a cronofotografia. Ou

Thomas Edison, inventor do filme perfurado e do cinetoscópio em 1890. Em 1895, os irmãos

Auguste e Louis Lumiere inventaram o cinematógrafo – uma ancestral das filmadoras como

conhecemos hoje.

Assim como o vídeo, a televisão também não pode ser atribuída a um só inventor. Em

fevereiro de 1924, John Logie Baird faz a primeira demonstração de televisão analógica. O

sistema completo, com a transmissão analógica surgiu pouco depois, em 1927, demonstrado

por Philo Farnsworth.

A partir de 1935, a televisão passou a ser oficialmente transmitida na Alemanha e na

França, sendo a Torre Eiffel o principal posto transmissor francês. A rede inglesa BBC foi

Page 15: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

15

fundada em 1936. Londres, na época, usava imagens com definição de 450 linhas. Uma das

primeiras grandes transmissões foi a dos jogos olímpicos de Berlim, em 1936. Durante a

Segunda Grande Guerra, a Alemanha foi o único país europeu que manteve suas transmissões

no ar. As transmissões em Paris só voltariam em outubro de 1944, e em Londres, somente em

junho de 1946, com a exibição, pela BBC, do desfile da vitória.

Apesar das primeiras imagens coloridas terem sido realizadas em 1929, por Hebert

Eugene Ives, as transmissões regulares em cores só começaram em 1954, nos Estados Unidos,

através da rede NBC. Nessa época que surgiu o padrão NTSC (National Television Standards

Comittee), para decidir como a exibição da transmissão a cores seria feita e de modo a não

inutilizar os 10 milhões de aparelhos em preto e branco da época.

No Brasil, a primeira transmissão foi realizada na década de 1950, pela TV Tupi,

primeiro canal de televisão do país, fundado por Assis Chateaubriand. A primeira transmissão

em cores no Brasil só veio a ocorrer em 1962.

1.1 - Sistemas de Televisão

1.1.1 - Televisão Analógica

Para que seja possível compreender as melhorias e novas funcionalidades disponíveis

na televisão digital é necessário saber mais sobre o funcionamento da televisão analógica.

Há 3 padrões de televisão analógica disponíveis em larga escala atualmente, e que

lentamente estão sendo substituídos por sinais digitais: NTSC (National Television System

Committee), PAL (Phase Alternation Line) e SECAM (Séquentiel Couleur Avec Memoire).

Tais padrões especificam número de linhas horizontais e verticais (quantidade de pontos),

número de quadros exibidos por segundo, em resumo, a qualidade da imagem sendo

transmitida. Nestes 3 padrões, a proporção da imagem exibida é de 4:3.

O padrão NTSC é utilizado nos países da América do Norte, alguns países da América

Central e do Sul, Japão, etc. O vídeo é composto por 30 quadros por segundo e com 525

linhas horizontais. Já o padrão SECAM é utilizado na França e em alguns de seus países

vizinhos, utilizando 25 quadros por segundo e 625 linhas horizontais. Similarmente ao

SECAM, o padrão PAL também usa 25 quadros por segundo e 625 linhas horizontais e é

adotado na Europa ocidental e no Brasil, entre outras regiões. Com as 100 linhas a mais, a

resolução da imagem nos padrões PAL e SECAM é maior, dando mais nitidez e detalhes aos

quadros do que o padrão NTSC é capaz de fornecer.

Todos estes padrões usam uma técnica para redução do efeito flickering (cintilação na

tela perceptível aos olhos humanos), que consiste em dividir os quadros em dois conjuntos,

Page 16: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

16

combinando as linhas pares e as linhas ímpares em cada um (Fischer, 04). Essas linhas são

transmitidas seqüencialmente de forma entrelaçada, resultando em uma taxa de atualização de

quadros mais rápida, dobrando a quantidade de quadros por segundo. Desta forma, o padrão

NTSC consegue exibir 60 quadros por segundo enquanto os padrões PAL e SECAM

conseguem uma taxa de 50 quadros por segundo. Em ambos os casos, a transiçao de quadros

segundo a segundo torna-se mais suave aos olhos humanos, dando melhor sensação de

movimento da imagem (Zimet, 2002).

Houve ainda padrão de televisão analógica, o MUSE (Multiple sub-nyquist sampling

Encoding system), desenvolvido pela NHK (Nippon Hoso Kyokay) nos anos 80, que usava

uma técnica de filtragem do sinal para diminuir a banda utilizada, e com isso, poder aumentar

a qualidade da imagem. Seu nome comercial era Hi-Vision. Este padrão utilizava transmissão

via satélite e possuía 1125 linhas de definição e proporção de 1.66:1, o que o difere bastante

das outras opções em televisão analógica. Ainda assim, este padrão possuía imagem um tanto

borrada, mas pode ser considerado um grande avanço tecnológico para a época. O Japão

anunciou que as transmissões com este padrão seriam encerradas em meados de 2007.

Em todos os padrões apresentados, algumas linhas não são visíveis, nos padrões com

625 linhas, 50 linhas não são visíveis, nos padrões com 525 linhas, entre 38 e 42 linhas não

são visíveis e no padrão de 1125 linhas, 90 ou 55 não são visíveis. As linhas restantes servem

para sincronismo ou funcionalidades extras como closed caption (Fischer, 2004).

Na televisão analógica dois sinais são responsáveis pela imagem: o sinal de

luminosidade e o de croma. O sinal de luminosidade define o brilho e o contraste da imagem,

enquanto o croma fica responsável por torná-la colorida a imagem. Esta separação faz com

que televisões antigas monocromáticas ainda sejam compatíveis com sinal de televisão

analógica com imagem colorida.

A transmissão do sinal da televisão analógica ocorre através de ondas aéreas enviadas

por uma estação de televisão, em determinadas freqüências, que são pré-estabelecidas. Um

sinal de televisão analógica, composto por som e vídeo, necessita de uma banda de 6 MHz

para ser transmitido. Estas freqüências são organizadas em bandas da seguinte maneira:

• 54 a 88 MHz para os canais VHF 2 a 6

• 174 a 216 MHz para os canais VHF 7 a 13

• 470 a 890 MHz para canais UHF 14 a 83

Dentro desses canais, o vídeo é transmitido em um sinal AM, de amplitude modulada,

e o áudio é transmitido em um sinal FM, de freqüência modulada.

Page 17: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

17

A qualidade da imagem na televisão analógica é limitada não só devido à tecnologia

da época, que não disponibilizava aparelhos de televisão com alta definição, mas também pela

falta de uma alta compressão dos dados. Na citação a seguir, o autor previa a necessidade de

utilizar-se compressão no sinal de televisão, visando um avanço da tecnologia, que já estava

em estudo desde aquela época (Lynch, 1985). “Broadcast television will still be analog as it arrives at the home receiver, but along the transmission

path from the studio transmitter to the home receiver a digital link will be used, such as is a communications

satellite link, and herein will be a logical place for compression.”

1.1.2 - Televisão Digital

As pesquisas em torno do desenvolvimento de uma televisão digital iniciaram-se em

1970 pelos cientistas da Sony e da NHK (Nippon Hoso Kyokay), uma empresa de transmissão

televisiva do Japão, com o intuito de melhorias na qualidade de áudio e vídeo das

transmissões, de forma a tentar alcançar a qualidade de um filme de 35 mm. Nasce aí o

conceito de HDTV - high definition television - um formato de televisão onde o número de

linhas que compõem as imagens é altamente ampliado. Logo se viu, entretanto, que essa

tarefa não seria simples. Um único canal de 6 MHz não iria suportar o tráfego da programação

nessa qualidade. A solução só chegaria na década de 90, com a criação de um padrão de

compressão de vídeo que está em uso até hoje, o MPEG, que significa Moving Picture

Experts Group. Fazendo uso de sofisticadas técnicas de compressão, foi possível obter um

vídeo com uma qualidade muito boa em um tamanho muito menor.

A grande diferença da televisão digital está justamente na forma de transmissão,

digitalizada. A televisão, como é transmitida hoje em dia, faz uso de um sinal analógico,

transmitidos pelo ar em ondas eletromagnéticas que ocupam completamente uma freqüência

de 6 MHz. A transmissão digital continuará usando esse espaço de 6 MHz, transmitindo os

canais pelo ar. A diferença é que os dados passam a ser digitalizados. Isso permite um uso

melhor da mesma faixa de freqüência, através da compressão do conteúdo, permitindo o

tráfego de até 19 Mbits/segundo. Dessa forma, será possível que uma emissora transmita, por

exemplo, até 4 programações distintas. Mas ela pode ocupar esse espaço com imagens, áudio

e dados, por exemplo. A própria emissora é quem define o que será transmitido.

A digitalização permitirá um transporte maior de informações, e, com isso, o vídeo e o

áudio poderão possuir uma melhor qualidade. A começar pelo tamanho da tela de vídeo. Hoje

em dia, usa-se a proporção 4:3, entretanto, com a difusão das televisões widescreen e com a

Page 18: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

18

melhoria da qualidade dos vídeos transmitidos, a resolução 16:9, com proporções de cinema,

tende a se tornar padrão.

Figura 2: Comparação entre área da televisão comum (4:3) com o padrão HDTV (16:9)

O vídeo transmitido na maior qualidade, recebe o nome de HDTV (High Definition

Television). Com tela em formato 16:9, usa áudio estéreo 5.1 e qualidade de imagem que

pode ser de 720 linhas x 1280 pixels/linha ou 1080 linhas x 1920 pixels/linha. O vídeo no

formato EDTV (Enhanced Definition Television) também segue padrão de 16:9 e áudio 5.1,

porém o tamanho da tela é bem inferior, sendo de 480 linhas x 720 pixels/linha. É

considerado o padrão médio entre o HDTV e o SDTV (Standard Definition Television), o

formato padrão, com resolução 4:3, tela de tamanho 480 linhas x 680 pixels/linha e 60

quadros por segundo. Além desses, ainda há o LDTV (Low Definition Television), um padrão

voltado para dispositivos móveis. Com 30 quadros por segundo, o LDTV possui tela com

tamanho de apenas 240 linhas x 320 pixels/linha (Fernandes et al., 2004).

A transmissão de dados também irá permitir uma maior interatividade do usuário com

a televisão. Ele poderá votar em enquetes realizadas pelos programas, saber mais informações

da atração ou da programação do canal e até mesmo comprar produtos relacionados com o

que estiver sendo transmitido.

Por esse motivo a televisão digital não deve ser encarada como apenas uma melhoria

da televisão analógica, e sim como uma mudança de paradigma. Ela é uma nova plataforma,

com novas funcionalidades e com potencial para revolucionar a forma que a sociedade assiste

televisão, pois adicionará interatividade.

Diversas tecnologias têm surgido nos últimos anos de forma a tentar reproduzir, na

televisão analógica, as vantagens que a televisão digital trará. Empresas de transmissão de

Page 19: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

19

canais pagos já possuem suas versões digitais que exibem dados sobre a programação para os

telespectadores. A LG lançou recentemente uma televisão que contém internamente um disco

rígido de 80GB que consegue gravar a programação para ser exibida posteriormente.

Nos Estados Unidos há uma espécie de televisão interativa chamada TiVo (Gartner,

2005). Trata-se de um aparelho instalado no televisor que permite não só que os usuários

gravem e assistam seus programas favoritos na hora que quiserem, mas também que criem

uma programação de acordo com seus gostos. É possível, por exemplo, criar um canal só de

desenhos. O aparelho se encarrega de verificar a programação dos canais disponíveis e gravar

o que se adequar aos filtros definidos pelo próprio usuário. Através de uma linha telefônica, o

TiVo também se conecta à internet. Dessa forma, ele consegue trazer para a televisão

informações personalizadas pelo usuário.

Algumas promessas da televisão digital já são uma realidade em alguns lugares do

mundo, mas são conseguidas através de aparelhos anexados às televisões com HDs internos

para armazenamento dos vídeos e que assim, conseguem simular essa tecnologia que está por

vir, na trasmissão analógica convencional. A televisão de alta definição, por sua vez, também

já é uma realidade no Japão, onde, em 1º de dezembro de 2000, a NHK, que iniciou as

pesquisas da tecnologia, fez a primeira transmissão em HDTV. Entretanto há elementos que

ainda não conseguem ser reproduzidos com a transmissão analógica. Principalmente no que

diz respeito à interação do usuário com o que está sendo transmitido.

Com a transmissão digital, será possível o envio de diversos canais de vídeo e áudio.

Assim, será possível escolher se o filme será transmitido dublado ou legendado, e ainda o

idioma das legendas. Em um show ou jogo de futebol, haverá a disponibilidade de vários

ângulos de câmera para que o telespectador escolha a que mais lhe agradar. A interatividade

estará presente na própria programação, mesmo sem a necessidade de envio de um sinal de

retorno, ou seja, informação vinda das casas dos telespectadores à emissora. Para uso de todas

as funcionalidades prometidas pela televisão digital, entretanto, é necessária a existência de

uma forma de retornar o sinal. O consenso atual é que a forma escolhida seria a internet. A

televisão - ou o Set-Top-Box, aparelho que reproduz o sinal digital nos televisores

convencionais - teria que ser conectado à linha telefônica, ou a redes domésticas conectadas à

internet.

Há três formas de transmissão do sinal: transmissão terrestre, através de cabo ou a

transmissão via satélite. No caso do cabo, esse retorno do sinal pode ser realizado sem o uso

da internet. O cabo já vem sendo usado há algum tempo na televisão analógica e suporta

atualmente uma banda de até 550 MHz. Nos sistemas de transmissão analógica via cabo

Page 20: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

20

atuais, o sinal é embaralhado e decodificado nas residências. O embaralhamento é feito para,

por exemplo, limitar a quantidade de canais de um usuário. Um sinal é inserido na

transmissão, levemente deslocado da freqüência e o sinal é retirado com o uso do

decodificador. A televisão digital utiliza uma forma mais segura que o embaralhamento: a

codificação. O sinal é enviado codificado e decodificado nas residências através do uso de

uma chave apropriada. Caso não haja chave para decodificação, ao invés de um sinal

embaralhado, a televisão pode exibir propagandas ou uma tela qualquer. O sistema de

transmissão via cabo, porém, apresenta grandes desvantagens, como o alto custo e a

dificuldade de implantação em regiões remotas, bem como sua disseminação local.

Para essas regiões mais afastadas das grandes cidades, a transmissão por satélite

apresenta uma ótima solução. Ela é eficaz porque o satélite possui uma área de alcance muito

maior que as antenas de transmissão terrestre. Os dados são enviados e recebidos ao satélite

com o uso de antenas chamadas “parabólicas de satélite”. Os satélites de televisão mantém-se

em órbita geossíncrona em relação à Terra, o que quer dizer que o movimento deles

acompanha o movimento de rotação da Terra. Dessa forma, as parabólicas para recepção de

sinal de televisão por satélite só precisam ser ajustadas uma vez que continuarão recebendo o

sinal.

Porém é a transmissão terrestre que deverá ser usada para a transmissão digital, graças

ao seu baixo custo. Além disso, não há necessidade de se pagar assinaturas às emissoras.

Através de grandes antenas, os sinais são transmitidos por ondas de radiofreqüência pelo ar e

podem ser captados nas residências através de receptores apropriados, assim como é

transmitido o sinal de televisão analógica pública.

Além da forma de transmissão, é necessário também realizar a escolha do padrão de

televisão digital a ser usado (Fernandes et al., 2004). O padrão escolhido decidirá o método a

ser usado em cada uma das três etapas principais da transmissão digital.

• A codificação do sinal, que converterá o áudio e vídeo para sinais digitais. É

consenso entre os três padrões de que a codificação usada nessa etapa será em

vídeo MPEG.

• A multiplexação é a segunda etapa. Ela se encarrega de transformar os sinais que

foram digitalizados de áudio, vídeo e dados em um único feixe digital.

• A modulação é a etapa que se encarrega de converter o feixe digital gerado na

multiplexação em um ou mais sinais que poderiam ser transmitidos usando uma

das três formas descritas (terrestre, satélite ou cabo).

Page 21: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

21

1.2 – Padrões de transmissão digital

Na figura a seguir, são representadas as interações entre as diversas estapas para que a

transmissão do sinal digital seja efetuada a partir de um vídeo analógico:

Figura 3: Etapas para converter um vídeo analógico em um sinal de televisão digital

1.2.1 - Padrões para Codificação e Compressão

É a etapa responsável por converter o vídeo analógico para arquivos de áudio e vídeo

digitais. Todos os sistemas já definiram como padrão para codificação e compressão do vídeo

o MPEG-2, criado em 1992 pelo Moving Picture Experts Group. Ele se divide, na verdade em

um grupo de padrões de compressão de vídeo, áudio, identificação de objetos multimídia,

entre outros. O MPEG, estabelece um conjunto de padrões, entre os quais se encontram o

MPEG-2, MPEG-4, MPEG-7 e MPEG-21, estes dois últimos provendo algumas

funcionalidades úteis para a televisão digital e que serão utilizadas neste trabalho.

Uma das características do MPEG é o fato de o custo de codificação ser muito maior

que o custo de decodificação. Assim, num sistema de televisão, por exemplo, o maior custo

cabe às emissoras transmissoras do vídeo, enquanto a decodificação pode ser feita num

receptor mais barato. Detalhes sobre o padrão MPEG, sua codificação e suas funcionalidades

serão explorados no capítulo 2.

1.2.2 - Padrão para Multiplexação e Transporte

As informações de áudio, vídeo e outros dados são agrupadas em fluxos de programa.

A multiplexação se encarrega de converter todos os fluxos de programa em um único fluxo de

transporte denominado Transport Stream, usando padrão MPEG-2 TS. Cada pacote gerado

pela multiplexação possui tamanho fixo de 188 bytes. Isso ocorre para facilitar o processo de

tratamento de erros, além de aumentar a velocidade do processamento. Cada pacote possui

Page 22: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

22

obrigatoriamente um header de no mínimo 4 bytes. Cada header possui um campo

denominado PID (Packet Identifier), usado para a indentificação do pacote. Os bytes

posteriores são a carga do pacote ou PES (Packetized Elementary Stream).

Como os pacotes possuem tamanho fixo, o primeiro byte de cada pacote é chamado

“byte de sincronismo” e é usado na verificação de erros. Assim, ele verifica o byte encontrado

a cada 188 bytes e confere para ver se é o valor fixo correspondente ao byte de sincronismo.

Os pacotes de transporte estão sujeitos a erros ou interferências. Quando esses erros

são detectados, um bit do pacote é alterado de forma a informar o demultiplexador que aquele

pacote contém erros. Esse bit se encontra no header do pacote e é usado especificamente para

a deteccção de erros.

Uma seqüência de pacotes resultante de uma multiplexação pode ser multiplexada

novamente. Caberá ao receptor fazer o processo inverso, demultiplexar a seqüência e entregar

os itens corretos para seus respectivos decodificadores.

1.2.3 - Padrões para Modulação e Transmissão

A modulação se encarrega de deixar o feixe de dados gerado na multiplexação em um

ou mais sinais que possam ser transmitidos. Há dois métodos principais de modulação: o 8-

VSB e o COFDM.

O padrão 8-VSB (Eight Vestigial Side Band) usa uma única portadora e um único eixo

de modulação para simplificar os circuitos do receptor. Uma portadora é um sinal analógico

em forma de onda que representa a informação a ser transmitida. O fluxo de bits resultante da

multiplexação é embaralhado, de forma a espalhar melhor a energia, sem concentrar muito em

determinados pontos. É feita uma codificação para correção de erros e os bits são entrelaçados

para evitar a perda de vários segmentos inteiros.

O COFDM (Coded Orthogonal Frequency-Division Multiplexing) usa um sistema de

multiportadoras. Assim, a modulação quebra um fluxo de dados em diversos fluxos paralelos,

com taxas menores e usa diversas subportadoras para transmitir todos os fluxos de dados

simultaneamente. Para fazer essa transmissão, o espaçamento de freqüência das ondas das

portadoras é feito de forma que uma seja ortogonal a outra, de forma que uma não consiga

interferir na outra.

A modulação COFDM usa ainda um sistema de detecção de erros. A modulação é

comumente feita usando transformada rápida de Fourier. Uma das vantagens que ele

apresenta sobre a modulação 8-VSB é no que diz respeito à transmissão em cidades com

Page 23: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

23

grandes diferenças geográficas, como São Paulo, com densidade de edifícios, produzindo

padrões de sombra e multipercurso, que são prejudiciais à propagação UHF.

1.3 - Arquitetura da Televisão Digital Interativa

A arquitetura de um sistema de televisão digital é composta por camadas, tanto do

lado do provedor de serviços de televisão, quanto do lado cliente. Estas camadas apenas se

comunicam com as camadas diretamente superiores ou inferiores a elas, e cada padrão de

televisão digital implementa cada camada da sua própria maneira, já que o único consenso

entre os padrões foi a adoção de um padrão MPEG, que atende às expectativas de compressão

necessárias para a transmissão de vídeos de alta definição com baixo consumo de banda. A

figura abaixo representa tais camadas (Paes, Antoniazzi, 2005) e (Fernandes et al., 2004):

Figura 4: Processo de transmissão e recepção de dados da Televisão Digital

Do lado do provedor de serviços, o conteúdo é produzido e enviado à camada de

middleware através de aplicações próprias para o broadcast. Em seguida, o corre a

compressão desse conteúdo, e a multiplexação feita pela camada de transporte. Nesta etapa,

áudio, vídeo e dados viram um único elemento, que será chamado de serviço. Este serviço

será enviado para modulação e transmitido de acordo com o meio de transmissão adotado.

No lado cliente, tais camadas são implementadas dentro de um computador

denominado STB (Set-Top-Box), que pode estar embutido dentro da própria televisão. O STB

Page 24: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

24

possui memória, processador, disco de armazenamento e uma série de componentes também

presentes em microcomputadores.

Tal aparelho tem a função de realizar a receptação deste sinal de televisão digital, seja

qual for o meio de transmissão, e realizar a demodulação, transformando-o para a forma

lógica novamente. Em seguida, esses dados são demultiplexados, separando áudio, vídeo e

dados novamente, descomprimidos e então o sistema operacional e o middleware processam

essa informação. As informações de áudio e vídeo serão enviadas a um Controlador de Mídia

presente no middleware, que será responsável pela apresentação dessas informações ao

usuário, e os outros dados serão enviados a um subsistema denominado SI (Service

Information), responsável por disponibilizar aplicações aos usuários, exibir dados como

legenda, imagens estáticas, etc. Há ainda o Gerador de Carrossel, que é responsável por

estabelecer uma fluxo de dados entre o provedor de serviços e o STB, enquanto o serviço

estiver sintonizado. O gerador recebe este nome porque os fluxos de dados que geram o

sistema de arquivos precisam ser re-transmitidos ciclicamente, a fim de que seja possível a um

STB que sintonizou o serviço receber este sistema de arquivos, mesmo após o início da

difusão (Fernandes et al., 2004)

Para o maior aproveitamento da interatividade disponível nesta plataforma, é

necessário que o STB tenha um canal de retorno, ou seja, uma conexão com a internet, ou

com linha telefônica (há diversas outras maneiras propostas em (Oliveira, Albuquerque, 2005)

para que o STB possa enviar informações ao prestador de serviços, e não somente receber, o

que possibilita uma infinidade de novas aplicações para o cliente.

1.4 - Padrões de televisão digital

Atualmente há três padrões fazendo uma disputa pelos mercados dos países que ainda

não definiram o futuro de sua televisão digital. Todos os padrões adotam a tecnologia de

compressão de áudio de vídeo e de multiplexação do MPEG, devido à necessidade de

transferências de elevadas quantidades de dados. Como pode ser visto na tabela, todos estes

padrões utilizam a codificação MPEG-2 mas alguns padrões já estudam o uso codificações

diferentes como o MPEG-4 para obter taxas de compressão ainda maiores.

A tabela a seguir (Peng, 2002) compara alguns importantes aspectos dos padrões

DVB, ATSC e ISDB.

Page 25: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

25

Tabela 1: Comparação entre os padrões de televisão digital

Padrão Tipo Codificação do vídeo

Codificação do áudio

Banda utilizada

Taxa de transmissão (Mbps)

Países que adotaram

DVB DVB-S MPEG-2 MPEG-2/1 Digital Sound

8 Mhz 38 Europa, Austrália, Rússia, Taiwan, etc

DVB-T 24 15 (disp. móveis)

DVB-C 38 ATSC ATSC-T MPEG-2 AC-3 6 Mhz 19.28 América do

Norte, México, Argentina, etc

ATSC-C 38.57

ISDB ISDB-S MPEG-2 MPEG-2 AAC

34,5 Mhz 52 Japão, Brasil ISDB-T 5,6 Mhz 21.47

4.06 (disp. móveis)

ISDB-C 6 Mhz 31.644

1.4.1 - ATSC (Advanced Television Systems Committee)

O padrão foi adotado nos Estados Unidos, Canadá, Coréia do Sul, entre outros países.

Tem como intuito a melhoria na implementação da transmissão televisiva de alta definição, a

HDTV. Vêm sendo desenvolvido desde 1987 e está em uso nos Estados Unidos desde 1998.

Por ter sido o padrão pioneiro, este ainda tem problemas que já foram consertados nos outros,

principalmente no que diz respeito à transmissão para dispositivos móveis, que é o principal

ponto fraco deste padrão. Foi desenvolvido de forma a não sofrer interferência das

transmissões NTSC - as transmissões analógicas. Usa a modulação 8-VSB, o que garante uma

taxa de transmissão de aproximadamente 19,8Mbps (ATSC, 2004). O sinal de áudio usa

codificação Dolby AC-3 e o sinal de vídeo usa codificação MPEG-2 Vídeo, na qualidade de

HDTV.

Para a camada de middleware, que é a camada que faz a interação do software de

televisão digital com o hardware da Set-Top-Box, o ATSC usa o padrão DASE (DTV

Application Software Enviroment), que suporta a execução de aplicações JavaTV em seu

modelo procedural e, no seu modelo declarativo, faz uso de uma linguagem chamada ACAP

(Advanced Common Application Platform), que possui um formato parecido com a

linguagem HTML.

Entre os seus formatos de exibição de vídeo estão o 1080i e o 720p, ambos formatos

de vídeo em alta qualidade com tela de proporções 16:9. O formato 1080i exibe em uma tela

Page 26: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

26

de 1080 pixels verticais por 1920 pixels horizontais. O formato de 720p possui uma tela de

exibição menos - de 720 pixels verticais por 1280 pixels horizontais -, entretanto, possui uma

taxa de atualização da tela de 60 quadros por segundo - duas vezes maior que o formato

1080i.

1.4.2 - DVB (Digital Vídeo Broadcasting)

O padrão DVB já é adotado pela Europa, Austrália, Índia, África do Sul, entre outros

países. Iniciado em 1993, a partir de uma equipe de 300 membros, entre fabricantes,

emissoras de televisão, desenvolvedores de software e orgãos de regulamentação. Por padrão,

funciona transmitindo em um canal de 7Mhz, mas possui também suporte a canais de 6Mhz e

8 Mhz. Através da modulação COFDM (Coded Orthogonal Frequency Division

Multiplexing), este padrão permite taxas de transmissão que variam entre 3,74Mbps e

23,75Mbps. (DVB, 2004)

Com formatos que variam de 240 a 1080 linhas, este padrão permite que seja

simultaneamente feita transmissão de HDTV e transmissão para dispositivos móveis. O

enfoque do DVB é diversificar a quantidade de programas e serviços. Assim, o padrão

permite uma maior quantidade de operadoras de transmissão.

O áudio é codificado em formato MPEG2-BC e o vídeo usa MPEG-2 Video na

qualidade standard.

O padrão de middleware é chamado MHP (Multimedia Home Plataform) e permite

funcionalidades como o uso de um canal de retorno, permitindo o feedback das residências às

emissoras de televisão. Assim como o padrão DASE, do ATSC, este padrão de middleware

permite o uso de aplicações JavaTV em seu modelo procedural e o uso de uma linguagem

parecida com o HTML em seu modelo declarativo, o DVB-HTML.

1.4.3 - ISDB (Integrated Services Digital Broadcasting)

O padrão japonês de televisão digital. Foi criado em 1997, pelo grupo DiBEG (Digital

Broadcasting Experts Group). Surgiu a partir do padrão europeu DVB, sendo muito parecido

com ele. Destaca-se principalmente na área da transmissão digital para dispositivos móveis

(ISDB, 1998).

Usa o mesmo padrão de modulação do DVB, o COFDM, que permite uma taxa de

transmissão de dados entre 3,65Mbps e 23,23 Mbps. Possui melhorias em relação ao DVB no

que diz respeito à interferência dos sinais móveis com a transmissão de televisão em alta

Page 27: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

27

qualidade. O áudio é codificado em padrão MPEG-2 ACC (Advanced Audio Coding) e o

vídeo é codificado em MPEG-2 Video, com qualidade HDTV.

O middleware adota uma plataforma denominada ARIB (Association of Radio

Industries and Business), que usa em seu modelo declarativo uma linguagem semelhante ao

XML, denominada BML (Broadcast Markup Language).

1.4.4 - Padrão Brasileiro

Alguns países, entretanto, não pretendem aderir a nenhum dos padrões já existentes,

criando seu próprio. A China é um exemplo, desenvolvendo atualmente o DMB-T (Digital

Media Broadcasting Terrestrial).

O Brasil é outro país que pretendia, ao invés de escolher um dos padrões, desenvolver

um padrão próprio para o mercado brasileiro. A Sociedade de Engenharia de Televisão (SET)

começou em novembro de 2003 a criação do que foi chamado SBTVD (Sistema Brasileiro de

Televisão Digital) e, depois renomeado para ISDTV (International System for Digital TV).

A tecnologia brasileira seguia bem adiantada. Os sistemas “SORCER” e “MI-

SBTVD” foram desenvolvidos pela Pontifícia Universidade Católica do Rio Grande do Sul

(PUC-RS) e pelo Instituto Nacional de Telecomunicações (Inatel) para realizar a modulação

da televisão digital brasileira. O middleware recebia o nome de “Ginga” e já estava

desenvolvido, sendo uma unificação do sistema declarativo “Maestro”, desenvolvido pela

Pontifícia Universidade Católica do Rio de Janeiro (PUC-RJ) com o sistema procedural

“FlexTV”, desenvolvido pela Universidade Federal da Paraíba (UFPB).

Os padrões de codificação de áudio e vídeo ainda não estavam definidos, e ainda assim

o sistema apresentava ótimos resultados em comparação com os demais apresentados.

Entretanto, o governo brasileiro anunciou em 2006 que o padrão que seria adotado nas

transmissões digitais de televisão no Brasil seria o padrão japonês, o ISDB. A escolha gerou

críticas pelo fato de ser um padrão que privilegia em alguns aspectos as emissoras de

televisão. É o padrão, porém, que obteve os melhores resultados nas pesquisas da Anatel.

As promessas são para que em 10 anos o sistema digital esteja completamente

implantado no país. A transmissão analógica, entretanto, ainda deverá permanecer por mais

algum tempo. Os televisores atuais ainda não possuem capacidade de executar a transmissão

digital. Assim, têm-se a necessidade de uso de um aparelho que possa codificar o sinal digital

para ser transmitido nas televisões, o Set-Top-Box, enquanto as televisões ainda não saírem

de fábrica com a funcionalidade deste aparelho. Por um tempo, entretanto, a televisão digital

Page 28: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

28

seria transmitida juntamente com a televisão analógica, para que a nova tecnologia possa se

firmar gradativamente.

Alguns outros grandes problemas ainda não têm solução aparente. Para uso completo

de todas as funcionalidades esperadas, por exemplo, seria necessário o retorno do sinal, das

residências às emissoras de televisão. Num país onde apenas 20% da população têm acesso à

Internet, uma grande parcela - especialmente a mais pobre - não poderia usufruir de todas as

funcionalidades prometidas.

As mudanças com a chegada da televisão digital também atingem a gravação dos

programas. Com programas sendo transmitidos em qualidade altíssima, os equipamentos de

gravação teriam que ser melhorados para conseguir melhor qualidade de imagem. As câmeras

atualmente usadas nas gravações não suportariam a qualidade da imagem que seria

apresentada.

1.5 - Middlewares

Middleware é um termo genérico usado para representar softwares que interagem com

o sistema operacional, hardware e alguns protocolos de comunicação, trabalhando como

mediadores dessas funcionalidades para outras aplicações. Suas principais funções são:

• Esconder a distribuição do sistema para o usuário;

• Esconder a heterogeneidade de componentes de hardware, sistemas operacionais e

protocolos de comunicação;

• Fornecer interfaces de alto nível para desenvolvedores, de modo a facilitar o

processo de desenvolvimento.

No caso da televisão digital, existem diferentes padrões, cada um fornecendo STBs

diferentes, onde as características de hardware e até mesmo o sistema operacional dos

mesmos variam (levando em consideração que a única característica igual entre os padrões é a

adoção ao padrão MPEG), a taxa de transferência e a freqüência utilizada pelos padrões

também, enfim, há muita heterogeneidade entre eles, tornando este ambiente propício ao uso

de middleware, pois desenvolver uma aplicação portável entre vários padrões de televisão

digital sem middlewares geraria um elevado custo e perda de tempo, análogo a desenvolver

uma aplicação em C++ e outra em Java com a mesma funcionalidade. A própria

interatividade da televisão digital, com imagens, textos, gráficos, faz com que o middleware

se torne necessário, para que os desenvolvedores não se preocupem com as camadas mais

baixas da plataforma.

Page 29: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

29

Para facilitar o desenvolvimento de aplicações nesta plataforma, e tornar as aplicações

mais portáveis, os STBs devem prover uma API (Application Programming Interface)

genérica bem definida, com o intuito de abstrair um pouco dessa heterogeneidade presente

para outras aplicações (Fernandes et al., 2004).

Os benefícios do uso de um middleware não se fazem necessários só no front-end

(STBs), mas também no back-end em características como: conversão de conteúdo Web para

televisão, proxy, segurança, gerenciamento do assinante, etc. (Paes, Antoniazzi, 2005)

Devido a essa grande quantidade de benefícios, os órgãos que projetam os padrões de

televisão digital também desenvolvem seu próprio middleware, de forma com que este

funcione melhor com as características pré-estabelecidas no padrão. Desta forma, o padrão

DVB desenvolveu o middleware MHP (Multimedia Home Platform), o ATSC desenvolveu o

DASE (DTV Application Software Environment) e o ISDB desenvolveu o ARIB (Association

of RadioIndustries and Businesses).

A figura de (Paes, Antoniazzi, 2005) apresenta a estrutura do modelo funcional do

middleware para televisão Digital.

Figura 5: Estrutura do modelo funcional de um middleware

• Porting Layer – camada entre os drivers e o Middleware;

• Network Layer – responsável pelo gerenciamento do transporte, comandos e

controles da rede;

Page 30: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

30

• Security – integra a autenticação do usuário com os propósitos do CAS e DRM

(Digital Rigths Management);

• Kernel – é o cérebro do STB. Gerencia os arquivos do sistema, a memória e

acodificação de audio e vídeo;

• Presentation Control – atua na experiência do usuário que assiste a televisão;

• Application Management Layer – gerencia o conteúdo, os serviços da plataforma

interativa e os aplicativos.

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

aplicações para tal plataforma é a facilidade; porém, portar um software entre estes

middlewares pode ter uma tarefa mais complicada, e o software pode precisar de alguns

ajustes. Para facilitar um pouco esta tarefa, estes middlewares usam diversas funcionalidades

de outros blocos fundamentais. Destacam-se: DAVIC, HAVi e Java TV, cujos detalhes serão

explicados a seguir. Assim, a tarefa de portar aplicações entre diferentes padrões de televisão

digital é ligeiramente facilitada.

1.5.1 – Blocos Fundamentais

1.5.1.1 – DAVIC

DAVIC (Digital Audio-Visual Council) é uma associação de diversas empresas do

setor áudio-visual, órgãos de pesquisa, órgãos do governo e prestadores de serviços de

telecomunicações e televisão criada em 1994 e que durante 5 anos desenvolveu um padrão

para a interoperabilidade de comunicação multimídia e difusão de dados áudio-visuais

interativos. (DAVIC, 1999)

Seu objetivo era facilitar o desenvolvimento de aplicações áudio-visuais e sua

interoperabilidade especificando padrões de interfaces e protocolos a serem utilizados. Sua

última especificação, a 1.5, passou a englobar aplicações e serviços para televisão interativa.

As APIs definidas nesta especificação abrangem controle de acesso, filtragem de

informações, notificação, acesso a informações do serviço e controle de sintonização

(Fernandes, 2004). Para oferecer suporte à televisão interativa, a especificação apenas

acrescentou protocolos na parte de rede e controle, sem nenhuma modificação nas APIs ou

outros protocolos de níveis mais alto. Suas principais APIs são (DAVIC, 1999):

• MPEG-2 Section Filter API – serve para acessar dados anexos ao MPEG-2, como

metadados de outros padrões MPEG por exemplo;

Page 31: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

31

• Resource Notification API – serve para o gerenciamento de recursos em um

ambiente limitado, como um STB por exemplo;

• MPEG Component API – serve para representar os componentes básicos do

MPEG

• Tuning API – provê um mecanismo para seleção de serviços através da

sintonização de diferentes streams MPEG-2

• Conditional Access API – prove uma interface de acesso à algumas funções

específicas como EPG(Eletronic Program Guide) com a possibilidade de controle

desse acesso

• Media Player API – fornece controle da execução do vídeo em tempo real,

baseado na JMF (Java Media Framework)

• DSM-CC User-to-Network API – fornece uma aplicação para controlar sessões de

usuários

A especificação ainda conta com uma extensão de API para tratamento de interface

para o usuário, utilizando o pacote AWT já disponível na API do Java.

1.5.1.2 – HAVi

HAVi (Home Audio Video interoperability) é uma iniciativa de 8 grandes fabricantes

de produtos eletrônicos que visa fornecer uma especificação para a interoperabilidade entre

dispositivos de áudio e vídeo dispostos em uma rede doméstica. Propõe uma rede onde

dispositivos de áudio e vídeo tenham controle sobre outros dispositivos de áudio e vídeo,

independentemente da configuração do dispositivo ou outro elemento de rede (HAVI, 1999).

Desta forma, qualquer elemento desta rede terá a possibilidade de exercer controle sobre outro

elemento.

Com esta arquitetura é possível fazer com que dispositivos de diferentes marcas

interajam entre si, já que é uma arquitetura de especificação aberta, independente de

plataforma ou linguagem de programação. Assim, é possível fazer dispositivos se

comunicarem, mesmo sem utilizarem o mesmo sistema operacional ou linguagem de

programação, por exemplo. Basta que todos implementem uma versão desta arquitetura e

usem a API definida pela especificação.

A rede escolhida para suportar dados multimídia e troca de comandos entre os

dispositivos foi a IEEE-1394, também conhecida como Firewire. Este tipo de rede tem a

capacidade de transportar 400Mb/s e tem a vantagem de suportar comunicação síncrona,

tornando possível que dados multimídia sejam transferidos em tempo real. Versões desta rede

Page 32: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

32

utilizando tecnologia wireless, linhas telefônicas, entre outras, foram previstas desde o

começo da especificação HAVi, possibilitando que adaptações para as mesmas possam ser

desenvolvidas.

HAVi é uma arquitetura de software distribuído que implementa elementos como

controle de rede, abstração de dispositivo, comunicação entre dispositivos e ainda a interface

para o usuário (HAVI, 1999), que juntos, formam uma API para a interoperabilidade desta

arquitetura. Os elementos de software sao:

• 1394 Communication Media Manager – possibilita comunicação síncrona e

assíncrona

• Messaging System – responsável pela troca de mensagens entre elementos

• Registry – provê services de busca de outros elementos, bem como a detecção de

suas propriedades

• Event Manager – serviço que dispara eventos

• Stream Manager – gerencia as transferências de áudio e vídeo da rede

• Resource Manager – facilita o compartilhamento e agendamento de ações

• DCM (Device Control Module) – representa um dispositivo na rede e expõe sua

API

• FCM (Functional Component Module) – representa cada função disponível em um

DCM

• DCM Manager – responsável pela instalação e desinstalação de dispositivos na

rede

• Applications – aplicações precisam ser conhecidas pela rede antes de interagirem

Além destes elementos de software, a arquitetura apresenta alguns elementos de software

especiais para lidar com a interface com o usuário. São eles:

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

aplicações e DCMs quando uma interface precisa ser exibida lado a lado com umo

próprio display do aparelho

• Havlet – usada para desenhar interface para o usuário na tela de um dispositivo

Um bom exemplo de uso desta arquitetura, do lado cliente, é uma solicitação de

agendamento para gravação de conteúdo televisivo, feito a partir da televisão, para um DVD-

Recorder. Porém, se na hora da gravação a televisão estiver desligada desta rede, o gravador

poderá buscar outro dispositivo capaz de auxiliá-lo a realizar esta tarefa.

Page 33: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

33

1.5.1.3 - Java TV API

Em março de 1998, a Sun Microsystems anunciou a Java TV API, definindo uma

plataforma totalmente Java para televisão digital (Morris et al., 2005). Parte deste trabalho foi

padronizar o uso de APIs já existentes para o uso na televisão digital, como a JMF (Java

Multimedia Framework), que é usada para o gerenciamento do fluxo de áudio de vídeo, e a

outra parte deste trabalho foi criar novos pacotes que atendessem às necessidades de

características específicas da plataforma que foram surgindo à medida em que a tecnologia de

televisão digital e o conceito de interatividade envolvido, evoluía. Atualmente, esta API é

distribuída com o pacote J2ME.

Oferece uma plataforma de desenvolvimento bastante rica em recursos específicos

para os recentes avanços tecnológicos em televisão digital, podendo acessar e controlar

algumas funcionalidades da mesma, assim como controle de acesso, seleção de conteúdo,

controle de canais, streaming de áudio e vídeo, acesso aos canais de entrada e saída de dados,

informações do serviço (análogo ao canal de televisão) e ainda proporcionar a criação de

elementos visuais por cima do vídeo que está sendo exibido para o telespectador. Um serviço

é caracterizado por um conjunto de informações (Service Information) e as informações sobre

os serviços disponíveis são armazenadas em um banco de dados específico (SI Database)

(Fernandes et al., 2004).

Além disso, acrescentará funcionalidades como sincronização de conteúdo interativo

da televisão digital com o vídeo e o áudio de um determinado programa de televisão, e

também o controle do ciclo de vida de uma aplicação, que poderá existir ao mesmo tempo em

que os programas de televisão, como anúncios, por exemplo. Desta forma é possível que o

telespectador aproveite ao máximo os novos recursos da televisão da era digital, alcançando

níveis de interatividade com tal meio de comunicação até então desconhecidos.

No lado do software, a Java TV API necessita de um sistema operacional real-time

com uma plataforma Java para ser executada. Em um nível mais elevado, um software

desenvolvido para um receptor de televisão digital pode utilizar os pacotes da Java TV API, e

ser executado sobre a plataforma Java. Sendo assim, o desenvolvedor tem a oportunidade de

oferecer ao telespectador conteúdo interativo, como anúncios de produtos, informações extras

sobre a programação, seleção de legendas, entre outras inúmeras novidades existentes nesta

plataforma. Em um nível mais baixo, o sistema operacional real-time contém diversos drivers

e bibliotecas específicas de suporte ao hardware, bem como a estrutura necessária para a

execução da máquina virtual Java e outras bibliotecas incorporadas pela plataforma Java.

Page 34: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

34

Uma característica importante da plataforma Java sobre este tipo de hardware é que ela

encapsula todas as funcionalidades que o sistema operacional expõe para o controle do

hardware.

No lado do hardware, a Java TV API roda sobre um hardware muito específico e

limitado, se comparado a um computador, que é o receptor de televisão digital. Este receptor

lida com o sinal de vídeo e de dados de acordo com o meio de transmissão e realiza tarefas

como sintonização, mudança de canal e demultiplexação dos dados. A Java TV API

proporciona uma abstração ao hardware do receptor, fornecendo pacotes suficientes para o

controle de tais operações, deixando que o desenvolvedor se preocupe apenas com o software

em si, e não com detalhes específicos da plataforma ou drivers para o controle do hardware.

Esta abstração é fundamental para o sucesso desta API, já que diferentes padrões de televisão

digital foram desenvolvidos, e continuam sendo aprimorados, gerando assim, algumas

derivações dos mesmos em uma grande escala. Tais padrões serão implantandos nestes

receptores, e cada um terá suas particularidades, e caberá ao fabricante do receptor adotá-lo e

adaptá-lo às especificações Java. Esta característica, há tempos está presente nos

computadores, como por exemplo, uma aplicação desenvolvida em Java sobre um sistema

operacional Mac é capaz de ser executada, da mesma forma, sobre um sistema operacional

Windows. A máquina virtual é residente no receptor e pode ser usada por outros blocos

fundamentais (Paes, Antoniazzi, 2005).

A figura abaixo caracteriza este ambiente de hardware e software para a Java TV API

quando implementada em um receptor de televisão digital. (Fernandes et al., 2004)

Figura 6: Pilha de software em um receptor de televisão digital

Page 35: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

35

Uma aplicação desenvolvida com a Java TV API é chamada xlet. Semelhante ao

Applet na web e ao Midlet nos dispositivos móveis, um xlet não precisa estar previamente

armazenado no STB para que seja executado, pois ele pode ser enviado da mesma forma

como o vídeo pelo canal de difusão, e posteriormente executado.

A figura a seguir mostra o ciclo de vida de uma aplicação xlet dentro de um STB.

(Fernandes et al., 2004)

Figura 7: Ciclo de vida de um xlet

Ao ser descarregado para o STB, a xlet encontra-se no estado Loaded. A seguir, pode

ser inicializada por um gerente de aplicação, que passa um objeto XletContext para a xlet, que

define seu contexto de execução, que por sua vez, possibilita que a xlet notifique o gerente de

aplicação sobre mudanças de estado, num mecanismo semelhante ao de callbacks adotados

em diversas plataformas. Após sua inicialização a xlet fica no estado Paused, onde ainda está

inoperante, e não retém informações do serviço. Neste estado, a xlet pode ser ativada e entrar

em execução com todas as suas funcionalidades, passando para o estado Active, e em qualquer

estado a xlet pode ser destruída.

O objetivo da Sun Microsystems ao desenvolver esta API é fazer com que as

necessidades dos fabricantes, desenvolvedores e distribuidores de conteúdo (canais de

televisão) sejam atendidas à medida que estes procuram por soluções seguras e portáveis, pois

diferentes tipos de receptores são desenvolvidos para trabalharem com diferentes padrões de

televisão digital. Alguns padrões de televisão digital já adotam esta API, tornando-a um

grande recurso para desenvolvedores de aplicações interativas.

1.5.1.4 – Microsoft TV

A Microsoft também faz um importante trabalho no desenvolvimento para a

plataforma de televisão digital. Eles possuem uma plataforma toda baseada em softwares

Page 36: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

36

próprios e buscam oferecer seu produto como uma alternativa à utilização da televisão digital

com outras APIs. Ao contrário da Java TV API é uma plataforma privada, e não de código

aberto. Por outro lado, é uma solução para integrar as diferentes tecnologias necessárias para

se ter um ambiente de televisão digital adequado, pois ao invés de usar APIs de interface

gráfica em conjunto com Java TV API, seria possível usar apenas as APIs da própria

Microsoft. Desta forma, o desenvolvedor encontra menos flexibilidade, porém mais facilidade

no desenvolvimento da aplicação.

Esta plataforma pode ser utilizada com diferentes meios de transmissão em que o sinal

de televisão digital é capaz de ser transmitido e possui funcionalidades como suporte à vídeos

de alta resolução, gravação de vídeo no formato digital e aquisição de vídeos sob demanda.

1.5.2 - Padrões

1.5.2.1 – MHP

MHP (Multimedia Home Platform) é o middleware desenvolvido pelo padrão de

televisão digital europeu, o DVB (DVB, 2004). Este middleware define uma interface

genérica entre as aplicações e o ambiente no qual essas aplicações são executadas, por

exemplo o STB, criando uma abstração entre as aplicações e o ambiente (hardware e

software) em que elas residem. Desta maneira as aplicações com base em MHP, serão

compatíveis com STBs, televisões com sistema digital integrado e computadores multimídia.

O MHP estende os padrões DVB para broadcast e serviços interativos em todos os

tipos de transmissão de sinal: cabo, terrestre, satélite, etc.

Sua arquitetura é definida em 3 camadas (DVB, 2004):

• Aplicações: como EPG, informações do serviço, jogos, e-commerce, transações

seguras e aplicações educacionais;

• Softwares de sistema: como o gerenciador de aplicações (ou navigator), outras

APIs, protocolos de transporte e máquinas virtuais, como a JVM;

• Recursos: como o processamento do MPEG, gráficos, entrada e saída de dados e

unidade de processamento.

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

procedural, que utiliza a máquina virtual Java. Toda aplicação baseada em MHP nesta forma,

deve usar softwares do sistema para acessar os recursos da plataforma através de APIs

especificadas. Dentre estas APIs estão os principais blocos fundamentais já descritos:

DAVIC, HAVi, Java TV. Na sua forma mais simples, a declarativa, dá suporte à uma

Page 37: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

37

linguagem declarativa baseada em HTML, denominada DVB-HTML (Paes, Antoniazzi,

2005).

O MHP possui três tipos de perfis para implementação das plataformas de

serviços(Paes, Antoniazzi, 2005):

• Enhanced Broadcast – suporte a recepção de áudio, vídeo e serviços de download

de aplicações de interatividade apenas local, pois não tem o canal de retorno,

também chamadas de one-way services. Possui suporte a DVB-HTML;

• Interactive Broadcast – possui todas as características do perfil Enhanced

Broadcast, com a vantagem de implementar um canal de retorno, deixando de ter

interatividade apenas local, podendo de comunicar com o serviço de broadcast ou

não; A comunicação é feita com a utilização do protocolo IP;

• Internet Access – possui todas as características do perfil Interactive Broadcast,

com a vantagem de poder se conectar à Internet. Desta forma, serviços como e-

mail tornam-se possíveis nesta plataforma.

Na primeira versão do middleware, 1.0, apenas os dois primeiros perfis estavam

disponíveis. Só na versão 1.1 surgiu o Internet Access.

1.5.2.2 – DASE

DASE(DTV Application Software Environment) é o middleware desenvolvido para o

padrão de televisão digital americano ATSC (ATSC, 2004). O middleware DASE interage

com a camada de transporte, de modo a transformar a informação recebida pelo broadcast em

saída de vídeo e áudio para a televisão acoplada.

Assim como as aplicações MHP, as aplicações DASE possuem forma declarativa e

procedural. Na forma declarativa as aplicações podem ser escritas em HTML, XHTML ou

mesmo XML e conter folhas de estilos, scripts, etc. E na forma procedural a aplicação pode

ser uma xlet da API Java TV e conter outros arquivos.

O middleware DASE possui um subsistema chamado DAE (Declarative Application

Environment) para realizar o processamento das aplicações declarativas. Este subsistema tem

um componente chave chamado DCDE (Declarative Content Decoding Engine) que atua

como analisador sintático XDML e interpretador de scripts e estilos. Já para as aplicações

procedurais, existe um subsistema chamado PAE (Procedural Declarative Application

Environment) para realizar tal tarefa, como por exemplo, a JVM.

A arquitetura proposta por esta especificação é basicamente composta por:

• DASE Content Model – são as aplicações DASE;

Page 38: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

38

• DASE Environment Model – representa o sistema DASE.

O sistema DASE é constituído pelos elementos a seguir especificados, direta ou

indiretamente com base nos mecanismos fornecidos pelo receptor (ATSC, 2004):

• Entrada de dados – o sistema deve suportar entrada de dados por parte do usuário;

• Áudio – o sistema deve suportar decodificação e apresentação do áudio em tempo

real;

• Vídeo – o sistema deve suportar decodificação e exibição do vídeo em tempo real;

• Gráficos – o sistema deve suportar decodificação e exibição de imagens estáticas,

ou seja, conteúdo visual que não seja vídeo, de acordo com resoluções pré-

estabelecidas;

• Modelo de exibição – o sistema deve apresentar o seguinte modelo de exibição:

Figura 8: Modelo de exibição DASE

No sistema de segurança do DASE, uma aplicação somente poderá executar algumas

operações privilegiadas se a aplicação fizer a chamada através da API do middleware e este,

através de uma política de segurança local, conceder a permissão.

1.5.2.3 – ARIB

ARIB (Association of Radio Industries and Businesses) é o middleware desenvolvido

pelo o padrão de televisão digital japonês ISDB (ISDB, 1998) para que seja efetuada a

comunicação entre sistema operacional, hardware e aplicações. Neste middleware foi criada

uma linguagem de marcação chamada BML (Broadcast Markup Language), que possui

estrutura semelhante à linguagem XML, para fazer o papel das aplicações declarativas.

No ARIB o modelo de exibição é mais elaborado, como na figura a seguir (Paes,

Antoniazzi, 2005):

Page 39: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

39

Figura 9: Modelo de exibição ARIB

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

2005):

• Serviços de conteúdo – apresentar legendas com superposição sobre o vídeo, como

definido no modelo de exibição; permitir assistir vídeo, áudio ou outras

informações interativas; considera as possibilidades de serviços e até mesmo o

público que irá adquirir os serviços;

• Serviços de acessibilidade – permitir agendamento de gravação através do EPG;

acesso dos controles pelo usuário, etc;

• Serviços de extensões – define a possibilidade de expandir as especificações no

futuro, considerando o estilo dos serviços, novas codificações, sistemas de acesso

e receptores;

• Interoperabilidade – permitir recepção de dados em qualquer STB que implemente

o middleware, por mais comum que seja; considera a integração com sistemas de

comunicações como alta prioridade;

• Capacidade de Controle – considera a flexibilidade de controle do sistema usando

a eficiência da capacidade de transmissão; considera as funções automáticas de

controle de recepção, como funções de emergência por exemplo;

• Erros de apresentação no display – sempre que possível, tratar os erros de

sobreposição de elementos visuais ou até mesmo áudio em uma faixa de tempo

suficientemente pequena para que o usuário não perceba.

Por enquanto pouquíssimos países são adeptos desta plataforma, portanto ela está

sendo reformulada de forma a ficar mais parecida com o MHP (Morris et al., 2005). Um dos

motivos que faz este padrão ser menos aceito no mercado pode ser a falta de aplicações do

tipo procedural, que restringem basante o ambiente do desenvolvedor.

Page 40: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

40

1.5.2.4 – Ginga

Ginga é o nome do middleware desenvolvido para trabalhar com o padrão brasileiro de

televisão digital, e destinado à transmissão terrestre. É o resultado do trabalho em conjunto de

diversos centros de pesquisa, destacando-se as universidades Pontifícia Universidade Católica

do Rio de Janeiro (PUC-Rio) e Universidade Federal da Paraíba (UFPB).

Este middleware também possui sua forma declarativa e sua forma procedural, assim

como é possível identificar nos outros middlewares apresentados. Na sua forma declarativa, é

denominado Ginga-ncl e define uma linguagem declarativa chamada NCL, capaz de

endereçar funcionalidades relativamente simples, no que diz respeito à interatividade,

sincronismo de objetos de mídia, suporte à diferentes tipos de dispositivos, entre outros.

Possui um mecanismo decodificador para esta linguagem NCL, suporte à navegação

XHTML, incluindo CSS e um interpretador ECMAScript, além de um mecanismo para

interpretar scripts LUA. (Filho et al, 2007)

Já em sua forma procedural, há um subsistema denominado Ginga-J, que se baseia na

linguagem Java para prover suas funcionalidades. Seu ambiente de execução é uma Máquina

Virtual Java (JVM) e aplicações sobre este middleware tem acesso à todos os recursos do

STB, além de possuir suporte à comunicações do tipo Bluetooth, Wi-fi, Ethernet, entre outras

formas. Provê funcionalidades básicas como acesso a fluxo de dados de baixo nível,

processamento do fluxo elementar de dados, componentes de interface, comunicação,

gerenciamento, persistência e acesso condicional.

Para prover compatibilidade com outros middlewares de outros padrões de televisão

digital, o Ginga é dividido em um conjunto de três APIs : A Verde, a Amarela e a Azul. A

API Verde é compatível com GEM (Globally Executable MHP), a API Amarela é usada para

satisfazer necessidades específicas para o mercado brasileiro e pode criar aplicações

compatíveis com middlewares como MHP através de uma adaptação do software para a API

Verde, desde que essas ferramentas de adaptação sejam enviadas anteriormente ao STB. Já a

API Azul produz aplicações que só são capazes de executar em um ambiente com middleware

Ginga.

Page 41: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

41

Capítulo 2 – MPEG MPEG (Moving Picture Experts Group) é o nome dado a uma família de padrões ISO

(International Organization for Standardization) que são usados para a codificação de

elementos áudio-visuais em um formato digital e comprimido. Tal família inclui os padrões

MPEG-1, MPEG-2, MPEG-4, MPEG-7 e MPEG-21 que serão vistos sob mais detalhes ao

longo deste capítulo. Esta família é constantemente atualizada para a adaptação às novas

tecnologias que surgem com o tempo e não só os padrões já existentes são atualizados, mas

também são criados novos padrões.

2.1 - Padrões

O Moving Picture Coding Experts Group iniciou seus trabalhos em 1988. O padrão

MPEG-2 foi iniciado em 1991 e publicado em 1995, sendo uma evolução do MPEG-1. O

MPEG-2 é descrito pelas especificações ISO/IEC 13818, que definem a forma de compressão

para o fluxo de dados do sistema (ISO, 2000a), para a compressão do vídeo (ISO, 2000b) e

para a compressão do áudio (ISO, 1998). A camada de compressão de fluxo de dados MPEG-

2 Systems segue as recomendações H.222.0 (ITU, 2000a) e a camada de compressão de vídeo

MPEG-2 Video segues as recomendações H.262 (ITU, 2000b) no âmbito do ITU-T

(International Telecommunication Union - Telecommunication Standardization Sector).

O objetivo do MPEG-2 é prover uma taxa de vídeo adequado para os sistemas de

televisão. Assim, a taxa de vídeo varia entre 1,5 Mbps e 30 Mbps, sendo até 15Mbps

adequados para o padrão SDTV e acima de 15 indicado para o padrão de HDTV.

O padrão MPEG-4 foi finalizado em 1998 e se tornou padrão internacional em 2000.

O surgimento desse novo padrão tornou-se necessário como forma de permitir a transmissão

pela internet de vídeos com a qualidade do MPEG-2, em arquivos menores. A portabilidade

criada com o MPEG-4 permite que os filmes sejam executados nos mais diversos tipos de

aparelhos, de celulares a televisores.

Para garantir essa interoperabilidade, diversas empresas, como Apple, IBM, Philips,

HP, Cisco, Sun, entre outras, se uniram para a criação do ISMA (Internet Streaming Media

Alliance), que define os padrões dos players que deverão rodar o MPEG-4. Devido à

capacidade do MPEG-4 de manter a qualidade do vídeo, mesmo a baixas taxas de

transmissão, o padrão também é usado em algumas transmissoras de televisão via satélite.

Page 42: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

42

O padrão MPEG-4 faz uso de um padrão de compressão denominado H.264, que

possibilita a apresentação da mesma qualidade do vídeo MPEG-2, porém usando apenas um

terço de taxa de dados.

O padrão MPEG-7, formalmente conhecido como Multimedia Content Description

Interface ou Interface para Descrição de Conteúdo Multimídia, disponibiliza ferramentas para

a descrição de conteúdo multimídia através de anotações em XML. Dessa forma é possível,

por exemplo, fazer com que a letra de uma música seja sincronizada com a própria música.

Assim como o MPEG-7, o MPEG-21 utiliza as anotações em XML embutidas dentro do

vídeo de forma bem semelhante. O MPEG-21, entretanto possui uma segurança maior, além

de outras funcionalidades, como proteger os direitos autorais dos vídeos e monitoria dos

estados de transmissão.

2.3 - MPEG-1

Aprovado inicialmente em 1991, o padrão MPEG-1 define a codificação de elementos

audiovisuais para mídias de armazenamento com capacidade de transferência de até 1,5Mbit/s

de dados. MPEG-1 foi o primeiro resultado dos esforços do grupo MPEG.

Este padrão foi definido em 5 partes. São elas (MPEG1, 1996) :

• Sistemas: caracteriza a combinação de uma ou mais streams de dados das partes de

áudio e vídeo definidas neste padrão juntamente com uma sincronização temporal,

tendo como resultado uma única stream. Desta maneira, facilita-se o

armazenamento e transmissão dos dados digitais;

• Vídeo: originou-se do padrão H.261 (definido na International Telecommucation

Union- ITU) e representa a codificação de vídeos de 625 e 525 linhas (similares

aos padrões de televisão analógica) em taxas de até 1,5Mbit/s. Nesta parte são

definidas algumas técnicas para se atingir um elevado nível de compressão do

vídeo, como selecionar uma resolução apropriada para o sinal, utilizar algoritmos

de compensação de movimento para reduzir a redundância temporal e por último a

aplicação da Transformada Discreta de Cosseno para compactar ainda mais os

quadros de interpolação e predição;

• Áudio: especifica uma compressão de seqüência de áudio mono ou estéreo.

Amostras de áudio são transferidas à um codificador, que caracteriza realiza

processos de filtragem e reamostragem do áudio de entrada, e com a ajuda da

codificação de Huffman cria símbolos de amostragem, compactando o áudio sem

que ruídos sejam adicionados. É dividido em três camadas, onde as duas primeiras

Page 43: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

43

especificam áudio de qualidade elevada, porém com alta complexidade no

momento da compressão, enquanto a terceira também consegue atingir alta

qualidade de maneira mais simplificada, sendo esta, mais usada em aplicações

digitais;

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

definidas acima;

• Software: uma implementação das três primeiras partes com código fonte fechado.

Tecnologias como Vídeo CDs (VCDs) e MPEG-1 Layer III (mais conhecido como

MP3) são os pontos fortes deste padrão. Este último vem sendo usado para comprimir áudio e

é a única parte deste padrão que ainda é encontrada com alta freqüência em dispositivos

digitais (como MP3 players, celulares, etc), devido ao seu baixo custo de armazenamento e

fidelidade para com o áudio original. A perda de qualidade do MP3 é praticamente

imperceptível.

2.4 - MPEG-2

Um arquivo no formato MPEG-2 divide-se em duas camadas. A camada de

compressão e a camada de sistema. A camada de sistema é a responsável pela multiplexação

do vídeo, ideal para a transmissão. A camada de compressão cuida da codificação e

compressão dos dados de áudio e vídeo.

2.4.1 - Camada de compressão

Os vídeos nada mais são do que um conjunto de imagens exibidas seqüencialmente.

Cada frame de um vídeo pode ser representado por três matrizes, sendo uma de luminância e

duas matrizes de crominância. A luminância é a componente do vídeo que contém somente as

informações de brilho – o preto e branco. A crominância contém as informações sobre as

cores da imagem. As informações de um quadro podem ser separadas nas linhas pares ou

ímpares que o compõem, em campos denominados top field e bottom field.

Uma figura codificada através de MPEG-2 pode representar um único quadro ou um

campo codificado. Se um sinal de vídeo contém figuras que representem campos, ele é

chamado de vídeo entrelaçado. Se o sinal de vídeo contiver figuras que representem apenas

quadros, ele é chamado de vídeo progressivo.

A principal diferença entre o vídeo entrelaçado e o vídeo progressivo é que, no vídeo

entrelaçado, a cada novo frame de vídeo, apenas metade dos pixels são atualizados,

Page 44: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

44

redesenhando apenas as linhas pares ou as ímpares – o top field ou o bottom field. Já no vídeo

progressivo, todas as linhas são atualizadas.

O olho humano é mais sensível a mudanças no brilho do que na cromaticidade. Por

isso a divisão do frame em uma matriz de luminância e duas de cromância é feita. As matrizes

de cromância acabam então, sofrendo uma compressão maior do que a matriz de luminância.

O habitual método de compressão usado é o Discrete Cosine Transform (DCT), ou

transformada discreta de Cosseno. A técnica reduz as componentes de alta-freqüência da

imagem, uma vez que o olho humano é mais sensível a reconstruções de componentes de

baixa-freqüência.

As imagens podem ser codificadas em três tipos diferentes de frames. Os Intra-Coded

Frames (I-frames) são codificados usando apenas informações contidas no próprio frame

original, não havendo dependência com frames anteriores ou posteriores. Como cada frame

pode ser considerado como uma imagem, a compressão de um I-frame é semelhante à

realizada em uma imagem de padrão JPEG, por exemplo. Os Predictive-Coded Frames (P-

frames) são codificados de forma preditiva em relação a um quadro I-frame ou a um quadro

P-frame anterior. Ou seja, há pelo menos um macrobloco presente no quadro que possui uma

dependência com algum macrobloco de outra figura. Já os Bidirectionally-Predictive-Coded

Frames (B-frames) são codificados de forma preditiva em relação aos quadros I-frame ou P-

frame anteriores ou posteriores. Dessa forma, pelo menos um macro bloco de um quadro B-

frame possui dependência com algum quadro posterior a ele. Logo, para uma codificação B-

frame, é necessário que o quadro posterior ao qual ele possui essa dependência já tenha sido

codificado (Cavendish, 2005).

Cada frame codificado possui o parâmetro temporal_reference, que funciona como um

contador, utilizado para que o decodificador consiga detectar eventuais perdas de frames.

Os algoritmos que realizam a compressão MPEG buscam reduzir a redundância

temporal que existe entre os frames consecutivos. Eles tentam, por exemplo, eliminar

elementos que são iguais em dois frames seqüenciais. O método consiste em calcular o erro

de predição entre os blocos nas imagens atuais e nas imagens anteriores.

Outro tipo de compressão possível é usando a predição por compensação de

movimento. É feita uma estimativa de movimento entre as imagens do vídeo e a codificação

gera uma translação de pixels entre as imagens. Esse método é feito realizando a comparação

de macrobloco de uma figura com macroblocos pertencentes a figuras vizinhas. O macrobloco

da figura vizinha que mais se identificar com o do frame que está sendo codificado será usado

como referência na operação de predição. Um vetor de movimento indicando a diferença de

Page 45: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

45

localização do macrobloco entre os dois frames é criado e transmitido junto com o

macrobloco codificado. Também é transmitida junto com o macrobloco, a posição em relação

ao macrobloco anterior, a indicação do método de predição e quais blocos de cromância e

luminância foram codificados.

Para facilitar a decodificação, a ordenação dos frames no fluxo é diferente da ordem

que os frames devem ser exibidos. Essa ordem garante que as figuras usadas como referência

pelos outros quadros sejam sempre recebidas antes dos quadros que as utilizam. Para a

exibição de um frame que usa codificação P-frame em referência a outro frame I-frame, é

necessário que o decodificador já tenha recebido o I-frame antes de decodificar o P-frame

(Cavendish, 2005).

Figura 10: Exemplo de ordem de apresentação em relação à ordem de codificação

A Figura 10 ilustra como deve ser a ordem. Como os frames 2 e 3 utilizam codificação

B-frame, que necessita dos frames posteriores para serem usados como referência (no caso, o

frame 4), o decodificador recebe primeiramente o frame 4 e depois os frames 2 e 3, que

possuem referência a ele.

Page 46: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

46

2.4.2 - Camada de Sistemas

Definida no MPEG-2 Systems - recomendações H.222.0 (ITU, 2000a) – a camada de

sistemas é responsável pela divisão e encapsulamento dos fluxos gerados na compressão em

pacotes e pela multiplexação desses pacotes. Além disso, mantém a sincronização entre os

fluxos de mídias diferentes e pelo transporte da informação de referência do relógio utilizado

no codificador.

Existem duas formas de multiplexação. O fluxo de programa (Program Stream)

otimiza a decodificação para ambientes com menor ocorrência de erros e contém só um

conjunto de fluxos elementares (como áudio, vídeo ou dados). É o fluxo utilizado, por

exemplo, em sistemas de armazenamento, como os DVDs. O fluxo de transporte (Transport

Stream) pode conter mais de um conjunto de fluxos elementares e é otimizado para ambientes

onde a ocorrência de erros é mais freqüente, como nas transmissões de televisão digital, muito

suscetíveis a ruídos.

Após a compressão, os fluxos elementares de vídeo são divididos em pacotes em uma

subcamada chamada PES (Packetized Elementary Stream). Essa camada realiza a

identificação dos pacotes através de um parâmetro Stream_ID. A camada PES ainda realiza

uma sincronização intra e intermídia, através da colocação de marcadores de tempo

(timestamps) nos fluxos de PES e nos fluxos de sistemas. As timestamps inseridas no fluxo de

sistemas na subcamada de multiplexação permitem ao decodificador a recuperação da

referência de tempo em relação ao relógio usado no codificador. Esses timestamps são

denominados System Clock Reference (SCR) para os fluxos de transporte e Program Clock

Reference (PCR) para os fluxos de programa e são definidos em termos de um relógio de

sistema comum denominado System Time Clock (STC). Os valores dessas marcas de tempo

SCR e PCR indicam o instante em que o último bit desses campos entra no decodificador

(Cavendish, 2005).

Após o empacotamento desses dados nas PES, alguns pacotes são escolhidos e

recebem novos marcadores de tempo. Entre esses timestamps, destacam-se o Presentation

Time Stamp (PTS), que indica o tempo em que a unidade de apresentação deve ser exibida, e

o Decoding Time Stamp (DTS), que indica o tempo em que a unidade de apresentação deve

ser entregue ao respectivo decodificador. O DTS é usado quando é necessária uma

reordenação dos quadros pelo decodificador.

Page 47: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

47

2.5 - MPEG-4

O MPEG-4 utiliza o padrão H.264, desenvolvido pela ITU-T Video Coding Experts

Group (VCEG) em conjunto com a Moving Pictures Experts Group (MPEG). Ele foi criado

com o intuito de fornecer uma qualidade de vídeo tão boa quanto a apresentada pelo MPEG-2,

mas gerando arquivos com apenas metade do tamanho. A implementação, entretanto, não

poderia ser muito complexa para não tornar o processo de codificação extremamente caro.

Para atingir seu objetivo, o MPEG-4 possui algumas diferenças em relação à

compressão. Ele permite, por exemplo, o uso de até 32 frames de referência, contra apenas 1

ou 2 frames nos métodos anteriores. Isso permite a geração de arquivos muito menores e

melhorias até na qualidade de imagem.

A técnica de predição por compensação de movimento também evoluiu bastante,

permitindo blocos com tamanho 4x4 e 16x16 e precisão de movimento dos blocos de até ¼ de

pixel. A performance também é amplamente melhorada nos efeitos de fade in e fade out.

Além disso, usa sistemas chamados de flexible macroblock reordering (ordenação dos

macroblocos flexível) e arbitrary slice ordering (ordenação arbitrária de fatias) para

reestruturar a maneira como os macroblocos são apresentados na imagem.

O H.264 ainda utiliza de duas técnicas de codificação denominadas “Codificação

aritmética binária adaptável segundo o contexto” (context-adaptive binary arithmetic coding,

CABAC) e “Codificação de comprimento variável adaptável segundo o contexto” (context-

adaptive variable-length coding, CAVLC), que usam algoritmos inteligentes para comprimir

streams de vídeo com perdas quase mínimas.

Há diversos novos meios de se evitar erros na codificação e decodificação também.

Entre eles, pode-se destacar a partição de dados, que permite separar pedaços mais

importantes e menos importantes da imagem em pacotes separados, permitindo que se faça

um controle maior de erros naqueles pedaços mais importantes. Usa também redundant slices,

(fatias redundantes) que permite que um codificador crie uma imagem extra – geralmente de

menor qualidade - de uma região de um frame, para ser usada se a representação preliminar

original do frame estiver corrompida.

Essas técnicas permitem que o MPEG-4 tenha um desempenho muito superior ao

MPEG-2, apresentando uma qualidade de vídeo semelhante – e, por vezes, até superior – com

arquivos que têm metade ou menos da metade do tamanho.

2.6 - MPEG-7

Page 48: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

48

Seguindo os mesmos princípios do MPEG-4, o grupo MPEG iniciou um projeto de

outro padrão, o MPEG-7. Seu intuito era de estabelecer descrições (ou anotações) para

conteúdos multimídia de forma a possibilitar que buscas, filtragens e outros processamentos

similares fossem realizados de forma mais rápida e eficiente. Tais anotações também são

chamadas de metadados.

Este padrão provê diversas ferramentas para auxiliar na descrição e gerenciamento do

conteúdo, organização e navegação. A descrição do conteúdo pode ser transmitida ou

acessada por um dispositivo ou programa de computador, e pode ter diferentes interpretações

dependendo do contexto da informação.

O MPEG-7 não está focado em apenas uma aplicação em particular, ao invés disso, os

elementos contidos no MPEG-7 dão suporte à uma larga escala de aplicações possíveis, pois

são bastante genéricas (MPEG7, 2004). A necessidade de uma ferramenta de descrição em

conteúdos multimídia está diretamente relacionada com a necessidade que as novas

tecnologias tem com relação à eficiência e rapidez.

Um grande conjunto de ferramentas de descrição são definidas, e ainda uma

linguagem própria, com sintaxe semelhante à linguagem de marcação XML, que possibilita

aos desenvolvedores expandir a funcionalidade do padrão. Há também uma série de outras

ferramentas de sistema relativas à distribuição final das anotações MPEG-7, que realizam a

preparação dos dados para a transmissão (Martinez et al, 2002).

As ferramentas de descrição são representadas por elementos com metadados,

estruturas e relacionamentos, definidos como descritores e esquemas de descrição. A

descrição de um conteúdo multimídia é feita através de descritores que possibilitam a

indexação e classificação das informações. O padrão MPEG-7 fornece ferramentas para

descrição de regiões estáticas, regiões temporais e até mesmo regiões dinâmicas, que se

movem, no caso de vídeos.

A especificação deste padrão, assim como nos outros padrões MPEG, também está

definida em partes, cujas principais são: sistema, Description Definition Language (DDL),

vídeo, áudio e Multimedia Description Schemes (MDS). Antes de explicar cada uma delas é

preciso conhecer cada uma das definições a seguir, retiradas de (Martinez, 2002) de acordo

com definições presentes na especificação do padrão:

• Descriptor (descritor) – representa uma característica. Um descritor define a

sintaxe e a semântica de uma representação de uma característica;

• Description Scheme (esquema de descrição) – define a estrutura e o significado da

relação entre componentes que podem ser descritores ou outro esquema descrição;

Page 49: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

49

• Description Definition Language (DDL, linguagem própria para definição de

descrições) – uma linguagem para definição ou alteração de descritores e

esquemas de descrição, provendo a possibilidade de expansão do padrão de acordo

com as necessidades do desenvolvedor;

• System Tools (ferramentas de sistema) – Ferramentas de apoio à multiplexação,

sincronização, transmissão e codificação (forma de texto e binária) das descrições

de maneira eficiente e proteção à propriedade intelectual.

A especificação define também uma implementação do software de referência da

especificação do padrão. Tal software é baseado em uma normalização com respeito ao

processo de decodificação, isto é, qualquer software produzido para trabalhar com este padrão

deve apresentar os mesmos resultados que o software de referência. Além disso, a

especificação define testes de conformidade e padrões para o uso e extração de descrições. Os

testes de conformidade, presentes em todos os padrões MPEG, especificam os métodos para

testes das descrições MPEG-7 para verificar se estão de acordo com o padrão, e os padrões

para uso e extração de descrições fornecem informações para extração de descrições das

streams MPEG e para o uso das ferramentas de descrição, utilizando o software de referência

mas também com outras abordagens (MPEG7, 2004).

2.6.1 - Sistemas MPEG-7

Esta parte especifica ferramentas de sistema para a preparação de descrições MPEG-7

para o transporte e armazenamento, viabilizando a sincronização com o conteúdo multimídia

de forma eficiente, além de atualizações e construção de descrições dinâmicas. Sistemas

MPEG-7 dispõe de todas as características necessárias para a representação de conteúdos

multimídia com descrições multiplexadas.

A entidade capaz de tratar tais informações são comumente chamadas de terminais (ou

MPEG-7 terminal) e podem ser representadas por aplicações independentes ou partes de um

outro sistema. A arquitetura desses terminais é dividida em três camadas: aplicação,

normalização (que é responsável pela sincronização e gerenciamento das descrições) e

distribuição (que é responsável pela abstração do meio transmissão e armazenamento

proporcionado por este padrão), conforme definido na especificação ISO do padrão (MPEG7,

2004). A distribuição herda características de outros padrões como o MPEG-4 e o MPEG-2

como o conceito de elementary streams. Essas streams consistem em pequenas partes

consecutivas de dados, que são individualmente acessados, chamados de access units

(unidades de acesso) e dentro dessas unidades estão as descrições e definições de esquemas

Page 50: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

50

referentes ao padrão. Há também uma camada no sistema responsável por reagrupar essas

pequenas unidades para reconstituir os dados de descrições (Martinez, 2002).

Outra característica importante do sistema é a utilização do formato BiM (Binary

Formato for MPEG-7) para a representação binária das descrições MPEG-7, que

originalmente são feitas em XML, que por sua vez não foi feita para trabalhar com sistemas

de tempo-real, por exemplo, conteúdo multimídia. O formato BiM possibilita a compressão e

distribuição streaming de documentos XML.

2.6.2 - MPEG-7 Description Definition Language

As principais ferramentas usadas na implementação das anotações MPEG-7 são:

Description Definition Language (DDL), Description Schemes (DSs) e Descriptors (Ds).

DDL constitui a parte principal do padrão MPEG-7, pois fornece elementos descritivos onde

os usuários podem criar seus próprios esquemas de descrição e descritores para expandir a

usabilidade do padrão de acordo com suas necessidades. Representa a modelagem do

conteúdo multimídia em forma de linguagem de texto.

Com a DDL é possível representar relações conceituais, espaciais, temporais e

estruturas de elementos, pois sua modelagem é bastante completa em termos de referências e

relações entre esquemas de descrição e descritores.

Em resumo, DDL define as regras gramaticais de uma linguagem derivada do XML

(eXtensible Markup Language), com sua própria sintaxe e semântica para expressar e

combinar esquemas de descrição e descritores (MPEG7, 2004). Também é importante lembrar

que é possível alterar definições já existentes de esquemas de descrição e descritores.

Esta é uma linguagem legível tanto para seres humanos quanto para máquinas, porém

as máquinas necessitarão de um analisador sintático, capaz de validar o conteúdo e a estrutura

de um documento DDL, bem como os tipos de dados definidos na especificação da

linguagem. Também deverão ser capazes de validar descrições MPEG-7 de acordo com seus

respectivos esquemas de descrição (MPEG7, 2004).

O uso de esquemas XML proporciona à linguagem DDL a facilidade de

interoperabilidade necessária para a extensão dos descritores e esquemas de descrição.

Também é possível que outras aplicações baseadas em XML utilizem o MPEG-7 para

estender suas funcionalidades com descrição de conteúdos multimídia.

Abaixo segue um exemplo de uso da linguagem DDL para anotação do logo MPEG,

retirado de (Martinez, 2002): <Mpeg7 xmlns=“http://www.mpeg7.org/2001/MPEG-7_Schema” xml:lang=“en”

Page 51: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

51 type=“complete”> <ContentDescription xsi:type=“ContentEntityType”> <MultimediaContent xsi:type=“ImageType”> <Image> <MediaLocator> <MediaUri> http://www.tilab.org/mpeg/mpeg_logo-anim_l.gif </MediaUri> </MediaLocator> <CreationInformation”> <Creation> <Title xml:lang=“en”>The animated MPEG Logo</Title> <Creator> <Role href=“urn:mpeg:mpeg7:cs:RoleCS:AUTHOR”> <Name xml:lang=“en”>Author</Name> </Role> <Agent xsi:type=“OrganizationType”> <Name>MPEG</Name> </Agent> </Creator> </Creation> <RelatedMaterial> <MediaLocator> <MediaUri>http://www.tilab.com/mpeg/</MediaUri> </MediaLocator> </RelatedMaterial> </CreationInformation> </Image> </MultimediaContent> </ContentDescription> </Mpeg7>

Código DDL da descrição do logo MPEG a seguir

Figura 11: Logo MPEG descrito pela anotação MPEG-7

2.6.3 - MPEG-7 Visual

Especifica ferramentas de descrição de elementos visuais, como vídeo e imagens

estáticas. Ferramentas de descrição visuais consistem em estruturas básicas e descritores

visuais, que são baseados em características semelhantes que possibilitam a identificação de

similaridades em vídeos e imagens. Também são usados para filtragens e buscas baseadas em

diversas características como cor, textura, formas, movimento e localização. Cada uma destas

categorias tem desde descritores básicos até os mais avançados e específicos. Esses

descritores são classificados em genéricos e específicos de aplicação. Os específicos de

aplicação podem, por exemplo, ser utilizados em aplicações com processamento de imagem,

Page 52: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

52

como localização de veículos e reconhecimento de faces (Martinez, 2002). Já os genéricos são

classificados em (MPEG7, 2004):

• Básicos – interpolação, coordenadas 2D, visões 2D e 3D, temporal, etc;

• Cor – cor dominante, estrutura de cor, espaço de cor, etc;

• Textura – textura homogênea ou heterogênea, navegação por textura;

• Forma – baseados em região, contorno ou formas 3D;

• Movimento – movimento de câmera, trajetórias, etc;

• Localização – localização regional e especial-temporal;

Figura 12: Exemplo de aplicação de descrição em uma cena de vídeo, retirado de (MARTINEZ; KOENEN; PEREIRA, 2002)

Page 53: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

53

2.6.4 - MPEG-7 Áudio

Especifica ferramentas de descrição de elementos de áudio, como música e fala.

Descritores desse tipo são considerados de baixo nível quando se referem à características

paramétricas, temporais, e de espectros dos sinais de áudio (também conhecido como MPEG-

7 Audio Framework) e de alto nível quando são mais específicos para uma determinada

aplicação, usados em situações como anotar o timbre ou melodia de um instrumento,

conteúdo falado ou até mesmo reconhecimento de som (MPEG7, 2004). Os descritores de

áudio de alto nível são classificados em (Martinez, 2002) :

• Combinação de áudio (descreve a semelhança espectral dos sons);

• Combinação de Timbre (identificação, busca e filtragem);

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

• Reconhecimento de som e indexação;

• Fala

2.6.5 - MPEG-7 Multimedia Description Schemes

Especifica os descritores e esquemas de descrição para características genéricas e

descrições multimídia, incluindo esquemas de descrição de áudio, vídeo, e de outros tipos

(Martinez, 2002). São basicamente, modelos de objetos multimídia e do universo que

representam. Especificam tipos de descritores que podem ser usados em uma determinada

descrição, e as relações entre esses descritores ou entre outros esquemas de descrição.

Para criar descrições MPEG-7 de qualquer conteúdo multimídia, a primeira etapa é

criar um wrapper (esquema ao qual será atribuída a descrição) para a descrição utilizando as

ferramentas de esquema. As diferentes ferramentas utilizadas para criação de descrições usam

elementos básicos genéricos, que representam o alicerce do MPEG-7 para extensão da

linguagem fornecida.

2.6.6 - MPEG-7 Description Tools

MPEG-7 Description Tools define um conjunto padronizado de descritores e

esquemas de descrição, baseado em suas funcionalidades, porém nada impede de mesclar

vários descritores e esquema de descrição de funcionalidades diferentes em um processo de

anotação, desde que faça algum sentido lógico, através da ferramenta Schema Tools (ou

ferramentas de esquema). São basicamente agrupados em (Martinez, 2002):

• Elementos Básicos – entidades genéricas utilizadas por outras ferramentas de

descrição;

Page 54: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

54

• Ferramentas de esquema – disponibiliza as ferramentas de descrição para as

aplicações;

• Ferramentas de descrição de conteúdo – representa informação perceptível, como

aspectos estruturais, conceituais, audiovisuais, etc;

• Ferramentas de gerenciamento de conteúdo – especifica características da mídia,

criação e uso da mesma;

• Ferramentas de organização de conteúdo – permite criar e modelar conjuntos de

conteúdo multimídia e descrições;

• Ferramentas de acesso e navegabilidade – especifica particionamento e

decomposição de conteúdo multimídia para facilitar a navegação;

• Ferramentas de interação com o usuário – descreve preferências do usuário e

mantém um histórico de uso do conteúdo multimídia.

Figura 13: Organização das ferramentas de acordo com a funcionalidade

2.7 - MPEG-21

O formato MPEG havia alcançado seus objetivos de compressão de formatos de mídia

com boa qualidade e utilizando pouco espaço. Entretanto, a mídia somente não basta para

divulgar algumas informações. O MPEG-21 surge com o objetivo de transportar mais do que

vídeo em um arquivo de mídia. Isso permite um uso mais específico do conteúdo de mídia,

baseado, por exemplo, nas preferências do usuário ou nas capacidades do dispositivo. Com

Page 55: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

55

isso é possível fazer um controle sobre quem acessa a mídia, permitindo um maior controle

sobre os direitos autorais de um item digital.

Há muitas semelhanças entre o MPEG-7 e o MPEG-21, principalmente no que diz

respeito às ferramentas de descrição que os dois sistemas adotam. O MPEG-21 é focado em

estabelecer a relação entre um item digital e aquele que o usa. Entende-se por item digital a

combinação de recursos como vídeo, imagens, textos, metadados (que podem ser usados para

identificação do conteúdo) e a estrutura que descreve a relação entre esses recursos. Um

usuário é qualquer um que possa interagir com aquele conteúdo, incluindo o criador, o

distribuidor, o detentor dos direitos autorais e o consumidor final.

Entretanto, por ser um formato ainda em desenvolvimento, várias partes do padrão

ainda não estão completamente definidas. Dentre as partes que já possuem especificação

definida, podemos citar:

• Multimedia Framework: Define os elementos para a inclusão correta dos recursos

de multimídia, assim como a integração, criação, manipulação, controle, e

distribuição desses itens digitais;

• Digital Item Declaration: Define uma série de termos e conceitos que serão usados

para definir itens digitais;

• Digital Item Identification: Identifica o item digital e suas partes;

• Intellectual Property Management and Protection: Framework que funcionará

como uma forma de proteção de direitos de propriedade intelectual em um arquivo

áudio-visual;

• Rights Expression Language: Define uma linguagem, baseada nos termos do

Rights Data Dictionary, que pode declarar direitos e permissões para arquivos

áudio-visuais, permitindo maior controle no uso desses arquivos e em sua

distribuição, publicação e consumo;

• Rights Data Dictionary: Define uma série de termos bem estruturados e integrados

que visam atender todas as necessidades do Rights Expression Language;

• Digital Item Adaptation: Provê mecanismos de descrição de informações

relacionadas a um ambiente e a um formato que podem ser utilizadas em um

mecanismo de adaptação, possibilitando acesso transparente a itens digitais;

• Reference Software: Define softwares que implementam as funcionalidades

previstas em MPEG-21;

• File Format: Define um formato de arquivo para o MPEG-21, de forma que seja

compatível com os demais formatos MPEG.

Page 56: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

56

Como é possível verificar, o formato MPEG-21 está se direcionando para o uso e

manipulação de itens digitais. Para definir um item digital que será usado no padrão MPEG-

21, é necessário seguir algumas normas. A Digital Item Declaration (DID - Declaração de

item digital) - ISO/IEC 21000-2 - define a estrutura e organização que deve ser seguida em

um item digital (Burnett et al, 2003). O objetivo é definir termos e conceitos que definem o

que é um item digital. Para isso, é usada a Digital Item Declaration Language (DIDL), que

define um XML com flexibilidade suficiente para representação de complexos itens digitais.

A DIDL é composta de alguns elementos, podendo citar:

• Contêiner: Permite o agrupamento de itens ou outros contêineres. Os contêineres

podem formar pacotes lógicos – úteis no transporte de dados ou na organização

dos elementos de um item digital;

• Item: É o agrupamento de componentes ou subconjuntos que são ligados a

descritores relevantes. Podem conter diversas opções de configuração para que um

item possa ser personalizado. Um item pode ou não conter subitens. Se um item

contém um subitem, ele é chamado de “compilação”. Se ele não contém, ele é

chamado de “entidade”. Um item é, na verdade, uma representação declarativa de

um item digital;

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

descritores contém informações relacionadas à uma instância do recurso ou à parte

dela. Os descritores comumente contêm informações estruturais sobre o recurso –

tais como tamanho, informações de decriptação, pontos de início etc – mas não

informações descritivas sobre o recurso;

• Âncora: Faz a ligação entre descritores e fragmentos, correspondendo à

localização específica de um recurso ou de parte dele;

• Descritor: Associa informações com um elemento. Essa informação pode ser

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

• Condição: Descreve o elemento como sendo opcional e faz um link dele com as

condições que afetam a sua inclusão. Múltiplos predicados inseridos em uma

mesma condição geram uma conjunção (relação AND). Múltiplas condições

associadas geram uma disjunção (relação OR);

• Escolha: Designa uma série de seleções que podem afetar a configuração de um

item;

Page 57: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

57

• Seleção: Descreve uma decisão que afeta uma ou mais condições em um item.

Pode retornar um predicado sendo verdadeiro, falso ou indefinido;

• Anotação: Uma anotação descreve informações sobre outro elemento do modelo

sem alterar ou adicionar qualquer coisa ao elemento. As anotações podem ter o

formato de afirmações, descrições e âncoras;

• Afirmação: Descreve a configuração de estado de uma escolha completa ou

parcial, definindo valores para alguns predicados associados com alguma seleção

para uma escolha como sendo verdadeiros, falsos ou indefinidos;

• Recurso: Qualquer objeto – vídeo, áudio, texto, imagem – individualmente

identificável. Pode ser também potencialmente um objeto físico. Os recursos

devem ser localizados por endereços que não sejam ambíguos;

• Fragmento: Designa um ponto específico ou um intervalo de um recurso;

• Indicação: É um valor textual literal que contém uma informação mas não é um

recurso. Exemplos de indicações podem ser: uma descrição ou uma informação de

identificação;

• Predicado: É uma declaração que pode ser verdadeira, falsa ou indefinida.

Um exemplo do uso dos elementos definidos no Digital Item Declaration Language

pode ser visto na figura a seguir (Burnett et al, 2003):

Figura 14: Exemplo do uso dos elementos da Digital Item Declaration Language

Page 58: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

58

O MPEG-21 ainda é composto por um Digital Item Identification – Identificação de

Item Digital, cuja função inclui identificar os itens digitais e suas partes, o endereço de IP

relacionado aos itens digitais e os esquemas de descrição. Além disso o Digital Item

Identification especifica como usar os identificadores para relacionar os itens digitais com as

informações contidas em suas respectivas descrições em metadados. Digital Item

Identification também indica como devem ser identificados os diferentes tipos de Itens

digitais.

Outra preocupação é com os direitos autorais dos arquivos de mídia. MPEG-21

estabelece um framework para o Intellectual Property Management and Protection (IPMP).

Para isso, ele faz uso de um Right Expression Language (REL), que permite declarar direitos

e permissões usando os termos definidos em um Right Data Dictionary (RDD). O RDD forma

a base de todas as expressões definidas no REL. O RDD e o REL provêem mecanismos para

controlar o uso dos recursos digitais na publicação, distribuição e uso desses recursos – áudio,

filme, livros, jogos, softwares e qualquer outra criação em formato digital – com o objetivo de

proteger o conteúdo e os direitos autorais especificados.

Por ser um formato muito recente, muito ainda vêm sendo discutido em relação a

novas funcionalidades que o MPEG-21 pode vir a apresentar. Um exemplo é o Digital Item

Adaptation, que especifica um conjunto de ferramentas de descrição para auxiliar a adaptação

de itens digitais.

Page 59: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

59

Capítulo 3 – Desenvolvimento da Aplicação A proposta do trabalho é oferecer um método diferenciado para a apresentação de

produtos de uma loja virtual para televisão digital. Partindo da idéia de que os produtos serão

mostrados ao decorrer da programação, e de que o fluxo de dados MPEG será constante

durante a exibição da programação do canal, os produtos seriam extraídos do próprio vídeo,

baseado nos padrões MPEG-7 e MPEG-21. Para que tal operação seja possível, é necessário

que o lado do provedor de serviços tenha a capacidade de codificação do vídeo com os

padrões apresentados e o lado do usuário (STB) tenha a capacidade de decodificação.

3.1 – O Emulador

O emulador utilizado, o XleTView, disponível em http://xletview.sourceforge.net,

encontra-se em fase bastante inicial. Sua versão atual mais estável que pode ser encontrada no

site oficial do emulador é a 0.3.6, que apresenta uma implementação parcial, que deixa de

lados diversos elementos necessários para o desenvolvimento total da aplicação de loja virtual

sugerida. Um exemplo dessa ausência de funcionalidade é a falta da simulação de um fluxo de

dados MPEG, como aconteceria em um STB, sendo assim, impossível obter um vídeo em

tempo real, ou seja, para que o emulador rode vídeos é necessário que o vídeo esteja presente

por inteiro no disco local. Também não estão presentes decodificadores para os padrões

MPEG-7 e MPEG-21, portanto não seria possível extrair do vídeo, metadados MPEG-7 e

MPEG-21 ou mesmo fazer uso de ferramentas MPEG-21 para controle multimídia, de acesso,

entre outros.

O XleTView permite a visualização de xlets Java sobre o middleware MHP no

computador e é distribuído e desenvolvido pela GNU General Public License (GPL).

Desta forma é impossível desenvolver a aplicação da maneira desejada utilizando este

emulador, ou seja, recebendo os dados já decodificados do formato MPEG-7 e MPEG-21,

onde o STB será o encarregado de separar estes dados e disponibilizá-los para a aplicação.

Devido a esta restrição outros emuladores que possuem implementação de algum padrão de

televisão digital foram pesquisados, como o Cardinal Studio da Cardinal Systems e o

AltiComposer da Alticast, mas como todos estes são soluções comerciais e disponibilizam

apenas versões de demonstração que duram por 30 dias, também não foi possível a sua

utilização para desenvolvimento do sistema. Ainda assim, o que aparentou ser o mais

completo foi o AltiComposer e segundo sua descrição no site oficial, não implementa

Page 60: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

60

decodificação de MPEG-7 nem MPEG-21. A implementação destes padrões está diretamente

associada ao suporte de padrões MPEG do padrão de televisão digital, no caso, o MHP.

Segundo o site oficial do projeto XleTView, na versão 0.3.6, de 2004, das 373 classes

e interfaces listadas referentes às implementações das APIs DAVIC, HAVi, DVB-MHP e

JavaTV, apenas 245 estão completamente implementadas, 1 tem um bug conhecido, 15 estão

sob implementação e 112 ainda não foram implementadas. Enquanto a versão mais atual,

listada como não-estável, a versão 0.3.7 de 2005, apresenta 247 classes completamente

implementadas, 1 com bug conhecido, 16 sob implementação e 109 ainda não implementadas.

Desde esta última versão, nenhuma atualização foi feita, o que sugere que o projeto foi

descontinuado.

A versão escolhida para o desenvolvimento da aplicação foi a XleTView 0.3.7, que,

mesmo sendo a última, já está defasada e não suporta diversas funcionalidades que estavam

nos planos da implementação inicial. Esta versão foi levemente modificada para facilitar a

depuração da aplicação.

3.1.1 – Suporte à vídeos

O suporte à multimídia na versão do emulador XleTView utlizada, é limitado aos

formatos de áudio e vídeo suportados pela API JMF versão 2.1.1. A API JMF – Java Media

Framework – permite a decodificação de conteúdo multimídia dentro de uma aplicação Java.

A conversão é necessária porque o número de formatos que a API JMF consegue suportar é

baixíssimo, e sendo assim, alguns formatos de vídeo mais populares foram deixados de lado,

como MPEG-2, MPEG-4, Windows Media, Real Media, entre outros, até porque alguns são

formatos proprietários, como é o caso do Windows Media.

A tabela a seguir apresenta os formatos que podem ser lidos pelo JMF. Os que

estiverem marcados com a letra “D” podem ser lidos e apresentados, e os que estiverem

marcados com a letra “E” podem ser ainda codificados no devido formato. Se o formato pode

ser lido de um arquivo (input), ele estará marcado com “read”. Se ele pode ser escrito a partir

da aplicação, ele estará marcado com “write”. A linha da tabela marcada em cinza escuro

representa o o tipo de vídeo utilizado na compressão.

Page 61: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

61

Tabela 2: Suporte a formatos multimídia da API JMF

Formato

JMF 2.1.1 JMF 2.1.1 Versão

independente de plataforma

Versão Windows

AVI (.avi) Leitura/escrita Leitura/escrita Audio: 8-bit mono/stereo linear D,E D,E

Audio: 16-bit mono/stereo linear D,E D,E Audio: DVI ADPCM compressed D,E D,E

Audio: G.711 (U-law) D,E D,E Audio: A-law D D

Audio: GSM mono D,E D,E Audio: ACM** - D,E

Video: Cinepak D D Video: MJPEG (422) D D,E

Video: RGB D,E D,E Video: YUV D,E D,E

Video: VCM** - D,E MPEG-1 Video (.mpg) - Apenas leitura

Multiplexed System stream - D Video-only stream - D

MPEG Layer II Audio (.mp2) Apenas leitura Leitura/escrita MPEG layer 1, 2 audio D D,E

O formato utilizado nesta aplicação foi o Cinepak, convertido com o software RAD

Video Tools disponível para download em http://www.radgametools.com/bnkmain.htm. A

princípio, a intenção era de utilizar o formato MPEG-2, por ser mais próximo da realidade

quanto aos padrões de televisão digital, porém, com a versão da JMF utilizada pelo emulador

(que pouco difere da versão mais recente no quesito compatibilidade de formatos) não é

possível a decodificação do formato. O formato Cinepak tem baixa taxa de compressão se

comparado ao MPEG-2, e a perda de qualidade também é maior: um vídeo de 1 minuto e 53

segundos compactado com o codec Windows Media Video (extensão .wmv) ocupava 2.53MB

de espaço em disco, quando convertido para MPEG-2, passou a ocupar aproximadamente

23MB sem perda de qualidade perceptível, e quando convertido utilizando-se o Cinepak,

ficou com 77MB e houve uma perceptível redução de qualidade.

3.1.2 – Modificações no Emulador

Algumas modificações foram feitas na versão 0.3.7 do emulador XletTView. Isso

ocorreu porque esta versão, que estava disponível no repositório de códigos do projeto, não

era considerada versão estável e para distribuição, portanto continha um mecanismo de

depuração que gerava um histórico de todas as ações do emulador no próprio console onde era

Page 62: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

62

executado, e este mecanismo não estava acompanhado de código-fonte, apenas de códigos

intermediários Java.

Para contornar este problema, foi criada uma janela para o armazenamento de

mensagens das xlets, apenas para guardar a saída da aplicação, separando-a da saída do

emulador. Este mecanismo foi o mais próximo de uma depuração que foi possível chegar

neste trabalho, se tratando de uma xlet, cujos arquivos binários são carregados em tempo de

execução e não são percebidos pela ferramenta de desenvolvimento utilizada. A figura a

seguir mostra o funcionamento da janela durante a execução da xlet da loja virtual.

Figura 15: Imagem da janela de log

3.2 – A aplicação

Para explicar como a aplicação funciona, bem como seu comportamento dentro de um

STB, é necessário entender suas funcionalidades primeiro. Já se sabe que a aplicação é uma

loja virtual para televisão digital, porém, uma aplicação para tal plataforma difere de uma em

plataformas mais convencionais para este tipo de aplicação, como por exemplo computadores

pessoais ou smart phones. É possível perceber melhor essa diferença analisando variáveis

como resolução da tela do dispositivo utilizado, poder computacional, e até o foco da

plataforma em questão: em uma televisão digital o foco na tela será, na maior parte das vezes,

o vídeo que estará sendo exibido e não a loja virtual, enquanto em um computador pessoal, o

foco na tela geralmente será a loja virtual.

No caso da televisão digital a aplicação deve ser mínima, estritamente relacionada com

a sua funcionalidade e sem quaisquer outros recursos que poderiam ser considerados de

importância secundária. Baseado nisso, a aplicação, do ponto de vista do usuário contém

apenas uma interface que varia de conteúdo e tamanho de acordo com comandos do usuário.

São considerados comandos, toques nos botões do controle remoto. O usuário que desejar

Page 63: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

63

visualizar os produtos da loja, deverá primeiramente ativar a exibição de anúncios, que poderá

ser feita a qualquer momento, através de uma possível aplicação para a configuração do

serviço, ou ainda, através do botão azul do controle remoto. O usuário saberá da interação

com o botão azul e sua relação com a loja virtual através de propagandas do próprio serviço

durante a programação, ou através de um alerta sonoro ou um discreto alerta visual na tela,

notificando-o a respeito de uma possível interação.Desta forma, quando houver um anúncio

da loja disponível naquele intervalo de tempo, a aplicação exibirá sobre o vídeo, uma pequena

interface, alertando-o da existência de um produto à venda, como na figura a seguir.

Figura 16: Imagem da xlet em execução sobre o vídeo

Nesta interface, será possível visualizar uma miniatura da foto do produto, caso esteja

disponível, bem como seu nome e uma breve descrição, acompanhados com um botão

vermelho e um botão verde, respectivamente simbolizando ações para ver mais detalhes do

produto e partir para a compra imediatamente. Ambas as cores, neste modelo, estão

diretamente ligadas às cores dos botões no controle, para facilitar a interação do usuário com

a aplicação.

Page 64: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

64

Também é possível visualizar na figura anterior o remoto existente no emulador. É

importante lembrar que um controle remoto para televisão digital deve ter mais botões do que

o normal para facilitar a interação com o usuário e o controle de aplicações na tela. No caso

desta xlet, os botões coloridos servirão para ações dentro da aplicação e acarretarão em uma

transição nas formas da interface do programa enquanto o botão com o texto “exit” terá a

função de desligar a exibição de propagandas daquele determinado serviço (comumente

chamado de canal na televisão analógica), ou seja, invocar um método de destruição da xlet

responsável pela loja que ainda reside no STB, para que este dê continuidade no ciclo de vida

desta xlet.

Quando o usuário aperta o botão vermelho referente à tela de mais informações, a

mesma interface tem o tamanho aumentado e seu conteúdo atualizado com uma foto maior do

produto caso esteja disponível, sua descrição completa, preço de compra pela televisão digital

e opção de compra. Tanto a foto versão miniatura quanto a foto grande do produto podem ou

não aparecer não só devido a ela existir ou não para determinado produto, mas também por

possíveis erros nas decodificações dos padrões MPEG-7 e MPEG-21 envolvidos.

Figura 17: Interfaces de exibição de detalhes e confirmação de compra

Se o usuário deseja comprar o produto, basta apertar o botão verde, a qualquer

momento da exibição do anúncio, que ele será remetido à interface de compra, com um

simples formulário, semelhante à formulários encontrados freqüentemente na web, onde ele

deverá usar um código único por assinante previamente cadastrado com a fornecedora do

sinal de televisão digital. Para este campo do formulário, apesar de o código ser confidencial

do usuário, alguns fatores foram levados em consideração para que o campo não funcionasse

Page 65: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

65

de modo análogo ao campo de senha em um formulário web: o fato de que apertar os botões

numéricos do controle de televisão digital, inutiliza funcionalidades de troca de canal durante

o tempo em que o campo detém o foco na tela e ter que digitar duas vezes aumentaria ainda

mais esse tempo, e também que este campo só terá validade no local onde se encontra o

respectivo STB, ou seja, o usuário só poderá utilizar seu código no local onde está cadastrada

a sua assinatura. Para esta aplicação, o ideal é que houvesse assinatura de televisão digital à

cabo, pois o mesmo cabo serviria para transmissão do sinal de televisão e para transmissão de

dados pela internet, que será necessário no momento da compra, já que estes dados precisam

ser retornados ao provedor de serviço de televisão.

Esta comunicação com o serviço ocorre de forma totalmente transparente para o

usuário sob as condições citadas, e realiza a autenticação no servidor, que retorna uma

resposta ao usuário pelo mesmo canal de comunicação, realizando assim, a operação de

autenticação e validação da compra. Esta ação pode gerar erro, caso o formulário não tenha

sido preenchido corretamente ou o serviço tenha recusado a requisição, ou pode finalizar a

compra caso o serviço tenha validado a compra. Em caso de validação da compra, neste

modelo, o valor deverá ser descontado na próxima fatura do usuário.

Figura 18: Interfaces de resultado da confirmação de compra: sucesso e erro

3.3 – Desenvolvimento da Xlet

Para compreender como a aplicação funciona em um nível mais baixo, neste item

serão apresentados trechos de código da aplicação xlet e seu significado perante a modelagem

do problema, ou seja, para que foi utilizado no desenvolvimento da loja virtual.

A aplicação da loja virtual foi desenvolvida sob os moldes de uma xlet descrita pela

API Java TV e com base em uma modelagem UML (Booch et al., 1998) de 5 camadas. São

elas: cliente, apresentação, negócios, integração e dados. O código fonte do programa foi

organizado de forma semelhante à organização em camadas, separando-as em pacotes, cada

um com sua respectiva estruturação interna. Esta estruturação será apresentada a seguir, na

mesma ordem em que são apresentadas as camadas.

Page 66: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

66

Alguns padrões de programação GoF (Freeman et al., 2001) e também alguns padrões

extraídos da Java Enterprise Edition (Alur et al., 2003) foram utilizados e serão explicados à

medida em que forem apresentados.

Em seguida, serão apresentados diagramas de seqüência para demonstrar como

funciona a execução inicial do programa até o momento da exibição de um anúncio e também

de um evento de compra gerado pelo usuário.

3.3.1 - Pacote org.tgi.store.view

Neste pacote, encontra-se apenas a classe principal da aplicação denominada Store.

Esta classe representa a xlet em si e portanto é a base da loja virtual. Para esta classe ser

considerada uma xlet, é necessário que a interface Xlet do pacote xjavax.tv.xlet, definida na

implementação da API Java TV do emulador, seja implementada, e com base nos métodos

herdados desta interface, a xlet será informada sobre qualquer mudança de estado gerada pelo

gerente de aplicações dentro do STB e dessa forma, poder finalizar seus componentes antes de

ser reciclada pelo STB, ou seja, passar para o estado Destroyed ou apenas ter sua execução

interrompida.

Figura 19: Pacote cliente

Nos testes realizados, foi possível concluir que a xlet é carregada dinamicamente pelo

STB. Em outras palavras, o STB, no momento em que recebe a xlet pelo fluxo de dados de

entrada, não conhece sua implementação, mas pode tentar carregá-la, fazendo-a passar para o

estado Loaded e executá-la através da interface já conhecida e padrão para xlets

implementada na API Java TV. O mesmo acontece com quaisquer outras classes que são

utilizadas no decorrer da execução da xlet.

Por exemplo, quando a xlet tentar acessar um objeto cuja definição não está disponível

dentro do próprio STB, supõe-se que esta classe tenha sido enviada junto com a xlet no fluxo

de dados, e então o STB tenta carregá-la dinamicamente assim como fez com a própria xlet.

Page 67: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

67

Esse é o esquema de funcionamento do emulador XleTView e talvez gere algum pequeno

atraso na execução da aplicação, que pode se tornar quase imperceptível dependendo do poder

computacional do STB e do tamanho do respectivo arquivo em disco.

Essa busca por definições de classe dinamicamente ocorre, no caso da aplicação da

loja virtual, quando a xlet se comunica com as classes da camada de apresentação.

A xlet se comunica com classe StoreController da camada de apresentação assim que

passa para o estado Active, para informar, através de seu contexto de execução, a instância do

gerenciador de execução da mídia, no caso uma instância de Player. Outras operações

importantes que a xlet faz assim que passa para este estado, são os registros junto às classes

StoreController e ProductEventManager que fazem a classe receber eventos da camada de

apresentação, para que seja possível atualizar a interface da aplicação. Para isso, a xlet

implementa as interfaces AnnounceListener e ProductListener, que são explicadas na próxima

camada. O registro nada mais é do que uma referência ao objeto da xlet que uma classe

gerenciadora de eventos possui.

3.3.2 - Pacote org.tgi.store.presentation

Este pacote reúne as classes da camada de apresentação e é nesta camada que se

concentra a maior parte das classes desta aplicação.

Page 68: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

68

Figura 20: Pacote de apresentação

Por se tratar de uma aplicação onde a parte visual é extremamente importante, pois não

se deseja interferir excessivamente na exibição do vídeo, há bastante lógica de interface e é

nesta camada que é feita a comunicação com a camada de negócios para a efetuação da

respectiva lógica. Esta camada é uma ponte entre a camada cliente e de negócios, e está mais

relacionada com a camada cliente do que com a camada de negócios.

A classe mais importante é a StoreController que é uma thread que é implementada

utilizando-se o padrão GoF Singleton (Freeman et al., 2001), para que haja apenas uma

instância desta thread. Esta thread é disparada assim que a xlet entra no estado Active, e tem a

função de solicitar à camada de negócios uma listagem dos anúncios dos produtos descritos

no arquivo MPEG-7 recebido pelo fluxo de entrada de dados, e também de sincronizar a

exibição de anúncios com o vídeo transmitido pelo canal. Para isto, esta thread verifica o

exibição do vídeo a cada segundo. Isto é feito através de uma referência ao objeto do

gerenciador de execução da mídia, que por sua vez é recebida pela classe Store, e analisa em

sua lista de anúncios se algum dos anúncios pertence àquele segundo.

Page 69: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

69

É importante ressaltar que esta lista é administrada da seguinte forma: assim que a

thread encontra um anúncio para começar a ser exibido naquele instante de tempo, este

anúncio é removido da lista, pois não aparecerá novamente e a thread pausa a sua execução

por uma quantidade de tempo estipulada no próprio anúncio. Também é importante ressaltar

que nesta lista, os anúncios estão organizados por ordem cronológica. Estas duas medidas

foram tomadas para que a execução do programa não necessitasse de muito processamento

por parte do STB, ou seja, a fim de otimizar a aplicação.

A classe StoreController ainda implementa o padrão GoF Observer (Freeman et al.,

2001), semelhante ao mecanismo de “listeners” encontrado no pacote java.awt.event. Esta

classe mantém uma lista de objetos que implementam a interface AnnounceListener do pacote

org.tgi.store.presentation.event. Desta forma, quando a thread encontra um anúncio para

exibição naquele segundo, ela gera eventos do tipo AnnounceEvent, e os envia para todos os

itens desta lista, avisando que o anúncio deve ser exibido. Então a thread pausa, e quanto

retorna, gera outro evento para que os anúncios sejam escondidos.

Figura 21: Pacote de interface gráfica da camada de apresentação

Page 70: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

70

Já no pacote org.tgi.store.presentation.ui encontram-se componentes visuais, que

derivam da API HAVi para televisão digital, pois a mesma implementa componentes de

forma padronizada, e cada STB tem a sua implementação desta API, ou seja, podem haver

componentes que sejam visualmente diferentes de um STB para outro. Por isso, estes

componentes foram criados.

No pacote org.tgi.store.presentation.ui.layout encontram-se os components visuais

personalizados para a exibição do anúncio. A classe StoreLayoutManager, que também adota

o padrão GoF Singleton (Freeman et al., 2001), é responsável pela criação de novas instâncias

de AnnounceContainer, que nada mais é do que um contêiner visual, que engloba

componentes que representam o texto, a imagem e os botões do anúncio. A maneira como

será exibida esses componentes dentro do contêiner dependerá da instância de StoreLayout.

A classe abstrata StoreLayout e todas as classes que a implementam fazem parte de

um padrão GoF do tipo comportamental, denominado Strategy (Freeman et al., 2001). Cada

uma das classes que implementam esta interface, dispõem de componentes visuais diferentes

para representar o anúncio, ou seja, são maneiras diferentes de representar um mesmo tipo de

dado na tela. Neste caso são utilizadas para ilustrar as etapas de visualização do anúncio,

visualização de detalhes do produto, autenticação e compra ou ainda mensagens de erro ou

sucesso na compra. Todas fazem uso da classe LineBreakHelper do pacote

org.tgi.store.presentation.ui.helper para auxiliar na quebra de linha dos textos exibidos no

contêiner, de acordo com o tamanho dos componentes, realizando uma tarefa simples, mas

que não estava implementada por padrão.

A classe AnnounceContainer também implementa a interface ProductListener e se

registra em ProductEventManager (outro Singleton), num mecanismo igual ao da classe

StoreController que implementa o padrão GoF Observer (Freeman et al., 2001). Só que desta

vez, os eventos são gerados quando o usuário pressiona um botão do controle remoto, e este

evento do botão acarreta em uma alteração na interface, como por exemplo, apertar o botão

vermelho para visualizar a interface de detalhes do produto. No momento em que o

AnnounceContainer recebe um evento desse tipo, é chamada a instância de

StoreLayoutManager para a geração de um novo StoreLayout, e em seguida este é associado

ao contêiner, redesenhando a interface na tela. AnnounceContainer também guarda uma

instância de LayoutState, que é um padrão GoF chamado State (Freeman et al., 2001) “hard-

coded”, ou seja, implementado diretamente via código e não através de uma hierarquia de

classes. Este LayoutState representa o estado que a interface do anúncio se encontra no

Page 71: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

71

momento em que é gerado um evento, pois o mesmo botão pode gerar diferentes ações

dependendo do StoreLayout atual.

3.3.2 - Pacote org.tgi.store.business

É neste pacote que se concentra a lógica de negócio da aplicação. A principal

funcionalidade aqui, é receber requisições e tratá-las de forma correta aplicando a lógica

necessária.

Figura 22: Pacote de negócios

Toda vez que uma a thread da classe StoreController, da camada de apresentação, é

instanciada pela primeira vez, as informações sobre anúncios são solicitadas à classe

StoreFacade, que por sua vez, também utiliza o padrão GoF Singleton (Freeman et al., 2001),

para manter apenas uma instância de si mesma. O principal motivo para se ter apenas uma

instância dessa classe deve-se ao fato de a aplicação inteira estar armazenada no STB, onde há

apenas um usuário, e não múltiplos usuários acessando de forma concorrente, como em um

servidor web.

A classe StoreFacade, após receber a requisição da listagem dos anúncios, solicita à

camada seguinte, mais precisamente à qualquer classe que deriva de DataAccess da camada

de persistência. O resultado dessa solicitação é então processado e armazenado em objetos do

tipo AnnounceBO que utilizam o conceito do padrão Java EE Business Object (Alur et al.,

2003).

A classe AnnounceBO tem a responsabilidade de armazenar as informações,

representando a entidade anúncio de forma coesa, e seus objetos podem então ser repassados

Page 72: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

72

para a camada de apresentação, onde é utilizado como um dos atributos de classes como

AnnounceEvent e ProductEvent, que pertencem ao mecanismo do padrão GoF Observer

(Freeman et al., 2001). Sendo assim, qualquer classe que se registrar para receber eventos dos

tipos citados, também irá receber, como atributo, uma instância da classe AnnounceBO,

possibilitando que classes da camada de apresentação tenham acesso às informações do

produto.

Outra funcionalidade desta classe, que foi deixada de lado nesta aplicação, é a

validação da compra. O método checkUser() da classe StoreFacade, do modo como foi

implementado apenas valida qualquer requisição. Esta validação não foi implementada pois

necessita da uma comunicação com o canal de retorno, que ainda não foi implementado nesta

versão do emulador.

Esta classe também poderia ser responsável por se comunicar com o SI para obter

informações temporais que poderiam ser utilizadas na sincronização dos anúncios com a

propaganda, mas as classes do pacote org.dvb.si e as classes referentes ao SI da API Java TV

também não foram implementadas no emulador.

3.3.3 – Pacote org.tgi.store.integration

Dentro do pacote org.tgi.store.integration, encontram-se as classes referentes a camada

de integração. Pra acesso aos dados foi utilizado o padrão Java EE Data Access Object,

também conhecido como DAO (Alur et al., 2003), com a seguinte estrutura: a interface

DataAccess é a interface comum de acesso aos dados, e as classes que implementam esta

interface provém acesso aos dados de forma específica.

Figura 23:Pacote de ingração

Page 73: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

73

A classe utilizada para efetivo acesso aos dados foi a XmlDataAccess, que é

apropriada para ler especificadamente os dados de produtos relativos à anúncios da aplicação,

que provém do schema criado para MPEG-7 e descrito no próximo item deste capítulo. Sendo

assim, esta classe lê os dados do arquivo XML e transforma-os em objetos do respectivo tipo

definido na camada de dados, neste caso o tipo Product, para devolver à classe solicitante do

acesso aos dados, neste caso a StoreFacade.

A leitura dos dados referentes ao MPEG-7 e armazenado em estrutura XML, é feita

através da API Simple API for XML, também conhecida como SAX, que pode ser

considerada uma API rápida e eficiente neste caso, pois devido a baixa complexidade do

XML resultante, uma API com mais funcionalidades acarretaria em perda de desempenho da

aplicação. Com o auxílio do padrão Java EE Data Access Object (Alur et al., 2003), outras

formas de leitura ao arquivo XML poderiam ser implementadas, expandindo-as facilmente

para outros tipos de dados e não só para produtos. Até mesmo outra fonte de dados que não

fosse o MPEG-7 poderiam ser implementadas e tratadas. Nesta aplicação os tipos de dados

que são lidos do XML são definidos via código, proporcionando pouca flexibilidade para a

obtenção do produto, que deixa o acesso aos dados mais rápido já que se espera um XML

derivado do schema de produtos definido.

Algumas considerações devem ser feitas quanto ao XML. Como a localização do

anúncio na tela é definida também pelo XML, possíveis problemas como se o tamanho da tela

da televisão digital e o tamanho do anúncio forem incompatíveis com a localização do

mesmo, não serão responsabilidade desta camada e serão tratados mais à frente, quando os

dados relativos ao anúncio chegarem na camada de apresentação. E como o tempo de exibição

também é definido via XML, a verificação e validação destes dados é praticamente

inexistente, pois este processo feito item a item, pode retardar uma exibição de anúncio o

suficiente para que ele não apareça. Assim, o sistema considera desde o início, que o arquivo

XML contenha dados corretos para a exibição das propagandas. Um dado incorreto muitas

vezes não acarretaria em uma exceção, erro ou mensagem tratada pelo sistema.

Possíveis erros na montagem do arquivo XML podem ser citados: em relação ao

tempo de exibição, um anúncio poderia estar configurado para ser exibido no momento em

que outro anúncio já estivesse em exibição, e desta forma ele seria automaticamente

descartado e não seria exibido ao usuário. Erros nos valores da posição do anúncio da tela,

como anúncios que ficam fora da área de exibição, ou seja, ultrapassam os limites da tela, são

automaticamente corrigidos pela aplicação no momento da exibição do anúncio.

Page 74: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

74

3.3.4 – Pacote org.tgi.store.data

Este pacote tem a funcionalidade de representar entidades relacionadas com o

conteúdo XML do MPEG-7 recebido. No caso da aplicação deste trabalho, a entidade produto

é representada pela classe Product. Esta classe é utilizada apenas pela camada de integração e

não se estende às outras camadas da aplicação pois para tal funcionalidade foi criada a classe

AnnounceBO.

Figura 24: Pacote de dados

3.3.5 – Pacote de utilidades org.tgi.store.util

Este pacote contém apenas a classe Debug para a geração de um histórico de

mensagens para a depuração da aplicação, e faz o uso de uma das modificações feitas no

emulador que é a janela para armazenamento de mensagens de xlets.

3.3.6 – Diagrama de Seqüência para a ativação de um anúncio

O diagrama UML (Booch et al., 1998) a seguir é um diagrama de seqüência e foi

utilizado para demonstrar quais classes e quais métodos precisam ser utilizados até que um

anúncio possa ser exibido na tela, ou seja, representa a seqüência de ativação de um anúncio.

Relações de ordem de execução também são representadas através deste diagrama, que possui

uma característica temporal de representação de ações na aplicação na forma de linhas

verticais para o tempo decorrido e de linhas horizontais para a chamada de métodos.

Page 75: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

75

Para representar esta seqüência, que não faz parte de nenhuma ação do usuário, mas

sim da execução inicial da aplicação e que ocorre de forma automática, o diagrama poderá ser

subdividido em duas partes. Também podemos perceber que é considerada apenas a execução

da xlet em si, e não das operações do STB de carregamento da mesma no sistema.

Na primeira parte, a xlet Store apenas realiza inicialização de variáveis internas e

recupera a instância do gerenciador de mídias em execução dentro do emulador e repassa à

camada de apresentação. Em seguida a xlet inicia o serviço de busca de anúncios, ou seja,

instancia a thread StoreController, cujo papel é solicitar à classe StoreFacade que ela realize

a busca de anúncios para exibição, e verificar a cada segundo se existem anúncios a serem

feitos naquele intervalo de tempo. A classe StoreFacade, por sua vez, delega a tarefa de busca

de dados ao XmlStoreDataAccess que apenas adapta o schema MPEG-7 de produtos e os

transforma em objetos Product. Estes objetos do tipo Product quando retornados à classe

StoreFacade, são encapsulados em objetos do tipo AnnounceBO.

E por último, a classe StoreController gera um evento de exibição de anúncio

AnnounceEvent. Para esta última chamada, vale lembrar, que ocorre apenas quando um

anúncio foi encontrado para determinado intervalo de tempo, e que apenas é feita para outros

objetos que estão previamente registrados para recebê-los, seguindo a idéia do padrão GoF

Observer (Freeman et al., 2001).

Figura 25: Primeira parte do diagrama de seqüência da ativação de um anúncio

Page 76: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

76

Na segunda parte deste diagrama, ocorre a exibição de componentes visuais na tela, já

que se considera o cenário onde uma ocorrência de anúncio foi encontrada para determinado

instante. A partir desse momento, a xlet é avisada através de um mecanismo de eventos e

solicita à classe que gerencia componentes visuais para exibição de anúncios,

StoreLayoutManager, que crie um componente visual que atenda às especificações do

produto em questão, ou seja, crie um anúncio para um produto. Esse conjunto de componentes

visuais está contido em AnnounceContainer e é definido por StoreLayout. Com essa criação e

inicialização do objeto AnnounceContainer, o anúncio deve ser repassado à xlet, que é a única

classe que contém referência para a tela de exibição do usuário, podendo assim, anexar o

anúncio à tela.

Figura 26: Segunda parte do diagrama de seqüência da ativação de um anúncio

3.3.7 – Diagrama de Seqüência para a compra de um produto

O diagrama de seqüência a seguir, representa o cenário de compra de um

produto através de um anúncio na loja virtual.

Page 77: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

77

Figura 27: Diagrama de seqüência de um cenário de compra

Neste cenário, o anúncio envia ao seu ativador, ou seja, a thread StoreController, que

é responsável por eventos de ativação de anúncio, as informações contidas no campo para

preenchimento do código de assinante, que o usuário deverá preencher para que valide sua

intenção de compra. A StoreController faz apenas uma validação básica nesse código, como

por exemplo, se o campo foi realmente preenchido com a quantidade certa de caracteres, e

repassará à StoreFacade. A classe StoreFacade de fato se encarregará da lógica de negócio

referente à compra. É nesta parte que deveria ocorrer uma chamada ao serviço com o código

de assinante para efetiva validação da compra, através do canal de retorno, porém, por

motivos já explicados, é impossível fazer esta operação através do emulador utilizado.

Em seguida, o próprio AnnounceContainer se encarrega de atualizar seus componentes

visuais de acordo com seu estado interno, para mostrar a resposta da solicitação de compra.

3.4 – O Uso dos padrões MPEG-7 e MPEG-21

A aplicação desenvolvida neste trabalho nada mais é do que um elo de ligação entre o

MPEG-7 e o MPEG-21, pois utiliza dados vindos de ambos para gerar um produto final: a

loja virtual para televisão digital. Nos próximos itens serão destacados os modos com os quais

cada padrão foi utilizado.

Page 78: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

78

É importante ressaltar que MPEG-7 e MPEG-21 são independentes do formato de

codificação de vídeo e áudio utilizado, e o resultado da codificação do vídeo com os seus

metadados dar-se-á a partir da combinação de ambos. Por exemplo, o padrão MPEG-7,

quando utilizado em conjunto com o MPEG-4 (referente ao conteúdo de áudio e vídeo), pode

ser chamado de MPEG-47.

Através das ferramentas de descrição e linguagem de declaração de itens digitais

presentes nesses formatos de vídeo, é possível, através do MPEG-7 classificar os itens, e com

o uso do MPEG-21 também seria possível o anexo de imagens ou vídeos demonstrativos do

produto junto com o vídeo principal da programação.

3.4.1 – MPEG-7

A partir da Description Definition Language do MPEG-7, será obtido o XML de onde

os produtos e seus dados serão retirados para o uso no programa. A flexibilidade

proporcionada pelo MPEG-7 permite a passagem desse tipo de dados junto com o vídeo. O

MPEG-7, entretanto, ainda é um formato recente e com algumas funcionalidades a serem

definidas.

A complexidade da Description Definition Language se deve à alta flexibildade, à

grande variedade de descritores diferentes, à longa estrutura hierárquica a se seguir, entre

outros fatores. Por conta dessa complexidade e das indefinições ainda presentes no formato,

não foi possível usar propriamente um arquivo MPEG-7. Os programas de anotações para

vídeo ainda estão em fases iniciais de desenvolvimento, não permitindo gerar as estruturas

necessárias para o uso no programa. Entretanto, é certo que essa estrutura é possível de ser

obtida e por isso, foi simulada de forma a funcionar da maneira mais próxima da estrutura que

é esperada em um arquivo MPEG-7. Entre os programas que foram usados para a tentativa de

criação de anotações em MPEG, pode-se citar o IBM Multimedia Annotation Tool, da IBM,

em sua versão 1.1, que, devido a diversos erros na geração do arquivo, não pôde ser explorado

com maiores detalhes. Já o Semantic Video Annotation Tool, SVAT, permitiu a criação de

um arquivo MPEG-7 simples que serviu de base para o desenvolvimento do schema de XML

que foi usado no programa.

Entre outros programas para trabalhar com MPEG-7, pode-se citar o Caliph e Emir,

que trabalham na criação de metadados para arquivos de imagem. Entretanto, são tags

específicas para anotação de imagem, não sendo genérico o suficiente para especificar um

produto, por exemplo.

Page 79: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

79

Maior do que a dificuldade de obter um arquivo MPEG-7 foi a dificuldade de

manipular o arquivo de vídeo corretamente na aplicação. Por ser uma tecnologia muito

recente, as bibliotecas de manipulação do vídeo ainda não existem, impedindo que o

programa trabalhasse com MPEG-7 da forma que era desejada. A escolha foi, portanto, partir

de uma situação ideal, considerando que o arquivo já tivesse sido tratado e o vídeo e o arquivo

descritivo XML com a descrição dos produtos da loja já estivessem devidamente separados.

Com o avanço do padrão MPEG-7 e com a disseminação da televisão digital,

softwares e bibliotecas que dão suporte à MPEG-7, ou maior nível de compatibilidade, vão

conseqüentemente surgir, possibilitando a manipulação desses arquivos de forma a chegar

facilmente na situação inicial com a qual se inicia a aplicação.

Devido à dificuldade na geração de um arquivo MPEG-7, o arquivo de Description

Definition Language, também foi simulado. A aplicação lê o arquivo como se fosse um XML

comum. O código a seguir é um exemplo de header para esse tipo de arquivo que foi montado

na simulação do programa: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg7:schema:2001 Mpeg7-2001.xsd "> <DescriptionMetadata> <Version>1.1</Version> <LastUpdate>2007-05-20T20:13:15</LastUpdate> <Comment> <FreeTextAnnotation>FrangoStore Movie</FreeTextAnnotation> </Comment> <PrivateIdentifier>TestId</PrivateIdentifier> </DescriptionMetadata>

Os elementos pertencentes à DescriptionMetaData são dados referentes ao

componente multimídia. Cada nó do arquivo XML do MPEG-7 deve seguir um schema

definido e bem estruturado, de forma que o XML final possa ser lido sem problemas por

qualquer decodificador. Na ausência de um schema adequado para o uso na aplicação, pois os

schemas encontrados, mesmo os que lidavam com informação genérica, tratavam apenas de

elementos que de fato apareciam no vídeo e não de elementos externos ao mesmo, a

alternativa foi a criação de um schema próprio, que satisfizesse as necessidades de metadados

do programa. A criação deste schema também favorece a incorporação de aplicações básicas

na definição básica do padrão, já que novas plataformas como a televisão digital favorecem o

desenvolvimento e a expansão destes padrões.

Page 80: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

80

<Description xsi:type="ContentEntityType"> <DescriptionMetadata> <PublicIdentifier></PublicIdentifier> <PrivateIdentifier>PID_1</PrivateIdentifier> <CreationTime>2007-05-20</CreationTime> </DescriptionMetadata> <Semantics> <AbstractionLevel dimension="0"/> <complexType name="FrangoStore"> <complexContent> <sequence> <complexType name="produto"> <attribute name="id" type="nonNegativeInteger" use="required"/> <attribute name="start" type="nonNegativeInteger" use="required"/> <attribute name="length" type="nonNegativeInteger" use="required"/> <complexContent> <sequence> <element name="name" type="mpeg7:TextualType"/> <element name="shortdescription" type="mpeg7:TextualType"/> <element name="description" type="mpeg7:TextualType"/> <element name="image" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element> <element name="imageLarge" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element> <element name="price" type="float"> <attribute name="currency" type="mpeg7:TextualType" use="required"/> </element> <element name="layout" minOccurs="0"> <complexType> <attribute name="transparency" type="float" use="optional"/> <attribute name="positionX" type="nonNegativeInteger" use="optional"/> <attribute name="positionY" type="nonNegativeInteger" use="optional"/> <attribute name="height" type="nonNegativeInteger" use="required"/> <attribute name="width" type="nonNegativeInteger" use="required"/> </complexType> </element> </sequence> </complexContent> </complexType> </sequence> </complexContent> </complexType> </Semantics> </Description>

A declaração desse esquema permite que o programa consiga ler a partir de um

arquivo, a especificação de um produto para uso na loja.

Page 81: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

81

Um exemplo do tipo de XML que pode ser feito seguindo essa declaração:

<FrangoStore> <produto id="72" start="2" length="8"> <name>Camisa Social DG</name> <shortdescription>Camisa Social Dolce Gabbana</shortdescription> <description>Camisa social Dolce Gabbana de mangas longas, botão na frente, punhos com botões duplos e motivo listrado. Made in Italy.</description> <image video="false">prod3.jpg</image> <imageLarge video="false">prod3_large.jpg</imageLarge> <price currency="R$">319.90</price> <layout transparency="0.3" positionX="500" positionY="20" height="100" width="200"></layout> </produto> </FrangoStore>

A aplicação desenvolvida é capaz de ler sem maiores problemas o XML citado através

da API SAX. O esquema de montagem do XML segue também o que foi definido no DDL

anterior, seguindo as regras de tipos e nomes dos campos, além da hierarquia.

O contêiner externo frangostore engloba todos os produtos que serão usados no

programa. Cada produto é definido junto com um id, que é um campo numérico para controle

do produto pela loja. Além disso, outros itens essenciais para a definição de um produto é o

tempo de início e duração do anúncio na loja, definidos respectivamente nos atributos start e

length.

Cada produto engloba também uma série de variáveis que caracterizam-no. Entre os

campos pertencentes a um produto, temos name, que é o nome do produto na loja,

shortdescription, que é uma descrição curta do produto para exibição no anúncio não

selecionado e description, que é uma descrição mais detalhada que é exibida quando o usuário

desejar ver mais informações do produto.

O elemento image indica o endereço de uma imagem para exibição no anúncio, se

existir uma imagem. Se um produto não possuir uma imagem, este campo pode vir vazio e o

anúncio será exibido somente com a descrição. Este elemento ainda possui um atributo

booleano video, que indica se será mostrado uma imagem ou vídeo no anúncio. Já o elemento

imageLarge é utilizado para especificar o endereço de uma segunda imagem ou trecho de

vídeo, que poderão ser utilizados na tela de exibição de detalhes do anúncio.

Um valor de ponto flutuante é definido no elemento price, que ainda possui o atributo

currency, que indica em qual moeda aquele valor está sendo cobrado.

Um elemento mais complexo é o elemento layout, que possui diversos atributos, que

podem definir a transparência do layout (transparency), posição do anúncio na horizontal,

Page 82: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

82

posição do anúncio na vertical (positionX e positionY), altura e largura do anúncio (width e

height).

Cada um desses elementos precisa ser especificado com detalhes no schema do

MPEG-7. O contêiner produto, por exemplo, foi especificado como um complexType, pois ele

encapsula todos os elementos relacionados com o produto. Cada elemento deve ser detalhado,

incluindo a definição de seus atributos e seus respectivos tipos.

<element name="image" type="mpeg7:TextualType"> <attribute name="video" type="boolean" use="required"/> </element>

O código acima, por exemplo, define o elemento image do XML de produtos. A tag

element indica que é um novo elemento que está sendo especificado, que receberá o nome

definido no atributo name e que possuirá o tipo definido em type. O nó attribute, dentro de

element indica que o elemento ainda conterá um atributo com nome definido em name e tipo

definido em type. O atributo use indica se este será um atributo opcional ou obrigatório. No

caso da definição de uma imagem para o anúncio, por exemplo, era necessário definir um

campo de texto que indique o nome da imagem ou vídeo a ser exibido no anúncio do

programa. E era necessária também uma variável booleana obrigatória que indicará se o

conteúdo daquele elemento é uma imagem ou um vídeo.

O schema, então, define um trecho do XML como exemplificado abaixo: <image video="true">pizza1.avi</image>

Entretanto não é possível garantir a integridade dos dados presentes no XML antes da

execução da aplicação, pois mesmo que ele esteja compatível segundo o schema definido,

dados contidos nele podem ser inválidos do ponto de vista da aplicação, como a posição do

anúncio. Considera-se, portanto que ele está correto quanto aos dados apresentados.

Entretanto, uma interface para a criação de um arquivo XML para ser usado na aplicação é

uma tarefa simples e uma validação dos dados, para garantir que todos os valores estejam no

formato certo e de forma consistente, poderia ser feita nesse processo de geração do arquivo.

Para exemplificação do funcionamento do programa, o XML usado foi escrito manualmente,

com dados que se encaixavam na aplicação. A geração do MPEG-7, portanto, é uma etapa

crucial para o funcionamento da aplicação.

Page 83: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

83

3.4.2 – MPEG-21

A utilização do formato MPEG-21 é bastante prejudicada pela constante atualização

ou até mesmo indefinição de várias partes do padrão, cujo progresso pode ser verificado

através do site oficial dos padrões MPEG. No site oficial é possível conferir um cronograma

das publicações das especificações que já foram realizadas. Também é possível observar que

atualmente menos da metade das partes do padrão que foram propostas, já possuem

especificação. Isto se deve ao fato do constante trabalho focado nas primeiras partes, pois elas

servirão de base para as conseguintes.

Sendo assim, fabricantes de hardware e softwares em geral, como por exemplo, os

fabricantes de STBs, ainda não optaram pela adoção deste padrão. A rápida mudança de

tecnologias, como a migração de televisões analógicas para televisões digitais, bem como a

variedade de dispositivos receptores de sinal de televisão digital disponíveis, impulsiona o

avanço dos padrões MPEG. Há padrões de televisão digital que utilizam MPEG-2 para o

vídeo, enquanto outros utilizam MPEG-4, e é essa divergência de padrões que o MPEG-21

procura resolver, proporcionando interoperabilidade entre os padrões em diferentes

plataformas. Daí tem-se idéia da complexidade da especificação do padrão e das constantes

atualizações que serão necessárias com o desenvolvimento de qualquer outro padrão MPEG.

Então, o uso deste padrão trata-se de uma modelagem conceitual do que ele realmente

representaria na loja virtual. Este modelo usará algumas das principais partes do padrão

MPEG-21 que já foram publicadas até agora e que estão passíveis de atualização, que são:

Digital Item Declaration, Digital Item Identification, Digital Item Adaptation, Rights

Expression Language e Rights Data Dictionary.

O modelo definido para esta aplicação será um item digital denominado Produto, que

representará a entidade produto da loja virtual. Um item digital desse tipo, deverá conter todas

as informações necessárias para que a aplicação da loja virtual, que reside no STB, seja capaz

de exibir um anúncio ao usuário.

O item digital terá imagens do produto, como miniaturas que serão usadas para o

anúncio inicial e imagens maiores que serão exibidas em maior tamanho para a melhor

visualização do mesmo, além de metadados MPEG-7 informando detalhes como preço do

produto, descrição, se possui imagens relacionadas ou não, entre outros. Este item digital

também terá componentes que poderão ser opcionais para a exibição do anúncio, como vídeos

de utilização do mesmo, por exemplo, ou então áudios e vídeos para o caso de o produto da

loja virtual ser necessariamente digital, e não um objeto físico, externo ao sistema. Um

Page 84: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

84

modelo do que seria um produto, do ponto de vista de um item digital, é representado na

figura a seguir:

Figura 28: Modelagem do conteúdo de um produto

Diversos conceitos definidos em Digital Item Declaration, DID, serão utilizados nesta

parte, para a estruturação do item digital, como contêiner, item, descritor, componente e

recursos. Um contêiner poderá conter um ou mais itens, que por sua vez, serão itens digitais

da entidade produto, ou seja, em um só arquivo MPEG-21, diversos produtos poderão ser

armazenados e transferidos. Desta forma, também pode ser feita uma categorização por

contexto em que aparecem, por exemplo, um contêiner pode ser utilizado para cada programa

de televisão que é transmitido. Cada item digital terá seu descritor, onde estarão os metadados

no formato MPEG-7 referente ao produto o qual representa, e também terá estruturas internas

denominadas componente que representarão uma associação entre descritores e recursos, ou

seja, conteúdos multimídia presentes no item digital, que poderão ser opcionais ou não. No

caso do componente, o descritor seguirá a parte Digital Item Adaptation da especificação do

padrão MPEG-21, pois esta descrição, ao contrário do padrão MPEG-7 que trata da descrição

do conteúdo multimídia, trata de informações sobre a manipulação desse conteúdo

multimídia, encapsulado em recursos, como bit rate, métodos de criptografia utilizados,

conjunto de caracteres, entre outros.

A parte Digital Item Identification, DII, que trata da identificação do item digital,

também tem grande utilidade nesta aplicação, pois servirá para atribuir nomes únicos aos

componentes do item digital. Estes identificadores são atribuídos pelo provedor de serviços de

televisão digital de acordo com um sistema interno de nomenclatura. Neste caso,

Page 85: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

85

identificadores são escolhidos para representar hierarquia entre os componentes de um item

digital, e também para representar um produto perante a loja virtual. Cada produto recebe uma

identificação única, e cada componente do item digital que o representa, recebe uma

identificação padronizada, de acordo com a identificação única do item digital e uma

funcionalidade atribuída a cada componente.

Esta estruturação, bem como a identificação do produto é representada na figura a

seguir:

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

A parte da especificação Rights Expression Language pode ser usada pelo provedor de

serviços de televisão digital, para definir diferentes métodos de acesso ao item digital. Desta

maneira, é possível fazer com que a aplicação da loja virtual e o serviço de exibição de

anúncios sejam exibidos apenas para usuários que contrataram este serviço perante o provedor

de serviços, por exemplo. Também é possível a criação de regras mais complexas para a

visualização deste item digital, ou de apenas partes dele.

Uma regra mais complexa para um item digital pode ser a validação do STB para a

exibição de um anúncio, ou seja, verificar se a aplicação da loja virtual está disponível no

STB, e até mesmo verificar a identificação do próprio STB por questões de segurança, para

saber se o item digital foi enviado para o STB correto, já que o sinal de televisão digital é

distribuído através da difusão.

Outra possível, e importante regra, é para a definição do acesso a conteúdo protegido

dentro de um item digital. Este conteúdo interno pode ser considerado um produto digital, no

Page 86: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

86

contexto da loja virtual, sendo imagens, outros vídeos, filmes, ou músicas. Para representar

essa hierarquia interna, de apenas partes de um item digital possuírem regras de utilização,

convém a adoção de termos comuns, definidos na parte Rights Data Dictionary da

especificação do MPEG-21.

Nesta parte estão presentes conjuntos de termos únicos e consistentes, que representam

relacionamentos ontológicos entre regras presentes em um item digital, e o conteúdo sobre o

qual a regra infere. Assim, esta parte age como um complemento à Rights Expression

Language, provendo uma associação lógica para as regras. Um exemplo de uma regra de

acesso à um produto digital pode ser visto na figura a seguir:

Figura 30: Regra aplicada à exibição de item digital contendo o vídeo de um produto digital vendido

Na aplicação desenvolvida para este trabalho, o papel do padrão MPEG-21 é implícito.

Como os metadados MPEG-7 e as imagens do produto, estão contidos no item digital

derivado do MPEG-21, descrito acima, e partindo do princípio de que o emulador utilizado

não consegue simular fluxo de dados, ou seja, a captação de dados do STB através do meio de

transmissão escolhido, e de que o emulador também não é capaz de interpretar padrões

MPEG, especialmente padrões mais recentes como o MPEG-21, é essencial o estabelecimento

de uma condição ideal para que o desenvolvimento se torne viável.

Nesta condição ideal considera-se que ambos os componentes MPEG-7 e multimídia,

que são relativos a um item digital, que neste caso é o produto, tenham sido extraídos do

arquivo MPEG-21 que supostamente foi enviado pelo SI e posteriormente, recebido e

armazenado temporariamente no STB. Este STB deveria ter a implementação do software de

referência do padrão MPEG-21 que está especificado em uma das partes deste padrão, mas

encontra-se em constante atualização. Sendo assim, o STB teria a capacidade de extrair

recursos do item digital, e disponibilizá-los em uma memória local, dentro do próprio sistema

de arquivos, para quaisquer aplicações residentes no STB. Ainda assim, de acordo com a

Page 87: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

87

identificação do item digital, seria possível iniciar a execução de uma determinada xlet. Por

exemplo, se o STB identifica que o item digital é um produto de loja virtual, e o mesmo

contém a aplicação loja virtual, o STB simplesmente executa-a. Nesta situação, é necessária

uma alta compatibilidade entre STB e xlet, que se pode alcançar através da adoção aos

padrões MPEG-7 e MPEG-21, para que o STB faça a relação entre item digital e aplicação.

Page 88: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

88

Capítulo 4 – Conclusão e Trabalhos futuros

O desenvolvimento de aplicações para televisão digital com recursos de fins não-

comerciais e plataformas de código aberto é bastante prejudicado pela escassez dos mesmos.

Poucos estão disponíveis, e os que estão disponíveis de forma livre, são incompletos ora na

implementação da API Java TV ora na implementação de um padrão de televisão digital.

Pesquisas em tecnologias recentes são agravadas devido a funcionalidades que ainda não

foram completamente definidas ou que sofrem mudanças com uma freqüência elevada, assim

como evidenciado nesta pesquisa, já que, apesar de existirem padrões de televisão digital

definidos, o desenvolvimento de softwares para tais padrões encontra-se em estado primário.

A escassez de material acadêmico, livros em especial, sobre os padrões MPEG-7 e

MPEG-21 também é um fator prejudicial. Apesar de contar com diversas fontes, a maior parte

delas tratam de uma introdução ao assunto. Isto se dá pois ambos os padrões são

relativamente recentes, principalmente o padrão MPEG-21, que ainda não possui sua

especificação completa, mas apenas a sua base, que ocasionalmente ainda sofrerá mudanças

devido a novas plataformas como televisão digital estarem em ascensão. Com esta plataforma,

diferentes dispositivos terão acesso ao sinal de televisão digital, bem como sua inovadora

interatividade com o telespectador, que por sua vez deixa de ter o papel passivo de apenas

assistir, para se tornar um usuário do sistema. Diversas formas de interatividade surgem a

partir daí, e essa foi a questão explorada com os padrões MPEG-7 e MPEG-21 nesta pesquisa.

Ao contrário dos outros padrões MPEG, o padrão MPEG-7 propõe um complemento para

outros padrões, e não um novo método de codificação de vídeo. O mesmo acontece com o

MPEG-21 que propõe uma maneira de interação entre todos os outros padrões.

A interação entre padrões MPEG proposta pelo padrão MPEG-21 pode ser facilmente

aplicada à televisão digital, já que os padrões de televisão digital se baseiam em compressões

de vídeo MPEG para otimizar a transferência de dados. Porém estes recursos não podem ser

explorados na prática pela falta de ferramentas de desenvolvimento capacitadas para realizar

estas operações. Isto também ocorre com o padrão MPEG-7, cujas ferramentas de

desenvolvimento não são totalmente compatíveis com a especificação.

Com o emulador utilizado, o XleTView, também foi inviável a construção do sistema

da forma como era desejada, pois o emulador carece de diversas implementações da API Java

TV e também do middleware MHP, no qual se baseia. Sendo assim, funcionalidades como a

validação de uma compra na loja virtual que necessitariam da utilização do canal de retorno

Page 89: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

89

também não puderam ser testadas, pois o emulador não suporta tal funcionalidade. A

tendência é que a disseminação da televisão digital acarretará na melhoria das condições de

desenvolvimento para aplicações voltadas à tecnologia, com o surgimento de ferramentas que

possibilitarão a implementação de aplicações para tal plataforma.

A precariedade do emulador também nos impossibilitou tirar maiores conclusões sobre

o desempenho do aplicativo. A configuração do computador também influencia na execução

do aplicativo. Sendo assim, espera-se que, rodado num STB, a aplicação não tenha quaisquer

problemas em relação ao desempenho, pois um STB deve ter poder computacional suficiente

para decodificar vídeos digitais e realizar todas as suas outras operações, além de deixar um

restante de sua capacidade para aplicações disponíveis pelas próprias emissoras

Diversas possibilidades para continuações desta pesquisa se abrem. A implementação

do software em um emulador mais avançado, que tenha suporte à funcionalidades como a

comunicação com o canal de retorno, ou a simulação de transmissão de dados de vídeo são

necessárias. Com a comunicação com o canal de retorno é possível a implementação da

validação de uma compra com o servidor, e outras aplicações que necessitem de uma troca de

dados mútua. Já com o suporte à simulação de transmissão de dados de vídeo, é possível

recuperar dinamicamente metadados disponíveis à medida em que são transmitidos,

simulando um ambiente real de televisão digital. Outra opção seria a implementação do item

digital proposto, que no momento da realização desta pesquisa, era inviável. É possível ainda,

fazer um estudo de usabilidade em interfaces de televisão digital, já que se encontram

precárias e as que foram usadas neste trabalho foram totalmente ou parcialmente criadas.

Page 90: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

90

Referências Referências Bibliográficas

ALUR, DEEPARK; CRUPI, JOHN; MALKS, DAN. Core J2EE Patterns: Best Practices and Design Strategies, 2/e. New Jersey: Prentice Hall, 2003 ATSC. Advanced Television Systems Committee. Disponível em http://www.atsc.org. Acesso em 25 fev, 2004. BOOCH, GRADY; RUMBAUGH, JAMES; JACOBSON, IVAR.; The Unified Modeling Language User Guide. Addison-Wesley, 1998. BURNETT, I.; WALLE, R. V.; HILL, K.; BORMANS, J.; PEREIRA, F.; MPEG-21: Goals and Achievements. California: IEEE Computer Society, 2003. CAVENDISH, S. A. Algoritmo de Ajuste Elástico para Vídeo em Fluxos MPEG-2. Dissertação (Mestrado em Ciência da Computação), Pontifícia Universidade Católica do Rio de Janeiro, Brasil, 2005 DAVIC. DAVIC 1.4.1 Specification Part 9: Information Representation. Disponível em: http://www.davic.org/Download/Spec1_2/part09.pdf. Acesso em 30 mar, 1999 DVB. Digital Video Broadcasting Project. Disponível em http://www.dvb.org. Acesso em 25 fev, 2004. FERNANDES, J.; LEMOS, G.; SILVEIRA, G. Introdução à Televisão Digital Interativa: Arquitetura, Protocolos, Padrões e Práticas. Apresentado na Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação, JAI-SBC, Salvador, 2004. FISCHER, W. Digital Television: A practical Guide for Engineers. Springer, Berlin, 2004. FILHO, G. L. S.; LEITE, L. E. C.; BATISTA, C. E. C. F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Departamento de Informática, Universidade Federal da Paraíba , 2007 FREEMAN, E.; FREEMAN. E.; SIERRA, K.; BATES B. Head First: Design Patterns. Sebastopol: O`Reilly, 2001. GARTNER, J. TiVo, the Starving Actor. In: MIT Digital Review, September. Disponível em: http://www.technologyreview.com/BizTech/14734/. Acesso em 24 mar, 2005. HAVI, HAVi, the A/V digital network revolution. Disponível em: http://www.havi.org/pdf/white.pdf - Acesso em 11 jul, 1999. ISDB. ISDB-T - Terrestrial Integrated Services Digital Broadcasting (ISDB-T): Specification of Channel Coding, Framing Structure and Modulation., 1998. LYNCH, T. J., Data Compression: Techniques and Application. New York: Van Nostrand Reinhold, 1985. MARTINEZ, J. M.; KOENEN, R.; PEREIRA, F. MPEG-7: Overview of MPEG-7 Description Tools. California: IEEE Computer Society, 2002. MARTINEZ, J. M.. MPEG-7: the generic Multimedia Content Description Standard. California: IEEE Computer Society, 2002

Page 91: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

91

MATHWORLD. Wolfram Mathworld. Disponível em : http://mathworld.wolfram.com/ -Acesso em 20 mai, 2007. MORRIS, S.; SMITH-CHAIGNEAU, A. Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Oxford: Focal Press, 2005 MPEG1. MPEG-1: Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-1/mpeg-1.htm. Acesso em 24 abr, 1996. MPEG7. MPEG-7 Overview. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm. Acesso em 2 mai, 2004. OLIVEIRA, E. C. R.; ALBUQUERQUE, C. V. N. TV Digital Interativa: Padrões para uma nova era. Disponível em: http://www.ic.uff.br/~celio/papers/eri05.pdf - Acesso em 11 jul, 2005. PAES, A.; ANTONIAZZI, R. Padrões de Middleware para TV Digital. Universidade Federal Fluminense, Niterói, 2005. PENG, C. Digital Television Applications. Dissertação (Doutorado em Ciência da Computação), Helsinki University of Technology, Finlândia, 2002. ZIMET, L. Digital Processing of Analog Television. Department of Electrical Engineering, Stanford University, 2002. Bibliografia Complementar

BURNETT, I. S.; PEREIRA, F.; WALLE, R. V.; KOENEN, R. The MPEG-21 Book. Chichester : John Wiley & Sons Ltd, 2006. CAPDA. TV Digital Interativa. Subgrupo de Trabalho 2 do CAPDA - Comitê das Atividades de Pesquisa e Desenvolvimento na Amazônia, 2004. CHIQUITO, J. G.; ARANTES, D. S.; COSTA, M. H. M. Considerações sobre o relatório final da SET/ABERT para definição do padrão de televisão digital no Brasil. Departamento de Comunicações, Unicamp, São Paulo, 2000. ERONEN, L. and VUORIMAA, P.. User interfaces for digital television: a navigator case study. Disponível em: from http://portal.acm.org/citation.cfm?id=345346. Acesso em 14 mar, 2000. HERIGSTAD, D. and WICHANKY, A.. Designing user interfaces for television. Disponível em: http://portal.acm.org/citation.cfm?id=286645 – Acesso em 22 mar, 1998. KIM, H.; MOREAU, N.; SIKORA, T. MPEG-7 Audio and Beyond: Audio Content Indexing and Retrieval. Chichester : John Wiley & Sons Ltd, 2005. KOSCH, H. Distributed Multimedia Database Technologies Supported by MPEG-7 and MPEG-21. London: CRC Press, 2004. LIU, P.; HSU, L. Queries of Digital Content Descriptions in MPEG-7 and MPEG-21 XML documents, 2001. LOUREIRO, J. A. Interfaces de Programação para o Desenvolvimento de Aplicações para TV Digital. Trabalho de Graduação, Universidade Federal de Pernambuco, 2004.

Page 92: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

92

MHP. An Introduction to MHP - White Paper. Disponível em: http://www.mhp.org/about_mhp/WP02%20(MHP).pdf. Acesso em 12 mar, 2005. MPEG. The MPEG handbook. Oxford: Focal Press, 2001 MPEG2. MPEG-2 : Generic coding of moving pictures and associated audio information. Disponível em : http://www.chiariglione.org/mpeg/standards/mpeg-2/mpeg-2.htm. Acesso 25 abr, 2000. MPEG4. Overview of the MPEG-4 standard. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm. Acesso em 3 mai, 2002. MPEG21. MPEG-21 Overview. Disponível em: http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm. Acesso em 2 mai, 2002. PAWLAN, M.. Introduction to Digital TV Applications Programming. Disponível em: http://java.sun.com/developer/technicalArticles/javatv/apiintro/index.html. Acesso em 02 fev, 2001. PENG, C. and VUORIMAA, P. A digital television navigator. Disponível em: http://portal.acm.org/citation.cfm?id=376335 – Acesso em 22 mar, 2000. PIMENTEL, C. A. F. Uma análise do uso do padrão MPEG-7 pela ferramenta IBM Annotation Tool, 2006. SILVA, F. P. R.; SOUSA, A. H. S.; LEMOS, G. Aplicações para TV Digital Interativa. Departamento de Informática, Universidade Federal da Paraíba, João Pessoa, 2004. SIVARAMAN, G.; CESAR, P.; VUORIMAA, P. System software for digital television applications. Tokyo: IEEE, 2001. SUWELACK, S., GANTES, F. and HERNÁNDEZ, A.. Introduction to MPEG-21. Disponível em: http://emfs1.eps.hw.ac.uk/~ceeet1/b39si2/winner05-MPEG21.pdf. Acesso em 04 abr, 2005. ZIMET, L. Digital Processing of Analog Television. Department of Electrical Engineering, Stanford University, 2002.

Page 93: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL

93

Anexo

Page 94: APLICAÇÃO DOS PADRÕES MPEG-7 E MPEG-21 EM TV DIGITAL