Por que eu devo ler este artigo: Este artigo explica a escolha do padrão brasileiro da TV digital de forma a oferecer um embasamento inicial para a compreensão da estrutura da solução brasileira proposta para o Sistema Brasileiro de Televisão Digital (SBTVD).

Também vamos explicar o que é e qual é o middleware do padrão brasileiro responsável pelo desenvolvimento da interatividade da TV Digital.

Muitos países implantaram nos últimos anos sistemas digitais, que têm inúmeras vantagens sobre os analógicos, como maior imunidade a ruído e melhor reprodução. Porém, sua maior vantagem é utilizar a forma de processamento dos computadores, permitindo que as tecnologias de TV, rádio e telefone celular convirjam para as dos computadores.

Existem no Brasil 43 milhões de domicílios com cerca de 54 milhões de aparelhos de TV fixos, com tecnologia analógica. Recentemente, o mercado de telefones celulares se expandiu de forma imprevisível: há hoje cerca de 85 milhões em uso no país. No futuro, cada celular poderá ser uma unidade de TV móvel [3].

A implantação da TV digital começou a ser considerada no Brasil em 96, mas o governo anterior não tomou a decisão sobre o sistema a ser adotado. Partindo da premissa de valorizar o conhecimento e a capacidade de produção nacional, em novembro de 2003 o presidente Lula assinou decreto instituindo o SBTVD-T e determinando a mobilização de pesquisadores para estudar os aspectos envolvidos na adoção da nova tecnologia.

Também estabeleceu as diretrizes para o sistema:

  • Acessibilidade por parte de toda a população;
  • Inclusão social;
  • Preservação da identidade nacional nos meios de comunicação de massa;
  • Fortalecimento da cadeia produtiva de televisão, compreendendo, entre outros, as empresas de radiodifusão e de criação de conteúdos, equipamentos e software.

Cerca de 1.400 cientistas e técnicos, distribuídos em 22 consórcios formados por 90 entidades de pesquisa e empresas, estudaram durante dois anos os padrões de TV digital implantados no mundo (o japonês, o europeu e o norte-americano) e as opções para o SBTVD-T, financiados pelos ministérios das Comunicações e da Ciência e Tecnologia.

Com base nesses estudos e em consultas a representantes de diversos segmentos da sociedade-empresa difusoras de TV e de telefonia, indústrias do setor eletrônico e discussões realizadas no Congresso e em fóruns diversos, o governo definiu as características do SBTVD-T. Ele não é igual a nenhum dos três padrões existentes: é o mais avançado de todos. A transmissão de TV digital no Brasil será feita pelo sistema de modulação do padrão japonês, com componentes exclusivos criados no Brasil ou desenvolvidos após a implantação dos demais sistemas.

O SBTVD-T mantém as características da TV brasileira, aberta e gratuita para toda a população, podendo ser captada por receptores fixos ou portáteis. O sistema de modulação japonês é o único que, atualmente, permite transmitir imagens com a mesma qualidade, em um só canal, como utilizado no Brasil. A decisão sobre a adoção do sistema de modulação do SBTVD-T foi precedida de intensas negociações com o governo e as indústrias do Japão. Isso porque a implantação da TV digital no Brasil abre a possibilidade de revigorar a indústria eletrônica do país, dentro dos objetivos da Política Industrial, Tecnológica e de Comércio Exterior do governo federal [3].

O acordo assinado entre o Brasil e o Japão prevê parcerias entre centros de pesquisa e empresas dos dois países, como também a incorporação de tecnologias aqui desenvolvidas no sistema japonês. E o Brasil já tem discutido com nossos vizinhos para que a configuração final do sistema seja comum ao Mercosul ampliado.

O SBTVD-T possibilitará, ainda, a implantação de mais quatro canais públicos de televisão, com programação sobre educação, cultura, cidadania e atos de governo, seja federal, estadual ou municipal. Trata-se de reivindicação de entidades defensoras da democratização dos meios de comunicação, viabilizada com a adoção do novo sistema. Os desafios para a indústria nacional de eletrônica, para os pesquisadores, produtores culturais e difusoras de TV estão apenas começando, pois o novo sistema irá revolucionar os meios de transmissão de imagens e de comunicação [3].

