Resumo

  • Toda carga RTP CellB começa com quatro valores de 16 bits: X/Y da primeira célula de 4×4 e largura/altura da imagem em pixels.
  • A RFC 2029 exige que códigos com vários bytes caibam inteiros em um pacote. Após uma perda, o pacote intacto seguinte começa em um limite de código e declara sua posição no quadro.
  • Essa autonomia contém a falha; não recupera a informação perdida. Cabeçalho, timestamp comum e Marker final não provam cobertura total, tabelas de quantização iguais, decodificação correta, continuidade visual nem qualidade de serviço.

Um pacote de vídeo comprimido pode levar consigo mais do que a região que continha. Se o receptor perde a fronteira entre instruções ou a posição acumulada no quadro, bytes posteriores chegam sem um ponto seguro de interpretação.

Publicada em outubro de 1996, a RFC 2029 desenhou a packetização de CellB para impedir que esse dano se propagasse sem limite. A solução não tentava fabricar a imagem perdida. Dava contexto local a cada pacote sobrevivente.

Coordenadas de células e dimensões de pixels

Oito bytes antecedem os dados CellB comprimidos. São quatro inteiros sem sinal, em ordem de bytes de rede: Cell X Location, Cell Y Location, Width of Image e Height of Image.

X e Y contam células, não pixels. Cada célula cobre um bloco de 4×4 pixels. Já largura e altura são medidas em pixels. Assim, a carga diz onde começa na grade de células e qual é o tamanho do quadro em que pretende ser colocada.

As dimensões só podem mudar entre quadros. Mesmo assim, aparecem em todos os pacotes. Se o pacote anterior sumir, o seguinte ainda traz o tamanho do canvas. O custo de repetir quatro bytes de dimensão compra independência em relação ao passado imediato.

O campo não valida a própria afirmação. Ele não demonstra que as células anteriores chegaram, que as coordenadas são coerentes entre si ou que a área inteira será coberta. O endereço ajuda a continuar; não funciona como inventário do quadro.

Um pacote não podia entregar metade de um código

O fluxo CellB combina instruções de comprimentos diferentes. Um código de célula usa quatro bytes. Um skip code de um byte avança de uma a 32 células. Outros dois comandos anunciam novas tabelas Y/Y ou U/V, cada qual acompanhada por 512 bytes.

O implementador pode escolher o tamanho do pacote, chegando a um quadro inteiro. A condição é que nenhum código multibyte atravesse a fronteira entre pacotes. Nem uma célula de quatro bytes nem a atualização de uma tabela pode ser cortada no meio.

Por isso, o pacote completo recebido depois de uma perda não começa como o fragmento final de uma instrução cujo início desapareceu. Ele oferece uma fronteira sintática. Seu cabeçalho, por sua vez, oferece a fronteira espacial.

Esse mecanismo permite ressincronização local. Não é retransmissão, correção antecipada de erro ou redundância de conteúdo. As células transportadas pelo pacote perdido não voltam. A RFC reduz a área de ambiguidade e torna utilizável o que sobreviveu.

O último pacote declarado não certifica o quadro

CellB usa timestamp RTP de 90 kHz. Todos os pacotes do mesmo quadro compartilham esse valor; o bit Marker identifica o último. Esses sinais ligam os blocos espaciais a uma unidade temporal.

O timestamp, contudo, não enumera os membros do quadro. Marker indica a terminação declarada pelo emissor, não a chegada de tudo que veio antes. O sequence number RTP pode revelar buracos e ajudar a restaurar a ordem de envio. A própria especificação RTP afirma que o protocolo não garante entrega, pontualidade, ordem de chegada ou qualidade de serviço.

É possível receber um pacote final com coordenada plausível e ainda ter uma lacuna no meio do quadro. O metadado prova o rótulo que acompanhou o pacote; não prova o conjunto ausente.

Uma tabela perdida muda pixels sem mudar posições

Os campos U/V e Y/Y de uma célula apontam para tabelas de vetores de crominância e luminância. O índice só produz o valor esperado se o decodificador tiver a mesma tabela usada pelo emissor.

A RFC 2029 define comandos capazes de carregar 512 bytes para substituir cada tabela. O par de encoder/decoder de exemplo não implementava o recurso, mas o documento previa que codecs futuros poderiam usá-lo. A regra de confinamento mantém a atualização recebida inteira dentro do pacote.

Se o pacote da atualização for perdido por completo, a situação muda. Um pacote posterior ainda pode começar em código válido, declarar a coordenada certa e pertencer ao timestamp esperado. Seus índices, porém, podem ser lidos com a tabela antiga. A geometria é recuperada e a cor é interpretada de forma errada.

Esse cenário é uma inferência dos campos definidos pela RFC, não o relato de um incidente histórico. Ele estabelece o limite mais claro do desenho: o pacote pode ser autônomo quanto à posição e ao parsing sem ser autônomo quanto a todo estado anterior.

A cadeia probatória continua depois do cabeçalho

Uma análise responsável separa sequence number, posição, sintaxe e enquadramento temporal. Depois verifica o estado das tabelas, o resultado do decodificador, a renderização e a entrega no ponto de consumo.

Para alegar quadro completo, é preciso comparar cargas e cobertura espacial. Para alegar pixels corretos, registrar a versão das tabelas e o resultado do decoder. Para alegar boa visualização, medir tempo, perdas e saída no terminal. Nenhuma dessas conclusões nasce apenas dos oito bytes.

O registro da IANA ainda mostra CelB como payload type RTP fixo 25, vídeo a 90.000 Hz, com referência à RFC 2029. Isso comprova a atribuição do parâmetro, não uso atual. A permanência da RFC como Proposed Standard também não prova implementação, interoperabilidade ou qualidade.

A contribuição histórica da RFC 2029 foi prática e limitada. Ela transformou cada pacote sobrevivente em um novo ponto de entrada espacial e sintático. Conteve o alcance da perda sem apagar a perda. A mesma precisão deve orientar qualquer afirmação posterior: saber onde a próxima célula pertence não equivale a saber que a imagem chegou inteira.

Fontes