Ginga-NCL em Dispositivos Portteis:

Uma Implementao para a Plataforma Android

Guilherme Daher Ferreira Guilherme Nogueira Giovanni Comarela

daher@inf.ufes.br guilherme@inf.ufes.br gcomarela@inf.ufes.br
Fbio Fabris Magnos Martinello Jos Gonalves P. Filho
ffabris@inf.ufes.br magnos@inf.ufes.br 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 interac-
tive 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 execu-
tion of NCL applications, as well as the usage of devices resources.
Moreover, the developed environment allows to evaluate the trans-
mission and reception of NCL applications through the standardi-
zed DSM-CC over IP protocol.
RESUMO
Hoje j existem no Brasil aparelhos que permitem a recepo do
sinal de TV digital. No entanto, estes dispositivos no esto equi-
pados 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 im-
plementao do Ginga-NCL para dispositivos portteis baseados
no sistema operacional Android. Como meio de validar a imple-
mentao, foram conduzidos experimentos para analisar a execu-
o 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, Hyper-
text/Hypermedia, Markup languages, Standards.
Ginga-NCL for Portable Devices: An Implementation for the An-
droid Platform
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 port-
teis, tais como a Samsung e LG, cujos aparelhos permitem a recep-
o 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 dis-
positivos portteis disponveis no mercado brasileiro, embora se
aproveitem da qualidade superior de udio e vdeo inerente s tec-
nologias digitais, no suportam a interatividade. Logo, existe uma
demanda natural por implementaes do middleware Ginga volta-
das para terminais portteis.
No cenrio de mobilidade, a escolha do sistema operacional em-
barcado 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 Ginga-
NCL 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 plata-
forma 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 com-
piladas para a mquina virtual Dalvik. Esta mquina virtual foi
projetada especialmente para a plataforma Android, sendo otimi-
zada 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-

43
NCL para dispositivos portteis, tendo como sistema operacional
embarcado o Google Android. Um estudo experimental foi re-
alizado para avaliar a sensibilidade de aplicaes NCL [15] e o
desempenho do middleware desenvolvido, incluindo o atraso de-
corrente da preparao dos players considerando aplicaes con-
tendo um nmero elevado de mdias simultneas, e a utilizao de
CPU e memria durante a execuo de aplicaes NCL com ca-
ractersticas distintas. O ambiente de testes empregado permite ex-
perimentar aplicaes multimdia escritas na linguagem NCL, ex-
traindo medidas de interesse. No caso da transmisso e recepo
de contedo, foi implementado o protocolo DSM-CC (Digital Sto-
rage Media Command and Control) [11] sobre IP, permitindo efe-
tuar 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 implemen-
tao realizada no sistema Android. Seo 4 contempla o estudo
experimental realizado com vistas avaliao sistmica do prot-
tipo desenvolvido. Por fim, a seo 5 conclui o artigo apresentando
as consideraes finais e as perspectivas de trabalhos futuros.
2. 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 pa-
dres.
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 ado-
tam, disponibilizam middleware para aparelhos compatveis.
Digital Multimedia Broadcasting (DMB) [8] uma tecnologia
de transmisso desenvolvida pela Coria do Sul como parte do pro-
jeto nacional de tecnologia de informao para transmisses de TV,
rdio e dados para dispositivos portteis. Este sistema oferece su-
porte 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) res-
ponsvel 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 dis-
positivos 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 Inter-
national. Esta nomenclatura deve-se a um processo de harmoniza-
o 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 bra-
sileiro (ISDB-T International) a especificao do middleware bra-
sileiro, denominado Ginga, tanto para set-top-boxes quanto para
dispositivos portteis. O Ginga-NCL, parte declarativa do mid-
dleware, possui o profile Basic DTV, utilizado para dispositivos
portteis, especificado em [2]. Alm de utilizado no padro bra-
sileiro de TV digital, o Ginga-NCL padronizado atravs da reco-
mendao H.761 do ITU-T [12] como middleware para aplicaes
multimdia em IPTV, provendo interoperabilidade e harmonizao
entre os distintos frameworks para desenvolvimento destas aplica-
es.
No trabalho [7], foi apresentada uma implementao do mid-
dleware Ginga para dispositivos portteis baseados no sistema ope-
racional Symbian. Trata-se da primeira implementao de refern-
cia 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 pla-
taforma 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 exe-
cuo de aplicaes NCL em dispositivos portteis.
3. MIDDLEWARE DECLARATIVO GINGA-
NCL EM ANDROID: ARQUITETURA E
IMPLEMENTAO
O universo das aplicaes Ginga pode ser classificado como um
conjunto composto por aplicaes declarativas e aplicaes proce-
durais. Aplicaes declarativas so tratadas pelo subsistema Ginga-
NCL 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 (fra-
mework) 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
 NCL Applications tre a Mquina de Apresentao e a API de decodificao de con-
