JP2015529065A

JP2015529065A - スケーラブルビデオコーディングおよび３ｄビデオコーディングのための多重仮説動き補償

Info

Publication number: JP2015529065A
Application number: JP2015526609A
Authority: JP
Inventors: リ、シャン; チェン、ジャンレ; カークゼウィックズ、マルタ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2012-08-07
Filing date: 2013-08-05
Publication date: 2015-10-01
Also published as: WO2014025692A1; US9635356B2; CN104521237A; CN104521237B; US20140044179A1

Abstract

いくつかの態様による、ビデオ情報をコーディングするための装置は、メモリユニットと、メモリユニットと通信しているプロセッサとを含む。メモリユニットは、参照レイヤおよびエンハンスメントレイヤのビデオ情報を記憶する。プロセッサは、明示的な仮説および参照レイヤからの動き情報から計算された暗黙的な仮説に少なくとも部分的に基づいて、エンハンスメントレイヤの現在のビデオユニットの値を決定する。

Description

[0001] 本開示は、ビデオコーディングに関する。

[0002] デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−ＴＨ．２６３、ＩＴＵ−ＴＨ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ（ＡＶＣ）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオコーディング技法のような、ビデオコーディング技法を実装する。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。

[0003] ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースのビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

[0004] 空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コード化ブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて残差変換係数をもたらすことができ、その残差変換係数は、次いで量子化され得る。量子化変換係数は、最初に２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査されてよく、なお一層の圧縮を達成するためにエントロピーコーディングが適用されてよい。

[0005] 一般に、本開示は、スケーラブルビデオコーディング（ＳＶＣ）に関係する技法を記載する。いくつかの実施形態では、ビデオ圧縮による画像のひずみを減らすために、明示的に符号化された仮説と暗黙的に導出された仮説の両方を使用する多重仮説動き補償が使用される。たとえば、エンハンスメントレイヤでビデオユニットをコーディングしながら、ビデオコーダは、参照レイヤからの情報を使用して、さらなる仮説を識別するために使用され得るさらなる動き補償データを取得することができる。これらのさらなる仮説は、ビデオのビットストリーム内にすでに存在するデータから暗黙的に導出されるので、ビットストリームのサイズにおける追加コストがほとんどまたはまったくない状態で、ビデオコーディングにおけるさらなる性能が得られ得る。別の例では、さらなる仮説を見つけるために、空間的に隣接するビデオユニットからの動き情報が使用され得る。次いで、導出された仮説は、明示的に符号化された仮説と平均化されるか、または場合によっては組み合わされて、ビデオユニットの値のより良い予測を生成することができる。

[0006] １つまたは複数の例の詳細が、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面から、および特許請求の範囲から明らかになろう。

[0007] 図面全体にわたって、参照される要素間の対応を示すために参照番号が再使用される場合がある。図面は、本明細書に記載される例示的な実施形態を図示するために提供され、本開示の範囲を限定するものではない。

[0008] 本開示に記載される態様に従って技法を利用することができる、例示的なビデオ符号化システムとビデオ復号システムとを示すブロック図。 [0009] 本開示に記載される態様に従って技法を実装することができる、ビデオエンコーダの一例を示すブロック図。 [0010] 本開示に記載される態様に従って技法を実装することができる、ビデオデコーダの一例を示すブロック図。 [0011] 本開示の態様による、例示的な候補動きベクトルを示すブロック図。 [0012] 本開示の態様による、空間候補の走査を示すブロック図。 [0013] 本開示の態様による、Ｂスライス用の空間ＭＶＰ候補を導出する一例を示すブロック図。 [0014] 本開示の態様による、３つの異なる次元におけるスケーラビリティを示すブロック図。 [0015] 本開示の態様による、ＳＶＣビットストリームの例示的な構造を示すブロック図。 [0016] 本開示の態様による、ビットストリーム内の例示的なＳＶＣアクセスユニットを示すブロック図。 [0017] 本開示の態様による、暗黙的な多重仮説動き補償（ＩＭＭＣ）のための例示的な方法を示すブロック図。 [0018] 本開示の態様による、符号化ルーチン用の方法の一実施形態を示すフローチャート。 [0019] 本開示の態様による、復号ルーチン用の方法の一実施形態を示すフローチャート。

[0020] 本開示に記載される技法は、一般に、スケーラブルビデオコーディング（ＳＶＣ）および３Ｄビデオコーディングに関する。たとえば、本技法は、高効率ビデオコーディング（ＨＥＶＣ）のスケーラブルビデオコーディング（ＳＶＣ）拡張に関係し、それとともに、またはその中で使用される場合がある。ＳＶＣ拡張では、複数のレイヤのビデオ情報が存在する可能性がある。最下位レベルにあるレイヤは基本レイヤ（ＢＬ）として働くことができ、最上位にあるレイヤは強調レイヤ（ＥＬ）として働くことができる。「強調レイヤ」は時々「エンハンスメントレイヤ」と呼ばれ、これらの用語は互換的に使用される場合がある。中間にあるすべてのレイヤは、ＥＬまたは参照レイヤ（ＲＬ）のどちらか、または両方として働くことができる。たとえば、中間にあるレイヤは、基本レイヤまたは任意の介在するエンハンスメントレイヤなどのその下のレイヤ用のＥＬであり得るし、同時にその上のエンハンスメントレイヤ用のＲＬとして働くことができる。

[0021] 単に例示のために、本開示に記載される技法は、２つのみのレイヤ（たとえば、基本レイヤなどの下位レベルレイヤ、および強調レイヤなどの上位レベルレイヤ）を含む例を用いて記載される。本開示で記載される例は、複数の基本レイヤとエンハンスメントレイヤとを有する例にも拡張され得ることを理解されたい。加えて、説明を簡単にするために、以下の開示は「フレーム」または「ブロック」という用語を主に使用する。しかしながら、これらの用語は限定的ではあり得ない。たとえば、以下に記載される技法は、ブロック（たとえば、ＣＵ、ＰＵ、ＴＵ、マクロブロックなど）、スプライス、フレームなどの様々なビデオユニットとともに使用され得る。

ビデオコーディング規格
[0022] ビデオコーディング規格には、ＩＴＵ−ＴＨ．２６１、ＩＳＯ／ＩＥＣＭＰＥＧ−１Ｖｉｓｕａｌ、ＩＴＵ−ＴＨ．２６２またはＩＳＯ／ＩＥＣＭＰＥＧ−２Ｖｉｓｕａｌ、ＩＴＵ−ＴＨ．２６３、ＩＳＯ／ＩＥＣＭＰＥＧ−４Ｖｉｓｕａｌ、および、そのスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）の拡張を含む（ＩＳＯ／ＩＥＣＭＰＥＧ−４ＡＶＣとしても知られている）ＩＴＵ−ＴＨ．２６４が含まれる。加えて、ＩＴＵ−ＴＶｉｄｅｏＣｏｄｉｎｇＥｘｐｅｒｔｓＧｒｏｕｐ（ＶＣＥＧ）とＩＳＯ／ＩＥＣＭｏｔｉｏｎＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ（ＭＰＥＧ）とのＪｏｉｎｔＣｏｌｌａｂｏｒａｔｉｏｎＴｅａｍｏｎＶｉｄｅｏＣｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって開発されている新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）がある。ＨＥＶＣの最新ドラフトは、２０１２年６月７日現在、ｈｔｔｐ：／／ｗｇ１１．ｓｃ２９．ｏｒｇ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｃｕｒｒｅｎｔ＿ｄｏｃｕｍｅｎｔ．ｐｈｐ？ｉｄ＝５８８５／ＪＣＴＶＣ−Ｉ１００３−ｖ２から入手可能である。

「ＨＥＶＣ作業ドラフト７」と呼ばれるＨＥＶＣ規格の別の最新ドラフトは、２０１２年６月７日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／９＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｉ１００３−ｖ３．ｚｉｐからダウンロード可能である。ＨＥＶＣ作業ドラフト７用の完全な引用は、文書ＨＣＴＶＣ−Ｉ１００３、Ｂｒｏｓｓら、「ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＶｉｄｅｏＣｏｄｉｎｇ（ＨＥＶＣ）ＴｅｘｔＳｐｅｃｉｆｉｃａｔｉｏｎＤｒａｆｔ７」、ＩＴＵ−ＴＳＧ１６ＷＰ３とＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１とのＪｏｉｎｔＣｏｌｌａｂｏｒａｔｉｖｅＴｅａｍｏｎＶｉｄｅｏＣｏｄｉｎｇ（ＪＣＴ−ＶＣ）、第９回会合、ジュネーブ、スイス、２０１２年４月２７日〜２０１２年５月７日である。これらの参照文献の各々は、その全体が参照により組み込まれる。

[0023] スケーラブルビデオコーディング（ＳＶＣ）は、（信号対雑音比（ＳＮＲ）とも呼ばれる）品質スケーラビリティ、空間スケーラビリティ、および／または時間スケーラビリティを実現するために使用され得る。たとえば、一実施形態では、参照レイヤ（たとえば、基本レイヤ）は、第１の品質レベルでビデオを表示するのに十分なビデオ情報を含み、エンハンスメントレイヤは、参照レイヤと比べてさらなるビデオ情報を含み、その結果、参照レイヤおよびエンハンスメントレイヤは一緒に、第１の品質レベルよりも高い第２の品質レベル（たとえば、少ない雑音、大きい解像度、より良いフレームレートなど）でビデオを表示するのに十分なビデオ情報を含む。強調レイヤは、基本レイヤとは異なる空間解像度を有することができる。たとえば、ＥＬとＢＬとの間の空間アスペクト比は、１．０、１．５、２．０、または他の異なる比であり得る。言い換えれば、ＥＬの空間アスペクトは、ＢＬの空間アスペクトの１．０倍、１．５倍、または２．０倍に等しい場合がある。いくつかの例では、ＥＬの倍率は、ＢＬの倍率よりも大きい場合がある。たとえば、ＥＬ内のピクチャのサイズは、ＢＬ内のピクチャのサイズよりも大きい場合がある。このようにして、限定ではないが、ＥＬの空間解像度がＢＬの空間解像度よりも大きいことは可能であり得る。

[0024] Ｈ．２６４用のＳＶＣ拡張では、現在のブロックの予測は、ＳＶＣ用に提供された様々なレイヤを使用して実施され得る。そのような予測は、レイヤ間予測と呼ばれる場合がある。レイヤ間予測方法は、レイヤ間の冗長性を低減するためにＳＶＣ内で利用され得る。レイヤ間予測のいくつかの例には、レイヤ間イントラ予測、レイヤ間動き予測、およびレイヤ間残差予測が含まれ得る。レイヤ間イントラ予測は、基本レイヤ内の同じ位置にあるブロックの復元を使用して、エンハンスメントレイヤ内の現在のブロックを予測する。レイヤ間動き予測は、基本レイヤの動きを使用して、エンハンスメントレイヤ内の動きを予測する。レイヤ間残差予測は、基本レイヤの残差を使用して、エンハンスメントレイヤの残差を予測する。

