Sincronismo entre Fluxos de Mídia Contínua e Aplicações Multimídia em Redes por Difusão

Transcrição

1 Sincronismo entre Fluxos de Mídia Contínua e Aplicações Multimídia em Redes por Difusão Marcio Ferreira Moreno Romualdo Monteiro de Resende Costa Luiz Fernando Gomes Soares Departamento de Informática PUC-Rio Rua Marquês de São Vicente, 225 Rio de Janeiro/RJ Brasil {mfmoreno, romualdo, lfgs}@inf.puc-rio.br ABSTRACT This paper aims to discuss how timebases can be handled by application managers in order to support intermedia synchronization in digital TV applications, including interactive and adaptive applications. The presented models and concepts are discussed based on the reference implementation of Ginga-NCL, the standard declarative middleware of the Brazilian Terrestrial Digital TV System (SBTVD-T). RESUMO Este artigo tem por objetivo discutir como as bases temporais podem ser manipuladas pelos gerenciadores de aplicações de TV digital, incluindo as aplicações interativas e adaptativas, de forma a preservar o sincronismo intermídia entre os objetos dessas aplicações. Os modelos e conceitos propostos são discutidos com base na implementação de referência do middleware declarativo Ginga-NCL, padrão do Sistema Brasileiro de TV Digital Terrestre (SBTVD-T). Categories and Subject Descriptors I.7.2 [Document Preparation]: Languages and systems, Hypertext/hypermedia, Markup languages, Standards. General Terms Algorithm, Design, Standardization, Languages. Keywords Multimedia Synchronism, Declarative Middleware, Ginga-NCL, Interactive DTV, NCL, SBTVD-T. 1. INTRODUÇÃO Um documento (aplicação) multimídia/hipermídia pode conter objetos de mídia de diferentes tipos, como texto, imagem, vídeo, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WebMedia 08, October 26-29, 2008, Vila Velha, ES, Brazil. Copyright 2008 ACM /00/0004 $5.00. áudio etc. Em comum, esses objetos devem obedecer às relações de sincronismo especificadas pelo autor, tanto em relação ao tempo de exibição, quanto ao espaço de exibição nos dispositivos utilizados para apresentação. A especificação do sincronismo entre os diferentes objetos de mídia, usualmente denominado sincronismo intermídia, pode ser realizada em relação a intervalos temporais absolutos de um eixo temporal [1]. Porém, essa abordagem só é adequada quando os instantes temporais do sincronismo entre as mídias são deterministicamente conhecidos em tempo de especificação da aplicação. Esse é o caso, por exemplo, do sincronismo entre o áudio e o vídeo que compõem o conteúdo audiovisual de um fluxo MPEG-2 (MPEG-2 Transport Stream [1]). Nas aplicações onde o sincronismo depende da ocorrência de eventos 1 com duração variável ou mesmo imprevisível no momento da especificação, é imperativo que essa especificação seja realizada de forma relativa à ocorrência desses eventos, independente do momento temporal em que eles ocorrem e se de fato eles irão ocorrer. Esse é o caso, por exemplo, das aplicações interativas, onde é impossível prever o momento exato da interação do usuário. Quando o sincronismo é especificado de forma relativa, os instantes temporais de ocorrência dos eventos somente serão conhecidos na fase de execução da aplicação. Durante a execução das aplicações, os exibidores devem reportar todos os eventos, incluindo os não determinísticos, para que outros eventos relacionados possam ser disparados. O tempo de exibição (media time) individual de cada objeto de mídia deverá ser controlado, uma vez que os eventos podem estar associados a trechos específicos de seu conteúdo. Esses trechos (âncoras) podem ser definidos sobre intervalos temporais dos objetos. Como exemplo, uma aplicação pode especificar que quando o usuário interagir em um momento temporal específico da exibição de um filme (âncora temporal), uma propaganda, consistindo em outro vídeo, seja exibida. Para os conteúdos de mídia que estejam previamente disponíveis junto aos exibidores, o controle do tempo de exibição pode ser realizado simplesmente verificando o tempo transcorrido a partir 1 Neste artigo um evento corresponde a qualquer ocorrência no tempo instantânea, como o clique em um botão do controle remoto, ou com uma duração, como a apresentação de um objeto de vídeo.