Android Applications tedo dos exibidores, sendo que para cada exibidor existe um adap-
0.10 cDisplay Driver
GINGA-NCL tador associado. Ainda como os Exibidores, os Adaptadores se-
guem uma padronizao de interface.
Activity Content Package Location O Gerenciador Grfico realiza o controle da renderizao dos
Manager Provider Manager Manager
objetos especificados na aplicao NCL, definindo as dimenses
Window View Resource Notification
Manager System Manager Manager e posicionamento destes objetos. O Gerenciador de Atualiza-
es, possui como principal caracterstica receber e instalar atuali-
Surface Media
zaes de maneira independente sem interromper o funcionamento
Manager Framework Dalvik VM do middleware, e o Gerenciador de Contexto, responsvel por
gerenciar o perfil de usurio e demais informaes contextuais.
OpenGL | ES Libc
No subsistema da mquina de apresentao, o principal compo-
Core Libraries nente o Formatador e seu papel consiste em direcionar todas
SGL SSL
as aes a serem executadas. Inicialmente o Formatador solicita
WebKit FreeType ao Conversor que processe a aplicao NCL. O resultado desta
converso uma rvore de execuo denominada Base Privada. A
Flash Memory gerncia de todas as bases presentes no middleware feita pelo
Display Driver Camera Driver Blinder Driver
Driver componente Gerenciador de Bases Privadas.
Keypad Driver Wifi Driver Audio Driver
Power Aps receber esta estrutura de dados, o Formatador dispara a
Management
execuo do Escalonador, cuja responsabilidade gerir a execuo
e temporizao das mdias presentes na aplicao NCL. O Escalo-
(a) Camada Ginga-NCL sobre Android
nador atribui ao Gerenciador de Exibidores o processamento dos
Mquina de Apresentao Ginga NCL recursos necessrios para exibio de cada mdia e ao componente
Gerenciador de Layout a responsabilidade de definir os parme-
Gerenciador de Gerenciador
Conversor
Bases Privadas de Layout
tros de exibio NCL no dispositivo.
Gerenciador

