JP2016523483A - Ｈｅｖｃ拡張のためのレイヤ間パラメータセット - Google Patents

Abstract

ビデオコーディングデバイスは、ビデオデータ処理を提供することができる。ビデオコーディングデバイスは、複数のビデオ表現フォーマットサブセットを受信することができる。複数のビデオ表現フォーマットサブセットは、複数のレイヤに対応することができる。複数のビデオ表現フォーマットサブセットの各々は、１つまたは複数のビデオ表現パラメータ値を含むことができる。ビデオコーディングデバイスは、カレントレイヤと関連付けられたビデオ表現フォーマットサブセットインデックスを受信することができる（例えば、クロスレイヤパラメータセットにおいて）。ビデオコーディングデバイスは、ビデオ表現フォーマットサブセットインデックスを使用して、カレントレイヤと関連付けられたビデオ表現フォーマットサブセットのうちの１つを判定することができる。

Description

本発明は、デジタルビデオ圧縮技術に関する。

関連出願の相互参照
本出願は、２０１３年６月１８日に出願された米国特許仮出願第６１／８３６，５５２号、２０１３年６月１９日に出願された米国特許仮出願第６１／８３７，１１６号、２０１３年６月２７日に出願された米国特許仮出願第６１／８４０，３８０号、および２０１３年７月３０日に出願された米国特許仮出願第６１／８６０，２２１号の利益を主張し、これらの内容は、参照により本明細書に組み込まれている。

デジタルビデオ圧縮技術、例えば、デジタルビデオ通信、配信および／または消費の効率を高める高効率ビデオコーディング（ＨＥＶＣ）が、開発され続けている。従来のデジタルビデオサービス（ＴＶ信号など）と比較すると、ビデオアプリケーションは、異種環境において展開されることがある。そのような異種性は、ネットワーク側だけでなく、クライアント側にも存在することがある。スケーラブルビデオコーディング機構は、ビデオ信号を最高分解能でいったん符号化するために使用されることがあるが、一定のアプリケーションによって必要とされ、および／またはクライアントデバイスによってサポートされる特定のレートおよび分解能に応じて、ストリームのサブセットからの復号を有効にすることがある。

スケーラブルビデオコーディング技術を含むことができるビデオ圧縮技術が提供されて、エンドユーザの経験および／またはサービスの品質を改善することができる。例えば、スケーラブルビデオコーディングは、１または複数のパラメータセットを介して高レベルの構文で実装されてもよい。しかしながら、シグナリングすることができるパラメータセットおよび構文要素は、貴重な通信帯域幅および／または処理リソースを非効率に消費することがある。

ＪＣＴＶＣ−Ｍ１００８，ＳＨＶＣ Ｗｏｒｋｉｎｇ Ｄｒａｆｔ，Ａｐｒｉｌ ２０１３ ＪＣＴＶＣ−Ｍ０４６５，"Ｓｉｇｎａｌｉｎｇ ｏｆ ｐｈａｓｅ ｏｆｆｓｅｔ ｉｎ ｕｐ−ｓａｍｐｌｉｎｇ ｐｒｏｃｅｓｓ ａｎｄ ｃｈｒｏｍａ ｓａｍｐｌｉｎｇ ｌｏｃａｔｉｏｎ"，Ａｐｒｉｌ，２０１３ ＪＣＴＶＣ−Ｍ０２７３，Ｎｏｎ−ＳＣＥ４ Ｓｗｉｔｃｈａｂｌｅ ｆｉｌｔｅｒ ｏｎ ｉｎｔｅｇｅｒ ｐｏｓｉｔｉｏｎ，Ａｐｒｉｌ ２０１３

ビデオデータ処理を実装するためのシステム、方法、および手段（instrumentality）が提供される。ビデオコーディングデバイスは、複数のビデオ表現（representation）フォーマットサブセットを受信してもよい。ビデオコーディングデバイスは、複数のビデオ表現フォーマットサブセットの総計（count）を受信してもよい。複数のビデオ表現フォーマットサブセットは、複数のレイヤに対応してもよい。例えば、複数のビデオ表現フォーマットサブセットの第１のビデオ表現フォーマットサブセットは、第１のレイヤに対応してもよく、および複数のビデオ表現フォーマットサブセットの第２のビデオ表現フォーマットサブセットは、第２のレイヤ、または複数のレイヤに対応してもよい。

複数のビデオ表現サブセットの各々は、１または複数のビデオ表現パラメータ値を含んでもよい。パラメータ値は、輝度サンプル（luma sample）におけるピクチャ幅のインジケーション、輝度サンプルにおけるピクチャ高（picture height）のインジケーション、輝度配列（luma array）の１もしくは複数のサンプルのビット深度のインジケーション、彩度配列（chroma array）の１もしくは複数のサンプルのビット深度のインジケーション、または彩度フォーマットインデックスのインジケーションのうちの少なくとも１つを含んでもよい。

ビデオコーディングデバイスは、カレントレイヤに関連付けられたビデオ表現フォーマットサブセットインデックスを受信してもよい。例えば、ビデオ表現フォーマットサブセットインデックスは、クロスレイヤパラメータセットおよび／またはシーケンスパラメータセット（ＳＰＳ）で受信されてもよい。

ビデオコーディングデバイスは、ビデオ表現フォーマットサブセットインデックスを使用して、カレントレイヤと関連付けられた複数のビデオ表現フォーマットサブセットのうちの１つを判定してもよい。

ビデオ符号化デバイスは、アクティブ参照レイヤの数と複数の直接参照レイヤ（direct reference layer）の数とを比較してもよい。ビデオ符号化デバイスは、アクティブ参照レイヤの数と直接参照レイヤの数との比較に基づいて、アクティブ参照レイヤのインジケーションをスライスレベルヘッダに含めるかを判定してもよい。

ビデオ符号化デバイスは、例えば、アクティブ参照レイヤの数が直接参照レイヤの数と等しくない場合、レイヤ間予測のために使用することができるピクチャのインジケーションを含んでもよい。ビデオ符号化デバイスは、例えば、アクティブ参照レイヤの数が直接参照レイヤの数と等しい場合、レイヤ間予測のために使用することができるピクチャのインジケーションをスキップしてもよい。

ビデオデコーディングデバイスは、１または複数のレイヤを備えるビットストリームを受信してもよい。受信されたビットストリームにおけるアクティブ参照レイヤの数が直接参照レイヤの数と等しくないことを条件に、ビデオデコーディングデバイスは、レイヤ間予測レイヤ構文要素（inter-layer prediction layer syntax element）を受信してもよい。レイヤ間予測レイヤ構文要素は、レイヤ間予測のためにカレントレイヤのカレントピクチャによって使用することができる、参照ピクチャレイヤＩＤのリストを示す。

ビデオデコーディングデバイスは、例えば、アクティブ参照レイヤの数が直接参照レイヤの数と等しい場合、レイヤ間予測レイヤ構文要素を導出してもよい。レイヤ間予測レイヤ構文要素は、カレントレイヤの直接参照レイヤのレイヤＩＤから推測されてもよい。

例示的なレイヤ間パラメータセットを示す構文テーブルである。 例示的なレイヤ間パラメータセットを示す構文テーブルである。 例示的なレイヤ間パラメータセットを示す構文テーブルである。 簡略化されたシーケンスパラメータセットの例を示す構文テーブルである。 簡略化されたシーケンスパラメータセットの例を示す構文テーブルである。 簡略化されたシーケンスパラメータセットの例を示す構文テーブルである。 簡略化されたシーケンスパラメータセット拡張の例を示す構文テーブルである。 レイヤ間パラメータセットからビデオコーディングパラメータおよび／またはビデオデコーディングパラメータを導出する例示的なプロセスを示す図である。 参照ピクチャトリミング（cropping）の例を示す図である。 １または複数の開示される実施形態を実装することができる例示的な通信システムのシステム図である。 図６Ａに示される通信システム内で使用することができる例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図６Ａに示される通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 図６Ａに示される通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。 図６Ａに示される通信システム内で使用することができる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。

例示的な実施形態の詳細な説明は、様々な図を参照しつつ、ここで説明される。この説明は、考えられる実装形態の詳細な例を提供するが、詳細は、例示的であることが意図され、本出願の範囲を決して限定しないことを留意されるべきである。

ビデオコーディングシステムにおいて、クライアントデバイス側では、Ｎのスクリーンシナリオ、すなわち、可変スクリーンサイズおよび／または表示能力を有するデバイス、例えば、スマートフォン、タブレット、ＰＣ、およびＨＤＴＶなどでビデオコンテンツを消費し続けていると予期される。通信ネットワーク側では、ビデオは、インターネット、ＷｉＦｉネットワーク、モバイル通信ネットワーク（例えば、３Ｇ、４Ｇなど）など、またはこれらの任意の組み合わせのうちの１または複数に渡って送信されてもよい。

ユーザ経験（例えば、クライアントデバイスのエンドユーザに対する）および／またはビデオサービスの品質を改善するために、スケーラブルビデオコーディングが実装されてもよい。スケーラブルビデオコーディングで、ビデオ信号は、最高分解能でいったん符号化されてもよい。そのようなビデオ信号は、例えば、特定のアプリケーションによって必要とされ、および／またはクライアントデバイスによってサポートされることがある特定のレートに従って、ビデオ信号に関連付けられた１または複数のビデオストリームの１または複数のサブセットから復号されてもよい。分解能は、空間分解能（ピクチャサイズなどの）、時間分解能（例えば、フレームレート）、ならびにビデオ品質（例えば、ＭＯＳなどの主観的品質、および／またはＰＳＮＲ、ＳＳＩＭもしくはＶＱＭなどの客観的品質）などの１または複数のビデオパラメータを含んでもよい。使用することができる他のビデオパラメータは、彩度フォーマット（例えば、ＹＵＶ４２０、ＹＵＶ４２２、もしくはＹＵＶ４４４）、ビット深度（例えば、８ビットビデオもしくは１０ビットビデオ）、複雑度、ビュー、全領域（gamut）（例えば、色域（color gamut））、および／またはアスペクト比（例えば、１６：９もしくは４：３）を含む。

ビデオ標準は、スケーラビリティモードをサポートすることができるツールおよび／またはプロファイルを含んでもよい。例えば、高効率ビデオコーディングは、スケーラブルビデオコーディングをサポートするように構成されてもよい。ＨＥＶＣに対する例示的なスケーラブル拡張は、空間スケーラビリティ（例えば、スケーラブルビットストリームは、２つ以上の空間分解能においてそれぞれの信号を含んでもよい）、品質スケーラビリティ（例えば、スケーラブルビットストリームは、２つ以上の品質レベルにおいてそれぞれの信号を含んでもよい）、および標準スケーラビリティ（例えば、スケーラブルビットストリームは、Ｈ．２６４／ＡＶＣを使用してコーディングされた基底レイヤと、ＨＥＶＣを使用して符号化された１つもしくは複数の強化レイヤ（enhancement layers）と、を含んでもよい）のうちの１または複数をサポートしてもよい。スケーラブルビデオは、３Ｄビデオへ拡張されてもよい。例えば、マルチビュースケーラビリティが実装されてもよい（例えば、スケーラブルビットストリームは、２Ｄビデオ信号と３Ｄビデオ信号との両方を含んでもよい）。スケーラブルＨＥＶＣ設計の態様は、空間スケーラビリティおよび／または品質スケーラビリティの使用を含んでもよく、例えば、本明細書において説明されるように、本明細書において説明される技法は、１または複数の他のタイプのスケーラビリティに適用されてもよいことが認識されるべきである。

ＨＥＶＣのスケーラブル拡張（ＳＨＶＣ：scalable extensions of HEVC）は、参照インデックスベースのフレームワークに従って実装されてもよい。参照インデックスベースのフレームワークは、そのようなフレームワークを採用するスケーラブルコーディングシステム内で単一レイヤコーデックロジックが再使用されてもよいように、ブロックレベルにおける動作において、および／またはブロックレベルのまま未満での（below block level intact）動作を維持してもよい。参照インデックスベースのフレームワークは、スケーラブルコーデックの設計を簡略化してもよい。そのようなフレームワークは、例えば、高レベル構文シグナリングモジュールおよび／またはレイヤ間処理モジュールを組み込んで、コーディング効率を達成することによって、異なるタイプのスケーラビリティをサポートしてもよい。高レベル構文変更が実装されて、例えば、ＳＨＶＣのレイヤ間処理および／またはマルチレイヤシグナリングをサポートしてもよい。そのような構文変更は、例えば、参照インデックスベースのフレームワークに従って実装されてもよい。

