Resumen

  • RFC 2038 obligaba a que un comienzo de slice MPEG apareciera en una posición que el receptor pudiera localizar sin recorrer la carga. Los bits B y E declaraban si el paquete comenzaba o terminaba en una frontera de slice.
  • Cada paquete de vídeo repetía Temporal Reference, Picture Type y los parámetros de vectores de movimiento aplicables. Tras perder un GOP Header o Picture Header, esos valores podían servir para reconstruir contexto limitado en la slice siguiente.
  • El hueco de secuencia y esos campos prueban una discontinuidad observada y unas entradas declaradas. No prueban slices anteriores, cabeceras auténticas, imágenes de referencia utilizables, decodificación correcta, reproducción continua ni calidad de servicio.

El receptor sabe que falta algo porque el número de secuencia salta de 1206 a 1208. Lo que no sabe todavía es dónde recuperar el significado. Si el paquete 1208 continúa una slice cuyo principio desapareció, sus bytes pueden estar intactos y aun así carecer de un punto seguro de interpretación.

Entonces aparece B=1.

Ese bit no devuelve el paquete 1207. Hace una afirmación más modesta: después de las cabeceras MPEG permitidas, la carga empieza con un código de inicio de slice. Junto a él viajan TR, P y los valores de movimiento que describen de forma abreviada la imagen. RFC 2038 permitió que el receptor descartara hasta ese punto y volviera a intentar el procesamiento.

La diferencia entre recuperar contexto y recuperar contenido es el centro del diseño.

MPEG necesitaba una salida del error que el paquete pudiera señalar

RFC 2038 partió de una limitación incómoda. El flujo MPEG contenía dependencias espaciales y temporales; la pérdida de ciertos datos podía inutilizar otros datos que sí habían llegado. A la vez, un cuadro grande debía dividirse para caber por debajo del MTU habitual de una red.

La fragmentación no podía tratar el flujo como una bolsa de bytes. Cuando estaba presente, un Video Sequence Header debía situarse al principio de una carga RTP. Un GOP Header podía abrir la carga o seguir al anterior. Un Picture Header podía abrirla o seguir al GOP Header. Cada cabecera del flujo elemental tenía que permanecer completa dentro de un paquete.

Estas reglas reducían la ambigüedad estructural, pero no resolvían la recuperación de una slice. MPEG formaba cada imagen con una o más slices y las concebía como unidades de recuperación tras pérdida o corrupción. Un decodificador normalmente avanzaba hasta el comienzo de la siguiente.

RFC 2038 hizo visible esa unidad. Un inicio de slice tenía que ser el primer dato del paquete —después de las cabeceras permitidas— o aparecer después de un número entero de slices completas dentro de la misma carga. La slice podía fragmentarse entre paquetes, pero su siguiente comienzo recuperable no quedaba escondido detrás de un fragmento arbitrario.

Por eso el receptor podía localizarlo sin escanear todos los bytes. La packetización había llevado una frontera interna del códec hasta la capa de transporte.

B y E eran coordenadas sintácticas

El encabezado específico de vídeo ocupaba 32 bits y seguía al encabezado RTP fijo. B, Beginning-of-slice, se activaba cuando el payload comenzaba con el código de inicio de una slice o cuando solo lo precedían un Video Sequence Header, un GOP Header o un Picture Header. E, End-of-slice, se activaba cuando el último byte de la carga cerraba una slice.

Así, un paquete podía abrir y cerrar material alineado; abrir una slice que seguía en otro paquete; terminar una que venía de antes; o ser un fragmento intermedio. El receptor podía elegir qué hacer con esas cuatro formas antes de entregar la carga al decodificador.

No obstante, B y E son datos procedentes del emisor. Un B activado no autentica el código de inicio. Un E activado no demuestra que llegaron los fragmentos anteriores. Los dos juntos tampoco enumeran las demás slices del cuadro. Para elevar la afirmación a sintaxis real hay que analizar el payload; para hablar de integridad hay que comprobar mucho más.

La frontera declarada es útil precisamente porque su alcance es pequeño. Permite decidir dónde intentar reanudar. No permite decir que ya no existe daño.

Cada paquete repetía la ficha mínima de la imagen

La otra defensa contra la pérdida estaba en la repetición. El campo TR, de diez bits, expresaba la referencia temporal de la imagen dentro del GOP y permanecía constante en todos sus paquetes. P, de tres bits, identificaba una imagen I, P, B o D y también se mantenía constante.

