特許 7522036 適応型不均等重み付けによる平面予測

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

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

(11)【特許番号】

(24)【登録日】2024-07-16

(45)【発行日】2024-07-24

(54)【発明の名称】適応型不均等重み付けによる平面予測

(51)【国際特許分類】

   H04N 19/593 20140101AFI20240717BHJP

   H04N 19/70 20140101ALI20240717BHJP

【ＦＩ】

H04N19/593

H04N19/70

【請求項の数】 9

(21)【出願番号】P 2020540699

(86)(22)【出願日】2018-10-09

(65)【公表番号】

(43)【公表日】2020-12-17

(86)【国際出願番号】 US2018055099

(87)【国際公開番号】W WO2019074985

(87)【国際公開日】2019-04-18

【審査請求日】2021-09-29

(31)【優先権主張番号】62/569,868

(32)【優先日】2017-10-09

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

(31)【優先権主張番号】16/155,858

(32)【優先日】2018-10-09

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

【前置審査】

(73)【特許権者】

【識別番号】514188564

【氏名又は名称】アリス エンタープライジズ エルエルシー

【氏名又は名称原語表記】ＡＲＲＩＳ ＥＮＴＥＲＰＲＩＳＥＳ ＬＬＣ

【住所又は居所原語表記】３８７１ Ｌａｋｅｆｉｅｌｄ Ｄｒｉｖｅ， Ｓｕｗａｎｅｅ， ＧＡ ３００２４， Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(72)【発明者】

【氏名】パヌソポーン、クリット

(72)【発明者】

【氏名】ユ、ユエ

(72)【発明者】

【氏名】ホン、ソンウク

(72)【発明者】

【氏名】ワン、リミン

【審査官】坂東 大五郎

(56)【参考文献】

【文献】Krit Panusopone et al.，Weighted Angular Prediction，Joint Video Exploration Team (JVET)，2017年04月04日，[JVET-F0104] (version 1)

【文献】Vadim Seregin et al.，Block shape dependent intra mode coding，Joint Video Exploration Team (JVET)，2017年07月16日，[JVET-G0159] (version 1)

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

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

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

【請求項1】

ビデオをコーディングする方法であって、
ビデオフレームのコーディング領域内にコーディングユニット（ＣＵ）を定義することであって、ＣＵｘとＣＵｙの座標を有する前記ＣＵを定義すること、
イントラ予測モードが垂直モードの場合に前記コーディングユニットの上側に位置する参照行におけるピクセルをメイン参照ピクセルとして定義し、前記イントラ予測モードが水平モードの場合に前記コーディングユニットの左側に位置する参照列におけるピクセルを前記メイン参照ピクセルとして定義することであって、前記メイン参照ピクセルに関連付けられたメインｘとメインｙの座標を有する前記メイン参照ピクセルを定義すること、
前記イントラ予測モードが前記垂直モードの場合に前記コーディングユニットの左側に位置する参照列におけるピクセルをサイド参照ピクセルとして定義し、前記イントラ予測モードが前記水平モードの場合に前記コーディングユニットの上側に位置する参照行におけるピクセルを前記サイド参照ピクセルとして定義することであって、前記サイド参照ピクセルに関連付けられたサイドｘとサイドｙの座標を有する前記サイド参照ピクセルを定義すること、
前記イントラ予測モードのセットを定義すること、
前記イントラ予測モードのセット内において同じ予測角度を共有するモード２とモード６６を識別することであって、前記水平モードの一つである前記モード２と前記垂直モードの一つである前記モード６６を識別すること、
前記イントラ予測モードのセットから１つのイントラ予測モードを選択すること、
前記イントラ予測モードが角度予測である場合に前記メイン参照ピクセルと前記サイド参照ピクセルとの組み合わせに少なくとも部分的に基づいて前記コーディングユニットの予測ＣＵの予測ピクセルを生成すること、
を備え、
前記モード２と前記モード６６の各々が、同じコードワードを用いてコーディングされ、
前記モード２と前記モード６６の各々が、予測方向に少なくとも部分的に基づいて区別される、ビデオをコーディングする方法。

【請求項2】

前記予測方向が前記コーディングユニットの幅及び高さを規定するブロック寸法に基づく、請求項１に記載のビデオをコーディングする方法。

【請求項3】

前記予測ＣＵに基づいて前記ビデオフレームがエントロピー符号化される、請求項１に記載のビデオをコーディングする方法。

【請求項4】

前記イントラ予測モードのセットが０～６６の間の整数値のモードを含む、請求項１に記載のビデオをコーディングする方法。

【請求項5】

前記モード２に関連する角度予測を実施する場合に、
前記メイン参照ピクセルに関連するメイン重み付け値を決定すること、
前記サイド参照ピクセルに関連するサイド重み付け値を決定すること、
前記メイン重み付け値と組み合わせられた前記メイン参照ピクセルと、前記サイド重み付け値と組み合わせられた前記サイド参照ピクセルとの組み合わせに少なくとも部分的に基づいて、前記コーディングユニットの予測ＣＵの予測ピクセルを生成すること、
を含む、請求項１に記載のビデオをコーディングする方法。

【請求項6】

前記メイン重み付け値が前記コーディングユニットと前記メイン参照ピクセルとの間の距離に少なくとも部分的に基づき、前記サイド重み付け値が前記コーディングユニットと前記サイド参照ピクセルとの間の距離に少なくとも部分的に基づく、請求項５に記載のビデオをコーディングする方法。

【請求項7】

前記予測ＣＵに基づいて前記ビデオフレームがエントロピー符号化される、請求項６に記載のビデオをコーディングする方法。

【請求項8】

前記モード６６に関連する角度予測を実施する場合に、
前記メイン参照ピクセルに関連するメイン重み付け値を決定すること、
前記サイド参照ピクセルに関連するサイド重み付け値を決定すること、
前記メイン重み付け値と組み合わせられた前記メイン参照ピクセルと、前記サイド重み付け値と組み合わせられた前記サイド参照ピクセルとの組み合わせに少なくとも部分的に基づいて、前記コーディングユニットの予測ＣＵの予測ピクセルを生成すること、
を含む、請求項１に記載のビデオをコーディングする方法。

【請求項9】

前記メイン重み付け値が前記コーディングユニットと前記メイン参照ピクセルとの間の距離に少なくとも部分的に基づき、前記サイド重み付け値が前記コーディングユニットと前記サイド参照ピクセルとの間の距離に少なくとも部分的に基づく、請求項８に記載のビデオをコーディングする方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ビデオコーディングの分野に関し、特に、符号化のためのモード数を減らすことによって、より高いビットレート、より高い解像度、およびより高い品質のビデオを可能にする符号化効率の向上に関する。この出願は、２０１７年１０月９日に提出された米国仮出願番号第６２／５６９，８６８に基づく優先権を主張し、その内容全体が参照により本明細書に組み込まれる。

【背景技術】

【0002】

日々進化するビデオコーディング標準の技術的向上により、より高いビットレート、より高い解像度、およびより高品質のビデオを可能にする符号化効率が向上しつつある。ジョイントビデオエクスプロレーションチーム（Joint Video Exploration Team）は、ＪＶＥＴと呼ばれる新しいビデオコーディング方式を開発している。ＪＶＥＴは、ＨＥＶＣ（High Efficiency Video Coding）などの他のビデオコーディング方式と同様に、ブロックベースのハイブリッド空間および時間予測コーディング方式である。ただし、ＨＥＶＣと比べて、ＪＶＥＴは、復号化画像を生成するためのビットストリーム構造、構文、制約、およびマッピングに対する多くの変更を含む。ＪＶＥＴは、重み付け角度予測を含む種々のコーディング技術を利用するジョイントエクスプロレーションモデル（ＪＥＭ）エンコーダおよびデコーダに実装されている。

【0003】

現在のＪＶＥＴ設計では、６７個の角度コーディングモードを使用して予測ＣＵを決定する。しかしながら、これらのコーディングモードのうちの２つ（モード２およびモード６６）は共通の角度を共有する。したがって、コーディングの負担を軽減するためにモード２およびモード６６の共通の角度を利用してＪＶＥＴをコーディングするシステムおよび方法が必要とされている。

【発明の概要】

【0004】

１つまたは複数のコンピュータのシステムは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせがシステムにインストールされて作動時に特定の操作または動作をシステムに実行させることにより、それら特定の操作または動作を実現するように構成され得る。１つまたは複数のコンピュータプログラムは、データ処理装置による実行時にそのデータ処理装置に特定の操作または動作を実行させる命令を含むことにより、それら特定の操作または動作を実現するように構成され得る。一般的な一態様は、ビデオフレームのコーディング領域内にコーディングユニット（ＣＵ）を定義することであって、ＣＵｘおよびＣＵｙの座標を有するＣＵを定義することを含み、当該定義することはさらに、メイン参照（main reference）に関連付けられたメインｘおよびメインｙの座標を有するメイン参照ピクセルをコーディング領域内に定義することを含む。このステップはさらに、サイド参照（side reference）に関連付けられたサイドｘおよびサイドｙの座標を有するサイド参照ピクセルをコーディング領域内に定義することを含み得る。また、システムおよび方法は、予測モードのセットを定義すること、および／または予測モードのセット内の２つの離散予測モードを識別することを含み得る。システムおよび方法はさらに、予測モードのセットから１つの予測モードを選択すること、および／またはメイン参照ピクセルとサイド参照ピクセルとの組み合わせに少なくとも部分的に基づいてコーディングユニットの予測ＣＵを生成することを含み得る。また、システムおよび方法は、予測方向に少なくとも部分的に基づいて２つの離散予測モードの各々が区別される方法と同じ方法でコーディングユニットの予測ＣＵがコーディングされるステップを含み得る。この態様の他の実施形態は、上記方法の動作を実現するように構成された、対応するコンピュータシステム、装置、および１つまたは複数のコンピュータストレージデバイスに記録されたコンピュータプログラムを含む。

【0005】

実装形態としては、予測方向がコーディングユニットの１つまたは複数の特性に基づいたＪＶＥＴビデオをコーディングする方法、予測ＣＵがエントロピー符号化されたＪＶＥＴビデオをコーディングする方法、予測方向がコーディングユニットの幅に少なくとも部分的に基づいたＪＶＥＴビデオをコーディングする方法、および／または予測モードが０～６６の間の整数値のモードを含むＪＶＥＴビデオをコーディングする方法、および／または２つの離散予測モードがモード２およびモード６６であるＪＶＥＴビデオをコーディングする方法、のうちの１つ以上を含み得る。また、いくつかの実施形態において、ＪＶＥＴビデオをコーディングする方法は、予測モード２に関連付けられたコーディングが、メイン参照ピクセルに関連付けられたメイン重み付け値（main weight value）を決定すること、サイド参照ピクセルに関連付けられたサイド重み付け値（side weight value）を決定すること、および、メイン重み付け値と組み合わせられたメイン参照ピクセルとサイド重み付け値と組み合わせられたサイド参照ピクセルとの組み合わせに少なくとも部分的に基づいてコーディングユニットの予測ＣＵを生成することを含むことに基づくものとすることができる。上記技術の実装形態には、ハードウェア、方法もしくはプロセス、またはコンピュータアクセス可能媒体上のコンピュータソフトウェアが含まれ得る。

【0006】

本発明のさらなる詳細は、添付の図面を用いて説明される。

【図面の簡単な説明】

【0007】

【図1】複数のコーディングツリーユニット（ＣＴＵ）へのフレームの分割を示す図。

【図2】クワッドツリー分割および対称バイナリ分割を用いた、複数のコーディングユニット（ＣＵ）へのＣＴＵの例示的な分割を示す図。

【図3】図２の分割のクワッドツリーおよびバイナリツリー（ＱＴＢＴ）表現を示す図。

【図4】ＣＵをより小さな２つのＣＵへ分割する場合のとり得る４つの非対称バイナリ分割を示す図。

