JP2017526268A - ビデオ符号化のための適応検索ウィンドウの配置 - Google Patents

Abstract

レンダリングされたビデオフレームに関連付けられた動きヒントを利用する方法、システム及びコンピュータプログラム製品を提供する。動きヒントは、ビデオエンコーダによって実行される動き補償予測処理を進めるために、ビデオエンコーダに提供される。具体的には、動きヒントを用いて、参照ビデオフレーム内で検索ウィンドウをより良く配置することによって、参照ビデオフレーム内の画素ブロックの動きをより良く捕らえる。検索ウィンドウが参照ビデオフレーム内でより良く配置されるために、符号化処理を実行するのに必要なメモリを、符号化した画像の品質のレベルを犠牲にすることなく減らすことができる。【選択図】図３

Description

（関連出願の相互参照）
本願は、２０１４年８月１日に出願された米国特許出願第１４／４５０，０９４号の利益を主張し、当該特許出願の内容は、参照することにより、本明細書に完全に記載されているように組み込まれる。

本願は、概してビデオ符号化に関し、より具体的には、動き補償予測に関する。

ビデオエンコーダは、符号化されるデータの量を、連続するビデオフレーム間の時間的相関を利用することによって減らすために、動き補償予測をよく適用する。動き補償予測は、カレントビデオフレームを、参照ビデオフレームの変化という観点から表現するプロセスである。動き補償予測は、１つのビデオフレームと他のビデオフレームとの間の唯一の違いがカメラの移動結果又はフレーム内を移動する物体であることが多い、という事実に基づいている。このことは、１つのフレームを表す情報の殆どが、次のフレーム内で使用される情報と同じである、ということを意味している。

動き補償予測は、カレントフレーム内のブロックごとに、「最も可能性のある」一致を参照フレーム内で検出することから構成されている。しかしながら、参照フレーム全体を検索することは、計算の複雑性及びメモリ帯域幅の観点において非常に高コストとなる。したがって、ソフトウェアビデオエンコーダ及びハードウェアビデオエンコーダの実際の実装形態では、選択されたエリア（つまり、検索範囲）を検索する。検索範囲は、先に符号化されたブロックに基づいて計算される予測動きベクトルの周りの参照フレーム内に存在する。

さらに、多くの場合では、エンコーダは、参照フレーム全体を記憶するのに十分なメモリを備えていない。したがって、実際には、ビデオエンコーダは、通常、参照フレームのサブセット（つまり、検索ウィンドウ）のみを記憶している。この検索ウィンドウは、通常、参照フレーム内に対応して配置されたブロック（つまり、配置ブロック）上に中心が置かれる。その後、予測動きベクトルは、この検索ウィンドウ内に留まるように制限される。検索エリアは、検索ウィンドウと検索範囲との間の重複領域である。

ビデオ符号化処理は、検索ウィンドウが大きいほど、計算の複雑性及びメモリ帯域幅の観点においてより高コストになる。特に、検索ウィンドウが大きいほど、要求されるメモリ設置面積が大きくなり、ビデオエンコーダのハードウェア実装コストがより高くなる。

一方、速い動きのあるフレームでは、より小さな検索ウィンドウは、動きを効果的に捕らえるための動き補償予測処理の失敗につながることがある。これは、物体が検索ウィンドウの外側に移動してしまう可能性が非常に高いからである。このことは、実際には、カレントブロックを、イントラ予測ブロック、又は、高エネルギー残差を有するインター予測ブロックとして符号化するという結果になる。それぞれの場合、エンコーダのレート歪み（Ｒ−Ｄ）性能は別々に影響を受ける。結果として、ビデオフレームを符号化するために、より高いビットレートが必要とされる。

したがって、速い動きのあるビデオを、限られたメモリを有するビデオエンコーダを用いて効果的に符号化することの可能なシステム及び方法が必要とされている。

実施形態は、特定の状況下で、動きヒントを、参照ビデオフレーム及びカレントビデオフレームを生成するアプリケーションが受信した動き情報に基づいて生成することと、ビデオエンコーダによって実行される動き補償予測処理をガイドしてカレントビデオフレームを符号化するために、動きヒントをビデオに提供することと、を行う方法を含む。この動きヒントを用いて、参照ビデオフレーム内の検索ウィンドウを改善し、参照ビデオフレーム内の画素ブロックの動きをよりよく捕らえることができる。検索ウィンドウが参照ビデオフレーム内でよりよく配置されるために、符号化処理を実行するのに必要なメモリを、符号化画像の品質のレベルを犠牲にすることなく減らすことができる。

実施形態のさらなる特徴及び利点と、実施形態の構造及び動作とを、添付の図面を参照して以下に詳細に説明する。実施形態は、本明細書において説明する特定の実施形態に限定されない、ということに留意されたい。かかる実施形態は、本明細書において、例示の目的のためだけに提示されている。追加的な実施形態は、本明細書に含まれる教示に基づいて、当業者において明白である。

本明細書に組み込まれ、且つ、本明細書の一部を形成する添付の図面は、本開示の実施形態を例示するものであって、発明を実施するための形態と共に、実施形態の原理を説明し、当業者が実施形態を製造、使用することを可能にする役目をさらに果たす。

本開示の実施形態が実装され得るシステムの機能ブロック図である。 参照ビデオフレームを用いて現在のビデオフレームを符号化するために、ビデオエンコーダによって通常用いられる動き補償予測処理を示す図である。 本開示の実施形態による、レンダリングされたビデオフレームに関連付けられた動きヒントを用いて、当該レンダリングされたビデオフレームをより効果的に符号化するためのシステムの機能ブロック図である。 本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、当該レンダリングされたビデオフレームを、領域とサブ領域とに分割することを示す図である。 本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、検索ウィンドウ位置を特定することを示す図である。 本開示の実施形態による、レンダリングされたビデオフレームを、動きヒントを用いてより効果的に符号化するために、追加的な検索ウィンドウ位置を特定することを示す図である。 本開示の実施形態による、動きヒントを用いて、ビデオエンコーダによって実行される動き補償予測処理を進める方法のフローチャートである。 本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きベクトルを生成するシステムの機能ブロック図である。 本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きヒントを決定する方法のフローチャートである。 本開示の態様を実装するのに用いられ得る例示的なコンピュータシステムのブロック図である。

添付の図面を参照して本開示の実施形態を説明する。要素が最初に現れる図面は、通常、対応する参照番号の左端の数字によって示されている。

以下の説明では、本開示の実施形態の完全な理解を提供するために、多数の具体的な詳細が明記されている。しかしながら、構造、システム及び方法を含む実施形態をこれらの具体的な詳細なしに実施可能である、ということは当業者において明白である。本明細書内の説明及び表現は、当業者の作業の本質を他の当業者に最も効果的に伝えるために、当業者によって用いられる共通手段である。他の例では、周知の方法、手順、構成要素及び回路は、本開示の態様を不必要に曖昧にすることを避けるために、詳細に説明されない。

