QoE(エクスペリエンスの質)こそ QoS の要

QoE(エクスペリエンスの質)こそ QoS の要

新製品やサービスによって、家庭や職場での日常的な作業が瞬時に向上することがよくあります。Dropbox – すぐに役立つ。Square – お店にとっては便利だが、エンド ユーザにとってはあまり魅力的ではない。Uber – 素晴らしい。Uberでは携帯電話から専用車両サービスの予約、追跡、支払いが簡単にできます。と言ってもすぐにはメリットが思い浮かばないかもしれませんが、たとえば以下が挙げられます。

  • クレジットカードへの自動課金と電子レシートの発行 - クレジットカード リーダーが壊れていて使えないというトラブルがない(サンフランシスコ)
  • 車の予約と到着予定時間の追跡 – 道端でタクシーを拾うために待たなくて済む(ニューヨーク)
  • 車が清潔でドライバーがプロフェッショナルだという確信 – 不機嫌なドライバーが運転する、嫌な臭いのする車に乗らなくて済む(あらゆる場所)

スピード、距離、全体的な料金といったきめ細かいサービス品質は従来の手段(タクシー サービスなど)と変わりがないかもしれませんが、Uber のエクスペリエンスが素晴らしいため、リピーターとして愛用しています。

同じことが動画 QoS(サービス品質)にも言えます。つまり、サービスこそがエクスペリエンスなのです。動画 QoSは、過去 1 年の間にパブリッシャとの間でよく話題に上ったトピックの 1 つです。パブリッシャは、ライブ ストリーミングやオンデマンド動画について、以下のような各種のメトリクス(指標)を把握したいと考えています。

  • プレーヤのロード/起動時間
  • 平均的なバッファリング時間とバッファリングが視聴エクスペリエンスに及ぼす影響
  • 平均的な帯域幅と再生ビットレート
  • 動画の起動失敗回数

いくつかの専門的な企業では、パブリッシャがこの種のデータを収集して動画配信と再生パフォーマンスの把握を行えるようにしています。結果として CDN 機能を中心とした分析が行われています。

パブリッシャにとってこのような動画利用状況の最適化は重要ですが、QoS を動画エクスペリエンスの品質(動画 QoE)として定義し直す必要があります。視聴エクスペリエンスの測定と監視では、多くのパブリッシャの目的、つまりユーザあたりの視聴回数の増加、全体的な視聴時間の増加、広告インベントリ(これを必要としているパブリッシャは多い)などに重点を置く必要があります。

再生パフォーマンス
パブリッシャは通常、レンダリング オプションの詳細をユーザからは見えないようにしています(あるいは、たとえば HTTP ライブ ストリーミング用の Apple ネイティブ動画プレーヤなど、下層の動画プレーヤにレンダリング オプションの選択を行わせています)。最近発表されたいくつかのレポートによると、動画再生パフォーマンスの最適化のためには 2.5Mbps 以上の動画レンダリング速度を提供しなければならないことがわかりました。

ただしこれ以外にも、考慮しなければならない以下のような要因があります。

  • 既知の制限(対象となる視聴者に帯域幅制限が課せられている、など)を基に、ユーザ自身がレンダリング オプションを直接制御できるようにしているパブリッシャもあります。その結果、低速でのレンダリングは必要性から生じたものではなく、好みの問題という場合があります。
  • ますますモバイル化が進んでいます。パブリッシャは空港、電車、カフェ、公共の場所、ホテル、関連するエリアでの Wi-Fi の普及度を考慮する必要があります。帯域幅は無料で(または比較的安価に)利用できますが、帯域幅と待機時間(特にモバイル 3G の場合)が一致していない場合が多いのです。

帯域幅が十分あり、待機時間も短く、十分な処理能力を備えたデバイスを使用しているユーザ向けに最適化するのは簡単なのですが、決して理想的とは言えない状況でのモバイル エクスペリエンス用に最適化する必要があります。

ユーザによるコンテンツ利用状況を把握するために、パブリッシャはコンテキスト情報の収集を重視する必要があります。特に、帯域幅(平均的な帯域幅、長期的な帯域幅の変化など)とローカル パフォーマンス(ドロップ フレーム数、平均的なフレームレート、長期的なフレームレートの変化など)の把握が重要です。パブリッシャはエンコーディング済みのレンダリングを分析して、異なるビットレート レベルで最適なアダプティブ再生エクスペリエンスが提供できていることを確認するだけでなく、ユーザ自身がレンダリング品質を基に低速再生を選べるようにすることで、一貫した再生と、頻繁なバッファリングによる中断を伴う高速再生のいずれかを選択できるようにする必要もあります。

