JP2022075931A - 柔軟なツリー構造を提供する方法、装置およびプログラム - Google Patents

Abstract

【課題】柔軟なツリー構造を提供する。
【解決手段】ビデオシーケンスの符号化または復号化を可能にするようにブロックを分割する方法および装置は、正方形分割という分割パターン、水平二分木分割パターン、または水平三分木分割パターンを使用してブロックを分割し、サブブロックのセットを生成することであって、前記正方形分割という分割パターンを前記水平二分木分割パターンおよび前記水平三分木分割パターンドの前に、後に、またはそれらと交互に使用するように、前記正方形分割という分割パターン、前記水平二分木分割パターン、および前記水平三分木分割パターンに同じ優先度を割り当てることと、前記正方形分割という分割パターン、前記水平二分木分割パターン、または水平三分木分割パターンを使用して前記ブロックを分割することに基づいて、前記ビデオシーケンスの符号化または復号化を実行することと、を含む。
【選択図】図１

Description

［関連出願への相互参照］
本願は、米国特許法第３５条第１１９項に基づいて、２０１８年３月７日に米国特許商標庁に提出された米国特許出願第６２／６３９，９８９号に対する優先権を主張し、その開示の全体が参照により本明細書に組み込まれる。
［技術分野］
本開示は、高効率ビデオ符号化／復号化（ＨＥＶＣ：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）を超えたハイブリッドビデオ符号化／復号化における高度なブロック分割に関するものである。より具体的には、効率的なブロック分割のために柔軟なツリー構造が提案されている。

ＩＴＵ－Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は、２０１３年（バージョン１）、２０１４年（バージョン２）、２０１５年（バージョン３）および２０１６年（バージョン４）に、Ｈ．２６５／ＨＥＶＣ（高効率ビデオ符号化／復号化）規格を発表した。それ以来、彼らは、既に、ＨＥＶＣ規格（その拡張を含む）の圧縮能力を著しく超える圧縮能力を有する将来のビデオ符号化／復号化技術の規格化への潜在的なニーズを検討している。共同ビデオ探査チーム（ＪＶＥＴ：Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ）として知られている各グループは、この分野の専門家によって提案された圧縮技術の設計を評価するために、共同開発の努力でこの探査活動に協力している。ＪＶＥＴは、ＨＥＶＣの能力を超えるビデオ符号化／復号化技術を探索するために、共同探索モデル（ＪＥＭ：Ｊｏｉｎｔ Ｅｘｐｌｏｒａｔｉｏｎ Ｍｏｄｅｌ）を開発した。ＪＥＭの現在の最新バージョンは、ＪＥＭ－７．０である。

ＨＥＶＣでは、符号化ツリーユニット（ＣＴＵ：Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ）は、様々なローカル特性に適応するために、符号化ツリーとして示される四分木構造を使用することによって、符号化ユニット（ＣＵ：Ｃｏｄｉｎｇ Ｕｎｉｔｓ）に分割される。フレーム間画像（時間的）予測またはフレーム内画像（空間的）予測のどちらを使用して画像領域を符号化するかは、ＣＵレベルで決定される。各ＣＵは、さらに、予測ユニット（ＰＵ：Ｐｒｅｄｉｃｔｉｏｎ Ｕｎｉｔｓ）の分割タイプに従って、１つ、２つまたは４つのＰＵに分割されることができる。１つのＰＵ内で、同じ予測処理が適用され、また、関連情報がＰＵベースでデコーダに送信される。ＰＵの分割タイプに基づいて、予測処理を適用することにより残差ブロックを取得した後、ＣＵは、ＣＵの符号化ツリーに類似する別の四分木構造に従って、変換ユニット（ＴＵ：Ｔｒａｎｓｆｏｒｍ Ｕｎｉｔｓ）に分割されることができる。ＨＥＶＣ構造の重要な特徴の１つは、ＣＵ、ＰＵおよびＴＵを含む複数分割の概念を有することである。ＨＥＶＣでは、フレーム間予測ブロックについて、ＣＵまたはＴＵは正方形のみであるが、ＰＵは正方形または長方形であってもよい。ＨＥＶＣの後期段階では、いくつかの投稿は、長方形のＰＵをフレーム内予測および変換に使用することを許可するように提案されている。これらの提案は、ＨＥＶＣには採用されていないが、ＪＥＭで使用するように拡張されている。画像の境界で、ＨＥＶＣは暗黙的な四分木分割を課し、サイズが画像の境界に合うまで、ブロックが四分木分割を維持するようにする。

以前の研究から着想を得て、四分木二分木（ＱＴＢＴ：Ｑｕａｄ－Ｔｒｅｅ－Ｂｉｎａｒｙ－Ｔｒｅｅ）構造が開発され、ＣＵ、ＰＵおよびＴＵの概念を統合し、またＣＵの分割形状のより多くの柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは、正方形または長方形を有することができる。まず、四分木構造によって符号化ツリーユニット（ＣＴＵ）を分割することができる。さらに、二分木構造によって四分木のリーフノードを分割することができる。二分木分割では、対称水平分割と対称垂直分割の２つの分割タイプがある。二分木のリーフノードは、符号化ユニット（ＣＵ）と呼ばれ、この分割が、さらなる分割なしで、予測および変換処理に用いられる。これは、ＱＴＢＴ符号化ブロック構造では、ＣＵ、ＰＵとＴＵが同じブロックサイズを有する、ということを意味する。ＪＥＭでは、ＣＵは、異なる色成分の符号化ブロック（ＣＢ：Ｃｏｄｉｎｇ Ｂｌｏｃｋ）から構成される場合があり、例えば、４：２：０色度フォーマットのＰおよびＢスライスの場合、１つのＣＵが１つの輝度ＣＢと２つの色度ＣＢを含み、単一成分のＣＢから構成される場合があり、例えば、Ｉスライスの場合、１つのＣＵが１つの輝度ＣＢのみまたはちょうど２つの色度ＣＢを含む。

ＱＴＢＴの分割スキームに対して、以下のパラメータが定義された。

ＣＴＵサイズは、四分木のルートノードサイズであり、ＨＥＶＣにおける同じ概念である。

ＭａｘＱＴＤｅｐｔｈは、許可された最大の四分木の深さである。

ＭｉｎＱＴＳｉｚｅは、許可された最小の四分木のリーフノードのサイズである。

ＭａｘＢＴＳｉｚｅは、許可された最大の二分木のルートノードのサイズである。

ＭａｘＢＴＤｅｐｔｈは、許可された最大の二分木の深さである。

ＭｉｎＢＴＳｉｚｅは、許可された最小の二分木のリーフノードのサイズである。

ＱＴＢＴ分割構造の１つの例では、ＣＴＵサイズを色度サンプルの対応する２つの６４×６４ブロックを有する１２８×１２８輝度サンプルとして設定し、ＭｉｎＱＴＳｉｚｅを１６×１６に設定し、ＭａｘＢＴＳｉｚｅを６４×６４に設定し、ＭｉｎＢＴＳｉｚｅ（幅と高さの両方）を４×４に設定し、ＭａｘＢＴＤｅｐｔｈを４に設定する。まず、四分木分割をＣＴＵに適用して四分木のリーフノードを生成する。四分木のリーフノードは、１６×１６（即ち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（即ち、ＣＴＵサイズ）までのサイズを有することができる。四分木のリーフノードは１２８×１２８のサイズである場合、ＭａｘＢＴＳｉｚｅ（即ち、６４×６４）を超えるため、二分木によって更に分割されない。そうでなければ、四分木のリーフノードは、二分木によって更に分割されることができる。したがって、四分木のリーフノードも、二分木のルートノードであり、また、それが、二分木の深さ「０」を有する。二分木の深さがＭａｘＢＴＤｅｐｔｈ（即ち、４）に達する場合、さらなる分割は考慮されていない。二分木のノードがＭｉｎＢＴＳｉｚｅ（即ち、４）に等しい幅を有する場合、さらなる水平分割は考慮されていない。同様に、二分木のノードがＭｉｎＢＴＳｉｚｅに等しい高さを有する場合、さらなる垂直分割は考慮されていない。任意の更なる分割を行わない売、さらに、二分木のリーフノードを予測および変換処理によって処理する。ＪＥＭでは、最大のＣＴＵサイズは２５６×２５６個の輝度サンプルである。

また、ＱＴＢＴスキームは、輝度と色度が個別のＱＴＢＴ構造を有する能力をサポートしている。現在、ＰおよびＢスライスについて、１つのＣＴＵにおける輝度ＣＴＢおよび色度ＣＴＢは、同じＱＴＢＴ構造を共有する。しかしながら、Ｉスライスについて、輝度ＣＴＢをＱＴＢＴ構造に従ってＣＵに分割し、色度ＣＴＢを別のＱＴＢＴ構造に従って色度ＣＵに分割する。これは、ＩスライスにおけるＣＵが、輝度成分の符号化ブロックまたは２つの色度成分の符号化ブロックから構成され、ＰスライスまたはＢスライスにおけるＣＵが、３つの色成分の符号化ブロックのすべてから構成される、ということを意味する。

ＨＥＶＣでは、動き補償のメモリアクセスを低減するために、小さいブロックのフレーム間予測を制限し、これにより、４×８と８×４のブロックは、双方向予測をサポートしていないし、４×４のブロックは、フレーム間予測をサポートしていない。ＪＥＭのＱＴＢＴでは、これらの制限は削除された。