本明細書における、「一実施形態」、「実施形態」、「例示的な実施形態」等の言及は、説明される実施形態が、特定の特性、構造又は特徴を含み得るが、全ての実施形態が、必ずしも当該特定の特性、構造又は特徴を含まなくてもよい、ということを示している。さらに、かかる表現は、必ずしも同じ実施形態を指していない。さらに、特定の特性、構造又は特徴を有する実施形態に関連して説明される場合、当該特定の特性、構造又は特徴は、明示的に説明されていようとなかろうと、他の実施形態に関連するかかる特性、構造又は特徴に影響を与えるように当業者の知識内に含まれるものとして提示される。

（１．概要）
本開示は、レンダリングされたビデオフレームをより効果的に符号化するために、当該レンダリングされたビデオフレームを生成するアプリケーションが受信した情報に基づいて、動きヒントを利用するためのシステム及び方法に関連する実施形態を対象としている。システム及び方法のさらなる詳細を説明する前に、ビデオ符号化の簡単な概要を説明する。

一般的に、ビデオ符号化は、レンダリングされたビデオフレームのシーケンスを符号化するのに必要なビットの量を、冗長な画像情報を削除することによって減らす処理である。例えば、ビデオフレームのシーケンス内で近接するビデオフレームは、通常、非常に類似しており、大抵、これらのビデオフレームが描写するシーン内の１つ以上のオブジェクトが、連続するフレーム間でわずかに移動する点でのみ異なっている。ビデオ符号化は、少なくとも１つのケースにおいては、符号化される現在のビデオフレーム内の画素ブロックと密接に一致する画素ブロックを参照ビデオフレームで検索することによって、ビデオフレーム間の時間的冗長性を利用するように構成されている。

ビデオエンコーダは、参照ビデオフレーム内の密接に一致する画素ブロックを用いて冗長化した現在のビデオフレーム内の画素ブロックを記憶又は送信する必要が一般的にない、という事実を利用する。代わりに、ビデオエンコーダは、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて画素ブロックの予測を現在のビデオフレーム内で形成して、冗長情報を決定する。そして、この予測を、現在のビデオフレーム内の画素ブロックから減算して、残差のみを残す。この処理は、動き補償予測とよく呼ばれる。そして、残差（又は、残差に基づいて決定される情報）を冗長情報無しで受信デバイスに送信して、現在のビデオフレームを送信するのに必要なビットの量を減らすことができる。

ビデオデコーダは、現在のビデオフレーム内の画素ブロックを、残差に基づいて再構築することができる。冗長情報を、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて、例えばビデオエンコーダによって実行される予測方法と同じ予測方法を用いて予測することができる。

一実施形態では、本開示のシステム及び方法は、レンダリングされたビデオフレームのシーケンスに関連付けられたグローバル動きヒント（global motion hints）を用いて、レンダリングされたビデオフレームのシーケンスを符号化するためにビデオエンコーダによって実行される動き補償予測処理を改善する。動き補償予測は、上述したように、符号化される現在のビデオフレーム内の画素ブロックに密接に一致する画素ブロックを参照ビデオフレーム内で検索することを含む。この検索処理を改善することによって、現在のビデオフレーム内の画素ブロックを符号化するのに用いられる時間及び／又はビットの量を減らすことができる。

他の実施形態では、本開示のシステム及び方法は、レンダリングされたビデオフレームのシーケンスに関連付けられたセミグローバル動きヒント（semi-global motion hints）を用いて、レンダリングされたビデオフレームのシーケンスを符号化するためにビデオエンコーダによって実行される動き補償予測処理を改善する。

上述した本開示のシステム及び方法の実施形態を、当業者が本明細書の教示に基づいて理解するように、動きヒントを利用可能なアプリケーション内で使用することができる。例えば、本開示の方法及びシステムを、動きヒントを生成するために、動き情報に関連付けられたユーザ入力コマンドを受信するビデオゲーム内で使用することができる。

本開示のこれらの特性及び他の特性と、様々な実施形態の構造及び動作とを、添付図面を参照して、より詳細に以下に説明する。

（２．例示的な動作環境）
図１は、本開示の実施形態を実装することの可能な例示的な動作環境の機能ブロック図１００である。ブロック図１００は、アプリケーション１０１と、レンダリングされたビデオフレーム１０２と、ビデオエンコーダ１０３と、動き予測１０４と、を含む。

アプリケーション１０１は、例えば、ビデオゲーム、ビデオ編集アプリケーション、コンピュータ支援設計（ＣＡＤ）アプリケーション、コンピュータ支援製造アプリケーション等のように、レンダリング及び表示用のビデオフレームを生成するエンドユーザアプリケーションであってよい。

レンダリングされると、レンダリングされたビデオフレーム１０２のシーケンスを、ネットワークを介して受信デバイスに記憶又は送信するのに必要なビットの量を減らすように符号化するために、レンダリングされたビデオフレーム１０２のシーケンスがビデオエンコーダ１０３に提供され得る。例えば、ビデオエンコーダ１０３は、レンダリングされたビデオフレーム１０２のシーケンスを記憶又は送信するのに必要なビットの量を、冗長な画像情報を除去することによって減らす。一実施例では、レンダリングされたビデオフレーム１０２のシーケンス内で近接したビデオフレームは、通常、非常に類似しており、各ビデオフレームが描写するシーン内の１つ以上の物体が、ビデオフレーム間でわずかに移動する点でのみ異なることが多い。

動き予測１０４は、少なくとも一実施例では、符号化される現在のビデオフレーム内の画素ブロックに密接に一致する画素ブロックについて、レンダリングされたビデオフレーム１０２のシーケンス内の参照ビデオフレームを検索することによって、ビデオフレーム間の時間冗長性を利用するように構成され得る。現在のビデオフレーム及び参照ビデオフレームは、レンダリングされたビデオフレーム１０２のシーケンス内で連続するビデオフレームであってもよいし、時間的にさらに間隔が開いていてもよい。参照ビデオフレーム内の密接に一致する画素ブロックが既に受信デバイスに送信されていると仮定すると、動き予測１０４は、参照ビデオフレーム内の密接に一致する画素ブロックを用いて冗長化した現在のビデオフレーム内の画素ブロックの内容を受信デバイスに送信する必要が一般的にない、という事実を利用する。代わりに、動き予測１０４は、参照ビデオフレーム内の密接に一致する画素ブロックに基づいて画素ブロックの予測を形成して、冗長情報を決定する。そして、この予測を画素ブロックから減算して、残差のみを残す。この処理は、動き補償予測と呼ばれる。そして、残差（又は、残差に基づいて決定される情報）を冗長情報無しで受信デバイスに送信して、現在のビデオフレームを送信するのに必要なビットの量を減らすことができる。

