特許7551225 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ テンセント・アメリカ・エルエルシーの特許一覧

特許7551225ビデオデータをコーディングするための方法、装置、およびコンピュータプログラム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

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

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

(11)【特許番号】

(24)【登録日】2024-09-06

(45)【発行日】2024-09-17

(54)【発明の名称】ビデオデータをコーディングするための方法、装置、およびコンピュータプログラム

(51)【国際特許分類】

H04N 19/70 20140101AFI20240909BHJP

【ＦＩ】

H04N19/70

【請求項の数】 9

(21)【出願番号】P 2021562365

(86)(22)【出願日】2021-02-15

(65)【公表番号】

(43)【公表日】2022-07-06

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

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

(87)【国際公開日】2021-10-07

【審査請求日】2021-10-20

【審判番号】

【審判請求日】2023-07-20

(31)【優先権主張番号】63/003,112

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

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

(31)【優先権主張番号】17/087,865

(32)【優先日】2020-11-03

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾直樹

(72)【発明者】

【氏名】ビョンドゥ・チェ

(72)【発明者】

【氏名】シャン・リュウ

(72)【発明者】

【氏名】ステファン・ヴェンガー

【合議体】

【審判長】畑中高行

【審判官】圓道浩史

【審判官】高橋宣博

(56)【参考文献】

【文献】ＢｅｎｊａｍｉｎＢｒｏｓｓ，ＪｉａｎｌｅＣｈｅｎ，ＳｈａｎＬｉｕ，ａｎｄＹｅ－ＫｕｉＷａｎｇ，ＶｅｒｓａｔｉｌｅＶｉｄｅｏＣｏｄｉｎｇ（Ｄｒａｆｔ８），ＪｏｉｎｔＶｉｄｅｏＥｘｐｅｒｔｓＴｅａｍ（ＪＶＥＴ）ｏｆＩＴＵ－ＴＳＧ１６ＷＰ３ａｎｄＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１，ＪＶＥＴ－Ｑ２００１（ｖｅｒｓｉｏｎ１５），１７ｔｈＭｅｅｔｉｎｇ：Ｂｒｕｓｓｅｌｓ，ＢＥ，２０２０年０３月１２日，ｐｐ．４７－５０，１１９－１２６，１７２－１７４

【文献】ＢｅｎｊａｍｉｎＢｒｏｓｓ，ＪｉａｎｌｅＣｈｅｎ，ａｎｄＳｈａｎＬｉｕ，ＶｅｒｓａｔｉｌｅＶｉｄｅｏＣｏｄｉｎｇ（Ｄｒａｆｔ６），ＪｏｉｎｔＶｉｄｅｏＥｘｐｅｒｔｓＴｅａｍ（ＪＶＥＴ）ｏｆＩＴＵ－ＴＳＧ１６ＷＰ３ａｎｄＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１，ＪＶＥＴ－Ｏ２００１（ｖｅｒｓｉｏｎ１４），１５ｔｈＭｅｅｔｉｎｇ：Ｇｏｔｈｅｎｂｕｒｇ，ＳＥ，２０１９年０７月３１日，ｐｐ．５０－５４，１２０－１２９，１５３－１５５

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

H04N 19/00-19/98

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

【請求項1】

プロセッサによって実行可能な、ビデオデータを符号化するための方法であって、
現在ピクチャおよび1つまたは複数の他のピクチャを含むビデオデータを受信するステップと、
第1のフラグおよび第2のフラグに設定された値に基づいて前記ビデオデータを符号化するステップであって、前記現在ピクチャは、前記第1のフラグが、前記現在ピクチャが1つまたは複数の他の後続のピクチャによって参照されないことを示す1に設定され、かつ前記第2のフラグが、前記現在ピクチャが出力されないことを示す0に設定された場合、出力ビットストリームに符号化されない、ステップと、
前記現在ピクチャが前記1つまたは複数の他の後続のピクチャによって参照されるかどうかを示す前記第1のフラグをシグナリングするステップと、
前記現在ピクチャが出力されるかどうかを示す前記第2のフラグをシグナリングするステップと
を含む、方法。

【請求項2】

前記第1のフラグおよび前記第2のフラグは、前記ビデオデータに関連付けられたピクチャヘッダまたはスライスヘッダでシグナリングされる、請求項１記載の方法。

【請求項3】

前記第1のフラグは、前記現在ピクチャが動き補償またはパラメータ予測のために参照されるかどうかに対応する、請求項１または２に記載の方法。

【請求項4】

前記第2のフラグは、前記現在ピクチャが表示または他の目的のためにクロップされて出力されるかどうかに対応する、請求項１から３のうちいずれか一項に記載の方法。

【請求項5】

前記第2のフラグの値は、前記第1のフラグの値に基づいて推測される、請求項１から４のうちいずれか一項に記載の方法。

【請求項6】

前記第2のフラグの値は、エンコーダ側またはデコーダ側で推測される、請求項５に記載の方法。

【請求項7】

前記ビデオデータを符号化するステップは、アクセスユニット毎のピクチャ順序カウントサイクルの値にさらに基づき、ピクチャ順序カウント値がアクセスユニット毎に一律に増加する場合は、前記アクセスユニット毎のピクチャ順序カウントサイクルの値は、ビデオパラメータセットにおいてシグナリングされ、アクセスユニット毎のピクチャ順序カウントサイクルの値ピクチャ順序カウント値がアクセスユニット毎に一律に増加しない場合は、前記アクセスユニット毎のピクチャ順序カウントサイクルの値は、スライスヘッダにおいてシグナリングされる、請求項１から６のうちいずれか一項に記載の方法。

【請求項8】

請求項１から７のいずれか一項に記載の方法を行うように構成された、ビデオデータを符号化するための装置。

【請求項9】

ビデオデータを符号化するための装置のコンピュータに、請求項１から７のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願への相互参照
本出願は、2020年3月31日に出願された米国仮特許出願第63／003，112号、および2020年11月3日に出願された米国特許出願第17／087，865号に基づく優先権を主張し、その全体が本明細書に組み込まれる。

【0002】

本開示は、一般に、データ処理の分野に関し、より詳細には、ビデオエンコーディングおよびデコーディングに関する。

【背景技術】

【0003】

動き補償を伴うインターピクチャ予測を用いたビデオコーディングおよびデコーディングは、何十年にもわたり知られている。非圧縮デジタルビデオは、各ピクチャが例えば1920×1080の輝度サンプルと関連付けられた色差サンプルの空間次元を有する、一連のピクチャからなりうる。一連のピクチャは、例えば毎秒60ピクチャすなわち60 Hzの固定または可変のピクチャレート（非公式にはフレームレートとも呼ばれる）を有し得る。非圧縮ビデオには、重要なビットレート要件がある。例えば、サンプルあたり8ビットの1080p60 4：2：0ビデオ（60 Hzのフレームレートで1920×1080輝度サンプル解像度）は、1．5 Gbit／sに近い帯域幅を必要とする。このようなビデオを1時間使用するには、600 GBを超える記憶領域が必要である。

【0004】

ビデオのコーディングとデコーディングの1つの目的は、圧縮によって入力ビデオ信号の冗長性を減らすことであり得る。圧縮は、前述の帯域幅または記憶領域の要件を、場合によっては2桁以上削減するのに役立ち得る。可逆圧縮と非可逆圧縮の両方、およびそれらの組み合わせが使用されうる。可逆圧縮とは、圧縮された元の信号から元の信号の正確な複製を再構築できる技術を指す。非可逆圧縮を用いる場合、再構築された信号は元の信号と同一ではない可能性があるが、元の信号と再構築された信号との間の歪みは十分に小さいため、再構築された信号は目的の用途に役立つ。ビデオの場合、非可逆圧縮が広く採用されている。許容される歪みの量は用途によって異なる。例えば、特定の消費者ストリーミング用途のユーザは、テレビ投稿用途のユーザよりも高い歪みを許容し得る。達成可能な圧縮率は、より高い許容／許容歪みにより、より高い圧縮率が得られることを反映し得る。

【0005】

ビデオエンコーダおよびデコーダは、例えば、そのうちのいくつかが以下に紹介される、動き補償、変換、量子化、エントロピーコーディングなど、いくつかの広範なカテゴリの技術を利用できる。

【0006】

歴史的に、ビデオエンコーダおよびデコーダは、ほとんどの場合、コード化されたビデオシーケンス（CVS）、Group of Pictures（GOP）、または同様のマルチ・ピクチャ・タイム・フレームに対して定義され一定のままであった所与のピクチャサイズで動作する傾向があった。例えば、MPEG－2では、システム設計は、シーンのアクティビティなどの要因に依存して水平解像度（それによって、ピクチャサイズ）を変更することが知られているが、Iピクチャにおいてのみであり、したがって典型的にはGOP用である。CVS内で異なる解像度を使用するための参照ピクチャの再サンプリングは、例えばITU－T Rec．H．263 Annex Pから知られている。しかしながら、ここではピクチャサイズは変化せず、参照ピクチャのみが再サンプリングされ、ピクチャキャンバスの一部のみが使用される（ダウンサンプリングの場合）、またはシーンの一部のみがキャプチャされる（アップサンプリングの場合）可能性がある。さらに、H．263 Annex Qにより、個々のマクロブロックを上方または下方に（各次元で）2倍だけ再サンプリングすることが可能になる。ここでも、ピクチャサイズは同じままである。マクロブロックのサイズはH．263では固定されているため、シグナリングする必要はない。

【0007】

予測ピクチャのピクチャサイズの変更は、最新のビデオコーディングにおいてより主流になった。例えば、VP9は、参照ピクチャの再サンプリングおよびピクチャ全体の解像度の変更を可能とする。同様に、VVCに向けてなされたある提案（例えば、その全体が本明細書に組み込まれる、Hendry他著、「On adaptive resolution change（ARC）for VVC」、Joint Video Team文書JVET－M0135－v1、2019年1月9～19日を含む）は、参照ピクチャ全体を異なる（より高いまたはより低い）解像度へ再サンプリングすることを可能とする。その文書では、異なる候補解像度がシーケンス・パラメータ・セット内でコード化され、ピクチャ・パラメータ・セット内のピクチャ毎のシンタックス要素によって参照されることが提案されている。

【発明の概要】

【課題を解決するための手段】

【0008】

実施形態は、ビデオデータをコーディングするための方法、システム、およびコンピュータ可読媒体に関する。一態様によれば、ビデオデータをコーディングするための方法が提供される。この方法は、現在ピクチャおよび1または複数の他のピクチャを含むビデオデータを受信することを含み得る。現在ピクチャが1つまたは複数の他のピクチャによってデコード順に参照されているかどうかに対応する第1のフラグがチェックされる。現在ピクチャが出力されるかどうかに対応する第2のフラグがチェックされる。ビデオデータは、第1のフラグおよび第2のフラグに対応する値に基づいてデコードされる。

【0009】

別の態様によれば、ビデオデータをコーディングするためのコンピュータシステムが提供される。コンピュータシステムは、1つまたは複数のプロセッサと、1つまたは複数のコンピュータ可読メモリと、1つまたは複数のコンピュータ可読有形記憶装置と、1つまたは複数のメモリのうちの少なくとも1つを介して1つまたは複数のプロセッサのうちの少なくとも1つによって実行するために1つまたは複数の記憶装置のうちの少なくとも1つに記憶されたプログラム命令とを含むことができ、それによってコンピュータシステムは方法を実行することができる。この方法は、現在ピクチャおよび1または複数の他のピクチャを含むビデオデータを受信することを含み得る。現在ピクチャが1つまたは複数の他のピクチャによってデコード順に参照されているかどうかに対応する第1のフラグがチェックされる。現在ピクチャが出力されるかどうかに対応する第2のフラグがチェックされる。ビデオデータは、第1のフラグおよび第2のフラグに対応する値に基づいてデコードされる。

【0010】

さらに別の態様によれば、ビデオデータをコーディングするためのコンピュータ可読媒体が提供される。コンピュータ可読媒体は、1つまたは複数のコンピュータ可読記憶装置と、1つまたは複数の有形記憶装置のうちの少なくとも1つに記憶されたプログラム命令とを含むことができ、プログラム命令はプロセッサによって実行可能である。プログラム命令は、それに応じて現在ピクチャおよび1つまたは複数の他のピクチャを含むビデオデータを受信することを含み得る方法を実行するためにプロセッサによって実行可能である。現在ピクチャが1つまたは複数の他のピクチャによってデコード順に参照されているかどうかに対応する第1のフラグがチェックされる。現在ピクチャが出力されるかどうかに対応する第2のフラグがチェックされる。ビデオデータは、第1のフラグおよび第2のフラグに対応する値に基づいてデコードされる。

【0011】

これらおよび他の目的、特徴および利点は、添付の図面に関連して読まれるべき例示的な実施形態の以下の詳細な説明から明らかになるであろう。図面の様々な特徴は、詳細な説明と併せて当業者の理解を容易にする上で明確にするためのものであるため、縮尺通りではない。

【図面の簡単な説明】

【0012】

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

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

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

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

【図5】従来技術または実施形態によるARCパラメータをシグナリングするための選択肢の概略図である。

【図6】一実施形態によるシンタックステーブルの一例である。

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

【図8】適応的な解像度変更を伴う拡張性のための予測構造の一例である。

【図9】一実施形態によるシンタックステーブルの一例である。

【図10】アクセスユニット毎のpocサイクルおよびアクセスユニットカウント値のシンタックス解析およびデコーディングの簡略ブロック図の概略図である。

【図11】マルチレイヤサブピクチャを含むビデオビットストリーム構造の概略図である。

【図12】エンハンスされた解像度を有する選択されたサブピクチャの表示の概略図である。

【図13】マルチレイヤサブピクチャを含むビデオビットストリームのデコーディングおよび表示処理のブロック図である。

【図14】サブピクチャのエンハンスメントレイヤを有する360ビデオ表示の概略図である。

【図15】サブピクチャならびにその対応するレイヤおよびピクチャ予測構造のレイアウト情報の一例である。

【図16】ローカル領域の空間拡張性形式を用いた、サブピクチャならびにその対応するレイヤおよびピクチャ予測構造のレイアウト情報の一例を示す図である。

【図17】サブピクチャレイアウト情報のシンタックステーブルの例である。

【図18】サブピクチャレイアウト情報のSEIメッセージのシンタックステーブルの例である。

【図19】出力レイヤおよび各出力レイヤセットのプロファイル／ティア／レベル情報を示すシンタックステーブルの一例である。

【図20】出力レイヤセット毎に出力レイヤモードを示すシンタックステーブルの一例である。

【図21】出力レイヤセット毎の各レイヤの現在のサブピクチャを示すシンタックステーブルの一例である。

【図22】ビデオパラメータセットRBSPのシンタックステーブルの例を示す図である。

【図23】出力レイヤセットモードで設定された出力レイヤを示すシンタックステーブルの一例である。

【図24】ピクチャの出力情報を示すピクチャヘッダのシンタックステーブルの一例である。

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

【0013】

特許請求される構造および方法の詳細な実施形態が本明細書に開示される。しかしながら、開示された実施形態は、様々な形態で具体化され得る特許請求された構造および方法の単なる例示であることが理解され得る。しかしながら、これらの構造および方法は、多くの異なる形態で具現化されてもよく、本明細書に記載の例示的な実施形態に限定されると解釈されるべきではない。むしろ、これらの例示的な実施形態は、本開示が徹底的かつ完全であり、当業者に範囲を十分に伝えるように提供される。説明では、提示された実施形態を不必要に不明瞭にすることを避けるために、周知の特徴および技術の詳細が省略され得る。

【0014】

前述したように、ビデオエンコーダおよびデコーダは、ほとんどの場合、コード化されたビデオシーケンス（CVS）、Group of Pictures（GOP）、または同様のマルチ・ピクチャ・タイムフレームのために定義され一定に保たれた、所与のピクチャサイズで動作する傾向があった。しかしながら、ピクチャは、動き補償または他のパラメータ予測のために後続のピクチャによって参照されるかもしれないし、されないかもしれない。ピクチャは出力されるかもしれないし、されないかもしれない。したがって、1つまたは複数のパラメータセットにおいて参照情報およびピクチャ出力情報をシグナリングすることが有利であり得る。

【0015】

