例示的な実施形態の詳細な説明は、様々な図を参照しつつ、ここで説明される。この説明は、考えられる実装形態の詳細な例を提供するが、詳細は、例示的であることが意図され、本出願の範囲を決して限定しないことを留意されるべきである。
ビデオコーディングシステムにおいて、クライアントデバイス側では、Nのスクリーンシナリオ、すなわち、可変スクリーンサイズおよび/または表示能力を有するデバイス、例えば、スマートフォン、タブレット、PC、およびHDTVなどでビデオコンテンツを消費し続けていると予期される。通信ネットワーク側では、ビデオは、インターネット、WiFiネットワーク、モバイル通信ネットワーク(例えば、3G、4Gなど)など、またはこれらの任意の組み合わせのうちの1または複数に渡って送信されてもよい。
ユーザ経験(例えば、クライアントデバイスのエンドユーザに対する)および/またはビデオサービスの品質を改善するために、スケーラブルビデオコーディングが実装されてもよい。スケーラブルビデオコーディングで、ビデオ信号は、最高分解能でいったん符号化されてもよい。そのようなビデオ信号は、例えば、特定のアプリケーションによって必要とされ、および/またはクライアントデバイスによってサポートされることがある特定のレートに従って、ビデオ信号に関連付けられた1または複数のビデオストリームの1または複数のサブセットから復号されてもよい。分解能は、空間分解能(ピクチャサイズなどの)、時間分解能(例えば、フレームレート)、ならびにビデオ品質(例えば、MOSなどの主観的品質、および/またはPSNR、SSIMもしくはVQMなどの客観的品質)などの1または複数のビデオパラメータを含んでもよい。使用することができる他のビデオパラメータは、彩度フォーマット(例えば、YUV420、YUV422、もしくはYUV444)、ビット深度(例えば、8ビットビデオもしくは10ビットビデオ)、複雑度、ビュー、全領域(gamut)(例えば、色域(color gamut))、および/またはアスペクト比(例えば、16:9もしくは4:3)を含む。
ビデオ標準は、スケーラビリティモードをサポートすることができるツールおよび/またはプロファイルを含んでもよい。例えば、高効率ビデオコーディングは、スケーラブルビデオコーディングをサポートするように構成されてもよい。HEVCに対する例示的なスケーラブル拡張は、空間スケーラビリティ(例えば、スケーラブルビットストリームは、2つ以上の空間分解能においてそれぞれの信号を含んでもよい)、品質スケーラビリティ(例えば、スケーラブルビットストリームは、2つ以上の品質レベルにおいてそれぞれの信号を含んでもよい)、および標準スケーラビリティ(例えば、スケーラブルビットストリームは、H.264/AVCを使用してコーディングされた基底レイヤと、HEVCを使用して符号化された1つもしくは複数の強化レイヤ(enhancement layers)と、を含んでもよい)のうちの1または複数をサポートしてもよい。スケーラブルビデオは、3Dビデオへ拡張されてもよい。例えば、マルチビュースケーラビリティが実装されてもよい(例えば、スケーラブルビットストリームは、2Dビデオ信号と3Dビデオ信号との両方を含んでもよい)。スケーラブルHEVC設計の態様は、空間スケーラビリティおよび/または品質スケーラビリティの使用を含んでもよく、例えば、本明細書において説明されるように、本明細書において説明される技法は、1または複数の他のタイプのスケーラビリティに適用されてもよいことが認識されるべきである。
HEVCのスケーラブル拡張(SHVC:scalable extensions of HEVC)は、参照インデックスベースのフレームワークに従って実装されてもよい。参照インデックスベースのフレームワークは、そのようなフレームワークを採用するスケーラブルコーディングシステム内で単一レイヤコーデックロジックが再使用されてもよいように、ブロックレベルにおける動作において、および/またはブロックレベルのまま未満での(below block level intact)動作を維持してもよい。参照インデックスベースのフレームワークは、スケーラブルコーデックの設計を簡略化してもよい。そのようなフレームワークは、例えば、高レベル構文シグナリングモジュールおよび/またはレイヤ間処理モジュールを組み込んで、コーディング効率を達成することによって、異なるタイプのスケーラビリティをサポートしてもよい。高レベル構文変更が実装されて、例えば、SHVCのレイヤ間処理および/またはマルチレイヤシグナリングをサポートしてもよい。そのような構文変更は、例えば、参照インデックスベースのフレームワークに従って実装されてもよい。
スケーラブルビデオコーディングは、1または複数のレイヤ(例えば、多数のレイヤ)をサポートしてもよい。各々のそのようなレイヤは、空間スケーラビリティ、時間スケーラビリティ、SNRスケーラビリティ、または他のタイプのスケーラビリティのうちの1または複数を有効にするように設計されてもよい。例えば、スケーラブルビットストリームは、混合されたスケーラビリティレイヤを含んでもよく、1または複数のそれぞれの強化レイヤは、復号されるために、1または複数の下位レイヤに依存してもよい。レイヤ間処理は、レイヤ間参照ピクチャ(ILR:inter-layer reference)サンプルおよび/または動きフィールド情報を生成して、例えば、1または複数の強化レイヤの予測精度を高めてもよい。
いくつかのパラメータセットが、HEVC実装に対し、および/または1もしくは複数の対応する拡張に対して指定されてもよい。例えば、ビデオパラメータセット(VPS)は、複数のレイヤによって共有することができる、1または複数の構文要素を含んでもよい。VPSは、ビットストリーム抽出、能力交換(capability exchange)、および/またはセッションネゴシエーションのために使用される情報を含んでもよい(例えば、レイヤの最大数、ならびに/または、プロファイル情報、層(tier)情報、およびレベル情報のうちの1つもしくは複数)。
シーケンスパラメータセット(SPS)は、時間間隔にわたる一連のビデオピクチャなどの、コーディングされたビデシーケンスにおける1または複数のコーディングスライス(coded slices)(例えば、全てのコーディングスライス)に共通することができる情報を含んでもよい。そのような情報は、ピクチャ分解能、ビット深度、およびコーディングブロックサイズなどのうちの1または複数を含んでもよい。
ピクチャパラメータセット(PPS)は、ピクチャレベル情報を含んでもよい。そのような情報は、初期量子化値、コーディングツール有効フラグ(coding tools enable flags)および/またはコーディングツール無効フラグ(coding tools disable flags)などのうちの1または複数を含んでもよい。PPSにおいて伝達される情報は、その情報が頻繁に更新されないように、比較的長期間、例えば、複数のピクチャの期間を通じて、変更されないままであってもよい。スライスレベルで変更することができる情報は、スライスヘッダに含まれてもよい。
VPS、SPSおよび/またはPPSなどの、1または複数のパラメータセットは、帯域外(out-of-band)で送信されてもよい(例えば、いくつかの適用シナリオにおけるように、信頼性のあるチャネルを使用して)。高レベル構文設計によって、複数のレイヤが単一のレイヤ(例えば、同一のSPS)を参照することが可能になる。これは、例えば、マルチビュースケーラビリティおよび/またはSNRスケーラビリティに使用されてもよい。空間スケーラビリティに対し、1または複数のレイヤ(例えば、各レイヤ)は、例えば、異なるビデオ分解能に起因して、それぞれの異なるSPSを参照してもよい。SPSにおける1または複数のパラメータ(例えば、パラメータの大部分)が複数のレイヤにわたって同一である場合、そのような冗長性を除去することによってビットレートを節約することが望ましいことがある。1または複数のそのようなパラメータは、複数のレイヤの間で共有されてもよい。
ビットレートを節約するための例示的なアプローチにおいて、SPSごとの予測(SPS to SPS prediction)が実装されてもよく、それは、例えば、基底レイヤおよび/または別の従属レイヤ(dependent layer)のSPSパラメータから、スケーリングリスト、参照ピクチャセット(RPS:reference picture set)などの、1または複数の強化レイヤSPSパラメータを予測するために使用されてもよい。そのようなSPSごとの予測は、異なるレイヤ間でパラメータセット従属(parameter set dependency)を導入してもよい。
ビットレートを節約するための別の例において、VPSごとの予測が実装されてもよぃ、それは、レイヤにわたって1または複数の共有パラメータをVPSに再配置してもよく、VPSにおける対応するパラメータに基づいて、1または複数の共有SPSパラメータ(例えば、各レイヤのSPSパラメータ)を予測してもよい。
HEVC拡張のためのVPS実装および/またはSPS実装に対する設計基準は、下記のうちの1または複数を含んでもよい。VPSは、ビットストリーム抽出および/または能力交換のために有益となることがある、1または複数のパラメータを含んでもよい。復号ピクチャバッファ(DPB:decoded picture buffer)関連パラメータは、VPS拡張に含まれてもよい。
複数のレイヤの間で共有することができる1または複数の高レベル構文要素を集約することができるパラメータセット(例えば、レイヤ間パラメータセット(IPS:inter-layer parameter set))が実装されてもよい。1または複数のレイヤ(例えば、各レイヤ)は、1または複数のIPSパラメータを参照してもよく、これは、対応するオーバーヘッドビットを節約することができる。
IPSは、スケーラブルHEVCビデオコーディングシステムにおいて提供されてもよい。例えば、IPSは基底レイヤにおいて伝達されないことがあるため、IPSのサイズは、基底レイヤサブストリームに影響を及ぼさないことがある。IPSは、例えば、複数のレイヤにわたる1または複数の共有パラメータの予測を容易にすることによって、高レベルのシグナリング効率を提供することができる。IPSの実装は、ビデオコーディングシステムにおける構文解析依存(parsing dependency)を除去することができ、なぜなら、例えば、各パラメータの構文解析が別の異なるパラメータセットからの構文解析結果に依拠しないように、異なるパラメータセットに一般的に配置されることがある1または複数のパラメータが、同一のIPSに含まれてもよいからである。
IPSは、IPS NALユニットのnuh_layer_id値が適合ビットストリーム(conforming bitstream)に対してゼロ(0)にならないように、スケーラブルコーディングシステムにおける1または複数の強化レイヤに適用可能であってもよい。例えば、適合ビットストリームは、一(1)に等しい、1または複数のIPS NALユニット(例えば、全てのIPS NALユニット)のnuh_layer_idを有してもよい。
図1A〜図1Cは、例示的なIPSを示す構文テーブルである。図1A〜図1Cに示されるように、IPSは、1または複数のパラメータを含んでもよく、および複数のレイヤをコーディングする目的のために設計されてもよい。そのようなパラメータは、例えば、max_sublayer_for_ilp_plus1およびdirect_dependency_typeを含んでもよい。1または複数のレイヤが、同一のRPSまたは非常に類似したRPSを共有してもよいため、IPSは、1または複数のレイヤに関連したRPSを含んでもよい。
類似した目的を果たし、およびSPSに存在してもよい、1または複数のパラメータは、ビデオフォーマットサブセット、コーディングパラメータサブセット、スケーリングリストサブセット(scaling list subset)、スケールドオフセットサブセット(scaled offset subset)、またはVUIサブセットのうちの1または複数を含むことができる、それぞれのサブセットにグループ化されてもよい。IPSにおいて、1または複数のサブセット(例えば、各サブセット)は、それぞれの複数のパラメータ値を有してもよい。これによって、IPSおよびサブセット内にインデックス付けすることによって、強化レイヤが複数のパラメータ値を参照することが可能になる。例えば、第1のビデオフォーマットセット(例えば、0)は、720pフォーマットを指定してもよく、および第2のビデオフォーマットセット(例えば、1)は、1080pフォーマットを指定してもよい。四(4)レイヤ(例えば、レイヤ0が、720pレイヤであり、レイヤ1、レイヤ2、およびレイヤ3が、1080pレイヤである)を有する混合(mixed)空間および/またはSNRスケーラビリティコーディングシステムに対し、基底レイヤ(例えば、レイヤ0)SPSは、ips_video_format_subset(0)を参照してもよく、強化レイヤ(例えば、レイヤ1、レイヤ2、およびレイヤ3)は、ips_video_format_subset(1)を参照してもよい。そのような例においては、低減された(例えば、最小の)数の構文要素がシグナリングされて、複数のレイヤによって使用されるパラメータをカバーしてもよい。
下記は、図1A〜図1Cに示される例示的なIPS構文テーブルにおけるエントリに適用されてもよい。構文要素ips_inter_layer_view_parameter_set_idは、他の構文要素による参照のためのIPSを識別してもよい。構文要素num_video_format_subsetsは、ビデオフォーマット構文構造(ips_video_format_subset)の数を指定してもよい。構文要素num_coding_param_subsetsは、コーディングパラメータ構文構造(ips_coding_param_subset)の数を指定してもよい。構文要素num_pcm_param_subsetsは、PCMコーディングパラメータ構文構造(ips_pcm_param_subset)の数を指定してもよい。構文要素num_scaling_list_subsetsは、スケーリングリスト構造(ips_scaling_list_subset)の数を指定してもよい。構文要素num_scaled_ref_layer_offset_subsetは、スケールド参照レイヤオフセット構造(ips_scaled_ref_layer_offset_subset)の数を指定してもよい。構文要素num_vui_param_subsetsは、VUIパラメータ構造(ips_vui_param_subset)を指定してもよい。
1または複数のビデオ表現フォーマットは、サブセットにグループ化されてもよい。1または複数のサブセットは、パラメータセット(例えば、IPS)でシグナリングされてもよい。サブセットは、1または複数のレイヤによって参照されてもよい。例えば、第1のレイヤは、第1のサブセットを参照してもよい。1または複数のレイヤは、第2のサブセットを参照してもよい。レイヤの各々は、サブセットのインデックスを参照して、ビデオ表現構文値(video representation syntax values)を導出してもよい。例えば、IPSでは、IPS構文要素をシグナリングするビット(例えば、オーバーヘッドビット)をさらに保存(save)するために、1または複数のサブセットが実装されてもよい。例えば、所与のサブセットの第1のセットのパラメータ値に限定される絶対パラメータ値がシグナリングされてもよい。1または複数の後続のセットのパラメータ値に対し、カレントセット(current set)のパラメータ値と前のセットのパラメータ値との間のそれぞれの差分値がシグナリングされてもよい。例示すために、ips_video_format_subset(0)は、720pフォーマットを示してもよく(pic_width_in_luma_samplesが、1280に設定されてもよく、pic_height_in_luma_samplesが、720に設定されてもよい)、ips_video_format_set(1)は、1080pフォーマットを示してもよい(pic_width_in_luma_samplesが、1920に設定されてもよく、pic_height_in_luma_samplesが、1080に設定されてもよい)。1920および1080の両方をシグナリングするのではなく、ips_video_format_set(0)とips_video_format_set(1)との間のそれぞれの差分値がシグナリングされてもよい。この例に従って、幅および高さに対するそれぞれの差分値640および360は、ips_video_format_set(1)でシグナリングされてもよい。
そのようなIPSの対応する構文テーブルは、図1A〜図1Cに示されるようであってもよく、記述子タイプは、例えば、差分値としてシグナリングすることができるパラメータに対し、uc(v)またはse(v)へ変更されてもよい。関連するパラメータの値は、下記のように導出されてもよい。
例えば、S(i)が、所与のサブセットに対するi番目のセットのパラメータである場合、変数P(i,X)は、i番目のパラメータセットS(i)におけるパラメータXであり、および/または、変数ParamValueInIPS(i,X)は、IPSにおけるP(i,X)に対してシグナリングされる値である。i番目のパラメータサブセットにおけるパラメータXの変数ParamValue(i,X)、P(i,X)は、(i−1)番目のパラメータサブセットにおけるパラメータX、P(i−1,X)から、例えば、下記のように導出されてもよい。
if(i==0)
ParamValue(i,X)=ParamValueInIPS(i,X)
else
ParamValue(i,X)=ParamValue(i−1,X)+ParamValueInIPS(i,X)
SPSおよび/またはその拡張は、例えば、それぞれ図2A〜図2Cおよび図3に図示されるように簡略化されてもよい。1または複数の強化レイヤに対するSPSにおいて同様の構文要素を伝達するのではなく、強化レイヤSPS構文テーブルが、例えば、IPSパラメータセットインデックスへの参照を含めることによって簡略化されてもよい。
SPSの1または複数の構文要素(例えば、そのような全ての構文要素)は、図2A〜図2Cにおける影付きの(shaded)エントリによって表現されるように、基底レイヤ(nuh_layer_id=0)に対し、そのままの状態で維持されてもよい(kept intact)。これによって、例えば、単一レイヤHEVC仕様との後方互換性が可能になる。IPSの実装に従ってSPSに追加することができる例示的な構文要素は、図2A〜図2Cおよび図3においてイタリック体のテキストによって表現されている。
下記は、図2A〜図2Cおよび図3に示される簡略化されたSPS構文テーブルおよび簡略化された拡張構文テーブルにおけるエントリに適用されてもよい。図2A〜図2Cおよび図3に示されるように、構文要素sps_inter_layer_view_parameter_set_idは、アクティブパラメータセット(例えば、IPS)のips_inter_layer_view_parameter_set_idの値を指定してもよい。パラメータセットにおいてシグナリングされる構文要素ips_video_format_subsets_indexは、アクティブパラメータセットに含まれるビデオ表現フォーマット構文構造のリスト内のインデックスを指定してもよい。構文要素ips_video_format_subsets_indexは、このSPSを参照するレイヤに適用することができる表現フォーマット構文構造を指定してもよい。ips_video_format_subsets_indexの範囲は、0より大きく、num_video_format_subsets_index未満であってもよい。構文要素ips_coding_param_subsets_indexは、アクティブIPSに含まれるコーディングパラメータ構文構造のリスト内のインデックスを指定してもよい。ips_coding_param_subsets_indexの範囲は、0より大きく、num_coding_param_subsets_index未満であってもよい。ips_scaling_list_subsets_indexは、アクティブIPSに含まれるスケーリングリスト構文構造のリスト内のインデックスを指定してもよい。ips_scaling_list_subsets_indexの範囲は、0より大きく、num_scaling_list_subsets_index未満であってもよい。ips_pcm_param_subsets_indexは、アクティブIPSに含まれるPCMパラメータ構文構造のリスト内のインデックスを指定してもよい。ips_pcm_param_subsets_indexの範囲は、0より大きく、num_pcm_param_subsets_index未満であってもよい。ips_vui_param_subsets_indexは、アクティブIPSに含まれるVUI構文構造のリスト内のインデックスを指定してもよい。ips_vui_param_subsets_indexの範囲は、0より大きく、num_vui_param_subsets_index未満であってもよい。ips_scaled_ref_layer_offset_subset_indexは、アクティブIPSに含まれるビデオフォーマット構文構造のリスト内のインデックスを指定してもよい。ips_scaled_ref_layer_offset_subset_indexの範囲は、0より大きく、num_scaled_ref_layer_offset_subsets_index未満であってもよい。
これらの例示的な構文構造インデックスによって、例えば、IPSおよび特定のサブセット内にインデックス付けすることによって、強化レイヤが複数のパラメータ値を導出すことが可能になる。例えば、レイヤ(例えば、強化レイヤ(EL))のpic_width_in_luma_samplesを導出するために、ELは、例えば、所与のELのSPSに存在するIPS ID(sps_inter_layer_view_parameter_set_id)によって、関連付けられたアクティブIPSを位置付けてもよい(locate)。EL SPSにおけるインデックスips_video_format_subsets_indexの値を使用することによって、ELは、関連付けられたアクティブIPSに存在する特定のビデオフォーマットサブセット、ips_video_format_subset(ips_video_format_subsets_index)を位置付けてもよい。ELのpic_width_in_luma_samplesの値は、例えば、本明細書において説明される第1の例示的なIPSシグナリング方法に直接従って、ips_video_format_subset(ips_video_format_subsets_index)に存在するpic_width_in_luma_samplesの対応するパラメータ値から導出されてもよい。代わりに、pic_width_in_luma_samplesの値は、例えば、本明細書において説明される第2の例示的なIPSシグナリング方法に従って、ParamValue(ips_video_format_subsets_index,pic_width_in_luma_samples)から導出されてもよい。このELのpic_height_in_luma_samplesの値は、同様の方式で導出されてもよい。図4は、IPSからパラメータを導出するためのそのような例を示す。1または複数の他のパラメータサブセット内の1または複数の他のパラメータの値は、同様の方式で導出されてもよい。
IPSローバイトシーケンスペイロード(RBSP:raw byte sequence payload)は、1または複数のSPS RBSPによって参照する(refer to)ことができる、1または複数のパラメータを含んでもよい。各IPS RBSPは、最初は、例えば、復号プロセスの動作の開始時には、アクティブではないとみなされてもよい。例示的な復号プロセスの動作の間、最大で1つのIPS RBSPが、アクティブであるとみなされてもよい。任意のIPS RBSPのアクティブ化は、以前のアクティブIPS RBSPの非アクティブ化をもたらすことがある。
IPS RBSPが既にアクティブではなく、SPS RBSPのアクティブ化によって参照される(例えば、sps_inter_layer_view_parameter_set_idが、ips_inter_layer_view_parameter_set_id値と等しい)とき、IPS RBSPがアクティブ化されてもよい。アクティブ化されたIPS RBSPは、例えば、別のIPS RBSPのアクティブ化の結果として非アクティブ化されるまで、アクティブIPS RBSPと称されてもよい。IPS RBSPは、ips_inter_layer_view_parameter_subset_idのその特定の値と共に、そのアクティブ化の前に、復号プロセスに利用可能であってもよい。
スライスヘッダは、1つのスライスから他に変化することがある情報と、小さく、またはスライスおよび/もしくはピクチャタイプのうちの一部に対して関連することがあるピクチャ関連情報とを含んでもよい。ビデオコーディング標準、例えば、高効率ビデオコーディング(HEVC)のスケーラブル拡張(SHVC)において、レイヤ間予測のために設計された構文要素は、サンプル予測を含んでもよく、動き予測は、固有の冗長性を有してもよい。スライスヘッダのビットコストは、例えば、いくつかのシグナリングロジックを調整することを通じて、一定の冗長性を除去することによって低減されてもよい。
表1は、VPS拡張構文テーブルの例を示す。表2は、ビデオコーディング標準、例えば、SHVCにおいて使用されるスライスヘッダ構文の例を示す。
表1に示されるように、max_one_active_ref_layer_flagは、例えば、1つのレイヤまたは2つ以上のレイヤからの1または複数のピクチャがスケーラブルシステムにおいてレイヤ間予測のために使用することができるかを特定するために、VPS拡張においてシグナリングされてもよい。このフラグは、スケーラブルシステムにおける1つのレイヤからのレイヤ間参照ピクチャを可能にするための制限を課すために使用されてもよい。そのような制限は、スケーラブルプロファイルおよび/またはスケーラブルレベルが定義されるときに望ましいことがある。max_one_active_ref_layer_flagの設定に応じて、スライスヘッダ内の構文要素num_inter_layer_ref_pics_minus1(例えば、表2に示されるような)は、スライスヘッダでシグナリングされてもよく、またはシグナリングされなくてもよい。max_one_active_ref_layer_flagが1に等しいとき、num_inter_layer_ref_pics_minus1は、0になると推測されてもよく、したがって、シグナリングされなくてもよく、1つの参照レイヤのレイヤIDが、スライスヘッダでシグナリングされてもよい。そうでない場合(例えば、max_one_active_ref_layer_flagが0であるとき)、num_inter_layer_ref_pics_minus1は、シグナリングされてもよい。(num_inter_layer_ref_pics_minus1+1)レイヤのレイヤIDは、スライスヘッダにおけるnum_inter_layer_ref_pics_minus1フラグに続いてもよい。
max_one_active_ref_layer_flagは、max_num_active_ref_layers_minus1フラグによって置き換えられてもよい。max_num_active_ref_layers_minus1フラグの記述子タイプ(descriptor type)は、ue(v)であってもよい(例えば、表3において示されるような)。構文要素は、能力交換の目的を果たすために復号プロセスにおいて使用することができる最大参照レイヤを示してもよい。適切なプロファイル制限および/またはレベル制限が定義されてもよい。構文要素は、1ビットフラグよりも柔軟(flexible)であってもよい。
max_num_active_ref_layers_minus1が0に等しいとき、num_inter_layer_ref_pics_minus1は、スライスヘッダでシグナリングされなくてもよい(例えば、省略されてもよい)。最大で1つの参照レイヤがレイヤ間予測のために許可される場合、VPS拡張におけるそのような構文要素のビットコストは、元のmax_one_active_ref_layer_flagと同一であってもよい(例えば、1ビット)。そのような場合において、ビデオデコーディングデバイスは、レイヤ間予測レイヤ構文要素を推測してもよい。表4は、スライスセグメントヘッダの例を示す。
変数NumActiveRefLayerPicsは、max_num_active_ref_layers_minus1に基づいて導出されてもよい。例えば、変数は、下記のように導出されてもよい。
表4に示されるように、inter_layer_pred_layer_idcは、例えば、アクティブ参照レイヤの数(NumActiveRefLayerPics)が直接参照レイヤの数(例えば、NumDirectRefLayers[num_layer_id])と同一ではない場合に、シグナリングされてもよい。inter_layer_pred_layer_idcは、例えば、アクティブ参照レイヤの数(NumActiveRefLayerPics)が直接参照レイヤの数(例えば、NumDirectRefLayers[num_layer_id])と同一である場合、ビットストリームに存在しないことがある。例えば、スライスヘッダ内のinter_layer_pred_layer_idcは、冗長であることがある。そのような場合において、レイヤ間予測のために使用されるピクチャのインジケーションは、スキップされてもよい。そのような場合において、inter_layer_pred_layer_idcは、疑似コード2に示されるように、RefLayerIdから導出または予測されてもよい。変数NumDirectRefLayersの値は、標準、例えば、SHVCにおいて提供されてもよい。
スライスが従属スライス(dependent slice)ではない場合、誤り耐性への考慮のために、スライスヘッダは、ピクチャ内のスライスごとに提供されてもよい。ピクチャが、1または複数のスライスを含むことがあり、スライスヘッダが、スライスごとに提供されることがあるため、スライスヘッダのビットコストは、他のパラメータセット、例えば、SPS(シーケンスパラメータセット)、PPS(ピクチャパラメータセット)等のビットコストよりも懸念事項となることがある。これらのパラメータセットは、スライスヘッダよりも低頻度で提供されてもよい。
ビデオコーディング標準、例えば、SHVCにおいて、NumActiveRefLayerPics、inter_layer_pred_layer_idcおよびcollocated_ref_layer_idxなどの変数は、コーディングされたピクチャのスライスごとに同一であってもよい。したがって、同一の構文がピクチャ内でスライスごとに重複しないように、スライスヘッダの代わりに、構文要素、例えば、SPS拡張、PPS、APSまたはIPSにおけるinter_layer_pred_enable_flag、num_inter_layer_ref_pics_minus1、inter_layer_pred_layer_idc、inter_layer_sample_pred_only_flag、alt_collocated_indicate_flagおよびcollocated_ref_layer_idxが送信されてもよい。表5は、SPS拡張においてシグナリングすることができる構文要素を示す。
他のパラメータセットでシグナリングされるパラメータ値に依存する条件は、例えば、パラメータセット間の構文解析依存を回避するために、構文要素をスライスヘッダからパラメータセットへ再配置するときに修正されてもよい。表5は、関連構文要素がスライスヘッダからSPS拡張内へ再配置されるときのSPS拡張構文テーブルの例を示す。
いくつかの適用例において、レイヤ間予測関連シグナリング(例えば、inter_layer_pred_enable_flag、inter_layer_sample_pred_only_flagなど)は、スライスごとに、またはピクチャごとに、変更されてもよい。そのような適用例の場合、スライスヘッダ内で構文要素を送信することは、望ましくないシグナリングオーバーヘッドを生じさせることがある。フラグは、SPS拡張(またはPPSもしくはIPS)に追加されて、例えば、レイヤ間予測関連構文要素がスライスセグメントヘッダに存在することがあるか否かを示してもよい。表6は、SPS拡張においてシグナリングすることができる構文要素の例を示す。表7は、対応するスライスヘッダの例を示す。
1に等しいsample_prediction_present_slice_present_flagは、inter_layer_pred_enable_flag、num_inter_layer_ref_pics_minus1、inter_layer_pred_layer_idc、inter_layer_sample_pred_only_flagなどのレイヤ間サンプル予測関連構文要素がスライスヘッダに存在してもよいことを示してもよい。0に等しいsample_prediction_present_slice_present_flagは、関連サンプル予測構文要素がスライスセグメントヘッダに存在しないことがあることを示してもよい。存在しないとき、構文要素の値は、1または複数の変数に基づいて推測されてもよい。例えば、疑似コード3は、どのように構文要素の値が推測されてもよいかの例を提供する。
変数NumSamplePredRefLayers、NumSamplePredLayersおよびSamplePredEnabledFlagは、ビデオコーディング標準、例えば、SHVCにおいて提供されてもよい。sample_prediction_slice_present_flagが0に等しい場合、サンプル予測構文要素inter_layer_sample_pred_onlyは、0に等しくなるように推測されてもよい。1に等しいmotion_prediction_slice_present_flagは、レイヤ間動き予測関連構文要素、例えば、alt_collocated_indication_flag、collocated_ref_layer_idxなどがスライスヘッダに存在してもよいことを示してもよい。0に等しいmotion_prediction_slice_present_flagは、レイヤ間動き予測関連構文要素が強化レイヤスライスセグメントヘッダに存在しないことがあることを示してもよい。これらの構文要素の値は、1または複数の変数に基づいて推測されてもよい。例えば、疑似コード4は、どのように構文要素の値が推測されてもよいかの例を提供する。NumMotionPredRefLayersおよび/またはMotionPredRefLayerldは、ビデオコーディング標準、例えば、SHVCによって提供されてもよい。
疑似コード4に示されるように、少なくとも1つの動き予測参照レイヤが利用可能である場合、(例えば、時間動き情報の代わりに)レイヤ間動き情報が、時間動きベクトル予測(TMVP:temporal motion vector prediction)のために使用されてもよい。配置された(collocated)参照レイヤは、現在の強化レイヤに最も近い動き予測参照レイヤに設定されてもよい。他の動き予測参照レイヤは、配置された参照レイヤとして指定されてもよい。例えば、最も近い参照レイヤの代わりに、最下位動き予測参照レイヤ、すなわち、MotionPredRefLayerId[nuh_layer_id][0]が、TMVPに対するデフォルトの配置された参照レイヤとして使用されてもよい。
1に等しい構文要素inter_layer_sample_pred_only_flagは、カレントピクチャを復号するときに、ELにおける時間参照ピクチャを使用するインター予測がかのうでないことがあることを示してもよい。参照ピクチャリストL0およびL1は、時間参照ピクチャを含まないことがある。inter_layer_sample_pred_only_flagは、スライスのネットワーク抽出レイヤ(NAL:network abstraction layer)ユニットタイプに関わらず、スライスの各々においてシグナリングされてもよい。強化レイヤ(EL)の瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャは、時間参照ピクチャを使用する、インター予測なしのピクチャであってもよい。inter_layer_sample_pred_only_flagは、ELにおけるIDR NALユニットに基づいて判定されてもよい。表8に示されるような条件(例えば、(nal_unit_type!=IDR_W_RADL && nal_unit_type !=IDR_N_LP))が、適用されてもよい。
inter_layer_sample_pred_only_flagが1に等しいとき、利用可能な参照ピクチャは、レイヤ間参照ピクチャであってもよい。SHVCにおいては、レイヤ間参照ピクチャからの動きベクトルがゼロに等しいことがあるため、時間動きベクトル予測(TMVP)は、バイパスされてもよく、TMVPに関連するスライスヘッダ内の構文要素の各々は、スキップされてもよい。inter_layer_sample_pred_only_flagが利用されて、動き予測シグナリングがスキップされてもよい。
WTRUは、inter_layer_sample_pred_only_flagを使用せずに、レイヤ間予測のための参照ピクチャを判定してもよい。例えば、WTRUは、inter_layer_sample_pred_only_flagを受信しないことがあるが、WTRUは、レイヤ間予測のために利用することができる参照ピクチャを判定してもよい。WTRUによる、例えば、時間予測なしのレイヤ間予測の推測は、inter_layer_sample_pred_only_flagに依拠しないことがある。inter_layer_sample_pred_only_flagがビットストリーム内でシグナリングされない(例えば、および/またはWTRUによって受信されない)場合、WTRUは、時間参照ピクチャを推測してもよい。例えば、WTRUは、例えば、RPSを調べる(例えば、RPSにおけるフラグused_by_curr_pic_flag、used_by_curr_pic_s0_flagおよびused_by_curr_pic_sl_flagが0に設定されてもよい)ことによって、時間参照ピクチャがカレントスライスに対して使用されないことを検出してもよい。時間動きベクトル予測(TMVP)プロセスは、例えば、時間参照ピクチャがカレントスライスのコーディングのために使用されない場合、バイパスされてもよい。例えば、他の関連構文要素は、スキップされてもよい(例えば、他の関連構文要素も、スキップされてもよい)。
slice_temporal_mvp_enabled_flagは、(例えば、SHVCにおいて提供されるような)sps_temporal_mvp_enabled_flagおよび/または強化レイヤ(例えば、nuh_layer_id>0)に対するinter_layer_sample_pred_only_flagに基づいて、シグナリングされてもよい。表9は、そのようなシグナリングの例を示す。例えば、変数InterRefEnabledlnRPLFlagは、下記のように導出されてもよい。NumSamplePredRefLayers[nuh_layer_id]およびNumActiveRefLayerPicsが、0よりも大きい場合、InterRefEnabledlnRPLFlagは、!inter_layer_sample_pred_only_flagに等しくなるように設定されてもよい。そうでない場合、InterRefEnabledlnRPLFlagは、1に等しくなるように設定されてもよい。
inter_layer_sample_pred_only_flagをslice_temporal_mvp_enabled_flagの条件とするために、inter_layer_sample_pred_only_flagおよび(例えば、表9に示されるような)サンプル予測構文構造のシグナリングは、slice_temporal_mvp_enabled_flagに先行して、判定またはシグナリングされてもよい。slice_temporal_mvp_enabled_flagがシグナリングされない場合(例えば、inter_layer_sample_pred_only_flagが1に等しく設定されることが理由で)、slice_temporal_mvp_enabled_flagは、0に等しくなるように推測されてもよい。
slice_temporal_mvp_enabled_flagが0であるとき、alt_collocated_indication_flag、collocated_ref_layer_idx、collocated_from_10_flagおよび/またはcollocated_ref_idxなどの構文要素は、スキップされてもよい(例えば、表9に示されるように)。
slice_temporal_mvp_enabled_flagをinter_layer_sample_pred_only_flagに先行してシグナリングすることができるシグナリング順序が維持されてもよい。条件(InterRefEnabledlnRPLFlag)は、表10に示されるように、TMVPパラメータをシグナリングするために適用されてもよい。InterRefEnabledlnRPLFlagの導出は、ビデオコーディング標準、例えば、SHVCにおいて指定されてもよい。変数InterRefEnabledlnRPLFlagは、下記のように導出されてもよい。NumSamplePredRefLayers[nuh_layer_id]が0よりも大きく、NumActiveRefLayerPicsが0よりも大きい場合、InterRefEnabledlnRPLFlagは、!inter_layer_sample_pred_only_flagに等しくなるように設定されてもよい。そうでない場合、InterRefEnabledlnRPLFlagは、1に等しくなるように設定されてもよい。slice_temporal_mvp_enabled_flagの値は、下記のように変更されてもよい。InterRefEnabledlnRPLFlagが0に等しい場合、slice_temporal_mvp_enabled_flagは、0に等しくなるように設定されてもよい。
時間輝度動きベクトル予測(temporal luma motion vector prediction)のための導出プロセスは、変更されてもよく、変数mvLXColおよびavailableFlagLXColが、導出されてもよい。例えば、slice_temporal_mvp_enabled_flagは、0に等しく、またはInterRefEnabledlnRPLFlagは、0に等しく、mvLXColの成分(例えば、双方の成分)は、0に等しくなるように設定されてもよく、availableFlagLXColは、0に等しくなるように設定されてもよい。
ビデオコーディングデバイス(例えば、SHVCコーディング標準に基づく)は、1または複数の構文要素(例えば、2つの構文要素)、alt_collocated_indication_flagおよび/またはcollocated_ref_layer_idxをスライスヘッダ内でシグナリングして、レイヤ間動き予測のための参照レイヤを示してもよい。元の時間動きベクトル予測(TMVP)は、構文要素collocated_from_lO_flagおよびcollocated_ref_idxを使用して、TMVPのために使用される参照ピクチャを示してもよい。同一のシグナリングは、冗長な構文要素alt_collocated_indication_flagおよびcollocated_ref_layer_idxがシグナリングされないように(例えば、省略されるように)、レイヤ間動き予測に適用されてもよい。表11は、例示的な一般的なスライスセグメントヘッダ構文を示す。
alt_collocated_indication_flagおよびcollocated_ref_layer_idxは、ビデオコーディング標準、例えば、HEVCによって提供されてもよい。TMVPのために使用されるレイヤ間参照ピクチャのうちのいくつかは、サンプル予測のためには使用されないことがある。参照ピクチャリスト内のレイヤ間参照ピクチャのインデックスが使用されて、TMVPのためのレイヤ間配置参照ピクチャが示されてもよい。参照ピクチャリスト内のレイヤ間参照ピクチャのインデックスは、レイヤ間サンプル予測のためには使用されないことがある。レイヤ間参照ピクチャに対応する参照インデックスは、強化レイヤピクチャの予測ブロックによっても参照されないことがあるというビットストリーム制限が課されてもよい。
SNRスケーラビリティをシグナリングするためのシステムおよび/または方法が、提供されてもよい。そのようなシステムおよび/または方法において、そのようなシグナリングは、異なるスケーラビリティ間で区別してもよい。例えば、空間スケーラビリティは、SNRスケーラビリティとは区別されてもよく、その逆もまた同様である。例示的な実施形態において、インジケータ、フラグ、または他の識別子もしくは情報は、SNRスケーラビリティと空間スケーラビリティとを区別してもよい。また、SNRスケーラビリティインジケータなどのインジケータに基づいて、そのようなシグナリングは、(例えば、サンプルのための)再サンプリングプロセスおよび/または動き予測を呼び出し、または実行するべきかを示してもよい。
本明細書において説明されるように、MPEG−2 Video、H.263、MPEG4 VisualおよびH.264などの既存の国際ビデオ標準の各々は、スケーラビリティモードをサポートするツールおよび/またはプロファイルを含んでもよく、または有してもよい。しかしながら、HEVCは、それらの既存の標準によってサポートすることができるそのようなスケーラブルコーディングを現在はサポートしていないことがある。そのため、HEVCは、拡張されて、下記のうちの少なくとも1つを含むそのようなスケーラビリティコーディングをサポートしてもよい:空間スケーラビリティ(すなわち、スケーラブルビットストリームが、2つ以上の空間分解能においてシグナリングしてもよい)、品質スケーラビリティ(すなわち、スケーラブルビットストリームが、2つ以上の品質レベルにおける信号を含んでもよい)、および標準スケーラビリティ(すなわち、スケーラブルビットストリームが、H.264/AVCを使用してコーディングされた基準レイヤと、HEVCを使用してコーディングされた1または複数の強化レイヤとを含む)。例示的な実施形態において、HEVCによってサポートされてもよい品質スケーラビリティは、SNRスケーラビリティも含んでもよい。また、今日では3Dビデオがより人気を得るにつれて、スケーラビリティの付加的な拡張(例えば、2Dビデオ信号および/または3Dビデオ信号を含むスケーラブルビットストリーム)が、(例えば、MPEGにおいて説明または定義されているように)さらに提供され、および/または使用されてもよい。
HEVCのスケーラブル拡張およびマルチビュー拡張に対する共通仕様は、HEVCのスケーラブル拡張(SHVC)のための参照インデックスベースフレームワークを含んでもよい。そのようなフレームワークにおいて、SHVCについての構文、意味(semantics)および復号プロセスが提供されてもよい。参照インデックスベースのフレームワークは、既存の単一レイヤコーデックロジックがスケーラブルコーディングシステム内で再利用されてもよいように、ブロックレベルおよびブロックレベル未満の1または複数の動作をそのままの状態に維持してもよい。フレームワークは、スケーラブルコーデック設計を簡略化してもよく、また、高レベル構文シグナリングおよびレイヤ間処理モジュールを組み込んで、コーディング効率を達成することによって、異なるタイプのスケーラビリティをサポートするようにさらに柔軟になることがある。様々な新たな高レベル構文変化が提供されてもよく、および/またはSHVCのレイヤ間処理およびマルチレイヤシグナリングがサポートされてもよい。
HEVCにおいてそのようなスケーラビリティをシグナリングするために、本明細書において説明されるようなシステムおよび/または方法が提供されてもよい。例えば、空間スケーラビリティは、SNRスケーラビリティとは区別されてもよく、その逆もまた同様である。例示的な実施形態において、インジケータ、フラグ、または他の識別子もしくは情報は、SNRスケーラビリティと空間スケーラビリティとを区別してもよい。また、SNRスケーラビリティインジケータなどのインジケータに基づいて、そのようなシグナリングは、(例えば、サンプルのための)再サンプリングプロセスおよび/または動き予測を呼び出し、または実行するべきかを示してもよい。
スケーラブルビデオコーディングは、複数のレイヤをサポートしてもよく、各レイヤは、空間スケーラビリティ、時間スケーラビリティ、SNR(信号対雑音比)スケーラビリティ、および/または任意の他のタイプのスケーラビリティをサポートしてもよい。スケーラブルビットストリームは、混合されたスケーラビリティレイヤを有してもよく、各強化レイヤは、復号されることになる1または複数の下位レイヤに依存してもよい。レイヤ間プロセスは、レイヤ間参照ピクチャ(ILR)サンプルおよび/または動きフィールド情報を生成して、強化レイヤコーディング効率を強化または改善してもよい。
SNRスケーラビリティシグナリングが、提供および/または使用されてもよい。空間スケーラビリティに対し、ビデオは、異なる分解能において、および異なるレイヤにおいてコーディングされてもよい。例えば、基準レイヤビデオは、720p分解能を有し、強化レイヤは、1080p分解能を有してもよい。また、SNRスケーラビリティについて、ビデオ分解能は、複数のレイヤにわたって同一であってもよいが、異なるレイヤは、異なる品質でコーディングされてもよい。例えば、基準レイヤは、33dBでコーディングされてもよいのに対して、強化レイヤは、36dBでコーディングされてもよい。SHVCにおいて、scalability_maskなどの構文要素は、パラメータセット(例えば、ビデオパラメータセット(VPS))に含まれて、(表12に示されるように)マルチビュースケーラビリティと空間/SNRスケーラビリティとが区別されてもよい。
しかしながら、現在、SHVCにおいて、scalability_mask構文は、空間スケーラビリティとSNRスケーラビリティとを区別しないことがある。例えば、空間スケーラビリティおよびSNRスケーラビリティは、異なるコーデック動作およびメモリ割り当てを使用することができる、2つの異なる種類のスケーラビリティであってもよい。こうした相違点のいくつかの例は、下記の通りである。参照レイヤピクチャサンプルおよび参照レイヤ動きフィールドに対する再サンプリングプロセスは、空間スケーラビリティについては使用されてもよいが、SNRスケーラビリティについては使用されないことがある。また、固定代替再サンプリングフィルタ(fixed alternative resampling filter)(例えば、コア実験SCE3において評価される)などのいくつかのレイヤ間フィルタは、SNRスケーラビリティに対して改善された性能利得を達成してもよいが、空間スケーラビリティに対しては適用可能ではないことがある。適用例は、単ループ設計(例えば、SVC、H.264のスケーラブル拡張によってサポートされてきたことがある)をSNRスケーラビリティについては使用してもよいが、空間スケーラビリティについては使用しなくてもよい。サンプリンググリッド(sampling grid)(例えば、現在、コア実験SCE1が行われている)は、空間スケーラビリティに関連する特定の問題に対処してもよいが、SNRスケーラビリティに関連する特定の問題には対処しなくてもよい。
エンコーダ動作およびデコーダ動作が、サポートすることができる関連コーディングツールに従って構成および/または初期化されてもよいように、高レベル構文において空間スケーラビリティとSNRスケーラビリティとを区別することができるシステム、方法、および手段が、本明細書において説明される。
例えば、現在、SHVCにおいて、SNRスケーラビリティは、再サンプリングプロセス(例えば、非特許文献1のG.8.1.4において説明される再サンプリングプロセスなどの)において指定することができるScaleFactorXなどのスケールファクタから推測されてもよい。ScaleFactorXが1に等しい場合、スケーラビリティは、SNRスケーラビリティであってもよい。スケーラビリティは、SPSおよびSPS拡張を構文解析した後に、導出されてもよい。冗長なコーデック動作ならびにメモリ割り当ておよび/またはメモリアクセスが低減または回避されるように(例えば、構文解析を回避することによって)、SNRスケーラビリティのシグナリングおよび再サンプリングプロセスに対処するために、他のシグナリングオプションが提供されてもよい。
別々のスケーラビリティ次元が、空間スケーラビリティとSNRスケーラビリティとに割り当てられて、例えば、空間スケーラビリティとSNRスケーラビリティとの間で区別してもよい。表13は、空間スケーラビリティおよびSNRスケーラビリティが別個または別々の値を有することができる、変形されたスケーラビリティディメンションテーブルの例示的な実施形態を示す。
表13に示されるように、ViewIdおよびDependencyIdに加えて、変数SnrId[layer_id_in_nuh[i]]が、i番目のレイヤのSNR識別子として提供および/または使用されてもよい。例示的な実施形態によれば、SnrIdは、下記のように導出されてもよい。
加えて、例えば、空間スケーラビリティとSNRスケーラビリティとを区別するために、SNRスケーラビリティフラグが、提供および/または使用されてもよい。例えば、SNRスケーラビリティフラグは、パラメータセット拡張(例えば、ビデオパラメータセット(VPS)拡張)に追加されて、表14に示されるようなSNRスケーラビリティを示してもよい。
例示的な実施形態に従って、SNR_scalability_flagが1に等しい場合、layer_id_in_nuh[i]に等しいnuh_layer_idおよびlayer_id_in_nuh[j]に等しいnuh_layer_idを有するレイヤ間のスケーラビリティは、SNRスケーラビリティを指定してもよく、または示してもよい。SNR_scalability_flagが0に等しい場合、layer_id_in_nuh[i]に等しいnuh_layer_idおよびlayer_id_in_nuh[j]に等しいnuh_layer_idを有するレイヤ間のスケーラビリティは、SNRスケーラビリティではないことがある(例えば、SNRスケーラビリティを指定しないことがあり、または示さないことがある)。また、SNR_scalability_flagが提供されない場合、それは、0に等しくなるように予測されてもよい。
本明細書において説明されるように、復号は、例えば、再サンプリングプロセスの一部として実行されてもよい。例示的な再サンプリングプロセスに関連付けられた復号処理は、下記のように実行されてもよい。PicWidthlnSamplesLがRefLayerPicWidthlnSamplesLに等しく、PicHeightlnSamplesLがRefLayerPicHeightlnSamplesLに等しく、ScaledRefLayerLeftOffset、ScaledRefLayerTopOffset、ScaledRefLayerRightOffsetおよび/またはScaledRefLayerBottomOffsetの値の各々が0に等しい場合、例えば、alt_collocated_indication_flagが1に等しくなることがあるとき、rsPicSampleは、rlPicSampleに設定されてもよく、rsPicMotionは、rlPicMotionに等しくなるように設定されてもよい。rsPicは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.1項で指定されるような)は、入力としてrlPicSampleのサンプル値で、および、出力としてrsPicSampleの再サンプリングされたサンプル値で呼び出されてもよい。alt_collocated_indication_flagが1に等しい場合、ピクチャ動きフィールド再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.2項で指定されるような)は、入力としてrlPicMotionで、および、出力としてrsPicMotionの再サンプリングされた動きフィールドで呼び出されてもよい。
本明細書において説明されるSNR_scalability_flagを使用して、例示的な再サンプリングプロセスは、下記のように提供されてもよい。例えば、SNR_scalability_flagが1に設定される場合、rsPicSampleは、rlPicSampleに等しくなるように設定されてもよい。また、alt_collocated_indication_flagが1に等しくすることができるとき、かつ、SNR_scalability_flagが1に設定される場合、rsPicMotionは、rlPicMotionに設定されてもよい。rsPicは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.1項において指定されるような)は、入力としてのrlPicSampleのサンプル値で、および出力してのrsPicSampleの再サンプリングされたサンプル値で呼び出されてもよい。alt_collocated_indication_flagが1に等しくなることができるとき、ピクチャ動きフィールド再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.2項において指定されるような)は、入力としてのrlPicMotionで、および、出力としてのrsPicMotionの再サンプリングされた動きフィールドで呼び出されてもよい。
例示的な実施形態において、1または複数の例外が、提供されてもよく、および/または存在してもよい。1つのそのような例外は、基底レイヤ(BL:base layer)をAVCコーディングすることができるハイブリッド標準スケーラビリティを含んでもよく、またはハイブリッド標準スケーラビリティであってもよい。ビデオコーディングサイズは、HEVC ELとAVC BLとの間で異なってもよい。例えば、AVC基底レイヤ(BL)およびHEVC強化レイヤ(EL)の両方が1920×1080ビデオを符号化してもよい場合、復号されたBL参照ピクチャサイズは、1920×1088となってもよく、強化コーディングピクチャサイズは、1920×1080となってもよい(例えば、これは、AVC標準およびHEVC標準が異なるパディングプロセスを適用するためである)。輝度サンプルおよび/または彩度サンプルの再サンプリングは必要ではないことがあるが、復号された参照ピクチャ(1920×1088)は、ELピクチャ(1920×1080)を予測するために直接使用されないことがあり、対応するトリミングされた領域は、ILRピクチャ内へコピーされてもよい。
そのような例外に対処するために、本明細書において説明されるように使用することができる複数の方法が存在する。例えば、方法において、1または複数のスケーリングされたオフセットの値に関わらず、BLビデオコーディングサイズとELビデオコーディングサイズとが同一とすることができるとき、SNR_scalability_flagは、1に制限されてもよい。そのような制限は、ビットストリーム適合制限(bitstream conformance restriction)の形式において提供されてもよく、および/または課されてもよく、エンコーダがSNR_scalability_flagの値を適切に設定することができることを保証してもよい。その場合において、SNR_scalability_flagは、上記の1920×1080ハイブリッド標準スケーラビリティに対しては0に設定されてもよく、レイヤ間参照ピクチャは、再サンプリングプロセス(例えば、非特許文献1のSHVC WD G.8.1.4.1において指定されるように)に従って、1920×1088AVC基準レイヤピクチャから導出されてもよい。
方法において、スケールファクタScaleFactorX(例えば、G.8.1.4.において指定されるような)が0に等しくなることができるとき、SNR_scalability_flagは、1に設定される。そのような方法において、再サンプリングプロセスは、さらに変形されて、下記のような特別なケースをカバーしてもよい。rlPicおよびrsPic(例えば、SHVC WD G.8.1.4において定義されるような)に加えて、別のトリミングされた参照レイヤピクチャrcPcが、再サンプリングプロセスに追加されてもよい。変数CroppedRefLayerPicWidthinSamplesLおよびCroppedRefLayerPicWidthinSamplesLは、Picの幅および高さと輝度サンプルの単位でそれぞれ等しくなるように設定されてもよい。変数rcPicSampleは、輝度成分および彩度成分のrcPicのサンプル値を指定するサンプルアレイのグループとしてさらに定義されてもよい。また、rcPicMotionは、rcPicの圧縮された動きフィールドを指定する可変アレイ(variable array)のグループとして定義されてもよい。
変数RefLayerPicWidthlnSamplesLおよびRefLayerPicHeightlnSamplesLは、復号された参照レイヤピクチャrlPicの幅および高さ、ならびに輝度サンプルの単位においてそれぞれ等しくなるように設定される。輝度サンプル位置[xP][yP]は、rlPicの左上のサンプルを指定してもよい。また、変数rcLeftStart、rcRightEnd、rcTopStartおよびrcBottomEndは、下記のように導出されてもよい。
rcPicは、左上位置(rcLeftStart,rcTopStart)および右下位置(rcRightEnd,rcBottomEnd)でrlPicをトリミングすることによって導出されてもよい。図5は、トリミングの例を示す。図5に示されるように、rcPicは、スケーリングされたオフセットがゼロではないことがあるときに、rlPicから導出されてもよい。
再サンプリングプロセスは、下記のように提供されてもよい。SNR_scalability_flagを1に設定することができる場合、rsPicSampleは、rcPicSampleと等しくなるように設定されてもよく、alt_collocated_indication_flagを1に等しくすることができるとき、rsPicMotionは、rcPicMotionに等しく設定されてもよい。rsPicは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.1項において指定されるような)は、入力としてのrlPicSampleのサンプル値、および出力としてのrsPicSampleの再サンプリングされたサンプル値で呼び出されてもよい。ピクチャ動きフィールド再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.2項において指定されるような)は、例えば、alt_collocated_indication_flagが1に等しいとき、入力としてのrlPicMotion、および出力としてのrsPicMotionの再サンプリングされた動きフィールドで呼び出されてもよい。
空間スケーラビリティおよびSNRスケーラビリティは、例えば、不要な再サンプリング動作および/またはメモリ割り当てを回避するために区別されてもよい。付加的または追加的な構文要素は、パラメータセット拡張(例えば、表15に示されるような、ビデオパラメータセット(VPS)拡張)においてシグナリングされて、再サンプリングプロセスをバイパスすることができるか否かを示してもよい。
0に等しくすることができるresampling_buffer_enable_flag[i][j]は、i番目のレイヤとj番目のレイヤとの間の再サンプリングプロセスをバイパスすることができ、および再サンプリングバッファが割り当てられな九手も良いことを示し、または指定してもよい。1に等しくすることができるresampling_buffer_enable_flagは、ピクチャサンプルまたは動き値の再サンプリングプロセスに対する関連するバッファを呼び出すことができることを示し、または指定してもよい。resampling_buffer_enable_flagが存在しないことがあるとき、デフォルト値は0であってもよい。再サンプリングプロセスは、下記のように修正されてもよい。resampling_buffer_enable_flagが0に設定されてもよい場合、rsPicSampleは、rlPicSampleに等しく設定されてもよく、alt_collocated_indication_flagが1に等しくなることがあるとき、rsPicMotionは、rlPicMotionに等しくなるように設定されてもよい。rsPicは、下記のように導出されてもよい。ピクチャサンプル再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.1項において指定されるような)は、入力としてのrlPicSampleのサンプル値、および出力としてのrsPicSampleの再サンプリングされたサンプル値で呼び出されてもよい。また、alt_collocated_indication_flagが1に等しいことがあるとき、ピクチャ動きフィールド再サンプリングプロセス(例えば、非特許文献1のG.8.1.4.2項において指定されるような)は、入力としてのrlPicMotion、および出力としてのrsPicMotionの再サンプリングされた動きフィールドで呼び出されてもよい。
resampling_buffer_enable_flagは、direct_dependency_type構文要素とは結合されなくてもよい。resampling_buffer_enable_flagは、表17に示されるようにシグナリングされてもよい(例えば、独立してシグナリングされてもよい)。resampling_buffer_enable_flagは、再サンプリングされた参照ピクチャおよび動きをサンプル予測および/または動き予測以外の目的のために使用することができるように、柔軟性を与えることができる。例えば、再サンプリングされた動きは、ハイブリッドレイヤ間参照ピクチャが生成するために使用されてもよい。
resampling_buffer_enable_flagは、direct_dependency_type構文要素と結合されなくてもよい。resampling_buffer_enable_flagは、SNR_scalability_flagとしてシグナリングされてもよく(例えば、独立してシグナリングされてもよい)、resampling_buffer_enable_flagは、SPSもしくはSPS拡張または任意の他の適当なパラメータセットで配置されてもよい。表17は、SPS拡張においてSNR_scalability_flagをシグナリングする例示的な実施形態を示す。表17に示されるような構文要素num_SNR_scalability_flagは、シグナリングされるフラグの数を示してもよい。num_SNR_scalability_flagの値は、現在の強化レイヤの参照レイヤの数と等しくてもよい。num_scaled_ref_layer_offsetsの値は、現在の強化レイヤの参照レイヤの数と等しくてもよい。表19に示されるように、構文要素num_SNR_scalability_flagおよびnum_scaled_ref_layer_offsetsは、1つの構文要素、例えば、num_ref_layersとして組み合わされ、およびシグナリングされてもよい。
本明細書において説明されるようなSNRスケーラビリティシグナリングで、コーデック動作は、1または複数の構文要素をシグナリングして、シグナリングされるビットの数を節約し、それによって、効率を向上させることができる。例えば、本明細書において説明されるようなSNR_scalability_flag(例えば、上述されたようにVPS拡張に追加されてもよい)は、様々な適用シナリオにおいて使用されてもよい。
例えば、サンプリンググリッドシフトシグナリング(sampling grid shift signaling)が、例えば、SNR_scalability_flagと共に、提供および/または使用されてもよい。サンプリンググリッドシフト情報は、様々な技法および/または方法(例えば、非特許文献2において提案されるような)を使用してサンプリングされてもよい。例えば、サンプリンググリッド情報は、フェーズオフセット存在フラグ(phase offset present flag)ならびに輝度フェースオフセットパラメータおよび/または彩度フェースオフセットパラメータで、SPS拡張においてシグナリングされてもよい。サンプリングフェーズシフトは、空間スケーラビリティに適用可能であるため、提案されるSNR_scalability_flagは、SNRスケーラビリティについてのビットストリーム内に存在する不要な構文要素を回避するための条件として使用されてもよい。表18は、追加的なサンプリンググリッドパラメータをシグナリングすることができるかを判定するための条件として、SNR_scalability_flagシグナリングを使用することができる例示的な構文テーブルを示す。
スケーリングされた参照レイヤオフセットがまた、提供および/または使用されてもよい。例えば、SPS拡張においてシグナリングすることができるスケーリングされた参照レイヤオフセット構文要素は、基準レイヤおよび強化レイヤを調節するために使用されてもよい。SNRスケーラビリティでは、スケーリングされたオフセットはゼロであってもよく、そのため、SNR_scalability_flagをこれらのオフセットのシグナリングの条件とすることによって、追加的なビットは、SNRスケーラブルレイヤに対してスケーリングされたオフセットシグナリングをスキップすることによって節約されてもよい。表19は、そのようなシグナリングの例を示す。
num_ref_layersの意味(semantic)は、SPSに存在することができるスケーリングされた参照レイヤオフセットパラメータのセットの数を指定することができるVPSにおいてシグナリングすることができる従属レイヤ(例えば、参照レイヤ)の数と一致させるには正確ではないことがある。一実施形態において、num_ref_layersの値は、0〜63を含む範囲になってもよい。意味は、下記のように修正されてもよい。num_ref_layersは、SPSに存在することができるスケーリングされた参照レイヤオフセットパラメータのセットの数を指定してもよく、または示してもよい。num_ref_layersの値は、NumDirectRefLayers[nuh_layer_id](例えば、ビットストリーム適合制限の一部としての、また、非特許文献1のF.7.4.3.1.1において指定されるような)に等しくてもよい。
レイヤ間フィルタリングシグナリングが、提供および/または使用されてもよい。例えば、切り替え可能な整数位置フィルタ(switchable integer position filter)(例えば、レイヤ間フィルタリングに関するコア実験(SCE3)において提供することができる非特許文献3において説明されるフィルタなどの)は、SNRスケーラビリティについては性能利得を達成してもよいが、空間スケーラビリティについては達成しないことがある。そのため、様々なフィルタ切り替え方法が、提供および/または使用されてもよい。例えば、フィルタ切り替えは、スライスヘッダにおいてシグナリングされてもよく、また、追加的な実施形態においては、ILRとフィルタリングされたILRとの両方が、レイヤ間予測のための参照ピクチャリスト(RPL)内に挿入されてもよい。例えば、スライスヘッダにおける1ビット構文要素は、SNR_scalability_flagが0に設定されるときに、バイパスされてもよく、それは、そのようなフィルタは、空間スケーラビリティシナリオについての性能を改善しないことがあるためである。別の例において、SNR_scalability_flagが0に設定されるとき、アクティブレイヤ間参照ピクチャの数が低減されてもよく、それは、例えば、フィルタリングされたILRピクチャは、参照ピクチャセットおよび参照ピクチャリスト内も追加されないことがあるためである。SNRスケーラビリティインジケータをシグナリングすることは、参照ピクチャリスト構築プロセスを簡略化し、空間スケーラビリティケースについて、DPBメモリサイズを事前に節約することができる。SNR_scalability_flagは、再サンプリングプロセスにおいて参照されて、空間スケーラビリティ(SNR_scalability_flagは0に設定される)についての切り替え可能な整数位置フィルタ(例えば、非特許文献3において説明されるフィルタなどの)をバイパスして、コーデック動作複雑度およびメモリ割り当てを低減してもよい。
複数のフラグが、パラメータセット(例えば、ビデオパラメータセット)においてシグナリングされてもよい。フラグの各々は、スケーラブルビットストリームのレイヤ(例えば、基準レイヤおよび従属強化レイヤ)に関連付けられた再サンプリングプロセスが実行される必要があるかを示してもよい。再サンプリングプロセスが必要とされないことをフラグが示すことを条件に、再サンプリングバッファの割り当てがバイパスされてもよい。再サンプリングプロセスが必要とされることをフラグが示すことを条件に、1または複数の再サンプリングバッファが割り当てられてもよく、参照ピクチャサンプルに関連付けられた参照ピクチャサンプルまたは動きのうちの1つまたは複数の再サンプリングが呼び出されてもよい。
本明細書において説明されるシグナリングは、例えば、本明細書において説明されるネットワークまたは適切なネットワーク要素のうちのいずれかにおいて使用されてもよい。例えば、本明細書において説明されるシグナリングは、図6A〜図6Eに示される例示的な無線通信システム100および/またはその構成要素などの無線通信システムに関連付けられたデバイス(例えば、ビデオストリーミングデバイス)によって実装されるスケーラブルビデオコーディングに従って、実装されてもよい。
図6Aは、1または複数の開示された実施形態を実装および/または使用することができる例示的な通信システム100の図を示す。通信システム100は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザへ提供する多元接続システムであってもよい。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、そのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC−FDMA)などの、1または複数のチャネルアクセス方法を採用してもよい。
図6Aに示されるように、通信システム100は、無線送受信ユニット(WTRU)102a、102b、102c、および/または102d(これらは、一般に、または、まとめて、WTRU102と称されてもよい)と、無線アクセスネットワーク(RAN)103/104/105と、コアネットワーク106/107/109と、公衆交換電話網(PSTN)108と、インターネット110と、他のネットワーク112とを含んでもよいが、開示される実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を想定することを認識されるであろう。WTRU102a、102b、102c、および/または102dの各々は、無線環境において動作および/または通信するように構成された、任意のタイプのデバイスであってもよい。例として、WTRU102a、102b、102c、および/または102dは、無線信号を送信および/または受信するように構成されてもよく、ユーザ機器(UE)、移動局、固定加入者ユニットまたは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでもよい。
通信システム100はまた、基地局114aおよび基地局114bを含んでもよい。基地局114a、114bの各々は、WTRU102a、102b、102c、および/または102dのうちの少なくとも1つと無線でインターフェースして、コアネットワーク106/107/109、インターネット110、および/またはネットワーク112などの、1または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってもよい。例として、基地局114aおよび/または114bは、基地送受信局(BTS)、ノードB、eNodeB、ホームノードB、ホームeNodeB、サイトコントローラ、アクセスポイント(AP)、無線ルータなどであってもよい。基地局114a、114bの各々は、単一の要素として示されるが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含んでもよいことを認識されるであろう。
基地局114aは、RAN103/104/105の一部であってもよく、これは、基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、中継ノードなどの他の基地局および/またはネットワーク要素(図示せず)も含んでもよい。基地局114aおよび/または基地局114bは、セル(図示せず)と称されてもよい特定の地理的領域内で無線信号を送信および/または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。例えば、基地局114aに関連付けられたセルは、3つのセクタに分割されてもよい。したがって、1つの実施形態において、基地局114aは、3つの送受信器、すなわち、セルのセクタごとに1つの送受信器を含んでもよい。別の実施形態において、基地局114aは、多入力多出力(MIMO:multiple-input multiple output)技術を採用してもよく、したがって、セルのセクタごとに複数の送受信器を利用してもよい。
基地局114aおよび/または114bは、WTRU102a、102b、102c、および/または102dのうちの1または複数と、エアインターフェース115/116/117上で通信してもよい。これは、任意の適切な無線通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光等)であり得る。エアインターフェース115/116/117は、任意の適切な無線アクセス技術(RAT:radio access technology)を使用して確立されてもよい。
より具体的には、上述されたように、通信システム100は、多元接続システムであってもよく、CDMA、TDMA、FDMA、OFDMA、SC−FDMAなどの、1または複数のチャネルアクセス方式を採用してもよい。例えば、RAN103/104/105内の基地局114aならびにWTRU102a、102b、および/または102cは、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)地上波無線アクセス(UTRA)などの無線技術を実装してもよい。これは、広帯域CDMA(WCDMA(登録商標))を使用してエアインターフェース115/116/117を確立してもよい。WCDMAは、高速パケットアクセス(HSPA)および/または進化型HSPA(HSPA+)などの通信プロトコルを含んでもよい。HSPAは、高速ダウンリンクパケットアクセス(HSDPA)および/または高速アップリンクパケットアクセス(HSUPA)を含んでもよい。
別の実施形態において、基地局114aならびにWTRU102a、102b、および/または102cは、進化型UMTS地上波無線アクセス(E−UTRA)などの無線技術を実装してもよい。これは、ロングタームエボリューション(LTE)および/またはLTE−Advanced(LTE−A)を使用してエアインターフェース115/116/117を確立してもよい。
他の実施形態において、基地局114aおよびWTRU102a、102b、および/または102cは、IEEE802.16(Worldwide interoperability for Microwave Access(WiMAX)、CDMA2000、CDMA2000 1X、CDMA2000 EV−DO、Interim Standard 2000(IS−2000)、Interim Standard 95(IS−95)、Interim Standard 856(IS−856)、Global System for Mobile communications(GSM(登録商標))、Enhanced Data rates for GSM Evolution(EDGE)、GSM EDGE(GERAN)などの無線技術を実装してもよい。
図10Aにおける基地局114bは、例えば、無線ルータ、ホームノードB、ホームeNodeB、またはアクセスポイントであってもよく、職場、家庭、車両、キャンパスなどの局所的なエリアにおける無線接続性を容易にするために任意の適切なRATを利用してもよい。一実施形態において、基地局114bおよびWTRU102c、102dは、IEEE802.11などの無線技術を実装して、無線ローカルエリアネットワーク(WLAN)を確立してもよい。別の実施形態において、基地局114bおよびWTRU102c、102dは、IEEE802.15などの無線技術を実装して、無線パーソナルエリアネットワーク(WPAN)を確立してもよい。また別の実施形態において、基地局114bおよびWTRU102c、102dは、セルラベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、LET−Aなど)を利用して、ピコセルまたはフェムトセルを確立してもよい。図6Aに示されるように、基地局114bは、インターネット110への直接接続を有してもよい。したがって、基地局114bは、コアネットワーク106/107/109を介してインターネット110へアクセスすることを必要とされないことがある。
RAN103/104/105は、コアネットワーク106/107/109と通信していることがあってもよく、これは、音声、データ、アプリケーション、および/またはボイスオーバーインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、および/または102dのうちの1または複数へ提供するように構成された、任意のタイプのネットワークであってもよい。例えば、コアネットワーク106/107/109は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド電話、インターネット接続性、ビデオ配信等を提供し、ユーザ認証などの高レベルのセキュリティ機能を実行してもよい。図6Aには示されていないが、RAN103/104/105および/またはコアネットワーク106/107/109は、RAN103/104/105と同じRATまたは異なるRATを採用する他のRANと直接通信または間接通信していることがあってもよいことを認識されるであろう。例えば、E−UTRA無線技術を利用中であり得るRAN103/104/105に接続されることに加えて、コアネットワーク106/107/109は、GSM無線技術を採用する別のRAN(図示せず)とも通信していることがあってもよい。
コアネットワーク106/107/109は、WTRU102a、102b、102c、および/または102dのためのゲートウェイとしての機能も果たしてもよく、PSTN108、インターネット110、および/または他のネットワーク112へアクセスしてもよい。PSTN108は、旧来型電話サービス(POTS)を提供する回線交換電話網を含んでもよい。インターネット110は、TCP/IPインターネットプロトコルスイートにおける送信制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)およびインターネットプロトコル(IP)などの共通通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク112は、他のサービスプロバイダによって所有および/または運用される有線通信ネットワークまたは無線通信ネットワークを含んでもよい。例えば、ネットワーク112は、RAN103/104/105と同じRATまたは異なるRATを採用してもよい1または複数のRANに接続された別のコアネットワークを含んでもよい。
通信システム100内のWTRU102a、102b、102c、および/または102dのうちの一部または全部は、マルチモード能力を含んでもよい。すなわち、WTRU102a、102b、102c、および/または102dは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信器を含んでもよい。図6Aに示されるWTRU102cは、セルラベースの無線技術を採用してもよい基地局114aと、IEEE802無線技術を採用してもよい基地局114bと通信するように構成されてもよい。
図6Bは、例示的なWTRU102のシステム図を示す。図6Bに示されるように、WTRU102は、プロセッサ118と、送受信器120と、送受信要素122と、スピーカ/マイクロフォン124と、キーパッド126と、ディスプレイ/タッチパッド128と、非リムーバブルメモリ130と、リムーバブルメモリ132と、電源134と、全地球測位システム(GPS)チップセット136と、他の周辺機器138とを含んでもよい。WTRU102は、実施形態との整合性を維持したまま、前述の要素の任意のサブコンビネーションを含んでもよいことを認識されるであろう。また、実施形態は、特に、トランシーバステーション(BTS)、ノードB、サイトコントローラ、アクセスポイント(AP)、ホームノードB、進化型ホームノードB(eNodeB)、ホーム進化型ノードB(HeNB)、ホーム進化型ノードBゲートウェイ、およびプロキシノードなどであって、これらに限定されない、基地局114aおよび114b、ならびに/または基地局114aおよび114bが表してもよいノードが、図6Bに示され、かつ、本明細書において説明される要素のうちの一部または全部を含んでもよい。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアに関連付けられた1または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、任意の他のタイプの集積回路(IC)、状態機械などであってもよい。プロセッサ118は、信号コーディング、データ処理、電力制御、入出力処理、および/またはWTRU102が無線環境において動作することを可能にする任意の他の機能性を実行してもよい。プロセッサ118は、送受信要素122に結合されてもよい送受信器120に結合されてもよい。図6Bは、プロセッサ118と送受信器120とを別々の構成要素として示しているが、プロセッサ118および送受信器120は、電子パッケージまたはチップにおいて一体化されてもよいことを認識されてもよい。
送受信要素122は、エアインターフェース115/116/117上で、信号を基地局(例えば、基地局114a)へ送信し、または信号を基地局から受信するように構成されてもよい。例えば、一実施形態において、送受信要素122は、RF信号を送信および/または受信するように構成されたアンテナであってもよい。別の実施形態において、送受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成されたエミッタ/ディテクタであってもよい。また別の実施形態において、送受信要素122は、RFと光信号との双方を送信および受信するように構成されてもよい。送受信要素122は、無線信号の任意の組み合わせを送信および/または受信するように構成されてもよいことを認識されるであろう。
また、送受信要素122は、図6Bにおいて単一の要素として示されているが、WTRU102は、任意の数の送受信要素122を含んでもよい。より具体的には、WTRU102は、MIMO技術を採用してもよい。したがって、一実施形態において、WTRU102は、エアインターフェース115/116/117上で無線信号を送信および受信するために、2つ以上の送受信要素122(例えば、複数のアンテナ)を含んでもよい。
送受信器120は、送受信要素122によって送信されるべき信号を変調し、送受信要素122によって受信される信号を復調するように構成されてもよい。上述されたように、WTRU102は、マルチモード能力を有してもよい。したがって、送受信器120は、例えば、UTRAおよびIEEE802.11などの複数のRATを介してWTRU102が通信することを可能にするために、複数の送受信器を含んでもよい。
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128(例えば、液晶ディスプレイ(LCD)ディスプレイユニットもしくは有機発光ダイオード(OLED)ディスプレイユニット)に結合されてもよく、これらからユーザ入力データを受信してもよい。プロセッサ118はまた、スピーカ/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド128へユーザデータを出力してもよい。また、プロセッサ118は、非リムーバブルメモリ130および/またはリムーバブルメモリ132などの、任意のタイプの適切なメモリからの情報にアクセスし、任意のタイプの適切なメモリにデータを記憶してもよい。非リムーバブルメモリ130は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、ハードディスク、または任意の他のタイプのメモリストレージデバイスを含んでもよい。リムーバブルメモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、セキュアデジタル(SD)メモリカードなどを含んでもよい。他の実施形態において、プロセッサ118は、サーバまたは家庭用コンピュータ(図示せず)上など、WTRU102に物理的に位置しないメモリからの情報にアクセスし、WTRU102に物理的に位置しないメモリにデータを記憶してもよい。
プロセッサ118は、電源134から電力を受信してもよく、また、WTRU102内の他の構成要素へ電力を分配および/または制御するように構成されてもよい。電源134は、WTRU102に電力供給するための任意の適切なデバイスであってもよい。例えば、電源134は、1または複数の乾電池(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池などを含んでもよい。
プロセッサ118は、WTRU102の現在の位置に関する位置情報(例えば、経度および緯度)を提供するように構成されてもよいGPSチップセット136にも結合されてもよい。GPSチップセット136からの情報に加えて、またはその代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインターフェース115/116/117上で位置情報を受信し、および/または、2つ以上の近くの基地局から受信されている信号のタイミングに基づいて、その位置を判定してもよい。WTRU102は、実施形態との整合性を維持したまま、任意の適切な位置判定方法によって位置情報を取得してもよいことが認識されるであろう。
プロセッサ118は、追加的な特徴、機能性および/または有線接続性もしくは無線接続性を提供する、1または複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含んでもよい、他の周辺機器138にさらに結合されてもよい。例えば、周辺機器138は、加速度計、電子コンパス、衛星送受信器、(写真またはビデオ用の)デジタルカメラ、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビ送受信器、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザなどを含んでもよい。
図6Cは、実施形態に係るRAN103およびコアネットワーク106のシステム図を示す。上述されたように、RAN103は、UTRA無線技術を採用して、WTRU102a、102b、および/または102cとエアインターフェース115上で通信してもよい。RAN103は、コアネットワーク106とも通信していることがあってもよい。図6Cに示されるように、RAN103は、ノードB140a、140b、および/または140cを含んでもよい。これらの各々は、WTRU102a、102b、および/または102cとエアインターフェース115上で通信するための1または複数の送受信器を含んでもよい。ノードB140a、140b、および/または140cの各々は、RAN103内の特定のセル(図示せず)に関連付けられてもよい。RAN103は、RNC142aおよび/または142bも含んでもよい。RAN103は、実施形態との整合性を維持したまま、任意の数のノードBおよびRNCを含んでもよいことを認識されるであろう。
図6Cに示されるように、ノードB140aおよび/または140bは、RNC142aと通信していてもよい。また、ノードB140cは、RNC142bと通信していてもよい。ノードB140a、140b、および/または140cは、それぞれのRNC142a、142bとIubインターフェースを介して通信してもよい。RNC142a、142bは、Iurインターフェースを介して互いに通信してもよい。RNC142a、142bの各々は、それが接続されているそれぞれのノードB140a、140b、および/または140cを制御するように構成されてもよい。また、RNC142a、142bの各々は、外側ループ電力制御、負荷制御、受付制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化等などの他の機能性を実行またはサポートするように構成されてもよい。
図6Cに示されるコアネットワーク106は、メディアゲートウェイ(MGW)144、モバイルスイッチングセンタ(MSC)146、サービングGPRSサポートノード(SGSN)148、および/またはゲートウェイGPRSサポートノード(GGSN)150を含んでもよい。前述の要素の各々は、コアネットワーク106の一部として描かれているが、これらの要素のうちのいずれか1つが、コアネットワーク事業者以外のエンティティによって所有または運用されてもよいことが認識されるであろう。
RAN103内のRNC142aは、IuCSインターフェースを介してコアネットワーク106内のMSC146に接続されてもよい。MSC146は、MGW144に接続されてもよい。MSC146およびMGW144は、WTRU102a、102b、および/または102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。
RAN103内のRNC142aは、IuPSインターフェースを介してコアネットワーク106内のSGSN148にも接続されてもよい。SGSN148は、GGSN150に接続されてもよい。SGSN148およびGGSN150は、WTRU102a、102b、および/または102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cとIP対応デバイスとの間の通信を容易にしてもよい。
上述されたように、コアネットワーク106は、他のサービスプロバイダによって所有および/または運用される他の有線ネットワークまたは無線ネットワークを含むことができるネットワーク112にも接続されてもよい。
図6Dは、実施形態に係るRAN104およびコアネットワーク107のシステム図を示す。上述されたように、RAN104は、E−UTRA無線技術を採用して、WTRU102a、102b、および/または102cとエアインターフェース116上で通信してもよい。RAN104は、コアネットワーク107とも通信していてもよい。
RAN104は、eNodeB160a、160b、および/または160cを含んでもよいが、RAN104は、実施形態との整合性を維持したまま、任意の数のeNodeBを含んでもよいことを認識されるであろう。eNodeB160a、160b、および/または160cの各々は、WTRU102a、102b、および/または102cとエアインターフェース116上で通信するための1または複数の送受信器を含んでもよい。一実施形態において、eNodeB160a、160b、および/または160cは、MIMO技術を実装してもよい。したがって、例えば、eNodeB160aは、複数のアンテナを使用して、WTRU102aへ無線信号を送信し、またはWTRU102aから無線信号を受信してもよい。
eNodeB160a、160b、および/または160cの各々は、特定のセル(図示せず)に関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてもよい。図6Dに示されるように、eNodeB160a、160b、および/または160cは、X2インターフェースを介して互いに通信してもよい。
図6Dに示されるコアネットワーク107は、モビリティマネジメントゲートウェイ(MME)162と、サービングゲートウェイ164と、パケットデータネットワーク(PDN)ゲートウェイ166とを含んでもよい。前述の要素の各々は、コアネットワーク107の一部として描かれているが、これらの要素のうちのいずれか1つが、コアネットワーク事業者以外のエンティティによって所有および/または運用されてもよいことを認識されるであろう。
MME162は、S1インターフェースを介してRAN104内のeNodeB160a、160b、および/または160cの各々に接続されてもよく、制御ノードとしての機能を果たしてもよい。例えば、MME162は、WTRU102a、102b、および/または102cのユーザを認証すること、ベアラアクティブ化/非アクティブ化、WTRU102a、102b、および/または102cの初期アタッチの間に特定のサービングゲートウェイを選択することなどに関与してもよい。MME162は、RAN104と、GSMまたはWCDMAなどの他の無線技術を採用する他のRAN(図示せず)との間の切り替えのための制御プレーン機能も提供してもよい。
サービングゲートウェイ164は、S1インターフェースを介してRAN104内のeNodeB160a、160b、および/または160cの各々に接続されてもよい。サービングゲートウェイ164は、一般に、WTRU102a、102b、および/または102cへ/からユーザデータパケットをルーティングおよび/または転送してもよい。サービングゲートウェイ164は、eNodeB間のハンドオーバの間にユーザプレーンをアンカーリングすること、ダウンリンクデータがWTRU102a、102b、および/または102cについて利用可能である場合にページングをトリガすること、WTRU102a、102b、および/または102cのコンテキストを管理および記憶することなどの他の機能も実行してもよい。
サービングゲートウェイ164は、PDNゲートウェイ166にも接続されてもよい。これは、WTRU102a、102b、および/または102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cとIP対応デバイスとの間の通信を容易にしてもよい。
コアネットワーク107は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク107は、WTRU102a、102b、および/または102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク107yは、コアネットワーク107とPSTN108との間のインターフェースとしての機能を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含んでもよく、またはIPゲートウェイと通信してもよい。また、コアネットワーク107は、WTRU102a、102b、および/または102cに、他のサービスプロバイダによって所有および/または運用される他の有線ネットワークまたは無線ネットワークを含むことができるネットワーク112へのアクセスを提供してもよい。
図6Eは、実施形態に係るRAN105およびコアネットワーク109のシステム図を示す。RAN105は、IEEE802.16無線技術を採用して、WTRU102a、102b、および/または102cとエアインターフェース117上で通信するアクセスサービスネットワーク(ASN)であってもよい。下記でさらに議論されるように、WTRU102a、102b、および/または102c、RAN105、ならびにコアネットワーク109の異なる機能エンティティ間の通信リンクは、基準点として定義されてもよい。
図6Eに示されるように、RAN105は、基地局180a、180b、および/または180c、ならびにASNゲートウェイ182を含んでもよいが、RAN105は、実施形態との整合性を維持したまま、任意の数の基地局およびASNゲートウェイを含んでもよいことを認識されるであろう。基地局180a、180b、および/または180cの各々は、RAN105内の特定のセル(図示せず)に関連付けられてもよく、WTRU102a、102b、および/または102cとエアインターフェース117上で通信するための1または複数の送受信器を含んでもよい。一実施形態において、基地局180a、180b、および/または180cは、MIMO技術を実装してもよい。したがって、例えば、基地局180aは、複数のアンテナを使用して、WTRU102aへ無線信号を送信し、WTRU102aから無線信号を受信してもよい。基地局180a、180b、および/または180cは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、サービスの品質(QoS)ポリシー強化などのモビリティ管理機能も提供してもよい。ASNゲートウェイ182は、トラフィックアグリゲーションポイントとしての機能を果たしてもよく、ページング、加入者プロファイルのキャッシング、コアネットワーク109へのルーティングなどに関与してもよい。
WTRU102a、102b、および/または102cとRAN105との間のエアインターフェース117は、IEEE802.16仕様を実装するR1基準点として定義されてもよい。また、WTRU102a、102b、および/または102cの各々は、コアネットワーク109と論理インターフェース(図示せず)を確立してもよい。WTRU102a、102b、および/または102cとコアネットワーク109との間の論理インターフェースは、認証、許可、IPホスト構成管理、および/またはモビリティ管理のために使用されてもよいR2基準点として定義されてもよい。
基地局180a、180b、および/または180cの各々の間の通信リンクは、WTRUハンドオーバおよび基地局間のデータの転送を容易にするためのプロトコルを含むR8基準点として定義されてもよい。基地局180a、180b、および/または180cとASNゲートウェイ182との間の通信リンクは、R6基準点として定義されてもよい。R6基準点は、WTRU102a、102b、および/または102cの各々に関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするためのプロトコルを含んでもよい。
図6Eに示されるように、RAN105は、コアネットワーク109に接続されてもよい。RAN105とコアネットワーク109との間の通信リンクは、例えば、データ転送およびモビリティ管理能力を容易にするためのプロトコルを含むR3基準点として定義されてもよい。コアネットワーク109は、モバイルIPホームエージェント(MIP−HA)184と、認証、許可、課金(AAA:authentication, authorization, accounting)サーバ186と、ゲートウェイ188とを含んでもよい。前述の要素の各々は、コアネットワーク109の一部として示されているが、これらの要素のうちのいずれか1つは、コアネットワーク事業者以外のエンティティによって所有および/または運用されてもよいことを認識されるであろう。
MIP−HAは、IPアドレス管理に関与してもよく、WTRU102a、102b、および/または102cが異なるASNおよび/または異なるコアネットワーク間でローミングすることを可能にしてもよい。MIP−HA184は、WTRU102a、102b、および/または102cに、インターネット110などのパケット交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cとIP対応デバイスとの間の通信を容易にしてもよい。AAAサーバ186は、ユーザ認証と、ユーザサービスをサポートすることとに関与してもよい。ゲートウェイ188は、他のネットワークとの相互作用を容易にしてもよい。例えば、ゲートウェイ188は、WTRU102a、102b、および/または102cに、PSTN108などの回線交換ネットワークへのアクセスを提供して、WTRU102a、102b、および/または102cと従来の固定電話通信デバイスとの間の通信を容易にしてもよい。また、ゲートウェイ188は、WTRU102a、102b、および/または102cに、他のサービスプロバイダによって所有および/または運用される有線ネットワークまたは無線ネットワークを含んでもよいネットワーク112へのアクセスを提供してもよい。
図6Eには示されていないが、RAN105は他のASNに接続されてもよく、コアネットワーク109は他のコアネットワークに接続されてもよいことを認識されるであろう。RAN105と他のASNとの間の通信リンクは、RAN105と他のASNとの間でWTRU102a、102b、および/または102cのモビリティを調整するためのプロトコルを含んでもよいR4基準点として定義されてもよい。コアネットワーク109と他のコアネットワークとの間の通信リンクは、ホームコアネットワークと訪問先コアネットワークとの間の相互作用を容易にするためのプロトコルを含んでもよいR5基準点として定義されてもよい。
特徴および要素は、特定の組み合わせにおいて上述されているが、当業者は、各特徴または要素が単独で、または他の特徴および要素との任意の組み合わせにおいて使用されてもよいことを認識するであろう。また、本明細書において説明される方法は、コンピュータまたはプロセッサによる実行のためのコンピュータ読取可能な媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ読取可能な媒体の例は、(有線接続または無線接続上で送信される)電気信号およびコンピュータ読取可能な記憶媒体を含む。コンピュータ読取可能な記憶媒体の例は、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびに、CD−ROMディスク、およびデジタル多用途ディスク(DVD)などの光媒体を含むが、これらに限定されない。ソフトウェアと関連付けられたプロセッサは、WTRU、端末、基地局、RNC、または任意のホストコンピュータにおける使用のための無線周波数送受信器を実装するために使用されてもよい。