Como vimos a TV Digital interativa necessita da programação desta interatividade através do middleware. A definição do middleware, camada que oferece este serviço, e a escolha do Governo Brasileiro em desenvolver seu padrão é explanado a seguir.

Middleware

O complexo sistema do terminal de acesso da TV digital interativa é representado por uma arquitetura em camadas em que cada camada oferece serviços para a camada superior e usa os serviços oferecidos pela subjacente. Desta forma, as aplicações, executadas na TV digital fazem uso dos serviços de uma camada de middleware.

O middleware – ou camada do meio – é uma camada de software que tem por finalidade oferecer um serviço padronizado para as aplicações (camada de cima), escondendo as peculiaridades e heterogeneidades das camadas inferiores (tecnologias de compressão, de transporte e de modulação). As principais funções de um middleware para a televisão digital interativa são [5]

  • Possibilitar a execução de aplicações, fornecendo para as mesmas um conjunto de APIs bem definido, abstraindo características específicas de hardware e de sistema operacional;
  • Fornecer serviços para estas aplicações tais como, serviços de comunicação, acesso a fluxos elementares de áudio, vídeo e dados.

O uso do middleware facilita a portabilidade das aplicações, permitindo que sejam transportadas para qualquer receptor digital ou STB que suporte o middleware adotado, independente da marca ou sistema operacional que ele utilize. Essa portabilidade é primordial em sistemas de TV digital, pois não é prudente considerar como premissa que todos os receptores digitais sejam exatamente iguais.

Buscando evitar uma proliferação de padrões de middleware, os principais sistemas existentes de TV digital, terrestre – norte-americano, europeu e japonês – adotam um padrão de middleware em seus receptores.

Requisitos de middleware para IDTV

A camada de middleware segue uma série de requisitos para que suas funções sejam realizadas de forma eficaz. Os quatro principais requisitos são [5]

  • Confiabilidade - ao contrário dos usuários de computadores pessoais, os usuários de televisão não estão acostumados a problemas de desempenho e desejam ver e utilizar seus programas sem falhas que os levem a estar em uma situação de negação de serviço. É importante ressaltar que um sistema com falhas pode levar uma reputação má a toda uma infraestrutura montada, mesmo que esta seja de excelente qualidade. Por exemplo, a rapidez de resposta do sistema ao usuário em aplicações como anúncios virtuais, que podem gerar altas taxas de requisição, é essencial para a utilização por parte dos usuários.
  • Segurança - o middleware deve dispor de mecanismos seguros, como autenticação, criptografia, políticas de acesso, dentre outros, que garantam ao usuário o recebimento e envio de dados, assim como a execução dos componentes. Por exemplo, em transações envolvendo senhas, como compras com cartão de crédito, o middleware deve gerenciar a troca de dados provendo a segurança das informações, transações e valores.
  • Extensibilidade - com o acelerado processo de inovação tecnológica, é necessário que o middleware suporte os futuros softwares e dispositivos de hardware desenvolvidos. Por isso, o middleware tem de ser extensível (Souza, 2003). Por exemplo, integração com sistemas biométricos (impressão digital, dinâmica da digitação, assinatura dinâmica, reconhecimento de voz, face, geometria das mãos, íris, retina, etc.) e, até mesmo, com sistemas de realidade virtual (mouse 3D, joystick, luvas, sensores acoplados ao corpo etc.).
  • Reflexibilidade - considerando a heterogeneidade das plataformas dos STBs, é importante que a camada de middleware possua a característica de reflexão, ou seja, que além da interface tradicional possuam uma meta-interface, cuja aplicação pode requisitar ao middleware uma capacidade de conhecimento do ambiente e de modificação, adequando as necessidades de um dispositivo ou protocolo específico para otimizar, por exemplo, a performance ou características de interface com o usuário.

A Funcionalidade do Middleware

