Top Trends in Cybersecurity for 2024 | 
ビデオのエクスペリエンス品質とリバッファ
ビデオストリーミングの初期には、視聴者は排他的なコンテンツにアクセスするためにイライラする再生体験に耐えて喜んでいた。 コンテンツを複数の配信者間で共有するコンテンツプロバイダーの数が増加するにつれて、視聴者の定着にはQuality of Experience(QoE)が不可欠になっている。
体験の質(Quality of Experience)とは、ユーザーが動画ストリームを見ているときの全体的な体験を指す。 サービス品質(QoS)とは異なり、QoEはより主観的な問題であり、一定のレベルを測定したり保証したりすることは困難である。 QoEは、ビデオサービスが追跡してプラットフォームのパフォーマンスを明確にする多くの主要業績評価指標（KPI）で構成されている。 これらの品質メトリックは、再バッファリングや広範なビットレート変動など、特定の関心領域に分解することができる。
さまざまな指標の中で、再バッファリングは視聴者の最も顕著で迷惑な障害である。 その小さな回転する車輪は悪い視聴者経験の象徴である。 動画業界の調査では、視聴者がリバッファリングを経験したときにストリームを放棄することが一貫して示されている。 再バッファリングとQoEの低下の原因を特定するのは難しい。 視聴者のインターネットサービスプロバイダー(ISP)、コンテンツ配信ネットワーク(CDN)、クライアントのブラウザ/プレーヤーアプリ、または元のパブリッシャーのビデオインフラストラクチャ全体のソースから発生する可能性がある。
ISPやパブリッシャーの問題はほとんど制御できないが、CDNに起因するQoEの問題を特定して解決することを可能にする実用的なデータをキャプチャできるようになった。 これを行うために、Webサーバーログを使用してビデオQoEの問題を特定するための「Estimate Rebuffer」と呼ばれるアルゴリズムを開発した。 このリアルタイム監視システムは、きめ細かなデータを使用してQoEの問題を特定し、ドリルダウンして根本原因と対応する解決アクションを理解する。 この記事では、このアルゴリズムがQoE問題をどのように決定するか、そしてQoEを改善するためにそれをどのように使用できるかを見ていく。
見積もり再バッファアルゴリズムの概要
QoEを追跡する1つの方法は、プレーヤーがQoEデータをCDNに送信することである。 そのためには、プレイヤーとクライアントはソフトウェア開発キット(SDK)を採用する必要がある。 また、再生デバイスの多様性を考えると、クライアントサイドのQoEメトリックを一貫して捉えることはほぼ不可能である。 Estimate Rebufferアルゴリズムは、プレイヤー/クライアントの変更やSDKの採用の必要性を軽減する。 クライアント側からビーコンを介して送信される情報を必要としないため、推定値である。 しかし、データセンターと配信ネットワーク全体に及ぶ広範さを考慮すると、QoEの問題の根本原因について、クライアント側だけに比べてはるかに鋭い洞察を提供する。
Estimate Rebufferツールは、プラットフォーム上のビデオサービスからサーバー側のクライアントアクセスログを使用してQoEの問題を特定する。 QoEを評価するために、
- クライアントがasset/video-stream-chunkを要求したときのタイムスタンプ
- アセット/video-stream-chunkのファイル名。
- セッションIDまたはクライアントID。
この情報から、サードパーティのツールを必要とせずに、Estimate Rebufferアルゴリズムは、QoEに影響を与える次のような主要要素を決定できる。
- 再バッファリング：アルゴリズムは、クライアントが認識した再バッファリングの数、再バッファリングイベントの期間、およびビデオストリームの視聴に費やした時間に対する再バッファリングの比率を詳細に説明する。
- 平均ビットレート—ビデオ品質はビデオビットレートの関数。 平均ビットレートが高いほど、より良いビデオ品質、より鮮明で鮮明な画像、より豊かな色、より良い体験を意味する。
- 変動率—視聴者はビットレートの変動に否定的に反応し、一定のビットレートを好む傾向がある。 このメトリックは、ビデオストリームが品質を変更する回数を決定する。
- 品質分布—これにより、特定のクライアントにどの程度の品質で提供されたかを判断できる。 例えば、80%は高品質で、10%は中程度、10%は低品質で提供された。
仕組み
Estimate Rebufferアルゴリズムは、たった2つの情報でQoEの有用な評価をどのように提供できるか? 見てみよう。
アダプティブビットレート(ABR)ビデオストリームは、多数の個別のビデオチャンクまたはアセットから構成される。 各チャンクは固定サイズで、通常は4秒である。 例えば、40秒のABRビデオストリームは10チャンク（40/4 = 10チャンク）を持つ。
各チャンクには、例えばA1.ts、A2.ts、A3.ts…A10.tsなどのように順番に名前が付けられる。 最初の文字は品質タイプである。 例えば、Aは最低、BはAより高い、CはBより高い……というようになる。 この知識をもとに、各クライアントからのリクエストを見て、順番にチェックする。 例えば、A1.ts, B2.ts, A3.tsのように品質が変化した場合、それを変動率指標に加える。
クライアントがいつチャンクを要求したか、各チャンクの長さ(4秒)がわかっているので、要求されたすべてのチャンクの時間/継続時間をすべて加算することができる。 その間にギャップがある場合、プレイヤーが過去に要求したチャンク数(バッファ内のビデオ)よりも長いリクエストギャップを再バッファとしてカウントする。 また、バッファされたビデオクライアントがCDNから新しいチャンク要求を行ったときにどれだけ視聴したかを検討する。
このアルゴリズムはベライゾン・メディア（現在はEdgio）に排他的ではない。 同様のファイル命名規則を使用する限り、Edgio配信ネットワーク上の他のビデオサービスにも拡張できる。
応用
QoEデータを活用することで、特定の問題のデバッグや低パフォーマンスのネットワークの特定など、QoEを改善することができる。 QoEの問題を特定すれば、その原因をより深く掘り下げて理解することができる。
QoEが低い場合は、データセンターごとのQoEメトリックを見て、どのデータセンターがQoEが低いかを特定できる。 データセンターを特定したら、ドリルダウンして原因となったネットワークを特定し、原因を特定し、修正を推奨する。 例えば、次のライブビデオストリーム中に特定のネットワークが故障しやすいことが示された場合、そのネットワークを使用しないようにすることができる。 通常、再バッファリングの問題が発生した場合、イベントが新しいトラフィックのためのスペースを作り始める前に、手動でトラフィックを移動する。 推定された再バッファアルゴリズムのデータに基づいて、私たちのトラフィック管理チームは、ゲームが容量の問題を先取りする前にトラフィックを移動するために、ゲーム前のバッファを作成することができる。
また、リアルタイムで動作するため、ライブストリーミング動画では積極的に是正措置を講じることができる。 たとえば、QoEが低いデータセンターからより健全なデータセンターにトラフィックを移動させることが必要になる。 リアルタイムのエラー検出と解決は、再バッファリングやその他の問題が発生しているクライアントの数を減らすための非常に効果的なツールである。
恐ろしい回転ホイールを排除することは不可能かもしれないが、Estimate Rebufferアルゴリズムのようなサーバーサイド分析ツールは、外観をはるかに少なくするために長い道のりを歩んでいる。
