Ginga-NCL em Dispositivos Portteis:

Uma Implementao para a Plataforma Android

Guilherme Daher Ferreira
daher@inf.ufes.br
Fbio Fabris
ffabris@inf.ufes.br

Guilherme Nogueira
guilherme@inf.ufes.br
Magnos Martinello
magnos@inf.ufes.br

Giovanni Comarela
gcomarela@inf.ufes.br
Jos Gonalves P. Filho
zegonc@inf.ufes.br

Departamento de Informtica - LPRM

Universidade Federal do Esprito Santo - UFES
Av. Fernando Ferrari, 514, 29060-970 - Vitria/ES, Brasil

ABSTRACT

General Terms

Recently, there has been in Brazil a few number of devices capable

of receiving the digital television signal. However, these devices
lack the Brazilian Digital Television Systems middleware, named
Ginga, and therefore they do not allow the execution of interactive multimedia content. This paper reports an implementation of
Ginga-NCL for Googles Android platform. In order to validate the
implementation, experiments were conducted to analyze the execution of NCL applications, as well as the usage of devices resources.
Moreover, the developed environment allows to evaluate the transmission and reception of NCL applications through the standardized DSM-CC over IP protocol.

Design, Standardization, Languages

Keywords
Ginga, Middleware, SBTVD, Android OS, TV Digital, DTV

1.

INTRODUO

O acesso ao contedo televisivo interativo a partir de dispositivos

portteis multifuncionais, como celulares e smartphones, uma das
grandes apostas para o crescimento da TV digital aberta no Brasil.
Hoje j existem no pas diversos fabricantes de dispositivos portteis, tais como a Samsung e LG, cujos aparelhos permitem a recepo do sinal de TV digital. No entanto, estes dispositivos no esto
equipados com o Ginga [16, 6], software nacional adotado como
padro de middleware pelo Sistema Brasileiro de Televiso Digital
- SBTVD. O Ginga, em suas duas modalidades, uma declarativa,
o Ginga-NCL [16], e outra imperativa, o Ginga-J [6], fornece uma
srie de facilidades para a construo e a execuo de aplicaes
interativas em ambiente de TV digital aberta. Desta forma, os dispositivos portteis disponveis no mercado brasileiro, embora se
aproveitem da qualidade superior de udio e vdeo inerente s tecnologias digitais, no suportam a interatividade. Logo, existe uma
demanda natural por implementaes do middleware Ginga voltadas para terminais portteis.
No cenrio de mobilidade, a escolha do sistema operacional embarcado no dispositivo porttil, assim como de suas plataformas
de desenvolvimento associadas, tornam-se questes proeminentes
no processo de desenvolvimento de novas implementaes Ginga.
Uma primeira iniciativa acadmica de desenvolvimento do GingaNCL para dispositivos mveis, foi realizada na PUC-RJ [7], tendo
como plataforma base o sistema operacional Symbian [14].
A plataforma Android foi lanada em 2008 pelo Google, atravs
do consrcio Open Handset Alliance [3]. Trata-se de uma plataforma de cdigo aberto, no vinculada a apenas um fabricante, fato
este que tem permitido a ampliao da restrita rea de telefonia
mvel. O Android consiste em um sistema operacional baseado no
kernel Linux 2.6 e prov uma Application Programming Interface
(API) na linguagem Java cujas aplicaes desenvolvidas so compiladas para a mquina virtual Dalvik. Esta mquina virtual foi
projetada especialmente para a plataforma Android, sendo otimizada para rodar em dispositivos portteis. Para os desenvolvedores,
h um Software Development Kit (SDK) disponvel gratuitamente
e j existe uma ampla gama de aparelhos com Android embarcado.
Este trabalho apresenta uma implementao do middleware Ginga-

RESUMO
Hoje j existem no Brasil aparelhos que permitem a recepo do
sinal de TV digital. No entanto, estes dispositivos no esto equipados com o Ginga, middleware adotado pelo Sistema Brasileiro
de Televiso Digital - SBTVD, o que inviabiliza a execuo de
contedo multimdia interativo. Este trabalho descreve uma implementao do Ginga-NCL para dispositivos portteis baseados
no sistema operacional Android. Como meio de validar a implementao, foram conduzidos experimentos para analisar a execuo de aplicaes NCL, bem como o uso de recursos do dispositivo
porttil. Alm disso, o ambiente desenvolvido permite avaliar a
transmisso e recepo de aplicaes NCL por meio do protocolo
padronizado DSM-CC sobre IP.

Categories and Subject Descriptors

I.7.2 [Document Preparation]: Languages and systems, Hypertext/Hypermedia, Markup languages, Standards.
Ginga-NCL for Portable Devices: An Implementation for the Android Platform

43

NCL para dispositivos portteis, tendo como sistema operacional

embarcado o Google Android. Um estudo experimental foi realizado para avaliar a sensibilidade de aplicaes NCL [15] e o
desempenho do middleware desenvolvido, incluindo o atraso decorrente da preparao dos players considerando aplicaes contendo um nmero elevado de mdias simultneas, e a utilizao de
CPU e memria durante a execuo de aplicaes NCL com caractersticas distintas. O ambiente de testes empregado permite experimentar aplicaes multimdia escritas na linguagem NCL, extraindo medidas de interesse. No caso da transmisso e recepo
de contedo, foi implementado o protocolo DSM-CC (Digital Storage Media Command and Control) [11] sobre IP, permitindo efetuar testes preliminares da capacidade de recepo do dispositivo
porttil empregado.
As demais sees do artigo esto organizadas da seguinte forma:
Seo 2 discute os trabalhos relacionados. A seo 3 descreve a
arquitetura do middleware Ginga-NCL e os detalhes da implementao realizada no sistema Android. Seo 4 contempla o estudo
experimental realizado com vistas avaliao sistmica do prottipo desenvolvido. Por fim, a seo 5 conclui o artigo apresentando
as consideraes finais e as perspectivas de trabalhos futuros.