O objetivo principal do middleware é prover um conjunto de ferramentas para possibilitar a interoperabilidade entre sistemas de transmissão de vídeo para vários tipos de mídias de transmissão incluindo satélites, cabos, redes terrestres e microondas. Este conjunto de ferramentas também compreende serviços interativos usando diferentes tipos de canais de retorno e suporte a outras funcionalidades como informação dos serviços (SI -Service Information) entre outras.

Além disto, é interessante que o middleware adicione uma solução tecnológica para o terminal de acesso a fim de possibilitar a recepção e execução de aplicações em um framework independente do desenvolvedor e da emissora. Esta independência deve incluir cenários que consideram a infraestrutura legada. Aplicações de vários provedores de serviço podem interoperar com diferentes implementações do middleware em um mercado horizontal, onde aplicações, redes e terminais de acesso podem tornar-se disponíveis por diferentes provedores.

As aplicações a serem executadas no middleware em geral podem ser classificadas em duas categorias, dependendo de que o conteúdo processado na aplicação seja de natureza declarativa ou procedural [5]. Um exemplo de aplicação declarativa é um documento multimídia, composto de símbolos de marcação, regras de estilo, scripts, imagens posicionadas sob o documento, áudio e vídeo. Um exemplo de aplicação procedural é um programa JavaTV (Xlet) compilado em byte code Java, em conjunto com outros elementos multimídia como gráficos, áudio e vídeo.

Para processar as aplicações, é necessário que o middleware possua um ambiente de aplicações que também possa ser de natureza declarativa ou procedural, conforme o tipo de aplicações processado. Um exemplo de um ambiente de aplicações declarativas é um navegador de documentos multimídia, também conhecido como agente de usuário (user agent). Um exemplo de ambiente de aplicações procedural é uma Máquina Virtual Java (JVM – Java Virtual Machine) e as suas implementações de APIs (Application Programming Interface).

No seu nível básico, o middleware possui um software que acessa o fluxo de streams de áudio, vídeo e dados, faz o roteamento dos streams para um dispositivo de saída (monitor) ou o armazenamento de dados, em um dispositivo de recepção, no caso STB, se este for provido de disco rígido.

O middleware recebe dados dos dispositivos de entrada (controle remoto/teclado) do usuário e envia saídas para a tela da televisão e para as caixas de som, além de fazer a comunicação com entidades remotas por meio de um canal de retorno.

Os padrões de middleware podem ser divididos em três categorias (SUN Microsystems):

  • Baseados em HTML, JavaScript e CSS (Cascade Style Sheet), que é definida pelo padrão ATVEF (Advanced Television Enhacement Fórum).
  • Tecnologias proprietárias como Open TV e WebTV.
  • Java TV, que é vista como a tecnologia da nova geração no que se refere a desenvolvimento de conteúdo para TV interativa.

O middleware foi desenvolvido para padronizar aplicações e tornar irrelevantes certas particularidades do hardware, no entanto, para cada sistema de televisão digital, existe um middleware diferente. Para os produtores de conteúdo, isto implica ter de dispor de diferentes versões da aplicação para cada uma das plataformas de middleware. Isto eleva os custos do processo de produção, uma vez que é sobre a tecnologia do middleware que é implementada a maioria das aplicações para TV digital interativa. Uma tendência é harmonizar diferentes middleware em um único padrão.

O Padrão GEM de Middleware

O MHP – Multimídia Home Plataform foi desenvolvido pelo DVB – Digital Vídeo Broadcasting, padrão europeu de TV digital, como o primeiro padrão aberto para a TV interativa. É um ambiente que define uma interface básica entre as aplicações digitais interativas e os terminais de recepção, nos quais as aplicações são executadas [8].

O MHP foi originariamente projetado para rodar nas plataformas que utilizam o padrão DVB de TV digital. Com a expansão do uso do middleware europeu, surgiram iniciativas para sua implementação em outras plataformas como forma de aproveitar aplicações desenvolvidas para diferentes sistemas. Esta demanda originou o GEM –Globally Executable MHP, uma estrutura que permite a outras organizações definirem especificações baseadas em MHP [8].

Uma destas especificações é o OCAP - Open Cable Application Plataform, plataforma de TV a cabo adotada nos Estados Unidos. No OCAP, as especificações do DVB, que não são usadas no ambiente de TV a Cabo norte-americano, foram retiradas e substituídas por seus equivalentes funcionais, conforme especificações do GEM.

