【4回シリーズ／4回目】メディアサービス － リファレンスアーキテクチャとテスト結果

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

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

パート 4：参照アーキテクチャとテスト結果

このブログシリーズの前回の記事では、ビデオ処理と配信のチェーン、およびビデオプレイヤー全体のレイテンシーを最適化するオプションについて説明しました。それでは、ライブ動画のワークフローを展開するときに低レイテンシーを優先する場合に最良の結果をもたらすいくつかの参照アーキテクチャと、それに関連するエンドツーエンドレイテンシーについて検討してみましょう。私たちは 2 つの異なる軸に取り組みました。1 つはオンプレミスに完全デプロイできるシナリオ、もう 1 つはクラウドで AWS Elemental メディアサービスを使用して、エンコードを提供または貢献する 3 つのハイブリッドシナリオです。このアプローチにより、既存の機器やサービスに期待できることを視覚化し、それらを AWS Elemental メディアサービスと組み合わせて、要件に合うレイテンシーレベルを達成する方法を習得することができます。

これらのテストで使用される共通パラメータは、エンコードのプロファイルと DASH パッケージ化のパラメータです。

• エンコード： AVC 360p@700Kbps / 720p@3Mbps / 1080p@5Mbps
• DASH パッケージ化：
  • SegmentTemplate/$Number%09d$
  • minBufferTime="PT2S"
  • suggestedPresentationDelay="PT1S"
  • timeShiftBufferDepth="PT3S"

テーブルには、テストストリームのさまざまな変形が表示されます。

• 3x1s は、DVR プレイリストがそれぞれ 1 秒のセグメント 3 個を公開することを意味します
• 3x2s は、それぞれ 2 秒のセグメント 3 個を意味します
• 3600x1s は、1 秒のセグメントあたり 1 時間の DVR を意味します

目的は、短いセグメントを作成する最も効率的な戦略と、45 分のような長時間の再生における標準プレイヤーと最適化されたプレイヤーの動作を調べることです。従来の HLS および AVC を使用した DASH を補完するものとして、HEVC および fMP4/CMAF を使用する場合、より多くのテストが必要です。ただし、現在のテスト結果では、AWS Elemental ソリューションとさまざまなプレイヤーを使用して、レイテンシーに関して達成できることの概要を把握できます。

完全なオンプレミスのシナリオから始めます。エンコードには AWS Elemental Live、パッケージ化と供給元には AWS Elemental Delta が含まれます。これは、オンプレミスに展開されているすべてのコンポーネントを含む、マルチ画面配信用の有料テレビ事業者の一般的なワークフローに対応しています。

シナリオ 1

このシナリオは、複数のタイプの取り込み形式でテストされました。HLS および RTMP 入力は、UDP 入力よりわずかに良い結果を提供します。緑色は、最高の再生安定性が得られる組み合わせの概要を説明します。AWS Elemental Delta では 1 秒のセグメントを作成できますが、それに関して使用されるストレージソリューションの読み取り/書き込みパフォーマンスでは、許容できる量の再バッファーで再生できる 1 秒のセグメントを作成し配信する機能が制限されます。Safari mobile と 2 秒のセグメントでは、10 秒のしきい値をわずかに超えているため、完全に満足するわけにはいきません。

AWS Elemental Delta と通常のストレージソリューションを使用する場合は、2 秒のセグメントを HLS と DASH にパッケージ化することをお勧めします。1 秒のセグメントを使用するには、より高い読み取り/書き込みパフォーマンスを提供するストレージソリューションが必要です。

2 番目のシナリオは最初のシナリオに似ていますが、地上とクラウドの間のハイブリッドワークフローを使用します。エンコードは地上で実行され、パッケージ化と供給は AWS Elemental MediaPackage を使用した AWS で実行されます。これは、主要スポーツイベント期間のように、一時的にチャネルをサポートする既存のオンプレミスワークフローの進化に対応しています。

シナリオ 2

このシナリオは、レイテンシーに関して、最初のシナリオに非常に近いです。DASH での Exoplayer の結果は、このテストでは少し遅れています。一般的に、このプレイヤーで予測できるレイテンシーはもっと短いです。ここでは、インデックス期間が重要な要素と思われます。DASH で 3 個のセグメントのみを表示することでは、すべての状況で同等に機能するとは思われません。

AWS Elemental MediaPackage では、HLS と DASH で 2 秒のセグメントを作成することをお勧めします。1 秒のセグメントを使用する場合はプレイヤーの調整が必要です。

3 番目のシナリオは、アップロード帯域幅がオンサイトで制限されていて貢献エンコーダーを使用する必要がある、1 つの形式の単純なライブイベントに適しています。ビットレート変形のエンコードは、クラウドベースのサービス（この例では AWS Elemental MediaLive）にオフロードされ、HLS にパッケージ化されたライブストリームがオリジンとして AWS Elemental MediaStore に公開されます。

シナリオ 3

これが、アーキテクチャで集めた結果です。1 秒のセグメント（およびビットレートの半分でバッファーサイズのパラメータを使用）では、レイテンシーは 7 秒弱になります。したがって、ほとんどの要件でうまく機能します。この特定のワークフローでのセグメント長に関する推奨事項です。