2.

dispositivos portteis. O Ginga-NCL, parte declarativa do middleware, possui o profile Basic DTV, utilizado para dispositivos
portteis, especificado em [2]. Alm de utilizado no padro brasileiro de TV digital, o Ginga-NCL padronizado atravs da recomendao H.761 do ITU-T [12] como middleware para aplicaes
multimdia em IPTV, provendo interoperabilidade e harmonizao
entre os distintos frameworks para desenvolvimento destas aplicaes.
No trabalho [7], foi apresentada uma implementao do middleware Ginga para dispositivos portteis baseados no sistema operacional Symbian. Trata-se da primeira implementao de referncia do Ginga-NCL para dispositivos portteis e, como tal, possui
uma descrio estendida sobre o padro e trabalhos relacionados. O
artigo tem seu foco na descrio da arquitetura e na implementao
do middleware, no apresentando testes experimentais sobre a plataforma desenvolvida. Na poca de desenvolvimento do trabalho
no existiam plataformas abertas amplamente disponveis, como
o caso do sistema Android, motivo pelo qual, apesar de ressaltar a
vantagem de se utilizar uma plataforma aberta e livre, escolheu-se
o sistema fechado Symbian1 para desenvolvimento.
O presente trabalho distingue-se dos anteriores ao apresentar no
apenas uma implementao do Ginga-NCL em sistema Android,
mas tambm efetuando um conjunto de experimentos realizados
sobre a plataforma, complementando as discusses iniciadas em
[7], particularmente por meio de uma anlise aprofundada da execuo de aplicaes NCL em dispositivos portteis.

TRABALHOS RELACIONADOS

Prover televiso digital para dispositivos mveis um objetivo

comum em qualquer sistema de televiso digital. Para atingir tal
objetivo alguns padres foram propostos e implementados. O foco
desta seo voltado para descrever brevemente alguns destes padres.
O Digital Video Broadcasting (DVB) o padro europeu para
televiso digital e define o Digital Video Broadcasting - Handheld
(DVB-H) [9], como padro de transmisso da TV Digital para os
dispositivos portteis. O DVB-H uma extenso do padro para
transmisso terrestre DVB-T, voltado apenas para transmisso. No
entanto, os diferentes provedores de contedo nos pases que o adotam, disponibilizam middleware para aparelhos compatveis.
Digital Multimedia Broadcasting (DMB) [8] uma tecnologia
de transmisso desenvolvida pela Coria do Sul como parte do projeto nacional de tecnologia de informao para transmisses de TV,
rdio e dados para dispositivos portteis. Este sistema oferece suporte para operao via satlite (S-DMB) ou terrestre (T-DMB). O
transporte foi implementado com o uso do MPEG-2 TS [10] e seu
middleware de carcter procedural baseado no Java Micro Edition
(JME).
A Association of Radio Industries and Businesses (ARIB) responsvel pela padronizao do sistema de televiso digital japons,
o Integrated Services Digital Broadcasting Terrestrial (ISDB-T).
Este padro permite a transmisso de contedo para dispositivos
portteis atravs do one-seg. Na transmisso digital do ISDB-T,
cada canal dividido em 13 segmentos, dos quais 12 so utilizados
para transmisso aos dispositivos fixos, capazes de exibir contedo
de alta qualidade, e 1 segmento utilizado para transmisso aos dispositivos portteis, o que nomeia esta forma de transmisso como
one-seg. O middleware de TV Digital do ISDB-T baseado na
linguagem Broadcast Markup Language (BML), que de natureza
declarativa e baseada em XHTML1.0 [4].
O Sistema Brasileiro de Televiso Digital (SBTVD) tem como
base o ISDB-T e conhecido mundialmente como ISDB-T International. Esta nomenclatura deve-se a um processo de harmonizao de padres definido pelo Digital Broadcasting Experts Group
(DiBEG), rgo do ARIB que promove o padro ISDB-T.
A principal diferena entre os padres japons (ISDB-T) e o brasileiro (ISDB-T International) a especificao do middleware brasileiro, denominado Ginga, tanto para set-top-boxes quanto para

3.

MIDDLEWARE DECLARATIVO GINGANCL EM ANDROID: ARQUITETURA E

IMPLEMENTAO

O universo das aplicaes Ginga pode ser classificado como um

conjunto composto por aplicaes declarativas e aplicaes procedurais. Aplicaes declarativas so tratadas pelo subsistema GingaNCL e aplicaes procedurais pelo subsistema Ginga-J. De acordo
com as normas NBR-15606-4 e NBR-15606-5 [2, 1] definidas para
o Sistema Brasileiro de Televiso Digital (SBTVD), dentre os dois
subsistemas, apenas o declarativo obrigatrio para dispositivos
portteis.
Este trabalho concentra-se no desenvolvimento do middleware
declarativo Ginga-NCL, o que habilita a execuo de aplicaes
NCL em dispositivos portteis equipados especificamente com o
sistema operacional Android. Inicialmente uma breve introduo
arquitetura conceitual do Ginga apresentada, seguida de uma
descrio mais detalhada dos componentes arquiteturais que foram
implementados ou alterados nesta primeira verso do Ginga-NCL
para Android.

3.1

Arquitetura

Do ponto de vista conceitual, o middleware uma camada na

arquitetura que prov servios para a camada de aplicao. No
caso do Ginga-NCL, este middleware responsvel pela execuo
das aplicaes NCL e, considerando o sistema Android, conforme
mostrado na Figura 1(a), est posicionado sobre o arcabouo (framework) de desenvolvimento.
A Figura 1(b) ilustra a sua componentizao, na qual pode-se ver
a diviso em dois subsistemas [7]: a mquina de apresentao NCL
e o ncleo Ginga.
Na arquitetura do Ginga-NCL para Android, assim como para
1
A verso utilizada foi a Symbian 9.2, parte do Symbian Series1.
Esta a ltima srie de cdigo fechado do sistema Symbian. As
sries seguintes, lanadas a partir de 2009, possuem cdigo livre
aberto em licena EPL - Eclipse Public License

