TS/M2TS

Todos los demás contenedores aquí asumen que tienes el archivo completo y puedes leer su cabecera primero. Transport Stream supone lo contrario: que has sintonizado parcialmente una stream que comenzó antes de que llegaras y continuará después de que te vayas. Por lo tanto, repite todo lo que necesita un decodificador (el diseño de la stream, las referencias de tiempo, los parámetros) cada fracción de segundo, para siempre.

Los paquetes de 188 bytes tienen la misma idea. La interferencia destruye un paquete; el decodificador pierde unos milisegundos y continúa. Un formato creado alrededor de un índice grande perdería todo el resto del archivo.

Esta es una ingeniería genuinamente buena para su propósito y tiene la forma incorrecta para un archivo en un disco. Todo lo que hace que una stream sea resistente hace que una grabación sea torpe.

Sin un índice, un reproductor que quiere alcanzar la marca de los 47 minutos tiene que hacer una estimación: multiplicar la tasa de bits por el tiempo, saltar aproximadamente allí y buscar el siguiente fotograma decodificable. En una stream de velocidad de bits constante, esto se acerca. En una grabación con velocidad de bits variable, puede tardar unos segundos, y en una grabación dividida de una stream interrumpida, puede tardar unos minutos.

La duración tiene el mismo origen. Un reproductor tiene que leer el archivo completo para saber cuánto dura o adivinar a partir de la tasa de bits. Por eso a veces una grabación muestra una duración incorrecta o ninguna, y por qué la barra de fregado puede ser una obra de ficción.

La reparación es remuxing: lee la stream una vez y escribe el mismo video y audio en un MP4 o MKV con un índice real. No se vuelve a codificar nada, la calidad permanece intacta y se ejecuta a la velocidad del disco. La búsqueda posterior es instantánea y exacta, porque el archivo finalmente sabe dónde están sus propios fotogramas.