特表 2023-552821 ビデオ復号化の方法、装置、及びプログラム、並びにビデオ符号化の方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-12-19

(54)【発明の名称】ビデオ復号化の方法、装置、及びプログラム、並びにビデオ符号化の方法

(51)【国際特許分類】

   H04N 19/70 20140101AFI20231212BHJP

   H04N 19/91 20140101ALI20231212BHJP

【ＦＩ】

H04N19/70

H04N19/91

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023534916

(86)(22)【出願日】2022-04-29

(85)【翻訳文提出日】2023-06-08

(86)【国際出願番号】 US2022072018

(87)【国際公開番号】W WO2023056108

(87)【国際公開日】2023-04-06

(31)【優先権主張番号】63/250,180

(32)【優先日】2021-09-29

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/710,794

(32)【優先日】2022-03-31

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】チョイ，ビヨンドゥ

(72)【発明者】

【氏名】リウ，シャン

(72)【発明者】

【氏名】ウェンジャー，ステファン

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159MA04

5C159MA05

5C159MA21

5C159MC11

5C159ME01

5C159ME17

5C159PP05

5C159PP06

5C159PP07

5C159PP16

5C159UA02

5C159UA05

5C159UA16

5C159UA33

(57)【要約】

開示の態様は、ビデオデータ処理のための方法及び装置を提供する。いくつかの例で、ビデオデータ処理のための装置は処理回路を含む。例えば、処理回路は、ビットストリーム内のコーディングされたビデオデータの第１範囲でのコーディング制御のための第１シンタックス要素を決定する。第１シンタックス要素は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールに関連する。コーディングツールが、変換スキップモードでの残差コーディングのためのスライスレベルでのＲｉｃｅパラメータを提供する。第１シンタックス要素が第１範囲でのコーディングツールの無効化を示す第１値であることに応答して、処理回路は、コーディングツールを呼び出さずに、コーディングされたビデオデータの１つ以上の第２範囲を含むコーディングされたビデオデータの第１範囲を復号する。

【特許請求の範囲】

【請求項1】

デコーダが実行するビデオ復号化の方法であって、
プロセッサによって、ビットストリーム内のコーディングされたビデオデータの第１範囲でのコーディング制御のための第１シンタックス要素を決定するステップであって、前記第１シンタックス要素は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールに関連し、前記コーディングツールは、前記変換スキップモードでの前記残差コーディングのためのスライスレベルでのＲｉｃｅパラメータを提供する、前記決定するステップと、
前記第１シンタックス要素が前記第１範囲での前記コーディングツールの無効化を示す第１値であることに応答して、前記プロセッサによって、前記コーディングツールを呼び出さずに、コーディングされたビデオデータの１つ以上の第２範囲を含むコーディングされたビデオデータの前記第１範囲を復号するステップと
を有する方法。

【請求項2】

前記第１シンタックス要素は、前記デコーダのための出力レイヤセット内のピクチャのコーディング制御のための一般制約情報においてｇｅｎｅｒａｌ＿ｎｏ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇによって表される、
請求項１に記載の方法。

【請求項3】

前記第１シンタックス要素の前記第１値は、前記出力レイヤセット内の各コーディングレイヤビデオシーケンス（ＣＬＶＳ）で前記コーディングツールを無効化することを示す、
請求項２に記載の方法。

【請求項4】

前記第１シンタックス要素が前記第１値であることに応答して、前記ビットストリーム内のコーディングレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２シンタックス要素を、当該ＣＬＶＳを復号するために前記コーディングツールを呼び出さないことを示す値を有するように制約するステップを更に有する、
請求項２に記載の方法。

【請求項5】

前記第２シンタックス要素の前記値は、前記ＣＬＶＳのピクチャ内のスライスのスライスヘッダでの前記コーディングツールに関連したスライスヘッダフラグの不存在を示す、
請求項４に記載の方法。

【請求項6】

前記第１シンタックス要素が第２値であり、前記変換スキップモードがコーディングレイヤビデオシーケンス（ＣＬＶＳ）で有効にされることに応答して、前記ＣＬＶＳが参照するシーケンスパラメータセット（ＳＰＳ）内の第２シンタックス要素の値を決定するステップを更に有し、
前記第２シンタックス要素は、Ｒｉｃｅパラメータの選択を示すスライスレベルシンタックス要素の存在／不存在を示す、
請求項２に記載の方法。

【請求項7】

前記第２シンタックス要素の前記値が前記スライスレベルシンタックス要素の存在を示すことに応答して、スライスのスライスヘッダから第３シンタックス要素を復号するステップを更に有し、
前記第３シンタックス要素は、前記変換スキップモードでの前記スライスの前記残差コーディングのためのＲｉｃｅパラメータの選択を示す、
請求項６に記載の方法。

【請求項8】

前記第２シンタックス要素の前記値を決定するステップは、
前記第２シンタックス要素が前記ＣＬＶＳの前記ＳＰＳに存在しないことに応答して、前記ＣＬＶＳでの前記コーディングツールの不使用を示す前記第２シンタックス要素の前記値を推測するステップを更に有する、
請求項６に記載の方法。

【請求項9】

前記第１シンタックス要素を決定するステップは、
一般制約情報のためのシンタックス構造内のシンタックス要素が前記シンタックス構造内の一般制約情報のための追加ビットを示すことに応答して、前記シンタックス構造から前記第１シンタックス要素を復号するステップを更に有する、
請求項１に記載の方法。

【請求項10】

ビデオ復号化のための装置であって、
プログラムコードを記憶するよう構成される少なくとも１つのメモリと、
前記プログラムコードを読み出し、該プログラムコードによって指示されるように動作するよう構成される少なくとも１つのプロセッサと
を有し、
前記プログラムコードは、前記少なくとも１つのプロセッサによって実行される場合に、前記少なくとも１つのプロセッサに、請求項１乃至９のうちいずれか一項に記載の方法を実行させる、装置。

【請求項11】

少なくとも１つのプロセッサによって実行される場合に、該少なくとも１つのプロセッサに、請求項１乃至９のうちいずれか一項に記載の方法を実行させるプログラム。

【請求項12】

エンコーダが実行するビデオ符号化の方法であって、
プロセッサによって、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールが、ビットストリーム内のコーディングされたビデオデータの第１範囲の符号化中に使用されるかどうかを決定するステップであって、前記コーディングされたビデオデータの前記第１範囲は、前記コーディングされたビデオデータの１つ以上の第２範囲を含み、前記コーディングツールは、前記変換スキップモードでの前記残差コーディングのためのスライスレベルでのＲｉｃｅパラメータを提供する、前記決定するステップと、
前記コーディングツールが前記コーディングされたビデオデータの前記第１範囲で使用されない場合に、第１値を有する第１シンタックス要素をビットストリームにおいて符号化するステップであって、前記第１シンタックス要素は、前記ビットストリーム内の前記コーディングされたビデオデータの第１範囲でのコーディング制御のためのものであり、前記第１シンタックス要素は、前記変換スキップモードでの前記残差コーディングのための前記スライスベースＲｉｃｅコーディングの前記コーディングツールに関連し、前記第１値は、前記コーディングされたビデオデータの前記第１範囲のコーディングでの前記コーディングツールの不使用を示す、前記符号化するステップと
を有する方法。

【発明の詳細な説明】

【技術分野】

【0001】

［参照による援用］
本特許出願は、２０２１年９月２９日付けで「TECHNIQUES FOR CONSTRAINT FLAG SIGNALING FOR RANGE EXTENSION WITH TRANSFORM RESIDUAL RICE CODING」との発明の名称で出願された米国特許仮出願第６３／２５０１８０号に対する優先権の利益を主張して２０２２年５月３１日付けで「TECHNIQUES FOR CONSTRAINT FLAG SIGNALING FOR RANGE EXTENSION WITH RICE CODING」との発明の名称で出願された米国特許出願第１７／７１０７９４号の優先権の利益を主張するものである。先願の開示は、それらの全文を参照により本願に援用される。

【0002】

［技術分野］
本開示は、ビデオコーディングに概して関係がある実施形態について記載する。

【背景技術】

【0003】

本明細書で与えられている背景の説明は、開示の背景を一般的に提示することを目的とするものである。現在指名されている発明者の研究は、その研究がこの背景の項で説明されている範囲で、また、出願時に先行技術としてさもなければ適格でない可能性がある説明の側面は、本開示に対する先行技術として明示的にも暗黙的にも認められない。

【0004】

ビデオ符号化及び復号化は、動き補償を伴ったインターピクチャ予測を用いて実行することができる。圧縮されていないデジタルビデオはピクチャの連続を含むことができ、各ピクチャは、例えば、１９２０×１０８０のルミナンスサンプル及び関連するクロミナンスサンプルの空間ディメンションを有する。ピクチャの連続は、例えば、毎秒６０ピクチャ、つまり６０Ｈｚの固定又は可変のピクチャレート（俗にフレームレートとしても知られている。）を有することができる。圧縮されていないビデオは、特定のビットレート要件を有している。例えば、サンプル当たり８ビットでの１０８０ｐ６０ ４：２：０ビデオ（６０Ｈｚのフレームレートでの１９２０×１０８０のルミナンスサンプル解像度）は、１．５Ｇビット／ｓに近いバンド幅を必要とする。そのようなビデオの１時間は、６００Ｇバイト超の記憶空間を必要とする。

【0005】

ビデオ符号化及び復号化の１つの目的は、圧縮による入力ビデオ信号の冗長性の低減であることができる。圧縮は、いくつかの場合に２桁以上、上記のバンド幅及び／又は記憶空間要件を減らすのを助けることができる。可逆圧縮及び不可逆圧縮の両方並びにそれらの組み合わせが用いられ得る。可逆圧縮は、原信号の厳密なコピーが圧縮された原信号から再構成可能である技術を指す。不可逆圧縮を使用する場合に、再構成された信号は、原信号と同じでない場合があるが、原信号と再構成された信号との間のひずみは、再構成された信号を、意図された用途にとって有用なものとするほど十分に小さい。ビデオの場合には、不可逆圧縮が広く用いられている。許容されるひずみの量は用途に依存し、例えば、特定の消費者ストリーミング用途のユーザは、テレビジョン配信用途のユーザよりも高いひずみを許容し得る。達成可能な圧縮比は、より高い許容可能な／受け入れ可能なひずみがより高い圧縮比をもたらし得ることを反映することができる。

【0006】

ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化、及びエントロピコーディングを含むいくつかの広いカテゴリからの技術を利用することができる。

【0007】

ビデオコーデック技術には、イントラコーディングとして知られている技術が含まれ得る。イントラコーディングでは、サンプル値が、以前に再構成された参照ピクチャからのサンプル又は他のデータを参照せずに表現される。いくつかのビデオコーデックにおいて、ピクチャは、サンプルのブロックに空間的に細分される。サンプルの全ブロックがイントラモードでコーディングされる場合に、そのピクチャはイントラピクチャであることができる。イントラピクチャ及びそれらの派生物、例えば、独立デコーダリフレッシュピクチャ（independent decoder refresh pictures）は、デコーダの状態をリセットするために使用可能であり、従って、コーディングされたビットストリーム及びビデオセッションにおける最初のピクチャとして、又は静止画像として使用され得る。イントラブロックのサンプルは、変換を受けることができ、変換係数は、エントロピコーディング前に量子化され得る。イントラ予測は、変換前領域でサンプル値を最小限にする技術であることができる。いくつかの場合に、変換後のＤＣ値が小さければ小さいほど、かつ、ＡＣ係数が小さければ小さいほど、エントロピコーディング後にブロックを表すために所与の量子化ステップサイズで必要とされるビットはますます少ない。

【0008】

例えば、ＭＰＥＧ－２世代のコーディング技術から知られているような、従来のイントラコーディングは、イントラ予測を使用しない。しかし、いくつかのより新しいビデオ圧縮技術は、例えば、データの空間的に隣接しかつ復号化順序において先行するブロックの符号化／復号化中に得られた周囲サンプルデータ及び／又はメタデータから試みる技術を含む。かような技術は、以降「イントラ予測」技術と呼ばれる。少なくともいくつかの場合に、イントラ予測は、再構成中の現在ピクチャからの参照データのみを使用し、参照ピクチャからは使用しない点に留意されたい。

【0009】

多種多様な形態のイントラ予測が存在し得る。かような技術の１つよりも多くが所与のビデオコーディング技術で使用可能である場合に、使用中の技術はイントラ予測モードでコーディングされ得る。特定の場合に、モードは、サブモード及び／又はパラメータを有することができ、それらは、独立してコーディングされ得るか、又はモードコードワードに含まれ得る。所与のモード／サブモード／パラメータ組み合わせのためにどのコードワードを使用すべきは、イントラ予測を通じてコーディング効率利得に影響を及ぼし得るので、エントロピコーディング技術が、コードワードをビットストリームに変換するために使用され得る。

【0010】

特定のモードのイントラ予測が、Ｈ．２６４により導入され、Ｈ．２６５で洗練され、Joint Exploration Model（ＪＥＭ）、Versatile Video Coding（ＶＶＣ）、及びBenchmark Set（ＢＭＳ）などのより新しいコーディング技術で更に洗練された。予測子ブロックは、既に利用可能なサンプルに属する隣接サンプル値を用いて形成され得る。隣接サンプルのサンプル値は、方向に応じて予測子ブロック内にコピーされる。使用中の方向の参照は、ビットストリームの中にコーディングされ得るか、又はそれ自体が予測されてもよい。

【0011】

図１Ａを参照すると、右下には、Ｈ．２６５の３３個のとり得る予測子方向（３５個のイントラモードのうちの３３個の角度モードに対応）から知られている９つの予測子方向のサブセットが表されている。矢印が集まる点（１０１）は、予測中のサンプルに相当する。矢印は、サンプルが予測されている方向を表す。例えば、矢印（１０２）は、サンプル（１０１）が、水平から４５度の角度で右上にある１つ又は複数のサンプルから予測される、ことを示す。同様に、矢印（１０３）は、サンプル（１０１）が、水平から２２．５度の角度でサンプル（１０１）の左下にある１つ又は複数のサンプルから予測される、ことを示す。

【0012】

依然として図１Ａを参照して、左上には、４×４個のサンプル（太破線によって示される。）の正方形ブロック（１０４）が表されている。正方形ブロック（１０４）は１６個のサンプルを含み、各サンプルは、「Ｓ」、Ｙ次元でのその位置（例えば、行インデックス）、及びＸ次元でのその位置（例えば、列インデックス）を用いてラベル付けされている。例えば、サンプルＳ２１は、Ｙ次元で（上から）２番目のサンプルかつＸ次元で（左から）１番目のサンプルである。同様に、サンプルＳ４４は、Ｙ及びＸの両方の次元でブロック（１０４）内の４番目のサンプルである。ブロックはサイズが４×４サンプルであるということで、Ｓ４４は右下にある。更には、類似した番号付け方式に従う参照サンプルが示されている。参照サンプルは、「Ｒ」と、ブロック（１０４）に対するそのＹ位置（例えば行インデックス）及びＸ位置（列インデックス）とを用いてラベル付けされている。Ｈ．２６４及びＨ．２６５の両方で、予測サンプルは再構成中のブロックに隣接するので、負値が使用される必要はない。

【0013】

イントラピクチャ予測は、シグナリングされた予測方向によって必要に応じて隣接サンプルから参照サンプル値をコピーすることによって、働くことができる。例えば、コーディングされたビデオビットストリームが、このブロックについて、矢印（１０２）と一致する予測方向を示す、すなわち、サンプルが水平から４５度の角度で右上にある１つ以上の予測サンプルから予測される、とのシグナリングを含む、とする。その場合に、サンプルＳ４１、Ｓ３２、Ｓ２３、及びＳ１４は、同じ参照サンプルＲ０５から予測される。次いで、サンプルＳ４４が参照サンプルＲ０８から予測される。

【0014】

特定の場合に、複数の参照サンプルの値は、参照サンプルを計算するために、特に、方向が４５度で等しく分割可能でない場合に、例えば、補間を通じて、結合されてもよい。

【0015】

とり得る方向の数は、ビデオコーディング技術が発展するとともに増えている。Ｈ．２６４（２００３年）では、９つの異なる方向が表現可能であった。それは、Ｈ．２６５（２０１３年）では３３個にまで増え、そして、ＪＥＭ／ＶＶＣ／ＢＭＳは、本開示の時点で、最大６５個の方向をサポートすることができる。最もありそうな方向を識別するために実験が行われており、エントロピコーディングにおける特定の技術は、可能性が低い方向に対する若干のペナルティを受け入れながら、少数のビットでそれらのありそうな方向を表現するよう使用されている。更に、方向それ自体は時々、隣接する、既に復号されたブロックで使用されている隣接方向から予測され得る。

【0016】

図１Ｂは、時間とともに増える予測方向の数を説明するために、ＪＥＭによる６５個のイントラ予測方向を表す概略図（１８０）を示す。

【0017】

方向を表すコーディングされたビデオビットストリーム内のイントラ予測方向ビットのマッピングは、ビデオコーディング技術ごとに異なる可能性があり、例えば、予測方向の単純な直接マッピングから、イントラ予測モードまで、コードワードまで、最確モードを含む複雑な適応スキーム、及び同様の技術まで及び得る。全ての場合で、しかしながら、特定の他の方向よりも統計的にビデオコンテンツで起こる可能性が低い特定の方向が存在し得る。ビデオ圧縮の目標は冗長性の低減であるということで、それらの可能性が低い方向は、上手く働くビデオコーディング技術では、よりありそうな方向よりも多いビット数によって表現されることになる。

【0018】

動き補償は、不可逆圧縮技術であることができ、以前に再構成されたピクチャ又はその部分（参照ピクチャ）からのサンプルデータのブロックが、動きベクトル（以降ＭＶ）によって示された方向において空間的にシフトされた後に、新たに再構成されるピクチャ又はピクチャ部分の予測のために使用される技術に関係があり得る。いくつかの場合に、参照ピクチャは、現在再構成中のピクチャと同じであることができる。ＭＶは２つの次元Ｘ及びＹ、又は３つの次元を有することができ、３番目の次元は、使用中の参照ピクチャの指示である（後者は、間接的に、時間次元であることができる。）。

【0019】

いくつかのビデオ圧縮技術では、サンプルデータの特定のエリアに適用可能なＭＶは、他のＭＶから、例えば、再構成中のエリアに空間的に隣接するサンプルデータの他のエリアに関係があり、復号化順序においてそのＭＶに先行するものから、予測され得る。そうすることで、ＭＶをコーディングするために必要なデータの量を大幅に減らすことができ、それによって、冗長性を取り除きかつ圧縮を高める。例えば、カメラから得られた入力ビデオ信号（自然ビデオ（natural video）として知られる。）をコーディングする場合に、単一のＭＶが適用可能であるエリアよりも大きいエリアが同様の方向に移動するという統計的可能性があり、従って、いくつかの場合には、隣接するエリアのＭＶから導出された同様の動きベクトルを用いて予測可能であるということで、ＭＶ予測は有効に働くことができる。その結果、所与のエリアについて求められるＭＶは、周囲のＭＶから予測されたＭＶと類似又は同じであり、エントロピコーディング後に、ＭＶを直接コーディングする場合に使用されることになるビット数よりも少ないビットで表され得る。いくつかの場合に、ＭＶ予測は、原信号（すなわち、サンプルストリーム）から導出された信号（すなわち、ＭＶ）の可逆圧縮の例であることができる。他の場合には、ＭＶ予測それ自体は、例えば、いくつかの周囲のＭＶから予測子を計算するときの丸め誤差のために、不可逆であり得る。

【0020】

様々なＭＶ予測メカニズムがＨ．２６５／ＨＥＶＣ（ＩＴＵ－Ｔ Ｒｅｃ． Ｈ２６５，“High Efficiency Video Coding”，２０１６年１２月）で説明されている。Ｈ．２６５が提案する多くのＭＶ予測メカニズムの中から、本明細書では、以降「空間マージ」（spatial merge）と呼ばれる技術が説明される。

【0021】

図２を参照すると、現在ブロック（２０１）は、空間的にシフトされている同じサイズの前のブロックから予測可能であると動き探索プロセス中にエンコーダによって認められたサンプルを有する。そのＭＶを直接にコーディングする代わりに、ＭＶは、１つ以上の参照ピクチャと関連付けられたメタデータから、例えば、（復号化順序において）最も最近の参照ピクチャから、Ａ０、Ａ１及びＢ０、Ｂ１、Ｂ２（夫々、２０２乃至２０６）と表される５つの周囲サンプルのうちのいずれか１つと関連付けられたＭＶを用いて導出され得る。Ｈ．２６５では、ＭＶ予測は、隣接するブロックが使用している同じ参照ピクチャからの予測子を使用することができる。

【発明の概要】

【0022】

開示の態様は、ビデオデータ処理のための方法及び装置を提供する。いくつかの例で、ビデオデータ処理のための装置は処理回路を含む。例えば、処理回路は、ビットストリーム内のコーディングされたビデオデータの第１範囲でのコーディング制御のための第１シンタックス要素を決定する。第１シンタックス要素は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールに関連する。コーディングツールは、いくつかの例において、変換スキップモードでの残差コーディングのためのスライスレベルでのＲｉｃｅパラメータを提供する。第１シンタックス要素が第１範囲でのコーディングツールの無効化を示す第１値であることに応答して、処理回路は、コーディングツールを呼び出さずに、コーディングされたビデオデータの１つ以上の第２範囲を含むコーディングされたビデオデータの第１範囲を復号する。

【0023】

いくつかの実施形態で、第１シンタックス要素は、出力レイヤセット内のピクチャのコーディング制御のための一般制約情報（general constraint information）に含まれる。いくつかの例において、第１シンタックス要素の第１値は、出力レイヤセット内の各コーディングレイヤビデオシーケンス（Coded Layer Video Sequence、ＣＬＶＳ）でコーディングツールを無効化することを示す。

【0024】

いくつかの実施形態で、第１シンタックス要素が第１値であることに応答して、処理回路は、ビットストリーム内のコーディングレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２シンタックス要素を、ＣＬＶＳを復号するためにコーディングツールを呼び出さないことを示す値を有するように制約する。いくつかの例において、第２シンタックス要素の値は、ＣＬＶＳのピクチャ内のスライスのスライスヘッダでのコーディングツールに関連したスライスヘッダフラグの不存在を示す。

