特許 7506700 履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-18

(45)【発行日】2024-06-26

(54)【発明の名称】履歴ベースの動きベクトル予測を用いるビデオコーディング方法及び装置

(51)【国際特許分類】

   H04N 19/52 20140101AFI20240619BHJP

【ＦＩ】

H04N19/52

【請求項の数】 12

【外国語出願】

(21)【出願番号】P 2022033329

(22)【出願日】2022-03-04

(62)【分割の表示】P 2021504164の分割

【原出願日】2019-07-16

(65)【公開番号】P2022071147

(43)【公開日】2022-05-13

【審査請求日】2022-03-04

(31)【優先権主張番号】62/700,106

(32)【優先日】2018-07-18

(33)【優先権主張国・地域又は機関】US

【前置審査】

(73)【特許権者】

【識別番号】521024075

【氏名又は名称】ベイジン・ダジア・インターネット・インフォメーション・テクノロジー・カンパニー，リミテッド

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100138759

【弁理士】

【氏名又は名称】大房 直樹

(74)【代理人】

【識別番号】100201743

【弁理士】

【氏名又は名称】井上 和真

(72)【発明者】

【氏名】ワーン，シアーンリン

(72)【発明者】

【氏名】チェン，イー－ウエン

【審査官】鉢呂 健

(56)【参考文献】

【文献】特許第７２０２４４４（ＪＰ，Ｂ２）

【文献】特表２０２１－５３０９０４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ １９／００－１９／９８

(57)【特許請求の範囲】

【請求項1】

ビデオデータの符号化方法であって、
符号化される現在のピクチャを複数の符号化ツリーユニット（ＣＴＵ）行に分割するステップであって、前記各ＣＴＵが１つ以上の符号化ユニット（ＣＵ）を含むステップと、
符号化される当該現在のピクチャ内の現在のＣＴＵ行における先頭のＣＵを符号化する前に、履歴ベースの動きベクトル予測子（ＨＭＶＰ）テーブルをリセットするステップと、
前記現在のＣＴＵ行の符号化を実行してビットストリームを生成するステップと
を備え、
前記符号化を実行するステップは、
前記ＨＭＶＰテーブル内の複数の動きベクトル予測子を整備するステップであって、前記ＨＭＶＰテーブル内の前記各動きベクトル予測子が前記現在のＣＴＵ行の少なくとも１つのＣＵを符号化するために使用されていたものである、ステップと、
符号化対象となる前記現在のＣＴＵ行の現在のＣＵについて、
前記現在のＣＵについて予測モードを選択し、
前記予測モードに従い、前記ＨＭＶＰテーブル内の前記複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成し、
前記動きベクトル候補リストから動きベクトル予測子を選択し、
前記現在のＣＵを符号化するために、前記予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、
当該決定された動きベクトルに基づいて前記ＨＭＶＰテーブルを更新するステップとを含む、方法。

【請求項2】

請求項１に記載の方法であって、
当該決定された動きベクトルに基づいて前記ＨＭＶＰテーブルを更新するステップは、
前記ＨＭＶＰテーブル内の前記複数の動きベクトル予測子を、当該決定された動きベクトルと比較するステップと、
前記ＨＭＶＰテーブル内の前記複数の動きベクトル予測子のいずれもが、当該決定された動きベクトルと同一ではないとの判定に応じて、
前記ＨＭＶＰテーブルが限度一杯であるときは前記ＨＭＶＰテーブルから最先の動きベクトル予測子を削除し、
当該決定された動きベクトルを最新の動きベクトルとして前記ＨＭＶＰテーブルに追加するステップと、
前記ＨＭＶＰテーブル内の前記複数の動きベクトル予測子のうちの１つが、当該決定された動きベクトルと同一であるとの判定に応じて、
前記同一である１つの動きベクトル予測子を前記ＨＭＶＰテーブルから削除し、
当該削除された動きベクトル予測子の後の当該動きベクトル予測子の各々を、前記ＨＭＶＰテーブル内で前方に移動させ、
当該決定された動きベクトルを最新の動きベクトルとして前記ＨＭＶＰテーブルに追加するステップと
をさらに含む方法。

【請求項3】

請求項１に記載の方法であって、前記ＨＭＶＰテーブルをリセットするステップは、前記ＨＭＶＰテーブル内の利用可能な動きベクトル予測子の個数をゼロに設定するステップを含む、方法。

【請求項4】

請求項１に記載の方法であって、前記予測モードは、インターモード，マージモード，及びスキップモードからなる群から選択されたものである、方法。

【請求項5】

請求項４に記載の方法であって、
前記予測モードは、前記インターモードであり、
前記現在のＣＵを符号化するステップは、
前記現在のＣＵについて動きベクトル差分を生成するステップと、
前記動きベクトル差分を当該選択された動きベクトル予測子に加算して、当該決定された動きベクトルを得るステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するＣＵとを用いて前記現在のＣＵを符号化するステップと
をさらに含む、方法。

【請求項6】

請求項４に記載の方法であって、
前記予測モードは、前記インターモードであり、
前記動きベクトル候補リストを構成するステップは、
前記現在のＣＵに対して時間的に近隣のＣＵ及び／又は時間的に連結するＣＵに由来するゼロ個以上の動きベクトル予測子を、前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの現在の長さが第１の所定しきい値に到達するまで、前記ＨＭＶＰテーブルに由来するゼロ個以上の履歴ベースの動きベクトル予測子を前記動きベクトル候補リストに追加するステップと、
前記動きベクトル候補リストの当該現在の長さが前記第１の所定しきい値と等しくなるまで、ゼロ個以上のゼロ値の動きベクトル予測子を前記動きベクトル候補リストに追加するステップと
をさらに含む、方法。

【請求項7】

請求項４に記載の方法であって、
前記予測モードは、前記マージモード及び前記スキップモードのうちの１つであり、
前記現在のＣＵを符号化するステップは、
当該決定された動きベクトルとして、当該選択された動きベクトル予測子を使用するステップと、
当該決定された動きベクトルと参照ピクチャ内の対応するＣＵとを用いて前記現在のＣＵを符号化するステップと
をさらに含む、方法。

【請求項8】

請求項１に記載の方法であって、符号化される前記現在のピクチャ内の２つ以上のＣＴＵ行が並列に符号化され、前記各ＣＴＵ行は、対応するＣＴＵ行を符号化するために使用された複数の履歴ベースの動きベクトル予測子を格納するように関連付けられたＨＭＶＰテーブルを有する、方法。

【請求項9】

請求項１に記載の方法であって、符号化される前記現在のピクチャ内の複数の異なるＣＴＵ行が複数の異なる関連スレッドを有するように、符号化される前記現在のピクチャ内の当該現在のＣＴＵ行を符号化することにスレッドを割り当てるステップをさらに備える方法。

【請求項10】

演算装置であって、
１つ以上のプロセッサと、
前記１つ以上のプロセッサに接続されたメモリと、
前記メモリに格納された複数のプログラムと
を備え、
前記複数のプログラムは、前記１つ以上のプロセッサにより実行されると、請求項１から９のうちのいずれか１項に記載の方法のステップを前記演算装置に実行させてビデオビットストリームを生成する、演算装置。

【請求項11】

１つ以上のプロセッサを有する演算装置による実行のために複数のプログラムを格納する非一時的なコンピュータ読み取り可能な記録媒体であって、
前記複数のプログラムは、前記１つ以上のプロセッサにより実行されると、請求項１から９のうちのいずれか１項に記載の方法のステップを前記演算装置に実行させてビデオビットストリームを生成し、当該ビデオビットストリームを前記非一時的なコンピュータ読み取り可能な記録媒体に格納させる、非一時的なコンピュータ読み取り可能な記録媒体。

【請求項12】

１つ以上のプロセッサを有する演算装置による実行のためのコンピュータプログラムであって、前記コンピュータプログラムは、前記１つ以上のプロセッサにより実行されると、請求項１から９のうちのいずれか１項に記載の方法のステップを前記演算装置に実行させてビデオビットストリームを生成する、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

[0001]本出願は、概してビデオデータの符号化及び復号に関し、特に、履歴ベースの動きベクトル予測を用いるビデオコーディング方法及びシステムに関するものである。

【背景技術】

【0002】

[0002]デジタルビデオは、デジタルテレビ、ラップトップ型又はデスクトップ型のコンピュータ、タブレット型コンピュータ、デジタルカメラ、デジタル記録装置、デジタルメディア再生装置、ビデオゲーム端末、スマートフォン、ビデオ会議装置、ビデオストリーミング装置といった種々の電子デバイスによってサポートされている。そのような電子デバイスは、ＭＰＥＧ－４、ＩＴＵ－ＴＨ．２６３、ＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４Ｐａｒｔ １０ ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＨＥＶＣ（高能率映像符号化：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）、ＶＶＣ（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）規格などで定められたビデオ圧縮伸張規格を実装することにより、デジタルビデオデータの送信、受信、符号化、復号、及び／又は格納を行う。一般にビデオ圧縮は、空間（フレーム内）予測及び／又は時間（フレーム間）予測を実行してビデオデータに内在する冗長性を低減又は除去する手順を含む。ブロックベースのビデオコーディングでは、ビデオフレームは１つ以上のスライスに分割され、各スライスは複数のビデオブロックを有し、ビデオブロックは符号化ツリーユニット（ＣＴＵ：ｃｏｄｉｎｇ ｔｒｅｅ ｕｎｉｔ）とも呼ばれうる。各ＣＴＵは、１つの符号化ユニット（ＣＵ：ｃｏｄｉｎｇ ｕｎｉｔ）を含むものでもよいし、あるいは、予め定められた最小のＣＵサイズに到達するまで、より小さな複数のＣＵに再帰的に分割されてもよい。各ＣＵ（リーフＣＵとも呼ばれる。）は単数又は複数の変換ユニット（ＴＵ：ｔｒａｎｓｆｏｒｍ ｕｎｉｔ）を含み、また各ＣＵは単数又は複数の予測ユニット（ＰＵ：ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）を含む。各ＣＵは、イントラモード、インターモード又はＩＢＣモードのいずれかで符号化されうる。ビデオフレームにおけるイントラ符号化（Ｉ）スライス内の複数のビデオブロックは、同じビデオフレーム内の近隣ブロックの参照サンプルに対して空間予測を用いて符号化される。ビデオフレームにおけるインター符号化（Ｐ又はＢ）スライス内の複数のビデオブロックは、同じビデオフレーム内の近隣ブロックの参照サンプルに対して空間予測を用いたものでもよいし、あるいは、過去及び／又は未来における別の参照ビデオフレームの参照サンプルに対して時間予測を用いたものでもよい。

【0003】

[0003]過去に符号化された参照ブロック（たとえば近隣ブロック）に基づく空間予測又は時間予測を実行すれば、符号化対象の現在のビデオブロックに対する予測ブロックが得られる。当該参照ブロックを探し出す処理は、ブロックマッチングアルゴリズムにより実行されればよい。符号化対象の現在のブロックと予測ブロックとの間の画素の差分を示す残差データを残差ブロック又は予測誤差と呼ぶ。インター符号化ブロックは、当該予測ブロックを形成する参照フレームを指す動きベクトルと残差ブロックとに従って符号化されたものである。動きベクトルを決定する処理は、一般に、動き推定と呼ばれている。イントラ符号化ブロックは、イントラ予測モードと残差ブロックとに従って符号化されたものである。さらなる圧縮のために、残差ブロックを画素領域から変換領域（たとえば周波数領域）へ変換することで残差変換係数が得られ、次にこれらは量子化される。量子化変換係数は、先ずは２次元配置で配列されており、これを走査して複数の変換係数からなる１次元ベクトルを生成し、次いで、さらなる圧縮を実現するためにエントロピー符号化を実行してビデオストリームを得てもよい。

【0004】

[0004]次に、その符号化ビデオストリームは、デジタルビデオ機能をもつ他の電子デバイスによりアクセスされるコンピュータ読み取り可能な記録媒体（たとえばフラッシュメモリ）に記録されるか、あるいは、有線又は無線でその電子デバイスに直接送信される。当該電子デバイスは、次いで、たとえば当該符号化ビットストリームを解析してそのビットストリームからシンタックス要素を取得し、そのビットストリームから得た当該シンタックス要素の少なくとも一部に基づいて、当該符号化ビットストリームから元のフォーマットへデジタルビデオデータを再構成することにより（上記ビデオ圧縮とは逆の処理である）ビデオ伸張を実行し、そして、当該再構成されたデジタルビデオデータを当該電子デバイスのディスプレイに描画する。

