• Nenhum resultado encontrado

Desenvolvimento de Aplicações Declarativas para TV Digital Interativa

N/A
N/A
Protected

Academic year: 2021

Share "Desenvolvimento de Aplicações Declarativas para TV Digital Interativa"

Copied!
38
0
0

Texto

(1)

Capítulo

1

Desenvolvimento de Aplicações Declarativas para

TV Digital Interativa

Carlos de Salles Soares Neto, Simone Diniz Junqueira Barbosa,

Luiz Fernando Gomes Soares, Rogério Ferreira Rodrigues

Abstract

This course addresses the declarative authoring of programs for the Interactive Digital TV. The course presents the reference models for Digital TV and the main application types. The development of NCL (Nested Context Language) applications is described and illustrated by examples, including their supporting mechanisms for media synchronization and their tools for the nonlinear editing of programs. The course also presents some basic concepts of usability and their applications to the design of interactive audio-visual programs.

Resumo

Este mini-curso é voltado para a autoria declarativa de programas para TV Digital Interativa. O mini-curso apresenta os modelos de referência para TV Digital e os principais tipos de aplicações. O desenvolvimento de aplicações com base em NCL (Nested Context Language) é descrito e ilustrado com exemplos, o que inclui seus mecanismos de suporte para o sincronismo de mídias e ferramentas para edição de programas não-lineares. O mini-curso também objetiva apresentar alguns conceitos básicos de usabilidade e suas aplicações para o design de programas audiovisuais interativos.

1.1. Introdução

A mudança da TV Analógica para a TV Digital não significa apenas uma melhora significativa na qualidade da imagem e do som. Com a TV Digital, problemas decorrentes de ruídos ou multipercurso de sinal não são mais graves. Enquanto houver sinal mantém-se a mesma qualidade na reprodução do conteúdo. Outro aspecto importante é a tendência natural ao surgimento de uma vasta gama de novos serviços na

(2)

TV Digital, como a oferta de guias eletrônicos de programas, a distribuição de jogos de computador, o controle de acesso e a proteção de conteúdo (criptografia).

Assim como ocorreu na área de telecomunicações há alguns anos, o foco para a definição de um novo sistema de TV Digital não parece ser apenas o de permitir uma maior interoperabilidade de aparelhos. Outro importante desafio desse novo modelo de TV é a adoção de padrões que permitam a construção rápida, fácil, eficiente e livre de erros de novas aplicações interativas. A dificuldade em fornecer tais serviços parece evidente: apesar da expectativa de haver um amplo número de equipamentos diferentes, é necessário um alto grau de interoperabilidade para que o autor de programas interativos crie um único documento para ser reproduzido em qualquer plataforma de recepção.

As novas funcionalidades da TV Digital interativa podem ser resumidas como “agregar capacidade computacional à TV”. Como há um grande legado de TVs analógicas, uma solução simples para oferecer esses novos serviços é utilizar junto à TV um pequeno computador capaz de tratar corretamente o sinal de radiodifusão, decodificá-lo e exibir de forma consistente a programação de TV, as aplicações e os serviços avançados. Esse “computador” é chamado de terminal de acesso (ou set-top

box). Num futuro próximo, a tendência por uma convergência é natural, de forma que a

TV traga embutido esse terminal de acesso e mais, que outros dispositivos de exibição possam ser utilizados como celulares, PDAs, etc.

Há tipicamente três camadas de software atuando em um terminal de acesso: os serviços, programas e aplicações (no nível mais alto); o middleware; e o sistema operacional. O sistema operacional atua como uma camada de abstração para facilitar a implementação de programas, tornando-os independentes do hardware sobre o qual eles executam.

O middleware é uma camada que atua sobre o sistema operacional e cuja função é oferecer aos diferentes serviços, programas e aplicações, por meio de uma API bem definida, o conceito de uma máquina abstrata sobre a qual se tem uma visão única dos diferentes tipos de terminais de acesso. Ao definir o middleware para um terminal de acesso, os padrões oferecem o suporte para dois tipos de aplicações: as imperativas e as declarativas.

Em geral, aplicações onde o sincronismo e adaptabilidade exercem papéis preponderantes são mais fáceis de serem especificadas usando uma linguagem declarativa orientada a esse tipo de foco. Porém, quando a exigência de sincronismo ou adaptabilidade é apenas eventual, o melhor suporte é dado por uma linguagem imperativa de propósito geral.

O conjunto de serviços que dão suporte ao desenvolvimento de aplicações imperativas tem como objetivo definir uma máquina abstrata única que é chamada de

máquina de execução. Por sua vez, os mecanismos para o suporte a aplicações

declarativas compõem a máquina de apresentação. Alguns exemplos de máquinas de apresentação são o ACAP-X [ATSC 2005], DVB-HTML [ETSI 2005], BML [ARIB 2004] e o Ginga-NCL. Este mini-curso é voltado especificamente para a autoria declarativa de programas interativos para TV Digital Interativa fazendo uso da máquina de apresentação Ginga-NCL.

(3)

1.2. Principais tipos de aplicação

As aplicações de TV Digital Interativa podem estar ou não semanticamente associadas ao conteúdo do áudio ou vídeo principal. Adicionalmente, elas podem definir ou não relações de sincronismo entre objetos de mídia que a compõem, entre eles o conteúdo principal (vídeo e áudio).

Uma aplicação de correio eletrônico, por exemplo, está sempre disponível e não possui relação semântica com o conteúdo do programa televisivo exibido. Por outro lado, uma aplicação que calcula o “nível de estresse” em um programa de saúde, por exemplo, poderia estar disponível durante toda sua exibição. É conveniente notar que, mesmo não havendo relações de sincronismo dessas aplicações com o áudio e vídeo principal, tais aplicações podem ser compostas de objetos que mantêm relações de sincronismo entre si. Ainda um terceiro tipo de aplicação é composto por aplicações em que existe não só uma relação semântica entre seus objetos de mídia e o áudio e vídeo principal do programa televisivo, mas também uma relação de sincronismo. Esse é exatamente o caso dos chamados programas não-lineares.

O termo não-linear vem em contraposição à forma seqüencial – linear – que caracteriza os programas para a TV analógica. Nesses últimos, existe um e apenas um caminho, seqüencial, de exibição. Ao contrário, os programas não-lineares são compostos de múltiplas cadeias de exibição, algumas exibidas em paralelo e outras como alternativas (ou seja, ou uma cadeia ou a outra) que dependem da escolha do usuário, do terminal onde o programa será exibido, da região onde o telespectador está inserido etc. O exemplo mais simples de um programa não-linear é aquele onde, em um dado instante de exibição, o usuário telespectador pode escolher entre formas alternativas de sua continuação. Note assim que o programa deixa de poder ser representado por uma linha de tempo e passa a ter um fluxo de exibição que pode ser especificado por um grafo.

Na grande maioria dos casos, a linguagem declarativa tende a ser a preferencial no desenvolvimento dos programas lineares. Mais ainda, como em programas não-lineares o sincronismo intermídia sem a interação do usuário deve ser tão ou mais importante que a interatividade, o sincronismo de mídias em sua forma mais ampla, e não a interatividade, deve ser o foco das linguagens declarativas, como é o caso da linguagem NCL, proposta para o SBTVD.

