TS / M2TS

Mọi vùng chứa khác ở đây đều giả định rằng bạn có toàn bộ tệp và có thể đọc header của nó trước tiên. Transport Stream giả định điều ngược lại: rằng bạn đã bắt sóng giữa chừng một buổi phát sóng bắt đầu trước khi bạn tới và sẽ tiếp tục sau khi bạn rời đi. Vì vậy nó lặp lại mọi thứ một bộ giải mã cần — cách bố trí luồng, các tham chiếu thời gian, các tham số — mỗi phần nhỏ của giây, mãi mãi.

Các gói tin 188 byte cũng theo cùng ý tưởng đó. Nhiễu phá hủy một gói tin; bộ giải mã mất vài mili giây rồi tiếp tục. Một định dạng được xây dựng quanh một chỉ mục lớn duy nhất sẽ mất toàn bộ phần còn lại của tệp.

Đây thực sự là một thiết kế kỹ thuật tốt cho mục đích của nó, và nó là hình dạng sai cho một tệp nằm trên đĩa. Mọi thứ khiến một buổi phát sóng trở nên bền bỉ lại khiến một bản ghi trở nên vụng về.

Không có chỉ mục, một trình phát muốn tới mốc phút thứ 47 phải ước lượng: nhân tốc độ bit với thời gian, nhảy đại khái tới đó, rồi lùng tìm khung hình giải mã được tiếp theo. Trên một buổi phát sóng tốc độ bit không đổi, điều này khá chính xác. Trên một bản ghi tốc độ bit thay đổi, nó có thể lệch vài giây, và trên một bản ghi được ghép từ một luồng bị gián đoạn, nó có thể lệch vài phút.

Thời lượng cũng có cùng nguồn gốc đó. Một trình phát phải hoặc đọc toàn bộ tệp để biết nó dài bao nhiêu, hoặc đoán từ tốc độ bit. Đó là lý do một bản ghi đôi khi hiển thị sai độ dài, hoặc không hiển thị gì cả, và là lý do thanh tua có thể chỉ là hư cấu.

Cách sửa là remux: đọc luồng một lần, và ghi cùng video và âm thanh đó vào một MP4 hoặc MKV với chỉ mục thật sự. Không gì bị mã hóa lại, chất lượng không bị đụng chạm, và nó chạy nhanh bằng tốc độ đĩa. Sau đó việc tìm kiếm là tức thì và chính xác, vì cuối cùng tệp đã biết các khung hình của chính nó nằm ở đâu.