2 do início de sua exibição. Além disso, estando os conteúdos previamente disponíveis, seu tempo total de duração (total media time) pode ser trivialmente calculado. Ao contrário, para conteúdos entregues em tempo de exibição através de fluxos contínuos (streaming), determinar o instante inicial do conteúdo, ou seu tempo total de exibição, exige que o receptor esteja sintonizado desde o início do fluxo, ou então, que mecanismos adicionais sejam disponibilizados. Referências temporais absolutas, que vão de zero ao infinito (valor muito grande), correspondendo, respectivamente, ao tempo inicial e final de um fluxo de mídia contínua, são usualmente multiplexadas ao fluxo. Como exemplo, podem ser citados o Presentation Time Stamps PTS [1] e o Presentation Clock Reference PCR [1] definidos no padrão MPEG-2 sistemas [1] 2. No entanto, esse tipo de referência temporal não é suficiente como mecanismo adicional mencionado no parágrafo anterior. A razão é que um conteúdo já codificado pode ser editado, causando descontinuidade nas referências temporais. Mais ainda, ao longo do tempo, um mesmo fluxo pode conter inúmeros conteúdos distintos, muitas vezes até entrelaçados. Ou seja, o conteúdo do fluxo contínuo pode estar semanticamente relacionado a objetos de mídia diferentes com o passar do tempo. Como exemplo, pode ser citado o fluxo de um canal de uma emissora qualquer em um sistema de TV digital por difusão terrestre. Durante o transcorrer da programação, diferentes conteúdos, que correspondem a diferentes programas da emissora, são transmitidos sem interrupção do fluxo audiovisual principal, e sem alterações das referências temporais citadas, que possam indicar o fim de um conteúdo específico ou que um novo conteúdo está iniciando sua transmissão. Além disso, usualmente, um conteúdo específico (programa) é interrompido diversas vezes para a exibição de comerciais, que do ponto de vista do sincronismo das aplicações hipermídia, podem ser considerados novos conteúdos. O controle do tempo individual de conteúdos distintos, transmitidos através de um mesmo fluxo contínuo, exige o uso de diferentes bases temporais, cada uma correspondente ao tempo de exibição individual de cada conteúdo. Cada base temporal deve ser mantida (multiplexada) junto ao fluxo e deve ser possível associar cada base ao conteúdo específico a que ela se refere. Quando mais de um conteúdo é transmitido de forma intercalada, operações de pausa e retomada sobre os conteúdos devem ser realizadas, tendo como referência a troca da base temporal. Pausar um conteúdo corresponde a pausar sua base temporal. Assim, uma base temporal pode ser pausada e, posteriormente, reiniciada a partir do instante em que foi pausada. Eventualmente, a pausa em um conteúdo e a sua retomada pode acontecer em algum instante temporal diferente. Como exemplo, quando o usuário troca de canal e em seguida retorna ao canal anterior, a exibição do conteúdo deve ser retomada a partir de um instante temporal posterior àquele em que a apresentação foi interrompida. O uso de bases temporais permite que o tempo de exibição (media time) de cada um dos diferentes conteúdos existentes em um fluxo contínuo seja controlado. No entanto, é necessário definir como as aplicações hipermídia fazem referência a esses conteúdos (ou a trechos desse conteúdo), que do ponto de vista da especificação da aplicação são vistos como um único objeto de mídia (por exemplo, o vídeo principal de um canal de TV). Adicionalmente, a fim de preservar o sincronismo intermídia, as operações de pausa e retomada sobre um conteúdo do fluxo contínuo devem ser refletidas no comportamento das aplicações que referenciam esse conteúdo. Este artigo discute como as bases temporais podem ser manipuladas pelos gerenciadores de aplicações de TV digital, incluindo as aplicações interativas e adaptativas, de forma a preservar o sincronismo intermídia entre os objetos dessas aplicações. No artigo, são discutidas como as operações de pausa e retomada nos conteúdos de um mesmo fluxo podem ser suportadas, utilizando para isso uma estrutura de grafos temporais [2]. Os modelos e conceitos propostos são discutidos com base na implementação de referência do middleware declarativo Ginga- NCL [3], padrão do Sistema Brasileiro de TV Digital por difusão terrestre (SBTVD-T). O restante deste artigo apresenta em detalhes a solução proposta, com a seguinte organização. A Seção 2 apresenta como é realizado o controle temporal das aplicações nos principais sistemas de TV digital por difusão. A Seção 3 discute a solução proposta com base na implementação Ginga- NCL, com destaque para a forma de associação dos objetos das aplicações às bases temporais. A Seção 4 discute a modelagem das aplicações através de grafos temporais, fundamentais para que o sincronismo seja preservado. Finalmente, a Seção 5 apresenta as conclusões. 2. TRABALHOS RELACIONADOS Na maioria dos sistemas de TV digital terrestre [4], o formato adotado para a multiplexação dos fluxos de áudio principal e vídeo principal de um programa e de outros dados, incluindo as aplicações interativas, é o fluxo de transporte MPEG-2 (TS), especificado no padrão MPEG-2 Sistemas [1]. Um fluxo de transporte é formado por um ou mais fluxos elementares (ES Elementary Stream), cada um gerado pela codificação individual dos conteúdos. A Figura 1 apresenta um exemplo de fluxo de transporte de um sistema de TV digital, composto de um vídeo e de um áudio sincronizados pela mesma base temporal, por um fluxo transportando o relógio de referência, por um fluxo de dados formado por um carrossel de objetos, e ainda outro, transportando eventos DSM-CC, discutidos no que se segue. 2 Enquanto o PTS é utilizado para ajustar o relógio temporal dos clientes em relação ao relógio das estações transmissoras, preservando o sincronismo do conteúdo audiovisual quando ele é decodificado, o PCR é utilizado para controlar a taxa de decodificação do conteúdo, evitando underflow e overflow no buffer dos transmissores e receptores.

