【4回シリーズ／1回目】メディアサービス － ライブ動画ストリーミングの遅延（レイテンシー）

スポーツ中継、ゲーム、ニュース配信、TV番組など、動画配信のニーズは高まっているものの、配信遅延や最適なサービスの選択に困っている方もいらっしゃるのではないでしょうか？メディアサービスを検討する際によくある課題とソリューションについて、以下のように4つのパートに分けて解説します。ひとつ目のテーマは「レイテンシー（配信遅延）の定義と測定」です。

パート 1：レイテンシーの定義と測定（この記事）
パート 2：エンコード、パッケージ化、および CDN 配信のおすすめ最適化
パート 3：動画プレイヤーのおすすめ最適化
パート 4：参照アーキテクチャとテスト結果

パート 1：レイテンシーの定義と測定

ライブ動画ストリーミングでレイテンシーが問題になるのはなぜでしょうか？ スポーツ、ゲーム、ニュースなどの TV コンテンツ、あるいは eSports やギャンブルなどの純粋な OTT コンテンツかどうかにかかわらず、コンテンツ配信が時間に敏感なときは、遅れるわけにはいきません。待つ時間が長引くと興味がなくなります。待ち時間によって、エンターテインメントとリアルタイムの情報の世界で二流に変わってしまいます。分かりやすい例として、サッカー試合の観戦があります。隣人が従来のようにテレビでサッカー試合を見て、好きなチーム（多くの場合、あなたと一緒）がゴールを決めると壁越しに叫ぶとします。OTT サービスの場合は、同じものを見るまで 25 秒または 30 秒待たなければなりません。これは非常にイライラするもので、ストリーミングチャネルと一緒にモニタリングしている Twitter または Facebook のフィードによってお気に入りの歌唱コンテストの結果をネタバレされた場合と似ています。これらのソーシャルフィードは通常、自身のテレビで番組を視聴しているユーザーによって生成されるため、通常のレイテンシーは 15〜20 秒に短縮されますが、それでもテレビの生放送よりかなり遅れています。

ブロードキャストレイテンシーとソーシャルネットワークの競合に加えて、コンテンツプロバイダーがライブストリーミングのレイテンシーを最小限にしたい理由は他にもあります。RTMP ストリーミングを使用した古い Flash ベースのアプリケーションは、レイテンシーの点ではうまく機能しました。しかし、ウェブブラウザでは、Flash の使用は減少しています。配信側では CDN が RTMP を使わなくなったため、コンテンツプロバイダーは HLS や DASH などの HTML5 対応ストリーミングテクノロジー、または最近では CMAF に切り替える必要があります。他のコンテンツプロバイダーは、インタラクティブ機能を備えたパーソナル放送サービスを開発したいと考えており、このユースケースでは動画信号で 30 秒の遅延はありえません。さらに、同期化されたセカンドスクリーン、ソーシャルウォッチング、またはギャンブルアプリケーションを開発したい人は、ストリーミングレイテンシーを細かいレベルで制御する必要があります。

レイテンシーに関しては、通常 3 つのカテゴリが定義され、上限と下限があります。これらは、転送手段（ケーブル/IPTV/DTT /衛星）および各配信ネットワークトポロジの詳細に応じて 3～12 秒に及ぶため、正確にはブロードキャストレイテンシーと一致しません。ブロードキャストレイテンシーの平均値が 6 秒の場合は、このフィールドでよく見られます。つまり、OTT のスイートスポットは「低レイテンシー」カテゴリの低範囲または「低レイテンシー」カテゴリの高範囲のどこかにあります。5 秒に近づくと、ブロードキャストとソーシャルネットワークフィードの競合に対して、効率的に競う可能性が最大になります。さらに、コンテンツの準備ワークフロー内の OTT エンコーダーの位置によっては、エンコーダーがチェーンのダウンストリームに位置する場合、レイテンシー短縮という目的が高まります。

HTTP ベースのストリーミングでは、レイテンシーは主にメディアセグメントの長さによって異なります。メディアセグメントの長さが 6 秒の場合、最初のセグメントを要求したときの実際の絶対時間と比べて、プレイヤーはすでに少なくとも 6 秒遅れています。そして多くのプレイヤーは、実際に再生を開始する前に追加のメディアセグメントをバッファーにダウンロードします。これにより、最初にデコードされたビデオフレームまでの時間が自動的に長くなります。もちろん、動画のエンコードパイプラインの継続時間、取り込みおよびパッケージ化操作の継続時間、ネットワーク伝達遅延、および CDN バッファーなど、レイテンシーを発生させる要因は他にもあります。しかし、ほとんどの場合はレイテンシー全体において、プレイヤーは最大の割合を占めます。実際にほとんどのプレイヤーは、一般的に消極的なヒューリスティックを使用して、3 つ以上のセグメントをバッファーします。