図２は、本開示の実施形態による、画素ブロックを符号化するためにビデオエンコーダ１０３によって用いられる従来の動き補償予測処理２００のさらなる詳細を示す図である。上述したように、動き補償予測処理は、符号化される現在のビデオフレーム２０６内の画素ブロック２０７に密接に一致する画素ブロックを参照ビデオフレーム２０１内で検索することを含み得る。参照ビデオフレーム２０１全体を検索することは、メモリ及び計算複雑性の観点において非常に高くつくことがあるため、ソフトウェアビデオエンコーダ及びハードウェアビデオエンコーダの実際の実装形態では、参照ビデオフレーム２０１の選択されたエリア（検索範囲２０２と呼ばれる）を検索することができる。検索範囲２０２は、参照ビデオフレーム２０１内であって、先に符号化された画素ブロックに基づいて計算された予測動きベクトル２０５の周囲に存在し得る。

多くの場合、特にハードウェアエンコーダ実装形態においては、ビデオエンコーダは、参照ビデオフレーム２０１全体を記憶するのに十分なメモリを備えていないことがある。このため、参照ビデオフレーム２０１のサブセット（検索ウィンドウ２０３と呼ばれる）を記憶することができ、予測動きベクトル２０５は、検索ウィンドウ２０３内に留まるように制限され得る。検索ウィンドウ２０３は、通常、参照ビデオフレーム２０１内の画素ブロック２０４上に中心が置かれ、現在のビデオフレーム２０６内の画素ブロック２０７と同じ相対位置に位置している。この画素ブロック２０４は、配置ブロックとよく呼ばれ得る。図２に示すように、検索範囲２０２の一部は、検索ウィンドウ２０３の外側にあってもよい。かかる場合、実際の検索エリア２０８は、検索ウィンドウ２０３と検索範囲２０２との間の重複領域となる。

一般に、検索ウィンドウ２０３を小さくするほど、必要とされるメモリ設置面積が小さくなり、図１に示したビデオエンコーダ１０３を実装する費用が安くなる。しかし、比較的速い動きのあるシーンを表現するビデオフレームでは、又は、符号化されるフレームから大きな時間的距離を有するフレームを参照フレームとして使用する場合には、検索ウィンドウ２０３の大きさをあまりにも制限することは、ビデオフレーム間の動きを効果的に捕らえるための動き補償予測処理の失敗につながることがある。この失敗は、画素ブロック２０７によって描画された物体が、検索ウィンドウ２０３の外に移動してしまった可能性が高いことから発生する。現実には、このことは、画素ブロック２０７を、イントラ予測ブロック、又は、高エネルギー残差を有するインター予測ブロックとして符号化する結果となり得る。何れの場合においても、画素ブロック２０７を符号化するのに用いられるビットの数は、通常、検索ウィンドウ２０３がビデオフレーム間の動きをより良く捕らえるのに十分に大きい場合と同じレベルの符号化画像品質を維持するために、増やす必要がある。以下に説明するように、本開示のシステム及び方法の実施形態は、検索ウィンドウ２０３の大きさと、画素ブロック２０７を符号化するのに必要なビットの数との間のトレードオフを、参照ビデオフレーム２０１と、現在のビデオフレーム２０６とに関連付けられた動きヒントを利用することによって軽減するのに役立つことができる。

（３．ビデオ符号化のための検索ウィンドウを適応的に配置するためのシステム及び方法）
図３は、本開示の実施形態による機能ブロック図３００である。機能ブロック図３００では、適応検索ウィンドウポジショナー３０４が追加され、既存のブロックに対していくつかの変更が行われたこと以外は、図１の機能ブロック図１００と実質的に類似している。特に、アプリケーション３０１は、少なくとも一実施形態において、レンダリングされたビデオフレーム３０２のシーケンスに関連付けられた動きヒント３０８を出力として提供するように変更されている。

適応検索ウィンドウポジショナー３０４は、アプリケーション３０１と動き予測３０５との間の中間段階であり、アプリケーション３０１によって生成されたシーンを、適応検索ウィンドウポジショナー３０４上で補償予測を用いて符号化する。適応検索ウィンドウポジショナー３０４は、一致する画素ブロックを、動きヒント３０８を用いて知的に検索することによって、動き予測をより効果的に行うことができる。一実施形態では、適応検索ウィンドウポジショナー３０４は、ビデオエンコーダ３０３に含まれている。

一実施例では、適応検索ウィンドウポジショナー３０４は、動き予測３０５によって実行される動き補償予測処理を進めるために、動きヒント３０８を処理するように構成されている。一実施形態では、動き予測３０５は、ビデオエンコーダ３０３に含まれている。一実施形態では、動きヒント３０８は、１つの動きベクトルを含むことができる。当業者が理解するように、動きヒント３０８を用いて、１つの動きベクトルを生成することができる。この動きベクトルは、現在のビデオフレーム２０６全体に関連付けられてもよく、参照ビデオフレーム２０１に関連付けられた全ブロックの動きを予測する。言い換えれば、この１つの動きベクトルは、グローバル動きヒントを構成する。

他の実施形態では、動きヒント３０８は、多数の異なる動きベクトルを含むことができる。代替的に、他の実施形態では、動きヒント３０８を用いて、多数の異なる動きベクトルを生成することができる。異なる動きベクトルの各々は、現在のビデオフレーム２０６内の異なる画像領域に関連付けられており、各動きベクトルを用いて、参照ビデオフレーム２０１内の対応する領域に関連付けられたブロックの動きを予測する。言い換えれば、これらの２つの実施形態では、動きヒント３０８は、セミグローバル動きヒントを提供する。

動きヒント３０８が１つの動きベクトル又は多数の動きベクトルに関連付けられているかどうかに関わらず、動きヒント３０８がビデオエンコーダ３０３によって用いられることで、現在のビデオフレーム２０６内の画素ブロック２０７をより効果的に符号化することができる。特に、アプリケーション３０１によって提供される動きヒント３０８を用いて、画素ブロック２０７が存在する現在のビデオフレーム２０６の画像領域に関連付けられた動きベクトルを検出することができる。そして、この動きベクトルを用いて、画素ブロック２０７の動きを参照ビデオフレーム２０１からより良く捕らえるために、検索ウィンドウ２０３を、参照ビデオフレーム２０１内でより良く配置することができる。検索ウィンドウ２０３は、画素ブロック２０７の動きを参照ビデオフレーム２０１から捕らえるようにより良く配置されているため、画素ブロック２０７を符号化するのに必要なビットの数を増やさない一方で、符号化した画像の品質のレベルを維持しながら検索ウィンドウ２０３を小さくすることができる。

上記の結果として、いくつかの利点が様々な状況で得られ又は現れ得る。例えば、上述した動きヒントの結果として、本明細書で説明する実施形態の態様を用いるクラウドサーバ又は他のリモートサーバは、フレームを、より迅速に、並びに／又は、より少ない処理要件及び／若しくは電力要件で符号化することができる。また、このようにレンダリングされたフレームは、エンドユーザデバイスのユーザにおいて、より高い知覚品質、又は、代替的に、短縮された遅延で先行技術の手法と等しい品質を有した状態で、見られ得る。したがって、かかるクラウドサーバ又はリモートサーバと、エンドユーザデバイスとを包含するシステムは、より良い効率で動作することができる。

