Resumo

  • A RFC 2038 organizava a packetização para que o começo do próximo slice MPEG pudesse ser localizado sem varrer os bytes do payload. Os bits B e E declaravam a relação de cada payload RTP com as fronteiras do slice.
  • Todo pacote de vídeo repetia o Temporal Reference TR, o Picture Type P e, quando cabível, os parâmetros dos vetores de movimento para frente e para trás. Se um GOP Header ou Picture Header desaparecesse, esses campos sustentavam uma reconstrução limitada no slice seguinte.
  • Lacuna de sequência, B/E e estado repetido justificam uma decisão local de retomada. Não provam os slices anteriores, a veracidade do cabeçalho, a imagem inteira, o quadro de referência, a decodificação correta, a reprodução contínua, o recebimento pelo público nem a qualidade de serviço.

O pacote 305 termina no meio de um slice. O 306 não chega. O 307 traz B=1, TR igual a 23, tipo P e os parâmetros de vetor para frente. O receptor não sabe reconstruir o conteúdo do 306, mas já sabe algo operacional: pode abandonar a continuação danificada, preparar um contexto substituto e tentar o processamento MPEG no novo começo de slice.

Essa retomada pode ser tecnicamente correta e ainda resultar numa faixa corrompida, num congelamento ou em nenhum quadro útil. O pacote perdido pode conter macroblocos indispensáveis; a imagem de referência pode faltar; o emissor pode ter marcado a fronteira de modo incorreto. A RFC 2038 não eliminou esses casos. Ela limitou o ponto a partir do qual o receptor deixava de tratar todos os bytes seguintes como semanticamente incertos.

A unidade de recuperação apareceu na fronteira do pacote

Vídeo MPEG comprimido contém dependências temporais e espaciais. Perder um trecho pode inutilizar dados posteriores que chegaram intactos. Ao mesmo tempo, imagens grandes precisam ser divididas para caber em pacotes menores do que o MTU comum da rede.

A RFC 2038 impôs uma disposição precisa. Um Video Sequence Header precisava começar o payload RTP. O GOP Header precisava aparecer no começo ou logo depois do Sequence Header. O Picture Header precisava começar o payload ou seguir o GOP Header. Cada um desses cabeçalhos do Elementary Stream devia caber inteiro em um único pacote.

O slice recebeu a regra mais reveladora. A RFC o descrevia como a unidade MPEG destinada à recuperação depois de perda ou corrupção. O início de slice podia ser o primeiro dado do payload, vir depois dos cabeçalhos MPEG permitidos ou seguir uma quantidade inteira de slices completos no mesmo payload. Ainda assim, um slice podia atravessar vários pacotes. A especificação jamais equiparou um pacote a um slice.

Esse arranjo retirava do receptor uma busca arriscada. Depois de uma perda, ele não precisava examinar cada byte dos próximos payloads à procura de um start code. O packetizador já havia colocado um ponto recuperável numa posição declarável. O codec definia a unidade significativa; o cabeçalho RTP específico a tornava visível ao transporte. Visibilidade não equivalia a autoridade sobre o conteúdo MPEG.

B e E informavam alinhamento, não completude

Um cabeçalho de vídeo de 32 bits seguia o cabeçalho fixo do RTP. B=1 indicava que o payload começava por um código de início de slice, talvez depois apenas de um Video Sequence Header, GOP Header ou Picture Header. E=1 indicava que o último byte do payload encerrava um slice MPEG.

As quatro combinações descreviam payloads que começavam e terminavam em fronteiras, começavam um slice que continuaria, continuavam e terminavam um slice anterior, ou continham somente um fragmento intermediário. Era possível classificar a forma antes de analisar profundamente os dados comprimidos.

Mas B=1 continuava sendo uma declaração do emissor. Não autenticava um start code real. E=1 não enumerava os outros fragmentos necessários. Um pacote alinhado nas duas pontas podia chegar depois de uma lacuna que removeu outra parte da imagem. Um pacote com os dois bits zerados podia estar fisicamente íntegro, mas não servir para nada sem o fragmento inicial.

O enunciado probatório correto é estreito: B/E demonstram o estado de fronteira carregado pelo cabeçalho. Confirmar a sintaxe MPEG, a integralidade do slice e a aceitação pelo decodificador exige observações independentes.

Cada pacote repetia um pequeno dossiê da imagem

