Desenvolvimento e Validação de Componente Decodificador de Vídeo para o Middleware Ginga

Transcrição

1 Desenvolvimento e Validação de Componente Decodificador de Vídeo para o Middleware Ginga Marco Beckmann 1, Tiago H. Trojahn 2, Juliano L. Gonçalves 1, Luciano V. Agostini 1, Leomar S. Da Rosa Junior 1, Lisane Brisolara 1 1 Universidade Federal de Pelotas, Centro de Desenvolvimento Tecnológico, Grupo de Arquitetura e Circuitos Integrados, Pelotas, Rio Grande do Sul, Brasil. {mbeckmann, juliano, agostini, leomarjr, lisane }@inf.ufpel.edu.br 2 Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação, São Carlos, São Paulo, Brasil. ttrojahn@icmc.usp.br Abstract. The Brazilian middleware for Digital TV, known as Ginga, is currently divided in two subsystems: the declarative, named Ginga Nested Context Language (Ginga-NCL), and the procedural Ginga-Java (Ginga-J). In this context, there is an effort to create a unique reference implementation of the Ginga middleware, composed by the Ginga-NCL and the Ginga-J environments in a common core named Ginga Common Core (GingaCC), reaching a full and modular version of the middleware. The Media Processing, one of the main components of the GingaCC, is responsible to handle video, audio and subtitles. This work presents an implementation of the Media Processing using the libvlc library and an evaluation of the efficiency of the component. Moreover, a graphical application for video reproduction developed reusing the Media Processing implementation is also presented. Resumo. O middleware brasileiro para a TV Digital, chamado Ginga, está atualmente dividido em dois subsistemas: o declarativo, conhecido como Ginga Nested Context Language (GingaNCL) e o procedural GingaJ. Neste contexto, existe um esforço de desenvolvimento para criar uma implementação única de referência do middleware Ginga, composta dos ambientes GingaNCL e o GingaJ em um núcleo comum, chamado de Ginga Common Core (GingaCC), almejando uma versão completa e modular do middleware. O controle de fluxos de vídeo, áudio e legenda no middleware é responsabilidade do componente Media Processing, um dos principais módulos do GingaCC. Neste trabalho é apresentada uma implementação do Media Processing usando a biblioteca libvlc, além da avaliação da eficiência do componente. Será apresentada, ainda, uma aplicação gráfica para reprodução de vídeo, desenvolvida reusando o componente Media Processing.

2 1. Introdução Em 2003, o decreto 4901 [Decreto 4901,2003] criou o Sistema Brasileiro de TV Digital (SBTVD) [SBTVD, 2011] para incentivar o desenvolvimento de um padrão nacional para TV Digital e Interativa. Em 2000 foi publicado um estudo [SET, 2000] que avaliou os padrões americano, Advanced Television System Committee (ATSC) [ATSC, 2011], europeu, Digital Video Broadcasting Terrestrial (DVB-T) [DVB, 2011)] e o japonês Integrated Services Digital Broadcasting Terrestrial (ISDB-T) [ISDB, 2011] com o intuito de descobrir qual o padrão que melhor se adaptava às necessidades brasileiras. Em 2006, o decreto 5820 [Decreto 5820, 2004] definiu o padrão japonês como padrãobase para o SBTVD, pois demonstrava uma melhor eficiência das transmissões para antenas internas e a possibilidade de acessar o sinal digital com dispositivos portáteis, característica destacada no estudo original [SET, 2000]. O novo padrão do SBTVD define ainda, três importantes diferenças sobre o padrão-base: Adoção do padrão de codificação de vídeo H.264/AVC (Advanced Video Coding). O ISDB-T usa o padrão MPEG-2 Part 2 (conhecido como H.262). Taxa de quadros por segundo (FPS, Frame Rate per Second) de 30 quadros, inclusive para dispositivos móveis. O padrão japonês usa 15 quadros/segundo para dispositivos móveis. Uso de interatividade, ausente no padrão japonês. Além da definição do padrão, um middleware é requerido para facilitar o desenvolvimento de aplicações para o Sistema Brasileiro de TV Digital. Duas soluções distintas, uma procedural, o GingaJ [Filho; Leite; Batista, 2007] suportando aplicativos escritos em Java, e outra declarativa, o GingaNCL [Soares; Rodrigues;Moreno, 2007], suportando aplicativos escritos na linguagem Nested Context Language (NCL), foram propostas. Comparando as duas abordagens o desenvolvimento de uma aplicação para o GingaJ é mais simples e rápido, devido ao fato de Java ser uma linguagem bem disseminada no meio profissional e acadêmico. Outra vantagem é o uso da orientação a objetos e também de não haver necessidade de se integrar com nenhuma outra linguagem, ao contrario do que acontece em uma aplicação implementada em NCL- Lua. Já o GingaNCL tem como vantagem a integração entre a linguagem C e Lua, podendo se trabalhar com um nível de abstração mais baixo, sendo mais adequado a aplicações que necessitem de processamento em larga escala. Isso porque Lua é linguagem mais rápida e leve em comparação a Java que, tendo o paradigma de orientação a objetos e um nível de abstração alto, requer um processamento maior [Oliveira, 2010]. Um desenvolvedor não pode escrever aplicações em NCL e rodá-las no abiente GingaJ, assim como também não é possível a execução de aplicativos Java no ambiente GingaNCL, o que exige que os dois middlewares diferentes tenham de ser instalados e usados de forma isolada.