Um outro aspecto importante para as aplicações é a adaptabilidade. Ao agregar capacidade computacional à TV, torna-se possível fazer com que o terminal de acesso adapte o conteúdo de acordo com informações de contexto referentes às preferências ou localização do usuário, ou ainda à disponibilidade atual do terminal de acesso (capacidade de processamento, memória disponível etc). A adaptação pode não envolver apenas o conteúdo de cada objeto de mídia individualmente mas também a própria forma de apresentação. NCL provê suporte a ambos os tipos de adaptação.

O suporte a múltiplos dispositivos de exibição é também uma característica importante no suporte à interatividade em um sistema de TV digital. Através de múltiplos dispositivos de exibição será possível, por exemplo, que a interação de um usuário com o programa de TV traga novos objetos a serem exibidos em seu dispositivo particular de interação, sem que apareçam na tela da TV, não atrapalhando, assim, uma

(4)

audiência coletiva. O suporte a múltiplos dispositivos de exibição é outra característica importante da linguagem NCL.

Independente de a autoria ser feita de forma declarativa ou imperativa, é necessário oferecer o suporte à produção de programas não-lineares ao vivo. Geralmente, a autoria e a exibição de documentos multimídia (como os programas da TV Digital interativa) ocorrem em fases distintas. Em um evento ao vivo, no entanto, é necessário que a autoria do documento ocorra ao mesmo tempo em que é feita a exibição.

A máquina de apresentação Ginga-NCL oferece suporte à exibição e edição de programas não-lineares ao vivo. Para isso ela é capaz de receber, via carrossel de dados do padrão DSM-CC [ISO 1998], a especificação de um programa NCL, e controlar a exibição sincronizada de seus objetos. Através do mecanismo de sincronização baseado em elos da NCL, e de um protocolo de sinalização baseado em eventos DSM-CC, foi possível construir um modelo de edição de programas de TV em paralelo com suas exibições [Moreno et al. 2005]. Comandos de edição foram definidos, permitindo que o

middleware seja notificado para adicionar ou remover uma entidade NCL (objeto de

mídia, âncora, elo, contexto etc.) em tempo de exibição. Esses comandos são enviados através de eventos de sincronização (stream events) oferecidos pelo padrão DSM-CC. A máquina de apresentação Ginga-NCL efetua a operação e recalcula as suas estruturas de dados de execução para que a mudança surta o efeito na exibição do programa. Incluir e retirar objetos e elos de contextos são operações triviais em documentos NCL, uma vez que não implicam mudanças na estrutura do documento. Cabe ressaltar que a inclusão de tal facilidade em modelos de sincronismo baseados em composições seria muito difícil.

1.3. Modelo de Contextos Aninhados (NCM)

NCL (Nested Context Language) é uma linguagem de autoria de documentos multimídia baseada no NCM. O NCM (Nested Context Model, Modelo de Contextos Aninhados) utiliza os conceitos de nós (nodes) e elos (links) comumente aplicados em documentos hipermídia (Figura 1.1a).

(a) (b)

Figura 1.1. Nós e elos (a) num hipertexto comum e (b) com nós de composição (contextos).

No NCM, os grafos podem ser aninhados, permitindo segmentar e estruturar o documento hipermídia conforme necessário ou desejado. Isto é feito através de nós de composição, que são nós compostos de grafos NCM (Figura 1.1b). Um nó de composição também é chamado de contexto.

(5)

Assim, em NCM, um node (nó) pode ser de dois tipos:

 nó de conteúdo ou de mídia (content node ou media node): associado a um elemento de mídia como vídeo, áudio, imagem, texto, aplicação etc.; ou

 nó de composição ou contexto (composite node ou context).

No caso da Figura 1.1b, capítulo 1 e capítulo 2 são contextos (nós de composição), enquanto cada seção é um nó de conteúdo.

Para auxiliar a construção de documentos hipermídia seguindo o modelo NCM, foi desenvolvida a linguagem NCL, que será utilizada por todo este documento na elaboração de exemplos de documentos hipermídia. Os elementos da linguagem serão introduzidos progressivamente, com base em exemplos. Os exemplos serão baseados na versão atual da máquina de apresentação Ginga-NCL, que interpreta um documento NCL e apresenta o programa audiovisual interativo nele representado. As seções seguintes apresentam uma introdução básica sobre vários elementos do modelo NCM e como os mesmos são expressos por meio de NCL. Maiores detalhes sobre NCM podem ser encontrados em [Soares & Rodrigues 2005].

1.3.1 Regiões

Uma região (region) é definida como uma área no dispositivo de saída onde um nó de mídia pode ser exibido. Para organizar o layout das diversas partes do documento hipermídia, as regiões podem ser aninhadas. Em NCL, as regiões devem ser definidas no cabeçalho do programa (<head>), na seção de base de regiões (<regionBase>). Todo documento NCL possui pelo menos uma região, que define a dimensão e as características da tela onde um ou mais nós de mídia serão apresentados. Uma região serve para posicionar os nós de mídia em locais específicos. Uma região para que o vídeo seja apresentado no centro de uma tela com resolução de 720x576 pixels seria:

<region id="rgVideo1" left="200" top="168" width="320" height="240" />

A Figura 1.2 ilustra a região definida no exemplo acima:

Figura 1.2. Definição de regiões da tela.

Todas as regiões devem ser definidas no cabeçalho do programa (<head>), contidas na seção de base de regiões (<regionBase>).

A NCL define os seguintes atributos de região:

id: identificador único, utilizado nas referências à região (por exemplo, nos descritores das mídias que são apresentadas na região)

(6)

left (esquerda): coordenada x do lado esquerdo da região, com relação à coordenada do lado esquerdo da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra)

top (topo): coordenada y do lado superior da região, com relação à coordenada do lado superior da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra)

right (direita): coordenada x do lado direito da região, com relação à coordenada do lado esquerdo da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra)

bottom (base): coordenada y do lado inferior da região, com relação à coordenada do lado superior da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra)

width (largura) e height (altura): dimensões horizontal e vertical da região. Cabe observar que o autor pode escolher especificar as dimensões de uma região de acordo com a melhor conveniência. Por exemplo, em certos casos pode ser melhor definir os atributos right, bottom, width, height. Em outros casos, pode ser mais apropriado especificar os atributos top, left, width e height.

zIndex: posição da região no eixo “z”, utilizado geralmente para indicar, no caso de regiões sobrepostas, quais regiões aparecem sobre quais outras. Camadas com zIndex maior são apresentadas no topo de (sobrepondo) camadas com zIndex menor.

1.3.2 Descritores

Um descritor (descriptor) define como um nó de mídia será apresentado, incluindo a associação com uma região onde será exibido. Em NCL, todos os descritores devem ser definidos no cabeçalho do programa (<head>), na seção de base de descritores (<descriptorBase>). Um descritor do vídeo pode ser definido da seguinte maneira:

<descriptor id="dVideo1" region="rgVideo1" />

Este descritor é identificado como dVideo1 e se refere à região rgVideo1. A NCL define os seguintes atributos de descritor:

id: identificador único, utilizado nas referências ao descritor (por exemplo, nos nós de mídia/conteúdo apresentados pelo descritor)

player: identifica a ferramenta de apresentação a ser utilizada para exibir o objeto de mídia associado ao descritor. Esse atributo é opcional. Quando omitido, a máquina de apresentação procura pela ferramenta default em função do tipo do objeto de mídia.