[0025] レイヤ間動き予測のいくつかの実施形態では、（たとえば、同じ位置にあるブロックについての）基本レイヤの動きデータは、エンハンスメントレイヤ内の現在のブロックを予測するために使用される場合がある。たとえば、エンハンスメントレイヤでビデオユニットをコーディングしながら、ビデオコーダは、参照レイヤからの情報を使用して、さらなる仮説を識別するために使用され得るさらなる動き補償データを取得することができる。これらのさらなる仮説は、ビデオビットストリーム内にすでに存在するデータから暗黙的に導出されるので、ビットストリームのサイズにおける追加コストがほとんどまたはまったくない状態で、ビデオコーディングにおけるさらなる性能が得られ得る。別の例では、さらなる仮説を見つけるために、空間的に隣接するビデオユニットからの動き情報が使用され得る。次いで、導出された仮説は、明示的に符号化された仮説と平均化されるか、または場合によっては組み合わされて、ビデオユニットの値のより良い予測を生成することができる。

[0026] 添付の図面を参照して、新規のシステム、装置、および方法の様々な態様が以下でより十分に記載される。しかしながら、本開示は、多くの異なる形態で具現化される場合があり、本開示全体にわたって提示される任意の特定の構造または機能に限定されるものと解釈されるべきではない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるように提供される。本明細書の教示に基づいて、本開示の範囲は、本発明の任意の他の態様とは無関係に実装されるにせよ、または本開示の任意の他の態様と組み合わせて実装されるにせよ、本明細書で開示される新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者は諒解されたい。たとえば、本明細書に記載の任意の数の態様を使用して、装置が実現され得るか、または方法が実践され得る。加えて、本発明の範囲は、本明細書に記載の本発明の様々な態様に加えて、またはそれらの態様以外に、他の構造、機能、または構造および機能を使用して実践される、そのような装置または方法をカバーするものとする。本明細書で開示される任意の態様が請求項の１つまたは複数の要素によって具現化され得ることを理解されたい。

[0027] 本明細書では特定の態様が記載されるが、これらの態様の多くの変形および置換は本開示の範囲内に入る。好ましい態様のいくつかの利益および利点が言及されるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、様々なワイヤレス技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であるものであり、そのうちのいくつかが、図および好ましい態様の以下の説明で例として示される。発明を実施するための形態および図面は、限定的なものではなく本開示を説明するものにすぎず、本開示の範囲は、添付の特許請求の範囲およびその均等物によって規定される。

[0028] 図１は、本開示に記載される態様に従って技法を利用することができる、例示的なビデオ符号化システムとビデオ復号システムとを示すブロック図である。図１に示されるように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介してビデオデータを宛先デバイス１４に与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（たとえば、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に対応し得る。

[0029] 宛先デバイス１４は、コンピュータ可読媒体１６を介して復号されるべき符号化ビデオデータを受信し得る。コンピュータ可読媒体１６は、ソースデバイス１２から宛先デバイス１４に符号化ビデオデータを移動させることができる任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、符号化ビデオデータを宛先デバイス１４にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、高周波（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路のような、任意のワイヤレスまたは有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークのような、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。

[0030] いくつかの例では、符号化データは、出力インターフェース２２からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは、符号化されたビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような、種々の分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、有線接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。

[0031] 本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、ｄｙｎａｍｉｃａｄａｐｔｉｖｅｓｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、種々のマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

[0032] 図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。本開示によれば、ソースデバイス１２のビデオエンコーダ２０は、複数の規格または規格拡張に準拠するビデオデータを含むビットストリームをコーディングするための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは他のコンポーネントまたは構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、内蔵ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。

[0033] 図１の図示されたシステム１０は一例にすぎない。現在のブロック用の動きベクトル予測子のための予測リスト用の候補を決定するための技法は、任意のデジタルビデオの符号化デバイスおよび／または復号デバイスによって実施され得る。一般に、本開示の技法はビデオ符号化デバイスによって実行されるが、本技法は、通常「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。その上、本開示の技法はまた、ビデオプリプロセッサによって実行され得る。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化コンポーネントとビデオ復号コンポーネントとを含むように、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話のための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートすることができる。

[0034] ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブされたビデオとコンピュータにより生成されたビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはビデオ電話を形成し得る。しかしながら、上述のように、本開示で説明される技法は、全般にビデオコーディングに適用可能であってよく、ワイヤレスおよび／または有線の適用例に適用可能であってよい。各々の場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータで生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。

[0035] コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたは有線ネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、たとえば、ネットワーク送信、直接有線通信などを介して、ソースデバイス１２から符号化されたビデオデータを受信し、宛先デバイス１４に符号化ビデオデータを与え得る。同様に、ディスクスタンピング設備などの媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを製造することができる。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。

[0036] 宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号ビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスのいずれかを備え得る。

[0037] ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作することができ、ＨＥＶＣＴｅｓｔＭｏｄｅｌ（ＨＭ）に準拠することができる。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４、Ｐａｒｔ１０、ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−ＴＨ．２６４規格のような、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。しかしながら、本開示の技法は、限定はしないが、上記に列挙された規格のうちのいずれかを含む、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−ＴＨ．２６３がある。いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は各々、オーディオエンコーダおよびオーディオデコーダと統合されてよく、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアとソフトウェアとを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵＨ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。

[0038] ビデオエンコーダ２０およびビデオデコーダ３０は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアのような、種々の適切なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアのための命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行することができる。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／または携帯電話などのワイヤレス通信デバイスを備える場合がある。

[0039] ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣＴｅｓｔＭｏｄｅｌ（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−ＴＨ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。

[0040] 一般に、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマとクロマの両方のサンプルを含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ）に分割され得ることを記載する。ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大コーディングユニットであるＬＣＵのサイズを定義し得る。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。一般に、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。

[0041] ４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義されてよく、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがさらに分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的分割が存在しない場合でも、リーフＣＵの４つのサブＣＵもリーフＣＵと呼ばれる。たとえば、１６×１６サイズのＣＵがこれ以上分割されない場合、この１６×１６ＣＵがまったく分割されなくても、４つの８×８サブＣＵもリーフＣＵと呼ばれる。

[0042] ＣＵは、ＣＵがサイズ差異を有さないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、４つの子ノード（サブＣＵとも呼ばれる）に分割されてよく、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割されてよい。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深さと呼ばれる、ツリーブロックが分割され得る最大回数を定義することができ、また、コーディングノードの最小サイズを定義することもできる。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ）も定義することができる。本開示では、ＨＥＶＣの文脈におけるＣＵ、ＰＵ、またはＴＵ、あるいは他の規格の文脈における同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそれのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。

[0043] ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルを有するツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化またはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、あるいはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非正方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。

[0044] ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従った変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは通常、ＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ）として知られる４分木構造を使用して、より小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、量子化され得る変換係数を生成するために変換され得る。

[0045] リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。一般に、ＰＵは、対応するＣＵのすべてまたは一部分に対応する空間的エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのデータは、ＰＵに対応するＴＵのイントラ予測モードを記述するデータを含み得る、残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０、リスト１、もしくはリストＣ）を記述し得る。

[0046] １つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。変換ユニットは、上で論じられたように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットは、さらに、さらなるサブＴＵに分割され得る。ＴＵがさらに分割されないとき、そのＴＵはリーフＴＵと呼ばれ得る。一般に、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、一般に、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵはＰＵよりも大きくまたは小さくなり得る。イントラコーディングの場合、ＰＵは、同じＣＵのための対応するリーフＴＵと同じ位置にあり得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応し得る。

[0047] その上、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造と関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは一般にリーフＣＵに対応し、ＣＵ４分木のルートノードは一般にツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。全般に、本開示では、別段明記されない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。

[0048] ビデオシーケンスは通常、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、一般に、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は通常、ビデオデータを符号化するために個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定のサイズまたは可変のサイズを有してよく、指定されるコーディング規格に応じてサイズが異なり得る。

[0049] 一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５ＮＰＵと下部の２Ｎ×１．５ＮＰＵへと水平方向に区分された２Ｎ×２ＮＣＵを指す。

[0050] 本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ただし、Ｎは非負整数値を表す。ブロック内のピクセルは行と列で構成され得る。さらに、ブロックは、必ずしも、水平方向に垂直方向と同じ数のピクセルを有さなくてもよい。たとえば、ブロックはＮ×Ｍピクセルを備えてよく、ただし、Ｍは必ずしもＮに等しいとは限らない。

[0051] ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備えてよく、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後の、変換領域における係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵの変換係数を生成し得る。

[0052] 変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、その最も広い通常の意味を有するように意図された広義語である。一実施形態では、量子化は、係数を表すために使用されるデータの量をできるだけ低減し、さらなる圧縮を実現するために、変換係数が量子化されるプロセスを指す。量子化プロセスは、係数の一部またはすべてに関連するビット深度を低減することができる。たとえば、量子化中にｎビット値がｍビット値に切り捨てられてよく、ｎはｍよりも大きい。

[0053] 量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、あらかじめ定義された走査順序を利用して、量子化された変換係数を走査し、エントロピー符号化され得る直列化されたベクトルを生成し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディング、または別のエントロピー符号化方法に従って、１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化することができる。

[0054] ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルにコンテキストモデル内のコンテキストを割り当てることができる。コンテキストは、たとえば、シンボルの隣接値が０ではないかどうかに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルのための可変長コードを選択することができる。ＶＬＣにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣを使用すると、たとえば、送信されるべきシンボルごとに等長コードワードを使用するよりも、ビットの節約を実現することができる。確率の決定は、シンボルに割り当てられるコンテキストに基づき得る。

[0055] ビデオエンコーダ２０はさらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびＧＯＰベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送り得る。ＧＯＰシンタックスデータは、それぞれのＧＯＰ中のいくつかのフレームを記述することができ、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化／予測モードを示すことができる。

[0056] 図２は、本開示に記載される態様に従って技法を実装することができる、ビデオエンコーダの一例を示すブロック図である。ビデオエンコーダ２０は、本開示の技法のうちのいずれかまたはすべてを実施するように構成され得る。一例として、モード選択ユニット４０は、本開示に記載された技法のうちのいずれかまたはすべてを実施するように構成され得る。しかしながら、本開示の態様はそのようには限定されない。いくつかの例では、本開示に記載された技法は、ビデオエンコーダ２０の様々な構成要素の間で共有される場合がある。追加または代替のいくつかの例では、プロセッサ（図示せず）は、本開示に記載された技法のうちのいずれかまたはすべてを実施するように構成され得る。

[0057] ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングとインターコーディングとを実行し得る。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去する。インターコーディングは、時間的予測を利用して、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード（Ｉモード）は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。

[0058] 図２に示されるように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在のビデオブロックを受信する。図１の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照フレームメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、今度は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測ユニット４６と、区分ユニット４８とを含む。ビデオブロックの復元のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。復元されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングする、デブロッキングフィルタ（図２に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは一般に、加算器６２の出力をフィルタリングすることになる。また、デブロッキングフィルタに加えて追加のフィルタ（ループ内またはループ後）が使用され得る。そのようなフィルタは、簡潔のために示されていないが、所望される場合、（ループ内フィルタとして）加算器５０の出力をフィルタリングし得る。