3 Com o objetivo de criar um núcleo de execução comum entre essas duas abordagens, foi criado o Ginga Common Core (GingaCC) que oferece suporte tanto para o GingaNCL e o GingaJ, ambiente declarativo e procedural do middleware Ginga respectivamente. A interligação entre o GingaCC, GingaJ e o GingaNCL é representada na Figura 1. O GingaCC será composto de diversos componentes e o seu desenvolvimento foi distribuído entre 13 universidades brasileiras coordenadas pela Universidade Federal da Paraíba (UFPB) em um projeto chamado Ginga Code Development Network (GingaCDN), sendo que o GingaCC é o atual objetivo do projeto. Cada universidade é responsável pelo desenvolvimento de um conjunto de componentes do núcleo, criando uma rede distribuída e colaborativa de desenvolvimento de softwares para a TV Digital. Figura 1. O middleware Ginga proposto pelo projeto GingaCDN. Esse trabalho tem como foco o desenvolvimento de um componente decodificador de mídias, chamado Media Processing, e seu reuso para a criação de um player de vídeo. O Media Processing é um dos principais componentes do GingaCC, sendo responsável pela decodificação da mídia, tarefa fundamental em qualquer sistema televisivo já que está diretamente relacionada à exibição de vídeo. Este artigo está organizado da seguinte forma: A Seção 2 apresenta uma visão geral da arquitetura do middleware Ginga e seus componentes, incluindo a apresentação do componente Media Processing. Na Seção 3 é detalhada a implementação do componente Media Processing desenvolvido para decodificação de vídeo. A Seção 4 faz avaliações da eficiência do componente para diferentes vídeos e a Seção 5 descreve o reuso do componente Media Processing no desenvolvimento de um player de vídeo. A seção 6 conclui o trabalho e aponta direções para trabalhos futuros. 2. O middleware Ginga e seus componentes 2.1. O middleware Ginga O middleware Ginga é dividido entre três subsistemas, o declarativo GingaNCL, o procedural GingaJ e o provedor de métodos básicos, o GingaCC. Todas as aplicações criadas para o Ginga têm de utilizar o GingaNCL e/ou o GingaJ, não sendo possível o uso dos métodos do GingaCC diretamente. O GingaNCL é um subsistema que provê suporte para aplicações escritas na linguagem declarativa NCL. Este oferece uma grande gama de métodos para controlar o

