特許 7578819 ビデオ復号のための方法、装置及びコンピュータプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-28

(45)【発行日】2024-11-06

(54)【発明の名称】ビデオ復号のための方法、装置及びコンピュータプログラム

(51)【国際特許分類】

   H04N 19/13 20140101AFI20241029BHJP

   H04N 19/157 20140101ALI20241029BHJP

   H04N 19/18 20140101ALI20241029BHJP

   H04N 19/70 20140101ALI20241029BHJP

【ＦＩ】

H04N19/13

H04N19/157

H04N19/18

H04N19/70

【請求項の数】 10

(21)【出願番号】P 2023528033

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

(65)【公表番号】

(43)【公表日】2023-11-22

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

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

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

【審査請求日】2023-05-10

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

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

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

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

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

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】チェ，ビヨンドゥ

(72)【発明者】

【氏名】リウ，シャン

(72)【発明者】

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

【審査官】田中 純一

(56)【参考文献】

【文献】特表２０２４－５０２１０９（ＪＰ，Ａ）

【文献】国際公開第２０２２／２５５３９５（ＷＯ，Ａ１）

【文献】国際公開第２０２２／１４７５７０（ＷＯ，Ａ１）

【文献】特開２０２３－００６２０３（ＪＰ，Ａ）

【文献】Adrian Browne, et al.，Algorithm description for Versatile Video Coding and Test Model 14 (VTM 14) [online]， JVET-W JVET-W2002-v1，ITU-T インターネット＜URL:https://jvet-experts.org/doc_end_user/documents/23_Teleconference/wg11/JVET-W2002-v1.zip＞，2021年09月25日，pp.1-105

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１２

Ｈ０４Ｎ １９／００ － １９／９８

(57)【特許請求の範囲】

【請求項1】

デコーダにおけるビデオ復号の方法であって、
プロセッサによって、ビットストリーム内のコーディングされたビデオデータの第１範囲におけるコーディング制御のための第１構文要素を決定するステップであって、前記第１構文要素は、残差コーディングにおけるＲｉｃｅパラメータ導出のための第１コーディングツールに代わる第２コーディングツールに関連付けられており、前記第１構文要素を決定するステップは、構文構造内の構文要素が前記構文構造内の一般制約情報の追加ビットを示すことに応答して、前記一般制約情報の前記構文構造から前記第１構文要素を復号することを含む、ステップと、
前記第１構文要素が、前記第１範囲における前記第２コーディングツールの無効化を示す第１値であることに応答して、前記プロセッサによって、前記第２コーディングツールを呼び出すことなく、コーディングされたビデオデータの１つ以上の第２範囲を含む、コーディングされたビデオデータの前記第１範囲を復号するステップと、
を含む、方法。

【請求項2】

前記第１構文要素は、前記デコーダにおける出力レイヤセット内のピクチャのコーディング制御のための制約情報内にある、
請求項１に記載の方法。

【請求項3】

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

【請求項4】

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

【請求項5】

前記第１構文要素が第２値であることに応答して、前記ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２構文要素の値を決定するステップを更に含み、前記第２構文要素は、前記ＣＬＶＳにおける前記第２コーディングツールの有効化／無効化を示す、
請求項２に記載の方法。

【請求項6】

前記第２構文要素の値を決定するステップは、
前記第２構文要素が前記ＣＬＶＳのためのシーケンスパラメータセット（ＳＰＳ）内に存在しないことに応答して、前記ＣＬＶＳにおける前記第２コーディングツールの無効化を示すために前記第２構文要素の前記値を推論するステップ、
を更に含む、請求項５に記載の方法。

【請求項7】

前記第２コーディングツールは、前記デコーダによってサポートされていないレンジ拡張において定義される、
請求項１に記載の方法。

【請求項8】

前記第２コーディングツールは、残差コーディングの間の絶対値の二値化のためのＲｉｃｅパラメータ導出のためのものである、
請求項７に記載の方法。

【請求項9】

請求項１乃至８のいずれか一項に記載の方法を実行するよう構成される処理回路を含む、ビデオ復号のための装置。

【請求項10】

少なくとも１つのプロセッサによって実行されると、前記少なくとも１つのプロセッサに、請求項１乃至８のいずれか一項に記載の方法を実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

参照による組み込み
本出願は、２０２１年９月２９日に出願された米国仮出願第６３／２５０,１６６号、「ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＣＯＮＳＴＲＡＩＮＴ ＦＬＡＧ ＳＩＧＮＡＬＩＮＧ ＦＯＲ ＲＡＮＧＥ ＥＸＴＥＮＳＩＯＮ ＷＩＴＨ ＲＥＳＩＤＵＡＬ ＲＩＣＥ ＣＯＤＩＮＧ ＥＸＴＥＮＳＩＯＮ」の優先権の利益を主張する、２０２２年３月３１日に出願された米国特許出願第１７／７１０,７７８号、「ＴＥＣＨＮＩＱＵＥＳ ＦＯＲ ＣＯＮＳＴＲＡＩＮＴ ＦＬＡＧ ＳＩＧＮＡＬＩＮＧ ＦＯＲ ＲＡＮＧＥ ＥＸＴＥＮＳＩＯＮ ＷＩＴＨ ＲＥＳＩＤＵＡＬ ＲＩＣＥ ＣＯＤＩＮＧ ＥＸＴＥＮＳＩＯＮ」の利益を主張する。先の出願の開示は、参照によりその全体が本明細書に組み込まれる。

【0002】

本開示は、一般的にビデオコーディングに関連する実施形態を説明する。

【背景技術】

【0003】

本明細書で提供される背景説明は、本開示の文脈を一般的に提示するためのものである。現在名前を挙げられている発明者の研究は、その研究がこの背景技術に記載された範囲において、出願時に先行技術として通常見なされ得ない記載の態様とともに、明示的にも暗黙的にも本開示に対する先行技術として認められない。

【0004】

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

【0005】

ビデオコーディング及び復号の１つの目的は、圧縮を通した、入力ビデオ信号の冗長性の低減である可能性がある。圧縮は、前述の帯域幅及び／又は記憶領域の要件を、場合によっては２桁以上低減するのを助けることができる。可逆圧縮と非可逆圧縮の両方、並びにそれらの組合せを採用することができる。可逆圧縮は、圧縮された元の信号から元の信号の正確なコピーを再構成することができる技術を指す。非可逆圧縮を使用するとき、再構成信号は、元の信号と同一でない可能性はあるが、元の信号と再構成信号との間の歪みは、再構成信号を、意図されるアプリケーションに有用であるようにするために十分に小さい。ビデオの場合、非可逆圧縮は広く使用される。許容される歪み量はアプリケーションに依存し、例えば特定の消費者ストリーミングアプリケーションのユーザは、テレビジョン分配アプリケーションのユーザよりも高い歪みを許容し得る。達成可能な圧縮比は、より高い許容可能な／容認可能な歪みが、より高い圧縮比をもたらすことができることを反映する可能性がある。

【0006】

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

【0007】

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

【0008】

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

【0009】

多くの異なる形式のイントラ予測が存在し得る。所与のビデオコーディング技術において、そのような技術のうちの２つ以上を使用することができるとき、使用中の技術を、イントラ予測モードにおいてコーディングすることができる。ある場合には、モードは、サブモード及び／又はパラメータを有することができ、これらを個々にコーディングするか又はモードコードワード（mode codeword）に含めることができる。どのコードワードを、所与のモード／サブモード／パラメータの組合せに使用するかは、イントラ予測を通したコーディング効率ゲインに影響を与える可能性があり、コードワードをビットストリームに変換するために使用されるエントロピーコーディング技術も同様であり得る。

【0010】

イントラ予測の特定のモードは、Ｈ．２６４で導入され、Ｈ．２６５で精査され、ＪＥＭ（joint exploration model）、ＶＶＣ（versatile video coding）及びベンチマークセット（ＢＭＳ：benchmark set）のようなより新しいコーディング技術で更に精査された。既に利用可能なサンプルに属している隣接するサンプル値を使用して、予測子ブロック（predictor block）を形成することができる。隣接するサンプルのサンプル値は、方向に従って予測子ブロックにコピーされる。使用中の方向への参照は、ビットストリームでコーディングされることができるか又はそれ自体が予測され得る。

【0011】

図１Ａを参照すると、右下に示されているのは、Ｈ．２６５の３３の可能な予測子方向（predictor directions）（３５のイントラモードの３３の角度モードに対応する）からわかる、９つの予測子方向のサブセットである。矢印が収束する点（１０１）は、予測されているサンプルを表す。矢印は、サンプルが予測されている方向を表す。例えば矢印（１０２）は、サンプル（１０１）が、１つのサンプル又は複数のサンプルから右上へ、水平から４５度の角度で予測されることを示す。同様に、矢印（１０３）は、サンプル（１０１）が、１つのサンプル又は複数のサンプルからサンプル（１０１）の左下へ、水平から２２．５度の角度で予測されることを示す。

【0012】

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

【0013】

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

【0014】

ある場合には、特に方向が４５度で均一に割り切れないときは、参照サンプルを計算するために、複数の参照サンプルの値が、例えば補間（interpolation）を通して組み合わされ得る。

【0015】

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

【0016】

図１Ｂは、ＪＥＭに従う６５のイントラ予測方向を示す概略（１８０）を示しており、経時的な予測方向の数の増加を例示す。

【0017】

コーディングされたビデオビットストリーム内の、方向を表すイントラ予測方向ビットのマッピングは、ビデオコーディング技術ごとに異なる可能性があり、例えばイントラ予測モードへの予測方向の単純な直接マッピングから、コードワードへ、最確モード（most probable mode）を含む複雑な適応スキームへ及び類似の技術に及ぶ可能性がある。しかしながら、すべての場合において、特定の他の方向よりもビデオコンテンツ内において生じる可能性が統計的に低い、特定の方向が存在する可能性がある。ビデオ圧縮の目標は冗長性の低減であるので、それらのより可能性が低い方向は、良好に機能するビデオコーディング技術では、より可能性が高い方向よりも多くのビット数によって表される。

【0018】

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

【0019】

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

【0020】

様々なＭＶ予測メカニズムが、Ｈ．２６５／ＨＥＶＣ（ＩＴＵ－Ｔ Ｒｅｃ． Ｈ．２６５、「Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ」、２０１６年１２月）において説明されている。Ｈ．２６５が提案する多くのＭＶ予測メカニズムのうち、ここで説明されるのは「空間マージ（spatial merge）」と呼ばれる技術である。

【0021】

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

【発明の概要】

【0022】

本開示の態様は、ビデオデータ処理のための方法及び装置を提供する。いくつかの実施形態において、ビデオデータ処理のための装置は処理回路を含む。例えば処理回路は、ビットストリーム内のコーディングされたビデオデータの第１範囲（first scope）におけるコーディング制御のための第１構文要素を決定する。第１構文要素は、残差コーディングにおけるＲｉｃｅパラメータ導出（Rice parameter derivation）のための第１コーディングツールに代わる第２コーディングツールに関連付けられる。第１構文要素が、第１範囲における第２コーディングツールの無効化を示す第１値であることに応答して、処理回路は、第２コーディングツールを呼び出すことなく、コーディングされたビデオデータの１つ以上の第２範囲を含む、コーディングされたビデオデータの第１範囲を復号する。

【0023】

いくつかの実施形態において、第１構文要素は、出力レイヤセット内のピクチャのコーディング制御のための一般制約情報（general constraint information）内にある。いくつかの例において、第１構文要素の第１値は、出力レイヤセット内の各コーディングされたレイヤビデオシーケンス（ＣＬＶＳ：coded layer video sequence）における第２コーディングツールの無効化を示す。

【0024】

いくつかの例において、処理回路は、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２構文要素を、ＣＬＶＳを復号するために第２コーディングツールの呼び出しがないことを示す値を有するよう制約することができる。

【0025】

いくつかの実施形態において、第１構文要素が第２値であることに応答して、処理回路は、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２構文要素の値を決定する。第２構文要素は、ＣＬＶＳにおける第２コーディングツールの有効化／無効化を示す。第２コーディングツールは、残差コーディングの間の絶対値の二値化のためのＲｉｃｅパラメータ導出のためのものである。

【0026】

いくつかの例において、処理回路は、第２構文要素がＣＬＶＳのためのシーケンスパラメータセット（ＳＰＳ：sequence parameter set）内に存在しないことに応答して、ＣＬＶＳにおける第２コーディングツールの不使用を示すための第２構文要素の値を推論する。

【0027】

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

【0028】

いくつかの例において、第２コーディングツールは、規格のレンジ拡張（range extension）において定義され、レンジ拡張は、当該装置によってサポートされていない。

【0029】

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

【図面の簡単な説明】

【0030】

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

【0031】

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

【0032】

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

【0033】

【図2】一例における、現在のブロックとその周辺の空間マージ候補の概略図である。

【0034】

【図3】一実施形態による通信システム（３００）の簡略化されたブロック図の概略図である。

【0035】

【図4】一実施形態による通信システム（４００）の簡略化されたブロック図の概略図である。

【0036】

【図5】一実施形態によるデコーダの簡略化されたブロック図の概略図である。

【0037】

【図6】一実施形態によるエンコーダの簡略化されたブロック図の概略図である。

【0038】

【図7】別の実施形態によるエンコーダのブロック図である。

