MPEG-2 e o datacasting suportado na TV digital – final

DESTAQUE
MPEG-2  e  o  datacasting  suportado  na  TV  digital – final

A  SEGUIR,  A  ÚLTIMA  PARTE  DO  ARTIGO  “MPEG-2  SYSTEMS  E  OS  MECANISMOS  DE  DATACASTING  SUPORTADOS  NA  TV  DIGITAL”  DOS  PESQUISADORES  CARLOS  PICCIONI  E  CARLOS  MONTEZ  DA  UNIVERSIDADE  FEDERAL  DE  SANTA  CATARINA  (UFSC).

Por Carlos Piccioni e Carlos Montez

DSM-CC e os Carrosséis
O DSM-CC, Digital Storage Media Command and Control, é a sexta parte do conjunto de especificações MPEG-2. Também conhecido como ISO/IEC 13818-6, padroniza um conjunto de protocolos que fornece funções de controle para o gerenciamento de fluxos de bits MPEG-2. Partes dessa especificação são adotadas pelos sistemas de televisão digital. Foi originalmente desenvolvido com o objetivo de fornecer funções semelhantes às presentes em aparelhos de vídeo cassete para o controle de fluxos de áudio e vídeo presentes em um fluxo de transporte. Posteriormente o DSM-CC foi estendido e dividido em várias partes, com o intuito de fornecer funções como seleção, acesso e controle de fontes distribuídas de vídeo e suporte para a transmissão de dados através de fluxos de transporte, além de outras.
O DSM-CC pode ser visto como um conjunto de ferramentas, apresentando várias configurações e funcionalidades. Os mecanismos de carrossel de dados e carrossel de objetos do DSM-CC são dois dos mecanismos mais utilizados para a difusão de dados nos sistemas de TVD. O nome carrossel deriva de seu propósito que é o de repetir ciclicamente determinado conjunto de dados em um fluxo de transporte.
Essa característica auxilia o receptor no acesso aos dados, visto que o mesmo, em busca de determinada informação, necessita apenas aguardar sua próxima repetição no TS. Também é possível, em nível do set-top box, adotar mecanismos de armazenamento prévio de conteúdo de um carrossel, de forma a agilizar a disponibilidade dos dados à alguma aplicação. Os mecanismos de carrosséis são apresentados em mais detalhes a seguir.

figura 1
Fig. 9 – Exemplo de um carrossel de dados.