【0005】

[0005]デジタルビデオ品質がハイビジョン（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）から４Ｋ×２Ｋ又は８Ｋ×４Ｋに移行するにつれて、符号化／復号対象のビデオデータ量が指数関数的に増大する。復号ビデオデータの画質を維持しつつ、いかにしてビデオデータがより効率的に符号化／復号できるかという点での絶え間ない努力がある。

【発明の概要】

【0006】

[0006]本出願は、ビデオデータの符号化及び復号に関し、特に、履歴ベースの動きベクトル予測を用いたビデオ符号化及び復号の際におけるビデオデータの並列処理のシステム及び方法に関する実施形態について説明するものである。

【0007】

[0007]本出願の第１の態様によるビデオデータの符号化方法は、１つ以上のプロセッサと、当該１つ以上のプロセッサにより実行される複数のプログラムを格納するメモリとを有する演算装置で実施される。演算装置は、符号化される現在のピクチャを複数の符号化ツリーユニット（ＣＴＵ）行に分割することから始め、各ＣＴＵは、１つ以上の符号化ユニット（ＣＵ）を含む。符号化される現在のピクチャ内の現在のＣＴＵ行の先頭のＣＵを符号化することを開始する前に、演算装置は、履歴ベースの動きベクトル予測子（ＨＭＶＰ）テーブルをリセットする。次いで、ビットストリームを生成するために現在のＣＴＵ行の符号化が実行される。演算装置は、ＨＭＶＰテーブル内の複数の動きベクトル予測子を整備する。各動きベクトル予測子は、少なくとも１つのＣＵを符号化するために使用されたものである。符号化対象となる現在のＣＴＵ行の現在のＣＵについて、演算装置は、現在のＣＵについて予測モードを選択し、当該予測モードに従い、ＨＭＶＰテーブル内の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成する。動きベクトル候補リストから動きベクトル予測子を選択した後は、演算装置は、当該予測モードと当該選択された動きベクトル予測子との少なくとも一部に基づいて動きベクトルを決定し、当該決定された動きベクトルを用いて現在のＣＵを符号化し、当該決定された動きベクトルに基づいてＨＭＶＰテーブルを更新する。

【0008】

[0008]本出願の第２の態様による演算装置は、１つ以上のプロセッサと、メモリと、当該メモリに格納された複数のプログラムとを含む。そのプログラムは、１つ以上のプロセッサにより実行されると、上記した処理を演算装置に実行させる。

【0009】

[0009]本出願の第３の態様による非一時的なコンピュータ読み取り可能な記録媒体は、１つ以上のプロセッサを有する演算装置による実行のための複数のプログラムを格納する。そのプログラムは、１つ以上のプロセッサにより実行されると、上記した処理を演算装置に実行させる。

【0010】

[0010]添付図面は、実施形態のさらなる理解を与えるべく含められ、かつ本願に組み入れられたものであり、本明細書の一部を構成し、説明される実施形態を図示し、その説明とともにその基礎をなす原理を説明する役目を果たすものである。対応する構成要素には、同じ参照符号が付されている。

【図面の簡単な説明】

【0011】

【図1】[0011]図１は、本開示のいくつかの実施形態に係るビデオ符号化・復号システムの例を示すブロック図である。

【図2】[0012]図２は、本開示のいくつかの実施形態に係るビデオ符号化器の例を示すブロック図である。

【図3】[0013]図３は、本開示のいくつかの実施形態に係るビデオ復号器の例を示すブロック図である。

【図4A】[0014]図４Ａは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。

【図4B】[0014]図４Ｂは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。

【図4C】[0014]図４Ｃは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。

【図4D】[0014]図４Ｄは、本開示のいくつかの実施形態に従って、複数の異なるサイズを有する複数のビデオブロックへフレームを再帰的に四分木分割する方法を示すブロック図である。

【図5A】[0015]図５Ａは、本開示のいくつかの実施形態に従って、符号化対象である現在のＣＵに対して空間的に近隣でかつ時間的に連結するブロック位置を示すブロック図である。

【図5B】[0016]図５Ｂは、本開示のいくつかの実施形態に従って、波面並列処理を用いてピクチャ内の複数のＣＴＵ行をマルチスレッド符号化することを示すブロック図である。

【図6】[0017]図６は、本開示のいくつかの実施形態に従って、動きベクトル予測子の候補リストを構成する技術を実現するビデオコーダによる処理例を示すフローチャートである。

【発明を実施するための形態】

【0012】

[0018]具体的な実施形態について以下に詳細に言及し、当該実施の形態の例を添付図面に示す。以下の詳細な説明においては、本明細書で示される主題を理解する助けとなるように、限定されない多くの具体的に詳細な内容が示されている。ただし、請求項の範囲から逸脱せずに種々の変形例が使用されうること、並びに、それら具体的に詳細な内容がなくとも主題が実施されうることは、当業者であれば明らかであろう。たとえば、本明細書に示される主題が、デジタルビデオ機能をもつ種々の電子デバイスにて実現可能であることは、当業者であれば明らかであろう。

【0013】

[0019]図１は、本開示のいくつかの実施形態に従い、ビデオブロックを並列に符号化し復号するための例示的なシステム１０を示すブロック図である。図１に示されるようにシステム１０は、後の時点で送信先（デスティネーション）装置１４で復号されることとなるビデオデータを生成し符号化する情報源（ソース）装置１２を備えている。情報源装置１２及び送信先装置１４は、デスクトップ型もしくはラップトップ型のコンピュータ，タブレット型コンピュータ，スマートフォン，セットトップボックス，デジタルテレビジョン，カメラ，表示装置，デジタルメディア再生装置，ビデオゲーム端末，又はビデオストリーミング装置などを含む幅広い種類の任意の電子デバイスを備えてよい。いくつかの実施形態では、情報源装置１２及び送信先装置１４は無線通信機能を搭載している。

【0014】

[0020]いくつかの実施形態では、送信先装置１４は、復号されることとなる符号化ビデオデータをリンク１６を介して受信してよい。リンク１６は、情報源装置１２から送信先装置１４に符号化ビデオデータを転送する任意の種類の通信媒体又はデバイスを備えてよい。１つの例として、リンク１６は、情報源装置１２がリアルタイムに符号化ビデオデータを送信先装置１４に直接送信することを可能とする通信媒体を備えてよい。符号化ビデオデータは、無線通信プロトコルなどの通信規格に従って変調されて送信先装置１４に送信されてもよい。当該通信媒体は、無線周波数（ＲＦ）又は１つ以上の物理的な送信ラインといった任意の無線又は有線の通信媒体を備えてよい。当該通信媒体は、ローカルエリアネットワーク，広域ネットワーク，又はインターネットなどのグルーバルネットワークといった、パケットベースのネットワークの一部を構成するものでもよい。当該通信媒体は、情報源装置１２から送信先装置１４への通信を実現するために使用される、ルータ，スイッチ，基地局又はその他の機器を含んでもよい。

【0015】

[0021]他のいくつかの実施形態では、符号化ビデオデータは、出力インタフェース２２から記録装置３２に送信されてもよい。その後、記録装置３２内の当該符号化ビデオデータは、入力インタフェース２８を介して送信先装置１４によりアクセスされてよい。記録装置３２は、符号化ビデオデータを記録するために、ハードドライブ（ｈａｒｄ ｄｒｉｖｅ），ブルーレイディスク，ＤＶＤ，ＣＤ－ＲＯＭ，フラッシュメモリ，揮発性もしくは不揮発性のメモリ，又はその他任意の適当なデジタル記録媒体などの、分散化された又はローカルにアクセスされた任意の種々のデータ記録媒体を含んでよい。さらに他の例としては、記録装置３２は、情報源装置１２で生成された符号化ビデオデータを保持しうるファイルサーバ又は他の中間記録装置に相当するものでもよい。送信先装置１４は、記録装置３２からのストリーミング又はダウンロードを通じて記録済みビデオデータにアクセスしてもよい。ファイルサーバは、符号化ビデオデータを格納して当該符号化ビデオデータを送信先装置１４に送信する機能をもつ任意の種類のコンピュータであってよい。ファイルサーバの例には、（たとえばウェブサイト用の）ウェブサーバ，ＦＴＰサーバ，ネットワーク接続ストレージ（ＮＡＳ：ｎｅｔｗｏｒｋ ａｔｔａｃｈｅｄ ｓｔｏｒａｇｅ）装置，又はローカルディスクドライブが含まれる。送信先装置１４は、無線チャネル（たとえばＷｉ－Ｆｉ接続），有線接続（たとえばＤＳＬやケーブル媒体など），又はこれら両方の組合せを含むような、ファイルサーバに記録された符号化ビデオデータへのアクセスに適した任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスしうる。記録装置３２からの符号化ビデオデータの送信は、ストリーミング送信，ダウンロード送信，又はこれら両方の組合せであってよい。

【0016】

[0022]図１に示されるように情報源装置１２は、ビデオ源１８，ビデオ符号化器２０及び出力インタフェース２２を含む。ビデオ源１８は、たとえば、ビデオカメラ，過去に取得されたビデオを格納するビデオアーカイブ，ビデオコンテンツプロバイダからビデオを受信するビデオ供給インタフェース，及び／又は，情報源のビデオとしてコンピュータグラフィックスを生成するコンピュータグラフィックスシステムといったビデオキャプチャ装置などの情報源（ソース）を含んでいればよい。一例として、ビデオ源１８が安全監視システムのビデオカメラであるとき、情報源装置１２及び送信先装置１４は、カメラ電話機又はビデオ電話機を構成してもよい。ただし、本出願で説明される実施形態は、一般にビデオコーディングに適用可能なものであればよく、無線及び／又は有線の用途に適用されればよい。

【0017】

[0023]そのように取得もしくは以前に取得され、又はコンピュータで生成されたビデオは、ビデオ符号化器２０により符号化されうる。その符号化ビデオデータは、情報源装置１２の出力インタフェース２２を通じて送信先装置１４に直接送信されればよい。また（又はその代わりに）その符号化ビデオデータは、送信先装置１４又はその他の装置からの後のアクセスのため、復号及び／又は再生のために記録装置３２に記録されればよい。さらに出力インタフェース２２は、モデム及び／又は送信器を含んでもよい。

【0018】

[0024]送信先装置１４は、入力インタフェース２８，ビデオ復号器３０及び表示装置３４を含む。入力インタフェース２８は、受信器及び／又はモデムを含んでリンク１６を介して符号化ビデオデータを受信してもよい。リンク１６を介して通信された符号化ビデオデータ、又は、記録装置３２で供給された符号化ビデオデータは、ビデオ符号化器２０により生成された各種のシンタックス要素を、ビデオ復号器３０でのビデオデータの復号に使用するために含んでいてもよい。そのようなシンタックス要素は、通信媒体で送信された符号化ビデオデータ内に組み込まれ、記録媒体に記録され、あるいはファイルサーバに記録されればよい。

【0019】

[0025]いくつかの実施形態では、送信先装置１４は表示装置３４を含んでもよく、この表示装置３４は、統合型の表示装置や、送信先装置１４と通信するように構成された外部表示装置とすることができる。表示装置３４は、復号されたビデオデータをユーザに表示するものであり、液晶表示ディスプレイ（ＬＣＤ：ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ），プラズマディスプレイ，有機発光ダイオード（ＯＬＥＤ）ディスプレイ，又は他タイプの表示装置など、種々の任意の表示装置を備えたものであればよい。

【0020】

[0026]ビデオ符号化器２０及びビデオ復号器３０は、ＶＶＣ，ＨＥＶＣ，ＭＰＥＧ－４ Ｐａｒｔ１０ ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ），又はこれらの規格の拡張版など、知的所有物又は業界規格に基づいて動作すればよい。本出願は、特定のビデオ符号化／復号規格に限定されるものではなく、他のビデオ符号化／復号規格に適用可能であってよいことを理解すべきである。情報源装置１２のビデオ符号化器２０が現在又は将来の規格のいずれかに従ってビデオデータを符号化するように構成されてよいことが、通常考えられることである。同様に、送信先装置１４のビデオ復号器３０が現在又は将来の規格のいずれかに従ってビデオデータを復号するように構成されてよいことも、通常考えられることである。

【0021】

