Texto originalmente publicado no Portal Imasters.

Este texto introduz a norma referente a linguagem Java para o middleware Ginga

Está em consulta pública na ABNT a norma Codificação de dados e especificações de transmissão para radiodifusão digital — Parte 4: Ginga-J — Ambiente para a execução de aplicações procedurais, que especifica o uso da linguagem Java para o desenvolvimento de aplicações para TV digital Interativa. Até o momento apenas a norma Ginga-NCL, discutida nos texto anteriores desta seção está oficializada, prevendo as linguagens NCL e Lua para o desenvolvimento das interatividades na TV digital brasileira.
A norma Ginga-J ficará em consulta pública até 17 de julho. Qualquer pessoa ou empresa pode se manifestar sobre a norma, aprovando-a integralmente, reprovando-a ou sugerindo alterações. Nos dois último casos é necessário anexar um documento com a justificativa ou as alterações sugeridas, respectivamente. Depois desse processo, a norma volta para o Fórum do SBTVD, responsável pela sua redação. O Fórum fará as análises dos votos, podendo aceitar ou não as alterações sugeridas. Depois disso, a norma é enviada para o Comité Consultivo do governo federal, responsável pela homologação da mesma. Esse processo deverá levar cerca de 90 dias, talvez um pouco menos, dependendo das burocracias do Fórum e do governo. Dessa forma, é possível lançar oficialmente a interatividade antes do natal. As emissoras de TV estão apostando em um “natal interativo” para a TV digital.
O Ginga-J é composto por um conjunto de API (Application Programming Interface, Interfaces de Programação de Aplicativos), usadas para desenvolver todas as funcionalidades para a implementação de aplicativos para televisão digital. Isso inclui desde a manipulação de dados multimídia até protocolos de acesso. O middleware Ginga é obrigatório para todos os receptores com interatividade, compreendendo set top boxes, TVs com recepção digital embutida, computadores multimídia e clusters locais de aparelhos conectados via redes domésticas (Home Area Networks , HAN).
Essa norma completa as normas anteriores, incluindo a Ginga-NCL. Para o desenvolvedor de aplicativos em NCL e Lua não muda nada, pois é possível escolher em quais linguagens programas as interatividades. Pode ser NCL sozinho, Java sozinho, NCL+Lua, NCL+Java ou NCL+Java+Lua.
Como já vimos em textos anteriores, O Ginga-NCL (ou Máquina de Apresentação) é um subsistema lógico do middleware Ginga que processa documentos declarativos NCL. 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.
A norma em consulta na ABNT também faz parte do middleware Ginga, porém processa aplicações procedurais desenvolvidos em Java, que recebem o nome de Xlets. Um componente-chave deste ambiente é o mecanismo de execução do conteúdo procedural, que tem por base uma Máquina Virtual Java.
A arquitetura completa do middleware Ginga é mostrado na figura abaixo. O Ginga é estruturado de forma a organizar as partes comuns, que independem da linguagem de programação dos aplicativos, como segurança e gerenciamento de mídias e fluxos de áudio e vídeo. A máquina de execução é responsável pela decodificação dos Xlets, enquanto a máquina de apresentação trata as aplicações declarativas. Em caso da aplicação declarativa conter código procedural Java, há uma ponte entre as duas máquinas, que executam simultaneamente.

É preciso ressaltar que essa arquitetura se aplica apenas a receptores fixos e móveis. Receptores portáteis não possuem máquina de execução, nem máquina virtual Java.
Apenas para atualizar o panorama da implantação da TV digital no Brasil, o processo está adiantado em quase dois anos. Vinte cidades já dispõe de sinal digital, sendo 16 capitais, compreendendo mais da metade da população brasileira. Os receptores, cujo preço abusivo foi muito criticado no lançamento da TV digital em 2007, custam menos de R$ 400,00. O único problema é que a maioria dos fornecedores está sem estoque, segurando as vendas para incluir a interatividade nos próximos lotes. Até empresas desenvolvedoras de aplicações tem tido problemas para adquirir quantidades maiores de set top boxes. As 20 cidades com sinal digital são: São Paulo (SP), Belo Horizonte (MG), Rio de Janeiro (RJ), Goiânia (GO), Porto Alegre (RS), Curitiba (PR), Campinas (SP), Cuiabá (MT), Salvador (BA), Florianópolis (SC), Vitória (ES), Uberlândia (MG), São José do Rio Preto (SP), Teresina (PI), Santos (SP), Brasília (DF), Campo Grande (MS), Fortaleza (CE) e Recife (PE).