様々な実施形態による方法、装置（システム）、およびコンピュータ可読媒体のフローチャート図および／またはブロック図を参照して、態様を本明細書で説明する。フローチャート図および／またはブロック図の各ブロック、ならびにフローチャート図および／またはブロック図のブロックの組み合わせは、コンピュータ可読プログラム命令によって実施されうることが理解されよう。

【0016】

図1は、本開示の実施形態による通信システム（100）の簡略化されたブロック図を示す。システム（100）は、ネットワーク（150）を介して相互接続された少なくとも2つの端末（110～120）を含み得る。データの一方向送信の場合、第1の端末（110）は、ネットワーク（150）を介して他の端末（120）に送信するために、ローカル位置でビデオデータをコード化することができる。第2の端末（120）は、ネットワーク（150）から他の端末のコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータを表示することができる。一方向データ伝送は、メディア・サービング・アプリケーションなどにおいて一般的であり得る。

【0017】

図1は、例えば、ビデオ会議中に発生し得るコード化されたビデオの双方向送信をサポートするために提供される第2の対の端末（130、140）を示す。データの双方向送信の場合、各端末（130、140）は、ネットワーク（150）を介して他の端末に送信するために、ローカル位置でキャプチャされたビデオデータをコード化することができる。各端末（130、140）はまた、他の端末によって送信されたコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータをローカルディスプレイ装置に表示し得る。

【0018】

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

【0019】

図2は、開示された主題のための用途の例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタル媒体への圧縮ビデオの格納などを含む、他のビデオ対応アプリケーションにも等しく適用可能であり得る。

【0020】

ストリーミングシステムは、例えば非圧縮のビデオ・サンプル・ストリーム（202）を作成する、例えばデジタルカメラなどのビデオソース（201）を含み得るキャプチャサブシステム（213）を含み得る。そのサンプルストリーム（202）は、エンコードされたビデオビットストリームと比較したときに大量のデータを強調するために太線で示され、カメラ（201）に結合されたエンコーダ（203）によって処理されうる。エンコーダ（203）は、以下でより詳細に説明されるように、開示された主題の態様を可能にするまたは実装するためのハードウェア、ソフトウェア、またはそれらの組み合わせを含み得る。サンプルストリームと比較してデータ量が少ないことを強調するために細い線で示されたエンコードされたビデオビットストリーム（204）は、将来の使用のためにストリーミングサーバ（205）に格納され得る。1つまたは複数のストリーミングクライアント（206、208）は、ストリーミングサーバ（205）にアクセスして、エンコードされたビデオビットストリーム（204）の複製（207、209）を取り出すことができる。クライアント（206）は、エンコードされたビデオビットストリーム（207）の入ってくる複製をデコードし、ディスプレイ（212）または他のレンダリング装置（図示せず）上でレンダリングされうる出ていくビデオ・サンプル・ストリーム（211）を作成するビデオデコーダ（210）を含み得る。一部のストリーミングシステムでは、ビデオビットストリーム（204、207、209）は特定のビデオコーディング／圧縮規格に従ってエンコードされうる。これらの規格の例としては、ITU－T勧告H．265などが挙げられる。多用途ビデオコーディング（Versatile Video Coding：VVC）として非公式に知られているビデオコーディング規格が開発中である。開示された主題は、VVCの文脈で使用され得る。

【0021】

図3は、本発明の実施形態によるビデオデコーダ（210）の機能ブロック図であり得る。

【0022】

受信器（310）は、デコーダ（210）によってデコードされる1つまたは複数のコーデック・ビデオ・シーケンスを受信することができ、同じまたは他の実施形態では、一度に1つのコード化されたビデオシーケンスであり、各々のコード化されたビデオシーケンスのデコードは、他のコード化されたビデオシーケンスから独立している。コード化されたビデオシーケンスは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得るチャネル（312）から受信され得る。受信器（310）は、それぞれの使用エンティティ（図示せず）に転送され得る他のデータ、例えば、コード化された音声データおよび／または補助データストリームとともに、エンコードされたビデオデータを受信し得る。受信器（310）は、コード化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、受信器（310）とエントロピーデコーダ／パーサ（320）（以下、「パーサ」）との間にバッファメモリ（315）が結合され得る。受信器（310）が十分な帯域幅および制御性を有するストア／フォワード装置から、または等同期（isosychronous）ネットワークからデータを受信している場合、バッファ（315）は必要ないか、小さくてもよい。インターネットなどのベスト・エフォート・パケット・ネットワークで使用するために、バッファ（315）が必要とされる場合があり、比較的大きくすることができ、有利に適応サイズにすることができる。

【0023】

ビデオデコーダ（210）は、エントロピーコード化されたビデオシーケンスからシンボル（321）を再構築するためのパーサ（320）を含み得る。図2に示すように、これらのシンボルのカテゴリには、デコーダ（210）の動作を管理するために使用される情報、およびデコーダの不可欠な部分ではないがそれに結合することができるディスプレイ（212）などのレンダリング装置を制御するための情報が潜在的に含まれる。レンダリング装置の制御情報は、補足エンハンスメント情報（Supplementary Enhancement Information：SEIメッセージ）またはビデオユーザビリティ情報（Video Usability Information：VUI）パラメータ・セット・フラグメント（図示せず）の形であり得る。パーサ（320）は、受信されたコード化されたビデオシーケンスを解析／エントロピーデコードすることができる。コード化されたビデオシーケンスのコーディングは、ビデオコーディング技術またはビデオコーディング規格に従ったものでありえ、文脈依存性の有無にかかわらず、可変長コーディング、ハフマンコーディング、算術コーディングなどを含む、当業者に周知の原理に従ったものでありうる。パーサ（320）は、グループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのサブグループパラメータの組を、コード化されたビデオシーケンスから抽出することができる。サブグループは、Group of Pictures（GOP）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含み得る。エントロピーデコーダ／パーサはまた、変換係数、量子化パラメータ値、動きベクトルなどのようなコード化されたビデオシーケンス情報から抽出することができる。

【0024】

パーサ（320）は、シンボル（321）を作成するために、バッファ（315）から受信されたビデオシーケンスに対してエントロピーデコーディング／パース操作を行うことができる。

【0025】

シンボル（321）の再構築には、コード化されたビデオピクチャまたはその一部（インターピクチャおよびイントラピクチャ、インターブロックおよびイントラブロックなど）の型式、およびその他の要因に応じて、複数の異なるユニットが含まれ得る。含まれるユニットおよびその方法は、パーサ（320）によってコード化されたビデオシーケンスから解析されたサブグループ制御情報によって制御され得る。明確性のため、パーサ（320）と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、示されていない。

【0026】

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

【0027】

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

【0028】

場合によっては、スケーラ／逆変換（351）の出力サンプルは、イントラコード化されたブロック、つまり、以前に再構築されたピクチャからの予測情報を使用していないが、現在ピクチャの以前に再構築された部分からの予測情報を使用できるブロックに関係し得る。そのような予測情報は、イントラピクチャ予測ユニット（352）によって提供され得る。場合によっては、イントラピクチャ予測ユニット（352）は、現在の（部分的に再構築された）ピクチャ（356）からフェッチされた周囲のすでに再構築された情報を使用して、再構築中のブロックと同じサイズおよび形状のブロックを生成する。アグリゲータ（355）は、場合によっては、サンプル毎に、イントラ予測ユニット（352）が生成した予測情報をスケーラ／逆変換ユニット（351）によって提供された出力サンプル情報に追加する。

【0029】

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

【0030】

アグリゲータ（355）の出力サンプルは、ループ・フィルタ・ユニット（356）における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術には、コード化されたビデオビットストリームに含まれるパラメータによって制御され、パーサ（320）からのシンボル（321）としてループ・フィルタ・ユニット（356）で利用できるループ内フィルタ技術を含めることができるが、コード化されたピクチャまたはコード化されたビデオシーケンスの以前の（デコード順で）部分のデコーディング中に取得されたメタ情報に応答するものであってもよく、以前に再構築およびループフィルタされたサンプル値に応答するものであってもよい。

【0031】

ループ・フィルタ・ユニット（356）の出力は、レンダリング装置（212）に出力することができるとともに、将来のインターピクチャ予測に使用するために参照ピクチャメモリ（356）に格納され得るサンプルストリームとすることができる。

【0032】

特定のコード化されたピクチャは、完全に再構築されると、将来の予測のための参照ピクチャとして使用されうる。コード化されたピクチャが完全に再構築され、コード化されたピクチャが（例えば、パーサ（320）によって）参照ピクチャとして識別されると、現在の参照ピクチャ（356）は参照ピクチャバッファ（357）の一部になり得、次のコード化されたピクチャの再構築を開始する前に、新鮮な現在ピクチャメモリが再割り当てされうる。

【0033】

ビデオデコーダ320は、ITU－T Rec．H．265などの規格に文書化され得る所定のビデオ圧縮技術に従ってデコード動作を行いうる。コード化されたビデオシーケンスは、ビデオ圧縮技術文書または規格として指定されるように、ビデオ圧縮技術または規格のシンタックスと、特にその中のプロファイル文書に準拠しているという意味において、使用されているビデオ圧縮技術または規格によって指定されたシンタックスに準拠し得る。また、コード化されたビデオシーケンスの複雑さが、ビデオ圧縮技術または規格のレベルで定義されている範囲内にあることも、遵守に必要である。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート（例えば毎秒メガサンプルで測定される）、最大参照ピクチャサイズなどを制限する。レベルによって設定される制限は、場合によっては、仮想参照デコーダ（Hypothetical Reference Decoder：HRD）仕様およびコード化されたビデオシーケンスにおいてシグナリングされたHRDバッファ管理のためのメタデータによってさらに制限され得る。

【0034】

一実施形態では、受信器（310）は、エンコードされたビデオとともに追加の（冗長な）データを受信し得る。追加のデータは、コード化されたビデオシーケンスの一部として含まれ得る。追加のデータは、データを適切にデコードし、および／または元のビデオデータをより正確に再構築するために、ビデオデコーダ（320）によって使用され得る。追加のデータは、例えば、時間的、空間的、またはSNRエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正符号などの形式であり得る。

【0035】

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

【0036】

エンコーダ（203）は、エンコーダ（203）によってコード化されるビデオ画像をキャプチャすることができるビデオソース（201）（エンコーダの一部ではない）からビデオサンプルを受信し得る。

【0037】

ビデオソース（201）は、エンコーダ（203）によってコード化されるソース・ビデオ・シーケンスを、任意の適切なビット深度（例えば、8ビット、10ビット、12ビット、…）であり得、任意の色空間（例えば、BT．601 Y CrCB、RGB、…）および適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタル・ビデオ・サンプル・ストリームの形態で提供し得る。メディア・サービング・システムでは、ビデオソース（201）は、以前に準備されたビデオを格納する記憶装置であり得る。ビデオ会議システムでは、ビデオソース（203）は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、順番に見たときに動作を与える複数の個別のピクチャとして提供され得る。ピクチャ自体は、ピクセルの空間アレイとして編成することができ、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含み得る。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明では、サンプルを中心に説明する。

【0038】

一実施形態によれば、エンコーダ（203）は、用途によって要求されるように、リアルタイムで、または任意の他の時間制約の下で、ソース・ビデオ・シーケンスのピクチャをコード化し、コード化されたビデオシーケンス（443）に圧縮し得る。適切なコーディング速度を強制することは、コントローラ（450）の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、結合は描かれていない。コントローラによって設定されたパラメータには、レート制御関連パラメータ（ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値など）、ピクチャサイズ、group of pictures（GOP）レイアウト、最大動きベクトル探索範囲などが含まれ得る。当業者は、特定のシステム設計用に最適化されたビデオエンコーダ（203）に関係し得るので、コントローラ（450）の他の機能を容易に識別することができる。

【0039】

一部のビデオエンコーダは、当業者が「コーディングループ」として容易に認識できる方法で動作する。過度に単純化された説明として、コーディングループは、エンコーダ（430）（以下、「ソースコーダ」）のエンコーディング部分（コード化される入力ピクチャおよび参照ピクチャに基づくシンボルの作成を担当）と、エンコーダ（203）に埋め込まれた（ローカル）デコーダ（433）であって、シンボルを再構築して（リモート）デコーダも作成するサンプルデータを作成する、（ローカル）デコーダ（433）と、からなり得る（シンボルとコード化されたビデオビットストリームとの間の圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるため）。再構築されたサンプルストリームは、参照ピクチャメモリ（434）に入力される。シンボルストリームのデコーディングは、デコーダの場所（ローカルまたはリモート）に関係なくビット正確な結果をもたらすため、参照ピクチャ・バッファ・コンテンツもローカルエンコーダとリモートエンコーダとの間でビットが正確である。言い換えると、エンコーダの予測部分は、デコーダがデコード中に予測を使用するときに「見る」するのとまったく同じサンプル値を参照ピクチャのサンプルとして「見る」。参照ピクチャの同期性のこの基本原理（および、例えばチャネルエラーのために同期性を維持できない場合に生じるドリフト）は、当業者によく知られている。

【0040】

「ローカル」デコーダ（433）の動作は、「リモート」デコーダ（210）の動作と同じであり得、これは、図3に関連して上で詳細にすでに説明されている。しかしながら、図3も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ（445）およびパーサ（320）によるコード化されたビデオシーケンスへのシンボルのエンコーディング／デコーディングは可逆であり得るため、チャネル（312）、受信器（310）、バッファ（315）、およびパーサ（320）を含むデコーダ（210）のエントロピーデコード部分は、ローカルデコーダ（433）に完全に実装されない場合がある。

【0041】

この時点でなされ得る観測は、デコーダ内に存在するパーサ／エントロピーデコーディングを除く任意のデコーダ技術もまた、対応するエンコーダ内に実質的に同一の機能形態で存在する必要があるということである。このため、開示された主題は、デコーダの動作に重点を置いている。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略できる。特定の領域においてのみ、より詳細な説明が必要とされ、以下に提供される。

【0042】

動作の一部として、ソースコーダ（430）は、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前にコード化されたフレームを参照して入力フレームを予測的にコード化する動き補償予測コーディングを行い得る。このようにして、コーディングエンジン（432）は、入力フレームのピクセルブロックと、入力フレームへの予測参照として選択され得る参照フレームのピクセルブロックとの間の差分をコード化する。

【0043】

ローカルビデオデコーダ（433）は、ソースコーダ（430）によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコード化されたビデオデータをデコードし得る。コーディングエンジン（432）の動作は、不可逆処理であることが有利であり得る。コード化されたビデオデータがビデオデコーダ（図4には図示せず）でデコードされ得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを伴うソース・ビデオ・シーケンスのレプリカであり得る。ローカルビデオデコーダ（433）は、参照フレームに対してビデオデコーダによって実行され得るデコード処理を複製し、再構築された参照フレームを参照ピクチャキャッシュ（434）に記憶させることができる。このようにして、エンコーダ（203）は、遠端ビデオデコーダによって得られる（送信エラーがないとき）再構築参照フレームとして共通のコンテンツを有する再構築参照フレームの複製をローカルに格納し得る。

【0044】

予測器（435）は、コーディングエンジン（432）の予測検索を実行し得る。すなわち、コード化される新しいフレームについて、予測器（435）は、（候補参照ピクセルブロックとしての）サンプルデータまたは参照ピクチャの動きベクトル、ブロック形状などの、新しいピクチャの適切な予測参照として機能し得る特定のメタデータについて参照ピクチャメモリ（434）を検索することができる。予測器（435）は、適切な予測参照を見つけるために、サンプルブロック－ピクセルブロック毎に動作し得る。いくつかの場合において、予測器（435）によって得られた検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ（434）に記憶された複数の参照ピクチャから引き出された予測参照を有し得る。

【0045】

コントローラ（450）は、例えば、ビデオデータをエンコーディングするために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ（430）のコーディング動作を管理し得る。

【0046】

前述のすべての機能ユニットの出力は、エントロピーコーダ（445）においてエントロピーコーディングを受けてもよい。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットにより生成されたシンボルをコード化されたビデオシーケンスに変換する。

【0047】

送信器（440）は、エントロピーコーダ（445）によって作成されたコード化されたビデオシーケンスをバッファリングして、エンコードされたビデオデータを格納する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル（460）を介した送信に備えることができる。送信器（440）は、ビデオコーダ（430）からのコード化されたビデオデータを、送信される他のデータ、例えばコード化された音声データおよび／または補助データストリーム（ソースは図示せず）とマージすることができる。