[0059] 符号化プロセス中に、ビデオエンコーダ２０は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的な予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対する受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測ユニット４６は代替的に、空間的な予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。

[0060] その上、区分ユニット４８は、前のコーディングパスにおける前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、さらに、ＬＣＵをサブＣＵに区分することを示す４分木データ構造を生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。

[0061] モード選択ユニット４０は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラまたはインターのうちの１つを選択することができ、残差ブロックデータを生成するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器５０に与え、参照フレームとして使用するための符号化ブロックを復元するために、得られたイントラコーディングされたブロックまたはインターコーディングされたブロックを加算器６２に与える。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、区分情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット５６に与える。

[0062] 動き推定ユニット４２および動き補償ユニット４４は高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または他のコード化ユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対する現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるブロックに精密に一致することがわかっているブロックである。いくつかの例では、ビデオエンコーダ２０は、参照フレームメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。

[0063] 動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵのための動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択されてよく、それらの参照ピクチャリストの各々は、参照フレームメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。

[0064] 動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。現在のビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、参照ピクチャリストのうちの１つにおいて動きベクトルが指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明されるように、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。一般に、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。

[0065] イントラ予測ユニット４６は、上で説明されたように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測または計算し得る。特に、イントラ予測ユニット４６は、現在のブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット４６は、たとえば、別々の符号化パスの間に、様々なイントラ予測モードを使用して、現在のブロックを符号化することができ、イントラ予測ユニット４６（または、いくつかの例において、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。

[0066] たとえば、イントラ予測ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、一般に、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを判定するために、様々な符号化ブロックのひずみおよびレートから比率を計算し得る。

[0067] ブロック用のイントラ予測モードを選択した後、イントラ予測ユニット４６は、ブロック用に選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット５６に提供することができる。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ２０は、（コードワードマッピングテーブルとも呼ばれる）複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブルと、様々なブロック用の符号化コンテキストの定義と、最確イントラ予測モードの指示とを含み得る送信されるビットストリーム構成データの中に、コンテキストの各々について使用する、イントラ予測モードインデックステーブルと修正されたイントラ予測モードインデックステーブルとを含めることができる。

[0068] ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって、残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数のコンポーネントを表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部またはすべてに関連するビット深度を低減することができる。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。

[0069] 量子化の後、エントロピー符号化ユニット５６は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行し得る。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングの後、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されてよく、または後で送信するかもしくは取り出すために保管され得る。

[0070] 逆量子化ユニット５８および逆変換ユニット６０は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを復元する。動き補償ユニット４４は、残差ブロックを参照フレームメモリ６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、復元された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６２は、復元された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照フレームメモリ６４に記憶するための復元されたビデオブロックを生成する。復元されたビデオブロックは、後続のビデオフレーム中のブロックをインターコーディングするための参照ブロックとして、動き推定ユニット４２および動き補償ユニット４４によって使用され得る。

[0071] 図３は、本開示に記載される態様に従って技法を実装することができる、ビデオデコーダの一例を示すブロック図である。ビデオデコーダ３０は、本開示の技法のうちのいずれかまたはすべてを実施するように構成され得る。一例として、動き補償ユニット７２および／またはイントラ予測ユニット７４は、本開示に記載された技法のうちのいずれかまたはすべてを実施するように構成され得る。しかしながら、本開示の態様はそのようには限定されない。いくつかの例では、本開示に記載された技法は、ビデオデコーダ３０の様々な構成要素の間で共有される場合がある。追加または代替のいくつかの例では、プロセッサ（図示せず）は、本開示に記載された技法のうちのいずれかまたはすべてを実施するように構成され得る。

[0072] 図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測ユニット７４と、逆量子化ユニット７６と、逆変換ユニット７８と、参照フレームメモリ８２と、加算器８０とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明された符号化パスとは全般に逆の復号パスを実行し得る。動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルに基づいて予測データを生成することができ、イントラ予測ユニット７４は、エントロピー復号ユニット７０から受信されたイントラ予測モードインジケータに基づいて予測データを生成することができる。

[0073] 復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化係数と、動きベクトルまたはイントラ予測モードインジケータと、他のシンタックス要素とを生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

[0074] ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測ユニット７４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（たとえば、Ｂ、Ｐ、またはＧＰＢ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャの１つから生成され得る。ビデオデコーダ３０は、参照フレームメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト０とリスト１とを構築し得る。動き補償ユニット７２は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックについての予測情報を決定し、予測情報を使用して、復号されている現在のビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）、インター予測スライスタイプ（たとえば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）、スライスの参照ピクチャリストのうちの１つまたは複数に対する構成情報、スライスの各インター符号化ビデオブロックに対する動きベクトル、スライスの各インターコード化ビデオブロックに対するインター予測ステータス、および現在のビデオスライス中のビデオブロックを復号するための他の情報を決定するために、受信されたシンタックス要素のいくつかを使用する。

[0075] 動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルの補間値を計算し得る。この場合、動き補償ユニット７２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。

[0076] 逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット８０によって復号された量子化変換係数を逆量子化（inverse quantize）、たとえば、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を判定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ３０によって計算される量子化パラメータＱＰ_Yの使用を含み得る。逆変換ユニット７８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換処理を変換係数に適用して、ピクセル領域において残差ブロックを生成する。

[0077] 動き補償ユニット８２が、動きベクトルと他のシンタックス要素とに基づいて現在のビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数のコンポーネントを表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号されたブロックをフィルタリングするためのデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化し、または別様にビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャの中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ９２に記憶される。参照フレームメモリ８２はまた、図１のディスプレイデバイス３２のようなディスプレイデバイス上での後の表示のために、復号されたビデオを記憶する。

ＨＥＶＣにおける動き補償
[0078] 上述されたように、ＨＥＶＣは次世代のビデオコーディング規格である。概して、ＨＥＶＣは以前のビデオコーディング規格の枠組に追従する。ＨＥＶＣの動き補償ループは、Ｈ．２６４／ＡＶＣにおける動き補償ループと同じに保持される、すなわち現在のフレームの復元

は、逆量子化係数γプラス時間予測Ｐに等しい。

[0079] ここで、ＰはＰフレームまたはＰスライスについての単方向予測、またはＢフレームまたはＢスライスについての双方向予測を示す。

[0080] ＨＥＶＣにおける動き補償の単位は、以前のビデオコーディング規格における単位とは異なる。実際、以前のビデオコーディング規格におけるマクロブロックの概念は、ＨＥＶＣでは存在しない。代わりに、マクロブロックの概念は、一般的な４分木方式に基づく極めて柔軟な階層構造によって置き換えられる。この方式の中で、３タイプのブロック、すなわちコーディングユニット（ＣＵ）、予測ユニット（ＰＵ）、および変換ユニット（ＴＵ）が定義される。ＣＵは領域分割の基本単位である。ＣＵはマクロブロックの概念に類似するが、それは最大サイズを制限せず、それは４つの等しいサイズのＣＵへの再帰分割がコンテンツの適応性を向上させることを可能にする。ＰＵはインター／イントラ予測の基本単位であり、それは単一のＰＵ内に複数の任意の形状のパーティションを含んで、不規則な画像パターンを効果的にコーディングすることができる。ＴＵは変換の基本単位である。それはＰＵとは無関係に定義され得るが、そのサイズはＴＵが属するＣＵに限定される。このようにブロック構造を３つの異なる概念に分割すると、各々がその役割に応じて最適化されることが可能になり、その結果、コーディング効率が改善される。

[0081] 一般に、多重仮説動き補償では、現在のフレームを予測するために、２つ以上の動き補償予測信号が同時に使用される。今日では、Ｂフレームが２仮説動き補償の最も一般的な例である。多重仮説動き補償に対して行われた調査により、仮説の数を増加させると、一般により高いコーディング効率がもたらされることが見出されている。さらなる調査は、さらなる仮説の動き情報のビットコストが考慮されるとき、２仮説動き補償がほぼ最適であることを示す。したがって、さらなる仮説（たとえば、第３または第４の仮説）の使用からのさらなる品質またはコーディング効率を得る利益よりも、さらなる仮説用のさらなる動き情報を符号化するビットコストが勝るので、２仮説動き補償が今日のビデオコーディング規格および実際のビデオコーデックで広く採用される。しかしながら、下記の開示は、いくつかの実施形態において、最小限の追加データのみがビットストリームの中に符号化されることを要求しながら、さらなる仮説が使用されることを可能にするシステムとデバイスとを記載する。むしろ、システムおよびデバイスは、既存のデータを使用してさらなる仮説を導出することができる。

ＨＥＶＣにおける動き予測
[0082] ＨＥＶＣでは、インター予測ユニット（ＰＵ）ごとに、それぞれの動きパラメータが送信される。改善されたコーディング効率を実現するために、ブロックマージングプロセスが利用されて、いわゆるマージモードで最良の動きベクトル予測子を選択する。

[0083] マージモードの実施形態の復号プロセスは、次のように記載される。

●予測ユニットにおいて指定された候補リストのインデックス：ｍｅｒｇｅ＿ｉｄｘの構文解析。

●図４によるマージ候補リストの構築。以下の特定の順序で、現在の予測ユニットに対して、空間的なネイバーＡ、Ｂ、Ｃ、Ｄおよび時間的に同じ位置にあるブロックからの候補動きベクトル。

〇ａｖａｉｌａｂｌｅＦｌａｇＡが１に等しい場合、Ａ
〇ａｖａｉｌａｂｌｅＦｌａｇＢが１に等しい場合、Ｂ
〇ａｖａｉｌａｂｌｅＦｌａｇＣｏｌが１に等しい場合、Ｃｏｌ（時間的に同じ位置にあるブロック）
〇ａｖａｉｌａｂｌｅＦｌａｇＣが１に等しい場合、Ｃ
〇ａｖａｉｌａｂｌｅＦｌａｇＤが１に等しい場合、Ｄ
●いくつかのマージング候補が動きベクトルと同じ参照インデックスとを有する場合、マージ候補リスト内で最小の順序を有するマージング候補を除き、マージング候補はリストから除去される。

●マージ候補リスト内で構文解析されたｍｅｒｇｅ＿ｉｄｘを有する候補の選択。

場合によっては、時間的に同じ位置にある候補の参照インデックスおよび動きベクトルは、たとえば、ピクチャ順序カウント（ＰＯＣ）に基づいてスケーリングされる場合がある。さらに、ＨＥＶＣのＳＶＣ拡張または３Ｄビデオコーディング拡張では、基本レイヤまたは基本ビュー内の同じ位置にあるブロックの動きは、マージリストに入れられる場合がある。

動きベクトル予測
[0084] 動きマージモード以外に、動きベクトル予測がＨＥＶＣでサポートされる。動きベクトル予測では、現在のＰＵについて、動きベクトル予測子（ＭＶＰ）リストが構築される。予測子は、空間ネイバーまたは／および時間ネイバーからの動きベクトルであり得る。ＭＶＰリストは、３つまでの候補、空間左ＭＶＰＡと、空間上ＭＶＰＢと、時間ＭＶＰＣｏｌとを含んでいる。３つの候補のうちの１つまたは複数は、たとえば隣接ブロックがイントラであり、存在しないので、利用可能ではない。この場合、ＭＶＰリストはより少ない項目を有し、欠落した候補は利用可能ではないと考えられる。

