当社は、Brightcove Player での HLS 再生をより良く、より速く、より安定したものにするために取り組んでいます。そのためには、思い込みを捨て、先入観なしに直面している問題に目を向ける必要がありました。
チャレンジ
Media Source Extensions (MSE) を使用する再生エンジンの主な責務の1つは、任意の時点でサーバーに要求するビデオデータ (セグメントまたはフラグメントと呼ばれる) を決定することです。
ビデオ・オン・デマンド（VOD）の HLS ソースの場合、判断は極めてシンプルです。我々は、すべてのセグメントとその（おおよその）時間を知っています。その情報をもとに、どのセグメントをダウンロードするかを選択するのは簡単なことです。
残念ながら、HLSのライブ・ストリームでは、物事はそれほど単純ではありません。セグメントの全履歴が欠落しているだけでなく PROGRAM-DATETIME タグ（HLS 仕様に最近追加されたもの）を使用した場合、異なるプレイリスト間でセグメントを関連付ける簡単な方法はありません。プレーヤーに残された唯一の選択肢は、メディアの内部タイムスタンプを使用するために、セグメントを推測的にダウンロードすることです。
要するに、ライブ再生の問題は、多くの「未知数 」があるために、初回に正しいセグメントを選択することが難しい場合があります。
フェッチアルゴリズム
誤ったセグメントを選択してしまうフェッチアルゴリズムの傾向に対抗するため、制御理論からいくつかの概念を借用しました。以前は、フェッチアルゴリズムは
- 限られた情報から可能な限り最善の推測をする
- 推測が間違っていた場合、そのリクエストから得た情報を使って、より良い推測をする（「誤差」を小さくする）
- 繰り返す
アルゴリズムが繰り返し改善され、最終的に正しいセグメントがダウンロードされることを期待していました。問題は、「エラー」とは何かを考え始めたときに生じます。私たちのアルゴリズムでは、エラーをビデオバッファのデータが欠落している領域と定義しました。
ここで考えられるのは、セグメントAをフェッチした後にセグメントCをフェッチした場合、Bサイズの ギャップを埋める必要があるということです。アルゴリズムは、そのエラーを埋めるためにバックトラックを行い、セグメントBを選択してからDに進むべきです。
良いニュースは、99％の確率でこれが機能し、非常にうまくいったということです。悪いニュースは、1％の確率で、本質的に埋められないギャップを埋めようとして詰まってしまうことです。このようなことが起こるのは、たいてい再生しているソースの性質によるものです。HLSソースの中には、オーディオとビデオがすべてのバリアントで同じ時点でセグメント化されず、ギャップが生じるような、セグメント化が不十分なものがあります。HLSソースの中には、破損したフレームや欠落したフレーム（オーディオまたはビデオ）を持つものがあり、これもギャップの原因となります。
原因が何であれ、バッファのこれらの埋められない部分は、アルゴリズムがバッファを埋めようとして立ち往生する状況を作り出しました。私たちは最終的に、フェッチャーがスタックしないようにするための多くのアプローチを組み込みました：
- 非常に小さなギャップは、ソースに内在するものと考え、無視する。
- アルゴリズムが、前回の繰り返しでフェッチしたセグメントと同じセグメントをフェッチしようとした場合、1つ以上のセグメントを強制的に前方にフェッチさせる。
- 不必要な帯域幅の浪費を避けるため、境界が90%以上バッファに表現されているセグメントをロード済みとみなす。
これらの戦略の問題点は、故障する状況が非常に特殊だということです。「修正」を試みるたびに、滅多に発生するはずのない厄介な不具合の数は増えていきました。多くの場合、フェッチアルゴリズムの小さな変更でさえ、以前はうまくいっていた奇妙なシナリオの下では失敗することがわかりました。
心機一転の再スタート
これらの問題はすべて、私たちをひとつの避けがたい結論へと導きました。それは、我々のアプローチを抜本的に変える必要があるということでした。この問題を検討した結果、フェッチ・アルゴリズムが機能する方法について多くの仮定があり、それが事態を難しくしていることに気づきました。
その前提のひとつは、フェッチアルゴリズムは、すでにバッファリングされているセグメントのリクエストを常に避けるべきだというものでした。
問題は、シーク、バッファのガベージコレクション（MSEが裏で自動的に行うもの）、ギャップが自然に発生するソースなどの影響を組み合わせると、バッファの状態を推論するのが非常に難しくなるということです。結局、我々のアルゴリズムはMSEの変化し続けるバッファに表裏一体で依存していることになります。
新しいフェッチャーは、可能な限り物事を単純化するために、このような仮定や他の多くの仮定を排除しています。例えば、プレーヤーはシークするたびにバッファをクリーンアップするようになり、バッファの状態を推論しやすくなり、バッファにすでに存在するセグメントをロードしないようにガードしようとしなくなりました。
実行
前提条件を再検討した結果、100％の確率で正確な推測をすることは不可能だが、100％の確率で保守的な推測をすることは十分に可能であることがわかりました。保守的な推測とは、目的のセグメントの前か、その前のセグメントを推測することです。保守的な推測をするということは、プレイリストのセグメントを前に進むだけで、常に正しいセグメントを見つけることができるということです。
この理解によって、問題の性質が大きく変わります。現在、私たちは最初の推測を行った後、常に連続した領域をフェッチしています。つまり、バッファの状態に関する詳細は、フェッチアルゴリズムの動作によるものではなく、定義上、メディアに内在するものであるため、もはや私たちには関係ありません。
残された唯一の疑問は、ライブ・プレイリストのバリアント間のセグメントと時間をどのように相関させるかということでした。そのために、「シンクポイント」という概念を導入しました。シンクポイントとは、セグメントインデックスとディスプレイタイムです（再生時間を表示するための player.currentTime().
新しいフェッチ・アルゴリズムには3つの動作モードがあります。
- どのセグメントからダウンロードを開始するかを控えめに推測する
- 単純にプレイリストを進む
- シンクポイントの作成を試みる
この最後の状態になるのは、フェッチャーが推測を行うために保存しておいた情報を使用できない場合のみです。めったにないことですが、そのような場合は、セグメントをダウンロードし、メディアの内部タイムスタンプを利用して "シンクポイント "を生成しなければなりません。
これらの変更の最終的な結果は、HLS再生体験の向上になります。特にライブ再生は、より素早く開始され、より確実に再生されるはずです。