Texto originalmente publicado no Portal Imasters.

Este texto continua o detalhamento das definições do estado inicial das mídias, definidas através dos descritores.

No texto anterior começamos a detalhar o uso dos descritores, com as necessidades e possibilidades de declaração. Apenas para relembrar, os descritores descrevem o estado inicial das mídias, que pode ser manipulado posteriormente através de um conector que altera os atributos de uma mídia. Neste texto iremos esgotar os atributos e parâmetros dos descritores e traremos alguns exemplos de uso.

transIn e transOut

Determina transições para o começo e término das mídias. As transições especificadas com um atributo transIn iniciarão no começo dos elementos de mídia, enquanto que transOut determina a transição final da execução da mídia. Todas as transições devem ser declaradas em uma seção <transitionBase>, dentro do cabeçalho do documento NCL (discutiremos essa seção em textos futuros).

explicitDur e freeze

São atributos temporais definidos pelo módulo Timing, que descrevem a duração de execução da mídia e se o último quadro deve ser congelado, respectivamente. Atraves do explicitDur podemos declarar uma mídia com duração definida, que não precisa ser encerrada através de um conector e um link.

player

Atributo que identifica a ferramenta de apresentação a ser utilizada. Quando um elemento em foco é selecionado pressionando a tecla de ativação, o controle do foco passa a ser do exibidor do elemento <media> (player ). Essa parte do controle de foco ainda é muito confusa na norma Ginga-NCL. Deverá ser esclarecida e totalmente normatizada pela norma Ginga-J, que está em consulta pública na ABNT.

region

Atributo que conecta o descritor à região, definida pelos elementos do módulo Layout.

top, left, bottom, right, width, height

Determina a região da tela onde a mídia inicializa, com distâncias do topo, da esquerda, baixo, direita, largura e altura, respectivamente. O valor é um número real na faixa [0,100] terminando com o caractere “%” (por exemplo, 30 %), ou um valor inteiro especificando o atributo em pixels.

location

Dois números separados por vírgula, cada um seguindo as regras de valor especificadas para parâmetros left e top, respectivamente.

size

Dois valores separados por vírgula. Cada valor deve seguir as mesmas regras especificadas para parâmetros de width e height, respectivamente.

bounds

Quatro valores separados por vírgula. Cada valor deve seguir as mesmas regras especificadas para parâmetros left, top, width e height, respectivamente.

background

Cor de fundo da mídia. Nomes de cores reservadas: “white”, “black”, “silver”, “gray”, red”, “maroon”, fuchsia”, “purple”, “lime”, “green”, “yellow”, “olive”, “blue”, “navy”, “aqua”, ou “teal”. O valor da cor de fundo pode também ter valor reservado “transparent”. Isso pode ser útil para apresentar imagens transparentes, como GIFs transparentes, sobrepostas a outras imagens ou vídeos. Quando não especificado, o atributo de cor de fundo toma o valor default “transparent”.

visible

Pode ter os valores “true” ou “false”, determina se uma mídia aprece invisível no início da execução. Trata-se de um recurso importante para sincronismos temporais mais avançados, feitos em função do tempo de execução das mídias e não da duração do vídeo.

Transparency

Um número real na faixa [0,1], ou um número real na faixa [0,100] terminando com o caractere “%” (por exemplo, 30 %), especificando o grau de transparência da mídia.

fit

