Artigo originalmente publicado no Portal Imasters.

Como já visto em textos anteriores, nem sempre é possível antecipar a ação do usuário diante da aplicação. Podem acontecer casos em que os usuários sigam caminhos diferentes ou mesmo executem aplicações diferentes durante um mesmo programa de TV. Neste caso, pode ser necessário saber em que estágio está a aplicação em execução e quais as ações feitas pelo telespectador. Isso é feito com uso de variáveis, que podem ser armazenadas para uso posterior, incluindo testes de estado da aplicação. Também é possível fazer jogos bem sofisticados com esse recurso.

A linguagem NCL, apesar de ser declarativa, chega a níveis de sofisticação e complexidade relativamente altos. O uso de variáveis permite o desenvolvimento de aplicações bastante complexas, com identificação do perfil do usuário, seu local, tipo de dispositivo, e adaptação do conteúdo a essas características. Durante uma programação de TV qualquer, é possível adaptar o conteúdo ao perfil do telespectador, usando apenas programação na linguagem NCL.

Para tanto, vamos usar o elemento nó de mídia x-ginga-settings, regras que definem a apresentação e switches com alternativas para a apresentação. Todos trabalham de forma integrada, sendo usados pelos links através de conectores. A apresentação da aplicação pode ser feita de duas formas: usando um contexto chamado switch ou testando as variáveis a cada uso. Neste exemplo vamos mostrar como usar o switch. Para tanto, vamos dividir o texto em duas partes: hoje apresentaremos os conceitos mais importantes, e no próximo texto discutiremos um exemplo de um comercial que se adapta ao perfil do usuário: homem ou mulher. O teste de variáveis fica para um segundo momento.

Elemento x-ginga-settings

Trata-se de um tipo de nó de mídia utilizado para agrupar variáveis definidas pelo autor do documento ou reservadas pelo sistema. Em ambos os casos, as variáveis podem ser utilizadas nas regras ou testadas. No exemplo abaixo, a primeira variável é de sistema, e define a linguagem configurada. A segunda é definida pelo autor do documento, visando, neste caso, estabelecer uma regra para testar o perfil do usuário.

<media id=”nodeSettings” type=”application/x-ginga-settings”>
<property name=”system.language”/>
<property name=”sexo”/>
</media>

Os valores não reservados são atribuídos através de links usando conectores.

Regras

As regras são definidas dentro do cabeçalho, em uma seção <ruleBase>, tal qual as regiões, descritores e conectores. Cada regra deve possuir um identificador único, uma referência a uma propriedade do objeto settings, um operador de comparação e um valor. Segue um exemplo:

<ruleBase>
<rule comparator=”eq” id=”r1″ value=”mulher” var=”sexo”/>
<rule comparator=”eq” id=”r2″ value=”homem” var=”sexo”/>
</ruleBase>

Os comparadores podem ser:
eq - igual a (equal to)
ne - diferente de (not equal to)
gt - maior que (greater than)
lt - menor que (less than)
gte - maior ou igual a (greater than or equal to)
lte - menor ou igual a (less than or equal to)

No exemplo acima, caso a variável “sexo” seja “homem”, a regra “r2” era verdadeira, executando a mídia correspondente no switch, descrito abaixo.

Além das comparações, é possível combinar regras para atingir um objetivo mais preciso, usando <compositeRule>. Por exemplo, checar o idioma da legenda e a língua da dublagem em que o telespectador está assistindo um determinado filme. Isso pode ser útil para direcionar comerciais, que podem usar o mesmo idioma e a mesma dublagem do filme.

Switch

Trata-se de uma composição contendo nós alternativos, que serão executados de acordo com as regras. Um switch pode conter qualquer tipo de nó: de mídia, de contexto ou mesmo outros switches. Assim, é preciso definir todas as possibilidade de execução dos nós, e relacionar cada uma com uma regra. Se a regra for verdadeira, executa o nó correspondente.
Ou seja, um switch seleciona um conteúdo de acordo com uma regra. Isso é útil para adaptar diferentes conteúdos a perfis de usuário. No entanto, também é possível adaptar o conteúdo para aparecer em diferentes áreas da tela, caso a área original já esteja ocupada com outra aplicação. Por exemplo, se o filme estiver sendo assistido com legenda, o comercial aparece na parte superior da tela. Caso contrário, na parte inferior. Isso é feito através do <descriptorSwitch>.

No próximo texto detalharemos um exemplo onde um anúncio é diferente para cada tipo de audiência.

Artigo originalmente publicado na minha coluna do Portal Imasters.

A TV interativa, assim como todas as mídias dependentes da participação do usuário, tem de lidar com a imponderabilidade da ação humana. Tal qual a internet, nada acontece com as aplicações interativas na TV se o usuário não tomar nenhuma atitude. Conforme discutido no texto anterior, a audiência da televisão tem posturas diferentes dos usuários da internet. Essas posturas interferem no tipo de conteúdo mais adequado a cada mídia.

Na televisão atual estamos acostumados a ficar assistindo à programação com pouca ação diante da TV. Podemos mudar de canal, regular o volume, enviar um SMS ou um e-mail para a emissora, desligar a TV. A emissora de televisão não tem como saber quando e se qualquer uma dessas ações vai ocorrer. O mesmo é válido para uma interatividade. É possível sinalizar que ela está disponível, mas não é possível obrigar a pessoa a interagir.

Dessa forma, além de determinar claramente o público-alvo do serviço ou da aplicação, é extremamente importante entender o que esse público espera de uma aplicação interativa, e caso não espere nada ou desconheça essa nova funcionalidade, o que o atraia à interatividade. Dentro da nova realidade da televisão, pode-se identificar quatro tipos de comportamentos diante da nova programação:

1. Pessoas que vão querer continuar assistindo à TV da mesma forma como assistem hoje, sem interagir.
2. Pessoas que não vão querer assistir a mais nenhum programa sem interatividade.
3. Pessoas que ora vão interagir, ora vão preferir ficar passivas.
4. Pessoas que vão apenas usar os novos recursos, sem sequer assistir à TV.

Esses quatro tipos de usuários demandam aplicações diferentes, com graus de interatividade também diferenciados. O primeiro grupo, que ainda precisa de convencimento para usar, demanda aplicações mais simples, que antes de se aprofundarem na informação precisam trazer o usuário à interatividade. Nesse caso, a linguagem que agregue a interatividade à programação tem grande importância.

Já para o segundo grupo, a qualidade das aplicações e a informação transmitida são mais pertinentes do que a linguagem usada para a interatividade. O desafio passa a ser oferecer programas concebidos em harmonia com a interatividade, onde haja disposição ordenada das informações e ações demandadas pelo usuário.

O maior problema é conceber aplicações para um público cujo comportamento é uma incógnita, e que no momento da transição da TV analógica para o modelo digital tende a ser a maioria dos usuários. Nesse caso corre-se o risco de oferecer aplicações muito simples para determinado público ou muito complexas para outro. É o mesmo desafio dos programas de TV aberta, onde a audiência é composta pelos mais variados segmentos sociais e culturais.

O último grupo, em tese, é o mais fácil de ser atendido, uma vez que as aplicações demandadas pelo público desinteressado na televisão se aproximam muito da internet. No entanto, trata-se de um público que assiste cada vez menos à televisão, preferindo usar a web. A interatividade, de certa forma, pode ser interpretada como uma possibilidade para trazer esse público de volta para a televisão.

Gerações mais novas, notadamente com menos de 25 anos, não têm mais paciência para ver programas de TV durante uma hora ou mais. Preferem algo mais ativo para se entreter. É onde entra a internet, ou as atividades chamadas multitarefa, onde o telespectador faz várias coisas além de ver TV.

Esse comportamento incerto do telespectador está previsto no middleware Ginga, que pode adaptar aplicações interativas para diferentes perfis de usuário e dispositivos de exibição (não apenas aparelhos de TV, mas também computadores e celulares). Para tanto, é necessário o uso de regras e variáveis para definir essa adaptação. As regras e variáveis serão tema do nosso próximo texto.

Aproveitando o ensejo, semana passada foi lançado o livro TV Digital.Br: Conceitos e Estudos sobre o ISDB-Tb (Editora Ateliê, R$ 38,00), organizado pelo professor Sebastião Squirra e por mim. A obra discute, de forma interdisciplinar, a introdução da TV digital no Brasil e as consequências para diferentes áreas do conhecimento. Apesar de já sair um pouco desatualizado devido à velocidade com que a evolução das tecnologias acontece, trata-se de uma boa referência para quem estiver interessado em compreender melhor os desdobramentos e impactos da digitalização da TV aberta brasileira.

Artigo originalmente publicado no Portal Imasters.

Quando se fala em TV interativa, é usual buscar conceitos e conteúdos na internet ou em programas para computadores. Analisando os exemplos de aplicações disponíveis online com foco no Ginga, percebe-se claramente um viés de internet na maioria deles.

Apesar de um set top box ser um computador, do ponto de vista da arquitetura, seus usos variam consideravelmente sobre vários aspectos. Inicialmente, o oferecimento do conteúdo da internet é feito sob demanda, enquanto que na televisão ele é transmitido por broadcast. Essa diferença impacta no tempo, pois na web o conteúdo fica disponível, enquanto que na TV, com raras exceções de gravação, o conteúdo transmitido não poderá ser recuperado.

Essa postura diante da TV gera hábitos de consumo com horários estabelecidos pela programação televisiva. Isso leva à constatação de que a mídia TV é mais voltada para o entretenimento, sendo raramente utilizada para fins profissionais. Já a postura diante de um computador ou da internet, varia. O entretenimento e o uso profissional são intercalados, com predominância do último. Além disso, a televisão normalmente é assistida coletivamente, em família ou com amigos, ao contrário de um computador que, com exceção de alguns jogos, sempre é usado individualmente.

Essas diferenças de uso se originam de dois pontos: a imagem entrelaçada dos monitores de TV analógicos é melhor percebida a uma distância de sete vezes a altura do monitor. Já os monitores de computador não têm essa necessidade, sendo utilizados a uma distância média de 50 centímetros. Além disso, a televisão tem apenas o controle remoto para interação, enquanto que um computador tem mouse, teclado, impressora, conexões de rede e uma série de outros dispositivos que podem ser conectados pela interface USB.

Finalmente, o uso cultural da televisão pode ser considerado como um fim em si, onde o simples fato de a TV estar ligada representa uma presença na casa. A televisão não é necessariamente ligada para que um programa seja assistido mas, muitas vezes, apenas para dar a sensação de presença, pelo diálogo que ela enseja.