【0025】

いくつかの実施形態において、第１シンタックス要素が第２値であり、変換スキップモードがコーディングレイヤビデオシーケンス（ＣＬＶＳ）で有効にされることに応答して、処理回路は、ＣＬＶＳが参照するシーケンスパラメータセット（Sequence Parameter Set，ＳＰＳ）内の第２シンタックス要素の値を復号する。第２シンタックス要素は、Ｒｉｃｅパラメータの選択を示すスライスレベルシンタックス要素の存在／不存在を示す。第２シンタックス要素の値がスライスレベルシンタックス要素の存在を示すことに応答して、一例において、処理回路は、スライスのスライスヘッダから第３シンタックス要素を復号し、第３シンタックス要素は、変換スキップモードでのスライスの残差コーディングのためのＲｉｃｅパラメータの選択を示す。

【0026】

いくつかの実施形態で、第２シンタックス要素がＣＬＶＳのＳＰＳに存在しないことに応答して、処理回路は、ＣＬＶＳでのコーディングツールの不使用を示す第２シンタックス要素の値を推測する。

【0027】

いくつかの例において、処理回路は、一般制約情報のためのシンタックス構造内のシンタックス要素がシンタックス構造内の一般制約情報のための追加ビットを示すことに応答して、シンタックス構造から第１シンタックス要素を復号する。

【0028】

開示の態様はまた、ビデオ復号化のためのコンピュータによって実行される場合に、コンピュータに、ビデオ復号化のための法法を実行させる命令を記憶している非一時的なコンピュータ可読記憶媒体も提供する。

【0029】

開示されている対象の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。

【図面の簡単な説明】

【0030】

【図1A】イントラ予測モードの例示的なサブセットの模式図である。

【図1B】例示的なイントラ予測方向の説明図である。

【図2】一例における現在のブロック及びその周囲空間マージ候補の模式図である。

【図3】実施形態に係る通信システム（３００）の略ブロック図の模式図である。

【図4】実施形態に係る通信システム（４００）の略ブロック図の模式図である。

【図5】実施形態に係るデコーダの略ブロック図の模式図である。

【図6】実施形態に係るエンコーダの略ブロック図の模式図である。

【図7】他の実施形態に係るエンコーダのブロック図を示す。

【図8】他の実施形態に係るデコーダのブロック図を示す。

【図9】本開示の実施形態に係る適応解像度変更（ＡＲＣ）パラメータのシグナリングの例を示す。

【図10】アップサンプリング又はダウンサンプリング係数、コードワード、及びＥｘｔ－Ｇｏｌｏｍｂコードのマッピングについてのテーブル（１０００）の例を示す。

【図11】本開示の実施形態に係るＡＲＣパラメータシグナリングのいくつかの例を示す。

【図12】いくつかの例におけるＰＴＬシンタックス要素の組のシンタックス構造例を示す。

【図13】いくつかの例における一般制約情報のシンタックス構造例を示す。

【図14A】本開示のいくつかの実施形態に係るＰＴＬシンタックス構造及び一般制約情報シンタックス構造を含むＰＴＬ情報の例を示す。

【図14B】本開示のいくつかの実施形態に係るＰＴＬシンタックス構造及び一般制約情報シンタックス構造を含むＰＴＬ情報の例を示す。

【図15A】本開示の実施形態に係る一般制約情報シンタックス構造の例を示す。

【図15B】本開示の実施形態に係る一般制約情報シンタックス構造の例を示す。

【図16】本開示のいくつかの実施形態に係る一般制約情報のシンタックス構造を示す。

【図17】本開示のいくつかの実施形態に係るシーケンスパラメータセット（ＳＰＳ）範囲拡張のシンタックス構造例を示す。

【図18】本開示の実施形態に係るプロセスを説明するフローチャートを示す。

【図19】本開示の実施形態に係るプロセスを説明するフローチャートを示す。

【図20】実施形態に係るコンピュータシステムの模式図である。

【発明を実施するための形態】

【0031】

図３は、本開示の実施形態に係る通信システム（３００）の略ブロック図を表す。通信システム（３００）は、例えば、ネットワーク（３５０）を介して、互いと通信することができる複数の端末デバイスを含む。例えば、通信システム（３００）は、ネットワーク（３５０）を介して相互接続されている端末デバイス（３１０）及び（３２０）の第１対を含む。図３の例では、端末デバイス（３１０）及び（３２０）の第１対は、データの一方向伝送を実行する。例えば、端末デバイス（３１０）は、ネットワーク（３５０）を介した他の端末デバイス（３２０）への伝送のために、ビデオデータ（例えば、端末デバイス（３１０）によって捕捉されるビデオピクチャのストリーム）をコーディングしてよい。符号化されたビデオデータは、１つ以上のコーディングされたビデオビットストリームの形で伝送可能である。端末デバイス（３２０）は、コーディングされたビデオデータをネットワーク（３５０）から受信し、コーディングされたビデオデータを復号してビデオピクチャを回復し、回復されたビデオデータに従ってビデオピクチャを表示してよい。一方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。

【0032】

他の例では、通信システム（３００）は、例えば、ビデオ会議中に、現れ得るコーディングされたビデオデータの双方向伝送を実行する端末デバイス（３３０）及び（３４０）の第２対を含む。データの双方向伝送のために、例において、端末デバイス（３３０）及び（３４０）の各端末デバイスは、ネットワーク（３５０）を介した端末デバイス（３３０）及び（３４０）のうちの他方の端末デバイスへの伝送のために、ビデオデータ（例えば、その端末デバイスによって捕捉されるビデオピクチャのストリーム）をコーディングしてよい。端末デバイス（３３０）及び（３４０）の各端末デバイスはまた、端末デバイス（３３０）及び（３４０）のうちの他方の端末デバイスによって送信されたコーディングされたビデオデータを受信してよく、コーディングされたビデオデータを復号してビデオピクチャを回復してよく、回復されたビデオデータに従って、アクセス可能な表示デバイスでビデオピクチャを表示してよい。

【0033】

図３の例では、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）は、サーバ、パーソナルコンピュータ、及びスマートフォンとして表され得るが、本開示の原理はそのように限定されなくてもよい。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤー、及び／又は専用のビデオ会議装置により用途を見出す。ネットワーク（３５０）は、例えば、ワイヤライン（有線）及び／又はワイヤレス通信ネットワークを含む、コーディングされたビデオデータを端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）の間で伝達する任意数のネットワークに相当する。通信ネットワーク（３５０）は、回路交換及び／又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークには、電気通信網、ローカルエリアネットワーク、ワイドエリアネットワーク及び／又はインターネットがある。本議論のために、ネットワーク（３５０）のアーキテクチャ及びトポロジは、本明細書において以降で説明されない限りは、本開示の動作に無関係であってよい。

【0034】

図４は、開示されている対象の応用例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を表す。開示されている対象は、例えば、ビデオ会議と、デジタルＴＶと、ＣＤ、ＤＶＤ、メモリスティックなどを含むデジタル媒体上での圧縮されたビデオの記憶と、などを含む他のビデオ対応用途に同様に適用可能であることができる。

【0035】

ストリーミングシステムは、例えば、圧縮されていないビデオピクチャのストリーム（４０２）を生成するビデオソース（４０１）、例えば、デジタルカメラ、を含むことができる捕捉サブシステム（４１３）を含んでよい。例において、ビデオピクチャのストリーム（４０２）は、デジタルカメラによって撮影されるサンプルを含む。ビデオピクチャのストリーム（４０２）は、符号化されたビデオデータ（４０４）（又はコーディングされたビデオビットストリーム）と比較して高いデータボリュームを強調するために太線で表されており、ビデオソース（４０１）へ結合されたビデオエンコーダ（４０３）を含む電子機器（４２０）によって処理され得る。ビデオエンコーダ（４０３）は、以下で更に詳細に記載されるように、開示されている対象の態様を可能にする又は実装するためのハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。符号化されたビデオデータ（４０４）（又は符号化されたビデオビットストリーム（４０４））は、ビデオピクチャのストリーム（４０２）と比較してより低いデータボリュームを強調するために細線で表されており、将来の使用のためにストリーミングサーバ（４０５）に記憶され得る。図４のクライアントサブシステム（４０６）及び（４０８）などの１つ以上のストリーミングクライアントサブシステムは、符号化されたビデオデータ（４０４）のコピー（４０７）及び（４０９）を読み出すためにストリーミングサーバ（４０５）にアクセスすることができる。クライアントサブシステム（４０６）は、例えば、電子機器（４３０）において、ビデオデコーダ（４１０）を含むことができる。ビデオデコーダ（４１０）は、符号化されたビデオデータの入来するコピー（４０７）を復号し、ディスプレイ（４１２）（例えば、表示スクリーン）又は他のレンダリングデバイス（図示せず。）でレンダリング可能なビデオピクチャの送出ストリーム（４１１）を生成する。いくつかのストリーミングシステムにおいて、符号化されたビデオデータ（４０４）、（４０７）、及び（４０９）（例えば、ビデオビットストリーム）は、特定のビデオコーディング／圧縮規格に従って符号化され得る。そのような規格の例には、ＩＴＵ－Ｔ推奨Ｈ．２６５がある。例において、開発中のビデオコーディング規格は、Versatile Video Coding（ＶＶＣ）として俗に知られている。開示されている対象は、ＶＶＣに関連して使用されてもよい。

【0036】

電子機器（４２０）及び（４３０）は、他のコンポーネント（図示せず。）を含むことができる。例えば、電子機器（４２０）は、ビデオデコーダ（図示せず。）を含むことができ、電子機器（４３０）は、ビデオエンコーダ（図示せず。）を同様に含むことができる。

【0037】

図５は、本開示の実施形態に係るビデオデコーダ（５１０）のブロック図を示す。ビデオデコーダ（５１０）は、電子機器（５３０）に含まれ得る。電子機器（５３０）は、受信器（５３１）（例えば、受信回路）を含むことができる。ビデオデコーダ（５１０）は、図４の例のビデオデコーダ（４１０）の代わりに使用され得る。

【0038】

受信器（５３１）は、ビデオデコーダ（５１０）によって復号されるべき１つ以上のコーディングされたビデオシーケンスを、同じ又は他の実施形態では、一度に１つのコーディングされたビデオシーケンスを、受信してよい。このとき、夫々のコーディングされたビデオシーケンスの復号化は、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、チャネル（５０１）から受信されてよく、チャネルは、符号化されたビデオデータを記憶している記憶デバイスへのハードウェア／ソフトウェアリンクであってよい。受信器（５３１）は、符号化されたビデオデータを他のデータ、例えば、コーディングされたオーディオデータ及び／又は補助的なデータストリームとともに受信してもよく、それらは、それらの各々の使用エンティティ（図示せず。）へ転送されてよい。受信器（５３１）は、コーディングされたビデオシーケンスを他のデータから分離してよい。ネットワークジッタに対抗するために、バッファメモリ（５１５）が受信器（５３１）とエントロピデコーダ／パーサ（５２０）（以降「パーサ（５２０）」）との間に結合されてよい。特定の用途では、バッファメモリ（５１５）は、ビデオデコーダ（５１０）の部分である。他では、それは、ビデオデコーダ（５１０）の外にあることができる（図示せず。）。更に他では、例えば、ネットワークジッタに対抗するための、ビデオデコーダ（５１０）の外にあるバッファメモリ（図示せず。）と、加えて、例えば、再生タイミングを操作するための、ビデオデコーダ（５１０）内のもう１つのバッファメモリ（５１５）とが存在することができる。受信器（５３１）が十分なバンド幅及び可制御性の記憶／転送デバイスから、又はアイソシンクロナス（isosynchronous）ネットワークからデータを受信しているときに、バッファメモリ（５１５）は必要とされなくてもよく、あるいは、小さいことが可能である。インターネットなどのベストエフォートのパケットネットワークでの使用のために、バッファメモリ（５１５）は必要とされる場合があり、比較的に大きいことが可能であり、有利なことには、適応サイズであることができ、ビデオデコーダ（５１０）の外のオペレーティングシステム又は同様の要素（図示せず。）で少なくとも部分的に実装され得る。

【0039】

ビデオデコーダ（５１０）は、コーディングされたビデオシーケンスからシンボル（５２１）を再構成するためのパーサ（５２０）を含んでよい。それらのシンボルのカテゴリは、ビデオデコーダ（５１０）の動作を管理するために使用される情報と、潜在的に、電子機器（５３０）の必須部分でないが、図５に示されたように、電子機器（５３０）へ結合され得るレンダーデバイス（５１２）（例えば、表示スクリーン）などのレンダリングデバイスを制御するための情報とを含む。レンダリングデバイスのための制御情報は、補助強化情報（Supplemental Enhancement Information，ＳＥＩ）メッセージ又はビデオユーザビリティ情報（Video Usability Information，ＶＵＩ）パラメータセットフラグメント（図示せず。）の形をとってよい。パーサ（５２０）は、受信されるコーディングされたビデオシーケンスをパース／エントロピ復号してよい。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術又は標準規格に従うことができ、可変長コーディング、ハフマンコーディング、文脈依存による又はよらない算術コーディング、などを含む様々な原理に従うことができる。パーサ（５２０）は、コーディングされたビデオシーケンスから、ビデオデコーダにおけるピクセルのサブグループのうちの少なくとも１つについてのサブグループパラメータの組を、そのグループに対応する少なくとも１つのパラメータに基づいて抽出し得る。サブグループは、グループ・オブ・ピクチャ（Group of Picture，ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（Coding Unit，ＣＵ）、ブロック、変換ユニット（Transform Unit，ＴＵ）、予測ユニット（Prediction Unit，ＰＵ）、などを含むことができる。パーサ（５２０）はまた、コーディングされたビデオシーケンスから、変換係数、量子化器パラメータ値、動きベクトル、などの情報も抽出し得る。

【0040】

パーサ（５２０）は、シンボル（５２１）を生成するために、バッファメモリ（５１５）から受信されたビデオシーケンスに対してエントロピ復号化／パーシング動作を実行してよい。

【0041】

シンボル（５２１）の再構成は、コーディングされたビデオピクチャ又はその部分（例えば、インター及びイントラピクチャ、インター及びイントラブロック）のタイプ及び他の因子に応じて多数の異なるユニットを有することができる。どのユニットがどのように含まれるかは、コーディングされたビデオシーケンスからパーサ（５２０）によってパースされたサブグループ制御情報によって制御され得る。パーサ（５２０）と以下の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明りょうさのために表されていない。

【0042】

既に述べられた機能ブロックを超えて、ビデオデコーダ（５１０）は、概念的に、以下で説明される多数の機能ユニットに細分され得る。商業上の制約の下で動作する実際の実施では、それらのユニットの多くが互いに密に相互作用し、少なくとも部分的に互いに組み込まれ得る。しかし、開示されている対象を説明することを目的として、以下での機能ユニットへの概念的細分は適切である。

【0043】

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

【0044】

いくつかの場合に、スケーラ／逆変換器（５５１）の出力サンプルは、イントラコーディングされたブロック、すなわち、前に再構成されたピクチャからの予測情報を使用しておらず、現在ピクチャの前に再構成された部分からの予測情報を使用することができるブロック、に関係することができる。かような予測情報は、イントラピクチャ予測ユニット（５５２）によって供給され得る。いくつかの場合に、イントラピクチャ予測ユニット（５５２）は、現在ピクチャバッファ（５５８）からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックと同じサイズ及び形状のブロックを生成する。現在ピクチャバッファ（５５８）は、例えば、部分的に再構成された現在ピクチャ及び／又は完全に再構成された現在ピクチャをバッファリングする。アグリゲータ（５５５）は、いくつかの場合に、サンプルごとに、イントラ予測ユニット（５５２）が生成した予測情報を、スケーラ／逆変換ユニット（５５１）によって供給される出力サンプル情報に加える。

【0045】

他の場合では、スケーラ／逆変換ユニット（５５１）の出力サンプルは、インターコーディングされた、そして潜在的に、動き補償されたブロックに関係することができる。かような場合に、動き補償予測ユニット（５５３）は、予測のために使用されるサンプルをフェッチするよう参照ピクチャメモリ（５５７）にアクセスすることができる。ブロックに関係するシンボル（５２１）に従って、フェッチされたサンプルを動き補償した後に、それらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（５５５）によって、スケーラ／逆変換ユニット（５５１）の出力（この場合に、残差サンプル又は残差信号と呼ばれる。）に加えられ得る。動き補償予測ユニット（５５３）が予測サンプルをフェッチする参照ピクチャメモリ（５５７）内のアドレスは、例えば、Ｘ、Ｙ及び参照ピクチャコンポーネントを有することができるシンボル（５２１）の形で動き補償予測ユニット（５５３）が利用することができる動きベクトルによって、制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリ（５５７）からフェッチされるサンプル値の補間や、動きベクトル予測メカニズムなどを含むこともできる。

【0046】

アグリゲータ（５５５）の出力サンプルは、ループフィルタユニット（５５６）において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタ技術を含むことができる。この技術は、コーディングされたビデオシーケンス（コーディングされたビデオビットストリームとも呼ばれる。）に含まれており、パーサ（５２０）からのシンボル（５２１）としてループフィルタユニット（５５６）に利用可能にされたパラメータによって制御されるが、コーディングされたピクチャ又はコーディングされたビデオシーケンスの（復号化順序において）前の部分の復号化中に得られたメタ情報にも応答することができ、更には、前に構成されたループフィルタ処理されたサンプル値に応答することもできる。

【0047】

ループフィルタユニット（５５６）の出力は、レンダーデバイス（５１２）へ出力され、更には、将来のインターピクチャ予測における使用のために参照ピクチャメモリ（５５７）に記憶され得るサンプルストリームであることができる。

【0048】

特定のコーディングされたピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用され得る。例えば、現在ピクチャに対応するコーディングされたピクチャが完全に再構成され、コーディングされたピクチャが（例えば、パーサ（５２０）によって）参照ピクチャとして識別されると、現在ピクチャバッファ（５５８）は、参照ピクチャメモリ（５５７）の部分になることができ、未使用の現在ピクチャバッファが、後続のコーディングされたピクチャの再構成を開始する前に再割り当てされ得る。

【0049】

ビデオデコーダ（５１０）は、ＩＴＵ－Ｔ推奨Ｈ．２６５などの標準規格における所定のビデオ圧縮技術に従って復号化動作を実行してよい。コーディングされたビデオシーケンスは、そのコーディングされたビデオシーケンスが、ビデオ圧縮技術又は標準規格のシンタックス及びビデオ圧縮技術又は標準規格において文書化されているプロファイルの両方に従うという意味で、使用中のビデオ圧縮技術又は標準規格によって規定されたシンタックスに従い得る。具体的には、プロファイルは、ビデオ圧縮技術又は標準規格で利用可能な全てのツールから、そのプロファイルの下での使用のために利用可能な唯一のツールとして、特定のツールを選択することができる。また、コーディングされたビデオシーケンスの複雑さは、ビデオ圧縮技術又は標準規格のレベルによって定義された境界内にあることが、順守のために必要である。いくつかの場合に、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、メガサンプル／秒で測定される。）、最大参照ピクチャサイズ、などを制限する。レベルによって設定された制限は、いくつかの場合に、仮想参照デコーダ（Hypothetical Reference Decoder，ＨＲＤ）仕様と、コーディングされたビデオシーケンスにおいて通知されるＨＲＤバッファ管理のためのメタデータとを通じて、更に制限され得る。

【0050】

実施形態において、受信器（５３１）は、符号化されたビデオとともに、追加の（冗長な）データを受信してもよい。追加のデータは、コーディングされたビデオシーケンスの部分として含まれてもよい。追加のデータは、ビデオデコーダ（５１０）によって、データを適切に復号するために及び／又は原ビデオデータをより正確に再構成するために使用されてよい。追加のデータは、例えば、時間、空間、又は信号対雑音比（ＳＮＲ）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正符号、などの形をとることができる。

【0051】

図６は、本開示の実施形態に係るビデオエンコーダ（６０３）のブロック図を示す。ビデオエンコーダ（６０３）は、電子機器（６２０）に含まれている。電子機器（６２０）は、送信器（６４０）（例えば、送信回路）を含む。ビデオエンコーダ（６０３）は、図４の例のビデオエンコーダ（４０３）の代わりに使用され得る。

【0052】

ビデオエンコーダ（６０３）は、ビデオエンコーダ（６０３）によってコーディングされるべきビデオ画像を捕捉し得るビデオソース（６０１）（図６の例では電子機器（６２０）の部分ではない。）からビデオサンプルを受信してよい。他の例では、ビデオソース（６０１）は、電子機器（６２０）の部分である。

【0053】

ビデオソース（６０１）は、任意の適切なビットデプス（例えば、８ビット、１０ビット、１２ビットなど）、任意の色空間（例えば、ＢＴ．６０１ ＹＣｒＣＢ、ＲＧＢなど）、及び任意の適切なサンプリング構造（例えば、ＹＣｒＣｂ ４：２：０、ＹＣｒＣｂ ４：４：４）であることができるデジタルビデオサンプルストリームの形で、ビデオエンコーダ（６０３）によってコーディングされるべきソースビデオシーケンスを供給してよい。メディアサービングシステムでは、ビデオソース（６０１）は、予め準備されたビデオを記憶している記憶デバイスであってよい。ビデオ会議システムでは、ビデオソース（６０１）は、ローカル画像情報をビデオシーケンスとして捕捉するカメラであってよい。ビデオデータは、順に見られる場合に動きを授ける複数の個別ピクチャとして供給されてもよい。ピクチャ自体は、ピクセルの空間アレイとして編成されてよく、各ピクセルは、使用中のサンプリング構造、色空間、などに依存する１つ以上のサンプルを有することができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。本明細書は、以下、サンプルに焦点を当てる。

【0054】

