(57)【要約】ＪＶＥＴのための動画コーディングブロックを分割する方法において、ＭＰＭのセットは、６つ以外のイントラ予測コーディングモードのセットを含み、truncated unary二値化を使用して符号化される。１６個の選択されたイントラ予測コーディングモードは、固定長コードの４ビットを用いて符号化される。残りの非選択のコーディングモードは、truncatedバイナリコーディングを用いて符号化される。ＪＶＥＴコーディングツリーユニットは、ＱＴＢＴ構造のルートノードとしてコード化され得る。ＱＴＢＴ構造は、ルートノードから分岐する四分木と、四分木の複数のリーフノードの各々から分岐する二分木とを有し、非対称２分割を使用して、四分木のリーフノードによって表されたコーディングユニットを複数の子ノードに分割し、複数の子ノードを四分木のリーフノードから分岐する２分木の複数のリーフノードとして表す。
2020529157.tif 000002
【特許請求の範囲】
【請求項１】
ＪＶＥＴイントラ予測のための動画コーディング方法であって、
固有のイントラ予測コーディングモードのセットを規定すること、
前記固有のイントラ予測コーディングモードのセットから固有のＭＰＭイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、
前記固有のＭＰＭイントラ予測コーディングモードのサブセット以外の前記固有のイントラ予測コーディングモードのセットから、選択された固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、
前記固有のＭＰＭイントラ予測コーディングモードのサブセット以外であり且つ前記選択された固有のイントラ予測コーディングモードのサブセット以外の前記固有のイントラ予測コーディングモードのセットから、非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、
truncated unary二値化を使用して、前記固有のＭＰＭイントラ予測コーディングモードのサブセットをコーディングすること、を備える動画コーディング方法。
【請求項２】
前記ＭＰＭイントラ予測コーディングモードのサブセットは、６つ未満のＭＰＭイントラ予測コーディングモードのサブセットである、請求項１に記載の動画コーディング方法。
【請求項３】
前記選択された固有のイントラ予測符号化モードのサブセットは、１６個のイントラ予測コーディングモードのサブセットである、請求項２に記載の動画コーディング方法。
【請求項４】
前記固有のイントラ予測コーディングモードのセットは、６７個のイントラ予測コーディングモードのセットである、請求項３に記載の動画コーディング方法。
【請求項５】
前記ＭＰＭイントラ予測コーディングモードのサブセットは、６つよりも多いＭＰＭイントラ予測コーディングモードのサブセットである、請求項１に記載の動画コーディング方法。
【請求項６】
前記選択された固有のイントラ予測符号化モードのサブセットは、１６個のイントラ予測コーディングモードのサブセットである、請求項５に記載の動画コーディング方法。
【請求項７】
前記固有のイントラ予測コーディングモードのセットは、６７個のイントラ予測コーディングモードのセットである、請求項６に記載の動画コーディング方法。
【請求項８】
前記固有のイントラ予測コーディングモードのセットは、６７個のイントラ予測コーディングモードのセットである、請求項１に記載の動画コーディング方法。
【請求項９】
前記ＭＰＭイントラ予測コーディングモードのサブセットは、６つよりも多いＭＰＭイントラ予測コーディングモードのサブセットである、請求項８に記載の動画コーディング方法。
【請求項１０】
前記選択された固有のイントラ予測符号化モードのサブセットは、１６個のイントラ予測コーディングモードのサブセットである、請求項２に記載の動画コーディング方法。
【請求項１１】
前記選択された固有のイントラ予測コーディングモードのサブセットは、４ビットの固定長コードを使用して符号化される、請求項１０に記載の動画コーディング方法。
【請求項１２】
前記固有の非選択のイントラ予測コーディングモードのサブセットは、truncatedバイナリコーディングを使用して符号化される、請求項１１に記載の動画コーディング方法。
【請求項１３】
前記ＭＰＭイントラ予測コーディングモードのサブセットは、５つのＭＰＭイントラ予測符号化モードのサブセットであり、
前記選択された固有のイントラ予測コーディングモードのサブセットは、１６個のイントラ予測コーディングモードのサブセットであり、４ビットの固定長コードを用いて符号化され、前記非選択の固有のイントラ予測コーディングモードのサブセットは、４６個の非選択のイントラコーディングモードのサブセットであり、truncatedバイナリコーディングを用いて符号化される、請求項１に記載の動画コーディング方法。
【請求項１４】
ＪＶＥＴイントラ予測のための動画コーディングシステムであって、
６７個の固有のイントラ予測コーディングモードのセットをメモリにおいてインスタンス化すること、
前記固有のイントラ予測コーディングモードのセットから固有のＭＰＭイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、
前記固有のＭＰＭイントラ予測コーディングモードのサブセット以外の前記固有のイントラ予測コーディングモードのセットから、１６個の選択された固有のイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、
前記固有のＭＰＭイントラ予測コーディングモードのサブセット以外であり且つ前記選択された固有のイントラ予測コーディングモードのサブセット以外の前記固有のイントラ予測コーディングモードのセットから、非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、
truncated unary二値化を用いて、前記固有のＭＰＭイントラ予測コーディングモードのサブセットを符号化すること、
４ビットの固定長コードを用いて、前記１６個の選択された固有のイントラ予測コーディングモードのサブセットを符号化すること、を備える動画コーディングシステム。
【請求項１５】
前記固有のＭＰＭイントラ予測コーディングモードのサブセットは、５つ以下のＭＰＭイントラ予測コーディングモードのサブセットである、請求項１４に記載の動画コーディングシステム。
【請求項１６】
前記固有のＭＰＭイントラ予測コーディングモードのサブセットは、５つのＭＰＭイントラ予測コーディングモードのサブセットである、請求項１４に記載の動画コーディングシステム。
【請求項１７】
前記非選択の固有のイントラ予測コーディングモードのサブセットは、４６個のＭＰＭイントラ予測コーディングモードのサブセットである、請求項１６に記載の動画コーディングシステム。
【請求項１８】
前記固有のＭＰＭイントラ予測コーディングモードのサブセットは、４つのＭＰＭイントラ予測コーディングモードのサブセットである、請求項１４に記載の動画コーディングシステム。
【請求項１９】
前記非選択の固有のイントラ予測コーディングモードのサブセットは、４７個のＭＰＭイントラ予測コーディングモードのサブセットである、請求項１８に記載の動画コーディングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、動画コーディング、より具体的には効率的なイントラモードコーディングの分野に関する。
【背景技術】
【０００２】
進化する動画コーディング規格の技術的改善は、コーディング効率を高めて、より高いビットレート、より高い解像度、より良い動画品質を実現する傾向を示している。Joint Video Exploration Teamは、ＪＶＥＴと呼称される新しい動画コーディング方式を開発している。ＨＥＶＣ（High Efficiency Video Coding）などの他の動画コーディング方式と同様に、ＪＶＥＴは、ブロックベースのハイブリッド空間および時間予測コーディング方式である。ただし、ＨＥＶに比べて、ＪＶＥＴは、復号化された複数の画像を生成するためのビットストリーム構造、シンタックス、制約、およびマッピングに対する多くの変更を含む。ＪＶＥＴは、ＪＥＭ（Joint Exploration Model）符号化器および復号化器に実装されている。
【０００３】
現在のＪＶＥＴ規格には、平面（planar）モード、ＤＣモード、６５個の方向性角度（directional angular）イントラモードを含む合計６７個のイントラ予測モード（intra prediction mode）が記述されている。これら６７個のモードを効率的にコード化するために、すべてのイントラモードは、６つの最確モード（most probable mode : MPM）のセット、１６個の選択モードのセット、および４５個の非選択モードのセットを含む３つのセットに細分化される。
【０００４】
６つのＭＰＭは、利用可能な近傍ブロックのモード、導出されたイントラモードおよびデフォルトのイントラモードから導出される。現在のブロックの５つの隣接ブロックのイントラモードを図１ａに示す。これらは、左（Ｌ）、上（Ａ）、左下（ＢＬ）、右上（ＡＲ）、左上（ＡＬ）であり、現在のブロックのＭＰＭリストを形成するために使用される。初期のＭＰＭリストは、５つの隣接イントラモード、平面モード、およびＤＣモードをＭＰＭリストに挿入することによって作成される。プルーニングプロセス（pruning process）が使用されて重複したモードを削除し、固有のモードのみをＭＰＭリストに含めることができる。複数の初期モードが含まれる順序は、左、上、平面、ＤＣ、左下、右上、左上である。
【０００５】
ＭＰＭリストが埋まっていない場合、導出されたモードが追加され、これらのイントラモードは、ＭＰＭリストに既に含まれている角度モードに「−１」または「＋１」を加えることによって導出される。ＭＰＭリストがまだ完全でない場合、複数のデフォルトモードは、垂直、水平、モード２（mode 2）、および斜めモードの順序で追加される。このプロセスの結果、６つのＭＰＭモードの固有のリストが生成される。
【０００６】
６つのＭＰＭのエントロピーコーディングでは、図１ｂに示されるtruncated unary二値化が、現在使用されている。ＭＰＭモードの最初の３つのビン（bin）は、現在信号伝達されているビンに関連するＭＰＭモードに依存する複数のコンテキストでコード化される。ＭＰＭモードは、（ａ）主として水平である（すなわち、ＭＰＭモード番号は、対角線方向のモード番号よりも小さい）モード、（ｂ）主として垂直である（つまり、ＭＰＭモードが、対角線方向のモード番号より大きい）モード、（ｃ）非角度（non-angular）（ＤＣおよび平面）クラスの３つのカテゴリのうちの１つに分類される。したがって、３つのコンテキストは、この分類に基づいてＭＰＭインデックスを信号伝達するために用いられる。
【０００７】
残りの６１個の非ＭＰＭを選択するためのコーディングは、次のように行われる。６１個の非ＭＰＭは最初に、選択モードセットと非選択モードセットの２つのセットに分割される。選択されたモードセットは、１６個のモードを含み、残り（４５個のモード）は、非選択のモードセットに割り当てられる。現在のモードが属するモードセットは、ビットストリームにおいてフラグで示される。示されたモードが選択モードセット内にある場合、選択されたモードは、４ビットの固定長コードで信号伝達され、示されたモードが非選択モードセットからのものである場合、選択されたモードは、truncatedバイナリコードで信号伝達される。例として、選択されたモードセットは、以下のように６１個の非ＭＰＭモードをサブサンプリングすることによって生成される。
【０００８】
選択モードセット＝｛０，４，８，１２，１６，２０…６０｝
非選択モードセット＝｛１、２、３、５、６、７、９、１０…５９｝
現在のＪＶＥＴイントラモードコーディングは、以下の図１ｂに要約されている。
【０００９】
図１ｂに示すように、ＭＰＭリストの最後の２つのエントリは、１６個の選択モードに割り当てられたビンの数と同じである６つのビンを必要とする。このような構成は、ＭＰＭリストの最後の２つのモードのコーディングパフォーマンスの点では利点を有していない。また、ＭＰＭモードの最初の３つのビンはコンテキストベースのエントロピーコーディングでコーディングされているため、ＭＰＭモードの６つのビンの符号化の複雑さは、選択モードの６つのビンのコーディングよりも高い。
【００１０】
イントラモードコーディングに関連するコーディングの負担および帯域幅を低減するシステムおよび方法が必要とされている。
【発明の概要】
【００１１】
本開示は、ＪＶＥＴイントラ予測のための動画コーディング方法を提供し、この動画コーディング方法は、固有のイントラ予測コーディングモードのセットを規定することであって、いくつかの実施形態では、６７個のモードとすることができる、規定すること、前記固有のイントラ予測コーディングモードのセットから固有のＭＰＭイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化することであって、いくつかの実施形態では、７つ以上のうちの５つ以下とすることができる、特定してインスタンス化すること、を含む。またこの方法は、固有のＭＰＭイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、幾つかの実施形態において１６個のコーディングモードを含み得る選択された固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、固有のＭＰＭイントラ予測コーディングモードのサブセット以外であり且つ選択された固有のイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、イントラ予測モードのバランスを構成する非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいて特定してインスタンス化すること、を提供する。次に、truncated unary二値化を使用して、固有のＭＰＭイントラ予測コーディングモードのサブセットをコーディングする。
【００１２】
また本開示は、ＪＶＥＴイントラ予測のための動画コーディングシステムを提供し、幾つかの実施形態において、この動画コーディングシステムは、６７個の固有のイントラ予測コーディングモードのセットをメモリにおいてインスタンス化すること、固有のイントラ予測コーディングモードのセットから固有のＭＰＭイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、固有のＭＰＭイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、１６個の固有の選択されたイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、固有のＭＰＭイントラ予測コーディングモードのサブセット以外であり且つ固有の選択されたイントラ予測コーディングモードのサブセット以外の固有のイントラ予測コーディングモードのセットから、非選択の固有のイントラ予測コーディングモードのサブセットをメモリにおいてインスタンス化すること、truncated unary二値化を使用して、固有のＭＰＭイントラ予測コーディングモードのサブセットを符号化すること、４ビットの固定長コードを使用して、１６個の選択された固有のイントラ予測コーディングモードのサブセットを符号化すること、を備える。
【図面の簡単な説明】
【００１３】
本発明のさらなる詳細は、添付図面を用いて説明される。
【図１ａ】現在のコーディングブロックに関連する隣接ブロックを示す。
【図１ｂ】イントラモード予測のための現在のＪＶＥＴコーディングの表を示す。
【図１ｃ】フレームの複数のコーディングツリーユニット（Coding Tree Units : CTUs）への分割を示す。
【図２】四分木分割および対称２分割を用いたＣＴＵの複数のコーディングユニット（Coding Units : CUs））への例示的な分割を示す。
【図３】図２の分割のＱＴＢＴ（quadtree plus binary tree）表現を示す。
【図４】ＣＵをより小さい２つのＣＵに非対称２分割する４つの可能なタイプを示す。
【図５】四分木分割、対称２分割、及び非対称２分割を用いたＣＴＵの複数のＣＵへの例示的な分割を示す。
【図６】図５の分割のＱＴＢＴ表現を示す。
【図７】ＪＶＥＴ符号化器におけるＣＵコーディングの簡略化されたブロック図を示す。
【図８】ＪＶＥＴの輝度成分の６７個の可能なイントラ予測モードを示す。
【図９】ＪＶＥＴ符号化器におけるＣＵコーディングの簡略化されたブロック図を示す。
【図１０】ＪＶＥＴ符号化器におけるＣＵコーディングの方法の実施形態を示す。
【図１１】ＪＶＥＴ符号化器におけるＣＵコーディングの簡略化されたブロック図を示す。
【図１２】ＪＶＥＴ復号化器におけるＣＵ復号化の簡略化されたブロック図を示す。
【図１３】イントラモード予測のためのＪＶＥＴコーディングの代替的な簡略化されたブロック図を示す。
【図１４】イントラモード予測のための代替的なＪＶＥＴコーディングの表を示す。
【図１５】ＣＵコーディングの方法を処理するように適合および／または構成されたコンピュータシステムの実施形態を示す。
【図１６】ＪＶＥＴ符号化器／復号化器におけるＣＵ符号化／復号化のための符号化／復号化システムの実施形態を示す。
【発明を実施するための形態】
【００１４】
図１は、フレームの複数のコーディングツリーユニット（Coding Tree Units : CTUs）１００への分割を示す。フレームは、動画シーケンスの画像であり得る。フレームは、画像内の強度測定値を表す複数の画素値を有する行列（matrix）または一組の行列を含み得る。したがって、これらの一組の行列によって、動画シーケンスが生成され得る。複数の画素値は、複数の画素が３つのチャネルに分割されるフルカラー動画コーディングにおいて色及び明るさを表すように定義され得る。たとえば、ＹＣｂＣｒ色空間では、複数の画素は、画像のグレーレベル（gray level）の強度を表す輝度値Ｙと、グレーから青および赤までの色の違いを表す２つのクロミナンス値（chrominance value）Ｃｂ，Ｃｒを有する。他の実施形態では、複数の画素値は、異なる色空間またはモデルの値で表すことができる。動画の解像度によって、フレームの画素数が決定される。解像度が高いほど、画素数が多くなり、画像の鮮明度が向上するが、帯域幅、ストレージ（storage）、および伝送の要件も高くなる。
【００１５】
動画シーケンスの複数のフレームは、ＪＶＥＴを使用して符号化および復号化され得る。ＪＶＥＴは、Joint Video Exploration Teamによって開発されている動画コーディング方式である。ＪＶＥＴの複数のバージョンは、ＪＥＭ（Joint Exploration Model）復号化器および複合化器に実装されている。ＨＥＶＣ（High Efficiency Video Coding）などの他の動画コーディング方式と同様に、ＪＶＥＴは、ブロックベースのハイブリッド空間および時間予測コーディング方式である。ＪＶＥＴでのコーディングにおいて、フレームは、図１に示されるように、ＣＴＵ１００と呼称される複数の正方形ブロックに最初に分割される。たとえば、複数のＣＴＵ１００は、１２８ｘ１２８画素の複数のブロックであり得る。
【００１６】
図２は、ＣＴＵ１００の複数のＣＵ１０２への例示的な分割を示す。フレーム内の各ＣＴＵ１００は、１つ以上のＣＵ（Coding Unit）１０２に分割され得る。１つ以上のＣＵ１０２は、以下で説明するように予測および変換のために使用され得る。ＨＥＶＣとは異なり、ＪＶＥＴでは、複数のＣＵ１０２は、長方形または正方形であってもよく、複数の予測ユニットまたは複数の変換ユニットにさらに分割することなくコード化され得る。複数のＣＵ１０２は、それらのルート（root）ＣＴＵ１００と同じ大きさであるか、または４×４ブロックと同じくらい小さいルートＣＴＵ１００のより小さな細分区画（subdivision）であり得る。
【００１７】
ＪＶＥＴでは、ＣＴＵ１００は、ＱＴＢＴ（quadtree plus  binary tree）方式に従って複数のＣＵ１０２に分割され得る。この方式では、ＣＴＵ１００は、四分木に従って複数の正方形ブロックに再帰的に分割され、これらの正方形ブロックは、二分木に従って水平または垂直に再帰的に分割され得る。複数のパラメータは、ＣＴＵサイズ、四分木および二分木のリーフノード（leaf node）の最小サイズ、二分木のリーフノードの最大サイズ、二分木の最大深さなどのＱＴＢＴに従って分割を制御するように設定され得る。
【００１８】
いくつかの実施形態では、ＪＶＥＴは、ＱＴＢＴの二分木部分の２分割（binary partitioning）を対称分割に制限することができ、複数のブロックは、正中線（midline）に沿って垂直または水平のいずれかで半分に分割される。
【００１９】
非限定的な例として、図２は、複数のＣＵ１０２に分割されたＣＴＵ１００を示し、実線は四分木分割を示し、破線は対称二分木分割を示す。図示されているように、２分割によって、対称的な水平分割と垂直分割が可能になり、ＣＴＵの構造および複数のＣＵへの細分化を定義することができる。
【００２０】
図３は、図２の分割のＱＴＢＴ表現（representation）を示す。四分木ルートノードは、親の正方形ブロックから分割された四つの正方形ブロックのうちの一つを表す四分木部分の各子ノードを有するＣＴＵ１００を表す。複数の四分木リーフノードで表される複数の正方形ブロックは、二分木を使用して対称的に０回以上分割され、複数の四分木リーフノードは、二分木の複数のルートノードである。二分木部分の各レベルで、ブロックは、垂直または水平に対称的に分割され得る。「０」に設定されたフラグは、ブロックが水平方向に対称的に分割されることを示し、「１」に設定されたフラグは、ブロックが垂直方向に対称的に分割されることを示す。
【００２１】
他の実施形態では、ＪＶＥＴは、ＱＴＢＴの二分木部分における対称２分割または非対称２分割のいずれかを可能にすることができる。非対称モーション分割（Asymmetrical motion partitioning : AMP）は、複数の予測ユニット（prediction unit : PU）を分割する場合、ＨＥＶＣの異なるコンテキストで可能である。しかし、ＱＴＢＴ構造に従ってＪＶＥＴ内の複数のＣＵ１０２を分割する場合、ＣＵ１０２の複数の相関領域（correlated area）がＣＵ１０２の中心を通る正中線の両側に配置されていないとき、非対称２分割は、対称２分割に対する改善された分割をもたらすことができる。非限定的な例として、ＣＵ１０２が、ＣＵの中心に近接する１つのオブジェクトと、ＣＵ１０２の側部にある別のオブジェクトとを示す場合、ＣＵ１０２は、非対称的に分割されて、各オブジェクトを異なるサイズの別個のより小さいＣＵ１０２に配置することができる。
【００２２】
図４は、４つの可能なタイプの非対称２分割を示し、ＣＵ１０２は、ＣＵ１０２の長さまたは高さを横切る線に沿って２つのより小さいＣＵ１０２に分割され、２つのより小さいＣＵ１０２の一方は親ＣＵ１０２のサイズの２５％であり、他方は親ＣＵ１０２のサイズの７５％である。図４に示す４つのタイプの非対称２分割によって、ＣＵ１０２は、ＣＵ１０２の左側から２５％離れた、ＣＵ１０２の右側から２５％離れた、ＣＵ１０２の上部から２５％離れた、またはＣＵ１０２の下部から２５％離れた線に沿って分割可能である。別の実施形態では、ＣＵ１０２が分割される非対称分割線は、ＣＵ１０２が半分に対称的に分割されないような他の任意の位置に配置され得る。
【００２３】
図５は、ＱＴＢＴの二分木部分において対称２分割および非対称２分割の両方を可能にする方式を使用して複数のＣＵ１０２に分割されたＣＴＵ１００の非限定的な例を示す。図５において、破線は、非対称２分割線を示し、親ＣＵ１０２は、図４に示される複数の分割タイプのうちの１つを使用して分割されている。
【００２４】
図６は、図５の分割のＱＴＢＴ表現を示す。図６において、ノードから延びる２本の実線は、ＱＴＢＴの二分木部分における対称分割を示し、ノードから延びる２本の破線は、二分木部分における非対称分割を示す。
【００２５】
どのようにＣＴＵ１００が複数のＣＵ１０２に分割されたかを示すシンタックス（syntax）は、ビットストリームにコード化され得る。非限定的な例として、シンタックスはビットストリームにコード化されて、どのノードが四分木分割で分割され、対称２分割で分割され、非対称２分割で分割されたかを示すことができる。同様に、シンタックスは、非対称２分割を用いて分割された複数のノードのためにビットストリームにコード化され、図４に示される４つのタイプのうちの１つのような、どのタイプの非対称２分割が使用されたかを示すことができる。
【００２６】
いくつかの実施形態では、非対称分割の使用は、ＱＴＢＴの四分木部分の複数のリーフノードで複数のＣＵ１０２を分割することに限定することができる。これらの実施形態では、四分木部分で四分木分割を使用して親ノードから分割された複数の子ノードのＣＵ１０２は、最終ＣＵ１０２であるか、または四分木分割、対称２分割、または非対称２分割を使用してさらに分割され得る。対称２分割を使用して分割された二分木部分の複数の子ノードは、最終ＣＵ１０２であるか、または対称２分割のみを使用して再帰的に１回以上さらに分割され得る。非対称２分割を使用してＱＴリーフノードから分割された二分木部分の複数の子ノードは、それ以上の分割されない最終ＣＵ１０２であり得る。
【００２７】
これらの実施形態では、非対称分割の使用を四分木リーフノードの分割に制限することによって、検索の複雑さを軽減し、および／または付加ビット（overhead bit）を制限することができる。四分木リーフノードのみが非対称分割で分割されるため、非対称分割を使用することは、ＱＴ部分の分岐の終端を、他のシンタックスまたはそれ以上の信号伝達なしで直接的に示すことができる。
【００２８】
同様に、非対称に分割された複数のノードはそれ以上分割できないため、ノードでの非対称分割の使用は、その非対称に分割された複数の子ノードが他のシンタックスまたはさらなる信号伝達なしで最終ＣＵ１０２であることを直接的に示すこともできる。
【００２９】
検索の複雑さを制限し、および／または付加ビットの数を制限することがあまり問題でない場合などの代替的な実施形態では、非対称分割は、四分木分割、対称２分割、および／または非対称２分割によって生成された複数のノードを分割するために用いられ得る。
【００３０】
上記したいずれかのＱＴＢＴ構造を使用した四分木分割および二分木分割の後、ＱＴＢＴのリーフノードで表される複数のブロックは、インター予測またはイントラ予測を使用したコード化など、コード化される最終ＣＵ１０２を示す。インター予測でコード化された複数のスライス（slice）または複数のフルフレーム（full frame）の場合、異なる分割構造を輝度成分およびクロマ成分（chroma component）に使用できる。例えば、インタースライス（inter slice）の場合、ＣＵ１０２は、１つの輝度ＣＢと２つのクロマＣＢなどの異なる色成分のコーディングブロック（Coding Block : CB）を有することができる。イントラ予測でコード化された複数のスライスまたは複数のフルフレームの場合、輝度成分およびクロマ成分の分割構造は同じである。
【００３１】
代替実施形態では、ＪＶＥＴは、上述したＱＴＢＴ分割の代替または拡張として２つのレベルのコーディングブロック構造を使用することができる。２つのレベルのコーディングブロック構造では、ＣＴＵ１００は、最初に高いレベルで複数のベースユニット（base unit : BU）に分割され得る。その後、複数のＢＵは、低いレベルで複数のオペレーティングユニット（operating unit : OU）に分割され得る。
【００３２】
２つのレベルのコーディングブロック構造を採用する実施形態では、高レベルで、ＣＴＵ１００は、上記した複数のＱＴＢＴ構造の１つに従って、またはＨＥＶＣで使用されるものなどの四分木（quadtree : QT）構造に従って複数のＢＵに分割され得る。ブロックは、４つの同じサイズのサブブロックにのみ分割され得る。非限定的な例として、図５〜６に関して上述したＱＴＢＴ構造に従って、ＣＴＵ１０２を複数のＢＵに分割することができる。四分木部分の複数のリーフノードは、四分木分割、対称二分木分割、または非対称二分木分割を使用して分割され得る。
【００３３】
この例では、ＱＴＢＴの最終リーフノードは、複数のＣＵではなく複数のＢＵにすることができる。
２つのレベルのコーディングブロック構造のうちの低いレベルでは、ＣＴＵ１００から分割された各ＢＵは、１つまたは複数のＯＵにさらに分割され得る。いくつかの実施形態では、ＢＵが正方形である場合、それは、対称または非対称の２分割など、四分木分割または２分割を使用して、複数のＯＵに分割することができる。ただし、ＢＵが正方形でない場合は、２分割のみを使用して複数のＯＵに分割され得る。非正方形のＢＵに使用できる分割のタイプを制限すると、複数のＢＵの生成に使用される分割の種類を示すために使用されるビット数を制限できる。
【００３４】
以下の説明はＣＵ１０２のコーディングについて説明しているが、２つのレベルのコーディンググブロック構造を使用する実施形態では、ＣＵ１０２の代わりにＢＵおよびＯＵをコード化することができる。非限定的な例として、複数のＢＵは、イントラ予測またはインター予測などの高いレベルのコーディング演算に使用され、より小さな複数のＯＵは、変換や変換係数の生成などの低いレベルのコーディング演算に使用され得る。従って、複数のＢＵのためにコード化されるシンタックスは、それらが、イントラ予測またはインター予測でコード化されるかどうかを示すか、または複数のＢＵをコード化するために使用される特定のイントラ予測モードまたは動きベクトルを識別する情報を示す。同様に、複数のＯＵのシンタックスは、複数のＯＵをコード化するために使用される特定の変換演算または量子化変換係数を識別することができる。
【００３５】
図７は、ＪＶＥＴ符号化器におけるＣＵコーディングの簡略化されたブロック図を示す。動画コーディングの主な段階は、上述したように、分割して複数のＣＵ１０２を特定し、次いで、７０４または７０６で予測を使用して複数のＣＵ１０２を符号化し、７０８で残差（residual）ＣＵ７１０を生成し、７１２で変換し、７１６で量子化し、７２０でエントロピーコーディングする。
【００３６】
図７に示される符号化器および符号化プロセスは、以下でより詳細に説明される復号化プロセスも含む。現在のＣＵ１０２が与えられると、符号化器は、７０４でイントラ予測を空間的に使用するか、７０６でインター予測を時間的に使用して予測ＣＵ７０２を取得し得る。予測コーディングの基本的な考え方は、元の信号と元の信号の予測との間の差分信号または残差信号を送信することである。受信器側では、以下で説明するように、元の信号は、残差と予測を追加することによって再構成され得る。差分信号は元の信号よりも相関が低いため、送信に必要なビットは少なくなる。
【００３７】
画像全体または画像の一部など、全体がイントラ予測ＣＵ１０２によってコード化されたスライスは、他のスライスを参照せずに復号化される「Ｉ」スライスとし、復号化を開始する可能性がある点とし得る。少なくともいくつかのインター予測ＣＵでコード化されたスライスは、１つ以上の参照画像に基づいて復号化できる予測（Ｐ）スライスまたは双予測（Ｂ）スライスであり得る。Ｐスライスは、以前にコード化されたスライスでイントラ予測とインター予測を使用し得る。たとえば、Ｐスライスは、インター予測を使用して「Ｉ」スライスよりもさらに圧縮できるが、それらをコード化するには、以前にコード化されたスライスのコーディングが必要である。Ｂスライスは、２つの異なるフレームからの内挿予測（interpolated prediction）を使用したイントラ予測またはインター予測を使用して、コーディングの前および／または後のスライスからのデータを使用できるため、動き推定プロセスの精度が向上する。幾つかの場合には、Ｐスライス及びＢスライスは、同じスライスの他の部分からのデータが使用されるイントラブロックコピーを使用して符号化するか、または代替的に符号化することもできる。
【００３８】
以下で説明するように、イントラ予測またはインター予測は、隣接する複数のＣＵ１０２または参照画像内の複数のＣＵ１０２など、以前にコード化された複数のＣＵ１０２から再構成された複数のＣＵ７３４に基づいて実行され得る。
【００３９】
７０４でイントラ予測を用いてＣＵ１０２を空間的にコード化すると、画像内の隣接する複数のＣＵ１０２からの複数のサンプルに基づいて、ＣＵ１０２の複数の画素を最適に予測するイントラ予測モードを特定し得る。
【００４０】
ＣＵの輝度成分をコーディングするとき、符号化器は、候補イントラ予測モードのリストを生成できる。ＨＥＶＣは輝度成分の３５個の可能なイントラ予測モードを有していたが、ＪＶＥＴには輝度成分の６７個の可能なイントラ予測モードがある。これらは、隣接する複数の画素から生成された複数の値の三次元平面を使用する平面モード（planar mode）、隣接する複数の画素から平均化された複数の値を使用するＤＣモード、および指示された複数の方向に沿って隣接する複数の画素からコピーされた複数の値を使用する図８に示される６５個の方向性モードを含む。
【００４１】
ＣＵの輝度成分の候補イントラ予測モードのリストを生成する場合、リスト上の候補モードの数は、ＣＵのサイズに依存する。候補リストは、最低のＳＡＴＤ（Sum of Absolute Transform Difference）コストを有するＨＥＶＣの３５個のモードの一部分、複数のＨＥＶＣモードから特定された複数の候補に隣接するＪＶＥＴに追加された複数の新しい方向性モード、以前にコード化された隣接する複数のブロックに使用される複数のイントラ予測モードと複数のデフォルトモードのリストに基づいて識別されるＣＵ１０２の６つの最確モード（most probable mode : MPM）のセットからの複数のモードを含み得る。
【００４２】
ＣＵのクロマ成分をコーディングするとき、候補イントラ予測モードのリストを生成できる。候補モードのリストは、輝度サンプルからのクロスコンポーネント線形モデル投影（cross-component linear model projection）で生成されたモード、クロマブロック内の特定の複数の配列位置の輝度ＣＢで特定された複数のイントラ予測モード、および隣接する複数のブロックで以前に特定された複数のクロマ予測モードを含む。符号化器は、最も低いレート歪みコスト（rate distortion cost）でリスト上の候補モードを特定し、ＣＵの輝度およびクロマ成分をコーディングする際にそれらのイントラ予測モードを使用する。シンタックスは、各ＣＵ１０２のコード化に使用される複数のイントラ予測モードを示すビットストリームにコード化され得る。
【００４３】
ＣＵ１０２の最適なイントラ予測モードが選択された後、符号化器は、それらのモードを使用して予測ＣＵ４０２を生成し得る。選択したモードが方向性モードである場合、４タップフィルタ（4-tap filter）を使用して方向性の精度を向上させることができる。予測ブロックの上部または左側の列または行は、２タップまたは３タップフィルタなどの境界予測フィルタで調整され得る。
【００４４】
予測ＣＵ７０２は、隣接する複数のブロックのフィルタリングされていない複数のサンプルを用いて隣接する複数のブロックのフィルタリングされたサンプルに基づいて生成された予測ＣＵ７０２を調整するＰＤＰＣ（position dependent intra prediction combination）プロセス、または複数の参照サンプルを処理するために３タップまたは５タップのローパスフィルタを用いた適応参照サンプル平滑化（adaptive reference sample smoothing）によってさらに平滑化され得る。
【００４５】
７０６でインター予測を用いてＣＵ１０２が時間的にコード化されると、ＣＵ１０２の複数の画素を最適に予測する複数の参照画像内の複数のサンプルを指す一組の動きベクトル（motion vector : MV）を特定することができる。インター予測は、スライス内の複数の画素のブロックの変位を表すことにより、複数のスライス間の時間的冗長性（temporal redundancy）を利用する。変位は、動き補償と呼ばれるプロセスを通じて、前または後のスライスの複数の画素の値に従って決定される。特定の参照画像に対する画素変位を示す動きベクトルおよび関連する参照インデックスは、元の画素と動き補償された画素との間の残差とともに、復号化器へのビットストリームで提供され得る。復号化器は、残差の信号伝達された（signaled）動きベクトル及び参照インデックスを使用して、再構成されたスライス内の複数の画素のブロックを再構成できる。
【００４６】
ＪＶＥＴでは、動きベクトルの精度は１／１６ペル（ｐｅｌ）で格納され、動きベクトルとＣＵの予測された動きベクトルとの差分は、１／４ペルの解像度または整数ペル解像度でコード化され得る。
【００４７】
ＪＶＥＴにおいて、複数の動きベクトルは、ＣＵ１０２内の複数のサブＣＵについて、高度時間動きベクトル予測（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）などの技法を用いて特定され得る。
【００４８】
符号化器は、ＡＴＭＶＰを使用して、参照画像内の対応するブロックを指すＣＵ１０２の時間ベクトルを特定し得る。時間ベクトルは、以前にコード化された隣接する複数のＣＵ１０２について特定された複数の動きベクトルおよび複数の参照画像に基づいて特定され得る。ＣＵ１０２全体の時間ベクトルによって示される参照ブロックを使用して、ＣＵ１０２内の各サブＣＵの動きベクトルが特定され得る。
【００４９】
ＳＴＭＶＰは、以前にインター予測でコード化された隣接する複数のブロックで特定された複数の動きベクトルを、時間ベクトルとともにスケーリングおよび平均化することによって、サブＣＵの動きベクトルを特定し得る。
【００５０】
アフィン動き補償予測は、ブロックの上部コーナーで特定された２つの制御動きベクトルに基づいて、ブロック内の各サブＣＵの複数の動きベクトルのフィールドを予測するために使用され得る。例えば、複数のサブＣＵの複数の動きベクトルは、ＣＵ１０２内の各４ｘ４ブロックで特定された上部コーナーの複数の動きベクトルに基づいて導出され得る。
【００５１】
ＰＭＭＶＤは、両側マッチング（bilateral matching）またはテンプレートマッチング（template matching）を使用して、現在のＣＵ１０２の初期動きベクトルを特定することができる。両側マッチングは、運動軌道に沿った異なる２つの参照画像内の現在のＣＵ１０２および参照ブロックを特定し、一方、テンプレートマッチングは、現在のＣＵ１０２内の対応する複数のブロックおよびテンプレートによって識別される参照画像を検索することができる。
【００５２】
次いで、ＣＵ１０２について特定された初期動きベクトルは、各サブＣＵについて個別に改良され得る。ＢＩＯは、前後の参照画像に基づく双予測でインター予測を行う場合に使用されて、２つの参照画像間の差分の勾配に基づいてサブＣＵの動きベクトルを特定し得る。
【００５３】
状況によっては、ＣＵのレベルで局所照明補償（local illumination compensation : LIC）を使用して、現在のＣＵ１０２に隣接する複数のサンプルと、候補動きベクトルによって識別される参照ブロックに隣接する対応する複数のサンプルとに基づいて、スケーリング係数パラメータ（scaling factor parameter）およびオフセットパラメータの値を特定することができる。ＪＶＥＴでは、複数のＬＩＣパラメータを変更し、ＣＵのレベルで信号伝達し得る。上記した方法の一部では、ＣＵのサブＣＵごとに特定された複数の動きベクトルを、ＣＵのレベルで復号化器に信号伝達し得る。ＰＭＭＶＤやＢＩＯなどの他の方法の場合、モーション情報は、オーバーヘッドを節約するためにビットストリームで信号伝達されず、復号化器は、同じプロセスで動きベクトルを導出し得る。
【００５４】
ＣＵ１０２の動きベクトルが特定された後、符号化器は、それらの動きベクトルを使用して予測ＣＵ７０２を生成し得る。場合によっては、個々のサブＣＵで複数の動きベクトルが特定された場合、それらの動きベクトルを隣接する１つ以上のサブＣＵで以前に特定された動きベクトルと組み合わせて予測ＣＵ７０２を生成するときに、オーバーラップブロック動き補償（Overlapped Block Motion Compensation : OBMC）が使用され得る。
【００５５】
双予測を使用すると、ＪＶＥＴは、復号化器側動きベクトル調整（decoder-side motion vector refinement : DMVR）を使用して複数の動きベクトルを特定し得る。ＤＭＶＲでは、両側テンプレートマッチングプロセス（bilateral template matching process）を使用して、双方向予測で特定された２つの動きベクトルに基づいて動きベクトルを特定し得る。ＤＭＶＲでは、２つの動きベクトルの各々を用いて生成された複数の予測ＣＵ７０２の重み付けされた組み合わせが特定され、２つの動きベクトルは、それらを、組み合わせられた予測ＣＵ７０２を最適に示す新しい動きベクトルで置き換えることによって改良され得る。
【００５６】
改良された２つの動きベクトルを使用して、最終予測ＣＵ７０２を生成することができる。
上記したように、７０４でのイントラ予測または７０６でのインター予測で予測ＣＵ７０２が特定されると、７０８において、符号化器は、現在のＣＵ１０２から予測ＣＵ７０２を減算し、残差ＣＵ７１０を特定し得る。
【００５７】
符号化器は、７１２において、１つ以上の変換演算を使用して、例えば、離散コサインブロック変換（ＤＣＴ変換）（discrete cosine block transform）を使用してデータを変換ドメインに変換するように、残差ＣＵ７１０を変換ドメイン内の残差ＣＵ７１０を示す変換係数７１４に変換し得る。ＪＶＥＴでは、ＤＣＴ−ＩＩ、ＤＳＴ−ＶＩＩ、ＤＳＴ−ＶＩＩ、ＤＣＴ−ＶＩＩＩ、ＤＳＴ−Ｉ、ＤＣＴ−Ｖ演算など、ＨＥＶＣよりも多くの種類の変換演算が可能である。この可能な複数の変換演算は、複数のサブセットにグループ化され、どのサブセットおよびそれらのサブセット内のどの特定の演算が使用されたかの指示は、符号化器によって信号伝達され得る。いくつかの場合では、大きなブロックサイズ変換が使用されて、特定のサイズよりも大きいＣＵ１０２内の高周波数変換係数をゼロにし（zero out）、その結果、これらのＣＵ１０２については低周波数変換係数のみが維持される。
【００５８】
場合によっては、ＭＤＮＳＳＴ（mode dependent non-separable secondary transform）は、順方向コア変換（forward core transform）後に低周波数変換係数７１４に適用され得る。ＭＤＮＳＳＴ演算では、回転データに基づいてＨｙｐｅｒｃｕｂｅ−Ｇｉｖｅｎｓ変換（Hypercube-Givens Transform  : HyGT）を使用できる。使用すると、特定のＭＤＮＳＳＴ演算を識別するインデックス値は、符号化器から信号伝達され得る。
【００５９】
７１６において、符号化器は、変換係数７１４を量子化変換係数７１６に量子化し得る。各係数の量子化は、量子化パラメータ（quantization parameter : QP）から導出される量子化ステップで係数の値を除算することによって計算され得る。いくつかの実施形態では、Ｑｓｔｅｐは、２（ＱＰ−４）／６として定義される。高精度変換係数７１４は有限個の可能な値を有する量子化変換係数７１６に変換することができるので、量子化は、データ圧縮を補助することができる。
【００６０】
したがって、変換係数の量子化は、変換プロセスによって生成および送信されるビットの量を制限してもよい。ただし、量子化は損失の多い演算であり、量子化による損失は回復できないが、量子化プロセスは、再構成されたシーケンスの品質と、シーケンスを示すのに必要な情報量とのトレードオフを示す。たとえば、ＱＰ値を低くすると、復号化された動画の品質が向上するが、表現と送信には大量のデータが必要になる場合がある。対照的に、ＱＰ値が高いと、再構成された動画シーケンスの品質は低下するが、データと帯域幅の必要性は低くなる。
【００６１】
ＪＶＥＴは、（フレームの各ＣＵ１０２のコーディングにおいて同じフレームＱＰを使用する代わりに）各ＣＵ１０２がそのコーディングプロセスのために異なる量子化パラメータを使用することを可能にする分散ベース適応量子化技法（variance-based adaptive quantization technique）を利用することができる。分散ベース適応量子化技法は、特定のブロックの量子化パラメータを適応的に低下させ、他のブロックでは増加させる。ＣＵ１０２の特定のＱＰを選択するために、ＣＵの分散が計算される。つまり、ＣＵの分散がフレームの平均分散よりも高い場合、フレームのＱＰよりも高いＱＰがＣＵ１０２に対して設定されてもよい。ＣＵ１０２がフレームの平均分散よりも低い分散を示す場合、より低いＱＰが割り当てられてもよい。
【００６２】
７２０において、符号化器は、複数の量子化変換係数７１８をエントロピーコーディングすることによって、複数の最終圧縮ビット７２２を特定し得る。エントロピーコーディングは、送信される情報の統計的な冗長性を除去することを目的としている。ＪＶＥＴでは、確率測度を使用して統計的冗長性を除去するＣＡＢＡＣ（Context Adaptive Binary Arithmetic Coding）を使用して、量子化変換係数７１８をコード化し得る。非ゼロの量子化変換係数７１８を有する複数のＣＵ１０２の場合、量子化変換係数７１８は、バイナリ（binary）に変換され得る。次いで、バイナリ表現の各ビット（「ビン」）は、コンテキストモデルを使用して符号化され得る。ＣＵ１０２は、３つの領域に分割され、各領域は、その領域内の複数の画素に使用する自身の一組のコンテキストモデルを備えている。
【００６３】
複数のスキャンパスは、複数のビンを符号化するために実行され得る。最初の３つのビン（ｂｉｎ０、ｂｉｎ１、ｂｉｎ２）を符号化するパスの間、どのコンテキストモデルをビンに使用すべきかを示すインデックス値は、テンプレートによって識別される前にコード化された最大５つの隣接量子化変換係数７１８においてそのビン位置の合計を求めることによって特定され得る。
【００６４】
コンテキストモデルは、ビンの値が「０」または「１」である確率に基づくことができる。値がコード化されると、実際の「０」値と「１」値の数に基づいて、コンテキストモデルの確率が更新され得る。ＨＥＶＣは新しい各画像のコンテキストモデルを再初期化するために固定テーブルを用いたが、ＪＶＥＴでは、複数の新しいインター予測画像のコンテキストモデルの確率は、以前にコード化されたインター予測画像のために生成されたコンテキストモデルに基づいて初期化され得る。
【００６５】
符号化器は、複数の残差ＣＵ７１０のエントロピー符号化ビット７２２、選択されたイントラ予測モードまたは動きベクトルなどの予測情報、ＱＴＢＴ構造に従って複数のＣＵ１０２がＣＴＵ１００からどのように分割されたかのインジケータ、および／または符号化された動画に関する他の情報を含むビットストリームを生成し得る。以下で説明するように、ビットストリームは、復号化器で復号化され得る。
【００６６】
量子化変換係数７１８を使用して最終圧縮ビット７２２を特定することに加えて、符号化器はまた、量子化変換係数７１８を使用して、復号化器が再構成された複数のＣＵ７３４を生成するために使用するのと同じ復号化プロセスに従うことによって、再構成された複数のＣＵ７３４を生成し得る。したがって、符号化器によって変換係数が計算および量子化されると、量子化変換係数７１８は、符号化器内の復号化ループに送信され得る。複数のＣＵの変換係数を量子化した後、復号化ループは、符号化器に、復号化プロセスにおいて復号化器が生成するものと同じ再構成されたＣＵ７３４を生成させることができる。したがって、符号化器は、新しいＣＵ１０２のイントラ予測またはインター予測を実行するときに、復号化器が隣接する複数のＣＵ１０２または複数の参照画像に使用するのと同じ再構成された複数のＣＵ７３４を使用することができる。再構成された複数のＣＵ１０２、再構成された複数のスライス、または完全に再構成されたフレームは、さらなる予測段階のための参照としての役割を有してもよい。
【００６７】
再構成された画像の複数の画素値を得るために、符号化器の復号化ループにおいて（復号化器の同じ演算のため、以下を参照されたい）、逆量子化プロセスが実行されてもよい。フレームを逆量子化するには、たとえば、フレームの各画素の量子化された値は、上記したＱｓｔｅｐのような量子化ステップによって乗算されて、再構成された逆量子化変換係数７２６を取得する。例えば、符号化器における図７に示す復号化処理では、残差ＣＵ７１０の量子化変換係数７１８は、７２４において逆量子化されて、逆量子化変換係数７２６を求めることができる。符号化においてＭＤＮＳＳＴ演算が実行された場合、その演算は、逆量子化後に逆転され得る（reversed）。
【００６８】
７２８において、逆量子化変換係数７２６は、再構成された画像を得るために複数の値にＤＣＴを適用することなどによって、逆変換（inverse transformed）されて再構成された残差ＣＵ７３０を特定し得る。７３２において、再構成された残差ＣＵ７３０は、再構成されたＣＵ７３４を特定するために、７０４におけるイントラ予測または７０６におけるインター予測で特定された対応する予測ＣＵ７０２に追加され得る。
【００６９】
７３６において、１つ以上のフィルタが、画像レベルまたはＣＵレベルのいずれかで、（符号化器、または以下に説明するように復号化器における）復号化プロセス中に再構成データに適用され得る。たとえば、符号化器は、デブロッキングフィルタ（deblocking filter）、サンプルアダプティブオフセット（sample adaptive offset : SAO）フィルタ、および／またはアダプティブループフィルタ（adaptive loop filter : ALF）を適用できる。符号化器の復号化プロセスは、再構築された画像の潜在的なアーティファクトに対処できる最適なフィルタパラメータを推定し、復号化器に送信するフィルタを実装し得る。このような改善は、再構成された動画の客観的で主観的な品質を向上させる。
【００７０】
デブロッキングフィルタリングでは、サブＣＵ境界付近の複数の画素が修正されるが、ＳＡＯでは、ＣＴＵ１００内の複数の画素は、エッジオフセット（edge offset）またはバンドオフセット（band offset）分類のいずれかを用いて修正され得る。ＪＶＥＴのＡＬＦは、２ｘ２のブロックごとに円形対称形状のフィルタを使用できる。各２ｘ２のブロックに使用されるフィルタのサイズ及びアイデンティティの指示が信号伝達され得る。
【００７１】
再構成された画像が参照画像である場合、７０６において、これらは将来のＣＵ１０２のインター予測のために参照バッファ７３８に格納され得る。
上記した複数のステップにおいて、ＪＶＥＴでは、コンテンツ適応クリッピング演算（content adaptive clipping operation）を使用して、クリッピング境界（clipping bound）の上限と下限との間に合わせて色値を調整可能である。複数のクリッピング境界はスライスごとに変更でき、境界を識別する複数のパラメータはビットストリームで信号伝達され得る。
【００７２】
図９は、ＪＶＥＴ復号化器におけるＣＵコーディングの簡略化されたブロック図を示す。ＪＶＥＴ復号化器は、符号化されたＣＵ１０２に関する情報を含むビットストリームを受信し得る。ビットストリームは、ＱＴＢＴ構造に従ってＣＴＵ１００から画像の複数のＣＵ１０２がどのように分割されたかを示すことができる。非限定的な例として、ビットストリームは、四分木分割、対称２分割、および／または非対称２分割を使用して、ＱＴＢＴ内の各ＣＴＵ１００から複数のＣＵ１０２がどのように分割されたかを識別できる。ビットストリームは、イントラ予測モードまたは動きベクトルなどの複数のＣＵ１０２の予測情報、およびエントロピー符号化された残差ＣＵを表す複数のビット９０２も示すことができる。
【００７３】
９０４において、復号化器は、符号化器によってビットストリームで信号伝達されたＣＡＢＡＣコンテキストモデルを使用してエントロピー符号化された複数のビット９０２を復号化し得る。復号化器は、符号化器によって信号伝達された複数のパラメータを使用して、符号化中に更新されたのと同じ方法でコンテキストモデルの確率を更新し得る。
【００７４】
９０４においてエントロピー符号化を逆転させて量子化変換係数９０６を特定した後、復号化器は、９０８においてそれらを逆量子化して逆量子化変換係数９１０を特定し得る。符号化においてＭＤＮＳＳＴ演算が実行された場合、その演算は、逆量子化後に復号化器によって逆転され得る。
【００７５】
９１２において、逆量子化された複数の変換係数９１０は、再構成された残差ＣＵ９１４を特定するために逆変換され得る。９１６において、再構成された残差ＣＵ９１４は、再構成されたＣＵ９１８を特定するために、９２２におけるイントラ予測または９２４におけるインター予測で特定された対応する予測ＣＵ９２６に追加され得る。
【００７６】
９２０において、画像レベルまたはＣＵレベルのいずれかで、１つまたは複数のフィルタは、再構成されたデータに適用され得る。たとえば、復号化器は、デブロッキングフィルタ、サンプルアダプティブオフセット（sample adaptive offset : SAO）フィルタ、および／またはアダプティブループフィルタ（adaptive loop filter : ALF）を適用できる。上述したように、符号化器の復号化ループにあるインループフィルタ（in-loop filter）を使用して、最適なフィルタパラメータを推定し、フレームの客観的で主観的な品質を向上させることができる。９２０において、これらのパラメータは復号化器に送信されて、再構成されたフレームをフィルタリングして、符号化器内のフィルタリングされた再構成されたフレームに一致させる。
【００７７】
再構成された複数のＣＵ９１８を特定して信号伝達された複数のフィルタを適用することによって再構成された画像が生成された後、復号化器は、再構成された画像を出力動画９２８として出力し得る。再構成された画像が参照画像として用いられる場合、９２４において、これらは将来のＣＵ１０２のインター予測のために参照バッファ９３０に格納され得る。
【００７８】
図１０は、ＪＶＥＴ復号化器におけるＣＵコーディング１０００の方法の実施形態を示す。図１０に示される実施形態では、ステップ１００２において、符号化ビットストリーム９０２を受信し、ステップ１００４において、符号化ビットストリーム９０２に関連するＣＡＢＡＣコンテキストモデルを決定し、次いで、ステップ１００６において、決定されたＣＡＢＡＣコンテキストモデルを使用して符号化ビットストリーム９０２を復号化し得る。
【００７９】
ステップ１００８では、符号化ビットストリーム９０２に関連付けられた複数の量子化変換係数９０６を決定し、ステップ１０１０では、複数の量子化変換係数９０６から逆量子化変換係数９１０を決定し得る。
【００８０】
ステップ１０１２において、符号化中にＭＤＮＳＳＴ演算が実行されたかどうか、および／またはビットストリーム９０２はＭＤＮＳＴ動作がビットストリーム９０２に適用されたという指示を含むかどうかを判定し得る。符号化プロセス中にＭＤＮＳＳＴ演算が実行されたか、またはビットストリーム９０２はＭＤＮＳＳＴ演算がビットストリーム９０２に適用されたという指示を含むと判定された場合、逆ＭＤＮＳＳＴ演算１０１４は、逆変換演算９１２が実行される前にステップ１０１６においてビットストリーム９０２について実行され得る。あるいは、ステップ１０１４において逆ＭＤＮＳＳＴ演算の適用がない場合、ステップ１０１６において、ビットストリーム９０２に対して逆変換演算９１２が実行され得る。ステップ１０１６の逆変換動作９１２は、再構成された残差ＣＵ９１４を決定および／または構成し得る。
【００８１】
ステップ１０１８において、ステップ１０１６からの再構成された残差ＣＵ９１４は、予測ＣＵ９１８と組み合わされ得る。予測ＣＵ９１８は、ステップ１０２０で決定されたイントラ予測ＣＵ９２２およびステップ１０２２で決定されたインター予測ユニット９２４のうちの１つであり得る。
【００８２】
ステップ１０２４では、任意の１つまたは複数のフィルタ９２０は、再構成されたＣＵ９１４に適用し、ステップ１０２６において出力され得る。いくつかの実施形態では、複数のフィルタ９２０は、ステップ１０２４で適用されなくてもよい。
【００８３】
いくつかの実施形態では、ステップ１０２８において、再構成されたＣＵ９１８は、参照バッファ９３０に格納され得る。
図１１は、ＪＶＥＴ符号化器におけるＣＵコーディングの簡略化されたブロック図１１００を示す。ステップ１１０２において、ＪＶＥＴコーディングツリーユニットは、ＱＴＢＴ（quadtree plus binary tree）構造のルートノードとして示され得る。いくつかの実施形態では、ＱＴＢＴは、ルートノードから分岐する四分木および／または四分木の１つ以上のリーフノードから分岐する二分木を有し得る。ステップ１１０２からの表現（representation）は、ステップ１１０４、１１０６または１１０８に進むことができる。
【００８４】
ステップ１１０４において、非対称２分割を使用して、表現された四分木ノードをサイズが等しくない２つのブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表現する複数のリーフノードとして、四分木ノードから分岐する二分木で表現され得る。いくつかの実施形態では、四分木ノードからリーフノードとして分岐する二分木は、さらなる分割が許可されない最終コーディングユニットを示す。いくつかの実施形態において、非対称分割は、コーディングユニットを不均等なサイズの複数のブロックに分割し、第１のブロックは四分木ノードの２５％を表し、第２のブロックは四分木ノードの７５％を表す。
【００８５】
ステップ１１０６では、四分木分割を使用して、表現された四分木ノートを等しいサイズの４つの正方形ブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表す四分木ノードとして表されるか、または、四分木分割、対称二分木分割、または非対称二分木分割によって再度分割される複数の子ノードとして表され得る。
【００８６】
ステップ１１０８では、四分木分割を使用して、表現された四分木ノートを等しいサイズの２つのブロックに分割し得る。いくつかの実施形態では、分割された複数のブロックは、複数の最終コーディングユニットを表す四分木ノードとして表されるか、または、四分木分割、対称二分木分割、または非対称二分木分割によって再度分割される複数の子ノードとして表され得る。
【００８７】
ステップ１１１０では、ステップ１１０６またはステップ１１０８からの複数の子ノードは、符号化されるように構成された複数の子ノードとして表され得る。いくつかの実施形態では、複数の子ノードは、ＪＶＥＴで二分木の複数のリーフノートによって表され得る。
【００８８】
ステップ１１１２において、ステップ１１０４または１１１０からの複数のコーディングユニットは、ＪＶＥＴを使用して符号化され得る。
図１２は、ＪＶＥＴ復号化器におけるＣＵ復号化の簡略化されたブロック図１２００を示す。図１２に示す実施形態では、ステップ１２０２において、ＱＴＢＴ構造に従ってコーディングツリーユニットがどのように複数のコーディングユニットに分割されたかを示すビットストリームを受信し得る。ビットストリームは、四分木分割、対称２分割、または非対称２分割の少なくとも１つで四分木ノードがどのように分割されるかを示すことができる。
【００８９】
ステップ１２０４において、ＱＴＢＴ構造の複数のリーフノードによって表される複数のコーディングユニットが識別され得る。いくつかの実施形態では、複数のコーディングユニットは、非対称２分割を使用してノードが四分木リーフノードから分割されたかどうかを示すことができる。いくつかの実施形態では、コーディングユニットは、ノードが復号化される最終コーディングユニットを表すことを示すことができる。
【００９０】
ステップ１２０６において、識別された１つまたは複数のコーディングユニットは、ＪＶＥＴを使用して復号化され得る。
図１３は、イントラモード予測のためのＪＶＥＴコーディングの代替的な簡略化されたブロック図１３００を示す。図１３に示す実施形態では、ステップ１３０２において、ＭＰＭのセットがメモリ内で特定されてインスタンス化され（instantiated）、ステップ１３０４において、１６個の選択されたモードのセットがメモリ内で特定されてインスタンス化され、ステップ１３０４において、６７個のモードのバランス（balance）がメモリ内で定義され且つインスタンス化され得る。いくつかの実施形態では、ＭＰＭのセットは、６つのＭＰＭの標準セットから削減され得る。いくつかの実施形態では、ＭＰＭのセットは、５つの固有モード（unique mode）を含み、選択されたモードは、１６個の固有モードを含み、非選択のモードのセットは、残りの４６個の非選択の固有モードを含み得る。しかしながら、代替実施形態では、ＭＰＭのセットは、より少ない固有のモードを含み、選択されたモードは、１６個の固有のモードで固定されたままであり、非選択の固有のモードのセットサイズは、合計６７個のモードに適応するように適切に調節され得る。非限定的な例として、ＭＰＭのセットが６つのＭＰＭの代わりに５つの固有のモードを含むいくつかの実施形態では、truncated unary二値化（binarization）が使用され、５つのＭＰＭのための新しい二値化が利用される場合には、ＭＰＭモードに割り当てられるビンの数は、５つのビンに等しいか、またはそれ未満であり得る。
【００９１】
したがって、いくつかの実施形態では、６２個の残りのイントラモードから選択された１６個のモードは、これら６２個のイントラモードを均等にサブサンプリングすることによって生成され、それぞれが４ビットの固定長コードでコード化される。非限定的な例として、残りの６２個のモードが｛０、１、２、…、６１｝としてインデックス付けされると仮定すると、１６個の選択されたモード＝｛０、４、８、１２、１６、２０、２４、２８、３２、３６、４０、４４、４８、５２、５６、６０｝である。残りの４６個の非選択のモード＝｛１、２、３、５、６、７、９、１０…５９、６１｝であり、このような４６個の非選択のモードは、truncatedバイナリコード（binary code）でコード化され得る。
【００９２】
図１４は、図１３によるイントラモード予測のための代替的なＪＶＥＴコーディングの表１４００を示す。図１４に示す実施形態では、複数のイントラ予測モード１４０２は、５つのＭＰＭ、１６個の選択モード、および４６個の非選択モードを含むように示されており、ＭＰＭのための複数のビンストリング（bin string）１４０４は、truncated unary二値化を使用して符号化され、１６個の選択モードは、固定長コードの４ビットを使用してコード化され、４６個の非選択モードは、truncatedバイナリコーディング（binary coding）を使用してコード化され得る。
【００９３】
図１３の代替的な実施形態では、６個のＭＰＭを利用することができるが、ＭＰＭリストの最初の５つのＭＰＭのみが、図１４に示すように二値化され（binarized）、現在のＪＶＥＴに記述されている現在のコンテキストに基づく方法でコード化される。ＭＰＭリストの第６のＭＰＭは、１６個の選択モードのうちの１つと見なされ、他の１５個の選択モードとともに４ビットの固定長コードでコード化される。
【００９４】
非限定的な例として、残りの６１個のモードが｛０、１、２、…、６０｝としてインデックス付けされる場合、１５個の選択モードは、残りの６１個のイントラモードを次のように均等にサブサンプリングすることによって取得され得る：１５個の選択されたモードのセットは、｛０、５、１０、１４、１８、２２、２６、３０、３４、３８、４２、４６、５０、５５、６０｝とすることができ、ここで、１５個の選択されたモードに加えて第６のＭＰＭは、｛第６のＭＰＭ、０、５、１０、１４、１８、２２、２６、３０、３４、３８、４２、４６、５０、５５、６０｝のセットのように固定長コードの４ビットでコード化され、４６個の非選択モードのバランスは、非選択モードのセット＝｛１、２、３、４、６、７、８、９、１１、１２…４９、５１、５２、５３、５４、５６、５７、５８、５９｝のようなセットとして示され、truncatedバイナリコードでコード化される。
【００９５】
図１３の更なる代替的な実施形態では、ＭＰＭリストの最初の５つのＭＰＭのみが、図１４に示すように二値化され、現在のＪＶＥＴ規格に記述されている現在のコンテキストに基づく方法でコード化される。そのような実施形態では、ＭＰＭリストの第６のＭＰＭは、１６個の選択モードのうちの１つと見なされ、他の１５個の選択モードとともに４ビットの固定長コードでコード化される。したがって、他の１５個の選択されたモードの選択は、任意の既知の便利なおよび／または所望の選択プロセスを使用して確立され得る。非限定的な例として、それらは、ＭＰＭモード関して、または（コンテンツベースの）統計的によく知られたモードに関して、または訓練されたまたは歴史的によく知られたモードに関して、または他の方法またはプロセスを使用して選択され得る。
【００９６】
この場合も先と同様に、５つのＭＰＭの選択は、単なる非限定的な例であり、代替の実施形態では、ＭＰＭのセットは、４つまたは３つのＭＰＭにさらに削減されるか、または６つを超えるまで拡大され得る。１６個の選択されたモードが依然として存在し、６７個（または他の既知の、便利な、および／または所望の総数）のイントラコーディングモードのバランスは、非選択のイントラコーディングモードのセットに含まれる。すなわち、イントラコーディングモードの総数が６７個よりも多いかまたは少ない実施形態が考えられ、その実施形態では、ＭＰＭのセットが任意の既知の便利なまたは所望の数のＭＰＭを含み、選択されたモードの量が任意の既知の便利なおよび／または所望の量であり得る。
【００９７】
複数の実施形態を実施するのに必要な命令のシーケンスの実行は、図１５に示されるようにコンピュータシステム１５００によって実行され得る。一実施形態では、命令のシーケンスの実行は、単一のコンピュータシステム１５００によって実行される。他の実施形態によれば、通信リンク１５１５によって接続された複数のコンピュータシステム１５００は、互いに協調して命令のシーケンスを実行し得る。以下では、１つのコンピュータシステム１５００のみの説明を提示するが、複数の実施形態を実施するために任意の数のコンピュータシステム１５００を使用できることを理解されたい。
【００９８】
次に、一実施形態によるコンピュータシステム１５００を、コンピュータシステム１５００の複数の機能構成要素のブロック図である図１５を参照して説明する。本明細書で使用されるコンピュータシステム１５００という用語は、１つまたは複数のプログラムを格納し、独立して実行できる任意のコンピューティングデバイスを記述するために広く使用される。
【００９９】
各コンピュータシステム１５００は、バス１５０６に接続された通信インタフェース１５１４を含み得る。通信インタフェース１５１４は、複数のコンピュータシステム１５００間の双方向通信を提供する。各コンピュータシステム１５００の通信インタフェース１５１４は、様々なタイプの信号情報、例えば、命令、メッセージ、およびデータを表すデータストリームを含む電気信号、電磁信号、または光信号を送受信する。通信リンク１５１５は、１つのコンピュータシステム１５００を別のコンピュータシステム１５００とリンクする。例えば、通信リンク１５１５はＬＡＮであり、その場合、通信インタフェース１５１４はＬＡＮカードであり、または通信リンク１５１５はＰＳＴＮであり、その場合、通信インタフェース１５１４は統合サービスデジタルネットワーク（integrated services digital network : ISDN）カードまたはモデムであり、または通信リンク１５１５はインターネットであり、その場合、通信インタフェース１５１４はダイヤルアップ、ケーブルまたは無線モデムであり得る。
【０１００】
コンピュータシステム１５００は、その対応する通信リンク１５１５および通信インタフェース１５１４を介して、プログラム、すなわちアプリケーション、コードを含むメッセージ、データ、および命令を送受信し得る。受信したプログラムコードは、受信した各プロセッサ１５０７によって実行され、および／または後で実行するために記憶装置１５１０または他の関連する不揮発性媒体に格納される。
【０１０１】
一実施形態では、コンピュータシステム１５００は、データストレージシステム１５３１、例えば、コンピュータシステム１５００によって容易にアクセス可能なデータベース１５３２を含むデータストレージシステム１５３１と連動して動作する。コンピュータシステム１５００は、データインタフェース１５３３を介してデータストレージシステム１５３１と通信する。バス１５０６に接続されたデータインタフェース１５３３は、様々なタイプの信号情報、例えば、命令、メッセージ、およびデータを表すデータストリームを含む電気信号、電磁信号、または光信号を送受信する。複数の実施形態において、データインタフェース１５３３の機能は、通信インタフェース１５１４によって実行され得る。
【０１０２】
コンピュータシステム１５００は、命令、メッセージおよびデータ、集合的に情報を通信するためのバス１５０６または他の通信メカニズムと、情報を処理するためにバス１５０６に接続された１つまたは複数のプロセッサ１５０７と、を含む。コンピュータシステム１５００は、１つまたは複数のプロセッサ１５０７によって実行される動的データおよび命令を格納するためにバス１５０６に接続されたランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ１５０８も含む。メインメモリ１５０８はまた、１つまたは複数のプロセッサ１５０７による命令の実行中に一時的なデータ、すなわち変数、または他の中間情報を格納するために使用され得る。
【０１０３】
コンピュータシステム１５００は、１つまたは複数のプロセッサ１５０７のための静的データおよび命令を格納するためにバス１５０６に接続されたリードオンリーメモリ（ＲＯＭ）１５０９または他の静的記憶装置をさらに含み得る。また磁気ディスクまたは光ディスクなどの記憶装置１５１０が提供され、１つまたは複数のプロセッサ１５０７のためのデータおよび命令を格納するためにバス１５０６に接続され得る。
【０１０４】
コンピュータシステム１５００は、ユーザに情報を表示するために、バス１５０６を介して、陰極線管（cathode ray tube : CRT）または液晶ディスプレイ（liquid-crystal display : LCD）モニタなどのディスプレイ装置１５１１に接続されることができるが、これらに限定されない。入力デバイス１５１２、例えば英数字及び他のキーは、情報及びコマンド選択をプロセッサ１５０７に通信するためにバス１５０６に接続される。
【０１０５】
一実施形態によれば、個々のコンピュータシステム１５００は、メインメモリ１５０８に含まれる１つ以上の命令の１つ以上のシーケンスを実行するこれらの対応する１つまたは複数のプロセッサ１５０７によって特定の演算を実行する。そのような命令は、ＲＯＭ１５０９または記憶装置１５１０などの別のコンピュータ使用可能媒体からメインメモリ１５０８に読み込まれ得る。メインメモリ１５０８に含まれる命令のシーケンスの実行によって、１つまたは複数のプロセッサ１５０７は、本明細書において説明されるプロセスを実行する。代替的な実施形態では、ハードワイヤード回路をソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用することができる。したがって、複数の実施形態は、ハードウェア回路および／またはソフトウェアの特定の組み合わせに限定されない。
【０１０６】
本明細書で使用される「コンピュータ使用可能媒体」という用語は、情報を提供するか、または１つまたは複数のプロセッサ１５０７によって使用可能な任意の媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに限定されない多くの形態を有することができる。不揮発性媒体、つまり電力が無くても情報を保持できる媒体は、ＲＯＭ１５０９、ＣＤ ＲＯＭ、磁気テープ、および磁気ディスクを含む。揮発性媒体、つまり電力が無いと情報を保持できない媒体は、メインメモリ１５０８を含む。伝送媒体は、バス１５０６を構成するワイヤーを含む同軸ケーブル、銅線、光ファイバを含む。伝送媒体はまた、搬送波の形態を有することができ、すなわち、情報信号を送信するために周波数、振幅または位相において変調される電磁波であり得る。さらに伝送媒体は、電波や赤外線データ通信中に生成されるものなど、音波または光波の形態を有することができる。
【０１０７】
前述した明細書では、複数の実施形態は、その特定の構成要素を参照して説明された。しかしながら、実施形態のより広い趣旨および範囲から逸脱することなく、様々な変更および変更を行うことができることは明らかである。例えば、本明細書に記載されるプロセスフローダイアグラムに示される複数のプロセスアクションの特定の順序付けおよび組合せは単なる例示であり、異なるまたは追加のプロセスアクションを使用するか、または複数のプロセスアクションの異なる組合せまたは順序付けを使用して、実施形態を実施することができることを理解されたい。従って、本明細書および図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。
【０１０８】
また、本発明は様々なコンピュータシステムで実施できることに留意されたい。本明細書において説明される様々な技法は、ハードウェアまたはソフトウェア、または両方の組み合わせで具体化され得る。好ましくは、これらの技法は、各々がプロセッサと、（揮発性および不揮発性メモリおよび／またはストレージ素子を含む）プロセッサによって読み取り可能な記憶媒体と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、を含む複数のコンピュータ上で実行されるプログラム可能なコンピュータプログラムにおいて具体化される。プログラムコードは、入力デバイスを使用して入力されたデータに適用され、上記した機能を実行し、出力情報を生成する。出力情報は、１つ以上の出力デバイスに適用される。各プログラムは、コンピュータシステムと通信するために、概略的な手続き型またはオブジェクト指向プログラミング言語で実装されることが好ましい。ただし、必要に応じて、プログラムは、アセンブリ言語または機械語で具体化され得る。いずれの場合でも、言語は、コンパイルされた言語またはインタープリター言語であり得る。このような各コンピュータプログラムは、好ましくは、記憶媒体または装置がコンピュータによって読み取られて上述の手順を実行するときに、コンピュータを構成および動作させるための汎用または特殊目的のプログラム可能なコンピュータによって読み取り可能な記憶媒体または装置（例えば、ＲＯＭまたは磁気ディスク）に記憶される。また、システムは、コンピュータプログラムを有するように構成されたコンピュータ可読記憶媒体として具体化されるように検討され、そのように構成された記憶媒体は、コンピュータを特定の所定の方法で動作させる。さらに、例示的なコンピューティングアプリケーションのストレージ要素は、様々な組み合わせおよび構成でデータを格納することができるリレーショナルまたはシーケンシャル（フラットファイル）タイプのコンピューティングデータベースとすることができる。
【０１０９】
図１６は、本明細書に記載されたシステムおよびデバイスの特徴を組み込む発信源装置１６１２および宛先装置１６１０の概略図である。図１６に示すように、例示的な動画コーディングシステム１６１０は、発信源装置１６１２と、宛先装置１６１６とを含み、この例では、発信源装置１６１２が、符号化された動画データを生成する。したがって、発信源装置１６１２は、動画符号化装置と呼称され得る。宛先装置１６１６は、発信源装置１６１２によって生成された符号化された動画データを復号化し得る。したがって、宛先装置１６１６は、動画復号装置と呼称され得る。発信源装置１６１２および宛先装置１６１６は、動画コーディング装置の例であり得る。
【０１１０】
宛先装置１６１６は、チャネル１６１６を介して発信源装置１６１２から符号化された動画データを受信し得る。チャネル１６１６は、符号化された動画データを発信源装置１６１２から宛先装置１６１６に移動させることができるタイプの媒体またはデバイスを備えてもよい。一例では、チャネル１６１６は、発信源装置１６１２が符号化された動画データを宛先装置１６１６にリアルタイムで直接的に送信することを可能にする通信媒体を備えてもよい。
【０１１１】
この例では、発信源装置１６１２は、無線通信プロトコルなどの通信規格に従って符号化された動画データを変調し、変調された動画データを宛先装置１６１６に送信し得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理的伝送線などの無線または有線の通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、広域ネットワーク、またはインターネットなどのグローバルネットワークなどのパケットベースのネットワークの一部を形成してもよい。通信媒体は、ルータ、スイッチ、基地局、または発信源装置１６１２から宛先装置１６１６への通信を可能にする他の機器を含み得る。別の例では、チャネル１６１６は、発信源装置１６１２によって生成された符号化動画データを格納する記憶媒体に対応し得る。
【０１１２】
図１６の例では、発信源装置１６１２は、動画ソース（video source）１６１８、動画符号化器１６２０、および出力インタフェース１６２２を含む。場合によっては、出力インタフェース１６２８は、変調器／復調器（モデム）および／または送信機を含み得る。発信源装置１６１２において、動画ソース１６１８は、例えば動画カメラなどの動画キャプチャデバイス、前にキャプチャされた動画データを含む動画アーカイブ、動画コンテンツプロバイダから動画データを受信するための動画フィードインタフェース、および／または動画データを生成するためのコンピュータグラフィックシステム、またはそのようなソースの組み合わせなどのソースを含んでもよい。
【０１１３】
動画符号化器１６２０は、キャプチャされた、事前にキャプチャされた、またはコンピュータによって生成された動画データを符号化してもよい。入力画像は、動画符号化器１６２０によって受信され、入力フレームメモリ１６２１に格納され得る。汎用プロセッサ１６２３は、そこから情報をロードし、符号化を実行し得る。汎用プロセッサを駆動するためのプログラムは、図１６に示される例示的なメモリモジュールのような記憶装置からロードされ得る。汎用プロセッサは、処理メモリ１６２２を使用して符号化を実行し、汎用プロセッサによる符号化情報の出力は、出力バッファ１６２６等のバッファに格納され得る。
【０１１４】
動画符号化器１６２０は、少なくとも１つのベース層及び少なくとも１つのエンハンスメント層を規定するスケーラブル動画コーディング方式（scalable video coding scheme）で動画データをコード化（例えば、符号化）するように構成される再サンプリングモジュール（resampling module）１６２５を含み得る。再サンプリングモジュール１６２５は、符号化プロセスの一部として少なくともいくつかの動画データを再サンプリングしてもよく、再サンプリングは、再サンプリングフィルタを使用して適応的に実行されてもよい。
【０１１５】
符号化された動画データ、例えば、コード化されたビットストリームは、発信源装置１６１２の出力インタフェース１６２８を介して宛先装置１６１６に直接的に送信され得る。図１６の例では、宛先装置１６１６は、入力インタフェース１６３８、動画復号化器１６３０、およびディスプレイ装置１６３２を含む。場合によっては、入力インタフェース１６２８は、受信機および／またはモデムを含み得る。宛先装置１６１６の入力インタフェース１６３８は、チャネル１６１６を介して符号化された動画データを受信する。符号化された動画データは、動画データを表す動画符号化器１６２０によって生成されたさまざまなシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体で送信されるか、記憶媒体に格納されるか、またはファイルサーバに格納される符号化された動画データに含まれてもよい。
【０１１６】
符号化された動画データはまた、復号化および／または再生のために宛先装置１６１６による後のアクセスのために、記憶媒体またはファイルサーバに格納され得る。例えば、コード化されたビットストリームは、入力バッファ１６３１に一時的に格納され、その後、汎用プロセッサ１６３３にロードされてもよい。汎用プロセッサを駆動するためのプログラムは、記憶装置またはメモリからロードされてもよい。汎用プロセッサは、プロセスメモリ１６３２を使用して復号化を実行してもよい。動画復号化器１６３０はまた、動画符号化器１６２０で使用される再サンプリングモジュール１６２５と同様の再サンプリングモジュール１６３５を含み得る。
【０１１７】
図１６は、再サンプリングモジュール１６３５を汎用プロセッサ１６３３とは別に示しているが、再サンプリング機能は、汎用プロセッサによって実行されるプログラムによって実行され、動画符号化器における処理は、１つ以上のプロセッサを使用して達成されることが当業者には理解されよう。復号化された１つまたは複数の画像は、出力フレームバッファ１６３６に格納され、その後、入力インタフェース１６３８に送信されてもよい。
【０１１８】
ディスプレイ装置１６３８は、宛先装置１６１６と統合されるか、または外部にあってもよい。いくつかの例では、宛先装置１６１６は、統合ディスプレイ装置を含むか、または外部ディスプレイ装置とインタフェースするように構成されてもよい。他の例では、宛先装置１６１６は、ディスプレイ装置であってもよい。概して、ディスプレイ装置１６３８は、復号化された動画データをユーザに表示する。
【０１１９】
動画符号化器１６２０および動画復号化器１６３０は、動画圧縮規格に従って動作し得る。ＩＴＵ−Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は、現在の高効率動画コーディングＨＥＶＣ規格（スクリーンコンテンツコーディングおよび高い動的範囲のコーディングのためのその現在の拡張および近い将来の拡張を含む）のものを大幅に超える圧縮能力を有する、将来的な動画コーディング技法の標準化のための潜在的必要性を現在研究している。これらのグループは、この分野におけるそれらの専門家によって提案された圧縮技術設計を評価するために、ＪＶＥＴ（Joint Video Exploration Team）として知られる共同コラボレーションのこの調査活動で協働している。ＪＶＥＴ開発の最近の記録は、J.Chen、E.Alshina、G.Sullivan、J.Ohm、J.Boyce著「Algorithm Description of Joint Exploration Test Model 5 (JEM 5)」、JVET-E1001-V2に記載されている。
【０１２０】
追加または代替的に、動画符号化器１６２０および動画復号化器１６３０は、開示されたＪＶＥＴの特徴と共に機能する他の独自規格または業界規格に従って動作し得る。つまり、他の規格には、ＩＴＵ−Ｔ Ｈ．２６４規格、代替的にはＭＰＥＧ−４、Ｐａｒｔ １０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、またはそのような規格の拡張などの他の規格がある。したがって、本開示の技法は、ＪＶＥＴのために新たに開発されたが、特定のコーディング規格または技法に限定されない。動画圧縮規格および技法の他の例は、ＭＰＥＧ−２、ＩＴＵ−Ｔ Ｈ．２６３、および独自のまたはオープンソースの圧縮フォーマットおよび関連フォーマットを含む。
【０１２１】
動画符号化器１６２０および動画復号化器１６３０は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで具体化され得る。例えば、動画符号化器１６２０および復号化器１６３０は、１つ以上のプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、離散ロジック、またはそれらの任意の組み合わせを使用することができる。
【０１２２】
動画符号化器１６２０および復号化器１６３０が部分的にソフトウェアで具体化される場合、装置は、適切な、一時的でないコンピュータ可読記憶媒体にソフトウェアの複数の命令を格納し、本開示の技法を実行するために、１つ以上のプロセッサを使用してハードウェアで複数の命令を実行し得る。動画符号化器１６２０および動画復号化器１６３０の各々は、１つまたは複数の符号化器または復号化器に含まれることがあり、そのいずれもが、それぞれの装置内の複合符号化器／復号化器（コーデック）の一部として統合されることがある。
【０１２３】
本明細書に記載する主題の態様は、上述した汎用プロセッサ１６２３および１６３３のようなコンピュータによって実行されるプログラムモジュールのようなコンピュータ実行可能な複数の命令の全体的な文脈において説明され得る。概して、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本明細書に記載する主題の態様は、通信ネットワークを介してリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境においても実施され得る。分散コンピューティング環境では、複数のプログラムモジュールは、メモリ記憶装置を含むローカルとリモートの両方のコンピュータ記憶媒体に配置され得る。
【０１２４】
メモリの複数の例は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、またはその両方を含む。メモリは、上記した技法を実行するためのソースコードまたはバイナリコードなどの複数の命令を格納し得る。メモリはまた、プロセッサ１６２３および１６３３などのプロセッサによって実行される複数の命令の実行中に変数または他の中間情報を格納するために使用されてもよい。
【０１２５】
記憶装置は、上記した技法を実行するためのソースコードまたはバイナリコードなどの複数の命令を格納し得る。記憶装置は、コンピュータプロセッサによって使用および操作されるデータをさらに格納してもよい。例えば、動画符号化器１６２０または動画復号化器１６３０内の記憶装置は、コンピュータシステム１６２３または１６３３によってアクセスされるデータベースであってもよい。
【０１２６】
記憶装置の他の複数の例は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードドライブ、磁気ディスク、光ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、フラッシュメモリ、ＵＳＢメモリカード、またはコンピュータが読み取ることができる任意の他の媒体を含む。
【０１２７】
メモリまたは記憶装置は、動画符号化器および／または復号化器によって、またはそれらに関連して使用するための非一時的なコンピュータ可読記憶媒体の一例であり得る。非一時的なコンピュータ可読記憶媒体は、特定の実施形態によって説明された複数の機能を実行するように構成されるコンピュータシステムを制御するための複数の命令を含む。複数の命令は、１つ以上のコンピュータプロセッサによって実行されると、特定の実施形態で説明されているものを実行するように構成され得る。
【０１２８】
また、いくつかの実施形態は、フロー図またはブロック図として示されるプロセスとして説明されていることに留意されたい。それぞれが複数の演算を順次処理として説明したが、複数の演算の多くは並列または同時に実行することができる。さらに、複数の演算の順序を並べ替えることができる。プロセスは、図面に含まれていない追加のステップを有してもよい。
【０１２９】
特定の実施形態は、命令実行システム、装置、システムまたはマシンによる使用またはそれと関連しての使用のための非一時的なコンピュータ可読記憶媒体に実装され得る。コンピュータ可読記憶媒体は、特定の実施形態によって説明したように、方法を実行するためにコンピュータシステムを制御するための命令を含む。コンピュータシステムは、１つ以上のコンピューティングデバイスを含み得る。１つ以上のコンピュータプロセッサによって実行されると、命令は、特定の実施形態に記載されているものを実行するように構成され得る。
【０１３０】
本明細書の説明においておよび以下の特許請求の範囲を通して使用される際に、文脈が別様に明確に指示しない限り、「１つの（ａ、ａｎ）」および「該、前記（ｔｈｅ）」は複数への言及を含む。また、本明細書の説明においておよび以下の特許請求の範囲を通して使用される際に、文脈が別様に明確に指示しない限り、「において、における、内の、内に、（ｉｎ）」の意味は、「において、における、内の、内に、（ｉｎ）」および「の上の、の上で（ｏｎ）」を含む。
【０１３１】
本発明の例示的な実施形態は、上記した構造的特徴および／または方法論動作に特有の詳細および言語で説明されてきたが、当業者は、本発明の新規な教示および利点から実質的に逸脱することなく、例示的な実施形態において多くの追加の変更が可能であることを容易に理解するであろう。さらに、添付の特許請求の範囲に定義される主題は、必ずしも上記した特定の特徴または動作に限定されないことを理解されたい。従って、これら及び全てのそのような変更は、添付の特許請求の範囲に従った広さ及び範囲で解釈される本発明の範囲内に含まれることが意図されている。
【図１ａ】
2020529157.tif 000003
【図１ｂ】
2020529157.tif 000004
【図１ｃ】
2020529157.tif 000005
【図２】
2020529157.tif 000006
【図３】
2020529157.tif 000007
【図４】
2020529157.tif 000008
【図５】
2020529157.tif 000009
【図６】
2020529157.tif 000010
【図７】
2020529157.tif 000011
【図８】
2020529157.tif 000012
【図９】
2020529157.tif 000013
【図１０】
2020529157.tif 000014
【図１１】
2020529157.tif 000015
【図１２】
2020529157.tif 000016
【図１３】
2020529157.tif 000017
【図１４】
2020529157.tif 000018
【図１５】
2020529157.tif 000019
【図１６】
2020529157.tif 000020
【国際調査報告】
2020529157.tif 000021
2020529157.tif 000022
2020529157.tif 000023