DEEP DIVE: P2P LIVE STREAMING

P2Pライブ配信：1対多のリアルタイム配信を支える中継技術

ライブ配信では、1人の配信者の映像を多数の視聴者が「同じ最新の数秒」として観ています。素朴に全員へ直接送れば、真っ先に破綻するのは配信者のアップリンク回線です。配信ツリーとカスケード、制御プレーンとしてのリーダー選出、PLIとキーフレーム制御、WebRTCの外へ届けるプロトコルブリッジ。これらの制約を乗り越える中継技術を、実装から得られた実践知見とともに詳説します。

ライブ配信は何が難しいのか

ライブ配信は、あらかじめ完成しているファイルを配るのではなく、「1人が送り出す映像・音声を、多数の視聴者がほぼ同時に、同じ最新の数秒として観る」というリアルタイムな1対多通信です。この性質が、VOD（Video on Demand、視聴者が好きなタイミングで完成済みファイルを再生する方式）とは根本的に異なる難しさを生みます。

BitTorrentのようなスウォーム型のP2P配布は、VODでは絶大な効果を発揮します。各ピアが異なるピースを持ち寄り、レアレストファーストで交換することで、需要が集中するほど配信力も増す自己スケーリング性が働くためです。しかしライブ配信では、視聴者全員が「今まさに生成されたばかりの、同じ最新のピース」を欲しがります。過去のピースを持ち寄って交換し合うという多様性が生まれにくく、素朴なスウォームの仕組みはそのままでは効きにくいのです。

かといって、配信者がWebRTCで全視聴者へ直接データを送る素朴な構成にも別の壁があります。配信者は視聴者の人数ぶんだけ同じ映像・音声のコピーを送信する必要があり、配信者のアップリンク帯域が視聴者数に比例して詰まります。これはWebRTCのフルメッシュ構成が抱えるO(n²)問題の1対多版であり、配信者の回線が数十人規模で早々に頭打ちになります。

配信ツリーとカスケード：アップリンクを1本に保つ

この問題への基本的な解決策が、中継ノードによる木構造（ツリー/カスケード）での再配布です。中継ノード群のうち1台だけ（以下ルートと呼びます）が配信者から直接メディアを受信し、受け取ったストリームを再エンコードせずそのまま他の中継ノードへ再配布します。配信者から見ればアップリンク先は常にルート1台だけであり、視聴者数がどれだけ増えても配信者側の負荷は変わりません。

大規模なビデオ会議サービスも、WebRTCのSFU（Selective Forwarding Unit）を複数台つないだ「SFUカスケード」という同じ発想の構成を使って、単一サーバーでは支えきれない規模の会議を成立させています。

P2Pオーバーレイが全参加者同士のフルメッシュではなく、一部のノード間だけがつながる選択的メッシュであっても、ルート経由の再配布であれば配信者と直接接続していないノードにもメディアが届くという副次的な利点もあります。

観点	直接ファンアウト（1対n）	フルメッシュ	カスケード/ツリー
配信者のアップリンク	視聴者数nに比例して増加	視聴者数nに比例して増加	常に1本（ルートへの送信のみ）
視聴者側の負荷	受信のみで軽い	他の全参加者ぶんの送受信が必要で重い	中継ノードのみやや重く、末端は受信のみ
ルート障害の影響	該当なし（単一障害点は配信者自身）	該当なし	ルート配下の視聴者が一斉に切断される
適する規模	数人規模まで	数人規模まで	数百〜数千人規模までスケール可能

「誰がルートか」だけを合意する：制御プレーンとしての合意アルゴリズム

ルートを誰にするかをどう決めるかも設計課題です。実用的な解の1つが、中継ノード群によるRaft（分散合意を参照）でのリーダー選出です。ただし、Raft本来のログ複製の仕組みまでは使わず、リーダー選出だけを取り出して使うという割り切りが実務では有効です。「選ばれたリーダーが誰か」という1点だけが、このシステムにとって唯一合意すべき事柄だからです。

ここには押さえておくべき大原則があります。合意アルゴリズムはコミットのたびにノード間の往復を要するため、低遅延を求められるメディアデータそのものには決して載せてはいけません。合意アルゴリズムはあくまで制御プレーンです。「どのノードが再配布を担うか」を決めるためだけに使い、データプレーン（実際の映像・音声）は合意の外側を流れる別経路として設計するのが鉄則です。

実務上の落とし穴もあります。Raft実装が持つ既定のタイムアウト値（選挙タイムアウトが150〜300ミリ秒、ハートビート間隔が50ミリ秒程度）は、データセンター内のLANのような低ジッタ環境を前提にしています。ジッタの大きいP2P＋WebRTC経路にこの既定値をそのまま適用すると、単に「ハートビートの到着が少し遅れただけ」を「リーダーの死亡」と誤認し、偽の再選挙が頻発します。選挙タイムアウトは秒オーダーまで保守的に伸ばす必要があります。「合意アルゴリズムのタイムアウトは、実際のネットワーク特性に合わせて調整せよ」という教訓は、この種の応用に限らず広く当てはまります。

リーダーが失われれば、残りの中継ノードが自動的に新しいリーダーを選出し、各中継はその新リーダーからの再配布へロックし直します。人手の介入なしにフェイルオーバーが完結する点が、この構成の強みです。

キーフレームとフィードバック：PLIとNACK