実施形態に従って、ビデオエンコーダ（６０３）は、実時間において、又は用途によって必要とされる任意の他の時間制約の下で、ソースビデオシーケンスのピクチャを、コーディングされたビデオシーケンス（６４３）へとコーディング及び圧縮してよい。適切なコーディング速度を強いることは、コントローラ（６５０）の一機能である。いくつかの実施形態において、コントローラ（６５０）は、以下で記載されるような他の機能ユニットを制御し、他の機能ユニットへ機能的に結合される。結合は明りょうさのために表されていない。コントローラ（６５０）によってセットされるパラメータには、レート制御に関連したパラメータ（ピクチャスキップ、量子化器、レートひずみ最適化技術のラムダ値、など）、ピクチャサイズ、グループ・オブ・ピクチャ（ＧＯＰ）レイアウト、最大動きベクトル探索範囲、などが含まれ得る。コントローラ（６５０）は、特定のシステム設計のために最適化されたビデオエンコーダ（６０３）に関係する他の適切な機能を有するよう構成され得る。

【0055】

いくつかの実施形態において、ビデオエンコーダ（６０３）は、コーディングループで動作するよう構成される。過度に単純化された記載として、例において、コーディングループは、ソースコーダ（６３０）（例えば、コーディングされるべき入力ピクチャと、参照ピクチャとに基づいて、シンボルストリームなどのシンボルを生成することに関与する。）と、ビデオエンコーダ（６０３）に埋め込まれた（ローカル）デコーダ（６３３）とを含むことができる。デコーダ（６３３）は、（シンボルとコーディングされたビデオストリームとの間の如何なる圧縮も、開示されている対象で考えられているビデオ圧縮技術において可逆であるということで）（遠隔の）デコーダも生成することになるのと同様の方法でサンプルデータを生成するようにシンボルを再構成する。再構成されたサンプルストリーム（サンプルデータ）は、参照ピクチャメモリ（６３４）へ入力される。シンボルストリームの復号化は、デコーダの場所（ローカル又は遠隔）に依存しないビットパーフェクト（bit-exact）な結果をもたらすので、参照ピクチャメモリ（６３４）内のコンテンツも、ローカルのエンコーダと遠隔のエンコーダとの間でビットパーフェクトである。すなわち、エンコーダの予測部分は、デコーダが復号化中に予測を使用するときに“見る”ことになるのとまさに同じサンプル値を参照ピクチャサンプルとして“見る”。参照ピクチャのシンクロニシティ（及び、例えば、チャネルエラーのために、シンクロニシティが維持され得ない場合に、結果として生じるドリフト）のこの基本原理は、いくつかの関連技術でも使用されている。

【0056】

“ローカル”のデコーダ（６３３）の動作は、図５とともに詳細に既に上述されている、ビデオデコーダ（５１０）などの“遠隔”のデコーダと同じであることができる。一時的に図５も参照すると、しかしながら、シンボルが利用可能であり、エントロピコーダ（６４５）及びパーサ（５２０）によるコーディングされたビデオシーケンスへのシンボルの符号化／復号化が可逆であることができるということで、バッファメモリ（５１５）及びパーサ（５２０）を含むビデオデコーダ（５１０）のエントロピ復号化部分は、ローカルのデコーダ（６３３）において完全には実装されなくてもよい。

【0057】

この時点で観察できることは、デコーダに存在するパーシング／エントロピ復号化を除く如何なるデコーダ技術も、必然的に、対応するエンコーダにおいて略同じ機能形態で存在する必要がある、ということである。この理由により、開示されている対象は、デコーダの動作に焦点を当てる。エンコーダ技術の説明は、それらが、包括的に記載されるデコーダ技術の逆であるということで、省略され得る。特定の範囲においてのみ、より詳細な説明が必要とされ、以下で与えられている。

【0058】

動作中、いくつかの例では、ソースコーダ（６３０）は、動き補償された予測コーディングを実行してよい。これは、「参照ピクチャ」として指定された、ビデオシーケンスからの１つ以上の前にコーディングされたピクチャを参照して、予測的に入力ピクチャをコーディングする。このようにして、コーディングエンジン（６３２）は、入力ピクチャに対する予測参照として選択され得る参照ピクチャのピクセルブロックと入力ピクチャのピクセルブロックとの間の差をコーディングする。

【0059】

ローカルのビデオデコーダ（６３３）は、ソースコーダ（６３０）によって生成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコーディングされたビデオデータを復号してよい。コーディングエンジン（６３２）の動作は、有利なことに、不可逆プロセスであってよい。コーディングされたビデオデータがビデオデコーダ（図６には図示せず。）で復号され得るとき、再構成されたビデオシーケンスは、通常は、いくらかのエラーを伴ったソースビデオシーケンスの複製であり得る。ローカルのビデオデコーダ（６３３）は、参照ピクチャに対してビデオデコーダによって実行され得る復号化プロセスを再現し、再構成された参照ピクチャを参照ピクチャキャッシュ（６３４）に格納されるようにしてよい。このように、ビデオエンコーダ（６０３）は、（伝送エラーなしで）遠端のビデオデコーダによって取得されることになる再構成された参照ピクチャと共通の内容を有している再構成された参照ピクチャのコピーをローカルで記憶し得る。

【0060】

予測器（６３５）は、コーディングエンジン（６３２）のための予測探索を実行してよい。すなわち、新しいピクチャがコーディングされるために、予測器（６３５）は、その新しいピクチャのための適切な予測基準となり得る参照ピクチャ動きベクトル、ブロック形状、などの特定のメタデータ又は（候補参照ピクセルブロックとしての）サンプルデータを参照ピクチャメモリ（６３４）から探してよい。予測器（６３５）は、適切な予測基準を見つけるためにサンプルブロック・バイ・ピクセルブロックベース（sample block-by-pixel block basis）で動作してよい。いくつかの場合に、予測器（６３５）によって取得された探索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（６３４）に記憶されている複数の参照ピクチャから引き出された予測基準を有してよい。

【0061】

コントローラ（６５０）は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含め、ソースコーダ（６３０）のコーディング動作を管理してよい。

【0062】

上記の全ての機能ユニットの出力は、エントロピコーダ（６４５）においてエントロピコーディングを受けてよい。エントロピコーダ（６４５）は、ハフマンコーディング、可変長コーディング、算術コーディングなどの技術に従ってシンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを、コーディングされたビデオシーケンスへと変換する。

【0063】

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

【0064】

コントローラ（６５０）は、ビデオエンコーダ（６０３）の動作を管理してよい。コーディング中、コントローラ（６５０）は、各々のピクチャに適用され得るコーディング技術に影響を及ぼす可能性がある特定のコーディングされたピクチャタイプを夫々のコーディングされたピクチャに割り当ててよい。例えば、ピクチャはしばしば、次のピクチャタイプのうちの１つとして割り当てられてよい。

【0065】

イントラピクチャ（Intra Picture）（Ｉピクチャ）は、予測のソースとしてシーケンス内の如何なる他のピクチャも使用せずに符号化及び復号化され得るピクチャであってよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ（Independent Decoder Refresh，ＩＤＲ）ピクチャを含む種々のタイプのイントラピクチャを許容する。当業者であれば、Ｉピクチャのそのような変形並びにそれらの各々の応用及び特徴を知っている。

【0066】

予測ピクチャ（Predictive Picture）（Ｐピクチャ）は、各ブロックのサンプル値を予測するために多くても１つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。

【0067】

双方向予測ピクチャ（Bi-directionally Predictive Picture）（Ｂピクチャ）は、各ブロックのサンプル値を予測するために多くても２つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。同様に、多重予測ピクチャ（multiple-predictive picture(s)）は、単一のブロックの再構成のために２つよりも多い参照ピクチャ及び関連するメタデータを使用することができる。

【0068】

ソースピクチャは、一般に、複数のサンプルブロック（例えば、夫々、４×４、８×８、４×８、又は１６×１６のサンプルのブロック）に空間的に細分され、ブロックごとにコーディングされてよい。ブロックは、ブロックの各々のピクチャに適用されているコーディング割り当てによって決定される他の（既にコーディングされた）ブロックを参照して予測的にコーディングされてよい。例えば、Ｉピクチャのブロックは、非予測的にコーディングされてよく、あるいは、それらは、同じピクチャの既にコーディングされたブロックを参照して予測的にコーディングされてもよい（空間予測又はイントラ予測）。Ｐピクチャのピクセルブロックは、１つの前にコーディングされた参照ピクチャを参照して空間予測により又は時間予測により、予測的にコーディングされてよい。Ｂピクチャのブロックは、１つ又は２つの前にコーディングされた参照ピクチャを参照して空間予測により又は時間予測により、予測的にコーディングされてよい。

【0069】

ビデオエンコーダ（６０３）は、ＩＴＵ－Ｔ推奨Ｈ．２６５のような所定のビデオコーディング技術又は標準規格に従ってコーディング動作を実行してよい。その動作中に、ビデオエンコーダ（６０３）は、入力ビデオシーケンスにおける時間及び空間冗長性を利用する予測コーディング動作を含む様々な圧縮動作を実行してよい。従って、コーディングされたビデオデータは、使用されているビデオコーディング技術又は標準規格によって定められているシンタックスに従い得る。

【0070】

実施形態において、送信器（６４０）は、符号化されたビデオとともに追加のデータを送信してもよい。ソースコーダ（６３０）は、コーディングされたビデオシーケンスの部分としてそのようなデータを含めてよい。追加のデータは、時間／空間／ＳＮＲエンハンスメントレイヤ、冗長ピクチャ及びスライスなどの他の形式の冗長データ、ＳＥＩメッセージ、ＶＵＩパラメータセットフラグメント、などを有してよい。

【0071】

ビデオは、時間シーケンスにおいて複数のソースピクチャ（ビデオピクチャ）として捕捉されてよい。イントラピクチャ予測（しばしばイントラ予測と省略される。）は、所与のピクチャにおける空間相関を利用し、インターピクチャ予測は、ピクチャ間の（時間又は他の）相関を利用する。例において、現在ピクチャ（current picture）と呼ばれる、符号化／復号化中の特定のピクチャは、ブロックにパーティション化される。現在ピクチャ内のあるブロックが、ビデオの前にコーディングされて依然としてバッファリングされている参照ピクチャ内の参照ブロックと類似している場合に、現在ピクチャ内のそのブロックは、動きベクトル（motion vector）と呼ばれるベクトルによってコーディングされ得る。動きベクトルは、参照ピクチャ内の参照ブロックを指し示し、複数の参照ピクチャが使用されている場合には、参照ピクチャを識別する第３の次元を有することができる。

【0072】

いくつかの実施形態において、双予測技術がインターピクチャ予測において使用され得る。双予測技術に従って、２つの参照ピクチャ、例えば、ビデオ内で現在ピクチャに対して復号化順序において両方とも先行する（しかし、表示順序では、夫々、過去及び将来にあってよい。）第１参照ピクチャ及び第２参照ピクチャが、使用される。現在ピクチャ内のあるブロックは、第１参照ピクチャ内の第１参照ブロックを指し示す第１動きベクトルと、第２参照ピクチャ内の第２参照ブロックを指し示す第２動きベクトルとによって、コーディングされ得る。そのブロックは、第１参照ブロック及び第２参照ブロックの組み合わせによって予測可能である。

【0073】

更に、マージモード技術が、コーディング効率を改善するためにインターピクチャ予測において使用され得る。

【0074】

本開示のいくつかの実施形態に従って、インターピクチャ予測及びイントラピクチャ予測などの予測は、ブロックの単位で実行される。例えば、ＨＥＶＣ標準規格に従って、ビデオピクチャのシーケンス内のピクチャは、圧縮のためにコーディングツリーユニット（Coding Tree Unit，ＣＴＵ）にパーティション化され、ピクチャ内のＣＴＵは、６４×６４ピクセル、３２×３２ピクセル、又は１６×１６ピクセルといった同じサイズを有する。一般に、ＣＴＵは、１つのルーマＣＴＢ及び２つのクロマＣＴＢである３つのコーディングツリーブロック（Coding Tree Block，ＣＴＢ）を含む。各ＣＴＵは、１つ又は複数のコーディングユニット（Coding Unit，ＣＵ）に再帰的に四分木分割され得る。例えば、６４×６４ピクセルのＣＴＵは、６４×６４ピクセルの１つのＣＵ、又は３２×３２ピクセルの４つのＣＵ、又は１６×１６ピクセルの１６個のＣＵに分割可能である。例において、各ＣＵは、インター予測タイプ又はイントラ予測タイプなどの、当該ＣＵのための予測タイプを決定するよう、解析される。ＣＵは、時間及び／又は空間予測可能性に応じて１つ以上の予測ユニット（Prediction Unit，ＰＵ）に分割される。一般に、各ＰＵは、１つのルーマ予測ブロック（Prediction Block，ＰＢ）及び２つのクロマＰＢを含む。実施形態において、コーディング（符号化／復号化）における予測動作は、予測ブロックの単位で実行される。予測ブロックの例としてルーマ予測ブロックを使用すると、予測ブロックは、８×８ピクセル、１６×１６ピクセル、８×１６ピクセル、１６×８ピクセルなどのような、ピクセルの値（例えば、ルーマ値）の行列を含む。

【0075】

図７は、開示の他の実施形態に係るビデオエンコーダ（７０３）の図を示す。ビデオエンコーダ（７０３）は、ビデオピクチャの連続に含まれる現在ビデオピクチャ内のサンプル値の処理ブロック（例えば、予測ブロック）を受け取り、コーディングされたビデオシーケンスの部分であるコーディングされたピクチャへと処理ブロックを符号化するよう構成される。例において、ビデオエンコーダ（７０３）は、図４の例のビデオエンコーダ（４０３）の代わりに使用される。

【0076】

ＨＥＶＣの例では、ビデオエンコーダ（７０３）は、８×８サンプルの予測ブロックなどのような処理ブロックのためのサンプル値の行列を受け取る。ビデオエンコーダ（７０３）は、例えば、レートひずみ最適化を用いて、処理ブロックがイントラモード、インターモード、又は双予測モードにより最も良くコーディングされるかどうかを決定する。処理ブロックがイントラモードでコーディングされるべきである場合には、ビデオエンコーダ（７０３）は、コーディングされたピクチャへと処理ブロックを符号化するためにイントラ予測技術を使用してよく、処理ブロックがインターモード又は双予測モードでコーディングされるべきである場合には、ビデオエンコーダ（７０３）は、コーディングされたピクチャへと処理ブロックを符号化するためにインター予測又は双予測技術を夫々使用してよい。特定のビデオコーディング技術において、マージモードは、予測子の外にあるコーディングされた動きベクトル成分の恩恵を受けずに１つ以上の動きベクトル予測子から動きベクトルが導出されるインターピクチャ予測サブモードであることができる。特定の他のビデオコーディング技術では、対象ブロックに適用可能な動きベクトル成分が存在する場合がある。例において、ビデオエンコーダ（７０３）は、処理ブロックのモードを決定するモード決定モジュール（図示せず。）などの他のコンポーネントを含む。

【0077】

図７の例では、ビデオエンコーダ（７０３）は、図７に示されるように結合されているインターエンコーダ（７３０）、イントラエンコーダ（７２２）、残差計算部（７２３）、スイッチ（７２６）、残差エンコーダ（７２４）、汎用コントローラ（７２１）、及びエントロピエンコーダ（７２５）を含む。

【0078】

インターエンコーダ（７３０）は、現在ブロック（例えば、処理ブロック）のサンプルを受け取り、そのブロックを参照ピクチャ内の１つ以上の参照ブロック（例えば、前のピクチャ及び後のピクチャ内のブロック）と比較し、インター予測情報（例えば、インター符号化技術に従う冗長情報の記述、動きベクトル、マージモード情報）を生成し、何らかの適切な技術を用いてインター予測情報に基づいてインター予測結果（例えば、予測されたブロック）を計算するよう構成される。いくつかの例において、参照ピクチャは、符号化されたビデオ情報に基づいて復号されている復号された参照ピクチャである。

【0079】

イントラエンコーダ（７２２）は、現在ブロック（例えば、処理ブロック）のサンプルを受け取り、いくつかの場合には、同じピクチャ内で既にコーディングされたブロックとそのブロックを比較し、変換後の量子化された係数を、更には、いくつかの場合には、イントラ予測情報（例えば、１つ以上のイントラ符号化技術に従うイントラ予測方向情報）も生成するよう構成される。例において、イントラエンコーダ（７２２）はまた、イントラ予測情報及び同じピクチャ内の参照ブロックに基づいてイントラ予測結果（例えば、予測ブロック）を計算する。

【0080】

汎用コントローラ（７２１）は、汎用制御データを決定し、汎用制御データに基づいてビデオエンコーダ（７０３）の他のコンポーネントを制御するよう構成される。例において、汎用コントローラ（７２１）は、ブロックのモードを決定し、モードに基づいて制御信号をスイッチ（７２６）へ供給する。例えば、モードがイントラモードである場合には、汎用コントローラ（７２１）は、残差計算部（７２３）による使用のためにイントラモード結果を選択するようスイッチ（７２６）を制御し、そして、イントラ予測情報を選択し、イントラ予測情報をビットストリームに含めるようエントロピエンコーダ（７２５）を制御する。モードがインターモードである場合には、汎用コントローラ（７２１）は、残差計算部（７２３）による使用のためにインター予測結果を選択するようスイッチ（７２６）を制御し、そして、インター予測情報を選択し、インター予測情報をビットストリームに含めるようエントロピエンコーダ（７２５）を制御する。

【0081】

残差計算部（７２３）は、受け取られたブロックと、イントラエンコーダ（７２２）又はインターエンコーダ（７３０）から選択された予測結果との間の差（残差データ）を計算するよう構成される。残差エンコーダ（７２４）は、残差データを符号化して変換係数を生成するために残差データに基づき動作するよう構成される。例において、残差エンコーダ（７２４）は、残差データを空間領域から周波数領域に変換し、変換係数を生成するよう構成される。次いで、変換係数は、量子化された変換係数を取得するよう量子化処理を受ける。様々な実施形態において、ビデオエンコーダ（７０３）はまた、残差デコーダ（７２８）も含む。残差デコーダ（７２８）は、逆変換を実行し、復号された残差データを生成するよう構成される。復号された残差データは、イントラエンコーダ（７２２）及びインターエンコーダ（７３０）によって適切に使用され得る。例えば、インターエンコーダ（７３０）は、復号された残差データ及びインター予測情報に基づいて、復号ブロックを生成することができ、イントラエンコーダ（７２２）は、復号された残差データ及びイントラ予測情報に基づいて、復号されたブロックを生成することができる。復号されたブロックは、復号されたピクチャを生成するよう適切に処理され、復号されたピクチャは、メモリ回路（図示せず。）にバッファリングされ、いくつかの例では参照ピクチャとして使用され得る。

【0082】

エントロピエンコーダ（７２５）は、符号化されたブロックを含めるようにビットストリームをフォーマット化するよう構成される。エントロピエンコーダ（７２５）は、ＨＥＶＣ標準規格などの適切な標準規格に従って様々な情報を含めるよう構成される。例において、エントロピエンコーダ（７２５）は、汎用制御データ、選択された予測情報（例えば、イントラ予測情報又はインター予測情報）、残差情報、及び他の適切な情報をビットストリームに含めるよう構成される。開示されている対象に従って、インターモード又は双予測モードのどちらか一方のマージサブモードでブロックをコーディングする場合に、残差情報は存在しない点に留意されたい。

【0083】

図８は、開示の他の実施形態に従うビデオデコーダ（８１０）の図を示す。ビデオデコーダ（８１０）は、コーディングされたビデオシーケンスの部分であるコーディングされたピクチャを受け取り、コーディングされたピクチャを復号して、再構成されたピクチャを生成するよう構成される。例において、ビデオデコーダ（８１０）は、図４の例のビデオデコーダ（４１０）の代わりに使用される。

【0084】

図８の例では、ビデオデコーダ（８１０）は、図８に示されるように結合されているエントロピデコーダ（８７１）、インターデコーダ（８８０）、残差デコーダ（８７３）、再構成モジュール（８７４）、及びイントラデコーダ（８７２）を含む。

【0085】

エントロピデコーダ（８７１）は、コーディングされたピクチャから、シンタックス要素を表す特定のシンボルを再構成するよう構成され得、それらから、コーディングされたピクチャは構成されている。かようなシンボルは、例えば、ブロックがコーディングされるモード（例えば、イントラモード、又はマージサブモード若しくは他のサブモードにおけるインターモード若しくは双予測モード）、イントラデコーダ（８７２）又はインターデコーダ（８８０）による予測のために夫々使用される特定のサンプル又はメタデータを識別することができる予測情報（例えば、イントラ予測情報又はインター予測情報）、例えば、量子化された変換係数の形をとる残差情報、などを含むことができる。例において、予測モードがインター又は双予測モードである場合には、インター予測情報がインターデコーダ（８８０）へ供給され、予測タイプがイントラ予測タイプである場合には、イントラ予測情報がイントラデコーダ（８７２）へ供給される。残差情報は、逆量子化を受けることができ、残差デコーダ（８７３）へ供給される。

【0086】

インターデコーダ（８８０）は、インター予測情報を受け取り、インター予測情報に基づいてインター予測結果を生成するよう構成される。

【0087】

イントラデコーダ（８７２）は、イントラ予測情報を受け取り、イントラ予測情報に基づいて予測結果を生成するよう構成される。

【0088】

残差デコーダ（８７３）は、逆量子化された変換係数を取り出すように逆量子化を実行し、逆量子化された変換係数を処理して、残差を周波数領域から空間領域に変換するよう構成される。残差デコーダ（８７３）はまた、（量子化パラメータ（ＱＰ）を含めるための）特定の制御情報を要求してもよく、その情報は、エントロピデコーダ（８７１）によって供給されてよい（これは低容量の制御情報のみであるということで、データパスは示されない。）。

【0089】

再構成モジュール（８７４）は、残差デコーダ（８７３）によって出力された残差と、（場合によっては、インター又はイントラ予測モジュールによって出力された）予測結果とを空間領域において組み合わせて、再構成されたブロックを形成するよう構成される。再構成されたブロックは、再構成されたピクチャの部分であってよく、次いで、再構成されたピクチャは、再構成されたビデオの部分であってよい。なお、デブロッキング動作などのような他の適切な動作が、視覚品質を改善するために実行されてもよい。

【0090】

なお、ビデオエンコーダ（４０３）、（６０３）及び（７０３）並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、如何なる適切な技術によっても実装可能である。実施形態において、ビデオエンコーダ（４０３）、（６０３）及び（７０３）並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、１つ以上の集積回路を用いて実装可能である。他の実施形態では、ビデオエンコーダ（４０３）、（６０３）及び（７０３）並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、ソフトウェア命令を実行する１つ以上のプロセッサを用いて実装可能である。

【0091】

本開示の態様は、コーディングされたビデオストリームに制約フラグを含むコーディングツール及び機能の制御技術を提供する。

【0092】

本開示の態様に従って、ビットストリーム内のピクチャサイズは、同じままであることができ、あるいは、変化してもよい。いくつかの関連例では、ビデオエンコーダ及びデコーダは、コーディングされたビデオシーケンス（Coded Video Sequence，ＣＶＳ）、グループ・オブ・ピクチャ（Groupe Of Picture，ＧＯＰ）、又は類似したマルチピクチャ時間フレームのために定義されて一定のままである所与のピクチャサイズに対して作用することができる。一例では、ＭＰＥＧ－２などで、システム設計は、シーンのアクティビティなどの因子に応じて水平解像度（よってピクチャサイズ）を変更することが知られているが、Ｉピクチャでのみ、従って、ピクチャサイズは、通常はＧＯＰのために定義されて一定のままである。ＣＶＳ内の異なる解像度の使用のための参照ピクチャのリサンプリングは、例えばＩＴＵ－Ｔ推奨Ｈ．２６３付録Ｐから、知られている。しかし、ＣＶＳでのピクチャサイズは変化せず、参照ピクチャのみがリサンプリングされ、その結果、ピクチャキャンバスの部分のみが使用されること（例えば、ダウンサンプリングの場合）や、シーンの部分のみが捕捉されること（アップサンプリングの場合）が起こる可能性がある。いくつかの例で、Ｈ．２６３付録Ｑなどでは、各次元（例えば、上方向又は下方向）において２倍で個々のマクロブロックをリサンプリングすることが許されている。しかし、ピクチャサイズは同じままである。マクロブロックのサイズが固定され得るとき、例えば、Ｈ．２６３では、マクロブロックのサイズは通知される必要がない。

【0093】

いくつかの関連例では、予測されたピクチャでのピクチャサイズは変化することができる。ＶＰ９などの例では、ピクチャ全体の参照ピクチャリサンプリング及び解像度変更が許されている。いくつかの例（例えば、Hendry, et. al，“On adaptive resolution change (ARC) for VVC”，Joint Video Team document JVET-M0135-v1，２０１９年１月９日；その全文を本願に援用される。）では、異なる解像度（例えば、より高い解像度又はより低い解像度）への参照ピクチャ全体のリサンプリングが許されている。異なる候補解像度は、シーケンスパラメータセット（Sequence Parameter Set，ＳＰＳ）でコーディングすることができ、ピクチャパラメータセット（Picture Parameter Set，ＰＰＳ）内のピクチャごとのシンタックス要素によって参照され得る。

【0094】

本開示の態様に従って、ソースビデオは、異なる解像度などの異なる品質を持った１つ以上のレイヤを含むビットストリームにピクチャを符号化することができるレイヤードコーディングによって圧縮可能である。ビットストリームは、どのレイヤ（又はレイヤの組）がデコーダ側で出力され得るかを指定するシンタックス要素を有することができる。出力されるレイヤの組は、出力レイヤセットとして定義され得る。例えば、複数のレイヤ及びスケーラビリティをサポートするビデオコーデックにおいて、１つ以上の出力レイヤセットはビデオパラメータセット（ＶＰＳ）で通知され得る。ビットストリーム全体又は１つ以上の出力レイヤセットのプロファイル・ティア・レベル（Profile Tier Level，ＰＴＬ）を指定するシンタックス要素は、ＶＰＳ、いくつかの例ではデコーダ能力情報（Decode Capability Information，ＤＣＩ）と呼ばれることがあるデコーダパラメータセット（Decoder Parameter Set，ＤＰＳ）、ＳＰＳ、ＰＰＳ、ＳＥＩメッセージ、などで通知され得る。ＰＴＬ情報には、コーディングツール又は機能に関して制約を指定することができる一般制約情報が存在することができる。様々なコーディングツール及び機能について制約情報を効率的に表現及び通知することが望ましい。

【0095】

いくつかの例において、「サブピクチャ」という用語は、例えば、意味的にグループにまとめられて、変更された分解能で独立してコーディングされ得るサンプル、ブロック、マクロブロック、コーディングユニット、又は同様のエンティティの長方形配置を指すために使用され得る。１つ以上のサブピクチャはピクチャを形成することができる。１つ以上のコーディングされたサブピクチャは、コーディングされたピクチャを形成することができる。１つ以上のサブピクチャは、ピクチャに組み立てられ得、また、１つ以上のサブピクチャはピクチャから抽出され得る。いくつかの例では、１つ以上のコーディングされたサブピクチャは、サンプルレベルへのトランスコーディングを伴わない圧縮された領域で、コーディングされたピクチャに組み立てられ得る。いくつかの例では、１つ以上のコーディングされたサブピクチャは、圧縮された領域で、コーディングされたピクチャから抽出され得る。

【0096】

いくつかの例では、例えば、参照ピクチャリサンプリングによる、ＣＶＳ内のピクチャ又はサブピクチャの解像度の変更を許すメカニズムは、適応解像度変更（Adaptive Resolution Change，ＡＲＣ）と呼ばれ得る。適応解像度変更を実行するために使用される制御情報はＡＲＣパラメータと呼ばれ得る。ＡＲＣパラメータは、フィルタパラメータ、スケーリング係数、出力及び／又は参照ピクチャの解像度、様々な制御フラグ、及び／又はその他を含むことができる。

【0097】

いくつかの例では、ＡＲＣの符号化／復号化はピクチャの単位であり、よって、制御情報（ＡＲＣパラメータ）の組が、信号及び意味的に独立したコーディングされたビデオピクチャの符号化／復号化のために使用される。いくつかの例では、ＡＲＣの符号化／復号化はサブピクチャの単位であり、よって、ピクチャ内の複数のサブピクチャは、独立したＡＲＣパラメータで符号化／復号化され得る。ＡＲＣパラメータは様々な技術で通知することができる、ことが留意されるべきである。

【0098】

図９は、本開示のいくつかの実施形態に係るＡＲＣパラメータのシグナリング技術の例（例えば、オプション）を示す。コーディング効率、複雑性、及びアーキテクチャは例ごとに様々であることができる。ビデオコーディング標準規格又は技術は、ＡＲＣパラメータのシグナリングのために、１つ以上の例又は他の変形を選択してよい。例は、相互排他的でなくてもよく、アプリケーションニーズ、標準技術、エンコーダの選択、及び／又はその他に基づき交換されてもよい。

【0099】

本開示の態様に従って、ＡＲＣパラメータは、様々な方法で、ＡＲＣパラメータのクラスとして供給されてよい。いくつかの例では、ＡＲＣパラメータのクラスには、Ｘ次元及びＹ次元で別々の又は組み合わされたアップサンプル及び／又はダウンサンプル係数が含まれる。一例では、アップサンプル及び／又はダウンサンプル係数を含むテーブルを指すことができる１つ以上の短いシンタックス要素がコーディングされ得る。

【0100】

いくつかの例では、ＡＲＣパラメータのクラスはアップサンプル及び／又はダウンサンプル係数を含み、所与の数のピクチャに対する一定速度のズームイン及び／又はアウトを示す時間次元が加えられる。一例では、時間次元が追加されたアップサンプル及び／又はダウンサンプル係数を含むテーブルを指すことができる１つ以上の短いシンタックス要素がコーディングされ得る。

【0101】

いくつかの例では、ＡＲＣパラメータのクラスは、組み合わせて又は別々に入力ピクチャ、出力ピクチャ、参照ピクチャ、コーディングされたピクチャの、サンプル、ブロック、マクロブロック、ＣＵ、又はその他の適切な粒度でのＸ次元又はＹ次元の解像度を含む。いくつかの例では、ビデオコーディングで使用される１つよりも多い解像度（例えば、入力ピクチャのための１つの解像度、参照ピクチャのための他の解像度）が存在し、値の組（解像度の１つに対応する。）は値の他の組（解像度の他の１つに対応する。）から推測され得る。値の決定は、例えば、フラグの使用に基づき、ゲーティングされ得る。ゲーティングのためのフラグの利用については、以降の説明で詳述される。

【0102】

いくつかの例では、ＡＲＣパラメータのクラスは、上述されたように適切な粒度で、Ｈ．２６３付録Ｐで使用されるものに類似するワーピング座標を含む。Ｈ．２６３付録Ｐは、ワーピング座標をコーディングするための効率的な方法を定義している。他の効率的な方法を考案することができる。例えば、付録Ｐのワーピング座標の可変長可逆ハフマンスタイルコーディングは、適切な長さのバイナリコーディングで置換することができ、この場合、バイナリコードワードは、最大画像サイズの境界外でのワーピングを可能にするように、最大画像サイズに係数を掛けて値をオフセットすることで求められ得る。

【0103】

いくつかの例では、ＡＲＣパラメータのクラスは、アップサンプル及び／又はダウンサンプルフィルタパラメータを含む。一例では、アップサンプリング及び／又はダウンサンプリングのために単一のフィルタしか存在しない。他の例では、複数のフィルタが使用され得る。いくつかの例では、フィルタパラメータが、フィルタ設計をより柔軟にする用に通知され得る。フィルタパラメータは、可能なフィルタ設計のリストの中から、インデックスを使用することによって選択することができる。フィルタは、（例えば、適切なエントロピコーディング技術を使用して、フィルタ係数のリストを指定することによって）完全に指定されても、フィルタは、上記のメカニズムのいずれかに従って通知されるアップサンプル及び／又はダウンサンプル比により暗黙的に選択されても、かつ／あるいは、別なふうに指定／選択されてもよい。

【0104】

以下の記載では、アップサンプル及び／又はダウンサンプル係数の有限な組（Ｘ次元及びＹ次元の両方で使用される同じ係数）が、コードワードによるＡＲＣパラメータのシグナリングを説明するために使用される。いくつかの例では、コードワードは、例えば、ビデオコーディング規格（例えば、Ｈ．２６４及びＨ．２６５）において特定のシンタックス要素にＥｘｔ－Ｇｏｌｏｍｂコードを用いて、可変長コーディングされ得る。

【0105】

図１０は、アップサンプル又はダウンサンプル係数、コードワード、及びＥｘｔ－Ｇｏｌｏｍｂコードのマッピングについてのテーブル（１０００）の例を示す。

【0106】

他の類似したテーブルが、ビデオ圧縮技術又は標準規格で利用可能なアップスケール及びダウンスケールメカニズムの適用及び能力に従って導出され得る、ことが留意されるべきである。いくつかの例では、テーブル１は、追加の値に適切に拡張され得る。値は、例えば、バイナリコーディングを使用することによって、Ｅｘｔ－Ｇｏｌｏｍｂコード以外のエントロピコーディングメカニズムによって表されてもよい、ことが留意されるべきである。一例では、Ｅｘｔ－Ｇｏｌｏｍｂコード以外のエントロピコーディングメカニズムは、リサンプリング係数が、例えば、メディア認識ネットワーク要素（Media-Aware Network Element(s)，ＭＡＮＥ）にとって、ビデオ処理エンジン（例えば、エンコーダ及びデコーダ）の外部で重要である場合に、特定の利点があり得る。いくつかの例では、解像度変更が不要である場合に（例えば、元の／目標の解像度がテーブル１中で１である。）、短いＥｘｔ－Ｇｏｌｏｍｂコード（例えば、テーブル１に示される単一ビットのみ）が選択され得る。これは、例えば、最も一般的なケースでバイナリコードを使用するよりも、コーディング効率の利点があり得る。

【0107】

本開示の態様に従って、テーブル１などのマッピングテーブルが構成可能である。例えば、テーブル１中のエントリの数及び対応するセマンティクスは完全に又は部分的に構成可能である。いくつかの例では、マッピングテーブルの基本アウトラインは、ＳＰＳ又はＤＰＳなどの高位パラメータセットで運ばれる。代替的に、又は追加的に、いくつかの例では、テーブル１に類似した１つ以上のテーブルがビデオコーディング技術又は標準規格で定義されてもよく、テーブルの１つは、例えば、ＳＰＳ又はＤＰＳにより、選択されてよい。

【0108】

上述されたようにコーディングされるアップサンプル又はダウンサンプル係数などのＡＲＣ情報がビデオコーディング技術又は標準規格シンタックスに含まれてもよい。１つ以上のコードワードが、アップサンプル又はダウンサンプル係数などのＡＲＣ情報の他のクラスを制御するために使用され得る、ことが留意されるべきである。いくつかの例では、非常に大量のデータが、フィルタ又は他のデータ構造に必要とされる。

【0109】

図９を参照すると、Ｈ．２６３付録Ｐなどの例（９１０）において、ＡＲＣ情報（９１２）は、４つのワーピング座標の形をとることができ、Ｈ．２６３ ＰＬＵＳＰＴＹＰＥ（９１３）ヘッダ拡張などのピクチャヘッダに含まれる。例（９１０）は、ｉ）ピクチャヘッダが利用であり、ｉｉ）ＡＲＣ情報の頻繁な変更が予想されるときに、適用され得る。しかし、例えば例（９１０）に示されるような、Ｈ．２６３－スタイルシグナリングを使用するときにオーバーヘッドは高くなる可能性があり、スケーリング係数は、ピクチャヘッダが一時的な性質の者であり得るために、ピクチャ境界の間で適用できない可能性がある。

【0110】

図９を参照すると、ＪＶＣＥＴ－Ｍ１３５－ｖ１などの例（９２０）では、ＡＲＣ参照情報（９２５）（例えば、インデックス）がＰＰＳ（９２４）に置かれ、目標の解像度（例えば、解像度１～３）を含むテーブル（つまり、目標解像度テーブル）（９２６）を指すことができる。一例では、テーブル（９２６）はＳＰＳ（９２７）に位置する。ＳＰＳ（９２７）内のテーブル（９２６）に目標解像度を置くことは、能力交換中の相互運用性ネゴシエーションポイントとしてＳＰＳを使用することによって正当化され得る。解像度は、適切なＰＰＳ（９２４）内の参照（例えば、ＡＲＣ参照情報（９２５））によってピクチャごとにテーブル（９２６）内の値の限られた組（例えば、解像度１～３）の中で変化し得る。

【0111】

図９は、ビデオビットストリームでＡＲＣ情報を運ぶために使用され得る例（９３０）、（９４０）及び（９５０）などの追加技術も示す。技術は、同じビデオコーディング技術又は標準規格において、個別的に使用されてもよく、あるいは、適切な組み合わせで使用することができる。

【0112】

図９を参照すると、例（９３０）において、リサンプリング係数（又はズーム係数）などのＡＲＣ情報（９３９）は、スライスヘッダ、ＧＯＢヘッダ、タイルヘッダ、タイルグループヘッダ、などのヘッダに存在してよい。例えば、図９では、タイルグループヘッダ（９３８）が表されている。例（９３０）によって表されている技術は、ＡＲＣ情報（９３９）が、数ビットの固定長コードワード又は単一の可変長ｕｅ（ｖ）などの少数のビットデコーディングされ得る場合に、使用することができる。

【0113】

本開示の態様に従って、ヘッダ（例えば、図９のタイルグループヘッダ（９３８）、スライスヘッダ、又はタイルヘッダ）で直接にＡＲＣ情報（９３９）を有することは、ＡＲＣ情報（９３９）が、ピクチャ全体ではなく、例えば、対応するタイルグループ（又はスライス、タイル）によって表示されるサブピクチャに適用可能である点で、更なる利点を有することができる。更に、一例では、たとえビデオ圧縮技術又は標準規格がピクチャ全体の適応解像度の変更しか想定していないとしても（例えば、タイル
グループに基づく適応解像度の変更とは対照的に）、例（９３０）は、誤り耐性の視点から、例（９１０）と比べて特定の利点を有することができる。

【0114】

図９を参照すると、例（９４０）において、ＡＲＣ情報（９４２）は、ＰＰＳ、ヘッダパラメータセット、タイルパラメータセット、適応パラメータセット（Adaptation Parameter Set，ＡＰＳ）などのようなパラメータセット（９４１）に存在してよい。例えば、図９では、ＡＰＳ（９４１）が表されている。いくつかの例で、パラメータセット（９４１）の範囲は、ピクチャよりも大きくなくてもよく、例えば、ピクチャ、タイルグループなどであることができる。ＡＲＣ情報（例えば、ＡＲＣ情報（９４２））の使用は、関連するパラメータセット（例えば、ＡＰＳ（９４１））の活性化により暗示的であることができる。例えば、ビデオコーディング技術又は標準規格がピクチャベースのＡＲＣしか企図していない場合に、ＰＰＣ又は同等物が適切であり得る。

【0115】

図９を参照すると、例（９５０）において、ＡＲＣ参照情報（９５３）は、上述されたように、タイルグループヘッダ（９５４）又は類似したデータ構造（例えば、ピクチャヘッダ、スライスヘッダ、タイルヘッダ、又はＧＯＰヘッダ）に存在してよい。図９では、タイルグループヘッダ（９５４）が一例として表されている。ＡＲＣ参照情報（９５３）は、単一のピクチャを超えた範囲を有するパラメータセット（９５６）、例えば、ＳＰＳ、ＤＰＳ、などで利用可能なＡＲＣ情報のサブセット（９５５）を参照することができる。図９では、ＳＰＳ（９５６）が一例として表されている。

【0116】

図１１は、本開示のいくつかの実施形態に係るＡＲＣパラメータシグナリングのいくつかの例を示す。図１１は、ビデオコーディング標準規格で使用されるシンタックスダイアグラム例を示す。一例では、シンタックスダイアグラムの表記は、Ｃ型プログラミングにほぼ従う。太字体の行は、ビットストリームに存在するシンタックス要素を示すことができ、太字体ではない行は、制御フロー又は変数の設定を示すことができる。

【0117】

図１１を参照すると、タイルグループヘッダ（１１０１）は、ピクチャの一部（例えば、長方形部分）に適用可能なヘッダのシンタックス構造を含む。一例では、タイルグループヘッダ（１１０１）は、可変長の、Ｅｘｔ－Ｇｏｌｏｍｂコーディングされたシンタックス要素ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ（１１０２）（太字体で表記）を条件付きで含むことができる。タイルグループヘッダ（１１０１）でのシンタックス要素（例えば、ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ（１１０２））の存在は、例えば、フラグ（例えば、ａｄａｐｔｉｖｅ＿ｐｉｃ＿ｒｅｓｏｌｕｔｉｏｎ＿ｃｈａｎｇｅ＿ｆｌａｇ）（１１０３）によって表現される適応解像度に基づき、ゲーティングされ得る。フラグ（例えば、ａｄａｐｔｉｖｅ＿ｐｉｃ＿ｒｅｓｏｌｕｔｉｏｎ＿ｃｈａｎｇｅ＿ｆｌａｇ）（１１０３）の値は太字体で表されておらず、よって、フラグは、フラグがシンタックスダイアグラムで現れるポイントでビットストリームに存在する。適応解像度がピクチャ又はピクチャの部分に使用中であるかどうかは、ビットストリームの中又は外で高位シンタックス構造（例えば、図１１のＳＰＳ（１１１０））で通知され得る。

【0118】

図１１を参照ると、ＳＰＳ（１１１０）の抜粋が示されている。ＳＰＳ（１１１０）は、フラグ（１１１１）（例えば、ａｄａｐｔｉｖｅ＿ｐｉｃ＿ｒｅｓｏｌｕｔｉｏｎ＿ｃｈａｎｇｅ＿ｆｌａｇ）である第１シンタックス要素（１１１１）を含む。フラグ（１１１１）が真であるとき、フラグ（１１１１）は、特定の制御情報を必要とし得る適応解像度の使用を示すことができる。一例では、特定の制御情報は、ＳＰＳ（１１１０）及びタイルグループヘッダ（１１０１）においてｉｆ（）文によって示されるように、フラグ（１１１１）の値に基づき条件付きで存在する。

【0119】

図１１の例で示されるように、適応解像度が使用中であるとき、サンプルの単位での出力解像度（又は出力ピクチャの解像度）（１１１３）はコーディングされる。一例では、出力解像度（１１１３）は、幅分解能（例えば、ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）及び高さ分解能（例えば、ｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）に基づきコーディングされる。ビデオコーディング技術又は標準規格では、出力解像度（１１１３）の値への特定の制限が定義される場合がある。例えば、レベル定義は、全部の出力サンプルの数を制限し得る（例えば、ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓとｏｕｔｐｕｔ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓとの積）。いくつかの例では、ビデオコーディング技術又は標準規格、あるいは、外部技術又は標準規格（例えば、システム標準）は、幅分解能及び／又は高さ分解能の番号付け範囲（例えば、幅分解能及び／又は高さ分解能は、２の累乗で割り切れる。）、高さ分解能に対する幅分解能のアスペクト比（例えば、高さ分解能に対する幅分解能の比は４：３又は１６：９である。）、などを制限することができる。一例では、上記の制限は、ハードウェア実施を容易にするために導入されてもよい。

【0120】

特定のアプリケーションでは、エンコーダは、サイズが出力ピクチャサイズであると暗黙的に仮定するのではなく、特定の参照ピクチャサイズを使用するようにデコーダに命じることができる。例えば、シンタックス要素（例えば、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｓｉｚｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ）（１１１４）は、参照ピクチャ次元（１１１５）の条件付きの存在をゲーティングする。参照ピクチャ次元（１１１５）は、一例では、幅（例えば、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）及び高さ（例えば、ｒｅｆｅｒｅｎｃｅ＿ｐｉｃ＿ｈｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）の両方を含むことができる。

【0121】

また図１１では、適用可能な復号化ピクチャ幅及び高さのテーブルが表されている。一例では、テーブル内の入力の数は、テーブル指示（例えば、シンタックス要素ｎｕｍ＿ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＿ｍｉｎｕｓ１）（１１１６）によって表現され得る。「ｍｉｎｕｓ１」は、シンタックス要素（１１１６）の値の解釈を参照することができる。例えば、コーディングされた値がゼロである場合に、１つのテーブル入力が存在する。コーディングされた値が５である場合に、６つのテーブル入力が存在する。テーブル内の入力ごとに、復号されたピクチャ幅及び高さがシンタックス要素（１１１７）として含まれる。

