ライブ動画ストリーミングプロトコルと遅延ゼロへの競争

概要

ライブ動画は、ユーザーのエンゲージメントを大幅に向上させます。この事実が、ライブ動画ストリーミング業界の成長を劇的に高めています。そして、Periscope、TikTok、Facebook Liveなどおなじみの動画ストリーミングSNSアプリや、Twitchをはじめとするeスポーツ、さらにビデオゲームのライブ配信の台頭により、リアルタイム遅延だけが可能にする高度なインタラクティブ性に価値があることが証明されました。この点を考慮したとき、現在の低遅延ストリーミングソリューションは、その遅延が2～3秒の範囲にあるもの（真のインタラクティブなユースケースには適さない）と、1秒以下またはリアルタイムのカテゴリーにあるものに大別できます。もちろん、十分な効果を発揮するには、そのソリューションは数百万単位の同時接続数をカバーできるほどスケーラブルでなければなりません。

この記事では、CMAF、コミュニティ主導の低遅延HLS（LHLS）、Appleの低遅延 HLS（ALHLS）、さらにWowzaが超低遅延ソリューションとして提供しているWebSocketsとMSE（Media Source Extensions）のアプローチなど、HTTPベースのライブストリーミングプロトコルに焦点を当て、それらの最新の開発状況を紹介し、そのいずれもが 2～3 秒という不十分な遅延になることを説明します。後半では、Red5 Proが実装する、WebRTCをベースとした真のリアルタイム遅延ソリューションについて紹介します。

リアルタイム遅延の動画ストリーミングを要する、遅延が1秒以下であることが絶対的に必要な体験は、これまで早押しクイズ、ギャンブル、オークションなど一部のユースケースに限定されていました。しかし、SNSの即時性、モバイル機器やドローンの普及により、スポーツ中継や監視カメラなど他の産業でもリアルタイムなインタラクティビティが求められるようになりました。ライブストリーミングの未来は妥協のないインタラクティブ性であり、現在ユーザーに我慢を強いているようなカッコ書きの「低遅延」ソリューションは、今後5年以内に許容されなくなると私たちは考えています。遅延を秒数で測定しているようなプロトコルは、ゼロ遅延への競争において、せいぜいその場しのぎのソリューションに過ぎないのです。

はじめに

ライブストリーミングプラットフォームとライブインタラクションのユースケースの人気が高まるにつれ、複数のライブストリーミングプロトコルの現状と、それぞれが達成し得る遅延に注目が集まりました。遅延が高いと、ライブストリームとのインタラクションが不可能になったり、ユーザーエクスペリエンスが低下したりするため、遅延の数値は最も意味のあるパラメーターの1つです。図1は、遅延の分類と、それぞれを実現できるプロトコルを示したものです。

ストリームで許容される最大遅延は、ユースケースによって異なります。例えば、リアルタイム通話および会議の場合、一般に、遅延が200ms（0.2秒！）を超えると体感速度が低下し始めると考えられており、この限界を超えると会話が困難になります[2]。スポーツのライブ中継も同様にデリケートで、視聴者が最も避けたいと思うのは、試合がライブストリーム上では続行中なのに試合結果のプッシュ通知を受け取ってしまうことです。また、同じイベントでも配信プロバイダーにより遅延が異なる場合、先に結果を知った隣人がスポーツイベントのクライマックスを台無しにすることもあります。

ギャンブルやオークション業界でも、ライブストリーミングは広く受け入れられています。リアルなディーラーを相手にするオンラインカジノが誕生したことで、ディーラーやプレイヤーの各アクションの間の待機時間を短縮してゲームの流れを維持することの重要性が強調されています。さらに、オークションハウスはオンラインの視覚表現を拡張し、ユーザーはライブストリームを見ながらバーチャルに入札することができるようになりました。論理的には、正しく同期した入札を保証する唯一の方法は、1秒以下の遅延です。

動画ストリーミング業界が低遅延プロトコルに移行しない理由は、コンテンツ配信ネットワーク（CDN）がHTTPに依存する現在のインフラを長年にわたって構築してきたからにほかなりません。技術スタックを根本から見直すのではなく、小さな改善を重ねながら、まあまあの結果が出ることを期待するという、彼らにとっては理にかなったアプローチを選択したのです。Red5 Proのようなスタートアップにはそのようなしがらみがなく、スケーラブルなリアルタイム遅延ストリーミングアーキテクチャの実装に取り組むのは、ずっと容易なことでした。

以下のセクションでは、MPEG-DASH/HLS/CMAF、コミュニティ主導の低遅延HLS（LHLS）、Appleの低遅延HLS（ALHLS）といった各種の低遅延HTTPライブストリーミングプロトコルについて説明し、これらのソリューションと、Red5 Proが採用し500ms以下の遅延を実現しているWebRTCとの比較評価をおこないます。

HTTPベースのライブストリーミング

HLSやMPEG-DASHなどHTTPベースのライブストリーミングプロトコルは、動画ストリームを小さな塊（チャンク）に分割し、HTTPサーバー上に保持します。動画プレイヤーには個々の動画チャンクがTCP経由でダウンロードされるため、動画はファイアウォールを容易に通過し、配信を受けながら再生を続行することができます。このアプローチによりキャッシュサイズは最小限に抑えられ、視聴者は対応する動画チャンクを取得するだけで、任意の再生位置にシークすることが可能になります。さらに、コンテンツ配信ネットワーク（CDN）が、ストリーミングサーバー専用の小規模なネットワークに頼ることなく、HTTPネットワーク全体の容量を活用してストリーミングコンテンツを配信できるため、拡張性に優れています。

