JP6199371B2 - ビデオ・コーディングのためのインタ・レイヤ・テクスチャ予測 - Google Patents

Description

関連出願に対する相互参照

本願は、２０１２年３月２２日に出願された米国仮出願６１／６１４，４５０号、２０１２年９月２８日に出願された米国仮出願６１／７０７，６２０号、および、２０１３年３月１５日に出願された米国仮出願１３／８３８，２７０号に対する優先権を主張する。これらが開示するすべてについて、これらコンテンツの全体が、本明細書において参照によって組み込まれており、本明細書を構成している。

本開示は、一般に、ビデオ・コーディングおよび圧縮の分野に関し、さらに詳しくは、インタ・レイヤ・テクスチャ予測のためのスケーラブル・ビデオ・コーディング（ＳＶＣ）および技法に関する。

デジタル・ビデオ機能は、デジタル・テレビ、デジタル・ダイレクト・ブロードキャスト・システム、無線ブロードキャスト・システム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップ・コンピュータ、タブレット・コンピュータ、ｅブック・リーダ、デジタル・カメラ、デジタル記録デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーム・デバイス、ビデオ・ゲーム・コンソール、セルラまたは衛星ラジオ電話、いわゆる「スマート・フォン」、ビデオ・テレビ会議デバイス、ビデオ・ストリーミング・デバイス等を含む広範囲のビデオに組み込まれうる。デジタル・ビデオ・デバイスは、例えば、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、パート１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）、現在開発中の高効率ビデオ・コーディング（ＨＥＶＣ）規格、およびこれら規格の拡張版によって定義された規格において記載されているようなビデオ圧縮技法を実施する。ビデオ・デバイスは、このようなビデオ圧縮技法を実施することによって、デジタル・ビデオ情報をより効率的に送信、受信、エンコード、デコード、および／または、格納しうる。

ビデオ圧縮技法は、ビデオ・シーケンスに固有の冗長性を低減または除去するために、空間（イントラ・ピクチャ）予測、および／または、時間（インタ・ピクチャ）予測を行なう。ブロック・ベースのビデオ・コーディングのために、ビデオ・スライス（すなわち、ビデオ・フレーム、またはビデオ・フレームの一部分）が、ツリーブロック、コーディング・ユニット（ＣＵ）、および／または、コーディング・ノードとも称される複数のビデオ・ブロックへ分割されうる。ピクチャのイントラ・コード（Ｉ）スライスにおけるビデオ・ブロックは、同じピクチャ内の近隣ブロックにおける基準サンプルに対する空間予測を用いてエンコードされる。ピクチャのインタ・コード（ＰまたはＢ）スライスにおけるビデオ・ブロックは、同じピクチャ内の近隣ブロックにおける基準サンプルに対する空間予測を用いるか、別の基準ピクチャにおける基準サンプルに対する時間予測を用いうる。ピクチャは、フレームと称され、基準ピクチャは、基準フレームと称されうる。

空間予測または時間予測の結果、ブロックの予測ブロックがコーディングされるようになる。残余データは、コーディングされるべきオリジナルのブロックと、予測ブロックとの間のピクセル差分を表す。インタ・コード・ブロックは、予測ブロックを形成する基準サンプルのブロックを示す動きベクトルと、コーディングされたブロックと予測ブロックとの差分を示す残余データと、にしたがってエンコードされる。イントラ・コード・ブロックは、イントラ・コーディング・モードと残余データとにしたがってエンコードされる。さらなる圧縮のため、残余データは、ピクセル領域から変換領域へ変換され、残余変換係数となる。残余変換係数は、その後、量子化されうる。最初に２次元アレイで配列された量子化された変換係数は、変換係数の一次元ベクトルを生成するためにスキャンされ、より更なる圧縮を達成するために、エントロピ・コーディングが適用されうる。

本開示のシステム、方法、およびデバイスはおのおの、いくつかの革新的な態様を有しており、そのうちのどの１つも、単独で、本明細書に開示された所望の特性のための役割を負うものではない。

本開示の１つの態様は、ビデオ情報をコーディングするための装置を提供する。この装置は、ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を格納するように構成されたメモリを含む。この装置はさらに、メモリと通信するプロセッサを含んでいる。このプロセッサは、ビデオ情報に少なくとも部分的に基づいて、ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、エンハンスメント・レイヤにおけるビデオ・ユニットに関連付けられた第２の重みとを決定するように構成されている。プロセッサはさらに、第１および第２の重みに少なくとも部分的に基づいて、エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングするように構成される。

本開示の別の態様は、ビデオ情報をコーディングする方法を提供する。この方法は、ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得することを含む。この方法はまた、ビデオ情報に少なくとも部分的に基づいて、ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、エンハンスメント・レイヤにおけるビデオ・ユニットに関連付けられた第２の重みとを決定することを含む。この方法はさらに、第１および第２の重みに少なくとも部分的に基づいて、エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングすることを含む。

本開示のさらに別の態様は、装置のプロセッサによって実行可能な命令群を含むコンピュータ読取可能な媒体を提供する。これら命令群は、装置に対して、ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得させうる。これら命令群はまた、装置に対して、ビデオ情報に少なくとも部分的に基づいて、ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、エンハンスメント・レイヤにおけるビデオ・ユニットに関連付けられた第２の重みとを決定させうる。これら命令群はさらに、装置に対して、第１および第２の重みに少なくとも部分的に基づいて、エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングさせうる。

本開示のさらなる態様は、ビデオ情報をコーディングするための装置を提供する。この装置は、ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得する手段を含む。この装置はまた、ビデオ情報に少なくとも部分的に基づいて、ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、エンハンスメント・レイヤにおけるビデオ・ユニットに関連付けられた第２の重みとを決定する手段を含む。この装置はさらに、第１および第２の重みに少なくとも部分的に基づいて、エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングする手段を含む。

図１は、本開示に記載された態様にしたがう技法を利用しうる例示的なビデオ・エンコーディングおよびデコード・システムのブロック図である。 図２は、本開示に記載されたコーディング技法を実施するための例示的な処理のフロー図である。 図３は、本開示に記載されたコーディング技法を実施しうるビデオ・エンコーダの例を例示するブロック図である。 図４は、本開示に記載されたコーディング技法を実施しうるビデオ・デコーダの例を例示するブロック図である。 図５は、例示的なイントラ予測モードの図解である。 図６は、予測処理の例示的な表現である。 図７は、コーディングされるべき例示的な現在のエンハンスメント・ブロックの図解であり、ここでは、現在のエンハンスメント・ブロックのいくつかのピクセルが、近隣ブロックの境界の比較的に近くにあるものとして識別される。 図８Ａは、コーディングされるべき例示的な現在のエンハンスメント・ブロックの図解であり、ここでは、現在のエンハンスメント・ブロックのいくつかのピクセルが、予測方向に基づいて、近隣ブロックの境界に比較的近くにあるものとして識別されている。 図８Ｂは、コーディングされるべき例示的な現在のエンハンスメント・ブロックの図解であり、ここでは、現在のエンハンスメント・ブロックのいくつかのピクセルが、予測方向に基づいて、近隣ブロックの境界に比較的近くにあるものとして識別されている。 図９は、コーディングされるべき例示的な現在のエンハンスメント・ブロックの図解であり、ここでは、重み付けパラメータが、予測方向に基づいて変動する。 図１０は、重み付けられたベース・レイヤ予測子およびエンハンスメント・レイヤ予測子を用いてビデオをコーディングするための例示的な方法のフロー図である。 図１１は、ピクセル位置に基づいて、ベース・レイヤ予測子とエンハンスメント・レイヤ予測子との重み付けを行い、これらを結合するための例示的な方法のフロー図である。 図１２は、ベース・レイヤおよびエンハンスメント・レイヤの特定の特性に基づいて、ベース・レイヤ予測子とエンハンスメント・レイヤ予測子との重み付けを行い、これらを結合するための例示的な方法のフロー図である。

一般的に説明されるように、本開示は、スケーラブル・ビデオ・コーディングに関する。本開示の態様は、エンハンスメント・レイヤのための最終的な予測子を生成するために、結合された、重み付けられたベース・レイヤ予測およびエンハンスメント・レイヤ予測を使用することに関して記載されるだろう。いくつかの例では、これら重みは、スライス全体、コーディング・ブロック、またはビット・ストリームについて一定でありうる。さらなる例では、特定のピクセル、スライス、コーディング・ブロック等のための重みは、変動しうる。変動する重みを決定する際に考慮されうる要因は、とりわけ、以前にコーディングまたはデコードされたブロックに対するピクセルの近接度、および、イントラ予測方向を含みうる。その他の要因は、量子化パラメータ、および空間スケーリング比を含む。

さらなる例では、エンハンスメント・レイヤ予測子およびベース・レイヤ予測子のそれぞれの重みが決定される条件が、これら予測子から、または、これらの特性から、暗黙的に導出されうる。したがって、デコーダに、追加のデータが送信される必要はなく、むしろ、デコーダが、この重みを動的に導出しうる。さらなる例では、デコーダが重みを決定するために使用しうるビット・ストリーム内に、データが含まれうる。

１または複数の例の詳細が、添付図面および以下の説明において述べられる。他の特徴、目的、および利点が、説明と図面から、および特許請求の範囲から明らかになるだろう。

例えば、ビデオ画像、ＴＶ画像、静止画像、または、ビデオ・レコーダまたはコンピュータによって生成された画像は、水平線および垂直線で配列されたピクセルからなる。単一の画像におけるピクセルの数は、一般に、小さな画像の場合、数万であり、高解像度画像の場合、数１００万である。各ピクセルは一般に、輝度情報およびクロミナンス情報を含んでいる。圧縮が無ければ、画像エンコーダから画像デコーダへ送られるべき情報の量は、非常に大きくなり、リアル・タイム送信を非現実的にしうる。送信されるべき情報量を低減するために、例えば、ＪＰＥＧ規格、ＭＰＥＧ規格、およびＨ．２６３規格のような多くの異なる圧縮方法が開発された。

典型的なビデオ・エンコーダでは、オリジナルのビデオ・シーケンスのフレームが、長方形の領域またはブロックへ分割されうる。これらは、イントラ・モード（Ｉ−モード）またはインタ・モード（Ｐ−モード）でエンコードされる。これらブロックは、例えばＤＣＴコーディングのようなある種の変換コーディングを用いてコーディングされうる。しかしながら、純粋な変換ベースのコーディングは、ピクセルのインタ・ブロック相関を考慮することなく、特定のブロック内のインタ・ピクセル相関のみを低減し、一般には、依然として、送信のために高いビット・レートを生成する。現在のデジタル画像コーディング規格はまた、ブロック間のピクセル値の相関を低減するある方法を利用している。

一般に、Ｐモードでエンコードされるブロックは、以前にコーディングされ、送信されたフレームのうちの１つから予測される。ブロックの予測情報は、二次元（２Ｄ）動きベクトルによって表わされる。Ｉモードでエンコードされるブロックの場合、予測されるブロックは、同じフレーム内のすでにエンコードされた近隣ブロックからの空間予測を用いて生成されうる。予測誤差、すなわち、エンコードされたブロックと予測されたブロックとの差分は、ある離散変換の重み付けられた基本関数のセットとして表現される。この変換は、一般に、８×８または４×４のブロック・ベースで実行される。重み（例えば、変換係数）が、その後、量子化される。量子化は、情報の損失をもたらす。したがって、量子化された係数は、オリジナルよりも低い精度しか有していない場合がありうる。

量子化された変換係数は、動きベクトルおよびある制御情報とともに、完全にコーディングされたシーケンス表現を生成し、シンタックス要素と称される。シンタックス要素は、エンコーダからデコーダへの送信前に、これらの表現のために必要とされるビット数をさらに低減するために、エントロピ・コーディングされうる。

ビデオ・デコーダでは、先ず、エンコーダと同じ方式で予測を構築し、圧縮された予測誤差を、この予測に加えることによって、現在のフレームにおけるブロックが取得される。圧縮された予測誤差は、変換ベースの関数を、量子化された係数を用いて重み付けることによって得られうる。再構築されたフレームとオリジナルのフレームとの間の差分は、しばしば、再構築誤差と称される。

本開示に記載された技法は、一般に、スケーラブル・ビデオ・コーディング（ＳＶＣ）および３Ｄビデオ・コーディングに関連する。例えば、これら技法は、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）スケーラブル・ビデオ・コーディング（ＳＶＣ）拡張に関連しており、（ＨＥＶＣ）（ＳＶＣ）拡張とともに、または、（ＨＥＶＣ）（ＳＶＣ）拡張内で使用されうる。ＳＶＣ拡張では、ビデオ情報の多数のレイヤが存在しうる。最下位レベルにおけるレイヤは、ベース・レイヤ（ＢＬ）として役立ち、最上位レベルにおけるレイヤは、エンハンスト・レイヤ（ＥＬ）として役立ちうる。「エンハンスト・レイヤ」は、しばしば、「エンハンスメント・レイヤ」と称される。これら用語は、相互交換可能に使用されうる。中間にあるすべてのレイヤは、ＥＬまたはＢＬの何れかまたは両方として役立ちうる。例えば、中間にあるレイヤは、例えば、ベース・レイヤ、または、介在するエンハンスメント・レイヤのように、その下のレイヤのためのＥＬでありうると同時に、その上のエンハンスメント・レイヤのためのＢＬとして役立ちうる。

例示のみの目的のために、本開示に記載された技法は、２つのみのレイヤ（例えば、ベース・レイヤのような低レベル・レイヤと、エンハンスト・レイヤのような高レベル・レイヤ）を含む例を用いて記載されている。本開示において記載された例は、複数のベース・レイヤおよびエンハンスト・レイヤを用いた例にも同様に拡張されうることが理解されるべきである。

ビデオ・コーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびＩＴＵ−Ｔ Ｈ．２６４（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られている）を含み、そのスケーラベル・ビデオ・コーディング（ＳＶＣ）およびマルチ・ビュー・コーディング（ＭＶＣ）拡張を含んでいる。ＳＶＣおよびＭＶＣの最新のジョイント・ドラフトが、２０１０年３月のＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６４における「一般的なオーディオ・ビジュアル・サービスのためのアドバンスト・ビデオ・コーディング」（Advanced video coding for generic audiovisual services）に記載されている。さらに、新たなビデオ・コーディング規格であるＨｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）がある。これは、ＩＳＯ／ＩＥＣ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）およびＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）のＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｏｎ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって開発された。最近のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）テキスト仕様書ドラフトは、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ―ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１２＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｌ１００３−ｖ１３．ｚｉｐから利用可能である。ＨＥＶＣ ＷＤ９とも称されるＨＥＶＣの別の最近のワーキング・ドラフト（ＷＤ）は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ―ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１１＿Ｓｈａｎｇｈａｉ／ｗｇ１１／ＪＣＴＶＣ−Ｋ１００３−ｖ１３．ｚｉｐにおいて利用可能である。ＨＥＶＣ ＷＤ８（またはＷＤ８）と称されるＨＥＶＣの別のワーキング・ドラフトは、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ―ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１０＿Ｓｔｏｃｋｈｏｌｍ／ｗｇ１１／ＪＣＴＶＣ−Ｊ１００３−ｖ８．ｚｉｐにおいて利用可能である。以下にＨＥＶＣ ＷＤ７と称されるＨＥＶＣの別のワーキング・ドラフトは、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ―ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／９＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｉ１００３−ｖ５．ｚｉｐから利用可能である。これらのドキュメントのすべては、その全体が参照によって組み込まれている。