Microsoft Smooth Streaming では、通常のセグメントの長さは 2 秒で、Silverlight プレイヤーでは一般的に 10 秒程度のレイテンシーがかかります。DASH では、ほとんど同じです。ほとんどのプレイヤーは 2 秒のセグメントをサポートして、レイテンシーに関して可変的な結果をもたらします。しかし、状況は HLS とはかなり異なります。2016 年半ばまで、Apple の推奨は 10 秒セグメントを使用することでした。これは、Apple 自身のプレイヤーを含むほとんどの HLS プレイヤーで約 30 秒のレイテンシーをもたらしました。2016 年 8 月、Apple のテクニカルノート TN2224 では、次のように述べています。「当社は 10 秒の目標時間を推奨していました。すべてのコンテンツを突然再セグメント化することを期待しているわけではありません。しかし、今後 6 秒間でより良いトレードオフが可能になると確信しています。」 1 セグメントあたり 4 秒未満で、画面から突然消えるレイテンシーは 12 秒です。ほとんどの場合、コンテンツ制作者は iOS プレイヤーが AppStore で iOS アプリケーションを検証するときに危険を回避したいため、より短いセグメント長で作業できるとしても、Apple の推奨に従いました。しかし、最近は 3 つの進化により、iOS 11 の Safari Mobile でゲームが変更されました。ライブ HLS ストリームの自動起動機能が有効になり、小セグメント期間のサポートが大幅に向上され、FairPlay DRM がサポートされました。つまり、iOS でコンパイルされたアプリケーションを絶対に使用する必要がないコンテンツ制作者は、短いメディアセグメントでライブレイテンシーを短縮すると同時に、スタジオで承認された DRM で保護されたストリームを配信できます。

短いメディアセグメントでは CDN とプレイヤーに大きな負荷がかかることに異議を唱える人がいるかもしれませんが、Microsoft Smooth Streaming が 2 秒のセグメントを利用しているため、長年にわたって実際に続けてきました。ブロードキャストとのレイテンシーのギャップを減らす次の手順は、1 秒のセグメントへ移動することです。これによって実際に大きなボトルネックが生成されることはありません。 もちろん、ヘッダー数と TCP 接続に関してすべての HTTP オーバーヘッドを考えてリクエスト数を 2 倍に増やしますが、CDN（特にエッジが HTTP 2.0 をサポートし、Amazon CloudFront のような HTTP 1.1 をサポートしている場合）によってかなり管理しやすくなります。そして、ファイバー、4G、LTE、DOCSIS 3.1 FD、およびその他の最近の接続性の進歩による、より広い帯域幅のラストマイル接続から利益を得るモダンなプレイヤーがあります。実験によると、1 秒と 2 秒という短いセグメントが現在多くのプレイヤーによってサポートされているため、レイテンシーを短縮する新しいオプションが多く提供されています。最後に、HLS と DASH の両方において、短いセグメントは通常、チェーン全体のエンコーダー、パッケージャー、およびオリジンサービスで問題になることはありません。

AppStore の要件を除いて 6 秒のセグメント期間を依然として適用するコンテンツ制作者は、すべてのプラットフォームのさまざまなプレイヤーで 1 秒または 2 秒のメディアセグメントと同等のブロードキャストレイテンシーまたはそれ以上の速さを試すことができます。

高レベルで、ストリーミングソリューションを「低レイテンシー」カテゴリに分類するために実行する主な操作は次のとおりです。

• 動画のエンコードパイプラインを最適化する
• 要件に合った適切なセグメント期間を選択する
• 適切なアーキテクチャを構築する
• 動画プレイヤーを最適化（または置き換え）する

AWS Elemental のビデオソリューションと、現在利用可能なオープンソースまたは商用プレイヤーを組み合わせて、実現する方法を見てみましょう。

レイテンシーの測定方法
レイテンシー最適化プロセスの最初の手順は、チェーン内でどのコンポーネントがレイテンシー全体のうちどのくらい割合を占めているかを知ることです。これによって、ワークフローのエンコード、パッケージ化、または再生段階にかかわらず、最適化の優先順位に向けて導いてくれます。まず、エンドツーエンドのレイテンシーを測定することから始めましょう。

エンドツーエンドのレイテンシーを測定する最も簡単な方法は、カチンコアプリケーションを実行しているタブレットを使用し、それをエンコーダーに接続されたカメラで撮影し、ストリームをオリジンに公開し、CDN を通じてプレイヤに配信することです。カチンコタブレットの横にプレイヤーを置いて、2 つの画面の写真を撮り、各画面のタイムコードを引くと、番号がわかります。これがワークフローのレイテンシーの正確な表現であることを確認するために、数回実行する必要があります。

