You are on page 1of 9

Implementação de um Multiplexador de Transport Streams

Gustavo Girão, Eupólemo Holanda, Monica Magalhães Pereira, Sílvio R. F. de Araújo, Mário César Heliodoro Arruda, Ivan Saraiva Silva Departamento de Informática e Matemática Aplicada – Universidade Federal do Rio Grande do Norte (UFRN) Caixa Postal 59072-970 – Natal – RN – Brasil
{ggirao, eupolemo, monica, silvio}@lcc.ufrn.br, mariocha@natalnet.br, ivan@dimap.ufrn.br

Abstract. This paper presents a proposal of a transport stream multiplexer arquitecture for digital television. This arquitecture makes possible the transport stream packages generation from video and audio Packetized Elementary Stream; which are multiplexed in time together with the control informations of tables Program Assosiation Table and Program Map Table. Resumo. Este artigo apresenta a proposta de uma arquitetura de multiplexador de transport stream para televisão digital. Essa arquitetura possibilita a geração de pacotes transport stream a partir de Packetized Elementray Stream de vídeo ou de áudio, os quais são multiplexados no tempo juntamente com as informações de controle das tabelas Program Association Table e Program Map Table.

1. Introdução
Multiplexação é uma técnica empregada para permitir transmitir mais de um sinal em um mesmo meio físico [Soares 1995], assim várias fontes de informação podem compartilhar um mesmo sistema de transmissão. Quando os dados a serem multiplexados são áudio ou vídeo, é necessário considerar a estrutura de cada dado e principalmente a sincronização dos mesmos, para que a transmissão da imagem juntamente com o áudio seja um processo simultâneo. O processo de multiplexação é dado por etapas. A primeira etapa está relacionada com o armazenamento e a leitura dos dados a serem transmitidos. Se necessário, os dados devem ser encapsulados em estruturas adequadas a multiplexação. A segunda etapa corresponde ao armazenamento das estruturas obtidas na etapa anterior. Após a realização da primeira e segunda etapas, a etapa seguinte é a de multiplexação, onde de fato, os dados a serem transmitidos serão multiplexados e será a eles anexado um PCR (program clock reference) que é uma indicação de tempo utilizada em processos seguintes da transmissão. A última etapa é a de geração e armazenamento de transport streams que são os dados multiplexados encapsulados em uma estrutura que possui um cabeçalho e um payload (seção de dados). É necessário criar as estruturas transport streams porquê são as estruturas adequadas à transmissão dos dados. Na seção 2 é apresentada uma arquitetura de um multiplexador e as etapas de implementação descritas anteriormente de forma mais detalhada. A seção seguinte

Na seção 4 é apresentada a conclusão. Assim. Transport Streams são formados por pacotes PES. os pacotes PES devem ser quebrados em segmentos menores. que permite determinar que estrutura de dado está sendo multiplexada (áudio.1. vídeo ou dados codificados) e um identificador de stream.Arquitetura do Multiplexador 2. A Figura 1 exibe a arquitetura proposta para o multiplexador de TS. Para implementar o multiplexador. Um controle do multiplexador decide qual informação deve ser empacotada em um dado momento. E por fim. Repositório Temporário Figura 1 .apresenta como foram implementados os módulos. Arquitetura do Multiplexador O processo de multiplexação de TS (transport stream) consiste em transmitir pacotes TS com informações de vídeo. que determina qual segmento PES está . Inicialmente. As informações extraídas correspondem ao tipo de stream. a primeira etapa corresponde a armazenar as estruturas de dados a serem multiplexadas. Cada segmento é então analisado e são extraídas informações necessárias para o processo de multiplexação. composta apenas por bytes de dados extraídos do elementary stream. Analisador de PES Packetized Elementray Stream (PES) consiste em um pacote formado por um cabeçalho seguido por uma seção de dados. áudio e tabelas PSI com restrições de tempo. é proposta uma arquitetura na qual cada uma das informações é tratada em um módulo distinto. e a comunicação entre os módulos é feita através de buffers ou por outro módulo. na seção 5 os trabalhos futuros são relacionados. 2. Para o multiplexador de transport stream a primeira estrutura de dados a ser manipulada corresponde ao pacote PES.

