ARTIGO
caçõeS multiuSuário e multidiSpoSitivo
para tv digital com ginga
LINCOLN DAVID NeRy e SILVA, CARLOS eDuARDO COeLhO FReIRe
BATISTA, LuIz eDuARDO CuNhA LeITe e GuIDO LemOS De SOuzA
FILhO
Introdução
O presente artigo visa descrever as definições do middleware Ginga que permitem o desenvolvi-mento de aplicações de TV Digital multiusuário e multidispositivo através da conexão do receptor de TV com dispositivos móveis, em uma HAN (Home
Área Network). O Ginga é o padrão de middleware
do Sistema Brasileiro de TV Digital, que dá supor-te à aplicações declarativas e procedurais, sendo compatível com as definições internacionais ITU J.200 [3], J.201 [4] e J.202 [5]. As definições da parte procedural do Ginga, o Ginga-J, é que in-cluem as APIs (Application Program Interfaces) que permitem o desenvolvimento de aplicações que po-dem utilizar recursos disponíveis nos dispositivos conectados ao receptor de TV Digital.
ArquIteturA do MIddlewAre GInGA O universo das aplicações para televisão digital pode ser dividido em dois conjuntos: o das aplica-ções declarativas e o das aplicaaplica-ções procedurais. Uma aplicação declarativa é aquela em que sua
entidade “inicial” é do tipo “conteúdo declarativo”. Analogamente, uma aplicação procedural é aquela em que sua entidade “inicial” é do tipo “conteúdo procedural”.
Um conteúdo declarativo deve ser baseado em uma linguagem declarativa, isto é, em uma lingua-gem que enfatiza a descrição declarativa do proble-ma, ao invés da sua decomposição em uma imple-mentação algorítmica [4]. Um conteúdo procedural deve ser baseado em uma linguagem não decla-rativa. Linguagens não declarativas podem seguir diferentes paradigmas. Tem-se assim, as lingua-gens baseadas em módulos, orientadas a objetos, etc. A literatura sobre televisão digital, no entanto, utiliza o termo procedural para representar todas as linguagens que não são declarativas. Numa pro-gramação procedural, o computador deve obriga-toriamente ser informado sobre cada passo a ser executado [5]. Pode-se afirmar que, em linguagens procedurais, o programador possui um maior poder sobre o código, sendo capaz de estabelecer todo o fluxo de controle e execução de seu programa - como existem mais recursos disponíveis o grau
de complexidade é maior. A linguagem mais usual encontrada nos ambientes procedurais de um sis-tema de TV digital é Java[6].
O Ginga-NCL[2] (ou Máquina de Apresentação) é um subsistema lógico do Sistema Ginga que pro-cessa documentos NCL. Um componente-chave do Ginga-NCL é o mecanismo de decodificação do conteúdo informativo (NCL formatter). Outros módulos importantes são o usuário baseado em XHTML, que inclui uma linguagem de estilo (CSS) e intérprete ECMAScript, e o mecanismo LUA, que é responsável pela interpretação dos scripts LUA.
O Ginga-J[1] (ou Máquina de Execução) é um subsistema lógico do Sistema Ginga que processa aplicações procedurais (Xlets Java). Um compo-nente-chave do ambiente do aplicativo procedural é o mecanismo de execução do conteúdo procedu-ral, que tem por base uma Máquina Virtual Java.
Decodificadores comuns de conteúdo devem servir para as necessidades de aplicativos tanto procedurais quanto informativos de decodificação e apresentação de conteúdos comuns do tipo PNG, JPEG, MPEG e outros formatos. O Ginga-Core é
composto por decodificadores e procedimentos comuns de conteúdo para obter conteúdos trans-portados em fluxos de transporte MPEG-2 (TS) e através de um canal de retorno.
A arquitetura (ver Figura 1) e as facilidades da especificação Ginga devem ser destinadas à apli-cação em sistemas e receptores de transmissão para transmissão terrestre (over-the-air). Além dis-so, a mesma arquitetura e facilidades podem ser aplicadas a outros sistemas de transporte (como sistemas de televisão via satélite ou cabo).
GInGA-J – A porção procedurAl do MIddlewAre BrAsIleIro
A Figura 2 apresenta o contexto em que a pi-lha do software Ginga-J é executada. O Ginga-J é uma especificação de middleware distribuído, que reside em um dispositivo Ginga (dispositivo que embarque o middleware Ginga – um receptor de televisão digital), com possibilidade de possuir componentes de software nos dispositivos de inte-ração (celulares, PDA, etc).
O dispositivo Ginga deve ter acesso a fluxos de
Figura 1 - Arquitetura em alto nível do middleware Ginga
vídeo, áudio, dados e outros recursos de mídia, que devem ser transmitidos através do ar, cabo, satélite ou através de redes IP. As informações recebidas devem ser processadas e apresentadas aos teles-pectadores [8][12].
O telespectador pode interagir com o dispositi-vo Ginga através de dispositidispositi-vos de interação que podem conter componentes de software Ginga, de forma que o dispositivo de interação possa enviar informações para o dispositivo Ginga utilizando as funcionalidades providas na especificação Ginga, ou seja, estes componentes de software que po-dem ser instalados nos dispositivos de interação permitem que as funcionalidades dos mesmos se-jam exploradas, utilizando funcionalidades da API Ginga-J, por aplicações nos dispositivos Ginga (re-ceptores de televisão digital). Para que um disposi-tivo de interação possa ser utilizado ele deve estar registrado com o dispositivo Ginga e durante esse processo o dispositivo de interação pode receber o componente de software necessário para viabilizar a comunicação com o dispositivo Ginga.
Como resposta à informação enviada pelo te-lespectador, o dispositivo de Ginga deve apresen-tar a saída de vídeo e áudio utilizando seu próprio monitor e alto-falantes ou os dos dispositivos de in-teração. Um único dispositivo pode ter capacidade de entrada e saída simultâneas.
Por exemplo, um dispositivo de interação pode ser um PDA conectado à plataforma Ginga através de uma rede sem fio. Utilizando tal dispositivo de interação, um telespectador pode enviar comandos (eventos de usuário) à plataforma através do tecla-do PDA e os aplicativos da plataforma podem en-viar conteúdo visual para ser apresentado na tela do PDA.
Um dispositivo de interação pode também ter capacidades de captura e reprodução de som, de forma que o telespectador possa enviar fluxos de áudio e vídeo para o dispositivo Ginga, utilizando os dispositivos de interação que dêem suporte a essa funcionalidade.
Vários telespectadores podem interagir com a plataforma Ginga, simultaneamente. Nesse caso,
cada telespectador pode ter um dispositivo de inte-ração e a plataforma deve distinguir os comandos enviados por e para cada dispositivo. O dispositivo Ginga pode também enviar informações para os transmissores de conteúdo quando da existência de um canal de retorno (conexão com a Internet, por exemplo).
InovAções do GInGA-J
Quando o governo brasileiro guiou as pesquisas no desenvolvimento do middleware de referência para a Televisão Digital Brasileira, ele determinou alguns requisitos importantes a serem preenchi-dos. Esses requisitos foram em sua maioria ba-seados em algumas particularidades do contexto social brasileiro. Por exemplo, apenas 32,1 milhões de pessoas têm acesso à Internet, o que represen-ta 21% da população brasileira - o governo brasilei-ro definiu então que a televisão digital deveria ser uma ferramenta para a inclusão digital, uma vez que a televisão está presente em 91% dos lares brasileiros.
Durante o desenvolvimento do middleware pro-cedural de referência para o Sistema de TV Digital Brasileiro foram conduzidos muitos estudos sobre as principais soluções de middleware para TV digital adotadas mundialmente e, uma vez que a maioria das especificações estava baseada nas especifica-ções do GEM[9] e do J.202, ficou claro que alguns requisitos não seriam alcançados, uma vez que o contexto europeu (que guiou o desenvolvimento do MHP[10]) é muito diferente do brasileiro.
As funcionalidades inovadoras do Ginga-J, pro-vidas por suas APIs, permitem o desenvolvimento de aplicações avançadas, explorando a integração com outros dispositivos tais como telefones celu-lares, PDAs, etc. Essa integração foi motivada por um outro número: o Brasil correntemente possui 79,5 milhões de telefones celulares. Um telefone celular pode ser utilizado como um canal de retorno para o ambiente de TV, ou usado como um controle remoto, ou ainda como um dispositivo de interação (para responder a enquetes de maneira individual,
por exemplo), etc. Uma vez que essas funcionali-dades são todas implementadas utilizando protoco-los comuns tais como Bluetooth, USB, Wi-Fi, etc., o Ginga é compatível com diversos dispositivos.
A ApI de InteGrAção coM dIsposItI-vos
A API de Integração de Dispositivos agrega ao Ginga funcionalidades relacionadas à maneira como é feita a interação dos usuários com o recep-tor de TV Digital A API integra as especificações do Ginga-J e foi completamente idealizada e espe-cificada pelo grupo de trabalho responsável pelos estudos do middleware para o Sistema Brasileiro de TV Digital. Não existe nenhuma especificação de middleware no mundo [9][10][13][14] que ofere-ça funcionalidades equivalentes, sendo o Ginga o primeiro middleware que integra o receptor de TV Digital ao modelo HAN (Home Area Network).
As funcionalidades inovadoras oferecidas pela API permitem o uso de diversos dispositivos de interação para comunicação com o receptor que hospeda o middleware Ginga e viabilizam que as aplicações interativas utilizem os recursos disponí-veis nesses dispositivos. Tais dispositivos devem possuir um componente (módulo) do Ginga insta-lado – uma pequena parte móvel do Ginga que é responsável por gerenciar o protocolo de comuni-cação entre a instância Ginga no receptor de TV digital e o componente do Ginga no próprio dispo-sitivo. Dentre os possíveis dispositivos podemos citar celulares, PDAs, computadores portáteis e virtualmente qualquer outro dispositivo móvel com capacidade de processamento e comunicação; podemos imaginar “controles remotos avançados” compatíveis com o Ginga.
Para que os dispositivos possam ser efetiva-mente utilizados pelo Ginga eles precisam estar re-gistrados junto ao middleware. O registro deve ser feito pela própria interface do sistema, que deve permitir a conexão de dispositivos através de dife-rentes redes: Bluetooth, wi-fi, infra-vermelho, USB entre outras, ficando a critério do desenvolvedor
do receptor decidir que meios de conexão estarão disponíveis. O registro junto ao middleware só é possível para dispositivos que já possuem o mó-dulo Ginga instalado, porém o processo de insta-lação também pode ser realizado pela interface do sistema: o componente móvel do Ginga pode ser um Midlet num celular com tecnologia Java ou uma aplicação Symbian para dispositivos com sistema operacional Symbian, e o módulo móvel do Ginga pode ser automaticamente transferido do receptor de TV digital para o dispositivo onde o componente deve ser instalado.
Uma vez que um dispositivo esteja registrado junto ao Ginga (conectado) sua interação com o mesmo pode ser feita de forma automática: os re-cursos presentes no dispositivo, como teclado, tela, microfone, câmera, alto-falantes e outros, estarão disponíveis para as aplicações através da API de Integração de Dispositivos do Ginga. Como exem-plo de uso simples, podemos conectar um celular ao Ginga e passar a usar o seu teclado como con-trole remoto e dispor de suas funcionalidades bá-sicas – troca de canal, controle do volume do som, etc; em um outro caso, uma aplicação interativa em execução poderá dispor de uma segunda tela de exibição (a tela do celular), que pode ser utilizada para apresentar ao usuário informações adicionais às exibidas na tela da televisão.
Os recursos dos dispositivos disponíveis para as aplicações dependem dos dispositivos conec-tados com o receptor – caso um celular possua câmera, será possível, por exemplo, que uma apli-cação requisite a captura de uma imagem de tal dispositivo. A API dispõe de métodos para consulta de quais recursos estão disponíveis em cada dis-positivo conectado.
A API de Integração de Dispositivos oferece a funcionalidade de identificar a origem de cada in-teração, relacionando-a a cada dispositivo indivi-dualmente. Essa característica viabiliza aplicações multiusuário.
Uma aplicação simples que pode explorar essa característica seria um Quiz (questionário). Tal apli-cação comumente espera a resposta do usuário
para cada pergunta por meio do clique no contro-le remoto (ou de qualquer dispositivo conectado, caso a aplicação esteja sendo executada no Gin-ga), e então pula para a próxima pergunta; ao final a pontuação do usuário é apresentada. No Quiz multiusuário, utilizando as APIs Ginga, é possível se identificar qual dispositivo originou cada respos-ta para o questionário, passando para as próximas perguntas apenas quando todos dispositivos indivi-dualmente respondessem a cada pergunta. Cada dispositivo representaria um usuário único da apli-cação, e esta controla a pontuação de cada um desses usuários individualmente, e ao final do Quiz a pontuação de cada um seria exibida – inclusive nas telas dos dispositivos.
A Especificação
A especificação já está disponível juntamente com a Norma Ginga-J, atualmente em consulta pú-blica da Associação Brasileira de Normas Técnicas (ABNT). Apesar das funcionalidades avançadas presentes na API, ela é bastante simples, peque-na e apresenta uma interface familiar às interfaces já utilizadas para a construção de Xlets – algumas funcionalidades foram baseadas no Havi[7] e os desenvolvedores provavelmente não encontrarão problemas para usar a nova API e, assim, incre-mentarem suas aplicações.
A API especifica apenas um pacote, o pacote br.org.sbtvd.interactiondevices, cujas classes com-ponentes serão detalhadas a seguir:
a) Classe GRemoteDeviceManager
A classe GRemoteDeviceManager define um objeto que deve administrar todas as conexões com os dispositivos de interatividade registrados com o Ginga.
Os métodos públicos disponíveis são:
static GRemoteDeviceManager getInstance ()
Este método retorna um objeto GRemoteDeviceManager.
GRemoteDevice[] getActiveDeviceList() Este método retorna um array conten-•
•
do objetos GRemoteDevice referenciando cada um dos dispositivos de interatividade registrados com o Ginga.
b) Classe GRemoteDevice
A classe GRemoteDevice define um objeto que deve ser uma representação abstrata de um dispo-sitivo de interação. Essa classe oferece métodos que possibilitam a recuperação de informações acerca dos dispositivos registrados (tipo do dispo-sitivo, funcionalidades disponíveis, etc.), bem como explorar as funcionalidades disponíveis do mesmo (utilizar recursos de gravação de áudio, vídeo, cap-tura de imagens, etc.).
As constantes públicas estáticas presentes na classe GRemoteDevice são:
int KEYBOARD_FACILITY
Um valor inteiro que representa a fun-cionalidade de teclado de um dispositivo de interação.
int SCREEN_FACILITY
Um valor inteiro que representa a fun-cionalidade de tela de um dispositivo de interação.
int SOUND_CAPTURE_FACILITY
Um valor inteiro que representa a fun-cionalidade de captura de áudio de um dispositivo de interação.
int SOUND_PLAYER_FACILITY
Um valor inteiro que representa a fun-cionalidade de reprodução de áudio de um dispositivo de interação.
int PICTURE_CAPTURE_FACILITY Um valor inteiro que representa a fun-cionalidade de captura de imagens de um dispositivo de interação.
int VIDEO_CAPTURE_FACILITY
Um valor inteiro que representa a fun-cionalidade de captura de vídeo de um dispositivo de interação.
int VIDEO_PLAYER_FACILITY
Um valor inteiro que representa a fun-cionalidade de reprodução de vídeo de um dispositivo de interação. • • • • • • •
int DIALING_FACILITY
Um valor inteiro que representa a fun-cionalidade de efetuar ligações telefônicas de um dispositivo de interação.
Os métodos públicos da classe GRemoteDevi-ce são:
int getID()
Este método retorna um inteiro repre-sentando o identificador de um dispositivo de interação.
String getDescription()
Este método retorna uma string (ca-deia de caracteres) contendo a descrição do dispositivo de interação.
int[] getFacilities()
Este método retorna um vetor de intei-ros onde cada item representa uma fun-cionalidade suportada pelo dispositivo. String getParameter(String name)
Este método recebe uma string con-tendo um mnemônico para um parâmetro (característica) relacionada a um disposi-tivo de interação (por exemplo, a área da tela em pixels representado pelo mnemô-nico “screen_area”) e retorna o valor cor-respondente em uma String (por exemplo “640x480”). Estes parâmetros (e seus res-pectivos mnemônicos) dependem do dis-positivo de interação em questão.
boolean isActive()
Este método retorna um valor boolea-no (verdadeiro ou falso) representando o estado do dispositivo: verdadeiro (true) se o dispositivo estiver ativo, falso (false) se o dispositivo estiver inativo ou não regis-trado com o Ginga.
void addActionListener(GRemoteDeviceA ctionListener lis)
Este método registra o dispositivo em um Listener do tipo GRemoteDeviceActio-nListener (passado como parâmetro). void removeActionListener(HRemoteDevic eActionListener lis)
Este método desregistra o dispositivo • • • • • • • •
de Listener do tipo GRemoteDeviceActio-nListener (passado como parâmetro). int submitFile(java.io.File file) throws java. io.IOException
Este método envia um arquivo (pas-sado como parâmetro) para o dispositivo. O método retornará um valor inteiro igual ao tamanho do arquivo em bytes em caso de sucesso ou -1 (menos um) em caso de falha. Este método pode lançar uma exce-ção do tipo java.io.IOException.
void startAudioRecording() throws IOEx-ception
Este método inicia a captura de áudio no dispositivo. Este método pode lançar uma exceção do tipo java.io.IOException. void stopAudioRecording() throws IOEx-ception
Este método finaliza a captura de áudio no dispositivo. Este método pode lançar uma exceção do tipo java.io.IOException. void startVideoRecording() throws IOEx-ception
Este método inicia a captura de vídeo no dispositivo. Este método pode lançar uma exceção do tipo java.io.IOException. void stopVideoRecording() throws IOEx-ception
Este método finaliza a captura de vídeo no dispositivo. Este método pode lançar uma exceção do tipo java.io.IOException. int takePicture() throws java. io.IOException
Este método dispara a captura de uma fotografia no dispositivo. Este médoto pode lançar uma exceção do tipo java.
io.IOException.
void dialNumber(String number)
Este método faz com que o dispositivo efetue uma ligação telefônica para o nú-mero passado como parâmetro em uma cadeia de caracteres (string). Este méto-do pode lançar uma exceção méto-do tipo java. io.IOException. • • • • • • •
org.havi.HScene getHScene()
Este método retorna um objeto do tipo org.havi.HScene, relativo ao dispositivo, de forma que elementos de interface pos-sam ser manipulados no objeto HScene de cada dispositivo de interação.
c) Interface GRemoteDeviceActionListener A interface GRemoteDeviceActionListener deve conter métodos que devem ser implementados por qualquer objeto que deva ser notificado sobre even-tos relacionados às atividades dos dispositivos de interação registrados com o Ginga.
O método público que deverá ser implementa-do:
void notifyDeviceEvent(GRemoteEvent event)
Este método notifica o objeto que im-plementa a interface GRemoteDevice
ActionListener acerca de eventos que
ocorreram nos dispositivos, através da passagem de um objeto GRemoteEvent como parâmetro.
d) Classe GRemoteEvent
A classe GRemoteEvent descreve um objeto que representa um evento relacionado a um dis-positivo de interação registrado com o Ginga. Este objeto encapsula dados relacionados ao evento.
As constantes públicas estáticas presentes na classe GRemoteEvent são:
int AUDIO_REQUEST
Um valor inteiro que define que o even-to está relacionado a uma requisição por áudio e contém o estado dessa requisição encapsulado.
int VIDEO_REQUEST
Um valor inteiro que define que o even-to está relacionado a uma requisição por vídeo e contém o estado dessa requisição encapsulado.
int PICTURE_REQUEST
Um valor inteiro que define que o even-to está relacionado a uma requisição por •
•
•
•
•
imagem e contém o estado dessa requisi-ção encapsulado.
int FILE_TRANSFER
Um valor inteiro que define que o even-to está relacionado a uma requisição por transferência e contém o estado dessa re-quisição encapsulado.
int NUMBER_DIALED
Um valor inteiro que define que o even-to está relacionado ao estabelecimeneven-to de uma ligação telefônica (por parte do dis-positivo de interação) e contém o estado dessa requisição encapsulado.
int AUDIO_DATA
Um valor inteiro que define que o even-to possui dados de áudio encapsulados. int VIDEO_DATA
Um valor inteiro que define que o even-to possui dados de vídeo encapsulados. int PICTURE_DATA
Um valor inteiro que define que o even-to possui uma imagem encapsulada. int KEY_DATA
Um valor inteiro que define que o even-to possui um eveneven-to de teclas encapsula-do.
Os métodos públicos da classe GRemoteEvent são:
Object getSource()
Este método retorna um Object re-ferenciando o dispositivo de interação (GRemoteDevice) que foi a fonte do even-to em questão.
int getType()
Este método retorna um valor inteiro de acordo com o tipo do evento em questão (de acordo com as constantes estáticas definidas na mesma classe).
byte[] getData()
Este método retorna os dados relacio-nados ao evento em questão.
String getDescription()
Este método retorna uma cadeia de caracteres (String) relacionada a uma descrição do evento em questão.
• • • • • • • • • •
boolean isSuccessful()
Este método retorna um valor boolea-no (verdadeiro ou falso) representando o estado do evento: se verdadeiro (true) o evento foi bem-sucedido, falso (false) em caso contrário.
e) Classe GRemoteKeyEvent
A classe GRemoteKeyEvent estende java.awt.
event.KeyEvent, e é relacionada a eventos de
te-clas originados em dispositivos de interatividade. Sua utilização é feita da mesma maneira como nos eventos awt normais, bastando fazer um
downcas-ting quando necessário.
Os métodos públicos da classe GRemoteKeyE-vent são:
GRemoteDevice getSourceDevice() Este método retorna um objeto
GRe-moteDevice referenciando o dispositivo
de interação que foi a fonte do evento em questão.
f) Classe GRemoteUserEvent
A classe GRemoteUserEvent estende org. dvb.event.UserEvent, e é relacionada a eventos do usuário originados em dispositivos de interatividade.
Os métodos públicos da classe GRemoteUse rEvent são:
GRemoteDevice getSourceDevice() Este método retorna um objeto GRe-moteDevice referenciando o dispositivo de interação que foi a fonte do evento em questão.
Impacto na adaptação de aplicações GEM Um forte requisito considerado durante a fase de especificação e, posteriormente nas primeiras implementações de referência, era a de deixar sua interface a mais familiar possível, além de garantir que as aplicações existentes possam vir a utilizar a API Ginga com pouco impacto na sua reengenha-ria – poucas chamadas devem ser adicionadas ao código da aplicação.
•
•
•
A forma como os eventos de usuário são cap-turados pela aplicação é idêntica à utilizada pelos padrões de middleware compatíveis com o GEM. Seja usando AWT ou a classe UserEvent do siste-ma DVB-MHP, os Xlets existentes precisam apenas fazer um downcasting para as classes equivalentes definidas na API e, assim, poderão identificar qual dispositivo gerou eventos para a aplicação. Para captura de eventos convencional, nenhuma cha-mada no código precisa ser alterada – apenas para identificação do dispositivo teremos duas linhas de código adicionadas (com relação a uma aplicação GEM), como pode ser visualizado no código fonte de exemplo presente nesse artigo.
Ainda na parte de dispositivos, a notificação de atividade dos mesmos é feita através do uso de ouvintes (listerners), o que facilita o trabalho do de-senvolvimento já que essa estratégia é familiar aos desenvolvedores Java[11].
conclusão
O presente artigo descreveu as definições do
middleware Ginga que permitem o
desenvolvi-mento de aplicações de TV Digital multiusuário e multidispositivo através da conexão do receptor de TV com dispositivos móveis, em uma HAN (Home
Area Network). Utilizando esses novos recursos,
uma nova gama de aplicações em TV se torna fac-tível, visto que a interatividade na televisão deixa de ser a experiência individual oferecida pelos sis-temas de TV digital atuais e assume a coletividade que é inerente ao ambiente televisivo.
BIBlIoGrAFIA
[1] SOUZA FILHO, Guido Lemos de; LEITE, Luiz Eduardo Cunha; BATISTA, Carlos Edu-ardo Coelho Freire. Ginga-J: The
Proce-dural Middleware for the Brazilian Digital TV System. In: ______ Journal of the
Brazilian Computer Society. No. 4, Vol. 13. p.47-56. ISSN: 0104-6500. Porto Alegre, RS, 2007.
[2] SOARES, Luiz Fernando Gomes; RODRI-GUES, Rogério Ferreira; MORENO, Márcio Ferreira. Ginga-NCL: the
De-clarative Environment of the Brazilian Digital TV System. In: ______ Journal
of the Brazilian Computer Society. No. 4, Vol. 13. p.37-46. ISSN: 0104-6500. Porto Alegre, RS, 2007.
[3] ITU Recommendation J.200:2001, Worldwide
common core – Application environ-ment for digital interactive television services.
[4] ITU Recommendation J.201:2004,
Harmoniza-tion of declarative content format for interactive television applications.
[5] ITU Recommendation J.202:2003,
Harmoniza-tion of procedural content formats for interactive TV applications.
[6] Sun Microsystems, Java TV API, <http://java. sun.com/products/javatv/>.
[7] HAVi Level 2 Graphical User-Interface:2006,
Specification of the Home Audio/Vi-deo Interoperability (HAVi) Architectu-re. HAVi, Inc. 2001. <http://www.havi.
org>.
[8] DAVIC 1.4:1998, Part 2 – DAVIC Specification
Reference Models and Scenarios,
<http://www.davic.org>.
[9] DVB Document A103 – Globally Executable
MHP (GEM) Specification 1.1. DVB
Bluebook, 2007. <http://www.mhp. org/mhp_technology/gem/a103r1. tm3567r1.GEM1.1.1.pdf>
[10] TS 102 812:2003, Digital video broadcasting
(DVB) multimedia home platform
(MHP).
[11] Sun Microsystems, Java Media Framework API (JMF), <http://java.sun.com/products/ java-media/jmf/index.jsp>
[12] ARIB STD-B10:2004, Service information for
digital broadcasting system.
[13] ATSC Standard:2005, Advanced Common
Ap-plication Platform (ACAP)
[14] CableLabs:2005, OpenCable Application
Pla-tform Specification – OCAP 1.0 Pro-file.
Lincoln David Nery e Silva é aluno do curso de mestrado em Informática na Universidade Federal da Paraíba (UFPB). Trabalha há quatro anos com projetos de pesquisa acadêmicos em Vídeo e TV Digital. Atuou no projeto FlexTV, FlexTV, cuja jun-ção com o MAESTRO originou o Ginga, padrão de
Middleware adotado no Sistema Brasileiro de TV
Digital. Atualmente é membro do Grupo de Traba-lho de TV Digital da RNP e trabalha com o desen-volvimento do middleware Ginga para diversas pla-taformas - lincoln@lavid.ufpb.br
Carlos Eduardo Coelho Freire Batista é aluno do curso de mestrado em Informática na Universidade Federal da Paraíba (UFPB). Trabalha há quatro anos com projetos de pesquisa em Vídeo e TV Di-gital. Atuou como gerente de Qualidade e Processo no projeto FlexTV, cuja junção com o MAESTRO originou o Ginga, padrão de Middleware adotado no Sistema Brasileiro de TV Digital. Atualmente é membro do Grupo de Trabalho de TV Digital da RNP e trabalha no projeto de redação da Norma Brasileira de TV Digital Terrestre (middleware pro-cedural) - bidu@lavid.ufpb.br
Luiz Eduardo Cunha Leite é graduado em Enge-nharia de Computação pela Universidade Federal do Rio Grande do Norte (UFRN) e mestre em Sis-temas e Computação pela mesma universidade. Atualmente é aluno de doutorado na Universidade Federal de Pernambuco (UFPE). Foi o responsável pelo gerenciamento técnico do projeto FlexTV, que resultou na proposta do middleware Ginga, adota-do como padrão no Sistema Brasileiro de Televisão Digital - leduardo@lavid.ufpb.br
Guido Lemos de Souza Filho é professor do De-partamento de Informática da Universidade Fede-ral da Paraíba (UFPB). Concluiu o doutorado em 1997, na Pontifícia Universidade Católica do Rio de
Janeiro (PUC-Rio). É coordenador do Laboratório de Aplicações de Vídeo Digital da UFPB, onde são desenvolvidas aplicações nas áreas de televisão digital, ambientes virtuais colaborativos e servido-res de vídeo. É um dos servido-responsáveis pela defini-ção do middleware Ginga, adotado como padrão no Sistema Brasileiro de Televisão Digital -
guido@lavid.ufpb.br
Laboratório de Aplicações de Vídeo Digital – LAViD
Departamento de Informática – Universidade Fede-ral da Paraíba (UFPB).