Determina como o nó de mídia compõe a região na qual deve aparecer. Pode conter os valores “fill”, “hidden”, “meet”, “meetBest”, “slice”.
“fill”: redimensiona o conteúdo do objeto de mídia para que toque todas as bordas da caixa definida pelos atributos de largura e altura do objeto.
“hidden”: se a altura/largura intrínseca do conteúdo de mídia for menor que o atributo de altura/largura, o objeto deve ser criado iniciando da margem superior/esquerda e ter a altura/largura remanescente preenchida com a cor de fundo. Já se a altura/largura intrínseca do conteúdo de mídia for maior do que o atributo altura/largura, o objeto deve ser criado iniciando pela margem superior/esquerda até que a altura/largura definida no atributo seja alcançada, e ter a parte do conteúdo de mídia abaixo/a direita da altura/largura cortada.
“meet”: redimensiona o objeto de mídia visual enquanto preserva sua relação de aspecto até que sua altura ou largura seja igual ao valor especificado pelos atributos height ou width. O canto superior esquerdo do conteúdo de mídia é posicionado nas coordenadas superiores esquerdas da caixa, o espaço vazio à direita ou na base é preenchido com a cor de pano de fundo.
“meetBest”: a semântica é idêntica à do “meet”, exceto que a imagem não é redimensionada em mais de 100 % em qualquer dimensão.
“slice”: redimensiona o conteúdo de mídia visual enquanto preserva sua relação de aspecto, até que sua altura ou largura seja igual ao valor especificado nos atributos de altura e largura, e que a caixa de apresentação definida esteja completamente preenchida. Algumas partes do conteúdo podem ser cortadas. O excesso de largura é cortado a partir da direita do objeto de mídia. O excesso de altura é cortado a partir da base do objeto de mídia.

scroll

Especifica se haverá barra de rolagem na tela, caso todo o contéudo não caiba na região determinada. Pode ter os valores “none”, “horizontal”, “vertical”, “both”, ou “automatic”, que significam, respectivamente: sem barra, barra horizontal, barra vertical, ambos ou automático.

style

Localizador de um arquivo de folha de estilo.

soundLevel, balanceLevel, trebleLevel, bassLevel

Configura o áudio, com um número real na faixa [0, 1], ou um número real na faixa [0,100] terminando com o caractere “%” (por exemplo, 30 %).

zIndex

Determina a ordem em que os elementos de mídia sobrepostos devem aparecer. É definido com um número inteiro na faixa [0, 255], sendo que mídias com maior valor de zIndex são posicionadas sobre as outras com menor valor de zIndex.

fontFamily

Uma lista priorizada de nomes de família de fontes e/ou nomes genéricos de famílias.

fontStyle

Estilo da fonte (“normal”,ou “italic”).

fontSize

Tamanho da fonte em pontos.

fontVariant

Forma de exibição do texto: fonte em “small-caps” ou “normal”.

fontWeight

Peso da fonte (“normal”, ou “bold”).

fontColor

Cor da fonte, definida com os nomes reservados: “white”, “black”, “silver”, “gray”, red”, “maroon”, fuchsia”, “purple”, “lime”, “green”, “yellow”, “olive”, “blue”, “navy”, “aqua”, ou “teal”.

reusePlayer

Valor booleano: “false”, “true”. Valor default = “false”

playerLife

Define o ciclo de vida do player, através dos valores “keep”, “close”. O valor default é “close”.

Agora que conhecemos todos os atributos e parâmetros dos descritores, vamos a um rápido exemplo:
<descriptor id=”dTXT” region=”Base_rg#rgTXT” moveRight=”1″ moveLeft=”2″ focusIndex=”3″ explicitDur=”10s”>
<descriptorParam name=”fontColor” value=”red”/>
<descriptorParam name=”fontSize” value=”16″/>
<descriptorParam name=”fontWeight” value=”bold”/>
<descriptorParam name=”transparency” value=”0.2″/>
</descriptor>

