カメラ収録のタイムコード（TC）を後処理で調整する方法

2026-03-22

LTC・NDI・ATEMで、現場のフレームを1点に揃える技術

この記事は「映像IPシステム設計シリーズ」の応用編だ。 タイムコードを「記録の証拠」としか思っていないなら、今日から認識が変わるはずだ。

「映像はバッチリ届いているのに、なぜか編集でズレる」──あの感覚の正体

マルチカメラの現場に立ったことがある人なら、一度はこの状況に直面したはずだ。

スイッチャーのマルチビューを見ると、カメラAとカメラBで拍手のタイミングが微妙にズレている。SDIで繋いでいたときはこんなことなかったのに、NDIやSRTを使い始めてから「なんとなく合わない」が常態化してきた。

あるいは、外部レコーダーで収録したデータを編集室に持ち込んだとき、タイムコードがカメラ本体の映像と数秒ズレていて、マルチカム編集が機能しない。

こうしたトラブルの根本には、共通した認識の欠如がある。

「映像を届ける」ことと「時間を揃える」ことは、まったく別の問題だ──という認識だ。

IP伝送が「時間」に対して無関心な理由

SDIケーブルの時代、映像の「時間」はジェンロック（Genlock）という仕組みで統一されていた。全機材が同じ同期信号（ブラックバースト or トライレベルシンク）を参照し、物理的に「同じ瞬間」を共有していた。フレームが揃うのは当然であり、むしろズレる方が異常だった。特にアナログの時代では、遅れている映像を保存するバッファ機能自体がないのだ。

ところがIPネットワークは、本来「データを届ける」ために設計された仕組みであり、「届けるタイミングを揃える」ための設計ではない。NDIは非同期（asynchronous）ベースで設計されており、各ストリームが独自のクロックで動作する。SRTは伝送品質を維持するためのバッファを持ち、その遅延は設定と回線状況によって変動する。

この「伝送の非同期性」に気づかないまま現場設計をすると、フレームが揃わない原因が特定できず、経験と勘による「なんとなく調整」に終始することになる。

問題を構造的に整理すると、こう見える

現場でタイムコードがズレる原因は、大きく3つの独立した層に分解できる。

第一層：タイムコードのラベル自体がズレている 複数のカメラや録音機材が、起動時刻の違いや手動設定のミスにより、そもそも異なる「時計」を持っている状態だ。

第二層：タイムコードのラベルは合っているが、映像の到達タイミングがズレている LTC（Linear Timecode：後述する）で時刻を統一しても、SDI・HDMI・NDI・SRTそれぞれが異なる遅延特性を持つため、スイッチャーに届く映像の「物理的な瞬間」がズレる。

第三層：タイムコードのラベルも到達タイミングも合っているが、ドロップフレーム/ノンドロップの混在で後処理が崩壊する 特に29.97fpsと30fps、23.98fpsと24fpsの混在は、タイムライン全体のTCと実時間の乖離を生む。

この3層を個別に対処する知識がある人と、「なんとなく調整している」人の間には、現場での問題解決速度に3倍以上の差が生まれる。

この記事で得られること

この記事の有料部分では、上記3層のトラブルを体系的に解決するための完全な設計図を公開している。

DaVinci Resolve・Premiere Pro・Final Cut Pro・ffmpegそれぞれでのTCオフセット調整の具体的手順、LTCをNDI音声チャンネルとして安全に伝送するための音量・コーデック・フィルター設定、NDIフレームズレを「遅延基準合わせ」で揃えるvMix/OBS実践手法、そしてATEM Mini系（ジェンロック非搭載機）でも実用精度の同期を達成する現場構成──これらを、曖昧な説明なしに数値と手順で記している。

また、記事末尾に「現場タイムコード設計チェックリスト」と「機材別遅延早見表」を付録として収録している。本番前の確認作業がこれ1枚で完結するよう設計した。