特表2022-531093 | 知財ポータル「IP Force」

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

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

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

特表2022-531093ビデオデータをコーディングする方法、コンピュータシステム、及びコンピュータプログラム

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

目に優しい文字サイズ小中大 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)【公報種別】公表特許公報(A)

(11)【公表番号】

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

(54)【発明の名称】ビデオデータをコーディングする方法、コンピュータシステム、及びコンピュータプログラム

(51)【国際特許分類】

H04N 19/70 20140101AFI20220629BHJP

【ＦＩ】

H04N19/70

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021561945

(86)(22)【出願日】2021-03-16

(85)【翻訳文提出日】2021-10-18

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

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

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

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

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

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

(31)【優先権主張番号】17/095,289

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

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎修

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

【氏名】リィウ，シャン

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

5C159

【Ｆターム（参考）】

5C159MA31

5C159ME11

5C159PP13

5C159PP23

5C159RC11

5C159RC24

5C159RC26

5C159UA02

5C159UA05

(57)【要約】

ビデオデータをコーディングする方法、コンピュータプログラム、及びコンピュータシステムが提供される。１つ以上のサブピクチャを含むビデオデータが受け取られる。１つ以上のサブピクチャの夫々に関連したネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプが、１つ以上のサブピクチャにおける混合ＮＡＬユニットに対応するフラグの確認に基づき識別される。ビデオデータは、識別されたＮＡＬユニットタイプに基づきデコードされる。

【特許請求の範囲】

【請求項1】

プロセッサによって実行可能な、ビデオデータをコーディングする方法であって、
１つ以上のサブピクチャを含むビデオデータを受け取るステップと、
前記１つ以上のサブピクチャの夫々に関連したネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプを、前記１つ以上のサブピクチャにおける混合ＮＡＬユニットに対応するフラグの確認に基づいて識別するステップと、
前記ビデオデータを、前記識別されたＮＡＬユニットタイプに基づいてデコードするステップと
を有する方法。

【請求項2】

１に等しいＨａｎｄｌｅＣｒａＡｓＣｖｓＳｔａｒｔＦｌａｇフラグは、現在のピクチャが現在のコーディングされたビデオシーケンスの開始点であることを示す、
請求項１に記載の方法。

【請求項3】

混合ＮＡＬユニットタイプの存在と、クリーンランダムアクセスタイプを有するビデオコーディングレイヤＮＡＬユニットとに基づいて、前記ＨａｎｄｌｅＣｒａＡｓＣｖｓＳｔａｒｔＦｌａｇフラグ及び前記ビデオデータのＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙＦｌａｇフラグは両方とも０に等しくセットされる、
請求項２に記載の方法。

【請求項4】

前記ＨａｎｄｌｅＣｒａＡｓＣｖｓＳｔａｒｔＦｌａｇフラグが０に等しくセットされることに基づいて、現在のサブピクチャは、コーディングされたビデオシーケンスの開始ピクチャとして扱われない、
請求項３に記載の方法。

【請求項5】

混合ＮＡＬユニットタイプの存在と、クリーンランダムアクセスタイプを有するビデオコーディングレイヤＮＡＬユニットとに基づいて、前記ビデオデータに関連した先頭ピクチャが出力される、
請求項２に記載の方法。

【請求項6】

前記ＨａｎｄｌｅＣｒａＡｓＣｖｓＳｔａｒｔＦｌａｇフラグ及び前記ビデオデータのＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙＦｌａｇフラグは両方とも０に等しくセットされる、
請求項５に記載の方法。

【請求項7】

混合ＮＡＬユニットタイプの存在に基づいて、ｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇフラグは１に等しくセットされる、
請求項６に記載の方法。

【請求項8】

ビデオデータをコーディングするコンピュータシステムであって、
コンピュータプログラムコードを記憶するよう構成された１つ以上のコンピュータ可読非一時的記憶媒体と、
前記コンピュータプログラムコードにアクセスするよう構成され、前記コンピュータプログラムコードによって指示されるよう動作する１つ以上のコンピュータプロセッサと
を有し、
前記コンピュータプログラムコードは、前記少なくとも１つ以上のコンピュータプロセッサによって実行される場合に、前記１つ以上のコンピュータプロセッサに、請求項１乃至７のうちいずれか一項に記載の方法を実行させる、
コンピュータシステム。

【請求項9】

ビデオデータをコーディングするコンピュータプログラムであって、
前記コンピュータプログラムは、１つ以上のコンピュータプロセッサによって実行される場合に、前記１つ以上のコンピュータプロセッサに、請求項１乃至７のうちいずれか一項に記載の方法を実行させる、
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願への相互参照］
本願は、米国特許商標庁で、２０２０年３月３１日付けで出願された米国特許仮出願第６３／００３１３７号、及び２０２０年１１月１１日付けで出願された米国特許出願第１７／０９５２８９号の優先権を主張するものであり、これらの出願は、その全文を参照により本願に援用される。

【0002】

［技術分野］
本開示は、概して、データ処理の分野に、より具体的には、ビデオエンコーディング及びデコーディングに関係がある。

【背景技術】

【0003】

動き補償付きのインターピクチャ予測を使用したビデオコーディング及びデコーディンは、数十年にわたって知られている。圧縮されていないデジタルビデオはピクチャの連続から成ることができ、各ピクチャは、例えば、１９２０×１０８０のルミナンスサンプル及び関連するクロミナンスサンプルの空間寸法を有する。ピクチャの連続は、例えば、毎秒６０ピクチャ、つまり６０Ｈｚの固定又は可変のピクチャレート（俗にフレームレートとしても知られている。）を有することができる。圧縮されていないビデオは、有意なビットレート要件を有している。例えば、サンプル当たり８ビットでの１０８０ｐ６０４：２：０ビデオ（６０Ｈｚのフレームレートでの１９２０×１０８０のルミナンスサンプル解像度）は、１．５Ｇｂｉｔ／ｓに近いバンド幅を必要とする。そのようなビデオの１時間は、６００ＧＢｙｔｅ超の記憶空間を必要とする。

【0004】

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

【0005】

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

【0006】

従前、ビデオエンコーダ及びデコーダは、ほとんどの場合に、コーディングされたビデオシーケンス（Coded Video Sequence，ＣＶＳ）、グループ・オブ・ピクチャ（Group of Picture，ＧＯＰ）、又は同様のマルチピクチャタイムフレームについて、定義され一定に保たれた所与のピクチャサイズで動作する傾向があった。例えば、ＭＰＥＧ－２では、システム設計は、シーンの活動などの因子に応じて、しかしＩピクチャでのみ、従って、通常はＧＯＰについて、水平解像度（及び、それによって、ピクチャサイズ）を変えることが知られている。ＣＶＳ内の異なる解像度の使用のための参照ピクチャのリサンプリングは、例えば、ＩＴＵ－ＴＲｅｃ．Ｈ．２６３ＡｎｎｅｘＰから、知られている。しかし、ここでは、ピクチャサイズは変化せず、参照ピクチャのみがリサンプリングされて、結果として、潜在的に、ピクチャキャンバスの部分のみが（ダウンサンプリングの場合に）使用されるか、あるいは、シーンの部分のみが（アップサンプリングの場合に）捕捉されることになる。更に、Ｈ．２６３ＡｎｎｅｘＱは、上向き又は下向きに（各次元で）２倍で個々のマクロブロックのリサンプリングを可能にする。この場合もやはり、ピクチャサイズは同じままである。マクロブロックのサイズは、Ｈ．２６３では固定であるから、シグナリングされる必要がない。

【0007】

予測されたピクチャにおけるピクチャサイズの変化は、現代のビデオコーディングでは、より主流になっている。例えば、ＶＰ９は、参照ピクチャリサンプリング、及びピクチャ全体の解像度の変化を可能にする、同様に、ＶＶＣに向けて行われたある提案（例えば、その全文を本願に援用されるHendry, et. al，“On adaptive resolution change (ARC) for VVC”，Joint Video Team document JVET-M0135-v1，２０１９年１月９～１８日）は、異なる（より高い又はより低い）解像度への参照ピクチャ全体のリサンプリングを可能にする。そのような文献では、異なる候補解像度が、シーケンスパラメータセットでコーディングされて、ピクチャパラメータセットでピクチャごとのシンタックス要素によって参照されることが提案されている。

【発明の概要】

【0008】

実施形態は、ビデオデータをコーディングする方法、システム、及びコンピュータ可読媒体に関する。一態様に従って、ビデオデータをコーディングする方法が提供される。方法は、１つ以上のサブピクチャを含むビデオデータを受け取るステップを含んでよい。１つ以上のサブピクチャの夫々に関連したネットワーク抽象化レイヤ（network abstraction layer，ＮＡＬ）ユニットタイプが、１つ以上のサブピクチャにおける混合ＮＡＬユニットに対応するフラグの確認に基づいて識別される。ビデオデータは、識別されたＮＡＬユニットタイプに基づいてデコードされる。

【0009】

他の態様に従って、ビデオデータをコーディングするコンピュータシステムが提供される。コンピュータシステムは、１つ以上のプロセッサと、１つ以上のコンピュータ読み出し可能なメモリと、１つ以上のコンピュータ読み出し可能な有形記憶デバイスと、１つ以上のメモリの少なくとも１つを介した１つ以上のプロセッサの少なくとも１つによる実行のために１つ以上の記憶デバイスの少なくとも１つに記憶されているプログラム命令とを含んでよく、これによって、コンピュータシステムは方法を実行することができる。方法は、１つ以上のサブピクチャを含むビデオデータを受け取るステップを含んでよい。１つ以上のサブピクチャの夫々に関連したネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプが、１つ以上のサブピクチャにおける混合ＮＡＬユニットに対応するフラグの確認に基づいて識別される。ビデオデータは、識別されたＮＡＬユニットタイプに基づいてデコードされる。

【0010】

更なる他の態様に従って、ビデオデータをコーディングするコンピュータ可読媒体が提供される。コンピュータ可読媒体は、１つ以上のコンピュータ可読記憶デバイスと、１つ以上の有形な記憶デバイスの少なくとも１つに記憶されているプログラム命令とを含んでよく、プログラム命令はプロセッサによって実行される。プログラム命令は、１つ以上のサブピクチャを含むビデオデータを受け取るステップを然るべく含んでもよい方法を実行するようプロセッサによって実行される。１つ以上のサブピクチャの夫々に関連したネットワーク抽象化レイヤ（ＮＡＬ）ユニットタイプが、１つ以上のサブピクチャにおける混合ＮＡＬユニットに対応するフラグの確認に基づいて識別される。ビデオデータは、識別されたＮＡＬユニットタイプに基づいてデコードされる。

【0011】

これら及び他の目的、特徴、及び利点は、添付の図面とともに読まれるべき以下の発明の詳細な説明から明らかになるだろう。図面の様々な特徴は、実寸通りではなく、図は、詳細な説明とともに当業者の理解を促す際に明りょうさを目的とする。

【図面の簡単な説明】

【0012】

【図1】実施形態に従う通信システムの略ブロック図の概略図である。

【図2】実施形態に従う通信システムの略ブロック図の概略図である。

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

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

【図5】指示されるように、先行技術又は実施形態に従ってＡＲＣパラメータをシグナリングするためのオプションの概略図である。

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

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

【図8】適応解像度変更によるスケーラビリティのための予測構造の例である。

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

【図10】アクセスユニットごとのＰＯＣサイクル及びアクセスユニットカウント値のパージング及びデコーディングの略ブロック図の概略図である。

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

【図12】強化された解像度による選択されたサブピクチャの表示の概略図である。

【図13】多層サブピクチャを含むビデオビットストリームのためのデコーディング及び表示プロセスのブロック図である。

【図14】サブピクチャの拡張レイヤによる３６０度ビデオ表示の概略図である。

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

【図16】局所領域の空間スケーラビリティモダリティを伴った、サブピクチャ並びにその対応するレイヤ及びピクチャ予測構造のレイアウト情報の例である。

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

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

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

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

【図21】各出力レイヤセットについて各レイヤの目下のサブピクチャを示すシンタックステーブルの例である。

【図22】サブピクチャ識別子を示すシンタックステーブルの例である。

【図23】サブピクチャパーティショニング情報を示すシンタックステーブルの例である。

【図24】混合ＮＡＬユニットタイプ及び関連するサブピクチャパーティショニング情報を示すシンタックステーブルの例である。

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

【0013】

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

【0014】

上述されたように、ビデオエンコーダ及びデコーダは、ほとんどの場合に、コーディングされたビデオシーケンス（ＣＶＳ）について定義され一定に保たれた所与のピクチャサイズで動作する傾向があった。しかし、ピクチャは１つ以上のサブピクチャにパーティション化され得る。各サブピクチャは、１つ以上のスライスに更にパーティション化され得る。２つ以上の、独立してコーディングされたサブピクチャは、コーディングされたピクチャにマージされ、デコーダによってデコードされ、単一の出力ピクチャとして表示されてもよい。従って、２つ以上の、独立してコーディングされたピクチャがコーディングされたピクチャにマージされる場合に、いくつかのエンコーディング又はデコーディング制約を指定することが有利であり得る。