4 fluxo multimídia e hipermídia, provendo facilidades para sincronismo espaço-temporal. Os componentes principais do GingaNCL são o NCL Formatter, responsável por decodificar fluxos de entrada, o motor LUA, o interpretador de scripts escritos na linguagem LUA, o componente que provê suporte pra o XHTML e o interpretador de estilo CSS (Cascading Style Sheets). O GingaJ é um subsistema que provê suporte à aplicações escritas na linguagem procedural Java, desenvolvida pela Sun Microsystems. Este subsistema suporta o pacote JavaDTV [JavaDTV, 2011], uma implementação adaptada do pacote JavaTV mas sem problemas de royalties. Uma das implementações de referência deste sistema é o OpenGinga atualmente chamado de GingaJ e disponível em [GingaJ, 2010]. Ambos os ambientes usam os recursos providas pelo GingaCC, sendo o mesmo responsável por prover métodos fundamentais para o middleware, como a sintonização de canais, a exibição de mídias, controle gráfico e controle do canal de retorno. A comunicação entre o GingaNCL e o GingaJ com o GingaCC está sendo feita através da Java Native Interface (JNI) [JNI, 2011]. A JNI é um padrão de interface que permite a comunicação entre programas nativos e programas escritos em Java. Desta maneira, os métodos básicos implementados no GingaCC podem ser chamados por aplicações escritas tanto para o GingaNCL, como para o GingaJ. O Media Processing, detalhado na seção 2.2, é um dos componentes do GingaCC, podendo ser usado tanto pelo ambiente declarativo quanto pelo procedural O componente Media Processing O componente Media Processing é um dos principais componentes do GingaCC diretamente envolvido na renderização e exibição de fluxos de vídeo. Para realizar esta tarefa, o Media Processing interage com os componentes Tuner, Information Service, Demux e Graphics. O componente Tuner é responsável por sintonizar os canais e capturar o fluxo de transporte ou stream, o conjunto formado por áudio, vídeo e outras informações transmitidas em um determinado canal. A saída do Tuner é enviada ao Information Service, que por sua vez, analisa o stream, obtendo algumas informações e adicionando dados essenciais para a reprodução. O Demux é responsável por demultiplexar o fluxo de entrada que compõe o fluxo de transporte usando os dados obtidos pelo componente Information Service. A saída do Demux é enviada ao Media Processing, que decodifica o fluxo recebido, que pode ser composto de vídeos, áudios e legendas, e envia sua saída para o componente Graphics, último componente envolvido diretamente na exibição de vídeos. Finalmente, o Graphics faz o controle e a exibição da mídia decodificada. A Figura 2 ilustra as conexões diretas entre os componentes Media Processing, Demux e Graphics, assim como as interfaces providas pelos mesmos. Vários métodos providos pela interface do Demux são utilizados pelo Media Processing no processo de decodificação, como o getvideostream, que retorna o descritor do fluxo de vídeo para ser decodificado. O vídeo decodificado pelo Media Processing é enviado ao componente Graphics para que seja exibido na tela.

5 Figura 2. Interconexões entre os componentes Media Processing, Demux e Graphics. 3. Implementação do Media Processing A implementação do Media Processing segue a Java Media Framework (JMF) versão 1.0 [JMF, 2011]. A JMF é uma API que especifica uma arquitetura para sincronizar e controlar áudio, vídeo e outras estruturas baseadas em tempo, como legendas. A versão 1.0 especifica a reprodução de mídias. A versão atual da implementação do Media Processing é capaz de suportar fluxos de vídeo e legendas, não provendo suporte à streams de áudio. Uma descrição de alto nível de suas funcionalidades está descrita abaixo: Alocação de recursos e controle do fluxo de mídia. Recebimento e decodificação de fluxos mídia em diversos formatos. Carregamento, seleção e exibição de legendas. Captura de tela. Prover várias informações sobre o vídeo, como a duração total, tempo de reprodução atual, resolução e taxa de quadros por segundo. Suporte a transmissões de vídeo usando os protocolos Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), User Datagram Protocol (UDP) e Real-Time Transfer Protocol (RTP). O componente Media Processing apresentado neste trabalho foi desenvolvido na linguagem C++ usando a biblioteca libvlc [LivVLC, 2011] detalhada na seção 3.1. Para ser integrado com os outros componentes, o modelo de componente utilizado foi o FlexCM [Filho, 2007], apresentado na seção A biblioteca libvlc LibVLC é uma biblioteca gráfica implementada na linguagem C e desenvolvida pela VideoLAN sob a licença GNU General Public License (GPL) versão 2. Esta biblioteca é compatível com vários formatos de mídia, inclusive o padrão H.264/AVC, o padrão de áudio MPEG Layer 3 e Advanced Audio Coded (AAC) e suporta diversos sistemas