スケーラブルビデオコーディングは、１または複数のレイヤ（例えば、多数のレイヤ）をサポートしてもよい。各々のそのようなレイヤは、空間スケーラビリティ、時間スケーラビリティ、ＳＮＲスケーラビリティ、または他のタイプのスケーラビリティのうちの１または複数を有効にするように設計されてもよい。例えば、スケーラブルビットストリームは、混合されたスケーラビリティレイヤを含んでもよく、１または複数のそれぞれの強化レイヤは、復号されるために、１または複数の下位レイヤに依存してもよい。レイヤ間処理は、レイヤ間参照ピクチャ（ＩＬＲ：inter-layer reference）サンプルおよび／または動きフィールド情報を生成して、例えば、１または複数の強化レイヤの予測精度を高めてもよい。

いくつかのパラメータセットが、ＨＥＶＣ実装に対し、および／または１もしくは複数の対応する拡張に対して指定されてもよい。例えば、ビデオパラメータセット（ＶＰＳ）は、複数のレイヤによって共有することができる、１または複数の構文要素を含んでもよい。ＶＰＳは、ビットストリーム抽出、能力交換（capability exchange）、および／またはセッションネゴシエーションのために使用される情報を含んでもよい（例えば、レイヤの最大数、ならびに／または、プロファイル情報、層（tier）情報、およびレベル情報のうちの１つもしくは複数）。

シーケンスパラメータセット（ＳＰＳ）は、時間間隔にわたる一連のビデオピクチャなどの、コーディングされたビデシーケンスにおける１または複数のコーディングスライス（coded slices）（例えば、全てのコーディングスライス）に共通することができる情報を含んでもよい。そのような情報は、ピクチャ分解能、ビット深度、およびコーディングブロックサイズなどのうちの１または複数を含んでもよい。

ピクチャパラメータセット（ＰＰＳ）は、ピクチャレベル情報を含んでもよい。そのような情報は、初期量子化値、コーディングツール有効フラグ（coding tools enable flags）および／またはコーディングツール無効フラグ（coding tools disable flags）などのうちの１または複数を含んでもよい。ＰＰＳにおいて伝達される情報は、その情報が頻繁に更新されないように、比較的長期間、例えば、複数のピクチャの期間を通じて、変更されないままであってもよい。スライスレベルで変更することができる情報は、スライスヘッダに含まれてもよい。

ＶＰＳ、ＳＰＳおよび／またはＰＰＳなどの、１または複数のパラメータセットは、帯域外（out-of-band）で送信されてもよい（例えば、いくつかの適用シナリオにおけるように、信頼性のあるチャネルを使用して）。高レベル構文設計によって、複数のレイヤが単一のレイヤ（例えば、同一のＳＰＳ）を参照することが可能になる。これは、例えば、マルチビュースケーラビリティおよび／またはＳＮＲスケーラビリティに使用されてもよい。空間スケーラビリティに対し、１または複数のレイヤ（例えば、各レイヤ）は、例えば、異なるビデオ分解能に起因して、それぞれの異なるＳＰＳを参照してもよい。ＳＰＳにおける１または複数のパラメータ（例えば、パラメータの大部分）が複数のレイヤにわたって同一である場合、そのような冗長性を除去することによってビットレートを節約することが望ましいことがある。１または複数のそのようなパラメータは、複数のレイヤの間で共有されてもよい。

ビットレートを節約するための例示的なアプローチにおいて、ＳＰＳごとの予測（SPS to SPS prediction）が実装されてもよく、それは、例えば、基底レイヤおよび／または別の従属レイヤ（dependent layer）のＳＰＳパラメータから、スケーリングリスト、参照ピクチャセット（ＲＰＳ：reference picture set）などの、１または複数の強化レイヤＳＰＳパラメータを予測するために使用されてもよい。そのようなＳＰＳごとの予測は、異なるレイヤ間でパラメータセット従属（parameter set dependency）を導入してもよい。

ビットレートを節約するための別の例において、ＶＰＳごとの予測が実装されてもよぃ、それは、レイヤにわたって１または複数の共有パラメータをＶＰＳに再配置してもよく、ＶＰＳにおける対応するパラメータに基づいて、１または複数の共有ＳＰＳパラメータ（例えば、各レイヤのＳＰＳパラメータ）を予測してもよい。

ＨＥＶＣ拡張のためのＶＰＳ実装および／またはＳＰＳ実装に対する設計基準は、下記のうちの１または複数を含んでもよい。ＶＰＳは、ビットストリーム抽出および／または能力交換のために有益となることがある、１または複数のパラメータを含んでもよい。復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）関連パラメータは、ＶＰＳ拡張に含まれてもよい。

複数のレイヤの間で共有することができる１または複数の高レベル構文要素を集約することができるパラメータセット（例えば、レイヤ間パラメータセット（ＩＰＳ：inter-layer parameter set））が実装されてもよい。１または複数のレイヤ（例えば、各レイヤ）は、１または複数のＩＰＳパラメータを参照してもよく、これは、対応するオーバーヘッドビットを節約することができる。

ＩＰＳは、スケーラブルＨＥＶＣビデオコーディングシステムにおいて提供されてもよい。例えば、ＩＰＳは基底レイヤにおいて伝達されないことがあるため、ＩＰＳのサイズは、基底レイヤサブストリームに影響を及ぼさないことがある。ＩＰＳは、例えば、複数のレイヤにわたる１または複数の共有パラメータの予測を容易にすることによって、高レベルのシグナリング効率を提供することができる。ＩＰＳの実装は、ビデオコーディングシステムにおける構文解析依存（parsing dependency）を除去することができ、なぜなら、例えば、各パラメータの構文解析が別の異なるパラメータセットからの構文解析結果に依拠しないように、異なるパラメータセットに一般的に配置されることがある１または複数のパラメータが、同一のＩＰＳに含まれてもよいからである。

ＩＰＳは、ＩＰＳ ＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄ値が適合ビットストリーム（conforming bitstream）に対してゼロ（０）にならないように、スケーラブルコーディングシステムにおける１または複数の強化レイヤに適用可能であってもよい。例えば、適合ビットストリームは、一（１）に等しい、１または複数のＩＰＳ ＮＡＬユニット（例えば、全てのＩＰＳ ＮＡＬユニット）のｎｕｈ＿ｌａｙｅｒ＿ｉｄを有してもよい。

図１Ａ〜図１Ｃは、例示的なＩＰＳを示す構文テーブルである。図１Ａ〜図１Ｃに示されるように、ＩＰＳは、１または複数のパラメータを含んでもよく、および複数のレイヤをコーディングする目的のために設計されてもよい。そのようなパラメータは、例えば、ｍａｘ＿ｓｕｂｌａｙｅｒ＿ｆｏｒ＿ｉｌｐ＿ｐｌｕｓ１およびｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｔｙｐｅを含んでもよい。１または複数のレイヤが、同一のＲＰＳまたは非常に類似したＲＰＳを共有してもよいため、ＩＰＳは、１または複数のレイヤに関連したＲＰＳを含んでもよい。

類似した目的を果たし、およびＳＰＳに存在してもよい、１または複数のパラメータは、ビデオフォーマットサブセット、コーディングパラメータサブセット、スケーリングリストサブセット（scaling list subset）、スケールドオフセットサブセット（scaled offset subset）、またはＶＵＩサブセットのうちの１または複数を含むことができる、それぞれのサブセットにグループ化されてもよい。ＩＰＳにおいて、１または複数のサブセット（例えば、各サブセット）は、それぞれの複数のパラメータ値を有してもよい。これによって、ＩＰＳおよびサブセット内にインデックス付けすることによって、強化レイヤが複数のパラメータ値を参照することが可能になる。例えば、第１のビデオフォーマットセット（例えば、０）は、７２０ｐフォーマットを指定してもよく、および第２のビデオフォーマットセット（例えば、１）は、１０８０ｐフォーマットを指定してもよい。四（４）レイヤ（例えば、レイヤ０が、７２０ｐレイヤであり、レイヤ１、レイヤ２、およびレイヤ３が、１０８０ｐレイヤである）を有する混合（mixed）空間および／またはＳＮＲスケーラビリティコーディングシステムに対し、基底レイヤ（例えば、レイヤ０）ＳＰＳは、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ（０）を参照してもよく、強化レイヤ（例えば、レイヤ１、レイヤ２、およびレイヤ３）は、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ（１）を参照してもよい。そのような例においては、低減された（例えば、最小の）数の構文要素がシグナリングされて、複数のレイヤによって使用されるパラメータをカバーしてもよい。

下記は、図１Ａ〜図１Ｃに示される例示的なＩＰＳ構文テーブルにおけるエントリに適用されてもよい。構文要素ｉｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、他の構文要素による参照のためのＩＰＳを識別してもよい。構文要素ｎｕｍ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓは、ビデオフォーマット構文構造（ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ）の数を指定してもよい。構文要素ｎｕｍ＿ｃｏｄｉｎｇ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓは、コーディングパラメータ構文構造（ｉｐｓ＿ｃｏｄｉｎｇ＿ｐａｒａｍ＿ｓｕｂｓｅｔ）の数を指定してもよい。構文要素ｎｕｍ＿ｐｃｍ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓは、ＰＣＭコーディングパラメータ構文構造（ｉｐｓ＿ｐｃｍ＿ｐａｒａｍ＿ｓｕｂｓｅｔ）の数を指定してもよい。構文要素ｎｕｍ＿ｓｃａｌｉｎｇ＿ｌｉｓｔ＿ｓｕｂｓｅｔｓは、スケーリングリスト構造（ｉｐｓ＿ｓｃａｌｉｎｇ＿ｌｉｓｔ＿ｓｕｂｓｅｔ）の数を指定してもよい。構文要素ｎｕｍ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔ＿ｓｕｂｓｅｔは、スケールド参照レイヤオフセット構造（ｉｐｓ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔ＿ｓｕｂｓｅｔ）の数を指定してもよい。構文要素ｎｕｍ＿ｖｕｉ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓは、ＶＵＩパラメータ構造（ｉｐｓ＿ｖｕｉ＿ｐａｒａｍ＿ｓｕｂｓｅｔ）を指定してもよい。

１または複数のビデオ表現フォーマットは、サブセットにグループ化されてもよい。１または複数のサブセットは、パラメータセット（例えば、ＩＰＳ）でシグナリングされてもよい。サブセットは、１または複数のレイヤによって参照されてもよい。例えば、第１のレイヤは、第１のサブセットを参照してもよい。１または複数のレイヤは、第２のサブセットを参照してもよい。レイヤの各々は、サブセットのインデックスを参照して、ビデオ表現構文値（video representation syntax values）を導出してもよい。例えば、ＩＰＳでは、ＩＰＳ構文要素をシグナリングするビット（例えば、オーバーヘッドビット）をさらに保存（save）するために、１または複数のサブセットが実装されてもよい。例えば、所与のサブセットの第１のセットのパラメータ値に限定される絶対パラメータ値がシグナリングされてもよい。１または複数の後続のセットのパラメータ値に対し、カレントセット（current set）のパラメータ値と前のセットのパラメータ値との間のそれぞれの差分値がシグナリングされてもよい。例示すために、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ（０）は、７２０ｐフォーマットを示してもよく（ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが、１２８０に設定されてもよく、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが、７２０に設定されてもよい）、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｅｔ（１）は、１０８０ｐフォーマットを示してもよい（ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが、１９２０に設定されてもよく、ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓが、１０８０に設定されてもよい）。１９２０および１０８０の両方をシグナリングするのではなく、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｅｔ（０）とｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｅｔ（１）との間のそれぞれの差分値がシグナリングされてもよい。この例に従って、幅および高さに対するそれぞれの差分値６４０および３６０は、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｅｔ（１）でシグナリングされてもよい。

そのようなＩＰＳの対応する構文テーブルは、図１Ａ〜図１Ｃに示されるようであってもよく、記述子タイプは、例えば、差分値としてシグナリングすることができるパラメータに対し、ｕｃ（ｖ）またはｓｅ（ｖ）へ変更されてもよい。関連するパラメータの値は、下記のように導出されてもよい。