リプレイ
DVR が一般的になり始めた頃に、初めて REPLAY ボタンというものを目にしました。主として CM をスキップするための調整に使用していました。動画プレーヤの REPLAY ボタンはこのような昔ながらの機能の延長だと思っていましたが、以下のような別な用法を何度か見かけて考え方が変わりました(録画済みの放送用コンテンツでも一般的な用法でした)。

  • スノーボードでの高度なナックル グラインド成功や、クローバーフィールド/HAKAISHA ラストシーンでのコニー アイランドの「水しぶき」映像といった「すごい」瞬間の巻き戻し再生。
  • バッファリングによる中断後の巻き戻し再生。
  • 音質/バランスの不良(デジタルまたはテレビ放送用のリミックスがうまくいっていない映画によく見られる現象)時の巻き戻し再生。
  • ユーザ側の制約(ラップトップ スピーカの使用、雑音の多い環境、マルチタスキングによって集中できない状態での視聴など)がある場合の巻き戻し再生。

パブリッシャはユーザによる再生イベント(REPLAY ボタンの使用による明示的な巻き戻し再生、またはスクラブバーを使用した黙示的な巻き戻し再生の両方)を追跡し、プレーヤまたはコンテンツの体系的な問題に対して、ユーザの反応がポジティブ、ネガティブのいずれなのかを理解する必要があります。

広告
プレーヤに QoS 測定機能を持たせている場合は、広告コンテンツではなく、動画コンテンツに限定してデータ収集を行います。動画コンテンツは本来それを見る人を想定して作られますが、コンテンツの「エクスペリエンス」は広告エクスペリエンスと密接に結び付いています。品質が低い場合、特に再生自体に問題があると、動画エクスペリエンスに直接影響を及ぼします。

  • 使用可能なレンダリング オプションとビットレート、フォーマット、プロトコルに基づき、広告データをあらゆるプラットフォーム(デスクトップ、モバイル、Web、ネイティブ アプリ)での配信用に最適化する必要がある。
  • 広告リクエスト(そしてその下にあるアセットのリクエスト)の待機時間や障害(動画再生が途中でストップすることもある)を分析する必要がある。

CDN パフォーマンスと自己回復機能
再生バッファリングの体系的問題や障害が発生した場合に、パブリッシャが最初に疑うことが多いのが CDN です。この種の問題を分析する際には、コンテキスト上の要因や物理的なアセット(レンダリングのフォーマット、エンコーディング プロファイルなど)についても確認する必要があります。

  • 地域的な CDN 戦略が、グローバルな CDN 戦略と一致しているか(特定の地域への配信を最適化するために、その地域のプロバイダを選択するなど)。
  • 採用している動画プラットフォーム戦略には、「自己回復」機能があるか、つまり問題を自動的に検出し、対応することができるか(検出した体系的な再生機能の低下や障害に基づき、プロトコル、フォーマット、CDN の切り替えができるのか)。

What's Next - 続きの連想
ブロードキャスト シンジケーションでは、映画のクレジットが通常のスピードやサイズで流れることはほとんどありません。映画館で観るのとは異なり、放送用バージョンはコンテンツ、CM、そして最もよくあるのが全体的な長さ(その番組が事前に割り当てられた時間帯の枠内に収まるようにするため)の点で編集されることが多いのです。また、番組の続きを連想させるような「what’s next」編集もよく行われます。クレジットやエンドロールのあるコンテンツの場合、動画が終わりに近付くとユーザが無意識に視聴を途中で終了していないかどうかを確認する必要があります。ページ上またはプレーヤ内に事前に何らかの要素を表示することによって、次の動画への誘導効果がどの程度上がるのかを調査します。

QoS の測定は終わりのない作業なのです。QoS(サービス品質)を QoE(エクスペリエンス品質)として定義することで、収集した膨大なデータ量に困惑することなく、優れた動画エクスペリエンス メカニズムを提供できるはずです。そうすることで、視聴者にもっとたくさんの動画を簡単に楽しんでもらえるようになります。