Daniel Augusto de Andrade Sacramento. Um Estudo de Desempenho Entre Linguagens Declarativas para TV Digital

Transcrição

1 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

2 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.

3 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.

4 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.

5 Sumário 1 Introdução Motivação Objetivos Contribuições Organização Domínio de Estudo Componentes da TV Digital Difusor Meios de Difusão Receptor Novidades da TV Digital Tecnologias Utilizadas na TV Digital Aplicativos Compressão Mediador Nested Context Language (NCL) Synchronized Multimedia Integration Language (SMIL) Transporte Modulação Principais Sistemas de TV Digital ATSC (Advanced Television System Committee) DVB (Digital Video Broadcasting) ISDB (Integrated Services Digital Broadcasting) SBTVD (Sistema Brasileiro de TV Digital)...27 III

6 3 Metodologia de Avaliação Cargas Projeto Experimental Testes em Observações Pareadas Observações Não Pareadas Ambiente e Ferramental Cenários de Avaliação Tocador X-Smiles Tocador Ginga X-Smiles Limitações Resultados Experimentais Utilização de Memória RAM Execuções Com Tempo de Carga Desempenho Relativo entre NCL e SMIL Impacto do Tipo de Mídia Sumário Execuções Sem Tempo de Carga Desempenho Relativo entre NCL e SMIL Impacto do Tipo de Mídia Sumário Impacto da Variação de Velocidade de CPU e Quantidade Memória RAM Execuções Com Tempo de Carga Execuções Sem Tempo de Carga Sumário Conclusão e Trabalhos Futuros...70 IV

7 5.1 Conclusão Trabalhos Futuros 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 V

8 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 VI

9 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 VII

10 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 VIII

11 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 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 1

12 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 2

13 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. 3

14 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. 4

15 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 5

16 experimental. O Capítulo 5 apresenta um resumo conclusivo desse trabalho e propostas de trabalhos futuros. 6

17 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 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. 7

18 Figura 2 - Modelo do sistema de TV digital 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 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]. 8

19 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 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; 9

20 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 10

21 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. 11

22 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. 12

23 Figura 5 - Tecnologias utilizadas em cada camada da arquitetura de um sistema de TV digital 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 13

24 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 evitase 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, 14

25 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 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 15

26 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], 16

27 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 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 17

28 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 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 18

29 (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 <?xml version="1.0" encoding="iso "?> <ncl xsi:schemalocation=" xmlns:xsi=" xmlns=" 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"/> </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 19

30 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 20

31 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 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 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. 21

32 <smil xmlns:meta=" <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 22

33 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 23

34 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 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 multiplexar 1 á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 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. 24

35 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 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. 25

36 Figura 9 - Tecnologias adotadas pelo padrão ATSC 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 26

37 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 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. 27

38 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 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

39 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. 29

40 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. 30

41 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 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 31

42 (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 Considerado nos Tempo Medido (ms) Experimentos (ms) # # # # # 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. 32

43 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. 33

44 Nº de Classes Carregadas Ginga X-Smiles Iniciado Acesso à opção "File/Open" 1ª Execução do Arquivo 2ª Execução do Arquivo NCL SMIL Etapa 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 milissegundos, em SMIL a diferença é de apenas 453 milissegundos Milissegundos NCL SMIL 0 # 1 # 2 Execução Figura 14 -Tempos referentes à execuções com e sem tempo de carga para NCL e SMIL 34

45 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 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 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 35

46 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 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 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 Cenários de Avaliação Os experimentos mencionados na Seção 3.2 foram executados em um PC AMD- Athlon XP (1.533 MHz), 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 Este computador estava isolado, ou seja, não encontrava- 36

47 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 MHz e 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 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 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 37

48 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 valores referentes ao tempo de CPU gasto para interpretação dos arquivos. Linguagem Número de Objetos de Velocidade de Quantidade Elementos Mídia CPU (MHz) de Memória RAM (MB) NCL 1 Vídeo SMIL 2 Áudio Imagem 5 Texto Tabela 2 - Fatores variados nos experimentos 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 38

49 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. 39

50 Figura 15 - Arquitetura interna do navegador X-Smiles Tocador Ginga X-Smiles Utilizando-se da arquitetura baseada em componentes do aplicativo X-Smiles, criouse 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. 40

51 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; 41