例えば、Ｓ（ｉ）が、所与のサブセットに対するｉ番目のセットのパラメータである場合、変数Ｐ（ｉ，Ｘ）は、ｉ番目のパラメータセットＳ（ｉ）におけるパラメータＸであり、および／または、変数ＰａｒａｍＶａｌｕｅＩｎＩＰＳ（ｉ，Ｘ）は、ＩＰＳにおけるＰ（ｉ，Ｘ）に対してシグナリングされる値である。ｉ番目のパラメータサブセットにおけるパラメータＸの変数ＰａｒａｍＶａｌｕｅ（ｉ，Ｘ）、Ｐ（ｉ，Ｘ）は、（ｉ−１）番目のパラメータサブセットにおけるパラメータＸ、Ｐ（ｉ−１，Ｘ）から、例えば、下記のように導出されてもよい。

ｉｆ（ｉ＝＝０）
ＰａｒａｍＶａｌｕｅ（ｉ，Ｘ）＝ＰａｒａｍＶａｌｕｅＩｎＩＰＳ（ｉ，Ｘ）
ｅｌｓｅ
ＰａｒａｍＶａｌｕｅ（ｉ，Ｘ）＝ＰａｒａｍＶａｌｕｅ（ｉ−１，Ｘ）＋ＰａｒａｍＶａｌｕｅＩｎＩＰＳ（ｉ，Ｘ）

ＳＰＳおよび／またはその拡張は、例えば、それぞれ図２Ａ〜図２Ｃおよび図３に図示されるように簡略化されてもよい。１または複数の強化レイヤに対するＳＰＳにおいて同様の構文要素を伝達するのではなく、強化レイヤＳＰＳ構文テーブルが、例えば、ＩＰＳパラメータセットインデックスへの参照を含めることによって簡略化されてもよい。

ＳＰＳの１または複数の構文要素（例えば、そのような全ての構文要素）は、図２Ａ〜図２Ｃにおける影付きの（shaded）エントリによって表現されるように、基底レイヤ（ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＝０）に対し、そのままの状態で維持されてもよい（kept intact）。これによって、例えば、単一レイヤＨＥＶＣ仕様との後方互換性が可能になる。ＩＰＳの実装に従ってＳＰＳに追加することができる例示的な構文要素は、図２Ａ〜図２Ｃおよび図３においてイタリック体のテキストによって表現されている。

下記は、図２Ａ〜図２Ｃおよび図３に示される簡略化されたＳＰＳ構文テーブルおよび簡略化された拡張構文テーブルにおけるエントリに適用されてもよい。図２Ａ〜図２Ｃおよび図３に示されるように、構文要素ｓｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、アクティブパラメータセット（例えば、ＩＰＳ）のｉｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値を指定してもよい。パラメータセットにおいてシグナリングされる構文要素ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、アクティブパラメータセットに含まれるビデオ表現フォーマット構文構造のリスト内のインデックスを指定してもよい。構文要素ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、このＳＰＳを参照するレイヤに適用することができる表現フォーマット構文構造を指定してもよい。ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。構文要素ｉｐｓ＿ｃｏｄｉｎｇ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、アクティブＩＰＳに含まれるコーディングパラメータ構文構造のリスト内のインデックスを指定してもよい。ｉｐｓ＿ｃｏｄｉｎｇ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｃｏｄｉｎｇ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。ｉｐｓ＿ｓｃａｌｉｎｇ＿ｌｉｓｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、アクティブＩＰＳに含まれるスケーリングリスト構文構造のリスト内のインデックスを指定してもよい。ｉｐｓ＿ｓｃａｌｉｎｇ＿ｌｉｓｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｓｃａｌｉｎｇ＿ｌｉｓｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。ｉｐｓ＿ｐｃｍ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、アクティブＩＰＳに含まれるＰＣＭパラメータ構文構造のリスト内のインデックスを指定してもよい。ｉｐｓ＿ｐｃｍ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｐｃｍ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。ｉｐｓ＿ｖｕｉ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘは、アクティブＩＰＳに含まれるＶＵＩ構文構造のリスト内のインデックスを指定してもよい。ｉｐｓ＿ｖｕｉ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｖｕｉ＿ｐａｒａｍ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。ｉｐｓ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔ＿ｓｕｂｓｅｔ＿ｉｎｄｅｘは、アクティブＩＰＳに含まれるビデオフォーマット構文構造のリスト内のインデックスを指定してもよい。ｉｐｓ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔ＿ｓｕｂｓｅｔ＿ｉｎｄｅｘの範囲は、０より大きく、ｎｕｍ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ未満であってもよい。

これらの例示的な構文構造インデックスによって、例えば、ＩＰＳおよび特定のサブセット内にインデックス付けすることによって、強化レイヤが複数のパラメータ値を導出すことが可能になる。例えば、レイヤ（例えば、強化レイヤ（ＥＬ））のｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓを導出するために、ＥＬは、例えば、所与のＥＬのＳＰＳに存在するＩＰＳ ＩＤ（ｓｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ）によって、関連付けられたアクティブＩＰＳを位置付けてもよい（locate）。ＥＬ ＳＰＳにおけるインデックスｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘの値を使用することによって、ＥＬは、関連付けられたアクティブＩＰＳに存在する特定のビデオフォーマットサブセット、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ（ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ）を位置付けてもよい。ＥＬのｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は、例えば、本明細書において説明される第１の例示的なＩＰＳシグナリング方法に直接従って、ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔ（ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ）に存在するｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの対応するパラメータ値から導出されてもよい。代わりに、ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は、例えば、本明細書において説明される第２の例示的なＩＰＳシグナリング方法に従って、ＰａｒａｍＶａｌｕｅ（ｉｐｓ＿ｖｉｄｅｏ＿ｆｏｒｍａｔ＿ｓｕｂｓｅｔｓ＿ｉｎｄｅｘ，ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ）から導出されてもよい。このＥＬのｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓの値は、同様の方式で導出されてもよい。図４は、ＩＰＳからパラメータを導出するためのそのような例を示す。１または複数の他のパラメータサブセット内の１または複数の他のパラメータの値は、同様の方式で導出されてもよい。

ＩＰＳローバイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）は、１または複数のＳＰＳ ＲＢＳＰによって参照する（refer to）ことができる、１または複数のパラメータを含んでもよい。各ＩＰＳ ＲＢＳＰは、最初は、例えば、復号プロセスの動作の開始時には、アクティブではないとみなされてもよい。例示的な復号プロセスの動作の間、最大で１つのＩＰＳ ＲＢＳＰが、アクティブであるとみなされてもよい。任意のＩＰＳ ＲＢＳＰのアクティブ化は、以前のアクティブＩＰＳ ＲＢＳＰの非アクティブ化をもたらすことがある。

ＩＰＳ ＲＢＳＰが既にアクティブではなく、ＳＰＳ ＲＢＳＰのアクティブ化によって参照される（例えば、ｓｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄが、ｉｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ値と等しい）とき、ＩＰＳ ＲＢＳＰがアクティブ化されてもよい。アクティブ化されたＩＰＳ ＲＢＳＰは、例えば、別のＩＰＳ ＲＢＳＰのアクティブ化の結果として非アクティブ化されるまで、アクティブＩＰＳ ＲＢＳＰと称されてもよい。ＩＰＳ ＲＢＳＰは、ｉｐｓ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｖｉｅｗ＿ｐａｒａｍｅｔｅｒ＿ｓｕｂｓｅｔ＿ｉｄのその特定の値と共に、そのアクティブ化の前に、復号プロセスに利用可能であってもよい。

スライスヘッダは、１つのスライスから他に変化することがある情報と、小さく、またはスライスおよび／もしくはピクチャタイプのうちの一部に対して関連することがあるピクチャ関連情報とを含んでもよい。ビデオコーディング標準、例えば、高効率ビデオコーディング（ＨＥＶＣ）のスケーラブル拡張（ＳＨＶＣ）において、レイヤ間予測のために設計された構文要素は、サンプル予測を含んでもよく、動き予測は、固有の冗長性を有してもよい。スライスヘッダのビットコストは、例えば、いくつかのシグナリングロジックを調整することを通じて、一定の冗長性を除去することによって低減されてもよい。

表１は、ＶＰＳ拡張構文テーブルの例を示す。表２は、ビデオコーディング標準、例えば、ＳＨＶＣにおいて使用されるスライスヘッダ構文の例を示す。

表１に示されるように、ｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇは、例えば、１つのレイヤまたは２つ以上のレイヤからの１または複数のピクチャがスケーラブルシステムにおいてレイヤ間予測のために使用することができるかを特定するために、ＶＰＳ拡張においてシグナリングされてもよい。このフラグは、スケーラブルシステムにおける１つのレイヤからのレイヤ間参照ピクチャを可能にするための制限を課すために使用されてもよい。そのような制限は、スケーラブルプロファイルおよび／またはスケーラブルレベルが定義されるときに望ましいことがある。ｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇの設定に応じて、スライスヘッダ内の構文要素ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１（例えば、表２に示されるような）は、スライスヘッダでシグナリングされてもよく、またはシグナリングされなくてもよい。ｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇが１に等しいとき、ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１は、０になると推測されてもよく、したがって、シグナリングされなくてもよく、１つの参照レイヤのレイヤＩＤが、スライスヘッダでシグナリングされてもよい。そうでない場合（例えば、ｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇが０であるとき）、ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１は、シグナリングされてもよい。（ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１＋１）レイヤのレイヤＩＤは、スライスヘッダにおけるｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１フラグに続いてもよい。

ｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇは、ｍａｘ＿ｎｕｍ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１フラグによって置き換えられてもよい。ｍａｘ＿ｎｕｍ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１フラグの記述子タイプ（descriptor type）は、ｕｅ（ｖ）であってもよい（例えば、表３において示されるような）。構文要素は、能力交換の目的を果たすために復号プロセスにおいて使用することができる最大参照レイヤを示してもよい。適切なプロファイル制限および／またはレベル制限が定義されてもよい。構文要素は、１ビットフラグよりも柔軟（flexible）であってもよい。

ｍａｘ＿ｎｕｍ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０に等しいとき、ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１は、スライスヘッダでシグナリングされなくてもよい（例えば、省略されてもよい）。最大で１つの参照レイヤがレイヤ間予測のために許可される場合、ＶＰＳ拡張におけるそのような構文要素のビットコストは、元のｍａｘ＿ｏｎｅ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒ＿ｆｌａｇと同一であってもよい（例えば、１ビット）。そのような場合において、ビデオデコーディングデバイスは、レイヤ間予測レイヤ構文要素を推測してもよい。表４は、スライスセグメントヘッダの例を示す。

変数ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓは、ｍａｘ＿ｎｕｍ＿ａｃｔｉｖｅ＿ｒｅｆ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１に基づいて導出されてもよい。例えば、変数は、下記のように導出されてもよい。

表４に示されるように、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃは、例えば、アクティブ参照レイヤの数（ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ）が直接参照レイヤの数（例えば、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｎｕｍ＿ｌａｙｅｒ＿ｉｄ］）と同一ではない場合に、シグナリングされてもよい。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃは、例えば、アクティブ参照レイヤの数（ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ）が直接参照レイヤの数（例えば、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｎｕｍ＿ｌａｙｅｒ＿ｉｄ］）と同一である場合、ビットストリームに存在しないことがある。例えば、スライスヘッダ内のｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃは、冗長であることがある。そのような場合において、レイヤ間予測のために使用されるピクチャのインジケーションは、スキップされてもよい。そのような場合において、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃは、疑似コード２に示されるように、ＲｅｆＬａｙｅｒＩｄから導出または予測されてもよい。変数ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓの値は、標準、例えば、ＳＨＶＣにおいて提供されてもよい。

スライスが従属スライス（dependent slice）ではない場合、誤り耐性への考慮のために、スライスヘッダは、ピクチャ内のスライスごとに提供されてもよい。ピクチャが、１または複数のスライスを含むことがあり、スライスヘッダが、スライスごとに提供されることがあるため、スライスヘッダのビットコストは、他のパラメータセット、例えば、ＳＰＳ（シーケンスパラメータセット）、ＰＰＳ（ピクチャパラメータセット）等のビットコストよりも懸念事項となることがある。これらのパラメータセットは、スライスヘッダよりも低頻度で提供されてもよい。

ビデオコーディング標準、例えば、ＳＨＶＣにおいて、ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃおよびｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘなどの変数は、コーディングされたピクチャのスライスごとに同一であってもよい。したがって、同一の構文がピクチャ内でスライスごとに重複しないように、スライスヘッダの代わりに、構文要素、例えば、ＳＰＳ拡張、ＰＰＳ、ＡＰＳまたはＩＰＳにおけるｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅ＿ｆｌａｇ、ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃ、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇ、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｅ＿ｆｌａｇおよびｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘが送信されてもよい。表５は、ＳＰＳ拡張においてシグナリングすることができる構文要素を示す。