Por isso, aplicações para TV sempre precisam considerar as limitações da interface e os contextos de uso. A resolução de uma TV de tubo é de no máximo 720X480, com construção entrelaçada dos quadros. Isso significa que primeiro as linhas ímpares são mostradas na tela e depois as pares, o que complica muito a leitura de textos longos. Mesmo na TV analógica, as emissoras usam pouquíssimos textos, sempre curtos. Identificação de pessoas, escalações de times esportivos, dados estatísticos, transcrições de fitas, entre outros, são feitos em blocos pequenos de texto, com fonte grande, superior a 20 pontos, na maioria dos casos.

Além disso, a maioria dos possíveis usuários da televisão interativa não têm experiência com internet. Pesquisas mostram que, no Brasil, 61% da população nunca usou um computador. E quem tem acesso à internet não deseja ver replicado na TV interativa o sistema de navegação ou mesmo o conteúdo da internet. Semelhanças com computadores não são bem aceitas.

Texto na TV

As interfaces das aplicações interativas começam e terminam pela compreensão das informações dispostas na tela da TV. Por isso, todos os manuais e guias de estilo descrevem tipologias que preenchem requisitos mínimos de leitura. Há muitas semelhanças entre fontes e tamanho da letra entre as aplicações interativas que foram ao ar na Europa.

A programadora de satélite brasileira Sky, primeira a oferecer interatividade pela TV no país, usa fontes que se assemelham com a variante condensada da família de tipos Frutiger. Já a emissora britânica BBC sugere, em seu guia de estilos, o uso dos tipos Gill Sans e Tiresias. Veja exemplos de tipos destas famílias em corpos 36, 24 e 18 pontos.

É importante ressaltar que a fonte Tiresias foi projetada pelo Royal National Institute for the Blind para que tivesse caracteres facilmente distinguíveis uns dos outros. Segundo o instituto britânico, o projeto foi realizado com atenção específica às pessoas com deficiências visuais, com a filosofia de que um bom projeto para deficientes visuais é um bom projeto para todos. Devido a essas características, o tipo Tiresias foi adotado como fonte padrão para as aplicações em MHP e, por essa razão, já vem sendo implementada nos set-top boxes de diversos fabricantes europeus.

Em seu guia de estilos, a BBC traz sete importantes considerações a respeito da legibilidade em monitores de televisão. Segundo a emissora britânica:

1. O corpo dos textos, na maioria dos casos, não deve usar tipos menores que 24 pontos;
2. Nenhum texto, em qualquer circunstância, deve ter tipos menores que 18 pontos;
3. Textos claros em fundos escuros são ligeiramente mais legíveis na tela;
4. Textos na tela necessitam de entrelinhas maiores que textos impressos;
5. Quanto tecnicamente possível, o espaço entre os caracteres deve ser aumentado em 30%;
6. Uma tela completa de textos deve conter o máximo de 90 palavras aproximadamente;
7. Os textos devem ser divididos em pequenos blocos para que possam ser lidos instantaneamente;

Ao analisar a programação da SKY interativa veiculada no Brasil, é possível perceber que outros tamanhos de fonte também funcionam. Das sugestões trazidas pela BBCi, as três primeiras são as menos seguidas nas aplicações brasileiras, tanto da Sky quanto da NET digital. Em todas as interfaces de aplicações veiculadas pelas TVs por assinatura brasileiras nota-se o uso de textos de tamanhos inferiores aos sugeridos pela emissora britânica.

De um modo geral, os textos principais e os menus de opções são apresentados com 20 pontos, ou seja, 15% menores que o indicado. Já os títulos de seções variam entre 20 e 24 pontos, ficando também, em alguns casos, abaixo do padrão britânico. Porém, o caso mais grave fica por conta dos botões que indicam ações importantes como sair, retornar, confirmar e ajuda. Na grande maioria das interfaces analisadas, esses botões eram representados com 16 pontos. Em muitas aplicações, os textos dos botões eram diminuídos a apenas 12 pontos e raramente chegavam a 18 pontos - tamanho mínimo sugerido pela BBCi.

Outra regra a ser também desconsiderada em solo brasileiro é a do emprego de textos claros em fundos mais escuros, pois em muitas das interfaces analisadas estes são apresentados de forma justamente oposta.

Apesar de as interfaces não seguirem à risca os padrões britânicos, alguns testes de legibilidade realizados em televisores de 14 polegadas revelam que os textos principais dessas interfaces são perfeitamente legíveis a cerca de 1 metro de distância. Entretanto, é importante observar que, em virtude de seu tamanho, o mesmo não se aplica aos textos dos botões. Cabe lembrar ainda que a distância de leitura observada para os textos principais das aplicações em televisores de 14 polegadas chega quase ao dobro da distância de observação recomendada para esse tipo de aparelho.

Para finalizar, é preciso lembrar que as recomendações acima são aplicáveis apenas em TVs de tubo. As TVs de LCD e plasma necessitam de tratamentos e enfoques diferentes.

Artigo originalmente publicado no Portal Imasters.

Finalmente saiu o primeiro livro sobre programação para a TV digital brasileira, especificamente para o middleware Ginga. Os professores da Puc-Rio Luiz Fernando Gomes Soares e Simone Diniz Junqueira Barbosa acabam de lançar “Programando em NCL 3.0: desenvolvimento de aplicações para o middleware Ginga” (Editora Campus, R$ 125,00). O livro aborda, de forma ampla e completa, a linguagem NCL, permitindo que iniciantes no assunto se familiarizem com o tema e que especialistas consultem exemplos avançados de uso de variáveis e múltiplos dispositivos.

Em 340 páginas de texto, distribuídas em 18 capítulos, mais 140 páginas de apêndices, os autores dissecam a linguagem NCL, começando por definições pertinentes ao desenvolvimento de aplicações. Nos primeiros capítulos, que compõem a parte um, o tema é apresentado, com detalhamento da importância e da função de um middleware em TV digital, passando pelo modelo conceitual que embasa a linguagem e nos componentes da mesma.

A parte dois é dedicada à apresentação de cada elemento e cada atributo da linguagem, com base no perfil EDTV. Com vários exemplos, os autores discutem a estrutura de aplicações bem simples e avançam paulatinamente na complexidade, o que facilita a compreensão. O final desta parte já entra em conceitos um pouco mais avançados, como adaptação de aplicações durante a execução, regras e reuso de elementos.

Finalmente, na terceira parte, os autores apresentam as inovações do middleware Ginga e como elas podem ser incorporadas nas aplicações. São apresentados exemplos de aplicações para programas ao vivo, para múltiplos dispositivos e aninhamento de objetos importados, escritos em outras linguagens como Lua.

O livro é completado com dois CDs: um emulador Ginga Live, versão 1.1, que permite testar as aplicações desenvolvidas no próprio PC, e uma série de slides com ilustrações e imagens referentes aos temas abordados nos capítulos. São ótimos para uso em sala de aula. Além disso, acompanha um arquivo pdf com os apêndices, que detalham, em linguagem bem acessível, conceitos como compressão e transmissão de dados, modelo NCM, exemplos de conectores, NPT (Normal Play Time), edição ao vivo, procedimentos de escalonamento, entre outros.

Apesar de ser um livro sobre programação, a estrutura dos textos permite que ele seja utilizado também para compreender o funcionamento da interatividade na TV digital. Os apêndices agregam conteúdos sobre a dinâmica da transmissão de dados e como eles são tratados tanto no transmissor quanto no receptor.

Além disso, a forma como o desenvolvimento é apresentado possibilita o uso por pessoas não muito familiarizadas com lógica de programação. Os exemplos são úteis para programar e desenvolver conteúdos apenas adaptando os mesmos, copiando e colando partes, técnica muito comum com programadores iniciantes. A maioria dos exemplos discutidos no livro podem ser baixados no Clube NCL e no Portal do Software Público, na Comunidade Ginga. Os exemplos são distribuídos com licenças Creative Commons.

Artigo publicado originalmente no Portal Imasters

O congresso da SET deste ano, aliado a feira Broadcast & Cable, mostrou um dado interessante sobre o pensamento e comportamento do setor audiovisual diante de temas como interatividade e acesso ao conteúdo pela web. Por um lado, foram apresentadas várias aplicações, explicados por executivos das emissoras como uma nova forma de comunicação com a audiência. Por outro lado, o receio de que concorrência com a internet comprometa o modelo de negócios atual da radiodifusão permeou os debates.

O tema interatividade predominou novamente, tal como já acontecera no ano passado. Várias emissoras e empresas mostraram aplicações interativas no ar e sendo recebidas por set top boxes comerciais, cujo início das vendas está previsto para novembro deste ano. A norma do Ginga está concluída, faltando acertar apenas pequenos detalhes sobre a versão do Java que será obrigatório e publicar a mesma. Depois disso, os receptores poderão ser oficialmente comercializados.

As aplicações transmitidas ainda estão bastante simples no conteúdo que oferecem e nos recursos utilizados. No entanto, são de complexo uso. O tem usabilidade ainda passa longe do desenvolvimento, com interfaces voltadas para quem domina a navegação da web. Houve stands em que o responsável pela demonstração não conseguia usar a aplicação devido a problemas de interface. Imagine o público leigo, ou os 61% da população brasileira que nunca acessaram a internet…

Portal de interatividade do SBT

Aplicativo “A Fazenda”, da Record

No entanto, o que chamou a atenção na maioria dos paineis do congresso foi a forma como a interatividade está sendo tratada. Pela primeira vez, o broadbandTV (acesso à TV por banda larga) contagiou os debates, sendo interpretado como oportunidades por alguns e como preocupação para muitos.

Os radiodifusores não se mostraram nem um pouco confortáveis, e, em alguns casos, até irritados, com o lançamento da Samsung, que colocou no mercado uma TV que acessa o Portal Terra e o Youtube, podendo sobrepor os vídeos à programação das emissoras. Assim, é possível assistir gratuitamente a qualquer série disponível nos portais, a qualquer momento, pela televisão. Se as emissoras já estão se debatendo com concorrências ferrenhas entre elas mesmas, agora há um inimigo comum: o conteúdo da web.

Além disso, o modelo boradbandTV permite colocar widgets (pequenos aplicativos que se sobrepõe a interface e acessam serviços em outros sites, como previsão do tempo, posts no Twitter etc.) sobre a programação das emissoras, gerando conflito de atenção. Dessa forma, a tela da TV pode ser divida em funções semelhantes à tela de um computador, onde o próprio telespectador/usuário escolhe o que como deve ser a interface. Isso se acentua com a comercialização, ainda incipiente no Brasil, mas comum na Europa e EUA, dos media boxes, caixas que centralizam todo conteúdo audiovisual da casa. São computadores ligados à TV apenas para gerenciar o que será visto e como.