【0015】

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

【0016】

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

【0017】

図１は、例えば、ビデオ会議中に、現れ得るコーディングされたビデオの双方向伝送をサポートするよう設けられた端末（１３０、１４０）の第２対を表す。データの双方向伝送については、各端末（１３０、１４０）は、ネットワーク（１５０）を介した他の端末への伝送のために、ローカル位置で捕捉されたビデオデータをコーディングしてよい。各端末（１３０、１４０）はまた、他の端末によって送信されたコーディングされたビデオデータを受信してもよく、コーディングされたデータをデコードしてもよく、そして、回復されたビデオデータをローカルの表示デバイスで表示してもよい。

【0018】

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

【0019】

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

【0020】

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

【0021】

図３は、実施形態に従うビデオデコーダ（２１０）の機能ブロック図を表し得る。

【0022】

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

【0023】

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

【0024】

パーサ（３２０）は、シンボル（３２１）を生成するために、バッファ（３１５）から受け取られたビデオシーケンスに対してエントロピデコーディング／パージング動作を実行してもよい。

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

図４は、本開示の実施形態に従うビデオエンコーダ（２０３）の機能ブロック図であってよい。

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

開示されている態様の特定の態様について更に詳細に記載する前に、本明細書の残りで参照されることになる２、３の項目が紹介される。

【0056】

以降、サブピクチャは、いくつかの場合に、意味的にグループ分けされており、変更された解像度で独立してコーディングされ得るサンプル、ブロック、マクロブロック、コーディングユニット、又は同様のエンティティの長方形配置を指す。１つ以上のサブピクチャは、ピクチャを形成してよい。１つ以上のコーディングされたサブピクチャは、コーディングされたピクチャを形成してよい。１つ以上のサブピクチャは、ピクチャにまとめられてもよく、１つ以上のサブピクチャは、ピクチャから抽出されてもよい。特定の環境で、１つ以上のコーディングされたサブピクチャは、同じレベルにトランスコーディングせずに圧縮領域で、コーディングされたピクチャにまとめられてもよく、同じ又は他の場合には、１つ以上のコーディングされたサブピクチャは、圧縮領域で、コーディングされたサブピクチャから抽出されてもよい。

【0057】

以降、適応解像度変更（Adaptive Resolution Change，ＡＲＣ）は、コーディングされたビデオシーケンス内のピクチャ又はサブピクチャの解像度の変化を、例えば、参照ピクチャリサンプリングによって、可能にするメカニズムを指す。ＡＲＣパラメータは、以降、適応解像度変更を実行するために必要な制御情報を指し、例えば、フィルタパラメータ、スケーリング係数、出力及び／又は参照ピクチャの解像度、様々な制御フラグ、などを含んでもよい。

【0058】

上記の説明は、単一の、意味的に独立したコーディングされたビデオピクチャのコーディング及びデコーディングに焦点を当てられている。独立したＡＲＣパラメータによる複数のサブピクチャのコーディング／デコーディングの意味合い及びその暗黙的な更なる複雑性について記載する前に、ＡＲＣパラメータのシグナリングについてのオプションが説明されるべきである。

【0059】

図５を参照すると、ＡＲＣパラメータのシグナリングについてのいくつかの新規のオプションが示されている。オプションの夫々により述べられているように、それらは、コーディング効率、複雑性、及びアーキテクチャ視点から特定の利点及び特定の欠点を有している。ビデオコーディング規格又は技術は、ＡＲＣパラメータのシグナリングのために、これらのオプション、又は先行技術から知られているオプション、のうちの１つ以上を選択してよい。オプションは、相互排他的でなくてよく、考えられる限りは、アプリケーションニーズ、関連する標準技術、又はエンコーダの選択に基づいて交換されてもよい。

【0060】

ＡＲＣパラメータの分類には、次が含まれ得る。

【0061】

・Ｘ及びＹ次元で別々であるか又は結合されているアップサンプル及び／又はダウンサンプル係数

【0062】

・所与の数のピクチャについて一定速度のズームイン／アウトを示す時間次元を追加されたアップサンプル及び／又はダウンサンプル係数

【0063】

上記の２つのうちのどちらも、その係数を含む表を指し示し得る１つ以上の、おそらくは短いシンタックス要素のコーディングを伴ってよい。

【0064】

・組み合わせて又は別々に、入力ピクチャ、出力ピクチャ、参照ピクチャ、コーディングされたピクチャのサンプル、ブロック、マクロブロック、ＣＵ、又は任意の他の適切な粒度の単位での、Ｘ又はＹ次元における解像度。１つよりも多い解像度がある場合に（例えば、入力ピクチャについて１つと参照ピクチャについて１つ）、特定の場合に、ひと組の値が他の組の値から推測されてもよい。解像度は、例えば、フラグの使用によって、ゲーティング（gated）されてもよい。より詳細な例については、以下を参照されたい。

【0065】

・Ｈ．２６３ＡｎｎｅｘＰで使用されるものと同種であって、先と同じく、上述された適切な粒度にある「ワーピング」（Warping）座標。Ｈ．２６３ＡｎｎｅｘＰは、そのようなワーピング座標をコーディングするための１つの効率的な方法を定義するが、他の、潜在的により効率的な方法も、考えられる限りは、考案されてよい。例えば、ＡｎｎｅｘＰのワーピング座標の可変長リバーシブルな「ハフマン」スタイルコーディングは、適切な長さのバイナリコーディングで置換されてもよく、このとき、バイナリコードワードの長さは、例えば、最大ピクチャサイズから導出されて、場合により、最大ピクチャサイズの境界の外での「ワーピング」を可能にするために、特定の係数を乗じられかつ特定の値でオフセットされてもよい。

【0066】

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

【0067】

以降、説明は、コードワードにより示される有限なアップサンプル及び／又はダウンサンプル係数の組（同じ係数がＸ及びＹの両方の次元で使用される。）のコーディングを前提とする。そのコードワードは、有利なことに、例えば、Ｈ．２６４及びＨ．２６５などのビデオコーディング規格で特定のシンタックス要素に共通なＥｘｔ－Ｇｏｌｏｍｂコードを使用することによって、可変長コーディングされてよい。アップサンプル及び／又はダウンサンプル係数への値の１つの適切なマッピングは、例えば、以下の表に従うことができる。

【表1】

【0068】

多くの類似したマッピングが、ビデオ圧縮技術又は規格で利用可能なアップ及びダウンスケールメカニズムの適用のニーズ及び能力に従って考案され得た。表は、より多くの値に拡張されてもよい。値はまた、Ｅｘｔ－Ｇｏｌｏｍｂコード以外のエントロピコーディングメカニズムによって、例えば、バイナリコーディングを用いて、表されてもよい。それは、リサンプリング係数が、例えば、ＭＡＮＥによって、ビデオ処理エンジン（第１に、エンコーダ及びデコーダ）自体の外で重要である場合に、特定の利点を有し得る。解像度変更が不要である（推定上）最も一般的な場合については、短い（例えば、上記の表では、単一ビットのみ）Ｅｘｔ－Ｇｏｌｏｍｂコードが選択可能であることが留意されるべきである。それは、最も一般的な場合のためにバイナリコードを使用することよりもコーディング効率が優れている可能性がある。

【0069】

表中のエントリの数及びそれらのセマンティクスは、完全に又は部分的に設定可能であってよい。例えば、表の基本概要は、シーケンス又はデコーダパラメータセットなどの「ハイ」パラメータセットで運ばれてよい。代替的に、又は追加的に、１つ以上のそのような表は、ビデオコーディング技術又は規格で定義されてもよく、例えば、デコーダ又はシーケンスパラメータセットにより選択されてもよい。

【0070】

以下では、上述されたようにコーディングされているアップサンプル及び／又はダウンサンプル係数（ＡＲＣ情報）がビデオコーディング技術又は標準シンタックスにどのように含まれ得るかが記載される。同様の考えは、アップサンプル及び／又はダウンサンプルフィルタを制御する１つ又は数個のコードワードに当てはまる。比較的大量のデータがフィルタ又は他のデータ構造のために必要とされ得る場合に関する説明については以下を参照されたい。

【0071】

Ｈ．２６３ＡｎｎｅｘＰは、４つのワーピング座標の形でＡＲＣ情報（５０２）をピクチャヘッダ（５０１）内に、具体的には、Ｈ．２６３ＰＬＵＳＰＴＹＰＥ（５０３）ヘッダ拡張に含める。これは、（ａ）利用可能なピクチャヘッダが有り、かつ、（ｂ）ＡＲＣ情報の頻繁な変化が期待される、場合に、理にかなった設計選択であることができる。しかし、Ｈ．２６３スタイルシグナリングを使用する場合のオーバーヘッドは極めて高くなる可能性があり、スケーリング係数は、ピクチャヘッダが過渡的な性質を有し得るので、ピクチャ境界に付随しないことがある。

【0072】

上記のＪＶＣＥＴ－Ｍ１３５－ｖ１は、シーケンスパラメータセット（５０７）の中に位置している目標解像度を含む表（５０６）をインデックス化する、ピクチャパラメータセット（５０４）に位置しているＡＲＣ参照情報（５０５）（インデックス）を含む。シーケンスパラメータセット（５０７）における表（５０６）でのとり得る解像度の配置は、著者による口頭の声明によれば、能力交換（capability exchange）中に相互運用ネゴシエーションポイント（interoperability negotiation point）としてＳＰＳ（５０７）を使用することによって正当化され得る。解像度は、適切なピクチャパラメータセット（５０４）を参照することによってピクチャごとに表（５０６）の値によってセットされた限界内で変化することができる。

【0073】

依然として図５を参照すると、次の追加オプションは、ＡＲＣ情報をビデオビットストリームで運ぶために存在してよい。これらのオプションの夫々は、上記の既存技術に対して特定の利点を有する。オプションは、同時に、同じビデオコーディング技術又は規格において存在してもよい。

【0074】

実施形態において、リサンプリング（ズーム）係数などのＡＲＣ情報（５０９）は、スライスヘッダ、ＧＯＢヘッダ、タイルヘッダ、又はタイルグループヘッダ（以降、タイルグループヘッダ）（５０８）に存在してよい。これは、例えば、上述されたような、数ビットの単一の可変長ｕｅ（ｖ）又は固定長コードワードのように、ＡＲＣ情報が小さい場合に、適切であることができる。タイルグループヘッダで直接にＡＲＣ情報を有することは、ＡＲＣ情報が、例えば、ピクチャ全体ではなく、そのタイルグループによって表されるサブピクチャに適用可能であり得るという付加的な利点を有している。以下も参照されたい。更には、たとえビデオ圧縮技術又は規格が（例えば、タイルグループに基づいた適応的な解像度変化とは対照的に）ピクチャ全体にのみ適応可能な解像度変化を企図するとしても、ＡＲＣ情報をタイルグループヘッダに、それをＨ２６３スタイルのピクチャヘッダに置くことにより置くことは、誤り耐性の観点から特定の利点を有する。

【0075】

同じ又は他の実施形態において、ＡＲＣ情報（５１２）自体が、例えば、ピクチャパラメータセット、ヘッダパラメータセット、タイルパラメータセット、適応パラメータセット、などのような適切なパラメータセット（５１１）（表されているのは、適応パラメータセット）に存在してもよい。そのパラメータセットの範囲は、有利なことに、ピクチャよりも大きくならず、例えば、タイルグループであることができる。ＡＲＣ情報の使用は、関連するパラメータセットの活性化を通じて潜在してもよい。例えば、ビデオコーディング技術又は規格がピクチャベースのＡＲＣのみを企図する場合に、ピクチャパラメータセット又は同等物が適切であり得る。

【0076】

同じ又は他の実施形態において、ＡＲＣ参照情報（５１３）は、タイルグループヘッダ（５１４）又は類似したデータ構造に存在してもよい。その参照情報（５１３）は、単一のピクチャを越える範囲でパラメータセット（５１６）において利用可能なＡＲＣ情報（５１５）のサブセット、例えば、シーケンスパラメータセット又はデコーダパラメータセットを参照することができる。

【0077】

ＪＶＥＴ－Ｍ０１３５－ｖ１で使用されるタイルグループヘッダ、ＰＰＳ、ＳＰＳからのＰＰＳの追加レベルの間接的な暗黙的活性は、シーケンスパラメータセットと同様に、ピクチャパラメータセットが能力ネゴシエーション又はアナウンスのために使用され得る（ＲＦＣ３９８４などの特定の標準規格では使用されている）ということで、不必要であるように見える。しかし、ＡＲＣ情報が、例えば、タイルグループによっても表されるサブピクチャに適用可能であるべき場合には、適応パラメータセット又はヘッダパラメータセットなどの、タイルグループに限定された活性化範囲を有するパラメータセットは、より良い選択であり得る。また、ＡＲＣ情報が無視できるサイズよりも大きく、例えば、多数のフィルタ係数などのフィルタ制御情報を含む場合には、パラメータは、そのような設定が同じパラメータセットを参照することによって将来のピクチャ又はサブピクチャによって再利用され得るということで、コーディング効率の観点から、直接にヘッダ（５０８）を使用することによりも良い選択であり得る。