他のパラメータセットでシグナリングされるパラメータ値に依存する条件は、例えば、パラメータセット間の構文解析依存を回避するために、構文要素をスライスヘッダからパラメータセットへ再配置するときに修正されてもよい。表５は、関連構文要素がスライスヘッダからＳＰＳ拡張内へ再配置されるときのＳＰＳ拡張構文テーブルの例を示す。

いくつかの適用例において、レイヤ間予測関連シグナリング（例えば、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅ＿ｆｌａｇ、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇなど）は、スライスごとに、またはピクチャごとに、変更されてもよい。そのような適用例の場合、スライスヘッダ内で構文要素を送信することは、望ましくないシグナリングオーバーヘッドを生じさせることがある。フラグは、ＳＰＳ拡張（またはＰＰＳもしくはＩＰＳ）に追加されて、例えば、レイヤ間予測関連構文要素がスライスセグメントヘッダに存在することがあるか否かを示してもよい。表６は、ＳＰＳ拡張においてシグナリングすることができる構文要素の例を示す。表７は、対応するスライスヘッダの例を示す。

１に等しいｓａｍｐｌｅ＿ｐｒｅｄｉｃｔｉｏｎ＿ｐｒｅｓｅｎｔ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅ＿ｆｌａｇ、ｎｕｍ＿ｉｎｔｅｒ＿ｌａｙｅｒ＿ｒｅｆ＿ｐｉｃｓ＿ｍｉｎｕｓ１、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｌａｙｅｒ＿ｉｄｃ、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇなどのレイヤ間サンプル予測関連構文要素がスライスヘッダに存在してもよいことを示してもよい。０に等しいｓａｍｐｌｅ＿ｐｒｅｄｉｃｔｉｏｎ＿ｐｒｅｓｅｎｔ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、関連サンプル予測構文要素がスライスセグメントヘッダに存在しないことがあることを示してもよい。存在しないとき、構文要素の値は、１または複数の変数に基づいて推測されてもよい。例えば、疑似コード３は、どのように構文要素の値が推測されてもよいかの例を提供する。

変数ＮｕｍＳａｍｐｌｅＰｒｅｄＲｅｆＬａｙｅｒｓ、ＮｕｍＳａｍｐｌｅＰｒｅｄＬａｙｅｒｓおよびＳａｍｐｌｅＰｒｅｄＥｎａｂｌｅｄＦｌａｇは、ビデオコーディング標準、例えば、ＳＨＶＣにおいて提供されてもよい。ｓａｍｐｌｅ＿ｐｒｅｄｉｃｔｉｏｎ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが０に等しい場合、サンプル予測構文要素ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙは、０に等しくなるように推測されてもよい。１に等しいｍｏｔｉｏｎ＿ｐｒｅｄｉｃｔｉｏｎ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、レイヤ間動き予測関連構文要素、例えば、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇ、ｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘなどがスライスヘッダに存在してもよいことを示してもよい。０に等しいｍｏｔｉｏｎ＿ｐｒｅｄｉｃｔｉｏｎ＿ｓｌｉｃｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、レイヤ間動き予測関連構文要素が強化レイヤスライスセグメントヘッダに存在しないことがあることを示してもよい。これらの構文要素の値は、１または複数の変数に基づいて推測されてもよい。例えば、疑似コード４は、どのように構文要素の値が推測されてもよいかの例を提供する。ＮｕｍＭｏｔｉｏｎＰｒｅｄＲｅｆＬａｙｅｒｓおよび／またはＭｏｔｉｏｎＰｒｅｄＲｅｆＬａｙｅｒｌｄは、ビデオコーディング標準、例えば、ＳＨＶＣによって提供されてもよい。

疑似コード４に示されるように、少なくとも１つの動き予測参照レイヤが利用可能である場合、（例えば、時間動き情報の代わりに）レイヤ間動き情報が、時間動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）のために使用されてもよい。配置された（collocated）参照レイヤは、現在の強化レイヤに最も近い動き予測参照レイヤに設定されてもよい。他の動き予測参照レイヤは、配置された参照レイヤとして指定されてもよい。例えば、最も近い参照レイヤの代わりに、最下位動き予測参照レイヤ、すなわち、ＭｏｔｉｏｎＰｒｅｄＲｅｆＬａｙｅｒＩｄ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］［０］が、ＴＭＶＰに対するデフォルトの配置された参照レイヤとして使用されてもよい。

１に等しい構文要素ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇは、カレントピクチャを復号するときに、ＥＬにおける時間参照ピクチャを使用するインター予測がかのうでないことがあることを示してもよい。参照ピクチャリストＬ０およびＬ１は、時間参照ピクチャを含まないことがある。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇは、スライスのネットワーク抽出レイヤ（ＮＡＬ：network abstraction layer）ユニットタイプに関わらず、スライスの各々においてシグナリングされてもよい。強化レイヤ（ＥＬ）の瞬時デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャは、時間参照ピクチャを使用する、インター予測なしのピクチャであってもよい。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇは、ＥＬにおけるＩＤＲ ＮＡＬユニットに基づいて判定されてもよい。表８に示されるような条件（例えば、（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ！＝ＩＤＲ＿Ｗ＿ＲＡＤＬ ＆＆ ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ ！＝ＩＤＲ＿Ｎ＿ＬＰ））が、適用されてもよい。

ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇが１に等しいとき、利用可能な参照ピクチャは、レイヤ間参照ピクチャであってもよい。ＳＨＶＣにおいては、レイヤ間参照ピクチャからの動きベクトルがゼロに等しいことがあるため、時間動きベクトル予測（ＴＭＶＰ）は、バイパスされてもよく、ＴＭＶＰに関連するスライスヘッダ内の構文要素の各々は、スキップされてもよい。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇが利用されて、動き予測シグナリングがスキップされてもよい。

ＷＴＲＵは、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇを使用せずに、レイヤ間予測のための参照ピクチャを判定してもよい。例えば、ＷＴＲＵは、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇを受信しないことがあるが、ＷＴＲＵは、レイヤ間予測のために利用することができる参照ピクチャを判定してもよい。ＷＴＲＵによる、例えば、時間予測なしのレイヤ間予測の推測は、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇに依拠しないことがある。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇがビットストリーム内でシグナリングされない（例えば、および／またはＷＴＲＵによって受信されない）場合、ＷＴＲＵは、時間参照ピクチャを推測してもよい。例えば、ＷＴＲＵは、例えば、ＲＰＳを調べる（例えば、ＲＰＳにおけるフラグｕｓｅｄ＿ｂｙ＿ｃｕｒｒ＿ｐｉｃ＿ｆｌａｇ、ｕｓｅｄ＿ｂｙ＿ｃｕｒｒ＿ｐｉｃ＿ｓ０＿ｆｌａｇおよびｕｓｅｄ＿ｂｙ＿ｃｕｒｒ＿ｐｉｃ＿ｓｌ＿ｆｌａｇが０に設定されてもよい）ことによって、時間参照ピクチャがカレントスライスに対して使用されないことを検出してもよい。時間動きベクトル予測（ＴＭＶＰ）プロセスは、例えば、時間参照ピクチャがカレントスライスのコーディングのために使用されない場合、バイパスされてもよい。例えば、他の関連構文要素は、スキップされてもよい（例えば、他の関連構文要素も、スキップされてもよい）。

ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、（例えば、ＳＨＶＣにおいて提供されるような）ｓｐｓ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇおよび／または強化レイヤ（例えば、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＞０）に対するｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇに基づいて、シグナリングされてもよい。表９は、そのようなシグナリングの例を示す。例えば、変数ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、下記のように導出されてもよい。ＮｕｍＳａｍｐｌｅＰｒｅｄＲｅｆＬａｙｅｒｓ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］およびＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓが、０よりも大きい場合、ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、！ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇに等しくなるように設定されてもよい。そうでない場合、ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、１に等しくなるように設定されてもよい。

ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇをｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの条件とするために、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇおよび（例えば、表９に示されるような）サンプル予測構文構造のシグナリングは、ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇに先行して、判定またはシグナリングされてもよい。ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇがシグナリングされない場合（例えば、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇが１に等しく設定されることが理由で）、ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、０に等しくなるように推測されてもよい。

ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０であるとき、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇ、ｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘ、ｃｏｌｌｏｃａｔｅｄ＿ｆｒｏｍ＿１０＿ｆｌａｇおよび／またはｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｉｄｘなどの構文要素は、スキップされてもよい（例えば、表９に示されるように）。

ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇをｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇに先行してシグナリングすることができるシグナリング順序が維持されてもよい。条件（ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇ）は、表１０に示されるように、ＴＭＶＰパラメータをシグナリングするために適用されてもよい。ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇの導出は、ビデオコーディング標準、例えば、ＳＨＶＣにおいて指定されてもよい。変数ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、下記のように導出されてもよい。ＮｕｍＳａｍｐｌｅＰｒｅｄＲｅｆＬａｙｅｒｓ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］が０よりも大きく、ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓが０よりも大きい場合、ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、！ｉｎｔｅｒ＿ｌａｙｅｒ＿ｓａｍｐｌｅ＿ｐｒｅｄ＿ｏｎｌｙ＿ｆｌａｇに等しくなるように設定されてもよい。そうでない場合、ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、１に等しくなるように設定されてもよい。ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値は、下記のように変更されてもよい。ＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇが０に等しい場合、ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、０に等しくなるように設定されてもよい。

時間輝度動きベクトル予測（temporal luma motion vector prediction）のための導出プロセスは、変更されてもよく、変数ｍｖＬＸＣｏｌおよびａｖａｉｌａｂｌｅＦｌａｇＬＸＣｏｌが、導出されてもよい。例えば、ｓｌｉｃｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、０に等しく、またはＩｎｔｅｒＲｅｆＥｎａｂｌｅｄｌｎＲＰＬＦｌａｇは、０に等しく、ｍｖＬＸＣｏｌの成分（例えば、双方の成分）は、０に等しくなるように設定されてもよく、ａｖａｉｌａｂｌｅＦｌａｇＬＸＣｏｌは、０に等しくなるように設定されてもよい。

ビデオコーディングデバイス（例えば、ＳＨＶＣコーディング標準に基づく）は、１または複数の構文要素（例えば、２つの構文要素）、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇおよび／またはｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘをスライスヘッダ内でシグナリングして、レイヤ間動き予測のための参照レイヤを示してもよい。元の時間動きベクトル予測（ＴＭＶＰ）は、構文要素ｃｏｌｌｏｃａｔｅｄ＿ｆｒｏｍ＿ｌＯ＿ｆｌａｇおよびｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｉｄｘを使用して、ＴＭＶＰのために使用される参照ピクチャを示してもよい。同一のシグナリングは、冗長な構文要素ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇおよびｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘがシグナリングされないように（例えば、省略されるように）、レイヤ間動き予測に適用されてもよい。表１１は、例示的な一般的なスライスセグメントヘッダ構文を示す。

ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇおよびｃｏｌｌｏｃａｔｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｉｄｘは、ビデオコーディング標準、例えば、ＨＥＶＣによって提供されてもよい。ＴＭＶＰのために使用されるレイヤ間参照ピクチャのうちのいくつかは、サンプル予測のためには使用されないことがある。参照ピクチャリスト内のレイヤ間参照ピクチャのインデックスが使用されて、ＴＭＶＰのためのレイヤ間配置参照ピクチャが示されてもよい。参照ピクチャリスト内のレイヤ間参照ピクチャのインデックスは、レイヤ間サンプル予測のためには使用されないことがある。レイヤ間参照ピクチャに対応する参照インデックスは、強化レイヤピクチャの予測ブロックによっても参照されないことがあるというビットストリーム制限が課されてもよい。

ＳＮＲスケーラビリティをシグナリングするためのシステムおよび／または方法が、提供されてもよい。そのようなシステムおよび／または方法において、そのようなシグナリングは、異なるスケーラビリティ間で区別してもよい。例えば、空間スケーラビリティは、ＳＮＲスケーラビリティとは区別されてもよく、その逆もまた同様である。例示的な実施形態において、インジケータ、フラグ、または他の識別子もしくは情報は、ＳＮＲスケーラビリティと空間スケーラビリティとを区別してもよい。また、ＳＮＲスケーラビリティインジケータなどのインジケータに基づいて、そのようなシグナリングは、（例えば、サンプルのための）再サンプリングプロセスおよび／または動き予測を呼び出し、または実行するべきかを示してもよい。