【図5】クワッドツリー分割、対称バイナリ分割、および非対称バイナリ分割を用いた、複数のＣＵへのＣＴＵの例示的な分割を示す図。

【図6】図５の分割のＱＴＢＴ表現を示す図。

【図7A】ＪＶＥＴエンコーダにおけるＣＵコーディングの簡略ブロック図。

【図7B】ＪＶＥＴエンコーダにおけるＣＵコーディングの簡略ブロック図。

【図8】ＪＶＥＴの輝度成分のとり得る６７個のイントラ予測モードを示す図。

【図9】ＪＶＥＴエンコーダにおけるＣＵデコーディングの簡略ブロック図。

【図10】ＪＶＥＴエンコーダにおけるＣＵコーディングの方法の実施形態を示す図。

【図11】ＪＶＥＴエンコーダにおけるＣＵコーディングの簡略ブロック図。

【図12】ＪＶＥＴデコーダにおけるＣＵデコーディングの簡略ブロック図。

【図13】効率を向上させたコーディングシステムおよび方法の簡略ブロック図。

【図14】ＪＶＥＴエンコーダにおいて効率を向上させたＣＵコーディングの簡略ブロック図。

【図15】ＪＶＥＴデコーダにおいて効率を向上させたＣＵデコーディングの簡略ブロック図。

【図16】ＣＵコーディングの方法を処理するべく適応化および／または構成されたコンピュータシステムの実施形態を示す図。

【図17】ＪＶＥＴエンコーダ／デコーダにおけるＣＵコーディング／デコーディングのためのコーダ／デコーダシステムの実施形態を示す図。

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

【0008】

図１は、複数のコーディングツリーユニット（ＣＴＵ）１００へのフレームの分割を示す。フレームはビデオシーケンスの画像とすることができる。フレームは、画像内の強度測定値を表すピクセル値を有したマトリクスまたはマトリクスのセットを含み得る。したがって、マトリクスのセットによりビデオシーケンスを生成することができる。ピクセル値は、フルカラービデオコーディングにおける色と明るさを表すように定義することができ、ピクセルは３つのチャネルに分割される。例えば、ＹＣｂＣｒ色空間では、ピクセルは、画像内のグレーレベル強度を表す輝度（luma）値Ｙと、グレーから青への色の違いの程度とグレーから赤への色の違いの程度を表す２つの色差（chrominance）値Ｃｂ，Ｃｒとを有し得る。他の実施形態では、ピクセル値は、異なる色空間または異なるモデルの値で表すことができる。ビデオの解像度はフレーム内のピクセル数を決定し得る。解像度が高いほど、ピクセルがより多く、画像がより鮮明であることを意味するが、帯域幅、ストレージ、および伝送要件も高くなる。

【0009】

ビデオシーケンスのフレームは、ＪＶＥＴを使用して符号化および復号化され得る。ＪＶＥＴは、ジョイントビデオエクスプロレーションチーム（Joint Video Exploration Team）によって開発されているビデオコーディング方式である。ＪＶＥＴのバージョンは、ＪＥＭ（Joint Exploration Model）エンコーダおよびデコーダに実装されている。ＪＶＥＴは、ＨＥＶＣ（High Efficiency Video Coding）などの他のビデオコーディング方式と同様に、ブロックベースのハイブリッド空間および時間予測コーディング方式である。図１に示されるように、フレームはまず、ＪＶＥＴによるコーディング中に、ＣＴＵ１００と呼ばれる複数の正方形ブロックに分割される。例えば、これらのＣＴＵ１００は１２８×１２８ピクセルのブロックとすることができる。

【0010】

図２は、複数のＣＵ１０２へのＣＴＵ１００の例示的な分割を示す。フレーム内の各ＣＴＵ１００は、１つまたは複数のＣＵ（コーディングユニット）１０２に分割され得る。ＣＵ１０２は、以下で説明するように予測および変換に使用され得る。ＨＥＶＣとは異なり、ＪＶＥＴでは、ＣＵ１０２は長方形または正方形とすることができ、予測ユニットまたは変換ユニットにさらに分割することなくコーディングすることができる。ＣＵ１０２は、その元のＣＴＵ１００と同程度の大きさでもよいし、または元のＣＴＵ１００を４×４ブロック程度により小さく細分化したものでもよい。

【0011】

ＪＶＥＴでは、ＣＴＵ１００がクワッドツリーおよびバイナリツリー（ＱＴＢＴ）方式に従って複数のＣＵ１０２に分割され得る。この方式では、ＣＴＵ１００がクワッドツリーに従って複数の正方形ブロックに再帰的に分割されるとともに、それら正方形ブロックがバイナリツリーに従って水平方向または垂直方向に再帰的に分割され得る。ＣＴＵサイズ、クワッドツリーやバイナリツリーのリーフノードの最小サイズ、バイナリツリーのルートノードの最大サイズ、バイナリツリーの最大深度などのパラメータは、ＱＴＢＴに従った分割を制御するように設定され得る。

【0012】

いくつかの実施形態では、ＪＶＥＴは、ＱＴＢＴのバイナリツリー部分でバイナリ分割を対称分割に制限し得るものであり、この場合、ブロックは中央線に沿って垂直方向または水平方向に半分に分割され得る。

【0013】

非限定的な例として、図２は複数のＣＵ１０２に分割されたＣＴＵ１００を示しており、実線はクワッドツリー分割を示し、破線は対称バイナリツリー割を示している。図示されるように、バイナリ分割は、対称的な水平分割と垂直分割により、ＣＴＵの構造とそのＣＴＵの複数のＣＵへの細分化を規定することができる。

【0014】

図３は、図２の分割のＱＴＢＴ表現を示す。クワッドツリーのルートノードはＣＴＵ１００を表しており、クワッドツリー部分における各々の子ノードは、親の正方形ブロックから分割された４つの正方形ブロックのうちの１つを表している。クワッドツリーのリーフノードによって表される正方形ブロックは、バイナリツリーを用いて対照的に０（ゼロ）または１回以上分割され得るものとなり、クワッドツリーのリーフノードがバイナリツリーのルートノードとなる。バイナリツリー部分の各レベルでブロックが垂直方向または水平方向に対称的に分割され得る。フラグが「０」に設定される場合はブロックが左右対称に分割されることを示し、フラグが「１」に設定される場合はブロックが上下対称に分割されることを示す。

【0015】

他の実施形態では、ＪＶＥＴは、ＱＴＢＴのバイナリツリー部分で対称バイナリ分割または非対称バイナリ分割のいずれかを可能とし得る。予測ユニット（ＰＵ）を分割する際、ＨＥＶＣでは異なるコンテキストで非対称動き分割（ＡＭＰ）が可能とされていた。しかしながら、ＱＴＢＴ構造に従ってＪＶＥＴでＣＵ１０２を分割する場合、非対称バイナリ分割は、ＣＵ１０２の中心を通る中央線の両側にＣＵ１０２の相関領域が配置されない場合に、対称バイナリ分割に比べて改善された分割を行うことができる。非限定的な例として、ＣＵ１０２がそのＣＵ中心に近接する１つのオブジェクトとＣＵ１０２の辺側の他のオブジェクトとを表現する場合、ＣＵ１０２を非対称に分割して各オブジェクトを異なるサイズの個別の小さなＣＵ１０２に設定することができる。

【0016】

図４は、とり得る４つの非対称バイナリ分割のタイプを示しており、同図では、ＣＵ１０２がそのＣＵ１０２の長さ方向または高さ方向にわたって延びる線に沿って２つの小さなＣＵ１０２に分割され、それら２つの小さなＣＵ１０２のうちの一方が親のＣＵ１０２のサイズの２５％とされ、他方が親のＣＵ１０２のサイズの７５％とされている。図４に示される４つの非対称バイナリ分割のタイプは、ＣＵ１０２の左側からの距離が２５％の位置の線、ＣＵ１０２の右側からの距離が２５％の位置の線、ＣＵ１０２の上部からの距離が２５％の位置の線、またはＣＵ１０２の下部からの距離が２５％の位置の線に沿って、ＣＵ１０２を分割可能とする。代替実施形態では、ＣＵ１０２を分割する非対称分割線は、ＣＵ１０２が半分に対称的に分割されないように他の任意の位置に位置決めされ得る。

【0017】

図５は、対称バイナリ分割と非対称バイナリ分割の両方を可能にする方式を用いてＱＴＢＴのバイナリツリー部分でＣＴＵ１００を複数のＣＵ１０２に分割する非限定的な例を示す。図５において、破線は、図４に示される分割タイプのうちの１つを使用して親のＣＵ１０２が分割される非対称バイナリ分割線を示している。

【0018】

図６は、図５の分割のＱＴＢＴ表現を示す。図６において、ノードから延びる２本の実線はＱＴＢＴのバイナリツリー部分における対称分割を示す一方、ノードから延びる２本の破線はバイナリツリー部分における非対称分割を示している。

【0019】

ＣＴＵ１００が複数のＣＵ１０２にどのように分割されたかを示す構文はビットストリームでコーディングされ得る。非限定的な例として、どのノードがクワッドツリー分割で分割されたのか、どのノードが対称バイナリ分割で分割されたのか、およびどのノードが非対称バイナリ分割で分割されたのかを示す構文がビットストリームでコーディングされ得る。同様に、非対称バイナリ分割で分割されたノードについて、非対称バイナリ分割のどのタイプが使用されたのか（図４に示された４つのタイプのうちの１つなど）を示す構文がビットストリームでコーディングされ得る。

【0020】

いくつかの実施形態では、非対称分割の使用は、ＱＴＢＴのクワッドツリー部分のリーフノードにおけるＣＵ１０２の分割に制限され得る。これらの実施形態において、クワッドツリー部分でクワッドツリー分割を用いて親ノードから分割された子ノードのＣＵ１０２は、最終のＣＵ１０２とされてもよいし、または、クワッドツリー分割、対称バイナリ分割、あるいは非対称バイナリ分割を用いてさらに分割されてもよい。対称バイナリ分割を用いて分割されたバイナリツリー部分における子ノードは、最終のＣＵ１０２とされてもよいし、または、対称バイナリ分割のみを用いて再帰的にさらに１回以上分割されてもよい。非対称バイナリ分割を使用してＱＴリーフノードから分割されたバイナリツリー部分における子ノードは、さらなる分割を不可とする最終のＣＵ１０２とされてもよい。

【0021】

これらの実施形態では、非対称分割の使用をクワッドツリーのリーフノードの分割に制限することにより、検索の複雑さを低減しおよび／またはオーバーヘッドビットを制限することができる。クワッドツリーのリーフノードのみが非対称分割で分割可能とされるため、非対称分割の使用は、他の構文またはさらなる通知（signaling）を必要とすることなく、そのＱＴ部分の分岐の終わりを直接示すことができる。同様に、非対称分割されたノードはさらなる分割が不可とされるため、ノードでの非対称分割の使用は、他の構文またはさらなる通知を必要とすることなく、その非対称分割された子ノードが最終のＣＵ１０２であることを直接示すことができる。

【0022】

代替実施形態では、検索の複雑さを制限したりおよび／またはオーバーヘッドビット数を制限したりすることがそれほど問題にならない場合などには、クワッドツリー分割、対称バイナリ分割、および／または非対称バイナリ分割で生成されたノードを、非対称分割を用いて分割することができる。

【0023】

上記いずれかのＱＴＢＴ構造を用いたクワッドツリー分割およびバイナリツリー分割の後、ＱＴＢＴのリーフノードによって表されるブロックは、インター予測またはイントラ予測を用いたコーディングなど、コーディング対象となる最終のＣＵ１０２を表す。インター予測を用いてコーディングされるスライスまたはフルフレームの場合、輝度（luma）成分および色差（chroma）成分に対して異なる分割構造が使用され得る。例えば、インタースライスの場合、ＣＵ１０２は、１つの輝度ＣＢおよび２つの色差ＣＢなどのように、異なる色成分のコーディングブロック（ＣＢ）を有し得る。イントラ予測を用いてコーディングされるスライスまたはフルフレームの場合、輝度成分および色差成分に対して分割構造が同一とされ得る。

