【ITニュース解説】EP05: How Simulcast works and what it's for

ライブストリーミング技術の世界では、視聴者に安定して高品質な映像を届けるために様々な工夫が凝らされている。特に、ネットワークの状態やデバイスの性能が異なる多様な環境において、それぞれの視聴者に最適な映像を提供することは非常に重要な課題だ。この課題を解決するための一つの鍵となるのが「Simulcast（サイマルキャスト）」という技術である。これまで、映像配信ではサーバー側で受信した映像を様々な画質に変換する「トランスコーディング」が行われてきたが、この方法はCPU負荷が高く、映像の遅延も発生しやすいという課題があった。Simulcastは、このトランスコーディングの仕組みを根本的に見直し、より効率的で低遅延な映像配信を実現する。

Simulcastの基本的な考え方は、「配信元（パブリッシャー）が、最初から複数の異なる画質の映像ストリームを同時に生成して送信する」という点にある。これは、単一の映像ストリームをサーバーが受け取ってから、それを複数の画質に加工する伝統的な方法とは大きく異なる。例えば、パブリッシャーが高解像度である1080pの映像を入力として受け取った場合、Simulcastを使えば、同時に1080p、720p、360pといった複数の独立した画質レイヤーを生成し、それぞれを別々の映像ストリームとしてサーバーへ送信できる。これらの各ストリームは、それぞれが完全にデコード可能であり、他のストリームに依存することなく単独で再生できる。

この仕組みの最大のメリットは、サーバー側でのトランスコーディングが不要になることだ。サーバーは、パブリッシャーから送られてきた複数の画質レイヤーの中から、視聴者のネットワーク状況やデバイス性能に最も適したレイヤーを「そのまま」選択し、視聴者に転送するだけでよい。つまり、サーバーは複雑なデコードや再エンコード処理を行う必要がなくなり、純粋にバイトデータを転送する役割に徹することができる。これにより、サーバーの処理負荷が大幅に軽減され、映像配信に伴う遅延も大きく減少する。トランスコーディングという重い処理が、サーバーから配信元のエンコーダーへと移動した形だ。

Simulcastと似たような概念に「SVC（Scalable Video Coding：スケーラブルビデオコーディング）」があるが、両者には明確な違いがある。SVCは、1つのエンコードデータの中に、基本となる低画質レイヤーと、それを補強する高画質レイヤーを組み込む技術だ。これにより、必要に応じて一部のデータだけを送信することで、限られた帯域幅でも映像を届けられるというビットレート効率の良さが特徴である。しかし、SVCのレイヤー間には依存関係が存在するため、サーバーや受信側デバイスがその複雑な構造を理解し、適切に処理する必要がある。そのため、実装の複雑さや互換性の問題が生じやすい。WebRTCではVP9やAV1コーデックでSVCモードが利用されることが多いが、H.264やHEVCといった一般的なコーデックでSVCを利用できるかどうかは、ブラウザやシステムのデコーダー、さらには製品ごとの実装に大きく依存する。

一方でSimulcastの各エンコードは、前述の通り完全に独立してデコード可能である。サーバーは、WebRTCにおいてはRID（RTP Stream ID）やSSRC（Synchronization Source）といった識別子を使って各レイヤーを区別し、選択したレイヤーのデータを転送する。サーバーはRTPシーケンス、タイムスタンプ、RTCPフィードバック、そしてレイヤースイッチの状態を管理する必要はあるものの、SVCのように複雑な依存関係を解析する必要はない。現在のPPCDNプロジェクトでSimulcastが選択されているのは、H.264/HEVCといった主要なコーデックを対象とし、既存のブラウザやデバイスとの高い互換性を優先した結果だ。これはコーデックの標準によって強制されたものではなく、現在の製品環境における最適なトレードオフと判断されている。

Simulcastを実際に利用する際には、いくつかの考慮点がある。まず、生成するレイヤーの数には、製品やシステムの設計によって上限が設けられることがある。例えば、このプロジェクトではH.264で最大4層、HEVCで最大3層といった制限があるが、これは汎用的な標準ではなく、現在のエンコーダーパイプラインやデバイス環境を考慮した上での調整だ。各エンコードにはRTP識別子と独立した状態が必要となる。

次に、視聴者のネットワーク状況やデバイス性能に応じて画質を切り替える「ABR（Adaptive Bitrate：適応型ビットレート）」の仕組みについてだ。サーバーは、受信者からのフィードバックや利用可能な帯域幅の推定に基づいて、より高画質または低画質のレイヤーへと段階的に切り替える判断をする。この際、Simulcastでは各レイヤーが独立しているため、別のレイヤーへの切り替えは、通常、ターゲットとなるレイヤーの「ランダムアクセスポイント」、つまりH.264やHEVCでいうところの「IDRフレーム（キーフレーム）」を待って行われる。キーフレームは映像の参照チェーンを切断し、そのフレーム単独でデコード可能な特別なフレームである。サーバーは、PLI（Picture Loss Indication）やFIR（Full Intra Request）といった信号を通じてキーフレームの生成を要求し、そのキーフレームが届いてから新しいレイヤーのデータを転送し始める。これにより、映像の途中で急に画質が切り替わった際に発生しがちな映像の乱れやアーティファクト（ノイズやブロック状の歪み）を防ぐことができる。ただし、キーフレームの生成には若干のビットレートコストと待ち時間が発生するため、切り替えが常に完璧にシームレスで視聴者に全く感知されないとは限らない。

また、Simulcastは「マルチトラック」とは別の概念である点も理解しておくべきだ。マルチトラックは、異なるデコード能力を持つブラウザやデバイスに対して、それぞれH.264とHEVCのような異なるコーデックの映像ストリームを提供するものだ。例えば、H.264をサポートするデバイスにはH.264ストリームを、HEVCをサポートするデバイスにはHEVCストリームを提供するという使い分けができる。一方、Simulcastは「異なるネットワーク状況や品質要件に対応するために、同じコーデックで複数の画質レイヤーを提供する」という目的を持つ。これらは互いに排他的ではなく、同時に利用することも可能だ。例えば、H.264ストリームが4つのSimulcastレイヤーを持ち、HEVCストリームが独立して3つのSimulcastレイヤーを持つといった運用ができる。

Simulcastのメカニズムをまとめると、サーバー側でのトランスコーディングによる重い処理と遅延を回避するために、配信元が複数の独立した画質レイヤーを同時に生成するという画期的な手法である。サーバーは単にバイトデータを転送する役割を担うが、RTP/RTCPの処理やレイヤー切り替えの状態管理は引き続き行う。SVCと比較した場合の複雑さや互換性のトレードオフを考慮し、現在の主流なデバイスやブラウザとの親和性が高いSimulcastが多くのライブストリーミング環境で採用されている。品質レイヤーの切り替えは、映像の品質を損なわないよう、キーフレームのタイミングを見計らって慎重に行われることが重要だ。

このSimulcastの理解は、低遅延ライブストリーミングシステムの設計において不可欠な要素である。次に、この配信された映像コンテンツを不正利用から守るためのセキュリティ対策、具体的には配信の署名、トークン認証、そして不正な埋め込み（ホットリンク）防止の仕組みについて詳しく見ていくことになるだろう。