assim um PID é gerado para essa tabela e armazenado no módulo Repositório Temporário juntamente com o número do programa dessa tabela. Desse modo essa estrutura é consultada no momento da geração das PMTs. isto é. Essas informações correspondem ao Program Specific Information (PSI) que é classificado em cinco tabelas. onde cada seção realiza a associação de PID com número de programa ou com fluxos elementares. os pacotes PES são armazenados em um buffer e serão retirados byte a byte todas as vezes que o módulo Controle requisitar. As tabelas podem ser segmentadas em uma ou mais seções. 2. por conseguinte o tamanho da seção também o é. logo o número da seção corrente e o número da última seção fazem parte das informações da seção da tabela. Gerador de Tabelas PSI A multiplexação de pacotes Transport Stream deve inserir informações sobre a natureza dos dados multiplexados. A Program Association Table por sua vez possui os números de programas e PIDs associados. mas em um segundo momento também serão extraídos PES de transport streams e de program streams.sendo utilizado naquele pacote que está sendo multiplexado. no entanto apenas duas delas serão exploradas nesse artigo. É extraído também o PTS (presentation time stamp). informações de controle que permitam ao receptor desses pacotes realizar a demultiplexação para os decodificadores apropriados. e o DTS (decoding time stamp) que são informações de tempo necessárias em outros módulos do multiplexador. Todo fluxo elementar está associado a um número de programa específico o qual também faz parte das informações da PMT. as quais também devem possuir um PID (que mais tarde será utilizado no pacote TS com o payload preenchido com essa PMT). Esses dados serão armazenados no módulo Repositório Temporário. ou seja. Nas duas tabelas um campo de redundância é colocado para verificação de erros.2. Na etapa de leitura e armazenamento de pacotes PES considera-se que existam pacotes PES prontos para serem lido. assim a seção possui em seu cabeçalho seu tamanho em bytes para permitir calcular a quantidade de PIDs associados . A Program Map Table é responsável por associar fluxos elementares de um programa específico ao PID do pacote TS que os carrega. Quando as tabelas PAT estão sendo geradas as informações do número de programa e PID de cada programa também é consultado no Repositório Temporário. A geração das tabelas necessita das informações dos fluxos elementares que vão ser transmitidos. Após extrair as informações necessárias. a Program Association Table (PAT) e a Program Map Table (PMT). assim os tipos de fluxos e o PID de cada fluxo são armazenados em um módulo do multiplexador que obtém essas informações do analisador de PES e do gerador de PIDs. e serão utilizados em etapas seguinte da multiplexação. A quantidade de informações associadas em cada seção de tabela é variável. esse campo denominado CRC_32 possui o valor do cálculo do CRC da tabela sem incluí-lo. a PAT indica o PID do pacote TS que carrega uma tabela com o número de programa especificado nessa PAT.