【0024】

代替実施形態では、ＪＶＥＴは、上記したＱＴＢＴ分割の代替または拡張として、２レベル・コーディングブロック構造を用いることができる。２レベル・コーディングブロック構造では、まず、ＣＴＵ１００は高レベルで複数のベースユニット（ＢＵ）に分割され得る。次いで、ＢＵが低レベルで複数のオペレーティングユニット（ＯＵ）に分割され得る。

【0025】

２レベル・コーディングブロック構造を採用する実施形態では、高レベルにおいて、ＣＴＵ１００は、上記したＱＴＢＴ構造の１つに従って、またはＨＥＶＣで使用されるものなどのようにブロックが４つの等しいサイズのサブブロックに分割されることのみが可能となるクワッドツリー（ＱＴ）構造に従って、複数のＢＵに分割され得る。非限定的な例として、ＣＴＵ１０２は、図５および図６を参照して上記したＱＴＢＴ構造に従って、クワッドツリー部分のリーフノードがクワッドツリー分割、対称バイナリ分割、または非対称バイナリ分割を用いて分割され得るものとなるように、複数のＢＵに分割され得る。この例では、ＱＴＢＴの最終リーフノードがＣＵに代わってＢＵとされ得る。

【0026】

２レベル・コーディングブロック構造の低レベル側では、ＣＴＵ１００から分割された各ＢＵが、１つまたは複数のＯＵにさらに分割され得る。いくつかの実施形態では、ＢＵが正方形である場合、ＢＵは、クワッドツリー分割、または、対称もしくは非対称バイナリ分割などのバイナリ分割を用いて、ＯＵに分割され得る。ただし、ＢＵが正方形でない場合、ＢＵはバイナリ分割のみを用いてＯＵに分割され得る。非正方形のＢＵに使用可能な分割のタイプを制限することにより、ＢＵの生成に使用される分割のタイプを通知するために使用されるビット数を制限することができる。

【0027】

以下の説明は、ＣＵ１０２のコーディングについて記載したものであるが、２レベル・コーディングブロック構造を使用する実施形態では、ＣＵ１０２の代わりにＢＵやＯＵをコーディングすることができる。非限定的な例として、ＢＵは、イントラ予測またはインター予測などのより高レベルのコーディング操作に使用することができ、より小さなＯＵは、変換や変換係数の生成などのより低レベルのコーディング操作に使用することができる。したがって、ＢＵについてコーディングされる場合の構文は、ＢＵがイントラ予測でコーディングされているのかそれともインター予測でコーディングされているのか、または特定のイントラ予測モードもしくはＢＵのコーディングに使用される動きベクトルを識別する情報を示す。同様に、ＯＵの場合の構文は、ＯＵのコーディングに使用される特定の変換操作または量子化変換係数を識別し得るものとなる。

【0028】

図７Ａは、ＪＶＥＴエンコーダにおけるＣＵコーディングの簡略ブロック図を示す。ビデオコーディングの主な段階は、上記のようにＣＵ１０２を分割して識別することに続いて、７０４または７０６における予測、７０８における残差ＣＵ７１０の生成、７１２における変換、７１６における量子化、および７２０におけるエントロピー符号化（entropy coding）を用いて、ＣＵ１０２を符号化することを含む。図７Ａに示されるエンコーダおよび符号化処理は、以下でより詳細に説明する復号化処理も含む。

【0029】

現在のＣＵ１０２が与えられると、エンコーダは、７０４におけるイントラ予測を空間的に使用するか、または７０６におけるインター予測を時間的に使用して、予測ＣＵ７０２を取得し得る。予測コーディングの基本的な考えは、元の信号とその元の信号の予測との間の差分信号または残差信号を送信することにある。受信側では、以下で説明するように、残差と予測とを追加することによって元の信号を再構築することができる。差分信号は元の信号よりも低い相関性を有するため、その送信に必要とされるビットが少ない。

【0030】

画像全体または画像の一部など、全体的にイントラ予測ＣＵ１０２を用いてコーディングされたスライスは、他のスライスを参照することなく復号可能なＩスライスとなり得るものであり、このため、デコーディングが開始され得る潜在的ポイントとなり得る。少なくともいくつかのインター予測ＣＵを用いてコーディングされたスライスは、１つまたは複数の参照画像に基づいて復号可能な予測（Ｐ）スライスまたは双予測（Ｂ）スライスとなり得る。Ｐスライスは、イントラ予測と、以前にコーディングされたスライスを用いるインター予測とを使用してもよい。例えば、Ｐスライスは、インター予測を使用することによってＩスライスよりもさらに圧縮され得るものとなるが、それらをコーディングするには、以前にコーディングされたスライスのコーディングが必要となる。Ｂスライスは、イントラ予測かまたは２つの異なるフレームに基づく内挿予測を用いたインター予測を使用してそのコーディングのために以前のおよび／または後続のスライスからのデータを使用することにより、動き推定処理の精度を向上し得るものである。いくつかの場合では、同じスライスの他の部分のデータが使用されるブロック内コピーを使用してＰスライスとＢスライスがエンコードされ得るかまたはそれらが交互にエンコードされ得る。

【0031】

以下で説明するように、イントラ予測またはインター予測は、隣接ＣＵ１０２または参照画像内のＣＵ１０２など、以前にコーディングされたＣＵ１０２による再構築ＣＵ７３４に基づいて実行され得る。

【0032】

ＣＵ１０２が７０４におけるイントラ予測を用いて空間的にコーディングされるとき、画像内の隣接ＣＵ１０２からのサンプルに基づいてＣＵ１０２のピクセル値を最良に予測するイントラ予測モードが探索され得る。

【0033】

ＣＵの輝度成分をコーディングするとき、エンコーダは候補イントラ予測モードのリストを生成し得る。ＨＥＶＣは輝度成分に対してとり得るイントラ予測モードが３５個であったが、ＪＶＥＴでは輝度成分に対してとり得るイントラ予測モードが６７個存在する。これらのモードには、隣接ピクセルから生成された値の３次元平面を用いる平面モードと、隣接ピクセルから平均化された値を用いるＤＣモードと、指定方向に沿って隣接ピクセルからコピーされた値を用いる図８に示される６５個の指向性モードとが含まれる。

【0034】

ＣＵの輝度成分の候補イントラ予測モードのリストを生成するとき、そのリスト上の候補モードの数はそのＣＵのサイズに依存し得る。この候補リストには、最も低いＳＡＴＤ（絶対値変換差分和（Sum of Absolute Transform Difference））コストを有するＨＥＶＣの３５個のモードのサブセットと、ＨＥＶＣモードから探索された候補に隣接する新たな指向性モードと、以前にコーディングされた隣接ブロックに使用されたイントラ予測モードとデフォルトモードのリストとに基づいて識別される、ＣＵ１０２の６つの最も可能性の高いモード（ＭＰＭ）のセットからのモードとが含まれ得る。

【0035】

ＣＵの色差成分をコーディングするときには、候補イントラ予測モードのリストも生成され得る。この候補モードのリストには、輝度サンプルからのクロス成分線形モデル投影で生成されたモードと、色差ブロック内の特定の配列位置における輝度ＣＢについて探索されたイントラ予測モードと、隣接ブロックについて以前に探索された色差予測モードとが含まれ得る。エンコーダは、このリスト上で最も低いレート歪みコストを有する候補モードを探索して、ＣＵの輝度成分と色差成分をコーディングするときにそれらのイントラ予測モードを使用し得る。各ＣＵ１０２のコーディングに使用されるイントラ予測モードを示す構文はビットストリームでコーディングされ得る。

【0036】

ＣＵ１０２の最良のイントラ予測モードが選択された後、エンコーダは、それらのモードを使用して予測ＣＵ４０２を生成し得る。選択したモードが指向性モードである場合、４タップフィルタを使用することで指向性の精度を向上させることができる。予測ブロックの上側または左側における列または行は、２タップまたは３タップフィルタなどの境界予測フィルタを用いて調整することができる。

【0037】

予測ＣＵ７０２は、隣接ブロックの未フィルタのサンプルを使用して、隣接ブロックのフィルタ済みのサンプルに基づき生成された予測ＣＵ７０２を調整する位置依存イントラ予測結合（ＰＤＰＣ（position dependent intra prediction combination））処理か、またはステップ７０５ｂで参照サンプルを処理する３タップもしくは５タップのローパスフィルタを用いた適応参照サンプル平滑化によってさらに平滑化することができる。いくつかの実施形態では、ＰＤＰＣは、次式（１）に従って実現され得る。

【0038】

Ｐ’［ｘ，ｙ］＝（（Ａ＊Ｒｅｃｏｎ［ｘ，－１］－Ｂ＊Ｒｅｃｏｎ［－１，－１］＋Ｃ＊Ｒｅｃｏｎ［－１，ｙ］＋Ｄ＊Ｐ［ｘ，ｙ］＋Ｒｏｕｎｄ）／Ｄｅｎｏｍ 式（１）
ここで、Ａ＝（Ｃｖ１＞＞ｉｎｔ（ｙ／ｄｙ））、Ｂ＝（（Ｃｖ２＞＞ｉｎｔ（ｙ／ｄｙ））＋（Ｃｈ２＞＞ｉｎｔ（ｘ／ｄｘ）））、Ｃ＝（Ｃｈ１＞＞ｉｎｔ（ｘ／ｄｘ））、およびＤ＝（１＜＜Ｄｅｎｏｍ）－Ａ－Ｃ＋Ｂである。Ｐ’［ｘ，ｙ］は、現在のＣＵの座標（ｘ，ｙ）におけるポストフィルタ操作後のフィルタ済みのピクセルである。Ｃｖ１，Ｃｖ２，Ｃｈ１，Ｃｈ２はフィルタ効果を決定するＰＤＰＣパラメータであり、「Ｒｏｕｎｄ」は丸めパラメータであり、「Ｄｅｎｏｍ」は正規化係数である。

【0039】

いくつかの実施形態では、上部参照行と左側参照列の双方の投影位置にあるピクセルを使用して角度予測用の予測ピクセルを生成する重み付け角度予測が実施され得る。重み付け角度予測を実施する実施形態では、予測生成は、メイン参照投影予測と、サイド参照投影予測と、それら投影予測の組み合わせとの３つのステップで行われ得る。

【0040】

重み付け角度予測を実施するいくつかの実施形態では、システムおよび方法は、コーディングするイントラ予測モードの角度方向定義に従ってメイン参照に沿ってピクセル位置を投影し、２つの隣接する再構築ピクセル間の線形補間を使用してその投影位置のピクセル値を決定し得る。また、システムおよび方法は、同じコーディングモードの角度定義に従ってサイド参照に沿ってピクセル位置を投影し、２つの隣接する再構築ピクセル間の線形補間を使用してその投影位置のピクセル値を決定し得る。次いで、システムおよび方法は、メイン参照の投影ピクセル値をサイド参照の投影ピクセル値と組み合わせ得る。非限定的な例示的組み合わせは、以下の式（２）で示される。式（２）で示される例示的な組み合わせでは、メイン参照とサイド参照に関する予測ピクセルと投影ピクセル位置との距離に従って値が重み付けされる。しかしながら、代替実施形態では、メイン参照ピクセルとサイド参照ピクセルに関連する値を重み付けするために別の値が使用され得る。

【0041】

