UNIVERSIDADE FEDERAL FLUMINENSE MAICK DE SOUZA … · duais. As especificações das aplicações e...
68
UNIVERSIDADE FEDERAL FLUMINENSE MAICK DE SOUZA MAGNO TRANSPORTE DE DADOS EM SISTEMAS DE TV DIGITAL Niterói 2010
Transcript of UNIVERSIDADE FEDERAL FLUMINENSE MAICK DE SOUZA … · duais. As especificações das aplicações e...
UNIVERSIDADE FEDERAL FLUMINENSEMAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EMSISTEMAS DE TV DIGITAL
Niterói2010
MAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EMSISTEMAS 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ÓI2010
MAICK DE SOUZA MAGNO
TRANSPORTE DE DADOS EMSISTEMAS 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”
(Albert Einstein)
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
Figura 26: Análise em Baixo Nível do Quarto Pacote PES........................................62
Figura 27: Análise em Baixo Nível do 319º pacote PES............................................63
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
Tabela 5 : Especificação do Playout Professional EITV [22]......................................54
LISTA DE GRÁFICOS
Gráfico 1 : Gráfico da Multiplexação do TS................................................................58
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...........................................................................................................................49
SFN.............................................................................................................................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
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 66
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 aproximadamente 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 informaçã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 de ajustes possíveis a fim de encontrar uma configuração ideal 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 conteú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 parte 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 linguagens 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 ponto de imprevisibilidade) podem ocorrer, alterando qualquer sincronismo inicialmente calculado.
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 Di-
2 Pixel: Elemento de imagem (Picture Element). É o menor elemento em um dispositivo exibidor.
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 MPEG-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.pdf4 http://math.uoregon.edu/alumni/theses/merchant.pdf5 http://www.michael-maniscalco.com/papers/rle-exp.pdf
Figura 1: Diagrama de Codificação MPEG-4.
Figura 2: Diagrama de Decodificaçã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 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_idO 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_priorityEste 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
CopyrightCampo de 1 bit. Se o seu valor é 1 indica que o material associado à
carga útil do PES é protegida.
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 indi-
car 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 con-
6 Program Clock Reference; PCR: É um selo de tempo contido no fluxo de transporte.
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 fluxoNúmerodo PID
Descrição
Tabela de Associação
do programa
ITU-T H.222.0 [23] |
ISO/IEC 13818-10x00
Número de associação do pro-
grama e PID da PMTTabela 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 progrmasTabela de
Informação da RedePrivada
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-10x01
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 autorizam níveis de serviços de alguns decodificadores.
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 temporal pode ser pausada
e, posteriormente, reiniciada a partir do instante em que foi pausada e, isto normal-
mente ocorre aleatoriamente 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 refe-
rência não encontrada.
Tabela 3: Descrição do Conteúdo NPT.
Campo Descriçãocontent_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 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.
Figura 17: Disposição do Carrossel de Objetos em Módulos.
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 identificador [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] podendo 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 movi-mento em relação ao observador
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.
Figura 20: Diagrama 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.
• Remultiplexador.
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 Control).
-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 múltiplas possibilidades de programação que o usuário encontra na TV Digital.
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.
Figura 22: Funções do EITV Playout Professional [22].
4 ANÁLISE E INTERPRETAÇÃO DOS DADOS
Neste capítulo serão abordados alguns testes de performance e análise
do processo de multiplexação e geração do TS.
4.1 MULTIPLEXAÇÃO DO FLUXO ELEMENTAR E TAXA GLOBAL
Conforme discutido anteriormente, no Capítulo 3, o fluxo elementar, com-
posto do conteúdo audiovisual, é multiplexado com uma taxa fixa, consequentemen-
te, pacotes nulos podem ser gerados. Essa taxa permanece na construção do TS fi-
nal e os pacotes nulos podem ser utilizados para inserir informações como a especi-
ficação das aplicações, o NPT e as mídias do carrossel de objetos.
A taxa pode ser escolhida a partir de alguma heurística. A proposta deste
trabalho é calcular a taxa do TS como a soma da taxa média do áudio, com o vídeo
e adicionar uma margem de 5% para criação dos paddings (pacotes nulos) e assim
teremos a primeira taxa a ser testada.
Para realizar os testes foi utilizado um arquivo de áudio, codificado em
AAC (2 canais), com tamanho 2,65 MB e com 114 segundos de reprodução. O ar-
quivo de vídeo escolhido foi codificado no formato H.264 com resolução 1920x816
pixels, tamanho de 123 MB e possui os mesmos 114 segundos de reprodução.
A taxa média esperada para o áudio é de 2,65 * 8 /114 = 0,185 Mbps. Por
outro lado, a taxa média do vídeo é de 123 * 8/114 = 8,269 Mbps. A soma das taxas
médias é, aproximadamente 8,454 Mbit/s. Adicionando os 5% dos pacotes nulos te-
mos 8,88 Mbps.
A partir deste valor, a taxa de dados foi aumentada em 10%, 15% e 20%
da taxa destinada a pacotes nulos. O Erro: Origem da referência não encontrada
mostra a relação entre o tamanho do arquivo e a taxa global.
Gráfico 1 : Gráfico da Multiplexação do TS.
A relação entre os pacotes nulos e o conteúdo do áudio e vídeo principais
é um dos principais problemas a serem tratados nos sistemas de TV digital. É impor-
tante mencionar que esses pacotes nulos estão sendo colocados como uma referên-
cia a outros conteúdos adicionais que devem estar presentes na transmissão, como
outras mídias, o NPT e aplicações interativas.
Quando um percentual considerável do TS é destinado a essas informa-
ções adicionais, pode ser necessário diminuir a qualidade do vídeo a fim de se obter
uma taxa capaz de ser modulada em um canal de TV. Por outro lado, para que um
vídeo de alta qualidade possa ser transmitido, pode ser necessário manter a taxa de
pacotes nulos, correspondentes às informações adicionais, baixa.
No intuito de trabalhar com o pior caso, isto é, a hipótese em que as con-
dições de transmissão se mostram mais adversas, será utilizado para análise o ar-
quivo TS, cuja taxa foi 10,769 Mbps.
4.2 ANÁLISE DO TS EM BAIXO NÍVEL
O Capítulo 3 informa que o fluxo elementar pode ser dividido em pacotes
denominados PES. Cada pacote tem uma carga útil (payload) que contém os dados
e um cabeçalho. Cada pacote tem 188 bytes e será analisado com o auxílio da ferra-
menta TS Analyser.
Inicialmente, o arquivo TS escolhido na seção anterior é aberto nesta fer-
ramenta. O arquivo foi subdividido em 989651 pacotes PES de 188 bytes. A Erro:
Origem da referência não encontrada mostra a lista de identificadores PID do TS.
Figura 23: Lista de PID do pacote TS.
Além da lista de PID’s, o programa permite navegar através dos fluxos, fil-
trar pelo PID e/ou flag de início de carga útil, etc.. No primeiro PID, pode-se encon-
trar a Tabela de Associação do Programa (PAT), alocada no primeiro pacote PES
com o PID 0. No segundo pacote PES, encontra-se a Tabela de Informação da Rede
(NIT) alocada com o PID 16. As Figuras 24 e 25 ilustram, em baixo nível, os deta-
lhes destes dois primeiros pacotes.
Figura 24: Análise em Baixo Nível do Primeiro Pacote PES.
Figura 25: Análise em Baixo Nível do Segundo Pacote PES.
No terceiro pacote, encontra-se a Tabela de Descrição do Serviço (SDT)
que é responsável por conter a lista de nomes e informações sobre os serviços con-
tidos no TS. Esta tabela foi alocada com PID 17. A partir do quarto pacote, encontra-
mos o primeiro Prefixo de Código de Início de Pacote PES. É o primeiro pacote com
os 188 bytes preenchidos. Através da Erro: Origem da referência não encontrada, é
possível conferir os detalhes do quarto pacote PES.
Figura 26: Análise em Baixo Nível do Quarto Pacote PES.
No 319º pacote PES, por exemplo, é possível encontrar os pacotes nulos
gerados a partir da multiplexação do Elecard XMuxer. Na Erro: Origem da referência
não encontrada percebe-se que do 5º byte até o 160º os pacotes nulos são repre-
sentados por FF em hexadecimal. É interessante observar que trata-se início do flu-
xo do áudio AAC.
Figura 27: Análise em Baixo Nível do 319º pacote PES.
5 CONCLUSÃO
O Sistema Brasileiro de TV Digital veio se consolida a cada dia e, em al-
guns anos, o sistema analógico estará totalmente inoperante. A pesquisa realizada
neste projeto pode contribuir como uma importante base de conhecimento sobre
este sistema. Entretanto, ainda há muito a ser estudado e desenvolvido.
Durante as etapas de desenvolvimento deste trabalho, houve discussões
de grande valia acerca do processo de transmissão de dados nos sistemas de TV di-
gital.
Inicialmente foi realizado um estudo detalhado sobre os dados a serem
multiplexados e as suas estruturas, permitindo a escolha da melhor configuração de
acordo com as restrições de cada dado a ser multiplexado.
No decorrer da elaboração deste trabalho foi notório que o desenvolvi-
mento de um ambiente de testes de aplicações de TV digital interativa com código li -
vre e totalmente funcional é algo que deve ser pensado. É imprescindível o surgi-
mento de inúmeros desenvolvedores de aplicações nessa área e a falta de softwa-
res disponíveis que façam uma simulação deste processo é um obstáculo que preci-
sa ser contornado.
Além das questões relacionadas com a construção do TS, a questão da
preservação do sincronismo em aplicações que referenciam conteúdos transmitidos
de forma intercalada com outros conteúdos foi discutida neste trabalho. Este assunto
deve ser estudado em detalhes, pois não se trata de um problema de solução trivial.
Embora o trabalho apresente uma alternativa interessante com o fluxo NPT, não foi
possível avaliar na prática seu comportamento, pois faz-se necessária a utilização
do Playout.
Tecnicamente, o SBTVD possui os atributos necessários para que o siste-
ma se desenvolva com sucesso e o Brasil possa desfrutar de todos os benefícios
que o sistema pode proporcionar e estudos com este enfoque serão de grande valia.
5.1 TRABALHOS FUTUROS
Como trabalho futuro, pretende-se implementar um mecanismo integrado
que seja capaz de simular todas as etapas do processo de transmissão e recepção
do TV digital. Um estudo do sistema de recepção também é objetivo de um trabalho
futuro.
Muitos detalhes precisariam ser estudados mais a fundo, tais como a ge-
ração e o funcionamento do carrossel de objetos, a multiplexação/demultiplexação
do fluxo de transporte e a construção das aplicações interativas.
REFERÊNCIAS BIBLIOGRÁFICAS
[01] Padrão ISO/IEC 13818-1 “Information technology — Generic coding of mov-ing pictures and associated audio information: Systems”, 2000, ISO/IEC.
[02] Morris, S., Smith-Chaigneau, A. Interactive TV Standards: A Guide to MHP, OCAP, and JavaTV. Focal Press, 2005.
[03] NBR ABNT 15602-1 “Televisão digital terrestre — Codificação de vídeo, áu-dio e multiplexação Parte 1: Codificação de vídeo”
[04] DTV, Site Oficial da TV Digital Brasileira, www.dtv.org.br “acessado em
14/07/2010”
[05] Padrão ISO/IEC 14496-14 “Information technology — Coding of Audio-Visual Objects”, 2003.
[06] Padrão ISO/IEC 14496-10 “Information technology — Coding of Audio-Visual Objects”, 2004.
[07] Ginga, www.ginga.org.br – “acessado em 13/07/2010”
[08] Padrão ISO/IEC 13818-2 “Information technology — Generic coding of mov-ing pictures and associated audio information: Video”, 2000.
[08] Laboratório de Aplicações de Vídeo Digital, Universidade Federal da Paraíba,
www.lavid.ufpb.br – “acessado em 13/07/2010”
[09] Oracle Corporation, http://java.sun.com/ - “acessado em 14/07/2010”
[10] GingaNcl, Laboratório Telemídia – Pontifícia Universidade Católica do Rio de
Janeiro, www.gingancl.org.br “acessado em 13/07/2010”
[11] Nagato, Felippe. Soares, Luiz Fernando Gomes. Acesso a bases temporais multiplexadas em fluxos Normal Play Time. Rio de Janeiro, 2009. 40p. Relatório
de Projeto Final de Curso – Departamento de Informática. Pontifícia Universidade
Católica do Rio de Janeiro.
[12] International Organization for Standartization, www.iso.org “acessado em
14/08/2010”
[13] Padrão ISO/IEC 14496-2 “Information technology — Coding of Audio-Visual Objects: Visuals”, 2001.
[14] Sony Vegas Pro ®, www.sonycreativesoftware.com/vegaspro “acessado e,
16/08/2010”
[15] Elecard Group, www.elecard.com “acessado e, 27/08/2010”.
[16] Padrão ISO/IEC 13818-6 “Information technology — Generic coding of mov-ing pictures and associated audio information: Digital Storage Media Com-mand & Control”, 1996.
[17] NBR ABNT 15601 “Televisão digital terrestre – Sistema de Transmissão”,
2007
[18] Soares, L. F Gomes, Artigo - Mecanismo de Identificação de Recursos para Aplicações Interativas em Redes de TV Digital por Difusão - Veículo: XXV Sim-
pósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC2007,
2007
[19] Costa, Romualdo M. Resende; Moreno, Soares; L. F Gomes; Artigo - Sincronis-mo entre Fluxos de Mídia Contínua e Aplicações Multimídia em Redes por Difu-são – Veículo: XIV Simpósio Brasileiro de Sistemas Multimídia e Web - WebMedi-
a2008, 2008
[20] ARIB STD – B31 - Transmission System for Digital Terrestrial Television Broadcast. Padrão japonês
[21] Haykin, Simon, Sistemas de Comunicação – Analógicos e Digitais, Bookman, 2004
[22] Eitv do Brasil, http://www.eitv.com.br/playprof.php “acessado e, 06/10/2010”
[23] Padrão ITU-T H.222 – International Telecommunication Union. www.itu.ch,
“acessado em 02/11/2010”
Kurose, F. James., Ross, W. Keith. Redes de computadores e a Internet – Uma abordagem top-down. Pearson, 2006
NBR ABNT 15602-2 “Televisão digital terrestre – Codificação de dados e especi-ficações de transmissão para radiodifusão digital Parte 2: Ginga-NCL para re-ceptores fixos e móveis – Linguagem de aplicação XML para codificação de aplicações”
NBR ABNT 15602-3 “Televisão digital terrestre – Codificação de dados especifi-cações de transmissão para radiodifusão digital Parte 3: Especificação de transmissão de dados”