3 Provedor de Conteúdo M U X Fluxo de Transporte (TS) Figura 1. Fluxo de transporte em sistemas de TVD. No processo de codificação, fluxos elementares que possuem uma base temporal em comum como, por exemplo, áudio, vídeo, legendas etc. são sincronizados por selos de tempo. Quando esses fluxos elementares são recebidos, os receptores conhecem, além do conteúdo, a especificação do sincronismo entre esses fluxos. Para os dados, transmitidos em um serviço assíncrono, os sistemas de TV digital por difusão utilizam, em sua maioria, o protocolo carrossel de objetos, especificado no padrão DSM-CC (Digital Storage Media Command and Control) [5]. O carrossel de objetos e outras entidades apresentadas na Figura 1, como os eventos DSM-CC [5] e as bases temporais, serão detalhados posteriormente nesta seção. Selos de tempo permitem o sincronismo entre os fluxos elementares de uma base temporal comum. Para especificar o sincronismo entre os dados transmitidos de forma assíncrona e os conteúdos de mídia contínua dos fluxos elementares, os tempos de exibição de cada conteúdo de cada fluxo elementar devem ser conhecidos. Em alguns dos principais sistemas de TV digital (Digital Video Broadcast - DVB [6], Advanced Television System Committee - ATSC [7], Association of Radio Industries and Businesses - ARIB [8]) as bases temporais dos diversos conteúdos de um fluxo elementar são multiplexadas, de forma idêntica à multiplexação dos conteúdos que compõem o fluxo, compondo o que se denomina o NPT (Normal Play Time). Esses valores são transportados em estruturas de dados denominadas descritores de referência NPT (NPT Reference Descriptor) [5]. Um descritor NPT contém um campo contentid identificando a que conteúdo de um fluxo ele se refere e o valor de sua base temporal no momento. Utilizando o NPT, o controle do sincronismo nesses sistemas pode ser realizado de duas formas principais: monitorando constantemente os valores NPT recebidos; enviando aos receptores eventos de sincronismo (eventos DSM- CC [5]) Na primeira alternativa, as aplicações se cadastram como ouvintes dos valores NPT. Isso envolve o processamento do fluxo de transporte, com o intuito de extrair os descritores NPT. O sincronismo é obtido através de constantes comparações entre os valores especificados na aplicação e os valores recebidos através dos descritores NPT. D E M U X Cabeçalho Pacote TS Pacote TS Objeto de Evento id event_name 5 Tipo X 7 Tipo Y Tap (tipo NPT) Base temporal 3 Carrossel de Objetos ste dir fil fil Receptor 3 Evento DSMCC id: 5 time_value: 508 private_data: Na segunda alternativa, o sincronismo é realizado através de eventos DSM-CC, ilustrados na Figura 1. Um evento DSM-CC é gerado através da inserção, no fluxo de transporte, de uma estrutura denominada descritor de eventos. Cada descritor de eventos possui um identificador numérico único, que o identifica no escopo das aplicações (id 5 na Figura 1). Cada descritor possui também uma referência temporal que indica em qual instante o evento deverá ocorrer (time_value), baseado em um valor NPT. Alternativamente, um descritor de eventos pode informar ao receptor que o evento deve ocorrer imediatamente esse tipo de evento é chamado de do it now. Além do identificador e da referência temporal, o descritor de eventos possui também um campo para dados específicos das aplicações (private_data), cujo significado é definido pelas próprias aplicações. Como pode ser observado na Figura 1, um carrossel de objetos pode transportar um objeto do tipo evento (ste). Esse objeto é utilizado para definir tipos de eventos DSM-CC possíveis de serem descritos no fluxo de transporte. Para isso, o objeto relaciona identificadores de descritores de eventos DSM-CC a uma string (event_name). Assim, a aplicação pode requisitar ao receptor ser notificada sobre a ocorrência de tipos de eventos específicos. O objeto do tipo evento é fundamental na definição da associação de um evento DSM-CC a uma base temporal (contentid), por meio de uma estrutura chamada Tap (base temporal 3 da Figura 1). Se essa estrutura não for definida, os eventos relacionados no objeto de evento só poderão ser do tipo do it now. Completando a Figura 1, os outros objetos apresentados no carrossel de objetos representam as estruturas da aplicação, que podem ser diretórios (dir) ou arquivos (fil), como imagens, ou a própria aplicação interativa. É importante ressaltar que diferentemente da primeira alternativa, em que as aplicações monitoraram os valores NPT, na segunda alternativa a aplicação é notificada pelo receptor sobre a ocorrência dos eventos quando os valores NPT são satisfeitos. No entanto, devido à complexidade do mecanismo de disparo dos eventos, na prática observa-se que apenas eventos cujo sincronismo é trivial são especificados, ou seja, os eventos do tipo do it now [5]. Em relação ao suporte à autoria de aplicações, os sistemas de TV digital europeu, americano e o japonês definem tanto linguagens baseadas em implementações Java 3 quanto linguagens baseadas em tecnologias XHTML (incluindo CSS, DOM e ECMAScript) [9]. Nas linguagens baseadas em Java o sincronismo pode ser especificado registrando os eventos de sincronismo a serem monitorados e criando observadores para monitorar a chegada desses eventos. Essa abordagem, no entanto, exige que os autores conheçam bibliotecas específicas e técnicas de programação orientada a objeto. As linguagens baseadas em XHTML são mais simples de serem utilizadas. No entanto, para as tarefas mais elaboradas, que incluem o sincronismo das mídias, linguagens de scripts [4] são necessárias. Nesse caso, as vantagens da simplicidade declarativa são perdidas. Os mesmo procedimentos citados para Java deverão ser realizados pelos scripts. Uma alternativa para especificar o sincronismo em linguagens baseadas em XHTML consiste em dividir o documento, que 3