44

tre a Mquina de Apresentao e a API de decodificao de contedo dos exibidores, sendo que para cada exibidor existe um adaptador associado. Ainda como os Exibidores, os Adaptadores seguem uma padronizao de interface.
O Gerenciador Grfico realiza o controle da renderizao dos
objetos especificados na aplicao NCL, definindo as dimenses
e posicionamento destes objetos. O Gerenciador de Atualizaes, possui como principal caracterstica receber e instalar atualizaes de maneira independente sem interromper o funcionamento
do middleware, e o Gerenciador de Contexto, responsvel por
gerenciar o perfil de usurio e demais informaes contextuais.
No subsistema da mquina de apresentao, o principal componente o Formatador e seu papel consiste em direcionar todas
as aes a serem executadas. Inicialmente o Formatador solicita
ao Conversor que processe a aplicao NCL. O resultado desta
converso uma rvore de execuo denominada Base Privada. A
gerncia de todas as bases presentes no middleware feita pelo
componente Gerenciador de Bases Privadas.
Aps receber esta estrutura de dados, o Formatador dispara a
execuo do Escalonador, cuja responsabilidade gerir a execuo
e temporizao das mdias presentes na aplicao NCL. O Escalonador atribui ao Gerenciador de Exibidores o processamento dos
recursos necessrios para exibio de cada mdia e ao componente
Gerenciador de Layout a responsabilidade de definir os parmetros de exibio NCL no dispositivo.

NCL Applications
Android Applications
GINGA-NCL
0.10 cDisplay Driver

Activity
Manager

Content
Provider

Package
Manager

Location
Manager

Window
Manager

View
System

Resource
Manager

Notification
Manager

Surface
Manager

Media
Framework

OpenGL | ES

Libc

SGL

SSL

WebKit

FreeType

Display Driver

Camera Driver

Flash Memory
Driver

Blinder Driver

Keypad Driver

Wifi Driver

Audio Driver

Power
Management

Dalvik VM

Core Libraries

(a) Camada Ginga-NCL sobre Android

Mquina de Apresentao Ginga NCL
Conversor

Gerenciador de
Bases Privadas

Formatador

Escalonador

Gerenciador
de Layout
Gerenciador
de Contexto

Ncleo Ginga
Processador
de Dados

3.2

Gerenciador
Exibidores

Adaptadores
Gerenciador de Contexto

Gerenciador de
Atualizaes

Persistncia

Mquina Lua

Sintonizador

Transporte

Gerenciador
Grco

Exibidores

API Android
Bibliotecas de Sistema

Implementao

Para a implementao do Ginga-NCL em Android, partiu-se da

implementao pblica em Java para set-top box. No entanto, uma
srie de modificaes foram efetuadas, principalmente nos mtodos relacionados ao gerenciamento e manipulao dos elementos
grficos (vdeo, pginas HTML e imagens) e udio.
Os componentes que tiveram de ser implementados ou alterados
encontram-se com fundo escuro e fonte clara na Figura 1(b) e os
que permaneceram inalterados em fundo claro com fonte preta.
No foi possvel utilizar diretamente a implementao pblica,
pois ela faz uso de recursos de bibliotecas grficas no suportadas
no dispositivo porttil (tais como AWT e Swing). A parte do cdigo que no utiliza estas bibliotecas precisou de poucas modificaes devido natureza portvel da plataforma de desenvolvimento
Java/Dalvik. A implementao resultante capaz de executar aplicaes NCL declarativas em dispositivos portteis de maneira satisfatria conforme apresentado na seo 4.
importante salientar que os dispositivos disponveis baseados
no sistema Android no possuem ainda o hardware necessrio para
receber contedo transmitido via radiodifuso. Por estes motivos,
a implementao atual ainda no possui um mdulo Sintonizador
funcional. Alm disso, o mdulo Processador de Dados encontrase num estado inicial em que foi implementado um cliente para o
protocolo DSM-CC, cuja descrio encontra-se na seo 4.3.
As prximas sees apresentam detalhes das classes que foram
implementadas nesta primeira verso do Ginga-NCL em Android.

Dalvik VM

Kernel Linux

(b) Viso dos Componentes Ginga-NCL

Figure 1: Arquitetura Ginga NCL para dispositivos portteis

set-top-boxes, o ncleo Ginga responsvel por prover recursos

necessrios mquina de apresentao NCL. Seu componente Sintonizador tem o papel de receber contedo de TVD para dispositivos portteis (1-seg) transmitido por provedores de contedo.
As aplicaes interativas podem chegar ao dispositivo de dois modos: multiplexadas no contedo recebido pelo Sintonizador, ou por
outra interface de rede presente no dispositivo. Quando a aplicao estiver multiplexada, ela obtida atravs de um processamento
efetuado pelo mdulo Processador de Dados sobre o contedo recebido. O componente Transporte definido para gerenciar protocolos e interfaces de rede, para o caso em que a aplicao for
recebida por este meio. Aps o recebimento destas aplicaes e do
contedo referenciado por elas, o mdulo Persistncia atua para
gerenciar o seu armazenamento.
O componente Exibidores responsvel pelos decodificadores
especficos para cada tipo de mdia. Por outro lado, o componente
Adaptadores responsvel pela padronizao da comunicao en-

3.2.1

Formatador

A classe Formatter atua como um gerenciador em alto nvel,

sendo responsvel pelo controle das aplicaes NCL presentes no
middleware. este gerenciador o responsvel por receber uma
aplicao NCL, convert-la para uma Base Privada, armazen-la
e iniciar sua execuo, alm de repassar comandos para pausar e
reiniciar uma aplicao.
A instanciao inicial da classe ocorre na Activity principal do
Middleware, a classe GingaMobile. A classe mantm uma referncia ao Formatador e, ao receber uma aplicao NCL, realiza as