Neste descritor, estamos atribuindo o nome “dTXT”, importando uma região “rgTXT” de uma base de regiões “Base_rg” definida em outro documento NCL. Estamos atribuindo valores de navegação, onde a seta para a direita atribui foco a mídia com focusIndex 1. Já a seta a esquerda atribui foco ao elemento identificado com 2. A mídia em questão recebe a identificação 3, que pode ser utilizado para voltar o foco quando este estiver em outra mídia. O explicitDur siginifca que a mídia deverá ficar 10 segundos em execução. Ao final desse tempo, ela para automaticamente. Nos parâmetros está definido que a cor da fonte é vermelha, tamanho 16, negrito e 20% de transparência.
Neste exemplo, o descritor atribui características iniciais a uma mídia txt. Todas essas configurações podem ser feitas em documento HTML, importado dentro do NCL. Vale registrar que nos receptores com Ginga disponíveis para teste atualmente, nem todos esses atributos ou parâmetros estão implementados. O mesmo acontece com as ferramentas de teste disponibilizadas no site no Ginga-NCL.

Texto publicado originalmente no Portal Imasters.

Este texto detalha as configurações do início da execução das mídias, definidas através dos descritores.

De forma bem sintética, pode-se dizer que os descritores conectam as mídias às regiões em que devem aparecer, definindo o seu status inicial. Assim, descritores descrevem como os nós de mídia são executados. Um descritor é composto por um conjunto de atributos opcionais, agrupando todas as definições espaço-temporais a serem usadas de acordo com o tipo de objeto a ser apresentado. Ou seja, os atributos mudam de acordo com a mídia, com descrições específicas para elementos de vídeo, texto, imagens e scripts. Como já visto em textos anteriores, os descritores devem obrigatoriamente ser declarados no cabeçalho do documento, dentro do elemento <descriptorBase>, responsável por agrupar o conjunto de descritores de um documento.
Precisamos ressaltar que os descritores definem o estado inicial das mídias, ou seja, quando elas são executas. Os atributos podem ser mudados durante a execução, usando conectores que configuram as características iniciais das mídias. Dessa forma, um vídeo pode ser executado em determinado volume, que pode ser alterado através de um elemento <soundLevel> definido como propriedade da mídia. A norma da ABNT estabelece que se vários valores forem especificados para um mesmo atributo, o valor definido no elemento <property> da mídia tem precedência sobre o valor definido em um elemento <descriptorParam>, que, por sua vez, tem precedência sobre o valor definido em um atributo do elemento <descriptor>. Em todo caso, convém evitar declarar o mesmo atributo mais de uma vez. Isso ajuda a ter mais clareza sobre o código, o que facilita compreender melhor aplicações com duas ou três mil linhas de código, algo comum em aplicações NCL para TV digital que usam muitas variáveis.
Cada descritor deve obrigatoriamente ter um atribute id, responsável pela identificação única e inequívoca do mesmo. Os demais atributos e parâmetros são opcionais. Além disso, um descritor pode possuir elementos filho <descriptorParam> utilizados para parametrizar o controle da apresentação do objeto principal. Esses parâmetros podem, por exemplo, redefinir alguns valores de atributos definidos pela região. Também é possível definir novos atributos, como por exemplo, background , que determina a cor de fundo utilizada para preencher a área de uma região de exibição da mídia, quando toda a região não é preenchida pela mídia em si; visible , que estabelece se o objeto é visualizado ou ocultado no começo da apresentação; fit , que indica como um objeto será apresentado; scroll , que permite configura a rolagem caso o elemento de mídia seja maior do que a região; transparency , indicando o grau de transparência da apresentação de um objeto; style, que refere-se a uma folha de estilo CSS com informações, por exemplo, para apresentação do texto; além de especificar atributos para objetos de áudio, tais como soundLevel , balanceLevel , trebleLevel e bassLevel .
Além disso, os elementos-filhos <descriptorParam> podem determinar se um novo exibidor deve ser instanciado, ou se um exibidor já instanciado deve ser utilizado (reusePlayer), e especificar o que acontecerá à instância do exibidor no final da apresentação (playerLife).
A seguir, a primeira parte da descrição detalhada dos atributos e parâmetros, lembrando que estes nomes são reservados, ou seja, não podem ser utilizados para identificar qualquer outra ação em um documento NCL.

