FEC Pro-MPEG : PROTEGENDO SEU VIDEO OVER IP

 

Este documento apresenta informações sobre a RFC 2733, que aborda o funcionamento da função FEC D/L.

DEFINIÇÃO DA RFC 2733

A RFC 2733 é projetado como um formato genérico de carga útil para correção de erros, de forma que o protocolo seja aplicado para as seguintes propriedades:

- Independente do conteúdo a ser protegido, seja áudio ou vídeo, ou outro tipo de conteúdo;

- Deve ser flexível o suficiente para suportar uma grande variedade de mecanismos de FEC;

- Seja adaptável, de forma que a técnica de FEC possa ser alterada de maneira fácil sem sinalização de banda.

- Ter suporte à vários mecanismos diferentes para o transporte de pacotes FEC.

Para a geração dos pacotes FEC, a RFC propõe o uso da lógica XOR ou a paridade FEC anteriormente descrita, mas informa que qualquer código FEC pode ser utilizado. A RFC propõe vários esquemas diferentes para a implementação da lógica XOR em conjunto com o FEC, porém as descrições são superficiais. O esquema a seguir é informado a partir da RFC.

Figura 1- Funcionamento proposto para o FEC

O esquema apresentado acima é bem simples, porém eficiente. É um esquema FEC unidimensional conforme dito anteriormente. Os demais esquemas apresentados a seguir são um pouco mais complicados e apresenta uma maior dificuldade em sua implementação.

Figura 2 - Esquema 1 para o FEC

O primeiro esquema é muito simples e apresenta uma grande quantidade de pacotes desperdiçados. O esquema a seguir permite a recuperação de até dois pacotes em sequência.

 

Figura 3 - Esquema 2 para o FEC

 

Este esquema específico difere dos outros apenas transmitindo pacotes FEC.

O esquema tem menos sobrecarga de transmissão do que o esquema acima, mas é capaz de corrigir erros de rajadas para até três pacotes consecutivos, dependendo da temporização.

A recuperação é bem demorada, uma vez que um pacote afeta 4 pacotes FEC, e por conta disso, as ações são tomadas muito antes de serem recebidos os pacotes.

Figura 4 - Esquema 3 do FEC

 

O último dos três esquemas apresenta uma solução onde é possível a recuperação de até três pacotes consecutivos perdidos. Além disso, o receptor precisa aguardar quatro pacotes após o pacote perdido.

Os pacotes FEC da RFC são construídos a partir de um cabeçalho FEC e um payload para o pacote. Os detalhes da formação destes pacotes serão apresentados a posterior.

 

PRO-MPEG

 

O Fórum PRO-MPEG, formado em 1998, é uma associação de Broadcasters e Desenvolvedores de Programas, fabricantes de equipamentos e fornecedoras de componentes com o intuito de promover interoperabilidade entre equipamentos para o setor de emissoras de televisão, conforme as necessidades do mercado.

O Fórum foi formado para promover um padrão aberto para aplicações profissionais emergentes no mercado e já conta com mais de 130 membros ao redor do mundo.

O Fórum Pro-Mpeg, entre outros trabalhos, desenvolveu uma recomendação para a transmissão de fluxos MPEG-2 TS através de redes IP, conhecida como Pro-MPEG Code of Practice #3 release 2 (CoP). Esta recomendação aborda o uso do FEC nas transmissões de streaming, independente dos conteúdos estarem codificados em MPEG-2 ou MPEG-4.

O CoP é basicamente uma extensão da RFC 2733, abordada anteriormente, porém com algumas alterações referente a habilidade na correção de erros. O esquema CoP FEC propõe um algoritmo XOR bidirecional de muitas possibilidades, incluindo a configuração do tamanho da matriz. Sua implementação mínima é um FEC unidirecional, mas feito apenas através de colunas ao invés de linhas, conforme propõe a RFC 2733. A restrição para o esquema Pro-MPEG é que deve haver pelo menos uma coluna e não mais do que 20.  E pode haver pelo menos quatro linhas e não mais do que 20. Além disso, o número total de pacotes em uma matriz não pode exceder 100 pacotes. A aplicação da operação FEC ocorre em alguns dos cabeçalhos RTP, mas não ocorre na carga útil.

Importante mencionar que os pacotes durante a transmissão não devem estar fragmentados. Além disso, é exigido o uso do cabeçalho RTP para a transmissão dos pacotes, quando se utiliza a solução de FEC.

O CoP recomenda que a solução proposta suporte pacotes IP contendo, um, quatro ou sete pacotes TS, porém é necessário suportar outros tamanhos também. A solução deve suportar fluxos com pacotes de TS 188 bytes, porém podem estendida sua implementação para soluções que operam com 204 bytes.

O cabeçalho do RTP na RFC 2733 é sugerido como o formato do cabeçalho para esta aplicação. Sua formação contém o cabeçalho RTP comum, um cabeçalho FEC e, a carga útil. Como este formato só suporta 24 pacotes consecutivos para cada pacote FEC, é estudada uma proposta de extensão. A extensão sugere adicionar 32 bits ao cabeçalho FEC, compondo vários campos onde alguns podem ser utilizados para mais extensões.

Na construção dos pacotes FEC existem algumas regras, que incluem vários conceitos. A matriz é composta de uma largura L e uma profundidade D que são à largura e profundidade da matriz correspondida em pacotes. Os valores de L e D têm as seguintes restrições:

L x D ≤ 100

1 ≤ L ≤ 20

4 ≤ D ≤ 20