【0039】

【図8】別の実施形態によるデコーダのブロック図である。

【0040】

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

【0041】

【図10】アップサンプル又はダウンサンプルのファクタ、コードワード及びＥｘｔ－Ｇｏｌｏｍｂコードのマッピングのための表（１０００）の例を示す図である。

【0042】

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

【0043】

【図12】いくつかの例におけるＰＴＬ構文要素のセットの構文構造例を示す図である。

【0044】

【図13】いくつかの例における一般制約情報の構文構造例を示す図である。

【0045】

【図14A】本開示のいくつかの実施形態による、ＰＴＬ構文構造と一般制約情報の構文構造を含む、ＰＴＬ情報の例を示す図である。

【図14B】本開示のいくつかの実施形態による、ＰＴＬ構文構造と一般制約情報の構文構造を含む、ＰＴＬ情報の例を示す図である。

【0046】

【図15A】本開示の一実施形態による一般制約情報の構文構造の例を示す図である。

【図15B】本開示の一実施形態による一般制約情報の構文構造の例を示す図である。

【0047】

【図16】本開示のいくつかの実施形態による一般制約情報の構文構造を示す図である。

【0048】

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

【0049】

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

【0050】

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

【0051】

【図20】一実施形態によるコンピュータシステムの概略図である。

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

【0052】

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

【0053】

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

【0054】

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

【0055】

図４は、開示される主題の適用の例として、ストリーミング環境におけるビデオエンコーダ及びビデオデコーダの配置を示す。開示される主題は、例えばビデオ会議やデジタルＴＶ、ＣＤ、ＤＶＤ、メモリスティック等を含むデジタルメディアにおける圧縮ビデオの記憶等を含む、他のビデオ対応アプリケーションにも同様に適用可能であり得る。

【0056】

ストリーミングシステムは、例えば圧縮されていないビデオピクチャのストリーム（４０２）を作成するビデオソース（４０１）、例えばデジタルカメラを含むことができる、ビデオキャプチャサブシステム（４１３）を含み得る。一例では、ビデオピクチャのストリーム（４０２）は、デジタルカメラによって撮られたサンプルを含む。ビデオピクチャのストリーム（４０２）は、符号化ビデオデータ（４０４）（又はコーディングされたビデオビットストリーム）と比較したときの高データ量を強調するために太線として示されており、ビデオソース（４０１）に結合されるビデオエンコーダ（４０３）を含む電子デバイス（４２０）によって処理されることができる。ビデオエンコーダ（４０３）は、以下により詳細に説明されるような、開示される主題の態様を可能にするか又は実装するために、ハードウェア、ソフトウェア又はそれらの組合せを含むことができる。符号化ビデオデータ（４０４）（又は符号化ビデオビットストリーム（４０４））は、ビデオピクチャのストリーム（４０２）と比較したときの低データ量を強調するために細線として示されており、将来の使用のためにストリーミングサーバ（４０５）に記憶されることができる。図４のクライアントサブシステム（４０６）及び（４０８）のような１つ以上のストリーミングクライアントサブシステムは、ストリーミングサーバ（４０５）にアクセスして、符号化ビデオデータ（４０４）のコピー（４０７）及び（４０９）を取り出すことができる。クライアントサブシステム（４０６）は、例えば電子デバイス（４３０）内にビデオデコーダ（４１０）を含むことができる。ビデオデコーダ（４１０）は符号化ビデオデータの入力コピー（４０７）を復号し、そして、ディスプレイ（４１２）（例えばディスプレイ画面）又は他のレンダリングデバイス（図示せず）上でレンダリングすることができる、ビデオピクチャの出力ストリーム（４１１）を作成する。いくつかのストリーミングシステムでは、符号化ビデオデータ（４０４）、（４０７）及び（４０９）（例えばビデオビットストリーム）を、特定のビデオコーディング／圧縮規格に従って符号化することができる。これらの規格の例は、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。一例では、開発中のビデオコーディング規格は、ＶＶＣ（Versatile Video Coding）として非公式に知られている。開示される主題はＶＶＣの文脈で使用され得る。

【0057】

電子デバイス（４２０）及び（４３０）は、他の構成要素（図示せず）を含むことができることに留意されたい。例えば電子デバイス（４２０）は、ビデオデコーダ（図示せず）を含むことができ、電子デバイス（４３０）は、ビデオエンコーダ（図示せず）も含むことができる。

【0058】

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

【0059】

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

【0060】

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

【0061】

パーサ（５２０）は、シンボル（５２１）を生成するように、バッファメモリ（５１５）から受け取ったビデオシーケンスに対してエントロピー復号／構文解析動作を実行し得る。

【0062】

シンボル（５２１）の再構成は、コーディングされたビデオピクチャ又はその部分のタイプ（例えばインター及びイントラピクチャ、インター及びイントラブロック）及び他のファクタに応じて、複数の異なるユニットに関与することができる。どのユニットがどのように関与するかは、コーディングされたビデオシーケンスからパーサ（５２０）によって構文解析されたサブグループ制御情報によって制御されることができる。パーサ（５２０）と下記の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明確性のために図示されていない。

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

実施形態では、受信機（５３１）は、符号化ビデオとともに追加の（冗長な）データを受け取ることがある。追加のデータは、コーディングされたビデオシーケンスの一部として含まれてよい。追加のデータは、データを適切に復号し、かつ／又は元のビデオデータをより正確に再構成するために、ビデオデコーダ（５１０）によって使用され得る。追加のデータは、例えば時間的、空間的又は信号対ノイズ比（ＳＮＲ）強化レイヤ（enhancement layers）、冗長スライス、冗長ピクチャ、順方向誤り訂正コード等の形態とすることができる。

【0072】

図６は、本開示の実施形態による、ビデオエンコーダ（６０３）のブロック図を示す。ビデオエンコーダ（６０３）は、電子デバイス（６２０）に含まれる。電子デバイス（６２０）は、送信機（６４０）（例えば送信回路）を含む。図４の例のビデオエンコーダ（４０３）の代わりに、ビデオエンコーダ（６０３）を使用することができる。

【0073】

ビデオエンコーダ（６０３）は、ビデオサンプルを、ビデオエンコーダ（６０３）によってコーディングされるべきビデオ画像をキャプチャし得るビデオソース（６０１）（図６の例では電子デバイス（６２０）の一部ではない）から受け取り得る。別の例では、ビデオソース（６０１）は、電子デバイス（６２０）の一部である。

【0074】

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

【0075】

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

【0076】

いくつかの実施形態では、ビデオエンコーダ（６０３）は、コーディングループで動作するように構成される。過剰に簡略化した説明として、一例では、コーディングループは、ソースコーダ（６３０）（例えばコーディングされるべき入力ピクチャ及び参照ピクチャに基づいて、シンボルストリーム等のシンボルを作成することを担当する）と、ビデオエンコーダ（６０３）に埋め込まれた（ローカル）デコーダ（６３３）とを含むことができる。デコーダ（６３３）は、（リモート）デコーダも作成するのと同様の方法で、シンボルを再構成してサンプルデータを作成する（シンボルとコーディングされたビデオビットストリームとの間の任意の圧縮は、開示される主題において考慮されるビデオ圧縮技術で可逆であるので）。再構成されたサンプルストリーム（サンプルデータ）は、参照ピクチャメモリ（６３４）に入力される。シンボルストリームの復号は、デコーダ位置（ローカル又はリモート）とは独立のビット正確な結果（bit-exact results）をもたらすので、参照ピクチャメモリ（６３４）内のコンテンツも、ローカルエンコーダとリモートエンコーダとの間でビット正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のとまったく同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャのシンクロニシティ（synchronicity）のこの基本原理（及び例えばチャネルエラーのためにシンクロニシティを維持することができない場合の結果として生じるドリフト）は、いくつかの関連する技術でも同様に使用される。

【0077】

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

【0078】

この時点で可能な観察は、デコーダに存在する解析／エントロピー復号を除く任意のデコーダ技術はまた、対応するエンコーダにおいて、実質的に同一の機能形態で必ず存在する必要がある。この理由のために、開示される主題はデコーダの動作に焦点を当てる。エンコーダ技術の説明は、網羅的に説明されるデコーダ技術の反対であるので、省略される可能性がある。特定の領域のみにおいて、より詳細な説明が必要とされ、以下で提供される。

【0079】

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

【0080】

ローカルビデオデコーダ（６３３）は、ソースコーダ（６３０）によって作成されたシンボルに基づいて、参照ピクチャとして指定され得るピクチャのコーディングされたビデオデータを復号し得る。コーディングエンジン（６３２）の動作は、有利には、非可逆プロセスであり得る。コーディングされたビデオデータがビデオデコーダ（図６には図示せず）で復号され得るとき、再構成ビデオシーケンスは、典型的に、いくつかの誤差を伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ（６３３）は、参照ピクチャに対してビデオデコーダによって実行され得る復号処理を複製し、再構成参照ピクチャを参照ピクチャキャッシュ（６３４）に記憶させ得る。このようにして、ビデオエンコーダ（６０３）は、（伝送誤差なしに）遠端ビデオデコーダによって取得される再構成参照ピクチャとして、共通のコンテンツを有する再構成参照ピクチャのコピーを、ローカルに記憶し得る。

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

コントローラ（６５０）は、ビデオエンコーダ（６０３）の動作を管理し得る。コーディングの間、コントローラ（６５０）は、各コーディングされたピクチャに、特定のコーディングピクチャタイプ（coded picture type）を割り当ててよく、該コーディングピクチャタイプは、それぞれのピクチャに適用され得るコーディングに影響を与え得る。例えばピクチャは、しばしば、次のピクチャタイプのうちの１つとして割り当てられ得る：

【0086】

イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内のいずれの他のピクチャも使用せずにコーディング及び復号され得るものであり得る。いくつかのビデオコーデックは、例えば独立デコーダリフレッシュ（「ＩＤＲ：Independent Decoder Refresh」）ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Ｉピクチャのこれらの変形並びにそれらのそれぞれの用途及び特徴を知っている。

【0087】

予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために、最大１つの動きベクトルと参照インデックスを用いて、イントラ予測又はインター予測を使用して、コーディング及び復号され得るものであり得る。

【0088】

双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために、最大２つの動きベクトルと参照インデックスを用いて、イントラ予測又はインター予測を使用して、コーディング及び復号され得るものであり得る。同様に、複数予測ピクチャ（multiple-predictive pictures）は、単一のブロックの再構成のために、２つより多くの参照ピクチャ及び関連するメタデータを使用することができる。

【0089】

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

【0090】

ビデオエンコーダ（６０３）は、ＩＴＵ－Ｔ Ｒｅｃ． Ｈ．２６５のような所定のビデオコーディング技術又は規格に従ってコーディング動作を実行し得る。その動作において、ビデオエンコーダ（６０３）は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測コーディング動作を含む、様々な圧縮動作を実行し得る。コーディングされたビデオデータは、したがって、使用されているビデオコーディング技術又は規格によって指定された構文に従うことができる。

【0091】

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

【0092】

ビデオは、時間シーケンスにおいて複数のソースピクチャ（ビデオピクチャ）としてキャプチャされ得る。イントラピクチャ予測（しばしば、イントラ予測と略される）は、所与のピクチャにおける空間的相関を使用し、インターピクチャ予測は、ピクチャ間の（時間的又は他の）相関を使用する。一例では、符号化／復号中の特定のピクチャは、現在のピクチャと呼ばれ、ブロックに区分化される。現在のピクチャ内のブロックが、ビデオ内の以前にコーディングされて依然としてバッファされている参照ピクチャ内の参照ブロックに類似するとき、現在のピクチャ内のブロックは、動きベクトルと呼ばれるベクトルによってコーディングされることができる。動きベクトルは、参照ピクチャ内の参照ブロックを指し、複数の参照ピクチャが使用されているケースでは、参照ピクチャを識別する第３次元（third dimension）を有することができる。

【0093】

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

【0094】

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

【0095】

本開示のいくつかの実施形態によると、インターピクチャ予測及びイントラピクチャ予測のような予測は、ブロック単位（unit）で実行される。例えばＨＥＶＣ規格によると、ビデオピクチャのシーケンス内のピクチャは、圧縮のためにコーディングツリーユニット（ＣＴＵ）に区分化され、ピクチャ内のＣＴＵｓは、６４×６４ピクセル、３２×３２ピクセル又は１６×１６ピクセルのように、同じサイズを有する。一般に、ＣＴＵは、３つのコーディングツリーブロック（ＣＴＢｓ）を含み、該３つのＣＴＢは、１つのルマ（luma）ＣＴＢと２つのクロマ（chroma）ＣＴＢである。各ＣＴＵは、１つ又は複数のコーディングユニット（ＣＵｓ）に再帰的に四分木分裂（quadtree split）することができる。例えば６４×６４ピクセルのＣＴＵを、６４×６４ピクセルの１つのＣＵに又は３２×３２ピクセルの４つのＣＵに又は１６×１６ピクセルの１６個のＣＵに分裂することができる。一例では、各ＣＵを分析して、インター予測タイプ又はイントラ予測タイプのような、ＣＵの予測タイプを決定する。ＣＵは、時間的及び／又は空間的予測可能性に依存して、１つ以上の予測ユニット（ＰＵｓ）に分裂される。一般に、各ＰＵはルマ予測ブロック（ＰＢ）と２つのクロマＰＢｓを含む。一実施形態では、コーディング（符号化／復号）における予測動作は、予測ブロックのユニットにおいて実行される。予測ブロックの例としてルマ予測ブロックを使用すると、予測ブロックは、８×８ピクセル、１６×１６ピクセル、８×１６ピクセル、１６×８ピクセル等のような、ピクセルについての値（例えばルマ値）の行列を含んでよい。

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

