Resumen

  • En RFC 5371, el bit T decide si el campo de número de tile es válido. Debe ser uno —y el receptor debe ignorar el número— cuando el payload solo contiene la cabecera principal o reúne partes de varias tiles.
  • El offset de fragmento localiza bytes dentro del codestream, pero no prueba continuidad; MHF describe material de cabecera, pero no recupera fragmentos perdidos; el marcador RTP termina la contribución de cada sesión, no todas las capas de una imagen.
  • La evidencia necesita conservar juntos valor, puerta de validez, contrato negociado y resultado del receptor. mh_id y prioridad se ignoran en el contrato base y solo adquieren semántica adicional bajo RFC 5372.

La columna existía; el objeto no

El encabezado de payload JPEG 2000 de RFC 5371 reserva dieciséis bits para el número de tile. En una tabla plana, eso parece una dimensión de análisis lista para usar. Sin embargo, el bit T funciona como autoridad sobre esa dimensión.

T=0 significa que el número es válido. T=1 significa que es inválido y que el receptor debe ignorarlo. El emisor tiene que marcarlo así en dos situaciones: cuando el payload transporta únicamente la cabecera principal, porque no hay datos de tile que numerar, y cuando contiene partes de varias tiles, porque un solo número no puede representar el conjunto.

Los dieciséis bits siguen viajando. Pueden contener cero, un residuo de memoria o un valor que casualmente parece razonable. La existencia física del campo no crea la entidad lógica “tile 0”.

Un pipeline que elimina T y conserva tile_number cambia el contrato. Luego puede calcular tasas de error, tendencias y responsables con una exactitud numérica que el paquete prohibía. No se trata de dato faltante; se trata de dato no aplicable.

La corrección exige almacenar el par y aplicar la puerta antes de indexar. Cuando T=1, la salida analítica debe ser “sin número de tile válido”, no un número tentativo.

La invalidez también contiene información

Ignorar el número no significa ignorar el evento. T=1 ayuda a entender el tipo de payload. Puede indicar una cabecera principal sin tile-part o una agregación con múltiples tile-parts.

Para distinguir ambos casos, el receptor necesita mirar MHF, los bytes del codestream y las fronteras de unidades de packetización. El bit invalida una lectura simple y obliga a consultar el contexto correcto.

Eso convierte la invalidez en una propiedad útil. Evita atribuir una cabecera común a una región particular y evita reducir un paquete con varias tiles a una sola. El protocolo prefiere perder una etiqueta cómoda antes que afirmar una asociación falsa.

La práctica de observabilidad debería hacer lo mismo. Un tablero maduro muestra “multi-tile” o “solo cabecera” cuando puede probarlo, y “tile no aplicable” cuando no. No rellena el hueco con el valor que ocupaba el campo.

Este diseño ofrece una regla general para registros de infraestructura: los bits de presencia, máscaras de validez y capacidades negociadas son parte del dato. No son metadatos prescindibles.

MHF decía qué había dentro, no qué sobrevivió antes

El campo MHF usa dos bits para clasificar la relación del payload con la cabecera principal. Cero: no hay cabecera. Uno: hay una parte no final de una cabecera fragmentada. Dos: hay la última parte. Tres: la cabecera completa está en el payload.

La clasificación permite observar mejor las pérdidas. Si desaparece un paquete con MHF=1 y llega el de MHF=2, el receptor sabe que tiene el final y puede detectar que la cadena anterior está incompleta.

No puede deducir que la cabecera se recuperó solo porque llegó el último fragmento. RFC 5371 advierte que, sin cabecera principal, la imagen no puede decodificarse. Un MHF=2 verdadero puede coexistir con un resultado inutilizable.

MHF=3 tampoco firma toda la imagen. Demuestra que ese payload contiene una cabecera principal entera. Faltan las partes de tile, los paquetes de imagen, la admisión del decoder y la salida.

La prueba tiene que seguir la cadena: material declarado, intervalos recibidos, cabecera parseada, codestream reunido, recursos aceptados e imagen producida.

Un offset preciso puede describir un hueco con precisión

RFC 5371 coloca en cada payload un offset de veinticuatro bits desde el comienzo del codestream de la imagen. Así, un fragmento que llega fuera de orden puede situarse en la posición correcta.

En una transmisión escalable sobre varias sesiones RTP, el primer paquete de una sesión puede comenzar con un offset distinto de cero. La coordenada pertenece a la imagen común, no a la sesión particular.