図４を参照すると、本開示の実施形態による、適応検索ウィンドウポジショナー３０４の動作のさらなる詳細が示されている。特に、図４は、現在のビデオフレーム２０６内の１つ以上の異なる画像領域を参照ビデオフレーム２０１から符号化するのを補助するために、動きヒント３０８に関連付けられた１つ以上の動きベクトルを用いることを詳述している。

一実施例では、アプリケーション３０１は、１つ以上のアプリケーション領域を現在のビデオフレーム２０６内に生成する。各アプリケーション領域の大きさ及び位置は、アプリケーション３０１によって決定され得る。例えば、図４では、現在のビデオフレーム２０６は、３つのアプリケーション領域から構成されている。アプリケーション領域４０１は、例えば、現在のビデオフレーム２０６の右下に位置している。当業者が理解するように、様々な戦略を用いて、アプリケーション領域の大きさ及び位置を選択することができる。

適応検索ウィンドウポジショナー３０４は、異なる動きベクトルを各アプリケーション領域に関連付けることができる。各動きベクトルは、アプリケーション３０１によって生成された動きヒント３０８に基づくことができる。一実施形態では、各動きベクトルは、動きヒント３０８に直接含まれている。他の実施形態では、各動きベクトルは、動きヒント３０８から生成される。当業者が理解するように、動きベクトルを、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４の何れかによって生成することができる。さらに、当業者が理解するように、動きヒント３０８は、ユーザ入力型の動き情報と、非ユーザ入力型の動き情報とに基づくことができる。例えば、動きヒント３０８は、ビデオゲームアプリケーションが実行されているときにユーザによって入力されるコマンドに基づくことができる。

次に、適応検索ウィンドウポジショナー３０４によって、１つ以上のアプリケーション領域を１つ以上のサブ領域に分割することができる。例えば、アプリケーション領域４０１は、サブ領域４０２と、サブ領域４０４と、サブ領域４０６と、サブ領域４０８と、サブ領域４１０と、に分割される。各サブ領域の大きさ及び位置は、適応検索ウィンドウポジショナー３０４によって決定され得る。

サブ領域の粒度によって、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御することができる。当業者が理解するように、様々な戦略を活用して、このバランスを達成することができる。例えば、１つの戦略は、現在のビデオフレームを、それぞれ等しい大きさのサブ領域のセットに分割することから構成されている。潜在的には、より最適な戦略である他の戦略は、サブ領域の大きさ及び位置を、前のビデオフレーム内での動きベクトルの分布と、現在のビデオフレームと参照ビデオフレームとの間の時間差と、アプリケーションによって提供されるシーン変化ヒントと、に基づいて選択することから構成されている。

各サブ領域内の画素ブロックを、対応するアプリケーション領域に関連付けられた動きベクトルに基づいて符号化することができる。例えば、サブ領域４０２、サブ領域４０４、サブ領域４０６、サブ領域４０８及びサブ領域４１０は、アプリケーション領域４０１に関連付けられた動きベクトルに基づいて符号化される。

一実施例では、１つ以上のアプリケーション領域を１つ以上のサブ領域に分割した後に、サブ領域毎にアンカーブロックが定められる。一実施形態では、アンカーブロックは、現在のビデオフレーム２０６のサブ領域の第１のブロックとして定義される。例えば、図４では、アンカーブロック４１２は、アプリケーション領域４０１内のサブ領域４０２の第１のブロックである。

ここで、図５を参照すると、本開示の実施形態による、適応検索ウィンドウポジショナー３０４の動作のさらなる詳細が示されている。具体的には、アンカーブロックを定めた後に、適応検索ウィンドウポジショナー３０４は、現在のビデオフレーム内のブロックを符号化するための検索ウィンドウを何処に配置するのかを決定する。検索ウィンドウを何処に配置するのかは、サブ領域毎に決定される。

一実施例では、サブ領域内の画素ブロックを符号化するために、最初に、検索ウィンドウの中心が、関連する動きベクトルによって移動された、関連するアンカーブロックの配置ブロック位置上に置かれてもよい。例えば、図５では、現在のビデオフレーム５０５内の画素ブロック５０６は、サブ領域４０２内のアンカーブロック４１２に対応している。そして、画素ブロック５０６は、参照ビデオフレーム５０１内の配置ブロック５０３に対応している。したがって、検索ウィンドウ５０２の位置は、動きベクトル５０４によって移動された配置ブロック５０３の位置となる。

代替的に、動きヒントがアプリケーションによって提供されなかった場合には、検索ウィンドウは、移動することなく、参照ビデオフレーム内のアンカーブロックの配置ブロック位置上に中心が置かれる。例えば、図５では、検索ウィンドウ５０２の中心は、参照ビデオフレーム５０１内の配置ブロック５０３上に置かれる。

動きヒントが提供される場合には、アンカーブロックは、最初に、関連する動きベクトルによって移動されたアンカーブロックの配置ブロック位置上に中心が置かれた検索ウィンドウ５０２を用いて、符号化される。この検索ウィンドウを用いてアンカーブロックを符号化したときに動き予測３０５によって報告されるＲ−Ｄコストが閾値よりも大きい場合には、適応検索ウィンドウポジショナー３０４は、検索ウィンドウを他の位置に配置したときのレート歪み（Ｒ−Ｄ）コストを評価する。当業者が理解するように、閾値は、画素ブロックを符号化するのに必要なビット数が、符号化することの計算複雑性に対してバランスを取るような値に設定され得る。さらに、一実施形態では、閾値は、符号化戦略によって適応的に変化し得る。

図６は、本開示の実施形態による、検索ウィンドウを他の位置に配置したときのＲ−Ｄコストを評価するプロセスを示す図である。一実施例では、検索ウィンドウ６０３は、最初に、動きベクトル６０２によって移動された画素ブロック６０１に置かれている。この最初の位置は、図５の検索ウィンドウ５０２の位置に対応している。次に、追加検索ウィンドウの位置が特定される。例えば、図６では、７個の追加検索ウィンドウの位置６０４が特定されている。当業者が理解するように、追加検索ウィンドウの位置６０４の数は、計算複雑性及びビデオ符号化効率の間のバランスに基づくことができる。

様々な戦略を用いて、追加検索ウィンドウの位置６０４を選択することができる。これらの戦略は、先に符号化されたビデオフレーム、又は、同じビデオフレーム内で先に符号化されたブロックに基づくことができる。当業者が理解するように、１つの戦略は、最初の検索ウィンドウ（つまり、関連する動きベクトルによって移動された配置ブロックに位置する検索ウィンドウ）の位置６０３の周りで均一にサンプリングされたＮ個の位置を選択することである。

