UNIVERSIDADE FEDERAL FLUMINENSE
MAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EM
SISTEMAS DE TV DIGITAL
Niterói
2010
MAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EM
SISTEMAS DE TV DIGITAL
Trabalho de Conclusão de Curso subme-tido ao Curso de Tecnologia em Siste-mas de Computação da Universidade Federal Fluminense como requisito par-cial para obtenção do título de Tecnólo-go em Sistemas de Computação.
Orientador:
Leandro Soares de Sousa
NITERÓI
2010
MAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EM
SISTEMAS DE TV DIGITAL
Trabalho de Conclusão de Curso subme-tido ao Curso de Tecnologia em Siste-mas de Computação da Universidade Federal Fluminense como requisito par-cial para obtenção do título de Tecnólo-go em Sistemas de Computação.
Niterói, ___ de _______________ de 2010. Banca Examinadora:
_________________________________________ Prof. Leandro Soares de Sousa, Msc. – Orientador
UFF - Universidade Federal Fluminense _________________________________________
Prof. Cristiano Grijó Pitangui, Msc. – Avaliador UFRJ – Universidade Federal do Rio de Janeiro
Dedico este trabalho aos meus pais, minha irmã e, em especial, à minha esposa.
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-nhada.
A meu Orientador Prof. Leandro Soares de Sousa pelo estímulo e atenção que me con-cedeu durante este projeto.
A todos os meus familiares e amigos pelo apoio e colaboração.
“A mente que se abre a uma nova idéia ja-mais voltará ao seu tamanho original”
RESUMO
Este trabalho apresenta um estudo sobre o processo de transporte de dados no sis-tema brasileiro de TV digital. Isto inclui a construção do fluxo de transporte, divisão dos fluxos elementares em pacotes PES, bem como a multiplexação dos demais flu-xos em um único fluxo principal. Além disso, o texto discute como as bases tempo-rais podem ser manipuladas pelos gerenciadores de aplicações de TV digital sem perda no sincronismo intermídia, incluindo as aplicações interativas. Este trabalho também discute questões importantes sobre o processo de modulação e codificação dos dados transmitidos. Complementarmente, são feitos testes de multiplexação e geração de pacotes nulos e análise do fluxo de transporte em baixo nível.
Palavras-chaves: TV Digital, MPEG-4, Ginga, NCL, SBTVD, Transport Stream, Normal Play Time, Packetized Elementary Stream, DSM-CC, BST-OFDM .
LISTA DE ILUSTRAÇÕES
Figura 1: Diagrama de Codificação MPEG-4...25
Figura 2: Diagrama de Decodificação MPEG-4...25
Figura 3: Ambiente de Desenvolvimento: Sony Vegas Pro 9 ®...26
Figura 4: Diagrama de Construção de um Fluxo de Transporte TS...27
Figura 5: Encapsulamento do fluxo elementar e de pacotes PES (Björkqvist, 2004). 28 Figura 6: Representação dos Campos Obrigatórios do Cabeçalho PES...28
Figura 7: Diagrama de Sintaxe do Pacote PES [1]...31
Figura 8: Ferramenta Elecard XMuxer Pro...32
Figura 9: Representação da Estrutura de um TS...34
Figura 10: Organização da Tabela PSI [1]...36
Figura 11: Exemplo de uma Base Temporal...37
Figura 12: Conteúdo Principal Concatenado com um Conteúdo Extra (filme + propa-ganda)...38
Figura 13: NPT Associado ao Fluxo Principal e Outro para a Propaganda...38
Figura 14: Ambiente de Desenvolvimento do NPT – NPT Project...39
Figura 15: CARROSSEL DE OBJETOS DSM-CC...42
Figura 16: Sistema de arquivos do Carrossel de Objetos...44
Figura 17: Disposição do Carrossel de Objetos em Módulos...44
Figura 18: Sequência de Transmissão dos Módulos do Carrossel de Objetos...45
Figura 19: Esquema de modulação BST-OFDM...50
Figura 20: Diagrama de Transmissão...51
Figura 21: Fabricado pela EITV do Brasil. Vistas Frontal e Traseira...53
Figura 22: Funções do EITV Playout Professional [22]...56
Figura 23: Lista de PID do pacote TS...59
Figura 24: Análise em Baixo Nível do Primeiro Pacote PES...60
Figura 25: Análise em Baixo Nível do Segundo Pacote PES...61
LISTA DE TABELAS
Tabela 1: Descrição do Cabeçalho PES [1]...29
Tabela 2: Informação de Especificação do Programa [1]...35
Tabela 3: Descrição do Conteúdo NPT...40
Tabela 4: Exemplo de um Objeto de Eventos DSM-CC...47
LISTA DE GRÁFICOS
LISTA DE ABREVIATURAS E SIGLAS
ASI...55 BST-OFDM...47 CAT...34 DSM-CC...19, 42 ESCR...30 FDM...48 FTP...55 HDTV...49 HE-AAC...18 HTML...42 IPTV...40 ISDB-T...17 ISI...51 MPEG...18 NCL...19 NIT...34 NPT...36 PAT...34 PCR...34 PDA...48 PES...16 PMT...34 PTS...55 PUC-Rio...19 QAM...47 RDS...17 SBTVD...15, 17 SDTV...49SFN...49 STVD...33 TDM...27 TMCC...54 TS...15 UFPB...19 URL...43 UTC...54 XML...55
SUMÁRIO
1 INTRODUÇÃO ... 15
2 ASPECTOS GERAIS DO SISTEMA DE TELEVISÃO DIGITAL NO BRASIL ... 17
3 DESENVOLVIMENTO ... 20
4 ANÁLISE E INTERPRETAÇÃO DOS DADOS ... 57
5 CONCLUSÃO ... 64
1 INTRODUÇÃO
O Sistema Brasileiro de TV Digital Terrestre (SBTVD) oferece suporte a aplicações contendo mídias de alta qualidade, com recursos de sincronismo e intera-tividade. Cada conteúdo, incluindo essas mídias e as especificações das aplicações, pode ser transportado através de um único fluxo, chamado de fluxo de transporte ou TS (Transport Stream) [1].
As mídias de natureza contínua, como o áudio e o vídeo, representam o conteúdo audiovisual da TV, são normalmente transmitidas através de fluxos indivi-duais. As especificações das aplicações e as mídias de natureza discreta, como imagens e textos, também podem ser transmitidas individualmente, mas, normal-mente, são transmitidas em um único fluxo. Para realizar a transmissão final, todos os fluxos intermediários devem ser multiplexados em um fluxo único que será trans-mitido por difusão. Para especificar esse fluxo final devemos levar em consideração uma série de detalhes que serão analisados neste trabalho. Essa análise tem o obje-tivo de encontrar uma boa configuração em relação à taxa de transmissão, à com-pactação e compressão das mídias transmitidas e, se possível, à especificação do sincronismo das mídias.
A principal motivação para estudo deste tema vem do fato de que atual-mente somam-se aproximadaatual-mente 60 milhões de televisores no Brasil que, para acessar o sistema digital, deverão ser trocados ou ligados através de conversores digitais também chamados de set-top-box. Esses conversores necessitam de um sistema eficaz que disponibilize ao usuário todas as potencialidades que a TV digital pode proporcionar.
O áudio e do vídeo que formam o conteúdo audiovisual principal da TV, podem ser gerados a partir de uma taxa qualquer. A partir da especificação dessa taxa, os quadros do vídeo, ou as amostras do áudio são distribuídos no fluxo. Se o valor da taxa for menor do que aquele necessário para a exibição do vídeo ou do áu-dio, partes dessas mídias deverão ser descartadas. Por outro lado, se a taxa for
mai-or do que a necessária, partes com nenhuma infmai-ormação relevante são adicionadas ao PES, distribuídas entre os quadros de vídeo ou amostras de áudio. A especifica-ção da taxa usualmente depende das características das informações audiovisuais, sobretudo em relação ao vídeo, uma vez que o tamanho dessa mídia sobrepõe a im-portância do áudio. Entre essas características podem ser citadas o tamanho dos quadros, sua taxa e a resolução adotada. Independente dessas características, a banda disponível para transmissão representa uma limitação importante que deve ser obedecida na especificação da taxa.
A construção de fluxos para o conteúdo audiovisual principal pode ser re-alizada por algumas ferramentas onde diversas configurações podem ser adotadas, tanto em relação às características das mídias (áudio e vídeo) quanto da taxa para transmissão. As configurações adequadas podem variar inclusive de acordo com o conteúdo do áudio e vídeo. Vídeos com menos movimentos, como aqueles obtidos a partir de ambientes de estúdio, podem exigir uma taxa menor para as mesmas ca-racterísticas de qualidade em relação aos vídeos com maiores movimentos, como fil-magens de esportes. Sendo assim, um trabalho com o foco voltado para o nestes detalhes da transmissão de dados no sistema da televisão digital pode ser uma boa contribuição para o desenvolvimento destes sistemas.
Outro fator motivador dos trabalhos direcionados para essa área é a gran-de combinação gran-de ajustes possíveis a fim gran-de encontrar uma configuração igran-deal para o sistema. Isto exige um estudo detalhado das etapas inerentes ao processo de transmissão no sistema de TV digital brasileiro.
Este trabalho foi organizado da seguinte forma: No Capítulo 2 serão abor-dados os aspectos gerais do Sistema de Televisão Digital no Brasil. No Capítulo 3 o foco estará voltado para a transmissão. Nesse capítulo serão apresentados detalhes sobre a construção do fluxo de transporte, codificação, divisão em pacotes PES (Packetized Elementary Stream) [2], multiplexação, sincronismo, carrossel de dados e taxa de transmissão do conteúdo audiovisual e dados. No Capítulo 4, são apresen-tadas uma análise e interpretação dos dados obtidos em simulações de transmissão. Finalmente, o Capítulo 5 discorre sobre a conclusão e os possíveis trabalhos futuros.
2 ASPECTOS GERAIS DO SISTEMA DE TELEVISÃO
DIGI-TAL NO BRASIL
O Sistema Brasileiro de TV Digital Terrestre (SBTVD) foi desenvolvido com base no sistema japonês denominado Integrated Services Digital Broadcasting
Terrestrial (ISDB-T), incorporando algumas facilidades que o destacam em relação
aos principais sistemas de TV digital atualmente em funcionamento no mundo. Entre os diferenciais do SBTVD merece ser destacado o “casamento” entre a base técnica de transmissão do sistema japonês com os padrões de compressão digital de áudio e vídeo [3], que serão detalhados nas seções seguintes [4]. Assim, o sistema brasi-leiro permite a transmissão de conteúdo de alta qualidade, tanto em termos do con-teúdo de áudio como do concon-teúdo de vídeo, que pode, inclusive, ser recebido e apresentado em dispositivos móveis e portáteis.
Além da alta qualidade das mídias e da facilidade de recepção, outra van-tagem dos sistemas de TV digital em relação aos sistemas analógicos é o tratamen-to que eles oferecem para outros dados, permitindo que, além do conteúdo audiovi-sual principal, outras mídias e até aplicações completas possam ser transmitidas e executadas nos clientes. Nos sistemas analógicos é possível o transporte de dados tanto em sistemas de TV quanto em sistemas de rádios. Como exemplos, podem ser citados o serviço de legendas (Close Caption) para TV e o RDS (Radio Data
Sys-tem) para rádio, que oferece informações sobre a estação de rádio sintonizada,
incluindo o nome da rádio, tipo de programação, etc. Contudo, devido a restrições técnicas do sistema analógico, enriquecer a programação ou difundir dados indepen-dentes, torna-se um objetivo restrito a poucas aplicações.
Nos sistemas de TV digital, todas as informações podem ser codificadas e transmitidas sem depender do tipo dessa informação. Através da transmissão de da-dos, aplicações podem ser difundidas até o aparelho televisor ou receptor, servindo como base para os sistemas interativos. É possível, inclusive, que dados indepen-dentes da programação da emissora sejam recebidos nos clientes, o que possibilita a apresentação de diversas aplicações, além daquelas voltadas apenas ao entrete-nimento.
As principais diferenças do SBTVD, em relação aos demais sistemas, in-cluem os formatos para codificação e especificação das aplicações. O SBTVD ado-tou o padrão MPEG-4 [5], também conhecido como H.264 [6], para codificação de vídeo, e o HE-AAC v2 [6] para o áudio, com possibilidade de adaptação para dife-rentes perfis e níveis. Esses padrões permitem a transmissão de vídeo e áudio com alta qualidade através de uma banda com largura limitada. Complementarmente, as aplicações no SBTVD permitem especificar o sincronismo, o formato da apresenta-ção e a interatividade das mídias que serão apresentadas.
Em relação à transmissão, como mencionado, as mídias de natureza con-tínua, como o áudio e vídeo que representam os conteúdos de áudio e vídeo da TV, são normalmente transmitidas através de fluxos individuais, chamados de fluxos ele-mentares. Seguindo a especificação MPEG-2 Sistemas, utilizada na especificação da transmissão, cada fluxo elementar é dividido em diversos pacotes denominados PES (Packetized Elementary Stream) [1], que por sua vez, são multiplexados e po-dem vir a gerar um único fluxo de transporte (Transport Stream) [1]. É esse o fluxo que será modulado e enviado por difusão aos clientes.
As especificações das aplicações e as mídias de natureza discreta, como imagens e textos, como mencionado, podem fazer parte, cada um, de um único flu-xo, porém, todos esses conteúdos são normalmente transmitidos em conjunto atra-vés de um único fluxo elementar, que deve ser multiplexado junto aos demais fluxos definidos pela estação transmissora, formando o fluxo de transporte.
As aplicações e as mídias multiplexadas junto aos fluxos elementares do áudio e vídeo principal podem ser sincronizadas de diferentes formas. Uma legenda, por exemplo, deve estar sempre sincronizada com o filme, isto é, se o telespectador começa a ver o filme durante a sua exibição, as legendas passadas são desneces-sárias. Por outro lado, uma aplicação que exibe a sinopse de um filme (um conteúdo audiovisual) poderia ser útil durante toda a sua exibição. Essa aplicação é assíncro-na em relação à exibição do conteúdo audiovisual do filme. Nesse ponto, uma ques-tão importante é como o sistema de transporte pode gerenciar diferentes requisitos de sincronismo multiplexados em um único fluxo.
Para os conteúdos de mídia que usam a mesma base de tempo, o sincro-nismo entre os fluxos pode ser especificado através de selos de tempo (timestamps) [1]. Essa é a estratégia utilizada para exibição do áudio e vídeo principais. Cada
par-te do áudio é sincronizada dessa forma com uma parpar-te do vídeo. Por outro lado, para os conteúdos assíncronos, a especificação do sincronismo deve ser enviada juntamente com os conteúdos a serem sincronizados. Essa especificação torna-se mais uma mídia no conjunto dos conteúdos transmitidos.
Os conteúdos assíncronos em relação ao conteúdo audiovisual principal devem estar disponíveis nos clientes durante todo o período da transmissão desse conteúdo audiovisual. Para isso, esses conteúdos são transmitidos de forma cíclica, em um carrossel, durante todo o período necessário, seguindo a especificação de uma outra parte do padrão MPEG-2, conhecido como DSM-CC (Digital Storage
Media – Command and Control). Essa forma de transmissão necessita ser
geren-ciada, para que apenas os conteúdos necessários em certo momento temporal este-jam posicionados no carrossel. Essa gerência é necessária, principalmente devido ao fato de, nos sistemas de TV, a largura de banda compartilhada para a transmis-são de todo o conteúdo ser limitada.
2.1 O MIDDLEWARE GINGA
Para que a emissora de TV, neste contexto chamada de provedor de con-teúdo, possa difundir as aplicações interativas aos receptores, pode ser interessante que exista um componente intermediário responsável pela comunicação entre o hardware que compõe os receptores e as aplicações interativas. Esse componente é chamado de middleware. No Sistema Brasileiro de TV Digital Terrestre (SBTVD) o
middleware proposto foi denominado Ginga [7], sendo desenvolvido através de uma
parceria entre a Universidade Federal da Paraíba (UFPB) e Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio).
O Ginga é um middleware aberto, isto é, seu código está disponível e pode ser livremente utilizado para fins não comerciais. Ele pode ser dividido em dois subsistemas principais, Ginga-J e Ginga-NCL. O Ginga-J [8], desenvolvido pela UFPB, é uma máquina de execução responsável por oferecer suporte às aplicações especificadas através da linguagem Java [9]. O Ginga-NCL, desenvolvido pela PUC-Rio, possui a infra-estrutura necessária para apresentar as aplicações declarativas
escritas na linguagem NCL (Nested Context Language) [10]. Há ainda o Ginga-CC (Ginga Common Core) que é responsável por prover recursos de infra-estrutura a ambos os subsistemas Ginga-J e o Ginga-NCL.[11].
O Ginga-NCL, como mencionado, oferece suporte a NCL, uma linguagem declarativa para autoria de documentos hipermídia1. Linguagens declarativas
favore-cem a descrição em alto nível das aplicações, isto é, através dessas linguagens usu-almente deve-se especificar o comportamento esperado da aplicação, ao invés de fornecer detalhes de sua implementação (algoritmo), como é feito através das lin-guagens baseadas em Java. Assim, as linlin-guagens declarativas são mais intuitivas e, portanto, mais fáceis de usar do que as imperativas, que normalmente requerem que o autor seja um programador com conhecimento da linguagem.
As aplicações declarativas no Ginga-NCL devem ser especificadas atra-vés de um documento NCL. Nesse documento, os relacionamentos entre as mídias que fazem parte da aplicação são definidos através de elos e conectores hipermídia. As possibilidades de especificação das aplicações através dessa linguagem serão abordadas na Seção 3.2.4.
3 DESENVOLVIMENTO
Neste Capítulo aborda-se, inicialmente, na Seção 3.1 a importância da compressão de dados na TV digital, cuja banda de transmissão é escassa e o
volu-1 Várias mídias sincronizadas no tempo e espaço onde eventos imprevisíveis e adaptações (outro
me de dados transmitidos aumentou consideravelmente em relação aos sistemas analógicos. Na Seção 3.2 os pacotes elementares estarão em evidência e alguns conceitos importantes para a compreensão dos demais itens deste trabalho. As Se-ções subseqüentes detalham os principais aspectos e particularidades de toda a cri-ação do conteúdo que será enviado através da antena transmissora.
3.1 COMPRESSÃO DE DADOS
Uma câmera de vídeo de alta definição (1920 x 1080 pixels2) no padrão
brasileiro gera um sinal de vídeo a 1 Gbps que precisa ser comprimido para não desperdiçar a largura de banda de canal. Como os dados contidos nesse sinal são, em parte, redundantes, a compressão é razoavelmente eficiente, dependendo do tipo de cena. Uma cena com pouca movimentação, não se altera com a sucessão de muitos dos quadros e, normalmente, pode ser comprimida sem perda de qualidade perceptível à visão humana.
No processo de compressão pretende-se representar os dados originais, com a menor quantidade de dados possível, para um determinado nível de qualida-de. Para isso, exploram-se as redundâncias temporais e espaciais do vídeo que será transmitido, otimizando dessa forma, o uso da largura de banda do canal, que é de 6 MHz. Isto pode ser obtido porque os pixels não são independentes, mas estão rela-cionados com seus vizinhos, tanto do mesmo quadro (redundância espacial) quanto entre quadros consecutivos (redundância temporal). Dessa forma, o valor do pixel pode ser predito a partir dos valores vizinhos, assim como regiões de um quadro fu-turo podem ser preditas a partir do quadro atual.
Entre o áudio e o vídeo, o segundo é mais relevante do ponto de vista do armazenamento e da transmissão, tendo em vista a grande quantidade de informa-ções que pode ser gerada em um curto espaço de tempo, dependendo da qualidade adotada. Conforme introduzido nas seções anteriores, o Sistema Brasileiro de TV
gital Terrestre (SBTVDT) utiliza o MPEG-4 para a codificação de vídeo, que será re-sumidamente descrito na subseção seguinte.
3.1.1 O PADRÃO MPEG-4
O grupo Moving Picture Expert Group ou, simplesmente, MPEG é um gru-po da ISO (International Standards Organization) [12], que tem como objetivo princi-pal a especificação de padrões destinados à codificação de áudio e vídeo.
Entre os padrões MPEG, o MPEG-4 tornou-se oficialmente um padrão internacional no começo de 2000, após uma primeira versão oficial finalizada em outubro de 1998 e publicada nos primeiros meses de 1999. Esse padrão é dividido em várias partes, das quais merecem ser destacadas, em relação aos sistemas de TV digital, as seguintes partes:
1 – Parte 1 – Sistemas; 2 – Parte 2 – Visual; 3 – Parte 3 – Áudio; e
4 – Parte 10 - Codificação Avançada de Vídeo. (as demais partes não serão abordadas pois não fazem parte do escopo deste trabalho. Informações adicionais podem ser obtidas nos padrões ISO/IEC 14496.)
Todas as partes mencionadas relacionam-se diretamente com a condificação do áudio, do vídeo e dos demais objetos, inclusive aplicações, que podem fazer parte do conteúdo de um sistema de TV digital. No entanto, em termos da codificação do vídeo, a Parte 10 merece ser destacada por representar as melhorias do 4 em relação aos padrões anteriores, particularmente o MPEG-2.
Apesar do MPEG-4, em sua segunda versão, ter sido publicado no começo de 2000, sua Parte 10 surgiu algum tempo depois, a partir da junção dos trabalhos da ISO como o ITU-T (International Telecommunication Union). Em 2001, o grupo MPEG reconheceu os esforços do grupo de trabalho H.26L do ITU, principalmente em relação ao padrão H.263 [13] e, a partir de então, os trabalhos dos dois grupos caminharam juntos. Como resultado foram obtidos dois padrões
idênticos, o MPEG-4 Parte 10 e o ITU-T H.264, ambos genericamente conhecidos como AVC (Advanced Video Coding).
No MPEG-4, de forma similar aos padrões MPEG e ITU anteriores, voltados à codificação de vídeo, um quadro do vídeo a ser codificado é dividido em macroblocos, formados por um bloco (parte espacial da imagem) relativo à informação da luminância (informação sobre a luz da quadro) e por dois blocos relativos à informação da crominância (informação sobre a cor do quadro). Cada bloco pode ser codificado usando apenas a informação do próprio quadro. Nessa codificação, as informações redundantes existentes no quadro não são codificadas e assim, menos informação é gerada. Quadros em que os macroblocos são codificados dessa forma são chamados de quadros I.
Um macrobloco também pode ser codificado de forma preditiva, usando informações existentes em blocos de quadros passados e de quadros futuros da sequência de um vídeo. Quando a predição é feita baseada em um quadro passado, no bloco codificado do quadro atual apenas a informação do erro de predição é codificada, isto é, a diferença entre o bloco do quadro codificado e do bloco do quadro de referência. Também deve ser codificada a informação a respeito do vetor de referência, que indica a localização no quadro de referência do bloco predito. Quadros com blocos contendo esse tipo de codificação são chamados de quadros P. Quando a codificação, além do quadro anterior, também envolve quadros posteriores, os quadros codificados são chamados de quadros B.
No MPEG-4 Parte 10 os blocos podem ter tamanhos variados. A predição intraquadros pode usar blocos de tamanho 16x16 ou 4x4. A predição interquadros pode usar quadros de tamanho 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 ou 4x4. A predição de cada macrobloco pode ser baseada em um ou dois quadros quaisquer, passados ou futuros, que já foram codificados. Quando o movimento da cena é periódico, essa abordagem podem obter um alto índice de compressão.
Os blocos, após serem preditos, sofrem a ação de duas transformadas: a transformada discreta de cossenos3 e a transformada de hadamard4. Essas
transformadas inteiras são importantes para distribuir as informações do quadro, originalmente no domínio espacial, para o domínio da frequência. Informações representadas por frequências próximas podem ser novamente comprimidas, obtendo, como resultado, menos informação para um mesmo quadro.
Os valores discretos obtidos após a aplicação das transformadas são convertidos em códigos binários compactados através de codificação por carreira e aritmética5. A Erro: Origem da referência não encontrada apresenta, resumidamente,
os módulos utilizados na codificação do MPEG-4. A estrutura básica de codificação envolve a codificação de forma (shape coding) e a Transformada Discreta dos Cossenos DCT bem como a compensação de movimento. Uma importante vantagem da codificação MPEG-4 é que a eficiência da compressão pode ser consideravelmente melhorada para alguns videos utilizando ferramentas dedicadas e apropriadas de predição de movimento. (motion prediction) para cada objeto na cena.
A Erro: Origem da referência não encontrada, complementarmente, apresenta os módulos utilizados na decodificação MPEG-4. Não nos deteremos nos aspéctos mais detalhados da implementação por não fazer parte do escopo deste trabalho. Maiores informações podem ser encontradas em www.iso.org (ISO/IEC 14496-2, 2004).
3 http://www2.unoeste.br/~chico/monografia_francisco.pdf 4 http://math.uoregon.edu/alumni/theses/merchant.pdf 5 http://www.michael-maniscalco.com/papers/rle-exp.pdf
Figura 1: Diagrama de Codificação MPEG-4.
3.2 O FLUXO DE TRANSPORTE (TRANSPORT STREAM)
Algumas ferramentas podem ser utilizadas para realizar a codificação das mídias e para construir o fluxo de transporte. Neste trabalho, a edição do áudio e do vídeo foi realizada através do Sony Vegas Pro 9 [14], por ser uma ferramenta que permite editar e codificar o vídeo e o áudio nos formatos do SBTVD (AAC/H.264). A interface do programa é apresentada na Erro: Origem da referência não encontrada.
Figura 3: Ambiente de Desenvolvimento: Sony Vegas Pro 9 ®.
Além da codificação do conteúdo audiovisual, o Sony Vegas pode gerar um fluxo de transporte (Transport Stream - TS) como resultado da multiplexação
sín-crona do áudio e do vídeo. Como mencionado, o TS é formado por fluxos elementa-res, que, por sua vez, são formados por vários pacotes PES, que serão descritos a seguir. A Erro: Origem da referência não encontrada mostra o esquema de criação do TS gerado, por exemplo, através do Sony Vegas. O áudio e o vídeo são individu-almente empacotados em vários PES, que formam um fluxo elementar para o áudio e outro para o vídeo. Um TS é então construído através do processo de multiplexa-ção por divisão de tempo (TDM) dos pacotes de fluxo elementar PES. O TS resul-tante pode ser transmitido para apresentação. É interessante mencionar que o TS pode ser decodificado em qualquer ponto, característica desejável para transmissão em broadcast com acesso às aplicações de forma aleatória no tempo.
Figura 4: Diagrama de Construção de um Fluxo de Transporte TS.
3.2.1 PES (PACKETIZED ELEMENTARY STREAM)
PES em um TS são fundamentais para facilitar seu manuseio, oferecer proteção contra erros e também para habilitar o acesso aleatório, isto é, em qualquer ponto de um TS [2]. Cada PES é formado por um cabeçalho e uma carga útil. Esse processo é conhecido como empacotamento ou encapsulamento. O tamanho dos PES pode ser ajustado, mas normalmente, é configurado com 188 bytes. A Erro: Origem da referência não encontrada apresenta um esquema de encapsulamento de fluxos elementares em pacotes PES e de pacotes PES em TS.
Figura 5: Encapsulamento do fluxo elementar e de pacotes PES (Björkqvist, 2004).
A carga útil dos pacotes PES inclui os dados do fluxo elementar. A infor-mação no cabeçalho PES começa com um código de prefixo de 24 bits para indicar o início de um novo pacote, seguido por 8 bits de identificação (fluxo ID) desse PES e um campo de 16 bits que informa o tamanho do pacote. A Figura 6 representa essa estrutura.
Figura 6: Representação dos Campos Obrigatórios do Cabeçalho PES.
Os campos da Erro: Origem da referência não encontrada são os princi-pais. Na decodificação, por exemplo, é importante que a partir de um PES o decodi-ficador possa conhecer qual fluxo elementar ele representa, informação existente no
campo fluxoID. Além dos campos da Erro: Origem da referência não encontrada, ou-tros campos opcionais também podem fazer parte de um PES. A definição semânti-ca desses semânti-campos é descrita na Erro: Origem da referência não encontrada:
Tabela 1: Descrição do Cabeçalho PES [1].
Campo PES Descrição
Packet_Start _Code_
Prefix
O Prefixo de Código de Início do Pacote é um código de 24 bits. Juntamente com o Fluxo ID que o segue constitui o código que iden-tifica o início do pacote.
stream_id O Fluxo ID pode informar qualquer valor válido que descreve
corre-tamente o tipo do fluxo elementar.
PES_Packet_ Length
Um campo de 16 bits que especifica o número de bytes no PES se-guinte ao último byte do campo. Um valor 0 indica que o comprimen-to do PES não é especificado e é permitido somente nos PES cuja carga útil consista de bytes de um fluxo elementar de vídeo contido nos pacotes TS.
PES_ scrambling_c
ontrol
O campo de 2 bits o modo embaralhamento do campo de dados do PES. Quando o embaralhamento está ativo no nível do PES, o ca-beçalho do PES não deve ser embaralhado.
PES_priority Este campo de 1 bit indica a prioridade da carga útil contida neste
PES. O bit 1 indica maior prioridade em relação aos que possuem valor zero.
Data_ Alignment _Indicator
Este é um flag de 1 bit. Quando seu valor é 1 indica que o cabeçalho é imediatamente seguido pelo código de início do vídeo.
Campo Descrição
Copyright Campo de 1 bit. Se o seu valor é 1 indica que o material associado à
original_ or_copy
Campo de 1 bit. Se o seu valor é igual a 1 significa que o conteúdo associado à carga útil do PES é original, caso contrário, indica uma cópia.
PTS_DTS _flags
Este é um campo de 2 bits. Quando o valor desse campo é igual a ‘10’, o campo PTS deve ser apresentado no cabeçalho do PES. Se seu valor for igual a ‘11’, tanto o PTS e o DTS devem ser apresenta-dos no cabeçalho do PES. Quando o valor do campo
PTS_DTS_flags for igual a ‘00’ nem o PTS nem o DTS aparecem no
cabeçalho do PES. O valor ‘01’ é proibido
ESCR_flag
Quando este flag de 1 bit possui valor 1 significa que a base ESCR e o campo de extensão são mostrados no cabeçalho PES. Caso contrário indica a ausência do ESCR no cabeçalho PES
ES_rate_flag
Quando este flag de 1 bit possui valor 1 significa que o ES_rate é mostrado no cabeçalho PES. Caso contrário indica a ausência do ES_rate no cabeçalho PES.
A distribuição dos campos no cabeçalho PES pode ser conferida no dia-grama de sintaxe do pacote PES apresentado na Erro: Origem da referência não en-contrada.
Figura 7: Diagrama de Sintaxe do Pacote PES [1].
O Sony Vegas é voltado à codificação direta do conteúdo audiovisual, po-dendo gerar, como mencionado um TS. No entanto, para controlar um TS em deta-lhes, incluindo seus elementos, outra ferramenta, denominada Elecard XMuxer Pro [15], foi utilizada. Essa ferramenta permite que os fluxos elementares de um TS se-jam visualizados. Na verdade, um novo TS pode ser construído através dessa ferra-menta, adicionando ou removendo fluxos elementares. Além disso, pode-se definir a taxa de transmissão desejada. A Erro: Origem da referência não encontrada ilustra o ambiente de desenvolvimento do Elecard XMuxer Pro.
Figura 8: Ferramenta Elecard XMuxer Pro.
3.2.2 PROGRAM STREAM X TRANSPORT STREAM
As informações de cada PES são importantes para o processo de decodificação das informações transmitidas. Porém, para serem transmitidas, essas informações preci-sam ser multiplexadas, como apresentado na Erro: Origem da referência não encon-trada. Duas formas principais para multiplexação são definidas podem gerar, cada uma, um fluxo diferente, o fluxo de programa (program stream) e o fluxo de transpor-te (transport stream).
O fluxo de programa é utilizado para transmissão de apenas um serviço (programa). Um serviço é definido como um conjunto de fluxos elementares que tem
um forte acoplamento temporal. Normalmente, esses fluxos elementares estão sin-cronizados entre si. No fluxo de programa, o tamanho dos pacotes PES são variá-veis, consequentemente, a taxa do fluxo multiplexado é variável. Na decodificação, um fluxo variável pode ser mais difícil de gerenciar, podendo ocorrer facilmente es-touro do buffer ou, ao contrário, o buffer permanecer ocioso durante muito tempo.
Fluxos de programa somente são adequados para aplicações isoladas em ambientes robustos, isto é, que favoreçam a decodificação. Por exemplo, para a construção de mídias de DVD, o fluxo de programa pode ser utilizado.
Nos STVD, por outro lado, existe um ambiente heterogêneo, formado pe-los receptores e também pelas estações repetidoras. Além disso, vários programas diferentes precisam ser transmitidos. Nesse caso, é ideal que o transporte seja reali-zado através de um fluxo com taxa constante e que suporte vários serviços. Para es-ses sistemas, o ideal, portanto, é a utilização do fluxo de transporte.
Em um fluxo de transporte – TS, o tamanho de cada pacote, formado a partir de um conjunto de PES é constante. Dessa forma, também é mais fácil identifi -car o início e o fim do pacote. Cada pacote tem tamanho de 188 bytes, com 4 bytes destinados ao cabeçalho. O início de um pacote é definido através de um byte utili-zado para o sincronismo, que, com o valor 47 em hexadecimal, indica o início do pa-cote. Os três bytes seguintes correspondem a sinalizadores (flags), que podem indicar algum erro no pacote, se o pacote é o primeiro de uma sequência, e qual a prio -ridade do pacote, campo que pode ser utilizado caso seja necessário descartar al-guns pacotes durante a transmissão. O próximo campo, de treze bits, é o identifica-dor de sequência dos pacotes (PID). Cada pacote que carrega o mesmo PID corres-ponde a um mesmo fluxo elementar. A Erro: Origem da referência não encontrada apresenta a estrutura de um TS.
Figura 9: Representação da Estrutura de um TS.
Um TS pode conter vários serviços e, portanto, é necessário identificar cada um dos serviços multiplexados. Assim, além das informações dos serviços, um TS contém também um conjunto de metainformações que permitem identificar cada serviço. As metainformações são denominadas Program Specific Information (PSI), existindo quatro tipos principais:
• Tabela de Associação do Programa (Program Association Table - PAT); • Tabela de Mapa do Programa (Program Map Table - PMT);
• Tabela de Acesso Condicional (Conditional Access Table - CAT); • Tabela de Informação da Rede (Network Information Table – NIT).
Estas tabelas contêm as informações necessárias para demultiplexar e apresentar os programas. A PMT especifica, entre outras informações, os PIDs, e portanto, qual fluxo elementar está associado para formar o programa. Adicionalmente, a PMT indi-ca o PID dos pacotes TS que transportam o PCR6 (Program Clock Reference) de
cada serviço, que é uma informação temporal importante para a decodificação. A CAT só está presente se o embaralhamento for empregado, visando proteger o
teúdo transmitido. A NIT também é opcional e pode conter informações sobre a mo-dulação, operadora de rede e outras relacionadas ao transporte.
Cada tabela PSI tem um identificador PID. Ao contrário dos programas e dos flu-xos elementares estes podem ser embaralhados para acesso condicional às tabelas PSI não devem ser embaralhadas. A Erro: Origem da referência não encontrada re-sume as tabelas PSI. Como estas estruturas podem ser pensadas como simples ta-belas, elas podem ser segmentadas em seções e inseridas nos pacotes TS, alguns com PIDs predeterminados e outros com PIDs que podem ser selecionados pelo usuário [1].
Tabela 2: Informação de Especificação do Programa [1].
Nome da Estrutura Tipo de fluxo Número
do PID Descrição
Tabela de Associação do programa
ITU-T H.222.0 [23] |
ISO/IEC 13818-1 0x00
Número de associação do pro-grama e PID da PMT Tabela de Mapa de Programa ITU-T H.222.0 | ISO/IEC 13818-1 Atribuição indica-da na PAT
Especifica os valores dos PIDs para os progrmas Tabela de
Informação da Rede Privada
Atribuição indica-da na PAT
Parâmetros da rede física tais como frequências FDM, etc. Tabela de Acesso
Condicional
ITU-T H.222.0 |
ISO/IEC 13818-1 0x01
Associa um ou mais fluxos
EMM7 com um único valor PID
Continuando com a descrição das tabelas PSI, a PAT (Program
Association Table) é a responsável por identificar os serviços existentes. Através da
PAT, por exemplo, é possível localizar uma PMT (Program Map Table) que por sua vez contém uma lista de fluxos elementares que pertencem a um mesmo serviço ou programa. A Erro: Origem da referência não encontrada apresenta a organização das tabelas PSI.
7 Entitlement Management Message (EMM): São acessos condicionais privados que especificam e
Figura 10: Organização da Tabela PSI [1].
Ferramentas como Sony Vegas Pro e o Elecard permitem construir um ar-quivo TS relativo ao conteúdo audiovisual principal com todas as informações sobre os PES, cabeçalhos do TS e tabelas PSI. No entanto, no caso de aplicações interati-vas no SBTVD, poderá ser necessário acrescentar outros itens a essa transmissão, como o carrossel de dados, a aplicação NCL e a referência temporal NPT (Normal
Play Time), itens que serão abordados nas próximas seções.
3.2.3 NPT (NORMAL PLAY TIME)
Os exibidores de vídeo ou decodificadores precisam contextualizar os ins-tantes de exibição dos objetos de mídia de acordo com o projeto do provedor de conteúdos. Para isso, pode ser necessária a criação de um fluxo especial que esteja
apto a informar aos exibidores esses instantes contextualizados. Para isso, um fluxo especial deve ser construído, contendo um índice temporal denominado NPT
(Nor-mal Play Time) [11].
Nas aplicações interativas para TV digital é comum que o comportamento da aplicação esteja associado à ocorrência temporal de eventos associados às suas mídias. O conteúdo audiovisual principal é uma dessas mídias e, portanto, o seu tempo deve ser controlado.
O NPT é utilizado para controlar o tempo de um conteúdo transportado a partir de um fluxo elementar. Para exemplificar essa situação, considere um filme que tem seu conteúdo segmentado de tal forma que em cada segmento é associado um rótulo NPT. Esse exemplo é apresentado na Erro: Origem da referência não en-contrada, onde na parte superior o filme é representado em preto. Nesse exemplo, um outro vídeo, equivalente a uma propaganda (um outro fluxo), também possui um NPT associado e é representado na parte inferior da Erro: Origem da referência não encontrada, em azul.
Figura 11: Exemplo de uma Base Temporal.
No exemplo da Erro: Origem da referência não encontrada, uma edição do filme acontece e outro fluxo (propaganda) é inserido em um dado instante. É inte-ressante observar que ao adicionar o conteúdo da propaganda, o novo fluxo resul-tante mantém os rótulos NPT originais. É esse o resultado desejado para que o
sin-cronismo das aplicações seja preservado. A Erro: Origem da referência não encon-trada apresenta o resultado dessa inserção.
Figura 12: Conteúdo Principal Concatenado com um Conteúdo Extra (filme + propaganda).
Além dos valores para temporizar os fluxos, o NPT possui um campo de-nominado “contentId” que serve como uma identidade do NPT. O receptor associa o “contentId” atual à aplicação que foi iniciada. Assim, quando o valor do “contentId” do NPT é alterado, o receptor percebe que a aplicação foi modificada. A retomada de uma base temporal faz com que o conteúdo de uma aplicação associada ao “contentId” volte a ser executada a partir do ponto em que ela foi interrompida. Se uma base temporal não for retomada em um período de tempo, significa que o ciclo de vida da apresentação deste fluxo chegou ao fim [11]. A Erro: Origem da referên-cia não encontrada apresenta os diferentes valores de “contentId” para os fluxos de vídeo do exemplo da Erro: Origem da referência não encontrada.
Figura 13: NPT Associado ao Fluxo Principal e Outro para a Propaganda.
Ao executar um comando de pausa em um fluxo contínuo, sua base tem-poral associada também deve ser pausada. Uma base temtem-poral pode ser pausada e, posteriormente, reiniciada a partir do instante em que foi pausada e, isto normal-mente ocorre aleatorianormal-mente no tempo. Como exemplo, quando o usuário muda o
canal corrente e, em seguida, retorna ao canal anterior, a exibição do conteúdo deve ser retomada a partir de um instante temporal imediatamente posterior àquele em que a apresentação foi interrompida.
O fluxo NPT possui algumas regras para ser utilizado em uma transmis-são. Cada referência temporal deve ser enviada em espaços de tempo de 1 segun-do. Espaços menores resultam numa precisão maior, porém com um custo adicional na largura banda de transmissão. Outra regra é informar ao receptor quando houver mudança na base temporal com antecedência (dois segundos, de acordo com a nor-ma japonesa ARIB TR-B14, 2006). Essa mudança pode ser de “contentId” ou na ve-locidade de reprodução de um conteúdo. [11].
Para gerar uma base temporal NPT, a ferramenta NPT Project pode ser utilizada. Essa ferramenta facilita a construção dos valores de referência (momentos temporais), bem como do “contenId”. A mostra a interface do NPT Project.
Figura 14: Ambiente de Desenvolvimento do NPT – NPT Project.
Todos os valores temporais que compõem um fluxo NPT são transporta-dos em um fluxo elementar através de estruturas chamadas de NPT Reference
Des-criptor [16]. Todas as informações do NPT são resumidas na Erro: Origem da
Tabela 3: Descrição do Conteúdo NPT.
Campo Descrição
content_id Refere-se ao valor do “contentId”;
inicio_tempo_absoluto Indica o tempo de exibição do vídeo, em milissegundos, no local que um conteúdo é iniciado;
fim_tempo_absoluto Indica o tempo de exibição do vídeo, em milissegundos, no local que um conteúdo é finalizado;
inicio_valor_npt Indica o valor NPT inicial, em milissegundos, no local que um conteúdo é iniciado;
Numerador Representa o numerador da taxa com que um conteúdo deve ser reproduzido;
Denominador Representa o denominador da taxa com que um conteúdo deve ser reproduzido. Esse valor não pode ser negativo.
3.2.4 APLICAÇÃO INTERATIVA
O Ginga-NCL realiza a apresentação de aplicações interativas especifica-das em NCL. NCL é uma linguagem declarativa para a especificação especifica-das aplicações nos sistemas de TV digital e também é a linguagem de referência, definida pelo ITU-T, para sistemas IPTV. Ao contrário das linguagens imperativas, como a linguagem Java, que também podem ser utilizadas na especificação das aplicações para TV, a construção de aplicações NCL não exige que o autor seja um programador com ex-periência na especificação através dessa linguagem. Ao contrário, NCL é proposta para que autores relacionados à área de TV possam especificar as aplicações, inclu-indo publicitários, engenheiros, etc.
Através da NCL é possível especificar um objeto, como um vídeo, áudio, texto, etc., que podem estar sendo transmitidos através dos fluxos elementares, como um nó representado pelo elemento <media>.
Cada elemento do documento NCL possui alguns atributos. O elemento <media> possui os atributos id, que define um identificador exclusivo para esse
elemento, src, que define o endereço ou diretório onde se encontra o conteúdo des-se elemento e descriptor, que referencia o descritor que especifica como o objeto deverá ser apresentado. Há ainda outros atributos que não fazem parte do escopo deste trabalho.
Um documento NCL traz a especificação da forma com que os objetos de mídia são estruturados e relacionados no tempo e no espaço. O elemento <area> permite a especificação de âncoras que identificam segmentos do objeto de mídia. Essas âncoras podem ter várias especializações em relação ao conteúdo que se de-seja marcar. Dentre as especializações destacam-se: âncora de texto, espacial, rotu-lada, de intervalo de tempo relativo e de intervalo de amostras. As âncoras de inter-valo permitem descrever um conjunto de unidade de informação dos objetos de mí-dia, e, neste trabalho, o enfoque principal fica por conta deste tipo de âncoras, mais especificamente, âncoras por amostra NPT. Esse tipo de âncora é definido em um documento NCL como um elemento <area>, filho do elemento <media>.
Utilizando os atributos first e last, ou begin e end referentes ao ele-mento <area>, um fluxo NPT pode atuar como referência temporal entre os objetos de uma aplicação. O atributo first determina o início de uma mídia contínua en-quanto o atributo last determina o término da âncora de uma mídia contínua. A Erro: Origem da referência não encontrada mostra um segmento de um código NCL que usa uma base temporal para fazer referência aos objetos. O receptor associa o
“contentId” atual, contido no fluxo NPT, à aplicação que foi iniciada. Como pode ser
observado na Erro: Origem da referência não encontrada, os valores dos atributos first e last das âncoras são definidos com base no valor do NPT.
Figura 15: CARROSSEL DE OBJETOS DSM-CC.
Em um sistema interativo, faz-se necessário algum mecanismo para transportar os arquivos inerentes às aplicações. Estas aplicações são enviadas pela emissora por difusão. O padrão DSM-CC possui os recursos necessários para tornar esta tarefa factível. O DSM-CC não é somente um padrão, mas um pacote completo de proto-colos, incluindo todos os elementos necessários para que um sistema de TV digital funcione de forma adequada. Isto inclui a configuração de rede, o controle de fluxo de mídias, o sincronismo de mídias, o acesso a arquivos em uma ou duas vias, etc. O uso mais comum do DSM-CC é prover acesso a objetos em um servidor remoto. Arquivos e diretórios são tratados como objetos, e clientes podem usar este meca-nismo para manipular estes objetos e acessar seus conteúdos [2].
Uma vez que a sintonização de um canal pode ser realizada em qualquer instante, aplicações que possam ser instanciadas durante qualquer momento do conteúdo audiovisual principal devem ser enviadas ciclicamente. Dessa forma, é ga-rantido o acesso à aplicação pelo usuário telespectador, mesmo que ele tenha de esperar uma “rodada” até que esta aplicação esteja disponível. Este processo é co-nhecido como carrossel. Um carrossel de objetos permite que um ou mais sistemas de arquivos sejam ciclicamente enviados. Esse carrossel é especificado no conjunto de protocolos DSM-CC.
Vários carrosséis de objetos podem ser transmitidos simultaneamente. Aplicações presentes em um carrossel podem fazer referência a arquivos presentes em outro carrossel. Como exemplo, uma página em HTML pode utilizar como refe-rência uma imagem contida em outro carrossel de objetos [16]. Para que o receptor
interprete a hierarquia de diretórios de forma correta, deve-se utilizar um mecanismo para fazer com que os autores de aplicações interativas aprendam detalhes do me-canismo de identificação de recursos do carrossel de objetos e do protocolo DSM-CC, com o objetivo de especificarem as aplicações com as URLs adequadas ao am-biente de exibição do sistema de TV digital. [17].
O DSM-CC determina que os dados transmitidos através do carrossel de objetos devem ser divididos em unidades denominadas módulos. Cada módulo pode possuir mais de um arquivo desde que não ultrapasse um total de 64 Kbytes. Os ar-quivos que estão em um mesmo módulo podem fazer parte de diretórios diferentes. Uma vez que os objetos foram dispostos em módulos, cada um deles é então trans-mitido um após o outro. Após transmitir o último módulo, a transmissão é reiniciada a partir do primeiro bloco. O resultado disso é um fluxo que contém o sistema de arqui-vos transmitido de forma cíclica. Assim, se um determinado receptor não recebeu uma parte de um módulo em particular, devido a um erro na transmissão ou por ter sido iniciado após a transmissão desse módulo, basta esperar pela retransmissão desse módulo.
Em alguns casos, utilizar o carrossel de objetos dessa forma significa in-troduzir uma latência impraticável para os dados enviados pela emissora. Para ate-nuar este problema, os geradores de carrossel oferecem como opção transmitir al-guns módulos com maior frequência que outros. Assim, os módulos que contêm ar-quivos com maior prioridade podem ser transmitidos com maior frequência.
Como exemplo, considere a estrutura de diretórios da Erro: Origem da re-ferência não encontrada. Essa estrutura conta com um arquivo “index.htm” que deve ser exibido nos receptores. O arquivo “Pasta1.htm” possui como elo (Link) para o “Track1.mp3”. Se, eventualmente, o link for acionado, a mídia “Track1.mp3” seria exibida.
Figura 16: Sistema de arquivos do Carrossel de Objetos.
Para transmitir a estrutura da Erro: Origem da referência não encontrada via carrossel de objetos, primeiro é necessário separar seus arquivos em módulos. Inicialmente, seria possível alocar o arquivo “Pasta1.htm” em um primeiro módulo. O arquivo seguinte da estrutura - Track1.mp3 - possui mais de 64 Kbytes e, portanto, não é possível que este faça parte do mesmo módulo de “Pasta1.htm”. Assim, “Track1.mp3” é alocado em um módulo único. Analogamente, o arquivo image001.png deve ser alocado em um terceiro módulo. Já os demais arquivos po-dem ser alocados no mesmo módulo que se encontra o arquivo Pasta1.htm, uma vez que a soma do tamanho desses arquivos é inferior a 64 Kbytes. A disposição fi-nal de arquivos em três módulos é ilustrada na Erro: Origem da referência não en-contrada.
Após a divisão dos dados em módulos, é possível determinar a sequência que estes módulos serão transmitidos. Uma sequência interessante seria 1-3-2, já que o arquivo “image001.png” depende do arquivo “pasta1.htm” para ser exibido. Assim, essa divisão resultaria em uma menor latência na transmissão. O módulo 2 só será utilizado se o usuário acionar a âncora e, portanto, não fará falta antes da ocorrência da ação interativa. A Erro: Origem da referência não encontrada ilustra a forma de transmissão escolhida:
Figura 18: Sequência de Transmissão dos Módulos do Carrossel de Objetos.
Finalmente, neste exemplo, um objeto de evento deveria ser transmitido (nesse mesmo carrossel de objetos). Simplificadamente, o objeto de evento possui informações sobre os eventos DSM-CC que farão com que a aplicação responsável exiba o arquivo “Pasta1.htm”. Os objetos DSM-CC, bem como os eventos DSM-CC, são abordados na seção seguinte.
3.2.5 EVENTOS DSM-CC
A estrutura de arquivos mostrada na seção anterior utiliza como exemplo o envio cíclico uma aplicação denominada “Tabela do Campeonato Brasileiro”. As-sim, durante uma rodada do campeonato, a ocorrência de um gol (evento) pode alte-rar o posicionamento do time na tabela e o usuário teria esta informação disponível na próxima iteração da transmissão do carrossel. O sincronismo desses eventos com o conteúdo audiovisual principal é especificado no padrão DSM-CC e é
chama-do de evento DSM-CC. Neste contexto, um evento significa qualquer ocorrência no tempo, tal como o acionamento de um botão do controle remoto.
Para criar um evento DSM-CC, é inserida no fluxo de transporte uma es-trutura denominada descritor de eventos. Cada descritor de eventos possui um iden-tificador numérico único, que o identifica no fluxo de transporte. Uma vez que não existe a possibilidade do emissor prever exatamente a posição que o descritor será inserido no fluxo, cada descritor possui uma referência temporal NPT que indica em qual instante o evento deverá ocorrer. [16].
Além do identificador e da referência temporal, o descritor de eventos possui também um campo para dados específicos, que podem ser tratados pelas aplicações [18].
Neste exemplo, a aplicação “Tabela do Campeonato Brasileiro” deverá enviar um descritor de evento para atualizar a aplicação do receptor, toda vez que a emissora possuir novos lançamentos dessas informações. Paralelamente ao envio dos descritores de evento, são enviados os objetos de eventos transportados atra-vés de carrosséis DSM-CC. Esse objeto possui um nome textual e um identificador numérico (eventId) que deverá ser único dentro de um carrossel. Assim, as aplica-ções podem se registrar como “ouvintes” de eventos com os nomes contidos no ob-jeto de eventos. É interessante ressaltar que cada nome textual deverá estar associ-ado apenas a um único identificassoci-ador [18].
Conforme discutido, o descritor de eventos possui dados específicos das aplicações. No exemplo do parágrafo anterior, esses dados seriam responsáveis por informar qual time teria feito o gol, permitindo à aplicação fazer a atualização da ta-bela.
Um objeto de eventos especial deve ser enviado no carrossel de objetos para atribuir nomes aos eventos que, eventualmente, possam ocorrer. Neste objeto, tem-se uma tabela que referencia nomes textuais, conhecidos pelas aplicações, aos identificadores numéricos dos eventos que serão criados pelos descritores. Um exemplo de objeto de evento é apresentado na Erro: Origem da referência não en-contrada. A aplicação da tabela é instruída ou programada para se atualizar a cada ocorrência do evento “Gol”.
Tabela 4: Exemplo de um Objeto de Eventos DSM-CC.
Nome do Evento ID do Evento
Gol 02
Cartão Amarelo 04
Cartão Vermelho 06
Tecla Azul do Controle Remoto 07
Considere que a aplicação “Tabela do Campeonato Brasileiro” seja cha-mada através do acionamento da tecla azul do controle remoto. Havendo um gol, isto é, uma ocorrência do Evento 02, a aplicação deve atualizar o conteúdo da tabe-la.
3.3 MODULAÇÃO
O SBTVD utiliza a mesma técnica de modulação do sistema japonês [17]. O chamado BST-OFDM (Bandwidth Segmented Transition - Orthogonal Frequency
Division Multiplexing).
A modulação do sistema de TV digital é responsável por acomodar um canal de alta definição na mesma banda de 6 MHz existente no sistema analógico. Além do processo de compressão MPEG-4 mais eficiente, o sistema de modulação adotado tem boa parte desse mérito.
Alguns sistemas de modulação digital transportam apenas um bit de infor-mação por símbolo, isto é, cada símbolo só pode ser representado por dois níveis: baixo ou alto (0 ou 1). As técnicas de modulação digital são geralmente indicadas por um número que representa o número de níveis (ou estado) que um símbolo pode ser representado. No caso da modulação 16QAM, por exemplo, significa que cada símbolo pode ser representado por 16 bits de informação. Analisando dessa forma, nos induz a pensar que aumentar o número de bits por símbolo resolveria
todo o problema de escassez da banda de transmissão. O problema de aumentar a taxa de transmissão é que essa estratégia eleva muito à probabilidade de erros devi -do à interferência intersimbólica [19] poden-do resultar em erros impraticáveis no sis-tema. Ao aumentarmos a taxa de transmissão diminuiremos a sensibilidade a ruídos. Na modulação onde apenas uma portadora é utilizada, os símbolos são transmitidos em série, e, portanto, o período do bit é inversamente proporcional a taxa de transmissão. Um canal digital em resolução 1920x1080 pixels utiliza, aproxi-madamente, uma taxa de 19,3 Mbps. Com essa taxa, teríamos sérios problemas em transmiti-la por difusão, onde os efeitos de multipercurso8 e o ruído impulsivo são
inevitáveis. Dessa forma, a taxa de erro poderia tornar o sistema inoperante.
Para lidar com essas dificuldades, pode-se utilizar uma técnica de modu-lação com múltiplas portadoras. Como nesta técnica, o período do símbolo pode ser aumentado significativamente, há uma redução no problema do ruído impulsivo e múltiplos percursos. Isso é alcançado ao dividir a alta taxa de bits em vários canais com baixa taxa de bits. Cada canal modula uma subportadora resultando em uma transmissão em paralelo, ao contrário do sistema com uma única portadora.
Para modular cada subportadora, normalmente, é utilizada uma variação do FDM (frequecy division multiplexing). No sistema FDM, as portadoras são espa-çadas igualmente para permitir que sejam demultiplexadas em filtros convencionais. Para que não haja erros durante essa filtragem na recepção, um intervalo de guarda é adicionado em cada canal resultando em um desperdício na largura da banda. Na modulação OFDM (Orthogonal Frequency Division Multiplexing), as subportadoras são alocadas ortogonalmente e, dessa forma, é permitido que estas ocupem um es-pectro reduzido, já que sua disposição ortogonal impede que haja interferência des-trutiva.
Complementarmente, a técnica de modulação BST-OFDM divide a banda de 6 MHz em 13 segmentos de 428,5 kHz. Esses 13 segmentos podem ser divididos em três grupos hierárquicos ou camadas, que lhe conferem maior ou menor robus-tez, dependendo da aplicação a que se destinam. Um desses segmentos é reserva-do à transmissão para receptores móveis e portáteis, tais como celulares, PDAs e notebooks, com parâmetros de transmissão adequados a essas aplicações. Ao
mes-8 Efeito Multipercurso: Fenômeno que ocorre quando o sinal percorre diferentes percursos, através de
sucessivas reflexões, fazendo com que o sinal recebido seja formado pela sobreposição destes si-nais.
mo tempo e no mesmo canal, os outros 12 segmentos podem ser utilizados para transmissão para receptores fixos em HDTV e/ou SDTV. Os parâmetros de trans-missão podem ser configurados individualmente para cada segmento, aqui referido como segmento OFDM, formando um canal de composição flexível. Este procedi-mento de configuração é denominado estrutura de camada hierárquica. Uma das ca-racterísticas importantes da modulação OFDM é a possibilidade de operar no esque-ma de transmissão rede de frequência única (SFN – Single Frequency Network). Para adequar a distância entre as estações SFN e robustez ao efeito Doppler9
du-rante a recepção móvel, são estabelecidos três diferentes espaçamento entre as fre-quências portadoras, denominados modos. Esses espaçamentos são de 3.968 Hz para modo 1, 1984 Hz para modo 2 e 992 Hz para modo 3. Esses espaçamentos re-sultam em 108 portadoras para cada segmento OFDM no modo 1, 216 portadoras para o modo 2 e 432 portadoras para o modo 3. A Figura 19 ilustra o processo de modulação BST-OFDM. [17]
9 Efeito Doppler: Fenômeno característico das ondas emitidas ou refletidas por um objeto em
Figura 19: Esquema de modulação BST-OFDM.
O sistema brasileiro de TV digital utiliza códigos de correção de erro. Des-sa forma, a modulação BST-OFDM é utilizada em conjunto com o codificador de ca-nal que será abordado na seção seguinte.
O esquema de codificação de canal permite a transmissão hierárquica, isto é, múltiplas camadas hierárquicas com diferentes parâmetros de transmissão podem ser transmitidas simultaneamente. Cada camada hierárquica consiste em um ou mais segmento OFDM. [20].
3.4 TRANSMISSÃO
No sistema brasileiro de TV digital terrestre, o sinal é enviado em um meio não guiado, isto é, o sinal é difundido no ar. Este processo insere um ruído aleatório inerente ao canal referido e não pode ser evitado. Para atenuar os efeitos do ruído aleatório, procura-se elevar a relação sinal ruído. Em um sistema de transmissão analógico, o ruído se manifesta nas telas em forma de “chuviscos”. Já no sistema digital, conforme informado na seção 3.7, existem códigos corretores de erro para reduzir a probabilidade de que o ruído modifique o sinal ao ponto de um nível alto ser interpretado como nível baixo ou vice-versa. Complementarmente, a degradação de um sinal pode ocorrer com o chamado efeito multipercurso. Este efeito pode cau-sar interferência intersimbólica (ISI – Intersymbol Interference), ou seja, cada bit pode interferir no bit subsequente aumentando a taxa de erro. Se essa taxa de erro for maior do que um determinado limiar, a recepção pode ser interrompida. Por esta razão, geralmente é dito que no sistema de TV digital, ou teremos um sinal perfeito, isto é, isento de “chuviscos” ou, nenhum sinal.
A estrutura de rádio frequência do transmissor é bastante semelhante ao sistema analógico, requerendo somente uma resposta de fase e linearidade de am-plitude mais precisa para minimizar a distorção do sinal.
A Erro: Origem da referência não encontrada representa, em forma de blocos, uma visão Geral do sistema de transmissão.
3.4.1 O PLAYOUT
As ferramentas apresentadas neste trabalho não são suficientes para rea-lizar simulações e testes de todas as etapas do processo de geração e transmissão do conteúdo presente em um sistema de TV digital interativa atual. Na construção e multiplexação do carrossel, por exemplo, torna-se necessário um equipamento de hardware capaz de realizar essa tarefa. Tal equipamento é denominado Playout.
Nos sistemas de transmissão por radiodifusão, o termo playout se refere ao equipamento que faz a transmissão do conteúdo da emissora para as redes que distribuem o conteúdo aos clientes.
O playout, geralmente, fica situado em salas de controle (playout centers) embora haja unidades portáteis deste equipamento.
Alguns dos maiores Playout Center da Europa e Estados Unidos lidam com mais de 50 canais de TV e serviços interativos.
No Brasil, existe uma solução da Empresa EITV que se propõe a simular essa cadeia de transmissão e recepção do sinal de TV digital brasileiro, incluindo to-das as particularidades do sistema nacional. Este equipamento, incluindo a placa moduladora, é vendido por, aproximadamente $ 36.000,00 (dólares americanos). As demais soluções são, geralmente, voltadas para os sistemas europeus de TV digital interativa. A representação deste playout pode ser visualizada na Erro: Origem da referência não encontrada.
Nos contexto deste trabalho, o resultado da multiplexação dos pacotes PES em um único TS realizada pelo Elecard Xmuser poderia ser combinado com os pacotes das aplicações através da utilização do Playout. Além disso, este equipa-mento faria a codificação destas aplicações utilizando o protocolo de Carrossel de Objetos DSMCC. Complementarmente, poderiam ser geradas informações de sinali-zação das aplicações que permitem o controle de execução das mesmas.
Figura 21: Fabricado pela EITV do Brasil. Vistas Frontal e Traseira.
O Playout da EITV é um equipamento profissional de alta disponibilidade voltado para operação em emissoras geradoras de TV digital totalmente compatível com as especificações do padrão brasileiro SBTVD.
O equipamento pode integrar seis funções distintas que, em geral, são realizadas por equipamentos específicos. Essas funções são:
• Servidor de PSI.
• Servidor de EPG (Eletronic Program Guide). • Servidor de Closed Caption.
• Servidor de Dados (Ginga/OAD). • Multiplexador.
Tabela 5 : Especificação do Playout Professional EITV [22].
Função Características Técnicas
Servidor de In-formação de Serviços (SI)
-Multiplexação e geração de PSI conforme a Norma Brasileira ABNT NBR 15603.
-Geração de informações de tabelas PAT, PMT, NIT, etc.
-Configuração de fuso horário para ajuste automático de horário com base no UTC.
-Configuração das tabelas que serão geradas no fluxo de transporte. -Configuração de número de canal virtual.
-Configuração de ID de serviço (service ID).
-Configuração de taxa de repetição das tabelas em milissegundos.
Servidor de EPG
-Multiplexação e geração de EPG10 conforme a Norma Brasileira ABNT NBR
15603.
-Informações de data, horário, duração, título, subtítulo e descrição dos pro-gramas.
-Descritores EIT (Informação de Evento).
-Atualização automática de tabelas EIT com base em arquivo XML. -Sincronização com relógio externo via NPT.
Re-multiplexa-dor
-Remultiplexação de fluxo de transporte conforme a Norma Brasileira ABNT NBR 15601.
-Geração de fluxo de transporte organizado em camadas hierárquicas. -Geração do pacote IIP (ISDB-T Information Packet).
-Geração de informação TMCC (Transmission and Multiplexing Configurati-on CConfigurati-ontrol).
-Configuração de modo de transmissão e intervalo de guarda.
-Configuração de segmentos, modulação, code rate e time interleaving dos layers.
-Configuração para habilitar flag de alerta de emergência.
-Ordenação automática dos pacotes para construção de quadro OFDM. -Geração de sinais para transmissão HDTV, SDTV e TV Móvel.
-Opção de entrada de referência externa de clock de 10 MHz.
Função Características Técnicas
Servidor de Carrossel de
-Codificação de dados conforme a Norma Brasileira ABNT NBR 15606. -Geração de carrossel de objetos DSM-CC.
10 EPG: Sigla de Electronic Programming Guide, Interface gráfica que possibilita a navegação pelas
Objetos
-Suporte a aplicações GINGA-J, GINGA-NCL.
-Inserção em tempo real do carrossel de objetos no fluxo de transporte. -Configuração de ID de organização e ID de aplicação.
-Configuração de opção de auto-inicialização.
-Descritores de dados (association tag, component tag, carousel ID, data broadcast ID).
-Configuração de taxa de bits de transmissão da aplicação. -Configuração de PIDs de AIT e fluxo de dados.
-Geração de Eventos DSM-CC.
-Atualização automática de aplicações com base em arquivo XML e protoco-lo FTP.
-Agendamento automático de transmissão, início (start) e parada (stop) de aplicações via XML.
-Agendamento automático de envio de Fluxo de Eventos via XML.
Servidor de Closed Caption
-Aderente às Normas ABTN NBR 15606-1 e ARIB STD-B24 VOL1 PART 3. -Geração em tempo real de legendas e caracteres sobrepostos.
Suporte a Closed Caption roll-up e pop-up.
-Entrada de sinal serial a partir de interface RS-232.
-Configuração de PID do fluxo de saída do Closed Caption (CC). -Configuração de idioma do CC.
-Suporte a geração de vários fluxos de CC simultâneos. -Geração de PTS para sincronização com o fluxo de A/V. -Saída em tempo real do fluxo com CC multiplexado.
Multiplexador
-Multiplexação de fluxo de transporte conforme a Norma Brasileira ABNT NBR 15603.
-Até 8 entradas ASI independentes para multiplexação em tempo real. -Integração com codificadores externos via entradas ASI.
-Multiplexação automática de A/V, SI, EPG, Closed Caption e carrossel de objetos.
-Filtragem de PIDs e streams, regeração de tabelas e dados de TS. -Entrada de TS em tempo real via interface ASI.
A Erro: Origem da referência não encontrada exibe um diagrama que ilus-tra as funções desempenhadas pelo EITV Playout Professional dentro de um ambi-ente de transporte e transmissão de TV Digital com serviços interativos.
