【4回シリーズ／3回目】メディアサービス － 動画プレイヤーのおすすめ最適化

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

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

パート 3：動画プレイヤーのおすすめ最適化

このブログシリーズの前回の記事では、動画ワークフローのエンコード、パッケージ化、および CDN 配信の手順に適用できる最適化について説明しました。ここでは、レイテンシー改善の最も重要な分野、つまり動画プレイヤーのパラメータについて語ります。ワークフローのパラメータをアップストリームで最適化したとしても、低レイテンシー指向のメカニズムを統合していない動画プレイヤーでは、これらの努力が無効になる可能性があります。このセクションでは、オープンソースの動画プレイヤーを最適化する提案を行い、商用プレイヤーについては、このトピックに関して協力してくれた AWS Elemental テクノロジーパートナーの castLabs と Accedo のアプローチを紹介します。

動画再生の最適化

動画プレイヤーは、エンドユーザーが中断されることなく再生を利用できるように最適化されていることが多く、ストリームのレイテンシーを短縮するよりもバッファーの長さを優先します。低レイテンシーを有効にするオプションが完全に欠如していること、各プレイヤーの初期設定でこれらのオプションがデフォルトで有効になっていないことを意味するわけではありません。

ストリームに対して、プレイヤーが可能な限り低レイテンシーを提供することを妨げる可能性がある問題については、こちらに非網羅的なリストがあります。

• 初期バッファーサイズ：ほとんどのプレイヤーは、ストリーム再生を開始する前に、特定の数のセグメント、数秒、またはメガバイト（MB）をバッファーするように設計されています。1 秒と 2 秒のセグメントでは、通常、問題になりません。プレイヤーが3 つ以上のセグメントをバッファーしない場合は 10 秒未満のレイテンシーが可能です。しかし、長い DVR ウィンドウがライブプレイリスト/マニフェストに表示されている場合は、特定の時間をバッファーするように設計されているプレイヤーもあります。この場合、セグメントの長さが 1 秒であっても、最終的には 30〜40 秒のバッファーが必要になります。これにより、レイテンシーが短くなることを防ぎます。そのため、デフォルトでのプレイヤーのバッファーポリシーを確認し、プレイヤーが消極的すぎる場合は起動時のバッファー長を制限する方法を探す必要があります。通常、バッファーを 3 秒または 4 秒に制限することは、レイテンシーと再生の安定性の間の妥当なトレードオフです。3 秒未満にすると、レイテンシーが明らかに改善されますが、再生セッションと並行して定期的な再バッファーフェーズが発生するため、ユーザーエクスペリエンスも危険にさらされます。
• ライブエッジタイムと比較した、ライブタイムライン内でのプレイヤーの初期位置：ほとんどのプレイヤーにとって、前のポイントと重複していますが、常にそうとは限りません。プレイヤー設定で起動時のバッファー時間を短く設定した場合、再生ヘッドをストリームのライブエッジタイムと比較して x 個のセグメントまたは秒単位で遅れて開始するように設定すると、効率が悪くなる可能性があります。これは補完的な設定で、その後カスタマイズが必要です。
• ライブエッジタイムの持続性：プレイヤーがライブエッジタイムと比較して、予想される遅延で再生を開始した場合でも、再バッファーが発生したら、再バッファー前の最後の既知タイムコードから再生が再開される可能性があります。つまり、プレイヤーが再バッファーに要する時間がわずか 100 ミリ秒であれば、再バッファーフェーズの後、ライブエッジタイムと比較して自動的に同じ時間だけ遅れることになります。これは通常すべてのプレイヤーからデフォルトで起こることですが、一部がドライバッファー効果の後にプレイリスト/マニフェストをリロードするオプションを提供する（オーディオまたはビデオトラックのバッファーがゼロ秒になり、動作できなくなる）、または そのような状況では、タイムを見越してライブエッジタイムに注意してください。再生セッション全体で最短レイテンシーを維持し、ライブセッションでエンドユーザーが 1 秒ごとにコンテンツを処理しないようにすることを優先する場合、プレイヤーがオープンソースを活用または追加するためのオプションです。どのような場合でも、時間の経過とともにレイテンシーを変動させたくない場合は、プレイヤーにとって重要な機能です。
• セグメントの回復力を利用できない：指定されたメディアセグメントをまったく利用できないか、プレイヤーの予想と比較して少し遅れて利用できることがあります。この場合、プレイヤーはセグメントのロードを数回再試行し、すべての再試行後にセグメントがまったく使用できない場合は、再生セッションを停止する可能性があります。このようなユースケースでは、再試行回数を増やすため、低いビットレートに切り替えるため、またはタイムラインで欠けているスライスをスキップするためにプレイヤーオプションを探すことができます。