スケーラブル・ビデオ・コーディング（ＳＶＣ）では、各レイヤ（例えば、ベース・レイヤおよびエンハンスメント・レイヤ）からのビット・ストリームは、単一のビット・ストリームへ、ともに多重化される。そのようなビット・ストリームは、エンハンスメント・レイヤ・ビット・ストリームが、デコードされた場合に、いつくかのエンハンスメントをベース・レイヤに提供しうるという観点において、スケーラブルである。そのようなエンハンスメントは、ベース・レイヤに対する、空間解像度、時間解像度、品質エンハンスメント等を含む。ベース・レイヤは、エンハンスメント・レイヤから独立してデコードされうる。それに応じて、これらエンハンスメントはまた、それぞれ、空間スケーラビリティ、時間スケーラビリティ、および、信号対雑音比（ＳＮＲ）スケーラビリティとも称される。

スケーラビリティのタイプに関わらず、ＳＶＣの目標は、一般に、コーディング効率を改善するために、インタ・レイヤ相関を利用することである。そのようなインタ・レイヤ相関は、（例えば、予測モード、動きベクトル、予測残余等のような）異なるレイヤにおける対応するブロックの異なるシンタックスに存在しうる。

そのような相関を利用するために、多くのコーディング・ツールが、過去に提案されている。例えば、Ｈ．２６４／ＡＶＣのスケーラブル拡張では、例えばイントラ・ベース・レイヤ（ＢＬ）モード、残余予測、モード継承、および動きベクトル予測のようないくつかのコーディング・ツールが定義される。イントラＢＬモードにおいて、ベース・レイヤが再構築したブロックのテクスチャが、対応するエンハンスメント・レイヤ・ブロックを予測する際の予測子として使用される。ベース・レイヤ・ブロックの予測残余が、対応するエンハンスメント・レイヤ・ブロックの予測残差を予測するために、残余予測とともに使用される。ベース・レイヤ・ブロックの予測モード（分割モードを含む）が、エンハンスメント・レイヤ・ブロックの予測モードを予測するために、モード継承とともに使用される。ベース・レイヤ・ブロックの動きベクトルが、エンハンスメント・レイヤ・ブロックの動きベクトルを予測するために、動きベクトル予測とともに使用される。

ＳＶＣでは、レイヤがベース・レイヤであるかエンハンスメント・レイヤであるか否かは、相対的に見られうる。例えば、最初のレイヤと最後のレイヤとの間にある任意のレイヤが、１または複数の下部レイヤのエンハンスメント・レイヤであり、同時に、１または複数の高次レイヤのベース・レイヤとして役立ちうる。

ＳＶＣは、品質（信号対雑音（ＳＮＲ）とも称される）スケーラビリティ、空間スケーラビリティ、および／または、時間スケーラビリティを提供するために使用されうる。エンハンスト・レイヤは、ベース・レイヤとは異なる空間解像度を有しうる。例えば、ＥＬとＢＬとの間の空間アスペクト比は、１．０，１．５，２．０またはその他の異なる比率でありうる。言い換えれば、ＥＬの空間アスペクトは、ＢＬの空間アスペクトの１．０倍、１．５倍、または２．０倍に等しくなりうる。いくつかの例では、ＥＬのスケーリング係数は、ＢＬのものよりも大きくなりうる。例えば、ＥＬにおけるピクチャのサイズは、ＢＬにおけるピクチャのサイズより大きくなりうる。このように、限定する訳ではないが、ＥＬの空間解像度は、ＢＬの空間解像度よりも大きく可能性がありうる。

本開示の態様は、予測されたＥＬブロックを生成するために、ＥＬとＢＬとの両方からの予測に基づいて、結合された予測を用いることに関連する。ＥＬをコーディングする際、予測子は、一般に、前述したように生成されうる。その後、ＥＬ予測子は、ＥＬピクセルのインタ・レイヤ予測のために使用される最終的な予測子の品質を改善するために、ＢＬ予測子と結合されうる。ＥＬ予測子とＢＬ予測子とを結合する際に、重みが適用されうる。これによって、ＥＬ予測子は、ＥＬ予測子がより正確になるケースにおいて、ＢＬ予測子よりも、最終的な予測子に対して影響を与えることができるようになる。あるいは、ＢＬ予測子がより正確になるケースにおいて、ＢＬ予測子が、ＥＬ予測子よりも最終的な予測子に影響を与えることができるように、重みが適用されうる。これら予測子のうちの何れが、より正確になるのかが分からないケースでは、ＢＬ予測子とＥＬ予測子とが、均等に重み付けられうる。

斬新なシステム、装置、および方法のさまざまな態様が、添付図面を参照して以下により十分に記載される。しかしながら、本開示は、異なる多くの形態で具体化され、本開示を通じて示された如何なる具体的な構成または機能にも限定されるとは解釈されるべきではない。むしろ、これらの態様は、本開示が十分で完全であり、本開示の範囲を当業者に十分に伝達できるように提供されている。本明細書における教示に基づいて、当業者は、本開示のスコープは、本発明のその他任意の態様と独立しているか、または、結合されているかに関わらず、本明細書に開示された新規なシステム、装置、および方法の任意の態様をカバーすることが意図されていることを認識すべきである。例えば、本明細書に記載された任意の数の態様を用いて装置が実現され、方法が実施されうる。さらに、本発明の範囲は、別の構成、機能、または、本明細書に記載された発明のさまざまな態様またはそれ以外の態様が追加された構成および機能を用いて実現される装置または方法をカバーすることが意図されている。本明細書で開示されたあらゆる態様は、特許請求の範囲の１または複数の要素によって具体化されうる。

本明細書では、特定の態様が記載されているが、これら態様の多くの変形および置換が、本開示の範囲内にある。好適な態様のいくつかの利点および長所が述べられているが、本開示の範囲は、特定の利点、使用、および目的に限定されることは意図されていない。むしろ、本開示の態様は、このうちのいくつかが図面における例示によって、および、以下の好適な態様の記載によって例示されている異なる無線技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であることが意図されている。詳細な記載および図面は、限定ではない開示の単なる例示であり、本開示の範囲は、特許請求の範囲およびその均等物によって定義される。

図１は、本開示に記載された態様にしたがう技法を利用しうるビデオ・エンコードおよびデコード・システムの例を例示するブロック図である。図１に図示されるように、システム１０は、宛先デバイス１４によって、後の時間においてデコードされるべきエンコードされたビデオ・データを提供するソース・デバイス１２を含む。特に、ソース・デバイス１２は、ビデオ・データを、コンピュータ読取可能な媒体１６を経由して、宛先デバイス１４へ提供する。ソース・デバイス１２および宛先デバイス１４は、デスクトップ・コンピュータ、ノートブック（例えば、ラップトップ）コンピュータ、タブレット・コンピュータ、セット・トップ・ボックス、例えば、いわゆる「スマート」フォンや、いわゆる「スマート」パッドのような電話ハンドセット、テレビ、カメラ、ディスプレイ・デバイス、デジタル・メディア・プレーヤ、ビデオ・ゲーミング・コンソール、ビデオ・ストリーミング・デバイス、等を含む広範なデバイスのうちの何れかを備えうる。いくつかのケースでは、ソース・デバイス１２および宛先デバイス１４が無線通信のために装備されうる。

宛先デバイス１４は、デコードされるべき、エンコードされたビデオ・データを、コンピュータ読取可能な媒体１６を経由して受け取りうる。コンピュータ読取可能な媒体１６は、エンコードされたビデオ・データを、ソース・デバイス１２から宛先デバイス１４へ移動させることが可能な任意のタイプの媒体またはデバイスを備えうる。一例において、コンピュータ読取可能な媒体１６は、エンコードされたビデオ・データを、ソース・デバイス１２が、宛先デバイス１４へリアル・タイムでダイレクトに送信することを可能にする通信媒体を備えうる。エンコードされたビデオ・データは、例えば無線通信プロトコルのような通信規格にしたがって変調され、宛先デバイス１４へ送信されうる。通信媒体は、例えばラジオ周波数（ＲＦ）スペクトルまたは１または複数の物理送信ラインのような任意の無線または有線の通信媒体を備えうる。通信媒体は、例えば、ローカル・エリア・ネットワーク、広域ネットワーク、またはインターネットのようなグローバル・ネットワークのような、パケット・ベースのネットワークの一部を形成しうる。通信媒体は、ルータ、スイッチ、基地局、または、ソース・デバイス１２から宛先デバイス１４への通信を容易にするために有用でありうるその他任意の機器を含みうる。

いくつかの例において、エンコードされたデータは、出力インタフェース２２から、記憶デバイスへ出力されうる。同様に、エンコードされたデータは、入力インタフェースによって、記憶デバイスからアクセスされうる。記憶デバイスは、例えば、ハード・ディスク、ブルーレイ・ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュ・メモリ、揮発性または不揮発性のメモリ、または、エンコードされたビデオ・データを格納するためのその他任意の適切なデジタル記憶媒体のような、種々の分散型またはローカルにアクセスされるデータ記憶媒体のうちの何れかを含みうる。さらなる例では、記憶デバイスは、ソース・デバイス１２によって生成された、エンコードされたビデオを格納しうるファイル・サーバまたはその他の中間記憶デバイスに相当しうる。宛先デバイス１４は、ストリーミングまたはダウンロードによって、記憶デバイスから、格納されたビデオ・データにアクセスしうる。ファイル・サーバは、エンコードされたビデオ・データを格納することと、エンコードされたビデオ・データを宛先デバイス１４へ送信することとが可能な任意のタイプのサーバでありうる。ファイル・サーバの例は、（例えば、ウェブサイト用の）ウェブ・サーバ、ＦＴＰサーバ、ネットワーク・アタッチ・ストレージ（ＮＡＳ：ｎｅｔｗｏｒｋ ａｔｔａｃｈｅｄ ｓｔｏｒａｇｅ）デバイス、またはローカル・ディスク・ドライブを含む。宛先デバイス１４は、エンコードされたビデオ・データに、インターネット接続を含む任意の標準的なデータ接続によってアクセスしうる。これは、無線チャネル（例えば、Ｗｉ−Ｆｉ接続）、有線接続（例えば、ＤＳＬ、ケーブル・モデム等）、または、ファイル・サーバに格納されたエンコードされたビデオ・データにアクセスすることに適したこれら両方の組み合わせを含みうる。記憶デバイスからの、エンコードされたビデオ・データの送信は、ストリーミング送信、ダウンロード送信、またはこれらの組み合わせを備えうる。

本開示の技法は、必ずしも無線のアプリケーションまたはセッティングに制限される必要はない。これら技法は、例えば、オーバ・ザ・エア・テレビジョン・ブロードキャスト、ケーブル・テレビジョン送信、衛星テレビジョン送信、例えば動的適応ストリーミング・オーバＨＴＴＰ（ＤＡＳＨ）のようなインターネット・ストリーミング・ビデオ送信、データ記憶媒体にエンコードされたデジタル・ビデオ、データ記憶媒体に格納されたデジタル・ビデオのコーディング、または、その他のアプリケーションのような種々のマルチメディア・アプリケーションのうちの何れかをサポートするビデオ・コーディングに適用されうる。いくつかの例において、システム１０は、例えばビデオ・ストリーミング、ビデオ再生、ビデオ・ブロードキャスト、および／または、ビデオ・テレフォニのようなアプリケーションをサポートする１方向または２方向のビデオ送信をサポートするように構成されうる。

図１の例では、ソース・デバイス１２は、ビデオ・ソース１８、ビデオ・エンコーダ２０、および出力インタフェース２２を含んでいる。宛先デバイス１４は、入力インタフェース２８、ビデオ・デコーダ３０、およびディスプレイ・デバイス３２を含んでいる。ソース・デバイス１２のビデオ・エンコーダ２０は、本開示にしたがって、複数の規格または規格拡張版に準拠するビデオ・データを含むビット・ストリームをコーディングするための技法を適用するように構成されうる。別の例では、ソース・デバイスおよび宛先デバイスは、その他の構成要素または構成を含みうる。例えば、ソース・デバイス１２は、例えば外部カメラのような外部ビデオ・ソース１８からビデオ・データを受け取りうる。同様に、宛先デバイス１４は、統合されたディスプレイ・デバイスを含むのではなく、外部のディスプレイ・デバイスとインタフェースしうる。

図１の例示されたシステム１０は単なる一例である。現在のブロックのための動きベクトル予測の候補リストのための候補を決定するための技法は、任意のデジタル・ビデオ・エンコーディングおよび／またはデコーディング・デバイスによって実行されうる。一般に、本開示の技法は、ビデオ・エンコーディング・デバイスによって実行されるが、本技法はまた、一般に「コーデック」と称されるビデオ・エンコーダ／デコーダによって実行されうる。さらに、本開示の技術はまた、ビデオ・プリプロセッサによっても実行されうる。ソース・デバイス１２および宛先デバイス１４は、単に、ソース・デバイス１２が、宛先デバイス１４への送信のために、コーディングされたビデオ・データを生成するようなコーディング・デバイスの例である。いくつかの例において、デバイス１２，１４は、デバイス１２，１４のおのおのがビデオ・エンコードおよびデコード構成要素を含むように、実質的に対称的に動作しうる。したがって、システム１０は、例えば、ビデオ・ストリーミング、ビデオ・プレイバック、ビデオ・ブロードキャスト、またはビデオ・テレフォニのために、ビデオ・デバイス１２，１４間の１方向または２方向のビデオ送信をサポートしうる。

ソース・デバイス１２のビデオ・ソース１８は、例えば、ビデオ・カメラ、以前にキャプチャされたビデオを含むビデオ・アーカイブ、および／または、ビデオ・コンテンツ・プロバイダからビデオを受け取るためのビデオ・フィード・インタフェースのようなビデオ・キャプチャ・デバイスを含みうる。さらなる代案として、ビデオ・ソース１８は、コンピュータ・グラフィック・ベースのデータを、ソース・ビデオとして、または、ライブ・ビデオと、アーカイブされたビデオと、コンピュータによって生成されたビデオとの組み合わせとして生成しうる。いくつかのケースにおいて、ビデオ・ソース１８がビデオ・カメラであれば、ソース・デバイス１２および宛先デバイス１４は、いわゆるカメラ電話またはテレビ電話を形成しうる。しかしながら、前述したように、本開示において記載されているこれら技法は、一般に、ビデオ・コーディングに適用可能でありうる。そして、無線または有線のアプリケーションに適用されうる。各ケースでは、キャプチャされたビデオ、プリ・キャプチャされたビデオ、または、コンピュータによって生成されたビデオが、ビデオ・エンコーダ２０によってエンコードされうる。エンコードされたビデオ情報は、その後、出力インタフェース２２によって、コンピュータ読取可能な媒体１６に出力されうる。