【0048】

コントローラ（450）は、エンコーダ（203）の動作を管理し得る。コーディング中に、コントローラ（450）は、各々のコード化されたピクチャに特定のコード化されたピクチャ型式を割り当て得、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、多くの場合、ピクチャは次のフレーム型式のうちの1つとして割り当てられ得る。

【0049】

イントラピクチャ（Iピクチャ）は、シーケンス内の他のフレームを予測のソースとして使用せずにコード化およびデコードできるものである。一部のビデオコーデックでは、例えばIndependent Decoder Refresh Pictureなど、様々な型式のイントラピクチャを使用できる。当業者は、Iピクチャのこれらの変形ならびにそれらのそれぞれの用途および特徴を認識している。

【0050】

予測ピクチャ（Pピクチャ）は、各ブロックのサンプル値を予測するために最大で1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコード化およびデコードされ得るものであり得る。

【0051】

双方向予測ピクチャ（Bピクチャ）は、各ブロックのサンプル値を予測するために最大で2つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用してコード化およびデコードされ得るものであり得る。同様に、複数の予測ピクチャは、単一のブロックの再構築のために3つ以上の参照ピクチャおよび関連付けられたメタデータを使用することができる。

【0052】

ソースピクチャは、通常、空間的に複数のサンプルブロック（例えば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック）に細分化され、ブロック毎にコード化され得る。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように、他の（すでにコード化された）ブロックを参照して予測的にコード化され得る。例えば、Iピクチャのブロックは非予測的にコード化されてもよく、またはそれらは同じピクチャのすでにコード化されたブロックを参照して予測的にコード化されてもよい（空間予測またはイントラ予測）。Pピクチャのピクセルブロックは、以前にコード化された1つの参照ピクチャを参照して、空間的予測を介して、または時間的予測を介して、非予測的にコード化され得る。Bピクチャのブロックは、1つまたは2つの以前にコード化された参照ピクチャを参照して、空間的予測を介して、または時間的予測を介して、非予測的にコード化され得る。

【0053】

ビデオコーダ（203）は、ITU－T Rec．H．265などの所定のビデオコーディング技術または規格に従ってコーディング動作を実行し得る。その動作において、ビデオコーダ（203）は、入力ビデオシーケンスの時間的および空間的冗長性を活用する予測コーディング操作を含む、様々な圧縮操作を行いし得る。したがって、コード化ビデオデータは、使用されているビデオコーディング技術または規格によって指定されたシンタックスに準拠し得る。

【0054】

一実施形態では、送信器（440）は、エンコードされたビデオとともに追加のデータを送信し得る。ビデオコーダ（430）は、そのようなデータを、コード化されたビデオシーケンスの一部として含み得る。追加のデータには、時間的／空間的／SNRエンハンスメントレイヤ、冗長なピクチャやスライスなどの冗長データの他の形式、補足エンハンスメント情報（SEI）メッセージ、視覚ユーザビリティ情報（VUI）パラメータ・セット・フラグメントなどが含まれ得る。

【0055】

開示された主題の特定の態様をより詳細に説明する前に、この説明の残りの部分で参照されるいくつかの用語を導入する必要がある。

【0056】

以下、サブピクチャは、意味的にグループ化され、変更された解像度で独立してコード化され得るサンプル、ブロック、マクロブロック、コーディングユニット、または同様のエンティティの矩形配置を指す場合がある。1つのピクチャに対して1つまたは複数のサブピクチャがあり得る。1または複数のコード化されたサブピクチャは、コード化されたピクチャを形成し得る。1つまたは複数のサブピクチャをピクチャにアセンブルすることができ、1つまたは複数のサブピクチャをピクチャから抽出することができる。ある特定の環境では、1または複数のコード化されたサブピクチャは、サンプルレベルへのコード化されたピクチャへのトランスコードを行わずに、圧縮された領域においてアセンブルされ得る。そして、同じまたはある特定の他のケースでは、1または複数のコード化されたサブピクチャが、圧縮された領域におけるコード化されたピクチャから抽出され得る。

【0057】

以下、適応解像度変更（ARC）は、例えば、参照ピクチャの再サンプリングによって、コード化されたビデオシーケンス内のピクチャまたはサブピクチャの解像度の変更を可能にするメカニズムを称する。以下、ARCパラメータは、適応解像度変更を行うために必要とされる制御情報を指し、これは、例えば、フィルタパラメータ、スケーリング係数、出力ピクチャおよび／または参照ピクチャの解像度、様々な制御フラグなどを含み得る。

【0058】

上記の説明は、単一の意味的に独立のコード化されたビデオピクチャのコーディングおよびデコーディングに焦点を当てている。独立のARCパラメータを有する複数のサブピクチャのコーディング／デコーディングの含意およびその含意される追加の複雑さを説明する前に、ARCパラメータをシグナリングするための選択肢を説明することができる。

【0059】

図5を参照すると、ARCパラメータをシグナリングするためのいくつかの新規選択肢が示されている。各選択肢で述べたように、それらは、コーディング効率、複雑さ、およびアーキテクチャの観点から、特定の利点および特定の欠点を有する。ビデオコーディング規格または技術は、ARCパラメータをシグナリングするために、これらの選択肢、または従来技術から知られている選択肢のうちの1つまたは複数を選択することができる。選択肢は、相互に排他的でなくてもよく、アプリケーションのニーズ、関連する標準技術、またはエンコーダの選択に基づいて交換されてもよいと考えられる。

【0060】

ARCパラメータのクラスは、以下を含み得る。

【0061】

－XおよびY次元で分離または結合される、アップ／ダウンサンプル係数。

【0062】

－所与の数のピクチャに対する一定速度のズームイン／アウトを示す、時間次元を追加したアップ／ダウンサンプル係数。

【0063】

－上記の2つのいずれかは、係数を含むテーブルを指すことができる1つまたは複数のおそらく短いシンタックス要素のコーディングを含み得る。

【0064】

－入力ピクチャ、出力ピクチャ、参照ピクチャ、コード化されたピクチャ、結合されたピクチャ、または別々の、サンプル、ブロック、マクロブロック、CU、または任意の他の適切な粒度の単位でのX次元またはY次元の解像度。2つ以上の分解能がある場合（例えば、入力ピクチャ用のもの、参照ピクチャ用のものなど）、特定の場合には、1つの値の組が別の値の組から推測され得る。これは、例えば、フラグを使用することによってゲートすることができる。より詳細な例については、以下を参照されたい。

【0065】

－「ワーピング」座標は、H．263 Annex Pで用いられるものと同様に、上述したように適切な粒度である。H．263 Annex Pは、そのようなワーピング座標をコード化する1つの効率的な方法を定義しているが、他の潜在的により効率的な方法も考えられる。例えば、付属書Pのワーピング座標の可変長可逆「ハフマン」スタイルのコーディングは、適切な長さのバイナリコーディングに置き換えることができ、バイナリコードワードの長さは、例えば、最大ピクチャサイズから導出することができ、場合によっては特定の係数を乗算し、特定の値だけずらされて、最大ピクチャサイズの境界外の「ワーピング」を可能にする。

【0066】

－アップサンプルフィルタパラメータまたはダウンサンプルフィルタパラメータ。最も簡単な場合には、アップサンプリングおよび／またはダウンサンプリングのための単一のフィルタのみが存在してもよい。しかしながら、ある場合には、フィルタ設計においてより多くの柔軟性を可能にすることが有利であり得、それはフィルタパラメータのシグナリングを必要とし得る。そのようなパラメータは、可能なフィルタ設計のリスト内のインデックスを介して選択されてもよく、フィルタは、完全に指定されてもよく（例えば、適切なエントロピーコーディング技術を用いて、フィルタ係数のリストを介して）、フィルタは、アップ／ダウンサンプル比を介して暗黙的に選択されてもよく、アップ／ダウンサンプル比は、上述のメカニズムのいずれかに従ってシグナリングされ、以下同様である。

【0067】

以下では、説明は、コードワードによって示される有限集合のアップ／ダウンサンプル係数（X次元およびY次元の両方で使用される同じ係数）のコーディングを想定している。そのコードワードは、有利には、例えば、H．264およびH．265などのビデオコーディング仕様における特定のシンタックス要素に共通のExt－Golomb符号を使用して、可変長コード化することができる。アップ／ダウンサンプル係数への値の1つの適切なマッピングは、例えば、以下のテーブルに従うことができる。

【0068】

【表1】

【0069】

アプリケーションのニーズ、およびビデオ圧縮技術または規格で利用可能なアップスケール機構およびダウンスケール機構の能力に従って、多くの同様のマッピングを考案することができる。テーブルは、より多くの値に拡張することができる。値はまた、例えばバイナリコーディングを使用して、Ext－Golomb符号以外のエントロピーコーディング機構によって表されてもよい。これは、例えばMANEによって、再サンプリング係数がビデオ処理エンジン自体の外部で（エンコーダおよびデコーダが最も前）関心対象であった場合に、一定の利点を有し得る。解像度変更が必要とされない（おそらく）最も一般的なケースでは、短いExt－Golomb符号が選択され得ることに留意されたい。上記のテーブルでは、1ビットのみである。これは、最も一般的な場合にバイナリコードを使用するよりもコーディング効率の利点を有することができる。

【0070】

テーブル内のエントリの数、ならびにそれらのセマンティクスは、完全にまたは部分的に構成可能であり得る。例えば、テーブルの基本的な概要は、シーケンスまたはデコーダ・パラメータ・セットなどの「高」パラメータセットで伝達されてもよい。あるいは、または加えて、1つまたは複数のそのようなテーブルは、ビデオコーディング技術または規格で定義されてもよく、例えばデコーダまたはシーケンス・パラメータ・セットを介して選択されてもよい。

【0071】

以下では、上述のようにコード化されたアップサンプル／ダウンサンプル係数（ARC情報）がビデオコーディング技術または標準シンタックスにどのように含まれ得るかを説明する。アップ／ダウンサンプルフィルタを制御する1つまたはいくつかのコードワードにも同様の考慮事項が適用され得る。フィルタまたは他のデータ構造に比較的大量のデータが必要な場合の説明については、以下を参照されたい。

【0072】

H．263 Annex Pは、ピクチャヘッダ501内に、具体的にはH．263 PLUSPTYPE（503）ヘッダ拡張子内に、4つのワーピング座標の形態のARC情報502を含む。これは、a）利用可能なピクチャヘッダがあり、b）ARC情報の頻繁な変更が予想される場合に、賢明な設計選択となり得る。しかしながら、H．263スタイルのシグナリングを使用する場合のオーバーヘッドは非常に高くなる可能性があり、ピクチャヘッダは一時的な性質であり得るため、スケーリング係数はピクチャ境界間に関係しない可能性がある。

【0073】

上記で引用したJVCET－M 135－v1は、ピクチャ・パラメータ・セット（504）内に位置するARC参照情報（505）（インデックス）を含み、シーケンス・パラメータ・セット（507）内に位置するターゲット解像度を含むテーブル（506）をインデックス付けする。シーケンス・パラメータ・セット（507）内のテーブル（506）における可能な解像度の配置は、著者によって行われた口頭の陳述に従って、能力交換中に相互運用の交渉点としてSPSを使用することによって正当化され得る。解像度は、適切なピクチャ・パラメータ・セット（504）を参照することによって、ピクチャ毎にテーブル（506）内の値によって設定された制限内で変化し得る。

【0074】

さらに図5を参照すると、ビデオビットストリームでARC情報を伝達するために、以下の追加選択肢が存在し得る。これらの選択肢の各々は、上述のように既存の技術を超える特定の利点を有する。選択肢は、同じビデオコーディング技術または規格に同時に存在してもよい。

【0075】

一実施形態では、再サンプリング（ズーム）係数などのARC情報（509）は、スライスヘッダ、GOBヘッダ、タイルヘッダ、またはタイルグループヘッダ（以下、タイルグループヘッダ）（508）に存在することができる。これは、例えば上記に示すように、単一の可変長ue（v）または数ビットの固定長コードワードなど、ARC情報が小さい場合には適切であり得る。タイルグループヘッダ内にARC情報を直接有することは、ARC情報のさらなる利点を有し、ピクチャ全体ではなく、例えば、そのタイルグループによって表されるサブピクチャに適用可能であり得る。以下も参照されたい。加えて、ビデオ圧縮技術または規格が全ピクチャ適応解像度変更（例えば、タイルグループベースの適応解像度の変化とは対照的に）のみを想定している場合であっても、ARC情報をH．263スタイルのピクチャヘッダに入れることに対して、ARC情報をタイルグループヘッダに入れることは、誤り耐性の観点から一定の利点を有する。

【0076】

同じまたは他の実施形態において、ARC情報（512）自体は、例えば、ピクチャ・パラメータ・セット、ヘッダ・パラメータ・セット、タイル・パラメータ・セット、適応パラメータセットなど（図示されている適応パラメータセット）のような適切なパラメータセット（511）の中に存在してもよい。そのパラメータセットの範囲は、有利には、ピクチャ、例えばタイルグループ以下とすることができる。ARC情報の使用は、関連するパラメータセットの起動によって暗黙的に行われる。例えば、ビデオコーディング技術または規格がピクチャベースのARCのみを企図する場合、ピクチャ・パラメータ・セットまたは同等物が適切であり得る。

【0077】

同じ実施形態または他の実施形態において、ARC参照情報（513）は、タイルグループヘッダ（514）または類似のデータ構造の中に存在してもよい。その参照情報（513）は、単一のピクチャを超える範囲、例えばシーケンス・パラメータ・セットまたはデコーダ・パラメータ・セットを有するパラメータセット（516）において利用可能なARC情報（515）のサブセットを指すことができる。

【0078】

JVET－M 0135－v1で使用されるタイルグループヘッダ、PPS、SPSからのPPSの間接的な追加レベルの暗示的なアクティブ化は、シーケンス・パラメータ・セットと同様に、ピクチャ・パラメータ・セットが能力交渉またはアナウンスに使用され得る（およびRFC 3984などの特定の規格で有する）ので、不要であるように思われる。しかしながら、ARC情報が、例えばタイルグループによっても表現されるサブピクチャに適用可能であるべきである場合、アダプテーション・パラメータ・セットまたはヘッダ・パラメータ・セットのような、タイルグループに限定された起動範囲を有するパラメータセットが、より良い選択であり得る。また、ARC情報が無視できないサイズである場合、例えば、多数のフィルタ係数などのフィルタ制御情報を含む場合、パラメータは、コーディング効率の観点から直接ヘッダ（508）を使用するよりも良い選択であり得る。なぜなら、これらの設定は、同じパラメータセットを参照することによって将来のピクチャまたはサブピクチャによって再利用可能であり得るからである。

【0079】

シーケンス・パラメータ・セットまたは複数のピクチャにまたがるスコープを有する別のより高いパラメータセットを使用するとき、特定の考慮事項が適用され得る。

【0080】

1．ARC情報テーブル（516）を格納するためのパラメータセットは、場合によってはシーケンス・パラメータ・セットであってもよいが、他の場合ではデコーダ・パラメータ・セットが有利である。デコーダ・パラメータ・セットは、複数のCVS、すなわちコード化ビデオストリーム、すなわちセッション開始からセッション終了までのすべてのコード化ビデオビットのアクティブ化範囲を有することができる。そのような範囲は、可能性のあるARC因子が、おそらくハードウェアに実装されるデコーダ機能であり得、ハードウェア機能は、CVSによって変化しない傾向があるため、より適切であり得る（少なくともいくつかの娯楽システムでは、長さが1／2以下のGroup of Picturesである）。とは言え、テーブルをシーケンス・パラメータ・セットに入れることは、特に以下の点2に関連して、本明細書に記載の配置選択肢に明確に含まれる。

【0081】