Formatador Escalonador
de Contexto 3.2 Implementao
Gerenciador Para a implementao do Ginga-NCL em Android, partiu-se da
Exibidores
implementao pblica em Java para set-top box. No entanto, uma
srie de modificaes foram efetuadas, principalmente nos mto-
Ncleo Ginga Adaptadores
dos relacionados ao gerenciamento e manipulao dos elementos
Processador
Gerenciador de Contexto
grficos (vdeo, pginas HTML e imagens) e udio.
de Dados
Os componentes que tiveram de ser implementados ou alterados
Gerenciador de
Atualizaes
Persistncia Mquina Lua Exibidores encontram-se com fundo escuro e fonte clara na Figura 1(b) e os
Gerenciador
que permaneceram inalterados em fundo claro com fonte preta.
Sintonizador Transporte
Grco No foi possvel utilizar diretamente a implementao pblica,
pois ela faz uso de recursos de bibliotecas grficas no suportadas
API Android no dispositivo porttil (tais como AWT e Swing). A parte do c-
digo que no utiliza estas bibliotecas precisou de poucas modifica-
Bibliotecas de Sistema Dalvik VM
es devido natureza portvel da plataforma de desenvolvimento
Kernel Linux Java/Dalvik. A implementao resultante capaz de executar apli-
caes NCL declarativas em dispositivos portteis de maneira sa-
(b) Viso dos Componentes Ginga-NCL tisfatria conforme apresentado na seo 4.
Figure 1: Arquitetura Ginga NCL para dispositivos portteis 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,
set-top-boxes, o ncleo Ginga responsvel por prover recursos a implementao atual ainda no possui um mdulo Sintonizador
necessrios mquina de apresentao NCL. Seu componente Sin- funcional. Alm disso, o mdulo Processador de Dados encontra-
tonizador tem o papel de receber contedo de TVD para dispo- se num estado inicial em que foi implementado um cliente para o
sitivos portteis (1-seg) transmitido por provedores de contedo. protocolo DSM-CC, cuja descrio encontra-se na seo 4.3.
As aplicaes interativas podem chegar ao dispositivo de dois mo- As prximas sees apresentam detalhes das classes que foram
dos: multiplexadas no contedo recebido pelo Sintonizador, ou por implementadas nesta primeira verso do Ginga-NCL em Android.
outra interface de rede presente no dispositivo. Quando a aplica-
o estiver multiplexada, ela obtida atravs de um processamento 3.2.1 Formatador
efetuado pelo mdulo Processador de Dados sobre o contedo re- A classe Formatter atua como um gerenciador em alto nvel,
cebido. O componente Transporte definido para gerenciar pro- sendo responsvel pelo controle das aplicaes NCL presentes no
tocolos e interfaces de rede, para o caso em que a aplicao for middleware. este gerenciador o responsvel por receber uma
recebida por este meio. Aps o recebimento destas aplicaes e do aplicao NCL, convert-la para uma Base Privada, armazen-la
contedo referenciado por elas, o mdulo Persistncia atua para e iniciar sua execuo, alm de repassar comandos para pausar e
gerenciar o seu armazenamento. reiniciar uma aplicao.
O componente Exibidores responsvel pelos decodificadores A instanciao inicial da classe ocorre na Activity principal do
especficos para cada tipo de mdia. Por outro lado, o componente Middleware, a classe GingaMobile. A classe mantm uma refe-
Adaptadores responsvel pela padronizao da comunicao en- rncia 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 se-
guintes aes: compilar a aplicao NCL para gerar uma Base Pri-
vada, 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 re-
aliza 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 ini-
ciais, poder iniciar a execuo da aplicao.
3.2.2 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 IEn-
tity. 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 de-
finem como os objetos sero inicialmente apresentados dentro de
regies de dispositivos de sada. Components define os tipos bsi-
cos 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 m-
dia 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 imple-
mentada. Animation , na verdade, uma combinao de fatores de
suporte ao desenho do objeto e de suporte ao movimento do ob-
jeto 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 des-
tas classes foram seguidos os padres definidos em [13].
3.2.3 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. En-
tretanto, 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 ini-
cial, e duas classes internas que implementam a interface Runna-
ble, 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.
Analogamente, a classe updateUI utilizada para alterar o layout
principal, adicionando e removendo elementos do tipo AndroidWin-
dow adicionados listas internas atravs dos mtodos addRemove-
Task, addDisplayTask, addLayout e addClearTask.
3.2.4 Gerenciador de Exibidores
O mdulo Gerenciador de Exibidores compreende as classes ne-
cessrias ao gerenciamento da execuo dos exibidores de mdias e
de interao com usurio.
Pode-se destacar nesta implementao a interface AndroidSur-
face, 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 mid-
dleware. A fim de realizar a interface entre o middleware e as
bibliotecas nativas da API, foram implementadas a AndroidAu-
dioSurface, AndroidHTMLSurface, AndroidVideoSurface e a
AndroidImageSurface.
Uma outra classe importante a AndroidWindow. Sua fun-
o 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 An-
droidWindow.
Por fim, tem-se a classe GingaKeyListener, responsvel por re-
ceber 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, pro-
vida pela API Android, que chamada sempre que um evento
enviado para uma respectiva View.
3.2.5 Exibidores
No mdulo exibidores temos os apresentadores de mdia defini-
dos para cada tipo suportado pelo middleware. Eles so utilizados
pelos adaptadores para inserir as mdias numa apresentao e defi-
nem 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, An-
droidAudioPlayer e AndroidAudioPlayerAdapter, esto relaci-
onados.
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 implemen-
tam as interfaces de adaptador e listener de eventos. Desta forma,
o adaptador recebe uma chamada de execuo de uma mdia e car-
rega 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 es-
tender as interfaces NCL IFormaterPlayerAdapter e IProcedu-
ralPlayerAdapter, alm da interface InputEventListener. Para
cada tipo de mdia a ser executado existe um adaptador distinto,
sendo eles: AndroidImagePlayerAdapter, AndroidVideoPlaye-
rAdapter, AndroidHTMLPlayerAdapter, AndroidAudioPlaye-
46
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 que-
las 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 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 pri-
meiros 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 di-
ferente. 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 reali-
zar 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 atua-
lizaes 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 repassa-
das aos Exibidores especficos, e os eventos gerados pelos players,
como o trmino de uma exibio, so passados ao escalonador atra-
vs do Callback.
4. EXPERIMENTOS PARA VALIDAO
Para avaliar o desempenho do middleware foram desenvolvi-
das aplicaes NCL que exploram caractersticas importantes desta
plataforma. As aplicaes foram executadas no middleware embar-
cado 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 di-
menses so 113 x 55.56 x 13.65 mm com resoluo de 320x480
HVGA.
O primeiro experimento visa analisar o atraso decorrente da pre-
parao 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 ca-
ractersticas diferentes. Por fim, o terceiro experimento analisa a
implementao do protocolo DSM-CC sobre IP e a saturao do
buffer de recepo no dispositivo.
4.1 Anlise do tempo de preparo para exibi-
o de mdias simultneas
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 compor-
tamento 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, fo-
ram 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 simul-
taneamente de 1 a 50 mdias. No entanto, o middleware no foi ca-
paz 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 prepara-
o.
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 apli-
caes 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 com-
portamento dos mesmos se mantm semelhante aos abaixo apre-
sentados.
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 simul-
tneas 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 simul-
tneas que podem ser suportadas em aplicativos NCL nesta cate-
goria de dispositivos, devido ao atraso considervel no tempo de
preparo em decorrncia deste nmero mximo de threads de carre-
gamento. Isto dito considerando que o dispositivo utilizado para
testes reflete uma capacidade mdia-alta de processamento e me-
mria atual para a categoria.
Alm disso, pode-se perceber que vrias threads tendem a termi-
nar em um instante prximo execuo do garbage collector (GC),
por exemplo, no instante 2350ms da Figura 2(b), onde 4 threads en-
cerram sua execuo logo aps essa chamada. Esta caracterstica
peculiar explicada pela liberao de recursos (memria) necess-
rios para o trmino da execuo dessas threads concorrentes.
Nota-se ainda que o tempo de preparao das mdias est relacio-
nado ao intervalo entre chamadas ao GC. Para um intervalo grande,
h uma maior probabilidade de saturao dos recursos no disposi-
tivo, 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.
4.2 Anlise do uso de memria e CPU durante
a execuo de aplicaes NCL
Recursos como memria e capacidade de processamento so usu-
almente limitados em dispositivos portteis, fazendo com que o seu
gerenciamento seja um ponto chave no desenvolvimento, em par-
ticular, 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 teles-
pectador 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 par-
ticipantes, 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 sobre-
posta ao vdeo. Essa era uma das limitaes da plataforma utilizada
no trabalho [7]. Na implementao em Android, isto possvel de-
vido ao gerenciador grfico da API Android, que permite a sobre-
posio de Surfaces.

