解像度・フレームレート・走査方式で決まる映像伝送設計
対象読者:撮影・演出・編集・配信・制作進行に関わり、IP伝送技術に関心を持つすべてのプロフェッショナルへ。
誰も疑わなかった数字
3時間の企業カンファレンス配信。カメラは3台、スイッチャーはATEM、プレゼン資料はノートPCからHDMI経由でキャプチャーカードに入れていた。本番は問題なく終わった、はずだった。

数日後、アーカイブ映像を見返した制作進行の担当者が違和感に気づく。開始直後は完璧に合っていたはずの字幕とプレゼン画面の切り替えタイミングが、終盤になるほど微妙にズレている。編集ソフトの波形を並べても原因がわからず、音声トラブルを疑い、キャプチャーカードのドライバーを疑い、最後にたどり着いたのがフレームレートだった。
カメラ側は業界標準の59.94Hzで動いていた。ノートPCの映像出力は初期設定のまま、真の60.00Hzだった。この0.06Hzという小さな差が、3時間という時間の中でじわじわと積み重なっていた。
なぜこの差が誰にも気づかれないのか
問題は、この種のズレが「壊れ方」をしないという点にある。信号が途切れるわけでも、画面が固まるわけでもない。ただ、時間の物差しが2種類、同じ現場に混在しているだけだ。
60Hzと59.94Hzの差は、60 − 59.94 = 0.06フレーム毎秒(正確には60 × 1/1001 ≈ 0.05994Hz。NTSC方式が採用する1000/1001比に基づく、出典:The Broadcast Bridge「Timing: Part 5 – NTSC Frame Rates」)。この数字だけを見ると誤差の範囲に思える。
だが積算すると話が変わる。3,600秒(1時間)× 0.06フレーム ≈ 216フレームの差が生じ、216フレーム ÷ 60fps = 3.6秒。これが「1時間あたり3.6秒」という時間差の正体だ。3時間の配信であれば、単純計算で10秒以上のズレが蓄積する計算になる。しかも波形やレベルメーターには一切現れない。テロップの表示タイミング、複数ソースの切り替えタイミング、字幕の同期といった「見た目の違和感」として、しかも本人が気づくまで放置される形で現れる。

あなたが悪いわけではない、地図が古いだけだ
ここで自分を責める必要はない。フレームレート・走査方式・解像度という3つの数字は、鉄道の時刻表に似ている。同じ駅を、ほぼ同じ間隔で出発する2本の電車があるとする。最初の発車時刻はぴったり揃っていても、片方が59.94分間隔、もう片方が60.00分間隔で走っていたら、1日の終わりには到着ホームが一致しなくなる。乗客(=映像信号)は「なぜか少しずつズレていく」としか感じない。

現場で使う機材は、業界の標準(59.94Hz)を前提に作られたものと、コンピューターの世界の標準(60.00Hz)を前提に作られたものが混在している。どちらが正しいという話ではなく、「時刻表が2種類ある」ことを知らずに運行しているのが問題なのだ。
この記事で扱う3つの設計軸
映像をIPネットワークで伝送するとき、フォーマットを決める要素は次の3つに分解できる。走査方式(プログレッシブかインターレースか、あるいはPsFという第三の方式か)、フレームレート(59.94Hzか60.00Hzか)、解像度(HDかUHDか、それに応じた必要帯域)。この3つの掛け合わせで、映像が正しく届くか、崩れるかが決まる。
方法は存在する。ただし、この無料エリアではその「存在」だけを伝える。実際の診断手順・数値の閾値・帯域計算式・トラブル早見表は、このあとの有料エリアに置いている。
有料エリアで手に入るもの
- 走査方式・フレームレート・解像度、それぞれの「正常値と異常値」を示した判定表
- 現場で今すぐ使えるフレームレート不一致の診断手順(所要時間つき)
- 「くし歯状のノイズ」の正体と、その場で見分ける方法
- HDとUHD、それぞれの必要帯域を自分の現場で計算する式
- 症状から原因を逆引きできるトラブルシューティング早見表

ここから先は有料エリアだ。 診断手順・数値基準・帯域計算式・トラブル早見表のすべてがここに揃っている。この設定を知らないまま多台数・長時間の本番に臨むと、ズレは録画後にしか発見できず、編集段階での手戻り作業が発生する。次の現場で同じ事故を防ぐ手順が、このあとにある。


コメント