2．ARC参照情報（513）は、有利には、JVCET－M 0135－v1のようにピクチャ・パラメータ・セット内にではなく、ピクチャ／スライスタイル／GOB／タイルグループヘッダ（以下、タイルグループヘッダ）（514）内に直接配置され得る。その理由は、エンコーダが、例えばARC参照情報などのピクチャ・パラメータ・セット内の単一の値を変更したい場合、新しいPPSを作成し、その新しいPPSを参照する必要があるためである。ARC参照情報のみが変化するが、例えばPPS内の量子化マトリクス情報などの他の情報は残るとする。そのような情報はかなりのサイズであり得、新しいPPSを完成させるために再送信される必要がある。ARC参照情報は、テーブル（513）へのインデックスのような単一のコードワードであってもよく、それは変化する唯一の値であるので、例えば量子化行列情報のすべてを再送信することは面倒で無駄である。その限りにおいて、JVET－M 0135－v1で提案されているように、PPSを通る間接を回避するためにコーディング効率の観点からかなり良好であり得る。同様に、ARC参照情報をPPSに入れることには、ピクチャ・パラメータ・セット・アクティブ化の範囲がピクチャであるので、ARC参照情報（513）によって参照されるARC情報は、必ずしもサブピクチャではなくピクチャ全体に適用される必要があるというさらなる欠点がある。

【0082】

同じまたは他の実施形態において、ARCパラメータのシグナリングは、図6に概説されるような詳細な例に従うことができる。図6は、少なくとも1993年以降のビデオコーディング規格で使用されている表現のシンタックス図を示す。このようなシンタックス図の表記は、大まかにはCスタイルプログラミングに従う。太字の線はビットストリームに存在するシンタックス要素を示し、太字のない線は制御フローまたは変数の設定を示すことが多い。

【0083】

ピクチャの（場合によっては矩形の）部分に適用可能なヘッダの例示的なシンタックス構造としてのタイルグループヘッダ（601）は、条件付きで、可変長のExp－Golombコード化シンタックス要素dec＿pic＿size＿idx（602）（太字で示されている）を含むことができる。タイルグループヘッダ内のこのシンタックス要素の存在は、適応型解像度（603）、ここでは太字で示されていないフラグの値を使用してゲートすることができ、これは、フラグがシンタックス図内で発生する点でビットストリーム内に存在することを意味する。適応型解像度がこのピクチャまたはその一部に使用されているか否かは、ビットストリームの内部または外部の任意の高レベルシンタックス構造でシグナリングすることができる。示されている例では、以下に概説するようにシーケンス・パラメータ・セットでシグナリングされる。

【0084】

引き続き図6を参照すると、シーケンス・パラメータ・セット（610）の抜粋も示されている。示されている第1のシンタックス要素は、adaptive＿pic＿resolution＿change＿flag（611）である。真の場合、そのフラグは適応解像度の使用を示すことができ、適応解像度は特定の制御情報を必要とする場合がある。この例では、このような制御情報は、パラメータセット（612）内のif（）文に基づくフラグの値と、タイルグループヘッダ（601）とに基づいて、条件付きで存在する。

【0085】

適応解像度が用いられているとき、この例では、コード化されるものは、サンプル単位（613）の出力解像度である。参照符号613は、出力ピクチャの解像度をともに定義することができるoutput＿pic＿width＿in＿luma＿samplesおよびoutput＿pic＿height＿in＿luma＿samplesの両方を指す。ビデオコーディング技術または規格の他の箇所では、いずれかの値に対する特定の制限を定義することができる。例えば、レベル定義は、それらの2つのシンタックス要素の値の積でありうる総出力サンプルの数を制限することができる。また、特定のビデオコーディング技術もしくは規格、または例えばシステム規格などの外部技術もしくは規格は、番号付けの範囲（例えば、一方または両方の寸法は、2の累乗で割り切れなければならない）、またはアスペクト比（例えば、幅と高さは4：3または16：9などの関係になければならない）を制限しうる。そのような制限は、ハードウェア実装を容易にするために、または他の理由で導入されてもよく、当技術分野で周知である。

【0086】

特定の用途では、エンコーダは、サイズが出力ピクチャサイズであると暗黙的に仮定するのではなく、特定の参照ピクチャサイズを使用するようにデコーダに指示することが望ましい場合がある。この例では、シンタックス要素reference＿pic＿size＿present＿flag（614）は、参照ピクチャ寸法（615）（この場合も、数字は幅と高さの両方を指す）の条件付き存在をゲートする。

【0087】

最後に、可能なデコーディングピクチャの幅および高さのテーブルが示されている。このようなテーブルは、例えば、テーブル指示（num＿dec＿pic＿size＿in＿luma＿samples＿minus1）（616）で表すことができる。「minus1」は、そのシンタックス要素の値の解釈を指すことができる。例えば、コード化された値が0である場合、1つのテーブルエントリが存在する。値が5である場合、6つのテーブルエントリが存在する。テーブル内の各「ライン」について、デコードされたピクチャの幅および高さがシンタックス（617）に含まれる。

【0088】

提示されたテーブルエントリ（617）は、タイルグループヘッダ内のシンタックス要素dec＿pic＿size＿idx（602）を使用してインデックス付けすることができ、それにより、タイルグループ毎に異なるデコードサイズ、実際にはズーム率を可能にする。

【0089】

例えばVP9のようなあるビデオコーディング技術または規格は、空間拡張性を可能にするために、（開示された主題とは全く異なるようにシグナリングされた）ある形式の参照ピクチャ再サンプリングを、時間拡張性と併せて実施することによって、空間拡張性をサポートする。特に、特定の参照ピクチャは、ARCスタイル技術を使用してより高い解像度にアップサンプリングされ、空間エンハンスメントレイヤのベースを形成することができる。これらのアップサンプリングされたピクチャは、詳細を追加するために、高解像度で通常の予測メカニズムを使用して洗練されることができる。

【0090】

開示された主題は、そのような環境で使用することができる。場合によっては、同じまたは他の実施形態では、NALユニットヘッダ内の値、例えば時間IDフィールドを使用して、時間レイヤだけでなく空間レイヤも示すことができる。そうすることは、一定のシステム設計において一定の利点を有する。例えば、NALユニットヘッダ時間ID値に基づいて時間レイヤ選択転送のために作成および最適化された既存の選択転送ユニット（SFU）は、スケーラブル環境のために、修正なしで使用されうる。これを可能にするために、コード化されたピクチャサイズと時間レイヤとの間のマッピングに対する要件が存在してもよく、これはNALユニットヘッダ内の時間IDフィールドによって示される。

【0091】

いくつかのビデオコーディング技術では、アクセスユニット（AU）は、時間における所与のインスタンスにおいてそれぞれのピクチャ／スライス／タイル／NALユニットビットストリームに捕捉されて構成された、コード化されたピクチャ、スライス、タイル、NALユニットなどを参照することができる。その時間におけるインスタンスは、合成時間であり得る。

【0092】

HEVC、および一定の他のビデオコーディング技術では、デコード・ピクチャ・バッファ（DPB）に格納された複数の参照ピクチャの中から選択された参照ピクチャを示すためにピクチャ順序カウント（POC）値を使用することができる。アクセスユニット（AU）が1つまたは複数のピクチャ、スライス、またはタイルを含む場合、同じAUに属する各ピクチャ、スライス、またはタイルは、同じPOC値を有することができ、そこから、それらが同じ合成時間のコンテンツから作成されたことを導出することができる。言い換えれば、2つのピクチャ／スライス／タイルが同じ所与のPOC値を運ぶシナリオでは、それは同じAUに属し、同じ合成時間を有する2つのピクチャ／スライス／タイルを示すことができる。逆に、異なるPOC値を有する2つのピクチャ／タイル／スライスは、異なるAUに属し、異なる合成時間を有するそれらのピクチャ／スライス／タイルを示すことができる。

【0093】

開示される主題の一実施形態では、アクセスユニットが異なるPOC値を有するピクチャ、スライス、またはタイルを含むことができるという点で、前述の厳格な関係を緩和することができる。AU内で異なるPOC値を許容することにより、POC値を使用して、同一の提示時間を有する、潜在的に独立にデコード可能なピクチャ／スライス／タイルを識別することが可能になる。これにより、以下でより詳細に説明するように、参照ピクチャ選択シグナリング（例えば、参照ピクチャセットシグナリングまたは参照ピクチャリストシグナリング）を変更することなく、複数のスケーラブルなレイヤのサポートを可能にすることができる。

【0094】

しかしながら、POC値のみから、異なるPOC値を有する他のピクチャ／スライス／タイルに対して、ピクチャ／スライス／タイルが属するAUを識別できることが依然として望ましい。これは、以下に説明するように達成することができる。

【0095】

同じまたは他の実施形態では、アクセスユニットカウント（AUC）は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセットまたはAUデリミタなどの高レベルシンタックス構造でシグナリングされてもよい。AUCの値は、どのNALユニット、ピクチャ、スライス、またはタイルが所与のAUに属するかを識別するために使用され得る。AUCの値は、別個の合成時間インスタンスに対応し得る。AUC値は、POC値の倍数に等しくてもよい。POC値を整数値で除算することにより、AUC値を算出することができる。場合によっては、除算演算は、デコーダの実装に一定の負担をかける可能性がある。このような場合、AUC値の番号付けスペースの制約が小さいため、除算演算をシフト演算に置き換えることができる。例えば、AUC値は、POC値範囲の最上位ビット（MSB）値に等しくてもよい。

【0096】

同じ実施形態において、AU毎のPOCサイクルの値（poc＿cycle＿au）は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセットまたはAUデリミタなどの高レベルシンタックス構造でシグナリングされてもよい。poc＿cycle＿auは、いくつの異なる連続するPOC値を同じAUに関連付けることができるかを示すことができる。例えば、poc＿cycle＿auの値が4に等しい場合、0以上－3以下に等しいPOC値を有するピクチャ、スライスまたはタイルは、0に等しいAUC値を有するAUに関連付けられ、4以上－7以下に等しいPOC値を有するピクチャ、スライスまたはタイルは、1に等しいAUC値を有するAUに関連付けられる。したがって、AUCの値は、POC値をpoc＿cycle＿auの値で除算することによって推測することができる。

【0097】

同じまたは他の実施形態では、poc＿cyle＿auの値は、例えばビデオパラメータセット（VPS）に位置する、コード化されたビデオシーケンスにおける空間レイヤまたはSNRレイヤの数を識別する情報から導出され得る。以下、このような関係を簡単に説明する。上述したような導出は、VPSにおいて数ビットを節約することができ、したがってコーディング効率を改善することができるが、ビデオパラメータセットの下位に階層的に適切な高レベルシンタックス構造でpoc＿cycle＿auを明示的にコード化して、ピクチャなどのビットストリームの所与の小部分についてpoc＿cycle＿auを最小化することができることが有利であり得る。この最適化は、POC値（および／またはPOCを間接的に参照するシンタックス要素の値）が低レベルのシンタックス構造でコード化され得るため、上記の導出処理を通して節約できるよりも多くのビットを節約することができる。

【0098】

上記のシグナリング適応解像度パラメータのための技法は、コンピュータ可読命令を使用してコンピュータソフトウェアとして実装でき、1つまたは複数のコンピュータ可読媒体に物理的に格納できる。例えば、図7は、開示された主題の特定の実施形態を実装するのに適したコンピュータシステム700を示す。

【0099】

コンピュータソフトウェアは、任意の適切な機械コードまたはコンピュータ言語を使用してコード化でき、アセンブリ、コンパイル、リンク、または同様のメカニズムの対象となり、コンピュータ中央処理装置（CPU）、グラフィック処理装置（GPU）などによる直接、または解釈、マイクロコードの実行などを通じて実行できる命令を含むコードを作成する。

【0100】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット装置などを含む様々な型式のコンピュータまたはその構成要素上で実行することができる。

【0101】

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

【0102】

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

【0103】

入力ヒューマンインターフェース装置には、キーボード701、マウス702、トラックパッド703、タッチスクリーン710、データグローブ704、ジョイスティック705、マイク706、スキャナ707、カメラ708のうち1つまたは複数（それぞれ図示のものの1つのみ）が含まれ得る。

【0104】

コンピュータシステム700はまた、特定のヒューマンインターフェース出力装置を含み得る。そのようなヒューマンインターフェース出力装置は、例えば、触知出力、音、光、および匂い／味によって1人または複数の人間のユーザの感覚を刺激することができる。そのようなヒューマンインターフェース出力装置は、触覚出力装置（例えば、タッチスクリーン710、データグローブ704、またはジョイスティック705による触覚フィードバックを含み得るが、入力装置として機能しない触覚フィードバック装置もあり得る）、音声出力装置（スピーカ709、ヘッドホン（図示せず）など）、視覚的出力装置（それぞれにタッチスクリーン入力機能の有無にかかわらず、それぞれ触覚フィードバック機能の有無にかかわらず、ステレオグラフィック出力、仮想現実の眼鏡（図示せず）、ホログラフィックディスプレイおよびスモークタンク（図示せず）などの手段により、2次元の視覚的出力または3次元以上の出力を出力できるものもある、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン710など）、およびプリンタ（図示せず）を含み得る。

【0105】

コンピュータシステム700には、人間がアクセスできる記憶装置と、CD／DVDを含むCD／DVD ROM／RW720などの光学メディア721、サムドライブ722、リムーバブルハードドライブまたはソリッドステートドライブ723、テープおよびフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの専用のROM／ASIC／PLDベースの装置などの関連媒体も含めることができる。

【0106】

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

【0107】

コンピュータシステム700は、1つまたは複数の通信ネットワークへのインターフェースも含み得る。ネットワークは、例えば、無線、有線、光であり得る。ネットワークはさらに、ローカル、広域、メトロポリタン、車両および産業、リアルタイム、遅延耐性などであり得る。ネットワークの例としては、イーサネット、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワークなどのローカル・エリア・ネットワーク、ケーブルテレビ、衛星テレビ、地上波放送テレビを含むTV有線または無線広域デジタルネットワーク、CANBusなどが含まれる車両用、産業用など、がある。特定のネットワークでは、一般に、特定の汎用データポートまたは周辺バス（749）（例えば、コンピュータシステム700のUSBポートなど）に接続された外部ネットワークインターフェースアダプタが必要であり、他のものは一般に、以下に説明するようにシステムバスに接続することにより、コンピュータシステム700のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム700は他のエンティティと通信できる。このような通信は、一方向、受信のみ（例えば、放送TV）、一方向送信のみ（例えば、CANbusから特定のCANbus装置）、または双方向、例えば、ローカルエリアデジタルネットワークまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。

【0108】

前述のヒューマンインターフェース装置、ヒューマンアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム700のコア740に接続することができる。

【0109】

コア740には、1つまたは複数の中央処理装置（CPU）741、グラフィックス処理装置（GPU）742、フィールド・プログラマブル・ゲート・エリア（FPGA）743、特定のタスクのハードウェアアクセラレータ744などの形式の特殊なプログラマブル処理装置を含めることができる。これらの装置は、読み取り専用メモリ（ROM）745、ランダムアクセスメモリ746、ユーザがアクセスできない内部ハードドライブ、SSDなどの内部大容量記憶装置747とともに、システムバス748を介して接続され得る。いくつかのコンピュータシステムでは、システムバス748に1つまたは複数の物理プラグの形でアクセスして、追加のCPU、GPUなどによる拡張を可能にすることができる。周辺機器は、コアのシステムバス748に直接、または周辺バス749を介して接続できる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。

【0110】

CPU741、GPU742、FPGA743、およびアクセラレータ744は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行できる。そのコンピュータコードは、ROM745またはRAM746に記憶することができる。移行データはまた、RAM746に記憶することができ、一方、永続データは、例えば内部大容量記憶装置747に記憶することができる。1つまたは複数のCPU741、GPU742、大容量記憶装置747、ROM745、RAM746などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリ装置に対する高速記憶および読み出しが可能になる。

【0111】

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

【0112】

限定ではなく例として、アーキテクチャ700、特にコア740を有するコンピュータシステムは、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供できる。このようなコンピュータ可読媒体は、上で紹介したユーザがアクセス可能な大容量記憶装置、およびコア内部大容量記憶装置747やROM745などの非一時的な性質を持つコア740の特定の記憶装置に関連付けられた媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に記憶され、コア740によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリ装置またはチップを含み得る。ソフトウェアは、コア740、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM746に格納されているデータ構造を定義すること、およびソフトウェアで定義された処理に従ってそのようなデータ構造を変更することを含む、ここで説明する特定の処理または特定の処理の特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、ロジックハードワイヤードまたは他の方法で回路（例えば、アクセラレータ744）に具現化された論理の結果として機能を提供することができ、ソフトウェアの代わりに、またはソフトウェアとともに動作して、本明細書に記載の特定の処理または特定の処理の特定の部分を実行することができる。ソフトウェアへの参照はロジックを含むことができ、その逆も適宜可能である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアとの任意の適切な組み合わせを包含する。