【0078】

複数のピクチャに及ぶ範囲でシーケンスパラメータセット又は他のより高いパラメータセットを使用する場合に、特定の考慮事項が適用され得る。

【0079】

１．ＡＲＣ情報テーブル（５１６）を保持するパラメータセットは、いくつかの場合に、シーケンスパラメータセットであることができるが、他の場合には、有利なことに、デコーダパラメータセットであることができる。デコーダパラメータセットは、複数のＣＶＳ（つまり、コーディングされたビデオストリーム）の活性化範囲、すなわち、セッション開始からセッション破棄までの全てのコーディングされたビデオビットを有することができる。そのような範囲は、起こり得るＡＲＣ因子は、場合によりハードウェアで実装されるデコーダ機構である可能性があり、ハードウェア機構は、如何なるＣＶＳ（少なくともいくつかのエンターテイメントシステムでは、１秒以下のグループ・オブ・ピクチャである）によっても変化しない傾向があるため、より適切であり得る。とは言うものの、シーケンスパラメータにテーブルを置くことは、特に以下の２．に関連して、本明細書で記載される配置オプションに明示的に含まれる。

【0080】

２．ＡＲＣ参照情報（５１３）は、有利なことに、ＪＶＣＥＴ－Ｍ０１３５－ｖ１で見られるようにピクチャパラメータセットにではなく、ピクチャ／スライスタイル／ＧＯＢ／タイルグループヘッダ（以降、タイルグループヘッダ）（５１４）に直接に置かれてもよい。その理由は次の通りである・エンコーダがピクチャパラメータセット内の単一の値、例えば、ＡＲＣ参照情報を変更したい場合に、それは、新しいＰＰＳを生成し、その新しいＰＰＳを参照すべきである。ＡＲＣ参照情報のみが変化し、他の情報、例えば、ＰＰＳ内の量子化マトリクス情報はそのままである、とする。そのような情報は、かなりのサイズになる可能性があり、新しいＰＰＳを完成させるには再送される必要がある。ＡＲＣ参照情報は、テーブルへのインデックス（５１３）などの、変更される唯一の値である単一のコードワードであり得るから、全ての、例えば、量子化マトリクス情報を再送することは、面倒かつ無駄である。これまでのところ、ＪＶＥＴ－Ｍ０１３５－ｖ１で提案されているように、ＰＰＳを通じた間接参照を回避することは、コーディング効率の観点から、かなり優れている可能性がある。同様に、ＡＲＣ参照情報をＰＰＳに置くことには、ピクチャパラメータセットの活性化の範囲がピクチャであるということで、ＡＲＣ参照情報（５１３）によって参照されるＡＲＣ情報がサブピクチャにではなく不必要にピクチャ全体に適用される必要があるという更なる欠点がある。

【0081】

同じ又は他の実施形態において、ＡＲＣパラメータのシグナリングは、図６で説明されている詳細な例に従うことができる。図６は、少なくとも１９９３年以降にビデオコーディング標準規格で使用された表現でシンタックスダイアグラムを表す。そのようなシンタックスダイアグラムの表記法は、Ｃ言語プログラミングに大体従う。太字体の行は、ビットストリームに存在するシンタックス要素を示し、太字体でない行は、しばしば、制御フロー又は変数の設定を示す。

【0082】

ピクチャの（場合により長方形の）部分に適用可能なヘッダの例となるシンタックス構造としてのタイルグループヘッダ（６０１）は、可変長のＥｘｐ－Ｇｏｌｏｍｂコーディングされたシンタックス要素ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ（６０２）（太字で表示）を条件付きで含むことができる。タイルグループヘッダにおけるこのシンタックス要素の存在は、適応解像度（６０３）の使用時にゲーティングされ得る。ここで、フラグの値は太字で表されておらず、これは、フラグが、シンタックスダイアグラムで発生する時点でビットストリームに存在することを意味する。適応解像度がこのピクチャ又はその部分に対して使用中であるか否かは、ビットストリーム内又は外の如何なる高位シンタックス構造でもシグナリングされ得る。示されている例では、適応解像度は、以下で説明されるようにシーケンスパラメータセットでシグナリングされる。

【0083】

依然として図６を参照すると、シーケンスパラメータセット（６１０）の抜粋も示されている。示されている最初のシンタックス要素は、ａｄａｐｔｉｖｅ＿ｐｉｃ＿ｒｅｓｏｌｕｔｉｏｎ＿ｃｈａｎｇｅ＿ｆｌａｇ（６１１）である。真である場合に、そのフラグは、適応解像度の使用を示すことができ、翻って、特定の制御情報を必要とし得る。例において、そのような制御情報は、パラメータセット（６１２）及びタイルグループヘッダ（６００）においてｉｆ（）文に基づくフラグの値に基づいて条件付きで存在する。

【0084】

適応解像度が使用中である場合に、この例では、サンプル（６１３）のユニットで出力解像度がコーディングされる。数６１３は、ｏｕｔｐｕｔ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ及びｏｕｔｐｕｔ＿ｐｉｃ＿ｈｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの両方を参照する。これらは一緒に、出力ピクチャの解像度を定義することができる。ビデオコーディング技術又は規格の他の場所で、どちらかの値に対する特定の制限が定義され得る。例えば、レベル定義は、それら２つのシンタックス要素の値の積であることができる総出力サンプル数を制限してよい。また、特定のビデオコーディング技術又は規格、あるいは、例えば、システム規格などの外部技術又は規格は、番号付け範囲（例えば、一方又は両方の次元が２の累乗で割り切れるべきである）、又はアスペクト比（例えば、幅及び高さは４：３又は１６：９などの関係になければならない）を制限してもよい。そのような制限は、ハードウェア実装を容易にするために、又は他の理由のために、導入されてもよく、当該技術でよく知られている。

【0085】

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

【0086】

最後に、とり得るデコーディングピクチャ幅及び高さの表が示されている。そのような表は、例えば、表指示（ｎｕｍ＿ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＿ｍｉｎｕｓ１）（６１６）によって、表現され得る。「ｍｉｎｕｓ１」は、そのシンタックス要素の値の解釈（interpretation）を指すことができる。例えば、シンタックス要素のコーディングされた値が０である場合に、１つの表エントリが存在する。コーディングされた値が５である場合に、６つの表エントリが存在する。表の各“行”ごとに、デコードされたピクチャ幅及び高さが、次いで、シンタックス（６１７）に含まれる。

【0087】

表されている表エントリ（６１７）は、タイルグループヘッダにおけるシンタックス要素ｄｅｃ＿ｐｉｃ＿ｓｉｚｅ＿ｉｄｘ（６０２）を用いてインデックスを付され得る。それによって、タイルグループごとに異なったデコーディングサイズ、実際にはズーム係数が可能となる。

【0088】

特定のビデオコーディング技術又は規格、例えば、ＶＰ９は、空間スケーラビリティを可能にするために、時間スケーラビリティとともに特定の形態の参照ピクチャリサンプリング（開示されている対象とは全く別なふうにシグナリングされる）を実装することによって空間スケーラビリティをサポートする。特に、特定の参照ピクチャは、空間拡張レイヤのベースを形成するよう、ＡＲＣスタイル技術を用いて、より高い解像度へアップサンプリングされてもよい。それらのアップサンプリングされたピクチャは、詳細を追加するために、高い解像度で通常の予測メカニズムを使用して精緻化され得る。

【0089】

開示されている対象は、そのような環境で使用され得る。特定の場合に、同じ又は他の実施形態において、ＮＡＬユニットヘッダ、例えば、一時ＩＤ（Temporal ID）フィールドにおける値は、時間レイヤのみならず空間レイヤも示すために使用され得る。そうすることには、特定のシステム設計にとって特定の利点がある。例えば、ＮＡＬユニットヘッダの一時ＩＤ値に基づいて時間レイヤ選択的転送のために生成及び最適化された既存の選択的転送ユニット（Selected Forwarding Units，ＳＦＵ）は、スケーラブル環境のために変更無しで使用可能である。それを可能にするために、コーディングされたピクチャと時間レイヤとの間のマッピングがＮＡＬユニットヘッダにおいて一時ＩＤフィールドによって示される必要がある。

【0090】

いくつかのビデオコーディング技術で、アクセスユニット（Access Unit，ＡＵ）は、所与の時点で捕捉されて各々のピクチャ／スライス／タイル／ＮＡＬユニットビットストリーム内に構成されたコーディングされたピクチャ、スライス、タイル、ＮＡＬユニットなどを指すことができる。そのような時点は、合成時間（composition time）であることができる。

【0091】

ＨＥＶＣ、及び特定の他のビデオコーディング技術では、ピクチャ・オーダー・カウント（Picture Order Count，ＰＯＣ）値が、デコーディングピクチャバッファ（Decoded Picture Buffer，ＤＰＢ）に格納された複数の参照ピクチャの中から選択された参照ピクチャを示すために使用され得る。アクセスユニット（ＡＵ）が１つ以上のピクチャ、スライス、又はタイルを含む場合に、同じＡＵに属する各ピクチャ、スライス、又はタイルは、同じＰＯＣ値を運んでよく、ＰＯＣ値から、それらが同じ合成時間のコンテンツから生成されたことが導出され得る。すなわち、２つのピクチャ／スライス／タイルが同じ所与のＰＯＣ値を運ぶシナリオにおいて、その２つのピクチャ／スライス／タイルは同じＡＵに属しかつ同じ合成時間を有していることが決定され得る。対照的に、異なるＰＯＣ値を有する２つのピクチャ／タイル／スライスは、それらのピクチャ／スライス／タイルが異なるＡＵに属しかつ異なる合成時間を有していることを示すことができる。

【0092】

開示されている対象の実施形態において、上記の堅固な関係は、アクセスユニットが異なるＰＯＣ値を有するピクチャ、スライス、又はタイルを含むことができる点で緩和され得る。ＡＵ内の異なるＰＯＣ値を許すことによって、ＰＯＣ値を使用して、同じ提示時間（presentation time）を有する潜在的に独立してデコード可能なピクチャ／スライス／タイルを識別することが可能になる。それは、翻って、以下で更に詳細に記載されるように、参照ピクチャ選択シグナリング（例えば、参照ピクチャセットシグナリング又は参照ピクチャリストシグナリング）の変化無しで、複数のスケーラブルレイヤのサポートを可能にすることができる。

【0093】

しかし、ＰＯＣ値のみから、異なるＰＯＣ値を有する他のピクチャ／スライス／タイルに対して、ピクチャ／スライス／タイルが属するＡＵを識別することができることが、依然として望ましい。これは、以下で記載されるように、達成され得る。

【0094】

同じ又は他の実施形態において、アクセスユニットカウント（Access Unit Count，ＡＵＣ）は、ＮＡＬユニットヘッダ、スライスヘッダ、タイルグループヘッダ、ＳＥＩメッセージ、パラメータセット又はＡＵデリミタ（delimiter）などの高位シンタックス構造でシグナリングされてよい。ＡＵＣの値は、どのＮＡＬユニット、ピクチャ、スライス、又はタイルが所与のＡＵに属するかを識別するために使用されてよい。ＡＵＣの値は、個別の合成時間インスタンスに対応していてよい。ＡＵＣ値は、ＰＯＣ値の倍数に等しくなる。整数値でＰＯＣ値を割ることによって、ＡＵＣ値は計算され得る。特定の場合に、割り算は、デコーダ実装に一定の負担をかける可能性がある。そのような場合に、ＡＵＣ値の番号付け空間における小さな制限は、シフト演算による割り算の置換を可能にし得る。例えば、ＡＵＣ値は、ＰＯＣ値範囲の最上位ビット（ＭＳＢ）値に等しくなる。

【0095】

同じ実施形態において、ＡＵごとのＰＯＣサイクル（ｐｏｃ＿ｃｙｃｌｅ＿ａｕ）の値は、ＮＡＬユニットヘッダ、スライスヘッダ、タイルグループヘッダ、ＳＥＩメッセージ、パラメータセット又はＡＵデリミタなどの高位シンタックス構造でシグナリングされてよい。ｐｏｃ＿ｃｙｃｌｅ＿ａｕは、多数の異なる連続したＰＯＣ値が同じＡＵとどのように関連付けられ得るかを示してよい。例えば、ｐｏｃ＿ｃｙｃｌｅ＿ａｕの値が４に等しい場合に、０以上３以下に等しいＰＯＣ値を有するピクチャ、スライス、又はタイルは、０に等しいＡＵＣ値を有するＡＵと関連付けられ、４以上７以下に等しいＰＯＣ値を有するピクチャ、スライス、又はタイルは、１に等しいＡＵＣ値を有するＡＵと関連付けられる。従って、ＡＵＣの値は、ｐｏｃ＿ｃｙｃｌｅ＿ａｕでＰＯＣ値を割ることによって推測され得る。

【0096】

同じ又は他の実施形態において、ｐｏｃ＿ｃｙｃｌｅ＿ａｕの値は、コーディングされたビデオシーケンスにおける空間又はＳＮＲレイヤの数を識別する、例えば、ビデオパラメータセット（ＶＰＳ）に位置している情報から、導出されてもよい。そのような可能な関係は、以下で簡単に説明される。上述された導出はＶＰＳで数ビットを節約し得るので、コーディング効率を改善し得る一方で、ピクチャなどのビットストリームの所与の小さな部分についてｐｏｃ＿ｃｙｃｌｅ＿ａｕを最小化することが可能であるために、ｐｏｃ＿ｃｙｃｌｅ＿ａｕを、階層的にビデオパラメータセットの下にある適切な高位シンタックス構造で明示的にコーディングすることが有利であり得る。この最適化は、ＰＯＣ値（及び／又はＰＯＣを間接的に参照するシンタックス要素の値）が低位シンタックス構造でコーディングされ得るので、上記の導出プロセスを通じてセーブ可能であるよりも多いビットをセーブし得る。

【0097】

上記の、適応分解能パラメータをシグナリングする技術は、コンピュータ読み出し可能な命令を使用しかつ１つ以上のコンピュータ可読媒体に物理的に記憶されているコンピュータソフトウェアとして実装可能である。例えば、図７は、開示されている対象の特定の実施形態を実装することに適したコンピュータシステム７００を示す。

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

図８は、適応解像度変更とのｔｅｍｐｏｒａｌ＿ｉｄ、ｌａｙｅｒ＿ｉｄ、並びにＰＯＣ及びＡＵＣ値の組み合わせによるビデオシーケンス構造の例を示す。この例では、ＡＵＣ＝０を有する最初のＡＵ内のピクチャ、スライス、又はタイルは、ｔｅｍｐｏｒａｌ＿ｉｄ＝０及びｌａｙｅｒ＿ｉｄ＝０又は１を有してよく、一方、ＡＵＣ＝１を有する第２のＡＵ内のピクチャ、スライス、又はタイルは、ｔｅｍｐｏｒａｌ＿ｉｄ＝１及びｌａｙｅｒ＿ｉｄ＝０又は１を夫々有してよい。ＰＯＣの値は、ｔｅｍｐｏｒａｌ＿ｉｄ及びｌａｙｅｒ＿ｉｄの値にかかわらずピクチャごとに１ずつ増える。この例では、ｐｏｃ＿ｃｙｃｌｅ＿ａｕの値は２に等しくなる。望ましくは、ｐｏｃ＿ｃｙｃｌｅ＿ａｕの値は、（空間スケーラビリティ）レイヤの数に等しくセットされてよい。この例では、従って、ＰＯＣの値は２ずつ増え、一方、ＡＵＣの値は１ずつ増える。

【0113】

上記の実施形態で、インターピクチャ又はインターレイヤ予測構造及び参照ピクチャ指示の全て又はサブセットは、ＨＥＶＣでの既存の参照ピクチャセット（ＲＰＳ）シグナリング又は参照ピクチャリスト（ＲＰＬ）シグナリングを使用することによってサポートされてよい。ＲＰＳ又はＲＰＬで、選択された参照ピクチャは、ＰＯＣの値、又は現在のピクチャと選択された参照ピクチャとの間のＰＯＣの差分値をシグナリングすることによって、示され得る。開示されている対象については、ＲＰＳ又はＲＰＬは、シグナリングの変化無しで、しかし、次の制限を有して、インターピクチャ又はインターレイヤ予測構造を示すために使用され得る。参照ピクチャのｔｅｍｐｏｒａｌ＿ｉｄの値が現在のピクチャのｔｅｍｐｏｒａｌ＿ｉｄの値よりも大きい場合に、現在のピクチャは、動き補償又は他の予測のために参照ピクチャを使用しなくもよい。参照ピクチャのｌａｙｅｒ＿ｉｄの値が現在のピクチャのｌａｙｅｒ＿ｉｄの値よりも大きい場合に、現在のピクチャは、動き補償又は他の予測のために参照ピクチャを使用しなくてもよい。

【0114】

同じ又は他の実施形態において、時間動きベクトル予測のためのＰＯＣ差分に基づいた動きベクトルスケーリングは、アクセスユニット内の複数のピクチャにわたって無効にされてもよい。従って、各ピクチャがアクセスユニット内で異なるＰＯＣ値を有し得るとしても、動きベクトルは、アクセスユニット内の時間動きベクトル予測のためにスケーリング及び使用されない。これは、同じＡＵで異なるＰＯＣを有する参照ピクチャが同じ時間インスタンスを有する参照ピクチャと見なされるからである。従って、実施形態において、動きベクトルスケーリング関数は、参照ピクチャが現在のピクチャに関連したＡＵに属する場合に１を返してよい。

【0115】

同じ又は他の実施形態において、時間動きベクトル予測のためのＰＯＣ差分に基づいた動きベクトルスケーリングは、参照ピクチャの空間分解能が現在のピクチャの空間分解能とは異なる場合に、任意に、複数のピクチャにわたって任意に無効化されてもよい。動きベクトルスケーリングが許可される場合に、動きベクトルは、現在のピクチャと参照ピクチャとの間のＰＯＣ差分及び空間分解能比の両方に基づいてスケーリングされる。

【0116】

同じ又は他の実施形態において、動きベクトルは、特に、ｐｏｃ＿ｃｙｃｌｅ＿ａｕが非一様値を有する場合に（ｖｐｓ＿ｃｏｎｔａｎｔ＿ｐｏｃ＿ｃｙｃｌｅ＿ｐｅｒ＿ａｕ＝＝０である場合に）、時間動きベクトル予測のために、ＰＯＣ差分の代わりにＡＵＣ差分に基づいて、スケーリングされてもよい。そうでない場合（ｖｐｓ＿ｃｏｎｔａｎｔ＿ｐｏｃ＿ｃｙｃｌｅ＿ｐｅｒ＿ａｕ＝＝１である場合）には、ＡＵＣ差分に基づいた動きベクトルスケーリングは、ＰＯＣ差分に基づいた動きベクトルスケーリングと同じであってよい。

【0117】

同じ又は他の実施形態において、動きベクトルがＡＵＣ差分に基づいてスケーリングされる場合に、現在のピクチャを含む同じＡＵ内の（同じＡＵＣ値を有する）参照動きベクトルは、ＡＵＣ差分に基づいてスケーリングされず、現在のピクチャと参照ピクチャとの間の空間分解能比に基づいたスケーリングを有して又はスケーリング無しで動きベクトル予測のために使用される。

【0118】

同じ又は他の実施形態において、ＡＵＣ値は、ＡＵの境界を識別するために使用され、かつ、ＡＵ粒度での入力及び出力タイミングを必要とする仮想リファレンスデコーダ（hypothetical reference decoder，ＨＲＤ）動作のために使用される。ほとんどの場合に、ＡＵの最上位レイヤを有するデコードされたピクチャは、表示のために出力されてよい。ＡＵＣ値及びｌａｙｅｒ＿ｉｄ値は、出力ピクチャを識別するために使用され得る。

【0119】

実施形態において、ピクチャは、１つ以上のサブピクチャから成ってもよい。各サブピクチャは、ピクチャの局所領域又は全体領域をカバーしてよい。サブピクチャによってサポートされる領域は、他のサブピクチャによってサポートされる領域と重なり合っても重なり合わなくてもよい。１つ以上のサブピクチャによって構成されている領域は、ピクチャの全体領域をカバーしてもしなくてもよい。ピクチャがサブピクチャから成る場合に、そのサブピクチャによってサポートされる領域は、ピクチャによってサポートされる領域と同じである。

【0120】

同じ実施形態において、サブピクチャは、コーディングされたピクチャのために使用されているコーディング方法と類似したコーディング方法によってコーディングされてもよい。サブピクチャは、独立してコーディングされてもよく、あるいは、他のサブピクチャ又はコーディングされたピクチャに依存してコーディングされてもよい。サブピクチャは、他のサブピクチャ又はコーディングされたピクチャからの如何なるパージング依存性も有しても有さなくてもよい。

【0121】

同じ実施形態において、コーディングされたサブピクチャは、１つ以上のレイヤに含まれてもよい。レイヤ内のコーディングされたサブピクチャは、異なる空間分解能を有してもよい。元のサブピクチャは、空間的にリサンプリング（アップサンプリング又はダウンサンプリング）され、異なる空間分解能パラメータでコーディングされ、レイヤに対応するビットストリームに含まれてよい。

【0122】

同じ又は他の実施形態において、Ｗがサブピクチャの幅を示し、Ｈがサブピクチャの高さを示すとして、（Ｗ，Ｈ）を有するサブピクチャは、コーディングされて、レイヤ０に対応するコーディングされたビットストリームに含まれてよく、一方、元の空間分解能を有するサブピクチャからアップサンプリング（又はダウンサンプリングされた）、（Ｗ×Ｓ_ｗ，ｋ，Ｈ×Ｓ_ｈ，ｋ）を有するサブピクチャは、コーディングされ、レイヤｋに対応するコーディングされたビットストリームに含まれてよい。ここで、Ｓ_ｗ，ｋ、Ｓ_ｈ，ｋは、夫々、水平方向及び垂直方向でのリサンプリング比を示す。Ｓ_ｗ，ｋ、Ｓ_ｈ，ｋの値が１よりも大きい場合に、リサンプリングはアップサンプリングに等しい。一方、Ｓ_ｗ，ｋ、Ｓ_ｈ，ｋの値が１よりも小さい場合には、リサンプリングはダウンサンプリングに等しい。

【0123】

同じ又は他の実施形態において、レイヤ内のコーディングされたサブピクチャは、同じサブピクチャ又は異なるサブピクチャにおける他のレイヤ内のコーディングされたサブピクチャのそれとは異なった視覚品質を有してもよい。例えば、レイヤｎ内のサブピクチャｉは、量子化パラメータＱ_ｉ，ｎでコーディングされ、一方、レイヤｍ内のサブピクチャｊは、量子化パラメータＱ_ｊ，ｍでコーディングされる。

【0124】

同じ又は他の実施形態において、レイヤ内のコーディングされたサブピクチャは、同じ局所領域の他のレイヤ内のコーディングされたサブピクチャからの如何なるパージング又はデコーディング依存性もなしで、独立してデコード可能であってよい。同じ局所領域の他のサブピクチャレイヤを参照せずに独立してデコード可能であることができるサブピクチャレイヤは、独立サブピクチャレイヤ（independent sub-picture layer）である。独立サブピクチャレイヤ内のコーディングされたサブピクチャは、同じサブピクチャレイヤ内の前にコーディングされたサブピクチャからのデコーディング又はパージング依存性を有しても有さなくてもよいが、コーディングされたサブピクチャは、他のサブピクチャレイヤ内のコーディングされたサブピクチャからの如何なる依存性も有さなくてよい。

【0125】

同じ又は他の実施形態において、レイヤ内のコーディングされたサブピクチャは、同じ局所領域の他のレイヤ内のコーディングされたサブピクチャからの何らかのパージング又はデコーディング依存性を有して、従属的にデコード可能であってもよい。同じ局所領域の他のサブピクチャレイヤを参照して従属的にデコード可能であることができるサブピクチャレイヤは、従属サブピクチャレイヤ（dependent sub-picture layer）である。従属サブピクチャレイヤ内のコーディングされたサブピクチャは、同じサブピクチャに属するコーディングされたサブピクチャ、同じサブピクチャレイヤ内の前にコーディングされたサブピクチャ、又は両方の参照サブピクチャを参照してよい。

【0126】

同じ又は他の実施形態において、コーディングされたサブピクチャは、１つ以上の独立サブピクチャレイヤと、１つ以上の従属サブピクチャレイヤとから成る。しかし、少なくとも１つの独立サブピクチャレイヤが、コーディングされたサブピクチャのために存在してもよい。独立サブピクチャレイヤの、ＮＡＬユニットヘッダ又は他の高位シンタックス構造に存在し得るレイヤ識別子（ｌａｙｅｒ＿ｉｄ）の値は、０に等しくなる。０に等しいｌａｙｅｒ＿ｉｄを有するサブピクチャレイヤは、基本サブピクチャレイヤであってよい。

【0127】

同じ又は他の実施形態において、ピクチャは、１つ以上の前景サブピクチャと、１つの背景サブピクチャとから成ってもよい。背景サブピクチャによってサポートされる領域は、ピクチャの領域に等しくてよい。前景サブピクチャによってサポートされる領域は、背景サブピクチャによってサポートされる領域と重なり合ってもよい。背景サブピクチャは、基本サブピクチャレイヤであってよく、一方、前景サブピクチャは、非基本（拡張）サブピクチャレイヤであってよい。１つ以上の非基本サブピクチャレイヤは、デコーディングのために同じ基本レイヤを参照してよい。ａがｂよりも大きいとして、ａに等しいｌａｙｅｒ＿ｉｄを有する各非基本サブピクチャレイヤは、ｂに等しいｌａｙｅｒ＿ｉｄを有する非基本サブピクチャレイヤを参照してもよい。