多くの映像コーデックは、大半のフレームを直前フレームとの差分として送ります。フレーム単独で復号できるキーフレーム（IDR）はデータ量が大きいため、エンコーダーは基本的に「要求された時だけ」キーフレームを送出します。この要求に使われるのがRTCPフィードバックのPLI（Picture Loss Indication）です。

ここでNACK（個別パケットの再送要求）が無い場合の劣化モデルを理解しておく必要があります。パケットロスが起こるとRTPシーケンス番号にギャップが生じ、そのフレームは復元不能になります。壊れたフレームを下流に流すわけにはいかないため、次のキーフレームが来るまでフレームを捨てるしかありません。結果として、映像はキーフレームが届くまで静止します。「パケット単位の小さな損失が、再送の仕組みが無ければフレーム単位・秒単位の大きな損失に化ける」というのが本質です。

実務でよく使われるパターンは3つの組み合わせです。定期PLI（数秒周期で送り、途中から参加した視聴者も1周期以内にキーフレームを得られるようにする）、ロス検知時の即時PLI（次の定期周期まで待つと数秒単位で映像が固まってしまうため、ロスを検知した瞬間に追加で送る）、そしてデバウンス（1回のロススパイクで連続的なギャップが多数検知されても、PLIの連射（PLIストーム）にしないよう間引く）です。

木構造による配信では特有の落とし穴があります。末端ノードが送るPLIは自分の直接の上流(ルートからの再配布トラック)に向きますが、それが元の配信者まで転送される戻り経路を設計しておかないと、配信者に対してキーフレームを要求できるのは実質ルートだけになってしまいます。この場合、末端ノードのキーフレーム待ちはルートのPLI送出周期に律速されます。データの下り経路と同じくらい、フィードバックの上り経路の設計が重要な課題になるのです。

プロトコルブリッジ：WebRTCの外の世界へ届ける

視聴側が常にWebRTCを話せるとは限りません。組み込み機器や、ゲーム・メタバースプラットフォーム内の動画プレイヤーのように、「URLを指定して再生することしかできない」プレイヤーにメディアを届けるには、中継ノードがWebRTCから他のプロトコル（RTSP/HLSなど）へ翻訳するプロトコルブリッジが必要です。

原則として、ブリッジの本質はデパケット化してから再パケット化することであり、再エンコードではありません。例えばH.264の映像であれば、RTPペイロードからフレーム（アクセスユニット）を組み立て直し、別プロトコルのパケット形式に載せ替えるだけで済みます。トランスコード（コーデック自体の変換）が必要になるのは、再生側が対応していないコーデックを使っている場合だけです（例: WebRTCで標準的に使われるOpus音声を、プレイヤー側が確実に再生できるAACへ変換するケース）。変換は最小限にとどめることが、遅延と画質の両面で正解になります。

面白い運用形態として、各視聴者が自分のマシン上でブリッジを動かし、`rtsp://127.0.0.1/...`のようなループバックURLを自分のプレイヤーで再生するという構成があります。全視聴者がP2Pスウォーム側でメディアを受信するため、配信サーバーそのものが不要になり、公開IPアドレスもポート開放も要りません。

地味ながら重要な知見もあります。プレイヤーの多くは、データが来ない状態を「切断」と誤認して自らセッションを切ってしまいます。実際のメディアデータが途切れている間も、デコーダーにとって妥当なダミーデータ（パラメータセットなど）を流し続け、接続を維持し続ける工夫が必要です。

リップシンク：別々の時計を合わせる

映像と音声は別々のストリームとして、別々のタイムスタンプ空間（映像は90kHz、音声は48kHzといったRTPクロック）で流れています。受信側がこの2つを正しく突き合わせる基準になるのがRTCP Sender Report（SR）です。SRは「このストリームのRTP時刻は、この実時刻（NTP時刻）に対応する」という対応表を定期的に運びます。SRの送信を忘れると、再生側は同期の基準を失い、映像と音声が徐々にずれていきます。多くのライブラリが暗黙にこの処理を行ってくれるため、自前で実装する際に最も見落としやすい部分です。

もう1つの実務上の注意点として、ソース由来のRTPタイムスタンプは、配信元の切り替えやメディアの欠損によって不連続に飛ぶことがあります。中継ノードは受信したタイムスタンプの差分を検査し、異常なジャンプを検出した場合には公称値(音声であれば20ミリ秒相当など)に置き換えることで、出力するタイムスタンプを常に単調増加へ保つ再ベースを行うのが定石です。

遅延はどこで生まれるか

中継ノード自体が付加する遅延は小さく、フレーム組み立てで概ね1フレーム分、音声の再フレーミングで20ミリ秒程度です。遅延の支配的な要因はむしろ両端にあります。配信側のエンコーダーが持つ先読みバッファと、視聴側のプレイヤーが持つジッタバッファ・デコードバッファです。

配信の遅延を詰めようとする議論では、まず「自分たちが設計・最適化できる区間」と「エンコーダーやプレイヤー実装に依存していて手を出しにくい区間」を切り分けることが先決です。

文脈として、従来からのRTMPベースの配信は数秒から十数秒の遅延を持つことが一般的である一方、WebRTCベースの配信はサブ秒の遅延を実現できます。この取り込み（ingest）の標準化を担っているのがWHIP/WHEPで、詳しくはWebRTCのシグナリングの節を参照してください。