Resumen

  • RFC 9627 permite solicitar un punto de refresco para determinadas capas de vídeo escalable, con menos alcance que un Full Intra Request que renueva el estado completo.
  • El par de capas actual y objetivo, los SSRC, el tipo de carga y el número de secuencia describen qué cambio se pidió y si un mensaje es repetición; no confirman admisión, emisión, llegada, decodificación ni presentación.
  • La trazabilidad completa une negociación, autoridad, validación, presupuesto de congestión, respuesta específica del códec, recepción, nuevo estado del decodificador y resultado visible.

El receptor quiere dejar la capa base y empezar a mostrar una capa superior. Envía la solicitud en el momento exacto en que el enlace tiene menos margen. El mensaje es pequeño; la respuesta que provoca puede no serlo.

Esa asimetría explica por qué RFC 9627 separa una instrucción precisa de una garantía inmediata. Layer Refresh Request, o LRR, pide al codificador un punto desde el cual el receptor pueda decodificar más capas. El codificador debe actuar cuanto antes, pero el control de congestión conserva la facultad de aplazar una imagen de refresco costosa.

La pregunta operativa no es solo si se envió la orden. Es quién puede demostrar cada cambio de estado y durante cuánto tiempo esa demostración sigue siendo válida.

El refresco modifica una cadena de dependencias

En una capa espacial normal, una imagen puede depender de la capa inferior del mismo instante y de imágenes anteriores de su propia capa. Para refrescarla, la nueva imagen deja de depender de ese pasado propio y el codificador promete que las imágenes futuras tampoco volverán a usarlo como referencia.

Las capas no incluidas pueden mantener sus dependencias antiguas. Por eso LRR no equivale a FIR. El Full Intra Request exige un punto de renovación más amplio del decodificador; RFC 8082 aclara cómo abarca las capas de un flujo escalable. LRR pretende pagar solo por la transición necesaria.

En el eje temporal, refrescar significa anidar la capa sobre niveles temporales inferiores y romper la dependencia con sus propios fotogramas anteriores. Si la estructura ya está anidada de forma inherente, la subida es posible sin LRR. Un sistema que solicite siempre un refresco temporal añade control y potencialmente bits sin crear una nueva capacidad.

Por tanto, no basta con detectar una imagen grande o una codificación intra. Hay que demostrar que la estructura de referencias adecuada a esa capa y a ese códec permite al receptor iniciar la decodificación.

La orden contiene contexto, no observación futura

LRR ocupa el valor FMT=10 dentro de los mensajes RTCP de feedback específico de carga. Cada entrada de control nombra el SSRC del emisor multimedia al que se dirige. El SSRC del encabezado común identifica a quien formula la petición; el campo común de fuente multimedia queda a cero porque las entradas llevan las verdaderas dianas.

La meta se expresa como TTID/TLID: nivel temporal y nivel espacial o de calidad. El tipo de carga indica cómo interpretar ese par. Los mismos números pueden significar otra cosa con otro mapeo; por eso una captura sin offer/answer ni tabla de payload types no conserva la semántica suficiente.

Cuando C=0, se pide refrescar todo hasta la meta. Cuando C=1, CTID/CLID declaran la capa más alta que el receptor ya puede decodificar y excluyen las inferiores. La meta no puede retroceder en ningún eje y al menos uno debe avanzar. Una petición que diga lo contrario se descarta.

El emisor aún debe validar que payload type e índices pertenecen al flujo que está transmitiendo. Superar el formato evita una orden imposible; no demuestra que la fuente tenga autorización local ni que el codificador haya reservado capacidad.

Además, la capa «actual» es la declaración del receptor al emitir la orden. No es una lectura firmada del estado posterior. La pantalla puede seguir igual aunque el tuple original fuera perfectamente veraz.

Repetir el número no multiplica los resultados

El número de secuencia tiene ocho bits y un ámbito concreto: el par formado por SSRC de origen de la orden y SSRC objetivo. Una orden nueva incrementa el número módulo 256. Una retransmisión de la misma orden lo conserva. El primer valor puede ser cualquiera.

El modelo procede de la fiabilidad del FIR definida en RFC 5104. El solicitante repite una orden pendiente según el calendario RTCP y deja de hacerlo cuando reconoce un punto de refresco completo o un intento que quedó dañado por pérdida. Si después necesita otro refresco, emite una orden nueva.

Así, la secuencia permite reunir copias de una misma intención y separar una intención posterior. No es un ACK. No contiene una decisión del codificador, ni un identificador de fotograma producido, ni la hora de envío, ni el estado del decodificador.

El wraparound añade otra cautela. El mismo valor reaparece tras 256 órdenes. Archivar solo «seq=12» destruye identidad; hacen falta sesión, tiempo, pareja de SSRC, payload type y tuple.

La prioridad de red puede vencer al deseo del receptor

RFC 9627 ordena producir el punto cuanto antes tras una solicitud válida, pero también obliga a respetar los límites del control de congestión. El refresco suele ocupar más que una imagen ordinaria. Forzarlo de inmediato puede empeorar la cola, elevar la pérdida y hacer que la mejora solicitada llegue demasiado tarde o perjudique a todos.

La implementación necesita estados que no oculten ese conflicto: recibida, inválida, autorizada, admitida, esperando presupuesto, planificada, emitida, recibida, reconocida, decodificada y mostrada. Una política de producto puede declarar fracaso por exceder el plazo aunque la espera haya sido correcta desde el punto de vista de congestión.

También debe conservarse el motivo. LRR no es la señal apropiada para pérdida o corrupción de imágenes. La norma exige no usarlo con esa reacción y recomienda Picture Loss Indication, definido en RFC 4585. LRR expresa un cambio deliberado: el receptor empezará a usar una capa antes descartada. Mezclar ambos motivos impide saber si la repetición solicita recuperación o expansión.

No existe una firma universal de finalización

H.264 SVC distribuye la capa entre identificadores temporal, de dependencia y de calidad. La renovación puede quedar completa solo cuando todas las capas pertinentes muestran la señal correcta en orden de decodificación. Una indicación PACSI agregada puede ocultar qué NAL unit y qué capa la originaron.

VP8, en el formato citado, ofrece escalabilidad temporal. El bit Y identifica un punto de cambio, pero afecta a todas las capas, de modo que responder a una meta estrecha puede tener un coste más amplio.

H.265 combina banderas de anidamiento con tipos NAL y admite satisfacción inmediata o incremental. Una imagen IRAP puede cerrar la petición, pero buscar únicamente el icono genérico de «keyframe» no interpreta todos los caminos válidos.

RFC 9628 define para VP9 el par TID/SID y recomienda incluir índices y referencias para reconstruir la dependencia. La prueba central no es el nombre de la imagen, sino que la nueva capa ya no dependa de material que el receptor no tiene.

La coincidencia sintáctica con TID/LID de RFC 9626 facilita observar capas. No convierte la marca en recibo causal. Un punto válido puede aparecer sin esa orden; una marca correcta puede perderse en red; un punto entregado puede no entrar en el decodificador o no llegar a la presentación.

Fuentes