[0027]ビデオ符号化器２０及びビデオ復号器３０は、それぞれ、１つ以上のマイクロプロセッサ，デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ），特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ），フィールドプログラマブルゲートアレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ），ディスクリートロジック（個別論理回路：ｄｉｓｃｒｅｔｅ ｌｏｇｉｃ），ソフトウェア，ハードウェア，ファームウェア，又はこれらの組合せといった種々の任意の適切な符号化回路として実現されればよい。ソフトウェアで部分的に実現される場合には、電子デバイスは、適切な非一時型のコンピュータ読み取り可能な媒体に当該ソフトウェア用の命令を格納し、１つ以上のプロセッサを用いたハードウェアで当該命令を実行して本開示に開示されたビデオ符号化／復号処理を実行すればよい。ビデオ符号化器２０及びビデオ復号器３０の各々は、１つ以上の符号化器又は復号器に組み込まれたものでよく、当該符号化器又は復号器のどちらかが複合型の符号化器／復号器（ＣＯＤＥＣ）の一部として各装置に統合されていればよい。

【0022】

[0028]図２は、本出願で説明されるいくつかの実施形態に係る例示的なビデオ符号化器２０を示すブロック図である。ビデオ符号化器２０は、ビデオフレーム内におけるビデオブロックのイントラ予測符号化及びインター予測符号化を実行しうる。イントラ予測符号化は、所与のビデオフレーム又はピクチャ内のビデオデータの空間的な冗長度を低減又は除去するために空間予測に依存する。インター予測符号化は、ビデオシーケンスの隣接するビデオフレーム又はピクチャ内のビデオデータの時間的な冗長度を低減又は除去するために時間予測に依存する。

【0023】

[0029]図２に示されるようにビデオ符号化器２０は、ビデオデータメモリ４０，予測処理部４１，復号ピクチャバッファ（ＤＰＢ：ｄｅｃｏｄｅｄ ｐｉｃｔｕｒｅ ｂｕｆｆｅｒ）６４，加算器５０，変換処理部５２，量子化部５４及びエントロピー符号化部５６を含む。予測処理部４１は、動き推定部４２，動き補償部４４，分割部４５，イントラ予測処理部４６及びイントラブロックコピー（ＢＣ）部４８を含む。いくつかの実施形態では、ビデオ符号化器２０は、さらにビデオブロックの再構成のために、逆量子化部５８，逆変換処理部６０及び加算器６２を含む。再構成されたビデオからブロック歪を除去するために加算器６２とＤＰＢ６４との間にデブロッキングフィルタ（図示せず）が配置されればよい。デブロッキングフィルタに加えて、加算器６２の出力をフィルタリングするためにループ内フィルタ（図示せず）が使用されてもよい。ビデオ符号化器２０は、変更不能な又はプログラマブルなハードウェアユニットの形態を有していてよいし、あるいは、図示されるような１つ以上の変更不能な又はプログラマブルなハードウェアユニットのうちに分割されていてもよい。

【0024】

[0030]ビデオデータメモリ４０は、ビデオ符号化器２０の構成要素で符号化されるべきビデオデータを格納すればよい。ビデオデータメモリ４０内のビデオデータは、たとえばビデオ源１８から取得されればよい。ＤＰＢ６４は、ビデオ符号化器２０でビデオデータを符号化する際に使用される参照ビデオデータを格納するバッファである。ビデオデータメモリ４０及びＤＰＢ６４は、任意の種々のメモリデバイスで構成されていればよい。種々の例において、ビデオデータメモリ４０は、ビデオ符号化器２０の他の構成要素とともにチップに実装されてよいし、あるいは、他の構成要素に対してチップ外に実装されてよい。

【0025】

[0031]図２に示されるように、ビデオデータの受信後、予測処理部４１内の分割部４５は、当該ビデオデータを複数のビデオブロックに分割する。この分割には、当該ビデオデータに関連付けられた四分木構造などの所定の分割構造に従って、ビデオフレームを複数のスライス又はより大きな複数の符号化ユニット（ＣＵ）に分割することが含まれてもよい。ビデオフレームは、複数のビデオブロック（又は、タイルと称されるビデオブロックの複数組）に分割されればよい。予測処理部４１は、エラー結果（たとえば、符号化レート及び歪みレベル）に基づいて、現在のビデオブロックに対し、複数のイントラ予測符号化モードのうちの１つ又は複数のインター予測符号化モードのうちの１つなどの、選択可能な複数の予測符号化モードのうちの１つを選択すればよい。予測処理部４１は、得られたイントラ予測符号化ブロック又はインター予測符号化ブロックを加算器５０に供給して残差ブロックを生成させるとともに、加算器６２にも供給して後に参照フレームの一部として使用される符号化ブロックを再構成させればよい。また予測処理部４１は、動きベクトル，イントラモード予測子，分割情報及びその他のシンタックス情報といったシンタックス要素をエントロピー符号化部５６に供給する。

【0026】

[0032]現在のビデオブロックについて適切なイントラ予測符号化モードを選択するために、予測処理部４１内のイントラ予測処理部４６は、符号化対象となる現在のブロックと同じフレーム内の１つ以上の近隣ブロックに対して現在のビデオブロックのイントラ予測符号化を実行して空間予測を提供すればよい。予測処理部４１内の動き推定部４２及び動き補償部４４は、１つ以上の参照フレーム内の１つ以上の予測ブロックに対して現在のビデオブロックのインター予測符号化を実行して時間予測を提供する。ビデオ符号化器２０は、たとえばビデオデータの各ブロックについて適切な符号化モードを選択するために、複数の符号化手順を実行してよい。

【0027】

[0033]いくつかの実施形態では、動き推定部４２は、ビデオフレームのシーケンス内の所定パターンに従って、参照フレーム内の予測ブロックに対する現在のビデオフレーム内のビデオブロックの予測ユニット（ＰＵ）の位置ずれを示す動きベクトルを生成することにより、現在のビデオフレームについてのインター予測符号化モードを決定する。動き推定は、動き推定部４２によって実行されるものであり、ビデオブロックについての動きを推定する動きベクトルを生成する処理である。動きベクトルは、たとえば、現在のフレーム内（又は他の符号化ユニット内）の符号化される現在のブロックに対して、参照フレーム内（又は他の符号化ユニット内）の予測ブロックに対する現在のビデオフレーム又はピクチャ内のビデオブロックのＰＵの位置ずれを示すものでよい。上記所定パターンは、当該シーケンス内の複数のビデオフレームをＰフレーム又はＢフレームとして指定するものであればよい。イントラＢＣ部４８は、インター予測についての動き推定部４２による動きベクトルの決定と同様に、イントラＢＣ符号化について、たとえばブロックベクトルなどのベクトルを決定すればよく、あるいは、動き推定部４２を用いて当該ブロックベクトルを決定すればよい。

【0028】

[0034]予測ブロックは、画素差分の観点から、符号化対象となるビデオブロックのＰＵと密接に対応するものとみなされる参照フレームのブロックであり、差分絶対値和（ＳＡＤ：ｓｕｍ ｏｆ ａｂｓｏｌｕｔｅ ｄｉｆｆｅｒｅｎｃｅ），差分二乗和（ＳＳＤ：ｓｕｍ ｏｆ ｓｑｕａｒｅ ｄｉｆｆｅｒｅｎｃｅ）又はその他の差分基準量により決定されるものでよい。いくつかの実施形態では、ビデオ符号化器２０は、ＤＰＢ６４に格納されている参照フレームのサブ整数型画素位置についての値を計算すればよい。たとえば、ビデオ符号化器２０は、参照フレームの１／４画素位置，１／８画素位置又はその他の分数画素位置の値を補間すればよい。したがって、動き推定部４２は、全体の画素位置及び分数画素位置に対する動き検索を実行して、分数画素精度の動きベクトルを出力すればよい。

【0029】

[0035]動き推定部４２は、インター予測符号化フレーム内のビデオブロックのＰＵについて、第１の参照フレームリスト（リスト０）又は第２の参照フレームリスト（リスト１）から選択された参照フレームの予測ブロックの位置と当該ＰＵの位置とを比較することにより動きベクトルを算出する。ここで、第１の参照フレームリスト又は第２の参照フレームリストはそれぞれＤＰＢ６４に格納されている１つ以上の参照フレームを特定するものである。動き推定部４２は、当該算出された動きベクトルを動き補償部４４に転送し、次いでエントロピー符号化部５６に転送する。

【0030】

[0036]動き補償は、動き補償部４４により実行されるものであり、動き推定部４２で決定された動きベクトルに基づいて予測ブロックを取り込む（フェッチ）又は生成することを含みうる。現在のビデオブロックのＰＵについての動きベクトルを受け取ると、動き補償部４４は、複数の参照フレームリストのうちの１つのリストで当該動きベクトルが指し示す予測ブロックを見つけ出し、当該予測ブロックを取得し、そして当該予測ブロックを加算器５０に送る。次いで加算器５０は、符号化される現在のビデオブロックの画素値から、動き補償部４４から供給された予測ブロックの画素値を減算することにより画素差分値からなる残差ビデオブロックを構成する。残差ビデオブロックを構成する画素差分値は、輝度（ｌｕｍａ）差分成分もしくは色差（ｃｈｒｏｍａ）差分成分，又はこれらの両方を含むものでよい。また動き補償部４４は、ビデオ復号器３０でビデオフレームのビデオブロックを復号する際に使用するために、ビデオフレームのビデオブロックに関連付けられたシンタックス要素を生成すればよい。シンタックス要素は、たとえば、予測ブロックを特定するために使用された予測ベクトル，当該予測モードを示す何らかのフラグ，又は本明細書で説明される何らかの他のシンタックス情報を定めたシンタックス要素を含んでいればよい。動き推定部４２及び動き補償部４４は高度に統合されてよいが、概念目的のために分離されて図示されている点に留意すべきである。

【0031】

[0037]いくつかの実施形態では、イントラＢＣ部４８は、動き推定部４２及び動き補償部４４に関して上述した場合と同様の方法でベクトルの生成と予測ブロックの取り込み（フェッチ）とを行ってよいが、ここで、当該予測ブロックは、符号化される現在のブロックと同じフレーム内に存在し、当該ベクトルは、動きベクトルとは逆向きのブロックベクトルとみなされる。特に、イントラＢＣ部４８は、現在のブロックを符号化するように使用するためのイントラ予測モードを決定してよい。いくつかの例では、イントラＢＣ部４８は、たとえば別々の符号化手順で、種々のイントラ予測モードを用いて現在のブロックを符号化すればよく、レート歪み解析によりそれらの性能を評価すればよい。次に、イントラＢＣ部４８は、種々の評価済みのイントラ予測モードの中から、使用するイントラモード予測子を生成するために適切なイントラ予測モードを選択すればよい。たとえば、イントラＢＣ部４８は、当該種々の評価済みのイントラ予測モードに対するレート歪み解析を用いてレート歪み値を算出してよく、当該評価済みのモードの中から、使用する適切なイントラ予測モードとして最高のレート歪み特性を有するイントラ予測モードを選択すればよい。レート歪み解析は、一般に、符号化ブロックと、当該符号化ブロックを生成するために符号化された符号化前の元のブロックとの間の歪み（又は誤差）量とともに、これら符号化ブロックを生成するために使用されたビットレート（すなわち、多数のビット）を決定する。イントラＢＣ部４８は、どのイントラ予測モードが当該ブロックについて最高のレート歪み値を示すのかを決定するために、当該歪みから割合を算出し、当該種々の符号化ブロックについてのレートを算出する。

【0032】

[0038]他の例では、イントラＢＣ部４８は、本明細書で説明される実施形態に従ってイントラＢＣ予測用のそのような機能を実行するために、動き推定部４２及び動き補償部４４の全部又は一部を使用してよい。いずれのケースでも、イントラブロックコピーについて予測ブロックは、画素差分の観点から、符号化対象となるブロックと密接に対応するものとみなされるブロックであればよく、差分絶対値和（ＳＡＤ），差分二乗和（ＳＳＤ）又はその他の差分基準量により決定されるものでよい。そして予測ブロックの特定には、サブ整数型の画素位置に関する値の算出が含まれればよい。

【0033】

[0039]予測ブロックがイントラ予測に従って同一フレームから得られたか、あるいはインター予測に従って異なるフレームから得られたかどうか、ビデオ符号化器２０は、符号化される現在のビデオブロックの画素値から予測ブロックの画素値を減算して画素差分値を構成することにより、残差ビデオブロックを構成すればよい。残差ビデオブロックを構成する画素差分値は、輝度（ｌｕｍａ）成分の差分及び色差（ｃｈｒｏｍａ）成分の差分を含むものでよい。