【0128】

同じ又は他の実施形態において、ピクチャは、背景サブピクチャの有無によらず１つ以上の前景サブピクチャから成ってもよい。各サブピクチャは、それ自身の基本サブピクチャレイヤと、１つ以上の非基本（拡張）レイヤとを有してよい。各基本サブピクチャレイヤは、１つ以上の非基本サブピクチャレイヤによって参照されてよい。ａがｂよりも大きいとして、ａに等しいｌａｙｅｒ＿ｉｄを有する各非基本サブピクチャレイヤは、ｂに等しいｌａｙｅｒ＿ｉｄを有する非基本サブピクチャレイヤを参照してよい。

【0129】

同じ又は他の実施形態において、ピクチャは、背景サブピクチャの有無によらず１つ以上の前景サブピクチャから成ってもよい。（基本又は非基本）サブピクチャレイヤ内の各コーディングされたサブピクチャは、同じサブピクチャに属する１つ以上の非基本レイヤサブピクチャと、同じサブピクチャに属していない１つ以上の非基本レイヤサブピクチャとによって参照されてよい。

【0130】

同じ又は他の実施形態において、ピクチャは、背景サブピクチャの有無によらず１つ以上の前景サブピクチャから成ってもよい。レイヤａ内のサブピクチャは、同じレイヤ内の複数のサブピクチャに更にパーティション化されてよい。レイヤｂ内の１つ以上のコーディングされたサブピクチャは、レイヤａ内のパーティション化されたサブピクチャを参照してよい。

【0131】

同じ又は他の実施形態において、コーディングされたビデオシーケンス（ＣＶＳ）は、コーディングされたピクチャのグループであってよい。ＣＶＳは、１つ以上のコーディングされたサブピクチャシーケンス（ＣＳＰＳ）から成ってもよく、ＣＳＰＳは、ピクチャの同じ局所領域をカバーするコーディングされたサブピクチャのグループであってよい。ＣＳＰＳは、コーディングされたビデオシーケンスのそれと同じ又は異なった時間分解能を有してよい。

【0132】

同じ又は他の実施形態において、ＣＳＰＳは、コーディングされて、１つ以上のレイヤに含まれてもよい。ＣＳＰＳは、１つ以上のＣＳＰＳレイヤから成ってもよい。ＣＳＰＳに対応する１つ以上のＣＳＰＳレイヤをデコードすることは、同じ局所領域に対応するサブピクチャのシーケンスを再構成し得る。

【0133】

同じ又は他の実施形態において、ＣＳＰＳに対応するＣＳＰＳレイヤの数は、他のＣＳＰＳに対応するＣＳＰＳレイヤの数と同じであっても又は異なってもよい。

【0134】

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

【0135】

同じ又は他の実施形態において、フレームレートＦを有するサブピクチャシーケンスは、コーディングされて、レイヤ０に対応するコーディングされたビットストリームに含まれてもよく、一方、元のサブピクチャシーケンスから時間的にアップサンプリング（又はダウンサンプリング）された、Ｆ×Ｓ_ｔ，ｋを有するサブピクチャシーケンスは、コーディングされて、レイヤｋに対応するコーディングされたビットストリームに含まれてもよい。ここで、Ｓ_ｔ，ｋは、レイヤｋのための時間サンプリング比を示す。Ｓ_ｔ，ｋの値が１よりも大きい場合には、時間リサンプリングプロセスは、フレームレートアップコンバージョンに等しい。一方、Ｓ_ｔ，ｋが１よりも小さい場合には、時間リサンプリングプロセスは、フレームレートダウンコンバージョンに等しい。

【0136】

同じ又は他の実施形態において、ＣＳＰＳレイヤａを有するサブピクチャが、動き補償又は何らかのインターレイヤ予測のために、ＣＳＰＳレイヤｂを有するサブピクチャによって参照される場合に、ＣＳＰＳレイヤａの空間分解能がＣＳＰＳレイヤｂの空間分解能とは異なるならば、ＣＳＰＳレイヤａでのデコードされたピクセルは、リサンプリングされて、参照のために使用される。リサンプリングプロセスは、アップサンプリングフィルタリング又はダウンサンプリングフィルタリングを必要とし得る。

【0137】

同じ又は他の実施形態において、図９は、コーディングされたビデオシーケンスで全てのピクチャ／スライスのために使用されるｐｏｃ＿ｃｙｃｌｅ＿ａｕを示す、ＶＰＳ（又はＳＰＳ）におけるｖｐｓ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕのシンタックス要素と、スライスヘッダで現在のスライスのｐｏｃ＿ｃｙｃｌｅ＿ａｕを示すｓｌｉｃｅ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕのシンタックス要素とをシグナリングするためのシンタックステーブルの例を示す。ＰＯＣ値がＡＵごとに一様に増大する場合に、ＶＰＳにおけるｖｐｓ＿ｃｏｎｔａｎｔ＿ｐｏｃ＿ｃｙｃｌｅ＿ｐｅｒ＿ａｕは、１に等しくセットされ、ｖｐｓ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕは、ＶＰＳでシグナリングされる。この場合に、ｓｌｉｃｅ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕは、明示的にシグナリングされず、各ＡＵのＡＵＣの値は、ｖｐｓ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕでＰＯＣの値を割ることによって計算される。ＰＯＣ値がＡＵごとに一様に増大しない場合に、ＶＰＳにおけるｖｐｓ＿ｃｏｎｔａｎｔ＿ｐｏｃ＿ｃｙｃｌｅ＿ｐｅｒ＿ａｕは、０に等しくセットされる。この場合に、ｖｐｓ＿ａｃｃｅｓｓ＿ｕｎｉｔ＿ｃｎｔはシグナリングされず、一方、ｓｌｉｃｅ＿ａｃｃｅｓｓ＿ｕｎｉｔ＿ｃｎｔは各スライス又はピクチャごとにスライスヘッダでシグナリングされる。各スライス又はピクチャは、異なる値のｓｌｉｃｅ＿ａｃｃｅｓｓ＿ｕｎｉｔ＿ｃｎｔを有してよい。各ＡＵのＡＵＣの値は、ｓｌｉｃｅ＿ｐｏｃ＿ｃｙｃｌｅ＿ａｕでＰＯＣの値を割ることによって計算される。図１０は、関連するワークフローを表すブロック図を示す。

【0138】

同じ又は他の実施形態において、たとえピクチャ、スライス、又はタイルのＰＯＣの値が異なり得るとしても、同じＡＵＣ値を有するＡＵに対応するピクチャ、スライス、又はタイルは、同じデコーディング又は出力時間インスタンスと関連付けられてよい。従って、同じＡＵ内のピクチャ、スライス、又はタイルの間で如何なる相互的なパージング／デコーディング依存性もなしで、同じＡＵと関連付けられたピクチャ、スライス、又はタイルの全て又はサブセットは、並行してデコードされてよく、同じ時間インスタンスで出力されてよい。

【0139】

同じ又は他の実施形態において、たとえピクチャ、スライス、又はタイルのＰＯＣの値が異なり得るとしても、同じＡＵＣ値を有するＡＵに対応するピクチャ、スライス、又はタイルは、同じ合成／表示時間インスタンスと関連付けられてよい。合成時間がコンテナフォーマットに含まれる場合に、たとえピクチャが異なるＡＵに対応するとしても、ピクチャが同じ合成時間を有しているならば、ピクチャは同じ時間インスタンスで表示され得る。

【0140】

同じ又は他の実施形態において、各ピクチャ、スライス、又はタイルは、同じＡＵにおいて同じ時間識別子（ｔｅｍｐｏｒａｌ＿ｉｄ）を有してよい。ある時間インスタンスに対応するピクチャ、スライス、又はタイルの全て又はサブセットは、同じ時間サブレイヤと関連付けられてもよい。同じ又は他の実施形態において、各ピクチャ、スライス、又はタイルは、同じＡＵにおいて同じ又は異なる空間レイヤｉｄ（ｌａｙｅｒ＿ｉｄ）を有してもよい。ある時間インスタンスに対応するピクチャ、スライス、又はタイルの全て又はサブセットは、同じ又は異なる空間レイヤと関連付けられてよい。

【0141】

図１１は、０に等しいｌａｙｅｒ＿ｉｄを有する背景ビデオＣＳＰＳと、複数の前景ＣＳＰＳレイヤとを含むビデオストリームの例を示す。コーディングされたサブピクチャは１つ以上のＣＳＰＳレイヤから成ってもよく、一方、如何なる前景ＣＳＰＳレイヤにも属さない背景領域は、基本レイヤから成ってもよい。基本レイヤは、背景領域及び前景領域を含んでもよく、一方、拡張ＣＳＰＳレイヤは前景領域を含んでもよい。拡張ＣＳＰＳレイヤは、同じ領域で、基本レイヤよりも良い視覚品質を有し得る。拡張ＣＳＰＳレイヤは、同じ領域に対応する基本レイヤの動きベクトル及び再構成されたピクセルを参照してもよい。

【0142】

同じ又は他の実施形態において、ビデオファイルでは、基本レイヤに対応するビデオビットストリームは、トラックに含まれ、一方、各サブピクチャに対応するＣＳＰＳレイヤは、別個のトラックに含まれる。

【0143】

同じ又は他の実施形態において、基本レイヤに対応するビデオビットストリームは、トラックに含まれ、一方、同じｌａｙｅｒ＿ｉｄを有するＣＳＰＳレイヤは、別個のトラックに含まれる。この例では、レイヤｋに対応するトラックは、レイヤｋに対応するＣＳＰＳレイヤのみを含む。

【0144】

同じ又は他の実施形態において、各サブピクチャの各ＣＳＰＳレイヤは、別のトラックに格納される。各トラックは、１つ以上の他のトラックからの如何なるパージング又はデコーディング依存性も有しても有さなくてもよい。

【0145】

同じ又は他の実施形態において、各トラックは、サブピクチャの全て又はサブセットのＣＳＰＳレイヤのレイヤｉからレイヤｊに対応するビットストリームを含んでよい。ここで、０＜ｉ＝＜ｊ＝＜ｋであり、ｋはＣＳＰＳの最高レイヤである。

【0146】

同じ又は他の実施形態において、ピクチャは、デプスマップ、アルファマップ、３Ｄジオメトリデータ、占有マップ、などを含む１つ以上の関連するメディアデータから成る。そのような関連する時間付き（timed）メディアデータは、夫々が１つのサブピクチャに対応している１つ又は複数のデータサブストリームに分けられ得る。

【0147】

同じ又は他の実施形態において、図１２は、多層サブピクチャ方法に基づいたビデオ会議の例を示す。ビデオストリームには、背景ピクチャに対応する１つの基本レイヤビデオビットストリームと、前景サブピクチャに対応する１つ以上の拡張レイヤビデオビットストリームとが含まれる。各拡張レイヤビデオビットストリームは、ＣＳＰＳレイヤに対応している。ディスプレイでは、基本レイヤに対応するピクチャがデフォルトで表示される。基本レイヤは、一人以上のユーザのピクチャ・イン・ピクチャ（Picture In Picture，ＰＩＰ）を含む。特定のユーザがクライアントの制御によって選択される場合に、選択されたユーザに対応する拡張ＣＳＰＳレイヤは、向上した品質又は空間分解能でデコード及び表示される。図１３は、動作の図を示す。

【0148】

同じ又は他の実施形態において、ネットワークミドルボックス（例えば、ルータ）は、そのバンド幅に応じてユーザへ送信すべきレイヤのサブセットを選択してもよい。ピクチャ／サブピクチャ編成は、バンド幅適応のために使用されてもよい。例えば、ユーザがバンド幅を有さない場合に、ルータは、それらの重要性により又は使用されている設定に基づいてレイヤを削除するか又はいくつかのサブピクチャを選択する。これは、バンド幅に適応するよう動的に行われ得る。

【0149】

図１４は、３６０度ビデオの使用ケースを示す。球状の３６０度ピクチャが平面ピクチャに投影される場合に、投影３６０度ピクチャは、基本レイヤとして複数のサブピクチャにパーティション化されてよい。特定のサブピクチャの拡張レイヤがコーディングされて、クライアントへ伝送されてよい。デコーダは、全てのサブピクチャを含む基本レイヤと、選択されたサブピクチャの拡張レイヤとの両方をデコードすることが可能であってよい。現在のビューポートが選択されたサブピクチャと同じである場合に、表示されているピクチャは、拡張レイヤを伴ったデコードされたサブピクチャでより高い品質を有し得る。そうでない場合には、基本レイヤを含むデコードされたピクチャが、低い品質で表示され得る。