4 representa a aplicação, em vários pequenos documentos apresentados ao longo do tempo, iniciados por meio de eventos de sincronismo disparados pelo autor. Essa abordagem, no entanto, pode ser utilizada apenas para aplicações simples e mesmo nesse caso, a semântica da aplicação original é completamente perdida, em seu lugar tem-se um conjunto de exibições isoladas disparadas no tempo. Em outras palavras, a semântica da apresentação como um todo fica na cabeça do autor que passa a ser o controlador da aplicação. O padrão brasileiro de TV digital (SBTVD-T) define como alternativa declarativa a linguagem NCL (Nested Context Language) [3]. NCL é uma linguagem com o escopo muito mais amplo que XHTML, permitindo a definição do sincronismo de mídias em sua forma mais ampla, sem a necessidade do uso de scripts imperativos. Na NCL o sincronismo é realizado de forma transparente para os autores, que não precisam se preocupar com elementos como o NPT ou eventos de sincronismos, entidades abstraídas pela máquina de apresentação, facilitando muito a tarefa do autor, como discutido nas próximas seções. 3. TRATAMENTO DO SINCRONISMO NO GINGA-NCL Na linguagem NCL, um objeto de mídia (especificado através do elemento NCL <media>) é associado a um conteúdo de mídia através de um localizador (locator). No caso de um fluxo elementar carregando vários conteúdos diferentes multiplexados, o localizador é, por si só, incapaz de identificar a base temporal ligada a cada conteúdo, problema similar encontrado nos outros sistemas de TV digital. No Ginga-NCL (agente de usuário NCL) a associação entre os objetos de mídia e as bases temporais de cada conteúdo individual, é realizada através de comandos de edição [3], também fazendo uso de eventos DSM-CC, mas de uma forma tal que esconde toda a complexidade da manipulação do NPT. Comandos de edição NCL permitem maior dinamismo na execução das aplicações através de edições realizadas sobre as especificações das aplicações em tempo de execução (ao vivo). Além de poder modificar as aplicações nos receptores, preservando a sintaxe de autoria definida junto aos provedores, é através desses comandos que as aplicações são iniciadas, finalizadas, pausadas e retomadas. Durante uma transmissão, a especificação da aplicação e os conteúdos das mídias por ela referenciados podem ser recebidos em momentos distintos ao longo da programação da emissora. Mesmo após o recebimento da especificação da aplicação (contendo todas as relações de sincronismo entre seus objetos de mídia) e dos conteúdos que fazem parte da apresentação, o início de uma aplicação no Ginga-NCL somente ocorre após o recebimento de um comando para iniciar a apresentação (startdocument). É no momento do recebimento desse comando que o contentid corrente do NPT, isto é, aquele que está sendo recebido no estado ocorrendo no fluxo NPT multiplexado no fluxo de transporte, é associado aos conteúdos transmitidos por fluxos contínuos referenciados na aplicação iniciada. A partir de então, todo descritor de NPT com o mesmo contentid adotado na iniciação é reportado a todos os exibidores de objetos de mídia referenciados na aplicação, fazendo com que eles saibam exatamente o tempo de exibição (media time) de cada conteúdo contínuo recebido por fluxo elementar. Na arquitetura apresentada na Figura 2, o Núcleo Ginga é responsável por oferecer serviços à Máquina de Apresentação Ginga-NCL 4. A Máquina de Apresentação Ginga-NCL contém os módulos responsáveis por iniciar e controlar as aplicações NCL. Máquina de Apresentação Ginga-NCL Formatador Escalonador Ger. de Exibidores Núcleo Ginga Processador de Dados Persistência Conversor Gerenciador de Bases Privadas Exibidores Sintonizador Figura 2. Ginga-NCL: arquitetura resumida. No Ginga-NCL, o módulo Sintonizador é a entidade responsável por receber o fluxo de transporte transmitido pelos provedores de conteúdo. A demultiplexação desse fluxo é realizada pelo módulo Processador de Dados, que então obtém as informações para a execução das aplicações, que incluem os fluxos do carrossel de objetos, eventos DSM-CC e o fluxo NPT. O Núcleo Ginga possui ainda o módulo Exibidores, contendo os decodificadores necessários para a exibição dos diversos tipos de mídia. Na Máquina de Apresentação NCL, o módulo Formatador é o responsável por receber e controlar as aplicações NCL entregues pelo Núcleo Ginga. Ao receber uma aplicação NCL, o Formatador solicita a tradução das especificações em estruturas de dados adequadas à apresentação das aplicações. Essa tradução é realizada pelo módulo Conversor. As estruturas geradas a partir da conversão da NCL são voltadas para o controle da apresentação e incluem tanto entidades abstratas, como monitores de eventos das âncoras temporais existentes nas aplicações, quanto entidades conceituais do modelo hipermídia no qual a NCL é baseada [3]. Os eventos associados às âncoras temporais de objetos com conteúdos recebidos pelo carrossel de objetos são facilmente dedutíveis pela duração e o tempo de início dos objetos, conhecidos a priori. Os eventos associados às âncoras temporais de um objeto cujo conteúdo é recebido através de um fluxo elementar só podem ter seus tempos deduzidos a partir do NPT obtido, como mencionado anteriormente nesta seção. Além das estruturas mencionadas, em um ambiente de TV digital, outras estruturas de controle são necessárias, como a estrutura de grafos temporais, construída pelo módulo Escalonador, conforme será descrito na próxima seção. As estruturas geradas pelo módulo Conversor somente estarão disponíveis ao módulo Formatador após o comando adddocument ser recebido pelo módulo Gerenciador de Bases Privadas. Uma 4 O middleware Ginga é formado por duas partes principais: a parte declarativa, representada na autoria pela linguagem NCL, e a parte procedural, representada pela linguagem Java. Em comum, essas partes compartilham serviços oferecidos pelo mesmo núcleo.