本明細書において説明されるように、ＭＰＥＧ−２ Ｖｉｄｅｏ、Ｈ．２６３、ＭＰＥＧ４ ＶｉｓｕａｌおよびＨ．２６４などの既存の国際ビデオ標準の各々は、スケーラビリティモードをサポートするツールおよび／またはプロファイルを含んでもよく、または有してもよい。しかしながら、ＨＥＶＣは、それらの既存の標準によってサポートすることができるそのようなスケーラブルコーディングを現在はサポートしていないことがある。そのため、ＨＥＶＣは、拡張されて、下記のうちの少なくとも１つを含むそのようなスケーラビリティコーディングをサポートしてもよい：空間スケーラビリティ（すなわち、スケーラブルビットストリームが、２つ以上の空間分解能においてシグナリングしてもよい）、品質スケーラビリティ（すなわち、スケーラブルビットストリームが、２つ以上の品質レベルにおける信号を含んでもよい）、および標準スケーラビリティ（すなわち、スケーラブルビットストリームが、Ｈ．２６４／ＡＶＣを使用してコーディングされた基準レイヤと、ＨＥＶＣを使用してコーディングされた１または複数の強化レイヤとを含む）。例示的な実施形態において、ＨＥＶＣによってサポートされてもよい品質スケーラビリティは、ＳＮＲスケーラビリティも含んでもよい。また、今日では３Ｄビデオがより人気を得るにつれて、スケーラビリティの付加的な拡張（例えば、２Ｄビデオ信号および／または３Ｄビデオ信号を含むスケーラブルビットストリーム）が、（例えば、ＭＰＥＧにおいて説明または定義されているように）さらに提供され、および／または使用されてもよい。

ＨＥＶＣのスケーラブル拡張およびマルチビュー拡張に対する共通仕様は、ＨＥＶＣのスケーラブル拡張（ＳＨＶＣ）のための参照インデックスベースフレームワークを含んでもよい。そのようなフレームワークにおいて、ＳＨＶＣについての構文、意味（semantics）および復号プロセスが提供されてもよい。参照インデックスベースのフレームワークは、既存の単一レイヤコーデックロジックがスケーラブルコーディングシステム内で再利用されてもよいように、ブロックレベルおよびブロックレベル未満の１または複数の動作をそのままの状態に維持してもよい。フレームワークは、スケーラブルコーデック設計を簡略化してもよく、また、高レベル構文シグナリングおよびレイヤ間処理モジュールを組み込んで、コーディング効率を達成することによって、異なるタイプのスケーラビリティをサポートするようにさらに柔軟になることがある。様々な新たな高レベル構文変化が提供されてもよく、および／またはＳＨＶＣのレイヤ間処理およびマルチレイヤシグナリングがサポートされてもよい。

ＨＥＶＣにおいてそのようなスケーラビリティをシグナリングするために、本明細書において説明されるようなシステムおよび／または方法が提供されてもよい。例えば、空間スケーラビリティは、ＳＮＲスケーラビリティとは区別されてもよく、その逆もまた同様である。例示的な実施形態において、インジケータ、フラグ、または他の識別子もしくは情報は、ＳＮＲスケーラビリティと空間スケーラビリティとを区別してもよい。また、ＳＮＲスケーラビリティインジケータなどのインジケータに基づいて、そのようなシグナリングは、（例えば、サンプルのための）再サンプリングプロセスおよび／または動き予測を呼び出し、または実行するべきかを示してもよい。

スケーラブルビデオコーディングは、複数のレイヤをサポートしてもよく、各レイヤは、空間スケーラビリティ、時間スケーラビリティ、ＳＮＲ（信号対雑音比）スケーラビリティ、および／または任意の他のタイプのスケーラビリティをサポートしてもよい。スケーラブルビットストリームは、混合されたスケーラビリティレイヤを有してもよく、各強化レイヤは、復号されることになる１または複数の下位レイヤに依存してもよい。レイヤ間プロセスは、レイヤ間参照ピクチャ（ＩＬＲ）サンプルおよび／または動きフィールド情報を生成して、強化レイヤコーディング効率を強化または改善してもよい。

ＳＮＲスケーラビリティシグナリングが、提供および／または使用されてもよい。空間スケーラビリティに対し、ビデオは、異なる分解能において、および異なるレイヤにおいてコーディングされてもよい。例えば、基準レイヤビデオは、７２０ｐ分解能を有し、強化レイヤは、１０８０ｐ分解能を有してもよい。また、ＳＮＲスケーラビリティについて、ビデオ分解能は、複数のレイヤにわたって同一であってもよいが、異なるレイヤは、異なる品質でコーディングされてもよい。例えば、基準レイヤは、３３ｄＢでコーディングされてもよいのに対して、強化レイヤは、３６ｄＢでコーディングされてもよい。ＳＨＶＣにおいて、ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋなどの構文要素は、パラメータセット（例えば、ビデオパラメータセット（ＶＰＳ））に含まれて、（表１２に示されるように）マルチビュースケーラビリティと空間／ＳＮＲスケーラビリティとが区別されてもよい。

しかしながら、現在、ＳＨＶＣにおいて、ｓｃａｌａｂｉｌｉｔｙ＿ｍａｓｋ構文は、空間スケーラビリティとＳＮＲスケーラビリティとを区別しないことがある。例えば、空間スケーラビリティおよびＳＮＲスケーラビリティは、異なるコーデック動作およびメモリ割り当てを使用することができる、２つの異なる種類のスケーラビリティであってもよい。こうした相違点のいくつかの例は、下記の通りである。参照レイヤピクチャサンプルおよび参照レイヤ動きフィールドに対する再サンプリングプロセスは、空間スケーラビリティについては使用されてもよいが、ＳＮＲスケーラビリティについては使用されないことがある。また、固定代替再サンプリングフィルタ（fixed alternative resampling filter）（例えば、コア実験ＳＣＥ３において評価される）などのいくつかのレイヤ間フィルタは、ＳＮＲスケーラビリティに対して改善された性能利得を達成してもよいが、空間スケーラビリティに対しては適用可能ではないことがある。適用例は、単ループ設計（例えば、ＳＶＣ、Ｈ．２６４のスケーラブル拡張によってサポートされてきたことがある）をＳＮＲスケーラビリティについては使用してもよいが、空間スケーラビリティについては使用しなくてもよい。サンプリンググリッド（sampling grid）（例えば、現在、コア実験ＳＣＥ１が行われている）は、空間スケーラビリティに関連する特定の問題に対処してもよいが、ＳＮＲスケーラビリティに関連する特定の問題には対処しなくてもよい。

エンコーダ動作およびデコーダ動作が、サポートすることができる関連コーディングツールに従って構成および／または初期化されてもよいように、高レベル構文において空間スケーラビリティとＳＮＲスケーラビリティとを区別することができるシステム、方法、および手段が、本明細書において説明される。

例えば、現在、ＳＨＶＣにおいて、ＳＮＲスケーラビリティは、再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４において説明される再サンプリングプロセスなどの）において指定することができるＳｃａｌｅＦａｃｔｏｒＸなどのスケールファクタから推測されてもよい。ＳｃａｌｅＦａｃｔｏｒＸが１に等しい場合、スケーラビリティは、ＳＮＲスケーラビリティであってもよい。スケーラビリティは、ＳＰＳおよびＳＰＳ拡張を構文解析した後に、導出されてもよい。冗長なコーデック動作ならびにメモリ割り当ておよび／またはメモリアクセスが低減または回避されるように（例えば、構文解析を回避することによって）、ＳＮＲスケーラビリティのシグナリングおよび再サンプリングプロセスに対処するために、他のシグナリングオプションが提供されてもよい。

別々のスケーラビリティ次元が、空間スケーラビリティとＳＮＲスケーラビリティとに割り当てられて、例えば、空間スケーラビリティとＳＮＲスケーラビリティとの間で区別してもよい。表１３は、空間スケーラビリティおよびＳＮＲスケーラビリティが別個または別々の値を有することができる、変形されたスケーラビリティディメンションテーブルの例示的な実施形態を示す。

表１３に示されるように、ＶｉｅｗＩｄおよびＤｅｐｅｎｄｅｎｃｙＩｄに加えて、変数ＳｎｒＩｄ［ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］］が、ｉ番目のレイヤのＳＮＲ識別子として提供および／または使用されてもよい。例示的な実施形態によれば、ＳｎｒＩｄは、下記のように導出されてもよい。

加えて、例えば、空間スケーラビリティとＳＮＲスケーラビリティとを区別するために、ＳＮＲスケーラビリティフラグが、提供および／または使用されてもよい。例えば、ＳＮＲスケーラビリティフラグは、パラメータセット拡張（例えば、ビデオパラメータセット（ＶＰＳ）拡張）に追加されて、表１４に示されるようなＳＮＲスケーラビリティを示してもよい。

例示的な実施形態に従って、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが１に等しい場合、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｊ］に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤ間のスケーラビリティは、ＳＮＲスケーラビリティを指定してもよく、または示してもよい。ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが０に等しい場合、ｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｉ］に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｌａｙｅｒ＿ｉｄ＿ｉｎ＿ｎｕｈ［ｊ］に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤ間のスケーラビリティは、ＳＮＲスケーラビリティではないことがある（例えば、ＳＮＲスケーラビリティを指定しないことがあり、または示さないことがある）。また、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが提供されない場合、それは、０に等しくなるように予測されてもよい。

本明細書において説明されるように、復号は、例えば、再サンプリングプロセスの一部として実行されてもよい。例示的な再サンプリングプロセスに関連付けられた復号処理は、下記のように実行されてもよい。ＰｉｃＷｉｄｔｈｌｎＳａｍｐｌｅｓＬがＲｅｆＬａｙｅｒＰｉｃＷｉｄｔｈｌｎＳａｍｐｌｅｓＬに等しく、ＰｉｃＨｅｉｇｈｔｌｎＳａｍｐｌｅｓＬがＲｅｆＬａｙｅｒＰｉｃＨｅｉｇｈｔｌｎＳａｍｐｌｅｓＬに等しく、ＳｃａｌｅｄＲｅｆＬａｙｅｒＬｅｆｔＯｆｆｓｅｔ、ＳｃａｌｅｄＲｅｆＬａｙｅｒＴｏｐＯｆｆｓｅｔ、ＳｃａｌｅｄＲｅｆＬａｙｅｒＲｉｇｈｔＯｆｆｓｅｔおよび／またはＳｃａｌｅｄＲｅｆＬａｙｅｒＢｏｔｔｏｍＯｆｆｓｅｔの値の各々が０に等しい場合、例えば、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しくなることがあるとき、ｒｓＰｉｃＳａｍｐｌｅは、ｒｌＰｉｃＳａｍｐｌｅに設定されてもよく、ｒｓＰｉｃＭｏｔｉｏｎは、ｒｌＰｉｃＭｏｔｉｏｎに等しくなるように設定されてもよい。ｒｓＰｉｃは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．１項で指定されるような）は、入力としてｒｌＰｉｃＳａｍｐｌｅのサンプル値で、および、出力としてｒｓＰｉｃＳａｍｐｌｅの再サンプリングされたサンプル値で呼び出されてもよい。ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しい場合、ピクチャ動きフィールド再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．２項で指定されるような）は、入力としてｒｌＰｉｃＭｏｔｉｏｎで、および、出力としてｒｓＰｉｃＭｏｔｉｏｎの再サンプリングされた動きフィールドで呼び出されてもよい。

本明細書において説明されるＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇを使用して、例示的な再サンプリングプロセスは、下記のように提供されてもよい。例えば、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが１に設定される場合、ｒｓＰｉｃＳａｍｐｌｅは、ｒｌＰｉｃＳａｍｐｌｅに等しくなるように設定されてもよい。また、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しくすることができるとき、かつ、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが１に設定される場合、ｒｓＰｉｃＭｏｔｉｏｎは、ｒｌＰｉｃＭｏｔｉｏｎに設定されてもよい。ｒｓＰｉｃは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．１項において指定されるような）は、入力としてのｒｌＰｉｃＳａｍｐｌｅのサンプル値で、および出力してのｒｓＰｉｃＳａｍｐｌｅの再サンプリングされたサンプル値で呼び出されてもよい。ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しくなることができるとき、ピクチャ動きフィールド再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．２項において指定されるような）は、入力としてのｒｌＰｉｃＭｏｔｉｏｎで、および、出力としてのｒｓＰｉｃＭｏｔｉｏｎの再サンプリングされた動きフィールドで呼び出されてもよい。

例示的な実施形態において、１または複数の例外が、提供されてもよく、および／または存在してもよい。１つのそのような例外は、基底レイヤ（ＢＬ：base layer）をＡＶＣコーディングすることができるハイブリッド標準スケーラビリティを含んでもよく、またはハイブリッド標準スケーラビリティであってもよい。ビデオコーディングサイズは、ＨＥＶＣ ＥＬとＡＶＣ ＢＬとの間で異なってもよい。例えば、ＡＶＣ基底レイヤ（ＢＬ）およびＨＥＶＣ強化レイヤ（ＥＬ）の両方が１９２０×１０８０ビデオを符号化してもよい場合、復号されたＢＬ参照ピクチャサイズは、１９２０×１０８８となってもよく、強化コーディングピクチャサイズは、１９２０×１０８０となってもよい（例えば、これは、ＡＶＣ標準およびＨＥＶＣ標準が異なるパディングプロセスを適用するためである）。輝度サンプルおよび／または彩度サンプルの再サンプリングは必要ではないことがあるが、復号された参照ピクチャ（１９２０×１０８８）は、ＥＬピクチャ（１９２０×１０８０）を予測するために直接使用されないことがあり、対応するトリミングされた領域は、ＩＬＲピクチャ内へコピーされてもよい。

そのような例外に対処するために、本明細書において説明されるように使用することができる複数の方法が存在する。例えば、方法において、１または複数のスケーリングされたオフセットの値に関わらず、ＢＬビデオコーディングサイズとＥＬビデオコーディングサイズとが同一とすることができるとき、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、１に制限されてもよい。そのような制限は、ビットストリーム適合制限（bitstream conformance restriction）の形式において提供されてもよく、および／または課されてもよく、エンコーダがＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇの値を適切に設定することができることを保証してもよい。その場合において、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、上記の１９２０×１０８０ハイブリッド標準スケーラビリティに対しては０に設定されてもよく、レイヤ間参照ピクチャは、再サンプリングプロセス（例えば、非特許文献１のＳＨＶＣ ＷＤ Ｇ．８．１．４．１において指定されるように）に従って、１９２０×１０８８ＡＶＣ基準レイヤピクチャから導出されてもよい。

方法において、スケールファクタＳｃａｌｅＦａｃｔｏｒＸ（例えば、Ｇ．８．１．４．において指定されるような）が０に等しくなることができるとき、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、１に設定される。そのような方法において、再サンプリングプロセスは、さらに変形されて、下記のような特別なケースをカバーしてもよい。ｒｌＰｉｃおよびｒｓＰｉｃ（例えば、ＳＨＶＣ ＷＤ Ｇ．８．１．４において定義されるような）に加えて、別のトリミングされた参照レイヤピクチャｒｃＰｃが、再サンプリングプロセスに追加されてもよい。変数ＣｒｏｐｐｅｄＲｅｆＬａｙｅｒＰｉｃＷｉｄｔｈｉｎＳａｍｐｌｅｓＬおよびＣｒｏｐｐｅｄＲｅｆＬａｙｅｒＰｉｃＷｉｄｔｈｉｎＳａｍｐｌｅｓＬは、Ｐｉｃの幅および高さと輝度サンプルの単位でそれぞれ等しくなるように設定されてもよい。変数ｒｃＰｉｃＳａｍｐｌｅは、輝度成分および彩度成分のｒｃＰｉｃのサンプル値を指定するサンプルアレイのグループとしてさらに定義されてもよい。また、ｒｃＰｉｃＭｏｔｉｏｎは、ｒｃＰｉｃの圧縮された動きフィールドを指定する可変アレイ（variable array）のグループとして定義されてもよい。

変数ＲｅｆＬａｙｅｒＰｉｃＷｉｄｔｈｌｎＳａｍｐｌｅｓＬおよびＲｅｆＬａｙｅｒＰｉｃＨｅｉｇｈｔｌｎＳａｍｐｌｅｓＬは、復号された参照レイヤピクチャｒｌＰｉｃの幅および高さ、ならびに輝度サンプルの単位においてそれぞれ等しくなるように設定される。輝度サンプル位置［ｘＰ］［ｙＰ］は、ｒｌＰｉｃの左上のサンプルを指定してもよい。また、変数ｒｃＬｅｆｔＳｔａｒｔ、ｒｃＲｉｇｈｔＥｎｄ、ｒｃＴｏｐＳｔａｒｔおよびｒｃＢｏｔｔｏｍＥｎｄは、下記のように導出されてもよい。

ｒｃＰｉｃは、左上位置（ｒｃＬｅｆｔＳｔａｒｔ，ｒｃＴｏｐＳｔａｒｔ）および右下位置（ｒｃＲｉｇｈｔＥｎｄ，ｒｃＢｏｔｔｏｍＥｎｄ）でｒｌＰｉｃをトリミングすることによって導出されてもよい。図５は、トリミングの例を示す。図５に示されるように、ｒｃＰｉｃは、スケーリングされたオフセットがゼロではないことがあるときに、ｒｌＰｉｃから導出されてもよい。

再サンプリングプロセスは、下記のように提供されてもよい。ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇを１に設定することができる場合、ｒｓＰｉｃＳａｍｐｌｅは、ｒｃＰｉｃＳａｍｐｌｅと等しくなるように設定されてもよく、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇを１に等しくすることができるとき、ｒｓＰｉｃＭｏｔｉｏｎは、ｒｃＰｉｃＭｏｔｉｏｎに等しく設定されてもよい。ｒｓＰｉｃは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．１項において指定されるような）は、入力としてのｒｌＰｉｃＳａｍｐｌｅのサンプル値、および出力としてのｒｓＰｉｃＳａｍｐｌｅの再サンプリングされたサンプル値で呼び出されてもよい。ピクチャ動きフィールド再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．２項において指定されるような）は、例えば、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しいとき、入力としてのｒｌＰｉｃＭｏｔｉｏｎ、および出力としてのｒｓＰｉｃＭｏｔｉｏｎの再サンプリングされた動きフィールドで呼び出されてもよい。

空間スケーラビリティおよびＳＮＲスケーラビリティは、例えば、不要な再サンプリング動作および／またはメモリ割り当てを回避するために区別されてもよい。付加的または追加的な構文要素は、パラメータセット拡張（例えば、表１５に示されるような、ビデオパラメータセット（ＶＰＳ）拡張）においてシグナリングされて、再サンプリングプロセスをバイパスすることができるか否かを示してもよい。

０に等しくすることができるｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇ［ｉ］［ｊ］は、ｉ番目のレイヤとｊ番目のレイヤとの間の再サンプリングプロセスをバイパスすることができ、および再サンプリングバッファが割り当てられな九手も良いことを示し、または指定してもよい。１に等しくすることができるｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、ピクチャサンプルまたは動き値の再サンプリングプロセスに対する関連するバッファを呼び出すことができることを示し、または指定してもよい。ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇが存在しないことがあるとき、デフォルト値は０であってもよい。再サンプリングプロセスは、下記のように修正されてもよい。ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇが０に設定されてもよい場合、ｒｓＰｉｃＳａｍｐｌｅは、ｒｌＰｉｃＳａｍｐｌｅに等しく設定されてもよく、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しくなることがあるとき、ｒｓＰｉｃＭｏｔｉｏｎは、ｒｌＰｉｃＭｏｔｉｏｎに等しくなるように設定されてもよい。ｒｓＰｉｃは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．１項において指定されるような）は、入力としてのｒｌＰｉｃＳａｍｐｌｅのサンプル値、および出力としてのｒｓＰｉｃＳａｍｐｌｅの再サンプリングされたサンプル値で呼び出されてもよい。また、ａｌｔ＿ｃｏｌｌｏｃａｔｅｄ＿ｉｎｄｉｃａｔｉｏｎ＿ｆｌａｇが１に等しいことがあるとき、ピクチャ動きフィールド再サンプリングプロセス（例えば、非特許文献１のＧ．８．１．４．２項において指定されるような）は、入力としてのｒｌＰｉｃＭｏｔｉｏｎ、および出力としてのｒｓＰｉｃＭｏｔｉｏｎの再サンプリングされた動きフィールドで呼び出されてもよい。

ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、ｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｔｙｐｅ構文要素とは結合されなくてもよい。ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、表１７に示されるようにシグナリングされてもよい（例えば、独立してシグナリングされてもよい）。ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、再サンプリングされた参照ピクチャおよび動きをサンプル予測および／または動き予測以外の目的のために使用することができるように、柔軟性を与えることができる。例えば、再サンプリングされた動きは、ハイブリッドレイヤ間参照ピクチャが生成するために使用されてもよい。

ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、ｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｔｙｐｅ構文要素と結合されなくてもよい。ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇとしてシグナリングされてもよく（例えば、独立してシグナリングされてもよい）、ｒｅｓａｍｐｌｉｎｇ＿ｂｕｆｆｅｒ＿ｅｎａｂｌｅ＿ｆｌａｇは、ＳＰＳもしくはＳＰＳ拡張または任意の他の適当なパラメータセットで配置されてもよい。表１７は、ＳＰＳ拡張においてＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇをシグナリングする例示的な実施形態を示す。表１７に示されるような構文要素ｎｕｍ＿ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、シグナリングされるフラグの数を示してもよい。ｎｕｍ＿ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇの値は、現在の強化レイヤの参照レイヤの数と等しくてもよい。ｎｕｍ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔｓの値は、現在の強化レイヤの参照レイヤの数と等しくてもよい。表１９に示されるように、構文要素ｎｕｍ＿ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇおよびｎｕｍ＿ｓｃａｌｅｄ＿ｒｅｆ＿ｌａｙｅｒ＿ｏｆｆｓｅｔｓは、１つの構文要素、例えば、ｎｕｍ＿ｒｅｆ＿ｌａｙｅｒｓとして組み合わされ、およびシグナリングされてもよい。

本明細書において説明されるようなＳＮＲスケーラビリティシグナリングで、コーデック動作は、１または複数の構文要素をシグナリングして、シグナリングされるビットの数を節約し、それによって、効率を向上させることができる。例えば、本明細書において説明されるようなＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ（例えば、上述されたようにＶＰＳ拡張に追加されてもよい）は、様々な適用シナリオにおいて使用されてもよい。

例えば、サンプリンググリッドシフトシグナリング（sampling grid shift signaling）が、例えば、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇと共に、提供および／または使用されてもよい。サンプリンググリッドシフト情報は、様々な技法および／または方法（例えば、非特許文献２において提案されるような）を使用してサンプリングされてもよい。例えば、サンプリンググリッド情報は、フェーズオフセット存在フラグ（phase offset present flag）ならびに輝度フェースオフセットパラメータおよび／または彩度フェースオフセットパラメータで、ＳＰＳ拡張においてシグナリングされてもよい。サンプリングフェーズシフトは、空間スケーラビリティに適用可能であるため、提案されるＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、ＳＮＲスケーラビリティについてのビットストリーム内に存在する不要な構文要素を回避するための条件として使用されてもよい。表１８は、追加的なサンプリンググリッドパラメータをシグナリングすることができるかを判定するための条件として、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇシグナリングを使用することができる例示的な構文テーブルを示す。

スケーリングされた参照レイヤオフセットがまた、提供および／または使用されてもよい。例えば、ＳＰＳ拡張においてシグナリングすることができるスケーリングされた参照レイヤオフセット構文要素は、基準レイヤおよび強化レイヤを調節するために使用されてもよい。ＳＮＲスケーラビリティでは、スケーリングされたオフセットはゼロであってもよく、そのため、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇをこれらのオフセットのシグナリングの条件とすることによって、追加的なビットは、ＳＮＲスケーラブルレイヤに対してスケーリングされたオフセットシグナリングをスキップすることによって節約されてもよい。表１９は、そのようなシグナリングの例を示す。

ｎｕｍ＿ｒｅｆ＿ｌａｙｅｒｓの意味（semantic）は、ＳＰＳに存在することができるスケーリングされた参照レイヤオフセットパラメータのセットの数を指定することができるＶＰＳにおいてシグナリングすることができる従属レイヤ（例えば、参照レイヤ）の数と一致させるには正確ではないことがある。一実施形態において、ｎｕｍ＿ｒｅｆ＿ｌａｙｅｒｓの値は、０〜６３を含む範囲になってもよい。意味は、下記のように修正されてもよい。ｎｕｍ＿ｒｅｆ＿ｌａｙｅｒｓは、ＳＰＳに存在することができるスケーリングされた参照レイヤオフセットパラメータのセットの数を指定してもよく、または示してもよい。ｎｕｍ＿ｒｅｆ＿ｌａｙｅｒｓの値は、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］（例えば、ビットストリーム適合制限の一部としての、また、非特許文献１のＦ．７．４．３．１．１において指定されるような）に等しくてもよい。