45

chamadas para adicionar a aplicao e para iniciar a exibio. Os

botes de controle para pausar e parar a aplicao possuem eventos
que realizam as chamadas aos respectivos mtodos do Formatador
para a ao escolhida.
O processo de adio de uma aplicao ao Formatador feito
atravs da classe NclDocumentManager. O Formatador faz uma
chamada ao mtodo addDocument desta classe, que realiza as seguintes aes: compilar a aplicao NCL para gerar uma Base Privada, adicionar a Base Privada a um mapa de bases e retornar a
Base Privada para o Formatador.
Para iniciar a exibio de uma aplicao NCL, o Formatador realiza uma navegao pela Base Privada da aplicao para criar uma
lista de eventos de entrada, ou seja, os eventos iniciais da aplicao.
Esta lista enviada ao Escalonador que, a partir destes eventos iniciais, poder iniciar a execuo da aplicao.

3.2.2

Analogamente, a classe updateUI utilizada para alterar o layout

principal, adicionando e removendo elementos do tipo AndroidWindow adicionados listas internas atravs dos mtodos addRemoveTask, addDisplayTask, addLayout e addClearTask.

3.2.4

Gerenciador de Bases Privadas

O mdulo Bases Privadas tem como principal funo armazenar

a estrutura processada pelo Formatador NCL, responsvel por tratar
as aplicaes recebidas pelo ncleo.
A principal classe deste mdulo, Entity, estende a interface IEntity. Todas as classes deste mdulo (ns, links, descritores, etc)
devem implementar essa interface, considerando que cada entidade
NCL/NCM tem como atributo um nico Identificador (ID).
A rea funcional Layout especifica elementos e atributos que definem como os objetos sero inicialmente apresentados dentro de
regies de dispositivos de sada. Components define os tipos bsicos de objetos de mdia, e tambm responsvel pela definio de
ns de contexto atravs de elementos <context>. A rea funcional
Interfaces permite a definio de interfaces de ns (objetos de mdia ou ns de composio) que sero utilizadas em relacionamentos
com outras interfaces de ns. Por sua vez, Linking responsvel
por definir os elos, que utilizam conectores. Alm dos mdulos
bsicos, a rea funcional Connectors tambm define mdulos que
agrupam conjuntos de mdulos bsicos para facilitar a definio do
perfil de linguagem. O NCL permite uma grande reutilizao de
seus elementos; para tal, a rea funcional Reuse tambm foi implementada. Animation , na verdade, uma combinao de fatores de
suporte ao desenho do objeto e de suporte ao movimento do objeto ou, mais propriamente, suporte para a alterao do objeto em
funo do tempo. Por fim, Metainformation contm informaes
sobre o contedo utilizado ou exibido. Para a implementao destas classes foram seguidos os padres definidos em [13].

3.2.3

Gerenciador de Exibidores

O mdulo Gerenciador de Exibidores compreende as classes necessrias ao gerenciamento da execuo dos exibidores de mdias e
de interao com usurio.
Pode-se destacar nesta implementao a interface AndroidSurface, responsvel por definir uma superfcie de exibio de mdia.
importante destacar que cada mdia executada numa aplicao
NCL tem uma superfcie de exibio a ela associada. Cada tipo
de mdia requer superfcies com caractersticas diferentes. Para tal,
a API Android prov classes distintas para exibio destas mdias.
So elas: ImageView, SurfaceView e WebView. Estas classes so
utilizadas como base para as superfcies de apresentao do middleware. A fim de realizar a interface entre o middleware e as
bibliotecas nativas da API, foram implementadas a AndroidAudioSurface, AndroidHTMLSurface, AndroidVideoSurface e a
AndroidImageSurface.
Uma outra classe importante a AndroidWindow. Sua funo prover uma abstrao da janela de trabalho do middleware,
para tal, foi utilizada como base a classe de layout de exibio da
API LinearLayout e a interface NCL IWindow. Em suma, todos
os elementos exibidos pelo middleware esto contidos numa AndroidWindow.
Por fim, tem-se a classe GingaKeyListener, responsvel por receber os dados de interao do usurio via teclado. Esta recebe os
eventos e repassa-os para as classes necessrias para realizar a ao
pretendida. Esta classe implementa a interface OnKeyListener, provida pela API Android, que chamada sempre que um evento
enviado para uma respectiva View.

3.2.5

Gerenciador de Grfico

Para realizar o papel do Gerenciador Grfico do middleware Ginga,

foi implementada a classe InterfaceUpdater. Sua funo bsica
gerenciar a exibio e remoo de superfcies (Surfaces) na tela e,
portanto, necessita alterar o layout principal do middleware. Entretanto, a plataforma Android no permite que todas as classes
pertencentes a uma aplicao alterem o layout principal; apenas a
Activity inicial pode faz-lo.
De modo a contornar esta limitao da plataforma, a classe foi
implementada utilizando um Handler, uma classe da API Android
que permite executar uma thread com as permisses da Activity inicial, e duas classes internas que implementam a interface Runnable, updateUI e changeImage. A classe changeImage utilizada
para a troca de uma imagem exibida na tela e, como a exibio
feita atravs da classe ImageView, o mtodo changeView da classe
InterfaceUpdater utilizado. Neste mtodo, um vetor contendo
a View a ser removida e a View a ser exibida adicionado a uma
lista de vetores a ser lida pela thread changeImage quando esta
executada.

46

Exibidores

No mdulo exibidores temos os apresentadores de mdia definidos para cada tipo suportado pelo middleware. Eles so utilizados
pelos adaptadores para inserir as mdias numa apresentao e definem as funes bsicas de apresentao necessrias, como: start,
pause, abort, resume e stop. O comportamento destas funes
definido por norma, sendo que buscou-se, na implementao deste
middleware, seguir exatamente as instrues contidas no captulo
8.2 em [13].
O mdulo foi implementado de forma que tem-se uma classe
correspondente ao exibidor para cada adaptador, por exemplo, AndroidAudioPlayer e AndroidAudioPlayerAdapter, esto relacionados.