5 base privada corresponde ao local onde as estruturas relativas às aplicações permanecem à disposição do módulo Formatador. Como mais de uma base privada pode ser controlada simultaneamente, essa tarefa cabe ao módulo Gerenciador de Bases Privadas. Esse módulo também recebe os comandos de edição ao vivo, como o adddocument mencionado, e garante suas execuções. Os comandos de edição são transmitidos junto ao fluxo de transporte através de eventos DSM-CC com uma sintaxe padronizada para o SBTVD-T [3]. Ao serem recebidos, os comandos são processados pelo módulo Processador de Dados, que os entrega ao Gerenciador de Bases Privadas a fim de serem executados. Estando as estruturas obtidas pela conversão da aplicação em uma base privada, o comando startdocument, quando recebido pelo Gerenciador de Bases Privadas, gera uma notificação ao Formatador, que solicita ao módulo Escalonador para orquestrar a apresentação da aplicação. Para que os conteúdos sejam corretamente exibidos, o Escalonador solicita ao Gerenciador de Exibidores que instancie o exibidor apropriado ao tipo de conteúdo a ser exibido. O comando startdocument gera também uma solicitação ao Processador de Dados para que seja informado o contentid do descritor NPT atualmente recebido no fluxo de transporte. Dessa forma, se o elemento <media> do documento NCL referencia um fluxo elementar de mídia contínua, o exibidor instanciado é capaz de tratar o valor da base temporal passado pelos descritores NPT com o mesmo contentid. A mudança do valor do campo contentid de um descritor NPT para outro consecutivo indica a interrupção da apresentação de um conteúdo para a exibição de outro. Essa interrupção pode ser temporária ou permanente, indicando que o conteúdo anterior terminou sua apresentação. Em qualquer desses casos, o Escalonador deve ser notificado para que a apresentação de todos os objetos de mídia associados ao contentid sejam pausados. No primeiro caso, quando a base temporal é retomada (quando voltar a receber o descritor NPT com o mesmo contentid), a aplicação continua sua execução a partir do ponto de interrupção. Caso a base temporal não seja retomada em um determinado intervalo máximo de tempo (de acordo com as características do receptor), o ciclo de vida da aplicação chega ao fim. Nesse caso, a apresentação dos objetos de mídia associados ao contentid no momento de pausa deve ser finalizada pelo módulo Formatador. Todos os eventos relacionados ao término da apresentação dos conteúdos devem ser disparados pelo Escalonador. O único cuidado que o provedor deve tomar nesse procedimento é não reusar o contentid em um intervalo de tempo menor do que o estipulado para o término da aplicação. Para que os conteúdos das aplicações sejam corretamente associados às bases temporais, é importante considerar o tempo de envio dos comandos startdocument. A Figura 3 apresenta um exemplo de como essa associação deve ser realizada. Nessa figura, um vídeo de uma animação (áudio e vídeo codificados) é transmitido através de um fluxo contínuo. Durante a transmissão são inseridos dois outros conteúdos a esse fluxo, relativos a duas propagandas (P1 e P2). Nesse exemplo, uma aplicação NCL, que faz referência ao conteúdo do vídeo da animação também é transmitida aos usuários. As demais mídias, bem como a especificação da aplicação, são transmitidas, através do carrossel de objetos, durante todo o período definido na grade de programação do exemplo, permitindo que os receptores ligados em diferentes momentos da transmissão também possam receber e executar a aplicação. Da mesma forma, o comando de edição adddocument utilizado para carregar a aplicação na base privada, também deve ser transmitido durante todo o período da transmissão das mídias e da especificação. O comando startdocument da aplicação, por outro lado, somente pode ser transmitido no intervalo de tempo em que a base temporal transmitida corresponde ao vídeo da animação (contendid = 1). Grade de Programação Áudio e Vídeo P1 P2 Áudio e Vídeo... Garrincha Garrincha... NPT Ciclos C 1 C 1 C 2 C 3 contentid 1 contentid 2 contentid 3 contentid 1 (cont.) C 1 C 1 C 1 C 1 Estruturas C 2 C 3 Carrossel(1) + adddocument(1) + startdocument(1) Carrossel(1) + adddocument(1) Carrossel(2) + adddocument(2) + startdocument(2) Carrossel(3) + adddocument(3) + startdocument(3) Figura 3. Exemplo de conteúdos NPT em uma grade de programação. Ainda no exemplo da Figura 3, outras aplicações são também transmitidas, cujo conteúdo faz referência aos conteúdos do fluxo contínuo relativos às propagandas P1 e P2. Para essas aplicações o comportamento é análogo ao da aplicação com conteúdo do vídeo da animação. Os diferentes ciclos do carrossel de objetos ao longo do tempo são apresentados na figura. 4. MODELAGEM DO CONTROLE DO SINCRONISMO Quando uma aplicação sofre operações de pausa e retomada, que exigem que ela prossiga, mas em um instante temporal posterior ao de pausa, outras estruturas devem ser utilizadas para garantir o sincronismo e a qualidade da apresentação. Esse tipo de operação é comum quando o usuário troca e, em seguida, retorna ao mesmo canal. Ou seja, troca as bases temporais mantidas pelo NPT por outras bases mantidas por outro NPT (outro fluxo TS), e depois as retoma. De maneira genérica, o mesmo problema de sincronismo ocorre sempre que conteúdos transmitidos por fluxos contínuos são referenciados na aplicação, uma vez que, no ambiente de TV, o usuário pode começar a assistir a uma apresentação cujos conteúdos referenciados já iniciaram a sua exibição, como é o caso do áudio e vídeo principais. Para controlar o comportamento temporal das aplicações durante a sua execução, o Ginga-NCL adota uma estrutura formada por grafos direcionados (dígrafos). Essa estrutura, conhecida como Grafos Temporais Hipermídia (GTH) [2], oferece suporte ao início ou retomada síncrona da apresentação a partir de um instante temporal qualquer. No GTH cada vértice representa uma transição de estado de um evento. Os eventos representados nessa estrutura são os mesmos definidos na NCL [3]. NCL define os eventos de apresentação, seleção e atribuição, cada um controlado por uma máquina de estados, como mostra a Figura 4.