オープンソースプレイヤー

hls.js

MSE（Media Source Extensions）環境用のオープンソース HLS プレイヤーは、config.js の初期ファイルでさまざまなパラメータを数多く公開しています。一部のパラメータを試して、減らしてください。

• maxBufferLength（デフォルト：30 秒）は、プレイヤーがバッファーを試みる最大秒数です
• maxBufferSize（デフォルト：60MB）は、プレイヤーがバッファーを試みる最大のコンテンツサイズ（MB）です
• maxStarvationDelay（デフォルト：4 秒）は、再バッファーの最大許容秒数です。これを減らすと、プレイヤーに低下したビットレートへの切り替えを強制することで、大きな再バッファーフェーズを防ぐことができます。
• liveSyncDurationCount（デフォルト：3）は、起動時に最後に参照されたセグメントの後にあるセグメント数です。低くすると、プレイヤーがライブエッジタイムに近くなります。

hls.js 0.9.1 より前のバージョンで、プレイリストのリロード間隔を 1 秒より短くする必要がある場合は、次の level-controller.js 行でハードコード化された 1000 の値を減らす必要があります。
reloadInterval = Math.max(1000, Math.round(reloadInterval));

dash.js

MSE 環境用のオープンソース DASH プレイヤーは、ライブエッジタイムと比較して初期遅延を設定する複数の方法を提供します。player.setLiveDelayFragmentCount（デフォルト：4）は、ライブエッジタイムより後ろのセグメント数を指定し、player.setLiveDelay はそれを秒単位で指定します。「最終的に達成される遅延は、セグメント境界に関してストリームが要求されたときのセグメント期間、およびソースバッファーがデコードを開始するために必要なデータ量の関数です」と、ライブ遅延プレイヤーのサンプルの一つに関して語ります。カスタマイズしたい他のメソッドパラメータは次のとおりです。

• player.setFragmentLoaderRetryInterval（デフォルト：1000 ミリ秒）は、失敗したフラグメントのロード試行間隔をセグメントの長さの 3 分の 1 にします
• player.setFragmentLoaderRetryAttempts（デフォルト：3）は、以前のカスタマイズを補うために増やすことができます
• player.setBandwidthSafetyFactor（デフォルト：0.9）は、より消極的なスループット計算を強制するために 0.5 に下げることができます
• player.setStableBufferTime（デフォルト：12 秒）を大幅に下げることで、起動後やバッファーターゲットを制限したり、ビットレートの切り替えを早くしたりすることができます
• player.setBufferToKeep（デフォルト：20 秒）を大幅に下げて、ソースバッファーの長さを制限し、バッファーされたビットレートの変形をより反応的に回転させることができます
• player.setBufferTimeAtTopQuality（デフォルト：30 秒）を大幅に下げると、最高品質の再生時に内部バッファーターゲットを制限できます
• player.setLowLatencyEnabled（デフォルト：false）：v.2.6.8 から、従来の XHR ロードメカニズムの代わりに、ブラウザのフェッチ API を利用するためにこのパラメータを ‘true’ に設定することができます。長い DVR ウィンドウのレイテンシーに非常に効率的な影響を与えます。

Exoplayer

この Android 用オープンソースプレイヤーは、HLS と DASH を含め、複数のストリーミング形式と互換性があります。HLS では、Exoplayer はプレイリストが参照するセグメントが少なすぎるため、問題が生じる可能性があります。DASH では、マニフェストでアドバタイズされた suggestedPresentationDelay がデフォルトで採用されています。低レイテンシーのエクスペリエンスを最適化するために変更できるパラメータがいくつかあります。

• 404 のセグメントでより多く再試行を許可するために、HlsMediaSource クラスと DashMediaSource クラスの DEFAULT_MIN_LOADABLE_RETRY_COUNT 値（デフォルト：3）を増やすことができます
• ChunkedTrackBlacklistUtil クラスの DEFAULT_TRACK_BLACKLIST_MS（デフォルト：60000）を減らすことで、404 が連続しているビットレートの変形がブラックリストに登録される確率を減らすことができます
• 最後に、DefaultLoadControl クラスでデフォルトのバッファー値を減らすことができます。DEFAULT_MAX_BUFFER_MS（デフォルト：3000）、DEFAULT_BUFFER_FOR_PLAYBACK_MS（デフォルト：2500）、DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS（デフォルト：5000）検索または再バッファー後に再生セッションの開始時にロードされるコンテンツをより厳密に制御します

