低遅延動画ストリーミングの進化
ここ数年、動画ストリーミング業界では、低遅延ストリーミングプロトコルへの関心が非常に高まっています。その多くは、5秒以下の遅延で動画を配信することで、生放送のテレビシステムの遅延と同等にすることに関心が集まっています。このような低遅延を実現することは、ライブスポーツ、ゲーム、オンライン学習、インタラクティブな動画アプリケーションなどのストリーミングに不可欠です。
低遅延ストリーミング技術の開発
HLSやDASHといった従来のOTTライブストリーミングテクノロジーの遅延はもっと長くなります。これは、比較的長いセグメント（4～10秒）と、再生前に各メディアセグメントの完全な配信を必要とするセグメントベースの配信モデルによって引き起 こされます。HLSやDASHのストリーミングクライアントが使用するバッファリング戦略と組み合わせると、通常10～30秒、あるいはそれ以上の遅延が発生します。
遅延に対処するため、最近のHLSとDASHの規格は、低遅延HLS（LL-HLS）と低遅延DASH（LL-DASH）として進化しており、2つの重要なツールが導入されています：
- Chunked video encoding : これは、より短いサブセグメントまたはチャンクのシーケンスとして構造化された動画セグメントを生成する符号化戦略です。
- Chunked segment transfer : 短い動画チャンクが生成されるとすぐにストリーミングクライアントに送信できるようにするHTTP転送モードです。
ストリーミングクライアントは、セグメント境界やチャンク境界でライブトランスコーダーが利用可能にした任意のストリームアクセスポイント（SAP）から低遅延のライブストリームに参加することができます。一度参加すると、プレーヤーはエンコーダーが生成した最新の動画チャンクをデコードおよびレンダリングする前にバッファリングするだけです。各セグメントが複数のチャンク（通常4～10個）に分割されることを考慮すると、これにより遅延が大幅に短縮されます。
現在、低遅延サーバーやプレーヤーの実装は、Brightcove社のものを含め、オープンソースや独自に実装されたものが市場に出回っています。これらの多くは、単一ビットレートのストリー ムのみを使用し、高速ネットワーク接続でストリーミングする場合に、ストリーミングの遅延が少ないことを実証しています。しかし、より複雑で現実的な展開環境下での性能は十分に研究されていません。
低遅延ストリーミングの性能検証
ACM Mile-High-Video 2023（リンク先）に掲載された論文や、Facebook@Scaleでのプレゼンテーションで、低遅延システムの性能を検証した結果を報告しました。
まず、LL-HLSとLL-DASHの両システムの評価テストベッドを開発しました。そして、このテストベッドを使用して、Dash.js、HLS.js、Shaka player、Theo playerなど、さまざまな低遅延プレーヤーを評価しました。また、低遅延ライブプレーヤー用に最適化された最新のビットレート適応アルゴリズムもいくつか評価しました。評価は、一連のライブストリーミング実験に基づいて行われました。これらの実験は、同一の動画コンテンツ、エンコーディングプロファイル、ネットワーク条件（実世界のネットワークのトレースを使用してエミュレート）を使用して繰り返されました。
表1は、マルチビットレート、低遅延のDASH/HLSストリームを生成するためのライブ動画エンコーディングプロファイルです。
| Rendition | Video resolution (pixels) | Video codec and profile | Bitrate (kbps) |
|---|---|---|---|
| low | 768 x 432 | H.264 main | 949 |
| mid | 1024 x 576 | H.264 main | 1854 |
| high | 1600 x 900 | H.264 main | 3624 |
| top | 1920 x 1080 | H.264 main | 5166 |
図1に、低遅延DASHおよびHLSストリーミングテストベッドのワークフローを示します。
図2は、エミュレートしたLTEモバイルネットワークの利用可能なネットワーク帯域幅を示したものです。低遅延プレーヤーのダウンロード帯域幅は、当社 のネットワークエミュレーションツールとネットワークトレースによって制御されています。
実験では、さまざまなシステム性能指標（平均ストリームビットレート、ダウンロードされたメディアデータ量、ストリーミングレイテンシー）、およびバッファリングとストリームスイッチングの統計情報を取得し報告しました。
これらの結果は、LL-HLSとLL-DASHのプレーヤーやシステムで観察される性能の違いを説明するために使用されています。
研究から得られたいくつかのプロットは、以下の図に見ることができます。
パフォ ーマンス統計 - T-Mobile LTEネットワーク
| Player/Algorithm | Avg. bitrate [kbps] | Avg. height [pixels] | Avg. latency [secs] | Latency var. [secs] | Speed var. [%] | Number of switches | Buffer events | Buffer ratio [%] | MBs loaded | Objects loaded |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.js default | 2770 | 726 | 3.06 | 0.21 | 10.4 | 93 | 38 | 7.99 | 352.2 | 256 |
| DASH.js LolP | 3496 | 853 | 5.65 | 4.59 | 22.7 | 70 | 53 | 21.96 | 369.4 | 210 |
| DASH.js L2all | 3699 | 908 | 4.14 | 3.18 | 19.9 | 5 | 19 | 7.99 | 368 | 147 |
| Shaka player (dash) | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| THEO player (dash) | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.js default 2020 | 1763 | 562 | 10.08 | 10.91 | 8.1 | 26 | 2 | 9.8 | 130.7 | 589 |
| HLS.js LolP 2020 | 1756 | 560 | 5.97 | 0.2 | 6.1 | 24 | 0 | 0 | 148.1 | 688 |
| HLS.js L2all 2020 | 1752 | 560 | 6 | 0.23 | 5.9 | 34 | 0 | 0 | 133.1 | 686 |
| HLS.js default 2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| Shaka player (HLS) | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
低遅延ストリーミングの性能評価
LL-HLSとLL-DASHは、制約のないネットワーク環境ではうまく機能しましたが、低帯域幅や変化の激しいネットワーク（モバイル展開で典型的）では苦戦しました。その結果、遅延が大きく変化したり、バッファリングを防ぐことができなかったり、帯域幅が頻繁に切り替わったり、利用可能なネットワーク帯域幅を使用できなかったりするなどの影響が観察されました。このような厳しいネットワーク条件下では、低遅延でないストリーミングに切り替えたプレイヤーもあります。
LL-HLSやLL-DASHは理論的には有望ですが、これらの技術にはまだ成熟の余地があります。
ブライトコーブでは、低遅延ストリーミング クライアントのアルゴリズムや、エンコーダおよびサーバサイドの最適化について、クラス最高の実装を継続的に行っています。低遅延ストリーミングのサポートは、スケーラブルで信頼性が高く、プライムタイムに完全に対応できるようにするつもりです。
このブログは、2021年にYuriy Reznikによって書かれたもので、正確さと包括性のために更新されています。