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

コミュニティ主導の低遅延HLS：LHLS

Community Low-Latency HLS（LHLS）は、HLS.jsコミュニティとMux、JWPlayer、Wowza、Elementalおよび Akamai他との共同開発により、HLSを使用して低遅延ストリーミングを実装するためのコミュニティ主導のアプローチです。低遅延HLSへの最初の試みは、2017年半ばにTwitter傘下のPeriscopeが自社のプラットフォームで使用するために実施されました。LHLSの目標は、2～5秒台の低遅延を実現しながらスケーラブルであり、なおかつ標準的なHLSとの後方互換性を持ち、必要に応じてプレイヤーがフォールバックできるようにすることです。

LHLSは、遅延を低減するために2つのアプローチを採用しています。

1. HTTP/1.1のチャンク転送でセグメントを分割送信する
2. 利用可能になるセグメントのパートを予告する

チャンク転送により、LHLSではセグメント全体のエンコードが終わる前に動画のダウンロードを開始することができます。標準的なHLSでは、動画フレームが利用可能な数秒の長さに満ちるまでバッファリングされるのに対して、チャンク転送では、エンコーダーが出力した直後の動画フレームを次々にサーバーから取得することが可能です。
このプロトコルでは、セグメントに含まれるパートのうちダウンロード可能なものが動画プレイヤーに予告されるため、図4に示すように、生成途中のセグメントであっても動画再生を要求できます。さらに、プレイヤーが要求したセグメントが存在しない、あるいは不完全である場合、そのセグメントが利用可能になり次第、自動的にそれを受け取ることができます。このアプローチはCMAFのそれと非常に似ていますが、LHLSではコンテナにMPEG TSを使用している点が大きく異なります。セグメント全体ではなく利用可能なパートを予告することで、LHLSはバッファのオフセットによって生じる遅延を低減できます。このプロトコルでは、マニフェストとセグメントの両方をロードするのに十分な長さのバッファしか必要としません。動画プレイヤーにはこれから作成されるセグメントのパートとその場所が予告され、優先して読み込むべきファイルを知ることができるので、結果として全体の待ち時間が短縮されます。これらの機能はHTTP/1.1チャンク転送をサポートする標準的なCDNですぐに使えるため、スケーラビリティも確保されます。しかし、CMAFと同様、LHLSの動画プレイヤーで可変ビッ トレートストリーミングをおこなうには、クライアント側で利用可能な帯域幅 を決定できるように、高度な帯域幅推定アルゴリズムを使用する必要があります。LHLSは低遅延動画ストリーミングへの一歩であり、標準的なHLSで達成可能な遅延よりもかなり改善されていますが、エンドツーエンドの遅延が3～5秒と、リアルタイムのライブ動画体験にとって十分なものではなく、適しているとはいえません。

Appleの低遅延HLS：ALHSL

Appleは、HLSプロトコルを拡張し、同程度のスケーラビリティを維持しながら、低遅延動画ストリーミングを可能にしました。この新しい低遅延モードは、パブリックネットワーク上の映像の遅延を、標準的なテレビ放送のレベルまで低減します。初期のテストでは、CMAFおよびLHLSと同程度の遅延が3～10秒の範囲で確認されています［4］。この拡張プロトコルでは、低遅延ライブストリームを実現するために、バックエンドツールやコンテンツ配信システムに新しい機能を実装する必要があります。

Appleの低遅延HLSは、TSのパート（CMAFのチャンクに相当）と呼ばれる、メディアの分割セグメントを生成することで実現します。このチャンクの長さは約250～300msで、完全な動画/音声フレームを複数含みます。処理速度を向上させるために、これらのパートはHLSプレイリストの先頭に記述され、動画プレイヤーは従来より少数のフレーム群をエンコード直後に取得することができます。また、プレイヤーによるパーツの取得速度をさらに向上させるために、この新しいプロトコルではHTTP/2のサーバープッシュを使用します。これにより、プレイヤーがプレイリストをリクエストすると、自動的にHTTP/2 Pushでパートを受信します。

また、クライアント-サーバー通信も追加され、プレイリストへのHTTPリクエストを、特定のセグメントやパートが利用可能になるまで保留することができるようになりました。さらに、プレイリスト全体のうち一部のセグメントのみを含む「デルタ」（差分）プレイリストの作成が可能になっています。これにより、動画プレイヤーはプレイリスト全体を一度ダウンロードし、その後、より小さなデルタプレイリストを使用して最新の数セグメントを取得することができます。また、特定のレンディションに対するプレイリスト応答には、別のレンディションが参照する、利用可能な最新のチャンクとセグメントに関する情報を含めることができる機能も導入されました。これによりプレイヤーは、切り替え開始前に完全なプレイリストを取得せずに、別のレンディションにジャンプできるようになります。後者の機能はサポートされていますが、完全に仕様化されているわけではなく、Appleのデモでさえもまだサポートされていないことに留意してください。