コンピュータ読取可能な媒体１６は、例えば無線ブロードキャストまたは有線ネットワーク送信のような一時的な媒体、または、例えばハード・ディスク、フラッシュ・ドライブ、コンパクト・ディスク、デジタル・ビデオ・ディスク、ブルーレイ・ディスクのような記憶媒体（すなわち、非一時的な記憶媒体）、または、その他のコンピュータ読取可能な媒体を含みうる。いくつかの例において、ネットワーク・サーバ（図示せず）は、エンコードされたビデオ・データを、ソース・デバイス１２から受け取り、エンコードされたビデオ・データを、例えばネットワーク送信、ダイレクト有線通信等によって、宛先デバイス１４へ提供しうる。同様に、例えばディスク・スタンピング施設のような媒体製造施設のコンピューティング・デバイスが、エンコードされたビデオ・データをソース・デバイス１２から受け取り、このエンコードされたビデオ・データを含むディスクを生成しうる。

したがって、コンピュータ読取可能な媒体１６は、さまざまな例において、さまざまな形態からなる１または複数のコンピュータ読取可能な媒体を含むものと理解されうる。

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

ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格のようなビデオ・コーディング規格にしたがって動作し、ＨＥＶＣテスト・モデル（ＨＭ）に準拠しうる。あるいは、ビデオ・エンコーダ２０およびビデオ・デコーダ３０は、例えば、ＭＰＥＧ ４、パート１０、アドバンスト・ビデオ・コーディング（ＡＶＣ）とも称されるＩＴＵ−Ｔ Ｈ．２６４規格のようなその他の独占規格または業界規格、または、これら規格の拡張版にしたがって動作しうる。しかしながら、本開示の技法は、任意の特定のコーディング規格に限定されず、上記リストされた規格の何れにも制限されないことを含む。ビデオ・コーディング規格のその他の例は、ＭＰＥＧ２およびＩＴＵ−Ｔ Ｈ．２６３を含んでいる。図１に図示されていないが、いくつかの態様では、ビデオ・エンコーダ２０およびビデオ・デコーダ３０はおのおの、オーディオ・エンコーダおよびデコーダと統合されうる。そして、共通のデータ・ストリームまたは個別のデータ・ストリームでオーディオとビデオとの両方のエンコードを取り扱うために、適切なＭＵＸ−ＤＥＭＵＸユニット、またはその他のハードウェアおよびソフトウェアを含みうる。適用可能であれば、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ Ｈ．２２３マルチプレクサ・プロトコル、または、例えばユーザ・データグラム・プロトコル（ＵＤＰ）のようなその他のプロトコルに準拠しうる。

ビデオ・エンコーダ２０およびビデオ・デコーダ３０はおのおの、例えば１または複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディスクリート・ロジック、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせ、のようなさまざまな適切なエンコーダ回路のうちの何れかとして実現されうる。これら技法が部分的にソフトウェアで実現される場合、デバイスは、本開示の技法を実行するために、ソフトウェアのための命令群を、適切な非一時的なコンピュータ読取可能な媒体に格納し、１または複数のプロセッサを用いて、ハードウェアにおいて、これら命令群を実行しうる。ビデオ・エンコーダ２０およびビデオ・デコーダ３０のおのおのは、１または複数のエンコーダまたはデコーダに含まれうる。これらの何れかは、それぞれのデバイスにおいて、結合されたビデオ・エンコーダ／デコーダ（コーデック）の一部として統合されうる。ビデオ・エンコーダ２０および／またはビデオ・デコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／または、例えばセルラ電話のような無線通信デバイスを含みうる。

ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に寄与している。ＨＥＶＣ規格化の努力は、ＨＥＶＣテスト・モデル（ＨＭ）と称されるビデオ・コーディング・デバイスの発展中のモデルに基づく。ＨＭは、例えばＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣにしたがう既存のデバイスに対するビデオ・コーディング・デバイスのいくつかの追加機能であると考えられる。例えば、Ｈ．２６４が、９つのイントラ予測エンコーディング・モードを提供する一方、ＨＭは、３３ものイントラ予測エンコーディング・モードを提供しうる。

一般に、ＨＭのワーキング・モデルは、ビデオ・フレームまたはピクチャが、輝度サンプルと彩度サンプルとの両方を含む最大コーディング・ユニット（ＬＣＵ：ｌａｒｇｅｓｔ ｃｏｄｉｎｇ ｕｎｉｔ）またはツリーブロックのシーケンスへ分割されうることを記載している。ビット・ストリーム内のシンタックス・データは、ピクセル数の観点から最大のコーディング・ユニットであるＬＣＵのためのサイズを定義しうる。

スライスは、連続した多くのツリーブロックを、コーディング順に含んでいる。

ビデオ・フレームまたはピクチャは、１または複数のスライスへ分割されうる。

おのおののツリーブロックは、クワッドツリーにしたがってコーディング・ユニット（ＣＵ）へ分割されうる。一般に、クワッドツリー・データ構造は、ツリーブロックに対応するルート・ノードと共に、ＣＵ当たり１つのノードを含んでいる。ＣＵが４つのサブＣＵへ分割されるのであれば、ＣＵに対応するノードは、４つのリーフ・ノードを含んでいる。これらのおのおのは、サブＣＵのうちの１つに対応する。

クワッドツリー・データ構造の各ノードは、対応するＣＵのためのシンタックス・データを提供しうる。例えば、クワッドツリーにおけるノードは、分割フラグを含みうる。これは、このノードに対応するＣＵが、サブＣＵに分割されるているか否かを示す。ＣＵのためのシンタックス要素は、再帰的に定義され、ＣＵがサブＣＵに分割されているか否かに依存しうる。ＣＵは、さらに分割されないのであれば、リーフＣＵと称される。本開示では、たとえオリジナルのリーフＣＵの明示的な分割が無くても、リーフＣＵのうちの４つのサブＣＵも、リーフＣＵと称されるだろう。例えば、１６×１６サイズのＣＵがこれ以上分割されていないのであれば、１６×１６のＣＵが分割されていなくても、４つの８×８のサブＣＵもまたリーフＣＵと称されるだろう。

ＣＵは、ＣＵがサイズ区別を有していないこと以外は、Ｈ．２６４規格のマクロブロックと同様の目的を有する。例えば、ツリーブロックは、４つの子ノード（サブＣＵとも称される）に分割され、各子ノードが親ノードになり、別の４つの子ノードに分割されうる。クワッドツリーのリーフ・ノードと称される最終的な分割されない子ノードは、リーフＣＵとも称されるコーディング・ノードを備える。コーディングされたビット・ストリームに関連付けられたシンタックス・データは、最大ＣＵデプスと称される、ツリーブロックが分割される最大回数を定義しうる。そして、コーディング・ノードの最大サイズをも定義しうる。したがって、ビット・ストリームはまた、最小コーディング・ユニット（ＳＣＵ）を定義しうる。本開示は、ＨＥＶＣのコンテキストにおいて、または、その他の規格におけるコンテキストの類似のデータ構造（例えば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそのサブ・ブロック）におけるＣＵ、ＰＵ、またはＴＵのうちの何れかを称するために「ブロック」という用語を用いる。

ＣＵは、コーディング・ノードと、コーディング・ノードに関連付けられた変換ユニット（ＴＵ：ｔｒａｎｓｆｏｒｍ ｕｎｉｔ）および予測ユニット（ＰＵ：ｐｒｅｄｉｃｔｉｏｎ ｕｎｉｔ）を含む。ＣＵのサイズは、コーディング・ノードのサイズに相当し、正方形の形状でなければならない。ＣＵのサイズは、８×８ピクセルから、最大６４×６４またはそれ以上のピクセルを有するツリーブロックのサイズに及びうる。おのおののＣＵは、１または複数のＰＵおよび１または複数のＴＵを含みうる。ＣＵに関連付けられたシンタックス・データは、例えば、ＣＵを、１または複数のＰＵへ分割することを記述しうる。モードを分割することは、ＣＵがスキップされるか、または、ダイレクト・モード・エンコードされるか、イントラ予測モード・エンコードされるか、インタ予測モード・エンコードされるかで異なりうる。ＰＵは、非正方形の形状に分割されうる。ＣＵに関連付けられたシンタックス・データはまた、例えば、クワッドツリーにしたがって、ＣＵを１または複数のＴＵへ分割することを記述しうる。ＴＵは、正方形形状または非正方形形状（例えば、長方形）でありうる。

ＨＥＶＣ規格は、ＴＵにしたがう変換を考慮している。これは異なるＣＵについて異なりうる。ＴＵは、常にそうであるとは限らないが、一般に、分割されたＬＣＵのために定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ化される。ＴＵは、一般に、ＰＵと同じサイズであるか、ＰＵよりも小さい。いくつかの例において、ＣＵに対応する残余サンプルは、「残余クワッドツリー」（ＲＱＴ：ｒｅｓｉｄｕａｌ ｑｕａｄ ｔｒｅｅ）として知られているクワッドツリー構造を用いて、より小さなユニットに細分化されうる。ＲＱＴのリーフ・ノードは、変換ユニット（ＴＵ）と称されうる。ＴＵに関連付けられたピクセル差分値は、変換係数を生成するために変換されうる。これは、量子化されうる。

リーフＣＵは、１または複数の予測ユニット（ＰＵ）を含みうる。一般に、ＰＵは、対応するＣＵのすべてまたは一部に対応する空間エリアを表し、ＰＵのための基準サンプルを取得するためのデータを含みうる。さらに、ＰＵは、予測に関連するデータを含む。例えば、ＰＵがイントラ・モード・エンコードされた場合、ＰＵのデータは、残余クワッドツリー（ＲＱＴ）に含まれうる。これは、ＰＵに対応するＴＵのためのイントラ予測モードを記述するデータを含みうる。別の例として、ＰＵがインタ・モード・エンコードされている場合、ＰＵは、ＰＵのための１または複数の動きベクトルを定義するデータを含みうる。ＰＵの動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（例えば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが示す基準ピクチャ、および／または、動きベクトルの基準ピクチャ・リスト（例えば、リスト０、リスト１、またはリストＣ）、を記述しうる。

１または複数のＰＵを有するリーフＣＵはまた、１または複数の変換ユニット（ＴＵ）を含みうる。変換ユニットは、前述したように、（ＴＵクワッドツリー構造とも称される）ＲＱＴを用いて指定されうる。例えば、分割フラグが、リーフＣＵが４つの変換ユニットに分割されているか否かを示しうる。その後、各変換ユニットは、さらに、さらなるサブＴＵに分割されうる。ＴＵは、さらに分割されない場合、リーフＴＵと称されうる。一般に、イントラ・コーディングの場合、リーフＣＵに属するすべてのリーフＴＵは、同じイントラ予測モードを共有する。すなわち、同じイントラ予測モードは、一般に、リーフＣＵのすべてのＴＵのための予測値を計算するために適用される。イントラ・コーディングのために、ビデオ・エンコーダは、イントラ予測モードを用いて、各リーフＴＵのための残余値を、ＴＵに対応するＣＵの一部と、オリジナル・ブロックとの間の差分として計算しうる。ＴＵは、必ずしもＰＵのサイズに制限されない。したがって、ＴＵは、ＰＵより大きくも、または、小さくもなりうる。イントラ・コーディングのために、ＰＵは、同じＣＵのための対応するリーフＴＵと連結されうる。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに相当しうる。

さらに、リーフＣＵのＴＵはまた、残余クワッドツリー（ＲＱＴ）と称されるそれぞれのクワッドツリー・データ構造に関連付けられうる。すなわち、リーフＣＵは、リーフＣＵがどうやってＴＵへ分割されるのかを示すクワッドツリーを含みうる。ＴＵクワッドツリーのルート・ノードは、一般に、リーフＣＵに対応する。一方、ＣＵクワッドツリーのルート・ノードは、一般に、ツリーブロック（またはＬＣＵ）に対応する。

分割されないＲＱＴのＴＵは、リーフＴＵと称される。一般に、もしも別に言及されていないのであれば、本開示は、リーフＣＵおよびリーフＴＵを称するためにＣＵおよびＴＵという用語を用いる。

ビデオ・シーケンスは一般に、一連のビデオ・フレームまたはピクチャを含む。ピクチャのグループ（ＧＯＰ：ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ）は、一般に、１または複数のビデオ・ピクチャからなる一連のビデオ・ピクチャを備える。ＧＯＰは、ＧＯＰのヘッダ、ピクチャの１または複数のヘッダ、または別の何れかに、シンタックス・データを含みうる。これは、ＧＯＰに含まれるピクチャの数を記述している。ピクチャのおのおののスライスは、それぞれのスライスのためのエンコード・モードを記述するスライス・シンタックス・データを含みうる。ビデオ・エンコーダ２０は一般に、ビデオ・データをエンコードするために、個々のビデオ・スライス内のビデオ・ブロックに対して動作する。ビデオ・ブロックは、ＣＵ内のコーディング・ノードに対応しうる。ビデオ・ブロックは、固定サイズまたは可変サイズを有しうる。そして、指定されたコーディング規格によってサイズが異なりうる。

例として、ＨＭは、さまざまなＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮであるＰＵサイズではイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎである対称なＰＵサイズではインタ予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズにおけるインタ予測のために、非対称分割をサポートする。非対称分割では、ＣＵの１つの方向が分割されないが、他の方向が２５％および７５％へ分割される。２５％分割に対応するＣＵ部分は、“Ｕｐ”、“Ｄｏｗｎ”、“Ｌｅｆｔ”、または“Ｒｉｇｈｔ”を示すインジケーションが続く“ｎ”によって示される。したがって、例えば、“２Ｎ×ｎＵ”は、トップにおいて２Ｎ×０．５Ｎ ＰＵで、ボトムにおいて２Ｎ×１．５Ｎ ＰＵを用いて水平的に分割される２Ｎ×２Ｎ ＣＵを称する。

本開示では、“Ｎ×Ｎ”および“ＮバイＮ”は、例えば１６×１６ピクセルまたは１６バイ１６ピクセルのように、垂直大きさおよび水平大きさに関するビデオ・ブロックのピクセル大きさを称するために交換可能に使用されうる。一般に、１６×１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）と、水平方向に１６ピクセル（ｘ＝１６）をと有するだろう。同様に、Ｎ×Ｎブロックは、一般に、垂直方向においてＮ個のピクセルと、水平方向においてＮ個のピクセルとを有する。ここで、Ｎは、負ではない整数値を表す。ブロックにおけるピクセルは、行と列とで構成されうる。さらに、ブロックは、必ずしも、垂直方向と同じ数のピクセルを、水平方向に有する必要はない場合がありうる。例えば、ブロックは、Ｎ×Ｍピクセルを備えうる。ここで、Ｍは、必ずしもＮに等しくはない。

ＣＵのＰＵを用いたイントラ予測コーディングまたはインタ予測コーディングの後、ビデオ・エンコーダ２０は、ＣＵのＴＵの残余データを計算しうる。ＰＵは、（ピクセル領域とも称される）空間領域に予測ピクセル・データ生成する方法またはモードを記述するシンタックス・データを備えうる。そして、ＴＵは、例えば、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または、残余ビデオ・データへの概念的に類似の変換、のような変換の適用後、変換領域に係数を備えうる。残余データは、エンコードされていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応しうる。ビデオ・エンコーダ２０は、ＣＵのための残余データを含むＴＵを生成し、その後、ＴＵを変換して、ＣＵのための変換係数を生成する。

