¿Qué es MPEG-TS?

MPEG-TS (flujo de transporte MPEG-2) es un contenedor dividido en paquetes que multiplexa los flujos de video, audio y datos de uno o más programas junto con las tablas que los describen; los archivos que lo contienen suelen utilizar la extensión .ts. Fue diseñado para entornos propensos a errores, como la transmisión de radiodifusión.

Un flujo de transporte MPEG divide los flujos elementales y las tablas de señalización en paquetes de tamaño fijo de 188 bytes, cada uno etiquetado con un identificador de paquete (PID) de 13 bits. Un receptor lee la tabla de asociación de programas en el PID 0, la sigue hasta la tabla de mapa de programa de cada programa y obtiene de ella qué PID transportan el video, el audio y los datos del programa. Un contador de continuidad en cada PID, excepto el PID de los paquetes nulos, ayuda a detectar paquetes perdidos, y un bit indicador de error de transporte en la cabecera de cada paquete, cuando está activado, señala al menos un error de bit no corregible en ese paquete. Las referencias de reloj del programa son las marcas de tiempo de las que se deriva la temporización del decodificador. Un flujo multiplexado puede transportar varios programas con bases de tiempo independientes. Como un receptor puede incorporarse a un flujo ya iniciado, las tablas normalmente se retransmiten de forma periódica; el estándar lo recomienda sin fijar una frecuencia.

Un paquete de flujo de transporte siempre tiene 188 bytes y comienza con el byte de sincronización 0x47; 4 de esos bytes corresponden a la cabecera, por lo que la estructuración en paquetes supone una sobrecarga de al menos el 2,1 % antes de los campos de adaptación, las cabeceras PES o el relleno. Algunos sistemas envuelven cada paquete con bytes adicionales: la transmisión satelital DVB añade 16 bytes de paridad Reed-Solomon para llegar a 204, y el demultiplexor de FFmpeg también busca una variante de 192 bytes, por lo que un analizador que presuponga una separación de 188 bytes entre inicios de paquete pierde la sincronización en esas capturas.
La tabla de asociación de programas en el PID 0x0000 enumera todos los programas y el PID de su tabla de mapa de programa, que a su vez enumera los PID de los flujos elementales de ese programa. HLS impone restricciones adicionales: cada segmento de flujo de transporte debe contener un solo programa y debe incluir una PAT y una PMT, que deberían ser sus dos primeros paquetes, a menos que un EXT-X-MAP las proporcione. Las marcas de tiempo y los contadores de continuidad también deben mantener la continuidad de un segmento al siguiente, a menos que la lista de reproducción indique una discontinuidad. Por tanto, una captura de radiodifusión con varios programas debe reducirse a un solo programa antes de poder utilizarse como segmentos HLS.
El contador de continuidad es un valor de 4 bits por PID que avanza de uno en uno en cada paquete que contiene carga útil y vuelve a cero después de 15. Se repite legítimamente en los paquetes que solo contienen un campo de adaptación y en un duplicado repetido inmediatamente una sola vez; puede dar saltos donde el flujo activa el indicador de discontinuidad, y no está definido en los paquetes nulos. Cualquier otro valor es un error de continuidad, cuyas causas enumera el RFC 6990: un paquete perdido, un orden incorrecto de paquetes o un paquete que aparece más de dos veces. Cuando la causa es una pérdida, la magnitud del salto indica el número de paquetes con carga útil que faltan solo módulo 16, por lo que perder exactamente 16, o cualquier múltiplo de 16, no deja ningún salto.
La remultiplexación permite extraer un solo programa de un flujo con varios programas e insertar o eliminar paquetes nulos para cambiar la tasa de bits de transporte sin volver a comprimir el audio ni el video. El remultiplexor puede tener que corregir los valores de referencia de reloj del programa, porque sus posiciones en el flujo cambian. La extracción por sí sola no deja un programa listo para HLS: el RFC 8216 recomienda que cada segmento H.264 contenga un fotograma IDR, y la especificación de creación de HLS de Apple solo acepta video H.264, HEVC, Dolby Vision o AV1, exige fMP4 en lugar de flujos de transporte para HEVC, exige que cada segmento de video comience con un fotograma IDR y exige que se desentrelace todo el contenido de origen entrelazado. Un programa de radiodifusión cuyo códec no acepten los reproductores de destino, o cuyos fotogramas clave no coincidan con límites de segmento utilizables, debe volver a codificarse, al igual que el video de radiodifusión entrelazado que deba cumplir la especificación de Apple.

Elige MPEG-TS para radiodifusión, IPTV, señales de contribución o entrega tradicional de segmentos HLS. Su resistencia a errores y su soporte de multiplexación añaden sobrecarga en comparación con los contenedores optimizados para el almacenamiento fiable de archivos.

Los Robots de Transloadit basados en FFmpeg incluyen MPEG-TS entre los formatos que pueden leer y escribir. /video/encode tiene una opción segment que divide su salida en partes para HTTP Live Streaming, cuyos nombres determina segment_prefix (el prefijo segment_ produce segment_0.ts, segment_1.ts, y así sucesivamente), y /video/adaptive empaqueta variantes para HLS, MPEG-DASH o CMAF y escribe la lista de reproducción o el manifiesto.

Explora los formatos de archivo y las capacidades de compresión de Transloadit

¿Qué es MPEG-TS?

Cómo funciona MPEG-TS

Datos clave

Cuándo es importante MPEG-TS

Cómo ayuda Transloadit con MPEG-TS

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional