(57)【要約】  イメージのブロックを復号する復号方法であって、分割モードのセット内で前記ブロックの分割モードを判定することと、前記分割モードに応答して、前記ブロックを少なくとも２つのサブブロックに分割することと、少なくとも２つのサブブロックのそれぞれを復号することとを含み、分割モードの前記セットは、前記ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、復号方法を開示する。【選択図】図１４
2019537299.tif 000002
【特許請求の範囲】
【請求項１】
イメージのブロックを復号する復号方法であって、
−分割モードのセット内で前記ブロックの分割モードを判定することであって、分割モードの前記セットは、前記ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、判定することと、
−前記分割モードに応答して、前記ブロックを少なくとも２つのサブブロックに分割することと、
−前記少なくとも２つのサブブロックのそれぞれを復号することと
を含み、前記分割モードの判定は、
−前記ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を復号することと、
−前記ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を復号することと、
−前記第２の構文要素が、前記ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）を復号することと
を含む、復号方法。
【請求項２】
イメージのブロックを復号するように構成された復号デバイスであって、
−分割モードのセット内で前記ブロックの分割モードを判定する手段であって、分割モードの前記セットは、前記ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、判定する手段と、
−前記分割モードに応答して、前記ブロックを少なくとも２つのサブブロックに分割する手段と、
−前記少なくとも２つのサブブロックのそれぞれを復号する手段と
を含み、前記分割モードを判定する前記手段は、
−前記ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を復号し、
−前記ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を復号し、
−前記第２の構文要素が、前記ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）を復号する
ように構成される、復号デバイス。
【請求項３】
前記第２の構文要素の復号は、
−前記第２の構文要素の復号に関するコンテキストを判定することであって、前記コンテキストは、現在のブロックのサイズに対する相対的な隣接ブロックのサイズの関数であり、前記サイズは、幅または高さである、判定することと、
−前記判定されたコンテキストに応答して、前記第２の構文要素のコンテキストベースの算術復号を行うことと
を含む、請求項１に記載の方法または請求項２に記載のデバイス。
【請求項４】
前記コンテキストは、前記ブロックのサイズの１／４未満のサイズを有する隣接ブロック内のサブブロックの個数の関数であり、前記サイズは、幅または高さである、請求項３に記載の方法または請求項３に記載のデバイス。
【請求項５】
前記ブロックが水平に分割される場合に、前記第２の構文要素の復号に関する前記コンテキストの判定は、
−前記ブロックの高さの１／４未満の高さを有する前記ブロックの左に配置された隣接ブロック内のサブブロックの個数を判定することと、
−前記個数が０と等しい場合には第１のコンテキストを、そうでない場合には第２のコンテキストを入手することと
を含む、請求項４に記載の方法または請求項４に記載のデバイス。
【請求項６】
前記ブロックが垂直に分割される場合に、前記第２の構文要素の復号に関する前記コンテキストの判定は、
−前記ブロックの幅の１／４未満の幅を有する前記ブロックの上に配置された隣接ブロック内のサブブロックの個数を判定することと、
−前記個数が０と等しい場合には第１のコンテキストを、そうでない場合には第２のコンテキストを入手することと
を含む、請求項４から５のいずれか１項に記載の方法または請求項４から５のいずれか１項に記載のデバイス。
【請求項７】
前記コンテキストは、前記ブロックのサイズの１／２を超えるサイズを有する隣接ブロックの存在の関数であり、前記サイズは、幅または高さである、請求項３に記載の方法または請求項３に記載のデバイス。
【請求項８】
前記分割モード構文要素の復号は、
−前記ブロックの隣接ブロック内のフロンティアが、前記ブロックを非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素の復号に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの隣接ブロック内のフロンティアが、前記ブロックを非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベース算術復号を行うことと
を含む、請求項１もしくは３から７のいずれか１項に記載の方法または請求項２から７のいずれか１項に記載のデバイス。
【請求項９】
前記ブロックが水平に分割される場合に、前記分割モード構文要素の復号は、
−前記ブロックの左に配置された隣接ブロック内のフロンティアが、前記ブロックを水平に非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素の復号に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの左に配置された隣接ブロック内のフロンティアが、前記ブロックを水平に非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術復号を行うことと
を含む、請求項１もしくは３から７のいずれか１項に記載の方法または請求項２から７のいずれか１項に記載のデバイス。
【請求項１０】
前記ブロックが垂直に分割される場合に、前記分割モード構文要素の復号は、
−前記ブロックの上に配置された隣接ブロック内のフロンティアが、前記ブロックを垂直に非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素を復号するためのコンテキストを判定することであって、前記コンテキストは、前記ブロックの上に配置された隣接ブロック内のフロンティアが、前記ブロックを垂直に非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術復号を行うことと
を含む、請求項１もしくは３から７のいずれか１項に記載の方法または請求項２から７のいずれか１項に記載のデバイス。
【請求項１１】
前記分割モード構文要素の復号は、
−前記分割モード構文要素の復号に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの第２の隣接ブロックのサイズに対する相対的な前記ブロックの第１の隣接ブロックのサイズの関数であり、前記サイズは、幅または高さである、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術復号を行うことと
を含む、請求項１もしくは３から７のいずれか１項に記載の方法または請求項２から７のいずれか１項に記載のデバイス。
【請求項１２】
イメージのブロックを符号化するコーディング方法であって、
−分割モードのセット内で前記ブロックの分割モードを判定することであって、分割モードの前記セットは、前記ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、判定することと、
−前記分割モードに応答して、前記ブロックを少なくとも２つのサブブロックに分割することと、
−前記少なくとも２つのサブブロックのそれぞれを符号化することと
を含み、前記分割モードの判定は、
−前記ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を判定し、符号化することと、
−前記ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を判定し、符号化することと、
−前記第２の構文要素が、前記ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）を判定し、符号化することと
を含む、コーディング方法。
【請求項１３】
イメージのブロックを符号化するように構成されたコーディング・デバイスであって、
−分割モードのセット内で前記ブロックの分割モードを判定する手段であって、分割モードの前記セットは、前記ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、判定する手段と、
−前記分割モードに応答して、前記ブロックを少なくとも２つのサブブロックに分割する手段と、
−前記少なくとも２つのサブブロックのそれぞれを符号化する手段と
を含み、分割モードを判定する前記手段は、
−前記ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を判定し、符号化し、
−前記ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を判定し、符号化し、
−前記第２の構文要素が、前記ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）を判定し、符号化する
ように構成される、コーディング・デバイス。
【請求項１４】
前記第２の構文要素の符号化は、
−前記第２の構文要素の符号化に関するコンテキストを判定することであって、前記コンテキストは、現在のブロックのサイズに対する相対的な隣接ブロックのサイズの関数であり、前記サイズは、幅または高さである、判定することと、
−前記判定されたコンテキストに応答して、前記第２の構文要素のコンテキストベースの算術符号化を行うことと
を含む、請求項１２に記載の方法または請求項１３に記載のデバイス。
【請求項１５】
前記コンテキストは、前記ブロックのサイズの１／４未満のサイズを有する隣接ブロック内のサブブロックの個数の関数であり、前記サイズは、幅または高さである、請求項１４に記載の方法または請求項１４に記載のデバイス。
【請求項１６】
前記ブロックが水平に分割される場合に、前記第２の構文要素の符号化に関する前記コンテキストの判定は、
−前記ブロックの高さの１／４未満の高さを有する前記ブロックの左に配置された隣接ブロック内のサブブロックの個数を判定することと、
−前記個数が０と等しい場合には第１のコンテキストを、それ以外の場合には第２のコンテキストを入手することと
を含む、請求項１５に記載の方法または請求項１５に記載のデバイス。
【請求項１７】
前記ブロックが垂直に分割される場合に、前記第２の構文要素の符号化に関する前記コンテキストの判定は、
−前記ブロックの幅の１／４未満の幅を有する前記ブロックの上に配置された隣接ブロック内のサブブロックの個数を判定することと、
−前記個数が０と等しい場合には第１のコンテキストを、それ以外の場合には第２のコンテキストを入手することと
を含む、請求項１５から１６のいずれか１項に記載の方法または請求項１５から１６のいずれか１項に記載のデバイス。
【請求項１８】
前記コンテキストは、前記ブロックのサイズの１／２を超えるサイズを有する隣接ブロックの存在の関数であり、前記サイズは、幅または高さである、請求項１４に記載の方法または請求項１４に記載のデバイス。
【請求項１９】
前記分割モード構文要素の符号化は、
−前記ブロックの隣接ブロック内のフロンティアが、前記ブロックを非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素の符号化に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの隣接ブロック内のフロンティアが、前記ブロックを非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術符号化を行うことと
を含む、請求項１２もしくは１４から１８のいずれか１項に記載の方法または請求項１３から１８のいずれか１項に記載のデバイス。
【請求項２０】
前記ブロックが水平に分割される場合に、前記分割モード構文要素の符号化は、
−前記ブロックの左に配置された隣接ブロック内のフロンティアが、前記ブロックを水平に非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素の符号化に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの左に配置された隣接ブロック内のフロンティアが、前記ブロックを水平に非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術符号化を行うことと
を含む、請求項１２もしくは１４から１８のいずれか１項に記載の方法または請求項１３から１８のいずれか１項に記載のデバイス。
【請求項２１】
前記ブロックが垂直に分割される場合に、前記分割モード構文要素の符号化は、
−前記ブロックの上に配置された隣接ブロック内のフロンティアが、前記ブロックを垂直に非対称に分割することから生じるフロンティアに整列されているかどうかを判定することと、
−前記分割モード構文要素の符号化に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの上に配置された隣接ブロック内のフロンティアが、前記ブロックを垂直に非対称に分割することから生じるフロンティアに整列されているかどうかの前記判定の関数である、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術符号化を行うことと
を含む、請求項１２もしくは１４から１８のいずれか１項に記載の方法または請求項１３から１８のいずれか１項に記載のデバイス。
【請求項２２】
前記分割モード構文要素の符号化は、
−前記分割モード構文要素の符号化に関するコンテキストを判定することであって、前記コンテキストは、前記ブロックの第２の隣接ブロックのサイズに対する相対的な前記ブロックの第１の隣接ブロックのサイズの関数であり、前記サイズは、幅または高さである、判定することと、
−前記判定されたコンテキストに応答して、前記分割モード構文要素のコンテキストベースの算術符号化を行うことと
を含む、請求項１２もしくは１４から１８のいずれか１項に記載の方法または請求項１３から１８のいずれか１項に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
［0001］  以下では、ピクチャを符号化する方法およびデバイスを開示する。対応する復号方法および復号デバイスをさらに開示する。
【背景技術】
【０００２】
［0002］  高い圧縮効率を達成するために、ビデオ・コーディング方式は、通常、ビデオ・コンテンツ内の空間的冗長性および時間的冗長性を活用するために予測および変換を使用する。一般に、イントラ予測またはインター予測が、イントラフレーム相関またはインターフレーム相関を活用するのに使用され、その後、しばしば残差と示される元のイメージと予測されたイメージとの間の差が、変換され、量子化され、エントロピ・コーディングされる。ビデオを再構成するために、圧縮されたデータは、予測、変換、量子化、およびエントロピ・コーディングに対応する逆プロセスによって復号される。
【０００３】
［0003］  ＨＥＶＣコーディング（「ＩＴＵ−Ｔ  Ｈ．２６５  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  ｓｅｃｔｏｒ  ｏｆ  ＩＴＵ  （１０／２０１４），  ｓｅｒｉｅｓ  Ｈ：  ａｕｄｉｏｖｉｓｕａｌ  ａｎｄ  ｍｕｌｔｉｍｅｄｉａ  ｓｙｓｔｅｍｓ，  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ｏｆ  ａｕｄｉｏｖｉｓｕａｌ  ｓｅｒｖｉｃｅｓ  −  ｃｏｄｉｎｇ  ｏｆ  ｍｏｖｉｎｇ  ｖｉｄｅｏ，  Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｖｉｄｅｏ  ｃｏｄｉｎｇ，  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  ＩＴＵ−Ｔ  Ｈ．２６５」）では、ピクチャは、通常は６４×６４、１２８×１２８、または２５６×２５６の構成可能なサイズを有する正方形形状のコーディング・ツリー・ユニット（ＣＴＵ）に区分される。ＣＴＵは、コーディング・ユニット（ＣＵ）への四分木分割のルートである。ＣＵごとに、そのＣＵがイントラ予測またはインター予測のどちらを使用してコーディングされるのかを示す予測モードがシグナリングされる。コーディング・ユニットは、１つまたは複数の予測ユニット（ＰＵ）に区分され、変換ユニット（ＴＵ）への四分木（変換木とも称する）区分のルートを形成する。ＰＵは、正方形または長方形の形状を有することができるが、ＴＵは、正方形の形状を有する。ＰＵへのＣＵの非対称副分割は、インター予測でも可能である、すなわち、ＣＵがサイズＮ×Ｎを有する場合に、ＰＵは、図１に示されているように、サイズＮ／４×Ｎ、３Ｎ／４×Ｍ、Ｎ×Ｎ／４、Ｎ×３Ｎ／４を有することができる。各ＰＵは、なんらかの予測情報、たとえば動き情報、空間イントラ予測などを割り当てられる。
【０００４】
［0004］  Ｑｕａｄ−Ｔｒｅｅ  ｐｌｕｓ  Ｂｉｎａｒｙ−Ｔｒｅｅ（ＱＴＢＴ）コーディング・ツール（「Ａｌｇｏｒｉｔｈｍ  Ｄｅｓｃｒｉｐｔｉｏｎ  ｏｆ  Ｊｏｉｎｔ  Ｅｘｐｌｏｒａｔｉｏｎ  Ｔｅｓｔ  Ｍｏｄｅｌ  ３」、Ｄｏｃｕｍｅｎｔ  ＪＶＥＴ−Ｃ１００１＿ｖ３、Ｊｏｉｎｔ  Ｖｉｄｅｏ  Ｅｘｐｌｏｒａｔｉｏｎ  Ｔｅａｍ  ｏｆ  ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１、３ｒｄ  ｍｅｅｔｉｎｇ、２０１５年５月２６日〜６月１日、スイス国ジュネーブ）は、ＨＥＶＣ標準規格のＣＵ／ＰＵ／ＴＵ配置より柔軟なＣＴＵ表現を提供する新しいビデオ・コーディング・ツールである。Ｑｕａｄ−Ｔｒｅｅ  ｐｌｕｓ  Ｂｉｎａｒｙ−Ｔｒｅｅ（ＱＴＢＴ）コーディング・ツールは、コーディング・ユニットを四分木と二分木との両方の形で分割できるコーディング・ツリーを定義する。コーディング・ツリー・ユニットのそのようなコーディング・ツリー表現が、図２に示されており、図では、実線が四分木区分を示し、破線がＣＵの二分木区分を示す。
【０００５】
［0005］  コーディング・ユニットへのＣＴＵの分割は、符号器側で、たとえば、最小のレートひずみコストを有するＣＴＵのＱＴＢＴ表現を判定することに存するレートひずみ最適化手順を介して決定される。ＱＴＢＴ表現では、ＣＵは、正方形または長方形のいずれかの形状を有する。コーディング・ユニットのサイズは、必ず２のべきであり、通常は４から１２８までになる。図３に示されているように、ＣＴＵのＱＴＢＴ分解は、２つのステージを含み、ＣＴＵは、まず四分木の形で４つのＣＵに分割され、その後、各四分木葉は、二項の形で２つのＣＵに、または四分木の形で４つのＣＵにさらに分割され得る。図３では、実線は四分木分割を表し、破線は、四分木葉内で空間的に実施される二項分割を表す。
【０００６】
［0006］  ＱＴＢＴ表現を用いると、ＣＵは、ＰＵまたはＴＵにさらには分割されない。言い換えると、ＣＴＵの区分が決定されたならば、各ＣＵは、単一の予測ユニットおよび単一の変換ユニットと考えられる。しかし、そのようなＱＴＢＴ表現は、図４によって示されるＣＵの対称分割のみを可能にする。図４は、ＱＴＢＴによって許容される４つの分割モードを示す。モードＮＯ＿ＳＰＬＩＴは、ＣＵがさらには分割されないことを示し、モードＱＴ＿ＳＰＬＩＴは、ＣＵが四分木に従って４つの象限に分割されることを示し、モードＨＯＲは、ＣＵが等しいサイズの２つのＣＵに水平に分割されることを示し、ＶＥＲは、ＣＵが等しいサイズの２つのＣＵに垂直に分割されることを示す。
【発明の概要】
【０００７】
［0007］  イメージのブロックを復号する復号方法であって、
−分割モードのセット内でブロックの分割モードを判定することと、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することと、
−少なくとも２つのサブブロックのそれぞれを復号することと
を含み、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、復号方法。
【０００８】
［0008］  イメージのブロックを復号するように構成された復号デバイスであって、
−分割モードのセット内でブロックの分割モードを判定する手段と、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割する手段と、
−少なくとも２つのサブブロックのそれぞれを復号する手段と
を含み、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、復号デバイスを開示する。
【０００９】
［0009］  少なくともストリームにアクセスするように構成された通信インターフェースと少なくとも１つのプロセッサとを含む復号デバイスであって、少なくとも１つのプロセッサは、
−分割モードのセット内でイメージのブロックの分割モードを判定し、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割し、
−アクセスされたストリームからの少なくとも２つのサブブロックのそれぞれを復号する
ように構成され、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、復号デバイスを開示する。
【００１０】
以下の実施形態は、上で開示された復号方法および復号デバイスにあてはまる。
【００１１】
［0010］  有利なことに、分割モードの判定は、
−ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を復号することと、
−ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を復号することと、
−第２の構文要素が、ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）を復号することと
を含む。
【００１２】
［0011］  特定の特性に従って、第２の構文要素すなわちｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇのいずれかは、単一のビットから復号される。
【００１３】
［0012］  変形形態では、第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）は、復号順で現在のブロックに先行するブロックを復号する時に第２の構文要素のとる値に依存する単一のコンテキストを使用するコンテキストベースの算術コーディングによって復号される。
【００１４】
［0013］  変形形態では、第２の構文要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、現在のブロックの高さの１／４以下の高さを有する左隣接ブロック内に配置されたサブブロックの個数に依存する２つのコンテキストを使用するコンテキストベースの算術コーディングによって復号される。同一の形で、第２の構文要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、現在のブロックの幅の１／４以下の幅を有する上隣接ブロック内に配置されたサブブロックの個数に依存する２つのコンテキストを使用するコンテキストベースの算術コーディングによって復号される。
【００１５】
［0014］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数またはブロックの幅および高さの関数のいずれかとしてインデクシングされる。
【００１６】
［0015］  特定の特性によれば、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）は、単一のビットから復号される。
【００１７】
［0016］  変形形態では、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅのいずれか）は、復号順で現在のブロックに先行するブロックを復号する時に分割モード構文要素のとる値に依存する単一のコンテキストを使用するコンテキストベースの算術コーディングによって復号される。
【００１８】
［0017］  変形形態では、分割モード構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、現在のブロックの水平非対称分割の選択を介して入手される現在のブロックの水平フロンティアと空間的に一致するフロンティアの現在のブロックの左に配置されたブロック内での存在に依存する３つのコンテキストを使用するコンテキストベースの算術コーディングによって復号される。
【００１９】
［0018］  同一の形で、分割モード構文要素ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、現在のブロックの垂直非対称分割の選択を介して入手される現在のブロックの垂直フロンティアと空間的に一致するフロンティアの現在のブロックの上に配置されたブロック内での存在に依存する３つのコンテキストを使用するコンテキストベースの算術コーディングによって復号される。
【００２０】
［0019］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数またはブロックの幅および高さの関数のいずれかとしてインデクシングされる。
【００２１】
［0020］  変形形態では、分割モードの判定は、
ブロックが、復号順で次のブロックと合併されることを示す構文要素（ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵ＿ｆｌａｇ）を復号すること
を含む。
【００２２】
［0021］  特定の実施形態では、ブロックは、ルマ・サンプルのブロック、クロマ・サンプルのブロック、またはルマ・サンプルの１ブロックおよびクロマ・サンプルの２ブロックによって形成されるコーディング・ユニットのうちの１つである。
【００２３】
［0022］  特定の実施形態では、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することは、ブロックを高さｈ／４の１つのサブブロックおよび高さ３ｈ／４の１つのサブブロックに水平に分割することであって、ｈはブロックの高さである、分割することを含む。
【００２４】
［0023］  特定の実施形態では、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することは、ブロックを幅ｗ／４の１つのサブブロックおよび幅３ｗ／４の１つのサブブロックに垂直に分割することであって、ｗはブロックの幅である、分割することを含む。
【００２５】
［0024］  イメージのブロックを符号化するコーディング方法であって、
−分割モードのセット内でブロックの分割モードを判定することと、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することと、
−少なくとも２つのサブブロックのそれぞれを符号化することと
を含み、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、コーディング方法も開示される。
【００２６】
［0025］  イメージのブロックを符号化するように構成されたコーディング・デバイスであって、
−分割モードのセット内でブロックの分割モードを判定する手段と、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割する手段と、
−少なくとも２つのサブブロックのそれぞれを符号化する手段と
を含み、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、コーディング・デバイスも開示される。
【００２７】
［0026］  少なくとも、現在のブロックと命名される、イメージのブロックにアクセスするように構成された通信インターフェースと、少なくとも１つのプロセッサとを含むコーディング・デバイスが開示される。少なくとも１つのプロセッサは、
−分割モードのセット内でブロックの分割モードを判定し、
−分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割し、
−少なくとも２つのサブブロックのそれぞれを符号化する
ように構成され、分割モードのセットは、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む。
【００２８】
［0027］  以下の実施形態は、上で開示されたコーディング方法およびコーディング・デバイスにあてはまる。
【００２９】
［0028］  有利なことに、分割モードの判定は、
−ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を判定し、符号化することと、
−ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）を判定し、符号化することと、
−第２の構文要素が、ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）判定し、符号化することと
を含む。
【００３０】
［0029］  特定の特性によれば、第２の構文要素すなわちｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇのいずれかは、単一のビットを用いて符号化される。
【００３１】
［0030］  変形形態では、第２の構文要素は、符号化順で現在のブロックに先行するブロックを符号化する時に第２の構文要素のとる値に依存する単一のコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。
【００３２】
［0031］  変形形態では、第２の構文要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、現在のブロックの高さの１／４以下の高さを有する左隣接ブロック内に配置されたサブブロックの個数に依存する２つのコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。同一の形で、第２の構文要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、現在のブロックの幅の１／４以下の幅を有する上隣接ブロック内に配置されたサブブロックの個数に依存する２つのコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。
【００３３】
［0032］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数またはブロックの幅および高さの関数のいずれかとしてインデクシングされる。
【００３４】
［0033］  特定の特性によれば、分割モード構文要素（ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）は、単一のビットを用いて符号化される。
【００３５】
［0034］  変形形態では、分割モード構文要素は、符号化順で現在のブロックに先行するブロックを符号化する時に分割モード構文要素のとる値に依存する単一のコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。
【００３６】
［0035］  変形形態では、分割モード構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、現在のブロックの水平非対称分割の選択を介して入手される現在のブロックの水平フロンティアと空間的に一致するフロンティアの現在のブロックの左に配置されたブロック内での存在に依存する３つのコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。
【００３７】
［0036］  同一の形で、分割モード構文要素ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、現在のブロックの垂直非対称分割の選択を介して入手される現在のブロックの垂直フロンティアと空間的に一致するフロンティアの現在のブロックの上に配置されたブロック内での存在に依存する３つのコンテキストを使用するコンテキストベースの算術コーディングによって符号化される。
【００３８】
［0037］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数またはブロックの幅および高さの関数のいずれかとしてインデクシングされる。
【００３９】
［0038］  別の実施形態では、分割モードの判定は、
ブロックが、符号化順で次のブロックと合併されることを示す構文要素（ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵ＿ｆｌａｇ）を判定し、符号化すること
を含む。
【００４０】
［0039］  例示的な実施形態として、ブロックは、ルマ・サンプルのブロック、クロマ・サンプルのブロック、またはルマ・サンプルの１ブロックおよびクロマ・サンプルの２ブロックによって形成されるコーディング・ユニットのうちの１つである。
【００４１】
［0040］  一実施形態では、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することは、ブロックを高さｈ／４の１つのサブブロックおよび高さ３ｈ／４の１つのサブブロックに水平に分割することであって、ｈはブロックの高さである、分割することを含む。
【００４２】
［0041］  一実施形態では、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することは、ブロックを幅ｗ／４の１つのサブブロックおよび幅３ｗ／４の１つのサブブロックに垂直に分割することであって、ｗはブロックの幅である、分割することを含む。
【００４３】
［0042］  コーディングされたデータが、分割モードのセット内でブロックの分割モードを判定することと、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することと、少なくとも２つのサブブロックのそれぞれをコーディングされたデータに符号化することとによって入手され、分割モードのセットが、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、ブロックを表すコーディングされたデータを含むストリームも開示される。
【００４４】
［0043］  ストリームが、ブロックを表すコーディングされたデータを含み、コーディングされたデータが、分割モードのセット内でブロックの分割モードを判定することと、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することと、少なくとも２つのサブブロックのそれぞれをコーディングされたデータに符号化することとによって入手され、分割モードのセットが、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、その上にストリームを記憶された非一時的プロセッサ可読媒体が開示される。
【００４５】
［0044］  コーディングされたデータが、分割モードのセット内でブロックの分割モードを判定することと、分割モードに応答して、ブロックを少なくとも２つのサブブロックに分割することと、少なくとも２つのサブブロックのそれぞれをコーディングされたデータに符号化することとによって入手され、分割モードのセットが、ブロックを少なくとも２つのサブブロックに非対称に分割する少なくとも１つの分割モードを含む、ブロックを表すコーディングされたデータを送信することを含む送信方法が開示される。
【００４６】
［0045］  有利なことに、コーディングされたデータは、
−ブロックが垂直または水平のどちらに分割されるのかを指定する第１の構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）と、
−ブロックが対称または非対称のどちらで分割されるのかを指定する第２の構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）と、
−第２の構文要素が、ブロックが非対称に分割されることを指定する場合に、分割モード構文要素（ｖｅｒｔｉｃａｌ／ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）と
を含む。
【００４７】
［0046］  変形形態では、コーディングされたデータは、ブロックが、符号化順で次のブロックと合併されることを示す構文要素（ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵ＿ｆｌａｇ）を含む。
【図面の簡単な説明】
【００４８】
【図１】［0047］従来技術による予測ユニットへのコーディング・ユニットの非対称副分割を示す図である。
【図２】［0048］技術的現状によるコーディング・ユニットへのコーディング・ツリー・ユニットの分割を示す図である。
【図３】［0048］技術的現状によるコーディング・ユニットへのコーディング・ツリー・ユニットの分割を示す図である。
【図４】［0049］Ｑｕａｄ−Ｔｒｅｅ  ｐｌｕｓ  Ｂｉｎａｒｙ−Ｔｒｅｅコーディング・ツールによって定義されるコーディング・ユニットの分割モードを示す図である。
【図５】［0050］非限定的な実施形態による、ビットストリーム内でイメージ・ブロックを符号化するように構成された送信器の例示的なアーキテクチャを表す図である。
【図６】［0051］図７および／または図１１の符号化方法を実行するように適合された例示的なビデオ符号器を示す図である。
【図７】［0052］特定の非限定的な実施形態による、ビットストリーム内でイメージのブロックを符号化する方法を示す流れ図である。
【図８】［0053］本原理による非対称分割モードの例を示す図である。
【図９】［0054］本原理によるＣＵへのＣＴＵの区分の例を示す図である。
【図１０】［0055］符号化構文のグラフ表現を示す図である。
【図１１】［0056］特定の非限定的な実施形態による、現在のブロックの二項分割情報を符号化する方法を示す流れ図である。
【図１２】［0057］非限定的な実施形態による、復号されたイメージ・ブロックを入手するためにビットストリームからイメージ・ブロックを復号するように構成された受信器の例示的なアーキテクチャを表す図である。
【図１３】［0058］図１４および／または図１５の復号方法を実行するように適合された例示的なビデオ復号器を示すブロック図である。
【図１４】［0059］特定の非限定的な実施形態による、ビットストリームからイメージのブロックを復号する方法を示す流れ図である。
【図１５】［0060］特定の非限定的な実施形態による、二項分割の場合の現在のブロックの分割モードを復号する方法を示す流れ図である。
【図１６】［0061］本原理による、非対称分割モードを表す構文要素のエントロピ・コーディング・プロセスを示す図である。
【図１７】［0061］本原理による、非対称分割モードを表す構文要素のエントロピ・コーディング・プロセスを示す図である。
【図１８】［0062］符号化構文の変形形態を示す図である。
【発明を実施するための形態】
【００４９】
［0063］  図面および説明が、明瞭さのために通常の符号化デバイスおよび／または復号デバイスに見られる多数の他の要素を除去しながら、本原理の明瞭な理解に関係する要素を示すために単純化されていることを理解されたい。用語「第１」および「第２」が、本明細書で様々な要素を記述するのに使用される場合があるが、これらの要素が、これらの用語によって限定されてはならないことを理解されたい。これらの用語は、ある要素を別の要素から区別するためにのみ使用される。様々な方法が、上で説明され、方法のそれぞれが、説明される方法を達成するために１つまたは複数のステップまたはアクションを含む。ステップまたはアクションの特定の順序が、方法の正しい動作のために要求されない限り、特定のステップおよび／またはアクションの順序および／または使用を、変更しまたは組み合わせることができる。
【００５０】
［0064］  ピクチャは、モノクローム・フォーマットのルマ・サンプルの配列または４：２：０、４：２：２、および４：４：４カラー・フォーマットのルマ・サンプルの１つの配列およびクロマ・サンプルの２つの対応する配列である。一般に「ブロック」は、サンプル配列（たとえば、ルマＹ）内の特定の区域をアドレッシングし、「ユニット」は、すべての符号化された色成分（ルマＹとおそらくはクロマＣｂおよびクロマＣｒ）の同一位置に配置されたブロックを含む。しかし、用語「ブロック」は、本明細書ではブロック（たとえば、ＣＢ）またはユニット（たとえば、ＣＵ）を指すのに使用される。
【００５１】
［0065］  以下のセクションでは、用語「再構成された」および「復号された」が、交換可能に使用され得る。必ずではないが通常、「再構成された」は符号器側で使用され、「復号された」は復号器側で使用される。
【００５２】
符号化装置
［0066］  図５は、非限定的な実施形態による、ビットストリーム内でイメージ・ブロックを符号化するように構成された送信器２００の例示的なアーキテクチャを表す。
【００５３】
［0067］  送信器２００は、内部メモリ２０３０（たとえば、ＲＡＭ、ＲＯＭ、および／またはＥＰＲＯＭ）と共に、１つまたは複数のプロセッサ２０００を含み、プロセッサ２０００は、たとえば、ＣＰＵ、ＧＰＵ、および／またはＤＳＰ（デジタル信号プロセッサの英語頭字語）を含むことができる。送信器２００は、それぞれが出力情報を表示し、かつ／またはユーザがコマンドおよび／もしくはデータ（たとえば、ストリーム）を入力することを可能にするように適合された１つまたは複数の通信インターフェース２０１０（たとえば、キーボード、マウス、タッチパッド、ウェブカム）と、送信器２００の外部とすることができる電源２０２０とを含む。送信器２００は、１つまたは複数のネットワーク・インターフェース（図示せず）をも含むことができる。符号器モジュール２０４０は、コーディング機能を実行するためにデバイス内に含めることのできるモジュールを表す。さらに、符号器モジュール２０４０は、送信器２００の別々の要素として実施され得、あるいは、当業者に既知のようにハードウェアとソフトウェアとの組合せとしてプロセッサ（１つまたは複数）２０００内に組み込まれ得る。
【００５４】
［0068］  イメージ・ブロックは、ソースから入手され得る。異なる実施形態によれば、ソースは、
−ローカル・メモリ、たとえば、ビデオ・メモリ、ＲＡＭ、フラッシュ・メモリ、ハード・ディスクと、
−ストレージ・インターフェース、たとえば、マス・ストレージ、ＲＯＭ、光ディスク、または磁気サポートとのインターフェースと、
−通信インターフェース、たとえば、有線インターフェース（たとえば、バス・インターフェース、広域ネットワーク・インターフェース、ローカル・エリア・ネットワーク・インターフェース）または無線インターフェース（ＩＥＥＥ  ８０２．１１インターフェースまたはＢｌｕｅｔｏｏｔｈインターフェースなど）と、
−イメージ取込回路（たとえば、たとえばＣＣＤ（すなわち電荷結合素子）またはＣＭＯＳ（すなわち相補型金属酸化膜半導体）などのセンサ）
とすることができるが、これに限定されない。
【００５５】
［0069］  異なる実施形態によれば、ビットストリームは、宛先に送られ得る。一例として、ビットストリームは、リモート・メモリまたはローカル・メモリ、たとえばビデオ・メモリまたはＲＡＭ、ハード・ディスク内に記憶される。変形形態では、ビットストリームは、ストレージ・インターフェース、たとえば、マス・ストレージ、ＲＯＭ、フラッシュ・メモリ、光ディスク、または磁気サポートとのインターフェースに送られ、かつ／または通信インターフェース、たとえば、ポイント・ツー・ポイト・リンク、通信バス、ポイント・ツー・マルチポイント・リンク、またはブロードキャスト・ネットワークへのインターフェースを介して伝送される。
【００５６】
［0070］  例示的で非限定的な実施形態によれば、送信器２００は、メモリ２０３０内に記憶されたコンピュータ・プログラムをさらに含む。コンピュータ・プログラムは、送信器２００、具体的にはプロセッサ２０００によって実行される時に、送信器２００が図７および／または図１１を参照して説明される符号化方法を実行することを可能にする命令を含む。変形形態によれば、コンピュータ・プログラムは、送信器２００の外部で非一時的デジタル・データ・サポート上、たとえば、すべて当技術分野で既知の、ＨＤＤ、ＣＤ−ＲＯＭ、ＤＶＤ、読取専用および／もしくはＤＶＤドライブ、ならびに／またはＤＶＤ  Ｒｅａｄ／Ｗｒｉｔｅドライブなどの外部記憶媒体上に記憶される。したがって、送信器２００は、コンピュータ・プログラムを読み取る機構を含む。さらに、送信器２００は、対応するＵｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）ポート（図示せず）を介して、１つまたは複数のＵＳＢタイプのストレージ・デバイス（たとえば、「メモリ・スティック」）にアクセスすることができる。
【００５７】
［0071］  例示的で非限定的な実施形態によれば、送信器２００は、
−モバイル・デバイスと、
−通信デバイスと、
−ゲーム・デバイスと、
−タブレット（またはタブレット・コンピュータ）と、
−ラップトップと、
−静止画カメラと、
−ビデオ・カメラと、
−符号化チップまたは符号化デバイス／装置と、
−静止画サーバと、
−ビデオ・サーバ（たとえば、ブロードキャスト・サーバ、ビデオオンデマンド・サーバ、またはウェブ・サーバ）と
とすることができるが、これに限定されない。
【００５８】
［0072］  図６は、図７および／または図１１の符号化方法を実行するように適合された例示的なビデオ符号器４００を示す。符号器４００は、送信器２００の例であり、あるいは、そのような送信器２００の一部とすることができる。１つまたは複数のピクチャを有するビデオ・シーケンスを符号化するために、ピクチャは、構成可能なサイズを有する正方形形状のコーディング・ツリー・ユニット（ＣＴＵ）に区分され得る。コーディング・ツリー・ユニットの連続するセットは、スライスにグループ化され得る。ＣＴＵは、コーディング・ユニットへのＱＴＢＴ区分のルートである。例示的な符号器４００では、ピクチャは、下で説明する符号器モジュールによって符号化される。各ブロックは、イントラ・モードまたはインター・モードのいずれかを使用して符号化される。ブロックがイントラ・モードで符号化される時には、符号器４００は、イントラ予測（モジュール４６０）を実行する。インター・モードでは、動き推定（モジュール４７５）および動き補償（モジュール４７０）が実行される。符号器は、イントラ・モードまたはインター・モードのどちらをブロックの符号化に使用すべきかを決定し（モジュール４０５）、予測モード・フラグによってイントラ／インター決定を示す。残差が、元の画像ブロックから予測されたサンプル・ブロック（プレディクタとも称する）を減算する（モジュール４１０）ことによって計算される。
【００５９】
［0073］  一例として、ブロックは、イントラ・モードでは再構成された隣接サンプルから予測される。インター予測は、参照ピクチャ・バッファ４８０内に記憶された参照ブロックを動き補償することによって実行される。
【００６０】
［0074］  残差は、変換され（モジュール４２５）、量子化される（モジュール４３０）。量子化された変換係数ならびに動きベクトルおよび他の構文要素が、ビットストリームを出力するためにエントロピ・コーディングされる（モジュール４４５）。符号器は、変換をスキップし、変換されていない残差信号に直接に量子化を適用することもできる。符号器は、変換と量子化との両方を迂回することもできる、すなわち、残差は、変換プロセスまたは量子化プロセスを適用せずに直接にコーディングされる。直接ＰＣＭコーディングでは、予測が適用されず、ブロック・サンプルは、直接にビットストリームにコーディングされる。
【００６１】
［0075］  符号器は、復号ループを含み、したがって、さらなる予測のための参照を提供するために、符号化されたブロックを復号する。量子化された変換係数は、残差を復号するために、逆量子化され（モジュール４４０）、逆変換される（モジュール４５０）。イメージ・ブロックは、復号された残差と予測されたサンプル・ブロックとを組み合わせる（モジュール４５５）ことによって再構成される。ループ内フィルタ（４６５）が、たとえばコーディング・アーティファクトを減らすためにデブロッキング／ＳＡＯ（サンプル・アダプティブ・オフセット）フィルタリングを実行するために、再構成されたピクチャに適用され得る。フィルタリングされたイメージは、参照ピクチャ・バッファ４８０内に記憶される。
【００６２】
符号化方法
［0076］  図７は、特定の非限定的な実施形態による、ビットストリーム内でイメージのブロックを符号化する方法の流れ図を表す。
【００６３】
［0077］  この方法は、ステップＳ２００で開始する。ステップＳ２１０では、たとえば符号器４００などの送信器が、イメージのブロックにアクセスする。ブロックは、サイズｗ×ｈであり、ｗはその幅（画素単位）であり、ｈはその高さ（画素単位）である。ブロックは、ルマ・サンプルのコーディング・ブロック、クロマ・サンプルのコーディング・ブロック、またはルマ・サンプルの１つのコーディング・ブロックとクロマ・サンプルの２つのコーディング・ブロックとによって形成されるコーディング・ユニットのうちの１つである。ステップＳ２２０では、送信器が、分割モードのセット内でアクセスされたブロックの分割モードを判定する。特定の実施形態では、判定された分割モードは、分割モードのセット内で最小限のレートひずみコストを実現する分割モードである。本原理によれば、分割モードのセットは、少なくとも１つの非対称分割モードを含む。図８は、そのような非対称分割モードの例を示す。第１の実施形態では、少なくとも１つの非対称分割モードは、ブロックを高さｈ／４の１つのサブブロックと高さ３ｈ／４の１つのサブブロックとに水平に分割することを示す。高さｈ／４のサブブロックは、高さ３ｈ／４のサブブロックの上（モードＨＯＲ＿ＵＰ）または下（モードＨＯＲ＿ＤＯＷＮ）のいずれかにある。別の実施形態では、少なくとも１つの非対称分割モードは、ブロックを幅ｗ／４の１つのサブブロックと幅３ｗ／４の１つのサブブロックとに垂直に分割することを示す。幅ｗ／４のサブブロックは、幅３ｗ／４のサブブロックの左（モードＶＥＲ＿ＬＥＦＴ）または右（モードＶＥＲ＿ＲＩＧＨＴ）のいずれかにある。特定の実施形態では、分割モードのセットは、図８に示された分割モードのすべてを含む。変形実施形態では、少なくとも１つの非対称分割モードは、ブロックを、そのサイズが２のべきではないサブブロックに水平または垂直のいずれかに分割することを示し、たとえば、幅ｗまたは高さｈにおけるサイズは、３・２n画素と等しく、ｎは整数である。
【００６４】
［0078］  変形形態では、分割モードのセットは、少なくとも１つの非対称分割モードに加えて、ＱＴＢＴによって定義される、図４に示された分割モードを含む。分割モードが、ブロックがさらには分割されないことを示す（たとえば、分割モード＝ＮＯ＿ＳＰＬＩＴ）場合には、そのブロックは、ステップＳ２５０で符号化される。
【００６５】
［0079］  そうではない場合には、ステップＳ２３０で、送信器が、判定された分割モードに応答して、アクセスされたブロックを少なくとも２つのサブブロックに分割する。
【００６６】
［0080］  ステップＳ２４０では、送信器が、ビットストリーム内で少なくとも２つのサブブロックを符号化する。少なくとも２つのサブブロックの符号化は、少なくとも２つのサブブロックのそれぞれに対してステップＳ２２０〜Ｓ２５０を再帰的に適用することを含み得る。再帰的分割は、たとえば分割モードＮＯ＿ＳＰＬＩＴがステップＳ２２０で判定されるので、ブロックがさらには分割されない時に終了する。この場合には、ブロックは、以下のステップを適用することによってステップＳ２５０で符号化される。
−予測されたブロックを入手するために前記ブロックのサンプルに対して同一の予測を適用するステップ
−前記予測されたブロックおよび前記ブロックから残差ブロックを判定するステップ
−変換されたブロックを入手するために前記残差ブロックのサンプルに対して同一の変換を適用するステップ
−ビットストリーム内で前記変換されたブロックを符号化する、たとえば、量子化し、エントロピ・コーディングするステップ
ブロックをどのように分割するのかを示す分割情報も、ビットストリーム内で符号化される。
【００６７】
［0081］  この方法は、ステップＳ２６０で終了する。
【００６８】
［0082］  有利なことに、３・２nと等しい幅または高さを有するコーディング・ユニットが、本原理に従って符号器によって選択され得る。その場合に、３の倍数のサイズを有する長方形ブロックのイントラ予測および／またはインター予測が実行され得る。さらに、幅または高さにおいてサイズ３・２nを有する２Ｄ変換および後続の変換係数エントロピ・コーディング・プロセスも実行され得る。
【００６９】
［0083］  これらの追加のコーディング・ユニット・トポロジは、元の信号に含まれる構造および不連続性と空間的に一致するコーディング構造を有するのを手伝う。本原理によるＣＵへのＣＴＵの区分の例が、図９に表されている。この図では、四分木区分が実線によって表され、二項区分（対称および非対称）が破線によって表されている。そのような区分（特に灰色のＣＵ）を、ＨＥＶＣまたはＱＴＢＴで定義される区分を用いて得ることはできない。二項分割の場合の非対称分割モードの追加は、元の信号に含まれる構造および不連続性によりよく一致することによってコーディング効率を改善する。
【００７０】
［0084］  ビットストリーム内で二項分割情報を符号化するための例示的な構文が、表１および表２で定義される。この構文は、情報の様々な項目がどのようにコーディングされるのかを定義する。ＱＴＢＴで定義された二項分割モードを符号化するのに使用される構文要素ｂｔＳｐｌｉｔＦｌａｇおよびｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎは、未変更のままである。第１の構文要素ｂｔＳｐｌｉｔＦｌａｇは、ブロック（ＣＵまたはＣＢ）が分割されるかどうかを示し、そうである場合には、第２の構文要素ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎが、ブロックが水平または垂直のどちらで分割されるのかを示す。ＱＴＢＴ構文は、図８の新しい分割モードを示す新しい構文要素を追加することによって変更される。表１および表２は、本原理による構文の例であり、ＱＴＢＴ構文に対する修正は、斜体で示されている。図１０は、表１および表２で定義された構文のグラフ表現である。追加された構文要素は、図１０では破線で示されている。ＱＴＢＴからの構文要素は、図１０では実線によって示されている。
【００７１】
［0085］  新しい構文要素は、二項分割が非対称であるかどうかを示し、そうである場合には、どの非対称二項分割モードが使用されるのかを示す。より正確には、ｈｏｒＡｓｙｓｍｍｅｔｒｉｃＦｌａｇ構文要素およびｖｅｒＡｓｙｓｍｍｅｔｒｉｃＦｌａｇ構文要素は、それぞれ水平分割および垂直分割の場合に、二項分割されるブロックについて、分割モードが非対称であるか否かを示す。
【数１】
2019537299.tif 000003
構文要素は、水平に非対称に分割されるブロックについて、ＨＯＲUP非対称二項分割モードまたはＨＯＲDOWN非対称二項分割モードのどちらに従ってそのブロックが分割されるのかを示す。
【数２】
2019537299.tif 000004
構文要素は、垂直に非対称に分割されるブロックについて、ＶＥＲLEFT非対称二項分割モードまたはＶＥＲRIGHT非対称二項分割モードのどちらに従ってそのブロックが分割されるのかを示す。
【００７２】
特定の実施形態では、構文要素ｈｏｒＡｓｙｓｍｍｅｔｒｉｃＦｌａｇおよび
【数３】
2019537299.tif 000005
（それぞれｖｅｒＡｓｙｓｍｍｅｔｒｉｃＦｌａｇおよび
【数４】
2019537299.tif 000006
）は、非対称水平分割（それぞれ、非対称垂直分割）が許容されない場合には存在しない。
【表１−１】
2019537299.tif 000007
【表１−２】
2019537299.tif 000008
表１
【表２】
2019537299.tif 000009
表２
【００７３】
［0086］  図１１は、表１および表２で定義された修正された構文を使用する特定の非限定的な実施形態による、現在のブロックの二項分割情報を符号化する方法の流れ図を表す。
【００７４】
［0087］  図１１では、現在のブロックの二項分割モード符号化に関するステップだけが表されている。この方法は、ステップＳ２０００で開始する。ステップＳ２０１０では、符号器４００などの送信器２００が、現在のブロックにアクセスする。
【００７５】
［0088］  ステップＳ２０２０では、送信器２００が、二項分割が現在のブロックに関して許容されるかどうかをチェックする。これは、通常は、現在のブロックの幅（ｗ）または現在のブロックの高さ（ｈ）が第１のしきい値（ｍｉｎＢＴＳｉｚｅ）より大きいかどうかをチェックすることに存する。幅または高さにおける最小長方形ブロック・サイズの典型的な  はｍｉｎＢＴＳｉｚｅ＝４である。そうでない場合には、ブロックは分割されず、分割に関する他の構文要素はコーディングされない。
【００７６】
［0089］  そうではない（二項分割が許容される）場合には、ステップＳ２０３０で、現在のブロックが分割されるか否かを示すために、第１のフラグ（ｂｔＳｐｌｉｔＦｌａｇ）を符号化する。例のｂｔＳｐｌｉｔＦｌａｇは、現在のブロックが分割されることを示すために値１またはＴｒｕｅをとり、現在のブロックが分割されないことを示すために値Ｆａｌｓｅまたは０をとることができる。ステップＳ２０４０では、送信器２００が、現在のブロックが分割されまたはされないのどちらを第１のフラグが示すのかをチェックする。
【００７７】
［0090］  ステップＳ２０４０で、第１のフラグが、現在のブロックが分割されないことを示す（たとえば、ｂｔＳｐｌｉｔＦｌａｇ＝Ｆａｌｓｅなので）場合には、分割に関する他の構文要素はコーディングされない。
【００７８】
［0091］  そうではなく、ステップＳ２０４０で、第１のフラグが、現在のブロックが分割されることを示す（たとえば、ｂｔＳｐｌｉｔＦｌａｇ＝Ｔｒｕｅなので）場合には、ステップＳ２０５０で、送信器２００が、水平、垂直、非対称水平、および非対称垂直の分割モードが現在のブロックに関して許容されるかどうかを判定する。
【００７９】
［0092］  一例として、垂直分割モードは、条件（ｗ＞ｍｉｎＢＴＳｉｚｅ  ＆＆  ｗ％３≠０）が真である場合に許容され、％は、モジュロ演算子である。ｗ％３は、３によるｗの除算の後の剰余を返す。通常、ｍｉｎＢＴＳｉｚｅは４と等しい可能性があり、垂直分割モードは、ｗが８、１６、または３２と等しい場合に許容される。
【００８０】
［0093］  この場合には、ｖｅｒｔｉｃａｌ＿ａｌｌｏｗｅｄパラメータに、値１または真をセットすることができる。一例として、水平分割モードは、条件（ｈ＞ｍｉｎＢＴＳｉｚｅ  ＆＆  ｈ％３≠０）が真である場合に許容される。この場合には、ｈｏｒｉｚｏｎｔａｌ＿ａｌｌｏｗｅｄパラメータに、値１または真をセットすることができる。一例として、垂直非対称分割モードは、条件ｖｅｒｔｉｃａｌallowed  ＆＆  ｗ＞８が真である場合に許容される。一例として、水平非対称分割モードは、条件ｈｏｒｉｚｏｎｔａｌallowed  ＆＆  ｈ＞８が真である場合に許容される。したがって、非対称水平分割または非対称垂直分割から生じる通常の許容されるブロックの幅または高さは、１６／４＝４、１６＊３／４＝１２、３２／４＝８、３２＊３／４＝２４である。
【００８１】
［0094］  この実施形態では、ブロックが既に非対称な形で分割されている場合に、我々は、ブロックが３の倍数のサイズを有する方向でのブロックのさらなる分割を許容しない。さらに、ブロック・サイズに対するなんらかの制限が、ブロックの非対称分割を許容するために課される。通常、ブロック・サイズは８を超えなければならない。この場合に、３の倍数である最小ブロックのサイズは、１２である。
【００８２】
［0095］  特定の実施形態では、そのサイズが１つの方向で３・２n、ｎ≧１と等しいブロックの二項分割は、分割すべきブロックが２の倍数のサイズを有するならば、その方向に沿って許容される。これは、ブロックの分割が、３のブロック・サイズにつながり得ることを意味する。たとえば、ブロック１２×４は、それぞれがサイズ６×４を有する２つのサブブロックに分割され得る。
【００８３】
［0096］  別の特定の実施形態では、ブロックの非対称分割は、そのサイズが８を超え、２のべきであるならば許容される。たとえば、これは、サイズ８×４を有するブロックの、サイズ６×４および２×４を有する２つのサブ・コーディング・ユニットへの非対称分割を許容する。これは、具体的には、ＱＴＢＴツールが下がって２までのブロック・サイズを許容する場合のクロマ成分で可能である可能性がある。その場合に、条件ｖｅｒｔｉｃａｌallowed  ＆＆  ｗ＞８は、条件ｖｅｒｔｉｃａｌallowed  ＆＆  ｗ≧８に置換される。同様に、その場合に、条件ｈｏｒｉｚｏｎｔａｌallowed  ＆＆  ｗ＞８は、条件ｈｏｒｉｚｏｎｔａｌallowed  ＆＆  ｗ≧８に置換される。
【００８４】
［0097］  ステップＳ２０６０では、送信器２００が、水平分割モードと垂直分割モードとの両方が許容されるかどうかをチェックする。そうである場合には、ステップＳ２０７０で、二項分割方位（水平または垂直）を示すために、構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）をコーディングする。水平分割または垂直分割のいずれかが許容されない場合には、この構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）はコーディングされない。この後者の場合には、二項分割方位は、次のように復号器側で推論される。水平分割が許容されない場合には、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎは、ＶＥＲと等しいと推論される。そうではなく、垂直分割が許容されない場合には、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎは、ＨＯＲと等しいと推論される。
【００８５】
［0098］  その後、ステップＳ２０８０（水平分割の場合）またはステップＳ２０９０（垂直分割の場合）で、送信器２００は、非対称分割モードがこの方位に沿って許容されるかどうかをチェックする。そうではない場合には、分割に関するさらなる構文要素は、コーディングされない。この後者の場合には、二項分割モードは、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ値に依存して、復号器側でＨＯＲまたはＶＥＲであると推論される。
【００８６】
［0099］  そうではない場合には、構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）は、（ステップＳ２０８２またはＳ２０９２で）非対称分割が現在のブロックに関して使用されるか否かを示すために符号化される。
【００８７】
［0100］  一例として、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ（それぞれ、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）は、現在のブロックが非対称に分割されることを示すために値１またはＴｒｕｅをとることができ、現在のブロックが非対称に分割されないことを示すために値Ｆａｌｓｅまたは０をとることができる。ステップＳ２０８４（それぞれ、Ｓ２０９４）で、送信器２００は、現在のブロックが非対称に水平に（それぞれ、垂直に）分割されるかどうかをチェックする。
【００８８】
［0101］  非対称分割が使用されない（たとえば、ステップＳ２０８４でｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇが偽であるか、ステップＳ２０９４でｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇがＦａｌｓｅである）場合には、分割に関するさらなる構文要素は、コーディングされない。非対称分割が使用される（ステップＳ２０８４でｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇが真であるか、ステップＳ２０９４でｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇがＴｒｕｅである）場合には、現在のブロックの非対称分割モードを示すために、別の構文要素（ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）が符号化される（ステップＳ２０８６またはＳ２０９６で）。
【００８９】
［0102］  ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、値ＨＯＲ＿ＵＰまたはＨＯＲ＿ＤＯＷＮをとることができ、ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、値ＶＥＲ＿ＬＥＦＴまたはＶＥＲ＿ＲＩＧＨＴをとることができる。
【００９０】
［0103］  この方法は、ステップＳ２１００で終了する。
【００９１】
復号装置
［0104］  図１２は、非限定的な実施形態による、復号されたイメージ・ブロックを入手するためにビットストリームからイメージ・ブロックを復号するように構成された受信器１００の例示的なアーキテクチャを表す。
【００９２】
［0105］  受信器１００は、内部メモリ１０３０（たとえば、ＲＡＭ、ＲＯＭ、および／またはＥＰＲＯＭ）と共に、１つまたは複数のプロセッサ１０００を含み、プロセッサ１０００は、たとえばＣＰＵ、ＧＰＵ、および／またはＤＳＰ（デジタル信号プロセッサの英語頭字語）を含むことができる。受信器１００は、それぞれが出力情報を表示し、かつ／またはユーザがコマンドおよび／もしくはデータ（たとえば、復号されたイメージ・ブロック）を入力することを可能にするように適合された１つまたは複数の通信インターフェース１０１０（たとえば、キーボード、マウス、タッチパッド、ウェブカム）と、受信器１００の外部とすることができる電源１０２０とを含む。受信器１００は、１つまたは複数のネットワーク・インターフェース（図示せず）をも含むことができる。復号器モジュール１０４０は、復号機能を実行するためにデバイス内に含めることのできるモジュールを表す。さらに、復号器モジュール１０４０は、受信器１００の別々の要素として実施され得、あるいは、当業者に既知のようにハードウェアとソフトウェアとの組合せとしてプロセッサ（１つまたは複数）１０００内に組み込まれ得る。
【００９３】
［0106］  ビットストリームは、ソースから入手され得る。異なる実施形態によれば、ソースは、
−ローカル・メモリ、たとえば、ビデオ・メモリ、ＲＡＭ、フラッシュ・メモリ、ハード・ディスクと、
−ストレージ・インターフェース、たとえば、マス・ストレージ、ＲＯＭ、光ディスク、または磁気サポートとのインターフェースと、
−通信インターフェース、たとえば、有線インターフェース（たとえば、バス・インターフェース、広域ネットワーク・インターフェース、ローカル・エリア・ネットワーク・インターフェース）または無線インターフェース（ＩＥＥＥ  ８０２．１１インターフェースまたはＢｌｕｅｔｏｏｔｈインターフェースなど）と、
−ピクチャ取込回路（たとえば、たとえばＣＣＤ（すなわち電荷結合素子）またはＣＭＯＳ（すなわち相補型金属酸化膜半導体）などのセンサ）
とすることができるが、これに限定されない。
【００９４】
［0107］  異なる実施形態によれば、復号されたイメージ・ブロックは、宛先、たとえばディスプレイ・デバイスに送られ得る。一例として、復号されたイメージ・ブロックは、リモート・メモリまたはローカル・メモリ、たとえばビデオ・メモリまたはＲＡＭ、ハード・ディスク内に記憶される。変形形態では、復号されたイメージ・ブロックは、ストレージ・インターフェース、たとえば、マス・ストレージ、ＲＯＭ、フラッシュ・メモリ、光ディスク、または磁気サポートとのインターフェースに送られ、かつ／または通信インターフェース、たとえば、ポイント・ツー・ポイト・リンク、通信バス、ポイント・ツー・マルチポイント・リンク、またはブロードキャスト・ネットワークへのインターフェースを介して伝送される。
【００９５】
［0108］  特定の非限定的な実施形態によれば、受信器１００は、メモリ１０３０内に記憶されたコンピュータ・プログラムをさらに含む。コンピュータ・プログラムは、受信器１００、具体的にはプロセッサ１０００によって実行される時に、受信器が図１４および／または図１５を参照して説明される復号方法を実行することを可能にする命令を含む。変形形態によれば、コンピュータ・プログラムは、受信器１００の外部で非一時的デジタル・データ・サポート上、たとえば、すべて当技術分野で既知の、ＨＤＤ、ＣＤ−ＲＯＭ、ＤＶＤ、読取専用および／もしくはＤＶＤドライブ、ならびに／またはＤＶＤ  Ｒｅａｄ／Ｗｒｉｔｅドライブなどの外部記憶媒体上に記憶される。したがって、受信器１００は、コンピュータ・プログラムを読み取る機構を含む。さらに、受信器１００は、対応するＵｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）ポート（図示せず）を介して１つまたは複数のＵＳＢタイプのストレージ・デバイス（たとえば、「メモリ・スティック」）にアクセスすることができる。
【００９６】
［0109］  例示的で非限定的な実施形態によれば、受信器１００は、
−モバイル・デバイスと、
−通信デバイスと、
−ゲーム・デバイスと、
−セット・トップ・ボックスと、
−ＴＶセットと、
−タブレット（またはタブレット・コンピュータ）と、
−ラップトップと、
−ビデオ・プレイヤ、たとえば、ブルーレイ・プレイヤ、ＤＶＤプレイヤと、
−ディスプレイと、
−復号チップまたは復号デバイス／装置と
とすることができるが、これに限定されない。
【００９７】
［0110］  図１３は、図１４および／または図１５の復号方法を実行するように適合された例示的なビデオ復号器３００のブロック図を示す。ビデオ復号器３００は、受信器１００の例であり、あるいは、そのような受信器１００の一部とすることができる。例示的な復号器３００では、ビットストリームが、下で説明するように復号器モジュールによって復号される。ビデオ復号器３００は、一般に、図６で説明したビデオ符号器４００によって実行される符号化パスと相反する復号パスを実行する。
【００９８】
［0111］  具体的には、復号器の入力は、ビデオ符号器４００によって生成され得るビデオ・ビットストリームを含む。ビットストリームは、まず、変換係数、動きベクトル、および他のコーディングされた情報を入手するためにエントロピ復号される（モジュール３３０）。変換係数が、残差を復号するために逆量子化され（モジュール３４０）、逆変換される（モジュール３５０）。その後、復号された残差は、復号され／再構成されたイメージ・ブロックを入手するために、予測されたサンプル・ブロック（プレディクタとも称する）と組み合わされる（モジュール３５５）。予測されたサンプル・ブロックは、イントラ予測（モジュール３６０）または動き補償された予測（すなわち、インター予測）（モジュール３７５）から入手され得る（モジュール３７０）。ループ内フィルタ（モジュール３６５）が、再構成されたイメージに適用され得る。ループ内フィルタは、デブロッキング・フィルタおよびＳＡＯフィルタを含むことができる。フィルタリングされたイメージは、参照ピクチャ・バッファ３８０内に記憶される。
【００９９】
復号方法
［0112］  図１４は、特定の非限定的な実施形態による、ビットストリームからイメージのブロックを復号する方法の流れ図を表す。ブロックは、サイズｗ×ｈであり、ｗは画素単位のその幅であり、ｈは画素単位のその高さである。ブロックは、ルマ・サンプルのブロック、クロマ・サンプルのブロック、またはルマ・サンプルの１つのブロックとクロマ・サンプルの２つのブロックとによって形成されるコーディング・ユニットのうちの１つである。
【０１００】
［0113］  この方法は、ステップＳ１００で開始する。ステップＳ１１０では、復号器３００などの受信器１００が、復号されるブロックを表すビットストリームまたはその一部にアクセスする。
【０１０１】
［0114］  ステップＳ１２０では、受信器が、分割モードのセット内でブロックの分割モードを判定する。分割モードは、たとえばビットストリームから復号される。本原理によれば、分割モードのセットは、少なくとも１つの非対称分割モードを含む。図８は、そのような非対称分割モードの例を示す。第１の実施形態では、少なくとも１つの非対称分割モードは、ブロックを高さｈ／４の１つのサブブロックと高さ３ｈ／４の１つのサブブロックとに水平に分割することを示す。高さｈ／４のサブブロックは、高さ３ｈ／４のサブブロックの上（モードＨＯＲ＿ＵＰ）または下（モードＨＯＲ＿ＤＯＷＮ）のいずれかにある。別の実施形態では、少なくとも１つの非対称分割モードは、ブロックを幅ｗ／４の１つのサブブロックと幅３ｗ／４の１つのサブブロックとに垂直に分割することを示す。幅ｗ／４のサブブロックは、幅３ｗ／４のサブブロックの左（モードＶＥＲ＿ＬＥＦＴ）または右（モードＶＥＲ＿ＲＩＧＨＴ）のいずれかにある。特定の実施形態では、分割モードのセットは、図８に示された分割モードのすべてを含む。変形実施形態では、少なくとも１つの非対称分割モードは、ブロックを、そのサイズが２のべきではないサブブロックに水平または垂直のいずれかに分割することを示し、たとえば、幅または高さにおけるサイズは、３・２nと等しく、ｎは整数である。
【０１０２】
［0115］  変形形態では、分割モードのセットは、少なくとも１つの非対称分割モードに加えて、ＱＴＢＴによって定義される、図４に示された分割モードを含む。分割モードが、ブロックがさらには分割されないことを示す（ＮＯ＿ＳＰＬＩＴ）場合には、そのブロックは、ステップＳ１５０で復号される。
【０１０３】
［0116］  そうではない場合には、ステップＳ１３０で、受信器が、判定された分割モードに応答して、アクセスされたブロックを少なくとも２つのサブブロックに分割する。
【０１０４】
［0117］  ステップＳ１４０では、送信器が、少なくとも２つのサブブロックのそれぞれを復号する。少なくとも２つのサブブロックの復号は、少なくとも２つのサブブロックのそれぞれにステップＳ１２０〜Ｓ１４０を再帰的に適用することを含むことができる。再帰的な分割は、ブロックが、たとえば分割モードＮＯ＿ＳＰＬＩＴがステップＳ１２０で判定されるので、さらには分割されない時に終了する。この場合に、ブロックは、以下のステップを適用することによってステップＳ１５０で復号される。
−前記サブブロックの変換されたブロックを復号する、たとえばエントロピ復号し、逆量子化するステップ
−残差ブロックを入手するために前記復号された変換されたブロックのサンプルに対して同一の変換（符号器側で使用されたものの逆）を適用するステップ
−予測されたブロックを入手するために前記サブブロックのサンプルに対して同一の予測を適用するステップ
−前記予測されたブロックおよび前記残差ブロックから前記サブブロックを再構成するステップ。
【０１０５】
［0118］  この方法は、ステップＳ１６０で終了する。
【０１０６】
［0119］  ブロックがどのように分割されるのかを示す分割情報もビットストリームから復号される。
【０１０７】
［0120］  図１５は、表１および表２で定義された修正された構文を使用する特定の非限定的な実施形態による、二項分割の場合の現在のブロックの分割モードを復号する方法の流れ図を表す。
【０１０８】
［0121］  図１５では、現在のブロックの二項分割モード復号に関するステップだけが表されている。この方法は、ステップＳ１０００で開始する。ステップＳ１０１０では、復号器３００などの受信器１００が、復号される現在のブロックを表すビットストリームまたはその一部にアクセスする。
【０１０９】
［0122］  ステップＳ１０２０では、受信器１００が、二項分割が、復号される現在のブロックに関して許容されるかどうかをチェックする。これは、通常、現在のブロックの幅（ｗ）または現在のブロックの高さ（ｈ）が第１のしきい値（ｍｉｎＢＴＳｉｚｅ）より大きいかどうかをチェックすることに存する。幅または高さにおける最小長方形ブロック・サイズの典型的な  はｍｉｎＢＴＳｉｚｅ＝４である。二項分割が許容されない場合には、ブロックは分割されず（ステップＳ１０４５で、ｂｔＳｐｌｉｔＭｏｄｅにＮＯ＿ＳＰＬＩＴをセットする）、分割に関する他の構文要素は復号されない。
【０１１０】
［0123］  そうではない（二項分割が許容される）場合には、ステップＳ１０３０で、現在のブロックが分割されるか否かを示す第１のフラグ（ｂｔＳｐｌｉｔＦｌａｇ）をビットストリームから復号する。
【０１１１】
［0124］  ステップＳ１０４０では、受信器１００が、現在のブロックが分割されるか否かをチェックする。現在のブロックが分割されない（たとえば、ステップＳ１０４０でｂｔＳｐｌｉｔＦｌａｇがＦａｌｓｅである）場合には、分割に関する他の構文要素は復号されない。ステップＳ１０４５で、ｂｔＳｐｌｉｔＭｏｄｅにＮＯ＿ＳＰＬＩＴをセットする。
【０１１２】
［0125］  現在のブロックが分割される（ステップＳ１０４０でｂｔＳｐｌｉｔＦｌａｇがＴｒｕｅである）場合には、ステップＳ１０５０で、受信器１００が、現在のブロックに関して水平、垂直、非対称水平、および非対称垂直の分割モードが許容されるかどうかを判定する。ステップＳ１０５０は、図１１のステップＳ２０５０と同一である。
【０１１３】
［0126］  ステップＳ１０６０では、受信器１００が、水平分割モードと垂直分割モードとの両方が許容されるかどうかをチェックする。そうである場合には、ステップＳ１０７０で、二項分割方位（水平または垂直）を示すために、構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）を復号する。水平分割または垂直分割のいずれかが許容されない場合には、この構文要素（ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ）は復号されない。この後者の場合には、ステップＳ１０６５で、二項分割方位を推論する。水平分割が許容されない場合には、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎはＶＥＲと等しいと推論される。そうではなく、垂直分割が許容されない場合には、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎはＨＯＲと等しいと推論される。
【０１１４】
［0127］  その後、受信器１００は、ステップＳ１０８０（水平分割の場合）またはステップＳ１０９０（垂直分割の場合）で、非対称分割がこの方位に沿って許容されるかどうかをチェックする。そうではない場合には、分割に関するさらなる構文要素は、復号されない。この後者の場合には、二項分割モードは、ｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎ値に依存してＨＯＲまたはＶＥＲであると推論される（ｂｔＳｐｌｉｔＭｏｄｅには、ステップＳ１０８５でｂｔＳｐｌｉｔＯｒｉｅｎｔａｔｉｏｎがセットされる）。
【０１１５】
［0128］  そうではない場合には、非対称分割が現在のブロックに関して使用されるか否かを示す構文要素（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）が復号される（ステップＳ１０８２またはＳ１０９２で）。ステップＳ１０８４（それぞれ、Ｓ１０９４）では、受信器１００が、現在のブロックが非対称に水平に（それぞれ、垂直に）分割されるかどうかをチェックする。
【０１１６】
［0129］  非対称分割が使用されない（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇがＴｒｕｅではない）場合には、分割に関するさらなる構文要素は、復号されない。非対称分割が使用される（ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇまたはｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇがＴｒｕｅである）場合には、現在のブロックの非対称分割モードを示す構文要素（ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）が復号される（ステップＳ１０８６またはＳ１０９６で）。
【０１１７】
［0130］  ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、値ＨＯＲ＿ＵＰまたはＨＯＲ＿ＤＯＷＮをとることができ、ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、値ＶＥＲ＿ＬＥＦＴまたはＶＥＲ＿ＲＩＧＨＴをとることができる。
【０１１８】
［0131］  ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅが値ＨＯＲ＿ＵＰをとる場合には、二項分割モード（ｂｔＳｐｌｉｔＭｏｄｅ）は、ＨＯＲ＿ＵＰと等しくなるようにセットされる。
【０１１９】
［0132］  ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅが値ＨＯＲ＿ＤＯＷＮをとる場合には、二項分割モードは、ＨＯＲ＿ＤＯＷＮと等しくなるようにセットされる。
【０１２０】
［0133］  ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅが値ＶＥＲ＿ＬＥＦＴをとる場合には、二項分割モードは、ＶＥＲ＿ＬＥＦＴと等しくなるようにセットされる。
【０１２１】
［0134］  ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅが値ＶＥＲ＿ＬＥＦＴをとる場合には、二項分割モードは、ＶＥＲ＿ＬＥＦＴと等しくなるようにセットされる。
【０１２２】
［0135］  この方法は、ステップＳ１１００で終了する。
【０１２３】
構文要素のエントロピ・コーディングおよびエントロピ復号
［0136］  新しい構文要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、異なる形で符号化され得る。第１の実施形態では、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ（それぞれ、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）は、ビットストリーム内の単一のビットを用いてコーディングされる。これは、対称分割モードおよび非対称分割モードが等しい確率を有する、すなわち、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ（それぞれ、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ）が、真と等しくなる０．５の確率を有する場合に限って最適である。 その場合に、これらの構文要素によってそれぞれもたらされる情報の平均量は、１ビットと等しく、１ビットを用いる固定長コーディングが最適である。
【０１２４】
［0137］  最も実用的な場合には、対称分割モードおよび非対称分割モードは、等確率ではない可能性が高い。したがって、別の実施形態によれば、コンテキストベースの算術コーディングが、構文要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇを符号化するのに使用される。コンテキストベースの算術コーディングは、コンテキスト・モデル化および算術コーディングを含む。特定の実施形態では、コンテキストベースの算術コーディングは、コンテキスト・モデル化の前に、構文要素の２進化を含むことができる。２進化および算術コーディングは、過去の符号化方式（たとえば、Ｈ．２６４およびＨＥＶＣ）から周知である。コンテキスト・モデル化は、なんらかのコンテキストに基づいて各構文要素の確率を推定し、符号器側および復号器側に対称に適用する。エントロピ・コーディングに関して開示される以下の実施形態はエントロピ復号にもあてはまる。したがって、新しいコンテキストが、新しい構文要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＦｌａｇのために定義される。
【０１２５】
［0138］  この実施形態では、それぞれ各構文要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＦｌａｇに関連する２つの単純なコンテキストが使用される。これらのコンテキストのそれぞれは、関係する構文要素自体によって過去（すなわち、コーディング順で現在のブロックに先行するブロックを符号化する時）にとられた値だけに依存する。したがって、考慮される構文要素によって表されるランダム変数の一次エントロピに近い情報の平均量にわたってこの非対称分割モード情報を符号化することができる。したがって、これらの構文要素は、これらのフラグの統計的分布が均一ではない場合に、平均して１ビット未満にわたって符号化される。このコンテキストベースのコーディングの変形形態では、ｈｏｒＡｓｙｍｍｅｔｒｉｃＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＦｌａｇに使用されるコンテキストが、同一である。実際に、この２つの構文要素のコーディングは、同一のコンテキストを共有することができる。これは、ｈｏｒＡｓｙｍｍｅｔｒｉｃＦｌａｇがＴＲＵＥまたはＦＡＬＳＥになり、現在のブロックが水平方位で二項分割されることを知る確率が、ｖｅｒＡｓｙｍｍｅｔｒｉｃＦｌａｇがＴＲＵＥまたはＦＡＬＳＥになり、現在のブロックが垂直方位で二項分割されることを知る確率に近いと仮定するならば、効率的であるはずである。
【０１２６】
［0139］  第３の実施形態では、これらの構文要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇは、先行する隣接ブロック内で既に決定された分割構成に関するなんらかのコンテキスト情報の関数としてエントロピ・コーディングされる。非対称分割が、現在のブロックに関して使用される時に、２サブブロックの１つのサブブロックは、幅または高さにおいて現在のブロックのサイズの１／４と等しいサイズを有する。これは、現在のブロックの元の信号が、ある空間アクティビティまたは不連続性を含むことと、コーディング効率に関して現在のブロックを分割することが価値を有することとを意味する。そのような高い空間アクティビティまたは不連続性は、コーディング順で現在のブロックに先行する隣接ブロック内にも存在する可能性が高い。
【０１２７】
［0140］  コンテキストは、考慮される分割方位に沿って現在のブロックのサイズの１／４以下のサイズを有するサブブロックの個数の関数として非対称分割構文要素を符号化するように定義される。これは、それぞれ水平および垂直の非対称分割コンテキストに関して、以下の形をとる。
−ｎｂＱｕａｒｔｅｒＨｅｉｇｈｔＳｕｂＣＵ＝左隣接ブロック内の
【数５】
2019537299.tif 000010
以下の高さを有するサブブロックの個数を判定する。ここで、ｈｅｉｇｈｔ＝現在のブロックの高さである。
−ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔ＝（ｎｂＱｕａｒｔｅｒＨｅｉｇｈｔＳｕｂＣＵ＞０？１：０）      （１）を判定する。
【０１２８】
［0141］  式（１）によれば、２つの異なるコンテキストが、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ構文要素のコーディングに使用される。値ｎｂＱｕａｒｔｅｒＨｅｉｇｈｔＳｕｂＣＵが、厳密に０を超える場合には、第１のコンテキスト（インデックス０を有する）が、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇに対応する２進シンボルを符号化するのに使用される。反対の場合では、値ｎｂＱｕａｒｔｅｒＨｅｉｇｈｔＳｕｂＣＵが０と等しい場合には、第２のコンテキスト（インデックス１を有する）が、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇに対応する２進シンボルを符号化するのに使用される。
【０１２９】
［0142］  左隣接ブロックは、現在のブロックの高さ以上の高さを有し、その右境界が現在のブロックの左境界のｘ座標から１を減じたものと等しいｘ座標を有するブロックに対応する。左隣接ブロックは、高さ方向で１つまたは複数のサブブロックに分割され得る。
−ｎｂＱｕａｒｔｅｒＷｉｄｔｈＳｕｂＣＵ＝上隣接ブロック内の
【数６】
2019537299.tif 000011
以下の幅を有するサブブロックの個数  を判定する。ここで、ｗｉｄｔｈ＝現在のブロックの幅である。
−ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔ＝（ｎｂＱｕａｒｔｅｒＷｉｄｔｈＳｕｂＣ＞０？１：０）      （２）を判定する。
【０１３０】
［0143］  式（２）によれば、２つの異なるコンテキストが、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ構文要素をコーディングするのに使用される。値ｎｂＱｕａｒｔｅｒＷｉｄｔｈＳｕｂＣＵが厳密に０を超える場合には、第１のコンテキスト（インデックス０を有する）が、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇに対応する２進シンボルを符号化するのに使用される。反対の場合において、値ｎｂＱｕａｒｔｅｒＷｉｄｔｈＳｕｂＣＵが０と等しい場合には、第２のコンテキスト（インデックス１を有する）が、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇに対応する２進シンボルを符号化するのに使用される。
【０１３１】
［0144］  上隣接ブロックは、現在のブロックの幅以上の幅を有し、その下境界が現在のブロックの上境界のｙ座標から１を減じたものと等しいｙ座標を有するブロックに対応する。上隣接ブロックは、幅方向で１つまたは複数のサブブロックに分割され得る。
【０１３２】
［0145］  別の実施形態によれば、非対称分割フラグｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇをコーディングするのに使用されるコンテキストは、それぞれ幅および高さにおいて現在のブロックのサイズの１／２以上のサイズを有する隣接ブロックの存在の関数として判定される。これは、以下の形をとる。第１に、要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇのコーディングをコーディングするのに使用されるコンテキストは、次のように判定される。
−現在のＣＵの左上角の左に配置されたブロックが、現在のブロックの高さの１／２を超える高さを有するかどうかを判定する。
−現在のＣＵの左下角の左側に配置されたブロックが、現在のブロックの高さの１／２を超える高さを有するかどうかを判定する。
−上記テストのうちの１つが肯定である場合には、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔに値０を与える。
−そうではない場合には、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔに値１を与える。
【０１３３】
［0146］  同様に、要素ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇのコーディングをコーディングするのに使用されるコンテキストは、次のように判定される。
−現在のＣＵの左上角の上に配置されたブロックが、現在のブロックの幅の１／２を超える幅を有するかどうかを判定する。
−現在のＣＵの右上角の上に配置されたブロックが、現在のブロックの幅の１／２を超える幅を有するかどうかを判定する。
−上記テストのうちの１つが肯定である場合には、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔに値０を与える。
−そうではない場合には、ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＣｔｘｔに値１を与える。
【０１３４】
［0147］  さらなる実施形態によれば、いくつかの別々のコンテキストが、スライス・タイプ（ＩＮＴＲＡまたはＩＮＴＥＲ）に従って、ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇをコーディング／復号するのに使用される。ＩＮＴＥＲスライス内では、上記のコンテキスト判定方法が使用される。ＩＮＴＲＡスライス内では、それぞれｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇに関して、これらのフラグをコーディング／復号する時に使用可能なコンテキスト的ブロック・サイズ情報にかかわりなく、単一のコンテキストが、これらの２つのフラグの統計的挙動を取り込むのに使用される。
【０１３５】
［0148］  この実施形態の利点は、特にＩＮＴＥＲスライスにおいて、コーディングされるフラグと隣接ブロック情報との間の統計的依存性をよりよくモデル化することであり、これは、これらのフラグのコーディングに関連するレート・コストを下げる。
【０１３６】
［0149］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数としてインデクシングされる。したがって、コンテキストの別々のセットが、ＣＴＵの四分木＋二分木表現内の深さレベルごとに使用される。有利なことに、より正確なコンテキストが、コーディング／復号される構文要素の統計的挙動をモデル化するのに使用される。
【０１３７】
［0150］  第３の実施形態では、２つの異なるコンテキストのセットが、構文要素ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇのコンテキスト適応コーディングを実行するのに使用される。したがって、コンテキストのセットは、次のように示される。
・ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．１］
・ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．１］
【０１３８】
［0151］  この実施形態では、コンテキストは、四分木＋二分木ＣＴＵ表現内の処理されるブロックの深さによってインデクシングされる。したがって、コンテキストの上記２つのセットは、深さレベルに基づいてさらにインデクシングされる。
・ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．．ｍａｘＤｅｐｔｈ］［０．．１］
・ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．．ｍａｘＤｅｐｔｈ］［０．．１］
ここで、ｍａｘＤｅｐｔｈは、ブロックの最大深さを表す。ここで、深さは、現在のブロックの四分木深さと二分木深さとの和を意味する。
【０１３９】
［0152］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、ブロックの形状すなわち幅および高さの関数としてインデクシングされる。これは、コンテキストの別々のセットが、可能なコーディング・サイズのタプル（ｗ，ｈ）ごとに使用されることを意味する。この実施形態の利点は、コーディング／復号される構文要素の統計的挙動をモデル化するためのさらに改善されたコンテキストである。有利なことに、より正確なコンテキストが、コーディング／復号される構文要素の統計的挙動をモデル化するのに使用される。
【０１４０】
［0153］  この実施形態では、コンテキストは、ブロックの幅のｌｏｇ２および高さのｌｏｇ２によってインデクシングされる。
・ｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．．ｍａｘＬｏｇ２ＣＵＨｅｉｇｈｔ］［０．．１］
・ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇＣｔｘ［０．．．ｍａｘＬｏｇ２ＣＵＷｉｄｔｈ］［０．．１］
ここで、ｍａｘＬｏｇ２ＣＵＷｉｄｔｈおよびｍａｘＬｏｇ２ＣＵＨｅｉｇｈｔは、２のべきと等しい最大の可能なブロック幅およびブロック高さのｌｏｇ２を表す。
【０１４１】
［0154］  非対称分割が、２のべきと等しいブロック・サイズだけに適用され得るので、コンテキストは、２のべきと等しいブロック・サイズに関連付けられる。
【０１４２】
［0155］  新しい構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、異なる形で符号化され得る。第１の実施形態では、ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ（それぞれ、ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ）は、ビットストリーム内の単一のビットを用いてコーディングされる。
【０１４３】
［0156］  これは、ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅ構文要素が等しい確率を有する場合に限って最適である。
【０１４４】
［0157］  別の実施形態によれば、コンテキストベースの算術コーディングが、構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅを符号化するのに使用される。この実施形態では、それぞれ各構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅに関連する２つの単純なコンテキストが使用される。これらのコンテキストのそれぞれは、関係する構文要素自体によって過去（たとえば、コーディング順で先行するブロックを符号化する時）にとられた値だけに依存する。このコンテキストベースのコーディングの変形形態では、ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅおよびｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅに使用されるコンテキストを、同一とすることができる。したがって、この２つの構文要素のコーディングは、同一のコンテキストを共有することができる。これは、ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅがＴＲＵＥまたはＦＡＬＳＥになり、現在のブロックが水平方位で非対称に二項分割されることを知る確率が、ｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅがＴＲＵＥまたはＦＡＬＳＥになり、現在のブロックが垂直方位で非対称に二項分割されることを知る確率に近いと仮定するならば、効率的であるはずである。
【０１４５】
［0158］  第３の実施形態では、これらの構文要素ｈｏｒｉｚｏｎｔａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅまたはｖｅｒｔｉｃａｌ＿ａｓｙｍｍｅｔｒｉｃ＿ｔｙｐｅは、図１６および図１７に示されているように、先行する隣接ブロック内で既に決定された分割構成に関するなんらかのコンテキスト情報の関数としてエントロピ・コーディングされる。水平非対称分割では、現在のブロックの左の以前のブロック内の分割フロンティア（図１６のＦ１）が、存在し、水平非対称分割の選択を介して現在のブロック内に現れるはずの水平フロンティアと空間的に一致する場合には、現在のブロック内でこの非対称分割を使用する確率が、高められる。
【０１４６】
［0159］  この原理が、図１６に示されている。この図の左側では、候補ＨＯＲ＿ＵＰ分割モードが、現在のブロック内で評価されつつあり、左の隣接ブロックは、分割されなかった。その場合の現在のブロックに関するＨＯＲ＿ＵＰ分割モードの使用の確率は、図１６の右側に示された場合より低い。実際に、この後者の場合には、隣接ブロックは、ＨＯＲ＿ＵＰ分割モードの選択によって現在のブロック内に伝搬されるはずの水平フロンティアを含む分割構成を用いて符号化された。現在のブロックでのＨＯＲ＿ＵＰ分割モードの選択は、図１６の左側に示された以前の場合より、この場合に発生する可能性がより高い。
【０１４７】
［0160］  この原理は、垂直非対称分割の場合において図１７にも示されている。ＶＥＲ＿ＲＩＧＨＴ分割モードは、図１７の左の場合よりも図１７の右に示された場合に現在のブロックを符号化するのに使用されることのより高い確率を有する。というのは、右の場合が、垂直フロンティアＦ２を、現在のブロックの上に配置された隣接ブロックから現在のブロックに伝搬させるからである。
【０１４８】
［0161］  この原理に基づいて、以下のコンテキストが、構文要素
【数７】
2019537299.tif 000012
をコーディングし、復号するのに使用される。
・ＨＯＲ＿ＵＰ非対称タイプから生じるフロンティアに整列された左隣接ブロック内のフロンティアがあるかどうかを判定する。結果に応じて、
【数８】
2019537299.tif 000013
に真または偽をセットする。
・ＨＯＲ＿ＤＯＷＮ非対称タイプから生じるフロンティアに整列された左隣接ブロック内のフロンティアがあるかどうかを判定する。結果に応じて、
【数９】
2019537299.tif 000014
に真または偽をセットする。
・以下のように、値（０、１、２）の中でコンテキスト・インデックスを判定する。
【数１０】
2019537299.tif 000015
（３）
【０１４９】
式（３）によれば、３つの異なるコンテキストが、
【数１１】
2019537299.tif 000016
構文要素をコーディングするのに使用される。値
【数１２】
2019537299.tif 000017
がＴＲＵＥと等しい場合には、第１のコンテキスト（インデックス１を有する）が、
【数１３】
2019537299.tif 000018
に対応する２進シンボルを符号化するのに使用される。反対の場合において、値
【数１４】
2019537299.tif 000019
がＴＲＵＥと等しい場合には、第２のコンテキスト（インデックス２を有する）が、
【数１５】
2019537299.tif 000020
に対応する２進シンボルを符号化するのに使用される。最後に、値
【数１６】
2019537299.tif 000021
と
【数１７】
2019537299.tif 000022
との両方がＦＡＬＳＥと等しい場合には、第３のコンテキスト（インデックス０を有する）が、
【数１８】
2019537299.tif 000023
に対応する２進シンボルを符号化するのに使用される。
【０１５０】
以下のコンテキストが、構文要素
【数１９】
2019537299.tif 000024
をコーディングし、復号するのに使用される。
・ＶＥＲ＿ＬＥＦＴ非対称タイプから生じるフロンティアに整列された上隣接ブロック内のフロンティアがあるかどうかを判定する。結果に応じて、
【数２０】
2019537299.tif 000025
に真または偽をセットする。
・ＶＥＲ＿ＲＩＧＨＴ非対称タイプから生じるフロンティアに整列された上隣接ブロック内のフロンティアがあるかどうかを判定する。結果に応じて、
【数２１】
2019537299.tif 000026
に真または偽をセットする。
・以下のように、値（０、１、２）の中でコンテキスト・インデックスを計算する。
【数２２】
2019537299.tif 000027
（４）
【０１５１】
式（３）によれば、３つの異なるコンテキストが、
【数２３】
2019537299.tif 000028
構文要素のコーディングに使用される。値
【数２４】
2019537299.tif 000029
がＴＲＵＥと等しい場合には、第１のコンテキスト（インデックス１を有する）が、
【数２５】
2019537299.tif 000030
に対応する２進シンボルを符号化するのに使用される。反対の場合において、値
【数２６】
2019537299.tif 000031
がＴＲＵＥと等しい場合には、第２のコンテキスト（インデックス２を有する）が、
【数２７】
2019537299.tif 000032
に対応する２進シンボルを符号化するのに使用される。最後に、値
【数２８】
2019537299.tif 000033
と
【数２９】
2019537299.tif 000034
との両方がＦＡＬＳＥと等しい場合には、第３のコンテキスト（インデックス０を有する）が、
【数３０】
2019537299.tif 000035
に対応する２進シンボルを符号化するのに使用される。
【０１５２】
別の実施形態によれば、構文要素
【数３１】
2019537299.tif 000036
または
【数３２】
2019537299.tif 000037
のコーディングは、それぞれ以下のように判定されるコンテキストを使用する。まず、フラグ
【数３３】
2019537299.tif 000038
をコーディングするのに使用されるコンテキスト
【数３４】
2019537299.tif 000039
は、以下のように判定される。
−現在のブロックの左上角の左側に配置されたブロックの高さを入手する。これは、値ｔｏｐＬｅｆｔＨｅｉｇｈｔを与える。
−現在のブロックの左下角の左側に配置されたブロックの高さを入手する。これは、値ｂｏｔｔｏｍＬｅｆｔＨｅｉｇｈｔを与える。
−ｔｏｐＬｅｆｔＨｅｉｇｈｔがｂｏｔｔｏｍＬｅｆｔＨｅｉｇｈｔと等しい場合には、
【数３５】
2019537299.tif 000040
に値０を与える。
−そうではなく、ｔｏｐＬｅｆｔＨｅｉｇｈｔ＜ｂｏｔｔｏｍＬｅｆｔＨｅｉｇｈｔである場合には、
【数３６】
2019537299.tif 000041
に値１を与える。
−そうではない場合（ｔｏｐＬｅｆｔＨｅｉｇｈｔ＞ｂｏｔｔｏｍＬｅｆｔＨｅｉｇｈｔの場合）には、
【数３７】
2019537299.tif 000042
に値２を与える。
したがって、３つのコンテキストが、フラグ
【数３８】
2019537299.tif 000043
をコーディング／復号するのに使用される。
【０１５３】
第２に、フラグ
【数３９】
2019537299.tif 000044
をコーディングするのに使用されるコンテキスト
【数４０】
2019537299.tif 000045
は、以下のように判定される。
−現在のブロックの左上角の上に配置されたブロックの幅を入手する。これは、値ｔｏｐＬｅｆｔＷｉｄｔｈを与える。
−現在のブロックの右上角の上に配置されたブロックの幅を入手する。これは、値ｔｏｐＲｉｇｈｔＷｉｄｔｈを与える。
−ｔｏｐＬｅｆｔＷｉｄｔｈがｔｏｐＲｉｇｈｔＷｉｄｔｈと等しい場合には、
【数４１】
2019537299.tif 000046
に値０を与える。
−そうではなく、ｔｏｐＬｅｆｔＷｉｄｔｈ＞ｔｏｐＲｉｇｈｔＷｉｄｔｈである場合には、
【数４２】
2019537299.tif 000047
に値１を与える。
−そうではない場合（ｔｏｐＬｅｆｔＷｉｄｔｈ＜ｔｏｐＲｉｇｈｔＷｉｄｔｈの場合）には、
【数４３】
2019537299.tif 000048
に値２を与える。
したがって、３つのコンテキストが、フラグ
【数４４】
2019537299.tif 000049
をコーディング／復号するのに使用される。
【０１５４】
さらなる実施形態によれば、いくつかの別々のコンテキストが、スライス・タイプ（ＩＮＴＲＡまたはＩＮＴＥＲ）に従って
【数４５】
2019537299.tif 000050
および
【数４６】
2019537299.tif 000051
をコーディング／復号するのに使用される。ＩＮＴＥＲスライス内では、上記のコンテキスト判定方法が使用される。ＩＮＴＲＡスライス内では、それぞれフラグ
【数４７】
2019537299.tif 000052
および
【数４８】
2019537299.tif 000053
に関して、これらのフラグをコーディング／復号する時に使用可能なコンテキスト的ブロック・サイズ情報にかかわりなく、単一のコンテキストが、これらの２つのフラグの統計的挙動を取り込むのに使用される。
【０１５５】
［0162］  この実施形態の利点は、特にＩＮＴＥＲスライスにおいて、コーディングされるフラグと隣接ブロック情報との間の統計的依存性をよりよくモデル化することであり、これは、これらのフラグのコーディングに関連するレート・コストを下げる。
【０１５６】
［0163］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、現在のブロックに関連する四分木＋二分木の深さ値の関数としてインデクシングされる。これは、コンテキストの別々のセットが、ＣＴＵの四分木＋二分木表現内の深さレベルごとに使用されることを意味する。ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ構文要素に関して定義されたものと同一の原理があてはまる。この実施形態の利点は、コーディング／復号される構文要素の統計的挙動をモデル化するのに使用される、より正確なコンテキストである。
【０１５７】
［0164］  さらなる実施形態によれば、先行する実施形態のうちの１つで提案されるコンテキストは、コーディング・ユニットの形状すなわち幅および高さの関数としてインデクシングされる。これは、コンテキストの別々のセットが、可能なコーディング・サイズのタプル（ｗ，ｈ）ごとに使用されることを意味する。ｖｅｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇおよびｈｏｒＡｓｙｍｍｅｔｒｉｃＳｐｌｉｔＦｌａｇ構文要素に関して定義されたものと同一の原理があてはまる。この実施形態の利点は、コーディング／復号される構文要素の統計的挙動をモデル化するためのさらに改善されたコンテキストである。
【０１５８】
表１および表２の構文の変形形態
［0165］  表１および表２で定義された構文の変形形態が、表３に示されている。これは、以下を含む。
−現在のブロックに関して、これを親ブロックの非対称サブブロックを形成するために隣接ブロックと空間的に合併できるかどうかを識別すること。親ブロックは、現在のブロックの親ブロック（ケース１）または現在のブロックの親の親ブロック（ケース２）とすることができる。このステップは、符号器側および復号器側で同一の形で実行される。
【０１５９】
［0166］  ケース１の例を、図１８の最上部に示す。この図では、灰色で塗り潰された上サブブロックは、現在のブロックの親の非対称部分を形成するために、次のサブブロックと合併され得る。
【０１６０】
［0167］  ケース２の例を、図１８の底部に示す。現在のブロックは、灰色で塗り潰されたブロックである。この図では、現在のブロックは、図１８でＣＵ’と呼ばれるブロックの非対称部分を形成するために次のサブブロック（図１８ではｎｅｘｔＳｕｂＣＵと命名される）と合併され得る。
−サイズ３・２nを有する非対称ブロックを形成するために、現在のブロックに関して、これが処理順で次のブロックと合併されるかどうかを示す、ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵと呼ばれる構文要素をコーディングする。
【０１６１】
［0168］  初期ＱＴＢＴコーディング構文に対する最小限の変更を伴ってこの実施形態をサポートするために、ＱＴＢＴ構文は、二分木および二項分割モードのコーディングに関して変更されない。
【表３】
2019537299.tif 000054
表３
【０１６２】
［0169］  「ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵ＿ｆｌａｇ」と呼ばれる新しい構文要素が、ブロックが分割されない時にブロック・コーディングの前に導入される。このフラグは、関係するブロックが、ビットストリームのこの段階ではまだ符号化されていないが、スキャン順で次のブロックと合併されることを示す。これは、現在の二項分割方位に応じて
【数４９】
2019537299.tif 000055
または
【数５０】
2019537299.tif 000056
と等しいサイズを有する非対称ブロックを形成することを可能にする。
【０１６３】
［0170］  この実施形態の利点は、非対称コーディング・ユニットをサポートするのに必要なＱＴＢＴ構文変更の量を大幅に減らすことである。
【０１６４】
［0171］  図１８に関して開示されるこの実施形態は、復号器側にもあてはまる。この場合には、構文要素ｍｅｒｇｅ＿ｗｉｔｈ＿ｎｅｘｔ＿ＣＵ＿ｆｌａｇが、非対称ブロックを回復するために復号される。
【０１６５】
［0172］  本明細書で説明される実施態様は、たとえば、方法もしくはプロセス、装置、ソフトウェア・プログラム、データ・ストリーム、または信号内で実施され得る。単一の形の実施態様の文脈でのみ議論される（たとえば、方法またはデバイスとしてのみ議論される）場合であっても、議論される特徴の実施態様は、他の形（たとえば、プログラム）でも実施され得る。装置は、たとえば、適当なハードウェア、ソフトウェア、およびファームウェアで実施され得る。方法は、たとえば、たとえばコンピュータ、マイクロプロセッサ、集積回路、またはプログラマブル論理デバイスを含む処理デバイス全般を指す、たとえばプロセッサなどの装置内で実施され得る。プロセッサは、たとえば、コンピュータ、セル電話機、ポータブル／携帯情報端末（「ＰＤＡ」）、およびエンドユーザの間の情報の通信を容易にする他のデバイスなどの通信デバイスをも含む。
【０１６６】
［0173］  本明細書で説明される様々なプロセスおよび特徴の実施態様は、様々な異なる機器またはアプリケーション、特に、たとえば機器またはアプリケーション内で実施され得る。そのような機器の例は、符号器、復号器、復号器からの出力を処理するポストプロセッサ、符号器への入力を供給するプリプロセッサ、ビデオ・コーダ、ビデオ復号器、ビデオ・コーダ、ウェブ・サーバ、セット・トップ・ボックス、ラップトップ、パーソナル・コンピュータ、セル電話機、ＰＤＡ、および他の通信デバイスを含む。明瞭であるとおり、機器は、モバイルとすることができ、移動車両内に設置されることすら可能である。
【０１６７】
［0174］  さらに、方法は、プロセッサによって実行される命令によって実施され得、そのような命令（および／または実施態様によって作られるデータ値）は、たとえば、集積回路、ソフトウェア担体、またはたとえばハード・ディスク、コンパクト・ディスケット（「ＣＤ」）、光ディスク（たとえば、しばしばデジタル多用途ディスクまたはデジタル・ビデオ・ディスクと呼ばれるＤＶＤ）、ランダム・アクセス・メモリ（「ＲＡＭ」）、または読取専用メモリ（「ＲＯＭ」）などの他のストレージ・デバイスなどのプロセッサ可読媒体上に記憶され得る。命令は、プロセッサ可読媒体上で有形に実施されるアプリケーション・プログラムを形成することができる。命令は、たとえば、ハードウェア内、ファームウェア内、ソフトウェア内、またはその組合せ内にあるものとすることができる。命令は、たとえば、オペレーティング・システム内、別々のアプリケーション内、またはこの２つの組合せ内に見出され得る。したがって、プロセッサは、たとえば、プロセスを実行するように構成されたデバイスと、プロセスを実行するための命令を有するプロセッサ可読媒体（ストレージ・デバイスなど）を含むデバイスとの両方として特徴を表され得る。さらに、プロセッサ可読媒体は、命令に加えてまたはその代わりに、実施態様によって作られたデータ値を記憶することができる。
【０１６８】
［0175］  当業者に明白であるとおり、実施態様は、たとえば記憶されまたは伝送され得る情報を担持するようにフォーマットされた様々な信号を作ることができる。情報は、たとえば、方法を実行するための命令または説明された実施態様のうちの１つによって作られるデータを含むことができる。たとえば、信号は、説明される実施形態の構文を書き込みまたは読み取るためのルールをデータとして担持し、または説明される実施形態によって書き込まれる実際の構文値をデータとして担持するようにフォーマットされ得る。そのような信号は、たとえば、電磁波（たとえば、スペクトルのラジオ周波数部分を使用する）またはベースバンド信号としてフォーマットされ得る。フォーマッティングは、たとえば、データ・ストリームを符号化することと、符号化されたデータ・ストリームを用いて搬送波を変調することとを含むことができる。信号が担持する情報は、たとえば、アナログ情報またはデジタル情報とすることができる。信号は、既知のとおり、様々な異なる有線リンクまたは無線リンクを介して伝送され得る。信号は、プロセッサ可読媒体上に記憶され得る。
【０１６９】
［0176］  複数の実施態様を説明した。それでも、様々な変更を行うことができることを理解されたい。たとえば、他の実施態様を作るために、異なる実施態様の要素を組み合わせ、補足し、変更し、または除去することができる。さらに、当業者は、他の構造およびプロセスを開示された構造およびプロセスと置換することができ、結果の実施態様が、少なくとも実質的に開示される実施態様と同一の結果（１つまたは複数）を達成するために、少なくとも実質的に同一の形（１つまたは複数）で、少なくとも実質的に同一の機能（１つまたは複数）を実行することを理解するであろう。したがって、上記および他の実施態様が、本願によって企図されている。
【図１】
2019537299.tif 000057
【図２】
2019537299.tif 000058
【図３】
2019537299.tif 000059
【図４】
2019537299.tif 000060
【図５】
2019537299.tif 000061
【図６】
2019537299.tif 000062
【図７】
2019537299.tif 000063
【図８】
2019537299.tif 000064
【図９】
2019537299.tif 000065
【図１０】
2019537299.tif 000066
【図１１】
2019537299.tif 000067
【図１２】
2019537299.tif 000068
【図１３】
2019537299.tif 000069
【図１４】
2019537299.tif 000070
【図１５】
2019537299.tif 000071
【図１６】
2019537299.tif 000072
【図１７】
2019537299.tif 000073
【図１８】
2019537299.tif 000074
【国際調査報告】
2019537299.tif 000075
2019537299.tif 000076