Sessions REGULAR SESSIONS

2.2.1 Introdução

Televisão Digital é o nome comumente utilizado para definir a “nova” tecnologia adotada no sistema de produção, transmissão e recepção de conteúdo televisivo que vem substituindo a tecnologia mais antiga: a TV Analógica.

36

A Figura 2.1mostra um modelo simplificado do sistema de TV Analógica tradicional.

Figura 2.1: Modelo simplificado de um sistema de TV analógica.

Como ilustrado na Figura 2.1, num sistema de TV Analógica tradicional, um programa televisivo sendo transmitido ao vivo, por exemplo, tem seu áudio e vídeo capturados por câmeras e microfones transformados em sinais eletromagnéticos e enviados via broadcast utilizando-se um meio de comunicação, comumente o ar. Telespectadores em suas residências são capazes de receber esse sinal que é captado pela antena do televisor e este utiliza as informações contidas no sinal para exibir cada pixel de cada frame que compõe o vídeo na tela, e reproduzir cada elemento de frequência e amplitude do som no sistema de áudio.

A primeira diferença entre o sistema de TV Analógica e o de TV Digital é em relação à utilização de algoritmos de compressão de dados para a codificação do sinal capturado pelas câmeras e microfones. Esses algoritmos são baseados nas características de percepção de sons e imagens do ser humano. Esse processo proporciona duas vantagens principais: (i) permite que seja possível a criação de mecanismos de correção de erros a serem utilizados na decodificação feita no aparelho receptor, fazendo com que som e imagem recebidos sejam exatamente iguais aos enviados, garantindo qualidade de som e imagem; e (ii) diminui a banda necessária para a transmissão dos sinais capturados, permitindo o envio de som e imagem com uma maior resolução e, principalmente, que sejam enviados outros tipos de dados, como outros vídeos, figuras e até mesmo aplicações, as quais podem ser utilizadas como meio de interação entre usuário e a TV para permitir, por exemplo, que o usuário pause filmes, veja informações sobre a programação, etc. A esse tipo de aplicação é dado o nome de aplicações interativas e ao processo de interação

37

dá-se o nome interatividade.

A Figura 2.2ilustra um típico sistema de TV Digital.

Figura 2.2: Modelo simplificado de um sistema de TV Digital. Fonte: (SOARES; BARBOSA,

2008)

Como se pode ser visualizado na Figura 2.2, nesse novo paradigma, um programa de TV pode ser considerado uma aplicação utilizada para gerenciar conteúdo multimídia sendo enviado. Nesse caso, a aplicação e seu conteúdo (áudio e vídeo principais e demais mídias), produzidos pela emissora, são multiplexados e enviados via broadcast. No sistema receptor, que pode ser um Set-Top Box (STB) - aparelho receptor do sinal de TV Digital - ou um celular, por exemplo, o sinal é demultiplexado, sendo que áudio e vídeo principais são enviados para os sistemas de som e imagem do televisor e a aplicação é enviada para o middleware de TV Digital (destacado na Figura 2.2), elemento do sistema receptor de TV Digital responsável por abstrair aspectos específicos das plataformas receptoras e dar o suporte necessário para a execução das aplicações sendo, portanto, elemento essencial para prover interatividade.

2.2.2 Interatividade

A interatividade é, sem dúvida alguma, um dos maiores benefícios providos pela TV digital, pois, além de interações simples entre telespectador e aparelho televisor, como o controle das mídias sendo exibidas, por exemplo, a interatividade pode permitir funcionalidades adicionais, como o

38

acesso a serviços disponíveis na Internet.

Dado o fato de que quase todos os domicílios brasileiros possuem pelo menos uma televisão, enquanto poucos possuem computadores com acesso à internet (estatísticas da Pesquisa Naci- onal de Amostras por Domicílio (PNAD) mostram que em 2009 95% dos domicílios brasileiros possuíam televisão, mas apenas 27,4% possuíam computadores com acesso à internet (TELECO,

2011)), foi vislumbrada a possibilidade de transformar a TV Digital num meio essencial de in- clusão digital e social. Sendo assim, foi instituído em 26 de Novembro de 2003, via decreto presidencial número 4.901 (DP4901, 2003), o Sistema Brasileiro de Televisão Digital (SBTVD), cujo padrão de middleware, definido posteriormente, pode ser utilizado para prover ao brasileiro comum o acesso a serviços públicos digitais, como serviços de educação à distância, serviços governamentais, serviços de saúde ou “simplesmente” o acesso à internet.