Assim. no processo de multiplexação. Em um transport stream. em seguida três flags: a primeira que indica se há um erro no pacote . o controle mantém um sinal de tempo que indica o momento correto para enviar as informações de controle (tabelas PAT e PMT e pacote contendo PCR). os pacotes PES são divididos em pacotes menores com um conjunto de dados de cabeçalho próprios. seu primeiro byte é um byte de sincronia (sync_byte). O outro tipo é o Program Specific Information que na verdade é representado por dois tipos de informação. Estes pacotes contêm bytes codificados de apenas um elementary stream. entretanto para que haja consistência na exibição dos dados. Baseado neste processo. Dessa forma. áudio ou dados de controle (tabelas de associação). O armazenamento no buffer deve respeitar sempre o tempo de 0. a geração das tabelas PMT e PAT depende das informações do fluxo de dados que será enviado e dos PIDs desses fluxos. Geralmente os pacotes PES são muito grandes para serem transmitidos e por isso é necessário dividi-los em pacotes menores para que possam ser enviados. que traz informações relativas aos tempos de apresentação dos segmentos de informação. Empacotador TS Os pacotes PES são pacotes contendo vídeo. 2. chamado PID (Packet Identifier) [Tome 2001].5 segundo e um pacote contendo o PCR deve ser enviado a cada 0. Então. deve ser gerado um fluxo contínuo de bits empacotados na forma de Transport Streams.na demultiplexação. pois isto causaria uma colisão no processo de multiplexação.1 segundo. são enviados mais dois tipos de dados que são as informações de controle. O primeiro tipo é o Program Clock Reference. Do mesmo modo é necessária a informação de que tipo tabela está sendo multiplexada. é necessário que haja uma garantia de que o momento em que essas informações devam ser enviadas não seja o mesmo. Além desses. Como resultado desta multiplexação. de forma que depois de construídas essas tabelas são disponibilizadas em um buffer para o módulo de empacotamento de TS. que é uma tabela que identifica os fluxos que compõem o programa e determina o que cada um deles faz e a Program Association Table que associa cada programa a um identificador único durante todo o processo de transmissão. a Program Map Table. Por isso. 2. todos os dados necessários numa transmissão (vídeo. áudio e dados de controle) são multiplexados em um único feixe de Transport Streams.3.4. Uma vez que as tabelas PAT e PMT devem ser enviadas em um período de 0. tais como pacotes PES de áudio e pacotes PES de vídeo. a classe dispara um sinal para que sejam enviados pacotes Transport Stream contendo pacotes PES de áudio ou pacotes PES de vídeo. assim o cabeçalho da seção de uma tabela carrega o identificador de tabela que as distingue. Esses pacotes menores são chamados de Transport Streams. Controle do Multiplexador O controle tem por objetivo principal decidir quais os diferentes tipos de dados a serem multiplexados.5 segundo para o envio da seção atualizada da tabela. Caso não seja o momento de enviar informações de controle. as seções de tabelas depois de construídas são então armazenadas em um buffer que permite ao gerador de pacotes TS utilizá-las no preenchimento do payload do pacote. é preciso uma sincronia no envio de cada um dos tipos de dados descritos anteriormente.

Implementação do Multiplexador 3. o qual o percorre retirando as informações de alguns campos do cabeçalho. O segundo é um campo que contém vários bytes “setados” em “1” de forma a completar os 188 bytes do pacote TS. o módulo de empacotamento TS. o módulo irá preencher o payload do pacote TS a ser enviado com dados vindos do buffer de áudio e assim ocorre com todos os tipos de dados que devam ser enviados. não preencham todo o pacote TS.(transport_error_indicator). o pacote TS a ser enviado não pode conter apenas 160 bytes. essas tabelas têm tamanho menor que 184 bytes (tamanho comum do payload de um pacote TS). entretanto esses dados restantes são num total de 160 bytes. . caso os dados sejam de áudio. deve preencher o payload do pacote TS com dados vindos do buffer de vídeo. Nesse caso. Existe um subcampo no adaptation_field chamado PCR_flag que quando assume o valor “1” indica que o payload do pacote TS contém informações relativas aos tempos de apresentação dos segmentos de informação [Tome 2001]. Para resolver este problema. pois.1. como já foi especificado anteriormente. caso seja disparado um sinal indicando que deva ser enviado um pacote contendo dados de vídeo. o módulo de empacotamento TS deve preencher o campo data_byte (payload) dos pacotes TS que for enviar com esses dados. o pacote de vídeo teria mais 28 bytes compondo o campo adaptation_field. Independente de qual seja o tipo de dado a ser enviado. O primeiro indica qual é o tamanho do campo adaptation_field excluindo o tamanho do adaptation_field_lenght. 3. Para isso. Este processo de preenchimento de pacotes TS com stuffing bytes é comumente realizado quando é recebido um sinal de envio de tabelas PAT ou PMT uma vez que na maioria dos casos. a estrutura do pacote TS contém um campo chamado adaptation field. o módulo de empacotamento TS pode receber um sinal que indica que deva ser enviado um pacote TS contendo dados de áudio. Os outros bytes de um pacote TS são conhecidos como data_byte ou simplesmente o payload do pacote. eventualmente pode ocorrer que os dados a serem enviados. ela não é a única. um campo descrevendo o tipo de embaralhamento (transport_scrambling_control) além da presença de um campo de adaptação (adaptation_field_control) e a seqüência dos pacotes (continuity_counter). o pacote TS tem um tamanho fixo de 188 bytes. Pelo fato de que um pacote TS tem um tamanho fixo de 188 bytes. isto é. logo após existe um campo que identifica o pacote (PID). O adaptation_field tem o objetivo principal de manter o tamanho do pacote TS em 188 bytes mesmo que os dados a serem enviados não atinjam este tamanho. Apesar da funcionalidade principal do adaptation_field ser a de completar os 188 bytes do pacote TS. No exemplo citado acima. Analisador de PES A implementação do módulo analisador de PES consiste em uma classe que possui um método que recebe um arquivo com todos os PES de um único elementary stream. o adaptation field contém outros subcampos e entre eles destacam-se o adaptation_field_lenght e o stuffing_byte. a segunda que indica se este é o primeiro pacote de uma seqüência com mesmo PID (payload_unit_start_indicator) e qual a prioridade do pacote (transport_priority). Por exemplo.

