Resumo

  • O BMPEG da RFC 2343 combinava slices completos, frames de áudio completos, timestamp de imagem a 90 kHz, Audio Length e Audio Offset assinado.
  • Essa estrutura declarava como o emissor relacionava som e imagem; não provava chegada completa, estado correto, lip-sync, saída perceptível ou audiência real.

Um pacote com aparência de programa

O formato reunia muitos sinais convincentes. O vídeo vinha primeiro e o áudio, depois. O cabeçalho RTP indicava sequência, instante da imagem e fim da picture. Quatro campos adicionais informavam tipo I/P/B, mudança de header, tamanho do áudio e deslocamento do seu início em relação ao timestamp.

Para vídeo sob demanda, a simplificação era concreta. Um programa usava um único port. O servidor podia enviar conteúdo já intercalado sem separá-lo em duas sessões. O cliente evitava parte do custo de dois ports. O overhead caía e o buffer conjunto podia ser menor. No exemplo de 4 Mbps, o documento estimava aproximadamente 1% de economia.

A RFC chamou a coordenação de implicit synchronization. Isso queria dizer que o relacionamento temporal estava codificado no pacote. Não queria dizer que a saída havia sido medida.

A troca entre eficiência e modularidade

Publicado como Experimental, o RFC não especificava um padrão da Internet. Sua justificativa dependia de uma escolha: usar as vantagens do bundle quando elas fossem importantes o bastante para sacrificar a modularidade de áudio e vídeo separados.

Essa troca aproximava também os defeitos. A perda podia remover som e imagem juntos. Um receiver perdia flexibilidade para selecionar apenas uma mídia. Um pacote maior podia superar o path MTU e depender de fragmentação inferior. O estado necessário para interpretar um pacote podia ter sido transportado antes e já ter desaparecido.

O desenho omitia partes da camada systems de MPEG consideradas redundantes com RTP. O ganho vinha da redistribuição de deveres, não da extinção deles. Sender, receiver e aplicação ainda precisavam concordar sobre tempo, buffer, headers e recovery.

Fronteiras do codec viravam fronteiras do transporte

Video_Sequence_Header, quando presente, começava o payload. GOP_header começava ali ou vinha logo depois. Picture_Header começava o payload ou seguia o GOP. Cada pacote tinha um número inteiro de video slices.

As regras ofereciam pontos de reinício. Não impediam IP fragmentation. A aplicação precisava ajustar slice size e quantidade por packet para caber no MTU. Se não coubesse, camadas inferiores fragmentavam, ampliando o impacto da perda e criando problemas de classificação para serviços integrados.

O áudio seguia o vídeo em frames inteiros suficientes para cobrir a duração do segmento. Como um frame podia durar mais, pacotes seguintes podiam não trazer áudio. Repetir o frame anterior era uma estratégia possível contra perdas.

Tudo isso podia passar em um parser e ainda falhar no caminho. Conformidade não revelava fragmento ausente, buffer esvaziado, repetição audível ou atraso além do prazo.

Timestamp não era um relógio de parede na sala

O timestamp tinha 32 bits e frequência de 90 kHz. Todos os pacotes da mesma picture compartilhavam o valor. Marker identificava o pacote que continha o final da imagem.

Com B pictures, a ordem de transmissão não coincidia com apresentação, e o timestamp podia diminuir legitimamente. Pacotes só com sequence, extension ou GOP header usavam o tempo da imagem seguinte. Sequence number e timestamp, portanto, contavam histórias diferentes.

Audio Offset registrava em samples assinados a distância entre o início do frame de áudio e o timestamp do pacote. A 44,1 kHz, cobria aproximadamente ±750 ms. Em uma taxa muito baixa, como uma imagem por segundo, a própria RFC admitia que o formato talvez não funcionasse.

O áudio permanecia na ordem de transmissão quando o vídeo B era reordenado. O offset dizia quando deveria ser apresentado. Não mostrava que o receiver converteu o valor corretamente, que os clocks permaneceram alinhados ou que o hardware emitiu ambos no mesmo momento.

Recovery podia criar continuidade sem recuperar verdade

Gaps em sequence number e timestamp denunciavam perda. Slice number e primeira posição de macroblock ajudavam a dimensionar o dano. Se a perda ficasse em uma picture, o decoder podia avançar e repetir pixels de uma imagem anterior. Para som ausente, podia inserir background noise e tentar preservar lip-sync.

Essas técnicas construíam uma saída plausível, não os dados originais. Concealment ocultava o defeito; não o desfazia.

O bit N indicava que headers MPEG haviam mudado. Se o receiver perdesse o novo estado, descartar bytes até outro picture start podia ser necessário. Perdas severas levavam à espera por um novo sequence header.

BMPEG não carregava um contador específico equivalente ao temporal reference usado em RFC 2250. A perda de um GOP_header podia não ser detectada e causar decode incorreto de B pictures seguintes. Um payload parseável podia estar ligado ao contexto errado.

A evidência continuava em várias camadas

Era preciso observar entrega dentro do prazo, reassembly, conjunto completo de packets, headers válidos, decoder output, alinhamento dos clocks, renderização, tela e áudio físicos, estado mute/hidden e presença de público.

RTP não reservava recursos nem garantia QoS. Um packet válido podia chegar atrasado. Uma picture inteira podia depender de estado anterior ausente. Um frame decodificado podia ser descartado. A aplicação podia dizer “playing” enquanto estava oculta. Uma tela acesa podia tocar para uma cadeira vazia.

O mérito histórico da RFC 2343 foi delimitar bem a declaração do packetizer. Ela tornou som e imagem transportáveis como relação conjunta. Não deu ao pacote autoridade sobre o que acontecia depois.