Resumen

  • La IESG aprobó draft-ietf-avtcore-rtp-jpegxs-3ed-07 como Proposed Standard el 14 de septiembre, pero el día 21 todavía no había número RFC y la cola editorial esperaba información de los autores.
  • Que las implementaciones conformes con RFC 9134 sigan siendo válidas dentro de sus funciones no significa que un receptor antiguo pueda decodificar Temporal Differential Coding.
  • Un recibo de compatibilidad debe unir versión y hash del borrador, estados RFC/IANA, parámetros SDP, builds de ambos extremos, ruta sin TDC y pruebas de medios delimitadas.

Una norma puede avanzar mientras una sala de control permanece exactamente igual. El 14 de septiembre de 2026, la IESG aprobó la revisión 07 de RTP Payload Format for ISO/IEC 21122 (JPEG XS) para su publicación como Proposed Standard. Eso resuelve una decisión del proceso IETF. No asigna aún un número RFC, no instala un códec y no confirma que dos productos puedan intercambiar el nuevo modo.

La diferencia se ve en el registro del 21 de septiembre. Datatracker sitúa el documento en la cola del RFC Editor. La cola indica que falta el formulario inicial y se requiere respuesta de los autores. IANA debe revisar la versión cambiada. La ficha video/jxsv continúa remitiendo a RFC 9134. Son estados normales posteriores a la aprobación, no señales de que el protocolo haya sido rechazado. También impiden llamar al texto «el nuevo RFC» antes de tiempo. Y Proposed Standard no es Internet Standard.

«Obsoletes» cambia la referencia, no apaga el legado

La revisión 07 dice que el futuro documento dejará obsoleto RFC 9134. En la serie RFC, esa relación orienta al lector hacia la especificación sustituta. No invalida físicamente los equipos existentes, no revoca firmware ni impone una migración automática.

El propio borrador conserva una ruta incremental. Las implementaciones conformes con RFC 9134 siguen siendo válidas bajo la especificación actualizada, y las implementaciones heredadas continúan operando dentro de su conjunto de funciones. La última condición es decisiva: continuidad del conjunto antiguo no equivale a soporte del conjunto nuevo.

TDC añade memoria entre imágenes

Las dos primeras ediciones de JPEG XS usaban codificación intra. La tercera introduce Temporal Differential Coding, que descorrelaciona imágenes sucesivas en el dominio wavelet. Un codestream sin TDC puede decodificarse como imagen independiente. Uno con TDC puede necesitar coeficientes reconstruidos del codestream anterior: un búfer para vídeo progresivo y dos búferes, uno por campo, para vídeo entrelazado o PsF.

Por eso aparecen el marcador SLI para slices con TDC y el parámetro fbblevel, que expresa el nivel de ancho de banda del búfer. fbblevel sólo se utiliza con TDC y debe coincidir con la señalización de la imagen, igual que profile, level y sublevel.

Un receptor RFC 9134 puede seguir siendo conformante y útil para un flujo sin TDC, pero carecer de ese perfil, memoria o lógica temporal. La compatibilidad de diseño preserva una intersección; no agranda por decreto la capacidad instalada.

SDP decide qué intenta la sesión

El subtipo sigue siendo video/jxsv. La tasa RTP es 90 kHz y packetmode es obligatorio. En SDP, a=rtpmap transporta jxsv/90000, mientras a=fmtp incluye packetmode y parámetros opcionales como profile, level, sublevel y fbblevel.

En oferta/respuesta unicast, el receptor debe soportar todos los parámetros y valores ofrecidos o rechazar la sesión. Si acepta, devuelve los mismos valores. El oferente asume así la responsabilidad de proponer un conjunto que espera que el otro extremo soporte.

La regla evita aceptar una sesión ambigua, pero no inventa un reintento compatible. Tras rechazar TDC, debe comprobarse que el emisor o la capa de orquestación formula una nueva oferta sin TDC. Incluso entonces, una respuesta positiva sólo demuestra acuerdo sobre parámetros declarados. El contenido todavía debe decodificarse sin fallos visuales, temporales ni de búfer.

Una prueba que pueda reconstruirse

El recibo de compatibilidad de edición debería guardar la revisión 07 y su SHA-256; los estados de IESG, RFC Editor e IANA; el número RFC cuando exista; video/jxsv, reloj, tipo de carga, packetmode, perfil, nivel, subnivel, fbblevel y estado TDC; producto y build de emisor y receptor; oferta y respuesta exactas; resultado del fallback sin TDC; identidad, formato y duración de la muestra; condiciones de paquetes; errores, correcciones, nueva prueba, reversión y criterio de salida.

El alcance debe aparecer junto al resultado. Una pareja, un perfil y una muestra progresiva no certifican vídeo entrelazado, todas las pasarelas o todos los niveles. Un fallo TDC tampoco borra la operación no-TDC de RFC 9134. «Estos dos builds intercambiaron este flujo bajo estas condiciones» vale más que una insignia universal de compatibilidad.

Fuentes

  1. Datatracker: formato RTP para JPEG XS
  2. Historial del documento
  3. Texto de la revisión 07
  4. Cola del RFC Editor
  5. RFC 9134
  6. Registro IANA de video/jxsv