(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-06-09
(45)【発行日】2023-06-19
(54)【発明の名称】イントラモードJVETコーディング
(51)【国際特許分類】
H04N 19/46 20140101AFI20230612BHJP
H04N 19/593 20140101ALI20230612BHJP
【FI】
H04N19/46
H04N19/593
(21)【出願番号】P 2020503788
(86)(22)【出願日】2018-07-24
(86)【国際出願番号】 US2018043438
(87)【国際公開番号】W WO2019023200
(87)【国際公開日】2019-01-31
【審査請求日】2021-07-21
(32)【優先日】2017-07-24
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2018-07-24
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】514188564
【氏名又は名称】アリス エンタープライジズ エルエルシー
【氏名又は名称原語表記】ARRIS ENTERPRISES LLC
【住所又は居所原語表記】3871 Lakefield Drive, Suwanee, GA 30024, U.S.A.
(74)【代理人】
【識別番号】100105957
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【氏名又は名称】恩田 博宣
(72)【発明者】
【氏名】ユ、ユエ
(72)【発明者】
【氏名】ワン、リミン
【審査官】田中 純一
(56)【参考文献】
【文献】国際公開第2017/086746(WO,A1)
【文献】国際公開第2013/000324(WO,A1)
【文献】特開2015-167267(JP,A)
【文献】米国特許出願公開第2014/0119439(US,A1)
【文献】米国特許出願公開第2018/0316913(US,A1)
【文献】特表2019-530367(JP,A)
【文献】Yu Han, Jicheng An, Jianhua Zheng,Improvements for Intra Prediction Mode Coding [online], JVET-G JVET-G0060,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/7_Torino/wg11/JVET-G0060-v2.zip>,2018年12月15日,1-4
【文献】Vadim Seregin, Wei-Jung Chien, Marta Karczewicz, Nan Hu,Block shape dependent intra mode coding [online], JVET-D JVET-D0114r1,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/4_Chengdu/wg11/JVET-D0114-v2.zip>,2017年11月11日,1-3
【文献】Jianle Chen, Elena Alshina, Gary J. Sullivan, Jens-Rainer Ohm, Jill Boyce,Algorithm Description of Joint Exploration Test Model 5 (JEM 5) [online], JVET-E JVET-E1001-v2,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/5_Geneva/wg11/JVET-E1001-v2.zip>,2017年11月11日,i-iii, 1-41
【文献】Yue Yu, Limin Wang, Krit Panusopone,Non-EE1: Priority List Based Intra Mode Coding with 5 MPM [online], JVET-H JVET-H0051,ITU-T インターネット<URL:http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/8_Macau/wg11/JVET-H0051-v2.zip>,2018年12月15日,1-5
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00 - 19/98
(57)【特許請求の範囲】
【請求項1】
動画データを復号化する方法であって、
(a)前記動画データの現在のブロックに対する第1組の最確モード(MPM)を決定するステップと、ここで、前記第1組のMPMは、MPMインデックスに基づいて選択可能であり、前記MPMインデックスに基づいて選択可能である前記第1組のMPMのうちの1つは、真水平モードを含み、前記MPMインデックスに基づいて選択可能である前記第1組のMPMのうちの別の1つは、真垂直モードを含み、前記MPMインデックスに基づいて選択可能である前記第1組のMPMのうちの別の1つは、角度モードを含み、前記第1組のMPMは、異なる5つのモードのみを含んでおり、
(b)ビットストリームから、合計1ビットを含むMPMフラグと別のインデックスとを導出するステップと、ここで、前記MPMフラグと別のインデックスとの少なくとも1つは、前記現在のブロックを予測するためのイントラモードが前記第1組のMPMのうちの1つであるかどうかを示しており、
(c)前記MPMフラグと前記別のインデックスとの少なくとも1つが、前記現在のブロックを予測するための前記イントラモードが前記MPMインデックスに基づいて選択可能である前記第1組のMPMのうちの1つであることを示す場合、前記第1組のMPMのうちの1つの前記ビットストリームから復号化された前記MPMインデックスに基づいて前記現在のブロックのイントラモードを選択するステップと、
(d)前記MPMフラグと前記別のインデックスとの少なくとも1つが、前記現在のブロックを予測するための前記イントラモードが前記第1組のMPMのうちの1つではないことを示す場合、前記MPMフラグおよび前記別のインデックスによって、(i)第2組の少なくとも1つのモードを決定するステップ、および(ii)第3組の少なくとも1つのモードを決定するステップと、
(e)ここで、前記第1組、前記第2組、および前記第3組は、異なるモードを含み、前記第1組、前記第2組、および前記第3組の組み合わせは、67個の異なるモードを含んでおり、
(f)前記第1組のMPMに含まれる前記MPMインデックスに基づいて選択可能である前記第1組のMPMのいずれも含まない前記MPMフラグおよび前記別のインデックスの第1の組み合わせに基づいた前記第2組の少なくとも1つのモードについての前記現在のブロックのイントラモードを決定するステップと、
(g)前記第1組のMPMに含まれる前記MPMインデックスに基づいて選択可能である前記第1組のMPMのいずれも含まない前記MPMフラグおよび前記別のインデックスの第2の組み合わせに基づいた前記第3組の少なくとも1つのモードについての前記現在のブロックのイントラモードを決定するステップと、を備える方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、動画コーディング、より具体的には効率的なイントラモードコーディングの分野に関する。
【背景技術】
【0002】
進化する動画コーディング規格の技術的改善は、コーディング効率を高めて、より高いビットレート、より高い解像度、より良い動画品質を実現する傾向を示している。Joint Video Exploration Teamは、JVETと呼称される新しい動画コーディング方式を開発している。HEVC(High Efficiency Video Coding)などの他の動画コーディング方式と同様に、JVETは、ブロックベースのハイブリッド空間および時間予測コーディング方式である。ただし、HEVに比べて、JVETは、復号化された複数の画像を生成するためのビットストリーム構造、シンタックス、制約、およびマッピングに対する多くの変更を含む。JVETは、JEM(Joint Exploration Model)符号化器および復号化器に実装されている。
【0003】
現在のJVET規格には、平面(planar)モード、DCモード、65個の方向性角度(directional angular)イントラモードを含む合計67個のイントラ予測モード(intra prediction mode)が記述されている。これら67個のモードを効率的にコード化するために、すべてのイントラモードは、6つの最確モード(most probable mode : MPM)のセット、16個の選択モードのセット、および45個の非選択モードのセットを含む3つのセットに細分化される。
【0004】
6つのMPMは、利用可能な近傍ブロックのモード、導出されたイントラモードおよびデフォルトのイントラモードから導出される。現在のブロックの5つの隣接ブロックのイントラモードを
図1aに示す。これらは、左(L)、上(A)、左下(BL)、右上(AR)、左上(AL)であり、現在のブロックのMPMリストを形成するために使用される。初期のMPMリストは、5つの隣接イントラモード、平面モード、およびDCモードをMPMリストに挿入することによって作成される。プルーニングプロセス(pruning process)が使用されて重複したモードを削除し、固有のモードのみをMPMリストに含めることができる。複数の初期モードが含まれる順序は、左、上、平面、DC、左下、右上、左上である。
【0005】
MPMリストが埋まっていない場合、導出されたモードが追加され、これらのイントラモードは、MPMリストに既に含まれている角度モードに「-1」または「+1」を加えることによって導出される。MPMリストがまだ完全でない場合、複数のデフォルトモードは、垂直、水平、モード2(mode 2)、および斜めモードの順序で追加される。このプロセスの結果、6つのMPMモードの固有のリストが生成される。
【0006】
6つのMPMのエントロピーコーディングでは、
図1bに示されるtruncated unary二値化が、現在使用されている。MPMモードの最初の3つのビン(bin)は、現在信号伝達されているビンに関連するMPMモードに依存する複数のコンテキストでコード化される。MPMモードは、(a)主として水平である(すなわち、MPMモード番号は、対角線方向のモード番号よりも小さい)モード、(b)主として垂直である(つまり、MPMモードが、対角線方向のモード番号より大きい)モード、(c)非角度(non-angular)(DCおよび平面)クラスの3つのカテゴリのうちの1つに分類される。したがって、3つのコンテキストは、この分類に基づいてMPMインデックスを信号伝達するために用いられる。
【0007】
残りの61個の非MPMを選択するためのコーディングは、次のように行われる。61個の非MPMは最初に、選択モードセットと非選択モードセットの2つのセットに分割される。選択されたモードセットは、16個のモードを含み、残り(45個のモード)は、非選択のモードセットに割り当てられる。現在のモードが属するモードセットは、ビットストリームにおいてフラグで示される。示されたモードが選択モードセット内にある場合、選択されたモードは、4ビットの固定長コードで信号伝達され、示されたモードが非選択モードセットからのものである場合、選択されたモードは、truncatedバイナリコードで信号伝達される。例として、選択されたモードセットは、以下のように61個の非MPMモードをサブサンプリングすることによって生成される。
【0008】
選択モードセット={0,4,8,12,16,20…60}
非選択モードセット={1、2、3、5、6、7、9、10…59}
現在のJVETイントラモードコーディングは、以下の
図1bに要約されている。
【0009】
図1bに示すように、MPMリストの最後の2つのエントリは、16個の選択モードに割り当てられたビンの数と同じである6つのビンを必要とする。このような構成は、MPMリストの最後の2つのモードのコーディングパフォーマンスの点では利点を有していない。また、MPMモードの最初の3つのビンはコンテキストベースのエントロピーコーディングでコーディングされているため、MPMモードの6つのビンの符号化の複雑さは、選択モードの6つのビンのコーディングよりも高い。
【0010】
イントラモードコーディングに関連するコーディングの負担および帯域幅を低減するシステムおよび方法が必要とされている。
【発明の概要】
【0011】
本開示は、JVETイントラ予測のための動画コーディング方法を提供し、この動画コーディング方法は、固有のイントラ予測コーディングモードのセットを規定することであって、いくつかの実施形態では、67個のモードとすることができる、規定すること、前記固有のイントラ予測コーディングモードのセットから固有のMPMイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化することであって、いくつかの実施形態では、7つ以上のうちの5つ以下とすることができる、特定してインスタンス化すること、を含む。またこの方法は、固有のMPMイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、幾つかの実施形態において16個のコーディングモードを含み得る選択された固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、固有のMPMイントラ予測コーディングモードのサブセット以外であり且つ選択された固有のイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、イントラ予測モードのバランスを構成する非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、を提供する。次に、truncated unary二値化を使用して、固有のMPMイントラ予測コーディングモードのサブセットをコーディングする。
【0012】
また本開示は、JVETイントラ予測のための動画コーディングシステムを提供し、幾つかの実施形態において、この動画コーディングシステムは、67個の固有のイントラ予測コーディングモードのセットをメモリにおいてインスタンス化すること、固有のイントラ予測コーディングモードのセットから固有のMPMイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、固有のMPMイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、16個の固有の選択されたイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、固有のMPMイントラ予測コーディングモードのサブセット以外であり且つ固有の選択されたイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、truncated unary二値化を使用して、固有のMPMイントラ予測コーディングモードのサブセットを符号化すること、4ビットの固定長コードを使用して、16個の選択された固有のイントラ予測コーディングモードのサブセットを符号化すること、を備える。
【図面の簡単な説明】
【0013】
本発明のさらなる詳細は、添付図面を用いて説明される。
【
図1a】現在のコーディングブロックに関連する隣接ブロックを示す。
【
図1b】イントラモード予測のための現在のJVETコーディングの表を示す。
【
図1c】フレームの複数のコーディングツリーユニット(Coding Tree Units : CTUs)への分割を示す。
【
図2】四分木分割および対称2分割を用いたCTUの複数のコーディングユニット(Coding Units : CUs))への例示的な分割を示す。
【
図3】
図2の分割のQTBT(quadtree plus binary tree)表現を示す。
【
図4】CUをより小さい2つのCUに非対称2分割する4つの可能なタイプを示す。
【
図5】四分木分割、対称2分割、及び非対称2分割を用いたCTUの複数のCUへの例示的な分割を示す。
【
図7】JVET符号化器におけるCUコーディングの簡略化されたブロック図を示す。
【
図8】JVETの輝度成分の67個の可能なイントラ予測モードを示す。
【
図9】JVET符号化器におけるCUコーディングの簡略化されたブロック図を示す。
【
図10】JVET符号化器におけるCUコーディングの方法の実施形態を示す。
【
図11】JVET符号化器におけるCUコーディングの簡略化されたブロック図を示す。
【
図12】JVET復号化器におけるCU復号化の簡略化されたブロック図を示す。
【
図13】イントラモード予測のためのJVETコーディングの代替的な簡略化されたブロック図を示す。
【
図14】イントラモード予測のための代替的なJVETコーディングの表を示す。
【
図15】CUコーディングの方法を処理するように適合および/または構成されたコンピュータシステムの実施形態を示す。
【
図16】JVET符号化器/復号化器におけるCU符号化/復号化のための符号化/復号化システムの実施形態を示す。
【発明を実施するための形態】
【0014】
図1は、フレームの複数のコーディングツリーユニット(Coding Tree Units : CTUs)100への分割を示す。フレームは、動画シーケンスの画像であり得る。フレームは、画像内の強度測定値を表す複数の画素値を有する行列(matrix)または一組の行列を含み得る。したがって、これらの一組の行列によって、動画シーケンスが生成され得る。複数の画素値は、複数の画素が3つのチャネルに分割されるフルカラー動画コーディングにおいて色及び明るさを表すように定義され得る。たとえば、YCbCr色空間では、複数の画素は、画像のグレーレベル(gray level)の強度を表す輝度値Yと、グレーから青および赤までの色の違いを表す2つのクロミナンス値(chrominance value)Cb,Crを有する。他の実施形態では、複数の画素値は、異なる色空間またはモデルの値で表すことができる。動画の解像度によって、フレームの画素数が決定される。解像度が高いほど、画素数が多くなり、画像の鮮明度が向上するが、帯域幅、ストレージ(storage)、および伝送の要件も高くなる。
【0015】
動画シーケンスの複数のフレームは、JVETを使用して符号化および復号化され得る。JVETは、Joint Video Exploration Teamによって開発されている動画コーディング方式である。JVETの複数のバージョンは、JEM(Joint Exploration Model)復号化器および複合化器に実装されている。HEVC(High Efficiency Video Coding)などの他の動画コーディング方式と同様に、JVETは、ブロックベースのハイブリッド空間および時間予測コーディング方式である。JVETでのコーディングにおいて、フレームは、
図1に示されるように、CTU100と呼称される複数の正方形ブロックに最初に分割される。たとえば、複数のCTU100は、128x128画素の複数のブロックであり得る。
【0016】
図2は、CTU100の複数のCU102への例示的な分割を示す。フレーム内の各CTU100は、1つ以上のCU(Coding Unit)102に分割され得る。1つ以上のCU102は、以下で説明するように予測および変換のために使用され得る。HEVCとは異なり、JVETでは、複数のCU102は、長方形または正方形であってもよく、複数の予測ユニットまたは複数の変換ユニットにさらに分割することなくコード化され得る。複数のCU102は、それらのルート(root)CTU100と同じ大きさであるか、または4×4ブロックと同じくらい小さいルートCTU100のより小さな細分区画(subdivision)であり得る。
【0017】
JVETでは、CTU100は、QTBT(quadtree plus binary tree)方式に従って複数のCU102に分割され得る。この方式では、CTU100は、四分木に従って複数の正方形ブロックに再帰的に分割され、これらの正方形ブロックは、二分木に従って水平または垂直に再帰的に分割され得る。複数のパラメータは、CTUサイズ、四分木および二分木のリーフノード(leaf node)の最小サイズ、二分木のリーフノードの最大サイズ、二分木の最大深さなどのQTBTに従って分割を制御するように設定され得る。
【0018】
いくつかの実施形態では、JVETは、QTBTの二分木部分の2分割(binary partitioning)を対称分割に制限することができ、複数のブロックは、正中線(midline)に沿って垂直または水平のいずれかで半分に分割される。
【0019】
非限定的な例として、
図2は、複数のCU102に分割されたCTU100を示し、実線は四分木分割を示し、破線は対称二分木分割を示す。図示されているように、2分割によって、対称的な水平分割と垂直分割が可能になり、CTUの構造および複数のCUへの細分化を定義することができる。
【0020】
図3は、
図2の分割のQTBT表現(representation)を示す。四分木ルートノードは、親の正方形ブロックから分割された四つの正方形ブロックのうちの一つを表す四分木部分の各子ノードを有するCTU100を表す。複数の四分木リーフノードで表される複数の正方形ブロックは、二分木を使用して対称的に0回以上分割され、複数の四分木リーフノードは、二分木の複数のルートノードである。二分木部分の各レベルで、ブロックは、垂直または水平に対称的に分割され得る。「0」に設定されたフラグは、ブロックが水平方向に対称的に分割されることを示し、「1」に設定されたフラグは、ブロックが垂直方向に対称的に分割されることを示す。
【0021】
他の実施形態では、JVETは、QTBTの二分木部分における対称2分割または非対称2分割のいずれかを可能にすることができる。非対称モーション分割(Asymmetrical motion partitioning : AMP)は、複数の予測ユニット(prediction unit : PU)を分割する場合、HEVCの異なるコンテキストで可能である。しかし、QTBT構造に従ってJVET内の複数のCU102を分割する場合、CU102の複数の相関領域(correlated area)がCU102の中心を通る正中線の両側に配置されていないとき、非対称2分割は、対称2分割に対する改善された分割をもたらすことができる。非限定的な例として、CU102が、CUの中心に近接する1つのオブジェクトと、CU102の側部にある別のオブジェクトとを示す場合、CU102は、非対称的に分割されて、各オブジェクトを異なるサイズの別個のより小さいCU102に配置することができる。
【0022】
図4は、4つの可能なタイプの非対称2分割を示し、CU102は、CU102の長さまたは高さを横切る線に沿って2つのより小さいCU102に分割され、2つのより小さいCU102の一方は親CU102のサイズの25%であり、他方は親CU102のサイズの75%である。
図4に示す4つのタイプの非対称2分割によって、CU102は、CU102の左側から25%離れた、CU102の右側から25%離れた、CU102の上部から25%離れた、またはCU102の下部から25%離れた線に沿って分割可能である。別の実施形態では、CU102が分割される非対称分割線は、CU102が半分に対称的に分割されないような他の任意の位置に配置され得る。
【0023】
図5は、QTBTの二分木部分において対称2分割および非対称2分割の両方を可能にする方式を使用して複数のCU102に分割されたCTU100の非限定的な例を示す。
図5において、破線は、非対称2分割線を示し、親CU102は、
図4に示される複数の分割タイプのうちの1つを使用して分割されている。
【0024】
図6は、
図5の分割のQTBT表現を示す。
図6において、ノードから延びる2本の実線は、QTBTの二分木部分における対称分割を示し、ノードから延びる2本の破線は、二分木部分における非対称分割を示す。
【0025】
どのようにCTU100が複数のCU102に分割されたかを示すシンタックス(syntax)は、ビットストリームにコード化され得る。非限定的な例として、シンタックスはビットストリームにコード化されて、どのノードが四分木分割で分割され、対称2分割で分割され、非対称2分割で分割されたかを示すことができる。同様に、シンタックスは、非対称2分割を用いて分割された複数のノードのためにビットストリームにコード化され、
図4に示される4つのタイプのうちの1つのような、どのタイプの非対称2分割が使用されたかを示すことができる。
【0026】
いくつかの実施形態では、非対称分割の使用は、QTBTの四分木部分の複数のリーフノードで複数のCU102を分割することに限定することができる。これらの実施形態では、四分木部分で四分木分割を使用して親ノードから分割された複数の子ノードのCU102は、最終CU102であるか、または四分木分割、対称2分割、または非対称2分割を使用してさらに分割され得る。対称2分割を使用して分割された二分木部分の複数の子ノードは、最終CU102であるか、または対称2分割のみを使用して再帰的に1回以上さらに分割され得る。非対称2分割を使用してQTリーフノードから分割された二分木部分の複数の子ノードは、それ以上の分割されない最終CU102であり得る。
【0027】
これらの実施形態では、非対称分割の使用を四分木リーフノードの分割に制限することによって、検索の複雑さを軽減し、および/または付加ビット(overhead bit)を制限することができる。四分木リーフノードのみが非対称分割で分割されるため、非対称分割を使用することは、QT部分の分岐の終端を、他のシンタックスまたはそれ以上の信号伝達なしで直接的に示すことができる。
【0028】
同様に、非対称に分割された複数のノードはそれ以上分割できないため、ノードでの非対称分割の使用は、その非対称に分割された複数の子ノードが他のシンタックスまたはさらなる信号伝達なしで最終CU102であることを直接的に示すこともできる。
【0029】
検索の複雑さを制限し、および/または付加ビットの数を制限することがあまり問題でない場合などの代替的な実施形態では、非対称分割は、四分木分割、対称2分割、および/または非対称2分割によって生成された複数のノードを分割するために用いられ得る。
【0030】
上記したいずれかのQTBT構造を使用した四分木分割および二分木分割の後、QTBTのリーフノードで表される複数のブロックは、インター予測またはイントラ予測を使用したコード化など、コード化される最終CU102を示す。インター予測でコード化された複数のスライス(slice)または複数のフルフレーム(full frame)の場合、異なる分割構造を輝度成分およびクロマ成分(chroma component)に使用できる。例えば、インタースライス(inter slice)の場合、CU102は、1つの輝度CBと2つのクロマCBなどの異なる色成分のコーディングブロック(Coding Block : CB)を有することができる。イントラ予測でコード化された複数のスライスまたは複数のフルフレームの場合、輝度成分およびクロマ成分の分割構造は同じである。
【0031】
代替実施形態では、JVETは、上述したQTBT分割の代替または拡張として2つのレベルのコーディングブロック構造を使用することができる。2つのレベルのコーディングブロック構造では、CTU100は、最初に高いレベルで複数のベースユニット(base unit : BU)に分割され得る。その後、複数のBUは、低いレベルで複数のオペレーティングユニット(operating unit : OU)に分割され得る。
【0032】
2つのレベルのコーディングブロック構造を採用する実施形態では、高レベルで、CTU100は、上記した複数のQTBT構造の1つに従って、またはHEVCで使用されるものなどの四分木(quadtree : QT)構造に従って複数のBUに分割され得る。ブロックは、4つの同じサイズのサブブロックにのみ分割され得る。非限定的な例として、
図5~6に関して上述したQTBT構造に従って、CTU102を複数のBUに分割することができる。四分木部分の複数のリーフノードは、四分木分割、対称二分木分割、または非対称二分木分割を使用して分割され得る。
【0033】
この例では、QTBTの最終リーフノードは、複数のCUではなく複数のBUにすることができる。
2つのレベルのコーディングブロック構造のうちの低いレベルでは、CTU100から分割された各BUは、1つまたは複数のOUにさらに分割され得る。いくつかの実施形態では、BUが正方形である場合、それは、対称または非対称の2分割など、四分木分割または2分割を使用して、複数のOUに分割することができる。ただし、BUが正方形でない場合は、2分割のみを使用して複数のOUに分割され得る。非正方形のBUに使用できる分割のタイプを制限すると、複数のBUの生成に使用される分割の種類を示すために使用されるビット数を制限できる。
【0034】
以下の説明はCU102のコーディングについて説明しているが、2つのレベルのコーディンググブロック構造を使用する実施形態では、CU102の代わりにBUおよびOUをコード化することができる。非限定的な例として、複数のBUは、イントラ予測またはインター予測などの高いレベルのコーディング演算に使用され、より小さな複数のOUは、変換や変換係数の生成などの低いレベルのコーディング演算に使用され得る。従って、複数のBUのためにコード化されるシンタックスは、それらが、イントラ予測またはインター予測でコード化されるかどうかを示すか、または複数のBUをコード化するために使用される特定のイントラ予測モードまたは動きベクトルを識別する情報を示す。同様に、複数のOUのシンタックスは、複数のOUをコード化するために使用される特定の変換演算または量子化変換係数を識別することができる。
【0035】
図7は、JVET符号化器におけるCUコーディングの簡略化されたブロック図を示す。動画コーディングの主な段階は、上述したように、分割して複数のCU102を特定し、次いで、704または706で予測を使用して複数のCU102を符号化し、708で残差(residual)CU710を生成し、712で変換し、716で量子化し、720でエントロピーコーディングする。
【0036】
図7に示される符号化器および符号化プロセスは、以下でより詳細に説明される復号化プロセスも含む。現在のCU102が与えられると、符号化器は、704でイントラ予測を空間的に使用するか、706でインター予測を時間的に使用して予測CU702を取得し得る。予測コーディングの基本的な考え方は、元の信号と元の信号の予測との間の差分信号または残差信号を送信することである。受信器側では、以下で説明するように、元の信号は、残差と予測を追加することによって再構成され得る。差分信号は元の信号よりも相関が低いため、送信に必要なビットは少なくなる。
【0037】
画像全体または画像の一部など、全体がイントラ予測CU102によってコード化されたスライスは、他のスライスを参照せずに復号化される「I」スライスとし、復号化を開始する可能性がある点とし得る。少なくともいくつかのインター予測CUでコード化されたスライスは、1つ以上の参照画像に基づいて復号化できる予測(P)スライスまたは双予測(B)スライスであり得る。Pスライスは、以前にコード化されたスライスでイントラ予測とインター予測を使用し得る。たとえば、Pスライスは、インター予測を使用して「I」スライスよりもさらに圧縮できるが、それらをコード化するには、以前にコード化されたスライスのコーディングが必要である。Bスライスは、2つの異なるフレームからの内挿予測(interpolated prediction)を使用したイントラ予測またはインター予測を使用して、コーディングの前および/または後のスライスからのデータを使用できるため、動き推定プロセスの精度が向上する。幾つかの場合には、Pスライス及びBスライスは、同じスライスの他の部分からのデータが使用されるイントラブロックコピーを使用して符号化するか、または代替的に符号化することもできる。
【0038】
以下で説明するように、イントラ予測またはインター予測は、隣接する複数のCU102または参照画像内の複数のCU102など、以前にコード化された複数のCU102から再構成された複数のCU734に基づいて実行され得る。
【0039】
704でイントラ予測を用いてCU102を空間的にコード化すると、画像内の隣接する複数のCU102からの複数のサンプルに基づいて、CU102の複数の画素を最適に予測するイントラ予測モードを特定し得る。
【0040】
CUの輝度成分をコーディングするとき、符号化器は、候補イントラ予測モードのリストを生成できる。HEVCは輝度成分の35個の可能なイントラ予測モードを有していたが、JVETには輝度成分の67個の可能なイントラ予測モードがある。これらは、隣接する複数の画素から生成された複数の値の三次元平面を使用する平面モード(planar mode)、隣接する複数の画素から平均化された複数の値を使用するDCモード、および指示された複数の方向に沿って隣接する複数の画素からコピーされた複数の値を使用する
図8に示される65個の方向性モードを含む。
【0041】
CUの輝度成分の候補イントラ予測モードのリストを生成する場合、リスト上の候補モードの数は、CUのサイズに依存する。候補リストは、最低のSATD(Sum of Absolute Transform Difference)コストを有するHEVCの35個のモードの一部分、複数のHEVCモードから特定された複数の候補に隣接するJVETに追加された複数の新しい方向性モード、以前にコード化された隣接する複数のブロックに使用される複数のイントラ予測モードと複数のデフォルトモードのリストに基づいて識別されるCU102の6つの最確モード(most probable mode : MPM)のセットからの複数のモードを含み得る。
【0042】
CUのクロマ成分をコーディングするとき、候補イントラ予測モードのリストを生成できる。候補モードのリストは、輝度サンプルからのクロスコンポーネント線形モデル投影(cross-component linear model projection)で生成されたモード、クロマブロック内の特定の複数の配列位置の輝度CBで特定された複数のイントラ予測モード、および隣接する複数のブロックで以前に特定された複数のクロマ予測モードを含む。符号化器は、最も低いレート歪みコスト(rate distortion cost)でリスト上の候補モードを特定し、CUの輝度およびクロマ成分をコーディングする際にそれらのイントラ予測モードを使用する。シンタックスは、各CU102のコード化に使用される複数のイントラ予測モードを示すビットストリームにコード化され得る。
【0043】
CU102の最適なイントラ予測モードが選択された後、符号化器は、それらのモードを使用して予測CU402を生成し得る。選択したモードが方向性モードである場合、4タップフィルタ(4-tap filter)を使用して方向性の精度を向上させることができる。予測ブロックの上部または左側の列または行は、2タップまたは3タップフィルタなどの境界予測フィルタで調整され得る。
【0044】
予測CU702は、隣接する複数のブロックのフィルタリングされていない複数のサンプルを用いて隣接する複数のブロックのフィルタリングされたサンプルに基づいて生成された予測CU702を調整するPDPC(position dependent intra prediction combination)プロセス、または複数の参照サンプルを処理するために3タップまたは5タップのローパスフィルタを用いた適応参照サンプル平滑化(adaptive reference sample smoothing)によってさらに平滑化され得る。
【0045】
706でインター予測を用いてCU102が時間的にコード化されると、CU102の複数の画素を最適に予測する複数の参照画像内の複数のサンプルを指す一組の動きベクトル(motion vector : MV)を特定することができる。インター予測は、スライス内の複数の画素のブロックの変位を表すことにより、複数のスライス間の時間的冗長性(temporal redundancy)を利用する。変位は、動き補償と呼ばれるプロセスを通じて、前または後のスライスの複数の画素の値に従って決定される。特定の参照画像に対する画素変位を示す動きベクトルおよび関連する参照インデックスは、元の画素と動き補償された画素との間の残差とともに、復号化器へのビットストリームで提供され得る。復号化器は、残差の信号伝達された(signaled)動きベクトル及び参照インデックスを使用して、再構成されたスライス内の複数の画素のブロックを再構成できる。
【0046】
JVETでは、動きベクトルの精度は1/16ペル(pel)で格納され、動きベクトルとCUの予測された動きベクトルとの差分は、1/4ペルの解像度または整数ペル解像度でコード化され得る。
【0047】
JVETにおいて、複数の動きベクトルは、CU102内の複数のサブCUについて、高度時間動きベクトル予測(advanced temporal motion vector prediction : ATMVP)、空間時間動きベクトル予測(spatial-temporal motion vector prediction : STMVP)、アフィン動き補償予測(affine motion compensation prediction)、パターン整合動きベクトル導出(pattern matched motion vector derivation : PMMVD)、および/または双方向オプティカルフロー(bi-directional optical flow : BIO)などの技法を用いて特定され得る。
【0048】
符号化器は、ATMVPを使用して、参照画像内の対応するブロックを指すCU102の時間ベクトルを特定し得る。時間ベクトルは、以前にコード化された隣接する複数のCU102について特定された複数の動きベクトルおよび複数の参照画像に基づいて特定され得る。CU102全体の時間ベクトルによって示される参照ブロックを使用して、CU102内の各サブCUの動きベクトルが特定され得る。
【0049】
STMVPは、以前にインター予測でコード化された隣接する複数のブロックで特定された複数の動きベクトルを、時間ベクトルとともにスケーリングおよび平均化することによって、サブCUの動きベクトルを特定し得る。
【0050】
アフィン動き補償予測は、ブロックの上部コーナーで特定された2つの制御動きベクトルに基づいて、ブロック内の各サブCUの複数の動きベクトルのフィールドを予測するために使用され得る。例えば、複数のサブCUの複数の動きベクトルは、CU102内の各4x4ブロックで特定された上部コーナーの複数の動きベクトルに基づいて導出され得る。
【0051】
PMMVDは、両側マッチング(bilateral matching)またはテンプレートマッチング(template matching)を使用して、現在のCU102の初期動きベクトルを特定することができる。両側マッチングは、運動軌道に沿った異なる2つの参照画像内の現在のCU102および参照ブロックを特定し、一方、テンプレートマッチングは、現在のCU102内の対応する複数のブロックおよびテンプレートによって識別される参照画像を検索することができる。
【0052】
次いで、CU102について特定された初期動きベクトルは、各サブCUについて個別に改良され得る。BIOは、前後の参照画像に基づく双予測でインター予測を行う場合に使用されて、2つの参照画像間の差分の勾配に基づいてサブCUの動きベクトルを特定し得る。
【0053】
状況によっては、CUのレベルで局所照明補償(local illumination compensation : LIC)を使用して、現在のCU102に隣接する複数のサンプルと、候補動きベクトルによって識別される参照ブロックに隣接する対応する複数のサンプルとに基づいて、スケーリング係数パラメータ(scaling factor parameter)およびオフセットパラメータの値を特定することができる。JVETでは、複数のLICパラメータを変更し、CUのレベルで信号伝達し得る。上記した方法の一部では、CUのサブCUごとに特定された複数の動きベクトルを、CUのレベルで復号化器に信号伝達し得る。PMMVDやBIOなどの他の方法の場合、モーション情報は、オーバーヘッドを節約するためにビットストリームで信号伝達されず、復号化器は、同じプロセスで動きベクトルを導出し得る。
【0054】
CU102の動きベクトルが特定された後、符号化器は、それらの動きベクトルを使用して予測CU702を生成し得る。場合によっては、個々のサブCUで複数の動きベクトルが特定された場合、それらの動きベクトルを隣接する1つ以上のサブCUで以前に特定された動きベクトルと組み合わせて予測CU702を生成するときに、オーバーラップブロック動き補償(Overlapped Block Motion Compensation : OBMC)が使用され得る。
【0055】
双予測を使用すると、JVETは、復号化器側動きベクトル調整(decoder-side motion vector refinement : DMVR)を使用して複数の動きベクトルを特定し得る。DMVRでは、両側テンプレートマッチングプロセス(bilateral template matching process)を使用して、双方向予測で特定された2つの動きベクトルに基づいて動きベクトルを特定し得る。DMVRでは、2つの動きベクトルの各々を用いて生成された複数の予測CU702の重み付けされた組み合わせが特定され、2つの動きベクトルは、それらを、組み合わせられた予測CU702を最適に示す新しい動きベクトルで置き換えることによって改良され得る。
【0056】
改良された2つの動きベクトルを使用して、最終予測CU702を生成することができる。
上記したように、704でのイントラ予測または706でのインター予測で予測CU702が特定されると、708において、符号化器は、現在のCU102から予測CU702を減算し、残差CU710を特定し得る。
【0057】
符号化器は、712において、1つ以上の変換演算を使用して、例えば、離散コサインブロック変換(DCT変換)(discrete cosine block transform)を使用してデータを変換ドメインに変換するように、残差CU710を変換ドメイン内の残差CU710を示す変換係数714に変換し得る。JVETでは、DCT-II、DST-VII、DST-VII、DCT-VIII、DST-I、DCT-V演算など、HEVCよりも多くの種類の変換演算が可能である。この可能な複数の変換演算は、複数のサブセットにグループ化され、どのサブセットおよびそれらのサブセット内のどの特定の演算が使用されたかの指示は、符号化器によって信号伝達され得る。いくつかの場合では、大きなブロックサイズ変換が使用されて、特定のサイズよりも大きいCU102内の高周波数変換係数をゼロにし(zero out)、その結果、これらのCU102については低周波数変換係数のみが維持される。
【0058】
場合によっては、MDNSST(mode dependent non-separable secondary transform)は、順方向コア変換(forward core transform)後に低周波数変換係数714に適用され得る。MDNSST演算では、回転データに基づいてHypercube-Givens変換(Hypercube-Givens Transform : HyGT)を使用できる。使用すると、特定のMDNSST演算を識別するインデックス値は、符号化器から信号伝達され得る。
【0059】
716において、符号化器は、変換係数714を量子化変換係数716に量子化し得る。各係数の量子化は、量子化パラメータ(quantization parameter : QP)から導出される量子化ステップで係数の値を除算することによって計算され得る。いくつかの実施形態では、Qstepは、2(QP-4)/6として定義される。高精度変換係数714は有限個の可能な値を有する量子化変換係数716に変換することができるので、量子化は、データ圧縮を補助することができる。
【0060】
したがって、変換係数の量子化は、変換プロセスによって生成および送信されるビットの量を制限してもよい。ただし、量子化は損失の多い演算であり、量子化による損失は回復できないが、量子化プロセスは、再構成されたシーケンスの品質と、シーケンスを示すのに必要な情報量とのトレードオフを示す。たとえば、QP値を低くすると、復号化された動画の品質が向上するが、表現と送信には大量のデータが必要になる場合がある。対照的に、QP値が高いと、再構成された動画シーケンスの品質は低下するが、データと帯域幅の必要性は低くなる。
【0061】
JVETは、(フレームの各CU102のコーディングにおいて同じフレームQPを使用する代わりに)各CU102がそのコーディングプロセスのために異なる量子化パラメータを使用することを可能にする分散ベース適応量子化技法(variance-based adaptive quantization technique)を利用することができる。分散ベース適応量子化技法は、特定のブロックの量子化パラメータを適応的に低下させ、他のブロックでは増加させる。CU102の特定のQPを選択するために、CUの分散が計算される。つまり、CUの分散がフレームの平均分散よりも高い場合、フレームのQPよりも高いQPがCU102に対して設定されてもよい。CU102がフレームの平均分散よりも低い分散を示す場合、より低いQPが割り当てられてもよい。
【0062】
720において、符号化器は、複数の量子化変換係数718をエントロピーコーディングすることによって、複数の最終圧縮ビット722を特定し得る。エントロピーコーディングは、送信される情報の統計的な冗長性を除去することを目的としている。JVETでは、確率測度を使用して統計的冗長性を除去するCABAC(Context Adaptive Binary Arithmetic Coding)を使用して、量子化変換係数718をコード化し得る。非ゼロの量子化変換係数718を有する複数のCU102の場合、量子化変換係数718は、バイナリ(binary)に変換され得る。次いで、バイナリ表現の各ビット(「ビン」)は、コンテキストモデルを使用して符号化され得る。CU102は、3つの領域に分割され、各領域は、その領域内の複数の画素に使用する自身の一組のコンテキストモデルを備えている。
【0063】
複数のスキャンパスは、複数のビンを符号化するために実行され得る。最初の3つのビン(bin0、bin1、bin2)を符号化するパスの間、どのコンテキストモデルをビンに使用すべきかを示すインデックス値は、テンプレートによって識別される前にコード化された最大5つの隣接量子化変換係数718においてそのビン位置の合計を求めることによって特定され得る。
【0064】
コンテキストモデルは、ビンの値が「0」または「1」である確率に基づくことができる。値がコード化されると、実際の「0」値と「1」値の数に基づいて、コンテキストモデルの確率が更新され得る。HEVCは新しい各画像のコンテキストモデルを再初期化するために固定テーブルを用いたが、JVETでは、複数の新しいインター予測画像のコンテキストモデルの確率は、以前にコード化されたインター予測画像のために生成されたコンテキストモデルに基づいて初期化され得る。
【0065】
符号化器は、複数の残差CU710のエントロピー符号化ビット722、選択されたイントラ予測モードまたは動きベクトルなどの予測情報、QTBT構造に従って複数のCU102がCTU100からどのように分割されたかのインジケータ、および/または符号化された動画に関する他の情報を含むビットストリームを生成し得る。以下で説明するように、ビットストリームは、復号化器で復号化され得る。
【0066】
量子化変換係数718を使用して最終圧縮ビット722を特定することに加えて、符号化器はまた、量子化変換係数718を使用して、復号化器が再構成された複数のCU734を生成するために使用するのと同じ復号化プロセスに従うことによって、再構成された複数のCU734を生成し得る。したがって、符号化器によって変換係数が計算および量子化されると、量子化変換係数718は、符号化器内の復号化ループに送信され得る。複数のCUの変換係数を量子化した後、復号化ループは、符号化器に、復号化プロセスにおいて復号化器が生成するものと同じ再構成されたCU734を生成させることができる。したがって、符号化器は、新しいCU102のイントラ予測またはインター予測を実行するときに、復号化器が隣接する複数のCU102または複数の参照画像に使用するのと同じ再構成された複数のCU734を使用することができる。再構成された複数のCU102、再構成された複数のスライス、または完全に再構成されたフレームは、さらなる予測段階のための参照としての役割を有してもよい。
【0067】
再構成された画像の複数の画素値を得るために、符号化器の復号化ループにおいて(復号化器の同じ演算のため、以下を参照されたい)、逆量子化プロセスが実行されてもよい。フレームを逆量子化するには、たとえば、フレームの各画素の量子化された値は、上記したQstepのような量子化ステップによって乗算されて、再構成された逆量子化変換係数726を取得する。例えば、符号化器における
図7に示す復号化処理では、残差CU710の量子化変換係数718は、724において逆量子化されて、逆量子化変換係数726を求めることができる。符号化においてMDNSST演算が実行された場合、その演算は、逆量子化後に逆転され得る(reversed)。
【0068】
728において、逆量子化変換係数726は、再構成された画像を得るために複数の値にDCTを適用することなどによって、逆変換(inverse transformed)されて再構成された残差CU730を特定し得る。732において、再構成された残差CU730は、再構成されたCU734を特定するために、704におけるイントラ予測または706におけるインター予測で特定された対応する予測CU702に追加され得る。
【0069】
736において、1つ以上のフィルタが、画像レベルまたはCUレベルのいずれかで、(符号化器、または以下に説明するように復号化器における)復号化プロセス中に再構成データに適用され得る。たとえば、符号化器は、デブロッキングフィルタ(deblocking filter)、サンプルアダプティブオフセット(sample adaptive offset : SAO)フィルタ、および/またはアダプティブループフィルタ(adaptive loop filter : ALF)を適用できる。符号化器の復号化プロセスは、再構築された画像の潜在的なアーティファクトに対処できる最適なフィルタパラメータを推定し、復号化器に送信するフィルタを実装し得る。このような改善は、再構成された動画の客観的で主観的な品質を向上させる。
【0070】
デブロッキングフィルタリングでは、サブCU境界付近の複数の画素が修正されるが、SAOでは、CTU100内の複数の画素は、エッジオフセット(edge offset)またはバンドオフセット(band offset)分類のいずれかを用いて修正され得る。JVETのALFは、2x2のブロックごとに円形対称形状のフィルタを使用できる。各2x2のブロックに使用されるフィルタのサイズ及びアイデンティティの指示が信号伝達され得る。
【0071】
再構成された画像が参照画像である場合、706において、これらは将来のCU102のインター予測のために参照バッファ738に格納され得る。
上記した複数のステップにおいて、JVETでは、コンテンツ適応クリッピング演算(content adaptive clipping operation)を使用して、クリッピング境界(clipping bound)の上限と下限との間に合わせて色値を調整可能である。複数のクリッピング境界はスライスごとに変更でき、境界を識別する複数のパラメータはビットストリームで信号伝達され得る。
【0072】
図9は、JVET復号化器におけるCUコーディングの簡略化されたブロック図を示す。JVET復号化器は、符号化されたCU102に関する情報を含むビットストリームを受信し得る。ビットストリームは、QTBT構造に従ってCTU100から画像の複数のCU102がどのように分割されたかを示すことができる。非限定的な例として、ビットストリームは、四分木分割、対称2分割、および/または非対称2分割を使用して、QTBT内の各CTU100から複数のCU102がどのように分割されたかを識別できる。ビットストリームは、イントラ予測モードまたは動きベクトルなどの複数のCU102の予測情報、およびエントロピー符号化された残差CUを表す複数のビット902も示すことができる。
【0073】
904において、復号化器は、符号化器によってビットストリームで信号伝達されたCABACコンテキストモデルを使用してエントロピー符号化された複数のビット902を復号化し得る。復号化器は、符号化器によって信号伝達された複数のパラメータを使用して、符号化中に更新されたのと同じ方法でコンテキストモデルの確率を更新し得る。
【0074】
904においてエントロピー符号化を逆転させて量子化変換係数906を特定した後、復号化器は、908においてそれらを逆量子化して逆量子化変換係数910を特定し得る。符号化においてMDNSST演算が実行された場合、その演算は、逆量子化後に復号化器によって逆転され得る。
【0075】
912において、逆量子化された複数の変換係数910は、再構成された残差CU914を特定するために逆変換され得る。916において、再構成された残差CU914は、再構成されたCU918を特定するために、922におけるイントラ予測または924におけるインター予測で特定された対応する予測CU926に追加され得る。
【0076】
920において、画像レベルまたはCUレベルのいずれかで、1つまたは複数のフィルタは、再構成されたデータに適用され得る。たとえば、復号化器は、デブロッキングフィルタ、サンプルアダプティブオフセット(sample adaptive offset : SAO)フィルタ、および/またはアダプティブループフィルタ(adaptive loop filter : ALF)を適用できる。上述したように、符号化器の復号化ループにあるインループフィルタ(in-loop filter)を使用して、最適なフィルタパラメータを推定し、フレームの客観的で主観的な品質を向上させることができる。920において、これらのパラメータは復号化器に送信されて、再構成されたフレームをフィルタリングして、符号化器内のフィルタリングされた再構成されたフレームに一致させる。
【0077】
再構成された複数のCU918を特定して信号伝達された複数のフィルタを適用することによって再構成された画像が生成された後、復号化器は、再構成された画像を出力動画928として出力し得る。再構成された画像が参照画像として用いられる場合、924において、これらは将来のCU102のインター予測のために参照バッファ930に格納され得る。
【0078】
図10は、JVET復号化器におけるCUコーディング1000の方法の実施形態を示す。
図10に示される実施形態では、ステップ1002において、符号化ビットストリーム902を受信し、ステップ1004において、符号化ビットストリーム902に関連するCABACコンテキストモデルを決定し、次いで、ステップ1006において、決定されたCABACコンテキストモデルを使用して符号化ビットストリーム902を復号化し得る。
【0079】
ステップ1008では、符号化ビットストリーム902に関連付けられた複数の量子化変換係数906を決定し、ステップ1010では、複数の量子化変換係数906から逆量子化変換係数910を決定し得る。
【0080】
ステップ1012において、符号化中にMDNSST演算が実行されたかどうか、および/またはビットストリーム902はMDNST動作がビットストリーム902に適用されたという指示を含むかどうかを判定し得る。符号化プロセス中にMDNSST演算が実行されたか、またはビットストリーム902はMDNSST演算がビットストリーム902に適用されたという指示を含むと判定された場合、逆MDNSST演算1014は、逆変換演算912が実行される前にステップ1016においてビットストリーム902について実行され得る。あるいは、ステップ1014において逆MDNSST演算の適用がない場合、ステップ1016において、ビットストリーム902に対して逆変換演算912が実行され得る。ステップ1016の逆変換動作912は、再構成された残差CU914を決定および/または構成し得る。
【0081】
ステップ1018において、ステップ1016からの再構成された残差CU914は、予測CU918と組み合わされ得る。予測CU918は、ステップ1020で決定されたイントラ予測CU922およびステップ1022で決定されたインター予測ユニット924のうちの1つであり得る。
【0082】
ステップ1024では、任意の1つまたは複数のフィルタ920は、再構成されたCU914に適用し、ステップ1026において出力され得る。いくつかの実施形態では、複数のフィルタ920は、ステップ1024で適用されなくてもよい。
【0083】
いくつかの実施形態では、ステップ1028において、再構成されたCU918は、参照バッファ930に格納され得る。
図11は、JVET符号化器におけるCUコーディングの簡略化されたブロック
図1100を示す。ステップ1102において、JVETコーディングツリーユニットは、QTBT(quadtree plus binary tree)構造のルートノードとして示され得る。いくつかの実施形態では、QTBTは、ルートノードから分岐する四分木および/または四分木の1つ以上のリーフノードから分岐する二分木を有し得る。ステップ1102からの表現(representation)は、ステップ1104、1106または1108に進むことができる。
【0084】
ステップ1104において、非対称2分割を使用して、表現された四分木ノードをサイズが等しくない2つのブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表現する複数のリーフノードとして、四分木ノードから分岐する二分木で表現され得る。いくつかの実施形態では、四分木ノードからリーフノードとして分岐する二分木は、さらなる分割が許可されない最終コーディングユニットを示す。いくつかの実施形態において、非対称分割は、コーディングユニットを不均等なサイズの複数のブロックに分割し、第1のブロックは四分木ノードの25%を表し、第2のブロックは四分木ノードの75%を表す。
【0085】
ステップ1106では、四分木分割を使用して、表現された四分木ノートを等しいサイズの4つの正方形ブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表す四分木ノードとして表されるか、または、四分木分割、対称二分木分割、または非対称二分木分割によって再度分割される複数の子ノードとして表され得る。
【0086】
ステップ1108では、四分木分割を使用して、表現された四分木ノートを等しいサイズの2つのブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表す四分木ノードとして表されるか、または、四分木分割、対称二分木分割、または非対称二分木分割によって再度分割される複数の子ノードとして表され得る。
【0087】
ステップ1110では、ステップ1106またはステップ1108からの複数の子ノードは、符号化されるように構成された複数の子ノードとして表され得る。いくつかの実施形態では、複数の子ノードは、JVETで二分木の複数のリーフノートによって表され得る。
【0088】
ステップ1112において、ステップ1104または1110からの複数のコーディングユニットは、JVETを使用して符号化され得る。
図12は、JVET復号化器におけるCU復号化の簡略化されたブロック
図1200を示す。
図12に示す実施形態では、ステップ1202において、QTBT構造に従ってコーディングツリーユニットがどのように複数のコーディングユニットに分割されたかを示すビットストリームを受信し得る。ビットストリームは、四分木分割、対称2分割、または非対称2分割の少なくとも1つで四分木ノードがどのように分割されるかを示すことができる。
【0089】
ステップ1204において、QTBT構造の複数のリーフノードによって表される複数のコーディングユニットが識別され得る。いくつかの実施形態では、複数のコーディングユニットは、非対称2分割を使用してノードが四分木リーフノードから分割されたかどうかを示すことができる。いくつかの実施形態では、コーディングユニットは、ノードが復号化される最終コーディングユニットを表すことを示すことができる。
【0090】
ステップ1206において、識別された1つまたは複数のコーディングユニットは、JVETを使用して復号化され得る。
図13は、イントラモード予測のためのJVETコーディングの代替的な簡略化されたブロック
図1300を示す。
図13に示す実施形態では、ステップ1302において、MPMのセットがメモリ内で特定されてインスタンス化され(instantiated)、ステップ1304において、16個の選択されたモードのセットがメモリ内で特定されてインスタンス化され、ステップ1304において、67個のモードのバランス(balance)がメモリ内で定義され且つインスタンス化され得る。いくつかの実施形態では、MPMのセットは、6つのMPMの標準セットから削減され得る。いくつかの実施形態では、MPMのセットは、5つの固有モード(unique mode)を含み、選択されたモードは、16個の固有モードを含み、非選択のモードのセットは、残りの46個の非選択の固有モードを含み得る。しかしながら、代替実施形態では、MPMのセットは、より少ない固有のモードを含み、選択されたモードは、16個の固有のモードで固定されたままであり、非選択の固有のモードのセットサイズは、合計67個のモードに適応するように適切に調節され得る。非限定的な例として、MPMのセットが6つのMPMの代わりに5つの固有のモードを含むいくつかの実施形態では、truncated unary二値化(binarization)が使用され、5つのMPMのための新しい二値化が利用される場合には、MPMモードに割り当てられるビンの数は、5つのビンに等しいか、またはそれ未満であり得る。
【0091】
したがって、いくつかの実施形態では、62個の残りのイントラモードから選択された16個のモードは、これら62個のイントラモードを均等にサブサンプリングすることによって生成され、それぞれが4ビットの固定長コードでコード化される。非限定的な例として、残りの62個のモードが{0、1、2、…、61}としてインデックス付けされると仮定すると、16個の選択されたモード={0、4、8、12、16、20、24、28、32、36、40、44、48、52、56、60}である。残りの46個の非選択のモード={1、2、3、5、6、7、9、10…59、61}であり、このような46個の非選択のモードは、truncatedバイナリコード(binary code)でコード化され得る。
【0092】
図14は、
図13によるイントラモード予測のための代替的なJVETコーディングの表1400を示す。
図14に示す実施形態では、複数のイントラ予測モード1402は、5つのMPM、16個の選択モード、および46個の非選択モードを含むように示されており、MPMのための複数のビンストリング(bin string)1404は、truncated unary二値化を使用して符号化され、16個の選択モードは、固定長コードの4ビットを使用してコード化され、46個の非選択モードは、truncatedバイナリコーディング(binary coding)を使用してコード化され得る。
【0093】
図13の代替的な実施形態では、6個のMPMを利用することができるが、MPMリストの最初の5つのMPMのみが、
図14に示すように二値化され(binarized)、現在のJVETに記述されている現在のコンテキストに基づく方法でコード化される。MPMリストの第6のMPMは、16個の選択モードのうちの1つと見なされ、他の15個の選択モードとともに4ビットの固定長コードでコード化される。
【0094】
非限定的な例として、残りの61個のモードが{0、1、2、…、60}としてインデックス付けされる場合、15個の選択モードは、残りの61個のイントラモードを次のように均等にサブサンプリングすることによって取得され得る:15個の選択されたモードのセットは、{0、5、10、14、18、22、26、30、34、38、42、46、50、55、60}とすることができ、ここで、15個の選択されたモードに加えて第6のMPMは、{第6のMPM、0、5、10、14、18、22、26、30、34、38、42、46、50、55、60}のセットのように固定長コードの4ビットでコード化され、46個の非選択モードのバランスは、非選択モードのセット={1、2、3、4、6、7、8、9、11、12…49、51、52、53、54、56、57、58、59}のようなセットとして示され、truncatedバイナリコードでコード化される。
【0095】
図13の更なる代替的な実施形態では、MPMリストの最初の5つのMPMのみが、
図14に示すように二値化され、現在のJVET規格に記述されている現在のコンテキストに基づく方法でコード化される。そのような実施形態では、MPMリストの第6のMPMは、16個の選択モードのうちの1つと見なされ、他の15個の選択モードとともに4ビットの固定長コードでコード化される。したがって、他の15個の選択されたモードの選択は、任意の既知の便利なおよび/または所望の選択プロセスを使用して確立され得る。非限定的な例として、それらは、MPMモード関して、または(コンテンツベースの)統計的によく知られたモードに関して、または訓練されたまたは歴史的によく知られたモードに関して、または他の方法またはプロセスを使用して選択され得る。
【0096】
この場合も先と同様に、5つのMPMの選択は、単なる非限定的な例であり、代替の実施形態では、MPMのセットは、4つまたは3つのMPMにさらに削減されるか、または6つを超えるまで拡大され得る。16個の選択されたモードが依然として存在し、67個(または他の既知の、便利な、および/または所望の総数)のイントラコーディングモードのバランスは、非選択のイントラコーディングモードのセットに含まれる。すなわち、イントラコーディングモードの総数が67個よりも多いかまたは少ない実施形態が考えられ、その実施形態では、MPMのセットが任意の既知の便利なまたは所望の数のMPMを含み、選択されたモードの量が任意の既知の便利なおよび/または所望の量であり得る。
【0097】
複数の実施形態を実施するのに必要な命令のシーケンスの実行は、
図15に示されるようにコンピュータシステム1500によって実行され得る。一実施形態では、命令のシーケンスの実行は、単一のコンピュータシステム1500によって実行される。他の実施形態によれば、通信リンク1515によって接続された複数のコンピュータシステム1500は、互いに協調して命令のシーケンスを実行し得る。以下では、1つのコンピュータシステム1500のみの説明を提示するが、複数の実施形態を実施するために任意の数のコンピュータシステム1500を使用できることを理解されたい。
【0098】
次に、一実施形態によるコンピュータシステム1500を、コンピュータシステム1500の複数の機能構成要素のブロック図である
図15を参照して説明する。本明細書で使用されるコンピュータシステム1500という用語は、1つまたは複数のプログラムを格納し、独立して実行できる任意のコンピューティングデバイスを記述するために広く使用される。
【0099】
各コンピュータシステム1500は、バス1506に接続された通信インタフェース1514を含み得る。通信インタフェース1514は、複数のコンピュータシステム1500間の双方向通信を提供する。各コンピュータシステム1500の通信インタフェース1514は、様々なタイプの信号情報、例えば、命令、メッセージ、およびデータを表すデータストリームを含む電気信号、電磁信号、または光信号を送受信する。通信リンク1515は、1つのコンピュータシステム1500を別のコンピュータシステム1500とリンクする。例えば、通信リンク1515はLANであり、その場合、通信インタフェース1514はLANカードであり、または通信リンク1515はPSTNであり、その場合、通信インタフェース1514は統合サービスデジタルネットワーク(integrated services digital network : ISDN)カードまたはモデムであり、または通信リンク1515はインターネットであり、その場合、通信インタフェース1514はダイヤルアップ、ケーブルまたは無線モデムであり得る。
【0100】
コンピュータシステム1500は、その対応する通信リンク1515および通信インタフェース1514を介して、プログラム、すなわちアプリケーション、コードを含むメッセージ、データ、および命令を送受信し得る。受信したプログラムコードは、受信した各プロセッサ1507によって実行され、および/または後で実行するために記憶装置1510または他の関連する不揮発性媒体に格納される。
【0101】
一実施形態では、コンピュータシステム1500は、データストレージシステム1531、例えば、コンピュータシステム1500によって容易にアクセス可能なデータベース1532を含むデータストレージシステム1531と連動して動作する。コンピュータシステム1500は、データインタフェース1533を介してデータストレージシステム1531と通信する。バス1506に接続されたデータインタフェース1533は、様々なタイプの信号情報、例えば、命令、メッセージ、およびデータを表すデータストリームを含む電気信号、電磁信号、または光信号を送受信する。複数の実施形態において、データインタフェース1533の機能は、通信インタフェース1514によって実行され得る。
【0102】
コンピュータシステム1500は、命令、メッセージおよびデータ、集合的に情報を通信するためのバス1506または他の通信メカニズムと、情報を処理するためにバス1506に接続された1つまたは複数のプロセッサ1507と、を含む。コンピュータシステム1500は、1つまたは複数のプロセッサ1507によって実行される動的データおよび命令を格納するためにバス1506に接続されたランダムアクセスメモリ(RAM)または他の動的記憶装置などのメインメモリ1508も含む。メインメモリ1508はまた、1つまたは複数のプロセッサ1507による命令の実行中に一時的なデータ、すなわち変数、または他の中間情報を格納するために使用され得る。
【0103】
コンピュータシステム1500は、1つまたは複数のプロセッサ1507のための静的データおよび命令を格納するためにバス1506に接続されたリードオンリーメモリ(ROM)1509または他の静的記憶装置をさらに含み得る。また磁気ディスクまたは光ディスクなどの記憶装置1510が提供され、1つまたは複数のプロセッサ1507のためのデータおよび命令を格納するためにバス1506に接続され得る。
【0104】
コンピュータシステム1500は、ユーザに情報を表示するために、バス1506を介して、陰極線管(cathode ray tube : CRT)または液晶ディスプレイ(liquid-crystal display : LCD)モニタなどのディスプレイ装置1511に接続されることができるが、これらに限定されない。入力デバイス1512、例えば英数字及び他のキーは、情報及びコマンド選択をプロセッサ1507に通信するためにバス1506に接続される。
【0105】
一実施形態によれば、個々のコンピュータシステム1500は、メインメモリ1508に含まれる1つ以上の命令の1つ以上のシーケンスを実行するこれらの対応する1つまたは複数のプロセッサ1507によって特定の演算を実行する。そのような命令は、ROM1509または記憶装置1510などの別のコンピュータ使用可能媒体からメインメモリ1508に読み込まれ得る。メインメモリ1508に含まれる命令のシーケンスの実行によって、1つまたは複数のプロセッサ1507は、本明細書において説明されるプロセスを実行する。代替的な実施形態では、ハードワイヤード回路をソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用することができる。したがって、複数の実施形態は、ハードウェア回路および/またはソフトウェアの特定の組み合わせに限定されない。
【0106】
本明細書で使用される「コンピュータ使用可能媒体」という用語は、情報を提供するか、または1つまたは複数のプロセッサ1507によって使用可能な任意の媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに限定されない多くの形態を有することができる。不揮発性媒体、つまり電力が無くても情報を保持できる媒体は、ROM1509、CD ROM、磁気テープ、および磁気ディスクを含む。揮発性媒体、つまり電力が無いと情報を保持できない媒体は、メインメモリ1508を含む。伝送媒体は、バス1506を構成するワイヤーを含む同軸ケーブル、銅線、光ファイバを含む。伝送媒体はまた、搬送波の形態を有することができ、すなわち、情報信号を送信するために周波数、振幅または位相において変調される電磁波であり得る。さらに伝送媒体は、電波や赤外線データ通信中に生成されるものなど、音波または光波の形態を有することができる。
【0107】
前述した明細書では、複数の実施形態は、その特定の構成要素を参照して説明された。しかしながら、実施形態のより広い趣旨および範囲から逸脱することなく、様々な変更および変更を行うことができることは明らかである。例えば、本明細書に記載されるプロセスフローダイアグラムに示される複数のプロセスアクションの特定の順序付けおよび組合せは単なる例示であり、異なるまたは追加のプロセスアクションを使用するか、または複数のプロセスアクションの異なる組合せまたは順序付けを使用して、実施形態を実施することができることを理解されたい。従って、本明細書および図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。
【0108】
また、本発明は様々なコンピュータシステムで実施できることに留意されたい。本明細書において説明される様々な技法は、ハードウェアまたはソフトウェア、または両方の組み合わせで具体化され得る。好ましくは、これらの技法は、各々がプロセッサと、(揮発性および不揮発性メモリおよび/またはストレージ素子を含む)プロセッサによって読み取り可能な記憶媒体と、少なくとも1つの入力デバイスと、少なくとも1つの出力デバイスと、を含む複数のコンピュータ上で実行されるプログラム可能なコンピュータプログラムにおいて具体化される。プログラムコードは、入力デバイスを使用して入力されたデータに適用され、上記した機能を実行し、出力情報を生成する。出力情報は、1つ以上の出力デバイスに適用される。各プログラムは、コンピュータシステムと通信するために、概略的な手続き型またはオブジェクト指向プログラミング言語で実装されることが好ましい。ただし、必要に応じて、プログラムは、アセンブリ言語または機械語で具体化され得る。いずれの場合でも、言語は、コンパイルされた言語またはインタープリター言語であり得る。このような各コンピュータプログラムは、好ましくは、記憶媒体または装置がコンピュータによって読み取られて上述の手順を実行するときに、コンピュータを構成および動作させるための汎用または特殊目的のプログラム可能なコンピュータによって読み取り可能な記憶媒体または装置(例えば、ROMまたは磁気ディスク)に記憶される。また、システムは、コンピュータプログラムを有するように構成されたコンピュータ可読記憶媒体として具体化されるように検討され、そのように構成された記憶媒体は、コンピュータを特定の所定の方法で動作させる。さらに、例示的なコンピューティングアプリケーションのストレージ要素は、様々な組み合わせおよび構成でデータを格納することができるリレーショナルまたはシーケンシャル(フラットファイル)タイプのコンピューティングデータベースとすることができる。
【0109】
図16は、本明細書に記載されたシステムおよびデバイスの特徴を組み込む発信源装置1612および宛先装置1610の概略図である。
図16に示すように、例示的な動画コーディングシステム1610は、発信源装置1612と、宛先装置1616とを含み、この例では、発信源装置1612が、符号化された動画データを生成する。したがって、発信源装置1612は、動画符号化装置と呼称され得る。宛先装置1616は、発信源装置1612によって生成された符号化された動画データを復号化し得る。したがって、宛先装置1616は、動画復号装置と呼称され得る。発信源装置1612および宛先装置1616は、動画コーディング装置の例であり得る。
【0110】
宛先装置1616は、チャネル1616を介して発信源装置1612から符号化された動画データを受信し得る。チャネル1616は、符号化された動画データを発信源装置1612から宛先装置1616に移動させることができるタイプの媒体またはデバイスを備えてもよい。一例では、チャネル1616は、発信源装置1612が符号化された動画データを宛先装置1616にリアルタイムで直接的に送信することを可能にする通信媒体を備えてもよい。
【0111】
この例では、発信源装置1612は、無線通信プロトコルなどの通信規格に従って符号化された動画データを変調し、変調された動画データを宛先装置1616に送信し得る。通信媒体は、無線周波数(RF)スペクトルまたは1つまたは複数の物理的伝送線などの無線または有線の通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットなどのグローバルネットワークなどのパケットベースのネットワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、または発信源装置1612から宛先装置1616への通信を可能にする他の機器を含み得る。別の例では、チャネル1616は、発信源装置1612によって生成された符号化動画データを格納する記憶媒体に対応し得る。
【0112】
図16の例では、発信源装置1612は、動画ソース(video source)1618、動画符号化器1620、および出力インタフェース1622を含む。場合によっては、出力インタフェース1628は、変調器/復調器(モデム)および/または送信機を含み得る。発信源装置1612において、動画ソース1618は、例えば動画カメラなどの動画キャプチャデバイス、前にキャプチャされた動画データを含む動画アーカイブ、動画コンテンツプロバイダから動画データを受信するための動画フィードインタフェース、および/または動画データを生成するためのコンピュータグラフィックシステム、またはそのようなソースの組み合わせなどのソースを含んでもよい。
【0113】
動画符号化器1620は、キャプチャされた、事前にキャプチャされた、またはコンピュータによって生成された動画データを符号化してもよい。入力画像は、動画符号化器1620によって受信され、入力フレームメモリ1621に格納され得る。汎用プロセッサ1623は、そこから情報をロードし、符号化を実行し得る。汎用プロセッサを駆動するためのプログラムは、
図16に示される例示的なメモリモジュールのような記憶装置からロードされ得る。汎用プロセッサは、処理メモリ1622を使用して符号化を実行し、汎用プロセッサによる符号化情報の出力は、出力バッファ1626等のバッファに格納され得る。
【0114】
動画符号化器1620は、少なくとも1つのベース層及び少なくとも1つのエンハンスメント層を規定するスケーラブル動画コーディング方式(scalable video coding scheme)で動画データをコード化(例えば、符号化)するように構成される再サンプリングモジュール(resampling module)1625を含み得る。再サンプリングモジュール1625は、符号化プロセスの一部として少なくともいくつかの動画データを再サンプリングしてもよく、再サンプリングは、再サンプリングフィルタを使用して適応的に実行されてもよい。
【0115】
符号化された動画データ、例えば、コード化されたビットストリームは、発信源装置1612の出力インタフェース1628を介して宛先装置1616に直接的に送信され得る。
図16の例では、宛先装置1616は、入力インタフェース1638、動画復号化器1630、およびディスプレイ装置1632を含む。場合によっては、入力インタフェース1628は、受信機および/またはモデムを含み得る。宛先装置1616の入力インタフェース1638は、チャネル1616を介して符号化された動画データを受信する。符号化された動画データは、動画データを表す動画符号化器1620によって生成されたさまざまなシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体で送信されるか、記憶媒体に格納されるか、またはファイルサーバに格納される符号化された動画データに含まれてもよい。
【0116】
符号化された動画データはまた、復号化および/または再生のために宛先装置1616による後のアクセスのために、記憶媒体またはファイルサーバに格納され得る。例えば、コード化されたビットストリームは、入力バッファ1631に一時的に格納され、その後、汎用プロセッサ1633にロードされてもよい。汎用プロセッサを駆動するためのプログラムは、記憶装置またはメモリからロードされてもよい。汎用プロセッサは、プロセスメモリ1632を使用して復号化を実行してもよい。動画復号化器1630はまた、動画符号化器1620で使用される再サンプリングモジュール1625と同様の再サンプリングモジュール1635を含み得る。
【0117】
図16は、再サンプリングモジュール1635を汎用プロセッサ1633とは別に示しているが、再サンプリング機能は、汎用プロセッサによって実行されるプログラムによって実行され、動画符号化器における処理は、1つ以上のプロセッサを使用して達成されることが当業者には理解されよう。復号化された1つまたは複数の画像は、出力フレームバッファ1636に格納され、その後、入力インタフェース1638に送信されてもよい。
【0118】
ディスプレイ装置1638は、宛先装置1616と統合されるか、または外部にあってもよい。いくつかの例では、宛先装置1616は、統合ディスプレイ装置を含むか、または外部ディスプレイ装置とインタフェースするように構成されてもよい。他の例では、宛先装置1616は、ディスプレイ装置であってもよい。概して、ディスプレイ装置1638は、復号化された動画データをユーザに表示する。
【0119】
動画符号化器1620および動画復号化器1630は、動画圧縮規格に従って動作し得る。ITU-T VCEG(Q6/16)およびISO/IEC MPEG(JTC 1/SC 29/WG 11)は、現在の高効率動画コーディングHEVC規格(スクリーンコンテンツコーディングおよび高い動的範囲のコーディングのためのその現在の拡張および近い将来の拡張を含む)のものを大幅に超える圧縮能力を有する、将来的な動画コーディング技法の標準化のための潜在的必要性を現在研究している。これらのグループは、この分野におけるそれらの専門家によって提案された圧縮技術設計を評価するために、JVET(Joint Video Exploration Team)として知られる共同コラボレーションのこの調査活動で協働している。JVET開発の最近の記録は、J.Chen、E.Alshina、G.Sullivan、J.Ohm、J.Boyce著「Algorithm Description of Joint Exploration Test Model 5 (JEM 5)」、JVET-E1001-V2に記載されている。
【0120】
追加または代替的に、動画符号化器1620および動画復号化器1630は、開示されたJVETの特徴と共に機能する他の独自規格または業界規格に従って動作し得る。つまり、他の規格には、ITU-T H.264規格、代替的にはMPEG-4、Part 10、Advanced Video Coding(AVC)、またはそのような規格の拡張などの他の規格がある。したがって、本開示の技法は、JVETのために新たに開発されたが、特定のコーディング規格または技法に限定されない。動画圧縮規格および技法の他の例は、MPEG-2、ITU-T H.263、および独自のまたはオープンソースの圧縮フォーマットおよび関連フォーマットを含む。
【0121】
動画符号化器1620および動画復号化器1630は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで具体化され得る。例えば、動画符号化器1620および復号化器1630は、1つ以上のプロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、離散ロジック、またはそれらの任意の組み合わせを使用することができる。
【0122】
動画符号化器1620および復号化器1630が部分的にソフトウェアで具体化される場合、装置は、適切な、一時的でないコンピュータ可読記憶媒体にソフトウェアの複数の命令を格納し、本開示の技法を実行するために、1つ以上のプロセッサを使用してハードウェアで複数の命令を実行し得る。動画符号化器1620および動画復号化器1630の各々は、1つまたは複数の符号化器または復号化器に含まれることがあり、そのいずれもが、それぞれの装置内の複合符号化器/復号化器(コーデック)の一部として統合されることがある。
【0123】
本明細書に記載する主題の態様は、上述した汎用プロセッサ1623および1633のようなコンピュータによって実行されるプログラムモジュールのようなコンピュータ実行可能な複数の命令の全体的な文脈において説明され得る。概して、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本明細書に記載する主題の態様は、通信ネットワークを介してリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境においても実施され得る。分散コンピューティング環境では、複数のプログラムモジュールは、メモリ記憶装置を含むローカルとリモートの両方のコンピュータ記憶媒体に配置され得る。
【0124】
メモリの複数の例は、ランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、またはその両方を含む。メモリは、上記した技法を実行するためのソースコードまたはバイナリコードなどの複数の命令を格納し得る。メモリはまた、プロセッサ1623および1633などのプロセッサによって実行される複数の命令の実行中に変数または他の中間情報を格納するために使用されてもよい。
【0125】
記憶装置は、上記した技法を実行するためのソースコードまたはバイナリコードなどの複数の命令を格納し得る。記憶装置は、コンピュータプロセッサによって使用および操作されるデータをさらに格納してもよい。例えば、動画符号化器1620または動画復号化器1630内の記憶装置は、コンピュータシステム1623または1633によってアクセスされるデータベースであってもよい。
【0126】
記憶装置の他の複数の例は、ランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、ハードドライブ、磁気ディスク、光ディスク、CD-ROM、DVD、フラッシュメモリ、USBメモリカード、またはコンピュータが読み取ることができる任意の他の媒体を含む。
【0127】
メモリまたは記憶装置は、動画符号化器および/または復号化器によって、またはそれらに関連して使用するための非一時的なコンピュータ可読記憶媒体の一例であり得る。非一時的なコンピュータ可読記憶媒体は、特定の実施形態によって説明された複数の機能を実行するように構成されるコンピュータシステムを制御するための複数の命令を含む。複数の命令は、1つ以上のコンピュータプロセッサによって実行されると、特定の実施形態で説明されているものを実行するように構成され得る。
【0128】
また、いくつかの実施形態は、フロー図またはブロック図として示されるプロセスとして説明されていることに留意されたい。それぞれが複数の演算を順次処理として説明したが、複数の演算の多くは並列または同時に実行することができる。さらに、複数の演算の順序を並べ替えることができる。プロセスは、図面に含まれていない追加のステップを有してもよい。
【0129】
特定の実施形態は、命令実行システム、装置、システムまたはマシンによる使用またはそれと関連しての使用のための非一時的なコンピュータ可読記憶媒体に実装され得る。コンピュータ可読記憶媒体は、特定の実施形態によって説明したように、方法を実行するためにコンピュータシステムを制御するための命令を含む。コンピュータシステムは、1つ以上のコンピューティングデバイスを含み得る。1つ以上のコンピュータプロセッサによって実行されると、命令は、特定の実施形態に記載されているものを実行するように構成され得る。
【0130】
本明細書の説明においておよび以下の特許請求の範囲を通して使用される際に、文脈が別様に明確に指示しない限り、「1つの(a、an)」および「該、前記(the)」は複数への言及を含む。また、本明細書の説明においておよび以下の特許請求の範囲を通して使用される際に、文脈が別様に明確に指示しない限り、「において、における、内の、内に、(in)」の意味は、「において、における、内の、内に、(in)」および「の上の、の上で(on)」を含む。
【0131】
本発明の例示的な実施形態は、上記した構造的特徴および/または方法論動作に特有の詳細および言語で説明されてきたが、当業者は、本発明の新規な教示および利点から実質的に逸脱することなく、例示的な実施形態において多くの追加の変更が可能であることを容易に理解するであろう。さらに、添付の特許請求の範囲に定義される主題は、必ずしも上記した特定の特徴または動作に限定されないことを理解されたい。従って、これら及び全てのそのような変更は、添付の特許請求の範囲に従った広さ及び範囲で解釈される本発明の範囲内に含まれることが意図されている。