レイヤ間フィルタリングシグナリングが、提供および／または使用されてもよい。例えば、切り替え可能な整数位置フィルタ（switchable integer position filter）（例えば、レイヤ間フィルタリングに関するコア実験（ＳＣＥ３）において提供することができる非特許文献３において説明されるフィルタなどの）は、ＳＮＲスケーラビリティについては性能利得を達成してもよいが、空間スケーラビリティについては達成しないことがある。そのため、様々なフィルタ切り替え方法が、提供および／または使用されてもよい。例えば、フィルタ切り替えは、スライスヘッダにおいてシグナリングされてもよく、また、追加的な実施形態においては、ＩＬＲとフィルタリングされたＩＬＲとの両方が、レイヤ間予測のための参照ピクチャリスト（ＲＰＬ）内に挿入されてもよい。例えば、スライスヘッダにおける１ビット構文要素は、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが０に設定されるときに、バイパスされてもよく、それは、そのようなフィルタは、空間スケーラビリティシナリオについての性能を改善しないことがあるためである。別の例において、ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇが０に設定されるとき、アクティブレイヤ間参照ピクチャの数が低減されてもよく、それは、例えば、フィルタリングされたＩＬＲピクチャは、参照ピクチャセットおよび参照ピクチャリスト内も追加されないことがあるためである。ＳＮＲスケーラビリティインジケータをシグナリングすることは、参照ピクチャリスト構築プロセスを簡略化し、空間スケーラビリティケースについて、ＤＰＢメモリサイズを事前に節約することができる。ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、再サンプリングプロセスにおいて参照されて、空間スケーラビリティ（ＳＮＲ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは０に設定される）についての切り替え可能な整数位置フィルタ（例えば、非特許文献３において説明されるフィルタなどの）をバイパスして、コーデック動作複雑度およびメモリ割り当てを低減してもよい。

複数のフラグが、パラメータセット（例えば、ビデオパラメータセット）においてシグナリングされてもよい。フラグの各々は、スケーラブルビットストリームのレイヤ（例えば、基準レイヤおよび従属強化レイヤ）に関連付けられた再サンプリングプロセスが実行される必要があるかを示してもよい。再サンプリングプロセスが必要とされないことをフラグが示すことを条件に、再サンプリングバッファの割り当てがバイパスされてもよい。再サンプリングプロセスが必要とされることをフラグが示すことを条件に、１または複数の再サンプリングバッファが割り当てられてもよく、参照ピクチャサンプルに関連付けられた参照ピクチャサンプルまたは動きのうちの１つまたは複数の再サンプリングが呼び出されてもよい。

本明細書において説明されるシグナリングは、例えば、本明細書において説明されるネットワークまたは適切なネットワーク要素のうちのいずれかにおいて使用されてもよい。例えば、本明細書において説明されるシグナリングは、図６Ａ〜図６Ｅに示される例示的な無線通信システム１００および／またはその構成要素などの無線通信システムに関連付けられたデバイス（例えば、ビデオストリーミングデバイス）によって実装されるスケーラブルビデオコーディングに従って、実装されてもよい。

図６Ａは、１または複数の開示された実施形態を実装および／または使用することができる例示的な通信システム１００の図を示す。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザへ提供する多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、そのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセス方法を採用してもよい。

図６Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（これらは、一般に、または、まとめて、ＷＴＲＵ１０２と称されてもよい）と、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５と、コアネットワーク１０６／１０７／１０９と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定することを認識されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄの各々は、無線環境において動作および／または通信するように構成された、任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定加入者ユニットまたは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのうちの少なくとも１つと無線でインターフェースして、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってもよい。例として、基地局１１４ａおよび／または１１４ｂは、基地送受信局（ＢＴＳ）、ノードＢ、ｅＮｏｄｅＢ、ホームノードＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってもよい。基地局１１４ａ、１１４ｂの各々は、単一の要素として示されるが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことを認識されるであろう。

基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってもよく、これは、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどの他の基地局および／またはネットワーク要素（図示せず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されてもよい特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、１つの実施形態において、基地局１１４ａは、３つの送受信器、すなわち、セルのセクタごとに１つの送受信器を含んでもよい。別の実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ：multiple-input multiple output）技術を採用してもよく、したがって、セルのセクタごとに複数の送受信器を利用してもよい。

基地局１１４ａおよび／または１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのうちの１または複数と、エアインターフェース１１５／１１６／１１７上で通信してもよい。これは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光等）であり得る。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ：radio access technology）を使用して確立されてもよい。

より具体的には、上述されたように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。これは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１５／１１６／１１７を確立してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態において、基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、進化型ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。これは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立してもよい。

他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、ＩＥＥＥ８０２．１６（Ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ)、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

図１０Ａにおける基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、職場、家庭、車両、キャンパスなどの局所的なエリアにおける無線接続性を容易にするために任意の適切なＲＡＴを利用してもよい。一実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。また別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＥＴ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図６Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０へアクセスすることを必要とされないことがある。

ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信していることがあってもよく、これは、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのうちの１または複数へ提供するように構成された、任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド電話、インターネット接続性、ビデオ配信等を提供し、ユーザ認証などの高レベルのセキュリティ機能を実行してもよい。図６Ａには示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接通信または間接通信していることがあってもよいことを認識されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用中であり得るＲＡＮ１０３／１０４／１０５に接続されることに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）とも通信していることがあってもよい。

コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのためのゲートウェイとしての機能も果たしてもよく、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２へアクセスしてもよい。ＰＳＴＮ１０８は、旧来型電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル（ＩＰ）などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線通信ネットワークまたは無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用してもよい１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのうちの一部または全部は、マルチモード能力を含んでもよい。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信器を含んでもよい。図６Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用してもよい基地局１１４ａと、ＩＥＥＥ８０２無線技術を採用してもよい基地局１１４ｂと通信するように構成されてもよい。

図６Ｂは、例示的なＷＴＲＵ１０２のシステム図を示す。図６Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信器１２０と、送受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、非リムーバブルメモリ１３０と、リムーバブルメモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持したまま、前述の要素の任意のサブコンビネーションを含んでもよいことを認識されるであろう。また、実施形態は、特に、トランシーバステーション（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ホームノードＢ（ｅＮｏｄｅＢ）、ホーム進化型ノードＢ（ＨｅＮＢ）、ホーム進化型ノードＢゲートウェイ、およびプロキシノードなどであって、これらに限定されない、基地局１１４ａおよび１１４ｂ、ならびに／または基地局１１４ａおよび１１４ｂが表してもよいノードが、図６Ｂに示され、かつ、本明細書において説明される要素のうちの一部または全部を含んでもよい。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などであってもよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２が無線環境において動作することを可能にする任意の他の機能性を実行してもよい。プロセッサ１１８は、送受信要素１２２に結合されてもよい送受信器１２０に結合されてもよい。図６Ｂは、プロセッサ１１８と送受信器１２０とを別々の構成要素として示しているが、プロセッサ１１８および送受信器１２０は、電子パッケージまたはチップにおいて一体化されてもよいことを認識されてもよい。

送受信要素１２２は、エアインターフェース１１５／１１６／１１７上で、信号を基地局（例えば、基地局１１４ａ）へ送信し、または信号を基地局から受信するように構成されてもよい。例えば、一実施形態において、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態において、送受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタであってもよい。また別の実施形態において、送受信要素１２２は、ＲＦと光信号との双方を送信および受信するように構成されてもよい。送受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことを認識されるであろう。

また、送受信要素１２２は、図６Ｂにおいて単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態において、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７上で無線信号を送信および受信するために、２つ以上の送受信要素１２２（例えば、複数のアンテナ）を含んでもよい。

送受信器１２０は、送受信要素１２２によって送信されるべき信号を変調し、送受信要素１２２によって受信される信号を復調するように構成されてもよい。上述されたように、ＷＴＲＵ１０２は、マルチモード能力を有してもよい。したがって、送受信器１２０は、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介してＷＴＲＵ１０２が通信することを可能にするために、複数の送受信器を含んでもよい。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、これらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８へユーザデータを出力してもよい。また、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２などの、任意のタイプの適切なメモリからの情報にアクセスし、任意のタイプの適切なメモリにデータを記憶してもよい。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含んでもよい。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態において、プロセッサ１１８は、サーバまたは家庭用コンピュータ（図示せず）上など、ＷＴＲＵ１０２に物理的に位置しないメモリからの情報にアクセスし、ＷＴＲＵ１０２に物理的に位置しないメモリにデータを記憶してもよい。

プロセッサ１１８は、電源１３４から電力を受信してもよく、また、ＷＴＲＵ１０２内の他の構成要素へ電力を分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池などを含んでもよい。

プロセッサ１１８は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよいＧＰＳチップセット１３６にも結合されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７上で位置情報を受信し、および／または、２つ以上の近くの基地局から受信されている信号のタイミングに基づいて、その位置を判定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持したまま、任意の適切な位置判定方法によって位置情報を取得してもよいことが認識されるであろう。

プロセッサ１１８は、追加的な特徴、機能性および／または有線接続性もしくは無線接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでもよい、他の周辺機器１３８にさらに結合されてもよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信器、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信器、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザなどを含んでもよい。

図６Ｃは、実施形態に係るＲＡＮ１０３およびコアネットワーク１０６のシステム図を示す。上述されたように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１５上で通信してもよい。ＲＡＮ１０３は、コアネットワーク１０６とも通信していることがあってもよい。図６Ｃに示されるように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃを含んでもよい。これらの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１５上で通信するための１または複数の送受信器を含んでもよい。ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃの各々は、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０３は、ＲＮＣ１４２ａおよび／または１４２ｂも含んでもよい。ＲＡＮ１０３は、実施形態との整合性を維持したまま、任意の数のノードＢおよびＲＮＣを含んでもよいことを認識されるであろう。

図６Ｃに示されるように、ノードＢ１４０ａおよび／または１４０ｂは、ＲＮＣ１４２ａと通信していてもよい。また、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信していてもよい。ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃは、それぞれのＲＮＣ１４２ａ、１４２ｂとＩｕｂインターフェースを介して通信してもよい。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信してもよい。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されているそれぞれのノードＢ１４０ａ、１４０ｂ、および／または１４０ｃを制御するように構成されてもよい。また、ＲＮＣ１４２ａ、１４２ｂの各々は、外側ループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化等などの他の機能性を実行またはサポートするように構成されてもよい。

図６Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。前述の要素の各々は、コアネットワーク１０６の一部として描かれているが、これらの要素のうちのいずれか１つが、コアネットワーク事業者以外のエンティティによって所有または運用されてもよいことが認識されるであろう。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。

ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８にも接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。

上述されたように、コアネットワーク１０６は、他のサービスプロバイダによって所有および／または運用される他の有線ネットワークまたは無線ネットワークを含むことができるネットワーク１１２にも接続されてもよい。

図６Ｄは、実施形態に係るＲＡＮ１０４およびコアネットワーク１０７のシステム図を示す。上述されたように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１６上で通信してもよい。ＲＡＮ１０４は、コアネットワーク１０７とも通信していてもよい。

ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃを含んでもよいが、ＲＡＮ１０４は、実施形態との整合性を維持したまま、任意の数のｅＮｏｄｅＢを含んでもよいことを認識されるであろう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１６上で通信するための１または複数の送受信器を含んでもよい。一実施形態において、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、例えば、ｅＮｏｄｅＢ１６０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａへ無線信号を送信し、またはＷＴＲＵ１０２ａから無線信号を受信してもよい。

ｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々は、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてもよい。図６Ｄに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃは、Ｘ２インターフェースを介して互いに通信してもよい。

図６Ｄに示されるコアネットワーク１０７は、モビリティマネジメントゲートウェイ（ＭＭＥ）１６２と、サービングゲートウェイ１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６とを含んでもよい。前述の要素の各々は、コアネットワーク１０７の一部として描かれているが、これらの要素のうちのいずれか１つが、コアネットワーク事業者以外のエンティティによって所有および／または運用されてもよいことを認識されるであろう。

ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々に接続されてもよく、制御ノードとしての機能を果たしてもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの初期アタッチの間に特定のサービングゲートウェイを選択することなどに関与してもよい。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間の切り替えのための制御プレーン機能も提供してもよい。