追加検索ウィンドウの位置６０４の数及び位置を特定した後に、適応検索ウィンドウポジショナー３０４は、検索ウィンドウを追加検索ウィンドウの各位置６０４に配置したときのＲ−Ｄコストを評価する。追加検索ウィンドウの各位置６０４のうち最小のＲ−Ｄコストが設定した閾値よりも高い場合、又は、当該閾値に等しい場合には、検索ウィンドウの位置は、検索ウィンドウの位置６０３に留まる。言い換えれば、検索ウィンドウは、関連する動きベクトルによって移動されたアンカーブロックの配置ブロック位置、例えば、図６の検索ウィンドウ６０３上に中心が置かれている。その一方で、追加検索ウィンドウの各位置６０４のうち最小のＲ−Ｄコストが閾値よりも低い場合には、検索ウィンドウは、最小のＲ−Ｄコストを有する追加検索ウィンドウの位置６０４に配置される。

最終的な検索ウィンドウの位置が選択されると、現在のサブ領域内の非アンカーブロックは、最終的な検索ウィンドウの位置を用いて符号化される。しかしながら、最終的な検索ウィンドウの位置は、非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。次に、１つのサブ領域内のブロックを符号化した後に、対応するアプリケーション領域内の他のサブ領域が符号化される。これらの他のサブ領域は、同一の最終的な検索ウィンドウの位置を継承する。しかしながら、最終的な検索ウィンドウの位置は、同様に、その領域での非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。

ここで、図７を参照すると、本開示の実施形態による、ビデオ符号化のために、検索ウィンドウを、動きヒントに基づいて適応的に配置する方法７００のフローチャートが示されている。一実施例では、方法７００は、図３〜図６を参照して上述したように、適応検索ウィンドウポジショナー３０４によって実装され得る。しかしながら、方法を、他のシステム及び構成要素によって実装することもできる、ということに留意すべきである。フローチャート７００の一部のステップを実行する必要がなく、及び／又は、図７に示す順に実行する必要がない、ということも留意すべきである。

ステップ７０２では、符号化される現在のビデオフレームと参照ビデオフレームとに関連付けられた動きヒント３０８を、アプリケーション３０１から受信する。当業者が理解するように、受信した動きヒント３０８は、ユーザ入力型の動き情報と、非ユーザ入力型の動き情報と、に基づくことができる。

ステップ７０４では、現在のビデオフレームが１つ以上のアプリケーション領域に分割される。一実施形態では、現在のビデオフレーム全体がアプリケーション領域を構成する。他の実施形態では、現在のビデオフレームが複数のアプリケーション領域に分割される。当業者が理解するように、様々な戦略を用いて、これらのアプリケーション領域の大きさ及び位置を選択することができる。一実施形態では、アプリケーション３０１は、ビデオフレームの分割戦略を定める。

また、１つ以上のアプリケーション領域は、１つ以上のサブ領域に分割される。一実施形態では、この分割は、適応検索ウィンドウポジショナー３０４によって実行される。サブ領域の粒度は、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御する。一実施形態では、１つのアプリケーション領域において１つのサブ領域のみが生成される。他の実施形態では、アプリケーション領域は、等しい大きさのサブ領域のセットに分割される。他の実施形態では、アプリケーション領域は、先のビデオフレーム内の動きベクトルの分布と、現在のビデオフレームと参照ビデオフレームとの間の時間差と、アプリケーション３０１によって提供されるシーン変化ヒントと、に基づいてサブ領域に分割される。

ステップ７０６では、ステップ７０２で受信した動きヒント３０８を用いて、１つ以上の動きベクトルを、１つ以上のアプリケーション領域に関連付ける。一実施形態では、各動きベクトルは、受信した動きヒント３０８に含まれている。他の実施形態では、各動きベクトルは、動きヒント３０８から生成される。当業者が理解するように、動きベクトルを、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４によって生成することができる。一実施形態では、１つ以上の動きベクトルの各々は、１つ以上のアプリケーション領域の何れかのアプリケーション領域に関連付けられる。当業者が理解するように、動きベクトルをアプリケーション領域に関連付けることは、アプリケーション３０１又は適応検索ウィンドウポジショナー３０４によって実行され得る。

ステップ７０８では、１つ以上のアプリケーション領域がサブ領域に分割される。一実施形態では、各サブ領域の大きさ及び位置は、適応検索ウィンドウポジショナー３０４によって決定される。１つ以上のサブ領域の粒度は、動き予測の精度と、メモリトラフィック要件と、計算複雑性との間のバランスを制御する。当業者が理解するように、様々な戦略を用いて、このバランスを達成することができる。

１つ以上のアプリケーション領域をサブ領域に分割した後に、アンカーブロックがサブ領域毎に定められる。一実施形態では、アンカーブロックは、サブ領域の第１のブロックとして定義される。

ステップ７１０では、検索ウィンドウの位置をサブ領域毎に決定する。検索ウィンドウの位置は、対応するアプリケーション領域に関連付けられた動きベクトルに基づいている。検索ウィンドウの中心は、最初に、関連する動きベクトルによって移動された、関連するアンカーブロックの配置ブロック位置上に置かれている。そして、アンカーブロックは、この位置の検索ウィンドウを用いて符号化される。アンカーブロックを検索ウィンドウの位置で符号化したときのＲ−Ｄコストが閾値よりも大きい場合には、追加検索ウィンドウの位置が試される。様々な戦略を用いて、追加検索ウィンドウの位置を選択することができる。

追加検索ウィンドウの位置を特定した後に、検索ウィンドウを追加検索ウィンドウの位置の各々に配置したときのＲ−Ｄコストが計算される。追加検索ウィンドウの位置間で最小のＲ−Ｄコストが上記で設定した閾値よりも高い又は等しい場合には、検索ウィンドウの位置は、最初の検索ウィンドウの位置に留まる。一方、追加検索ウィンドウの位置のうち最小のＲ−Ｄコストが閾値よりも小さい場合には、検索ウィンドウは、最小のＲ−Ｄコストを有する追加検索ウィンドウの位置に配置される。

ステップ７１２では、アンカーブロックが、最終的な検索ウィンドウの位置を用いて符号化される。また、サブ領域内の全ての非アンカーブロックが、最終的な検索ウィンドウの位置を用いて符号化される。しかしながら、非アンカーブロックについては、最終的な検索ウィンドウの位置は、各非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。

１つのサブ領域を符号化した後に、対応するアプリケーション領域内の他のサブ領域が符号化される。他のサブ領域の各々は、同一の最終的な検索ウィンドウの位置を継承する。しかしながら、検索ウィンドウの位置は、各サブ領域の対応するアンカーブロックに対して調整される。さらに、非アンカーブロックについては、検索ウィンドウの位置が、同様に、各非アンカーブロックとアンカーブロックとの間の位置の違いに基づいてシフトされる。

一実施形態では、図３の例示的なシステムを例示のために用いて、参照ビデオフレームと現在のビデオフレームとを生成するアプリケーション３０１によって受信された動き情報に基づいて、動きヒント３０８を生成することができる。そして、アプリケーション３０１は、レンダリングされたビデオフレームのシーケンスに関連付けられた動きヒント３０８を、ビデオエンコーダ３０３に提供することができる。