エントロピーエンコーダ（７２５）は、符号化ブロックを含むようにビットストリームをフォーマットするように構成される。エントロピーエンコーダ（７２５）は、ＨＥＶＣ規格のような適切な規格に従って、様々な情報を含めるように構成される。一例では、エントロピーエンコーダ（７２５）は、一般制御データ、選択された予測情報（例えばイントラ予測情報又はインター予測情報）、残差情報及び他の適切な情報をビットストリーム内に含めるよう構成される。開示される主題によると、インターモード又は双予測モードのいずれかのマージサブモードでブロックをコーディングするとき、残差情報がないことに留意されたい。

【0104】

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

【0105】

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

【0106】

エントロピーデコーダ（８７１）は、コーディングされたピクチャから、該コーディングされたピクチャが構成される構文要素を表す特定のシンボルを再構成するよう構成されることができる。そのようなシンボルは、例えばブロックがコーディングされるモード（例えばイントラモード、インターモード、双予測モード、後者２つのマージサブモード又は別のサブモード等）、イントラデコーダ（８７２）又はインターデコーダ（８８０）によってそれぞれ予測のために使用される特定のサンプル又はメタデータを識別することができる予測情報（例えばイントラ予測情報又はインター予測情報等）、例えば量子化された変換係数の形態の残差情報等を含むことができる。一例では、予測モードがインターモード又は双予測モードであるとき、インター予測情報がインターデコーダ（８８０）に提供され、予測モードがイントラ予測モードであるとき、イントラ予測情報がイントラデコーダ（８７２）に提供される。残差情報は、逆量子化の対象となり得、残差デコーダ（８７３）に提供される。

【0107】

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

【0108】

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

【0109】

残差デコーダ（８７３）は、逆量子化を実行して非量子化（de-quantized）変換係数を抽出し、非量子化変換係数を処理して残差を周波数領域から空間領域に変換するよう構成され得る。残差デコーダ（８７３）はまた、特定の制御情報（量子化器パラメータ（ＱＰ：Quantizer Parameter）を含む）も要求することがあり、この情報は、エントロピーデコーダ（８７１）によって提供され得る（これは低量の制御情報のみであり得るので、データ経路は図示されない）。

【0110】

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

【0111】

ビデオエンコーダ（４０３）、（６０３）及び（７０３）、並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、任意の適切な技術を使用して実装されることができることに留意されたい。一実施形態では、ビデオエンコーダ（４０３）、（６０３）及び（７０３）、並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、１つ以上の集積回路を使用して実装されることができる。別の実施形態では、ビデオエンコーダ（４０３）、（６０３）及び（７０３）、並びにビデオデコーダ（４１０）、（５１０）及び（８１０）は、ソフトウェア命令を実行する１つ以上のプロセッサを使用して実装されることができる。

【0112】

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

【0113】

本開示の態様によると、ビットストリーム内のピクチャサイズは同じままであっても、変化してもよい。いくつかの関連する例では、ビデオエンコーダ及びデコーダは、コーディングされたビデオシーケンス（ＣＶＳ）、ピクチャのグループ（ＧＯＰ）又は同様のマルチピクチャ時間フレームに対して定義されて、一定のままである、所与のピクチャサイズで動作することができる。ＭＰＥＧ－２のような一例では、システム設計は、シーンのアクティビティのようなファクタに応じて水平解像度（したがって、ピクチャサイズ）を変更することが知られているが、Ｉピクチャのみでは、ピクチャサイズは、ＧＯＰに対して定義されて、典型的には一定のままである。ＣＶＳ内で異なる解像度を使用するための参照ピクチャの再サンプリングは、ＩＴＵ－Ｔ Ｒｅｃ． Ｈ．２６３ Ａｎｎｅｘ Ｐから知られている。しかしながら、ＣＶＳ内のピクチャサイズは変化せず、参照ピクチャのみが再サンプリングされ、結果として潜在的に、ピクチャキャンバスの一部のみが使用されることになるか（例えばダウンサンプリングの場合）あるいはシーンの一部のみがキャプチャされたることになる（例えばアップサンプリングの場合）。Ｈ.２６３ Ａｎｎｅｘ Ｑのようないくつかの例では、個々のマクロブロックを各次元（例えば上方又は下方）で２倍にサンプリングすることが許容される。しかしながら、ピクチャサイズは同じままである。例えばＨ.２６３でマクロブロックのサイズを固定することができるとき、マクロブロックのサイズをシグナリングする必要はない。

【0114】

いくつかの関連する例では、予測されたピクチャのピクチャサイズを変更することができる。ＶＰ９のような例では、参照ピクチャの再サンプリングと、ピクチャ全体の解像度の変更が可能になる。いくつかの例（例えばＨｅｎｄｒｙ等著「Ｏｎ ａｄａｐｔｉｖｅ ｒｅｓｏｌｕｔｉｏｎ ｃｈａｎｇｅ（ＡＲＣ）ｆｏｒ ＶＶＣ」、Ｊｏｉｎｔ Ｖｉｄｅｏ Ｔｅａｍ ｄｏｃｕｍｅｎｔ ＪＶＥＴ－Ｍ０１３５、Ｊａｎ９－１９、２０１９年、これらはその全体が本明細書に組み込まれる）では、異なる解像度（例えばより高解像度又はより低解像度）への参照ピクチャ全体の再サンプリングが可能になる。異なる候補解像度を、シーケンスパラメータセット（ＳＰＳ）でコーディングすることができ、ピクチャパラメータセット（ＰＰＳ）のピクチャごとの構文要素によって参照することができる。

【0115】

本開示の態様によると、ソースビデオを、異なる解像度のような異なる品質を有する１つ以上のレイヤを含むビットストリームへ、ピクチャを符号化することができる、レイヤコーディング（layered coding）によって圧縮することができる。ビットストリームは、デコーダ側で出力することができるレイヤ（又はレイヤのセット）を指定する構文要素を有することができる。出力すべきレイヤのセットを、出力レイヤセットとして定義することができる。例えば複数のレイヤとスケーラビリティをサポートするビデオコーデックでは、１つ以上の出力レイヤセットをビデオパラメータセット（ＶＰＳ）でシグナリングすることができる。ビットストリーム全体又は１つ以上の出力レイヤセットについてプロファイル階層レベル（ＰＴＬ：profile tier level）を指定する構文要素を、ＶＰＳ、いくつかの例でデコーダ能力情報（ＤＣＩ：decoder capability information）と呼ばれることがあるデコーダパラメータセット（ＤＰＳ）、ＳＰＳ、ＰＰＳ、ＳＥＩメッセージ等でシグナリングすることができる。ＰＴＬ情報には、コーディングツール又は機能性に対する制約を指定することができる一般制約情報が存在する可能性がある。様々なコーディングツール及び機能性の制約情報を効率的に表現し、シグナリングすることが望ましい。

【0116】

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

【0117】

いくつかの例では、例えば参照ピクチャ再サンプリングによってＣＶＳ内のピクチャ又はサブピクチャの解像度の変更を可能にするメカニズムを、適応解像度変更（ＡＲＣ：adaptive resolution change）と呼ぶことができる。適応解像度変更を行うために使用される制御情報を、ＡＲＣパラメータと呼ぶことができる。ＡＲＣパラメータは、フィルタパラメータ、スケーリング係数、出力及び／又は参照ピクチャの解像度、様々な制御フラグ及び／又は同様のものを含むことができる。

【0118】

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

【0119】

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

【0120】

本開示の一態様によると、ＡＲＣパラメータは、様々な方法でＡＲＣパラメータのクラスとして提供され得る。いくつかの例では、ＡＲＣパラメータのクラスは、Ｘ次元とＹ次元で分離又は結合される、アップサンプル及び／又はダウンサンプル係数を含む。一例では、アップサンプル及び／又はダウンサンプル係数を含むテーブルをポイントすることができる１つ以上の短い構文要素を、コーディングすることができる。

【0121】

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

【0122】

いくつかの例では、ＡＲＣパラメータのクラスは、サンプル、ブロック、マクロブロック、ＣＵ又は任意の他の適切な粒度の単位で、組合せ又は別個に、入力ピクチャ、出力ピクチャ、参照ピクチャ、コーディングされたピクチャのＸ次元又はＹ次元の解像度を含む。いくつかの例では、ビデオコーディングで使用される２つ以上の解像度があり（例えば入力ピクチャのための１つの解像度と、参照ピクチャのための別の解像度）、（解像度のうちの１つに対応する）値のセットを、（解像度のうちの別のものに対応する）別の値のセットから推論することができる。値の決定は、例えばフラグの使用に基づいてゲーティング（gate）されることができる。ゲーティングのためのフラグの使用については、更なる説明において詳細に説明される。

【0123】

いくつかの例では、ＡＲＣパラメータのクラスは、上述のような適切な粒度でＨ.２６３ Ａｎｎｅｘ Ｐで使用されているものと同様のワーピング座標（warping coordinates）を含む。Ｈ.２６３ Ａｎｎｅｘ Ｐは、ワーピング座標をコーディングする効率的な方法を定義する。他の効率的な方法を考案することができる。例えばＡｎｎｅｘ Ｐのワーピング座標の可変長可逆ハフマンスタイルのコーディングを、適切な長さのバイナリコーディングによって置き換えることができ、ここで、バイナリコードワードの長さは、最大ピクチャサイズの境界の外部でのワーピングを可能にするために、係数を掛けて値をオフセットした最大ピクチャサイズから導出されることができる。

【0124】

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

【0125】

以下の説明では、アップサンプル又はダウンサンプル係数の有限セット（Ｘ次元とＹ次元の両方で使用される同じ係数）を使用して、コードワードを通したＡＲＣパラメータのシグナリングを例示する。いくつかの例では、コードワードは、ビデオコーディング仕様（例えばＨ.２６４及びＨ.２６５）における特定の構文要素のためにＥｘｔ－Ｇｏｌｏｍｂコードを使用して、可変長コーディングされることができる。

【0126】

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

【0127】

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

【0128】

本開示の態様によると、表１のようなマッピングテーブルは構成可能なものとすることができる。例えば表１のエントリ数及び対応する意味は、完全に又は部分的に構成可能なものとすることができる。いくつかの例では、マッピングテーブルの基本的な概要は、ＳＰＳ又はＤＰＳのような高レベルのパラメータセットで伝達される。あるいは又は追加として、いくつかの例では、表１と同様の１つ以上のテーブルがビデオコーディング技術又は規格で定義されてよく、テーブルのうちの１つが、例えばＳＰＳ又はＤＰＳを通して選択されてもよい。

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

図９を参照すると、例（９４０）では、ＡＲＣ情報（９４２）が、ＰＰＳ、ヘッダパラメータセット、タイルパラメータセット、適応パラメータセット（ＡＰＳ）等のようなパラメータセット（９４１）内に存在し得る。例えばＡＰＳ（９４１）が図９に図示されている。いくつかの例では、パラメータセット（９４１）の範囲は、ピクチャよりも大きくない可能性があり、例えばピクチャ、タイルグループ等とすることができる。ＡＲＣ情報（例えばＡＲＣ情報（９４２））の使用は、関連するパラメータセット（例えばＡＰＳ（９４１））のアクティブ化を通して暗黙的にすることができる。例えばビデオコーディング技術又は規格がピクチャベースのＡＲＣのみを考慮するとき、ＰＰＳ又は同等のものが適切であり得る。

【0136】

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

【0137】

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

【0138】

図１１を参照すると、タイルグループヘッダ（１１０１）は、ピクチャの一部（例えば長方形の部分）に適用可能なヘッダの構文構造を含む。一例では、タイルグループヘッダ（１１０１）は、条件付きで、可変長のＥｘｐ－Ｇｏｌｏｍｂコーディングされた構文要素dec_pic_size_idx（１１０２）（太字で示される）を含むことができる。タイルグループヘッダ（１１０１）内の構文要素（例えばdec_pic_size_idx（１１０２））の存在を、例えばフラグ（例えばadaptive_pic_resolution_change_flag）（１１０３）によって表される適応解像度に基づいてゲーティングすることができる。フラグ（例えばadaptive_pic_resolution_change_flag）（１１０３）の値は太字で示されておらず、したがって、該フラグは、該フラグが構文図内で発生するポイントでビットストリーム内に存在する。ピクチャ又はピクチャの一部に適応解像度が使用されているかどうかを、ビットストリームの内部又は外部の高レベルの構文構造（例えば図１１のＳＰＳ（１１１０））においてシグナリングすることができる。

【0139】

図１１を参照すると、ＳＰＳ（１１１０）の抜粋が示されている。ＳＰＳ（１１１０）は、フラグ（１１１１）（例えばadaptive_pic_resolution_change_flag）である第１構文要素（１１１１）を含む。フラグ（１１１１）が真（true）であるとき、フラグ（１１１１）は、特定の制御情報を必要とし得る適応解像度の使用を示すことができる。一例では、ＳＰＳ（１１１０）内のif()ステートメント（１１１２）とタイルグループヘッダ（１１０１）によって示されるように、特定の制御情報はフラグ（１１１１）の値に基づいて条件付きで存在する。