サービングゲートウェイ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々に接続されてもよい。サービングゲートウェイ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃへ／からユーザデータパケットをルーティングおよび／または転送してもよい。サービングゲートウェイ１６４は、ｅＮｏｄｅＢ間のハンドオーバの間にユーザプレーンをアンカーリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃについて利用可能である場合にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのコンテキストを管理および記憶することなどの他の機能も実行してもよい。

サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６にも接続されてもよい。これは、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。

コアネットワーク１０７は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク１０７ｙは、コアネットワーク１０７とＰＳＴＮ１０８との間のインターフェースとしての機能を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはＩＰゲートウェイと通信してもよい。また、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、他のサービスプロバイダによって所有および／または運用される他の有線ネットワークまたは無線ネットワークを含むことができるネットワーク１１２へのアクセスを提供してもよい。

図６Ｅは、実施形態に係るＲＡＮ１０５およびコアネットワーク１０９のシステム図を示す。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１７上で通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。下記でさらに議論されるように、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃ、ＲＡＮ１０５、ならびにコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、基準点として定義されてもよい。

図６Ｅに示されるように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、および／または１８０ｃ、ならびにＡＳＮゲートウェイ１８２を含んでもよいが、ＲＡＮ１０５は、実施形態との整合性を維持したまま、任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことを認識されるであろう。基地局１８０ａ、１８０ｂ、および／または１８０ｃの各々は、ＲＡＮ１０５内の特定のセル（図示せず）に関連付けられてもよく、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとエアインターフェース１１７上で通信するための１または複数の送受信器を含んでもよい。一実施形態において、基地局１８０ａ、１８０ｂ、および／または１８０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、例えば、基地局１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａへ無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信してもよい。基地局１８０ａ、１８０ｂ、および／または１８０ｃは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービスの品質（ＱｏＳ）ポリシー強化などのモビリティ管理機能も提供してもよい。ＡＳＮゲートウェイ１８２は、トラフィックアグリゲーションポイントとしての機能を果たしてもよく、ページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどに関与してもよい。

ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＲＡＮ１０５との間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義されてもよい。また、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの各々は、コアネットワーク１０９と論理インターフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとコアネットワーク１０９との間の論理インターフェースは、認証、許可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用されてもよいＲ２基準点として定義されてもよい。

基地局１８０ａ、１８０ｂ、および／または１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むＲ８基準点として定義されてもよい。基地局１８０ａ、１８０ｂ、および／または１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６基準点として定義されてもよい。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの各々に関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含んでもよい。

図６Ｅに示されるように、ＲＡＮ１０５は、コアネットワーク１０９に接続されてもよい。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含むＲ３基準点として定義されてもよい。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４と、認証、許可、課金（ＡＡＡ：authentication, authorization, accounting）サーバ１８６と、ゲートウェイ１８８とを含んでもよい。前述の要素の各々は、コアネットワーク１０９の一部として示されているが、これらの要素のうちのいずれか１つは、コアネットワーク事業者以外のエンティティによって所有および／または運用されてもよいことを認識されるであろう。

ＭＩＰ−ＨＡは、ＩＰアドレス管理に関与してもよく、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃが異なるＡＳＮおよび／または異なるコアネットワーク間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。ＡＡＡサーバ１８６は、ユーザ認証と、ユーザサービスをサポートすることとに関与してもよい。ゲートウェイ１８８は、他のネットワークとの相互作用を容易にしてもよい。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。また、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに、他のサービスプロバイダによって所有および／または運用される有線ネットワークまたは無線ネットワークを含んでもよいネットワーク１１２へのアクセスを提供してもよい。

図６Ｅには示されていないが、ＲＡＮ１０５は他のＡＳＮに接続されてもよく、コアネットワーク１０９は他のコアネットワークに接続されてもよいことを認識されるであろう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、ＲＡＮ１０５と他のＡＳＮとの間でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのモビリティを調整するためのプロトコルを含んでもよいＲ４基準点として定義されてもよい。コアネットワーク１０９と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと訪問先コアネットワークとの間の相互作用を容易にするためのプロトコルを含んでもよいＲ５基準点として定義されてもよい。

特徴および要素は、特定の組み合わせにおいて上述されているが、当業者は、各特徴または要素が単独で、または他の特徴および要素との任意の組み合わせにおいて使用されてもよいことを認識するであろう。また、本明細書において説明される方法は、コンピュータまたはプロセッサによる実行のためのコンピュータ読取可能な媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ読取可能な媒体の例は、（有線接続または無線接続上で送信される）電気信号およびコンピュータ読取可能な記憶媒体を含む。コンピュータ読取可能な記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびに、ＣＤ−ＲＯＭディスク、およびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、これらに限定されない。ソフトウェアと関連付けられたプロセッサは、ＷＴＲＵ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおける使用のための無線周波数送受信器を実装するために使用されてもよい。

Claims (24)

1. ビデオデータ処理方法であって、
   複数のビデオ表現フォーマットサブセットを受信するステップであって、前記複数のビデオ表現フォーマットサブセットは、複数のレイヤに対応する、ステップと、
   カレントレイヤと関連付けられたビデオ表現フォーマットサブセットインデックスを受信するステップと、
   前記ビデオ表現フォーマットサブセットインデックスを使用して、前記カレントレイヤと関連付けられた前記複数のビデオ表現フォーマットサブセットのうちの１つを決定するステップと
   を備えたことを特徴とする方法。
2. 前記複数のビデオ表現フォーマットサブセットのうちの第１のビデオ表現フォーマットサブセットは、第１のレイヤに対応し、および前記複数のビデオ表現フォーマットサブセットのうちの第２のビデオ表現フォーマットサブセットは、複数のレイヤに対応することを特徴とする請求項１に記載の方法。
3. 前記ビデオ表現フォーマットサブセットインデックスは、シーケンスパラメータセット（ＳＰＳ）において受信されることを特徴とする請求項１に記載の方法。
4. 前記複数のビデオ表現フォーマットサブセットは、クロスレイヤパラメータセットにおいて受信されることを特徴とする請求項１に記載の方法。
5. 前記複数のビデオ表現フォーマットサブセットの総計を受信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
6. 前記複数のビデオ表現フォーマットサブセットの各々は、１つまたは複数のビデオ表現パラメータ値を備えていることを特徴とする請求項１に記載の方法。
7. 前記パラメータ値は、輝度サンプルにおけるピクチャ幅のインジケーション、輝度サンプルにおけるピクチャ高さのインジケーション、輝度配列の１つもしくは複数のサンプルのビット深度のインジケーション、彩度配列の１つもしくは複数のサンプルのビット深度のインジケーション、または彩度フォーマットインデックスのインジケーション、のうちの少なくとも１つを備えていることを特徴とする請求項６に記載の方法。
8. ビデオ符号化方法であって、
   アクティブ参照レイヤの数を直接参照レイヤの数と比較するステップと、
   前記アクティブ参照レイヤの数を前記直接参照レイヤの数と比較したことに基づいて、前記アクティブ参照レイヤのインジケーションをスライスレベルヘッダに含めるかを判定するステップと
   を備えたことを特徴とする方法。
9. 前記アクティブ参照レイヤの数が前記直接参照レイヤの数と等しくないことを条件に、レイヤ間予測のために使用することができるピクチャのインジケーションを含めるステップをさらに備えたことを特徴とする請求項８に記載の方法。
10. 前記アクティブ参照レイヤの数が前記直接参照レイヤの数と等しいことを条件に、レイヤ間予測のために使用することができるピクチャのインジケーションを含めないステップをさらに備えたことを特徴とする請求項８に記載の方法。
11. ビデオ復号化方法であって、
    １つまたは複数のレイヤを備えたビットストリームを受信するステップと、
    前記受信されたビットストリームにおけるアクティブ参照レイヤの数が、直接参照レイヤの数と等しくないことを条件に、レイヤ間予測レイヤ構文要素を受信するステップであって、前記レイヤ間予測レイヤ構文要素は、レイヤ間予測のためにカレントレイヤのカレントピクチャによって使用することができる参照ピクチャレイヤＩＤのリストを示す、ステップと
    を備えたことを特徴とする方法。
12. 前記アクティブ参照レイヤの数が、前記直接参照レイヤの数と等しいことを条件に、前記レイヤ間予測レイヤ構文要素を導出するステップをさらに備え、前記レイヤ間予測レイヤ構文要素は、前記カレントレイヤの直接参照レイヤのレイヤＩＤから推測されることを特徴とする請求項１１に記載の方法。
13. ビデオコーディングデバイスであって、
    複数のビデオ表現フォーマットサブセットを受信し、前記複数のビデオ表現フォーマットサブセットは、複数のレイヤに対応し、
    カレントレイヤと関連付けられたビデオ表現フォーマットサブセットインデックスを受信し、および
    前記ビデオ表現フォーマットサブセットインデックスを使用して、前記カレントレイヤと関連付けられた前記複数のビデオ表現フォーマットサブセットのうちの１つを決定する
    ように構成されたプロセッサを備えたことを特徴とするビデオコーディングデバイス。
14. 前記複数のビデオ表現フォーマットサブセットの第１のビデオ表現フォーマットサブセットは、第１のレイヤに対応し、および前記複数のビデオ表現フォーマットサブセットの第２のビデオ表現フォーマットサブセットは、複数のレイヤに対応することを特徴とする請求項１３に記載のビデオコーディングデバイス。
15. 前記ビデオ表現フォーマットサブセットインデックスは、シーケンスパラメータセット（ＳＰＳ）において受信されることを特徴とする請求項１３に記載のビデオコーディングデバイス。
16. 前記複数のビデオ表現フォーマットサブセットは、クロスレイヤパラメータセットにおいて受信されることを特徴とする請求項１３に記載のビデオコーディングデバイス。
17. 前記プロセッサは、前記複数のビデオ表現フォーマットサブセットの総計を受信するようにさらに構成されていることを特徴とする請求項１３に記載のビデオコーディングデバイス。
18. 前記複数のビデオ表現フォーマットサブセットは、１つまたは複数のビデオ表現パラメータ値を備えていることを特徴とする請求項１３に記載のビデオコーディングデバイス。
19. 前記パラメータ値は、輝度サンプルにおけるピクチャ幅のインジケーション、輝度サンプルにおけるピクチャ高さのインジケーション、輝度配列の１つもしくは複数のサンプルのビット深度のインジケーション、彩度配列の１つもしくは複数のサンプルのビット深度のインジケーション、または彩度フォーマットインデックスのインジケーション、のうちの少なくとも１つを備えていることを特徴とする請求項１８に記載のビデオコーディングデバイス。
20. ビデオ符号化デバイスであって、
    アクティブ参照レイヤの数を直接参照レイヤの数と比較し、
    前記アクティブ参照レイヤの数を前記直接参照レイヤの数と比較したことに基づいて、前記アクティブ参照レイヤのインジケーションをスライスレベルヘッダに含めるかを判定する
    ように構成されたプロセッサを備えたことを特徴とするビデオ符号化デバイス。
21. 前記プロセッサは、前記アクティブ参照レイヤの数が前記直接参照レイヤの数と等しくないことを条件に、レイヤ間予測のために使用することができるピクチャのインジケーションを含めるようにさらに構成されていることを特徴とする請求項２０に記載のビデオ符号化デバイス。
22. 前記プロセッサは、前記アクティブ参照レイヤの数が前記直接参照レイヤの数と等しいことを条件に、レイヤ間予測のために使用することができるピクチャのインジケーションを含めないようにさらに構成されていることを特徴とする請求項２０に記載のビデオ符号化デバイス。
23. ビデオ復号化デバイスであって、
    １つまたは複数のレイヤを備えたビットストリームを受信し、
    前記受信されたビットストリームにおけるアクティブ参照レイヤの数が、直接参照レイヤの数と等しくないことを条件に、レイヤ間予測レイヤ構文要素を受信し、前記レイヤ間予測レイヤ構文要素は、レイヤ間予測のためにカレントレイヤのカレントピクチャによって使用することができる参照ピクチャレイヤＩＤのリストを示す
    ように構成されたプロセッサを備えたことを特徴とするビデオ復号化デバイス。
24. 前記プロセッサは、前記アクティブ参照レイヤの数が、前記直接参照レイヤの数と等しいことを条件に、前記レイヤ間予測レイヤ構文要素を導出するようにさらに構成され、前記レイヤ間予測レイヤ構文要素は、前記カレントレイヤの直接参照レイヤのレイヤＩＤから推測されることを特徴とする請求項２３に記載のビデオ復号化デバイス。