6 gráficos, como DirectX, OpenGL, X11, XVideo, SDL e Frame Buffer. Estas características aliadas a sua portabilidade com uma grande variedade de sistemas operacionais (Microsoft Windows, GNU Linux, Mac OS, BeOS e FreeBSD) e ao seu alto desempenho, justificaram a escolha por esta biblioteca para implementar o Media Processing. A versão da biblioteca usada no desenvolvimento do Media Processing é a de número A partir da versão 1.0, a biblioteca funciona através de camadas crescentes de abstração de classes. As duas camadas de mais alto nível, libvlc_media_player e libvlc_media, provêm métodos para controlar a reprodução de mídias. A libvlc_media_player provê métodos para controlar a reprodução e também retornar informações relativas à ela, além de métodos auxiliares, como o de adicionar legendas ao fluxo em execução. Já a camada libvlc_media provê métodos de mais baixo nível que permitem controlar a mídia em si, como o descritor, e algumas operações básicas sobre a mídia, como o cálculo da duração total. Esta camada é separada em libvlc_video e libvlc_audio, as classes de menor nível de abstração, responsáveis por controlar diretamente os fluxos de vídeo e áudio, respectivamente. Algumas das principais funcionalidades do Media Processing e seus relacionamentos com as classes libvlc_media_player e libvlc_media estão ilustradas na Figura 3. Figura 3. Componente Media Processing, as classes libvlc_media_player e a libvlc_media e alguns dos métodos implementados O modelo de componentes FlexCM O modelo de componente chamado de FlexCM [Filho, 2007], está sendo usado em todos os componentes do projeto GingaCDN. Um componente que se utilizar do FlexCM deve especificar uma interface provida a outros componentes e também as interfaces requeridas para que possa operar, sendo que a tarefa de realizar eventuais conexões é realizada pelo FlexCM, em tempo de execução. Cada implementação deve, ainda, especificar dois arquivos: Architecture: Arquivo onde serão colocados dados essenciais para a execução do componente, como o caminho para a biblioteca dinâmica de cada componente necessário e um identificador único para cada componente. Registry: Especifica as conexões utilizadas pelo componente através do uso de um identificador único provido em cada interface.

7 Essa metodologia auxilia o desenvolvimento distribuído e, também, garante um processo de integração mais rápido e eficiente. A versão do modelo de componente FlexCM utilizada na implementação do Media Processing foi a de número Resultados Experimentais A implementação do Media Processing foi submetida a um conjunto de testes com o objetivo de avaliar o componente em termos de taxa de uso de processador e de custo de memória. O computador utilizado é equipado com um processador Intel Core 2 Duo 6320 [Intel, 2010], 2 Gigabytes (GB) de memória RAM e executando o sistema operacional Ubuntu O GNU GCC foi utilizado para compilação do componente Media Processing, sem ser utilizada qualquer das otimizações disponíveis para a referida arquitetura. As amostras foram obtidas de segundo em segundo ao se executar o vídeo especificado, por um tempo total de três minutos, sendo repetido o teste três vezes, perfazendo um total de 540 amostras para cada vídeo. Os resultados incluem os valores relativos ao carregamento do modelo de componente FlexCM, as alocações dos objetos da biblioteca libvlc, o processo de multiplexação padrão e a renderização do resultado através de um módulo X11 disponibilizado pela biblioteca libvlc. Nos experimentos foram usados quatro vídeos progressivos (p) em três diferentes resoluções, o 848x480 (480p), conhecido como definição padrão (Standard Definition, SD) e o 1280x720 (720p) e 1920x1080 (1080p), conhecidos como de alta definição (High Definition, HD). O vídeo STS116 foi obtido de [Nasa, 2011], o Taxi3 French, nomeado de Taxi, foi obtido de [WVM, 2011] e o Saguaro National Park, chamado de Park, e o Space Alone, chamado de Space, estão disponíveis em [Adobe, 2011]. Os detalhes dos vídeos são apresentados na Tabela 1 (vídeos 480p), Tabela 2 (vídeos 720p) e na Tabela 3 (vídeos 1080p). Todos os vídeos possuem uma proporção de tela (aspect ratio) de 16:9 e utilizam-se do contêiner MP4. Tabela 1. Detalhes para o conjunto de vídeos 480p. Nome do Vídeo Tamanho (MB) Duração (M:ss) Vídeo Bitrate (Kbps) Resolução (Pixel x Pixel) Park 103 5: x480 Space 60 3: x480 STS : x480 Taxi : x480

