Resumo

  • O registro video/jpeg2000 exige taxa de relógio RTP e sampling; largura e altura são máximos opcionais e devem aparecer juntas. A sintaxe aceita valores enormes, mas a negociação não é uma reserva de memória nem um teste de decoder.
  • O payload carrega offset absoluto, estado do main header, validade do número de tile e fronteiras de frame por sessão. Esses sinais permitem interpretar e localizar bytes, sem provar que todos chegaram ou formaram uma imagem aceitável.
  • mh_id e prioridade devem ser ignorados no contrato-base; RFC 5372 ativa semânticas adicionais. Oferta, transporte, integridade, reconstrução, admissão e exibição são decisões de autoridades diferentes.

Negociar é escolher uma gramática

O SDP não executa o codec. Ele alinha nomes e parâmetros para que emissor e receptor saibam qual gramática aplicar aos pacotes que virão.

No tipo video/jpeg2000, a taxa do relógio RTP e o sampling são obrigatórios. O sampling identifica espaços e subamostragens como RGB, YCbCr e grayscale. A taxa padrão é 90 kHz; implementações precisam suportá-la e podem suportar outras.

Largura e altura são parâmetros opcionais de máximo. Se um aparece, o outro também precisa aparecer. O domínio sintático vai até 2^32−1. Isso define o que o campo pode expressar. Não afirma que o receptor tenha memória para um frame daquele tamanho, que sua política permita a alocação ou que a imagem observada use o máximo.

Uma resposta SDP aceita uma declaração. A admissão acontece depois, em uma implementação concreta, sob carga concreta, com limites locais. Transformar aceitação de oferta em “capacidade disponível” transfere ao plano de controle uma decisão que ele não observou.

O recibo deve registrar os dois eventos: o envelope negociado e o veredito do decoder para cada frame real.

Um fallback de relógio ainda precisava funcionar

RFC 5371 exige suporte a 90 kHz e permite outros clocks. Taxas abaixo de 1000 Hz são desaconselhadas porque reduzem a resolução de medições RTCP como jitter.

Quando o emissor prefere uma taxa diferente, deve também oferecer 90 kHz em outro payload type dinâmico. O receptor pode selecionar a alternativa compatível.

Essa negociação não prova que timestamps posteriores estejam corretos. Não prova sincronização do relógio, comportamento do jitter buffer nem tempo de exibição. Ela só escolhe a escala em que esses eventos serão descritos.

Uma operação madura preserva a oferta, a resposta, o payload type efetivamente usado e amostras do clock observado. Sem isso, uma mudança de frequência pode parecer alteração de latência ou jitter.

O fallback também não é um resultado automático. É preciso mostrar que a alternativa foi escolhida e usada, não apenas oferecida.

Interlace fazia o máximo representar meia imagem

O parâmetro interlace muda a leitura do payload. Quando ausente, o fluxo deve ser progressivo e tp=0. Quando presente, tp=1 identifica o campo ímpar e tp=2 o campo par.

Nesse caso, a altura no main header é metade da imagem exibida. Um campo completo não equivale a um quadro visual completo. O receptor precisa receber o par correto e realizar o deinterlace.

Logo, três registros são distintos: SDP autorizou interlace; o pacote declarou odd ou even; o decoder emparelhou e exibiu os campos. Um não assina o outro.

Um contador que converte cada marcador em frame exibido pode dobrar o resultado ou aceitar metade do conteúdo. A relação temporal e a identidade do par precisam ser preservadas.

Essa é uma forma concreta do limite maior: parâmetros negociados ensinam como ler evidência, mas não constituem a evidência do resultado.

O offset localizava bytes sem reservar recursos

Cada payload RFC 5371 contém um fragment offset de 24 bits medido desde o início do codestream JPEG 2000. O receiver pode colocar um fragmento no lugar correto mesmo se ele chegar fora de ordem.

Em vídeo escalável distribuído por várias sessões RTP, o primeiro pacote de uma sessão pode ter offset diferente de zero. A coordenada pertence ao frame comum, não ao começo daquela sessão.

O campo é poderoso porque torna gaps observáveis. Se há bytes em 0–209 e 1610–3009, o intervalo intermediário continua ausente. O maior offset não prova cobertura contínua.

