Resumen

  • RFC 2032 prohibía dividir un macrobloque H.261 entre paquetes RTP. Cada paquete empezaba y terminaba en uno de esos límites y llevaba el estado necesario para interpretar el nuevo comienzo.
  • Reanudar el análisis no recuperaba el macrobloque ausente ni corregía una referencia dañada por la codificación entre cuadros.
  • Los mensajes opcionales FIR y NACK permitían solicitar un cuadro INTRA completo o señalar números de secuencia perdidos. La solicitud era una coordenada operativa, no una prueba del resultado.

Una transmisión puede recuperar su gramática antes que su imagen. La arquitectura de RFC 2032 se entiende mejor cuando esas dos recuperaciones no se cuentan como una sola.

El documento, publicado en octubre de 1996 como Proposed Standard, definió el transporte directo de vídeo H.261 sobre RTP. H.261 procedía de canales RDSI de velocidad fija y podía viajar dentro de tramas H.221 de 512 bits que combinaban vídeo, audio, datos y corrección de errores. El formato de Internet omitió esa envoltura y transportó el flujo Huffman. Su tarea no era prometer entrega, sino evitar que la pérdida de un datagrama volviera incomprensible todo lo que siguiera.

El macrobloque como frontera de contención

Una imagen H.261 se divide en grupos de bloques; cada grupo contiene 33 macrobloques y cada macrobloque representa 16 por 16 píxeles. RFC 2032 escogió ese elemento como unidad de fragmentación. Un paquete debía comenzar y terminar en un límite de macrobloque, nunca partirlo, y tampoco podía cortar entre la cabecera de un GOB y su primer macrobloque.

La razón estaba en el código de longitud variable. Tras una pérdida en una posición arbitraria, el receptor podía confundir el comienzo de un campo con la continuación de un código anterior. El límite conocido convierte al siguiente paquete recibido en una entrada sintáctica definida.

Pero la independencia sintáctica no es independencia visual. H.261 usa diferencias y predicción entre cuadros. Un macrobloque que se analiza sin error puede apuntar a una región de referencia ya dañada. El propio RFC advierte que la corrupción puede persistir hasta que los macrobloques afectados vuelvan a codificarse como INTRA. La frontera reduce el territorio de incertidumbre; no restaura los píxeles que faltan.

Un encabezado de cuatro bytes llevaba la memoria

SBIT y EBIT indican cuántos bits del primer y último octeto no son datos de vídeo. Así, una sintaxis orientada a bits cabe dentro de paquetes alineados a octetos.

GOBN identifica el grupo en el que empieza el paquete; cero indica un comienzo en la cabecera de imagen. MBAP conserva el predictor de dirección de macrobloque relativo al inicio del grupo. QUANT conserva el cuantificador aplicable al siguiente macrobloque. HMVD y VMVD conservan los datos de referencia horizontal y vertical con los que se reconstruyen diferencias de vectores de movimiento.

Son memoria de arranque, no certificaciones. MBAP no es una coordenada de una zona reparada en la pantalla: permite interpretar diferencias de dirección. Los vectores de referencia permiten obtener un movimiento, pero no validan la imagen anterior a la que ese movimiento remite.

Los bits I y V son indicios igualmente limitados. I anuncia un flujo compuesto solo por macrobloques INTRA; V anuncia el posible uso de vectores de movimiento. El RFC dice que pueden inferirse del flujo y permite que una implementación use los valores conservadores V=1 e I=0. Ayudan a elegir una ruta de decodificación segura; no inspeccionan cada macrobloque ni puntúan la calidad.

El final señalado no implicaba un cuadro completo

Todos los paquetes de una imagen llevan la misma marca temporal RTP, con reloj de 90 kHz. El bit marker se activa en el último paquete del cuadro para que el receptor no tenga que esperar el código de inicio de la siguiente imagen. Si un paquete contiene varias imágenes, la marca RTP corresponde solo a la primera y los tiempos posteriores se obtienen de las cabeceras H.261.

Esta información describe tiempo y cierre. El marker solo afirma que el emisor etiquetó ese paquete como último; no afirma que los números de secuencia anteriores llegaran. La secuencia RTP permite descubrir huecos, mientras que el envío UDP no da al emisor confirmación intrínseca de entrega. Recibir el final y recibir el conjunto completo son hechos distintos.

Contener no era corregir

RFC 2032 enumera tres formas de mitigar daño persistente: cuadros periódicos enteramente INTRA, ajuste de la frecuencia de refresco conforme a la pérdida y solicitudes del receptor después de detectar un fallo. Cada opción abre un posible bucle de control. Ninguna demuestra por sí sola que el bucle se cerró.

Con los límites y el contexto copiado, la sintaxis posterior puede sobrevivir. Aun así, la región perdida sigue sin datos, una referencia mala puede seguir contaminando la predicción y una corrección tardía puede quedar fuera de la ventana de reproducción. El formato protege la inteligibilidad futura. La restauración exige observar más eventos.

FIR y NACK dieron dirección a una petición

El RFC definió dos mensajes RTCP opcionales específicos de H.261. Full INTRA-frame Request usaba Payload Type 192 para pedir que el codificador produjera el próximo cuadro totalmente en modo INTRA; el SSRC identificaba al receptor solicitante. Negative Acknowledgement usaba el tipo 193: FSN nombraba el primer número de secuencia considerado perdido y BLP, un mapa de 16 bits, señalaba pérdidas entre los dieciséis siguientes.

FIR decía “renueva la base de predicción”. NACK decía “no vi estas posiciones”. Ambos convertían la observación local en una acción direccionable.

Sin embargo, eran opcionales y dependían de la topología. El texto advertía que las confirmaciones negativas podían ser perjudiciales con muchos participantes. El envío directo al puerto del codificador solo servía sin mixers ni translators, y el ejemplo IVS limitaba la función a grupos pequeños. El campo no podía demostrar que esas condiciones se cumplieran.

Un FIR capturado prueba que alguien pidió un refresco, no que la petición llegó ni que el codificador actuó. Un NACK capturado prueba qué secuencias consideraba ausentes el receptor, no que existiera retransmisión, que llegase antes del playout o que la imagen corregida alcanzase una pantalla. La intención de reparar y la reparación observada requieren pruebas diferentes.

El mínimo común terminaba antes de la experiencia

La idea de especificación inicial mínima de Lu Heng permite leer RFC 2032 sin exigirle más de lo que debía fijar. La norma compartió cortes legales, contexto de reinicio, tiempo, cierre de cuadro y sintaxis de retorno. La duración del búfer, el ritmo de refresco, el coste de una imagen INTRA y el retraso tolerable quedaron como decisiones locales.

La primacía del código en funcionamiento añade la disciplina probatoria: un diseño publicado, un encabezado generado correctamente, la entrega en ambas direcciones, la acción del codificador y la imagen mostrada a tiempo pertenecen a capas distintas. No se puede usar el nombre de un mecanismo para afirmar el resultado de toda la cadena.

RFC Editor marca hoy RFC 2032 como obsoleto por RFC 4587. Sin convertir este artículo en una historia del sucesor, queda una enseñanza suficiente: la norma proporcionó un lugar donde volver a entender y unas coordenadas donde empezar a pedir. Nunca convirtió esas posibilidades en una garantía de imagen restaurada.

Fuentes