標準的なHLSとALHLSの大きな違いは、プレイリスト生成プロセスとエンコーダープロセスの間で通信する必要がある状態が大幅に増加することです。さらに、新しいプロトコルを実装するためには、HTTP/2が必要になります。HTTP/2自体は主要なCDN企業によってサポートされているものの、ALHLSの鍵となるHTTP/2サーバープッシュ機能はまだ広く実装されているとはいえません。実装されている場合でも、通常はオリジンレスポンスにあるリンクヘッダでpreloadキーワードを使用することで実現されています。このため、CDNはキャッシュ内でHLSプレイリストとそれを参照するメディアを一緒にリンクします。ALHLSでは、プレイリストのレスポンスとともにメディアをプッシュする必要があるため、プレイリスト とメディアのリクエストに同じエッジを使用する必要があります［3］。なぜなら、CDNベンダーのシステムは、プレイリストとメディア配信の責任を分離して構築されており、この 2つの機能にはまったく異なる規模要件が存在するからです。

本稿の執筆時点でベータ版であるALHLSが対応しているのはiOSデバイスのみですが、このクライアント環境は、HLSエコシステム全体からするとごく一部に過ぎません。実際、大多数を占める非Appleデバイスに対し、HLS.js や Video.js のような動画プレイヤーを使ってHLSストリームが配信されています。それらのデバイスへのALHLSの実装は、HTTP/2のような技術ハードルがあるために簡単ではありません。それは、HTTP/2がまだ若い技術であり、ブラウザで利用可能なWeb APIを含め、それを扱うツールがまだ限られているためです。こういった要因と、まだ高い遅延の数値により、インタラクティブなライブ映像体験のための技術としてALHLSが魅力的なものだとはいえません。

WebSocketsとMedia Source Extensions（MSE）

WebSocketsとMedia Source Extensions（MSE）を併用すると、エンドツーエンドで 3 秒程度の低遅延ライブストリームを配信することができます。これは、Wowzaが独自の「WOWZ」技術で採用しているアプローチで、Wowza製の動画プレイヤーを使用した場合、3秒以下の遅延を実現します。また、ライブ動画配信企業NanoCosmosをはじめとする他のグループでも、MSEとWebSocketを使った同様のアプローチに取り組んでいることは注目に値します。

WOWZはTCPベースのメッセージングプロトコルで、サーバーとクライアントの間をWebSocketで接続し、動画/音声データの配信とインタラクティブ 性をサポートする、双方向のデータフローを確立します。クライアント側では、動画/音声のセグメントを構成するパケットは、250ミリ秒のバッファに蓄積されたのち、再生用にブラウザのMSE APIに渡されます。システムの構成図を図5に示します。

このアプローチの主な欠点は、iOSデバイスでMSEがサポートされないことに加え、従来のHTTPインフラストラクチャが未対応なプロトコルに依存していることです。さらに、WOWZは現在可変ビットレートをサポートしていないため、クライアント接続が高速または高信頼性でない場合にUXを低下させる可能性があります。これらの要因から、このアプローチがCMAFやLHLSよりも魅力的であるとはいえません。さらに、エンドツーエンドの遅延が3秒と比較的高いため、インタラクティブなライブ映像体験には適していません。

WebRTC

WebRTC（Web Real-Time Communication）は、Apple、Google、Microsoft、Mozilla、Operaがサポートする標準ベースのオープンソースプロジェクトで、ウェブブラウザとモバイルアプリケーションに、シンプルなAPIを介したリアルタイム通信を提供します。直接ピアツーピアで通信できるため、プラグインのインストールやネイティブアプリのダウンロードが不要で、ウェブページ内で音声や映像の通信をおこなえるようになります。

WebRTCのネットワークプロトコルスタックを図6に示します。TCPベースのHLSやMPEG-DASHと異なり、WebRTCはUDPベースです。実はTCPでWebRTCを配信することも可能ですが、 WebRTCのユースケースの大半がUDPを活用したものであるため本稿ではその説明を省きます。UDPはデータの順序を気にせず、各パケットは到着した次第アプリケーションに渡されます。WebRTCでは、TCPベースのプロトコルのようにパケットをキューに入れ、正しい順番でロードされるのを待つのではなく、失われたパケットに個別に対処します。これは、NACK（否定応答）を使用して最も重要なパケットを再送信するか、パケットロス隠蔽（失われたパケットの内容をある程度推定すること）によりおこなわれます。WebRTCのすべての要件を満たすには、輻輳/フロー制御の実装、何層ものNAT/ファイアウォールをトラバース（横断）する機能、各ストリームのパラメータのネゴシエーション、ユーザーデータの暗号化も必要で、そのためのプロトコルやサービスすべてがブラウザ側でサポートされていなければなりません

WebRTCは、Red5 Proが配信側と受信側の両方で使用している技術で、500ms以下のエンドツーエンドの遅延を実現します。さらに、Red5 Pro はクラスターアーキテクチャーを使用して、数百万人の同時接続ユーザーをサポートするスケーラビリティを実現しています。次のセクションでは、Red5 Proのアプローチの詳細について説明します