Também não informa quanto de memória o receiver reservará. Um offset válido pode apontar para uma região que excede sua política, ou compor um codestream cujos parâmetros requerem recursos recusados.

O mapa operacional deve unir frame, sessão, camada, offset, comprimento, sequência RTP e hash dos bytes. Depois, o decoder registra se aceitou aquela reconstrução.

Main header era pré-condição de leitura

RFC 5371 afirma que perder o main header impede decodificar a imagem. Os dados de tile podem chegar íntegros e coordenados, mas sem parâmetros comuns não formam uma entrada interpretável.

MHF descreve se o payload não contém header, contém uma parte intermediária, a última parte fragmentada ou o header inteiro.

Receber MHF=2 não garante as partes anteriores. Receber MHF=3 garante o header naquele payload, não o restante do frame. O flag classifica material; não mantém estado de entrega em nome do receiver.

A recomendação informativa sugere separar headers para simplificar recuperação. A implementação ainda precisa demonstrar que fez isso e que o mecanismo respondeu à perda.

Por isso, a admissão do decoder deve registrar a geração de header usada, cobertura de bytes, erros de parse e limites acionados. “Header visto” é um estágio, não a conclusão.

mh_id não era cache negociado no contrato-base

Os três bits mh_id parecem identificar uma geração de main header. Porém RFC 5371 diz que implementações apenas deste documento devem usar zero no emissor e ignorar o campo no receptor.

RFC 5372 dá a semântica de compensação: manter o mesmo ID enquanto parâmetros de encoding permanecem iguais, incrementar quando mudam, tratar rollover e permitir retenção no receiver sob condições definidas.

Aplicar esse comportamento sem extensão negociada cria estado invisível. Um receiver pode usar header antigo enquanto o sender acredita operar em baseline, ou uma ferramenta pode relatar recuperação que nunca ocorreu.

O contrato precisa guardar parâmetro SDP da extensão, ID, hash do header, geração de cache, motivo de substituição e resultado. O nome do campo não ativa a função.

Esse cuidado evita lock-in acidental: implementações não deveriam depender de uma interpretação privada dos bits reservados para interoperar.

O número de tile dependia de permissão explícita

O bit T decide se o número de tile de 16 bits é válido. Com T=1, o receiver deve ignorá-lo.

O emissor precisa invalidar quando o payload contém apenas main header ou quando agrega múltiplas tile-parts. No primeiro caso não há tile-part; no segundo, uma única etiqueta seria falsa.

Os bits continuam presentes, mas não têm autoridade de associação. Um pipeline que descarta T e mantém o número fabrica localização espacial.

Isso afeta diagnósticos de recurso. Um relatório pode culpar “tile 0” por pressão de memória quando o pacote era apenas header comum ou continha várias tiles.

Valores condicionais precisam ser armazenados como pares de validade. Nulo não basta se for impossível distinguir “ausente”, “inválido” e “não observado”.

Ordem de codestream não era sucesso do decoder

Main header, tile-part header e JPEG 2000 packet são packetization units. Várias podem dividir um RTP packet, desde que mantenham a ordem do codestream.

Uma unidade que excede MTU pode ser fragmentada. O payload com fragmento não pode misturar a unidade seguinte. A fronteira fica recuperável.

Essas regras ajudam parsing e isolamento de falhas. Elas não impedem perda, reorder ou corrupção fora do contexto protegido. Sequence number e offset ainda precisam ser analisados.

Mesmo uma sequência completa e ordenada pode ser recusada por dimensões, complexidade ou política. E um decode tecnicamente válido pode produzir qualidade insuficiente para o produto.

Por isso o pipeline de aceitação deve nomear cada etapa: unidade formada, intervalos completos, codestream parseado, recurso concedido, frame decodificado e saída exibida.

Marker terminava cada sessão separadamente

O bit Marker vale um no último pacote RTP do frame. Quando há várias sessões, cada uma marca seu próprio fim para aquele frame.

O primeiro Marker pode fechar a camada base enquanto outra continua. Todos os Markers podem chegar e ainda haver gap interior. Uma sessão inteira pode faltar sem ser percebida se o manifesto de camadas não estiver disponível.

O produto precisa definir se base layer é aceitável ou se todas são obrigatórias. Essa política não cabe no bit.