8 Tabela 2. Detalhes para o conjunto de vídeos 720p. Nome do Vídeo Tamanho (MB) Duração (M:ss) Vídeo Bitrate (Kbps) Resolução (Pixel x Pixel) Park 198 5: x720 Space 115 3: x720 STS : x720 Taxi 100 2: x720 Tabela 3. Detalhes para o conjunto de vídeos 1080p. Nome do Vídeo Tamanho (MB) Duração (M:ss) Vídeo Bitrate (Kbps) Resolução (Pixel x Pixel) Park 390 5: x1080 Space 226 3: x1080 STS : x1080 Taxi 196 2: x1080 Os vídeos foram codificados de fontes 1080p usando o codificador x264 [X264, 2010] na versão O H.264 High Profile e o AVC nível 5.1 foram utilizados com uma taxa de bits constante para cada resolução. A taxa de quadros por segundo de todos os vídeos foram convertidos para 30 FPS. Alguns dos detalhes da codificação estão listadas abaixo, elas são o padrão do High Profile e do codificador x264 com AVC nível 5.1: Codificador de Entropia CABAC (Context-adaptive binary arithmetic coding). Filtro de Deblocagem ativado, strength e threshold com valor 0. Estimação de Movimento Fracionária com hexagonal algorithm de tamanho 16x16 pixels, para as camadas de luminância e crominância, usando RDO (Rate-Distortion-Optimization) para os quadros I e P [X264, 2010]. Transformada DCT (Discrete Cosine Transform) adaptável usando I4x4, I8x8, P8x8 e B8x8.

9 Três B-Frames com bias igual a 0. Procura rápida por B-Frames adaptáveis e B-Pyramid desativado. Três quadros (frames) de referência com Adaptive I-Frame Decision ativado. Espaço de cores YCbCr 4:2:0. A porcentagem média de uso de processador para o conjunto de testes está representada na Figura 4, onde observamos uma variação de 100,78% de uso de processador e entre os vídeos com resolução de 480p e 720p e de 58,60% entre os vídeos de 720p e 1080p. Na Figura 5 é ilustrada a quantidade média de memória requerida para executar os diferentes vídeos com o Media Processing, que obteve uma variação de 28,41% comparando os vídeos com resolução de 480p e 720p e de 44,24% entre os vídeos de 720p e 1080p. Figura 4. Porcentagem de uso do processador pelo Media Processing Figura 5. Uso de memória, em Megabytes, requeridas pelo Media Processing. Com essa avaliação conclui-se que o crescimento de uso de memória é proporcional ao crescimento da qualidade do vídeo, mas a variação no uso de processador foi grande, chegando a mais que dobrar o uso de processador entre dois vídeos de qualidades próximas (480p e 720p). Além disso, observa-se que no vídeo de 1080p o uso de processador foi de 92,80% da capacidade total, para um processador de