【0150】

同じ又は他の実施形態において、表示のための如何なるレイアウト情報も、補足情報（例えば、ＳＥＩメッセージ又はメタデータ）として、ファイルに存在してもよい。１つ以上のデコードされたサブピクチャは、シグナリングされたレイアウト情報に応じて再配置又は表示されてよい。レイアウト情報は、ストリーミングサーバ又はブロードキャスタによってシグナリングされてもよく、あるいは、ネットワークエンティティ又はクラウドサーバによって再生されてもよく、あるいは、ユーザのカスタマイズされた設定によって決定されてもよい。

【0151】

実施形態において、入力されたピクチャが１つ以上の（長方形の）サブ領域に分けられる場合に、各サブ領域は、独立レイヤとしてコーディングされてもよい。局所領域に対応する各独立レイヤは、一意のｌａｙｅｒ＿ｉｄ値を有してよい。各独立レイヤについて、サブピクチャサイズ及び位置情報がシグナリングされてもよい。例えば、ピクチャサイズ（幅、高さ）及び左上隅のオフセット情報（ｘ＿ｏｆｆｓｅｔ、ｙ＿ｏｆｆｓｅｔ）がシグナリングされ得る。図１５は、分割されたサブピクチャのレイアウト、そのサブピクチャサイズ及び位置情報、並びにその対応するピクチャ予測構造の例を示す。サブピクチャサイズ及びサブピクチャ位置を含むレイアウト情報は、パラメータセット、スライス若しくはタイルグループのヘッダ、又はＳＥＩメッセージなどの高位シンタックス構造でシグナリングされてもよい。

【0152】

同じ実施形態で、独立レイヤに対応する各サブピクチャは、ＡＵ内でその一意のＰＯＣ値を有してもよい。ＤＰＢに格納されているピクチャの中の参照ピクチャがＲＰＳ又はＲＰＬ構造でシンタックス要素を使用することによって指示される場合に、レイヤに対応する各サブピクチャのＰＯＣ値が使用されてもよい。

【0153】

同じ又は他の実施形態において、（インターレイヤ）予測構造を示すために、ｌａｙｅｒ＿ｉｄは使用されなくてもよく、ＰＯＣ（差分）値が使用され得る。

【0154】

同じ実施形態で、レイヤ（又は局所領域）に対応するＮに等しいＰＯＣ値を有しているサブピクチャは、動き補償された予測のために、同じレイヤ（又は同じ局所領域）に対応する、Ｋ＋Ｎに等しいＰＯＣ値を有するサブピクチャの参照ピクチャとして使用されてもされなくてもよい。ほとんどの場合に、数Ｋの値は、サブ領域の数と同じであってもよい（独立）レイヤの最大数に等しくなる。

【0155】

同じ又は他の実施形態において、図１６は、図１５の拡張された場合を示す。入力されたピクチャが複数（例えば、４つ）のサブ領域に分けられる場合に、各局所領域は、１つ以上のレイヤを有してコーディングされてもよい。その場合に、独立レイヤの数はサブ領域の数に等しくてよく、１つ以上のレイヤは１つのサブ領域に対応してよい。よって、各サブ領域は、１つ以上の独立レイヤ及びゼロ個以上の従属レイヤを有してコーディングされてもよい。

【0156】

同じ実施形態において、図１６で、入力されたピクチャは４つのサブ領域に分けられてもよい。右上サブ領域は、レイヤ１及びレイヤ４である２つのレイヤとしてコーディングされてもよく、一方、右下サブ領域は、レイヤ３及びレイヤ５である２つのレイヤとしてコーディングされてもよい。この場合に、レイヤ４は、動き補償された予測のためにレイヤ１を参照してもよく、一方、レイヤ５は、動き補償のためにレイヤ３を参照してもよい。

【0157】

同じ又は他の実施形態において、レイヤ境界にわたるインループフィルタリング（例えば、デブロッキングフィルタリング、適応インループフィルタリング、リシェーパ（reshaper）、バイラテラルフィルタリング、又は任意のディープラーニングに基づいたフィルタリング）は、（任意に）無効にされてもよい。

【0158】

同じ又は他の実施形態において、レイヤ境界にわたる動き補償された予測又はイントラブロックコピーは、（任意に）無効にされてもよい。

【0159】

同じ又は他の実施形態において、サブピクチャの境界での動き補償された予測又はインループフィルタリングのための境界パディングは、任意に処理されてもよい。境界パディングが処理されるか否かを示すフラグは、パラメータセット（ＶＰＳ、ＳＰＳ、ＰＰＳ、若しくはＡＰＳ）、スライス若しくはタイルグループヘッダ、又はＳＥＩメッセージなどの高位シンタックス構造でシグナリングされてもよい。

【0160】

同じ又は他の実施形態において、サブ領域（又はサブピクチャ）のレイアウト情報は、ＶＰＳ又はＳＰＳでシグナリングされてもよい。図１７は、ＶＰＳ及びＳＰＳでのシンタックス要素の例を示す。この例では、ｖｐｓ＿ｓｕｂ＿ｐｉｃｔｕｒｅ＿ｄｉｖｉｄｉｎｇ＿ｆｌａｇがＶＰＳでシグナリングされる。フラグは、入力されたピクチャが複数のサブ領域に分けられるか否かを示し得る。ｖｐｓ＿ｓｕｂ＿ｐｉｃｔｕｒｅ＿ｄｉｖｉｄｉｎｇ＿ｆｌａｇの値が０に等しい場合に、現在のＶＰＳに対応するコーディングされたビデオシーケンス内の入力されたピクチャは、複数のサブ領域に分けられなくてもよい。この場合に、入力されたピクチャのサイズは、ＳＰＳでシグナリングされるコーディングされたピクチャのサイズ（ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）に等しくなる。ｖｐｓ＿ｓｕｂ＿ｐｉｃｔｕｒｅ＿ｄｉｖｉｄｉｎｇ＿ｆｌａｇの値が１に等しい場合に、入力されたピクチャは、複数のサブ領域に分けられ得る。この場合に、シンタックス要素ｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ及びｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍａｐｌｅｓは、ＶＰＳでシグナリングされる。ｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ及びｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍａｐｌｅｓの値は、夫々、入力されたピクチャの幅及び高さに等しくなる。

【0161】

同じ実施形態において、ｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ及びｖｐｓ＿ｆｕｌｌ＿ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍａｐｌｅｓの値は、デコーディングのために使用されなくてもよいが、合成及び表示のために使用され得る。

【0162】

同じ実施形態において、ｖｐｓ＿ｓｕｂ＿ｐｉｃｔｕｒｅ＿ｄｉｖｉｄｉｎｇ＿ｆｌａｇの値が１に等しい場合に、シンタックス要素ｐｉｃ＿ｏｆｆｓｅｔ＿ｘ及びｐｉｃ＿ｏｆｆｓｅｔ＿ｙは、特定のレイヤに対応するＳＰＳでシグナリングされてよい。この場合に、ＳＰＳでシグナリングされるコーディングされたピクチャのサイズ（ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）は、特定のレイヤに対応するサブ領域の幅及び高さに等しくなる。また、サブ領域の左上隅の位置（ｐｉｃ＿ｏｆｆｓｅｔ＿ｘ、ｐｉｃ＿ｏｆｆｓｅｔ＿ｙ）が、ＳＰＳでシグナリングされてもよい。

【0163】

同じ実施形態において、サブ領域の左上隅の位置情報（ｐｉｃ＿ｏｆｆｓｅｔ＿ｘ、ｐｉｃ＿ｏｆｆｓｅｔ＿ｙ）は、デコーディングのために使用されなくてもよいが、合成及び表示のために使用され得る。

【0164】

同じ又は他の実施形態において、入力されたピクチャのサブ領域の全て又はサブセットのレイアウト情報（サイズ及び位置）、及びレイヤ間の依存関係情報が、パラメータセット又はＳＥＩメッセージでシグナリングされてもよい。図１８は、サブ領域のレイアウトの情報、レイヤ間の依存性、及びサブ領域と１つ以上のレイヤとの間の関係を示すシンタックス要素の例を表す。この例では、シンタックス要素ｎｕｍ＿ｓｕｂ＿ｒｅｇｉｏｎは、現在のコーディングされたビデオシーケンス内の（長方形）サブ領域の数を示す。シンタックス要素ｎｕｍ＿ｌａｙｅｒｓは、現在のコーディングされたビデオシーケンス内のレイヤの数を示す。ｎｕｍ＿ｌａｙｅｒｓの値は、ｎｕｍ＿ｓｕｂ＿ｒｅｇｉｏｎの値以上であってよい。いずれかのサブ領域が単一のレイヤとしてコーディングされる場合に、ｎｕｍ＿ｌａｙｅｒｓの値は、ｎｕｍ＿ｓｕｂ＿ｒｅｇｉｏｎの値と等しくなる。１つ以上のサブ領域が複数のレイヤとしてコーディングされる場合に、ｎｕｍ＿ｌａｙｅｒｓの値は、ｎｕｍ＿ｓｕｂ＿ｒｅｇｉｏｎの値よりも大きくなる。シンタックス要素ｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［ｉ］［ｊ］は、ｊ番目のレイヤからｉ番目のレイヤへの依存性を示す。ｎｕｍ＿ｌａｙｅｒｓ＿ｆｏｒ＿ｒｅｇｉｏｎ［ｉ］は、ｉ番目のサブ領域に関連したレイヤの数を示す。ｓｕｂ＿ｒｅｇｉｏｎ＿ｌａｙｅｒ＿ｉｄ［ｉ］［ｊ］は、ｉ番目のサブ領域に関連したｊ番目のレイヤのｌａｙｅｒ＿ｉｄを示す。ｓｕｂ＿ｒｅｇｉｏｎ＿ｏｆｆｓｅｔ＿ｘ［ｉ］及びｓｕｂ＿ｒｅｇｉｏｎ＿ｏｆｆｓｅｔ＿ｙ［ｉ］は、夫々、ｉ番目のサブ領域の左上隅の水平及び垂直位置を示す。ｓｕｂ＿ｒｅｇｉｏｎ＿ｗｉｄｔｈ［ｉ］及びｓｕｂ＿ｒｅｇｉｏｎ＿ｈｅｉｇｈｔ［ｉ］は、夫々、ｉ番目のサブ領域の幅及び高さを示す。

【0165】

１つの実施形態において、プロファイルティアレベル情報の有無によらず出力されるべき１つ以上のレイヤを示すための出力レイヤセットを定める１つ以上のシンタックス要素は、高位シンタックス構造、例えば、ＶＰＳ、ＤＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、又はＳＥＩメッセージでシグナリングされてもよい。図１９を参照すると、ＶＰＳを参照するコーディングされたビデオシーケンスにおける出力レイヤセット（Output Layer Set，ＯＬＳ）の数を示すシンタックス要素ｎｕｍ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｓｅｔｓは、ＶＰＳでシグナリングされてもよい。各出力レイヤセットについて、ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇは、出力レイヤの数と同じ回数だけシグナリングされてよい。

【0166】

同じ実施形態において、１に等しいｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇは、ｉ番目のレイヤが出力されることを指定する。０に等しいｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇは、ｉ番目のレイヤが出力されないことを指定する。

【0167】

同じ又は他の実施形態において、各出力レイヤセットについてプロファイルティアレベル情報を定める１つ以上のシンタックス要素は、高位シンタックス構造、例えば、ＶＰＳ、ＤＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、又はＳＥＩメッセージでシグナリングされてもよい。依然として図１９を参照すると、ＶＰＳを参照するコーディングされたビデオシーケンスにおけるＯＬＳごとのプロファイルティアレベル情報の数を示すシンタックス要素ｎｕｍ＿ｐｒｏｆｉｌｅ＿ｔｉｅｒ＿ｌｅｖｅｌは、ＶＰＳでシグナリングされてもよい。各出力レイヤセットについて、プロファイルティアレベル情報のためのシンタックス要素の組又はプロファイルティアレベル情報内のエントリの中で特定のプロファイルティアレベル情報を示すインデックスは、出力レイヤの数と同じ回数だけシグナリングされてよい。

【0168】

同じ実施形態において、ｐｒｏｆｉｌｅ＿ｔｉｅｒ＿ｌｅｖｅｌ＿ｉｄｘ［ｉ］［ｊ］は、ｉ番目のＯＬＳのｊ番目のレイヤに適用するｐｒｏｆｉｌｅ＿ｔｉｅｒ＿ｌｅｖｅｌ（）シンタックス構造の、ＶＰＳでのｐｒｏｆｉｌｅ＿ｔｉｅｒ＿ｌｅｖｅｌ（）シンタックス構造のリスト内へのインデックスを指定する。

【0169】

同じ又は他の実施形態において、図２０を参照すると、シンタックス要素ｎｕｍ＿ｐｒｏｆｉｌｅ＿ｔｉｌｅ＿ｌｅｖｅｌ及び／又はｎｕｍ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｓｅｔｓは、最大レイヤの数が１よりも多い（ｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１＞０）場合にシグナリングされてもよい。