レンダリングは、三次元シーンを仮想カメラによって観察される視界に対応する二次元平面に投影することによって、ビデオフレームを取得するプロセスを含むことができる。仮想カメラからの三次元シーン内の物体の距離に関連する立体情報をレンダリング処理中に計算して、三次元シーン内の何れの物体が、レンダリングされたビデオフレーム内でユーザから見えるべきか又は見えないべきか、を決定することができる。例えば、三次元シーン内の特定の物体は、三次元シーン内の不透明な他の物体の後ろに存在するので、ユーザから見えなくすべきである。

図８を参照すると、本開示の実施形態による、動きヒントを生成する場合のカメラの動作と、アプリケーション３０１によって解析される立体情報と、のさらなる詳細が示されている。

例示的な動作では、アプリケーション３０１は、画像領域８０４を参照ビデオフレーム２０１内で選択する。そして、アプリケーション３０１は、深度値と、画像領域８０４内の二次元ポイント８０２（つまり、画素）とを関連付けることができる。一実施形態では、二次元ポイント８０２は、画像領域８０４の重心として選択され、深度値は、画像領域８０４内の二次元ポイント（つまり、画素）の平均深度値として設定される。一実施形態では、画像領域８０４内の二次元ポイントの深度値は、当該二次元ポイントが描写する三次元シーン８０８内の物質の仮想カメラ８１０からの距離に対応する。

そして、アプリケーション３０１は、二次元ポイント８０２を三次元シーン８０８内の三次元ポイント８０６にマッピングし直すことができる。当業者が理解するように、三次元ポイント８０６への二次元ポイント８０２のマッピングは、逆レンダリング処理であってもよく、参照ビデオフレーム２０１内の二次元ポイント８０２の位置と、関連する深度値と、参照ビデオフレーム２０１をレンダリングするために使用された仮想カメラ８１４の位置及び向きと、を用いて実行され得る。仮想カメラ８１０の位置及び向きは、アプリケーション３０１が利用可能である。

アプリケーション３０１は、現在のビデオフレーム２０６をレンダリングするのに用いられた仮想カメラ８１４の位置及び向きに基づいて三次元ポイント８０６をレンダリングすることによって、三次元ポイント８０６を現在のビデオフレーム２０６内の二次元ポイント８１２（つまり、画素）にマッピングすることができる。仮想カメラ８１４の位置及び向きは、同様に、アプリケーション３０１に提供され得る。

アプリケーション３０１は、二次元ポイント８０２と二次元ポイント８１２との位置の違いに基づいて、動きベクトル８１６を決定することができる。

アプリケーション３０１は、動きベクトル８１６（又は、動きベクトル８１６に基づいて決定されるいくつかの情報）を用いて、動きヒント３０８を決定することができる。アプリケーション３０１は、動きヒント３０８をビデオエンコーダ３０３に提供する。上述したように、ビデオエンコーダ３０３は、動きヒント３０８を用いて、検索ウィンドウを参照ビデオフレーム２０１内に配置しながら動き補償予測を実行して、現在のビデオフレーム２０６の画像領域８１８内の画素ブロックをより効果的に符号化することができる。

ここで、図９を参照すると、本開示の実施形態による、ビデオエンコーダによって実行される動き補償予測処理を進めるために動きベクトルを生成する方法のフローチャート９００が示されている。フローチャート９００の方法を、上述したアプリケーション３０１によって実装することができる。しかしながら、方法を、他のシステム及び構成要素によって実装することができる、ということに留意すべきである。フローチャート９００のステップのいくつかは、実行される必要がなく、又は、図９に示す順で実行される必要がない、ということにさらに留意すべきである。

ステップ９０２では、符号化される現在のビデオフレームと参照ビデオフレームとに関連付けられたカメラ情報及び立体情報が受信される。

ステップ９０４では、仮想カメラから見た参照ビデオフレームの領域内の二次元ポイント（つまり、画素）を、二次元ポイントに関連付けられた深度値に基づいて、及び、参照フレームのレンダリング中の仮想カメラの位置及び向きに基づいて、三次元ポイントにマッピングすることができる。一実施形態では、二次元ポイントを、参照ビデオフレームの重心として選択することができ、深度値は、参照ビデオフレームの画像領域内の二次元ポイント（つまり、画素）の平均深度値として設定される。一実施形態では、参照ビデオの画像領域内の二次元ポイントの深度値は、当該二次元ポイントが描写する物体の、当該二次元ポイントをレンダリングするのに用いられる仮想カメラからの距離に対応する。

ステップ９０６では、現在のフレームのレンダリング中の仮想カメラの位置及び向きに基づいて、三次元ポイントを、仮想カメラから見た現在のビデオフレーム内の二次元ポイントにマッピングすることができる。

ステップ９０８では、参照ビデオフレーム内の二次元ポイントと現在のビデオフレーム内の二次元ポイントとの位置の違いに基づいて、動きベクトルを決定することができる。

ステップ９１０では、動きベクトルに基づいて動きヒントを決定することができる。そして、現在のビデオフレームを符号化するためにビデオエンコーダによって実行される動き補償予測処理を進めるために、動きヒントをビデオエンコーダに提供することができる。例えば、ビデオエンコーダは、動きヒントを用いて検索ウィンドウを参照ビデオフレームに配置する一方で、現在のビデオフレーム内の画素ブロックをより効果的に符号化するために動き補償予測を実行することができる。

図３〜図９を参照して上述した本開示のシステム及び方法の実施形態を、クラウドゲームサービス内で動作しているサーバで用いて、例えば、当該サービス上でビデオゲームを行うことに関連する遅延量、ダウンストリーム帯域幅及び／又は計算処理能力を改善することができる。さらに、本開示の方法及びシステムを、当業者が本明細書の教示に基づいて理解するように、レンダリングされたビデオフレーム又は捕らえられたビデオフレームに関連する動きヒント情報を利用可能な他のアプリケーション内で使用することができる。例えば、本開示の方法及びシステムを、動き情報に関連するユーザコマンドを受信するビデオゲームアプリケーション内で使用することができる。

（４．例示的なコンピュータシステム実装形態）
本明細書で説明する本開示の様々な要素及び特性を、アナログ回路及び／又はデジタル回路を使用するハードウェアで実装してもよく、１つ以上の汎用プロセッサ又は専用プロセッサによる命令の実行を介してソフトウェアで実装してもよく、ハードウェア及びソフトウェアの組み合わせで実装してもよいことは、当業者において明らかである。

完全性のために、汎用コンピュータシステムの説明を以下に提供する。本開示の実施形態を、ハードウェアで、又は、ハードウェア及びソフトウェアの組み合わせで実装することができる。結果として、本開示の実施形態を、コンピュータシステム又は他の処理システムの環境で実装することができる。かかるコンピュータシステム１０００の一実施例を図１０に示す。図１及び図３に示したモジュールの全てを、１つ以上の個別のコンピュータシステム１０００上で実行することができる。さらに、図７に示したフローチャートのステップの各々を、１つ以上の個別のコンピュータシステム１０００上に実装することができる。