A produção de conteúdo tornaria viável a portabilidade de produtos gerados para OCAP que, com pequenas mudanças, poderia adaptá-los ao padrão ACAPAdvanced Cammon Aplication Plataform, ou MHP e demais plataformas, que constituíram o padrão GEM como o ARIB B23, que está sendo desenvolvido em torno do GEM.

O GEM não é uma especificação completa para terminais de acesso, mas sim estrutura de suporte definida em que outra implementação de middleware pode ser instanciada. Pode-se dizer que o GEM é um padrão ao qual implementações existentes devem se adaptar para obter uma conformidade que garanta a execução global de aplicações.

O padrão GEM deverá tornar-se a solução futura para padrões de middlewares e prevê mudanças para adicionar funcionalidades a fim de sustentar aplicações padrão HTML, ou seja, estabelecer um padrão para middlewares declarativos.

Categorias de Middleware

Conforme já foi dito no artigo anterior, em aplicações para TV digital, poderão ser utilizadas linguagens declarativas ou não procedurais, dependendo do objetivo da aplicação, portanto os dois tipos de aplicação irão coexistir. O terminal de acesso deverá prover em seu software uma solução que integre a execução de tais aplicações.

O Middleware Declarativo

Baseado em um ambiente de aplicações declarativo, dá suporte a aplicações desenvolvidas em linguagens declarativas, ou padrão HTML. A linguagem HTML é dominante na Internet, devido à sua simplicidade e oferecer diversos recursos de fácil utilização. Como não foi projetada para ser utilizada em TV digital interativa, apresenta limitações. Outras linguagens declarativas como o SMIL, XMT-O e NCL, foram projetadas para este fim.

O foco da produção de conteúdo para a TV digital é a interatividade; as linguagens declarativas não requerem do programador domínio de cada passo a ser executado pelo programa; este fornece apenas o conjunto de tarefas a ser realizadas, cabendo ao executor da linguagem (interpretador, compilador ou a própria máquina real ou virtual de execução) implementar estas tarefas. As linguagens declarativas facilitam o desenvolvimento de aplicações, por parte de profissionais que não dominem as GEM ferramentas de programação, quando o conteúdo requer interação com o usuário, alternativa que minimiza os custos do desenvolvimento de conteúdo.

O conteúdo declarativo é recebido via fluxo de transporte de radiodifusão e armazenado localmente no terminal de acesso, ou acessado remotamente, mediante uma solicitação, via canal de retorno do terminal de acesso. Estes conteúdos multimídia são formados por diferentes tipos de mídias sincronizados, além de áudio e vídeo que compõem o fluxo normal. O middleware declarativo consiste em uma aplicação residente de navegação (agente de usuário) implementada nativamente no terminal de acesso - STB - ou receptor digital, que possibilitará a interação do usuário com o conteúdo.

O Middleware Procedural

A segunda alternativa é baseada em um ambiente de aplicações procedural, termo que agrega as linguagens não declarativas, entre estas o JAVA TV, embora não seja essa a terminologia usual em linguagem de programação. Desenvolver aplicações nesta plataforma requer domínio da linguagem de programação, pois, todo o fluxo de controle e execução do programa deverá ser informado. O programador possui maior poder sobre o programa, o que requer conhecimento dos recursos de implementação.

A função do middleware é possibilitar que as aplicações possam ser escritas de modo o mais independente possível do hardware e do sistema operacional presentes nos receptores digitais, permitindo a um mesmo código de aplicação ser carregado e executado em diferentes equipamentos. O middleware procedural é apresentado na forma de uma Máquina Virtual Java e um conjunto de APIs que convergem para o padrão MHP-GEM. Java é a linguagem de desenvolvimento suportada pelos principais middlewares para TV digital, existentes (MHP, DASE, ARIB, OCAP e ACAP).

É também neste cenário que se inserem as extensões sugeridas para o middleware: ensino a distância e gravador pessoal digital. A primeira se beneficia do canal de retorno para a interação completa entre o aluno e o provedor de serviços, mas não depende desta interação para que o usuário possa acessar os conteúdos.