【0113】

図8は、適応的な解像度変更を伴うtemporal＿id、layer＿id、POC、およびAUC値の組み合わせを有するビデオシーケンス構造の一例を示す。この例では、AUC＝0の第1のAU内のピクチャ、スライス、またはタイルは、temporal＿id＝0およびlayer＿id＝0または1を有することができるが、AUC＝1の第2のAU内のピクチャ、スライス、またはタイルは、それぞれtemporal＿id＝1およびlayer＿id＝0または1を有することができる。temporal＿idおよびlayer＿idの値にかかわらず、POCの値はピクチャ毎に1ずつ増加する。この例では、poc＿cycle＿auの値は2に等しくすることができる。好ましくは、poc＿cycle＿auの値は、（空間拡張性）レイヤの数と等しく設定されてもよい。したがって、この例では、POCの値は2だけ増加し、AUCの値は1だけ増加する。

【0114】

上記の実施形態では、ピクチャ間またはレイヤ間予測構造および参照ピクチャ指示のすべてまたはサブセットは、HEVCにおける既存の参照ピクチャセット（RPS）シグナリングまたは参照ピクチャリスト（RPL）シグナリングを使用することによってサポートされ得る。RPSまたはRPLでは、選択された参照ピクチャは、現在ピクチャと選択された参照ピクチャとの間のPOCの値またはPOCのデルタ値をシグナリングすることによって示される。開示された主題の場合、RPSおよびRPLは、シグナリングを変更せずに、ただし以下の制限を伴って、ピクチャ間またはレイヤ間予測構造を示すために使用され得る。参照ピクチャのtemporal＿idの値がtemporal＿id現在ピクチャの値より大きい場合、現在ピクチャは、動き補償または他の予測のために参照ピクチャを使用しない場合がある。参照ピクチャのlayer＿idの値がlayer＿id現在ピクチャの値より大きい場合、現在ピクチャは、動き補償または他の予測のために参照ピクチャを使用しない場合がある。

【0115】

同じ実施形態および他の実施形態では、時間的動きベクトル予測のためのPOC差に基づく動きベクトルのスケーリングは、アクセスユニット内の複数のピクチャにわたって無効にすることができる。したがって、各ピクチャはアクセスユニット内で異なるPOC値を有し得るが、動きベクトルはスケーリングされず、アクセスユニット内の時間動きベクトル予測に使用されない。これは、同じAU内のPOCが異なる参照ピクチャは、同じ時刻インスタンスを有する参照ピクチャとみなされるためである。したがって、本実施形態では、参照ピクチャが現在ピクチャに関連付けられたAUに属する場合、動きベクトルスケーリング関数は1を返すことができる。

【0116】

同じ実施形態および他の実施形態では、参照ピクチャの空間解像度が現在ピクチャの空間解像度と異なる場合、時間動きベクトル予測のためのPOC差に基づく動きベクトルのスケーリングは、複数のピクチャにわたって任意選択的に無効にすることができる。動きベクトルのスケーリングが許可されている場合、動きベクトルは、現在ピクチャと参照ピクチャとの間のPOC差および空間解像度比の両方に基づいてスケーリングされる。

【0117】

同じまたは他の実施形態では、動きベクトルは、特にpoc＿cycle＿auが不均一な値を有する場合（vps＿contant＿poc＿cycle＿per＿au＝＝0の場合）、時間的な動きベクトル予測のために、POC差ではなくAUC差に基づいてスケーリングされてもよい。そうでない場合（vps＿contant＿poc＿cycle＿per＿au＝＝1の場合）、AUC差分に基づく動きベクトルのスケーリングは、POC差分に基づく動きベクトルのスケーリングと同一であり得る。

【0118】

同じまたは他の実施形態では、動きベクトルがAUC差に基づいてスケーリングされるとき、現在ピクチャと同じAU（同じAUC値を有する）内の参照動きベクトルは、AUC差に基づいてスケーリングされず、現在ピクチャと参照ピクチャとの間の空間解像度比に基づくスケーリングなしまたはスケーリングありの動きベクトル予測に使用される。

【0119】

同じ実施形態および他の実施形態において、AUC値は、AUの境界を識別するために使用され、AU粒度を有する入力および出力タイミングを必要とする仮想参照デコーダ（HRD）動作のために使用される。ほとんどの場合、AU内の最上位レイヤを持つデコードされたピクチャが、表示のために出力され得る。AUC値およびlayer＿id値は、出力ピクチャの識別に用いることができる。

【0120】

一実施形態では、ピクチャは、1つまたは複数のサブピクチャからなり得る。各サブピクチャは、ピクチャのローカル領域または全領域をカバーすることができる。サブピクチャによってサポートされる領域は、別のサブピクチャによってサポートされる領域と重なっていてもよいし、重なっていなくてもよい。1つまたは複数のサブピクチャによって構成される領域は、ピクチャの全領域をカバーしてもしなくてもよい。ピクチャがサブピクチャからなる場合、サブピクチャによってサポートされる領域はピクチャによってサポートされる領域と同一である。

【0121】

同じ実施形態において、サブピクチャは、コード化ピクチャに使用されるコーディング方法と同様のコーディング方法によってコード化されてもよい。サブピクチャは、独立してコード化され得るか、または、別のサブピクチャまたはコード化されたピクチャに依存してコード化され得る。サブピクチャは、別のサブピクチャまたはコード化されたピクチャからのシンタックス解析依存性を有しても、有しなくてもよい。

【0122】

同じ実施形態では、コード化サブピクチャは、1つまたは複数のレイヤに含まれてもよい。レイヤ内のコード化サブピクチャは、異なる空間解像度を有することができる。元のサブピクチャは、空間的に再サンプリング（アップサンプリングまたはダウンサンプリング）され、異なる空間解像度パラメータでコード化され、レイヤに対応するビットストリームに含まれ得る。

【0123】

同じ実施形態または他の実施形態において、（W、H）を有するサブピクチャは、Wがサブピクチャの幅を示し、Hがサブピクチャの高さをそれぞれ示す場合、コード化されてレイヤ0に対応するコード化されたビットストリームに含まれることができる一方で、（W＊S_w、k、H＊S_h、k）を有する元の空間解像度を有するサブピクチャからアップサンプリングされた（またはダウンサンプリングされた）サブピクチャがコード化されてレイヤkに対応するコード化されたビットストリームに含まれることができ、S_w、k、S_h、kは水平方向および垂直方向の再サンプリング比を示す。S_w、k、S_h、kの値が1より大きい場合、再サンプリングはアップサンプリングに等しい。一方、S_w、k、S_h、kの値が1より小さい場合、再サンプリングはダウンサンプリングに等しい。

【0124】

同じまたは他の実施形態では、レイヤ内のコード化されたサブピクチャは、同じサブピクチャまたは異なるサブピクチャ内の別のレイヤ内のコード化されたサブピクチャの視覚的品質とは異なる視覚的品質を有し得る。例えば、レイヤn内のサブピクチャiは量子化パラメータQ_i、nでコード化され、レイヤm内のサブピクチャjは量子化パラメータQ_j、mでコード化される。

【0125】

同じまたは他の実施形態では、レイヤ内のコード化サブピクチャは、同じローカル領域の別のレイヤ内のコード化サブピクチャからのシンタックス解析またはデコードの依存関係なしに、独立してデコード可能であり得る。同じローカル領域の別のサブピクチャレイヤを参照することなく独立して復号可能であり得るサブピクチャレイヤは、独立のサブピクチャレイヤである。独立のサブピクチャレイヤ内のコード化されたサブピクチャは、同じサブピクチャレイヤ内の以前にコード化されたサブピクチャからのデコーディングまたはシンタックス解析の依存関係を有しても有しなくてもよいが、コード化されたサブピクチャは、別のサブピクチャレイヤ内のコード化されたピクチャからのいかなる依存関係も有しなくてもよい。

【0126】

同じ実施形態または他の実施形態では、レイヤ内のコード化サブピクチャは、同じローカル領域の別のレイヤ内のコード化サブピクチャからの任意のシンタックス解析またはデコード依存性を伴って、依存してデコード可能であり得る。同じローカル領域の別のサブピクチャレイヤを参照して依存して復号可能であり得るサブピクチャレイヤは、依存サブピクチャレイヤである。依存サブピクチャ内のコード化されたサブピクチャは、同じサブピクチャに属するコード化されたサブピクチャ、同じサブピクチャレイヤ内の以前にコード化されたサブピクチャ、または両方の参照サブピクチャを参照することができる。

【0127】

同じまたは他の実施形態では、コード化されたサブピクチャは、1つまたは複数の独立のサブピクチャレイヤおよび1つまたは複数の依存したサブピクチャレイヤからなる。しかしながら、コード化されたサブピクチャに対して少なくとも1つの独立のたブピクチャレイヤが存在してもよい。独立のサブピクチャレイヤは、0に等しい、NALユニットヘッダまたは別の高レベルのシンタックス構造に存在し得るレイヤ識別子（layer＿id）の値を有し得る。layer＿idが0に等しいサブピクチャレイヤはベースサブピクチャレイヤである。

【0128】

同じ実施形態または他の実施形態において、ピクチャは、1つまたは複数の前景サブピクチャおよび1つの背景サブピクチャからなることができる。背景サブピクチャによってサポートされる領域は、ピクチャの領域と等しくてもよい。前景サブピクチャによってサポートされる領域は、背景サブピクチャによってサポートされる領域と重複してもよい。背景サブピクチャはベースサブピクチャレイヤであってもよく、前景サブピクチャは非ベース（エンハンスメント）サブピクチャレイヤであってもよい。1つまたは複数の非ベースサブピクチャレイヤは、デコードのために同じベースレイヤを参照することができる。layer＿idがaに等しい各非ベースサブピクチャレイヤは、layer＿idがbに等しい非ベースサブピクチャレイヤを参照することができ、aはbより大きい。

【0129】

同じまたは他の実施形態では、ピクチャは、背景サブピクチャの有無にかかわらず、1つまたは複数の前景サブピクチャからなることができる。各サブピクチャは、それ自体のベースサブピクチャレイヤおよび1つまたは複数の非ベース（エンハンスメント）レイヤを有することができる。各ベースサブピクチャレイヤは、1つまたは複数の非ベースサブピクチャレイヤによって参照され得る。layer＿idがaに等しい各非ベースサブピクチャレイヤは、layer＿idがbに等しい非ベースサブピクチャレイヤを参照することができ、aはbより大きい。

【0130】

同じまたは他の実施形態では、ピクチャは、背景サブピクチャの有無にかかわらず、1つまたは複数の前景サブピクチャからなることができる。（ベースまたは非ベース）サブピクチャレイヤ内の各々のコード化されたサブピクチャは、同じサブピクチャに属する1つまたは複数の非ベースレイヤサブピクチャと、同じサブピクチャに属さない1つまたは複数の非ベースレイヤサブピクチャとによって参照され得る。

【0131】

同じまたは他の実施形態では、ピクチャは、背景サブピクチャの有無にかかわらず、1つまたは複数の前景サブピクチャからなることができる。レイヤa内のサブピクチャは、同じレイヤ内の複数のサブピクチャにさらに分割され得る。レイヤb内の1または複数のコード化されたサブピクチャは、レイヤa内の分割サブピクチャを参照することができる。

【0132】

同じ実施形態または他の実施形態において、コード化されたビデオシーケンス（CVS）は、コード化されたピクチャのグループであってもよい。CVSは、1つまたは複数のコード化されたサブピクチャシーケンス（CSPS）からなることができ、CSPSは、ピクチャの同じローカル領域をカバーするコード化されたサブピクチャのグループとすることができる。CSPSは、コード化されたビデオシーケンスの時間分解能と同じまたは異なる時間解像度を有し得る。

【0133】

同じまたは他の実施形態では、CSPSはコード化され、1つまたは複数のレイヤに含まれてもよい。CSPSは、1つまたは複数のCSPレイヤからなり得る。CSPSに対応する1つまたは複数のCSPレイヤをデコーディングすることは、同じローカル領域に対応するサブピクチャのシーケンスを再構築することができる。

【0134】

同じまたは他の実施形態では、CSPSに対応するCSPレイヤの数は、別のCSPSに対応するCSPレイヤの数と同一であっても異なっていてもよい。

【0135】

同じまたは他の実施形態では、CSPレイヤは、別のCSPレイヤとは異なる時間分解能（例えば、フレームレート）を有し得る。元の（圧縮されていない）サブピクチャシーケンスは、時間的に再サンプリング（アップサンプリングまたはダウンサンプリング）され、異なる時間分解能パラメータでコード化され、レイヤに対応するビットストリームに含まれ得る。

【0136】

同じ実施形態または他の実施形態において、フレームレートFを有するサブピクチャシーケンスがコード化され、レイヤ0に対応するコード化されたビットストリームに含まれてもよく、F＊S_t、kを有する元のサブピクチャシーケンスからの時間的にアップサンプリングされた（またはダウンサンプリングされた）サブピクチャシーケンスがコード化され、レイヤkに対応するコード化ビットストリームに含まれてもよく、S_t、kはレイヤkの時間的サンプリング比を示す。S_t、kの値が1より大きい場合、時間的再サンプリング処理はフレームレートアップ変換に等しい。一方、S_t、kの値が1より小さい場合、時間的再サンプリング処理はフレームレートダウン変換に等しい。

【0137】

同じまたは他の実施形態では、CSPレイヤaを有するサブピクチャが動き補償または任意のレイヤ間予測のためにCSPレイヤbを有するサブピクチャによって参照されるとき、CSPレイヤaの空間解像度がCSPレイヤbの空間解像度と異なる場合、CSPレイヤa内のデコードされたピクセルは再サンプリングされ、参照に使用される。再サンプリング処理は、アップ・サンプリング・フィルタリングまたはダウン・サンプリング・フィルタリングを必要とする場合がある。

【0138】

同じまたは他の実施形態では、図9は、コード化ビデオシーケンス内のすべてのピクチャ／スライスに使用されるpoc＿cycle＿auを示す、VPS（またはSPS）内のvps＿poc＿cycle＿auのシンタックス要素、およびスライスヘッダ内の現在のスライスのpoc＿cycle＿auを示す、slice＿poc＿cycle＿auのシンタックス要素をシグナリングするためのシンタックステーブルの例を示す。POC値がAU毎に一律に増加する場合、VPSにおけるvps＿contant＿poc＿cycle＿per＿auを1に設定し、VPSにおいてvps＿poc＿cycle＿auをシグナリングする。この場合、slice＿poc＿cycle＿auは明示的にシグナリングされず、POCの値をvps＿poc＿cycle＿auで除算することにより、AU毎のAUCの値が算出される。POC値がAU毎に一律に増加しない場合、VPSにおけるvps＿contant＿poc＿cycle＿per＿auを0とする。この場合、vps＿access＿unit＿cntはシグナリングされず、slice＿access＿unit＿cntは、スライスまたはピクチャ毎にスライスヘッダでシグナリングされる。各スライスまたはピクチャは、異なる値のslice＿access＿unit＿cntを有してもよい。AU毎のAUCの値は、POCの値をslice＿poc＿cycle＿auで除算することにより算出される。図10は、関連する作業フローを示すブロック図を示す。

【0139】

同じまたは他の実施形態では、ピクチャ、スライス、またはタイルのPOCの値が異なっていても、同じAUC値を有するAUに対応するピクチャ、スライス、またはタイルは、同じデコーディングまたは出力時間インスタンスに関連付けられ得る。したがって、同じAU内のピクチャ、スライス、またはタイルにわたるシンタックス解析／デコーディング間の依存関係なしに、同じAUに関連付けられたピクチャ、スライス、またはタイルのすべてまたはサブセットを並列にデコードすることができ、同時に出力することができる。

【0140】

同じまたは他の実施形態では、ピクチャ、スライス、またはタイルのPOCの値が異なっていても、同じAUC値を有するAUに対応するピクチャ、スライス、またはタイルは、同じ合成／表示時間インスタンスに関連付けられ得る。合成時間がコンテナ形式に含まれている場合、ピクチャが異なるAUに対応していても、ピクチャが同じ合成時間を有する場合、それらのピクチャは同じ時間インスタンスにおいて表示され得る。

【0141】

