TS / M2TS
專為廣播設計，接收者可以中途加入，一切都沒有盡頭。
MPEG 傳輸串流就是電視的傳輸方式。它的設計使接收器可以隨時開始解碼並從丟失的數據中恢復，這使得它在空中傳輸非常出色，但作為檔案卻很尷尬：沒有索引，因此搜索是猜測，並且持續時間通常是錯誤的或完全丟失。
2026年7月30日
系統原生即可開啟
這兩個系統都不會打開 .ts 或 .m2ts 檔案，儘管一旦其他檔案解碼後，它們都能很好地解碼其中的 H.264 或 HEVC。包裝紙再次成為障礙。
基本資訊
| 全名 | MPEG-2 傳輸流 |
|---|---|
| 種類 | 容器，設計用於傳輸而不是存儲 |
| 擴展 | .ts、.m2ts、.mts、.m2t |
| 已發布 | 1995，作為 MPEG-2 的一部分 |
| 資料包大小 | 188 位元組，固定 — 足夠小，損壞後幾乎不會丟失任何內容 |
| 內有影片 | 舊廣播上使用 MPEG-2，新廣播上使用 H.264 和 HEVC |
| 內部音訊 | AC-3、E-AC-3、AAC、MP2 |
| 索引 | 沒有。檔案中沒有任何內容說明任何特定時刻的存在 |
| 它來自哪裡 | IPTV 串流、DVB 和 ATSC 錄製、AVCHD 攝影機、藍光光碟 |
無開頭的格式
這裡的每個其他容器都假設您擁有整個檔案並且可以先讀取其標頭。 Transport Stream 的假設相反：您已在到達之前開始的廣播中途收聽，並將在您離開後繼續。因此，它會重複解碼器所需的一切——流佈局、定時參考、參數——每一分之一秒，永遠重複。
188位元組資料包也是同樣的想法。幹擾破壞了資料包；解碼器會遺失幾毫秒並繼續。圍繞一個大索引構建的格式將丟失檔案的整個其餘部分。
對於其目的來說，這確實是一個很好的工程，但對於磁碟上的檔案來說，它的形狀是錯誤的。一切使廣播具有彈性的因素都會使錄音變得笨拙。
為什麼錄音表現得很奇怪
如果沒有索引，想要 47 分鐘標記的玩家必須進行估計：將比特率乘以時間，大致跳到那裡，尋找下一個可解碼的幀。在恆定位元率廣播中，這一點很接近。在可變位元率錄製中，可能會延遲幾秒鐘，而在從中斷流拼接的錄製中，可能會延遲幾分鐘。
持續時間同源。玩家必須讀取整個檔案以了解其長度，或根據比特率進行猜測。這就是為什麼錄音有時會顯示錯誤的長度，或者沒有，以及為什麼擦洗條可能是虛構的。
修復是重新混合：讀取一次串流，然後將相同的視訊和音訊寫入具有真實索引的MP4或MKV。沒有任何內容被重新編碼，品質不變，並以磁碟速度運行。之後的查找是即時且準確的，因為檔案最終知道它自己的幀在哪裡。
用一個做什麼
- 只想看的話直接播放
擁有自己的解復用器的玩家在沒有任何準備的情況下打開.ts。尋找將是近似的——這是格式，而不是播放器——但對於觀看某些東西來說，這很好。
- 重新混合為 MP4 或 MKV（如果您保留它）
快速、無損，並且永久修復搜尋和持續時間。對於進入圖書館而不是被觀看一次的任何內容，請執行此操作。
- 保留 IPTV 串流
當 TS 作為即時串流而不是檔案到達時，這些都不適用：沒有任何內容可以索引，因為沒有任何內容結束。緩衝有網路問題。