[0100] 図５に示されたように、左ＭＶＰの検索の場合、２つの隣接ＰＵ、Ａｍ＋１、Ａｍが使用される。同様に、上ＭＶＰの検索の場合、３つまでの隣接ＰＵ、Ｂｎ＋１、Ｂｎ、Ｂ−１が使用される。一般性を失わずに、上ＭＶＰの生成のみが記載される。

[0101] 各空間動きベクトル予測子（ＭＶＰ）候補を導出することに、優先順位ベースの方式が適用される。優先順位ベースの方式は、同じカテゴリ（たとえば、ＡまたはＢ）に属するいくつかのブロックを確認する。動きベクトル（ＭＶ）は、次のようにある特定の順序で確認される。

１）ＭＶを現在確認中のブロックの動きベクトルとする。現在確認中のブロック内のＭＶが、現在のＰＵと（同じ参照インデックスを有する）同じ参照ピクチャを指す場合、ＭＶは同じカテゴリを表すために選択され、（４）に進む、そうでない場合（２）に進む。

２）前のブロックがすでにこのカテゴリの最後のブロックである場合、（３）に進み、そうでない場合、ブロックをそのカテゴリの次のブロックとし、（１）に進む。

３）距離、すなわち現在のピクチャとこのＭＶの参照ピクチャとの間のＰＯＣ距離、および現在のピクチャと現在のＰＵの参照ピクチャとの間のＰＯＣ距離に基づいてＭＶをスケーリングする。

４）終了する。

[0102] 図６は、リストごとに単一の参照ピクチャを有する（リスト０用のピクチャｊおよびリスト１用のピクチャｌ）Ｂスライスの一例を示す。図６では、現在のＰＵにすでにシグナリングされたｒｅｆ＿ｉｄｘに基づいて、最終ＭＶＰ用の参照ピクチャがピクチャｊであると仮定される。現在のリストはリスト０であり、現在のＰＵの参照ピクチャはピクチャｊである。破線の青い矢印は隣接ブロックのリスト０のＭＶを示し、破線の赤い矢印は隣接ブロックのリスト１のＭＶを示す。番号は２つのＭＶの優先順位を示す。リスト０のＭＶが利用可能であるとき、それは空間ＭＶＰ候補として使用される。そうではなく、リスト１のＭＶが利用可能であるとき、それは、ＰＯＣ距離に基づいて実線の赤い矢印のように現在の参照ピクチャにスケーリングされる、次いで、空間ＭＶＰ候補として使用される。

[0103] １つの時間動きベクトル予測子（ｍｖＬ０ＣｏｌまたはｍｖＬ１Ｃｏｌ）が、現在のリストおよび現在の参照ピクチャに応じて選択され、ＭＶＰリストに追加される。ｍｖＬ０ＣｏｌまたはｍｖＬ１Ｃｏｌは、時間的に同じ位置にあるブロックの動きベクトル、および現在のピクチャと現在の参照ピクチャとの間のＰＯＣ差分、および同じ位置にあるピクチャと同じ位置にある時間ブロックによって参照される参照ピクチャとの間のＰＯＣ差分に基づいて導出される。

[0104] ＭＶＰリスト内に複数の候補が存在するとき、どの候補が使用されるべきかを示すためにインデックスがシグナリングされる。マージリストと同様に、ＨＥＶＣのＳＶＣおよび３Ｄビデオコーディングでは、基本レイヤまたは基本ビュー内の同じ位置にあるブロックの動きは、ＭＶＰリストに入れられる場合がある。

スケーラブルビデオコーディング
[0105] 様々な次元におけるスケーラビリティの一例が図７に示される。本例では、スケーラビリティは３つの次元で可能にされる。時間の次元では、７．５Ｈｚ、１５Ｈｚ、または３０Ｈｚを有するフレームレートが、時間スケーラビリティ（Ｔ）によってサポートされ得る。空間スケーラビリティ（Ｓ）がサポートされるとき、ＱＣＩＦ、ＣＩＦ、および４ＣＩＦなどの様々な解像度が可能にされる。特定の空間解像度およびフレームレートごとに、ピクチャ品質を改善するためにＳＮＲ（Ｑ）レイヤが追加され得る。ビデオコンテンツがそのようなスケーラブルな方法で符号化されると、たとえば、クライアントまたは伝送チャネルに依存するアプリケーション要件に従って、実際の配信されたコンテンツに適応するために抽出ツールが使用され得る。図７に示された例では、各立方体は、同じフレームレート（時間レベル）と、空間解像度と、ＳＮＲレイヤとを有するピクチャを含んでいる。それらの立方体（ピクチャ）を任意の次元で追加することによって、より良い表現が実現され得る。２つ、３つまたはさらに多くの可能にされたスケーラビリティが存在するとき、組み合わされたスケーラビリティがサポートされる。

[0106] ＳＶＣの仕様によれば、最も低い空間レイヤおよび品質レイヤを有するピクチャは、Ｈ．２６４／ＡＶＣと互換性があり、最低の時間レベルにあるピクチャは、より高い時間レベルにあるピクチャで強調され得る時間基本レイヤを形成する。Ｈ．２６４／ＡＶＣ互換レイヤに加えて、空間スケーラビリティおよび／または品質スケーラビリティを実現するために、いくつかの空間エンハンスメントレイヤおよび／またはＳＮＲエンハンスメントレイヤが追加され得る。ＳＮＲスケーラビリティは、品質スケーラビリティとも呼ばれる。各々の空間エンハンスメントレイヤまたはＳＮＲエンハンスメントレイヤ自体は時間的にスケーラブルであり得るし、Ｈ．２６４／ＡＶＣ互換レイヤと同じ時間スケーラビリティ構造を有する。１つの空間エンハンスメントレイヤまたはＳＮＲエンハンスメントレイヤの場合、それが依存するより低いレイヤは、その特定の空間エンハンスメントレイヤまたはＳＮＲエンハンスメントレイヤの基本レイヤとも呼ばれる。

[0107] ＳＶＣコーディング構造の一例が図８に示される。最も低い空間レイヤおよび品質レイヤを有するピクチャ（ＱＣＩＦ解像度を有するレイヤ０およびレイヤ１の中のピクチャ）は、Ｈ．２６４／ＡＶＣと互換性がある。それらの間で、最も低い時間レベルのそれらのピクチャは、図８のレイヤ０で示されたように、時間基本レイヤを形成する。この時間基本レイヤ（レイヤ０）は、より高い時間レベル（レイヤ１）のピクチャで強調され得る。Ｈ．２６４／ＡＶＣ互換レイヤに加えて、空間スケーラビリティおよび／または品質スケーラビリティを実現するために、いくつかの空間エンハンスメントレイヤおよび／またはＳＮＲエンハンスメントレイヤが追加され得る。たとえば、エンハンスメントレイヤは、レイヤ２と同じ解像度を有するＣＩＦ表現であり得る。本例では、レイヤ３はＳＮＲエンハンスメントレイヤである。本例で示されたように、各々の空間エンハンスメントレイヤまたはＳＮＲエンハンスメントレイヤ自体は時間的にスケーラブルであり得るし、Ｈ．２６４／ＡＶＣ互換レイヤと同じ時間スケーラビリティ構造を有する。また、エンハンスメントレイヤは、空間解像度とフレームレートの両方を強調することができる。たとえば、レイヤ４は、フレームレートを１５Ｈｚから３０Ｈｚにさらに増大させる４ＣＩＦエンハンスメントレイヤを提供する。

[0108] 図９に示されたように、同じ時間インスタンスでコーディングされたスライスは、ビットストリーム順序で連続し、ＳＶＣのコンテキスト内の１つのアクセスユニットを形成する。次いで、それらのＳＶＣアクセスユニットは復号順序に従い、復号順序は表示順序と異なる可能性があり、たとえば、時間予測関係によって決定される。

Ｈ．２６４／ＡＶＣのスケーラブルな拡張の特徴
[0109] ＳＶＣのいくつかの機能はＨ．２６４／ＡＶＣから引き継がれている。以前のスケーラブルな規格と比較して、最も重要な利点、すなわちレイヤ間予測および単一ループ復号が下記で概説される。

[0110] 低複雑度デコーダを保持するために、ＳＶＣでは単一ループ復号が必須である。単一ループ復号で、各々のサポートされるレイヤは、単一の動き補償ループで復号され得る。これを実現するために、レイヤ間イントラ予測の使用は、エンハンスメントレイヤのマクロブロックのみに可能にされ、そのために同じ位置にある参照レイヤ信号がイントラコーディングされる。より高いレイヤをレイヤ間予測するために使用されるすべてのレイヤが、制約付きイントラ予測を使用してコーディングされることがさらに必要である。

[0111] ＳＶＣは、テクスチャ、残差および動きに基づいて、空間スケーラビリティおよびＳＮＲスケーラビリティのためのレイヤ間予測を導入する。ＳＶＣにおける空間スケーラビリティは、２つのレイヤ間の任意の解像度比に一般化されている。ＳＮＲスケーラビリティは、粗粒度スケーラビリティ（ＣＧＳ）または中粒度スケーラビリティ（ＭＧＳ）によって実現され得る。ＳＶＣでは、２つの空間レイヤまたはＣＧＳレイヤは、（ＮＡＬユニットヘッダ内でｄｅｐｅｎｄｅｎｃｙ＿ｉｄによって示される）異なる依存性レイヤに属するが、２つのＭＧＳレイヤは同じ依存性レイヤ内にあり得る。１つの依存性レイヤは、品質エンハンスメントレイヤに対応する、０からより高い値までのｑｕａｌｉｔｙ＿ｉｄを有する品質レイヤを含む。ＳＶＣでは、レイヤ間の冗長性を低減するために、レイヤ間予測方法が利用される。それらは以下の段落で簡単に紹介される。

[0112] レイヤ間イントラ予測を使用するコーディングモードは、ＳＶＣでは「イントラＢＬ」モードと呼ばれる。単一ループ復号を可能にするために、制約付きイントラモードとしてコーディングされる、基本レイヤ内で同じ位置にあるＭＢを有するＭＢのみが、レイヤ間イントラ予測モードを使用することができる。制約付きイントラモードのＭＢは、隣接するインターコーディングされたＭＢからのいかなるサンプルも参照せずにイントラコーディングされる。

[0113] ＭＢが残差予測を使用するように指示された場合、レイヤ間予測用の基本レイヤ内で同じ位置にあるＭＢは、インターＭＢであるに違いなく、その残差は空間解像度比に従ってアップサンプリングされる場合がある。エンハンスメントレイヤの残差と基本レイヤの残差との間の差分がコーディングされる。すなわち、エンハンスメントレイヤの現在のフレームの復元

