(57)【要約】適応型ストリーミングの状況内でのもののような、メディアコンテンツにわたって変動する品質対ビットレートレベルでメディアコンテンツの複数のメディア部分を送信するデータストリーム部分のシーケンスを含むメディアデータストリームの品質の決定は、各データストリーム部分からそれぞれの部分に対する識別子を導出することによって、及び、各データストリーム部分について、それぞれのデータストリーム部分に対して導出された識別子を用いてルックアップテーブルからパラメータセットを検索することによって、より効率的であるように構成されており、それによって、パラメータセットを集約して、それにもとづいて品質を決定することが可能である。【選択図】図１
2016530751.tif 000002
【特許請求の範囲】
【請求項１】
メディアコンテンツ（２０）の複数の異なるメディア部分（２６）を、前記メディアコンテンツにわたって変動する品質対ビットレートレベルで送信するデータストリーム部分（２２）のシーケンスを含むメディアデータストリーム（１８）の品質を決定するためのデバイスであって、該デバイスは、
各データストリーム部分（２２）からそれぞれの前記データストリーム部分部分（２２）に対する識別子（５０）を導出するように構成されている識別子生成器（４０）と、
それぞれの前記データストリーム部分（２２）について導出された前記識別子（５０）を用いて、各データストリーム部分（２２）について、ルックアップテーブル（３４）からパラメータセット（５２）を検索するように構成されている検索ユニット（４２）と、
前記メディアコンテンツ（２０）のテスト部分内にあるメディア部分（２４’）を送信するデータストリーム部分（２２）について検索された前記パラメータセット（５２）を集約するように構成されている集約器（４４）と、
前記集約されたパラメータセットに基づいて前記品質を決定するように構成されている品質決定器（４６）と、を備えているデバイス。
【請求項２】
前記識別子生成器（４０）は、前記それぞれのデータストリーム部分（２２）の非復号バージョンに基づいて前記識別子の前記導出を実施するように構成されている、請求項１に記載のデバイス。
【請求項３】
前記データストリーム部分（２２）のシーケンスは、前記品質対ビットレートレベルの変動が、前記メディアデータストリームの他の部分から別個に再現可能であり、各部分（２４）が１つ又は複数のメディア部分（２４’）を含むように、自己完結型である前記メディアデータストリーム（１８）の部分（２４）の単位で行われるように、前記メディアコンテンツ（２０）の前記複数の異なるメディア部分（２４’）を送信する請求項１又は２に記載のデバイス。
【請求項４】
前記部分（２４）はＧＯＰ又は個々のファイルである請求項３に記載のデバイス。
【請求項５】
前記データストリーム部分（２２）は、各事例におけるメディア部分（２４’）として、ビデオの画像（２６）をメディアコンテンツ（２０）として送信する請求項１から４のいずれか一項に記載のデバイス。
【請求項６】
前記メディアデータストリーム（１８）の不完全に受信された部分を検出するように構成されている送信アーティファクト検出器（１８６）をさらに備え、前記品質決定器（４６）は、前記不完全に受信された部分に対して前記メディアデータストリームの送信アーティファクトのオンライン定量化（８８）を実施するとともに、前記品質の決定（９６）に、前記不完全に受信された部分について決定された前記送信アーティファクトを使用するように構成されている請求項１から５のいずれか一項に記載のデバイス。
【請求項７】
各パラメータセットは、
前記それぞれのデータストリーム部分によって送信される前記メディア部分の再構築バージョンと、基準メディアコンテンツの対応する部分との間の類似度の相関ベースの尺度、
前記それぞれのメディア部分内に位置するエッジと、前記対応する基準部分内に位置するエッジとの差の尺度、
前記それぞれのメディア部分内におけるブロック外乱の尺度、
前記それぞれのメディア部分内と前記対応する基準メディア部分内の色度平面の差の尺度、及び
前記それぞれの部分内に位置するエッジの時間的変化と、前記対応するメディア部分内に位置するエッジの時間的変化との差の尺度、
の１つ又は複数を含む請求項１から６のいずれか一項に記載のデバイス。
【請求項８】
前記品質決定器は、前記集約された品質パラメータセットの統計学的分析から前記品質を決定するように構成されている請求項１から７のいずれか一項に記載のデバイス。
【請求項９】
ルックアップテーブル内に、
メディアコンテンツの各メディア部分に対して、複数の品質対ビットレートレベルの各々について、
前記それぞれの品質対ビットレートレベルでそれぞれの前記メディア部分が符号化されているデータストリーム部分の符号化品質を記述するパラメータセットと、
前記パラメータセットと関連付けられるとともに、前記それぞれの品質対ビットレートレベルで前記それぞれのメディア部分が符号化されている前記データストリーム部分から、前記データストリーム部分のすべてについて同じである導出仕様によって導出することができる識別子とを記憶するように構成されており、
前記識別子と関連付けられている前記品質パラメータセットを返すことによって、識別子を含む要求に応答するように構成されているサーバ。
【請求項１０】
ルックアップテーブルを生成するためのデバイスであって、該デバイスは、
メディアコンテンツの各メディア部分に対して、複数の品質対ビットレートレベルの各々について、
前記それぞれの品質対ビットレートレベルで前記それぞれのメディア部分が符号化されているデータストリーム部分の符号化品質を記述するパラメータセットと、
前記パラメータセットと関連付けられるとともに、前記それぞれの品質対ビットレートレベルで前記それぞれのメディア部分が符号化されている前記データストリーム部分から、前記データストリーム部分のすべてについて同じである導出仕様によって導出することができる識別子とを生成するように構成されており、
前記識別子と関連付けられている前記品質パラメータセットを返すことによって、識別子を含む要求に応答するように構成されているデバイス。
【請求項１１】
メディアコンテンツの複数の異なるメディア部分を、前記メディアコンテンツにわたって変動する品質対ビットレートレベルで送信するデータストリーム部分のシーケンスを含むメディアデータストリームの品質を決定する方法であって、該方法は、
各データストリーム部分から、それぞれの前記データストリーム部分に対する識別子を導出することと、
各データストリーム部分について、それぞれの前記データストリーム部分について導出された前記識別子を用いて、ルックアップテーブルからパラメータセットを検索することと、
前記メディアコンテンツのテスト部分内にあるメディア部分を送信するデータストリーム部分について検索された前記パラメータセットを集約することと、
前記集約されたパラメータセットに基づいて前記品質を決定することと、
を含む方法。
【請求項１２】
メディアコンテンツの各メディア部分に対して、複数の品質対ビットレートレベルの各々について、
それぞれの前記品質対ビットレートレベルで前記それぞれのメディア部分が符号化されているデータストリーム部分の符号化品質を記述するパラメータセットを生成することと、
前記パラメータセットと関連付けられるとともに、前記それぞれの品質対ビットレートレベルにおける前記それぞれのメディア部分が符号化されている前記データストリーム部分から、前記データストリーム部分のすべてについて同じである導出仕様によって導出することができる識別子を生成することと、
を含むルックアップテーブルを生成する方法。
【請求項１３】
コンピュータ上で作動するときに、請求項１１又は１２に記載の方法を実施するためのプログラムコードを含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、品質対ビットレートが変動するメディアデータストリームの品質を決定することに関する。
【背景技術】
【０００２】
現代の伝送技術において、データ量を低減するための特定の符号化方法が、オーディオ信号及びビデオ信号の送信に利用可能である。上記特定の符号化方法は、エンドユーザに、現在の送信チャネル容量に応じて可能な最良の品質を提供するように利用される。
【０００３】
図１１は、現在使用されているものとしての、エンドユーザに対する一般的な送信リンクを示す。送信リンクは、送信されるべきすべての種類のメディアデータを記憶するデータベースと、ネットワークを介したデータの配信を請け負うストリーミングサーバと、ネットワーク自体と、所望のデータを受信するエンドユーザ／クライアントとを含む。メディアデータは、例えば、ビデオであり得る。頻繁に尋ねられる質問は、エンドユーザによって知覚されるビデオの実際の品質に関するものである。例えば、メディアデータがサーバ側で複数の異なる品質レベルにおいて提供されるＤＡＳＨ（動的適応型ｈｔｔｐストリーミング：Dynamic Adaptive Streaming over http）又はＨＬＳ（ＨＴＴＰライブストリーミング：HTTP Live Streaming）のような適応型ビデオストリーミング技法の割合を増大させるには、受信者側で知覚されるメディアコンテンツの品質を評価するために、可能な最大範囲まで標準化されるように、複数の異なるフレームサイズ及び／又は品質レベルを評価することができる安定した、又は均一な品質尺度（品質測定基準）が必要であることが分かっている。
【０００４】
一般的に、品質概念は３つのカテゴリに区分され得る。
【０００５】
いわゆるフルリファレンス（ＦＲ）品質測定技法は、圧縮によって劣化していない元のメディアコンテンツを、その品質が決定されるべきメディアコンテンツと比較する。ここで不利なことは、メディアコンテンツの元のバージョンにアクセスする必要があることである。いわゆるノーリファレンス（ＮＲ）品質測定技法は、もっぱら、受信されるメディアコンテンツ、又はすでに受信されていてそのメディアコンテンツを表すデータストリームのみに基づいて品質を決定する。場合によって、これは、送信アーティファクトを検出し、品質尺度を決定するためにそれらを定量化することのみを含む。いわゆる縮小リファレンス（ＲＲ）品質測定技法は、当該技法が排他的に受信データストリーム又は受信メディアコンテンツのみを使用するのではなく、送信側でリアルタイムに決定される中間結果が受信側品質の決定に寄与するという点で、ＦＲ技法とＮＲ技法との間の一種の中間的なソリューションを表す品質測定技法である。それらのパラメータ又は中間結果は一般的に、送信されるメディアデータストリーム内でともに送信（ともに符号化）される。
【０００６】
特にモバイル用途において、ＦＲ品質測定技法はほとんど実装することができない。この問題に対する解決策が、米国特許出願公開第２００９／０１５３６６８Ａ１号（特許文献１）に記載されている。送信機側において、送信機側で受け取る品質分析結果がＲＴＰ拡張ヘッダ内のような送信されるデータストリーム内に挿入され、例えば、それらの品質分析結果は一般的に、送信されるメディアコンテンツのＦＲ分析の結果である。受信機側において、送信されたメディアデータストリームが、アーティファクトがないように送信されているか否かを決定するための検証が実施される。アーティファクトがない期間においては、データストリーム自体の中で送信される品質情報が受信品質の決定に使用される。欠陥のある送信が発生している、すなわち、送信アーティファクトが発生している期間においては、受信機側で品質推定が実施される。最終的に、受信機側品質は、両方の品質測定値、すなわち、干渉のない期間中に送信される品質情報に基づいて得られる測定値と、干渉の傾向がある期間中に受信機側で推定されている測定値との組み合わせから導出される。この手法は、ＦＲ方法を適用するために基準メディアコンテンツが受信機側に存在する必要がないという結果をもたらすにしても、上記で引用されている文献に提示されている方法は、多くの観点において不利であり、適応型ストリーミング方法において満足のいくソリューションを見出すのには適していない。適応型ストリーミング方法は、個々のクライアントに、変動する品質レベルでメディアコンテンツを提供する。当然のことながら、品質は、各クライアントに対して、そのクライアントにとっていずれの帯域幅が現在利用可能であるかに応じて、異なる程度まで変化する。しかしながら、同時に複数のクライアントに対して様々な品質を提供するために、適応型ストリーミング方法は一般的に、プリコーディングされたデータを利用する。例えば、ビデオは複数のタイムスロットに分割され、高度に多様な品質レベルを有するプリコーディングされたバージョンが各タイムスロットに対して作成される。所定のプロトコルが、タイムスロット境界において個々の品質レベル間でスイッチングすることによって、クライアントが変動する品質レベルにおいてビデオをロードすることを可能にする。それらのタイムスロットは、例えば、２〜４秒の長さをもつことができ、チャンクと称されることもある。しかしながら、例えば、主観テストに適合されているITU-T J.247のようなＦＲ品質測定技法は、品質を決定するためにチャンク継続時間よりも長い継続時間、すなわち、いくつかのチャンクにわたって延伸する継続時間を必要とする。したがって、上記ＵＳ文献に記載されている方法を実現するためには、送信機側品質測定は、送信機側において各クライアントについて特定的に実施されなければならなくなり、受信機側にとって、拡張ヘッダを用いて、すなわち、すべてのクライアントについてオンライン及び／又はリアルタイムで利用可能にならなければならなくなる。しかしながら、同時に存在する多くのクライアントを有する多くの用途にとって、そのような手法は、時間及びエネルギーに関して費用が大きいという理由で実現可能でない。
【０００７】
米国特許出願公開第２０１２／０２７８４４１Ａ１号（特許文献２）は、受信機側における品質、すなわち、エンドユーザによって実際に知覚される品質を推定する方法を記載している。その方法について示されている１つの利点は、受信機側において計算能力をほんの少ししか必要とせず、任意の時点において実施されることが可能であると考えられることである。この方法では、特に、メディアデータの転送に影響をあたえるために受信機側測定値を使用することも可能である。このＵＳ文献において提案されている方法は、送信機側で複数の異なる品質レベルにおいてメディアコンテンツを提供することによって開始する。必要である場合、メディアコンテンツを表す署名が送信機側で作成され、その署名は、多かれ少なかれ画像コンテンツ全体に依存し、多かれ少なかれ画像コンテンツを表す。その署名は、少なくとも署名はアーティファクトがないように受信されるように、画像コンテンツとともに受信機側に送信される。受信機側において、その後、取得されたメディアコンテンツから同じように署名が生成され、その後、送信機側から送信されている署名と比較されて、その比較から品質値ＱｏＥが得られる。比較をＱｏＥ値にマッピングするために、継続的に訓練され及び／又は事前に分かっている分類関数が使用される。ここで、ＱｏＥ値は、例えば、「非常に良い（excellent）」、「良い（good）」、「普通（adequate）」、及び「悪い（poor）」のカテゴリで、受信機側の品質を示す。ＱｏＥ値は、受信機側で実際に得られる品質を、送信経路の再ルーティング、再生品質の変更などのような手段を用いて実際に期待されるその品質に適合させるように、送信機側のメディアサーバによって使用されるように受信機側から送信機側に送信し戻されることが可能であると考えられる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】米国特許出願公開第２００９／０１５３６６８号
【特許文献２】米国特許出願公開第米国特許出願公開第２０１２／０２７８４４１号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、より効率的であり、かつ／又は、エンドツーエンド測定の意味での品質知覚に対して決定的なすべての特性の現実的な検出及び評価を可能にする、メディアデータストリームの品質を決定するための概念を提供することである。
【課題を解決するための手段】
【００１０】
この目的は、新たに提出される独立請求項の主題によって達成される。
【００１１】
本発明の中核的な着想は、適応型ストリーミングの状況内でのもののような、メディアコンテンツにわたって変動する品質対ビットレートレベルを有するメディアコンテンツの複数のメディア部分を送信するデータストリーム部分のシーケンスから構成されるメディアデータストリームの品質が、それぞれのデータストリーム部分について各データストリーム部分から識別子が導出される場合に、かつ、各データストリーム部分について、それぞれのデータストリーム部分について導出される識別子によってルックアップテーブルからパラメータセットが検索され、それによって、パラメータセットを集約して、それに基づいて品質を決定することが可能である場合に、より効率的に決定され得ることが分かっているということにある。この手法は、各クライアントのメディアデータストリームを構成しているデータストリーム部分が、経時的に変化する可能性のあるその個々の帯域幅状況に応じて変化しないままであることを可能にし、データストリームには何も追加される必要がない。言い換えれば、メディアデータストリームとともに品質情報を受信機側に送信する必要はない。むしろ、受信機側の各クライアントにおける品質を決定するには、データストリーム部分についてルックアップテーブル内で提供されるパラメータで十分であり、すなわち、それぞれのクライアントに対して選択される品質対ビットレートの変動、及び、さらには、品質が決定され、いくつかのメディア部分が位置するテスト又は分析部分にさえかかわりなく、十分である。この方法では、例えば、品質の決定の基礎として、ITU-T J.247のような、主観テストに適合されている標準的な測定技法を利用することが可能である。
【００１２】
一実施形態によれば、識別子の導出は、例えば、ハッシュ関数をそれぞれのデータストリーム部分の非復号バージョンに適用することによって実施される。これによって、複数の異なる品質のデータストリーム部分、メディアコンテンツの複数の異なるメディア部分、及び、複数の異なるメディアコンテンツ自体の間で効率的に区別することが可能になる。特に、このタイプの識別子導出は本質的に送信における変化から保護される。すなわち、送信アーティファクト及びクライアントへの送信リンクに沿ったコード変換動作は十分に高い確率レベルをもって検索動作の失敗をもたらし、それによって、前もって誤って決定されたパラメータセットが品質の決定に使用される可能性はなくなる。前もって誤って決定されたパラメータセットは、結果的に符号化品質と基本的に相関付けられ得るが、メディアデータストリーム内の後続の変化とは相関付けられ得ない。したがって、識別が非復号バージョンによって、例えば、エレメンタリストリーム（ＥＳ）レベルで実施される場合、検索動作は送信アーティファクト及び／又はコード変換動作を検出することを暗に可能にもする。
【図面の簡単な説明】
【００１３】
【図１】サーバとクライアントを備えているネットワーク環境の概略ブロック図であり、それらのサーバとクライアントの間でメディアデータストリームの送信が、変動する品質対ビットレートで行われ、品質決定概念が一実施形態に従ってその環境内に適用される。
【図２】メディアデータストリーム及びそのメディアデータストリーム内に符号化されているメディアコンテンツ、並びにサーバ側における複数の異なる品質対ビットレートレベルの存在の概略図である。
【図３】一実施形態による品質決定のためのデバイスのブロック図であり、そのデバイスはオフラインで準備されたルックアップテーブルにアクセスする。
【図４】ルックアップテーブルを備えている一実施形態によるサーバの概略ブロック図であり、そのサーバは図３のデバイスと対話することができる。
【図５】一実施形態によるテーブル作成の流れ図である。
【図６】ルックアップテーブルを作成するための一実施形態によるデバイスの可能な実施態様のブロック図である。
【図７】受信機側の品質を決定するための一実施形態によるデバイスの可能な動作モードの流れ図である。
【図８】一実施形態によるパラメータセット決定の流れ図である。
【図９】サーバ側で利用可能なメディア信号の一部分の概略図であり、この信号におけるパラメータセット決定を示すように、基準信号の時間的に対応する部分を有する特定の一定の品質対ビットレートレベルを含んでいる。
【図１０】送信アーティファクトを考慮に入れながら全体的な品質を決定する一実施形態による可能な実施態様の流れ図である。
【図１１】ビットレート適応型メディアデータストリーム送信による一般的なサーバ−クライアントネットワークを示す図である。
【図１２】ＯＴＴ（オーバーザトップ：over-the-top）ストリーミングサービスの全体的なＱｏＥを表し、４つの層によってモデル化されている４層ＯＴＴ品質モデルの概略図であり、各層が担当のインフラストラクチャに含まれるパーティの手になるものである。
【発明を実施するための形態】
【００１４】
本発明の有利な実施態様が、従属請求項の主題を形成する。本出願の好ましい実施形態を、添付の図面を参照して下記により詳細に説明する。
【００１５】
図１はサーバとクライアントを備えた環境を示し、その中に本出願の一実施形態によるメディアデータストリームの品質を決定するための概念が使用されている。特に、図１は図１１に示されているような送信リンクを示し、メディアコンテンツがプリコーディングされて記憶されているメディアデータベース１０と、メディアデータベース１０にアクセスすることができるサーバ１２と、ネットワーク１６を介してサーバ１２に通信可能に接続されているクライアント１４とを備えている。例えば、クライアント１４は、ユーザの端末上で作動するコンピュータプログラム又はアプリケーションである。端末は、例えば、携帯電話、ノートブックなどのような携帯端末であってもよい。ネットワーク１６は有線部分及び／又は無線部分を備えることができる。サーバ１２は、例えば、コンピュータ又はコンピュータネットワークであり、メディアデータベース１０は、例えば、１つもしくは複数のハードディスク又は他の不揮発性メモリを含む。
【００１６】
サーバ１２とクライアント１４との間の通信に関して、サーバ１２は、例えば、メディアデータストリームを、ネットワーク１６を介してクライアント１４に送信する。例として、以下の説明は、メディアデータストリームが、メディアコンテンツとしてビデオを表すビデオデータストリームであると仮定するものとするが、後続の実施形態はオーディオコンテンツ、３Ｄグリッドモデルなどのような、他のメディアコンテンツ又は他のメディアデータストリームに容易に移行することができることに留意されるべきである。例として、図２は、メディアデータストリーム１８及びメディアデータストリームとともに送信されるメディアコンテンツ２０を示し、メディアコンテンツはここでは、すでに言及したように、例としてビデオである。
【００１７】
図２に示すように、メディアデータストリーム１８は、メディアコンテンツ２０の複数の異なるメディア部分２４が、メディアコンテンツにわたって変化する品質対ビットレートで符号化されているデータストリーム部分２２のシーケンスを含む。図２においては一例として時間的に変化するメディア信号の役割を果たすビデオ２０は、図２において、例えば、ビデオの直接相互に隣接する連続したタイムスロットが個々のメディア部分２４を形成するという点において、複数のメディア部分２４に区分化されているものとして示されている。したがって、各メディア部分２４は、ビデオ２０の画像２６のそれぞれのシーケンスを含む。
【００１８】
部分２４が品質対ビットレートをもってデータストリーム部分２２に符号化されており、その品質対ビットレートの変動は、クライアント１４の側においてクライアントにおけるメディアコンテンツ又はビデオ２０のリアルタイムの再生におけるデータストリームバッファのアイドリング、いわゆる「ストール（stall）」を回避するように、また、他方では、バッファの混雑状態を回避するように、例えば適切な基準に従って制御される。適応型ストリーミングはメディアデータストリーム１８のｈｔｔｐベースのストリーミング、例えばＤＡＳＨなど、とすることができ、それに従って、サーバ１２はクライアント１４に、いわゆるＭＰＤ、メディア表現記述を介して、利用可能なダウンロード可能品質対ビットレートレベルに関する情報を提供する。そのレベルに基づいて、クライアント１４内に位置する調整モジュールが、サーバ１２からクライアント１４までの効率的に利用可能な送信帯域幅にわたって行われる推定に応じて、かつクライアント１４における現在のバッファ利用レベルに応じて、利用可能なレベルの間で選択を実施し変更することができる。
【００１９】
図２に示すように、メディアデータベース１０は、例えば、各メディア部分２４の各々の複数の品質対ビットレートレベルＱ1〜Ｑ4の各々について、内部に記憶されているデータストリーム部分を有する。それらのデータストリーム部分は、図２において長方形２８によって示されている。したがって、実際にクライアント１４に出力されるメディアデータストリーム１８はデータストリーム部分２２のシーケンス又はストリームから構成され、各データストリーム部分２２は、異なる１つのメディア部分２４と関連付けられ、かつ記憶されているデータストリーム部分２８のうちのそのメディア部分２４にとって利用可能な１つに対応する。例として、図２は、メディア部分２４がメディアデータストリーム１８内において時間ｔ0、ｔ1、ｔ2及びｔ3の間が品質レベルＱ1、Ｑ3及びＱ2で送信されることを示しているが、上述したように、この選択は個々のクライアント１４に関する状況に応じて決まる。図２は、矢印３０によって、状況に応じた品質対ビットレート調整を示している。すでに説明したように、この調整は、例えば、クライアント１４によって実行することができる。
【００２０】
クライアント１４において又はサーバ１２とクライアント１４との間の送信リンクに沿った異なる箇所においてメディアデータストリームの品質を決定するように、下記に説明する品質を決定する概念は、デバイス３２がデータストリーム部分２２から識別子を導出して、それに基づいてルックアップテーブル３４において検索してデータストリーム部分２２のパラメータセットを得て、１つ又は複数のテスト部分又は分析部分のためにそれらのパラメータセットを集約し、それから品質を決定することを可能にする。本明細書から明らかになるように、メディアデータベース１０内に記憶されているデータストリーム部分２８はこの目的のために変更される必要はなく、これによって、既存のメディアサーバインフラストラクチャ内に品質決定概念を導入することがより容易になる。その上、サーバ−クライアント通信に他の情報をさらに導入する必要はない。通信は影響されないままである。ルックアップテーブル３４の内容は、テーブル３６を作成することによって前もってオフラインで生成され、これによって、デバイス３２の部分において品質を決定するのに関連する労力は手頃に低く保たれる。それにもかかわらず、下記により詳細に説明する品質決定のための概念は、特にデータストリーム部分ｉ（２２）のシーケンスの変動する品質レベルＱiにかかわらず、主観的品質テスト方法、例えば、特定のテスト部分もしくは分析部分又は例えばいくつかのメディア部分２４に及ぶ所定の時間間隔にわたる品質決定など、に適合されるための必要条件を構成する形態での品質決定を可能にする。
【００２１】
これまで言及してきたメディア部分２４は実際には異なる意味を有し、単純にするためにのみ同一であるように記載されており、例えば、ＧＯＰのような、互いから別個のメディアデータストリーム内に符号化されているメディア部分、及び、そのパラメータセットが各事例においてテーブル３４内に存在するメディア部分があることが留意されるべきである。例えば、前者のＧＯＰ、すなわち、画像シーケンスは、ＩＰＰＰ  …  ＰＰ画像シーケンスなどのように、互いから独立して復号可能である。そのようなメディアコンテンツの単位において、メディアデータストリーム１８は、例えば、レベルＱ1〜Ｑ4にあるその品質対ビットレートを変更し得る。そのような各メディア部分２４について、識別子が生成され得る、すなわち、品質対ビットレートの変動の粒度は、識別子生成の粒度と同一になり得る。しかしながら、これは必ずしもそうである必要はない。以下の説明は、識別子生成が相対的に小さい単位で、例えば、各画像２６に対してのように、行われ得ることを明瞭に示す。参照符号２４’を有するメディア部分は、それぞれの識別子を有するそれぞれのデータストリーム部分と関連付けられているようなメディアコンテンツ２０の部分と常に関係する。ＧＯＰ、すなわち、他のＧＯＰとは別個に復号することができる自己完結型の画像シーケンスについては、特に各品質対ビットレートレベルに関して、いくつかの識別情報を含むいくつかのメディア部分２４’、すなわちいくつかの画像、が存在することになる。データストリーム部分２２は、常に、そのメディア部分２４’と関連付けられることになる。対照的に、アポストロフィのないメディア部分２４は、例えば、ＧＯＰのように、その単位においてビットレートが変動し得るような部分を示す。すでに言及したように、両方の単位／部分は一致し得るが、必ずしもそうである必要はなく、後続の実施形態によれば、たとえそれらの単位／部分がこの観点において、すなわち、１つの画像よりも大きいがＧＯＰよりは小さいすべての中間形態、例えば、部分２４’によって容易に可変であり得るとしても、これは実際にはそうではない。したがって、図２においてまた、部分２４について、すなわち、Ｎ個の品質レベル及び部分２４’となる部分２４のＭ個の下位区分について、データベース内にＭ＊Ｎ個のデータストリーム部分も存在し得る。
【００２２】
次に、デバイス３２、又は、ルックアップテーブル３４を備えているサーバ３８の可能な設定について、図３及び図４を参照して説明する。
【００２３】
図３に示すように、デバイス３２は、識別子生成器４０と、検索ユニット４２と、集約器４４と、品質決定器４６とを含む。図３に示すように、要素４０〜４６は直列に接続することができ、識別子生成器４０はメディアデータストリーム１８を受信し、品質決定器４６はメディアデータストリームの品質４８を出力する。
【００２４】
識別子生成器４０は、入来するメディアデータストリーム１８の各データストリーム部分２２からそれぞれの部分２４’に対する識別子５０を導出する。検索ユニット４２は、入来するメディアデータストリーム１８のデータストリーム部分２２に対する識別子５０を取得する。検索ユニットは、各データストリーム部分２２についてサーバ３８のルックアップテーブル３４内で検索して、各データストリーム部分２２のパラメータセット５２を取得し、検索ユニット４２は、例えば、対応するクエリー５４をサーバ３８に送信し、応答５６として、それぞれのクエリー内に含まれる識別子に関連するパラメータセットを取得するという点で、データストリーム部分２２について導出された識別子５０を用いて検索動作を実施する。データストリーム部分２２のパラメータセットは、下記により詳細に記載するものとする。簡潔には、パラメータセットは、部分２４’ごとに、例えば、それぞれのメディアデータストリーム部分２２内に符号化されているそれぞれのメディアコンテンツ２４’内の画像２６ごとに、それぞれの画像２６の符号化品質、より正確に言えば、干渉のない送信の場合にその画像２６の再生品質を記述するいくつかのパラメータを含む測定パラメータであり、パラメータは、例として、符号化干渉が一切ないメディアコンテンツの品質、すなわち、元のメディアコンテンツの品質を記述する、部分２４’ごとの１つ又は複数のパラメータを含むことも可能である。以下の説明において、さらなる詳細が与えられるものとするが、すでに言及したように、本出願及び下記に説明する実施形態はビデオには限定されないことが留意されるべきである。例えば、メディア部分２４はまた、オーディオ信号の連続した時間間隔、又は、時間的に変化するグリッドモデルのタイムスロットなどでもあり得る。一般的に、関連付けられるデータストリーム部分２２のパラメータセットは、符号化品質、すなわち、メディア部分２４’の逸脱を記述し、そのメディア部分２４’は、データストリーム部分２２から再生可能であり、損失の多い符号化によっては導入されない元の符号化エラー、及び、任意選択的に、全体的なメディアコンテンツ２４’の品質を含む。
【００２５】
集約器４４は、所望のテスト部分又は分析部分のためのパラメータセット５２を集約する。テスト部分は、例えば、一連のメディア部分２４、及び、したがって、一連の部分２４’にわたって延伸する。図２に関して、テスト部分は、例えば、時間ｔ0〜時間ｔ6まで延伸し得る。テスト間隔の長さは、特定の最小持続時間、連続性、すなわち、時間の空白がないこと等に関する基準のような、対応する主観的ＦＲ品質テスト方法の必要とされる基準を満たす。したがって、集約器４４は、例えば、図２におけるｔ0〜ｔ6のような、メディア信号のテスト部分内に位置するメディア部分２４’を送信するデータストリーム部分２２に対して検索されたパラメータセット５２の集約５８を出力する。上記の説明から明らかになっているように、集約パラメータセット５２は、複数の異なる品質レベルに由来し得る。
【００２６】
したがって、品質決定器４６は、複数の集約５８、すなわち、メディアコンテンツ２０の対応するテスト部分内に位置するメディア部分２４’の全てに対するものを取得し、上記パラメータセット５２の集約５８に基づいて、品質決定器は品質４８を決定し、これに関する詳細は下記により詳細に説明する。
【００２７】
完全を期すためにのみ、図４は、ルックアップテーブル３４を含む図１のサーバ３８を示す。メディアデータベース１０内の各データストリーム部分２８について、ルックアップテーブル３４は、エラーのない送信の場合に識別子生成器４０によってデータストリーム１８の部分２２として生成されているような、識別子６０を内部に記憶しており、かつ、そのデータストリーム部分と関連付けられるか又はそのデータストリーム部分２８と関連付けられるメディア部分２４’から生成されているパラメータセット６２を内部に記憶している。図４に示すように、各パラメータセット６２は、例えば、Ｎ個の異なるパラメータを備え得る。パラメータセット６２は、各事例において、メディア部分２４、すなわち、例えば画像２６に関係し、いくつかのメディア部分２４’はメディア部分２４内に位置し得、その単位において、クライアントはフェッチされるビットレート及び／又は品質に関して変化させる。サーバ３８はクエリー応答器６４を含み、クエリー応答器６４はルックアップテーブル３４に接続されており、デバイス３２から入来し特定の識別子を含むクエリー５４に対して、このパラメータセット６２を返信５６においてデバイス３２に返すように、テーブル３４内でこの識別子のために記憶されているこのパラメータセットによって応答するように構成されている。
【００２８】
デバイス３２とサーバ３８との間の通信５４及び５６も、ネットワーク１６を介して、例えば、インターネット接続などを介して行なうことができる。サーバ３８は、サーバ１２及びメディアデータベース１０とは別個の、それ自体のサーバとすることができる。ルックアップテーブル３４は、例えば、不揮発性メモリ内で具現化することができ、クエリー応答器６４は、例えば、コンピュータ又はコンピュータネットワークによって実装することができる。デバイス３２は、クライアント１４も実行されているそのモバイルデバイス上で実行されるアプリケーションであってもよいが、無論、デバイス３２の異なる構成及び実施態様も可能である。
【００２９】
上記の説明からすでに明らかになっているように、データストリーム部分から取得される識別子によってパラメータセットを検索する手法の利点は、パラメータセット決定、及び、したがって、ルックアップテーブル３４の設定、すなわち、テーブル生成３６を、オフラインで前もって、すなわち、クライアント１４へのメディアストリーム送信が実際に行われる前に実施することができることにある。完全を期すためにのみ、次に、図５はテーブル生成３６の１つの可能性を示す。この可能性によれば、メディアデータベース１０内の各データストリーム部分２８について、識別子生成６６が、特に妨害のない送信の場合に識別子生成器４０を用いて生じるのと同じ識別子が結果として生じるように実施され、かつパラメータセット決定６８が実施される。
【００３０】
これまでで、品質決定概念に関与する要素の概説が図１及び図５を参照して与えられたので、例えば、要素のこの概念又は相互作用、がどのように実施され得るかの説明を例として、具体的な用語で下記に与えるものとする。これに関して、比較的に特定的な説明が、例えば、パラメータセットに関連して与えられるが、この説明は上述した他の要素に関連しても与えられ、それらの具体化の可能性のすべては、上記の以前の実施態様に個々に適用可能であることが理解されるべきである。これが、下記において図１から図５が繰り返し参照される理由であり、可能であるかぎり図１から図５の説明に使用されている参照符号が再使用される。
【００３１】
本出願の説明に対する導入部において説明したように、メディアデータ転送における重要な質問は、最終的なユーザの元に実際に届くメディアデータの品質のタイプに関するものである。以前の図面に関連してすでに大まかに説明したように、この決定は、前もって取得されるパラメータにアクセスすることによって行うことができる。図１に記載されているように、これに関与するものは、メディアデータベース１０を分析するテーブル生成モジュール３６、メディアデータベース１０から計算されるパラメータセットを記憶するためのデータベースを提供するルックアップテーブル３４、及びデバイス３２、すなわち、現在の品質を計算するために、例えばクライアント側で利用されるデバイスである。
【００３２】
最終的なユーザ又はクライアント１４におけるメディアデータの全体的な品質の評価において、原則として、以下の２つの外乱パターンが留意されるべきである。
１）符号化品質。これは、とりわけ、使用される符号化方法、及び平均ビットレートのような使用される設定に依存する。及び、
２）送信品質。これは送信チャネルにおける現在の外乱を記述するものである。送信品質は、パケット損失、ビットエラーなどのような外乱を考慮に入れる。
【００３３】
これまでの図１〜図５の以前の説明は、実際には符号化品質のみに対処している。例えば、説明したような識別子生成が例として非復号領域内で行われるとき、それによって、欠陥のあるデータストリーム部分は検出可能に欠陥のある識別子をもたらすことがすでに十分に保証されている。というのは、例えば、各事例において関連付けられるメディア部分２４について、欠陥のあるデータストリーム部分は、現在のメディアコンテンツ２０のそのメディア部分２４のルックアップテーブル３４内に記憶されているデータストリーム部分２８のいずれとも一致しないからである。下記に説明するように、品質決定器４６が、パラメータセット５２の対応する集約５８から１つ又は複数のテスト部分について決定されるとともに符号化品質を反映する品質と、品質外乱の量に関する推定とを組み合わせて、全体的な品質を取得することが可能である。
【００３４】
信号の全体的な品質を、符号化品質及び送信品質の規定の部分領域に分解することによって、客観的な方法で、品質予測に必要とされる計算能力を最適化することが可能になる。ここで、符号化品質は、送信チャネル内の現在の外乱には依存しないことが留意されるべきである。それゆえ、原則として、複数の異なる入力シーケンス及び符号化設定について、すなわち、テスト部分全体にわたって、前もって符号化品質を完全に計算することが可能である。しかしながら、本出願の説明に対する導入部において説明したように、ビットレートが、テスト部分よりも小さい時間単位においてクライアントごとに個々に変動するというだけの理由で、これは困難である。言い換えれば、符号化設定は、送信チャネルの現在の状態に応じて絶えず変化する。加えて、全体的な品質は、上記で言及した品質レベルの間で線形に連結するというだけのものではない。それゆえ、上記において「パラメータ」と称されており、下記において「インジケータ」と称されることがあるベンチマークデータを前もって決定し、実際の送信特性に応じて品質を推定するためにこのデータを使用することが、より意味のあるものなっている。
【００３５】
図６は、ビデオの例をメディアコンテンツとして使用することによって、メディア送信のためのパラメータセットを前もって決定するためのデバイス、すなわち、テーブル生成３６を実施するのに適しているデバイスを示す。
【００３６】
見て分かるように、図６のデバイスは、復号器７０、分割器７２、評価器７４、識別子決定器７６、ならびに、基準メディアコンテンツ、ここでは特に基準ビデオを受信するための入力７８、一定の品質対ビットレートレベルでメディアデータストリームを受信するための入力８０、及び、ルックアップテーブル３４のデータベースエントリ又はルックアップテーブルエントリ、すなわち、識別子６０と、関連付けられるパラメータセット６２との対を出力するための出力８２を含む。分割器７２は、３つの入力、すなわち、入力７８に接続されている入力と、入力８０に直に接続されているさらなる入力と、入力８０におけるメディアデータストリームの復号された又は再生可能なバージョンを取得するように復号器７０を介して入力８０に接続されている第３の入力とを備え、当該メディアデータストリームは、例えば、テストビデオが復号器７０の出力に又は分割器７２の入力に存在するように、図６に示すように、例えば、Ｈ.２６４を用いて符号化することができる。分割器７２は、入来する基準ビデオ、入来するテストビデオ、及び入来するメディアデータストリームを、基本的にそれらのサイズに関して以前に言及したテスト部分に対応する視聴期間に分割し、各視聴期間について、入力８０におけるメディアデータストリームの対応するデータストリーム部分２２を識別子決定器７６に転送し、それぞれの視聴期間内にあるテストビデオからのフレーム２６のようなメディア部分２４’、及び、基準ビデオからの対応する部分、例えば、画像を評価器７４に転送する。単純にするために、視聴期間への分割はいかなる空白もなしに行われることが下記において仮定されるので視聴期間が互いにシームレスに隣接するが、そうでない場合も実現可能である。
【００３７】
識別子決定器７６は、上述したものと同じように、かつ／又は、デバイス３２内の識別子生成器４０によって行われるものと同じマッピングを用いて、入力するデータストリーム部分２２のすべての識別子を決定する。識別子生成器はハッシュ値形成を含み得るが、識別子はまた、識別性の理由で、ハッシュ値と、例えば、メディアライブラリ１０内の個々のメディアコンテンツに割り当てられているさらなるＩＤとの合成でもあり得ることに注意すべきである。
【００３８】
評価器７４内の評価は、下記により詳細に説明するように行われ、各メディア部分２４’について、各視聴期間から、対応するメディアコンテンツ２４’が符号化されているデータストリーム部分２２から取得されている識別子と関連付けられている対応するパラメータセットをもたらす。
【００３９】
たった今説明したプロセスは、基準ビデオが入力７８に存在していかなる符号化損失もなくメディアコンテンツを表している間、対応するメディアデータストリーム１８が入力８０に与えられるという状況において、メディアデータベース１０内に存在するそれぞれのメディアコンテンツ又はビデオ２０の品質対ビットレートレベルの各々について繰り返される。品質対ビットレートレベルは各時点において一定のままである。より具体的には、入力８０におけるメディアデータストリーム１８のデータストリーム部分２２は各時点において、すべてのデータストリーム部分２２について同一である品質対ビットレートレベルにおいて関連付けられるメディア部分２４’を表し、このレベルは、連続する時点の間で変化させられる。このように、識別子と、関連付けられるパラメータセットとの対は、すでに説明したように、メディアコンテンツ２０の各メディア部分２４’の各品質対ビットレートレベルについて、ルックアップテーブルをもたらす。
【００４０】
したがって、原則として、図６の評価器７４は図５のパラメータセット決定６４を採用し、識別子決定器７６は図５の識別子生成６６を採用する。分割器７２は、図６の実施形態においては、パラメータセットを取得するために評価器７４によって実施される評価と相関する視聴期間への分割を実施する。視聴期間は、デバイス３２内の品質決定器４６によるテスト部分の選択に使用されるものと同じ基準を満たすことができるような期間である。したがって、視聴期間は、例えば、いくつかのメディア部分２４にわたって延伸し得る。それにもかかわらず、評価器７４は、視聴期間の評価から、現在の視聴期間内にあるメディア部分２４’ごとにパラメータセットを生成する。
【００４１】
それゆえ、より具体的には、基準ビデオ、それぞれの一定の品質対ビットレートレベルを含む送信されるべきメディアデータストリーム、及びメディアデータストリームから復号されるテストビデオは、それらの元の長さにおいて、図６のデバイスに対する入力として役割を果たす。評価器７４は、主観テストをマッピングするように、例えば、ＩＴＵ−Ｔ  Ｊ．２４７又はＩＴＵ−Ｔ  Ｊ．３４１のような客観的テスト方法を使用することができる。そのような客観的テスト方法は、そのようなテストに使用される画像シーケンスに対して適合される。そのような画像シーケンス又はそのような視聴期間の持続時間は、各場合を含めて、例えば、１０〜１６秒、又は６〜２０秒である。このように、分割器７２は、例えば、基準ビデオ、テストビデオ及び入来するメディアデータストリームをそのような視聴期間に分割し、このように分割されている基準ビデオ及びテストビデオを評価器７４に転送する。評価器７４内で実施される客観的測定技法の中で、パラメータ又はインジケータ、すなわち、パラメータセットがその後、視聴期間７２内の各メディア部分２４’について、例えば、それぞれの視聴期間７２内の各画像２６について決定される。パラメータセットを抽出するために利用される可能性があり得る方法を、以下より詳細に説明する。また以下、パラメータ又はインジケータも説明する。
【００４２】
例えば、分割器７２によって基準ビデオ及びテストビデオが分割される視聴期間の評価において、各画像のような各部分２４’についてパラメータセットがもたらされるように、識別子決定器７６は、各メディア部分２４’について、例えば、各画像２６について、それぞれのデータストリーム部分２２から識別子を決定する。識別子は下記において識別要素とも称される。識別要素は、ビットストリーム１８内で符号化されている部分２４’とデータベースエントリとの精密な関連付けが後の時点において可能であるように、部分２４’に関連して計算される。識別要素として、例えば、明確に決定されるべきＭＤ５和又は異なる「ハッシュ（HASH）」和を使用することができる。
【００４３】
上記ですでに説明したように、インジケータ又はパラメータセットはその後「ハッシュ」和とともに、さらに、任意ではあるが可能性としては、例えば画像形状に関する情報のようなさらなる制御要素とともに、データベース内に記憶される。したがって、符号化品質を決定するために必要などのような情報も、複数のビデオシーケンス及びフレームレベルでの符号化設定についてデータベース３４内で利用できる。
【００４４】
図７は、現在送信されている信号又はクライアント１４に送信されているメディアデータストリーム１８の全体的な品質を推定する方法を示す。この方法は、デバイス３２、例えば図３のデバイスによって実施されるが、図３の機能は、下記に説明するように、図７の方法を実施するために補完されている。すでに述べたように、たとえ説明がビデオ以外のメディアコンテンツにも容易に転用することができるとしても、説明はビデオストリームについて示されている。
【００４５】
図７に示すように、入来するメディアデータストリーム１８は最初にデータストリーム分析８６を受け、データストリーム１８は、すでに述べたように、例えば受信機に、又は一般的に言えばクライアント１４のような受信機側に到来するものである。メディアデータストリーム１８を取得するために、データは例えばネットワークカードから取り出されてもよい。データストリーム分析８６において、ビデオ関連データ又はここでは例としてビデオデータストリームであるメディアデータストリーム１８が、パケット損失、ビットエラー、時間遅延、パケット反復などのような送信アーティファクトについて分析される。その分析は、例えば、識別子生成器４０と並列に接続され、かつ／又は、メディアデータストリーム１８も取得する送信アーティファクト分析器又は検出器１８６内で実施することができる。その分析結果に基づいて、その後、送信リンクの外乱を記述する現在の送信品質がステップ８８において推定できる。それと同時に、データストリーム要素２２のシーケンスが、入来するメディアデータストリーム１８から、すなわち、例えば、画像レベルにおいてなどの画像部分２４’ごとに又は各ビデオフレームについて抽出される。データストリーム要素２２のシーケンスは例えばＨ.２６４ビットストリームを表し、それを用いて識別子又は識別要素が計算される。識別子決定９０が、例えば、識別子生成器４０によって実施される。すでに述べたように、ステップ６６において又は識別子決定器７６においてデータベースを生成するために利用されるものと同じアルゴリズム又は同じマッピングが、ステップ９０において計算される識別要素に利用される。それゆえ、送信外乱に起因して「ハッシュ」値又は識別子を決定することができない場合、画像部分２４’とルックアップテーブル３４内のエントリとの明確な関連付けを行うことができ、このステップは、図７においてデータベース検索９２と称され、図３内の検索ユニット４２によって実施されるステップである。各画像部分２４’例えば画像２６について検索されるインジケータ又はパラメータセットは、その後、現在の符号化品質の計算、すなわち、符号化品質推定のステップ９４に使用される。このステップ９４は、図３の集約器４４及び品質決定器４６によって実施される。このための唯一の必要条件は、デバイス３２が、すでに確立されているデータベース３４にアクセスできることである。これは、例えば、損失のないデータラインによって、又は前もってすでに送信されているデータベース３４によって保証することができる。符号化品質推定９４のプロセスのより詳細な説明は下記で行う。
【００４６】
この点において留意すべきことは、これまで説明した実施形態は、例えばＨＬＳ（ＨＴＴＰライブストリーミング：HTTP Live Streaming）のような最新のストリーミング方法もサポートするということである。
【００４７】
ステップ９６は、ステップ８８の推定送信品質とステップ９４の推定符号化品質に基づいて最終的に全体的な品質を推定することを含む。このステップは、例えば図３の品質決定器４６によって、送信品質推定８８ができるように実施することもできる。
【００４８】
したがって、上記の実施形態は、適応型ストリーミング方法が既存の送信チャネル容量に応じて複数の異なる符号化品質を利用する課題を解決する。符号化品質は、送信チャネル特性が変化する場合は、送信中に変更することさえできる。フレームレベルにおける任意の数の品質組み合わせを記憶するルックアップテーブル３４の利用によって、上記の実施形態に従って適切なインジケータを常に抽出することができる。
【００４９】
パラメータセット決定器６４又は評価器７４がどのように構成され得るかのより詳細な説明は下記に述べる。すでに説明したように、実際に良好な品質予測をもたらすことがすでに証明されている確立された標準的な測定技法を、インジケータ又はパラメータセットの抽出に使用することができる。例えば、ＩＴＵ−Ｔ  Ｊ．２４７の名称でＩＴＵによって標準化されている方法を使用することができる。完全を期すために、他の非標準的な方法又はＮＲ方法もパラメータセットを取得するために使用することができるが、それは一般的に、測定精度に関して損失を伴うことにも注意すべきである。
【００５０】
図８は、特に図６の評価器７４によって実施され得る可能なステップシーケンスの一例を示し、評価器７４が、視聴期間についてのパラメータセットを決定するために、復号によって受信メディアデータストリーム１８から取得されるテストビデオと、関連付けられる基準ビデオの両方を取得することが仮定されている。しかしながら、以下の説明は、パラメータセットを生成するとき視聴期間に分割することが絶対に強制されるというものではないことを示す。視聴期間への分割は、パラメータセットを生成するための十分に標準化された測定技法を使用することをより容易にするに過ぎない。
【００５１】
入力パラメータとして、視聴期間に分割されている基準ビデオからの時間部分、ならびに、評価対象であり、符号化外乱を呈する可能性があるビデオに由来する対応する時間部分が、図８のパラメータセット抽出方法に与えられる。時間的視聴期間及び／又はテスト部分の持続時間は、客観的測定技法の評価のもとになる主観テストの一般的な持続時間と、可能性のある品質切替え部分２４が指定されるストリーミング方法の要件との両方に応じて決まり得る。例えば、ＨＬＳ方法において、転送部分２４は、理想的には上記長さの整数倍が選択されるように、個々のファイルとして存在する。一般的な値は、各場合を含めて、例えば、４〜１４秒又は２〜２５秒の部分長である。
【００５２】
視聴期間に対応する基準ビデオの部分とテストビデオの部分との間に時間的なずれはないことが保証されている。必要なら、フレームを時間的に関連付けるためのアルゴリズムが利用される。
【００５３】
準備１００、すなわち第１のステップにおいて、個々の部分が読み込まれ、内部画像表現に変換される。このステップは任意であり、画像表現変換が必要とされない場合には省略してもよい。
【００５４】
信号分析１０２において、個々のビデオ部分、すなわち、それぞれの視聴期間又はそれぞれのテスト部分が分析され、画像レベルで特性化される。ここでは画像シーケンス分析が行われ、変化する画像シーケンス及び個々の静止フレーム部分が認識される。このブロックにおいて、元のビデオとテストビデオが別個に分析される。
【００５５】
後続のステップ１０４は、色マッチングを実施することを含む。このステップは、個々のグレースケール及び色成分のヒストグラム分析を含み、その後、元のビデオとテストビデオとの間の分布が適合される。わずかに異なるシステム色表示（色表現）及びシステム歪みは、一般的には観察者によってほとんど認識することができないため、ここで取り除かれる。除去する結果として、後続のインジケータ分析１０６が、この欠陥のある色表示（誤った色表現）及び歪みに反応しなくなる。
【００５６】
特に、インジケータ分析１０６は、品質評価に関連する外乱要素のセット、すなわちパラメータセットを抽出することを含む。パラメータセットの計算は、テストビデオ内で、各事例において、部分２４’について、すなわち例えば各事例における画像について実施され、それによって、各フレームについてパラメータセットが利用可能になる。すでに述べたように、メディア部分２４’が１つだけのフレームよりも大きくなる別の例も実現可能である。パラメータ又はインジケータの特性は下記に詳細に説明される。
【００５７】
上述したように、パラメータ又はインジケータのセット６２は、その後、特にそれぞれの識別子６０とともに又はそれと関連付けられて、データベース又はルックアップテーブル３４内に記憶される。それぞれの識別子６０は、データストリーム部分２２から取得されたものであり、それぞれのメディア部分２４’、例えば、ここでは個々の画像、を符号化された形態で含み、セット６２はメディア部分２４’について決定されている。図８に示すように、そのセット６２のインジケータは、後の時点において後処理するために、制御要素とともにバッファリングすることが可能である。そのような制御要素の例は上記ですでに述べた。データベース又はルックアップテーブル３４の設定は、この時点では自由に選択可能であり、サイズならびに既存のソフトウェア及びハードウェアの要件に応じて決まる。ここで利用することができるデータベースの一例として、ＭｙＳＱＬを挙げることができる。識別子を生成することによって、関連するパラメータ又はパラメータセット６２だけでなく、識別子６０、画像又はフレーム、すなわち、テストビデオ内のメディア部分２４’の間の明確な関連付けが保証されることは言及する価値がある。セット６２の個々のインジケータ値は、例えば、ＩＥＥＥ浮動小数点数として利用できることも留意されるべきである。Ｊ．２４７がパラメータの生成に使用される場合、データベースエントリ８２は、例えば、セット６２の６つのパラメータ、１つの識別子６０、及び、任意ではあるが１つの制御要素から構成することができる。
【００５８】
以前の実施形態についてパラメータがどのように選択され得るか、すなわち、それらのパラメータがいずれの次元を有し得るか、それらがどのように生成されるかなどの可能性は、下記において検討する。しかしながら、以下の説明は例示に過ぎず、無論、変動の可能性があることに留意されるべきである。同じく上記ですでに述べたように、例として、以下の説明において、パラメータセットが、個々の画像又はフレーム２６に対応するメディア部分２４’について決定されることが仮定される。Ｊ．２４７を使用し、又はそれに従いながら、計算が実施される。しかしながら、テストビデオ内の各フレーム、すなわちメディアコンテンツの再構成されたバージョン、についてどのようにパラメータが計算されるかについての概要のみが下記において与えられる。詳細な数学的説明については、さらに、参照により本明細書に組み込まれるrecommendation  ＩＴＵ−Ｔ  Ｊ．２４７、特にチャプタＢ．１．１０も参照されたい。
【００５９】
後述する実施形態によれば、それゆえ、以下の分析、すなわち、以下の１つ、いくつか又はすべてが図１のテーブル生成３６において、インジケータ分析１０６において、又は評価器７４によって実施される。
【００６０】
類似度分析
類似度分析に関し、例えば、この事例における、つまり一例としての各画像２６やビデオ２０の各メディア部分２４’の再構成されたバージョンと、基準ビデオ１２０の対応する部分１２４’との間の類似度の相関ベースの尺度が決定される。読者には再び、分析が一般的にオフラインで行われることを想起されたい。ビデオ２０は、符号化によって、一定の品質対ビットレートレベルを有するデータストリーム部分のシーケンスから構成されるメディアデータストリームに由来するものである。本発明の実施形態において、メディア部分２４’は個々のフレームであるため、したがって、類似度分析は、テストビデオ２０の画像２６を、符号化損失によって損なわれていない基準ビデオ１２０の時間的に対応する画像１２６と比較する。テストビデオ２０と基準ビデオ１２０内の画像２６又は１２６の時系列を示すために、それらのビデオの２つの連続する画像を図９に示し、例としてインデックス１と２によって区別する。相関ベースの尺度を計算するために、複数の異なる画像部分における画像領域にわたって、例えば画像２６1と１２６1との間の相関が決定され、局所的に取得された相関の適切な平均に基づいて相関ベースの尺度が決定される。したがって、例えば、テストビデオ２０からの、特にテスト部分からの画像２６1と基準ビデオ１２０の時間的に対応する画像１２６1が個々の画像領域１３０に分割され、基準ビデオとテストビデオとの間のこれらの領域１３０における相関が決定され、例えば、平均相関値が類似度尺度及び／又は相関ベースの尺度として決定されて、パラメータの１つが取得される。画像の領域構造における外乱が、このインジケータ又はパラメータを用いて特に強調される。類似度分析は、テスト部分又は視聴期間内で、各メディア部分２４’、すなわちここでは各フレーム２６について決定される。
【００６１】
エッジ分析
エッジ分析は、各画像２６及び／又は各メディア部分２４’について、それぞれの画像２６内に存在するエッジと対応する画像１２６内に存在するエッジとの間の差の尺度をもたらす。それらのエッジは、例えば、画像２６及び１２６の輝度面内で、及び／又は輝度成分から決定される。区別する基準として、例えば、画像２６及び１２６から取得される対応するエッジ画像の単なる減算が使用される。エッジ差分の１つの尺度を達成するために、画像領域にわたる適切な平均化を再使用することができる。平均化は、例えばＬ５ノルムに基づくことができる。言い換えれば、エッジ分析は、基準画像とテスト画像の輝度面内のエッジ画像を比較し、それらを差分について調査することを含む。インジケータ値を決定するために、外乱の平均化が、例えば、重み付きＬ５ノルムによって実施される。画像を見るとき、目はエッジによって方向付けられることが多い。それゆえ、エッジ外乱は特にはっきりと知覚される。
【００６２】
ブロック分析
ブロック分析はテスト部分内の各画像２６及び／又はメディア部分２４’におけるブロック外乱の尺度をもたらす。ブロック形成は、最新の「コーデック」によって生じる高頻度のエラーカテゴリである。この外乱は、「ブロック歪み（blockiness）」又は「タイリング（tiling）」と称されることもある。このエラーは、エッジ分析と同様に計算される。しかしながら、この値については、元の画像１２６と比較してテスト画像２６において追加されているエッジのみが評価される。例えば、ブロック外乱の尺度を達成するように、ここで重み付きＬ２ノルムを用いて局所平均化を実行することができる。他の分析、すなわち、類似度分析及びエッジ分析ならびに後続の分析と同様に、ブロック分析は、視聴期間及び／又はテスト部分内の各画像２６について実施される。
【００６３】
色度（chrominance）分析
色度分析はそれぞれの画像２６と対応する元の画像１２６内の色度平面の差の尺度をもたらす。この尺度及び／又はインジケータの値は、画像の色度平面の差に基づく。その結果、インジケータ値を決定するための元の画像とテスト画像との間の正規化画像点の、例えば差分の加重平均がもたらされる。
【００６４】
外乱の時間的経過の分析
外乱の時間的経過の分析は、テストビデオ２０の画像２６内に存在するエッジの時間的変化と、基準ビデオ１２０の対応する画像１２６内に存在するエッジの時間的変化との差の尺度をもたらす。テストビデオ２０の画像２６2のエッジの時間的変化が決定されるのは、例えば、この画像２６2及び時間的に先行する画像２６1のエッジ画像が最初に、ここでも輝度レベル内などで決定され、かつこれら２つの時間的に連続するエッジ画像の差が、基準ビデオ１２０において時間的に対応する画像１２６1と１２６2から取得されたエッジ画像の対応する差と比較されるからである。他の分析オプションと同様に、エッジ画像は、例えば、対応するハイパスフィルタリングによっても決定される。これらの時間的変化の差の尺度を達成するために、適切な局所平均化を再使用することができる。外乱の時間的経過の分析に対する背景には、時間的変化を呈する予期せぬ外乱が観察者によって非常に悩ましいものとして知覚されるということがある。この外乱カテゴリを評価するために、基準ビデオとテストビデオのエッジ画像の時間的変化が、発生したときにログ記録される。ここで計算されるインジケータは、基準画像１２６とテスト画像２６との間の、現在の画像又はフレームに関するエッジ画像の変化の差を記述するものである。観察者は外乱が加わっているか又は一部分が除去されているかに応じて別様に反応するため、このカテゴリについて２つのインジケータ又はパラメータを計算することができる。すなわち、ここでの局所平均化が、外乱が加わっている場合には重み付きＬ５ノルムを用いて、部分が失われている場合には重み付きＬ２ノルムを用いて実施される。しかしながら、これらは例に過ぎず、結局のところ、そこから逸脱が生じる可能性があり得る。
【００６５】
上記の分析及び結果的にもたらされるパラメータのすべてが組み込まれる場合、６個のパラメータが各パラメータセット６２をもたらす。これら６個のパラメータは、そのパラメータセット６２に属するものとしてテーブル３４に記憶されている識別子と明確に関連付けられているデータストリーム部分からの結果として、それぞれのメディア部分、ここではそれぞれの画像を記述するものである。
【００６６】
続いて、品質決定器４６又は符号化品質推定９４による品質決定の可能な実施態様の詳細を説明する。上記で概説したように、画像面内の、例えば、すなわち単一画像サイズのメディア部分２４’についてのインジケータ及び／又はパラメータをデータベース３４内に記憶することによって、後の時点において、デバイス３２内で、受信機側で取得されるビデオシーケンスの部分、すなわち、テスト部分及び／又は視聴期間についての品質を計算することが可能になる。それゆえ、下記において、受信機側における符号化品質推定を実施するデバイス３２のより詳細な説明を行う。デバイス３２は、個々のインジケータ及び／又はパラメータにのみアクセスすればよい。上述したように、上記アクセスのために、そのデバイスは識別要素又は識別子を使用する。すべての画像及びすべての品質レベルに関するエントリ８２がデータベース３４内で利用可能である。
【００６７】
しかしながら、可能な実施態様の詳細の説明を続ける前に、テーブル３４内のパラメータセットに基づく受信機側符号化品質決定の視聴期間が、パラメータセットを生成するためにオフラインで使用される視聴期間、又は受信機側でテーブル生成のためにオフラインで使用される視聴期間に一致する必要はないことが留意されるべきである。異なる開始時刻及び終了時刻が可能である。これに関して、視聴期間内又はテスト部分内に中断が生じないことを確実にすることが有利であり得る。このように、実際の品質曲線を推定するように、最新のストリーミング方法の切り替えプロセスを検出することが可能である。
【００６８】
図１０は、符号化品質推定９４又は品質決定器４６内での品質決定の可能な実施態様の流れ図である。メディアコンテンツ及び／又はビデオの現在の視聴期間又は現在のテスト部分についての、検索によってデータベース３４内の識別子５０を用いて取得されるパラメータセット５２、及び／又はその集約５８（図３参照）が、最初にステップ１５０における平均化、すなわち経時的な平均化を受けて、それによってその後、平均化の結果に基づいて、ステップ１５２において符号化品質推定が実施される。それゆえ、より具体的には、実際に送信されたデータストリーム１８からデバイス３２によって計算された識別要素又は識別子を用いて、データベース３４からの関連付けられるパラメータセット及び／又はインジケータ５２が決定されて、対応する平均化モジュールにおける平均化１５０を受ける。平均化を受けるパラメータセット５２の数は、図２に関連して説明されたような視聴期間内のフレーム２６の数、すなわち、その中で符号化品質推定が実施されるべき視聴期間及び／又はテスト部分に対応する。
【００６９】
平均化１５０は、個々のインジケータ及び／又はパラメータを経時的に平均化することを含む。例えば、異なるインジケータカテゴリ及び／又は異なるパラメータのカテゴリに対して、異なる平均化プロセスを使用することができる。インジケータ及び／又はパラメータごとの以下の平均化技法が可能である。
【００７０】
・類似度分析のインジケータ
このインジケータの平均化１は、個々の値を、要素の時間経過にわたって後続のＬ２ノルムを用いてロジスティックにマッピングすることによって実行される。
このインジケータの平均化２は、個々の値を、要素の時間経過にわたって後続のＬ４ノルムを用いてロジスティックにマッピングすることによって実行される。
【００７１】
・エッジ分析のインジケータ
このインジケータの平均化１は、個々の値を、時間的要素にわたって後続のＬ２ノルムを用いて線形的にマッピングすることによって実行される。
このインジケータの平均化２は、個々の値を、時間的要素にわたって後続のＬ２ノルムを用いてロジスティックにマッピングすることによって実行される。
【００７２】
・ブロック分析のインジケータ
時間的に平均化されたインジケータ値は個々の値の最小値である。
【００７３】
・色度分析のインジケータ
このインジケータの平均化は要素のＬ１ノルムによって実行される。
【００７４】
・外乱の時間的経過を分析するためのインジケータ
導入されている外乱のためのインジケータの平均化はＬ１ノルムによって実行される。
除去されている部分のためのインジケータの平均化はＬ１ノルムによって実行される。
【００７５】
その後、測定されるべき部分の品質推定１５２が、時間的に平均化されたインジケータを用いて実施される。この目的のために、個々の時間的に平均化されたインジケータは、ロジスティック関数に供給され、その後、線形平均化を受ける。ロジスティック関数のパラメータはここでも、フレームサイズに応じて決まる。
【００７６】
送信信号の全体的な品質はステップ９６において、符号化品質と送信品質を統合することによって決定される。ここで、１つの符号化品質値の最大値は各視聴部分について計算されることに留意されるべきである。例えば、送信外乱に起因してデータ関連付けが可能でなかったために失われている任意の視聴部分は、送信外乱を考慮に入れながらの補間によって計算することができる。全体的な品質の推定の方法として、単一の数値が決定されてもよく、又は、品質レベルの分布がヒストグラムの形態で示されてもよい。
【００７７】
それゆえ、ここでも結局のところ、上記の実施形態がほとんどビデオに関係していることは例に過ぎないことに留意されるべきである。しかしながら、上記の実施形態は、オーディオ信号に容易に転用することができる。品質決定の組み合わせ、すなわち、オーディオ信号とビデオ信号との組み合わせの品質の決定も実現可能である。識別子生成に関して、一実施形態によれば、識別子生成は必ずしも非復号領域、例えば、エレメンタリストリームレベルにおいて行われる必要はなく、また、特に、必ずしもハッシュ値形成を用いて行われる必要はないことに留意されるべきである。むしろ、識別子を生成するために、対象になっているデータストリーム部分の復号バージョンの部分を使用することも可能であり得る。しかしながら、上述したバージョンが好ましく、それによれば、識別子を決定するために、それぞれのデータストリーム部分の非復号バージョンが、少なくとも大部分、例えば、その８０％超について、マッピング、例えば、ハッシュマッピングに供給され、その結果として、その部分内の小さい変化又は個々のビットエラーにも関連する異なる識別子がもたらされ、それによって、データベース１０内でのデータストリーム部分２８の確実な識別性が保証される。
【００７８】
上記では指摘していないが、デバイス３２、ルックアップテーブル３４、及びテーブル生成３２によって実現される品質決定サービスは、決済システムの対象にすることができることが自明である。言い換えれば、品質決定概念は、無論、商用利用することができる。各デバイス３２に対して、各品質決定プロセスに対して、各テーブル生成３２に対して、テーブル３４へのアクセスごとに、テーブル３４の提示の持続時間及びサイズに対して、又は他の適切な選択肢に対してロイヤルティ収入を受け取ることができる。
【００７９】
図７の記載が明瞭にしているように、図３に関連してすでに説明した要素に加えて送信アーティファクト検出器１８６を備えてもよく、その送信アーティファクト検出器１８６がメディアデータストリーム１８の不完全に受信された部分を検出する。品質決定器４６は、不完全に受信された部分に対して、メディアデータストリーム１８の送信アーティファクトの定量化８８をオンラインで実施し、ステップ９６における全体的な品質の決定において、不完全に受信された部分について決定された送信アーティファクトを使用するように構成することができる。
【００８０】
データベースのオフライン生成に関して、視聴期間に分割することに関連してそこで説明した可能性を省くこともできることに留意されるべきである。パラメータの生成はまた、個々のメディア部分２４’に対するいかなるそのような分割もなしに実施することもできる。
【００８１】
すでに説明したように、テスト部分の集約パラメータセットの統計的分析を、集約パラメータセット内に含まれる異なるパラメータに対して異なる統計的評価が実施されるように、例えば、異なるパラメータの中心傾向及び／又は分散に対して異なる統計学的モーメント及び尺度が決定されるように実施することができるが、これらは、例として上記で言及したものには限定されない。
【００８２】
上記で概説した実施形態の利点及び効果をより現実的に示すために、４層品質モデルが使用され、図１２を参照して下記に示す。この４層品質モデルは、送信中にアーティファクトに寄与し得る異なるソースを反映する。
【００８３】
コンテンツ品質：元のコンテンツを、非圧縮、又は非常に高いビットレートでほんの緩やかな符号化のいずれかで、優れたスタジオ品質で提供することができる。それゆえ、「コンテンツ品質」という用語は、元のコンテンツの利用可能な最も高い品質を指す。この品質は、元の画像、又はフレームのサイズ（ＵＨＤ、ＨＤ、又はＳＤ）、順次走査もしくはインタレース走査と、元のフレームレート（２９.９７、２５、又は２４フレーム／秒（ｆｐｓ））によって定義される。原ビデオコンテンツは、莫大な記憶／送信リソースを必要とするが、符号化された後に記憶でき、配信できる。
【００８４】
メディアストリーム品質：ＩＰを介した配信のためには、ビデオは様々な配信フォーマットに整合するようにコード変換（すなわち、より効率的に再符号化）される必要がある。この層を、「メディアストリーム品質」と称する。この段階における圧縮ビデオの品質は、元のコンテンツの品質＋符号化品質によって定義される。符号化品質は、符号化パラメータとともに主に符号化器のタイプによって決定される。符号化器のタイプはほとんどがＨ.２６４であり、符号化パラメータは主に出力ビットレートである。符号化品質の決定には、いくつかの他の設定も関与する。そのような設定に含まれるのは、目標フレームレート、Ｉ、Ｂ及びＰフレーム又は画像の比、ならびに、符号化効率に影響を与える他の選択の可能性、すなわち、エントロピー符号化の好ましいタイプである。そのようなエントロピー符号化としては、ＣＡＶＬＣ（コンテキストベース適応型可変長符号化：context-based adaptive variable length encoding）又はＣＡＢＡＣ（コンテキストベース適応型２進演算符号化：context-based adaptive binary arithmetic encoding）がある。メディアストリーム品質を決定し得る別の態様は、符号化器が、固定ビットレート（ＣＢＲ：constant bitrate）を生成するように設定されているか、又は可変ビットレート（ＶＢＲ：variable bitrate）を生成するように設定されているかである。
【００８５】
すべての適応型ストリーミングソリューションには、クライアントがそれぞれのネット又はネットワークによって許容されるような複数の異なる品質レベルの間でおおよそ「円滑に」切り替えながら、コンテンツが様々なビットレート、したがって品質で提供されるべきであるという共通点がある。実際には、これは、各々が異なるビットレートで、かつ異なる目標スクリーンに対して符号化されている同じコンテンツが、サーバ上で、例えば、最大１１のストリーム内に存在することを意味し得る。１つのストリームから別のストリームへと切り替わるときにビットレートが変化しようとし得るだけでなく、利用可能なビットレートに応じて、フレームサイズ（解像度）及び符号化器プロファイルも変化しようとし得ることに留意されたい。
【００８６】
送信品質：実際のネットワークにおけるパケット送信に損失がないことは滅多にない。帯域幅不整合、パケットドロップ、待ち時間及び他の送信機能障害がビデオ品質の深刻な劣化をもたらし、したがって加入者のＱｏＥを低減するおそれがある。それゆえ、送信品質は、上記の送信機能障害によって決定される。静止型ネットワーク又はモバイルネットワークのリアルタイムの制約に対処するように、特に現在利用可能なビットレートに適合するように、様々なストリーミング設定及びプロトコルが考案されている。プログレッシブダウンロードについて、フレームサイズ及びビットレートは一度選択されるとビデオ提示中は変化しないが、ビデオ（及び／又はオーディオ）が複数のビットレートで符号化され、各２〜４秒チャンクについて符号化されるとき、動的要素が適応型ストリーミングプロトコルに関与する。クライアント／再生器はここで、その需要に最良に適するチャンク、すなわち、その瞬間に取り扱うことができる最良のビットレート及び解像度を選択することができる。ウェブサーバは一般的に、ネットワーク帯域幅が許容する限りの速さでデータを配信する。クライアントは、ユーザ帯域幅を容易に推定し、より大きい又はより小さいチャンクをダウンロードすべきかを早めに判断することができる。
【００８７】
提示品質：知覚される提示品質にとって重要な要因はクライアントデバイス自体、すなわち、フラットスクリーンテレビ、タブレット又はスマートフォンである。まったく異なるユーザ期待度を含み得るスクリーンサイズと視聴環境に加えて、再生ソフトウェアが提示品質に顕著な影響を及ぼし、例えば、プレイアウトバッファとダウンロードバッファのサイズのようなパラメータが、完全にカスタマイズ可能である。
【００８８】
上記の態様に加えて、提示品質は以下の様なクライアント側のいくつかの態様に応じて決まる。
−  エンドユーザデバイスのＣＰＵパワー、メモリ及び接続性の制約、
−  オペレーティングシステム及びそのストリーミングプロコトルの固有のサポート、
−  使用時のストリーミングプロトコルの性能、すなわち、実効的にはクライアント／サーバネゴシエーション、
−  再バッファリング、エラー隠蔽技法などを含む再生ソフトウェアであり、これらはオペレーティングシステムの機能のセット、インターネットブラウザ、（サードパーティ）プラグイン（例えば、Adobe Flash、Microsoft Silverlight）、又は、ＯＴＴサービスプロバイダによって提供されるアプリのいずれかである、ならびに
−  最後に、視聴環境とともに、（元々の）ディスプレイ又は接続モニタもしくはＴＶのサイズ、解像度及びリフレッシュレート、そのインターフェース（ＷＬＡＮ、ＲＧＢ、又はＨＤＭＩ）。
【００８９】
考案されている４層ＯＴＴ品質モデルを図１２に示す。今提示されている４層手法は、ＯＴＴストリーミングサービスの事例において、加入者とのＱｏＥ競合状態に関与するパーティに非常に適しており、実際には、図１２の４層モデルはその関与するパーティとの１：１対応を含む。
−  コンテンツ品質はコンテンツ所有者の責任下に入る。コンテンツ所有者の例は、Sony Pictures、Paramount、Universal、Warner Bros.（これらは登録商標）などである。所有者は、自身の映画及びＴＶシリーズ製品を新たなＶｏＤチャネルを介して売り込むことによって、自身の収益ストリームを拡大することを望む。
−  メディアストリーム品質は、ＯＴＴプロバイダの責任下に入り、ＯＴＴプロバイダの例は、Netflix、Hulu、Amazon/Lovefilm（これらは登録商標）などである。ＯＴＴプロバイダは、オンラインビデオ提供の新たなビジネスモデルをめぐって互いに競合するだけでなく、ＯＴＴサービス自体を設定するコンテンツ所有者とも競合する。
−  送信品質は明確にネットワークプロバイダの責任下に入る。ネットワークプロバイダの例は、ＢＢＣ、Deutsche Telekom、Time Warner Cableである。これらのプロバイダは、輸送インフラストラクチャを提供するだけでなく、それら自体のＶｏＤ提供（ＢＢＣ iPlayer、Telekom Entertain）も確立する。また、
−  提示品質は、デバイス又はハンドセットの製造業者の主要な責任下に入る。接続ＴＶ及びスマートＴＶ、セットトップボックス（「ＳＴＢ」、接続Ｂｌｕ−Ｒａｙプレーヤ及びゲームコンソールを含む）、ＰＣ、タブレット及びスマートフォンのようなエンドユーザデバイスのそのような製造業者、ならびに、オペレーティングソフトウェア及び標準ソフトウェアの販売元（Microsoft、Adobe、Apple）がユーザインターフェースを視聴者（＝加入者）に供給する。
【００９０】
４層品質モデルに基づいて、適応型ストリーミングに適した正確な知覚尺度に課される要件は以下のようなものであると要約することができる。
【００９１】
コンテンツ品質の評価：アクセス可能性に応じて、元のコンテンツ又は（ゆるやかに符号化された）配信バージョンのいずれかの優れたスタジオ品質がコンテンツ品質を表すと考えられる。この「基準」品質は、後に符号化及びコード変換によって累積する圧縮アーティファクトの量を評価するための任意のＦＲ測定のための基礎を形成する。それゆえ、適応型ストリーミング品質基準は、この基準信号受け入れることが可能であるべきである。
【００９２】
メディアストリーム品質の評価：適応型ビデオストリーミングについて、１つのストリームから別のストリームへと切り替わるときにビットレートが変化しようとするだけでなく、利用可能なビットレートに応じて、フレームサイズ（解像度）及び符号化器プロファイルも変化しようとする。それゆえ、適応型ストリーミングの知覚ビデオ品質尺度は、解像度及びフレームサイズのスケーラビリティに適したものでなければならない。
【００９３】
送信品質の評価：適応型ストリーミングに適した知覚品質尺度は、有線及び無線ＩＰネットワークのすべての種類の送信アーティファクトに敏感であるだけでなく、長期的スケールの状況において異なるビットレートのチャンクの適応的切り替えから生じるアーティファクトを評価するのに適したものでなければならない。これによってまた、ミクロスケール（チャンク長）からマクロスケール（実際のコンテンツ長）に及ぶ、時間領域におけるスケーラビリティも必要とされる。
【００９４】
提示品質の評価：知覚される提示品質にとって重要な要因はクライアントデバイス自体、すなわちフラットスクリーンＴＶ、タブレット又はスマートフォンである。スクリーンサイズと視聴環境は完全に異なるユーザ期待度を含み得るが、それらに加えて適応型ストリーミングに適した知覚品質尺度は、再生ソフトウェアによって導入されるすべての種類のアーティファクトに敏感でなければならない。
【００９５】
要約すると、適応型ストリーミングの正確な知覚ビデオ品質測定は、複数の異なるビットレート（＝品質）を継続的にトラッキングすることが可能であるだけでなく、プレーヤがどれだけ頻繁にストリームを切り替えるか、及びプレーヤがどれだけ「円滑に」混雑したネットワーク内でサーバと対話することが可能であるかを評価することも可能であるべきである。加えて、この品質測定は、複数の異なるフレームサイズ及びフレームレートについて、画像品質を測定し、かつ比較することが可能であるべきである。最後に、知覚されるＱｏＥの正確な予測のためにデバイス特性と視聴環境が考慮に入れられるべきである。
【００９６】
上記で提示した実施形態は、それらの要件を満たすことができるか、又は、少なくともそれらの要件のすべてを満たすための基礎を形成することができる。
【００９７】
上記で提示した実施形態の背後にある第１の着想は、適応型ビデオストリーミングにおいて一般的にチャンク（シーケンス）長であると考えられる２〜４秒のビデオの分析が依然として、現在の規格の標準的な使用事例に、満足のいく程度によく適合するということである。上記で提示した実施形態は、相対的に長いシーケンスの連結した測定値を組み合わせるという可能性を提供する。
【００９８】
上記で提示した実施形態の背後にある第２の着想は、言及した４つの品質層（コンテンツ、メディア、送信及び提示の品質）が動的な品質態様及び準一定の品質態様にグループ分けできるということである。
【００９９】
一般的なオンデマンドＯＴＴアプリケーションのストリーミングサーバ（図１の１０及び１２参照）上に存在するメディアストリームの符号化品質は「準一定」であると考えることができる。いったん異なる品質レベルに符号化されフォーマット化されると、サーバ上のファイルの符号化品質は同じままである。
【０１００】
他方、送信及び提示の品質は、特定のネットワークを通じて特定のコンテンツの各要求に対して動的に変化する。
【０１０１】
これら２つの態様の背景に対して、上記実施形態は、モバイルデバイス上でさえ、例えば、ＦＲ高精度ビデオ品質測定をリアルタイム測定と組み合わせることを可能にするように、準一定の態様及び動的な態様をカバーすることが可能である。それゆえ、２つの主要なブロック、すなわち、メディアストリーム品質分析（６４及び６６参照）とクライアントプローブ（図３参照）から構成されるハイブリッド設定が使用される。
【０１０２】
メディアストリーム品質分析の目的は、ストリーミングサーバ（図１の１０及び１２参照）上に存在するような特定の符号化コンテンツのメディアストリーム品質を決定することである。適応型ストリーミングの場合、これは、そのようなコンテンツの各品質レベルについてメディアストリーム品質を評価することを意味する（図２及び図５参照）。
【０１０３】
この分析は、２つのステップ、すなわちコンテンツの取得と実際の品質測定において実施される。
【０１０４】
コンテンツの取得中、すべての符号化品質レベル（図２のＱ1〜Ｑ4参照）のすべてのチャンクが、上述のメディアデータストリーム部分２４に従ってストリーミングサーバから取り出される。適応型ストリーミングはＴＣＰにより動作するため、コンテンツの取得中にさらに歪みを導入することになるパケット損失の危険性はない。しかし、サーバ上のチャンクが失われることによって又はマニフェストファイルが不正確であることによって生じ得るようないかなる空白もなく、コンテンツの品質レベルのすべてが完全に取得されることが確実であることに注意を要する。
【０１０５】
実際のメディアストリーム品質分析は、例えば、上記に記載したように、標準的なＦＲビデオ品質モデルＰＥＶＱをもとに構築できる。ＰＥＶＱは長さの短いビデオチャンクの適切な分析を確実にするためにさらに発展している。通常は高解像度の元のコンテンツである基準ビデオがＰＥＶＱにおける入力として提供される必要があり、一方で、取得される品質レベルを、基準復号器を用いて復号することによって劣化したビデオが生成される。分析（図５参照）によって、各品質レベルの各フレームについての品質値のセットがもたらされる。これらの品質値を特定の短いビデオ持続時間、例えば、１０秒にわたって集約（図４参照）することによって、例えば、対応するビデオのＪ．２４７準拠のＭＯＳスコアを計算することができる。
【０１０６】
メディアストリーム品質データベース（１０参照）は、それぞれのコンテンツのメディア情報のいくつかの項目とともに、品質値を記憶する。その後、データベース内の情報は、動的な品質の態様の測定中にクライアントプローブ（すなわち、図１の３２）によって使用される。
【０１０７】
復号ビデオ信号からメディアストリーム品質を測定することの主要な利点は、分析が、基礎となっている符号化技術に何が使用されているかに依存しないことにある。これによって、種々の符号化システムにわたって正確で一貫した測定値がもたらされる。別の顕著な利点は、メディアストリーム品質が準一定であると考えられるため、データベースは各コンテンツについて一度だけ生成されればよいということである。これは、計算的に要求の多いビデオ復号及び場合によってはＦＲ品質分析を、テストごとに繰り返す必要もクライアントデバイス上で実行する必要もなく、専用のオフラインメディアストリーム品質分析デバイスに割り当てることができることを意味する。
【０１０８】
クライアントプローブの目的は、動的ビデオストリーミング品質（すなわち、送信及び提示の品質）を分析し、それを、最終的なＱｏＥスコアの計算のために静的な品質の態様（コンテンツ及びメディアストリームの品質）に関する情報と組み合わせることである。
【０１０９】
その目的のために、プローブは、入来するＨＴＴＰトラヒックを捕捉し、その後、ビットストリーム分析を行う。
【０１１０】
このビットストリーム分析中、例えば、ジッタ及びパケット再送のようなネットワークパケット特性を考慮に入れることができる。流されたビデオコンテンツの各フレームについて、クライアントにおける到来時刻を計算することができる。
【０１１１】
その後、この情報はクライアントデバイス上のソフトウェアプレーヤのプレイアウト（play-out）挙動をモデル化するストリーミングプレーヤモデルに供給される。それゆえ、プレーヤモデル出力は、現在のネットワーク状況下でのビデオの現実的なプレイアウト挙動を表す。これは、初期バッファリング（最初のプレイアウトまでの時間）及び再バッファリング／ストーリングのような効果を含む。
【０１１２】
適応型ストリーミングには、クライアントデバイス上のソフトウェアプレーヤが、ネットワーク混雑状態に応じて各チャンクのビットレートについて、サーバとの交渉を管理し、したがって、バッファが枯渇することが非常に一般的である。それゆえ、ここでは、メディアストリーム品質の品質値を、プレーヤから要求されるように、各チャンク及び各ビットレートについてデータベース内で正確に識別することができる。その後、受信ビデオシーケンスについて、記憶されている品質値を集約及び後処理することによって流されたビデオの実際の品質が計算される。
【０１１３】
上記で提示したハイブリッド手法には、ＦＲ測定の計算負荷なしに、クライアントにおいて実際の受信ビデオの正確な符号化品質が処理され、一方で、ＦＲ測定が、オフライン前処理済みメディアストリーム分析の間に容易に実施され得るという利点もある。
【０１１４】
プローブは、例えば、データベースに対するＨＴＴＰアクセスを有するＰＣベースのテスタ上で動作してもよく、又は、モバイル及びポータブルアプリケーションについて、プローブはさらには、ストリーミングクライアント上のソフトウェアに組み込まれてもよく、当該ソフトウェアはストリーミングプレーヤと並列に動作する。それぞれの利用事例、例えば、モバイルネットワークのいわゆるドライブ及び／又は歩行試験（すなわち、車両内又は歩行中のモバイルデバイスによる測定）に応じて、明確に定義された、したがって、高度に限定されたビデオテストシーケンスセットが通常利用される。加えて、データベース・アクセス中のさらなるネットワークトラヒックによる測定に対するいかなる影響も排除するように、データベースのオフライン抜粋をクライアントデバイス上に記憶することが好ましい。
【０１１５】
このように、上記で説明した実施形態の概念はいくつかの応用形態及び利用形態を可能にする。この最適化の可能性によって、関与するすべてのパーティ、すなわち、コンテンツ所有者、ネットワーク及びＣＤＮオペレータ、ＯＴＴサービスプロバイダ、並びにデバイス製造者に対する有用なガイダンスがもたらされる。
【０１１６】
このハイブリッドアーキテクチャは、クライアント側における低複雑度ビットストリーム分析の利点を、現実のピクセルベースの画像品質分析の高精度であるが複雑なＦＲ測定と組み合わせるのに非常によく適している。
【０１１７】
いくつかの態様を装置に関して説明してきたが、当然のことながら、それらの態様はまた対応する方法の説明をも表しており、それによって、装置のブロック又は構造的構成要素はまた、対応する方法ステップ又は方法ステップの特徴としても理解されるべきである。それと同様に、方法ステップに関連して又は方法ステップとして説明されている態様も、対応する装置の対応するブロック又は詳細もしくは特徴の説明をも表す。方法ステップのいくつか又はすべては、例えば、マイクロプロセッサ、プログラマブルコンピュータ又は電子回路のようなハードウェアデバイスによって（又はハードウェアデバイスを使用しながら）実施することができる。いくつかの実施形態において、ほとんどの重要な方法ステップのいくつか又は２〜３より多くのものがそのような装置によって実施することができる。
【０１１８】
特定の実施要件に応じて、本発明の実施形態は、ハードウェア又はソフトウェアで実装することができる。実施態様は、デジタル記憶媒体、例えば、フロッピーディスク、ＤＶＤ、Ｂｌｕ−ｒａｙディスク、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭもしくはフラッシュメモリ、ハードディスク、又は任意の他の磁気もしくは光メモリを使用しながら実行することができる。そのデジタル記憶媒体には、それぞれの方法が実施されるようにプログラマブルコンピュータシステムと協働できるかもしくは協働する電子的に読取り可能な制御信号が記憶されている。それゆえ、そのデジタル記憶媒体はコンピュータ読取り可能である。
【０１１９】
したがって、本発明によるいくつかの実施形態は、本明細書に記載されている方法のいずれかが実施されるようにプログラマブルコンピュータシステムと協働することが可能な電子的に読取り可能な制御信号を含むデータキャリアを含む。
【０１２０】
概して、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実装することができ、そのプログラムコードはそのコンピュータプログラム製品がコンピュータ上で作動するときに本発明方法のいずれかを実施するように実行可能である。
【０１２１】
そのプログラムコードはまた、例えば、機械的に読取り可能なキャリア上に記憶することもできる。
【０１２２】
他の実施形態は、本明細書に記載されている方法のいずれかを実施するためのコンピュータプログラムを含み、そのコンピュータプログラムは、機械的に読取り可能なキャリアに記憶することができる。
【０１２３】
言い換えれば、本発明の方法の一実施形態は、したがって、コンピュータプログラムであり、そのコンピュータプログラムは、そのコンピュータプログラムがコンピュータ上で作動するときに本明細書に記載されている本発明の方法のいずれかを実施するためのプログラムコードを有する。
【０１２４】
本発明の方法のさらなる実施形態は、したがって、本明細書に記載されている本発明の方法のいずれかを実施するためのコンピュータプログラムが記録されているデータキャリア（又はデジタル記憶媒体もしくはコンピュータ読取り可能な媒体）である。
【０１２５】
本発明の方法のさらなる実施形態は、したがって、本明細書に記載されている本発明の方法のいずれかを実施するためのコンピュータプログラムを表すデータストリーム又は信号シーケンスである。そのデータストリーム又は信号シーケンスは、例えば、データ通信リンクを介して、例えばインターネットを介して転送されるように構成することができる。
【０１２６】
さらなる実施形態は、本明細書に記載されている本発明の方法のいずれかを実施するように構成又は適合されている処理手段、例えば、コンピュータ又はプログラマブル論理デバイスを含む。
【０１２７】
さらなる実施形態は、本明細書に記載されている本発明の方法のいずれかを実施するためのコンピュータプログラムがインストールされているコンピュータを含む。
【０１２８】
本発明によるさらなる実施形態は、本明細書に記載されている本発明の方法の少なくとも１つを実施するためのコンピュータプログラムを受信機に送信するように構成されている装置又はシステムを含む。その送信は、例えば電子的又は光学的とすることができる。その受信機は、例えばコンピュータ、モバイルデバイス、メモリデバイス又は同様のデバイスとすることができる。その装置又はシステムは、例えば、コンピュータプログラムを受信機に送信するためのファイルサーバを含むことができる。
【０１２９】
いくつかの実施形態において、プログラマブル論理デバイス（例えば、フィールドプログラマブルゲートアレイ、ＦＰＧＡ）が、本明細書に記載されている本発明の方法の機能のいくつか又はすべてを実施するために使用することができる。いくつかの実施形態において、フィールドプログラマブルゲートアレイは、マイクロプロセッサと協働して、本明細書に記載されている本発明の方法のいずれかを実施することができる。概して、本発明の方法は、いくつかの実施形態において、任意のハードウェア装置によって実施される。そのハードウェア装置は、コンピュータプロセッサ（ＣＰＵ）のような任意の普遍的に適用可能なハードウェアであってもよく、又はＡＳＩＣのような、本方法に特有のハードウェアであってもよい。
【０１３０】
上述した実施形態は本発明の原理の例示を提示しているに過ぎない。当然のことながら、他の当業者には、本明細書に記載されている構成及び詳細の任意の修正及び変形がわかる。それゆえ、本発明は、実施形態の記載及び説明によって本明細書に提示されている特定の詳細によってではなく、添付の特許請求項の範囲によってのみ限定されるように意図されている。
【図１】
2016530751.tif 000003
【図２】
2016530751.tif 000004
【図３】
2016530751.tif 000005
【図４】
2016530751.tif 000006
【図５】
2016530751.tif 000007
【図６】
2016530751.tif 000008
【図７】
2016530751.tif 000009
【図８】
2016530751.tif 000010
【図９】
2016530751.tif 000011
【図１０】
2016530751.tif 000012
【図１１】
2016530751.tif 000013
【図１２】
2016530751.tif 000014
【国際調査報告】
2016530751.tif 000015
2016530751.tif 000016
2016530751.tif 000017
2016530751.tif 000018
2016530751.tif 000019
2016530751.tif 000020