マルチタイプツリー（ＭＴＴ：Ｍｕｌｔｉ－Ｔｙｐｅ－Ｔｒｅｅ）は、ＱＴＢＴよりも柔軟なツリー構造である。ＭＴＴでは、四分木と二分木以外のツリータイプがサポートされている。例えば、水平と垂直の中心側の三分木が導入されている。また、ＭＴＴは、（ａ）四分木分割、（ｂ）垂直二分木分割、（ｃ）水平二分木分割、（ｄ）垂直中心側の三分木分割、（ｅ）水平中心側の三分木分割などの他のタイプをサポートしている。

領域ツリー（四分木）と予測ツリー（二分木または三分木）の２つレベルのツリーがある。まず、ＣＴＵを領域ツリー（ＲＴ：Ｒｅｇｉｏｎ ＴｒｅｅＲＴ）によって分割する。予測ツリー（ＰＴ：Ｐｒｅｄｉｃｔｉｏｎ Ｔｒｅｅ）を用いて領域ツリーのリーフをさらに分割することができる。ＰＴを用いて予測ツリーのノードを最大のＰＴ深さまでさらに分割することもできる。ＰＴに入った後、ＲＴ（四分木）を使用することができなくなる。予測ツリーのリーフは、基本的な符号化ユニットである。便宜上、予測ツリーのリーフは、依然としてＣＵと呼ばれる。ＣＵは、さらに分割されることができない。予測と変換はどちらも、ＪＥＭ－３またはＱＴＢＴと同じ方法で、ＣＵに適用される。

三分木分割の主な利点は、四分木分割と二分木分割を補完することであり、即ち、三分木分割は、ブロックの中心にあるオブジェクトを捕捉することができるが、四分木と二分木では、常にブロックの中心に沿って分割が実行される。さらに、提案された三分木分割の幅と高さは、常に２の累乗であるため、付加的な変換は必要なくなる。

２つレベルのツリーの設計は、主に複雑さの低減によって動機付けられる。理論的には、ツリーのトラバーサルの複雑さは

であり、ここで、Ｔは分割タイプの数を示し、Ｄはツリーの深さである。２つレベルのツリーの設計を採用して、第１レベルを四分木に制限する（例えば、特定のレベルでＴの数を減少する）ことにより、合理的なパフォーマンスを維持しながら、複雑さを大幅に低減することができる。

ＱＴＢＴ以上の符号化効率をさらに向上させるために、非対称な二分木が提案されている。例えば、サイズＳの符号化ユニットは、水平方向または垂直方向に、サイズＳ／４およびＳ／４の２つのサブ符号化ユニット（ＣＵ）に分割される。実際には、追加された利用可能なＣＵのサイズは、１２と２４である。このツールのさらに拡張されたバージョンでは、ＣＵサイズが６と４８であることが許可されることができる。

この方法、デバイスおよびコンピュータ媒体の１つの主な問題は、ブロックの幅／高さが２の累乗ではない場合に不便である、ということである。例えば、１２や２４などのサイズの変換をサポートする必要がある。２の累乗以外の幅／高さを有するブロックを分割する場合にも、特別な処理が必要になることがある。

２レベルのＭＴＴツリー構造は、不均衡なフレームワークである。四分木（ＱＴ）は、二分木／三分木（ＢＴ／ＴＴ）ノードの後に許可されないため、ＢＴ／ＴＴから始まるツリーの全体的な深さは、四分木ＱＴから始まるツリーよりもはるかに小さくにすることができる。このような非平衡なツリー設計では、エンコーダ側で深さが０であるマルチスレッドなどのような並列符号化の問題が導入され、これは、１つのサブツリーが符号化時間の大部分を占めている場合、マルチスレッド処理が役に立たないからである。

いくつかの特殊なケースでは、現在の設計は、符号化性能を低下させる可能性がある。例えば、４：２：２色度フォーマットでは、正方形の輝度ＣＴＵが使用された場合、それに応じて非正方形の色度ＣＴＵが発生する。このようにして、かなりの計算費用が導入された。

ＭＴＴなどのような柔軟なツリー構造を使用する場合、ＨＥＶＣの暗黙的なＱＴ分割は効率的ではなく、これは、暗黙的な分割によって小さすぎるブロックを選択しなければならない場合があるからである。

本開示の一態様によれば、ビデオシーケンスの符号化または復号化を可能にするようにブロックを分割する方法は、正方形分割という分割パターン、水平二分木分割パターン、または水平三分木分割パターンを使用してブロックを分割し、サブブロックのセットを生成するステップであって、前記正方形分割という分割パターンを前記水平二分木分割パターンおよび前記水平三分木分割パターンの前に、後に、またはそれらと交互に使用するように、前記正方形分割という分割パターン、前記水平二分木分割パターン、および前記水平三分木分割パターンに同じ優先度を割り当てるステップと、前記正方形分割という分割パターン、前記水平二分木分割パターン、または水平三分木分割パターンを使用して前記ブロックを分割することに基づいて、前記ビデオシーケンスの符号化または復号化を実行するステップと、を含む。

本開示の一態様によれば、ビデオシーケンスの符号化または復号化を可能にするようにブロックを分割する方法は、前記正方形分割という分割パターンを使用して前記ブロックを分割し、サブブロックのセットを生成するステップは、前記ブロックが正方形である場合、各サブブロックは正方形であり、前記ブロックが非正方形である場合、各サブブロックは前記ブロックの幅と高さの最大の共通因子である同じサイズを含むステップと、前記正方形分割という分割パターンを使用して前記ブロックを分割することに基づいて、前記ビデオシーケンスの符号化または復号化を実行するステップと、を含む。

本開示の一態様によれば、ビデオシーケンスの符号化または復号化を可能にするようにブロックを分割する装置であって、前記装置は、コンピュータコードを記憶するように構成される少なくとも１つのメモリと、前記コンピュータコードを読み取り、前記コンピュータコードの指示に従って動作するように構成される少なくとも１つのプロセッサを含み、前記プログラムコードが、前記なくとも1つのプロセッサに、正方形分割という分割パターン、水平二分木分割パターン、または水平三分木分割パターンを使用してブロックを分割し、サブブロックのセットを生成するであって、前記正方形分割という分割パターンを前記水平二分木分割パターンおよび前記水平三分木分割パターンの前に、後に、またはそれらと交互に使用するように、前記正方形分割という分割パターン、前記水平二分木分割パターン、および前記水平三分木分割パターンに同じ優先度を割り当てること、を実行させるように構成される分割コードと、前記なくとも1つのプロセッサに、前記正方形分割という分割パターン、前記水平二分木分割パターン、または水平三分木分割パターンに基づいて、前記ブロックを分割し、前記ビデオシーケンスの符号化または復号化を実行させるように構成される分割コードと、を含む。

本開示の一態様によれば、命令を記憶する不揮発性コンピュータ読み取り可能な媒体であって、前記命令は１つ以上の命令を含み、前記１つ以上の命令が、ビデオシーケンスの符号化または復号化を可能にするようにブロックを分割する装置の１つ以上のプロセッサによって実行される場合、前記１つ以上のプロセッサに、正方形分割という分割パターン、水平二分木分割パターン、または水平三分木分割パターンを使用してブロックを分割し、サブブロックのセットを生成することであって、前記正方形分割という分割パターンを前記水平二分木分割パターンおよび前記水平三分木分割パターンの前に、後に、またはそれらと交互に使用するように、前記正方形分割という分割パターン、前記水平二分木分割パターン、および前記水平三分木分割パターンに同じ優先度を割り当てることと、前記正方形分割という分割パターン、前記水平二分木分割パターン、または水平三分木分割パターンを使用して前記ブロックを分割することに基づいて、前記ビデオシーケンスの符号化または復号化を実行させる。

開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付図面からより明らかになり、ここで、
正方形分割という分割パターンを使用してブロックを分割することでサブブロックのセットを生成する例示的な処理のフローチャートである。 本開示の実施形態による通信システムの簡略化されたブロック図である。 ストリーミング環境におけるビデオエンコーダおよびデコーダの配置の図である。 本開示の実施形態によるビデオデコーダの機能ブロック図である。 本開示の実施形態によるビデオエンコーダの機能ブロック図である。 実施形態によるコンピュータシステムの図である。ｖ 統合されたツリー深さを使用してブロックを分割することでサブブロックのセットを生成する例示的な処理のフローチャートである。

図１は、正方形分割（ｓｐｌｉｔ－ｔｏ－ｓｑｕａｒｅ）という分割パターン（ｐａｒｔｉｔｉｏｎ ｐａｔｔｅｒｎ）を使用してブロックを分割することでサブブロックのセットを生成する例示的な処理のフローチャートである。

いくつかの実現では、図１の１つ以上の処理ブロックは、デコーダによって実行されてもよい。いくつかの実現では、図１の１つ以上の処理ブロックは、別のデバイス、あるいは、デコーダとは分離するまたはデコーダを含むデバイスのグループ（例えば、エンコーダ）によって実行されてもよい。

図１に示されるように、処理は、ブロックが正方形であるか否かを決定すること（ステップ１１０）を含むことができる。ブロックが正方形である場合（ステップ１１０における「はい」）、この処理は、正方形分割という分割パターンを使用してブロックを分割することでサブブロックのセットを生成すること（ステップ１２０）を含むことができる。この場合、各サブブロックは、正方形である。あるいは、ブロックが非正方形である場合（ステップ１１０における「いいえ」）、この処理は、正方形分割という分割パターンを使用してブロックを分割することで非正方形のサブブロックのセットを生成すること（ステップ１３０）を含むことができる。この場合、各サブブロックは、ブロックの幅と高さの最大の共通因子である同じサイズを含む。図１にさらに示されるように、この処理は、正方形分割という分割パターンを使用してブロックを分割することに基づいたビデオシーケンスに従って符号化または復号化を実行すること（ステップ１４０）を含むことができる。

一実施形態によれば、四分木の分割を正方形分割に変更することが提案された。分割しようとするブロックが正方形である場合、正方形分割は、四分木の分割と同様の効果を有する。それ例外の場合、ブロックは、同じサイズの正方形のサブブロックに分割され、前記正方形のサブブロックの幅／高さは、前記ブロックの幅と高さの最大の共通因子である。例えば、正方形分割を使用して、８ｘ３２ブロックを４つの８ｘ８ブロックに分割する。

一実施形態によれば、サブブロックの最大数は、事前定義またはシグナリングによって制約されることができ、シーケンスパラメータセット（ＳＰＳ：Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、画像パラメータセット（ＰＰＳ：Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、スライスヘッダ、ＣＴＵヘッダ、タイルヘッダで、または画像の領域に対して、信号で通知されることができる。一実施形態によれば、サブブロックの最大数は、４、８、１６などであってもよい。事前定義されたまたは信号で通知されたサブブロックの最大数が、正方形分割のシグナリングと競合する場合、例えば、正方形分割のシグナリングが６４ｘ８ブロックのための正方形分割ことを示すが、サブブロックの最大数が４に等しい場合、１つの実施形態では、正方形分割のフラグは上書きされ、６４ｘ８ブロックはさらに正方形に分割されない。別の実施形態では、この状況が発生した場合、ビットストリームは不適格なビットストリームであると見なされる。

二分木などの他の分割タイプとの重複を避けるために、特定の条件下、正方形分割または他の分割タイプは許可されない。分割（パーティションまたはスプリット）が許可されない場合、この分割（パーティションまたはスプリット）のシグナリングが除去されることができる。この場合、関連するシグナリングは、条件付きでスキップされてもよい。

正方形分割後に２つのサブブロックが存在する（輝度と色度の両方に２つのサブブロックがある）場合、正方形分割は許可されていなく、関連する二分木は許可されている。例えば、１６ｘ８ブロックに対して、正方形分割と垂直二値分割の両方は、２つの８ｘ８サブブロックにつながる。この場合、正方形分割は許可されないため、１６×８ブロックの正方形分割の信号はスキップされ、正方形分割のフラグは偽（ｆａｌｓｅ）として導出される。

正方形分割または垂直二分木分割が分割後に同じサブブロック分割につながる場合、正方形または垂直二分木分割は許可されない。正方形分割または水平二分木分割が分割後に同じサブブロック分割につながる場合、正方形または水平二分木分割は許可されない。

例えば、ＪＥＭのフレーム間スライスの場合のように、輝度と色度が同じ分割ツリーを共有する際に、例えば、ビデオコンテンツが４：２：２色度フォーマットである場合などのような、輝度ブロックおよびそれに関連付けられた色度ブロックが異なる形状を有する場合、正方形分割は許可されていても許可されていなくてもよい。

一実施形態では、輝度ブロックが正方形である場合、または輝度ブロックの関連付けられた色度ブロックが正方形である場合、正方形分割は許可されない。別の実施形態では、正方形分割は許可されるが、輝度および色度成分について異なる数のサブブロックをもたらす可能性がある。例えば、４：２：２色度フォーマットでのコンテンツについて、１６×１６輝度ブロックは、２つの８×１６ブロックに関連付けられる。正方形分割によって、輝度ブロックは、４つの８×８サブブロックに分割される一方、各色度ブロックは、２つの８×８サブブロックに分割される。別の実施形態では、正方形分割は輝度成分に基づいて許可される。色度ブロックは、輝度ブロックと整列する分割を必要とする。例えば、４：２：２色度フォーマットでのコンテンツについて、１６×１６輝度ブロックは、２つの８×１６ブロックに関連付けられる。正方形分割によって、輝度ブロックは、４つの８×８サブブロックに分割される一方、各色度ブロックは、４つの４×８サブブロックに分割される。

別の実施形態では、正方形分割は、色度成分に基づいて許可される。輝度ブロックは、色度ブロックと整列する分割を必要とする。例えば、４：２：２色度フォーマットのコンテンツについて、１６ｘ１６輝度ブロックは、２つの（ＣｂおよびＣｒ）８ｘ１６ブロックに関連付けられる。正方形分割によって、各色度ブロックは、２つの８×８サブブロックに分割される一方、輝度ブロックは、４つの８×８サブブロックに分割される。

一実施形態によれば、画像境界では、特定のツリータイプは条件付きで許可されない場合がある。例えば、分割されるブロックが水平方向ではなく、垂直方向に画像境界の外側にある場合、このブロックに対して、垂直二分木分割や垂直三分木分割などの垂直分割は許可されない。別の例として、分割されるブロックが垂直方向ではなく、水平方向に画像境界の外側にある場合、このブロックに対して、水平二分木分割や水平三分木分割などの水平分割は許可されない。

一実施形態によれば、最小輝度ブロックを正方形として維持しながら、最大の輝度ブロックおよび／または最大の色度ブロックに対して幅および高さの異なる値を可能にすることが提案された。ＣＴＵの幅と高さは、ＳＰＳ、ＰＰＳ、またはスライスヘッダなどのビットストリームで信号で通知される。最小の輝度ブロックの幅は、ＳＰＳ、ＰＰＳ、またはスライスヘッダなどのビットストリームで信号で通知される。最小の輝度ブロックの高さは、幅と同じように推定される。

一実施形態によれば、正方形分割、ＢＴ、およびＴＴに同じ優先度を与えることが提案され、したがって、１）統合されたツリーの深さがＱＴの深さおよびＢＴの深さが置き換えられ、２）正方形分割は、ＢＴ／ＴＴの前、ＢＴ／ＴＴの後、またはＢＴ／ＴＴとインターリーブされた任意の位置に位置してもよい。エンコーダ側では、通常、全てのツリータイプは、一般的に、同様な最大の深さおよび類似な探索の複雑さを有し、全てのツリータイプには、正方形分割、垂直二分木、水平二分木、垂直三分木、および水平三分木が含まれるが、これらに限定されない。したがって、エンコーダは、最適な分割ツリーを並列に見つけるために、マルチスレッド（１つのツリータイプにたしいて１つのスレッド）を使用することができる。

一例として、１２８×１２８ブロックについて、深さ０では、二分木分割を使用する。深さ１では、上サブブロックと下サブブロックのそれぞれについて、二分木分割と三分木分割を採用する。深さ２では、正方形割を使用して、１２８×３２サブブロックを４つの３２×３２サブブロックに分割する。最後に、深さ３では、さらに３２ｘ３２ブロックを正方形の分割で４つの１６ｘ１６サブブロックに分割する。

一実施形態によれば、特定のビン（ｂｉｎｓ）が、信号で通知される代わりに、画像境界で導出されることができるように、特定のツリータイプの二値化テーブルを使用して、画像境界を含むツリータイプ（分割タイプ）を常に信号で通知することが提案される。例えば、二値化テーブルは、次のように表示される。

以上のテーブルにおける４つのビンは、分割するかどうか、正方形に分割するかどうか、垂直または水平、および三分木または二分木などの分割タイプを、それぞれ表示する。画像境界にあり、かつ、ブロックの一部が画像の外側にあるブロックについて、分割するかどうかを示すビン（この実施形態ではビン０）は、信号で通知されるのではなく、１すなわち「分割」として導出される。あるいは、垂直または水平を示すビン（この実施例ではビン２）は、１）正方形分割を示すビンが０（この実施例ではビン１）である場合、２）ブロックが垂直かつ水平の両方ではなく、垂直のみまたは水平のみに画像の外側に位置する場合、信号で通知されずに導出される。

一実施形態によれば、二値化テーブルは、ブロック領域サイズ、ブロック高さおよび／または幅、ブロック形状、量子化パラメータ（ＱＰ：Ｑｕａｎｔｉｚａｔｉｏｎ Ｐａｒａｍｅｔｅｒ）、輝度または色度成分、フレーム内またはフレーム間符号化、時間レイヤ、ＣＴＵサイズ、ブロック分割深さを含むがこれらに限定されない、エンコーダおよびデコーダの両方に知られている、他の符号化された情報または他の任意の情報に依存し得ることが提案される。１つの例示的な実施形態では、いくつかの二値化テーブルは、エンコーダおよびデコーダの両方に対して予め定義されることができ、選択は、スライスヘッダ、ＳＰＳ、ＰＰＳ、ＶＰＳ、またはＣＴＵごとに信号で通知されることができる。別の例示的な実施形態では、分割タイプのための２つの二値化テーブルが予め定義され、現在ブロック領域のサイズが予め定義された閾値（例えば、１０２４）よりも大きい場合、２つのテーブルのうちの１つは、分割タイプを二値化するために使用され、そうではない場合、もう１つのテーブルは、分割タイプを二値化するために使用される。

一実施形態によれば、現在ブロックの分割タイプおよび／または方向を決定する場合、親ブロック分割（または分割ツリー）タイプおよび隣接分割（または分割ツリー）タイプをチェックすることが提案される。異なる分割順序による分割の重複は許可されない。１つの例示的な実施形態では、以下の図に示される２つの分割順序は、同じ分割につながる。例えば、まず、垂直二分木を用いてブロックを分割し、次に、水平二分木を用いて２つのサブブロックを分割する。さらに、まず、水平二分木を用いてブロックを分割し、次に、垂直二分木を用いて２つのサブブロックを分割する。重複を避けるため、３回目の分割は許可されない。

別の例では、現在符号化ブロックまたは予測ブロックの親（最後の深さ）の符号化ブロックまたは予測ブロックが、三分木を使用して垂直に３つのサブブロックに分割された場合、２番目（または中間）のサブブロックでは、さらに垂直二分木分割が許可されない。

別の例では、現在符号化ブロックまたは予測ブロックの親（最後の深さ）の符号化ブロックまたは予測ブロックが三分木を使用して水平に３つのサブブロックに分割された場合、２番目（または中間）のサブブロックでは、さらに水平二分木分割が許可されない。

一実施形態によれば、エンコーダとデコーダの両方がアクセス可能な予め定義されたルックアップテーブルにおいて、全ての可能な分割トレース（分割トレースは、ブロックを所与の分割パターン、すなわち各深さの分割タイプにどのように分割するか）の可用性を示すことが提案される。分割タイプおよび／または方向を許可するかまたは信号で通知するかを決定する場合、対応する分割は、予め定義されたルックアップテーブルに対する番号およびインデックスに変換され、そのルックアップテーブルから可能性が得られ、対応する分割が利用できない場合、分割は信号で通知されないかまたは許可されない。

１つの例示的な実施例では、ＣＴＵに関して、全ての可能な分割の可用性、例えば、６４×６４、１２８×１２８、または２５６×２５６が格納される。１つの例示的な実施形態では、２つの分割トレースは、ｍおよびｎによってインデックス付けられ、ｍおよびｎは整数である。１番目の分割トレースでは、まず、ブロックは、四分木によって４つの正方形のサブブロックに分割され、次に、各サブブロックは、四分木によって４つの正方形のサブブロックにさらに分割される。２番目の分割トレースでは、まず、ブロックは、二分木によって２つの長方形のサブブロックとして水平方向に分割され、次に、各サブブロックは、二分木によって２つの長方形のサブブロックとしてさらに水平方向に分割され、最後に、各サブブロックは、正方形分割によって４つの正方形ブロックとして分割される。ここから分かるように、これらの２つの分割トレースは、同じ最終分割パターンをもたらす。したがって、この例では、右の分割トレースは、ｎによってインデックス付けられたルックアップテーブルにおいて使用不可としてマークされ、それによって、底部の長方形のブロックを４つの正方形ブロックにさらに分割することを示すシグナリングが節約される。

一実施形態によれば、垂直四分木分割（ＶＱＴ）および水平四分木分割（ＨＱＴ）を追加することが提案される。例えば、垂直四分木分割を使用して３２×３２ブロックを４つの８×３２ブロックに分割してもよいし、水平四分木分割を使用して３２×３２ブロックを４つの３２×８ブロックに分割してもよい。別の実施形態では、フレーム内符号化されたスライスについて、垂直ＱＴおよび水平ＱＴのみが許容される。

別の実施形態によれば、ＳＰＳ、ＰＰＳ、またはスライスヘッダにおける柔軟なツリーフラグを信号で通知することで、二分木分割の後に四分木分割が許可されるかどうかを示すことが提案される。柔軟なツリーフラグが１に等しい場合、二分木分割の後に四分木分割が許可される。柔軟なツリーフラグが０に等しい場合、二分木分割の後に四分木分割は許可されない。ＳＰＳにおける柔軟なツリーフラグの構文テーブルの例を以下に示す。ＰＰＳおよびスライスヘッダのシグナリングは、同様の方法に従うことができる。

図１は、例示的なプロセスの例示的なステップを示すが、いくつかの実現では、このプロセスは、図１に示されたものと比較して、付加的なステップ、より少ないステップ、異なるステップ、または異なって配列されたステップを含むことができる。さらにまたは代替として、このプロセスのステップのうちの少なくとも２つのステップを並行して実行することができる。

図２は、本開示の実施形態による通信システム（２００）の簡略化されたブロック図を示す。通信システム（２００）は、ネットワーク（２５０）を介して相互接続された、少なくとも２つの端末（２１０、２２０）を含むことができる。データの単方向伝送について、第１端末（２１０）は、ネットワーク（２５０）を介して他の端末（２２０）に送信するために、ローカル位置でビデオデータを符号化することができる。第２端末（２２０）は、ネットワーク（２５０）から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号化して、復元されたビデオデータを表示することができる。単方向データ伝送は、メディアサービングアプリケーションでは一般的である。

図２は、例えば、ビデオ会議中に発生する可能性がある、符号化されたビデオの双方向伝送をサポートする第２ペアの端末（２３０、２４０）を示す。データの双方向伝送の場合、各端末（２３０、２４０）は、）は、ネットワーク（２５０）を介して他の端末に送信するために、ローカルで捕捉されたビデオデータを符号化することができる。各端末（２３０、２４０）は、他の端末によって送信された、符号化されたビデオデータを受信することもでき、符号化されたデータを復号化することができ、また復元されたビデオデータをローカルの表示デバイスに表示することもできる。

図２において、端末（２１０～２４０）は、サーバ、パーソナルコンピュータ、およびスマートフォンとして示されてもよいが、本開示の原理は、これに限定されていない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤおよび／または専用のビデオ会議機器を有するアプリケーションを見つける。ネットワーク（２５０）は、符号化されたビデオデータを端末（２１０～２４０）で送信する任意の数のネットワークを表し、例えば、有線および／または無線の通信ネットワークを含む。通信ネットワーク（２５０）は、回線交換および／またはパケット交換のチャネルでデータを交換することができる。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットを含む。本議論の目的のために、ネットワーク（２５０）のアーキテクチャおよびトポロジは、以下に本明細書で説明されない限り、本開示の動作にとって重要ではない場合がある。

図３は、開示された主題に対するアプリケーションの例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示す。開示された主題は、例えば、光ディスク（ＣＤ：Ｃｏｍｐｅｃｔ Ｄｉｓｃ）、高密度デジタルビデオディスク（ＤＶＤ：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ）、メモリスティックなどを含むデジタルメディアへの圧縮されたビデオの記憶、ビデオ会議、デジタルＴＶなどを含む、他のビデオサポートアプリケーションにも同等に適用可能である。

ストリーミングシステムは、捕捉サブシステム（３１３）を含むことができ、この捕捉サブシステムが、例えばデジタルカメラなどのビデオソース（３０１）を含むことができ、例えば圧縮されていないビデオサンプルストリーム（３０２）を作成することができる。符号化されたビデオビットストリームと比較する際に、高いデータボリュームを強調するために太い線で描かれたサンプルストリーム（３０２）は、カメラ（３０１）に結合されたエンコーダ（３０３）によって処理されることができる。エンコーダ（３０３）は、以下で詳細に説明するように、開示された主題の様々な態様を可能にするかまたは実現するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプルストリームと比較する際により低いデータボリュームを強調するために細い線で描かれた、符号化されたビデオビットストリーム（３０４）は、将来の使用のためにストリーミングサーバ（３０５）に記憶されることができる。１つ以上のストリーミングクライアント（３０６、３０８）は、ストリーミングサーバ（３０５）にアクセスして、符号化されたビデオビットストリーム（３０４）のコピー（３０７、３０９）を検索することができる。クライアント（３０６）は、ビデオデコーダ（３１０）を含むことができ、このビデオデコーダ（３１０）は、伝入される、符号化されたビデオビットストリーム（３０７）のコピーを復号化して、伝出される、ビデオサンプルストリーム（３１１）を作成することができ、このビデオサンプルストリーム（３１１）が、ディスプレイ（３１２）または他のレンダリングデバイス（図示せず）に表示されることができる。一部のストリーミングシステムでは、ビデオビットストリーム（３０４、３０７、３０９）は、特定のビデオ不符号化／圧縮規格に基づいて符号化されることができる。これらの規格の例には、ＩＴＵ－Ｔ勧告Ｈ．２６５が含まれる。開発中のビデオ符号化規格は、多機能ビデオ符号化（ＶＶＣ：Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）として非公式に知られている。開示された主題は、ＶＶＣのコンテキストで使用されてもよい。

図４は、本発明の実施形態によるビデオデコーダ（２１０）の機能ブロック図であることができる。