は、エンハンスメントレイヤの逆量子化係数ｒ_e、エンハンスメントレイヤからの時間予測Ｐ_e、および基本レイヤの量子化正規化残差係数ｒ_bの合計に等しい。

[0114] 同じ位置にある基本レイヤの動きベクトルは、ＭＢの動きベクトル用の予測子またはエンハンスメントレイヤ内のＭＢパーティションを生成するためにスケーリングされる場合がある。加えて、ＭＢごとに１つのフラグを送る、基本モードと命名された１つのＭＢタイプが存在する。このフラグが真であり、対応する基本レイヤのＭＢがイントラでない場合、動きベクトル、区分化モード、および参照インデックスは、すべて基本レイヤから導出される。

多重仮説動き補償
[0115] 図１０は、暗黙的な多重仮説動き補償（ＩＭＭＣ）を実装するコーダ（たとえば、エンコーダまたはデコーダ）によって実施される、本開示の態様による、ＩＭＭＣのための例示的な方法を示すブロック図１１００である。便宜上、その動き情報がビットストリーム内で明示的にコーディングされていない仮説は、本開示では暗黙的な仮説と呼ばれ、その動き情報がビットストリーム内でコーディングされている仮説は、明示的な仮説と呼ばれる。本開示に記載された技法は、暗黙的な多重仮説動き補償の枠組を提供し、それはデコーダおよび／またはエンコーダによって実装され得る。

[0116] 上記で説明されたように、多重仮説動き補償は、より高いコーディング効率を実現することができるが、ビットストリーム内にコーディングされるべきさらなる動き情報を必要とするコストがかかる。しかしながら、有利なことに、ＩＭＭＣにより、いくつかのさらなる仮説がすでに存在する動き情報から導出されることが可能になる。ＳＶＣおよび３Ｄビデオコーディングの場合、基本レイヤまたは基本ビューの動き情報は、エンハンスメントレイヤまたは依存ビューをコーディングするとき利用可能である。いくつかの実施形態では、ＩＭＭＣは、この基本レイヤ／ビュー情報を使用して、暗黙的な仮説用の動き情報を導出する。加えて、ＩＭＭＣの実施形態は、現在のブロックの空間および時間の隣接ブロックの動き情報を使用して、暗黙的な仮説を見つけることができる。いくつかの実施形態では、ＩＭＭＣエンコーダは、動き候補（たとえば、ビデオユニット）のためのビットストリーム内のフラグ、モードインデックス、または他のインジケータを設定することによって、そのような動き情報が暗黙的な仮説を導出するのに利用可能および／または有用であることをＩＭＭＣデコーダに示すことができる。次いで、ＩＭＭＣデコーダは、ビットストリーム内にすでに存在するデータから暗黙的な仮説を導出することができる。したがって、いくつかの実施形態では、ＩＭＭＣを使用するために、最小限の追加データ（たとえば、フラグまたは他のインジケータ）のみがビットストリームに追加される必要がある。通常、このインジケータデータは、さらなる明示的な仮説用の動き情報（たとえば、動きベクトル）よりも著しく少ない。

[0117] 図１０は、エンハンスメントレイヤ５２０と基本レイヤ５２５とを有するビットストリーム用の３つの連続するピクチャ（１１０５、１１１０、１１１５）用のＢフレームと、Ｐフレームと、Ｉフレームとを示す。いくつかの実施形態では、ビデオ内で、ピクチャ１１０５はピクチャ１１１０の直前にあり、ピクチャ１１１０はピクチャ１１１５の直前にある。エンハンスメントレイヤでは、Ｐフレーム１（ＰＥ１）１１２５、Ｂフレーム２（ＢＥ２）１１３０、およびＩフレーム３（ＩＥ３）１１３５が、それぞれピクチャ１、ピクチャ２、およびピクチャ３に対応する。基本レイヤでは、Ｐフレーム１（ＰＢ１）１１４０、Ｂフレーム２（ＢＢ２）１１４５、およびＩフレーム３（ＩＢ３）１１５０が、それぞれピクチャ１、ピクチャ２、およびピクチャ３に対応する。図１０は、Ｐフレーム、それに続くＢフレーム、それに続くＩフレームであるように３つのピクチャを示すが、他の場合、ＩＭＭＣは、様々な組合せのフレーム、様々な順序のフレーム、および／または様々な数のフレームに適用される場合がある。

[0118] 動作１で、コーダ（たとえば、エンコーダまたはデコーダ）は、基本レイヤ１１２５をすでに処理した後、エンハンスメントレイヤのＢＥ２１１３０の現在のビデオユニット１１５５を符号化または復号している。コーダは、ビットストリームからＢＥ２用の明示的にコーディングされた動き情報（たとえば、動きベクトルまたは動き補償データ）を取得する。そのような動き情報は、コーダのメモリに記憶される場合がある。動き情報により、コーダが、現在のビデオユニット１１５５に一致または対応するフレーム間予測を使用して、時間的に前のフレーム（または別の時間的に隣接するフレーム）内で動き補償されたビデオユニットを識別することが可能になり得る。動き情報を使用して、コーダは、前のフレームＰＥ１１１６０内のビデオユニット１１６０を参照して、明示的な仮説１を、現在のビデオユニット１１５５用の候補一致として識別する。

[0119] 動作２で、コーダは、時間的に次のフレームＩＥ３１１６５（または別の時間的に隣接するフレーム）内のビデオユニット１１６５を参照して、明示的にコーディングされた動き情報を使用して明示的な仮説２を別の候補一致として識別する。

[0120] 動作３で、コーダは、ＢＢ２１１４５の同じ位置にあるブロック１１７０についての、明示的にコーディングされた動き情報を基本レイヤ１１２５から取得する。上記で説明されたように、ＢＥ２１１３０とＢＢ２１１４５は、同じピクチャ（ピクチャ２）のフレームであるが、異なるレイヤ上にある。たとえば、ＢＢ２はより低い解像度のフレームであり得るが、ＢＥ２は同じピクチャのより高い解像度のフレームである。同じ位置にあるビデオユニット１１７０は、現在のビデオユニット１１５５と対応するピクチャの位置にある。基本レイヤ１１２５からの明示的にコーディングされた動き情報は、基本レイヤ内で同じ位置にあるビデオユニット１１７０についての仮説（１１７５、１１８０）を識別する動きベクトルを含むことができる。

[0121] 動作４および動作５で、コーダは、基本レイヤの動き情報を使用して、暗黙的な仮説１１８５と１１９０とを導出する。たとえば、コーダは、同じ位置にある基本レイヤのビデオユニット１１７０についての明示的な仮説によって識別されたビデオユニット１１７５、１１８０を識別することができる。次いで、コーダは、それらの基本レイヤのビデオユニット１１７５、１１８０の同じ位置にあるエンハンスメントレイヤのビデオユニット１１８５、１１９０を決定することができる。いくつかの実施形態では、コーダは、基本レイヤの動き情報をスケーリングまたは場合によっては修正する。たとえば、コーダは、エンハンスメントレイヤ１１２０と基本レイヤ１１２５との間の解像度比に基づいて、基本レイヤの動き情報に倍率を適用することができる。

スケーリングされた基本レイヤの動きの使用
[0122] ＩＭＭＣの一実施形態では、双予測ブロック／ＰＵ（たとえば、現在のビデオユニット１１５５）についての２つの従来の仮説に加えて、２つまでの暗黙的な仮説が可能にされる。この場合、同じ位置にある基本レイヤ／ビューのＰＵのスケーリングされた動きは、暗黙的な仮説の動きとして使用される。Ｖ_e0およびＶ_e1が２つの従来の仮説の動きを表し、スケーリングされた基本レイヤの動きＶ_sb0およびＶ_sb1が２つの暗黙的な仮説の動きを示すとする。一実施形態では、スケーリングされた基本レイヤの動きが導出され得るので、暗黙的な仮説が使用されるどうかを示すフラグ（暗黙的な仮説フラグ）のみがビットストリーム内でコーディングされる必要がある。

[0123] Ｖ_e0、Ｖ_e1、Ｖ_sb0、およびＶ_sb1によって指し示される仮説が、それぞれＰ_e0、Ｐ_e1、Ｐ_sb0、およびＰ_sb1であると仮定する。一般性を失わずに、Ｐ_e0およびＰ_sb0が参照リスト０から、Ｐ_e1およびＰ_sb1が参照リスト１からであるとさらに仮定され得る。４つの仮説がすべて利用可能であるとき、最終予測Ｐは、４つの仮説を平均化すること、たとえば、

によって取得され得るし、ここでｏは０または２であり得る丸めオフセットを示す。

[0124] Ｐ_e0、Ｐ_e1、およびＰ_sb0のみが利用可能であるように、すべての仮説が利用可能ではないとき、最終予測として予測の算術平均、たとえば、

が使用され得るし、ここで丸めオフセットｏは０、１、または２であり得る。

[0125] ３による除算はハードウェアで実装することが困難であり得るので、すべての仮説が利用可能ではないとき、２ステップの平均化が適用され得る。２ステップの平均化は、最初に同じ参照リストからの仮説を平均化することによって、次いで２つのリストの仮説を平均化することによって実施され得る。上記の例の場合、２ステップの平均化での最終予測は、

であり、ここで丸めオフセットｏ₁およびｏは、０または１であり得る。

[0126] 一実施形態では、同じ位置にある基本レイヤの動きに対するスケーリングプロセスは、基本レイヤとエンハンスメントレイヤとの間の解像度比に基づく場合がある。たとえば、解像度比がｒであるとき、スケーリングされた同じ位置にある基本レイヤの動きは、

であり、ここで、Ｖｘ_bおよびＶｙ_bは、それぞれ、同じ位置にある基本レイヤの動きベクトルのｘ成分とｙ成分とを示し、Ｖｘ_sbおよびＶｙ_sbは、関係するスケーリングされたエンハンスメントレイヤの動きを表す。

[0127] その上、両方の動き成分に対する１による移動などの、さらなる既定の移動が動きスケーリングプロセスに適用される場合もある。たとえば、

[0128] 場合によっては、Ｐ_e0およびＰ_sb1のみが利用可能である。すなわち、ＰＵが参照リスト０から単方向予測されることをエンハンスメントレイヤの動きが示し、ＰＵが参照リスト１から単方向予測されることを基本レイヤの動きが示す（または逆の場合もあり得る）。一実施形態では、ＰＵが単方向予測されることをＰＵのシンタックス要素ｉｎｔｅｒ＿ｐｒｅｄ＿ｉｄｃが示す場合があっても、コーダは、単方向予測を使用する代わりに、符号化および／または復号の間双方向予測されるようにＰＵを扱う。

[0129] いくつかの実施形態では、単方向予測されるビデオユニットは、１）単方向予測されるビデオユニットに対して時間的に前の１つもしくは複数のビデオユニット、または２）単方向予測されるビデオユニットに対して時間的に次の１つもしくは複数のビデオユニットのいずれかから予測される。たとえば、第１のビデオユニットは第１のフレーム内にあり得るが、予測で使用されるビデオユニットは、第１のフレームに対して前または次の第２のフレーム内にある。いくつかの実施形態では、双方向予測されるビデオユニットは、双方向予測されるビデオユニットに対して、１）時間的に前の１つまたは複数のビデオユニットと、２）時間的に次の１つまたは複数のビデオユニットの両方から予測される。