Appleは、HLSと呼ばれる独自のHTTPライブストリーミングソリューションを開発しました。Appleは当初、チャンクサイズを10秒に設定し、ストリームを開始する前に3つのセグメントをバッファリングすることを推奨していたため、この設定がHTTPベースのライブストリーミングの標準となりました。このソリューションの主な問題は、上記の設定に起因する30秒から40秒の遅延が発生することです。遅延を下げるための最初のアプローチは、チャンクのサイズを数秒程度に小さくすることです。これは、Short Segment HLSとも呼ばれ、およそ6秒まで遅延を低くすることができます。この方法の欠点は、GOP（Group-of-Pictures）の長さが短くなり、映像品質が低下することです。また、チャンクの長さがラウンドトリップタイム（RTT）の数倍しかないと、CDNを使った配信インフラは不安定になります。そのため、リアルタイムのライブ映像体験に求められる低遅延を実現するには、このプロトコルの設定を変えるだけでは不十分で、新しいプロトコルやフォーマットを作成したり、既存のものを拡張したりする必要がありました。

HTTPライブストリーミングの遅延を4秒以下にするための最新のソリューションとして登場したのが、Common Media Application Format（CMAF）、コミュニティ主導の低遅延HLS（LHLS）、Appleの低遅延HLS（ALHLS）です。

Common Media Application Format： CMAF

CMAFは、2017年にMicrosoftとAppleによって共同開発されました。CMAFは、HLSまたはDASHを使用してデプロイされる動画、オーディオ、またはテキストデータを格納できる標準化されたコンテナです。CMAFの利点は、HLSプレイリストからもDASHマニフェストからも同一のメディアセグメントを参照できることです。これにより、コンテンツ提供者が用意するファイルセットは1つで済むため、キャッシュ ヒット率が従来の2倍になり、CDNがより効率的になります。

CMAFコンテナは、それ自体で遅延を低減することはできません。実際には、エンコーダー、CDN、プレイヤーと組み合わせたシステム全体で低遅延を実現しなければなりません。メディア配信システムの大枠の構成を図2に示します。

このシステムの最初の要件はチャンクエンコーディングです。チャンクは、少なくともmoofとmdatという2つのタイプのatom（MP4のデータブロック）を含む、参照可能な最小単位として定義されます。そして、1 つ以上のチャンクが結合してフラグメントが形成され、それらを組み合わせたものがセグメントとなります。標準的な CMAFメディアセグメントにはmoofとmdatが含まれ、mdatにはセグメントの冒頭に必須のIDR（Instantaneous Decoder Refresh）フレームが格納されます。一方のチャンクエンコーディングの場合、各セグメントは一連のmoof/mdatタプル（連続する同種データ）として出力されますが、IDRフレームを含むのは最初のタプルのみです。このため、標準的なCMAFではセグメント全体の処理が終わるまでエンコーダーが配信用に出力できないのに対し、チャンクエンコーディングではより小さなチャンクがエンコードされ次第すぐに出力することができます。この2種類のエンコーディングを図3に示します。

エンコーダーが新しいセグメントの処理を始めると、インジェスト先のオリジンサーバーにPOSTリクエストをおこない、HTTP 1.1のチャンク転送エンコーディングを使って処理後すぐにエンコード済みのCMAFチャンクを送信します。例えば、エンコーダーが30フレーム/秒の4秒セグメントを生成する場合、4秒ごとにオリジンへのPOSTリクエストを行い、毎回120フレームがチャンク転送エンコーディングで送信されます。

次に、オリジンにインジェストされたチャンクは、HTTPチャンク転送エンコーディングを使ってCDNに配信され、プレイヤーが同じ配信プロトコルでアクセスできるようにエッジサーバー上に蓄積されます。プレイヤーは、ストリームに関連付けられたマニフェストまたはプレイリストを使用して接続先のエッジを決定し、GETリクエストを実行してセグメントを取得します。加えて、プレイヤーの起動アルゴリズムも、セグメントとそのチャンクのフェッチとデコードの方法によって遅延に影響を与えます。

チャンクエンコーディングの利点は、ラストマイル（サーバー-クライアント間）のスループットがセグメントのエンコードビットレートを上回っている限り、スループットに依存しない一貫したタイミングでセグメントがプレイヤーに配信されることです。これは、オリジンからエッジサーバーに送られてくるデータ速度を超えてプレイヤーがチャンクを受信できないため当然のことですが、同時にこの一貫性により、プレイヤーがセグメントのダウンロード時間を測定して可変ビットレート切り替えに必要なラストマイルのスループットを推定することができなくなります。実際、チャンクエンコーディングを使用する場合、標準的なスループット推定アルゴリズムは、スループットがエンコードされたビットレートと同じであると判断し、プレイヤーのスイッチアップを許しません。そのため、プレイヤーは、異なるビットレートのストリームにうまく切り替えるために、より高度なスループット推定アルゴリズムを実装する必要があります。

実験室の理想的な環境下でのテストでは、CMAFは600msという低いエンドツーエンドの遅延を達成できることが示されています。しかし、エンコーダー、オリジン、エッジ、クライアント間の物理的分散により、これら相互のラウンドトリップタイムが増加する現実のケースでCMAFを使用すると、遅延の数値はさほど芳しくありません。オープンインターネット上でデプロイされた最新の概念実証ではエンドツーエンドの遅延が約3秒で、そのうちプレイヤーバッファへの割当が1.5～2秒である場合にのみ、持続可能な体感品質（QoE）を示します［1］（PDF 2.0 参照）。これは、標準的なHLS やDASHの遅延よりも改善されていますが、リアルタイムのライブ動画体験を実現するために十分な低さではありません。