ケーブル不要。スマートフォンで構築する 超低遅延マルチアングル・ライブ配信システム

ライブハウスやイベントの多角度配信には、今日でも HDMI ケーブルの敷設、キャプチャ機材、スイッチャーという物理的な積み上げか、iOS 端末限定の高価な月額サブスクリプションのいずれかが必要になる。いずれの道も「運営側が用意した台数のカメラ」という前提で設計されており、会場にいる数十人・数百人のスマホという最大のカメラ資源を、配信インフラの外に置き続けてきた。

この前提を外すには、(1) 誰の・どの OS の端末でも参加できること、(2) 未知の参加者を安全に受け入れる承認と品質管理、(3) 揺らぐ消費者回線上での音声・映像同期、の 3 つを同時に解く必要がある。本稿執筆時点で、この組み合わせを単一製品として提供する既存サービスは確認できていない。

カメラ参加に必要なのは、会場に提示された QR コードをスマホカメラで読み取ることだけだ。参加はブラウザ上で完結し (WebRTC の WHIP/WHEP プロトコル)、アプリのインストールもアカウント登録も不要。iOS / Android / PC の混在がそのまま許容されるため、現場に集まった端末をそのままカメラ席にできる。

取り込んだ映像は Cloudflare Realtime (SFU) を経由してディレクターのマルチビューに並ぶ。ディレクターはワンタップで番組出力 (PGM) へ切り替え、レイアウト (単独 / ワイプ / 2分割 / 4分割) を変更する。参加から切替までの経路に、専用機材は 1 台も登場しない。

未知の参加者を無条件に受け入れる配信系は、品質もリスクも制御不能になる。OmniLiveCam では参加カメラをまずステージ待機室 (Waiting Room) に置き、ディレクターが映像を確認のうえ承認したものだけをマルチビューと収録に参加させる。不適切なカメラはいつでもキックできる。

さらに日次のセッション予算 (バーストガード) と緊急ブラックアウト (キルスイッチ) を備え、「誰かのスマホ」を開放したことによる課金と事故のリスクを構造側で抑え込んでいる。

同時カメラ上限

8 台品質とコストの両立点

オフライン判定

2.5 秒信号喪失の検出しきい値

緊急黒画面

FTBワンアクションで全出力停止

会場の PA (スピーカー出力) を受け取るディレクター端末の音声をマスターとし、映像側をそれに合わせ込む構成を取る。各カメラの RTT とジッタバッファ遅延から「最も遅いカメラに合わせた推奨ディレイ」を毎秒算出し、パスの悪いカメラに合わせて全体の遅延窓を調整する (音声固定・映像アダプティブ)。推奨値は 200ms のスムーズランプで適用され、視聴中の音飛びを作らない。

回線が推奨ディレイの窓を超えて遅延したカメラは DEGRADED に降格し、マルチビューでの監視は許しつつ PGM への切り替えをブロックする。口パクずれの原因となるカメラを、ディレクターが誤って放送に乗せてしまう事故を構造的に防ぐ。

放送出力とは別に、各カメラの映像を独立した ISO トラックとしてクラウドストレージ (R2) に収録する。「保存して終了」の操作でセッションが確定すると、アーカイブの生成・サムネイル・共有トークンが自動で用意され、視聴者はアングルを選んで再生できる。ディレクターが途中で退出しても収録は継続するため、運用上の単一障害点にならない。

系全体を Cloudflare のエッジ (Workers / Durable Objects / Realtime / R2) 上に構成し、常時稼働する専用サーバーを持たない。配信が発生している時間に対してのみ課金が発生する従量構造のため、収容台数を増やさない限り固定費はほぼゼロで、「低コストで観客カメラを受け入れる」ことをインフラ段階から成立させている。

消費者回線の品質は制御の対象外であり、DEGRADED 降格やオフライン検出は「起きないこと」ではなく「起きたときに壊れないこと」のための機構である。同時 8 台の上限は本稿執筆時点の品質・コストの両立点であり、大規模運用には再評価が必要だ。またブラウザ実装の差異 (コーデック対応、バックグラウンド挙動) は流動的で、継続的な検証を要する。本システムはこれらを隠さず、テレメトリとしてディレクターに可視化する方針を取る。