同じまたは他の実施形態では、各ピクチャ、スライス、またはタイルは、同じAU内で同じ時間識別子（temporal＿id）を有することができる。時間インスタンスに対応するピクチャ、スライス、またはタイルのすべてまたはサブセットは、同じ時間サブレイヤに関連付けられ得る。同じまたは他の実施形態では、各ピクチャ、スライス、またはタイルは、同じAU内の同じまたは異なる空間レイヤID（layer＿id）を有することができる。時間インスタンスに対応するピクチャ、スライス、またはタイルのすべてまたはサブセットは、同じまたは異なる空間レイヤに関連付けられ得る。

【0142】

図11は、layer＿idが0に等しい背景ビデオCSPSおよび複数の前景CSPレイヤを含む例示的なビデオストリームを示す。コード化されたサブピクチャは1つまたは複数のCSPレイヤからなり得るが、いかなる前景CSPレイヤにも属さない背景領域はベースレイヤからなり得る。ベースレイヤは背景領域および前景領域を含むことができ、一方、エンハンスメントCSPレイヤは前景領域を含む。エンハンスメントCSPレイヤは、同じ領域において、ベースレイヤよりも良好な視覚的品質を有し得る。エンハンスメントCSPレイヤは、同じ領域に対応する、再構築されたピクセルおよびベースレイヤの動きベクトルを参照することができる。

【0143】

同じまたは他の実施形態では、ベースレイヤに対応するビデオビットストリームはトラックに含まれ、各サブピクチャに対応するCSPレイヤはビデオファイル内の分離されたトラックに含まれる。

【0144】

同じまたは他の実施形態では、ベースレイヤに対応するビデオビットストリームはトラックに含まれ、同じlayer＿idを有するCSPレイヤは分離されたトラックに含まれる。この例では、レイヤkに対応するトラックは、レイヤkに対応するCSPレイヤのみを含む。

【0145】

同じまたは他の実施形態では、各サブピクチャの各CSPレイヤは、別個のトラックに格納される。各トラックは、1つまたは複数の他のトラックからのいかなるシンタックス解析またはデコーディング依存性も有していても、有していなくてもよい。

【0146】

同じまたは他の実施形態では、各トラックは、サブピクチャのすべてまたはサブセットのCSPレイヤのレイヤiからレイヤjに対応するビットストリームを含むことができ、0＜i＝＜j＝＜kであり、kはCSPSの最上位レイヤである。

【0147】

同じまたは他の実施形態では、ピクチャは、深度マップ、アルファマップ、3 Dジオメトリデータ、占有マップなどを含む1つまたは複数の関連するメディアデータからなる。そのような関連する時限メディアデータは、それぞれが1つのサブピクチャに対応する1つまたは複数のデータサブストリームに分割することができる。

【0148】

同じまたは他の実施形態では、図12は、マルチレイヤ・サブピクチャ方法に基づくテレビ会議の一例を示す。ビデオストリームには、背景ピクチャに対応する1つのベースレイヤビデオビットストリームと、前景サブピクチャに対応する1つまたは複数のエンハンスメントレイヤ・ビデオビットストリームとが含まれる。各エンハンスメントレイヤ・ビットストリームは、CSPレイヤに対応する。ディスプレイでは、ベースレイヤに対応するピクチャがデフォルトで表示される。これは、1つまたは複数のユーザのピクチャ内のピクチャ（PIP）を含む。クライアントの制御によって特定のユーザが選択されると、選択されたユーザに対応するエンハンスメントCSPレイヤがデコードされ、エンハンスされた品質または空間解像度で表示される。図13は、動作のための図を示す。

【0149】

同じまたは他の実施形態では、ネットワーク中間ボックス（ルータなど）は、その帯域幅に応じて、ユーザに送信するレイヤのサブセットを選択することができる。ピクチャ／サブピクチャ編成は、帯域幅適応のために使用され得る。例えば、ユーザが帯域幅を有していない場合、ルータは、それらの重要性に起因して、または使用される設定に基づいて、レイヤを取り去る、またはいくつかのサブピクチャを選択し、これは、帯域幅を採用するために動的に行うことができる。

【0150】

図14は、360ビデオのユースケースを示す。球面360ピクチャが平面ピクチャ上に投影される場合、投影360ピクチャは、ベースレイヤとして複数のサブピクチャに分割され得る。特定のサブピクチャのエンハンスメントレイヤは、コード化され、クライアントに送信され得る。デコーダは、すべてのサブピクチャを含むベースレイヤと選択されたサブピクチャのエンハンスメントレイヤの両方をデコードすることができる。現在のビューポートが選択されたサブピクチャと同一である場合、表示されたピクチャは、エンハンスメントレイヤを有するデコードされたサブピクチャでより高い品質を有することができる。そうでなければ、ベースレイヤを有するデコードされたピクチャを低い質で表示することができる。

【0151】

同じ実施形態または他の実施形態では、表示用の任意のレイアウト情報が補助情報（SEIメッセージまたはメタデータなど）としてファイルに存在してもよい。1つまたは複数のデコードされたサブピクチャは、シグナリングされたレイアウト情報に応じて再配置および表示され得る。レイアウト情報は、ストリーミングサーバまたは放送局によってシグナリングされてもよいし、ネットワークエンティティまたはクラウドサーバによって再生成されてもよいし、ユーザのカスタマイズされた設定によって決定されてもよい。

【0152】

一実施形態では、入力ピクチャが1つまたは複数の（矩形の）サブ領域に分割される場合、各サブ領域は独立のレイヤとしてコード化され得る。ローカル領域に対応する各独立レイヤは、一意のlayer＿id値を有することができる。各独立のレイヤについて、サブピクチャサイズおよび位置情報がシグナリングされ得る。例えば、ピクチャサイズ（幅、高さ）、左上隅のオフセット情報（x＿offset、y＿offset）である。図15は、分割されたサブピクチャのレイアウト、そのサブピクチャサイズおよび位置情報、ならびにその対応するピクチャ予測構造の一例を示す。サブピクチャサイズ（複数可）およびサブピクチャ位置（複数可）を含むレイアウト情報は、パラメータセット（複数可）、スライスもしくはタイルグループのヘッダ、またはSEIメッセージなどの高レベルシンタックス構造でシグナリングされ得る。

【0153】

同じ実施形態において、独立のレイヤに対応する各サブピクチャは、AU内にその一意のPOC値を有し得る。DPBに格納されたピクチャのうちの参照ピクチャをRPSまたはRPL構造のシンタックス要素を用いて示す場合、レイヤに対応する各サブピクチャのPOC値を用いてもよい。

【0154】

同一または他の実施形態では、（レイヤ間）予測構造を示すために、layer＿idは使用されなくてもよく、POC（デルタ）値が使用されてもよい。

【0155】

同じ実施形態では、レイヤ（またはローカル領域）に対応するNに等しいPOC値を有するサブピクチャは、動き補償予測のための同じレイヤ（または同じローカル領域）に対応する、N＋Kに等しいPOC値を有するサブピクチャの参照ピクチャとして使用されてもされなくてもよい。ほとんどの場合、数Kの値は、（独立の）レイヤの最大数に等しくてもよく、これはサブ領域の数と同一であってもよい。

【0156】

同じまたは他の実施形態では、図16は、図15の拡張ケースを示す。入力ピクチャが複数の（例えば4つの）サブ領域に分割される場合、各ローカル領域は1つまたは複数のレイヤでコード化され得る。この場合、独立のレイヤの数はサブ領域の数に等しくてもよく、1つまたは複数のレイヤがサブ領域に対応してもよい。したがって、各サブ領域は、1または複数の独立のレイヤおよび0または複数の独立のレイヤでコード化され得る。

【0157】

同じ実施形態では、図16において、入力ピクチャは4つのサブ領域に分割され得る。右上部サブ領域は、レイヤ1およびレイヤ4である2つのレイヤとしてコード化されてもよく、右下部サブ領域は、レイヤ3およびレイヤ5である2つのレイヤとしてコード化されてもよい。この場合、レイヤ4は、動き補償予測のためにレイヤ1を参照することができ、レイヤ5は、動き補償のためにレイヤ3を参照することができる。

【0158】

同じまたは他の実施形態では、レイヤ境界にわたるインループフィルタリング（デブロッキングフィルタ、適応インループフィルタ、リシェーパ、バイラテラルフィルタ、または任意のディープラーニングベースのフィルタリングなど）は、（任意選択的に）無効にすることができる。

【0159】

同じまたは他の実施形態では、レイヤ境界にわたる動き補償予測またはブロック内コピーは、（任意選択的に）無効にすることができる。

【0160】

同じまたは他の実施形態では、サブピクチャの境界における動き補償予測またはインループフィルタリングのための境界パディングは、任意選択的に処理されてもよい。境界パディングが処理されるか否かを示すフラグは、パラメータセット（VPS、SPS、PPS、またはAPS）、スライスもしくはタイルグループヘッダ、またはSEIメッセージなどの高レベルシンタックス構造でシグナリングすることができる。

【0161】

同じまたは他の実施形態では、サブ領域（またはサブピクチャ）のレイアウト情報は、VPSまたはSPSでシグナリングされ得る。図17は、VPSおよびSPSのシンタックス要素の一例を示す。この例では、VPSにおいて、vps＿sub＿picture＿dividing＿flagがシグナリングされる。フラグは、入力ピクチャが複数のサブ領域に分割されているか否かを示すことができる。vps＿sub＿picture＿dividing＿flagの値が0に等しいとき、現在のVPSに対応するコード化されたビデオシーケンス内の入力ピクチャは、複数のサブ領域に分割されなくてもよい。この場合、入力ピクチャサイズは、SPSでシグナリングされるコード化されたピクチャサイズ（pic＿width＿in＿luma＿samples、pic＿height＿in＿luma＿samples）と等しくてもよい。vps＿sub＿picture＿dividing＿flagの値が1に等しいとき、入力ピクチャは複数のサブ領域に分割され得る。この場合、シンタックス要素vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesがVPSでシグナリングされる。vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesの値は、それぞれ入力ピクチャの幅および高さに等しくてもよい。

【0162】

同じ実施形態において、vps＿full＿pic＿width＿in＿luma＿samplesおよびvps＿full＿pic＿height＿in＿luma＿samplesの値は、デコーディングに使用されなくてもよく、合成および表示に使用されてもよい。

【0163】

同じ実施形態において、vps＿sub＿picture＿dividing＿flagの値が1に等しいとき、シンタックス要素pic＿offset＿xおよびpic＿offset＿yは、（a）特定のレイヤ（複数可）に対応するSPSにおいてシグナリングされ得る。この場合、SPSでシグナリングされるコード化されたピクチャサイズ（pic＿width＿in＿luma＿samples、pic＿height＿in＿luma＿samples）は、特定のレイヤに対応するサブ領域の幅および高さに等しくてもよい。また、サブ領域の左上隅の位置（pic＿offset＿x、pic＿offset＿y）は、SPSでシグナリングされてもよい。

【0164】

同じ実施形態では、サブ領域の左上隅の位置情報（pic＿offset＿x、pic＿offset＿y）はデコーディングに使用されなくてもよく、合成および表示に使用されてもよい。

【0165】

同じまたは他の実施形態では、入力ピクチャのすべてまたはサブセットサブ領域のレイアウト情報（サイズおよび位置）、レイヤ間の依存関係情報は、パラメータセットまたはSEIメッセージでシグナリングされ得る。図18は、サブ領域のレイアウト（the information o the layout of sub－regions）、レイヤ間の依存関係、およびサブ領域と1つまたは複数のレイヤとの間の関係に関する情報を示すシンタックス要素の一例を示す。この例では、シンタックス要素num＿sub＿regionは、現在のコード化されたビデオシーケンス内の（矩形の）サブ領域の数を示す。シンタックス要素num＿layersは、現在のコード化されたビデオシーケンス内のレイヤ数を示す。num＿layersの値は、num＿sub＿regionの値以上であってもよい。任意のサブ領域が単一のレイヤとしてコード化される場合、num＿layersの値は、num＿sub＿regionの値と等しくてもよい。1つまたは複数のサブ領域が複数のレイヤとしてコード化されるとき、num＿layersの値は、num＿sub＿regionの値よりも大きくてもよい。シンタックス要素direct＿dependency＿flag ［ i ］［ j ］は、第jレイヤから第iレイヤへの依存性を示す。num＿layers＿for＿region ［ i ］は、第iサブ領域に対応付けられているレイヤ数を示す。sub＿region＿layer＿id ［ i ］［ j ］は、第iサブ領域に対応付けられた第jレイヤのlayer＿idを示す。sub＿region＿offset＿x ［ i ］およびsub＿region＿offset＿y ［ i ］は、それぞれ、第iサブ領域の左上隅の水平および垂直位置を示す。sub＿region＿width ［ i ］およびsub＿region＿height ［ i ］は、それぞれ第iサブ領域の幅および高さを示す。

【0166】

一実施形態では、プロファイル・ティア・レイヤ・レベル情報の有無にかかわらず出力される複数のレイヤのうちの1つを示すように設定された出力レイヤを指定する1つまたは複数のシンタックス要素は、高レベルのシンタックス構造、例えば、VPS、DPS、SPS、PPS、APSまたはSEIメッセージでシグナリングされ得る。図19を参照すると、VPSを参照するコード化されたビデオシーケンスにおける出力レイヤセット（OLS）の数を示すシンタックス要素num＿output＿layer＿setsは、VPSにおいてシグナリングされ得る。出力レイヤセット毎に、出力レイヤの数と同じ数だけoutput＿layer＿flagがシグナリングされ得る。

【0167】

同じ実施形態において、1に等しいoutput＿layer＿flag［ i ］は、第iレイヤが出力されることを指定する。0と等しいvps＿output＿layer＿flag［ i ］は、第iレイヤが出力されないことを指定する。

【0168】

同じまたは他の実施形態では、各出力レイヤセットのプロファイル・ティア・レベル情報を指定する1つまたは複数のシンタックス要素は、高レベルのシンタックス構造、例えばVPS、DPS、SPS、PPS、APSまたはSEIメッセージでシグナリングされ得る。さらに図19を参照すると、VPSを参照するコード化されたビデオシーケンス内のOLS毎のプロファイル・ティア・レベル情報の数を示すシンタックス要素num＿profile＿tile＿levelは、VPS内でシグナリングされ得る。出力レイヤセット毎に、プロファイル・ティア・レベル情報のシンタックス要素のセット、またはプロファイル・ティア・レベル情報内のエントリのうちの特定のプロファイル・ティア・レベル情報を示すインデックスが、出力レイヤの数と同じ数だけシグナリングされ得る。

【0169】

同じ実施形態において、profile＿tier＿level＿idx ［ i ］［ j ］は、VPS内のprofile＿tier＿level（）シンタックス構造のリスト内で、第iのOLSの第jレイヤに適用されるprofile＿tier＿level（）シンタックス構造のインデックスを指定する。

【0170】

同じまたは他の実施形態では、図20を参照すると、最大レイヤ数が1より大きい（vps＿max＿layers＿minus1＞0）場合、シンタックス要素num＿profile＿tile＿levelおよび／またはnum＿output＿layer＿setsがシグナリングされ得る。

【0171】

同じまたは他の実施形態では、図20を参照すると、第iの出力レイヤセットに対する出力レイヤシグナリングのモードを示すシンタックス要素vps＿output＿layers＿mode ［ i ］は、VPS内に存在し得る。

【0172】

同じ実施形態において、0に等しいvps＿output＿layers＿mode［ i ］は、第i出力レイヤセットで最上位レイヤのみが出力されることを指定する。1に等しいvps＿output＿layer＿mode［ i ］は、すべてのレイヤが第i出力レイヤセットで出力されることを指定する。2に等しいvps＿output＿layer＿mode［ i ］は、出力されるレイヤが、第i出力レイヤが設定された1に等しいvps＿output＿layer＿flag［ i ］［ j ］を有するレイヤであることを指定する。より多くの値が予約されてもよい。

【0173】

同じ実施形態において、output＿layer＿flag ［ i ］［ j ］は、第i出力レイヤセットについてのvps＿output＿layers＿mode ［ i ］の値に応じてシグナリングされてもされなくてもよい。

【0174】

同じまたは他の実施形態では、図20を参照すると、第i出力レイヤセットについてフラグvps＿ptl＿signal＿flag ［ i ］が存在してもよい。vps＿ptl＿signal＿flag ［ i ］の値に応じて、第iの出力レイヤセットのプロファイル・ティア・レベル情報はシグナリングされてもされなくてもよい。