コンピュータシステム１０００は、例えばプロセッサ１００４等のように１つ以上のプロセッサを含む。プロセッサ１００４は、専用又は汎用のデジタル信号プロセッサであってもよい。プロセッサ１００４は、通信インフラストラクチャ１００２（例えば、バス又はネットワーク）に接続されている。様々なソフトウェア実装形態を、この例示的なコンピュータシステムの観点から説明する。本説明を読んだ後に、開示の実施形態を他のコンピュータシステム及び／又はコンピュータアーキテクチャを用いて実装する方法が当業者において明らかになる。

また、コンピュータシステム１０００は、メインメモリ１００６、好ましくはランダムアクセスメモリ（ＲＡＭ）を含んでもよいし、二次メモリ１００８を含んでもよい。二次メモリ１００８は、例えば、ハードディスクドライブ１０１０及び／又は取り外し可能ストレージドライブ１０１２（例えば、フロッピー（登録商標）ディスクドライブ、磁気テープドライブ、光ディスクドライブ等に代表される）を含んでもよい。取り外し可能ストレージドライブ１０１２は、周知の方法で、取り外し可能ストレージユニット１０１６からの読み出し、及び／又は、取り外し可能ストレージユニット１０１６への書き込みを行ってもよい。取り外し可能ストレージユニット１０１６は、例えば、フロッピー（登録商標）ディスク、磁気テープ、光ディスク等に代表され、取り外し可能ストレージドライブ１０１２によって読み出され、書き込まれる。当業者が理解するように、取り外し可能ストレージユニット１０１６は、コンピュータソフトウェア及び／又はデータを内部に記憶したコンピュータ可用ストレージ媒体を含む。

代替的な実装形態では、二次メモリ１００８は、コンピュータプログラム又は他の命令をコンピュータシステム１０００にロードすることを可能にするための他の同様の手段を含んでもよい。かかる手段は、例えば、取り外し可能ストレージユニット１０１８と、インターフェース１０１４とを含むことができる。かかる手段の例は、（例えば、ビデオゲームデバイスで見つかるもの等の）プログラムカートリッジ及びカートリッジインターフェースと、（例えば、ＥＰＲＯＭ又はＰＲＯＭ等の）取り外し可能メモリチップ及び関連ソケットと、サムドライブ及びＵＳＢポートと、取り外し可能ストレージユニット１０１８からコンピュータシステム１０００にソフトウェア及びデータを伝達することを可能にする他の取り外し可能ストレージユニット１０１８及びインターフェース１０１４と、を含んでもよい。

また、コンピュータシステム１０００は、通信インターフェース１０２０を含んでもよい。通信インターフェース１０２０は、コンピュータシステム１０００と外部デバイスとの間でソフトウェア及びデータを伝達することを可能にする。通信インターフェース１０２０の例は、モデムと、（イーサネット（登録商標）カード等の）ネットワークインターフェースと、通信ポートと、ＰＣＭＣＩＡスロット及びカード等と、を含んでもよい。通信インターフェース１０２０を介して伝達されるソフトウェア及びデータは、信号の形態であってもよいし、電子信号、電磁信号、光信号、又は、通信インターフェース１０２０が受信可能な他の信号であってもよい。これらの信号は、通信経路１０２２を介して通信インターフェース１０２０に提供される。通信経路１０２２は、信号を運ぶものであって、ワイヤ又はケーブルと、光ファイバと、電話線と、携帯電話リンクと、ＲＦリンクと、他の通信チャネルと、を用いて実装され得る。

本明細書で用いられるように、「コンピュータプログラム媒体」及び「コンピュータ可読媒体」という用語は、一般的に、取り外し可能ストレージユニット１０１６及び取り外し可能ストレージユニット１０１８等の有形ストレージ媒体、又は、ハードディスクドライブ１０１０にインストールされたハードディスクを指すのに用いられる。これらのコンピュータプログラム製品は、ソフトウェアをコンピュータシステム１０００に提供するための手段である。

（コンピュータ制御論理とも呼ばれる）コンピュータプログラムは、メインメモリ１００６及び／又は二次メモリ１００８に記憶されている。また、コンピュータプログラムを、通信インターフェース１０２０を介して受信することができる。かかるコンピュータプログラムは、実行されると、コンピュータシステム１０００が、本明細書で説明した本開示の内容を実装することを可能にする。特に、コンピュータプログラムは、実行されると、プロセッサ１００４が、本明細書で説明した方法のうち任意の方法等のように、本開示のプロセスを実行することを可能にする。したがって、かかるコンピュータプログラムは、コンピュータシステム１０００のコントローラを表している。開示した実施形態がソフトウェアを用いて実装されている場合には、ソフトウェアを、コンピュータプログラム製品に記憶することができ、取り外し可能ストレージドライブ１０１２、インターフェース１０１４又は通信インターフェース１０２０を用いて、コンピュータシステム１０００にロードすることができる。

他の実施形態では、本開示の特性を、主に、例えば特定用途向け集積回路（ＡＳＩＣ）及びゲートアレイ等のハードウェア構成要素を使用するハードウェアで実装することができる。本明細書で説明した機能を実行するためのハードウェア状態機械の実装形態は、当業者において明らかである。

発明の概要及び要約は、発明者によって考慮された１つ以上であるが全てとは限らない例示的な実施形態を示すことができる。したがって、これらは、実施形態及び添付の特許請求の範囲において、どのようにも限定されることを意図していない。

本明細書の実施形態を、機能ビルディングブロックの助けを用いて上述し、機能ビルディングブロックは、その特定の機能の実装形態と関係とを示している。これらの機能ビルディングブロックの境界は、本明細書では、説明の利便性のために任意に定義されている。代替的な境界を定めてもよく、境界は、特定の機能及びその関係が適切に実行される限りにおいて定められてもよい。

特定の実施形態の上記の説明は、実施形態の一般的な性質を完全に明らかにし、他者が当該技術分野における知識を応用することによって、様々なアプリケーションのために、過度の実験なしに、実施形態の一般的概念から逸脱することなしに、かかる実施形態を容易に変更及び／又は適応させることを可能にする。したがって、かかる適応物及び変更物は、本明細書に提示された教示及び助言に基づいて、開示の実施形態の均等物の意味及び範囲に含まれることが意図されている。本明細書の表現及び用語は、限定ではなく説明の目的のためであり、本明細書の用語及び表現は、本教示と助言とを踏まえて、熟練の技術者によって解釈されるものである、ということが理解される。

Claims (25)

1. 参照ビデオフレーム及び現在のビデオフレームを生成するアプリケーションが受信した動き情報に基づいて、動きヒントを生成することと、
   前記現在のビデオフレームを符号化するビデオエンコーダによって実行される動き補償予測処理を進めるために、前記動きヒントを前記ビデオエンコーダに提供することと、
   を備える、方法。