(a) Aplicao contendo 14 mdias NCL

40

35

30

25
(a) Pilotos participantes na temporada
Thread ID

20

15

10

5
garbage collector
threads
0
0 1000 2000 3000 4000 5000
Tempo (ms)

(b) Aplicao contendo 38 mdias NCL (b) Escuderias inscritas na temporada

Figure 2: Tempo de preparo para aplicaes NCL Analise do Uso de Processamento e Uso de Memoria
100
grande impacto nas aplicaes que o utilizam. Consumo de CPU
Consumo Memoria
220000
O objetivo deste teste analisar a utilizao de CPU e memria
em duas aplicaes NCL, desenvolvidas em conjunto PUC-RJ, 80
Porcentagem de consumo da CPU

com caractersticas diferentes. Para obter as medidas referentes a

Consumo de memoria (bytes)

200000

esses recursos durante a execuo, foi utilizada a ferramenta An-

droid Debug Bridge (ADB)2 . Tal ferramenta permite um acesso via 60
180000
shell ao sistema linux do Android, no qual o middleware possui um
processo identificvel. Baseando-se no /proc 3 pode-se medir o uso 40
de recursos pelos processos. 160000

Para capturar as telas que sero apresentadas nesta seo, foi

utilizada a ferramenta Device Screen Capture contida no Android 20
140000
SDK, atravs da qual possvel capturar uma imagem que est
sendo exibido na tela do dispositivo.
0 120000
0 5 10 15 20 25 30 35
4.2.1 Frmula 1 Tempo Decorrido (segundos)