3.2.6

Adaptadores

Os adaptadores atuam como intermedirios entre o formatador e

os exibidores respectivos a cada tipo de mdia, de forma que existe
uma relao um para um entre eles. Cabe ressaltar que tanto os
adaptadores de mdia quanto os de cdigo procedural implementam as interfaces de adaptador e listener de eventos. Desta forma,
o adaptador recebe uma chamada de execuo de uma mdia e carrega o exibidor necessrio e, ao captar um evento, repassa-o a este
exibidor para que este realize uma ao baseada neste evento.
Para implementao do mdulo Adaptadores foi necessrio estender as interfaces NCL IFormaterPlayerAdapter e IProceduralPlayerAdapter, alm da interface InputEventListener. Para
cada tipo de mdia a ser executado existe um adaptador distinto,
sendo eles: AndroidImagePlayerAdapter, AndroidVideoPlayerAdapter, AndroidHTMLPlayerAdapter, AndroidAudioPlaye-

rAdapter e AndroidLuaPlayerAdapter.
A implementao dos quatro primeiros foi elaborada de forma
que cada um deles estenda a classe AndroidMediaPlayerAdapter.
Esta classe responsvel por agrupar caractersticas comuns quelas que a estendem. Por fim, a classe FormatterPlayerAdapter
responsvel por executar comandos de gerenciamento das mdias
de udio, Vdeo, Imagem e HTML.

3.2.7

buffer de recepo no dispositivo.

4.1

Conforme o apresentado na seo 3.2.7, o processo de iniciar

um evento do tipo Apresentao custoso e envolve a preparao
da mdia. O experimento apresentado pretende analisar o comportamento do tempo de preparao para documentos NCL contendo
um grande nmero de mdias a serem exibidas simultaneamente,
indicando o tempo de atraso relativo a este processo.
Considerando que este tempo de preparo do exibidor pode variar
significativamente em funo do nmero de mdias simultneas, foram elaboradas aplicaes NCL incrementando-se gradativamente
o nmero de mdias a fim de quantificar a variao do tempo de
preparo. Os testes foram realizados em aplicaes exibindo simultaneamente de 1 a 50 mdias. No entanto, o middleware no foi capaz de exibir arquivos com mais de 40 mdias devido s limitaes
de seus recursos de memria e processamento, tendo a execuo
abortada pelo sistema operacional durante o processo de preparao.
Para cada um dos arquivos foi realizado um estudo de tempo de
preparao das mdias que seriam exibidas. As Figuras 2(a) e 2(b)
ilustram os tempos de preparo para cada mdia presente nas aplicaes NCL contendo 14 e 38 mdias de imagem de 2.3 KB cada,
respectivamente, que deveriam ser exibidas simultaneamente. Os
demais grficos no foram plotados neste trabalho visto que o comportamento dos mesmos se mantm semelhante aos abaixo apresentados.
Durante os experimentos foi observado que haviam no mximo
6 threads concorrentes do Media Player (ocorrido, por exemplo na
Figura 2(a)). O fato de haver um limite mximo de threads simultneas era um resultado esperado para dispositivos portteis. No
entanto, essa observao sugere aos desenvolvedores de aplicativos
NCL uma orientao quanto ao limite no nmero de mdias simultneas que podem ser suportadas em aplicativos NCL nesta categoria de dispositivos, devido ao atraso considervel no tempo de
preparo em decorrncia deste nmero mximo de threads de carregamento. Isto dito considerando que o dispositivo utilizado para
testes reflete uma capacidade mdia-alta de processamento e memria atual para a categoria.
Alm disso, pode-se perceber que vrias threads tendem a terminar em um instante prximo execuo do garbage collector (GC),
por exemplo, no instante 2350ms da Figura 2(b), onde 4 threads encerram sua execuo logo aps essa chamada. Esta caracterstica
peculiar explicada pela liberao de recursos (memria) necessrios para o trmino da execuo dessas threads concorrentes.
Nota-se ainda que o tempo de preparao das mdias est relacionado ao intervalo entre chamadas ao GC. Para um intervalo grande,
h uma maior probabilidade de saturao dos recursos no dispositivo, isso leva a um aumento no tempo de execuo da thread. Para
intervalos menores, por exemplo, entre 1400ms e 1500ms da Figura
2(b), a liberao de recursos pelo GC permitiu uma diminuio no
tempo de execuo das threads 11, 12 e 13. No entanto, evidente
que h ainda um conjunto de threads do sistema que competem
por recursos e isso tambm um fator que afeta o tempo total de
preparo.

Escalonador

O escalonador de documentos NCL um importante mdulo da

arquitetura do middleware implementado, sendo ele o responsvel
por orquestrar a exibio de todos os elementos presentes em um
documento NCL.
A implementao do Escalonador tem como base o recebimento
via parmetro de um evento NCL, que pode ser instantneo ou
ter durao mensurvel, e de uma ao a ser realizada sobre este
evento. Um evento NCL pode ser do tipo Seleo, em que uma rea
ou n do documento selecionada; Atribuio, em que um valor
atribudo a uma propriedade de um n NCL; Composio, com o
qual um mapa da composio exibido; ou Apresentao, em que
a mdia contida em um n NCL exibida. Aes sobre os trs primeiros tipos so aes mais simples e de execuo rpida; porm,
aes em eventos do tipo Apresentao so aes sobre uma mdia
pertencente ao documento NCL e necessitam de um tratamento diferente. Este tipo de evento tem associado a ele um Exibidor que
executar em uma thread separada a mdia em questo e sobre o
qual sero executadas as aes.
importante destacar, no Escalonador, a ao de start para um
evento do tipo Apresentao. Ao ser feita esta chamada, o player da
mdia em questo deve ser instanciado e preparado para exibio.
Esta preparao consiste em criar uma superfcie de exibio para
a mdia e envi-la ao Gerenciador de Layout para que esta possa
ser adicionada ao conjunto de superfcies em exibio. Aps realizar estas preparaes, o escalonador adicionado como listener do
evento e chamado o mtodo start do exibidor.
Para manter a sincronia dos eventos, o Escalonador prov uma
funo de Callback e registra-se como listener dos eventos no
instantneos. Atravs deste Callback o Escalonador recebe atualizaes sobre o estado de cada evento iniciado e consegue manter
uma estrutura interna para gerncia de eventos condicionais. Desta
maneira, o escalonador gerencia a instanciao de novas threads e
a construo das superfcies de exibio associadas. As aes de
controle sobre as mdias so recebidas pelo escalonador e repassadas aos Exibidores especficos, e os eventos gerados pelos players,
como o trmino de uma exibio, so passados ao escalonador atravs do Callback.