Ｐ［ｘ，ｙ］＝（（（ｗ１＊ＭａｉｎＲｅｃｏｎ［ｘ’，ｙ’］）＋（ｗ２＊ＳｉｄｅＲｅｃｏｎ［ｘ”，ｙ”］）＋（ｗ１＋ｗ２）／２）／（ｗ１＋ｗ２）） 式（２）
上記の例示的な式（２）において、ＭａｉｎＲｅｃｏｎ［ｘ’，ｙ’］は、予測ピクセル（ｘ，ｙ）に対応するメイン参照に沿った投影位置（ｘ’，ｙ’）の近傍のピクセル値である。ＳｉｄｅＲｅｃｏｎ［ｘ”，ｙ”］は、予測ピクセル（ｘ，ｙ）に対応するサイド参照に沿った投影位置（ｘ”，ｙ”）の近傍のピクセル値である。

【0042】

以下の式（３）は、ＨＥＶＣのモード２またはモード６６を用いて重み付け角度予測を使用する非限定的な例示的組み合わせであり、座標（ｘ，ｙ）における予測ピクセルを示す。したがって、Ｐ［ｘ，ｙ］は、式（３）に示され説明されるように決定され、ここで、Ｒｅｃｏｎ［０，０］は、現在のＣＵの左上の座標（０，０）における再構築ピクセルである。

【0043】

Ｐ［ｘ，ｙ］＝（（（（ｘ＋１）＊Ｒｅｃｏｎ［ｘ＋ｙ＋２，－１］）＋（（ｙ＋１）＊（Ｒｅｃｏｎ［－１，ｘ＋ｙ＋２］））＋（ｙ＋ｘ＋２）／２）／（ｙ＋ｘ＋２）） 式（３）
サイド参照について投影された参照位置が、実行可能な位置ではないかもしくは利用できない再構築位置を参照している場合、重み付け角度予測を実施できないシステムおよび処理の例外が発生することがある。重み付け角度予測を実施できないそのような場合には、複数のオプションにより例外を処理することが可能である。いくつかの実施形態では、この例外は、最新の利用可能な再構築ピクセルの値または投影位置のデフォルト値を使用することによって処理することができる。他の代替実施形態では、重み付け角度予測を無効にすることによって、および／またはメイン参照のみについて投影ピクセル位置を使用することによって、例外を処理することができる。したがって、ステップ７０５ａでは、重み付け角度予測がステップ７０４でイントラ予測モードとして実施されたかどうかが判定され得る。イントラ予測モードが重み付け角度予測を使用するものとしてステップ７０５ａで判定された場合、予測コーディングユニット７０２がフィルタ処理なしでエントロピー符号化に向けて送信され得る。しかしながら、イントラ予測モードが重み付け角度予測以外であるとステップ７０５ａで判定された場合は、エントロピー符号化に向けた送信に先立って、ＰＤＰＣフィルタ処理などのポストイントラ予測フィルタ処理７０５ｂが予測コーディングユニットに適用され得る。

【0044】

図７Ｂに示されるように、いくつかの実施形態では、ポストイントラ予測フィルタ７０５ｂは、ステップ７０４の後にすべてのイントラ予測に対して使用され得る。図７Ｂに示されるこのような実施形態では、イントラ予測モードが重み付け角度予測以外に基づくものである場合、適用されるフィルタは、ステップ７０５ｂで通常適用されるように適用することができる。しかしながら、イントラ予測モードが重み付け角度予測に基づいている場合は、ステップ７０５ｂのフィルタ処理がバイパスされてもよく、および／または、いくつかの実施形態では、メイン参照、サイド参照、またはメイン参照とサイド参照の両方に対して、適用されるフィルタがバイアスされないものとされ得る。非限定的な例として、Ｃｖ１，Ｃｈ１の値は等しくてもよく、および／またはＣｖ２，Ｃｈ２の値は等しくてもよい。

【0045】

ＣＵ１０２が７０６におけるインター予測を用いて時間的に符号化される場合、ＣＵ１０２のピクセル値を最良に予測する参照画像内のサンプルを指す動きベクトル（ＭＶ）のセットが探索され得る。インター予測は、スライス内でのピクセル群のブロックの変位を表すことによりスライス間の時間的冗長性を利用する。この変位は、動き補償と呼ばれる処理を通じて、前後のスライスにおけるピクセルの値に従って決定され得る。特定の参照画像に対するピクセル変位を示す動きベクトルとそれに関連する参照インデックスは、元のピクセルと動き補償されたピクセルとの間の残差とともに、ビットストリームでデコーダに供給され得る。デコーダは、残差および供給された動きベクトルと参照インデックスを使用して、再構築スライス内にピクセル群のブロックを再構築することができる。

【0046】

ＪＶＥＴでは、動きベクトルの精度を１／１６ペル（pel）に保つことができ、動きベクトルとＣＵの予測動きベクトルとの差分を１／４ペル解像度または整数ペル解像度でコーディングすることができる。

【0047】

ＪＶＥＴでは、高度時間動きベクトル予測（ＡＴＭＶＰ（advanced temporal motion vector prediction））、時空間動きベクトル予測（ＳＴＭＶＰ（spatial-temporal motion vector prediction））、アフィン動き補償予測（affine motion compensation prediction）、パターン一致動きベクトル導出（ＰＭＭＶＤ（pattern matched motion vector derivation））、および／または双方向オプティカルフロー（ＢＩＯ）などの技術を用いて、ＣＵ１０２内の複数のサブＣＵの動きベクトルを探索することができる。

【0048】

エンコーダは、ＡＴＭＶＰを使用して、参照画像内の対応するブロックを指すＣＵ１０２の時間ベクトルを探索することができる。この時間ベクトルは、以前にコーディングされた隣接ＣＵ１０２について探索された動きベクトルおよび参照画像に基づいて探索され得る。ＣＵ１０２内の各サブＣＵの動きベクトルは、ＣＵ１０２全体の時間ベクトルが指す参照ブロックを使用して探索され得る。

【0049】

ＳＴＭＶＰでは、インター予測を用いて以前にコーディングされた隣接ブロックについて探索された動きベクトルを時間ベクトルとともにスケーリングおよび平均化することによってサブＣＵの動きベクトルを探索することができる。

【0050】

アフィン動き補償予測は、ブロックの上部の角部について探索された２つの制御動きベクトルに基づいてブロック内の各サブＣＵの動きベクトルのフィールドを予測するために使用され得る。例えば、サブＣＵの動きベクトルは、ＣＵ１０２内の各４×４ブロックで探索された上部の角部の動きベクトルに基づいて導出され得る。

【0051】

ＰＭＭＶＤでは、バイラテラルマッチング（bilateral matching）またはテンプレートマッチングを使用して、現在のＣＵ１０２の初期動きベクトルを探索することができる。バイラテラルマッチングでは、動きの軌跡（motion trajectory）に沿った２つの異なる参照画像内で現在のＣＵ１０２と参照ブロックを確認することができ、テンプレートマッチングでは、現在のＣＵ１０２の対応するブロックと、テンプレートによって識別される参照画像を確認することができる。その後、ＣＵ１０２について探索された初期動きベクトルを各サブＣＵについて個別に改良することができる。

【0052】

ＢＩＯは、前後の参照画像に基づいて双予測でインター予測を行うときに使用することができ、２つの参照画像間の差の勾配に基づいてサブＣＵの動きベクトルを探索することができる。

【0053】

いくつかの状況では、ローカルイルミネーション補正（ＬＩＣ）をＣＵレベルで使用して、現在のＣＵ１０２に隣接するサンプルと、候補の動きベクトルによって識別される参照ブロックに隣接する対応するサンプルとに基づいて、スケーリング係数パラメータとオフセットパラメータの値を探索することができる。ＪＶＥＴでは、ＬＩＣパラメータを変更して、ＣＵレベルで通知することができる。

【0054】

上記した方法のいくつかでは、ＣＵのサブＣＵの各々について探索された動きベクトルは、ＣＵレベルでデコーダに通知され得る。ＰＭＭＶＤやＢＩＯなどの他の方法の場合、動き情報はオーバーヘッドを節約するためにビットストリームで通知されず、デコーダは同じ処理を経て動きベクトルを導出し得る。

【0055】

ＣＵ１０２の動きベクトルが探索された後、エンコーダは、それらの動きベクトルを使用して予測ＣＵ７０２を生成し得る。いくつかの場合では、個々のサブＣＵの動きベクトルが探索された場合に、それらの動きベクトルを１つまたは複数の隣接サブＣＵで以前に探索された動きベクトルと組み合わせて予測ＣＵ７０２を生成する際にオーバーラップブロック動き補正（ＯＢＭＣ）が使用され得る。

【0056】

双予測が使用される場合、ＪＶＥＴはデコーダ側動きベクトル改良（ＤＭＶＲ）を用いて動きベクトルを探索し得る。ＤＭＶＲでは、バイラテラルテンプレートマッチング処理を用いた双予測で探索された２つの動きベクトルに基づいて動きベクトルを探索することができる。ＤＭＶＲでは、２つの動きベクトルの各々を用いて生成された予測ＣＵ７０２の組み合わせを重み付けしたものが探索され、その組み合わせ予測ＣＵ７０２を最良に指し示す新たな動きベクトルでそれら２つの動きベクトルを置き換えることによってそれら２つの動きベクトルを改良することができる。２つの改良された動きベクトルは、最終の予測ＣＵ７０２を生成するために使用され得る。

【0057】

上記のように７０４におけるイントラ予測または７０６におけるインター予測を用いて予測ＣＵ７０２が探索されると、７０８において、エンコーダは、現在のＣＵ１０２から予測ＣＵ７０２を減算して残差ＣＵ７１０を探索し得る。

【0058】

エンコーダは、データを変換ドメインに変換するための離散コサインブロック変換（ＤＣＴ変換）を使用するなどにより、７１２において１つ以上の変換操作を使用することにより、残差ＣＵ７１０を、変換ドメイン内における残差ＣＵ７１０を表す変換係数７１４に変換し得る。ＪＶＥＴでは、ＤＣＴ－ＩＩ、ＤＳＴ－ＶＩＩ、ＤＳＴ－ＶＩＩ、ＤＣＴ－ＶＩＩＩ、ＤＳＴ－Ｉ、ＤＣＴ－Ｖ操作など、ＨＥＶＣよりも多い種類の変換操作が可能である。許可された変換操作はサブセットにグループ化され、どのサブセットが使用されたのかおよびそれらサブセット内のどの特定操作が使用されたのかの指示がエンコーダによって通知され得る。いくつかの場合には、大きなブロックサイズ変換を使用して、特定のサイズよりも大きいＣＵ１０２の高周波変換係数をゼロにすることで、それらのＣＵ１０２に対して低周波数変換係数のみが維持されるようにする。

【0059】

いくつかの場合には、フォワードコア変換後の低周波数変換係数７１４にモード依存性非分離型二次変換（ＭＤＮＳＳＴ）が適用され得る。ＭＤＮＳＳＴ操作では、回転データに基づくハイパーキューブギブンズ変換（ＨｙＧＴ（Hypercube-Givens Transform））を使用することができる。これが使用される場合には、特定のＭＤＮＳＳＴ操作を識別するインデックス値がエンコーダによって通知され得る。

【0060】

７１６において、エンコーダは、変換係数７１４を量子化変換係数７１６に量子化し得る。各係数の量子化は、係数の値を量子化パラメータ（ＱＰ）から導出される量子化ステップで除算することによって計算され得る。いくつかの実施形態では、Ｑｓｔｅｐは２^{（ＱＰ－４）／６}として定義される。高精度の変換係数７１４を、とり得る有限数の値を有する量子化変換係数７１６に変換できるため、量子化はデータ圧縮を支援することができる。したがって、変換係数の量子化は、変換処理によって生成および送信されるビットの量を制限することができる。しかしながら、量子化は損失の多い操作であり、量子化による損失は回復できないが、量子化処理は、再構築されたシーケンスの品質と、シーケンスを表すのに必要な情報量とのトレードオフを示すものとなる。例えば、ＱＰ値が低いほど、デコードされたビデオの品質はより良いものとなるが、表現と送信に多くのデータ量が必要となり得る。対照的に、ＱＰ値が高いと、再構築されたビデオシーケンスの品質が低下し得るものとなり、より小さなデータと帯域幅が必要とされる。

