(57)【要約】  本発明では、映像のデコーディングを行う方法およびこのための装置が開示される。具体的には、映像をデコードする方法であって、現コーディングツリーブロックが現ピクチャの境界を外れる場合、上記現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、上記現コーディングツリーブロックを複数のコーディングブロックに分割するステップと、現コーディングブロックが予め設定された条件を満たす場合、上記現コーディングブロックが複数のサブブロックに分割されるか否かを指示するシンタックス要素（syntax element）をパージングするステップと、上記シンタックス要素に基づいて上記現コーディングブロックの分割モード（split mode）を決定するステップと、を有することができる。【選択図】図１９
2021519035.tif 000002
【特許請求の範囲】
【請求項１】
映像をデコードする方法であって、
現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、前記現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップと、
現コーディングブロックが予め設定された条件を満たす場合、前記現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングするステップと、
前記第１のシンタックス要素が前記現コーディングブロックが分割されることを指示する場合、前記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングするステップと、
前記第２のシンタックス要素が前記現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、前記現コーディングブロックが、二分木（binary-tree）構造を利用して分割されるか、または三分木（ternary-tree）構造を利用して分割されるか、を指示する第３のシンタックス要素と、前記現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングするステップと、
前記第１のシンタックス要素、前記第２のシンタックス要素、前記第３のシンタックス要素、および前記第４のシンタックス要素のうちの少なくとも１つに基づいて前記現コーディングブロックの分割モード（split mode）を決定するステップと、を有する、映像のデコード方法。
【請求項２】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割することにより行われ、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に属する領域を表す、請求項１に記載の映像のデコード方法。
【請求項３】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロックが前記現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否かを指示する第５のシンタックス要素をパージングするステップをさらに有し、
前記第５のシンタックス要素が前記四分木分割が許容されないことを指示する場合、前記現コーディングツリーブロックは、前記二分木構造または前記三分木構造を利用して複数のコーディングブロックに分割される、請求項１に記載の映像のデコード方法。
【請求項４】
前記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされる、請求項３に記載の映像のデコード方法。
【請求項５】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記四分木構造を利用して複数のコーディングブロックに分割することにより行われ、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に属する領域を表す、請求項１に記載の映像のデコード方法。
【請求項６】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記有効な領域の幅（width）が最大変換サイズより大きいか、または前記有効な領域の高さ（height）が前記最大変換サイズより大きい場合、前記現コーディングツリーブロックを前記四分木構造を利用してコーディングブロックに分割することにより行われる、請求項５に記載の映像のデコード方法。
【請求項７】
映像をデコードする装置であって、
現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、前記現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、前記現コーディングツリーブロックを複数のコーディングブロックに分割するコーディングツリーブロック分割部と、
現コーディングブロックが予め設定された条件を満たす場合、前記現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングし、
前記第１のシンタックス要素が前記現コーディングブロックが分割されることを指示する場合、前記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングし、
前記第２のシンタックス要素が前記現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、前記現コーディングブロックが、二分木（binary-tree）構造を利用して分割されるか、または三分木（ternary-tree）構造を利用して分割されるか、を指示する第３のシンタックス要素と、前記現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングするシンタックス要素パージング部と、
前記第１のシンタックス要素、前記第２のシンタックス要素、前記第３のシンタックス要素、および前記第４のシンタックス要素のうちの少なくとも１つに基づいて前記現コーディングブロックの分割モード（split mode）を決定する分割モード決定部と、を備える、映像のデコード装置。
【請求項８】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割し、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に属する領域を表す、請求項７に記載の映像のデコード装置。
【請求項９】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否かを指示する第５のシンタックス要素をパージングし、
前記第５のシンタックス要素が前記四分木分割が許容されないことを指示する場合、前記現コーディングツリーブロックは、前記二分木構造または前記三分木構造を利用して複数のコーディングブロックに分割される、請求項７に記載の映像のデコード装置。
【請求項１０】
前記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされる、請求項９に記載の映像のデコード装置。
【請求項１１】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記四分木構造を利用して複数のコーディングブロックに分割し、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に属する領域を表す、請求項７に記載の映像のデコード装置。
【請求項１２】
前記コーディングツリーブロック分割部は、
前記有効な領域の幅（width）が最大変換サイズより大きいか、または前記有効な領域の高さ（height）が前記最大変換サイズより大きい場合、前記現コーディングツリーブロックを前記四分木構造を利用してコーディングブロックに分割する、請求項１１に記載の映像のデコード装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、静止画または動画の処理方法に関し、より詳細には、エンコーディング（符号化）／デコーディング（復号）が行われるブロック分割構造を決定する方法、およびこれをサポート（支援）する装置に関する。
【背景技術】
【０００２】
圧縮符号化とは、デジタル化した情報を通信回線を介して送信するか、記憶（保存）媒体に適した形態で記憶するための一連の信号処理技術を意味する。映像、イメージ、音声などのメディアが圧縮符号化の対象になり得、特に、映像を対象に圧縮符号化を行う技術をビデオ映像圧縮と称する。
【０００３】
次世代ビデオコンテンツは、高解像度（high spatial resolution）、高フレームレート（率）（high frame rate）、および映像表現の高次元化（high dimensionality of scene representation）という特徴を有するようになるはずである。そのようなコンテンツを処理するためには、メモリストレージ（memory storage）、メモリアクセスレート（率）（memory access rate）、および処理電力（processing power）の側面で大幅な増加をもたらすであろう。
【０００４】
したがって、次世代ビデオコンテンツをより効率的に処理するためのコーディングツールをデザインする必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、ＱＴＢＴ構造でブロック分割を行うにおいて、ブロック分割を効率的に調整する方法を提案することである。
【０００６】
本発明においてなそうとする技術的課題は、以上で言及した技術的課題に制限されず、言及していないさらに他の技術的課題は、下記の記載から本発明の属する技術分野における通常の知識を有する者に明確に理解され得るであろう。
【課題を解決するための手段】
【０００７】
本発明の一態様は、映像をデコードする方法であって、現（現在）コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、現コーディングツリーブロックを複数のコーディングブロックに分割するステップと、現コーディングブロックが予め設定された条件を満たす場合、現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングするステップと、第１のシンタックス要素が現コーディングブロックが分割されることを指示する場合、現コーディングブロックが四分木（クアッドツリー）（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングするステップと、第２のシンタックス要素が現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、現コーディングブロックが、二分木（バイナリツリー）（binary-tree）構造を利用して分割されるか、または三分木（ターナリーツリー）（ternary-tree）構造を利用して分割されるか、を指示する第３のシンタックス要素と、現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングするステップと、第１のシンタックス要素、第２のシンタックス要素、第３のシンタックス要素、および第４のシンタックス要素のうちの少なくとも１つに基づいて現コーディングブロックの分割モード（split mode）を決定するステップと、を有することができる。
【０００８】
望ましくは、現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、現コーディングツリーブロック内の有効な領域（valid region）に達するまで、現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割することにより行われ、ここで、有効な領域は、現コーディングツリーブロック内で現ピクチャの境界内に属する領域を表すことができる。
【０００９】
望ましくは、現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否か（の許容可否）を指示する第５のシンタックス要素をパージングするステップをさらに有し、第５のシンタックス要素が四分木分割が許容されないことを指示する場合、現コーディングツリーブロックは、二分木構造または三分木構造を利用して複数のコーディングブロックに分割されることができる。
【００１０】
望ましくは、第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（抽象階層）（Network Abstract Layer）ユニットのヘッダを介してシグナリングされることができる。
【００１１】
望ましくは、現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、現コーディングツリーブロック内の有効な領域（valid region）に達するまで、現コーディングツリーブロックを四分木構造を利用して複数のコーディングブロックに分割することにより行われ、ここで、有効な領域は、現コーディングツリーブロック内で現ピクチャの境界内に属する領域を表すことができる。
【００１２】
望ましくは、現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、有効な領域の幅（width）が最大変換サイズより大きいか、または有効な領域の高さ（height）が最大変換サイズより大きい場合、現コーディングツリーブロックを四分木構造を利用してコーディングブロックに分割することにより行われることができる。
【００１３】
本発明の他の一態様は、映像をデコードする装置であって、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、現コーディングツリーブロックを複数のコーディングブロックに分割するコーディングツリーブロック分割部と、現コーディングブロックが予め設定された条件を満たす場合、現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングし、第１のシンタックス要素が現コーディングブロックが分割されることを指示する場合、現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングし、第２のシンタックス要素が現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、現コーディングブロックが、二分木（binary-tree）構造を利用して分割されるか、または三分木（ternary-tree）構造を利用して分割されるか、を指示する第３のシンタックス要素と、現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングするシンタックス要素パージング部と、第１のシンタックス要素、第２のシンタックス要素、第３のシンタックス要素、および第４のシンタックス要素のうちの少なくとも１つに基づいて現コーディングブロックの分割モード（split mode）を決定する分割モード決定部と、を備えることができる。
【００１４】
望ましくは、コーディングツリーブロック分割部は、現コーディングツリーブロック内の有効な領域（valid region）に達するまで、現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割し、ここで、有効な領域は、現コーディングツリーブロック内で現ピクチャの境界内に属する領域を表すことができる。
【００１５】
望ましくは、コーディングツリーブロック分割部は、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否かを指示する第５のシンタックス要素をパージングし、第５のシンタックス要素が四分木分割が許容されないことを指示する場合、現コーディングツリーブロックは、二分木構造または三分木構造を利用して複数のコーディングブロックに分割されることができる。
【００１６】
望ましくは、第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされることができる。
【００１７】
望ましくは、コーディングツリーブロック分割部は、現コーディングツリーブロック内の有効な領域（valid region）に達するまで、現コーディングツリーブロックを四分木構造を利用して複数のコーディングブロックに分割し、ここで、有効な領域は、現コーディングツリーブロック内で現ピクチャの境界内に属する領域を表すことができる。
【００１８】
望ましくは、コーディングツリーブロック分割部は、有効な領域の幅（width）が最大変換サイズより大きいか、または有効な領域の高さ（height）が最大変換サイズより大きい場合、現コーディングツリーブロックを四分木構造を利用してコーディングブロックに分割することができる。
【発明の効果】
【００１９】
本発明の実施形態によれば、効果的にＱＴＢＴ分割構造を決定し、関連情報をシグナリングすることで、圧縮性能を向上させることができる。
【００２０】
また、本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【００２１】
本発明において得ることができる効果は、以上で言及した効果に制限されず、言及していないさらに他の効果は、下記の記載から本発明の属する技術分野における通常の知識を有する者に明確に理解され得るであろう。
【図面の簡単な説明】
【００２２】
【図１】本発明が適用される実施形態であって、ビデオ／イメージ信号のエンコーディングが行われるエンコード装置の概略ブロック図である。
【図２】本発明が適用される実施形態であって、ビデオ／イメージ信号のデコーディングが行われるデコード装置の概略ブロック図である。
【図３】本発明が適用され得る実施形態であって、マルチタイプツリー構造の一例を示す図である。
【図４】本発明が適用され得る実施形態であって、マルチタイプツリーを伴う四分木（quadtree with nested multi-type tree）構造のパーティション分割情報のシグナリングメカニズムを例示する図である。
【図５】本発明が適用され得る実施形態であって、四分木および伴われるマルチタイプツリー（quadtree and nested multi-type tree）構造に基づいて（を基盤に）ＣＴＵをマルチ（多重）ＣＵに分割する方法を例示する図である。
【図６】本発明が適用され得る実施形態であって、三分木（ternary-tree）分割を制限する方法を例示する図である。
【図７】本発明が適用される一実施形態であって、四分木（quad-tree）に基づくブロック分割構造を例示する図である。
【図８】本発明が適用される一実施形態であって、二分木（binary-tree）に基づくブロック分割構造を例示する図である。
【図９】本発明が適用される一実施形態であって、三分木（ternary-tree）に基づくブロック分割構造を例示する図である。
【図１０】本発明が適用される一実施形態であって、二分木（binary-tree）、三分木（ternary-tree）、およびストライプツリー（stripe tree）構造に基づくブロック分割構造を例示する図である。
【図１１】本発明が適用される一実施形態であって、正方形ブロックのブロック分割構造を例示する図である。
【図１２】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１３】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１４】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１５】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１６】本発明が適用される一実施形態であって、正方形ブロックのブロック分割構造を例示する図である。
【図１７】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１８】本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【図１９】本発明が適用される一実施形態であって、映像の境界をＣＴＵ（Coding Tree Unit）が外れる場合を例示する図である。
【図２０】本発明が適用される一実施形態であって、非対称ツリー（asymmetric-tree）に基づくブロック分割構造を例示する図である。
【図２１】本発明が適用され得る一実施形態に係るブロック分割の例を示す図である。
【図２２】本発明が適用され得る一実施形態に係るブロック分割の例を示す図である。
【図２３】本発明が適用され得る一実施形態に係るブロック分割の例を示す図である。
【図２４】本発明が適用される一実施形態であって、シンタックスシグナリングなしで最大変換ブロックサイズに基づいてブロック分割が許容されるか否かを決定する方法を例示する図である。
【図２５】本発明が適用される実施形態に係るビデオ信号のデコード方法を例示するフローチャートである。
【図２６】本発明が適用される実施形態に係るビデオ信号のデコード装置を例示する図である。
【図２７】本発明が適用されるビデオコーディングシステムを示す図である。
【図２８】本発明が適用される実施形態であって、コンテンツストリーミングシステム構造図である。
【発明を実施するための形態】
【００２３】
本発明に関する理解を助けるために、詳細な説明の一部として含まれる添付図面は、本発明に対する実施形態を提供し、詳細な説明とともに本発明の技術的特徴を説明する。
【００２４】
以下、本発明による好ましい実施形態を添付図を参照して詳細に説明する。添付図と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明しようとするものであり、本発明が実施され得る唯一の実施形態を示そうとするものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかしながら、当業者は、本発明がこのような具体的な細部事項がなくても実施され得ることを知る。
【００２５】
いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造および装置は省略されるか、各構造および装置の中核機能を中心としたブロック図の形式で示し得る。
【００２６】
また、本発明で使用される用語は、できる限り現在広く使用される一般的な用語を選択しているが、特定の場合は、出願人が任意に選定した用語を使用して説明する。そのような場合には、該当部分の詳細な説明でその意味を明確に記載するので、本発明の説明で使用された用語の名称だけで単純に解釈されてはならず、その該当用語の意味まで把握して解釈されるべきであることを明らかにしておく。
【００２７】
以下の説明で使用される特定用語は、本発明の理解を助けるために提供されたものであり、このような特定用語の使用は、本発明の技術的思想を外れない範囲で他の形態に変更され得る。例えば、信号、データ、サンプル、ピクチャ、フレーム、ブロックなどの場合、各コーディング過程で適切に代替して解釈され得る。
【００２８】
以下、本発明における「処理ユニット」は、予測、変換および／または量子化などのエンコーディング／デコーディングの処理過程が行われる単位を意味する。以下、説明の便宜のために、処理ユニットは、「処理ブロック」または「ブロック」と称されてもよい。
【００２９】
処理ユニットは、輝度（luma）成分に対する単位と色差（chroma）成分に対する単位とを含む意味と解釈され得る。例えば、処理ユニットは、コーディングツリー（符号化木）ユニット（ＣＴＵ：Coding Tree Unit）、コーディングユニット（ＣＵ：Coding Unit）、予測ユニット（ＰＵ：Prediction Unit）または変換ユニット（ＴＵ：Transform Unit）に該当し得る。
【００３０】
また、処理ユニットは、輝度（luma）成分に対する単位または色差（chroma）成分に対する単位として解釈され得る。例えば、処理ユニットは、輝度（luma）成分に対するコーディングツリーブロック（ＣＴＢ：Coding Tree Block）、コーティングブロック（ＣＢ：Coding Block）、予測ブロック（ＰＵ：Prediction Block）または変換ブロック（ＴＢ：Transform Block）に該当し得る。あるいは、色差（chroma）成分に対するコーディングツリーブロック（ＣＴＢ）、コーティングブロック（ＣＢ）、予測ブロック（ＰＵ）または変換ブロック（ＴＢ）に該当し得る。また、これに限定されるわけではなく、処理ユニットは、輝度（luma）成分に対する単位と色差（chroma）成分に対する単位とを含む意味で解釈されることもある。
【００３１】
また、処理ユニットは、必ずしも正方形のブロックに限定されるわけではなく、３つ以上の頂点を有する多角形の形態で構成されることもある。
【００３２】
また、以下、本明細書でピクセルまたは画素などをサンプルと総称（通称）する。そして、サンプルを利用するというのは、ピクセル値または画素値などを利用することを意味し得る。
【００３３】
図１は、本発明が適用される実施例であって、ビデオ／イメージ信号のエンコーディングが行われるエンコード装置の概略ブロック図を示す。
【００３４】
図１を参照すると、エンコード装置１００は、映像分割部１１０、減算部１１５、変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０、加算部１５５、フィルタリング部１６０、メモリ１７０、インター予測部１８０、イントラ予測部１８５、およびエントロピ符号化部１９０を含んで構成されることができる。インター予測部１８０およびイントラ予測部１８５は予測部と総称され得る。言い換えると、予測部は、インター予測部１８０およびイントラ予測部１８５を含み得る。変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０は、残差（residual）処理部に含まれ得る。残差処理部は、減算部１１５をさらに含んでもよい。一実施例として、前述した映像分割部１１０、減算部１１５、変換部１２０、量子化部１３０、逆量子化部１４０、逆変換部１５０、加算部１５５、フィルタリング部１６０、インター予測部１８０、イントラ予測部１８５、およびエントロピ符号化部１９０は、１つのハードウェアコンポーネント（例えば、エンコーダまたはプロセッサ）によって構成され得る。また、メモリ１７０は、ＤＰＢ（Decoded Picture Buffer）を含んでもよく、デジタル記憶媒体によって構成されてもよい。
【００３５】
映像分割部１１０は、エンコード装置１００に入力された入力映像（または、ピクチャ、フレーム）を１つまたは複数の処理ユニット（processing unit）に分割することができる。一例として、上記処理ユニットは、コーディングユニット（Coding Unit、ＣＵ）と呼ばれることがある。この場合、コーディングユニットは、コーディングツリーユニット（Coding Tree Unit、ＣＴＵ）または最大コーディングユニット（Largest Coding Unit、ＬＣＵ）から、ＱＴＢＴ（Quad-Tree Binary-Tree）構造に応じて、再帰的に（recursively）分割されることができる。例えば、１つのコーディングユニットは、四分木構造、および／または二分木構造に基づいて、下位デプスの（deeper）複数のコーディングユニットに分割されることができる。この場合、例えば、四分木構造が先に適用され、二分木構造が後に適用され得る。あるいは、二分木構造が先に適用されることもある。それ以上分割されない最終コーディングユニットに基づいて、本発明によるコーディング手続が行われる。この場合、映像の特性によるコーディング効率などに基づいて、最大コーディングユニットが直ぐに最終コーディングユニットとして使用され得、あるいは必要に応じて、コーディングユニットは、再帰的に（recursively）より下位デプスのコーディングユニットに分割され、最適なサイズのコーディングユニットが最終コーディングユニットとして使用され得る。ここで、コーディング手続とは、後述する予測、変換、および復元などの手続を含み得る。別の例として、上記処理ユニットは、予測ユニット（ＰＵ：Prediction Unit）または変換ユニット（ＴＵ：Transform Unit）をさらに含み得る。この場合、上記予測ユニットおよび上記変換ユニットは、それぞれ前述した最終コーディングユニットから分割またはパーティショニングされ得る。上記予測ユニットは、サンプル予測の単位であってもよく、上記変換ユニットは、変換係数を導出する単位および／または変換係数から残差信号（residual signal）を導出する単位であってもよい。
【００３６】
ユニットは、場合に応じて、ブロック（block）または領域（area）などの用語と混用してもよい。一般的な場合、Ｍ×Ｎのブロックは、Ｍ個の列とＮ個の行とからなるサンプルまたは変換係数（transform coefficient）の集合を示し得る。サンプルは、一般的にピクセルまたはピクセルの値を示してもよく、輝度（luma）成分のピクセル／ピクセル値のみを示してもよく、彩度（chroma）成分のピクセル／ピクセル値のみを示してもよい。サンプルは、１つのピクチャ（または映像）をピクセル（pixel）またはペル（pel）に対応する用語として使用され得る。
【００３７】
エンコード装置１００は、入力映像信号（オリジナル（原本）ブロック、オリジナルサンプルアレイ）から、インター予測部１８０またはイントラ予測部１８５から出力された予測信号（予測されたブロック、予測サンプルアレイ）を減算して残差信号（residual signal、残差（残余）ブロック、残差サンプルアレイ）を生成することができ、生成された残差信号は、変換部１２０へ送信される。この場合、図示されたように、エンコーダ１００内で入力映像信号（オリジナルブロック、オリジナルサンプルアレイ）から予測信号（予測ブロック、予測サンプルアレイ）を減算するユニットは、減算部１１５と呼ばれることがある。予測部は、処理対象のブロック（以下、現ブロックという）に対する予測を行い、上記現ブロックに対する予測サンプルを含む予測されたブロック（predicted block）を生成することができる。予測部は、現ブロックまたはＣＵ単位で、イントラ予測が適用されるか、またはインター予測が適用されるかを決定できる。予測部は、各予測モードに関する説明で後述するように、予測モード情報などの予測に関する様々な情報を生成して、エントロピ符号化部１９０へ伝達することができる。予測に関する情報は、エントロピ符号化部１９０でエンコードされ、ビットストリームの形態で出力されることができる。
【００３８】
イントラ予測部１８５は、現ピクチャ内のサンプルを参照して現ブロックを予測することができる。上記参照されるサンプルは、予測モードに応じて上記現ブロックの周辺（neighbor）に位置してもよく、あるいは離れて位置してもよい。イントラ予測で、予測モードは、複数の非方向性モードと複数の方向性モードとを含み得る。非方向性モードは、例えば、ＤＣモードおよび平面（プラナー）モード（Ｐｌａｎａｒモード）を含み得る。方向性モードは、予測方向の細密の程度によって、例えば、３３個の方向性予測モードまたは６５個の方向性予測モードを含み得る。ただし、これは例示であって、設定によってそれ以上またはそれ以下の数の方向性予測モードが使用され得る。イントラ予測部１８５は、周辺ブロックに適用された予測モードを用いて、現ブロックに適用される予測モードを決定することもある。
【００３９】
インター予測部１８０は、参照ピクチャ上で動きベクトルにより特定される参照ブロック（参照サンプルアレイ）に基づき、現ブロックに対する予測されたブロックを導出することができる。その際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報をブロック、サブブロックまたはサンプル単位で予測することができる。上記動き情報は、動きベクトルおよび参照ピクチャインデックスを含み得る。上記動き情報は、インター予測方向（Ｌ０予測、Ｌ１予測、Ｂｉ予測など）の情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック（spatial neighboring block）と、参照ピクチャに存在する時間的周辺ブロック（temporal neighboring block）と、を含み得る。上記参照ブロックを含む参照ピクチャと上記時間的周辺ブロックを含む参照ピクチャとは、同一であってもよく、異なってもよい。上記時間的周辺ブロックは、コロケート（同じ位置）参照ブロック（collocated reference block）、コロケートＣＵ（ｃｏｌＣＵ）などの名称で呼ばれることがあり、上記時間的周辺ブロックを含む参照ピクチャは、コロケートピクチャ（collocated picture、ｃｏｌＰｉｃ）と呼ばれることもある。例えば、インター予測部１８０は、周辺ブロックに基づいて動き情報の候補リストを構成し、上記現ブロックの動きベクトルおよび／または参照ピクチャインデックスを導出するために、どの候補が使用されるかを指示する情報を生成し得る。様々な予測モードに基づいてインター予測が行われることがあり、例えば、スキップモードおよびマージモードの場合、インター予測部１８０は、周辺ブロックの動き情報を現ブロックの動き情報として利用し得る。スキップモードの場合、マージモードと異なり、残差信号が送信されないことがある。動きベクトル予測（Motion Vector Prediction、ＭＶＰ）モードの場合、周辺ブロックの動きベクトルを動きベクトル予測子（motion vector predictor）として利用し、動きベクトルの差分（motion vector difference）をシグナリングすることによって、現ブロックの動きベクトルを指示することができる。
【００４０】
上記インター予測部１８０または上記イントラ予測部１８５を介して生成された予測信号は、復元信号を生成するために利用されるか、残差信号を生成するために利用されることができる。
【００４１】
変換部１２０は、残差信号に変換技法を適用して変換係数（transform coefficients）を生成することができる。例えば、変換技法は、ＤＣＴ（Discrete Cosine Transform）、ＤＳＴ（Discrete Sine Transform）、ＫＬＴ（Karhunen-Loeve Transform）、ＧＢＴ（Graph-Based Transform）、またはＣＮＴ（Conditionally Non-linear Transform）のうちの少なくとも１つを含んでもよい。ここで、ＧＢＴは、ピクセル間の関係情報をグラフで表現するとき、このグラフから得られた変換を意味する。ＣＮＴは、以前に復元された全てのピクセル（all previously reconstructed pixel）を利用して予測信号を生成し、それに基づいて獲得される変換を意味する。また、変換過程は、正方形の同じサイズを有するピクセルブロックに適用されてもよく、正方形ではない可変サイズのブロックに適用されてもよい。
【００４２】
量子化部１３０は、変換係数を量子化してエントロピ符号化（エンコーディング）部１９０に送信し、エントロピ符号化部１９０は、量子化された信号（量子化された変換係数に関する情報）をエンコードしてビットストリームとして出力することができる。上記量子化された変換係数に関する情報は、残差情報と呼ばれることがある。量子化部１３０は、係数のスキャン順序（scan order）に基づいて、ブロック形態の量子化された変換係数を１次元のベクトル形態で再整列することができ、上記１次元のベクトル形態の量子化された変換係数に基づいて、上記量子化された変換係数に関する情報を生成することもできる。エントロピ符号化部１９０は、例えば、指数ゴロム（exponential Golomb）、ＣＡＶＬＣ（Context-Adaptive Variable Length Coding）、ＣＡＢＡＣ（Context-Adaptive Binary Arithmetic Coding）などの様々なエンコード方法を行うことができる。エントロピ符号化部１９０は、量子化された変換係数以外のビデオ／イメージの復元に必要な情報（例えば、シンタックス要素（syntax elements）の値など）を、共にまたは別にエンコードすることもできる。エンコードされた情報（例えば、エンコードされたビデオ／映像情報）は、ビットストリームの形態でＮＡＬ（Network Abstraction Layer）ユニット単位で送信または記憶されることができる。上記ビットストリームは、ネットワークを介して送信されることができ、またはデジタル記憶媒体に記憶されることができる。ここで、ネットワークは、放送網および／または通信網などを含んでもよく、デジタル記憶媒体は、ＵＳＢ、ＳＤ、ＣＤ、ＤＶＤ、ブルーレイ、ＨＤＤ、ＳＳＤなどの様々な記憶媒体を含んでもよい。エントロピ符号化部１９０から出力された信号に関して、送信する送信部（図示せず）および／もしくは記憶する記憶部（図示せず）が、エンコード装置１００の内／外部のエレメントとして構成されてもよく、または送信部がエントロピ符号化部１９０の構成要素であってもよい。
【００４３】
量子化部１３０から出力された量子化された変換係数は、予測信号を生成するために利用されることができる。例えば、量子化された変換係数は、ループ内の逆量子化部１４０および逆変換部１５０を介して逆量子化および逆変換を適用することによって、残差信号が復元されることができる。加算部１５５は、復元された残差信号をインター予測部１８０またはイントラ予測部１８５から出力された予測信号に加えることによって、復元（reconstructed）信号（復元ピクチャ、復元ブロック、復元サンプルアレイ）が生成され得る。スキップモードが適用された場合のように、処理対象のブロックに対する残差がない場合、予測されたブロックが復元ブロックとして使用され得る。加算部１５５は、復元部または復元ブロック生成部と呼ばれることがある。生成された復元信号は、現ピクチャ内の次の処理対象のブロックのイントラ予測のために使用されることもあり、後述するように、フィルタリングを経て、次のピクチャのインター予測のために使用されることもある。
【００４４】
フィルタリング部１６０は、復元信号にフィルタリングを適用し、主観的／客観的画質を向上させることができる。例えば、フィルタリング部１６０は、復元ピクチャに様々なフィルタリング方法を適用して、修正された（modified）復元ピクチャを生成することができ、上記修正された復元ピクチャを、メモリ１７０、具体的にはメモリ１７０のＤＰＢに記憶することができる。上記様々なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット（sample adaptive offset）、適応ループフィルタ（adaptive loop filter）、両方向フィルタ（bilateral filter）などを含み得る。フィルタリング部１６０は、各フィルタリング方法に関する説明で後述するように、フィルタリングに関する様々な情報を生成してエントロピ符号化部１９０へ伝達することができる。フィルタリングに関する情報は、エントロピ符号化部１９０でエンコードされてビットストリームの形態で出力されることができる。
【００４５】
メモリ１７０に送信された修正された復元ピクチャは、インター予測部１８０で参照ピクチャとして使用されることができる。エンコード装置は、これを介してインター予測が適用される場合、エンコード装置１００とデコード装置とにおける予測のミスマッチを避けることができ、符号化効率も向上させることができる。
【００４６】
メモリ１７０のＤＰＢは、修正された復元ピクチャをインター予測部１８０における参照ピクチャとして使用するために記憶することができる。メモリ１７０は、現ピクチャ内の動き情報が導出された（またはエンコードされた）ブロックの動き情報および／または既に復元されたピクチャ内ブロックの動き情報を記憶することができる。上記記憶された動き情報は、空間的周辺ブロックの動き情報または時間的周辺ブロックの動き情報として活用するために、インター予測部１８０に伝達できる。メモリ１７０は、現ピクチャ内の復元されたブロックの復元サンプルを記憶することができ、イントラ予測部１８５に伝達できる。
【００４７】
図２は、本発明が適用される実施例であって、ビデオ／イメージ信号のデコーディングが行われるデコード装置の概略ブロック図を示す。
【００４８】
図２を参照すると、デコード装置２００は、エントロピ復号（デコーディング）部２１０、逆量子化部２２０、逆変換部２３０、加算部２３５、フィルタリング部２４０、メモリ２５０、インター予測部２６０、およびイントラ予測部２６５を含んで構成されることができる。インター予測部２６０とイントラ予測部２６５とを合わせて予測部と呼ぶことがある。すなわち、予測部は、インター予測部１８０およびイントラ予測部１８５を含み得る。逆量子化部２２０、逆変換部２３０を合わせて残差処理部と呼ぶことがある。すなわち、残差処理部は、逆量子化部２２０、逆変換部２３０を含み得る。前述したエントロピ復号部２１０、逆量子化部２２０、逆変換部２３０、加算部２３５、フィルタリング部２４０、インター予測部２６０、およびイントラ予測部２６５は、実施例によって１つのハードウェアコンポーネント（例えば、デコーダまたはプロセッサ）により構成されることができる。また、メモリ１７０は、ＤＰＢ（Decoded Picture Buffer）を含み得、デジタル記憶媒体によって構成されることもある。
【００４９】
ビデオ／イメージ情報を含むビットストリームが入力されると、デコード装置２００は、図１のエンコード装置でビデオ／イメージ情報が処理されたプロセスに対応して、映像を復元することができる。例えば、デコード装置２００は、エンコード装置で適用された処理ユニットを利用してデコーディングを行うことができる。したがって、デコーディングの処理ユニットは、例えば、コーディングユニットであってもよく、コーディングユニットは、コーディングツリーユニットまたは最大コーディングユニットから、四分木構造および／または二分木構造に従って分割されることができる。また、デコード装置２００を介してデコーディングおよび出力された復元映像信号は、再生装置を介して再生されることができる。
【００５０】
デコード装置２００は、図１のエンコード装置から出力された信号をビットストリームの形態で受信することができ、受信した信号は、エントロピ復号部２１０を介してデコードされることができる。例えば、エントロピ復号部２１０は、上記ビットストリームをパージングして、映像復元（またはピクチャ復元）に必要な情報（例えば、ビデオ／映像情報）を導出することができる。例えば、エントロピ復号部２１０は、指数ゴロム符号化、ＣＡＶＬＣまたはＣＡＢＡＣなどのコーディング方法に基づいてビットストリーム内の情報をデコードし、映像の復元に必要なシンタックスエレメントの値、残差に関する変換係数の量子化された値を出力することができる。より詳細には、ＣＡＢＡＣエントロピ復号方法は、ビットストリームで各構文要素に該当するビンを受信し、デコーディング対象の構文要素情報と、周辺およびデコーディング対象ブロックのデコーディング情報、または以前の段階でデコードされたシンボル／ビンの情報と、を利用してコンテキスト（context）モデルを決定し、決定されたコンテキストモデルに応じてビン（bin）の発生確率を予測し、ビンの算術復号（arithmetic decoding）を行い、各構文要素の値に該当するシンボルを生成し得る。その際、ＣＡＢＡＣエントロピ復号方法では、コンテキストモデルの決定後、次のシンボル／ビンのコンテキストモデルのためにデコードされたシンボル／ビンの情報を利用してコンテキストモデルをアップデートすることができる。エントロピ復号部２１０でデコードされた情報のうちの予測に関する情報は、予測部（インター予測部２６０およびイントラ予測部２６５）に提供され、エントロピ復号部２１０でエントロピ復号が行われた残差値、すなわち、量子化された変換係数および関連のパラメータ情報は、逆量子化部２２０に入力され得る。また、エントロピ復号部２１０でデコードされた情報のうちのフィルタリングに関する情報は、フィルタリング部２４０に提供され得る。一方、エンコード装置から出力された信号を受信する受信部（図示せず）がデコード装置２００の内／外部のエレメントとしてさらに構成され得、または受信部は、エントロピ復号部２１０の構成要素であり得る。
【００５１】
逆量子化部２２０では、量子化された変換係数を逆量子化し、変換係数を出力することができる。逆量子化部２２０は、量子化された変換係数を２次元のブロック形態で再整列することができる。この場合、上記再整列は、エンコード装置で行われた係数のスキャン順序に基づいて再整列を行うことができる。逆量子化部２２０は、量子化パラメータ（例えば、量子化ステップサイズ情報）を利用して量子化された変換係数に対する逆量子化を行い、変換係数（transform coefficient）を獲得することができる。
【００５２】
逆変換部２３０では、変換係数を逆変換し、残差信号（残差ブロック、残差サンプルアレイ）を獲得することになる。
【００５３】
予測部は、現ブロックに対する予測を行い、上記現ブロックに対する予測サンプルを含む予測されたブロック（predicted block）を生成することができる。予測部は、エントロピ復号部２１０から出力された上記予測に関する情報に基づいて、上記現ブロックにイントラ予測が適用されるか、またはインター予測が適用されるかを決定することができ、具体的なイントラ／インター予測モードを決定することができる。
【００５４】
イントラ予測部２６５は、現ピクチャ内のサンプルを参照して現ブロックを予測することができる。上記参照されるサンプルは、予測モードに応じて現ブロックの周辺（neighbor）に位置してもよく、または離れて位置してもよい。イントラ予測で予測モードは、複数の非方向性モードと複数の方向性モードとを含み得る。イントラ予測部２６５は、周辺ブロックに適用された予測モードを利用して、現ブロックに適用される予測モードを決定することもできる。
【００５５】
インター予測部２６０は、参照ピクチャ上で動きベクトルにより特定される参照ブロック（参照サンプルアレイ）に基づき、現ブロックに対する予測されたブロックを導出することができる。その際、インター予測モードで送信される動き情報の量を減らすために、周辺ブロックと現ブロックとの間の動き情報の相関性に基づいて、動き情報を、ブロック、サブブロック、またはサンプル単位で予測することができる。上記動き情報は、動きベクトルおよび参照ピクチャインデックスを含み得る。上記動き情報は、インター予測方向（Ｌ０予測、Ｌ１予測、Ｂｉ予測など）の情報をさらに含み得る。インター予測の場合、周辺ブロックは、現ピクチャ内に存在する空間的周辺ブロック（spatial neighboring block）と参照ピクチャに存在する時間的周辺ブロック（temporal neighboring block）とを含み得る。例えば、インター予測部２６０は、周辺ブロックに基づいて動き情報の候補リストを構成し、受信した候補選択情報に基づいて、上記現ブロックの動きベクトルおよび／または参照ピクチャインデックスを導出することができる。様々な予測モードに基づいてインター予測が行われ、上記予測に関する情報は、上記現ブロックに対するインター予測のモードを指示する情報を含み得る。
【００５６】
加算部２３５は、獲得された残差信号を、インター予測部２６０またはイントラ予測部２６５から出力された予測信号（予測されたブロック、予測サンプルアレイ）に加えることによって、復元信号（復元ピクチャ、復元ブロック、復元サンプルアレイ）を生成することができる。スキップモードが適用された場合のように、処理対象ブロックに対する残差がない場合、予測されたブロックが復元ブロックとして使用され得る。
【００５７】
加算部２３５は、復元部または復元ブロック生成部と呼ばれることがある。生成された復元信号は、現ピクチャ内の次の処理対象ブロックのイントラ予測のために使用され得、後述するように、フィルタリングを経て、次のピクチャのインター予測のために使用されることもある。
【００５８】
フィルタリング部２４０は、復元信号にフィルタリングを適用し、主観的／客観的画質を向上させることができる。例えば、フィルタリング部２４０は、復元ピクチャに様々なフィルタリング方法を適用し、修正された（modified）復元ピクチャを生成することができ、上記修正された復元ピクチャを、メモリ２５０、具体的にはメモリ２５０のＤＰＢに送信することができる。上記様々なフィルタリング方法は、例えば、デブロックフィルタリング、サンプル適応オフセット（sample adaptive offset）、適応ループフィルタ（adaptive loop filter）、両方向フィルタ（bilateral filter）などを含み得る。
【００５９】
メモリ２５０のＤＰＢに記憶された（修正された）復元ピクチャは、インター予測部２６０で参照ピクチャとして使用されることができる。メモリ２５０は、現ピクチャ内の動き情報が導出された（またはデコードされた）ブロックの動き情報および／または既に復元されたピクチャ内ブロックの動き情報を記憶できる。上記記憶された動き情報は、空間的周辺ブロックの動き情報または時間的周辺ブロックの動き情報として活用するために、インター予測部２６０に伝達できる。メモリ１７０は、現ピクチャ内の復元されたブロックの復元サンプルを記憶することができ、イントラ予測部２６５に伝達できる。
【００６０】
本明細書において、エンコード装置１００のフィルタリング部１６０、インター予測部１８０、およびイントラ予測部１８５で説明された実施例は、それぞれ、デコード装置２００のフィルタリング部２４０、インター予測部２６０、およびイントラ予測部２６５にも同一または対応するように適用され得る。
【００６１】
ブロック分割（Block Partitioning）
【００６２】
本文書によるビデオ／映像のコーディング方法は、様々な細部技術に基づいて行われ、それぞれの細部技術を概略的に説明すると次の通りである。以下説明される技術は、前述したおよび／または後述するビデオ／映像のエンコーディング／デコーディング手続における予測、残差処理（（逆）変換、（逆）量子化など）、シンタックス要素コーディング、フィルタリング、パーティショニング／分割などの関連手続に関連し得ることは、当業者にとって自明である。
【００６３】
本文書によるブロックパーティショニング手続は、前述したエンコード装置の映像分割部１１０で行われ、パーティショニング関連の情報がエントロピ符号化部１９０で（エンコーディング）処理され、ビットストリームの形態でデコード装置に伝達されることができる。デコード装置のエントロピ復号部２１０は、上記ビットストリームから獲得した上記パーティショニング関連の情報に基づいて現ピクチャのブロックパーティショニング構造を導出し、これに基づいて、映像のデコーディングのための一連の手続（例えば、予測、残差処理、ブロック復元、インループフィルタリングなど）が行われることができる。
【００６４】
ピクチャのＣＴＵへの分割（Partitioning of picture into CTUs）
【００６５】
ピクチャは、コーディングツリーユニット（ＣＴＵｓ）のシーケンスに分割され（divided into a sequence）得る。ＣＴＵは、コーディングツリーブロック（ＣＴＢ）に対応し得る。あるいは、ＣＴＵは、ルマサンプルのコーディングツリーブロックと、対応するクロマサンプルと、の２つのコーディングツリーブロックを含み得る。言い換えると、３つのサンプルアレイを含むピクチャに対して、ＣＴＵは、ルマサンプルのＮ×Ｎのブロックと、クロマサンプルの２つの対応ブロックと、を含み得る。
【００６６】
コーディングおよび予測などのためのＣＴＵの最大許容サイズは、変換のためのＣＴＵの最大許容サイズと異なり得る。例えば、ＣＴＵ内ルマブロックの最大許容サイズは、１２８×１２８であり得る。
【００６７】
ツリー構造を使用したＣＴＵの分割（Partitioning of the CTUs using a tree structure）
【００６８】
ＣＴＵは、四分木（Quad-Tree、ＱＴ）構造に基づいてＣＵに分割され得る。四分木構造は、クォータナリ（quaternary）ツリー構造と呼ばれることがある。これは、様々なローカル（局地的）特徴（local characteristic）を反映するためである。一方、本文書では、ＣＴＵは、四分木だけでなく、二分木（Binary-Tree、ＢＴ）および三分木（Ternary-Tree、ＴＴ）を含むマルチタイプツリー構造の分割に基づいて分割され得る。以下、ＱＴＢＴ構造とは、四分木および二分木ベースの分割構造を含んでもよく、ＱＴＢＴＴＴとは、四分木、二分木、および三分木ベースの分割構造を含んでもよい。あるいは、ＱＴＢＴ構造は、四分木、二分木、および三分木ベースの分割構造を含んでもよい。コーディングツリー構造において、ＣＵは、正方形または矩形の形状を有し得る。ＣＴＵは、まず、四分木構造で分割され得る。その後、四分木構造のリーフノードは、マルチタイプツリー構造によりさらに分割され得る。
【００６９】
図３は、本発明が適用され得る実施例であって、マルチタイプツリー構造の一例を示す図である。
【００７０】
本発明の一実施例において、マルチタイプツリー構造は、図３に示すような４つの分割タイプを含み得る。上記４つの分割タイプは、垂直二分割（バイナリ分割）（Vertical Binary Splitting、ＳＰＬＩＴ＿ＢＴ＿ＶＥＲ）、水平二分割（Horizontal Binary Splitting、ＳＰＬＩＴ＿ＢＴ＿ＨＯＲ）、垂直三分割（ターナリ分割）（Vertical Ternary Splitting、ＳＰＬＩＴ＿ＴＴ＿ＶＥＲ）、水平三分割（Horizontal Ternary Splitting、ＳＰＬＩＴ＿ＴＴ＿ＨＯＲ）を含み得る。上記マルチタイプツリー構造のリーフノードは、ＣＵと呼ばれることがある。このようなＣＵは、予測および変換手続のために使用され得る。本文書で、一般的に、ＣＵ、ＰＵ、ＴＵは、同一のブロックサイズを有し得る。ただし、最大許容の変換長さ（maximum supported transform length）がＣＵの色成分（colour component）の幅または高さより小さい場合には、ＣＵとＴＵとが互いに異なるブロックサイズを有し得る。
【００７１】
図４は、本発明が適用され得る実施例であって、マルチタイプツリーを伴う四分木（quadtree with nested multi-type tree）構造のパーティション分割情報のシグナリングメカニズムを例示する図である。
【００７２】
ここで、ＣＴＵは、四分木のルート（root）として取り扱われ、四分木構造で最初にパーティショニングされる。各四分木リーフノードは、以降、マルチタイプツリー構造でさらにパーティショニングされ得る。マルチタイプツリー構造において、第１フラグ（a first flag，例えば、ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｆｌａｇ）が、該当ノードがさらにパーティショニングされるかを指示するためにシグナリングされる。該当ノードがさらにパーティショニングされる場合、第２フラグ（a second flag，例えば、ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃｌａ＿ｆｌａｇ）が分割方向（splitting direction）を指示するためにシグナリングされ得る。その後、第３フラグ（a third flag，例えば、ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇ）が、分割タイプが二分割であるか、三分割であるかを指示するために、シグナリングされ得る。例えば、上記ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｖｅｒｔｉｃａｌ＿ｆｌａｇおよび上記ｍｔｔ＿ｓｐｌｉｔ＿ｃｕ＿ｂｉｎａｒｙ＿ｆｌａｇに基づいて、ＣＵのマルチタイプツリー分割モード（multi-type tree splitting mode、ＭｔｔＳｐｌｉｔＭｏｄｅ）が次の表１のように導出され得る。
【００７３】
【表１】
2021519035.tif 000003
【００７４】
図５は、本発明が適用され得る実施例であって、四分木および伴われるマルチタイプツリー（quadtree and nested multi-type tree）構造に基づいて、ＣＴＵをマルチＣＵに分割する方法を例示する図である。
【００７５】
ここで、太線の（ボールド）ブロックエッジ（bold block edges）は、四分木のパーティショニングを、残りのエッジは、マルチタイプツリーパーティショニングを示す。マルチタイプツリーを伴った四分木パーティションは、コンテンツ適応コーディングツリー構造を提供することができる。ＣＵは、コーディングブロック（ＣＢ）に対応し得る。あるいは、ＣＵは、ルマサンプルのコーディングブロックと、対応するクロマサンプルの２つのコーディングブロックと、を含み得る。ＣＵのサイズは、ＣＴＵだけ大きいこともあり、またはルマサンプルの単位で４×４だけ小さいこともある。例えば、４：２：０のカラーフォーマット（またはクロマフォーマット）の場合、最大クロマのＣＢサイズは、６４×６４であり、最小クロマのＣＢサイズは、２×２であり得る。
【００７６】
本文書で、例えば、最大許容ルマのＴＢサイズは、６４×６４であり、最大許容クロマのＴＢサイズは、３２×３２であり得る。上記ツリー構造に応じて分割されたＣＢの幅または高さが最大の変換幅または高さより大きい場合、該当ＣＢは、自動的に（または暗黙（黙示）的に）水平および垂直方向のＴＢサイズの制限を満たすまで分割され得る。
【００７７】
一方、マルチタイプツリーを伴った四分木コーディングツリーのスキームのために、次のパラメータがＳＰＳシンタックス要素として定義および識別され得る。
【００７８】
−  ＣＴＵ  ｓｉｚｅ：四分木（クォータナリツリー）のルートノードサイズ（the root node size of a quaternary tree）
【００７９】
−  ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ（the minimum allowed quaternary tree leaf node size）
【００８０】
−  ＭａｘＢｔＳｉｚｅ：（最大許容二分木ルートノードサイズ（the maximum allowed binary tree root node size）
【００８１】
−  ＭａｘＴｔＳｉｚｅ：（最大許容三分木ルートノードサイズ（the maximum allowed ternary tree root node size）
【００８２】
−  ＭａｘＭｔｔＤｅｐｔｈ：四分木リーフから分割されるマルチタイプツリーの最大許容階層の深度（the maximum allowed hierarchy depth of multi-type tree splitting from a quadtree leaf）
【００８３】
−  ＭｉｎＢｔＳｉｚｅ：最小許容バイナリーツリーリーフノードサイズ（the minimum allowed binary tree leaf node size）
【００８４】
−  ＭｉｎＴｔＳｉｚｅ：最小許容三分木リーフノードサイズ（the minimum allowed ternary tree leaf node size）
【００８５】
マルチタイプツリーを伴った四分木コーディングツリー構造の一例として、ＣＴＵサイズは、１２８×１２８のルマサンプルおよび２つの対応するクロマサンプルの６４×６４のブロックに設定され得る（４：２：０のクロマフォーマットで）。この場合、ＭｉｎＯＴＳｉｚｅは１６×１６に設定され、ＭａｘＢｔＳｉｚｅは１２８×１２８に設定され、ＭａｘＴｔＳｚｉｅは６４×６４に設定され、ＭｉｎＢｔＳｉｚｅおよびＭｉｎＴｔＳｉｚｅ（for both width and height）は４×４に、かつＭａｘＭｔｔＤｅｐｔｈは４に設定され得る。四分木のパーティショニングは、ＣＴＵに適用され、四分木リーフノードを生成し得る。四分木リーフノードは、リーフＱＴノードと呼ばれることがある。四分木リーフノードは、１６×１６サイズ（すなわち、ＭｉｎＯＴＳｉｚｅ）から１２８×１２８サイズ（すなわち、ＣＴＵ  ｓｉｚｅ）を有し得る。リーフＱＴノードが１２８×１２８の場合、さらに二分木／三分木に分割されないことがある。これは、この場合、分割されても、ＭａｘＢｔｓｉｚｅおよびＭａｘＴｔｓｚｉｅ（すなわち、６４×６４）を超えるためである。これ以外の場合、リーフＱＴノードは、マルチタイプツリーにさらに分割され得る。したがって、リーフＱＴノードは、マルチタイプツリーに対するルートノード（root node）であり、リーフＱＴノードは、マルチタイプツリーデプス（ｍｔｔＤｅｐｔｈ）０値を有し得る。マルチタイプツリーデプスがＭａｘＭｔｔｄｅｐｔｈ（例えば、４）に到達した場合、それ以上更なる分割は考慮されないことがある。マルチタイプツリーノードの幅がＭｉｎＢｔＳｉｚｅと同一であり、２×ＭｉｎＴｔＳｉｚｅより小さいか等しいとき、それ以上更なる水平分割は考慮されないことがある。マルチタイプツリーノードの高さがＭｉｎＢｔＳｉｚｅと同一であり、２×ＭｉｎＴｔＳｉｚｅより小さいか等しいとき、それ以上更なる垂直分割は考慮されないことがある。
【００８６】
図６は、本発明が適用され得る実施例であって、三分木（ternary-tree）の分割を制限する方法を例示する図である。
【００８７】
図６を参照すると、ハードウェアデコーダにおける６４×６４のルマブロックおよび３２×３２のクロマパイプラインのデザインを許容するために、ＴＴ分割は、特定の場合に制限され得る。例えば、ルマコーディングブロックの幅または高さが予め設定された特定値（例えば、３２、６４）より大きい場合、図６に示すように、ＴＴ分割が制限され得る。
【００８８】
本文書で、コーディングツリーのスキームは、ルマおよびクロマブロックがセパレータ（separate）ブロックのツリー構造を有することをサポートすることができる。ＰおよびＢスライスに対して、１つのＣＴＵ内のルマおよびクロマＣＴＢは、同一のコーディングツリー構造を有するように制限され得る。しかしながら、Ｉスライスに対して、ルマおよびクロマブロックは、互いにセパレータブロックのツリー構造を有し得る。セパレータブロックツリーモードが適用される場合、ルマＣＴＢは、特定のコーディングツリー構造に基づいてＣＵに分割され、クロマＣＴＢは、他のコーディングツリー構造に基づいてクロマＣＵに分割され得る。これは、Ｉスライス内のＣＵは、ルマ成分のコーディングブロックまたは２つのクロマ成分のコーディングブロックで構成され、ＰまたはＢスライスのＣＵは、３つのカラー成分のブロックで構成され得ることを意味し得る。
【００８９】
前述した「ツリー構造を使用したＣＴＵの分割（Partitioning of the CTUs using a tree structure）」でマルチタイプツリーを伴った四分木コーディングツリー構造について説明したが、ＣＵが分割される構造はこれに限定されない。例えば、ＢＴ構造およびＴＴ構造は、マルチ（多数）分割ツリー（Multiple Partitioning Tree、ＭＰＴ）構造に含まれる概念として解釈され得、ＣＵは、ＱＴ構造およびＭＰＴ構造を介して分割されると解釈し得る。ＱＴ構造およびＭＰＴ構造を介してＣＵが分割される一例において、ＱＴ構造のリーフノードがいくつかのブロックに分割されるかに関する情報を含むシンタックス要素（例えば、ＭＰＴ＿ｓｐｌｉｔ＿ｔｙｐｅ）、ならびにＱＴ構造のリーフノードが垂直および水平のうちどちらの方向に分割されるかに関する情報を含むシンタックス要素（例えば、ＭＰＴ＿ｓｐｌｉｔ＿ｍｏｄｅ）がシグナリングされることによって、分割構造が決定され得る。
【００９０】
さらに他の例において、ＣＵは、ＱＴ構造、ＢＴ構造、またはＴＴ構造と異なる方法で分割され得る。すなわち、ＱＴ構造に応じて下位デプスのＣＵが上位デプスのＣＵの１／４のサイズに分割されるか、ＢＴ構造に応じて下位デプスのＣＵが上位デプスのＣＵの１／２のサイズに分割されるか、ＴＴ構造に応じて下位デプスのＣＵが上位デプスのＣＵの１／４または１／２のサイズに分割されることと異なり、下位デプスのＣＵは、場合に応じて上位デプスのＣＵの１／５、１／３、３／８、３／５、２／３または５／８のサイズに分割され得、ＣＵが分割される方法はこれに限定されない。
【００９１】
ツリーノードブロックの部分（a portion）が下端（bottom）または右側（right）ピクチャの境界を超える（exceeds）場合、該当ツリーノードブロックは、全てのコーディングされたＣＵの全てのサンプルが上記ピクチャの境界内に位置するように制限され得る。この場合、例えば、次のような分割規則が適用され得る。
【００９２】
−  ツリーノードブロックの一部がピクチャの下端または右側の境界を超えると、（If a portion of a tree node block exceeds both the bottom and the right picture boundaries,）
【００９３】
−  ブロックがＱＴノードであり、ブロックサイズが最小ＱＴサイズより大きければ、ブロックは、強制的にＱＴ分割モードで分けられる。（If the block is a QT node and the size of the block is larger than the minimum QT size, the block is forced to be split with QT split mode.）
【００９４】
−  そうでなければ、ブロックは強制的にＳＰＬＩＴ＿ＢＴ＿ＨＯＲモードで分けられる。（Otherwise, the block is forced to be split with SPLIT_BT_HOR mode.）
【００９５】
−  そうではなく、ツリーノードブロックの一部がピクチャの下端の境界を超えると、（Otherwise, if a portion of a tree node block exceeds the bottom picture boundaries,）
【００９６】
−  ブロックがＱＴノードであり、ブロックサイズが最小ＱＴサイズより大きく、ブロックサイズが最大ＢＴサイズよりも大きければ、ブロックは、強制的にＱＴ分割モードで分けられる。（If the block is a QT node, and the size of the block is larger than the minimum QT size, and the size of the block is larger than the maximum BT size, the block is forced to be split with QT split mode.）
【００９７】
−  そうではなく、ブロックがＱＴノードであり、ブロックサイズが最小ＱＴサイズより大きく、ブロックサイズが最大ＢＴサイズよりも小さいか同じであれば、ブロックは、強制的にＱＴ分割モードまたはＳＰＬＩＴ＿ＢＴ＿ＨＯＲモードで分けられる。（Otherwise, if the block is a QT node, and the size of the block is larger than the minimum QT size and the size of the block is smaller than or equal to the maximum BT size, the block is forced to be split with QT split mode or SPLIT_BT_HOR mode.）
【００９８】
−  そうでなければ（ブロックがＢＴＴノード、またはブロックサイズが最小ＱＴサイズよりも小さいか同じであれば）、ブロックは、強制的にＳＰＬＩＴ＿ＢＴ＿ＨＯＲモードで分けられる。（Otherwise (the block is a BTT node or the size of the block is smaller than or equal to the minimum QT size), the block is forced to be split with SPLIT_BT_HOR mode.）
【００９９】
−  そうではなく、ツリーノードブロックの一部がピクチャの右側の境界を超えると、（Otherwise, if a portion of a tree node block exceeds the right picture boundaries,）
【０１００】
−  ブロックがＱＴノードであり、ブロックサイズが最小ＱＴサイズより大きく、ブロックサイズが最大ＢＴサイズよりも大きければ、ブロックは、強制的にＱＴ分割モードで分けられる。（If the block is a QT node, and the size of the block is larger than the minimum QT size, and the size of the block is larger than the maximum BT size, the block is forced to be split with QT split mode.）
【０１０１】
−  そうではなく、ブロックがＱＴノードであり、ブロックサイズが最小ＱＴサイズより大きく、ブロックサイズが最大ＢＴサイズよりも小さいか同じであれば、ブロックは、強制的にＱＴ分割モードまたはＳＰＬＩＴ＿ＢＴ＿ＶＥＲモードで分けられる。（Otherwise, if the block is a QT node, and the size of the block is larger than the minimum QT size and the size of the block is smaller than or equal to the maximum BT size, the block is forced to be split with QT split mode or SPLIT_BT_VER mode.）
【０１０２】
−  そうでなければ（ブロックがＢＴＴノードあるいは、ブロックサイズが最小ＱＴサイズよりも小さいか同じであれば）、ブロックは、強制的にＳＰＬＩＴ＿ＢＴ＿ＶＥＲモードで分けられる。（Otherwise (the block is a BTT node, or the size of the block is smaller than or equal to the minimum QT size), the block is forced to be split with SPLIT_BT_VER mode.）
【０１０３】
第１実施形態
【０１０４】
図７は、本発明が適用される一実施形態であって、四分木（quad-tree）に基づくブロック分割構造を例示する図である。
【０１０５】
図７に示すように、本発明の一実施形態において、１つのブロックは、四分木（Quad-Tree、ＱＴ）に基づいて分割されることができる。また、ＱＴ構造で分割された１つのサブブロック（sub block）は、ＱＴ構造で再帰的にさらに分割されることができる。ＱＴ構造でそれ以上分割されない末端ブロック（リーフブロック、リーフノードブロックと呼ばれることができる）は、二分木（２進ツリー）（Binary Tree、ＢＴ）、三分木（３進ツリー）（Ternary Tree、ＴＴ）、または非対称ツリー（Asymmetric Tree、ＡＴ）のうちの少なくとも１つにより分割されることができる。
【０１０６】
一例として、ブロックＡは、ＱＴ構造で４個のサブブロックＡ０、Ａ１、Ａ２、Ａ３に分割されることができる。そして、サブブロックＡ１は、再度ＱＴ構造で４個のサブブロックＢ０、Ｂ１、Ｂ２、Ｂ３に分割されることができる。
【０１０７】
図８は、本発明が適用される一実施形態であって、二分木（binary-tree）に基づくブロック分割構造を例示する図である。
【０１０８】
図８に示すように、ＢＴは、水平方向ＢＴ（例えば、２Ｎ×Ｎ、２Ｎ×Ｎ）と垂直方向ＢＴ（例えば、Ｎ×２Ｎ、Ｎ×２Ｎ）の２つの形態の分割を有することができる。
【０１０９】
一例として、ＱＴ構造でそれ以上分割されないブロック（すなわち、リーフノードブロック）Ｂ３は、垂直方向ＢＴ（Ｃ０、Ｃ１）または水平方向ＢＴ（Ｄ０、Ｄ１）に分割されることができる。垂直方向に分割された場合、ブロックＣ０のように、それぞれのサブブロックは、水平方向ＢＴ（Ｅ０、Ｅ１）または垂直方向ＢＴ（Ｆ０、Ｆ１）の形態のように再帰的に分割されることができる。
【０１１０】
図９は、本発明が適用される一実施形態であって、三分木（ternary-tree）に基づくブロック分割構造を例示する図である。
【０１１１】
図９に示すように、ＴＴは、水平方向ＴＴ（例えば、２Ｎ×１／２Ｎ、２Ｎ×Ｎ、２Ｎ×１／２Ｎ）と垂直方向ＴＴ（例えば、１／２Ｎ×２Ｎ、Ｎ×２Ｎ、１／２Ｎ×２Ｎ）との２つの形態の分割を有することができる。
【０１１２】
一例として、ＱＴによってそれ以上分割されないブロックＢ３は、垂直方向ＴＴ（Ｃ０、Ｃ１、Ｃ２）または水平方向ＴＴ（Ｄ０、Ｄ１、Ｄ２）に分割されることができる。図１１に示されたように、ブロックＣ１は、水平方向ＴＴ（Ｅ０、Ｅ１、Ｅ２）または垂直方向ＴＴ（Ｆ０、Ｆ１、Ｆ２）の形態のように再帰的に分割されることができる。
【０１１３】
他の一例として、ＡＴは、水平上向（horizontal-up）ＡＴ（２Ｎ×１／２Ｎ、２Ｎ×３／２Ｎ）、水平下向（horizontal-down）ＡＴ（２Ｎ×３／２Ｎ、２Ｎ×１／２Ｎ）、垂直上向ＡＴ（１／２Ｎ×２Ｎ、３／２Ｎ×２Ｎ）、垂直右向（vertical-right）ＡＴ（３／２Ｎ×２Ｎ、１／２Ｎ×２Ｎ）の４つの形態の分割構造を有することができる。それぞれのＢＴ、ＴＴ、ＡＴは、ＢＴ、ＴＴ、ＡＴを使用して再帰的にさらに分割されることができる。
【０１１４】
図１０は、本発明が適用される一実施形態であって、二分木（binary-tree）、三分木（ternary-tree）、およびストライプツリー（stripe tree）構造に基づくブロック分割構造を例示する図である。
【０１１５】
図１０に示すように、処理ブロックは、ＢＴ、ＴＴ、ストライプツリー（ＳＴ：Stripe Tree）分割構造を共に使用して分割されることができる。例えば、ＢＴ構造で分割されたサブブロックは、ＴＴ構造で分割されることができる。あるいは、ＴＴ構造で分割されたサブブロックは、ＢＴ構造で分割されることができる。
【０１１６】
また、一実施形態において、処理ブロックは、水平方向または垂直方向に４分割されるＳＴ構造で分割されることができる。また、ＢＴ、ＴＴ、ＳＴ分割は、共に使用して分割が可能である。例えば、ＢＴにより分割されたサブブロックは、ＴＴまたはＳＴによる分割が可能である。また、ＴＴにより分割されたサブブロックは、ＢＴまたはＳＴによる分割が可能である。また、ＳＴにより分割されたサブブロックは、ＢＴまたはＴＴによる分割が可能である。
【０１１７】
図１０で、細い実線で表現された分割は、１番目の分割を示し、太い点線で表現された分割は、１番目の分割で生成されたサブブロックで行われた２番目の分割を示す。
【０１１８】
表２は、ｃｏｄｉｎｇ  ｑｕａｄｔｒｅｅのシンタックス構造を示し、表３は、ｃｏｄｉｎｇ  ｔｒｅｅに関するシンタックスを示す。
【０１１９】
【表２】
2021519035.tif 000004
【０１２０】
表２を参照し、四分木分割構造の決定のためのデコーディングプロセスを説明する。現ブロックの左上端（段）座標（ｘ０，ｙ０）、現ブロックのサイズ（ｌｏｇ２ＣｂＳｉｚｅ）、現四分木分割深度を入力として、ｃｏｄｉｎｇ  ｑｕａｄｔｒｅｅのシンタックス（または関数）が呼び出され得る。
【０１２１】
現ブロックが現ピクチャの幅または高さを超えず、現ブロックが最小サイズのコーディングブロックより大きい場合、デコーダは、ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇのシンタックス要素（syntax element）をパージングする。ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇのシンタックス要素は、現ブロックが四分木構造で４分割されるか否かを指示する。例えば、ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇの値が０である場合、分割されないことを示し、ｓｐｌｉｔ＿ｑｔ＿ｆｌａｇの値が１である場合、ブロックが、幅の半分、高さの半分で（を有する）４分割されることを示す。ｘ０およびｙ０は、輝度映像のｔｏｐ−ｌｅｆｔの位置を示す。
【０１２２】
パージングの結果、現ブロックを四分木構造で分割すると決定された場合、デコーダは、現ブロックから分割された４つのサブブロックに対して、再度ｃｏｄｉｎｇ  ｑｕａｄｔｒｅｅのシンタックス（または関数）を呼び出す。
【０１２３】
パージングの結果、現ブロックを四分木構造で分割しないと決定された場合、デコーダは、以降の分割構造（すなわち、マルチタイプツリー構造）の決定のための現ブロックに対してｃｏｄｉｎｇ  ｔｒｅｅのシンタックス（または関数）を呼び出す。
【０１２４】
【表３】
2021519035.tif 000005
【０１２５】
表３を参照し、四分木リーフノードブロックで更なる分割構造の決定のためのデコーディングプロセスを説明する。現ブロックの左上端座標（ｘ０，ｙ０）、現ブロックの幅（ｌｏｇ２ＣｂＳｉｚｅＷ）、現ブロックの幅（ｌｏｇ２ＣｂＳｉｚｅＨ）を入力としてｃｏｄｉｎｇ  ｔｒｅｅのシンタックス（または関数）が呼び出され得る。
【０１２６】
現ブロックが現ピクチャの幅または高さを超えず、現ブロックが最小サイズのＭＴＴブロックより大きい場合、デコーダは、ｓｐｌｉｔ＿ｆｕｒ＿ｆｌａｇのシンタックス要素（syntax element）をパージングする。ｓｐｌｉｔ＿ｆｕｒ＿ｆｌａｇのシンタックスは、現ブロックがさらに分割されるか否かを示す。例えば、ｓｐｌｉｔ＿ｆｕｒ＿ｆｌａｇの値が０である場合、これ以上分割されないことを意味し、ｓｐｌｉｔ＿ｆｕｒ＿ｆｌａｇの値が１である場合、ブロックが分割されることを意味する。
【０１２７】
パージングの結果、現ブロックがさらに分割されることが確認された場合、デコーダは、ｓｐｌｉｔ＿ｂｔ＿ｆｌａｇおよびｓｐｌｉｔ＿ｄｉｒのシンタックス要素をパージングする。ｓｐｌｉｔ＿ｂｔ＿ｆｌａｇのシンタックスは、ＢＴ構造で分割されるか、またはＴＴ構造で分割されるかを示す。例えば、ｓｐｌｉｔ＿ｂｔ＿ｆｌａｇの値が１である場合、ブロックがＢＴにより分割されることを意味し、ｓｐｌｉｔ＿ｂｔ＿ｆｌａｇの値が０である場合、ブロックがＴＴにより分割されることを意味する。
【０１２８】
現ブロックの分割タイプ（ＳｐｌｉｔＴｙｐｅ）は、ｓｐｌｉｔ＿ｆｕｒ＿ｆｌａｇのシンタックスおよびｓｐｌｉｔ＿ｂｔ＿ｆｌａｇのシンタックスに基づいて、次の表４のように決定され得る。
【０１２９】
【表４】
2021519035.tif 000006
【０１３０】
また、表３で、ｓｐｌｉｔ＿ｄｉｒのシンタックス要素は、分割方向を示す。例えば、ｓｐｌｉｔ＿ｄｉｒの値が０である場合、ブロックが水平方向に分割されることを示し、ｓｐｌｉｔ＿ｄｉｒの値が１である場合、ブロックが垂直方向に分割されることを示す。
【０１３１】
現ブロックからＭＴＴ分割された最終的なブロック分割モード（ＳｐｌｉｔＭｏｄｅ）は、次の表５のように導出され得る。
【０１３２】
【表５】
2021519035.tif 000007
【０１３３】
デコーダは、最終的に決定された分割構造によって分割されたサブブロックに対して、再度ｃｏｄｉｎｇ  ｔｒｅｅのシンタックス（または関数）を呼び出す。
【０１３４】
第２実施形態
【０１３５】
本発明の一実施形態では、ブロックの形状（または、サイズ）によるＢＴ、ＴＴ、またはＳＴ分割に対する許容方法を提案する。上述した第１実施形態では、ブロックの形状に関係なく、最大分割深さを表すＭａｘＤｅｐｔｈ、二分木構造で分割されたブロックの最小サイズを表すＭｉｎＢＴＳｉｚｅ、または三分木構造で分割されたブロックの最小サイズを表すＭｉｎＴＴＳｉｚｅに到達しないならば分割が許容される。しかしながら、本実施形態において、エンコーダ／デコーダは、ブロックの幅または高さ（すなわち、ブロックの形状）によって適応的にブロック分割を許容することができる。
【０１３６】
図１１は、本発明が適用される一実施形態であって、正方形ブロックのブロック分割構造を例示する図である。
【０１３７】
図１１に示すように、現ブロックが２Ｎ×２Ｎブロックである場合を仮定する。本発明の一実施形態において、幅と高さとが同じ正方形ブロックは、図１１に示されたように、水平ＢＴ、ＴＴ、ＳＴ分割が全て可能であり、垂直ＢＴ、ＴＴ、ＳＴ分割が全て可能である。すなわち、本発明の実施形態において、正方形ブロックは、ブロック形状によるブロック分割制限が適用されないことができる。
【０１３８】
図１２は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１３９】
図１２に示すように、現ブロックが２Ｎ×Ｎブロックである場合を仮定する。本発明の一実施形態において、幅が高さより２倍大きい非正方形ブロックは、図１２に示されたように、垂直ＢＴ、ＴＴ分割および水平ＢＴ分割のみが許容されることができる。
【０１４０】
言い換えれば、現ブロックが高さより幅が大きい非正方形ブロックである場合、水平方向および垂直方向のＳＴ分割は、許容されないことができる。また、現ブロックが高さより幅が大きい非正方形ブロックである場合、水平方向に対して、ＴＴ分割は許容されないことができる。
【０１４１】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１４２】
図１３は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１４３】
図１３に示すように、現ブロックがＮ×２Ｎブロックである場合を仮定する。本発明の一実施形態において、高さが幅より２倍大きい非正方形ブロックは、図１３に示されたように、水平ＢＴ、ＴＴ分割、および垂直ＢＴ分割のみ許容されることができる。
【０１４４】
言い換えれば、現ブロックが幅より高さが大きい非正方形ブロックである場合、水平方向および垂直方向のＳＴ分割は、許容されないことができる。また、現ブロックが幅より高さが大きい非正方形ブロックである場合、垂直方向に対して、ＴＴ分割は許容されないことができる。
【０１４５】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１４６】
図１４は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１４７】
図１４に示すように、現ブロックが２Ｎ×１／２Ｎブロックである場合を仮定する。本発明の一実施形態において、幅が高さより４倍大きい非正方形ブロックは、図１４に示されたように、垂直ＢＴ分割のみ許容されることができる。
【０１４８】
言い換えれば、現ブロックの高さより幅が４倍以上大きいブロックである場合、垂直方向のＴＴおよびＳＴ分割は、許容されないことができる。また、現ブロックが高さより幅が４倍以上大きいブロックである場合、水平方向に対しては、全ての分割を許容しないことができる。
【０１４９】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１５０】
図１５は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１５１】
図１５に示すように、現ブロックが１／２Ｎ×２Ｎブロックである場合を仮定する。本発明の一実施形態において、高さが幅より４倍大きい非正方形ブロックは、図１５に示されたように、水平ＢＴ分割のみ許容されることができる。
【０１５２】
言い換えれば、現ブロックの幅より高さが４倍以上大きいブロックである場合、水平方向のＴＴおよびＳＴ分割は、許容されないことができる。また、現ブロックが幅より高さが４倍以上大きいブロックである場合、垂直方向に対しては、全ての分割を許容しないことができる。
【０１５３】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１５４】
一実施形態において、上述したブロックの形状またはサイズによって特定の分割を制限する方法は、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界が映像（ピクチャまたはスライス）の境界を外れる場合に限って適用されることもできる。
【０１５５】
第３実施形態
【０１５６】
本発明では、ブロックの形状によるＢＴ、ＴＴ、またはＳＴ分割に対する許容方法を提案する。前述した第２実施形態によれば、エンコーダ／デコーダは、ブロックの幅および高さの形状によって適応的にブロック分割を許容することができる。前述した第２実施形態では、ブロックのサイズが相対的に大きいブロックに対して様々なブロックの分割を許容し、相対的に小さいブロックに対しては、ブロック形状によって特定分割を許容しない方法である。それに対し、本発明の実施形態では、相対的に小さいブロックに対してより細かいブロック分割を許容する方法を提案する。
【０１５７】
図１６は、本発明が適用される一実施形態であって、正方形ブロックのブロック分割構造を例示する図である。
【０１５８】
図１６に示すように、現ブロックが２Ｎ×２Ｎブロックである場合を仮定する。本発明の一実施形態において、幅と高さとが同じ正方形ブロックは、図１６に示されたように、水平および垂直ＢＴ分割のみ許容されることができる。すなわち、幅と高さとが同じ正方形ブロックは、ＴＴおよびＳＴ分割が許容されないことができる。
【０１５９】
また、本発明の一実施形態において、２Ｎ×ＮブロックおよびＮ×２Ｎブロックに対して可能な分割は、前述した第２実施形態と同じ分割構造に対して許容されることができる（図１２、図１３参照）。
【０１６０】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１６１】
図１７は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１６２】
図１７に示すように、現ブロックが２Ｎ×１／２Ｎブロックである場合を仮定する。本発明の一実施形態において、幅が高さより４倍大きい非正方形ブロックは、図１７に示されたように、垂直ＢＴ、ＴＴ、ＳＴ分割のみが許容されることができる。
【０１６３】
言い換えれば、現ブロックの高さより幅が４倍以上大きいブロックである場合、垂直方向の分割のみ許容されることができる。また、現ブロックが高さより幅が４倍以上大きいブロックである場合、水平方向に対しては、全ての分割を許容しないことができる。
【０１６４】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１６５】
図１８は、本発明が適用される一実施形態であって、非正方形ブロックのブロック分割構造を例示する図である。
【０１６６】
図１８に示すように、現ブロックが１／２Ｎ×２Ｎブロックである場合を仮定する。本発明の一実施形態において、高さが幅より４倍大きい非正方形ブロックは、図１５に示されたように、水平ＢＴ、ＴＴ、ＳＴ分割のみが許容されることができる。
【０１６７】
言い換えれば、現ブロックの幅より高さが４倍以上大きいブロックである場合、水平方向の分割のみ許容されることができる。また、現ブロックが幅より高さが４倍以上大きいブロックである場合、垂直方向に対しては、全ての分割を許容しないことがある。
【０１６８】
本発明の実施形態によれば、幅と高さとの割合を考慮して、非効率的な分割構造を許容しないことで、分割情報シグナリングに必要なビット数を減らすことができる。
【０１６９】
一実施形態において、上述したブロックの形状またはサイズによって特定の分割を制限する方法は、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界が映像（ピクチャまたはスライス）の境界を外れる場合に限って適用されることもできる。
【０１７０】
第４実施形態
【０１７１】
先に、第２実施形態および第３実施形態において、ブロックの形状によって分割可能なブロック分割構造を決定する方法を説明した。本発明の一実施形態において、上述したブロック形状によってブロック分割構造を決定するためのシンタックスは、上位レベルシンタックス（high level syntax）から送信されることができる。
【０１７２】
例えば、上記ブロック形状によってブロック分割構造を決定するためのシンタックスは、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してエンコーダからデコーダへシグナリングされることができる。
【０１７３】
一実施形態において、上記ブロック分割構造を決定するシンタックスは、次の表６のように、シーケンスパラメータセット（ＳＰＳ：Sequence Parameter Set）から送信されることができる。
【０１７４】
【表６】
2021519035.tif 000008
【０１７５】
表６を参照すれば、ｌｏｇ２＿ｓｉｚｅ＿ｂｔ＿ａｌｌｏｗ＿ｒａｔｉｏは、ＢＴ分割に関して、ブロックの幅と高さとの間の割合（または、差、差の割合）の許容範囲を指示するシンタックス（または、シンタックス要素）である。一例として、その値が１であれば、エンコーダ／デコーダは、ブロックの一方（すなわち、幅または高さ）の長さが他の一方の２倍までは分割を許容し、それ以上である場合は、ブロック分割を許容しないことがある。そして、ｌｏｇ２＿ｓｉｚｅ＿ｂｔ＿ａｌｌｏｗ＿ｒａｔｉｏおよびｌｏｇ２＿ｓｉｚｅ＿ｓｔ＿ａｌｌｏｗ＿ｒａｔｉｏは、各々ＴＴおよびＳＴ分割に関して、ブロックの幅と高さとの間の割合（または、差、差の割合）の許容範囲を指示するシンタックス（または、シンタックス要素）である。
【０１７６】
あるいは、一実施形態において、上記ブロック分割構造を決定するシンタックスは、次の表７のように、シーケンスパラメータセット（ＳＰＳ：Sequence Parameter Set）から送信されることができる。
【０１７７】
【表７】
2021519035.tif 000009
【０１７８】
表７を参照すれば、ｌｏｇ２＿ｓｉｚｅ＿ｂｔ＿ｄｉｓａｌｌｏｗ＿ｒａｔｉｏは、ＢＴ分割に関して、ブロックの幅と高さとの間の割合（または、差、差の割合）の許容範囲を指示するシンタックス（または、シンタックス要素）である。一例として、その値が１であれば、エンコーダ／デコーダは、ブロックの一方の長さが他の一方の２倍になる場合、ブロックの分割を許容しないことがある。そして、ｌｏｇ２＿ｓｉｚｅ＿ｂｔ＿ｄｉｓａｌｌｏｗ＿ｒａｔｉｏおよびｌｏｇ２＿ｓｉｚｅ＿ｓｔ＿ｄｉｓａｌｌｏｗ＿ｒａｔｉｏは、各々ＴＴおよびＳＴ分割に関して、ブロックの幅と高さとの間の割合（または、差、差の割合）の許容範囲を指示するシンタックス（または、シンタックス要素）である。
【０１７９】
表６および表７のシンタックスは、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してエンコーダからデコーダへシグナリングされることができる。
【０１８０】
表６および表７の例示によれば、幅と高さとが一定の割合である場合、ブロック分割を許容しないことで、分割構造を効率的に決定し、分割構造決定に必要なシグナリングビットを低減することができる。
【０１８１】
一実施形態において、上述したブロックの形状またはサイズによって特定の分割を制限する方法は、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界が映像（ピクチャまたはスライス）の境界を外れる場合に限って適用されることもできる。
【０１８２】
第５実施形態
【０１８３】
前述したように、ＱＴ構造は、ブロックの幅と高さとの長さが同じ場合に使用されることができる。本発明の一実施形態において、映像の境界（picture boundary）領域でブロックが掛けられる場合、すなわち、現ＣＴＵ（または、最大コーディングユニット、ＣＴＢ）の左側または下側境界が現ピクチャを超過する場合、エンコーダ／デコーダは、現ＣＴＵを追加的なシンタックスシグナリングなしで、ＢＴまたはＴＴ（すなわち、マルチタイプツリー（ＭＴＴ：Multi Type Tree））分割可能な最大のサイズのブロックに分割することができる。
【０１８４】
従来の映像圧縮技術において、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界がピクチャ（または、スライス）の境界を外れる場合、デコーダは、エンコーダからシグナリングされる分割情報をパージングせずに（すなわち、暗示的に）、ピクチャの境界を外れない（深さ）までＱＴ分割を行うことができる。
【０１８５】
例えば、現ＣＴＵが６４×６４であり、ピクチャ（または、スライス）は、６４×３２領域のみ含む場合、デコーダは、分割情報パージングなしで、現ＣＴＵを４個の３２×３２ＣＵでＱＴ分割することができる。このような場合、６４×３２サイズのブロックは、２個の３２×３２サイズブロックに暗示的に分割された後、分割情報に対するパージングがなされる。本発明において、暗示的分割は、分割情報シグナリングなしで特定条件によってブロック分割を行う方法を表し、自動分割、デフォルト分割などと呼ばれることができる。
【０１８６】
本発明の実施形態では、ＣＴＵ（または、ＣＴＢ、最大サイズのＣＵ）の境界がピクチャの境界を外れる場合、ＱＴ分割を許容しないことでピクチャ境界を外れるＣＴＵ分割を最小にする方法を提案する。例えば、エンコーダ／デコーダは、現ＣＴＵが６４×６４であり、ピクチャ（または、スライス）は、６４×３２領域のみを含む場合、ＱＴ分割を許容しないことで、ＱＴ以外の分割（例えば、ＢＴ、ＴＴ、ＡＴ）を行うことができる。例えば、ＱＴ分割の代わりにＢＴ分割が行われることができ、この場合、ピクチャ（または、スライス）境界に隣接する６４×３２サイズのブロックは、２個の３２×３２サイズブロックでない、６４×３２サイズのブロックから、分割情報のパージングを介して分割が始まり得る。本発明の実施形態によれば、映像の複雑度によってＱＴ分割を調節することにより、相対的に少ない分割情報で効果的な分割構造を決定することができる。
【０１８７】
一実施形態において、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界がピクチャ（または、スライス）の境界を外れる場合、エンコーダは、ＱＴ分割が許容されるか否かを指示するシンタックスをデコーダへ送信することができる。上記ＱＴ分割が許容されるか否かを指示するシンタックスは、例えば、シーケンス、ピクチャ、スライス（または、タイルグループ）単位で送信されることができる。下記の表８では、上位レベルでシグナリングされるＱＴ分割制限シンタックスを例示する。
【０１８８】
【表８】
2021519035.tif 000010
【０１８９】
表８を参照すれば、ｐｉｃ＿ｂｏｕｎｄａｒｙ＿ｑｔ＿ｄｉｓａｂｌｅ＿ｆｌａｇは、映像の境界領域のブロックサイズが最大ブロックサイズと同一でない場合、ＱＴによる分割を許容するか否かを指示するシンタックス（または、シンタックス要素）を表す。実施形態として、ｐｉｃ＿ｂｏｕｎｄａｒｙ＿ｑｔ＿ｄｉｓａｂｌｅ＿ｆｌａｇ値が１であれば、映像境界領域では、ＱＴ分割を許容しないことがある。上記シンタックスは、シーケンスパラメータセット（Sequence Parameter Set）の他に、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してエンコーダからデコーダへシグナリングされることもできる。
【０１９０】
図１９は、本発明が適用される一実施形態であって、映像の境界をＣＴＵ（Coding Tree Unit）が外れる場合を例示する図である。
【０１９１】
図１９に示すように、現ピクチャは、ＣＴＵ単位で分割されることができる。この場合、現ピクチャの高さは、ＣＴＵ高さの倍数に該当しないことができ、この場合、図１９に示されたように、現ピクチャの下端に位置するＣＴＵは、現ピクチャの境界を外れることができる。
【０１９２】
すなわち、前述した第２実施形態〜第４実施形態により決定されるブロック形状によって可能なブロック分割形状が決定され、当該ブロックを分割できる最も大きいブロックから暗示的に分割が行われ得る。このとき、分割のための情報は、シンタックスに含まれないことができる。暗黙的に分割可能な最も大きいブロックに分割された後、エンコーダは、最適なブロック分割構造に関する情報をシグナリングすることができる。
【０１９３】
また、他の一実施形態において、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界がピクチャ（または、スライス）の境界を外れる場合、エンコーダとデコーダとで同様に特定条件によってＱＴ分割が許容されるか否かを決定できる。ＱＴ分割が許容されない場合、ＱＴ以外の分割（例えば、ＢＴ、ＴＴ、ＡＴ）を利用してエンコーダ／デコーダは、ＣＴＵを分割することができる。
【０１９４】
一例として、ＣＴＵの境界が映像（ピクチャまたはスライス）の境界を外れる場合、デコーダは、ＣＴＵと映像とが重複する領域（または、重複する面積）を基にＱＴ分割が許容されるか否かを決定できる。例えば、デコーダは、重複する領域がＣＴＵサイズの１／２以下である場合、ＱＴ分割を許容せず、重複する領域が１／２を超過する場合、ＱＴ分割を許容することができる。
【０１９５】
このとき、重複する領域を基にＱＴ分割が許容されるか否かを決定するステップに先立って、重複する領域を確認（または、判断）するステップが行われ得る。重複する領域は、ＣＴＵ内における面積の割合、ＣＴＵと比べた幅または高さの割合、仮想領域との面積／幅／高さの割合などを利用して計算されることができる。本発明において、ＣＴＵ内でＣＴＵと映像とが重複する領域を除いた残りの領域（すなわち、ＣＴＵ内で映像（ピクチャまたはスライス）の境界を外れる領域）は、仮想領域と称されることができる。その後、重複する領域（または、面積、割合）が予め決められた領域（または、面積、割合）より小さいか、同じである場合、ＱＴ分割を許容せず、大きい場合、ＱＴ分割を許容できる。また、例えば、重複する領域の割合を特定閾値（threshold）と比較して、ＱＴ分割が許容されるか否かを決定できる。
【０１９６】
また、一例として、ＣＴＵの境界が映像（ピクチャまたはスライス）の境界を外れる場合、デコーダは、変換（または、変換カーネル、変換行列）のサイズを基にＱＴ分割が許容されるか否かまたは暗示的分割構造を決定できる。例えば、デコーダは、重複する領域に利用可能な変換がある場合、ＱＴ分割を許容しないことができる。あるいは、デコーダは、上述した実施形態のように、重複する領域を基にＱＴ分割が許容されるか否かを決定し、重複する領域で利用可能な変換のサイズによって分割構造を決定できる。例えば、デコーダは、利用可能な変換の最大サイズ単位で重複する領域を分割できる。
【０１９７】
一実施形態において、エンコーダ／デコーダは、現ＣＴＵの重複する領域が最大変換サイズより大きい場合、現ＣＴＵに対してシンタックスシグナリングなしでＱＴ分割を行うことができる。例えば、エンコーダ／デコーダは、重複する領域、すなわち、ＣＴＵ内で仮想領域を除いた現ピクチャ内の領域の幅が最大変換サイズ（または、最大変換の一辺の長さ）より大きいか、または、上記重複する領域の高さが最大変換サイズより大きい場合、現ＣＴＵに対してシンタックスシグナリングなしでＱＴ分割を行うことができる。
【０１９８】
また、他の一実施形態において、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界がピクチャ（または、スライス）の境界を外れる場合、ＱＴ分割が常に許容されないように設定されることもできる。ＱＴ分割が許容されない場合、ＱＴ以外の分割（例えば、ＢＴ、ＴＴ、ＡＴ）を利用して当該ＣＴＵを分割できる。このような場合、シンタックスシグナリングデータを減らすと同時に、ピクチャ境界を外れるブロックの分割を最小化できる。
【０１９９】
本発明の実施形態によれば、ＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）の境界が映像（ピクチャまたはスライス）の境界を外れる場合、当該ＣＴＵ内の映像の分割を最小化でき、当該ＣＴＵ内の映像の初期分割ブロックのサイズを効果的に決定することができる。映像の解像度がより大きくなり多様化されるにつれて、映像を分割する基本単位であるＣＴＵ（または、ＣＴＢ、最大サイズＣＵ）に関しても、既存のＨＥＶＣより大きいサイズである１２８×１２８、２５６×２５６ブロックなどが議論中である。
【０２００】
したがって、ＣＴＵ境界が映像の境界を外れる場合が頻繁に発生し得るし、従来の映像圧縮技術のように、いずれの場合でもＱＴ分割を許容するならば、映像の境界が不要に小さいサイズに分割されることがあり、不要に分割されたブロック単位で符号化情報がシグナリングされることにより、映像の境界で圧縮効率が非常に低下する可能性がある。下記の表９は、一般的な映像のサイズを表す。
【０２０１】
【表９】
2021519035.tif 000011
【０２０２】
本発明の実施形態では、ＣＴＵのサイズが６４×６４、１２８×１２８である場合を中心に説明するが、本発明がこれに制限されるものではなく、２５６×２５６、５１２×５１２である場合にも同様に適用されることができる。８ｋ映像の場合、７６８０×４３２０解像度を有することができ、このとき、最も下のＣＴＵラインに属するＣＴＵは、全てのＣＴＵが映像の境界を外れることができる。この場合、上述した実施形態などが適用され得る。同様に、この場合、４０９６×２１６０解像度を有する４ｋ映像、３８４０×２１６０解像度を有するＵＨＤ映像、１９２０×１０８０解像度を有するＦＨＤ映像などの場合にも、最も下のＣＴＵラインに属するＣＴＵは、全てのＣＴＵが映像の境界を外れることができ、上述した実施形態などが適用され得る。
【０２０３】
第６実施形態
【０２０４】
図２０は、本発明が適用される一実施形態であって、非対称ツリー（asymmetric-tree）に基づくブロック分割構造を例示する図である。
【０２０５】
図２０に示すように、ＡＴは、ｈｏｒｉｚｏｎｔａｌ−ｕｐ  ＡＴ（２Ｎ×１／２Ｎ、２Ｎ×３／２Ｎ）、ｈｏｒｉｚｏｎｔａｌ−ｄｏｗｎ  ＡＴ（２Ｎ×３／２Ｎ、２Ｎ×１／２Ｎ）、ｖｅｒｔｉｃａｌ−ｌｅｆｔ  ＡＴ（１／２Ｎ×２Ｎ、３／２Ｎ×２Ｎ）、ｖｅｒｔｉｃａｌ−ｒｉｇｈｔ  ＡＴ（３／２Ｎ×２Ｎ、１／２Ｎ×２Ｎ）の４つの形態の分割を有することができる。
【０２０６】
一例として、ＱＴによってそれ以上分割されないブロックＢ３は、ｖｅｒｔｉｃａｌ  ＡＴ（Ｃ０、Ｃ１）またはｈｏｒｉｚｏｎｔａｌ  ＡＴ（Ｄ０、Ｄ１）に分割されることができる。ブロックＣ１のように、それぞれのサブブロックは、ｈｏｒｉｚｏｎｔａｌ  ＡＴ（Ｅ０、Ｅ１）またはｖｅｒｔｉｃａｌ  ＴＴ（Ｆ０、Ｆ１）の形態のように再帰的にさらに分割されることができる。
【０２０７】
図２１〜図２３は、本発明が適用され得る一実施形態に係るブロック分割の例を示す図である。
【０２０８】
図２１〜図２３に示すように、ＢＴ、ＴＴ、ＡＴ分割は、共に使用して分割が可能である。例えば、ＢＴにより分割されたサブブロックは、ＴＴまたはＡＴによる分割が可能である。また、ＴＴにより分割されたサブブロックは、ＢＴまたはＡＴによる分割が可能である。ＡＴにより分割されたサブブロックは、ＢＴまたはＴＴによる分割が可能である。
【０２０９】
図２１〜図２３において、実線で表現された分割は、１番目の分割を表し、点線で表現された分割は、１番目の分割により生成されたサブブロックの２番目の分割を表す。例えば、図２１（１）ないし（４）は、水平ＢＴ分割以後、それぞれのサブブロックが、垂直ＢＴ、垂直ＴＴ、垂直左側ＡＴ、垂直右側ＡＴ分割されることを図示する。図２１（５）ないし（８）は、水平ＴＴ分割以後、それぞれのサブブロックが、垂直ＢＴ、垂直ＴＴ、垂直左側ＡＴ、垂直右側ＡＴ分割されることを図示する。
【０２１０】
図２１（９）ないし（１２）は、水平上側ＡＴ分割以後、それぞれのサブブロックが、垂直ＢＴ、垂直ＴＴ、垂直左側ＡＴ、垂直右側ＡＴ分割されることを図示する。図２２（１３）ないし（１６）は、水平下側ＡＴ分割以後、それぞれのサブブロックが、垂直ＢＴ、垂直ＴＴ、垂直左側ＡＴ、垂直右側ＡＴ分割されることを図示する。
【０２１１】
図２２（１７）ないし（２０）は、垂直ＢＴ分割以後、それぞれのサブブロックが、水平ＢＴ、水平ＴＴ、水平上側ＡＴ、水平下側ＡＴ分割されることを図示する。図２２（２１）ないし（２４）は、垂直ＴＴ分割以後、それぞれのサブブロックが、水平ＢＴ、水平ＴＴ、水平上側ＡＴ、水平下側ＡＴ分割されることを図示する。
【０２１２】
図２３（２５）ないし（２８）は、垂直左側ＡＴ分割以後、それぞれのサブブロックが、水平ＢＴ、水平ＴＴ、水平上側ＡＴ、水平下側ＡＴ分割されることを図示する。図２３（２９）ないし（３２）は、垂直右側ＡＴ分割以後、それぞれのサブブロックが、水平ＢＴ、水平ＴＴ、水平上側ＡＴ、水平下側ＡＴ分割されることを図示する。
【０２１３】
第７実施形態
【０２１４】
様々な構造のブロック分割を介して分割の自由度を高めることにより圧縮効率を上げることができるのに対し、向上した分割自由度による複雑度の増加が問題になり得る。したがって、本発明の一実施形態において、ＱＴ構造に基づいてブロック分割を行うのにあたって、性能と複雑度との間の関係を考慮して、ＱＴ分割程度を調整するシンタックスを送信する方法を提案する。
【０２１５】
実施形態として、エンコーダは、最大ＱＴブロックサイズ（ＭａｘＱＴＳｉｚｅ）、最小ＱＴブロックサイズ（ＭｉｎＱＴＳｉｚｅ）、および最大ＱＴブロック分割深さ（ＭａｘＱＴＤｅｐｔｈ）シンタックス（または、シンタックス要素）のうちの少なくとも１つをデコーダへ送信することができる。ここで、最大ＱＴブロックサイズは、ＱＴ分割が行われ得るブロックの最大サイズを表し、対数（ログスケール）の形態（例えば、ｌｏｇ２）で表現されることができる。最小ＱＴブロックサイズは、ＱＴ分割が行われ得るブロックの最小サイズを表し、対数の形態（例えば、ｌｏｇ２）で表現されることができる。また、最大ＱＴ分割深さは、最大ＱＴブロックサイズから何回のＱＴ分割を許容するかを表す。
【０２１６】
また、実施形態として、エンコーダは、最大ＢＴブロックサイズ（ＭａｘＢＴＳｉｚｅ）、最小ＢＴブロックサイズ（ＭｉｎＢＴＳｉｚｅ）、および最大ＢＴブロック分割深さ（ＭａｘＢＴＤｅｐｔｈ）シンタックス（または、シンタックス要素）のうちの少なくとも１つをデコーダへ送信することができる。ここで、最大ＢＴブロックサイズは、ＢＴ分割が許容されるブロックの最大サイズを表し、対数の形態（例えば、ｌｏｇ２）で表現されることができる。最小ＢＴブロックサイズは、ＢＴ分割が許容されるブロックの最小サイズを表し、対数の形態（例えば、ｌｏｇ２）で表現されることができる。また、最大ＢＴ分割深さは、最大ＢＴブロックサイズから何回のＢＴ分割を許容するかを表す。
【０２１７】
また、実施形態として、エンコーダは、最大ＴＴブロックサイズ（ＭａｘＴＴＳｉｚｅ）、最小ＴＴブロックサイズ（ＭｉｎＴＴＳｉｚｅ）、および最大ＴＴブロック分割深さ（ＭａｘＴＴＤｅｐｔｈ）シンタックス（または、シンタックス要素）のうちの少なくとも１つをデコーダへ送信することができる。ここで、最大ＴＴブロックサイズは、ＴＴ分割が許容されるブロックの最大サイズを表し、対数の形態（例えば、ｌｏｇ２）で表現されることができる。最小ＴＴブロックサイズは、ＴＴ分割が許容されるブロックの最小サイズを表し、対数の形態（例えば、ｌｏｇ２）で表現されることができる。また、最大ＴＴ分割深さは、最大ＴＴブロックサイズから何回のＴＴ分割を許容するかを表す。
【０２１８】
それぞれのシンタックス情報は、スライス（または、タイルグループ）、タイル、映像コンポーネント（component）の種類によって、シーケンスパラメータセット（Sequence Parameter Set、ＳＰＳ）、ピクチャパラメータセット（Picture Parameter Set、ＰＰＳ）、スライスヘッダ（Slice Header、ＳＨ）（または、タイルグループヘッダ（Tile Group Header、ＴＧＨ）、またはネットワーク抽象化層（Network Abstract Layer、ＮＡＬ）単位（ユニット）のヘッダなどを介して送信されることができる。
【０２１９】
第８実施形態
【０２２０】
前述した第７実施形態では、映像でＱＴ、ＢＴ、ＴＴ分割に対する最大サイズまたは最小サイズまたは最大分割許容深さに関するシンタックスを定義する。本発明において、ｃｏｄｉｎｇ  ｕｎｉｔ（ＣＵ）、ｐｒｅｄｉｃｔｉｏｎ  ｕｎｉｔ（ＰＵ）、ｔｒａｎｓｆｏｒｍ  ｕｎｉｔ（ＴＵ）のブロックサイズは、同一でありうるし、そうでないこともできる。
【０２２１】
本発明の一実施形態では、ＣＵ、ＴＵ、ＰＵのサイズが異なる場合、エンコーダおよびデコーダは、性能と複雑度との関係を考慮して、ＣＵ、ＰＵ、ＴＵの分割程度を調整するシンタックスを送信する方法を提案する。本発明において、ＴＵは、エンコーダからシグナリングされた分割情報によって、ツリー構造（例えば、ＱＴ、ＱＴＢＴ、ＱＴＢＴ＋ＴＴなど）で分割されて変換が行われる単位を意味することができ、または、ＴＵは、変換カーネル（または、変換行列）のサイズによって暗示的に分割されて変換が行われる単位を意味することもできる。
【０２２２】
一実施形態において、ＴＵがエンコーダからシグナリングされた分割情報によってツリー構造で分割されて変換が行われる単位を意味する場合、ＣＵ、ＰＵなどのブロックは、シグナリングされた分割情報によって再帰的に分割されることができる。
【０２２３】
他の一実施形態において、ＴＵが変換カーネルのサイズによって暗示的に分割されて変換が行われる単位を意味する場合、エンコーダとデコーダとは、分割情報のシグナリングなしで記憶された変換カーネルのサイズに基づいて、ＣＵ、ＰＵなどのブロックを同一に分割することができる。すなわち、変換カーネルサイズは、従属的にＴＵ分割が決定され得る。例えば、ＣＵまたはＰＵのサイズが１２８×１２８であり、適用可能な（または、予め決められた）変換カーネルの最大サイズが６４×６４である場合、変換のための別の分割情報シグナリングなしで、エンコーダとデコーダとは、ＣＵまたはＰＵを４個の６４×６４ブロックに分割した後、変換を行うことができる。下記の図面において変換のための暗示的分割方法の一例を説明する。
【０２２４】
図２４は、本発明が適用される一実施形態であって、シンタックスシグナリングなしで、最大変換ブロックサイズに基づいてブロック分割が許容されるか否かを決定する方法を例示する図である。
【０２２５】
図２４に示すように、デコーダは、現ブロックサイズが最大変換サイズ（または、変換カーネルの最大サイズ、変換行列の最大サイズ）より大きいか否かを確認できる（Ｓ２４０１）。
【０２２６】
デコーダは、現ブロックサイズが最大変換サイズより大きい場合、現ブロックを分割できる（Ｓ２４０２）。このとき、デコーダは、現ブロックを最大変換サイズ単位で分割することができる。現ブロックは、ただ逆変換するときにのみ最大変換サイズ単位で分割されることもできる。デコーダは、分割されたブロックに対して逆変換を行うことができる（Ｓ２４０３）。
【０２２７】
一方、Ｓ２４０１ステップにおいて、現ブロックサイズが最大変換サイズより大きくない場合、デコーダは、現ブロックに対して逆変換を行うことができる。
【０２２８】
一実施形態において、最大ＣＵブロックサイズ（ＭａｘＣＵＳｉｚｅ）、最小ＣＵブロックサイズ（ＭｉｎＣＵＳｉｚｅ）、最大ＣＵブロック分割深さ（ＭａｘＣＵＤｅｐｔｈ）などのシンタックスが送信され得る。より詳細には、最大ＣＵブロックサイズは、映像を初めて分割する最大ブロックのサイズを意味し、ｌｏｇ２のスケールの形態で表現されることができる。これは、最大ＱＴブロックサイズ（ＭａｘＱＴＳｉｚｅ）、最小ＱＴブロックサイズ（ＭｉｎＱＴＳｉｚｅ）、最大ＱＴブロック分割深さ（ＭａｘＱＴＤｅｐｔｈ）などのシンタックスと同様に使用されるか、代替されて使用されることができる。
【０２２９】
他の一実施形態において、最大ＰＵブロックサイズ（ＭａｘＰＵＳｉｚｅ）、最小ＰＵブロックサイズ（ＭｉｎＰＵＳｉｚｅ）、最大ＰＵブロック分割深さ（ＭａｘＰＵＤｅｐｔｈ）などのシンタックスが送信され得る。より詳細には、最大ＰＵブロックサイズは、映像を初めて分割する最大ブロックのサイズを意味し、ｌｏｇ２のスケールの形態で表現されることができる。例えば、最大ＰＵサイズより最大ＣＵサイズが大きい場合、当該ＣＵは、最大ＰＵまでシグナリング情報なしで暗示的に分割されることができる。具体的には、最大ＰＵサイズが６４×６４であり、最大ＣＵサイズは１２８×１２８であるとき、１２８×１２８ブロックは、４個の６４×６４のＰＵを使用して予測が行われ得る。あるいは、当該ブロックは、暗示的に４個のｓｕｂ−ＰＵに分割されることができる。１２８×６４ブロックは、２個の６４×６４のＰＵを使用して予測が行われ得る。１２８×３２ブロックは、２個の６４×３２のＰＵを使用したり、４個の３２×３２のＰＵを使用して予測が行われ得る。ＣＵとＰＵとが同じである場合、上記シンタックスは、送信されないことができる。あるいは、明示的にシンタックスを送信することができる。
【０２３０】
他の一実施形態において、最大ＴＵブロックサイズ（ＭａｘＴＵＳｉｚｅ）、最小ＴＵブロックサイズ（ＭｉｎＴＵＳｉｚｅ）、最大ＴＵブロック分割深さ（ＭａｘＴＵＤｅｐｔｈ）などのシンタックスが送信され得る。より詳細には、最大ＴＵブロックサイズは、映像を初めて分割する最大ブロックのサイズを意味し、ｌｏｇ２のスケールの形態で表現されることができる。例えば、最大ＴＵサイズより最大ＣＵサイズが大きい場合、当該ＣＵは、最大ＴＵまでシグナリング情報なしで暗示的に分割されることができる。具体的には、最大ＴＵサイズが６４×６４であり、最大ＣＵサイズは１２８×１２８であるとき、１２８×１２８ブロックは、４個の６４×６４のＴＵを使用して変換が行われ得る。あるいは、当該ブロックは、暗示的に４個のｓｕｂ−ＣＵに分割されることができる。１２８×６４ブロックは、２個の６４×６４のＴＵを使用して変換が行われ得る。１２８×３２ブロックは、２個の６４×３２のＴＵを使用したり、４個の３２×３２のＴＵを使用して変換が行われ得る。ＣＵとＴＵとが同じである場合、上記シンタックスは、送信されないことができる。あるいは、明示的にシンタックスを送信することができる。
【０２３１】
他の一実施形態において、最大サイズＣＵ（または、ＣＴＵ）でＴＴまたはＡＴ分割されたＣＵに対して、変換サイズに基づいた暗示的分割が行われ得る。例えば、最大サイズＣＵが１２８×１２８であり、１回のＴＴ分割のみ行われるならば、２個の３２×１２８ＣＵと１個の６４×１２８ＣＵとが生成され得る。変換カーネルの最大サイズを６４×６４であると仮定するとき、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、３２×１２８ＣＵを、２個の６４×３２のＴＵに分割するか、または４個の３２×３２のＴＵに分割することができる。この場合、適用可能な変換カーネル単位または予め決められたサイズ単位でＴＵ分割が決定され得る。そして、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、６４×１２８ＣＵを２個の６４×６４のＴＵに分割することができる。
【０２３２】
また、例えば、最大サイズＣＵが１２８×１２８であり、１回のＡＴ分割のみ行われるならば、１個の３２×１２８ＣＵと１個の９６×１２８ＣＵとが生成され得る。変換カーネルの最大サイズを６４×６４であると仮定するとき、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、３２×１２８ＣＵを、２個の６４×３２のＴＵに分割するか、または４個の３２×３２のＴＵに分割することができる。この場合、適用可能な変換カーネル単位または予め決められたサイズ単位でＴＵ分割が決定され得る。そして、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、９６×１２８ＣＵを、２個の６４×６４のＴＵと２個の６４×３２のＴＵとに分割するか、２個の６４×６４のＴＵと４個の３２×３２のＴＵとに分割することができる。
【０２３３】
また、最大ＴＵサイズより最大ＰＵサイズが大きい場合、当該ＰＵは、最大ＴＵまでシグナリング情報なしで暗示的に分割されることができる。具体的には、最大ＴＵサイズが６４×６４であり、最大ＰＵサイズは１２８×１２８であるとき、１２８×１２８ブロックは、４個の６４×６４のＴＵを使用して変換が行われ得る。あるいは、当該ブロックは、暗示的に４個のｓｕｂ−ＰＵに分割されることができる。１２８×６４ブロックは、２個の６４×６４のＴＵを使用して変換が行われ得る。１２８×３２ブロックは、２個の６４×３２のＴＵを使用するか、４個の３２×３２のＴＵを使用して変換が行われ得る。ＰＵとＴＵとが同じである場合、上記シンタックスは、送信されないことができる。あるいは、明示的にシンタックスを送信することができる。
【０２３４】
一実施形態において、最大サイズＰＵでＴＴまたはＡＴ分割されたＰＵに対して、変換サイズに基づいた暗示的分割が行われ得る。例えば、最大サイズＰＵが１２８×１２８であり、１回のＴＴ分割のみが行われるならば、２個の３２×１２８ＰＵと１個の６４×１２８ＰＵとが生成され得る。変換カーネルの最大サイズを６４×６４であると仮定するとき、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、３２×１２８ＰＵを、２個の６４×３２のＴＵに分割するか、または４個の３２×３２のＴＵに分割することができる。この場合、適用可能な変換カーネル単位または予め決められたサイズ単位でＴＵ分割が決定され得る。そして、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、６４×１２８ＰＵを２個の６４×６４のＴＵに分割することができる。
【０２３５】
また、例えば、最大サイズＰＵが１２８×１２８であり、１回のＡＴ分割のみ行われるならば、１個の３２×１２８ＰＵと１個の９６×１２８ＰＵとが生成され得る。変換カーネルの最大サイズを６４×６４であると仮定するとき、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、３２×１２８ＰＵを、２個の６４×３２のＴＵに分割するか、または４個の３２×３２のＴＵに分割することができる。この場合、適用可能な変換カーネル単位または予め決められたサイズ単位でＴＵ分割が決定され得る。そして、変換実行の際、エンコーダ／デコーダは、別のシグナリングなしで、９６×１２８ＰＵを、２個の６４×６４のＴＵと２個の６４×３２のＴＵとに分割するか、２個の６４×６４のＴＵと４個の３２×３２のＴＵとに分割することができる。
【０２３６】
また、最小ＴＵサイズよりＰＵのサイズが小さい場合、当該ブロックは、最小ＴＵを満たす種々のブロックを合わせて行われることができる。あるいは、最小ＴＵサイズより小さいＰＵの分割を許容しないことができる。具体的には、最小ＴＵサイズが８×８であり、最小ＰＵサイズが４×４であるとき、４個の４×４ブロックを集めて１つの８×８のＴＵを使用して変換が行われ得る。あるいは、当該ブロックは、暗示的に４×４ＰＵへの分割を制限できる。
【０２３７】
上記シンタックス情報を利用してエンコーダの複雑度を減らすことができ、デコーダでは、暗示的にブロックの分割情報を導くことができるので、ビット低減効果がありうる。
【０２３８】
それぞれのシンタックス情報は、スライス（または、タイルグループ）、タイル、映像コンポーネント（component）の種類によって、シーケンスパラメータセット（Sequence Parameter Set、ＳＰＳ）、ピクチャパラメータセット（Picture Parameter Set、ＰＰＳ）、スライスヘッダ（Slice Header、ＳＨ）（または、タイルグループヘッダ（Tile Group Header、ＴＧＨ）、またはネットワーク抽象化層（Network Abstract Layer、ＮＡＬ）単位のヘッダなどを介して送信されることができる。
【０２３９】
以上で説明した本発明の実施形態などは、説明の都合上、それぞれの実施形態を区分して説明したが、本発明がこれに制限されるものではない。言い換えれば、前述した第１実施形態〜第８実施形態は、各々独立して行われることができ、１つまたは複数の種々の実施形態が組み合わせられて行われることもできる。
【０２４０】
図２５は、本発明が適用される実施形態に係るビデオ信号のデコード方法を例示するフローチャートである。
【０２４１】
図２５に示すように、説明の都合上、デコーダを中心に説明するが、本発明がこれに限定されるものではなく、本発明の実施形態に係るビデオ信号のデコード方法は、エンコーダとデコーダとで同一に行われることができる。
【０２４２】
デコーダは、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、上記現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、上記現コーディングツリーブロックを複数のコーディングブロックに分割する（Ｓ２５０１）。
【０２４３】
デコーダは、現コーディングブロックが予め設定された条件を満たす場合、上記現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングする（Ｓ２５０２）。
【０２４４】
デコーダは、上記第１のシンタックス要素が上記現コーディングブロックが分割されることを指示する場合、上記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングする（Ｓ２５０３）。
【０２４５】
デコーダは、上記第２のシンタックス要素が上記現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、上記現コーディングブロックが、二分木（binary-tree）構造を利用して分割されるか、または三分木（ternary-tree）構造を利用して分割されるかを指示する第３のシンタックス要素と、上記現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングする（Ｓ２５０４）。
【０２４６】
デコーダは、上記第１のシンタックス要素、上記第２のシンタックス要素、上記第３のシンタックス要素、および上記第４のシンタックス要素のうちの少なくとも１つに基づいて、上記現コーディングブロックの分割モード（split mode）を決定する（Ｓ２５０５）。
【０２４７】
先に第５実施形態で説明したように、上記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、上記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、上記現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割することにより行われ、ここで、上記有効な領域は、上記現コーディングツリーブロック内で上記現ピクチャの境界内に属する領域を表すことができる。
【０２４８】
また、先に第５実施形態で説明したように、上記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否かを指示する第５のシンタックス要素をパージングするステップをさらに含み、上記第５のシンタックス要素が四分木分割が許容されないことを指示する場合、上記現コーディングツリーブロックは、二分木構造または三分木構造を利用して複数のコーディングブロックに分割されることができる。
【０２４９】
また、先に第５実施形態で説明したように、上記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされることができる。
【０２５０】
また、先に第５実施形態で説明したように、上記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、上記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、上記現コーディングツリーブロックを四分木構造を利用して複数のコーディングブロックに分割することにより行われ、ここで、上記有効な領域は、上記現コーディングツリーブロック内で上記現ピクチャの境界内に属する領域を表すことができる。
【０２５１】
また、先に第５実施形態で説明したように、上記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、上記有効な領域の幅（width）が最大変換サイズより大きいか、または上記有効な領域の高さ（height）が上記最大変換サイズより大きい場合、上記現コーディングツリーブロックを四分木構造を利用してコーディングブロックに分割することにより行われることができる。
【０２５２】
また、一実施形態において、上記第１のシンタックス要素値が０であれば、現ブロックは分割されず、上記第１のシンタックス要素値が１であれば、現ブロックは、四分木構造を利用して４個のサブブロックに分割されるか、二分木構造を利用して２個のサブブロックに分割されるか、または三分木構造を利用して３個のサブブロックに分割されることができる。
【０２５３】
また、一実施形態において、上記予め設定された条件は、現ブロックの左上端サンプルの水平方向座標に上記現ブロックの幅（width）を加算した値が現ピクチャの幅より小さいか、同じであり、そして、現ブロックの左上端サンプルの垂直方向座標に現ブロックの高さ（height）を加算した値が現ピクチャの高さより小さいか、同じである場合に満たされることができる。
【０２５４】
また、一実施形態において、デコーダは、現ブロックの分割構造決定のためのコーディングツリーユニットシンタックスを呼び出すことができる。この場合、現ブロックに対するコーディングツリーユニットシンタックスを呼び出すステップがＳ１５０１ステップに先立って行われ得る。
【０２５５】
また、一実施形態において、第１のシンタックス要素が上記現ブロックが分割されないことを指示する場合、デコーダは、現ブロックのデコーディングプロセスのためのコーディングユニットシンタックス（coding unit syntax）を呼び出すことができる。
【０２５６】
また、一実施形態において、デコーダは、上記分割モードに基づいて現ブロックから分割されたサブブロックの分割構造決定のためのコーディングツリーユニット（Coding tree unit）シンタックスを呼び出すことができる。
【０２５７】
また、一実施形態において、上記第１のシンタックス要素、上記第２のシンタックス要素、上記第３のシンタックス要素、および上記第４のシンタックス要素は、同じレベルのシンタックスでパージングされることができる。
【０２５８】
図２６は、本発明が適用される実施形態に係るビデオ信号のデコード装置を例示する図である。
【０２５９】
図２６では、説明の都合上、デコード装置を１つのブロックで図示したが、図２６に示されたデコード装置は、エンコーダおよび／またはデコーダに含まれる構成で実現されることができる。
【０２６０】
図２６に示すように、デコード装置は、先に図１〜図２５において提案された機能、過程、および／または方法を実現する。具体的には、デコード装置は、コーディングツリーブロック分割部２６０１、シンタックス要素パージング部２６０２、分割モード決定部２６０３を備えて構成されることができる。また、一実施形態において、コーディングツリーブロック分割部２６０１、上記シンタックス要素パージング部２６０２は、上記分割モード決定部２６０３に含まれる構成で実現されることもできる。
【０２６１】
コーディングツリーブロック分割部２６０１は、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、上記現コーディングツリーブロックから分割されたコーディングブロックが現ピクチャ内に含まれるように、上記現コーディングツリーブロックを複数のコーディングブロックに分割する。
【０２６２】
シンタックス要素パージング部２６０２は、現コーディングブロックが予め設定された条件を満たす場合、上記現コーディングブロックが複数のサブブロックに分割されるか否かを指示する第１のシンタックス要素（syntax element）をパージングする。
【０２６３】
シンタックス要素パージング部２６０２は、上記第１のシンタックス要素が上記現コーディングブロックが分割されることを指示する場合、上記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かを指示する第２のシンタックス要素をパージングする。
【０２６４】
シンタックス要素パージング部２６０２は、上記第２のシンタックス要素が上記現コーディングブロックが四分木構造を利用して分割されないことを指示する場合、上記現コーディングブロックが、二分木（binary-tree）構造を利用して分割されるか、または三分木（ternary-tree）構造を利用して分割されるかを指示する第３のシンタックス要素と、上記現コーディングブロックの分割方向を指示する第４のシンタックス要素と、のうちの少なくとも１つをパージングする。
【０２６５】
分割モード決定部２６０３は、上記第１のシンタックス要素、上記第２のシンタックス要素、上記第３のシンタックス要素、および上記第４のシンタックス要素のうちの少なくとも１つに基づいて上記現コーディングブロックの分割モード（split mode）を決定する。
【０２６６】
先に第５実施形態で説明したように、上記コーディングツリーブロック分割部２６０１は、上記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、上記現コーディングツリーブロックを二分木構造または三分木構造を利用して複数のコーディングブロックに分割することができる。ここで、上記有効な領域は、上記現コーディングツリーブロック内で上記現ピクチャの境界内に属する領域を表すことができる。
【０２６７】
また、先に第５実施形態で説明したように、上記コーディングツリーブロック分割部２６０１は、現コーディングツリーブロックが現ピクチャの境界（boundary）を外れる場合、四分木分割が許容されるか否かを指示する第５のシンタックス要素をパージングできる。上記第５のシンタックス要素が四分木分割が許容されないことを指示する場合、上記現コーディングツリーブロックは、二分木構造または三分木構造を利用して複数のコーディングブロックに分割されることができる。
【０２６８】
また、先に第５実施形態で説明したように、上記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされることができる。
【０２６９】
また、先に第５実施形態で説明したように、上記コーディングツリーブロック分割部２６０１は、上記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、上記現コーディングツリーブロックを四分木構造を利用して複数のコーディングブロックに分割することができる。ここで、上記有効な領域は、上記現コーディングツリーブロック内で上記現ピクチャの境界内に属する領域を表すことができる。
【０２７０】
また、先に第５実施形態で説明したように、上記コーディングツリーブロック分割部２６０１は、上記有効な領域の幅（width）が最大変換サイズより大きいか、または上記有効な領域の高さ（height）が上記最大変換サイズより大きい場合、上記現コーディングツリーブロックを四分木構造を利用してコーディングブロックに分割することができる。
【０２７１】
また、一実施形態において、上記第１のシンタックス要素値が０であれば、現ブロックは分割されず、上記第１のシンタックス要素値が１であれば、現ブロックは、四分木構造を利用して４個のサブブロックに分割されるか、二分木構造を利用して２個のサブブロックに分割されるか、または三分木構造を利用して３個のサブブロックに分割されることができる。
【０２７２】
また、一実施形態において、上記予め設定された条件は、現ブロックの左上端サンプルの水平方向座標に上記現ブロックの幅（width）を加算した値が現ピクチャの幅より小さいか、同じであり、そして、現ブロックの左上端サンプルの垂直方向座標に現ブロックの高さ（height）を加算した値が現ピクチャの高さより小さいか、同じである場合、満たされることができる。
【０２７３】
また、一実施形態において、デコーダは、現ブロックの分割構造決定のためのコーディングツリーユニットシンタックスを呼び出すことができる。この場合、現ブロックに対するコーディングツリーユニットシンタックスを呼び出すステップが、Ｓ１５０１ステップに先立って行われることができる。
【０２７４】
また、一実施形態において、第１のシンタックス要素が上記現ブロックが分割されないことを指示する場合、デコーダは、現ブロックのデコーディングプロセスのためのコーディングユニットシンタックス（coding unit syntax）を呼び出すことができる。
【０２７５】
また、一実施形態において、デコーダは、上記分割モードに基づいて現ブロックから分割されたサブブロックの分割構造決定のためのコーディングツリーユニット（Coding tree unit）シンタックスを呼び出すことができる。
【０２７６】
また、一実施形態において、上記第１のシンタックス要素、上記第２のシンタックス要素、上記第３のシンタックス要素、および上記第４のシンタックス要素は、同じレベルのシンタックスでパージングされることができる。
【０２７７】
図２７は、本発明が適用されるビデオコーディングシステムを示す。
【０２７８】
ビデオコーディングシステムは、ソースデバイス（source device）および受信デバイス（receiving device）を含み得る。ソースデバイスは、エンコードされたビデオ／映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して、受信デバイスに伝達できる。
【０２７９】
上記ソースデバイスは、ビデオソース（video source）、エンコード装置（encoding apparatus）、送信部（transmitter）を含み得る。上記受信デバイスは、受信部（receiver）、デコード装置（decoding apparatus）およびレンダラ（renderer）を含み得る。上記エンコード装置は、ビデオ／映像のエンコード装置と呼ばれることがあり、上記デコード装置は、ビデオ／映像のデコード装置と呼ばれることがある。送信器は、エンコード装置に含まれ得る。受信器は、デコード装置に含まれ得る。レンダラは、ディスプレイ部を含むこともあり、ディスプレイ部は、別のデバイスまたは外部コンポーネントで構成されることもある。
【０２８０】
ビデオソースは、ビデオ／映像のキャプチャ、合成または生成過程などを通じて、ビデオ／映像を獲得することができる。ビデオソースは、ビデオ／映像キャプチャデバイスおよび／またはビデオ／映像生成デバイスを含み得る。ビデオ／映像キャプチャデバイスは、例えば、一つまたは複数のカメラ、以前にキャプチャされたビデオ／映像を含むビデオ／映像アーカイブなどを含み得る。ビデオ／映像生成デバイスは、例えば、コンピュータ、タブレット、およびスマートフォンなどを含み得、（電子的に）ビデオ／映像を生成し得る。例えば、コンピュータなどを介して仮想のビデオ／映像が生成され得、この場合、関連のデータが生成される過程として、ビデオ／映像キャプチャ過程に代えることができる。
【０２８１】
エンコード装置は、入力ビデオ／映像をエンコードできる。エンコード装置は、圧縮およびコーディング効率のために、予測、変換、量子化などの一連の手続を行うことができる。エンコードされたデータ（エンコードされたビデオ／映像情報）は、ビットストリーム（bitstream）の形態で出力され得る。
【０２８２】
送信部は、ビットストリームの形態で出力されたエンコードされたビデオ／映像情報またはデータを、ファイルまたはストリーミングの形態でデジタル記憶媒体またはネットワークを介して受信デバイスの受信部に伝達できる。デジタル記憶媒体は、ＵＳＢ、ＳＤ、ＣＤ、ＤＶＤ、ブルーレイ、ＨＤＤ、ＳＳＤなどの様々な記憶媒体を含み得る。送信部は、予め決められたファイルフォーマットを介して、メディアファイルを生成するためのエレメントを含んでもよく、放送／通信ネットワークを介した送信のためのエレメントを含み得る。受信部は、上記ビットストリームを抽出してデコード装置に伝達できる。
【０２８３】
デコード装置は、エンコード装置の動作に対応する逆量子化、逆変換、予測等一連の手続を行って、ビデオ／映像をデコードできる。
【０２８４】
レンダラは、デコードされたビデオ／映像をレンダリングできる。レンダリングされたビデオ／映像は、ディスプレイ部を介して表示されることができる。
【０２８５】
図２８は、本発明が適用される実施例であって、コンテンツストリーミングシステムの構造図を示す。
【０２８６】
図２８を参照すると、本発明が適用されるコンテンツストリーミングシステムは、概して、エンコードサーバ、ストリーミングサーバ、ウェブサーバ、メディアストレージ、ユーザ装置、およびマルチメディア入力装置を含み得る。
【０２８７】
上記エンコードサーバは、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置から入力されたコンテンツをデジタルデータに圧縮してビットストリームを生成し、これを上記ストリーミングサーバに送信する役割を果たす。別の例として、スマートフォン、カメラ、カムコーダなどのマルチメディア入力装置がビットストリームを直接生成する場合、上記エンコードサーバは、省略され得る。
【０２８８】
上記ビットストリームは、本発明が適用されるエンコード方法またはビットストリーム生成方法により生成され得、上記ストリーミングサーバは、上記ビットストリームを送信または受信する過程で、一時的に上記ビットストリームを記憶し得る。
【０２８９】
上記ストリーミングサーバは、ウェブサーバを介したユーザの要求に基づいて、マルチメディアデータをユーザ装置に送信し、上記ウェブサーバは、ユーザにどのようなサービスがあるかを知らせる媒介体の役割を果たす。ユーザが上記ウェブサーバに望むサービスを要求すると、上記ウェブサーバは、これをストリーミングサーバに伝達し、上記ストリーミングサーバは、ユーザにマルチメディアデータを送信する。その際、上記コンテンツストリーミングシステムは、別の制御サーバを含んでもよく、この場合、上記制御サーバは、上記コンテンツストリーミングシステム内の各装置間の命令／応答を制御する役割を果たす。
【０２９０】
上記ストリーミングサーバは、メディアストレージおよび／またはエンコードサーバからコンテンツを受信できる。例えば、上記エンコードサーバからコンテンツを受信することになる場合、上記コンテンツをリアルタイムで受信できる。この場合、円滑なストリーミングサービスを提供するために、上記ストリーミングサーバは、上記ビットストリームを一定時間記憶できる。
【０２９１】
上記ユーザ装置の例としては、携帯電話、スマートフォン（smart phone）、ラップトップパソコン（laptop computer）、デジタル放送用端末機、ＰＤＡ（Personal Digital Assistants）、ＰＭＰ（Portable Multimedia Player）、ナビゲーション、スレートＰＣ（slate PC）、タブレットＰＣ（tablet PC）、ウルトラブック（ULTRABOOK（登録商標））、ウェアラブルデバイス（wearable device、例えば、スマートウォッチ（ウォッチ型端末機）（smartwatch）、スマートグラス（ガラス型端末機）（smart glass）、ＨＭＤ（Head Mounted Display））、デジタルＴＶ、デスクトップコンピュータ、デジタルサイネージなどがあり得る。
【０２９２】
上記コンテンツストリーミングシステム内の各サーバは、分散サーバとして運用されることができ、この場合、各サーバで受信するデータは、分散処理されることができる。
【０２９３】
上記記述されたように、本発明で説明した実施例は、プロセッサ、マイクロプロセッサ、コントローラまたはチップ上で実現され行われ得る。例えば、各図で示した機能ユニットは、コンピュータ、プロセッサ、マイクロプロセッサ、コントローラまたはチップ上で実現され行われ得る。
【０２９４】
また、本発明が適用されるデコーダおよびエンコーダは、マルチメディア放送の送受信装置、モバイル通信端末、ホームシネマビデオ装置、デジタルシネマビデオ装置、監視用カメラ、ビデオ対話装置、ビデオ通信などのリアルタイム通信装置、モバイルストリーミング装置、記憶媒体、カムコーダ、ビデオオンデマンド（オーダメイド型ビデオ）（ＶｏＤ）サービス提供装置、ＯＴＴビデオ（Over The Top video）装置、インターネットストリーミングサービス提供装置、３次元（３Ｄ）ビデオ装置、画像電話ビデオ装置、および医療用ビデオ装置などに含まれ得、ビデオ信号またはデータ信号を処理するために使用され得る。例えば、ＯＴＴビデオ（Over The Top video）装置としては、ゲームコンソール、ブルーレイプレーヤ、インターネットアクセスＴＶ、ホームシアターシステム、スマートフォン、タブレットＰＣ、ＤＶＲ（Digital Video Recorder）などを含み得る。
【０２９５】
本発明が適用される処理方法は、コンピュータで実行されるプログラムの形態で生産されることができ、コンピュータが読み取れる記録媒体に記憶されることができる。本発明によるデータ構造を有するマルチメディアデータもまた、コンピュータが読み取れる記録媒体に記憶されることができる。上記コンピュータが読み取れる記録媒体は、コンピュータで読むことができるデータが記憶される全ての種類の記憶装置および分散記憶装置を含む。上記コンピュータが読み取れる記録媒体は、例えば、ブルーレイディスク（ＢＤ）、ユニバーサルシリアル（汎用直列）バス（ＵＳＢ）、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピ（登録商標）ディスク、および光学データ記憶装置を含み得る。また、上記コンピュータが読み取れる記録媒体は、搬送波（例えば、インターネットを介した送信）の形態で実現されたメディアを含む。また、エンコード方法で生成されたビットストリームが、コンピュータが読み取れる記録媒体に記憶されるか、有無線通信ネットワークを介して送信されることができる。
【０２９６】
また、本発明の実施例は、プログラムコードによるコンピュータプログラム製品で実現されることができ、上記プログラムコードは、本発明の実施例によってコンピュータで実行されることができる。上記プログラムコードは、コンピュータによって読み取り可能なキャリア上に記憶されることができる。
【０２９７】
以上で説明された実施例は、本発明の構成要素と特徴が所定の形態で結合されたものである。各構成要素または特徴は、別途の明示的言及がない限り、選択的なものとして考慮されるべきである。各構成要素または特徴は、他の構成要素や特徴と結合されない形態で実施され得る。また、一部の構成要素および／または特徴を結合し、本発明の実施例を構成することも可能である。本発明の実施例で説明される動作の順序は、変更され得る。いずれかの実施例の一部の構成や特徴は、他の実施例に含まれてもよく、または他の実施例の対応する構成もしくは特徴と置き換えられ（交替し）てもよい。特許請求の範囲で明示的な引用関係がない請求項を結合して実施例を構成するか、出願後の補正によって新しい請求項に含め得ることは、自明である。
【０２９８】
本発明による実施例は、多様な手段、例えば、ハードウェア、ファームウェア（firmware）、ソフトウェアまたはそれらの結合などにより実現され得る。ハードウェアによる実現の場合、本発明の一実施例は、一つまたは複数のＡＳＩＣｓ（Application Specific Integrated Circuits）、ＤＳＰｓ（Digital Signal Processors）、ＤＳＰＤｓ（Digital Signal Processing Devices）、ＰＬＤｓ（Programmable Logic Devices）、ＦＰＧＡｓ（Field Programmable Gate Arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより実現され得る。
【０２９９】
ファームウェアやソフトウェアによる実現の場合、本発明の一実施例は、以上で説明された機能または動作を行うモジュール、手続、関数などの形態で実現されることができる。ソフトウェアコードは、メモリに記憶され、プロセッサによって駆動されることができる。上記メモリは、上記プロセッサの内部または外部に位置し、既に公知となった多様な手段により上記プロセッサとデータをやり取りすることができる。
【０３００】
本発明は、本発明の必須的特徴を外れない範囲で、他の特定の形態で具体化できることは、当業者にとって自明である。したがって、前述した詳細な説明は、全ての面で制限的に解釈されてはならず、例示的なものと考慮されるべきである。本発明の範囲は、添付された請求項の合理的解釈によって決定されなければならず、本発明の等価的範囲内における全ての変更は、本発明の範囲に含まれる。
【産業上の利用可能性】
【０３０１】
以上、前述した本発明の好ましい実施例は、例示の目的のために開示されたもので、当業者であれば、以下に添付される特許請求の範囲に開示された本発明の技術的思想とその技術的範囲内で、多様な他の実施例の改良、変更、代替または付加などが可能である。
【図１】
2021519035.tif 000012
【図２】
2021519035.tif 000013
【図３】
2021519035.tif 000014
【図４】
2021519035.tif 000015
【図５】
2021519035.tif 000016
【図６】
2021519035.tif 000017
【図７】
2021519035.tif 000018
【図８】
2021519035.tif 000019
【図９】
2021519035.tif 000020
【図１０】
2021519035.tif 000021
【図１１】
2021519035.tif 000022
【図１２】
2021519035.tif 000023
【図１３】
2021519035.tif 000024
【図１４】
2021519035.tif 000025
【図１５】
2021519035.tif 000026
【図１６】
2021519035.tif 000027
【図１７】
2021519035.tif 000028
【図１８】
2021519035.tif 000029
【図１９】
2021519035.tif 000030
【図２０】
2021519035.tif 000031
【図２１】
2021519035.tif 000032
【図２２】
2021519035.tif 000033
【図２３】
2021519035.tif 000034
【図２４】
2021519035.tif 000035
【図２５】
2021519035.tif 000036
【図２６】
2021519035.tif 000037
【図２７】
2021519035.tif 000038
【図２８】
2021519035.tif 000039
【手続補正書】
【提出日】令和2年10月16日(2020.10.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
映像をデコードする方法であって、
現コーディングツリーブロックが現ピクチャの境界（boundary）を外れることに基づいて、前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップと、
現コーディングブロックが予め設定された条件を満たすことに基づいて、前記現コーディングブロックが複数のサブブロックに分割されるか否かという情報を有する第１のシンタックス要素（syntax element）をパージングするステップと、
前記第１のシンタックス要素が前記現コーディングブロックが分割されるという情報を有することに基づいて、前記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かという情報を有する第２のシンタックス要素をパージングするステップと、
前記第２のシンタックス要素が前記現コーディングブロックが前記四分木構造を利用して分割されないという情報を有することに基づいて、前記現コーディングブロックが二分木（binary-tree）構造を利用して分割されるか否か、または前記現コーディングブロックが三分木（ternary-tree）構造を利用して分割されるか否か、という情報を有する第３のシンタックス要素と、前記現コーディングブロックの分割方向に関する情報を有する第４のシンタックス要素と、のうちの少なくとも１つをパージングするステップと、
前記第１のシンタックス要素、前記第２のシンタックス要素、前記第３のシンタックス要素、および前記第４のシンタックス要素のうちの少なくとも１つに基づいて、前記現コーディングブロックの分割モード（split mode）を決定するステップと、を有し、
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、前記現コーディングツリーブロックのサイズが最大の変換サイズより大きいことに基づいて、前記現コーディングツリーブロックを前記四分木構造を利用して前記複数のコーディングブロックに分割するステップを有する、映像のデコード方法。
【請求項２】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記二分木構造または前記三分木構造を利用して前記複数のコーディングブロックに分割するステップであって、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に位置する領域を表すステップを有する、請求項１に記載の映像のデコード方法。
【請求項３】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロックが前記現ピクチャの境界（boundary）を外れることに基づいて、四分木分割が許容されるか否かという情報を有する第５のシンタックス要素をパージングするステップをさらに有し、
前記第５のシンタックス要素が前記四分木分割が許容されないという情報を有することに基づいて、前記現コーディングツリーブロックは、前記二分木構造または前記三分木構造を利用して前記複数のコーディングブロックに分割される、請求項１に記載の映像のデコード方法。
【請求項４】
前記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされる、請求項３に記載の映像のデコード方法。
【請求項５】
前記現コーディングツリーブロックを複数のコーディングブロックに分割するステップは、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記四分木構造を利用して前記複数のコーディングブロックに分割するステップであって、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に位置する領域を表すステップを有する、請求項１に記載の映像のデコード方法。
【請求項６】
映像をデコードする装置であって、
現コーディングツリーブロックが現ピクチャの境界（boundary）を外れることに基づいて、前記現コーディングツリーブロックを複数のコーディングブロックに分割するよう構成されたコーディングツリーブロック分割部と、
現コーディングブロックが予め設定された条件を満たすことに基づいて、前記現コーディングブロックが複数のサブブロックに分割されるか否かという情報を有する第１のシンタックス要素（syntax element）をパージングし、
前記第１のシンタックス要素が前記現コーディングブロックが分割されるという情報を有することに基づいて、前記現コーディングブロックが四分木（quad-tree）構造を利用して分割されるか否かという情報を有する第２のシンタックス要素をパージングし、
前記第２のシンタックス要素が前記現コーディングブロックが前記四分木構造を利用して分割されないという情報を有することに基づいて、前記現コーディングブロックが二分木（binary-tree）構造を利用して分割されるか否か、または前記現コーディングブロックが三分木（ternary-tree）構造を利用して分割されるか否か、という情報を有する第３のシンタックス要素と、前記現コーディングブロックの分割方向に関する情報を有する第４のシンタックス要素と、のうちの少なくとも１つをパージングする、よう構成されたシンタックス要素パージング部と、
前記第１のシンタックス要素、前記第２のシンタックス要素、前記第３のシンタックス要素、および前記第４のシンタックス要素のうちの少なくとも１つに基づいて、前記現コーディングブロックの分割モード（split mode）を決定するよう構成された分割モード決定部と、を備え、
前記コーディングツリーブロック分割部は、前記現コーディングツリーブロックのサイズが最大の変換サイズより大きいことに基づいて、前記現コーディングツリーブロックを前記四分木構造を利用して前記複数のコーディングブロックに分割する、映像のデコード装置。
【請求項７】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記二分木構造または前記三分木構造を利用して前記複数のコーディングブロックに分割し、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に位置する領域を表す、請求項６に記載の映像のデコード装置。
【請求項８】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロックが現ピクチャの境界（boundary）を外れることに基づいて、四分木分割が許容されるか否かという情報を有する第５のシンタックス要素をパージングし、
前記第５のシンタックス要素が前記四分木分割が許容されないという情報を有することに基づいて、前記現コーディングツリーブロックは、前記二分木構造または前記三分木構造を利用して前記複数のコーディングブロックに分割される、請求項６に記載の映像のデコード装置。
【請求項９】
前記第５のシンタックス要素は、シーケンスパラメータセット（Sequence Parameter Set）、ピクチャパラメータセット（Picture Parameter Set）、タイルグループヘッダ（Tile Group Header）、またはネットワーク抽象化層（Network Abstract Layer）ユニットのヘッダを介してシグナリングされる、請求項８に記載の映像のデコード装置。
【請求項１０】
前記コーディングツリーブロック分割部は、
前記現コーディングツリーブロック内の有効な領域（valid region）に達するまで、前記現コーディングツリーブロックを前記四分木構造を利用して前記複数のコーディングブロックに分割し、前記有効な領域は、前記現コーディングツリーブロック内で前記現ピクチャの境界内に位置する領域を表す、請求項６に記載の映像のデコード装置。
【国際調査報告】
2021519035.tif 000040
2021519035.tif 000041
2021519035.tif 000042
2021519035.tif 000043