10 propósito geral de dois núcleos de processamento. Com isso conclui-se que o Media Processing requer que o middleware Ginga tenha um processador de alto desempenho para a execução de vídeos em qualidade superior, mas em contrapartida não necessita de uma grande quantidade de memória RAM, dentro dos padrões atuais de hardware de um computador. O desempenho demonstrado pelo componente poderá ser melhorado com o desenvolvimento em hardware de um decodificador de vídeo para o formato H.264/AVC, aumentando o desempenho geral do processo do middleware. Na próxima seção será demonstrado que o uso do componente desenvolvido não se restringe apenas ao seu uso no middleware, podendo ser reaproveitado para o desenvolvimento de aplicações que necessitem de recursos para manipulação de vídeo e áudio. 5. Reuso do componente no desenvolvimento de um player A partir dos métodos fornecidos pelo componente Media Processing foi desenvolvido um aplicativo gráfico para reprodução de vídeo. Além da funcionalidade de reprodução de vídeo, o aplicativo fornece outras funcionalidades relacionadas com a manipulação de mídias e de legendas. Para implementar estas funcionalidades, são usados métodos providos pelo componente Media Processing. A Figura 6 ilustra o diagrama de casos de uso desta aplicação, no qual podem ser observadas as funcionalidades atendidas pelo player. Para o controle da reprodução de vídeos, o aplicativo possui cinco funcionalidades básicas: Reproduzir vídeo, Pausar vídeo, Parar vídeo, Carregar vídeo local e Carregar vídeo pela Web, que estão representadas no diagrama. O caso de uso Reproduzir vídeo realiza a decodificação do vídeo, o que implica em colocar o reprodutor no estado play e uma precondição para a execução deste caso de uso é que o player deve estar no estado stop ou pause. Além disso, antes de reproduzir o vídeo este deve ser carregado. O vídeo a ser carregado pode estar localmente armazenado ou estar disponível na web, os casos de uso Carregar vídeo local e Carregar vídeo da Web representam estas modalidades de carga. Na carga de vídeo local, o usuário indica a localização do arquivo referente à mídia (unidade de disco e caminho para a pasta). No caso da carga de vídeo da web, a localização do vídeo na internet deve ser informada pelo usuário. Se outro vídeo estiver sendo reproduzido, antes da carga será executado o caso de uso Parar vídeo, que desaloca os recursos para que um novo vídeo possa ser carregado. O usuário também pode pausar a reprodução, esta funcionalidade está representada pelo caso de uso Pausar vídeo, coloca o reprodutor no estado de pause, e uma precondição para sua execução é que o player esteja no estado de play. O aplicativo permite também adicionar uma legenda, bem como selecionar a legenda a ser usada durante a reprodução (casos de usos Adicionar legenda e Selecionar legenda na Figura 6). No caso de uso Adicionar legenda, uma nova legenda é adicionada ao vídeo atualmente alocado. As legendas devem ser compatíveis com o suporte dado pela libvlc sendo que esta suporta uma série de formatos, como o básico SubRip (SRT), o Advanced Substation Alpha (ASS), e o SBTVD Standard Subtitle Format. No caso de uso Selecionar legenda, o usuário escolhe uma legenda específica para ser reproduzida junto ao vídeo. Uma precondição para a execução deste último caso de uso é que haja um vídeo alocado pelo player e uma legenda carregada.

11 O player desenvolvido também permite que o usuário obtenha algumas informações sobre o vídeo e capture uma tela do vídeo. Dois casos de uso representam a funcionalidade de visualização das informações do vídeo, são eles: Ver informações do vídeo e Ver informações gerais. No caso de uso Ver informações do vídeo são providas informações sobre a taxa de frames por segundo (FPS), o tempo atual do frame corrente em microssegundos e as dimensões do vídeo (altura e largura do vídeo), além da duração total do vídeo alocado, quando possível já que algumas transmissões pela internet e transmissões pela TV não provém essa informação. O usuário pode também solicitar informações adicionais do vídeo e esta funcionalidade está representada pelo caso de uso Ver Informações gerais, que provê uma série de informações como nome do arquivo, artista, álbum, etc. Por fim, o usuário pode solicitar a captura de uma tela, funcionalidade representada pelo caso de uso Capturar tela, que retira uma screenshot do frame atual mostrado pelo player. O arquivo criado utiliza a compressão com poucas perdas fornecida pelo formato Joint Photographic Expert Group (JPEG). Uma precondição para a execução do Capturar tela é que o player esteja no estado de Play ou Pause. O aplicativo em funcionamento é ilustrado na Figura 7. Figura 6. Diagrama de casos de uso UML do player de vídeo.