【0034】

[0040]イントラ予測処理部４６は、上記したような動き推定部４２及び動き補償部４４により実行されるインター予測、又はイントラＢＣ部４８により実行されるイントラブロックコピー予測に代わるものとして、現在のビデオブロックのイントラ予測を行ってもよい。特に、イントラ予測処理部４６は、現在のブロックを符号化するために使用するイントラ予測モードを決定すればよい。このようにするために、イントラ予測処理部４６は、たとえば別々の符号化手順で、種々のイントラ予測モードを用いて現在のブロックを符号化すればよく、イントラ予測処理部４６（又は、いくつかの例ではモード選択部）は、評価済みのイントラ予測モードの中から、使用する適切なイントラ予測モードを選択すればよい。イントラ予測処理部４６は、当該ブロックについて選択されたイントラ予測モードを示す情報をエントロピー符号化部５６に供給すればよい。エントロピー符号化部５６は、当該選択されたイントラ予測モードを示す情報をビットストリーム内に符号化すればよい。

【0035】

[0041]予測処理部４１が現在のビデオブロックについてインター予測又はイントラ予測のいずれかで予測ブロックを決定した後、加算器５０は、当該現在のビデオブロックから当該予測ブロックを減算することで残差ビデオブロックを構成する。その残差ブロック内の残差ビデオデータは、１つ以上の変換ユニット（ＴＵ）内に組み込まれてよく、変換処理部５２に供給される。変換処理部５２は、離散コサイン変換（ＤＣＴ：ｄｉｓｃｒｅｔｅ ｃｏｓｉｎｅ ｔｒａｎｓｆｏｒｍ）又は概念的に同様の変換などの変換を用いて、残差ビデオデータを残差変換係数に変換する。

【0036】

[0042]変換処理部５２は、残差変換係数を量子化部５４に転送する。量子化部５４は、さらにビットレートを低減するために変換係数を量子化する。その量子化処理では、当該係数の一部又は全部に関するビット深さが削減されてもよい。その量子化度は、量子化パラメータを調整することで変更されてよい。いくつかの例では、次に量子化部５４は、量子化変換係数を含むマトリクスに対する走査を実行すればよい。あるいは、エントロピー符号化部５６がその走査を実行してもよい。

【0037】

[0043]量子化に続いて、エントロピー符号化部５６は、たとえば、コンテキスト適応型可変長符号化（ＣＡＶＬＣ：ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｃｏｄｉｎｇ），コンテキスト適応型２値算術符号化（ＣＡＢＡＣ：ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｂｉｎａｒｙ ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ），シンタックスベースコンテクスト適応型２値算術符号化（ＳＢＡＣ：ｓｙｎｔａｘ－ｂａｓｅｄ ｃｏｎｔｅｘｔ－ａｄａｐｔｉｖｅ ｂｉｎａｒｙ ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ），確率区間区分エントロピー符号化（ＰＩＰＥ：ｐｒｏｂａｂｉｌｉｔｙ ｉｎｔｅｒｖａｌ ｐａｒｔｉｔｉｏｎｉｎｇ ｅｎｔｒｏｐｙ ｃｏｄｉｎｇ）、もしくはその他のエントロピー符号化の方法論又は技術を用いて、量子化変換係数にエントロピー符号化を施してビデオビットストリームを得る。その後、符号化ビットストリームは、ビデオ復号器３０に送信されるか、あるいは、後にビデオ復号器３０に送信または取得されるように記録装置３２に記録されればよい。エントロピー符号化部５６は、動きベクトルと、符号化される現在のビデオフレームに関する他のシンタックス要素とにエントロピー符号化を施してもよい。

【0038】

[0044]逆量子化部５８及び逆変換処理部６０は、それぞれ逆量子化及び逆変換を適用して、他のビデオブロックの予測用の参照ブロックを生成するために画素領域で残差ビデオブロックを再構成する。上記のとおり、動き補償部４４は、ＤＰＢ６４に格納されているフレームの１つ以上の参照ブロックから、動き補償された予測ブロックを生成すればよい。動き補償部４４は、動き補償に使用されるサブ整数型の画素値を算出するために、１つ以上の補間フィルタを予測ブロックに適用してもよい。

【0039】

[0045]加算器６２は、再構成された残差ブロックを、動き補償部４４で生成された動き補償された予測ブロックに加算して参照ブロックを生成しこれをＤＰＢ６４に格納する。次に、その参照ブロックは、後続のビデオフレーム内の他のビデオブロックにインター予測を行うための予測ブロックとして、イントラＢＣ部４８，動き推定部４２及び動き補償部４４で使用されればよい。

【0040】

[0046]図３は、本出願のいくつかの実施形態に係るビデオ復号器３０を例示するブロック図である。ビデオ復号器３０は、ビデオデータメモリ７９，エントロピー復号部８０，予測処理部８１，逆量子化部８６，逆変換処理部８８，加算器９０及びＤＰＢ９２を含む。さらに予測処理部８１は、動き補償部８２，イントラ予測処理部８４及びイントラＢＣ部８５を含む。ビデオ復号器３０は、図２関連のビデオ符号化器２０に関して上述した符号化処理に対して一般に逆の復号処理を実行すればよい。たとえば、動き補償部８２は、エントロピー復号部８０から取得された動きベクトルに基づいて予測データを生成すればよく、その一方でイントラ予測処理部８４は、エントロピー復号部８０から取得されたイントラ予測モードインジケータに基づいて予測データを生成すればよい。

【0041】

[0047]いくつかの例では、ビデオ復号器３０内の１つのユニットが、本出願の実施形態を実施するためのタスクの割り当てを受けてよい。いくつかの例では、本開示の実施形態は、ビデオ復号器３０内の１つ以上のユニットに分割されてもよい。たとえば、イントラＢＣ部８５は、単独で、又は、動き補償部８２，イントラ予測処理部８４及びエントロピー復号部８０などの他のユニットと協働して本出願の実施形態を実施してよい。いくつかの例では、ビデオ復号器３０はイントラＢＣ部８５を有しなくてよく、イントラＢＣ部８５の機能性は、予測処理部８１内の動き補償部８２などの他の構成要素によって遂行されてもよい。

【0042】

[0048]ビデオデータメモリ７９は、ビデオ復号器３０の他の構成要素で復号されるべき符号化ビデオビットストリームなどのビデオデータを格納すればよい。ビデオデータメモリ７９に格納されるビデオデータは、たとえば、記録装置３２から，あるいはビデオデータの有線ネットワーク通信又は無線ネットワーク通信によりカメラなどのローカルなビデオ源から，あるいは物理的なデータ記録媒体（たとえば、フラッシュドライブ又はハードディスク）から取得されればよい。ビデオデータメモリ７９は、符号化ビデオビットストリームからの符号化ビデオデータを格納する符号化ピクチャバッファ（ＣＰＢ：ｃｏｄｅｄ ｐｉｃｔｕｒｅ ｂｕｆｆｅｒ）を含んでよい。ビデオ復号器３０内の復号ピクチャバッファ（ＤＰＢ）９２は、（たとえば、イントラ予測符号化モード又はインター予測符号化モードで）ビデオ復号器３０でビデオデータを復号する際に使用される参照ビデオデータを格納する。ビデオデータメモリ７９及びＤＰＢ９２は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）など、同期型ＤＲＡＭ（ＳＤＲＡＭ：ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ），磁気抵抗型ＲＡＭ（ＭＲＡＭ：ｍａｇｎｅｔｏ－ｒｅｓｉｓｔｉｖｅ ＲＡＭ），抵抗変化型ＲＡＭ（ＲＲＡＭ：ｒｅｓｉｓｔｉｖｅ ＲＡＭ）又は他タイプのメモリデバイスといった多種多様な任意のメモリデバイスで構成されればよい。図示するために、ビデオデータメモリ７９及びＤＰＢ９２は、ビデオ復号器３０内で２つの異なる構成要素として示されている。しかしながら、ビデオデータメモリ７９及びＤＰＢ９２が同一のメモリデバイス又は別々のメモリデバイスで与えられてよいことは、当業者であれば明らかであろう。いくつかの例では、ビデオデータメモリ７９は、ビデオ復号器３０内の他の構成要素とともにチップに実装されてもよいし、あるいは、他の構成要素に対してチップ外に実装されてもよい。

【0043】

[0049]復号処理の間、ビデオ復号器３０は、符号化ビデオフレームの複数のビデオブロックとこれに関連したシンタックス要素とを示す符号化ビットストリームを受信する。ビデオ復号器３０は、ビデオフレームのレベル及び／又はビデオブロックのレベルでシンタックス要素を受信すればよい。ビデオ復号器３０内のエントロピー復号部８０は、当該ビットストリームにエントロピー復号を施して、量子化係数，動きベクトル又はイントラ予測モードインジケータ，及び他のシンタックス要素を生成する。次いでエントロピー復号部８０は、動きベクトル及び他のシンタックス要素を予測処理部８１に送る。

【0044】

[0050]イントラ予測符号化（Ｉ）フレームとして、又は他タイプのフレーム内のイントラ符号化予測ブロックについてビデオフレームが符号化されるときは、予測処理部８１内のイントラ予測処理部８４は、現在のフレーム内の過去の復号ブロックから、信号伝達されたイントラ予測モード及び参照データに基づき、現在のビデオフレーム内のビデオブロックについて予測データを生成してよい。

【0045】

[0051]インター予測符号化（たとえばＢ又はＰ）フレームとしてビデオフレームが符号化されるときは、予測処理部８１内の動き補償部８２は、エントロピー復号部８０から取得された動きベクトル及び他のシンタックス要素に基づき、現在のビデオフレーム内のビデオブロックについて１つ以上の予測ブロックを生成する。予測ブロックの各々は、複数の参照フレームリストのうちの１つのリスト内の参照フレームから生成されればよい。ビデオ復号器３０は、ＤＰＢ９２に格納されている参照フレームに基づき、初期設定の構成技術を用いて、リスト０及びリスト１という参照フレームリストを構成すればよい。

【0046】

[0052]いくつかの例では、本明細書に説明されるイントラＢＣモードに従ってビデオブロックが符号化されるときは、予測処理部８１内のイントラＢＣ部８５は、エントロピー復号部８０から取得されたブロックベクトル及び他のシンタックス要素に基づき、現在のビデオブロックについて予測ブロックを生成する。予測ブロックは、ビデオ符号化器２０で定められた現在のビデオブロックと同じピクチャ内の再構成領域内に存在すればよい。

【0047】

[0053]動き補償部８２及び／又はイントラＢＣ部８５は、当該動きベクトル及び他のシンタックス要素を解析することにより現在のビデオフレーム内のビデオブロックについての予測情報を決定し、次いで、その予測情報を用いて、復号される現在のビデオブロックに対する予測ブロックを生成する。たとえば、動き補償部８２は、現在のビデオフレームにおけるビデオブロックを復号するために、当該取得されたシンタックス要素のいくつかを使用して、当該ビデオフレーム内のビデオブロックの符号化に使用された予測モード（たとえば、イントラ予測又はインター予測）、インター予測フレームの種類（たとえば、Ｂ又はＰ）、当該フレームに対する１つ以上の参照フレームリストについての構成情報、当該フレーム内のインター予測符号化ビデオブロックの各々についての動きベクトル、当該フレーム内のインター予測符号化ビデオブロックの各々についてのインター予測状態、及びその他の情報を決定する。

【0048】

[0054]同様に、イントラＢＣ部８５は、現在のビデオフレームにおけるビデオブロックを復号するために、当該取得されたシンタックス要素のいくつか（たとえば、フラグ）を使用して、現在のビデオブロックがイントラＢＣモードを用いて予測されたこと，当該フレーム内のどのビデオブロックが再構成領域内に存在しかつＤＰＢ９２に格納されるべきであるかを示す構成情報、当該フレーム内のイントラＢＣ予測ビデオブロックの各々についてのブロックベクトル，当該フレーム内のイントラＢＣ予測ビデオブロックの各々についてのイントラＢＣ予測状態，及びその他の情報を決定すればよい。

【0049】