【0140】

図１１の例に示されるように、適応解像度が使用されているとき、サンプル単位の出力解像度（又は出力ピクチャの解像度）（１１１３）をコーディングすることができる。一例では、出力解像度（１１１３）は、幅解像度（例えばoutput_pic_width_in_luma_samples）と高さ解像度（例えばoutput_pic_height_in_luma_samples）に基づいてコーディングされる。ビデオコーディング技術又は規格では、出力解像度（１１１３）の値に対する特定の制限を定義することができる。例えばレベル定義では、合計出力サンプルの数（例えばoutput_pic_width_in_luma_samplesとoutput_pic_height_in_luma_samplesの積）を限定し得る。いくつかの例では、ビデオコーディング技術又は規格あるいは外部技術又は規格（例えばシステム規格）は、幅解像度及び／又は高さ解像度の番号付けの範囲（例えば幅解像度及び／又は高さ解像度は２の累乗で割り切れる）、高さ解像度に対する幅解像度のアスペクト比（例えば高さ解像度に対する幅解像度の比率は４：３又は１６：９である）等を限定することができる。一例では、上記の制限は、ハードウェアの実装を容易にするために導入され得る。

【0141】

特定の適用では、エンコーダは、サイズが出力ピクチャサイズであることを暗黙的に仮定するのではなく、特定の参照ピクチャサイズを使用するようにデコーダに指示することができる。例えば構文要素（例えばreference_pic_size_present_flag）（１１１４）は、参照ピクチャ寸法（１１１５）の条件付きの存在をゲーティングする。参照ピクチャ寸法（１１１５）は、例えば幅（例えばreference_pic_width_in_luma_samples）と高さ（例えばreference_pic_height_in_luma_samples）の両方を含むことができる。

【0142】

また、図１１では、ピクチャの幅と高さの適用可能な復号のテーブルが図示されている。一例では、テーブル内のエントリの数を、テーブル指示（table indication）（例えば構文要素num_dec_pic_size_in_luma_samples_minus1）（１１１６）によって表すことができる。「minus1」は構文要素（１１１６）の値の解釈を指すことができる。例えばコーディングされた値が０である場合、１つのテーブルエントリが存在する。コーディングされた値が５である場合、６つのテーブルエントリが存在する。テーブル内の各エントリについて、復号されたピクチャの幅と高さが構文要素（１１１７）として含まれる。

【0143】

構文要素（１１１７）によって表されるテーブルエントリは、タイルグループヘッダ（１１０１）内の構文要素dec_pic_size_idx（１１０２）を使用してインデックス化されることができ、したがって、タイルグループごとに異なる復号サイズとズーム係数を可能にする。

【0144】

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

【0145】

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

【0146】

本開示の態様によると、コーディングされたビットストリームのいくつかの特徴は、プロファイル、階層、レベル及び一般制約情報を含む、プロファイルと階層とレベルの組合せ（ＰＴＬ：profile、tier、level）情報を使用して指定されることができる。いくつかの例では、プロファイルは、色再現、解像度、追加のビデオ圧縮等のようなビットストリームの機能のサブセットを定義する。ビデオコーデックは、ベースラインプロファイル（例えば低圧縮比の単純なプロファイル）、高プロファイル（高圧縮比の複雑なプロファイル）、メインプロファイル（例えばベースラインプロファイルと高プロファイルの間の中間の圧縮比のプロファイルは、デフォルトのプロファイル設定とすることができる。）のような様々なプロファイルを定義することができる。

【0147】

さらに、階層とレベルを使用して、最大ビットレート、最大ルマサンプルレート、最大ルマピクチャサイズ、最小圧縮比、許容される最大スライス数、許容される最大タイル数等の観点からビットストリームを定義する特定の制約を指定することができる。下位階層は上位階層よりも制約され、下位レベルは上位レベルよりも制約される。一例では、規格は２つの階層：Ｍａｉｎ（メイン）階層とＨｉｇｈ（高）階層を定義し得る。Ｍａｉｎ階層はＨｉｇｈ階層よりも下位階層である。階層は、最大ビットレートに関して異なるアプリケーションに対処するために作成される。一例では、Ｍａｉｎ階層はほとんどのアプリケーション向けに設計されており、Ｈｉｇｈ階層は非常に要求の厳しいアプリケーション向けに設計される。規格は複数のレベルを定義することができる。レベルは、ビットストリームの制約のセットである。一例では、レベル４未満のレベルでは、Ｍａｉｎ階層のみが許容される。いくつかの例では、特定の階層／レベルに準拠するデコーダは、その階層／レベルとすべての下位階層／レベルに対して符号化されたすべてのビットストリームを復号することができることが要求される。

【0148】

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

【0149】

本開示のいくつかの態様によると、ＰＴＬ情報を、範囲（例えばビットストリーム内のコーディングされたビデオデータの一部）に関連付けることができる。いくつかの例では、ＰＴＬ情報を、例えばビットストリーム全体、ビットストリームのＣＶＳ、ビットストリームの各出力レイヤセット（ＯＬＳ：output layer set）及び／又は同様のものに対して指定することができ、ＶＰＳ、ＤＰＳ、ＤＣＩ、ＳＰＳ、ＰＰＳ、ＡＰＳ、ＧＯＰ、シーケンス、ヘッダ、ＳＥＩメッセージ等のような高レベル構文（ＨＬＳ：high-level syntax）構造でシグナリングすることができる。

【0150】

いくつかの例では、高レベル構文（ＨＬＳ）は、ブロックレベルに関して定義される。ブロックレベルのコーディングツールを使用して、ピクチャ内のピクセル又はサンプルを復号してピクチャを再構成することができる。ブロックレベルのコーディングツールは、インター予測のためのコーディングツール（又はインターコーディングツール）、イントラ予測のためのコーディングツール（又はイントラコーディングツール）、適応ループフィルタ（ＡＬＦ：adaptive loop filter）、デブロッキングフィルタ（ＤＢＦ：deblocking filter）、エントロピーコーディング、変換等のような、コーディングブロックの再構成において使用される任意の適切なコーディングツールを含むことができる。

【0151】

高レベル構文（ＨＬＳ）は、機能性、システムインタフェース、ツールのピクチャレベル制御及びバッファ制御等に関する情報を指定することができる。例えばＨＬＳは、パーティション（例えばタイル、スライス、サブピクチャ）、バッファ管理、ランダムアクセス（例えばＩＤＲ、クリーンランダムアクセス（ＣＲＡ））、パラメータセット（例えばＶＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ）、参照ピクチャ再サンプリング（ＲＰＲ）、スケーラビリティ及び／又は同様のものを指定することができる。高レベル構文は、ブロックレベルを超えるものとすることができる。

【0152】

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

【0153】

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

【0154】

図１２において、ＰＴＬ構文要素のセットは、general_profile_idc、general_tier_flag、general_level_idc、num_sub_profiles、general_sub_profile_idc、sublayer_level_present_flag、ptl_alignment_zero_bit及びsublayer_level_idcを含むことができる。

【0155】

図１３において、一般制約情報は、複数の制約フラグを含むことができる。一例では、１に等しい制約フラグ（例えばintra_only_constraint_flag）（１３０５）は、パラメータsh_slice_typeがＩでなければならないこと（すなわち、スライスがイントラスライスであること）を示すことができる。パラメータsh_slice_typeは、タイプＩ、Ｐ、Ｂの間でスライスのコーディングタイプを指定する、スライスヘッダ内のパラメータである。０に等しい制約フラグ（例えばintra_only_constraint_flag）（１３０５）は、ＰＴＬ情報の範囲内のすべてのコーディングされたピクチャに対して制約（例えばsh_slice_typeがＩでなければならないこと）を課さず、この場合、他の情報（例えばprofile_idc）は非イントラスライスを許容することができる。別の例では、１に等しい制約フラグ（例えばno_alf_constraint_flag）（１３０６）は、ＰＴＬ情報の範囲内のすべてのＣＶＳに対してsps_alf_enabled_flagが０に等しいことを示すことができ、したがって、適応ループフィルタリングが例えばprofile_idcに基づいて許容される場合であっても、適応ループフィルタリングは使用されない。０に等しい制約フラグ（例えばno_alf_constraint_flag）（１３０６）は、上記の制約を課さない。

【0156】

別の例では、図１３に示されるように、制約フラグ（例えばno_lossless_coding_tool_constraint_flag）（１３０１）を一般制約情報でシグナリングすることができる。１に等しい制約フラグ（例えばno_lossless_coding_tool_constraint_flag）（１３０１）は、当該制約フラグ（１３０１）を含むＰＴＬ情報の範囲内で、可逆コーディングに関連するコーディングツールを使用することができないことを示すことができる。０に等しい制約フラグ（例えばno_lossless_coding_tool_constraint_flag）（１３０１）は、上記の制約を課さない。

【0157】

別の例では、図１３に示されるように、制約フラグ（例えばno_lossy_coding_tool_constraint_flag）（１３０２）を一般制約情報でシグナリングすることができる。１に等しい制約フラグ（例えばno_lossy_coding_tool_constraint_flag）（１３０２）は、当該制約フラグ（１３０２）を含むＰＴＬ情報の範囲内で、非可逆コーディングに関連するコーディングツールを使用することができないことを示すことができる。０に等しい制約フラグ（例えばno_lossy_coding_tool_constraint_flag）（１３０２）は、上記の制約を課さない。

【0158】

一実施形態では、制約フラグ（例えばno_lossy_coding_tool_constraint_flag）（１３０２）が１に等しいとき、制約フラグ（例えばno_lossless_coding_tool_constraint_flag）（１３０１）は１に等しくなくてよい。あるいは、制約フラグ（例えばno_lossless_coding_tool_constraint_flag）（１３０１）が１に等しいとき、制約フラグ（例えばno_lossy_coding_tool_constraint_flag）（１３０２）は１に等しくなくてよい。

【0159】

一般制約情報内の複数の制約フラグを、特定の順序でソートすることができる。順序は、例えばそれぞれのメカニズムやツールがＰＴＬの範囲内で使用されていない可能性に基づいて設定されることができる。順序を、優先順位と呼ぶことができる。この順序を、一般制約情報の構文構造において、高い優先度から低い優先度へと提示することができ、この場合、高い優先度は、ツール（又はメカニズム）の不使用が高い可能性であることを示し、低い優先度は、ツール（又はメカニズム）の不使用が低い可能性であることを示す。順序に影響を与える追加の要素は、特定のユースケース（例えばサブピクチャ、スケーラビリティ、インターレースサポートのためのツール）にのみ使用される可能性の高いツール、エンコーダ／デコーダ／実装の複雑さに対するツールの影響等を含むことができる。

【0160】

図１４Ａ～図１４Ｂは、本開示のいくつかの実施形態による、ＰＴＬ構文構造（ＰＴＬブラケットとも呼ばれる）の構文構造例（１４１０）と、一般制約情報構文構造（一般制約情報ブラケットとも呼ばれる）の構文例（１４２０）を含む、ＰＴＬ情報の例を示す。いくつかの例では、制約フラグの数（例えばnum_available_constraint_flags）を示す構文要素をシグナリングすることができる。一例では、制約フラグの数を示す構文要素は、一般制約情報ブラケットの構文例（１４２０）の外部であり得る、図１４Ａに示される構文例（１４１０）内の（１４０１）によって示されるような、ＰＴＬ構文構造でシグナリングされることができる。あるいは、制約フラグの数を示す構文要素を、構文例（１４２０）の先頭のように、一般制約情報ブラケットの先頭でシグナリングすることができる。構文要素（例えばnum_available_constraint_flags）が存在し、構文要素（例えばnum_available_constraint_flags）の値がＮに等しいとき、最初のＮ個の制約フラグが、一般制約情報構文構造内に存在し得る。さらに、他の制約フラグが存在しないことがあり、特定の値と等しいと推論することができる。Ｎは負でない整数を指定することができる。

【0161】

一実施形態では、値Ｎ（例えばnum_available_constraint_flags）は、０から制約フラグの最大数（例えばパラメータMaxNumConstraintFlagsの値）までの範囲である。制約フラグの最大数は任意の正の整数とすることができる。制約フラグの最大数（例えばMaxNumConstraintFlags）の値は、１６、３２、６４、１２８等であるよう予め定義されることができる。値Ｎ（例えばnum_available_constraint_flags）が０に等しいとき、制約フラグは一般制約情報構文構造内に存在しない。値Ｎ（例えばnum_available_constraint_flags）のコーディングは、値Ｎと制約フラグの対応するエントロピーコーディング表現が８で割り切れる数まで加算してバイトアライメント（byte alignment）を保証することができるように選択されることができる。

【0162】