[0130] たとえば、コーダは、現在のＰＵを予測するための多重仮説モードを使用するために、現在のＰＵに対して時間的に前のエンハンスメントレイヤのフレームからの予測情報と、現在のＰＵに対して時間的に次の基本レイヤのフレームからの予測情報とを使用することができる。必要な場合、コーダは予測情報（たとえば、動き情報）をスケーリングすることができる。たとえば、現在のＰＵがエンハンスメントレイヤ上にある場合、コーダは、次の基本レイヤのフレームからの（たとえば、対応する位置にある基本レイヤ上の第２のＰＵからの）予測情報をスケーリングし、次の基本レイヤのフレームからのスケーリングされた予測情報、および前のエンハンスメントレイヤのフレームからの予測情報から双方向予測されるようにＰＵを扱うことができる。

[0131] いくつかの実施形態では、コーダは、上述されたように、多重仮説モードをさらに使用して、双方向予測されるように扱われている現在のＰＵを予測する。さらに、上記は、エンハンスメントレイヤのフレームを時間的に前として、基本レイヤのフレームを時間的に次として記載するが、上記の技法は、エンハンスメントレイヤのフレームが時間的に次であり、基本レイヤのフレームが時間的に前である場合にも適用され得る。

[0132] Ｐ_e0およびＰ_sb1のみが利用可能であるいくつかの場合では、予測子Ｐ_e0またはＰ_sb1に対応する動きベクトルのうちの１つがスケーリングされ得るし、エンハンスメントレイヤまたは基本レイヤに関して同じ参照リストを利用可能にし、単方向多重仮説が使用されることを可能にする。上記の例では、Ｐ_sb1に対応する基本レイヤリスト１の動きベクトルがリスト０からの動きベクトルにしてスケーリングされ得るし、多重仮説モードがリスト０用の単方向予測として適用され得る。

[0133] 明示的な仮説１１６０、１１６５と暗黙的な仮説１１８５、１１９０とを識別した後、次いでコーダは、明示的な仮説および暗黙的な仮説において識別されたビデオユニットの値に基づいて、現在のビデオユニット５５５用の値を決定することができる。たとえば、上記で説明されたように、コーダは、それらのビデオユニット（１１６０、１１６５、１１８６、１１９０）の値を平均化して、現在のビデオユニット１１５５用の予測値を決定することができる。ＩＭＭＣプロセスの実施形態は、図１１および図１２でさらに詳細に記載される。

符号化プロセス
[0134] 図１１は、本開示の態様による、符号化ルーチン用の方法の一実施形態を示すフローチャートである。プロセス１２００は、エンコーダ（たとえば、図２に示されたようなエンコーダ）、デコーダ（たとえば、図３に示されたようなデコーダ）、または任意の他の構成要素によって実施される場合がある。プロセス１２００のステップは、図２のビデオエンコーダ２０に関して記載されるが、プロセス１２００は、上述されたように、デコーダなどの他の構成要素によって実施される場合がある。

[0135] 上記で説明されたように、いくつかの実施形態では、４つまでの仮説（２つの暗黙的および２つの従来（明示的））がエンハンスメントレイヤ／ビュー内で可能にされる。２つの暗黙的な仮説は、エンハンスメントレイヤの既定の動き予測子によって示される。たとえば、ＰＵのマージリストまたはＭＶＰリスト内の動き候補が使用され得る。暗黙的な多重仮説モードを示すために、ビットストリーム内でフラグがコーディングされる。このフラグが真であるとき、２つの暗黙的な仮説が動き候補によって決定されるまで、動き候補はマージリストおよびＭＶＰリスト内の動き候補と同じ順序で確認される。一般に、２つの暗黙的な仮説の動きは、２つの従来の仮説の動きと異なる。しかしながら、場合によっては、それらの仮説は部分的または全体的に重複する場合がある。

[0136] 別の実施形態では、マージリストまたはＭＶＰリスト内の動き候補のインデックスは、暗黙的な仮説の動きを示すために、ビットストリーム内でコーディングされる。

[0137] ブロック１２０５で、エンコーダ２０は、エンハンスメントレイヤの第１のフレームの第１のビデオブロック（または他のビデオユニット）用のビデオデータを符号化している。エンコーダは、第１のビデオブロック（たとえば、エンコーダによって処理されている現在のブロック）用の動き補償された仮説１（ＭＣＨ１）を決定する。ＭＣＨ１は、時間的に隣接するフレーム（たとえば、第１のビデオユニットの現在のフレームに対して前のフレームまたは次のフレーム）内のビデオブロックを識別することができる。

[0138] ブロック１２１０で、エンコーダ２０は、第１のビデオブロック用の動き補償された仮説２（ＭＣＨ２）を決定する。ＭＣＨ２は、時間的に隣接するフレーム（たとえば、第１のビデオユニットの現在のフレームに対して前のフレームまたは次のフレーム）内のビデオブロックを識別することができる。通常、ＭＣＨ２はＭＣＨ１とは異なるブロックを指す。たとえば、ＭＣＨ１は現在のフレームに対して前のフレーム内の第２のビデオブロックを指す場合があり、ＭＣＨ２は次のフレーム内の第３のビデオブロックを指す場合がある。

[0139] ブロック１２１５で、エンコーダ２０は、ＭＣＨ１およびＭＣＨ２（すなわち、明示的な仮説）または（たとえば、動きベクトルを使用する）ＭＣＨ１およびＭＣＨ２についての動き情報を、デコーダへの送信用のビットストリーム内に符号化し、デコーダは、復号中にそのような情報を使用して第１のビデオブロック用の値を決定することができる。現在のルーチン１２００はＭＣＨ１とＭＣＨ２とを識別することを記載するが、場合によっては、エンコーダ２０は単一の仮説のみを決定する場合がある。

[0140] ブロック１２２０で、エンコーダ２０は、現在のフレームに関連付けられた参照レイヤのフレーム（たとえば、基本レイヤ）から動き情報を取得する。たとえば、そのようなフレームは、エンハンスメントレイヤ内の現在のフレームと同じピクチャ用の基本レイヤ内の対応するフレームであり得る。一実施形態では、エンコーダ２０は、エンハンスメントレイヤのフレーム上の第１のビデオブロックに対応する参照レイヤのフレーム上の同じ位置にあるビデオブロックについての動き情報を取得する。

[0141] ブロック１２２５で、エンコーダ２０は、参照レイヤの動き情報をスケーリングする。上述されたように、エンコーダは、参照レイヤの動き情報をスケーリングまたは場合によっては修正することができる。たとえば、コーダは、エンハンスメントレイヤと参照レイヤとの間の解像度比に基づいて、参照レイヤの動き情報に倍率を適用することができる。

[0142] ブロック１２３０で、エンコーダ２０は、スケーリングされた参照レイヤの動き情報からＭＣＨ３とＭＣＨ４とを決定する。図１０で説明されたように、レイヤ情報は、同じ位置にある参照ビデオブロックについての参照レイヤ内の仮説に基づいて、ＭＣＨ３とＭＣＨ４とを識別するために使用され得る。現在のルーチン１２００はＭＣＨ３とＭＣＨ４とを識別することを記載するが、場合によっては、エンコーダ２０は単一の仮説のみを決定する場合がある。

[0143] ブロック１２３５で、エンコーダ２０は、第１のビデオブロックを復号する際にＭＣＨ３とＭＣＨ４と（すなわち、暗黙的な仮説）を使用するように、デコーダに指示するかどうかを判定する。場合によっては、エンコーダ２０は、暗黙的な仮説を使用することによってさらなるコーディング効率は取得されないと判断する場合がある。たとえば、暗黙的な仮説を使用することは、ひずみを低減しないか、または（たとえば、ＭＣＨ３およびＭＣＨ４がＭＣＨ１およびＭＣＨ２と同じ値を有する場合）より効率的な圧縮を可能にしない場合がある。

[0144] エンコーダ２０は、フラグまたは他のインジケータを使用して、デコーダが暗黙的な仮説を計算すべきかどうかを示すことができる。暗黙的な仮説が有益であるとエンコーダが判断した場合、ルーチンはブロック１２４０に進む。暗黙的な仮説が有益ではないとエンコーダが判断した場合、ルーチン１２００は終了することができる。いくつかの実施形態では、エンコーダ２０は、（たとえば、デコーダがデフォルトで暗黙的な仮説を使用するように設定されている場合）ルーチンを終了する前に、ＩＭＭＣを実施しないようにデコーダに指示するフラグを符号化する必要があり得る。

[0145] ブロック１２４０で、エンコーダ２０は、暗黙的な多重仮説動き補償（ＩＭＭＣ）用のフラグをビットストリーム内に符号化する。デコーダがビットストリームを受信したとき、デコーダは、第１のビデオブロック用のＩＭＭＣフラグを確認して、暗黙的な仮説を計算すべきか、または明示的な仮説のみを使用すべきかを判定することができる。いくつかの実施形態では、エンコーダ２０は、（たとえば、デコーダがデフォルトで暗黙的な仮説を使用するように設定されている場合）ルーチンを終了する前に、ＩＭＭＣを実施するフラグを符号化する必要がない場合がある。

[0146] デコーダが暗黙的な仮説を計算すべきでないときをシグナリングすることによって、計算リソースはデコーダによって浪費されない。有利なことに、これにより、暗黙的な仮説を使用すべきときをデコーダに伝えるためにそのようなインジケータを使用しない実施形態と比較して、ビットストリームの復号速度の向上が可能になる。次いで、ルーチン１２００は終了することができる。

多重仮説モードのシグナリングに関するさらなる詳細
[0147] 提案された多重仮説モードは、シーケンスレベルまたはフレームレベルで有効化／無効化され得る。たとえば、モードを示すために、シーケンスパラメータセット（ＳＰＳ）またはピクチャパラメータセット（ＰＰＳ）内のフラグが使用され得る。

[0148] 場合によっては、小さいビデオユニットに対して多重仮説動き補償を実施する際は、さらなるコーディング効率が少ししか得られない。したがって、いくつかの実施形態では、提案された多重仮説モードは、８×８よりも大きくないＣＵ／ＰＵなどの小さいサイズを有するＣＵ／ＰＵに対して無効化される場合がある。これを示すパラメータは、ＳＰＳ、ＰＰＳ、およびスライスヘッダなどの、スライスまたはより高いレベルでコーディングされる場合がある。

[0149] 代替として、提案された多重仮説モードは、ゼロでない重み係数を有するＧＲＰモードでコーディングされたＣＵ／ＰＵなどの、特定のモードでコーディングされたＣＵ／ＰＵ、または非スキップモードまたは非マージモードとしてコーディングされたインターＣＵ／ＰＵに対して無効化される場合がある。

