Resumo

  • A IESG aprovou draft-ietf-avtcore-rtp-jpegxs-3ed-07 como Proposed Standard em 14 de setembro, mas em 21 de setembro o documento ainda não tinha número RFC e aguardava dados dos autores na fila editorial.
  • Preservar implementações conformes à RFC 9134 dentro de suas funções não faz um receptor antigo decodificar o Temporal Differential Coding da terceira edição.
  • Um recibo de compatibilidade de edição deve ligar o estado normativo aos builds dos dois lados, ao SDP exato, ao fallback sem TDC e a testes de mídia com escopo declarado.

Uma cadeia de vídeo pode ter um documento aprovado e continuar sem uma imagem decodificada no outro lado. A aprovação da IESG, a publicação pelo RFC Editor, a atualização de video/jxsv pela IANA, a entrega do software pelo fornecedor, a aceitação dos parâmetros e a ativação em produção são eventos diferentes.

Em 14 de setembro de 2026, a IESG aprovou a revisão 07 de RTP Payload Format for ISO/IEC 21122 (JPEG XS) para publicação como Proposed Standard. Isso não é um Internet Standard e também não é o ato de publicar um RFC.

O estado público de 21 de setembro deixa a fronteira visível. O Datatracker mostra RFC Ed Queue. A fila do RFC Editor informa que o formulário inicial está pendente e que é necessária uma resposta dos autores. Ainda não há número RFC. A IANA precisa revisar a versão alterada, e o registro público video/jxsv continua citando a RFC 9134. Esses passos não significam rejeição técnica; significam apenas que a produção do documento não terminou.

Uma nova referência não desliga a antiga

A revisão diz que o futuro RFC tornará a RFC 9134 obsoleta. Na série RFC, essa relação muda a referência principal. Ela não desativa firmware, não invalida equipamentos instalados e não interrompe automaticamente fluxos sem TDC.

O desenho busca migração incremental. Implementações existentes que cumprem a RFC 9134 continuam válidas sob a especificação atualizada, e equipamentos legados seguem operando dentro do conjunto de funções que suportam. O limite está nessa última expressão. Continuidade do conjunto antigo não é suporte automático a recursos novos.

TDC acrescenta estado entre quadros

As duas primeiras edições do JPEG XS usavam codificação intra. A terceira introduz o Temporal Differential Coding, que aplica descorrelação temporal no domínio wavelet. Um codestream sem TDC pode ser decodificado como imagem independente. Um codestream TDC pode depender dos coeficientes reconstruídos do anterior: um frame buffer no vídeo progressivo e dois, um por campo, em conteúdo entrelaçado ou PsF.

Por isso aparecem o marcador SLI para slices TDC e fbblevel, o nível de largura de banda do frame buffer. fbblevel só pode estar presente quando TDC é usado e deve coincidir com o valor sinalizado na imagem. A mesma coerência vale para profile, level e sublevel.

Um receptor antigo pode permanecer conforme e útil para tráfego sem TDC, mas não possuir o perfil, a memória ou a lógica temporal exigidos pelo novo modo. Compatibilidade preserva um caminho comum; não fabrica capacidade.

O SDP define a tentativa concreta

O subtipo continua video/jxsv, com relógio RTP de 90 kHz e packetmode obrigatório. O SDP coloca jxsv/90000 em a=rtpmap e leva packetmode e parâmetros opcionais, como profile, level, sublevel e fbblevel, em a=fmtp.

No modelo offer/answer unicast, o equipamento que responde precisa suportar todos os parâmetros e valores oferecidos; caso contrário, deve rejeitar a sessão. Se aceitar, devolve exatamente os mesmos valores. Cabe ao ofertante escolher valores que espera encontrar no outro lado.

Essa regra impede uma aceitação ambígua, mas não cria fallback por conta própria. Depois da rejeição de TDC, é necessário provar que o emissor ou a orquestração consegue emitir outra oferta explicitamente sem TDC. Mesmo uma resposta positiva só confirma acordo declarativo. Ainda é preciso decodificar a amostra e observar buffer, tempo e imagem.

O recibo precisa caber no change ticket

O registro de compatibilidade deve reter a revisão 07 e o SHA-256; estados IESG, RFC Editor e IANA; número RFC quando houver; video/jxsv, payload type, clock, packetmode, perfil, nível, subnível, fbblevel e TDC; produto, build, firmware e configuração de emissor e receptor; oferta, resposta ou rejeição; fallback sem TDC; amostra, formato, frame rate, duração e condições de pacote; falha, correção, reteste, rollback e condição de saída.

O escopo acompanha o resultado. Um par e uma amostra progressiva não comprovam todos os níveis, conteúdo entrelaçado, gateways ou toda a planta. Uma falha TDC também não elimina o funcionamento sem TDC da RFC 9134. O resultado defensável é limitado: estes dois builds trocaram este fluxo nestas condições.

Fontes

  1. IETF Datatracker: revisão RTP de JPEG XS
  2. Histórico do documento
  3. Texto da revisão 07
  4. Fila do RFC Editor
  5. RFC 9134
  6. Registro IANA de video/jxsv