Coluna do Daniel Castro, Folha de hoje.

Pouco mais de um ano e meio após seu lançamento, em São Paulo, sinais de TV digital já cobrem mais da metade dos domicílios com televisores no Brasil, mas apenas 3% deles usufruem da nova tecnologia, que oferece imagem e áudio de melhor qualidade.
A TV digital já foi lançada em 22 cidades/metrópoles, onde se concentram 53% dos 53,4 milhões de domicílios com TV. Nesses domicílios, vivem 95,2 milhões de pessoas, ou 49,8% da população brasileira.
Segundo o Fórum de TV Digital, entidade que reúne fabricantes, emissoras e governo, já existem 1,6 milhão de receptores de televisão digital no Brasil. A estimativa inclui cerca de 1,2 milhão de televisores com receptores digitais integrados ou com caixas decodificadoras e 400 mil celulares e minitelevisores que captam TV digital.
O número de receptores ganhou impulso nos últimos meses, mas ainda é muito pequeno em relação à área de cobertura. Executivos apostam que a Copa de 2010 e que a popularização de celulares com TV levarão a um crescimento muito rápido do uso da tecnologia.
A Globo é a rede com maior cobertura digital. Seu sinal cobre 46,5% da população, mas ainda não chegou à região Norte. Sem contar a Rede Vida (presente em sinal digital em São José Rio Preto), é a única que já expandiu para além das capitais -está em Campinas, Sorocaba, Santos e Uberlândia.
A Record cobre 22% da população, porém está restrita a cinco capitais (SP, Rio, Belo Horizonte, Goiânia e Aracaju). SBT e Rede TV! cobrem 19,4% da população e a Band, 15,7%.

A Abra, associação dissidente e concorrente da Abert, entrou na justiça ontem contra a proibição da multiprogramação, feita pelo Ministério das Comunicações. É mais um passo na tentativa de buscar um acordo para aumentar o número de canais e a opção de conteúdos na TV digital. A Globo está isolada na defesa do mercado atual, uma vez que Abril, Band, Record e RedeTV se posicionaram publicamente contra a proibição. Vale lembrar que o presidente da Abra é Frederico Nogueira, vice-presidente do Grupo Bandeirantes e presidente do Fórum do SBTVD.
Toda essa discussão me remeteu ao professor NIcholas Negroponte, que em 1990 escreveu no livro A Vida Digital:

Os impérios monolíticos de meios de comunicação estão se dissolvendo em uma série de indústrias de fundo de quintal. Os atuais barões das mídias irão se agarrar a seus impérios centralizados amanhã, na tentativa de mantê-los. As forças combinadas da tecnologia e da natureza humana acabarão por impor a pluralidade com muito mais vigor do que quaisquer leis que o congresso possa inventar.

Parece profecia. Enquanto o setor de radiodifusão racha na discussão sobre a multiprogramação, as tecnologias convergentes que trazem a internet para a TV e a TV para a internet não estão nem um pouco preocupadas com o que a lei permite e o que ela bloqueia. Simplesmente criam seu mercado, onde não há espaço para mídias de massa e publicidades que usam um canhão para acertar um passarinho (típico da televisão aberta).

Acima de toda essa discussão está em debate não a multiprogramação, mas a capacidade das TVs de se posicionarem diante desse novo cenário e com que mentalidade seus executivos irão enfrentar essas mudanças.

Vale a pena dar uma olhada no caderno Link do Estado de São Paulo de hoje, com ótimas matérias sobre a relação da TV com a internet e vice versa. Seguem os links:

O nascimento da geração Lost

O canal que passa seu programa na hora que você quer

A TV está ficando com a cara da internet…

…E a internet está ficando com conteúdo de televisão

Texto originalmente publicado no Portal Imasters.

Este texto traça um panorama contextual sobre a inserção da interatividade no mercado audiovisual, com a concorrência com outros dispositivos.