Shaka プレイヤー

この MSE 環境用オープンソース HLS および DASH プレイヤーは、デフォルト値が消極的であるため、レイテンシーの短縮を変更できる複数のパラメータオプションを提供します。

• streaming.bufferingGoal（デフォルト：10 秒）は、プレイヤーがバッファーを試みるコンテンツの秒数です。ロードされたセグメントの数に影響します
• streaming.rebufferingGoal （デフォルト：2 秒）は、再生を開始する前にプレイヤーがバッファーに持ち込む必要があるコンテンツの秒数です。起動フェーズと再バッファーフェーズに有効です。DASH マニフェストの minBufferTime がこの値より大きい場合、上書きします。
• retryParameters.maxAttempts （デフォルト：2）は、プレイヤーが失敗するまで、指定されたセグメントに対する最大要求数です
• retryParameters.baseDelay （デフォルト：1000 ミリ秒）は、再試行間の基本遅延です
• retryParameters.timeout （デフォルト：0、無いに等しい）は、要求のタイムアウトを定義するミリ秒単位の遅延です
• retryParameters.backoffFactor （デフォルト：2）は、再試行間の遅延を増やすために baseDelay に適用される乗数です

すべての retryParameters は、マニフェストにも適用できます。

商用プレイヤー

免責事項：この記事の内容および意見は第三者の作者によるものであり、AWS はこの記事の内容または正確性について責任を負いません。
これらの結果は、このブログシリーズのパート 4 のシナリオ 4 と一致する参照アーキテクチャを使用したテストによるものです。

すべての castLabs プレイヤーの共通構成および共通 ABR
当社の PRESTOplay プレイヤーの SDK は、「共通構成」フレームワークを特徴としています。プレイヤー間で同じ JSON オブジェクトを使用することで、共通構成は複数のデバイスやプラットフォームにまたがって、再生アプリを構築する開発時間を節約し、プレイヤー間の A/B テストを簡素化します。

PRESTOplay SDK の固有機能では、次のことができます。

• すべての castLab の PRESTOplay SDK で同じ構成を使用
• 開発プロセスをより簡単にさせ、エンドユーザーエクスペリエンスを統一
• 「共通 ABR」：低レイテンシーのライブストリーミングに独自の最適化を含め、ヒューリスティックとバッファーの改善
• クラス最高のレイテンシーを達成する標準ストリームタイプ「安全要件」（HLS の 3 セグメントのレイテンシーを克服するなど）を手動で上書き

共通構成は、「共通 ABR」機能によって補完されています。共通 ABRは、すべてのプレイヤープラットフォームで同じ適応型ビットレートのヒューリスティック/アルゴリズムおよびバッファーロジックを採用する、castLabs の PRESTOplay 製品の独自の機能です。他のプレイヤーベンダーが、標準 ABR とバッファーロジックを持つネイティブプレイヤーを介してのみサポートできる iOS が明示的に含まれます。castLabs は、厳密に制御された超低レイテンシーを実現する独自の機能を備えた共通 ABR を開発しました。これは、業界の平均をはるかに下回り、現在のストリーミングプロトコルの一般的な保証/標準をはるかに超えます。

5 秒未満のレイテンシーを達成することができ、（エンコーダーが 2 秒を超えないセグメントを生成する限り）プレイヤーを正確に ±0.5 秒の精度で整列させることができます。最適な場合、castLabs のプレイヤーは、MPEG-DASH 用に 1 秒のセグメントで 2.5 秒のレイテンシーを達成することができます。

当社の共通構成には、ライブ低レイテンシーシナリオ用プレイヤーの初期化設定が含まれています。例えば、以下のオプションは低レイテンシー再生に関連しており、ブラウザ、Android、および iOS の各プレイヤーテクノロジーにおいても同じです。これは当社がサポートする将来のすべてのプレイヤープラットフォームでも同じです。以下は、すべての PRESTOplay プレイヤープラットフォームで同等に機能し、独自の共通 ABR で低レイテンシーモードを有効にする共通構成オプションです。

{
…
“lowLatencyMode”: true,
“suggestedPresentationDelayMs”: 0,
“lowLatencyCatchupMode”: “speedup|seek|none”,
“lowLatencyCatchupThresholdMs”: 3000,
“lowLatencyCatchupRate”: 1.1
...
}