【0122】

シンタックス要素（１１１７）によって表されるテーブル入力は、タイルグループヘッダ（１１０１）内のシンタックス要素ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ（１１０２）を用いてインデックス付けすることができるので、タイルグループごとに異なる復号化サイズ及びズーム係数を可能にする。

【0123】

本開示の態様に従って、特定のビデオコーディング技術又は標準規格（例えば、ＶＰ９）は、時間スケーラビリティと併せて、特定の形式の参照ピクチャリサンプリングを実施することによって空間スケーラビリティを可能にすることができる。実施形態において、参照ピクチャは、空間エンハンスメントレイヤのベースを形成するよう、より高い解像度へとＡＲＣスタイル技術を用いてアップサンプリングされる。アップサンプリングされたピクチャは、通常の予測メカニズム（例えば、参照ピクチャからのインター予測のための動き補償予測）を使用して、例えば詳細を追加するために高解像度で精緻化され得る。

【0124】

いくつかの例では、ネットワーク抽象化レイヤ（Network Abstraction Layer，ＮＡＬ）ユニットヘッダ内の値、例えば、時間ＩＤフィールドは、時間レイヤ情報とともに空間レイヤ情報も示すために使用される。時間レイヤ情報及び空間レイヤ情報の両方を示すためにＮＡＬユニットヘッダ内の値を使用することは、変更なしでスケーラブル環境に対して既存の選択された転送ユニット（Selected Forwarding Units，ＳＦＵ）の使用を可能にすることができる。例えば、既存のＳＦＵは、ＮＡＬユニットヘッダの時間ＩＤ値に基づき、選択された時間レイヤの転送用に作成及び最適化され得る。次いで、既存のＳＦＵは、いくつかの例では変更なしで空間スケーラビリティ（例えば、空間レイヤの選択）のために使用することができる。いくつかの例では、コーディングされたピクチャと、ＮＡＬユニットヘッダの時間ＩＤ値内の時間ＩＤフィールドによって示される時間レイヤとの間に、マッピングが与えられ得る。

【0125】

本開示の態様に従って、コーディングされたビットストリームのいくつかの特徴は、プロファイル、ティア、レベル、及び一般制約情報を含むプロファイル、ティア、及びレベルの組み合わせ（ＰＴＬ）情報を用いて指定され得る。いくつかの例では、プロファイルは、色再現、解像度、追加のビデオ圧縮、などのようなビットストリームの特徴のサブセットを定義する。ビデオコーデックは、ベースライン（baseline）プロファイル（例えば、低圧縮比率による簡単なプロファイル）、ハイ（high）プロファイル（高圧縮比率による複雑なプロファイル）、メイン（main）プロファイル（例えば、ベースラインプロファイルとハイプロファイルとの間の中間圧縮比率によるプロファイルはデフォルトのプロファイル設定であることができる。）、などのような様々なプロファイルを定義することができる。

【0126】

更に、ティア及びレベルは、最大ビットレート、最大ルーマサンプルレート、最大ルーマピクチャサイズ、最小圧縮比、許されるスライスの最大数、許されるタイルの最大数、などに関してビットストリームを定義する特定の制約を指定するために使用され得る。より低いティアは、より高いティアよりも制約が多く、より低いレベルは、より高いレベルよりも制約が多い。一例では、標準規格は２つのティア：メイン（Ｍａｉｎ）及びハイ（Ｈｉｇｈ）を定義してよい。ＭａｉｎティアはＨｉｇｈティアよりも低いティアである。ティアは、それらの最大ビットレートに関して異なっているアプリケーションを扱うよう作られる。Ｍａｉｎティアは、ほとんどのアプリケーションのために設計され、一方、Ｈｉｇｈティアは、一例では、非常に要求の厳しいアプリケーションのために設計される。標準規格は複数のレベルを定義することができるレベルは、ビットストリームのための制約の組である。一例では、レベル４よりも下のレベルについては、Ｍａｉｎティアのみが許される。いくつかの例では、所与のティア／レベルに従うデコーダは、そのティア／レベル及びより低い全てのティア／レベルについて符号化されている全てのビットストリームを復号することができることを求められる。

【0127】

一般制約情報には、ビデオソースタイプ、コーディングツール及び機能に関する制約情報が含まれ得る。例えば、制約フラグは、インターコーディングツール、イントラコーディングツール、ＤＢＦ、エントロピコーディング、変換、パーティショニング（例えば、タイル、スライス）、バッファ管理、ランダムアクセス（例えば、ＩＤＲ）、パラメータセット（例えば、ＳＰＳ、ＰＰＳ）、及び／又は同様のものがコーディングされたビデオビットストリームに存在しているか又は使用されているかどうかを示すことができる。制約情報は、パラメータセット（例えば、ＳＰＳ、ＶＰＳ、又はＤＣＩ）で通知することができる。制約フラグは、高位シンタックス構造（例えば、ＳＰＳ、ＶＰＳ、ＤＣＩ）で通知することができる。

【0128】

本開示のいくつかの実施形態に従って、ＰＴＬ情報は範囲（例えば、ビットストリーム内のコーディングされたビデオデータの部分）に関連することができる。いくつかの例では、ＰＴＬ情報は、例えば、ビットストリーム全体、ビットストリームのＣＶＳ、ビットストリームの各出力レイヤセット（ＯＬＳ）、及び／又は同様のものに対して規定され得、ＶＰＳ、ＤＰＳ、ＤＣＩ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ＧＯＰ、シーケンス、ヘッダ、ＳＥＩメッセージ、などのような高位シンタックス（High-Level Syntax，ＨＬＳ）構造で通知することができる。

【0129】

いくつかの例では、高位シンタックス（ＨＬＳ）は、ブロックレベルに関して定義される。ブロックレベルのコーディングツールは、ピクチャ内のピクセル又はサンプルを復号してピクチャを再構成するために使用することができる。ブロックレベルのコーディングツールは、インター予測用のコーディングツール（つまり、インターコーディングツール）、イントラ予測用のコーディングツール（つまり、イントラコーディングツール）、適応ループフィルタ（ＡＬＦ）、デブロッキングフィルタ（DeBlocking Filter，ＤＢＦ）、エントロピコーディング、変換、などのような、コーディングブロックの再構成に使用される如何なる適切なコーディングツールも含むことができる。

【0130】

高位シンタックス（ＨＬＳ）は、ツール及びバッファ制御の機能、システムインターフェース、ピクチャレベルの制御、などに関する情報を規定することができる。例えば、ＨＬＳは、パーティション（例えば、タイル、スライス、サブピクチャ）、バッファ管理、ランダムアクセス（例えば、ＩＤＲ、クリーンランダムアクセス（Clean Random Access，ＣＲＡ））、パラメータセット（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ）、参照ピクチャリサンプリング（Reference Picture Resampling（ＰＲＰ））、スケーラビリティ、及び／又は同様のものを規定することができる。高位レベルシンタックスは、ブロックレベルよりも上であることができる。

【0131】

制御情報は、ＳＰＳレベルのツール制御情報、ＰＰＳレベルのツール制御情報、シーケンスレベルの制御情報、ビットストリームレベルの制御情報、及び／又は同様のものなどの適切なレベルを有することができる。いくつかの例では、ＰＴＬ情報は、制御情報の部分であり、ＨＬＳ構造で制約フラグとして通知することができ、ＨＬＳ構造に対応する範囲においてツールの制御又は制約を示すことができる。例えば、ＰＴＬ情報用の制約フラグは、シーケンスレベルの制御情報及びビットストリームレベルの制御情報のうちの1つで供給され得る。一例では、特定のツールがＨＬＳ構造で制約フラグによって無効にされる場合には、ツールは、例えば、ＨＬＳに対応する範囲でブロックをコーディングするためには、使用されない。

【0132】

図１２及び図１３は、本開示のいくつかの実施形態に係るＰＴＬ情報の例を示す。図１２は、ＰＴＬシンタックス要素の組のシンタックス構造例（１２００）を示し、図１２は、一般制約情報のシンタックス構造例（１３００）を示す。

【0133】

図１２で、ＰＴＬシンタックス要素の組は、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ、ｎｕｍ＿ｓｕｂ＿ｐｒｏｆｉｌｅｓ、ｇｅｎｅｒａｌ＿ｓｕｂ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｓｕｂｌａｙｅｒ＿ｌｅｖｅｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｐｔｌ＿ａｌｉｇｎｍｅｎｔ＿ｚｅｒｏ＿ｂｉｔ、及びｓｕｂｌａｙｅｒ＿ｌｅｖｅｌ＿ｉｄｃを含むことができる。

【0134】

図１３で、一般制約情報は複数の制約フラグを含むことができる。一例では、１に等しい制約フラグ（例えば、ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）は、パラメータｓｈ＿ｓｌｉｃｅ＿ｔｙｐｅがＩ（すなわち、イントラスライスであるスライス）であるべきことを示す。パラメータｓｈ＿ｓｌｉｃｅ＿ｔｙｐｅは、タイプＩとＰとＢとの間でスライスのコーディングタイプを規定するスライスヘッダ内のパラメータである。０に等しい制約フラグ（例えば、ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０５）は、ＰＴＬ情報の範囲内の全てのコーディングされたピクチャに対して制約（例えば、ｓｈ＿ｓｌｉｃｅ＿ｔｙｐｅはＩでなければならない。）を課さず、このとき、他の情報（例えば、ｐｒｏｆｉｌｅ＿ｉｄｃ）は非イントラスライスを許すことができる。他の例では、１に等しい制約フラグ（例えば、ｎｏ＿ａｌｆ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０６）は、ｓｐｓ＿ａｌｆ＿ｅｎａｂｌｅｄ＿ｆｌａｇがＰＴＬ情報の範囲内の全てのＣＶＳに対して０に等しいことを示すことができ、よって、適応ループフィルタリングは、たとえ適応ループフィルタリングが、例えば、ｐｒｏｆｉｌｅ＿ｉｄｃに基づき、許されるとしても、使用されない。０に等しい制約フラグ（例えば、ｎｏ－ａｌｆ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０６）は、上記の制約を課さない。

【0135】

他の例では、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｌｅｓｓ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０１）は、図１３に示されるように、汎用制約情報で通知することができる。１に等しい制約フラグ（例えば、ｎｏ＿ｌｏｓｓｌｅｓｓ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０１）は、可逆コーディングに関係があるコーディングツールが、制約フラグ（１３０１）を含むＰＴＬ情報の範囲内で使用不可であることを示すことができる。０に等しい制約フラグ（例えば、ｎｏ＿ｌｏｓｓｌｅｓｓ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０１）は、上記の制約を課さない。

【0136】

他の例では、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｙ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０２）は、図１３に示されるように、汎用制約情報で通知することができる。１に等しい制約フラグ（例えば、ｎｏ＿ｌｏｓｓｙ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０２）は、不可逆コーディングに関係があるコーディングツールが、制約フラグ（１３０２）を含むＰＴＬ情報の範囲内で使用不可であることを示すことができる。０に等しい制約フラグ（例えば、ｎｏ＿ｌｏｓｓｙ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０２）は、上記の制約を課さない。

【0137】

実施形態において、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｌｅｓｓ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０１）は、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｙ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０２）が１に等しいときに１に等しくなくてもよい。代替的に、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｙ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）（１３０２）が、制約フラグ（例えば、ｎｏ＿ｌｏｓｓｌｅｓｓ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）（１３０１）が１に等しいときには１に等しくなくてもよい。

【0138】

汎用制約情報内の複数の制約フラグは、特定の順序でソートされ得る。順序は、例えば、各々のメカニズム及び／又はツールがＰＴＬの範囲において使用されない可能性に基づき、セットされ得る。順序は優先順序と呼ばれ得る。順序は、汎用制約情報シンタックス構造において高い優先度から低い優先度まで与えられ得、このとき、高い優先度は、ツール（又はメカニズム）の不使用は尤度が高いことを示し、低い優先度は、ツール（又はメカニズムの不使用）の不使用は尤度が低いことを示す。順序に影響を及ぼす付加的に因子には、ツールが特定の使用ケースにのみ使用される可能性が高いこと（例えば、サブピクチャ、スケーラビリティ、及び／又はインターレースサポート）、エンコーダ／デコーダ／実施複雑性に対するツールの影響、などが含まれ得る。

【0139】

図１４Ａ～１４Ｂは、本開示のいくつかの実施形態に係る、ＰＴＬシンタックス構造（ＰＴＬブラケットとも呼ばれる。）のシンタックス構造例（１４１０）及び汎用制約情報シンタックス構造（汎用制約情報ブラケットとも呼ばれる。）のシンタックス構造例（１４２０）を含むＰＴＬ情報の例を示す。いくつかの例では、制約フラグの数を示すシンタックス要素（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）が通知され得る。一例では、制約フラグの数を示すシンタックス要素は、例えば、汎用制約情報ブラケットのシンタックス例（１４２０）の外にあることができる図１４Ａに示されたシンタックス例（１４１０）内の（１４０１）によって示されるような、ＰＴＬシンタックス構造で通知することができる。代替的に、制約フラグの数を示すシンタックス要素は、シンタックス要素（１４２０）の最初などの、汎用制約情報ブラケットの最初に通知することができる。シンタックス要素（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）が存在し、シンタックス要素の数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）がＮに等しい場合に、最初のＮ個の制約フラグは汎用制約情報シンタックス構造に存在してよい。更に、他の制約フラグは、存在しなくてもよく、特定の値に等しいと推測され得る。Ｎは非負整数であることができる。

【0140】

実施形態において、値Ｎ（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）は、０から制約フラグの最大数（例えば、パラメータＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ）までの範囲内にある。制約フラグの最大数は任意の正整数であることができる。制約フラグの最大数（例えば、ＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ）の値は、１６、３２、６４、１２８、などであるよう予め定義され得る。値Ｎ（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）が０に等しい場合に、制約フラグは汎用制約情報シンタックス構造に存在しない。値Ｎ（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇ）のコーディングは、値Ｎ及び制約フラグの対応するエントロピコーディング表現がバイトアライメントを確かにするよう８で割りきれる数まで合計され得るように、選択され得る。

【0141】

いくつかの例では、制約フラグは、１つ以上の制約情報グループに分類され得る。各制約情報グループは、１つ以上の制約フラグを含むことができ、対応するゲートフラグを有することができる。対応する制約情報グループのゲートフラグは、対応する制約情報グループ内の制約フラグが存在する可能性があるかどうかを示すことができる。一例では、ゲートフラグは、制約グループ存在フラグと呼ばれ得る。一般に、ゲートフラグは、対応する制約情報グループに関連し、対応する制約情報グループ内の制約フラグに関連する。実施形態において、ゲートフラグは、対応する制約情報グループ内の制約フラグが制約情報に存在する（又は通知される）かどうかをゲーティングする。例えば、対応する制約情報グループのゲートフラグが１に等しい場合に、制約情報グループに対応する制約フラグは、例えば、汎用制約情報において、存在することができる。対応する制約情報グループのゲートフラグが０に等しい場合には、制約情報グループに対応する制約フラグは、例えば、汎用制約情報において、存在しなくてもよい。一例では、全てのゲートフラグが０に等しい場合に、制約フラグは存在しない。

【0142】

制約フラグは異なる範囲を有することができる。例えば、ＤＣＩ内の制約フラグの範囲は、コーディングされたビデオビットストリームであることができる。ＶＰＳ内の制約フラグの範囲は、複数のレイヤを有するＣＬＶＳであることができる。ＳＰＳ内の制約フラグの範囲は、単一ＣＬＶＳであることができる。

【0143】

図１５Ａ～１５Ｂは、本開示の実施形態に係る汎用制約情報シンタックス構造（１５００）の一例を示す。汎用制約情報シンタックス構造（１５００）は、汎用制約情報を表すフラグを含む。具体的に、汎用制約情報シンタックス構造（１５００）は、図１５Ａのゲートフラグ（例えば、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｓｔｒｕｃｔｕｒｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０１）、ゲートフラグ（例えば、ｈｉｇｈ＿ｌｅｖｅｌ＿ｆｕｎｃｔｉｏｎａｌｉｔｙ＿ｃｏｎｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０２）、ゲートフラグ（例えば、ｓｃａｌａｂｉｌｉｔｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０３）、ゲートフラグ（例えば、ｐａｒｔｉｔｉｏｎｉｎｇ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０４）、ゲートフラグ（例えば、ｉｎｔｒａ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０５）、ゲートフラグ（例えば、ｉｎｔｅｒ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０６）、ゲートフラグ（例えば、ｔｒａｎｓｆｏｒｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０７）、ゲートフラグ（例えば、ｉｎｌｏｏｐ＿ｆｉｌｔｅｒｉｎｇ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０８）などのような１つ以上のゲートフラグを含む。１つ以上のゲートフラグ（例えば、ゲートフラグ（１５０１）～（１５０８））は、図１５Ａに示されるように、汎用制約情報シンタックス構造（１５００）の最初に存在することができる。

【0144】

ゲートフラグ（例えば、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｓｔｒｕｃｔｕｒｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０１）は、制約情報グループ（１５１０）に関連し、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）に関連する。１に等しいゲートフラグ（例えば、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｓｔｒｕｃｔｕｒｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０１）は、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）が存在してもよいことを規定することができる。

【0145】

制約情報グループ（１５１０）（又は制約フラグ（１５１１）～（１５１４））は、入力ソース及びフレームパッキング（例えば、パッキング又は投影されたフレーム）に関係があることができる。図１５Ａを参照すると、制約フラグ（１５１１）～（１５１４）は、ｇｅｎｅｒａｌ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ（１５１１）、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ（１５１２）、ｇｅｎｅｒａｌ＿ｎｏｎ＿ｐｒｏｊｅｃｔｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ（１５１３）、及びｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ（１５１４）に対応する。さもなければ、０に等しいゲートフラグ（例えば、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｓｔｒｕｃｔｕｒｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０１）は、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）が汎用制約情報シンタックス構造（１５００）に存在しなくてもよいことを規定することができる。

【0146】

更に、いくつかの例では、１に等しいゲートフラグ（例えば、ｈｉｇｈ＿ｌｅｖｅｌ＿ｆｕｎｃｔｉｏｎａｌｉｔｙ＿ｃｏｎｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０２）は、制約情報グループ（１５２０）内にある高位機能（例えば、参照ピクチャリサンプリング）に関する制約フラグが図１５Ｂによって示されるように存在してもよいことを規定することができる。さもなければ、０に等しいゲートフラグ（例えば、ｈｉｇｈ＿ｌｅｖｅｌ＿ｆｕｎｃｔｉｏｎａｌｉｔｙ＿ｃｏｎｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０２）は、制約情報グループ（１５２０）内にある制約フラグが汎用制約情報シンタックス構造（１５００）に存在しなくてもよいことを規定することができる。

【0147】

図１５Ａを参照し直すと、１に等しいゲートフラグ（例えば、ｓｃａｌａｂｉｌｉｔｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０３）は、スケーラビリティ（例えば、インターレイヤ予測）に関する制約フラグが存在してもよいことを規定することができる。さもなければ、スケーラビリティに関する制約フラグは、汎用制約情報シンタックス構造（１５００）に存在しなくてもよい。

【0148】

１に等しいゲートフラグ（例えば、ｐａｒｔｉｔｉｏｎｉｎｇ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０４）は、高位パーティショニング（例えば、サブピクチャ又はタイル）に関する制約フラグが存在してもよいことを規定することができる。さもなければ、高位パーティショニングに関する制約フラグは、汎用制約情報シンタックス構造（１５００）に存在しなくてもよい。

【0149】

１に等しいゲートフラグ（例えば、ｉｎｔｒａ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０５）は、イントラコーディング（例えば、イントラ予測）に関する制約フラグが存在してもよいことを規定することができる。さもなければ、イントラコーディングに関する制約フラグは、汎用制約情報シンタックス構造（１５００）に存在しなくてもよい。

【0150】

１に等しいゲートフラグ（例えば、ｉｎｔｅｒ＿ｃｏｄｉｎｇ＿ｔｏｏｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０６）は、インターコーディング（例えば、インターピクチャ予測のための動き補償）に関する制約フラグが存在してもよいことを規定することができる。さもなければ、インターコーディングに関する制約フラグは、汎用制約情報シンタックス構造（１５００）に存在しなくてもよい。

【0151】

１に等しいゲートフラグ（例えば、ｔｒａｎｓｆｏｒｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｇｒｏｕｐ＿ｆｌａｇ）（１５０７）は、変換コーディング（例えば、多重変換行列）に関する制約フラグが存在してもよいことを規定することができる。さもなければ、変換コーディングに関する制約フラグは、汎用制約情報シンタックス構造（１５００）に存在しなくてもよい。

【0152】

実施形態において、全てのゲートフラグ（例えば、図１５Ａのゲートフラグ（１５０１）～（１５０８））が０に等しい場合に、制約フラグは汎用制約情報シンタックス構造（例えば、汎用制約情報シンタックス構造（１５００））に存在しない。

【0153】

本開示の態様に従って、シンタックスは、ゲートフラグ（例えば、ゲートフラグ（１５０１）～（１５０８））、関連する制約フラグ（例えば、制約フラグ（１５１１）～（１５１２）及び制約情報グループ（１５２０）内の制約フラグ）、追加制御情報、及び／又は同様のものを含む制御情報がバイトアライメントされ得るように設計することができ、例えば、フラグの数は、バイトアライメントを保つために８で割りきれる。一例では、制約情報（例えば、汎用制約情報シンタックス構造（１５００））内のゲートフラグ及び制約フラグの数は８で割りきれる。バイトアライメントメカニズムは、制御情報のバイトアライメントを達成するために使用され得る。図１５Ｂを参照すると、シンタックス（例えば、ｗｈｉｌｅループ）（１５３０）がバイトアライメントのために使用され得る。

【0154】