6 (fim) preparado pausado (pausa) (início) (fim) (recomeço) ocorrendo Figura 4. Transições entre estados de um evento. O grafo temporal obtido através da modelagem de uma aplicação deve preservar todos os relacionamentos entre os eventos, sejam eles previsíveis ou imprevisíveis, bem como o estado atual de cada máquina de estados associada a um evento. No GTH as arestas entre os vértices representam os relacionamentos entre as transições dos estados de um evento. Cada aresta possui associada uma condição que deve ser satisfeita para que a transição, representada pelo seu vértice de destino, seja disparada. Em resumo, os grafos nessa estrutura são definidos por um conjunto de vértices, arestas e condições de caminhamento (V, A, C), onde: V = (v 0, v 1, v 2, v 3,..., v n-1 ) é um conjunto finito de vértices, em que cada vértice representa uma transição na máquina de estados associada a um evento. Cada vértice é representado por uma tripla: o nome da ação que dispara a transição; o tipo de evento correspondente; e o nome da âncora que identifica o objeto ou sua parte (se o evento é do tipo apresentação ou seleção) ou o identificador único da propriedade (se for um evento de atribuição); A = (a 0, a 1, a 2, a 3,..., a m-1 ) é um conjunto finito de arestas que representam, individualmente, um relacionamento entre transições. Para cada aresta a, v e w são os vértices de origem e destino respectivamente ((v, w) V x V); C = {c ij } é um conjunto finito de condições associadas às arestas. Uma condição c ij é associada com a aresta (v i, v j ) A e deve ser satisfeita para que o disparo do vértice (disparo da transição) destino da aresta considerada seja realizado. Condições podem ser simples ou compostas. Uma condição simples é definida por: um intervalo temporal que deve ser obedecido para que a transição, representada no vértice destino da aresta, seja executada; uma variável que pode ser testada em relação a um valor desejado; ações externas à aplicação, como as interações do usuário. Condições compostas são definidas através de operadores lógicos (OR, AND, NOT), relacionando duas ou mais condições (simples ou compostas). Para exemplificar o uso dos grafos temporais, considere a mesma aplicação apresentada na seção anterior, onde um programa interativo, baseado na exibição de uma animação, é exibido. Nessa aplicação, outro vídeo pode ser exibido, paralelamente ao vídeo da animação principal, se o usuário interagir com a aplicação em um determinado instante. A possibilidade de interação é representada através da inserção de uma imagem, em um período definido por uma âncora temporal no vídeo da animação. A ação interativa provoca também o redimensionamento do vídeo principal e a exibição de um formulário XHTML, que será interrompido somente quando terminar a exibição do segundo vídeo mencionado (disparado pela ação interativa). Nesse instante, o vídeo principal é novamente redimensionado, voltando às suas dimensões originais. A Figura 5 apresenta parte de um documento NCL que pode ser utilizado para especificar essa aplicação. No documento aparecem em destaque os objetos de mídia (elementos <media>, linhas 5 a 10) e os relacionamentos entre eles (elementos <link>, linhas 12 a 36). 1. <ncl id="ncl" xmlns="futebol" > 2. <head> </head> 3. <body> 4. <port id="entrada" component="animacao"/> 5. <media id="animacao" src="x-sbtvd-ts://0x57" > 6. <area id="ancora" begin="19s" end="25s"/> 7. <property name="bounds"/> </media> 8. <media id="chuteira" src="chuteira.jpg" /> 9. <media id="anuncio" src="anuncio.mpg" /> 10. <media id="pagina" src="compra.html /> <link id="inichuteira" xconnector="onbeginstart"> 13. <bind role="onbegin" component="animacao" interface="ancora"/> 14. <bind role="start" component="chuteira"/> 15. </link> 16. <link id="fimchuteira" xconnector="onendstop"> 17. <bind role="onend" component="animacao" interface="ancora"/> 18. <bind role="stop" component="chuteira"/> 19. </link> 20. <link id="propaganda" xconnector="onselsetstart"> 21. <bind role="onsel" component="chuteira"> 22. <bindparam name="keycode" value="red"/> 23. </bind> 24. <bind role="set" component="animacao" interface="bounds"> 25. <bindparam name="var" value="5%,6%,41%,38%"/> 26. </bind> 27. <bind role="start" component="anuncio" /> 28. <bind role="start" component="pagina" /> 29. </link> 30. <link id="fimpagina" xconnector="onendstopset"> 31. <bind role="onend" component="anuncio" /> 32. <bind role="set" component="animacao" interface="bounds" > 33. <bindparam name="var" value="0,0,100%,100%"/> 34. </bind> 35. <bind role="stop" component="pagina" /> 36. </link> 37. </body> 38. </ncl> Figura 5. Documento NCL. A Figura 6 apresenta o grafo resultante da modelagem do exemplo da Figura 5, detalhado nos próximos parágrafos. (Início, Animacao) 1 Dur = 19s (Início, Âncora) (Início,Chuteira) Dur A = 6s 2 3 (Fim, Âncora) (Fim,Chuteira) (Fim, Animacao) Ação Interativa (Início, Anúncio) (Fim, Anúncio) (Início, Seleção, Chuteira) 0 Dur B = 8s 0 0 (Início, Atribuicao, Bounds) (Início, Atribuicao, Bounds) (Início, Página) (Fim, Página) Figura 6. Grafo da modelagem de um programa interativo. 14