変換係数を生成する任意の変換後、ビデオ・エンコーダ２０は、変換係数の量子化を実行しうる。量子化は、その最も広い通常の意味を有することが意図された広い用語である。１つの実施形態では、量子化は、変換係数が量子化され、恐らくは、さらなる圧縮によって、これら係数を表すために使用されるデータ量が低減される処理を称する。この量子化処理は、これら係数のうちのいくつかまたはすべてに関連付けられたビット・デプスを低減しうる。例えば、ｎビット値は、量子化中に、ｍビット値に丸められうる。ここで、ｎは、ｍよりも大きい。

量子化後、ビデオ・エンコーダは、変換係数をスキャンし、量子化された変換係数を含む２次元行列から１次元ベクトルを生成する。スキャンは、アレイの前面により高いエネルギ（したがって、より低い周波数）係数を配置し、アレイに背面により低いエネルギ（したがって、より高い周波数）係数を配置するように設計されうる。いくつかの例において、ビデオ・エンコーダ２０は、量子化された変換係数をスキャンするために、予め定義されたスキャン順序を利用し、エントロピ・エンコードされうるシリアル・ベクトルが生成されうる。別の例では、ビデオ・エンコーダ２０は、適応性スキャンを実行しうる。１次元ベクトルを生成するために、量子化された変換係数がスキャンされた後、ビデオ・エンコーダ２０は、例えば、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ・コーディング、（ＣＡＢＡＣ）、シンタックス・ベース・コンテキスト適応バイナリ・コーディング（ＳＢＡＣ）、確率インタバル分割エントロピ（ＰＩＰＥ）コーディング、または、その他のエントロピ・エンコード方法にしたがって、１次元ベクトルをエントロピ・エンコードしうる。ビデオ・エンコーダ２０はさらに、ビデオ・データをデコードする際にビデオ・デコーダ３０によって用いられるために、エンコードされたビデオ・データに関連付けられたシンタックス要素をエントロピ・エンコードしうる。

ＣＡＢＡＣを実行するために、ビデオ・エンコーダ２０は、コンテキスト・モデル内のコンテキストを、送信されるべきシンボルへ割り当てうる。このコンテキストは、例えば、近隣のシンボルの値が、非ゼロであるか否かに関連しうる。ＣＡＶＬＣを実行するために、ビデオ・エンコーダ２０は、送信されるべきシンボルのために、可変長コードを選択しうる。ＶＬＣにおけるコードワードは、比較的短いコードが、より確率の高いシンボルに対応する一方、よい長いコードが、より確率の低いシンボルに対応するように構築されうる。このように、ＶＬＣを用いることで、例えば、送信されるべき各シンボルのために等しい長さのコードワードを用いるよりも、ビットを節約しうる。確率決定は、シンボルに割り当てられたコンテキストに基づきうる。

ビデオ・エンコーダ２０はさらに、例えば、ブロック・ベースのシンタックス・データ、フレーム・ベースのシンタックス・データ、およびＧＯＰベースのシンタックス・データのようなシンタックス・データを、例えば、フレーム・ヘッダ、ブロック・ヘッダ、スライス・ヘッダ、またはＧＯＰヘッダで、ビデオ・デコーダ３０へ送信しうる。ＧＯＰシンタックス・データは、それぞれのＧＯＰにおけるフレームの数を記述しうる。そして、フレーム・シンタックス・データは、対応するフレームをエンコードするために使用されるエンコード／予測モードを示しうる。

図２は、例えば、図３のビデオ・エンコーダ２０、図４のビデオ・デコーダ３０、または他のいくつかのビデオ・コーダのような種々のビデオ・コーダによって実施されうる処理フローの例を例示する。以下の記載では、例示の便宜上、ベース・レイヤ・ブロックが再構築したテクスチャは、ＢＬ予測子と称される（Ｐｂとして表示される）。エンハンスメント・レイヤ・ブロックの情報を用いてエンハンスメント・レイヤにおいて生成される予測子は、ＥＬ予測子と称される（Ｐｅとして表示される）。本開示の技法にしたがって、ＢＬ予測子とＥＬ予測子との適切な結合によって生成される予測子は、最終的な予測子と称される（Ｐｆとして表示される）。これは、現在のエンハンスメント・レイヤ・ブロックを予測するために実際に使用されるものである。図２に例示される処理は、インタ・レイヤ予測子を生成する場合に、ＢＬ予測子とＥＬ予測子とを結合するために使用されうる。

ベース・レイヤ・ビデオ情報３００およびエンハンスメント・レイヤ・ビデオ情報３０２は、ビデオ・コーダによって取得されうる。ブロック３１０では、例えばＢＬブロックのようなベース・レイヤ・ビデオのコーディングが始まりうる。ＢＬ予測子（例えば、ベース・レイヤにおいて再構築されたブロック）は、本明細書に記載された動き補償予測技法、イントラ予測技法、および残余予測技法にしたがって生成されうる。ブロック３１２では、例えばＥＬブロックのようなエンハンスメント・レイヤ・ビデオのコーディングも始まりうる。ＥＬ予測子は、動き補償された予測およびイントラ予測にしたがって生成されうる。さらに、ブロック３１０で生成されたＢＬ予測子は、最終的なＥＬ予測子を生成するために、ブロック３１２において生成されたＥＬ予測子と結合されうる。以下に示すように、最終的なＥＬ予測子を生成する際、より正確である可能性が高い予測子により高い重みを与えるために、ＢＬ予測子およびＥＬ予測子に重み付け係数が適用されうる。

いくつかの実施形態では、第１の重み付け係数は、ベース・レイヤ予測子のすべてのピクセルについて一定であり、第２の重み付け係数は、ベース・レイヤ予測子のすべてのピクセルについて一定でありうる。さらなる実施形態では、第１の重み付け係数は、ピクセル位置の関数として変動し、第２の重み付け係数は、ピクセル位置の関数として変動しうる。さらなる実施形態では、重み付け係数は、量子化パラメータまたは空間スケーリング比に基づいて変動しうる。与えられた例の何れかについて、重み付け係数は、第１の重み付け係数および第２の重み付け係数の総和が、一定値に等しくなるように決定されうる。

例えば、現在のエンハンスメント・レイヤ・ブロック（例えば、現在コーディングされているＥＬブロック）の境界または境界近傍におけるピクセルについて、ＥＬ予測子に対応する第２の重み付け係数は、ＢＬ予測子に対応する第１の重み付け係数よりも大きくなりうる。このような重み付けは、現在のＥＬブロックのピクセルの近傍のピクセルまたは隣接するピクセルが、ベース・レイヤからのピクセルよりも、より良好な予測子を与えるケースにおいて使用されうる。現在のエンハンスメント・レイヤ・ブロックの境界にも、その近傍にもないピクセルについては、ＢＬ予測子に対応する第１の重み付け係数は、ＥＬ予測子に対応する第２の重み付け係数よりも大きくなりうる。これらの場合では、現在のエンハンスメント・レイヤ・ブロックに対応するベース・レイヤ・ブロックからのピクセルが、その他のエンハンスメント・レイヤ・ブロックからのピクセルよりも、より良好な予測子を与えると判定されうる。これら予測子に適用される重みに影響を与えるほど、隣接するエンハンスメント・レイヤ・ブロックにピクセルが十分近い場合にあるとの判定は、現在のエンハンスメント・レイヤ・ブロックのイントラ予測方向に基づいて、ビデオ・コーダによってなされうる。

ビデオ・コーダはまた、現在のエンハンスメント・レイヤ・ブロックの境界とピクセルとの間の距離の関数として、第１の重み付け係数を決定しうる。第２の重み付け係数は、一般に、境界に近いピクセルに対して増加し、第１の重み付け係数は、一般に、境界から離れるピクセルに対して増加する。

ビデオ・コーダはまた、ベース・レイヤ予測子の量子化パラメータと、エンハンスメント・レイヤ予測子の量子化パラメータとに基づいて、第１の重み付け係数および第２の重み付け係数を決定しうる。例えば、ＢＬの量子化パラメータが、ＥＬの量子化パラメータに実質的に等しいか、または、ＥＬの量子化パラメータの、あるしきい値内にあるのであれば、ＢＬ予測子およびＥＬ予測子の重みは、ＥＬ量子化パラメータとＢＬ量子化パラメータとの差分が大きい場合よりも近くなりうる。ＢＬ量子化パラメータが、ＥＬ量子化パラメータよりもはるかに大きいのであれば、ビデオ・コーダがＥＬ予測子に割り当てる重みは、ＢＬ予測子に割り当てられる重みよりも実質的に大きくなりうる（例えば、差分ＱＰ１−ＱＰ２が増加すると、ＥＬ予測子に割り当てられた重みが増加する。ここで、ＱＰ１は、ＢＬの量子化パラメータを表わし、ＱＰ２は、ＥＬの量子化パラメータを表わす）。同様に、ＢＬ量子化パラメータがＥＬ量子化パラメータよりもはるかに小さいのであれば、ビデオ・コーダがＥＬ予測子に割り当てる重みは、ＢＬ予測子に割り当てられた重みよりも実質的に小さくなりうる。

ビデオ・コーダはまた、スケーリング比に基づいて、第１の重み付け係数と第２の重み付け係数とを選択しうる。例えば、より大きなスケーリング比は、一般に、第２の重み付け係数のためのより高い値に対応しうる。

ブロック３２０では、前述されたように生成された予測ＢＬブロックとオリジナルのＢＬブロックとの間のピクセル差分を表わす残余データが、コーディングされうる。例えば、ビデオをエンコードする場合、残余データは、ピクセル領域から変換領域へ変換され、残余変換係数となる。残余変換係数は、その後、量子化されうる。ブロック３２２では、前述されたように生成された予測ＥＬブロックとオリジナルのＥＬブロックとの間のピクセル差分を表わす残余データが、コーディングされうる。

ブロック３３０では、ベース・レイヤのための動きベクトルに対する予測子が、例えば本明細書に記載されたような動き予測技法にしたがって生成されうる。ブロック３３２では、エンハンスメント・レイヤのための動きベクトルに対する予測子が、動き予測技法にしたがって生成されうる。さらに、ベース・レイヤ動きベクトルは、エンハンスメント・レイヤ動きベクトルのための予測子として使用されうる。

ブロック３４０では、コーディングされたＢＬビデオが、ビデオ・コーダから出力されうる。ブロック３４２では、コーディングされたＥＬビデオが、ビデオ・コーダから出力されうる。この処理がビデオ・エンコーダによって実行される場合、ＢＬ残余およびその他のシンタックス要素が、エントロピ・コーディングされ、結果として得られるビット・ストリームのサイズがさらに低減されうる。そして、ＥＬ残余およびその他のシンタックス要素が、同様にエントロピ・コーディングされうる。各レイヤに対応するビット・ストリームは、その後、出力（例えば、送信または格納）のために多重化されうる。この処理がビデオ・デコーダによって実行される場合、コーディングされたＥＬビデオおよびＢＬビデオは、（例えば、デコーダに関連付けられたディスプレイで）表示するためのビデオ信号を出力するために使用されうる。

図３は、本開示において記載された態様にしたがうコーディング技法を実施しうるビデオ・エンコーダ２０の例を例示するブロック図である。ビデオ・エンコーダ２０は、本開示の技法のうちの何れかまたはすべてを実行するように構成されうる。一例として、モード選択ユニット４０は、例えばピクセル位置、ＢＬ特性およびＥＬ特性等に基づいてＢＬ重みおよびＥＬ重みを決定することのように、本開示で記載された技法のいずれかはまたはすべてを実行するように構成されうる。しかしながら、本開示の態様は、そのように限定されない。いくつかの例において、本開示に記載された技法は、ビデオ・エンコーダ２０のさまざまな構成要素間で共有されうる。いくつかの例では、それに加えて、または、その代わりに、プロセッサ（図示せず）が、本開示に記載された技法の何れかまたはすべてを実行するように構成されうる。

ビデオ・エンコーダ２０は、ビデオ・スライス内で、ビデオ・ブロックのイントラ・コーディングおよびインタ・コーディングを実行しうる。イントラ・コーディングは、所与のビデオ・フレームまたはピクチャ内のビデオにおける空間冗長を低減または除去するために、空間予測に依存する。インタ・コーディングは、ビデオ・シーケンスの隣接するフレームまたはピクチャ内のビデオにおける時間冗長を低減または除去するために、時間予測に依存する。イントラ・モード（Ｉモード）は、いくつかの空間ベースのコーディング・モードのうちの何れかを称しうる。例えば単一方向予測（Ｐモード）または双方向予測（Ｂモード）のようなインタ・モードは、いくつかの時間ベースのコーディング・モードのうちの何れかを称しうる。

図３に図示されるように、ビデオ・エンコーダ２０は、エンコードされるべきビデオ・フレーム内の現在のビデオ・ブロックを受け取る。図３の例では、ビデオ・エンコーダ２０は、モード選択ユニット４０、基準フレーム・メモリ６４、加算器５０、変換処理ユニット５２、量子化ユニット５４、およびエントロピ・エンコーディング・ユニット５６を含んでいる。一方、モード選択ユニット４０は、動き補償ユニット４４、動き推定ユニット４２、イントラ予測ユニット４６、および分割ユニット４８を含んでいる。ビデオ・ブロック再構築のために、ビデオ・エンコーダ２０はまた、逆量子化ユニット５８、逆変換ユニット６０、および加算器６２を含んでいる。再構築されたビデオからのブロッキネス（blockiness）アーチファクトを除去するためにブロック境界をフィルタするデブロッキング・フィルタ（図３に図示せず）もまた含まれうる。所望されるのであれば、デブロッキング・フィルタは、一般には、加算器６２の出力をフィルタするであろう。デブロッキング・フィルタに加えて、（ループまたはポスト・ループにおける）追加のフィルタも使用されうる。このようなフィルタは、簡潔さのために図示されていないが、もしも所望されるのであれば、加算器５０の出力を（イン・ループ・フィルタとして）フィルタしうる。

エンコード処理中、ビデオ・エンコーダ２０は、コーディングされるべきビデオ・フレームまたはスライスを受け取る。フレームまたはスライスは、複数のビデオ・ブロックに分割されうる。動き推定ユニット４２および動き補償ユニット４４は、時間予測を与えるために、１または複数の基準フレームにおける１または複数のブロックに対して、受け取られたビデオ・ブロックのインタ予測コーディングを実行する。イントラ予測ユニット４６は、代わりに、同じフレームまたはスライスにおける１または複数の近隣ブロックに対して、受け取られたビデオ・ブロックのイントラ予測コーディングを、空間予測を提供するためにコーディングされるべきブロックとして実行しうる。ビデオ・エンコーダ２０は、例えば、ビデオ・データの各ブロックのために適切なコーディング・モードを選択するために、複数のコーディング・パスを実行しうる。

さらに、分割ユニット４８は、以前のコーディング・パスにおける以前の分割スキームの評価に基づいて、ビデオ・データのブロックを、サブ・ブロックに分割しうる。例えば、分割ユニット４８は、先ず、フレームまたはスライスを、ＬＣＵに分割し、ＬＣＵのおのおのを、レート歪み分析（例えば、レート歪み最適化）に基づいてサブＣＵに分割しうる。モード選択ユニット４０はさらに、ＬＣＵのサブＣＵへの分割を示すクワッドツリー・データ構造を生成しうる。クワッドツリーのリーフ・ノードＣＵは、１または複数のＰＵおよび１または複数のＴＵを含みうる。