Carrossel de Dados
A idéia básica desse protocolo é a de difundir módulos de dados ciclicamente, de modo que, quando o receptor necessitar determinado módulo, deve apenas aguardar o instante de sua próxima repetição no fluxo de dados. Devido a essa organização de dados na forma de módulos, essa forma de datacasting é recomendada para a difusão de dados delimitados. A Figura 9 ilustra um carrossel de dados.
Com relação ao protocolo em si, existem dois tipos de mensagem nos carrosséis de dados: as mensagens de controle, ou Download Control Messages e as mensagens de dados, ou Download Data Messages. As Download Data Messages usam uma estrutura sintática conhecida como DDB – Download Data Block, para o encapsulamento de dados. Já as Download Control Messages podem ser de dois tipos diferentes: as DSIs– Download Server Initiate ou as DIIs – Download Info Indication.
Um módulo, em um carrossel de dados, é definido como um item simples e completo de dados. Por exemplo, um único arquivo de texto ou vários outros arquivos de texto podem ser definidos como um módulo. Cada módulo é então dividido em um ou mais blocos, e cada bloco é inserido na carga de uma Download Data Blocks. As Download Control Messages nas formas de DSI ou DII carregam as informações sobre o conjunto de módulos de um determinado carrossel. Tanto as DDBs, DIIs e DSIs são construídas baseadas nas estruturas das private sections. A pilha de estruturas de um carrossel de dados é ilustrada na Figura 10.
Em um carrossel, não há restrições com relação à ordem dos DDBs e com a quantidade de vezes em que são inseridos no mesmo. Dessa forma, determinados módulos podem estar presentes mais de uma vez por rotação, fazendo com que os mesmo sejam difundidos a uma freqüência maior que os outros.
O carrossel de dados permite que um conjunto de diferentes módulos possa ser organizado logicamente formando grupos. Não há restrições sobre quantos módulos podem pertencer a um grupo, e um módulo pode fazer parte de um ou mais grupos. Para cada grupo, sempre deve haver uma DII que é responsável pela descrição de cada módulo pertencente ao mesmo.
Um conjunto de grupos pode ser organizado logicamente formando supergrupos.
Assim como em um grupo, cada supergrupo deve possuir uma mensagem de controle.
Porém, no caso dos supergrupos são as DSI as mensagens responsáveis por descrever cada um de seus membros. A Figura 11 ilustra a estrutura de um carrossel de dados baseado em grupos e supergrupos.
Quando o número de módulos é pequeno, e apenas um grupo pode ser formado, não há necessidade de supergrupos. Nesse caso, conceitua-se o carrossel como um carrossel de dados de uma camada, onde apenas uma DII é necessária para descrever todo o conjunto de módulos. Por outro lado, um carrossel de dados de duas camadas é aquele onde existem supergrupos, ou seja, há a presença de mensagens de controle do tipo DII assim como do tipo DSIs. Geralmente um carrossel desse tipo se faz necessário quando o número de módulos é demasiadamente grande para ser descrito por apenas uma DII.
Os carrosséis de dados podem ser referenciados nas PSIs, mais especificamente pelas PMTs. Dessa forma, um carrossel pode fazer parte de um serviço, e a localização de suas mensagens de controle facilmente encontradas pelo set-top box através de consultas a PMT de determinado serviço.
A princípio, o DSM-CC não define nenhum mecanismos na codificação, das próprias mensagens do carrossel, de forma a incluir estampilhas de tempo para a implementação de datacasting sincronizado. Porém, alguns sistemas de televisão digital, como o ATSC, recomendam o uso de determinados campos das mensagens do carrossel para a inserção dessas estampilhas de tempo. Outra solução para o problema do sincronismo é a utilização de outras estruturas, como tabelas adicionais as PSIs, as quais fornecem informações de sincronismo dos fluxos elementares do carrossel.
O DSMCC define alguma dessas soluções, as quais podem ser implementadas também de forma proprietária pelos sistemas de televisão digital.

figura 2
Fig. 10 – Encapsu-lamento de um módulo das estruturas DSM-CC e MPEG-2 Systems.

Carrossel de Objetos
Esse protoloco é a escolha natural para a difusão de dados delimitados armazenados na forma de arquivos, como ocorre na maioria dos sistemas de arquivos atuais. Dessa forma, também é a solução mais empregada na difusão de aplicações, assim como os demais recursos utilizados por essa.

figura 3
Fig. 11 – Grupos em um carrossel de dados.

Da mesma forma como ocorre com o carrossel de dados, o carrossel de objetos pode ser utilizado para datacastingassíncrono ou sincronizado. Nesse último caso, como citado no tópico anterior, os mecanismos de sincronização podem ser implementados por outras estruturas ou por uso de determinados campos nas mensagens do carrossel de objetos.

Mensagens em um Carrossel de Objetos
Os Carrosséis de Objetos são construídos sobre as estruturas dos carrosséis de dados, adicionando uma nova camada a aqueles, onde a informação é encapsulada na forma de objetos. Nessa nova camada, os objetos são transportados em mensagens conhecidas como BIOPs, ou Broadcast Inter ORB Protocol. O BIOP é uma extensão do ORB, Object Request Broker, definido pelo CORBA.

figura 4
Fig. 12 –  Seqüência de objetos encapsulados em um módulo.

Uma BIOP é dividida primeiramente em 3 partes: cabeçalho (MessageHeader), sub-cabeçalho (MessageSubHeader) e corpo da mensagem (MessageBody). O cabeçalho carrega informações sobre a versão do protocolo BIOP utilizado e sobre o tamanho da mensagem. O sub-cabeçalho traz informações a respeito do objeto carregado, seu tipo, e um identificador, o objectKey. O corpo depende do tipo do objeto, e contém os dados que serão difundidos.
As BIOPs são carregadas dentro de módulos, os mesmos definidos pelo carrossel de dados. Cada módulo pode encapsular uma ou mais BIOPs, onde cada objeto é identificado dentro do módulo pelo seu objectKey. Dessa forma, o decodificador pode encontrar facilmente um objeto pela análise seqüencial de cada objectKey, encontrado em intervalos dentro do módulo de acordo com o tamanho de cada objeto, atributo informado pelo cabeçalho da BIOP. A Figura 12 ilustra a organização dos objetos dentro de cada módulo.
Assim como acontece com o carrossel de dados, cada módulo é fragmentado em um ou mais blocos, os quais são inseridos nas cargas de Download Data Blocks -DDBs. Os DDBs possuem tamanho fixo, com exceção do último DDB que carrega um módulo, que pode ser menor. Cada DDB é encapsulado em uma seção DSM-CC, uma extensão das private sections, como mostrado na Figura 9.