A segunda não utiliza o canal de retorno, mas, requer um terminal de acesso mais avançado, com grande capacidade de armazenamento (STB com disco rígido). Grandes oportunidades de pesquisa estão nas aplicações interativas (conteúdo para TV Interativa) e nos padrões de middleware, que vão dar o suporte para estas aplicações.

GINGA-J – O MIDDLEWARE DO SBTVD-T

No Decreto 5.820, o Governo Brasileiro assume o compromisso de incorporar inovações tecnológicas, aprovadas pelo Comitê de Desenvolvimento, ao padrão de modulação ISDB-T.

Uma das muitas e talvez a mais importante inovação tecnológica desenvolvida pelos pesquisadores brasileiros concentra-se no middleware. A junção dos resultados de pesquisas, que originaram o middleware procedural FlexTV, com os resultados obtidos com o middleware declarativo Maestro, originaram o middleware Ginga [3]. Esta camada de software, que vai estar presente nos set-top boxes, reúne um conjunto de tecnologias e inovações brasileiras que o tornam a especificação de middleware mais avançada e, ao mesmo tempo, mais adequada à realidade do País.

O middleware Ginga, de acordo com os projetos que lhe deram origem, segue o padrão GEM de middleware procedural, e tem por base declarativa a linguagem NCL (Nested Context Language). Historicamente a linguagem NCL deriva do modelo NCM, resultado de pesquisas da academia brasileira, que contribuiu para as especificações do padrão MHEG, base do primeiro middleware declarativo da TV europeia, até hoje um dos mais utilizados.

O middleware declarativo dá suporte a aplicações desenvolvidas em linguagens declarativas, ao passo que o middleware procedural dá suporte a aplicações desenvolvidas em linguagens não-declarativas. Middlewares declarativos e procedurais são complementares. O middleware Ginga dará suporte a aplicações desenvolvidas em linguagens declarativas Ginga-ncl, e não declarativas Ginga-j.

O nome Ginga é sugestivo, no estilo bem brasileiro, “Ginga, porque esperamos poder afirmar que todos os brasileiros têm Ginga”, segundo os líderes do projeto. Esta afirmação se refere ao alcance que a TV digital interativa deverá ter nos lares brasileiros e a autonomia, que a adoção de tecnologia nacional proporcionará aos desenvolvedores de softwares e produtores de conteúdo para a nova mídia televisiva.

É no middleware que o Brasil tem a chance de criar seu “padrão”, esta declaração feita por James Beveridge, diretor da Microsoft, relata a importância do software na definição de um padrão e o potencial da indústria de software brasileira (BEVERIDGE, 2005).

A academia brasileira, mediante a competência de seus pesquisadores, desenvolveu o Ginga, um middleware inovador, que permitirá que programas produzidos no Brasil se comuniquem com outros padrões, assim como programas produzidos em outros padrões possam sem exibidos no SBTVD-T, além de atender às peculiaridades da produção de conteúdos para a diversidade de necessidades brasileiras.

O middleware Ginga pode ser dividido em três subsistemas principais:

  • Ginga-CC (Ginga Common-Core) - Oferece o suporte básico para os ambientes declarativos (Ginga-NCL) e procedural (Ginga-J). Dependendo das funcionalidades requeridas no projeto de cada aplicação, um paradigma de programação (declarativo ou procedural) possuirá uma melhor adequação que o outro;
  • Ginga-J - Desenvolvido pela UFPB (Universidade Federal da Paraíba) para prover uma infraestrutura de execução de aplicações baseadas em linguagem Java, com facilidades especificamente voltadas para o ambiente de TV digital;
  • Ginga-NCL - Desenvolvido pela PUC-Rio (Pontifícia Universidade Católica do Rio de Janeiro) para prover uma infraestrutura de apresentação de aplicações baseadas em documentos hipermídia escritos em linguagem NCL, com facilidades para a especificação de aspectos de interatividade, sincronismo espaço-temporal de objetos de mídia, adaptabilidade e suporte a múltiplos dispositivos.