[0150] 一実施形態では、暗黙的な仮説を示すために、スケーリングされた基本レイヤの動きのみが使用される場合がある。この場合、暗黙的な仮説が使用されるか否かを示すために、インターＰＵレベルでフラグがコーディングされる。このフラグは、単一のビットでコーディングされるか、またはＣＡＢＡＣでコーディングされる場合がある。ＣＡＢＡＣを使用するとき、左のＰＵおよび上のＰＵの暗黙的な仮説モードフラグなどの、空間的および時間的に隣接するコーディングされたＰＵの情報は、現在のＰＵの暗黙的な仮説モードのコンテキストを決定するために使用され得る。その上、現在のＰＵのマージフラグなどの、現在のＰＵの以前にコーディングされた情報も、コンテキストとして使用され得る。

[0151] 別の実施形態では、マージリスト内の動き候補などの、暗黙的な仮説を見つけるいくつかの動き候補が存在する。この場合、動き候補のインデックスはビットストリーム内でコーディングされる必要がある。ＣＡＢＡＣを使用してインデックスをコーディングするとき、符号なし整数指数ゴロムコード、切頭符号なし整数指数ゴロムコード、単項コード、または切頭単項コード［８］が、インデックスを２値化するために使用され得る。空間的および／または時間的に隣接するＣＵまたはＰＵの情報は、ＣＡＢＡＣコーディング用のコンテキストとして使用され得る。その上、マージフラグ、ＰＵパーティション、またはＰＵサイズなどの現在のＰＵの情報も、コンテキストとして使用され得る。

[0152] 上記の実施形態では、動き候補の数があるしきい値を上回るとき、候補を削るためにテンプレート照合が使用され得る。次いで、インデックスがシグナリングされる。候補の数が２つ未満に削減されたとき、ビットストリーム内のフラグまたはインデックスを明示的にシグナリングする必要はない。

[0153] 一実施形態では、多重仮説モードがいくつかの予測モードに適用され得る。この場合、フラグは、それらのいくつかのモードについてのみコーディングされ得る。多重仮説モードは、第１のセットの予測モードに適用されるが、第２のセットの予測モードに適用されない場合がある。たとえば、多重仮説は、マージモードのみに適用され、高度動きベクトル予測（ＡＭＶＰ）には適用されない可能性がある。この例では、多重仮説フラグは、マージモードを使用するときのみコーディングされ、ＡＭＶＰを使用するときコーディングされない可能性がある。

[0154] 場合によっては、多重仮説フラグおよび多重仮説モードインデックスは、以前にコーディングされた情報に基づいて導出される場合がある。一実施形態では、マージおよびスキップとは異なりインターコーディングされたＰＵの場合、多重仮説フラグまたは多重仮説インデックスは常に０に設定され、ビットストリーム内でコーディングされる必要がない。

[0155] 別の実施形態では、多重仮説モードフラグは、ビット空間をさらに節約するために条件付きでコーディングされる場合もある。最初に、暗黙的な仮説の利用可能性は次のように定義される：基本レイヤ内の同じ位置にあるＰＵがイントラコーディングされ、したがって暗黙的な仮説を見つけるために基本の動きが使用され得ないなどの、既定のルールに従って暗黙的な仮説の動きが導出され得ないとき、または導出された動きが現在のＰＵの１つの従来の仮説の動きと同じであるときのいずれかで、暗黙的な仮説はＰＵのために利用可能ではない。そのような定義を使用して、エンコーダは、暗黙的な多重仮説モードフラグを条件付きでコーディングすることができる。たとえば、ＰＵの１つまたは複数の多重仮説が利用可能であるときのみ、エンコーダはフラグをコーディングする。そうでない場合、フラグはコーディングされず、ゼロに設定される。暗黙的な仮説の利用可能性は次のようにも定義され得る：ＰＵがＢスライス内にあり、単方向予測される場合、ＰＵの暗黙的な仮説は利用可能ではないとマークされる。暗黙的な仮説の利用可能性は次のようにも定義され得る：ＰＵのマージフラグが真であり、そのマージインデックスがゼロでないとき、ＰＵの暗黙的な仮説は利用可能であるとマークされる。そうでない場合、暗黙的な仮説は利用可能ではないとマークされる。

[0156] 図１２は、本開示の態様による、復号ルーチン用の方法の一実施形態を示すフローチャートである。プロセス１３００は、エンコーダ（たとえば、図２に示されたようなエンコーダ）、デコーダ（たとえば、図３に示されたようなデコーダ）、または任意の他の構成要素によって実施される場合がある。プロセス１３００のステップは、図３のビデオデコーダ３０に関して記載されるが、プロセス１３００は、上述されたように、エンコーダなどの他の構成要素によって実施される場合がある。

[0157] ブロック１３０５で、デコーダ３０は、エンハンスメントレイヤの第１のフレームの第１のビデオブロック（または他のビデオユニット）用のビデオデータを復号している。デコーダは、ビットストリームから（または情報を記憶した後メモリを介して）第１のビデオブロックについての明示的な動き情報を取得し、第１のビデオブロック（たとえば、エンコーダによって処理されている現在のブロック）用の動き補償された仮説１（ＭＣＨ１）を決定する。ＭＣＨ１は、時間的に隣接するフレーム（たとえば、第１のビデオユニットの現在のフレームに対して前または次のフレーム）内のビデオブロックを識別することができる。

[0158] いくつかの実施形態では、デコーダ３０は、第１のビデオブロック用の動き補償された仮説２（ＭＣＨ２）も決定する。ＭＣＨ２は、時間的に隣接するフレーム（たとえば、第１のビデオユニットの現在のフレームに対して前または次のフレーム）内のビデオブロックを識別することができる。通常、ＭＣＨ２はＭＣＨ１とは異なるブロックを指す。たとえば、ＭＣＨ１は現在のフレームに対して前のフレーム内の第２のビデオブロックを指す場合があり、ＭＣＨ２は次のフレーム内の第３のビデオブロックを指す場合がある。

[0159] ブロック１３１０で、デコーダ３０は、たとえば、ＩＭＭＣフラグに基づいて、第１のビデオブロックを復号する際に暗黙的な仮説を計算すべきかどうかを判定する。場合によっては、エンコーダ２０は、暗黙的な仮説を使用することによってさらなるコーディング効率は取得されない（たとえば、画像のひずみを低減しないか、または圧縮を改善しない）と判断しており、したがってデコーダが暗黙的な仮説を使用するように指示されるようなフラグを設定している／設定していない場合がある。デコーダが暗黙的な仮説を使用するように指示された場合、ルーチンはブロック１３１５に進む。デコーダが暗黙的な仮説を使用しないように指示された場合、ルーチンはブロック１３３５に進む。

[0160] ブロック１３１５で、デコーダ３０は、現在のフレームに関連付けられた参照レイヤのフレーム（たとえば、基本レイヤ）から動き情報を取得する。たとえば、そのようなフレームは、エンハンスメントレイヤ内の現在のフレームと同じピクチャ用の基本レイヤ内の対応するフレームであり得る。一実施形態では、デコーダは、エンハンスメントレイヤのフレーム上の第１のビデオブロックに対応する参照レイヤのフレーム上の同じ位置にあるビデオブロックについての動き情報を取得する。

[0161] ブロック１３２０で、デコーダ３０は、参照レイヤの動き情報をスケーリングする。上述されたように、デコーダは、参照レイヤの動き情報をスケーリングまたは場合によっては修正することができる。たとえば、コーダは、エンハンスメントレイヤと参照レイヤとの間の解像度比に基づいて、参照レイヤの動き情報に倍率を適用することができる。

[0162] ブロック１３２５で、デコーダ３０は、スケーリングされた参照レイヤの動き情報からＭＣＨ３とＭＣＨ４とを決定する。図１０で説明されたように、レイヤ情報は、同じ位置にある参照ビデオブロック用の参照レイヤ内の仮説に基づいて、ＭＣＨ３とＭＣＨ４とを識別するために使用され得る。現在のルーチン１２００はＭＣＨ３とＭＣＨ４とを識別することを記載するが、場合によっては、エンコーダ２０は単一の仮説のみを決定する場合がある。

[0163] ブロック１３３０で、デコーダ３０は、第１のビデオブロック用の画像データまたは画像値を決定する。図１０に関して上述されたように、デコーダは、ＭＣＨ１、ＭＣＨ２、ＭＣＨ３、およびＭＣＨ４の値の平均（たとえば、仮説によって参照されたビデオブロックの値）を計算することができる。場合によっては、丸めオフセットが仮説に追加される。次いで、ルーチン１３００は終了することができる。

[0164] ブロック１３１０に戻って、暗黙的な仮説が計算されるべきでないことをＩＭＭＣフラグが示した場合、ルーチン１３００はブロック１３３５に進むことができる。ブロック１３３５で、デコーダ３０は、暗黙的な仮説を計算せずに、明示的な仮説に基づいて、第１のビデオブロック用の画像データまたは画像値を決定する。たとえば、デコーダは、ＭＣＨ１の値とＭＣＨ２の値の平均を計算することができる。次いで、ルーチン１３００は終了することができる。

[0165] 上記の開示は特定の実施形態を記載しているが、多くの変形形態が可能である。たとえば、上述されたように、上記の技法は３Ｄビデオコーディングに適用され得る。３Ｄビデオのいくつかの実施形態では、参照レイヤ（たとえば、基本レイヤ）は、ビデオの第１のビューを表示するのに十分なビデオ情報を含み、エンハンスメントレイヤは、参照レイヤに比べてさらなるビデオ情報を含み、その結果、参照レイヤおよびエンハンスメントレイヤは一緒に、ビデオの第２のビューを表示するのに十分な情報を含む。これらの２つのビューは、立体的な画像を生成するために使用され得る。上記で説明されたように、本開示の態様に従って、エンハンスメントレイヤ内でビデオユニットを符号化または復号するとき、参照レイヤからの動き情報は、さらなる暗黙的な仮説を識別するために使用され得る。これにより、３Ｄビデオのビットストリームについてのより大きいコーディング効率が実現され得る。

[0166] 例によっては、本明細書で説明された技法のうちいずれかの、いくつかの行為またはイベントは、異なる順番で実行される可能性があり、追加され、統合され、または完全に除外され得る（たとえば、すべての説明された行為またはイベントが、本技法の実施のために必要であるとは限らない）ことを認識されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、同時に、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通じて実行され得る。

[0167] １つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されてよく、あるいは、コンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する、任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。

[0168] 限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体を備え得る。同様に、いかなる接続も適切にコンピュータ可読媒体と称される。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。

[0169] 命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明される技法の実装に好適な他の構造のいずれかを指す。加えて、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内で与えられてよく、あるいは複合コーデックに組み込まれてよい。また、本技法は、１つまたは複数の回路または論理要素中で完全に実装され得る。

[0170] 本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネント、モジュール、またはユニットが説明されたが、それらのコンポーネント、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上で説明された１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられてよく、または相互動作ハードウェアユニットの集合によって与えられてよい。

[0171] 様々な例が説明されてきた。これらおよび他の例は以下の特許請求の範囲内に入る。

Claims