Além do alinhamento, a RFC 2038 replicava estado de imagem. O campo TR, de dez bits, carregava o Temporal Reference da imagem dentro do GOP e permanecia constante em todos os seus pacotes. P, de três bits, identificava imagem I, P, B ou D e também ficava constante.

Quatro campos adicionais traziam as flags full-pel e os f-codes dos vetores de movimento para frente e para trás copiados do Picture Header mais recente. Imagens I zeravam todos; imagens P utilizavam o par para frente; imagens B podiam usar os quatro. Esse conjunto era muito menor do que o contexto comprimido original. Servia para refazer parte de um cabeçalho, não para refazer a imagem.

Sem a repetição, perder o pacote que continha o Picture Header podia deixar o próximo slice sem tipo de imagem ou regras de interpretação dos vetores. Ao aproximar esses valores de toda fronteira potencial, o formato rompeu a dependência no próximo slice utilizável.

Valores repetidos também podiam denunciar inconsistência. Mudanças inesperadas em TR e P sugeriam perda de GOP Header ou Picture Header. O apêndice propunha contadores para imagens de referência e dependentes e comparava a progressão esperada com o Temporal Reference declarado. Divergência mostrava que expectativa local e declaração recebida já não coincidiam; não revelava os bytes originais do cabeçalho nem a causa do desaparecimento.

Reconstruir significava produzir um substituto explícito

Para um GOP Header perdido, a RFC sugeria um time code nulo, o closed_gop do GOP anterior e broken_link=1. Para um Picture Header perdido, o receptor podia usar P, TR, os quatro campos de vetor e valores padrão dependentes do fluxo na próxima indicação Beginning-of-slice.

Esses dados não recuperavam o cabeçalho byte por byte. O time code nulo não era o valor emitido. Repetir uma flag anterior não observava o novo GOP. Um padrão era uma suposição do receptor. O próprio broken_link=1 preservava a ruptura em vez de fingir continuidade.

O resultado fornecia uma estrutura utilizável para tentar decodificação. Não certificava que as dependências preditivas estavam presentes ou que o resultado visual estaria correto. A diferença entre substituição e recuperação é parte central do mecanismo.

A lacuna autorizava contenção de dano

O procedimento do apêndice começava com uma lacuna nos números de sequência RTP. O receptor podia descartar todos os pacotes seguintes até encontrar Beginning-of-slice. Ali haveria estado suficiente para reiniciar o processamento MPEG, possivelmente depois de reconstruir GOP Header ou Picture Header.

Números de sequência RTP avançam com os pacotes de dados transmitidos e ajudam a detectar perda e restaurar a ordem do emissor. O RTP, porém, não garante entrega, ordem, prazo nem QoS. Uma lacuna observada por um receptor não distingue sozinha perda física, reordenação ou captura incompleta, e tampouco descreve o conteúdo ausente.

Descartar até B é uma política de contenção. Sacrifica bytes que talvez estejam perfeitos para evitar que uma continuação sem começo chegue ao decodificador. A retomada local nasce do reconhecimento de que parte da história é desconhecida.

Sete observações precisam continuar separadas

Uma auditoria deve distinguir: continuidade da sequência RTP; declaração B/E; sintaxe de fronteira MPEG realmente analisada; estado TR/P/vetores repetido; disponibilidade e integridade das imagens de referência; saída e ocultação de erros do decodificador; reprodução temporal e observação do público.

Uma camada pode orientar a coleta da próxima, mas não substituí-la. B/E coerentes não provam imagem completa. TR/P plausíveis não são o cabeçalho perdido. Sintaxe válida não prova previsão correta. Um quadro decodificado não prova apresentação contínua. Um evento do player não prova que uma pessoa recebeu ou aceitou o vídeo.

A RFC 2038 saiu em outubro de 1996 como Proposed Standard e foi substituída pela RFC 2250 em janeiro de 1998. O registro atual da IANA lista o payload type estático 32 como MPV, a 90 kHz, e cita a RFC 2250. É evidência de atribuição no registro, não de implantação atual, uso numa rede específica ou desempenho.

O ensinamento duradouro não depende da longevidade do formato: resiliência melhora quando a verdadeira unidade de recuperação do codec aparece na fronteira do pacote e o mínimo de estado necessário é repetido perto dela. A fronteira permite tentar novamente; não torna inteira a imagem anterior nem a posterior.

Fontes