Ese mecanismo permite reunir capas y detectar discontinuidades. No acredita que todos los bytes anteriores hayan llegado. Un registro que solo conserva el mayor offset puede confundir alcance con cobertura.

La estructura correcta es un mapa de intervalos. Cada intervalo conserva frame, sesión, secuencia RTP, offset, longitud, bytes y flags. El análisis calcula huecos, solapamientos y conflictos. Si dos payloads ocupan el mismo rango con datos distintos, el offset no decide cuál es correcto; solo hace visible la contradicción.

La semántica del hueco depende de lo perdido. Puede ser cabecera principal, cabecera de tile-part o datos codificados. El porcentaje de bytes no mide esa autoridad. Una pérdida pequeña de cabecera puede bloquear una imagen completa.

El orden del codestream no era un acuse de entrega

RFC 5371 define tres unidades de packetización: cabecera principal, cabecera de tile-part y paquete JPEG 2000. El emisor puede incluir varias unidades en un paquete RTP, pero debe mantener el orden del codestream.

Si una unidad supera la MTU junto con los encabezados de red, puede fragmentarse. Un fragmento no puede compartir el payload con la unidad siguiente. Así se preserva una frontera que el receptor pueda reconstruir.

Estas reglas gobiernan la construcción. La red aún puede perder o reordenar paquetes. El número de secuencia RTP observa el transporte, el offset observa la posición en el codestream y las fronteras observan el parser. Ninguno reemplaza al otro.

Una secuencia ordenada con un hueco sigue incompleta. Una secuencia completa puede contener parámetros que el decoder rechaza. Un decoder puede aceptar y producir una imagen que el servicio considere insuficiente.

La observabilidad debe indicar en qué nivel se cerró la prueba. “Orden correcto” no debe convertirse en “imagen correcta”.

El marcador cerraba una sesión, no el universo de capas

El bit marcador RTP vale uno en el último paquete de la frame. Cuando el mismo frame se reparte por múltiples sesiones RTP, cada sesión marca su propio último paquete.

Un receptor puede ver el marcador de la capa base mientras otra capa continúa. También puede recibir todos los marcadores y conservar huecos interiores por pérdida. Puede incluso no saber que falta una sesión si perdió el manifiesto que definía el conjunto esperado.

Por eso, “marker recibido” es un evento de alcance local. Para declarar el frame completo hay que saber qué sesiones participaban, qué función tenía cada capa, qué intervalos llegaron y qué política de calidad acepta el producto.

Una capa base puede ser suficiente para continuidad operativa y no para una obligación de fidelidad. Esa decisión no está contenida en M=1.

Los sistemas que terminan el temporizador con el primer marcador tienden a mejorar artificialmente la latencia. Los que esperan toda capa sin distinguir objetivos pueden ocultar una degradación útil. La evidencia debe permitir ambas decisiones sin fingir que son la misma.

La prioridad de base debía ser ignorada

El campo de prioridad usa ocho bits y parece apto para ordenar colas. RFC 5371 indica que, en implementaciones que siguen solo esta especificación, el emisor debería poner 255 y el receptor debería ignorarlo.

RFC 5372 amplía el contrato. Define modos y cálculos de prioridad para aprovechar progresión, capas, resoluciones y componentes. También añade parámetros SDP para negociar esas funciones.

Leer prioridad RFC 5372 en una sesión base es un error de autoridad. Los bits existen, pero la semántica no está activa. Incluso con la extensión, una prioridad declarada no demuestra que la red la obedeció ni que el receptor recibió la capa.

Una promesa de servicio necesita cuatro pruebas: extensión negociada, valor válido, acción del scheduler y resultado medido. Mostrar un byte no basta.

El mismo límite se aplica a mh_id. RFC 5371 pide ponerlo a cero e ignorarlo en base; RFC 5372 le da reglas para compensación de cabecera. La presencia física precede a la autoridad semántica.

SDP acordaba cómo leer, no que se pudiera mostrar

El tipo video/jpeg2000 requiere tasa de reloj y muestreo de color. Todos deben soportar 90 kHz; otros valores son opcionales. Si se ofrece otra frecuencia, conviene ofrecer también 90 kHz con un payload type distinto.

Anchura y altura son máximos opcionales y tienen que aparecer juntos. La sintaxis admite valores hasta 4.294.967.295. Un máximo declarado no reserva memoria ni obliga al decoder a aceptar una frame real.