あるいは、ループファイルソースで AWS Elemental Live エンコーダーを使用し、（NTP 参照を使用するエンコーダーで）エンコーダー時間をオーバーレイとして動画に書き込み、書き込まれたタイムコードを ブラウザウィンドウで time.is などのタイムサービスと比較することもできます。通常は約 400 ミリ秒のキャプチャレイテンシーを追加する必要があります。

キャプチャレイテンシー
動画エンコードのパラメータのプリプロセッサセクションで AWS Elemental Live のタイムコード書き込みを有効にできます。エンコードラダーのビットレートごとに有効にする必要があります。

エンコーダーを低レイテンシーモードに設定したことを確認する必要があります。AWS Elemental Live では、入力パラメータの「追加グローバル構成」セクションにある「低レイテンシーモード」チェックボックスを選択することを意味します。

次に、ノート PC IP を送信先として、TS 出力セクションに 500 ミリ秒のバッファーを持つ UDP/TS エンコードイベントを設定します。

ノート PC で、:network-caching=200 オプションを指定して VLC（この例では rtp://192.168.10.62:5011）のネットワークストリームを開いて、200 ミリ秒のネットワークバッファーを使用します。書き込まれたタイムコードとカチンコのタイムコードを比較することで、VLC ウィンドウのスナップショットからキャプチャレイテンシーを計算することができます。

タブレットで NTP と同期できない場合でも、iOS の「Emerald Time」などの一部のアプリケーションでは、タブレットのタイムドリフトが NTP と比較してどれだけ大きいかを確認できます。この例では、ドリフトは +0.023 秒です。つまり、カチンコタイムは実際には 25:00.88 ではなく 25:00.86 です。書き込まれたタイムコードは 25:01:06（最後の 2 桁はフレーム番号です）で、これは（24fps でエンコードされているため）100 分の 1 秒で 25:01.25 に変換できます。したがって、キャプチャレイテンシーは (25:01.25 – 25:00.86 ) = 0.39 秒です。式は次のとおりです。キャプチャレイテンシー = 秒単位の書き込みタイムコード – (書き込みタイムコード + NTP ドリフトt).

エンコードレイテンシー
この UDP/TS エンコードイベントを使用して、動画のエンコードパイプラインによって発生するレイテンシーも計算できます。この例では、誘導レイテンシーに関して許容できるトレードオフを提案しながら、要求の厳しいシーンに対応したブロードキャストに準拠している品質を生成するために、次のエンコードパラメータを使用します。

この場合、タブレットの時間は 13:27:19.32、VLC の時間は 13:27:16.75 です。

エンコードパイプラインのレイテンシーは、次の式によって計算されます。（タブレット時間 – VLC時間）–（キャプチャレイテンシー + VLC バッファー + RTP バッファー）、つまり (19.32-16.75) – (0.39 + 0.20 + 0.50) = 1.48 秒になります

取り込みレイテンシー
キャプチャレイテンシーとエンコードのパイプラインレイテンシーがわかったので、取り込みレイテンシーを考えてみましょう。「取り込みレイテンシー」には、取り込み形式をパッケージ化し、取り込みストリームにパッケージ化を適用しないオリジンに取り込むために必要な時間が含まれます。これは、パススルーフィルター付きの AWS Elemental Delta、または AWS Elemental MediaStore です。ここでは、AWS Elemental MediaStore にプッシュされた 1 秒のセグメントで HLS を使用します。

シェルを使用して、オリジンの HLS 子プレイリストの変更をモニタリングします。

$ while sleep 0.01; do curl https://container.mediastore.eu-west-1.amazonaws.com/livehls/index_730.m3u8 && date +"%Y-%m-%d %H:%M:%S,%3N"; done

シェルの出力で最初にセグメント “index_73020180223T154954_02190.ts” が参照されているときに返されます。

#EXTM3U
[…]
index_73020180223T154954_02190.ts
2018-02-23 15:49:55,515

次に、セグメント “index_73020180223T154954_02190.ts” をダウンロードして、どのタイムコード : 16:49:53:37 (UTC+1) を運ぶのかを確認します。現在の日付とセグメントのタイムコードの差は 55.51 – 53.37 = 2.14 秒です。エンコードレイテンシーとキャプチャレイテンシーを取り除いた場合、HLS セグメントをパッケージ化して、オリジンにプッシュするために必要な時間を分離します。式は、取り込みレイテンシー =（現在の日付 – セグメントのタイムコード）–（取り込みレイテンシー + エンコードレイテンシー）です。AWS Elemental MediaStore の場合、0.27 秒になります。AWS Elemental Delta の場合、同じ計算で 0.55 秒になります。