いくつかの実施形態で、オフセット（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［］を使用する。）などのオフセット情報、及び長さ（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［］）などの長さ情報が、制約情報内のゲートフラグに関連した各々の制約情報グループで制約フラグを示すのを助けるよう、制約情報に（例えば、汎用制約情報シンタックス構造の最初に）存在する。実施形態において、少なくとも１つの制約情報グループのうちの１つ以上は、コーディングされたビデオビットストリームに存在する。制約情報グループの場合に、オフセット及び長さは、制約情報グループのための制約情報に存在することができる。オフセットは、制約情報グループ内の第１制約フラグへのオフセットを示すことができ、長さは、制約情報グループ内の制約フラグの数を示すことができる。いくつかの例で、制約情報グループの数は、例えば、シンタックス要素ｎｕｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｓｅｔによって、明示的に指示することができる。ｎｕｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｓｅｔの値は、０以上の整数であることができる。ｎｕｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｓｅｔの値が０であるとき、ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［］、ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［］、及び制約フラグは汎用制約情報シンタックス構造に存在しない。

【0155】

実施形態において、制約情報オフセット（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［ｉ］）及び制約情報長さ（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［ｉ］）は、制約情報（例えば、汎用制約情報シンタックス構造）で制約情報グループｉ（ｉは正整数である。）のための制約フラグを示すのを助けることができる。一例では、制約情報オフセット（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［ｉ］）の値が５に等しく、制約情報長さ（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［ｉ］）の値が３に等しいとき、５番目、６番目及び７番目の制約フラグが制約情報グループｉに関連し、制約情報（例えば、汎用制約情報シンタックス構造）に存在する。

【0156】

一例では、ランレングス（run-length）コーディングが、所定の順序（又は所与の順序）で規定される制約フラグをコーディングするために使用され得る。

【0157】

実施形態において、ランコーディング（run-coding）が使用されてもよく、このとき、制約フラグは所定の順序（又は所与の順序）で規定される。制約フラグを直接コーディングする代わりに、“スキップ”値の適切にコーディングされたリストが、ゼロに等しい制約フラグを示すことができ、続く制約フラグは１に等しいことが暗示される。上記のランコーディングは、（ｉ）制約フラグの数が多く、（ｉｉ）制約フラグのごく一部が１に等しい場合に特に有効であり得る。

【0158】

実施形態において、少なくとも１つの制約情報グループのうちの１つ以上は、コーディングされたビデオビットストリームに存在する。少なくとも１つの制約情報グループのうちの１つ以上における複数の制約フラグは、所定の順序に従って通知される。従って、複数の制約フラグはランコーディング（例えば、ラン符号化又はラン復号化）され得る。更に、コーディングブロックのサブセットのための予測情報が複数の制約フラグに基づき決定され得る。

【0159】

実施形態において、ゲートフラグの制約情報グループ内の少なくとも１つの制約フラグは、所定の順序に従って通知された複数の制約フラグを含む。従って、複数の制約フラグはランコーディング（例えば、ラン符号化又はラン復号化）され得る。

【0160】

実施形態において、制約フラグの全リストは、ビデオコーディング標準規格（例えば、ＶＶＣ仕様）、外部テーブル、などで規定され得る。一例では、制約フラグの利用可能な制約フラグのみが、例えば、次の：利用可能な制約フラグの数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓ）、ゲートフラグ（又は制約グループ存在フラグ）、制約情報オフセット情報及び制約情報長さ情報、などのうちの１つ以上によって示され、コーディングされたビデオストリームに存在する。

【0161】

一例では、制約フラグの全リストが規定され、エンコーダ及びデコーダに利用可能である。制約フラグの全リストはデコーダに記憶され得る。制約フラグの全リストは１００個の制約フラグを含むことができる。１００個の制約フラグのうちの１０個は、ＣＬＶＳのための制約情報に存在し、よって、ＣＬＶＳ内のコーディングブロックのサブセットに利用可能である。１００個の制約フラグのうちの１０個は、１０個の利用可能な制約フラグと呼ばれる。一例では、利用可能な制約フラグの数（例えば、１０）が通知される。一例では、１０個の利用可能な制約フラグは２つの制約情報グループにあり、第１ゲートフラグ及び第２ゲートフラグによってゲーティングされる。よって、第１ゲートフラグ及び第２ゲートフラグは、１０個の利用可能な制約フラグを示すよう通知され得る。

【0162】

一例では、第１制約情報オフセット（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［０］）及び第１制約情報長さ（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［０］）が通知される。第２制約情報オフセット（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［１］）及び第２制約情報長さ（例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［１］）が通知される。例えば、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［０］は１５であり、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［０］は３であり、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｏｆｆｓｅｔ［１］は８２であり、シンタックス要素ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏ＿ｌｅｎｇｔｈ［１］は７であり、よって、全リスト（例えば、１００個の制約フラグ）内の１５番目から１７番目の制約フラグ及び８２番目から８８番目の制約フラグが利用可能であり、あるいは、制約情報に存在する。

【0163】

実施形態において、制約フラグの効率的なコーディングのための様々な技術（又は方法、実施形態、例）のいずれも、適切な制御情報を使用して、組み合わされ得る。組み合わせは、そのような技術のうちの２つ以上の適切な組み合わせであってよい。代替的に、様々な技術（又は方法、実施形態、例）のうちの１つは独立して使用することができる。制約情報はグループにまとめられ得る。特定のグループでは、ランコーディングが使用され得、一方、他のグループは単純なバイナリコーディングを用いてもよい。

【0164】

制約フラグの最大数（例えば、ＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ）の値は、１６、３２、６４、１２８などであるよう予め定義され得る。

【0165】

制約フラグの最大数（例えば、ＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ）の値は、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ若しくはｇｅｎｅｒａｌ＿ｓｕｂ＿ｐｒｏｆｉｌｅ＿ｉｄｃなどのプロファイル情報、又はコーデックバージョン情報によって決定することができ、それにより、制約フラグの数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓ（１４０１））の範囲がプロファイル情報又はバージョン情報によって制限され得る。例えば、メインプロファイル内の制約フラグの数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓ（１４０１））の値（なお、ＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ＝６４）は、０から６４の範囲にあることができ、一方、高度（advanced）プロファイル内の制約フラグの数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓ（１４０１））の値（なお、ＭａｘＮｕｍＣｏｎｓｔｒａｉｎｔＦｌａｇｓ＝１２８）は、０から１２８の範囲にあることができる。

【0166】

実施形態において、制約フラグの数（例えば、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓ）の値は、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ若しくはｇｅｎｅｒａｌ＿ｓｕｂ＿ｐｒｏｆｉｌｅ＿ｉｄｃなどのプロファイル情報、又はコーデックバージョン情報によって予め定義された値に等しいと推測することができるので、ｎｕｍ＿ａｖａｉｌａｂｌｅ＿ｃｏｎｔｒａｉｎｔ＿ｆｌａｇｓの値は明示的なシグナリングなしで決定可能である。

【0167】

いくつかの実施形態において、予約済み（reserved）バイト情報が汎用制約情報シンタックス構造に存在することができる。例えば、図１３に示されるように、フラグｇｃｉ＿ｎｕｍ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓ（１３０３）及びｇｃｉ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓ［］（１３０４）が、汎用制約情報シンタックス構造の拡張のために、汎用制約情報シンタックス構造に存在することができる。フラグｇｃｉ＿ｎｕｍ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓは予約済み制約バイトの数を規定することができる。一例では、予約済み制約バイトは追加フラグ（例えば、追加制約フラグ）用である。フラグｇｃｉ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓ［］は如何なる適切な値も有してよい。

【0168】

実施形態において、ｇｃｉ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓの値は、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ若しくはｇｅｎｅｒａｌ＿ｓｕｂ＿ｐｒｏｆｉｌｅ＿ｉｄｃなどのプロファイル情報、又はコーデックバージョン情報によって制限又は決定されてよい。基本プロファイル（又はメインプロファイル）によれば、フラグｇｃｉ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓの値は０であることができる。拡張プロファイル（又は高度プロファイル）によれば、ｇｃｉ＿ｎｕｍ＿ｒｅｓｅｒｖｅｄ＿ｂｙｔｅｓの値は０よりも大きくなる。

【0169】

いくつかの実施形態において、フィールドシーケンスフラグは、コーディングされたビデオビットストリームで通知することができる。フィールドシーケンスフラグは、出力レイヤセット内のピクチャがフィールドコーディングでコーディングされているかどうかを示すことができる。いくつかの例では、フィールドシーケンスフラグは、シンタックス要素ｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇを用いてＳＰＳで通知することができる。実施形態において、フラグｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇはＳＰＳに存在する。１に等しいフラグｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇは、フィールドを表すピクチャをＣＬＶＳが運ぶことを示すことができる。０に等しいフラグｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇは、フレームを表すピクチャをＣＬＶＳが運ぶことを示すことができる。

【0170】

図１３の汎用制約情報シンタックス構造には、フラグｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが存在してよい。１に等しいフラグｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、出力レイヤセット用の範囲（例えば、ＯｌｓＩｎＳｃｏｐｅ）が、フレームを表すピクチャを運ぶことを規定することができる。０に等しいフラグｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、出力レイヤセット用の範囲（例えば、ＯｌｓＩｎＳｃｏｐｅ）が、フレームを表しても表さなくてもよいピクチャを運ぶことを規定する。実施形態において、フラグ、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、出力レイヤセット内のピクチャがフィールドコーディングでコーディングされているかどうかを示す。出力レイヤセットは、コーディングブロックのサブセットを含むことができる。フラグｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇは、ピクチャのサブセットがフィールドコーディングでコーディングされていないことを示すフラグｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ（例えば、１である）に基づき、偽であることができる。ピクチャのサブセットは、出力レイヤセットの１レイヤにあることができる。

【0171】

フラグｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｓｐｓ＿ｆｉｅｌｄ＿ｓｅｑ＿ｆｌａｇの値は０に等しくてよい。

【0172】

実施形態において、フラグｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇはＰＰＳに存在してよい。１に等しいフラグｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、ＰＰＳを参照する各ピクチャが１つよりも多いＶＣＬ ＮＡＬユニットを有し、ＶＣＬ ＮＡＬユニットが同じ値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有さないことを規定することができる。０に等しいフラグｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、ＰＰＳを参照する各ピクチャが１つ以上のＶＣＬ ＮＡＬユニットを有し、ＰＰＳを参照する各ピクチャのＶＣＬ ＮＡＬユニットが同じ値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有することを規定することができる。図１３の汎用制約情報シンタックス構造には、フラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが存在してよい。１に等しいフラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔは、ｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの値が０に等しくなければならないことを規定することができる。０に等しいフラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔは、そのような制約を課さない。

【0173】

実施形態において、フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、コーディングされたピクチャがビットストリームに１つしか存在しないことを規定することができる。０に等しいフラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａは、そのような制約を課さない。

【0174】

実施形態において、フラグｓｉｎｇｌｅ＿ｌａｙｅｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｓｉｎｇｌｅ＿ｌａｙｅｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｓｐｓ＿ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄが０に等しくなければならないことを規定することができる。０に等しいフラグｓｉｎｇｌｅ＿ｌａｙｅｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｓｉｎｇｌｅ＿ｌａｙｅｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値は１に等しくてよい。

【0175】

実施形態において、フラグａｌｌ＿ｌａｙｅｒｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいフラグａｌｌ＿ｌａｙｅｒｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、フラグｖｐｓ＿ａｌｌ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｌａｙｅｒｓ＿ｆｌａｇが１に等しくてもよいことを規定することができる。０に等しいフラグａｌｌ＿ｌａｙｅｒｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｓｉｎｇｌｅ＿ｌａｙｅｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグａｌｌ＿ｌａｙｅｒｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値は１に等しくてよい。

【0176】

実施形態において、フラグｎｏ＿ｒｅｓ＿ｃｈａｎｇｅ＿ｉｎ＿ｃｌｖｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｒｅｓ＿ｃｈａｎｇｅ＿ｉｎ＿ｃｌｖｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、フラグｓｐｓ＿ｒｅｓ＿ｃｈａｎｇｅ＿ｉｎ＿ｃｌｖｓ＿ａｌｌｏｗｅｄ＿ｆｌａｇが０に等しくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｒｅｓ＿ｃｈａｎｇｅ＿ｉｎ＿ｃｌｖｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｎｏ＿ｒｅｆ＿ｐｉｃ＿ｒｅｓａｍｐｐｌｉｎｇ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｒｅｓ＿ｃｈａｎｇｅ＿ｉｎ＿ｃｌｖｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値は１に等しくてよい。

【0177】

実施形態において、フラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１２の汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、フラグｐｐｓ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの値が０に等しくてもよいことを規定する。０に等しいフラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｏｎｅ＿ｓｕｂｐｉｃ＿ｐｅｒ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0178】

実施形態において、フラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３の汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＴＲＡＩＬ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる（ＯｌｓＩｎＳｃｏｐｅは、ＤＰＳを参照するビットストリーム全体の全レイヤを含む出力レイヤセットである。）。０に等しいフラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0179】

実施形態において、フラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３の汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＳＴＳＡ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0180】

実施形態において、フラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３の汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＴＲＡＩＬ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｔｒａｉｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0181】

実施形態において、フラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３の汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＳＴＳＡ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、そのような制約を課さない。フラグｇｅｎｅｒａｌ＿ｏｎｅ＿ｐｉｃｔｕｒｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｓｔｓａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0182】

実施形態において、フラグｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＩＤＲ＿Ｗ＿ＲＡＤＬ又はＩＤＲ＿Ｎ＿ＬＰに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇはそのような制約を課さない。

【0183】

実施形態において、フラグｎｏ＿ｃｒａ＿ｃｏｎｓｔｒｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｃｒａ＿ｃｏｎｓｔｒｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＣＲＡ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｃｒａ＿ｃｏｎｓｔｒｒａｉｎｔ＿ｆｌａｇそのような制約を課さない。

【0184】

実施形態において、フラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３の汎用制約情報シンタックス構造に存在してよい（フラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは図示されず。）。１に等しいフラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＲＡＳＬ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇはそのような制約を課さない。フラグｎｏ＿ｃｒａ＿ｃｏｎｓｔｒｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは１に等しくてよい。

【0185】

実施形態において、フラグｎｏ＿ｒａｄｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、図１３に示されるように、汎用制約情報シンタックス構造に存在してよい。１に等しいフラグｎｏ＿ｒａｄｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇは、ｎｕｈ＿ｕｎｉｔ＿ｔｙｐｅがＲＡＤＬ＿ＮＵＴに等しいＮＡＬユニットがＯｌｓＩｎＳｃｏｐｅに存在しなくてもよいことを規定することができる。０に等しいフラグｎｏ＿ｒａｄｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇはそのような制約を課さない。フラグｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇが１に等しく、フラグｎｏ＿ｃｒａ＿ｃｏｎｓｔｒｒａｉｎｔ＿ｆｌａｇが１に等しいとき、フラグｎｏ＿ｒａｓｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇの値は１に等しくてよい。

【0186】

本開示のいくつかの態様は、変換スキップモードでの残差Ｒｉｃｅコーディング、レギュラー残差コーディングでのＲｉｃｅコーディング、などによる範囲拡張などのような範囲拡張のための制約フラグシグナリングの技術を提供する。

【0187】

変換スキップモードで、変換プロセス及び逆変換プロセスはスキップされる。例えば、ビデオエンコーダで、ピクセル領域残差データは、変換領域へ変換されずに、量子化及びエントロピ符号化されてよい。ビデオデコーダで、符号化されたデータは、逆変換操作なしで、ピクセル領域残差データにエントロピ復号化及び逆量子化される。

【0188】

本開示の態様に従って、残差コーディングはＲｉｃｅコーディングに基づき実行され得る。Ｒｉｃｅコーディングは、入力値を２つの部分に分け、それから異なるコーディング技術を用いて２つの部分をコーディングするために、調整可能なパラメータを使用する。調整可能なパラメータはＲｉｃｅパラメータと呼ばれる。Ｒｉｃｅパラメータは、Ｒｉｃｅコーディングのコーディング効率に影響を及ぼす可能性がある。技術は、特定のアプリケーションのためにコーディング効率を改善するようその特定の用途のＲｉｃｅパラメータを決定するために使用され得る。Ｒｉｃｅパラメータを決定するためのいくつかの技術は、ビデオ標準規格の範囲拡張に含まれてもよい。

【0189】

本開示の態様に従って、いくつかの標準規格は、もともとは特定のアプリケーションのために開発され得る。標準規格を他のアプリケーションに適用可能にするために、他のアプリケーションをサポートするツールにより範囲拡張が開発されている。例えば、ＨＥＶＣは、もともとは、８～１０ビット／サンプルでの４：２：０クロマフォーマットによるアプリケーションを対象としている。ＨＥＶＣ標準規格を特定のクロマフォーマット及び特定のビットデプスに加えて他のフォーマット及びビットデプスに適用可能にするために、範囲拡張は、他のクロマフォーマット及び／又はより高いビットデプスを使用するアプリケーションをサポートするよう開発され得る。

【0190】

アプリケーションの特定のグループに必要とされるものに特徴セットを制限するために、ビデオコーディング標準規格は、それらの特徴を使用するエンコーダとの相互運用制のためにサポートされる定義済みのデコーダ特徴セットを含むことができるプロファイルを定義する。プロファイルに加えて、いくつかの標準規格（例えば、ＶＶＣ、ＨＥＶＣ、など）はレベル及びティアも定義する。レベルは、デコーダ処理負荷及びメモリ能力に対応することがある空間分解能、ピクセルレート、ビットレート値及び変数に関してビットストリームに制限を課す。レベル正弦波、最大サンプルレート、最大ピクチャサイズ、最大ビットレート、最小圧縮比、コーディングされたピクチャバッファの容量、などに関して表され得る。レベルの値が高いほど、複雑さの制限が高くなる可能性がある。ティアは、各レベルごとにビットレートの値及び変動の制限を変更する。例えば、Ｍａｉｎティアはほとんどのアプリケーションを対象としているが、Ｈｉｇｈティアは、ビデオ配信アプリケーションよりもビットレート値が非常に高いなど、より要求の厳しいビデオコントリビューションアプリケーションに対応するように設計されている。プロファイル、ティア、及びレベルのそれぞれが実装及び復号化の複雑さに影響を与え、３つの組み合わせがビットストリーム及びデコーダの相互運用性ポイントを指定する。

【0191】

いくつかの例では、特定のティア及びレベルに適合しているデコーダは、そのレベル又はそれよりも下の任意のレベルの同じティア又はより低いティアに適合する全てのビットストリームを復号することができることを要求され、特定のプロファイルに適合するデコーダは、そのプロファイルの全ての特徴をサポートすることができる。いくつかの例では、エンコーダは、プロファイルでサポートされている特徴の任意の特定の組を使用することを要求されないが、ビットストリーム、つまり、適合するデコーダによってそれらが復号化されることを可能にする特定の制約に従うビットストリームを生成することを要求される。

【0192】

ＰＴＬ情報に加えて、ＰＴＬシンタックス構造は、ビットストリームの特定の制約特性を示す非フラグシンタックス要素及び制約フラグのリストを含む汎用制約情報（ＧＣＩ）シンタックス構造も含んでよい。

【0193】

一例では、ＨＥＶＣは、メインプロファイル、メイン１０（Main 10）プロファイル、及びメイン静止画（Main Still Picture）プロファイルと呼ばれる３つのプロファイルをもともと含んでいる。３つのプロファイルは、４：２：０クロマサンプリングのみをサポートすることといった何らかの制限を有している。メインプロファイル及びメイン静止画プロファイルでは、８ビット／サンプルのビデオ精度のみがサポートされ、一方、メイン１０プロファイルは最大１０ビット／サンプルまでをサポートする。メイン静止画プロファイルでは、ビットストリーム全体が1つのコーディングされたピクチャしか含まない。

【0194】

いくつかの例では、範囲拡張を伴うＨＥＶＣは追加のプロファイルをサポートすることができる。一例では、次のプロファイルが範囲拡張プロファイルと総称される：モノクロ（Monochrome）プロファイル、モノクロ１０プロファイル、モノクロ１２プロファイル、モノクロ１６プロファイル、メイン１２プロファイル、メイン４：２：２ １０プロファイル、メイン４：２：２ １２プロファイル、メイン４：４：４プロファイル、メイン４：４：４ １０プロファイル、メイン４：４：４ １２プロファイル、メインイントラプロファイル、メイン１０イントラプロファイル、メイン１２イントラプロファイル、メイン４：２：２ １０イントラプロファイル、メイン４：２：２ １２イントラプロファイル、メイン４：４：４イントラプロファイル、メイン４：４：４ １０イントラプロファイル、メイン４：４：４ １２イントラプロファイル、メイン４：４：４ １６イントラプロファイル、メイン４：４：４静止画プロファイル及びメイン４：４：４ １６静止画プロファイル。

【0195】

範囲拡張プロファイルのいくつかは、より高いビットデプスをサポートすることができ、高いビットデプスを有する動作範囲拡張のためのプロファイル（profiles for operation range extensions with high bitdepth）と呼ばれ得る。いくつかの例では、高いビットデプスを有する動作範囲拡張のためのプロファイルは、メイン１２プロファイル、メイン１２ ４：４：４プロファイル、メイン１６ ４：４：４プロファイル、メイン１２イントラプロファイル、メイン１２ ４：４：４イントラプロファイル、メイン１６ ４：４：４イントラプロファイル、メイン１２静止画プロファイル、メイン１２ ４：４：４静止画プロファイル、メイン１６ ４：４：４静止画プロファイル、などのような、１０ビット／サンプルよりも大きいものをサポートするプロファイルを含む。

【0196】

具体的に、メイン１２プロファイルは、４：０：０及び４：２：０クロマサンプリング、並びにイントラ予測モード及びインター予測モードの両方をサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。いくつかの例では、メイン１２プロファイルに適合するデコーダは、次のプロファイル：モノクロ、モノクロ１２、メイン、メイン１０、及びメイン１２で作成されたビットストリームを復号することができる。

【0197】

メイン１２ ４：４：４プロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４クロマサンプリング、並びにイントラ予測モード及びインター予測モードの両方をサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。いくつかの例では、メイン１２ ４：４：４プロファイルに適合するデコーダは、次のプロファイル：モノクロ、メイン、メイン１０、メイン１２、メイン１０ ４：２：２、メイン１２ ４：２：２、メイン４：４：４、メイン１０ ４：４：４、メイン１２ ４：４：４、及びモノクロ１２で作成されたビットストリームを復号することができる。

【0198】