[0055]動き補償部８２は、参照ブロックのサブ整数型画素に関する補間値を算出するために、ビデオブロックの符号化の際にビデオ符号化器２０で使用されたような補間フィルタを用いて補間を実行してもよい。この場合、動き補償部８２は、当該取得されたシンタックス要素から、ビデオ符号化器２０で使用された補間フィルタを決定すればよく、予測ブロックを生成するために当該補間フィルタを使用すればよい。

【0050】

[0056]逆量子化部８６は、ビットストリームで与えられてエントロピー復号部８０によりエントロピー復号された量子化変換係数に対して、量子化度を決めるためにビデオフレーム内の各ビデオブロックについてビデオ符号化器２０で算出された量子化パラメータと同じものを用いた逆量子化を実行する。逆変換処理部８８は、画素領域の残差ブロックを再構成するために、変換係数に対して、たとえば、逆ＤＣＴ，逆整数変換又は概念的に同様の逆変換処理といった逆変換を適用する。

【0051】

[0057]動き補償部８２又はイントラＢＣ部８５が、当該ベクトル及び他のシンタックス要素に基づき、現在のビデオブロックについて予測ブロックを生成した後、加算器９０は、逆変換処理部８８からの残差ブロックと、動き補償部８２及びイントラＢＣ部８５により生成された対応する予測ブロックとを加算することにより、現在のビデオブロックについて復号ビデオブロックを再構成する。復号ビデオブロックをさらに処理するために加算器９０とＤＰＢ９２との間にループ内フィルタ（図示せず）が配置されてもよい。次に、特定のフレーム内の復号ビデオブロックがＤＰＢ９２内に格納される。ＤＰＢ９２は、次のビデオブロックのその後の動き補償のために使用される参照フレームを格納するものである。図１の表示装置３４のような表示装置での表示をその後行うために、ＤＰＢ９２又はＤＰＢ９２とは別のメモリデバイスが復号ビデオを格納してもよい。

【0052】

[0058]一般的なビデオ復号処理では、ビデオシーケンスは、一般に、配列された複数フレーム又は複数ピクチャの組を含む。各フレームは、ＳＬ，ＳＣｂ及びＳｃｒで示される３つのサンプル配列を含んでよい。ＳＬは、複数の輝度（ｌｕｍａ）サンプルからなる２次元配列である。ＳＣｂは、複数のＣｂ色差（ｃｈｒｏｍａ）サンプルからなる２次元配列である。ＳＣｒは、複数のＣｒ色差（ｃｈｒｏｍａ）サンプルからなる２次元配列である。他の例では、フレームは単色でもよく、これにより複数の輝度（ｌｕｍａ）サンプルからなる単一の２次元配列のみを有する。

【0053】

[0059]図４Ａに示されるように、ビデオ符号化器２０（又は、より具体的には分割部４５）は、フレームを複数の符号化ツリーユニット（ＣＴＵ）の集合に最初に分割することによりフレームの符号化表現を生成する。ビデオフレームは、上端から下端へかつ左側から右側へ向かうラスタ走査順で連続的に順序付けされた整数個のＣＴＵを含んでいればよい。各ＣＴＥＴは、最大の論理符号化ユニットであり、ＣＴＵの幅及び高さは、シーケンスパラメータセットでビデオ符号化器２０により信号伝達されて、ビデオシーケンス内の全てのＣＴＵが１２８×１２８，６４×６４，３２×３２及び１６×１６のうちの１つと同じサイズを有するようにされる。ただし、本出願は必ずしも特定のサイズに限定されるものではない点に注意すべきである。図４Ｂに示されるように、各ＣＴＵは、複数の輝度サンプルからなる１つの符号化ツリーブロック（ＣＴＢ）及びこれに対応した複数の色差サンプルからなる２つの符号化ツリーブロックと、それら符号化ツリーブロックのサンプルを符号化するために使用されるシンタックス要素とを有してよい。シンタックス要素は、符号化画素ブロックの異なるタイプのユニットの特性と、ビデオシーケンスをビデオ復号器３０で再構成できる方法とを記述するものであり、インター予測もしくはイントラ予測，イントラ予測モード，動きベクトル及びその他のパラメータを含む。モノクロのピクチャ又は３つの異なる色プレーンをもつピクチャでは、ＣＴＵは、単一の符号化ツリーブロックと当該符号化ツリーブロックのサンプルを符号化するために使用されるシンタックス要素とを有していればよい。符号化ツリーブロックは、複数サンプルからなるＮ×Ｎのブロックであればよい。

【0054】

[0060]より良好な性能を達成するために、ビデオ符号化器２０は、ＣＴＵの符号化ツリーブロックに対して、二分木（ｂｉｎａｒｙ－ｔｒｅｅ）分割，四分木（ｑｕａｄ－ｔｒｅｅ）分割，又はこれらの両方の組合せといった木分割を再帰的に実行して、当該ＣＴＵをより小さな複数の符号化ユニット（ＣＵ）に分割すればよい。図４Ｃに示されるように、６４×６４のＣＴＵ４００は、最初に、より小さな４つのＣＵに分割され、各ＣＵは、３２×３２のブロックサイズを有している。これらの小さな４つのＣＵのうち、ＣＵ４１０及びＣＵ４２０の各々は、１６×１６のブロックサイズの４つのＣＵに分割される。２つの１６×１６のＣＵ４３０，４４０は、各々、さらに８×８のブロックサイズの４つのＣＵに分割される。図４Ｄは、図４Ｃに示したＣＴＵ４００に分割処理を施して得られた最終結果を表す四分木データ構造の図であり、四分木の各リーフノード（葉ノード）は、３２×３２から８×８までの範囲内の各サイズを有する１つのＣＵに相当する。図４Ｂに示したＣＴＵのように、各ＣＵは、同一サイズのフレームにおける複数の輝度サンプルからなる符号化ブロック（ＣＢ）及びこれに対応した複数の色差サンプルからなる２つの符号化ブロックと、これら符号化ブロックのサンプルを符号化するために使用されるシンタックス要素とを有する。モノクロのピクチャ又は３つの異なる色プレーンをもつピクチャでは、ＣＵは、単一の符号化ブロックと、当該符号化ブロックのサンプルを符号化するために使用されるシンタックス構造とを有してよい。

【0055】

[0061]いくつかの実施形態では、ビデオ符号化器２０は、さらに、ＣＵの符号化ブロックを１つ以上のＮ×Ｎの予測ブロック（ＰＢ）に分割してよい。予測ブロックは、同一の予測すなわちインター又はイントラが適用される複数サンプルからなる矩形状（正方形又は非正方形）のブロックである。ＣＵの予測ユニット（ＰＵ）は、複数の輝度サンプルからなる予測ブロックと、これに対応した複数の色差サンプルからなる２つの予測ブロックと、それら予測ブロックを予測するために使用されるシンタックス要素とを有してよい。モノクロのピクチャ又は３つの異なる色プレーンをもつピクチャでは、ＰＵは、単一の予測ブロックと、当該予測ブロックを予測するために使用されるシンタックス構造とを有してよい。ビデオ符号化器２０は、ＣＵの各ＰＵにおける輝度予測ブロック，Ｃｂ予測ブロック及びＣｒ予測ブロックについて、予測輝度ブロック，予測Ｃｂブロック及び予測Ｃｒブロックを生成すればよい。

【0056】

[0062]ビデオ符号化器２０は、イントラ予測又はインター予測を使用してＰＵについてそれら予測ブロックを生成すればよい。ビデオ符号化器２０がイントラ予測を使用してＰＵの予測ブロックを生成するときは、ビデオ符号化器２０は、当該ＰＵに関するフレームの復号サンプルに基づいて、当該ＰＵの予測ブロックを生成すればよい。ビデオ符号化器２０がインター予測を使用してＰＵの予測ブロックを生成するときは、ビデオ符号化器２０は、当該ＰＵに関するフレーム以外の１つ以上のフレームの復号サンプルに基づいて、当該ＰＵの予測ブロックを生成すればよい。

【0057】

[0063]ビデオ符号化器２０がＣＵの１つ以上のＰＵについて予測輝度ブロック，予測Ｃｂブロック及び予測Ｃｒブロックを生成した後は、ビデオ符号化器２０は、ＣＵの予測輝度ブロックをその元の輝度符号化ブロックから減算することにより、ＣＵについて輝度残差ブロックを生成すればよく、当該ＣＵの輝度残差ブロックの各サンプルが、当該ＣＵの複数の予測輝度ブロックのうちの１つのブロックの輝度サンプルと、当該ＣＵの元の輝度符号化ブロックの対応するサンプルとの間の差分を示すものとする。同様に、ビデオ符号化器２０は、それぞれ、Ｃｂ残差ブロック及びＣｒ残差ブロックを生成すればよく、当該ＣＵのＣｂ残差ブロックの各サンプルが、当該ＣＵの複数の予測Ｃｂブロックのうちの１つのブロックのＣｂサンプルと、当該ＣＵの元のＣｂ符号化ブロックの対応するサンプルとの間の差分を示すものとし、当該ＣＵのＣｒ残差ブロックの各サンプルが、当該ＣＵの複数の予測Ｃｒブロックのうちの１つのブロックのＣｒサンプルと、当該ＣＵの元のＣｒ符号化ブロックの対応するサンプルとの間の差分を示してよいものとする。

【0058】

[0064]さらに、図４Ｃに示されるように、ビデオ符号化器２０は、ＣＵにおける輝度残差ブロック，Ｃｂ残差ブロック及びＣｒ残差ブロックを、１つ以上の輝度変換ブロック，Ｃｂ変換ブロック及びＣｒ変換ブロックに分解するために四分木分割を使用すればよい。変換ブロックは、同一の変換が適用される複数サンプルからなる矩形状（正方形又は非正方形）のブロックである。ＣＵの変換ユニット（ＴＵ）は、複数の輝度サンプルからなる変換ブロックと、これに対応した複数の輝度サンプルからなる２つの変換ブロックと、それら変換ブロックのサンプルを変換するために使用されるシンタックス要素とを有してよい。よって、ＣＵの各ＴＵは、輝度変換ブロック，Ｃｂ変換ブロック及びＣｒ変換ブロックと関連付けられうる。いくつかの例では、ＴＵに関連付けられた輝度変換ブロックは、ＣＵの輝度残差ブロックのサブブロックであればよい。Ｃｂ変換ブロックは、ＣＵのＣｂ残差ブロックのサブブロックであればよい。Ｃｒ変換ブロックは、ＣＵのＣｒ残差ブロックのサブブロックであればよい。モノクロのピクチャ又は３つの異なる色プレーンをもつピクチャでは、ＴＵは、単一の変換ブロックと、当該変換ブロックのサンプルを変換するために使用されるシンタックス構造とを有してよい。

【0059】

[0065]ビデオ符号化器２０は、ＴＵの輝度変換ブロックに１つ以上の変換を適用して当該ＴＵについて輝度係数ブロックを生成すればよい。係数ブロックは、複数の変換係数の２次元配列であればよい。変換係数は、スカラー量であればよい。ビデオ符号化器２０は、ＴＵのＣｂ変換ブロックに１つ以上の変換を適用して当該ＴＵについてＣｂ係数ブロックを生成すればよい。ビデオ符号化器２０は、ＴＵのＣｒ変換ブロックに１つ以上の変換を適用して当該ＴＵについてＣｒ係数ブロックを生成すればよい。

【0060】

[0066]係数ブロック（たとえば、輝度係数ブロック，Ｃｂ係数ブロック又はＣｒ係数ブロック）を生成した後、ビデオ符号化器２０は、当該係数ブロックを量子化すればよい。通常、量子化は、変換係数を示すために使用されたデータの総量を削減しうるように変換係数を量子化する処理をいい、さらなる圧縮を与えるものである。ビデオ符号化器２０が係数ブロックを量子化した後、ビデオ符号化器２０は、その量子化変換係数を示すシンタックス要素をエントロピー符号化すればよい。たとえば、ビデオ符号化器２０は、量子化変換係数を示すシンタックス要素に対してコンテキスト適応型２値算術符号化（ＣＡＢＡＣ：Ｃｏｎｔｅｘｔ－Ａｄａｐｔｉｖｅ Ｂｉｎａｒｙ Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ）を実行すればよい。最終的に、ビデオ符号化器２０は、符号化フレーム及び関連データの表現を構成するビットシーケンスを示すビットストリームを出力すればよく、それは記録装置３２に保存されるか、あるいは、送信先装置１４に送信される。

【0061】