Arquitetura

O Ginga oferece uma série de facilidades para o desenvolvimento de conteúdo e aplicativos para TV Digital, entre elas a possibilidade desses conteúdos serem exibidos nos mais diferentes sistemas de recepção, independente do fabricante e tipo de receptor (TV, celular, PDAs etc.).

No modelo de referência do Sistema Brasileiro, Ginga é uma camada de software interposta entre as aplicações e os outros módulos que compõem o Sistema Brasileiro, que são, usualmente, implementados por hardware (Figura 1).

pb_20_06_09_pic01.JPG
Figura 1. Camada de aplicações [12]

Quando se busca os requisitos de um middleware, tendo por base as aplicações a serem desenvolvidas em um sistema de TV digital, quatro pontos chamam a atenção: o sincronismo de mídia, o suporte a múltiplos dispositivos, a adaptabilidade e o suporte ao desenvolvimento de programas ao vivo.

Com esses requisitos em foco, o universo das aplicações para TV digital pode ser particionado em dois conjuntos: o das aplicações declarativas e o das aplicações procedurais. As linguagens declarativas são mais intuitivas (de mais alto nível) e, por isso, mais fáceis de usar, normalmente não exigindo um perito programador. Contudo, as linguagens declarativas têm de ser definidas com um foco específico. Quando o foco da aplicação não casa com o da linguagem, o uso de uma linguagem procedural não é apenas vantajoso, mas se faz necessário. O uso de linguagens procedurais usualmente requer um perito em programação. Uma aplicação não precisa ser, entretanto, puramente declarativa ou puramente procedural. Sem erro pode-se afirmar que, nos sistemas de TV digital, os dois tipos de aplicação coexistirão, sendo então conveniente que o dispositivo receptor integre o suporte aos dois tipos em seu middleware. Isso ocorre nos middlewares de todos os sistemas, incluindo o middleware Ginga.

No caso especial do Brasil, o middleware deve também oferecer um bom suporte ao desenvolvimento de aplicações visando à inclusão social, como aplicações para ensino, saúde etc. (Figura 2).

pb_20_06_09_pic02.JPG
Figura 2. Importância da TV na Inclusão Social [12]

A arquitetura da implementação de referência do middleware Ginga pode ser dividida em três grandes módulos: Ginga-CC (Common Core), o ambiente de apresentação Ginga-NCL (declarativo) e o ambiente de execução Ginga-J (procedural).

Ginga-CC oferece o suporte necessário aos ambientes declarativo e procedural, e tem como funções principais a exibição dos vários objetos de mídia, o controle do plano gráfico, o tratamento de dados obtidos do carrossel de objetos DSM-CC, o tratamento do canal de retorno, entre outras (Figuras 3 e 4).

pb_20_06_09_pic03.JPG
Figura 3. Arquitetura de alto nível, baseado na ITU - “ITU-T Recommendation J.200: Worldwide common core – Application environment for digital interactive television services”, 2001
pb_20_06_09_pic04.JPG
Figure 4. Componentes comuns do Ginga (ISDTV-T Forum. “Volume 2 of ISDTV-T Standard 06”. ISDTV-T Forum Draft, December, 2006)

Quanto ao ambiente de apresentação Ginga-NCL, a única linguagem declarativa que oferece suporte a todos os requisitos mencionados para um middleware é a linguagem NCL (Nested Context Language), desenvolvida no Laboratório TeleMídia da PUC-Rio, e escolhida como base do Ginga. NCL é uma das principais linguagens existentes para a definição do sincronismo temporal. Como vantagem adicional, e imprescindível em um sistema de TV digital, NCL também provê suporte a variáveis, que podem ser manipuladas através de código procedural, entre eles o de sua linguagem de script Lua.

Lua, também desenvolvida no Departamento de Informática da PUC-Rio, constitui-se hoje em padrão internacional de fato na área de entretenimento, em especial jogos. Alguns dos principais jogos lançados nos últimos anos utilizaram Lua em seu desenvolvimento. Lua é leve, fácil de usar e possui um altíssimo desempenho.