7 Para simplificar a Figura 6, os eventos de apresentação foram suprimidos nas triplas que definem os vértices. Nessa figura, o Vértice 1 é o ponto de entrada da aplicação e representa a transição de início da apresentação da animação. Quando a duração (Dur) do objeto Animação atinge o valor de 19 (dezenove) segundos, é disparada a transição de início de uma âncora temporal (Vértice 2), com duração de 6 (seis) segundos. A transição de início da âncora do objeto Animação dispara a transição de início de um objeto de imagem (Chuteira), representado pelo Vértice 4, que indica ao usuário a possibilidade de interação com a aplicação. A imagem da chuteira tem sua apresentação interrompida através da transição de fim da âncora (Vértice 3). O Vértice 6 representa a transição de início do evento de seleção. A aresta, que relaciona esse vértice com o Vértice 4, tem como condição a ação de interatividade do usuário. Na versão anterior do GTH, vários grafos eram normalmente utilizados para representar uma mesma aplicação, cada um representando um conjunto de eventos previsíveis. Na atual estrutura, um único grafo é utilizado para representar toda a aplicação e, durante a apresentação, partes podem ser retiradas desse grafo quando os eventos imprevisíveis que ligam essas partes ao restante do grafo não puderem mais ser disparados. No contexto da Figura 6, se o usuário não realizar a ação interativa até o fim da apresentação do objeto Chuteira, os eventos representados no grafo a partir do Vértice 6 nunca irão ocorrer. A partir da ocorrência do evento interativo (Vértice 6), a disposição espacial do objeto Animação é alterada (Vértice 7, propriedade Bounds), e são exibidas a página XHTML (Vértice 8) e o objeto de vídeo Anúncio (Vértice 9). Ao término da duração desse último objeto de vídeo (Dur B), a exibição da página XHTML é terminada (Vértice 11) e a disposição espacial inicial do objeto Animação é restabelecida. O conjunto de transições de eventos disparados sobre os objetos de uma aplicação e os seus correspondentes momentos no tempo definem um plano de apresentação. Quando uma aplicação é modelada através de um grafo temporal, como o apresentado na Figura 6, os tempos para o disparo dos seus eventos podem ser estimados através do caminhamento nas arestas do grafo. Para as aplicações que contêm apenas eventos previsíveis, os instantes para o disparo das transições dos eventos podem ser totalmente calculados antes da execução da aplicação. Quando a aplicação contém eventos imprevisíveis, o cálculo dos instantes para o disparo das transições dos eventos também pode ser realizado a priori. No entanto, nesse caso, o tempo para o disparo de alguns eventos será computado de forma relativa à ocorrência de um evento imprevisível. Considerando o exemplo apresentado nas Figuras 5 e 6, os tempos dos eventos representados pelos vértices numerados de 7 a 12 é calculado com base no tempo da ocorrência do Vértice 6. A Tabela 1 resume o plano de apresentação obtido a partir do grafo da Figura 6. Tabela 1. Eventos do plano de apresentação. Início, Apresentação, Animação, 0s Início, Apresentação, Âncora,19s Início, Apresentação, Chuteira, 19s Início, Seleção, Chuteira, i Fim, Apresentação, Chuteira, 25s Fim, Apresentação, Animação, - Início, Atribuição, Bounds, (i+0)s Inicio, Apresentação, Pagina, (i+0)s Inicio, Apresentação, Anúncio, (i+0)s Fim, Apresentação, Anúncio, (i+8)s Fim, Apresentação, Página, (i+8)s Início, Atribuição, Bounds (i+8)s Na Tabela 1, a coluna inicial representa os eventos que não dependem da ação interativa, com exceção do evento de seleção. Na outra coluna encontram-se os eventos disparados a partir do evento de seleção representado pelo Vértice 6. Como os tempos dessa coluna são relativos à ocorrência do evento imprevisível, seus tempos estimados estão vinculados ao tempo da ocorrência do evento imprevisível. A partir do plano de apresentação, as operações de início/retomada da exibição de um aplicativo de TV podem ser realizadas simplesmente desprezando os eventos não determinísticos que poderiam ter ocorrido antes do tempo em que se pretende iniciar/retomar a apresentação, mas levando em consideração todos os que de fato ocorreram (no caso de retomada da exibição). Como exemplo de iniciação do aplicativo da Figura 5, considere que o usuário sintonizou o canal onde o vídeo da animação está sendo transmitido, em um momento onde já se passaram 20 segundos do início da transmissão. Considere também que nesse momento o vídeo está sendo normalmente transmitido, isto é, não há interrupção corrente por nenhum tipo de propaganda. Assim, deverão ser entregues aos receptores, através do carrossel de objetos, os conteúdos que fazem parte da aplicação e o arquivo NCL que especifica os relacionamentos de sincronismo. Além desses arquivos, também deverão ser entregues aos receptores os eventos DSM-CC correspondentes aos comandos adddocument e startdocument. Conforme apresentado na seção anterior, o comando adddocument é interpretado pelos receptores fazendo com que a especificação da aplicação seja adicionada à base privada. O comando startdocument gera uma notificação ao módulo Formatador, que solicita ao módulo Escalonador a construção do grafo temporal. Com o grafo construído, o Escalonador calcula o plano de apresentação e, através do Gerenciador de Exibidores, obtém a informação que um dos objetos da aplicação, no caso o objeto Animação, faz referência a um conteúdo transmitido por fluxo de mídia contínua. Através do exibidor desse conteúdo, o Escalonador é informado do seu tempo de exibição, no caso, 20 (vinte) segundos. Note que o exibidor de conteúdo sabe esse valor por monitorar descritores NPT. De posse do valor 20 (vinte) segundos, o Escalonador posiciona a aplicação no contexto desse instante temporal, no plano de apresentação. No caso específico desse exemplo, o usuário ainda poderia realizar a ação interativa, originalmente prevista com duração de 6 (seis) segundos, nos próximos 5 (cinco) segundos. A Figura 7 apresenta a exibição da aplicação no momento temporal do sincronismo. Figura 7. Retomada em uma aplicação NCL em apresentação.