El parámetro interlace también gobierna la lectura. Si falta, el payload debe ser progresivo y tp=0. Si está presente, tp=1 y tp=2 separan campos impar y par, cada uno con media altura visual.

El acuerdo SDP define un sobre. Después hay que observar que los paquetes lo respeten, que el receiver tenga recursos, que el parser acepte la estructura, que los campos se emparejen y que la salida se muestre.

Un sistema que transforma “oferta aceptada” en “capacidad disponible” confunde autorización declarativa con estado operativo.

Autenticar al miembro no validaba su codestream

La seguridad de RFC 5371 distingue confidencialidad, integridad y autenticidad de la fuente. Un mecanismo puede confirmar que el paquete proviene de un miembro de la sesión RTP y que no cambió bajo el contexto protegido.

El miembro puede estar equivocado. Puede emitir T=0 con una asociación falsa, un offset inconsistente, una cabecera malformada o dimensiones que agoten recursos. La integridad preserva el error; no lo corrige.

Tampoco recupera pérdidas. Un paquete posterior íntegro no contiene el anterior. Una firma de MHF=2 acredita el mensaje del emisor, no la continuidad de la cabecera en el receiver.

Las menciones históricas a SRTP, IPsec y TLS para RTP sobre TCP deben leerse como contexto de 2008, no como receta actual ni prueba de despliegue.

El informe debe decir exactamente qué fue autenticado y qué fue validado por el codec. “Flujo seguro” es demasiado grueso si oculta un codestream imposible.

QoS también necesitaba medición

RFC 5371 exige vigilar pérdidas incluso si se solicitó un servicio QoS mejorado. Si la entrega no coincide con lo pedido, el receiver debe asumir best effort y actuar en consecuencia.

En best effort, la aplicación debe controlar que el flujo sea compatible con una competencia razonable frente a TCP, reducir tasa o capas, o abandonar si la pérdida es inaceptable.

Un hueco de offsets puede ser pérdida de red, retirada deliberada de una capa, cambio de suscripción o captura parcial. El mapa muestra el dónde; la telemetría de congestión ayuda con el porqué.

Sin esa relación, una adaptación prudente aparece como defecto y un fallo de red puede maquillarse como selección de calidad. Un byte de prioridad no resuelve la atribución.

La evidencia comercial de QoS debe incluir servicio solicitado, pérdida observada, acción de adaptación y resultado. La etiqueta por sí sola no es entrega.

RFC 9828 no heredó esta tesis

RFC 9828 define otro payload JPEG 2000 orientado a latencia de sub-codestream. Añade Main Packets, Body Packets, resync y campos de tiempo, calidad y resolución. Permite solapar encoding y envío bajo condiciones específicas.

El artículo BTW existente sobre RFC 9828 analiza por qué un primer paquete temprano no prueba latencia de pantalla, recuperación ni calidad completa. Esta pieza se detiene antes: analiza cuándo un campo presente tiene o no autoridad para describir la reconstrucción.

RFC 5372 ocupa otra frontera: activa semánticas adicionales en mh_id y prioridad. Ninguna extensión prueba su propia negociación en un caso real.

Mezclar los tres documentos crea un protocolo imaginario con todas las funciones disponibles siempre. La investigación debe identificar el payload, la extensión y la versión observados.

La continuidad histórica tampoco es despliegue. Que IANA conserve el registro video/jpeg2000 prueba el registro, no la población de equipos ni su comportamiento.

La especificación mínima incluía las puertas

La Minimum Initial Specification de Lu Heng es una lente editorial, no una motivación atribuida al IETF. Aplicada aquí, enseña que el mínimo común debe preservar aquello que las decisiones locales necesitarán y que no podrá recuperarse después.

Eso incluye el valor y su puerta: T con tile, el contrato con prioridad y mh_id, la lista de sesiones con cada marcador, la identidad de frame con cada offset. Incluye también los intervalos de bytes, la cabecera, el verdict del decoder y la salida.

No exige un decoder universal. Permite políticas locales de recursos y calidad siempre que la decisión deje un recibo comprensible.

Reality Layers impide el salto indebido. Un número de tile es una representación. Un número válido es una asociación protocolaria. Los bytes recibidos son un hecho de transporte. La imagen decodificada es un resultado. La utilidad para la persona es otro nivel.

La claridad no consiste en llenar toda celda. Consiste en decir cuándo la celda no tenía derecho a hablar.