2.2.3 Ginga: O middleware do SBTVD

Ginga é o nome do middleware do SBTVD. Como discutido na seção anterior, sua principal função é abstrair aspectos específicos das plataformas receptoras, que podem ser de tecnologias variadas, e dar o suporte necessário para a execução das aplicações, de acordo com os requisitos estabelecidos no padrão do SBTVD.

A arquitetura do Ginga foi estabelecida de acordo com as necessidades que os aplicativos de TV digital demandam. Em geral, estes aplicativos podem ser desenvolvidos seguindo dois paradigmas de programação: o imperativo e o declarativo. A escolha do paradigma depende exclusivamente das necessidades e do tipo de aplicativo em questão. O middleware Ginga possui dois subsistemas lógicos para lidar com estas possibilidades: a Máquina de Apresentação Ginga- NCL (SOARES; RODRIGUES; MORENO, 2007), para o paradigma declarativo e a Máquina de Execução Ginga-J (FILHO; LEITE; BATISTA,2007), para o paradigma imperativo.

Estes subsistemas compartilham um terceiro componente arquitetural denotado por Common Core (ou Ginga-CC). A Figura 2.3 apresenta uma visão macro da arquitetura, relacionando estes três componentes. Percebe-se que embora Ginga-J (Ambiente de execução) e Ginga-NCL (ambiente de apresentação) sejam componentes distintos, existe uma relação entre eles, de modo que aplicações declarativas podem fazer referência às imperativas e vice-versa.

39

Figura 2.3: Arquitetura do Ginga. Fonte: (SOARES,2009)

Ginga responsável pelo processamento de aplicativos para TV digital escritos em Java (também conhecidos como Xlets). Esta especificação incorpora novas funcionalidades, mas mantém com- patibilidade com a maior parte dos middleware de TV digital compatíveis com o GEM, uma especificação unificada proposta pelo grupo europeu DVB para middleware de TV digital).

Pelo fato de não ser obrigatória a implementação do subsistema Ginga-J em todos os tipos de dispositivos receptores (ABNT, 2007a, pág.14), este trabalho considera apenas o ambiente declarativo Ginga-NCL e o paradigma declarativo.

O Ginga-NCL, ilustrado na parte superior direita da Figura2.3, é o subsistema responsável pelo ambiente declarativo do Ginga. Sua principal funcionalidade é o processamento de docu- mentos NCL (Nested Context Language). NCL é uma linguagem de aplicação XML (eXtensible Markup Language) com facilidades para a especificação de aspectos de interatividade, sincro- nismo espaço-temporal entre objetos de mídia, adaptabilidade, suporte a múltiplos dispositivos e suporte à produção ao vivo de programas interativos não-lineares. NCL aceita também objetos imperativos chamados NCLua, os quais devem ser escritos em linguagem Lua (LUA,1993).

O suporte a múltiplos dispositivos foi originalmente inserido no padrão do Ginga motivado, principalmente, pelas vantagens proporcionadas pela utilização de múltiplos dispositivos de exi- bição, como a possibilidade de se obter múltiplas navegações individuais em dispositivos variados de um mesmo conteúdo recebido pela TV (COSTA; MORENO; SOARES,2009). O padrão define dois tipos de classes de dispositivos utilizados para este fim: a classe passiva, cujos dispositivos

40

exibem o mesmo conteúdo sob controle de navegação único; e a classe ativa, onde o controle da apresentação é feito individualmente. Essa característica é refletida na linguagem NCL, onde é possível direcionar as mídias a serem exibidas para os dispositivos cadastrados em uma dessas classes (a implementação de novas classes é possível, porém específica da implementação, assim como a implementação dos mecanismos de registro e gerenciamento de dispositivos).

A função do Common Core é prover serviços comuns necessários para o funcionamento dos ambientes declarativo e imperativo. Dentre estes serviços podem ser citados como exemplos a decodificação e demultiplexação do conteúdo transportado via MPEG-2 Transport Stream e decodificação/apresentação de mídias em diversos formatos.