モード選択ユニット４０は、例えば、誤り結果に基づいて、イントラまたはインタのコーディング・モードのうちの１つを選択しうる。そして、結果として得られたイントラ・コーディングされたブロックまたはインタ・コーディングされたブロックを加算器５０に提供し、残余ブロック・データを生成する。また、加算器６２に提供し、エンコードされたブロックを、基準フレームとして使用するために再構築する。モード選択ユニット４０はまた、例えば、動きベクトル、イントラ・モード・インジケータ、分割情報、およびその他のこのようなシンタックス情報を、エントロピ・コーディング・ユニット５６に提供する。

動き推定ユニット４２および動き補償ユニット４４は、高度に統合されうるが、概念の目的のために、個別に例示されている。動き推定ユニット４２によって実行される動き推定は、動きベクトルを生成する処理であり、ビデオ・ブロックの動きを推定する。動きベクトルは、例えば、現在のフレーム内でコーディングされている現在のブロック（または、その他のコーディングされたユニット）に対する、基準フレーム内の予測ブロック（または、その他のコーディングされたユニット）に対する現在のビデオ・フレームまたはピクチャ内のビデオ・ブロックのＰＵの変位を示しうる。予測ブロックは、絶対差分（ＳＡＤ）の合計、平方差分（ＳＳＤ）の合計、または、その他の別のメトリックによって決定されうるピクセル差分の観点においてコーディングされるべきブロックに緊密にマッチするものとして発見されるブロックである。いくつかの例では、ビデオ・エンコーダ２０は、基準フレーム・メモリ６４内に格納された基準ピクチャの整数未満のピクセル位置の値を計算しうる。例えば、ビデオ・エンコーダ２０は、基準ピクチャの、１／４ピクセル位置、１／８ピクセル位置、または、その他の分数のピクセル位置の値を補間しうる。したがって、動き推定ユニット４２は、フル・ピクセル位置および分数ピクセル位置に対する動き探索を実行し、動きベクトルを、分数ピクセル精度で出力しうる。

動き推定ユニット４２は、ＰＵの位置を、基準ピクチャの予測ブロックの位置と比較することによって、インタ・コード・スライスにおけるビデオ・ブロックのＰＵの動きベクトルを計算する。基準ピクチャは、第１の基準ピクチャ・リスト（リスト０）または第２の基準ピクチャ・リスト（リスト１）から選択されうる。これらのおのおのは、基準フレーム・メモリ６４に格納された１または複数の基準フレームを識別しうる。動き推定ユニット４２は、計算された動きベクトルを、エントロピ・エンコード・ユニット５６および動き補償ユニット４４へ送信する。

動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって決定された動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを含みうる。繰り返すが、動き推定ユニット４２と動き補償ユニット４４とは、いくつかの例では、機能的に統合されうる。動き補償ユニット４４は、現在のビデオ・ブロックのＰＵの動きベクトルを受け取ると、基準ピクチャ・リストのうちの１つにおいて動きベクトルが指し示す予測ブロックを位置決めしうる。加算器５０は、以下に示すように、予測ブロックのピクセル値を、コーディングされている現在のビデオ・ブロックのピクセル値から引くことによって、ピクセル差分値を生成する。一般に、動き推定ユニット４２は、輝度成分に対する動き推定を実行し、動き補償ユニット４４は、彩度成分と輝度成分との両方のために、輝度成分に基づいて計算された動きベクトルを用いる。また、モード選択ユニット４０は、ビデオ・スライスのビデオ・ブロックをデコードする際に、ビデオ・デコーダ３０によって使用されるための、ビデオ・ブロックおよびビデオ・スライスに関連付けられたシンタックス要素を生成しうる。

イントラ予測ユニット４６は、前述されたように、動き推定ユニット４２および動き補償ユニット４４によって実行されるインタ予測に対する代替として、現在のブロックをイントラ予測または計算しうる。特に、イントラ予測ユニット４６は、現在のブロックをエンコードするために使用するための、イントラ予測モードを決定しうる。いくつかの例において、イントラ予測ユニット４６は、例えば、個別のエンコーディング・パスの間、さまざまなイントラ予測モードを用いて現在のブロックをエンコードし、イントラ予測ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから、使用する適切な予測モードを選択しうる。

例えば、イントラ予測ユニット４６は、テストされたさまざまなイントラ予測モードのためのレート歪み値を、レート歪み分析を用いて計算し、テストされたモードのうち最良のレート歪み特性を有するイントラ予測モードを選択しうる。レート歪み分析は、一般に、エンコードされたブロックと、エンコードされたブロックを生成するためのエンコードされた、オリジナルのエンコードされていないブロックとの間の歪み（または誤差）の量のみならず、エンコードされたブロックを生成するために使用されるビットレート（すなわち、ビット数）をも決定する。イントラ予測ユニット４６は、どのイントラ予測モードが、ブロックのために最良のレート歪み値（または、最低のコスト値）を示すのかを判定するために、エンコードされたさまざまなブロックのレートおよび歪みからコスト値を計算しうる。

ブロックのためにイントラ予測モードを選択した後、イントラ予測ユニット４６は、ブロックのために選択されたイントラ予測モードを示す情報を、エントロピ・エンコーディング・ユニット５６へ提供しうる。エントロピ・エンコーディング・ユニット５６は、選択されたイントラ予測モードを示す情報をエンコードしうる。ビデオ・エンコーダ２０は、送信されるビット・ストリームに、コンフィギュレーション・データを含めうる。これは、複数のイントラ予測モード・インデクス・テーブルおよび複数の修正されたイントラ予測モード・インデクス・テーブル（これらは、コードワード・マッピング・テーブルとも称される）、さまざまなブロックのエンコード・コンテキストの定義、最も確実性の高いイントラ予測モードを示すインジケーション、イントラ予測モード・インデクス・テーブル、および、コンテキストのおのおのを使用するための修正されたイントラ予測モード・インデクス・テーブルを含みうる。

ビデオ・エンコーダ２０は、コーディングされているオリジナルのビデオ・ブロックから、モード選択ユニット４０からの予測データを引くことにより、残余ビデオ・ブロックを生成する。加算器５０は、この減算演算を実行する構成要素（単数または複数）を表す。変換処理ユニット５２は、例えば離散コサイン変換（ＤＣＴ）または概念的に類似した変換のような変換を、残余ブロックに適用し、残余変換係数値を備えるビデオ・ブロックが生成される。変換処理ユニット５２は、概念的にＤＣＴに類似したその他の変換を実行しうる。ウェーブレット変換、整数変換、サブ帯域変換、またはその他のタイプの変換もまた使用されうる。何れの場合も、変換処理ユニット５２は、この変換を残余ブロックに適用し、残余変換係数のブロックが生成される。この変換は、残余情報を、ピクセル値領域から、例えば周波数領域のような変換領域に変換しうる。

変換処理ユニット５２は、結果として得られた変換係数を量子化ユニット５４へ送信しうる。量子化ユニット５４は、さらにビット・レートを低減するために、この変換係数を量子化する。この量子化処理は、これら係数のうちのいくつかまたはすべてに関連付けられたビット・デプスを低減しうる。量子化の程度は、量子化パラメータを調節することにより修正されうる。いくつかの例では、その後、量子化ユニット５４は、量子化された変換係数を含むマトリックスのスキャンを実行しうる。あるいは、エントロピ・エンコード・ユニット５６が、このスキャンを実行しうる。

量子化の後、エントロピ・エンコード・ユニット５６は、量子化された変換係数を、エントロピ・コーディングする。例えば、エントロピ・エンコーディング・ユニット５６は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応バイナリ計算コーディング（ＣＡＢＡＣ）、シンタックス・ベースのコンテキスト適応バイナリ演算コーディング（ＳＢＡＣ）、確率インタバル分割エントロピ（ＰＩＰＥ）コーディング、またはその他のエントロピ・コーディング技法を実行しうる。コンテキスト・ベースのエントロピ・コーディングのケースでは、コンテキストは、近隣のブロックに基づきうる。エンコードされたビット・ストリームは、エントロピ・エンコーディング・ユニット５６によるエントロピ・コーディング後、（例えばビデオ・デコーダ３０のような）別のデバイスへ送信されうるか、または、後の送信または取得のためにアーカイブされうる。

逆量子化ユニット５８および逆変換ユニット６０は、例えば、基準ブロックとして後に使用するために、逆量子化または逆変換をそれぞれ適用し、ピクセル領域内の残余ブロックを再構築しうる。動き補償ユニット４４は、残余ブロックを、基準フレーム・メモリ６４のフレームのうちの１つの予測ブロックへ加えることによって、基準ブロックを計算しうる。動き補償ユニット４４はまた、動き推定において使用するための整数未満のピクセル値を計算するために、１または複数の補間フィルタを、再構築された残余ブロックに適用しうる。加算器６２は、動き補償ユニット４４によって生成された動き補償予測ブロックに、再構築された残余ブロックを加え、基準フレーム・メモリ６４に格納するための再構築されたビデオ・ブロックが生成される。再構築されたビデオ・ブロックは、その後のビデオ・フレームにおけるブロックをインタ・コーディングするために、動き推定ユニット４２および動き補償ユニット４４によって、基準ブロックとして使用されうる。

このように、図３のビデオ・エンコーダ２０は、本開示の技法を実行するように構成されたビデオ・エンコーダの例を表わす。例えば、ビデオ・エンコーダ２０は、最終的な予測子を生成するために、ベース・レイヤ予測子とエンハンスメント・レイヤ予測子とを結合しうる。そして、最終的な予測子に基づいて、現在のエンハンスメント・レイヤ・ブロックのためのインタ・レイヤ予測を実行しうる。インタ・レイヤ予測を実行することは、インタ・レイヤ・テクスチャ予測を実行することを含みうる。ベース・レイヤ予測子およびエンハンスメント・レイヤ予測子を結合する場合、ビデオ・エンコーダ２０は、第１の重み付け係数をベース・レイヤ予測子に割り当て、第２の重み付け係数をエンハンスメント・レイヤ予測子に割り当てる。

図４は、本開示に記載された態様にしたがって技法を実施しうるビデオ・デコーダの例を例示するブロック図である。ビデオ・デコーダ３０は、本開示の技法のうちの何れかまたはすべてを実行するように構成されうる。一例として、動き補償ユニット７２および／またはイントラ予測ユニット７４は、例えば、ピクセル位置、ＢＬ特性およびＥＬ特性等に基づいてＢＬ重みおよびＥＬ重みを決定することのように、本開示に記載された技法の何れかまたはすべてを実行するように構成されうる。しかしながら、本開示の態様は、そのように限定されない。いくつかの例において、本開示に記載された技法は、ビデオ・デコーダ３０のさまざまな構成要素間で共有されうる。いくつかの例では、それに加えて、または、その代わりに、プロセッサ（図示せず）は、本開示に記載された技法のうちの何れかまたはすべてを実行するように構成されうる。

図４の例では、ビデオ・デコーダ３０は、エントロピ・デコード・ユニット７０、動き補償ユニット７２、イントラ予測ユニット７４、逆量子化ユニット７６、逆変換ユニット７８、基準フレーム・メモリ８２、および加算器８０を含んでいる。ビデオ・デコーダ３０は、いくつかの例において、ビデオ・エンコーダ２０（図３Ａ）に関して記載されたエンコード・パスに対して一般に逆であるデコード・パスを実行しうる。動き補償ユニット７２は、エントロピ・デコード・ユニット７０から受け取った動きベクトルに基づいて、予測データを生成しうる一方、イントラ予測ユニット７４は、エントロピ・デコード・ユニット７０から受け取ったイントラ予測モード・インジケータに基づいて、予測データを生成しうる。

デコード処理中、ビデオ・デコーダ３０は、関連付けられたシンタックス要素とエンコードされたビデオ・スライスのビデオ・ブロックを示す、エンコードされたビデオ・ビットストリームを、ビデオ・エンコーダ２０から受け取る。ビデオ・デコーダ３０のエントロピ・デコード・ユニット７０は、量子化された係数、動きベクトルまたはイントラ予測モード予測子、およびその他のシンタックス要素を生成するために、ビット・ストリームをエントロピ・デコードする。エントロピ・デコード・ユニット７０は、動きベクトルおよびその他のシンタックス要素を、動き補償ユニット７２へ転送する。ビデオ・デコーダ３０は、ビデオ・スライス・レベルおよび／またはビデオ・ブロック・レベルにおいて、シンタックス要素を受け取りうる。

ビデオ・スライスが、イントラ・コード（Ｉ）スライスとしてコーディングされた場合、イントラ予測ユニット７４は、現在のフレームまたはピクチャの、以前にデコードされたブロックからの、シグナルされたイントラ予測モードおよびデータに基づいて、現在のビデオ・スライスのビデオ・ブロックの予測データを生成しうる。ビデオ・フレームが、インタ・コードされた（例えば、Ｂ、Ｐ、またはＧＰＢ）スライスとしてコーディングされている場合、動き補償ユニット７２は、エントロピ・デコード・ユニット７０から受け取られた動きベクトルおよびその他のシンタックス要素に基づいて、現在のビデオ・スライスのビデオ・ブロックの予測ブロックを生成する。予測ブロックは、基準ピクチャ・リストのうちの１つ内の、基準ピクチャのうちの１つから生成されうる。ビデオ・デコーダ３０は、基準フレーム・メモリ９２に格納された基準ピクチャに基づいて、デフォルトの構築技法を用いて、基準フレーム・リストであるリスト０およびリスト１を構築しうる。動き補償ユニット７２は、動きベクトルおよびその他のシンタックス要素を解析することによって、現在のビデオ・スライスのビデオ・ブロックの予測情報を決定し、この予測情報を用いて、デコードされている現在のビデオ・ブロックの予測ブロックを生成する。例えば、動き補償ユニット７２は、受け取ったシンタックス要素のうちのいくつかを用いて、ビデオ・スライスのビデオ・ブロック、インタ予測スライス・タイプ（例えば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）、スライスのための基準ピクチャ・リストのうちの１または複数の構築情報、スライスの各インタ・エンコード・ビデオ・ブロックの動きベクトル、スライスの各インタ・コード・ビデオ・ブロックのインタ予測状態、および、現在のビデオ・スライスにおけるビデオ・ブロックをデコードするためのその他の情報、をコーディングするために使用される予測モード（例えば、イントラ予測またはインタ予測）を決定する。

動き補償ユニット７２はまた、補間フィルタに基づいて、補間を実行しうる。動き補償ユニット７２は、基準ブロックの整数未満ピクセルの補間値を計算するために、ビデオ・ブロックのエンコード中、ビデオ・エンコーダ２０によって使用されるような補間フィルタを使用しうる。このケースでは、動き補償ユニット７２は、受け取られたシンタックス要素から、ビデオ・エンコーダ２０によって使用される補間フィルタを決定し、この補間フィルタを用いて、予測ブロックを生成する。