いくつかの例では、制約フラグを、１つ以上の制約情報グループに分類することができる。各制約情報グループは１つ以上の制約フラグを含むことができ、対応するゲートフラグを有することができる。対応する制約情報グループのゲートフラグは、対応する制約情報グループ内に制約フラグが存在し得るかどうかを示すことができる。一例では、ゲートフラグを、制約グループ存在フラグと呼ぶことができる。一般に、ゲートフラグは、対応する制約情報グループに関連付けられ、対応する制約情報グループ内の制約フラグに関連付けられる。一実施形態では、ゲートフラグは、対応する制約情報グループ内の制約フラグが、制約情報内に存在する（又はシグナリングされる）かどうかをゲーティングする。例えば対応する制約情報グループのゲートフラグが１に等しい場合、制約情報グループに対応する制約フラグが、例えば一般制約情報内に存在することができる。対応する制約情報グループのゲートフラグが０に等しい場合、制約情報グループに対応する制約フラグは、例えば一般制約情報内に存在し得ない。例えばすべてのゲートフラグが０に等しい場合、制約フラグは存在しない。

【0163】

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

【0164】

図１５Ａ～図１５Ｂは、本開示の実施形態による一般制約情報構文構造（１５００）の例を示す。一般制約情報構文構造（１５００）は、一般制約情報を表すフラグを含む。具体的には、一般制約情報構文構造（１５００）は、図１５Ａのゲートフラグ（例えばgeneral_frame_structure_constraint_group_flag）（１５０１）、ゲートフラグ（例えばhigh_level_functionality_constraint_group_flag）（１５０２）、ゲートフラグ（例えばscalability_constraint_group_flag）（１５０３）、ゲートフラグ（例えばpartitioning_constraint_group_flag）（１５０４）、ゲートフラグ（例えばintra_coding_tool_constraint_group_flag）（１５０５）、ゲートフラグ（例えばinter_coding_tool_constraint_group_flag）（１５０６）、ゲートフラグ（例えばtransfom_contraint_group_flag）（１５０７）、ゲートフラグ（例えばinloop_filtering_constraint_group_flag）（１５０８）のような１つ以上のゲートフラグを含む。１つ以上のゲートフラグ（例えばゲートフラグ（１５０１）～（１５０８））は、図１５Ａに示されるように、一般制約情報構文構造（１５００）の先頭に存在することができる。

【0165】

ゲートフラグ（例えばgeneral_frame_structure_constraint_group_flag）（１５０１）は、制約情報グループ（１５１０）に関連付けられ、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）に関連付けられる。１に等しいゲートフラグ（例えばgeneral_frame_structure_constraint_group_flag）（１５０１）は、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）が存在し得ることを指定することができる。

【0166】

制約情報グループ（１５１０）（又は制約フラグ（１５１１）～（１５１４））は、入力ソース及びフレームパッキング（例えばパック化又は投影されたフレーム）に関連することができる。図１５Ａを参照すると、制約フラグ（１５１１）～（１５１４）は、general_non_packed_constraint_flag（１５１１）、general_frame_only_constraint_flag（１５１２）、general_non_projected_constraint_flag（１５１３）及びgeneral_one_picture_only_constraint_flag（１５１４）に対応する。そうでない場合、０に等しいゲートフラグ（例えばgeneral_frame_structure_constraint_group_flag）（１５０１）は、制約情報グループ（１５１０）内にある制約フラグ（１５１１）～（１５１４）が一般制約情報構文構造（１５００）内に存在し得ないことを指定することができる。

【0167】

さらに、いくつかの例では、１に等しいゲートフラグ（例えばhigh_level_functionality_constraint_group_flag）（１５０２）は、図１５Ｂによって示されるように、制約情報グループ（１５２０）内にある高レベルの機能性（例えば参照ピクチャ再サンプリング）に関連する制約フラグが存在し得ることを指定することができる。そうでない場合、０に等しいゲートフラグ（例えばhigh_level_functionality_constraint_group_flag）（１５０２）は、制約情報グループ（１５２０）内にある制約フラグが一般制約情報構文構造（１５００）内に存在し得ないことを指定することができる。

【0168】

図１５Ａに戻ると、１に等しいゲートフラグ（例えばscalability_constraint_group_flag）（１５０３）は、スケーラビリティ（例えばインターレイヤ予測）に関連する制約フラグが存在し得ることを指定することができる。そうでない場合、スケーラビリティに関連する制約フラグは、一般制約情報構文構造（１５００）内に存在し得ない。

【0169】

１に等しいゲートフラグ（例えばpartitioning_constraint_group_flag）（１５０４）は、高レベルパーティショニング（例えばサブピクチャ又はタイル）に関連する制約フラグが存在し得ることを指定することができる。そうでない場合、高レベルパーティショニングに関連する制約フラグは、一般制約情報構文構造（１５００）内に存在し得ない。

【0170】

１に等しいゲートフラグ（例えばintra_coding_tool_constraint_group_flag）（１５０５）は、イントラコーディング（例えばイントラ予測）に関連する制約フラグが存在し得ることを指定することができる。そうでない場合、イントラコーディングに関連する制約フラグは、一般制約情報構文構造（１５００）内に存在し得ない。

【0171】

１に等しいゲートフラグ（例えばinter_coding_tool_constraint_group_flag）（１５０６）は、インターコーディングに関連する制約フラグ（例えばイントラピクチャ予測の動き補償）が存在し得ることを指定することができる。そうでない場合、インターコーディングに関連する制約フラグは、一般制約情報構文構造（１５００）内に存在し得ない。

【0172】

１に等しいゲートフラグ（例えばtransfom_contraint_group_flag）（１５０７）は、変換コーディング（例えば複数の変換行列）に関連する制約フラグが存在し得ることを指定することができる。そうでない場合、変換コーディングに関連する制約フラグは、一般制約情報構文構造（１５００）に存在し得ない。

【0173】

一実施形態では、すべてのゲートフラグ（例えば図１５Ａのゲートフラグ（１５０１）～（１５０８））が０に等しいとき、制約フラグは、一般制約情報構文構造（例えば一般制約情報構文構造（１５００））内に存在しない。

【0174】

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

【0175】

いくつかの実施形態では、オフセット（例えば構文要素constraint_info_offset[]を使用する）のようなオフセット情報と、長さ（例えば構文要素constraint_info_length[]を使用する）のような長さ情報が、制約情報内に（例えば一般制約情報構文構造の先頭に）存在し、制約情報内のゲートフラグに関連付けられるそれぞれの制約情報グループ内の制約フラグの提示を助ける。一実施形態では、少なくとも１つの制約情報グループのうちの１つ以上が、コーディングされたビデオビットストリーム内に存在する。制約情報グループの場合、オフセットと長さが制約情報グループの制約情報内に存在することができる。オフセットは、制約情報グループの第１制約フラグへのオフセットを示すことができ、長さは、制約情報グループの制約フラグの数を示すことができる。いくつかの例では、制約情報グループの数を、例えば構文要素num_constraint_info_setによって明示的に示すことができる。num_constaint_info_setの値は０以上の整数とすることができる。num_constaint_info_setの値が０であるとき、constraint_info_offset[]、constraint_info_length[]及び制約フラグは、一般制約情報構文構造内に存在しない。

【0176】

一実施形態では、制約情報オフセット（例えば構文要素constraint_info_offset[i]）と制約情報長さ（例えば構文要素constraint_info_length[i]）は、制約情報（例えば一般制約情報構文構造）における制約情報グループｉ（ｉは正の整数）の制約フラグの提示を助けることができる。例えば制約情報オフセット（例えば構文要素constraint_info_offset[i]）の値が５に等しく、制約情報長さ（例えば構文要素constraint_info_length[i]）の値が３に等しいとき、５番目、６番目及び７番目の制約フラグが制約情報グループｉに関連付けられ、制約情報（例えば一般制約情報構文構造）内に存在する。

【0177】

一例では、ランレングスコーディングを使用して、予め決められた順序（又は所与の順序）で指定される制約フラグをコーディングすることができる。

【0178】

一実施形態では、制約フラグが予め決められた順序（又は所与の順序）で指定される、ランコーディング（run-coding）を使用することができる。制約フラグを直接コーディングする代わりに、「スキップ」値の適切にコーディングされたリストは、０に等しい制約フラグを示すことができ、次の制約フラグが１に等しいことを意味する。上述のランコーディングは、（ｉ）制約フラグの数が多く、（ｉｉ）制約フラグのわずかな割合が１に等しい場合に特に効率的であり得る。

【0179】

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

【0180】

一実施形態では、ゲートフラグの制約情報グループ内の少なくとも１つの制約フラグは、所定の順序に従ってシグナリングされる複数の制約フラグを含む。したがって、複数の制約フラグをランコーディング（例えばラン符号化又はラン復号）することができる。

【0181】

一実施形態では、制約フラグの完全なリストを、ビデオコーディング規格（例えばＶＶＣ仕様）、外部テーブル等において指定することができる。一例では、制約フラグの利用可能な制約フラグのみが、例えば以下の１つ以上によって、すなわち、利用可能な制約フラグの数（例えばnum_available_constraint_flags）、ゲートフラグ（又は制約グループ存在フラグ）、制約情報オフセット情報及び制約情報長さ情報等がコーディングされたビデオストリーム内に存在すること、によって示される。

【0182】

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

【0183】

一例では、第１制約情報オフセット（例えば構文要素constraint_info_offset[0]）と第１制約情報長さ（例えば構文要素constraint_info_length[0]）がシグナリングされる。第２制約情報オフセット（例えば構文要素constraint_info_offset[1]）と第２制約情報長さ（例えば構文要素constraint_info_length[1]）がシグナリングされる。例えば構文要素constraint_info_offset[0]は１５であり、構文要素constraint_info_length[0]は３であり、構文要素constraint_info_offset[1]は８２であり、構文要素constraint_info_length[1]は７であり、したがって、完全なリスト（例えば１００個の制約フラグ）内の１５番目から１７番目の制約フラグと８２番目から８８番目の制約フラグが制約情報で利用可能又は存在することを示す。

【0184】

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

【0185】

制約フラグの最大数（例えばMaxNumConstraintFlags）の値を、１６、３２、６４、１２８等であるように予め定義することができる。

【0186】

制約フラグの最大数（例えばMaxNumConstraintFlags）の値を、general_profile_idcやgeneral_sub_profile_idcのようなプロファイル情報又はコーデックバージョン情報によって決定することができ、その結果、制約フラグの数（例えばnum_available_constraint_flags（１４０１））の範囲をプロファイル情報又はバージョン情報によって制限することができる。例えばメインプロファイル（例えばMaxNumConstraintFlags＝６４）における制約フラグの数（例えばnum_available_constraint_flags（１４０１））の値は、０から６４の範囲内とすることができ、高度なプロファイル（例えばMaxNumConstraintFlags＝１２８）における制約フラグの数（例えばnum_available_constraint_flags（１４０１））の値は、例えば０から１２８の範囲内とすることができる。

【0187】

一実施形態では、制約フラグの数（例えばnum_available_constraint_flags）の値は、general_profile_idcやgeneral_sub_profile_idcのようなプロファイル情報又はコーデックバージョン情報によって予め定義された値と等しいと推測することができ、その結果、明示的にシグナリングすることなく、num_available_constraint_flagsの値を決定することができる。

【0188】

いくつかの実施形態では、予約されたバイト情報（reserved byte information）が一般制約情報構文構造に存在することができる。例えば図１３に示されるように、フラグgci_num_reserved_bytes（１３０３）及びgci_reserved_bytes[]（１３０４）が、一般制約情報構文構造の拡張のために、一般制約情報構文構造に存在することができる。フラグgci_num_reserved_bytesは、予約された制約バイトの数を指定することができる。一例では、予約された制約バイトは、追加のフラグ（例えば追加の制約フラグ）をシグナリングするためのものである。フラグgci_reserved_byte[]は、任意の適切な値を有してよい。

【0189】

一実施形態では、gci_num_reserved_bytesの値は、general_profile_idcやgeneral_sub_profile_idcのようなプロファイル情報又はコーデックバージョン情報によって制限又は決定され得る。ベースプロファイル（又はメインプロファイル）では、フラグgci_num_reserved_bytesの値は０とすることができる。拡張プロファイル（又は高度なプロファイル）では、gci_num_reserved_bytesの値を０より大きいものとすることができる。

【0190】

いくつかの実施形態では、フィールドシーケンスフラグを、コーディングされたビデオビットストリームでシグナリングすることができる。フィールドシーケンスフラグは、出力レイヤのピクチャがフィールドコーディングでコーディングされているかどうかを示すことができる。いくつかの例では、フィールドシーケンスフラグは、構文要素sps_field_seq_flagを使用してＳＰＳでシグナリングすることができる。一実施形態では、フラグsps_field_seq_flagがＳＰＳ内に存在し得る。１に等しいフラグsps_field_seq_flagは、ＣＬＶＳが、フィールドを表すピクチャを伝達することを示すことができる。０に等しいフラグsps_field_seq_flagは、ＣＬＶＳが、フレームを表すピクチャを伝達することを示すことができる。

【0191】

図１３の一般制約情報構文構造には、フラグgeneral_frame_only_constraint_flagが存在し得る。１に等しいフラグgeneral_frame_only_constraint_flagは、出力レイヤセットの範囲（例えばOlsInScope）が、フレームを表すピクチャを伝達することを指定することができる。０に等しいフラグgeneral_frame_only_constraint_flagは、出力レイヤセットの範囲（例えばOlsInScope）が、フレームを表すことも表さないこともあるピクチャを伝達することを指定する。一実施形態では、フラグgeneral_frame_only_constraint_flagは、出力レイヤセット内のピクチャが、フィールドコーディングでコーディングされているかどうかを示す。出力レイヤセットは、コーディングブロックのサブセットを含むことができる。フラグsps_field_seq_flagは、ピクチャのサブセットが、フィールドコーディングでコーディングされていないことを示すフラグgeneral_frame_only_constraint_flag（例えば１である）に基づいて、偽（false）とすることができる。ピクチャのサブセットは、出力レイヤセットの１つのレイヤ内にすることができる。