moveLeft, moveRight, moveUp; moveDown,

São atributos para navegação, definidos pelo módulo KeyNavigation. Definem o que acontece com as mídias quando as setas direcionais do controle remoto são pressionadas. Os atributos moveLeft, moveRight, moveUp; moveDown, se referem as setas esquerda, direita, para cima e para baixo, respectivamente. A cada movimento de foco, o atributo especifica um valor igual ao valor do focusIndex associado ao elemento sobre o qual o foco será aplicado quando a respectiva tecla for pressionada.

focusIndex

O atributo focusIndex especifica um índice para o elemento <media> sobre o qual o foco pode ser aplicado, quando esse elemento estiver em exibição. A mídia recebe o foco, que é atribuído através do descritor. Quando o descritor não definir o atributo, a mídia não poderá receber o foco. Em um determinado momento da apresentação, se o foco não tiver sido ainda definido, ou se estiver perdido, o próprio set top box aplica um foco ao elemento que estiver em execução com o menor valor de índice. Os valores do atributo focusIndex precisam ser únicos em um documento NCL. Se houver atributos repetidos, o foco será ignorado, prejudicando a navegação.

focusBorderColor; focusBorderWidth; focusBorderTransparency,

Quando uma mídia recebe o foco, ela precisa ser destacada para identificar esse foco para o telespectador. Isso é definido pelos atributos de posicionamento, que criam uma moldura em torno da mídia. O atributo focusBorderColor define a cor da moldura e pode receber os nomes reservados de cor: “white”, “black”, “silver”, “gray”, “red”, “maroon”, “fuchsia”, “purple”, “lime”, “green”, “yellow”, “olive”, “blue”, “navy”, “aqua”, ou “teal”. O atributo focusBorderWidth define a largura em pixels da borda em destaque (0 significa que nenhuma borda aparece, valores positivos significam que a borda está fora do conteúdo do objeto e valores negativos significam que a borda é desenhada sobre o conteúdo do objeto). Já o atributo focusBorderTransparency define a transparência da cor de seleção. O valor do focusBorderTransparency deve ser um valor real entre 0 e 1, ou um valor percentual de zero a cem, seguido do caractere “%” (por exemplo, 30 %), com “1” ou “100 %” significando transparência total e “0” ou “0%” significando nenhuma transparência. Quando o focusBorderColor , o focusBorderWidth ou o focusBorderTransparency não são definidos, o próprio set top box atribui valores default, que podem ser trabalhados nas propriedades do elemento <media> do tipo application/x-ginga-settings: defaultFocusBorderColor , defaultFocusBorderWidth e defaultFocusTransparency. Esse elemento será detalhado mais para frente, quando abordarmos o uso de variáveis na linguagem NCL.

focusSrc, selBorderColor, focusSelSrc

Além da moldura, é possível substituir totalmente a mídia que estiver em foco. Isso é feito com o atributo focusSrc, que pode especificar um conteúdo alternativo a ser apresentado, ao invés da mídia com uma moldura. Esse atributo segue as mesmas regras do atributo src do elemento <media>, já discutido amplamente em textos anteriores. Da mesma forma, quando um elemento em foco é selecionado pressionando a tecla de ativação (OK), o atributo focusSelSrc também pode especificar uma mídia alternativa a ser apresentada. Quando selecionada, a caixa definida pelos atributos de posicionamento de elemento deve ser destacada com a cor definida pelo atributo selBorderColor.
No próximo texto, completaremos a descrição dos atributos e parâmetros dos descritores, e traremos alguns exemplos de como usar essas informações.

Texto publicado originalmente no Portal Imasters.

Neste é discutida a participação do telespectador, onde a interface da interatividade responde a uma ação do controle remoto.