explicitDur: define a duração ideal do objeto de mídia associado ao descritor. Na máquina de apresentação atual, o valor deste atributo só pode ser expresso em segundos, e deve estar no formato 9.9s (valor numérico seguido da letra “s”). Quando explicitDur não for especificado, o objeto que estiver associado ao descritor será exibido com sua duração default. Mídias como textos e imagens estáticas possuem duração default infinita.

region: identificador de uma região associada ao descritor. Ao utilizar o descritor o objeto será exibido na região correspondente. Esse atributo só precisa ser especificado para objetos que possuam um conteúdo visual a ser exibido.

(7)

A NCL define ainda o seguinte elemento contido num elemento de descritor:  descriptorParam: define parâmetros do descritor como pares <atributo, valor>. Os

atributos e seus respectivos valores dependem do programa de exibição da mídia associada ao descritor.

Cada descritor pode conter diversos elementos descriptorParam, definidos no formato:

<descriptorParam name="nome_do_parametro" value="valor_do_parametro" />

Por exemplo, um descritor pode definir um parâmetro adicional soundLevel, com o valor 1, para indicar que a mídia correspondente deve ser reproduzida com o volume máximo:

<descriptor id="dVideo1" region="rgVideo1"> <descriptorParam name="soundLevel" value="1" /> </descriptor>

O uso de parâmetros de descritor promove um alto grau de flexibilidade. Cabe ao programa de exibição do objeto de mídia interpretar esses atributos da forma adequada.

1.3.3 Portas

Uma porta (port) é um ponto de interface (interface point) de um contexto, que oferece acesso externo ao conteúdo de um contexto. Em outras palavras, para um elo apontar para um nó interno ao contexto, este contexto deve possuir uma porta que leve ao nó interno (Figura 1.3).

Figura 1.3. Porta pInicio como ponto de entrada a um nó interno de um contexto.

Observe que o elemento body de um documento NCL é um contexto que herda o id do próprio documento. Sendo assim, em todo documento, deve haver pelo menos uma porta de entrada (port na seção body) indicando qual é o nó de mídia ou contexto inicial. Uma porta pode ser definida da seguinte forma:

(8)

Observe que o atributo component dessa porta aponta para o nó de mídia video1. Isto significa que, ao iniciar o documento hipermídia, a máquina de apresentação seguirá a porta pInicio, que leva ao nó video1, que por sua vez será exibido.

Uma porta possui os seguintes atributos:

id: identificador único da porta, utilizado nas referências à porta (por exemplo, por elos)

component: nó de mídia ou contexto ao qual a porta se aplica.

interface: nome do ponto de interface (porta) de destino no contexto ou nome da âncora de destino no nó de mídia ou contexto. Caso component seja um contexto, pode-se definir ainda o atributo interface, apontando para uma porta ou âncora daquele contexto. Caso component seja um nó de mídia, pode-se definir o atributo interface apenas como sendo uma âncora do nó de mídia. Em ambos os casos, se o atributo interface for omitido, todo o nó será considerado como sendo a âncora de destino daquela porta.

1.3.4 Âncoras

As âncoras são pontos de entrada para os nós de mídia ou contextos. O objetivo de se utilizar âncoras é utilizar segmentos de um nó de mídia ou contexto, seja como origem ou destino de elos. Uma âncora pode ser do tipo âncora de conteúdo (content anchor) ou âncora de propriedade (property anchor). Uma âncora de conteúdo define um segmento da mídia (intervalo de tempo e/ou região no espaço) que poderá ser utilizado como ponto de ativação de elos. Cada nó de mídia é composto de unidades de informação (information units). A definição dessas unidades de informação depende do tipo de mídia representado pelo nó. As unidades de informação de um vídeo, por exemplo, podem ser os frames do vídeo. Uma âncora consiste numa seleção contígua de unidades de informação de um nó.

Uma âncora de conteúdo é definida como um elemento area dentro do elemento media. No exemplo abaixo, são definidas três âncoras de conteúdo para um nó de vídeo:

<media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"> <!-- âncoras de conteúdo no vídeo que devem ser sincronizadas com a legenda --> <area id="aVideoLegenda01" begin="5s" end="9s"/>

<area id="aVideoLegenda02" begin="10s" end="14s"/> <area id="aVideoLegenda03" begin="15s" end="19s"/> </media>

A NCL define os seguintes atributos de âncora de conteúdo:  id: identificador único da âncora

coords: coordenadas em pixels da âncora espacial âncora (atributo válido para mídias visuais).

begin e end: início e término e duração da âncora, em segundos, no formato “99.9s”

