Resumen

  • RFC 3984 reconoció que las unidades de imagen H.264 y los conjuntos de parámetros que enseñaban al decodificador a interpretarlas podían llegar por rutas y momentos distintos.
  • La unión tardía, la pérdida de una actualización, la reutilización prematura de un identificador o una colisión entre fuentes podían dejar al receptor con paquetes correctos y reglas equivocadas.

El nuevo participante abre la sesión y el tráfico empieza de inmediato. Los números de secuencia parecen normales, los tiempos avanzan y no hay una ráfaga evidente de pérdidas. Pero las primeras imágenes se rompen. El receptor ve las consecuencias de una historia a la que no asistió: antes de su llegada, el emisor cambió un conjunto de parámetros dentro del flujo.

La RFC 3984 convirtió esa historia invisible en un problema explícito del formato de carga RTP para H.264. Su registro de estado, sus erratas y su historial en Datatracker sitúan el documento en febrero de 2005 y muestran que después fue sustituido por RFC 6184. Su aporte no se limita a fragmentar o agrupar unidades NAL. También explica cómo transportar las reglas persistentes que esas unidades dan por sentadas.

H.264 guarda parte de esas reglas en conjuntos de parámetros. El conjunto de secuencia, SPS, describe el marco de una secuencia codificada. El conjunto de imagen, PPS, contiene decisiones empleadas en las imágenes y sus slices. Allí pueden residir dimensiones, modos de codificación y mapas de grupos. En vez de repetirlos, la cabecera de cada slice incluye identificadores que remiten a los conjuntos correspondientes.

Esa referencia ahorra ancho de banda y, al mismo tiempo, crea memoria. El receptor debe poseer la versión correcta antes de procesar la unidad dependiente en orden de decodificación. Un identificador no transporta por sí solo la definición. Por eso un receptor tardío puede recibir cada paquete actual y no tener el contexto vigente.

La distinción no aparece en las métricas básicas de RTP. La RFC 3550 asigna a los números de secuencia funciones de detección de pérdidas y reconstrucción de orden, y a las marcas de tiempo la representación del instante de muestreo. Su estado, sus erratas y el registro Datatracker no hacen de esos campos un inventario de SPS/PPS. El reloj del transporte puede estar sano mientras el de configuración está atrasado.

RFC 3984 describió tres principios. En A, los conjuntos llegan de forma fiable fuera de banda antes de empezar RTP. En B, las actualizaciones llegan de forma fiable fuera de banda durante la sesión. En C, los conjuntos viajan dentro del propio flujo. El texto original recomendaba el canal fiable fuera de banda para A y B. Cuando la configuración viajaba dentro de RTP, necesitaba repetición, retransmisión o corrección de errores, porque una sola pérdida podía dejar sin significado a muchas unidades posteriores.

El parámetro sprop-parameter-sets servía para anunciar el estado inicial mediante unidades NAL codificadas en base64. Las reglas anunciadas debían preceder, en orden de decodificación, a las unidades que las referenciaban. Había además una advertencia esencial: el parámetro no era una declaración de capacidades. Decía qué configuración iba a usarse, no todo lo que el receptor sabía soportar.

El caso del participante tardío revela la tensión entre los principios. Si recibe el SDP inicial pero se perdió una actualización en banda ya ocurrida, empieza con un mapa antiguo. Si la actualización se envió fuera de banda, el coordinador necesita saber que llegó antes de dejar pasar imágenes dependientes. Si dos canales pueden escribir el mismo identificador sin sincronización, el receptor no puede deducir cuál es autoritativo sólo mirando los slices.

La señalización ofrece orden, no omnisciencia. La RFC 4566, junto con su estado, erratas e historial, define SDP como formato de descripción. La RFC 3264, con su estado, erratas y registro, serializa oferta y respuesta al impedir varias ofertas pendientes.

RFC 3984 recomendaba esperar el acuse de la señalización fiable antes de enviar NAL dependientes de un conjunto actualizado. Esa frontera reduce la carrera, pero una implementación todavía debe definir qué confirma: recepción del mensaje, validación, instalación o activación. Ninguno de esos pasos equivale por sí solo a mostrar la imagen final.

También importaba cuánto tiempo conservaba sentido un identificador. Si el emisor reemplazaba un PPS mientras quedaban slices antiguos en la red o en los buffers, esos slices podían resolver la misma referencia contra reglas nuevas. El documento sugería emplear un identificador no usado durante suficiente tiempo o asignar uno nuevo. La prudencia debía cubrir reordenamiento, latencia, cola de reproducción y memoria interna del decodificador.

En escenarios multipunto, el problema dejaba de ser sólo temporal. Dos fuentes podían elegir el mismo número para conjuntos distintos. Sin una autoridad que dividiera el espacio, reescribiera identificadores o aislara contextos, cada fuente sería coherente consigo misma y el receptor recibiría una contradicción. El identificador pequeño funcionaba como un recurso compartido que necesitaba gobernanza.

El documento de 2005 llegó a indicar que los principios B y C no debían combinarse sin sincronización suficiente. Separar rangos de identificadores entre canales era una posible defensa. No curaba una actualización perdida, pero impedía que el mismo nombre adquiriera dos significados silenciosos.

La RFC 6184, con su estado, erratas e historial, sustituyó a RFC 3984 y ya no sostuvo una preferencia general por el método fuera de banda. Admitió ambos y añadió negociación, incluido in-band-parameter-sets. La revisión obliga a formular bien la conclusión: no existe un único canal históricamente correcto; sí existe la obligación de declarar y coordinar el canal elegido.

La RFC 7798, su estado, sus erratas y su registro Datatracker muestran una preocupación comparable al llevar HEVC sobre RTP. Es evidencia de una clase persistente de problema, no una medición de despliegue ni una garantía de que todos los decodificadores reaccionaran igual.

La seguridad amplía el alcance. Una unidad de parámetros manipulada puede modificar la lectura de muchas unidades futuras. De ahí la atención de RFC 3984 a la integridad y a la autenticación del origen. El objeto que parece pequeño en bytes puede ser grande en autoridad.

Para investigar una entrada tardía hay que reconstruir más que el flujo actual. Se necesitan las ofertas y respuestas, los acuses, las versiones históricas de SPS/PPS, las unidades en banda anteriores, los cambios de tipo de carga y el horizonte de retención del receptor. Si esa historia no se conservó, la ausencia no puede remediarse contando paquetes presentes.

La aportación histórica de RFC 3984 fue hacer visible una doble temporalidad. El medio lleva imágenes; otro estado —a veces por otro canal— lleva su gramática. La resiliencia no consiste en suponer que ambos llegaron porque uno se ve. Consiste en demostrar que la gramática correcta estaba activa antes de cada dato que dependía de ella.

Fuentes