No texto anterior (Trabalhando com links e conectores na linguagem NCL), apresentamos de forma sucinta e introdutória a criação de conectores e o uso de links. Apenas para relembrar, conectores definem relação causais na linguagem NCL. Já os links atribuem a relação causal a uma mídia, através de papéis. Assim, no exemplo anterior, dois botões apareciam simultaneamente na tela da TV, onde o primeiro (começo arbitrário) determinava o início do segundo. Hoje vamos aprofundar esse exemplo, onde o segundo botão irá aparecer a partir da ação do usuário. Mais especificamente, quando o botão vermelho do controle remoto for apertado.

Assim, o primeiro botão continua aparecendo automaticamente, com tempo de sincronismo determinado pela emissoras de TV. O segundo botão apenas surge na tela quando o telespectador apertar o botão vermelho do controle remoto. Para tanto, precisamos construir nosso conector:

<causalConnector id=”onKeySelectionStart”>
<connectorParam name=”keyCode”/>
<simpleCondition key=”$keyCode” role=”onSelection”/>
<simpleAction max=”unbounded” qualifier=”par” role=”start”/>
</causalConnector>

Nesse conector estamos construindo a causa “on selection”, cuja ação será “start”. O botão a ser apertado é definido no link. Para tanto, é preciso definir uma variável através do parâmetro do conector, a qual será atribuído o valor do botão.

O atributo “max” especifica a quantidade de nós de mídia que podem assumir o papel. No caso, “unbounded” significa que não há limites. O valor deve ser positivo e maior que um. Também é possível determinar um valor mínimo, usando “min” ao invés de “max”. Já o atributo “qualifier” define se as ações ocorrem em paralelo (“par”) ou em sequência (“seq”).

O uso desse conector no link será da seguinte forma:

<link id=”lStopBotaoStartMenu” xconnector=”onKeySelectionStart”>
<bind component=”botao” role=”onSelection”>
<bindParam name=”keyCode” value=”RED”/>
</bind>
<bind component=”botao2″ role=”start”/>
</link>

A ação, definida no primeiro bind, passa o valor da variável RED como parâmetro, que corresponde ao botão vermelho do controle remoto. O nome da variável pode ser qualquer um, desde que seja o mesmo definido no conector. O segundo bind corresponde a ação “start”.

Os seguintes valores (que são sensíveis ao tipo maiúscula ou minúscula) são aceitos pelo atributo key e podem ser usados para representar uma condição, caso sejam apertados pelo usuário:
Números: “0”, “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”;
Lestras: “A”, “B”, “C”, “D”, “E”, “F”, “G”, “H”, “I”, “J”, “K”, “L”, “M”, “N”, “O”, “P”, “Q”, “R”, “S”, “T”, “U”, “V”, “W”, “X”, “Y”, “Z”, “*”, “#”;
Teclas específicas: “MENU”, “INFO”, “GUIDE”, “EXIT”, “POWER”;
Setas direcionais: “CURSOR_DOWN”, “CURSOR_LEFT”, “CURSOR_RIGHT”, “CURSOR_UP”, “ENTER”;
Troca de canais: “CHANNEL_DOWN”, “CHANNEL_UP”;
Volume: “VOLUME_DOWN”, “VOLUME_UP”;
Botões coloridos: “RED”, “GREEN”, “YELLOW”, “BLUE”, “BACK”
Controle: “REWIND”, “STOP”, “EJECT”, “PLAY”, “RECORD”, “PAUSE”.

Com estes recursos é possível determinar qualquer tipo de participação do usuário, deixando a cargo dele o controle das aplicações. Pode ser desenvolvida uma aplicação onde, a partir do começo do segundo botão, determinado pelo telespectador, mais ações sejam desencadeadas. Pode-se usar uma ação “stop” para o primeiro botão, redimensionar o vídeo, iniciar aplicações em Java ou Lua, colocar um menu na tela, e tudo o mais que a criatividade permitir.

Lembrando sempre que há aplicações para TV interativa que não dependem de nenhuma participação do telespectador. Este participa apenas quando a aplicação permitir a interatividade. Portanto, a partir da primeira ação do telespectador apertando o botão vermelho, que significa que ele está interessado em participar da interatividade, inúmeras ações podem ser desencadeadas pelo sistema, sincronizadas ou não aos fluxos de vídeos da TV.