逆量子化ユニット７６は、ビット・ストリームで提供され、エントロピ・デコード・ユニット８０によってデコードされた、量子化された変換係数を逆量子化、すなわちｄｅ ｑｕａｎｔｉｚｅする。逆量子化処理は、量子化の程度、および、適用されるべき逆量子化の程度も同様に決定するために、ビデオ・スライスにおけるおのおののビデオ・ブロックについて、ビデオ・デコーダ３０によって計算される量子化パラメータ（ＱＰＹ）を使用することを含みうる。

逆変換ユニット７８は、ピクセル領域における残余ブロックを生成するために、例えば、逆ＤＣＴ、逆整数変換、または概念的に同様な逆変換処理を変換係数に適用する。

動き補償ユニット８２が、動きベクトルおよびその他のシンタックス要素に基づいて、現在のビデオ・ブロックの予測ブロックを生成した後、ビデオ・デコーダ３０は、逆変換ユニット７８からの残余ブロックと、動き補償ユニット７２によって生成された対応する予測ブロックとを総和することによって、デコードされたビデオ・ブロックを生成する。加算器９０は、この総和演算を実行する構成要素（単数または複数）を表わす。所望されるのであれば、ブロッキネス・アーティファクトを除去するために、デブロッキング・フィルタも適用され、デコードされたブロックがフィルタされる。その他のループ・フィルタ（コーディング・ループ中の、またはコーディング・ループ後の何れか）もまた、ピクセル推移を平滑化するために、あるいは、ビデオ品質を改善するために、使用されうる。所与のフレームまたはピクチャ内の、デコードされたビデオ・ブロックは、その後、基準ピクチャ・メモリ９２に格納される。基準ピクチャ・メモリ９２は、その後の動き補償のために使用される基準ピクチャを格納する。基準フレーム・メモリ８２はまた、例えば、図１のディスプレイ・デバイス３２のような、ディスプレイ・デバイスにおける後の表示のために、デコードされたビデオを格納する。

このように、図４のビデオ・デコーダ３０は、本開示の技法を実行するように構成されたビデオ・デコーダの例を表わす。例えば、ビデオ・デコーダ３０は、最終的な予測子を生成するために、ベース・レイヤ予測子とエンハンスメント・レイヤ予測子とを結合しうる。そして、最終的な予測子に基づいて、現在のエンハンスメント・レイヤ・ブロックのためのインタ・レイヤ予測を実行しうる。インタ・レイヤ予測を実行することは、インタ・レイヤ・テクスチャ予測を実行することを含みうる。ベース・レイヤ予測子およびエンハンスメント・レイヤ予測子を結合する場合、ビデオ・デコーダ３０は、第１の重み付け係数をベース・レイヤ予測子に割り当て、第２の重み付け係数をエンハンスメント・レイヤ予測子に割り当てる。いくつかの事例では、第１の重み付け係数は、ベース・レイヤ予測子のすべてのピクセルに対して一定であり、第２の重み付け係数は、ベース・レイヤ予測子のすべてのピクセルに対して一定でありうる。

ビデオ・デコーダ３０は、とりわけ、デコードされているエンハンスメント・レイヤ・ブロック内のピクセルの特性と、ＢＬ予測子およびＥＬ予測子の特性とから、これら重み付け係数を決定しうる。ビデオ・デコーダ３０は、前述したように、ビデオ・エンコーダ２０のものと同様の方式で、これら重み付け係数を決定するように構成されうる。このように、ビデオ・デコーダ３０は、例えば、どの重みを使用するのかに関するデータのような、追加のデータを必要とすることなく、ビデオ・ブロックをエンコードするために必要とされていたものと同じまたは実質的に類似したパラメータを決定しうる。

ビデオ・エンコーダ２０に関して前述したように、第１の重み付け係数は、ピクセル位置の関数として変動し、第２の重み付け係数は、ピクセル位置の関数として変動しうる。例えば、現在のエンハンスメント・レイヤ・ブロックの境界または境界の近傍におけるピクセルの場合、第２の重み付け係数は、第１の重み付け係数よりも大きくなりうる。例えば、現在のエンハンスメント・レイヤ・ブロックの境界に無い、または境界の近傍に無いピクセルの場合、第１の重み付け係数は、第２の重み付け係数よりも大きくなりうる。何が境界の近傍を構成しているかの判定は、現在のエンハンスメント・レイヤ・ブロックのイントラ予測方向に基づいて、ビデオ・デコーダ３０によって判定されうる。

ビデオ・デコーダ３０はまた、現在のエンハンスメント・ブロックの境界とピクセルとの間の距離の関数として、第１の重み付け係数を決定しうる。第２の重み付け係数は、一般に、境界に近いピクセルについて増加し、第１の重み付け係数は、一般に、境界から離れたピクセルについて増加しうる。

ビデオ・デコーダ３０はまた、図３に関して前述したものと同様に、ベース・レイヤ予測子の量子化パラメータと、エンハンスメント・レイヤ予測子の量子化パラメータとに基づいて、第１の重み付け係数および第２の重み付け係数を決定しうる。

ビデオ・デコーダ３０はまた、スケーリング比に基づいて、第１の重み付け係数および第２の重み付け係数を選択しうる。例えば、より大きなスケーリング比は、一般に、第２の重み付け係数のためのより高い値に対応しうる。

図５に移って、Ｈ．２６４コーダにおいて使用される空間予測（すなわち、イントラ予測）の例が、以下に記載される。空間予測を実行するために、Ｈ．２６４コーダは、４×４ブロックの予測のために９つのモードを提供する。これらは、ＤＣ予測（モード０）と、図５に図示されるようにラベル１乃至８が付された８方向のモードを含む。この予測処理は、図６に例示される。図６に図示するように、ブロック６００におけるａからｐまでのピクセルがエンコードされるべきであり、近隣ブロック６０２−６０８からのピクセルＡ乃至Ｒは、すでにエンコードされており、予測のために使用されうる。例えば、モード１が選択されると、ピクセルａ，ｅ，ｉ，およびｍをピクセルＡに等しく設定することにより、ピクセルａ，ｅ，ｉ，およびｍが予測され、ピクセルｂ，ｆ，ｊ，およびｎをピクセルＢに等しく設定することにより、ピクセルｂ，ｆ，ｊ，およびｎが予測されるという具合である。同様に、モード２が選択されると、ピクセルａ，ｂ，ｃ，およびｄをピクセルＩに等しく設定することにより、ピクセルａ，ｂ，ｃ，およびｄが予測され、ピクセルｅ，ｆ，ｇ，およびｈをピクセルＢに等しく設定することにより、ピクセルｅ，ｆ，ｇ，およびｈが予測されるという具合である。したがって、この例において、モード１は、垂直方向における予測子であり、モード２は、水平方向における予測子である。

図５および図６に例示された例およびイントラ・モード定義は、例示のみであり、限定することは意図されていない。その他のイントラ・モード定義は、例えばＨＥＶＣにおけるもののように使用されうる。ＨＥＶＣでは、予測モードの数が、さらに増加される。例えば、４×４ブロック、８×８ブロック、およびそれより大きなブロックについて、３５の予測モードがそれぞれ利用可能である。ＨＥＶＣにおける各モードのために定義されたモード・インデクスは、異なりうる。例えば、ＨＥＶＣでは、平面予測がモード０として、ＤＣ予測がモード１として定義される。

イントラＢＬモードにおいて記載されているように、インタ・レイヤ・テクスチャ予測では、ベース・レイヤ・ブロックから再構築されたテクスチャが、対応するエンハンスメント・レイヤ・ブロックのテクスチャを予測するための予測子として使用されうる。しかしながら、いくつかのケースでは、ベース・レイヤ・ブロックからの、再構築されたテクスチャにおけるピクセルのすべてが、エンハンスメント・レイヤ・ブロックにおける対応するピクセルのための最良の、または、好適な予測子であるという訳ではない。当該技術分野内の現在のスキームは、エンハンスメント・レイヤ・ブロックのための予測子を生成する際に、ピクセルの一部のみを用いたり、または、ベース・レイヤからのピクセルの一部の重み付けを下げるような柔軟性を提供しない。本開示は、このような柔軟性によって、より良好なコーディング効率を達成することを可能にするための技法を記載している。

いくつかの実施形態では、複数の予測子の、一定の重み付けがなされた結合が、使用されうる。このような技法によれば、最終的な予測子Ｐｆを生成するために、ＥＬ予測子ＰｅおよびＢＬ予測子Ｐｂが結合された場合、いくつかの重みが、ＥＬ予測子ＰｅおよびＢＬ予測子Ｐｂに割り当てられうる。このような重みは、予測子内のすべてのピクセルに一定でありうる。例えば、最終的な予測子は、以下の式に基づいて生成されうる。
Ｐｆ＝ｃ１＊Ｐｂ＋ｃ２＊Ｐｅ （１）
式（１）では、ｃ１およびｃ２は、重み係数を表わす。ｃ１とｃ２との総和は、例えば１のような一定値に等しくなりうる。ｃ１およびｃ２の両方は、ＰｂおよびＰｅ内のすべてのピクセルについて一定値を維持しうる。

いくつかの実施形態では、各予測子の重み付け係数は、一定の重みを用いるのではなく、ピクセル位置に基づいて変動しうる。例えば、重み付け係数は、予測子内の異なるピクセル位置については、異なりうる。より具体的には、最終的な予測子が、以下の式に基づいて生成されうる。
Ｐｆ［ｉ，ｊ］＝ｃ１［ｉ，ｊ］＊Ｐｂ［ｉ，ｊ］＋ｃ２［ｉ，ｊ］＊Ｐｅ［ｉ，ｊ］ （２）
式（２）では、ｉおよびｊが、予測子内の２次元座標を表わし、それぞれ行および列を示す。重み付けパラメータｃ１，ｃ２は、異なる位置［ｉ，ｊ］においては、異なりうる。しかしながら、ｃ１［ｉ，ｊ］およびｃ２［ｉ，ｊ］の合計は、例えば１のような一定値に等しくなりうる。式（２）に基づくと、ｃ１［ｉ，ｊ］＝１およびｃ２［ｉ，ｊ］＝０であれば、最終的な予測子における対応するピクセルは、ＢＬ予測子内のピクセルから完全に生成される。あるいは、ｃ１［ｉ，ｊ］＝０およびｃ２［ｉ，ｊ］＝１であれば、最終的な予測子における対応するピクセルは、ＥＬ予測子におけるピクセルから完全に生成される。

いくつかの実施形態では、ＥＬ予測子がイントラ予測子を用いて生成される場合、現在のＥＬレイヤ・ブロック（例えば、現在コーディングされているブロック）の境界において、かつ、再構築されたピクセルの近隣ブロックの近くに位置するＥＬ予測子におけるピクセルは、最終的な予測子を生成するためにＢＬ予測子と結合されるのであれば、より高い重みが与えられうる。その他のピクセル位置については、より高い重みが、ＢＬ予測子からのピクセルに与えられうる。

エンハンスメント・レイヤにおいて再構築されたピクセルは、一般に、ベース・レイヤ内の対応するピクセルよりもより正確である（例えば、オリジナルのピクセル値により近い値を有する）。その結果、近隣のピクセルの間の強い相関によって、ＥＬ予測子では、より高い品質の予測子を生成するために、近隣ブロックの再構築されたピクセルの近くに位置するピクセルが使用されうる（例えば、ＥＬ予測子は、対応するＢＬ予測子よりも高い重みを与えられうる）。しかしながら、予測のために使用される、近隣ブロックが再構築したピクセルから遠く離れて位置するＥＬ予測子における他のピクセルの場合、いくつかの事例において予測品質がより低くなりうる。これらの実例では、ＢＬ予測子は、より高い品質の最終的な予測子を生成するために使用されうる（例えば、ＢＬ予測子は、対応するＥＬ予測子よりも高い重みを与えられうる）。

このアイデアは、図７に例示される。図７において、ＥＬブロック７００は、予測されコーディングされるべき現在のＥＬブロックである。（“／”線模様で印された）エリア７２０は、現在のＥＬブロック７００の予測のために使用されうる近隣のＥＬブロック７０２−７０８の再構築されたピクセル・エリアである。陰付きで示されるエリア７１０は、近隣のＥＬブロック７０２−７０８の近くのエリアであり、ここでは、相対的に高い重み付けが、ＥＬ予測子に割り当てられうる。例えば、式（２）に基づくと、陰付きエリア７１０におけるピクセルについて、ｃ１［ｉ，ｊ］は０．５未満であり、ｃ２［ｉ，ｊ］は０．５よりも大きくなりうる。陰付きエリア７１０内の近隣のＥＬブロック７０２−７０８の境界におけるピクセルの場合、ｃ１［ｉ，ｊ］は０の値を取り、ｃ２［ｉ，ｊ］は１の値を取り、これによって、最終的な予測子における予測値は、これらピクセルのＥＬ予測子に完全に基づくようになる。

図７に図示されるケースは、例のみであり、限定することは意図されていない。実際、陰付きエリア７１０の形状は、例えば、現在のブロック７００のために選択されたイントラ予測方向に基づいて、適応的に定義されうる。図８Ａおよび図８Ｂは、陰付きエリアが異なって定義されうるその他２つの例を例示する。図８Ａは、予測方向が垂直であるケースを例示する。このケースでは、実質的に、垂直方向の近隣ＥＬブロックの境界またはその近傍の陰付きエリア８１０ａにおけるピクセルの場合、ＥＬ予測子に、より高い重みが与えられうる。図８Ｂは、予測方向が、水平である場合の例を示す。このケースでは、実質的に、水平方向の近隣ＥＬブロックの境界またはその近傍の陰付きエリア８１０ｂにおけるピクセルの場合、ＥＬ予測子に、より高い重みが与えられうる。

前述した例では、陰付きエリアが示されているが、重み付けパラメータは、陰付きエリアの内部または外部でも変動しうる。陰付きエリアは、最終的な予測子を生成する際に、ＢＬ予測子よりもＥＬ予測子により高いが与えられうる領域を例示するための例としてのみ使用される。いくつかの実施形態では、あるピクセル位置の重み付け係数が、予測のために使用される対応するより広いピクセルからのピクセル位置の本質的な距離およびイントラ予測方向に基づいて決定されうる。例えば、あるピクセル位置のための、より短い距離のために、ＥＬ予測子内の対応するピクセルに、より高い重み付け係数が割り当てられうる。

さらなる実施形態では、量子化パラメータまたは空間スケーリング比に基づいた複数の予測子の重み付けられた結合が、使用されうる。ベース・レイヤおよびエンハンスメント・レイヤからの予測子を結合するための係数（例えば、重み付けパラメータ）を決定する際にも、量子化パラメータ（ＱＰ）が考慮されうる。一般に、ＱＰ値がより低くなると、予測子の品質がより高くなる。その結果、エンハンスメント・レイヤ・ブロックが、ベース・レイヤ・ブロックにおいて使用されるものよりも著しく低いＱＰを有するのであれば、現在のエンハンスメント・レイヤ・ブロックのための最終的な予測子を生成する際に、ＥＬ予測子に、より高い重み付けが割り当てられうる。例えば、重み付けパラメータを決定する際の係数として、ベース・レイヤ・ブロックとエンハンスメント・レイヤ・ブロックとの間のＱＰ差分が、使用されうる。

