ここ数年、ビデオストリーミング業界では、低遅延ビデオストリーミングプロトコルへの関心が非常に高まっている。その関心の大半は、5秒以下の遅延でビデオを配信することであり、ライブ放送TVシステムの遅延に匹敵するものである。このような低遅延を実現することは、ライブスポーツ、ゲーム、オンライン学習、インタラクティブ・ビデオ・アプリケーションなどのストリーミングに不可欠である。
低遅延ストリーミング技術の開発
HLSや DASHのような従来のライブOTTストリーミング・テクノロジーの遅延は、もっと長い。これは、比較的長いセグメント（4-10秒）と、再生前に各メディアセグメントの完全な配信を必要とするセグメントベースの配信モデルによって引き起こされます。HLSやDASHのストリーミング・クライアントが使用するバッファリング戦略と相まって、通常10秒から30秒、あるいはそれ以上の遅延が発生します。
遅延に対抗するため、最近のHLSとDASHの規格の進化は、低遅延HLS（LL-HLS）と低遅延DASH（LL-DASH）として知られ、2つの重要なツールを導入した：
- チャンクビデオエンコーディング。これは、より短いサブセグメントまたはチャンクのシーケンスとして構造化されたビデオセグメントを生成するエンコーディング戦略です。
- チャンクセグメント転送。これは、短いビデオチャンクが生成されるとすぐにストリーミングクライアントに送信できるHTTP転送モードです。
ストリーミングクライアントは、ライブトランスコーダーがセグメント境界またはチャンク境界で利用可能にしたストリームアクセスポイント（SAP）から、低遅延ライブ配信に参加することができる。いったん参加すれば、プレーヤーはエンコーダーが生成した最新のビデオチャンクをデコードしてレンダリングする前にバッファリングするだけでよい。各セグメントが複数のチャンク（通常4～10）に分割されることを考慮すると、これにより遅延が大幅に削減される。
低遅延サーバーとプレーヤーのオープンソースおよびプロプライエタリな実装は、ブライトコーブによるものを含め、現在いくつか市販されている。これらの多くは、シングルビットレートストリームのみを使用し、高速ネットワーク接続でストリーミングする場合に、ストリーミング遅延が少ないことを実証している。しかし、より複雑で現実的な配備環境下での性能は十分に研究されていない。
低遅延ストリーミングのパフォーマンステスト
ACM Mile-High-Video 2023（リンクは近日公開予定）に掲載された論文とFacebook@Scaleでのプレゼンテーションで、低遅延ビデオシステムの性能をテストした結果を報告した。
まず、LL-HLS と LL-DASH システムの評価テストベッドを開発した。次に、このテストベッドを使用して、Dash.js、HLS.js、Shaka player、および Theo player を含むさまざまな低遅延プレーヤーを評価しました。また、低遅延ライブプレーヤー用に最適化された最新のビットレート適応アルゴリズムもいくつか評価した。評価は、一連のライブ・ストリーミング実験に基づいて行われた。これらの実験は、同一のビデオコンテンツ、エンコーディングプロファイル、ネットワーク条件（実際のネットワークのトレースを使用してエミュレート）を使用して繰り返された。
表1は、マルチビットレート、低遅延のDASH/HLSストリームを生成するためのライブビデオエンコーディングプロファイルを示す。
| レンディション | ビデオ解像度（ピクセル） | ビデオコーデックとプロファイル | ビットレート (kbps) |
|---|---|---|---|
| ロー | 768 x 432 | H.264メイン | 949 |
| 半ば | 1024 x 576 | H.264メイン | 1854 |
| 高い | 1600 x 900 | H.264メイン | 3624 |
| トップ | 1920 x 1080 | H.264メイン | 5166 |
表1.ライブビデオのエンコーディング・プロファイル
図1は、私たちの低遅延DASHおよびHLSストリーミング・テストベッドのワークフローを示しています。
図1.低遅延プレーヤーの評価に使用したシステムセットアップ。
図2は、エミュレートしたLTEモバイルネットワークの利用可能なネットワーク帯域幅を示しています。低遅延プレーヤーのダウンロード帯域幅は、ネットワークエミュレーショ ンツールとネットワークトレースによって制御されます。
図2.エミュレートしたLTEモバイルネットワークの利用可能帯域幅（VerizonとT-Mobile）
この実験では、バッファリングとストリームスイッチングの統計情報だけでなく、さまざまなシステムパフォーマンスメトリクス（平均ストリームビットレート、ダウンロードされたメディアデータ量、ストリーミングレイテンシ）が取得され、報告された。
これらの結果は、LL-HLSとLL-DASHのプレーヤーとシステムのパフォーマンスの違いを説明するために使用されました。
私たちの研究からいくつかのプロットを以下の図に見ることができる。
図3.LL-HLSおよびLL-DASHプレーヤーによって報告されたビットレート切り替えのダイナミクス。
図4.LL-HLSとLL-DASHプレーヤーが報告したレイテンシの変動の比較。
パフォーマンス統計 - TモバイルLTEネットワーク
| 選手／アルゴリズム | 平均ビットレート [kbps］ | 平均高さ［ピクセル］ | 平均待ち時間 [秒］ | レイテンシー var.秒 |
速度変動 [%]。 | スイッチ数 | バッファイベント | バッファー比 | MB搭載 | ロードされたオブジェクト |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.jsのデフォルト | 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 |
| シャカ選手（ダッシュ） | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| THEO選手（ダッシュ） | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.jsのデフォルト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デフォルト2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| シャカ選手（HLS） | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
表2.パフォーマンス統計 - T-Mobile LTEネットワーク
低遅延ストリーミングの性能評価
LL-HLSとLL-DASHは、制約のないネットワーク環境ではうまく機能したが、低帯域幅や変化の激しいネットワーク（モバイル環境で典型的）では苦戦した。観測された影響としては、遅延が大きく変動する、バッファリングを防ぐことができない、帯域幅が頻繁に切り替わる、または利用可能なネットワーク帯域幅を使用できない、などがありました。一部のプレーヤーは、このような厳しいネットワーク条件下で、単純に低遅延でないストリーミングに切り替えた。
LL-HLSやLL-DASHは理論的には有望だが、これらの技術にはまだ成熟の余地がある。
ブライトコーブでは、低遅延ストリーミング クライアントのアルゴリズムのクラス最高の実装と、エンコーダおよびサーバー側の最適化に引き続き取り組んでいます。ブライトコーブは、低遅延ストリーミングのサポートを非常にスケーラブルで信頼性の高いものにし、ゴールデンタイムに間に合わせるつもりです。
このブログは2021年にユリイ・レズニクによって書かれたもので、正確さと包括性のために更新されている。