Com essas restrições fica opcional a implementação para calcular apenas uma coluna FEC ou a coluna e a linha FEC. Se o FEC de coluna e linha for construído, L deve ser igual ou maior que quatro, caso contrário, apenas a coluna FEC deve ser calculada.

O CoP descreve que, quando é enviado apenas a coluna FEC, o FEC é calculado com base em D pacotes consecutivos e, desta forma, apenas uma perda de pacote por FEC poderá ser corrigida.

Isso pode ser interpretado de duas formas:

- Ao calcular apenas a FEC de linha, a matriz também é uma dimensional;

- A matriz também pode ser bidimensional e, portanto, é capaz de corrigir erros de burst.

Isso significaria que uma perda de pacotes de até L pacotes consecutivos podem ser corrigidos.

Figura 5- Alinhamento da Matriz do Pro-MPEG

 

Com a matriz acima com L = 3 e D = 4, três pacotes consecutivos podem ser corrigidos. Isso também questiona a CoP em suas afirmações de que a FEC unidimensional é efetiva quando você experimenta erros aleatórios, mas apenas as duas dimensões são efetivas no caso de perda causadas por burst. Na verdade, a capacidade de corrigir a perda de pacotes por burst é determinada apenas pela variável L.

Ao transmitir os pacotes originais e os pacotes FEC, é sugerido que três portas são usadas para receber os fluxos. Claro, a porta original para receber os pacotes originais e, em seguida, duas portas para receber a coluna FEC ou a linha FEC. O motivo para o uso de duas portas para a recepção do fluxo FEC é suportar implementações usando apenas uma dimensão FEC.

O CoP inclui uma tabela que mostra a sobrecarga, a latência, a capacidade de recuperação e o tamanho do buffer necessário. O CoP trata de forma otimista as estimativas de cálculos. Existe um requisito para o padrão proposto afirmando que a coluna FEC é enviada primeiro do que os pacotes L e após o último pacote IP usado para formar o pacote FEC e, o mais tardar, os pacotes L · D depois. Este último critério define o tamanho do buffer no decodificador que deve receber pacotes L · D antes do último pacote FEC, uma vez que é determinado pelo codificador, quando os pacotes FEC são enviados. Também o último critério determina o atraso no decodificador ao receber os pacotes. O atraso máximo é comparado ao tamanho do buffer no decodificador e ao overhead de transmissão causado pelo FEC.

Analisando a recepção do conteúdo, este requisito requer pelo menos duas vezes o tamanho do buffer no decodificador, o overhead calculado na tabela é o overhead na transmissão, ou seja, quantos pacotes podem ser perdidos e ainda serem recuperados. Se o overhead na transmissão é calculado, o conteúdo recebido pode ser diferente.

Figura 6 - Tabela de Amostragem Overhead de Transmissão x Tamanho do Buffer do Decoder com Pro-MPEG FEC

O atraso é calculado usando uma largura de banda de 15 Mbps, que é uma largura de canal frequentemente utilizada para este tipo de transmissão. A partir da largura de banda, o número de pacotes recebidos por segundo pode ser determinado.

Esses cálculos são muito importantes, uma vez que eles descrevem a quantidade de memória necessária no decodificador e o que afeta o FEC na largura de banda. O tamanho do buffer no decodificador é calculado pelo fato de que o número máximo de pacotes entre a matriz recebida de pacotes originais e o último pacote FEC pertencente a esta matriz é L · D. Esta é realmente uma outra matriz inteira e isso significa que a memória no decodificador deve ser duas vezes maior que a própria matriz. Para os tamanhos calculados, um tamanho geral de pacote de 1500 bytes foi usado, pois é apenas para provar um ponto.

Todos os cálculos acima são cenários de pior caso, já que o decodificador deve ser capaz de lidar com essas situações. Claro que há casos em que o atraso é menor dependendo do tempo de chegada dos pacotes FEC e, do número de pacotes perdidos.

Alguns tamanhos de matrizes são operacionais com o overhead de transmissão em comparação com o número de pacotes que podem ser recuperados, mas alguns deles não tem um resultado satisfatório. Por exemplo, na primeira matriz proposta, a taxa de recuperação é de 10%, mas o overhead na transmissão é de 23%. Esses 13% de overhead que não tem efeito direto.

Existem outros tamanhos de matrizes que recuperam a mesma porcentagem de pacotes que os custos indiretos de transmissão representam. Neste caso, seria fácil argumentar que a matriz é utilizável, mas nos outros casos é inaceitável.

No decodificador, há um atraso na coleta de uma imagem completa do sinal de áudio e vídeo de aproximadamente 40ms sem a FEC aplicada ao sinal. O atraso depende da taxa de quadros, e os 40ms são o padrão para o sinal PAL.

Além deste atraso, há também um atraso no processo de codificação, dependendo do esquema de codificação. O atraso total na aplicação é importante, especialmente quando se trata de fins de contribuição porque o tráfego bidirecional ocorre quando, por exemplo, retorno do áudio. Para isso, um atraso do áudio de retorno de até menos de um segundo seria muito difícil para um falante ou similar.

Analisando o atraso causado pelo FEC, apenas as matrizes menores têm atrasos aceitáveis em comparação com o atraso já no decodificador. As matrizes grandes têm atrasos, que são até cinco vezes maiores do que o atraso no decodificador, e isso teria um efeito muito notável sobre o resultado final.

Esses atrasos são calculados com base em uma taxa de 15 Mbps. 

O atraso depende diretamente da taxa de bits, com uma taxa de bits baixa o atraso aumenta.

E ai o que achou ? Deixe seu comentário para que eu possa trazer mais conteúdos como esse