4.

Anlise do tempo de preparo para exibio de mdias simultneas

EXPERIMENTOS PARA VALIDAO

Para avaliar o desempenho do middleware foram desenvolvidas aplicaes NCL que exploram caractersticas importantes desta
plataforma. As aplicaes foram executadas no middleware embarcado em um dispositivo HTC com processador Qualcomm RMSM
7200A, 528 MHz executando o sistema operacional Android, com
512 MB de memria ROM e 288 MB de memria RAM. As dimenses so 113 x 55.56 x 13.65 mm com resoluo de 320x480
HVGA.
O primeiro experimento visa analisar o atraso decorrente da preparao inicial dos players de mdia chamados pelo escalonador em
aplicaes que contm um nmero elevado de mdias simultneas.
O segundo experimento foi desenvolvido para analisar a utilizao
de CPU e memria durante a execuo de aplicaes NCL com caractersticas diferentes. Por fim, o terceiro experimento analisa a
implementao do protocolo DSM-CC sobre IP e a saturao do

4.2

Anlise do uso de memria e CPU durante

a execuo de aplicaes NCL

Recursos como memria e capacidade de processamento so usualmente limitados em dispositivos portteis, fazendo com que o seu
gerenciamento seja um ponto chave no desenvolvimento, em particular, de um middleware embarcado, cuja gesto de recursos tem

47

Na parte inferior da tela existem trs opes, atravs das quais

o telespectador poder interagir com a aplicao. Caso o telespectador selecione a primeira opo, sero apresentados os pilotos
participantes do Grande Prmio, conforme Figura 3(a). Caso seja
selecionada a segunda opo, sero apresentados as escuderias participantes, conforme Figura 3(b). Por fim, caso seja selecionada
a ultima opo, sero exibidos os circuitos nos quais as corridas
sero disputadas.
possvel ver na Figura 3(a) que a imagem do carro est sobreposta ao vdeo. Essa era uma das limitaes da plataforma utilizada
no trabalho [7]. Na implementao em Android, isto possvel devido ao gerenciador grfico da API Android, que permite a sobreposio de Surfaces.

(a) Aplicao contendo 14 mdias NCL

40

35

30

(a) Pilotos participantes na temporada

Thread ID

25

20

15

10

5
garbage collector
threads
0
0

1000

2000

3000

4000

5000

Tempo (ms)

(b) Escuderias inscritas na temporada

(b) Aplicao contendo 38 mdias NCL

Figure 2: Tempo de preparo para aplicaes NCL

Analise do Uso de Processamento e Uso de Memoria

100

Consumo de CPU

Porcentagem de consumo da CPU

Consumo Memoria

220000

80
200000

60
180000

40
160000

20

140000

120000
0

4.2.1

Frmula 1

Consumo de memoria (bytes)

grande impacto nas aplicaes que o utilizam.

O objetivo deste teste analisar a utilizao de CPU e memria
em duas aplicaes NCL, desenvolvidas em conjunto PUC-RJ,
com caractersticas diferentes. Para obter as medidas referentes a
esses recursos durante a execuo, foi utilizada a ferramenta Android Debug Bridge (ADB)2 . Tal ferramenta permite um acesso via
shell ao sistema linux do Android, no qual o middleware possui um
processo identificvel. Baseando-se no /proc 3 pode-se medir o uso
de recursos pelos processos.
Para capturar as telas que sero apresentadas nesta seo, foi
utilizada a ferramenta Device Screen Capture contida no Android
SDK, atravs da qual possvel capturar uma imagem que est
sendo exibido na tela do dispositivo.

10

15

20

25

30

35

Tempo Decorrido (segundos)

(c) Anlise de CPU e Memria

Figure 3: Frmula 1

A primeira aplicao apresenta uma exibio de um grande prmio de Frmula 1. A aplicao consiste em apresentar um vdeo
principal, com resoluo de 320x180, e algumas combinaes de
mdias de imagem secundrias que so exibidas de acordo com a
sequncia de toques no visor do dispositivo.

Observando a execuo da aplicao, Figura 3(c), pode-se perceber que apesar de exibir um vdeo juntamente com imagens e
interao com usurio, o uso da CPU no passa de 80%, enquanto
a utilizao de memria no chega a 10% da capacidade do dispositivo (210Kb de 288Mb disponveis).
A existncia de vales e picos no consumo de CPU um comportamento que ocorre sempre que h uma interao do usurio selecionando uma das opes disponveis. Ao fazer isto, um evento

2
Android Debug Bridge uma ferramenta contida no Android
SDK que permite gerir o estado de uma instncia do emulador ou
de um dispositivo executando Android
3
O /proc no Linux ponto de montagem de um pseudo sistema de
arquivos que permite acessar informaes de processos no sistema.

48

gerado pelo sistema Android e repassado ao middleware, que deve