A primeira aplicao apresenta uma exibio de um grande pr-
mio 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.
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 tamento que ocorre sempre que h uma interao do usurio sele-
O /proc no Linux ponto de montagem de um pseudo sistema de
arquivos que permite acessar informaes de processos no sistema.
(c) Anlise de CPU e Memria
Figure 3: Frmula 1
Observando a execuo da aplicao, Figura 3(c), pode-se per-
ceber 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 dispo-
sitivo (210Kb de 288Mb disponveis).
A existncia de vales e picos no consumo de CPU um compor-
cionando uma das opes disponveis. Ao fazer isto, um evento

48
gerado pelo sistema Android e repassado ao middleware, que deve incio da aplicao. Desta maneira, a interao do usurio apenas
reconhec-lo e realizar a ao relacionada, processo que resulta no altera a disposio das mdias, gerando picos e vales no consumo
aumento temporrio do uso de CPU. de CPU, de maneira similar ao exemplo anterior.
No que diz respeito ao consumo de memria, pode-se perceber Alm disto, esta aplicao apresenta um baixo uso de recursos,
um aumento do consumo at o instante 5s, que explicado pela mantendo o pico mais alto de CPU abaixo de 50% e a mdia pr-
instanciao em memria dos objetos a serem manipulados pelo xima de 25% e com uma utilizao de memria inferior a 10% da
middleware. Aps este instante, percebe-se uma certa linearidade capacidade total do dispositivo.
no consumo de memria com pequenas variaes de consumo. Es-
tas variaes ocorrem devido troca das imagens exibidas e o pre- 4.3 Anlise dos Mdulos Transporte e Proces-
enchimento do buffer de exibio do vdeo, que representam um sador de Dados
aumento do consumo, em contrapartida s execues do GC, que De modo a iniciar o desenvolvimento do Mdulo Processador
representam um declnio. Ao final, com o consumo do buffer, a de Dados, foi implementado o protocolo DSM-CC (Digital Sto-
curva do uso de memria apresenta uma queda. rage Media Command and Control)[11], adotado pela norma do
SBTVD-T como carrossel de dados. Segundo a norma, o DSM-CC
4.2.2 Mosaico utilizado sobre o MPEG-2 TS (Transport Stream) e transmi-
A segunda aplicao testada foi elaborada com base nos cartes tido como fluxo de dados no sincronizado com os programas. Po-
postais da cidade do Rio de Janeiro. O seu objetivo o de testar rm, a implementao escolhida foi DSM-CC sobre o protocolo IP,
a integrao com o exibidor HTML e o funcionamento do recurso considerando especificamente as mensagens do carrossel. Embora
de foco e seleo. Ao ser iniciada, a aplicao em questo divide a a codificao e decodificao das sees MPEG-2 em pacotes TS
tela em nove espaos de igual tamanho. Cada um dos espaos pre- no tenham sido implementadas neste prottipo, isso no restringe
enchido com uma imagem embaralhada aleatoriamente, conforme a transmisso de dados que compem os aplicativos NCL.
Figuras 4(a) e 4(b), sendo cada um dos nove blocos passvel de se- Para testar a implementao, construiu-se um cenrio de experi-
leo, bastando que o visor seja tocado para que o foco mude. O mentao composto pelos seguintes elementos (Figura 5):
objetivo do jogo que a imagem seja completada, movimentando-
se 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 rece-