text: texto da âncora no arquivo de origem (atributo válido para mídias de texto) position: posição do texto da âncora no arquivo de origem (atributo válido para

(9)

first e last: quadro/amostra da mídia definindo o início e término da âncora (atributo válido para mídias contínuas)

label: identificador da âncora no arquivo de origem, tal como interpretado pela ferramenta de exibição.

Já as âncoras de propriedade se referem a atributos de um nó de origem ou de destino, que podem ser manipulados pelos elos. Exemplos de atributos são: volume de áudio de um nó de áudio ou vídeo, coordenadas e dimensões de exibição de um nó de mídia visual, entre outros. Uma âncora de propriedade é definida como um elemento property dentro do elemento media ou context. No exemplo a seguir são definidas quatro âncoras de propriedade para um nó de vídeo, além da âncora de conteúdo:

(10)

<media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"> <!-- âncoras de atributos que serão manipulados pelos elos -->

<property name="top"/> <property name="left"/> <property name="width"/> <property name="height"/>

<!-- âncora de conteúdo no vídeo que deve sincronizar a imagem --> <area id="aVideo1Imagem1" begin="3s" end="8s"/>

</media>

1.3.5 Contextos (ou nós de composição)

Contextos ou nós de composição são utilizados para estruturar um documento hipermídia. Os contextos podem ser aninhados, para refletir a estrutura do documento e ajudar o autor a organizar os segmentos do programa audiovisual interativo.

Um contexto é definido da seguinte forma:

<context id=" ncNome"> …

</context>

Os atributos mais comuns de um contexto são:  id: identificador único do contexto

refer: referência a um outro contexto previamente definido (utiliza os atributos (exceto o id) do contexto referenciado)

Vale lembrar que o elemento body é considerado um caso particular de contexto, representando o documento como um todo.

1.3.6 Nó de mídia (ou nó de conteúdo)

Um nó de mídia ou de conteúdo (media node ou content node) define o objeto de mídia propriamente dito: vídeo, áudio, texto etc. Cada definição de nó de mídia deve apresentar, além do arquivo de origem da mídia, o descritor que regulará a apresentação daquele objeto de mídia. No exemplo a seguir é definido um nó de mídia do tipo vídeo:

<media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"/>

Um nó de mídia possui os seguintes atributos:

id: identificador único do nó de mídia, utilizado nas referências ao nó (por exemplo, nas portas dos nós de contexto que levam à mídia)

type: tipo de mídia. Há diversos tipos de mídia MIME: video, audio, text (páginas HTML ou TXT), image ou img (imagens JPEG, PNG ou BMP), nclet (código Java de um NCLet), lua (arquivo com código Lua) e settings (nó de propriedades globais para ser usado em escolhas (switches)).

src: fonte do objeto de mídia. Trata-se do caminho relativo para o arquivo de mídia, a partir do diretório onde se encontra o arquivo NCL. O caminho também pode ser especificado de forma absoluta, através de uma URI.

descriptor: identificador do descritor que controla a apresentação do objeto de mídia

(11)

refer: referência a um outro nó de mídia previamente definido (utiliza os atributos (exceto o id) do nó de mídia referenciado)

1.3.7 Elos

Os elos (links) associam nós através de conectores (connectors), que definem a semântica da associação entre os nós. A NCL define os seguintes atributos de elos:

id: identificador único do elo

xconnector: identificador do conector associado ao elo

A NCL define os seguintes elementos contidos num elemento de elo:

linkParam: define parâmetros do elo como pares <atributo, valor>. Os atributos e seus respectivos valores dependem da definição do conector ao qual o elo está associado.

bind: indica os componentes (component, nós de mídia e de contexto) envolvidos no elo, indicando o papel (role) de cada nó no elo, conforme a semântica do conector. Em alguns casos deve-se indicar também o ponto de interface (interface) do nó ao qual o elo é ligado.

O elemento bind pode ainda conter uma ou mais instâncias do seguinte elemento como elementos filhos:

bindParam: define parâmetros específicos do bind como pares <atributo, valor>. Os atributos e seus respectivos valores dependem da definição do conector ao qual o elo está associado.

1.3.8 Conectores

No NCM, o sincronismo não é feito por marcas de tempo (timestamps), mas sim por mecanismos de causalidade e restrição definidos nos conectores (connectors). O conector define os papéis (roles) que os nós de origem e de destino exercem nos elos que utilizam o conector. A Figura 1.4 ilustra um conector ligando três nós.

(12)

Há dois tipos de conectores: causal (causal connector) e de restrição (constraint

connector). Para a TV Digital, a NCL usa apenas conectores causais, os quais definem

dois ou mais papéis, que indicam as condições de ativação do elo (simpleCondition e compoundCondition) e as ações a serem realizadas quando o elo for ativado (simpleAction

e compoundAction).

1.3.9 Eventos

A Figura 1.5 apresenta a máquina de estados de um evento (propositalmente em inglês para haver correspondência direta com NCL). Um evento pode estar em um dos seguintes estados: dormindo, preparando, preparado, ocorrendo, suspenso e abortado. Um evento é a exibição (evento de exibição) ou seleção (evento de seleção) de um conjunto não vazio de unidades de informação (segmento de mídia). Um evento também pode ser de atribuição, quando se dá a mudança de um atributo de um nó ou a de comportamento (definido no respectivo objeto descritor). O início ou fim de um evento é instantâneo (duração zero ou infinitesimal) e é denominado ponto de

sincronização. A transição de estados de um evento é comumente usada em NCL para

definir conectores.

Figura 1.5. Máquina de estados de eventos. 1.4. Desenvolvimento de Aplicações em NCL

A Tabela 1.1 apresenta a estrutura básica de um documento NCL. Todo documento NCL possui um cabeçalho de arquivo NCL (linhas 1 a 3), uma seção de cabeçalho do programa (seção head, linhas 4 a 14), o corpo do programa (seção body, linhas 15 a 18), e a conclusão do documento (linha 19). No corpo do programa é que são definidos os contextos, nós de mídia, elos e outros elementos que definem o conteúdo e a estrutura do programa.

Como ponto de entrada no documento, deve-se definir portas (porta pInicio, linha 16) , que determinam onde a apresentação do programa pode se iniciar. Ao exibir o documento, deve-se informar a porta por onde a exibição do documento se inicia (i.e., passar o identificador da porta como parâmetro para a máquina de apresentação). Caso uma porta não seja informada no momento de exibir o documento, nada será exibido como resultado de tocar aquele documento.

Tabela 1.1: Estrutura básica de um documento NCL.

cabeçalho do arquivo NCL 1: <?xml version="1.0" encoding="ISO-8859-1"?> 2: 3: <ncl id="exemplo01" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> cabeçalho do programa 4: <head> base de 5: <regionBase>

(13)

regiões 6: <!-- regiões da tela onde as mídias são apresentadas --> 7: </regionBase>

base de descritores

8: <descriptorBase>

9: <!-- descritores que definem como as mídias são apresentadas --> 10: </descriptorBase>

base de conectores

11: <connectorBase>

12: <!-- conectores que definem como os elos são ativados e o que eles disparam --> 13: </connectorBase> 14: </head> corpo do programa 15: <body> ponto de entrada no programa

16: <port id="pInicio" component="ncPrincipal" interface="iInicio"/>

conteúdo do programa

17: <!-- contextos, nós de mídia, elos e outros elementos -->

18: </body> término do

arquivo NCL

19: </ncl>

Geralmente, os passos para se construir um documento NCL são: 1. escrever o cabeçalho básico;

2. definir as regiões da tela onde aparecerão os elementos visuais (regionBase);

3. definir como e onde os nós de mídia serão exibidos, através de descritores (descriptorBase);

4. definir os conectores que especificam o comportamento dos elos do documento (connectorBase);

5. definir o conteúdo (nós de mídia) e a estrutura (contextos) do documento (seção body), associando-os aos descritores;

6. definir âncoras para os nós de mídia, visando à construção dos elos de/para nós de mídia;

7. definir portas para os contextos, visando à construção dos elos entre contextos e nós de mídia e incluindo a porta de entrada do programa, apontando para o primeiro nó a ser exibido; e

8. definir elos para o sincronismo e interatividade entre os nós de mídia e contextos.

1.4.1 Sincronizando um vídeo com um único arquivo de legenda, segmentado

Esta seção apresenta um documento NCL que reproduz um vídeo no centro da tela e sincroniza uma legenda com o vídeo. A legenda é composta de um único arquivo HTML, contendo três elementos DIV, cada qual com um texto a ser sincronizado com o vídeo.

Para reproduzir um vídeo, é necessário criar os seguintes elementos (indicados na Listagem 1.1):

 as regiões da tela onde o vídeo e a legenda serão exibidos (regiões rgVideo1 e

(14)

 a associação das mídias com as regiões e a forma como serão exibidas (descritores dVideo1 e dLegenda, linhas 45 e 46);

 a(s) porta(s) que define(m) o ponto de entrada do documento hipermídia (porta

pInicio, linha 73), que aponta para o primeiro elemento de mídia, video1;

 os nós de mídia do vídeo e das legendas (linhas 80 a 89).

Os três nós de legenda se referenciam ao mesmo arquivo HTML, assim sua fonte (atributo src) ficará no formato nome_do_arquivo#id_do_div, como em

legendas.html#legenda01 (linhas 87 a 89).

Para definir os pontos do vídeo em que a legenda deve aparecer, é necessário criar âncoras para o vídeo, cada qual definindo o intervalo de exibição da legenda correspondente. Em seguida, basta criar três elos, cada qual para iniciar e terminar a exibição de cada legenda. A origem de cada elo deve ser uma das âncoras do vídeo, e o destino a legenda correspondente.

A listagem a seguir apresenta o código necessário para reproduzir o vídeo com a legenda sincronizada.

É importante reparar que todo elemento da NCL (região, descritor, nó de mídia, porta etc.) deve possuir um identificador único, representado pelo atributo id. Os demais atributos serão descritos nas seções seguintes, que aprofundam a definição de cada elemento utilizado no exemplo.

Listagem 1.1: Documento NCL para reprodução de um vídeo com três trechos de legenda sincronizados, num único arquivo1.

1: <?xml version="1.0" encoding="ISSO-8859-1"?>

2: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3: EXEMPLO 01

4:

5: Objetivo: Reproduzir um vídeo numa região da tela, sincronizando com trechos 20: de legenda.

6:

7: Características: 8:

9: - sincronismo: simples (de início e término de mídias) 10: - interação do usuário: nenhuma

11: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 12:

13: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 14: ! CABEÇALHO NCL:

15: ! define as URIs dos esquemas da NCL

16: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 17: 18: <ncl id="exemplo01" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> 19: 20: 21: 22: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 23: ! CABEÇALHO DO PROGRAMA 24: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 25: 26: <head> 27: 28: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 Para executar este exemplo, é necessário que haja, no subdiretório media sob o diretório onde o arquivo

NCL estiver localizado, as seguintes mídias: um vídeo chamado video1.mpg; e um arquivo HTML chamados legendas.html, contendo três elementos DIV identificados por legenda01, legenda02 e legenda03, cada qual com um texto a ser sincronizado.

(15)

29: ! BASE DE REGIÕES:

30: ! define as regiões na tela onde as mídias são apresentadas

31: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 32:

33: <regionBase>

34: <region id="rgVideo1" left="200" top="168" width="320" height="240" zIndex="1"/> 35: <region id="rgLegenda" left="200" top="450" width="240" height="50" zIndex="1" /> 36: </regionBase>

37:

38: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 39: ! BASE DE DESCRITORES:

40: ! define como as mídias são apresentadas

41: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 42:

43: <descriptorBase> 44:

45: <descriptor id="dVideo1" region="rgVideo1" /> 46: <descriptor id="dLegenda" region="rgLegenda"/> 47:

48: </descriptorBase> 49:

50: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 51: ! BASE DE CONECTORES:

52: ! definem o comportamento dos elos

53: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 54:

55: <connectorBase>

56: <importBase alias="connectors" baseURI="connectorBase.ncl"/> 57: </connectorBase> 58: 59: </head> 60: 61: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 62: ! CORPO DO PROGRAMA:

63: ! define as mídias e estrutura do programa

64: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 65: 66: <body> 67: 68: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 69: ! PONTO DE ENTRADA:

70: ! indica o componente onde o programa inicia

71: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 72:

73: <port id="pInicio" component="video1" /> 74:

75: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 76: ! MÍDIAS:

77: ! define o local dos arquivos de mídia e as associa com seus descritores

78: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 79:

80: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"> 81: <!-- âncoras no vídeo que devem ser sincronizadas com a legenda -->

82: <area id="aVideoLegenda01" begin="5s" end="9s"/> 83: <area id="aVideoLegenda02" begin="10s" end="14s"/> 84: <area id="aVideoLegenda03" begin="15s" end="19s"/> 85: </media>

86:

87: <media type="text/html" id="legenda01" src="media/legendas.html#legenda01" descriptor="dLegenda" /> 88: <media type="text/html" id="legenda02" src="media/legendas.html#legenda02" descriptor="dLegenda" /> 89: <media type="text/html" id="legenda03" src="media/legendas.html#legenda03" descriptor="dLegenda" /> 90:

91: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 92: ! ELOS

93: ! define os elos que regem o sincronismo entre as mídias

94: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 95:

96: <!-- início da legenda 01 -->

97: <link id="lLegenda01_start" xconnector="connectors#onBegin1StartN"> 98: <bind component="video1" interface="aVideoLegenda01" role="onBegin" /> 99: <bind component="legenda01" role="start" />

(16)

101:

102: <!-- término da legenda 01 -->

103: <link id="lLegenda01_stop" xconnector="connectors#onEnd1StopN"> 104: <bind component="video1" interface="aVideoLegenda01" role="onEnd" /> 105: <bind component="legenda01" role="stop" />

106: </link> 107:

108: <!-- início da legenda 02 -->

109: <link id="lLegenda02_start" xconnector="connectors#onBegin1StartN"> 110: <bind component="video1" interface="aVideoLegenda02" role="onBegin" /> 111: <bind component="legenda02" role="start" />

112: </link> 113:

114: <!-- término da legenda 02 -->

115: <link id="lLegenda02_stop" xconnector="connectors#onEnd1StopN"> 116: <bind component="video1" interface="aVideoLegenda02" role="onEnd" /> 117: <bind component="legenda02" role="stop" />

118: </link> 119:

120: <!-- início da legenda 03 -->

121: <link id="lLegenda03_start" xconnector="connectors#onBegin1StartN"> 122: <bind component="video1" interface="aVideoLegenda03" role="onBegin" /> 123: <bind component="legenda03" role="start" />

124: </link> 125:

126: <!-- término da legenda 03 -->

127: <link id="lLegenda03_stop" xconnector="connectors#onEnd1StopN"> 128: <bind component="video1" interface="aVideoLegenda03" role="onEnd" /> 129: <bind component="legenda03" role="stop" />

130: </link> 131: </body> 132: </ncl>

(17)

Figura 1.6. Visões temporal e espacial do Exemplo 1, que reproduz um vídeo sincronizando uma legenda.

As seguintes tabelas descrevem os conectores onBegin1StartN e onEnd1StopN utilizados no Exemplo 1:

Tabela 1.2: Conector onBegin1StartN.

Nome: onBegin1StartN Tipo: Causal

Condição: início de exibição de um nó de mídia (definido no papel onBegin)

Ação: dispara o início de exibição de um ou mais nós de mídia (definidos no papel start) Código: <causalConnector id="onBegin1StartN">

<simpleCondition role="onBegin"/>

<simpleAction role="start" max="unbounded"/> </causalConnector>

Tabela 1.3: Conector onEndStop.

Nome: onEnd1StopN Tipo: Causal

Condição: término de exibição de um nó de mídia (definido no papel onEnd) Ação: encerra a exibição de um ou mais nós de mídia (definidos no papel stop) Código: <causalConnector id="onEnd1StopN">

<simpleCondition role="onEnd"/>

<simpleAction role="stop" max="unbounded"/> </causalConnector>

(18)

1.4.2 Redimensionando uma região de vídeo durante a exibição de uma imagem

Esta seção apresenta um documento NCL que reproduz um vídeo em tela inteira (720 x 576 px) e que, num determinado momento, é redimensionado para dar lugar a uma imagem na parte inferior da tela. A listagem a seguir apresenta o código necessário para redimensionar o vídeo quando uma imagem aparecer, a 3 segundos do início do vídeo, e para restaurar o tamanho original, a 8 segundos do vídeo.

Para manipular os atributos top, left, width e height da região à qual o vídeo está associado, é necessário definir explicitamente esses atributos como atributos da mídia, ou então especificar o atributo bounds para manipular os atributos em conjunto (linha 54). A manipulação é feita através dos elos Video1Imagem1_start e

Video1Imagem1_stop (linhas 61 a 78). Os conectores onBegin1Resize1StartNStopN e onEnd1Resize1StartNStopN serão vistos no final desta seção.

Listagem 1.2: Documento NCL para redimensionamento de um vídeo enquanto uma imagem está sendo exibida2.

1: <?xml version="1.0" encoding="ISO-8859-1"?> 2:

3: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4: EXEMPLO 02

5:

6: Objetivo: Reproduzir um vídeo numa região da tela e redimensioná-lo num momento 7: de sincronização com uma imagem

8:

9: Características: 10:

11: - sincronismo: simples (de início e término de uma mídia) 12: - interação do usuário: nenhuma

13: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 14: 15: <!-- CABEÇALHO NCL --> 16: 17: <ncl id="exemplo02" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> 18: 19: <!-- CABEÇALHO DO PROGRAMA --> 20: <head> 21: 22: <!-- BASE DE REGIÕES --> 23: <regionBase>

24: <region id="rgVideo1" left="200" top="168" width="320" height="240" zIndex="1"/> 25: <region id="rgImagem1" left="200" top="190" width="504" height="377" zIndex="1" /> 26: </regionBase>

27:

28: <!-- BASE DE DESCRITORES --> 29: <descriptorBase>

30: <descriptor id="dVideo1" region="rgVideo1"> 31: <descriptorParam name="soundLevel" value="1" /> 32: </descriptor>

33: <descriptor id="dImagem1" region="rgImagem1" /> 34: </descriptorBase>

35:

36: <!-- BASE DE CONECTORES --> 37: <connectorBase>

38: <importBase alias="connectors" baseURI="connectorBase.ncl"/> 39: </connectorBase> 40: 41: </head> 42: 43: <!-- CORPO DO PROGRAMA -->

2 Para executar este exemplo, é necessário que haja, no subdiretório media sob o diretório onde o arquivo

NCL estiver localizado, as seguintes mídias: um vídeo chamado video1.mpg; e uma imagem chamada imagem1.png.

(19)

44: <body> 45:

46: <!-- PONTO DE ENTRADA -->

47: <port id="pInicio" component="video1" /> 48:

49: <!-- MÍDIAS -->

50: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"> 51: <!-- âncora no vídeo que deve sincronizar a imagem -->

52: <area id="aVideo1Imagem1" begin="3s" end="8s"/> 53: <!-- atributo que será manipulado pelos elos --> 54: <property name="bounds" />

55: </media> 56:

57: <media type="image/png" id="imagem1" src="media/imagem1.png" descriptor="dImagem1" /> 58:

59: <!-- ELOS --> 60:

61: <!-- âncora do vídeo 1 deve iniciar a exibição da imagem -->

62: <link id="Video1Imagem1_start" xconnector="connectors#onBegin1Resize1StartNStopN"> 63: <bind component="video1" interface="aVideo1Imagem1" role="onBegin" />

64: <bind component="video1" interface="bounds" role="setBounds"> 65: <bindParam name="bounds" value="200,18,160,120" /> 66: <!-- As dimensões de bounds são: left, top, width, height --> 67: </bind>

68: <bind component="imagem1" role="start" /> 69: </link>

70:

71: <!-- âncora do vídeo 1 deve terminar a exibição da imagem -->

72: <link id="Video1Imagem1_stop" xconnector="connectors#onEnd1Resize1StartNStopN"> 73: <bind component="video1" interface="aVideo1Imagem1" role="onEnd" />

74: <bind component="video1" interface="bounds" role="setBounds"> 75: <bindParam name="bounds" value="200,168,320,240" /> 76: </bind>

77: <bind component="imagem1" role="stop" /> 78: </link>

79:

80: </body> 81: </ncl>

(20)

Figura 1.7: Visões temporal e espacial do documento que redimensiona um vídeo sincronizado a uma imagem.

A tabela a seguir descreve o conector onBegin1Resize1StartNStopN. Tabela 1.4: Conector onBegin1Resize1StartNStopN.

Nome: onBegin1Resize1StartNStopN

Tipo: Causal

Condição: início de exibição da mídia no papel onBegin

Ação:  altera as coordenadas e dimensões da mídia do nó de destino, conforme os parâmetros passados pelo elo (linkParam ou bindParam) para a variável do conector (connectorParam) denominada bounds, utilizada pelo papel setBounds;

pode exibir mídias no papel start; e pode ocultar mídias no papel stop.

Observação: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional do elo (linkParam) ou do bind (bindParam), as novas coordenadas e dimensões (x,y,w,h). Por exemplo:

<linkParam name="bounds" value="200,18,160,120" /> Código: <causalConnector id="onBegin1Resize1StartNStopN">

<connectorParam name="bounds"/> <simpleCondition role="onBegin"/> <compoundAction operator="seq">

<simpleAction role="set" value="$bounds"/> <simpleAction role="start" max="unbounded"/> <simpleAction role="stop" max="unbounded"/> </compoundAction>

</causalConnector>

O conector onEnd1Resize1StartNStopN é análogo ao anterior, mas substitui a condição “onBegin” por:

<simpleCondition role="onEnd"/>

1.4.3 Alternando imagens para identificar ações disponíveis

O objetivo deste exemplo é permitir ao usuário alternar entre dois vídeos, através da seleção das teclas vermelha e verde do controle remoto da TV Digital. Ambos os vídeos

(21)

devem ser apresentados na mesma posição da tela e devem ser iniciados de forma sincronizada, sendo que um deles deve iniciar invisível e sem som. Quando o usuário fizer uma seleção com os botões do controle remoto, os atributos de visibilidade e volume de áudio dos dois vídeos devem ser invertidos.

Como as duas mídias tocarão ao mesmo tempo, mas com parâmetros de visibilidade e som distintos, um novo descritor para o segundo vídeo (video2, linha 64) é criado (dVideo2, linha 37) reusando a mesma região do video1 mas com os valores dos atributos correspondentes definidos no seu descritor (linhas 38 e 39) para que não haja som nem exibição no início.

Para que seja possível alterar os atributos visible e soundLevel, é necessário que esses atributos estejam definidos explicitamente no nó de mídia correspondente (linhas 60-61 e 65-66).

Finalmente, é necessário criar dois elos para efetuar a seleção do vídeo, através do conector onSelectionToggleVideo (linhas 89 a 109). Como será visto adiante, esse conector troca o vídeo sendo exibido, conforme o botão selecionado: o botão vermelho ativa o video1 e o botão verde ativa o video2. Observa-se que, como o elo deve alterar algumas propriedades dos nós de vídeo, cada elemento de ligação (bind) deve especificar não apenas o componente de destino do elo (atributo component), mas também a sua propriedade (atributo interface), tal como definido no nó da mídia:

<bind component="video1" interface="aVideo1Visible" role="setVisibilityOn"/>

A princípio, as imagens dos botões vermelho e verde ficariam o tempo todo visíveis, mas somente um dos botões causa efeito ao ser pressionado. Como isto pode causar problemas de usabilidade, será modificada a visibilidade das imagens correspondentes aos botões sempre que uma seleção for feita, de modo que apenas o botão que possa causar uma mudança do vídeo seja exibido.

Em primeiro lugar, o elo de exibição inicial do vídeo e dos botões não deve exibir o botão verde, pois pressionar a tecla verde enquanto o vídeo 1 está tocando não produz efeito. Além disto, é preciso incluir dois elos, que alternam a exibição das imagens correspondentes aos botões (linhas 111 a 127). Esses elos utilizam o conector onSelection1StartNStopN, especificado para modificar a visibilidade de um ou mais nós de mídia conforme o pressionamento de uma determinada tecla. A Listagem 1.3 apresenta o código deste exemplo.

Listagem 1.3: Documento NCL com elos para alternar a exibição de imagens e vídeos através da interação do usuário3.

1: <?xml version="1.0" encoding="ISO-8859-1"?> 2:

3: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4: EXEMPLO 03

5:

6: Objetivo: Reproduzir um vídeo e permitir que o usuário alterne entre dois vídeos, 7: numa mesma região da tela, através do pressionamento das teclas 8: vermelha e verde do controle remoto. Oculta a imagem correspondente ao 9: botão que não fizer efeito no momento.

10:

3 Para executar este exemplo, é necessário que haja, no subdiretório media, sob o diretório onde o arquivo

NCL estiver localizado, as seguintes mídias: dois arquivos de vídeo, chamados video1.mpg e video2.mpg; e duas imagens, chamadas botao_vermelho.png e botao_verde.png, representando os botões vermelho e verde, respectivamente.

(22)

11: Características: 12:

13: - sincronismo: ponto de alternância entre os vídeos 14: - interação do usuário: seleção do vídeo a ser exibido 15: 16: !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> 17: 18: <!-- CABEÇALHO NCL --> 19: 20: <ncl id="exemplo03" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> 21: 22: 23: 24: <!-- CABEÇALHO DO PROGRAMA --> 25: <head> 26: 27: <!-- BASE DE REGIÕES --> 28: <regionBase>

29: <region id="rgVideo1" left="200" top="168" width="320" height="240" /> 30: <region id="rgBotaoVermelho" left="200" top="420" width="25" height="25" /> 31: <region id="rgBotaoVerde" left="200" top="470" width="25" height="25" /> 32: </regionBase>

33:

34: <!-- BASE DE DESCRITORES --> 35: <descriptorBase>

36: <descriptor id="dVideo1" region="rgVideo1" /> 37: <descriptor id="dVideo2" region="rgVideo1"> 38: <descriptorParam name="visible" value="false" /> 39: <descriptorParam name="soundLevel" value="0"/> 40: </descriptor>

41: <descriptor id="dBotaoVermelho" region="rgBotaoVermelho" /> 42: <descriptor id="dBotaoVerde" region="rgBotaoVerde" /> 43: </descriptorBase>

44:

45: <!-- BASE DE CONECTORES --> 46: <connectorBase>

47: <importBase alias="connectors" baseURI="connectorBase.ncl"/> 48: </connectorBase> 49: 50: </head> 51: 52: <!-- CORPO DO PROGRAMA --> 53: <body> 54: 55: <!-- PONTO DE ENTRADA -->

56: <port id="pInicio" component="video1" /> 57:

58: <!-- MÍDIAS -->

59: <media type="video/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"> 60: <attribute id="aVideo1Visible" name="visible" />

61: <attribute id="aVideo1SoundLevel" name="soundLevel" /> 62: </media>

63:

64: <media type="video/mpeg" id="video2" src="media/video2.mpg" descriptor="dVideo2"> 65: <attribute id="aVideo2Visible" name="visible" />

66: <attribute id="aVideo2SoundLevel" name="soundLevel" /> 67: </media>

68:

69: <media type="image/png" id="botaoVermelho" src="media/botao_vermelho.png" descriptor="dBotaoVermelho"/>

70: <media type="image/png" id="botaoVerde" src="media/botao_verde.png" descriptor="dBotaoVerde" /> 71:

72: <!-- ELOS --> 73:

74: <!-- início do video1 deve disparar a exibição do video2 e das imagens dos botões --> 75: <link id="lVideo_Botoes_start" xconnector="connectors#onBegin1StartN">

76: <bind component="video1" role="onBegin" /> 77: <bind component="video2" role="start" /> 78: <bind component="botaoVermelho" role="start" /> 79: </link>

80:

(23)

82: <link id="lVideo_Botoes_stop" xconnector="connectors#onEnd1StopN"> 83: <bind component="video1" role="onEnd" />

84: <bind component="video2" role="stop" /> 85: <bind component="botaoVerde" role="stop" /> 86: <bind component="botaoVermelho" role="stop" /> 87: </link>

88:

89: <!-- alterna para vídeo 2 caso a tecla vermelha seja acionada -->

90: <link id="lSelecionaVideo2" xconnector="connectors#onSelection1ToggleVideo"> 91: <bind component="botaoVermelho" role="onSelection">

92: <bindParam name="keyCode" value="RED"/> 93: </bind>

94: <bind component="video1" interface="aVideo1Visible" role="setVisibilityOff"/> 95: <bind component="video1" interface="aVideo1SoundLevel" role="setSoundLevelOff"/> 96: <bind component="video2" interface="aVideo2Visible" role="setVisibilityOn"/> 97: <bind component="video2" interface="aVideo2SoundLevel" role="setSoundLevelOn"/> 98: </link>

99:

100: <!-- alterna para vídeo 1 caso a tecla verde seja acionada -->

101: <link id="lSelecionaVideo1" xconnector="connectors#onSelection1ToggleVideo"> 102: <bind component="botaoVerde" role="onSelection">

103: <bindParam name="keyCode" value="GREEN"/> 104: </bind>

105: <bind component="video1" interface="aVideo1Visible" role="setVisibilityOn"/> 106: <bind component="video1" interface="aVideo1SoundLevel" role="setSoundLevelOn"/> 107: <bind component="video2" interface="aVideo2Visible" role="setVisibilityOff"/> 108: <bind component="video2" interface="aVideo2SoundLevel" role="setSoundLevelOff"/> 109: </link>

110:

111: <!-- oculta a tecla vermelha quando ela é pressionada -->

112: <link id="lToggleBotaoVermelho" xconnector="connectors#onSelection1StartNStopN"> 113: <bind component="botaoVermelho" role="onSelection">

114: <bindParam name="keyCode" value="RED" /> 115: </bind>

116: <bind component="botaoVerde" role="start" /> 117: <bind component="botaoVermelho" role="stop" /> 118: </link>

119:

120: <!-- oculta a tecla verde quando ela é pressionada -->

121: <link id="lToggleBotaoVerde" xconnector="connectors#onSelection1StartNStopN"> 122: <bind component="botaoVerde" role="onSelection">

123: <bindParam name="keyCode" value="GREEN" /> 124: </bind>

125: <bind component="botaoVerde" role="stop" /> 126: <bind component="botaoVermelho" role="start" /> 127: </link>

128: </body> 129: </ncl>

(24)

Figura 1.8: Visões temporal e espacial do Exemplo 3, com sincronismo (conectores onBegin1StartN e onEnd1StopN) e interação (conectores

onSelection1ToggleVideo e onSelection1StartNStopN).

A tabela a seguir descreve o conector onSelection1ToggleVideo. Observa-se que esse conector exige que o elo correspondente defina um parâmetro, do tipo connectorParam, para preencher o valor do atributo keyCode, definido no elemento conditionRole.

Tabela 1.5: Conector onSelection1ToggleVideo.

Nome: onSelection1ToggleVideo

Tipo: Causal

Condição: tecla <keyCode> acionada (papel onSelection)

Ação: torna visível a mídia identificada no papel setVisibilityOn; torna invisível a mídia identificada no papel setVisibilityOff;

estabelece o volume máximo para a mídia identificada no papel setVolumeOn; e estabelece o volume mínimo (mute, ou sem som) para a mídia identificada no papel

setVolumeOff

Observações: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional da ligação com o nó de origem (linkParam ou bindParam), o código virtual da tecla do controle remoto associada à seleção. Por exemplo:

(25)

Código: <causalConnector id="onSelection1ToggleVideo"> <connectorParam name="keyCode" type="xsi:string"/> <simpleCondition role="onSelection" key=”$keyCode”/> <compoundAction operator="seq">

<simpleAction role="setVisibilityOn" eventType="attribution" actionType="start" value="true"/>

<simpleAction role="setSoundLevelOn" eventType="attribution" actionType="start" value="1"/>

<simpleAction role="setVisibilityOff" eventType="attribution" actionType="start" value="false"/>

<simpleAction role="setSoundLevelOff" eventType="attribution" actionType="start" value="0"/>

</compoundAction> </causalConnector>

A tabela a seguir descreve o conector onSelection1StartNStopN. Observa-se que

esse conector exige que o elo correspondente defina um parâmetro do tipo bindParam ou linkParam, para preencher o valor do atributo keyCode, definido no elemento conditionRole.

Tabela 1.6: Conector onSelection1StartNStopN.

Nome: onSelection1StartNStopN Tipo: Causal

Condição: tecla <keyCode> acionada (papel onSelection) Ação:  exibe as mídias identificadas pelo papel start;

oculta as mídias identificadas pelo papel stop

Observação: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional da ligação com o nó de origem (bindParam ou linkParam), o código virtual da tecla do controle remoto associada à seleção. Por exemplo:

<bindParam name="keyCode" value="VK_ENTER" /> Código: <causalConnector id="onSelection1StartNStopN">

<connectorParam name="keyCode" type="xsi:string" /> <simpleCondition role="onSelection" key=”$keyCode”/> <compoundAction operator="seq">

<simpleAction role="start" max="unbounded"/> <simpleAction role="stop" max="unbounded"/> </causalConnector>

1.4.4 Simulação de um menu de DVD com feedback

O objetivo deste exemplo é exibir um vídeo em loop, exibindo ao mesmo tempo duas opções de idioma. Ao selecionar uma das opções (pressionando a tecla verde ou vermelha do controle remoto da TV Digital), é exibido um vídeo de abertura (independente do idioma selecionado) e, em seguida, um vídeo sem som e um áudio de acordo com o idioma escolhido. Todos os vídeos devem ser apresentados na mesma posição da tela.

Para armazenar a opção selecionada, será utilizado um nó do tipo settings com um atributo idioma (linhas 61 a 63). Já para selecionar o nó de áudio a ser reproduzido ao final do video2, são definidas rules (regras, linhas 41 a 45) e um switch (linhas 76 a 87).

Quando o botão vermelho ou o verde é selecionado, o idioma correspondente é armazenado no atributo idioma, através do conector OnSelection1SetStartStopDelay (linhas 118 a 144). Este mesmo conector é o responsável por interromper o video1 e iniciar a exibição do video2. Quando o video2 termina, o elo lVideo2StartVideo3, através do conector OnEnd1StartN, ativa o nó de contexto contextoFilme (linhas 146 a 150). A porta desse contexto ativa o video3 (linha 72), que por sua vez dispara, sincronamente, através do conector onBegin1StartN (linhas 89 a 93), o switch switchAudioIdioma (linhas 76 a 87). Este switch é regido pelas regras rEn e rPt (linhas 82 e 83), definidas

(26)

previamente na seção ruleBase (linhas 41 a 45). Nota-se que foi criado um segundo descritor para o video3 (linhas 33 a 35), pois ele deve ser exibido sem som (soundLevel=0).

Como boa prática de projeto de programa audiovisual interativo, deve-se fornecer um feedback para toda ação do usuário. Ao selecionar um idioma, por exemplo, o usuário precisa receber um feedback imediato sobre qual opção foi selecionada. Caso contrário, ele precisaria esperar o início da reprodução do áudio, após o video2, para saber se fez a seleção correta. Uma forma de se fazer isso é ocultar momentaneamente as opções que não foram selecionadas, deixando apenas a seleção do usuário visível, mesmo que por uma fração de segundo. Para atingir esse efeito, pode-se definir um atributo delay no mapeamento de ativação do conector. A Tabela 1.7 apresenta o conector OnSelection1SetStartStopDelay, para acomodar não apenas o disparo imediato de eventos, mas também um disparo retardado por meio segundo:

Tabela 1.7: Definição do conector onSelection1SetStartStop, para introduzir papéis de ativação com retardo.

Nome: onSelection1SetStartStopDelay

Tipo: Causal

Condição: tecla <keyCode> acionada (papel onSelection) Ação: exibe as mídias identificadas pelo papel start;

pára as mídias identificadas pelo papel stop; aborta as mídias identificadas pelo papel abort;

define o valor <valueSet> ao atributo mapeado através do papel set; exibe, após um retardo de 0,5s, as mídias identificadas pelo papel dstart; pára, após um retardo de 0,5s, as mídias identificadas pelo papel dstop; e aborta, após um retardo de 0,5s, as mídias identificadas pelo papel dabort.

Observação: Os elos que utilizarem este conector deverão identificar, como parâmetros adicionais da ligação com o nó de origem (bindParam ou linkParam), o código virtual da tecla do controle remoto associada à seleção e o valor a ser atribuído. Por exemplo:

<bindParam name="keyCode" value="GREEN" /> <bindParam name="valueSet" value="en" />

Código: <causalConnector id="onSelection1SetStartStopDelay"> <connectorParam name="keyCode"/>

<connectorParam name="valueSet"/> <connectorParam name="delay"/>

<simpleCondition role="onSelection" key="$keyCode"/> <compoundAction operator="seq">

<simpleAction role="set" value="$valueSet"/> <simpleAction role="start" delay="$delay"/> <simpleAction role="stop" delay="$delay"/> </compoundAction>

</causalConnector>

Fazendo uso desse conector, pode-se ocultar imediatamente a opção não selecionada e, após meio segundo, oculta-se a opção selecionada e substituir o video1 pelo video2. A Listagem 1.4 apresenta o código NCL desse exemplo.

Listagem 1.4: Documento NCL para exibir um vídeo em loop e, mediante a seleção do usuário, substituí-lo por um segundo vídeo e, finalmente, exibir um terceiro vídeo e um áudio conforme a seleção de idioma, fornecendo feedback momentâneo.

1: <?xml version="1.0" encoding="ISO-8859-1"?> 2:

3: <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4: EXEMPLO 04

5:

6: Objetivo: Reproduzir um vídeo e permitir que o usuário selecione 7: 1) o idioma do áudio, através do pressionamento das teclas 8: 2) vermelha e verde do controle remoto.

