(57)【要約】  ネットワークノードにおいてクライアントとサーバとの間のｈｔｔｐ適応ストリーミングビデオセッションにおける再バッファリングイベントの存在を決定するための方法であって、動作モードにおいて：−  前記ビデオセッションについての後続のｈｔｔｐＧＥＴメッセージを収集するステップと、−  前記ビデオセッションについての特徴ベクトルを抽出するステップと、−  前記特徴ベクトルと、事前に行われた訓練モード中に決定されたタスク依存特徴セットとを比較して、前記ビデオセッションについての削減された特徴セットを取得するステップと、−  前記ビデオセッションが再バッファリングイベントを含むか否かの表示を前記削減された特徴セットから導出するステップとを備える、方法。
2017515329.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークノードにおいてクライアントとサーバとの間のｈｔｔｐ適応ストリーミングビデオセッションにおける再バッファリングイベントの存在を決定するための方法であって、動作モードにおいて、
前記ビデオセッションについての後続のｈｔｔｐＧＥＴメッセージを収集するステップと、
前記ビデオセッションについての特徴ベクトルを抽出するステップと、
前記特徴ベクトルと、事前に行われた訓練モード中に決定されたタスク依存特徴セットとを比較して、前記ビデオセッションについての削減された特徴セットを取得するステップと、
前記ビデオセッションが再バッファリングイベントを含むか否かの表示を前記削減された特徴セットから導出するステップと
を備える、方法。
【請求項２】
前記タスク依存特徴セットが、所定の期間の限度を超える再バッファリングイベントの存在または不在の決定をさらに可能にするようなものである、請求項１に記載の方法。
【請求項３】
前記訓練モード中に、前記クライアントが、再バッファリングイベントを監視し、前記情報を前記ネットワークノードに提供して、訓練中のビデオセッションについての特徴ベクトルをクライアントからのリアルタイム再バッファリングデータと比較することで前記タスク依存特徴セットが得られるようにし、再バッファリングイベントの有無を最も示す少なくとも１つの最も可能性の高い特徴を前記特徴ベクトルから抽出するように構成される、請求項１または２に記載の方法。
【請求項４】
前記訓練モード中に、一連のステップを備えるモデルが決定され、さらに前記動作モード中に、削減された特徴セットに適用して、再バッファリングイベントの存在または不在の表示をそれから導出できるようにする、請求項３に記載の方法。
【請求項５】
クライアントとサーバとの間のｈｔｔｐ適応ストリーミングビデオセッションにおける再バッファリングイベントの存在を決定するためのシステムであって、動作モードおよび訓練モードで動作するように構成され、動作モードにおいて、
前記ビデオセッションについての後続のｈｔｔｐＧＥＴメッセージを収集し、
前記ビデオセッションについての特徴ベクトルを抽出し、
前記特徴ベクトルと、事前に行われた訓練モード中に決定されたタスク依存特徴セットとを比較して、前記ビデオセッションについての削減された特徴セットを取得し、
前記ビデオセッションが再バッファリングイベントを含むか否かの表示を前記削減された特徴セットから導出し、前記情報を前記システムの出力において提供する
ように構成される、システム。
【請求項６】
前記再バッファリングイベントの期間が、所定の閾値を超えるか否かを判定するようにさらに構成される、請求項５に記載のシステム。
【請求項７】
訓練モード中に、前記クライアントにより提供される訓練ビデオセッションの再バッファリングイベントのリアルタイムデータを受信し、それらを、訓練中のビデオセッションについての特徴ベクトルと比較し、再バッファリングイベントの有無を最も示す少なくとも１つの最も可能性の高い特徴を前記特徴ベクトルから抽出するように構成される、請求項５または６に記載のシステム。
【請求項８】
前記訓練モード中に、一連のステップを備えるモデルを決定し、さらに前記動作モード中に、削減された特徴セットに適用して、再バッファリングイベントの存在または不在の表示をそれから導出できるようにするようにさらに構成される、請求項７に記載のシステム。
【請求項９】
サーバと複数のクライアントとの間のｈｔｔｐ適応ストリーミングビデオセッションを供給するためのネットワークのネットワークノードであって、請求項５から８のいずれか一項に記載のシステムを備える、ネットワークノード。
【請求項１０】
請求項１から４のいずれか一項に記載の方法を実施するように構成される、コンピュータプログラム。
【請求項１１】
請求項１０に記載のプログラムを備える、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２０１４年３月６日に出願された欧州特許出願第１４３０５３２３．９号に対する優先権を得る。
【０００２】
本発明は、現在のセッションの品質スコアを決定するために、たとえば、「ｓｅｓｓｉｏｎ  ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ  ｆｏｒ  ＨＴＴＰ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ」、Ｒａｆ  Ｈｕｙｓｅｇｅｍｓら著、ＩＷＱＯＳ、２０１２  ＩＥＥＥ  ２０ｔｈ  ｉｎｔｅｒｎａｔｉｏｎａｌ  ｗｏｒｋｓｈｏｐ  ｏｎ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ、１−９頁、ＸＰ０３２２０７３６７の論文に記載された方法により後で使用され得る再バッファリングイベントを容易に決定するための方法に関する。
【背景技術】
【０００３】
オンラインビデオトラフィックは、インターネットにおいて支配的になっている。ビデオの視聴中の、以降ＱｏＥと短縮される体感品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｅｘｐｅｒｉｅｎｃｅ）は、オンラインビデオマーケットにおける重要な成功要因である。以降ＨＡＳと短縮されるＨＴＴＰ適応ストリーミング（ＨＴＴＰ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ）ベースのビデオ配信の人気および成長、ならびに使用可能なＨＡＳ配備の増加と共に、ネットワークおよびコンテンツ配信プロバイダは、それらのネットワーク上でのＨＡＳセッションの知覚されるエンドユーザの体感品質を監視することへの関心を高めており、その理由は、これが、エンドユーザが視聴されているビデオに満足している度合いを伝えるはずであるためである。しかしながら、再バッファリングイベントの発生および期間は、通常は、クライアントアプリケーションのみに知られており、そのような情報をコンテンツプロバイダに提供するための上流への品質レポートは常に存在するわけではない。
【０００４】
したがって、クライアント側で発生したＱｏＥイベントを理解するためのネットワークベースのＱｏＥ評価メカニズムが、先述の論文に記載されている。このメカニズムは、一方では、要求されたビットレートおよびそれらの変更により表されるような品質レベル、品質切り替えなどのＱｏＥ関連のパラメータを必要とし、他方では、再バッファリングイベントの存在（または不在）、再バッファリングイベントの位置、再バッファリングイベントの期間、再バッファリングイベントの頻度などを含む、再バッファリングパラメータとも呼ばれるフリーズ関連のパラメータを必要とする。品質関連のＱｏＥパラメータは、ネットワークプロバイダまたはＣＤＮプロバイダにより受信されるＨＴＴＰ「ＧＥＴ」メッセージのシーケンスから直接導出することができるが、再バッファリング関連のパラメータは、上述の特許出願に記載されたようなセッション再構築に頼らなければならない。
【０００５】
その論文では、サーバまたはネットワークモジュールにおいてフリーズまたは再バッファリング関連のＱｏＥパラメータを取得するためには、全てのセッションが、再バッファリングイベントを含むか否かにかかわらず、完全に再構築される必要があることがさらに述べられている。セッション再構築が行われた後にしか、セッションが再バッファリングイベントを含むか否かを知ることができない。これが意味しているのは、再バッファリングイベントのない良好なセッションまでもが再構築されることによる計算資源の莫大な浪費だけではない。さらには、セッションの再構築には、再構築に関するヒューリスティック依存規則（ｈｅｕｒｉｓｔｉｃ  ｄｅｐｅｎｄｅｎｔ  ｒｕｌｅｓ）のセットを定義するための人手による労力が必要となり、これは、新たなヒューリスティックスが現れた場合にいくつかの拡張性の問題につながる可能性がある。
【０００６】
したがって、セッション再構築が行われる前に、ビデオセッションが再バッファリングイベントを含むか否かを、そのような再バッファリングイベントはフリーズに対応するものであるが、高速かつ自動的に識別する必要がある。これにより、フリーズなしのセッションの再構築を回避して、問題のあるセッションのみに資源を費やすようにする。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「ｓｅｓｓｉｏｎ  ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ  ｆｏｒ  ＨＴＴＰ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ」、Ｒａｆ  Ｈｕｙｓｅｇｅｍｓら著、ＩＷＱＯＳ、２０１２  ＩＥＥＥ  ２０ｔｈ  ｉｎｔｅｒｎａｔｉｏｎａｌ  ｗｏｒｋｓｈｏｐ  ｏｎ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ、１−９頁、ＸＰ０３２２０７３６７
【非特許文献２】Ｍｉｔｃｈｅｌｌ，Ｔｏｍ  Ｍ著、（１９９７年）、Ｍａｃｈｉｎｅ  Ｌｅａｒｎｉｎｇ、Ｔｈｅ  Ｍｃ−Ｇｒａｗ−Ｈｉｌｌ  Ｃｏｍｐａｎｉｅｓ，Ｉｎｃ．、ＩＳＢＮ００７０４２８０７７
【非特許文献３】Ｑｕｉｎｌａｎ，Ｊ．Ｒ．著、Ｃ４．５：Ｐｒｏｇｒａｍｓ  ｆｏｒ  Ｍａｃｈｉｎｅ  Ｌｅａｒｎｉｎｇ、Ｍｏｒｇａｎ  Ｋａｕｆｍａｎｎ  Ｐｕｂｌｉｓｈｅｒｓ、１９９３年
【発明の概要】
【課題を解決するための手段】
【０００８】
したがって、本発明の実施形態の目的は、従来技術の方法に内在する欠点を示さない改良された方法を提案することであり、したがって、ビデオ配信セッションにおけるフリーズの存在を容易に識別するシステムおよび方法を提供することである。本発明の実施形態によれば、この目的は、ネットワークノードにおいてクライアントとサーバとの間のｈｔｔｐ適応ストリーミングビデオセッションにおける再バッファリングイベントの存在を決定するための方法であって、動作モードにおいて：
−  前記ビデオセッションについての後続のｈｔｔｐＧＥＴメッセージを収集するステップと、
−  前記ビデオセッションについての特徴ベクトルを抽出するステップと、
−  前記特徴ベクトルと、事前に行われた訓練モード中に決定されたタスク依存特徴セットとを比較して、前記ビデオセッションについての削減された特徴セットを取得するステップと、
−  前記ビデオセッションが再バッファリングイベントを含むか否かの表示を前記削減された特徴セットから導出するステップと
を備える、方法を提供することで実現される。
【０００９】
このようにして、問題のあるビデオセッションの有無を迅速に識別するための完全に自動化された方法が得られる。
【００１０】
一実施形態では、前記タスク依存特徴セットは、所定の期間の限度を超える再バッファリングイベントの存在または不在の決定をさらに可能にするようなものである。
【００１１】
これにより、フリーズまたは再バッファリングが存在する場合に、フリーズが、所定の閾値期間により判定されるような「長い」フリーズまたは短いフリーズのいずれであると考えられるかを決定することがさらに可能になる。
【００１２】
同様に、別の実施形態では、複数のフリーズの存在もまた、別のタスク依存特徴セットによって検出することができる。
【００１３】
一実施形態では、前記クライアントが、訓練モード中に、再バッファリングイベントを監視し、前記情報を前記ネットワークノードに提供して、訓練中のビデオセッションについての特徴ベクトルをクライアントからのリアルタイム再バッファリングデータと比較することで前記タスク依存特徴セットが得られるようにし、再バッファリングイベントの有無を最も示す少なくとも１つの最も可能性の高い特徴を前記特徴ベクトルから抽出するように構成される。
【００１４】
これにより、タスク依存特徴セットが、クライアントにより取得された実際の測定値に基づくことが保証される。
【００１５】
別の実施形態では、前記訓練モード中に、一連のステップを備えるモデルが決定され、さらに前記動作モード中に、削減された特徴セットに適用して、再バッファリングイベントの存在または不在の表示をそれから導出できるようにする。
【００１６】
これらのモデルは、後で動作モード中に、削減された特徴セットの値を迅速に評価するために使用される。
【００１７】
また、本発明は、上述の方法を実施するためのシステム、そのようなシステムを備えるネットワークノード、および処理デバイス上で実行された場合に方法のステップを実施するように構成されるコンピュータプログラムにも関する。
【００１８】
添付図面と併せて実施形態の以下の説明を参照することで、本発明の上記および他の目的および特徴がより明らかとなり、本発明自体が最良に理解されよう。
【図面の簡単な説明】
【００１９】
【図１ａ】通常の動作モードにおける再バッファリングイベントを決定するためのシステムの動作の概略図である。
【図１ｂ】学習モードにおける再バッファリングイベントを決定するためのシステムの動作の概略図である。
【図２】特徴抽出に使用される方法の一実施形態の詳細の図である。
【図３】訓練モードにおいてタスク依存特徴セットを取得するのに使用される方法の一実施形態の詳細の図である。
【図４】、訓練結果およびオンライン測定値から（複数の）フリーズの発生およびそれらの長さの表示の迅速な評価を決定する方法の一実施形態の詳細の図である。
【図５】完全なシステムの一実施形態の図である。
【発明を実施するための形態】
【００２０】
「プロセッサ」とラベル付けされた任意の機能ブロックを含む、図面に示された様々な要素の機能が、専用ハードウェアを用いて、ならびに適切なソフトウェアとともにソフトウェアを実行可能なハードウェアを用いて提供され得ることに注目されたい。プロセッサにより提供される場合、機能は、単一の専用プロセッサ、単一の共有プロセッサ、または一部が共有され得る複数の個別プロセッサにより提供され得る。その上、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指すよう解釈されるべきではなく、暗黙的に、限定はしないが、デジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージを含み得る。他のハードウェアも、従来型および／またはカスタム型であっても、含まれ得る。それらの機能は、プログラムロジックの動作を通じて、専用ロジックを通じて、プログラム制御および専用ロジックの相互作用を通じて、または手動でさえ実行することができ、特定の技法は、文脈からより具体的に理解されるように実装者により選択可能である。
【００２１】
本明細書の任意のブロック図が、本発明の原理を具現化する例示的回路の概念図を表すことを当業者にはさらに理解されたい。同様に、任意のフローチャート、フロー図、状態遷移図、擬似コードなどが、コンピュータ可読媒体に実質的に表現され得、したがってコンピュータまたはプロセッサにより、そのようなコンピュータまたはプロセッサが明示的に示されていようといまいと、実行され得る様々な処理を表すことは理解されよう。
【００２２】
図５および１ａ−ｂは、ｈｔｔｐセッションにおけるフリーズを識別するためのシステムの一実施形態の上位レベルの外観を示している。システムは、ただ１つのプロセッサを用いて実現され得、あるいはネットワーク内のいくつかの物理サーバまたはプロセッサの間で分散され得るいくつかのモジュールを備える。
【００２３】
ネットワークは、モバイルもしくは固定ネットワークまたはこれらの任意の組み合わせとすることができる。ネットワークは、ビデオサーバと、クライアント１からクライアントＮと表記された複数のクライアントとの間に位置する雲により図示されている。サーバとクライアントとの間のビデオ配信は、ｈｔｔｐ適応ストリーミングプロトコルを利用し、これは、それぞれのクライアントが各々、クライアントとサーバとの間のそれぞれのビデオセッションのビデオセグメントごとに、通常はビットレートで表される特定の品質をサーバに要求することを意味している。これらの要求は、１つのセグメントについて、およびそれぞれのクライアント１からＮについて、ＧＥＴｒｅｑ１からＧＥＴｒｅｑＮと表記され、これらの要求は、図１ａのステップ（１）においてそれぞれのクライアントにより送信される。図１ａの図面を煩雑にしないために、それぞれのビデオセッションごとの多数の連続する要求のうちの１つのみが示されている。これらのＧＥＴ要求は、システムの一実施形態に含まれる１００と表記された第１のモジュールにより傍受される。したがって、このモジュール１００は、Ｎ個のクライアントからビデオサーバに送信されたこれらのｈｔｔｐ「ＧＥＴ」要求のコピーを、ステップ（２）においてこれらのＧＥＴ要求を修正なしでさらにビデオサーバに送信する前に傍受するように構成され、また、図１ａ−ｂおよび図４に示された実施形態では、さらにログ記録するまたは一時的に格納するように構成される。
【００２４】
このようにして、図１ａ−ｂの実施形態では、モジュール１００は、異なるビデオクライアントとビデオサーバとの間の全てのセッションに関する全ての連続したＧｅｔ要求のコピーを、これらのそれぞれのセッションが終了するまで収集し格納する。セッションが終了すると、このようにログ記録されたＧＥＴ要求は、ステップ（３）において、ビデオセッション解析モジュール２００に提供される。
【００２５】
図面に示されていない別の実施形態では、モジュール１００は単にｈｔｔｐＧＥＴ要求を傍受し、ただちにコピーをビデオ解析モジュール２００に提供するのみであり、次いでビデオ解析モジュール２００がこれらのＧＥＴ要求を収集し格納するように構成される。このモジュール２００の主な機能は、ログ記録モジュール１００から受信したｈｔｔｐＧＥＴ要求を解析して分析し、それぞれの受信された要求を、それぞれのＩＰアドレスまたは一意のセッションキーを有するそれぞれのクライアントからの単一のビデオセッションに分類することである。このように、Ｎ個のクライアントのＮ個のセッションの後続のＧＥＴデータは、ビデオセッションごとに１つのカテゴリずつ、Ｎ個のカテゴリに分類される。
【００２６】
この分類の後、それぞれのビデオセッションごとに１つのセットずつ、Ｎ個のそれぞれのＧＥＴ要求データのセットが、ステップ（４）において特徴抽出モジュール３００に提供され、特徴抽出モジュール３００はＮ個のビデオセッションの各々に対して単一の特徴ベクトルを生成するように構成される。この目的のために、モジュール３００は、訓練モジュールから何らかのデータ、より詳細には、推定されるセグメント長を表すパラメータＳｅｇＬｅｎｇｔｈと、考慮されるべき近傍のセグメントの数を表すパラメータＫとを前もって必要とし、これらのパラメータは訓練モジュール５００により事前に決定されたものである。
【００２７】
そして、モジュール３００は２Ｋ個の値のセットを決定し、これらは、ベクトル内に配置される場合、Ｋ＝２０の場合に４０個の要素の特徴ベクトルを構成することになる。
【００２８】
しかしながら、Ｋは異なる値を有することもできる。
【００２９】
図２に示された例では、１から３の範囲の値を有するＫについて、３つの例示的な状況が示されている。
【００３０】
図２では、左の上方の線は、１つの特定のクライアントの１つの特定のビデオセッションのタイミング図を概略的に示している。図を煩雑にしないために、このクライアントを識別するためのインデックスは省略されている。ビデオセッション解析モジュールにより提供される、連続したセグメントを要求するためのこのクライアントについての連続したＧＥＴ要求の発生は、上から下へ向かいそのタイムライン上で終わる矢印によって示されている。ＧＥＴ要求が受信される度に、インデックスｊが増加する。また、このインデックスは、このタイムラインの下に図示されており、最初のＧＥＴ要求が受信された場合に、値１から開始する。連続したＧＥＴ要求の間の連続した時間間隔はＩｊにより示されており、また、ｊはＧＥＴの発生に関する時点の離散的な番号を示す。ビデオセグメント長は固定であると仮定され、この仮定に基づいて、Ｋ個の近傍セグメントの間の平均セグメント間期間のリストを、
【数１】
2017515329.tif 000003
として計算することができ、ここでＩｊは、インデックスｊ＋１およびｊを有する２つの連続した要求の間の時間である。
【００３１】
そして、ｋ＝１について、この値ｄ１，ｊは、この上方のタイムラインの下に示されるように、Ｉｊと常に等しくなる。
【００３２】
再バッファリングの発生について可能性がある場所として扱われる、ｋセグメントウィンドウについての最低推定バッファ時間は、
【数２】
2017515329.tif 000004
として計算され、ここで、
【数３】
2017515329.tif 000005
である。
【００３３】
複数のフリーズを検出するために、２番目に低い推定バッファリング時間ｂ２，ｋも特徴セットに含める。
【００３４】
【数４】
2017515329.tif 000006
であり、ここで、
【数５】
2017515329.tif 000007
である。
【００３５】
ｋ＝１について、先述のようにただ１つの近傍がセグメントごとに考慮され、そして、
【数６】
2017515329.tif 000008
は、２つの連続したセグメントｊ＋１とｊとの間の期間に等しい。ｊの連続した値についてのｄ１，ｊの連続した値が、各ビデオセグメントの下に図示されている。
【００３６】
式（２）によれば、
【数７】
2017515329.tif 000009
となり、その理由は、この特定の例では、全てのｄ１，ｊの間隔の中で最長のもの（すなわちｄ１，４）についてのインデックスｊが４に対応するためである。
【００３７】
式（１）によれば、ｂ１，１の値は、
４＊ＳｅｇＬｅｎｇｔｈ−（Ｉ１＋Ｉ２＋Ｉ３＋Ｉ４）
に等しいものと計算される。
【００３８】
これは、期間（Ｉ１＋Ｉ２＋Ｉ３＋Ｉ４）における再バッファリングイベントの発生の最も可能性の高い時間を示すものと考えられる。
【００３９】
式（４）によれば、この特定の例では、
【数８】
2017515329.tif 000010
となる。
【００４０】
式（２）によれば、ｂ２，１についての値は：
３＊Ｓｅｇｌｅｎｇｔｈ−（Ｉ１＋Ｉ２＋Ｉ３）
として計算される。
【００４１】
この特定の例について、これは、この特定の例では、再バッファリングイベントを有する２番目に可能性の高い時点に関する。
【００４２】
ｋ＝３以上について、同様の計算を行うことができ、違いは、Ｋの値により直接影響される、フリーズ発生をチェックするためのウィンドウを構成する近傍の間隔の範囲となる。これは、図２に他のタイムラインによってさらに図示されている。この図を煩雑にしないために、インデックスｊの表示がこれらのタイムラインから省略されている。しかしながら、これは上方のタイムラインに示されたものと同様である。
【００４３】
要約すれば、Ｋの特定の値および特定のセッションについて、特徴ベクトル
ｘ＝（ｂ１，１，ｂ１，２，．．．ｂ１，Ｋ，ｂ２，１，ｂ２，２，．．．ｂ２，Ｋ）
が、ただ１つのビデオセッションの高レベルな情報を表現するために抽出される。したがって、このとき単一のビデオセッションが、Ｋ＝２０の場合、４０に等しい数の列を有する特徴ベクトルにより表現される。
【００４４】
通常動作の間に、Ｎ個のクライアントの特徴ベクトルが、次いで特徴選択モジュール４００に提供される。したがって通常動作の体制では、図１ａのスイッチＳは右側へ置かれ、これによりビデオセッションの特徴をモジュール４００に提供する。そのモジュールでは、これらは、図１ａに示されるように訓練モジュール５００から受信されるデータＴＤＦＳと比較される。
【００４５】
モジュール４００の出力は、ＲＦＳと表記される削減された特徴セット（ｒｅｄｕｃｅｄ  ｆｅａｔｕｒｅ  ｓｅｔ）であり、これは後の段落でこのモジュールの動作と共に説明される。
【００４６】
これらのＲＦＳの結果は次にモジュール７００に提供され、モジュール７００は削減された特徴セットと、モデル格納モジュール６００から受信されるモデルとを用いる。その動作もまた、後の段落で論じられる。フリーズ評価モジュールと呼ばれるこのモジュール７００の出力は、フリーズが存在するか否か、複数のフリーズが存在するか、および短いまたは長いフリーズのいずれに関連するかということについてのビデオセッションごとの短い要約となる。さらなる詳細が後の段落で与えられる。そして、これらの出力データは、先述の論文に記載されたような、これらのビデオストリームの品質を評価するためのモジュールに提供される。
【００４７】
モデル、タスク依存特徴セット、ＳｅｇＬｅｎｇｔｈおよびＫの値を取得するためには、訓練モジュール５００はまず、訓練データを取得する必要がある。この目的で、スイッチＳが左側に倒され、並行してさらにクライアントは、フリーズ発生に関するデータを訓練モジュールへ、他のモジュール８００を介して提供する必要がある。
【００４８】
ビデオセッションの訓練セットに対する特定の制限はなく、Ｎ個のクライアントとサーバとの間の任意のｈｔｔｐ適応ストリーミングセッションを、そのような訓練の目的で使用することができる。システムが現在訓練モードで動作していることは、Ｎ個のクライアントに提供される情報でもあり、その瞬間から、図１ｂに示されるように、それらのフリーズ検出モジュールのアクティブ化を開始する。この訓練モードの指示は、破線矢印により示されている。この指示は一般的には開始時に、ネットワークオペレータにより提供される。通常は、モデルが訓練された後、特定の期間の間、非常に安定したままになる。
【００４９】
しかしながら、ネットワークオペレータが再バッファリングイベントの最新の傾向を検出したい場合、クライアント側での実際の再バッファリングイベント（グラウンドトゥルース（ｇｒｏｕｎｄ  ｔｒｕｔｈ））の収集を開始し、モデルを再訓練して、新たな傾向に適応させることができる。
【００５０】
この制御信号の提供は、共にスイッチの位置を制御するためのものであり、クライアントがそれらのフリーズ測定値を提供する際のものでもあるが、ステップ（０）で行われる。
【００５１】
通常動作モードと同様に、訓練に割り当てられるセッションに関連するＧＥＴメッセージもまた、通常動作と全く同じように傍受され、ログ記録され、解析され、特徴抽出が行われる。抽出された特徴ベクトルは、通常動作中のものと同様に見えるが、ここでは左の位置に置かれたスイッチによって訓練モジュールに提供される。Ｋに使用される値は、この時点では未知であるが、反復的に決定されることになる。
【００５２】
ＳｅｇＬｅｎｇｔｈの値は、いかなるフリーズ発生もない最長の訓練セットから導出される。したがって、これは、最初の反復においてフリーズなしのセッションが存在しない場合に特に、数回の反復が行われるべきであることを意味し得る。
【００５３】
これらの訓練ビデオセッションのストリーミングの間に発生したフリーズは、Ｎ個のクライアントにより、それぞれのクライアントにおけるそれぞれのフリーズ検出モジュールＦＤ１からＦＤＮによって検出される。そのようなフリーズ検出モジュールの数個の実装が存在する：
【００５４】
１つ目は、ビデオプレーヤープラグインアプリケーションを利用する。このアプリケーションは、クライアント、たとえばクライアント１のビデオプレーヤーと組み合わせて、プレーヤーのステータス（たとえば瞬時バッファ充填レベル）を評価することができる。瞬時バッファ充填レベルが０の場合、プラグインアプリケーションは、それをビデオプレーヤーにおける画面のフリーズとして扱い、フリーズ情報ＦＲ１のレポートをモジュール８００に送信する。この情報は、それぞれのセッションごとに記録された全てのフリーズの開始および終了時刻を含む。
【００５５】
２つ目は、ＨＡＳクライアントでのＭｉｃｒｏｓｏｆｔスムーズストリーミングにおけるアドバンストロギングの機能を使用し得る。アドバンストロギングにおける１つのフィールドは「ｃ−ｂｕｆｆｅｒｃｏｕｎｔ」であり、これは特定の期間（デフォルトは３０秒）の間にフレームレベルで再バッファリングが必要とされた回数を示す。
【００５６】
訓練セットからの、それぞれのクライアント１からクライアントＮについてＦＲ１からＦＲＮと表記される全てのフリーズ情報の集約は、「グラウンドトゥルース」と呼ばれる。これは、訓練モジュール５００に提供される。
【００５７】
訓練モジュール自体は、クライアントから受信された情報、したがって、セッションごとの、フリーズがいつ発生したかとそれらが続いた時間の長さとの表示を、関連する特徴ベクトルと比較するように構成される。
【００５８】
セッションごとの３つの項目、すなわち、
（１）少なくとも１つのフリーズが存在するか否か？
（２）少なくとも１つの長いフリーズが存在するか？
（３）２つ以上のフリーズが存在するか？
を知ることのみに興味がある。
【００５９】
訓練モジュール５００により、０または１の値をこれらの記述またはイベントの各々に帰属させる。
【００６０】
フリーズが長いか短いかは所定の閾値により判定され、閾値は、たとえばネットワークオペレータによりやはり決定される入力信号ＶＴによって手動で入力することもできる。したがって、異なるオペレータは、フリーズの長さの許容範囲が異なり得る。中には、１０秒間のフリーズが長いフリーズであると考え、閾値をその値に設定する者もいるであろうが、５秒間のフリーズを長いフリーズとして扱う者もいるであろう。
【００６１】
そして、学習モジュールは、クライアントからのデータを分析し、それらから検出されたフリーズをこの閾値と比較し、それらの少なくとも１つが閾値を超えるか否かを判定するように構成される。超える場合、結果は「１」となる。
【００６２】
これは図３に示されており、上方の箱に、セッション１、２、３についての特徴ベクトルｘ１、ｘ２およびｘ３と、上記の３つの問の結果についての論理値を有する関連するイベントベクトルとを示す。
【００６３】
たとえば、第１のセッションは、関連する３列のイベントベクトルが（０，０，０）であるので、明らかに、フリーズがなく、長いフリーズがなく、複数のフリーズがない。
【００６４】
第２のセッションは、イベントベクトル（１，０，１）から明らかなように、少なくとも１つのフリーズがあり、長いフリーズがなく、２つ以上のフリーズがある。
【００６５】
同様に、第３のセッションは、少なくとも１つフリーズがあり、少なくとも１つの長いフリーズがあり、２つ以上のフリーズがある。
【００６６】
次の段階では、訓練モジュールは次いで、３列のイベントベクトルと、特徴ベクトルの２Ｋ個の特徴自体とを関連付けることを試行する。
【００６７】
図３において、これは、第２のタスクまたはイベント（少なくとも１つの長いフリーズの存在または不在）についてさらに説明される。
【００６８】
図の３つのセッション（実際の場では約１００００個以上の訓練セッションが考慮され得る）の２Ｋ個の特徴の各々、たとえば第１の特徴について、イベントベクトルの値に対する各個別の特徴の情報値を決定することにより、チェックが行われる。これは図３に図式的に示されており、３つのセッションについて、第１の特徴の情報が、第２のタスクまたはイベントの結果に対してチェックされる。そのような手順に関する情報は、たとえば、Ｍｉｔｃｈｅｌｌ，Ｔｏｍ  Ｍ著、（１９９７年）、Ｍａｃｈｉｎｅ  Ｌｅａｒｎｉｎｇ、Ｔｈｅ  Ｍｃ−Ｇｒａｗ−Ｈｉｌｌ  Ｃｏｍｐａｎｉｅｓ，Ｉｎｃ．、ＩＳＢＮ００７０４２８０７７の本で見出すことができる。
【００６９】
そして、２Ｋ個の特徴の各々についての情報利得（ｉｎｆｏｒｍａｔｉｏｎ  ｇａｉｎ）が取得およびランク付けされ、上位５つの特徴が保持され、その理由は、それらが、第２のタスクまたはイベントに関して最大の情報量を有する特徴を表すためである。
【００７０】
この手順は、タスクまたはイベントごとに反復されて、特定のタスクについての特徴ベクトルの削減された特徴のサブセットが保持される。この情報は、タスク依存特徴セットと呼ばれ、これにより図３の例では第２のタスクまたはイベントについて特徴３、８、１０、２１および３２が保持される必要があることを示す。ＴＤＦＳ２と表記されるこの情報は、後で特徴選択モジュール４００に提供されて、タスク２について、削減された特徴ベクトルまたは特徴セットが出力され、これにより特徴３、８、１０、２１および３２のみを有するベクトルとなる。
【００７１】
他のタスクについて、同様の削減された情報セットが提供される。タスクごとに、この情報が訓練モードの間に訓練モジュール５００のメモリＴＤＦＳに記憶される。
【００７２】
訓練モジュールの別の機能は、タスクごとにモデルのセットを提供することである。モデルによって示されるのは、命令および決定結果のセットであり、これらは後段で削減された特徴セットに対して実施され、これらの削減された特徴セットから、特定のイベントまたはタスクの結果が得られるか否かを決定できるようにする。たとえば、「長いフリーズか否か」のイベントについて、決定を伴う演算のリストが生成され、後で実際の動作モードからの削減された特徴ベクトルを適用して、これら５つの値から長いフリーズが存在するか否かを決定できるようにする。
【００７３】
そのようなモデルは、たとえば、Ｑｕｉｎｌａｎ，Ｊ．Ｒ．著、Ｃ４．５：Ｐｒｏｇｒａｍｓ  ｆｏｒ  Ｍａｃｈｉｎｅ  Ｌｅａｒｎｉｎｇ、Ｍｏｒｇａｎ  Ｋａｕｆｍａｎｎ  Ｐｕｂｌｉｓｈｅｒｓ、１９９３年の本に記載された原理を用いて取得することができる。
【００７４】
訓練モジュールは、このようにして得られたモデルをモデルデータベースに格納する。図１ａ−ｂにおいて、これは別個のモジュールとして示されているが、他の実施形態では、このモデルメモリは訓練モジュール自体に組み込むこともできる。
【００７５】
動作モードの場合、モジュール７００は、実データからの削減された特徴セットに対してフリーズ評価を行うことになり、したがってこのモジュールは、モデルデータベースからのモデル情報も使用し、次いでこれらの命令を削減された特徴ベクトルに用いて、特定のタスクまたはイベントに関する結果をそれから取得する。
【００７６】
これは図４に示されており、図の右部分に示されたオンラインテストの間に、タスクごとに、削減された特徴セットが、「分類」と表記されたモジュールで分析されて、セッションごとおよびタスクごとに値が取得される。そして、オンラインセッションに関して、３つの値が、この場合もやはり３列のイベントベクトルに組み合わせられる。そして、この情報は、記載のような品質評価モジュールに提供される。
【００７７】
まとめると、セッションを再構築するまたは規則を手動で設定することなくビデオセッションから抽出される数個の高レベルの特徴を用いることで、以下の３つのタスク：再バッファリングイベントの発生、長い再バッファリングの存在、および複数の再バッファリングイベントの存在を識別するための単純かつ自動化された方法が得られる。
【００７８】
従来のフリーズ分析器、たとえば未公開の欧州特許出願第１３３０５７４３号で提案されたものと比べて、３３倍の速度増加が得られる。加えて、本発明による実施形態は、再構築の規則を発見するための人手による労力を必要としない。
【００７９】
全ての異なるモジュールを備える完全なシステムの外観が図５に示されている。この実施形態では、フリーズ評価モジュールは、問題のあるビデオセッション（少なくとも１つのフリーズを有するもの）の表示を出力して、品質評価モジュールにさらに提供できるようにするように構成される。
【００８０】
本発明の原理が特定の装置との関連で上記で説明されたが、この説明が、ほんの一例として、添付の特許請求の範囲で定義されるような本発明の範囲への制限としてではなくなされていることは明らかに理解されよう。
【図１ａ】
2017515329.tif 000011
【図１ｂ】
2017515329.tif 000012
【図２】
2017515329.tif 000013
【図３】
2017515329.tif 000014
【図４】
2017515329.tif 000015
【図５】
2017515329.tif 000016
【国際調査報告】
2017515329.tif 000017
2017515329.tif 000018
2017515329.tif 000019