【0061】

ＪＶＥＴは、すべてのＣＵ１０２が（フレームのすべてのＣＵ１０２のコーディングで同じフレームＱＰを使用する代わりに）そのコーディング処理のために異なる量子化パラメータを使用することを可能にする分散ベースの適応量子化技術を利用し得る。分散ベースの適応量子化技術では、特定のブロックの量子化パラメータを適応的に低下させる一方、他のブロックでは量子化パラメータを増加させる。ＣＵ１０２の特定のＱＰを選択するために、ＣＵの分散が計算される。つまり、ＣＵの分散がフレームの平均分散よりも高い場合には、フレームのＱＰよりも高いＱＰがＣＵ１０２に対して設定され得る。ＣＵ１０２がフレームの平均分散よりも低い分散を示す場合には、より低いＱＰが割り当てられ得る。

【0062】

７２０において、エンコーダは、量子化変換係数７１８をエントロピー符号化することによって最終圧縮ビット７２２を探索し得る。エントロピー符号化は、送信される情報の統計的な冗長性を取り除くことを目的とする。ＪＶＥＴでは、確率測度を使用して統計的な冗長性を除去するＣＡＢＡＣ（Context Adaptive Binary Arithmetic Coding）を使用して、量子化変換係数７１８をコーディングすることができる。非ゼロの量子化変換係数７１８を有するＣＵ１０２の場合、量子化変換係数７１８はバイナリに変換され得る。バイナリ表現の各ビット（「ビン」（ｂｉｎ））はコンテキストモデルを使用して符号化され得る。ＣＵ１０２は、３つの領域に分割することができる、各領域はその領域内のピクセルに対して使用するための独自のコンテキストモデルのセットを有している。

【0063】

ビンを符号化するために複数のスキャンパスが実行され得る。第１の３つのビン（ｂｉｎ０，ｂｉｎ１，ｂｉｎ２）を符号化するためのパスの期間に、ビンに使用するためのコンテキストモデルを示すインデックス値が、テンプレートによって識別され以前にコーディングされた最大５つの隣接する量子化変換係数７１８でそのビン位置の合計を求めることによって探索され得る。

【0064】

コンテキストモデルは、ビンの値が「０」または「１」である確率に基づき得る。値がコーディングされると、発生した「０」および「１」の値の実際の数に基づいてコンテキストモデルの確率が更新され得る。ＨＥＶＣでは一定のテーブルを使用して新たな画像ごとのコンテキストモデルを再初期化する一方、ＪＶＥＴでは、以前にコーディングされたインター予測画像に対して作られたコンテキストモデルに基づいて新たなインター予測画像のためのコンテキストモデルの確率が初期化され得る。

【0065】

エンコーダは、残差ＣＵ７１０のエントロピー符号化ビット７２２、選択されたイントラ予測モードまたは動きベクトルなどの予測情報、ＣＵ１０２がＱＴＢＴ構造に従ってＣＴＵ１００からどのように分割されたのかについての指示、および／または符号化されたビデオに関するその他の情報、を含むビットストリームを生成し得る。以下で説明するように、ビットストリームはデコーダによって復号化され得る。

【0066】

量子化変換係数７１８を用いて最終圧縮ビット７２２を探索することに加えて、エンコーダはさらに、デコーダが再構築ＣＵ７３４を生成するのに使用するのと同じ復号化処理に従って、量子化変換係数７１８を用いて再構築ＣＵ７３４を生成し得る。したがって、変換係数がエンコーダによって計算および量子化されると、その量子化変換係数７１８はエンコーダの復号化ループに送信され得る。ＣＵの変換係数を量子化した後、エンコーダは、復号化ループにより、デコーダが復号化処理で生成するものと同一の再構築ＣＵ７３４を生成することができる。したがって、エンコーダは、新たなＣＵ１０２のイントラ予測またはインター予測を実行する際には、デコーダが隣接ＣＵ１０２または参照画像に使用するのと同じ再構築ＣＵ７３４を使用し得る。再構築ＣＵ１０２、再構築スライス、またはフル再構築フレームは、さらなる予測段階のための参照として役立ち得る。

【0067】

再構築画像のピクセル値を取得するエンコーダの復号化ループ（デコーダの同様な動作については、以下参照）では逆量子化処理が実行され得る。フレームを逆量子化するために、例えば、フレームの各ピクセルの量子化値に量子化ステップ（例えば、上記したＱｓｔｅｐ）を乗算することで、再構築された逆量子化変換係数７２６が取得される。例えば、エンコーダにおける図７Ａに示された復号化処理において、残差ＣＵ７１０の量子化変換係数７１８が７２４で逆量子化されることで、逆量子化変換係数７２６が探索され得る。符号化の際にＭＤＮＳＳＴ操作が実行された場合、その操作は逆量子化後に元に戻すことができる。

【0068】

７２８において、逆量子化変換係数７２６が、例えば再構築画像を取得するべくその値にＤＣＴを適用するなどの方法により、逆変換されて再構築残差ＣＵ７３０が探索され得る。７３２において、再構築ＣＵ７３４を探索するために、再構築残差ＣＵ７３０が、７０４におけるイントラ予測または７０６におけるインター予測で探索された対応する予測ＣＵ７０２に加えられ得る。

【0069】

７３６において、１つ以上のフィルタが、画像レベルまたはＣＵレベルのいずれかで（エンコーダまたは後述するデコーダでの）復号化処理中に再構築データに適用され得る。例えば、エンコーダは、デブロッキングフィルタ、サンプル適応オフセット（ＳＡＯ）フィルタ、および／または適応ループフィルタ（ＡＬＦ）を適用し得る。エンコーダの復号化処理では、再構築画像内の潜在的なアーチファクトに対処可能な最適フィルタパラメータを推定してデコーダに送信するためにフィルタを使用し得る。このような改善により、再構築されたビデオの客観的および主観的な品質が向上する。デブロッキングフィルタ処理ではサブＣＵ境界付近のピクセルが変更され得る一方、ＳＡＯではＣＴＵ１００のピクセルがエッジオフセットまたはバンドオフセットのいずれかの分類を使用して変更され得る。ＪＶＥＴのＡＬＦでは、２×２ブロックごとに円対称の形状のフィルタが使用され得る。２×２ブロックごとに使用されるフィルタのサイズと識別子についての指示が通知され得る。あるいは、重み付け角度予測が予測ＣＵに実施されるいくつかの実施形態では、代替のフィルタが再構築ＣＵに適用され得るか、もしくはフィルタは再構築ＣＵに適用されない。

【0070】

再構築画像が参照画像である場合、それら再構築画像は、７０６における将来のＣＵ１０２のインター予測のために参照バッファ７３８に格納され得る。
上記したステップの間、ＪＶＥＴではコンテンツ適応クリッピング操作を使用して色値をクリッピング境界とするクリッピングの下限と上限との間に収めるように調整することができる。クリッピング境界はスライスごとに変更可能であり、この境界を識別するパラメータはビットストリームで通知され得る。

【0071】

図９は、ＪＶＥＴデコーダにおけるＣＵコーディングの簡略ブロック図を示す。ＪＶＥＴデコーダは、符号化されたＣＵ１０２に関する情報を含むビットストリームを受信し得る。ビットストリームは、画像のＣＵ１０２がＱＴＢＴ構造に従ってＣＴＵ１００からどのように分割されたのかを示し得る。非限定的な例として、ビットストリームは、クワッドツリー分割、対称バイナリ分割、および／または非対称バイナリ分割を使用して、ＱＴＢＴの各ＣＴＵ１００からＣＵ１０２がどのように分割されたのかを識別し得る。ビットストリームはさらに、イントラ予測モードまたは動きベクトルなどのＣＵ１０２の予測情報、およびエントロピー符号化された残差ＣＵを表すビット９０２を示し得る。

【0072】

９０４において、デコーダは、エンコーダによってビットストリームで通知されたＣＡＢＡＣコンテキストモデルを用いてエントロピー符号化ビット９０２を復号化し得る。デコーダは、エンコーダによって通知されたパラメータを用いて、符号化中に更新されたのと同じ方法でコンテキストモデルの確率を更新し得る。

【0073】

デコーダは、９０４でエントロピー符号化を元に戻して量子化変換係数９０６を探索した後、９０８でそれら量子化変換係数９０６を逆量子化して逆量子化変換係数９１０を探索し得る。符号化中にＭＤＮＳＳＴ操作が実行された場合、その操作は逆量子化後にデコーダによって元に戻すことができる。

【0074】

９１２において、逆量子化変換係数９１０が逆変換されて再構築残差ＣＵ９１４が探索され得る。９１６において、再構築ＣＵ９１８を探索するために、再構築残差ＣＵ９１４が、９２２におけるイントラ予測または９２４におけるインター予測で探索された対応する予測ＣＵ９２６に加えられ得る。

【0075】

したがって、ステップ９２３ａでは、重み付け角度予測がステップ９２２でイントラ予測モードとして実施されたかどうかが判定され得る。イントラ予測モードが重み付け角度予測を使用するものとしてステップ９２３ａで判定された場合、予測コーディングユニット９２６がフィルタ処理なしでエントロピー符号化に向けて送信され得る。しかしながら、イントラ予測モードが重み付け角度予測以外であるとステップ９２３ａで判定された場合は、エントロピー符号化に向けた送信に先立って、ＰＤＰＣフィルタ処理などのポストイントラ予測フィルタ処理９２３ｂが予測コーディングユニットに適用され得る。

【0076】

９２０において、１つ以上のフィルタが、画像レベルまたはＣＵレベルのいずれかで再構築データに適用され得る。例えば、デコーダは、デブロッキングフィルタ、サンプル適応オフセット（ＳＡＯ）フィルタ、および／または適応ループフィルタ（ＡＬＦ）を適用し得る。上記したように、フレームの客観的および主観的な品質を向上させるための最適フィルタパラメータを推定するために、エンコーダの復号化ループに配置されたループ内フィルタが使用され得る。これらのパラメータは、９２０で再構築フレームをフィルタ処理して、エンコーダにおけるフィルタ済み再構築フレームとマッチングさせるために、デコーダに送信される。

【0077】

再構築ＣＵ９１８を探索し、通知されたフィルタを適用することによって再構築画像が生成された後、デコーダは、その再構築画像を出力ビデオ９２８として出力することができる。再構築画像が参照画像として使用される場合、それら再構築画像は、９２４における将来のＣＵ１０２のインター予測のために参照バッファ９３０に格納され得る。

【0078】

図１０は、ＪＶＥＴデコーダにおけるＣＵコーディング１０００の方法の実施形態を示す。図１０に示される実施形態では、ステップ１００２で符号化ビットストリーム９０２が受信され、次いでステップ１００４で符号化ビットストリーム９０２に関連するＣＡＢＡＣコンテキストモデルが決定され、次いでステップ１００６でその決定されたＣＡＢＡＣコンテキストモデルを使用して符号化ビットストリーム９０２が復号化され得る。

【0079】

ステップ１００８では、符号化ビットストリーム９０２に関連する量子化変換係数９０６が決定され、次いでステップ１０１０で量子化変換係数９０６から逆量子化変換係数９１０が決定され得る。

【0080】