ビデオ情報を復号する方法であって、
第１のレイヤ内の第１のビデオユニットを識別することと、
第２のレイヤ内の第２のビデオユニットを識別することと、
前記第１のビデオユニット用の複数の候補動きベクトルを備える候補リストを決定することと、ここにおいて、前記候補リストは、前記第２のビデオユニットに関連付けられた既定の動きベクトルから決定された少なくとも１つの導出された候補を含む、
前記候補リスト内の選択された候補の位置を識別するシグナリングされたインデックスに基づいて、前記候補動きベクトルの間で複数の候補を選択することと、
前記第１のビデオユニットについての予測を決定することと、ここにおいて、前記予測は予測仮説の組合せに対応し、ここにおいて前記予測仮説は前記候補リスト内の前記選択された候補に対応する、
を備える、方法。
前記第１のビデオユニットおよび前記第２のビデオユニットが、各々フレーム、スライス、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ）、ブロック、またはピクセルの領域を備える、請求項１に記載の方法。
前記第１のレイヤがエンハンスメントレイヤであり、前記第２のレイヤが参照レイヤであるか、または前記第１のレイヤが３Ｄビデオの依存ビューであり、前記第２のレイヤが３Ｄビデオの基本ビューである、請求項１に記載の方法。
前記第２のレイヤ内の前記第２のビデオユニットが、前記第１のレイヤ内の前記第１のビデオユニットと空間的に同じ位置にある、請求項１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに空間的に隣接する、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに時間的に隣接し、前記第１のビデオユニットと空間的に同じ位置にある、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に次の参照ビデオユニットに関して定義され、前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に前の参照ビデオユニットに関して定義される、請求項１に記載の方法。
前記導出された動きベクトルが、前記既定の動きベクトルをスケーリングすることによって決定され、前記スケーリングが、前記第１のレイヤと前記第２のレイヤとの間の、空間解像度における差分およびフレームレートにおける差分のうちの少なくとも１つに基づく、請求項１に記載の方法。
前記第１のビデオユニットについての前記予測が、前記選択された候補に対応する前記予測仮説を平均化し、０、１、または２のラウンディングオフセットを適用することによって少なくとも部分的に決定される、請求項１に記載の方法。
前記導出された動きベクトルが、前記第１のレイヤに関連付けられた、シグナリングされたインジケータに応答して決定される、請求項１に記載の方法。
ビデオ情報を符号化する方法であって、
第１のレイヤ内の第１のビデオユニットを識別することと、
第２のレイヤ内の第２のビデオユニットを識別することと、
前記第１のビデオユニット用の複数の候補動きベクトルを備える候補リストを決定することと、ここにおいて、前記候補リストは、前記第２のビデオユニットに関連付けられた既定の動きベクトルから決定された少なくとも１つの導出された候補を含む、
前記候補動きベクトルの間で複数の候補を選択することと、
前記第１のビデオユニットについての予測を決定することと、ここにおいて、前記予測は予測仮説の組合せに対応し、ここにおいて前記予測仮説は前記候補リスト内の前記選択された候補に対応する、
前記候補リスト内の前記選択された候補の位置を識別するインデックスをシグナリングすることと
を備える、方法。
前記第１のビデオユニットおよび前記第２のビデオユニットが、各々フレーム、スライス、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ）、ブロック、またはピクセルの領域を備える、請求項１１に記載の方法。
前記第１のレイヤがエンハンスメントレイヤであり、前記第２のレイヤが参照レイヤであるか、または前記第１のレイヤが３Ｄビデオの依存ビューであり、前記第２のレイヤが３Ｄビデオの基本ビューである、請求項１１に記載の方法。
前記第２のレイヤ内の前記第２のビデオユニットが、前記第１のレイヤ内の前記第１のビデオユニットと空間的に同じ位置にある、請求項１１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに空間的に隣接する、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項１１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに時間的に隣接し、前記第１のビデオユニットと空間的に同じ位置にある、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項１１に記載の方法。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に次の参照ビデオユニットに関して定義され、前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に前の参照ビデオユニットに関して定義される、請求項１１に記載の方法。
前記導出された動きベクトルが、前記既定の動きベクトルをスケーリングすることによって決定され、前記スケーリングが、前記第１のレイヤと前記第２のレイヤとの間の、空間解像度における差分およびフレームレートにおける差分のうちの少なくとも１つに基づく、請求項１１に記載の方法。
前記第１のビデオユニットについての前記予測が、前記選択された候補に対応する前記予測仮説を平均化し、０、１、または２のラウンディングオフセットを適用することによって少なくとも部分的に決定される、請求項１１に記載の方法。
前記第２のレイヤから導出された動きベクトルが前記第１のレイヤ用の候補リストに含まれることを示すインジケータをシグナリングすることをさらに備える、請求項１１に記載の方法。
ビデオ情報をコーディングするための装置であって、
第１のレイヤおよび対応する第２のレイヤに関連付けられたビデオ情報を記憶するように構成されたメモリユニットであって、前記ビデオ情報が、少なくとも前記第１のレイヤおよび第２のレイヤについての動き予測情報を含む、メモリユニットと、
前記メモリユニットと通信しているプロセッサであって、
前記第１のレイヤ内の第１のビデオユニットを識別することと、
前記第２のレイヤ内の第２のビデオユニットを識別することと、
少なくとも１つが前記第２のビデオユニットに関連付けられた既定の動きベクトルから導出された、前記第１のビデオユニット用の複数の候補動きベクトルを決定することと、
前記候補動きベクトルの間で複数の候補を選択することと、ここにおいて、前記選択された候補は、前記第１のビデオユニットについての複数の予測仮説に対応する、
前記第１のビデオユニットについての予測を決定することと、ここにおいて、前記予測は前記予測仮説の組合せに対応する、
を行うように構成された、プロセッサと
を備える、装置。
前記プロセッサが、候補リスト内の前記選択された候補の位置を識別するインデックスをシグナリングするようにさらに構成された、請求項２１に記載の装置。
前記プロセッサが、候補リスト内の前記選択された候補の位置を識別するシグナリングされたインデックスに基づいて、前記候補動きベクトルの間で前記複数の選択された候補を選択するようにさらに構成された、請求項２１に記載の装置。
前記第１のビデオユニットおよび前記第２のビデオユニットが、各々フレーム、スライス、コーディングユニット（ＣＵ）、予測ユニット（ＰＵ）、ブロック、またはピクセルの領域を備える、請求項２１に記載の装置。
前記第１のレイヤがエンハンスメントレイヤであり、前記第２のレイヤが参照レイヤであるか、または前記第１のレイヤが３Ｄビデオの依存ビューであり、前記第２のレイヤが３Ｄビデオの基本ビューである、請求項２１に記載の装置。
前記第２のレイヤ内の前記第２のビデオユニットが、前記第１のレイヤ内の前記第１のビデオユニットと空間的に同じ位置にある、請求項２１に記載の装置。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに空間的に隣接する、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項２１に記載の装置。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに時間的に隣接し、前記第１のビデオユニットと空間的に同じ位置にある、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項２１に記載の装置。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に次の参照ビデオユニットに関して定義され、前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に前の参照ビデオユニットに関して定義される、請求項２１に記載の装置。
前記既定の動きベクトルから導出された少なくとも１つの候補動きベクトルが、前記既定の動きベクトルをスケーリングすることによって決定され、前記スケーリングが、前記第１のレイヤと前記第２のレイヤとの間の、空間解像度における差分およびフレームレートにおける差分のうちの少なくとも１つに基づく、請求項２１に記載の装置。
前記第１のビデオユニットについての前記予測が、前記選択された候補に対応する前記予測仮説を平均化し、０、１、または２のラウンディングオフセットを適用することによって少なくとも部分的に決定される、請求項２１に記載の装置。
第１のレイヤ内の第１のビデオユニットを識別するための手段と、
第２のレイヤ内の第２のビデオユニットを識別するための手段と、
前記第１のビデオユニット用の複数の候補動きベクトルを決定するための手段と、ここにおいて前記候補動きベクトルのうちの少なくとも１つが、前記第２のビデオユニットに関連付けられた既定の動きベクトルから導出される、
前記候補動きベクトルの間で複数の候補を選択するための手段と、
前記第１のビデオユニットについての予測を決定するための手段と、ここにおいて前記予測が予測仮説の組合せに対応し、ここにおいて前記予測仮説が前記選択された候補に対応する、
を備える、ビデオコーディングデバイス。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに空間的に隣接する、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項３２に記載のビデオコーディングデバイス。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに時間的に隣接し、前記第１のビデオユニットと空間的に同じ位置にある、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項３２に記載のビデオコーディングデバイス。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に次の参照ビデオユニットに関して定義され、前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に前の参照ビデオユニットに関して定義される、請求項３２に記載のビデオコーディングデバイス。
前記既定の動きベクトルから導出された少なくとも１つの候補動きベクトルが、前記既定の動きベクトルをスケーリングすることによって決定され、前記スケーリングが、前記第１のレイヤと前記第２のレイヤとの間の、空間解像度における差分およびフレームレートにおける差分のうちの少なくとも１つに基づく、請求項３２に記載のビデオコーディングデバイス。
前記第１のビデオユニットについての前記予測が、前記選択された候補に対応する前記予測仮説を平均化し、０、１、または２のラウンディングオフセットを適用することによって少なくとも部分的に決定される、請求項３２に記載のビデオコーディングデバイス。
コンピュータストレージを有するコンピュータシステムによって実行されたとき、
第１のレイヤ内の第１のビデオユニットを識別することと、
第２のレイヤ内の第２のビデオユニットを識別することと、
前記第１のビデオユニット用の複数の候補動きベクトルを決定することと、ここにおいて、前記候補動きベクトルのうちの少なくとも１つは、前記第２のビデオユニットに関連付けられた既定の動きベクトルから導出される、
前記候補動きベクトルの間で複数の候補を選択することと、
前記第１のビデオユニットについての予測を決定することと、ここにおいて、前記予測は予測仮説の組合せに対応し、ここにおいて前記予測仮説は前記選択された候補に対応する、
を前記コンピュータシステムに行わせる命令を記憶した、非一時的コンピュータストレージ。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに空間的に隣接する、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項３８に記載の非一時的コンピュータストレージ。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに時間的に隣接し、前記第１のビデオユニットと空間的に同じ位置にある、前記第１のレイヤ内のビデオユニットに関連付けられた動きベクトルである、請求項３８に記載の非一時的コンピュータストレージ。
前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に次の参照ビデオユニットに関して定義され、前記候補動きベクトルのうちの少なくとも１つが、前記第１のビデオユニットに対して時間的に前の参照ビデオユニットに関して定義される、請求項３８に記載の非一時的コンピュータストレージ。
前記既定の動きベクトルから導出された少なくとも１つの候補動きベクトルが、前記既定の動きベクトルをスケーリングすることによって決定され、前記スケーリングが、前記第１のレイヤと前記第２のレイヤとの間の、空間解像度における差分およびフレームレートにおける差分のうちの少なくとも１つに基づく、請求項３８に記載の非一時的コンピュータストレージ。
前記第１のビデオユニットについての前記予測が、前記選択された候補に対応する前記予測仮説を平均化し、０、１、または２のラウンディングオフセットを適用することによって少なくとも部分的に決定される、請求項３８に記載の非一時的コンピュータストレージ。