Los campos FBV, BFC, FFV y FFC procedían del Picture Header más reciente. Conservaban los indicadores full-pel y los f-codes de los vectores hacia atrás y hacia delante. En una imagen I todos eran cero; una P utilizaba la pareja hacia delante; una B podía emplear las cuatro piezas.

No era una copia completa del Picture Header. Era el subconjunto que la estrategia de resincronización necesitaba para volver a crear determinadas entradas del decodificador. La ganancia operativa provenía de que ese subconjunto aparecía en cada paquete de la imagen. Si el paquete con la cabecera original se perdía, una slice posterior no quedaba necesariamente desprovista de todo contexto.

La repetición ofrecía además una señal de discontinuidad. El apéndice proponía contadores separados para imágenes de referencia I/P y para imágenes dependientes B. Una discordancia entre la progresión esperada y TR/P podía indicar que se había perdido el GOP Header o el Picture Header.

“Indicar” no significa observar el paquete desaparecer. La comparación descubre que dos historias ya no encajan. No identifica la causa ni reproduce los bits ausentes.

La reconstrucción reconocía su propia incertidumbre

Para un GOP Header perdido, RFC 2038 sugería construir uno con time code nulo, repetir closed_gop del GOP anterior y activar broken_link. Para un Picture Header perdido, el receptor podía avanzar hasta el siguiente B y usar P, TR, los cuatro campos de vectores y valores por defecto dependientes del flujo.

La operación era suficiente para permitir un intento de procesamiento MPEG. No recuperaba el original. El time code nulo reemplazaba un dato desconocido. El flag anterior aportaba memoria local, no confirmación nueva. Los defaults provenían de la configuración del receptor. broken_link avisaba de que la continuidad de predicción no debía darse por sentada.

También era una recomendación, no una obligación de resultado. El apéndice decía que un receptor conforme podía adoptar otra estrategia o ninguna. La interoperabilidad estaba en los campos y sus significados; la política de ocultación o abandono seguía siendo local.

Descartar hasta la siguiente slice era una elección conservadora

Cuando un hueco en la secuencia RTP indicaba una pérdida, el receptor podía descartar todos los paquetes hasta hallar Beginning-of-slice. A partir de allí tenía el estado que la RFC consideraba suficiente para iniciar el procesamiento en la próxima frontera, quizá después de reconstruir las cabeceras.

En ese intervalo podían existir bytes sin errores. Se descartaban porque su dependencia era incierta. La estrategia prefería una pérdida visible y acotada a introducir datos cuyo comienzo semántico había desaparecido.

RTP no hacía más fuerte el hecho inicial. Sus números de secuencia aumentaban por paquete y ayudaban a detectar pérdidas y restaurar el orden del emisor. Pero RTP no garantizaba entrega, orden, tiempo ni calidad de servicio. Un hueco en una captura puede corresponder a pérdida, reordenamiento o una observación incompleta. La conclusión correcta es “se observó una discontinuidad”, no “la red destruyó este paquete por esta causa”.

El informe debe conservar la escalera de evidencia

Hay al menos siete peldaños: continuidad de secuencia; B/E declarados; códigos de frontera realmente analizados; TR/P y vectores repetidos; disponibilidad de las imágenes de referencia; resultado del decodificador; presentación temporal y observación del usuario.

Saltar de uno a otro produce afirmaciones falsas. Una frontera plausible no completa el cuadro. Un Picture Header reconstruido no demuestra cómo era el perdido. La aceptación del decodificador no prueba que la predicción utilizó una referencia sana. Un frame renderizado no prueba continuidad. Y la continuidad del proceso no equivale a experiencia medida.

RFC 2038 apareció como Proposed Standard en octubre de 1996 y RFC 2250 la dejó obsoleta en enero de 1998. El registro IANA actual conserva el tipo estático 32, MPV, a 90 kHz y referencia RFC 2250. Ni el estado histórico ni el registro demuestran uso presente o calidad.

Lo duradero es una disciplina: exponer la verdadera unidad de recuperación del códec y repetir solo el estado necesario puede detener la propagación del daño. La misma disciplina exige no llamar “imagen recuperada” a un simple punto desde el que el decodificador pudo volver a empezar.

Fuentes