2. 前記参照ビデオフレーム及び前記現在のビデオフレームは、ビデオフレームのシーケンス内で連続するビデオフレームである、請求項１に記載の方法。
3. 前記動きヒントを前記ビデオエンコーダに提供することは、動きベクトルを前記ビデオエンコーダに提供することを含む、請求項１に記載の方法。
4. 前記ビデオエンコーダは、
   前記参照ビデオフレーム内の検索ウィンドウの位置に基づいて、アンカーブロックの符号化に対するレート歪み（Ｒ−Ｄ）コストを計算することであって、前記アンカーブロックは、前記現在のビデオフレームのサブ領域の第１のブロックである、ことと、
   前記Ｒ−ＤコストをＲ−Ｄ閾値と比較することと、
   前記比較に基づいて、追加検索ウィンドウの位置を前記参照ビデオフレーム内で特定することと、
   前記比較に基づいて、前記検索ウィンドウの位置を、前記追加検索ウィンドウの位置のうち何れかの位置に更新することと、
   を行う、請求項１に記載の方法。
5. 前記動きヒントを生成することは、
   前記現在のビデオフレームを領域に分割することと、
   前記動き情報に基づいて、前記領域のうち何れかの領域の動きベクトルを決定することと、
   を備える、請求項１に記載の方法。
6. 前記ビデオエンコーダは前記現在のビデオフレームの領域をサブ領域に分割し、各サブ領域はアンカーブロックを有する、請求項５に記載の方法。
7. 前記ビデオエンコーダは、動きベクトルの分布と、前記参照ビデオフレームと前記現在のビデオフレームとの間の時間差と、シーン変化ヒントと、のうち少なくとも１つに基づいて、前記現在のビデオフレームの領域をサブ領域に分割する、請求項６に記載の方法。
8. 前記ビデオエンコーダは、前記動きベクトルを用いて、前記現在のビデオフレームの領域のサブ領域内の画素ブロックを符号化するのに用いられる検索ウィンドウの位置を前記参照ビデオフレーム内で決定する、請求項５に記載の方法。
9. 前記ビデオエンコーダは、前記動きベクトルによって移動された前記サブ領域内のアンカーブロックを用いて、前記現在のビデオフレームのサブ領域内の画素ブロックを符号化するのに用いられる前記検索ウィンドウの位置を前記参照ビデオフレーム内で決定する、請求項８に記載の方法。
10. 前記ビデオエンコーダは、前記現在のビデオフレームのサブ領域内の画素ブロックを符号化するために、前記参照ビデオフレームの前記検索ウィンドウ内の検索範囲内で画素ブロックを検索する、請求項９に記載の方法。
11. 参照ビデオフレームと現在のビデオフレームとを生成するアプリケーションから動きヒントを受信することと、
    前記現在のビデオフレームを１つ以上の領域に分割することと、
    前記現在のビデオフレームの前記１つ以上の領域のうち何れかの領域内の画素ブロックを符号化するのに用いられる検索ウィンドウの位置を、前記動きヒントに基づいて前記参照ビデオフレーム内で決定することと、
    を行うように構成された適応検索ウィンドウポジショナーと、
    前記検索ウィンドウの位置に基づいて前記画素ブロックを符号化するように構成された動き予測デバイスと、
    を備える、システム。
12. 第１のビデオフレーム及び第２のビデオフレームは、ビデオフレームのシーケンス内で連続するビデオフレームである、請求項１１に記載のシステム。
13. 前記動きヒントは動きベクトルである、請求項１１に記載のシステム。
14. 前記適応検索ウィンドウポジショナーは、
    前記参照ビデオフレーム内の検索ウィンドウの位置に基づいて、アンカーブロックの符号化に対するレート歪み（Ｒ−Ｄ）コストを計算することであって、前記アンカーブロックは、前記現在のビデオフレームのサブ領域の第１のブロックである、ことと、
    前記Ｒ−ＤコストをＲ−Ｄ閾値と比較することと、
    前記比較に基づいて、追加検索ウィンドウの位置を前記参照ビデオフレーム内で特定することと、
    前記比較に基づいて、前記検索ウィンドウの位置を、前記追加検索ウィンドウの位置のうち何れかの位置に更新することと、
    をさらに行うように構成されている、請求項１１に記載のシステム。
15. 第１のビデオフレームを領域に分割することであって、前記領域のうち第１の領域は第１の二次元ポイントを含む、ことと、
    第２のビデオフレームを領域に分割することであって、前記領域のうち第１の領域は第２の二次元ポイントを含む、ことと、
    前記第１の二次元ポイントと前記第２の二次元ポイントとの間の動き情報に基づいて、動きベクトルを決定することと、
    前記動きベクトルを用いて動きヒントを生成することと、
    を備える、方法。
16. 前記動き情報は、前記第１の二次元ポイントと前記第２の二次元ポイントとの間の位置の違いに基づいている、請求項１５に記載の方法。
17. カメラを用いて前記第１のビデオフレームを見ることと、
    前記カメラの位置及び向きと、深度値と、に基づいて、前記第１の二次元ポイントを三次元ポイントにマッピングすることと、
    をさらに備える、請求項１６に記載の方法。
18. 前記カメラの前記位置及び向きに基づいて、前記三次元ポイントを前記第２の二次元ポイントにマッピングすること、
    をさらに備える、請求項１７に記載の方法。
19. 前記深度値は、三次元シーン内の物体の前記カメラからの距離である、請求項１７に記載の方法。
20. 第１のビデオフレームと第２のビデオフレームとを生成することと、
    前記第１のビデオフレームの第１の領域内の第１の二次元ポイントと、前記第２のビデオフレームの第２の領域内の第２の二次元ポイントと、の間の動き情報に基づいて、動きベクトルを決定することと、
    前記動きベクトルを用いて動きヒントを生成することと、
    を行うように構成されたアプリケーションモジュールと、
    前記アプリケーションモジュールから前記動きヒントを受信することと、
    前記動きヒントに基づいて、前記第２のビデオフレーム内の前記第２の領域内の画素ブロックを符号化するのに用いられる検索ウィンドウの位置を、前記第１のビデオフレーム内で決定することと、
    を行うように構成された適応検索ウィンドウポジショナーと、
    を備える、システム。
21. 前記画素ブロックを前記検索ウィンドウの位置に基づいて符号化するように構成された動き予測デバイス、
    をさらに備える、請求項２０に記載のシステム。
22. 前記アプリケーションモジュールは、前記第１の二次元ポイントと前記第２の二次元ポイントとの間の位置の違いに基づいて、前記動き情報を決定するようにさらに構成されている、請求項２０に記載のシステム。
23. 前記アプリケーションモジュールは、
    カメラを用いて、前記第１のビデオフレームを見ることと、
    前記カメラの位置及び向きと、深度値と、に基づいて、前記第１の二次元ポイントを三次元ポイントにマッピングすることと、
    を行うようにさらに構成されている、請求項２２に記載のシステム。
24. 前記アプリケーションモジュールは、前記カメラの位置及び向きに基づいて、前記三次元ポイントを前記第２の二次元ポイントにマッピングするようにさらに構成されている、請求項２３に記載のシステム。
25. 前記深度値は、三次元シーン内の物体の前記カメラからの距離である、請求項２３に記載のシステム。

Images