ステップ１０１２では、符号化中にＭＤＮＳＳＴ操作が行われたかどうか、および／またはＭＤＮＳＳＴ操作がビットストリーム９０２に適用された旨の指示をビットストリーム９０２が含むかどうかが決定され得る。符号化処理中にＭＤＮＳＳＴ操作が行われたと判定された場合、またはＭＤＮＳＳＴ操作がビットストリーム９０２に適用された旨の指示がビットストリーム９０２に含まれると判定された場合、ステップ１０１６で逆変換操作９１２がビットストリーム９０２に対して行われる前に、逆ＭＤＮＳＳＴ操作１０１４が実施され得る。あるいは、ステップ１０１４の逆ＭＤＮＳＳＴ演算を適用することなく、ステップ１０１６で逆変換操作９１２がビットストリーム９０２に対して行われ得る。ステップ１０１６の逆変換操作９１２により、再構築残差ＣＵ９１４を決定および／または構築することができる。

【0081】

ステップ１０１８において、ステップ１０１６による再構築残差ＣＵ９１４が予測ＣＵ９１８と組み合わせられ得る。予測ＣＵ９１８は、ステップ１０２０で決定されたイントラ予測ＣＵ９２２か、ステップ１０２２で決定されたインター予測ユニット９２４のうちの一方であり得る。

【0082】

したがって、ステップ１０２３ａでは、重み付け角度予測がステップ１０２０でイントラ予測モードとして実施されたかどうかが判定され得る。イントラ予測モードが重み付け角度予測を使用するものとしてステップ１０２３ａで判定された場合、予測コーディングユニット９２６がフィルタ処理なしでエントロピー符号化に向けて送信され得る、および／またはステップ１０２４で行われるフィルタ処理が変更および／または省略され得る。しかしながら、ステップ１０２３ａでイントラ予測モードが重み付け角度予測以外であると判断された場合、エントロピー符号化に向けた送信に先立って、ポストイントラ予測フィルタ処理１０２３ｂおよび／またはステップ１０２４でのＰＤＰＣフィルタ処理などが予測コーディングユニットに適用され得る。

【0083】

図１０に示されるように、いくつかの実施形態では、ステップ１０２３ｂは存在しなくてもよく、ポストイントラ予測フィルタ１０２４は、すべての予測についてステップ１０１８の後に実施され得る。図１０に示されるこのような実施形態では、イントラ予測モードが重み付け角度予測以外に基づくものである場合、適用されるフィルタは、ステップ１０２４で通常適用されるように適用することができる。しかしながら、イントラ予測モードが重み付け角度予測に基づいている場合は、ステップ１０２４のフィルタ処理がバイパスされてもよく、および／または、いくつかの実施形態では、ステップ１０２６における再構築ＣＵの出力前において、メイン参照、サイド参照、またはメイン参照とサイド参照の双方に対して、適用されるフィルタがバイアスされないものとされ得る。非限定的な例として、Ｃｖ１，Ｃｈ１の値は等しくてもよく、および／またはＣｖ２，Ｃｈ２の値は等しくてもよい。

【0084】

ステップ１０２４で任意の１つ以上のフィルタ９２０が再構築ＣＵ９１４に適用され、ステップ１０２６で出力が行われる。いくつかの実施形態では、ステップ１０２４でフィルタ９２０が適用されなくてもよい。

【0085】

いくつかの実施形態では、ステップ１０２８において、再構築ＣＵ９１８が参照バッファ９３０に格納され得る。
図１１は、ＪＶＥＴエンコーダにおけるＣＵコーディングの簡略ブロック図１１００を示す。ステップ１１０２において、ＪＶＥＴコーディングツリーユニットはクワッドツリーおよびバイナリツリー（ＱＴＢＴ）構造のルートノードとして表現され得る。いくつかの実施形態では、ＱＴＢＴは、ルートノードから分岐するクワッドツリーおよび／またはクワッドツリーのリーフノードの１つ以上から分岐するバイナリツリーを有し得る。ステップ１１０２に基づく表現は、ステップ１１０４、ステップ１１０６、またはステップ１１０８に進み得る。

【0086】

ステップ１１０４では、表現されたクワッドツリーノードを不均等サイズの２つのブロックに分割するために非対称バイナリ分割が実施され得る。いくつかの実施形態では、分割ブロックは、最終コーディングユニットを表し得るリーフノードとして、クワッドツリーノードから分岐するバイナリツリーで表現され得る。いくつかの実施形態では、クワッドツリーノードから分岐するリーフノードとしてのバイナリツリーは、さらなる分割が許可されない最終コーディングユニットを表す。いくつかの実施形態では、非対称分割は、コーディングユニットを、クワッドツリーノードの２５％を表す第１のブロックとクワッドツリーノードの７５％を表す第２のブロックとの不均等サイズのブロックに分割し得る。

【0087】

ステップ１１０６では、表現されたクワッドツリーノードを均等サイズの４つの正方形ブロックに分割するためにクワッドツリー分割が実施され得る。いくつかの実施形態では、分割ブロックは、最終コーディングユニットを表すクワッドツリーノードとして表現され得るか、あるいは、クワッドツリー分割、対称バイナリ分割、または非対称バイナリ分割を用いて再分割可能な子ノードとして表現され得る。

【0088】

ステップ１１０８では、表現されたクワッドツリーノードを均等サイズの２つのブロックに分割するためにクワッドツリー分割が実施され得る。いくつかの実施形態では、分割ブロックは、最終コーディングユニットを表すクワッドツリーノードとして表現され得るか、あるいは、クワッドツリー分割、対称バイナリ分割、または非対称バイナリ分割を用いて再分割可能な子ノードとして表現され得る。

【0089】

ステップ１１１０では、ステップ１１０６またはステップ１１０８からの子ノードが、符号化対象の子ノードとして表現され得る。いくつかの実施形態では、子ノードは、ＪＶＥＴでバイナリツリーのリーフノードによって表現され得る。

【0090】

ステップ１１１２では、ステップ１１０４またはステップ１１１０からのコーディングユニットは、ＪＶＥＴを用いて符号化され得る。
図１２は、ＪＶＥＴデコーダにおけるＣＵ復号化のための簡略ブロック図１２００を示す。図１２に示される実施形態では、ステップ１２０２において、コーディングツリーユニットがＱＴＢＴ構造に従ってどのように複数のコーディングユニットに分割されたのかを示すビットストリームが受信され得る。このビットストリームは、クワッドツリーノードが、クワッドツリー分割、対称バイナリ分割、および非対称バイナリ分割のうちの少なくとも１つを用いてどのように分割されるのかを示す。

【0091】

ステップ１２０４では、ＱＴＢＴ構造のリーフノードによって表現されたコーディングユニットが識別され得る。いくつかの実施形態では、コーディングユニットは、ノードが非対称バイナリ分割を用いてクワッドツリーのリーフノードから分割されたかどうかを示し得る。いくつかの実施形態では、コーディングユニットは、ノードが復号化対象の最終コーディングユニットを表すことを示し得る。

【0092】

ステップ１２０６では、識別されたコーディングユニットがＪＶＥＴを用いて復号化され得る。
図１３は、効率を向上させたコーディングシステムおよび方法の簡略ブロック図１３００を示す。コーディングおよびデコーディングシステムでは、コーディングブロックとその近傍との相関を利用するために予測がイントラコーディングで生成される。ＪＶＥＴでは、コーディングブロックの上部境界に隣接する参照行と左側境界に隣接する参照列とが予測生成処理で使用される。各イントラ予測モードについて、ＰＵ内の各ピクセルの基準線に沿った投影隣接位置が、決定されたイントラモードに関連する角度方向を用いて決定される。参照列に沿った投影隣接は、水平モード（モード２～３３）のメイン参照線として機能し、参照行に沿った投影隣接は、垂直モード（モード３５～６６）のメイン参照線として機能する。予測の生成で部分的に使用される参照列または参照行は、サイド参照線と呼ばれる。図８に示されるように、イントラ予測モード２およびモード６６は同じ予測角度を共有する。ただし、モード２で左隣を参照として使用し、モード６６は上隣を参照として使用する。したがって、これらの２つのモード（２および６６）を組み合わせて１つのコードワードによりこれらの２つのモードを通知してオーバーヘッドビットの削減を図るようにすることで、コーディング効率を向上させることができる。

【0093】

ステップ１３０２ではコーディング予測モードが決定され、次いでステップ１３０４ではコーディングモードがモード２であるかモード６６であるかが決定される。決定されたコーディング予測モードが、モード２やモード６６以外である場合は、任意の既知の適当なおよび／または所望のコーディング予測技術が使用され得る。しかしながら、コーディングモード予測モード２または６６が決定された場合、改良されたより効率的な予測コーディングが実施され得る。

【0094】

開示されるイントラ予測モードは、１つのコーディングモードを用いて２つのイントラ予測、すなわちモード２とモード６６を組み合わせる。方法１３００は、２つのイントラ予測モードであるモード２およびモード６６の予測精度を維持しつつ、エンコーダおよびデコーダの両方で予測方向を選択する際の負担を大幅に増加させないようにする。したがって、新規のモードは、その予測の予測方向がより適切な予測をもたらすとき、別のモードではなく１つのモードの予測に従うように適応的にその予測を設定することができ、その逆も同様である。いくつかの実施形態では、１つの発見的アプローチは、利用可能なコーディング情報をデコーダ側で使用して２つのモード（２および６６）間の選択を行うことである。新たな組み合わせモードの予測方向を決定するために種々の情報が使用され得る。いくつかの実施形態では、幅または高さなどのブロック寸法が選択基準として使用され得る。このような実施形態では、予測方向がより長い境界を有する方向に従うように選択され得る。しかしながら、代替実施形態では、より短い境界を有する予測方向が選択され得る。

【0095】

非限定的な例として、選択基準としてのブロック寸法および予測モード２および６６を用いて、座標（ｘ，ｙ）における重み付け角度予測の予測ピクセルＰ（ｘ，ｙ）は、以下のように計算され得る。

【0096】

Ｐ［ｘ，ｙ］＝Ｒｅｃｏｎ［ｘ＋ｙ＋２，－１］（幅＞高さの場合）
Ｐ［ｘ，ｙ］＝Ｒｅｃｏｎ［－１，ｘ＋ｙ＋２］（別の条件の場合）
ここで、Ｒｅｃｏｎ［０，０］は、現在のＣＵの左上の座標（０，０）にある再構築ピクセルである。

【0097】

代替の非限定的な例では、参照行に沿ったピクセル差（例えば、分散）と参照列に沿ったピクセル差が使用され得る。このような実施形態において、予測方向はより小さい（またはより大きい）ピクセル差を有するものとなる方向に従うように選択され得る。

【0098】

いくつかの実施形態において、重み付け角度予測では、上部参照行と左側参照列の両方の投影位置にあるピクセルを使用して角度予測用の予測ピクセルを生成することができる。ＪＶＥＴモード２またはモード６６の場合、座標（ｘ，ｙ）における重み付け角度予測の予測ピクセルＰ（ｘ，ｙ）は、以下のように計算され得る。

【0099】

Ｐ［ｘ，ｙ］＝（（（（ｘ＋１）＊Ｒｅｃｏｎ［ｘ＋ｙ＋２，－１］）＋（（ｙ＋１）＊（Ｒｅｃｏｎ［－１，ｘ＋ｙ＋２］））＋（ｙ＋ｘ＋２）／２）／（ｙ＋ｘ＋２））
ここで、Ｒｅｃｏｎ［０，０］は、現在のＣＵの左上の座標（０，０）にある再構築ピクセルである。

【0100】

システムおよび方法は、重み付け角度予測に使用されない、モード２かモード６６のいずれかのモードインデックスを割り当てることにより、重み付け角度予測をサポートするように拡張され得る。すなわち、モード２が重み付け角度予測に割り当てられる場合、モード６６は他の任意の既知の適当なおよび／または所望の予測方法に割り当てられ得る。いくつかの実施形態では、逆が当てはまる場合もあり、モード６６が重み付け角度予測に割り当てられ、モード２が他の任意の既知の適当なおよび／または所望の予測方法に割り当てられ得る。

【0101】