Agora que já dominamos um pouco o desenvolvimento de aplicações para o middleware Ginga, vamos analisar neste e nos próximos textos como esse desenvolvimento de insere no mercado audiovisual, mais especificamente nas emissoras de televisão. Nesta seção do Imasters estamos vendo como programar as aplicações. Falta, portanto, como conceber as interatividades que serão programadas em NCL, Lua ou Java e entender como elas se inserem no mercado.
Essa visão mais ampla é útil para pensar a interatividade dentro do contexto da grade de programação da emissora de TV, que é linear (um programa vem depois do outro, sempre) e tem acesso restrito. A transmissão é unidirecional e nada indica que isso mude nos próximos anos. A bidirecionalidade está associada apenas à interatividade, onde o telespectador pode enviar informações de volta para a emissora. Essa característica estrutural e tecnológica vai determinar o que pode e o que não pode ser feito.
Além disso, a TV aberta se sustenta pela publicidade, ou seja, ela vende a atenção de um determinado número de telespectadores para empresas fazerem anúncios. Conforme a constituição brasileira, a TV é aberta e gratuita, ou seja, não é permitido cobrar para que o telespectador assista ao conteúdo no ar. O mesmo vale para a interatividade, ou não. O tema é controverso e está longe de ter uma legislação específica. O que tende a acontecer é o mercado se adiantar e lançar produtos, serviços e aplicações antes de alguém decidir se pode ou não.
Por falar em negócios, e para mostrar a que o mercado não espera pela burocracia legislativa, vou trazer duas notícias que agitaram os últimos dias. Primeiro um equipamento que baixa arquivos de vídeo da internet e os mostra diretamente na TV, sem a necessidade de qualquer meio, ou mídia, para levar o arquivo do computador para o televisor. Dias depois veio a notícia de que a empresa de TV por assinatura Cablevision foi autorizada pelo governo dos EUA a gravar conteúdos remotamente, gerenciados pelos usuários. São duas iniciativas que confrontam o conservadorismo tradicional da indústria audiovisual, mostrando que a evolução tecnológica se sobrepõe as tentativas de reserva ou garantia de mercado.
No dia 26 de junho a empresa americana Zinnet anunciou o CinemaCube, um player multimídia que busca arquivos na internet, em redes domésticas ou em dispositivos USB. Os dois últimos estão presentes em vários players, inclusive alguns tocadores de DVD. A novidade do CinemaCube está em um cliente Torrent embutido. Com isso, levar o conteúdo baixado da Internet se torna mais fácil, sem a necessidade de gravar DVDs ou ainda de ter uma TV com entrada para drives USB. Os clientes de peer-to-peer Torrent são os mais usados para trocar grandes arquivos de mídia, principalmente vídeo. O dispositivo é conectado diretamente à TV e não conta com capacidade de armazenamento interno, mas pode trabalhar com pen drives e até mesmo discos rígidos externos para gravar e acessar arquivos de vídeo e música. O CinemaCube suporta os formatos de vídeo RM, RMVB, MP2, AVI, H.264, VOB, MOV, MKV, DivX, Xvid, WMV e de áudio MP3, Real Audio, FLAC, AAC, OGG, WAV.
Por enquanto, o CinemaCube está disponível apenas nos Estados Unidos por US$ 89,90 e é compatível com conteúdo em alta definição com até 720 linhas (lembrando que a alta definição no Brasil tem 1080 linhas). Para o Brasil, a Zinwell está em vias de lançar um equipamento similar, mas com capacidade de armazenamento e sem cliente Torrent.
Três dias depois, no dia 29, a Suprema Corte dos Estados Unidos liberou a operadora Cablevision a oferecer um serviço de gravação remota de conteúdo aos seus assinantes. Com isso, o telespectador pode gravar programas sem a necessidade de ter um gravador digital em casa. Os estúdios de Hollywood, bem como radiodifusores norte-americanos, tentaram barrar a oferta da tecnologia, argumentando que, no caso de gravação remota, a operadora teria que pagar uma licença pelo uso deste conteúdo. No entanto, a Suprema Corte não considerou dessa forma, e agora a empresa está liberada para comercializar o serviço de gravação, que vai concorrer com o Tivo, equipamento que grava localmente os programas.
A gravação remota traz um dado novo ao mercado audiovisual, uma vez que a comercialização não é mais feita através de equipamentos, mas sim oferecendo um serviço. De certa forma, trata-se de colocar inteligência nos receptores, dispensando qualquer tipo de parafernália tecnológica. A tão falada supervia da informação parece estar ganhando contorno práticos e mercadológicos, onde a infraestrutura de oferecimento de conteúdos está cada vez mais centrada nos serviços, deixando os equipamentos de lado. Isso representa uma enorme dor de cabeça para a visão tradicional e conservadora das empresas de comunicação, que não estão mais conseguindo garantir e reservar o mercado. A evolução das tecnologias está se sobrepondo ao poder político inerente à atividade da radiodifusão.
Aliado a isso, já tem muitas empresas, inclusive no Brasil, oferecendo locação de filmes on line, sem DVD ou fita VHS. O vídeo é alugado acessando um banco de dados através da internet e assistido da mesma forma. São mostras de conforto que o telespectador busca, e que mais cedo do que muitos esperam, irão alterar consideravelmente a oferta de conteúdo em alta qualidade, coisa que a internet ainda não tem conseguido fazer.
Esses exemplos, aparentemente sem relação com a TV digital, tem tudo a ver com o tema e podem definir inclusive se a TV digital e a interatividade terão sucesso ou não. É preciso ter isso em mente quando pretendemos criar e colocar ima interatividade no ar. Por que o telespectador/usuário vai usar e gastar tempo diante dessa programação interativa se tem acesso a outras tecnologias que podem ser mais atrativas?
A interatividade na TV se insere em um modelo social em que há concorrência com inúmeras outras mídias, como a internet, telefones celulares que mais parecem pequenos computadores, dispositivos de captura de conteúdo como os descritos acima, entre várias outras. Essa concorrência, muitas vezes ilegal, interfere diretamente no tipo de programação que as TVs estão oferecendo. Nos próximos textos iremos mesclar textos técnicos sobre NCL e aprofundaremos esse cenário, onde a criatividade e a percepção do que pode dar certo e no que vale a pena investir farão a diferença.

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.