Esta segunda-feira, 06/04, é um dia importante para o Fórum SBTVD e o futuro do mercado de TV Digital no Brasil. Pela primeira vez desde que foi criado, o Fórum poderá tomar uma decisão sem consenso, por voto. Na pauta, a especificação do middleware Ginga para receptores fixos e televisores com receptores embutidos. E, ironia das ironias, para decidir que Ginga teremos, o Fórum precisará mostrar toda a sua 'ginga'.

 

Passados quinze dias da última reunião do Conselho Deliberativo, ninguém arrisca um palpite. "Pode ser a reunião mais rápida ou a mais longa da história do SBTVD". "Tudo pode acontecer". "As opniões continuam muito divididas", formam as frases mais ouvidas nos últimos dias.

 

Uma coisa é certa. Se realmente tomada hoje _ como espera a maioria e deseja o Conselho Deliberativo, formado por treze conselheiros dos setores de Recepção, Radiodifusão, Software, Transmissão e  sete  representantes indicados pelo Poder Executivo _ a decisão deixará ao menos um segmento industrial feliz: o de software, que terá finalmente uma diretriz clara para trabalhar.

 

Explico.

O middleware Ginga é desenvolvido em três partes: uma é o Ginga-NCL, já definido; a outra, o Ginga-J, sobre o qual pairam as dúvidas; e a terceira, uma camada comum a esses dois módulos, declarativo e procedural, encarregado da comunicação entre eles, de modo a balancear o uso do melhor em termos de performance para a aplicação interativa.

 

É possível ter aplicações interativas só usando o módulo NCL? É. E já existem várias delas em teste no mercado. É inegável que a linguagem NCL, somada à linguagem Lua _ interativa, com alto poder computacional (é sete vezes mais eficiente em termos de utilização que o Action Script, utiizando um espaço quarenta vezes menor) e de penetração (já é uma das linguagens mais usadas no mundo na área de entretenimento) _ dá aos desenvolvedores brasileiros a oportunidade de resolver de forma fácil e eficiente um conjunto muito grande de tarefas da TV digital.

 

Mas é igualmente inegável que só com NCL/Lua, podemos deixar de fazer coisas de forma tão eficiente quanto Java faz. Por quê? Porque o Java dá conta de tarefas computacionais mais complexas, como as necessárias a transações que demandem requisitos de segurança forte.

 

Qual o melhor dos mundos? Ter os dois. Razão pela qual tantos defendem esse caminho.

 

São maioria? Impossível prever, dizem todos os integrantes do Fórum com quem tive a oportunidade de conversar, de diversos segmentos, software, academia, radiodifusão, indústria de receptores, governo...

 

Sendo, o Conselho Deliberativo do Fórum SBTVD precisará definir, então, que especificação de Ginga-J usar: a com GEM (Globally Executable MHP) ou a com Java-DTV (especificação livre recém criada pela Sun)? Qual das duas abre mais portas para o padrão brasileiro no mercado internacional? Sobretudo nos países latino americanos, onde o lobby do padrão DVB, europeu, vem usando a indefinição em torno da especificação do middleware Ginga para receptores fixos e televisores como argumento contrário ao padrão nipo brasileiro? E aí,novamente, as opiniões se dividem. Há quem advogue que a única forma de manter o argumento "livre de royalties" para o middleware seja optar pelo Java-DTV. E há quem acredite que a boa penetração do GEM em outros mercados possa facilitar a disseminação do padrão nipo brasileiro em outros países.

 

Uma decisão o mais rápido possível aceleraria também os complexos trabalhos de harmonização do middleware brasileiro com os diferentes padrões de middleware existentes, e de adequação aos requisitos gerados pela convergência tecnológica com outras redes (Internet e telefonia móvel, entre as principais).

 

A guerra dos Ginga é ruim para os negócios

Considerando que o Ginga é o único componente genuinamente nacional do "sistema nipo-brasileiro" de TV Digital, a definição da especificação que tanta curiosidade gera em outros mercados, faria muito bem aos negócios, nos mercados interno e externo.

 

Quer um bom exemplo?