図１４は、図７Ａおよび図７Ｂに示され説明されたものと実質的に同様のＪＶＥＴエンコーダにおける効率を向上させたＣＵコーディングの簡略ブロック図を示す。図１４は、ステップ１４０２，１４０４，１４０６をさらに含むシステムおよび方法を示し、ステップ１４０２では、イントラ予測モード２または６６が使用されるかどうかが決定される。次いでステップ１４０４では、標準／既知および／または適当な予測コーディングが使用され、ステップ１４０６では、重み付けまたは非重み付け角度予測についての図１３に関して上記したように、選択された修正予測コーディングが予測モードに対して使用され得る。このステップ１４０６は、重み付け角度予測が決定されたのかまたは非重み付け角度予測が決定されたのかに関する決定がステップ７０５ａでなされた後のステップである。すなわち、新規のモードは、その予測の予測方向がより適切な予測をもたらすとき、別のモードではなく１つのモードの予測に従うように適応的にその予測を設定することができ、その逆も同様である。いくつかの実施形態では、１つの発見的アプローチは、利用可能なコーディング情報をデコーダ側で使用して２つのモード（２および６６）間の選択を行うことである。新たな組み合わせモードの予測方向を決定するために種々の情報が使用され得る。いくつかの実施形態では、幅または高さなどのブロック寸法が選択基準として使用され得る。このような実施形態では、予測方向がより長い境界を有する方向に従うように選択され得る。しかしながら、代替実施形態では、より短い境界を有する予測方向が選択され得る。

【0102】

代替実施形態において、ステップ７０５ｂのポストフィルタ処理（図７Ａおよび図７Ｂに図示）が、図７Ａおよび図７Ｂに関して示されおよび説明されたシステムおよび方法において同時に実装可能であることは当業者に容易に明らかである。

【0103】

図１５は、ＪＶＥＴデコーダにおいて効率を向上させたＣＵデコーディングの簡略ブロック図を示す。図１５は、ステップ１４０２，１４０４，１４０６をさらに含むシステムおよび方法を示し、ステップ１４０２では、イントラ予測モード２が使用されるのかまたはイントラ予測モード６６が使用されるのかに関する決定が行われる。次いでステップ１４０４では、標準／既知および／または適当な予測コーディングが使用され、ステップ１４０６では、重み付けまたは非重み付け角度予測についての図１３に関して上記したように、選択された修正予測コーディングが予測モードに対して使用され得る。このステップ１４０６は、重み付け角度予測が決定されたのかまたは非重み付け角度予測が決定されたのかに関する決定がステップ９２３ａでなされた後のステップである。

【0104】

代替実施形態において、ステップ９２３ｂのポストフィルタ処理が、図９に関して示され説明されたシステムおよび方法において同時に実装可能であることは当業者に容易に明らかである。

【0105】

上記実施形態を実施するために必要な命令のシーケンスの実行は、図１６に示されるようなコンピュータシステム１６００によって行われ得る。一実施形態では、命令のシーケンスの実行は単一のコンピュータシステム１６００によって行われ得る。他の実施形態によれば、通信リンク１６１５によって結合された２つ以上のコンピュータシステム１６００が互いに協調して命令のシーケンスを実行し得る。以下では、１つのコンピュータシステム１６００のみについての説明を行うが、上記実施形態を実施するために任意の数のコンピュータシステム１６００を使用できることが理解され得る。

【0106】

以下、一実施形態によるコンピュータシステム１６００を、コンピュータシステム１３００の機能的構成要素のブロック図である図１６を参照して説明する。本明細書で使用されるコンピュータシステム１６００という用語は、１つ以上のプログラムを記憶してそれを個別に実行可能な任意のコンピューティングデバイスを説明するために広く使用される。

【0107】

各コンピュータシステム１６００は、バス１６０６に結合された通信インターフェース１６１４を含み得る。通信インターフェース１６１４は、コンピュータシステム１６００間の双方向通信を提供する。各コンピュータシステム１６００の通信インターフェース１６１４は、例えば、命令、メッセージ、およびデータなどの種々のタイプの信号情報を表すデータストリームを含む電気信号、電磁気信号、または光信号を送受信する。通信リンク１６１５は、１つのコンピュータシステム１６００を別のコンピュータシステム１６００とリンクさせる。例えば、通信リンク１６１５がＬＡＮである場合、通信インターフェース１６１４はＬＡＮカードとすることができ、通信リンク１６１５がＰＳＴＮである場合、通信インターフェース１６１４は統合サービスデジタルネットワーク（ＩＳＤＮ）カードまたはモデムとすることができ、通信リンク１６１５がインターネットである場合、通信インターフェース１６１４は、ダイヤルアップ、ケーブル、または無線モデムとすることができる。

【0108】

コンピュータシステム１６００は、対応する通信リンク１６１５および通信インターフェース１６１４を介して、メッセージ、データ、および命令（プログラム、すなわちアプリケーションやコードを含む）を送受信することができる。受信されたプログラムコードは、その受信時に対応するプロセッサ１６０７によって実行され得る、および／または後で実行するために記憶デバイス１６１０または他の関連する不揮発性媒体に記憶され得る。

【0109】

一実施形態では、コンピュータシステム１６００は、データ記憶システム１６３１、例えば、コンピュータシステム１６００が容易にアクセス可能なデータベース１６３２を含むデータ記憶システム１６３１と連携して動作する。コンピュータシステム１６００は、データインターフェース１６３３を介してデータ記憶システム１６３１と通信する。バス１６０６に結合されたデータインターフェース１６３３は、例えば命令、メッセージ、およびデータなどの種々のタイプの信号情報を表すデータストリームを含む電気信号、電磁気信号、または光信号を送受信する。実施形態では、データインターフェース１６３３の機能は通信インターフェース１６１４によって実行され得る。

【0110】

コンピュータシステム１６００は、命令、メッセージ、およびデータ（総称して、情報）を通信するためのバス１６０６または他の通信機構と、情報を処理するためにバス１６０６に結合された１つまたは複数のプロセッサ１６０７とを含む。コンピュータシステム１６００はさらに、プロセッサ１６０７によって実行される動的データおよび命令を記憶するためにバス１６０６に結合されたランダムアクセスメモリ（ＲＡＭ）または他の動的記憶デバイスなどのメインメモリ１６０８を含む。メインメモリ１６０８は、プロセッサ１６０７による命令の実行中に、一時的データ、すなわち変数または他の中間情報を記憶するためにも使用され得る。

【0111】

コンピュータシステム１６００はさらに、バス１６０６に結合されてプロセッサ１６０７のための静的データおよび命令を記憶するための読み取り専用メモリ（ＲＯＭ）１６０９または他の静的記憶デバイスを含み得る。また、磁気ディスクまたは光ディスクなどの記憶デバイス１６１０も提供され、プロセッサ１６０７のためのデータおよび命令を記憶するためにバス１６０６に結合され得る。

【0112】

コンピュータシステム１６００は、これらに限定されないが、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）モニタなどの、ユーザに情報を表示するためのディスプレイデバイス１６１１にバス１６０６を介して結合され得る。入力デバイス１６１２、例えば、英数字および他のキーなどの入力デバイスは、プロセッサ１６０７に情報およびコマンド選択を通信するためにバス１６０６に結合される。

【0113】

一実施形態によれば、個々のコンピュータシステム１６００は、メインメモリ１６０８に含まれる１つ以上の命令の１つ以上のシーケンスを実行するそれぞれのプロセッサ１６０７によって特定の動作を行う。このような命令は、ＲＯＭ１６０９または記憶デバイス１６１０などの別のコンピュータ使用可能媒体からメインメモリ１６０８に読み込まれ得る。プロセッサ１６０７は、メインメモリ１６０８に含まれる命令のシーケンスを実行することにより、本明細書で説明される処理を実行する。別の実施形態では、ハードワイヤード回路が、ソフトウェア命令の代わりにまたはそれと組み合わせて使用され得る。したがって、実施形態は、ハードウェア回路および／またはソフトウェアの特定の組み合わせに限定されない。

【0114】

本明細書で使用される「コンピュータ使用可能媒体」という用語は、情報を提供する、またはプロセッサ１６０７によって使用可能な任意の媒体を指す。このような媒体は、これらに限定されないが、不揮発性、揮発性、および伝送媒体を含む多くの形態をとり得る。不揮発性媒体、すなわち電力がなくても情報を保持できる媒体には、ＲＯＭ１３０９、ＣＤ－ＲＯＭ、磁気テープ、および磁気ディスクが含まれる。揮発性媒体、すなわち電力がないと情報を保持できない媒体には、メインメモリ１６０８が含まれる。伝送媒体には、バス１６０６を構成するワイヤを含む、同軸ケーブル、銅線、および光ファイバが含まれる。伝送媒体は、搬送波、すなわち、情報信号を送信するために周波数、振幅、または位相などで変調され得る電磁波の形態をとり得る。また、伝送媒体は、電波および赤外線データの通信中に生成されるものなどの音波または光波の形態をとり得る。

【0115】

本明細書では、上記実施形態をその特定の要素を参照して説明した。しかしながら、実施形態のより広い思想および範囲から逸脱することなく、種々の修正および変更をそれらに加えることができることは明らかである。例えば、本明細書で説明する処理フロー図に示された処理動作の特定の順序や組み合わせは単なる例示であり、異なる処理動作や追加の処理動作を使用したり、または処理動作の異なる組み合わせや異なる順序を使用したりして上記実施形態を実施できることが理解され得る。したがって、本明細書および図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。

【0116】

また、本発明は、種々のコンピュータシステムで実施することもできる。本明細書で説明する種々の手法は、ハードウェアもしくはソフトウェア、またはそれらの組み合わせで実装することができる。好ましくは、これらの手法は、プロセッサと、プロセッサが読み取り可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶要素を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを各々含むプログラマブルコンピュータ上で実行されるコンピュータプログラムにおいて実装される。上記の機能を実行して出力情報を生成するために、入力デバイスを使用して入力されたデータにプログラムコードが適用される。出力情報は、１つまたは複数の出力デバイスに適用される。各プログラムは、コンピュータシステムと通信するために、好ましくは、高レベル手続き型プログラミング言語またはオブジェクト指向プログラミング言語で実装される。しかしながら、プログラムは、必要に応じてアセンブリ言語または機械語で実装され得る。いずれの場合も、言語はコンパイル言語またはインタープリター言語とすることができる。このような各コンピュータプログラムは、好ましくは、汎用または専用プログラマブルコンピュータによって読み取り可能な記憶媒体または記憶デバイス（例えば、ＲＯＭまたは磁気ディスク）に記憶され、コンピュータによって記憶媒体または記憶デバイスが読み取られたときにコンピュータを構成するとともに動作させて上記の手順を実行するためのものである。また、システムは、コンピュータプログラムで構成されたコンピュータ可読記憶媒体として実装されると見なすこともでき、そのように構成された記憶媒体はコンピュータを特定の所定の方法で動作させる。さらに、例示的なコンピューティングアプリケーションの記憶要素は、種々の組み合わせおよび構成でデータを記憶可能なリレーショナルまたはシーケンシャル（フラットファイル）タイプのコンピューティングデータベースとすることができる。

【0117】

図１７は、本明細書で説明されるシステムおよびデバイスの特徴を組み込むことができるソースデバイス１７１２および宛先デバイス１７１０の高レベル図である。図１７に示されるように、例示的なビデオコーディングシステム１７１０はソースデバイス１７１２と宛先デバイス１７１４を含み、この例において、ソースデバイス１７１２は符号化ビデオデータを生成する。したがって、ソースデバイス１７１２はビデオ符号化デバイスと呼ばれ得る。宛先デバイス１７１４は、ソースデバイス１７１２によって生成された符号化ビデオデータを復号化し得る。したがって、宛先デバイス１７１４はビデオ復号化デバイスと呼ばれ得る。ソースデバイス１７１２および宛先デバイス１７１４はビデオコーディングデバイスの例であり得る。