メイン１６ ４：４：４プロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４クロマサンプリング、並びにイントラ予測モード及びインター予測モードの両方をサポートして、サンプルあたり８ビットから１６ビットのビットデプスを可能にする。

【0199】

メイン１２イントラプロファイルは、４：０：０及び４：２：０クロマサンプリング、並びにイントラ予測モードをサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。

【0200】

メイン１２ ４：４：４イントラプロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４、並びにイントラ予測モードをサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。

【0201】

メイン１６ ４：４：４イントラプロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４、並びにイントラ予測モードをサポートして、サンプルあたり８ビットから１６ビットのビットデプスを可能にする。

【0202】

メイン１２静止画プロファイルは、４：０：０及び４：２：０クロマサンプリングをサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。メイン１２静止画プロファイルでは、ビットストリーム全体が1つのコーディングされたピクチャしか含まない。

【0203】

メイン１２ ４：４：４静止画プロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４クロマサンプリングをサポートして、サンプルあたり８ビットから１２ビットのビットデプスを可能にする。メイン１２ ４：４：４静止画プロファイルでは、ビットストリーム全体が1つのコーディングされたピクチャしか含まない。

【0204】

メイン１６ ４：４：４静止画プロファイルは、４：０：０、４：２：０、４：２：２及び４：４：４クロマサンプリングをサポートして、サンプルあたり８ビットから１６ビットのビットデプスを可能にする。メイン１６ ４：４：４静止画プロファイルでは、ビットストリーム全体が1つのコーディングされたピクチャしか含まない。

【0205】

本開示のいくつかの態様に従って、コーディングツール制御は、ビットストリームの範囲、コーディングされたレイヤビデオシーケンス（ＣＬＶＳ）、ピクチャ、ピクチャのスライス、などのような様々な範囲（例えば、コーディングツール制御のためのシンタックス要素のインスタンスの永続性を利用してコーディングされているコーディングされたビデオデータの部分）で実行され得る。いくつかの例では、コーディングツール制御は、デコーダへ出力レイヤセットを運ぶビットストリームに対する制約情報を一般的に含む汎用制約情報（ＧＣＩ）シンタックス構造で提供することができる。いくつかの例では、コーディングツール制御は、ＣＬＶＳに関連したシーケンスパラメータセット（ＳＰＳ）で提供することができ、ＳＰＳは、一般的に、ＣＬＶＳの情報を含む。いくつかの例では、コーディングツール制御はピクチャのピクチャヘッダで提供することができ、ピクチャヘッダは、一般的に、ピクチャの情報を含む。いくつかの例では、コーディングツール制御はスライスのスライスヘッダで提供することができ、スライスヘッダは、一般的に、スライスの情報を含む。

【0206】

本開示の態様に従って、範囲拡張におけるコーディングツールのための制御情報は様々な範囲で提供することができる。いくつかの例では、より広い範囲のシンタックス要素を使用することは、コーディング効率を向上させることができる。例えば、０よりも大きいＧＣＩシンタックス要素値は、ビットストリームが特定の方法で、通常は、特定のコーディングツールがビットストリームで使用されないことを示すよう、制約されることを示す。更に、値０に等しいＧＣＩシンタックス要素値は、関連する制約が適用されない可能性があることを通知し、それにより、関連するコーディングツールは、（その使用が指示されているプロファイルでサポートされる場合に）ビットストリームで使用されることを許される（が要求されない）。

【0207】

本開示の他の態様に従って、コーディングツールがビットストリームでのビデオデータのコーディングで使用されないとき、例えば、ＰＴＬ情報及び／又は汎用制約情報での、コーディングツールの不使用を示し、コーディングツールのサポートがないビデオデコーダは、ＰＴＬ情報及び／又は汎用制約情報でのシグナリングに基づき、ビデオデコーダがビットストリームを復号することができることを決定してよく、ビデオデコーダの機能は拡張され得る。

【0208】

いくつかの実施形態において、エンコーダは、範囲拡張を伴うビデオ標準規格に適合するビットストリームを生成することができるが、範囲拡張でサポートされる１つ以上の特徴を使用しない。いくつかの例では、範囲拡張における１つ以上の特徴の不使用を知った上で、ビデオ標準規格に適合するが範囲拡張における１つ以上の特徴をサポートしないデコーダは、デコーダがビットストリームを復号することができることを決定してよく、ビットストリームを拒絶するのではなく、復号化のためにビットストリームを受け入れてよい。

【0209】

図１６は、本開示のいくつかの実施形態に係る汎用制約情報のシンタックス構造（１６００）を示す。いくつかの例では、シンタックス構造（１６００）は、デコーダへの出力レイヤセットを含むビットストリームなどのビットストリームに適用される制約を含む。図１６の例では、シンタックス構造（１６００）内でｇｃｉ＿ｎｕｍ＿ａｄｄｉｔｉｏｎａｌ＿ｂｉｔｓによって表されているシンタックス要素が、アライメントゼロビットシンタックス要素（存在する場合）以外の汎用制約情報シンタックス構造（１６００）内の追加の汎用制約情報（ＧＣＩ）ビットの数を指定するために使用される。いくつかの標準規格では、ｇｃｉ＿ｎｕｍ＿ａｄｄｉｔｉｏｎａｌ＿ｂｉｔｓの値は、０又は１に等しいことを要求される。いくつかの標準規格では、デコーダは、１よりも大きいｇｃｉ＿ｎｕｍ＿ａｄｄｉｔｉｏｎａｌ＿ｂｉｔｓの値がシンタックス構造に表れることを可能にしてもよい。

【0210】

図１６の例では、シンタックス構造（１６００）は、
ｇｅｎｅｒａｌ＿ｎｏ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、
ｇｅｎｒａｌ＿ｎｏ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、
ｇｅｎｅｒａｌ＿ｎｏ＿ｒｒｃ＿ｒｉｃｅ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、
ｇｅｎｅｒａｌ＿ｎｏ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｉｃｅ＿ａｄａｐｔａｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、及び
ｇｅｎｅｒａｌ＿ｎｏ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ
によって表される５つの追加のＧＣＩビット（シンタックス要素）（１６０１）～（１６０５）を含む。５つの追加のＧＣＩビット（１６０１）～（１６０５）は夫々、いくつかの例では、出力レイヤセットのビットストリームの範囲でコーディングツールのコーディング制御情報を提供する。

【0211】

図１７は、本開示のいくつかの実施形態に係るシーケンスパラメータセット（ＳＰＳ）範囲拡張のシンタックス構造（１７００）の例を示す。シンタックス構造（１７００）は、ＣＬＶＳに対して範囲拡張のコーディングツールの制御を提供するようＣＬＶＳについてはＳＰＳで付加され得る。シンタックス構造（１７００）は、
ｓｐｓ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇ、
ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇ、
ｓｐｓ＿ｒｒｃ＿ｒｉｃｅ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇ、
ｓｐｓ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｉｃｅ＿ａｄａｐｔａｔｉｏｎ＿ｅｎａｂｌｅｄ＿ｆｌａｇ、及び
ｓｐｓ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｅｎａｂｅｄ＿ｆｌａｇ
によって表される５つのシンタックス要素（１７０１）～（１７０５）を含む。５つのシンタックス要素（１７０１）～（１７０５）は、いくつかの例では、ＣＬＶＳの範囲でコーディングツールのコーディング制御情報を提供する。

【0212】

具体的に、実施形態において、ＧＣＩビット（１６０１）及びシンタックス要素（１７０１）は、異なる範囲において、スケーリング及び変換プロセスでの変換係数や、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などのようないくつかのシンタックス要素の二値化の拡張されたダイナミックレンジのコーディングツールの制御などのような、拡張された精度を使用する制御を提供するために使用される。

【0213】

１に等しいシンタックス要素（１７０１）は、拡張されたダイナミックレンジが、スケーリング及び変換プロセスでの変換係数のために、並びにａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などのようないくつかのシンタックス要素の二値化のために使用されることを規定する。シンタックス要素ａｂｓ＿ｒｅｍａｉｎｄｅｒ［走査位置ｎ］は、走査位置ｎでＧｏｌｏｍｂ－Ｒｉｃｅコードによりコーディングされている変換係数レベルの残りの絶対値である。ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］が存在しない場合に、それは０に等しいと推測される。シンタックス要素ｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［走査位置ｎ］は、走査位置ｎでＧｏｌｏｍｂ－Ｒｉｃｅコードによりコーディングされている中間値に対応することができ、走査位置ｎでの変換係数のレベルを決定するために使用される。０に等しいシンタックス要素（１７０１）は、拡張されたダイナミックレンジがスケーリング及び変換プロセスで使用されず、例えば、シンタックス要素ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などの二値化に使用されないことを規定する。

【0214】

一例では、Ｌｏｇ２ＴｒａｎｓｆｏｒｍＲａｎｇｅによって表される変数が、スケーリング及び変換プロセスでの変換係数のために並びに特定のシンタックス要素の二値化のためにダイナミックレンジを決定するために使用される。例えば、変数Ｌｏｇ２ＴｒａｎｓｆｏｒｍＲａｎｇｅは、スケーリング及び変換プロセスでの変換係数を表すための並びに特定のシンタックス要素の二値化のためのビットの数であることができる。ダイナミックレンジは、ビットの数を用いて表される、最大数及び最小数の差であることができる。一例では、変数Ｌｏｇ２ＴｒａｎｓｆｏｒｍＲａｎｇｅは、式（１）：

Ｌｏｇ２ＴｒａｎｓｆｏｒｍＲａｎｇｅ＝
ｓｐｓ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇ？
Ｍａｘ（１５，Ｍｉｎ（２０，ＢｉｔＤｅｐｔｈ＋６））：１５ 式（１）

を使用することなどの、シンタックス要素（１７０１）ｓｐｓ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇに従って、導出される。

【0215】

スケーリング及び変換プロセスでの変換係数のための並びに特定のシンタックス要素の二値化のためのダイナミックレンジは、変数Ｌｏｇ２ＴｒａｎｓｆｏｒｍＲａｎｇｅに基づき決定することができる。いくつかの例では、フラグｓｐｓ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが値０を有するとき、拡張されたダイナミックレンジ特徴（例えば、拡張されたダイナミックレンジのコーディングツール）は使用されず、変換係数のダイナミックレンジは、１５ビットなどの固定数のビットに基づく。フラグｓｐｓ＿ｅｘｔｅｎｄｅｄ＿ｐｒｅｃｉｓｉｏｎ＿ｆｌａｇが値１を有するとき、拡張されたダイナミックレンジ特徴は有効にされ、スケーリング及び変換プロセスでの変換係数を表すためのビットの数は、式（１）の例におけるビットデプスＢｉｔＤｅｐｔｈに基づいて、１５ビット、１６ビット、１７ビット、１８ビット、１９ビット、及び２０ビットのうちの１つであることができる。変換係数のダイナミックレンジは、ビットの数に基づき決定され得る。

【0216】

本開示の態様に従って、シンタックス要素（例えば、ｓｐｓ＿ｂｉｔｄｅｐｔｈ＿ｍｉｎｕｓ８によって表される。）は、ルーマアレイ及びクロマアレイのサンプルのビットデプス（例えば、ＢｉｔＤｅｐｔｈで表される。）と、ルーマ及びクロマ量子化パラメータ範囲オフセット（例えば、ＱｐＢｄＯｆｆｓｅｔで表される。）とを通知するために使用され得る。一例では、ビットデプスＢｉｔＤｅｐｔｈは、式（２）に従って計算することができ、ＱＰ範囲オフセットＱｐＢｄＯｆｆｓｅｔは、式（３）に従って計算することができる：

ＢｉｔＤｅｐｔｈ＝８＋ｓｐｓ＿ｂｉｔｄｅｐｔｈ＿ｍｉｎｕｓ８ （２）
ＱｐＢｄＯｆｆｓｅｔ＝６×ｓｐｓ＿ｂｉｔｄｅｐｔｈ＿ｍｉｎｕｓ８ （３）

【0217】

いくつかの例では、１に等しいＧＣＩビット（１６０１）は、出力レイヤセットの範囲（ＯｌｓＩｎＳｃｏｐｅ）内の全てのピクセルのためのシンタックス要素のインスタンス（１７０１）が０に等しくてもよいことを規定する。０に等しいＧＣＩビット（１６０１）はそのような制約を課さない。よって、１に等しいＧＣＩビット（１６０１）は、ビットストリームのコーディングでの拡張されたダイナミックレンジコーディングツールの不使用を規定することができる。

【0218】

いくつかの実施形態において、ＧＣＩビット（１６０２）及びシンタックス要素（１７０２）は、異なる範囲において、変換スキップモードでの残差コーディングのためのスライスベースのＲｉｃｅパラメータ選択などの、変換スキップモードでの残差コーディングのためのスライスベースのＲｉｃｅコーディングのコーディングツールの制御を提供するために使用される。

【0219】

本開示の態様に従って、変換スキップ残差コーディングのためのスライスベースのＲｉｃｅパラメータ選択は、ビデオ標準規格の範囲拡張に含まれ得る。いくつかの例では、１つの制御フラグ（例えば、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇのシンタックス要素（１７０２）で表される。）は、図１７に示されるように、変換スキップスライスのためのＲｉｃｅパラメータのシグナリングが有効又は無効にされることを示すよう、変換スキップモードが有効にされる（例えば、シンタックス要素ｓｐｓ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇが真である）場合にシーケンスパラメータセット（ＳＰＳ）で通知される。

【0220】

制御フラグが有効化と通知される（例えば、“１”に等しい）場合に、１つのシンタックス要素（例えば、ｓｈ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｉｄｘ＿ｍｉｎｕｓ１によって表される。）が更に、変換スキップスライスごとに、例えば、スライスヘッダで通知され、その変換スキップスライスのＲｉｃｅパラメータの選択を示す。制御フラグが無効化と通知される（例えば、“０”に等しい）場合に、更なるシンタックス要素は、変換スキップスライスのためのＲｉｃｅパラメータ選択を示すようスライスレベル（例えば、スライスヘッダ）で通知されず、デフォルトのＲｉｃｅパラメータが、一例でＳＰＳを参照するコーディングされたビデオデータ内の全ての変換スキップスライスに使用されてよい。

【0221】

例えば、ＳＰＳ内の１に等しいシンタックス要素（１７０２）は、ｓｈ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｉｄｘ＿ｍｉｎｕｓ１によって表されるスライスヘッダフラグが、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｊ＿ｆｌａｇを参照するスライスのスライスヘッダ（例えば、ｓｌｉｃｅ＿ｈｅａｄｅｒ（））シンタックス構造に存在してもよいことを規定する。ＳＰＳ内の０に等しいシンタックス要素（１７０２）は、スライスヘッダフラグｓｈ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｉｄｘ＿ｍｉｎｕｓ１が、ＳＰＳを参照するスライスのｓｌｉｃｅ＿ｈｅａｄｅｒ（）シンタックス構造に存在しないことを規定する。存在しない場合には、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇの値は、いくつかの例で、０に等しいと推測される。

【0222】

いくつかの例では、シンタックス要素は、出力レイヤセットの範囲において、変換スキップモードでの残差コーディングのためのスライスベースのＲｉｃｅコーディングのコーディングツールの使用を制御するよう、汎用制約情報に含まれ得る。例えば、１に等しいシンタックス要素（１６０２）は、出力レイヤセットの範囲（ＯｌｓＩｎＳｃｏｐｅ）内の全てのピクチャのためのシンタックス要素が０に等しくてもよいことを規定する。０に等しいシンタックス要素（１６０２）はそのような制約を課さない。よって、いくつかの例では、ビットストリーム内の１に等しいＧＣＩビット（１６０２）は、ビットストリームをコーディングする変換スキップ残差コーディングのためのスライスベースのＲｉｃｅパラメータ選択の不使用を規定することができる。

【0223】

いくつかの実施形態において、ＧＣＩビット（１６０３）及びシンタックス要素（１７０３）は、異なる範囲において、レギュラー残差コーディング（Regular Residual Coding，ＲＲＣ）でのａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などのようないくつかのシンタックス要素の二値化のためのＲｉｃｅパラメータ導出の１つ以上のコーディングツールの制御を提供するために使用される。いくつかの例では、レギュラー残差コーディング（ＲＲＣ）は、変換及び量子化によって得られたコーディングブロックのためのいくつかの技術を指す。いくつかの例では、ＲＲＣは、量子化のみによって得られたブロックのために変更され得る。いくつかの例では、変換スキップ残差コーディング（Transform Skip Residual Coding）は、変換をバイパスして（変換スキップとも呼ばれる。）得られたコーディングツールに専用であるいくつかの技術を指す。

【0224】

いくつかの例では、ビデオコーディング標準規格は、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などのようないくつかのシンタックス要素の二値化のためのＲｉｃｅパラメータ導出の１つ以上のコーディングツールを含んでよく、ビデオコーディング標準規格の範囲拡張は、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］などのようないくつかのシンタックス要素の二値化のためのＲｉｃｅパラメータ導出の１つ以上の代替コーディングツールを含むことができる。

【0225】

いくつかの例では、ビデオ標準規格は、Ｒｉｃｅパラメータ導出のために、ローカルテンプレートに基づいた技術を使用する。例えば、１つ以上（例えば、一例では５つ）の隣接係数レベルを含むテンプレートが、Ｒｉｃｅパラメータ導出のために使用される。例えば、テンプレート内の絶対係数値の和が計算され得、次いで、Ｒｉｃｅパラメータはその和に基づいて決定される。一例では、ルックアップテーブルが、和に基づいてＲｉｃｅパラメータを決定するために使用され得る。

【0226】

Ｒｉｃｅパラメータは他の適切なコーディングツールによって決定することができる点に留意されたい。一例では、式が、和に基づいてＲｉｃｅパラメータを決定するために使用され得る。他の例では、コンテキストモデリングが、隣接係数レベルの統計値に基づいてＲｉｃｅパラメータを決定するために使用され得る。いくつかの例では、ビデオ標準規格の範囲拡張は、Ｒｉｃｅパラメータ導出のための１つ以上の代替コーディングツールを規定することができる。

【0227】

いくつかの例で、ビデオ標準規格の範囲拡張は、他のシナリオでの使用のためにＲＲＣへの変更を含むことができる。一例では、範囲拡張は、異なるコンテキストモデリングツールと、変換スキップモードでの残差コーディングのための残差信号回転ツールとを含むことができる。

【0228】

いくつかの例では、１に等しいＳＰＳ内のシンタックス要素（１７０３）は、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のための代替のＲｉｃｅパラメータ導出（例えば、範囲拡張におけるＲｉｃｅパラメータ導出のための代替のコーディングツール）が、ＳＰＳを参照するＣＬＶＳをコーディングするために使用されることを規定する。０に等しいシンタックス要素（１７０３）は、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のための代替のＲｉｃｅパラメータ導出が、ＳＰＳを参照するＣＬＶＳをコーディングするために使用されないことを規定する。存在しない場合には、シンタックス要素（１７０３）の値は、０に等しいと推測される。

【0229】

いくつかの例では、１に等しいシンタックス要素（１６０３）は、出力レイヤセットの範囲（ＯｌｓＩｎＳｃｏｐｅ）内の全てのピクチャのためシンタックス要素（１７０３）が０に等しくてもよいことを規定する。０に等しいシンタックス要素（１６０３）はそのような制約を課さない。よって、いくつかの例では、１に等しいＧＣＩビット（１６０３）は、ビットストリームをコーディングするためにａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のための代替のＲｉｃｅパラメータ導出（例えば、定められた範囲拡張で規定されているＲｉｃｅパラメータ導出のための代替のコーディングツール）の不使用を規定することができる。

【0230】

いくつかの実施形態において、ＧＣＩビット（１６０４）及びシンタックス要素（１７０４）は、異なる範囲において、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のための統計値ベースのＲｉｃｅパラメータ導出の制御を提供するために使用される。

【0231】

本開示の態様に従って、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のためのＲｉｃｅパラメータ導出は、各変換ユニット（ＴＵ）の最初に、前のＴＵから累積された統計値を用いて初期化され得る。いくつかの例では、統計値ベースのＲｉｃｅパラメータ導出は、ビデオ標準規格の範囲拡張に含まれ得る。

【0232】

いくつかの例では、制御フラグ、例えば、ＳＰＳでｓｐｓ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｉｃｅ＿ａｄａｐｔａｔｉｏｎ＿ｅｎａｂｌｅｄ＿ｆｌａｇによって表されるシンタックス要素（１７０４）は、統計値ベースのＲｉｃｅパラメータ導出を制御するために使用される。例えば、ＳＰＳ内の１に等しいシンタックス要素（１７０４）は、ａｂｓ＿ｒｅｍａｉｎｄｅｒ［］及びｄｅｃ＿ａｂｓ＿ｌｅｖｅｌ［］の二値化のためのＲｉｃｅパラメータ導出が、各ＴＵからの最初に、前のＴＵから累積された統計値を用いて初期化されることを規定する。０に等しいシンタックス要素（１７０４）は、前のＴＵの状態が現在のＴＵのＲｉｃｅパラメータ導出で使用されないことを規定する。存在しない場合には、シンタックス要素（１７０４）の値は、０に等しいと推測される。

【0233】

更に、実施形態において、１に等しいシンタックス要素（１７０４）は、出力レイヤセットの範囲（ＯｌｓＩｎＳｃｏｐｅ）内の全てのピクチャのためシンタックス要素（１７０４）が０に等しくてもよいことを規定する。０に等しいシンタックス要素（１７０４）はそのような制約を課さない。よって、いくつかの例では、１に等しいＧＣＩビット（１６０４）は、ビットストリームをコーディングするために統計値ベースのＲｉｃｅパラメータ導出の不使用を規定することができる。

【0234】

いくつかの実施形態において、ＧＣＩビット（１６０５）及びシンタックス要素（１７０５）は、異なる範囲において、変換係数のエントロピコーディング中に最後の有効な係数の位置をコーディングするために使用される。一例では、最後の有効な係数の位置は、異なるコーディングツールによってコーディングされ得る。例えば、ビデオ標準規格は、ＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＸ及びＬａｓｔＳｉｇｎｉｆｉｃａｎｔＣｏｅｆｆＹによって表される当該位置の２つの座標を使用することによって、最後の有効な係数の位置を決定することができる第１コーディングツールを規定することができ、ビデオ標準規格の範囲拡張は、代替のコーディングツール、例えば、一例では、ゼロアウト（zero-out）変換ブロックの右下隅を参照して最後の有効な係数の相対座標をコーディングすることによって、最後の有効な係数の位置を決定することができる第２コーディングツールなどを規定することができる。