8 O mesmo raciocínio pode ser utilizado para operações de pausa e retomada, com mudança intermediária de canal. Ao se mudar o canal, a aplicação entra em modo de espera (stand by). Ao retornar ao canal, quando a base temporal for retomada 5 (quando voltar a receber o descritor NPT com o mesmo contentid), a aplicação continua sua execução a partir do ponto informado pelo valor do descritor NPT, desconsiderando qualquer evento não determinístico que poderia ter ocorrido desde o momento de sua pausa até o momento de sua retomada. Como anteriormente, caso não seja retomada em um determinado intervalo máximo de tempo (de acordo com as características do receptor), o ciclo de vida da aplicação chega ao fim. Nesse caso, a apresentação dos objetos de mídia associados ao contentid no momento de pausa será finalizada pelo módulo Formatador. Todos os eventos relacionados ao término da apresentação dos conteúdos serão disparados pelo módulo Escalonador. 5. CONCLUSÕES A preservação do sincronismo intermídia em aplicações que referenciam conteúdos transmitidos de forma intercalada com outros conteúdos, em um mesmo fluxo contínuo, não é um problema trivial. Para resolução desse problema, típico de aplicações para TV digital, diversas alternativas são discutidas neste artigo. Em um cenário típico de TV digital, uma aplicação pode referenciar o fluxo de vídeo principal que, usualmente é intercalado por propagandas e seguido por outros programas (conteúdos). Mais ainda, ao usuário telespectador é permitido receber e executar a aplicação qualquer que seja o tempo de sintonização de um canal. Agravando o fato, a sintonização de um canal pode ser um retorno após uma breve visita a outro canal, quando, então, não é desejável que a aplicação, anteriormente iniciada, seja finalizada e recomeçada sem levar em conta a sua história passada. Todas essas características tornam mais complexa a preservação do sincronismo. Entre as alternativas apresentadas no artigo, o uso de diferentes bases temporais, uma para cada conteúdo transmitido no fluxo contínuo, é descrita como a solução ideal. A dificuldade está em como associar cada base temporal a seu conteúdo. Em alguns dos principais sistemas de TV digital, como apresentado, o controle das bases temporais ou é insuficiente, ou demanda que os autores de aplicações (ou sistemas de autoria), conheçam os detalhes da implementação do sincronismo e que sejam os controladores da execução da aplicação. Na solução apresentada, adotada no ambiente Ginga-NCL do Sistema Brasileiro de TV Digital, a preservação do sincronismo é realizada de forma transparente, livrando o autor de aplicações finais o conhecimento dos detalhes de sua implementação. No Ginga-NCL, independente do momento em que um telespectador inicia a recepção da transmissão, a qualidade do sincronismo é sempre preservada. 6. REFERÊNCIAS [1] ISO/IEC , Information technology Generic coding of moving pictures and associated audio information: Systems, 2000, ISO/IEC. [2] Costa, R. et al. DocEng, ACM Symposium on Document Engineering, Intermedia Synchronization Management in DTV Systems, São Paulo, Brazil, [3] Televisão digital terrestre - Codificação de dados e especificações de transmissão para radiodifusão digital Parte 2: Ginga-NCL para receptores fixos e móveis Linguagem de aplicação XML para codificação de aplicações. Setembro [4] Morris, S., Smith-Chaigneau, A. Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Focal Press, [5] ISO/IEC , Information technology Generic coding of moving pictures and associated audio information: Digital Storage Media Command & Control, 1996, ISO/IEC. [6] DVB Document A038 Rev. 3, Specification for Service Information (SI) in DVB systems, 2007, DVB. [7] ATSC A/65b, Program and System Information Protocol, 2003, ATSC. [8] ARIB STD-B10, Service Information for Digital Broadcasting System, 2005, ARIB. [9] DVB Document A107, Multimedia Home Platform (MHP) Specification 1.2, 2007, DVB. 5 Note que a base temporal pode ser retomada não imediatamente após o retorno ao canal, pois pode estar sendo exibido outro conteúdo no momento.