【0170】

同じ又は他の実施形態において、図２０参照すると、ｉ番目の出力レイヤセットについての出力レイヤシグナリングのモードを示すシンタックス要素ｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒｓ＿ｍｏｄｅ［ｉ］が、ＶＰＳに存在してもよい。

【0171】

同じ実施形態において、０に等しいｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒｓ＿ｍｏｄｅ［ｉ］は、最高レイヤのみがｉ番目の出力レイヤセットにより出力されることを指定する。１に等しいｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒｓ＿ｍｏｄｅ［ｉ］は、全てのレイヤがｉ番目の出力レイヤセットにより出力されることを指定する。２に等しいｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒｓ＿ｍｏｄｅ［ｉ］は、ｉ番目の出力レイヤセットにより出力されるレイヤが、１に等しいｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇ［ｉ］［ｊ］を有するレイヤであることを指定する。より多くの値がリザーブされてもよい。

【0172】

同じ実施形態において、ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇ［ｉ］［ｊ］は、ｉ番目の出力レイヤセットについてのｖｐｓ＿ｏｕｔｐｕｔ＿ｌａｙｅｒｓ＿ｍｏｄｅ［ｉ］の値に応じて、シグナリングされてもされなくてもよい。

【0173】

同じ又は他の実施形態において、図２０を参照すると、フラグｖｐｓ＿ｐｔｌ＿ｆｌａｇ［ｉ］が、ｉ番目の出力レイヤセットについて存在してもよい。ｖｐｓ＿ｐｔｌ＿ｆｌａｇ［ｉ］の値に応じて、ｉ番目の出力レイヤセットのプロファイルティアレベル情報は、シグナリングされてもされなくてもよい。

【0174】

同じ又は他の実施形態において、図２１を参照すると、現在のＣＶＳでのサブピクチャの数ｍａｘ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１は、高位シンタックス構造、例えば、ＶＰＳ、ＤＰＳ、ＳＰＳ、ＰＰＳ、ＡＰＳ、又はＳＥＩメッセージでシグナリングされてもよい。

【0175】

同じ実施形態において、図２１を参照すると、ｉ番目のサブピクチャのサブピクチャ識別子ｓｕｂ＿ｐｉｃ＿ｉｄ［ｉ］は、サブピクチャの数が１よりも多い（ｍａｘ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１＞０）場合にシグナリングされてもよい。

【0176】

同じ又は他の実施形態において、各出力レイヤセットの各レイヤに属するサブピクチャ識別子を示す１つ以上のシンタックス要素は、ＶＰＳでシグナリングされてもよい。図２２を参照すると、ｓｕｂ＿ｐｉｃ＿ｉｄ＿ｌａｙｅｒ［ｉ］［ｊ］［ｋ］は、ｉ番目の出力レイヤセットのｊ番目のレイヤに存在するｋ番目のサブピクチャを示す。この情報により、デコーダは、特定の出力レイヤセットの各レイヤについて、どのサブピクチャがデコードされ出力され得るかを認識し得る。

【0177】

実施形態において、ピクチャヘッダ（ＰＨ）は、コーディングされたピクチャの全スライスに適用するシンタックス要素を含むシンタックス構造である。ピクチャユニット（ＰＵ）はＮＡＬユニットの組であり、ＮＡＬユニットは、特定の分類規則に従って互いに関連付けられ、デコーディング順序において連続しており、かつ、厳密に１つのコーディングされたピクチャを含む。ＰＵは、ピクチャヘッダ（ＰＨ）と、コーディングされたピクチャを構成する１つ以上のビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットとを含んでもよい。

【0178】

実施形態において、ＳＰＳ（ＲＢＳＰ）は、それが参照される前にデコーディングプロセスに利用可能であるか、０に等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＡＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0179】

実施形態において、ＳＰＳ（ＲＢＳＰ）は、それが参照される前にデコーディングプロセスに利用可能であるか、ＳＰＳを参照する１つ以上のＰＰＳを含むＣＶＳで０に等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＡＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0180】

実施形態において、ＳＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＰＳによって参照される前にデコーディングプロセスに利用可能であるか、ＳＰＳを参照する１つ以上のＰＰＳを含むＣＶＳでＳＰＳＮＡＬユニットを参照するＰＰＳＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0181】

実施形態において、ＳＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＰＳによって参照される前にデコーディングプロセスに利用可能であるか、０に等しいＴｅｍｐｏｒａｌＩＤ及びＳＰＳＮＡＬユニットを参照するＰＰＳＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0182】

実施形態において、ＳＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＰＳによって参照される前にデコーディングプロセスに利用可能であるか、０に等しいＴｅｍｐｏｒａｌＩＤ及びＣＶＳでＳＰＳＮＡＬユニットを参照するＰＰＳＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0183】

同じ又は他の実施形態で、ｐｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、参照されているＳＰＳについてのｓｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を指定する。ｐｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は、ＣＬＶＳにおけるコーディングされたピクチャによって参照されている全てのＰＰＳで同じであってよい。

【0184】

同じ又は他の実施形態で、ＣＶＳで特定の値のｓｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを有する全てのＳＰＳＮＡＬユニットは、同じ内容を有してもよい。

【0185】

同じ又は他の実施形態で、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値にかかわらず、ＳＰＳＮＡＬユニットは、ｓｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの同じ値空間を共有してもよい。

【0186】

同じ又は他の実施形態で、あるＳＰＳＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄ値は、そのＳＰＳＮＡＬユニットを参照するＰＰＳＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しくてもよい。

【0187】

実施形態において、ｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＳＰＳが、ｎに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する１つ以上のＰＰＳによって参照される場合に、ｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤは、ｎに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤ又はｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤの（直接又は間接）参照レイヤと同じであってもよい。

【0188】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳＮＡＬユニットのＴｅｍｐｏｒａｌＩＤに等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＡＵに含まれるか、あるいは、外部手段を通じて供給されるべきである。

【0189】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳを参照する１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）を含むＣＶＳでＰＰＳＮＡＬユニットのＴｅｍｐｏｒａｌＩＤに等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＡＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0190】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）によって参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳを参照する１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）を含むＣＶＳでＰＰＳＮＡＬユニットを参照するコーディングされたスライスＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0191】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）によって参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳを参照する１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）を含むＣＶＳでＰＰＳＮＡＬユニットを参照するコーディングされたスライスＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄ及びＰＰＳＮＡＬユニットのＴｅｍｐｏｒａｌＩＤに等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0192】

同じ又は他の実施形態で、ＰＨにおけるｐｈ＿ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、使用中の参照されているＰＰＳについてのｐｐｓ＿ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を指定する。ｐｐｓ＿ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は、ＣＬＶＳにおけるコーディングされたピクチャによって参照される全てのＰＰＳで同じであってよい。

【0193】

同じ又は他の実施形態で、ＰＵ内の特定の値のｐｐｓ＿ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを有する全てのＰＰＳＮＡＬユニットは、同じ内容を有するべきである。

【0194】

同じ又は他の実施形態で、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値にかかわらず、ＰＰＳＮＡＬユニットは、ｐｐｓ＿ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの同じ値空間を共有してもよい。

【0195】

同じ又は他の実施形態で、あるＰＰＳＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄは、そのＰＰＳＮＡＬユニットを参照するＮＡＬユニットを参照するコーディングされたスライスＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しくてもよい。

【0196】

実施形態において、ｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＰＰＳが、ｎに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する１つ以上のコーディングされたスライスＮＡＬユニットによって参照される場合に、ｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤは、ｎに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤ又はｍに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤの（直接又は間接）参照レイヤと同じであってもよい。

【0197】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳＮＡＬユニットのＴｅｍｐｏｒａｌＩＤに等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＡＵに含まれるか、あるいは、外部手段を通じて供給されるべきである、

【0198】

【0199】

【0200】

実施形態において、ＰＰＳ（ＲＢＳＰ）は、それが１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）によって参照される前にデコーディングプロセスに利用可能であるか、ＰＰＳを参照する１つ以上のＰＨ（又はコーディングされたスライスＮＡＬユニット）を含むＣＶＳでＰＰＳＮＡＬユニットを参照するコーディングされたスライスＮＡＬユニットの最小ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄ及びＰＰＳＮＡＬユニットのＴｅｍｐｏｒａｌＩＤに等しいＴｅｍｐｏｒａｌＩＤを有する少なくとも１つのＰＵに含まれるか、あるいは、外部手段を通じて供給されてもよい。

【0201】

【0202】

【0203】

【0204】

【0205】

【0206】

実施形態において、図２２に示されるよう、ピクチャパラメータセット内のｐｐｓ＿ｓｕｂｐｉｃ＿ｉｄ［ｉ］は、ｉ番目のサブピクチャのサブピクチャＩＤを指定する。ｐｐｓ＿ｓｕｂｐｉｃ＿ｉｄ［ｉ］シンタックス要素の長さは、ｐｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１ビットである。

【0207】

変数ＳｕｂｐｉｃＩｄＶａｌ［ｉ］は、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉの各値について、次のように導出される：

【数1】

【0208】

同じ又は他の実施形態で、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉ及びｊのいずれか２つの異なる値については、ＳｕｂｐｉｃＩｄＶａｌ［ｉ］は、ＳｕｂｐｉｃＩｄＶａｌ［ｊ］に等しくなくてもよい。

【0209】

同じ又は他の実施形態で、現在のピクチャがＣＬＶＳの最初のピクチャではない場合に、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉの各値について、ＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値が同じレイヤ内のデコーディング順序で前のピクチャのＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値と等しくないならば、サブピクチャインデックスｉを有する現在のピクチャ内のサブピクチャの全てのコーディングされたスライスＮＡＬユニットについてのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、ＩＤＲ＿Ｗ＿ＲＡＤＬ以上ＣＲＡ＿ＮＵＴ以下の範囲内の特定の値に等しくなる。

【0210】

【0211】

同じ又は他の実施形態で、現在のピクチャがＣＬＶＳの最初のピクチャではない場合に、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉの各値について、ＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値が同じレイヤ内のデコーディング順序で前のピクチャのＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値に等しくないならば、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］及びｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、１に等しくなる。

【0212】

同じ又は他の実施形態で、現在のピクチャがＣＬＶＳの最初のピクチャではない場合に、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉの各値について、ＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値が同じレイヤ内のデコーディング順序で前のピクチャのＳｕｂｐｉｃＩｄＶａｌ［ｉ］の値に等しくないならば、ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは、１に等しいはずであり、あるいは、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］及びｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、１に等しいはずである。

【0213】

同じ又は他の実施形態で、サブピクチャが他のサブピクチャへの如何なる参照もなしで独立してエンコードされる場合に、ある領域のサブピクチャ識別子の値は、コーディングされたビデオシーケンス内で変更されてもよい。

【0214】

サンプルは、ＣＴＢの単位で処理される。幅及び高さの両方でのルーマＣＴＢごとのアレイサイズは、サンプルの単位でのＣｔｂＳｉｚｅＹである。クロマＣＴＢごとのアレイの幅及び高さは、サンプルの単位で、夫々、ＣｔｂＷｉｄｔｈＣ及びＣｔｂＨｅｉｇｈｔＣである。各ＣＴＢは、イントラ又はインター予測のために及び変換コーディングのためにブロックサイズを識別するようパーティションシグナリングを割り当てられる。パーティショニングは、再帰的な四分木パーティショニングである。四分木の根は、ＣＴＢを割り当てられる。四分木は、四分木リーフと呼ばれるリーフに達するため分裂される。コンポーネント幅がＣＴＢサイズの整数倍でない場合に、右コンポーネント境界でのＣＴＢは不完全である。コンポーネント高さがＣＴＢサイズの整数倍でない場合に、↓コンポーネント境界でのＣＴＢは不完全である。

【0215】

各サブピクチャの幅及び高さは、ＣｔｂＳｉｚｅＹの単位でＳＰＳにおいてシグナリングされてもよい。図２３で、例えば、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］＋１は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの幅を指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］の値は、（（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ）－ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］－１に等しいと推測される。ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］＋１は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの高さを指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｈｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］の値は、（（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ）－ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］－１に等しいと推測される。

【0216】

各サブピクチャの幅は、ピクチャ幅がＣｔｂＳｉｚｅＹ以上である場合に、ＣｔｂＳｉｚｅＹ以上であり得る。各サブピクチャの高さは、ピクチャ高さがＣｔｂＳｉｚｅＹ以上である場合に、ＣｔｂＳｉｚｅＹ以上であり得る。

【0217】

ピクチャ幅がＣｔｂＳｉｚｅＹ以下であり、ピクチャ高さがＣｔｂＳｉｚｅＹ以下である場合には、ピクチャは、１つよりも多いサブピクチャにパーティション化されなくても良い。その場合に、サブピクチャの数は１に等しくなり得る。