【0235】

いくつかの例では、ＳＰＳ内の１に等しいシンタックス要素（１７０５）は、ｓｈ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｆｌａｇによって表されるスライスヘッダフラグ（スライス範囲）が、ＳＰＳを参照するスライスヘッダシンタックス構造（例えば、いくつかの例ではｓｌｉｃｅ＿ｈｅａｄｅｒ（））に存在することを規定する。ＳＰＳ内の０に等しいシンタックス要素（１７０５）は、スライスヘッダフラグｓｈ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｆｌａｇが、ＳＰＳを参照するスライスヘッダシンタックス構造に存在しないことを規定し、スライスヘッダフラグｓｈ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｆｌａｇは、ゼロであると推測され得る。存在しない場合には、シンタックス要素（１７０５）の値は、０に等しいと推測される。

【0236】

いくつかの例では、スライスのスライスヘッダフラグｓｈ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｆｌａｇは、スライスのコーディング中のスケーリング及び変換プロセスの変換係数における最後の有効な係数の位置導出を決定するために使用される。一例では、ｓｈ＿ｒｅｖｅｒｓｅ＿ｌａｓｔ＿ｓｉｇ＿ｃｏｅｆｆ＿ｆｌａｇが１に等しい場合に、最後の有効な係数の位置は、第２コーディングツールなどの、ビデオ標準規格の範囲拡張における代替のコーディングツールによってコーディングされ、そうでない場合には、最後の有効な係数の位置の現在座標は、第１コーディングツールによってコーディングされる。

【0237】

いくつかの例では、１に等しいＧＣＩビット（１６０５）は、出力レイヤセットの範囲（ＯｌｓＩｎＳｃｏｐｅ）内の全てのピクチャのためシンタックス要素（１７０５）が０に等しくてもよいことを規定する。０に等しいＧＣＩビット（１６０５）はそのような制約を課さない。よって、１に等しいＧＣＩビット（１６０５）は、ビットストリームの範囲について最後の有効な係数の位置導出での第２コーディングツールの不使用を規定することができる。

【0238】

図１８は、本開示の実施形態に係るプロセス（１８００）を説明するフローチャートを示す。プロセス（１８００）は、ビデオデコーダで使用され得る。様々な実施形態において、プロセス（１８００）は、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）の処理回路、ビデオデコーダ（４１０）の機能を実行する処理回路、ビデオデコーダ（５１０）の機能を実行する処理回路、などのような、処理回路によって実行される。いくつかの実施形態で、プロセス（１８００）は、ソフトウェア命令で実装され、このようにして、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（１８００）を実行する。プロセスは（Ｓ１８０１）から始まり、（Ｓ１８１０）へ進む。

【0239】

（Ｓ１８１０）で、ビットストリーム内のコーディングされたビデオデータの第１範囲でのコーディング制御のための第１シンタックス要素（例えば、ｇｅｎｅｒａｌ＿ｎｏ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）が決定される。第１シンタックス要素は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールに関連する。いくつかの例では、コーディングツールは、変換スキップモードでの残差コーディングのためのスライスレベルでのＲｉｃｅパラメータを提供する

【0240】

一例では、第１シンタックス要素は、シンタックス構造内のシンタックス要素（例えば、ｇｃｉ＿ｎｕｍ＿ａｄｄｉｔｉｏｎａｌ＿ｂｉｔｓ）がシンタックス構造内の汎用制約情報のための追加ビットを示すことに応答して、汎用制約情報のシンタックス構造から復号される。

【0241】

いくつかの例では、コーディングツールは、標準規格の範囲拡張において定義される。一例では、ビデオデコーダは、標準規格をサポートし得るが、標準規格の範囲拡張におけるコーディングツールをサポートしなくてもよい。他の例では、ビデオデコーダは、標準規格の範囲拡張をサポートする。

【0242】

（Ｓ１８２０）で、第１シンタックス要素の値が第１値である場合に、プロセスは（Ｓ１８３０）へ進み、そうでない場合には、プロセスは（Ｓ１８４０）へ進む。第１値は、コーディングされたビデオデータの１つ以上の第２範囲（例えば、出力レイヤセット内の１つ以上のＣＬＶＳ）を含むビットストリーム内のコーディングされたビデオデータの第１範囲のコーディングにおけるコーディングツールの不使用（無効化）を示す。

【0243】

いくつかの例では、第１シンタックス要素は、デコーダで出力された出力レイヤセット内にピクチャのコーディング制御のために一般制約情報内にある。一例では、第１シンタックス要素の第１値は、出力レイヤセット内の各コーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディングでのコーディングツールの不使用を示す。

【0244】

（Ｓ１８３０）で、第１シンタックス要素が第１値であることに応答して、ビットストリーム内のコーディングされたビデオデータの第１範囲が、コーディングツールを呼び出さずに復号される。

【0245】

いくつかの例では、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２シンタックス要素（例えば、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇ）は、ＣＬＶＳを復号するためにコーディングツールを呼び出さないことを示す値を有するよう制約される。

【0246】

（Ｓ１８４０）で、第１シンタックス要素が第２値であることをに応答して、ビットストリーム内のコーディングされたビデオデータの第２範囲（例えば、コーディングされたレイヤビデオシーケンス（ＣＬＶＳ））のコーディング制御のための第２シンタックス要素（例えば、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇ）の値が、第２範囲でのコーディングされたビデオデータの復号化のために決定される。コーディングされたビデオデータの第２範囲は、次いで、それに応じて復号される。

【0247】

いくつかの例では、第１シンタックス要素が第２値であり、変換スキップモードがコーディングレイヤビデオシーケンス（ＣＬＶＳ）で有効にされることに応答して、第２シンタックス要素の値が決定される。一例では、第２シンタックス要素は、ＣＬＶＳが参照するシーケンスパラメータセット（ＳＰＳ）から復号される。第２シンタックス要素の値は、Ｒｉｃｅパラメータの選択を示すスライスレベルシンタックス要素の存在／不存在を示す。第２シンタックス要素の値がスライスレベルシンタックス要素の存在を示すことに応答して、一例では、第３シンタックス要素がスライスのスライスヘッダから復号される。第３シンタックス要素は、変換スキップモードでのスライスの残差コーディングのためのＲｉｃｅパラメータの選択を示す。

【0248】

一例では、第２シンタックス要素は、ＣＬＶＳのためのシーケンスパラメータセット（ＳＰＳ）で提示されず、第２シンタックス要素の値は、ＣＬＶＳでのコーディングツールの不使用又は変換スキップモードでのスライスの残差コーディングのためのＲｉｃｅパラメータの選択を示すスライスレベルシンタックス要素の不存在を示すために推測される。

【0249】

プロセス（１８００）は適切に適応され得る。プロセス（１８００）のステップは変更及び／又は省略され得る。追加のステップを加えることもできる。如何なる適切な実施順序も使用することができる。

【0250】

図１９は、本開示の実施形態に係るプロセス（１９００）を説明するフローチャートを示す。プロセス（１９００）はビデオエンコーダで使用され得る。様々な実施形態で、プロセス（１９００）は、端末デバイス（３１０）、（３２０）、（３３０）及び（３４０）の処理回路、ビデオエンコーダ（４０３）の機能を実行する処理回路、ビデオエンコーダ（６０３）の機能を実行する処理回路、ビデオエンコーダ（７０３）の機能を実行する処理回路などのような、処理回路によって実行される。いくつかの実施形態で、プロセス（１９００）は、ソフトウェア命令で実装され、このようにして、処理回路がソフトウェア命令を実行すると、処理回路はプロセス（１９００）を実行する。プロセスは（Ｓ１９０１）から始まり、（Ｓ１９１０）へ進む。

【0251】

（Ｓ１９１０）で、処理回路は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールが、ビットストリーム内のコーディングされたビデオデータの第１範囲（例えば、出力レイヤセット）の符号化中に使用されるかどうかを決定する。コーディングされたビデオデータの第１範囲は、コーディングされたビデオデータの１つ以上の第２範囲（例えば、ＣＬＶＳ）を含む。いくつかの例では、コーディングツールは、変換スキップモードでの残差コーディングのためにスライスレベルでＲｉｃｅパラメータを提供する。

【0252】

いくつかの例では、処理回路は、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２シンタックス要素（例えば、ｓｐｓ＿ｔｓ＿ｒｅｓｉｄｕａｌ＿ｃｏｄｉｎｇ＿ｒｉｃｅ＿ｐｒｅｓｅｎｔ＿ｉｎ＿ｓｈ＿ｆｌａｇ）に基づき、コーディングツールが使用されるかどうかを決定することができる。

【0253】

（Ｓ１９２０）で、コーディングツールがコーディングされたビデオデータの第１範囲で使用されない場合に、プロセスは（Ｓ１９３０）へ進み、そうでない場合には、プロセスは（Ｓ１９４０）へ進む。

【0254】

（Ｓ１９３０）で、第１値を有する第１シンタックス要素（例えば、ｇｅｎｅｒａｌ＿ｎｏ＿ｐｅｒｓｉｓｔｅｎｔ＿ｒｉｃｅ＿ａｄａｐｔａｔｉｏｎ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ）がビットストリームにおいて符号化される。第１シンタックス要素は、ビットストリーム内のコーディングされたビデオデータの第１範囲でのコーディング制御のためのものである。第１シンタックス要素は、変換スキップモードでの残差コーディングのためのスライスベースＲｉｃｅコーディングのコーディングツールに関連する。第１値は、コーディングされたビデオデータの第１範囲のコーディングでのコーディングツールの不使用を示す。

【0255】

一例では、第１シンタックス要素は、汎用制約情報のシンタックス構造において符号化され、シンタックス構造内のシンタックス要素（例えば、ｇｃｉ＿ｎｕｍ＿ａｄｄｉｔｉｏｎａｌ＿ｂｉｔｓ）は、シンタックス構造内の汎用制約情報のための追加ビットを示すよう調整される。

【0256】

（Ｓ１９４０）で、第２値を有する第１シンタックス要素が、ビットストリームにおいて符号化される。いくつかの例では、第１シンタックス要素は、例えば、第２値が第１シンタックス要素のデフォルト値である場合に、ビットストリームにおいて符号化されず、よって、第１シンタックス要素は、存在しない場合に推測することができ、その場合に、（Ｓ１９４０）はスキップされ得る。

【0257】

プロセス（１９００）は適切に適応され得る。プロセス（１９００）のステップは変更及び／又は省略され得る。追加のステップを加えることもできる。如何なる適切な実施順序も使用することができる。

【0258】

上記の技術（例えば、制約フラグ、適応解像度パラメータ、及び／又は同様のもののシグナリングのための技術）は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、１つ以上のコンピュータ可読媒体に物理的に記憶され得る。例えば、図２０は、開示される対象の特定の実施形態を実装するのに適したコンピュータシステム（２０００）を示す。

【0259】

コンピュータソフトウェアは、１つ以上のコンピュータ中央演算処理装置（ＣＰＵ）、グラフィクス処理ユニット（ＧＰＵ）などによって、直接に、又は解釈、マイクロコード実行などを通じて、実行することができる命令を含むコードを生成するように、アセンブリ、コンパイル、リンキングなどのメカニズムに従い得る如何なる適切な機械コード又はコンピュータ言語によってもコーディング可能である。

【0260】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、インターネット・オブ・シングス（Internet of Things）デバイス、などを含む様々なタイプのコンピュータ又はその構成要素で実行可能である。

【0261】

コンピュータシステム（２０００）に関して図２０に示されるコンポーネントは、本質的に例示であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関して如何なる限定も示唆することを意図しない。コンポーネントの構成は、コンピュータシステム（２０００）の例示的な実施形態において説明される構成要素のうちのいずれか１つ又は組み合わせに関して如何なる依存性も要件も有するものとして解釈されるべきではない。

【0262】

コンピュータシステム（２０００）は、特定のヒューマンインターフェース入力デバイスを含んでよい。かようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スワイプ、データグロープ動作）、音声入力（例えば、声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず。）を通じた一人以上のユーザによる入力に反応してよい。ヒューマンインターフェースデバイスはまた、音声（例えば、発話、音楽、周囲音）、画像（例えば、スキャンされた画像、静止画カメラから取得された写真画像）、映像（例えば、２次元映像、立体視映像を含む３次元映像）などの、人による意識的な入力に必ずしも直接には関係しない特定のメディアを捕捉するためにも使用され得る。

【0263】

入力ヒューマンインターフェースデバイスは、キーボード（２００１）、マウス（２００２）、トラックパッド（２００３）、タッチスクリーン（２０１０）、データグローブ（図示せず。）、ジョイスティック（２００５）、マイク（２００６）、スキャナ（２００７）、カメラ（２００８）（各１つしか表されていない。）のうちの１つ以上を含んでよい。

【0264】

コンピュータシステム（２０００）は、特定のヒューマンインターフェース出力デバイスも含んでよい。かようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音響、光、及び匂い／味を通じて一人以上のユーザの感覚を刺激するものであってよい。かようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（２０１０）、データグローブ（図示せず。）、又はジョイスティック（２００５）による触覚フィードバック、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る。）、音声出力デバイス（例えば、スピーカ（２００９）、ヘッドホン（図示せず。））、視覚出力デバイス（例えば、夫々タッチスクリーン入力機能の有無によらず、夫々触覚フィードバック機能の有無によらず、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含み、それらのうちのいくつかは、立体視出力、仮想現実メガネ（図示せず。）、ホログラフィックディスプレイ及びスモークタンク（図示せず。）などの手段により２次元視覚出力又は３次元よりも多い次元の出力を出力可能なスクリーン（２０１０））、及びプリンタ（図示せず。）を含んでよい。

【0265】

コンピュータシステム（２０００）は、人がアクセス可能な記憶デバイス及びそれらの関連する媒体、例えば、ＣＤ／ＤＶＤ又は同様の媒体（２０２１）を有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ（２０２０）、サムドライブ（２０２２）、リムーバブルハードディスク又はソリッドステートドライブ（２０２３）、レガシー磁気媒体、例えば、テープ及びフロッピー（登録商標）ディスク（図示せず。）、専用のＲＯＭ／ＡＳＩＣ／ＰＬＤベースデバイス、例えば、セキュリティドングル（図示せず。）、なども含むことができる。

【0266】

当業者であれば、目下開示されている対象に関連して使用されている「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、又は他の一時的な信号を含まないことも理解するはずである。

【0267】

コンピュータシステム（２０００）は、１つ以上の通信ネットワーク（２０５５）へのインターフェース（２０５４）も含むことができる。ネットワークは、例えば、ワイヤレス、ワイヤライン、光であることができる。ネットワークは更に、ローカル、ワイドエリア、メトロポリタン、車両及び工業、実時間、遅延耐性、などであることができる。ネットワークの例には、イーサネット（登録商標）などのローカルエリアネットワーク、ワイヤレスＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上放送ＴＶを含むＴＶワイヤライン又はワイヤレスワイドエリアデジタルネットワーク、ＣＡＮＢｕｓを含む車両及び工場ネットワーク、などがある。特定のネットワークは、一般に、特定の汎用データポート又はペリフェラルバス（２０４９）（例えば、コンピュータシステム（２０００）のＵＳＢポートなど）に取り付けられた外付けネットワークインターフェースアダプタを必要とする。他は、一般に、後述されるようなシステムバスへの取り付け（例えば、ＰＣコンピュータシステムへのイーサネットネットワーク、又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）によってコンピュータシステム（２０００）のコアに組み込まれる。これらのネットワークのいずれかを使用して、コンピュータシステム（２０００）は他のエンティティと通信することができる。そのような通信は、単方向の受信専用（例えば、ブロードキャストＴＶ）又は単方向の送信専用（例えば、特定のＣＡＮＢｕｓデバイスへのＣＡＮＢｕｓ）であることができ、あるいは、例えば、ローカル若しくはワイドエリアデジタルネットワークを使用して他のコンピュータシステムに対して双方向であることができる。特定のプロトコル又はプロトコルスタックが、上述されたようなネットワーク及びネットワークインターフェースの夫々で使用可能である。

【0268】

上記のヒューマンインターフェースデバイス、人がアクセス可能な記憶デバイス、及びネットワークインターフェースは、コンピュータシステム（２０００）のコア（２０４０）へ取り付けられ得る。

【0269】

コア（２０４０）は、１つ以上の中央演算処理装置（ＣＰＵ）（２０４１）、グラフィクス処理ユニット（ＧＰＵ）（２０４２）、フィールドプログラマブルゲートエリア（ＦＰＧＡ）（２０４３）の形をとる専用のプログラム可能処理ユニット、特定のタスクのためのハードウェアアクセラレータ（２０４４）、グラフィクスアダプタ（２０５０）などを含むことができる。これらのデバイスは、リードオンリーメモリ（ＲＯＭ）（２０４５）、ランダムアクセスメモリ（ＲＡＭ）（２０４６）、内部のユーザアクセス不能ハードドライブなどの内蔵大容量記憶装置、ＳＳＤ、など（２０４７）とともに、システムバス（２０４８）を通じて接続されてよい。いくつかのコンピュータシステムでは、システムバス（２０４８）は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするように、１つ以上の物理プラグの形でアクセス可能であることができる。コアのシステムバス（２０４８）へ直接に又はペリフェラルバス（２０４９）を通じて、周辺機器が取り付けられ得る。一例では、スクリーン（２０１０）がグラフィクスアダプタ（２０５０）へ接続され得る。ペリフェラルバスのためのアーキテクチャには、ＰＣＩ、ＵＳＢなどがある。

【0270】

ＣＰＵ（２０４１）、ＧＰＵ（２０４２）、ＦＰＧＡ（２０４３）、及びアクセラレータ（２０４４）は、組み合わせて上記のコンピュータコードを構成することができる特定の命令を実行可能である。そのコンピュータコードは、ＲＯＭ（２０４５）又はＲＡＭ（２０４６）に記憶され得る。一時データもＲＡＭ（２０４６）に記憶可能であり、一方、永続性データは、例えば、内蔵大容量記憶装置（２０４７）に記憶可能である。メモリデバイスのいずれかへの高速な格納及び読み出しは、キャッシュメモリの使用により可能になる。キャッシュメモリは、１つ以上のＣＰＵ（２０４１）、ＧＰＵ（２０４２）、大容量記憶装置（２０４７）、ＲＯＭ（２０４５）、ＲＡＭ（２０４６）などと密接に関連し得る。

【0271】

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

【0272】

例として、限定としてではなく、アーキテクチャ（２０００）、具体的にはコア（２０４０）を有するコンピュータシステムは、１つ以上の有形なコンピュータ可読媒体において具現されているソフトウェアを実行するプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ、などを含む。）の結果として機能を提供することができる。かようなコンピュータ可読媒体は、コア内蔵大容量記憶装置（２０４７）又はＲＯＭ（２０４５）などの、非一時的な性質であるコア（２０４０）の特定の記憶装置に加えて、先に紹介されたユーザアクセス可能な大容量記憶装置に関連した媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア（２０４０）によって実行可能である。コンピュータ可読媒体には、特定のニーズに応じて、１つ以上のメモリデバイス又はチップが含まれ得る。ソフトウェアは、コア（２０４０）、及び、具体的には、その中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む。）に、ＲＡＭ（２０４６）に記憶されているデータ構造を定義することと、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することとを含め、本明細書で説明されている特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。追加的に、又は代替案として、コンピュータシステムは、本明細書で説明されている特定のプロセス又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はそれとともに動作することができる、回路内でハードワイヤード又は別なふうに具現されたロジック（例えば、アクセラレータ（２０４４））の結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶している回路（例えば、集積回路（ＩＣ））、実行のためのロジックを具現する回路、又は両方を包含することができる。本開示は、ハードウェア及びソフトウェアの如何なる適切な組み合わせも包含する。

【0273】

付録Ａ：頭字語
ＪＥＭ：Joint Exploration Model
ＶＶＣ：Versatile Video Coding
ＢＭＳ：Benchmark Set
ＭＶ：Motion Vector
ＨＥＶＣ：High Efficiency Video Coding
ＳＥＩ：Supplementary Enhancement Information
ＶＵＩ：Video Usability Information
ＧＯＰ：Group of Picture(s)
ＴＵ：Transform Unit(s)
ＰＵ：Prediction Unit(s)
ＣＴＵ：Coding Tree Unit(s)
ＣＴＢ：Coding Tree Block(s)
ＰＢ：Prediction Block(s)
ＨＲＤ：Hypothetical Reference Decoder
ＳＮＲ：Signal Noise Ratio
ＣＰＵ：Central Processing Unit(s)
ＧＰＵ：Graphics Processing Unit(s)
ＣＲＴ：Cathode Ray Tube
ＬＣＤ：Liquid-Crystal Display
ＯＬＥＤ：Organic Light-Emitting Diode
ＣＤ：Compact Disc
ＤＶＤ：Digital Video Disc
ＲＯＭ：Read-Only Memory
ＲＡＭ：Random Access Memory
ＡＳＩＣ：Application-Specific Integrated Circuit
ＰＬＤ：Programmable Logic Device
ＬＡＮ：Local Area Network
ＧＳＭ：Global System for Mobile communications
ＬＴＥ：Long-Term Evolution
ＣＡＮＢｕｓ：Controller Area Network Bus
ＵＳＢ：Universal Serial Bus
ＰＣＩ：Peripheral Component Interconnect
ＦＰＧＡ：Field Programmable Gate Area(s)
ＳＳＤ：Solid-State Drive
ＩＣ：Integrated Circuit
ＣＵ：Coding Unit

【0274】

本開示は、いくつかの例示的な実施形態について記載してきたが、本開示の範囲内にある代替、交換、及び様々な置換均等物が存在する。よって、明らかなように、当業者であれば、たとえ本明細書で明示的に図示又は説明されていないとしても、本開示の原理を具現し、よって、その精神及び範囲の中にある多数のシステム及び方法に想到可能である。

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図15A】

【図15B】

【図16】

【図17】

【図18】

【図19】

【図20】

【国際調査報告】