タリーランプが噓をつく日

TSL・NDI・ATEM三方式をIPで統合する設計原則

三台のカメラ、二系統のスイッチャー、そして本番中継車が一台。よくある編成の収録だった。サブスイッチャーのタリーランプが、実際にはオンエアになっていない別のカメラを指し続けた。抜かれていると思い込んだカメラマンがフレーミングを崩した瞬間、実際にオンエアだったのはその人だった。放送そのものは止まらなかったが、画は乱れた。原因はカメラでもスイッチャーでもなく、その間をつないでいたIPゲートウェイの設定にあった。

タリーという仕組みには、映像や音声のような世界共通の規格がない。TSL社が策定したUMDプロトコルはUDPで送られ、1パケットの上限は2048バイト、スクリーンとディスプレイのアドレスはそれぞれ0から65534まで、全画面への一斉送信には予約されたインデックス65535を使う（TSL UMD Protocol仕様書／tslumdドキュメント）。NDIはこれとは別の仕組みを持つ。タリー情報はTCPポート5960の管理接続と、そこに続く5961番以降の映像ストリーム接続の上を、双方向のメタデータとして流れる（NDI SDK関連ドキュメント）。ATEMに至っては公式に公開されたプロトコル仕様が存在せず、UDPポート9910を使うことがコミュニティの解析で判明しているだけだ。標準化団体AMWAも、ST 2110にはGPIに相当する仕組みがなく、各社が独自方式を乱立させる危険がある、と明言している（AMWA IS-07仕様書）。

現場の人間が悪いのではない。タリーの世界そのものが、統一言語を持たないまま急にIP化されただけだ。たとえるなら、日本語しか話せない進行、英語しか話せないカメラマン、手話でしか合図を出せないスイッチャーが、通訳なしで同じスタジオに放り込まれたようなものだ。三人とも自分の言葉では正しく喋っている。伝わらないのは、翻訳する仕組みがそこにないからだ。

この断片化は放置していい問題ではないが、絶望するほどの話でもない。プロトコルごとの違いを理解し、変換の要となるポイントを正しく設計すれば、TSL・NDI・ATEMが混在する現場でも、タリーは一つの言語で統一できる。その設計の手順と、単一障害点を作らないための冗長化の考え方を、この先に書いた。

有料部を読み終えると、次の三つが手元に残る。

• TSL／NDI／ATEM、三方式の変換設計フローチャート
• IPタリーゲートウェイを冗長化する具体的な構成手順
• 本番前に確認すべき測定項目と合格基準の一覧

どれも次の現場からそのまま使える形にしてある。

タリーの誤表示は、配信そのものは止めない。だが現場の判断を狂わせる。カメラマンが自分のオンエアに気づかず動きを止める、逆に抜かれているのに動き続ける——どちらも画面に残る。ゲートウェイの設計を知らないまま本番を迎える理由は、もうない。