Os valores constantes são aqueles como table_id que deve ter o valor 0x00 para uma seção de PAT e 0x02 para uma seção de PMT. o valor do stream_type correspondente será 0x02. foi implementada uma ferramenta que extrai pacotes PES a partir de arquivos transport streams. 3. ou com valores correspondentes a tabela vazia ou incompleta. Se o valor do stream_id estiver entre 192 e 223. Tabelas PSI A implementação das tabelas PSI consistiu em criar classes que descrevem os campos das seções da PAT e PMT. os campos reservados que são preenchidos com os valores padrões e no caso de uma seção PMT os campos section_number e last_section_number também são constantes com o valor 0x00. são indicações no tempo utilizadas na decodificação dos dados.O primeiro campo extraído do arquivo PES é o stream_id. todos os data_byte dos pacotes TS com o mesmo PID e que pertencem ao mesmo PES são inseridos em um arquivo que pode ser de vídeo ou áudio. valores temporários são usados. Os outros valores extraídos do arquivo PES correspondem aos atributos PTS e DTS.1. como o campo section_length que recebe o valor 0x09 na PAT que corresponde ao tamanho em bytes do campo . de acordo com [ITU 2000]. esse campo indica qual stream o pacote PES possui em seu payload. Essa ferramenta será discutida em seguida. também são armazenados no módulo Repositório Temporário.2. caso existam no arquivo PES. desenvolvida devido à necessidade de utilizar arquivos contendo apenas pacotes PES. Em posse do stream_id é possível determinar o stream_type do PES através da consulta de uma tabela de [ITU 2000]. assim um PES é formado pelos data_byte dos pacotes com esse campo com valor “1” e pelos de valor “0” até que um novo payload_unit_start_indicator tenha valor “1”. O extrator de PES recebe como entrada um arquivo transport stream e retorna um arquivo PES de áudio ou de vídeo. Os demais campos possuem os valores que variam de acordo com as informações carregadas na tabela. Os testes realizados no módulo analisador de PES utilizaram arquivos PES construídos de transport streams através da ferramenta Extrator de PES. No pacote encontrado é verificado o valor do payload_unit_start_indicator que será “1” sempre que um novo PES for encontrado. Caso o valor do stream_id esteja entre 224 e 239. section_syntax_indicator que tem sempre o valor 1. porém quando objetos dessas classes são criados (antes de ser inserida qualquer informação que preencherá os campos associados a PIDs). então de acordo com a tabela trata-se de uma stream de áudio que corresponde ao valor hexadecimal 0x04. cuja distinção é feita através da análise do campo stream_type nas tabelas PSI que devem ser analisadas antes. 3. Dessa forma. O valor desse campo é então armazenado no módulo Repositório Temporário. Esses campos a princípio são preenchidos com os valores constantes.1 Extrator de PES Considerando a necessidade de utilizar pacotes PES para o processo de multiplexação. A implementação do extrator de pacotes PES consiste em receber um arquivo de Transport Stream o qual é percorrido em busca do campo sync_byte indicando o início de um pacote.