受信機（４１０）は、ビデオデコーダ（３１０）によって復号化される１つ以上のコーデックビデオシーケンスを受信することができ、同じまたは別の実施形態では、一度に１つの符号化されたビデオシーケンスを受信することができ、ここで、各符号化されたビデオシーケンスの復号化が、他の符号化されたビデオシーケンスから独立している。符号化されたビデオシーケンスは、チャネル（４１２）から受信されることができ、このチャネルが、符号化されたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアのリンクであってもよい。受信機（４１０）は、それぞれの使用エンティティ（図示せず）に転送されることができる、例えば符号化されたオーディオデータおよび／または補助のデータストリームなどの他のデータとともに、符号化されたビデオデータを受信することができる。受信機（４１０）は、符号化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタを防止するために、バッファメモリ（４１５）は、受信機（４１０）とエントロピーデコーダ／解析器（Ｐａｒｓｅｒ）（４２０）（以後の「解析器」）との間に結合されることができる。受信機（４１０）が十分な帯域幅および制御可能性を有するストア／フォワードデバイスからまたは等時性同期ネットワークからデータを受信する場合、バッファメモリ（４１５）は、必要ではないかまたは小さくでもよい。インターネットなどのベストエフォートパケットネットワークで使用するために、バッファメモリ（４１５）は、必要になる場合があり、比較的大きくすることができ、有利には適応性のサイズにすることができる。

ビデオデコーダ（３１０）は、エントロピー符号化されたビデオシーケンスからシンボル（４２１）を再構築するための解析器（４２０）を含むことができる。これらのシンボルのカテゴリには、ビデオデコーダ（３１０）の動作を管理するために使用される情報と、デコーダの不可欠な部分ではないが、図４に示すように、そのデコーダに結合されることができるディスプレイ（３１２）などのレンダリングデバイスを制御するための潜在的な情報とが含まれる。レンダリングデバイスの制御情報は、補助拡張情報（ＳＥＩ：Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージまたはビデオユーザビリティ情報（ＶＵＩ：Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）パラメータセットフラグメント（図示せず）の形であってもよい。解析器（４２０）は、受信された、符号化されたビデオシーケンスに対して解析／エントロピー復号化を行うことができる。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術または規格に従うことができて、当業者に知られている原理に従うことができ、可変長符号化、ハフマン符号化（Ｈｕｆｆｍａｎ ｃｏｄｉｎｇ）、コンテキスト感度を有するかまたは有しないかの算術符号化などを含む。解析器（４２０）は、グループに対応する少なくとも１つのパラメータに基づいて、符号化されたビデオシーケンスから、ビデオデコーダにおける画素のサブグループのうちの少なくとも１つのためのサブグループパラメータのセットを、抽出することができる。サブグループは、画像のグループ（ＧＯＰ：Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）、画像、タイル、スライス、マクロブロック、符号化ユニット（ＣＵ：Ｃｏｄｉｎｇ Ｕｎｉｔ）、ブロック、変換ユニット（ＴＵ：Ｔｒａｎｓ ｆｏｒｍ Ｕｎｉｔ）、予測ユニット（ＰＵ：Ｐｒｅｃｔｉｏｎ Ｕｎｉｔ）などを含むことができる。エントロピーデコーダ／解析器は、変換係数、量子化器パラメータ値（ＱＰ：Ｑｕａｎｔｉｚｅｒ Ｐａｒａｍｅｔｅｒ）、動きベクトルなどの情報を符号化されたビデオシーケンスから抽出することもできる。

解析器（４２０）は、シンボル（４２１）を生成するために、バッファメモリ（４１５）から受信されたビデオシーケンスに対してエントロピー復号化／解析動作を実行することができる。解析器（４２０）は、符号化されたデータを受信し、特定のシンボル（４２１）を選択的に復号化することができる。さらに、解析器（４２０）は、特定のシンボル（４２１）が動き補償予測ユニット（４５３）、スケーラ／逆変換ユニット（４５１）、フレーム内予測ユニット（４５２）、またはループフィルタ（４５６）に供給されるかどうかを決定することができる。

シンボル（４２１）の再構築は、符号化されたビデオ画像またはその一部（例えば、レーム間画像およびフレーム内画像、フレーム間ブロックおよびフレーム内ブロック）のタイプ、および他の要因に応じて、複数の異なるユニットに関連することができる。どのようなユニットに関連するか、およびどのように関連するかは、解析器（４２０）によって、符号化されたビデオシーケンスから解析されたサブグループ制御情報によって制御されることができる。解析器（４２０）と以下の複数のユニットの間との間のそのようなサブグループ制御情報のフローは明確にするために説明されていない。

既に言及された機能ブロックに加えて、ビデオデコーダ（３１０）は、以下に説明するように、いくつかの機能ユニットに概念的に細分化されることができる。商業的制約で動作する実際の実施形態では、これらのユニットの多くは、互いに密接に相互作用し、少なくとも部分的には互いに統合されることができる。しかしながら、開示された主題を説明する目的のために、以下の機能ユニットへの概念的な細分が適切である。

第１ユニットは、スケーラ／逆変換ユニット（４５１）である。スケーラ／逆変換ユニット（４５１）は、量子化された変換係数と、どのような変換を使用するか、ブロックサイズ、量子化因子、量子化スケーリング行列などを含む制御情報とを、シンボル（４２１）として解析器（４２０）から受信する。スケーラ／逆変換ユニット（４５１）は、アグリゲータ（４５５）に入力できるサンプル値を含むブロックを出力することができる。

いくつかの場合では、スケーラ／逆変換ユニット（４５１）の出力サンプルは、フレーム内符号化されたブロックに属することができ、即ち、このフレーム内符号化ブロックは、以前に再構築された画像からの予測情報を使用していないが、現在の画像の以前に再構築された部分からの予測情報を使用できるブロックである。このような予測情報は、フレーム内画像予測ユニット（４５２）によって提供されてもよい。いくつかの場合では、フレーム内画像予測ユニット（４５２）は、現在の（部分的に再構築された）画像（４５４）から抽出された、周囲の既に再構築された情報を使用して、再構築中のブロックと同じサイズおよび形状のブロックを生成する。アグリゲータ（４５５）は、いくつかの場合では、サンプルごとに基づいて、フレーム内予測ユニット（４５２）によって生成された予測情報を、スケーラ／逆変換ユニット（４５１）によって提供される出力サンプル情報に追加する。

他の場合では、スケーラ／逆変換ユニット（４５１）の出力サンプルは、フレーム間符号化されたブロックおよび潜在的に動き補償されたブロックに属することができる。このような場合、動き補償予測ユニット（４５３）は、参照画像メモリ（４５７）にアクセスして、予測に用いられるサンプルを抽出することができる。抽出されたサンプルが、ブロックに関連するシンボル（４２１）に従って動き補償された後、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（４５５）によってスケーラ／逆変換ユニットの出力（この場合、残差サンプルまたは残差信号と呼ばれる）に追加されることができる。動き補償ユニットが予測サンプルを抽出するときの参照画像メモリ内のアドレスは、例えば、Ｘ、Ｙおよび参照画像成分を有することができるシンボル（４２１）の形で、動き補償ユニットに利用可能な動きベクトルによって制御されることができる。動き補償は、サブサンプルの正確な運動ベクトルが使用中であるときに、参照画像メモリから抽出されたサンプル値の補間、運動ベクトル予測メカニズムなどを含むこともできる。

アグリゲータ（４５５）の出力サンプルは、ループフィルタユニット（４５６）において様々なループフィルタリング技術によって採用されてもよい。ビデオ圧縮技術は、符号化されたビデオビットストリームに含まれ、解析器（４２０）からのシンボル（４２１）としてループフィルタユニット（４５６）に利用可能になるパラメータによって制御されるループ内フィルタ技術を含みことができ、また、符号化された画像または符号化されたビデオシーケンスの前の部分（復号化順序で）を復号化する期間で得られたメタ情報に応答し、および、以前に再構築されてループフィルタされたサンプル値に応答することもできる。

ループフィルタユニット（４５６）の出力は、レンダリングデバイス（３１２）に出力することができ、および、将来のフレーム間画像予測で使用するために参照画像メモリ（４５７）に記憶することができるサンプルストリームとすることができる。

特定の符号化された画像は、一旦完全に再構築されると、将来の予測のための参考画像として使用されることができる。例えば、符号化された画像が一旦完全に再構築され、かつ、符号化された画像が（例えば、解析器（４２０）によって）参照画像として識別されると、現在の参照画像（６５６）は、参照画像バッファ（４５７）の一部となることができ、また、後続の符号化された画像の再構築を開始する前に、新しい現在の画像メモリを再割り当てすることができる。

ビデオデコーダ（３１０）は、例えばＩＴＵ―Ｔ ＲＥＣ． Ｈ．２６５などの規格における所定のビデオ圧縮技術に従って復号化動作を実行することができる。符号化されたビデオシーケンスは、ビデオ圧縮技術ドキュメントまたは規格において、特に、それらのプロファイルドキュメントにおいて指定されたビデオ圧縮技術または規格の構文に従うという意味で、使用されているビデオ圧縮技術または規格によって指定された構文に従うことができる。符号化されたビデオシーケンスの複雑さが、ビデオ圧縮技術または規格の階層によって定義された範囲内にあることもコンプライアンスに必要である。いくつかの場合では、階層は、最大画像サイズ、最大フレームレート、（例えば、毎秒メガ（ｍｅｇａ）個のサンプルを単位として測定された）最大再構築サンプルレート、最大参照画像サイズなどを制限する。階層によって設定された制限は、いくつかの場合では、仮想参照デコーダ（ＨＲＤ：Ｈｙｐｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ）仕様と、符号化されたビデオシーケンスにおいて信号で通知されたＨＲＤバッファ管理のメタデータとによって、さらに限定されることができる。