Apesar de serem componentes opcionais da arquitetura do Ginga-CC, o Gerenciador de Contexto e o Canal de Interatividade são elementos essenciais para enriquecer a execução de aplicações interativas na TV Digital. O Gerenciador de Contexto é o elemento responsável por colher e armazenar informações sobre o receptor, o telespectador e sua localização e disponibilizá- las para que as aplicações as utilizem para adaptar seu comportamento, ou para exibí-las na tela (SOARES,2009). A forma com que essas informações devem ser adquiridas não é padronizada; logo, depende da implementação específica do middleware. Quais informações são armazenadas e como elas devem ser acessadas pelas aplicações, porém, são padronizados. O acesso, por exemplo, deve ser feito por meio da utilização do nó settings, elemento de mídia do tipo application/x- ginga-settings (Seção2.2.4.1). É importante ressaltar que a restrição imposta pelo padrão sobre as informações a serem utilizadas restringe também a gama de domínios a serem explorados por aplicações sensíveis ao contexto. Uma forma de adquirir essas e outras informações utilizando apenas funcionalidades do padrão é por meio do Canal de Interatividade via protocolo TCP/IP (ABNT,2008), o qual pode ser acessado pela aplicação por meio de objetos NCLua, o que ajuda a contornar as restrições impostas pelo Gerenciador de Contexto padrão citadas anteriormente. Ao longo deste trabalho às informações sobre receptor, telespectador, localização, e a qualquer outra que possa ser utilizada para caracterizar o contexto em que uma aplicação está sendo apresentada, dá-se o nome de “informação contextual”, e às aplicações que utilizam essa informação para adaptar seu comportamento dá-se o nome de “aplicações sensíveis ao contexto” (ver Seção2.3). Numa aplicação interativa sensível ao contexto no domínio de saúde, por exemplo, o Geren- ciador de Contexto poderia interagir com o Canal de Interatividade para recuperar informações sobre os sinais vitais do telespectador cardíaco e disponibilizá-las para a aplicação. Caso a

41

aplicação detecte alguma anomalia, ela pode automaticamente acionar um serviço médico de emergência provido por algum hospital público, o que também poderia ser feito pela utilização do Canal de Interatividade.

Pode-se dizer, então, que aplicações sensíveis ao contexto para a TV Digital podem ser implementadas nas linguagens NCL e Lua e devem utilizar os componentes Gerenciador de Contexto e Canal de Interatividade do Ginga-CC.

2.2.4 Aplicações Declarativas para o Ginga

As aplicações do ambiente declarativo da TV Digital, como já dito anteriormente, devem ser escritas em NCL. Em NCL há uma separação entre os conteúdos, ou mídias, a serem exibidos, como textos, vídeos, áudios, etc, e a estrutura da exibição dessas mídias, ou seja, a especificação de qual mídia deve ser exibida, quando ela deve ser exibida e onde (região da tela, ou até mesmo outros dispositivos).

Caso seja necessária a execução de código imperativo, para acesso ao Canal de Interatividade, por exemplo, deve ser incluída na aplicação NCL uma mídia NCLua apontando para seu arquivo de implementação, chamado de script Lua, que, quando inicializada pela aplicação, executa seu código.

2.2.4.1 Linguagem NCL

A linguagem NCL é baseada em módulos, que são “coleções de elementos, atributos e valores de atributos XML semanticamente relacionados que representam uma unidade de funcionali- dade” (ABNT,2007b). Os módulos de NCL são agrupados em áreas funcionais que definem os elementos da linguagem e suas funcionalidades.

A área funcional Presentation Control, por exemplo, pode ser utilizada para controlar e adaptar a exibição de conteúdo. Isso é feito com a utilização de seus elementos switch, que utilizam regras lógicas por meio de elementos rule que operam sobre variáveis, cujos valores determinam se a aplicação terá este ou aquele comportamento. Essas variáveis são, por padrão, propriedades de um nó settings, elemento do tipo mídia (discutido à seguir) que, como já exposto anteriormente, é gerenciado pelo Gerenciador de Contexto padrão. Esses recursos podem ser utilizados para a implementação de aplicações que manipulam contextos simples, que dependam

42

apenas das informações contidas no padrão, como perfil do usuário e localização. Esses recursos, porém, não são suficientes para atender à maioria dos requisitos associados ao desenvolvimento de aplicações sensíveis ao contexto mais complexas (Seção2.3).

Ao longo de outros trabalhos que também visam a implementação de uma infraestrutura adequada para manipulação de contexto no Ginga (VALE, 2011) (MIELKE, 2010), foi perce- bida a importância de outras áreas funcionais para o desenvolvimento de aplicações sensíveis ao contexto: Components, Interfaces, Connectors e Linking.

