Desenvolvimento de programas de TVDI explorando as
funções inovadoras do GINGA-J
Lincoln David Nery e Silva
LAVID/Laboratório de Aplicações de
Vídeo Digital UFPB
Cidade Universitária - João Pessoa -
PB - Brasil - CEP - 58059-900
+55 (083) 3216-7093 - Ramal 26
lincoln@lavid.ufpb.br
Tatiana Aires Tavares
LAVID - Departamento de Ciência da
Informação UFPB
Cidade Universitária - João Pessoa -
PB - Brasil - CEP - 58059-900
+55 (083) 3216-7093 - Ramal 26
tatiana@lavid.ufpb.br
Guido Lemos de Souza Filho
LAVID/Laboratório de Aplicações de
Vídeo Digital UFPB
Cidade Universitária - João Pessoa -
PB - Brasil - CEP - 58059-900
+55 (083) 3216-7093 - Ramal 26
guido@lavid.ufpb.br
ABSTRACT
The specification of Brazilian DTV middleware Ginga allows the incorporation of new functionalities using the Device Integration API. In this paper, we present a Ginga overview and, in particular, Ginga-J, we detail the used API and discuss different application scenarios of this API. These scenarios address multimedia resources and multiuser support. Finally, we present the obtained results.
RESUMO
No panorama nacional, a especificação do middleware Ginga permite a incorporação de novas funcionalidades através da API de Integração de Dispositivos, explorada neste artigo. Neste artigo, apresentamos uma visão geral do middleware Ginga e, em especial do Ginga-J, detalhamos a API de Integração de Dispositivos e, ainda, discutimos diferentes cenários de uso para essa API abordando recursos multimídia e suporte multiusuário. Por fim, apresentamos os resultados obtidos através da implementação de aplicações piloto.
Categories and Subject Descriptors
H.5.4 [Hypertext/Hypermedia]: Architectures, navigation, theory, user issues.
General Terms
Design, Experimentation, Human Factors, Standardization.
Keywords
TV Digital, Dispositivos Móveis, Ginga.
1. INTRODUÇÃO
Um sistema básico de Televisão Digital (TVD) consiste de uma estação transmissora, um meio físico sobre o qual o sinal é transmitido, e um receptor (o STB) responsável por receber o sinal transmitido, decodificá-lo e exibi-lo.
Como a transmissão é feita através de um fluxo de bits, há a possibilidade de se transmitir uma maior quantidade de informação, em comparação ao sistema analógico. Isso é possível principalmente graças ao desenvolvimento de técnicas de compressão, principalmente no vídeo [1].
A aplicação de técnicas de multiplexação no sinal de TV Digital permite que, adicionalmente aos fluxos de áudio e vídeo tradicionais do ambiente de televisão, sejam incluídos um ou mais fluxos de dados. Dentre as possibilidades para fluxos de dados
podemos citar: teletexto, informações sobre a programação do canal, além código executável (aplicações). É esta possibilidade de transmitir dados binários que codificam aplicações, que torna possível a concepção e funcionamento da TV Digital Interativa. A possibilidade de executar a mesma aplicação em dispositivos diferentes, de diferentes fabricantes e com diferentes capacidades de processamento, é viabilizada pela adoção de um middleware comum, que pode ser definido como uma camada de software que abstrai as características específicas de hardware da plataforma. Além de definir as possibilidades para cada sistema interativo de TV, o middleware é responsável pela padronização dessas capacidades. Ao ser executado, o middleware disponibiliza para os desenvolvedores uma máquina virtual que pode ser programada através de interfaces de programação padronizadas (APIs, do inglês Application Programming Interfaces).
Os principais projetos de middleware aberto são o Multimedia Home Plataform (MHP), do europeu Digital Video Broadcast (DVB), além dos americanos Digital TV Applications Software Enviroment (DASE), OpenCable Application Platform (OCAP), Advanced Common Application (ACAP), e o japonês ARIB. Mais recentemente o Brasil decidiu por especificar e usar um middleware próprio, o Ginga [3] [2].
O projeto do Ginga teve como meta refletir as ansiedades e necessidades requeridas pela sociedade brasileira, no que tange seu ambiente de televisão digital. Este projeto foi conduzido com base no levantamento dessas necessidades e na idealização de novas funcionalidades. Uma dessas idéias é explorada neste trabalho: que é a API de Integração que permite a interação entre o usuário e a televisão por meio de dispositivos móveis, o que torna possível o desenvolvimento de aplicações interativas multidispositivo e multiusuário [4] [7].
Neste artigo abordamos a utilização da API de Integração do Ginga-J em diferentes cenários os quais exploram as novas funcionalidades proporcionadas pela incorporação de dispositivos móveis como recursos multimídia e suporte multiusuário.
2. ARQUITETURA DO GINGA-J
Em termos de arquitetura, o Ginga é composto por dois ambientes para processamento de aplicações distintos: uma máquina de apresentação e uma máquina de execução. A máquina de apresentação é responsável pelas aplicações declarativas que fazem uso da API Ginga-NCL [5]. A máquina de execução é responsável pelas aplicações procedurais, que são desenvolvidas utilizando a API Ginga-J [6], que é a API baseada em Java, onde
o presente trabalho se insere. A Figura 1 ilustra a arquitetura e os componentes do Ginga.
Figura 1. Arquitetura do Ginga.
Alguns requisitos importantes identificados no contexto brasileiro não encontram funcionalidade correspondente nas definições estabelecidas internacionalmente em padrões de middleware para TV Digital. Para poder preencher os requisitos específicos brasileiros e ainda manter compatibilidade internacional com as APIs do GEM, o Ginga baseia-se em três conjuntos de APIs denominadas: Azuis, Amarelas e Verdes (ver Figura 2).
As APIs Verdes (exportação) são as APIs compatíveis com o GEM. Desta maneira, as aplicações que utilizam apenas as APIs Verdes podem ser executadas em middleware Ginga, MHP, OCAP, ACAP e B.23. Esse conjunto de APIs é composto pelos pacotes Sun JavaTV, DAVIC, HAVi e DVB, todos incluídos na especificação da estrutura do GEM.
As APIs Amarelas (inovação adaptável) são extensões propostas para satisfazer os requisitos brasileiros específicos que possam ser implementados através do uso de um adaptador de software que use as APIs Verdes. Assim, as aplicações que fazem uso das APIs Verdes e Amarelas, somente podem ser executadas em MHP, ACAP, OCP e B.23 caso o adaptador de software necessário seja transmitido e executado junto com a aplicação.
Por fim, as APIs Azuis (inovação) são aquelas que não são diretamente compatíveis em software com as APIs do GEM. Em outras palavras, essas APIs somente serão executadas nos ambientes com middleware Ginga e representam a inserção de funcionalidades não encontradas em outros middlewares.
O conjunto de APIs Azuis do Ginga-J inclui uma API de Integração de Dispositivos (tema desse trabalho), que permite ao receptor de TV digital comunicar-se com qualquer dispositivo que possua uma interface compatível (sobre cobre, como Ethernet ou PLC; ou sem fio, como infravermelho ou Bluetooth), que possa
ser utilizado como um dispositivo de entrada ou saída.
3. CENÁRIOS DE USO
A API de Integração de Dispositivos viabiliza a incorporação de novas funcionalidades às aplicações de TVDI, onde destacamos dois importantes cenários de uso: desenvolvimento de aplicações com suporte a recursos multimídia e o desenvolvimento de aplicações com interação simultânea de múltiplos usuários em um único receptor [4].
No primeiro caso são explorados os recursos de captura e exibição de diferentes tipos de mídia oferecidos atualmente pela maioria dos dispositivos móveis, como os celulares e PDAs.
Figura 2. APIs do Ginga-J.
Devido à forma como foi especificada a API de Integração de Dispositivos, cada interação do dispositivo móvel com o Ginga é recebida e tratada da mesma forma como é feita com o controle remoto. Percebeu-se então que a comunicação entre o dispositivo e o middleware poderia trazer dados binários que representassem tanto teclas como som, vídeo, imagem, posicionamento GPS ou outros tipos de informação. Essa possibilidade viabilizou a integração de um dispositivo capaz de capturar diferentes tipos de mídia com as TVs.
A API de Integração não restringe a quantidade de dispositivos móveis conectados ao aparelho de TV, dessa forma as aplicações contam com a possibilidade de se comunicar com mais de um dispositivo simultaneamente. Adicionalmente, a aplicação é capaz de identificar por qual dispositivo cada interação foi realizada. Essa característica torna possível que aplicações de TVDI interajam simultaneamente com mais de um usuário, viabilizando o desenvolvimento de aplicações multiusuário, nosso segundo cenário.
É importante ressaltar que normalmente as aplicações multiusuário utilizam um servidor de backend (ou retaguarda) para receber a interação de cada receptor, mixar, e enviar o resultado para eles. No nosso caso, estamos falando de aplicações multiusuário que são executadas localmente em um único receptor. Essa contribuição é importante no ambiente residencial, uma vez que assistir televisão é normalmente uma experiência coletiva [8].
Devido a possibilidade de identificar individualmente a interação proveniente de cada dispositivo móvel, é possível usar essa mesma característica para implementar um comportamento Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Conference’04, Month 1–2, 2004, City, State, Country.
baseado em perfis. Podemos imaginar, por exemplo, que ao utilizar seu celular para trocar de canal, o receptor perceba qual dispositivo fez a interação e, automaticamente, configure o receptor de TV com preferências de cor, volume e outras gravadas a partir de interações anteriores do dispositivo identificado. Essa característica também foi observada por Roibás [10].
4. API PROPOSTA
As funcionalidades inovadoras oferecidas pela API de Integração de Dispositivos 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 instalado – uma pequena parte móvel do Ginga que é responsável por gerenciar o protocolo de comunicação entre a instância Ginga no receptor de TV Digital e o componente do Ginga no próprio dispositivo. 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 efetivamente utilizados pelo Ginga eles precisam estar registrados 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 diferentes 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 instalação também pode ser realizado pela interface do sistema: o componente móvel do Ginga pode ser um Midlet1 num celular com tecnologia Java ou uma aplicação Symbian2 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 middleware Ginga (conectado) sua interação com o mesmo pode ser feita de forma automática: os recursos presentes no dispositivo, como teclado, tela, microfone, câmera, auto-falantes e outros, estarão disponíveis para as aplicações através da API de Integração de Dispositivos do Ginga.
Como exemplo de uso simples, podemos conectar um celular ao Ginga e passar a usar o seu teclado como controle 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) para exibição de parte sua interface.
Os recursos dos dispositivos disponíveis para as aplicações dependem dos dispositivos conectados com o receptor – caso um
1
Midlet é nome dado a aplicações Java provenientes da plataforma J2ME para dispositivos com capacidade reduzida, como por exemplo, os celulares.
2
Symbian é uma plataforma para desenvolvimento de aplicações para dispositivos móveis oriunda de um consórcio de empresas fabricantes de celulares, como: Nokia, Motorola e Sony Ericson, entre outras.
celular possua câmera, será possível, por exemplo, que uma aplicaçã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 dispositivo conectado.
A API de Integração de Dispositivos oferece a funcionalidade de identificar a origem de cada interação, relacionando-a a cada dispositivo individualmente. Essa característica viabiliza aplicações multiusuário.
Uma aplicação simples que pode explorar essa característica seria um Quiz (questionário). Tal aplicação comumente espera a resposta do usuário para cada pergunta por meio do clique no controle remoto (ou de qualquer dispositivo conectado, caso a aplicação esteja sendo executada no Ginga), e então exibe 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 resposta para o questionário, passando para as próximas perguntas apenas quando todos dispositivos individualmente respondessem a cada pergunta. Cada dispositivo representaria um usuário único da aplicaçã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. Um cenário para utilização de tal facilidade são programas que envolvem a participação do usuário [9].
A especificação foi incorporada à Norma Ginga-J, aprovada em consulta pública da ABNT (Associação Brasileira de Normas Técnicas), porém ainda não publicada. Apesar das funcionalidades avançadas presentes na API, ela é bastante simples, compacta e apresenta uma interface familiar as interfaces já utilizadas para a construção de Xlets. Algumas funcionalidades foram baseadas no Havi e os desenvolvedores provavelmente não encontrarão problemas para usar a nova API e, assim, incrementarem suas aplicações.
A API especifica apenas um pacote, o pacote br.org.sbtvd.interactiondevices, cujas classes componentes são as seguintes: (a) Classe GRemoteDeviceManager; (b) Classe GRemoteDevice; (c) Interface GRemoteDeviceActionListener; (d) Classe GRemoteEvent; (e) Classe GRemoteKeyEvent; (f) Classe GRemoteUserEvent. Na Figura 3 observamos o diagrama de classes UML que detalha a estrutura das classes componentes da API. Maiores detalhes sobre essas classes podem ser encontrados em [4]. Na seção seguinte apresentamos um estudo de casos que demonstra a aplicabilidade dessa API em programas de TVDI. Os casos ora retratados nos ajudam a perceber o que o conjunto de APIs Azuis do Ginga pode oferecer em termos de novas possibilidades de aplicações para programas interativos.
5. ESTUDO DE CASOS
Com a API ora proposta, tornou-se possível o desenvolvimento de aplicações interativas de TV Digital executadas em mais de um dispositivo e com suporte para múltiplos usuários interagindo simultaneamente.
Tais aplicações se destacam por apresentarem maior grau de interatividade, proporcionando ao usuário de TVDI uma experiência mais rica, incluindo o uso de recursos multimídia, quando disponíveis nos dispositivos móveis.
As aplicações demonstradas neste estudo de casos foram desenvolvidas utilizando a API Ginga-J com as modificações necessárias para integração de dispositivos móveis, e são executadas numa implementação de referência do middleware
desenvolvida pelo LAVID no contexto do esforço do SBTVD - o FlexTV [11].
Nessas aplicações utilizamos celulares Nokia com tecnologia Wi-fi e plataforma Symbian. A parte móvel do Ginga executada em cada celular foi desenvolvida em Symbian.
Para descrever de forma mais didática o contexto dessas aplicações utilizamos diagramas de casos de uso UML [12]. É importante salientar que os diagramas apresentados não representam as aplicações em sua plenitude, uma vez que procuramos enfatizar as funcionalidades oferecidas que utilizam a API proposta.
5.1 Uso de Dispositivos Móveis como
Controle-Remoto
A funcionalidade básica e direta conseguida com a API proposta é a utilização dos dispositivos móveis como meio de interagir com o receptor de TV Digital. Ao conectar o dispositivo ao receptor, cada tecla pressionada é interpretada como uma tecla de controle remoto.
Devido a forma como foi especificada essa parte da API, apenas com a adição de novos métodos a classes estendidas do HAVi, e sem nenhuma modificação ao modo de tratamento de eventos das APIs Havi e DVB User, presentes no núcleo comum J.201 [13], o GEM, é possível garantir que as aplicações já existentes permaneçam compatíveis com essa nova funcionalidade de maneira transparente. Ou seja, basta conectar um dispositivo móvel ao receptor e controlar qualquer aplicação já existente com as teclas desse dispositivo de forma automática, nenhum código da aplicação precisa ser modificado para usar a funcionalidade. No entanto, apesar da forma transparente com a qual a API de Integração de Dispositivos trata as aplicações já existentes, devemos observar que a API provê métodos para identificação de qual foi o dispositivo móvel que gerou cada interação, caso a aplicação necessite dessa informação.
De acordo com MIRANDA [8] a utilização de dispositivos móveis, especialmente celulares, como interfaces de acesso as aplicações em TV Digital é uma tendência para substituição do atual controle remoto.
5.1.1 HomeBanking e TOV
No intuito de ilustrar esse primeiro cenário apresentamos duas aplicações-piloto desenvolvidas no LAVID: a TOV (Torcida Virtual) [14] e o Homebanking para TV Digital3.
A aplicação TOV é uma aplicação que recebe comandos de controle remoto de forma transparente, pois ela não diferencia, em sua implementação corrente, qual dispositivo originou o chamado da interação. Sendo assim, a interação com usuário é feita da mesma forma como qualquer implementação utilizando o Havi. Para tanto, basta implementar o seguinte método:
keyPressed(KeyEvent < tecla>) da Interface KeyListener
A aplicação Homebanking, entretanto, precisa diferenciar qual dispositivo está gerando quais interações, pois a aplicação pode gerenciar mais de uma sessão de Homebanking por vez. Uma
3
A apresentação e descrição mais completa dessas aplicações é feita nos próximos cenários, pois cada uma utiliza outros recursos mais avançados da API proposta e especificamente relacionados ao propósito ao qual elas foram concebidas.
sessão é associada a cada dispositivo móvel conectado. Por questões de segurança e de confidencialidade de dados, é um requisito natural da aplicação perceber qual dispositivo gerou o comando para, por exemplo, exibir o saldo em conta, ou executar um comando para transferência de valores.
Figura 3. APIs do Ginga-J.
Para identificar qual dispositivo interagiu com a aplicação, apenas algumas linhas de código precisam ser adicionadas ao método: keyPressed(KeyEvent <tecla>)
Essas linhas de código têm o objetivo de verificar se o objeto KeyEvent é, na verdade, uma implementação da extensão GRemoteKeyEvent proposta; caso positivo, a aplicação saberá que a interação foi originada por um dispositivo móvel, e terá na classe GRemoteKeyEvent um método que identifica o dispositivo. Caso a implementação seja um KeyEvent original, a interação foi originada pelo controle remoto comum.
Como pode ser observado no trecho de código ilustrado na Figura 4, é muito simples identificar qual dispositivo interagiu com a aplicação. Após a identificação, a aplicação pode continuar com o tratamento especifico ao qual se propõe.
if ((tecla instanceof HRemoteKeyEvent)){
HRemoteKeyEvent teclaDisp = (HRemoteKeyEvent) tecla;
int idDispositivo =
teclaDisp.getOriginDevice().getID(); }
Figura 4. Trecho de código para identificação do dispositivo onde uma tecla foi pressionada
Ao especificar essa API para o Ginga-J, uma preocupação sempre presente foi a de garantir simplicidade para o desenvolvedor. Apesar de simples, a identificação de qual dispositivo interage com a aplicação oferece ao desenvolvedor a capacidade de desenvolver novos tipos de aplicações.
5.2 Uso de Recursos Multimídia dos
Dispositivos Móveis
Outra contribuição da API de Integração de Dispositivos foi possibilitar que as aplicações utilizem recursos multimídia
p d m c id in N p m in p c a a C im ( c p A d a p C c c in A p
5
A m e p e e A d o e lo u d spresentes nos dis da API Ginga-J, multimídia de controle remoto. dentifique os ntegrados ao Gin Nesse cenário – podemos destac móveis, que po nterativas, são possuem microfo celulares e PD aproveitadas pe adicional; (c) Al Câmera: muito c magens ou víde e) Rede Telefôn celular, uma liga provedor de Inter A API proposta p dispositivo móve a lista de Faciliti public int[] getFa Cada Facility correspondência classe GRemoteD niciar o uso de c Algumas aplica proposta. As seçõ
5.2.1 TOV
A Torcida Virt multimídia. O c esportes virtualm participantes pod estádio real. A espaço acústico c Figura As principais f diagrama de cas observar que cad estádio virtual p ocalização do us usuários a intera da TOV foi def sentados próximspositivos móvei , percebeu-se qu
forma semelha . A API provê tipos dos dad nga.
de recursos mu car alguns recu
dem ser utiliza eles: (a) Captu fones e capacida DAs possuem elas aplicações lto-falantes: tam comum em celu eos a serem util nica: uma aplica ação para um nú rnet. possui métodos el possui. Essa i ies de um dispos Facilities() dispon é representada entre as várias Device. A classe cada recurso mul ações foram de ões seguintes ap
tual, ou simple conceito da TO mente. Uma vez derão interagir e idéia é dar sup compartilhado.
a 5: Diagrama d
funcionalidades sos de uso UM da participante d para sentar, bem suário é importa ação por meio do
finido que o áu os, virtualmente
is. Durante a fas ue seria possíve ante a uma tec meios para que os capturados ultimídia e disp ursos existentes ados no context ura de áudio: c ade de capturar telas, essas t s para exibiçã mbém presentes ulares hoje em d izados por aplic ação pode gerar úmero de Call C para identificar identificação é p sitivo especifico. nível na classe G a por um inte s constantes def e também possu ltimídia. esenvolvidas pa resentam algum esmente TOV, OV é preenche preenchido o e entre si como se porte a um amb de Casos de Uso da TOV são ML da Figura 5 da TOV deve esc m como um asse ante para limitar
o áudio se dará. udio será ouvid e, implementand e de especificaç el tratar um dad cla capturada d e o desenvolved nos dispositiv ositivos móveis em dispositiv to das aplicaçõ celulares e PDA r áudio; (b) Tel telas podem s ão de conteúd em celulares; ( dia, pode captur cações interativa r, por meio de u Center, ou para u que recursos cad possível coletand . GRemoteDevice eiro, e tem su finidas na própr ui os métodos pa ara testar a A mas delas. é uma aplicaç er um estádio d estádio, as pesso e estivessem nu biente virtual co o UML da TOV apresentadas n 5. Nele podem colher um setor d ento numerado. r com quais outr Na especificaç do pelos usuári do uma espécie ão do do dor vos – vos ões As la: ser do (d) rar as; um um da do ua ria ara API ão de oas um om V. no mos do A ros ão os de cone ac dessas O caso ponto c estádio conecta e seus factível ambien “Enviar conjunt respons usuário do esco A API um celu a dispo móveis localme áudio, b ilustrad HRemote int act audio. if (act que ser }else Figur Como p de inic ouvinte pacote aplicaç ser util método Interfac observa informa cústico. A Figur duas funcionalid de uso “Torcer” central deste ap o virtual. Em o ado pode gerar á vizinhos do está l, é necessário te nte onde o rece r áudio por dis to de servidore sáveis pela cap os participantes. opo do presente t Fig proposta torna ular conectado a ositivos móveis, s com capacida ente. O procedi bem como de co do na Figura 7. eDevice dev = tion = aAction tion == 1){ dev.startAud dev.addActio rá notificado { dev.stopAudi dev.removeAc ra 7: Trecho de áud
pode ser observ ciar a captura do e para os even
de áudio gera ção será notificad
lizados. A notif o void notifyD ce GRemoteDev ado o código ação de um even ra 6 apresenta a dades. ” refere-se a cara plicativo: a poss outras palavras,
áudio que será m ádio. Para que e er algum mecani eptor de TVD e spositivo”). Alé es de mixagem ptura e mixagem Esses servidore trabalho. gura 6: Telas da possível captura ao receptor. Na v o áudio é captu ade de captura
imento para ini oletar o áudio e aDevice; n; //se action dioRecording() onListener(thi da chegada dos ioRecording(); ctionListener(
código para ini dio em um disp vado no trecho d o áudio, a aplic ntos do disposit ado na fase de da e receberá ta ficação dos eve DeviceEvent(GRe viceActionListen necessário pa nto e capturar os tela da TOV pa acterística mais sibilidade de tor o telespectado mixado e retorna essa funcionalida ismo de captura está inserido (c ém disso, é nec m de áudio de m do áudio e es de retaguarda a TOV. ar o áudio, por e versão da TOV c urado de todos a de áudio e r iciar e parar a comandar sua re = 1, então in ; is); //adiciona s pacotes de á (this); iciar e parar a c positivo. de código da Fig cação precisa ad tivo. Dessa form
captura do dis ais pacotes para
ntos ocorrerá p emoteEvent <e ner. Na Figura ara identificar s dados dessa inf
ara execução inovadora e rcer em um or uma vez ado para ele ade se torne do áudio do caso de uso cessário um retaguarda, retorno aos a estão fora exemplo, de com suporte dispositivos reproduzido captura do eprodução é niciar a ouvinte, áudio captura de gura 7, além dicionar um ma, a cada spositivo, a que possam por meio do event>), da 8 pode ser o tipo de formação.
i / p } N in s
5
A m In n g o d a m F E f T c in n p te N p f g a a g p d A in e o p B f e H p e C S p if (event.getTy audioP //audioPlayer é pacotes de áudi Figura 8: informação No momento en nicia a captura servidor de retag5.2.2 Homeb
A aplicação do mesmas operaçõ nternet. Com a na tela da TV po grande maioria d observar o diagr diagrama observ aplicação na TV mesmo aplicativo Figura 9: Diagr Entretanto, a tra feita de forma c TV é, na maiori conta bancária nconveniente, já naquele moment privacidade, qu elespectador ass Na aplicação de proposta nesse t factível ao amb garantir a ques aplicação para t ambiente comum gráfica disponíve podemos ter recu dos dispositivos m Além disso, o fanteragindo com enviar o resultad operação bancári para a tela do dis Buscando a faci forma de escreve escrever na tela T HScene já utiliz para a GRemot específicas para o Cada dispositivo Screen disponív possuiu seu HSc ype() == GRemo Player.addAudio é um objeto de io e os reprod Trecho de códi o de um evento
ntão que o usuá do áudio e inic guarda.
banking
Homebanking ões bancárias en consolidação da ode ser uma opç dos usuários de b rama de casos d vamos que o te V tem a opção d o no celular. rama de Casos d ansferência do b cautelosa. Sabem ia das vezes, co na tela da á que outras pes to. Desse modo, ue só é alcan sistindo à TV numHomeBanking o trabalho para to biente real. Par stão de privaci ela do dispositi m de TVDI on el é a tela da TV ursos de exibição móveis conectad ato da aplicação ela é possível p do do processam
ia, como o sald spositivo em que ilidade para o d er numa tela de TV. Para desenh zada no Havi, e teHScene, clas o funcionamento o móvel conectad vel, indicando q cene relacionado teEvent.AUDIO_ oData(event.get uma classe qu uz.
igo para verifica de dispositivo e ário escolhe um ia a transmissão tem o objetiv ncontradas nos s a TVDI, uma ap ção mais próxim baixa renda. Na de uso para esse
elespectador ao de abrir uma se
de Uso UML do
banco para a tela mos que a exper oletiva. Dessa fo TV pode, mu soas podem esta , é essencial ma nçada se tiver m dado moment ora apresentada, ornamos a aplic ra essa aplicaç idade enviando ivo móvel. Ou nde o único rec V, no Ginga-J co o gráficas extras dos ao receptor d
identificar o di rocessar os com mento (no caso, a
o em conta corr estão.
desenvolvedor, dispositivo é an har na tela usamo entretanto estend
se que contém o remoto.
do, desde que te que possui um o, com suas prop
_DATA){ tData()); ue recebe ar o tipo de e sua coleta. m assento, a TO o do áudio para o de oferecer sites de bancos n plicação de ban ma da realidade Figura 9 podem aplicativo. Nes se logar na su essão para uso d
o HomeBanking a da TV deve s riência de assis forma, acessar su uitas vezes, s ar assistindo a T anter a questão rmos um únic to. , utilizamos a A cação muito ma ção, conseguim o a interface seja, diferente d curso de exibiç om a API propos s, relativos as tel de TV. spositivo que es mandos recebidos a saída de algum rente) diretamen
mais uma vez, náloga a forma d os a mesma clas demos essa clas m funcionalidad enha a Facility d display present priedades gráfic OV a o as na co da mos sse ua do g. ser tir ua ser TV da co API ais mos da do ão sta las stá s e ma nte a de sse sse des de te, cas corresp compon HScene O trec referen opções Com a usufrui de hom diferen mais at podemo HScene GRemote cena.re cena.ad new Fon Color. entrada cena.ad 50, new Color. entrada cena.ad new Fon Color. entrada cena.se cena.re cena.re Figu
5.2.3
A apli funcion disposi Fi Como Digital podem represe 4 Trans para pondentes. O d nentes Havi a es e principal, que é cho de código nciar o HScene da aplicação ho utilização da AP i de uma caracte mebanking mais ncial de mercado trativa e princip os observar na F cena = dev.ge eDevice emoveAll(); dd(new HStatic nt("Tiresias", black, new HDe a de menu na t dd(new HStatic w Font("Tiresiblack, new HDe a de menu na t dd(new HStatic nt("Tiresias", black, new HDe a de menu na t etVisible(true equestFocus(); epaint(); ura 10: Trecho d dispositiv
TV Tunes
cação TV Tun nalidade princip itivo móvel. gura 11: Tela d vimos anteriorm , além do áudio ser multiplexad entam aplicações sport stream: O difusão. desenvolvedor sse HScene, da m é mostrado na te ilustrado na de um disposi omebanking. PI de Integração erística multimíd s privativa. Ess o para esse tipo palmente mais s Figura 11. etHScene(); //d cText("Saldo em Font.BOLD, 11 efaultTextLayou tela cText("Extrato ias", Font.BOLD efaultTextLayou tela cText("Transfer Font.BOLD, 11 efaultTextLayou tela e); ; de código para r vo e adicionar el nes, desenvolvid pal a troca de do Homebankin mente, em um e vídeo dos can dos paralelament s, e dessa forma O fluxo MPEG-2 pode então ad mesma maneira c ela da TV. Figura 10 mo itivo, e exibir de Dispositivos dia para tornar a se ganho é cert o de aplicação q egura e confide dev é um objet m Conta", 1, 1 1), Color.yell utManager()); da Conta", 1, D, 11), Color. utManager()); rência", 1, 1, 1), Color.yell utManager()); referenciar o H lementos a ele. da no LAVID, conteúdo entre ng na TV e no C transport strea nais de TV, flux e. Esses dados m podem conter ar 2 TS multiplexa dicionar os como faz no ostra como o menu de s a aplicação experiência tamente um que se torna encial, como to do tipo , 100, 50, low, //adiciona 1, 100, yellow, //adiciona 100, 50, low, //adiciona HScene do tem como a TV e o Celular. am4 de TV xos de dados muitas vezes rquivos. ado enviadoT m o m tr v n to D u il A d c T tr m d o 1 a f n p d d G F Tomando como multiplexados nu objetivo de trans móveis. Dentre ransferência de vídeos. Adiciona não serão aborda
orna uma manei Digital. Na Figu uso, reduzido, p lustrada a tela da Figura 12: Dia A transferência dispositivo pelo comunicação com Tal aplicação se rabalho. Mais es método submitFi do sistema de arq o arquivo e faz o 14 ilustra a utili arquivos multim fazer o preview necessidade de t pode ser implem dispositivo, como dev.submitFile( GRemoteDevice Figura 14: Trec base a capaci um transport str sferir alguns des esses arquivos conteúdo multim ando a aplicação
ados na nossa v ira de vender con ura 12 podemos para a aplicação a aplicação most agrama de Caso do conteúdo o receptor, e n mo acessório (co tornou possível specificamente, File(java.io.File < quivos da aplica o processamento ização desse m mídia, a aplicaçã do conteúdo di transferir o arq mentada ao utiliz o alto-falantes e Figura 13: Tela (mp3File); // cho de código p o disp idade de se tra ream, a aplicação sses arquivos pa s, o TV Tunes mídia, como rin funcionalidades versão), a aplica nteúdo digital m observar o diag o TV Tunes, e trada na TV. os de Uso UML se dá pela me não utilizando omo a rede do ce
l com a API pro a classe GRemo <file>) que tran ação para o dispo de acordo com método. Além da
ão pode se util iretamente no d quivo em si. Es zar outros recurs
tela. as do TV Tunes /dev é um o para transferir u ositivo. ansmitir arquiv o TV Tunes tem ara os dispositiv s se empenha n ngtones, músicas s de cobrança (qu ação TV Tunes multimídia pela T grama de casos d e na Figura 13 para TV Tunes esma conexão d algum canal elular). oposta no presen oteDevice possui nsfere um arquiv
ositivo, que cole seu tipo. A Figu a transferência d izar da API pa dispositivo, sem sa funcionalida sos multimídia d s. objeto do tip um arquivo par vos m o vos na s e ue se TV de é s. do de nte i o vo eta ura de ara m a de do po ra
5.3 A
Por fim importa de dese A AP simultâ Adicion identifi possíve um des de uma Essa fu apresen pressio adicion interaçã simulta criação determ forma c que ilu seguint5.3.1
A TOV No ent que est torcer a pelo us A ques relacion móvel. áudio p O códi função conecta captura cada um mixage Sendo multius pelo tra5.3.2
O Hom multim multius identifi control disposi Identifi pode g privativ pelo fa cada u aplicaç aplicaç present identifi específAplicações M
m, abordamos ante contribuiçã envolver aplicaçõ I de Integraçã ânea de vários nando a essa c icarem individua el fazer com que stes, criando as a aplicação multi uncionalidade es ntada no item 5. nadas em dispo nalmente, ident ão, além de per aneamente; a AP o de aplicaçõe inar, então, se como o desenvo ustram esse ce tes.TOV
V pode ser vistaanto, atentemos tamos tratando n
ao mesmo temp so dos servidores stão multiusuário nada com a capa E cada um des para o receptor d igo do TOV foi torcer, a ap ados ao recept ar áudio. A aplic m desses dispo em. assim, a TOV suário desenvolv abalho.
Homebankin
mebanking é o mídia, também suário. No cas icação de qual lar uma sessão itivo conectado a icando então a gerenciar sessõ va. Essa funcio ato de assistir TVusuário controla ção, ganhamos ção não interferir
tes. A Figura 1 icar a interação fica para cada um
Multiusuári
um último cen o do trabalho pr ões interativas m ão de Disposi dispositivos mó capacidade a po almente a intera e a aplicação reaj condições nece iusuário. stá intimamente .1. Ao prover m ositivos como te tificar qual d rmitir a conexão PI oferece as ferr es interativas m uma aplicação olvedor a conceb enário serão ap também como u para o fato de não é o fato de q po, essa caracters de back-end. o conseguida com acidade de cone sses dispositivos de TV simultanea concebido de f plicação procur tor de TV que cação requisita e sitivos, e os tra V exemplifica, vida com o uso
ng
outra aplicação possue cara o do Homeban l dispositivo o o de homebank ao receptor de TV interação de ca ões paralelas e onalidade é mu V ser uma exper ando o seu d sessões privad rá na experiênci 15 ilustra como o de um dispo m destes.io
nário onde test roposto, que é a multiusuário. tivos permite óveis ao recepto ossibilidade das ação de cada di aja diferentement ssárias para imp relacionada com meios de identific eclas de control dispositivo orig o de múltiplos ramentas necess multiusuário. O é ou não multi beu. As aplicaç presentadas nas uma aplicação m que a questão m que muitos usuá rística é consegu m o uso da API ctar mais de um s ser capaz de e
amente. forma que, quan ra todos os e possuem cap então a captura d ansmite para o também, uma o da API Ginga que, além do acterísticas de nking, a aplica originou a inte king individual V. ada dispositivo independentes ito interessante riência coletiva; dispositivo para das e a nave a de assistir TV o deve ser o c ositivo e reagir tamos outra a capacidade a conexão or de TVD. s aplicações ispositivo, é te para cada plementação m a que foi car as teclas e remoto e, ginou cada dispositivos sárias para a O que vai iusuário é a ões de teste s subseções multiusuário. multiusuário ários podem uida apenas é local e se m dispositivo enviar o seu ndo ativar a dispositivos pacidade de do áudio em servidor de a aplicação a-J proposta os recursos aplicação ação usa a eração para para cada a aplicação s de forma justamente tendo então a acessar a egação pela dos demais código para r de forma
if ((tecla instanceof HRemoteKeyEvent)){
HRemoteKeyEvent teclaDisp = (HRemoteKeyEvent) tecla; int idDispositivo = teclaDisp.getOriginDevice().getID(); switch (idDispositivo){ case disp1: sessaoDisp[0].newAction(tecla); break; case disp2: sessaoDisp[1].newAction(tecla); break; case disp3: sessaoDisp[2].newAction(tecla); break; }}
Figura 15: Trecho de código exemplificando a identificação do dispositivo onde uma tecla foi pressionada e tratamento de
sessões independentes em dispositivos distintos.
6. CONSIDERAÇÕES FINAIS
Um dos grandes desafios para o desenvolvimento de aplicações para a televisão interativa é o uso do controle remoto como o principal meio de interação. Tal recurso é limitante às aplicações e compromete a usabilidade na TVDI. Para que as aplicações se tornem mais atraentes, alternativas ao controle remoto devem ser analisadas. O uso de dispositivos móveis, como os telefones celulares, é levantado como uma alternativa, uma vez que estes dispositivos são bastante utilizados pela população [10] [8]. Uma das contribuições da API de Integração de Dispositivos é a possibilidade criação de aplicações inovadoras para o atual cenário de aplicações para TVDI. Esse fato se deve as novas características suportadas pela API que foram demonstradas nesse artigo através de diferentes aplicações piloto.
Nossa expectativa é dar prosseguimento a investigação dessas pontencialidades, com a criação de novas aplicações explorando características da API. Dentre as quais sugerimos o desenvolvimento das seguintes aplicações: (a) uma aplicação de controle de grade programação através do reconhecimento do perfil do usuário; (b) jogos educativos multiusuário utilizando os dispositivos móveis em apenas um receptor, o que poderia ser útil em escolas, por exemplo; (c) aplicações de produção e distribuição de conteúdo multimídia em redes domésticas, tendo o receptor como ponto central. Além do cenário de aplicações, a API de Integração de Dispositivos abre novas possibilidades em termos de expansão da API, tanto em funcionalidades, quanto em abrangência de dispositivos móveis compatíveis, onde destacamos: (a) a implementação do componente móvel do Ginga compatível com novos dispositivos móveis, como os PDAs e os controles remotos avançados já existentes no mercado americano [15] [16] [17]; (b) a adição de extensões na API que permita o controle de diferentes recursos numa rede doméstica, tais como luz, temperatura e os eletrodomésticos (Home Automation); (c) a adição de extensões que permita a expansão dos modos de interface atualmente disponíveis, em particular a Realidade Virtual.
7. REFERÊNCIAS
[1] Maior, M. S. TV interativa e seus caminhos. Dissertação (Mestrado profissional em Engenharia de Computação). Campinas : Instituto de Computação, Universidade Estadual de Campinas, 2002.
[2] Morris, S. and Smith-Chaigneau, A. Interactive TV Standards – A Guide to MHP, OCAP and JavaTV. s.l. : Elsevier, Focal Press, 2005.
[3] Fernandes, J., Lemos, G. and Silveira, G. Introdução à Televisão Digital Interativa. Jornada de Atualização em Informática do Congresso da Sociedade Brasileira de Computação. Salvador : SBC, 2004.
[4] Silva, Lincoln David Nery e, et al. Suporte para desenvolvimento de aplicações multiusuário e
multidispositivo para TV Digital com Ginga. T&C Amazônia Magazine. N. 12, ISSN 1678-3824, pp 75-84. Manaus, AM : s.n., 2007.
[5] Soares, L. F. G., Rodrigues, R. F. and Moreno, M. F. Ginga-NCL: the Declarative Environment of the Brazilian Digital TV System. Journal of the Brazilian Computer Society (ISSN: 0104-6500). 2007. pp. n. 4, v. 13. p.37-46.
[6] Souza Filho, G. L. de, Leite, L. E. C. and Batista, C. E. C. F. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. Journal of the Brazilian Computer Society (ISSN: 0104-6500). 2007. pp. n. 4, v. 13. p.47-56. [7] IBGE. Pesquisa Nacional por Amostra de Domicílios.
[Online] 2006.
http://www.ibge.gov.br/home/estatistica/populacao/trabalhoe rendimento/pnad2005/tabsintese.shtm.
[8] Miranda, Leonardo Cunha de. Uma Proposta de Taxonomia e Recomendação de Utilização de Artefatos Físicos de Interação com a TVDI. INTERACT - CLIHC - 2007. 2007. [9] Globo. Big Brother Brazil. Globo.com. [Online]
http://bbb.globo.com/.
[10] Roibás, A.C., Sala, R., Ahmad, S.N.A.S. e Radman, M. Beyond the remote control: Going the extra mile to enhance iTV access via mobile devices & humanizing navigation experience for those with special needs. Proceedings of the 3rd European Conference on Interactive Television. 2005. [11] Leite, L. E. C. et al. FlexTV – Uma Proposta de Arquitetura
de Middleware para o Sistema Brasileiro de TV Digital. Revista de Engenharia de Computação e Sistemas Digitais, v. 2, p 29-50. 2005.
[12] Booch, G., Rumbaugh, J. and Jacobson, I. UML - Guia do Usuário. Rio de Janeiro : Elsevier, 2005.
[13] ITU. ITU Recommendation J.201 – Harmonization of declarative content format for interactive television applications. 2004.
[14] Tavares, Tatiana A., et al. Sharing Virtual Acoustic Spaces over Interactive TV Programs – Presenting “Virtual Cheering” Application. ICME 2004. Taipei, Taiwan : s.n., 2004.
[15] ESPN. ESPN The Ultimate Remote. [Online] http://www.espnremote.com/.
[16] Ricavision. VAVE100 Universal Remote Control. [Online] http://www.ricavision.com/vave100.html.
[17] Logitech. Harmony® One Advanced Universal Remote. [Online]
http://www.logitech.com/index.cfm/remotes/universal_remot es/devices/3898&cl=us,en.