再パッケージ化レイテンシー
AWS Elemental Delta と AWS Elemental MediaPackage に同じアプローチを適用し、以前計算された取り込みレイテンシーを追加することで、取り込まれたストリームを再パッケージ化するのに必要な時間を計算できます。式は次のとおりです。
再パッケージレイテンシー =（現在の日付 – セグメントのタイムコード）–（取り込みレイテンシー + エンコードレイテンシー + 取り込みレイテンシー）
AWS ElementalMediaPackage の場合（簡単に測定する方法がないため、取り込みレイテンシーが AWS Elemental Delta と同じであると仮定）、HLS 1 秒の取り込みから HLS 1 秒のセグメントを出力する場合、再パッケージ化のレイテンシーは (57.34 – 54.58) – (0.39 + 1.48 + 0.55) = 0.34 秒です。AWS Elemental Delta の場合、 (26.41 –23.86) – (0.39 + 1.48 + 0.55) = 0.41 秒です。

配信レイテンシー
同じアプローチが配信にも適用されます。すなわち、オリジンから CDN エッジまでの転送です。オリジンが再パッケージ化を行う場合、配信レイテンシー =（現在の日付 – セグメントのタイムコード）–（取り込みレイテンシー + エンコードレイテンシー + 取り込みレイテンシー + 再パッケージ化レイテンシー）です。オリジンがパススルーストリーミングを行う場合、配信レイテンシー =（現在の日付 – セグメントのタイムコード）–（取り込みレイテンシー + エンコードレイテンシー + 取り込みレイテンシー）です。配信レイテンシーは、オリジンの先頭に Amazon CloudFront 分布を追加し、取り込みレイテンシーの計算と同じ種類のコマンドラインを使用して測定できます。AWS Elemental MediaStore の場合、(52.71 – 50.40) – (0.39 + 1.48 + 0.27) で、0.17 秒です。このレイテンシーは、同じリージョンのすべてのオリジンタイプでは同じです。

クライアントレイテンシー
このカテゴリには、クライアントに依存する 2 つのレイテンシー要因、ラストマイルレイテンシー（ネットワーク帯域幅関連）、およびプレイヤーレイテンシー（コンテンツバッファー関連）があります。ラストマイルのレイテンシーは、ファイバー接続で数ミリ秒から、最も遅いモバイル接続での最大数秒までです。タイムコード Ｔ がクライアント側のバッファーおよび再生に利用できる瞬間に、コンテンツダウンロード期間が T+x 秒遅れるので、コンテンツダウンロード期間は直接レイテンシーに影響を与えます。遅延がセグメントの長さに比べて大きすぎると、プレイヤーが十分なバッファーを構築できず、ビットレートとネットワーク 条件、およびそのコンテンツバッファーを構築する機能の間で適切なトレードオフが見つかるまで、エンコードラダーの低いビットレートに切り替わります。最低ビットレートでも十分なバッファーを構築できない場合は、コンテンツを十分にすばやくダウンロードできないため、常に再生を開始し、停止し、再バッファーします。コンテンツのダウンロード期間がセグメント期間の 50% に達すると、プレイヤーがすぐにバッファーの観点から危険なゾーンに移動します。25％ 未満に留まるのが理想的です。プレイヤーのレイテンシーは、プレイヤーのバッファーポリシー、つまりプレイヤーが X 個のセグメントをバッファーすること、または特定の最小期間のコンテンツを必要とすること、および再生ヘッドの位置を決める戦略がもたらした結果です。

クライアントレイテンシーを測定する方法は、クライアントレイテンシー = エンドツーエンドのレイテンシー –（キャプチャレイテンシー + エンコードレイテンシー + 取り込みレイテンシー + 再パッケージ化レイテンシー + 配信レイテンシー）です。プレイヤーのレイテンシーは、全体的なクライアントレイテンシーからメディアセグメントの平均転送時間（ラストマイルレイテンシー）を差し引くことによって分離できます。ラストマイルレイテンシーの値は、少なくとも 20 のセグメント要求で計算する必要があります。実際のデータ転送時間とクライアントが生成するレイテンシーが含まれます。例えば、セグメント要求が作成されたときに、特定のサブドメインに対して許可されているすべてのソケットが、現在オープンされている場合などです。

これは、Amazon CloudFront と一緒に標準 hls.js 0.8.9 プレイヤーに配信された、AWS Elemental Live および AWS Elemental MediaStore で作成された HLS 1 秒セグメントの内訳の例です。

ご覧のとおり、エンコードと再生の手順はレイテンシーのほとんどを生成しています。改善マージンのほとんどが位置するところです。他の手順を最適化する方法がないわけではありませんが、最適化による影響は最小限に抑えられます。出力メディアセグメントの時間が長くなると、通常、プレイヤーとラストマイルのレイテンシーは長くなりますが、他の手順は安定したままです。

シリーズのパート 2 では、ワークフローの各手順に適用できる最適化オプションについて説明します。

Nicolas Weil
AWS Elemental シニアソリューションアーキテクト