Components são os elementos de NCL utilizados para encapsular os objetos de mídia, cujos aspectos espeço-temporais são controlados pela aplicação. Cada objeto de mídia pode possuir um id, um atributo src indicando de onde a mídia pode ser carregada, um type indicando o tipo da mídia (áudio, vídeo, ts, script Lua etc.), e um descriptor, elemento de outra área funcional que descreve como a mídia deve ser apresentada.

Interfaces são os elementos de NCL utilizados para a definição de interfaces nos objetos de mídia que podem ser acessadas por outros objetos da linguagem para permitir, por exemplo, o controle dessas mídias. Um exemplo de interface são as âncoras de propriedades, que definem propriedades relacionadas às mídias. No caso de uma mídia NCLua, por exemplo, essas propri- edades podem ser alteradas por outros elementos da linguagem alterando a execução do script referente a essa mídia.

Connectors e Linking são os elementos de NCL que podem ser combinados para definir, o relacionamento causal entre elementos de mídia. Assim eles podem ser utilizados para definir, por exemplo, que o texto “a” deve ser exibido assim que o vídeo “b” terminar, ou ainda, que se o valor da propriedade “sinais_vitais” da mídia NCLua “joao” for alterado para “alerta”, as mídias de vídeo “vídeo_primeiros_socorros” e NCLua “web_service_hospital” devem ser inicializadas. Elementos dos connectors, os conectores causais causalConnectors definem os papéis envol- vidos na relação de causa e efeito, ou condição e ação, que podem ser simples (simpleCondition e simpleAction) ou compostas (compoundCondition e compoundAction). As condições podem ser utilizadas para monitorar eventos de transição simples, como o início ou o fim de um vídeo, por meio de condições simples monitorando transições de mídia (transition), ou avaliação de valores de atributos das mídias, ou de expressões, por meio dos elementos assessmentStatement e compoundStatement.

43

Esses papéis são preenchidos por elementos de mídia, por exemplo, com a utilização do links por meio do seu elemento bind.

A Figura 2.4 mostra um exemplo de código NCL para exemplificar a utilização desses ele- mentos.

Figura 2.4: Exemplo de código NCL

O código NCL apresentado na Figura2.4é utilizado para manipular duas mídias: um vídeo, e uma imagem que contém uma mensagem de pause. Essas mídias estão localizadas na pasta media, como pode ser visualizado no campo src das mesmas (linhas 21 e 24). Informações sobre como e onde essas mídias serão exibidas são definidas pelos elementos descritores (descriptors) que apontam para nós de região (region), que podem indicar a região da tela e as dimensões das mídias a serem exibidas. O conector causal onPauseStart define os papéis de condição e ação onPause e start que são preenchidos pelas mídias video e pause por meio de um link, fazendo com que sempre que o vídeo é pausado, a imagem de pause seja exibida.

2.2.4.2 Objetos NCLua

Como já visto anteriormente, caso seja necessária, por parte da aplicação, a execução de código imperativo, isso pode ser feito pela inclusão de objetos NCLua via nós de mídia de NCL.

Objetos NCLua são utilizados para permitir que a aplicação NCL principal seja estendida por meio de scripts escritos na linguagem NCLua - resultado da extensão da linguagem Lua

44

(LUA, 1993) para prover funcionalidades necessárias para atender os requisitos do padrão do SBTVD (ABNT,2007b). Aplicações NCL devem, por exemplo, fazer uso de scripts NCLua para acessar o Canal de Interatividade. Nesse caso, os scripts geralmente são responsáveis por efetuar a troca de dados, processar informações e realizar comunicação com o documento NCL.

O ambiente de NCLua adota um mecanismo de comunicação assíncrono, baseado em eventos. Os objetos NCLua, por meio de seus scripts, atuam como tratadores de eventos, enviando eventos para, e recebendo de, outros elementos. Para isso deve ser utilizado o módulo event, da biblioteca padrão. Um script pode receber eventos vindos da Emissora (eventos da classe si) e do Controle Remoto (eventos da classe key), além de enviar e receber eventos do Canal de Interatividade (eventos da classe tcp) e do Formatador NCL (eventos da classe ncl), que nesse caso representa o documento NCL que inicia o script NCLua. Um script NCLua pode, também, enviar eventos a si mesmo por meio de eventos da classe user.

Devido à capacidade de comunicação com o meio externo provida pela interação entre ob- jetos NCLua e o Canal de Interatividade via eventos tcp, pode-se dizer que esses elementos são essenciais para o desenvolvimento de aplicações sensíveis ao contexto para a TV Digital.