Home 技術記事 サーバー側からのビデオQoEの測定:再バッファリングの見積もり
Applications

サーバー側からのビデオQoEの測定:再バッファリングの見積もり

About The Author

Outline

ビデオ体験の質とリバッファ

ビデオストリーミングの初期段階で は、視聴者はイライラするような再生体験に耐えて、限定コンテンツにアクセスしようとしました。 コンテンツを複数のディストリビューター間で共有するコンテンツプロバイダーの数が増加するにつれて、視聴者の維持にQoE(Quality of Experience)が不可欠になってきています。

体験の質とは、動画ストリームを視聴しているユーザーの全体的な体験を指します。 Quality of Service(QoS)とは異なり、QoEは主観的な問題であるため、特定のレベルを測定または保証することは困難です。 QoEは、動画サービスがプラットフォームのパフォーマンスを明確にするために追跡する多くの主要業績評価指標(KPI)で構成されています。 これらの品質メトリックは、再バッファリングや広範なビットレート変動など、特定の懸念領域に分類できます。

様々な指標の中で、再バッファリングは視聴者にとって最も目立つ厄介な障害です。 その小さな回転する車輪は、視聴者の悪い体験の象徴です。 動画業界の調査では、視聴者が再バッファリングを経験したときにストリームを放棄することが一貫して示されています。 再バッファリングとQoEの低下の原因を特定することは困難です。 視聴者のインターネットサービスプロバイダー(ISP)、コンテンツ配信ネットワーク(CDN)、クライアントのブラウザ/プレーヤーアプリ、または元のパブリッシャーの動画インフラストラクチャ全体のソースから発生する可能性があります。

ISPやパブリッシャーの問題はほとんど私たちの手に負えませんが、CDNに起因するQoEの問題を特定して解決するための実用的なデータを取得できるようになりました。 これを行うために、Webサーバーログを使用してビデオQoEの問題を特定するための「Estimate Rebuffer」と呼ばれるアルゴリズムを開発しました。 このリアルタイム監視システムは、きめ細かなデータを使用してQoEの問題を特定し、ドリルダウンして根本原因と対応する解決策を理解します。 この記事では、このアルゴリズムがQoEの問題をどのように決定するか、およびそれを使用してQoEを改善する方法を見ていきます。

Estimate Rebuffer Algorithmの概要

QoEを追跡する1つの方法は、プレーヤーがQoEデータをCDNに送信することです。 このため、プレイヤーとクライアントはソフトウェア開発キット(SDK)を採用する必要があります。 また、再生デバイスの多様性を考えると、クライアント側のQoEメトリックを一貫して取得することはほぼ不可能です。 Estimate Rebufferアルゴリズムは、プレーヤー/クライアントの変更やSDKの採用の必要性を軽減します。 クライアント側からビーコンを介して送信される情報を必要としないため、推定値です。 ただし、データセンターと配信ネットワーク全体にわたる広範な機能を備えているため、クライアント側だけの場合と比較して、QoEの問題の根本原因をより明確に把握できます。

Estimate Rebufferツールは、プラットフォーム上のビデオサービスからのサーバー側クライアントアクセスログを使用して、QoEの問題を特定します。 QoEを評価するために、次の3つの情報を使用します。

  • クライアントがasset/video-stream-chunkを要求したときのタイムスタンプ
  • asset/video-stream-chunkのファイル名
  • セッションまたはクライアント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から新しいチャンク要求を行ったときにどれだけ視聴したかについても検討します。

このアルゴリズムは、Verizon Media (現Edgio )に限定されたものではありません 。 同様のファイル命名規則を使用する限り、Edgio配信ネットワーク上の他のビデオサービスに拡張できます。

応用

QoEデータが手元にあれば、特定の問題のデバッグやパフォーマンスの低いネットワークの特定など、いくつかの方法でQoEを改善できます。 QoEの問題を特定したら、その原因を簡単に掘り下げて理解できます。

QoEが低下している場合は、データセンターごとのQoEメトリックを調べて、どのデータセンターがQoEが低下しているかを特定できます。 データセンターを特定したら、ドリルダウンして原因となったネットワークを特定し、原因を特定し、修正を推奨します。 たとえば、次のライブビデオストリーム中に特定のネットワークを使用しないようにすることができます。そのネットワークが障害を起こしやすいことが示されている場合。 通常、再バッファリングの問題が発生した場合は、イベントが始まる前に手動でトラフィックを移動して、新しいトラフィックのためのスペースを確保します。 推定された再バッファアルゴリズムのデータに基づいて、トラフィック管理チームはゲームが容量の問題をプリエンプトし始める前にトラフィックを移動するためのゲーム前のバッファを作成できます。

また、システムはリアルタイムで機能するため、ライブストリーミングビデオ中に積極的に修正措置を講じることができます 。 これには、たとえば、QoEが低下しているデータセンターから、より健全なデータセンターにトラフィックを移動させることが必要になる場合があります。 リアルタイムのエラー検出と解決は、再バッファリングやその他の問題が発生しているクライアントの数を減らすための非常に効果的なツールです。

恐ろしい回転ホイールを排除することは不可能かもしれませんが、Estimate Rebufferアルゴリズムのようなサーバー側の分析ツールは、外観の頻度を大幅に減らすために大いに役立ちます。