Meu Primeiro Projeto para TV Digital com Ginga

Meu Primeiro Projeto para TV Digital com Ginga • Introdução O sinal de TV Digital no Brasil aconteceu pela primeira vez no início do mês de Dezembro no ano de 2007. O sinal trafegava sobre o padrão ISDB-TB, uma adaptação do japonês ISDB-T (Integrated Services Digital Broadcasting Terrestrial).

Segundo texto publicado no Telesintese (http://www.telesintese.com.br/index.php? option=com_ content&view=article&id=16409: ha-tres-anos-no-ar-tv-digital-somaavancos-e-problemas&catid=13: plantao&Itemid=1126), que fez um aparato geral de como está TV Digital Brasileira hoje, os pontos positivos são: Atualmente, o sinal digital está presente em 48 cidades do país, além de Brasília, atingindo uma população de 75 milhões de pessoas ou 40% do total dos brasileiros. O sistema Integrated Services Digital Broadcasting Terrestrial, tecnicamente conhecido como ISDB-TB, criado pelo Japão e aperfeiçoado no Brasil, já está presente em mais nove países - Argentina, Chile, Venezuela, Bolívia, Costa Rica, Paraguai, Peru, Equador e Filipinas, com público potencial de 550 milhões de pessoas.

Claro que o processo ainda apresenta algumas falhas, como: O Ginga não está presente na maioria dos conversores vendidos. Os radiodifusores também não encontraram um modelo de negócio que justifique investimentos em aplicativos para esse fim. E, o mais importante, ainda não há uma definição sobre o canal de retorno que dará suporte à interatividade.

A pouca oferta de conversores baratos é outro entrave para expansão da TV digital no Brasil.

Neste pequeno texto não vou tratar questões aprofundadas sobre este padrão, sobre adoção e mercado, por dois grandes motivos: não quero escrever um pocket book e também não tenho competências para tanto.

Bem, o que vou relatar aqui é como construir um aplicativo para TV Digital utilizando para isso o Ginga-NCL. No texto vou apontar links para criar todo o ambiente de desenvolvimento, assim como, mostrar os códigos que utilizei e a explicação de cada tag NCL.

• 1° Passo: Ginga NCL Segundo o site oficial do Ginga (http://www.ginga.org.br/): Ginga® é o nome do Middleware Aberto do Sistema Brasileiro de TV Digital (SBTVD). Ginga é constituído por um conjunto de tecnologias padronizadas e inovações brasileiras que o tornam a especificação de middleware mais avançada e a melhor solução para os requisitos do país.

O Ginga utliza dois subsistemas com dois paradigmas de programaão diferentes: Ginga-J (Procedural) e Ginga-NCL (Declarativo). Veja a Figura 1:

Figura 1: Ginga = Ginga NCL + GingaJ.Fonte: http://www.img.lx.it.pt/~fp/cav/ano2009_2010/Trabalhos_MERC_2010/Artigo_MERC_13/website_ cav/mid_ginga.html

Do lado esquerdo temos o Ginga NCL com suas APIs e seu NCL Formatter. O NCL é uma linguagem declarativa, ou seja, o “programador” informa o que o seu aplicativo deve fazer, sem se importar para a lógica, apenas colando mídias e definindo a interação entre elas.

Do lado direito temos o Ginga-J que é representado pelo Java TV e suas APIs. O GingaJ é a parte procedural do Ginga, onde o programador deve definir passo a passo, em forma de algoritmo, oque seu algoritmo deve fazer.

Além disso, existe uma ponte entre os dois, sendo assim, nada impede que um NCL chame um código LUA, ou seja, misturando a linguagem procedural com declarativa. Porém, não vamos entrar tão a fundo assim nesse texto.

• O Projeto O projeto apresenta um aplicativo para votação entre quatro candidatos ao cargo de presidente da república. Coloquei apenas os quatro mais bem colocados porque estamos trabalhando apenas de forma fictícia.

Ao executar a aplicação o usuário verá a Figura 2:

Figura 2: Tela incial do aplicativo.

Figura 3: Confirmação do voto.

Ao confirmar seu voto o usuário recebe uma confirmação, representada por uma urna eletrônica com a palavra FIM. Veja a Figura 3.

• Ambiente de Desenvolvimento Para configurar meu ambiente de desenvolvimento eu segui o passoa-passo do texto “Como Estruturar seu Ambiente de Desenvolvimento para o Ginga-NCL”. O link está aqui: http://www.peta5.com.br/br/tutoriais/88-comoestruturar-seu-ambiente-de-desenvolvimento-para-o-ginga-ncl.

• Iniciando: Entendendo o NCL O NCL (Nested Context Language) é uma linguagem para construção de documentos hipermídia. Ele prevê interação com o usuário e extensa sincronização entre mídias.

Figura 4: Nós de composição, Nós de conteúdo e Elos. Fonte: NETO

O NCL trabalha basicamente com três entidades, todas representadas na Figura 4: • Nós de Conteúdo: são os nós que representam as mídias propriamente ditas, esses nós podem ser figuras, arquivos de áudio e vídeo, aplicativos LUA, dentre outros. Na Figura 4 esses nós são as seções 1.1, 1.2, 1.3, 2.1 e 2.2 • Nós de Composição: compõe nós de conteúdo. Na Figura 4 temos o Capítulo 1 e 2 como exemplos.

• Elos: ligações entre os nós.

Segundo NETO, para construir um documento hipermídia, é necessário definir o que se quer tocar, onde (em qual região da tela ou dispositivo), como (que volume, com ou sem borda, com que player) e quando (antes/depois de qual mídia ser apresentada ou após qual tecla ser pressionada).

o O que tocar Um dos primeiros passos a ser definido na construção de um documento hipermídia é: quais são as mídias que queremos tocar, ou seja, com quais arquivos iremos trabalhar. Essa mídia pode ser uma imagem, um áudio, um vídeo, um aplicativo LUA, um arquivo HTML ou TXT, dentre outros.

Toda mídia será um nó de conteúdo que estará dentro de um nó de composição.

o Onde tocar Onde tocar é a definição da área da região onde sua mídia irá aparecer.

Vamos estudar dois exemplos. Na Figura 5 temos o aplicativo M.Edu. Percebam que ele ocupa duas áreas. A primeira na parte esquerda, a segunda na parte inferior-central. Através do NCL definimos onde cada mídia, que pode ser um HTML, vai aparecer.

Figura 5: Aplicativo M.Edu. Fonte: http://www.globalexchange.com.br/artigo.asp?txtid=593

No caso da Figura 6, o aplicativo também ocupa duas áreas, uma a esquerda e outra a direita.

Figura 6: Fonte: http://www.grandecoisas.com.br/conversor-digital-com-ginga-%E2%80%93-ainteratividade-chega-para-poucos/

o Como tocar Para definir como tocar é necessário associar uma mídia a uma região, para isso vamos utilizar descritores, que serão vistos na parte prática. Além disso, um descritor pode conter informações definindo parâmetros para exibição de uma mídia, como: volume, bordas, molduras, player, tempo de duração, algum grau de transparência, dentre outros.

o Quando tocar O seu documento hipermídia poderá ter dezenas de mídias, porém, uma delas deverá ser apontada como a porta de entrada do aplicativo, para isso, veremos o conceito de portas posteriormente. Uma porta dá acesso exterior aos nós de conteúdo de um nó de contexto. Veja a Figura 7.

Figura 7: Conceito de portas. Fonte: Neto.

Além disso, veremos também elos que permitem a sincronização entre mídias. Um exemplo: quando o vídeo A parar de tocar, mostra um documento HTML com uma descrição da aplicação.

• Estrutura básica de um documento NCL Um documento NCL apresenta basicamente três partes: • Cabeçalho: Veja a listagem abaixo. <?xml version="1.0" encoding="ISO-8859-1"?> <ncl id="ex1" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">

• Head: Nesta seção são definidas as regiões do documento (onde), os descritores (como) e os elos, representados por conectores (quando). <head> <regionBase> <region ... > <region .../>

<region .../> </region> </regionBase> <descriptorBase> <descriptor .../> </descriptorBase> <connectorBase> <causalConnector id="onBeginStart"> <simpleCondition role="onBegin"/> <simpleAction role="start"/> </causalConnector> </connectorBase> </head>

• Body: No body são definidas as mídias (oque) e a implementação dos conectores (quando). O body também implementa um port, que define qual media será a primeira a ser tocada. <body> <port id="portaPrincipal" component="img"/> <media id="img" .../> <link xconnector="onBeginStart"> <bind component="imgA" role="onBegin"/> <bind component="imgB" role="start"/> </link> </body> </ncl>

• Programando hipermídia)

o

aplicativo

(documento

Seguindo a documentação descrita em NETO, devemos obedecer uma ordem de construção no NCL, e, vamos segui-la aqui também.

o Cabeçalhos básicos do arquivo e do programa

Nosso escopo é mostrado na listagem abaixo. Nenhum segredo. <?xml version="1.0" encoding="ISO-8859-1"?> <!-- Generated by NCL Eclipse --> <ncl id="ex1" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> <head> </head> <body> </body> </ncl>

o Definir as regiões Volte rapidamente até a Figura 2, verás que temos 4 regiões onde as imagens dos candidatos são mostradas, além disso, estas estão inclusas dentro de uma região maior, algo como um container. Ainda temos 4 regiões menores para os botões que mostram as opções vinculadas ao controle remoto.

Nosso head passa a ficar assim: ... <head> <regionBase> <region id="rgBase" left="5" top="5" width="632" height="140"> <region id="rgDilma" width="156" left="0"/> <region id="rgSerra" width="156" left="158"/> <region id="rgMarina" width="156" left="316"/> <region id="rgPlinio" width="156" left="474"/> <region id="rgBtnDilma" width="24" left="0" top="105"/> <region id="rgBtnSerra" width="24" left="158" top="105"/> <region id="rgBtnMarina" width="24" left="316" top="105"/> <region id="rgBtnPlinio" width="24" left="474" top="105"/> </region> <region id="rgUrna" left="5" top="5"/> </regionBase> </head> ...

Perceba que temos um regionBase que serve como um root da definição de regiões. Podemos ter diversão regiões aninhadas ou filhas de outras regiões.

Perceba também que todas as regiões que irão abrigar as imagens dos candidatos tem a mesma largura (width): 156. A altura destas regiões é dependente da imagem, além disso, sua posição referente à extremidade esquerda da tela difere, isso porque, cada imagem estará uma ao lado da outra.

Abaixo das imagens dos candidatos temos as imagens dos controles.

Todos tem a mesma largura (width) e altura (height), sendo diferente apenas o atributo left, pelo mesmo motivo das imagens dos candidatos.

Todas as oito regiões citadas acima, ou seja, as regiões para as quatro imagens dos candidatos, assim como, as regiões para as imagens dos botões do controle remoto, todas estão vinculadas a mesma região, com id rgBase.

O atributo id é muito importante, ele será o identificador único daquela região.

Também temos a região com id rgUrna que mostrará a imagem final da urna, confirmando o voto.

Além dos atributos aqui discutidos, um region pode ter ainda os seguintes atributos: • title: se a região for exibida com uma moldura, é possível definir seu título com este atributo; • top: coordenada y da parte superior da região, sempre relacionada a região pai; • right: coordenada x da parte direita da região, sempre relacionada a região pai; • bottom: coordenada y da parte inferior da região, sempre relacionada a região pai; • background: define a cor de fundo da região. O valor é informado no padrão #RRGGBB ou através de constantes (Black, blue, cyan, darkGray, gray, green, lightGray, magenta, orange, pink, red, yellow ou white); • zIndex: posição da região no eixo z. Utilizado quando existem regiões sobrepostas, onde regiões com zIndex maior são apresentadas no topo, sobrepondo aquelas com zIndex menor.

o Definir descritores Com a definição dos descritores, associaremos as regiões da tela onde aparecerão os elementos visuais. Veja como fica nossa área de head:

<head> <regionBase> ... </regionBase> <descriptorBase> <descriptor <descriptor <descriptor <descriptor <descriptor <descriptor <descriptor <descriptor <descriptor </descriptorBase> </head>

id="dDilma" region="rgDilma"/> id="dSerra" region="rgSerra"/> id="dMarina" region="rgMarina"/> id="dPlinio" region="rgPlinio"/> id="dBtnDilma" region="rgBtnDilma"/> id="dBtnSerra" region="rgBtnSerra"/> id="dBtnMarina" region="rgBtnMarina"/> id="dBtnPlinio" region="rgBtnPlinio"/> id="dUrna" region="rgUrna" explicitDur="10s"/>

Os descritores ficam dentro de descriptorBase. Os oito primeiros descritores não tem nenhum mistério, apenas definem os atributos id e region. O primeiro é um identificador único e o segundo, a região ao qual o descritor está associado.

Apenas no último descritor que temos uma alteração. A definição do atributo explicitDur, com 10s. Isso quer dizer que, depois que o dUrna for iniciado, ele se auto-destruirá depois de 10 segundos.

Além disso, um descriptor pode ter outro atributo: • player: atributo opcional, pode definir a ferramenta de apresentação de um conteúdo multimídia.

Um descriptor também pode ter parâmetros, definidos com a tag descriptorParam. Veja um exemplo abaixo. A tag sempre deve definir o nome do atributo (name) e o seu valor (value).

Ex1: <descriptorParam name="nome" value="valor" /> Ex2: <descriptor id="dVideo1" region="rgVideo1"> <descriptorParam name="soundLevel" value="0.9" /> </descriptor>

o Definir elementos de mídia Neste terceiro passo começamos a editar o nosso body. Veja a listagem abaixo: <body> <media <media <media <media

id="imgDilma" src="dilma.jpg" descriptor="dDilma"/> id="imgSerra" src="serra.jpg" descriptor="dSerra"/> id="imgMarina" src="marina.jpg" descriptor="dMarina"/> id="imgPlinio" src="plinio.jpg" descriptor="dPlinio"/>

<media id="imgVerde" src="verde.jpg" descriptor="dBtnDilma"/> <media id="imgAmarelo" src="amarelo.jpg"descriptor="dBtnSerra"/> <media id="imgAzul" src="azul.jpg" descriptor="dBtnMarina"/> <media id="imgVermelho" src="vermelho.jpg" descriptor="dBtnPlinio"/> <media id="imgUrna" src="urna.jpg" descriptor="dUrna"/> </body>

A mídia é descrita com a tag media. Alguns atributos que usamos aqui foi o id, o src (define o caminho da imagem) e descriptor (descritor configurado no passo anterior).

Além disso, a tag media aceita mais dois atributos: • type: o tipo da mídia. Atualmente o formatador aceita os seguintes tipos de mídia: video, audio, text (páginas HTML ou TXT), image ou img (imagens JPEG, GIF, PNG ou BMP), nclet (código Java de um NCLet), lua (arquivo com código Lua) e settings (nó de atributos globais para ser usado em escolhas (switches)).

• refer: referência a outro nó de mídia já definido.

o Definir porta de entrada Anteriormente já falamos das portas e, este é o momento de vê-las na prática. Como todas as mídias estão dentro de contextos deve haver uma maneira de acessá-las externamente, do contrário, nosso documento hipermídia nunca seria visto pelo usuário.

Veja a tag que acrescentamos ao nosso body: <body> <port id="portaPrincipal" component="imgDilma"/>

... </body>

O body por si só já é um contexto. O primeiro contexto a ser exibido pelo formatador NCL. E a porta configura nesse contexto serve para dizer: formatador, por favor, o meu documento hipermídia começa pelo componente identificado pelo id imgDilma.

o Definir elos – Parte 1 Os elos entre as mídias, que são responsáveis pela sincronização desejada em um documento hipermídia, são feitos através de conectores.

Segundo SOARES, RODRIGUES e BARBOSA, um conector define a relação entre o(s) nó(s) de origem do elo (i.e., que ativam o elo) e o(s) nó(s) de destino do elo.

Os mesmos autores dão dois exemplos: • para disparar titulo1, assim que video1 iniciar • para terminar titulo1, assim que video1 terminar Vamos ver como ficaram nossos conectores: ...

1:<connectorBase> 2: <causalConnector id="onBeginStart"> 3: <simpleCondition role="onBegin"/> 4: <simpleAction role="start"/> 5: </causalConnector> 6: <causalConnector id="onEndStop"> 7: <simpleCondition role="onEnd"/> 8: <simpleAction role="stop"/> 9: </causalConnector> 10: <causalConnector id="onEndStart"> 11: <simpleCondition role="onEnd"/> 12: <simpleAction role="start"/> 13: </causalConnector> 14: <causalConnector id="onKeySelection"> 15: <connectorParam name="vKey"/> 16: <simpleCondition role="onSelection" key="$vKey"/> 17: <simpleAction role="stop"/> 18: </causalConnector> 19:</connectorBase> 20:</head>

Todos conectores ficam em connectorBase. Vamos a eles.

Linha 2: onBeginStart. Nesse conector definimos dois papéis, na linha 3 a condição onBegin e na linha 4 a ação start. Ou seja, quando uma mídia começar outra também deverá começar.

Linha 6: onEndStop. Nesse conector definimos dois papéis, na linha 7 a condição onEnd e na linha 8 a ação stop. Ou seja, quando uma mídia parar outra também deve encerrar seu ciclo na tela.

Linha 10: onEndStart. Nesse conector definimos dois papéis, na linha 11 a condição onEnd e na linha 12 a ação start. Ou seja, quando uma mídia parar outra deve iniciar.

Linha 14: onKeySelection. Nesse conector definimos dois papéis e um parâmetro. Na linha 16 temos a condição onSelection, que utiliza o parâmetro $vKey configurado na linha 15. Na linha 17 temos a ação, o stop. Ou seja, quando uma tecla for selecionada alguma mídia vai parar de ser mostrada.

Quando programarmos cada conector, na próxima seção, tudo ficará mais claro.

o Definir elos – Parte 2 Vamos por partes. Veja a Listagem abaixo: <body> ... <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgSerra" role="start"/> </link> <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgMarina" role="start"/> </link> <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgPlinio" role="start"/> </link> ... </body>

Nesse momento estamos trabalhando com o conector que definimos com o nome de onBeginStart. Ele servirá para iniciar todas as imagens dos candidatos quando a imagem da candidata Dilma for iniciada. Por que isso?

Porque definimos somente uma porta de entrada apontando para a media que contém a imagem da Dilma, logo, as imagens de Marina, Serra e Plínio também devem iniciar juntamente no start-up do aplicativo.

Esse é o tão falado sincronismo de mídia.

Logo depois da definição destes links, vamos para os próximos: <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgVerde" role="start"/> </link> <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgAmarelo" role="start"/> </link> <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgAzul" role="start"/> </link> <link xconnector="onBeginStart"> <bind component="imgDilma" role="onBegin"/> <bind component="imgVermelho" role="start"/> </link>

Perceba que ainda estamos usando o mesmo conector. Da mesma forma que todas as imagens dos candidatos devem iniciar ao mesmo tempo, as imagens dos botões do controle remoto também. Logo, quando a imagem da Dilma iniciar, todas imagens dos botões também iniciam.

Veja agora a listagem abaixo: <link xconnector="onKeySelection"> <bind role="onSelection" component="imgVermelho"> <bindParam name="vKey" value="RED"/> </bind> <bind role="stop" component="imgDilma"/> </link>

Este link foi colocado logo abaixo dos demais vistos até aqui. Porém, diferentemente dos demais, ele implementa o conector onKeySelection.

Nele definimos o onSelection, passando como parâmetro o botão vermelho do controle remoto como o responsável pela ação. Ao acontecer isso paramos de exibir a imagem da Dilma.

Mas e as imagens da Marina, Serra e Plínio? Os links abaixo serão justamente para isso: <body> ... <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgSerra" role="stop"/> </link> <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgMarina" role="stop"/> </link> <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgPlinio" role="stop"/> </link> ... </body>

Os últimos links configurados utilizam o conector onEndStop e, quando a media com id imgDilma for encerrada (onEnd) várias mídias também serão encerradas. Causando um efeito cascata, ou seja, todas as imagens desaparecerão. Todas? Mas e as imagens dos botões do controle remoto? Ainda faltam os seguintes links para fechar também estas imagens: <body> ... <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgVerde" role="stop"/> </link> <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgAmarelo" role="stop"/> </link> <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgAzul" role="stop"/> </link> <link xconnector="onEndStop"> <bind component="imgDilma" role="onEnd"/> <bind component="imgVermelho" role="stop"/> </link> ... </body>

E para finalizar vamos utilizar o último conector, o onEndStart. <body> ... <link xconnector="onEndStart"> <bind component="imgDilma" role="onEnd"/> <bind component="imgUrna" role="start"/> </link> ... </body>

Este conector inicia uma media quando outra acaba. É exatamente isto que queremos, ao esconder a imagem da Dilma e conseqüentemente dos outros candidatos e dos botões, desejamos que a imagem da urna fique visível.

Com isso encerramos nossa aplicação. Com certeza o leitor não viu 1% da capacidade do Ginga NCL e muito menos do Ginga como um todo, mas esse texto já serve como um guia inicial para quem deseja entrar no mundo da TV Digital e do padrão brasileiro.

• Sobre Mim Meu nome é Ricardo da Silva Ogliari, sou graduado em Ciência da Computação pela Universidade de Passo Fundo. Atualmente também estou cursando uma pós-graduação em web, estratégias de inovação e tecnologia, no Senac SP. Trabalho com mobile a 7 anos, atualmente na Pontomobi.

Escrevo artigos para algumas revistas nacionais especializadas. Sou criador e mantenedor do http://www.mobilidadetudo.com e sou um dos membros do www.javamovel.com. Palestrei em eventos nacionais e internacionais, como o FISL e o JustJava, além de ter dezenas de artigos meus espalhados pelo mundão da internet.

• Bibliografia • Construindo Programas Audiovisuais Interativos Utilizando a NCL 3.0 e a Ferramenta Composer. Autor: Carlos de Salles Neto.

• Programas Audiovisuais Interativos Utilizando a NCL2.3 – Perfil Básico. Autores: Luiz Fernando Gomes Soares, Rogério Ferreira Rodrigues e Simone Diniz Junqueira Barbosa.