reconhec-lo e realizar a ao relacionada, processo que resulta no
aumento temporrio do uso de CPU.
No que diz respeito ao consumo de memria, pode-se perceber
um aumento do consumo at o instante 5s, que explicado pela
instanciao em memria dos objetos a serem manipulados pelo
middleware. Aps este instante, percebe-se uma certa linearidade
no consumo de memria com pequenas variaes de consumo. Estas variaes ocorrem devido troca das imagens exibidas e o preenchimento do buffer de exibio do vdeo, que representam um
aumento do consumo, em contrapartida s execues do GC, que
representam um declnio. Ao final, com o consumo do buffer, a
curva do uso de memria apresenta uma queda.

4.2.2

incio da aplicao. Desta maneira, a interao do usurio apenas

altera a disposio das mdias, gerando picos e vales no consumo
de CPU, de maneira similar ao exemplo anterior.
Alm disto, esta aplicao apresenta um baixo uso de recursos,
mantendo o pico mais alto de CPU abaixo de 50% e a mdia prxima de 25% e com uma utilizao de memria inferior a 10% da
capacidade total do dispositivo.

4.3

Anlise dos Mdulos Transporte e Processador de Dados

De modo a iniciar o desenvolvimento do Mdulo Processador

de Dados, foi implementado o protocolo DSM-CC (Digital Storage Media Command and Control)[11], adotado pela norma do
SBTVD-T como carrossel de dados. Segundo a norma, o DSM-CC
utilizado sobre o MPEG-2 TS (Transport Stream) e transmitido como fluxo de dados no sincronizado com os programas. Porm, a implementao escolhida foi DSM-CC sobre o protocolo IP,
considerando especificamente as mensagens do carrossel. Embora
a codificao e decodificao das sees MPEG-2 em pacotes TS
no tenham sido implementadas neste prottipo, isso no restringe
a transmisso de dados que compem os aplicativos NCL.
Para testar a implementao, construiu-se um cenrio de experimentao composto pelos seguintes elementos (Figura 5):

Mosaico

A segunda aplicao testada foi elaborada com base nos cartes

postais da cidade do Rio de Janeiro. O seu objetivo o de testar
a integrao com o exibidor HTML e o funcionamento do recurso
de foco e seleo. Ao ser iniciada, a aplicao em questo divide a
tela em nove espaos de igual tamanho. Cada um dos espaos preenchido com uma imagem embaralhada aleatoriamente, conforme
Figuras 4(a) e 4(b), sendo cada um dos nove blocos passvel de seleo, bastando que o visor seja tocado para que o foco mude. O
objetivo do jogo que a imagem seja completada, movimentandose os blocos para o espao vazio.

Um servidor cujo papel transmitir aplicaes NCL atravs

de mensagens baseadas no protocolo DSM-CC;
Uma estao radio base WIFI que distribui mensagens recebidas do servidor via canal de broadcast;
Dispositivos portteis equipados com o middleware Ginga,
contendo um cliente DSM-CC para a recepo de mensagens
no mdulo Processador de Dados.

(a) Mosaico do Cristo

Redentor

(b) Mosaico do Maracan

Analise do Uso de Processamento e Uso de Memoria

100

Figure 5: Ambiente de experimentao DSM-CC

Consumo de CPU
220000

Para que a recepo do fluxo transmitido pela emissora seja efetivamente recebido em dispositivos portteis, preciso lembrar que
h uma notvel diferena entre a taxa de transmisso do servidor e
a taxa de recepo em dispositivos portteis. Em outras palavras,
requerido um mecanismo de controle de fluxo de modo que o receptor com recursos limitados (banda, processamento e cpu) no
seja saturado.
A ideia deste experimento investigar essa problemtica de saturao dos buffers do receptor na simulao de um ambiente de
difuso, quando faz-se uso de UDP. Para efeitos de comparao,
considera-se o caso no qual o fluxo transmitido usando o protocolo TCP tradicional.
O experimento consiste em transmitir uma aplicao NCL atravs do ambiente especificado e analisar o tempo de transferncia
percebido em um dispositivo porttil rodando o cliente DSM-CC.
Para cada ponto, os experimentos foram repetidos 5 vezes para
obteno de um valor mdio. A Figura 6 apresenta os resultados
obtidos, com o ndice junto a sigla UDP significando o valor do
intervalo entre envios consecutivos (pacing) em milissegundos.

80
200000

60
180000

40
160000

20

Consumo de memoria (bytes)

Porcentagem de consumo da CPU

Consumo Memoria

140000

120000
0

10

15

20

25

30

35

Tempo Decorrido (segundos)

(c) Anlise de CPU e Memria

Figure 4: Mosaicos
Durante a execuo desta aplicao, conforme Figura 4(c), o
consumo de memria manteve-se praticamente constante. Isto se
deve instanciao e apresentao de todas as mdias ser feita no

49

100
80

TCP
UDP
UDP2
UDP5
UDP10

mentao do mdulo Context Manager, previsto na arquitetura conceitual do Ginga. A sua integrao no middleware Ginga-NCL
Android permitir a construo de aplicaes NCL mais elaboradas, que associam mobilidade, interatividade e sensibilidade ao
contexto. Em relao transmisso de dados, prev-se a implementao do protocolo MPEG-2 TS para adequar-se norma. Por
fim, em vista da futura disponibilidade de dispositivos baseados em
Android com hardware capaz de receber o sinal de radiodifuso, a
implementao do mdulo Sintonizador ser necessria para lidar
com esta forma de recepo dos dados.

UDP5

60

TCP

40

Tempo (s)

UDP2

20

UDP10

Agradecimentos
0

Este trabalho parcialmente financiado pela Rede Nacional de Ensino e

