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

Marco Beckmann1, Tiago H. Trojahn2, Juliano L. Gonçalves1, Luciano V. Agostini1, Leomar S. Da Rosa Junior1, Lisane Brisolara1

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

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

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ão-

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

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

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.

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

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

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

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

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

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

4. 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 9.10. 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:20 2500 848x480

Space 60 3:06 2500 848x480

STS116 67 3:31 2500 848x480

Taxi 52.2 2:42 2500 848x480

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:20 5000 1280x720

Space 115 3:06 5000 1280x720

STS116 129 3:31 5000 1280x720

Taxi 100 2:42 5000 1280x720

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:20 10000 1920x1080

Space 226 3:06 10000 1920x1080

STS116 253 3:31 10000 1920x1080

Taxi 196 2:42 10000 1920x1080

Os vídeos foram codificados de fontes 1080p usando o codificador x264 [X264,

2010] na versão 1376. 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.

• 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

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.

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.

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.

Referências

Adobe - Adobe Flash HD Gallery, diponível em:

http://www.adobe.com/products/hdvideo/hdgallery. Acesso em: janeiro de 2011.

ATSC - Advanced Television Systems Committee, diponível em: http://www.atsc.org.

acesso em: janeiro de 2011.

Decreto 4901, disponível em: http://www.planalto.gov.br/ccivil_03/decreto/

2003/d4901.htm. Acesso em: janeiro de 2011. 2003.

Decreto 5820, disponível em: http://www.planalto.gov.br/ccivil_03/_Ato2004-

2006/2006/Decreto/D5820.htm. Acesso em: dezembro de 2010.

DVB - Digital Video Broadcasting, diponível em: http://www.dvb.org. acesso em:

março de 2011.

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, 47-

-56 (2007).

Filho, S.M., et al.: FLEXCM - A Component Model for Adaptive Embedded Systems.

In: 31st IEEE International Computer Software and Applications Conference,

pp.119—126. IEEE Press, New York (2007).

Ginga-J, diponível em: http http://gingacdn.lavid.ufpb.br/. Acesso em: dezembro de

2010.

Intel - Intel Core 2 Duo Processor E6320, http://ark.intel.com/Product.aspx?id=29754.

Acesso em: dezembro de 2010.

ISDT - Integrated Services Digital Broadcasting Terrestrial, diponível em: http://

http://www.dibeg.org/. Acesso em: março de 2011.

Java DTV API 1.0, diponível em: http://java.sun.com/javame/technology/javatv. Acesso

em: janeiro de 2011.

JMF 1.0 Programmers guide, diponível em:

http://java.sun.com/javase/technologies/desktop/media/jmf/1.0/guide. Acesso em:

janeiro de 2011.

JNI - Java Native Interface: diponível em:

http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/intro.html. Acesso em: janeiro de

2011.

libVLC, diponível em: http://wiki.videolan.org/Libvlc. Acesso em: janeiro de 2011.

NASA High Definition Video, diponível em: http://www.nasa.gov/multimedia/hd.

acesso em: janeiro de 2011.

Oliveira, B. Um estudo de caso entre GingaJ e GingaNCL no âmbito de aplicações

interativas residentes, diponível em:

http://www.brunodeoliveira.com.br/pdf/Monografia_BrunoDias%20v.2.0.pdf.

Acesso em: janeiro de 2011.

SBTVD – Sistema Brasileiro de TV Digital, disponível em: http://sbtvd.cpqd.com.br/.

Acesso em: janeiro de 2011.

SET - A comparative study of Digital TV standards,

http://www.set.com.br/artigos/testing.pdf. 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, 37--46 (2007).

WMV HD Content Showcase, diponível em:

http://www.microsoft.com/windows/windowsmedia/musicandvideo/hdvideo/content

showcase.aspx. Acesso em: janeiro de 2011.

X264, diponível em: http://www.videolan.org/developers/x264.html. Acesso em:

dezembro de 2010.