9:

Referências

Documentos relacionados

Mova a alavanca de acionamento para frente para elevação e depois para traz para descida do garfo certificando se o mesmo encontrasse normal.. Depois desta inspeção, se não

2.Disponibilização de recursos do OGU e linhas de financiamento simplificadas para o poder público, setor privado e terceiro setor em condições

A menor proporção de uso do SUS para exames preventivos e de diagnóstico precoce, em especial os cânceres de mama e próstata, sugere baixa cobertura populacional que pode

O valor da reputação dos pseudônimos é igual a 0,8 devido aos fal- sos positivos do mecanismo auxiliar, que acabam por fazer com que a reputação mesmo dos usuários que enviam

Outros fatores que contribuíram para o avanço tecnológico das máquinas elétricas foram: o desenvolvimento de materiais, como os ímãs de ferrita e os de

Em primeiro lugar, como a pecuária é menos intensiva em capital que a agricultura, mais produtores irão escolher a pecuária quando os preços da terra estiverem baixos em

Nestes dados, obviamente estão incluídas situações de urgência colectiva, com envolvimento de alguns tipos de produtos, designadamente químicos e biológicos; no

Essa dimensão é composta pelos conceitos que permitem refletir sobre a origem e a dinâmica de transformação nas representações e práticas sociais que se relacionam com as