Resumen

  • BMPEG combinaba slices de vídeo completos, tramas de audio completas, un reloj de imagen de 90 kHz y un Audio Offset firmado en una sola secuencia RTP.
  • Ese contrato permitía interpretar el paquete, no afirmar que los bytes llegaron, que el estado MPEG era válido, que el A/V salió sincronizado o que un espectador percibió el programa.

El objeto parecía más completo que su evidencia

Un paquete BMPEG tenía la apariencia de un programa en miniatura. El vídeo ocupaba la primera parte; el audio seguía detrás. El encabezado RTP aportaba secuencia, tiempo y fin de imagen. El encabezado específico declaraba el tipo de imagen, si habían cambiado los encabezados de vídeo, cuántos bytes de audio llevaba el paquete y a qué distancia temporal empezaban.

El diseño atacaba costes reales de 1998. Una sesión de vídeo bajo demanda podía usar un puerto por programa. El servidor evitaba separar material ya almacenado de forma intercalada. El cliente no pagaba dos rutas de puerto, y el encabezado conjunto reducía algo el overhead. El ejemplo de la RFC calculaba cerca de un 1 % sobre contenido de 4 Mbps.

También era posible dimensionar mejor el buffer común y controlar el ancho de banda total del programa. La especificación llamó “implícita” a la sincronización resultante. Lo implícito era la asociación dentro del transporte; la reproducción seguía siendo una acción posterior.

Agrupar cambiaba la distribución del riesgo

La RFC 2343 era Experimental y no establecía un estándar de Internet. Presentó una elección: renunciar a parte de la modularidad de flujos separados cuando el ahorro y la coordinación conjunta fueran más importantes.

Un puerto simplificaba, pero unía fallos. La pérdida de un paquete podía llevarse vídeo y audio. La selección independiente de medios se volvía más difícil. Un paquete mayor podía cruzar el path MTU y fragmentarse. Un cambio del codificador podía exigir nuevo estado justo cuando el receptor intentaba recuperarse.

BMPEG también eliminaba información de la capa systems de MPEG que juzgaba redundante con RTP. La eliminación de campos no eliminaba la función. La trasladaba al contrato entre packetizer, receptor y aplicación. Dos implementaciones podían aceptar la misma sintaxis y tomar decisiones diferentes sobre buffering, ocultación o resincronización.

El packetizer debía construir puntos de reinicio

Los encabezados MPEG tenían posiciones disciplinadas. Un Video_Sequence_Header, si aparecía, comenzaba la carga. Un GOP_header comenzaba allí o seguía al anterior. Un Picture_Header comenzaba la carga o seguía al GOP. Cada paquete contenía un número entero de slices de vídeo.

Eso reducía el trabajo necesario para volver a una frontera conocida. No impedía la fragmentación IP. Ajustar tamaño de slice y cantidad por paquete para no superar el MTU era responsabilidad de la aplicación. Si el paquete excedía el límite, capas inferiores podían fragmentarlo y complicar incluso la clasificación de servicios integrados.

El audio cubría la duración del segmento de vídeo mediante tramas enteras. Una sola trama de audio podía abarcar más tiempo que el vídeo de un paquete, de modo que los paquetes siguientes podían no llevar audio. Repetir la última trama era una opción de resiliencia.

La validez estructural no contestaba si un fragmento faltaba, si la repetición sonaba artificial o si el siguiente audio llegó antes de que el buffer quedara vacío.

Orden de red, orden de decodificación y orden de presentación

El timestamp RTP usaba 32 bits y un reloj de 90 kHz. Identificaba el tiempo de muestreo de la imagen y era igual en todos los paquetes de esa imagen. Marker señalaba el paquete con el final de la imagen.

Las imágenes B rompían cualquier lectura ingenua. Para decodificarlas era posible transmitir en un orden distinto al de presentación, por lo que el timestamp no tenía que aumentar siempre. Los paquetes que sólo llevaban encabezados adoptaban el tiempo de la imagen siguiente. El número de secuencia continuaba describiendo orden de transporte.

Audio Offset expresaba, en muestras con signo, la diferencia entre el comienzo de la trama de audio y el timestamp del paquete. A 44,1 kHz cubría aproximadamente ±750 ms. La RFC advertía que una cadencia tan baja como una imagen por segundo podía quedar fuera de alcance.

El audio no se reordenaba junto con las imágenes B. Seguía el orden de transmisión y usaba el offset para indicar cuándo debía sonar. Por tanto, un offset correcto sólo daba coordenadas. No certificaba la conversión a un reloj de salida, la latencia del dispositivo ni la sincronía que percibía una persona.

Localizar daño no era recuperar información

Una combinación de sequence number y timestamp permitía detectar pérdidas. El slice number y la posición del primer macroblock ayudaban a estimar la zona dañada. Si la pérdida quedaba dentro de una imagen, el decoder podía continuar y repetir píxeles de una imagen anterior. Para el audio podía introducir ruido de fondo u otra trama sustitutiva a fin de esconder el hueco y mantener lip-sync.

El resultado podía ser reproducible sin ser auténtico. Los píxeles repetidos y el sonido insertado eran decisiones de concealment, no reconstrucciones del material perdido.

El bit N advertía un cambio en los encabezados de secuencia, extensión, GOP o imagen. Si se perdía ese estado, descartar datos hasta un nuevo inicio podía ser más seguro. Tras pérdidas fuertes, el receptor podía necesitar un nuevo sequence header.

BMPEG no incluía un contador de imagen equivalente al temporal reference usado como ayuda en RFC 2250. La pérdida de un GOP_header podía pasar inadvertida y causar decodificación errónea de imágenes B posteriores. La aceptación del paquete no demostraba que la historia necesaria para interpretarlo siguiera completa.

Del socket a la audiencia había varios mundos

Había que probar, por separado, llegada dentro del plazo; reensamblado de fragmentos; integridad de los paquetes de la imagen; estado correcto de secuencia, GOP y picture; decodificación; cálculo de los tiempos de salida; renderizado; camino físico de pantalla y altavoz; y presencia de audiencia.

RTP no reservaba recursos ni garantizaba calidad de servicio. Un paquete válido podía llegar tarde. Una imagen completa podía depender de un encabezado anterior perdido. Un decoder podía producir un frame que el renderer descartaba. El vídeo podía quedar oculto o el audio silenciado. Incluso una pantalla encendida podía no tener nadie delante.

La contribución de RFC 2343 fue definir con precisión un lenguaje de empaquetado conjunto. Esa precisión no amplió la autoridad del paquete. Mostró exactamente dónde terminaba.