[0067]ビデオ符号化器２０により生成されたビットストリームを受信した後、ビデオ復号器３０は、当該ビットストリームを解析して当該ビットストリームからシンタックス要素を取得すればよい。ビデオ復号器３０は、ビットストリームから取得されたシンタックス要素の少なくとも一部に基づいてビデオデータのフレームを再構成すればよい。ビデオデータを再構成する処理は、通常、ビデオ符号化器２０により実行された符号化処理とは逆の処理である。たとえば、ビデオ復号器３０は、現在のＣＵのＴＵに関連する係数ブロックに逆変換を施して、当該現在のＣＵのＴＵに関連する残差ブロックを再構成すればよい。ビデオ復号器３０は、当該現在のＣＵにおけるＰＵについての予測ブロックのサンプルを、当該現在のＣＵにおけるＴＵの変換ブロックの対応サンプルに加算することにより、当該現在のＣＵの符号化ブロックを再構成してもよい。フレームの各ＣＵについて符号化ブロックを再構成した後、ビデオ復号器３０は、当該フレームを再構成すればよい。

【0062】

[0068]上記のとおり、ビデオ符号化は、主要な２つのモード、すなわち、イントラフレーム予測（又はイントラ予測）とインターフレーム予測（又はインター予測）とを用いてビデオ圧縮を実現するものである。ＩＢＣは、イントラフレーム予測又は第３のモードのいずれかとみなされうることに注意すべきである。当該２つのモードのうち、インターフレーム予測は、参照ビデオブロックから現在のビデオブロックを予測するために動きベクトルを使用することから、イントラフレーム予測よりも符号化効率に寄与する。

【0063】

[0069]ただし、ビデオデータのキャプチャ技術が絶え間なく向上していること、及びビデオデータの詳細情報を保持するためにビデオブロックサイズがより細かくなっていることに伴い、現在のフレームについて動きベクトルを表すために必要とされるデータ量も実質的に増大している。この課題を克服するための１つの方法は、空間領域及び時間領域の双方で近隣のＣＵからなる集合が予測のために類似のビデオデータを有していることだけでなく、これら近隣のＣＵ間の動きベクトルも類似しているという事実から利益を得ることである。したがって、空間的及び時間的な相関を探し出すことにより、空間的に近隣のＣＵ及び／又は時間的に連結するＣＵの動き情報を、現在のＣＵのおおよその動き情報（たとえば動きベクトル）として使用することが可能である。これは、現在のＣＵの「動きベクトル予測子（ＭＶＰ：ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｏｒ）」とも呼ばれる。

【0064】

[0070]図２に関して上記したように動き推定部４２により決定された現在のＣＵの実際の動きベクトルをビデオビットストリーム内に符号化する代わりに、現在のＣＵについて動きベクトル差分（ＭＶＤ：ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ）を生成するために、現在のＣＵの動きベクトル予測子は当該現在のＣＵの実際の動きベクトルから減算される。そのようにすることにより、フレームの各ＣＵについて動き推定部４２により決定された動きベクトルをビデオビットストリーム内に符号化する必要がなく、ビデオビットストリーム内の動き情報を表現するために使用されるデータ量を大幅に削減することができる。

【0065】

[0071]符号ブロックのインターフレーム予測の際に参照フレーム内の予測ブロックを選択する処理のように、現在のＣＵに対して空間的に近隣のＣＵ及び／又は時間的に連結するＣＵに関連して生成されうる候補動きベクトルを用いて現在のＣＵ用の動きベクトル候補リストを構成し、次いで当該現在のＣＵについて動きベクトル予測子としてその動きベクトル候補リストの中から一要素を選択するために、一組のルールがビデオ符号化器２０及びビデオ復号器３０の双方で適用される必要がある。そのようにすることにより、ビデオ符号化器２０とビデオ復号器３０との間で動きベクトル候補リスト自体を送信する必要がなく、動きベクトル候補リスト内の当該選択された動きベクトル予測子のインデックスは、現在のＣＵを符号化及び復号するためにビデオ符号化器２０及びビデオ復号器３０が動きベクトル候補リスト内の同じ動きベクトル予測子を使用するために十分なものである。

【0066】

[0072]いくつかの実施形態では、各インター予測ＣＵは、動きベクトル候補リスト構成するために、インター（以下「高度動きベクトル予測（ＡＭＶＰ：ａｄｖａｎｃｅｄ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｎ）」とも称する。），スキップ及びマージを含む３つの動きベクトル予測モードを有する。各モードの下では、以下に説明するアルゴリズムに従って１つ以上の動きベクトル候補が動きベクトル候補リストに追加されうる。その候補リストの中から最終的に１つの候補が、ビデオ符号化器２０によりビデオビットストリーム内に符号化されるべき又はビデオ復号器３０によりビデオビットストリームから復号されるべきインター予測ＣＵの最良の動きベクトル予測子として使用される。その候補リストの中から最良の動きベクトル予測子を見つけ出すために、与えられた複数の動きベクトルからなる候補セット、すなわち、空間的及び時間的な動きベクトル候補を含む動きベクトル候補リストの中から動きベクトルを選択するという動きベクトル競合（ＭＶＣ：ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｃｏｍｐｅｔｉｔｉｏｎ）方式が導入される。

【0067】

[0073]空間的に近隣の又は時間的に連結するＣＵの中から動きベクトル予測子の候補を抽出することに加えて、当該動きベクトル予測子の候補を、いわゆる「履歴ベースの動きベクトル予測（ＨＭＶＰ：ｈｉｓｔｏｒｙ－ｂａｓｅｄ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｐｒｅｄｉｃｔｉｏｎ）」テーブルから抽出することもできる。ＨＭＶＰテーブルは、所定数の動きベクトル予測子を格納し、各動きベクトル予測子は、同一のＣＴＵ行（又は、ときには同一のＣＴＵ）のうちの特定のＣＵを符号化／復号するために使用される。これらＣＵの空間的／時間的な近接度のために、ＨＭＶＰテーブル中の１つの動きベクトル予測子が、同一のＣＴＵ行内の互いに異なるＣＵを符号化／復号するために再利用されるであろうという高い確からしさが存在する。したがって、動きベクトル候補リストを構成する処理にＨＭＶＰテーブルを組み込むことにより、より高い符号効率を実現することができる。

【0068】

[0074]いくつかの実施形態では、ＨＭＶＰテーブルは、固定長（たとえば、５）を有し、準先入れ先出し（quasi-ＦＩＦＯ：ｑｕａｓｉ－Ｆｉｒｓｔ－Ｉｎ－Ｆｉｒｓｔ－Ｏｕｔ）方式で管理される。たとえば、動きベクトルは、ＣＵについて、当該ＣＵの１つのインター符号化ブロックを復号する際に再構成される。ＨＭＶＰテーブルは、再構成された動きベクトルでオンザフライで更新される。なぜならば、そのような動きベクトルは、次のＣＵの動きベクトル予測子となり得るからである。ＨＭＶＰテーブルを更新するとき、下記（ｉ），（ｉｉ）の２つのシナリオがある。（ｉ）再構成された動きベクトルがＨＭＶＰテーブル内の他の既存の動きベクトルと異なること、又は、（ｉｉ）再構成された動きベクトルがＨＭＶＰテーブル内の既存の動きベクトルの１つと同じであることである。前記第１のシナリオに対しては、ＨＭＶＰテーブルが限度一杯でなければ、再構成された動きベクトルは最新の動きベクトルとしてＨＭＶＰテーブルに追加される。ＨＭＶＰテーブルが既に限度一杯であれば、再構成された動きベクトルが最新の動きベクトルとして追加される前に、ＨＭＶＰテーブル内の最も古い動きベクトルがＨＭＶＰテーブルから削除される。言い換えれば、この場合のＨＭＶＰテーブルは、ＦＩＦＯバッファと類似しており、このＦＩＦＯバッファの先頭に位置しかつ他の過去のインター符号化ブロックに関連する動きベクトル情報が、そのバッファの外にシフトさせられるので、再構成された動きベクトルがＨＭＶＰテーブル内の最新の要素としてＦＩＦＯバッファの後部に追加されるというようなものである。上記第２のシナリオに対しては、再構成された動きベクトルが最新の動きベクトルとして追加される前に、再構成された動きベクトルと実質的に同一であるＨＭＶＰテーブル内の既存の動きベクトルがＨＭＶＰテーブルから削除される。またＨＭＶＰテーブルがＦＩＦＯバッファの形で整備されているのであれば、ＨＭＶＰテーブル内の当該同一の動きベクトルの後の動きベクトル予測子は、削除された動きベクトルの後に残ったスペースを占めるように１要素だけ前方にシフトさせられ、次いで、再構成された動きベクトルが、ＨＭＶＰテーブル内の最新の要素としてＦＩＦＯバッファの後部に追加される。

【0069】

[0075]ＨＭＶＰテーブル内の動きベクトルは、ＡＭＶＰ，マージ，スキップなどの複数の異なる予測モードの下で動きベクトル候補リストに追加されうる。ＨＭＶＰテーブルに格納されており、現在のブロックと隣接すらしない過去のインター符号化ブロックの動き情報が、より効率的な動きベクトル予測について使用可能であることが見出された。

【0070】

[0076]複数の動きベクトルからなる所与の候補セットのうち１つのＭＶＰ候補が現在のＣＵについて選択された後は、ビデオ符号化器２０は、１つ以上のシンタックス要素をこれに対応するＭＶＰ候補について生成し、これらをビデオビットストリーム内に符号化して、ビデオ復号器３０が当該シンタックス要素を用いてビデオビットストリームから当該ＭＶＰ候補を取得できるようにすればよい。動きベクトル候補セットを構成するために使用された特定のモードに応じて、複数の異なるモード（たとえば，ＡＭＶＰ，マージ，スキップなど）は、シンタックス要素からなる複数の異なるセットを有している。ＡＭＶＰモードについては、シンタックス要素には、インター予測インジケータ（リスト０，リスト１，又は双方向予測）と、参照インデックス，動きベクトル候補インデックス，動きベクトル予測残差信号などが含まれている。スキップモード及びマージモードについては、マージインデックスのみがビットストリーム内に符号化されている。なぜならば、現在のＣＵは、インター予測インジケータ，参照インデックス及び動きベクトルを含む他のシンタックス要素を、符号化マージインデックスにより参照された近隣のＣＵから引き継いでいるからである。スキップ符号化ＣＵの場合は、動きベクトル予測残差信号も無視される。

【0071】

[0077]図５Ａは、本開示のいくつかの実施形態に従って、符号化／復号対象である現在のＣＵに対して空間的に近隣でかつ時間的に連結するブロック位置を示すブロック図である。所与のモードに対して、先ずは、空間的に左方及び上方に近隣のブロック位置に関連付けられた動きベクトルの利用可能性と、時間的に連結するブロック位置に関連付けられた動きベクトルの利用可能性とをチェックし、次いでＦＤＭＶＰテーブル内の動きベクトルをチェックすることにより、動きベクトル予測（ＭＶＰ）候補リストが構成される。そのＭＶＰ候補リストを構成する処理の際、いくつかの重複するＭＶＰ候補が候補リストから除去され、必要に応じて、固定長をもつために候補リストを作成するようにゼロ値の動きベクトルが追加される（複数の異なるモードが異なる固定長を有してよい点に注意する。）。ＭＶＰ候補リストの構成後、ビデオ符号化器２０は、その候補リストの中から最良の動きベクトル予測子を選択して、当該選択された候補を示す対応インデックスをビデオビットストリーム内に符号化することができる。

【0072】