【0118】

宛先デバイス１７１４は、チャネル１７１６を介してソースデバイス１７１２から符号化ビデオデータを受信し得る。チャネル１７１６は、ソースデバイス１７１２から宛先デバイス１７１４に符号化ビデオデータを移動させることができる任意のタイプの媒体またはデバイスを備え得る。一例では、チャネル１７１６は、ソースデバイス１７１２が符号化ビデオデータをリアルタイムで宛先デバイス１７１４に直接送信可能とする通信媒体を備え得る。

【0119】

この例では、ソースデバイス１７１２は、ワイヤレス通信プロトコルなどの通信規格に従って符号化ビデオデータを変調し、その変調ビデオデータを宛先デバイス１７１４に送信し得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つ以上の物理的伝送線などの無線または有線通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどのパケットベースのネットワークの一部を形成し得る。通信媒体は、ソースデバイス１７１２から宛先デバイス１７１４への通信を支援するルータ、スイッチ、基地局、または他の機器を含み得る。別の例では、チャネル１７１６は、ソースデバイス１７１２によって生成された符号化ビデオデータを記憶する記憶媒体に対応し得る。

【0120】

図１７の例では、ソースデバイス１７１２は、ビデオソース１７１８、ビデオエンコーダ１７２０、および出力インターフェース１７２２を含む。いくつかの場合では、出力インターフェース１７２８は、変調器／復調器（モデム）、および／または送信機を含み得る。ソースデバイス１７１２において、ビデオソース１７１８は、ビデオキャプチャデバイス（例えば、ビデオカメラ）、以前にキャプチャされたビデオデータを含むビデオアーカイブ、ビデオコンテンツプロバイダからのビデオデータを受信するためのビデオフィードインターフェース、および／またはビデオデータを生成するためのコンピュータグラフィックスシステム、などのソース、あるいはそのようなソースの組み合わせを含み得る。

【0121】

ビデオエンコーダ１７２０は、キャプチャされた、プリキャプチャされた、またはコンピュータによって生成されたビデオデータを符号化し得る。入力画像は、ビデオエンコーダ１７２０によって受信され、入力フレームメモリ１７２１に記憶され得る。汎用プロセッサ１７２３は、このメモリ１７２１から情報をロードして符号化を実行し得る。汎用プロセッサを駆動するためのプログラムは、図１７に示される例示的なメモリモジュールなどの記憶デバイスからロードされ得る。汎用プロセッサは処理メモリ１７２２を使用して符号化を実行し、汎用プロセッサによる符号化情報の出力は出力バッファ１７２６などのバッファに記憶され得る。

【0122】

ビデオエンコーダ１７２０は、少なくとも１つのベースレイヤおよび少なくとも１つのエンハンスメントレイヤを定義するスケーラブルビデオコーディング方式でビデオデータをコーディング（例えば、符号化）するように構成され得るリサンプリングモジュール１７２５を含み得る。リサンプリングモジュール１７２５は、符号化処理の一部として少なくともいくつかのビデオデータをリサンプリングすることができ、このリサンプリングは、リサンプリングフィルタを使用して適応的な方法で実行することができる。

【0123】

符号化ビデオデータ、例えば、コーディングされたビットストリームは、ソースデバイス１７１２の出力インターフェース１７２８を介して宛先デバイス１７１４に直接送信され得る。図１７の例では、宛先デバイス１７１４は、入力インターフェース１７３８と、ビデオデコーダ１７３０と、表示デバイス１７３２とを含む。いくつかの場合では、入力インターフェース１７２８は、受信機および／またはモデムを含み得る。宛先デバイス１７１４の入力インターフェース１７３８は、チャネル１７１６を介して符号化ビデオデータを受信する。符号化ビデオデータは、ビデオエンコーダ１７２０によって生成された、ビデオデータを表す種々の構文要素を含み得る。このような構文要素は、通信媒体上で送信されるか、記憶媒体上に記憶されるか、またはファイルサーバに記憶された符号化ビデオデータに含まれ得る。

【0124】

また、符号化ビデオデータは、復号化および／または再生のために宛先デバイス１７１４によって後でアクセスするために記憶媒体またはファイルサーバに記憶され得る。例えば、コーディングされたビットストリームは、一時的に入力バッファ１７３１に記憶された後、汎用プロセッサ１７３３にロードされ得る。汎用プロセッサを駆動するためのプログラムは記憶デバイスまたはメモリからロードされ得る。汎用プロセッサは、プロセスメモリ１７３２を使用して復号化を実行し得る。また、ビデオデコーダ１７３０は、ビデオエンコーダ１７２０において使用されるリサンプリングモジュール１７２５と同様のリサンプリングモジュール１７３５を含み得る。

【0125】

図１７は、汎用プロセッサ１７３３とは別個にリサンプリングモジュール１７３５を示すが、リサンプリング機能が汎用プロセッサによって実行されるプログラムによって実現され得ること、およびビデオエンコーダの処理が１つ以上のプロセッサを用いて実現され得ることを当業者は理解し得る。復号化画像は、出力フレームバッファ１７３６に記憶された後、入力インターフェース１７３８に送信され得る。

【0126】

ディスプレイデバイス１７３８は、宛先デバイス１７１４と一体とされ得るか、または宛先デバイス１７１４に外付けされ得る。いくつかの例では、宛先デバイス１７１４は、一体型ディスプレイデバイスを含み得るとともに、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス１７１４がディスプレイデバイスであり得る。概して、ディスプレイデバイス１７３８は、復号化ビデオデータをユーザに表示する。

【0127】

ビデオエンコーダ１７２０およびビデオデコーダ１７３０はビデオ圧縮規格に従って動作し得る。ＩＴＵ－Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は、現在の高効率ビデオコーディング（High Efficiency Video Coding：ＨＥＶＣ）標準の圧縮能力を大幅に超える圧縮機能を備えた将来のビデオコーディング技術の標準化（画面コンテンツコーディングおよびハイダイナミックレンジコーディングの現在の拡張と短期的な拡張とを含む）の潜在的ニーズを研究している。このグループは、この分野の専門家によって提案された圧縮技術設計を評価するために、ジョイントビデオエクスプロレーションチーム（ＪＶＥＴ）と呼ばれる共同コラボレーション活動でこの調査活動に協力している。ＪＶＥＴ開発の最近の成果は、J.Chen、E.Alshina、G.Sullivan、J.Ohm、J.Boyceによる"Algorithm Description of Joint Exploration Test Model 5 (JEM 5)", JVET-E1001-V2で説明されている。

【0128】

追加的にまたは代替的に、ビデオエンコーダ１７２０およびビデオデコーダ１７３０は、開示されたＪＶＥＴ機能で機能する他の独自の仕様または業界標準に従って動作し得る。したがって、ＩＴＵ－Ｔ Ｈ．２６４規格（ＭＰＥＧ－４、パート１０、アドバンスドビデオコーディング（ＡＶＣ）とも呼ばれる）などのその他の規格、またはそのような規格の拡張機能である。したがって、ＪＶＥＴのために新たに開発されたものであるが、本開示の技術は、特定のコーディング標準または技術に限定されるものではない。ビデオ圧縮規格および技術の他の例には、ＭＰＥＧ－２や、ＩＴＵ－Ｔ Ｈ．２６３や、独自仕様またはオープンソースの圧縮形式および関連する形式が含まれる。

【0129】

ビデオエンコーダ１７２０およびビデオデコーダ１７３０は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装され得る。例えば、ビデオエンコーダ１７２０およびビデオデコーダ１７３０は、１つ以上のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック、またはそれらの任意の組み合わせを使用し得る。ビデオエンコーダ１７２０およびビデオデコーダ１７３０が部分的にソフトウェアで実装される場合、デバイスは、適切な非一時的コンピュータ可読記憶媒体にソフトウェアの命令を記憶し、１つ以上のプロセッサを用いたハードウェアでそれらの命令を実行してこの開示の技術を実施する。ビデオエンコーダ１７２０およびビデオデコーダ１７３０の各々は、１つまたは複数のエンコーダまたはデコーダに含めることができ、いずれも、対応するデバイスの複合エンコーダ／デコーダ（コーデック）の一部として統合することができる。

【0130】

本明細書に記載される主題の態様は、上記の汎用プロセッサ１７２３，１７３３などのコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明され得る。一般に、プログラムモジュールには、特定のタスクを実行したり、特定の抽象データタイプを実装したりするルーチン、プログラム、オブジェクト、成分、データ構造などが含まれる。本明細書に記載される主題の態様は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置され得る。

【0131】

メモリの例としては、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、またはその両方が挙げられる。メモリは、上記した技術を実施するためのソースコードまたはバイナリコードなどの命令を記憶し得る。メモリは、プロセッサ１７２３，１７３３などのプロセッサによって実行される命令の実行中に変数または他の中間情報を記憶するためにも使用され得る。

【0132】

また、記憶デバイスは、上記した技術を実施するための命令、ソースコード、またはバイナリコードなどの命令を記憶し得る。さらに、記憶デバイスは、コンピュータプロセッサによって使用および扱われるデータを記憶し得る。例えば、ビデオエンコーダ１７２０またはビデオデコーダ１７３０内の記憶デバイスは、コンピュータシステム１７２３またはコンピュータシステム１７３３によってアクセスされるデータベースであり得る。記憶デバイスの他の例としては、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードドライブ、磁気ディスク、光ディスク、ＣＤ－ＲＯＭ、ＤＶＤ、フラッシュメモリ、ＵＳＢメモリカード、またはコンピュータ読み取り可能な任意の他の媒体が挙げられる。

【0133】

メモリまたは記憶デバイスは、ビデオエンコーダおよび／またはビデオデコーダによって、あるいはそれに関連して使用するための非一時的なコンピュータ可読記憶媒体の一例であり得る。非一時的なコンピュータ可読記憶媒体は、特定の実施形態によって説明される機能を実行するように構成されたコンピュータシステムを制御するための命令を含む。これらの命令は、１つまたは複数のコンピュータプロセッサによって実行されることにより、特定の実施形態で説明されるものを実施するように構成され得る。

【0134】

また、いくつかの実施形態は、フロー図またはブロック図として表され得る処理として説明されている。動作を順次処理として説明しているが、動作の多くは並列または同時に実行することができる。また、動作の順序を入れ替えることもできる。処理は、図に含まれていない追加のステップを含み得る。

【0135】

特定の実施形態は、命令実行システム、装置、システム、または機械によって使用したり、またはそれに関連して使用したりするための非一時的なコンピュータ可読記憶媒体に実装され得る。コンピュータ可読記憶媒体は、特定の実施形態によって説明される方法を実施するようにコンピュータシステムを制御するための命令を含む。コンピュータシステムは、１つまたは複数のコンピューティングデバイスを含み得る。命令は、１つまたは複数のコンピュータプロセッサによって実行されることにより、特定の実施形態で説明されるものを実行するように構成され得る。

【0136】

本明細書の説明および特許請求の範囲全体で使用される「１つ」は、文脈から明らかにそうでないと示されない限り、複数の参照を含む。また、本明細書の説明および特許請求の範囲全体で使用される「～内に」の意味は、文脈が明確に指示しない限り、「～内に」と「～上に」の意味を含む。

【0137】

本発明の例示的な実施形態を詳細にかつ上記の構造的特徴および／または方法の動作に固有の用語で説明したが、本発明の新規の教示および利点から実質的に逸脱することなく多くの追加の変更が例示的な実施形態において可能であることを当業者は容易に理解し得る。さらに、特許請求の範囲で定義される主題は、上記した特定の特徴または動作に必ずしも限定されない。したがって、これらの実施形態およびすべてのそのような変更は、添付の特許請求の範囲に従った広さおよび範囲で解釈される本発明の範囲内に含まれることが意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】