bidas 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 (b) Mosaico do Mara-

Redentor can

Analise do Uso de Processamento e Uso de Memoria

100 Figure 5: Ambiente de experimentao DSM-CC
Consumo de CPU
Consumo Memoria
220000

Para que a recepo do fluxo transmitido pela emissora seja efe-

80
tivamente recebido em dispositivos portteis, preciso lembrar que
Porcentagem de consumo da CPU

Consumo de memoria (bytes)

200000
h uma notvel diferena entre a taxa de transmisso do servidor e
60 a taxa de recepo em dispositivos portteis. Em outras palavras,
180000 requerido um mecanismo de controle de fluxo de modo que o re-
ceptor com recursos limitados (banda, processamento e cpu) no
40
160000
seja saturado.
A ideia deste experimento investigar essa problemtica de sa-
turao dos buffers do receptor na simulao de um ambiente de
20
140000
difuso, quando faz-se uso de UDP. Para efeitos de comparao,
considera-se o caso no qual o fluxo transmitido usando o proto-
0 120000 colo TCP tradicional.
0 5 10 15 20 25 30 35
Tempo Decorrido (segundos)
O experimento consiste em transmitir uma aplicao NCL atra-
vs do ambiente especificado e analisar o tempo de transferncia
(c) Anlise de CPU e Memria
Figure 4: Mosaicos percebido em um dispositivo porttil rodando o cliente DSM-CC.
Para cada ponto, os experimentos foram repetidos 5 vezes para
Durante a execuo desta aplicao, conforme Figura 4(c), o obteno de um valor mdio. A Figura 6 apresenta os resultados
consumo de memria manteve-se praticamente constante. Isto se obtidos, com o ndice junto a sigla UDP significando o valor do
deve instanciao e apresentao de todas as mdias ser feita no intervalo entre envios consecutivos (pacing) em milissegundos.

49

100
TCP
UDP
UDP2
UDP5
UDP10
80
UDP2
60
Tempo (s)
40
20
0
0 1000 2000 3000 4000 5000
Tamanho Aplicativo (KB)
Figure 6: Medies de transferncia de aplicativos
A primeira observao a linearidade do caso TCP. Com rela-
o 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 recep-
o. 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 evidenci-
ado 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 traba-
lho descreve uma implementao do middleware Ginga-NCL para
a plataforma Android, sistema operacional de cdigo aberto da Go-
ogle. 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 implementa-
o aqui descrita so capazes de executar com sucesso aplicaes
NCL em dispositivos portteis com a plataforma Android. Espera-
se 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 par-
tida para a execuo de novos trabalhos, alguns deles de neces-
sidade 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 re-
lao ao suporte a mltiplos dispositivos, a implementao dever
suportar o modelo de controle hierrquico do NCL, conforme dis-
cutido em [5].
Outro trabalho, j em andamento no LPRM/UFES, a imple-
mentao do mdulo Context Manager, previsto na arquitetura con-
UDP5 ceitual do Ginga. A sua integrao no middleware Ginga-NCL
Android permitir a construo de aplicaes NCL mais elabo-
radas, que associam mobilidade, interatividade e sensibilidade ao
contexto. Em relao transmisso de dados, prev-se a imple-
mentao do protocolo MPEG-2 TS para adequar-se norma. Por
TCP
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
UDP10
com esta forma de recepo dos dados.
Agradecimentos
Este trabalho parcialmente financiado pela Rede Nacional de Ensino e
Pesquisa (RNP) atravs do Centro de Pesquisa e Desenvolvimento em Tec-
6000 7000
nologias Digitais para Informao e Comunicao (CTIC) sub-projeto Ginga
Frevo-GingaRAP, e pela CAPES - Brasil (RH-TVD #225/2008).
6. 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.
50