TS / M2TS

ここで扱う他のどのコンテナも、ファイル全体があって先にヘッダーを読める前提で作られています。Transport Streamはその逆を前提にしています——自分が到着する前から始まっていて、自分がいなくなった後も続く放送に、途中からチューニングして加わったという前提です。だからデコーダーに必要な情報——ストリームの構成、タイミングの基準、各種パラメーター——を、1秒に満たない間隔で永遠に繰り返します。

188バイトのパケットも同じ発想です。妨害で1パケットが壊れても、デコーダーは数ミリ秒を失うだけで処理を続けられます。1つの大きなインデックスを中心に据えた形式なら、そこから先の全部を失っていたはずです。

これはその目的においては本当に優れた設計であり、それがディスク上のファイルとしては誤った形になる理由でもあります。放送を頑丈にするすべての要素が、録画を扱いにくくしています。

インデックスがないため、47分地点を求めるプレーヤーは推測するしかありません——ビットレートに時間を掛け、おおよそそこへ飛び、次にデコードできるフレームを探します。ビットレートが一定の放送であればこれはかなり近い位置に着地します。可変ビットレートの録画では数秒ずれることがあり、中断されたストリームから継ぎ合わされた録画では数分ずれることもあります。

再生時間も同じ理由です。プレーヤーは長さを知るためにファイル全体を読むか、ビットレートから推測するしかありません。録画の長さが間違って表示されたり、まったく表示されなかったりし、シークバーが実質的な作り話になり得るのはこのためです。

解決策は再多重化です——ストリームを一度だけ読み込み、同じ映像・音声を、本物のインデックスを持つMP4やMKVへ書き出します。何も再エンコードされず画質はそのままで、ディスクの速度で進みます。その後はシークが瞬時かつ正確になります。ファイルがようやく自分のフレームがどこにあるかを把握したからです。