「lowLatencyMode」が有効になっていると、プレイヤーはライブに固執し、できるだけライブに近い感じでプレイしようとします。明示的に指定されていない場合、ライブエッジからの距離は低レイテンシーモードで 0 に設定されます。「suggestedPresentationDelayMs」パラメータでさらに調整できます。

動的ライブエッジの追跡
「lowLatencyCatchupMode」は、現在のライブエッジから遅れたとき、プレイヤーの動作を構成するために使用できます。バッファアンダーランが発生し、プレイヤーがデータ待機状態のときなどに発生します。このパラメータが「なし」に設定されていると、プレイヤーは追いつかずに、そのままプレイを続けます。「スピードアップ」に設定されている場合、現在の再生位置が現在のライブエッジから「lowLatencyCatchupThresholdMs」ミリ秒以上経過した後、プレイヤーが再生レートを上げます。スピードアップレートは「lowLatencyCatchupRate」パラメータでコントロールでき、プレイヤーが再びライブエッジに近づくと 1.0 に戻ります。パラメータが「検索」に設定されている場合、プレイヤーは構成されたしきい値を超えて遅れた場合、ライブエッジにジャンプします。

AWS Elemental テストストリームと castLabs プレイヤーを使用して測定された結果は次のとおりです（テストは AWS Elemental チームによって実行されました）。

Accedo では、最高のビデオユーザーエクスペリエンスを実現することに重点を置いています。独自のプレイヤーは提供していませんが、ビデオおよびライブフィードのストリーミングに関して、ベストプラクティスを検討しました。当社にとっては、ストリームの開始時間と手振りレイテンシーの両方です。

最初のパラメータは、この準備段階にかかる時間が長くなるほど「遅延」という知覚を追加するため、UX に直接影響を与えますが、バッファーが信頼できるフィードを十分配信するほど大きくない場合、2 番目のパラメータはユーザに影響します。開発者にとっては、ストリームの開始時間を最適化するために、次を考慮することをお勧めします。

• ストリームを開始する前に行われた同期呼び出し（同時実行チェックなど）を制限し（排除しようとし）、非同期に実行し、ストリームが開始された後に実行します
• 再生が予想されるときにライセンスをプリフェッチします（例えば、再生要求につながると思われる資産の詳細ページにいるユーザーなど）
• 権利をプリフェッチし、ユーザーが資産をストリーミングすることが許可されているかどうかを判断します
• QoE ツールを使用して、最初のフレームまでの時間、およびネットワーク特性がリージョンごとに異なる設定の調整に失敗する場合について分析します

手振りレイテンシーに関しては、バッファーサイズとレイテンシーの間にバランスがあります。Apple HLS のセグメントサイズのガイドラインを考慮しない場合は、小さなチャンクを検討し、開始時にバッファーするメディアの持続時間、ストリーミング中に再バッファーした後にバッファーするメディアの持続時間などのパラメータを検討することは本当に興味深い方法です。また、バッファーの最大サイズもレイテンシーの短縮に役立ちます。

iOS テスト
iOS 11.2.5 で default-buffer-control=true および AVPlayer automaticallyWaitsToMinimizeStalling = true のテストを行いました。

Android テスト
Android 7.0 で default-buffer-sizes-for playback-start=2.5s、 default-buffer-sizes-after-rebuffer=5s、stream-download-buffe-minimum=15s、stream-download-buffe-maximum=30s パラメータの Exoplayer 2.5.4 でテストを行いました

これらのテストでは、セグメントのサイズを小さくすることでレイテンシーを短縮できると示していますが、ストリームの信頼性が重要であることを忘れないでください。Accedo では、お客様のための AWS 関連 Accedo One Cloud プラットフォームで、バッファーの関連パラメータを設定して最適値を見つけることをお勧めします。配信チェーンは、展開したサービス（エンコード、パッケージ化、CDN、リージョンネットワーク）ごとに異なります。サービスを開始するときは安全な構成で初期化する必要がありますが、お客様はこれらのパラメータを独自のテクノロジーチェーンに合わせて、できるだけレイテンシーを短縮する必要があります。最適化と呼ばれる A/B テストサービスのおかげで、お客様はさまざまな構成をテストして UX への影響（再バッファー、再生保持時間など）を評価し、独自の最適化設定を定義することができます。

シリーズのパート 4では、AWS Elemental の製品とサービスを活用した複数のソリューションアーキテクチャと、関連テストの結果を参照プレイヤーで測定したEnd-toｰEndのレイテンシーについて説明します。