一実施形態では、受信機（４１０）は、符号化されたビデオとともに付加（冗長）的なデータを受信することができる。付加的なデータは、符号化されたビデオシーケンスの一部として含まれることができる。付加的なデータは、データを適切に復号化し、および／または、元のビデオデータをより正確に再構築するために、ビデオデコーダ（３１０）によって使用されることができる。付加的なデータは、例えば、時間的、空間的、または信号雑音比（ＳＮＲ：ｓｉｇｎａｌ－ｔｏ－ｎｏｉｓｅ ｒａｔｉｏ）拡張層、冗長スライス、冗長画像、前方誤り訂正符号などの形式にすることができる。

図５は、本開示の一実施形態によるビデオエンコーダ（３０３）の機能ブロック図である。

エンコーダ（３０３）は、エンコーダ（３０３）によって符号化されるビデオ画像を捕捉することができるビデオソース（３０１）（それはエンコーダの一部ではない）から、ビデオサンプルを受信することができる。

ビデオソース（３０１）は、エンコーダ（３０３）によって符号化されるソースビデオシーケンスをデジタルビデオサンプルストリームの形で提供することができ、前記タルビデオサンプルストリームは、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット、…）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ…）、および任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）を有することができる。メディアサービスシステムでは、ビデオソース（３０１）は、以前に準備されたビデオを記憶する記憶デバイスであってもよい。ビデオ会議システムでは、ビデオソース（３０１）は、ローカル画像情報をビデオシーケンスとして捕捉するカメラであってもよい。ビデオデータは、順番に見られるときに動きを与える複数の個別の画像として提供されることができる。画像自体は、空間画素アレイとして構成されてもよく、ここで、各画素は、使用中のサンプリング構造、色空間などに応じて、１つ以上のサンプルを含むことができる。当業者は、画素とサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。

一実施形態によれば、エンコーダ（３０３）は、リアルタイムで、またはアプリケーションによって要求される任意の他の時間制約の下で、ソースビデオシーケンスの画像を符号化して圧縮し、符号化されたビデオシーケンス（５４３）にすることができる。適切な符号化速度を実施することは、コントローラ（５５０）の１つの機能である。コントローラは、以下で説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。結合は、明瞭にするために図示されていない。コントローラによって設定されたパラメータは、レート制御関連パラメータ（画像スキップ、量子化器、レート歪み最適化技術のλ（ラムダ）値）、画像サイズ、画像グループ（ＧＯＰ：ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ）レイアウト、最大動きベクトル探索範囲などを含むことができる。当業者は、コントローラ（５５０）の他の機能を容易に識別することができ、これらの機能が、特定のシステム設計のために最適化されたビデオエンコーダ（３０３）に関係するからである。

いくつかのビデオエンコーダは、当業者が容易に認識する符号化ループで動作する。過度に簡単化された説明として、符号化ループは、エンコーダ（５３０）（以下、「ソースコーダ」）の符号化部分（符号化される入力画像と、参照画像とに基づいてシンボルを作成することを担当）と、エンコーダ（３０３）に埋め込まれた（ローカル）デコーダ（５３３）とによって構成されることができ、前記デコーダ（４３３）は、（リモート）デコーダによってサンプルデータを作成するようにシンボルを再構築してサンプルデータを作成する（開示された主題で考慮されているビデオ圧縮技術では、シンボルと符号化されたビデオビットストリームとの間の任意の圧縮が無損失であるため）。再構築されたサンプルストリームは、参照画像メモリ（５３４）に入力される。シンボルストリームの復号化により、デコーダの場所（ローカルまたはリモート）に関係なくビット正確な結果が得られるため、参照画像バッファのコンテンツは、ローカルエンコーダとリモートエンコーダとの間でもビットで正確に対応する。言い換えれば、エンコーダの予測部分が「見た」参照画像サンプルは、デコーダが復号化期間に予測を使用する際に「見た」サンプル値と全く同じである。この参照画像の同期性の基本原理（および、例えばチャネル誤差の原因で同期性を維持できない場合に生じるドリフト）は、当業者によく知られている。

「ローカル」デコーダ（５３３）の動作は、既に図４に関連して以上で詳細に説明された、「リモート」デコーダ（３１０）の動作と同じであってもよい。しかし、図５をさらに簡単に参照すると、シンボルが利用可能であり、かつ、エントロピーコーダ（５４５）および解析器（４２０）によって符号化されたビデオシーケンスへのシンボルの符号化／復号化が無損失であることができるため、（チャネル（４１２）、受信機（４１０）、バッファ（４１５）および解析器（４２０）を含む）デコーダ（３１０）のエントロピー復号化部分は、ローカルデコーダ（５３３）で完全に実行されていない可能性がある。

この時点で、デコーダに存在する解析／エントロピー復号化以外のいかなるデコーダ技術も、対応するエンコーダにおいて、実質的に同一の機能形式で必ず存在する必要がある、ということが観察されている。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略できる。特定の領域だけで、より詳細な説明が必要であり、以下で提供される。

その動作の一部として、ソースコーダ（５３０）は、動き補償予測符号化を実行することができ、前記動き補償予測符号化は、ビデオシーケンスから「参照フレーム」として指定された１つ以上の以前に符号化されたフレームを参照して、入力フレームを予測的に符号化する。このようにして、符号化エンジン（５３２）は、入力フレームの画素ブロックと、入力フレームに対する予測参照として選択されることができる参照フレームの画素ブロックとの間の差分を符号化する。

ローカルビデオデコーダ（５３３）は、ソースコーダ（５３０）によって作成されたシンボルに基づいて、参照フレームとして指定されることができるフレームの符号化されたビデオデータを復号化することができる。符号化エンジン（５３２）の動作は、有利には損失性のプロセスであってもよい。符号化されたビデオデータがビデオデコーダ（図５に示されない）で復号化されることができる場合、再構築されたビデオシーケンスは、通常、いくつかの誤差を伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ（５３３）は、参照フレームに対してビデオデコーダによって実行されることができる復号化プロセスを複製して、再構築された参照フレームを参照画像キャッシュ（５３４）に記憶させることができる。このようにして、エンコーダ（３０３）は、遠端ビデオデコーダによって得られる（伝送誤差が存在しない）再構築された参照フレームと共通のコンテンツを有する再構築された参照フレームのコピーを、ローカルに記憶することができる。

予測器（５３５）は、符号化エンジン（５３２）に対して予測検索を実行することができる。すなわち、符号化される新しいフレームについて、予測器（５３５）は、新しい画像の適切な予測参照として機能するサンプルデータ（候補参照画素ブロックとして）または特定のメタデータ、例えば参照画像動きベクトル、ブロック形状などについて、参照画像メモリ（５３４）を検索することができる。予測器（５３５）は、適切な予測参照を見つけるために、サンプルブロックに基づいて、画素ブロックごとに動作することができる。いくつかの場合では、予測器（５３５）によって得られた検索結果によって決定されるように、入力画像は、参照画像メモリ（５３４）に記憶された複数の参照画像から引き出された予測参照を有することができる。

コントローラ（５５０）は、例えば、ビデオデータを符号化するために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ（５３０）の符号化動作を管理することができる。

上述のすべての機能ユニットの出力は、エントロピーコーダ（５４５）においてエントロピー符号化されることができる。エントロピーコーダは、ハフマン符号化、可変長符号化、算術符号化などのような、当業者に知られている技術に従って、シンボルを無損失で圧縮することにより、様々な機能ユニットによって生成されたシンボルを符号化されたビデオシーケンスに変換する。

送信機（５４０）は、符号化されたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアリンクであることができる通信チャネル（５６０）を介した送信に備えるために、エントロピーコーダ（５４５）によって作成された、符号化されたビデオシーケンスをバッファリングすることができる。送信機（５４０）は、ビデオコーダ（５３０）からの符号化されたビデオデータを、送信される他のデータ、例えば、符号化されたオーディオデータおよび／または補助データストリーム（ソースは図示せず）とマージすることができる。

コントローラ（５５０）は、ビデオエンコーダ（３０３）の動作を管理することができる。符号化する期間、コントローラ（５５０）は、各符号化された画像に、特定の符号化された画像タイプを割り当てることができ、これは、それぞれの画像に適用できる符号化技術に影響を与える可能性がある。例えば、以下のフレームタイプのいずれかとして割り当てられることが多い。

フレーム内画像（Ｉ画像）は、シーケンス内の任意の他のフレームを予測ソースとして使用せずに、符号化および復号化されることができるものであってもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ（ＩＤＲ：Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）画像などの異なるタイプのフレーム内画像を許容する。当業者は、Ｉ画像の変種およびそれらのそれぞれのアプリケーションおよび特徴を理解している。

予測画像（Ｐ画像）は、多くとも１つの動きベクトルおよび参照インデックスを使用して各ブロックのサンプル値を予測するフレーム内予測またはフレーム間予測を、使用して符号化および復号化され得るものであってもよい。

双方向予測画像（Ｂ画像）は、多くとも２つの動きベクトルおよび参照インデックスを使用して各ブロックのサンプル値を予測するフレーム内予測またはフレーム間予測を使用して、符号化および復号化され得るものであってもよい。同様に、複数の予測画像は、単一のブロックの再構築に２つ以上の参照画像および関連されたメタデータを使用することができる。