Tipos de Objetos
O conjunto de objetos que forma um carrossel de objetos é conhecido como Service Domain. Em um Service Domain existem basicamente três tipos de objetos: arquivo, diretório e stream. Os objetos do tipo arquivo são destinados ao transporte de dados da mesma forma que os mesmos são armazenados em sistemas de arquivos simples. Um objeto desse tipo pode conter o bytecode de uma aplicação interativa, ou demais recursos utilizados por ela, como arquivos de imagens ou conteúdo textual, por exemplo.
Um conjunto de objetos do tipo arquivo sempre deve pertencer a um diretório, assim como na maioria dos sistemas de arquivos atuais. Essa é a função do objeto do tipo diretório, que contém uma lista com o nome dos demais objetos pertencentes a esse, ligados a uma IOR – Interoperable Object Reference. Essa lista com os nomes dos objetos e suas IORs é conhecida como lista de ligações (List of Bindings). Em todo Service Domain deve haver um diretório raiz, a partir do qual todos os demais objetos são encontrados. O diretório raiz é implementado por um objeto especial do tipo diretório denominado Service Gateway.
Um objeto do tipo stream, por sua vez, transporta uma lista de identificadores, onde cada identificador se refere a um fluxo elementar ou a um serviço inteiro, e não será tratado em mais detalhes nesse artigo.

IOR e Profile Body
A função da IOR é fornecer ao decodificador do carrossel de objetos informações suficientes para a localização do objeto ao qual é ligado na list of bindings. Cada IOR pode conter uma ou mais referências a determinado objeto. Cada referência é conhecida como profile body.
Existem dois tipos de profile body, o BIOP Profile Body e o Lite Options Profile Body. O primeiro é utilizado para referenciar objetos localizados em um mesmo Service Domain, ou seja, em um mesmo carrossel de objetos. Já o Lite Options Profile Body de uma IOR se refere a objetos localizados em outros carrosséis (Em até mesmo outro fluxo de transporte). Esse último não será apresentado em mais detalhes, visto que é similar em vários aspectos ao primeiro, e na maioria das vezes os objetos são referenciados em um mesmo carrossel de objetos.

figura 4
Fig. 13 – Uso do Tap para referenciar fluxos elementares.

Um BIOP Profile Body possui basicamente duas estruturas: o ObjectLocation e o ConnBinder. O ObjectLocationé utilizado para referenciar o objeto em um módulo. Ele fornece o número do indentificador do módulo (moduleId) assim como o objectKey do objeto. Como os módulos no carrossel de objetos são referenciados através das mensagens de controle, as DIIs, o decodificador precisa primeiro consultar essa mensagem para encontrar o módulo desejado. Essa é a função do ConnBinder do BIOP Profile Body: fornecer informações ao decodificador sobre onde se encontra a DII que indica onde está o módulo que contem o objeto desejado.
Para se encontrar a DII referente ao módulo procurado, o demultiplexador precisa encontrar o fluxo elementar onde a mesma está sendo difundida. Como um fluxo elementar é referenciado através do valor do PID dos pacotes que o transporta, conhecendo-se de antemão qual o PID do fluxo que transporta a DII é suficiente. Porém, a geração do carrossel de objetos geralmente é um processo anterior e independente do processo de multiplexação. Em alguns casos, o multiplexador altera os valores dos PIDs dos pacotes de entrada, ou seja, o fluxo de transporte resultante possui fluxos elementares com PIDs diferentes dos originais. Dessa forma, caso o ConnBinder referencie determinada DII através do PID na qual ela se encontra, o multiplexador ao alterar esse valor deve alterar também o valor referenciado pelo ConnBinder. Essa abordagem não é adotada devido à sua complexidade, pois o multiplexador necessitaria estar apto a manipular estruturas de mais alto nível que as definidas pelo MPEG-2 Systems. Esse problema é resolvido através de estruturas denominadas Taps no ConnBinder.
Um Tap contém três campos de maior importância para a localização de uma DII: o carouselId, o association tag e o transactionId. O carouselId serve para referenciar a PMT que contém em sua lista de fluxos elementares o fluxo que transporta a DII. Na PMT em questão deve haver um descritor no campo informações de programa, conhecido como carouselId descriptor, que deve conter o mesmo valor referenciado pelo Tap de forma que o set-top boxidentifique corretamente a PMT.
O association tag referencia indiretamente o fluxo elementar que transporta a DII em questão. Para que o fluxo possa ser encontrado, é necessário a inserção de um descritor no loop de descritores do fluxo da PMT. Esse descritor é conhecido como association tag descriptor, e contém o mesmo valor referenciado pelo association tagdo Tap. Dessa forma, o set-top box pode localizar o fluxo elementar que transporta a DII consultando a lista de fluxos da PMT a procura do mesmo valor do association tag informado pelo Tap. Para se identificar qual a DII entre as várias que podem ser transmitidas em um mesmo fluxo elementar é utilizado por fim o transactionIdfornecido pela Tap, que deve ser o mesmo apresentado pelo cabeçalho da DII. A Figura 13 ilustra como através da Tap é possível localizar uma DII.

