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.
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.
Top Related