IP伝送時代に「何フレーム遅れているか」を管理する設計術
放送、Web配信、企業VP、ライブイベント――現場の形は違っても、IP化が進んだ現場に共通して増えたものがある。誰も口に出さないまま蓄積していく「遅れ」だ。カメラを振ってから画面に映るまで、声を出してから相手に届くまで。その間には、昔のSDI一本の時代には存在しなかった段階がいくつも挟まっている。

MCがキューを一拍外した夜
本番中、ディレクターが「3、2、1、キュー」と声を出した。MCは画面の隅にあるタリーランプが点くのを待って話し始めた。だが実際にオンエアが切り替わったのは、タリーが点いてからさらに数コマあとだった。視聴者には、MCが一瞬「間」を置いてから話し出したように見えた。演出ではない。ディレクターの声、タリー信号、スイッチャーの実際の切り替え――この3つが、IP化によってそれぞれ独立した遅延を抱えて画面に届いていただけだ。
遅れは一箇所からは来ない
IPシステムの「遅い」という現象を切り分けると、必ず次の5段階のどこかに原因がある。撮像・カメラ内処理、符号化(圧縮する場合のみ)、伝送・ネットワーク、復号・同期、表示。この5段階以外に信号が通る場所はない。

この5段階のうち、単独では体感できないほど小さい段階がある一方で、方式の選び方によっては1段だけで100ミリ秒を超える段階もある。たとえばNDI公式ドキュメント(docs.ndi.video)によれば、非圧縮に近いFull NDIの1080p60ストリームはグラス・トゥ・グラスで約16ミリ秒、帯域を抑えたNDI|HX3は100ミリ秒未満、Long-GOP HEVCを使うNDI|HX2は100~300ミリ秒とされる。同じ「NDIで送る」という選択の中に、6倍以上の差がすでに存在する。

同期方式にも差がある。日本語版Wikipedia「フレームシンクロナイザー」の解説によれば、非同期の信号を自局の基準に合わせ直すフレームシンクロナイザーは、映像を一度フレームメモリに書き込んでから出力するため1~2フレームの遅延が生じる。SMPTE ST 2059-2に準拠したPTP(放送用の時刻合わせの規格、詳細は本シリーズ別記事で解説済み)で全機器を±1マイクロ秒以内に同期させておけば、この1~2フレーム分はそもそも発生しない。
伝言ゲームだと思えば、腹は立たない
これは伝言ゲームに近い。最初の人から次の人へ伝わる時間は、一人あたりコンマ数秒にすぎない。だが5人、10人と経由するうちに、最後の人に届く頃には最初の発言から数百ミリ秒、時には1秒近くが経っている。しかも誰も「自分が遅らせた」とは思っていない。各段の担当者はそれぞれ自分の持ち場を正しく処理しているだけだ。遅れは、誰か一人のミスではなく、経由した段数の合計として画面に現れる。
方法はある
5段階それぞれの遅延を数値で洗い出し、合計を「フレーム数」として管理する設計手法がある。どの段でどれだけ削れるか、どこは削れないかを事前に把握しておけば、本番前に「このシステムは何フレーム遅れる想定か」を関係者全員で共有できる。感覚ではなく数字で遅延を語れるようになる。
この記事で手に入るもの
有料部を読み終えると、次の3つが手元に残る。
- 5段階それぞれの代表的な遅延値と、その根拠となる公式資料の一覧表
- スマートフォンのスローモーション撮影だけで実測できる、グラス・トゥ・グラス遅延の測定手順
- 方式選定(圧縮方式・同期方式・モニター設定)ごとの遅延削減チェックリスト

このままでは、次の本番でも同じことが起きる
タリーとキュー出しのタイミングがずれる現象を「そういうものだ」と流してきた現場は、次の本番でも同じ数コマを溝として抱えたままになる。その溝がどこから来ているのかを数字で特定する手順を、このあとに書く。


コメント