Embed Size (px)
Citation preview
Daniel Augusto de Andrade Sacramento
Um Estudo de Desempenho Entre Linguagens Declarativas para TV Digital
Dissertação apresentada à Secretaria do Programa de Pós-Graduação em Engenharia Elétrica (PPGEE) da Universidade Federal de Minas Gerais (UFMG).
Orientadora: Jussara M. de Almeida
Co-Orientadora: Linnyer B. Ruiz
Belo Horizonte
2008
Resumo
A TV digital é uma tecnologia que chega ao Brasil trazendo melhorias na qualidade
de imagem, som, transmissão e recepção, além de introduzir o conceito de
interatividade entre o telespectador e os programas de televisão. Esta interatividade é
possível graças à camada denominada “mediador” presente na arquitetura padrão do
sistema de TV digital. Para ser capaz de prover esta interatividade, entretanto, o
mediador utiliza aplicações escritas em linguagens declarativas. Uma vez que cada
um dos padrões de sistema de TV digital existentes atualmente adota um mediador
diferente, que por sua vez utiliza linguagens declarativas diferentes, uma comparação
de desempenho entre estas linguagens faz-se interessante. Sendo assim, esta
dissertação de mestrado apresenta uma comparação quantitativa do desempenho das
linguagens Nested Context Language (NCL), adotada pelo mediador do Sistema
Brasileiro de TV Digital e Synchronized Multimedia Integration Language (SMIL),
utilizada para sincronismo de mídias na Web, recomendada pelo World Wide Web
Consortium (W3C) e tida como opção de extensão ao mediador do atual sistema
europeu de TV digital. Tendo em vista a importância de haver uma linguagem
declarativa padrão que seja interpretada por todos os mediadores, possibilitando assim
o intercâmbio de conteúdo e programação entre os diferentes sistemas de TV digital,
os resultados desta dissertação visam também levantar o potencial de NCL para
tornar-se esse padrão. A dissertação analisa ainda o impacto que velocidade de CPU e
quantidade de memória RAM têm sobre o desempenho das linguagens analisadas.
Abstract
The digital TV is a technology that comes to Brazil providing better quality of image,
sound, transmission, and also introduces the interactivity concept between users and
the channel programs. This interactivity has been possible due to a layer called
“middleware” which is present on the digital TV architecture system. In order to be
able to provide such interactivity, the middleware uses applications developed through
declarative languages. Since each digital TV system standard adopts different
middlewares, which also uses its own declarative language, it is relevant to carry out a
a performance comparison of those languages. Therefore, this dissertation presents a
quantitative performance comparison of Nested Context Language (NCL); adopted by
the Brazilian Digital TV System middleware, and Synchronized Multimedia
Integration Language (SMIL), a World Wide Web Consortium (W3C) recommended
markup language for describing multimedia presentations and an option for the
extension of the European Digital TV System middleware. Once it’s important to
have a standard declarative language that can be compatible with all middlewares,
thus allowing the interchange of content and programming among the different TV
digital systems, the results of this dissertation also intend to analyze the potential of
NCL becoming this standard language. Aside from that, this dissertation also analyses
the impact of the CPU velocity and the amount of RAM memory have on the
performance of the languages mentioned above.
Agradecimentos
Agradeço em primeiro lugar a Deus, por ter me iluminado, abençoado e
protegido durante toda a minha vida.
À minha esposa Luciane Rabelo pelo amor, apoio, incentivo e principalmente
paciência na minha ausência e nos meus rompantes de todos os tipos.
Aos meus pais e irmãos pela presença, força e por terem tornado possível
chegar até aqui.
À minha orientadora, Jussara Almeida, por aceitar o desafio de me orientar,
pelas cobranças e críticas sempre construtivas.
À minha co-orientadora Linnyer Ruiz, pelo apoio, acompanhamento e
conselhos desde antes do meu ingresso no mestrado.
Agradecimentos especiais a Rogério Ferreira Rodrigues e Vitor Medina Cruz
do laboratório TeleMídia da PUC-Rio por me atenderem tão prontamente, fornecendo
informações e ajuda indispensáveis a este trabalho.
Aos meus amigos da Synos Technologies que me incentivaram,
acompanharam, se envolveram e me possibilitaram dedicar-me a este projeto.
III
Sumário
1 Introdução ......................................................................................................... 1
1.1 Motivação.................................................................................................. 3
1.2 Objetivos ................................................................................................... 3
1.3 Contribuições............................................................................................. 4
1.4 Organização............................................................................................... 5
2 Domínio de Estudo ............................................................................................ 7
2.1 Componentes da TV Digital....................................................................... 7
2.1.1 Difusor............................................................................................... 8
2.1.2 Meios de Difusão ............................................................................... 8
2.1.3 Receptor............................................................................................. 9
2.2 Novidades da TV Digital............................................................................ 9
2.3 Tecnologias Utilizadas na TV Digital........................................................10
2.3.1 Aplicativos........................................................................................13
2.3.2 Compressão.......................................................................................15
2.3.3 Mediador...........................................................................................17
2.3.3.1 Nested Context Language (NCL)...................................................18
2.3.3.2 Synchronized Multimedia Integration Language (SMIL) ...............21
2.3.4 Transporte .........................................................................................24
2.3.5 Modulação ........................................................................................24
2.4 Principais Sistemas de TV Digital .............................................................25
2.4.1.1 ATSC (Advanced Television System Committee) .........................25
2.4.1.2 DVB (Digital Video Broadcasting)................................................26
2.4.1.3 ISDB (Integrated Services Digital Broadcasting) ...........................27
2.4.1.4 SBTVD (Sistema Brasileiro de TV Digital) ...................................27
IV
3 Metodologia de Avaliação ................................................................................30
3.1 Cargas.......................................................................................................30
3.2 Projeto Experimental.................................................................................31
3.2.1 Testes em Observações Pareadas.......................................................35
3.2.2 Observações Não Pareadas ................................................................35
3.3 Ambiente e Ferramental ............................................................................36
3.3.1 Cenários de Avaliação.......................................................................36
3.3.2 Tocador X-Smiles .............................................................................38
3.3.3 Tocador Ginga X-Smiles ...................................................................40
3.4 Limitações ................................................................................................41
4 Resultados Experimentais .................................................................................43
4.1 Utilização de Memória RAM ....................................................................43
4.2 Execuções Com Tempo de Carga..............................................................47
4.2.1 Desempenho Relativo entre NCL e SMIL .........................................47
4.2.2 Impacto do Tipo de Mídia .................................................................53
4.2.3 Sumário.............................................................................................55
4.3 Execuções Sem Tempo de Carga ..............................................................55
4.3.1 Desempenho Relativo entre NCL e SMIL .........................................56
4.3.2 Impacto do Tipo de Mídia .................................................................58
4.3.3 Sumário.............................................................................................62
4.4 Impacto da Variação de Velocidade de CPU e Quantidade Memória RAM
63
4.4.1 Execuções Com Tempo de Carga ......................................................63
4.4.2 Execuções Sem Tempo de Carga.......................................................66
4.4.3 Sumário.............................................................................................68
5 Conclusão e Trabalhos Futuros .........................................................................70
V
5.1 Conclusão .................................................................................................70
5.2 Trabalhos Futuros .....................................................................................71
6 Referências Bibliográficas ................................................................................72
Apêndice A – Arquivos NCL ...................................................................................76
Apêndice B – Arquivos SMIL ..................................................................................92
Apêndice C – Execuções Com Tempo de Carga .......................................................97
Apêndice D – Execuções Sem Tempo de Carga......................................................101
VI
Lista de Figuras
Figura 1 - Tela plana 16:9 exibindo barras coloridas e data de inauguração da TV
digital no Brasil [12].................................................................................................. 1
Figura 2 - Modelo do sistema de TV digital............................................................... 8
Figura 3 - Arquitetura padrão da TV digital ..............................................................10
Figura 4 - Arquitetura da TV digital por componentes do modelo.............................12
Figura 5 - Tecnologias utilizadas em cada camada da arquitetura de um sistema de TV
digital .......................................................................................................................13
Figura 6 - Exemplo de uma aplicação EPG [16] .......................................................14
Figura 7 - Exemplo de arquivo NCL.........................................................................19
Figura 8 - Exemplo de um arquivo SMIL .................................................................22
Figura 9 - Tecnologias adotadas pelo padrão ATSC..................................................26
Figura 10 - Tecnologias adotadas pelo padrão DVB .................................................26
Figura 11 - Tecnologias adotadas pelo padrão ISDB.................................................27
Figura 12 - Tecnologias adotadas pelo padrão SBTVD.............................................29
Figura 13 - Número de classes carregadas por etapa de execução .............................34
Figura 14 -Tempos referentes à execuções com e sem tempo de carga para NCL e
SMIL........................................................................................................................34
Figura 15 - Arquitetura interna do navegador X-Smiles ............................................40
Figura 16 - Arquitetura interna do navegador Ginga X-Smiles..................................41
Figura 17 - Uso de memória na geração Tenured em SMIL ......................................45
Figura 18 – Tempo médio de interpretação coletados em cinco execuções
consecutivas de um arquivo SMIL............................................................................45
Figura 19 - Uso de memória na geração Tenured em NCL........................................46
Figura 20 - Tempo médio de interpretação coletados em cinco execuções consecutivas
de um arquivo NCL..................................................................................................46
VII
Figura 21 - NCL x SMIL com vídeos em execuções com tempo de carga.................49
Figura 22 - NCL x SMIL com imagens em execuções com tempo de carga ..............51
Figura 23 – Média e intervalo de confiança de NCL com imagens em execuções com
tempo de carga .........................................................................................................52
Figura 24 - Comparativo do tempo médio com tempo de carga para os quatro objetos
de mídia em arquivos NCL.......................................................................................54
Figura 25 - Comparativo do tempo médio com tempo de carga para os quatro objetos
de mídia em arquivos SMIL .....................................................................................54
Figura 26 - NCL x SMIL com vídeos em execuções sem tempo de carga .................57
Figura 27 - Comparativo do tempo médio sem tempo de carga para os quatro objetos
de mídia em arquivos NCL.......................................................................................59
Figura 28 - Comparativo do tempo médio sem tempo de carga para os quatro objetos
de mídia em arquivos SMIL .....................................................................................59
Figura 29 - Comparativo entre NCL e as duas abordagens de SMIL para arquivos com
áudios em execuções sem tempo de carga.................................................................61
Figura 30 - Comparativo entre SMIL e as duas abordagens de NCL para arquivos com
textos em execuções sem tempo de carga .................................................................62
Figura 31 - Comparativo do tempo médio com tempo de carga para os quatro cenários
propostos em arquivos NCL com vídeo ....................................................................64
Figura 32 - Comparativo do tempo médio com tempo de carga para os quatro cenários
propostos em arquivos SMIL com vídeo...................................................................65
Figura 33 - Comparativo do tempo médio sem tempo de carga para os quatro cenários
propostos em arquivos NCL com vídeo ....................................................................67
Figura 34 - Comparativo do tempo médio sem tempo de carga para os quatro cenários
propostos em arquivos SMIL com vídeo...................................................................67
VIII
Lista de Tabelas
Tabela 1 - Tempo medido x tempo considerado........................................................32
Tabela 2 - Fatores variados nos experimentos...........................................................38
Tabela 3 - Diferença de desempenho das linguagens para interpretar vídeos e áudios
em execuções com tempo de carga ...........................................................................50
Tabela 4 - Diferença de desempenho das linguagens para interpretar imagens e textos
em execuções com tempo de carga ...........................................................................53
Tabela 5 - Diferença de desempenho das linguagens para interpretação em execuções
sem tempo de carga ..................................................................................................58
Tabela 6 - Impacto de velocidade de CPU e quantidade de memória RAM em
execuções com tempo de carga.................................................................................66
Tabela 7 - Impacto de velocidade de CPU e quantidade de memória RAM em
execuções sem tempo de carga .................................................................................68
1
1 Introdução
Ao longo dos últimos anos tem-se discutido em muitos meios sobre a TV digital,
principalmente no Brasil. A TV digital proporciona uma melhora significativa na
qualidade da imagem e do som, pois a transmissão de áudio e vídeo passa a ser feita
através de sinais digitais que, codificados, permitem um uso mais eficiente do
espectro eletromagnético [53]. O resultado disto é a viabilização da Televisão de Alta
Definição (High-Definition TeleVision - HDTV) que é capaz de reproduzir imagens
com definição de 1.080 linhas horizontais contra apenas 480 linhas horizontais da
Televisão com Definição Normal (Standard Definition TeleVision - SDTV). Além
disso, a imagem passará do formato 4:3 – onde a tela é quase quadrada - para o
formato 16:9, às vezes chamado de “tela de cinema” (widescreen). Já o som passará
de dois canais (estéreo) para seis canais, padrão utilizado por sofisticados
equipamentos de som, os chamados home theaters [6].
De fato, as primeiras imagens da TV digital no Brasil começaram a ser transmitidas
no dia 2 de Dezembro de 2007 para a grande São Paulo, e consistem na data de
inauguração da transmissão sobre barras coloridas em uma tela 16:9, conforme
mostrado na Figura 1. As operações experimentais começaram em Belo Horizonte em
Fevereiro de 2008, enquanto que as cidades de Brasília, Fortaleza, Rio de Janeiro e
Salvador deveriam começar a operar comercialmente o sistema digital até Julho [8].
As transmissões iniciais serão com resolução normal (SDTV) e a tecnologia HDTV
será introduzida gradualmente [12].
Figura 1 - Tela plana 16:9 exibindo barras coloridas e data de inauguração da TV digital no
Brasil [12]
Atualmente, existem em todo o mundo três principais sistemas de TV digital: o
sistema americano (Advanced Television System Comittee - ATSC [1]), o sistema
2
europeu (Digital Video Broadcasting - DVB [10]) e o sistema japonês (Integrated
Services Digital Broadcasting - ISDB [22]). Em Junho de 2006, o Brasil adotou o
padrão japonês, que já prevê a recepção de programas de TV em telefones celulares e
outros dispositivos eletrônicos portáteis, além de contar com aplicações de previsão
do tempo, notícias e jogos, com menu de opções semelhante à Internet.
Além da imagem e som, o sinal da TV digital também transmite dados. Esses dados
permitem interatividade entre o telespectador e os programas, possibilitando o acesso
a informações sobre a programação da emissora, votar em uma enquete e até mesmo
ser direcionado para uma loja virtual que, por exemplo, venda as roupas utilizadas
pelos atores de um filme. Tudo isso é disponibilizado ao alcance de um botão no
controle remoto. Esta interatividade é possível graças à camada denominada
“Mediador” (middleware). Posicionada entre os aplicativos e a camada de transporte,
o mediador é uma das cinco camadas que compõem os sistemas de TV digital [6].
Apesar da transmissão de dados trazer grande potencial de aplicações para a TV,
incluindo acesso à Internet, em um futuro próximo a TV tende a ser atropelada pela
Internet. Isto porque atualmente a Internet já possibilita não só os programas de TV
(filmes, seriados, TV aberta etc) como também vídeos de alta qualidade em sítios
como o YouTube, por exemplo. Desta forma a TV chega “atrasada” para competir,
pois além da questão cultural relacionada ao tempo que a população levará até utilizar
massivamente o acesso à Internet e serviços pela TV, existe ainda a questão
tecnológica do canal de interação (vide seção 2.1). Para que a experiência de troca de
dados e navegação na Internet seja eficiente, o canal de interação deve ser de banda
larga ou a velocidade será a mesma de uma conexão discada. Em uma país onde a TV
é altamente difundidada, mas acesso de banda larga é ainda privilégio de poucos, a
viabilização do canal de iteração de forma eficiente e barata para que a TV sobreviva
à Internet ainda é um desafio.
Conteúdos para TV digital interativa são usualmente concebidos usando uma
linguagem declarativa. Pode-se citar duas linguagens declarativas, a Nested Context
Language (NCL) [48] e a Synchronized Multimedia Integration Language (SMIL)
[61]. A NCL foi proposta como a linguagem do mediador declarativo Ginga [50] para
o Sistema Brasileiro de TV Digital [46]. A SMIL é a linguagem recomendada pelo
The World Wide Web Consortium (W3C) para sincronismo de mídias na Web e
proposta por (Pihkala et al., 2002) [32] para ser utilizado na TV digital, bem como em
3
dispositivos móveis. SMIL também é tida como uma opção de extensão ao mediador
declarativo do atual sistema europeu de TV digital (Digital Video Broadcasting -
DVB) [49].
1.1 Motivação
Conhecendo-se as duas linguagens declarativas citadas na seção anterior, é de
interesse uma comparação dos pontos positivos e negativos de ambas. Trabalhos
anteriores como os apresentados por (Rodrigues e Soares, 2006) [39] e (Saade et al.,
2003) [41] comparam a estrutura interna e semântica de ambas as linguagens. O
aplicativo apresentado por (Vieira et al., 2004) [57] utiliza SMIL para sincronismo de
áudio e vídeo em apresentações para ensino a distância, enquanto (Pihkala et al.,
2002) [32] e (Pihkala et al., 2001) [33] apresentam comparações de uso de memória e
tempo de CPU gastos por diferentes arcabouços Java para interpretação e reprodução
de arquivos SMIL. Porém, nenhum dos trabalhos mencionados compara o
desempenho da interpretação de arquivos equivalentes entre as duas linguagens.
Levando-se em conta que a interatividade provida pelas linguagens declarativas é uma
das maiores contribuições da TV digital, é de interesse conhecer o desempenho de
cada uma. Assim, o presente trabalho contribui apresentando um estudo experimental
de avaliação do desempenho estimado pelo tempo de CPU gasto para interpretar
arquivos de ambas as linguagens, com os diferentes objetos de mídia suportados,
como texto, imagem, áudio e vídeo, em diferentes configurações de memória e
velocidade de CPU.
1.2 Objetivos
Este trabalho tem como principal objetivo realizar um estudo de avaliação
experimental do desempenho da interpretação das linguagens NCL e SMIL,
considerando:
• Diferentes tipos de mídia, como texto, imagem, áudio e vídeo;
• Diferentes números de objetos de mídia em um mesmo arquivo;
• Plataformas com diferentes configurações de memória e CPU.
Assim, objetiva-se avaliar o desempenho relativo em diferentes cenários, bem como a
escalabilidade de cada linguagem.
4
Além disso, o trabalho possui como objetivo secundário medir o impacto que
velocidade (clock) de CPU e quantidade de memória principal têm sobre o tempo de
CPU gasto para interpretar as linguagens analisadas. Alcançando-se este objetivo é
possível conjecturar sobre qual linguagem seria mais adequada para dispositivos
eletrônicos portáteis, como telefones celulares e PDA’s (Personal Digital Assistant –
Assistente Digital Pessoal), aparelhos que possuem baixa velocidade de CPU e
pequena quantidade de memória RAM.
1.3 Contribuições
A fim de realizar o estudo proposto, foi implementado um tocador em Java capaz de
reproduzir tanto arquivos NCL quanto SMIL. Este tocador possibilita uma avaliação
justa das duas linguagens, eliminando ruídos secundários devido à utilização de
tocadores específicos, mas mantendo as características dos tocadores originais, sem
qualquer interferência no código que pudesse beneficiar/prejudicar uma das
linguagens. Além disso, a realização dos vários experimentos projetados,
considerando-se os cenários e cargas avaliados e descritos na seção 3, levou às
seguintes observações principais a respeito do desempenho relativo entre NCL e
SMIL:
• Durante execuções consecutivas de um arquivo, a primeira execução – que
inclui o tempo de carga (vide Capítulo 3) - em ambas as linguagens, é mais
lenta que as demais execuções.
• SMIL usa uma quantidade de memória praticamente constante durante
execuções consecutivas, dispensando a execução do coletor de lixo da
máquina virtual Java. NCL usa maior quantidade de memória que SMIL em
execuções consecutivas, sendo necessária a execução do coletor de lixo da
máquina virtual Java, o que termina por influenciar o desempenho desta
linguagem, aumentando o tempo de interpretação para um mesmo arquivo.
• Em execuções com tempo de carga (vide Capítulo 3), NCL possui
desempenho inferior a SMIL, apresentando tempo médio de interpretação no
mínimo 22,5% e no máximo 1153%, ou seja, quase treze vezes maior que
SMIL.
5
• Em execuções sem tempo de carga (vide Capítulo 3), NCL possui desempenho
superior a SMIL, apresentando tempo médio de interpretação no mínimo
38,1% e no máximo 99,1% menor que SMIL.
• Comparando-se uma configuração com velocidade de CPU e quantidade de
memória RAM típica de um computador comum a uma configuração
encontrada em PDA’s de última geração, tanto em NCL quanto em SMIL a
velocidade de CPU é muito mais impactante no tempo de interpretação dos
arquivos do que a variação da quantidade de memória RAM. Enquanto a
velocidade de CPU impacta no mínimo 130% e no máximo 499%, quantidade
de memória RAM possui impacto entre 3,3% e 39,8% no tempo de
interpretação.
• Foi encontrado e corrigido um erro no código do interpretador de arquivos
NCL. Este erro fazia com que não houvesse cache dos recursos de texto
utilizados, sendo necessário reler estes recursos e recriar os objetos em
memória a cada execução, prejudicando assim seu tempo de interpretação. A
correção do interpretador apresentou ganho de cerca de 40% no tempo médio
de interpretação para arquivos com mais de cinco recursos.
• Através das técnicas utilizadas no interpretador de arquivos NCL contendo
áudios, foi possível otimizar o interpretador de arquivos SMIL contendo esse
tipo de mídia. Esta otimização apresentou ganho de cerca de 80% no tempo
médio de interpretação para arquivos com qualquer quantidade de recursos de
áudio.
1.4 Organização
O restante desta dissertação está organizado como se segue. O Capítulo 2 apresenta os
conceitos, sistemas disponíveis, histórico da TV digital no Brasil, bem como os
principais componentes de sua arquitetura, além da revisão bibliográfica de trabalhos
envolvendo estas tecnologias. O Capítulo 3 descreve a carga, a metodologia de
categorização dos dados coletados, o ambiente de testes e os cenários avaliados
durante o estudo experimental. O Capítulo 4 apresenta os resultados principais obtidos
através da medição, coleta e análise dos valores obtidos durante a realização do estudo
6
experimental. O Capítulo 5 apresenta um resumo conclusivo desse trabalho e
propostas de trabalhos futuros.
7
2 Domínio de Estudo
Este capítulo tem como objetivo explicar o funcionamento de um sistema de TV
digital, apresentando os componentes que compõem este sistema, sua arquitetura em
camadas e as tecnologias utilizadas em cada camada, além de apresentar os principais
sistemas existentes atualmente.
A Seção 2.1 deste capítulo apresenta um modelo genérico do sistema de TV digital e
explica a função de cada um de seus componentes. Através deste modelo é possível
entender o caminho realizado pela transmissão de um programa de televisão desde sua
origem na emissora até o aparelho de TV dos telespectadores. A Seção 2.2 aborda as
principais vantagens da TV digital se comparada à TV analógica. Na Seção 2.3 são
detalhados os aplicativos e tecnologias utilizados por cada uma das camadas da
arquitetura do sistema de TV digital, apresentando ainda os trabalhos relacionados.
Por fim, os principais sistemas de TV digital existentes atualmente e a história do
sistema brasileiro - desde sua concepção até sua definição - são abordados na Seção
2.4.
2.1 Componentes da TV Digital
Conforme mencionado anteriormente a TV digital é uma nova tecnologia de
transmissão de sinais de televisão. Como em qualquer sistema, uma vez que há
transmissão, é natural concluir que há um responsável pela geração do conteúdo
transmitido e, principalmente, que há um receptor para este conteúdo. Assim, um
sistema de TV digital pode ser decomposto em três partes conforme definido por
(Becker e Montez, 2005) [6]: um difusor, um meio de difusão e um receptor. Em
relação ao sistema de TV analógico, o sistema de TV digital possui dois novos
elementos: o Set Top Box e o Canal de Interação, ambos relacionados ao receptor.
Um modelo genérico do sistema de TV digital juntamente com seus principais
componentes é mostrado na Figura 2, e seus componentes são detalhados nas
subseções a seguir.
8
Figura 2 - Modelo do sistema de TV digital
2.1.1 Difusor
A principal função do difusor - também conhecido como emissor - é gerar e enviar o
sinal com o conteúdo dos programas de televisão. Esta transmissão é realizada de
forma unidirecional, ou seja, apenas do difusor para o receptor através do canal de
difusão. O sinal transmitido no sistema de TV digital contém, além dos fluxos de
áudio e vídeo já existentes nas transmissões de TV convencionais, um terceiro fluxo
denominado fluxo de dados. Estes dados podem variar desde legendas ou dublagens
de um filme em vários idiomas até uma aplicação a ser executada no receptor [6],
como por exemplo a aplicação para declaração de isento do imposto de renda, prevista
para entrar em funcionamento a partir de 2009 [9].
A segunda função do difusor é dar suporte às interações dos telespectadores com os
programas e aplicativos que suportam interatividade. O difusor tanto recebe os dados
referentes às interações dos usuários quanto envia dados de resposta através do canal
de interação.
2.1.2 Meios de Difusão
Os meios de difusão mais comuns são: satélite, cabo e radiodifusão (também
conhecida como difusão terrestre). A principal função dos meios de difusão é fazer
com que o sinal gerado e transmitido pelo difusor seja entregue ao receptor. Além
disso, os meios de difusão também são utilizados para transmitir os dados do canal de
interação. Apesar de conceitualmente o canal de interação ter a mesma capacidade de
um canal de difusão, devido à limitações tecnológicas, este canal é tratado como tendo
pequena largura de banda, de forma que seja possível utilizar, por exemplo, uma linha
telefônica como meio de difusão [6].
9
2.1.3 Receptor
Receptor é o destino final das transmissões de TV, ou seja, a televisão do
telespectador. O receptor pode ser tanto a TV propriamente dita (chamada TV digital
completa [6]) quanto um aparelho à parte chamado Set Top Box (STB). O STB é
responsável por converter o sinal digital recebido em um sinal analógico compatível
com os aparelhos de televisão convencionais. Além disso, o STB também pode
possuir o canal de interação, responsável por possibilitar interatividade aos
telespectadores. Essa interatividade é provida por diversos aplicativos (explicitados na
Seção 2.3.1) e é através do canal de interação que as ações feitas pelo usuário chegam
ao difusor. Durante a transmissão de uma partida de futebol, por exemplo, o difusor
pode disponibilizar uma enquete sobre qual o melhor jogador em campo. O
telespectador através do controle remoto de sua TV vota na enquete e os dados
referentes a esse voto são levados pelo canal de interação até o difusor. O difusor
então soma esse voto e retorna o resultado parcial, também através do canal de
interação, para que o STB possa mostrar o resultado na TV.
2.2 Novidades da TV Digital
Uma vez que a TV digital é a evolução da TV analógica, a adoção desse novo sistema
traz consigo vários avanços tecnológicos que têm como objetivo levar ao
telespectador uma nova experiência ao assistir televisão. As principais melhorias são
destacadas abaixo:
• Viabilização da Televisão de Alta Definição (HDTV), capaz de reproduzir
imagens com definição de 1.080 linhas horizontais contra apenas 480 linhas
horizontais da Televisão com Definição Normal (SDTV) [6]. Isto significa que
a imagem poderá ser vista com muito mais detalhes que anteriormente;
• O atual formato 4:3, onde a tela é quase quadrada, será substituído pelo
formato 16:9, onde a imagem é mais larga e assemelha-se ao formato da tela
de cinema;
• Recepção do sinal de TV em movimento, possibilitando assistir TV dentro de
um carro ou ônibus em movimento com a mesma qualidade de uma TV
parada;
10
• Capacidade de transportar múltiplos programas com vídeo, diversos áudios,
texto e dados, possibilitando assistir a um filme e escolher o idioma do áudio e
da legenda (tal qual os DVDs), escolher entre diversos ângulos para assistir
um programa (jogo de futebol, shows) etc;
• Oferecimento de serviços interativos – possíveis devido à inclusão do canal de
interação no sistema de TV – como previsão do tempo, notícias, jogos, acesso
à Internet, acesso à programação dos canais etc. Dentre estes vale destacar as
aplicações que permitirão o chamado t-commerce - comércio eletrônico
televisivo [6] - onde com apenas um clique no controle remoto será possível
comprar um produto ofertado durante um comercial, por exemplo.
2.3 Tecnologias Utilizadas na TV Digital
Apesar das discussões sobre TV digital serem recentes no Brasil, em vários outros
países esta tecnologia já foi desenvolvida e até mesmo implantada. Atualmente,
existem três principais padrões definidos em todo o mundo: o americano (ATSC), o
europeu (DVB) e o japonês (ISDB). Para um melhor entendimento, um sistema de TV
digital pode ser dividido em camadas, conforme mostrado na Figura 3. A função de
cada camada, bem como as tecnologias existentes em cada uma, são detalhadas
posteriormente nesta seção.
Figura 3 - Arquitetura padrão da TV digital
11
Conforme apresentado anteriormente, um sistema de TV digital é formado pelo
difusor, meios de difusão e receptor. Além disso, foram apresentadas várias camadas
que compõe este sistema. A Figura 4 tem como objetivo apresentar a interação destas
camadas tanto no difusor quanto no receptor, possibilitando observar o caminho
percorrido pelos dados através das diferentes camadas até chegar à TV do
telespectador. Uma vez que há um programa da emissora a ser transmitido, os sinais
de áudio e vídeo deste programa são comprimidos pela camada de compressão. Caso
este programa permita interatividade por parte do telespectador, são utilizados
aplicativos em conjunto com o mediador para geração de dados que permitam esta
interatividade. Tanto os sinais comprimidos de áudio e vídeo quanto os dados gerados
passam pela camada de transporte e pela camada de modulação – onde as ondas
eletromagnéticas são alteradas de acordo com o sinal a ser transmitido – para então
serem transmitidos através do canal de difusão. Uma vez difundido, o sinal é captado
pelo receptor - por uma antena por exemplo - e passa pelo processo inverso ao
realizado no difusor. O sinal passa pelas camadas de demodulação e transporte. Os
sinais de áudio e vídeo passam pela camada de descompressão e os dados de
interatividade passam pelo mediador, chegando finalmente à TV, exibindo o
programa e os recursos de interatividade para o telespectador. Uma vez que haja
interação por parte do telespectador, as informações referentes às suas ações são
enviadas de volta ao difusor através do canal de interação. Estas informações são
processadas pelo provedor de interatividade e o retorno é enviado de volta, também
pelo canal de interação.
12
Figura 4 - Arquitetura da TV digital por componentes do modelo
Conforme exposto por (Becker e Montez, 2005) [6], a melhor forma de ilustrar um
sistema complexo é representar sua arquitetura, mostrando seus elementos principais.
Assim, a Figura 5 destaca as tecnologias existentes em cada uma das cinco camadas
da arquitetura padrão de um sistema de TV digital, a saber: aplicativos, compressão,
mediador, transporte e modulação. As subseções a seguir detalham a função de cada
camada, as tecnologias utilizadas por elas e os trabalhos relacionados.
13
Figura 5 - Tecnologias utilizadas em cada camada da arquitetura de um sistema de TV digital
2.3.1 Aplicativos
Aplicativos são utilizados tanto no lado do difusor quanto no lado do receptor. No
caso do difusor, os aplicativos são utilizados principalmente para geração de conteúdo
e interatividade. Já do lado do receptor os aplicativos têm como principal função
prover serviços ao telespectador.
Conforme mencionado anteriormente, um dos principais avanços inseridos pela
adoção da TV digital é a possibilidade de interação do telespectador. Ao invés de
apenas receber o conteúdo unilateralmente, o telespectador agora é capaz de tomar
decisões, navegar na Internet, fazer compras, dentre outros serviços. Toda essa
interação é provida pelos chamados “aplicativos interativos”, presentes na camada
mais alta da arquitetura da TV digital.
Um dos serviços mais simples disponível na TV Digital, é o chamado EPG (Eletronic
Program Guide – Guia de Programação Eletrônico) que consiste em uma interface
gráfica com textos informativos sobre o nome, gênero, horário e outras informações
referentes ao guia de programação disponibilizado pelos canais. Um exemplo de EPG
pode ser visto na Figura 6. Uma proposta de uma arquitetura flexível - que provê
suporte aos padrões de arquivos XML e as chamadas Tabelas SI (Service Information
14
– Serviço de Informação) - para montagem dos EPGs pelas emissoras de televisão,
transmissão dos mesmos e armazenamento no Set Top Box é apresentada por (Neto et
al., 2005) [29].
Figura 6 - Exemplo de uma aplicação EPG [16]
As aplicações chamadas de t-gov ou t-governo permitem o oferecimento de serviços
governamentais pela TV. (Becker e Montez, 2005) [6] citam que serviços referentes a
cartórios, prefeituras, postos de informações, programas como Bolsa Família e Fome
Zero, antes disponíveis apenas pela Internet, serão acessíveis pela TV. Com isso evita-
se o deslocamento da população e diminui-se a burocracia.
T-commerce é o termo que identifica o comércio eletrônico através da TV. As
aplicações provedoras de comércio na TV possibilitarão que os telespectadores
comprem produtos através do controle remoto, seja durante um comercial, um
programa de TV ou navegando em lojas virtuais.
Outra função que a TV digital agrega é a navegação na Internet. Através da TV e do
uso do controle remoto será possível navegar pela Internet e acessar todas as suas
funções.
Além dos aplicativos citados, que são utilizados pelos telespectadores, existem
também os aplicativos utilizados pelos provedores de conteúdo. Pode-se citar como
exemplo os aplicativos “Composer” e “EasyPres”. O Composer é uma ferramenta que
permite o desenvolvimento de arquivos NCL (Nested Context Language) através de
um ambiente gráfico. Com este aplicativo, um usuário pode criar um arquivo NCL
sem conhecer sua estrutura interna, apenas inserindo os objetos de mídia (texto,
15
imagem, vídeo, áudio, interação etc) desejados. Além disso, possui ainda um tocador
de arquivos NCL que permite a execução dos arquivos gerados. O EasyPres,
apresentado por (Vieira et al., 2004), consiste em uma ferramenta para criação de
apresentações e palestras para educação a distância, utilizando SMIL (Synchronized
Multimedia Integration Language) para sincronizar áudio e vídeo.
É importante ressaltar ainda que outros aplicativos interativos podem ser
desenvolvidos para a TV digital, sendo esse assunto tema de vários trabalhos atuais.
As principais novidades trazidas pela TV digital, dando maior enfoque à
interatividade do telespectador, são abordadas em (Fonseca, 2007) [16]. Os trabalhos
apresentados por (Hattori et al.) [18] e (Simioni e Roesler, 2006) [45] propõem
arcabouços distintos, ambos desenvolvidos na linguagem Java, que têm como objetivo
final facilitar o desenvolvimento de novas aplicações interativas. (Valdestilhas e
Almeida, 2005) [55] discutem a questão da usabilidade das aplicações desenvolvidas
para a TV interativa, objetivando minimizar a exclusão digital. O estudo apresentado
por (Joly, 2003) [27] refere-se à programação educativa destinada à TV interativa e
propõe o uso de aplicativos para apresentação de contos de fada, onde o telespectador
pode intervir na história através da interatividade.
2.3.2 Compressão
A camada de compressão implementa mecanismos para, como o próprio nome diz,
comprimir, ou seja, reduzir o espaço ocupado pelos dados de áudio e vídeo do
conteúdo a ser transmitido. A compressão de áudio e vídeo se faz necessária para que
seja viável trafegar essas informações nos meios de difusão disponíveis. Conforme
exemplo mostrado por (Becker e Montez, 2005) [6], uma hora de vídeo em qualidade
VHS (vídeocassete) ocupa 24,3 GBytes. Considerando-se uma conexão ADSL
(Asymmetric Digital Subscriber Line) de 225 kbps, a transmissão deste vídeo levaria
240 horas, ou seja, 10 dias. Através deste exemplo fica clara a necessidade de
compressão dos dados antes de sua transmissão.
O projeto MPEG (Moving Picture Experts Group) começou a ser desenvolvido em
1988 sob a supervisão dos órgãos internacionais de padronização ISO (International
Standardization Organization) e IEC (International Electrotechnical Committee).
Com a participação de centenas de especialistas, foi desenvolvido um método de
compressão de vídeo através da compressão de imagens digitais e sons, bem como do
16
sincronismo destes [42]. A partir de então o projeto foi evoluindo e vários padrões
foram criados.
O primeiro padrão desenvolvido foi chamado MPEG-1 [17] e era voltado para vídeos
com qualidade VHS e áudio com qualidade de CD estéreo [6]. O padrão MPEG-2
[17], uma extensão do padrão MPEG-1, é voltado principalmente para vídeos de alta
qualidade, e por isso foi adotado como padrão na maior parte dos sistemas de TV
digital. Uma vez que o padrão MPEG-2 não é utilizado exclusivamente em padrões de
TV digital, ele foi dividido em vários perfis e níveis, de forma a atender os diferentes
requisitos das várias aplicações-alvo [6]. Sendo assim, a tecnologia MPEG-2 SDTV
nada mais é que o padrão MPEG-2 com a combinação de perfis e níveis que mais se
aproximam das necessidades da TV padrão (SDTV), enquanto que MPEG-2 HDTV é
a combinação de perfis e níveis que mais se aproximam das necessidades da TV de
alta definição (HDTV).
A tecnologia MPEG-2 Audio é um conjunto de três camadas que comprimem os sons
utilizando técnicas que removem as frequências não audíveis pelo ouvido humano [6].
Este modelo de três camadas é compatível com o modelo utilizado na tecnologia
MPEG-1.
O padrão MPEG-2 AAC (Advanced Audio Coding – Codificação de Áudio Avançada)
é a evolução do MPEG-2 Audio, utilizando-se de métodos mais complexos porém
mais eficientes na compressão [42]. Entretanto, este padrão não mantém
compatibilidade com o modelo utilizado em MPEG-1.
Dolby Digital, também conhecido como AC-3, é um padrão proprietário desenvolvido
pela Dolby Laboratories [11]. O AC-3 baseia-se nos mesmos princípios de três
camadas do MPEG-2 Audio e do AAC.
Apesar de compressão de áudio e vídeo continuar sendo seu foco principal, o padrão
MPEG-4 passou a agregar novas funcionalidades. Tendo sua primeira versão liberada
em 1998, este padrão trouxe como inovação uma linguagem que é capaz de descrever
de forma compacta os objetos presentes em uma cena, bem como seus movimentos e
interações. Outra funcionalidade inserida é a interação com o usuário, que permite a
manipulação dos objetos das cenas [42].
O uso dos padrões MPEG-2 e MPEG-4 em transmissões de vídeo é abordado em
vários trabalhos. Pode-se citar o trabalho apresentado por (Zhao e Kuo, 2003) [64],
17
onde são comparados o uso de hardware e de software para compressão de vídeos –
utilizando MPEG-2 – com o objetivo de transmitir vídeos em alta qualidade para TV
digital. (Radha et al., 1999) [36] apresentam uma solução de transmissão de vídeos
em tempo real – utilizada para transmitir vídeos sob demanda e programas de TV ao
vivo – baseada no padrão MPEG-4.
2.3.3 Mediador
O mediador - middleware em inglês - tem como papel prover uma interface padrão
para as aplicações de TV digital. Desta forma, os desenvolvedores de aplicações não
precisam se preocupar com as camadas inferiores da arquitetura e passam a focar o
desenvolvimento para esta interface padrão, enquanto o mediador fica responsável por
“traduzir” a comunicação das aplicações com as camadas inferiores e vice-versa.
Além disso, o mediador também é responsável por combinar a TV tradicional (áudio e
vídeo) com textos, imagens e interatividade com o telespectador.
As aplicações para TV digital podem ser divididas em dois conjuntos [47] conforme
abaixo, e um mediador pode suportar apenas um ou ambos os conjuntos:
• Aplicações Procedurais: aplicações baseadas em linguagens procedurais e de
código binário compilado. A linguagem mais usual em sistemas de TV digital
é Java [47];
• Aplicações Declarativas: aplicações escritas em linguagens declarativas, que
são linguagens de mais alto nível de abstração. Dentre as linguagens
declarativas mais comuns pode-se citar NCL, SMIL e XHTML (Extensible
HyperText Markup Language) [62].
O mediador conhecido como DTV Application Software Environment (DASE) [5]
suporta tanto HTML (HyperText Markup Language) [60] como linguagem
declarativa, quanto JavaTV [26] como linguagem procedural. O mediador
denominado Multimedia Home Platform (MHP) [13] suporta tanto a linguagem
declarativa DVB-HTML (Digital Video Broadcast HyperText Markup Language) –
que é uma linguagem de programação semelhante ao HTML – quanto aplicações
DVB-J – escritas utilizando JavaTV – como linguagem procedural. O Association of
Radio Industries and Business (ARIB) [4], é um mediador que trabalha apenas com a
18
linguagem declarativa BML (Broadcast Markup Language), linguagem baseada em
XML (Extensible Markup Language) [59].
Ginga é o mediador brasileiro criado após anos de pesquisas lideradas pela Pontifícia
Universidade Católica do Rio de Janeiro (PUC-Rio) e pela Universidade Federal da
Paraíba (UFPB). O mediador Ginga – eleito como o mediador oficial do Sistema
Brasileiro de TV digital conforme o decreto 4901 – é um software livre, desenvolvido
em Java e possui o código publicado no Portal do Software Público Brasileiro [34]. O
Ginga suporta tanto a linguagem procedural JavaTV – através do módulo Ginga-J –
quanto NCL, uma linguagem declarativa baseada em XML.
Devido à importância dos mediadores para o funcionamento da TV digital e pelo fato
de cada sistema implementar o seu próprio mediador, vários trabalhos da atualidade
abordam este assunto. (Oliveira e Albuquerque, 2005) [30] e (Paes et al., 2005) [31]
realizam uma introdução ao conceito de mediador e aos principais padrões existentes.
O mediador Ginga, incluindo sua arquitetura e funcionamento interno, é explicado em
detalhes por (Soares et al., 2007) [50].
Conforme apresentado, os mediadores que suportam aplicações procedurais utilizam
linguagem Java com JavaTV. Porém, em relação às aplicações declarativas, cada
mediador possui suporte a uma linguagem distinta. Sendo assim, é de interesse a
comparação do desempenho destas diferentes linguagens. Neste trabalho foram
escolhidas as linguagens NCL e SMIL para comparação. NCL foi escolhida por ser a
linguagem adotada no mediador do Sistema Brasileiro de TV Digital. SMIL foi
escolhida por ser a linguagem para sincronismo de mídias na Web recomendada pelo
The World Wide Web Consortium (W3C), além de ser proposta para ser utilizada na
TV digital e em dispositivos móveis por (Pihkala et al., 2002), e ser tida como opção
de extensão ao mediador MHP. As subseções a seguir definem e apresentam as
principais características de ambas as linguagens.
2.3.3.1 Nested Context Language (NCL)
Conforme mencionado anteriormente, NCL é uma linguagem declarativa baseada em
XML para autoria de documentos hipermídia. A estrutura da linguagem NCL foi
concebida de forma modular, onde cada módulo agrupa elementos e atributos XML
com relação semântica entre si [39]. A estrutura básica de um documento NCL é
formada por um elemento ncl que contém um cabeçalho (elemento head) e um corpo
19
(elemento body). Estes elementos principais estão destacados na Figura 7, que mostra
um exemplo de um arquivo NCL responsável por exibir dois vídeos simultâneos na
tela. Os demais elementos apresentados na Figura 7 são explicados abaixo.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoVideo2">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
<causalConnector id="composerOnBeginStartDelay">
<simpleCondition role="onBegin"/>
<simpleAction delay="$delay" role="start"/>
<connectorParam value="xs:string" name="delay"/>
</causalConnector>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgVideo1"/>
<region left="550" top="100" width="320" height="240"
id="rgVideo2"/>
</regionBase>
<descriptorBase>
<descriptor region="rgVideo1" id="dVideo1"/>
<descriptor region="rgVideo2" id="dVideo2"/>
</descriptorBase>
</head>
<body>
<media descriptor="dVideo1" src="./media/nist.mpg"
type="video/mpeg" id="video1"/>
<port component="video1" id="pInicio"/>
<media descriptor="dVideo2" src="./media/coffee.mpg"
type="video/mpeg" id="video2"/>
<link xconnector="composerOnBeginStartDelay" id="link1">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video2"/>
<linkParam value="0.001s" name="delay"/>
</link>
</body>
</ncl>
Figura 7 - Exemplo de arquivo NCL
Da mesma forma que os elementos head e body estão contidos dentro do elemento
ncl, os elementos citados também podem conter outros elementos. Dentro de head,
são localizados os seguintes elementos:
• connectorBase: definido entre as linhas 8 e 16 da Figura 7, este elemento
contém o elemento importBase, responsável por referenciar um arquivo que
funciona como uma espécie de “modelo” para o arquivo NCL em questão,
contendo várias definições de elementos a serem utilizados. Caso o arquivo
20
em questão possua eventos temporais, ou seja, uma ação específica ocorra
antes ou depois de passado um tempo especificado, o elemento
causalConnector também será encontrado.
• regionBase: definido entre as linhas 17 e 22, este elemento contém as
declarações das regiões da tela onde as mídias desejadas serão exibidas. As
regiões são definidas através do elemento region que possui os atributos left e
top para definir o posicionamento, e os atributos width e height para definir o
tamanho da região. Assim, forma-se uma região quadrada ou retagular onde o
conteúdo será apresentado, apresentado no posicionamento informado e com o
tamanho desejado. Além disso, region ainda possui um atributo id, que é um
identificador da região criada.
• descriptorBase: definido entre as linhas 23 e 26, este elemento é responsável
por associar um descritor a uma região, através do elemento descriptor. O
descriptor possui o atributo id, que é um identificador do elemento em questão
e o atributo region, onde deve ser informado o identificador do elemento
region encontrado dentro do elemento regionBase. Desta forma um descritor
passa a referenciar uma região criada previamente.
Dentro do elemento body são declaradas as mídias desejadas e os eventos temporais
que devem ocorrer. Para isso são utilizados os seguintes elementos:
• media: definido nas linhas 29/30 e novamente nas linhas 32/33, este elemento
possibilita a definição de objetos de mídia de diferentes tipos, tais como texto,
imagem, vídeo e áudio. O atributo type indica o tipo da mídia ao qual o
elemento se refere, src indica a localização do arquivo a ser tocado, id define
um identificador ao elemento e por último descriptor. No atributo descriptor
deve-se informar o identificador de um descritor (elemento descriptor visto
nas linhas 24 e 25). Assim, a mídia em questão será exibida dentro da região
(elemento region) a qual o descritor informado está associado.
• port: definido na linha 31, é o elemento que informa, em caso de haver mais
de uma mídia por arquivo, qual a primeira mídia a ser tocada.
• link: definido nas linhas 34 a 38, este elemento é responsável por criar um
evento temporal, ou seja, é possível definir eventos que devem ocorrer depois
de n segundos que uma mídia começou ou terminou de ser tocada, por
21
exemplo. No arquivo exibido na Figura 7, este elemento define através da
linha 35 que o elemento responsável por disparar o evento é o elemento
“video1” e que o evento será disparado quando o vídeo começar a ser
reproduzido (role=”onBegin”). A consequência do evento, conforme definido
na linha 36, é o início da exibição (role=”start”) do elemento “video2”. Por
último, definido na linha 37, o evento deve ser disparado 0.001 segundos – 1
milissegundo – após o disparo do evento. Sendo assim, no exemplo em
questão o elemento define que o vídeo2 será inicializado 1 milissegundo após
o início do video1.
O processo de criação da linguagem NCL, seus principais conceitos e a comparação
desta com outras linguagens hipermídia existentes são apresentados por (Antonacci,
2000) [3]. O trabalho de (Costa, Rodrigues e Soares, 2004) [7] apresenta uma
ferramenta com o objetivo de permitir que documentos hipermídia criados com a
linguagem NCL possam ser armazenados, distribuídos e exibidos no formato MPEG-
4 [17]. Em relação à utilização de NCL na TV Digital, um estudo explicando os
principais conceitos referentes à produção de conteúdo declarativo para TV Digital é
apresentado por (Rodrigues e Soares, 2006) [39]. Neste estudo a linguagem NCL é
utilizada para a construção de um arquivo de exemplo.
2.3.3.2 Synchronized Multimedia Integration Language (SMIL)
A especificação SMIL propõe uma linguagem para autoria declarativa de documentos
multimídia para Web e foi definido em junho de 1998 através do The World Wide
Web Consortium (W3C) . Em agosto de 2001 foi publicada sua evolução, o SMIL 2.0.
Posteriormente, em maio 2005, a versão 2.1 – utilizada neste trabalho - foi publicada.
SMIL também é uma linguagem de marcação baseada em XML e portanto possui sua
estrutura lógica definida por elementos e atributos. Basicamente, um documento
SMIL contém um elemento mais externo denominado smil que, por sua vez, pode
conter dois outros elementos principais: head e body. Estes elementos principais estão
destacados na Figura 8, que mostra um exemplo de arquivo SMIL com função
equivalente ao arquivo NCL apresentado na Figura 7, ou seja, exibe dois vídeos
simultaneamente na tela. Os demais elementos apresentados na Figura 8 são
explicados abaixo.
22
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<smil xmlns:meta="http://www.w3.org/2005/SMIL21/Language">
<meta:meta name="documentoVideo2"/>
<head>
<layout>
<region left="250" top="250" width="320" height="240"
id="rgVideo1"/>
<region left="550" top="100" width="320" height="240"
id="rgVideo2"/>
</layout>
</head>
<body>
<par>
<video src="./media/nist.mpg" region="rgVideo1"/>
<video src="./media/coffee.mpg" region="rgVideo2"/>
</par>
</body>
</smil>
Figura 8 - Exemplo de um arquivo SMIL
Da mesma forma que os elementos head e body estão contidos dentro do elemento
smil, os elementos citados também podem conter outros elementos. Dentro de head é
localizado o elemento layout – definido entra as linhas 4 e 9 da Figura 8 - que pode
ser comparado ao elemento regionBase do NCL. Sua função é conter elementos do
tipo region, responsáveis por determinar regiões onde as mídias desejadas serão
exibidas. Bem como NCL, o elemento region possui os atributos left e top para definir
o posicionamento, width e height para definir o tamanho da região e id que é um
identificador da região criada.
Dentro do elemento body é localizado o elemento par. Definido entre as linhas 12 e
15, este elemento é responsável por agrupar elementos de mídia que serão tocados em
conjunto. Bem como NCL, um documento SMIL pode ser composto pelos seguintes
objetos de mídia: vídeo, áudio, texto e imagem. Porém, ao contrário de NCL, SMIL
possui um elemento específico para cada objeto de mídia, a saber: video, audio, text,
img. Estes elementos possuem o atributo src que indica a localização do arquivo a ser
tocado, e o atributo region onde deve ser informado o identificador da região onde a
mídia será exibida.
Um tocador de arquivos SMIL portável para diferentes plataformas, como PC’s,
PDA’s e TV Digital é apresentado por (Pihkala et al., 2002) [32]. Nesse trabalho são
analisadas e apresentadas as principais diferenças funcionais entre os diferentes
dispositivos, a saber: quantidade de memória persistente, quantidade de memória
RAM e velocidade de CPU. Mede-se ainda o tempo gasto em milissegundos e a
quantidade de memória utilizada por três diferentes arcabouços de interface gráfica
23
com o usuário para reproduzir o arquivo SMIL. A partir desses dados conclui-se qual
arcabouço deve ser utilizado para prover a portabilidade da aplicação. Apesar de
apresentar dados interessantes, o trabalho não especifica as técnicas de medição, a
carga, o número de testes ou faz experimentos nos diferentes dispositivos
apresentados.
No estudo apresentado por (Pihkala et al., 2001), são realizados experimentos
consistentes comparando o tempo e a quantidade de memória gastos para processar
arquivos SMIL contendo diferentes números de elementos, utilizando-se Swing [14] e
JMF (Java Media Framework API) [24]. Porém, uma vez que o objetivo é comparar o
desempenho entre os dois arcabouços e o primeiro não provê suporte a áudio e vídeo,
os experimentos são realizados apenas em arquivos com recursos de texto e imagem.
Além disso, os experimentos foram realizados em apenas uma configuração de
memória e CPU.
Comparando-se a estrutura dos arquivos NCL e SMIL apresentados na Figura 7 e na
Figura 8, respectivamente, e que são funcionalmente idênticos – ambos os arquivos
são responsáveis pela exibição de dois vídeos simultaneamente – é possível perceber
que NCL necessita de um maior número de elementos e instruções para realizar as
mesmas ações de um arquivo SMIL. Em contrapartida, NCL possui algumas
vantagens em relação a SMIL. Conforme exposto por (Antonacci, 2000) [3], em
relação a reuso de conteúdo, enquanto em SMIL a reutilização das estruturas é feita
através de cópias – o que dificulta a manutenção – NCL permite a reutilização tanto
de elementos simples quanto de grupamentos de elementos. Comparando-se o
grupamento de elementos, SMIL pode definir grupamentos sequênciais, paralelos e
alternativos. NCL por sua vez possui suporte a todos esses e ainda a grupamentos de
estruturação de documento, que propicia organização hierárquica do documento e
possibilita além do reuso de elementos, fácil alteração do documento. Demais
comparações entre as funcionalidades de NCL e outras linguagens são apresentadas
no trabalho supracitado. Pode-se citar ainda os trabalhos de (Rodrigues e Soares,
2006) e (Saade et al., 2003), onde são comparados a estrutura interna e a semântica
utilizada por cada linguagem. Além disso, são apresentadas as semelhanças, as formas
de integração, as vantagens, as desvantagens e os ganhos dos autores de conteúdo ao
utilizarem cada uma das linguagens. Entretanto, uma vez que os trabalhos
apresentados fazem apenas comparações qualitativas das linguagens, este trabalho
24
contribui fazendo comparações quantitativas. Desta forma, são comparados o tempo
de CPU gasto para interpretar arquivos NCL e SMIL contendo diferentes objetos de
mídia (texto, imagem, áudio e vídeo) e em diferentes configurações de memória e
velocidade de CPU.
Uma vez definidas as linguagens utilizadas neste trabalho, faz-se necessário definir os
aplicativos capazes de tocá-las, os chamados “tocadores”. O tocador “Ginga-NCL
Emulator” é capaz de tocar arquivos NCL e está disponível no Portal do Software
Público Brasileiro. Atualmente existem vários tocadores disponíveis para tocar SMIL,
como o Ambulant Player [2], o Real Player [37] e o X-Smiles [63]. Durante o
desenvolvimento deste trabalho, não foi encontrado nenhum tocador com suporte a
NCL e SMIL.
2.3.4 Transporte
O principal objetivo da camada de transporte é transportar dados multimídia através
de meios de difusão. Utilizado por todos os sistemas de TV digital nesta camada, o
padrão MPEG-2 TS (Transport Streams – Fluxo de Tranporte) é uma sub-divisão do
padrão MPEG-2 e é usado para multiplexar1 áudio, vídeo e dados. Uma vez que os
meios de difusão estão sujeitos a erros de transmissão, cada pacote possui tamanho
fixo de apenas 188 bytes, o que facilita a ressincronização de um vídeo em caso de
perda de pacotes [6].
(Hirayama e Silveira, 2005) [20] propõem um arcabouço que fornece ferramentas
para simular as condições reais de uma rede de distribuição de conteúdo. Esta rede de
distribuição, chamada de rede primária, utiliza o MPEG-2 TS para transmitir o sinal
de TV digital. No trabalho apresentado por (Schulter et al., 2003) [43], o formato
MPEG-2 TS é utilizado para transmitir vídeos capturados por uma câmera para um
Set Top Box, em uma infra-estrutura proposta para atender o desenvolvimento e o
teste de ferramentas para TV digital no Brasil.
2.3.5 Modulação
A camada de modulação é responsável por alterar as ondas eletromagnéticas enviadas
pelo difusor de acordo com o sinal da informação a ser transmitida [6]. O objetivo de
1 Transmitir várias mensagens simultaneamente em um mesmo canal.
25
realizar a modulação é permitir que o sinal chegue até o receptor, pois de outra forma,
problemas de atenuação do sinal por perdas de energia, ruído de outros sinais e
distorções impediriam sua chegada ao receptor.
No sistema 8-VSB (8 Level – Vestigial Side Band ou Vestígio de Banda Lateral de 8
níveis) os dados são transportados por oito níveis na onda de rádio-frequência, e a
modulação é efetuada na amplitude da onda [6]. Já no sistema COFDM (Coded
Orthogonal Frequency Division Multiplexing ou Multiplexação por Divisão de
Freqüências Ortogonais e Codificada) as ondas são moduladas por amplitude e por
fase [6]. Uma comparação em detalhes entre os dois sistemas de modulação é
realizada por (Rodrigues e Gomes, 2004) [38], mostrando as vantagens e
desvantagens de cada um e concluindo que a modulação COFDM é tecnicamente
superior à modulação 8-VSB. (Zheng e Miller) [65] analisam o desempenho do
sistema de modulação COFDM. O sistema de modulação 8-VSB é detalhado
tecnicamente por (Sparano, 1997) [51].
2.4 Principais Sistemas de TV Digital
As subseções a seguir apresentam os três principais sistemas de TV digital definidos
atualmente. Na subseção seguinte é apresentado o Sistema Brasileiro de Televisão
Digital, desde a iniciativa de sua criação até a definição do padrão. Para cada padrão
abordado, uma figura indica qual a tecnologia adotada em cada uma das camadas da
arquitetura padrão da TV digital (vide Figura 3). As tecnologias adotadas por cada
padrão bem como a função de cada camada da arquitetura da TV digital foram
discutidas na Seção 2.3.
2.4.1.1 ATSC (Advanced Television System Committee)
O padrão americano foi desenvolvido pelo comitê ATSC e implantado nos Estados
Unidos em 1998 [40]. Sua principal característica é a preocupação com a qualidade
audiovisual, contando com resolução de até 1920 x 1080 pixels e som de 6 canais.
Além dos Estados Unidos, o ATSC foi adotado pelo Canadá, México, Taiwan e
Coréia do Sul [19]. As tecnologias adotadas por este padrão são apresentadas na
Figura 9.
26
Figura 9 - Tecnologias adotadas pelo padrão ATSC
2.4.1.2 DVB (Digital Video Broadcasting)
Desenvolvido pelo DVB Project, um consórcio Europeu com mais de trezentos
membros [19], o DVB entrou em operação no Reino Unido em 1998 e hoje é adotado
pela maioria dos países do mundo, em especial países da Europa, Ásia, África e
Oceania. As tecnologias adotadas por este padrão são apresentadas na Figura 10.
Figura 10 - Tecnologias adotadas pelo padrão DVB
27
2.4.1.3 ISDB (Integrated Services Digital Broadcasting)
Desenvolvido no Japão pelo consóricio DiBEG (Digital Broadcasting Experts Group)
em 1999, o padrão ISDB foi o último dos três padrões a ser definido. Diferente dos
outros dois padrões, o ISDB permite transmissão simultânea para televisão de alta
definição e dispositivos móveis. As tecnologias adotadas por este padrão são
apresentadas na Figura 11.
Figura 11 - Tecnologias adotadas pelo padrão ISDB
2.4.1.4 SBTVD (Sistema Brasileiro de TV Digital)
Para definir o SBTVD, o governo brasileiro instituiu, conforme Decreto nº 4901 de 26
de Novembro de 2003 [52], três comitês:
• Comitê de Desenvolvimento, com a participação de representantes dos vários
ministérios e da Anatel;
• Comitê Consultivo, com a participação de entidades representativas;
• Grupo Gestor, com apoio técnico e administrativo da Finep e do CPqD.
Conforme citado em (Hobaika e Borges, 2007) [21], este decreto foi de grande
importância, pois além de estabelecer políticas para o SBTVD, estimulou
representantes da comunidade científica a realizarem intenso trabalho de estudos e
pesquisas nas seguintes áreas: modulação, transporte, compressão de áudio e vídeo,
mediador (middleware), software e interatividade, ou seja, as cinco camadas que
compõem a TV digital, conforme mostrado na Figura 3.
28
Em 17 de Dezembro de 2005, os resultados dos estudos de projetos de
desenvolvimento do SBTVD encomendados pelo grupo Gestor a várias entidades
foram apresentados ao comitê de desenvolvimento [52]. Conforme (Hobaika e
Borges, 2007) [21], estes estudos concluíram que desenvolver um padrão tecnológico
brasileiro seria demasiadamente oneroso uma vez que as emissoras e fabricantes
gastariam cerca de R$3,5 bilhões apenas para desenvolver e implantar o padrão
brasileiro. Assim, em 23 de Junho de 2006, através de um comunicado oficial, o
governo brasileiro anunciou a escolha do padrão japonês (ISDB) de TV digital,
através do Decreto 5820. Ainda segundo (Hobaika e Borges, 2007) [21], o padrão
japonês foi escolhido por atender as seguintes necessidades, definidas anteriormente
no decreto 4901:
• Mais de uma programação em um único canal de 6 MHz, inclusive em alta
definição;
• Interatividade com o telespectador através do controle remoto;
• Suporte à mobililidade e à portabilidade.
Uma outra condição levada em conta na escolha do padrão japonês, foi a
disponibilidade de transferência e flexibilização da tecnologia, ao invés da absorção
na íntegra do padrão. Sendo assim, o ISDB passou por duas alterações que definiram
o SBTVD:
• A tecnologia MPEG-2 foi substituída pela tecnologia MPEG-4 para
compressão de vídeo;
• Um novo mediador totalmente brasileiro chamado Ginga foi adotado.
Por fim, em Outubro de 2006 foram definidas as etapas a serem cumpridas por cada
emissora de TV analógica para implantação da TV digital no Brasil, conforme
Portaria nº 652 [35]. Em 02 de Dezembro de 2007 foi iniciada a operação
experimental da TV digital na cidade de São Paulo.
As tecnologias adotadas pelo SBTVD são apresentadas na Figura 12.
29
Figura 12 - Tecnologias adotadas pelo padrão SBTVD
Conforme apresentado neste capítulo, NCL e SMIL são duas linguagens declarativas
que permitem a criação de aplicações que serão executadas no mediador do sistema de
TV digital. Dito que uma das maiores inovações introduzidas pela TV digital é a
interatividade com o telespectador e que essa é oferecida através de aplicações
interativas, fica clara a importância dessas linguagens para que o mediador possa
oferecer esse serviço. Uma vez que os trabalhos existentes fazem apenas comparações
qualitativas quanto à semântica e estrutura interna dos arquivos escritos em NCL e
SMIL, este trabalho contribui apresentando uma comparação quantitativa em relação
ao desempenho destas linguagens.
30
3 Metodologia de Avaliação
Este capítulo tem como objetivo apresentar a metodologia utilizada na avaliação dos
desempenhos das linguagens NCL e SMIL. A Seção 3.1 apresenta as cargas utilizadas
na avaliação. A abordagem metodológica propriamente dita e as técnicas estatísticas
utilizadas na análise são apresentadas na Seção 3.2. A Seção 3.3 traz os cenários e as
ferramentas utilizadas. Por fim, a Seção 3.4 discute as limitações da avaliação.
3.1 Cargas
A fim de medir o desempenho da interpretação das linguagens NCL e SMIL -
principal objetivo deste trabalho - foram criados seis arquivos em NCL e outros seis
arquivos, de conteúdo equivalente, em SMIL. Para uma mesma linguagem, a
diferença entre os arquivos consiste no número de elementos de um determinado
objeto de mídia. Uma vez que até onde o autor pode verificar não há caracterização
adequada de cargas para linguagem declarativas, a escolha do número de elementos é
de certa forma arbitrária. Contudo, optou-se por variá-lo amplamente, de forma a
cobrir vários pontos no espaço de possibilidades. Em particular, este número foi
variado em 1, 2, 3, 5, 10 e 20 elementos. Desta forma foram contemplados tanto os
arquivos de exemplo disponibilizados para NCL (juntamente com a ferramenta
Composer no Portal do Software Público Brasileiro), contendo poucos recursos, como
aplicações que podem vir a utilizar mais recursos, como um programa de TV com
comerciais por exemplo. Atualmente um comercial tem duração de trinta segundos, e
um intervalo comercial - em média - duração total de três minutos. Nesse cenário, um
arquivo com 20 elementos, abrange um programa com 3 intervalos comerciais (18
comerciais mais o programa em si). Por outro lado, levando-se em consideração que
uma das funcionalidades da TV digital é a exibição de vídeos de forma simultânea, e
não há a necessidade de um intervalo para exibição de comerciais, um arquivo com 10
elementos atenderia ao requisito de um programa e mais nove comerciais, exibidos
apenas quando o produto ou objeto principal do comercial apareça no programa.
Além da variação do número de elementos, foram considerados os quatros objetos de
mídia suportados por ambas as linguagens, a saber: áudio, vídeo, texto e imagem.
Logo, no total, foram criados vinte e quatro arquivos para cada linguagem avaliada.
31
Cada um destes arquivos, bem como uma breve descrição do seu conteúdo estão
disponíveis no Apêndice A e no Apêndice B desta dissertação.
É importante destacar que mediu-se apenas o tempo de interpretação dos arquivos,
não considerando-se o tempo de exibição do conteúdo, uma vez que este deveria ser
independente da linguagem. Sendo assim, apenas o número de recursos por arquivo
foi variado, uma vez que tem influência no tempo de interpretação. Já o tamanho, a
duração e o formato do conteúdo não foram variados pois não influenciam o tempo de
intepretação, e sim o tempo de exibição do conteúdo, que não é o foco deste trabalho.
3.2 Projeto Experimental
Para cada um dos arquivos citados na Seção 3.1, foram realizadas três baterias de
experimentos. Cada bateria era constituída de cinco execuções consecutivas de um
arquivo, medindo-se o tempo - em milissegundos - de CPU gasto pelo aplicativo
“Ginga X-Smiles” (vide descrição na Seção 3.3.3) para interpretar o conteúdo do
arquivo em questão. Entre a execução de duas baterias consecutivas, o aplicativo
Ginga X-Smiles era reiniciado. Desta forma, foram medidos e coletados quinze
valores para cada arquivo. Este procedimento foi realizado em quatro diferentes
cenários, onde foram alteradas a velocidade de CPU e quantidade de memória RAM,
conforme exposto na Seção 3.3.1. Assim, para cada um dos arquivos utilizados, foram
medidos e coletados sessenta valores referentes ao tempo de CPU gasto para sua
interpretação nos diferentes cenários considerados. Neste ponto é importante ressaltar
que a biblioteca utilizada para medição do tempo de interpretação dos arquivos possui
granularidade mínima de 15 milissegundos. Dessa forma, qualquer interpretação de
um arquivo que gastasse menos que este tempo era considerada pela biblioteca como
gastando zero milissegundos. Sabido que é necessário um mínimo de processamento
para intepretar qualquer arquivo, e que valores iguais a zero aumentavam a
variabilidade (e consequentemente o intervalo de confiança) e influenciavam
negativamente na média, optou-se neste trabalho por considerar o tempo de execução
igual a 15 milissegundos nas execuções que originalmente possuiam o valor zero. Ao
optar por arredondar estes tempos para um valor superior, consideramos esta
abordagem como conservadora, uma vez que podemos estar superestimando os
valores ligeiramente, dada a granularidade da biblioteca. A Tabela 1 apresenta um
exemplo de valores coletados durante a execução de um arquivo SMIL contendo 1
32
(um) recurso de texto. Conforme mostrado pela segunda coluna desta tabela, o tempo
gasto para interpretar o arquivo em questão foi menor que 15 milissegundos na teceira
e quinta execuções e portanto, a biblioteca considerou o tempo de CPU gasto como
zero milissegundos. Entretanto, os valores considerados para os experimentos
realizados são mostrados na terceira coluna da tabela, onde os valores iguais a zero
foram substituídos por 15 milissegundos.
Execução Tempo Medido (ms) Tempo Considerado nos
Experimentos (ms) #1 547 547 #2 63 63 #3 0 15 #4 32 32 #5 0 15
Tabela 1 - Tempo medido x tempo considerado
De posse dos tempos de processamento referentes a todos os arquivos, os resultados
foram divididos em duas categorias:
• Tempos referentes à primeira execução após inicialização do aplicativo
Ginga X-Smiles;
• Tempos referentes à segunda, terceira, quarta e quinta execuções após
inicialização do aplicativo Ginga X-Smiles.
Esta categorização fez-se necessária pois, por ter sido desenvolvido em Java, o
aplicativo Ginga X-Smiles demanda na primeira execução o chamado “tempo de
carga”, que interfere no tempo de processamento do contéudo dos arquivos. Este
tempo de carga deve-se à execução do compilador JIT (Just-In-Time) na máquina
virtual Java. O compilador JIT é responsável por transformar o código das classes
Java em código nativo quando estas são carregadas pela máquina virtual, o que
possibilita maior velocidade de execução nas próximas vezes em que a máquina
virtual utilizar essas classes [28]. Em suma, a execução do compilador JIT melhora o
desempenho da máquina virtual Java nas execuções posteriores, em detrimento de um
maior tempo na primeira execução. Devido à interferência do JIT, o tempo de CPU
gasto para interpretar os arquivos refletem execuções heterogêneas, justificando sua
categorização. No restante deste trabalho, os tempos referentes à primeira execução
após inicialização do aplicativo Ginga X-Smiles serão referenciados como “execuções
com tempo de carga”, enquanto que os tempos referentes às demais execuções serão
referenciados como “execuções sem tempo de carga”.
33
A fim de ilustrar o funcionamento do JIT, utilizando-se a ferramenta nativa da
máquina virtual Java denominada “JConsole” [54], mediu-se o número de classes
carregadas por etapa de execução do aplicativo Ginga X-Smiles para um arquivo
contendo 1 vídeo. As seguintes etapas são consideradas:
• Ginga X-Smiles Iniciado: etapa inicial da aplicação, ou seja, estado em que a
aplicação se encontra logo após ser inicializada;
• Acesso à opção File/Open: etapa na qual a aplicação se encontra após a opção
de menu “File/Open” ser acessada e uma janela para indicar a localização do
arquivo que se deseja tocar ser aberta;
• 1ª Execução do Arquivo: etapa na qual a aplicação se encontra após a primeira
execução do arquivo selecionado na janela aberta na etapa anterior;
• 2ª Execução do Arquivo: etapa na qual a aplicação se encontra após a segunda
execução do arquivo selecionado.
Durante esta medição, foram coletados também os tempos de CPU para interpretação
do arquivo em questão – tanto para NCL quanto para SMIL – sendo possível
comparar a interferência do JIT no tempo de interpretação do arquivo em cada
linguagem analisada.
A Figura 13 exibe um gráfico apresentando o número de classes carregadas por etapa
de execução da aplicação, e através dela é possível observar que em seu estado inicial
a aplicação já possui várias classes carregadas. Além disso, pode-se observar que
novas classes são carregadas quando a opção de menu “File/Open” é acessada. É
importante observar que até este momento não há diferença no número de classes
carregadas entre as diferentes linguagens analisadas, uma vez que nenhum arquivo foi
selecionado para ser tocado. Entretanto, quando um arquivo é selecionado para ser
tocado pela primeira vez, novas classes são carregadas, conforme mostrado pelo
aumento no número de classes entre as etapas “Acesso à opção File/Open” e “1ª
Execução do Arquivo”. O tempo gasto pela máquina virtual Java para carregar essas
classes acaba por interferir no tempo gasto na interpretação do arquivo. Da segunda
execução em diante não há essa interferência pois, conforme ilustrado na figura em
questão, nenhuma classe adicional é carregada.
34
2500
3000
3500
4000
Ginga X-SmilesIniciado
Acesso à opção"File/Open"
1ª Execução doArquivo
2ª Execução doArquivo
Etapa
Nº
de
Cla
sses
Car
reg
adas
NCL
SMIL
Figura 13 - Número de classes carregadas por etapa de execução
Estas conclusões são reforçadas através da análise da Figura 14, que exibe o tempo de
CPU gasto para interpretar o arquivo em questão durante a primeira e a segunda
execuções. Nesta figura é possível verificar que tanto NCL quanto SMIL gastam
maior tempo de CPU durante a primeira execução, confirmando assim a influência do
JIT. É percebida a maior interferência do JIT em NCL, uma vez que esta linguagem
carrega um maior número de classes, através da diferença entre primeira e a segunda
execuções. Enquanto para esta linguagem a diferença é de 1.515 milissegundos, em
SMIL a diferença é de apenas 453 milissegundos.
0
500
1000
1500
2000
# 1 # 2
Execução
Mil
isse
gu
nd
os
NCL
SMIL
Figura 14 -Tempos referentes à execuções com e sem tempo de carga para NCL e SMIL
35
Uma vez coletados e categorizados, os resultados dos arquivos NCL foram
comparados com os resultados dos arquivos SMIL, utilizando-se as técnicas
discutidas a seguir.
3.2.1 Testes em Observações Pareadas
Conforme definido em (Jain, 1991) [23], ao realizar um número n de experimentos em
dois sistemas de forma a haver correspondência de “um para um” entre os
experimentos destes sistemas (isto é, um mesmo experimento, definido pelo mesmo
conjunto de entradas é executado nos dois sistemas), as observações são chamadas
pareadas. Nas observações pareadas, as amostras dos dois sistemas são tratadas como
apenas uma amostra de n pares. Para cada par pode-se calcular a diferença de
desempenho e o intervalo de confiança desta. Caso o intervalo de confiança inclua o
valor zero, os sistemas não são significativamente diferentes com um nível de
confiança preestabelecido.
Utilizando-se as técnicas de observações pareadas, os valores coletados durante os
experimentos foram comparados a fim de definir se NCL e SMIL apresentam tempo
de CPU significativamente diferentes. Nessas comparações, um intervalo de confiança
com ambos os valores positivos indica que SMIL possui melhor desempenho. Caso
ambos os valores do intervalo de confiança sejam negativos, NCL possui melhor
desempenho. A técnica em questão ainda consegue estimar o quanto uma linguagem é
superior à outra.
3.2.2 Observações Não Pareadas
Ao contrário das observações pareadas, quando não há correspondência entre os
experimentos, ou seja, os conjuntos de entradas executadas nos dois sistemas são
diferentes, as observações são chamadas não pareadas [23]. No caso das observações
não pareadas, é possível utilizar uma técnica chamada “Teste de Aproximação
Visual” [23]. Esta técnica define que através da observação da média e do intervalo de
confiança de duas amostras, três conclusões são possíveis:
• Caso não haja sobreposição dos intervalos de confiança das amostras A e B,
utiliza-se a média para definir se uma alternativa é melhor ou pior que a outra,
de acordo com as métricas utilizadas. Nesta dissertação, maior média significa
36
maior tempo de interpretação. Assim, quanto maior a média, pior o
desempenho.
• Caso haja sobreposição dos intervalos de confiança das amostras A e B e cada
intervalo de confiança contiver a média da outra amostra, os sistemas não são
diferentes no nível de confiança preestabelecido.
• Caso haja sobreposição dos intervalos de confiança das amostras A e B, mas
um intervalo de confiança não contiver a média da outra amostra, não é
possível chegar a uma conclusão utilizando-se a técnica em questão. Nesse
caso é necessário aplicar o chamado “teste-t”, que consiste em um conjunto de
passos para determinar o intervalo de confiança da diferença média entre os
sistemas [23]. Caso o intervalo de confiança encontrado inclua zero, os
sistemas não são significativamente diferentes com um nível de confiança
preestabelecido. Um intervalo de confiança com ambos os valores positivos
indica que SMIL possui melhor desempenho. Caso ambos os valores sejam
negativos, NCL possui melhor desempenho.
3.3 Ambiente e Ferramental
Uma vez que um dos objetivos deste trabalho é medir o impacto da velocidade de
CPU e quantidade de memória sobre o tempo gasto na interpretação dos arquivos, os
experimentos descritos na Seção 3.2 foram realizados em quatro cenários distintos
descritos na Subseção 3.3.1. Além disso, dito que o principal objetivo deste trabalho é
a comparação entre duas linguagens declarativas, fez-se necessário um aplicativo com
a capacidade de tocar ambas. Uma vez que nenhum tocador com essa característica
foi encontrado, optou-se por adaptar o aplicativo X-Smiles para tocar também NCL,
dando origem ao Ginga X-Smiles. A Subseção 3.3.2 apresenta em linhas gerais a
estrutura do aplicativo X-Smiles, enquanto as adaptações realizadas para gerar o
Ginga X-Smiles são apresentadas na Subseção 3.3.3.
3.3.1 Cenários de Avaliação
Os experimentos mencionados na Seção 3.2 foram executados em um PC AMD-
Athlon XP 1800+ (1.533 MHz), 1.256 MB de memória RAM – composto por um
banco de 1 GByte e um banco de 256 MBytes – e sistema operacional Windows XP
Professional, Versão 2002. Este computador estava isolado, ou seja, não encontrava-
37
se ligado a qualquer rede. É importante destacar ainda que antes do início dos
experimentos todos os processos em execução no sistema operacional foram
encerrados, exceto os do próprio sistema operacional, necessários para o
funcionamento deste.
A fim de possibilitar a medição do impacto da velocidade de CPU e quantidade de
memória sobre o tempo gasto na interpretação dos arquivos, a velocidade de CPU e
quantidade de memória RAM foram variados de forma a criar as quatro configurações
apresentadas abaixo. Para variar a velocidade de CPU, alterou-se o clock através da
BIOS do computador. A variação da memória por sua vez, foi realizada através da
remoção/adição física do banco de 1 GByte.
Velocidade de CPU em 1.533 MHz e 1.256 MBytes de memória RAM
Configuração padrão do PC onde os testes foram efetuados. Dos quatro cenários
utilizados é o que possui maior abundância de recursos. Esta configuração caracteriza
um PC comum onde o aplicativo Ginga X-Smiles pode ser executado.
Velocidade de CPU em 1.533 MHz e 256 MBytes de memória RAM
Manteve-se a velocidade de CPU típica do PC e retirou-se um banco de memória
RAM correspondente a 1 GByte, a fim de medir o impacto da quantidade de memória
disponível no desempenho do aplicativo Ginga X-Smiles ao interpretar as linguagens
avaliadas.
Velocidade de CPU em 504 MHz e 1.256 MBytes de memória RAM
Manteve-se a quantidade de memória típica do PC e restringiu-se a velocidade de
CPU, com o intuito de medir o impacto desta no desempenho do aplicativo Ginga X-
Smiles ao interpretar as linguagens avaliadas.
Velocidade de CPU em 504 MHz e 256 MBytes de memória RAM
Configuração com o mínimo de velocidade de CPU e quantidade de memória RAM
disponíveis. Dos quatro cenários utilizados é o que possui maior restrição de recursos
38
e tem como objetivo ser apenas uma aproximação dos recursos encontrados em
dispositivos móveis, como PDA’s (Personal Digital Assistant – Assistente Digital
Pessoal) de última geração, pois se sabe que a arquitetura de processador e de
memória desses dispositivos difere do encontrado em PC’s convencionais.
A Tabela 2 sumariza todos os fatores variados durante os testes, bem como os níveis
de cada fator. Assim, conforme descrito na Seção 3.1, foram feitos testes em duas
linguagens. Para cada linguagem, foram criados 6 arquivos com diferentes números
de elementos. Cada arquivo com determinado número de elementos foi replicado para
os 4 diferentes tipos de mídia suportados. Logo, foram criados 48 arquivos. Cada um
desses arquivos foram utilizados nos experimentos em 4 cenários com diferentes
velocidades de CPU e quantidade de memória RAM, conforme discutido nesta seção.
Como mencionado na Seção 3.2, em cada experimento foram realizadas 3 baterias
com 5 execuções consecutivas cada. Contabilizando todos os fatores variados em seus
diferentes níveis e o número de execuções consecutivas chega-se à conclusão que
foram coletados 2.880 valores referentes ao tempo de CPU gasto para interpretação
dos arquivos.
Linguagem Número de
Elementos
Objetos de
Mídia
Velocidade de
CPU (MHz)
Quantidade
de Memória
RAM (MB)
NCL 1 Vídeo 504 256
SMIL 2 Áudio 1.533 1.256
3 Imagem
5 Texto
10
20
Tabela 2 - Fatores variados nos experimentos
3.3.2 Tocador X-Smiles
X-Smiles é um navegador XML (Extensible Markup Language) de código aberto,
baseado em Java e que tem como principal objetivo ser capaz de exibir documentos
39
escritos em várias linguagens baseadas em XML, inclusive SMIL, cujo tocador foi
implementado como um componente deste navegador. Além disso, possui como
objetivo secundário permitir a reprodução de conteúdo multimídia rico, como áudio e
vídeo. Para essas funcionalidades, o X-Smiles utiliza o JMF.
A arquitetura do X-Smiles pode ser vista na Figura 15 e é composta por cinco
camadas principais (da inferior para a superior): processamento XML, núcleo de
funcionalidades do navegador, componentes funcionais de linguagens de marcação
(MLFCs) em conjunto com o interpretador ECMAScript [15] e interface gráfica com
o usuário. As principais funcionalidades de cada camada são descritas a seguir.
O módulo de processamento XML contém o interpretador (parser) XML -
responsável por interpretar os documentos XML - e o processador XSL, responsável
por processar o documento. A partir do resultado destas operações, uma árvore DOM
(Document Object Model ou Modelo de Objeto de Documentos) [58] é construída e
exibida. O núcleo do navegador é responsável por agrupar os diferentes módulos.
Dentre as partes principais do núcleo podemos citar o Gerenciador de MLFC,
responsável por carregar a MLFC apropriada para um determinado documento. Uma
vez que existem várias linguagens baseadas em XML e cada uma possui sua lógica e
elementos próprios, faz-se necessário o suporte a diferentes módulos de exibição. No
X-Smiles esse papel é realizado pelos componentes funcionais de linguagens de
marcação (MLFCs). Desta forma, o X-Smiles possui vários MLFCs – como o SMIL
MLFC por exemplo – cada um responsável por exibir um tipo específico de
linguagem baseada em XML. Tanto o MLFC base quanto os MLFCs específicos são
encontrados na camada MLFCs. O interpretador ECMAScript provê serviços que
permitem interatividade com o usuário. A camada de Interface Gráfica com o Usuário
implementada com Swing consiste na aplicação, menu de opções, barra de
ferramentas, caixas de mensagens etc.
40
Figura 15 - Arquitetura interna do navegador X-Smiles
3.3.3 Tocador Ginga X-Smiles
Utilizando-se da arquitetura baseada em componentes do aplicativo X-Smiles, criou-
se uma nova MLFC para arquivos NCL, conforme mostrado na Figura 16. Para o
correto funcionamento desta MLFC foram importadas do aplicativo Composer as
classes, arquivos de configuração e trechos de código referentes à interpretação e
reprodução dos arquivos NCL. Após configurar os arquivos de inicialização que
permitiam ao X-Smiles identificar e utilizar a NCL MLFC para interpretar os arquivos
desta linguagem, este aplicativo tornou-se capaz de interpretar e tocar ambas as
linguagens. Assim, como resultado deste trabalho, foi gerado o aplicativo Ginga X-
Smiles.
O Ginga X-Smiles foi compilado utilizando a JDK (Java Development Kit) versão
1.5.0_11 e utilizado nas medições apresentadas neste trabalho. Sabendo-se que a
máquina virtual Java possui vários parâmetros de configuração - incluindo alocação
inicial e alocação máxima de memória, diferentes estratégias de coleta de lixo, dentre
outros - que poderiam influenciar nos resultados deste trabalho, optou-se por utilizar
apenas as configurações definidas pela distribuição original do aplicativo X-Smiles.
Desta forma são definidas configurações necessárias ao correto funcionamento do
aplicativo, porém sem beneficiar/prejudicar qualquer uma das linguagens analisadas.
41
Figura 16 - Arquitetura interna do navegador Ginga X-Smiles
3.4 Limitações
Uma vez explicitadas as cargas, o projeto experimental, os cenários e as ferramentas
utilizadas na avaliação das linguagens, faz-se necessário destacar as limitações desta
avaliação. Considerando-se que os tempo de interpretação coletados e analisados
exprimem o tempo de interpretação do aplicativo Ginga X-Smiles nos diferentes
cenários de velocidade de CPU e quantidade de memória RAM analisados, estão
listados abaixo todos os fatores que, se variados, podem levar a diferentes resultados e
conclusões do que os apresentados neste trabalho.
• Um outro aplicativo ou uma nova implementação do Ginga X-Smiles, com
diferentes técnicas de interpretação das linguagens analisadas ou realizada em
outra linguagem de programação que não Java;
• Parâmetros de configuração da máquina virtual Java utilizada pelo Ginga X-
Smiles. Pode-se citar como principais exemplos os parâmetros referentes à
alocação inicial de memória, alocação máxima de memória e diferentes
estratégias de coleta de lixo;
• Versão da máquina virtual Java e do JMF;
• Número de elementos e tipos de mídia em um mesmo arquivo;
• Versão da especificação das linguagens NCL e SMIL;
• Versão do sistema operacional onde o Ginga X-Smiles é executado;
42
• Influências externas à execução do aplicativo Ginga X-Smiles, como
processos executando em paralelo, acesso de recursos via rede etc;
• Configurações de hardware como marca/velocidade de processador, placa de
vídeo, placa de som etc;
• Forma de variar a velocidade de CPU e quantidade de memória RAM, como
por exemplo a utilização de máquinas virtuais;
• Valores de velocidades mínima e máxima de CPU diferentes dos utilizadas;
• Valores mínimo e máximo de memória RAM diferentes dos utilizados.
Apesar da variação dos fatores supracitados poder levar a diferentes resultados - uma
vez que alteram o funcionamento padrão do aplicativo Ginga X-Smiles - os tempos
médios de interpretação possuem maior suscetibilidade a diferenças do que as
conclusões em si. Essa constatação deve-se ao fato de que nas diferentes
configurações de memória e CPU analisadas, considerando-se as cargas variadas, as
linguagens analisadas apresentaram diferentes tempos médios de interpretação mas
comportamentos semelhantes. Ou seja, apesar do tempo médio variar devido à
restrição de recursos, o comportamento das linguagens não se alterou nos diferentes
cenários. Isto nos leva a crer que, mesmo variações mais drásticas nos fatores
considerados levem à diferentes tempos médios, mas conclusões similares quanto ao
comportamento das linguagens.
43
4 Resultados Experimentais
Este capítulo tem como objetivo apresentar os principais resultados da comparação do
desempenho de interpretação das linguagens NCL e SMIL, utilizando a metodologia
discutida no Capítulo 3. A Seção 4.1 apresenta uma descrição sobre as observações
realizadas durante os experimentos quanto à utilização da memória RAM por cada
uma das linguagens analisadas. Com o intuito de definir qual linguagem possui
melhor desempenho, a Seção 4.2 compara o desempenho de NCL e SMIL analisando-
se as execuções com tempo de carga. O desempenho de ambas as linguagens nas
execuções sem tempo de carga são analisadas na Seção 4.3. A Seção 4.4 analisa o
impacto de velocidade de CPU e velocidade de memória RAM no desempenho das
linguagens analisadas.
4.1 Utilização de Memória RAM
Uma das principais características dos programas escritos em Java é o gerenciamento
automático de memória, realizado através do coletor de lixo (Garbage Collection)
[44]. A principal função do coletor de lixo é eliminar objetos que não são mais
referenciados pela aplicação liberando o espaço de memória ocupado anteriormente
por estes. Dentre as vantagens do coletor de lixo, pode-se destacar que este traz maior
facilidade no desenvolvimento de aplicações, em comparação com outras linguagens
que não o possuem, pois não há a necessidade do desenvolvedor alocar e desalocar
memória explicitamente [56]. Porém, como desvantagem, o coletor de lixo pode
afetar o desempenho das aplicações, pois no processo de localizar e finalizar objetos
sem referência, gasta-se um maior tempo de CPU para liberar os trechos de memória
referentes a estes [56].
Uma vez que os valores coletados durante os experimentos deste trabalho referem-se
ao tempo de CPU gasto pelo aplicativo Ginga X-Smiles para interpretar o conteúdo
dos arquivos, foi necessário verificar a influência do coletor de lixo no desempenho
do aplicativo. Para um melhor entendimento de como a existência do coletor de lixo
influencia o desempenho do aplicativo, uma breve explicação sobre seu
funcionamento é apresentada abaixo.
44
Para realizar o gerenciamento, o coletor de lixo organiza os objetos presentes na
memória em três gerações (áreas específicas da memória). As referências às classes,
aos métodos dos objetos e às constantes são armazenadas na geração Perm, ou
geração permanente. Os novos objetos criados são armazenados na área denominada
Young. Esta área é percorrida constantemente pelo coletor de lixo e todos os objetos
não utilizados são removidos. Quando um objeto sobrevive a diversas execuções do
coletor de lixo na área Young, ele é copiado para a área Tenured. Periodicamente, o
coletor de lixo percorre também a área Tenured. Este processo é chamado de coleta de
lixo completa (full garbage collection). Ao contrário da coleta de lixo na área Young,
a coleta de lixo na área Tenured requer maior tempo de CPU, pois ao invés de
verificar apenas os objetos recentemente criados, é necessário verificar todos os
objetos presentes na memória. Sendo assim, todas as execuções estão sujeitas à coleta
de lixo da área Young, porém somente durante algumas execuções ocorre a coleta de
lixo completa, que por gastar mais tempo de CPU termina por influenciar o tempo
medido da execução em questão de forma muito mais significativa
Após a realização de várias medições e acompanhamento do uso de memória pelo
aplicativo Ginga X-Smiles através da ferramenta nativa da máquina virtual Java
denominada JConsole [54], concluiu-se que:
• Nas cinco execuções consecutivas de uma mesma bateria de experimentos, em
arquivos SMIL, a coleta de lixo completa não é executada. É possível observar
este comportamento através da Figura 17, uma vez que a quantidade total de
memória RAM utilizada apenas cresce ligeiramente com o passar do tempo.
Desta forma, nenhum dos cinco valores coletados é influenciado pela coleta de
lixo completa. Conforme apresentado na Figura 18, sem a influência do
coletor de lixo, os tempos coletados possuem valores bem próximos, com
exceção da primeira execução, que inclui o tempo de carga discutido na Seção
3.2.
45
3
4
5
6
7
Tempo do ExperimentoTo
tal d
e M
emó
ria
RA
M A
loca
da
(MB
)Exec. # 1
Exec. # 2 Exec. # 3 Exec. # 4 Exec. # 5
Figura 17 - Uso de memória na geração Tenured em SMIL
0
200
400
600
800
# 1 # 2 # 3 # 4 # 5
Execuções
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Figura 18 – Tempo médio de interpretação coletados em cinco execuções consecutivas de um
arquivo SMIL
• Nas cinco execuções consecutivas de uma mesma bateria de experimentos,
em arquivos NCL, a coleta de lixo completa é executada sempre durante a
primeira execução e ocasionalmente durante a terceira execução, podendo
variar dependendo do tipo de mídia e do número de objetos de mídia presentes
no arquivo.
A Figura 19 mostra um comportamento típico de arquivos que contêm objetos de
mídia do tipo vídeo. É possível observar que a coleta de lixo completa é realizada
46
durante a primeira e a terceira execução, uma vez que a quantidade de memória RAM
utilizada diminui bruscamente durante estas execuções. A Figura 20 apresenta os
tempos referentes a cada umas das cinco execuções apresentadas na figura anterior.
Analisando-a é possível observar que as execuções com influência do coletor de lixo
possuem tempo muito superior às outras execuções. A primeira execução, que além
da influência do coletor de lixo possui o tempo de carga apresentado na Seção 3.2, é
discrepante em relação às outras. A terceira execução, influenciada apenas pelo
coletor de lixo, possui tempo de duas a três vezes maior que as execuções restantes.
3
4
5
6
7
Tempo do ExperimentoTo
tal d
e M
emó
ria
RA
M A
loca
da
(MB
)
Exec. # 1 Exec. # 2 Exec. # 3
Exec. # 4
Exec. # 5
Figura 19 - Uso de memória na geração Tenured em NCL
0
500
1000
1500
2000
# 1 # 2 # 3 # 4 # 5
Execuções
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Figura 20 - Tempo médio de interpretação coletados em cinco execuções consecutivas de um
arquivo NCL
47
Dado que os tempos das execuções com tempo de carga - conforme categorização
apresentada na Seção 3.2 - serão analisadas separadamente, o tempo da coleta de lixo
completa será considerada como parte do tempo de interpretação dos arquivos, uma
vez que sua execução é parte do funcionamento característico da linguagem NCL.
Entretanto, nas execuções sem tempo de carga, os tempos influenciados pela coleta de
lixo completa passam a ser discrepantes em relação aos tempos das demais execuções
- conforme ilustrado na Figura 20. Uma vez que a média calculada a partir destes
tempos não seria significativa devido à influência do coletor de lixo, optou-se por, nos
experimentos com arquivos da linguagem NCL, descartar execuções durante às quais
a coleta de lixo completa foi realizada. Experimentos extras foram então executados
de forma a manter o número de experimentos igual a cinco para as duas linguagens. É
importante ressaltar que este procedimento tende a favorecer a linguagem NCL na
comparação com SMIL, uma vez que os maiores tempos de execução - influenciados
pela coleta de lixo - são descartados. Porém, este procedimento visa uma menor
variância nos valores coletados, obtendo-se assim médias e intervalos de confiança
mais precisos e significativos.
4.2 Execuções Com Tempo de Carga
Uma vez coletados os tempos referentes às execuções com tempo de carga, calculou-
se a média aritmética dos tempos destas execuções. O valor encontrado representa o
tempo médio gasto pelo aplicativo Ginga X-Smiles para interpretar os arquivos NCL
e SMIL. Além da média calculou-se também o intervalo de confiança de 90% desta,
ou seja, um intervalo de tempo que, com noventa porcento de confiança, contém o
tempo médio de interpretação dos arquivos. Em 4.2.1, apresentamos uma comparação
entre as duas linguagens para arquivos com variados números de recursos,
considerando cada tipo de mídia separadamente. A Seção 4.2.2 contrasta, para cada
linguagem e fixado o número de recursos, o desempenho para diferentes mídias a fim
de determinar se este é influenciado pelo tipo de mídia. Por fim, as principais
conclusões obtidas são sumarizadas na Seção 4.2.3.
4.2.1 Desempenho Relativo entre NCL e SMIL
Nesta seção são apresentados - agrupados por tipo de mídia - os gráficos comparativos
contendo os tempos médios de interpretação dos arquivos NCL e SMIL, o intervalo
de confiança das médias e as conclusões obtidas através da análise dessas
48
comparações, para as excuções com tempo de carga na configuração com mais
recursos disponíveis, ou seja, velocidade de CPU em 1.533 MHz e 1.256 MB de
memória RAM. É importante ressaltar que estes gráficos apresentam o eixo “y” em
escala logarítmica pois, uma vez que arquivos contendo muitos recursos apresentam
tempo médio muito superior a arquivos contendo poucos recursos, em uma escala
aritmética não haveria diferença visual entre os menores tempos.
Vídeo e Áudio
Analisando-se os resultados obtidos, concluiu-se que a comparação entre arquivos
NCL e arquivos SMIL contendo recursos de vídeo ou áudio apresentam resultados
similares. Desta forma, apresentamos na Figura 21 os tempos médios e intervalos de
confiança para arquivos com recursos de vídeo, mas que ilustra o comportamento de
ambos os tipos de mídia (o gráfico com a comparação de arquivos contendo recursos
de áudio encontra-se no Apêndice C). Analisando-se esta figura, pode-se concluir a
respeito das execuções com tempo de carga para arquivos contendo vídeos ou áudios:
• O tempo médio de interpretação de arquivos NCL não sofre grandes alterações
com o crescimento do número de recursos presentes no arquivo.
• Ao contrário de NCL, o tempo médio de interpretação de arquivos SMIL
cresce à medida que o número de recursos incluídos em um arquivo aumenta.
Assim, pode-se concluir que NCL possui melhor escalabilidade que SMIL, e
que esta última apresenta grande degradação à medida que o número de
recursos em um arquivo cresce.
• O intervalo de confiança para arquivos SMIL com 20 recursos cresce
consideravelmente, significando que a variabilidade dos tempos de
interpretação medidos também aumenta, o que em contrapartida diminui a
previsibilidade dos tempos de interpretação da linguagem SMIL.
• SMIL possui desempenho superior a NCL em arquivos com 1, 2, 3 e 5
recursos. Porém, por ser mais escalável, NCL possui desempenho superior a
SMIL em arquivos com 10 e 20 recursos.
49
10
100
1000
10000
1 2 3 5 10 20
Número de Vídeos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)NCL
SMIL
Figura 21 - NCL x SMIL com vídeos em execuções com tempo de carga
Além de serem verificadas visualmente na Figura 21, é possível reforçar as
conclusões através da Tabela 3, que apresenta a diferença percentual entre as
linguagens em arquivos contendo vídeos e arquivos contendo áudios, com diferentes
números de recursos. O valor da diferença percentual apresentado é calculado através
da fórmula:
Tempo Médio de Interpretação de NCL – Tempo Médio de Interpretação de SMIL
Tempo Médio de Interpretação de SMIL
Analisando-se a Tabela 3 é possível observar o quanto o desempenho de NCL é
superior ou inferior a SMIL. É possível observar ainda que a diferença entre as
linguagens é mais acentuada em arquivos com recursos de áudio do que com recursos
de vídeo. Em um arquivo com um vídeo, por exemplo, NCL possui desempenho
183% inferior a SMIL, enquanto que, para a mesma quantidade de áudios, o
desempenho é 323% inferior. Com dois recursos, NCL é 134% inferior no caso de
arquivos com vídeos e 219% inferior em arquivos com áudios. A diferença entre as
linguagens diminui à medida que o número de recursos aumenta, até que com cinco
recursos em um arquivo, NCL é apenas 29,3% inferior a SMIL em arquivos com
vídeos e 42,6% inferior em arquivos com áudios. Com dez recursos NCL começa
apresentar desempenho superior a SMIL, sendo 12% superior em arquivos com
vídeos e 5,3% superior em arquivos com áudios. Com vinte recursos em um arquivo,
NCL passa a ser 60,6% superior em arquivos com vídeos e 50,5% superior em
arquivos com áudios. Este comportamento evidencia a degradação do desempenho de
SMIL com grande quantidade de recursos e ressalta a melhor escalabilidade de NCL.
50
Diferença de Desempenho entre NCL e SMIL Vídeo Áudio 1 Recurso 183% 323% 2 Recursos 134% 219% 3 Recursos 110% 184% 5 Recursos 29,3% 42,6% 10 Recursos -12% -5,3% 20 Recursos -60,6% -50,5%
Tabela 3 - Diferença de desempenho das linguagens para interpretar vídeos e áudios em
execuções com tempo de carga
Imagem e Texto
Bem como arquivos contendo vídeo e arquivos contendo áudio apresentam resultados
similares, os resultados de arquivos NCL e arquivos SMIL contendo recursos de
imagem ou texto também pode ser agrupados. Desta forma, apresentamos na Figura
22 os tempos médios e intervalos de confiança para arquivos com recursos de
imagem, mas que ilustra o comportamento de ambos os tipos de mídia (o gráfico com
a comparação de arquivos contendo recursos de texto encontra-se no Apêndice C).
Analisando-se essa figura, pode-se concluir a respeito das execuções com tempo de
carga para arquivos contendo imagens ou textos:
• O tempo médio de interpretação de arquivos NCL não sofre grandes alterações
com até 10 recursos incluídos em um arquivo. Com mais de 10 recursos em
um mesmo arquivo, o tempo médio cresce consideravelmente.
• Conforme observado anteriormente em arquivos com vídeos ou áudios, ao
contrário de NCL, o tempo médio de interpretação de arquivos SMIL cresce à
medida que o número de recursos incluídos em um arquivo aumenta.
• SMIL possui desempenho superior a NCL, independente do número de
recursos em um arquivo.
51
10
100
1000
10000
1 2 3 5 10 20
Número de Imagens Incluídas
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)NCL
SMIL
Figura 22 - NCL x SMIL com imagens em execuções com tempo de carga
Uma vez que o gráfico apresentado na Figura 22 apresenta o eixo “y” em escala
logarítmica, a diferença do tempo médio de interpretação de arquivos NCL com 20
imagens pode parecer pequena se comparado ao tempo médio dos outros arquivos. A
Figura 23 representa o mesmo gráfico da figura anterior, porém apenas com as médias
e intervalo de confiança referentes aos arquivos NCL e com escala linear reduzida.
Observando-se esta figura é possível ver com clareza que os tempos médios para
interpretar arquivos com 1, 2, 3, 5 ou 10 imagens não são estatisticamente diferentes -
com 90% de confiança - uma vez que o intervalo de confiança de um arquivo contém
a média de outro e vice-versa. O tempo médio para interpretar um arquivo com 20
imagens, por sua vez, é visivelmente maior, sendo cerca de 1,55 vezes mais lento que
o tempo médio gasto para interpretar um arquivo com 10 imagens. Além disso, o
intervalo de confiança também cresce, o que significa que o tempo para interpretar um
arquivo com 20 imagens além de mais lento, apresenta maior variabilidade,
diminuindo a previsibilidade dos tempos de interpretação. É importante lembrar que
estas mesmas observações são válidas para arquivos contendo recursos de texto.
52
1000
2500
1 2 3 5 10 20
Número de Imagens Incluídas
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)NCL
Figura 23 – Média e intervalo de confiança de NCL com imagens em execuções com tempo de
carga
Além de serem verificadas visualmente na Figura 22 e Figura 23, é possível reforçar
as conclusões através da Tabela 4. Analisando-se esta tabela, é possível observar o
quanto o desempenho de NCL é inferior a SMIL. É possível observar ainda que a
diferença entre as linguagens é mais acentuada em arquivos com recursos de imagem
do que com recursos de texto. Em um arquivo com uma imagem, por exemplo, NCL
possui um tempo médio de interpretação 1.153% maior que SMIL, ou seja, quase 13
vezes maior, enquanto que para a mesma quantidade de textos a diferença – embora
bastante significativa – é de apenas 176%. Bem como em arquivos com recursos de
vídeo e áudio, a diferença entre as linguagens tende a diminuir com o aumento de
recursos incluídos em um arquivo uma vez que, diferentemente de NCL com até 10
recursos, o tempo de interpretação de SMIL cresce à medida que o número de
recursos cresce. Assim, com dez recursos, NCL é 334% inferior a SMIL no caso de
arquivos com imagens e 22,5% inferior em arquivos com texto. Porém, com vinte
recursos em um arquivo a diferença entre as linguagens volta a aumentar pois, nesse
caso NCL também passa a apresentar degradação de desempenho. Desta forma, a
linguagem NCL passa a ser 397% inferior a SMIL em arquivos contendo imagens e
28% inferior em arquivos contendo textos. Com isso é possível concluir que para
arquivos com imagens ou textos, NCL possui melhor escalabilidade que SMIL, mas
passa a apresentar degradação do desempenho para mais de 10 recursos em um
arquivo. Entretanto, apesar de ser mais escalável, NCL possui desempenho inferior a
SMIL.
53
Diferença de Desempenho entre NCL e SMIL Imagem Texto 1 Recurso 1153% 176% 2 Recursos 640% 158% 3 Recursos 692% 124% 5 Recursos 431% 90,8% 10 Recursos 334% 22,5% 20 Recursos 397% 28%
Tabela 4 - Diferença de desempenho das linguagens para interpretar imagens e textos em
execuções com tempo de carga
4.2.2 Impacto do Tipo de Mídia
Comparando-se os valores apresentados na Tabela 3 e Tabela 4 - referentes aos quatro
tipos de mídia analisados - é possível perceber que a diferença entre as linguagens é
mais evidente para alguns tipos de mídia. Em arquivos com um vídeo, por exemplo,
NCL é 183% inferior a SMIL, enquanto que em arquivos com uma imagem a
diferença percentual chega a 1.153% vezes. A partir dessa observação, é possível
formular a seguinte hipótese: o desempenho relativo de cada uma das linguagens
depende do tipo de mídia? Para responder esta questão, a Figura 24 e a Figura 25
apresentam - para NCL e SMIL respectivamente - fixando o número de recursos, a
comparação dos tempos médios de interpretação dos arquivos com os diferentes tipos
de mídia apresentados. Analisando-se a Figura 24 é possível perceber que para NCL
os tempos médios para interpretação de vídeos e áudios são bem próximos, porém
áudio possui melhor desempenho independente do número de recursos incluídos.
Além disso, os tempos médios para interpretação de imagens e texto são ainda mais
próximos entre si - sendo estatisticamente iguais com 90% de confiança - e
claramente menores que os tempos referentes à interpretação de arquivos com vídeos
e áudios. A exceção se faz quando um arquivo possui 20 recursos. Conforme
observado anteriormente, nesse caso NCL apresenta degradação do tempo ao
interpretar arquivos com imagens e textos. Assim, para arquivos com 20 recursos, o
tempo médio para interpretação destes objetos de mídia supera o tempo médio de
arquivos com vídeos e áudios.
54
0
500
1000
1500
2000
2500
3000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Vídeo
Áudio
Imagem
Texto
Figura 24 - Comparativo do tempo médio com tempo de carga para os quatro objetos de mídia
em arquivos NCL
Observando-se a Figura 25 é possível ver claramente a diferença de desempenho na
interpretação de diferentes tipos de mídia para arquivos SMIL. Independentemente do
número de recursos, o tempo de interpretação de arquivos com imagens é
consideravelmente inferior aos demais objetos de mídia, enquanto a interpretação de
arquivos com vídeos possui o pior desempenho. Arquivos com um recurso de áudio
possuem desempenho superior a arquivos com um recurso de texto. Já para arquivos
com dois ou três recursos, com 90% de confiança, pode-se dizer que os tempos
médios de interpretação para arquivos com áudio e texto não são significativamente
diferentes. A partir de cinco recursos, arquivos com recursos de texto apresentam
desempenho superior a arquivos com áudios.
0
1000
2000
3000
4000
5000
6000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Vídeo
Áudio
Imagem
Texto
Figura 25 - Comparativo do tempo médio com tempo de carga para os quatro objetos de mídia
em arquivos SMIL
55
A análise da Figura 24 e da Figura 25 responde positivamente a hipótese elaborada,
ou seja, o desempenho relativo de cada linguagem depende do tipo de mídia.
4.2.3 Sumário
As principais conclusões da comparação entre as linguagens e diferentes tipos de
mídia em execuções com tempo de carga, considerando-se os cenários e cargas
utilizados, são:
• NCL possui maior escalabilidade que SMIL. Enquanto SMIL apresenta
degradação do desempenho à medida que o número de recursos incluídos em
um arquivo aumenta – independentemente do tipo de mídia – o ponto de
degradação de NCL varia dependendendo do tipo de mídia. Para vídeo e
áudio, a degradação não é notada até 20 recursos em um arquivo. Para imagem
e texto, a degradação é notada em arquivos com mais de 10 recursos.
• Apesar de ser mais escalável, NCL apresenta desempenho significativamente
inferior ao desempenho de SMIL na grande maioria dos casos analisados.
• Na maior parte dos casos, em ambas as linguagens, a previsibilidade do tempo
de interpretação diminui em arquivos com maior número de recursos.
• Arquivos NCL apresentam melhor desempenho ao interpretar arquivos com
recursos de imagens ou textos. O segundo melhor desempenho de
interpretação é encontrado em arquivos com recursos de áudio. Por fim, o pior
desempenho é encontrado durante a interpretação de arquivos com recursos de
vídeo.
• Arquivos SMIL apresentam melhor desempenho ao interpretar arquivos com
recursos de imagem. O segundo melhor desempenho é dividido entre arquivos
que possuem recursos de texto e arquivos com recursos de áudio, conforme
análise anterior. Por fim, como para NCL, arquivos com recursos de vídeo
apresentam o pior desempenho.
4.3 Execuções Sem Tempo de Carga
Bem como realizado em execuções com tempo de carga, calculou-se a média e o
intervalo de confiança das execuções sem tempo de carga. Na Seção 4.3.1,
apresentamos uma comparação entre as duas linguagens para arquivos com variados
56
números de recursos, considerando cada tipo de mídia separadamente. A Seção 4.3.2
contrasta, para cada linguagem e fixado o número de recursos, o desempenho para
diferentes mídias a fim de determinar se este é influenciado pelo tipo de mídia. Por
fim, as principais conclusões obtidas são sumarizadas na Seção 4.3.3.
4.3.1 Desempenho Relativo entre NCL e SMIL
Nesta seção são apresentadas as conclusões referentes às execuções sem tempo de
carga na configuração com mais recursos disponíveis, ou seja, velocidade de CPU em
1.533 MHz e 1.256 MB de memória RAM. Analisando-se os resultados obtidos,
porém, concluiu-se que a comparação entre os arquivos NCL e SMIL apresentam
conclusões similares para todos os tipos de mídia apresentados. Assim, apresentamos
na Figura 26 os tempos médios e intervalos de confiança para arquivos com recursos
de vídeo, mas que ilustra o comportamento de todos os tipos de mídia (os gráficos
com a comparação de arquivos contendo outros tipos de mídia encontra-se no
Apêndice D). As conclusões obtidas a partir deste gráfico, também válidas para todos
os tipos de mídia, são:
• NCL possui desempenho superior, ou no mínimo igual, a SMIL em todas as
execuções sem tempo de carga. NCL é estatisticamente igual a SMIL com
90% de confiança em arquivos com 1 recurso de vídeo e em arquivos com 1
ou 2 recursos de texto. Em todos os outros casos, NCL apresenta desempenho
superior.
• Ao contrário de NCL, o tempo médio de interpretação de arquivos SMIL
cresce à medida que o número de recursos incluídos em um arquivo aumenta.
Bem como nas execuções com tempo de carga, em execuções sem tempo de
carga, NCL possui melhor escalabilidade que SMIL, e esta última apresenta
grande degradação à medida que o número de recursos em um arquivo cresce.
57
10
100
1000
10000
1 2 3 5 10 20
Número de Vídeos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)NCL
SMIL
Figura 26 - NCL x SMIL com vídeos em execuções sem tempo de carga
A Tabela 5 apresenta as diferenças entre o desempenho de interpretação dos arquivos
NCL e SMIL para os diferentes tipos de mídia. É importante ressaltar que as
diferenças só foram calculadas para cenários em que o teste-t (vide Capítulo 3)
apresentou diferença significativa entre as linguagens. Com exceção de arquivos com
apenas um vídeo ou um texto e arquivos com dois textos – para os quais os tempos de
interpretação das duas linguagens são estatisticamente iguais com 90% de confiança –
NCL possui desempenho superior a SMIL em todas as execuções sem tempo de
carga. Desse forma, para melhor apresentação das diferenças percentuais, utilizou-se a
fórmula:
Tempo Médio de Interpretação de SMIL – Tempo Médio de Interpretação de NCL
Tempo Médio de Interpretação de SMIL
Analisando-se os valores da diferença entre as linguagens, é possível perceber que o
percentual da diferença cresce à medida que o número de recursos em um arquivo
cresce. Conforme dito anteriormente, uma vez que SMIL apresenta grande
degradação no tempo de interpretação à medida que o número de recursos em um
arquivos cresce e NCL possui melhor escalabilidade, a diferença tende a crescer
juntamente com o número de recursos em um arquivo. A exceção dá-se em arquivos
com recursos de imagem e texto com mais de cinco recursos, onde a diferença começa
a decrescer, o que indica que NCL também passa a apresentar degradação no tempo
de interpretação. Comparando-se a tabela em questão com a Tabela 3 e a Tabela 4,
conclui-se que esta degradação dá-se mais cedo em execuções sem tempo de carga,
uma vez que em execuções com tempo de carga a degradação só é notada para mais
58
de dez recursos por arquivos. Ainda comparando-se a tabela em questão com as
tabelas anteriores, observa-se que em execuções com tempo de carga onde NCL já
possuía desempenho superior, nas execuções sem tempo de carga as diferenças de
desempenho são mais acentuadas. Em um arquivo contendo vinte vídeos, por
exemplo, NCL possui desempenho 60,6% superior a SMIL em execuções com tempo
de carga. Esta diferença sobe para 90,5% em execuções sem tempo de carga.
Diferença de Desempenho entre NCL e SMIL Vídeo Áudio Imagem Texto
1 Recurso Iguais com 90%
de Confiança 80,0% 65,4% Iguais com 90%
de Confiança
2 Recursos 38,1% 89,5% 78,7% Iguais com 90%
de Confiança 3 Recursos 40,9% 96,1% 83,2% 65,7% 5 Recursos 64,9% 97,4% 88,1% 84,9% 10 Recursos 79,8% 98,0% 85,0% 57,8% 20 Recursos 90,5% 99,1% 78,9% 51,3% Tabela 5 - Diferença de desempenho das linguagens para interpretação em execuções sem tempo
de carga
4.3.2 Impacto do Tipo de Mídia
Sabendo-se que o desempenho relativo de cada linguagem depende do tipo de mídia,
são comparados os tempos médios de interpretação dos arquivos com os diferentes
tipos de mídia analisados. A Figura 27 mostra os tempos médios da linguagem NCL.
Pode-se perceber claramente que a diferença entre o tempo médio de arquivos
contendo vídeo e arquivos contendo outros tipos de mídia em execuções sem tempo
de carga é muito superior à diferença apresentada em execuções com tempo de carga.
A única exceção se faz no caso do arquivo com 20 recursos de texto, que devido à
degradação do tempo de interpretação apresentada em arquivos com este recurso,
supera o tempo de interpretação do arquivo com recursos de vídeo. O segundo pior
desempenho de interpretação se dá em arquivos contendo recursos de texto, seguido
pelos arquivos contendo recursos de imagem. Assim, o melhor desempenho é
encontrado em arquivos contendo recursos de áudio. Através desta figura ainda é
possível observar que, para arquivos com 10 e 20 recursos de texto, o intervalo de
confiança cresce significativamente, indicando que o tempo para interpretar estes
arquivos apresenta maior variabilidade, diminuindo a previsibilidade dos tempos de
interpretação.
59
0
100
200
300
400
500
600
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Vídeo
Áudio
Imagem
Texto
Figura 27 - Comparativo do tempo médio sem tempo de carga para os quatro objetos de mídia
em arquivos NCL
Observando-se a Figura 28 é possível identificar, inicialmente, que os tempos médios
de interpretação de arquivos SMIL com recursos de vídeos e áudios são
consideravelmente superiores aos tempos de arquivos com imagens e textos. Arquivos
com recursos de áudio apresentam pior desempenho quando possuem 2, 3, 5 ou 10
recursos incluídos, enquanto arquivos com recurso de vídeo possuem maior tempo
médio de interpretação quando possuem 1 ou 20 recursos. Arquivos com recursos de
imagem apresentam pior desempenho que arquivos com textos quando possuem 1 ou
2 recursos incluídos. Com 3 ou 5 recursos os tempos médios de interpretação destes
arquivos não são significativamente diferentes, com 90% de confiança. Com 10 ou 20
recursos em um arquivo, a situação se inverte e arquivos com recursos de imagem
passam a ter melhor desempenho que arquivos com recursos de texto. Estes
resultados, no geral, são qualitativamente semelhantes aos obtidos em execuções com
tempo de carga.
0
500
1000
1500
2000
2500
3000
3500
4000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
Vídeo
Áudio
Imagem
Texto
Figura 28 - Comparativo do tempo médio sem tempo de carga para os quatro objetos de mídia
em arquivos SMIL
60
Assumindo que os interpretadores de arquivos de cada linguagem possuem lógicas e
desempenhos diferentes devido à semântica de cada uma, comparou-se os
mecanismos de cache, preparação para exibição e exibição dos recursos de ambas as
linguagens, a fim de entender as diferenças no tratamento dos tipos de mídia. A seguir
os resultados obtidos categorizados por tipo de mídia:
• Vídeo: ambas as linguagens utilizam JMF para preparação e exibição dos
vídeos, justificando a similaridade de comportamento. Sendo assim, a
diferença de desempenho entre as linguagens é atribuída aos mecanismos de
interpretação.
• Imagem: ambas as linguagens utilizam recursos da JVM (Java Virtual
Machine) para cache, preparação e exibição das imagens. Sendo assim, a
diferença de desempenho entre as linguagens é atribuída aos mecanismos de
interpretação.
• Áudio: para tocar áudios, SMIL utiliza a Java Sound API [25], enquanto NCL
utiliza JMF. Uma vez que o desempenho de NCL para interpretação de
arquivos com recursos de áudio é superior a SMIL, alterou-se o interpretador
de arquivos SMIL para também utilizar JMF. Em execuções sem tempo de
carga, o desempenho de interpretação utilizando-se JMF mostrou-se cerca de
80% superior à abordagem utilizando Java Sound API, com qualquer
quantidade de áudios em um arquivo. Apesar deste ganho considerável, o
desempenho de interpretação de arquivos SMIL tornou-se no máximo,
estatisticamente igual - com 90% de confiança - ao desempenho de
interpretação de arquivos NCL. No entanto, devido à degradação encontrada
em SMIL, NCL volta a apresentar melhor desempenho à medida que o número
de elementos em um arquivo cresce. A Figura 29 apresenta a comparação
entre os tempos médios de NCL, de SMIL com Java Sound API e de SMIL
com JMF. A figura em questão mostra que com essa nova abordagem SMIL
passou a ser estatisticamente igual a NCL com 90% de confiança em arquivos
com um recurso áudio. Em arquivos com dez e vinte áudios a diferença entre
as linguagens diminui. No primeiro caso, NCL passa a apresentar desempenho
89,3% superior a SMIL. Já para arquivos com vinte áudios, o desempenho de
NCL passa a ser 95,9% superior a SMIL.
61
0
500
1000
1500
2000
2500
3000
3500
1 10 20
Número de Áudios Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)NCL
SMIL - Java Soud API
SMIL - JMF
Figura 29 - Comparativo entre NCL e as duas abordagens de SMIL para arquivos com áudios
em execuções sem tempo de carga
• Texto: verificou-se que devido a um erro no código do interpretador de
arquivos NCL o cache dos recursos de texto não era realizado, ou seja, a cada
execução todos os recursos de texto utilizados em um arquivos eram relidos e
recriados em memória. Ao corrigir o interpretador de arquivos NCL para
realizar cache dos recursos utilizados, o desempenho para este tipo de mídia
mostrou-se cerca de 40% superior em arquivos com mais de 5 recursos, em
execuções sem tempo de carga. É importante destacar que o Ginga X-Smiles
utiliza a versão 1.1.0 do interpretador NCL, e que a versão mais recente deste
interpretador liberada pela comunidade Ginga em 15/08/08 - e portanto
posterior às análises realizadas neste trabalho - possui a correção oficial do
cache de recursos de texto. Tendo em vista que NCL já apresentava
desempenho superior a SMIL anteriormente, o ganho apresentado ressalta o
melhor desempenho de NCL frente a SMIL. A Figura 30 apresenta a
comparação entre os tempos médios de SMIL, NCL sem cache e NCL com
cache. A figura em questão mostra que com a correção do código, NCL passa
a ser 72,1% superior a SMIL em arquivos com 10 recursos e 77,3% superior
em arquivos com 20 recursos de texto.
62
0
200
400
600
800
1000
10 20
Número de Textos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL - Sem Cache
SMIL
NCL - Com Cache
Figura 30 - Comparativo entre SMIL e as duas abordagens de NCL para arquivos com textos em
execuções sem tempo de carga
4.3.3 Sumário
Analisados os quatro tipos de mídia propostos pode-se concluir, considerando-se os
cenários e cargas utilizados, a respeito da execução sem tempo de carga:
• Bem como observado em execuções com tempo de carga, NCL possui maior
escalabilidade que SMIL. Enquanto SMIL apresenta degradação do
desempenho à medida que o número de recursos incluídos em um arquivo
aumenta, o ponto de degradação de NCL varia dependendendo do tipo de
mídia.
• Ao contrário do observado em execuções com tempo de carga, NCL apresenta
desempenho superior - ou pelo menos estatisticamente igual - ao desempenho
de SMIL nos casos analisados. Entretanto, é importante lembrar que a
linguagem NCL foi favorecida durante os testes, uma vez que os tempos de
execução influenciados pela coleta de lixo completa - tempos
significativamente maiores do que os tempos de execuções onde não há coleta
de lixo completa - foram descartados.
• Bem como em execuções com tempo de carga, na maior parte dos casos, em
ambas as linguagens, a previsibilidade do tempo de interpretação diminui em
arquivos com maior número de recursos.
• Arquivos NCL contendo recursos de áudio apresentam o melhor desempenho
de interpretação, ao contrário de execuções com tempo de carga, onde o
63
desempenho para interpretar arquivos com recursos de áudio é inferior a
arquivos com recursos de imagem e texto. Excetuando-se recursos de áudio, os
demais tipos de mídia apresentam o mesmo comportamento de execuções com
tempo de carga.
• O melhor desempenho em arquivos SMIL é dividido entre arquivos que
possuem recursos de imagem e arquivos com recursos de texto, conforme
análise anterior. O segundo melhor desempenho é observado em arquivos
contendo recursos de vídeo. Por fim, ao contrário do comportamento
observado nas execuções considerando-se o tempo de carga, arquivos
contendo recursos de áudio apresentam o pior desempenho.
4.4 Impacto da Variação de Velocidade de CPU e Quantidade
Memória RAM
Conforme apresentado na Seção 3.3, os tempos médios de interpretação de cada um
dos arquivos utilizados nos experimentos desta dissertação foram coletados em quatro
cenários, onde foram variados velocidade de CPU e quantidade de memória RAM
disponível, com o objetivo de estimar o impacto de cada um destes fatores no tempo
médio de interpretação das linguagens. Enquanto as seções 4.2 e 4.3 apresentam as
análises baseadas na configuração com mais recursos disponíveis - velocidade de
CPU em 1.533 MHz e 1.256 MB de memória RAM - as subseções 4.4.1 e 4.4.2
contrastam os resultados obtidos para os quatro cenários avaliados.
4.4.1 Execuções Com Tempo de Carga
Analisando-se os resultados obtidos nas execuções com tempo de carga concluiu-se
que a comparação entre os arquivos NCL e SMIL apresentam conclusões similares
para todos os tipos de mídia apresentados. Assim, os gráficos abaixo referem-se a
arquivos com recursos de vídeo, porém as conclusões de sua análise são válidas para
todos os objetos de mídia (os gráficos com a comparação de arquivos contendo outros
tipos de mídia encontram-se no Apêndice C).
Analisando-se a Figura 31 e a Figura 32 – referente a arquivos NCL e SMIL,
respectivamente – é possível perceber que para execuções com tempo de carga, a
velocidade de CPU tem impacto mais significativo no tempo médio de interpretação
64
do que quantidade de memória RAM. Esse fato é claramente observado através de
dois comportamentos:
• As barras referentes às configurações com mesma velocidade de CPU mas
diferentes quantidades de memória RAM possuem tempos de interpretação
estatisticamente iguais com 90% de confiança na maioria dos casos, indicando
que a quantidade de memória RAM não tem grande impacto no tempo de
interpretação.
• De forma análoga, as barras referentes às configurações com diferente
velocidade de CPU e mesma quantidade de memória RAM possuem tempos
de interpretação em diferente ordem de grandeza, indicando que a velocidade
de CPU tem grande impacto no tempo de interpretação.
0
1000
2000
3000
4000
5000
6000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
Figura 31 - Comparativo do tempo médio com tempo de carga para os quatro cenários propostos
em arquivos NCL com vídeo
A Figura 32 mostra que a degradação encontrada em arquivos SMIL à medida que o
número de recursos incluídos em um arquivo cresce (vide Seção 4.2), é ressaltada em
configurações com menos recursos disponíveis, principalmente velocidade de CPU.
Desta forma, arquivos com 20 vídeos em configurações com baixa velocidade de CPU
possuem tempos de interpretação significativamente maiores que de outros arquivos.
65
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
Figura 32 - Comparativo do tempo médio com tempo de carga para os quatro cenários propostos
em arquivos SMIL com vídeo
A Tabela 6 apresenta a sumarização da diferença percentual do tempo de
interpretação dos arquivos para cada um dos fatores variados, para ambas as
linguagens analisadas e para todos os objetos de mídia apresentados. O valor da
diferença percentual referente à degradação do desempenho quando a velocidade de
CPU é diminuída é calculado através da fórmula:
Tempo Médio para Configuração 3 – Tempo Médio para Configuração 1
Tempo Médio de Interpretação Configuração 1
Neste fórmula, “Configuração 1” refere-se à configuração com mais recursos
disponíveis, ou seja, velocidade de CPU em 1.533 MHz e 1.256 MB de memória
RAM. Já “Configuração 3” refere-se à configuração onde variou-se a velocidade de
CPU e manteve-se a quantidade de memória RAM, ou seja, velocidade de CPU em
504 MHz e 1.256 MB de memória RAM. Da mesma forma, o valor da diferença
percentual referente à degradação do desempenho quando a quantidade de memória
RAM é diminuída é calculado através da fórmula:
Tempo Médio para Configuração 2 – Tempo Médio para Configuração 1
Tempo Médio de Interpretação Configuração 1
Neste fórmula, “Configuração 1” refere-se à configuração com mais recursos
disponíveis e “Configuração 2” refere-se à configuração onde manteve-se a
velocidade de CPU e variou-se a quantidade de memória RAM, ou seja, velocidade de
CPU em 1.533 MHz e 256 MB de memória RAM. Em ambos os cálculos o sinal do
resultado da subtração foi ignorado, a fim de que todos os valores da diferença
66
percentual apresentados sejam positivos. Uma vez calculadas a diferença percentual
referente a cada um dos arquivos testados, foi calculada a média aritmética destas
diferenças. A Tabela 6 é composta por estas médias.
Analisando-se a Tabela 6 é possível perceber claramente o maior impacto causado
pela variação da velocidade de CPU no tempo de interpretação, sendo este fator
responsável por no mínimo 155% da variação no tempo de interpretação em ambas as
linguagens. Já a quantidade de memória RAM é responsável por menos de 11% da
variação no tempo de interpretação.
NCL SMIL
Velocidade de
CPU Quantidade de Memória RAM
Velocidade de CPU
Quantidade de Memória RAM
Vídeo 155% 3,9% 159% 5,5% Áudio 158% 3,3% 154% 3,7% Imagem 168% 6,8% 130% 10,1% Texto 161% 4,1% 150% 7,6% Tabela 6 - Impacto de velocidade de CPU e quantidade de memória RAM em execuções com
tempo de carga
Em suma, para execuções com tempo de carga, a variação da velocidade de CPU
impacta no mínimo 25 vezes e no máximo 48 vezes mais no tempo de interpretação
dos arquivos do que quantidade de memória RAM, em arquivos NCL. Em arquivos
SMIL, o impacto da velocidade de CPU é de 13 a 41 vezes maior que o impacto
causado pela quantidade de memória RAM.
4.4.2 Execuções Sem Tempo de Carga
Bem como ocorrido em execuções com tempo de carga, os resultados obtidos nas
execuções sem tempo de carga levam às mesmas conclusões para todos os tipos de
mídia apresentados: velocidade de CPU tem impacto mais significativo no tempo
médio de interpretação do que quantidade de memória RAM. Desta forma, a Figura
33 e a Figura 34 apresentam os gráficos referentes a arquivos com recursos de vídeo,
porém ilustram o comportamento de todos os tipos mídia (os gráficos com a
comparação de arquivos contendo outros tipos de mídia encontram-se no Apêndice
D).
67
0
100
200
300
400
500600
700
800
900
1000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
Figura 33 - Comparativo do tempo médio sem tempo de carga para os quatro cenários propostos
em arquivos NCL com vídeo
0
2000
4000
6000
8000
10000
12000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
Figura 34 - Comparativo do tempo médio sem tempo de carga para os quatro cenários propostos
em arquivos SMIL com vídeo
Apesar da conclusão de que o impacto da variação da velocidade de CPU é maior que
o impacto da variação de quantidade de memória RAM ser válida para todos os tipos
de mídia, nas execuções sem tempo de carga o impacto da variação destes fatores é
diferente em cada tipo de mídia. A Tabela 7 apresenta a sumarização da diferença
percentual do tempo de interpretação dos arquivos para cada um dos fatores variados,
para ambas as linguagens analisadas e para todos os objetos de mídia apresentados.
Observando-se esta tabela é possível perceber que, ao contrário da execução com
tempo de carga, nas execuções sem tempo de carga o impacto da variação dos fatores
torna-se mais notável para certos tipos de mídia. Em arquivos NCL, por exemplo, o
impacto da variação da velocidade de CPU não passava de 168% e o impacto da
68
variação da quantidade de memória RAM não passava de 6,8% em execuções com
tempo de carga. Em execuções sem tempo de carga, no entanto, esses valores chegam
a 499% e 39,8%, respectivamente. Já para arquivos SMIL, o impacto máximo da
variação na velocidade de CPU subiu de 159% para 202% e o impacto máximo da
variação na quantidade de memória RAM praticamente dobrou, passando de 10,1%
para 20,1%.
NCL SMIL
Velocidade de
CPU Quantidade de Memória RAM
Velocidade de CPU
Quantidade de Memória RAM
Vídeo 138% 14,5% 149% 7,5% Áudio 499% 16,6% 184% 3,9% Imagem 303% 18,7% 141% 20,1% Texto 407% 39,8% 202% 16,8% Tabela 7 - Impacto de velocidade de CPU e quantidade de memória RAM em execuções sem
tempo de carga
Em suma, para execuções sem tempo de carga, a variação da velocidade de CPU
impacta no mínimo 10 vezes e no máximo 30 vezes mais no tempo de interpretação
dos arquivos do que quantidade de memória RAM, em arquivos NCL. Em arquivos
SMIL, o impacto da velocidade de CPU é de 7 a 47 vezes maior que o impacto da
quantidade de memória RAM.
4.4.3 Sumário
Analisados os impactos da variação de velocidade de CPU e quantidade de memória
RAM no tempo de interpretação de arquivos contendo os quatro tipos de mídia
analisados, em execuções com e sem tempo de carga, conclui-se que com os cenários
e cargas utilizados:
• A variação dos fatores é mais impactante, em ambas as linguagens e para
todos os tipos de mídia, em execuções sem tempo de carga.
• A diferença entre o impacto dos dois fatores variados é maior em execuções
com tempo de carga em arquivos NCL. De forma análoga, arquivos SMIL
apresentam maior diferença entre os fatores variados em execuções sem tempo
de carga.
• Arquivos NCL contendo recursos de vídeo apresentam menor sensibilidade à
variação da velocidade de CPU do que arquivos contendo outros tipos de
mídia.
69
• Arquivos SMIL contendo recursos de imagem apresentam maior sensibilidade
à variação da quantidade de memória RAM do que arquivos contendo outros
tipos de mídia. Em contrapartida, apresentam menor sensibilidade à variação
da velocidade de CPU.
70
5 Conclusão e Trabalhos Futuros
A TV digital é uma tecnologia que chega ao Brasil trazendo melhorias na qualidade
de imagem, som, transmissão e recepção, além de introduzir o conceito de
interatividade entre o telespectador e os programas de televisão. Esta interatividade é
possível graças à camada denominada “mediador” presente na arquitetura padrão do
sistema de TV digital. Para ser capaz de prover esta interatividade, entretanto, o
mediador utiliza aplicações escritas em linguagens declarativas. Uma vez que cada
um dos padrões de sistema digital existentes atualmente adota um mediador diferente,
que por sua vez utiliza linguagens declarativas diferentes, é de interesse uma
comparação de desempenho entre estas linguagens. Este capítulo apresenta , na Seção
5.1, as conclusões obtidas através da avaliação experimental das linguagens NCL
Nested Context Language (NCL) e Synchronized Multimedia Integration Language
(SMIL). Na Seção 5.2 são apresentadas algumas direções de pesquisas futuras.
5.1 Conclusão
Este trabalho desenhou experimentos baseados em técnicas estatísticas de projeto
experimental. Através da aplicação destas técnicas sobre os valores coletados nos
diferentes experimentos executados, foi possível chegar aos resultados apresentados
no Capítulo 4. As conclusões obtidas a partir das análises realizadas, considerando-se
os cenários e cargas utilizados, são sumarizadas abaixo:
• Em relação a uso de memória, SMIL é superior a NCL. Enquanto NCL
depende da ação do coletor de lixo¸ SMIL utiliza uma quantidade de memória
praticamente constante durante seguidas execuções.
• Em relação a desempenho, NCL é superior a SMIL. Apesar de o tempo de
interpretação de arquivos NCL ser mais lento durante a execução com tempo
de carga, as execuções seguintes – sem tempo de carga – são mais rápidas em
relação a SMIL. NCL torna-se uma opção ainda melhor à medida que o
número de recursos em um arquivo cresce.
• Em dispositivos com baixo poder de processamento e pequena quantidade de
memória RAM disponível, como PDA’s (Personal Digital Assistant –
Assistente Digital Pessoal), recomenda-se o uso da linguagem NCL. Apesar de
71
em determinados tipos de mídia o impacto da restrição dos fatores
mencionados ser maior em NCL do que em SMIL, esta diferença não é
suficiente para tornar seu desempenho inferior a SMIL. Também nesses
dispositivos, NCL torna-se uma opção ainda melhor à medida que o número
de recursos em um arquivo cresce.
5.2 Trabalhos Futuros
Uma proposição futura consiste em estender a caracterização de cargas de acordo com
a real necessidade das emissoras de TV para o contexto da TV digital e alimentar
projetos exeperimentais.
Outra proposta consiste em desenvolver uma linguagem híbrida e estender a avaliação
para incluí-la. A vantagem de se desenvolver uma linguagem híbrida seria unir em
uma mesma linguagem as vantagens das linguagens analisadas, como por exemplo, o
desempenho de NCL e o uso de memória RAM de SMIL.
Uma nova direção seria o desenvolvimento de um tocador que suporte ambas as
linguagens, porém desenvolvido especificamente para dispositivos móveis. Com isso,
apesar das restrições de velocidade de CPU e quantidade de memória RAM, o novo
tocador utilizaria técnicas e algoritmos específicos de ambientes com restrições de
recursos com o objetivo de melhorar o desempenho da interpretação das linguagens
analisadas.
72
6 Referências Bibliográficas
[1] Advanced Television Systems Committee, Disponível em: <http://www.atsc.org>
[2] Ambulant Player, Disponível em: <http://www.cwi.nl/projects/Ambulant>
[3] Antonacci M. J. “NCL: Uma Linguagem Declarativa para Especificação de Documentos Hipermídia com Sincronização Temporal e Espacial”. Dissertação de Mestrado apresentada ao Departamento de Informática da PUC-Rio, 2000.
[4] ARIB Standard for Digital Broadcasting, Disponível em: <http://www.dibeg.org/aribstd/ARIBSTD.htm>
[5] ATSC Standard A/100: DTV Application Software Environment – Level 1 (DASE-1), Disponível em: <http://www.atsc.org/standards/a100.html>
[6] Becker V., Montez C. “TV Digital Interativa: Conceitos, Desafios e Perspectivas para o Brasil”. Editora da UFSC, 2005.
[7] Costa R.M.R., Rodrigues R.F., Soares L.F.G. “Armazenamento e Distribuição de Documentos NCL através do Padrão MPEG-4”. WebMedia, 2004.
[8] Cronograma da TV Digital no Brasil, Disponível em: <http://www.teleco.com.br/tvdigital_cronog.asp>
[9] Declaração de isentos em 2009 poderá ser feita pela TV digital, Disponível em: <http://www.softwarelivre.gov.br/declaracao-de-isentos-em-2009-podera-ser-feita-pela-tv-digital>
[10] Digital Video Bradcasting Project, Disponível em: <http://www.dvb.org>
[11] Dolby Laboratories, Disponível em: <http://www.dolby.com>
[12] DTV, A TV Digital Brasileira, Disponível em: <http://www.dtv.org.br>
[13] Digital Video Broadcasting (DVB) – Multimedia Home Platform (MHP) Specification 1.0.3, Disponível em: <http://www.dvb.org/technology/standards/index.xml >
[14] Eckstein R., Loy M., Wood D. “Java Swing”. O’Reilly Media, Inc., 2002.
[15] ECMAScript, Disponível em: <http://www.ecmascript.org>
[16] Fonseca M. “TV Digital: Principais Conceitos e Novos Recursos”, UCPEL, 2007, Disponível em: <http://g3pd.ucpel.tche.br/~cs/producao/2007-1/Michelli_Borges_da_Fonseca/TV_Digital_artigo.pdf >
[17] Harte L. “Introduction to MPEG; MPEG-1, MPEG-2 and MPEG-4”. Althos Publishing, 2006.
[18] Hattori L.P., Silva S.S., Tavares T.A., Neto M.C.M, Saibel C. “Utilizando o framework AppTV no desenvolvimento de aplicações para TV Digital Interativa”. SIBGRAPI, 2005.
[19] Hemmlepp P.M., Ferraz C. “Aplicações de TV Digital Sensíveis a Contexto para Dispositivos Móveis”. Trabalho de Gradução em Sistemas Distribuídos UFPE, 2006.
73
[20] Hirayama R.M., Silveira R.M. “Framework para Avaliação do Sincronismo em Aplicações de TV Digital Móvel”. III Fórum de Oportunidades em Televisão Digital Interativa, 2005.
[21] Hobaika M.B.S., Borges R.C. “Radiodifusão e TV Digital no Direito Brasileiro”. Fórum, 2007.
[22] Integrated Systems Digital Broadcasting, Disponível em: <http://www.dibeg.org>
[23] Jain R. “Art of Computer Systems Performance Analysis Techniques for Experimental Design Measurements Simulation and Modeling”. Wiley Computer Publishing, 1991.
[24] Java Media Framework API, Disponível em:
<http://java.sun.com/products/java-media/jmf>
[25] Java Sound API, Disponível em:
<http://java.sun.com/products/java-media/sound>
[26] Java TV API, Disponível em: <http://java.sun.com/products/javatv>
[27] Joly A.V. “Programação Educativa destinada à Televisão Interativa”. Monografia apresentada no Departamento de Artes e Comunicação da Universidade Federal de São Carlos, 2003.
[28] Lozano F. “Resolvendo Problemas de Performance em Java com Software Livre”. Disponível em:
<http://www.lozano.eti.br/palestras/java-performance.pdf>
[29] Neto M.A.M., Oliveira C.T., de Souza C.T. “Uma Arquitetura Distribuída para o Gerenciamento de Informações Sobre Programação em Televisão Digital”. WebMedia, 2005.
[30] Oliveira E.C.R., Albuquerque C.V.N. “TV Digital Interativa: Padrões para uma nova era”. Mini-curso da V Escola Regional de Informática RJ/ES, 2005.
[31] Paes A., Antoniazzi R.H., Saade D.C.M. “Padrões de Middleware para TV Digital”. IV Seminário Fluminense de Engenharia, 2005.
[32] Pihkala K., Cesar P., Vuorimaa P. “Cross-Platform SMIL Player”. IASTED, 2002.
[33] Pihkala K., von Knorring N., Vuorimaa P. “Smil In X-Smiles”. Proceedings of the 7th International Conference on Distributed Multimedia Systems, 2001.
[34] Portal do Software Público Brasileiro, Disponível em: <http://www.softwarepublico.gov.br/spb>
[35] Portaria nº 652 de 10 de Outubro de 2006, Disponível em: <http://www.mc.gov.br/sites/600/695/00001879.pdf >
[36] Radha H., Chen Y., Parthasarathy K., Cohen R. “Scalable Internet video using MPEG-4”. Signal Processing: Image Communication, 1999.
[37] RealPlayer, Disponível em: <http://www.realplayer.com>
[38] Rodrigues A.L., Gomes R.M. “Modulação COFDM - Uma proposta atrativa para os padrões de TV Digital”. Revista Digital Online, 2004.
74
[39] Rodrigues R.F., Soares L.F.G. “Produção de Conteúdo Declarativo para TV Digital”. SEMISH, 2006.
[40] Ross J. “Televisão Analógica e Digital”. Antenna Edições Técnicas, 2007.
[41] Saade D.C.M., Silva H.V., Soares L.F.G. “Linguagem NCL versão 2.0 para Autoria Declarativa de Documentos Hipermídia”. WebMedia, 2003.
[42] Salomon D. “Data Compression: The Complete Reference”. Springer, 1997.
[43] Schulter A., Ribeiro L.A., Becker V., Caetano M.F., Montez C., Melo E., Fröhlich A.A.M. “Um Ambiente de Distribuição de Vídeo MPEG2 com Suporte Multicast em Código Aberto para o Projeto I2TV”. Workshop RNP2, 2003.
[44] Sierra K., Bates B. “Certificação Sun para Programador Java 5”. Alta Books, 2006.
[45] Simioni A., Roesler V. “Um framework para o desenvolvimento de aplicações interativas para a Televisão Digital”. ERRC, 2006.
[46] Sistema Brasileiro de TV Digital, Disponível em: <http://sbtvd.cpqd.com.br>
[47] Soares L.F.G. “Ambiente para Desenvolvimento de Aplicações Declarativas para a TV Digital Brasileira”. MDIC, 2007.
[48] Soares L.F.G., Rodrigues R.F. “Nested Context Model 3.0 Part 5 – NCL (Nested Context Language) Main Profile”. Monografias em Ciência da Computação do Departamento de Informática da PUC-Rio, 2005.
[49] Soares L.F.G., Rodrigues R.F., Costa R.M.R. “Geração Automática de Frameworks para Processamento de Documentos XML”. WebMedia, 2006.
[50] Soares L.F.G., Rodrigues R.F., Moreno M.F. “Ginga-NCL: the Declarative Environment of the Brazilian Digital TV System”. JBCS, 2007.
[51] Sparano D. “What Exactly is 8-VSB Anyway?”. Harris Broadcast, 1997.
[52] TV Digital: Escolha do Padrão para o Brasil, Disponível em: <http://www.teleco.com.br/tvdigital_padraobr.asp>
[53] TV Digital no Brasil, Disponível em: <http://www.teleco.com.br/tvdigital.asp>
[54] Using JConsole to Monitor Applications, Disponível em: <http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html>
[55] Valdestilhas A., Almeida F.A. “A usabilidade no desenvolvimento de aplicações para TV Interativa”. SIBGRAPI, 2005.
[56] Venners B. “Inside The Java Virtual Machine”. McGraw-Hill Companies, 2000
[57] Vieira A.B., Campos S.V.A., Almeida J.M., Guimarães E., Cunha I., Costa C. “EasyPres: An Easy-to-Use Tool for Creating Synchronized Multimedia Presentations”. World Conference on Educational Multimedia, Hypermedia & Telecommunications, 2004.
[58] W3C Document Object Model, Disponível em: <http://www.w3.org/DOM>
[59] World-Wide Web Consortium “Extensible Markup Language (XML) 1.0”. W3C Recommendation, 2006.
[60] World-Wide Web Consortium “HTML 4.01”. W3C Recommendation, 1999.
75
[61] World-Wide Web Consortium “Synchronized Multimedia Integration Language (SMIL 2.1)”. W3C Recommendation, 2005.
[62] World-Wide Web Consortium “The Extensible HyperText Markup Language (Second Edition)”. W3C Recommendation, 2002.
[63] X-Smiles.org, Disponível em: <http://www.xsmiles.org>
[64] Zhao L., Katsavounidis I., Kuo C.-C.J. “Another Example of Software Replacing Hardware: Real-time Software MPEG-2 SDI/HD Encoding for Digital TV Broadcasting”. NAB Broadcast Engineering Conference, 2003.
[65] Zheng J., Miller S.L. “Performance Analysis in COFDM System over Frequency-Selective Fading Channels”. Disponível em: <http://wcl3.tamu.edu/publ/papers/ofdm4.pdf >
76
Apêndice A – Arquivos NCL
Nesta seção são apresentados os arquivos NCL utilizados nos experimentos desta
dissertação. Para cada tipo de mídia, são apresentados os arquivos com 1 e com 20
recursos. O arquivo com 1 recurso é apresentado pois apresenta estrutura mais simples
que os demais arquivos. Os arquivos com 2, 3, 5 e 10 recursos são omitidos pois
podem ser facilmente recriados através da simplificação do arquivo com 20 recursos.
Arquivo contendo 1 vídeo
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoVideo1">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgVideo1"/>
</regionBase>
<descriptorBase>
<descriptor region="rgVideo1" id="dVideo1"/>
</descriptorBase>
</head>
<body>
<media descriptor="dVideo1" src="./media/nist.mpg"
type="video/mpeg" id="video1"/>
<port component="video1" id="pInicio"/>
</body>
</ncl>
Arquivo contendo 20 vídeos
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoVideo20">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
<causalConnector id="composerOnBeginStartDelay">
<simpleCondition role="onBegin"/>
<simpleAction delay="$delay" role="start"/>
<connectorParam value="xs:string" name="delay"/>
</causalConnector>
</connectorBase>
77
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgVideo1"/>
<region left="550" top="100" width="320" height="240"
id="rgVideo2"/>
<region left="100" top="550" width="150" height="150"
id="rgVideo3"/>
<region left="10" top="10" width="150" height="150"
id="rgVideo4"/>
<region left="550" top="550" width="320" height="240"
id="rgVideo5"/>
<region left="900" top="10" width="50" height="50"
id="rgVideo6"/>
<region left="900" top="70" width="50" height="50"
id="rgVideo7"/>
<region left="900" top="130" width="50" height="50"
id="rgVideo8"/>
<region left="900" top="190" width="50" height="50"
id="rgVideo9"/>
<region left="900" top="250" width="50" height="50"
id="rgVideo10"/>
<region left="0" top="10" width="50" height="50"
id="rgVideo11"/>
<region left="0" top="70" width="50" height="50"
id="rgVideo12"/>
<region left="0" top="130" width="50" height="50"
id="rgVideo13"/>
<region left="0" top="190" width="50" height="50"
id="rgVideo14"/>
<region left="0" top="250" width="50" height="50"
id="rgVideo15"/>
<region left="10" top="0" width="50" height="50"
id="rgVideo16"/>
<region left="70" top="0" width="50" height="50"
id="rgVideo17"/>
<region left="130" top="0" width="50" height="50"
id="rgVideo18"/>
<region left="190" top="0" width="50" height="50"
id="rgVideo19"/>
<region left="250" top="0" width="50" height="50"
id="rgVideo20"/>
</regionBase>
<descriptorBase>
<descriptor region="rgVideo1" id="dVideo1"/>
<descriptor region="rgVideo2" id="dVideo2"/>
<descriptor region="rgVideo3" id="dVideo3"/>
<descriptor region="rgVideo4" id="dVideo4"/>
<descriptor region="rgVideo5" id="dVideo5"/>
<descriptor region="rgVideo6" id="dVideo6"/>
<descriptor region="rgVideo7" id="dVideo7"/>
<descriptor region="rgVideo8" id="dVideo8"/>
<descriptor region="rgVideo9" id="dVideo9"/>
<descriptor region="rgVideo10" id="dVideo10"/>
<descriptor region="rgVideo11" id="dVideo11"/>
<descriptor region="rgVideo12" id="dVideo12"/>
<descriptor region="rgVideo13" id="dVideo13"/>
<descriptor region="rgVideo14" id="dVideo14"/>
<descriptor region="rgVideo15" id="dVideo15"/>
<descriptor region="rgVideo16" id="dVideo16"/>
<descriptor region="rgVideo17" id="dVideo17"/>
<descriptor region="rgVideo18" id="dVideo18"/>
78
<descriptor region="rgVideo19" id="dVideo19"/>
<descriptor region="rgVideo20" id="dVideo20"/>
</descriptorBase>
</head>
<body>
<media descriptor="dVideo1" src="./media/nist.mpg"
type="video/mpeg" id="video1"/>
<port component="video1" id="pInicio"/>
<media descriptor="dVideo2" src="./media/coffee.mpg"
type="video/mpeg" id="video2"/>
<media descriptor="dVideo3" src="./media/nist_old.mpg"
type="video/mpeg" id="video3"/>
<media descriptor="dVideo4" src="./media/welcome to
pockettv.mpg" type="video/mpeg" id="video4"/>
<media descriptor="dVideo5" src="./media/BADLUCK.mpg"
type="video/mpeg" id="video5"/>
<media descriptor="dVideo6" src="./media/nist.mpg"
type="video/mpeg" id="video6"/>
<media descriptor="dVideo7" src="./media/coffee.mpg"
type="video/mpeg" id="video7"/>
<media descriptor="dVideo8" src="./media/nist_old.mpg"
type="video/mpeg" id="video8"/>
<media descriptor="dVideo9" src="./media/welcome to
pockettv.mpg" type="video/mpeg" id="video9"/>
<media descriptor="dVideo10" src="./media/BADLUCK.mpg"
type="video/mpeg" id="video10"/>
<media descriptor="dVideo11" src="./media/nist.mpg"
type="video/mpeg" id="video11"/>
<media descriptor="dVideo12" src="./media/coffee.mpg"
type="video/mpeg" id="video12"/>
<media descriptor="dVideo13" src="./media/nist_old.mpg"
type="video/mpeg" id="video13"/>
<media descriptor="dVideo14" src="./media/welcome to
pockettv.mpg" type="video/mpeg" id="video14"/>
<media descriptor="dVideo15" src="./media/BADLUCK.mpg"
type="video/mpeg" id="video15"/>
<media descriptor="dVideo16" src="./media/nist.mpg"
type="video/mpeg" id="video16"/>
<media descriptor="dVideo17" src="./media/coffee.mpg"
type="video/mpeg" id="video17"/>
<media descriptor="dVideo18" src="./media/nist_old.mpg"
type="video/mpeg" id="video18"/>
<media descriptor="dVideo19" src="./media/welcome to
pockettv.mpg" type="video/mpeg" id="video19"/>
<media descriptor="dVideo20" src="./media/BADLUCK.mpg"
type="video/mpeg" id="video20"/>
<link xconnector="composerOnBeginStartDelay" id="link1">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video2"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link2">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video3"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link3">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video4"/>
<linkParam value="0.001s" name="delay"/>
</link>
79
<link xconnector="composerOnBeginStartDelay" id="link4">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video5"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link5">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video6"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link6">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video7"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link7">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video8"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link8">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video9"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link9">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video10"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link10">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video11"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link11">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video12"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link12">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video13"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link13">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video14"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link14">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video15"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link15">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video16"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link16">
80
<bind role="onBegin" component="video1"/>
<bind role="start" component="video17"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link17">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video18"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link18">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video19"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link19">
<bind role="onBegin" component="video1"/>
<bind role="start" component="video20"/>
<linkParam value="0.001s" name="delay"/>
</link>
</body>
</ncl>
Arquivo contendo 1 áudio
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoAudio1">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
</connectorBase>
<regionBase/>
<descriptorBase/>
</head>
<body>
<media src="./media/english.wav" type="audio/basic"
id="Audio1"/>
<port component="Audio1" id="pInicio"/>
</body>
</ncl>
Arquivo contendo 20 áudios
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoAudio20">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
<causalConnector id="composerOnBeginStartDelay">
<simpleCondition role="onBegin"/>
<simpleAction delay="$delay" role="start"/>
81
<connectorParam value="xs:string" name="delay"/>
</causalConnector>
</connectorBase>
<regionBase/>
<descriptorBase/>
</head>
<body>
<media src="./media/english.wav" type="audio/basic"
id="Audio1"/>
<port component="Audio1" id="pInicio"/>
<media src="./media/captions_on.wav" type="audio/basic"
id="Audio2"/>
<media src="./media/wakeup5s.wav" type="audio/basic"
id="Audio3"/>
<media src="./media/germandub.wav" type="audio/basic"
id="Audio4"/>
<media src="./media/audiodesc_off.wav" type="audio/basic"
id="Audio5"/>
<media src="./media/english.wav" type="audio/basic"
id="Audio6"/>
<media src="./media/captions_on.wav" type="audio/basic"
id="Audio7"/>
<media src="./media/wakeup5s.wav" type="audio/basic"
id="Audio8"/>
<media src="./media/germandub.wav" type="audio/basic"
id="Audio9"/>
<media src="./media/audiodesc_off.wav" type="audio/basic"
id="Audio10"/>
<media src="./media/english.wav" type="audio/basic"
id="Audio11"/>
<media src="./media/captions_on.wav" type="audio/basic"
id="Audio12"/>
<media src="./media/wakeup5s.wav" type="audio/basic"
id="Audio13"/>
<media src="./media/germandub.wav" type="audio/basic"
id="Audio14"/>
<media src="./media/audiodesc_off.wav" type="audio/basic"
id="Audio15"/>
<media src="./media/english.wav" type="audio/basic"
id="Audio16"/>
<media src="./media/captions_on.wav" type="audio/basic"
id="Audio17"/>
<media src="./media/wakeup5s.wav" type="audio/basic"
id="Audio18"/>
<media src="./media/germandub.wav" type="audio/basic"
id="Audio19"/>
<media src="./media/audiodesc_off.wav" type="audio/basic"
id="Audio20"/>
<link xconnector="composerOnBeginStartDelay" id="link1">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio2"/>
<linkParam value="5.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link2">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio3"/>
<linkParam value="7.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link3">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio4"/>
82
<linkParam value="12.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link4">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio5"/>
<linkParam value="17.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link5">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio6"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link6">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio7"/>
<linkParam value="5.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link7">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio8"/>
<linkParam value="7.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link8">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio9"/>
<linkParam value="12.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link9">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio10"/>
<linkParam value="17.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link10">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio11"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link11">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio12"/>
<linkParam value="5.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link12">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio13"/>
<linkParam value="7.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link13">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio14"/>
<linkParam value="12.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link14">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio15"/>
<linkParam value="17.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link15">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio16"/>
<linkParam value="0.001s" name="delay"/>
83
</link>
<link xconnector="composerOnBeginStartDelay" id="link16">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio17"/>
<linkParam value="5.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link17">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio18"/>
<linkParam value="7.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link18">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio19"/>
<linkParam value="12.000s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link19">
<bind role="onBegin" component="Audio1"/>
<bind role="start" component="Audio20"/>
<linkParam value="17.000s" name="delay"/>
</link>
</body>
</ncl>
Arquivo contendo 1 imagem
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoImagem1">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgImagem1"/>
</regionBase>
<descriptorBase>
<descriptor region="rgImagem1" id="dImagem1"/>
</descriptorBase>
</head>
<body>
<media descriptor="dImagem1" src="./media/earth.jpg"
type="image/jpeg" id="Imagem1"/>
<port component="Imagem1" id="pInicio"/>
</body>
</ncl>
Arquivo contendo 20 imagens
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoImagem20">
84
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
<causalConnector id="composerOnBeginStartDelay">
<simpleCondition role="onBegin"/>
<simpleAction delay="$delay" role="start"/>
<connectorParam value="xs:string" name="delay"/>
</causalConnector>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgImagem1"/>
<region left="550" top="100" width="320" height="240"
id="rgImagem2"/>
<region left="100" top="550" width="150" height="150"
id="rgImagem3"/>
<region left="10" top="10" width="150" height="150"
id="rgImagem4"/>
<region left="550" top="550" width="320" height="240"
id="rgImagem5"/>
<region left="900" top="10" width="50" height="50"
id="rgImagem6"/>
<region left="900" top="70" width="50" height="50"
id="rgImagem7"/>
<region left="900" top="130" width="50" height="50"
id="rgImagem8"/>
<region left="900" top="190" width="50" height="50"
id="rgImagem9"/>
<region left="900" top="250" width="50" height="50"
id="rgImagem10"/>
<region left="0" top="10" width="50" height="50"
id="rgImagem11"/>
<region left="0" top="70" width="50" height="50"
id="rgImagem12"/>
<region left="0" top="130" width="50" height="50"
id="rgImagem13"/>
<region left="0" top="190" width="50" height="50"
id="rgImagem14"/>
<region left="0" top="250" width="50" height="50"
id="rgImagem15"/>
<region left="10" top="0" width="50" height="50"
id="rgImagem16"/>
<region left="70" top="0" width="50" height="50"
id="rgImagem17"/>
<region left="130" top="0" width="50" height="50"
id="rgImagem18"/>
<region left="190" top="0" width="50" height="50"
id="rgImagem19"/>
<region left="250" top="0" width="50" height="50"
id="rgImagem20"/>
</regionBase>
<descriptorBase>
<descriptor region="rgImagem1" id="dImagem1"/>
<descriptor region="rgImagem2" id="dImagem2"/>
<descriptor region="rgImagem3" id="dImagem3"/>
<descriptor region="rgImagem4" id="dImagem4"/>
<descriptor region="rgImagem5" id="dImagem5"/>
<descriptor region="rgImagem6" id="dImagem6"/>
<descriptor region="rgImagem7" id="dImagem7"/>
<descriptor region="rgImagem8" id="dImagem8"/>
85
<descriptor region="rgImagem9" id="dImagem9"/>
<descriptor region="rgImagem10" id="dImagem10"/>
<descriptor region="rgImagem11" id="dImagem11"/>
<descriptor region="rgImagem12" id="dImagem12"/>
<descriptor region="rgImagem13" id="dImagem13"/>
<descriptor region="rgImagem14" id="dImagem14"/>
<descriptor region="rgImagem15" id="dImagem15"/>
<descriptor region="rgImagem16" id="dImagem16"/>
<descriptor region="rgImagem17" id="dImagem17"/>
<descriptor region="rgImagem18" id="dImagem18"/>
<descriptor region="rgImagem19" id="dImagem19"/>
<descriptor region="rgImagem20" id="dImagem20"/>
</descriptorBase>
</head>
<body>
<media descriptor="dImagem1" src="./media/earth.jpg"
type="image/jpeg" id="Imagem1"/>
<port component="Imagem1" id="pInicio"/>
<media descriptor="dImagem2" src="./media/car.gif"
type="image/gif" id="Imagem2"/>
<media descriptor="dImagem3" src="./media/smile256.png"
type="image/png" id="Imagem3"/>
<media descriptor="dImagem4" src="./media/mickey.jpg"
type="image/jpeg" id="Imagem4"/>
<media descriptor="dImagem5" src="./media/donald_duck.gif"
type="image/gif" id="Imagem5"/>
<media descriptor="dImagem6" src="./media/earth.jpg"
type="image/jpeg" id="Imagem6"/>
<media descriptor="dImagem7" src="./media/car.gif"
type="image/gif" id="Imagem7"/>
<media descriptor="dImagem8" src="./media/smile256.png"
type="image/png" id="Imagem8"/>
<media descriptor="dImagem9" src="./media/mickey.jpg"
type="image/jpeg" id="Imagem9"/>
<media descriptor="dImagem10" src="./media/donald_duck.gif"
type="image/gif" id="Imagem10"/>
<media descriptor="dImagem11" src="./media/earth.jpg"
type="image/jpeg" id="Imagem11"/>
<media descriptor="dImagem12" src="./media/car.gif"
type="image/gif" id="Imagem12"/>
<media descriptor="dImagem13" src="./media/smile256.png"
type="image/png" id="Imagem13"/>
<media descriptor="dImagem14" src="./media/mickey.jpg"
type="image/jpeg" id="Imagem14"/>
<media descriptor="dImagem15" src="./media/donald_duck.gif"
type="image/gif" id="Imagem15"/>
<media descriptor="dImagem16" src="./media/earth.jpg"
type="image/jpeg" id="Imagem16"/>
<media descriptor="dImagem17" src="./media/car.gif"
type="image/gif" id="Imagem17"/>
<media descriptor="dImagem18" src="./media/smile256.png"
type="image/png" id="Imagem18"/>
<media descriptor="dImagem19" src="./media/mickey.jpg"
type="image/jpeg" id="Imagem19"/>
<media descriptor="dImagem20" src="./media/donald_duck.gif"
type="image/gif" id="Imagem20"/>
<link xconnector="composerOnBeginStartDelay" id="link1">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem2"/>
<linkParam value="0.001s" name="delay"/>
</link>
86
<link xconnector="composerOnBeginStartDelay" id="link2">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem3"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link3">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem4"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link4">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem5"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link5">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem6"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link6">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem7"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link7">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem8"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link8">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem9"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link9">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem10"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link10">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem11"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link11">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem12"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link12">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem13"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link13">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem14"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link14">
87
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem15"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link15">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem16"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link16">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem17"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link17">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem18"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link18">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem19"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link19">
<bind role="onBegin" component="Imagem1"/>
<bind role="start" component="Imagem20"/>
<linkParam value="0.001s" name="delay"/>
</link>
</body>
</ncl>
Arquivo contendo 1 texto
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoTexto1">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgTexto1"/>
</regionBase>
<descriptorBase>
<descriptor region="rgTexto1" id="dTexto1"/>
</descriptorBase>
</head>
<body>
<media descriptor="dTexto1" src="./media/texto1.html"
type="text/html" id="Texto1"/>
<port component="Texto1" id="pInicio"/>
</body>
</ncl>
88
Arquivo contendo 20 textos
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
id="documentoTexto20">
<head>
<connectorBase>
<importBase documentURI="composerConnectorBase.conn"
alias="connBase"/>
<causalConnector id="composerOnBeginStartDelay">
<simpleCondition role="onBegin"/>
<simpleAction delay="$delay" role="start"/>
<connectorParam value="xs:string" name="delay"/>
</causalConnector>
</connectorBase>
<regionBase>
<region left="250" top="250" width="320" height="240"
id="rgTexto1"/>
<region left="550" top="100" width="320" height="240"
id="rgTexto2"/>
<region left="100" top="550" width="150" height="150"
id="rgTexto3"/>
<region left="10" top="10" width="150" height="150"
id="rgTexto4"/>
<region left="550" top="550" width="320" height="240"
id="rgTexto5"/>
<region left="900" top="10" width="50" height="50"
id="rgTexto6"/>
<region left="900" top="70" width="50" height="50"
id="rgTexto7"/>
<region left="900" top="130" width="50" height="50"
id="rgTexto8"/>
<region left="900" top="190" width="50" height="50"
id="rgTexto9"/>
<region left="900" top="250" width="50" height="50"
id="rgTexto10"/>
<region left="0" top="10" width="50" height="50"
id="rgTexto11"/>
<region left="0" top="70" width="50" height="50"
id="rgTexto12"/>
<region left="0" top="130" width="50" height="50"
id="rgTexto13"/>
<region left="0" top="190" width="50" height="50"
id="rgTexto14"/>
<region left="0" top="250" width="50" height="50"
id="rgTexto15"/>
<region left="10" top="0" width="50" height="50"
id="rgTexto16"/>
<region left="70" top="0" width="50" height="50"
id="rgTexto17"/>
<region left="130" top="0" width="50" height="50"
id="rgTexto18"/>
<region left="190" top="0" width="50" height="50"
id="rgTexto19"/>
<region left="250" top="0" width="50" height="50"
id="rgTexto20"/>
</regionBase>
<descriptorBase>
89
<descriptor region="rgTexto1" id="dTexto1"/>
<descriptor region="rgTexto2" id="dTexto2"/>
<descriptor region="rgTexto3" id="dTexto3"/>
<descriptor region="rgTexto4" id="dTexto4"/>
<descriptor region="rgTexto5" id="dTexto5"/>
<descriptor region="rgTexto6" id="dTexto6"/>
<descriptor region="rgTexto7" id="dTexto7"/>
<descriptor region="rgTexto8" id="dTexto8"/>
<descriptor region="rgTexto9" id="dTexto9"/>
<descriptor region="rgTexto10" id="dTexto10"/>
<descriptor region="rgTexto11" id="dTexto11"/>
<descriptor region="rgTexto12" id="dTexto12"/>
<descriptor region="rgTexto13" id="dTexto13"/>
<descriptor region="rgTexto14" id="dTexto14"/>
<descriptor region="rgTexto15" id="dTexto15"/>
<descriptor region="rgTexto16" id="dTexto16"/>
<descriptor region="rgTexto17" id="dTexto17"/>
<descriptor region="rgTexto18" id="dTexto18"/>
<descriptor region="rgTexto19" id="dTexto19"/>
<descriptor region="rgTexto20" id="dTexto20"/>
</descriptorBase>
</head>
<body>
<media descriptor="dTexto1" src="./media/texto1.html"
type="text/html" id="Texto1"/>
<port component="Texto1" id="pInicio"/>
<media descriptor="dTexto2" src="./media/texto2.html"
type="text/html" id="Texto2"/>
<media descriptor="dTexto3" src="./media/texto3.html"
type="text/html" id="Texto3"/>
<media descriptor="dTexto4" src="./media/texto4.html"
type="text/html" id="Texto4"/>
<media descriptor="dTexto5" src="./media/texto5.html"
type="text/html" id="Texto5"/>
<media descriptor="dTexto6" src="./media/texto1.html"
type="text/html" id="Texto6"/>
<media descriptor="dTexto7" src="./media/texto2.html"
type="text/html" id="Texto7"/>
<media descriptor="dTexto8" src="./media/texto3.html"
type="text/html" id="Texto8"/>
<media descriptor="dTexto9" src="./media/texto4.html"
type="text/html" id="Texto9"/>
<media descriptor="dTexto10" src="./media/texto5.html"
type="text/html" id="Texto10"/>
<media descriptor="dTexto11" src="./media/texto1.html"
type="text/html" id="Texto11"/>
<media descriptor="dTexto12" src="./media/texto2.html"
type="text/html" id="Texto12"/>
<media descriptor="dTexto13" src="./media/texto3.html"
type="text/html" id="Texto13"/>
<media descriptor="dTexto14" src="./media/texto4.html"
type="text/html" id="Texto14"/>
<media descriptor="dTexto15" src="./media/texto5.html"
type="text/html" id="Texto15"/>
<media descriptor="dTexto16" src="./media/texto1.html"
type="text/html" id="Texto16"/>
<media descriptor="dTexto17" src="./media/texto2.html"
type="text/html" id="Texto17"/>
<media descriptor="dTexto18" src="./media/texto3.html"
type="text/html" id="Texto18"/>
<media descriptor="dTexto19" src="./media/texto4.html"
90
type="text/html" id="Texto19"/>
<media descriptor="dTexto20" src="./media/texto5.html"
type="text/html" id="Texto20"/>
<link xconnector="composerOnBeginStartDelay" id="link1">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto2"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link2">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto3"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link3">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto4"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link4">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto5"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link5">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto6"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link6">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto7"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link7">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto8"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link8">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto9"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link9">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto10"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link10">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto11"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link11">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto12"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link12">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto13"/>
91
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link13">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto14"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link14">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto15"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link15">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto16"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link16">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto17"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link17">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto18"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link18">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto19"/>
<linkParam value="0.001s" name="delay"/>
</link>
<link xconnector="composerOnBeginStartDelay" id="link19">
<bind role="onBegin" component="Texto1"/>
<bind role="start" component="Texto20"/>
<linkParam value="0.001s" name="delay"/>
</link>
</body>
</ncl>
92
Apêndice B – Arquivos SMIL
Nesta seção são apresentados os arquivos SMIL utilizados nos experimentos desta
dissertação. Para cada tipo de mídia é apresentado apenas o arquivo com 20 recursos,
uma vez que os arquivos com 1, 2, 3, 5 e 10 recursos podem ser facilmente recriados
através da simplificação deste.
Arquivo contendo 20 vídeos
<smil xmlns:meta="http://www.w3.org/2005/SMIL21/Language">
<meta:meta name="documentoVideo20"/>
<head>
<layout>
<region left="250" top="250" width="320" height="240"
id="rgVideo1"/>
<region left="550" top="100" width="320" height="240"
id="rgVideo2"/>
<region left="100" top="550" width="150" height="150"
id="rgVideo3"/>
<region left="10" top="10" width="150" height="150"
id="rgVideo4"/>
<region left="550" top="550" width="320" height="240"
id="rgVideo5"/>
<region left="900" top="10" width="50" height="50"
id="rgVideo6"/>
<region left="900" top="70" width="50" height="50"
id="rgVideo7"/>
<region left="900" top="130" width="50" height="50"
id="rgVideo8"/>
<region left="900" top="190" width="50" height="50"
id="rgVideo9"/>
<region left="900" top="250" width="50" height="50"
id="rgVideo10"/>
<region left="0" top="10" width="50" height="50"
id="rgVideo11"/>
<region left="0" top="70" width="50" height="50"
id="rgVideo12"/>
<region left="0" top="130" width="50" height="50"
id="rgVideo13"/>
<region left="0" top="190" width="50" height="50"
id="rgVideo14"/>
<region left="0" top="250" width="50" height="50"
id="rgVideo15"/>
<region left="10" top="0" width="50" height="50"
id="rgVideo16"/>
<region left="70" top="0" width="50" height="50"
id="rgVideo17"/>
<region left="130" top="0" width="50" height="50"
id="rgVideo18"/>
<region left="190" top="0" width="50" height="50"
id="rgVideo19"/>
<region left="250" top="0" width="50" height="50"
id="rgVideo20"/>
</layout>
</head>
<body>
93
<par>
<video src="./media/nist.mpg" region="rgVideo1"/>
<video src="./media/coffee.mpg" region="rgVideo2"/>
<video src="./media/nist_old.mpg" region="rgVideo3"/>
<video src="./media/welcome to pockettv.mpg"
region="rgVideo4"/>
<video src="./media/BADLUCK.mpg" region="rgVideo5"/>
<video src="./media/nist.mpg" region="rgVideo6"/>
<video src="./media/coffee.mpg" region="rgVideo7"/>
<video src="./media/nist_old.mpg" region="rgVideo8"/>
<video src="./media/welcome to pockettv.mpg"
region="rgVideo9"/>
<video src="./media/BADLUCK.mpg" region="rgVideo10"/>
<video src="./media/nist.mpg" region="rgVideo11"/>
<video src="./media/coffee.mpg" region="rgVideo12"/>
<video src="./media/nist_old.mpg" region="rgVideo13"/>
<video src="./media/welcome to pockettv.mpg"
region="rgVideo14"/>
<video src="./media/BADLUCK.mpg" region="rgVideo15"/>
<video src="./media/nist.mpg" region="rgVideo16"/>
<video src="./media/coffee.mpg" region="rgVideo17"/>
<video src="./media/nist_old.mpg" region="rgVideo18"/>
<video src="./media/welcome to pockettv.mpg"
region="rgVideo19"/>
<video src="./media/BADLUCK.mpg" region="rgVideo20"/>
</par>
</body>
</smil>
Arquivo contendo 20 áudios
<smil xmlns:meta="http://www.w3.org/2005/SMIL21/Language">
<meta:meta name="documentoAudio20"/>
<head>
<layout/>
</head>
<body>
<par>
<audio src="./media/english.wav"/>
<audio src="./media/captions_on.wav" begin="5s"/>
<audio src="./media/wakeup5s.wav" begin="7s"/>
<audio src="./media/germandub.wav" begin="12s"/>
<audio src="./media/audiodesc_off.wav" begin="17s"/>
<audio src="./media/english.wav"/>
<audio src="./media/captions_on.wav" begin="5s"/>
<audio src="./media/wakeup5s.wav" begin="7s"/>
<audio src="./media/germandub.wav" begin="12s"/>
<audio src="./media/audiodesc_off.wav" begin="17s"/>
<audio src="./media/english.wav"/>
<audio src="./media/captions_on.wav" begin="5s"/>
<audio src="./media/wakeup5s.wav" begin="7s"/>
<audio src="./media/germandub.wav" begin="12s"/>
<audio src="./media/audiodesc_off.wav" begin="17s"/>
<audio src="./media/english.wav"/>
<audio src="./media/captions_on.wav" begin="5s"/>
<audio src="./media/wakeup5s.wav" begin="7s"/>
<audio src="./media/germandub.wav" begin="12s"/>
<audio src="./media/audiodesc_off.wav" begin="17s"/>
</par>
</body>
</smil>
94
Arquivo contendo 20 imagens
<smil xmlns:meta="http://www.w3.org/2005/SMIL21/Language">
<meta:meta name="documentoImagem20"/>
<head>
<layout>
<region left="250" top="250" width="320" height="240"
id="rgImagem1"/>
<region left="550" top="100" width="320" height="240"
id="rgImagem2"/>
<region left="100" top="550" width="150" height="150"
id="rgImagem3"/>
<region left="10" top="10" width="150" height="150"
id="rgImagem4"/>
<region left="550" top="550" width="320" height="240"
id="rgImagem5"/>
<region left="900" top="10" width="50" height="50"
id="rgImagem6"/>
<region left="900" top="70" width="50" height="50"
id="rgImagem7"/>
<region left="900" top="130" width="50" height="50"
id="rgImagem8"/>
<region left="900" top="190" width="50" height="50"
id="rgImagem9"/>
<region left="900" top="250" width="50" height="50"
id="rgImagem10"/>
<region left="0" top="10" width="50" height="50"
id="rgImagem11"/>
<region left="0" top="70" width="50" height="50"
id="rgImagem12"/>
<region left="0" top="130" width="50" height="50"
id="rgImagem13"/>
<region left="0" top="190" width="50" height="50"
id="rgImagem14"/>
<region left="0" top="250" width="50" height="50"
id="rgImagem15"/>
<region left="10" top="0" width="50" height="50"
id="rgImagem16"/>
<region left="70" top="0" width="50" height="50"
id="rgImagem17"/>
<region left="130" top="0" width="50" height="50"
id="rgImagem18"/>
<region left="190" top="0" width="50" height="50"
id="rgImagem19"/>
<region left="250" top="0" width="50" height="50"
id="rgImagem20"/>
</layout>
</head>
<body>
<par>
<img src="./media/earth.jpg" region="rgImagem1"/>
<img src="./media/car.gif" region="rgImagem2"/>
<img src="./media/smile256.png" region="rgImagem3"/>
<img src="./media/mickey.jpg" region="rgImagem4"/>
<img src="./media/donald_duck.gif" region="rgImagem5"/>
<img src="./media/earth.jpg" region="rgImagem6"/>
<img src="./media/car.gif" region="rgImagem7"/>
<img src="./media/smile256.png" region="rgImagem8"/>
<img src="./media/mickey.jpg" region="rgImagem9"/>
<img src="./media/donald_duck.gif" region="rgImagem10"/>
<img src="./media/earth.jpg" region="rgImagem11"/>
95
<img src="./media/car.gif" region="rgImagem12"/>
<img src="./media/smile256.png" region="rgImagem13"/>
<img src="./media/mickey.jpg" region="rgImagem14"/>
<img src="./media/donald_duck.gif" region="rgImagem15"/>
<img src="./media/earth.jpg" region="rgImagem16"/>
<img src="./media/car.gif" region="rgImagem17"/>
<img src="./media/smile256.png" region="rgImagem18"/>
<img src="./media/mickey.jpg" region="rgImagem19"/>
<img src="./media/donald_duck.gif" region="rgImagem20"/>
</par>
</body>
</smil>
Arquivo contendo 20 textos
<smil xmlns:meta="http://www.w3.org/2005/SMIL21/Language">
<meta:meta name="documentoTexto20"/>
<head>
<layout>
<region left="250" top="250" width="320" height="240"
id="rgTexto1"/>
<region left="550" top="100" width="320" height="240"
id="rgTexto2"/>
<region left="100" top="550" width="150" height="150"
id="rgTexto3"/>
<region left="10" top="10" width="150" height="150"
id="rgTexto4"/>
<region left="550" top="550" width="320" height="240"
id="rgTexto5"/>
<region left="900" top="10" width="50" height="50"
id="rgTexto6"/>
<region left="900" top="70" width="50" height="50"
id="rgTexto7"/>
<region left="900" top="130" width="50" height="50"
id="rgTexto8"/>
<region left="900" top="190" width="50" height="50"
id="rgTexto9"/>
<region left="900" top="250" width="50" height="50"
id="rgTexto10"/>
<region left="0" top="10" width="50" height="50"
id="rgTexto11"/>
<region left="0" top="70" width="50" height="50"
id="rgTexto12"/>
<region left="0" top="130" width="50" height="50"
id="rgTexto13"/>
<region left="0" top="190" width="50" height="50"
id="rgTexto14"/>
<region left="0" top="250" width="50" height="50"
id="rgTexto15"/>
<region left="10" top="0" width="50" height="50"
id="rgTexto16"/>
<region left="70" top="0" width="50" height="50"
id="rgTexto17"/>
<region left="130" top="0" width="50" height="50"
id="rgTexto18"/>
<region left="190" top="0" width="50" height="50"
id="rgTexto19"/>
<region left="250" top="0" width="50" height="50"
id="rgTexto20"/>
</layout>
</head>
96
<body>
<par>
<text src="./media/texto1.html" region="rgTexto1"/>
<text src="./media/texto2.html" region="rgTexto2"/>
<text src="./media/texto3.html" region="rgTexto3"/>
<text src="./media/texto4.html" region="rgTexto4"/>
<text src="./media/texto5.html" region="rgTexto5"/>
<text src="./media/texto1.html" region="rgTexto6"/>
<text src="./media/texto2.html" region="rgTexto7"/>
<text src="./media/texto3.html" region="rgTexto8"/>
<text src="./media/texto4.html" region="rgTexto9"/>
<text src="./media/texto5.html" region="rgTexto10"/>
<text src="./media/texto1.html" region="rgTexto11"/>
<text src="./media/texto2.html" region="rgTexto12"/>
<text src="./media/texto3.html" region="rgTexto13"/>
<text src="./media/texto4.html" region="rgTexto14"/>
<text src="./media/texto5.html" region="rgTexto15"/>
<text src="./media/texto1.html" region="rgTexto16"/>
<text src="./media/texto2.html" region="rgTexto17"/>
<text src="./media/texto3.html" region="rgTexto18"/>
<text src="./media/texto4.html" region="rgTexto19"/>
<text src="./media/texto5.html" region="rgTexto20"/>
</par>
</body>
</smil>
97
Apêndice C – Execuções Com Tempo de
Carga
A figura abaixo apresenta os tempos médios e intervalos de confiança para arquivos
com recursos de áudio e foi omitida da Seção 4.2.1 pois apresenta resultados similares
a arquivos contendo recursos de vídeo.
10
100
1000
10000
1 2 3 5 10 20
Número de Áudios Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL
SMIL
A figura abaixo apresenta os tempos médios e intervalos de confiança para arquivos
com recursos de texto e foi omitida da Seção 4.2.1 pois apresenta resultados similares
a arquivos contendo recursos de imagem.
10
100
1000
10000
1 2 3 5 10 20
Número de Textos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL
SMIL
98
As figura abaixo apresentam os tempos médios e intervalos de confiança para os
quatro cenários de velocidade de CPU e quantidade de memória RAM propostos. As
figuras em questão foram omitidas da Seção 4.4.1 pois apresentam resultados
similares a arquivos contendo recursos de vídeo.
Áudio
NCL
0
500
1000
1500
2000
25003000
3500
4000
4500
5000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
SMIL
0
2000
4000
6000
8000
10000
12000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
99
Imagem
NCL
0
1000
2000
3000
4000
5000
6000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
SMIL
0
200
400
600
800
1000
1200
1400
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
100
Texto
NCL
0
1000
2000
3000
4000
5000
6000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
SMIL
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
101
Apêndice D – Execuções Sem Tempo de
Carga
As figura abaixo apresentam os tempos médios e intervalos de confiança para
arquivos com recursos de áudio, imagem e texto, respectivamente. As figuras em
questão foram omitidas da Seção 4.3.1 pois apresentam resultados similares a
arquivos contendo recursos de vídeo.
Áudio
1
10
100
1000
10000
1 2 3 5 10 20
Número de Áudios Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL
SMIL
Imagem
10
100
1000
10000
1 2 3 5 10 20
Número de Imagens Incluídas
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL
SMIL
102
Texto
10
100
1000
10000
1 2 3 5 10 20
Número de Textos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
NCL
SMIL
As figura abaixo apresentam os tempos médios e intervalos de confiança para os
quatro cenários de velocidade de CPU e quantidade de memória RAM propostos. As
figuras em questão foram omitidas da Seção 4.4.2 pois apresentam resultados
similares a arquivos contendo recursos de vídeo.
Áudio
NCL
0
50
100
150
200
250
300
350
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
103
SMIL
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
Imagem
NCL
0
100
200
300
400
500
600
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
SMIL
0
200
400
600
800
1000
1200
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
104
Texto
NCL
0
200
400
600
800
1000
1200
1400
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
SMIL
0
500
1000
1500
2000
2500
1 2 3 5 10 20
Número de Recursos Incluídos
Tem
po
Méd
io d
e In
terp
reta
ção
(M
ilis
seg
un
do
s)
1.533 MHz x 1.256 MB
1.533 MHz x 256 MB
504 MHz x 1.256 MB
504 MHz x 256 MB