【0192】

フラグgeneral_frame_only_constraint_flagが１に等しいとき、フラグsps_field_seq_flagの値は０に等しくなり得る。

【0193】

一実施形態では、フラグpps_mixed_nalu_types_in_pic_flagがＰＰＳ内に存在し得る。１に等しいフラグpps_mixed_nalu_types_in_pic_flagは、ＰＰＳを参照する各ピクチャが、２つ以上のＶＣＬ ＮＡＬユニットを有し、ＶＣＬ ＮＡＬユニットが、同じnal_unit_type値を有しないことを指定することができる。０に等しいフラグpps_mixed_nalu_types_in_pic_flagは、ＰＰＳを参照する各ピクチャが、１つ以上のＶＣＬ ＮＡＬユニットを有し、ＰＰＳを参照する各ピクチャのＶＣＬ ＮＡＬユニットが同じnal_unit_type値を有することを指定することができる。図１３の一般制約情報構文構造には、フラグno_mixed_nalu_types_in_pic_constraint_flagが存在し得る。１に等しいフラグno_mixed_nalu_types_in_pic_constraint_flagは、pps_mixed_nalu_types_in_pic_flagの値が０に等しくあるべきことを指定することができる。０に等しいフラグno_mixed_nalu_types_in_pic_constraint_flagは、このような制約を課さない。

【0194】

一実施形態では、フラグgeneral_one_picture_only_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいgeneral_one_picture_only_constraint_flagは、ビットストリーム内にコーディングされたピクチャが１つだけ存在することを指定することができる。０に等しいフラグgeneral_one_picture_only_constraint_flagは、このような制約を課さない。

【0195】

一実施形態では、フラグsingle_layer_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいフラグsingle_layer_constraint_flagは、sps_video_parameter_set_idが０に等しくあるべきことを指定することができる。０に等しいフラグsingle_layer_constraint_flagは、このような制約を課さない。フラグgeneral_one_picture_only_constraint_flagが１に等しいとき、フラグsingle_layer_constraint_flagの値は１に等しくなり得る。

【0196】

一実施形態では、フラグall_layers_independent_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいフラグall_layers_independent_constraint_flagは、フラグvps_all_independent_layers_flagが１に等しくなり得ることを指定することができる。０に等しいフラグall_layers_independent_constraint_flagは、このような制約を課さない。フラグsingle_layer_constraint_flagが１に等しいとき、フラグall_layers_independent_constraint_flagの値は１に等しくなり得る。

【0197】

一実施形態では、フラグno_res_change_in_clvs_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいフラグno_res_change_in_clvs_constraint_flagは、フラグsps_res_change_in_clvs_allowed_flagが０に等しくなり得ることを指定することができる。０に等しいフラグno_res_change_in_clvs_constraint_flagは、このような制約を課さない。フラグno_ref_pic_resampling_constraint_flagが１に等しいとき、フラグno_res_change_in_clvs_constraint_flagの値は１に等しくなり得る。

【0198】

一実施形態では、フラグno_mixed_nalu_types_in_pic_constraint_flagが、図１３の一般制約情報構文構造に存在し得る。１に等しいフラグno_mixed_nalu_types_in_pic_constraint_flagは、フラグpps_mixed_nalu_types_in_pic_flagの値が０に等しくなり得ることを指定する。０に等しいフラグno_mixed_nalu_types_in_pic_constraint_flagは、このような制約を課さない。フラグone_subpic_per_pic_constraint_flagが１に等しいとき、フラグno_mixed_nalu_types_in_pic_constraint_flagの値は１に等しくなり得る。

【0199】

一実施形態では、フラグno_trail_constraint_flagが、図１３の一般制約情報構文構造に存在し得る。１に等しいフラグno_trail_constraint_flagは、OlsInScope内に存在するTRAIL_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる（OlsInScopeは、ＤＰＳを参照するビットストリーム全体におけるすべてのレイヤを含む出力レイヤセットである）。０に等しいフラグno_trail_constraint_flagは、このような制約を課さない。フラグgeneral_one_picture_only_constraint_flagが１に等しいとき、フラグno_trail_constraint_flagは１に等しくなり得る。

【0200】

一実施形態では、フラグno_stsa_constraint_flagは、図１３の一般制約情報構文構造に存在し得る。１に等しいフラグno_stsa_constraint_flagは、OlsInScope内に存在するSTSA_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_stsa_constraint_flagは、このような制約を課さない。フラグeneral_one_picture_only_constraint_flagが１に等しいとき、フラグno_stsa_constraint_flagは１に等しくなり得る。

【0201】

一実施形態では、フラグno_trail_constraint_flagが、図１３の一般制約情報構文構造に存在し得る。１に等しいフラグno_trail_constraint_flagは、OlsInScope内に存在するTRAIL_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_trail_constraint_flagは、このような制約を課さない。フラグgeneral_one_picture_only_constraint_flagが１に等しいとき、フラグno_trail_constraint_flagは１に等しくなり得る。

【0202】

一実施形態では、フラグno_stsa_constraint_flagが、図１３の一般制約情報構文構造に存在し得る。１に等しいフラグno_stsa_constraint_flagは、OlsInScope内に存在するSTSA_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_stsa_constraint_flagは、このような制約を課さない。フラグgeneral_one_picture_only_constraint_flagが１に等しいとき、フラグno_stsa_constraint_flagは１に等しくなり得る。

【0203】

一実施形態では、フラグno_idr_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいno_idr_constraint_flagは、OlsInScope内に存在するIDR_W_RADL又はIDR_N_LPに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいno_idr_constraint_flagは、このような制約を課さない。

【0204】

一実施形態では、フラグno_cra_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいフラグno_cra_constraint_flagは、OlsInScope内に存在するCRA_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_cra_constraint_flagは、このような制約を課さない。

【0205】

一実施形態では、フラグno_rasl_constraint_flagが、図１３の一般制約情報構文構造に存在し得る（フラグno_rasl_constraint_flagは示されていない）。１に等しいフラグno_rasl_constraint_flagは、OlsInScope内に存在するRASL_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_rasl_constraint_flagは、このような制約を課さない。フラグno_cra_constraint_flagが１に等しいとき、フラグno_rasl_constraint_flagの値は１に等しくなり得る。

【0206】

一実施形態では、フラグno_radl_constraint_flagが、図１３に示されるような一般制約情報構文構造に存在し得る。１に等しいフラグno_radl_constraint_flagは、OlsInScope内に存在するRADL_NUTに等しいnuh_unit_typeを有するＮＡＬユニットが存在し得ないことを指定することができる。０に等しいフラグno_radl_constraint_flagは、このような制約を課さない。フラグno_idr_constraint_flagが１に等しく、フラグno_cra_constraint_flagが１に等しいとき、フラグno_rasl_constraint_flagの値は１に等しくなり得る。

【0207】

本開示のいくつかの態様は、残差ライスコーディング拡張を伴うレンジ拡張のようなレンジ拡張のための制約フラグシグナリングの技術を提供する。

【0208】

本開示の態様によると、残差コーディングを、Ｒｉｃｅコーディングに基づいて実行することができる。Ｒｉｃｅコーディングは、調整可能なパラメータを使用して入力値を２つの部分に分割し、異なるコーディング技術を使用して２つの部分をコーディングする。調整可能なパラメータは、いくつかの例ではＲｉｃｅパラメータと呼ばれる。Ｒｉｃｅパラメータは、ライスコーディングのコーディング効率に影響を与える可能性がある。技術を使用して、特定のアプリケーションのＲｉｃｅパラメータを決定し、特定のアプリケーションのコーディング効率を向上させることができる。Ｒｉｃｅパラメータを決定するいくつかの技術が、ビデオ規格のレンジ拡張に含まれ得る。

【0209】

本開示の態様によると、いくつかの規格を当初、特定のアプリケーションのために開発することができる。規格を他のアプリケーションに適用可能にするために、他のアプリケーションをサポートするようにツールを用いてレンジ拡張を開発する。例えばＨＥＶＣは当初、サンプルあたり８～１０ビットの４：２：０クロマ形式のアプリケーションを対象とする。規格を特定のクロマ形式と特定のビット深度以外の他の形式とビット深度に適用可能にするために、他のクロマ形式及び／又はより高ビット深度を使用するアプリケーションをサポートするようにレンジ拡張を開発することができる。

【0210】

機能セットを、アプリケーションの特定のグループに必要なものに制限するために、ビデオコーディング規格はプロファイルを定義し、プロファイルは、これらの機能を使用するエンコーダとの相互運用性のためにサポートされるべき定義されたデコーダ機能セットを含むことができる。例えばプロファイルは、準拠するビットストリームを生成する際に使用することができる、コーディングツール又はアルゴリズムのセットを定義することができる。プロファイルに加えて、いくつかの規格（例えばＶＶＣ、ＨＥＶＣ等）はまたレベルと階層を定義する。レベルは、空間解像度、ピクセルレート、ビットレート値及びデコーダ処理負荷とメモリ能力に対応し得る変動（variation）に関連してビットストリームに制限を課す。レベル制限は、最大サンプルレート、最大ピクチャサイズ、最大ビットレート、最小圧縮比、コーディングされたピクチャバッファの容量等に関して表され得る。より高いレベルの値は、より高い複雑さの限度に対応する可能性がある。階層は、各レベルについてビットレート値と変動限度（variation limits）を変更する。例えばＭａｉｎ階層はほとんどのアプリケーションを対象としており、一方、Ｈｉｇｈ階層は、ビデオ配信アプリケーションよりも大幅に高いビットレート値を有するような、より要求の厳しいビデオ寄与アプリケーション（video contribution applications）に対処するように設計されている。プロファイル、階層及びレベルの各々が実装と復号の複雑さに影響し、３つの組合せによりビットストリームとデコーダの相互運用性ポイントを指定する。

【0211】

いくつかの例では、特定の階層とレベルに準拠するデコーダは、そのレベルの同じ階層又は下位の階層又はその下の任意のレベルに準拠するすべてのビットストリームを復号することが可能である必要があり、特定のプロファイルに準拠するデコーダは、そのプロファイル内のすべての機能をサポートすることができる。いくつかの例では、エンコーダは、プロファイルでサポートされる機能の任意の特定のセットを使用する必要はないが、準拠するビットストリーム、すなわち、準拠するデコーダによって復号されることを可能にする、指定された制約に従うビットストリームを生成する必要がある。

【0212】

ＰＴＬ情報に加えて、ＰＴＬ構文構造はまた、一般制約情報（ＧＣＩ）構文構造も含んでよく、これは、制約フラグと、ビットストリームの特定の制約プロパティを示すフラグ以外の構文要素のリストを含む。

【0213】

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

【0214】

いくつかの例では、レンジ拡張を有するＨＥＶＣは、追加のプロファイルをサポートすることができる。一例では、以下のプロファイル、すなわち：モノクロ（Monochrome）プロファイル、モノクロ１０プロファイル、モノクロ１２プロファイル、モノクロ１６プロファイル、メイン１２プロファイル、メイン４：２：２ １０プロファイル、メイン４：２：２ １２プロファイル、メイン４：４：４プロファイル、メイン４：４：４ １０プロファイル、メイン４：４：４ １２プロファイル、メインイントラ（Main Intra）プロファイル、メイン１０イントラプロファイル、メイン１２イントラプロファイル、メイン４：２：２ １０イントラプロファイル、メイン４：２：２ １２イントラプロファイル、メイン４：４：４イントラプロファイル、メイン４：４：４ １０イントラプロファイル、メイン４：４：４ １２イントラプロファイル、メイン４：４：４ １６イントラプロファイル、メイン４：４：４静止画プロファイル、メイン４：４：４ １６静止画プロファイル、をまとめてレンジ拡張プロファイルと呼ぶ。

【0215】

レンジ拡張プロファイルのいくつかは、より高ビット深度をサポートすることができ、高ビット深度の操作レンジ拡張（operation range extensions）のプロファイルと呼ぶことができる。いくつかの例では、高ビット深度の操作レンジ拡張のプロファイルは、メイン１２プロファイル、メイン１２ ４：４：４プロファイル、メイン１６ ４：４：４プロファイル、メイン１２イントラプロファイル、メイン１２ ４：４：４イントラプロファイル、メイン１６ ４：４：４イントラプロファイル、メイン１２静止画プロファイル、メイン１２ ４：４：４静止画プロファイル、メイン１６ ４：４：４静止画プロファイル等のような、サンプルあたり１０ビット超をサポートするプロファイルを含む。

【0216】

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

【0217】

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

【0218】

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

【0219】

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

【0220】

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

【0221】

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

【0222】

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

【0223】

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

【0224】

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

【0225】

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

【0226】