重み付けパラメータを決定する場合、空間スケーリング比も考慮されうる。空間スケーラビリティでは、エンハンスメント・フレームが、ベース・レイヤ・フレームよりもより高い空間解像度を有する。このケースでは、ベース・レイヤが再構築したテクスチャは、それにしたがって、対応するエンハンスメント・レイヤ・ブロックのための予測子として使用されうる前に、アップ・サンプルされねばならない。テクスチャ品質は、アップサンプリング処理中に品質を下げられうる。より大きなスケーリング比は、一般に、品質がより大きく低下するという結果をもたらす。したがって、スケーリング比は、重み付けパラメータを決定する際の係数として考慮されうる。一般に、スケーリング比がより大きくなると、最終的な予測子を生成する際に、より高い重みがＥＬ予測子に割り当てられうる。

ここまで記載された技法のために、重み付けパラメータが、いくつかの条件またはコンテキストに暗黙的に依存して決定または導出されうる。このように、重み付けパラメータを導出するために、エンコーダとデコーダとの両方が、同じスキームを使用する場合、重み付けパラメータのための、エンコーダからデコーダへの、さらなるシグナリングは必要とされない。

前述したように、重み付けパラメータを暗黙的に導出するために使用される条件またはコンテキストは、イントラ予測方向（または、イントラ・モード）、予測のために使用される対応する境界ピクセルからのピクセル位置の距離、ベース・レイヤＱＰおよびエンハンスメント・レイヤＱＰ、のみならず、異なるレイヤ間の空間スケーリング比を含みうる。例えば、動きベクトル差分、ブロック・サイズ等のようなその他の要因も使用されうる。

重み付けパラメータの暗黙的な導出に対する代替手段として、エンコーダはまた、重み付けパラメータを決定するためのある情報を、デコーダへシグナルしうる。例えば、エンコーダは、重み付けパラメータがどのようにして計算されるべきであるかを示すために、現在のブロックにおける座標をシグナルしうる。

例が図９に提供される。イントラ予測方向が垂直である場合、行座標９１０が、デコーダにシグナルされ、ＥＬ予測子とＢＬ予測子とに等しい重み（例えば、０．５）が割り当てられる場所が示される。先頭行が、ＥＬ予測子から１の重み（すなわち、ＢＬ予測子から０の重み）を有し、最終行が、ＢＬ予測子から１の重み（すなわち、ＥＬ予測子から０の重み）を有すると仮定すると、それにしたがって、現在のエンハンスメント・レイヤ・ブロック９００内のその他すべてのピクセル位置の重み付けパラメータが、例えば線形補間のようなあるスキームに基づいて補間されうる。予測方向が水平方向である場合、同じ技法が適用されうる。そのような考えは、２次元のケースに拡張されうる。いくつかの実施形態では、行座標と列座標との両方が、デコーダにシグナルされ、これによって、重み付けパラメータの補間が、２次元方式で実行されるようになる。いくつかの実施形態では、行座標および／または列座標は、ＢＬ予測子およびＥＬ予測子に与えられた重みが均等であるポイントを示さないが、代わりに、ＢＬ予測子またはＥＬ予測子の何れかの重みが、最終的な予測子のための全体的な基礎を形成するポイントを示しうる。そのような場合、これら位置の残りに割り当てられた重みが同様に推論されうる。

図１０に移って、ビデオをコーディングするための例示的な処理が記載されるだろう。この処理は、例えばソース・デバイス１２または宛先デバイス１４のような、本明細書に記載されたデバイスのうちの１または複数で実施されうる。

この処理は、デジタル・ビデオの第１のレイヤと、デジタル・ビデオの第２のレイヤとが受け取られるブロック１００２において始まる。宛先デバイス１４またはその他のあるデコーダによって実施される場合、レイヤは、有線手段および／または無線手段（例えば、ＵＳＢ、ＰＳＴＮ、イーサネット（登録商標）、セルラ、衛星、ＷｉＦｉ、ブルートゥース（登録商標）等）によって、デジタル信号として送信されうる。これらレイヤは、個別に、または、同じ送信の一部として受信されうる。いくつかの実施形態では、レイヤは、ソース・デバイス１２からダイレクトに受け取られうるか、または、１または複数の介在を介してソース・デバイスから受け取られ得る。また、レイヤまたはその一部は、複数のソース・デバイスから受け取られうる。また、受取処理は、受け取られたレイヤを、メモリに格納することを含みうる。

いくつかの実施形態では、この処理は、ソース・デバイス１２またはその他いくつかのエンコーダによって実施されうる。いくつかのケースでは、第１のレイヤおよび第２のレイヤを含むデジタル・ビデオが、メモリから取得されうる（例えば、ディスク、ＤＶＤ、ブルー・レイ等に格納されたビデオ）。メモリは、この処理を実施するデバイスに含まれうる。あるいは、メモリは、この方法を実施するデバイスにアクセス可能な個別のデバイス（例えば、ネットワーク・ストレージ）でありうる。いくつかの実施形態では、デジタル・ビデオは、センサ（例えばカメラ）から取得されうる。

ブロック１００４では、この処理を実施するデバイスは、第１のレイヤに関連付けられた予測子（例えば、ベース・レイヤ予測子）および第２のレイヤに関連付けられた予測子（例えば、エンハンスメント・レイヤ予測子）のための重みを決定しうる。例えば、宛先デバイス１４は、重み付けられたＥＬ予測子およびＢＬ予測子に基づいて、ビデオの特定のフレームからのエンハンスメント・ブロックをデコードしうる。近隣のＥＬブロックは、既にデコードされているかもしれない。この近隣のブロックの近くのピクセルについて、デコーダは、そのピクセルのＥＬ予測子に対して、対応するＢＬ予測子（例えば、ベース・レイヤにおいて連結された予測子）に対するよりも高い重みを割り当てうる。以前にデコードされた近隣のＥＬブロックから離れたピクセルの場合、デコーダは、このピクセルに対応するＢＬ予測子に対して、ＥＬ予測子に対するよりも高い重みを割り当てうる。ピクセル位置に基づいて、ＥＬ予測子およびＢＬ予測子に重みを割り当てる例示的な処理が、図１１に関して後述される。重みを決定する場合、その他の要因も考慮されうる。例えば、予測方向が考慮されうる。そのようなケースでは、近隣ブロックに近いが、現在の予測方向と揃っていないピクセルに関連付けられたＥＬ予測子は、必ずしも、対応するＢＬ予測子よりも大きな重みを割り当てられる必要はない場合がありうる。ＱＰ値、空間スケーリング比等を含むその他の要因もまた考慮されうる。ＥＬ特性およびＢＬ特性に基づいてＥＬ予測子およびＢＬ予測子に重みを割り合てるための例示的な処理が、図１２に関して後述される。

ブロック１００６では、この処理を実施するデバイスは、ブロック１００４で決定された重み付けられた予測子に基づいて、エンハンスメント・レイヤ・ビデオ・ユニット（例えば、ブロックまたはピクセル）をコーディングしうる。例えば、前述した式（１）および（２）にしたがって、特定のエンハンスメント・レイヤ・ピクセルをデコードするために使用される最終的な予測子は、ピクセルに対応するＥＬ予測子と、このＥＬ予測子に関連付けられた重みとの積、および、ピクセルに対応するＢＬ予測子と、このＢＬ予測子に関連付けられた重みとの積、に基づきうる。重み付けられたそれぞれの予測子が、総和され、特定のピクセルのための最終的な予測子が提供される。

図１１は、ＥＬブロックとのピクセル位置に基づいて、または、以前にコーディングされた近隣のＥＬブロックに対して、ＥＬ予測子およびＢＬ予測子に重みを割り当てるための処理を例示する。この処理は、例えば、ソース・デバイス１２のビデオ・エンコーダ２０または宛先デバイス１４のビデオ・デコーダのような、本明細書に記載されたデバイスのうちの１または複数で実施されうる。

この処理は、ＥＬにおける特定のピクセルの位置が決定されるブロック１１０２において始まる。特に、現在のＥＬブロックのために使用されている予測方向における、その位置から、以前にコーディングされたＥＬブロック（例えば、現在コーディングされているＥＬブロックに隣接したＥＬブロック）におけるピクセルへの距離は、ＥＬ予測子に与えられた重みに対して逆比例しうる。

ブロック１１０４において、この処理を実行するデバイスは、上記で決定されたように、その位置、および、以前にコーディングされたＥＬブロックからの距離に基づいて、現在のピクセル（または行、または列）のＥＬ予測子に重みを割り当てうる。例示的に、ＥＬ予測子に割り当てられる重みは、１に近いか、１に等しくなりうる。ここで、現在のピクセルは、予測方向において以前にコーディングされているピクセルに対する直接的な近隣である。予測方向において、以前にコーディングされているピクセルと現在のピクセルとの間の距離が増加すると、ＥＬ予測子は、より小さくなるか、または、ゼロに近づきうる。

ブロック１１０６では、この処理を実行するデバイスが、ＥＬ予測子に割り当てられた重みに基づいて、ＢＬ予測子に重みを割り当てうる。例示的に、任意のピクセルのＥＬ予測子およびＢＬ予測子に割り当てられる重みは、総和されると、例えば１のような一定値になりうる。いくつかの実施形態では、ＢＬ予測子の重みが、現在のＥＬピクセルの位置に基づいて割り当てられ、ＥＬ予測子に割り当てられる重みは、ＢＬ予測子に割り当てられた重みに基づく。

ブロック１１０８では、この処理を実行するデバイスは、ピクセル位置を決定することと、現在のＥＬブロックにおける各ピクセルの位置に基づいて重みを割り当てることとの処理を反復しうる。

図１２は、ベース・レイヤおよびエンハンスメント・レイヤの特性に基づいて、ＢＬ予測子重みおよびＥＬ予測子重みを決定または割り当てる処理を例示する。この処理は、例えばソース・デバイス１２または宛先デバイス１４のように、本明細書に記載されたデバイスのうちの１または複数で実施されうる。

この処理は、ベース・レイヤおよびエンハンスメント・レイヤの関連する特性が決定されるブロック１２０２で始まる。これら特性は、量子化パラメータ、スケーリング・ファクタ、または、重み予測子に関連するその他いくつかの特性でありうる。

ブロック１２０４では、ＥＬ予測子の重みが、上記のように決定された特性に基づいて決定または割り当てられうる。例えば、エンハンスメント・レイヤとベース・レイヤとの、スケーリング・ファクタまたは量子化パラメータの差分が大きいのであれば、比較的大きなＥＬ予測子重みが割り当てられうる。このような大きな差分は、例えば、ＢＬブロックの品質が、ＥＬブロックの品質よりも著しく低くなりうるので、以前にコーディングされているＥＬブロックが、ＢＬブロックよりも、現在のＥＬブロックについてより良好な予測子を提供することを示しうる。

ブロック１２０６では、この処理を実行するデバイスは、ＥＬ予測子に割り当てられた重みに基づいて、ＢＬ予測子に重みを割り当てうる。例示的に、ＥＬ予測子およびＢＬ予測子に割り当てられた重みは、総和されると、例えば１のような一定値になりうる。いくつかの実施形態では、ＢＬ予測子の重みは、ＥＬブロックおよびＢＬブロックの特性に基づいて割り当てられ、ＥＬ予測子に割り当てられた重みは、ＢＬ予測子に割り当てられた重みに基づく。

１または複数の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせで実現されうる。ソフトウェアで実現されるのであれば、これら機能は、コンピュータ読取可能な媒体におけるコードまたは１または複数の命令群で送信されるか格納され、ハードウェア・ベースの処理ユニットによって実行されうる。コンピュータ読取可能な媒体は、コンピュータ読取可能な記憶媒体を含みうる。これは、例えばデータ記憶媒体のような有形な媒体、または、例えば通信プロトコルにしたがって、１つの場所から別の場所へのコンピュータ・プログラムの転送を容易にする任意の媒体を含む通信媒体に相当しうる。このように、コンピュータ読取可能な媒体は、一般に、（１）非一時的である有形のコンピュータ読取可能な記憶媒体、または、（２）例えば信号または搬送波のような通信媒体に対応しうる。データ記憶媒体は、本開示において記述された技術を実施するための命令群、コード、および／または、データ構造を検索するために１または複数のコンピュータまたは１または複数のプロセッサによってアクセスされうる任意の利用可能な媒体でありうる。コンピュータ・プログラム製品は、コンピュータ読取可能な媒体を含みうる。

例として、限定することなく、このようなコンピュータ読取可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶装置、磁気ディスク記憶装置またはその他の磁気記憶デバイス、フラッシュ・デバイス、あるいは、所望のプログラム・コード手段を命令群またはデータ構造の形式で搬送または格納するために使用され、しかも、コンピュータによってアクセスされうるその他任意の媒体を備えうる。さらに、いかなる接続も、コンピュータ読取可能な媒体として適切に称される。同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、デジタル加入者線（ＤＳＬ）、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術を使用して、ウェブサイト、サーバ、あるいはその他の遠隔ソースから命令群が送信される場合、同軸ケーブル、光ファイバ・ケーブル、ツイスト・ペア、ＤＳＬ、あるいは、例えば赤外線、無線およびマイクロ波のような無線技術が、媒体の定義に含まれる。しかしながら、コンピュータ読取可能な記憶媒体およびデータ記憶媒体は、コネクション、搬送波、信号、またはその他の過渡的な媒体を含まず、代わりに、非過渡的な、有形の記憶媒体に向けられていることが理解されるべきである。本明細書で使用されるディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクト・ディスク（ｄｉｓｃ）（ＣＤ）、レーザ・ディスク（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、およびブルー・レイ・ディスク（ｄｉｓｃ）を含む。これらｄｉｓｃは、レーザを用いてデータを光学的に再生する。それに対して、ｄｉｓｋは、通常、データを磁気的に再生する。前述した組み合わせもまた、コンピュータ読取可能な媒体の範囲内に含まれるべきである。

命令群は、例えば１または複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向けＩＣ（ＡＳＩＣ）、フィールド・プログラマブル・ロジック・アレイ（ＦＰＧＡ）、またはその他等価な集積またはディスクリート論理回路のような１または複数のプロセッサによって実行されうる。したがって、本明細書で使用されているように、用語「プロセッサ」は、前述した構成、または、本明細書に記載された技術の実施のために適切なその他任意の構成のうちの何れかを称しうる。さらに、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェア・モジュール内に適用されうるか、または、結合されたコーデック内に組み込まれうる。さらに、これら技法は、１または複数の回路または論理要素で完全に実現されうる。

本開示の技術は、無線ハンドセット、集積回路（ＩＣ）、またはＩＣのセット（例えば、チップセット）を含む種々さまざまなデバイスまたは装置において実現されうる。さまざまな構成要素、モジュール、またはユニットは、本開示では、開示された技術を実行するように構成されたデバイスの機能態様を強調するように記載されているが、異なるハードウェア・ユニットによる実現を必ずしも必要とする訳ではない。むしろ、前述されたように、さまざまなユニットは、適切なソフトウェアおよび／またはハードウェアと連携する、前述されたような１または複数のプロセッサを含む共通のハードウェア・ユニットの集合によって提供されうるか、コーデック・ハードウェア・ユニットに結合されうる。