Pesquisa (RNP) atravs do Centro de Pesquisa e Desenvolvimento em Tecnologias Digitais para Informao e Comunicao (CTIC) sub-projeto Ginga
Frevo-GingaRAP, e pela CAPES - Brasil (RH-TVD #225/2008).

1000

2000

3000

4000

5000

6000

7000

Tamanho Aplicativo (KB)

Figure 6: Medies de transferncia de aplicativos

6.
A primeira observao a linearidade do caso TCP. Com relao aos cenrios UDP, possvel perceber claramente a influncia
do tamanho de intervalo sobre o tempo total de transmisso. A
medida que aumentou-se o espaamento entre envios consecutivos,
pde-se perceber uma melhoria no tempo de transmisso, ao ponto
que o caso UDP10 propiciou melhores resultados que o caso base
(TCP). interessante notar que o gargalo determinado pela taxa
que o dispositivo porttil capaz de consumir do buffer de recepo. Por exemplo, no caso do UDP2 , o tempo de consumo no
suficiente para que os dados sejam recebidos resultando em uma
inundao considervel. O resultado sugere que uma melhoria na
infra-estrutura de comunicao no implica em uma melhoria da
taxa de transferncia efetiva. Entretanto, um ponto chave evidenciado pelo resultado o fato do gargalo estar no dispositivo porttil e
este determinado pela taxa de consumo do buffer de recepo.

5.

CONCLUSES E TRABALHOS FUTUROS

Com foco nos terminais de recepo portteis, o presente trabalho descreve uma implementao do middleware Ginga-NCL para
a plataforma Android, sistema operacional de cdigo aberto da Google. Esta , no nosso conhecimento, a primeira implementao do
Ginga-NCL para esse novo e promissor sistema operacional para
dispositivos embarcados.
A avaliao funcional e de desempenho da implementao est
ancorada em um conjunto de experimentos e medies executados
a partir de aplicaes NCL desenvolvidas. Os resultados obtidos
permitem afirmar que a especificao Ginga-NCL e a implementao aqui descrita so capazes de executar com sucesso aplicaes
NCL em dispositivos portteis com a plataforma Android. Esperase que o trabalho possa ser utilizado para estimular e orientar tanto
implementaes futuras do middleware quanto o desenvolvimento
de aplicaes NCL voltadas a essa classe de dispositivos. Para isso,
pretende-se disponibilizar em repositrio pblico o cdigo fonte da
implementao realizada.
O prottipo desenvolvido dever ser usado como ponto de partida para a execuo de novos trabalhos, alguns deles de necessidade imediata, como a realizao de baterias de experimentos
exaustivos e sistmicos para garantir a robustez do middleware.
Alm disto, a mquina de execuo Lua deve ser implementada,
como requerido pelo padro de middleware do SBTVD. Com relao ao suporte a mltiplos dispositivos, a implementao dever
suportar o modelo de controle hierrquico do NCL, conforme discutido em [5].
Outro trabalho, j em andamento no LPRM/UFES, a imple-

50

REFERENCES

[1] ABNT NBR 15606-4. Televiso digital terrestre - Codificao de

dados e especificaes de transmisso para transmisso digital - Parte
4: Ginga-J - Ambiente para a execuo de aplicaes procedurais.
2010.
[2] ABNT NBR 15606-5. Televiso digital terrestre - Codificao de
dados e especificaes de transmisso para radiodifuso digital Parte
5: Ginga-NCL para receptores portteis - Linguagem de aplicao
XML para codificao de aplicaes. 2009.
[3] Open Handset Alliance.
http://www.openhandsetalliance.com/press_110507.html.
[4] ARIB. ARIB STD-B24. Data Coding and Transmission Specification
for Digital Broadcasting, Junho 2008.
[5] Romualdo M. de Resende Costa e Marcio Ferreira Moreno e Luiz
Fernando Gomes Soares. Ginga-ncl: Suporte a mltiplos
dispositivos. In XV Simpsio Brasileiro de Sistemas Multimdia e
Web - WebMedia2009, Fortaleza, CE, Brasil, 2009.
[6] Guido Lemos de Souza Filho, Luiz Eduardo Cunha Leite, and Carlos
Eduardo Coelho Freire Batista. Ginga-j: The procedural middleware
for the brazilian digital tv system. Journal of the Brazilian Computer
Society, 12(4):4756, march 2007.
[7] Vtor Medina Cruz e Marcio Ferreira Moreno e Luiz Fernando
Gomes Soares. Ginga-ncl: Implementao de referncia para
dispositivos portteis. In XIV Simpsio Brasileiro de Sistemas
Multimdia e Web - WebMedia2008, pages 6774, Vila Velha, ES,
Brasil, 2008.
[8] ETSI. ETSI TS 102 428. Digital Audio Broadcasting (DAB); DMB
video service; User Application Specification. European Standard
(Telecommunications series), Novembro 2005.
[9] Gerard Faria, Jukka A. Henriksson, Erik Stare, and Pekka Talmola.
DVB-H: Digital broadcast services to handheld devices. Proceedings
of the IEEE, 94(1):194209, Jan. 2006.
[10] D. Hoffman, G. Fernando, and V. Goyal. RTP Payload Format for
MPEG1/MPEG2 Video, RFC 2038, Outubro 1996.
[11] International Organization for Standardization / International
Eletrotecnical Committee ISO/IEC 13818-6. Information technology
- coding of audio-visual objects - part 6: Extensions for dsm-cc.
2000.
[12] ITU-T. Nested context language (ncl) and ginga-ncl for iptv services,
2009.
[13] ABNT NBR15606-2. Televiso digital terrestre - Codificao de
dados e especificaes de transmisso para radiodifuso digital Parte
2: Ginga-NCL para receptores fixos e mveis - Linguagem de
aplicao XML para codificao de aplicaes. Abril 2008.
[14] Symbian Developer Network. http://developer.symbian.com.
[15] Luiz Fernando Gomes Soares and Simone Diniz Junqueira Barbosa.
Programando em NCL 3.0. Editora Campus, 2009.
[16] Luiz Fernando Gomes Soares, Rogrio Ferreira Rodrigues, and
Marcio Ferreira Moreno. Ginga-ncl: the declarative environment of
the brazilian digital tv system. Journal of the Brazilian Computer
Society, 12(4), March 2007.