【0175】

同じまたは他の実施形態では、図21を参照すると、現在のCVS内のサブピクチャの数max＿subpics＿minus1は、高レベルのシンタックス構造、例えばVPS、DPS、SPS、PPS、APSまたはSEIメッセージでシグナリングされ得る。

【0176】

同じ実施形態では、図21を参照すると、サブピクチャの数が1より大きい場合（max＿subpics＿minus1＞0）、第iサブピクチャのサブピクチャ識別子sub＿pic＿id［ i ］がシグナリングされ得る。

【0177】

同じまたは他の実施形態では、各出力レイヤセットの各レイヤに属するサブピクチャ識別子を示す1つまたは複数のシンタックス要素は、VPSでシグナリングされ得る。図22および図23を参照すると、sub＿pic＿id＿layer ［ i ］［ j ］［ k ］は、第i出力レイヤセットの第jレイヤに存在する第kサブピクチャを示す。これらの情報を用いて、デコーダは、特定の出力レイヤセットのレイヤ毎にどのサブピクチャがデコードされて出力され得るかを認識することができる。

【0178】

一実施形態では、ピクチャヘッダ（PH）は、コード化されたピクチャのすべてのスライスに適用されるシンタックス要素を含むシンタックス構造である。ピクチャユニット（PU）は、指定された分類規則に従って互いに関連付けられ、デコード順で連続し、正確に1つのコード化されたピクチャを含むNALユニットのセットである。PUは、ピクチャヘッダ（PH）と、コード化されたピクチャを構成する1または複数のVCL NALユニットとを含み得る。

【0179】

一実施形態では、SPS（RBSP）は、参照される前にデコーディング処理に利用可能であり、0に等しいTemporalIdを有する少なくとも1つのAUに含まれるか、または外部手段を介して提供され得る。

【0180】

一実施形態では、SPS（RBSP）は、参照される前にデコーディング処理に利用可能であってもよく、SPSを参照する1つまたは複数のPPSを含む、CVS内の0に等しいTemporalIdを有する少なくとも1つのAUに含まれてもよく、または外部手段を介して提供されてもよい。

【0181】

一実施形態では、SPS（RBSP）は、SPSを参照する1つまたは複数のPPSを含む、または外部手段を介して提供される、CVS内のSPS NALユニットを参照するPPS NALユニットの最も低いnuh＿layer＿id値に等しいnuh＿layer＿idを有する少なくとも1つのPUに含まれる、1つまたは複数のPPSによって参照される前にデコーディング処理に利用可能であり得る。

【0182】

一実施形態では、SPS（RBSP）は、0に等しいTemporalIdおよびSPS NALユニットを参照するかまたは外部手段を介して提供されるPPS NALユニットの最も低いnuh＿layer＿id値に等しいnuh＿layer＿idを有する少なくとも1つのPUに含まれる、1つまたは複数のPPSによって参照される前にデコーディング処理に利用可能であり得る。

【0183】

一実施形態では、SPS（RBSP）は、SPSを参照する1つまたは複数のPPSを含む、CVS内のSPS NALユニットを参照するPPS NALユニットのTemporalIdが0に等しく、nuh＿layer＿idが最も低いnuh＿layer＿id値に等しい少なくとも1つのPUに含まれる、1つまたは複数のPPSによって参照される前にデコーディング処理に利用可能であり得るか、または外部手段を介して提供されるか、または外部手段を介して提供され得る。

【0184】

同じまたは他の実施形態では、pps＿seq＿parameter＿set＿idは、参照されるSPSのsps＿seq＿parameter＿set＿idの値を指定する。pps＿seq＿parameter＿set＿idの値は、CLVS内のコード化されたピクチャによって参照されるすべてのPPSにおいて同じであり得る。

【0185】

同じまたは他の実施形態では、CVS内のsps＿seq＿parameter＿set＿idの特定の値を有するすべてのSPS NALユニットは同じコンテンツを有することができる。

【0186】

同じまたは他の実施形態では、nuh＿layer＿id値に関係なく、SPS NALユニットは、sps＿seq＿parameter＿set＿idの同じ値空間を共有することができる。

【0187】

同じまたは他の実施形態では、SPS NALユニットのnuh＿layer＿id値は、SPS NALユニットを参照するPPS NALユニットの最も低いnuh＿layer＿id値に等しくてもよい。

【0188】

一実施形態では、mに等しいnuh＿layer＿idを有するSPSが、nに等しいnuh＿layer＿idを有する1つまたは複数のPPSによって参照されるとき。nuh＿layer＿idがmに等しいレイヤは、nuh＿layer＿idがnに等しいレイヤまたはnuh＿layer＿idがmに等しいレイヤの（直接的または間接的な）参照レイヤと同じであってもよい。

【0189】

一実施形態では、PPS（RBSP）は、PPS NALユニットのTemporalIdと等しいTemporalIdを有する少なくとも1つのAUに含まれるか、または外部手段を介して提供される、参照される前のデコーディング処理に利用可能であり得る。

【0190】

一実施形態では、PPS（RBSP）は、PPSを参照する1つまたは複数のPH（またはコード化スライスNALユニット）を含む、CVS内のPPS NALユニットのTemporalIdに等しいTemporalIdを有する少なくとも1つのAUに含まれる、または外部手段を介して提供される、参照される前のデコーディング処理に利用可能であり得る。

【0191】

一実施形態では、PPS（RBSP）は、PPSを参照する1つまたは複数のPH（またはコード化スライスNALユニット）を含む、または外部手段を介して提供される、CVS内のPPS NALユニットを参照するコード化スライスNALユニットの最低nuh＿layer＿id値に等しいnuh＿layer＿idを有する少なくとも1つのPUに含まれる、1つまたは複数のPH（またはコード化スライスNALユニット）によって参照される前に、デコーディング処理に利用可能であり得る。

【0192】

一実施形態では、PPS（RBSP）は、PPSを参照する1つまたは複数のPH（またはコード化スライスNALユニット）を含む、または外部手段を介して提供される、CVS内のPPS NALユニットを参照する、PPS NALユニットのTemporalIdに等しいTemporalIdおよびコード化スライスNALユニットの最低nuh＿layer＿id値に等しいnuh＿layer＿idを有する少なくとも1つのPUに含まれる、1つまたは複数のPH（またはコード化スライスNALユニット）によって参照される前に、デコーディング処理に利用可能であり得る。

【0193】

同じまたは他の実施形態では、PHのph＿pic＿parameter＿set＿idは、使用中の参照PPSのpps＿pic＿parameter＿set＿idの値を指定する。pps＿seq＿parameter＿set＿idの値は、CLVS内のコード化されたピクチャによって参照されるすべてのPPSにおいて同じであり得る。

【0194】

同じまたは他の実施形態では、PU内のpps＿pic＿parameter＿set＿idの特定の値を有するすべてのPPS NALユニットは同じコンテンツを有し得る。

【0195】

同じまたは他の実施形態では、nuh＿layer＿id値に関係なく、PPS NALユニットは、pps＿pic＿parameter＿set＿idの同じ値空間を共有することができる。

【0196】

同じまたは他の実施形態では、PPS NALユニットのnuh＿layer＿id値は、PPS NALユニットを参照するNALユニットを参照するコード化されたスライスNALユニットの最も低いnuh＿layer＿id値に等しくてもよい。

【0197】

一実施形態では、mに等しいnuh＿layer＿idを有するPPSが、nに等しいnuh＿layer＿idを有する1つまたは複数のコード化されたスライスNALユニットによって参照されるとき。nuh＿layer＿idがmに等しいレイヤは、nuh＿layer＿idがnに等しいレイヤまたはnuh＿layer＿idがmに等しいレイヤの（直接的または間接的な）参照レイヤと同じであってもよい。

【0198】

【0199】

【0200】

【0201】

【0202】

【0203】

同じまたは他の実施形態では、PU内のpps＿pic＿parameter＿set＿idの特定の値を有するすべてのPPS NALユニットは同じコンテンツを有し得る。

【0204】

同じまたは他の実施形態では、nuh＿layer＿id値に関係なく、PPS NALユニットは、pps＿pic＿parameter＿set＿idの同じ値空間を共有することができる。

【0205】

【0206】

【0207】

出力レイヤは、出力される出力レイヤセットのレイヤを示す。出力レイヤセット（OLS）は、指定されたレイヤのセットからなるレイヤのセットを示し、レイヤのセット内の1つまたは複数のレイヤが出力レイヤであるように指定される。出力レイヤセット（OLS）レイヤインデックスは、OLS内のレイヤの、OLS内のレイヤのリストに対するインデックスである。

【0208】

サブレイヤは、TemporalId変数の特定の値を有するVCL NALユニットおよび関連する非VCL NALユニットからなる、時間スケーラブルなビットストリームの時間スケーラブルなレイヤを示す。サブレイヤ表現は、特定のサブレイヤおよび下位サブレイヤのNALユニットからなるビットストリームのサブセットを示す。

【0209】

VPS RBSPは、参照される前にデコーディング処理に利用可能であり、TemporalIdが0である少なくとも1つのAUに含まれるか、または外部手段を介して提供され得る。CVS内のvps＿video＿parameter＿set＿idの特定の値を有するすべてのVPS NALユニットは、同じコンテンツを有することができる。

【0210】

vps＿video＿parameter＿set＿idは、他のシンタックス要素による参照のためのVPSの識別子を提供する。vps＿video＿parameter＿set＿idの値は0より大きくてもよい。

【0211】

vps＿max＿layers＿minus1＋1は、VPSを参照する各CVS内の最大許容レイヤ数を指定する。

【0212】

vps＿max＿sublayers＿minus1＋1は、VPSを参照する各CVS内のレイヤに存在し得る時間的サブレイヤの最大数を指定する。vps＿max＿sublayers＿minus1の値は、0以上6以下の範囲であってもよい。

【0213】

1に等しいvps＿all＿layers＿same＿num＿sublayers＿flagは、時間的サブレイヤの数が、VPSを参照する各CVS内のすべてのレイヤについて同じであることを指定する。0に等しいvps＿all＿layers＿same＿num＿sublayers＿flagは、VPSを参照する各CVS内のレイヤが同じ数の時間的サブレイヤを有しても有しなくてもよいことを指定する。存在しない場合、vps＿all＿layers＿same＿num＿sublayers＿flagの値は1に等しいと推測される。

【0214】

1に等しいvps＿all＿independent＿layers＿flagは、CVS内のすべてのレイヤがレイヤ間予測を使用せずに独立してコード化されることを指定する。0に等しいvps＿all＿independent＿layers＿flagは、CVS内の1つまたは複数のレイヤがレイヤ間予測を使用することができることを指定する。存在しない場合、vps＿all＿independent＿layers＿flagの値は1に等しいと推測される。

【0215】

vps＿layer＿id ［ i ］は、第iレイヤのnuh＿layer＿idの値を指定する。mおよびnの任意の2つの負でない整数値について、mがn未満であるとき、vps＿layer＿id ［ m ］の値はvps＿layer＿id ［ n ］未満であり得る。

【0216】

1に等しいvps＿independent＿layer＿flag［ i ］は、インデックスiを有するレイヤがレイヤ間予測を使用しないことを指定する。0に等しいvps＿independent＿layer＿flag［ i ］は、インデックスiを有するレイヤがレイヤ間予測を使用することができ、0以上i－1以下の範囲内のjのシンタックス要素vps＿direct＿ref＿layer＿flag［ i ］［ j ］がVPSに存在することを指定する。存在しない場合、vps＿independent＿layer＿flag［ i ］の値は1に等しいと推測される。

【0217】

0に等しいvps＿direct＿ref＿layer＿flag［ i ］［ j ］は、インデックスjを有するレイヤがインデックスiを有するレイヤに対する直接参照レイヤではないことを指定する。1に等しいvps＿direct＿ref＿layer＿flag［ i ］［ j ］は、インデックスjを有するレイヤがインデックスiを有するレイヤに対する直接参照レイヤであることを指定する。0以上、vps＿max＿layers＿minus1以下の範囲のiおよびjについて、vps＿direct＿ref＿layer＿flag［ i ］［ j ］が存在しない場合、0と等しいと推測される。vps＿independent＿layer＿flag［ i ］が0に等しいとき、vps＿direct＿ref＿layer＿flag［ i ］［ j ］の値が1に等しくなるように、0以上i－1以下の範囲内に少なくとも1つのjの値があってもよい。

【0218】

変数NumDirectRefLayers ［ i ］、DirectRefLayerIdx ［ i ］［ d ］、NumRefLayers ［ i ］、RefLayerIdx ［ i ］［ r ］、およびLayerUsedAsRefLayerFlag ［ j ］は、以下のように導出される。
for（i＝0；i ＜＝vps＿max＿layers＿minus1；i＋＋）｛
for（j＝0；j ＜＝vps＿max＿layers＿minus1；j＋＋）｛
dependencyFlag［ i ］［ j ］＝vps＿direct＿ref＿layer＿flag［ i ］［ j ］
for（k＝0；k＜i；k＋＋）
if（vps＿direct＿ref＿layer＿flag［ i ］［ k ］＆＆dependencyFlag［ k ］［ j ］）
dependencyFlag［ i ］［ j ］＝1
｝
LayerUsedAsRefLayerFlag［ i ］＝0
｝
for（i＝0；i ＜＝vps＿max＿layers＿minus1；i＋＋）｛
for（j＝0、d＝0、r＝0；j ＜＝vps＿max＿layers＿minus1；j＋＋）｛
if（vps＿direct＿ref＿layer＿flag［ i ］［ j ］）｛
DirectRefLayerIdx［ i ］［ d＋＋］＝j
LayerUsedAsRefLayerFlag［ j ］＝1
｝
if（dependencyFlag［ i ］［ j ］）
RefLayerIdx［ i ］［ r＋＋］＝j
｝
NumDirectRefLayers［ i ］＝d
NumRefLayers［ i ］＝r
｝

【0219】

vps＿layer＿id ［ i ］に等しいnuh＿layer＿idを有するレイヤのレイヤインデックスを指定する変数GeneralLayerIdx ［ i ］は、以下のように導出される。
for（i＝0；i ＜＝vps＿max＿layers＿minus1；i＋＋）
GeneralLayerIdx［ vps＿layer＿id［ i ］］＝i

【0220】

0以上からvps＿max＿layers＿minus1以下の範囲内の両方のiおよびjの任意の2つの異なる値について、dependencyFlag［ i ］［ j ］が1に等しいとき、第iレイヤに適用されるchroma＿format＿idcおよびbit＿depth＿minus8の値は、第jレイヤに適用されるchroma＿format＿idcおよびbit＿depth＿minus8の値にそれぞれ等しくなり得ることがビットストリーム適合性の要件である。

【0221】

1に等しいmax＿tid＿ref＿present＿flag［ i ］は、シンタックス要素max＿tid＿il＿ref＿pics＿plus1［ i ］が存在することを指定する。0に等しいmax＿tid＿ref＿present＿flag［ i ］は、シンタックス要素max＿tid＿il＿ref＿pics＿plus1［ i ］が存在しないことを指定する。

【0222】

0と等しいmax＿tid＿il＿ref＿pics＿plus1［ i ］は、第iレイヤの非IRAPピクチャではレイヤ間予測を用いないことを指定する。0より大きいmax＿tid＿il＿ref＿pics＿plus1［ i ］は、第iレイヤのピクチャをデコーディングするために、max＿tid＿il＿ref＿pics＿plus1［ i ］－1より大きいTemporalIdを有するピクチャがILRPとして使用されないことを指定する。存在しない場合、max＿tid＿il＿ref＿pics＿plus1［ i ］の値は7に等しいと推測される。

【0223】

1に等しいeach＿layer＿is＿an＿ols＿flagは、各OLSが1つのレイヤのみを含み、VPSを参照するCVS内の各レイヤ自体がOLSであり、含まれる単一のレイヤが唯一の出力レイヤであることを指定する。each＿layer＿is＿an＿ols＿flagは0に等しく、OLSは2つ以上のレイヤを含み得る。vps＿max＿layers＿minus1が0に等しい場合、each＿layer＿is＿an＿ols＿flagの値は1に等しいと推測される。そうでない場合、vps＿all＿independent＿layers＿flagが0に等しいとき、each＿layer＿is＿an＿ols＿flagの値は0に等しいと推測される。