ソース画像は、一般的に、複数のサンプルブロック（例えば、それぞれ４ｘ４、８ｘ８、４ｘ８、または１６ｘ１６個のサンプルのブロック）に空間的に細分化され、ブロックごとに符号化されることができる。これらのブロックは、ブロックのそれぞれの画像に適用される符号化割り当てによって決定されるように、他の（既に符号化された）データブロックを参照して予測的に符号化されることができる。例えば、Ｉ画像のブロックは、非予測的に符号化されてもよく、またはそれらが同じ画像の既に符号化されたブロックを参照して予測的に符号化されてもよい（空間予測またはフレーム内予測）。Ｐ画像の画素ブロックは、１つ前に符号化された参照画像を参照して、空間的予測を介してまたは時間的予測を介して予測的に符号化されてもよい。Ｂ画像のブロックは、１つまたは２つ前に符号化された参照画像を参照して、空間予測または時間領域予測を介して予測的に符号化されてもい。

ビデオコーダ（３０３）は、例えばＩＴＵ―Ｔ ＲＥＣ．Ｈ．２６５などのような所定のビデオ符号化技術または規格に従って、符号化動作を実行することができる。その動作において、ビデオコーダ（３０３）は、入力ビデオシーケンスにおける時間的および空間的冗長性を利用する予測符号化動作を含む、さまざまな圧縮動作を実行することができる。したがって、符号化されたビデオデータは、使用されるビデオ符号化技術または規格によって指定された構文に従うことができる。

一実施形態では、送信機（５４０）は、符号化されたビデオとともに、付加的なデータを送信することができる。ビデオコーダ（５３０）は、そのようなデータを、符号化されたビデオシーケンスの一部として含むことができる。付加的なデータは、時間的／空間的／ＳＮＲ拡張層、冗長画像やスライスなどの他の形式の冗長データ、補足拡張情報（ＳＥＩ：Ｓｕｐｐｌｅｍｅｎｔａｒｙ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージ、視覚ユーザビリティ情報（ＶＵＩ：Ｖｉｓｕａｌ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ）パラメータセットフラグメントなどを含むことができる。

さらに、提案された方法は、処理回路（例えば、１つ以上のプロセッサ、または１つ以上の集積回路）によって実現されることができる。１つの例では、１つ以上のプロセッサは、不揮発性コンピュータ読み取り可能な媒体に記憶されたプログラムを実行して、１つ以上の提案された方法を実行する。

上述の技術は、コンピュータ読み取り可能な命令を使用するコンピュータソフトウェアとして実現され、１つ以上のコンピュータ読み取り可能な媒体に物理的に記憶され得る。例えば、図６は、開示された主題のいくつかの実施形態を実現するのに適したコンピュータシステム１２００を示す。

コンピュータソフトウェアは、任意の適切なマシンコードまたはコンピュータ言語を使用して符号化されてもよく、アセンブリ、コンパイル、リンクなどのメカニズムによって命令を含むコードを作成してもよいし、この命令は、コンピュータ中央処理ユニット（ＣＰＵ：ｃｏｍｐｕｔｅｒ ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、グラフィック処理ユニット（ＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などによって直接的に実行されてもよく、または解釈、マイクロコードなどによって実行されてもよい。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、オブジェクトネットワークデバイス（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ ｄｅｖｉｃｅｓ）などを含む、様々なタイプのコンピュータまたはそのコンポーネントで実行されてもよい。

図６に示されるコンピュータシステム１２００のコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実現するコンピュータソフトウェアの使用範囲または機能に関するいかなる制限も示唆することが意図されていない。コンポーネントの構成は、コンピュータシステム１２００の例示的な実施形態に示されているコンポーネントのいずれかまたは組み合わせに関連する任意の依存性または要件を有すると解釈されるべきではない。

コンピュータシステム１２００は、いくつかのヒューマンインターフェース入力デバイスを含むことができる。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スワイプ、データグローブの動き）、オーディオ入力（例えば、音声、拍手など）、視覚入力（例えば、ジェスチャーなど）、嗅覚入力（図示せず）によって、1人以上のユーザによる入力に応答することができる。ヒューマンインターフェース入力デバイスは、例えばオーディオ（例えば、音声、音楽、環境音など）、画像（例えば、スキャンされた画像、静止画像カメラから得られた写真画像など）、ビデオ（例えば、２次元ビデオ、立体映像を含む３次元ビデオなど）などの、人間による意識的な入力に必ずしも直接関連しているとは限らない、特定のメディアを捕捉するために使用されることもできる。

ヒューマンインターフェース入力デバイスは、キーボード６０１、マウス６０２、トラックパッド６０３、タッチスクリーン６１０、データグローブ、ジョイスティック６０５、マイクロホン６０６、スキャナ６０７、カメラ６０８のうちの１つまたは複数を含むことができる（そのうちの1つだけが図示された）。

コンピュータシステム１２００はまた、いくつかのヒューマンインターフェース出力デバイスを含むことができる。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚によって、１人以上のユーザの感覚を刺激することができる。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン６１０、データグローブ、ジョイスティック６０５による触覚フィードバックであるが、入力デバイスとして作用しない触覚フィードバックデバイスであってもよい）、オーディオ出力デバイス（例えば、スピーカ６０９、ヘッドホン（図示せず））、視覚出力デバイス（例えば、ブラウン管（ＣＲＴ：ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ）スクリーン、液晶ディスプレイ（ＬＣＤ：ｌｉｑｕｉｄ－ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ）スクリーン、プラズマスクリーン、有機発光ダイオード（ＯＬＥＤ：ｏｒｇａｎｉｃ ｌｉｇｈｔ－ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ）スクリーンを含むスクリーン６１０であり、各々は、タッチスクリーン入力機能を備えてもよく、あるいは備えていなくてもよく、各々は、触覚フィードバック機能を備えてもよく、あるいは備えていなくてもよいし、これらのいくつかは、ステレオグラフィック出力、仮想現実メガネ（図示せず）、ホログラフィックディスプレイとスモークタンク（図示せず）、およびプリンタ（図示せず）などによって、２次元の視覚出力または３次元以上の視覚出力を出力することができる。

コンピュータシステム１２００は、例えば、ＣＤ／ＤＶＤを有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ ６２０を含む光学媒体または類似の媒体６２１、サムドライブ６２２、リムーバブルハードドライブまたはソリッドステートドライブ６２３、テープおよびフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの特殊なＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイスなどのような、人間がアクセス可能な記憶デバイスおよびそれらに関連する媒体を含むことができる。

当業者はまた、ここで開示されている主題に関連して使用される「コンピュータ読み取り可能な媒体」という用語が、伝送媒体、搬送波、または他の一時的な信号を包含しないことを理解すべきである。

コンピュータシステム１２００はまた、１つ以上の通信ネットワークへのインターフェースを含むことができる。ネットワークは、例えば、無線、有線、光学的であってもよい。ネットワークはさらに、ローカルネットワーク、広域ネットワーク、大都市圏ネットワーク、車両用ネットワークおよび産業用ネットワーク、リアルタイムネットワーク、遅延耐性ネットワークなどであってもよい。ネットワークの例は、イーサネット（登録商標）、無線ＬＡＮ、セルラーネットワーク（モバイル通信のグローバルシステム（ＧＳＭ：ｇｌｏｂａｌ ｓｙｓｔｅｍｓ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、第３世代（３Ｇ：ｔｈｉｒｄ ｇｅｎｅｒａｔｉｏｎ）、第４世代（４Ｇ：ｆｏｕｒｔｈ ｇｅｎｅｒａｔｉｏｎ）、第５世代（５Ｇ：ｆｉｆｔｈ ｇｅｎｅｒａｔｉｏｎ）、長期進化（ＬＴＥ：Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などを含む）などのＬＡＮ、有線テレビまたは無線広域デジタルネットワーク（テレビケーブル、衛星テレビ、地上放送テレビを含む）、車両用ネットワークおよび産業用ネットワーク（ＣＡＮＢｕｓを含む）などを含む。いくつかのネットワークは、一般に、いくつかの汎用データポートまたは周辺バス（６４９）（例えば、コンピュータシステム１２００のユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）ポート）に接続された外部ネットワークインターフェースアダプタが必要であり、他のシステムは、通常、以下に説明するようにシステムバスに接続することによって、コンピュータシステム１２００のコアに統合される（例えば、イーサネットインターフェースからＰＣコンピュータシステムへ、またはセルラーネットワークインターフェースからスマートフォンコンピュータシステムへ）。これらのネットワークのいずれかを使用して、コンピューターシステム１２００は、他のエンティティと通信することができる。このような通信は、単方向の受信のみ（例えば、放送ＴＶ）、単方向の送信のみ（例えば、ＣＡＮバスから特定のＣＡＮバスデバイスへ）、あるいは、双方向の、例えばローカルまたは広域デジタルネットワークを使用して他のコンピュータシステムへの通信であってもよい。上記のように、特定のプロトコルおよびプロトコルスタックは、それらのネットワークおよびネットワークインターフェースのそれぞれで使用されることができる。

上記のヒューマンインターフェースデバイス、ヒューマンアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム１２００のコア６４０に接続されることができる。