[0078]図５Ａを例として用い、その候補リストが固定長２を有すると仮定すると、動きベクトル予測子（ＭＶＰ）候補リストは、現在のＣＵについて、ＡＭＶＰモードの下で以下のステップを順次実行することにより構成されればよい。
１）空間的に近隣の複数のＣＵからのＭＶＰ候補の選択
ａ）Ａ０を起点としＡ１で終わる、左方で空間的に近隣の２つのＣＵのうちの１つから、１つの非スケール化ＭＶＰ候補を抽出するステップ、
ｂ）前回のステップにて左方からは利用可能な非スケール化ＭＶＰ候補が存在しないときは、Ａ０を起点としＡ１で終わる、左方で空間的に近隣の２つのＣＵのうちの１つから、１つのスケール化ＭＶＰ候補を抽出するステップ、
ｃ）Ｂ０を起点としＢ１を経てＢ２で終わる、上方で空間的に近隣の３つのＣＵのうちの１つから、１つの非スケール化ＭＶＰ候補を抽出するステップ、
ｄ）Ａ０，Ａ１のいずれも利用可能ではないとき、あるいは、これらがイントラモードで符号化されているときは、Ｂ０を起点としＢ１を経てＢ２で終わる、上方で空間的に近隣の３つのＣＵのうちの１つから、１つのスケール化ＭＶＰ候補を抽出するステップ、
２）以前のステップにて２つのＭＶＰ候補が見つけ出され、これらが同一であるときは、ＭＶＰ候補リストの中から当該２つの候補のうちの１つを削除するステップ、
３）時間的に連結する複数のＣＵからのＭＶＰ候補の選択
ａ）以前のステップの後のＭＶＰ候補リストが２つのＭＶＰ候補を含まないときは、当該時間的に連結するＣＵの中から１つのＭＶＰ候補を抽出するステップ
４）ＨＭＶＰテーブルからのＭＶＰ候補の選択
ａ）以前のステップの後のＭＶＰ候補リストが２つのＭＶＰ候補を含まないときは、ＨＭＶＰテーブルから２つの履歴ベースのＭＶＰを抽出するステップ、
５）以前のステップの後のＭＶＰ候補リストが２つのＭＶＰ候補を含まないときは、２つのゼロ値ＭＶＰをＭＶＰ候補リストに追加するステップ。

【0073】

[0079]上記のとおりに構成されたＡＭＶＰモードＭＶＰ候補リストの中には２つの候補しか存在しないので、その候補リスト内の２つのＭＶＰ候補のうちどちらが現在のＣＵの復号に使用されるのかを示すために、２値フラグのような関連シンタックス要素がビットストリーム内に符号化される。

【0074】

[0080]いくつかの実施形態では、スキップモード又はマージモードにて、ＭＶＰ候補リストは、現在のＣＵについて、上記のような類似のステップ群を順次実行することにより構成されればよい。スキップモード又はマージモードについては、「ペアワイズ・マージ候補（ｐａｉｒ－ｗｉｓｅ ｍｅｒｇｅ ｃａｎｄｉｄａｔｅ）」と呼ばれる特別な種類のマージ候補もＭＶＰ候補リストに組み込まれる点に注意すべきである。ペアワイズ・マージ候補は、過去に抽出された２つのマージモード動きベクトル候補における複数のＭＶを平均化することで生成される。そのマージＭＶＰ候補リストのサイズ（たとえば、１～６）は、現在のＣＵのスライスヘッダにて信号伝達される。マージモードでは、各ＣＵについて、トランケーテッド・ユーナリー・バイナリゼーション（ＴＵ：ｔｒｕｎｃａｔｅｄ ｕｎａｒｙ ｂｉｎａｒｉｚａｔｉｏｎ）を用いて最良のマージ候補のインデックスが符号化される。マージインデックスの最初のビンはコンテキストで符号化され、他のビンについてはバイパス符号化が使用される。

【0075】

[0081]上記のとおり、履歴ベースのＭＶＰは、空間的なＭＶＰ又は時間的なＭＶＰの後に、ＡＭＶＰモードＭＶＰ候補リスト又はマージＭＶＰ候補リストのいずれかに追加されうる。過去のインター符号化ＣＵの動き情報はＨＭＶＰテーブルに格納され、現在のＣＵについてＭＶＰ候補として使用される。ＨＭＶＰテーブルは、符号化／復号処理の間に整備される。非サブブロック・インター符号化ＣＵがあるときはいつでも、（ＨＭＶＰテーブルが既に限度一杯であり、その関連する動きベクトル情報の同じものの重複が存在しないときは）その関連する動きベクトル情報が新しい候補としてＨＭＶＰテーブルの最後の項目に追加される一方で、ＨＭＶＰテーブルの最初の項目に格納されている動きベクトル情報は、そこから削除される。あるいは、その関連する動きベクトル情報がＨＭＶＰテーブルの最後の項目に追加される前に、その関連する動きベクトル情報の同じものの重複がそのテーブルから取り除かれる。

【0076】

[0082]上記のとおり、イントラブロックコピー（ＩＢＣ）は、表示コンテンツ素材の符号化効率を大幅に向上させることができる。ＩＢＣモードは、ブロックレベルの符号化モードとして実現されるので、各ＣＵについて最適なブロックベクトルを見つけ出すためにブロックマッチング（ＢＭ）がビデオ符号化器２０で実行される。ここで、ブロックベクトルは、現在のブロックから参照ブロックへの位置ずれを示すために使用され、現在のピクチャ内で既に再構成されているものである。ＩＢＣ符号化ＣＵは、イントラ予測モードやインター予測モード以外の第３の予測モードとして扱われる。

【0077】

[0083]ＣＵレベルでは、ＩＢＣモードは、以下のＩＢＣ・ＡＭＶＰモード又はＩＢＣ・スキップ／マージモードとして信号伝達されうる。
－ ＩＢＣ・ＡＭＶＰモード：上記のＡＭＶＰモードで動きベクトル差分を符号化する場合と同じ方法で、ＣＵの実際のブロックベクトルと、当該ＣＵのブロックベクトル候補から選択された当該ＣＵのブロックベクトル予測子との間のブロックベクトル差分（ＢＶＤ：ｂｌｏｃｋ ｖｅｃｔｏｒ ｄｉｆｆｅｒｅｎｃｅ）が符号化される。ブロックベクトル予測法は、２つのブロックベクトル候補を予測子として使用し、その一方を左方近隣から、その他方を上方近隣から得る。いずれの近隣も利用できないときは、初期設定のブロックベクトルがブロックベクトル予測子として使用されることとなる。２値フラグは、ブロックベクトル予測子のインデックスを示すために信号伝達される。ＩＢＣ・ＡＭＶＰ候補リストは、空間的なＨＭＶＰ候補で構成されている。
－ ＩＢＣ・スキップ／マージモード：近隣のＩＢＣ符号化ブロックからのマージ候補リスト内のブロックベクトル候補のうちのどれが、現在のブロックについてブロックベクトルの予測のために使われるのかを示すためにマージ候補インデックスが使用される。ＩＢＣマージ候補リストは、空間的、ＨＭＶＰかつペアワイズな候補で構成される。

【0078】

[0084]従来の符号化規格に適応する符号化効率を向上させる別のアプローチは、たとえばマルチコアプロセッサを用いて、ビデオ符号化／復号処理に並列処理を導入することである。たとえば、波面並列処理（ＷＰＰ：ｗａｖｅｆｒｏｎｔ ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｉｎｇ）は、マルチスレッドを使用して複数のＣＴＵ行の符号化又は復号を並列に行う機能としてＨＥＶＣに既に導入されてきた。

【0079】

[0085]図５Ｂは、本開示のいくつかの実施形態に従って、波面並列処理（ＷＰＰ）を用いてピクチャ内の複数のＣＴＵ行をマルチスレッド符号化することを示すブロック図である。ＷＰＰが有効であるとき、波面法で複数のＣＴＵ行を並列に処理することが可能である。ここで、２つの近隣の波面の先頭間に２つのＣＴＵ行の遅延がありうる。たとえば、ＷＰＰを使用してピクチャ５００を符号化するために、ビデオ符号化器２０及びビデオ復号器３０などのビデオコーダは、ピクチャ５００の符号化ツリーユニット（ＣＴＵ）を複数の波面に分割し、各波面は当該ピクチャ内の各ＣＴＵ行に相当する。ビデオコーダは、たとえば第１のコーダコア又はスレッドを用いて、先頭の波面のコーディングを開始すればよい。ビデオコーダが先頭の波面の２つ以上のＣＴＵをコーディングした後は、ビデオコーダは、たとえば２番目の並列なコーダコア又はスレッドを用いて、先頭の波面のコーディングと並行して、先頭から２番目の波面のコーディングを開始すればよい。ビデオコーダが先頭から２番目の波面の２つ以上のＣＴＵをコーディングした後は、ビデオコーダは、たとえば３番目の並列なコーダコア又はスレッドを用いて、より高次の波面のコーディングと並行して、先頭から３番目の波面のコーディングを開始すればよい。このパターンは、ピクチャ５００内の複数の波面について続行されればよい。本開示では、ビデオコーダが同時並行にコーディングを行うＣＴＵの集合を「ＣＴＵ群」と称する。よって、ビデオコーダがＷＰＰを使用してピクチャのコーディングを行うとき、ＣＴＵ群の各ＣＴＵは、ピクチャ内の唯１つの波面に属してよく、当該ＣＴＵは、それぞれ１つ上の波面内のＣＴＵから、ピクチャ内の少なくとも２つのＣＴＵ列だけオフセットされていればよい。

【0080】

[0086]ビデオコーダは、現在の波面についてコンテクストを初期化して、上の波面の先頭２つのブロックのデータと、当該現在の波面の先頭符号ブロックを含むスライスについてのスライスヘッダ内の１つ以上の要素とに基づいて、当該現在の波面のコンテキスト適応型２値算術符号化（ＣＡＢＡＣ：ｃｏｎｔｅｘｔ ａｄａｐｔｉｖｅ ｂｉｎａｒｙ ａｒｉｔｈｍｅｔｉｃ ｃｏｄｉｎｇ）を実行すればよい。ビデオコーダは、次のＣＴＵ行の上のＣＴＵ行における２つのＣＴＵをコーディングした後のコンテキスト状態を用いて、次の波面（又はＣＴＵ行）のＣＡＢＡＣ初期化を実行すればよい。言い換えれば、現在の波面のコーディングを開始する前に、ビデオコーダ（又は、より具体的には、そのビデオコーダのスレッド）は、当該現在の波面がピクチャ内の先頭のＣＴＵ行ではないと仮定して、当該現在の波面の上の波面における少なくとも２つのブロックのコーディングを実行すればよい。次いでビデオコーダは、現在の波面の上の波面における少なくとも２つのブロックのコーディング後に、現在の波面についてＣＡＢＡＣコンテキストを初期化すればよい。この例では、ピクチャ５００の各ＣＴＵ行は、分離区画であり、ピクチャ内の複数のＣＴＵ行が並列に符号化されるように関連したスレッド（ＷＰＰスレッド１，ＷＰＰスレッド２，…）を有している。

【0081】

[0087]ＨＭＶＰテーブルの現在の実施形態は、グローバルな動きベクトル（ＭＶ）バッファを用いて、過去に再構成された動きベクトルを格納しているので、このＨＭＶＰテーブルは、図５Ｂに関して上述したＷＰＰ有効型の並列符号化方式では実現できない。特に、グローバルなＭＶバッファがビデオコーダの符号化／復号処理の全てのスレッドで共有されているという事実は、先頭のＷＰＰスレッド（たとえば、ＷＰＰスレッド１）の後に続くＷＰＰスレッドが開始されることを妨げる。なぜならば、これらのＷＰＰスレッドは、先頭のＷＰＰスレッド（たとえば先頭のＣＴＵ行）の最後のＣＴＵ（たとえば右端のＣＴＵ）からＨＭＶＰテーブルの更新が完了するまで待たなければならないからである。

【0082】

[0088]このような課題を克服するために、ＷＰＰスレッドで共有されるグローバルなＭＶバッファをマルチＣＴＵ行専用のバッファに置き換えて、ビデオコーダのＷＰＰが有効なときに、ＣＴＵ行の各波面が、対応するＷＰＰスレッドで処理されるＣＴＵ行に対応するＨＭＶＰテーブルを格納するために自らのバッファを有するようにすることを提案する。自らのＨＭＶＰテーブルを有する各ＣＴＵ行は、当該ＣＴＵ行の先頭のＣＵをコーディングする前にＨＭＶＰテーブルをリセットすることと同等である点に注意すべきである。ＨＭＶＰテーブルのリセットとは、他のＣＴＵ行のコーディングから得られたＨＭＶＰテーブル内の全ての動きベクトルを消し去ることである。１つの実施形態では、そのリセット処理は、ＨＭＶＰテーブル内の利用可能な動きベクトル予測子のサイズをゼロに設定することである。他の実施形態では、そのリセット処理は、ＨＭＶＰテーブル内の全ての項目の参照インデックスを－１のような無効値に設定することもありうる。そのようにすることにより、特定の波面内の現在のＣＴＵに対するＭＶＰ候補リストは、ＡＭＶＰ，マージ及びスキップという３つのモードのうちのいずれのモードであろうとも、その特定の波面を処理するＷＰＰスレッドに関連したＨＭＶＰテーブルに応じて構成される。上記した２つのＣＴＵの遅延以外には異なる波面間の相互依存がなく、複数の異なる波面に関連した複数の動きベクトル候補リストを構成することを、図５Ｂに示したＷＰＰ処理のように並列に進行させることができる。言い換えれば、特定の波面を処理することを開始する際に、他のＷＰＰスレッドによって他のＣＴＵ波面のコーディングが影響を受けずに、ＨＭＶＰテーブルは空状態となるようにリセットされる。いくつか場合には、各ＣＴＵそれぞれのコーディングを行う前に、ＨＭＶＰテーブルは空状態となるようにリセットできる。この場合には、ＨＭＶＰテーブル内の動きベクトルは特定のＣＴＵに限定され、おそらく、当該ＨＭＶＰテーブル内の動きベクトルが、当該特定のＣＴＵ内の現在のＣＵの動きベクトルとして選択される可能性がより高くなる。