Gráfico 6
Fig. 14 – Resolução de um objeto em um BIOP Profile Body.

Localizada a DII, o módulo contendo o objeto desejado é também referenciado através de uma Tap presente nessa. Assim, o fluxo contendo as DDBs que carregam o módulo são encontradas de forma semelhante a utilizada para encontrar a DII. O objeto alvo é então localizado dentro do módulo através de seu objectKey. A Figura 14 ilustra esse processo.
Para iniciar a decodificação de um carrossel de objetos, o set-top box deve primeiro encontrar o objeto que corresponde ao diretório raiz do carrosel, o Service Gateway. De forma a facilitar a localização desse objeto, a IOR que o referencia é transportada em uma DSI. Isso se deve ao fato de que, para o carrossel de dados, as PSIs apontam para o fluxo elementar que contém a DSI, já que essa é a mensagem de controle de maior nível desse protocolo e deve ser a primeira a ser localizada.

Comparação entre os Mecanismos de Datacasting
Dadas as classificações dos dados apresentadas no início desse artigo, a Tabela 1 mostra a matriz de seleção proposta para o emprego do mecanismo de datacasting de acordo com o tipo dos dados e seus requisitos temporais.

Gráfico 6
Tab. 1 –  Matriz de recomendação do mecanismo de datacasting de acordo com o tipo de dado a ser difundido e seus requisitos temporais.

Como mostrado na Tabela 1, os carrosséis são preferidos para a difusão de dados delimitados, visto que os mesmos partem do princípio que os dados são estruturados em módulos ou objetos. Já para o envio de dados não delimitados síncronos e sincronizados, a melhor opção é através de encapsulamento em PES.
O MPE é a escolha natural quando se deseja difundir dados em datagramas, visto que esse protocolo foi desenvolvido justamente com a finalidade de atender esse propósito. Quando a difusão de datagramas passa a ser síncrona ou sincronizada, o mecanismo preferido passa a ser através das PES. Porém, é possível a implementação de aplicações de datacastig de datagramas síncronos e sincronizados via MPE, mas nesse caso, as estruturas de controle de sincronização são dependentes da implementação.
O data piping não foi incluído na seleção apresentada pela Tabela 1. Isso se deve ao fato de que os requisitos que os dados difundidos possuem, no caso dessa solução, devem ser atendidos geralmente de forma proprietária, já que o data piping não possuí recursos nativos de identificação de dados nem sincronização.
O carrossel de objetos apresenta algumas desvantagens. A maior delas é a falta de um mecanismo de endereçamento de terminais de acesso inerente ao protocolo utilizado na transmissão. Essa não é uma desvantagem, por exemplo, de mecanismos de datacasting baseados na difusão de datagramas IP via MPE.
Os carrosséis não possuem mecanismos de sincronização a nível do próprio protocolo de transmissão de dados. Assim como as MPE, nesse caso, possuem desvantagem em relação ao datacasting via PES, que carrega nas próprias mensagens de dados estampilhas de tempo com relação aos instantes de decodificação e apresentação desejados. Por sua vez, os carrosséis de objetos podem ser sincronizados com outros elementos do serviço do qual pertencem através do uso de outras estruturas, como por exemplo, através de tabelas de sinalização.

