可変遅延時代のバックタイミング設計
対象読者：撮影・演出・音響・照明・編集・配信・制作進行に関わり、IP伝送技術に関心を持つすべてのプロフェッショナルへ。
「おめでとうございます」が、二人の口から同時に出た
授賞式の配信だった。本社スタジオの司会が「それでは、リモート会場の受賞者にお祝いの言葉を」と切り出し、すぐにリモート会場のプレゼンターへマイクを渡した。台本上は、そこで一拍置いて拍手が入り、プレゼンターが「おめでとうございます」と続く手はずだった。
実際に起きたのは、司会の声が届いた1.6秒後、司会自身がもう次のコメントを話し始めた瞬間に、プレゼンターの「おめでとうございます」が視聴者の耳に届くという事故だった。二人の声が重なった。台本は正しかった。声を出すタイミングも、双方とも間違えていなかった。狂っていたのは、声が相手に届くまでの時間だった。
進行表のタイムコードは、リハーサルで確認した通りに進んでいた。バックタイミング——番組の終了時刻から逆算して各コーナーの開始時刻を割り出す、放送の古くからの技術——も、事前に組んだ通りだった(出典：Rundown Creator社「Timing 101」解説記事、List Producer社ブログ「Backtiming: Producer Tip for a More Productive Day」)。それでも進行が詰まった。バックタイミングという技術そのものは壊れていない。壊れていたのは、その技術が前提にしていた「全員が同じ時間を生きている」という土台の方だった。
遅延は消えていない。姿を変えて、バラバラになっただけだ
人間の会話は、驚くほど精密な間合いの上に成立している。10の言語を対象にした研究では、話者が交代する際の間合いは、言語をまたいでもおよそ0〜200ミリ秒に収まることが確認されている(出典：Stivers et al., 2009, “Universals and cultural variation in turn-taking in conversation,” PNAS 106巻26号)。この0〜200ミリ秒という幅の中で、人は無意識に相手の発話の終わりを予測し、次の発話を差し込んでいる。
一方、スタジオとリモート会場を衛星やインターネット回線でつなぐ中継では、往復でおよそ1〜2秒の遅延が生じるのが一般的で、携帯回線経由になると3〜4秒に達することもある(出典：リモート出演時の遅延対策を扱った技術背景説明、米国特許文書「System and Method for Removing a Pause in a Delayed Remote Broadcast Interview」)。冒頭の事故で発生した1.6秒の遅延を、人間の会話が許容する上限の200ミリ秒で割ると、8倍(1,600ミリ秒 ÷ 200ミリ秒 = 8)になる。人間の間合いの感覚が対応できる幅の、8倍のズレが乗っていたことになる。台本にもリハーサルにも問題はなかった。人間の反射神経が対応できる範囲を、単純に超えていただけだ。
あなたは悪くない。全員が同じ時計を見ていた時代が終わっただけだ
SDIで機材をつないでいた時代のバックタイミングは、壁に一つだけ時計が掛かっている部屋のようなものだった。スタジオの誰もが同じ時計を見て、同じ「今」を共有していた。ケーブルによる遅延はフレーム単位で、全員にほぼ均等にかかっていたからだ。
IPで各拠点をつなぐ時代のバックタイミングは、全員がそれぞれ自分の腕時計をつけている部屋に変わった。しかも、その腕時計は一つひとつ進み方が違う。ローカルのNDIソースはほぼ壁時計と同じ速さで進み、インターネット経由のSRTソースは少し遅れ、衛星やセルラー回線のリモート出演はさらに大きく遅れる。全員が「自分の時計は合っている」と信じたまま本番に入れば、誰も間違えていないのに、声だけがずれて重なる。
方法はすでにある
ソースごとに異なる遅延を測定し、それぞれに個別のバックタイムを割り当てるという考え方は、放送の現場ではすでに確立された設計思想として存在する。PTP(Precision Time Protocol、IEEE 1588)は映像信号のタイムスタンプを1マイクロ秒単位で同期させる技術だが(出典：SMPTE公式ブログ「Precision Time Protocol for Synchronization in Broadcast-over-IP」、SMPTE ST 2059規格)、これは信号そのものの時刻合わせであって、伝送経路にかかる遅延そのものを消す技術ではない。この二つを混同したまま「PTPで同期しているから大丈夫」と考えている現場ほど、冒頭のような事故を起こしやすい。
この記事で手に入るもの
有料部では、次の3点を具体的な数値とともに手に入れられる。
- 伝送経路別の遅延を実測し、ソースごとにバックタイムを割り当てる6ステップの設計手順
- 複数拠点をまたぐ掛け合い台本を、遅延を前提に組み直す具体的な書き換え方
- 症状別トラブルシューティング早見表と、本番前チェックリスト
ここから先は、45年の現場で積み上げた判断軸だ
進行が詰まる原因を「オペレーターの不慣れ」や「台本の甘さ」で片づけている現場を、これまで何度も見てきた。本当の原因は、拠点ごとに違う時計の進み方を、誰も設計していなかったことにある。次の本番で同じ8倍のズレを踏まないための手順を、このあとにまとめた。
コメント