Para facilitar o desenvolvimento de aplicações Ginga-NCL, a PUC-Rio desenvolveu também a ferramenta Composer. Composer é um ambiente de autoria voltado para a criação de programas NCL para TV digital interativa. Nessa ferramenta, as abstrações são definidas em diversos tipos de visões que permitem simular um tipo específico de edição (estrutural, temporal, layout textual). Essas visões funcionam de maneira sincronizada, a fim de oferecer um ambiente integrado de autoria.

Por sua vez, o ambiente de execução Ginga-J, desenvolvido no Laboratório LAVID da UFPB, utiliza a linguagem Java e é dividido em três partes: as APIs vermelhas, inovações que dão suporte às aplicações brasileiras, em especial as de inclusão social; as APIs amarelas, também inovações brasileiras, mas que podem ser exportadas para os outros sistemas; e as APIs verdes, que seguem o núcleo comum do padrão GEM (Globally Executable MHP) (Figura 5).

pb_20_06_09_pic05.JPG
Figure 5. APIs verde, amarela e vermelha do Ginga-J [12]

Diferente dos outros sistemas, os ambientes de apresentação e execução do middleware Ginga se complementam, unidos por uma ponte em uma implementação sem nenhuma redundância, o que confere ao sistema uma ótima eficiência, tanto em termos de uso de CPU quanto de ocupação de memória. Ao contrário dos outros sistemas, Ginga, desde seu projeto inicial, foi desenvolvido tendo em mente os dois ambientes de programação (Figura 5).

Referências Bibliográficas
  1. GRACIOSA, Hélio Marcos M. - Uma visão da implantação da TV digital no Brasil. Acesso em abril de 2008;
  2. CPqD ARQUITETURA DE REFERÊNCIA - Sistema Brasileiro de Televisão Digital Terrestre. PD.30.12.34A.0001A/RT-13/AA.
  3. TONIETO, Márcia Terezinha; Sistema Brasileiro de TV Digital – SBTVD - Uma Análise Política e Tecnológica na Inclusão Social; Mestrado Profissional em Computação Aplicada – UECE/CEFET - Dezembro de 2006;
  4. SOUZA FILHO, Guido Lemos de; LEITE, Luiz Eduardo Cunha; BATISTA, Carlos Eduardo Coelho Freire. Ginga-J: The Procedural Middleware for the Brazilian Digital TV System. In: Journal of the Brazilian Computer Society. No. 4, Vol. 13. p.47-56. ISSN: 0104-6500. Porto Alegre, RS, 2007;
  5. LEITE, L. E. C., et al. FlexTV – Uma Proposta de Arquitetura de Middleware para o Sistema Brasileiro de TV Digital (FlexTV – a Middleware Architecture Proposal for the Brazilian Digital TV System). In: Revista de Engenharia de Computação e Sistemas Digitais, v. 2, pp 29-50, 2005;
  6. Portal do Software Público Brasileiro – Acesso em maio e junho de 2008;
  7. Middleware Ginga – Acesso em 02 de junho de 2008;
  8. DVB Document A103 – Globally Executable MHP (GEM) Specification 1.1. DVB Bluebook, 2007. Acesso em junho de 2008;
  9. Ambiente para Desenvolvimento de Aplicações Declarativas para a TV Digital BrasileiraAcesso em 03 de março de 2008;
  10. Construindo Programas Audiovisuais Interativos Utilizando a NCL 3.0 e a Ferramenta Composer - 2a. edição (versão 3.0) – Acesso em junho de 2008;
  11. CPqD ARQUITETURA DE REFERÊNCIA - Sistema Brasileiro de Televisão Digital Terrestre. PD.30.12.34A.0001A/RT-13/AA;
  12. Fórum do Sistema Brasileiro TV Digital Terrestre;
  13. A TV Digital Brasileira;
  14. IDG Now. Especiais sobre TV Digital
  15. Ministério da Ciência e Tecnologia. Notas de imprensa
  16. Ministéria das Comunicações. Sistema Brasileiro de TV Digital
  17. ISDTV-T Forum. “Volume 4 of ISDTV-T Standard 06”. ISDTV-T Forum Draft, December, 2006