12 Figura 7. Imagem do aplicativo em funcionamento. Este player de vídeo, foi implementado na linguagem C++, usando o sistema para o desenvolvimento de programas de interface gráfica Qt na versão 4. O player foi executado usando sistema operacional Ubuntu 9.10, sendo o FlexCM responsável por fazer a conexão entre o aplicativo reprodutor de vídeo e o componente Media Processing. 6. Conclusão e Trabalhos Futuros O presente trabalho apresentou uma implementação do componente Media Processing para o middleware Ginga. Esta implementação faz uso da biblioteca libvlc e os resultados dos experimentos mostram que o Media Processing requer um elevado custo de processador, principalmente para vídeos de alta definição, mas em contrapartida pouca quantidade de memória RAM, considerando os padrões atuais. Com a conclusão do desenvolvimento do Media Processing será feito o processo de integração com os demais componentes disponibilizando um midlleware único que permita ao desenvolvedor escolher entre o ambiente declarativo ou procedural, para a criação de suas aplicações. Também foi apresentado o desenvolvimento de um player utilizando-se do componente desenvolvido para o middleware Ginga. Isso demonstra que o componente pode ser reusado no desenvolvimento de aplicações para TV digital que necessitem da manipulação de vídeo e áudio. Quanto aos trabalhos futuros será necessário adicionar ao componente Media Processing, suporte a áudio e algumas outras funcionalidades relacionadas tais como controle de volume e o seletor de stream de áudio. Além disso, pretende-se a realização de comparações de desempenho com outra implementação do componente Media Processing para o SBTVD e a implementação de outras aplicações reusando o componente apresentado neste trabalho.

13 Referências Adobe - Adobe Flash HD Gallery, diponível em: Acesso em: janeiro de ATSC - Advanced Television Systems Committee, diponível em: acesso em: janeiro de Decreto 4901, disponível em: /d4901.htm. Acesso em: janeiro de Decreto 5820, disponível em: Acesso em: dezembro de DVB - Digital Video Broadcasting, diponível em: acesso em: março de Filho, G. L. S., Leite, L. E. C., Batista, C. E. C. F.: GingaJ: The Procedural Middleware for the Brazilian Digital TV System. J. of the Brazilian Computer Society vol.12, (2007). Filho, S.M., et al.: FLEXCM - A Component Model for Adaptive Embedded Systems. In: 31st IEEE International Computer Software and Applications Conference, pp IEEE Press, New York (2007). Ginga-J, diponível em: http Acesso em: dezembro de Intel - Intel Core 2 Duo Processor E6320, Acesso em: dezembro de ISDT - Integrated Services Digital Broadcasting Terrestrial, diponível em: Acesso em: março de Java DTV API 1.0, diponível em: Acesso em: janeiro de JMF 1.0 Programmers guide, diponível em: Acesso em: janeiro de JNI - Java Native Interface: diponível em: Acesso em: janeiro de libvlc, diponível em: Acesso em: janeiro de NASA High Definition Video, diponível em: acesso em: janeiro de Oliveira, B. Um estudo de caso entre GingaJ e GingaNCL no âmbito de aplicações interativas residentes, diponível em: Acesso em: janeiro de SBTVD Sistema Brasileiro de TV Digital, disponível em: Acesso em: janeiro de 2011.

14 SET - A comparative study of Digital TV standards, Acesso em: janeiro de 2011 Soares, L. F. G., Rodrigues, R. F., Moreno, M. F.: GingaNCL: the declarative environment of the Brazilian Digital TV System. J. of the Brazilian Computer Society vol.1, (2007). WMV HD Content Showcase, diponível em: showcase.aspx. Acesso em: janeiro de X264, diponível em: Acesso em: dezembro de 2010.