【4回シリーズ／2回目】メディアサービス － エンコード、パッケージ化およびCDN配信のおすすめ最適化

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

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

パート 2：エンコード、パッケージ化、および CDN 配信のおすすめ最適化

このブログシリーズの最初のパートでは、なぜレイテンシーが OTT ストリーミングで問題になるのか、そしてエンドツーエンドのレイテンシーにおけるさまざまなワークフロー手順の責任を測定する方法について説明しました。エンコード、パッケージ化、CDN 配信の手順から始めて、可能な最適化について説明します。上記のパラメータを操作することで、視聴者に最適化された低レイテンシーのライブストリームを準備することができます。

エンコード
低レイテンシーモードの入力パラメータを使用して、AWS Elemental Live でキャプチャレイテンシーを最適化する方法についてはすでに説明しました。このパラメータは、入力タイムスタンプの不連続性により、オーディオパケットがドロップされる可能性があることに注意してください。バッファー サイズの入力パラメータを使用して、入力段階でバッファーされるフレーム数を最小限に減らすこともできますが、一部のフレームがドロップされる危険性があります。

動画のエンコードセクションでは、複数のパラメータがレイテンシーに影響を与えることがあります。

• 先読み：この値を低く設定すると、求められるシーンの出力品質を下げて、レイテンシーが改善されます。 ただし、シーンの変更がまったくないか、ほとんどない場合は、主に低い方が良好に機能します。
• GOP パラメータ：必要に応じて 2 秒のセグメントで再パッケージ化できる、1秒のクローズド GOP を使用することをお勧めします。B フレームのない小さな GOP は、一般的に動画品質を低下させます。
• B フレーム：GOP において使用される B フレームが多いほど、エンコードエンジンは B フレームを構築するために次の P フレームを先読みするため、追加される B フレームごとにエンコードのレイテンシーが数フレーム増加する確率が高くなります。ゼロの B フレームを使用すると、このレイテンシーの影響を回避することはできますが、B フレームを使用するときと同品質のレベルを維持するにはエンコードビットレートを上げる必要があります。
• 時間適応型量子化：オフにすると、レイテンシーが数フレーム短縮されます。他の適応型量子化オプションはレイテンシーに影響を与えません。
• エンコードのバッファーサイズ：動画ビットレートの2倍のビットがデフォルト値で、デコーダに2秒のレイテンシーが生じます。ビットレートを 1 倍に設定すると、1 秒のレイテンシーが発生し、動画の品質にわずかな影響を与えます。非常に積極的な低レイテンシーのターゲットでは、バッファーサイズをビットレートの半分に設定すると、レイテンシーが GOP（1/2 秒）の半分になります。もちろん、動画の品質はもっと影響を受けます。ビットレートが 1/2 倍の場合は、動画品質への影響はより深刻になります。
• 動画プリプロセッサ：インターレース解除のプロセッサが必要な場合は、低レイテンシー補間アルゴリズムを選択する必要があります。

AWS Elemental MediaLive では、[ストリーム設定] > [フレームレート] セクションのプログレッシブなスキャン型を通り超して、公開されていない最新設定を除いて、同じ設定を使用できます。エンコードラダーに関しては、セグメントのサイズが通常より短いにもかかわらず、困難なネットワーク条件でモバイルデバイスが依然としてストリームにアクセスできるように、ラダーの下端に軽量ストリームを追加することをお勧めします。

パッケージ化
ほとんどすべてのプレイヤーは、レイテンシーに対するセグメント期間の機械的な影響を受けます。1 秒の期間セグメントで、5 秒のレイテンシーに達することが可能です。2 秒の期間セグメントでは、かなり不可能に近いです。そしてプレイヤーの設定に重大な最適化を適用しない限り、結果は常に 7～10 秒の間になります。1 秒のセグメントは自動的に薄いプレイヤーのバッファーを生成します。したがって、プレイヤーがドライバッファーを素早く克服するために特定のメカニズムを提供しない限り、再生セッションの堅牢性は低下します。

要件に合わせて、適切なセグメントサイズを選択することが非常に重要です。7 秒未満のレイテンシーを明確に達成する必要がない場合は、1 秒のセグメントを使用せず、2 秒のセグメントを使用してください。7〜10 秒のレイテンシーでは問題ありません。プレイヤーで 2 秒のセグメントを使用している場合は、次のような利点もあります。

• GOP の長さを 1〜2 秒に増やすと、一定のビットレートでエンコード品質を向上させることができます。
• 元の取り込み時に 2 秒のセグメントを使用します（取り込みの形式に HLS を使用する場合）。元のストレージとパッケージ化の計算にかかるストレスが軽減されます。

インデックス期間（DVR ウィンドウの長さ）は、レイテンシーにも影響を与えます。一部のプレイヤーでは、プレイリスト/マニフェストに 1 時間 DVR ウィンドウを表示した場合、最後の 3 つのセグメントのみを参照してプレイリスト/マニフェストを表示した場合よりも多くのバッファーが発生します。

AWS Elemental Live では、ネットワーク転送エラーを通常より早く修正する必要があるため、HLS/DASH 再試行間隔の公開を低くする必要があります。2 秒セグメントの場合は 1 秒に設定し、1 秒セグメントの場合は 0 秒に設定します。

CDN 配信
レイテンシーを減らすために CDN 構成で変更できることはあまりありません。Amazon CloudFront がチェーンに沿って人工バッファーを追加することはありません。他の CDN を AWS Elemental オリジンサービスと組み合わせて使用している場合は、CDN アーキテクチャによって意図的に生成された CDN 組み込みのバッファーがあります。その場合は、可能であれば配信構成で CDN プロフェッショナルサービスを無効にするように依頼してください。

HLS プレイリストおよび DASH マニフェストの場合、プレイヤーがこの種の圧縮をサポートしている場合は、CDN 構成で gzip 形式で配信できることを確認してください。HLS または DASH/SegmentTimeline で長い DVR ウィンドウが使用されている場合は、ロード操作が簡単になります。

低レイテンシーモードのプレイヤーは、通常のライブエッジタイムと比較してリクエストに積極的であるため、将来的にセグメントをリクエストする可能性が高く、その結果エッジで 404 秒になります。各 CDN は、これらの 404 をキャッシュする固有のデフォルト TTL 値を持ちます。通常、この値は低レイテンシーのストリームには適していないため、調整する必要があります。Amazon CloudFront 分布の場合は、構成パネルの [エラーページ] セクションで 1 秒に設定できます。

低レイテンシーとは無関係ですが、それでもワークフローにとっては重要です。オリジンから返されるすべてのダウンストリーム CORS ポリシーにとって重要なトリガーとなるため、CDN がオリジンに転送するように、「オリジン」受信ヘッダーをホワイトリストに登録する必要があります。Amazon CloudFront の場合、構成パネルの [動作] セクションで設定できます。

最後に、HLS プレイリストまたは DASH マニフェストの TTL が CDN 側に設定されている場合は、それらが HLS セグメンテーション間隔または DASH マニフェスト更新間隔より短いか等しいことを確認する必要があります。

シリーズのパート 3では、動画プレイヤーに適用できる最適化オプションについて説明します。