(57)【要約】  本発明は、ネットワーク経由でチャネルを介してサーバからクライアントにビデオコンテンツをストリーミングする方法に関する。ビデオコンテンツは連続フラグメントのセットとして提供され、前記連続フラグメントのセットの各フラグメントは、それぞれの符号化済みデータレートに対応する複数の品質レベルで提供される。本方法は、フラグメントを求める１つまたは複数の要求を送信すること、および、要求に対する、ターゲット品質レベルを有するフラグメントを含む１つまたは複数の返信を、前記クライアントにおいてネットワーク経由で受信すること、のセッションを含む。これらのフラグメントは、前記クライアントにおいて表示される。捕捉ノードにおいて、セッションの要求および／または要求に対する返信が捕捉される。捕捉されたデータを使用して、クライアントにおいて体験される前記セッションの少なくとも一部（ＱｏＥ）が再構築される。
2014519259.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク経由でチャネルを介してサーバからクライアントにビデオコンテンツをストリーミングする方法であって、前記サーバが前記ビデオコンテンツを連続フラグメントのセットとして提供し、前記連続フラグメントのセットの各フラグメントが、それぞれの符号化済みデータレートに対応する複数の品質レベルで提供され、前記方法が、少なくとも、
前記クライアントにおいて表示されることになる前記ビデオコンテンツの、ターゲット品質レベルを有するフラグメントを求める１つまたは複数の要求を、ネットワーク経由で前記クライアントから前記サーバに送信すること、および、
要求に対する、ターゲット品質レベルを有するフラグメントを含む１つまたは複数の返信を、前記クライアントにおいてネットワーク経由で受信すること、のセッションを含み、
１つまたは複数のフラグメントが前記クライアントにおいて表示され、
ネットワーク中で、セッションの要求および／または要求に対する返信を捕捉すること、ならびに、クライアントにおいて体験されるセッションの少なくとも一部を再構築することをさらに含む、方法。
【請求項２】
クライアントにおいて体験されるセッションの少なくとも一部を再構築することが、クライアントにおけるバッファ充填および／またはピクチャフリーズを再構築することを含む、請求項１に記載の方法。
【請求項３】
クライアントにおいて体験されるセッションの少なくとも一部を再構築することが、クライアントによって選択された品質レベル、および品質変化を再構築することを含む、請求項１または２に記載の方法。
【請求項４】
クライアントにおいて体験されるセッションの少なくとも一部を再構築することが、クライアントにおけるユーザ対話を再構築することを含む、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記要求の前記送信が、ＨＴＴＰ要求データグラムを送ることを含む、請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記要求が、捕捉時間とフラグメント品質レベルとを少なくとも含むＨＴＴＰ−ＧＥＴである、請求項５に記載の方法。
【請求項７】
前記ターゲット品質レベルが、少なくとも１つのユニフォームリソース識別子によって示される、請求項５または６に記載の方法。
【請求項８】
クライアントにおいて体験されるセッションの少なくとも一部を再構築することが、再構築されるセッションの少なくとも１つのパラメータを補外することを含む、請求項１から７のいずれか一項に記載の方法。
【請求項９】
ネットワークを介して再構築済みセッションを送信することをさらに含む、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
ノードを経由してサーバからクライアントにビデオコンテンツを連続フラグメントのセットとしてセッション中でストリーミングするための、ネットワーク中のノードであって、前記連続フラグメントのセットの各フラグメントが複数の品質レベルで提供され、セッションが、クライアントからサーバに送られる、ターゲット品質レベルを有するフラグメントを求める要求と、要求に応じた、ターゲット品質レベルを有する１つまたは複数のフラグメントを含む返信とを含み、前記ノードが、
前記セッションの少なくとも一部を捕捉するための少なくとも捕捉デバイスと、
クライアントにおいて体験される前記セッションの一部（ＱｏＥ）を再構築するための少なくとも再構築デバイスとを備える、ノード。
【請求項１１】
再構築デバイスが、クライアントにおけるユーザ対話を再構築するように構成された、請求項１０に記載のノード。
【請求項１２】
再構築デバイスが、セッション中のクライアントにおけるバッファ充填およびピクチャフリーズを再構築するように構成された、請求項１０または１１に記載のノード。
【請求項１３】
ネットワークを介して再構築済みセッションを送信するための送信デバイスをさらに備える、請求項１０から１２のいずれか一項に記載のノード。
【請求項１４】
クライアントからの要求に応じてビデオコンテンツを連続フラグメントのセットとしてサーバからセッション中でストリーミングするためのネットワークであって、前記連続フラグメントのセットの各フラグメントが、それぞれの符号化済みデータレートに対応する複数の品質レベルでチャネルを介して提供され、請求項１０から１３のいずれか一項に記載のノードを含む、ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク化されたビデオストリーミングサービスの分野に関し、特に、ＨＴＴＰアダプティブストリーミング（ＨＡＳ）など、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）を介して提供されるビデオストリーミングサービスに関する。
【背景技術】
【０００２】
典型的な一実装形態では、インターネットベースのビデオストリーミングサービスが、ＨＴＴＰプロトコルを介して提供される。トランスポートネットワークとしてのインターネットのサービス品質は実質上「ベストエフォート」なので、ストリーミングされるコンテンツについて異なるビデオ品質レベル間で動的に切り替えることによって、任意の所与の時点でサーバとクライアントとの間で利用可能な帯域幅を最大限に利用するプロトコルが考案された。ＨＴＴＰアダプティブストリーミングは一例である。
【０００３】
したがって、利用可能な帯域幅が例えばネットワークトラフィック全体のレベル低下のせいで高いときは、比較的高品質で符号化されたビデオをストリーミングして、高データレートおよび／もしくは解像度で、ならびに／または高フレームレートでグラフィックスを表現することが有利である。同様に、利用可能な帯域幅が例えばネットワークトラフィック全体のレベル上昇のせいで低いときは、比較的低データレートで符号化されたビデオをストリーミングして、低解像度および／または低フレームレートでグラフィックスを表現することが有利である。
【０００４】
ＨＴＴＰアダプティブストリーミング（ＨＡＳ）は、新たに出現してきたビデオ送達技法である。ＨＡＳは、Ｍｉｃｒｏｓｏｆｔ（スムーズストリーミング）やＡｐｐｌｅ（ライブストリーミング）などの業界リーダによってサポートされている。ＨＡＳの利点の１つは、ＨＴＴＰウェブコンテンツのための既存のインフラストラクチャ（ＨＴＴＰサーバおよびプロキシ、ＣＤＮなどを含む）を、ビデオ配信のために再利用できることにある。
【０００５】
新規な向上したビデオ送達ソリューションとしてＨＡＳがますます普及しているにもかかわらず、現在、プロバイダ（コンテンツプロバイダ、ＩＳＰ、ＣＤＮプロバイダ）が消費者への送達品質を追跡することは不可能である。
【発明の概要】
【課題を解決するための手段】
【０００６】
本発明の一態様によれば、ネットワーク経由でチャネルを介してサーバからクライアントにビデオコンテンツをストリーミングする方法が提供される。本方法は、サーバが前記ビデオコンテンツを連続フラグメントのセットとして提供することを含み、前記連続フラグメントのセットの各フラグメントは、それぞれの符号化済みデータレートに対応する複数の品質レベルで提供される。クライアントは、連続フラグメントが種々の品質レベルを有する場合でも、フラグメントを受信し表示することができる。フラグメントは、本方法の間にセッションの一部として要求され受信される。本方法によるセッションは、前記クライアントにおいて表示されることになる前記ビデオコンテンツの、ターゲット品質レベルを有するフラグメントを求める１つまたは複数の要求を送信することを含む。要求は、ネットワークを介して前記クライアントから前記サーバに送られる。さらに、本方法は、要求に対する１つまたは複数の返信を前記クライアントにおいてネットワークを介して受信することを含む。返信は、ターゲット品質レベルを有する要求されたフラグメントを含んでよい。さらに、１つまたは複数の受信されたフラグメントは、前記クライアントにおいて表示される。本方法の一実施形態は、ＨＴＴＰアダプティブストリーミングである。
【０００７】
一実施形態によれば、本方法はさらに、ネットワーク中で、セッションの要求および／または要求に対する返信を捕捉することを含む。本方法はさらに、セッションの少なくとも一部を再構築することを含む。これにより、クライアントにおいて体験されるセッションに関するパラメータを得ることができる。再構築されるセッションに関係するパラメータは、サービス品質、体験品質に関係してよい。セッションの再構築は、セッション変数／パラメータのみに関係してよく、実際のコンテンツにはあまり関係しなくてよい。
【０００８】
したがって、セッションパラメータが再構築され、セッションパラメータを使用して、サービスを向上させることまたはサービスの結果を監視することができる。
【０００９】
本発明の一実施形態では、クライアントにおいて経験されるセッションの少なくとも一部を再構築することは、選択されたフラグメント品質、クライアントにおけるバッファ充填、およびユーザ対話（例えば一時停止／再開、ビデオカーソル再配置など）を再構築することを含んでよい。これらのパラメータは、セッション中の実際のビデオ再生および表示に関係する。
【００１０】
例として、クライアントにおけるユーザ対話の再構築について述べる。クライアントによって送られる要求は、ユーザによるクライアントとの対話を示す指示を含まないが、クライアントの要求および挙動から、クライアントとのユーザ対話（例えば一時停止）を演繹してそれにより再構築することが可能である。可能性のある一時停止イベントの後で、クライアントが、クライアントバッファが完全に充填されている場合のクライアントの定常状態条件に典型的に見られる要求／返信パターンを示す場合は、ユーザが再生を一時停止したと演繹することができる。
【００１１】
本発明の特徴は、再構築されたセッションが利用可能になれば、再構築されたセッションから可能性のある（ＨＡＳ）アーチファクトを計算することを可能にする。アーチファクトのリストは、ピクチャフリーズ、品質低下、品質変化、および対話性遅延を含み、これらについては後でより詳細に説明する。これらのアーチファクトにより、ユーザ体験を定量化することができる。これらのアーチファクトはどれも、本発明による再構築の一部とすることができる。
【００１２】
要求は、物理的に、クライアントにおいて、またはサーバにおいて、またはクライアントとサーバとの間の任意の中間ポイントにおいて捕捉することができる。
【００１３】
一実施形態では、本発明の方法はさらに、利用可能なチャネルデータレートを前記クライアントにおいて測定することを含み、利用可能なチャネルデータレートに応じてターゲット品質レベルがさらに選択される。一実施形態では、フラグメントを送信するための転送時間が考慮される。一実施形態では、バッファ充填は、ターゲット品質を選択するためのパラメータである。
【００１４】
本発明の方法の一実施形態では、要求の送信は、ＨＴＴＰ要求データグラムを送ることを含む。特定の一実施形態では、ターゲット品質レベルは、少なくとも１つのユニフォームリソース識別子によって示される。特定の一実施形態では、ターゲット品質レベルは、パラメータによって示される。一実施形態では、要求は、捕捉時間とフラグメント品質レベルとを少なくとも含むＨＴＴＰ−ＧＥＴである。
【００１５】
一実施形態では、クライアントにおいて経験されるセッションの少なくとも一部を再構築することは、再構築されるセッションの少なくとも１つのパラメータを補外することを含む。全ての要求および返信が本方法の一部として捕捉されることが好ましいが、キャッシュ、特にローカルキャッシュされる結果として、要求および返信が捕捉ポイント／ノードを受信しない可能性がある。欠損のセッション情報は、途切れの前と後からの最新の受信セッション情報間で補間を行うことによって再構築される。
【００１６】
一実施形態では、本方法は、ネットワークを介して再構築済みセッションを送信することを含む。再構築済みセッションをプロバイダ（コンテンツプロバイダ、ＩＳＰ、ＣＤＮプロバイダ）に提供して、消費者への送達品質を追跡することができる。
【００１７】
本発明の一態様によれば、ノードを経由してサーバからクライアントにビデオコンテンツを連続フラグメントのセットとしてセッション中でストリーミングするための、ネットワーク中のノードが提供される。セッションは、クライアントにおいて表示されることになる。クライアントは、連続フラグメントを見ることになる。前記連続フラグメントのセットの各フラグメントは、複数の品質レベルで提供される。セッションは、種々の品質レベルの連続フラグメントを含んでよい。セッション中、ターゲット品質レベルを有するフラグメントを求める要求が、クライアントからサーバに送られ、要求に応じて、ターゲット品質レベルを有する１つまたは複数のフラグメントを含む返信がクライアントに送られる。
【００１８】
一実施形態では、前記ノードは、前記セッションの少なくとも一部を捕捉するための少なくとも捕捉デバイスと、クライアントにおいて体験される前記セッションの一部（ＱｏＥ）を再構築するための少なくとも再構築デバイスとを備える。ノードにおいてセッションの一部を捕捉することにより、クライアントにおいてプレーヤを適応させることなくセッションの品質に関する詳細が利用可能になる。本発明の洞察は、捕捉されたセッション部分を使用して、ユーザにおけるセッション体験を再構築することである。生の要求および返信データは、クライアントにおけるセッションのサービス／体験の品質を示すものではなく、またクライアントにおける体験を示すものでもない。しかし、再構築を用いて、ノードにおいて捕捉されたセッションデータを使用してクライアントにおけるセッションを再建することができる。
【００１９】
要求自体の内容に加えて、要求／返信のタイミングが、追加の変数として考慮される。
【００２０】
本発明の一実施形態では、再構築デバイスは、クライアントにおけるユーザ対話を再構築するように構成される。要求および／または返信、ならびに内容（例えば要求されるフラグメント品質レベル）を解析することにより、クライアントにおけるプレイアウトの一時停止を、要求されるフラグメントから演繹することが可能である。
【００２１】
一実施形態では、再構築デバイスは、セッション中のクライアントにおけるバッファ充填およびピクチャフリーズを再構築するように構成される。バッファ充填およびピクチャフリーズは、それぞれ、重要なセッション品質およびセッションアーチファクトである。バッファ充填の再構築は、要求および返信の内容、ならびに要求および返信のタイミングを考慮することによって得られる。プレーヤ特性など、さらに他のクライアントプロパティを考慮することもできる。
【００２２】
他のセッション品質およびアーチファクトを再構築することもできる。
【００２３】
ノードはさらに、ネットワークを介して再構築済みセッションを送信するための送信デバイスを備えてよい。これにより、収集された情報を利用可能にすることができる。
【００２４】
さらに別の態様によれば、クライアントからの要求に応じてビデオコンテンツを連続フラグメントのセットとしてサーバからセッション中でストリーミングするためのネットワークが提供される。前記連続フラグメントのセットの各フラグメントは、それぞれの符号化済みデータレートに対応する複数の品質レベルでチャネルを介して提供される。ネットワークは、本明細書に述べる実施形態のいずれかによるノードを含む。
【００２５】
「クライアントによって体験されるセッション」は、受信されたセッションデータの知覚に関係する少なくとも何らかのサービス品質パラメータを含む。
【００２６】
「ユーザ対話」は、本明細書では、通常速度再生の他の、ストリーミングされるビデオコンテンツの任意の形のレンダリングとして定義される。
【００２７】
次に、本発明の実施形態による装置および／または方法のいくつかの実施形態について、添付の図面を参照しながら単なる例示として述べる。
【図面の簡単な説明】
【００２８】
【図１】本発明の方法の一実施形態のフローチャートである。
【図２】本発明のネットワークの概略図である。
【図３】本発明の一実施形態の概略図である。
【図４】本発明による方法を使用したセッションパラメータの再構築を示す図である。
【図５】本発明による方法を使用したセッションパラメータの再構築を示す図である。
【発明を実施するための形態】
【００２９】
後続の記述ではクライアントとサーバとの間の対話が仮定されるが、このクライアントおよびサーバは、異なる役割でネットワークプロトコルに参加するホストに関する通常の方式で定義される。
【００３０】
当業者なら理解するであろうが、「クライアント」２００に帰せられるアクションは、サーバと対話するように構成されたハードウェアおよび／またはソフトウェアの任意の組合せによって実施されてよく、このようなアクションは、クライアント機器の人間のオペレータによって明示的に開始される場合とそうでない場合がある。
【００３１】
同様に、「サーバ」２７０に帰せられるアクションは、サーバと対話するように構成されたハードウェアおよび／またはソフトウェアの任意の組合せによって実施されてよく、特に、コンテンツ配信ネットワーク（ＣＤＮ）２６１に含まれるかまたはストレージエリアネットワーク（ＳＡＮ）に含まれるかまたはＨＴＴＰプロキシの一実装形態に含まれるサーバ機器によって実施されてよい。
【００３２】
ビデオ符号化レート間の動的な切替えを可能にするために、ビデオサーバ２７０は、ストリーミングされるコンテンツの異なる時間フラグメントにつき、別々のビデオファイル（例えば、ＭＰ４などのファイルフォーマットに従ってファイルとして符号化されたビデオクリップまたはチャンク）を生成し、各ビデオファイルは、様々な品質で、すなわち種々のデータレートで符号化されて、クライアントに提供される。
【００３３】
一実施形態では、クライアント２００は、サーバ２７０、２６１からクライアント２００へのダウンストリームリンクの利用可能帯域幅を時々または継続的に評価し、この評価に従って、次に必要とされるビデオフラグメントの適切なバージョンを要求する（１３０）。ある方式によれば、クライアントは、現在測定されているダウンストリームデータレートよりも劣る最高データレートで符号化されたバージョンを要求する（１３０）。別の方式によれば、クライアントは、チャネル帯域幅変動に関する統計情報を考慮して、最も適切な符号化レートを決定する。
【００３４】
上記の方式に従ってクライアントによって選択されることになる種々のフラグメントへは、専用のユニフォームリソース識別子（ＵＲＩ）を用いてアドレスすることができる。このようにすれば、クライアントは単に、新しいフラグメントごとに適切なＵＲＩを選択すれば済む。利用可能なバージョンおよびそれらのＵＲＩは、関連するメタデータと共に、サーバによって再生リストまたは「マニフェスト」ファイルに記録される。
【００３５】
ＣＤＮキャッシュ２６１は、チャンクのキャッシングおよび配信を提供し、したがってオリジンＨＴＴＰサーバをオフロードする。アダプティブストリーミングは、このＣＤＮキャッシュ２６１と組み合わされて、ベストエフォートインターネットを介してスケーラブルな方式で円滑なビデオレンダリング体験を可能にする。
【００３６】
本発明の実施形態の１つは、ＨＴＴＰアダプティブストリーミング（ＨＡＳ）を使用する。ＨＡＳでは、コンテンツは、いくつかのビットレートで符号化され、一般に数秒である断片にフラグメント化される。プレイアウトに関係する種々のフラグメントと、利用可能な品質レベルとを記述する情報が、いわゆるマニフェストファイルに含まれる。このマニフェストファイルは、ＨＡＳサーバ／プロキシにおいて利用可能である。フラグメントのプレイアウトおよびダウンロードが開始する前に、マニフェストファイルがクライアントによって取り出される。
【００３７】
ピクチャフリーズを回避するために、クライアントソフトウェアは、ライブ（に近い）ＨＡＳストリーミングのための７秒から、オンデマンドビデオ送達のための３０秒超までの範囲にわたる可能性のあるプレイアウトバッファを適用することになる。実際のバッファ充填、および要求されたフラグメントの測定された転送時間など、いくつかの基準に基づいて、クライアントソフトウェアは、ダウンロードしなければならない次のフラグメントの品質レベルを決定することになる。
【００３８】
既存のＱｏＥ監視手法では、捕捉ファイルまたはリアルタイムの捕捉された情報を使用して、一般的なネットワーク欠陥（遅延、損失、ジッタ、パケットバーストなど）が検出される。これらの観察された欠陥に基づいて、ユーザによって知覚されることになる視覚的アーチファクト（ピクチャブロック、フリーズ、非同期、ディテール消失など）に関する予測が行われる。これらのアーチファクトに応じて、セッション全体の品質スコアを定義することができる。ストリーム中のビデオ圧縮のせいで、この方法は、非常に複雑でありエラーを被りやすくなることがわかる。というのは、パケット損失の影響は、例えばフレームタイプ（Ｉ／Ｐ／Ｂ）、場面中の動きの量、圧縮で使用される動きベクトルに、大きく依存するからである。
【００３９】
本発明の実施形態の一目的は、従来技術の方法を単純にすることである。
【００４０】
本発明は、選択されたフラグメント品質、（ＨＡＳ）クライアントにおけるバッファ充填、およびユーザ対話（例えば一時停止／再開、ビデオカーソル再配置など）を含めた、（ＨＡＳ）セッション全体を、捕捉ファイル（またはリアルタイム捕捉）を使用して再構築するという洞察に、少なくとも部分的に基づく。
【００４１】
（ＨＡＳ）セッション再構築の技法は、いくつかの新しい可能性をもたらす。ＩＳＰ、ＣＤＮプロバイダ、およびコンテンツプロバイダは、各（ＨＡＳ）送達の品質に対して、明確で客観的な見解を有することができる。不良の（ＨＡＳ）送達を早期に検出することで、顧客離れを回避することができる。集約されたＨＡＳ測定値により、プロバイダは、ネットワークのＨＡＳ送達能力を監視し、ベンチマーキングし、トラブルシューティングすることができることになる。高度な一実施形態では、本発明による方法およびノードを使用して、ピクチャフリーズの量および消費者への対話性遅延をかなり低減することができ、平均ＱｏＥ体験を向上させることができる。
【００４２】
本発明の実施形態では、本発明の洞察が、知られているビデオストリーミング技法と組み合わせられる。
【００４３】
次に、図１を参照しながら、本発明の方法の一実施形態についてより詳細に述べる。ステップ１１０で、いくつかのローカルおよび／またはネットワークパラメータを評価することができる。これは、継続的に実施されてもよく、または断続的に、例えばフラグメントを求める要求ごとに要求前に１度、実施されてもよい。ネットワークパラメータは、利用可能な帯域幅であってよい。ローカルパラメータは、バッファ充填であってよい。異なるパラメータを組み合わせて評価することができる。また、ユーザによって指示された所望の再生モードを考慮することもできる。
【００４４】
ステップ１１０からの情報がステップ１３０で結合され、その結果、ステップ１１０で考慮されたパラメータに対応する品質レベルのフラグメントを求める要求が生成される。
【００４５】
要求の結果、ステップ１４０で、適切なフラグメントが受信される。次いで、ステップ１５０で、フラグメントはクライアントによって表示される。ストリーミングの中で、例えば（受信された）より前のフラグメントの表示前に、さらに他のフラグメントを受信する要求を送ることができる。
【００４６】
次に、図２を参照しながら、本発明の装置の一実施形態についてより詳細に述べる。装置は、インターネットなどのネットワーク２６０を経由してビデオサーバ２７０に接続された、セットトップボックス、パーソナルコンピュータ、携帯電話機、または類似物などの、クライアントデバイス２００である。ネットワークの一部はＣＮＤ２６１とすることができる。
【００４７】
クライアントデバイス２００をネットワーク２６０に接続するアクセスリンクは、例えば、ｘＤＳＬ線、ＷｉＦｉリンク、３Ｇモバイルリンク、ＷｉＭＡＸリンク、または他の任意のタイプの接続とすることができる。ビデオサーバ２７０の機能は、コンテンツ配信ネットワーク（図示せず）の１つもしくは複数の要素、またはプロキシ要素によって達成することができる。一般性を失うことなく、ビデオサーバ２７０は、ビデオコンテンツの特定のアイテムの３つのバージョン２７１、２７２、２７３へのアクセスを有するものとして示されている。各バージョン２７１、２７２、２７３は、いくらかの継続時間のフラグメントのセットを含む。
【００４８】
クライアントデバイス２００内では、処理デバイス２１０が、ビデオサーバ２７０をクライアントデバイス２００にリンクするネットワーク２６０のダウンストリームチャネル上のデータレートなど、利用可能なパラメータを推定する。この評価は、帯域幅を推定することを含んでよい。評価は、追加的にまたは代替的に、知られている量のデータをダウンロードするのに必要とされる実際の時間量を測定することを含んでよい。特に、データレートの評価は、入来する１つのビデオフラグメントまたは各ビデオフラグメントの送信の継続時間を計ることを含んでよい。
【００４９】
クライアントデバイス２００はまた、ユーザ入力手段（図示せず）（リモートコントロール、マウス、キーボード、または専用制御パネルとすることができる）と、このようなデバイスによって提供される信号を解釈するための必要ドライバとを備える。ユーザ入力手段により、ユーザは、スローモーション、フルスピード再生、早送り、一時停止／再開、ビデオカーソル再配置、視点変更など、所望の再生モードを選択することができる。所望の再生モードは、処理デバイス２１０によって評価することができる。
【００５０】
要求エージェント２３０は、処理デバイス２１０から得られた情報に基づいて、ビデオサーバ２７０によって提供される品質レベル２７１、２７２、２７３の中からターゲット品質レベルを選択する。ターゲット品質レベルは、ダウンストリームリンク上の輻輳を引き起こすことなくダウンロードできるとともに、対応するビデオコンテンツを表示することによってダウンロードレートとほぼ同じレートで消費できる、持続可能な最高品質レベルであることが好ましい。この決定は、前述の計算に従って行うことができる。ターゲット品質レベルが決定されると、選択されたターゲット品質レベルの次の１つまたは複数のビデオフラグメントを得る要求が生成される。要求は、サーバ２７０によってサポートされるプロトコルの要件に従ってフォーマットされる。好ましくは、要求はＨＴＴＰ「ｇｅｔ」要求であり、この要求の中で、１つまたは複数の特定の品質レベルに対応するＵＲＩが指定される。より好ましくは、要求はさらに、ＵＲＩによって指定される品質レベルのうちの特定の１つ（とりわけ、選択されたターゲット品質レベル）に対応するパラメータを含む。
【００５１】
要求に応答して、ビデオサーバ２７０は、ネットワーク２６０を介して、要求されたビデオフラグメントの適切なバージョンをクライアントデバイス２００に送信する。スケーラブルビデオ符号化または類似の符号化技法を使用して、所与の品質レベルの単一のフラグメントを、異なる品質レベルのバージョン２７１、２７２、２７３の一部として、複数のファイルで表すことができる。コンテンツ配信ネットワーク２６１など、ストレージ使用を最適化することを目指すネットワークアーキテクチャ中では特に、同じフラグメントに属する異なるファイル、および、同じビデオストリームの異なるフラグメントに属するファイルを、異なるソースからネットワーク２６０を介してクライアントデバイス２００に送信できることは、当業者なら理解するであろう。本発明の方法の動作を説明する目的上、この状況は、単一の統合ビデオサーバ２７０がある状況と異なるものではない。
【００５２】
クライアントデバイス２００の受信デバイス２４０は、ビデオフラグメントを受信し、これを表示装置２５０に搬送する。表示装置２５０は、通常の暗号化解除および復号ステップを実施し、選択された再生モードでコンテンツが表示されるようにしてビデオストリームのフレームレートおよび／または解像度を適合させる。表示装置２５０はさらに、クライアントデバイス２００に組み込まれた実際の表示装置を備えてよい。別法として、表示手段２５０は、外部表示装置に接続するためのインタフェースを備えてもよい。要求が継続的に送信される結果、連続したフラグメントのセットがクライアントデバイス２００において受信されることになる。
【００５３】
受信されたフラグメントが表示されると、例えばフラグメントの品質レベルに応じて、何らかの体験がユーザによって得られることになる。クライアントにおけるサービス品質を評価する際に考慮できるアーチファクトの例の非限定的なリストは、以下のとおりである：
−  ピクチャフリーズ
−  低品質
−  品質変化
−  対話性遅延
【００５４】
ピクチャフリーズは、クライアントバッファのアンダーランの結果である可能性がある。これは、クライアントの帯域幅推定／知覚と、ネットワーク中の実際の利用可能な帯域幅との間に、（一時的な）不一致があるときに生じ得る。ピクチャフリーズは、帯域幅変動によって、またはキャッシュされたフラグメントとキャッシュされていないフラグメントの混合によって、トリガされる可能性がある。
【００５５】
利用可能な帯域幅が低い場合、クライアントは、そのフラグメントダウンロードのために、（より）低い品質を選択することになる。このようにして、クライアントは、ピクチャフリーズに対して視聴者を保護することになる。
【００５６】
１クライアント当たりの知覚される帯域幅は、多くの理由（競合するＨＴＴＰアダプティブストリーミングクライアントを含む）で変動し得る。クライアントは、知覚される帯域幅に基づいて、選択される品質を調整する。品質が適応される度に、ユーザの視聴体験は妨げられる可能性がある。
【００５７】
多くのＨＡＳクライアントにおいて、ユーザは、ビデオカーソルを再配置するかまたは別のタイプのユーザ対話を実施する能力を有する。ほとんどのタイプの対話（一時停止／再開を除く）の場合、ＨＡＳクライアントは、その現在のフラグメントバッファを無効にして、このバッファを再び最初から満たさなければならないことになる。対話性遅延は、実際のユーザ対話と、新しいシーケンスの最初のピクチャの表示との間の、必要とされる待機時間として定義することができる。
【００５８】
この４つのタイプのＨＡＳアーチファクトに加えて、他の（可能性のある）アーチファクトも、ＨＡＳアルゴリズムならびに基礎をなすプロトコル（例えば、タイミングおよび同期のためのＨＡＳ、再送のためのＴＣＰなど）によって内部で解決できることに留意されたい。
【００５９】
図３は、ネットワーク３００を使用する本発明の一実施形態の別の表現である。ネットワーク３００は、クライアント３０１とサーバ３０２との間の単一の接続として概略的にのみ示されている。異なる、および／または複数の接続も可能であることは、当業者なら理解するであろう。
【００６０】
ネットワーク３００は、ターゲット品質レベルのフラグメントを求める要求の送信、ならびに、要求に対する、ターゲット品質レベルのフラグメントを含む返信の送信を可能にする。
【００６１】
ノード３０３は、ネットワーク中のノードであり、サーバ３０３とクライアント３０１との間の接続内の任意の位置にあってよい。実施形態では、ノード３０３は、物理的にクライアント３０１上またはサーバ３０３上に位置する。一実施形態では、クライアント３０１にインストールされたソフトウェアが、ノード３０３を形成する。ネットワーク３００を介したＨＡＳストリームは、ノード３０３において捕捉される。この適用例では、捕捉は、ＨＡＳストリーム（の一部）をノードにおいて複製するステップとして理解されるものである。捕捉は、ノードにおけるプロービング、傍受、または介入を含んでよい。
【００６２】
本発明の一実施形態では、ＨＡＳセッションの一部として送られた要求および要求に対する返信のうちの少なくともいくつかを含む捕捉されたデータを使用して、クライアントにおけるセッションのサービス（＝体験）品質が再構築される。クライアントにおけるセッションを再構築することで、ＨＡＳセッションに関するクライアントにおけるサービス品質およびユーザの体験についてデータを得ることができる。
【００６３】
セッションの完全な再構築を実施するために、捕捉されたＨＡＳストリームから以下の情報を取り出すことができる（３０４）：
１）ＨＴＴＰメッセージのレベルで
ａ．フラグメントごとの要求時間：ＨＴＴＰ−ＧＥＴの捕捉時間
ｂ．要求されたフラグメント品質：ＨＴＴＰ−ＧＥＴの要求されたＵＲＬ中のパラメータとして入手可能
ｃ．個々のフラグメントの再生時間：要求されたＵＲＬ中またはマニフェストファイル中で入手可能
ｄ．フラグメント継続時間：固定、またはマニフェストファイル中で入手可能（Ｏｔｈｅｒｓ）
ｅ．フラグメントの最初のバイトの到着時刻：ＨＴＴＰ−ＯＫヘッダの捕捉時刻
ｆ．キャッシング指示：クライアントが条件付きＧＥＴを実施したが一方でサーバ中のデータが修正されていなかった場合の、ＨＴＴＰメッセージ３０４「Ｎｏｔ  Ｍｏｄｉｆｉｅｄ」の使用
２）ＴＣＰメッセージのレベルで
ａ．ＨＡＳフラグメントの最後のバイトの到着
３）ＨＡＳクライアント３０１のレベルで
ａ．捕捉されたデータから、使用クライアントソフトウェアを検出することも可能である。
【００６４】
使用クライアントソフトウェアに関する情報が利用可能なとき、この情報を使用して、例えば、このクライアント（バージョン）によって使用される最大バッファ充填、またはこのクライアントについての他の重要な挙動特性を見出すことができる。クライアントソフトウェアの挙動特性の一例は、例えば、あるパニックしきい値未満にバッファ充填が下がったときに、クライアントが最低品質レベルにジャンプすることである。
【００６５】
一実施形態では、クライアントバージョン（スムーズストリーミングの場合は、＊．ＸＡＰファイルによって表される）は、ファイル名、ファイルサイズの組合せから決定することができ、ファイルのハッシュを使用することができる。
【００６６】
クライアントにおけるセッションパラメータの再構築の一部として、検出された各クライアントバージョンにつきクライアント特性を演繹することもできる。特性の演繹は、観察された取出しパターンに基づくことができる。さらに他のクライアント特性は、最大バッファ充填、パニックしきい値レベルなどとすることができる。
【００６７】
一実施形態では、異なるノード３０３が共に働いて、特徴的なクライアント情報をネットワーク中の中央サーバ（図３には示さず）に転送することができる。この中央サーバから、クライアント挙動情報は妥当性検査され、フィルタリングされ、結論が再びノード３０３に配信される。
【００６８】
捕捉されたセッションデータ３０４は、後でさらに述べる再構築アルゴリズム３０５に入力される。
【００６９】
再構築により、ＨＡＳクライアントにおけるユーザの体験に関係するパラメータを得ることができることになる（３０６）。再構築されたパラメータを使用して、ピクチャフリーズ、品質低下、品質変化、および対話性遅延など、セッションアーチファクトを再構築することができる（３０７）。これらの値は、クライアント３０１を使用するユーザの体験を表すデータとして使用することができる。複製されたセッション情報は、コンテンツプロバイダ、ネットワークプロバイダ、またはＣＤＮプロバイダなどの関係者のために情報を収集する、ネットワーク中の１つまたは複数の中央ポイント（ネットワークアナライザエンティティなど）に、ネットワーク３００を介して提供することができる（３０８）。
【００７０】
次に、セッションを再構築するための具体的なプロセスステップの、さらに他の実施形態について述べる。
【００７１】
フラグメントが、ブラウザ中で、またはノード３０３とエンドユーザ３０１との間に位置するＨＴＴＰプロキシ中で、ローカルにキャッシュされる場合、これらのフラグメント要求は、ノード３０３中で欠損することになる。したがって、これらのキャッシュされたフラグメントの使用品質レベルは、ノード３０３には見えないままである。
【００７２】
欠損の品質レベルの単純な補外を用いて、欠損の品質レベルの再構築を実施することができる。欠損フラグメント（複数可）の前の最後の利用可能な品質レベルがレベル１品質であり、次の品質レベル（欠損フラグメントの後）もまたレベル１である場合、欠損レベルはレベル１に設定することができる。
【００７３】
一実施形態では、品質レベルは、現在のバッファ充填、クライアントの特性（品質を上昇させるかまたは低下させるためのしきい値レベルなど）、ある時間量内にとることのできる上昇および低下方向の最大品質ステップ数、欠損フラグメントの後のバッファ充填レベル、などの要素を使用して推論される。
【００７４】
図４に、例示的な一実施形態を示す。特定のクライアントが、品質上昇アクションを、例えば１０秒ごとに最大１品質レベルの上昇／低下に制限した場合、および、レベルｎからレベルｎ＋３への何らかの遷移に３０秒かかる場合は、この３０秒間の受信フラグメントについて何も知らなくても、この知識に基づいて中間品質レベルを正確に計算することができる。
【００７５】
この例では、約３０秒の期間中、プローブ３０３は、どんなフラグメント／要求も受信しなかった。プローブが新しいフラグメントを受信したとき、このフラグメントは、ｎ＋３０番目のフラグメントである。プレイアウトを継続するためにクライアントによって要求されたはずのフラグメントは、プローブによって受信されなかった。この理由は、これらのセグメント（ｓｅｇ  ｎ＋１からｓｅｇ  ｎ＋２９）が、前に（前のプレイアウトで）要求されて、
１）ウェブブラウザのローカルキャッシュから供給されたか、
２）クライアントとＨＡＳプローブとの間の中間ノードのキャッシュから供給されたか
のいずれかである可能性がある。
【００７６】
１セグメント当たりの継続時間（例えば１秒）、いつ各セグメントが再生されなければならないかについての知識（ｓｅｑｎｒ）、および、想定されるプレイアウトの進行（１秒ごとに１秒バッファ）に基づいて、ＨＡＳセッション再構築アルゴリズム（ＨＡＳ−ＳＲ）は、セッション中の欠損セグメントを補外することができ（例えば、最後に受信されたセグメント（ｎ）と次に受信されるセグメント（ｎ＋３０）との間で等間隔に）、この推定に基づいて、起こり得るバッファアンダーランの可能性および継続時間を計算することができる。
【００７７】
フラグメントｎ＋１およびｎ＋２に関して情報が捕捉されなかったので、プローブ３０３は、要求されるビデオ品質（ＶＱ）のどんな指示も受け取らなかった。フラグメントｎはＶＱ１で要求され、フラグメントｎ＋３０はＶＱ４で要求された。ＨＡＳ−ＳＲが特定のクライアント／クライアントバージョンを認識して、このクライアントが、前の上昇ステップ後の１０秒の時間枠の後にのみＶＱをステップアップするであろうということがわかるとき、ＨＡＳ−ＳＲアルゴリズムは、この図に示すように品質遷移を演繹する。このようにして、ＶＱ３への、その後にＶＱ４への遷移の瞬間を、正確に推定することができる。
【００７８】
一実施形態では、クライアントにおけるセッションの再構築の一部は、バッファ充填の追跡を含む。バッファ充填に応じて、利用可能な帯域幅の変動がピクチャフリーズを招く可能性もあり、そうでない可能性もある。この理由で、セッション再構築プロセスの一部として、セッション中の任意の時点のバッファ充填レベル（秒で表される）が決定されることになる。
【００７９】
一実施形態では、バッファ充填を追跡する間、いくつかの要因／イベントが考慮される：
−  ビデオデータの到着：ＨＴＴＰ／ＴＣＰメッセージを介して検出することができる
−  ビデオデータの通常プレイアウト：経過時間に等しい
−  実際のバッファ充填：ゼロ未満だとプレイアウトは保留されることになる
−  以下のようなユーザ対話性
ビデオカーソルの再配置：新しいデータが到着するまでバッファをゼロにする
一時停止／再開アクション：プレイアウトを保留する
【００８０】
一実施形態では、クライアントにおけるセッションの再構築の一部は、クライアント３０１とのユーザ対話性の影響を考慮することを含む。ユーザ対話性が関係する場合、バッファ充填を決定論的に予測することはできない。これは、ＨＡＳクライアント３０１が、進行中のユーザアクションに関する情報をサーバ３００に向けて提供しないからである。これらのユーザアクションは、バッファ充填の決定論的な予測を妨げる。
【００８１】
一例は、クライアントアルゴリズムがバッファを高速充填している間（例えば初期ロード中、またはユーザ再配置の後）に、視聴者が一時停止ボタンを使用する場合である。このユーザアクションの影響は、クライアントのＧＥＴパターン中ですぐには見えない。というのは、クライアントは、この一時停止を使用してさらにバッファを安全バッファ値まで高速充填することになるからである。この結果、一時停止は、ＨＡＳセッションの再構築に気付かれないままである可能性があり、それによりバッファ充填を過少に見積もることになる。クライアントヒューリスティックは、その全バッファ容量に達していないという印象を与える。
【００８２】
図５に例を示す。一般に、初期ロード中、セグメントが相次いでロードされてクライアントバッファが満たされる。この初期ロード期間の後、クライアントは定常状態の挙動に切り替わることになり、この挙動では、セグメント間の追加待機時間が挿入されてバッファオーバーフローが回避される。
【００８３】
この例では、初期ロード期間中、ｔ＝ｘ１で、ユーザはプレーヤを一時停止する。一次停止中、プレーヤはさらに他のフラグメントを要求し続けることになり、受信が継続することになる。クライアントにおける実際のバッファ充填は、グラフ４００によって示される。ｘ４で、後続のフラグメントを受信する結果としてバッファ充填が増加する。増加はｘ５で終了する。一次停止によりローカルバッファからどんなデータも表示されないので、バッファの実際の充填はこのレベルに留まる。
【００８４】
実際のバッファ充填４００は、後続のステップで、点線で示される最大レベルまで増加する。入手可能なプレーヤの場合、典型的な最大レベルは、２０秒と４０秒の間である。ｘ２でのみ、バッファからのフラグメントを表示する結果としてバッファレベルは低下することになる。その後は、フラグメントを求めるさらに他の要求、およびこれらの要求／ターゲットフラグメントの受信により、バッファ充填レベルはバッファ最大値付近になる。
【００８５】
捕捉ノードにおいて、要求および返信は捕捉される。一実施形態では、再構築方法は、継続的な再生を仮定する。再構築において時間が進むにつれて、グラフ４０１が構築される。２つのグラフ４００と４０１の間の「高さ」の差は、その瞬間の一時停止長さにちょうど等しい。
【００８６】
一次停止の結果、プローブは、実際のバッファ充填を過少に見積もる。
【００８７】
セッションの再構築において、クライアントのバッファは、４０４によって示される最大バッファレベルを有するように見える。クライアントのプレーヤのバッファ充填の最大レベルがプローブ中でわかっている（例えば前のセッションがこのプローブによって処理されたため）場合、またはプローブがこの情報をネットワーク中の中央収集通知ポイントから受け取ったとき、再構築方法は、過少な見積もりを訂正することができる。時間差４０６を推定することができる。時間差４０６は、実際の一時停止の継続時間（ｘ１−ｘ２の間）に対応する。したがって、再構築方法では、そのような情報を実際に受け取ることなく一次停止を再構築することが可能である。
【００８８】
別の例は、ユーザが、一次停止を、プレイアウトにおけるさらに離れた時点への再配置と組み合わせている場合である。この場合、セッション再構築は、欠損しているＧＥＴおよびＯＫが中間キャッシングによって引き起こされると合理的に仮定することができる。またこの場合、推定されるバッファ充填レベルは、クライアント中の実際のバッファ充填レベルとは異なる可能性がある。
【００８９】
この場合、使用されるクライアントヒューリスティックに関する情報（例えば、クライアント（バージョン）によって適用される最大バッファ充填）を使用して、バッファ充填が訂正されることになる。いつバッファが定常状態にあるかを検出することにより、バッファ充填を正確に調整することができる。クライアント３０１におけるいくつかのユーザアクションに関する入力をノード３０３中で受け取らなくても、完全なセッション再構築を監視することによってこれが可能である。
【００９０】
一実施形態では、要求されたフラグメント品質と実際のバッファ充填との点から見たＨＡＳセッションの再構築に基づいて、セッションのＱｏＥパラメータを計算することが可能である。ＱｏＥパラメータは以下を含むが、これらに限定されない：
−  ピクチャフリーズ：ピクチャフリーズの回数、ピクチャフリーズの総時間、初期対話性遅延
−  プレイアウト品質：平均プレイアウト品質、最高プレイアウト品質、最低プレイアウト品質
−  品質変化：品質遷移（上昇／低下）の回数、品質遷移における平均ステップ数
−  総対話性遅延、１ユーザアクション当たりの平均対話性遅延
【００９１】
加えて、平均および最高バッファ充填（ビデオフラグメントの円滑な送達のための尺度として）、ならびに観察されたユーザ挙動（一次停止の回数、総一次停止時間、ユーザ再配置、ザッピングおよびスキッピング、フラグメントの人気など）に関して、情報を提供することができる。
【００９２】
これらのＱｏＥパラメータを使用して、ＩＳＰ、コンテンツプロバイダ、およびＣＤＮプロバイダは今や、ＨＡＳコンテンツを送達する際の大域的なネットワーク性能を永続的に測定、監視、および追跡することが可能になる。さらに、ＩＳＰおよびＣＤＮプロバイダは、ネットワーク中でＨＡＳトラブルシューティングを実施することができる。再構築によってまた、コンテンツプロバイダおよびＣＤＮプロバイダは、サービスレベルアグリーメント（ＳＬＡ）の基礎となり得る、ＨＡＳ送達に関する測定可能な目標を定義することができる。さらに、ＨＡＳサービス送達品質の最小値を定義することもできる。
【００９３】
クライアントにおけるＱｏＥを再構築してＱｏＥデータを提供する結果、ＨＡＳセッションに関係するキャッシング問題を最適化することができる。
【００９４】
コンテンツの最初、またはコンテンツ中のいくつかの人気のあるジャンプポイントにおけるフラグメントは、常に、バッファ充填が非常に低い（初期ロードのせいで、またはユーザによるカーソル再配置のせいで）状態で要求される。ネットワークは、これらのフラグメントが要求されたときの平均バッファ充填に基づいて、エンドユーザにより近く位置するキャッシュにこれらのフラグメントを記憶することを決定することができる。別の可能性は、ノードのキャッシュエビクション戦略において、フラグメントごとの平均バッファ充填を考慮することである。バッファ充填が低い状態で常に要求されるフラグメントは、より長くキャッシュ中に保持することができる。どちらの場合も、初期待機時間および対話性遅延をかなり低減することができる。
【００９５】
要求があり次第クライアントの実際のバッファ充填を提供する、（修正された）クライアントを実行するのと比較して、信頼されるネットワークノード中での再構築はより安全であると考えることができることに留意されたい。そのようなクライアントは、非常に低いバッファ値を故意に報告して不当な量のリソースをネットワークから得るために、いくぶん容易に操作またはハッキングされる可能性がある。
【００９６】
ＨＡＳ−ＳＲ機能は、ＨＡＳフローの送達に関与するノード中で実行されていてよく、いくつかの追加パラメータ（現在のバッファ充填、一次停止／再開などのユーザアクションなど）を元の要求に加えて中間ノードに知らせることができる。
【００９７】
「エージェント」または「プロセッサ」の符号が付いた任意の機能ブロックを含めた図示の様々な要素の機能は、専用ハードウェアを使用して、ならびに適切なソフトウェアとの関連でソフトウェアを実行できるハードウェアを使用して、提供することができる。プロセッサによって提供されるとき、これらの機能は、単一の専用プロセッサ、単一の共有プロセッサ、または複数の個別プロセッサ（いくつかは共有される場合がある）によって提供することができる。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行できるハードウェアのみを指すものと解釈すべきではなく、ディジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を、限定ではなく暗黙的に含み得る。従来型および／またはカスタムの、他のハードウェアもまた含まれてよい。同様に、図示のどんなスイッチも、概念的なものに過ぎない。これらの機能は、プログラムロジックの動作を通して、専用ロジックを通して、プログラム制御と専用ロジックとの対話を通して、さらには手動で実施されてよく、特定の技法は、コンテキストからより具体的に理解されるように、実施者によって選択可能である。
【図１】
2014519259.tif 000003
【図２】
2014519259.tif 000004
【図３】
2014519259.tif 000005
【図４】
2014519259.tif 000006
【図５】
2014519259.tif 000007
【国際調査報告】
2014519259.tif 000008
2014519259.tif 000009