コア６４０は、１つ以上の中央処理ユニット（ＣＰＵ）６４１、画像処理ユニット（ＧＰＵ）６４２、フィールドプログラマブルゲートエリア（ＦＰＧＡ）６４３の形式の専用プログラマブル処理ユニット、特定のタスクのためのハードウェア加速器６４４などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）６４５、ランダムアクセスメモリ（ＲＡＭ）６４６、例えば内部の非ユーザアクセスハードドライブ、ソリッドステートドライブ（ＳＳＤ：ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅｓ）などの内部大容量ストレージ６４７などとともに、システムバス６４８を介して接続されてもよい。いくつかのコンピューターシステムでは、システムバス６４８は、付加的なＣＰＵ、ＧＰＵなどによって拡張を可能にするために、１つ以上の物理的プラグの形でアクセスすることができる。周辺デバイスは、コアのシステムバス６４８に直接に接続されてもよく、または周辺バス６４９を介して接続されてもよい。周辺バスのアーキテクチャは、外部コントローラインターフェース（ＰＣＩ：ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ）、汎用シリアルバス（ＵＳＢ）などを含む。

ＣＰＵ ６４１、ＧＰＵ ６４２、ＦＰＧＡ ６４３、および加速器６４４は、いくつかの命令を実行することができ、これらの命令を組み合わせて上記のコンピュータコードを構成することができる。そのコンピュータコードは、ＲＯＭ ６４５またはＲＡＭ ６４６に記憶されることができる。また、一時的なデータは、ＲＡＭ ６４６に記憶されることができる一方、永久的なデータは、例えば内部大容量ストレージ６４７に記憶されることができる。１つ以上のＣＰＵ ６４１、ＧＰＵ ６４２、大容量ストレージ６４７、ＲＯＭ ６４５、ＲＡＭ ６４６などと密接に関連することができる、高速ストレージを使用することにより、任意のメモリデバイスに対する高速記憶および検索が可能になる。

コンピュータ読み取り可能な媒体は、様々なコンピュータ実行された動作を実行するためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構成されたものであってもよく、またはコンピューターソフトウェア分野の技術者によって知られ、利用可能な媒体およびコードであってもよい。

限定ではなく例として、アーキテクチャ１２００、特にコア６４０を有するコンピュータシステムは、１つ以上の有形な、コンピュータ読み取り可能な媒体に具体化されたソフトウェアを実行する、（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、加速器などを含む）プロセッサの結果として機能を提供することができる。このようなコンピュータ読み取り可能な媒体は、上述したようにユーザがアクセス可能な大容量ストレージに関連する媒体であり、コア内部大容量ストレージ６４７またはＲＯＭ ６４５などの、不揮発性コア６４０を有する特定のストレージであってもよい。本開示の様々な実施形態を実現するソフトウェアは、そのようなデバイスに記憶され、コア６４０によって実行されてもよい。コンピュータ読み取り可能な媒体は、特定のニーズに応じて、１つ以上のメモリデバイスまたはチップを含むことができる。このソフトウェアは、コア６４０、具体的にはその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ ６４６に記憶されているデータ構造を定義することと、ソフトウェアによって定義されたプロセスに従ってこのようなデータ構造を変更することとを含む、ここで説明された特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えてまたは代替として、コンピュータシステムは、ロジックハードワイヤまたは他の方式で回路（例えば、加速器６４４）で具体化された結果としての機能を提供することができ、この回路は、ソフトウェアの代わりに動作しまたはソフトウェアと一緒に動作して、ここで説明された特定のプロセスまたは特定のプロセスの特定の部分を実行してもよい。適切な場合には、ソフトウェアへの参照はロジックを含むことができ、逆もまた然りである。適切な場合には、コンピュータ読み取り可能な媒体への参照は、実行のソフトウェアを記憶する回路（例えば、集積回路（ＩＣ）など）、実行のロジックを具体化する回路、またはその両方を兼ね備えることができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。

図７は、サブブロックのセットを生成するために、統合されたツリー深さを使用してブロックを分割するための例示的なプロセスのフローチャートである。

図７に示すように、例示的なプロセスは、サブブロックのセットを生成するために、正方形分割という分割パターン、水平二分木という分割パターン、または水平三分木という分割パターンを使用してブロックを分割することを含むことができる（ステップ７１０）。同じ優先度が、正方形分割という分割パターン、水平二分木という分割パターン、および水平三分木という分割パターンに割り当てられ、正方形分割という分割パターンが、水平二分木という分割パターンおよび水平三分木という分割パターンの前、後に、またはそれらの分割パターンと交互に使用されることができる。

図７にさらに示されるように、このプロセスは、別の分割が実行されるべきかどうかを決定することを含むことができる（ステップ７２０）。

別の分割を実行する場合（ステップ７２０における「はい」）、このプロセスは、ステップ７１０に戻る。それ以外の場合、図７にさらに示されるように、例示的なプロセスは、正方形分割という分割パターン、水平二分木という分割パターン、または水平三分木という分割パターンを使用してブロックを分割することに基づいて、ビデオシーケンスの符号化または復号化を実行することを含むことができる（ステップ７３０）。

本開示は、いくつかの例示的な実施形態について説明したが、本開示の範囲内にある変更、置換、および様々な均等置換が存在している。したがって、当業者は、本明細書では明示的に示されていないか、または説明されていないが、本開示の原則を具体化しているので、本開示の精神および範囲内ある、様々なシステムおよび方法を設計することができる、ということを理解されたい。

Claims (9)

1. エンコーダにおいてブロック分割を行う装置が実行するブロック分割方法であって、
   現在のブロックを分割するかどうかを決定し、現在のブロックを分割するかどうかを指示する第一構文要素の値を決定するステップと、
   前記現在のブロックを分割すると決定したとき、方形分割パターンを用いて前記現在のブロックを分割するかどうかを決定し、方形分割パターンを用いて前記現在のブロックを分割するかどうかを指示する第二構文要素の値を決定するステップと、
   方形分割パターンを用いて前記現在のブロックを分割しないと決定したとき、
   前記現在のブロックの少なくとも一つのサブブロックを水平木分割パターンを用いて分割するか垂直木分割パターンを用いて分割するかを決定し、前記現在のブロックの少なくとも一つのサブブロックを水平木分割パターンを用いて分割するか垂直木分割パターンを用いて分割するかを指示する第三構文要素の値を決定し、
   前記少なくとも一つのサブブロックを二分木分割パターンを用いて分割するか三分木分割パターンを用いて分割するかを決定し、前記少なくとも一つのサブブロックを二分木分割パターンを用いて分割するか三分木分割パターンを用いて分割するかを指示する第四構文要素の値を決定するステップと、
   を含み、
   前記装置が、前記二分木分割パターン及び前記三分木分割パターンを使用する前に、前記方形分割パターンを使用する、ブロック分割方法。
2. 前記第一構文要素の値が0または1を含み、
   前記現在のブロックを分割すると決定したとき、前記第一構文要素の値は1であると決定し、
   前記現在のブロックを分割しないと決定したとき、前記第一構文要素の値は0であると決定する、
   請求項１に記載のブロック分割方法。
3. 前記第二構文要素の値が0または1を含み、
   前記現在のブロックを複数の方形に分割すると決定したとき、前記第二構文要素の値は1であると決定し、
   前記現在のブロックを複数の方形に分割しないと決定したとき、前記第二構文要素の値が0であると決定する、
   請求項１または２に記載のブロック分割方法。
4. 前記第三構文要素の値が0または1を含み、
   前記垂直木分割パターンを用いて前記現在のブロックの少なくとも一つのサブブロックを分割すると決定したとき、前記第三構文要素の値は1であると決定し、
   前記水平木分割パターンを用いて前記現在のブロックの少なくとも一つのサブブロックを分割すると決定したとき、前記第三構文要素の値が0であると決定する、
   請求項１～３の何れか一項に記載のブロック分割方法。
5. 前記第四構文要素の値が0または1を含み、
   前記三分木分割パターンを用いて前記現在のブロックの少なくとも一つのサブブロックを分割すると決定したとき、前記第四構文要素の値は1であると決定し、
   前記二分木分割パターンを用いて前記現在のブロックの少なくとも一つのサブブロックを分割すると決定したとき、前記第四構文要素の値は0であると決定する、
   請求項１～４の何れか一項に記載のブロック分割方法。
6. 前記装置が、
   

   

   に基づき、前記第一構文要素、前記第二構文要素、前記第三構文要素および前記第四構文要素を決定することをさらに含み、
   前記ビン０は、前記第一構文要素を表し、前記ビン１は、前記第二構文要素を表し、前記ビン３は、前記第三構文要素を表し、前記ビン４は、前記第四構文要素を表す、
   請求項１～５の何れか一項に記載のブロック分割方法。
7. 前記第一構文要素の値が、現在のブロックが分割されないことを示す場合、前記第二構文要素、前記第三構文要素および前記第四構文要素は前記エンコーダによって生成されるビットストリームに含められず、
   前記第二構文要素の値が、現在のブロックが複数の方形に分割されることを示す場合、前記第三構文要素および前記第四構文要素は前記エンコーダによって生成されるビットストリームに含められない、
   請求項１～６の何れか一項に記載のブロック分割方法。
8. コンピュータに、請求項１～７の何れか一項に記載のブロック分割方法を実行させるためのプログラム。
9. ブロック分割を行う装置であって、
   プログラムを記憶しているメモリと、
   前記メモリに接続されるプロセッサと、
   を含み、
   前記プロセッサは、前記プログラムを実行して、請求項１～７の何れか一項に記載のブロック分割方法を実現するように構成される、装置。

Images