【0218】

ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがＣｔｂＳｉｚｅＹ以下であり、ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓがＣｔｂＳｉｚｅＹ以下である場合に、ｓｕｂｐｉｃ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は０に等しくなればならない。ｓｕｂｐｉｃ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが０に等しいとき、明示的なシグナリングはサブピクチャパーティショニング情報について存在せず、ピクチャ内のサブピクチャの数は１に等しい。

【0219】

同じ又は他の実施形態で、ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１＋１は、シンタックス要素ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ［ｉ］、存在する場合にシンタックス要素ｐｐｓ＿ｓｕｂｐｉｃ＿ｉｄ［ｉ］、及び存在する場合にシンタックス要素ｓｌｉｃｅ＿ｓｕｂｐｉｃ＿ｉｄを表すために使用されるビットの数を指定する。ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、０以上１５以下の範囲をとり得る。１＜＜（ｓｐｓ＿ｓｕｂｐｉｃ＿ｉｄ＿ｌｅｎ＿ｍｉｎｕｓ１）の値は、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１＋１以上であり得る。

【0220】

同じ又は他の実施形態で、サブピクチャの数が１に等しい場合に、ｓｕｂｐｉｃ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは１に等しくなり、サブピクチャパーティショニング情報は明示的にシグナリングされなくてもよい。これは、その場合に、サブピクチャ幅及び高さ情報がピクチャ幅及び高さ情報に等しく、サブピクチャの左上位置がピクチャの左上位置に等しいからである。

【0221】

例えば、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの左上ＣＴＵの水平位置を指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］の値は、０に等しい推測される。ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの高さの左上ＣＴＵの垂直位置を指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］の値は、０に等しいと推測される。ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］＋１は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの幅を指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｉ］の値は、（（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ）－ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］－１に等しい推測される。ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］＋１は、ＣｔｂＳｉｚｅＹの単位でのｉ番目のサブピクチャの高さを指定する。シンタックス要素の長さは、Ｃｅｉｌ（Ｌｏｇ２（（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ））ビットである。存在しない場合に、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｉ］の値は、（（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ＋ＣｔｂＳｉｚｅＹ－１）＞＞ＣｔｂＬｏｇ２ＳｉｚｅＹ）－ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］－１に等しい推測される。

【0222】

同じ又は他の実施形態で、サブピクチャの数が１よりも多い場合に、ｓｕｂｐｉｃ＿ｉｎｆｏ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは１に等しくなり、サブピクチャパーティショニング情報は、図２３に示されるように、パラメータセットにおいて明示的にシグナリングされ得る。

【0223】

例えば、図２３で、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ２＋２は、ＣＬＶＳでの各ピクチャ内のサブピクチャの数を指定する。ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ２の値は、０からＣｅｉｌ（ｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）×Ｃｅｉｌ（ｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ÷ＣｔｂＳｉｚｅＹ）－１以下の範囲をとり得る。存在しない場合に、ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ２の値は、０に等しいと推測される。

【0224】

同じ実施形態で、タイル列及び行におけるｉ番目のサブピクチャの幅及び高さを夫々指定する、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉについてのリストＳｕｂｐｉｃＷｉｄｔｈＩｎＴｉｌｅｓ［ｉ］及びＳｕｂｐｉｃＨｅｉｇｈｔＩｎＴｉｌｅｓ［ｉ］、並びにｉ番目のサブピクチャの高さが１タイル行に満たないかどうかを指定する、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｉについてのリストｓｕｂｐｉｃＨｅｉｇｈｔＬｅｓｓＴｈａｎＯｎｅＴｉｌｅＦｌａｇ［ｉ］は、次のように導出される：

【数2】

【0225】

ｒｅｃｔ＿ｓｌｉｃｅ＿ｆｌａｇが１に等しい場合に、ｉ番目のスライスにおけるＣＴＵの数を指定する、０以上ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１以下の範囲内のｉについてのリストＮｕｍＣｔｕｓＩｎＳｌｉｃｅ［ｉ］、そのスライス内の最初のＣＴＵを含むタイルのタイルインデックスを指定する、０以上ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１以下の範囲内のｉについてのリストＳｌｉｃｅＴｏｐＬｅｆｔＴｉｌｅＩｄｘ［ｉ］、及びｉ番目のスライス内のｊ番目のＣＴＢのピクチャラスタスキャンアドレスを指定する、０以上ｎｕｍ＿ｓｌｉｃｅｓ＿ｉｎ＿ｐｉｃ＿ｍｉｎｕｓ１以下の範囲内のｉ及び０以上ＮｕｍＣｔｕｓＩｎＳｌｉｃｅ［ｉ］－１以下の範囲内のｊについての行列ＣｔｂＡｄｄｒＩｎＳｌｉｃｅ［ｉ］［ｊ］、並びにｉ番目のスライスを含むタイル内のスライスの数を指定する変数ＮｕｍＳｌｉｃｅｓＩｎＴｉｌｅ［ｉ］は、次のように導出される：

【数3】

【0226】

２つ以上の独立してコーディングされたサブピクチャは、コーディングされたピクチャにマージされてもよく、それにより、コーディングされたピクチャは、単一のピクチャとしてデコード及び出力され得る。

【0227】

２つ以上の独立してコーディングされたサブピクチャが、コーディングされたピクチャにマージされる場合に、コーディングされたピクチャは、２つ以上の異なるＮＡＬユニットタイプを有するＶＣＬＮＡＬユニットからなってもよい。

【0228】

図２３で、フラグｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、パラメータセット（例えば、ＰＰＳ、ＳＰＳ）においてシグナリングされてもよい。１に等しいｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、ＰＰＳを参照する各ピクチャが１つよりも多いＶＣＬＮＡＬユニットを有し、ＶＣＬＮＡＬユニットが同じ値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有していないことを指定する。０に等しいｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、ＰＰＳを参照する各ピクチャが１つ以上のＶＣＬＮＡＬユニットを有し、ＰＰＳを参照する各ピクチャのＶＣＬＮＡＬユニットが同じ値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有することを指定する。

【0229】

ＰＰＳ内のｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇを有する各ピクチャは、トレーリング（trailing）ピクチャとして扱われる。従って、２つ以上の異なるＮＡＬユニットタイプを有するコーディングされたピクチャは、トレーリングピクチャとしてデコードされ得る。ピクチャがデコーディング順序で後続のピクチャによって参照される場合に、そのピクチャはトレーリングピクチャとして扱われてもよい。

【0230】

図２３で、１に等しいｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは、ＣＬＶＳにおける全てのサブピクチャ境界がピクチャ境界として扱われ、サブピクチャ境界間にループフィルタリングは存在しないことを指定する。０に等しいｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは、そのような制約を課さない。存在しない場合に、ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇの値は、０に等しいと推測される。

【0231】

図２３で、１に等しいｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］は、ＣＬＶＳにおける各コーディングされたピクチャのｉ番目のサブピクチャが、インループフィルタリング動作を除くデコーディングプロセスでピクチャとして扱われることを指定する。０に等しいｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］は、ＣＬＶＳにおける各コーディングされたピクチャのｉ番目のサブピクチャが、インループフィルタリング動作を除くデコーディングプロセスでピクチャとして扱われないことを指定する。存在しない場合に、ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値は、ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇに等しいと推測される。ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］が１に等しい場合に、次の条件の全てが、出力レイヤとしてｉ番目のサブピクチャを含むレイヤを含むＯＬＳ内の各出力レイヤ及びその参照レイヤについて真であることは、ビットストリーム一致（bitstream conformance）の要件である。

【0232】

・出力レイヤ及びその参照レイヤ内の全てのピクチャは、同じ値のｐｉｃ＿ｗｉｄｔｈ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ及び同じ値のｐｉｃ＿ｈｅｉｇｈｔ＿ｍａｘ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓを有するべきである。

【0233】

・出力レイヤ及びその参照レイヤによって参照される全てのＳＰＳは、同じ値のｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１を有するべきであり、かつ、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｊの各値について、夫々、同じ値のｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｘ［ｉ］、ｓｕｂｐｉｃ＿ｃｔｕ＿ｔｏｐ＿ｌｅｆｔ＿ｙ［ｉ］、ｓｕｂｐｉｃ＿ｗｉｄｔｈ＿ｍｉｎｕｓ１［ｊ］、ｓｕｂｐｉｃ＿ｈｅｉｇｈｔ＿ｍｉｎｕｓ１［ｊ］、及びｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｊ］を有するべきである。

【0234】

・出力レイヤ及びその参照レイヤ内の各アクセスユニットの全てのピクチャは、０以上ｓｐｓ＿ｎｕｍ＿ｓｕｂｐｉｃｓ＿ｍｉｎｕｓ１以下の範囲内のｊの各値について、同じ値のＳｕｂｐｉｃＩｄＶａｌ［ｊ］を有するべきである。

【0235】

図２３で、１に等しいｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、インループフィルタリング動作がＣＬＶＳにおける各コーディングされたピクチャ内のｉ番目のサブピクチャの境界にわたって実行されてもよいことを指定する。０に等しいｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、インループフィルタリング動作がＣＬＶＳにおける各コーディングされたピクチャ内のｉ番目のサブピクチャの境界にわたって実行されないことを指定する。存在しない場合に、ｌｏｏｐ＿ｆｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］の値は、１－ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇに等しいと推測される。

【0236】

２つ以上のコーディングされたサブピクチャがコーディングされたピクチャにマージされる場合に、これらのコーディングされたサブピクチャは、互いからの如何なるパージング又はデコーディング依存性も有さなくてもよい。

【0237】

実施形態で、ＰＰＳ内のｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合、ＰＰＳを参照するサブピクチャのｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値は、１に等しくなり得る。

【0238】

実施形態で、ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇが０に等しく、１つ以上のｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値が１に等しくない場合に、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、０に等しくなり得る。

【0239】

実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ｓｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇの値は、１に等しくなり得る。

【0240】

実施形態で、ＰＰＳ内のｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ＰＰＳを参照するサブピクチャのｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値は、１に等しいと推測される。

【0241】

実施形態で、ピクチャ内の、ＮＡＬユニットタイプが異なっている２つ以上の隣接するサブピクチャは、１に等しいｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値を有するべきである。

【0242】

実施形態において、図２４で、サブピクチャパーティショニング情報は、ＰＰＳでシグナリングされてもよい。例えば、１に等しいｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは、ＰＰＳを参照する全ての境界サブピクチャがピクチャ境界として扱われ、サブピクチャ境界間にループフィルタリングは存在しないことを指定する。０に等しいｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは、そのような制約を課さない。存在しない場合に、ｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇの値は、０に等しいと推測される。１に等しいｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］は、ＰＰＳを参照する各コーディングされたピクチャのｉ番目のサブピクチャが、インループフィルタリング動作を除くデコーディングプロセスでピクチャとして扱われることを指定する。０に等しいｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］は、ＰＰＳを参照する各コーディングされたピクチャのｉ番目のサブピクチャが、インループフィルタリング動作を除くデコーディングプロセスでピクチャとして扱われないことを指定する。存在しない場合に、ｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値は、ｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇに等しいと推測される。１に等しいｐｐｓ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、インループフィルタリング動作が、ＰＰＳを参照する各コーディングされたピクチャのｉ番目のサブピクチャの境界にわたって実行されてもよいことを指定する。０に等しいｐｐｓ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］は、インループフィルタリング動作が、ＰＰＳを参照する各コーディングされたピクチャのｉ番目のサブピクチャの境界にわたって実行されないことを指定する。存在しない場合に、ｐｐｓ＿ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｓｕｂｐｉｃ＿ｅｎａｂｌｅｄ＿ｆｌａｇ［ｉ］の値は、１－ｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇに等しいと推測される。

【0243】

同じ実施形態で、ＰＰＳ内のｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］の値は１に等しいはずである。

【0244】

同じ又は他の実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ｐｐｓ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｓｕｂｐｉｃｓ＿ｆｌａｇは１に等しいはずである。

【0245】

同じ又は他の実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合に、ｐｐｓ＿ｓｕｂｐｉｃ＿ｔｒｅａｔｅｄ＿ａｓ＿ｐｉｃ＿ｆｌａｇ［ｉ］は１に等しいはずである。

【0246】

実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しく、ピクチャの少なくともＶＣＬＮＡＬユニットがＣＲＡ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合に、ＣＲＡサブピクチャ又はピクチャは、ＣＶＳ開始ピクチャとして扱われなくてもよい。

【0247】

実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しく、ピクチャの少なくともＶＣＬＮＡＬユニットがＣＲＡ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合に、ＣＲＡサブピクチャ又はピクチャに関連した先頭ピクチャが出力され得る。

【0248】

同じ実施形態で、ｍｉｘｅｄ＿ｎａｌｕ＿ｔｙｐｅｓ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しく、ピクチャの少なくともＶＣＬＮＡＬユニットがＣＲＡ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合に、そのピクチャのＨａｎｄｌｅＣｒａＡｓＣｖｓＳｔａｒｔＦｌａｇ及びＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙＦｌａｇは両方とも、０に等しくセットされる。

【0249】

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

【図1】