本開示の態様によると、レンジ拡張におけるコーディングツールの制御情報を、様々な範囲で提供することができる。いくつかの例では、より大きな範囲の構文要素を使用することは、コーディング効率を改善させることができる。例えば０より大きいＧＣＩ構文要素の値は、ビットストリームが特定の方法で制約されることを示し、典型的には、特定のコーディングツールがビットストリームで使用されないことを示す。さらに、値０に等しいＧＣＩ構文要素の値は、関連するコーディングツールが（指示されたプロファイルでその使用がサポートされている場合）ビットストリームで使用されることが許容される（ただし、必要とはされない）ように、関連する制約が適用され得ないことをシグナリングする。

【0227】

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

【0228】

いくつかの実施形態では、エンコーダは、レンジ拡張を伴うビデオ規格に準拠したビットストリームを生成することができるが、レンジ拡張でサポートされる１つ以上の機能の使用は行わない。いくつかの例では、レンジ拡張における１つ以上の機能の不使用がわかっている場合、ビデオ規格に準拠しているが、レンジ拡張で１つ以上の機能をサポートしていないデコーダは、該デコーダがビットストリームを復号することが可能であると判断してよく、ビットストリームを拒絶する代わりに、復号のためにビットストリームを受け入れてよい。

【0229】

図１６は、本開示のいくつかの実施形態による一般制約情報の構文構造（１６００）を示す。いくつかの例では、構文構造（１６００）は、デコーダへの出力レイヤセットを含むビットストリームのような、ビットストリームに適用される制約を含む。図１６の例では、構文構造（１６００）のgci_num_additional_bitsによって示される構文要素は、アライメントゼロビット構文要素（存在する場合）以外の一般制約情報構文構造（１６００）内の追加の一般制約情報（ＧＣＩ）ビットの数を指定するために使用される。いくつかの規格では、gci_num_additional_bitsの値は、０又は１に等しいことが要求される。いくつかの規格では、デコーダは、１より大きいgci_num_additional_bitsの値が構文構造に表れることを許容し得る。

【0230】

図１６の例では、構文構造（１６００）は、general_no_extended_precision_constraint_flag、general_no_ts_residual_coding_rice_present_in_sh_constraint_flag、general_no_rrc_rice_extension_constraint_flag、general_no_persistent_rice_adaptation_constraint_flag及びgeneral_no_reverse_last_sig_coeff_constraint_flagによって示される５つの追加ＧＣＩビット（構文要素）（１６０１）～（１６０５）を含む。５つの追加ＧＣＩビット（１６０１）～（１６０５）はそれぞれ、いくつかの例では、出力レイヤセットのビットストリームの範囲におけるコーディングツールのコーディング制御情報を提供する。

【0231】

図１７は、本開示のいくつかの実施形態によるシーケンスパラメータセット（ＳＰＳ）レンジ拡張の構文構造（１７００）の例を示す。構文構造（１７００）は、ＣＬＶＳのレンジ拡張のコーディングツールの制御を提供するためにＣＬＶＳのＳＰＳに追加され得る。構文構造（１７００）は、sps_extended_precision_flag、sps_ts_residual_coding_rice_present_in_sh_flag、sps_rrc_rice_extension_flag、sps_persistent_rice_adaptation_enabled_flag及びsps_reverse_last_sig_coeff_enabled_flagによって示される５つの構文要素（１７０１）～（１７０５）を含む。５つの構文要素（１７０１）～（１７０５）は、いくつかの例では、ＣＬＶＳの範囲内のコーディングツールのコーディング制御情報を提供する。

【0232】

具体的には、一実施形態では、ＧＣＩビット（１６０１）及び構文要素（１７０１）は、異なる範囲において、スケーリング及び変換プロセスにおける変換係数のため、並びにabs_remainder[]及びdec_abs_level[]等のようないくつかの構文要素の二値化のための拡張ダイナミックレンジのコーディングツールの制御のような、拡張された精度を使用する制御を提供する。

【0233】

１に等しい構文要素（１７０１）は、拡張ダイナミックレンジが、スケーリング及び変換プロセスにおける変換係数のため、並びにabs_remainder[]及びdec_abs_level[]等のようないくつかの構文要素の二値化のために使用されることを指定する。構文要素abs_remainder[scanning position n]は、スキャン位置ｎにおいてＧｏｌｏｍｂ－Ｒｉｃｅコードでコーディングされる変換係数レベルの残りの絶対値である。abs_remainder[]が存在しないとき、０に等しいと推論される。構文要素dec_abs_level[scanning position n]は、スキャン位置ｎにおけるＧｏｌｏｍｂ－Ｒｉｃｅコードでコーディングされる中間値に対応することができ、スキャン位置ｎにおける変換係数のレベルを決定するために使用される。０に等しい構文要素（１７０１）は、拡張ダイナミックレンジがスケーリング及び変換プロセスにおいて使用されず、例えば構文要素abs_remainder[]及びdec_abs_level[]等のような二値化に使用されないことを指定する。存在しないとき、構文要素（１７０１）の値は０に等しいと推論される。

【0234】

一例では、Log2TransformRangeによって示される変数を使用して、スケーリング及び変換プロセスにおける変換係数と、特定の構文要素の二値化とのためのダイナミックレンジを決定する。例えば変数Log2TransformRangeは、スケーリング及び変換プロセスにおける変換係数を表すため、並びに特定の構文要素の二値化のためのビット数とすることができる。ダイナミックレンジは、ビット数を使用して表される最大数と最小数の差とすることができる。一例では、変数Log2TransformRangeは、例えば式（１）を使用して、構文要素（１７０１）sps_extended_precision_flagに従って導出される：
Log2TransformRange = sps_extended_precision_flag ? Max( 15, Min( 20, BitDepth + 6 ) ) : 15 式（１）

【0235】

スケーリング及び変換プロセスにおける変換係数と、特定の構文要素の二値化とのためのダイナミックレンジを、変数Log2TransformRangeに基づいて決定することができる。いくつかの例では、フラグsps_extended_precision_flagが値０を有するとき、拡張ダイナミックレンジ機能（例えば拡張ダイナミックレンジのコーディングツール）は使用されず、変換係数のダイナミックレンジは、１５ビットのような固定数のビットに基づく。フラグsps_extended_precision_flagが値１を有するとき、拡張ダイナミックレンジ機能が有効になり、スケーリング及び変換処理における変換係数を表すビット数は、式（１）の例におけるビット深度BitDepthに基づいて、１５ビット、１６ビット、１７ビット、１８ビット、１９ビット及び２０ビットのうちの１つとすることができる。変換係数のダイナミックレンジを、ビット数に基づいて決定することができる。

【0236】

本開示の一態様によると、構文要素（例えばsps_bitdepth_minus8によって示される）を使用して、ルマ及びクロマアレイのサンプルのビット深度（例えばBitDepthによって示される）と、ルマ及びクロマ量子化パラメータレンジオフセットの値（例えばQpBdOffsetによって示される）をシグナリングすることができる。一例では、ビット深度BitDepthを、式（２）に従って計算することができ、ＱＰレンジオフセットQpBdOffsetを、式（３）に従って計算することができる：
BitDepth = 8 + sps_bitdepth_minus8 式（２）
QpBdOffset = 6 × sps_bitdepth_minus8 式（３）

【0237】

いくつかの例では、１に等しいＧＣＩビット（１６０１）は、出力レイヤセットの範囲（OlsInScope）内のすべてのピクチャの構文要素（１７０１）が０に等しくなり得ることを指定する。０に等しいＧＣＩビット（１６０１）は、そのような制約を課さない。したがって、１に等しいＧＣＩビット（１６０１）は、ビットストリームのコーディングにおける拡張ダイナミックレンジコーディングツールの不使用を指定することができる。

【0238】

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

【0239】

本開示の一態様によると、変換スキップ残差コーディングのためのスライスベースのＲｉｃｅパラメータ選択を、ビデオ規格のレンジ拡張に含めることができる。いくつかの例では、図１７に示されるように、変換スキップスライスのＲｉｃｅパラメータのシグナリングが有効又は無効にされることを示すために、変換スキップモードが有効にされるとき（例えば構文要素sps_tranform_skip_enabled_flagが真）、１つの制御フラグ（例えばsps_ts_residual_coding_rice_present_in_sh_flag構文要素（１７０２）によって示される）がシーケンスパラメータセット（ＳＰＳ）においてシグナルされる。

【0240】

制御フラグが有効（例えば「１」に等しい）としてシグナルされるとき、例えばスライスヘッダにおいて、各変換スキップスライスに対して１つの構文要素（例えばsh_ts_residual_coding_rice_idx_minus1によって示される）が更にシグナリングされ、その変換スキップスライスのＲｉｃｅパラメータの選択を示す。制御フラグが無効（例えば「０」に等しい）としてシグナルされるとき、変換スキップスライスのＲｉｃｅパラメータの選択を示すために、スライスレベル（例えばスライスヘッダ）で更なる構文要素はシグナルされず、一例では、ＳＰＳを参照するコーディングされたビデオデータ内のすべての変換スキップスライスに対してデフォルトのＲｉｃｅパラメータが使用され得る。

【0241】

例えばＳＰＳ内の１に等しい構文要素（１７０２）は、sh_ts_residual_coding_rice_idx_minus1によって示されるスライスヘッダフラグが、ＳＰＳを参照するスライスのスライスヘッダ（例えばslice_header()）構文構造内に存在し得ることを指定する。ＳＰＳ内の０に等しい構文要素（１７０２）は、スライスヘッダフラグsh_ts_residual_coding_rice_idx_minus1が、ＳＰＳを参照するスライスのslice_header()構文構造内に存在しないことを指定する。存在しないとき、sps_ts_residual_coding_rice_present_in_sh_flagの値は、いくつかの例で０に等しいと推論される。

【0242】

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

【0243】

いくつかの実施形態では、ＧＣＩビット（１６０３）及び構文要素（１７０３）を使用して、異なる範囲において、正規残差コーディング（ＲＲＣ：regular residual coding）におけるabs_remainder[]及びdec_abs_level[]等のようないくつかの構文要素の二値化のためのＲｉｃｅパラメータ導出のための１つ以上のコーディングツールの制御を提供する。いくつかの例では、正規残差コーディング（ＲＲＣ）は、変換及び量子化によって取得されるブロックをコーディングするためのいくつかの技術を指す。いくつかの例では、量子化のみによって取得されるブロックのためにＲＲＣを変更することができる。いくつかの例では、変換スキップ残差コーディング（ＴＳＲＣ：transform skip residual coding）は、変換をバイパスすること（変換スキップとも呼ばれる）によって取得されるブロックをコーディングするための専用のいくつかの技術を指す。

【0244】

いくつかの例では、ビデオコーディング規格は、abs_remainder[]及びdec_abs_level[]のような、いくつかの構文要素の二値化のためのＲｉｃｅパラメータ導出のための１つ以上のコーディングツールを含んでよく、ビデオコーディング規格のレンジ拡張は、abs_remainder[]及びdec_abs_level[]のような、いくつかの構文要素の二値化のためのＲｉｃｅパラメータ導出のための１つ以上の代替コーディングツールを含むことができる。

【0245】

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

【0246】

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

【0247】

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

【0248】

いくつかの例では、１に等しいＳＰＳ内の構文要素（１７０３）は、abs_remainder[]及びdec_abs_level[]の二値化のための代替Ｒｉｃｅパラメータ導出（例えばレンジ拡張におけるＲｉｃｅパラメータ導出のための代替コーディングツール）が、ＳＰＳを参照するＣＬＶＳをコーディングするために使用されることを指定する。０に等しい構文要素（１７０３）は、abs_remainder[]及びdec_abs_level[]の二値化のための代替Ｒｉｃｅパラメータ導出が、ＳＰＳを参照するＣＬＶＳをコーディングするために使用されないことを指定する。存在しないとき、構文要素（１７０３）の値は０に等しいと推論される。

【0249】

いくつかの例では、１に等しい構文要素（１６０３）は、出力レイヤセットの範囲（OlsInScope）内のすべてのピクチャの構文要素（１７０３）が０に等しくなり得ることを指定する。０に等しい構文要素（１６０３）は、このような制約を課さない。したがって、いくつかの例では、１に等しいＧＣＩビット（１６０３）は、ビットストリームをコーディングするために、abs_remainder[]及びdec_abs_level[]の二値化に、代替Ｒｉｃｅパラメータ導出（例えば指定されたレンジ拡張で指定されたＲｉｃｅパラメータ導出のための代替コーディングツール）の不使用を指定することができる。

【0250】

いくつかの実施形態では、ＧＣＩビット（１６０４）及び構文要素（１７０４）を使用して、異なる範囲において、abs_remainder[]及びdec_abs_level[]の二値化のための統計ベースのＲｉｃｅパラメータ導出の制御を提供する。

【0251】

本開示の一態様によると、abs_remainder[]及びdec_abs_level[]の二値化のためのＲｉｃｅパラメータ導出を、以前のＴＵから蓄積された統計を使用して各変換ユニット（ＴＵ）の開始時に初期化することができる。いくつかの例では、統計ベースのＲｉｃｅパラメータ導出を、ビデオ規格のレンジ拡張に含めることができる。

【0252】