AWS Elemental MediaStore の設計とパフォーマンスは特に低レイテンシーを重視しているため、AWS Elemental MediaLive と AWS Elemental MediaStore を組み合わせることで、HLS で 1 秒のセグメントを使用することをお勧めします。

これにより、AWS Elemental Live を使用した地上でのエンコードと AWS Elemental MediaStore を介した AWS での供給を組み合わせた、最後のハイブリッドシナリオが自然に発生します。これは、アップロードの帯域幅に厳しい制約がない場合のシナリオで、レイテンシーを最小限に抑えた上で複数の形式が必要です。このシナリオでは、これが最速の参照アーキテクチャであるため、1 秒のセグメントのパッケージ化タイプのみをテストしました。

シナリオ 4

以前のテストと比較して、プレイヤー最適化の利点を強調するために、Shaka プレイヤー 2.3.0（標準）と Shaka プレイヤー 2.3.0（最適化）の 2 つの新しいプレイヤーを追加しました。今回のリリースでは、レイテンシーを 0.6 秒（DVR 3 秒）から 4.2 秒（1 時間）にする、新しい低レイテンシーモード（フェッチ API を利用）をもたらし、dash.js テストのプレイヤーも v.2.6.5 から v2.7.0 にアップグレードしました。 テスト中に AWS Elemental Live 2.12.3 で新たに出現した 1 つの形式である、HLS 用の断片化 MP4（fMP4）は CMAF として知られています。さらに、Transport Stream（TS）セグメントを MP4 セグメントに置き換えることができます。この形式は HLS のライブユースケースでは比較的新しいため、プレイヤーがこの形式を実行および動作させる方法は興味深いです。実際には混在した結果で、プレイヤーの半分のみが利用しています。

また、長いインデックス期間を持つプレイヤーの動作を観察するために、1 時間の DVR（3600×1 秒列）ウィンドウを導入しました。HLS の Shaka のように、結果として生じるレイテンシーが 10 秒に達する一部の例外を除いて、非常にうまく動作します。

fMP4 では、hls.js が再生ヘッドを DVR 開始時間の先頭に配置します。これは、3600×1 秒 HLS の結果を説明しています。Shaka では、オーディオバージョンを多重化した 3×1 秒 HLS が機能しません。1 時間の DVR HLS（TS）と多重化したオーディオでは、ストリームが開始されることもあれば、開始されないこともあります。Shaka に 2 つの最適化を適用すると、短い DVR ウィンドウで HLS（TS）と DASH のレイテンシーが大幅に減少します。

• config.streaming.bufferingGoal = 2
• config.streaming.rebufferingGoal = 2

私たちは現在、hls.js と Shaka の両方の開発者コミュニティと協力して、各プレイヤーで見つかった問題に対処しています。全体的な結果はかなり良く、プレイヤーは 1 秒のセグメントで非常に安定した方法で動作します。一部プレイヤーのビットレート切り替えアルゴリズムは、そのような短いセグメント期間によって明らかに難題になっています。ただし、そのプレイヤーには改善の余地があります。ほぼすべてのプレイヤーに、fMP4 を最適化させる作業がいくつか残っていますが、この形式の新しさを考えると良いスタートと言えます。動画プレイヤーのエコシステムはレイテンシー問題にますます敏感になっており、すべてのプラットフォームで低レイテンシーを適切にサポートするために開発に注力しています。

結論
HEVC 形式のテストと、最適化されたオープンソースプレイヤーによる追加実験との間で、まだ補完されていないブログ記事を生み出す、フォローアップ作業がまだ残っています。しかし、レイテンシーは致命的な問題ではありません。「標準」HLS、DASH、および CMAF/fMP4 テクノロジーを使用することで、ある程度の努力で効率的に最小化できることを強調したいと思います。

最適化されたプレイヤーでは、現在 HLS と DASH のワークフローで、4 秒のレイテンシーを可能にします。これらのテクノロジーは HTTP 1.1 および HTTP 2.0 に完全に準拠しているため、技術的および経済的な観点から低レイテンシーの追求をスケーラブルにします。 低レイテンシーを実現するために、高価な UDP ベースのソリューションを導入する必要はありません。お客様のビジネスが 4 秒未満のレイテンシーを必要とする場合は、チャンクされた CMAF が間近にあり、現在エンコーダーで生産されているセグメントのチャンクとオリジンを消費することによって、プレイヤーがレイテンシーを下げる機会をもたらします。放送の世界ではライブ TS の概念に非常に近いですが、HTTP を使用するジャストインタイムのエンドツーエンドのワークフローを提供します。

現在のところ、10 秒のエンドツーエンドのレイテンシーは、HLS または DASH を介して接続されたすべてのデバイスに対処できる、新しい標準です。ビジネスに必要な場合、すでに安定した 5 秒のレイテンシーを利用できます。もう 30 秒の壁を超えるために、実験を続けることも、待つ必要もありません！

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