A reação imediata a essa possibilidade tecnológica foi o fortalecimento do Ginga, visto agora não mais como um recurso da TV digital, mas como elemento central para a sobrevivência do modelo tradicional de radiodifusão atual. Percebeu-se finalmente que as novas mídias são todas interativas e não convivem com atitudes passivas do usuário. A televisão não pode ser diferente. O hábito de ver TV isoladamente, parando todas as demais atividades em função do que está passando na telinha não existe mais entre os jovens. O acesso à internet está cada vez mais presente e agregado à atividade ver TV.

Parece que finalmente o setor de radiodifusão acordou para a evolução tecnológica. A tecnologia está evoluindo muito mais rapidamente do que o setor gostaria, o que gera estratégias de incorporação dos novos recursos ao quotidiano das emissoras. Por um lado, a radiodifusão se opõe radicalmente a presença de conteúdo da web sobre o seu vídeo, e por outro avança no oferecimento de seus conteúdos na web.

Essa política traz um dado novo sobre a convergência entre TV e web, muito apregoada há anos. A convergência entre essas duas mídias já é uma realidade, mas ao contrário do que se acreditava, não está baseada nos serviços que a web oferece, e sim nos vídeos que a televisão oferece. A TV é uma mídia muito maior que a web, seja em acessos (o site mais acessado no Brasil daria traço na medição de audiência da TV), no faturamento, ou na qualidade dos conteúdos produzidos. As iniciativas de colocar redes sociais ou outros serviços tradicionais de internet (como e-mail, acesso a banco etc.) na TV não surtiram muito efeito, tendendo a serem marginais no processo de convergência. Agora, o oferecimento de vídeos por parte das emissoras levou a internet a outro patamar, com conteúdo melhores e mais profissionais (os sites mais acessados no Brasil estão relacionados ao oferecimento de conteúdos em vídeo não gerado por usuários, principalmente notícias).

Além disso, o amadurecimento das ferramentas de publicação dos vídeos na internet e o aumento da banda disponível para os usuários finais estão gerando um novo mercado, totalmente desregulamentado, que pode, sim, concorrer em relevância e qualidade com as emissoras de TV. Isso preocupa o setor de radiodifusão. Como exemplo, ano passado, nas Olimpíadas de Berlin, as emissoras abertas Globo e Band ofereciam no máximo duas opções de transmissões simultâneas de eventos esportivos, quando a grade entre as duas não coincidia. O portal Terra chegou a transmitir 13 eventos simultaneamente. A partir de agora, esses eventos estarão acessíveis também pela TV, concorrendo com as emissoras abertas, que não tem como aumentar muito a oferta (o espectro é limitado, ao contrário da internet) e ainda lutam contra a multiprogramação.

É uma luta desleal, que novamente opõe o poder político das emissoras de TV, com o poder econômico das empresas de telecomunicações, tal qual aconteceu na escolha do sistema brasileiro de TV digital.

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.

Texto publicado inicialmente no Portal Imasters

Este texto continua a abordagem sobre sincronismo de mídias, apresentando os princípios da construção de conectores e introduzindo os links.

Neste texto iremos discutir as relações de sincronismo a partir da criação de conectores e links. Na linguagem NCL tudo é determinado a partir de uma causa. Ou seja, cada ação é precedida por outra; uma condição deve obrigatoriamente ser satisfeita para disparar uma ação.
Assim, todo sincronismo no espaço e no tempo segue uma lógica causal. Para determinar as relações de causa e efeito, precisamos definir conectores. Conectores são expressões que ligam uma condição a uma determinada ação. Assim, todo conector possui ao menos uma condição e uma ação. Por exemplo: quando o vídeo chegar em determinado ponto (condição) coloca uma imagem na tela (ação); quando a imagem iniciar (condição) redimensiona o vídeo (ação); quando o telespectador apertar um botão no controle remoto (condição), inicia a interatividade (ação). Resumindo: conectores são utilizados para especificar relações de sincronização espaço-temporais, tratando relações de referência (de interação com usuário) como um caso particular de relações de sincronização temporal.

A única exceção para essa relação causal é no início da aplicação. Portanto, a primeira ação é definida arbitrariamente pelo desenvolvedor, através do elemento <port> do <body>. Para exemplificar, vamos criar um conector que defina uma ação para quando algo iniciar. Por exemplo, quando um nó de mídia aparecer na tela, deve aparecer outro no mesmo instante. Lembrando que os conectores devem ser criados na base de conectores, dentro do cabeçalho.

Assim:
<connectorBase>
<causalConnector id=”onBeginStart”>
<simpleCondition role=”onBegin”/>
<simpleAction role=”start”/>
</causalConnector>
</connectorBase>

Neste conector temos a condição definida como <simpleCondition> “onBegin” (ou seja, quando começar) e a ação definida como <simpleAction> “start”. Este conector possui apenas uma condição e uma ação. No entanto, tanto as condições quanto as ações podem ser compostas. Nesse caso, temos uma <compoundCondition> e uma <compoundAction> como elementos pai de <simpleCondition> e <simpleAction>, respectivamente . A primeira pode ser qualificada como “or” ou “and”. Isso significa que, no caso “or” uma das condições precisa ser satisfeita para ocorrer a ação; já em “and” ambas precisam ser atendidas. Por exemplo: se o telespectador apertar o botão vermelho do controle remoto e o vídeo estiver redimensionado, começa um joguinho. Só o fato de apertar o botão não dispara a ação. O vídeo precisa estar redimensionado.

Além disso, podemos definir um retardo (delay) para a condição, especificando que a condição é verdadeira após um período de retardo a partir do momento em o evento ocorre.

Já as ações compostas são mais simples, podendo ocorrer em paralelo “par” ou em sequência “seq”. Da mesma forma como nas condições, um atributo delay pode também ser definido para a <simpleAction>, especificando que a ação só pode ocorrer após esperar pelo tempo pré-definido. Além disso, também pode ser definido um atributo repeat para ser aplicado ao atributo repetitions do evento, e um atributo repeatDelay, para ser aguardado antes da repetição da ação. Além de todos os atributos acima citados, o elemento <simpleAction> também pode ter atributos definidos na área funcional Animation (atributos duration e by). Assim é possível fazer animações simples em NCL.

Os conectores definem relações de causa e efeito. A atribuição das relações com as mídias é feita nos <links>, dentro do <body> do documento. Para testar nosso conector, vamos pegar o exemplo do texto anterior (Interatividade, sincronismo e documentos NCL), cujo objetivo era colocar um botão na tela. Esse botão foi definido arbitrariamente através do uso da porta (<port>) do contexto principal (<body>). Agora, outro botão deve aparecer simultaneamente.
Vamos declarar mais uma mídia, com ID Botao2, lembrando que deve ter um descritor e uma região associados, e fazer esse botão aparecer junto com o botão vermelho.

<link xconnector=”onBeginStart”>
<bind component=”botao” role=”onBegin”/>
<bind component=”botao2″ role=”start”/>
</link>

Neste link estamos afirmando que quando o nó de mídia “botao” começar, deve inciar também o nó “botao2”. Isso é feito através do uso do conector declarado na base de conectores “onBeginStart”, onde definimos as condições e as ações. No link ligamos as mídias a estas condições e ações, usando “binds”. O “bind” tem um componente, que é a mídia, e um papel, que é definido no conector.
O código completo da aplicação deve estar assim:

<ncl id=”new_ncl_file” xmlns=”http://www.ncl.org.br/NCL3.0/EDTVProfile”>
<head>
<regionBase>
<region height=”50″ id=”rgBotao” left=”25″ top=”25″ width=”50″/>
<region height=”50″ id=”rgBotao2″ left=”100″ top=”100″ width=”50″/>
</regionBase>
<descriptorBase>
<descriptor id=”dBotao” region=”rgBotao”/>
<descriptor id=”dBotao2″ region=”rgBotao2″/>
</descriptorBase>
<connectorBase>
<causalConnector id=”onBeginStart”>
<simpleCondition role=”onBegin”/>
<simpleAction role=”start”/>
</causalConnector>
</connectorBase>
</head>
<body>
<port component=”botao” id=”pBotao”/>
<media descriptor=”dBotao” id=”botao” src=”media/botao_vermelho.png”/>
<media descriptor=”dBotao2″ id=”botao2″
src=”media/botao_verde.png”/>
<link xconnector=”onBeginStart”>
<bind component=”botao” role=”onBegin”/>
<bind component=”botao2″ role=”start”/>
</link>
</body>
</ncl>

As causas possíveis de serem descritas nos conectores são:
onBegin – quando começar
onEnd – quando terminar
onAbort – quando abortar
onPause – quando pausar
onResume – quando sair da pausa e começar a tocar
onSelection – quando for selecionado
onBeginAttribution – quando uma atribuição começar
onEndAttribution – quando uma atribuição terminar

Já as ações são:
start - comece
stop - pare
abort - aborte
pause - pause
resume - reinicie
set - configure

Dessa forma é possível concatenar causa e consequência, construindo relações de sincronismo e de interatividade. Podemos ter uma causa e várias consequências, assim como várias causas para apenas uma única consequência. Lembrando apenas que um conector pode ser utilizado quantos vezes for necessário e podemos ter quantos conectores precisarmos em um documento NCL. Nos próximos textos iremos aprofundar o tema sincronismo e começar a definir a participação do telespectador.

Texto originalmente publicado no portal imasters

Tabelas Lua.

As tabelas, em Lua, são estruturas de dados da linguagem. São comuns em outras linguagens, estruturas de dados do tipo vetor e lista. Porem, Lua possui somente as tabelas, pois são flexíveis e permitem combinações.

Este artigo visa tratar, de maneira introdutória, seu uso e suas propriedades.

Na verdade já tivemos contato com esta estrutura nos últimos artigos sobre a biblioteca NCLua. Como vimos, a biblioteca se baseia na troca de mensagens entre o formatador NCL e a máquina de execução Lua. Tal comunicação acontece através do envio e recebimento de tabelas Lua. Essas tabelas representam os eventos, que acontecem durante a execução da aplicação.

Relembrando:

Vimos que para um script Lua se comunicar com o documento NCL é necessário que uma tabela, específica, seja enviada através do comando event.post().

Por exemplo, para que um script Lua inicie uma ancora em um nó NCL, o seguinte evento deve ser gerado:

tabela = {
class = ‘ncl’,
type = ‘presentation’,
action = ‘start’,
label = ‘nome_ancora’
}

Então esta tabela deve ser enviada ao NCL:

event.post( tabela )

Outro exemplo. Cada vez que um botão de teclado ou de controle remoto é pressionado uma tabela é gerada, porem no sentido contrário, no sentido NCL para Lua, e as propriedades da tabela contem outros valores, como por exemplo, a propriedade class, que contem o valor ‘key’.

Tabelas Lua.

Até agora vimos seu uso apenas na interface de comunicação NCLua, veremos agora a essência das tabelas, quais suas principais características e funções dentro da linguagem Lua.

Para começar, temos que saber que uma tabela começa e termina com colchetes, dado seu identificador. Então uma tabela t vazia:

t = {}

Uma propriedade importante é saber o tamanho da tabela, e conseguimos isso através do uso de #.

> print (#t)
0

O seguinte exemplo cria uma tabela com valores:

carro = {
[‘cor’] = ‘cinza’,
[‘cilindradas’] = ‘1600’,
[‘ano’] = ‘2008’,
[‘modelo’] = ‘2009’,
}

Uma tabela é composta por uma coleção de chaves e valores. Onde cada chave esta associada um valor. No exemplo, as palavras entre [ ] são as chaves e os seus valores vem depois do sinal de =, e cada par é separado do outro por virgula.

Usando a tabela:

> print( carro[‘ano’] )
2008

>print( carro[ ‘portas’] )
nil

Caso o índice não exista na tabela o valor nil é retornado.

Flexibilidade:

Como disse no inicio, tabelas tem muita flexibilidade, os índices nem sempre precisam estar entre [ ]. Um outro jeito de escrever a tabela acima é:

carro = {
cor = ‘cinza’,
cilindradas = ‘1600’,
ano = ‘2008’,
modelo = ‘2009’,
}

Outro jeito de acessar os valores:

Dada a tabela, os seguintes meios de acesso aos valores:

ano = { mes = { dia = “quarta” } }

> print( ano.mes.dia )
quarta
> print( ano.mes[‘dia’] )
quarta

> print( ano[‘mes’][‘dia’] )
quarta

Índices implícitos

Índices numéricos são implícitos quando há ausência de declaração deles no corpo da tabela. Por exemplo:

tabela = {“a”, “b”, “c”}

Esta implícito que os índices de “a”, “b” e “c” são 1, 2 e 3 respectivamente. Portanto:

>print( tabela[1])
a

A função ipairs

Muitas vezes temos que fazer iterações sobre uma tabela inteira, tendo que acessar cada par (índice, valor) da tabela. Fazemos isso usando laços de controle como um bloco while ou for, por exemplo, e implicitamente declarando um valor de inicio e final para as iterações. Uma alternativa mais eficiente para iterar sobre um array ou tabela é a função ipairs.

Considere o seguinte array ou tabela:

> letras = { “a”, ”b”, ”c” }

Se quisermos imprimir cada índice e cada valor usando um bloco for faríamos desta maneira:

>for i = 1, #letras do
>> print(“índice: ” .. i .. “ valor: ” .. letras[i] )
>end
indice: 1 valor: a
indice: 2 valor: b
indice: 3 valor: c

De maneira similar mas usando ipairs:

>for i, n in ipairs( letras ) do
>> print(“índice: ” .. i .. “ valor: ” .. n )
>end
indice: 1 valor: a
indice: 2 valor: b
indice: 3 valor: c

O trecho de código in ipairs( tabela ), sugere um loop sobre a tabela passada como parâmetro. A função percorre a tabela de maneira ordenada, atribuindo o índice ao primeiro parâmetro passado antes de in, que é i, e passa o valor correspondente para o segundo parâmetro, n.

Importante notar que a função ipairs percorre índices numéricos sem intervalos. Isto quer dizer que dada a tabela

> letras = { “a”, b, ”c” }

a função iria ate o primeiro índice apenas, pois o índice de b não é 2.

A biblioteca table

A linguagem ainda oferece outras funções básicas. A seguir listo algumas:

table.sort (tabela) – ordena uma tabela.
table.insert (tabela, valor) – insere o valor na tabela, na ultima posição.
table.remove (tabela, valor) – remove o valor na tabela, na ultima posição.

Bibliografia

Os conceitos vistos acima são o básico que devemos saber sobre o uso de tabelas. Para saber mais sobre o assunto recomendo a consulta aos seguintes livros:

e

Ainda no site lua.org você encontra os binários para executar seus programas em Lua, para que usa Windows tem uma opção la também, basta baixar e executar o .exe.

Artigo inicialmente publicado no Portal Imasters.

Este artigo introduz a linguagem de programação declarativa do ISDB-Tb, já padronizada e definida como componente da TV digital brasileira.

A NCL é definida por duas normas da ABNT como linguagem declarativa do ISDB-Tb: a NBR 15606 Parte 2: Ginga-NCL para receptores fixos e móveis – Linguagem de aplicação XML para codificação de aplicações; e NBR 15606 Parte 5: Ginga-NCL para receptores portáteis – Linguagem de aplicação XML para codificação de aplicações. Dessa forma, dúvidas sobre os recursos e possibilidades de uso devem ser tiradas nesses documentos. A consulta de outros documentos disponíveis on line também é válida, mas mantende a ressalva de que eles podem não estar compatíveis com a norma, uma vez que foram gerados anteriormente às definições da ABNT, que, por sugestão do Fórum do SBTVD, fez uma série de alterações nos recursos.
A linguagem NCL está estrutura de forma a colar as mídias da aplicação no tempo e no espaço. Explicando melhor, com a NCL não é possível criar nada, apenas gerenciar. Dessa forma, é preciso criar as mídias das aplicações em outras ferramentas e determinar onde as mídias irão aparecer (em quais regiões), como, quando.
A norma NBR 15606-2 explica que um documento NCL apenas define como os objetos de mídia são estruturados e relacionados no tempo e espaço. Como uma linguagem de cola, ela não restringe ou prescreve os tipos de conteúdo dos objetos de mídia. Nesse sentido, pode-se ter objetos de imagem (GIF, JPEG.), de vídeo (MPEG), de áudio (MP3,), de texto (TXT, HTML), de execução (Xlet, Lua), entre outros, como objetos de mídia dentro de documentos NCL. A linguagem faz o gerenciamento dessas mídias. Quais objetos de mídia são suportados depende dos exibidores de mídia que estão acoplados ao formatador NCL (exibidor NCL), ou seja, depende da implementação do Ginga (ambientes reais) ou do emulador (ambientes de teste em computadores). Um desses exibidores é o decodificador/exibidor MPEG-4, normalmente implementado em hardware no receptor de televisão digital. Dessa forma, o vídeo e o áudio MPEG-4 principal são tratados como todos os demais objetos de mídia que podem estar relacionados utilizando NCL. Assim, é possível utilizar NCL para gerenciar todos os recursos do receptor.
Além disso, pensando na interoperabilidade, um outro objeto de mídia NCL deve obrigatoriamente ser suportado: o objeto de mídia baseado em XHTML. A NCL não substitui, mas embute documentos (ou objetos) baseados em XHTML. Como acontece com outros objetos de mídia, a implementação do NCL define o suporte.
Assim, é possível ter navegadores de outros middlewares, como BML, DVB-HTML e ACAP-X individualmente embutidos em um exibidor de documento NCL. É possível também ter todos eles. É igualmente possível receber o código de um programa navegador através da difusão de dados e instalá-lo como plug-in (normalmente um plug-in Java). Também é possível ter um navegador genérico implementado e, se necessário, receber a parte complementar (específica) como um plug-in, para converter o exibidor XHTML genérico em um exibidor específico de um dos diversos padrões de navegadores de TV digital.
Em último caso, um documento NCL pode ser reduzido para conter apenas um objeto de mídia XHTML. Nesse caso, o exibidor do documento NCL atua quase como um navegador XHTML, isto é, como qualquer outro navegador dos padrões supracitados. Da mesma forma, é possível tratar programas feitos em Java (NCLet), Lua (NCLua). Por exemplo, é possível fazer uma aplicação inteira em Lua, onde o NCL apenas a executa no momento definido pelo programador.
Durante a exibição do conteúdo de objetos de mídia são gerados vários eventos. A apresentação de parte do conteúdo de um objeto de mídia, e a seleção de parte do conteúdo de um objeto são exemplos. Os eventos podem gerar ações sobre outros objetos de mídia, como iniciar ou terminar suas apresentações. Portanto, os eventos devem obrigatoriamente ser relatados pelos exibidores de mídia ao formatador NCL que, por sua vez, pode gerar ações a serem aplicadas a esses ou outros exibidores. Ginga-NCL define a API de um adaptador com o objetivo de padronizar a interface entre o formatador Ginga-NCL e cada exibidor específico.
A NCL admite as seguintes mídias:

Os próximos artigos irão tratar do uso dessas mídias, da estrutura modular, da sintaxe e organização da linguagem.

Artigo publicado no portal Imasters

A linguagem NCL está estruturada para organizar mídias. Dessa forma ela gerencia o comportamento de mídias no tempo e no espaço. Como já comentado em artigo anterior, não é possível criar nada através da NCL; tudo deve ser desenvolvido em outros ambientes. A linguagem é responsável por colar essas mídias umas nas outras, o que determina o comportamento da aplicação através da atribuição de condições e ações. Assim, uma aplicação para TV digital pode ter apenas elementos de sincronismo das mídias, sem qualquer participação do usuário.

Antes de entrarmos em detalhes, vamos separar a interatividade das ações de sincronismo no tempo e no espaço sem participação do usuário. Tecnicamente, a interatividade se caracteriza por uma ação do usuário através do controle remoto que gera um retorno no sistema de TV digital. Dessa forma, pode aparecer, por exemplo, um botão vermelho na tela da TV informando que há uma interatividade disponível (para quem possui TV por assinatura digital esse recurso é amplamente explorado). Ao apertar o botão vermelho do controle remoto o set top box responde parando esse botão vermelho e inicia a interatividade correspondente.

Por esse exemplo, podemos perceber que o botão vermelho apareceu sozinho. Ou seja, isso não foi interatividade. Apenas uma relação de sincronismo no tempo e no espaço. No tempo porque o botão apareceu em um determinado tempo do vídeo, que pode ser definido pela emissora de TV. Por exemplo, durante um jogo de futebol, o botão vermelho sinaliza que saiu gol em um outro jogo. Ao apertar o botão vermelho do controle remoto (ação interativa) aparece uma tela informando qual foi o jogo, quem fez o gol, o placar e outras estatísticas.

O sincronismo é no espaço porque o botão vermelho aparece em uma determinada região da tela da TV. Essa região é definida por valores absolutos (em pontos) ou por valores relativos (em percentual). Como fazer cada declaração dessas será visto nos próximos textos.

Portanto, para fazer o botão vermelho aparecer na tela precisamos definir uma região para ele e um momento no qual ele deve aparecer. Podemos tratar da seguinte forma: quando o programa voltar do intervalo comercial, na vinheta de retorno, o botão aparece para sinalizar que existe uma interatividade. Porém, para desenvolver esse exemplo, vamos antes ver a estrutura de um documento NCL.

A sintaxe e a estrutura de documentos NCL são muito similares ao HTML. Portanto, tem um cabeçalho e um corpo do documento. Toda declaração deve ser aberta com uma tag < e fechada com outra />, como no exemplo abaixo.

Neste exemplo temos uma seção de descritores, que faz parte do cabeçalho do documento, onde há uma abertura da base com a tag , que é fechada . Dentro dela estão os descritores, que começam com e terminam com . Tudo na linguagem NCL segue essa sintaxe. Ah, os termos são em inglês mesmo. Todos.

Por falar em seções dentro do cabeçalho, podemos ter uma base de regiões (onde descrevemos as regiões em que as mídias devem aparecer); uma de descritores (que por hora vamos chamar de elementos de ligação entre as regiões e as mídias); uma de regras (para trabalhar e testar variáveis); uma de conectores (para determinar quando as mídias devem aparecer); e uma de transições (um conjunto de transições que podem ser usadas nas mídias).

Já no corpo do documento, declaramos as mídias e os links. Além disso, como toda linguagem NCL é estruturada sob o paradigma da causalidade (para que algum efeito ocorra é necessário um causa), é preciso especificar uma porta de entrada no contexto Body. Essa porta iniciará a primeira mídia a partir da qual todas as demais ações acontecem. A estrutura do documento está na figura a seguir:

Dessa forma, para que nosso botão apareça na tela é preciso declarar:

1. uma região em que ele vai aparecer;
2. um descritor que vai ligar essa região à mídia;
3. uma mídia que vai apontar para o botão.

A região pode ser descrita da seguinte forma:

Nessa figura, abrimos a regionBase e declaramos uma região, onde:

1. id é nome da região;
2. width é a largura;
3. height é a altura;
4. left é a distância da região em relação à margem esquerda da TV;
5. top é a distância da região em relação à margem superior da TV.

Vamos criar o descritor:

Abrimos a base de descritores e colocamos o descritor dentro, declarando a qual região ele se refere. A parte de descritores está simplificada ao máximo aqui. No futuro iremos tratar desse tema em vários outros artigos, pois os descritores são fundamentais para determinar o comportamento inicial das mídias.

Tendo encerrado a parte mínima do cabeçalho, vamos criar o corpo do documento:

Nesse caso, criamos o corpo do documento , uma porta, responsável pelo começo da aplicação, com um nome e um componente (que é a mídia inicial). Também descrevemos a mídia, com um nome, o descritor que ela irá utilizar e que vai definir a região em que ela deve aparecer, e uma localização da mídia, criada anteriormente em um editor de imagens. Essa localização aponta para onde o arquivo está salvo e armazenado. No caso, há uma pasta chamada media no mesmo nível onde está o arquivo .ncl.

A aplicação completa deve ter essa cara:

Antes de terminar é necessário salientar que o nome (id) de qualquer elemento da linguagem NCL não pode ser repetido. A sintaxe não aceita dois objetos com o mesmo nome. Uma dica para evitar esse problema é sempre começar o nome com letras que indicam a base em que ele está inserido. Assim, qualquer ID de região começa com Rg; de descritor com d; de porta com p; e assim sucessivamente. Não é uma regra, mas ajuda bastante.

Agora é só testar a aplicação em alguma ferramenta de teste, descrita em texto anterior. O mais simples é abrir o emulador para Windows e executar o arquivo .ncl. Ao dar play deve aparecer o botão no lado superior esquerdo. Essa aplicação é o exemplo mais simples de documento NCL.

Neste exemplo não tratamos de vídeo, uma vez que o mesmo já estaria no ar. Apenas colocamos um botão vermelho sobre ele. Nos próximos textos iremos aprofundar mais elementos de sincronismo, para chegar na interatividade propriamente dita.

Texto originalmente publicado no portal iMasters.

Lua como Mídia de NCL

A seguir alguns conceitos importantes que devemos ter em mente.

Como vimos no artigo passado, um NCLua é um programa escrito em linguagem Lua e que é executado através de um documento NCL. Por sua vez, um documento NCL apenas define como os objetos de mídia são estruturados e relacionados no tempo e espaço, como uma linguagem de “cola”. A relação entre essas diversas mídias é definida através dos conectores.

Uma mídia não tem qualquer comunicação com outra mídia declarada no documento. Sendo assim, o escopo de uma determinada mídia se restringe aos elos definidos no documento e aos eventos gerados para ela ou por ela.

Todas as regras válidas para um nó de vídeo, texto ou imagem, também são válidas para scripts Lua. Quero dizer, todo ciclo de vida, de qualquer nó, é controlado pelo formatador NCL, ele é quem decide se o nó para, começa ou pausa.

Incrementando um pouco mais: já que todas as regras se aplicam igualmente aos nós, podemos definir âncoras para o nó Lua, certo? A sintaxe NCL permite que um elemento pode definir âncoras através de elementos e propriedades através de elementos .

Então, aplicando isso a um nó Lua temos:

O código corresponde à figura. Simples assim:

Bibliotecas NCLua

Para que as duas linguagens se entendam foram definidos quatro novos módulos para NCLua, além do conjunto padrão de bibliotecas. São eles:

Este artigo irá apresentar o módulo event.

O script Lua, ao ser iniciado, executa seus procedimentos apenas uma vez e então se torna orientado a eventos e, por isso, até podemos chamá-lo de tratador de eventos.

Como já dito, a comunicação entre Lua e NCL se dá através dos eventos definidos pela linguagem NCL. Esses eventos, para efeito de código, têm o formato de tabelas Lua. Então quando um nó Lua é iniciado pelo documento NCL, a seguinte tabela é gerada:

A tabela chamada evt com 3 campos, class, type e action, diz que a classe de eventos é ‘ncl’, que o tipo de evento foi de apresentação e a ação do formatador que desencadeou a apresentação foi um ‘start’.

Os elementos da tabela acima:

1. class: São 5 tipos de classes: ‘key’, ‘ncl’, ‘user’, ‘sms’ e ‘tcp’, focaremos este artigo na classe “ncl”.

2. type: Pode assumir os valores ‘presentation’ ou ‘attribution’

Neste ponto irei explorar os dois valores possíveis para type:

2.1. presentation: Eventos de apresentação controlam a exibição do nó NCLua.
Eventos de apresentação estão sempre ligados ao nó como um todo ou a âncoras do nó. O documento NCL pode dar um “start” em uma âncora especifica que foi declarada no nó Lua, como a âncora a1 da Figura 2.

2.2. attribution: Eventos de atribuição controlam as propriedades do nó NCLua.
Neste caso a manipulação é na propriedade do nó, como a p1 da Figura 2, e um novo campo é associado, o value, que recebe ou atribui valores aquela propriedade.
Resumindo:

• type: ‘attribution’
• property: [string] Nome da propriedade (name) associada ao evento.
• value: [string] Novo valor a ser atribuído à propriedade

3. action: Pode assumir os seguintes valores: ’start’, ’stop’, ‘abort’, ‘pause’ e ‘resume’
Pois bem, a tabela foi gerada, mas aonde é usada? No script Lua, o tratador de eventos. E para que ele seja capaz de capturar os eventos gerados é preciso registrar uma função tratadora:

No script acima estou declarando uma função e dizendo que esta função receberá todos os eventos gerados (note que ela recebe como parâmetro uma tabela evt). Assim, o código da função “tratadora” pode manipular a tabela que recebeu, e identificar o tipo de evento e a ação, por exemplo.

Até aqui, vimos uma função do módulo event, a função register, e também o formato da tabela de eventos e seus respectivos campos.
Agora uma nova função de event será apresentada, a função post, que é necessária para que o scrpt Lua se comunique com o documento NCL.

Comunicação Lua para NCL

Em termos mais práticos vou exemplificar como um sript Lua sinaliza o formatador NCL para parar a execução do nó.

De maneira similar, se eu quisesse para a execução de uma âncora do nó, o elemento área, deveria estar presente no código.

Uma simples aplicação do código acima. O script sinaliza a âncora para parar. O formatador detecta que a âncora foi parada e, através dos elos associa esse evento ao inicio de uma figura, de background por exemplo.

Para saber mais:

Vimos neste artigo uma explanação geral sobre a biblioteca NCLua, continuarei no próximo artigo com este assunto.
Para quem ficou curioso recomendo fortemente a leitura do tutorial sobre NCLua escrito pelo Francisco Santana da PUC-Rio, la existe toda documentação sobre os métodos, exemplos e onde achar mais bibliografia sobre o assunto.

O link é:

http://www.telemidia.puc-rio.br/~francisco/nclua/index.html

Texto originalmente publicado no portal iMasters

Neste primeiro artigo irei apresentar a linguagem de programação Lua, a linguagem procedural do subsistema Ginga-NCL, parte integrante do sistema Ginga. Explanarei sobre suas características, sua origem, qual sua aplicação no meio de televisão, enfim, uma introdução dos principais conceitos. Inicialmente o foco será na linguagem pura e, gradativamente, será voltada para aplicações para televisão digital.
Lua é uma linguagem de programação em script, planejada para estender aplicações escritas nas mais diversas linguagens. Oferece bom suporte a programação funcional, programação orientada a dados e até programação orientada a objetos. Por sua natureza extensível, Lua funciona embarcada em um programa “hospedeiro” ou, também chamado programa principal, que pode chamar funções ou trechos de código Lua, ler e escrever em variáveis e ainda registrar funções da linguagem C a serem invocadas por Lua, pois esta é escrita em C.

Logo veremos que um NCLua (programa Lua para plataforma de televisão digital), é justamente isso, uma parte de um documento NCL.
Existem outras linguagens de script similares a Lua nos propósitos, como Perl, Tcl, Ruby, Forth, e Python. Porém, nenhuma outra linguagem oferece esse conjunto de características:

• Extensibilidade: É fácil prover uma interface de comunicação de Lua com linguagens como C/C++, Fortran, Java, Smalltalk, Ada e outras linguagens de script.

• Simplicidade: Lua é simples e pequena (leve).

• Eficiência: Comparativos mostram que Lua esta entre as linguagens interpretadas mais rápidas.

• Portabilidade: Lua roda em TODAS plataformas existentes.

A biblioteca de Lua, ou seja, sua API, a máquina de execução, e o interpretador de linha de comando são softwares livre. A comunidade de programadores já é bem vasta principalmente no exterior onde a linguagem é mais popular e possui uma boa documentação como manuais, artigos e livros.

Surgimento.

A linguagem Lua teve seu inicio em 1993 quando seus criadores, Roberto Lerusalimschy, Luiz H. de Figueiredo e Waldemar Celes, juntaram suas idéias e esforços para a criação de uma linguagem ágil, portável, completa e, apesar disso, simples.
Foi projetada e desenvolvida no laboratório TecGraf e atualmente esta sob responsabilidade do LabLua, ambos na PUC-Rio (Pontifícia Universidade Católica do Rio de Janeiro).
Nos primeiros anos de existência, Lua era usada em projetos internos e sua evolução lenta e gradual, na medida em que se descobria o verdadeiro potencial da nova linguagem.

Mercado.

A comunidade internacional conhece Lua muito bem e já usufrui de seus benefícios a muito tempo.
Uma pesquisa informal feita pelo site gamedev.net de setembro de 2003 mostrou que Lua é a linguagem mais usada para script em jogos, cerca de 20% dos jogos são desenvolvidos com Lua, contra 7 % da segunda colocada, Python. Empresas como LucasArts, BioWare, Microsoft, Relic Entertainment, Absolute Studios eMonkeystone Games desenvolvem jogos usando Lua.
A ferramenta de gerenciamento de fotos digital da Adobe, o Lightroom tem mais de 40% de seu código escrito em Lua.
Podemos citar outras aplicações como firmware para impressoras, analisadores de protocolos,ferramentas de pós-produção de filmes e servidores Web.

Aqui no Brasil a linguagem faz parte do nosso sistema de televisão digital sendo usada para o desenvolvimento de aplicações interativas, sua engine será parte integrante do middleware Ginga.

Lua no Ginga.

Alguns conceitos importantes: As aplicações interativas para Ginga podem ser puras, onde somente uma linguagem é usada no desenvolvimento, ou híbridas, quando misturamos linguagens na aplicação. Vejamos os casos:
Podemos ter um documento NCL com código procedural (estendido) Lua, que chamamos NCLua. Neste caso, o programa principal é escrito em NCL e um de seus nós de conteúdo é um documento com código Lua, ou seja, um programa Lua que é invocado pelo programa NCL principal.

Um caso similar é quando temos um documento NCL com código procedural (também estendido) Java, que chamamos de NCLet.
Quando falamos de aplicações puras, podemos ter aplicações feitas somente em Java, que chamamos de Xlet, ou somente em NCL. Aplicações feitas somente em Lua não são permitidas, pois, como falei anteriormente, Lua precisa de um programa hospedeiro.

A arquitetura dos decodificadores full-seg prevê a máquina de execução Lua e a Máquina Virtual Java (JVM) como partes obrigatórias. Assim como NCL e Java como linguagens de programação obrigatórias. Isso quer dizer que a linguagem Lua junto de NCL e Java poderá ser usada em todas as aplicações interativas, pois a norma prevê suporte para que elas executem sem problemas.

Mas quando mudamos o foco para receptores one-seg, que são os dispositivos portáteis, como celulares, a linguagem Java passa a ser opcional, enquanto Lua é obrigatória. Em termos práticos isso quer dizer que se alguma empresa que desenvolve aplicativos para celular o fizer usando linguagem Java, corre o risco de algum receptor não aceitar a aplicação porque o fabricante do dispositivo decidiu não colocar a JVM no aparelho. Esse problema não acontece com aplicações feitas em Lua, pois a norma prevê que todos os aparelhos devem obrigatoriamente dar suporte a aplicações Lua.

As figuras abaixo resumem as arquiteturas. A primeira camada são os aplicativos, escritos em NCL, NCLua ou Java (Xlet) no caso de receptores fixos. Na segunda camada estão as máquinas de execução, e por último o sistema operacional.

Figura 1: Arquitetura com Ginga-J e Ginga-NCL obrigatoriamente presentes: full-seg.

Figura 2: Arquitetura de dispositivo one-seg opcionalmente sem a máquina virtual Java.

Nos próximos artigos irei explorar a linguagem com conceitos e exemplos.

Günter Heinrich Herweg Filho.

Texto originalmente publicado no Portal Imasters

O desenvolvimento de aplicações para TV digital depende do domínio do que é interatividade e de como funciona a televisão. A interatividade para TV é diferente da interatividade na web. Essa percepção é fundamental para compreender os recursos que o Ginga oferece e as limitações que surgem com essa tecnologia. Em síntese, interatividade na TV digital é transmitir software junto com o fluxo de áudio e vídeo, que pode ser usado pelo telespectador através do controle remoto (jamais se esqueçam que a televisão não tem mouse, logo, não tem clique). Esse software, chamado tecnicamente de aplicativo, pode trazer informações adicionais à programação, como sinopses, jogos, acesso a bancos de dados, enviar informações e personalizar parte da programação televisiva. No entanto, é preciso considerar que qualquer tipo de personalização depende de um canal de interatividade, normalmente linha telefônica ou banda larga. Apenas as informações oferecidas a todos os receptores são transmitidas pelo fluxo de áudio e vídeo.

Em outras palavras, para quem está acostumado a criar conteúdos para a internet, a interatividade na TV digital pode parecer limitada. Já para quem fazia vídeos, cuja única reação do telespectador era trocar de canal, colocar um DVD ou baixar o vídeo na web, a interatividade abre um mundo de possibilidades.

Com isso em mente, vamos apresentar na seqüência as principais ferramentas para começar a desenvolver e testar aplicações para TV digital. Como o NCL é uma linguagem declarativa baseada em XML, bastante complexa se comparadas a outras, mas por isso mesmo completa, é possível criar programas interativos em qualquer editor XML (para os mais conservadores, pode-se usar até mesmo o bloco de notas). Recomendo o XMLPad, simples de usar e que checa a sintaxe XML. Já para quem tem conhecimento intermediário de programação e domina a IDE Eclipse, é possível instalar um plugin que estende a IDE para a linguagem NCL. Este plugin, além de checar a sintaxe XML, checa também os elementos básicos da linguagem NCL, facilitando um pouco o processo de debug do código.

É preciso considerar que as ferramentas listadas abaixo são fruto de trabalhos acadêmicos, visando desenvolver conhecimento em TV digital e interatividade, além de fomentar o início do mercado de desenvolvimento de aplicações. Dessa forma, todas as ferramentas tem limitações e carecem de assistência técnica. No entanto, os manuais e demais documentos disponibilizados pelo pessoal da PUC são muito bons e completos. Todos os softwares podem ser baixados gratuitamente nos sites Ginga-NCL (http://www.gingancl.org.br/) e Clube NCL (http://clube.ncl.org.br/). Exceção para o XMLPad, que pode ser localizado facilmente por qualquer ferramenta de busca, e o Ginga live CD, distribuído como CD (a imagem para download deve estar disponível em breve nesses sites).

Emulador Ginga NCL

Este software é a ferramenta mais fácil de ser usada e mais acessível. Através dele é possível abrir um arquivo NCL e controlar as ações através do controle remoto. No entanto, por ser implementado em Java e estar baseado no JMF, tem uma série de limitações. As principais são:

* A seqüência dos vídeos não é linear. Quando um vídeo é tocado em loop ou quando vários vídeos são encadeados, há uma quebra na seqüência dos vídeos, sendo que o último quadro de um não é ligado perfeitamente ao primeiro quadro do vídeo seguinte.
* Não há suporte a transparência. Algumas interfaces podem ser desenvolvidas em softwares como Adobe Photoshop ou Gimp e salvas no formato PNG, com níveis de transparência. Esses níveis aparecem chapados, na cor cinza, no emulador.

Além disso, o emulador não dá suporte à linguagem Lua.

O emulado Ginga NCL vem embutido na ferramenta composer e pode ser instalado como plugin na IDE Eclipse, o que facilita o desenvolvimento e teste de aplicações.

Composer

Trata-se de uma iniciativa muito interessante buscando desenvolver aplicativos em NCL sem a necessidade de conhecimentos de programação. O Composer oferece desenvolvimento visual das aplicações, através de quatro tipos de visualização dos componentes hipermídia:

* Temporal: apresenta uma linha do tempo com o comportamento de cada mídia a ser executada, com os sincronismos temporais, espaciais e a participação do usuário.
* Leiaute: apresenta uma visão do leiaute da estrutura espacial do aplicativo.
* Textual: apresenta as linhas de código NCL.
* Estrutural: apresenta o roteiro hipermídia da aplicação, com todas as mídias e suas conexões espaciais e temporais.

Todas as seções podem ser editadas, com atualização instantânea das demais. Por exemplo, uma alteração no código NCL é refletida instantaneamente na visão temporal, espacial e estrutural do documento. No entanto, a ferramenta ainda é bastante instável, sendo recomendada apenas para aplicações bem simples, que não envolvem muitas mídias.

Ginga NCL Virtual STB

Trata-se de uma implementação em C++ rodando em Linux e emulada no Windows. Assim, é necessário a instalação de um player de máquina virtual e de um SSH para carregamento e controle das aplicações. Apesar das instruções bem detalhadas na interface do set top box virtual, é recomendável um conhecimento básico em Linux para um uso pleno. A visualização das aplicações no STB virtual é um pouco mais demorada do que no emulador para Windows, mas o esforço vale a pena. Nesta ferramenta estão implementadas a maioria das funções Lua e a transparência funciona muito bem. A máquina virtual é limitada à resolução 640X480, o que impede testes de aplicativos para alta definição.

Emulador C++

Disponível apenas em código fonte para ser implementado na distribuição Fedora do Linux, este emulador exige conhecimentos avançados de Linux e a instalação de suas bibliotecas para rodar. Apesar da dificuldade trata-se de uma implementação bastante completa e compatível com a norma do SBTVD. Recomendado apenas para usuários avançados de Linux e programadores experientes.

Ginga Live CD

Versão mais amigável do emulador C++, dispensa instalações e conhecimentos de informática. Todo sistema operacional Fedora vem no CD, incluindo as bibliotecas e as APIs do NCL e Lua. Semelhante a distribuição Linux do Kurumin, não é necessário instalar nada na máquina. Basta dar o boot pelo CD, que o mesmo será descarregado na memória do computador. A partir deste ponto, é possível ver alguns exemplos que acompanham o CD, carregar aplicações por USB ou puxar a aplicativos do Clube NCL. É a ferramenta mais completa disponível para testes em computadores, mas tem o problema de necessitar um computador específico para ser executado, ou reiniciar o computador a cada teste.

Essas ferramentas são boas para desenvolver aplicações simples e testar conceitos. Em ambientes profissionais, para colocar aplicações no ar, são necessárias ferramentas mais completas e aderentes à norma da ABNT. Há empresas desenvolvendo soluções deste tipo, como Mopa, TQTVD e RCASoft. Essas estações de desenvolvimento e teste serão abordadas no futuro, quando tivermos esmiuçado as linguagens NCL e Lua, tema dos próximos textos.

Texto originalmente publicado no Portal Imasters.

Nesta semana a coluna apresenta um pouco da história da TV digital no Brasil, com as escolhas tecnológicas feitas e o que ainda falta definir. O tema foi objeto de muitos estudos, com investimento público que beira os R$ 100 mi, e ainda está longe da estabilidade comercial. Tecnicamente, a TV digital no Brasil é exemplo internacional, com funcionamento muito melhor do que o esperado. Porém faltam incentivos para que a população compre os receptores, considerados caros e sem atrativos para quem não tem TV de plasma ou LCD de alta definição.
Resumidamente, as discussões sobre a TV digital começaram no Brasil em 1994, quando foram feitos os primeiros estudos sobre o tema, conduzidos pela Sociedade Brasileira de Engenharia de Televisão (SET) e a Associação Brasileira de Emissoras de Rádio e Televisão (Abert). Desde então tem se debatido vários aspectos tecnológicos, com foco nos padrões e sistema internacionais que poderiam ser adotados. Até 2000, não houve resultados concretos desses estudos. Ficaram muito mais na suposição e na falta de vontade política de avançar.
Centrando os estudos nos três sistemas existentes (americano ATSC, europeu DVB e japonês ISDB), a Anatel iniciou os seus estudos sobre TV digital e mercado de telecomunicações em 1998. Além de tomar a frente nas pesquisas, a Agência avalizou a iniciativa SET/Abert, dando continuidade ao trabalho que vinha sendo desenvolvido, porém com uma visão mais pragmática. O objetivo inicial estava era escolher um dos três padrões para ser adotado pelo Brasil. O desenvolvimento de um sistema nacional estava totalmente fora de questão.
No início de 1999 foram importados os equipamentos necessários para testar os três sistemas de transmissão. Os testes de laboratório e de campo foram feitos em setembro daquele ano e em janeiro de 2000, respectivamente. Também foram feitas demonstrações da tecnologia em locai públicos, como shoppings.
Logo no início dos testes, em fevereiro de 2000, percebeu-se que a modulação 8-VSB, usada pelo sistema norte-americano, não atendia às necessidades brasileiras, uma vez que seu desempenho foi insatisfatório na recepção doméstica, principalmente usando antenas internas. Esse fato levou a Anatel a descartar o padrão de modulação norte-americano, colocando em consulta pública a utilização do COFDM, usado pelo DVB e ISDB. Atualmente, quase metade (47%) dos aparelhos de TV tem recepção apenas por antenas internas.
O relatório final dos testes de TV digital confirmou o melhor desempenho dos sistemas europeu e japonês, além do desempenho insuficiente do ATSC nos quesitos transmissão de sinais em áreas de sombra e para receptores móveis. Entre os dois primeiros, o ISDB foi considerado superior ao DVB, devido ao melhor desempenho na recepção de sinais televisivos em ambientes fechados, e a sua flexibilidade para recepção de programas ou acesso a serviços, através de terminais fixos ou móveis. Em 31 de agosto de 2000, a Anatel encerrou a discussão técnica sobre o padrão de TV digital a ser adotado no Brasil. Esperava-se um pronunciamento oficial sobre qual tecnologia seria adotada, mas este anúncio foi adiado para depois da posse do novo governo, que ocorreria dois anos depois.
Após a posse, o então Ministro das Comunicações, Miro Teixeira, encaminhou uma carta de intenções ao Presidente da República, onde levantou a necessidade da inclusão digital através da TV interativa. Era o primeiro sinal de que o assunto teria outro tratamento. O passo seguinte foi o anúncio de que o país desenvolveria um padrão próprio de transmissão, idéia que foi amplamente defendida pelo ministro até sua saída do Ministério, um ano após tomar posse. Em maio do mesmo ano, foi criado um grupo de estudo para analisar novamente o assunto e dar um parecer sobre os estudos já realizados.
Os trabalhos desse grupo de estudo duraram até novembro, quando saiu o decreto Nº. 4.901, que instituiu o Sistema Brasileiro de TV Digital (SBTVD). O decreto, além de nortear a transição do sistema analógico para o digital, deixou claro que esse avanço tecnológico não se restringiria a uma simples troca de equipamentos. A preocupação com a inclusão social por intermédio da TV e com o desenvolvimento da indústria nacional estava entre os principais objetivos. O decreto deixou claro que a TV digital seria uma ferramenta com finalidades sociais, não uma simples evolução tecnológica que atende apenas a interesses mercadológicos ou econômicos.
Para conduzir os estudos foram lançados 20 editais públicos, em forma de Requisição Formal de Proposta (RFP), buscando projetos para atender as mais variadas áreas que compõe a TV digital. Os editais incentivaram a formação de redes de pesquisa, onde os estudos são realizados de forma descentralizada por várias instituições trabalhando num mesmo tema. No total, o SBTVD envolveu 79 instituições acadêmicas, de P&D e da indústria eletroeletrônica, congregando mais de 1.200 pesquisadores.
O resultado final foi a opção pelo padrão OFDM-BST de modulação, integrante do sistema japonês de TV digital, que permite transmissões para dispositivos portáteis na mesma freqüência do canal de radiodifusão. Além disso, foram incorporadas inovações tecnológicas como o padrão de codificação H.264 e o middleware Ginga. Este último desenvolvido nacionalmente.

O Decreto Nº. 5.820, além de definir as tecnologias componentes do ISDB-Tb (International System for Digital Broadcasting – Terrestrial Brazil), nome comercial adotado pelo SBTVD, também estabelece as regras de implementação da TV digital no Brasil, delimitando em sete anos o prazo para que o sinal digital cubra todo o território nacional. Em 10 anos toda transmissão terrestre no Brasil deve ser digital e as concessões de canais analógicos devolvidas pelos operadores privados à União. Além disso, define que a TV digital brasileira terá alta definição, mobilidade, portabilidade, multiprogramação e interatividade.
Para desenvolver e implementar plenamente o ISDB-Tb, foi criado o Fórum do SBTVD-T, composto por representantes do setor de radiodifusão, do setor industrial e da comunidade científica e tecnológica, entre outros. O principal objetivo do Fórum é promover a definição, desenvolvimento, planejamento da implantação e implementação dos padrões técnicos voluntários e obrigatórios do ISDB-Tb.
A inauguração da TV digital brasileira aconteceu em dois de dezembro de 2007, em São Paulo. Na ocasião, as principais redes de TV da cidade lançaram suas transmissões digitais, mesclando conteúdos em alta definição com outros em definição padrão. Também foram lançadas as transmissões One-Seg, para dispositivos portáteis, em baixa definição. Atualmente, 11 capitais brasileiras já tem sinal digital comercial, abrangendo 46% da população. Pelo menos mais cinco capitais estão em fase de teste da tecnologia, cujo lançamento deve ocorrer nos próximos meses.
A interatividade foi postergada para um segundo momento. No entanto, vários fabricantes de set top boxes (receptores digitais, com saída analógica, que fazem a decodificação do sinal digital e suportam a interação do usuário) embutem softwares nos equipamentos, o que permite algum tipo de interatividade, como o guia de programação. As informações que compõe o guia são transmitidas multiplexadas ao fluxo de áudio e vídeo, e extraídas no momento da exibição. Como as transmissões digitais foram iniciadas sem o middleware Ginga nos set top boxes, atualmente o guia eletrônico de programação (EPG) é o único recurso interativo presente, que permite alguma interação entre o usuário e o receptor através de software e controle remoto.
No entanto, há vários receptores com versões de Ginga sendo vendidos clandestinamente. No centro da cidade de São Paulo, um receptor com Ginga-NCL implementado parcialmente é vendido a um preço médio de R$ 600,00. Esses receptores não são atualizáveis, mas recebem alta definição e tem saída HDMI.
Além disso, nesta semana foi lançado comercialmente o middleware RCA Soft. Trata-se de uma implementação das linguagens NCL e LUA, com suporte a aplicações carregadas localmente pela porta USB ou transmitidas pelo ar via carrossel de objetos. Por enquanto o middleware RCA Soft é voltado para o receptor XPS-1000 da Proview. Quem já comprou esse receptor pode fazer o download do Ginga no site da própria RCA Soft, a um custo de R$ 199,00, e acompanhar os testes que estão sendo feitos pelas emissoras de TV. Esse preço inclui os serviços técnicos de preparação do software de instalação para o receptor, envio do software por e-mail com as instruções detalhadas para atualização, envio de algumas aplicações interativas de exemplo e suporte técnico do usuário por e-mail durante o período de 90 dias.
A escolha das tecnologias envolvendo a TV digital no Brasil causou muita polêmica. Por um lado, a iniciativa do governo federal em usar a TV digital como fonte de inclusão digital não obteve respaldo das emissoras de TV, responsáveis pela geração de conteúdo. Por outro, o lobby do Sistema Europeu desvirtuou o debate, com informações incorretas sobre o potencial da tecnologia.
Analisando o processo agora, três anos depois do centro do debate, percebe-se que o DVB está míngua, com o MHP questionado por todo mundo que o adotou. Além disso, a escolha pelo MEPG-4 se mostrou totalmente acertada. Os EUA já anunciaram a evolução do sistema ATSC para incorporar essa tecnologia de codificação; A Europa está em vias de fazer o mesmo, uma vez que a França também optou por essa tecnologia. O Japão está estudando como evoluir o ISDB para incorporar essa inovação. Isso mostra na prática o que se sabia teoricamente: o ISDB-Tb é o sistema de TV digital com as tecnologias mais avançadas.
O único componente genuinamente nacional do ISDB-Tb é o middleware Ginga, desenvolvido pelas Universidades PUC-Rio e UFPB. Até o momento, a linguagem declarativa NCL e a procedural LUA estão confirmadas e especificadas pela ABNT. Os receptores e ferramentas de teste disponíveis no mercado estão baseados nessas duas linguagens. O Fórum do SBTVD ainda estuda a adoção da linguagem Java, como padrão procedural.
Resumidamente, os principais recursos do Ginga são:

• Recebimento de aplicações pelo ar
• Envio de informações por qualquer rede
• Sincronismo no tempo e no espaço
• Interatividade
• Adaptabilidade
• Múltiplos dispositivos
• Edição ao vivo

A linguagem NCL sozinha dá suporte a todos esses recursos, que podem ser incrementados com LUA. Cada uma dessas características será detalhada nas próximas semanas nesta coluna, com exemplos em NCL e LUA. Na semana que vem a coluna vai abordar infraestrutura de desenvolvimento e de teste de aplicativos para TV digital. Não esqueça de enviar seus comentários e dúvidas. E um bom carnaval, cheio de Ginga.

Texto originalmente publicado no Portal Imasters.

A TV digital é uma evolução da TV analógica. Ainda engatinhando no Brasil, a TV digital traz imagens em alta definição, incrivelmente melhores do que a TV analógica, que podem ser recebidas em aparelhos fixos, móveis e portáteis, com ou sem interatividade. A partir desta semana vamos tratar neste espaço as oportunidades criadas e expandidas por essa nova tecnologia, com foco principalmente no desenvolvimento de conteúdos interativos para TV aberta. Todas as semanas você terá novidades sobre interatividade, desenvolvimento de aplicações em NCL e LUA, testes, mercado e o andamento da TV digital no Brasil.

A TV digital já uma realidade nos Estados Unidos, na Europa e no Japão. Na maioria desses países a TV analógica está próxima do fim. No Brasil as transmissões digitais abertas começaram em dezembro de 2007 e atualmente quase metade das capitais já tem sinal digital, incluindo recepção portátil. A interatividade ainda não foi lançada oficialmente por problemas com direitos autorais envolvendo a linguagem Java. Por outro lado, as linguagens NCL e LUA, ambas nacionais, já estão especificadas pela ABNT e poderiam estar nos receptores, se a indústria assim o quisesse. Já na TV por assinatura, os principais provedores já oferecem pacotes digitais.

Mas antes de detalhar as linguagens de programação para conteúdo interativo na TV digital, vamos ver um pouco do funcionamento da tecnologia e o que compõe essa nova forma de transmissão. Os limites da interatividade na TV digital (que serão detalhadas nas próximas semanas) surgem por causa da organização da transmissão em broadcast. Para quem está acostumado com a interatividade na web, surpresas virão, porque a interatividade na TV digital (infelizmente) não tem relação com o que conhecemos na internet.

Olhando de forma genérica, um sistema de TV digital interativa pode ser decomposto em três partes: um difusor, responsável por prover o conteúdo a ser transmitido, e suportar as interações com os telespectadores; um receptor, que recebe e apresenta o conteúdo e possibilita ao telespectador interagir com o difusor; e um meio de difusão, composto por canal de difusão e canal de retorno (ou canal de interatividade), que habilita a comunicação entre difusor e receptor.

A transmissão do sinal de televisão pode ser pelo ar (transmissão terrestre), por cabo ou satélite. Mais recentemente a tecnologia IPTV (que não tem nada a ver com vídeo na internet ou webTV) também tem sido utilizada por algumas provedoras de TV por assinatura e vídeo sob demanda. Para o desenvolvimento de aplicativos, foco desta seção, não faz diferença a forma como o vídeo é transmitido. O que importa são as ferramentas de desenvolvimento e multiplexação, no lado do difusor, e a infraestrutura de recepção, no lado do receptor. Lembrando apenas que quando falamos em TV aberta, que está em processo de digitalização no Brasil, a transmissão é feita pelo ar, por radiodifusão. Isso não muda em relação à TV analógica.
O difusor

A transmissão do sinal de TV digital passa por várias etapas, nas quais o áudio, o vídeo e os dados são organizados para a difusão. Destaque para os dados, que representam a grande diferença em relação à TV analógica e são responsáveis por vários recursos novos, como o oferecimento de: legendas de filme, guias de programação de canais (EPG - Electronic Program Guide), informações sobre data e hora, sinopse de programas etc. Aqui é necessário dar uma ênfase especial para um tipo de dado importante em TV digital: os aplicativos - programas desenvolvidos nas linguagens NCL ou LUA -, que serão executados no receptor da televisão digital, que passa a possuir capacidade de processamento. São esses aplicativos que caracterizam a interatividade.

Falando especificamente sobre o áudio e o vídeo, existem duas formas de gerar conteúdo televisivo: transmiti-lo ao vivo ou gravar seqüências de vídeo e áudio para posterior edição antes da difusão. Em ambas as formas, os sinais de áudio e vídeo precisam ser codificados e encapsulados em pacotes de transporte MPEG2-TS por um multiplexador, antes de serem transmitidos. Os dados também precisam ser inseridos no multiplexador, através de um injetor de dados.

Após a multiplexação, o próximo passo é modular o sinal digital para ser difundido pelos meios convencionais. Cabe ao modulador essa tarefa, que gera um sinal em baixa freqüência. Esse sinal precisa ser convertido em um sinal de freqüência maior para poder ser difundido pelos diversos meios. O equipamento responsável por essa conversão é o UpConverter.
O receptor e o set top box

Antes de ser processado por um receptor, o sinal difundido precisa ser captado por uma antena, no caso de satélite ou radiodifusão, ou chegar via cabo. O receptor pode estar dentro de uma televisão digital ou ser um equipamento à parte. Nesse último caso, o receptor passa a ser conhecido como decodificador ou set top box. A idéia básica desse dispositivo é o de uma pequena caixa agregada a uma televisão analógica, que converte os sinais digitais para que sejam assistidos por essas televisões convencionais. Para quem assina ou conhece sistemas de TV por assinatura, o receptor é algo comum do lado da TV.

Um receptor ou set top box pode possuir também um canal de retorno tornando possível uma interatividade entre o telespectador e os serviços disponíveis. Esse canal de retorno pode utilizar as mais diversas tecnologias disponíveis, como linha telefônica discada, xDSL e cabo, rede celular 3G, para fazer a comunicação no sentido inverso da difusão, do telespectador para o operador da rede.

Para permitir a interatividade, os set top boxes precisam de capacidade de processamento. Por isso seu hardware pode conter tecnologias que são comuns aos computadores, tais como CPU, memória, modems para canal de retorno, memória para armazenamento de dados, e leitores de smart cards para controle de acesso. Como ocorre em computadores convencionais, esses dispositivos são controlados por device drivers de sistemas operacionais. Contudo, esses sistemas operacionais são bem mais simples que os convencionais, e possuem código armazenado em memória não volátil (ROM).

O primeiro elemento que processa (capta) o sinal difundido é o sintonizador digital. A seguir, o sinal passa pelo demodulador, que extrai o fluxo de transporte MPEG-2, passando-o para o demultiplexador, responsável por extrair todos os fluxos elementares. Esses, por sua vez, são então encaminhadas para o decodificador, que os converterá para o formato apropriado de exibição utilizado pelo equipamento televisivo. Já as aplicações são executadas pelo processador conforme o estado determinado no injetor de dados, podendo iniciar automaticamente ou ficar na espera de uma ação do telespectador (nesse caso, usuário).

As modalidades mais conhecidas de televisão digital são a SDTV (Standard Definition Television), a HDTV (High Definition Television) e a EDTV (Enhanced Definition Television), também conhecida como HDTV Ready. A primeira é um serviço de áudio e vídeo digitais, parecida com a TV analógica, na relação de aspecto 4:3 (largura:altura da imagem), cujos aparelhos receptores possuem 480 linhas, com 740 pontos em cada uma. A HDTV, cuja imagem possui formato 16:9, é recebida em aparelhos com 1080 linhas de definição e 1920 pontos. Entre esses dois sistemas existe a EDTV, TV de média definição, que possibilita a utilização de aparelhos com 720 linhas de 1280 pontos.

Dependendo da largura de banda disponível para a transmissão, é possível mesclar essas modalidades de TV digital, uma vez que a qualidade da imagem no receptor é proporcional à banda utilizada pela transmissão. No caso do Brasil, a largura de banda é um pouco superior a 17 Mbps.

A vantagem mais perceptível da transmissão em sistema digital é a conservação da qualidade do sinal. O número de linhas horizontais no canal de recepção, mesmo em modo SDTV, é superior a 400, sendo idêntico àquele proveniente do canal de transmissão. Nos atuais sistemas analógicos, em função das perdas, a definição nos aparelhos receptores (TVs e videocassetes) atinge, na prática, somente 330 linhas horizontais. Isso impacta diretamente na qualidade da imagem que vemos na TV. Digitalmente, a imagem é muito mais imune a interferências e ruídos, ficando livre dos “chuviscos” e “fantasmas” tão comuns na TV analógica. Na transmissão digital, os sinais de som e imagem são representados por uma seqüência de bits, e não mais por uma onda eletromagnética análoga ao sinal televisivo.

Do ponto de vista das telecomunicações, a grande vantagem da TV digital, comparado com a analógica, é a otimização do espectro de freqüências. Cabem mais canais digitais do que analógicos. Isso acontece porque o sinal digital pode ser compactado e porque há menos interferências do que na transmissão analógica.
Além disso, a TV digital traz pelo menos mais três grandes inovações: a recepção móvel, a recepção portátil e a interatividade. Apesar das constantes confusões, a TV digital móvel é diferente da portátil. A recepção móvel é feita por aparelhos de TV convencionais, em movimento, como ônibus, trens, metrôs, carros. Já a recepção portátil é pessoal, feita por aparelhos celulares ou TVs portáteis. Não tem nada a ver com vídeos das redes de telefonia, como 3G.

Todas essas vantagens só são possíveis graças à convergência de tecnologias, alardeada há pelo menos duas décadas. Do lado da produção, o computador já é amplamente usado na edição e codificação dos vídeos. Porém do lado do telespectador, o uso do PC para assistir TV ainda é praticamente desconhecido, com poucas exceções feitas por placas especiais capazes de decodificar os sinais das antenas analógicas. No caso da TV digital, tanto o set top box, como o próprio aparelho de TV, são computadores bastante potentes. É dessa convergência que surge a interatividade, que será o tema central dos próximos textos desta seção.

Até a próxima semana, quando explicaremos as tecnologias usadas na TV digital brasileira e o funcionamento da interatividade. Não deixe de postar seus comentários.