いくつかの例では、制御フラグ、例えばＳＰＳ内のsps_persistent_rice_adaptation_enabled_flagによって示される構文要素（１７０４）を使用して、統計ベースのＲｉｃｅパラメータ導出を制御する。例えばＳＰＳ内の１に等しい構文要素（１７０４）は、abs_remainder[]及びdec_abs_level[]の二値化のためのＲｉｃｅパラメータ導出が、以前のＴＵから蓄積された統計を使用して各ＴＵの開始時に初期化されることを指定する。０に等しい構文要素（１７０４）は、以前のＴＵ状態が現在のＴＵのＲｉｃｅパラメータ導出で使用されないことを指定する。存在しないとき、構文（１７０４）の値は０に等しいと推論される。

【0253】

さらに、一実施形態では、１に等しい構文要素（１６０４）は、出力レイヤセットの範囲（OlsInScope）内のすべてのピクチャの構文要素（１７０４）が０に等しくなり得ることを指定する。０に等しい構文要素（１６０４）は、このような制約を課さない。したがって、いくつかの例では、１に等しいＧＣＩビット（１６０４）は、ビットストリームのコーディングのための統計ベースのＲｉｃｅパラメータ導出の不使用を指定することができる。

【0254】

いくつかの実施形態では、ＧＣＩビット（１６０５）及び構文要素（１７０５）を使用して、異なる範囲において、変換係数のエントロピーコーディング中に最後の有意係数（significant coefficient）の位置をコーディングするために使用されるコーディングツールの制御を提供する。一例では、最後の有意係数の位置を、異なるコーディングツールによってコーディングすることができる。例えばビデオ規格は、LastSignificantCoeffX変数及びLastSignificantCoeffY変数によって示される位置の２つの座標をコーディングすることによって、最後の有意係数の位置を決定することができる、第１コーディングツールを指定してよく、ビデオ規格のレンジ拡張は、一例ではゼロアウト変換ブロックの右下隅を参照して、最後の有意係数の相対座標をコーディングすることによって、最後の有意係数の位置を決定することができる第２コーディングツールのような、代替のコーディングツールを指定することができる。

【0255】

いくつかの例では、ＳＰＳ内の１に等しい構文要素（１７０５）は、sh_reverse_last_sig_coeff_flagによって示されるスライスヘッダフラグ（スライス範囲）が、ＳＰＳを参照するスライスヘッダ構文構造（例えばいくつかの例ではslice_header()）内に存在することを指定する。ＳＰＳ内の０に等しい構文要素（１７０５）は、スライスヘッダフラグsh_reverse_last_sig_coeff_flagが、ＳＰＳを参照するスライスヘッダ構文構造内に存在しないことを指定し、スライスヘッダフラグsh_reverse_last_sig_coeff_flagは０であると推論され得る。存在しないとき、構文要素（１７０５）の値は０に等しいと推論される。

【0256】

いくつかの例では、スライスのスライスヘッダフラグsh_reverse_last_sig_coeff_flagの値を使用して、スライスのコーディングにおけるスケーリング及び変換プロセスでの変換係数の最後の有意係数の位置導出を決定する。一例では、sh_reverse_last_sig_coeff_flagが１に等しいとき、最後の有意係数の位置は、第２コーディングツールのような、ビデオ規格のレンジ拡張における代替コーディングツールによってコーディングされ、そうでない場合、最後の有意係数の位置の現在の座標は、第１コーディングツールによってコーディングされる。

【0257】

いくつかの例では、１に等しいＧＣＩビット（１６０５）は、出力レイヤセットの範囲（OlsInScope）内のすべてのピクチャの構文要素（１７０５）が０に等しくなり得ることを指定する。０に等しいＧＣＩビット（１６０５）は、このような制約を課さない。したがって、１に等しいＧＣＩビット（１６０５）は、ビットストリームの範囲に対する最後の有意係数の位置導出における第２コーディングツールの不使用を指定することができる。

【0258】

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

【0259】

（Ｓ１８１０）において、ビットストリーム内のコーディングされたビデオデータの第１範囲（例えば出力レイヤセット）におけるコーディング制御のための第１構文要素（例えばgeneral_no_rrc_rice_extension_constraint_flag）の値を決定する。第１構文要素は、残差コーディングにおけるＲｉｃｅパラメータ導出のための第１コーディングツールに代わる第２コーディングツールに関連付けられる。

【0260】

一例では、構文構造内の構文要素（例えばgci_num_additional_bits）が構文構造内の一般制約情報の追加ビットを示すことに応答して、第１構文要素を一般制約情報の構文構造から復号する。

【0261】

いくつかの例では、第１コーディングツールは規格で定義され、第２コーディングツールは、第１コーディングツールに対する代替コーディングツールとして規格のレンジ拡張で定義される。一例では、ビデオデコーダは規格をサポートし得るが、該規格のレンジ拡張における第２コーディングツールはサポートし得ない。

【0262】

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

【0263】

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

【0264】

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

【0265】

いくつかの例では、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２構文要素（例えばsps_extended_precision_flag）は、ＣＬＶＳを復号するために第２コーディングツールを呼び出さないことを示す値を有するように制約される。

【0266】

（Ｓ１８４０）において、第１構文要素が第２値であることに応答して、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のような、コーディングされたビデオデータの第２範囲のコーディング制御のための第２構文要素（例えばsps_extended_precision_flag）の値が、第２範囲内のコーディングされたビデオデータの復号のために決定される。第２構文要素は、ＣＬＶＳ内の第２コーディングツールの使用／不使用を示す。一例では、第２構文要素は、ＣＬＶＳのシーケンスパラメータセット（ＳＰＳ）内に提示されず、第２構文要素の値は、ＣＬＶＳ内の第２コーディングツールの不使用を示すために推論される。

【0267】

コーディングされたビデオデータの第２範囲は、次いで、（例えば第２コーディングツールを呼び出して又は呼び出さずに）第２構文要素の値に従って復号される。

【0268】

プロセス（１８００）を、適切に適応させることができる。プロセス（１８００）のステップを、変更及び／又は省略することができる。追加のステップを追加することができる。任意の適切な実装順序を使用することができる。

【0269】

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

【0270】

（Ｓ１９１０）において、処理回路は、第１コーディングツールに代わる第２コーディングツールが、ビットストリーム内のコーディングされたビデオデータの第１範囲（例えば出力レイヤセット）の符号化中に使用されるかどうかを判断する。第２コーディングツールは、残差コーディングにおけるＲｉｃｅパラメータ導出のための第１コーディングツールに代わるコーディングツールである。コーディングされたビデオデータの第１範囲は、コーディングされたビデオデータの１つ以上の第２範囲（例えばＣＬＶＳ）を含む。

【0271】

いくつかの例では、処理回路は、ビットストリーム内のコーディングされたレイヤビデオシーケンス（ＣＬＶＳ）のコーディング制御のための第２構文要素（例えばsps_extended_precision_flag）に基づいて、第２コーディングツールが使用されるかどうかを判断することができる。

【0272】

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

【0273】

（Ｓ１９３０）において、第１値を有する第１構文要素（例えばgeneral_no_rrc_rice_extension_constraint_flag）が、ビットストリームに符号化される。第１構文要素は、ビットストリーム内のコーディングされたビデオデータの第１範囲（例えば出力レイヤセット）におけるコーディング制御のためのものである。第１構文要素は、残差コーディングにおけるＲｉｃｅパラメータ導出のための第２コーディングツールに関連付けられる。第１値は、コーディングされたビデオデータの第１範囲のコーディングにおける第２コーディングツールの不使用を示す。

【0274】

一例では、第１構文要素は、一般制約情報のための構文構造で符号化され、該構文構造内の構文要素（例えばgci_num_additional_bits）は、該構文構造内の一般制約情報の追加ビットを示すように調整される。

【0275】

（Ｓ１９４０）において、第２値を有する第１構文要素が、ビットストリームに符号化される。いくつかの例では、第１構文要素はビットストリームに符号化されず、例えば第２値が第１構文要素のデフォルト値であり、したがって、提示されていない場合に第１構文要素を推論することができる場合には、次いで（Ｓ１９４０）をスキップすることができる。

【0276】

プロセス（１９００）を、適切に適応させることができる。プロセス（１９００）のステップを変更及び／又は省略することができる。追加のステップを追加することができる。任意の適切な実装順序を使用することができる。

【0277】

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

【0278】

コンピュータソフトウェアは、アセンブリ、コンパイル、リンキング又は類似のメカニズムの対象となり得る任意の適切な機械コード又はコンピュータ言語を使用してコーディングされ、１つ以上のコンピュータ中央処理ユニット（ＣＰＵ）、グラフィクス処理ユニット（ＧＰＵ）等によって直接的に又は解釈やマイクロコード実行等を通して実行され得る命令を含む、コードを作成することができる。

【0279】

命令は、例えばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイス等を含む様々なタイプのコンピュータ又はその構成要素において実行されることができる。

【0280】

コンピュータシステム（２０００）について図２０に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能性に関して、いかなる制限も示唆するように意図されていない。また、構成要素の構成は、コンピュータシステム（２０００）の例示的実施形態に示される構成要素の任意の１つ又は組合せに関するいかなる依存性又は要件も有するものとして解釈されてはならない。

【0281】

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

【0282】

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

【0283】

コンピュータシステム（２０００）はまた、特定のヒューマンインタフェース出力デバイスも含み得る。そのようなヒューマンインタフェース出力デバイスは、例えば触覚出力、音響、光及び嗅覚／味覚を通して、１人以上の人間のユーザの感覚を刺激し得る。そのようなヒューマンインタフェース出力デバイスは、触覚出力デバイス（例えばタッチ画面（２０１０）、データグローブ（図示せず）又はジョイスティック（２００５）による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスが存在する可能性もある）、オーディオ出力デバイス（スピーカー（２００９）、ヘッドフォン（図示せず）等）、視覚出力デバイス（各々タッチ画面入力機能の有無にかかわらず、各々触覚フィードバック機能の有無にもかかわらないが、その一部は、立体画像出力や仮想現実グラス（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）のような手段を通して、２次元視覚出力又は３次元超の出力を出力することができる、ＣＲＴ画面、ＬＣＤ画面、プラズマ画面、ＯＬＥＤ画面を含む画面（２０１０）等）及びプリンタ（図示せず）を含んでよい。

【0284】

コンピュータシステム（２０００）はまた、ＣＤ／ＤＶＤを有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ（２０２０）を含む光媒体又は類似の媒体（２０２１）、サムドライブ（２０２２）、取り外し可能ハードドライブ又はソリッドステートドライブ（２０２３）、テープ及びフロッピーディスク（図示せず）のようなレガシー磁気媒体、セキュリティドングル（図示せず）のような特別なＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイスのような、ヒューマンアクセス可能なストレージデバイス及びそれらの関連する媒体も含むことができる。

【0285】

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

【0286】

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

【0287】

前述のヒューマンインタフェースデバイス、ヒューマンアクセス可能なストレージデバイス及びネットワークインタフェースを、コンピュータシステム（２０００）のコア（２０４０）に取り付けることができる。

【0288】

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

【0289】

ＣＰＵ（２０４１）、ＧＰＵ（２０４２）、ＦＰＧＡ（２０４３）及びアクセラレータ（２０４４）は、組み合わされて上述のコンピュータコードを構成することができる、特定の命令を実行することができる。そのコンピュータコードを、ＲＯＭ（２０４５）又はＲＡＭ（２０４６）に記憶することができる。また、一時的なデータをＲＡＭ（２０４６）に記憶することができ、一方、永久的なデータを、例えば内部大容量ストレージ（２０４７）に記憶することができる。１つ以上のＣＰＵ（２０４１）、ＧＰＵ（２０４２）、大容量ストレージ（２０４７）、ＲＯＭ（２０４５）、ＲＡＭ（２０４６）等と密接に関連付けることができるキャッシュメモリの使用を通して、メモリデバイスのいずれかに対する高速記憶及び取り出しを可能にすることができる。

【0290】

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

【0291】

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

付録Ａ：頭字語
ＪＥＭ：joint exploration model
ＶＶＣ：versatile video coding
ＢＭＳ：ベンチマークセット（benchmark set）
ＭＶ：動きベクトル（Motion Vector）
ＨＥＶＣ：高効率ビデオコーディング（High Efficiency Video Coding）
ＳＥＩ：補足強化情報（Supplementary Enhancement Information）
ＶＵＩ：ビデオユーザビリティ情報（Video Usability Information）
ＧＯＰｓ：ピクチャのグループ（Groups of Pictures）
ＴＵｓ：変換ユニット（Transform Units）
ＰＵｓ：予測ユニット（Prediction Units）
ＣＴＵｓ：コーディングツリーユニット（Coding Tree Units）
ＣＴＢｓ：コーディングツリーブロック（Coding Tree Blocks）
ＰＢｓ：予測ブロック（Prediction Blocks）
ＨＲＤ：仮想リファレンスデコーダ（Hypothetical Reference Decoder）
ＳＮＲ：信号対ノイズ比（Signal Noise Ratio）
ＣＰＵｓ：中央処理ユニット（Central Processing Units）
ＧＰＵｓ：グラフィクス処理ユニット（Graphics Processing Units）
ＣＲＴ：ブラウン管（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 Array）
ＳＳＤ：ソリッドステートドライブ（solid-state drive）
ＩＣ：集積回路（Integrated Circuit）
ＣＵ：コーディングユニット（Coding Unit）

【0292】

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

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14A】

【図14B】

【図15A】

【図15B】

【図16】

【図17】

【図18】

【図19】

【図20】