さまざまな例が記載された。これらの例およびその他の例は、以下の特許請求の範囲のスコープ内である。
以下に出願時の特許請求の範囲に記載された発明を付記する。
［発明１］
デジタル・ビデオをコーディングする装置であって、
ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を格納するように構成されたメモリと、
前記メモリと通信するプロセッサとを備え、
前記プロセッサは、
前記ビデオ情報に少なくとも部分的に基づいて、前記ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、前記エンハンスメント・レイヤにおけるビデオ・ユニットに付けられた第２の重みとを決定し、
前記第１の重みと前記第２の重みとに少なくとも部分的に基づいて、前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングする
ように構成された、装置。
［発明２］
前記第１の重みおよび前記第２の重みのうちの少なくとも１つは１に等しくない、発明１に記載の装置。
［発明３］
前記プロセッサはさらに、最終的な予測子に少なくとも部分的に基づいて前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングするように構成され、
前記最終的な予測子は、前記第１の重みにしたがって重み付けられたベース・レイヤ予測子と、前記第２の重みにしたがって重み付けられたエンハンスメント・レイヤ予測子との結合を備える、発明１に記載の装置。
［発明４］
前記第１の重みと前記第２の重みとを総和すると、現在のエンハンスメント・レイヤ・ブロックのための最終的な予測子を決定するために結合されたベース・レイヤ予測子とエンハンスメント・レイヤ予測子とのすべてについて、予め決定された一定値となる、発明３に記載の装置。
［発明５］
以前にコーディングされたエンハンスメント・レイヤ・ブロックに対して、予測方向において実質的に隣接している、エンハンスメント・レイヤにおけるビデオ・ブロックについて、前記第２の重みは、前記第１の重みよりも大きい、発明１に記載の装置。
［発明６］
以前にコーディングされたエンハンスメント・レイヤ・ブロックから、予測方向において、最も離れたエンハンスメント・レイヤ・ブロックについて、前記第１の重みは、前記第２の重みよりも大きい、発明１に記載の装置。
［発明７］
前記ビデオ情報は、イントラ予測方向、ピクセル位置、量子化パラメータ、および空間スケーリング比のうちの１または複数を備える、発明１に記載の装置。
［発明８］
前記第２の重みは、前記ベース・レイヤの量子化パラメータＱＰ１と、前記エンハンスメント・レイヤの量子化パラメータＱＰ２との両方の関数として決定される、発明７に記載の装置。
［発明９］
前記第２の重みは一般に、ＱＰ１−ＱＰ２の値が増加すると増加する、発明８に記載の装置。
［発明１０］
前記第２の重みは、前記空間スケーリング比の関数として決定される、発明７に記載の装置。
［発明１１］
前記第２の重みは一般に、前記空間スケーリング比が増加すると増加する、発明１０に記載の装置。
［発明１２］
前記エンハンスメント・レイヤにおけるビデオ・ユニットは、現在のエンハンスメント・レイヤ・ブロックにおけるピクセルを備え、
前記第２の重みは、予測方向における近隣のエンハンスメント・レイヤ・ブロックの境界と前記ピクセルとの間の距離の関数として決定される、発明１に記載の装置。
［発明１３］
前記第２の重みは一般に、前記境界により近いピクセルについて増加し、前記第１の重みは一般に、前記境界からより遠いピクセルについて増加する、発明１２に記載の装置。
［発明１４］
前記ビデオ情報は、前記第１の重みおよび前記第２の重みを備えない、発明１に記載の装置。
［発明１５］
前記ビデオ情報は、前記第１の重みおよび前記第２の重みに関連する重み付けデータを備える、発明１に記載の装置。
［発明１６］
前記重み付けデータは、前記第１の重みおよび前記第２の重みが等しい、現在のエンハンスメント・レイヤ・ブロック内の位置を備える、発明１５に記載の装置。
［発明１７］
前記プロセッサはさらに、前記第１の重みおよび前記第２の重みが等しい位置に少なくとも部分的に基づいて、現在のエンハンスメント・レイヤ・ブロックに関連付けられた複数のビデオ・ユニットのために、前記第１の重みおよび前記第２の重みを決定するように構成された、発明１６に記載の装置。
［発明１８］
前記デジタル・ビデオをコーディングすることは、デジタル・ビデオをエンコードすることを備える、発明１に記載の装置。
［発明１９］
前記デジタル・ビデオをコーディングすることは、デジタル・ビデオをデコードすることを備える、発明１に記載の装置。
［発明２０］
デジタル・ビデオをコーディングする方法であって、
ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得することと、
前記ビデオ情報に少なくとも部分的に基づいて、前記ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、前記エンハンスメント・レイヤにおけるビデオ・ユニットに付けられた第２の重みとを決定することと、
前記第１の重みと前記第２の重みとに少なくとも部分的に基づいて、前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングすることと、
を備える方法。
［発明２１］
前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングすることは、最終的な予測子に少なくとも部分的に基づき、
前記最終的な予測子は、前記第１の重みにしたがって重み付けられたベース・レイヤ予測子と、前記第２の重みにしたがって重み付けられたエンハンスメント・レイヤ予測子との結合を備える、発明２０に記載の方法。
［発明２２］
前記第１の重みと前記第２の重みとを総和すると、現在のエンハンスメント・レイヤ・ブロックのための最終的な予測子を決定するために結合されたベース・レイヤ予測子とエンハンスメント・レイヤ予測子とのすべてについて、予め決定された一定値となる、発明２１に記載の方法。
［発明２３］
以前にコーディングされたエンハンスメント・レイヤ・ブロックに対して、実質的に隣接している、エンハンスメント・レイヤにおけるビデオ・ブロックについて、前記第２の重みは、前記第１の重みよりも大きい、発明２０に記載の方法。
［発明２４］
以前にコーディングされたエンハンスメント・レイヤ・ブロックから、最も離れたエンハンスメント・レイヤ・ブロックについて、前記第１の重みは、前記第２の重みよりも大きい、発明２０に記載の方法。
［発明２５］
前記ビデオ情報は、イントラ予測方向、ピクセル位置、量子化パラメータ、および空間スケーリング比のうちの１または複数を備える、発明２０に記載の方法。
［発明２６］
前記第２の重みは、前記ベース・レイヤの量子化パラメータＱＰ１と、前記エンハンスメント・レイヤの量子化パラメータＱＰ２との両方の関数として決定される、発明２５に記載の方法。
［発明２７］
前記第２の重みは一般に、ＱＰ１−ＱＰ２の値が増加すると増加する、発明２６に記載の方法。
［発明２８］
前記第２の重みは、前記空間スケーリング比の関数として決定される、発明２５に記載の方法。
［発明２９］
前記第２の重みは一般に、前記空間スケーリング比が増加すると増加する、発明２８に記載の方法。
［発明３０］
前記エンハンスメント・レイヤにおけるビデオ・ユニットは、現在のエンハンスメント・レイヤ・ブロックにおけるピクセルを備え、
前記第２の重みは、近隣のエンハンスメント・レイヤ・ブロックの境界と前記ピクセルとの間の距離の関数として決定される、発明２０に記載の方法。
［発明３１］
前記第２の重みは一般に、前記境界により近いピクセルについて増加し、前記第１の重みは一般に、前記境界からより遠いピクセルについて増加する、発明３０に記載の方法。
［発明３２］
前記ビデオ情報は、前記第１の重みおよび前記第２の重みを備えない、発明２０に記載の方法。
［発明３３］
前記ビデオ情報は、前記第１の重みおよび前記第２の重みに関連する重み付けデータを備える、発明２０に記載の方法。
［発明３４］
前記重み付けデータは、前記第１の重みおよび前記第２の重みが等しい、現在のエンハンスメント・レイヤ・ブロック内の位置を備える、発明３３に記載の方法。
［発明３５］
前記第１の重みおよび前記第２の重みが等しい位置に少なくとも部分的に基づいて、現在のエンハンスメント・レイヤ・ブロックに関連付けられた複数のビデオ・ユニットのために、前記第１の重みおよび前記第２の重みを決定すること、をさらに備える発明３４に記載の方法。
［発明３６］
装置のプロセッサによって実行可能な命令群を備えるコンピュータ読取可能な記憶媒体であって、
前記命令群は前記装置に対して、
ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得することと、
前記ビデオ情報に少なくとも部分的に基づいて、前記ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、前記エンハンスメント・レイヤにおけるビデオ・ユニットに付けられた第２の重みとを決定することと、
前記第１の重みと前記第２の重みとに少なくとも部分的に基づいて、前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングすることと
を実行させる、コンピュータ読取可能な記憶媒体。
［発明３７］
ビデオをコーディングする装置であって、
ベース・レイヤおよび対応するエンハンスメント・レイヤに関連付けられたビデオ情報を取得する手段と、
前記ビデオ情報に少なくとも部分的に基づいて、前記ベース・レイヤにおけるビデオ・ユニットに関連付けられた第１の重みと、前記エンハンスメント・レイヤにおけるビデオ・ユニットに付けられた第２の重みとを決定する手段と、
前記第１の重みと前記第２の重みとに少なくとも部分的に基づいて、前記エンハンスメント・レイヤにおけるビデオ・ユニットをコーディングする手段と、
を備える装置。

Claims (18)

1. デジタル・ビデオをコーディングする方法において、
   ベース・レイヤと対応するエンハンスメント・レイヤとに関係するビデオ情報を取得することと、
   前記ベース・レイヤ中の第１のビデオ・ユニットに関係する第１の重みと、前記エンハンスメント・レイヤのフレーム中の第２のビデオ・ユニットに関係する第２の重みとを決定し、前記第２の重みは、（１）前記エンハンスメント・レイヤのフレーム中の現在のエンハンスメント・レイヤ・ブロックの現在のビデオ・ユニットと、（２）予測方向の近隣エンハンスメント・レイヤ・ブロックの境界との間の空間距離に少なくとも部分的に基づいて決定されることと、
   前記第１の重みに少なくとも部分的に基づいているインタ・レイヤ予測と、前記第２の重みに少なくとも部分的に基づいているイントラ・レイヤ予測とを使用して、前記現在のビデオ・ユニットをコーディングすることとを含む方法。
2. 前記エンハンスメント・レイヤのフレーム中の現在のビデオ・ユニットをコーディングすることは、最終的な予測子に少なくとも部分的に基づいており、
   前記最終的な予測子は、前記第１の重みにしたがって重み付けられたベース・レイヤ予測子と、前記第２の重みにしたがって重み付けられたエンハンスメント・レイヤ予測子との結合を含む請求項１記載の方法。
3. 前記第１の重みと前記第２の重みとを総和すると、前記現在のエンハンスメント・レイヤ・ブロックに対する最終的な予測子を決定するために結合されたすべてのベース・レイヤ予測子とエンハンスメント・レイヤ予測子とに対して、予め決定された一定値となる請求項２記載の方法。
4. 以前にコーディングされたエンハンスメント・レイヤ・ブロックに隣接しているエンハンスメント・レイヤ・ビデオ・ユニットに対して、前記第２の重みは、前記第１の重みよりも大きい請求項１記載の方法。
5. 以前にコーディングされたエンハンスメント・レイヤ・ブロックから最も離れたエンハンスメント・レイヤ・ビデオ・ユニットに対して、前記第１の重みは、前記第２の重みよりも大きい請求項１記載の方法。
6. 前記ビデオ情報は、イントラ予測方向、ピクセル位置、量子化パラメータ、および空間スケーリング比のうちの１または複数を含む請求項１記載の方法。
7. 前記第２の重みは、前記ベース・レイヤの量子化パラメータＱＰ１と、前記エンハンスメント・レイヤの量子化パラメータＱＰ２との両方の関数として決定される請求項６記載の方法。
8. 前記第２の重みは、ＱＰ１−ＱＰ２の値が増加すると増加する請求項７記載の方法。
9. 前記第２の重みは、前記空間スケーリング比の関数として決定される請求項６記載の方法。
10. 前記第２の重みは、前記空間スケーリング比が増加すると増加する請求項９記載の方法。
11. 前記ビデオ情報は、前記第１の重みと前記第２の重みを含んでいない請求項１記載の方法。
12. 前記ビデオ情報は、前記第１の重みと前記第２の重みとに関する重み付けデータを含む請求項１記載の方法。
13. 前記重み付けデータは、前記第１の重みと前記第２の重みとが等しい、前記現在のエンハンスメント・レイヤ・ブロック内の位置を含む請求項１２記載の方法。
14. 前記第１の重みと前記第２の重みとが等しい前記位置に少なくとも部分的に基づいて、前記現在のエンハンスメント・レイヤ・ブロックに関係する複数のビデオ・ユニットに対する前記第１の重みと前記第２の重みとを決定することをさらに含む請求項１３記載の方法。
15. 前記第２のビデオ・ユニットは、前記近隣エンハンスメント・レイヤ・ブロック中のピクセルを含む請求項１記載の方法。
16. 前記現在のビデオ・ユニットと前記予測方向の近隣エンハンスメント・レイヤ・ブロックの境界との間の空間距離に基づいて決定された前記第２の重みに対する第１の値は、第２の現在のビデオ・ユニットと前記予測方向の近隣エンハンスメント・レイヤ・ブロックの境界との間の第２の空間距離に基づいて決定された前記第２の重みに対する第２の値よりも大きく、前記第２の空間距離が前記空間距離より長いために、前記第１の値は、前記第２の値よりも大きい請求項１記載の方法。
17. 装置のプロセッサによって実行可能な命令群を含む非一時的コンピュータ読取可能な記憶媒体において、
    前記命令群は前記装置に対して、
    ベース・レイヤと対応するエンハンスメント・レイヤとに関係するビデオ情報を取得させ、
    前記ベース・レイヤ中の第１のビデオ・ユニットに関係する第１の重みと、前記エンハンスメント・レイヤのフレーム中の第２のビデオ・ユニットに関係する第２の重みとを決定させ、前記第２の重みは、（１）前記エンハンスメント・レイヤのフレーム中の現在のエンハンスメント・レイヤ・ブロックの現在のビデオ・ユニットと、（２）予測方向の近隣エンハンスメント・レイヤ・ブロックの境界との間の空間距離に少なくとも部分的に基づいて決定され、
    前記第１の重みに少なくとも部分的に基づいているインタ・レイヤ予測と、前記第２の重みに少なくとも部分的に基づいているイントラ・レイヤ予測とを使用させて、前記現在のビデオ・ユニットをコーディングさせる非一時的コンピュータ読取可能な記憶媒体。
18. ビデオをコーディングする装置において、
    ベース・レイヤと対応するエンハンスメント・レイヤとに関係するビデオ情報を取得する手段と、
    前記ベース・レイヤ中の第１のビデオ・ユニットに関係する第１の重みと、前記エンハンスメント・レイヤのフレーム中の第２のビデオ・ユニットに関係する第２の重みとを決定し、前記第２の重みは、（１）前記エンハンスメント・レイヤのフレーム中の現在のエンハンスメント・レイヤ・ブロックの現在のビデオ・ユニットと、（２）予測方向の近隣エンハンスメント・レイヤ・ブロックの境界との間の空間距離に少なくとも部分的に基づいて決定される手段と、
    前記第１の重みに少なくとも部分的に基づいているインタ・レイヤ予測と、前記第２の重みに少なくとも部分的に基づいているイントラ・レイヤ予測とを使用して、前記現在のビデオ・ユニットをコーディングする手段とを具備する装置。

Images