【0083】

[0089]図６は、本開示のいくつかの実施形態に従って、少なくともＨＭＶＰテーブルを用いて動きベクトル予測子の候補リストを構成する技術を実現するビデオ符号化器２０又はビデオ復号器３０などのビデオコーダによる処理例を示すフローチャートである。図で示すために、フローチャートはビデオ復号処理を示している。先ず、ビデオ復号器３０は、複数の符号化ピクチャに関連したデータを含む符号化ビデオビットストリームを取得する（６１０）。図４Ａ及び図４Ｃに示されるように、各ピクチャは、符号化ツリーユニット（ＣＴＵ）行を複数含み、各ＣＴＵは、１つ以上の符号化ユニット（ＣＵ）を含む。ビデオ復号器３０は、シンタックス要素及び画素値などの複数の異なる情報をビデオビットストリームから抽出して、行単位でピクチャを再構成する。

【0084】

[0090]現在のＣＴＵ行を復号する前に、ビデオ復号器３０は、先ず、当該現在のＣＴＵ行について履歴ベースの動きベクトル予測子（ＨＭＶＰ）テーブルをリセットする（６２０）。上記のとおり、ＨＭＶＰテーブルのリセットは、ビデオ復号器３０が、たとえばマルチスレッド処理を用いて現在のピクチャ内の複数のＣＴＵ行を並列に復号できることを保証し、１つのスレッドがＣＴＵ行ごと又はマルチコアプロセッサごとに自らのＨＭＶＰテーブルを有すること、もしくは、１つのコアがＣＴＵ行ごとに自らのＨＭＶＰテーブルを有すること、又はこれらの両方を保証するものである。さらにいくつかの他の実施形態では、現在のＣＴＵを復号する前に、ビデオ復号器３０は、先ず、当該現在のＣＴＵについて履歴ベースの動きベクトル予測子（ＨＭＶＰ）テーブルをリセットする（６２０）。上記のとおり、ＨＭＶＰテーブルのリセットは、たとえばマルチスレッド処理を用いて現在のピクチャ内の複数のＣＴＵを並列に復号できることを保証し、１つのスレッドがＣＴＵごと又はマルチコアプロセッサごとに自らのＨＭＶＰテーブルを有すること、もしくは、１つのコアがＣＴＵごとに自らのＨＭＶＰテーブルを有すること、又はこれらの両方を保証するものである。

【0085】

[0091]現在のＣＴＵ行を復号する間に（６３０）、ビデオ復号器３０は、ＨＭＶＰテーブル内の複数の動きベクトル予測子を整備する（６３０－１）。上記のとおり、ＨＭＶＰテーブルに格納されている各動きベクトル予測子は、現在のＣＴＵ行内の少なくとも他のＣＵを復号するために使用されていた。実際、ＨＭＶＰテーブルに動きベクトル予測子が存在するのは、ＨＭＶＰテーブルが上記のように動きベクトル候補リストを構成する処理に関与するときに、当該動きベクトル予測子が現在のＣＴＵ行内の他のＣＵを予測するために再度利用されるかもしれないからである。

【0086】

[0092]
[0093]現在のＣＴＵ行内の現在のＣＵについて、ビデオ復号器３０は、ビデオビットストリームから予測モードを抽出する（６３０－３）。上記のとおり、ＣＵは、高度動きベクトル予測（ＡＭＶＰ：advanced motion vector prediction）モード，マージモード，スキップモード，ＩＢＣ・ＡＭＶＰモード，及びＩＢＣマージモードを含む複数種の予測モードを有してよい。ビデオ符号化器２０がＣＵについて適切な予測モードを選択したら、当該選択された予測モードがビットストリームで信号伝達される。上記のとおり、動きベクトル候補リストを構成するために、様々な順序で実行される様々なステップ群が存在する。ここで、ビデオ復号器３０は、当該予想モードに従って、ＨＭＶＰテーブル内の複数の動きベクトル予測子の少なくとも一部に基づいて動きベクトル候補リストを構成する（６３０－５）。他の情報源、これから動きベクトル候補リストは、現在のＣＵに対して空間的に近隣のＣＵ及び／又は時間的に連結するＣＵに由来する動きベクトル予測子（予測モードが、ＡＭＶＰモード，ＩＢＣ・ＡＭＶＰモード及びＩＢＣマージモードのうちの１つである場合）を含み、オプションとしてペアワイズな動きベクトル予測子（予測モードが、マージモード及びスキップモードのうちの１つである場合）を含む。オプションとして、動きベクトル候補リストが所定長とならないときは、動きベクトル候補リストに１つ以上のゼロ値の動きベクトル予測子が追加されればよい。

【0087】

[0094]次に、ビデオ復号器３０は、動きベクトル候補リストの中から、現在のＣＵについて動きベクトル予測子を選択し（６３０－７）、当該選択された動きベクトル予測子と予測モードとの少なくとも一部に基づいて、動きベクトルを決定する（６３０－９）。上記のとおり、当該予測モードがＡＭＶＰモードであるか否かに応じて、当該選択された動きベクトル予測子は、現在のＣＵについての推定動きベクトルであるか否かであってよい。たとえば、当該予測モードがＡＭＶＰモードであれば、推定動きベクトルは、ビットストリームから再生された動きベクトル差分を、当該選択された動きベクトル予測子に加算することによって決定され、次いで、その推定動きベクトルと参照ピクチャ内の対応するＣＵとを少なくとも部分的に用いて現在のＣＵが復号される。しかしながら、予測モードがマージモード又はスキップモードであれば、当該選択された動きベクトル予測子は既に推定動きベクトルであり、現在のＣＵを、参照ピクチャ内の対応するＣＵとともに復号する際に使用できるものである。最終的に、ビデオ復号器３０は、当該決定された動きベクトルに基づいてＨＭＶＰテーブルを更新する（６３０－１１）。上記のとおり、ＨＭＶＰテーブル内のすべての要素は、以前に少なくとも他のＣＵを復号するために使用されており、現在のＣＴＵ行内における次の他のＣＵを復号するために使用される動きベクトルの挿入により又はテーブルリセットによりＨＭＶＰテーブルから削除されるまで、動きベクトル候補リストを構成するためにＨＭＶＰテーブル内に保持される。

【0088】

[0095]いくつかの実施形態では、ＨＭＶＰテーブルへの動きベクトルの挿入には、現在のＣＵについて決定された動きベクトルと、ＨＭＶＰテーブル内の複数の動きベクトル予測子との比較結果に基づいて２つのシナリオの可能性がある。ＨＭＶＰテーブル内の複数の動きベクトル予測子のいずれもが当該決定された動きベクトルと同一ではないときは、ＨＭＶＰテーブルが限度一杯であれば、ＨＭＶＰテーブルから最先又は最古の動きベクトル予測子が削除されて、当該動きベクトルが最新のものとしてそのテーブルに追加される。ＨＭＶＰテーブル内の複数の動きベクトル予測子のうちの１つが当該動きベクトルと同一であるときは、当該同一の１つの動きベクトル予測子がＨＭＶＰテーブルから削除され、その削除された動きベクトル予測子の後の他の動きベクトル予測子は全てＨＭＶＰテーブル内で前方に移動させられて、当該動きベクトルが最新のものとしてＨＭＶＰテーブルの後部に追加されるようになる。

【0089】

[0096]上記のとおり、複数のＣＴＵ行のうちの２つ以上が、たとえばＷＰＰを用いて並列に符号化／復号されてよく、各ＣＴＵ行は、対応するＣＴＵ行を符号化／復号するために使用される履歴ベースの動きベクトル予測子を複数格納するために関連したＨＭＶＰテーブルを有している。たとえば、復号される現在のピクチャ内における特定のＣＴＵ行の復号に対してスレッドが割り当てられて、図５Ｂに関して上述したように複数の異なるＣＴＵ行が複数の異なる関連スレッドを有して復号できるようにされる。いくつかの例では、ビデオ復号器３０は、動きベクトル候補リスト内の１つ以上の動きベクトル予測子を冗長なものとして特定し、それを動きベクトル候補リストから削除して符号化効率をさらに向上させる。

【0090】

[0097]１つ以上の例では、上記の機能は、ハードウェア，ソフトウェア，またはこれらの組合せで実現されてよい。上記の機能は、ソフトウェアで実現されているときは、１つ以上の命令又は符号としてコンピュータ読み取り可能な媒体に格納又は送信されて、ハードウェアベースの処理ユニットで実行されればよい。コンピュータ読み取り可能な媒体は、記録媒体などの有形媒体に相当するコンピュータ読み取り可能な記録媒体、又は、たとえば通信プロトコルに従って１つの場所から他の場所へコンピュータプログラムを転送することを実現しやすくする任意の媒体を有する通信媒体を含んでよい。このようにコンピュータ読み取り可能な媒体は、一般に、（１）有形の非一時的なコンピュータ読み取り可能な記録媒体、又は（２）信号又はキャリア波などの通信媒体、に相当するものであればよい。データ記録媒体は、本出願に説明される実施形態を実現する命令，符号及び／又はデータ構造を取得するために１つ以上のコンピュータ又は１つ以上のプロセッサによりアクセス可能な何らかの利用可能な媒体であればよい。コンピュータプログラム製品は、コンピュータ読み取り可能な媒体を含んでもよい。

【0091】

[0098]本明細書の実施形態の説明で使用された用語は、特定の実施形態を説明する目的だけのものであり、特許請求の範囲を限定することを意図したものではない。実施の形態の説明及び添付の特許請求の範囲で使用される「ａ」，「ａｎ」，「ｔｈｅ」の単数形は、その文脈が明確に否定している場合を除き、複数形も含むことを意図したものである。また本明細書で使用される「及び／又は」との表現は、リスト化される関連項目のうちの１つ以上の任意かつ全てのありうる組合せを意味しかつ包含していることが理解されるであろう。さらに、「備える」（"ｃｏｍｐｒｉｓｅｓ"）及び／又は「備えている」（"ｃｏｍｐｒｉｓｉｎｇ"）との表現は、この明細書で使用される際には、定められた特徴，成分，及び／又は要素の存在を特定するものであるが、１つ以上の他の特徴，要素，部品，及び／又はこれらの組合せの存在又は追加を除外するものではないことが理解されるであろう。

【0092】

[0099]「第１の（先頭の）」及び「第２の」などの用語は、多種多様な要素を説明するために本明細書で使用されているが、これらの要素は、当該用語によって限定されるべきではないことも理解されるであろう。これらの用語は、要素同士を区別するためにのみ使用されている。たとえば、実施形態の範囲から逸脱しないように、第１の電極が第２の電極と呼ばれることがありうるし、同様に、第２の電極が第１の電極と呼ばれることもありうる。第１の電極と第２の電極とはともに電極であるが、同じ電極ではない。

【0093】

[00100]本出願の記述は、図示と説明のためになされたものであり、網羅的であること又は本発明に対する開示形態への限定を意図するものではない。上記説明及びその関連図面に示される教示の利益を受ける当業者であれば、多くの改良，変形及び代替的な実施形態は明らかであろう。本発明の原理や実際の適用例を最大限説明するために、また、当業者が種々の実施形態について本発明を理解して、その基礎をなす原理と、意図する特定の用途に適する種々の変形例とともに多種多様な実施形態とを最大限利用できるように、上記実施形態が選択され説明されている。したがって、特許請求の範囲は、開示された実施形態の特定例に限定されるべきではなく、変形例及び他の実施形態は添付の特許請求の範囲に包含されることを意図している点が理解されるべきである。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図4D】

【図5A】

【図5B】

【図6】