Um indicador de latência que para no primeiro Marker mede a fronteira de uma sessão. Um indicador de entrega que conta Markers mede eventos, não byte coverage.

O recibo completo combina conjunto esperado, Marker por sessão, intervalos, qualidade resultante e exibição.

Prioridade não reservava fila

No contrato-base, o emissor deve colocar 255 em priority e o receptor deve ignorar. RFC 5372 define modos de prioridade associados a progressão, camada, resolução e componente.

Mesmo com a extensão, prioridade expressa importância no payload. Não prova que uma fila de rede a leu nem que o resultado recebeu tratamento melhor.

Para uma promessa de serviço, é preciso registrar extensão, modo, valor, mapeamento para scheduler, ação e entrega medida. Sem isso, o byte é intenção sem execução.

Há uma simetria com SDP: ambos são declarações de controle. Um anuncia capacidade e outro importância. Nenhum substitui recursos ou resultado observados.

Cobrar pela declaração em vez da entrega cria incentivo para otimizar campos, não experiência.

Autenticação não aprovava o consumo de memória

RFC 5371 distingue confidencialidade, integridade e autenticação da fonte. Um mecanismo pode provar que o pacote veio de membro da sessão e que bytes protegidos não foram alterados.

O membro autenticado pode enviar dimensões excessivas, offsets conflitantes, flags incoerentes ou codestream malformado. Integridade preserva o input; o decoder ainda decide se o aceita.

Um pacote perdido não é recriado porque os demais são autênticos. Um header assinado continua incompleto se falta fragmento.

As referências históricas a SRTP, IPsec e TLS para RTP sobre TCP precisam ficar em seu contexto de 2008, sem virar recomendação automática atual.

O relatório deve separar identidade, integridade, admission control, decode e display. Chamar tudo de “mídia segura” apaga o risco de exaustão e erro estrutural.

QoS solicitado precisava ser verificado

O documento exige monitorar perda mesmo sob serviço QoS aprimorado. Se a entrega solicitada não ocorre, o receiver deve assumir best effort e se adaptar.

Em best effort, o fluxo precisa respeitar concorrência razoável com TCP, reduzir taxa ou número de camadas, ou sair quando a perda é inaceitável.

Uma camada ausente pode resultar de congestion control deliberado, não de falha. Um gap pode ser perda real. O mapa de bytes mostra o efeito; o registro de controle mostra a decisão.

Sem ambos, o time de decoder recebe culpa por material nunca entregue, ou o time de rede esconde perda como escolha de qualidade.

O envelope SDP não garante QoS e a prioridade do payload não comprova ação. Medição fecha essa lacuna.

RFC 9828 tratou da saída antecipada, não da reserva local

RFC 9828 criou payload posterior para sub-codestream latency, com Main/Body Packets, resync, tempo, qualidade e resolução. Ele permite iniciar transmissão antes do fim do encoding sob progressões definidas.

O artigo BTW já publicado sobre RFC 9828 pergunta se o primeiro pacote adiantado prova latência de tela e recuperação. Este texto não repete essa lente.

Aqui, a questão é quem decide se o envelope declarado pode ser convertido em recursos, bytes completos e output. O contrato de RFC 5371 organiza a entrada sem tomar a decisão do receiver.

RFC 5372 acrescenta outra camada contratual para header compensation e prioridade. Nenhum documento prova que uma implementação real ativou todas as funções.

Identidade do RFC, modo negociado e resultado observado precisam permanecer separados.

A especificação mínima deixa a decisão local visível

A Minimum Initial Specification de Lu Heng funciona aqui como lente declarada. Um padrão comum deve fornecer informação suficiente para decisões locais, sem fingir que conhece cada memória, decoder ou objetivo de qualidade.

O mínimo inclui SDP, frame/session/layer, sequence, timestamp, Marker, flags, offset, intervalos, extensão, estado do main header e veredito de recursos/decode.

Assim, o receiver pode impor limites próprios e ainda explicar por que recusou. O sender pode comprovar o envelope oferecido sem alegar a reserva do outro lado.

Reality Layers impede a promoção indevida. Parâmetro é declaração; pacote é observação; intervalo contínuo é reconstrução; admission é decisão; frame exibido é resultado.

RFC 5371 não reservou um edifício quando aceitou o teto. Ele definiu a planta mínima para que cada autoridade registrasse sua própria decisão.