como tipo e PID. é somado quatro ao valor do section_length da tabela. são inseridas através de um método que os recebe por parâmetro e ainda soma cinco ao valor do campo section_length. o qual é carregado no buffer.3. apenas o payload_unit_start_indicator tem o valor alterado. além disso. reserved e network_PID ou program_map_PID pois esses campos devem ser inseridos posteriormente sempre em conjunto. é alocado um buffer com todos os bits da tabela e em seguida. O algoritmo para o cálculo do CRC é baseado no algoritmo otimizado. reserved. reserved. Por fim. O campo adaptation_field_control pode assumir apenas dois valores: “01” caso o pacote não contenha adaptation_field e “11” caso contenha um adaptation_field seguido de um payload. Outros valores não são utilizados. o campo continuity_counter é incrementado em módulo 16 para pacotes com mesmo PID. os quais são usados em uma operação de “ouexclusivo” para encontrar o CRC final da tabela. Cada tipo de dados (vídeo. Em objetos PMT as informações de fluxo elementar. os campos das tabelas depois de preenchidos devem passar por um processo de mascaramento para obtenção apenas dos bits de cada campo para carregamento do buffer.O campo transport_scrambling_control é preenchido com o valor “00” indicando que não há embaralhamento no pacote. Uma vez tratados os campos do cabeçalho do pacote TS a ser enviado. Desse modo. Alguns dos campos desse cabeçalho são fixos. também não incluindo os campos stream_type. para calcular o CRC das tabelas PMT e PAT. Gerador de TS O envio de um pacote TS tem como primeira operação o preenchimento de um cabeçalho definido em [ITU 2000]. um buffer de 188 bytes (tamanho fixo de um pacote TS) é preenchido com o cabeçalho TS. ES_info_length e descritores caso existam. áudio ou dados de controle) é armazenado em um buffer exclusivo. assim. como o campo sync_byte que tem o valor 0x45. Como nas linguagens de programação os tipos primitivos possuem tamanhos na ordem de bytes. Na PMT o campo section_length recebe o valor 0x0d correspondente ao tamanho em bytes do program_number até program_info_length mais o CRC_32. Esta flag é “setada” com o valor “1” caso o pacote TS carregue o início de um pacote PES ou o início de uma seção de uma tabela PSI. as outras flags tem o seu valor mantido em “0”. a cada 8 bits da tabela o valor do CRC é calculado. O campo PID é preenchido com o valor armazenado no módulo Repositório Temporário relativo ao tipo de dado que está sendo empacotado. Nesse tratamento. Quando a classe de controle envia um sinal para que seja enviado um . é necessário preencher o campo data_byte que corresponde ao payload do pacote. 3. Para a PAT também há um método que recebe como parâmetro o número de um programa de uma tabela e o PID do TS que a carregará. Das três flags seguintes. pois pacotes contendo apenas adaptation_field não estão sendo enviados.transport_stream_id até o CRC_32 sem incluir o program_number. Após incrementar o valor do campo com o tamanho das seções da tabela um método para calcular o CRC é chamado tanto no método de inserção de programas quanto de inserção de fluxos elementares. visto que os campos inseridos somam cinco bytes. para isso. elementary_PID. é feito um tratamento para este preenchimento. as classes PAT e PMT utilizam um método que realiza esse mascaramento e concatenação dos bits de cada campo em um vetor de bytes.

