(57)【特許請求の範囲】
【請求項１】
ビデオを符号化する方法であって、
複数のビデオフレームに関連する動き情報に基づいて生成される動きヒントを受信することであって、前記複数のビデオフレームは、参照ビデオフレーム及び現在のビデオフレームを含み、前記動きヒントは、前記現在のビデオフレームの１つ以上の領域に関連する１つ以上の動きベクトルに関連する、ことと、
前記現在のビデオフレームの領域をサブ領域に分割することであって、各サブ領域は、サブ領域に対して定義されたアンカーブロックを有し、アンカーブロックはサブ領域の最初のブロックである、ことと、
前記参照ビデオフレーム内の検索ウィンドウを用いて、一致する画素ブロックを検索することであって、前記動きヒント及び前記サブ領域内の前記アンカーブロックを用いて、前記現在のビデオフレームのサブ領域内の画素ブロックを符号化するのに使用する前記参照ビデオフレーム内の前記検索ウィンドウの位置をサブ領域毎に決定し、前記検索ウィンドウは、前記一致する画素ブロックの複数のビデオフレーム間の画素ブロックの動きを捕捉するために配置されている、ことと、
前記動きヒント及び前記検索ウィンドウを用いて前記現在のビデオフレームを符号化することと、
を備える、方法。
【請求項２】
前記参照ビデオフレーム及び前記現在のビデオフレームは、ビデオフレームのシーケンス内で連続するビデオフレームである、請求項１に記載の方法。
【請求項３】
前記参照ビデオフレーム内の前記検索ウィンドウの位置に基づいて、前記アンカーブロックの符号化に対するレート歪み（Ｒ−Ｄ）コストを計算することであって、前記アンカーブロックは、前記現在のビデオフレームのサブ領域の第１のブロックである、ことと、
前記Ｒ−ＤコストをＲ−Ｄ閾値と比較することと、
前記比較に基づいて、追加検索ウィンドウの位置を前記参照ビデオフレーム内で特定することと、
前記比較に基づいて、前記検索ウィンドウの位置を、前記追加検索ウィンドウの位置のうち何れかの位置に更新することと、
をさらに含む、請求項１に記載の方法。
【請求項４】
動きベクトルの分布と、前記参照ビデオフレームと前記現在のビデオフレームとの間の時間差と、シーン変化ヒントと、のうち少なくとも１つに基づいて、前記現在のビデオフレームの領域をサブ領域に分割することをさらに含む、請求項１に記載の方法。
【請求項５】
ビデオを符号化するシステムであって、
プロセッサと、
メモリと、
ビデオエンコーダと、を備え、
前記ビデオエンコーダは、
複数のビデオフレームに関連する動き情報に基づいて生成される動きヒントを受信することであって、前記複数のビデオフレームは、参照ビデオフレーム及び現在のビデオフレームを含み、前記動きヒントは、前記現在のビデオフレームの１つ以上の領域に関連する１つ以上の動きベクトルに関連する、ことと、
前記現在のビデオフレームの領域をサブ領域に分割することであって、各サブ領域は、サブ領域に対して定義されたアンカーブロックを有し、アンカーブロックはサブ領域の最初のブロックである、ことと、
前記参照ビデオフレーム内の検索ウィンドウを用いて、一致する画素ブロックを検索することであって、前記動きヒント及び前記サブ領域内の前記アンカーブロックを用いて、前記現在のビデオフレームのサブ領域内の画素ブロックを符号化するのに使用する前記参照ビデオフレーム内の前記検索ウィンドウの位置をサブ領域毎に決定し、前記検索ウィンドウは、前記一致する画素ブロックの複数のビデオフレーム間の画素ブロックの動きを捕捉するために配置されている、ことと、
前記動きヒント及び前記検索ウィンドウを用いて前記現在のビデオフレームを符号化することと、
を行うように構成されている、
システム。
【請求項６】
前記参照ビデオフレーム及び前記現在のビデオフレームは、ビデオフレームのシーケンス内で連続するビデオフレームである、請求項５に記載のシステム。
【請求項７】
前記ビデオエンコーダは、
前記参照ビデオフレーム内の前記検索ウィンドウの位置に基づいて、前記アンカーブロックの符号化に対するレート歪み（Ｒ−Ｄ）コストを計算することであって、前記アンカーブロックは、前記現在のビデオフレームのサブ領域の第１のブロックである、ことと、
前記Ｒ−ＤコストをＲ−Ｄ閾値と比較することと、
前記比較に基づいて、追加検索ウィンドウの位置を前記参照ビデオフレーム内で特定することと、
前記比較に基づいて、前記検索ウィンドウの位置を、前記追加検索ウィンドウの位置のうち何れかの位置に更新することと、
をさらに行うように構成されている、請求項５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、２０１４年８月１日に出願された米国特許出願第１４／４５０，０９４号の利益を主張し、当該特許出願の内容は、参照することにより、本明細書に完全に記載されているように組み込まれる。
【０００２】
本願は、概してビデオ符号化に関し、より具体的には、動き補償予測に関する。
【背景技術】
【０００３】
ビデオエンコーダは、符号化されるデータの量を、連続するビデオフレーム間の時間的相関を利用することによって減らすために、動き補償予測をよく適用する。動き補償予測は、カレントビデオフレームを、参照ビデオフレームの変化という観点から表現するプロセスである。動き補償予測は、１つのビデオフレームと他のビデオフレームとの間の唯一の違いがカメラの移動結果又はフレーム内を移動する物体であることが多い、という事実に基づいている。このことは、１つのフレームを表す情報の殆どが、次のフレーム内で使用される情報と同じである、ということを意味している。
【０００４】
動き補償予測は、カレントフレーム内のブロックごとに、「最も可能性のある」一致を参照フレーム内で検出することから構成されている。しかしながら、参照フレーム全体を検索することは、計算の複雑性及びメモリ帯域幅の観点において非常に高コストとなる。したがって、ソフトウェアビデオエンコーダ及びハードウェアビデオエンコーダの実際の実装形態では、選択されたエリア（つまり、検索範囲）を検索する。検索範囲は、先に符号化されたブロックに基づいて計算される予測動きベクトルの周りの参照フレーム内に存在する。
【０００５】
さらに、多くの場合では、エンコーダは、参照フレーム全体を記憶するのに十分なメモリを備えていない。したがって、実際には、ビデオエンコーダは、通常、参照フレームのサブセット（つまり、検索ウィンドウ）のみを記憶している。この検索ウィンドウは、通常、参照フレーム内に対応して配置されたブロック（つまり、配置ブロック）上に中心が置かれる。その後、予測動きベクトルは、この検索ウィンドウ内に留まるように制限される。検索エリアは、検索ウィンドウと検索範囲との間の重複領域である。
【０００６】
ビデオ符号化処理は、検索ウィンドウが大きいほど、計算の複雑性及びメモリ帯域幅の観点においてより高コストになる。特に、検索ウィンドウが大きいほど、要求されるメモリ設置面積が大きくなり、ビデオエンコーダのハードウェア実装コストがより高くなる。
【０００７】
一方、速い動きのあるフレームでは、より小さな検索ウィンドウは、動きを効果的に捕らえるための動き補償予測処理の失敗につながることがある。これは、物体が検索ウィンドウの外側に移動してしまう可能性が非常に高いからである。このことは、実際には、カレントブロックを、イントラ予測ブロック、又は、高エネルギー残差を有するインター予測ブロックとして符号化するという結果になる。それぞれの場合、エンコーダのレート歪み（Ｒ−Ｄ）性能は別々に影響を受ける。結果として、ビデオフレームを符号化するために、より高いビットレートが必要とされる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
したがって、速い動きのあるビデオを、限られたメモリを有するビデオエンコーダを用いて効果的に符号化することの可能なシステム及び方法が必要とされている。
【課題を解決するための手段】
【０００９】
実施形態は、特定の状況下で、動きヒントを、参照ビデオフレーム及びカレントビデオフレームを生成するアプリケーションが受信した動き情報に基づいて生成することと、ビデオエンコーダによって実行される動き補償予測処理をガイドしてカレントビデオフレームを符号化するために、動きヒントをビデオに提供することと、を行う方法を含む。この動きヒントを用いて、参照ビデオフレーム内の検索ウィンドウを改善し、参照ビデオフレーム内の画素ブロックの動きをよりよく捕らえることができる。検索ウィンドウが参照ビデオフレーム内でよりよく配置されるために、符号化処理を実行するのに必要なメモリを、符号化画像の品質のレベルを犠牲にすることなく減らすことができる。
【００１０】
実施形態のさらなる特徴及び利点と、実施形態の構造及び動作とを、添付の図面を参照して以下に詳細に説明する。実施形態は、本明細書において説明する特定の実施形態に限定されない、ということに留意されたい。かかる実施形態は、本明細書において、例示の目的のためだけに提示されている。追加的な実施形態は、本明細書に含まれる教示に基づいて、当業者において明白である。
【００１１】
本明細書に組み込まれ、且つ、本明細書の一部を形成する添付の図面は、本開示の実施形態を例示するものであって、発明を実施するための形態と共に、実施形態の原理を説明し、当業者が実施形態を製造、使用することを可能にする役目をさらに果たす。
【図面の簡単な説明】
【００１２】
【図１】本開示の実施形態が実装され得るシステムの機能ブロック図である。
【図２】参照ビデオフレームを用いて現在のビデオフレームを符号化するために、ビデオエンコーダによって通常用いられる動き補償予測処理を示す図である。
【図３】本開示の実施形態による、レンダリングされたビデオフレームに関連付けられた動きヒントを用いて、当該レンダリングされたビデオフレームをより効果的に符号化するためのシステムの機能ブロック図である。
【図４】本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、当該レンダリングされたビデオフレームを、領域とサブ領域とに分割することを示す図である。
【図５】本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、検索ウィンドウ位置を特定することを示す図である。
【図６】本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、追加的な検索ウィンドウ位置を特定することを示す図である。
【図７】本開示の実施形態による、動きヒントを用いて、ビデオエンコーダによって実行される動き補償予測処理を進める方法のフローチャートである。
【図８】本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きベクトルを生成するシステムの機能ブロック図である。
【図９】本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きヒントを決定する方法のフローチャートである。
【図１０】本開示の態様を実装するのに用いられ得る例示的なコンピュータシステムのブロック図である。
【発明を実施するための形態】
【００１３】
添付の図面を参照して本開示の実施形態を説明する。要素が最初に現れる図面は、通常、対応する参照番号の左端の数字によって示されている。
【００１４】
以下の説明では、本開示の実施形態の完全な理解を提供するために、多数の具体的な詳細が明記されている。しかしながら、構造、システム及び方法を含む実施形態をこれらの具体的な詳細なしに実施可能である、ということは当業者において明白である。本明細書内の説明及び表現は、当業者の作業の本質を他の当業者に最も効果的に伝えるために、当業者によって用いられる共通手段である。他の例では、周知の方法、手順、構成要素及び回路は、本開示の態様を不必要に曖昧にすることを避けるために、詳細に説明されない。
【００１５】
本明細書における、「一実施形態」、「実施形態」、「例示的な実施形態」等の言及は、説明される実施形態が、特定の特性、構造又は特徴を含み得るが、全ての実施形態が、必ずしも当該特定の特性、構造又は特徴を含まなくてもよい、ということを示している。さらに、かかる表現は、必ずしも同じ実施形態を指していない。さらに、特定の特性、構造又は特徴を有する実施形態に関連して説明される場合、当該特定の特性、構造又は特徴は、明示的に説明されていようとなかろうと、他の実施形態に関連するかかる特性、構造又は特徴に影響を与えるように当業者の知識内に含まれるものとして提示される。
【００１６】
（１．概要）
本開示は、レンダリングされたビデオフレームをより効果的に符号化するために、当該レンダリングされたビデオフレームを生成するアプリケーションが受信した情報に基づいて、動きヒントを利用するためのシステム及び方法に関連する実施形態を対象としている。システム及び方法のさらなる詳細を説明する前に、ビデオ符号化の簡単な概要を説明する。
【００１７】
一般的に、ビデオ符号化は、レンダリングされたビデオフレームのシーケンスを符号化するのに必要なビットの量を、冗長な画像情報を削除することによって減らす処理である。例えば、ビデオフレームのシーケンス内で近接するビデオフレームは、通常、非常に類似しており、大抵、これらのビデオフレームが描写するシーン内の１つ以上のオブジェクトが、連続するフレーム間でわずかに移動する点でのみ異なっている。ビデオ符号化は、少なくとも１つのケースにおいては、符号化される現在のビデオフレーム内の画素ブロックと密接に一致する画素ブロックを参照ビデオフレームで検索することによって、ビデオフレーム間の時間的冗長性を利用するように構成されている。
【００１８】
ビデオエンコーダは、参照ビデオフレーム内の密接に一致する画素ブロックを用いて冗長化した現在のビデオフレーム内の画素ブロックを記憶又は送信する必要が一般的にない、という事実を利用する。代わりに、ビデオエンコーダは、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて画素ブロックの予測を現在のビデオフレーム内で形成して、冗長情報を決定する。そして、この予測を、現在のビデオフレーム内の画素ブロックから減算して、残差のみを残す。この処理は、動き補償予測とよく呼ばれる。そして、残差（又は、残差に基づいて決定される情報）を冗長情報無しで受信デバイスに送信して、現在のビデオフレームを送信するのに必要なビットの量を減らすことができる。
【００１９】
ビデオデコーダは、現在のビデオフレーム内の画素ブロックを、残差に基づいて再構築することができる。冗長情報を、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて、例えばビデオエンコーダによって実行される予測方法と同じ予測方法を用いて予測することができる。
【００２０】
一実施形態では、本開示のシステム及び方法は、レンダリングされたビデオフレームのシーケンスに関連付けられたグローバル動きヒント（global motion hints）を用いて、レンダリングされたビデオフレームのシーケンスを符号化するためにビデオエンコーダによって実行される動き補償予測処理を改善する。動き補償予測は、上述したように、符号化される現在のビデオフレーム内の画素ブロックに密接に一致する画素ブロックを参照ビデオフレーム内で検索することを含む。この検索処理を改善することによって、現在のビデオフレーム内の画素ブロックを符号化するのに用いられる時間及び／又はビットの量を減らすことができる。
【００２１】
他の実施形態では、本開示のシステム及び方法は、レンダリングされたビデオフレームのシーケンスに関連付けられたセミグローバル動きヒント（semi-global motion hints）を用いて、レンダリングされたビデオフレームのシーケンスを符号化するためにビデオエンコーダによって実行される動き補償予測処理を改善する。
【００２２】
上述した本開示のシステム及び方法の実施形態を、当業者が本明細書の教示に基づいて理解するように、動きヒントを利用可能なアプリケーション内で使用することができる。例えば、本開示の方法及びシステムを、動きヒントを生成するために、動き情報に関連付けられたユーザ入力コマンドを受信するビデオゲーム内で使用することができる。
【００２３】
本開示のこれらの特性及び他の特性と、様々な実施形態の構造及び動作とを、添付図面を参照して、より詳細に以下に説明する。
【００２４】
（２．例示的な動作環境）
図１は、本開示の実施形態を実装することの可能な例示的な動作環境の機能ブロック図１００である。ブロック図１００は、アプリケーション１０１と、レンダリングされたビデオフレーム１０２と、ビデオエンコーダ１０３と、動き予測１０４と、を含む。
【００２５】
アプリケーション１０１は、例えば、ビデオゲーム、ビデオ編集アプリケーション、コンピュータ支援設計（ＣＡＤ）アプリケーション、コンピュータ支援製造アプリケーション等のように、レンダリング及び表示用のビデオフレームを生成するエンドユーザアプリケーションであってよい。
【００２６】
レンダリングされると、レンダリングされたビデオフレーム１０２のシーケンスを、ネットワークを介して受信デバイスに記憶又は送信するのに必要なビットの量を減らすように符号化するために、レンダリングされたビデオフレーム１０２のシーケンスがビデオエンコーダ１０３に提供され得る。例えば、ビデオエンコーダ１０３は、レンダリングされたビデオフレーム１０２のシーケンスを記憶又は送信するのに必要なビットの量を、冗長な画像情報を除去することによって減らす。一実施例では、レンダリングされたビデオフレーム１０２のシーケンス内で近接したビデオフレームは、通常、非常に類似しており、各ビデオフレームが描写するシーン内の１つ以上の物体が、ビデオフレーム間でわずかに移動する点でのみ異なることが多い。
【００２７】
動き予測１０４は、少なくとも一実施例では、符号化される現在のビデオフレーム内の画素ブロックに密接に一致する画素ブロックについて、レンダリングされたビデオフレーム１０２のシーケンス内の参照ビデオフレームを検索することによって、ビデオフレーム間の時間冗長性を利用するように構成され得る。現在のビデオフレーム及び参照ビデオフレームは、レンダリングされたビデオフレーム１０２のシーケンス内で連続するビデオフレームであってもよいし、時間的にさらに間隔が開いていてもよい。参照ビデオフレーム内の密接に一致する画素ブロックが既に受信デバイスに送信されていると仮定すると、動き予測１０４は、参照ビデオフレーム内の密接に一致する画素ブロックを用いて冗長化した現在のビデオフレーム内の画素ブロックの内容を受信デバイスに送信する必要が一般的にない、という事実を利用する。代わりに、動き予測１０４は、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて画素ブロックの予測を形成して、冗長情報を決定する。そして、この予測を画素ブロックから減算して、残差のみを残す。この処理は、動き補償予測と呼ばれる。そして、残差（又は、残差に基づいて決定される情報）を冗長情報無しで受信デバイスに送信して、現在のビデオフレームを送信するのに必要なビットの量を減らすことができる。
【００２８】
図２は、本開示の実施形態による、画素ブロックを符号化するためにビデオエンコーダ１０３によって用いられる従来の動き補償予測処理２００のさらなる詳細を示す図である。上述したように、動き補償予測処理は、符号化される現在のビデオフレーム２０６内の画素ブロック２０７に密接に一致する画素ブロックを参照ビデオフレーム２０１内で検索することを含み得る。参照ビデオフレーム２０１全体を検索することは、メモリ及び計算複雑性の観点において非常に高くつくことがあるため、ソフトウェアビデオエンコーダ及びハードウェアビデオエンコーダの実際の実装形態では、参照ビデオフレーム２０１の選択されたエリア（検索範囲２０２と呼ばれる）を検索することができる。検索範囲２０２は、参照ビデオフレーム２０１内であって、先に符号化された画素ブロックに基づいて計算された予測動きベクトル２０５の周囲に存在し得る。
【００２９】
多くの場合、特にハードウェアエンコーダ実装形態においては、ビデオエンコーダは、参照ビデオフレーム２０１全体を記憶するのに十分なメモリを備えていないことがある。このため、参照ビデオフレーム２０１のサブセット（検索ウィンドウ２０３と呼ばれる）を記憶することができ、予測動きベクトル２０５は、検索ウィンドウ２０３内に留まるように制限され得る。検索ウィンドウ２０３は、通常、参照ビデオフレーム２０１内の画素ブロック２０４上に中心が置かれ、現在のビデオフレーム２０６内の画素ブロック２０７と同じ相対位置に位置している。この画素ブロック２０４は、配置ブロックとよく呼ばれ得る。図２に示すように、検索範囲２０２の一部は、検索ウィンドウ２０３の外側にあってもよい。かかる場合、実際の検索エリア２０８は、検索ウィンドウ２０３と検索範囲２０２との間の重複領域となる。
【００３０】
一般に、検索ウィンドウ２０３を小さくするほど、必要とされるメモリ設置面積が小さくなり、図１に示したビデオエンコーダ１０３を実装する費用が安くなる。しかし、比較的速い動きのあるシーンを表現するビデオフレームでは、又は、符号化されるフレームから大きな時間的距離を有するフレームを参照フレームとして使用する場合には、検索ウィンドウ２０３の大きさをあまりにも制限することは、ビデオフレーム間の動きを効果的に捕らえるための動き補償予測処理の失敗につながることがある。この失敗は、画素ブロック２０７によって描画された物体が、検索ウィンドウ２０３の外に移動してしまった可能性が高いことから発生する。現実には、このことは、画素ブロック２０７を、イントラ予測ブロック、又は、高エネルギー残差を有するインター予測ブロックとして符号化する結果となり得る。何れの場合においても、画素ブロック２０７を符号化するのに用いられるビットの数は、通常、検索ウィンドウ２０３がビデオフレーム間の動きをより良く捕らえるのに十分に大きい場合と同じレベルの符号化画像品質を維持するために、増やす必要がある。以下に説明するように、本開示のシステム及び方法の実施形態は、検索ウィンドウ２０３の大きさと、画素ブロック２０７を符号化するのに必要なビットの数との間のトレードオフを、参照ビデオフレーム２０１と、現在のビデオフレーム２０６とに関連付けられた動きヒントを利用することによって軽減するのに役立つことができる。
【００３１】
（３．ビデオ符号化のための検索ウィンドウを適応的に配置するためのシステム及び方法）
図３は、本開示の実施形態による機能ブロック図３００である。機能ブロック図３００では、適応検索ウィンドウポジショナー３０４が追加され、既存のブロックに対していくつかの変更が行われたこと以外は、図１の機能ブロック図１００と実質的に類似している。特に、アプリケーション３０１は、少なくとも一実施形態において、レンダリングされたビデオフレーム３０２のシーケンスに関連付けられた動きヒント３０８を出力として提供するように変更されている。
【００３２】
適応検索ウィンドウポジショナー３０４は、アプリケーション３０１と動き予測３０５との間の中間段階であり、アプリケーション３０１によって生成されたシーンを、適応検索ウィンドウポジショナー３０４上で補償予測を用いて符号化する。適応検索ウィンドウポジショナー３０４は、一致する画素ブロックを、動きヒント３０８を用いて知的に検索することによって、動き予測をより効果的に行うことができる。一実施形態では、適応検索ウィンドウポジショナー３０４は、ビデオエンコーダ３０３に含まれている。
【００３３】
一実施例では、適応検索ウィンドウポジショナー３０４は、動き予測３０５によって実行される動き補償予測処理を進めるために、動きヒント３０８を処理するように構成されている。一実施形態では、動き予測３０５は、ビデオエンコーダ３０３に含まれている。一実施形態では、動きヒント３０８は、１つの動きベクトルを含むことができる。当業者が理解するように、動きヒント３０８を用いて、１つの動きベクトルを生成することができる。この動きベクトルは、現在のビデオフレーム２０６全体に関連付けられてもよく、参照ビデオフレーム２０１に関連付けられた全ブロックの動きを予測する。言い換えれば、この１つの動きベクトルは、グローバル動きヒントを構成する。
【００３４】
他の実施形態では、動きヒント３０８は、多数の異なる動きベクトルを含むことができる。代替的に、他の実施形態では、動きヒント３０８を用いて、多数の異なる動きベクトルを生成することができる。異なる動きベクトルの各々は、現在のビデオフレーム２０６内の異なる画像領域に関連付けられており、各動きベクトルを用いて、参照ビデオフレーム２０１内の対応する領域に関連付けられたブロックの動きを予測する。言い換えれば、これらの２つの実施形態では、動きヒント３０８は、セミグローバル動きヒントを提供する。
【００３５】
動きヒント３０８が１つの動きベクトル又は多数の動きベクトルに関連付けられているかどうかに関わらず、動きヒント３０８がビデオエンコーダ３０３によって用いられることで、現在のビデオフレーム２０６内の画素ブロック２０７をより効果的に符号化することができる。特に、アプリケーション３０１によって提供される動きヒント３０８を用いて、画素ブロック２０７が存在する現在のビデオフレーム２０６の画像領域に関連付けられた動きベクトルを検出することができる。そして、この動きベクトルを用いて、画素ブロック２０７の動きを参照ビデオフレーム２０１からより良く捕らえるために、検索ウィンドウ２０３を、参照ビデオフレーム２０１内でより良く配置することができる。検索ウィンドウ２０３は、画素ブロック２０７の動きを参照ビデオフレーム２０１から捕らえるようにより良く配置されているため、画素ブロック２０７を符号化するのに必要なビットの数を増やさない一方で、符号化した画像の品質のレベルを維持しながら検索ウィンドウ２０３を小さくすることができる。
【００３６】
上記の結果として、いくつかの利点が様々な状況で得られ又は現れ得る。例えば、上述した動きヒントの結果として、本明細書で説明する実施形態の態様を用いるクラウドサーバ又は他のリモートサーバは、フレームを、より迅速に、並びに／又は、より少ない処理要件及び／若しくは電力要件で符号化することができる。また、このようにレンダリングされたフレームは、エンドユーザデバイスのユーザにおいて、より高い知覚品質、又は、代替的に、短縮された遅延で先行技術の手法と等しい品質を有した状態で、見られ得る。したがって、かかるクラウドサーバ又はリモートサーバと、エンドユーザデバイスとを包含するシステムは、より良い効率で動作することができる。
【００３７】
図４を参照すると、本開示の実施形態による、適応検索ウィンドウポジショナー３０４の動作のさらなる詳細が示されている。特に、図４は、現在のビデオフレーム２０６内の１つ以上の異なる画像領域を参照ビデオフレーム２０１から符号化するのを補助するために、動きヒント３０８に関連付けられた１つ以上の動きベクトルを用いることを詳述している。
【００３８】
一実施例では、アプリケーション３０１は、１つ以上のアプリケーション領域を現在のビデオフレーム２０６内に生成する。各アプリケーション領域の大きさ及び位置は、アプリケーション３０１によって決定され得る。例えば、図４では、現在のビデオフレーム２０６は、３つのアプリケーション領域から構成されている。アプリケーション領域４０１は、例えば、現在のビデオフレーム２０６の右下に位置している。当業者が理解するように、様々な戦略を用いて、アプリケーション領域の大きさ及び位置を選択することができる。
【００３９】
適応検索ウィンドウポジショナー３０４は、異なる動きベクトルを各アプリケーション領域に関連付けることができる。各動きベクトルは、アプリケーション３０１によって生成された動きヒント３０８に基づくことができる。一実施形態では、各動きベクトルは、動きヒント３０８に直接含まれている。他の実施形態では、各動きベクトルは、動きヒント３０８から生成される。当業者が理解するように、動きベクトルを、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４の何れかによって生成することができる。さらに、当業者が理解するように、動きヒント３０８は、ユーザ入力型の動き情報と、非ユーザ入力型の動き情報とに基づくことができる。例えば、動きヒント３０８は、ビデオゲームアプリケーションが実行されているときにユーザによって入力されるコマンドに基づくことができる。
【００４０】
次に、適応検索ウィンドウポジショナー３０４によって、１つ以上のアプリケーション領域を１つ以上のサブ領域に分割することができる。例えば、アプリケーション領域４０１は、サブ領域４０２と、サブ領域４０４と、サブ領域４０６と、サブ領域４０８と、サブ領域４１０と、に分割される。各サブ領域の大きさ及び位置は、適応検索ウィンドウポジショナー３０４によって決定され得る。
【００４１】
サブ領域の粒度によって、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御することができる。当業者が理解するように、様々な戦略を活用して、このバランスを達成することができる。例えば、１つの戦略は、現在のビデオフレームを、それぞれ等しい大きさのサブ領域のセットに分割することから構成されている。潜在的には、より最適な戦略である他の戦略は、サブ領域の大きさ及び位置を、前のビデオフレーム内での動きベクトルの分布と、現在のビデオフレームと参照ビデオフレームとの間の時間差と、アプリケーションによって提供されるシーン変化ヒントと、に基づいて選択することから構成されている。
【００４２】
各サブ領域内の画素ブロックを、対応するアプリケーション領域に関連付けられた動きベクトルに基づいて符号化することができる。例えば、サブ領域４０２、サブ領域４０４、サブ領域４０６、サブ領域４０８及びサブ領域４１０は、アプリケーション領域４０１に関連付けられた動きベクトルに基づいて符号化される。
【００４３】
一実施例では、１つ以上のアプリケーション領域を１つ以上のサブ領域に分割した後に、サブ領域毎にアンカーブロックが定められる。一実施形態では、アンカーブロックは、現在のビデオフレーム２０６のサブ領域の第１のブロックとして定義される。例えば、図４では、アンカーブロック４１２は、アプリケーション領域４０１内のサブ領域４０２の第１のブロックである。
【００４４】
ここで、図５を参照すると、本開示の実施形態による、適応検索ウィンドウポジショナー３０４の動作のさらなる詳細が示されている。具体的には、アンカーブロックを定めた後に、適応検索ウィンドウポジショナー３０４は、現在のビデオフレーム内のブロックを符号化するための検索ウィンドウを何処に配置するのかを決定する。検索ウィンドウを何処に配置するのかは、サブ領域毎に決定される。
【００４５】
一実施例では、サブ領域内の画素ブロックを符号化するために、最初に、検索ウィンドウの中心が、関連する動きベクトルによって移動された、関連するアンカーブロックの配置ブロック位置上に置かれてもよい。例えば、図５では、現在のビデオフレーム５０５内の画素ブロック５０６は、サブ領域４０２内のアンカーブロック４１２に対応している。そして、画素ブロック５０６は、参照ビデオフレーム５０１内の配置ブロック５０３に対応している。したがって、検索ウィンドウ５０２の位置は、動きベクトル５０４によって移動された配置ブロック５０３の位置となる。
【００４６】
代替的に、動きヒントがアプリケーションによって提供されなかった場合には、検索ウィンドウは、移動することなく、参照ビデオフレーム内のアンカーブロックの配置ブロック位置上に中心が置かれる。例えば、図５では、検索ウィンドウ５０２の中心は、参照ビデオフレーム５０１内の配置ブロック５０３上に置かれる。
【００４７】
動きヒントが提供される場合には、アンカーブロックは、最初に、関連する動きベクトルによって移動されたアンカーブロックの配置ブロック位置上に中心が置かれた検索ウィンドウ５０２を用いて、符号化される。この検索ウィンドウを用いてアンカーブロックを符号化したときに動き予測３０５によって報告されるＲ−Ｄコストが閾値よりも大きい場合には、適応検索ウィンドウポジショナー３０４は、検索ウィンドウを他の位置に配置したときのレート歪み（Ｒ−Ｄ）コストを評価する。当業者が理解するように、閾値は、画素ブロックを符号化するのに必要なビット数が、符号化することの計算複雑性に対してバランスを取るような値に設定され得る。さらに、一実施形態では、閾値は、符号化戦略によって適応的に変化し得る。
【００４８】
図６は、本開示の実施形態による、検索ウィンドウを他の位置に配置したときのＲ−Ｄコストを評価するプロセスを示す図である。一実施例では、検索ウィンドウ６０３は、最初に、動きベクトル６０２によって移動された画素ブロック６０１に置かれている。この最初の位置は、図５の検索ウィンドウ５０２の位置に対応している。次に、追加検索ウィンドウの位置が特定される。例えば、図６では、７個の追加検索ウィンドウの位置６０４が特定されている。当業者が理解するように、追加検索ウィンドウの位置６０４の数は、計算複雑性及びビデオ符号化効率の間のバランスに基づくことができる。
【００４９】
様々な戦略を用いて、追加検索ウィンドウの位置６０４を選択することができる。これらの戦略は、先に符号化されたビデオフレーム、又は、同じビデオフレーム内で先に符号化されたブロックに基づくことができる。当業者が理解するように、１つの戦略は、最初の検索ウィンドウ（つまり、関連する動きベクトルによって移動された配置ブロックに位置する検索ウィンドウ）の位置６０３の周りで均一にサンプリングされたＮ個の位置を選択することである。
【００５０】
追加検索ウィンドウの位置６０４の数及び位置を特定した後に、適応検索ウィンドウポジショナー３０４は、検索ウィンドウを追加検索ウィンドウの各位置６０４に配置したときのＲ−Ｄコストを評価する。追加検索ウィンドウの各位置６０４のうち最小のＲ−Ｄコストが設定した閾値よりも高い場合、又は、当該閾値に等しい場合には、検索ウィンドウの位置は、検索ウィンドウの位置６０３に留まる。言い換えれば、検索ウィンドウは、関連する動きベクトルによって移動されたアンカーブロックの配置ブロック位置、例えば、図６の検索ウィンドウ６０３上に中心が置かれている。その一方で、追加検索ウィンドウの各位置６０４のうち最小のＲ−Ｄコストが閾値よりも低い場合には、検索ウィンドウは、最小のＲ−Ｄコストを有する追加検索ウィンドウの位置６０４に配置される。
【００５１】
最終的な検索ウィンドウの位置が選択されると、現在のサブ領域内の非アンカーブロックは、最終的な検索ウィンドウの位置を用いて符号化される。しかしながら、最終的な検索ウィンドウの位置は、非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。次に、１つのサブ領域内のブロックを符号化した後に、対応するアプリケーション領域内の他のサブ領域が符号化される。これらの他のサブ領域は、同一の最終的な検索ウィンドウの位置を継承する。しかしながら、最終的な検索ウィンドウの位置は、同様に、その領域での非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。
【００５２】
ここで、図７を参照すると、本開示の実施形態による、ビデオ符号化のために、検索ウィンドウを、動きヒントに基づいて適応的に配置する方法７００のフローチャートが示されている。一実施例では、方法７００は、図３〜図６を参照して上述したように、適応検索ウィンドウポジショナー３０４によって実装され得る。しかしながら、方法を、他のシステム及び構成要素によって実装することもできる、ということに留意すべきである。フローチャート７００の一部のステップを実行する必要がなく、及び／又は、図７に示す順に実行する必要がない、ということも留意すべきである。
【００５３】
ステップ７０２では、符号化される現在のビデオフレームと参照ビデオフレームとに関連付けられた動きヒント３０８を、アプリケーション３０１から受信する。当業者が理解するように、受信した動きヒント３０８は、ユーザ入力型の動き情報と、非ユーザ入力型の動き情報と、に基づくことができる。
【００５４】
ステップ７０４では、現在のビデオフレームが１つ以上のアプリケーション領域に分割される。一実施形態では、現在のビデオフレーム全体がアプリケーション領域を構成する。他の実施形態では、現在のビデオフレームが複数のアプリケーション領域に分割される。当業者が理解するように、様々な戦略を用いて、これらのアプリケーション領域の大きさ及び位置を選択することができる。一実施形態では、アプリケーション３０１は、ビデオフレームの分割戦略を定める。
【００５５】
また、１つ以上のアプリケーション領域は、１つ以上のサブ領域に分割される。一実施形態では、この分割は、適応検索ウィンドウポジショナー３０４によって実行される。サブ領域の粒度は、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御する。一実施形態では、１つのアプリケーション領域において１つのサブ領域のみが生成される。他の実施形態では、アプリケーション領域は、等しい大きさのサブ領域のセットに分割される。他の実施形態では、アプリケーション領域は、先のビデオフレーム内の動きベクトルの分布と、現在のビデオフレームと参照ビデオフレームとの間の時間差と、アプリケーション３０１によって提供されるシーン変化ヒントと、に基づいてサブ領域に分割される。
【００５６】
ステップ７０６では、ステップ７０２で受信した動きヒント３０８を用いて、１つ以上の動きベクトルを、１つ以上のアプリケーション領域に関連付ける。一実施形態では、各動きベクトルは、受信した動きヒント３０８に含まれている。他の実施形態では、各動きベクトルは、動きヒント３０８から生成される。当業者が理解するように、動きベクトルを、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４によって生成することができる。一実施形態では、１つ以上の動きベクトルの各々は、１つ以上のアプリケーション領域の何れかのアプリケーション領域に関連付けられる。当業者が理解するように、動きベクトルをアプリケーション領域に関連付けることは、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４によって実行され得る。
【００５７】
ステップ７０８では、１つ以上のアプリケーション領域がサブ領域に分割される。一実施形態では、各サブ領域の大きさ及び位置は、適応検索ウィンドウポジショナー３０４によって決定される。１つ以上のサブ領域の粒度は、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御する。当業者が理解するように、様々な戦略を用いて、このバランスを達成することができる。
【００５８】
１つ以上のアプリケーション領域をサブ領域に分割した後に、アンカーブロックがサブ領域毎に定められる。一実施形態では、アンカーブロックは、サブ領域の第１のブロックとして定義される。
【００５９】
ステップ７１０では、検索ウィンドウの位置をサブ領域毎に決定する。検索ウィンドウの位置は、対応するアプリケーション領域に関連付けられた動きベクトルに基づいている。検索ウィンドウの中心は、最初に、関連する動きベクトルによって移動された、関連するアンカーブロックの配置ブロック位置上に置かれている。そして、アンカーブロックは、この位置の検索ウィンドウを用いて符号化される。アンカーブロックを検索ウィンドウの位置で符号化したときのＲ−Ｄコストが閾値よりも大きい場合には、追加検索ウィンドウの位置が試される。様々な戦略を用いて、追加検索ウィンドウの位置を選択することができる。
【００６０】
追加検索ウィンドウの位置を特定した後に、検索ウィンドウを追加検索ウィンドウの位置の各々に配置したときのＲ−Ｄコストが計算される。追加検索ウィンドウの位置間で最小のＲ−Ｄコストが上記で設定した閾値よりも高い又は等しい場合には、検索ウィンドウの位置は、最初の検索ウィンドウの位置に留まる。一方、追加検索ウィンドウの位置のうち最小のＲ−Ｄコストが閾値よりも小さい場合には、検索ウィンドウは、最小のＲ−Ｄコストを有する追加検索ウィンドウの位置に配置される。
【００６１】
ステップ７１２では、アンカーブロックが、最終的な検索ウィンドウの位置を用いて符号化される。また、サブ領域内の全ての非アンカーブロックが、最終的な検索ウィンドウの位置を用いて符号化される。しかしながら、非アンカーブロックについては、最終的な検索ウィンドウの位置は、各非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。
【００６２】
１つのサブ領域を符号化した後に、対応するアプリケーション領域内の他のサブ領域が符号化される。他のサブ領域の各々は、同一の最終的な検索ウィンドウの位置を継承する。しかしながら、検索ウィンドウの位置は、各サブ領域の対応するアンカーブロックに対して調整される。さらに、非アンカーブロックについては、検索ウィンドウの位置が、同様に、各非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。
【００６３】
一実施形態では、図３の例示的なシステムを例示のために用いて、参照ビデオフレームと現在のビデオフレームとを生成するアプリケーション３０１によって受信された動き情報に基づいて、動きヒント３０８を生成することができる。そして、アプリケーション３０１は、レンダリングされたビデオフレームのシーケンスに関連付けられた動きヒント３０８を、ビデオエンコーダ３０３に提供することができる。
【００６４】
レンダリングは、三次元シーンを仮想カメラによって観察される視界に対応する二次元平面に投影することによって、ビデオフレームを取得するプロセスを含むことができる。仮想カメラからの三次元シーン内の物体の距離に関連する立体情報をレンダリング処理中に計算して、三次元シーン内の何れの物体が、レンダリングされたビデオフレーム内でユーザから見えるべきか又は見えないべきか、を決定することができる。例えば、三次元シーン内の特定の物体は、三次元シーン内の不透明な他の物体の後ろに存在するので、ユーザから見えなくすべきである。
【００６５】
図８を参照すると、本開示の実施形態による、動きヒントを生成する場合のカメラの動作と、アプリケーション３０１によって解析される立体情報と、のさらなる詳細が示されている。
【００６６】
例示的な動作では、アプリケーション３０１は、画像領域８０４を参照ビデオフレーム２０１内で選択する。そして、アプリケーション３０１は、深度値と、画像領域８０４内の二次元ポイント８０２（つまり、画素）とを関連付けることができる。一実施形態では、二次元ポイント８０２は、画像領域８０４の重心として選択され、深度値は、画像領域８０４内の二次元ポイント（つまり、画素）の平均深度値として設定される。一実施形態では、画像領域８０４内の二次元ポイントの深度値は、当該二次元ポイントが描写する三次元シーン８０８内の物質の仮想カメラ８１０からの距離に対応する。
【００６７】
そして、アプリケーション３０１は、二次元ポイント８０２を三次元シーン８０８内の三次元ポイント８０６にマッピングし直すことができる。当業者が理解するように、三次元ポイント８０６への二次元ポイント８０２のマッピングは、逆レンダリング処理であってもよく、参照ビデオフレーム２０１内の二次元ポイント８０２の位置と、関連する深度値と、参照ビデオフレーム２０１をレンダリングするために使用された仮想カメラ８１４の位置及び向きと、を用いて実行され得る。仮想カメラ８１０の位置及び向きは、アプリケーション３０１が利用可能である。
【００６８】
アプリケーション３０１は、現在のビデオフレーム２０６をレンダリングするのに用いられた仮想カメラ８１４の位置及び向きに基づいて三次元ポイント８０６をレンダリングすることによって、三次元ポイント８０６を現在のビデオフレーム２０６内の二次元ポイント８１２（つまり、画素）にマッピングすることができる。仮想カメラ８１４の位置及び向きは、同様に、アプリケーション３０１に提供され得る。
【００６９】
アプリケーション３０１は、二次元ポイント８０２と二次元ポイント８１２との位置の違いに基づいて、動きベクトル８１６を決定することができる。
【００７０】
アプリケーション３０１は、動きベクトル８１６（又は、動きベクトル８１６に基づいて決定されるいくつかの情報）を用いて、動きヒント３０８を決定することができる。アプリケーション３０１は、動きヒント３０８をビデオエンコーダ３０３に提供する。上述したように、ビデオエンコーダ３０３は、動きヒント３０８を用いて、検索ウィンドウを参照ビデオフレーム２０１内に配置しながら動き補償予測を実行して、現在のビデオフレーム２０６の画像領域８１８内の画素ブロックをより効果的に符号化することができる。
【００７１】
ここで、図９を参照すると、本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きベクトルを生成する方法のフローチャート９００が示されている。フローチャート９００の方法を、上述したアプリケーション３０１によって実装することができる。しかしながら、方法を、他のシステム及び構成要素によって実装することができる、ということに留意すべきである。フローチャート９００のステップのいくつかは、実行される必要がなく、又は、図９に示す順で実行される必要がない、ということにさらに留意すべきである。
【００７２】
ステップ９０２では、符号化される現在のビデオフレームと参照ビデオフレームとに関連付けられたカメラ情報及び立体情報が受信される。
【００７３】
ステップ９０４では、仮想カメラから見た参照ビデオフレームの領域内の二次元ポイント（つまり、画素）を、二次元ポイントに関連付けられた深度値に基づいて、及び、参照フレームのレンダリング中の仮想カメラの位置及び向きに基づいて、三次元ポイントにマッピングすることができる。一実施形態では、二次元ポイントを、参照ビデオフレームの重心として選択することができ、深度値は、参照ビデオフレームの画像領域内の二次元ポイント（つまり、画素）の平均深度値として設定される。一実施形態では、参照ビデオの画像領域内の二次元ポイントの深度値は、当該二次元ポイントが描写する物体の、当該二次元ポイントをレンダリングするのに用いられる仮想カメラからの距離に対応する。
【００７４】
ステップ９０６では、現在のフレームのレンダリング中の仮想カメラの位置及び向きに基づいて、三次元ポイントを、仮想カメラから見た現在のビデオフレーム内の二次元ポイントにマッピングすることができる。
【００７５】
ステップ９０８では、参照ビデオフレーム内の二次元ポイントと現在のビデオフレーム内の二次元ポイントとの位置の違いに基づいて、動きベクトルを決定することができる。
【００７６】
ステップ９１０では、動きベクトルに基づいて動きヒントを決定することができる。そして、現在のビデオフレームを符号化するためにビデオエンコーダによって実行される動き補償予測処理を進めるために、動きヒントをビデオエンコーダに提供することができる。例えば、ビデオエンコーダは、動きヒントを用いて検索ウィンドウを参照ビデオフレームに配置する一方で、現在のビデオフレーム内の画素ブロックをより効果的に符号化するために動き補償予測を実行することができる。
【００７７】
図３〜図９を参照して上述した本開示のシステム及び方法の実施形態を、クラウドゲームサービス内で動作しているサーバで用いて、例えば、当該サービス上でビデオゲームを行うことに関連する遅延量、ダウンストリーム帯域幅及び／又は計算処理能力を改善することができる。さらに、本開示の方法及びシステムを、当業者が本明細書の教示に基づいて理解するように、レンダリングされたビデオフレーム又は捕らえられたビデオフレームに関連する動きヒント情報を利用可能な他のアプリケーション内で使用することができる。例えば、本開示の方法及びシステムを、動き情報に関連するユーザコマンドを受信するビデオゲームアプリケーション内で使用することができる。
【００７８】
（４．例示的なコンピュータシステム実装形態）
本明細書で説明する本開示の様々な要素及び特性を、アナログ回路及び／又はデジタル回路を使用するハードウェアで実装してもよく、１つ以上の汎用プロセッサ又は専用プロセッサによる命令の実行を介してソフトウェアで実装してもよく、ハードウェア及びソフトウェアの組み合わせで実装してもよいことは、当業者において明らかである。
【００７９】
完全性のために、汎用コンピュータシステムの説明を以下に提供する。本開示の実施形態を、ハードウェアで、又は、ハードウェア及びソフトウェアの組み合わせで実装することができる。結果として、本開示の実施形態を、コンピュータシステム又は他の処理システムの環境で実装することができる。かかるコンピュータシステム１０００の一実施例を図１０に示す。図１及び図３に示したモジュールの全てを、１つ以上の個別のコンピュータシステム１０００上で実行することができる。さらに、図７に示したフローチャートのステップの各々を、１つ以上の個別のコンピュータシステム１０００上に実装することができる。
【００８０】
コンピュータシステム１０００は、例えばプロセッサ１００４等のように１つ以上のプロセッサを含む。プロセッサ１００４は、専用又は汎用のデジタル信号プロセッサであってもよい。プロセッサ１００４は、通信インフラストラクチャ１００２（例えば、バス又はネットワーク）に接続されている。様々なソフトウェア実装形態を、この例示的なコンピュータシステムの観点から説明する。本説明を読んだ後に、開示の実施形態を他のコンピュータシステム及び／又はコンピュータアーキテクチャを用いて実装する方法が当業者において明らかになる。
【００８１】
また、コンピュータシステム１０００は、メインメモリ１００６、好ましくはランダムアクセスメモリ（ＲＡＭ）を含んでもよいし、二次メモリ１００８を含んでもよい。二次メモリ１００８は、例えば、ハードディスクドライブ１０１０及び／又は取り外し可能ストレージドライブ１０１２（例えば、フロッピー（登録商標）ディスクドライブ、磁気テープドライブ、光ディスクドライブ等に代表される）を含んでもよい。取り外し可能ストレージドライブ１０１２は、周知の方法で、取り外し可能ストレージユニット１０１６からの読み出し、及び／又は、取り外し可能ストレージユニット１０１６への書き込みを行ってもよい。取り外し可能ストレージユニット１０１６は、例えば、フロッピー（登録商標）ディスク、磁気テープ、光ディスク等に代表され、取り外し可能ストレージドライブ１０１２によって読み出され、書き込まれる。当業者が理解するように、取り外し可能ストレージユニット１０１６は、コンピュータソフトウェア及び／又はデータを内部に記憶したコンピュータ可用ストレージ媒体を含む。
【００８２】
代替的な実装形態では、二次メモリ１００８は、コンピュータプログラム又は他の命令をコンピュータシステム１０００にロードすることを可能にするための他の同様の手段を含んでもよい。かかる手段は、例えば、取り外し可能ストレージユニット１０１８と、インターフェース１０１４とを含むことができる。かかる手段の例は、（例えば、ビデオゲームデバイスで見つかるもの等の）プログラムカートリッジ及びカートリッジインターフェースと、（例えば、ＥＰＲＯＭ又はＰＲＯＭ等の）取り外し可能メモリチップ及び関連ソケットと、サムドライブ及びＵＳＢポートと、取り外し可能ストレージユニット１０１８からコンピュータシステム１０００にソフトウェア及びデータを伝達することを可能にする他の取り外し可能ストレージユニット１０１８及びインターフェース１０１４と、を含んでもよい。
【００８３】
また、コンピュータシステム１０００は、通信インターフェース１０２０を含んでもよい。通信インターフェース１０２０は、コンピュータシステム１０００と外部デバイスとの間でソフトウェア及びデータを伝達することを可能にする。通信インターフェース１０２０の例は、モデムと、（イーサネット（登録商標）カード等の）ネットワークインターフェースと、通信ポートと、ＰＣＭＣＩＡスロット及びカード等と、を含んでもよい。通信インターフェース１０２０を介して伝達されるソフトウェア及びデータは、信号の形態であってもよいし、電子信号、電磁信号、光信号、又は、通信インターフェース１０２０が受信可能な他の信号であってもよい。これらの信号は、通信経路１０２２を介して通信インターフェース１０２０に提供される。通信経路１０２２は、信号を運ぶものであって、ワイヤ又はケーブルと、光ファイバと、電話線と、携帯電話リンクと、ＲＦリンクと、他の通信チャネルと、を用いて実装され得る。
【００８４】
本明細書で用いられるように、「コンピュータプログラム媒体」及び「コンピュータ可読媒体」という用語は、一般的に、取り外し可能ストレージユニット１０１６及び取り外し可能ストレージユニット１０１８等の有形ストレージ媒体、又は、ハードディスクドライブ１０１０にインストールされたハードディスクを指すのに用いられる。これらのコンピュータプログラム製品は、ソフトウェアをコンピュータシステム１０００に提供するための手段である。
【００８５】
（コンピュータ制御論理とも呼ばれる）コンピュータプログラムは、メインメモリ１００６及び／又は二次メモリ１００８に記憶されている。また、コンピュータプログラムを、通信インターフェース１０２０を介して受信することができる。かかるコンピュータプログラムは、実行されると、コンピュータシステム１０００が、本明細書で説明した本開示の内容を実装することを可能にする。特に、コンピュータプログラムは、実行されると、プロセッサ１００４が、本明細書で説明した方法のうち任意の方法等のように、本開示のプロセスを実行することを可能にする。したがって、かかるコンピュータプログラムは、コンピュータシステム１０００のコントローラを表している。開示した実施形態がソフトウェアを用いて実装されている場合には、ソフトウェアを、コンピュータプログラム製品に記憶することができ、取り外し可能ストレージドライブ１０１２、インターフェース１０１４又は通信インターフェース１０２０を用いて、コンピュータシステム１０００にロードすることができる。
【００８６】
他の実施形態では、本開示の特性を、主に、例えば特定用途向け集積回路（ＡＳＩＣ）及びゲートアレイ等のハードウェア構成要素を使用するハードウェアで実装することができる。本明細書で説明した機能を実行するためのハードウェア状態機械の実装形態は、当業者において明らかである。
【００８７】
発明の概要及び要約は、発明者によって考慮された１つ以上であるが全てとは限らない例示的な実施形態を示すことができる。したがって、これらは、実施形態及び添付の特許請求の範囲において、どのようにも限定されることを意図していない。
【００８８】
本明細書の実施形態を、機能ビルディングブロックの助けを用いて上述し、機能ビルディングブロックは、その特定の機能の実装形態と関係とを示している。これらの機能ビルディングブロックの境界は、本明細書では、説明の利便性のために任意に定義されている。代替的な境界を定めてもよく、境界は、特定の機能及びその関係が適切に実行される限りにおいて定められてもよい。
【００８９】
特定の実施形態の上記の説明は、実施形態の一般的な性質を完全に明らかにし、他者が当該技術分野における知識を応用することによって、様々なアプリケーションのために、過度の実験なしに、実施形態の一般的概念から逸脱することなしに、かかる実施形態を容易に変更及び／又は適応させることを可能にする。したがって、かかる適応物及び変更物は、本明細書に提示された教示及び助言に基づいて、開示の実施形態の均等物の意味及び範囲に含まれることが意図されている。本明細書の表現及び用語は、限定ではなく説明の目的のためであり、本明細書の用語及び表現は、本教示と助言とを踏まえて、熟練の技術者によって解釈されるものである、ということが理解される。
【図１】
0006605581.tif 000002
【図２】
0006605581.tif 000003
【図３】
0006605581.tif 000004
【図４】
0006605581.tif 000005
【図５】
0006605581.tif 000006
【図６】
0006605581.tif 000007
【図７】
0006605581.tif 000008
【図８】
0006605581.tif 000009
【図９】
0006605581.tif 000010
【図１０】
0006605581.tif 000011