Resumo

  • RFC 3497 transportou HDTV SMPTE 292M sem compressão, a 1,485 Gbit/s, e estendeu a sequência RTP a 32 bits porque os 16 bits originais davam a volta em 336 milissegundos.
  • A extensão media perda e ordem, mas não fazia o fluxo fixo recuar. Em melhor esforço, o receptor tinha de abandonar a sessão quando o caminho deixava de ser compatível com uma vazão equivalente de TCP.

Dentro do estúdio, a premissa era física: havia um cabo dedicado entre a câmera e o equipamento de vídeo. Fora dele, a mesma torrente teria de compartilhar uma rede. RFC 3497 resolveu a primeira metade da passagem — como preservar o sinal — e recusou fingir que isso resolveria a segunda — quem forneceria 1,485 Gbit/s de capacidade segura.

SMPTE 292M carregava televisão de alta definição sem compressão em palavras de dez bits. A taxa era 1,485 Gbit/s ou 1,485/1,001 Gbit/s. Para usar conectividade IP de longa distância, o formato precisava conservar sinais de tempo, apagamento, imagem ativa e dados auxiliares que antes viajavam em uma interface serial contínua.

Cada linha podia ocupar um ou mais pacotes RTP. Os delimitadores SAV e EAV+LN+CRC não podiam ser fragmentados, pois o decodificador dependia deles para localizar as linhas. Depois do cabeçalho RTP vinha um cabeçalho de carga de quatro octetos. O bit marcador assinalava o fim do quadro, e um número de linha de onze bits mantinha contexto mesmo se o pacote de EAV desaparecesse.

Havia ainda a unidade de grupo de pixels. O arranjo 4:2:2 normalmente exigia pgroup de cinco octetos; 4:2:0 e 4:4:4, quinze. Quando a representação da fonte não era conhecida, um pgroup de um permitia corte em qualquer octeto, sem jamais autorizar a divisão dos delimitadores. O tipo video/SMPTE292M, a taxa obrigatória e o pgroup opcional faziam parte da descrição da sessão.

A velocidade encurtava radicalmente a utilidade do número RTP padrão. Com pacotes de pelo menos mil octetos, dezesseis bits davam a volta em 336 milissegundos. Isso era curto demais para distinguir perda, reordenação e pacote atrasado. O cabeçalho adicional trazia mais dezesseis bits, formando uma sequência de 32 bits e cerca de seis horas antes da repetição.

Era uma vitória do livro-caixa, não do regulador. A sequência longa dizia qual pacote faltou; não reduzia a fonte quando muitos faltavam.

Outros campos giravam ainda mais depressa. O relógio RTP de 148,5 MHz voltava em 21 segundos. A contagem de octetos do remetente em RTCP, em 23; a perda cumulativa, em 93. Quem quisesse totais desde o início precisava guardar externamente o número de voltas. Um painel que lesse a volta como reinício apagaria a história apesar de o protocolo funcionar corretamente.

RFC 3497 reconhecia a consequência operacional. O fluxo tinha taxa alta e constante, sem controle de congestionamento. Antes do overhead RTP, já era suficiente para negar serviço à maioria dos caminhos de Internet disponíveis na época. Seu uso deveria ser estreito: pontas adequadamente conectadas, redes privadas ou ambientes em que reserva e QoS fossem garantias reais.

Mesmo sob QoS, o receptor deveria medir perda para confirmar a entrega do serviço solicitado. Se a evidência dissesse o contrário, ele deveria assumir melhor esforço. A etiqueta não era uma ordem dirigida à realidade. Era uma hipótese que a realidade podia revogar.

No melhor esforço, a medição acionava uma obrigação. O receptor tinha de sair se a taxa de perda ficasse alta demais. A comparação era com uma conexão TCP no mesmo caminho e nas mesmas condições: seu rendimento médio deveria ser pelo menos igual ao do RTP. Se TCP não pudesse obter aquela vazão, o vídeo fixo estava ocupando capacidade sem responder à mesma pressão.

Como SMPTE 292M não podia diminuir gradualmente a linha, a saída do receptor era a única forma de satisfazer o critério. A boa instrumentação não virou janela de congestionamento; virou um disjuntor. Essa diferença separa visibilidade de governança operacional.

RTP carregava e numerava, RTCP relatava, SDP descrevia, IANA coordenava parâmetros. Nenhuma dessas funções provisionava um enlace. RFC 2914 explicava a necessidade de respostas compatíveis com a estabilidade do Internet. RFC 3550 atualizou RTP; RFC 4175 ampliou os formatos para vídeo não comprimido; RFC 8083 sistematizou disjuntores e RFC 8888 melhorou o feedback. São respostas posteriores ao mesmo limite, não prova de elasticidade escondida em RFC 3497.

A cadeia de recibos começa com uma sessão bem descrita, passa por pacote válido, fronteira de linha preservada, sequência contínua, tempo reconstruído e contadores corrigidos. Só depois vêm QoS entregue, convivência com TCP, imagem útil e segurança duradoura. Um analisador de pacotes pode aprovar os primeiros itens enquanto o caminho falha nos últimos.

O mérito histórico do RFC está em manter a especificação mínima dentro de seu mandato. Ele permitiu adoção interoperável sem declarar soberania sobre a capacidade compartilhada. Quando a promessa de serviço e os pacotes discordavam, a medição prevalecia — e, se necessário, o receptor ia embora.

Sources