tabelas PMT.4. estão sendo desenvolvidos cada módulo que a compõe e juntamente com o uso de estruturas de dados como buffers para que houvesse uma comunicação confiável entre os componentes do sistema além de tornar os mesmos. . Trabalhos Futuros A implementação da arquitetura em software encontra-se em processo de finalização. o pacote com PCR começa no tempo 0. facilitando assim o seu desenvolvimento. A seguir é preenchido o campo stuffing_byte. a flag PCR_flag recebe “1”. portanto agregar as funcionalidades de precisão do controle para sincronização e transmissão obedecendo rigorosamente aos tempos previstos para o empacotamento das diversas informações no pacote TS. O que pode ser enviado é TS de vídeo. foi proposta uma arquitetura. neste último caso. Uma vez definida a arquitetura do multiplexador. a tabela PMT começa a ser enviada no tempo 0. Este campo é preenchido com bytes de valor “1” para que o pacote TS contenha 188 bytes exatos. 5.5 segundo. Conclusão Com o propósito de implementar um multiplexador de Transport Streams para televisão digital. tabelas PAT e pacote com o campo PCR.525 segundos. Um pacote com tabelas PMT ou PAT deve ser enviado a cada 0. Através da conclusão da implementação em software e realização de testes de validação da multiplexação de transport stream será possível dar continuidade à metodologia de desenvolvimento da arquitetura através de sua descrição em uma linguagem de descrição de hardware.5 segundo. TS de áudio. Cada um desses pacotes deve ser enviado com uma freqüência determinada para que haja consistência na exibição dos dados. partes independentes do todo. O controle deve garantir que esses pacotes sejam enviados no tempo especificado e que não haja colisão no momento de enviar um determinado pacote. é inserido um adaptation_field no qual as 8 flags são “setadas” em “0” a menos que o pacote a ser enviado contenha um PCR. Controle do Multiplexador O controle é uma classe que possui como objetivo determinar o que será enviado pelo gerador de pacotes TS de acordo com o tempo. a tabela PAT começa no tempo 0. restando. 4.pacote contendo vídeo. é feita uma leitura num buffer de vídeo e caso os dados contidos no buffer não sejam suficientes para preencher os 184 bytes restantes do pacote TS (uma vez que 4 já são utilizados pelo cabeçalho). Para evitar colisão no estouro do tempo entre os tipos de pacotes foi escolhido um tempo inicial para envio de modo que esses tempos nunca colidissem. Os módulos desta arquitetura foram baseados nos diferentes tipos de dados a serem multiplexados (Pacotes PES de áudio e vídeo. tabelas PSI e pacotes contendo PCR) e no tipo de dado resultante do processo de multiplexação (Transport Stream).5125 segundos. um pacote com PCR deve ser enviado a cada 0. 3.1 segundo e o controle deve alternar entre TS’s de áudio ou vídeo de modo que haja sincronia na exibição.

F. (1997) Analysis and Design of Digital Systems with VHDL. at All (2001) “Relatório Integrador Dos Aspectos Técnicos e Mercadológicos da Televisão Digital”.anatel. .0.int/ Tome. (1995) Redes de Computadores: Das Lans. S.br Dewey A. G. Mans e Wans às Redes ATM.itu.Com a finalização desse processo. ITU (2000) “Infrastructure of audiovisual services – Transmission multiplexing and synchronization – ITU-T Recommendation H. 6.. http://www. de modo que a finalização dessa implementação não causará grandes mudanças no processo de multiplexação. http://www. and Colcher. Editora Campus. Lemos. outros testes de validação serão empregados para que a modelagem da arquitetura através de linguagem de descrição de hardware possa ser realizada. L. Referências Soares. Versão 1. Por conseguinte. visto que os teste realizados possibilitarão validar a implementação concluída. Editora PWS Publishing Company.0”. G. T.gov.222. em curto prazo essa arquitetura deve ser descrita em VHDL [Dewey 1997].