【0224】

0に等しいols＿mode＿idcは、VPSによって指定されたOLSの総数がvps＿max＿layers＿minus1＋1に等しいことを指定し、第iのOLSは0以上i以下のレイヤインデックスを有するレイヤを含み、各OLSについて、OLSの最上位レイヤのみが出力される。

【0225】

1に等しいols＿mode＿idcは、VPSによって指定されたOLSの総数がvps＿max＿layers＿minus1＋1に等しいことを指定し、第iのOLSは0以上i以下のレイヤインデックスを有するレイヤを含み、各OLSについて、OLS内のすべてのレイヤが出力される。

【0226】

2に等しいols＿mode＿idcは、VPSによって指定されたOLSの総数が明示的にシグナリングされ、各OLSについて出力レイヤが明示的にシグナリングされ、他のレイヤがOLSの出力レイヤの直接または間接参照レイヤであることを指定する。

【0227】

ols＿mode＿idcの値は、0以上2以下の範囲であってもよい。ols＿mode＿idcの値3は、ITU－T｜ISO／IECによる将来の使用のために予約されている。

【0228】

vps＿all＿independent＿layers＿flagが1に等しく、each＿layer＿is＿an＿ols＿flagが0に等しい場合、ols＿mode＿idcの値は2に等しいと推測される。

【0229】

num＿output＿layer＿sets＿minus1 plus1は、ols＿mode＿idcが2に等しいときにVPSによって指定されるOLSの総数を指定する。

【0230】

VPSによって指定されたOLSの総数を指定する変数TotalNumOlssは、以下のように導出される。
if（vps＿max＿layers＿minus1＝＝0）
TotalNumOlss＝1
else if（each＿layer＿is＿an＿ols＿flag ｜｜ ols＿mode＿idc＝＝0 ｜｜ ols＿mode＿idc＝＝1）
TotalNumOlss＝vps＿max＿layers＿minus1＋1
else if（ols＿mode＿idc＝＝2）
TotalNumOlss＝num＿output＿layer＿sets＿minus1＋1

【0231】

ols＿output＿layer＿flag［ i ］［ j ］が1であることは、nuh＿layer＿idがvps＿layer＿id［ j ］に等しいレイヤが、ols＿mode＿idcが2に等しいとき、第iのOLSの出力レイヤであることを指定し、ols＿output＿layer＿flag［ i ］［ j ］が0であることは、nuh＿layer＿idがvps＿layer＿id［ j ］に等しいレイヤが、ols＿mode＿idcが2に等しいとき、第iのOLSの出力レイヤではないことを指定する。

【0232】

第iのOLSにおける出力レイヤの数を指定する変数NumOutputLayersInOls［ i ］と、第iのOLSにおける第jレイヤにおけるサブレイヤの数を指定する変数NumSubLayersInLayerInOLS［ i ］［ j ］と、第iのOLSにおける第j出力レイヤのnuh＿layer＿id値を指定する変数OutputLayerIdInOls［ i ］［ j ］と、第kレイヤが少なくとも1つのOLSにおいて出力レイヤとして使用されるか否かを指定する変数LayerUsedAsOutputLayerFlag［ k ］とは、以下のように導出される。
NumOutputLayersInOls［ 0 ］＝1
OutputLayerIdInOls［ 0 ］［ 0 ］＝vps＿layer＿id［ 0 ］
NumSubLayersInLayerInOLS［ 0 ］［ 0 ］＝vps＿max＿sub＿layers＿minus1＋1
LayerUsedAsOutputLayerFlag［ 0 ］＝1
for（i＝1、i ＜＝vps＿max＿layers＿minus1；i＋＋）｛
if（each＿layer＿is＿an＿ols＿flag ｜｜ ols＿mode＿idc＜2）
LayerUsedAsOutputLayerFlag［ i ］＝1
else ／＊（！each＿layer＿is＿an＿ols＿flag＆＆ols＿mode＿idc＝＝2）＊／
LayerUsedAsOutputLayerFlag［ i ］＝0
｝
for（i＝1；i＜TotalNumOlss；i＋＋）
if（each＿layer＿is＿an＿ols＿flag ｜｜ ols＿mode＿idc＝＝0）｛
NumOutputLayersInOls［ i ］＝1
OutputLayerIdInOls［ i ］［ 0 ］＝vps＿layer＿id［ i ］
for（j＝0；j＜i＆＆（ols＿mode＿idc＝＝0）；j＋＋）
NumSubLayersInLayerInOLS［ i ］［ j ］＝max＿tid＿il＿ref＿pics＿plus1［ i ］
NumSubLayersInLayerInOLS［ i ］［ i ］＝vps＿max＿sub＿layers＿minus1＋1
｝ else if（ols＿mode＿idc＝＝1）｛
NumOutputLayersInOls［ i ］＝i＋1
for（j＝0；j＜NumOutputLayersInOls［ i ］；j＋＋）｛
OutputLayerIdInOls［ i ］［ j ］＝vps＿layer＿id［ j ］
NumSubLayersInLayerInOLS［ i ］［ j ］＝vps＿max＿sub＿layers＿minus1＋1
｝
｝ else if（ols＿mode＿idc＝＝2）｛
for（j＝0；j ＜＝vps＿max＿layers＿minus1；j＋＋）｛
layerIncludedInOlsFlag［ i ］［ j ］＝0
NumSubLayersInLayerInOLS［ i ］［ j ］＝0
｝
for（k＝0，j＝0；k ＜＝vps＿max＿layers＿minus1；k＋＋）（40）
if（ols＿output＿layer＿flag［ i ］［ k ］）｛
layerIncludedInOlsFlag［ i ］［ k ］＝1
LayerUsedAsOutputLayerFlag［ k ］＝1
OutputLayerIdx［ i ］［ j ］＝k
OutputLayerIdInOls［ i ］［ j＋＋］＝vps＿layer＿id［ k ］
NumSubLayersInLayerInOLS［ i ］［ j ］＝vps＿max＿sub＿layers＿minus1＋1
｝
NumOutputLayersInOls［ i ］＝j
for（j＝0；j＜NumOutputLayersInOls［ i ］；j＋＋）｛
idx＝OutputLayerIdx［ i ］［ j ］
for（k＝0；k＜NumRefLayers［ idx ］；k＋＋）｛
layerIncludedInOlsFlag［ i ］［ RefLayerIdx［ idx ］［ k ］］＝1
if（NumSubLayersInLayerInOLS［ i ］［ RefLayerIdx［ idx ］［ k ］］＜
max＿tid＿il＿ref＿pics＿plus1［ OutputLayerIdInOls［ i ］［ j ］］）
NumSubLayersInLayerInOLS［ i ］［ RefLayerIdx［ idx ］［ k ］］＝
max＿tid＿il＿ref＿pics＿plus1［ OutputLayerIdInOls［ i ］［ j ］］
｝
｝
｝

【0233】

0以上、vps＿max＿layers＿minus1以下の範囲のiの各値について、LayerUsedAsRefLayerFlag［ i ］およびLayerUsedAsOutputLayerFlag［ i ］の値は、いずれも0に等しくなくてもよい。言い換えると、少なくとも1つのOLSの出力レイヤでも他のレイヤの直接参照レイヤでもないレイヤは存在しなくてもよい。

【0234】

各OLSについて、出力レイヤである少なくとも1つのレイヤが存在し得る。すなわち、0以上TotalNumOlss－1以下の範囲の任意のiの値について、NumOutputLayersInOls［ i ］の値を1以上としてもよい。

【0235】

第iのOLSのレイヤ数を指定する変数NumLayersInOls ［ i ］と、第iのOLSの第jレイヤのnuh＿layer＿id値を指定する変数LayerIdInOls ［ i ］［ j ］とは、以下のように導出される。
NumLayersInOls［ 0 ］＝1
LayerIdInOls［ 0 ］［ 0 ］＝vps＿layer＿id［ 0 ］
for（i＝1；i＜TotalNumOlss；i＋＋）｛
if（each＿layer＿is＿an＿ols＿flag）｛
NumLayersInOls［ i ］＝1
LayerIdInOls［ i ］［ 0 ］＝vps＿layer＿id［ i ］
｝ else if（ols＿mode＿idc＝＝0 ｜｜ ols＿mode＿idc＝＝1）｛
NumLayersInOls［ i ］＝i＋1
for（j＝0；j＜NumLayersInOls［ i ］；j＋＋）
LayerIdInOls［ i ］［ j ］＝vps＿layer＿id［ j ］
｝ else if（ols＿mode＿idc＝＝2）｛
for（k＝0，j＝0；k ＜＝vps＿max＿layers＿minus1；k＋＋）
if（layerIncludedInOlsFlag［ i ］［ k ］）
LayerIdInOls［ i ］［ j＋＋］＝vps＿layer＿id［ k ］
NumLayersInOls［ i ］＝j
｝
｝

【0236】

nuh＿layer＿idがLayerIdInOls ［ i ］［ j ］に等しいレイヤのOLSレイヤインデックスを指定する変数OlsLayerIdx ［ i ］［ j ］は、以下のように導出される。
for（i＝0；i＜TotalNumOlss；i＋＋）
for j＝0；j＜NumLayersInOls［ i ］；j＋＋）
OlsLayerIdx［ i ］［ LayerIdInOls［ i ］［ j ］］＝j

【0237】

各OLSにおける最下レイヤは、独立のレイヤであってもよい。すなわち、0以上TotalNumOlss－1以下の範囲のi毎に、vps＿independent＿layer＿flag［ GeneralLayerIdx［ LayerIdInOls［ i ］［ 0 ］］］の値が1になるようにしてもよい。

【0238】

各レイヤは、VPSによって指定される少なくとも1つのOLSに含まれてもよい。言い換えれば、0以上、vps＿max＿layers＿minus1以下の範囲内のkに対して、nuh＿layer＿id nuhLayerIdの特定の値がvps＿layer＿id［ k ］のうちの1つに等しい各レイヤについて、LayerIdInOls［ i ］［ j ］の値がnuhLayerIdに等しくなるように、iとjの値の少なくとも1つのペアが存在してもよく、iは0以上、TotalNumOlss－1以下の範囲内にあり、jはNumLayersInOls［ i ］－1以下の範囲内にある。

【0239】

一実施形態では、デコード処理は、現在ピクチャCurrPicについて以下のように動作する。
－PictureOutputFlagは以下のように設定される。
－以下の条件のうちの1つが真である場合、PictureOutputFlagは0に等しく設定される。
－現在ピクチャはRASLピクチャであり、関連付けられたIRAPピクチャのNoOutputBeforeRecoveryFlagは1に等しい。
－gdr＿enabled＿flagは1に等しく、現在ピクチャは、1に等しいNoOutputBeforeRecoveryFlagを有するGDRピクチャである。
－gdr＿enabled＿flagが1に等しく、現在ピクチャが、NoOutputBeforeRecoveryFlagが1に等しいGDRピクチャと関連付けられ、現在ピクチャのPicOrderCntValが、関連付けられたGDRピクチャのRpPicOrderCntValよりも小さい。
－sps＿video＿parameter＿set＿idが0より大きく、ols＿mode＿idcが0に等しく、現在のAUが以下の条件のすべてを満たすピクチャpicAを含む。
－PicAのPictureOutputFlagは1である。
－PicAは、現在ピクチャよりも大きなnuh＿layer＿id nuhLidを有する。
－PicAは、OLS（すなわち、OutputLayerIdInOls ［ TargetOlsIdx ］［ 0 ］はnuhLidに等しい）の出力レイヤに属する。
－sps＿video＿parameter＿set＿idが0より大きく、ols＿mode＿idcが2に等しく、ols＿output＿layer＿flag ［ TargetOlsIdx ］［ GeneralLayerIdx ［ nuh＿layer＿id ］］が0に等しい。
－そうでない場合、PictureOutputFlagはpic＿output＿flagと等しく設定される。

【0240】

現在ピクチャのすべてのスライスがデコードされた後、現在のデコードされたピクチャは「短期参照に使用」としてマークされ、RefPicList［ 0 ］またはRefPicList［ 1 ］内の各ILRPエントリは「短期参照に使用」としてマークされる。

【0241】

同一または他の実施形態において、各レイヤが出力レイヤセットである場合、PictureOutputFlagは、ols＿mode＿idcの値にかかわらず、pic＿output＿flagと等しく設定される。

【0242】

同一または他の実施形態において、PictureOutputFlagは、sps＿video＿parameter＿set＿idが0より大きい場合に0に等しく設定され、each＿layer＿is＿an＿ols＿flagが0に等しく、ols＿mode＿idcが0に等しく、現在のAUが以下の条件：PicAが1に等しいPictureOutputFlagを有する、PicAが現在ピクチャのものより大きいnuh＿layer＿id nuhLidを有する、およびPicAがOLS（すなわち、OutputLayerIdInOls［ TargetOlsIdx ］［ 0 ］はnuhLidに等しい）の出力レイヤに属する、のすべてを満たすピクチャpicAを含む。

【0243】

同一または他の実施形態において、PictureOutputFlagは、sps＿video＿parameter＿set＿idが0より大きい場合に0に等しく設定され、each＿layer＿is＿an＿ols＿flagが0に等しく、ols＿mode＿idcが2に等しく、ols＿output＿layer＿flag ［ TargetOlsIdx ］［ GeneralLayerIdx ［ nuh＿layer＿id ］］が0に等しい。

【0244】

ピクチャが、動き補償またはパラメータ予測のために、1つまたは複数の後続のピクチャによってデコード順に参照されてもされなくてもよい場合。現在ピクチャが以下のピクチャによって参照されているかどうかを示すフラグは、ピクチャヘッダまたはスライスヘッダで明示的にシグナリングされてもよい。

【0245】

例えば、図24では、non＿reference＿picture＿flagがピクチャヘッダでシグナリングされる。1に等しいnon＿reference＿picture＿flagは、PHと関連付けられたピクチャが決して参照ピクチャとして使用されないことを指定する。0に等しいnon＿reference＿picture＿flagは、PHと関連付けられたピクチャが参照ピクチャとして用いられても用いられなくてもよいことを指定する。

【0246】

ピクチャがクロップされ、表示または他の目的のために出力されてもされなくてもよい場合。現在ピクチャがクロップされて出力されるか否かを示すフラグは、ピクチャヘッダまたはスライスヘッダで明示的にシグナリングされ得る。

【0247】

例えば、図24では、pic＿output＿flagがピクチャヘッダ内でシグナリングされる。1に等しいpic＿output＿flagは、現在ピクチャがクロップされて出力され得ることを示す。0に等しいpic＿output＿flagは、現在ピクチャがクロップされて出力されない可能性があることを示す。

【0248】

現在ピクチャがデコード順で後続のピクチャによって参照されない可能性がある非参照ピクチャであり、non＿reference＿picture＿flagの値が1に等しいとき、pic＿output＿flagの値は1に等しくなり得るが、これは、後続のピクチャによって参照されず、出力されない任意のピクチャがデコーダ側でビデオビットストリームに含まれない可能性があるためである。

【0249】

同じまたは他の実施形態において、現在ピクチャが非参照ピクチャ（すなわち、non＿reference＿picture＿flagは1に等しい）であるとき、pic＿output＿flagは明示的にシグナリングされず、1に等しいと推論される。

【0250】

エンコーダ側では、出力されない非参照ピクチャは、コード化されたビットストリームにコード化されない場合がある。

【0251】

中間システム要素において、non＿reference＿picture＿flagが1に等しく、かつ、pic＿output＿flagが0に等しい、コード化されたピクチャは、コード化されたビットストリームから廃棄され得る。

【0252】

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

【符号の説明】

【0253】

210 デコーダ
320 ビデオデコーダ
360 球面、投影
501 ピクチャヘッダ
502 ARC情報
700 コンピュータシステム
701 キーボード
702 マウス
703 トラックパッド
704 データグローブ
705 ジョイスティック
706 マイク
707 スキャナ
708 カメラ
709 スピーカ
710 タッチスクリーン
721 光学メディア
722 サムドライブ
723 ソリッドステートドライブ
740 コア
741 CPU
743 FPGA
744 ハードウェアアクセラレータ
745 ROM
746 RAM
747 大容量記憶装置
748 システムバス
749 周辺バス

【図1】