JP7378485B2 - Ｑｔ／ｂｔ／ｔｔサイズの改善されたヘッダシンタックス - Google Patents

Ｑｔ／ｂｔ／ｔｔサイズの改善されたヘッダシンタックス Download PDF

Info

Publication number
JP7378485B2
JP7378485B2 JP2021548146A JP2021548146A JP7378485B2 JP 7378485 B2 JP7378485 B2 JP 7378485B2 JP 2021548146 A JP2021548146 A JP 2021548146A JP 2021548146 A JP2021548146 A JP 2021548146A JP 7378485 B2 JP7378485 B2 JP 7378485B2
Authority
JP
Japan
Prior art keywords
ctu
slice
size
luma
video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021548146A
Other languages
English (en)
Other versions
JP2022520855A (ja
Inventor
イシン・ドゥ
シアン・リ
シン・ジャオ
シャン・リュウ
ビョンドゥ・チェ
ステファン・ヴェンガー
Original Assignee
テンセント・アメリカ・エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テンセント・アメリカ・エルエルシー filed Critical テンセント・アメリカ・エルエルシー
Publication of JP2022520855A publication Critical patent/JP2022520855A/ja
Application granted granted Critical
Publication of JP7378485B2 publication Critical patent/JP7378485B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

関連出願の相互参照
[1]本出願は、２０１９年８月２７日に提出された仮出願第ＵＳ６２／８９２，２４６号、および２０２０年８月２１日に提出された非仮出願第ＵＳ１６／９９９，６５７号の優先権を主張する。これらの出願の全ての内容は、参照により本願に組み込むものとする。
１、分野
[2]本開示は、改善されたＱＴ／ＢＴ／ＴＴサイズシンタックスを含む一連の高度なビデオコーディング技術によってビット効率を改善することを目的とする。
２、関連技術の説明
[3]ＩＴＵ－Ｔ ＶＣＥＧ（Ｑ６／１６）およびＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ １／ＳＣ ２９／ＷＧ １１）は、Ｈ．２６５／ＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ：高効率ビデオコーディング）規格を、２０１３年（バージョン１）、２０１４年（バージョン２）、２０１５年（バージョン３）および２０１６年（バージョン４）に公開した。２０１５年、これら２つの標準化団体が共同でＪＶＥＴ（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｌｏｒａｔｉｏｎ Ｔｅａｍ：共同ビデオ探索チーム）を結成し、ＨＥＶＣを超える次のビデオコーディング規格の開発の可能性を探った。２０１７年１０月、「ＨＥＶＣを超える性能を備えたビデオ圧縮に関する提案の共同募集（ＣｆＰ）」を発行した。２０１８年２月１５日までに、標準ダイナミックレンジ（ＳＤＲ）に関するＣｆＰ回答が計２２件、ハイダイナミックレンジ（ＨＤＲ）に関するＣｆＰ回答が計１２件、３６０ビデオカテゴリに関するＣｆＰ回答が計１２件、それぞれ提出された。２０１８年４月、１２２ ＭＰＥＧ ／ １０ｔｈ ＪＶＥＴ会議において、受信されたＣｆＰ回答がすべて評価された。この会議の結果、ＪＶＥＴはＨＥＶＣを超える次世代ビデオコーディングの標準化プロセスを正式に開始した。新しい規格は多用途ビデオコーディング（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ、ＶＶＣ）と名付けられ、ＪＶＥＴは共同ビデオエキスパートチーム（Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｅｒｔ Ｔｅａｍ）と改称された。ＶＴＭ（ＶＶＣ Ｔｅｓｔ Ｍｏｄｅｌ）の現在のバージョンは、ＶＴＭ ６である。
[4]ＶＶＣ Ｄｒａｆｔ ６では、以下の表１および表２のハイライト領域に示されるように、ＱＴ／ＢＴ／ＴＴのサイズを記述するシンタックス要素がある。前述した各シンタックスは、２つの数値の基数２の対数間のデフォルトの差分を指定する。
Figure 0007378485000001
Figure 0007378485000002
[5]上記を踏まえて、ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数と、スライスにおけるルマＣＵｓのルマサンプル内の最小コーディングブロックサイズの基数２の対数とのデフォルトの差分を指定するシンタックスｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｍｉｎ＿ｑｔ＿ｍｉｎ＿ｃｂ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａを例として考える。従って、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。ＣｔｂＬｏｇ２ＳｉｚｅＹは、ｌｏｇ２＿ｃｔｕ＿ｓｉｚｅ＿ｍｉｎｕｓ５＋５として導出されるため、ＣＴＵサイズがそれぞれ３２×３２、６４×６４、１２８×１２８の場合、その値は［５，６，７］以内となる。一方、ＶＶＣ Ｄｒａｆｔ ６では、ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹの値が２であると指定されている。したがって、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｍｉｎ＿ｑｔ＿ｍｉｎ＿ｃｂ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの最大値は、ＣＴＵサイズに応じて［３，４，５］以内となる。
[6]しかし、ＱＴ／ＢＴ／ＴＴのｍａｘ値が一般的にＣＴＵサイズに設定されているため、ｍａｘ ＱＴ／ＢＴ／ＴＴとｍｉｎ ＱＴ／ＣＢとの間の差分をシグナリングすることは、ビット効率が良くない。
[7]このため、そのような問題に対する技術的な解決策が望まれている。
[8]１つまたは複数の異なる課題に対処するために、本開示は、ＱＴ／ＴＴ／ＢＴサイズを記述するように設計された新しいシンタックスおよびその使用について説明した。実施形態によれば、これらのシンタックスは、基数をｍｉｎ ＣＢ／ＱＴからＣＴＵに変更しており、実施形態では、ＱＴ／ＴＴ／ＢＴのサイズをより小さな数値（ｎｕｍｂｅｒｓ）を用いてシグナリングすることが可能となる。したがって、コーディング効率の向上を図ることができる。
[9]コンピュータプログラムコードを記憶するように構成されるメモリと、前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令された通りに動作するように構成される１以上のプロセッサとを含む方法および装置が含まれる。前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサに、ビデオデータからコーディングツリーユニット（ＣＴＵ）を取得させるように構成される取得コードと、前記少なくとも１つのプロセッサに、前記ＣＴＵを四分木構造によってパーティションさせるように構成されるパーティションコードと、前記少なくとも１つのプロセッサに、前記パーティションされたＣＴＵのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションさせるように構成される更なるパーティションコードと、前記少なくとも１つのプロセッサに、前記ＣＴＵを前記四分木構造によってパーティションすることと、前記パーティションされたＣＴＵのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズと、少なくとも１つの値との間の差分を、基数２の対数でシグナリングさせるように構成されるシグナリングコードと、を含む。
[10]実施形態によれば、前記少なくとも１つの値は、前記ＣＴＵのサイズを含む。
[11]実施形態によれば、前記サンプルのサイズは、前記ＣＴＵを前記四分木構造によってパーティションした結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数である。
[12]実施形態によれば、前記サンプルのサイズは、前記パーティションされたＣＴＵの前記リーフノードを前記二分木構造によってパーティションした結果得られるルマコーディングブロックのルマサンプルにおける最大サイズの基数２の対数である。
[13]実施形態によれば、前記サンプルのサイズは、前記パーティションされたＣＴＵの前記リーフノードを前記三分木構造によってパーティションした結果得られるルマコーディングブロックのルマサンプルにおける最大サイズの基数２の対数である。
[14]実施形態によれば、前記サンプルのサイズは、前記パーティションされたＣＴＵの前記リーフノードを前記二分木構造によってパーティションした結果得られるクロマコーディングブロックの最大サイズの基数２の対数である。
[15]実施形態によれば、前記サンプルのサイズは、前記パーティションされたＣＴＵの前記リーフノードを前記三分木構造によってパーティションした結果得られるクロマコーディングブロックの最大サイズの基数２の対数である。
[16]実施形態によれば、前記サンプルのサイズは、前記ＣＴＵを前記四分木構造によってパーティションした結果得られるクロマリーフブロックの最小サイズの基数２の対数である。
[17]実施形態によれば、前記少なくとも１つの値は、前記ＣＴＵのコーディングブロック（ＣＢ）の最小サイズを含む。
[18]実施形態によれば、前記少なくとも１つの値は、所定値である。
[19]開示された主題のさらなる特徴、本質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。
実施形態による簡略図である。 実施形態による概略図である。 実施形態による概略図である。 実施形態による概略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略流れ図である。 実施形態による図を示す概略図である。
[35]以下に説明する提案された特徴は、別々に使用しても、任意の順序で組み合わせてもよい。さらに、実施形態は、処理回路（例えば、１つまたは複数のプロセッサ或いは１つまたは複数の集積回路）によって実装されてもよい。一例では、１つまたは複数のプロセッサは、非一時的なコンピュータ読取可能な媒体に記憶されているプログラムを実行する。
[36]図１は、本開示の一実施形態による通信システム１００の簡略ブロック図を示している。通信システム１００は、ネットワーク１０５を介して相互接続された少なくとも２つの端末１０２および１０３を含み得る。データの単方向送信の場合、第１の端末１０３は、ネットワーク１０５を介して他方の端末１０２へ送信するために、ビデオデータをローカル位置でコード化してもよい。第２の端末１０２は、ネットワーク１０５から他方の端末のコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータを表示することができる。単方向のデータ送信は、メディア供給アプリケーションなどで一般的である。
[37]図１は、例えばビデオ会議中に発生し得るコード化されたビデオの双方向送信をサポートするために提供される第２の対の端末１０１および１０４を示している。データの双方向送信の場合、各端末１０１および１０４は、ネットワーク１０５を介して他方の端末へ送信するために、ローカル位置でキャプチャされたビデオデータをコード化してもよい。また、各端末１０１および１０４は、他方の端末で送信されたコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータをローカルの表示装置に表示することができる。
[38]図１において、端末１０１，１０２，１０３および１０４は、サーバ、パーソナルコンピュータ、およびスマートフォンとして示され得るが、本開示の原理はこれに制限されることはない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤーおよび／または専用のビデオ会議機器における用途を見出す。ネットワーク１０５は、例えば有線および／または無線通信ネットワークを含む、端末１０１，１０２，１０３および１０４間でコード化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク１０５は、回線交換および／またはパケット交換チャネルでデータを交換することができる。代表的なネットワークとしては、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットが挙げられる。本議論の目的のために、ネットワーク１０５のアーキテクチャおよびトポロジーは、以下に説明されない限り、本開示の動作にとって重要ではないかもしれない。
[39]図２は、開示された主題のアプリケーションの一例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示している。開示された主題は、例えば、ビデオ会議、デジタルＴＶ、および、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタルメディアへの圧縮されたビデオの記憶など、を含む他のビデオ対応アプリケーションに等しく適用可能である。
[40]ストリーミングシステムは、例えば非圧縮のビデオサンプルストリーム２１３を作成するデジタルカメラのようなビデオソース２０１を含むことができるキャプチャサブシステム２０３を含んでもよい。そのサンプルストリーム２１３は、符号化されたビデオビットストリームと比較して高データ量として強調されることがあり、カメラ２０１に結合されたエンコーダ２０２によって処理されることができる。エンコーダ２０２は、以下でより詳細に説明するように、開示された主題の態様を可能にするかまたは実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプルストリームと比較してより低いデータ量として強調され得る符号化されたビデオビットストリーム２０４は、将来使うためにストリーミングサーバ２０５に記憶されることができる。１つまたは複数のストリーミングクライアント２１２および２０７は、ストリーミングサーバ２０５にアクセスして、符号化されたビデオビットストリーム２０４のコピー２０８および２０６を検索することができる。クライアント２１２は、符号化されたビデオビットストリームの入り方向コピー２０８をデコードし、ディスプレイ２０９または他のレンダリングデバイス（図示せず）でレンダリングできる出方向ビデオサンプルストリーム２１０を作成するビデオデコーダ２１１を含むことができる。一部のストリーミングシステムにおいて、ビデオビットストリーム２０４、２０６および２０８は、特定のビデオコーディング／圧縮規格に従って符号化されることができる。これらの規格の例は、上で述べられ、ここでさらに説明される。
[41]図３は、本発明の一実施形態によるビデオデコーダ３００の機能ブロック図である。
[42]受信機３０２は、デコーダ３００によってデコードされる１つまたは複数のコード化されたビデオシーケンスを受信することができ、同一または別の実施形態では、一度に１つのコーディングされたビデオシーケンスを受信してもよく、各コード化されたビデオシーケンスのデコードは、他のコード化されたビデオシーケンスから独立している。コード化されたビデオシーケンスは、符号化されたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得るチャネル３０１から受信されることができる。受信機３０２は、それぞれの使用エンティティ（図示せず）に転送され得る他のデータ、例えば、コード化されたオーディオデータおよび／または補助データストリームとともに、符号化されたビデオデータを受信し得る。受信機３０２は、コード化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタを防止するために、バッファメモリ３０３は、受信機３０２とエントロピーデコーダ／パーサ３０４（以降、「パーサ」）の間に結合されてもよい。受信機３０２が十分な帯域幅および可制御性を有する記憶／転送装置から、または等同期ネットワークからデータを受信する際に、バッファ３０３は必要とされないことがあり、または小さくされることがある。インターネットのようなベストエフォートパケットネットワークで使用するために、バッファ３０３が必要になる場合があり、バッファ３０３は、比較的大きいことがあり、有利には適応サイズであることができる。
[43]ビデオデコーダ３００は、エントリピーコード化されたビデオシーケンスからシンボル３１３を再構築するパーサ３０４を含んでもよい。これらのシンボルのカテゴリは、デコーダ３００の動作を管理するために使用される情報、および、デコーダの不可欠な部分ではないが、デコーダに結合され得るディスプレイ３１２のようなレンダリングデバイスを制御する潜在的情報を含む。レンダリングデバイスのための制御情報は、補助強化情報（ＳＥＩメッセージ）またはビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメント（図示せず）の形態であってよい。パーサ３０４は、受信されたコード化されたビデオシーケンスを構文解析／エントロピーデコードすることができる。コード化されたビデオシーケンスのコーディングは、ビデオコーディング技術または規格に合わせることができ、可変長コーディング、ハフマンコーディング、文脈感受性を有するもしくは有さない算術コーディングなどを含む、当業者によく知られている原理に従うことができる。パーサ３０４は、グループに対応する少なくとも１つのパラメータに基づいて、コード化されたビデオシーケンスから、ビデオデコーダ内の画素の少なくとも１つのサブグループのためのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャ群（ＧＯＰｓ）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（ＣＵｓ）、ブロック、変換ユニット（ＴＵｓ）、予測ユニット（ＰＵｓ）などを含むことができる。エントロピーデコーダ／パーサは、コード化されたビデオシーケンスから変換係数、量子化パラメータ値、動きベクトルのような情報をも抽出することができる。
[44]パーサ３０４は、シンボル３１３を作成するために、バッファ３０３から受信されたビデオシーケンスに対してエントロピーデコード／構文解析動作を実行することができる。パーサ３０４は、符号化されたデータを受信し、特定のシンボル３１３を選択的にデコードしてもよい。さらに、パーサ３０４は、特定のシンボル３１３を、動き補償予測ユニット３０６、スケーラ／逆変換ユニット３０５、イントラ予測ユニット３０７、またはループフィルタ３１１のいずれに提供するか否かを決定してもよい。
[45]シンボル３１３の再構築は、コード化されたビデオピクチャまたはその一部（例えば、インターおよびイントラピクチャ、インターおよびイントラブロック）のタイプ、および他の要因に応じて、複数の異なるユニットが関与することができる。どのユニットが、どのように関与するかは、パーサ３０４によって、コード化されたビデオシーケンスから構文解析されたサブグループ制御情報によって制御されることができる。パーサ３０４と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。
[46]すでに述べた機能ブロックに加え、デコーダ３００は、以下に説明されるようにいくつかの機能ユニットに概念的に細分されることができる。商業的な制約の下で実際の実施動作にあたっては、これらのユニットの多くは互いに密接に相互作用し、少なくとも一部は互いに統合することができる。しかしながら、開示された主題の説明の目的で、以下の機能ユニットへの概念的な細分は、適切に行われる。
[47]第１のユニットは、スケーラ／逆変換ユニット３０５である。スケーラ／逆変換ユニット３０５は、使用する変換、ブロックサイズ、量子化因子、量子化スケーリングマトリックスなどを含む制御情報と、量子化された変換係数をシンボル３１３としてパーサ３０４から受信する。スケーラ／逆変換ユニット３０５は、アグリゲータ３１０に入力可能なサンプル値を含むブロックを出力することができる。
[48]場合によっては、スケーラ／逆変換３０５の出力サンプルは、イントラコーディングブロック、すなわち、予め再構築されたピクチャからの予測情報を使用していないが、現在ピクチャの予め再構築された部分からの予測情報を使用できるブロックに関係することがある。このような予測情報は、イントラピクチャ予測ユニット３０７によって提供されることができる。場合によっては、イントラピクチャ予測ユニット３０７は、現在の（一部再構築された）ピクチャ３０９から取り出された周囲の既に再構築された情報を用いて、再構築中のブロックの同じサイズおよび形状のブロックを生成する。アグリゲータ３１０は、場合によっては、サンプルごとに、イントラ予測ユニット３０７が生成した予測情報を、スケーラ／逆変換ユニット３０５によって提供される出力サンプル情報に追加する。
[49]他の場合では、スケーラ／逆変換ユニット３０５の出力サンプルは、インターコード化された、潜在的に動き補償されたブロックに関係することがある。このような場合、動き補償予測ユニット３０６は、参照ピクチャメモリ３０８にアクセスして、予測に使用されるサンプルを取り出すことができる。取り出されたサンプルをブロックに関係するシンボル３１３に従って動き補償した後、出力サンプル情報を生成するように、これらのサンプルは、アグリゲータ３１０によってスケーラ／逆変換ユニットの出力に追加されることができる（この場合、残差サンプルまたは残差信号と呼ばれる）。動き補償予測ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、Ｘ、Ｙ、および参照ピクチャ成分を有し得るシンボル３１３の形態で動き補償予測ユニットに利用可能な動きベクトルによって制御されることができる。動き補償は、サブサンプル正確な動きベクトルが使用中であるときに参照ピクチャメモリから取り出されたサンプル値の補間、動きベクトル予測メカニズムなどを含むこともできる。
[50]アグリゲータ３１０の出力サンプルは、ループフィルタユニット３１１において様々なループフィルタリング手法を受けられる。ビデオ圧縮技術は、コード化されたビデオストリームに含まれる、パーサ３０４からのシンボル３１３としてループフィルタユニット３１１に利用可能とされたパラメータによって制御されることができ、それに、コード化ピクチャまたはコード化ビデオシーケンスの（デコード順で）前の部分のデコード中に取得されたメタ情報に応じるとともに、予め再構築されループフィルタリングされたサンプル値に応じることもできるループ内フィルタ技術を含むことができる。
[51]ループフィルタユニット３１１の出力は、レンダリングデバイス３１２へ出力されることができるとともに、将来のインターピクチャ予測で使用するために参照ピクチャメモリ５５７に記憶されることができるサンプルストリームであり得る。
[52]特定のコード化ピクチャは、完全に再構築されると、将来の予測のために参照ピクチャとして使用されることができる。コード化ピクチャが完全に再構築され、コード化ピクチャが（例えば、パーサ３０４によって）参照ピクチャとして識別されると、現在参照ピクチャ３０９は、参照ピクチャバッファ３０８の一部になることができ、次のコード化ピクチャの再構築を開始する前に新しい現在ピクチャメモリを再割当てすることができる。
[53]ビデオデコーダ３００は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５のような規格で文書化され得る所定のビデオ圧縮技術に従ってデコード動作を実行することができる。コード化されたビデオシーケンスは、ビデオ圧縮技術の文書または規格、具体的にはその中のプロファイル文書で指定された、ビデオ圧縮技術または規格のシンタックスに準拠するという意味で、使用されているビデオ圧縮技術または規格によって指定されたシンタックスに準拠し得る。コード化されたビデオシーケンスの複雑さがビデオ圧縮技術または規格のレベルによって定義される範囲内にあることも、コンプライアンスに必要である。場合によっては、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート（例えば、１秒あたりのメガサンプルで測定される）、最大参照ピクチャサイズなどがレベルによって制限される。レベルによって設定された制限は、場合によっては、仮想参照デコーダ（ＨＲＤ）仕様およびコード化されたビデオシーケンスでシグナリングされたＨＲＤバッファ管理のためのメタデータによってさらに制限され得る。
[54]一実施形態では、受信機３０２は、符号化されたビデオとともに追加の（冗長な）データを受信することができる。追加のデータは、コード化されたビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードし、および／または、元のビデオデータをより正確に再構築するためにビデオデコーダ３００によって使用され得る。追加のデータは、例えば、時間的、空間的、または信号対雑音比（ＳＮＲ）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方向誤り訂正コードのような形態にされることができる。
[55]図４は、本開示の一実施形態によるビデオエンコーダ４００の機能ブロック図である。
[56]エンコーダ４００は、エンコーダ４００によってコード化されるビデオ画像をキャプチャし得るビデオソース４０１（デコーダの一部ではない）からビデオサンプルを受信することができる。
[57]ビデオソース４０１は、エンコーダ（３０３）によってコード化されるソースビデオシーケンスを、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット、・・・）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、・・・）および任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）であり得るデジタルビデオサンプルストリームの形態で提供し得る。メディア供給システムでは、ビデオソース４０１は、予め準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース４０１は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、順番に見られるときに動きが与えられる複数の個別のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間アレイとして編成されてもよく、各画素は、使用中のサンプリング構造、色空間などに応じて１つまたは複数のサンプルを含むことができる。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明ではサンプルを中心に説明する。
[58]一実施形態によれば、エンコーダ４００は、リアルタイムでまたはアプリケーションが要求する任意の他の時間制約の下でソースビデオシーケンスのピクチャをコード化し、コード化されたビデオシーケンス４１０に圧縮することができる。適切なコーディング速度を実施することは、コントローラ４０２の機能の１つである。コントローラは、以下に説明される他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、カップリングは示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化、レート歪み最適化手法のラムダ値、・・・）、ピクチャサイズ、ピクチャ群（ＧＯＰ）レイアウト、最大動きベクトル検索範囲などを含むことができる。当業者であれば、特定のシステム設計に対して最適化されたビデオエンコーダ４００に関係し得るので、コントローラ４０２の他の機能を容易に認識することができる。
[59]ビデオエンコーダの中には、当業者が容易に認識できる「コーディングループ」で動作するものがある。過度に簡略化した説明として、コーディングループは、エンコーダ４０２（以降、「ソースコーダ」）（コーディング対象となる入力ピクチャおよび参照ピクチャに基づくシンボルの作成を担当する）と、エンコーダ４００に埋め込まれた（ローカル）デコーダ４０６であって、シンボルを再構築して、（リモート）デコーダも作成するであろうサンプルデータを作成する（シンボルとコード化されたビデオビットストリーム間の如何なる圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるためである）デコーダ４０６とから構成され得る。再構築されたサンプルストリームは参照ピクチャメモリ４０５に入力される。シンボルストリームのデコードにより、デコーダの位置（ローカルまたはリモート）に関係なくビット正確な結果が得られるため、参照ピクチャバッファのコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えれば、エンコーダの予測部分は、参照ピクチャサンプルとして、デコード中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を「見る」。参照ピクチャの同期性の該基本原理（および例えばチャネルエラーに起因して同期性を維持できない場合に生じるドリフト）は、当業者によく知られている。
[60]「ローカル」デコーダ４０６の動作は、前文で図３に関連して既に詳細に説明された、「リモート」デコーダ３００の動作と同様であり得る。しかしながら、図４も簡単に参照し、シンボルが使用可能であり、エントロピーコーダ４０８およびパーサ３０４によるコード化されたビデオシーケンスへのシンボルのエンコード／デコードは可逆であり得るので、チャネル３０１、受信機３０２、バッファ３０３、およびパーサ３０４を含むデコーダ３００のエントロピーデコード部分は、ローカルデコーダ４０６では完全に実施されない場合がある。
[61]これで分かるように、デコーダに存在する構文解析／エントロピーデコード以外の如何なるデコーダ技術も、対応するエンコーダにて実質的に同一の機能的形態で必ず存在する必要がある。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略できる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。
[62]その動作の一部として、ソースコーダ４０３は、「参照フレーム」として指定されたビデオシーケンスからの１つまたは複数の予めコード化されたフレームを参照して入力フレームを予測的にコード化する動き補償予測コーディングを実行してもよい。このようにして、コーディングエンジン４０７は、入力フレームの画素ブロックと、入力フレームへの予測基準として選択され得る参照フレームの画素ブロックとの差異をコード化する。
[63]ローカルビデオデコーダ４０６は、ソースコーダ４０３で作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコード化ビデオデータをデコードすることができる。コーディングエンジン４０７の動作は、有利にはロッシープロセスであり得る。コード化ビデオデータがビデオデコーダ（図４に示されていない）でデコードされ得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ４０６は、ビデオデコーダによって参照フレームに対して実行され得るデコードプロセスを再現し、再構築された参照フレームを参照ピクチャキャッシュ４０５に記憶させることができる。このようにして、エンコーダ４００は、遠端ビデオデコーダによって取得される再構築された参照フレームと共通するコンテンツ（送信エラー無し）を有する再構築された参照フレームのコピーをローカルに記憶し得る。
[64]予測器４０４は、コーディングエンジン４０７の予測検索を実行することができる。つまり、コード化対象となる新しいフレームについて、予測器４０４は、（候補の参照画素ブロックとしての）サンプルデータ、または、参照ピクチャの動きベクトル、ブロック形状など、新しいピクチャの適切な予測基準として機能し得る特定のメタデータを参照ピクチャメモリ４０５で検索することができる。予測器４０４は、適切な予測基準を見つけるために、サンプルブロック／画素ブロックごとに動作することができる。場合によっては、予測器４０４で取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ４０５に記憶された複数の参照ピクチャから引き出された予測基準を有してもよい。
[65]コントローラ４０２は、例えば、ビデオデータをエンコードするために使用されるパラメータおよびサブグループパラメータの設定を含む、ソースコーダ４０３のコーディング動作を管理することができる。
[66]前述のすべての機能ユニットの出力は、エントロピーコーダ４０８においてエントロピーコーディングを受けられる。エントロピーコーダは、例えば、ハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットによって生成されたシンボルをコード化されたビデオシーケンスに変換する。
[67]送信機４０９は、符号化されたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル４１１を介した送信の準備のために、エントロピーコーダ４０８によって作成されたコード化されたビデオシーケンスをバッファリングすることができる。送信機４０９は、ソースコーダ４０３からのコード化ビデオデータを、送信されるべき他のデータ、例えば、コード化オーディオデータおよび／または補助データストリーム（ソースは示されていない）とマージすることができる。
[68]コントローラ４０２は、エンコーダ４００の動作を管理してもよい。コーディング中、コントローラ４０５は、各コード化ピクチャに特定のコード化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング手法に影響を及ぼし得る。例えば、ピクチャは、多くの場合、次のフレームタイプのいずれかとして割り当てられ得る。
[69]イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内の他のいかなるフレームを使用せずにコード化および復号され得るものであり得る。一部のビデオコーデックは、例えば、インディペンデントデコーダリフレッシュピクチャ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ Ｐｉｃｔｕｒｅｓ）を含む、異なるタイプのイントラピクチャを許容する。当業者は、Ｉピクチャのこれらの変形およびそれらのそれぞれの用途および特徴を知っている。
[70]予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために最大１つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測によりコード化および復号され得るものであり得る。
[71]双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために最大２つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測によりコード化および復号され得るものであり得る。同様に、多重予測ピクチャは、単数のブロックの再構築のために２つを超えた参照ピクチャおよび関連メタデータを使用することができる。
[72]ソースピクチャは、一般に、複数のサンプルブロック（例えば、それぞれ、４×４、８×８、４×８、または１６×１６サンプルのブロック）に空間的に細分され、ブロック単位でコード化され得る。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定された他の（既にコード化された）ブロックを参照して予測的にコード化され得る。例えば、Ｉピクチャのブロックは、非予測的にコード化されてもよく、或いは、同一のピクチャの既にコード化されたブロックを参照して予測的にコード化されてもよい（空間予測またはイントラ予測）。Ｐピクチャの画素ブロックは、１つの予めコード化された参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的にコード化され得る。Ｂピクチャのブロックは、１つまたは２つの予めコード化された参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的にコード化され得る。
[73]ビデオコーダ４００は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの所定のビデオコーディング技術または規格に従って、コーディング動作を実行することができる。動作中、ビデオコーダ４００は、入力ビデオシーケンスの時間的および空間的冗長性を利用する予測コーディング動作を含む、様々な圧縮動作を実行することができる。したがって、コード化ビデオデータは、使用されるビデオコーディング技術または規格によって指定されたシンタックスに準拠する場合がある。
[74]一実施形態では、送信機４０９は、符号化されたビデオとともに追加のデータを送信することができる。ソースコーダ４０３は、このようなデータをコード化されたビデオシーケンスの一部として含み得る。追加のデータは、時間的／空間的／ＳＮＲエンハンスメントレイヤ、冗長なピクチャやスライスなどの他の形態での冗長データ、補助強化情報（ＳＥＩ）メッセージ、ビデオユーザビリティ情報（ＶＵＩ）パラメータセットフラグメントなどを含み得る。
[75]図５は、ＨＥＶＣとＪＥＭで使用されるイントラ予測モードを示している。自然なビデオに見られる任意のエッジ方向をキャプチャするために、方向性イントラモードの数をＨＥＶＣで使用される３３から６５に拡張している。ＨＥＶＣの上にあるＪＥＭの追加の方向性モードは図１（ｂ）では点線の矢印で示されており、平面（ｐｌａｎａｒ）およびＤＣモードは変わらない。これらのより高密度の方向性イントラ予測モードは、すべてのブロックサイズ、およびルマとクロマの両方のイントラ予測に適用される。図５に示されるように、奇数イントラ予測モードインデックスに関連付けられた、点線の矢印で識別される方向性イントラ予測モードは、奇数イントラ予測モードと呼ばれる。また、偶数イントラ予測モードインデックスに関連付けられた、実線の矢印で識別される方向性イントラ予測モードは、偶数イントラ予測モードと呼ばれる。本明細書では、図５の実線または点線の矢印で示されている方向性イントラ予測モードは、角度モードとも呼ばれる。
[76]ＪＥＭでは、ルマイントラ予測に合計６７通りのイントラ予測モードが使用されている。イントラモードをコード化するためには、隣接ブロックのイントラモードに基づいて、サイズ６の最確モード（Ｍｏｓｔ Ｐｒｏｂａｂｌｅ Ｍｏｄｅ、ＭＰＭ）リストが構築される。イントラモードがＭＰＭリストからのものではない場合、イントラモードが選択されたモードに属するか否かを示すフラグがシグナリングされる。ＪＥＭ－３．０では、第４の角度モードごとに一様に選択される、１６通りの選択されたモードがある。ＪＶＥＴ－Ｄ０１１４およびＪＶＥＴ－Ｇ００６０では、一様に選択されたモードを置き換えるために、１６通りの二次ＭＰＭｓが導出される。
[77]図６は、イントラ方向性モードに利用されるＮ個の参照階層を示している。ブロックユニット６１１、セグメントＡ ６０１、セグメントＢ ６０２、セグメントＣ ６０３、セグメントＤ ６０４、セグメントＥ ６０５、セグメントＦ ６０６、第１の参照階層６１０、第２の参照階層６０９、第３の参照階層６０８、および第４の参照階層６０７がある。
[78]ＨＥＶＣとＪＥＭの両方、およびＨ．２６４／ＡＶＣのような他の規格では、現在のブロックを予測するために使用される参照サンプルは、最も近い参照線（行または列）に制限されている。複数参照線イントラ予測の方法では、候補の参照線（行または列）の数は、イントラ方向性モードでは、１（すなわち最も近い）からＮまで増加し、ここで、Ｎは１以上の整数である。図２では、４×４予測ユニット（ＰＵ）を例として取り上げ、複数線イントラ方向性予測法の概念を示す。イントラ方向性モードでは、Ｎ個の参照階層のうちの１つを任意に選択して、予測子を生成することができる。言い換えれば、予測子ｐ（ｘ，ｙ）は、参照サンプルＳ１、Ｓ２、．．．、ＳＮのうちの１つから生成される。イントラ方向性モードに対してどの参照階層が選択されるかを示すようにフラグがシグナリングされる。Ｎを１とすると、イントラ方向性予測法は、ＪＥＭ２．０の従来の方法と同じである。図６では、参照線６１０、６０９、６０８、および６０７は、左上の参照サンプルとともに、６つのセグメント６０１、６０２、６０３、６０４、６０５、および６０６から構成される。本明細書では、参照階層は参照線とも呼ばれる。現在のブロックユニット内の左上の画素の座標は（０，０）であり、第１の参照線内の左上の画素の座標は（－１，－１）である。
[79]ＪＥＭでは、ルマ成分について、イントラ予測サンプルの生成に使用される隣接サンプルは、生成プロセスの前にフィルタリングされる。このフィルタリングは、与えられたイントラ予測モードおよび変換ブロックサイズによって制御される。イントラ予測モードがＤＣであるか、または変換ブロックサイズが４×４に等しい場合、隣接サンプルはフィルタリングされない。与えられたイントラ予測モードと垂直モード（または水平モード）との間の距離が、事前定義された閾値よりも大きい場合、フィルタリングプロセスが有効になる。隣接サンプルのフィルタリングには、［１，２，１］フィルタおよびバイリニアフィルタが使用される。
[80]位置依存イントラ予測組み合わせ（ＰＤＰＣ）法は、フィルタリングされていない境界参照サンプルと、フィルタリングされた境界参照サンプルを用いたＨＥＶＣスタイルのイントラ予測の組み合わせを呼び出すイントラ予測法である。（ｘ，ｙ）にある各予測サンプルｐｒｅｄ［ｘ］［ｙ］は、以下のように算出される。
Figure 0007378485000003
ただし、Ｒｘ，－１，Ｒ－１，ｙは、それぞれ現在のサンプル（ｘ，ｙ）の上と左にあるフィルタリングされていない参照サンプルを表し、Ｒ－１，－１は、現在のブロックの左上隅にあるフィルタリングされていない参照サンプルを表す。重み付けは以下のように算出される。
Figure 0007378485000004
[81]図７は、１つの４×４ブロック内の（０，０）および（１，０）の位置に対するＤＣモードＰＤＰＣ重み（ｗＬ，ｗＴ，ｗＴＬ）を示す図７００を示している。ＰＤＰＣがＤＣ、平面、水平、および垂直イントラモードに適用される場合、ＨＥＶＣ ＤＣモードの境界フィルタや水平／垂直モードのエッジフィルタのような追加の境界フィルタは必要ない。図７は、右上対角線モードに適用されるＰＤＰＣの参照サンプルＲｘ，－１、Ｒ－１，ｙ、およびＲ－１，－１の定義を示している。予測サンプルｐｒｅｄ（ｘ’，ｙ’）は、予測ブロック内の（ｘ’，ｙ’）にある。参照サンプルＲｘ，－１の座標ｘは、ｘ＝ｘ’＋ｙ’＋１で与えられ、参照サンプルＲ－１，ｙの座標ｙは、同様に、ｙ＝ｘ’＋ｙ’＋１で与えられる。
[82]図８は、局所照明補償（ＬＩＣ）のダイアグラム８００を示しており、スケーリング係数ａとオフセットｂを使用した、照明変化に対する線形モデルに基づいている。そして、各インターモードコード化されたコーディングユニット（ＣＵ）に対して適応的に有効化または無効化される。
[83]ＬＩＣがＣＵに適用される場合、現在のＣＵの隣接サンプルとそれらに対応する参照サンプルを用いてパラメータａおよびｂを導出するために、最小二乗誤差法が採用される。より具体的には、図８に示されるように、ＣＵのサブサンプリング（２：１サブサンプリング）された隣接サンプルおよび参照ピクチャ中の対応するサンプル（現在のＣＵまたはサブＣＵの動き情報によって特定される）が使用される。ＩＣパラメータが導出され、予測方向ごとに個別に適用される。
[84]ＣＵをマージモードでコード化する場合、マージモードでの動き情報のコピーと同様の方法で、ＬＩＣフラグを隣接ブロックからコピーする。それ以外の場合、ＬＩＣが適用されるか否かを示すようにＬＩＣフラグをＣＵのためにシグナリングする。
[85]図９Ａは、ＨＥＶＣで使用されるイントラ予測モード９００を示している。ＨＥＶＣでは、合計３５通りのイントラ予測モードがあり、そのうち、モード１０は水平モード、モード２６は垂直モード、モード２、モード１８、およびモード３４は対角線モードである。イントラ予測モードは、３通りの最確モード（ＭＰＭｓ）と３２通りの残りのモードによってシグナリングされる。
[86]図９Ｂに示されるように、ＶＶＣの実施形態において、合計８７通りのイントラ予測モードがあり、ここで、モード１８は水平モード、モード５０は垂直モード、モード２、モード３４、およびモード６６は対角線モードである。モード－１～－１０およびモード６７～７６は、広角イントラ予測（Ｗｉｄｅ－Ａｎｇｌｅ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ、ＷＡＩＰ）モードと呼ばれる。
[87]位置（ｘ，ｙ）にある予測サンプルｐｒｅｄ（ｘ，ｙ）は、次のＰＤＰＣ表現式に従って、イントラ予測モード（ＤＣ、平面、角度）および参照サンプルの線形結合を用いて予測される。
pred(x,y) = ( wL × R-1,y + wT × Rx,-1 - wTL × R-1,-1 + (64 - wL - wT + wTL) × pred(x,y) + 32 ) >> 6
ここで、Ｒｘ，－１、Ｒ－１，ｙは、それぞれ現在のサンプル（ｘ，ｙ）の上と左にある参照サンプルを表し、Ｒ－１，－１は、現在のブロックの左上隅にある参照サンプルを表す。
[88]ＤＣモードの場合、幅と高さの寸法を持つブロックに対して、重みは次のように算出される。
wT = 32 >> ( ( y<<1 ) >> nScale ), wL = 32 >> ( ( x<<1 ) >> nScale ), wTL = ( wL>>4 ) + ( wT>>4 )、
nScale = ( log2( width ) - 2 + log2( height ) - 2 + 2 ) >> 2とする。ここで、ｗＴは、同じ水平座標を持つ上方の参照線にある参照サンプルの重み付け係数を示し、ｗＬは、同じ垂直座標を持つ左の参照線にある参照サンプルの重み付け係数を示し、ｗＴＬは、現在のブロックの左上の参照サンプルの重み付け係数を示す。ｎＳｃａｌｅは、軸に沿って重み付け係数がどれくらいの速さで減少するか（ｗＬが左から右に減少するか、またはｗＴが上から下に減少する）、つまり重み付け係数の減少率を指定するもので、現在の設計ではＸ軸（左から右へ）とＹ軸（上から下へ）に沿って同じである。また、３２は隣接サンプルの初期重み付け係数を示し、初期重み付け係数は、現在のＣＢにおける左上のサンプルに割り当てられた上（左または左上）の重み付けでもあり、ＰＤＰＣプロセスにおける隣接サンプルの重み付け係数は、この初期重み付け係数に等しいか、それより小さいことが望ましい。
[89]平面モードの場合ｗＴＬ＝０、水平モードの場合ｗＴＬ＝ｗＴ、垂直モードの場合ｗＴＬ＝ｗＬとなる。ＰＤＰＣ重みは加算とシフトのみで算出されることができる。ｐｒｅｄ（ｘ，ｙ）の値は、式（１）を用いてワンステップで演算されることができる。
[90]ここで、提案された方法は、別々に使用されても、任意の順序で組み合わせられてもよい。さらに、方法（または実施形態）、エンコーダ、およびデコーダのそれぞれは、処理回路（例えば、１つまたは複数のプロセッサ、或いは１つまたは複数の集積回路）によって実施されてもよい。一例では、１つまたは複数のプロセッサは、非一時的なコンピュータ読取可能な媒体に記憶されているプログラムを実行する。以下では、ブロックという用語は、予測ブロック、コーディングブロック、またはコーディングユニット、すなわちＣＵとして解釈され得る。
[91]図１０Ａは、ＱＴＢＴを使用することによるブロックパーティションの例１０００を示しており、図１０Ｂは、対応するツリー表現１００１を示している。実線は四分木分割を示し、点線は二分木分割を示す。二分木の各分割（すなわち、非リーフ）ノードでは、どちらの分割タイプ（すなわち、水平または垂直）が使用されるかを示すように１つのフラグがシグナリングされ、ここで、０は水平分割を示し、１は垂直分割を示す。四分木分割の場合、四分木分割は常にブロックを水平と垂直の両方に分割し、同じサイズの４つのサブブロックを生成するため、分割タイプを示す必要はない。
[92]ＨＥＶＣでは、様々な局所特性に適応するように、コーディングツリーとして示される四分木構造を用いることでＣＴＵをＣＵｓに分割する。インターピクチャ（時間的）予測またはイントラピクチャ（空間的）予測を使用してピクチャ領域をコード化するか否かの決定は、ＣＵレベルで行われる。各ＣＵは、ＰＵ分割タイプに応じて、さらに１つ、２つ、または４つのＰＵｓに分割されることができる。１つのＰＵ内で、同じ予測プロセスが適用され、関連する情報がＰＵ単位でデコーダに送信される。ＰＵ分割タイプに基づいて予測プロセスを適用することで残余ブロックを取得した後、ＣＵのコーディングツリーのような別の四分木構造に従って、ＣＵを変換ユニット（ＴＵｓ）にパーティションすることができる。ＨＥＶＣ構造の重要な特徴の１つは、ＣＵ、ＰＵ、およびＴＵを含む複数のパーティション概念があることである。
[93]実施形態によれば、ＱＴＢＴ構造は、複数のパーティションタイプの概念をなくし、すなわち、ＣＵ、ＰＵ、およびＴＵ概念の分離をなくし、ＣＵのパーティション形状のより高い柔軟性をサポートする。ＱＴＢＴブロック構造では、ＣＵは、正方形または長方形のいずれかの形状を有することができる。図１１の流れ図１１００において、例示的な実施形態によれば、Ｓ１１で取得されたコーディングツリーユニット（ＣＴＵ）またはＣＵを、まずＳ１２において四分木構造によってパーティションする。さらに、Ｓ１４において、四分木リーフノードを二分木構造によってパーティションするか否かを決定し、そうであれば、Ｓ１５において、例えば図１０Ｃを用いて説明したように、二分木分割には、対称的な水平分割と対称的な垂直分割の２つの分割タイプがある。二分木リーフノードは、コーディングユニット（ＣＵｓ）と呼ばれ、そのセグメンテーションは、それ以上のパーティションをせずに、予測および変換処理に使用される。これは、ＱＴＢＴコーディングブロック構造では、ＣＵ、ＰＵ、およびＴＵが同じブロックサイズを持っていることを意味する。ＶＶＣでは、ＣＵは、異なる色成分のコーディングブロック（ＣＢｓ）から構成されることがあり、例えば、４：２：０クロマフォーマットのＰおよびＢスライスの場合、１つのＣＵが１つのルマＣＢと２つのクロマＣＢｓを含み、また、単一成分のＣＢから構成されることがあり、例えば、Ｉスライスの場合、１つのＣＵが１つのルマＣＢのみ、または２つのクロマＣＢｓのみを含む。
[94]実施形態によれば、ＱＴＢＴパーティションスキームには以下のパラメータが定義されている。
－ ＣＴＵサイズ：四分木のルートノードサイズで、ＨＥＶＣでのものと同じ概念である。
－ ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ、
－ ＭａｘＢＴＳｉｚｅ：最大許容二分木ルートノードサイズ、
－ ＭａｘＢＴＤｅｐｔｈ：最大許容二分木深度、
－ ＭｉｎＢＴＳｉｚｅ：最小許容二分木リーフノードサイズ。
[95]ＱＴＢＴパーティション構造の一例では、ＣＴＵサイズは、クロマサンプルの２つの対応する６４×６４ブロックを有する１２８×１２８ルマサンプルに設定され、ＭｉｎＱＴＳｉｚｅ（ＱＴはＱｕａｄ Ｔｒｅｅ）は１６×１６に設定され、ＭａｘＢＴＳｉｚｅは６４×６４に設定され、ＭｉｎＢＴＳｉｚｅ（幅と高さの両方）は４×４に設定され、ＭａｘＢＴＤｅｐｔｈは４に設定されている。四分木パーティションが、まずＣＴＵに適用され、Ｓ１２またはＳ１５において四分木リーフノードが生成される。四分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを持つことができる。リーフ四分木ノードが１２８×１２８である場合、Ｓ１４でチェックされたように、そのサイズがＭａｘＢＴＳｉｚｅ（すなわち、６４×６４）を超えているので、二分木によってさらに分割されることはない。それ以外の場合、Ｓ１５において、リーフ四分木ノードは、二分木によってさらにパーティションされる可能性がある。したがって、四分木リーフノードは、二分木のルートノードでもあり、その二分木深度が０である。二分木深度がＭａｘＢＴＤｅｐｔｈ（すなわち、４）に達すると、Ｓ１４ではそれ以上の分割は考慮されない。二分木ノードの幅がＭｉｎＢＴＳｉｚｅ（すなわち、４）に等しい場合、Ｓ１４ではそれ以上の水平分割は考慮されない。同様に、二分木ノードの高さがＭｉｎＢＴＳｉｚｅに等しい場合、Ｓ１４ではそれ以上の垂直分割は考慮されない。Ｓ１６での信号は、ＱＴ／ＴＴ／ＢＴサイズを記述するシンタックスに関して後述するように、Ｓ１７において、予測および変換処理によってさらに処理される二分木のリーフノードなどの行列のために提供され、そのような予測および変換処理に関して本明細書で議論されたのと同様なように、更なるパーティションは行われない。また、このようなシグナリングは、例示的な実施形態に従って、図１１に示されるように、Ｓ１２の後のＳ１３で提供されてもよい。ＪＥＭでは、最大ＣＴＵサイズは２５６×２５６ルマサンプルである。
[96]さらに、実施形態によれば、ＱＴＢＴスキームは、ルマおよびクロマが別々のＱＴＢＴ構造を有する能力／柔軟性をサポートする。現在、ＰおよびＢスライスの場合、１つのＣＴＵ内のルマおよびクロマコーディングツリーブロック（ＣＴＢｓ）は、同じＱＴＢＴ構造を共有している。しかし、Ｉスライスの場合、ルマＣＴＢはＱＴＢＴ構造によってＣＵｓにパーティションされ、クロマＣＴＢｓは別のＱＴＢＴ構造によってクロマＣＵｓにパーティションされる。これは、ＩスライスにおけるＣＵが、ルマ成分のコーディングブロックまたは２つのクロマ成分のコーディングブロックで構成され、ＰまたはＢスライスのＣＵが、３つの色成分すべてのコーディングブロックで構成されることを意味する。
[97]ＨＥＶＣでは、動き補償のメモリアクセスを低減するために、小ブロックのインター予測が制限されているため、４×８および８×４ブロックでは双予測がサポートされず、４×４ブロックではインター予測がサポートされていない。ＪＥＭ－７．０で実施されたＱＴＢＴでは、これらの制限が解除されている。
[98]図１０Ｃは、含まれるマルチタイプツリー（ＭＴＴ）構造１００２に関する簡略化されたブロック図１１００ ＶＶＣを示しており、この構造は、図示された四分木（ＱＴ）と、ネストされた二分木（ＢＴ）および三重／三分木（ＴＴ）との組み合わせであるＱＴ／ＢＴ／ＴＴである。ＣＴＵまたはＣＵは、まずＱＴによって正方形のブロックに再帰的にパーティションされる。次に、各ＱＴのリーフは、ＢＴまたはＴＴによってさらにパーティションされ、ここで、ＢＴおよびＴＴ分割は再帰的に適用され、インターリーブされることができるが、それ以上のＱＴパーティションは適用されることができない。関連するすべての提案において、ＴＴは、長方形のブロックを垂直または水平に１：２：１の割合で３つのブロックに分割する（したがって、２の累乗以外の幅と高さを回避する）。パーティションエミュレーション防止のために、ＭＴＴに典型的には追加の分割制約が課され、図１０Ｃの簡略図１００２に示されるように、ブロック１１０３（クワッド）、１１０４（バイナリー、ＪＥＭ）、および１１０５（ターナリー）に対する、ＶＶＣにおけるＱＴ／ＢＴ／ＴＴブロックパーティションがあり、重複したパーティションを回避する（例えば、垂直／水平のターナリー分割の結果得られる中央のパーティションでの垂直／水平のバイナリー分割を禁止する）。ＢＴおよびＴＴの最大深度に更なる制限が設けられることがある。
[99]ここで、例示的な実施形態に従ってＱＴ／ＴＴ／ＢＴサイズを記述するための新しいシンタックスが設計されている。これらのシンタックスは、基数（ｂａｓｅ）をｍｉｎ ＣＢ／ＱＴからＣＴＵに変更する。提案された方法では、例示的な実施形態に従って、ＱＴ／ＴＴ／ＢＴサイズをより小さな数値を用いてシグナリングすることが可能となり、したがって、ビット効率などのコーディング効率の向上を達成することができる。
[100]例示的な実施形態によれば、例示的な実施形態によるＳ１６で述べたように、ＱＴ／ＴＴ／ＢＴサイズを記述するシンタックスが変更され、本開示において、ＡとＢとの間のデルタ値をシグナリングすると言う場合、ＡとＢとの間のデルタ値の基数２の対数をシグナリングすることも意味し得ることが理解されるであろう。また、本開示において、Ａの絶対値をシグナリングすると言う場合、Ａの絶対値の基数２の対数をシグナリングすることも意味し得る。
[101]例示的な実施形態によれば、シグナリングは、ＱＴ／ＴＴ／ＢＴサイズとＣＴＵサイズとの間のデルタ値をシグナリングすることを含んでもよい。
[102]例示的な実施形態によれば、シグナリングは、デルタシグナリングを行わずに、ＱＴ／ＴＴ／ＢＴの絶対値を明示的にシグナリングすることを含んでもよい。
[103]例示的な実施形態によれば、シグナリングは、ＱＴ／ＴＴ／ＢＴサイズとｍｉｎ ＣＢサイズとの間のデルタ値をシグナリングすることを含んでもよい。
[104]例示的な実施形態によれば、シグナリングは、ＱＴ／ＴＴ／ＢＴサイズとｍｉｎ ＱＴサイズとの間のデルタ値をシグナリングすることを含んでもよい。
[105]例示的な実施形態によれば、シグナリングは、ＱＴ／ＴＴ／ＢＴサイズと任意の事前定義された値との間のデルタ値をシグナリングすることを含んでもよい。
[106]例示的な実施形態によれば、シグナリングは、ＱＴ／ＴＴ／ＢＴサイズと、任意のパラメータセット（デコードパラメータセット（ＤＰＳ）、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）および／または適応パラメータセット（ＡＰＳ））でシグナリングされる任意の値との間のデルタ値をシグナリングすることを含んでもよい。
[107]例示的な実施形態によれば、ＳＰＳおよびスライスヘッダに関する修正されたＶＶＣ Ｄｒａｆｔ ６を以下に示し、変更点は太字で強調され、取り消し線は削除されたテキストを示す。
Figure 0007378485000005
Figure 0007378485000006
[108]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａは、ＳＰＳを参照した、ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しいスライス内のルマＣＵｓのルマサンプルにおける最小コーディングブロックサイズの基数２の対数を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数は、以下のように導出される。
MinQtLog2SizeIntraY = log2_ctu_size_minus5 + 5 - sps_log2_diff_ctu_min_qt_intra_slice_luma - 式（７－２４）
[109]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅは、四分木分割およびＳＰＳへの参照の結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数は、以下のように導出される。
MinQtLog2SizeInterY = log2_ctu_size_minus5 + 5 - sps_log2_diff_ctu_min_qt_inter_slice - 式（７－２５）
[110]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａは、ＳＰＳを参照した、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しいスライス内のＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｒａＹ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの値は０に等しいと推測される。
[111]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａは、ＳＰＳを参照した、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しいスライス内のＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｒａＹ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａの値は０に等しいと推測される。
[112]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅは、ＳＰＳを参照した、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが０（Ｂ）または１（Ｐ）に等しいスライス内のＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｅｒＹ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅの値は０に等しいと推測される。
[113]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅは、ＳＰＳを参照した、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（およびｓｌｉｃｅ＿ｔｙｐｅが０（Ｂ）または１（Ｐ）に等しいスライス内のＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ））と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｅｒＹ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅの値は０に等しいと推測される。
[114]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａは、ＳＰＳを参照した、バイナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しいスライスにおける、ｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＴＵを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｃｈｒｏｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｒａＣ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａの値は０に等しいと推測される。
[115]例示的な実施形態によれば、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａは、ＳＰＳを参照した、ターナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しいスライスにおける、ｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＴＵを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間のデフォルトの差分を指定する。ｐａｒｔｉｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｏｖｅｒｒｉｄｅ＿ｆｌａｇが１に等しい場合、デフォルトの差分は、ＳＰＳを参照したスライスのスライスヘッダに存在するｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｃｈｒｏｍａによって上書きされることができる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＩｎｔｒａＣ以下の範囲とされる。ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａが存在しない場合、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａの値は０に等しいと推測される。
[116]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａは、現在のスライスにおける、ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数２の対数（ルマＣＵｓのルマサンプルにおける最小コーディングブロックサイズの基数２の対数を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａの値は以下のように推測される。
－ ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しい場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａに等しいと推測される。
－ それ以外の場合（ｓｌｉｃｅ＿ｔｙｐｅが０（Ｂ）または１（Ｐ）に等しい）、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅに等しいと推測される。
[117]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａは、現在のスライスにおける、ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）、および、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａの値は、以下のように推測される。
－ ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しい場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａに等しいと推測される。
－ それ以外の場合（ｓｌｉｃｅ＿ｔｙｐｅが０（Ｂ）または１（Ｐ）に等しい）、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅに等しいと推測される。
[118]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａは、現在のスライスにおける、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ＣＴＵを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａの値は、以下のように推測される。
－ ｓｌｉｃｅ＿ｔｙｐｅが２（Ｉ）に等しい場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｌｕｍａに等しいと推測される。
－ それ以外の場合（ｓｌｉｃｅ＿ｔｙｐｅが０（Ｂ）または１（Ｐ）に等しい）、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｌｕｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｅｒ＿ｓｌｉｃｅに等しいと推測される。
[119]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｃｈｒｏｍａは、現在のスライスにおける、ｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＴＵを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズの基数２の対数（ｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＵｓのルマサンプルにおける最小コーディングブロックサイズの基数２の対数を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｃｈｒｏｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＣｂＬｏｇ２ＳｉｚｅＹ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｃｈｒｏｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍｉｎ＿ｑｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａに等しいと推測される。
[120]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｃｈｒｏｍａは、現在のスライスにおける、バイナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）の基数２の対数（ｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＴＵを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ）を伴うかまたは伴わない）と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｃｈｒｏｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＣ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｃｈｒｏｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｂｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａに等しいと推測される。
[121]例示的な実施形態によれば、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｃｈｒｏｍａは、現在のスライスにおける、ターナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ（幅または高さ）（およびｔｒｅｅＴｙｐｅがＤＵＡＬ＿ＴＲＥＥ＿ＣＨＲＯＭＡに等しいクロマＣＴＵを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ（幅または高さ））の基数２の対数と、ｃｔｕサイズの基数２の対数との間の差分を指定する。ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｃｈｒｏｍａの値は、０以上ＣｔｂＬｏｇ２ＳｉｚｅＹ － ＭｉｎＱｔＬｏｇ２ＳｉｚｅＣ以下の範囲とされる。存在しない場合、ｓｌｉｃｅ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｃｈｒｏｍａの値は、ｓｐｓ＿ｌｏｇ２＿ｄｉｆｆ＿ｃｔｕ＿ｍａｘ＿ｔｔ＿ｉｎｔｒａ＿ｓｌｉｃｅ＿ｃｈｒｏｍａに等しいと推測される。
[122]本明細書に記載されているように、例示的な実施形態に従って本明細書に記載されている値の間の所定のデルタ値（差）を決定または記憶するように構成される、バッファ、算術論理ユニット、メモリ命令のような１つまたは複数のハードウェアプロセッサおよびコンピュータコンポーネントが存在してもよい。
[123]したがって、本明細書に記載された例示的な実施形態により、上述した技術的課題は、これらの技術的な解決策の１つまたは複数によって有利に改善され得る。つまり、実施形態によれば、１つまたは複数の異なる技術的課題に対処するために、本開示では、ＱＴ／ＴＴ／ＢＴサイズを記述するように設計された新しいシンタックスおよびその使用について説明した。実施形態によれば、これらのシンタックスは、基数をｍｉｎ ＣＢ／ＱＴからＣＴＵに変更しており、実施形態では、ＱＴ／ＴＴ／ＢＴサイズをより小さな数値を用いてシグナリングすることが可能となる。したがって、コーディング効率の向上を図ることができる。
[124]以上で説明された手法は、コンピュータ読取可能な命令を使用するコンピュータソフトウェアとして実施されることができ、１つまたは複数のコンピュータ読取可能な媒体に物理的に記憶されるか、または特別に構成された１つまたは複数のハードウェアプロセッサによって記憶されることができる。例えば、図１２は、開示された主題の特定の実施形態を実施することに適したコンピュータシステム１２００を示す。
[125]コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、またはそのようなメカニズムを施されて、コンピュータ中央処理装置（ＣＰＵｓ）、グラフィックスプロセッシングユニット（ＧＰＵｓ）などによって直接、または解釈、マイクロコード実行などによって実行されることができる命令を含むコードを作成する任意の適切な機械コードまたはコンピュータ言語を用いてコード化されることができる。
[126]命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはそのコンポーネント上で実行されることができる。
[127]コンピュータシステム１２００について、図１２に示される例示的なコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関していかなる限定を示唆することも意図しない。コンポーネントの構成は、コンピュータシステム１２００の例示的な実施形態で示されるコンポーネントのうちのいずれか１つ又は組み合わせに関する任意の依存性又は必要性を有するとして解釈されるべきではない。
[128]コンピュータシステム１２００は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（音声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（図示せず）によって、１人以上のユーザによる入力に応答することができる。ヒューマンインターフェースデバイスは、オーディオ（音声、音楽、環境音など）、画像（走査画像、静止画像カメラから取得される写真画像など）、ビデオ（２次元ビデオ、立体ビデオを含む３次元ビデオなど）など、人間による意識的な入力に必ずしも直接関係しない特定のメディアをキャプチャすることにも使用できる。
[129]入力ヒューマンインターフェースデバイスは、キーボード１２０１、マウス１２０２、トラックパッド１２０３、タッチスクリーン１２１０、ジョイスティック１２０５、マイクフォン１２０６、スキャナ１２０８、カメラ１２０７（それぞれ１つのみ示されている）のうちの１つまたは複数を含み得る。
[130]コンピュータシステム１２００は、特定のヒューマンインターフェース出力デバイスをも含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音声、光、および嗅覚／味覚を介して１人以上のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン１２１０、またはジョイスティック１２０５による触覚フィードバックがあるが、入力デバイスとして機能しない触覚フィードバックデバイスであってもよい）、オーディオ出力デバイス（スピーカ１２０９、ヘッドホン（図示せず）など）、視覚出力デバイス（ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン１２１０（それぞれタッチスクリーン入力能力を有するかもしくは有せず、それぞれ触覚フィードバック能力を有するかもしくは有しない。それらの一部は、ステレオグラフィック出力などの手段を介して、２次元の視覚出力または３次元以上の出力を出力することができる）、仮想現実眼鏡（図示せず）、ホログラフィックディスプレおよびスモークタンク（図示せず）など）、およびプリンタ（図示せず）を含み得る。
[131]コンピュータシステム１２００は、人間がアクセス可能な記憶装置およびそれらの関連する媒体、例えば、ＣＤ／ＤＶＤ１２１１などの媒体付きのＣＤ／ＤＶＤ ＲＯＭ／ＲＷ１２２０を含む光学媒体、サムドライブ１２２２、リムーバブルハードドライブまたはソリッドステートドライブ１２２３、テープやフロッピーディスクなどの従来の磁気媒体（図示せず）、セキュリティドングルなどの専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイス（図示せず）などをも含むことができる。
[132]ここで開示された主題に関連して使用される「コンピュータ読取可能な媒体」という用語は、送信媒体、搬送波、または他の一時的な信号を包含しないことをも当業者が理解するべきである。
[133]コンピュータシステム１２００は、１つまたは複数の通信ネットワーク１２９８へのインターフェース１２９９をさらに含むことができる。ネットワーク１２９８は、例えば、無線、有線、光学的であり得る。ネットワーク１２９８は、さらに、ローカル、広域、大都市圏、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワーク１２９８の例は、イーサネット、無線ＬＡＮｓなどのローカルエリアネットワーク、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、および地上放送ＴＶを含むＴＶ有線または無線広域デジタルネットワーク、ＣＡＮＢｕｓを含む車両用や産業用などを含む。特定のネットワーク１２９８は、一般に、特定の汎用データポートまたは周辺バス（１２５０および１２５１）（例えば、コンピューターシステム１２００のＵＳＢポートなど）に接続された外部ネットワークインターフェースアダプターを必要とする。他のものは一般に、以下に説明するようにシステムバスに接続することにより、コンピューターシステム１２００のコアに統合される（例えば、ＰＣコンピューターシステムへのイーサネットインターフェースまたはスマートフォンコンピューターシステムへのセルラーネットワークインターフェース）。これらのネットワーク１２９８のいずれかを用いて、コンピュータシステム１２００は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ（例えば、放送ＴＶ）、単方向の送信のみ（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、または双方向、例えばローカルまたはワイドエリアデジタルネットワークを用いる他のコンピュータシステムへの送信であり得る。特定のプロトコルおよびプロトコルスタックを上述したこれらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。
[134]前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム１２００のコア１２４０に接続されることができる。
[135]コア１２４０は、１つまたは複数の中央処理装置（ＣＰＵ）１２４１、グラフィックスプロセッシングユニット（ＧＰＵ）１２４２、グラフィックスアダプタ１２１７、フィールドプログラマブルゲートエリア（ＦＰＧＡ）１２４３の形態での専用プログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ１２４４などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）１２４５、ランダムアクセスメモリ１２４６、非ユーザアクセス可能な内部ハードドライブ、ＳＳＤｓなどの内部大容量記憶装置１２４７とともに、システムバス１２４８を介して接続されてもよい。一部のコンピュータシステムでは、システムバス１２４８は、１つまたは複数の物理プラグの形態でアクセスでき、追加のＣＰＵｓ、ＧＰＵなどによる拡張を可能にする。周辺機器は、コアのシステムバス１２４８に直接、または周辺バス１２５１を介して接続されることができる。周辺バスのアーキテクチャは、ＰＣＩ、ＵＳＢなどを含む。
[136]ＣＰＵｓ １２４１、ＧＰＵｓ １２４２、ＦＰＧＡｓ １２４３、およびアクセラレータ１２４４は、組み合わせて、前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ＲＯＭ １２４５またはＲＡＭ １２４６に記憶されることができる。推移データはＲＡＭ １２４６にも記憶できるが、永続データは、例えば、内部大容量ストレージ１２４７に記憶されることができる。１つまたは複数のＣＰＵ １２４１、ＧＰＵ １２４２、大容量ストレージ１２４７、ＲＯＭ １２４５、ＲＡＭ １２４６などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリデバイスへの高速保存および検索が可能になる。
[137]コンピュータ読取可能な媒体は、様々なコンピュータ実施操作を実行するためのコンピュータコードを備えることができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、もしくは、それらは、コンピュータソフトウェア技術の当業者に周知であって利用可能な種類のものであり得る。
[138]限定ではなく、一例として、アーキテクチャを有するコンピュータシステム１２００、特にコア１２４０は、１つまたは複数の有形のコンピュータ読取可能な媒体に組み込まれたソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）の結果としての機能性を提供することができる。このようなコンピュータ読取可能な媒体は、以上で説明したようにユーザがアクセス可能な大容量ストレージ、および、コア内部大容量ストレージ１２４７またはＲＯＭ １２４５などの非一時的な性質を持つコア１２４０の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実行するソフトウェアは、このようなデバイスに記憶され、コア１２４０によって実行されることができる。コンピュータ読取可能な媒体は、特定の必要に応じて、１つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア１２４０、具体的にはその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ １２４６に記憶されたデータ構造を定義すること、および、ソフトウェアで定義されたプロセスに従ってこのようなデータ構造を変更する言を含む、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または、代替として、コンピュータシステムは、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりにまたは一緒に動作することができる回路（例えば、アクセラレータ１２４４）に有線接続されたまたは組み込まれたロジックの結果としての機能性を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを含むことができ、その逆も同様である。コンピュータ読取可能な媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（ＩＣ）など）、実行のためのロジックを具現化する回路、またはその両方を含むことができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを含む。
[139]本開示は一部の例示的な実施形態を説明してきたが、本開示の範囲内に含まれる変更、置換、および様々な代替の均等物が存在する。したがって、当業者は、本明細書では明示的に示されていないか、または記載されていないが、本開示の原理を具現化し、その思想および範囲内に含まれる様々なシステムおよび方法を考案できることが理解されよう。
１００ 通信システム
１０１，１０２，１０３，１０４ 端末
１０５ ネットワーク

Claims (4)

  1. 少なくとも１つのプロセッサが実行するビデオコーディング方法であって、
    ビデオデータからコーディングツリーユニット（ＣＴＵ）を取得するステップと、
    前記ＣＴＵを四分木構造によってパーティションするステップと、
    前記パーティションされたＣＴＵのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションするステップと、
    前記ＣＴＵを前記四分木構造によってパーティションすることと、前記パーティションされたＣＴＵのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズの基数２の対数と、少なくとも１つの値の基数２の対数との間の差分をシグナリングするステップと、を含むビデオコーディング方法であって、
    前記少なくとも１つの値は、前記ＣＴＵのサイズを含み、
    前記サンプルの前記サイズは、前記ＣＴＵを前記四分木構造によってパーティションした結果得られるルマリーフブロックのルマサンプルにおける最小サイズである、
    ビデオコーディング方法。
  2. 少なくとも１つのプロセッサが実行するビデオコーディング方法であって、
    ビデオデータからコーディングツリーユニット（ＣＴＵ）を取得するステップと、
    前記ＣＴＵを四分木構造によってパーティションするステップと、
    前記パーティションされたＣＴＵのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションするステップと、
    前記ＣＴＵを前記四分木構造によってパーティションすることと、前記パーティションされたＣＴＵのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズの基数２の対数と、少なくとも１つの値の基数２の対数との間の差分をシグナリングするステップと、を含むビデオコーディング方法であって、
    前記少なくとも１つの値は、前記ＣＴＵのサイズを含み、
    前記サンプルの前記サイズは、前記ＣＴＵを前記四分木構造によってパーティションした結果得られるクロマリーフブロックの最小サイズである、
    ビデオコーディング方法。
  3. コンピュータプログラムコードを記憶するように構成される少なくとも１つのメモリと、
    前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令された通りに動作するように構成される少なくとも１つのプロセッサと、を備えるビデオコーディング装置であって、
    前記コンピュータプログラムコードは、
    前記少なくとも１つのプロセッサに、請求項１または２に記載のビデオコーディング方法を実行させるように構成されるビデオコーディング装置。
  4. コンピュータに、請求項１または２に記載のビデオコーディング方法を実行させるように構成されるプログラム。
JP2021548146A 2019-08-27 2020-08-26 Ｑｔ／ｂｔ／ｔｔサイズの改善されたヘッダシンタックス Active JP7378485B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962892246P 2019-08-27 2019-08-27
US62/892,246 2019-08-27
US16/999,657 US11496774B2 (en) 2019-08-27 2020-08-21 Header syntax for QT/BT/TT size
US16/999,657 2020-08-21
PCT/US2020/047960 WO2021041516A1 (en) 2019-08-27 2020-08-26 Improved header syntax for qt/bt/tt size

Publications (2)

Publication Number Publication Date
JP2022520855A JP2022520855A (ja) 2022-04-01
JP7378485B2 true JP7378485B2 (ja) 2023-11-13

Family

ID=74682480

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021548146A Active JP7378485B2 (ja) 2019-08-27 2020-08-26 Ｑｔ／ｂｔ／ｔｔサイズの改善されたヘッダシンタックス

Country Status (5)

Country Link
US (1) US11496774B2 (ja)
EP (1) EP4022891A4 (ja)
JP (1) JP7378485B2 (ja)
CN (1) CN113841393B (ja)
WO (1) WO2021041516A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023197998A1 (en) * 2022-04-13 2023-10-19 Mediatek Inc. Extended block partition types for video coding

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020057572A1 (en) 2018-09-18 2020-03-26 Huawei Technologies Co., Ltd. A video encoder, a video decoder and corresponding methods

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3662171B2 (ja) 2000-06-05 2005-06-22 三菱電機株式会社 符号化装置及び符号化方法
KR101484280B1 (ko) 2009-12-08 2015-01-20 삼성전자주식회사 임의적인 파티션을 이용한 움직임 예측에 따른 비디오 부호화 방법 및 장치, 임의적인 파티션을 이용한 움직임 보상에 따른 비디오 복호화 방법 및 장치
US9848197B2 (en) 2011-03-10 2017-12-19 Qualcomm Incorporated Transforms in video coding
US9497473B2 (en) 2013-10-03 2016-11-15 Qualcomm Incorporated High precision explicit weighted prediction for video coding
WO2017205700A1 (en) 2016-05-25 2017-11-30 Arris Enterprises Llc Binary, ternary and quad tree partitioning for jvet coding of video data
WO2017219342A1 (en) * 2016-06-24 2017-12-28 Mediatek Inc. Methods of signaling quantization parameter for quad-tree plus binary tree structure
CN117201820A (zh) * 2017-05-26 2023-12-08 Sk电信有限公司 对视频数据进行编码或解码的方法和发送比特流的方法
KR102435881B1 (ko) * 2017-05-26 2022-08-24 에스케이텔레콤 주식회사 영상 부호화 또는 복호화하기 위한 장치 및 방법
CN115442606A (zh) * 2017-07-31 2022-12-06 韩国电子通信研究院 对图像编码和解码的方法及存储比特流的计算机可读介质
CN117499684A (zh) * 2017-09-20 2024-02-02 韩国电子通信研究院 用于对图像进行编码/解码的方法和装置
CN111247799B (zh) * 2017-10-18 2022-08-09 韩国电子通信研究院 图像编码/解码方法和装置以及存储有比特流的记录介质
US10972758B2 (en) * 2018-04-02 2021-04-06 Qualcomm Incorporated Multi-type-tree framework for transform in video coding
US10887594B2 (en) * 2018-07-05 2021-01-05 Mediatek Inc. Entropy coding of coding units in image and video data
CN110719481B (zh) * 2018-07-15 2023-04-14 北京字节跳动网络技术有限公司 跨分量编码信息导出
CN112640470A (zh) * 2018-09-03 2021-04-09 华为技术有限公司 视频编码器、视频解码器及对应方法
JP7286757B2 (ja) * 2018-09-03 2023-06-05 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 分割制約要素間の関係
CN112703742B (zh) * 2018-09-14 2023-03-31 华为技术有限公司 视频译码中的分块指示
EP3837836A4 (en) * 2018-09-18 2021-06-23 Huawei Technologies Co., Ltd. DIVISION WITH HIGH-LEVEL CONSTRAINT
CN113273197A (zh) * 2019-02-03 2021-08-17 北京字节跳动网络技术有限公司 视频块分割模式的信令通知

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020057572A1 (en) 2018-09-18 2020-03-26 Huawei Technologies Co., Ltd. A video encoder, a video decoder and corresponding methods

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BROSS, Benjamin et al.，Versatile Video Coding (Draft 2)，JVET-K1001 (version 4)，ITU，2019年08月17日，pp.25, 37
BROSS, Benjamin et al.，Versatile Video Coding (Draft 6)，JVET-O2001 (version 14)，ITU，2019年07月31日，pp.37-40, 50-54, 57-58, 60-62, 125

Also Published As

Publication number Publication date
EP4022891A1 (en) 2022-07-06
JP2022520855A (ja) 2022-04-01
CN113841393A (zh) 2021-12-24
US20210067809A1 (en) 2021-03-04
EP4022891A4 (en) 2022-11-16
US11496774B2 (en) 2022-11-08
WO2021041516A1 (en) 2021-03-04
CN113841393B (zh) 2024-04-02

Similar Documents

Publication Publication Date Title
WO2020102185A1 (en) Constrained intra prediction and unified most probable mode list generation
JP7319438B2 (ja) イントラインター予測モードを改善するための方法及び装置、並びにコンピュータプログラム
JP7436482B2 (ja) 最大変換サイズの制御
KR102437516B1 (ko) 유연한 트리 구조
JP2022511865A (ja) ビデオ符号化又は復号の方法及び装置並びにコンピュータプログラム
JP2024016276A (ja) ビデオエンコーディング及びデコーディングのための方法、装置、コンピュータプログラム、及び非一時的なコンピュータ可読媒体
KR102506416B1 (ko) 다중 라인 인트라 예측을 위한 인트라 보간 필터
KR20210074385A (ko) 일반화된 트라이수프 기하 코딩을 위한 기법 및 장치
JP7271675B2 (ja) ビデオ復号の方法および装置、並びにプログラム
JP2021520150A (ja) 予測モードおよび符号化ブロックフラグ（ｃｂｆ）のコンテキスト設計を更に向上する方法および機器
JP2022515850A (ja) 統合位置依存予測組み合わせプロセスを使用するデコードのための方法、装置およびコンピュータ・プログラム
JP7357679B2 (ja) 改善された最確モードリスト生成方法
KR102456831B1 (ko) 유연한 트리 구조에서의 연접된 코딩 단위들
JP7378485B2 (ja) Ｑｔ／ｂｔ／ｔｔサイズの改善されたヘッダシンタックス
KR20230088855A (ko) 멀티-라인 인트라 예측을 위한 모드 리스트 생성
JP7391198B2 (ja) Ｌ字型パーティション分割ツリーを用いたイントラコーディング
JP2023549185A (ja) ビデオ復号のための方法、装置及びコンピュータプログラム
KR20230054889A (ko) 크로스 컴포넌트 블록 끝 플래그 코딩
KR20220122767A (ko) 비디오 코딩을 위한 방법 및 장치
JP7495564B2 (ja) イントラインター予測モードを改善するための方法及び装置、並びにコンピュータプログラム
JP7266710B2 (ja) ビデオコーディングのための方法、装置、およびコンピュータプログラム
JP7439344B2 (ja) ビデオデコーディングのための方法、デバイス、およびコンピュータプログラム
RU2812762C1 (ru) Сигнализация, связанная с адаптивным преобразованием цвета, для уровня cu и уровня tu
KR20210138083A (ko) 플렉시블 픽처 파티셔닝
JP2023543586A (ja) スキップ変換フラグ符号化

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210817

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210817

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220829

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230320

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230620

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231010

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231031

R150 Certificate of patent or registration of utility model

Ref document number: 7378485

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150