Esse post não irá falar do Ginga.

Atualmente estou dedicando um tempo no estudo da norma brasileira de TV Digital, vou tentar documentar estas “descobertas”. Meu foco inicial é nos mecanismos de transmissão, particularmente no Transport Stream. Não sou um especialista muito menos vinculado a alguma instituição que faz pesquisa na área, mas quero mostrar alguns conceitos e aplicações práticas, por isso, é importante o leitor buscar outras fontes que explicam melhor a teoria e se necessário, por favor, me corrija.

Um breve histório: O padrão brasileiro de televisão digitial foi criado em conjunto com o Fórum de TV Digital e a ABNT. As normas são referentes a:

• Transmissão (ABNT NBR 15601)
• Conpresão de Audio e Video (ABNT NBR 15602)
• Multiplexação e Serviços de Informação (SI) (ABNT NBR 15603)
• Receptores (ABNT NBR 15604)
• Segurança (ABNT NBR 15605)
• Codificação de Dados (ABNT NBR 15606)
• Canal de Interatividade (ABNT NBR 15607)
• Diretivas de Operação (ABNT NBR 15608)
• Suites de Testes para o Middleware (ABNT NBR 15609)
• Certificação dos receptores (ABNT NBR 15610)

Como mencionado, a priori vamos focar no Transport Stream (TS) que um protocolo de comunicação para audio, video e dados. É um tipo de “recipiente” que pode conter vários formatos que são separados no mesmo arquivo.

Dois tipos de pacotes foram padronizados para os sinais gerados pelo MPEG: um chamado Program Stream que é otimizado para um armazenamento eficiente e assume que o decodificador tem acesso ao stream completo para fins de sincronização; já o outro outro, o Transport Stream foi projetado para transmitir os dados em tempo real mesmo em um meio não-confiável (o ar) sendo que o receptor pode começar a “ler” os dados da fonte a partir de qualquer momento (e não necessariamente no começo da transmissão), por isso é usado na transmissão ISDB-Tb (incluindo também DVB e ATSC). Em linhas gerais, o Program Stream é usado, por exemplo, num CD ou DVD e o Transport Stream para uma transmissão de televisão. Para que este mecanismo funcione, é adicionado regularmente ao stream uma informação de tempo (timestamps) fazendo com que a sincronização dos pacotes seja agrupada relativo ao timestamp mais recente ao invés de um ponto inicial apenas no começo da transmissão. O TS está especificado na norma ISO/IEC 13818-1.

O TS utiliza o conceito de programas. Cada programa é descrito numa tabela chamada PMT (Program Map Table) na qual possui um único PID (Program ID) e os elementary streams associados a este PID. Por exemplo: um transport stream utilizado na televisão digital pode conter três programas, para representar três canais de televisão. Suponha que cada canal consista de um video diferente, um ou dois streams de audio (ex.: o audio dublado e original) e qualquer meta-informação necessária (ex.: sinopse do filme). O teleespectador querendo assistir a um canal particular apenas tem que decodificar os payloads de cada PID associado ao programa escolhido. Ele pode ignorar o conteúdo do resto. Um transport stream com mais de um programa é chamado MPTS (Multi Program Transport Stream) e um transport stream com um único programa é chamado SPTS (Single Program Transport Stream)

Nesta série de posts vou me concentrar nas “meta-informações” – qualquer informação que não o payload – do transport stream, ou seja, aquilo que caracteriza o protocolo e não propriamente no conteúdo. Na prática, se abrirmos um arquivo TS através de um editor hexadecimal (ex: hexdump) notaremos nos primeiros bytes alguma coisa do tipo:

00000000 47 40 00 10 00 00 b0 11 00 01 c1 00 00 00 00 e0
00000010 1f 00 01 e1 00 24 ac 48 84 ff ff ff ff ff ff ff

Contudo é impossível analisar um Transport Stream pelo dump do TS pois a construção dele é dinâmica. O primeiro erro que cometi foi pensar que era facil extrair o video de dentro do TS apenas “removendo” as informações que não eram pertinentes.  (Isso é até possível, mas meus testes foram restritos, espero fazer um post a parte sobre o tema) Deste começo, a única informação confiavel (que não muda) é o primeiro byte 0×47 referente ao sincronismo. Estruturalmente podemos pensar o cabeçalho como algo:

struct ts_header {
uint8_t sync_byte;
uint16_t transport_error_indicator:1;
uint16_t payload_unit_start_indicator:1;
uint16_t transport_priority:1;
uint16_t pid:13;
uint8_t transport_scrambling_control:2;
uint8_t adaptation_field:2;
uint8_t continuity_counter:4;
} __attribute__((__packed__));
 
struct adaptation_field {
uint8_t length;
uint8_t discontinuity_indicator:1;
} __attribute__((__packed__));

Existem diversas bibliotecas para a manipulação do TS. Uma delas é a libdvbpsi que foi desenvolvida para decodificar e gerar tabelas do MPEG TS e DVB PSI. No site diz que roda nas plataformas GNU/Linux, Windows e Mac OS X.

Bom, isso foi apenas uma introdução, pretendo ir publicando meus avanços por aqui… Lembre-se não é um tópico fácil, estou conversando com bastante gente e tirando dúvidas básicas, muitas delas referente a especificação na norma.

–tm