Considerações Finais
A adoção de padrões abertos nos sistemas de Televisão Digital terrestre recentemente, deu origem a várias oportunidades de pesquisas. Grande parte delas diz respeito a uma das principais características da televisão digital: a possibilidade de se difundir dados no mesmo meio de transporte utilizado pela programação audiovisual normal. Essa propriedade é conhecida como Data Broadcasting, ou simplesmente datacasting. Especificações já estabelecidas e adotadas pelos três principais sistemas de televisão digital fornecem diversos mecanismos de suporte ao datacasting. O MPEG-2 Systems, adotado pelos três, possibilita a difusão de informações tanto fortemente sincronizadas com a programação normal (fortemente acopladas) como o envio de informações totalmente independentes dessa (não-acopladas). Assim, o datacasting pode ter por finalidade tanto agregar valor aos programas televisivos das emissoras bem como disponibilizar serviços tanto para instituições públicas como privadas.
Independente de qual finalidade, o datacasting passa a ter importância fundamental em arquiteturas e modelos de sistemas de televisão digital.
Este artigo fez um levantamento dos principais mecanismos que possibilitam o datacasting em sistemas de TV digital.

Os  Autores
Carlos Piccioni é pós-graduado em Engenharia Elétrica pela Universidade Federal de Santa Catarina (UFSC).
Carlos Montez é do departamento de automação e sistemas, em Florianópolis, Santa Catarina.

e-mail: [email protected][email protected]

Referência
L. Staffans. Internet protocol datacasting, a technology overview. Master’s thesis, Helsinki University of Technology, 2004.
Tektronix. A Guide to MPEG Fundamentals and Protocol Analysis, 2002. URLhttp://www.tek.com/Measurement/App_Notes/25_11418/eng/ 25W_11418_4.pdf.
European Telecommunications Standards Institute. Digital Video Broadcasting: Implementation guidelines for Data Broadcasting, 2003. ETSI TR 101 202.
G. Zhiqi, Y. Songyu, and Z. Wenjun. Using object multiplex technique in data broadcast on digital CATV channel. IEEE Transactions on Broadcasting, 50(2):113– 119, Jun. 2004.
D. Catapano et. al. DTV data broadcasting: Opportunities and experiences. Technical report, Triveni Digital Inc., Harris Corporation, 2003.
S. Bushholz, A. Schill, e T. Ziegert. A simulation study of update techniques for cyclic data broadcast. In 4th ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems, pages 115–122, Rome, Italy, Jul. 2001.
G. Thomas. ATSC Datacasting: Opportunities and challenges. In NAB2000 Broadcasting Eng. Conf., Apr. 2002.
E.A. Heredia. Optimal object allocation for multimedia broadcast. In Int. Conf. Acoustics, Speech, and Signal Processing, pages 3717–3720, May 1998.
E.M. Schwalb. iTV Handbook: Technologies and Standards. Prentice Hall PTR, 2003.
European Telecommunications Standards Institute. Digital Video Broadcasting: Multimedia Home Platform Specification 1.0.3, 2003. ETSI ES 201 812 V1.1.1.
S. Morris. Mhp interactive, 2005. URL http://www.interactivetvweb.org/tutorial/mhp/index.shtml. Último acesso em 26 de janeiro.
Moving Picture Experts Group. The MPEG home page, 2005. URL http://www.chiariglione.org/mpeg. Último acesso em 27 de janeiro.
International Organization for Standardization. Coding of Moving Pictures and Associated Audio -MPEG-2 Systems, 2000. ISO/IEC 13818-1.
G. Fairhurst. Data transmission using MPEG-2 and DVB, 2005. URL http://www.erg.abdn.ac.uk/research/future-net/digital-video/ dsm-cc.html. Último acesso em 27 de janeiro.
International Organization for Standardization. Coding of Moving Pictures and Associated Audio -Extension for Digital Storage Media Command and Controls, 1996. ISO/IEC 13818-6.
Object Management Group, 2005. URL http://www.omg.org. Último acesso em 27 de janeiro.
ATSC Implementation Subcommittee Informational Document. Implementation of data broadcasting in a DTV station. Technical report, Advanced Television Systems Committee, 1999.
Advanced Television Systems Committee. ATSC Recommended Guidelines for the ATSC Data Broadcasting Standard, 2001. ATSC A/91.