特許 7485639 効率的なマルチビュー／レイヤ符号化を可能とする符号化コンセプト

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

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

(11)【特許番号】

(24)【登録日】2024-05-08

(45)【発行日】2024-05-16

(54)【発明の名称】効率的なマルチビュー／レイヤ符号化を可能とする符号化コンセプト

(51)【国際特許分類】

   H04N 19/597 20140101AFI20240509BHJP

   H04N 19/563 20140101ALI20240509BHJP

【ＦＩ】

H04N19/597

H04N19/563

【請求項の数】 18

【外国語出願】

(21)【出願番号】P 2021121175

(22)【出願日】2021-07-26

(62)【分割の表示】P 2018228292の分割

【原出願日】2014-04-08

(65)【公開番号】P2021182750

(43)【公開日】2021-11-25

【審査請求日】2021-08-13

(31)【優先権主張番号】61/809,605

(32)【優先日】2013-04-08

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

(73)【特許権者】

【識別番号】515089080

【氏名又は名称】ジーイー ビデオ コンプレッション エルエルシー

【住所又は居所原語表記】１ Ｒｅｓｅａｒｃｈ Ｃｉｒｃｌｅ，Ｎｉｓｋａｙｕｎａ，ＮＹ １２３０９，ＵＳＡ

(74)【代理人】

【識別番号】100079577

【弁理士】

【氏名又は名称】岡田 全啓

(72)【発明者】

【氏名】スクーピン ローベルト

(72)【発明者】

【氏名】ズューリング カルステン

(72)【発明者】

【氏名】サンチェス デ ラ フエンテ ヤーゴ

(72)【発明者】

【氏名】テヒ ゲルハルト

(72)【発明者】

【氏名】ジョージ ヴァレーリ

(72)【発明者】

【氏名】シーアル トーマス

(72)【発明者】

【氏名】マルペ デトレフ

【審査官】鉢呂 健

(56)【参考文献】

【文献】NAKAGAMI, Ohji et al.，MV-HEVC: Vertical length restriction of inter-view vector for HEVC simple 3D extension，Joint Collaborative Team on 3D Video Coding Extension Development of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 2nd Meeting: Shanghai, CN, 13-19 Oct. 2012, [JCT3V-B0037_r1]，JCT3V-B0037 (version 2)，ITU-T，2012年10月12日，＜URL:http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/2_Shanghai/wg11/JCT3V-B0037-v2.zip＞: JCT3V-B0037_r1.doc: pp.1-7

【文献】COBAN, Muhammed et al.，Support of independent sub-pictures，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 9th Meeting: Geneva, CH, 27 April - 7 May 2012, [JCTVC-I0356]，JCTVC-I0356 (version 1)，ITU-T，2012年04月17日，＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/9_Geneva/wg11/JCTVC-I0356-v1.zip＞: JCTVC-I0356.doc: pp.1-5

【文献】TECH, Gerhard et al.，3D-HEVC Test Model 3，Joint Collaborative Team on 3D Video Coding Extension Development of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 3rd Meeting: Geneva, CH, 17-23 Jan. 2013, [JCT3V-C1005_d0]，JCT3V-C1005 (version 1)，ITU-T，2013年03月15日，＜URL:http://phenix.it-sudparis.eu/jct2/doc_end_user/documents/3_Geneva/wg11/JCT3V-C1005-v1.zip＞: JCT3V-C1005_d0.docx: pp.13-19

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

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

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

【請求項1】

第１のビュー（１２）から第２のビュー（１５）へのビュー間予測を用いて、データストリームから複数のビュー（１２、１５）を復元するように構成されるマルチビューデコーダであって、前記マルチビューデコーダは、前記データストリームにおけるシグナリングに応答して、前記ビュー間予測を用いて現在予測される前記第２のビュー（１５）の現在の部分（３０２）と同じ場所に配置された前記第１のビューの部分（３０６）が空間的に配置される空間セグメントの境界（３００）を越えて拡張する部分において、前記空間セグメントからの外挿によって、補間フィルタカーネル（３１１）を前記空間セグメントの前記境界の外部の情報から独立した代替データによって充填するように構成され、前記空間セグメントは独立して復号化可能である、マルチビューデコーダ。

【請求項2】

前記データストリームに基づいて、前記第２のビュー（１５）の現在の部分（３０２）について可能な視差ベクトルのドメインから視差ベクトル（３０８）を決定し、前記現在の部分（３０２）と同じ場所に配置された前記第１のビュー（１２）の部分（３０６）から前記決定された視差ベクトル（３０８）分、変位した参照部分（３０４）において、前記第１のビュー（１２）をサンプリングするように構成される、請求項１に記載のマルチビューデコーダ。

【請求項3】

前記ビュー間予測において、前記第２のビューの現在の部分について、前記第１のビュー（１２）内の参照部分（３１４）を導き出し、前記データストリームにおけるシグナリングに依存して、前記参照部分（３１４）が、前記現在の部分（３０２）と同じ場所に配置された第１のビュー（１２）の部分（３０６）が空間的に配置される空間セグメント（３０１）内にあるかどうかをチェックし、
前記参照部分が前記空間セグメント内にある場合には、前記参照部分（３１４）の属性から導き出された前記現在の部分（３０２）のための予測器を適用し、
前記参照部分が前記空間セグメント内にない場合には、前記部分（３０６）が空間的に配置されている前記空間セグメント（３０１）内に前記参照部分（３１４）があるかどうかに依存して、前記現在の部分（３０２）のパラメータに対して前記予測器の適用を差し控える、もしくは代替予測器を適用する、または
前記部分（３０６）が空間的に配置される前記空間セグメント（８２）内に前記参照部分（３１４）があるか否かに拘りなく、前記予測器を適用する、
ように構成される、請求項１または請求項２に記載のマルチビューデコーダ。

【請求項4】

前記参照部分（３１４）を導き出すにあたり、
前記現在の部分（３０２）ための視差ベクトル（３１６）を推定し、
前記現在の部分（３０２）または前記現在の部分（３０２）に隣接する前記第１のビューの隣接部分（３２０）に対して同じ場所に配置された前記第１のビューの代表位置（３１８）を配置し、
前記代表位置（３１８）に前記視差ベクトル（３１６）を適用することによって前記参照部分（３１４）を決定する、
ように構成される、請求項３に記載のマルチビューデコーダ。

【請求項5】

前記データストリームに伝送される距離画像、または前記現在の部分について空間的または時間的に予測された視差ベクトルに基づいて、前記現在の部分のための前記視差ベクトルを推定するように構成される、請求項４に記載のマルチビューデコーダ。

【請求項6】

前記参照部分（３１４）を決定するにあたり、前記第１のビュー（１２）を符号化ブロック、予測ブロック、残差ブロックおよび／または変換ブロックに分割したものの中から、前記参照部分を前記視差ベクトル（３１６）の使用によって選択するように構成される、請求項４または請求項５に記載のマルチビューデコーダ。

【請求項7】

前記パラメータは、動きベクトル、視差ベクトル、残差信号および／または奥行き値である、請求項３ないし請求項６のいずれかに記載のマルチビューデコーダ。

【請求項8】

前記属性は、動きベクトル、視差ベクトル、残差信号および／または奥行き値である、請求項３ないし請求項７のいずれかに記載のマルチビューデコーダ。

【請求項9】

第１のビュー（１２）から第２のビュー（１５）へのビュー間予測を用いて、複数のビュー（１２、１５）をデータストリームに符号化するように構成されるマルチビューエンコーダであって、前記マルチビューエンコーダは、前記ビュー間予測を用いて現在予測される前記第２のビュー（１５）の現在の部分（３０２）と同じ場所に配置された前記第１のビューの部分（３０６）が空間的に配置される空間セグメントの境界（３００）を越えて拡張する部分において、前記空間セグメントからの外挿によって、補間フィルタカーネル（３１１）を前記空間セグメントの前記境界の外部の独立した代替データによって充填するように構成され、前記空間セグメントは独立して符号化可能である、マルチビューエンコーダ。

【請求項10】

前記第２のビュー（１５）の現在の部分（３０２）（例えば視差補正して予測された、予測ブロック）についての可能な視差ベクトルのドメインの中から視差ベクトル（３０８）を（たとえば、最適化によって）決定して前記データストリームにおいてシグナリングし、前記現在の部分（３０２）と同じ場所に配置された前記第１のビュー（１２）の部分（３０６）から前記決定された視差ベクトル分（３０８）変位された参照部分（３０４）において、前記第１のビュー（１２）をサンプリングするように構成される、請求項９に記載のマルチビューエンコーダ。

【請求項11】

前記ビュー間予測において、前記第２のビューの現在の部分について、前記第１のビュー（１２）内の参照部分（３１４）を導き出し、前記データストリームにおけるシグナリングに依存して、前記参照部分（３１４）が、前記現在の部分（３０２）と同じ場所に配置された第１のビュー（１２）の部分（３０６）が空間的に配置される空間セグメント（３０１）内にあるかどうかをチェックし、前記参照部分が前記空間セグメント内にある場合には、前記参照部分（３１４）の属性から導き出された前記現在の部分（３０２）のための予測器を適用し、前記参照部分が前記空間セグメント内にない場合には、前記部分（３０６）が空間的に配置される前記空間セグメント（３０１）内に前記参照部分（３１４）があるかどうかに依存して、前記現在の部分（３０２）のパラメータへの前記予測器の適用を差し控える、または
前記部分（３０６）が空間的に配置される前記空間セグメント（３０１）内に前記参照部分（３１４）があるか否かに拘りなく、前記予測器を適用する、
ように構成される、請求項９または請求項１０に記載のマルチビューエンコーダ。

【請求項12】

前記参照部分（３１４）を導き出すにあたり、
前記現在の部分（３０２）のための視差ベクトル（３１６）を推定し、
前記現在の部分（３０２）または前記現在の部分（３０２）に隣接する前記第１のビューの隣接部分（３２０）に対して同じ場所に配置された前記第１のビューの代表位置（３１８）を配置し、
前記代表位置（３１８）に前記視差ベクトル（３１６）を適用することによって前記参照部分（３１４）を決定する、
ように構成される、請求項１１に記載のマルチビューエンコーダ。

【請求項13】

前記データストリームに伝送される距離画像、または前記現在の部分について空間的または時間的に予測された視差ベクトルに基づいて、前記現在の部分のための前記視差ベクトルを推定するように構成される、請求項１２に記載のマルチビューエンコーダ。

【請求項14】

前記パラメータは、動きベクトル、視差ベクトル、残差信号および／または奥行き値である、請求項１１ないし請求項１３のいずれかに記載のマルチビューエンコーダ。

【請求項15】

前記属性は、動きベクトル、視差ベクトル、残差信号および／または奥行き値である、請求項１１ないし請求項１４のいずれかに記載のマルチビューエンコーダ。

【請求項16】

第１のビュー（１２）から第２のビュー（１５）へのビュー間予測を用いて、データストリームから複数のビュー（１２、１５）を復元するための方法であって、前記方法は、前記データストリームにおけるシグナリングに応答して、前記ビュー間予測を用いて現在予測される前記第２のビュー（１５）の現在の部分（３０２）と同じ場所に配置された前記第１のビューの部分（３０６）が空間的に配置される空間セグメントの境界（３００）を越えて拡張する部分において、前記空間セグメントからの外挿によって、補間フィルタカーネル（３１１）を前記空間セグメントの前記境界の外部の情報から独立した代替データによって充填し、前記空間セグメントは独立して符号化可能である、方法。

【請求項17】

第１のビュー（１２）から第２のビュー（１５）へのビュー間予測を用いて、複数のビュー（１２、１５）をデータストリームに符号化するための方法であって、前記方法は、前記ビュー間予測を用いて現在予測される前記第２のビュー（１５）の現在の部分（３０２）と同じ場所に配置された前記第１のビューの部分（３０６）が空間的に配置される空間セグメントの境界（３００）を越えて拡張する部分において、前記空間セグメントからの外挿によって、補間フィルタカーネル（３１１）を前記空間セグメントの前記境界の外部の情報から独立した代替データによって充填するステップを含み、前記空間セグメントは独立して符号化可能である、方法。

【請求項18】

コンピュータプログラムがコンピュータ上で動作するとき、請求項１６または請求項１７のいずれかに記載の方法を実行するプログラムコードを有する、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、マルチビュー画像／ビデオ符号化のような効率的なマルチビュー／レイヤ符号化を可能とする符号化コンセプトに関する。

【背景技術】

【0002】

従来技術において、スケーラブルな符号化コンセプトが知られている。ビデオ符号化において、たとえば、Ｈ．２６４は、空間分解能、ＳＮ比（ＳＮＲ）等、および／または、大事なことであるがビューの数のような異なる項目においてベース層品質のビデオの再生品質を向上させるために、ベース層の符号化されたビデオデータストリームに付加的な増強層データを付随させることを可能とする。最近完成されたＨＥＶＣ規格は、ＳＶＣ／ＭＶＣプロファイル（ＳＶＣ＝スケーラブルビデオ符号化、ＭＶＣ＝マルチビュー符号化）によっても拡張される。ＨＥＶＣは、その先行者Ｈ．２６４とは、たとえば並列の復号化／符号化に対する適合性および低遅延伝送のような多くの側面において異なる。並列の符号化／復号化に関する限り、ＨＥＶＣは、タイル並列処理コンセプトと同様にＷＰＰ（ウェーブフロント並列処理）符号化／復号化をサポートする。ＷＰＰコンセプトによれば、個々の画像は行ワイズの方法でサブストリームにセグメント化される。各サブストリーム内の符号化順序は左から右に向けられている。サブストリームは、トップのサブストリームからボトムのサブストリームまで導く、それらの間で定められた復号化順序を持つ。サブストリームのエントロピー符号化は、確率適応を用いて実行される。確率初期化は、各サブストリームに対して個別に、または、第２のＣＴＢ（符号化ツリーブロック）の終端のような、それぞれの先行するサブストリームの左端から特定の位置までの間近に先行するサブストリームのエントロピー符号化において用いられる確率の前もって適応された状態に基づいてなされる。空間予測は制限される必要はない。すなわち、空間予測は、間近に継続するサブストリームの境界を横断することができる。このように、この種のサブストリームは、現在の符号化／復号化の配置によって、並列に符号化／復号化することができ、左から右に、左下から右上まで導く偏向された方法で続くウェーブフロントを形成する。タイルコンセプトによれば、画像はタイルにセグメント化され、これらのタイルの符号化／復号化に並列処理の可能な対象を提供するために、タイルの境界を横切る空間予測は禁止される。単にタイルの境界を横切るインループフィルタリングは許容することができる。低遅延処理をサポートするために、スライスコンセプトは拡張されている。スライスは、前のサブストリーム、すなわち現在のスライスが属するサブストリームの前のサブストリームの処理の間保存されるエントロピー確率を採用することと、間近の先行するスライスの終端まで連続的にアップデートされているエントロピー確率を採用することの、いずれかのエントロピー確率の初期化に対して新たに切換え可能とすることが許容される。この手段によって、ＷＰＰおよびタイルコンセプトは、低遅延処理により適するようになる。

【0003】

しかしながら、マルチビュー／レイヤ符号化コンセプトを更に改善するコンセプトを手近に有することはより好ましい。

【発明の開示】

【0004】

したがって、本発明の目的は、マルチビュー／レイヤ符号化コンセプトを更に改善するコンセプトを提供することである。

【0005】

この目的は、出願中の独立請求項の主題によって達成される。

【0006】

本願の第１の態様は、マルチビュー符号化に関する。特に、第１の態様の根底にあるアイデアは以下の通りである。ビュー間予測は、一方では、特定のシーンがキャプチャされる複数のビュー間の冗長性の利用において役立ち、それによって符号化の効率が増大する。ビュー間予測は、他方では、複数のビューが、お互いから完全に独立して復号化／符号化可能であること、すなわちたとえばマルチコアプロセッサから利益を享受するために並列に復号化／符号化可能であることを妨げる。より正確には、ビュー間予測は、第２のビューの部分を第１のビューの対応する参照部分に従属させ、第１と第２のビューの部分間のこの相互関係は、第１と第２のビューを並列に復号化／符号化するとき、特定のビュー間の復号化／符号化のオフセット／遅延が一致することを要する。１の態様の根底にあるアイデアは、第１の／参照ビューが分割される空間セグメントの空間セグメント境界においてビュー間予測が実行される方法に関して、符号化および／または復号化が変更される場合に、符号化効率を単にマイナーな方法で低減することによって、このビュー間符号化のオフセットを実質的に低減することができることである。第１のビューから第２のビューへのビュー間予測が、第１のビューの異なる空間セグメントに対するいかなる情報も結合しないが、第１のビューの１つの空間セグメントのみから生じる情報からそれぞれ第２のビューおよびそのシンタックスエレメントを予測するように、変更を実行することができる。実施形態によれば、ビュー間予測が空間セグメント境界をさらに横断しない、すなわち１つの空間セグメントが同じ場所に配置される位置または同じ場所に配置される部分を備えるように、変更はより一層厳格に実行される。ビュー間予測における第１のビューの２つ以上空間セグメントから生じる結合情報の帰結を考慮するとき、セグメント境界におけるビュー間予測の変更から生じる利益は明白になる。その場合、レイヤ間予測のこの種の組合せを含む第２のビューのいかなる部分の符号化／復号化も、レイヤ間予測によって結合されている第１のビューの全ての空間セグメントの符号化／復号化まで延期されなければならない。第１のビューの空間セグメントの空間セグメント境界におけるビュー間予測の変更は、しかしながら、この問題を解決し、第２のビューの各部分は、第１のビューの１つの空間セグメントが復号化／符号化され次第、直ちに符号化／復号化可能である。符号化効率は、しかしながら、レイヤ間予測が依然として実質的に許容されるので、軽微にのみ低減されるだけあり、制限は単に第１のビューの空間セグメントの空間セグメント境界に適用される。実施形態によれば、エンコーダは、ちょうど概説された第１のビューの２つ以上の空間セグメントの結合を回避するため、第１のビューの空間セグメントの空間セグメント境界においてレイヤ間予測の変更に対処し、この回避／事情をデコーダにシグナルし、たとえばシグナリングに反応するビュー間復号化の遅延を減らすため、相当する保証として順にシグナリングを用いる。他の実施形態によれば、デコーダも、データストリームにおけるシグナリングによってトリガーされるレイヤ間予測の方法を変更し、その結果、これらの空間セグメント境界に関する限り、レイヤ間予測をコントロールするのに必要なサイド情報の量を低減することができるので、第１のビューの空間セグメントの空間セグメント境界におけるレイヤ間予測パラメータ設定の制限はデータストリームの形成に生かすことができる。

【0007】

本発明の第２の態様は、マルチレイヤのビデオ符号化と、１つのタイムインスタントに関係するＮＡＬユニットがレイヤに関係なくそれぞれのＮＡＬユニットが関係する１つのアクセスユニットを形成するように、または、選択される可能性にかかわりなく、各タイムインスタントとレイヤのペアのＮＡＬユニットを別々に処理し、それをインターリーブなしで順序付けることによって、タイムインスタントとレイヤの各異なるペアに対して１つのアクセスユニットが存在するように、通常複数のレイヤの画像が符号化されるＮＡＬユニットがアクセスユニットに集められる事情に関する。すなわち、１つの特定のタイムインスタントとレイヤに属するＮＡＬユニットは、タイムインスタントとレイヤの他のペアのＮＡＬユニットに進む前に送出される。インターリービングは認められない。しかしながら、エンコーダはベースレイヤに属するＮＡＬユニット間の従属レイヤに属するＮＡＬユニットの送出が防止されるので、これはエンドツーエンドの遅延の更なる低減を妨げ、この機会は、しかしながら、レイヤ間並列処理から生じる。本願の第２の態様は、伝送されたビットストリーム内でのＮＡＬユニットの厳格なシーケンシャルの非インターリーブ配列をあきらめ、この目的を達成するために、１つのタイムインスタントの全てのＮＡＬユニットを集める：１つのタイムインスタントの全てのＮＡＬユニットが１つのアクセスユニット内に集められ、アクセスユニットが依然として伝送されるビットストリーム内でインターリーブされない方法で配列されるように、アクセスユニットを定める第１の可能性を再利用する。しかしながら、１つのアクセスユニットのＮＡＬユニットのインターリービングは許容され、１つのレイヤのＮＡＬユニットは、他のレイヤのＮＡＬユニットによって分散される。１つのアクセスユニット内の１つのレイヤに属するＮＡＬユニットのランは、復号化ユニットを形成する。インターリービングは、１つのアクセスユニット内の各ＮＡＬユニットに対して、レイヤ間予測に対する必要な情報が、そのアクセスユニット内の先行するＮＡＬユニットのいずれかに含まれるという程度まで許容される。エンコーダは、ビットストリーム内でインターリービングが適用されたか否かをシグナリングすることができ、デコーダは、次に、シグナリングによって、各アクセスユニットの異なるレイヤのインターリーブされたＮＡＬユニットを再ソートするためにたとえば複数のバッファを用いる、またはインターリービングがない場合に単に１つのバッファを用いることができる。しかしながらエンドツーエンドの遅延が減少することで、符号化効率のペナルティに結果としてならない。

【0008】

本願の第３の態様は、ＮＡＬユニット当りのようなビットストリームパケット当りのレイヤインデックスのシグナル化に関する。本願の第３の態様によれば、発明者は、アプリケーションが第１に２つのタイプのうちの１つに分かれることを認識した。通常のアプリケーションは適度な数のレイヤを必要とし、したがって全体の適度なレイヤ数をカバーするように構成される各パケットにおけるレイヤＩＤフィールドに悩まされない。過剰なレイヤ数を必要とする、より複雑アプリケーションはまれに起こるだけである。したがって、本願の第３の態様によれば、マルチレイヤビデオ信号におけるレイヤ識別拡張メカニズムのシグナリングは、各パケット内のレイヤ識別シンタックスエレメントが、マルチレイヤデータストリームにおけるレイヤ識別拡張とともに、完全にまたは単に部分的にそれぞれのパケットのレイヤを決定するか、またはレイヤ識別拡張によって完全に置換される／破棄されるかをシグナリングするために用いられる。この手段によって、レイヤ識別拡張が必要であり、まれに起こるアプリケーションのみにおいてビットレートを消費するが、大部分のケースにおいてレイヤ関連付けの効率的なシグナリングが可能である。

【0009】

本願の第４の態様は、ビデオ材料がマルチレイヤビデオデータストリームに符号化される情報量の異なるレベル間のレイヤ間予測の従属性のシグナリングに関する。第４の形態によれば、第１のシンタックス構造は、従属性ディメンションの数ならびに従属性ディメンションｉ当りのランクレベルの最大Ｎ_i、全単射のマッピング、従属性空間内の利用可能ポイントの少なくともサブセットのそれぞれの１つへの各レベルのマッピング、および従属性ディメンションｉ当たりの第２のシンタックス構造を定める。後者は、レイヤ中の従属性を定める。各シンタックス構造は、それぞれの第２のシンタックス構造が属する従属性ディメンションｉのＮ_iランクレベル中の従属性を記述する。このように、従属性を定める効果は従属性ディメンションによって単に線形に増加するが、このシグナリングによって課される個々のレイヤ間の相互従属性に関する制限は比較的低い。

【0010】

当然、上記の態様の全ては、対、三つ組、またはその全てにおいて結合することができる。

【図面の簡単な説明】

【0011】

本願の好ましい実施形態は、以下の図面に関して後述される。

【図1】以下の図に関して更に概説されるマルチレイヤエンコーダのいずれかを実施する実例として役立つビデオエンコーダを示す。

【図2】図１のビデオエンコーダに適合するビデオデコーダを示す概略ブロック図を示す。

【図3】ＷＰＰ処理のためにサブストリームに再分割された画像の概略図を示す。

【図4】空間セグメントへの画像の更なる再分割を指示することによってブロックに再分割されたいずれかのレイヤの画像を図示する概略図を示す。

【図5】ブロックおよびタイルに再分割されたいずれかのレイヤの画像の概略図を示す。

【図6】ブロックおよびサブストリームに再分割された画像の概略図を示す。

【図7】実施形態にかかる、空間セグメント境界の近くのベースビューブロックの想定される視差ベクトルのドメインの制限を空間セグメント境界から更に離れて位置決めされるベースビューブロックと比較して図示するために両方とも互いに登録されたベースビュー画像の前に配置される従属ビュー画像によるベースビュー画像および従属ビュー画像の概略図を示す。

【図8】実施形態にかかる、ビュー間予測の制限および空間セグメント境界をサポートするエンコーダの概略ブロック図を示す。

【図9】図８のエンコーダにフィットするデコーダの概略ブロック図を示す。

【図10】想定される視差ベクトルのドメインの制限を決定する態様を図示するために視差ベクトルを用いたビュー間予測および／またはビュー間予測された従属ビューブロックのビュー間予測プロセスの可能な修正を図示する概略図を示す。

【図11】ビュー間予測の適用を図示するために従属ビューのパラメータを予測するビュー間予測を図示する概略図を示す。

【図12】タイルへの画像の再分割に従うコードブロックの中で定められたコードブロックと復号化順序の整数倍から成るタイルによって、コードブロックおよびタイルにそれぞれ再分割される画像の概略図を示す。

【図13a】図８～１１の実施形態をＨＥＶＣに例示的に組み込む実施例として、修正ＶＰＳシンタックスの部分を示す。

【図13b】図１３ａの対応する部分であるが、その部分がＳＰＳシンタックスに属する部分を示す。

【図13c】修正ＶＰＳシンタックスの他の例示的な部分を示す。

【図13d】ビュー間予測の変更のシグナル化を実施する修正ＶＰＳシンタックスの実施例を示す。

【図13e】空間セグメント境界におけるビュー間予測の変更をシグナリングする修正ＶＰＳシンタックスの部分に対する更なる実施例を示す。

【図13f】修正ＶＰＳシンタックスからの部分に対する更なる実施例を示す。

【図13g】ビュー間予測の変更／制限のシグナリングの更なる可能性として、修正ＶＰＳシンタックスの部分を示す。

【図14】ビュー間予測の変更／制限のシグナリングする更なる実施形態の修正ＶＰＳシンタックスの部分の実施例を示す。

【図15】実施形態にかかる、修正をビュー間予測の変更／制限に並行してトリガーすることができる、空間セグメント境界におけるベースレイヤフィルタプロセスに対する可能な修正を図示するための、他方の上部に示される従属ビュー画像およびベースビュー画像のオーバーレイの概略図を示す。

【図16】ここで３つのレイヤを例示的に備え、データストリーム内でそれぞれのタイムインスタントおよびそれぞれのレイヤに属するＮＡＬユニットを配置するオプション１および２が下半分において図示される、マルチレイヤビデオデータストリームの概略図を示す。

【図17】２つのレイヤの例示的ケースにおけるこれらの２つのオプションを図示した、データストリームの部分の概略図を示す。

【図18】オプション１の図１６および１７にかかるマルチレイヤビデオデータストリームを処理するように構成されるデコーダの概略ブロック図を示す。

【図19】図１８のデコーダにフィットするエンコーダの概略ブロック図を示す。

【図20】実施形態にかかる、ＷＰＰを用いて画像を並列に復号化／符号化するときに結果となるウェーブフロントを付加的に指示することにより、ＷＰＰ処理に対してサブストリームに再分割された画像の概略図を示す。

【図21】各々がインターリーブされない状態にある３つの復号化ユニットによる３つのビューに関するマルチレイヤビデオデータストリームを示す。

【図22】図２１にかかるマルチレイヤビデオデータストリームであって、ビューがインターリーブされる構成の概略図を示す。

【図23】アクセスユニット内でのレイヤのインターリービングにおいておそらく守られる拘束を図示するために、ＮＡＬユニットの内部シーケンスにおけるマルチレイヤビデオデータストリームの部分の概略図を示す。

【図24】復号化ユニットのインターリービングをシグナリングする可能性を図示する修正ＶＰＳシンタックスの部分に対する実施例を示す。

【図25】例示的に固定長のレイヤ識別シンタックスエレメントを備える、ＮＡＬユニットヘッダの部分を示す。

【図26】レイヤ識別拡張機構シグナリングを実現する可能性を指示するＶＰＳシンタックスの部分を示す。

【図27】レイヤ識別拡張機構シグナリングを実現する他の可能性を図示するＶＰＳシンタックスの部分を示す。

【図28】レイヤ識別拡張機構シグナリングを実現する更なる実施例を図示するためのＶＰＳシンタックスの部分を示す。

【図29】データストリームにおけるレイヤ識別拡張を実施する可能性を図示するためのスライスセグメントヘッダの部分を示す。

【図30】レイヤ識別拡張を実施する更なる可能性を図示するためのスライスセグメントヘッダの部分を示す。

【図31】レイヤ識別拡張の実現を図示するＶＰＳシンタックスの部分を示す。

【図32】レイヤ識別拡張を実現する他の可能性を図示するデータストリームシンタックスの部分を示す。

【図33】実施形態にかかる、レイヤ識別シンタックスエレメントをレイヤ識別拡張と結合する可能性を図示するためのカメラセットアップを概略的に示したものである。

【図34a】データストリーム内でレイヤ拡張機構に対するフレームワークをシグナリングするＶＰＳ拡張シンタックスの部分を示す。

【図34b】データストリーム内でレイヤ拡張機構に対するフレームワークをシグナリングするＶＰＳ拡張シンタックスの部分を示す。

【図35】データストリームのレイヤに関するシグナリング、従属性空間内のこれらのレイヤの配置、レイヤ間の従属性のそれぞれが提供されるマルチレイヤビデオデータストリームを処理するように構成されたデコーダの概略図を示す。

【図36】従属性空間、ここで、特定の予測構造を用いた、空間における各ディメンションによる、２次元空間におけるレイヤの直接従属性構造、を図示する概略図を示す。

【図37】異なるレイヤ間の従属性を特定する直接従属性フラグの配列の概略図を示す。

【図38】異なる位置および異なるディメンションの間の従属性を特定する直接位置従属性フラグの２つの配列の概略図を示す。

【図39】従属性空間を定める第１のシンタックス構造の部分をシグナリングする方法を図示するデータストリームシンタックスの部分を示す。

【図40】データストリームのレイヤと従属性空間における利用可能ポイントの間のマッピングに関する第１のシンタックス構造の部分をシグナリングする可能性を図示するデータストリームの部分を示す。

【図41】従属性ディメンションワイズの従属性を記述する第２のシンタックス構造を定める可能性を図示するデータストリームの部分を示す。

【図42】第２のシンタックス構造を定める他の可能性を示す。

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

【0012】

第一に、概要として、引き続いて提示されるコンセプトのいずれかにフィットするエンコーダ／デコーダ構造に対する実施例が提示される。

【0013】

図１は、実施形態にかかるエンコーダの全般的な構造を示す。エンコーダ１０は、マルチスレッドの方法または単にシングルスレッドにおいて動作できるように実施することができる。すなわち、エンコーダ１０は、たとえば多重のＣＰＵコアを用いて実施することができる。言い換えれば、エンコーダ１０は、並列処理をサポートすることができるが、必ずしもその必要はない。生成されるビットストリームは、シングルスレッドのエンコーダ／デコーダによって生成／復号化することもできる。本願の符号化コンセプトは、並列処理を効率的に適用し、しかしながら圧縮効率を妥協することのない並列処理エンコーダを可能とする。並列処理能力に関して、図２に関して後述されるデコーダに対して同様の記載が有効である。

【0014】

エンコーダ１０はビデオエンコーダであるが、通常エンコーダ１０は画像エンコーダとすることもできる。ビデオ１４の画像１２が入力１６においてエンコーダ１０の入力として示される。画像１２は、特定のシーン、すなわち画像コンテンツを示す。しかしながら、エンコーダ１０は、その入力１６において、異なるレイヤに属する双方の画像１２および１５によって、同じタイムインスタントに関係している他の画像１５も受信する。単に説明の便宜のため、画像１２はレイヤ０に属するとして示されるのに対して、画像１５はレイヤ１に属するとして示される。図１は、レイヤ１がレイヤ０に対してより高い空間分解能を含むことができる、すなわち同じシーンをより高い数の画像サンプルで示すことができるが、これは単に便宜のためであり、レイヤ１の画像１５は、代替として同じ空間分解能を持つが、たとえばレイヤ０と比較してビューの方向において異なる、すなわち画像１２および１５は異なる視点からキャプチャされたものとすることもできる。この文書において用いられるベースおよび増強レイヤの用語は、レイヤの階層構造において参照レイヤおよび従属するレイヤのいかなるセットにも言及することができることが注目される。

【0015】

エンコーダ１０は、ハイブリッドエンコーダであり、すなわち、画像１２および１５は予測器１８によって予測され、残差決定器２２によって取得される予測残差２０は、ＤＣＴのようなスペクトル分解のような変換、および変換／量子化モジュール２４における量子化の対象となる。このように得られた、変換され、量子化された予測残余２６は、エントロピー符号器２８において、たとえばコンテキスト適応を用いた算術符号化または可変長符号化のようなエントロピー符号化の対象となる。残差の再構成可能なバージョンは、デコーダに対して利用可能となる、すなわち、逆量子化および再変換された残差信号３０は、再変換／逆量子化モジュール３１によって復元され、結合器３３によって、予測器１８の予測信号３２と再結合され、それにより結果としてそれぞれ画像１２および１５の復元３４になる。しかしながら、エンコーダ１０は、ブロックベースで動作する。したがって、復元信号３４は、ブロック境界において不連続性の被害を受け、したがって、画像１２および１５に対してそれぞれ参照画像３８を産生するために、復元信号３４にフィルタ３６が適用され、それに基づいて予測器１８は引き続いて異なるレイヤの符号化された画像を予測する。図１において破線で示されるように、予測器１８は、しかしながら、空間予測モジュールのような他の予測モジュールのように、フィルタ３６または中間バージョンなしに復元信号３４を直接利用することができる。

【0016】

予測器１８は、画像１２の特定のブロックを予測するために、異なる予測モードの中で選択することができる。画像１２のそのようなブロック３９は、図１において例示的に示される。画像１２が分割される画像１２のいかなるブロックに対しても代表されるブロック３９が、画像１２’のような同じレイヤの前に符号化された画像に基づいて予測される時間的予測モードとすることができる。ブロック３９が、同じ画像１２の前に符号化された部分、隣接ブロック３９に基づいて予測される空間予測モードが存在することもできる。画像１５のブロック４１は、画像１５が分割される他ブロックのいずれに対しても代表されるように、図１においても例示的に示される。ブロック４１に対して、予測器１８は、丁度述べられた予測モード、すなわち時間的および空間的予測モードをサポートすることができる。加えて、予測器１８は、ブロック４１が低いレイヤの画像１２の対応する部分に基づいて予測されるレイヤ間予測モードに対して提供することができる。「対応する部分」における「対応する」は、空間的な対応、すなわち、画像１２内の部分が画像１５において予測されるブロック４１と同じシーンの部分を示すことを意味する。

【0017】

予測器１８の予測は、当然、画像サンプルに制限されないとすることができる。予測は、また、符号化パラメータ、すなわち予測モード、時間的予測の動きベクトル、マルチビュー予測の視差ベクトル、その他に適用することができる。単に、残差は次にビットストリーム４０において符号化することができる。すなわち、空間および／またはレイヤ間予測を用いて、符号化パラメータを予測的に符号化／復号化することができる。さらにここでは、視差補償を用いることができる。

【0018】

特定のシンタックスが、量子化された残差データ２６、たとえば予測器１８によって決定される画像１２および１５の個々のブロック３９および４１に対する予測モードおよび予測パラメータを含む符号化パラメータと同様に、変換係数レベルおよび他の残差データを編集するために用いられ、このシンタックスのシンタックスエレメントはエントロピー符号器２８によってエントロピー符号化の対象となる。エントロピー符号器２８による出力としてこのように取得されたデータストリーム４０は、エンコーダ１０によって出力されるビットストリーム４０を形成する。

【0019】

図２は、すなわち、図１のエンコーダにフィットするデコーダを示し、ビットストリーム４０を復号化することができる。図２のデコーダは、通常、参照符号５０によって指示され、エントロピー復号器、再変換／逆量子化モジュール５４、結合器５６、フィルタ５８および予測器６０を備える。エントロピー復号器４２は、ビットストリームを受信し、残差データ６２および符号化パラメータ６４を復元するため、エントロピー復号化を実行する。再変換／逆量子化モジュール５４は、残差データ６２を逆量子化および再変換し、このように取得された残差信号を結合器５６に転送する。結合器５６も、予測器６０から予測信号６６を受信し、次に、符号化パラメータ６４を用いて、結合器５６によって予測信号６６と残差信号６５を結合することによって決定される復元信号６８に基づいて予測信号を形成する。予測は、予測器１８によって最終的に選択された予測をミラー化する、すなわち、同じ予測モードが利用可能であり、これらのモードが画像１２および１５の個々のブロックに対して選択され、予測パラメータに従ってステアリングされる。図１に関して既に上述されたように、予測器６０は、あるいはまたは加えて、復元信号６８のフィルタリングされたバージョンまたはそのいくつかの中間のバージョンを用いることができる。最終的に復元される異なるレイヤの画像およびデコーダ５０の出力７０の出力の画像は、結合信号６８のフィルタリングされないバージョンまたはそのいくつかのフィルタリングされたバージョンについて同様に決定することができる。

【0020】

タイルコンセプトによれば、画像１２および１５はそれぞれタイル８０および８２に再分割され、少なくともこれらのタイル８０および８２内のブロック３９および４１の予測は、それぞれ、空間予測の根拠として単に同じ画像１２、１５の同じタイルに関するデータをそれぞれ用いるように制限される。これは、ブロック３９の空間予測は、同じタイルの前に符号化された部分を用いるように制限されることを意味するが、時間的予測モードは、画像１２’のような前に符号化された画像の情報に依存するように制限されない。同様に、ブロック４１の空間予測モードは、同じタイルのみの前に符号化されたデータを用いるように制限されるが、時間的およびレイヤ間予測モードは制限されない。画像１５および１２の６つのタイルへの再分割は、それぞれ、単に説明の便宜のため選択されたものである。タイルへの再分割は、それぞれ、画像１２’、１２および１５、１５’に対して、ビットストリーム４０内で個々に選択し、シグナリングすることができる。画像１２および１５当りのタイルの数は、それぞれ、１、２、３、４、６などとすることができ、タイル分割はタイルの行および列への規則的な分割のみに制限することができる。完全を期すために、タイルを別々に符号化する方法はイントラ予測または空間予測に制限することができないが、タイル境界を横切る符号化パラメータのいかなる予測およびエントロピー符号化におけるコンテキスト選択も含むことができることが注目される。すなわち、後者は同じタイルのデータのみに従属するように制限することもできる。このように、デコーダは、丁度言及された並列の、すなわちタイルを単位とした、動作を実行することができる。

【0021】

図１および２のエンコーダおよびデコーダは、あるいはまたは加えて、ＷＰＰコンセプトを用いることができる。図３を参照されたい。ＷＰＰサブストリーム１００は、画像１２、１５のＷＰＰサブストリームへの空間的分割を表す。タイルおよびスライスとは対照的に、ＷＰＰサブストリームは、ＷＰＰサブストリーム１００を横切る予測およびコンテキスト選択への制限を課さない。ＷＰＰサブストリーム１００は、ＬＣＵ（最大符号化ユニット）１０１、すなわち予測符号化モードがビットストリームにおいて個々に伝送することのできる最も大きな可能なブロック、の行を横切るような行ワイズに拡張し、並列処理を可能とするために単に１つの妥協だけがエントロピー符号化に関してなされる。特に、順序１０２は、ＷＰＰサブストリーム１００の中で定められ、トップからボトムまで例示的に導き、各ＷＰＰサブストリーム１００に対して、順序１０２において最初のＷＰＰサブストリームを除いて、シンボルアルファベットに対する確率推定、すなわちエントロピー確率は、完全にはリセットされないが、線１０４で指示されるように、ＬＣＵ順序、または各サブストリームに対して、矢印１０６によって指示される左手サイドのような、それぞれ画像１２および１５の同じサイドにおいて開始し、ＬＣＵの行方向において他のサイドに導くサブストリームの復号化順序によって、その第２のＬＣＵに至るまでに直前のＷＰＰストリームをエントロピー符号化／復号化した後に結果として生ずる確率から採用されるまたはそれに等しくなるようにセットされる。したがって、それぞれ、同じ画像１２および１５のＷＰＰサブストリームのシーケンス間のいくつかの符号化遅延を守ることによって、これらのＷＰＰサブストリーム１００は、それぞれの画像１２、１５が並列に、すなわち同時に、符号化／復号化される部分が、左から右に傾動する方法で画像を横切って移動する一種のウェーブフロント１０８を形成するように、並列に復号化／符号化可能である。

【0022】

順序１０２および１０４は、またＬＣＵの中でトップからボトムまで行ごとに左上ＬＣＵ１０１から右下ＬＣＵまで導くラスタスキャンを定めることが注目される。ＷＰＰサブストリームは、１つのＬＣＵ行とそれぞれ対応することができる。タイルに戻って簡単に参照すると、後者はＬＣＵ境界に整列されるように制限することもできる。サブストリームは、サブストリームの内側における２つのスライス間の境界に関する限り、ＬＣＵ境界に拘束されることなく、１つ以上のスライスに断片化することができる。エントロピー確率は、しかしながら、サブストリームの１つのスライスから次のスライスまで遷移するケースにおいて採用される。タイルのケースでは、全てのタイルは、１つのスライスにまとめることができる、または、１つのタイルは、タイルの内側における２つのスライス間の境界に関する限り、再びＬＣＵ境界に拘束されないことによって、１つ以上のスライスに断片化することができる。タイルのケースでは、ＬＣＵの中の順序は、タイル順序において次のタイルに進む前に最初に、ラスタスキャン順序におけるタイル順序においてタイルを横断するために変更される。

【0023】

これまで記述されたように、画像１２はタイルまたはＷＰＰサブストリームに分割することができ、同様に、画像１５もまたタイルまたはＷＰＰサブストリームに分割することができる。理論的には、ＷＰＰサブストリームの分割／コンセプトは画像１２および１５の１つに対して選択することができるのに対して、タイルの分割／コンセプトはその２つの他方に対して選択される。あるいは、コンセプトタイプ、すなわちタイルまたはＷＰＰサブストリーム、がレイヤの中で同じでなければならないことによって、ビットストリーム上に制限を課すことができる。空間セグメントに対する他の実施例はスライスを含む。スライスは、伝送目的に対して、ビットストリーム４０をセグメント化するために用いられる。スライスは、伝送に対して最小のエンティティであるＮＡＬユニットにパックされる。各スライスは、独立に符号化／復号化可能である。すなわち、ちょうどコンテキスト選択等がそうであるように、スライス境界を横切るいかなる予測も禁止される。これらは、全体として、空間セグメントに対する３つの実施例：スライス、タイルおよびＷＰＰサブストリームである。加えて、全３つのパラレル化コンセプト、タイル、ＷＰＰサブストリームおよびスライスは組み合わせて用いることができ、画像１２または画像１５はタイルに分割することができ、各タイルは多重のＷＰＰサブストリームに分割される。
また、スライスは、タイルまたはＷＰＰ境界において、ビットストリームを多重のＮＡＬユニットに分割するために用いることができる。画像１２、１５がタイルまたはＷＰＰサブストリームを用いておよび加えてスライスを用いて分割され、スライス分割が他のＷＰＰ／タイル分割から変位する場合、空間セグメントは、画像１２、１５の最小の、独立して復号化可能なセクションとして定められる。あるいは、画像（１２または１５）内でコンセプトの組み合せを用いることができ、および／または、境界が異なって用いられたコンセプト間で整列しなければならない場合、ビットストリームに制限を課すことができる。

【0024】

タイルおよび／またはＷＰＰコンセプトのような並列処理コンセプトを可能にするため、エンコーダおよびデコーダによってサポートされるさまざまな予測モード、並びに予測モードに課される制限、並びにエントロピー符号化／復号化に対するコンテキスト導出が、上述されてきた。エンコーダおよびデコーダがブロックベースで動作することができることも言及されてきた。たとえば、上述された予測モードは、ブロックベース、すなわち画像自身より精細なグラニュラリティで選択することができる。本願の態様を記述することに進む前に、実施形態によるスライス、タイル、ＷＰＰサブストリームおよびちょうど言及されたブロックの関係が説明される。

【0025】

図４は、画像１２のようなレイヤ０の画像または画像１５のようなレイヤ１の画像とすることができる画像である。画像は、ブロック９０の配列に規則正しく再分割される。
時には、これらのブロック９０は、最大符号化ブロック（ＬＣＢ）、最大符号化ユニット（ＬＣＵ）、符号化ツリーブロック（ＣＴＢ）等と呼ばれる。ブロック９０への画像の再分割は、上述された予測および残差符号化が実行される一種のベースまたは最も粗いグラニュラリティを形成することができ、この最も粗いグラニュラリティ、すなわちブロック９０のサイズは、シグナリングされ、エンコーダによってレイヤ０およびレイヤ１に対して個々にセットすることができる。たとえば、クワッドツリー再分割のようなマルチ木を用いることができ、各ブロック９０を、それぞれ予測ブロック、残差ブロックおよび／または符号化ブロックに再分割するために、データストリーム内でシグナリングすることができる。特に、符号化ブロックはブロック９０のリカーシブなマルチツリー再分割のリーフブロックとすることができ、いくつかの予測関連決定を予測モードのような符号化ブロックのグラニュラリティでシグナリングすることができ、そのグラニュラリティで時間的インター予測のケースにおける動きベクトルのような予測パラメータおよびたとえばインター予測のケースにおける視差ベクトルが符号化される予測ブロックおよびそのグラニュラリティで予測残差が符号化される残差ブロックをコードブロックの分離したリカーシブなマルチツリー再分割のリーフブロックとすることができる。

【0026】

ラスタスキャン符号化／復号化順序９２は、ブロック９０の中で定めることができる。符号化／復号化順序９２は、空間予測の目的に対して隣接する部分の利用可能性を制限する：単に、符号化／復号化順序９２に従って、現在予測されるシンタックスエレメントが関係する、ブロック９０またはそのいくつかの小さいブロックのような現在の部分に先立つ画像の部分が、現在の画像内で利用可能である。各レイヤ内で、符号化／復号化順序９２は、必ずしも画像の時間的再生順序に追従しない画像符号化／復号化順序において、次にそれぞれのレイヤの次の画像のブロックの横断を続けるために、画像の全てのブロック９０を横断する。個々のブロック９０内に、符号化／復号化順序９２は、符号化ブロックのようなより少ないブロックの中のスキャンにリファインされる。

【0027】

ちょうど概説されたブロック９０とより少ないブロックとの関係において、各画像は、ちょうど言及された符号化／復号化順序９２に沿って、１つ以上のスライスに更に再分割される。したがって、例示的に図４に示されたスライス９４ａおよび９４ｂは、それぞれの画像をギャップなしにカバーする。１つの画像の連続的なスライス９４ａおよび９４ｂの間の境界またはインターフェイス９６は、隣接するブロック９０の境界と整列するまたは整列しないことができる。より正確には、そして図４の右手側で図示される、１つの画像内の連続的なスライス９４ａおよび９４ｂは、符号化ブロック、すなわちブロック９０の１つの再分割のリーフブロックのようなより小さいブロックの境界において互いに接することができる。

【0028】

画像のスライス９４ａおよび９４ｂは、画像が符号化されるデータストリームの部分をパケット、すなわちＮＡＬユニットに、パケット化することができる最小単位を形成することができる。スライスの更なる可能なプロパティ、すなわち、たとえばスライス境界を横切る予測およびエントロピーコンテキストの決定、に関するスライス上への制限が上述されている。この種の制限のあるスライスは、「ノーマル」スライスと呼ぶことができる。以下でより詳細に概説されるように、ノーマルスライスの他に「従属スライス」も同様に存在することができる。

【0029】

タイル分割コンセプトが画像に対して用いられる場合、ブロック９０の配列の中で定められた符号化／復号化順序９２は変更することができる。これは、画像が４つのタイル８２ａ～８２ｄに分割されたことが例示的に示した図５に示される。図５に図示されるように、タイルは、ブロック９０を単位とする画像の正規の再分割として、それ自身定められる。すなわち、各タイル８２ａ～８２ｄは、ｎ×ｍのブロック９０の配列からなり、ｎはタイルの各行に対して個々にセットされ、ｍはタイルの各列に対して個々にセットされる。符号化／復号化順序９２に続いて、最初のタイルにおけるブロック９０は、次のタイル８２ｂその他へ進む前に最初にラスタスキャン順序でスキャンされ、タイル８２ａ～８２ｄは、それ自身ラスタスキャン順序でスキャンされる。

【0030】

ＷＰＰストリーム分割コンセプトに従って、画像は、符号化／復号化順序９２に沿って、ブロック９０の１つ以上の行を単位として、ＷＰＰサブストリーム９８ａ～９８ｄに再分割される。各ＷＰＰサブストリームは、たとえば、図６に図示されるように、ブロック９０の１つの完全な行をカバーすることができる。

【0031】

タイルコンセプトおよびＷＰＰサブストリームコンセプトは、しかしながら、混合することもできる。その場合、各ＷＰＰサブストリームは、たとえば各タイル内のブロック９０の１つの行をカバーする。

【0032】

画像のスライス分割さえ、タイル分割および／またはＷＰＰサブストリーム分割とともに用いることができる。タイルに関して、画像が再分割される１つ以上スライスの各々は、符号化／復号化順序９２に沿って、１つの完全なタイルまたは１つ以上の完全なタイル、または単に１つのタイルのサブ部分のいずれかから正確に構成することができる。
スライスは、ＷＰＰサブストリーム９８ａ～９８ｄを形成するために用いることもできる。このために、パケット化に対して最小ユニットを形成するスライスは、一方ではノーマルスライスを、他方では従属スライスを備えることができる：ノーマルスライスは、予測およびエントロピーコンテキスト導出に上述された制限を課すが、従属スライスはこの種の制限を課さない。符号化／復号化順序９２が実質的に行ワイズから離れてポイントする画像の境界で開始する従属スライスは、ブロック９０の直前の行におけるエントロピー復号化ブロック９０から結果として生ずるエントロピーコンテキストを採用し、他のどこかで開始する従属スライスは、直前のスライスのエントロピー符号化／復号化からその終了までに結果として生ずるようなエントロピー符号化コンテキストを採用することができる。この手段によって、各ＷＰＰサブストリーム９８ａ～９８ｄは、１つ以上の従属スライスから構成することができる。

【0033】

すなわち、ブロック９０の中で定められた符号化／復号化順序９２は、それぞれの画像の第１側、ここでは例示的に左側、から反対側、例示的に右側、に線状に導き、次にブロック９０の下方／ボトムの方向における次の行にステップする。現在の画像の利用可能な、すなわちすでに符号化／復号化された部分は、したがって本質的に、現在のブロック９０のような、現在の符号化／復号化された部分の左および上にある。タイル境界を横切る予測およびエントロピーコンテキスト導出の破壊ため、１つの画像のタイルは、並列に処理することができる。１つの画像のタイルの符号化／復号化は、同時に始めることさえできる。制限は、タイル境界を横断するためにそれが許容されるケースにおいて、上述されたインループフィルタリングから生じる。ＷＰＰサブストリームの符号化／復号化を順番に始めることは、トップからボトムまで千鳥状の方法で実行される。連続的なＷＰＰサブストリーム間のイントラ画像遅延は、ブロック９０において測定され、２つのブロック９０である。

【0034】

しかしながら、画像１２および１５の符号化／復号化を並列化すること、すなわち異なるレイヤのタイムインスタントさえ有利である。明らかに、従属レイヤの画像１５の符号化／復号化は、既に利用可能であるベースレイヤの「空間的に対応する」部分があることを保証するため、ベースレイヤの符号化／復号化と比較して遅延されなければならない。これらの配慮は、画像１２および１５内で、個々に符号化／復号化のいかなる並列化も用いないケースでさえ有効である。全部の画像１２および１５をカバーするためにそれぞれ１つのスライスを用いるケースにおいてさえ、タイルおよびＷＰＰサブストリームの処理を用いないことによって、画像１２および１５の符号化／復号化を並列化することができる。次に記述されるシグナリング、すなわち態様６、は、レイヤの画像のいずれかに対してタイルまたはＷＰＰの処理が用いられるこの種のケースにおいてさえ、またはそれに拘らず、レイヤ間のこの種の復号化／符号化遅延を表現する可能性がある。

【0035】

本願の上記提示されたコンセプトを議論する前に、再び図１および２を参照して、図１および２におけるエンコーダおよびデコーダのブロック構造は単に説明の便宜のためであり、構造は異なることもできる点に留意すべきある。

【0036】

連続的なレイヤの符号化の間の最小符号化遅延に関係する上記説明に関して、デコーダは、短期のシンタックスエレメントに基づいて最小復号化遅延を決定することができる点に留意すべきである。しかしなから、予め定められた期間に対して、前もってこのレイヤ間時間的遅延をシグナリングするために長期のシンタックスエレメントを用いるケースにおいて、デコーダは、提供される保証を用いて将来においてプランすることができ、ビットストリーム４０の並列復号化内でワークロードアロケーションをより容易に実行することができる。

【0037】

第１の態様は、より低いオーバーオールの符号化／復号化遅延または並列化機能の利益となるために、ビューの中のレイヤ間予測、特に、たとえば視差補正されたビュー間予測を制限することに関する。詳細は、以下の図から直ちに利用可能である。簡単な説明としては、図７を参照されたい。

【0038】

エンコーダは、たとえば、従属ビューの現在ブロック３０２がベースレイヤセグメントの境界３００においてレイヤ間-予測されるように、視差ベクトルの利用可能なドメイン３０１を制限することができる。３０３は制限を指示する。比較のため、図７は、従属ビューの他のブロック３０２’を示し、その視差ベクトルの利用可能なドメインは制限されない。エンコーダは、データストリームにおいて、デコーダが低遅延検知におけるその利益をとることができるようにするため、この挙動、すなわち規制３０３をシグナリングすることができる。すなわち、デコーダは、レイヤ間予測がエンコーダに関する限り、しかしながら、「利用可能でないセグメント」の部分が必要でない、すなわちデコーダがレイヤ間遅延をより低く保つことができることを保証して、ちょうどノーマルとして動作することができる。あるいは、加えて、たとえば、境界３００におけるレイヤ間予測パラメータの利用可能状態のより低いマニホルドを利用するために、境界３００におけるレイヤ間予測に関する限り、エンコーダとデコーダの両方ともそれらの動作モードを変更する。

【0039】

図８は、ビュー間予測を用いて、複数のビュー１２および１５をデータストリーム４０に符号化するように構成されるマルチビューエンコーダ６００を示す。図８のケースでは、ビューの数は、矢印６０２を用いて図示されるように、第１のビュー１２から第２のビュー１５に導くビュー間予測によって、例示的に２に選択される。２つ以上のビューに対する拡張は、容易に想像できる。同じことは、以下に記述される実施形態に適用される。マルチビューエンコーダ６００は、第１のビューが分割される空間セグメント３０１の空間セグメント境界３００においてビュー間予測を変更するように構成される。

【0040】

エンコーダ６００に関する可能な実施詳細に関する限り、たとえば、図１に関して上記提案された記載が参照される。すなわち、エンコーダ６００は、画像またはビデオのエンコーダとすることができ、ブロックワイズの方法で動作することができる。特に、エンコーダ６００は、第１のビュー１２および第２のビュー１５を予測符号化にかけ、予測パラメータをデータストリーム４０に挿入し、スペクトル分解を用いて予測残差をデータストリーム４０に変換符号化し、少なくとも第２のビュー１５に関する限り、少なくとも空間およびビュー間予測６０２を含む異なる予測タイプの間でスイッチするように構成された、ハイブリッド符号化タイプとすることができる、前に述べたように、エンコーダ６００が異なる予測タイプ／モードの間でスイッチするユニットは、符号化ブロックと呼ぶことができ、これらの符号化ブロックが、たとえば、第２のビュー１５の画像の階層的マルチツリー再分割のリーフブロックまたは第２のビュー１５の画像が定期的に予備分割することができるツリールートブロックを表すことができるように、そのサイズは変化することができる。ビュー間予測は、ブロック３０２内のサンプルが部分６０８の復元されたバージョンをブロック３０２にコピーすることによって予測される部分６０８をアクセスするために、第２のビュー１５の画像のビュー間予測されたブロック３０２に対して空間的に同じ場所に配置された第１のビュー１２の画像の空間的に同じ場所に配置された部分６０６に適用される変位を指示する視差ベクトル６０４を用いて、それぞれの符号化ブロック内でサンプルを予測することに結果としてなることができる。ビュー間予測６０２は、しかしながら、第２のビュー１５のサンプル値のそのタイプに制限されない。むしろ、加えてまたはあるいは、エンコーダ６００によってサポートされるようなビュー間予測は、それ自身予測パラメータを予測的に符号化するために用いることができる：エンコーダ６００が、ちょうど概説されたビュー間予測モードに加えて、空間および／または時間的予測をサポートすることを想像されたい。ちょうど時間的予測がするように、特定の符号化ブロックを空間的に予測することは、その符号化ブロックがデータストリーム４０に挿入される予測パラメータにおいて終わる。第２のビュー１５の画像の符号化ブロックのこれらの予測パラメータの全てをデータストリーム４０に独立に符号化する代わりに、しかしながら、第１のビューの画像をデータストリーム４０に符号化することに用いられた予測パラメータから独立して、エンコーダ６００は、第１のビュー１２がエンコーダ６００によって符号化されたデータストリーム４０の部分から入手可能な予測パラメータまたは他の情報に基づいて第２のビュー１５の符号化ブロックを予測符号化することに用いられる予測パラメータを予測することによって、予測符号化を用いることができる。すなわち、動きベクトル等のような第２のビュー１５の特定の符号化ブロック３０２の予測パラメータは、たとえば対応する第１のビュー１２の時間的に予測された符号化ブロックの動きベクトルに基づいて、予測することができる。「対応」は、ビュー１２と１５との視差を考慮に入れることができる。たとえば、第１および第２のビュー１２および１５は、各々それに関連する距離画像を有することができ、エンコーダ６００は、ビュー１２および１５のテキスチャーサンプルを、距離画像の関連する奥行き値とともに、データストリーム４０に符号化するように構成することができ、エンコーダ６００は、第１のビュー１２内で、そのシーンコンテンツが第２のビュー１５の現在の符号化ブロック３０２のシーンコンテンツによりよくフィットする「対応する符号化ブロック」を決定するために、符号化ブロック３０２の奥行き推定を用いることができる。当然、この種の奥行き推定は、符号化されたいかなる距離画像にもかかわりなく、ビュー１５の近くでビュー間予測された符号化ブロックの使用された視差ベクトルに基づいて、エンコーダ６００によって決定することもできる。

【0041】

既に述べたように、図８のエンコーダ６００は、空間セグメント境界３００でビュー間予測を変更するように構成される。すなわち、エンコーダ６００は、これらの空間セグメント境界３００でビュー間予測の方法を変更する。その理由および目的は、更に以下で概説される。特に、エンコーダ６００は、ビュー間予測された符号化ブロック３００のテキスチャーサンプルコンテンツまたはこの種の符号化ブロックの特定の予測パラメータのような、予測される第２のビュー１５の各エンティティが、ビュー間予測６０２の方法によって、単に第１のビュー１２の１つの空間セグメント３０１に正確に従属するというような方法で、ビュー間予測の方法を変更する。その利益は、サンプル値または予測パラメータがビュー間予測された特定の符号化ブロックのビュー間予測の変更の結果に注目することで容易に理解することができる。ビュー間予測６０２の変更または制限なしで、この符号化ブロックを符号化することは、ビュー間予測６０２に参加している第１のビュー１２の２つ以上の空間セグメント３０１の符号化を完了するまで延期されなければならない。したがって、エンコーダ６００は、いずれにせよこのビュー間符号化遅延／オフセットを守らなければならず、エンコーダ６００は、ビュー１２および１５を時間オーバーラップ方法で符号化することによって、符号化遅延を更に低減することはできない。ビュー間予測６０２が、ちょうど概説された方法で、空間セグメント境界３０１において変更／修正されるとき、そのケースでは、いくつかのエンティティがビュー間予測される非常に問題の符号化ブロック３０２は、第１のビュー１２の１つ（単に１つだけ）の空間セグメント３０１が完全に符号化されるとすぐに符号化の対象とすることができるので、ものは異なる。それによって、想定される符号化遅延は低減される。

【0042】

したがって、図９は、図８のマルチビューエンコーダにフィットするマルチビューデコーダ６２０を示す。図９のマルチビューデコーダは、第１のビュー１２から第２のビュー１５に対するビュー間予測６０２を用いて、データストリーム４０から複数のビュー１２および１５を復元するように構成される。上述されたように、デコーダ６２０は、そのいくつかはビュー間予測された符号化ブロックである第２のビュー１５のそれぞれの符号化ブロックに対して指示される予測モードのような、データストリーム含まれる予測パラメータを、データストリーム４０から読み込み、適用することによって、図８のマルチビューエンコーダ６００によってなされると予想されるのと同じ方法でビュー間予測６０２をやり直すことができる。すでに上述されたように、ビュー間予測６０２は、あるいはまたは加えて、予測パラメータ自身の予測に関係することができ、データストリーム４０は、この種のビュー間予測された予測パラメータに対して、予測残差または予測器のリストにポイントするものであって、そのうちの１つは６０２に従ってビュー間予測されるインデックスを備えることができる。

【0043】

図８に関して既に記述されたように、エンコーダは、２つのセグメント３０１からの情報を組み合わせるビュー間予測６０２を回避するために、境界３００におけるビュー間予測の方法を変更することができる。エンコーダ６００は、デコーダ６２０に対して透明な方法で、これを達成することができる。すなわち、エンコーダ６００は、データストリーム４０内で伝達されるセットされた符号化パラメータを適用するデコーダ６２０によって、ビュー間予測６０２における２つの区別可能なセグメント３０１の情報の組み合わせが本質的に回避されるように、可能な符号化パラメータセッティングからのその選択に関して、単純に自主制限を課すことができる。

【0044】

すなわち、デコーダ６２０がデータストリーム４０の復号化に対して、ビュー１２および１５を並列に復号化することによって並列処理を適用することに興味がない、または使用可能でない限り、デコーダ６２０は、ビュー間予測における前述の変更をシグナリングする、データストリーム４０に挿入されるシグナル化を単純に無視することができる。より正確には、本願の一実施形態に従って、あるいは、図８のエンコーダは、データストリーム４０内でセグメント境界３００でのビュー間予測における変更、すなわち境界において変化があるかまたは変化がないかをデータストリーム内でシグナリングする。適用されるようにシグナリングされる場合、デコーダ６２０は、第２のビューのそれぞれの部分３０２に対して同じ場所に配置された第１のビュー１２の同じ場所に配置された部分３０６が配置される空間セグメント以外の空間セグメント上に、第２のビュー１５のいかなる部分３０２のいかなる従属性も含まないように、ビュー間予測６０２が空間セグメント３０１の空間セグメント境界３００で制限されることの保証として、境界３００でのビュー間予測６０２における変更をとることができる。すなわち、境界３００でのビュー間予測６０２における変更が適用されるようにシグナリングされる場合、デコーダ６２０はこれを保証としてとる：ビュー間予測６０２がそのサンプルまたはその予測パラメータの予測に対して用いられる従属ビュー１５のいかなるブロック３０２に対しても、このビュー間予測６０２はいかなる「隣接する空間セグメント」上にいかなる従属性も導入しない。これは、以下を意味する：各部分／ブロック３０２に対して、第２のビュー１５のそれぞれのブロック３０２と同じ場所に配置された第１のビュー１２の同じ場所に配置された部分６０６がある。「同じ場所」は、たとえば、ビュー１２内のブロックの円周が正確にローカルにブロック３０２の円周と同一指標を示すことが意図されている。あるいは、「同じ場所」はサンプル精度で測定されないが、「同じ場所に配置された」ブロックを決定することが結果としてレイヤ１２の画像のブロックへの分割からそのブロックの選択になる、すなわち、たとえば位置を組み込むものがブロック３０２の左上隅に対して同じ場所に配置された位置を組み込むまたはブロック３０２の他の代表位置を選択することになるように、レイヤ１２の画像が分割されるブロックのグラニュラリティで測定される。「同じ場所に配置された部分／ブロック」は６０６で示される。ビュー１２および１５の異なるビュー方向によって、同じ場所に配置された部分６０６が部分３０２と同じシーンコンテンツを備えることができないことを思い出してほしい。それでも、ビュー間予測の変更のシグナル化のケースでは、デコーダ６２０は、ビュー間予測６０２の対象とされる第２のビュー１５のいかなる部分／ブロック３０２も、ビュー間予測６０２によって、単に同じ場所に配置された部分／ブロック６０６が配置される空間セグメント３０１に従属すると仮定する。すなわち、お互いに他の一方が登録された第１および第２のビューの１２の１５の画像に注目するとき、ビュー間予測６０２は、第１のビュー１２のセグメント境界３００を横断せず、第２のビュー１５のそれぞれのブロック／部分３０２が配置されるそれらのセグメント３０１は１５を見るそれらのセグメント３０１内にとどまる。たとえば、マルチビューエンコーダ６００は、第２のビュー１５のビュー間予測された部分／ブロック３０２のシグナリング／選択された視差ベクトル６０４を適切に制限しており、および／または、「隣接する空間セグメント３０１」の情報からビュー間予測６０２を含む予測器をインデックスしないように、インデックスを予測器リストに適切に符号化／選択している。

【0045】

図８および９のエンコーダおよびデコーダに関して、お互いに組み合わせることができるまたは組み合わせることができないさまざまな実施形態を表すさまざまな可能な詳細の記載を続ける前に、以下が注目される。図８および９の説明から、エンコーダ６００がそのビュー間予測６０２の「変更／制限」を実現することができる異なる方法があることが明らかになる。よりゆるい制限において、エンコーダ６００は、ビュー間予測６０２が２つ以上の空間セグメントの情報を組み合わせないような方法おいてビュー間予測６０２を制限する。図９の記載は、従って、ビュー間予測６０２が空間セグメント３０２を横断しないようにさらに制限される、より厳しい制限例を特徴とする：すなわち、ビュー間予測６０２の対象とされる第２のビュー１５のいかなる部分／ブロック３０２も、ビュー間予測６０２を介して、その「同じ場所に配置されたブロック／部分６０６」が配置される第１のビュー１２のその空間セグメント３０１の情報から排他的にそのビュー間予測器を取得する。エンコーダは、それに応じて作動する。後者の制限タイプは、図８の記載の変形例を表し、前に記述されたものよりさらに厳しい。両方の変形例により、デコーダ６０２は制限を利用することができる。たとえば、デコーダ６２０は、適用されるようにシグナリングされる場合、第１のビュー１２と関連して第２のビュー１５を復号化することにおけるビュー間復号化のオフセット／遅延を低減する／減少させることによって、ビュー間予測６０２の制限を利用することができる。あるいはまたは加えて、デコーダ６０２は、ビュー１２および１５を並列に復号化するトライアルの実行を決定するとき、保証のシグナリングを考慮に入れることができる：適用するために保証がシグナリングされる場合に、デコーダは、日和見主義的にビュー間並列処理を実行し、それ以外はそのトライアルを差し控える。たとえば、第１のビュー１２が定期的に４つの空間セグメント３０１に分割され、各々が第１のビューの１２の画像の４分の１を表す、図９に示された実施例において、デコーダ６２０は、第１のビュー１２の第１の空間セグメント３０１が完全に復号化されるとすぐに、第２のビュー１５の復号化を開始することができる。それ以外は、視差ベクトル６０４が水平の自然界のみの中にあるとみなして、デコーダ６２０は、第１のビュー１２の両方の上側の空間セグメント３０１の完全な復号化を少なくとも待たなければならない。セグメント境界３００に沿ったビュー間予測のより厳しい変更／制限によって、保証の利用がより容易になる。

【0046】

前述の保証のシグナル化は、たとえば、単に１つの画像または画像のシーケンスさえを包含するスコープ／有効性を有することができる。したがって、後述するように、それは、ビデオパラメータセットまたはシーケンスパラメータセットまたはさらに画像パラメータセットにおいて、シグナリングすることができる。

【0047】

今まで、保証のシグナル化、データストリーム４０および図８および９のエンコーダおよびデコーダによってそれを符号化／復号化する方法を除いて、ビュー間予測６０２における変更によって変化しない実施形態が、図８および９に関して提供されてきた。むしろ、データストリームを復号化／符号化する方法は、ビュー間予測６０２における自己制限が適用されるか否かに拘らず、同じままである。代替の実施形態によれば、しかしながら、エンコーダおよびデコーダは、保証ケース、すなわち空間セグメント境界３００でのビュー間予測６０２の制限を利用するために、データストリーム４０を符号化／復号化するそれらの方法を変更しさえする。たとえば、データストリーム４０においてシグナル化可能な想定される視差ベクトルのドメインは、第１のビュー１２の空間セグメント境界３００の同じ場所の近くの第２のビュー１５のビュー間予測されたブロック／部分３０２に対して制限することができる。たとえば、もう一度図７を参照されたい。すでに上述されたように、図７は、第２のビュー１５の２つの例示的なブロック３０２’および３０２を示し、そのうちの１つ、すなわちブロック３０２は、第１のビュー１２の空間セグメント境界３００の同じ場所に配置された位置に近い。第１のビュー１２の空間セグメント境界３００の同じ場所に配置された位置は、それを第２のビュー１５に変えるとき、６２２で示される。図７に示されるように、ブロック３０２の同じ場所に配置されたブロック３０６は空間セグメント境界３００に近くにあり、垂直に分離する空間セグメント３０１ａは同じ場所に配置されたブロック６０６を備え、垂直に隣接する空間セグメント３０１ｂは、あまりに大きい視差ベクトルが同じ場所に配置されたブロック／部分６０６を右まで、すなわち隣接する空間セグメント３０１ｂの方へシフトするそのような範囲に、少なくとも部分的に、この隣接する空間セグメント３０１ｂのサンプルからコピーされるビュー間予測ブロック３０２に結果としてなり、この場合にビュー間予測６０２は空間セグメント境界３００を横断する。したがって、「保証ケース」において、エンコーダ６００は、ブロック３０２に対してこの種の視差ベクトルを選択することができず、したがって、ブロック３０２に対する想定される視差ベクトルの符号化可能なドメインは制限することができる。たとえば、ハフマン符号化を用いるとき、ビュー間予測されたブロック３０２に対して視差ベクトルを符号化するために用いられたハフマン符号は、ブロック３０２が可能な視差ベクトルのその制限されたドメインの事情を利用するために変更することができる。算術符号化のケースにおいて、たとえば、２進演算スキームと組み合せる他の２値化は視差ベクトルの符号化に用いることができる、または想定される視差ベクトルの中の他の確率分布を用いることができる。この実施形態によれば、空間セグメント境界３００でのビュー間予測の制限から結果として生じる軽微な符号化効率の減少は、空間セグメント境界３００の同じ場所に配置された位置の近くの空間セグメント３０２に対する視差ベクトルの伝送に関してデータストリーム４０内で伝達されるサイド情報の量を低減することによって、部分的に補償することができる。

【0048】

このように、前述の実施形態によれば、マルチビューエンコーダおよびマルチビューデコーダの両方とも、保証ケースが適用されるか否かに従って、データストリームから視差ベクトルを復号化／符号化するそれらの方法を変更する。たとえば、両方とも、視差ベクトルを復号化／符号化するために用いられるハフマン符号を変更する、または視差ベクトルを算術的に復号化／符号化するために用いられる２値化および／または確率分布を変更する。

【0049】

具体例に関して、図８および９におけるエンコーダおよびデコーダがデータストリーム４０においてシグナル化可能な想定される視差ベクトルのドメインを制限する方法をより明らかに記述するため、図１０が参照される。図１０は、ビュー間予測されたブロック３０２に対するエンコーダおよびデコーダの通常の挙動を再び示す：想定される視差ベクトルのドメインからの視差ベクトル３０８は、現在のブロック３０２に対して決定される。ブロック３０２は、従って視差補正されて予測される予測ブロックである。第１のビュー１２は、次に参照部分３０４でサンプルされ、それは、決定された視差ベクトル３０８によって、現在ブロック３０２に対して同じ場所に配置された第１のビュー１２の同じ場所に配置された部分３０６から変位させられる。データストリームにおいてシグナル化可能な想定される視差ベクトルのドメインの制限は、以下のようになされる：制限は、参照部分３０４が同じ場所に配置された部分３０６が空間的に配置される空間セグメント３０１ａ内に完全にあるようになされる。図１０に図示された視差ベクトル３０８は、たとえば、この制限を果たさない。それは、従って、ブロック３０２に対して想定される視差ベクトルのドメインに対して外部にあり、一実施形態によれば、ブロック３０２に関する限り、データストリーム４０においてシグナル化可能でない。代替の実施形態によれば、しかしながら、視差ベクトル３０８は、データストリームにおいてシグナル化可能となるが、エンコーダ６００は、保証ケースにおいて、この視差ベクトル３０８の適用を回避し、たとえば、ブロック３０２に対して、たとえば空間予測モードのような他の予測モードを適用することを選択する。

【0050】

図１０は、また、視差ベクトルのドメインの制限を実行するために、補間フィルタのカーネル半価幅１０を考慮することができることを図示する。より正確には、第１のビュー１２の画像から視差補正され予測されたブロック３０２のサンプルコンテンツのコピーにおいて、ブロック３０２の各サンプルは、サブペルの視差ベクトルのケースにおいては、特定の補間フィルタカーネルサイズを有する補間フィルタを用いて補間を適用することによって、取得することができる。たとえば、図１０において「ｘ」を用いて図示されるサンプル値は、その中心においてサンプル位置「ｘ」が配置されるフィルタカーネル３１１内のサンプルを組み合せることによって取得することができ、従ってブロック３０２に対する想定される視差ベクトルは、そのケースにおいて、参照部分３０４内にいずれのサンプルもないようにさえ制限することができ、フィルタカーネル３１１は、隣接する空間セグメント３０１ｂにオーバーレイするが、現在の空間セグメント３０１ａ内にとどまる。シグナル化可能なドメインは、したがって、制限することができるまたは制限することができない。代替の実施形態によれば、隣接する空間セグメント３０１ｂ内に配置されたフィルタカーネル３１１のサンプルは、サブペルの視差ベクトルに対して、想定される視差ベクトルのドメインの付加的な制限を回避するためにいくつかの例外的なルールに従う以外は、単純に装填することができる、デコーダは、しかしながら、単に保証を適用するためにシグナリングされるケースにおいて、交換装填を可能とする。

【0051】

後者の実施例は、デコーダ６２０ができるかできないか、および、加えてまたはあるいは、データストリームのエントロピー復号化における変更が、シグナリングおよびエンコーダ６００によってデータストリームに挿入されたようなデータストリームに応答して、空間セグメント境界３００でのビュー間予測を実行する方法を変更することを明らかにしている。たとえば、前述のように、エンコーダおよびデコーダの両方とも、保証ケースが適用されるか否かに従って、空間セグメント境界３００を越えて拡張する部分において補間フィルタカーネルを異なって充填することができる。同じことは、参照部分３０６そのものにも適用することができる。参照部分３０６は、それぞれの部分が現在の空間セグメント３０１ａの外部のいかなる情報からも独立した情報を代わりに用いて充填されて、隣接する空間セグメント３０１ｂに少なくとも部分的に拡張することが可能となりうる。事実上、エンコーダおよびデコーダは、保証ケースにおいて、参照部分３０４の部分および／または補間フィルタカーネル３１１が現在の空間セグメント３０１ａからの外挿によって充填されて、空間セグメント３００を画像境界のように扱うことができる。

【0052】

また、上述されたように、ビュー間予測６０２は、ビュー間予測されたブロック３０２のサンプルワイズのコンテンツの予測に制限されない。むしろ、ビュー間予測は、たとえば、ビュー１５の時間的に予測されたブロック３０２の予測に関係する動きパラメータ、または空間的に予測されたブロック３０２の予測に関係する空間予測パラメータの予測のような、予測パラメータの予測に適用することもできる。可能な変更、境界３００でのこの種のビュー間予測６０２に課される制限を説明するため、図１１が参照される。図１１は、ビュー間予測を用いて、そのパラメータが、少なくともインターエイリアスで予測される従属ビュー１５のブロック３０２を示す。たとえば、ブロック３０２のパラメータのいくつかの予測器のリストは、ビュー間予測６０２によって決定することができる。このために、エンコーダおよびデコーダは、たとえば、以下のように作用する：第１のビュー１２の参照部分は、現在ブロック３０２に対して選ばれる。参照部分／ブロック３１４の選択または導出は、第１のレイヤの１２の画像は分割される、符号化ブロック、予測ブロック等のようなブロックから実行される。その導出に対して、第１のビュー１２内の代表位置３１８は、ブロック３０２の代表位置６２８、またはブロック３０２に隣接する隣接ブロック３２０の代表位置６３０に対して同じ場所に配置されるように決定することができる。たとえば、隣接ブロック３２０は、ブロック３０２のトップに対するブロックとすることができる。ブロック３２０の決定は、第２のビューレイヤの１５の画像がブロック３０２の左上隅のサンプルのトップの直近にサンプルを備えるように分割されるブロックからの選択ブロック３２０を含むことができる。代表位置６２８および６３０は、左上隅におけるサンプルまたはブロック等の中央におけるサンプルとすることができる。第１のビュー１２における参照位置３１８は、次に６２８または６３０に対して同じ位置に配置される位置である。図１１は、位置６２８に対して同じ場所を図示する。次に、エンコーダ／デコーダは、視差ベクトル３１６を推定する。これは、たとえば、それぞれ、現在のシーンの推定された距離画像に基づいて、またはすでに復号化され、ロック３０２またはブロック３２０の空間‐時間的に近傍にある視差ベクトルを用いて、なすことができる。このように決定された視差ベクトル３１６は、ベクトル３１６のヘッドが配置６３２をポイントするように、代表位置３１８に適用される。第１のビュー１２の画像のブロックへの分割の中で、参照部分３１４は、配置６３２を備えるその部分であるように選択される。ちょうど言及されたように、部分／ブロック３１４の選択がなされる分割は、ビュー１２の符号化ブロック、予測ブロック、残差ブロックおよび／または変換ブロックの分割とすることができる。

【0053】

一実施形態によれば、単にマルチビューエンコーダは、参照部分３１４が隣接する空間セグメント３０１ｂ内に、すなわち参照ポイント６２８の同じ場所がある、同じ場所に配置されたブロックを備えない空間セグメント内にあるかどうかをチェックする。エンコーダが上記概説された保証をデコーダにシグナリングする場合、エンコーダ６００は、現在のブロック３０２のパラメータに対するいかなる適用も抑制する。すなわち、ブロック３０２のパラメータに対する予測器のリストは境界３００の横断に導くビュー間予測器を備えることができるが、エンコーダ６００はその予測器を選択することを回避し、不必要な予測器をポイントしないブロック３０２に対するインデックスを選ぶ。マルチビューエンコーダおよびデコーダの両方が、保証ケースにおいて、参照部分３１４が隣接する空間セグメント３０１ｂ内にあるかどうかをチェックする場合、エンコーダおよびエンコーダの両方は、他の予測器を有する「境界を横断する」ビュー間予測器を他の予測器で置換するまたは単純にそれを、たとえば、空間的におよび／または時間的に予測されたパラメータおよび／または１つ以上の不履行予測器をも含むこともできる予測器のリストから排除することができる。状態、すなわち参照部分３１４が空間セグメント３０１ａの一部であるかまたはないかどうか、および条件つきの置換または排除のチェックは、単に保証ケースにおいてなされる。非保証のケースでは、参照部分３１４が空間セグメント３０１ａ内にあるかどうかのいかなるチェックも中止することができ、参照部分３１４の属性から導き出された予測器のブロック３０２のパラメータの予測への適用は、参照部分３１４が空間セグメント３０１ａまたは３０１ｂ内にあるかまたはどこにあるかに拘りなく、なすことができる。ブロック３１４の属性から導き出されたいかなる予測器も現在のブロック３０２に対する予測器のリストに加えない、または代替予測器の追加のケースでは、空間セグメント３０１ａ内にまたは外にある参照ブロック３１４に従い、通常のビュー間予測のそれぞれの修正が、エンコーダ並びにデコーダ６２０によって実行される。この手段によって、このように決定されたブロック３０２に対する予測器のリストへのいかなる予測器インデックスも、デコーダ内の同じ予測器のリストをポイントする。ブロック３０２に対するインデックスのシグナル化可能なドメインは、保証ケースが適用されるか否かに応答して制限することができるまたは制限することができない。補償ケースが適用されるが、単にエンコーダがチェックを実行するケースでは、マルチビューエンコーダは、参照部分３１４が空間セグメント３０１ａ内にあることに拘らず（そして、保証ケースを適用するか否かにさえ拘らず）、しかしながら、予測ケースにおいて、予測器のリストが空間セグメント３０１ａの外部にあるブロック３１４の属性から導き出されたケースにおいて、それから予測器を選択しないようにインデックスを制限することによって、ブロック３０２に対する予測器のリストを形成する。そのケースでは、デコーダ６２０は、同じ方法で、すなわち保証および非保証のケースにおいて、エンコーダ６００が、ビュー間予測が隣接する空間セグメント３０１ｂからいかなる情報も必要としないことに既に対処しているのと同じ方法で、ブロック３０２に対する予測器のリストを形成することができる。

【0054】

ブロック３０２のパラメータおよび参照部分３１４の属性に関しては、それは、動きベクトル、視差ベクトル、変換係数のような残差信号、および／または、奥行き値とすることができることが注目される。

【0055】

図８～１１に関して記述されたビュー間予測変更コンセプトは、すなわち後述される方法で、ＨＥＶＣ標準の現在想定されている拡張に導入することができる。その限りにおいて、以下に間近に提案される記載は、図８～１１に関して上記提案された記載に関する可能な実施詳細に対する基礎としても解釈される。

【0056】

中間の注として、ビュー間予測が変更／制限される境界においてユニットを形成するとして上記議論された空間セグメント３０１は、そのユニットにおいてイントラレイヤ並列処理が軽減されるまたは可能にされるこの種の空間セグメントを必ずしも形成しないことが注目される。言い換えれば、図８～１１の上記議論された空間セグメントは、ベースレイヤ１２が分割されるタイルとすることができるが、空間セグメント３０１がベースレイヤ１２の符号化ツリールートブロックＣＴＢを形成する実施例のような、他のサンプルも同様に可能である。後述する実施形態において、空間セグメント３０１は、タイルの定義と結合される、すなわち、空間セグメントはタイルまたはタイルのグループである。

【0057】

超低遅延に対して引き続いて説明された制限およびＨＥＶＣにおける並列化により、レイヤ間予測は、ベースレイヤ画像、特にタイルの分割を確実にする方法で拘束される。

【0058】

ＨＥＶＣは、垂直および水平の境界のグリッドを介して、符号化されたベースレイヤ画像のＣＴＢを、タイルと称され、インループフィルタリングを除いて独立に処理することができる矩形状領域に分割することを可能にする。インループフィルタは、それらを完全に独立にするために、タイル境界でターンオフすることができる。

【0059】

タイル境界のアーチファクトを減らすように構成された場合に、インループフィルタはタイル境界を横断することができるが、解析および予測の従属性は、特に画像境界のようなタイル境界においては破壊される。それ故に、個々のタイルの処理は、画像内の他のタイルに完全には、またはフィルタリング構成の広大な範囲の従属に対しては、依存しない。タイルの全てのＣＴＢが同じスライスに帰属する、または、スライスの全てのＣＴＢが同じタイルに帰属するという点で、制限がインストールされる。図１において分かるように、タイルは、ＣＴＢスキャン順序が、タイルの順序、すなわち、第２のタイル、例えば右上タイルに帰属するＣＴＢを続ける前に、第１のタイル、例えば左上タイルに帰属する全てのＣＴＢを通過することに注意するように強制する。タイル構造は、画像内でグリッドを構成する各タイルの行および列におけるＣＴＢの数およびサイズを通して定められる。この構造は、フレームベース当りで変更するまたは符号化ビデオシーケンスにわたって一定である、のいずれかとすることができる。

【0060】

図１２は、画像内でのＣＴＢの９枚のタイルへの例示的な分割を示す。太い黒線はタイル境界を表し、番号付けはＣＴＢのスキャン順序を表し、またタイル順序を示す。

【0061】

ＨＥＶＣ拡張の増強レイヤタイルは、ベースレイヤビットストリームにおけるその対応するイメージエリアをカバーする全てのタイルが復号化されるとすぐに、復号化することができる。

【0062】

次のセクションは、図７～１１のコンセプトを用いて、より低いレイヤ間符号化オフセット／遅延を可能とする、拘束、シグナリングおよび符号化／復号化プロセスの修正を記述する。

【0063】

ＨＥＶＣにおけるタイル境界に関係する修正された復号化プロセスは、以下のように見ることができる：

【0064】

ａ）動きまたは視差ベクトルは、ベースレイヤにおいてタイルを横断してはならない。
拘束が可能な場合、以下を適用する：
レイヤ間予測（例えば、サンプル値、動きベクトル、残差データまたは他のデータの予測のような）が参照用画像としてベースビュー（レイヤ１２）を用いる場合、視差または動きベクトルは、参照された画面エリアが共起されたベースレイヤＣＴＵと同じタイルに帰属するように、拘束される。特定の実施形態において、動きまたは視差ベクトル３０８は、参照された画像エリアが同じタイルの内部に配置され、参照されたサブペル位置は同じタイルの内部の情報のみから予測されるように、復号プロセスにおいてクリップされる。現在のＨＥＶＣのサンプル補間プロセスにおいてより具体的には、これはタイル境界３００から３～４画素離れてクリップされるサブペル位置をポイントする動きベクトルを拘束する、またはビュー間動きベクトル、ビュー間残差予測プロセスにおいて、これは同じタイル内の位置をポイントする視差ベクトルを拘束する。代替の実施形態は、動きベクトルがタイル境界に対してサブペル補間フィルタのカーネルサイズ３１０より近くに配置されるサブペル位置をポイントすることを可能とするために、画像境界に類似するタイル境界をハンドリングするようにサブペル補間フィルタを調整する。代替の実施形態は、前述の実施形態においてクリップされている動きまたは視差ベクトルの使用を許容しないビットストリーム拘束を意味する。

【0065】

ｂ）ベースレイヤにおいて共起されたブロックの隣接するブロックは、異なるタイルのときは利用されない。
制限が使用可能である場合、以下が適用される：
ベースレイヤが隣接するブロックからの予測（例えばＴＭＶＰまたは隣接するブロックの視差の導出のような）に用いられ、およびタイルが用いられる場合、以下が適用される：ＣＴＵ Ｂが、共起されたベースレイヤＣＴＵ Ａと同じタイルに帰属する場合、ベースレイヤにおいて共起されたＣＴＵ Ａと異なるＣＴＵ Ｂから生ずる予測器候補が用いられるだけである。たとえば、現在のＨＥＶＣの導出プロセスにおいて、ＣＴＵ Ｂは、共起されたＣＴＵ Ａの右に配置される。本発明の特定の実施形態において、予測候補は、異なる予測によって置換される。たとえば、共起されたＰＵは、その代わりに予測に対して用いることができる。本発明の他の実施形態では、符号化ビットストリームにおいて、関連する予測モードの使用は許容されない。

【0066】

ちょうど概説されたＨＥＶＣ修正の可能性の図８および１１の記載上への変形として、図１１の予測器の置換に関する限り、第１のレイヤ１２のそのブロックのそれぞれの属性になるように、同じことを選択することができ、それは現在のブロック３０２の参照位置６２８の同じ場所に配置された位置自身を備えることが注目される。

【0067】

ｃ）シグナリング
特定の実施形態において、たとえば図１３ａ、１３ｂで示されたように、以下の高水準シンタックスを、Ｎ個のフラグを用いて上述された拘束／制限を可能とするために、ＶＰＳまたはＳＰＳに用いることができる。

【0068】

ここで、inter＿layer＿PREDTYPE＿RESTYPE＿SCAL＿flag＿1 から inter＿layer＿PREDTYPE＿RESTYPE＿SCAL＿flag＿N における、PREDTYPE, RESTYPE, SCALは、以下で記述されるように異なる値に置換してもよい：
PREDTYPE は、制限／拘束が適用される予測タイプを指示し、リストされない以下のまたは他の予測タイプの１つとしてもよい：
－ 例えば、ベースビューにおいて共起されたブロックの隣接するブロックからの時間的動きベクトルの予測に対する、temporal＿motion＿vector＿prediction
－ 例えば、ベースビューにおいて共起されたブロックの隣接するブロックからの視差ベクトルの予測に対する、disparity＿vector＿prediction
－ 例えば、ベースビューからの奥行き値の予測に対する、depth＿map＿derivation
－ 例えば、ベースビューからの動きベクトルの予測に対する、inter＿view＿motion＿predition
－ 例えば、ベースビューからの残差データの予測に対する、inter＿view＿residual＿prediction
－ 例えば、ベースビューからのサンプル値の予測に対する、inter＿view＿sample＿prediction

【0069】

あるいは、制限／拘束が適用される予測タイプに対して明確にはシグナリングされず、全ての予測タイプに対して制限／拘束が適用される、または、セット当り１つのフラグのみを利用する予測タイプのセットに対して、制限／拘束がシグナリングされる。

【0070】

RESTYPE は、制限のタイプを指示する。以下のうちの１つとしてもよい：
－ 例えば、拘束（ビットストリーム拘束を指示する。フラグをＶＵＩに含めることができることを指示する）
－ 例えば、制限（クリッピング（ａ）または異なる予測器の選択（ｂ）を指示する）

【0071】

SCAL は、制限／拘束が同じタイプのレイヤに対してのみ適用されるかどうかを指示する：
－ 例えば、same＿scal（ベースレイヤが増強レイヤと同じスケーラビリティタイプであるとき、制限のみが適用されることを指示する）
－ 例えば、diff＿sca（ベースレイヤおよび増強レイヤのスケーラビリティタイプに関係なく、制限が適用されることを指示する）

【0072】

図１４が関係する代替の実施形態として、例えば、ＶＰＳまたはＳＰＳにおいて、ultra＿low＿delay＿decoding＿mode＿flag のように、全ての記述された制限の使用を、高水準シンタックスにおける超低遅延モードとして、シグナリングすることができる。

【0073】

１に等しい ultra＿low＿delay＿decoding＿mode＿flag は、タイル境界で修正された復号化プロセスの使用を指示する。

【0074】

このフラグによって暗示される制限は、タイル境界アラインメント上の拘束およびタイル境界にわたるアップサンプリングフィルタの拘束を含むこともできる。

【0075】

すなわち、図１を参照すると、保証シグナリングは、画像のシーケンスにわたり延伸する期間のような予め定められた期間において、第２レイヤの画像の空間セグメント８２の間の境界８４が第１の空間セグメント８０のすべての境界８６をオーバーレイするように（空間スケーラビリティが考慮される場合、おそらくアップサンプリングの後）、第２レイヤの画像１５が再分割されるという保証をシグナリングするために付加的に用いることができる。デコーダは、予め定められた期間より小さいタイムインターバルにおいて、例えば、個々の画像を単位とするような、すなわち画像ピッチインターバルにおいて、マルチレイヤビデオデータストリーム４０の短期のシンタックスエレメントに基づいて、第１のレイヤおよび第２のレイヤの画像１２、１５の空間セグメント８０および８２への実際の再分割を、依然として周期的に決定するが、アラインメントに関する知識は並列処理のワークロードアサインメントのプランニングを既に助けている。図１における実線８４は、たとえば、タイル境界８４がレイヤ０のタイル境界８６に完全に空間的に整合している実施例を表す。ちょうど言及された保証は、しかしながら、レイヤ１のタイル分割が、更に、レイヤ０のタイル境界８６のいずれをも空間的にオーバーラップしない付加的なタイル境界を含むように、レイヤ０のタイル分割より精細なレイヤ１のタイル分割も可能とする。いずれにせよ、レイヤ１とレイヤ０の間のタイル登録についての知識は、並列に同時に処理される空間セグメントの中で利用できるワークロードまたは処理パワーをアロケートすることにおいて、デコーダを助ける。長期のシンタックスエレメント構造なしで、デコーダは、より小さいタイムインターバル、すなわち画像当りにおいて、ワークロードアロケーションを実行しなければならず、それによりワークロードアロケーションを実行するためにコンピュータパワーを消費する。他の態様は「日和見的復号化」である：多重のＣＰＵコアを有するデコーダは、より複雑性の高いレイヤ、すなわち、またはより高いレイヤ数または、言い換えれば更なるビュー数のレイヤを復号化しようとするかまたはしないかを決定するために、レイヤの並列性についての知識を利用することができる。シングルコアの能力を超えるビットストリームは、デコーダの全てのコアを利用することによって復号化可能であろう。プロファイルおよびレベルの指示器が最小限の並列性に関するこの種の指示を含まない場合、この情報は特に有用である。

【0076】

前述したように、保証のシグナル化（例示的に、ultra＿low＿delay＿decoding＿mode＿flag ）は、また、従属ビュー画像１５と異なる空間分解能を有するベースレイヤ画像１２によるマルチレイヤビデオのケースにおいて、アップサンプリングフィルタ３６をステアリングするために用いることができる。アップサンプリングフィルタリングが、レイヤ０において空間セグメント境界８６を横切って実行された場合、レイヤ０の空間セグメント８０の符号化／復号化と関連して、レイヤ１の空間セグメント８２を並列に復号化／符号化する際に遭遇する遅延は、アップサンプリングフィルタリングはレイヤ０の隣接する空間セグメントの情報を組み合わせ、従って相互に従属させ、レイヤ１のブロック４１のレイヤ間予測において用いられる予測参照３８として役立つので、増大する。図１５を参照されたい。両方の画像１２および１５は、空間的対応に従ってお互いに必要な大きさにされ、登録される、すなわちシーンの同じ部分示す部分がお互いにオーバーレイすることによるオーバーレイ方法において示される。画像１２および１５は、それぞれタイルのような空間セグメント６および１２に分割されることが例示的に示される。フィルタカーネルは、左上側のタイルに空間的にオーバーレイする画像１５のタイル内のいかなるブロックのレイヤ間予測に対しても基礎として役立つアップサンプルされたバージョンを取得するために、画像１２の左上側のタイルを横切って移動するように、図示されている。２０２のようないくつかの中間のインスタンスにおいて、カーネル２００は画像１２の隣接するタイルにオーバーラップする。アップサンプルされたバージョンの位置２０２におけるカーネル２００の中央のサンプル値は、従って画像１２の左上タイルのサンプル並びにその右に対する画像１２のタイルのサンプルの両方に従属する。画像１２のアップサンプルされたバージョンがレイヤ間予測の根拠として役立つ場合、レイヤのセグメントの並列処理において、レイヤ間遅延は増大する。制限は、異なるレイヤを横切る並列化量の増大を助けることができ、したがって、オーバーオールの符号化遅延の低減を助けることができる。当然、シンタックスエレメントは、画像のシーケンスに対して有効な長期のシンタックスエレメントとすることもできる。制限は、以下の方法の１つにおいて達成することができる：たとえば、カーネル２００の非破線の部分内のサンプル値の中心傾向によって、オーバーラップ位置２０２におけるカーネル２００のオーバーラップ部分を装填し、線形または他の機能を用いて、非破線の部分を破線のもの等に外挿する。

【0077】

代替の実施形態は、実施例として、ＶＰＳにおける以下において与えられる。前述された制限／拘束が ultra＿low＿delay＿decoding＿mode＿flag によって制御されるが、代替として（フラグが使用不能なときに）各制限／拘束を個々に使用可能とすることができる。この実施形態に対して、図１３ｃおよび１３ｄが参照される。この実施形態は、他の非ＶＣＬ ＮＡＬユニット（例えば、ＳＰＳまたはＰＰＳ）において含むこともできる。図１３ｃおよび１３ｄにおいて、

【0078】

１に等しい ultra＿low＿delay＿decoding＿mode＿flag は、 du＿interleaving＿enabled＿flag、interlayer＿tile＿mv＿clipping＿flag、depth＿disparity＿tile＿mv＿clipping＿flag、inter＿layer＿tile＿tmvp＿restriction＿flag および independent＿tile＿upsampling＿idc が１に等しいと推定され、ＶＰＳ、ＳＰＳまたはＰＰＳにおいて存在しないことを特定する。

【0079】

タイルのような並列化技術がレイヤ化された符号化ビデオシーケンスにおいて用いられるとき、統一された方法でタイルの境界を横断しないようにするため、ＨＥＶＣの拡張においてビュー間予測のような符号化ツールの制限を制御することは、遅延予想から有益である。

【0080】

実施形態において、independent＿tiles＿flag 、または independent＿tile＿upsampling＿idc の値は、inter＿layer＿PREDTYPE＿RESTYPE＿SCAL＿flag＿x または independent＿tile＿upsampling＿idc のような個々の制限／拘束を制御するシンタックスエレメントの存在を決定する。 independent＿tiles＿flag は、図１３ｅに図示されるように、ＶＰＳに含むことができる。
ここで

【0081】

１に等しい independent＿tiles＿flag は、inter＿layer＿PREDTYPE＿RESTYPE＿SCAL＿flag＿1 ～inter＿layer＿PREDTYPE＿RESTYPE＿SCAL＿flag＿N、および independent＿tile＿upsampling＿idc が１に等しいと推定され、ＶＰＳ、ＳＰＳまたはＰＰＳにおいて存在しないことを特定する。

【0082】

代替の実施形態が、ＶＰＳにおいて、上述された拘束は、independent＿tiles＿flag によって制御されるが、代替として（フラグが使用付加のとき）各拘束は個々に使用可能とすることができることが、実施例として図１３ｆで与えられる。この実施形態は、図１３ｇに図示されたように、他の非ＶＣＬ ＮＡＬユニット（たとえばＳＰＳまたはＰＰＳ）においても含むことができる。

【0083】

図８～図１５に関して今までに記述された前記実施例を要約して、データストリームにおける保証のシグナル化は、異なるレイヤ／ビュー１２および１５の復号化の間のレイヤ間復号化オフセットを最適化するためにデコーダ６２０によって用いることができる、または、保証は「日和見主義的な復号化」を参照することによって上記の通りにレイヤ間並列処理裁判を抑制するかまたは認めるためにデコーダ６２０によって利用することができる。

【0084】

次に議論される本願の態様は、マルチレイヤビデオ符号化における、より低いエンドツーエンドの遅延を可能とする問題に関する。次に記述される態様は、前に記述された態様と組み合わせることができるが、その逆も正しいことに注目する価値があり、ここで記述される態様に関する実施形態は、上述された詳細なしで実施することもできる。この点に関して、以後に記述される実施形態は、マルチビュー符号化に制限されないことにも注目すべきである。本願の第２の態様に関する以下に言及される多重のレイヤは、異なるビューを含むことができるが、変化する空間分解能、ＳＮＲ精度等において、同じビューを表すこともできる。以下に議論される多重レイヤが前のレイヤによって伝達される情報コンテンツを増大させる可能なスケーラビリティディメンションは、マニホルドであり、たとえば、ビューの数、空間分解能およびＳＮＲ精度を備え、更なる可能性は本願の第３および第４の態様を議論することから明らかになり、その態様は、実施形態に従って現在記述されている態様と組み合わせることもできる。

【0085】

ここで記述される本願の第２の態様は、低符号化遅延、すなわちＮＡＬユニットのフレームワークに低遅延のアイデアを埋め込むことを実際に達成する問題に関する。上述のように、ＮＡＬユニットは、スライスから構成される。タイルおよび／またはＷＰＰコンセプトは、マルチレイヤビデオデータストリームの異なるレイヤに対して、個々に自由に選択される。したがって、それにパケット化されるスライスを有する各ＮＡＬユニットは、それぞれのスライスが参照する画像のエリアに空間的に起因することができる。したがって、レイヤ間予測のケースにおいて低遅延符号化を可能とするため、同じタイムインスタントに付随する異なるレイヤのＮＡＬユニットをインターリーブすることを可能とし、エンコーダおよびデコーダが符号化および伝送を開始し、およびこれらのＮＡＬユニットにパケット化されたスライスを、異なるレイヤのこれらの画像の並列処理を可能とするが、同じタイムコンスタントに付随する方法で、それぞれ復号化することを可能とすることは有利である。しかしながら、アプリケーションに依存して、エンコーダは、レイヤディメンションにおいて並列処理を可能とする能力をこえて、異なるレイヤに対して異なるＧＯＰ構造の使用のような、異なるレイヤの画像の中で異なる符号化順序を用いる能力を好むことができる。したがって、第２の態様によれば、データストリームの構造は、図１６に関して以下に再び記述されるようにすることができる。

【0086】

図１６は、異なるレイヤの各々に対して画像２０４のシーケンスから構成されるマルチレイヤビデオ材料２０１を示す。各レイヤは、マルチレイヤビデオ材料２０１によって記述されるこのシーンの異なるプロパティを記述することができる。すなわち、レイヤの意味は、次の中から選択することができる：たとえば、色成分、距離画像、透明性および／または視点。一般性を失うことなく、異なるレイヤはマルチビュービデオであるビデオ材料２０１によって異なるビューに対応すると仮定する。

【0087】

低遅延を必要とするアプリケーションのケースでは、エンコーダは、長期の高水準シンタックスエレメントをシグナリングすることを決定することができる（ 以下で導入される du＿interleaving＿enabled＿flag を１に等しくなるようにセットする）。その場合、エンコーダによって生成されるデータストリームは、それを囲む円によって図１６の中央において指示されるように見ることができる。その場合、マルチレイヤビデオストリーム２００は、１つのアクセスユニット２０６に帰属するＮＡＬユニット２０２が１つの時間的タイムインスタントの画像に関係するように、ＮＡＬユニット２０２のシーケンスからなり、異なるアクセスユニットのＮＡＬユニット２０２は異なるタイムインスタントに関係する。各アクセスユニット２０６内で、各レイヤに対して、それぞれのレイヤに関係する少なくともいくつかのＮＡＬユニットは、１つ以上の復号化ユニット２０８にグループ化される。これは、以下を意味する：ＮＡＬユニット２０２の中で、上記指示されたように、一方ではＶＣＬ ＮＡＬユニットおよび他方では非ＶＣＬ ＮＡＬユニットのような異なるタイプのＮＡＬユニットがある。より詳しくは、ＮＡＬユニット２０２は異なるタイプを持つことができ、これらのタイプは以下を備えることができる：

【0088】

１）スライス、タイル、ＷＰＰサブストリーム等、すなわち予測パラメータに関するシンタックスエレメントおよび／または画像サンプルのスケール／グラニュラリティについて画像コンテンツを記述する残差データを担持するＮＡＬユニット。１つ以上のこの種のタイプは存在することができる。ＶＣＬ ＮＡＬユニットはこの種のタイプの中にある。この種のＮＡＬユニットは着脱可能でない。

【0089】

２）パラメータセットＮＡＬユニットは、長期の符号化設定のようなまれに変更される情報を担持することができ、そのいくつかの例は上述されている。この種のＮＡＬユニットは、たとえば、データストリーム内で、ある程度および繰り返し散在することができる；

【0090】

３）補助増強情報（ＳＥＩ）ＮＡＬユニットは、オプションのデータを担持することができる。

【0091】

復号化ユニットは、上述したＮＡＬユニットの第１から構成することができる。より正確には、復号化ユニットは、「アクセスユニットにおける１つ以上のＶＣＬ ＮＡＬユニットおよび関連する非ＶＣＬ ＮＡＬユニット」から構成することができる。復号化ユニットは、従って、１つの画像の特定のエリア、すなわちそこに含まれる１つ以上のスライスに符号化されるエリアを記述する。

【0092】

異なるレイヤに関係するＮＡＬユニットの復号化ユニット２０８は、各復号化ユニットに対して、それぞれの復号化ユニットを符号化するために用いられたレイヤ間予測が、それぞれの復号化ユニットが関係するレイヤ以外のレイヤの画像の部分に基づき、その部分がそれぞれのアクセスユニット内でそれぞれの復号化ユニットの前の復号化ユニットに符号化されるように、インターリーブされる。例えば、図１６における復号化ユニット２０８ａを参照されたい。この復号化ユニットが、例示的に、従属レイヤ２および特定のタイムインスタントのそれぞれの画像のエリア２１０に関係することを想像されたい。同じタイムインスタントのベースレイヤ画像における同じ場所に配置されたエリアは２１２によって示され、このエリア２１２をわずかに超過しているこのベースレイヤ画像のエリアは、レイヤ間予測を利用することによって復号化ユニット２０８ａを完全に復号化するために必要とすることができる。わずかに超過しているは、たとえば、視差補正された予測の結果とすることができる。これは、順番に、アクセスユニット２０６内で復号化ユニット２０８ａに先行する復号化ユニット２０８ｂが、レイヤ間予測に対して必要とされるエリアを完全にカバーしなければならないことを意味する。インターリービング・グラニュラリティに対して境界として用いることができる遅延指示に関して、上記記述が参照される。

【0093】

しかしながら、アプリケーションは、異なるレイヤの中の画像の復号化順序を異なって選択する自由をより多く利用する場合、図１６のボトムにおいて、それを囲む円によって２で表されているこのケースによって、エンコーダは du＿interleaving＿enabled＿flag が０に等しくなるようにセットすることを選ぶことができる。この場合、マルチレイヤビデオデータストリームは、レイヤＩＤおよび単一のタイムインスタントの１つ以上の値の特定のペアに帰属する各画像に対して個々のアクセスユニットを有する。図１６に示されるように、（ｉ－１）番目の復号化順序、すなわちタイムインスタントｔ（ｉ－１）において、各レイヤは、アクセスユニットＡＵ１、ＡＵ２（など）から構成することができる、または全てのレイヤが単一のアクセスユニットＡＵ１に含まれるように構成することができる。しかしながら、この場合に、インターリービングは許容されない。アクセスユニットは、データストリーム２００において、復号化順序インデックスｉに従って配置される、すなわち各レイヤに対して復号化順序インデックスｉのアクセスユニットであって、復号化順序ｉ＋１に対応してこれらのレイヤの画像に関するアクセスユニットが続く。データストリームにおける時間的な画像間予測のシグナリングは、異なるレイヤに対して等しい符号化順序を適用するまたは異なる画像符号化順序を適用する、のいずれであるかに関してシグナリングし、シグナリングは、たとえば、ＮＡＬユニットへパケット化されるスライス内のようにデータストリーム内で、１つの位置内でまたは１つ以上の位置内で冗長に配置することができる。

【0094】

ＮＡＬユニットタイプに関して、それらの中で定められる順序ルールは、取り外し可能なパケットタイプのＮＡＬユニットが伝送の間に除去されたか否かに拘らず、連続的なアクセスユニットの間の境界がどこに位置されるかをデコーダが決定することを可能にすることができることが注目される。取り外し可能なパケットタイプのＮＡＬユニットは、たとえば、ＳＥＩ ＮＡＬユニット、または、冗長な画像データのＮＡＬユニットまたは他の特定のＮＡＬユニットタイプを備えることができる。すなわち、アクセスユニット間の境界は移動せずにとどまり、そして、しかし、順序ルールは各アクセスユニット内で守られるが、２つのアクセスユニットの間の各境界では破られる。

【0095】

完全のため、図１７は、du＿interleaving＿flag = 1 のケースであって、異なるレイヤに帰属するパケットを可能とするが、１つのアクセスユニット内で、たとえば、同じ時間インスタントｔ（ｉ－１）が分布されるケースを図示する。du＿interleaving＿flag = 0 のケースは、図１６において、それを囲む円によって２で表されている。

【0096】

しかしながら、図１６および１７に関して、上述されたインターリービングのシグナル化またはインターリービングのシグナリングが、必然的に、図１６および１７においてそれを囲む円によって１で示されるケースに従ってアクセスユニット定義を使用するマルチレイヤビデオデータストリームに結果としてなると共にやめられることができることが注目される。

【0097】

実施形態によれば、各アクセスユニット内に含まれるＮＡＬユニットが実際にインターリーブされるか否かに関する事実は、データストリームのレイヤとのそれらの関連に関して、エンコーダの裁量で決定することができる。データストリームのハンドリングを容易にするため、du＿interleaving＿flag のようなシンタックスエレメントは、デコーダがＮＡＬユニットをより容易に処理できるように、特定のタイムスタンプの全てのＮＡＬユニットを集合するアクセスユニット内で、ＮＡＬユニットのインターリービングまたは非インターリービングをデコーダにシグナリングすることができる。たとえば、インターリービングがスイッチオンされるようにシグナリングされるときはいつでも、図１８に関して簡単に図示されるように、デコーダは複数の符号化画像バッファを用いることができる。

【0098】

図１８は、図２に関して上記概説されたように具現化することができ、図９に関して提案された記述にさえ対応することができるデコーダ７００を示す。例示的に、図１７のマルチレイヤビデオデータストリームは、それを囲む円によってオプション１がエンタリングデコーダ７００として示される。異なるレイヤに帰属するＮＡＬユニットのデインターリービングを、より容易に、アクセスユニットＡＵ当りの共通のタイムインスタントで実行するために、デコーダ７００は、各アクセスユニットＡＵに対して、たとえばバッファ７０２に対して第１のレイヤに帰属するそのアクセスユニットＡＵのＮＡＬユニットをフォワードし、たとえばバッファ７０４に対して第２のレイヤに帰属するＮＡＬユニットをフォワードするマルチプレクサ７０６を有する２つのバッファ７０２、７０４を用いる。復号化ユニット７０８は、次に復号化を実行する。たとえば、図１８において、たとえば、ベースレイヤ／第１のレイヤに帰属するＮＡＬユニットはハッチされて示されていないが、従属レイヤ／第２のレイヤのＮＡＬユニットはハッチングを用いて示されている。上記概説されたインターリービングのシグナリングがデータストリームに存在する場合、デコーダ７００は、以下の方法でこのインターリービングのシグナリングに応答することができる：インターリービングのシグナリングがＮＡＬユニットにインターリービングがスイッチオンされるようにシグナリングする場合、すなわち、異なるレイヤのＮＡＬユニットが１つのアクセスユニットＡＵ内で互いにインターリーブされ、デコーダ７００は、ちょうど概説されたように、これらのバッファ上にＮＡＬユニットを分布するマルチプレクサ７０６を有するバッファ７０２および７０４を用いる。そうでない場合には、しかしながら、デコーダ７００は、アクセスユニットに備えられる全てのＮＡＬユニットに対して、単にバッファ７０２および７０４のうちの１つ、たとえばバッファ７０２を用いる。

【0099】

図１８の実施形態をより容易に理解するために、マルチレイヤビデオデータストリームを生成するように構成されたエンコーダが示される図１９とともに図１８が参照される。図９のエンコーダは、一般に参照符号７２０を用いて指示され、理解の容易のため、例示的に、ベースレイヤを形成するレイヤ１２と従属レイヤを形成するレイヤ１が指示される２つのレイヤの入力画像を符号化する。それらは、前に概説されたように、異なるビューを形成することができる。エンコーダ７２０がレイヤ１２および１５の画像を符号化する一般的な符号化順序は、これらのレイヤの画像を実質的に時間的順序（提示時間）に沿ってスキャンし、符号化順序７２２は、画像のグループのユニットにおいて、画像１２および１５の提示時間順序から逸脱することができる。各時間的タイムインスタントにおいて、符号化順序７２２は、レイヤ１２および１５の画像を、それらの従属性に沿って、すなわちレイヤ１２から１５の画像を渡す。

【0100】

エンコーダ７２０は、それぞれが空間的感覚においてそれぞれの画像の一部と関連している上述のＮＡＬユニットを単位として、レイヤ１２および１５の画像をデータストリーム４０に符号化する。このように、特定の画像に帰属するＮＡＬユニットは、それぞれの画像を空間的に再分割または分割し、既に記述されたように、レイヤ間予測は、レイヤ１５の画像の部分を、レイヤ１５の画像のそれぞれの部分と実質的に同じ場所に配置され、実質的に視差変位を含んでいるレイヤ１２の時間整合された画像の部分に従属させる。図１９の実施例において、エンコーダ７２０は、特定のタイムインスタントに帰属する全てのＮＡＬユニットを集合するアクセスユニットの形成においてインターリービングの可能性を利用することを選択する。図１９において、図示されたデータストリーム４０からの部分は、図１８のデコーダに入力されたものに対応する。すなわち、図１９の実施例において、エンコーダ７２０は、レイヤ１２および１５の符号化においてレイヤ間並列処理を用いる。タイムインスタントｔ（ｉ－１）が関係する限り、エンコーダ７２０は、レイヤ１２の画像のＮＡＬユニット１が符号化されるとすぐに、レイヤ１５の画像の符号化を開始する。各ＮＡＬユニットは、その符号化が完了すると、エンコーダ７２０によって出力され、それぞれのＮＡＬユニットが出力した時間に対応する到着タイムスタンプがエンコーダ７２０によって提供される。タイムインスタントｔ（ｉ－１）におけるレイヤ１２の画像の第１のＮＡＬユニットの符号化の後、エンコーダ７２０はレイヤ１２の画像のコンテンツの符号化を続行し、レイヤの１２の画像の第２のＮＡＬユニットを出力し、レイヤ１５の時間整合された画像の第１のＮＡＬユニットの到着タイムスタンプに続いている到着タイムスタンプが提供される。すなわち、エンコーダ７２０は、全て同じタイムインスタントに帰属しているレイヤ１２および１５の画像のＮＡＬユニットを、インターリーブ方法で出力し、データストリーム４０のＮＡＬユニットは実際に伝送される。エンコーダ７２０がインターリービングの可能性を利用することを選択した事情は、エンコーダ７２０によって、データストリーム４０内で、それぞれのインターリービングのシグナリング７２４によって指示される。エンコーダ７２０は、レイヤ１５の第１のＮＡＬユニットの出力が時間整合されたベースレイヤ画像の全てのＮＡＬユニットの出力が完了するまで延期されない非インターリーブのシナリオと比較して、タイムインスタントｔ（ｉ－１）の従属レイヤ１５の第１のＮＡＬユニットを早く出力することができるので、デコーダ図１８とエンコーダ図１９の間のエンドツーエンドの遅延は低減することができる。

【0101】

すでに上述されたように、代替の実施例によれば、非インターリービングのケースにおいて、すなわち非インターリーブの代替を指示するシグナリング７２４のケースでは、アクセスユニットの定義は同じことのままであり、すなわちアクセスユニットＡＵは特定のタイムインスタントに帰属する全てのＮＡＬユニットを集合することができる。その場合、シグナリング７２４は、各アクセスユニット内において、異なるレイヤ１２および１５に帰属するＮＡＬユニットがインターリーブされるか否かを単に指示する。

【0102】

上述のように、シグナリング７２４に従い、図１８の復号化は１つのバッファまたは２つのバッファのいずれかを用いる。インターリービングがスイッチオンされるケースでは、たとえば、レイヤ１２のＮＡＬユニットがバッファ７０２においてバッファリングされ、その一方で、レイヤ１５のＮＡＬユニットはバッファ７０４においてバッファリングされるように、デコーダ７００は、２つのバッファ７０２および７０４上にＮＡＬユニットを分布する。バッファ７０２および７０４は、アクセスユニットワイズに空にされる。インターリービングまたは非インターリービングを指示する両方のシグナリング７２４の場合には、これは正しい。

【0103】

エンコーダ７２０が各ＮＡＬユニット内で除去時間をセットする場合、復号化ユニット７０８が、レイヤ間並列処理を用いて、データストリーム４０からレイヤ１２および１５の復号化の可能性を利用するようにすることは好ましい。デコーダ７００がレイヤ間並列処理を適用しない場合であっても、エンドツーエンドの遅延は、しかしながら、すでに低減されている。

【0104】

すでに上述されたように、ＮＡＬユニットは異なるＮＡＬユニットタイプを持つことができる。各ＮＡＬユニットは、可能なタイプのセットからそれぞれのＮＡＬユニットのタイプを指示するＮＡＬユニットタイプインデックスを有することができ、各アクセスユニット内で、それぞれのアクセスユニットのＮＡＬユニットのタイプは、ＮＡＬユニットタイプの中の順序ルールを守ることができるが、その一方で単に２つの連続するアクセスユニットの間では、順序ルールは破られるので、デコーダ７００はこのルールを調査することによってアクセスユニット境界を識別することが可能である。より詳細な情報は、Ｈ．２６４標準が参照される。

【0105】

図１８および１９に関して、復号化ユニットＤＵは、同じレイヤに帰属する１つのアクセスユニット内で、連続的なＮＡＬユニットのランとして識別可能である。図１９のアクセスユニットＡＵ（ｉ－１）において、「３」および「４」を指示されたＮＡＬユニットは、たとえば、１つのＤＵを形成する。アクセスユニットＡＵ（ｉ－１）の他の復号化ユニットは、全て、単に１つのＮＡＬユニットを備える。合せて、図１９のアクセスユニットＡＵ（ｉ－１）は、例示的に、アクセスユニットＡＵ（ｉ－１）内で代替として配置される６つの復号化ユニットＤＵを備える、すなわち、それらはレイヤ１およびレイヤ０の間で交互に変わる１つのレイヤによる１つのレイヤのＮＡＬユニットのランから成る。

【0106】

第１の態様と同様に、以下において、前に記述された第２の態様は、ＨＥＶＣ拡張に組み込む方法に関して、ここで概説される。

【0107】

この前に、しかしながら、完全のために、現在のＨＥＶＣの更なる態様が記述され、それは画像間並列処理、すなわちＷＰＰ処理を可能にする。

【0108】

図２０は、ＷＰＰが、ＨＥＶＣおいて現在実施されている方法を記述する。すなわち、この記述は、上記のまたは以下に記述されるいずれかの実施形態のＷＰＰ処理のオプションとしての実施に対する基礎を形成する。

【0109】

ベースレイヤにおいて、ウェーブフロント並列処理は、符号化ツリーブロック（ＣＴＢ）行の並列処理を可能とする。予測従属性は、ＣＴＢ行を横切っても破壊されない。エントロピー符号化に関して、図２０で分かるように、ＷＰＰは、それぞれの上側ＣＴＢ行における左上ＣＴＢに対するＣＡＢＡＣ従属性を変更する。対応する右上ＣＴＢのエントロピー復号化が一旦終了すると、続く行におけるＣＴＢのエントロピー符号化を開始することができる。

【0110】

増強レイヤにおいて、対応するイメージエリアを含むＣＴＢが完全に復号化され、利用可能になるとすぐに、ＣＴＢの復号化を開始することができる。

【0111】

ＨＥＶＣおよびその拡張において、復号化ユニットの以下の定義が与えられる：

【0112】

復号化ユニット：SubPicHrdFlag が０に等しい場合のアクセスユニット、またはアクセスユニットにおける１つ以上のＶＣＬ ＮＡＬユニットおよび関連する非ＶＣＬ ＮＡＬユニットから構成されるアクセスユニットのサブセット他。

【0113】

ＨＥＶＣにおいて、好ましくは、外部手段および下位画像ＨＲＤパラメータが利用可能である場合、ＨＲＤ（ Hypothetical Reference Decoder ）は、復号化ユニットレベル（またはサブピクチャレベル）で、ＣＰＢおよびＤＰＢをオプションとして作動させることができる。

【0114】

ＨＥＶＣ仕様書［１］は、以下のように定義されたいわゆる復号化ユニットのコンセプトが記載されている。

【0115】

３．１ 復号化ユニット：SubPicHrdFlag が０に等しい場合のアクセスユニット、またはアクセスユニットにおける１つ以上のＶＣＬ ＮＡＬユニットおよび関連する非ＶＣＬ ＮＡＬユニットから構成されるアクセスユニットのサブセット他。

【0116】

３Ｄに対するＨＥＶＣ拡張［３］、マルチビュー［２］または空間的スケーラビリティ［４］（ビデオデータの付加的表現（たとえば高等忠実度、空間分解能または異なるカメラ視点）が低層レイヤに依存して、予測的レイヤ間／ビュー間符号化ツールを通して符号化される）において提供されるようなレイヤ化された符号化ビデオシーケンスにおいて、（画像エリアワイズに）関係するまたはビットストリームにおいて関係するレイヤの同じ場所に配置された復号化ユニットレイヤの関連するまたは同じ場所に配置された復号化ユニットにインターリーブすることは、エンコーダおよびデコーダ上のエンドツーエンド遅延を最小化するために有益である。

【0117】

符号化ビデオビットストリームにおいて復号化ユニットのインターリービングを可能とするため、符号化ビデオビットストリームへの特定の拘束がシグナリングされ、強制されなければならない。

【0118】

上記のインターリービングコンセプトがＨＥＶＣにおいて実施することができる方法は、詳細に記述され、以下のサブセクションで論証されている。

【0119】

ＨＥＶＣ拡張の現在の状態は、ＭＶ-ＨＥＶＣ仕様書［２］のドラフト書類から取り出される限り、それは使用されるアクセスユニットに対する定義を含み、それに従ってアクセスユニットは（特定の値 nuh＿layer＿id によって）１つの符号化画像を拘束する。１つの符号化画像は、以下で定義され、ＭＶＣにおけるビュー成分と基本的に同じである。アクセスユニットが、同じＰＯＣ値によって全てのビュー成分を含むように、定義されるべきであるかどうかは未解決の問題であった。

【0120】

ベースのＨＥＶＣ明細書［１］は次のように定義している：

【0121】

３．１ アクセスユニット：ＮＡＬユニットのセットは、復号化順序ルールに従ってお互いに関連し、復号化順序において連続的であり、正確に１つの符号化画像を含む。

【0122】

注記１－符号化画像のＶＣＬ ＮＡＬユニットを含むことに加えて、アクセスユニットは非ＶＣＬ ＮＡＬユニットを含むことができる。アクセスユニットの復号化は、常に復号化画像に結果としてなる。

【0123】

各アクセスユニットにおいて１つの符号化画像にのみ許容されるアクセスユニット（ＡＵ）の定義は、各従属ビューが別々の符号化画像と解釈され、別々のアクセスユニットに含まれることを必要とする方法で解釈されたように見える。これは、図１７において「２」で表される。

【0124】

前の標準において、「符号化画像」は、特定のタイムスタンプの画像のビュー表現の全てのレイヤを含む。

【0125】

アクセスユニットは、インターリーブすることができない。これは、各ビューが異なるアクセスユニットに含まれる場合、ベースビューの全部の画像は、従属画像の第１の復号化ユニット（ＤＵ）を復号化することができる前に、ＤＰＢにおいて受信される必要があることを意味する。

【0126】

従属レイヤ／ビューによる超低遅延動作に対して、復号化ユニットをインターリーブすることは有利である。

【0127】

図２１の実施例は、各々３つの復号化ユニットによる３つのビューを含む。それらは、左から右の順序で受信される：
各ビューが自身のアクセスユニットに含まれる場合、ビュー３の第１の復号化ユニットを復号化する最小遅延は、完全に受信ビュー１および２を含む。

【0128】

ビューがインターリーブされて送信することができる場合、図２２に示されるように、そして図１８および１９に関して既に説明されたように、最小遅延は低減することができる。

【0129】

ＨＥＶＣのスケーラブル拡張における異なるレイヤからのＮＡＬユニットのインターリービングは、以下のように達成することができる：

【0130】

レイヤまたはビュー表現に対するビットストリームインタリービング機構、およびこのビットストリームレイアウトを用いることができ、並列化技術を用いて非常に低い遅延で従属ビューを復号化することを実現することができるデコーダ。ＤＵのインターリービングは、フラグ（例えば、du＿interleaving＿enabled＿flag ）を介して制御される。

【0131】

ＨＥＶＣのスケーラブル拡張において、低遅延復号化および並列化を可能とするため、同じＡＵの異なるレイヤのＮＡＬユニットのインターリービングが必要である。それ故に、以下に沿った定義を導入することができる：

【0132】

アクセスユニット：特定の識別ルールに従ってお互いに関連するＮＡＬユニットのセットは、復号化順序において連続的で、正確に１つの符号化画像を含む。

【0133】

符号化されたレイヤ画像成分：レイヤ画像成分の全ての符号化ツリーユニットを含むレイヤ画像成分の符号化表現。

【0134】

符号化画像：１つ以上の符号化されたレイヤ画像成分を含む画像の全ての符号化ツリーユニットを含む画像の符号化表現。

【0135】

画像：画像は１つ以上のレイヤ画像成分のセットである。

【0136】

レイヤ画像成分：符号化表現がアクセスユニットにおける全てのＮＡＬユニットの中の特定のレイヤからのＮＡＬユニットから構成される、モノクロフォーマットにおけるｌｕｍａサンプルの配列またはｌｕｍａサンプルの配列および４：２：０、４：２：２および４：４：４のカラーフォーマットにおけるクロマサンプルの２つの対応する配列。

【0137】

ＮＡＬユニットは、各ＮＡＬユニットが符号化順序において前のＮＡＬユニットにおいて受信されたデータによって復号化することができる、すなわち各ＮＡＬユニットの復号化に対して復号化順序において後にＮＡＬユニットからデータを必要としないような方法で、それらの中の従属性に従ってインターリーブされる（ du＿interleaving＿enabled＿flag == 1 ）。

【0138】

ＤＵのインターリーブが適用され（ du＿interleaving＿enabled＿flag == 1 ）、ｌｕｍａおよびクロマ成分が異なるカラープレーンに分けられるとき、カラープレーンに関連付けられたそれぞれのＮＡＬユニットは、インターリーブすることができる。これらのそれぞれのＮＡＬユニット（ colour＿plane＿id の固有の値に関連する ）の各々は、後述するようにＶＣＬ ＮＡＬユニット順序を守らなければならない。カラープレーンは、アクセスユニットにおいてお互いの間に符号化従属性がないことが期待されるので、それらはノーマル順序に従う。

【0139】

ＮＡＬユニットの順序上の拘束は、ＣＴＢを単位として空間セグメント間の最悪のケースの遅延／オフセットを測定し、保証するシンタックスエレメント min＿spatial＿segment＿delay を用いて表現することができる。
シンタックスエレメントは、ＣＴＢまたはベースおよび増強レイヤの空間セグメント（たとえばＷＰＰに対するタイル、スライスまたはＣＴＢ行）の間に空間領域の従属性を記述する。シンタックスエレメントは、ＮＡＬユニットのインターリービングまたは符号化順序におけるＮＡＬユニットのシーケンシャル復号化に対しては必要でない。並列のマルチレイヤデコーダは、レイヤの並列復号化を準備するために、シンタックスエレメントを用いることができる。

【0140】

以下の拘束は、第１の態様に関して主として記述されたように、レイヤ／ビューを横切る並列化および復号化ユニットのインターリービングを可能とするエンコーダの可能性に影響を与える：

【0141】

１） サンプルおよびシンタックスエレメントの予測：
ｌｕｍａおよびクロマのリサンプリングに対する補間フィルタは、上位レイヤに対して必要なアップサンプルされたデータを生成するため、必要なデータ上の拘束を下位レイヤにセットする。たとえば、画像の空間セグメントは独立にアップサンプルすることができるので、復号化従属性は、これらのフィルタを拘束することによって低減することができる、タイル処理のための特定の拘束のシグナリングは、第１の形態に関して上述されている。

【0142】

「参照インデックスベースのスケーラブル拡張」（ＨＬＳアプローチ）に対する動きベクトル予測および、より具体的には時間的な動きベクトル予測は、より下位のレイヤにおいて必要なデータに拘束をセットし、必要なリサンプリングされた画像の動きフィールドを生成する。関連する発明およびシグナリングは、第１の形態に関して上述されている。

【0143】

２）動きベクトル：
ＳＨＶＣに対して、動き補償は、下位のレイヤによっては用いられない、すなわち、下位のレイヤが参照画像（ＨＬＳアプローチ）として使われる場合、結果として生じる動きベクトルは零ベクトルでなければならない。しかしながら、ＭＶ‐ＨＥＶＣ ０または３Ｄ‐ＨＥＶＣ ０に対して、視差ベクトルは拘束することができるが、必ずしも零ベクトルであるというわけではない。すなわち、動き補償は、ビュー間予測に対して用いることができる。それ故に、動きベクトルに対する制限は、前のＮＡＬユニットにおいて受け取られたデータのみが復号化に対して必要であることを確実にするために適用することができる。関連する発明およびシグナリングは、第１の形態に関して上述されている。

【0144】

３）タイル境界による画像分割：
異なるレイヤからのＮＡＬユニットのインターリーブによって、並列処理および低遅延が効率的に望ましい場合、増強レイヤにおける画像分割は、参照レイヤにおける分割の画像分割の従属をなさなければならない。

【0145】

ＶＣＬ ＮＡＬユニットの順序および符号化画像に対する関連に関する限り、以下は特定することができる。

【0146】

各ＶＣＬ ＮＡＬユニットは、符号化画像の一部である。

【0147】

符号化画像の符号化レイヤ画像成分内のＶＣＬ ＮＡＬユニット、すなわち同じ layer＿id＿nuh 値による符号化画像のＶＣＬ ＮＡＬユニットの順序は、以下のように拘束される：

【0148】

－ 符号化レイヤ画像成分の第１のＶＣＬ ＮＡＬユニットは、first＿slice＿segment＿in＿pic＿flag を１に等しくなる。

【0149】

－ sliceSegAddrA および sliceSegAddrB を、同じ符号化レイヤ画像成分内の２つの符号化スライスセグメントＮＡＬユニットＡおよびＢの slice＿segment＿address 値にする。以下のコンディションのいずれかが真のときに、符号化スライスセグメントＮＡＬユニットＡは符号化スライスセグメントＮＡＬユニットＢを先行する：

【0150】

－ TileId[ CtbAddrRsToTs[ sliceSegAddrA ] ] は、TileId[ CtbAddrRsToTs[ sliceSegAddrB ] ] より小さい。

【0151】

－ TileId[ CtbAddrRsToTs[ sliceSegAddrA ] ] は、TileId[ CtbAddrRsToTs[ sliceSegAddrB ] ] に等しく、CtbAddrRsToTs[ sliceSegAddrA ] は、CtbAddrRsToTs[ sliceSegAddrB ] より小さい。

【0152】

符号化画像が複数のレイヤ画像成分から構成される場合、全ての画像成分のＶＣＬ ＮＡＬユニットの順序は、以下のように拘束される：

【0153】

－ 他のレイヤ画像成分 layerPicB に対する参照として用いられる符号化レイヤ画像成分 layerPicA において、ＶＣＬ ＮＡＬ Ａを、第１のＶＣＬ ＮＡＬユニットＡとする。そのとき、ＶＣＬ ＮＡＬユニットＡは、layerPicB に帰属するいかなるＶＣＬ ＮＡＬユニットＢにも先行する。

【0154】

－ それ以外（第１のＶＣＬ ＮＡＬユニットでない）は、du＿interleaving＿enabled＿flag が０に等しい場合、ＶＣＬ ＮＡＬ Ａを、他の符号化レイヤ画像成分 layerPicB に対する参照として用いられる符号化レイヤ画像成分 layerPicA のいずれかのＶＣＬ ＮＡＬユニットとする。そのとき、ＶＣＬ ＮＡＬユニットＡは、layerPicB に帰属するいかなるＶＣＬ ＮＡＬユニットＢにも先行する。

【0155】

－ それ以外（第１のＶＣＬ ＮＡＬユニットでなく、du＿interleaving＿enabled＿flag が１に等しい）は、ctb＿based＿delay＿enabled＿flag が１に等しい、（すなわち、ビデオシーケンスにおいて、タイルまたはＷＰＰが用いられているかどうかを拘らず、ＣＴＢベースの遅延がシグナリングされる）場合、layerPicA を、他の符号化レイヤ画像成分 layerPicB に対する参照として用いられる符号化レイヤ画像成分とする。また、NALUsetA を layerPicB に帰属する連続的なスライスセグメントＮＡＬユニットのシーケンスを直接追従する layerPicA に帰属する連続的なスライスセグメントＮＡＬユニットのシーケンスとし、NALUsetB1 と NALUsetB2 を、NALUsetA を直接追従する layerPicB に帰属する連続的なスライスセグメントＮＡＬユニットのシーケンスとする。sliceSegAddrA を、NALUsetA の第１のセグメントＮＡＬユニットの slice＿segment＿address とし、sliceSegAddrB を、NALUsetB2 の第１の符号化スライスセグメントＮＡＬユニットのslice＿segment＿address とする。そのとき、以下のコンディションは真になる：

【0156】

－ NALUsetA が存在する場合、NALUsetB2 が存在する。

【0157】

－ CtbAddrRsToTs[PicWidthInCtbsYA * CtbRowBA(sliceSegAddrB-1) + CtbColBA(sliceSegAddrB-1) + min＿spatial＿segment＿delay] は、CtbAddrRsToTs[sliceSegAddrA-1] より小さいか、等しくなる。
図２３も参照されたい。

【0158】

それ以外（第１のＶＣＬ ＮＡＬユニットでなく、du＿interleaving＿enabled＿flag は１に等しく、ctb＿based＿delay＿enabled＿flag は０に等しい）は、tiles＿enabled＿flag が０に等しく、entropy＿coding＿sync＿enabled＿flag が０に等しい（すなわち、タイルもＷＰＰも、ビデオシーケンスに用いられない）場合、layerPicA を、他の符号化レイヤ画像成分 layerPicB に対して参照として用いられる符号化レイヤ画像成分とする。また、ＶＣＬ ＮＡＬユニットＢを、符号化レイヤ画像成分 layerPicB のいずれかのＶＣＬ ＮＡＬユニットとし、ＶＣＬ ＮＡＬユニットＡを、ＶＣＬ ＮＡＬユニットＡおよびＶＣＬ ＮＡＬユニットＢからの（ min＿spatial＿segment＿delay -1 ）のＶＣＬ ＮＡＬユニットがある、sliceSegAddrA に等しい slice＿segment＿address の値による layerPicA からの直前のＶＣＬ ＮＡＬユニットとする。また、ＶＣＬ ＮＡＬユニットＣを、sliceSegAddrC に等しい slice＿segment＿address の値によってＶＣＬ
ＮＡＬユニットＢを追従する符号化レイヤ画像成分 layerPicB の次のＶＣＬ ＮＡＬユニットとする。PicWidthInCtbsYA を、ＣＴＢ oflayerPicA を単位とする画像幅とする。そのとき、以下のコンディションは真になる：

【0159】

－ ＶＣＬ ＮＡＬユニットＢに先行する layerPicA から、min＿spatial＿segment＿delay のＶＣＬ ＮＡＬユニットが常にある。

【0160】

－ PicWidthInCtbsYA * CtbRowBA(sliceSegAddrC-1) + CtbColBA(sliceSegAddrC-1) は、sliceSegAddrA-1 より小さいまたは等しくなる。

【0161】

－ それ以外（第１のＶＣＬ ＮＡＬユニットでなく、du＿interleaving＿enabled＿flag は１に等しく、ctb＿based＿delay＿enabled＿flag は０に等しい）は、tiles＿enabled＿flag が０に等しく、entropy＿coding＿sync＿enabled＿flag が１に等しい（すなわち、ビデオシーケンスにおいてＷＰＰが用いられる）場合、sliceSegAddrA を、layerPicA を参照として用いる符号化レイヤ画像成分 layerPicB に帰属する sliceSegAddrB に等しい slice＿segment＿address により、スライスセグメントＶＣＬ ＮＡＬユニットＢに直接先行する符号化レイヤ画像成分 layerPicA のいずれかのスライスセグメントＶＣＬ
ＮＡＬユニットＡのslice＿segment＿address とする。また、PicWidthInCtbsYA を、layerPicA のＣＴＢを単位とする画像幅とする。そのとき、以下のコンディションは真となる：

【0162】

－ ( CtbRowBA(sliceSegAddrB) - Floor( (sliceSegAddrA) / PicWidthInCtbsYA) + 1) は、min＿spatial＿segment＿delay に等しいまたは大きい。

【0163】

それ以外（第１のＶＣＬ ＮＡＬユニットでなく、du＿interleaving＿enabled＿flag は１に等しく、ctb＿based＿delay＿enabled＿flag は０に等しい）は、tiles＿enabled＿flag が１に等しく、entropy＿coding＿sync＿enabled＿flag が０に等しい（すなわち、タイルがビデオシーケンスにおいて用いられる）場合、sliceSegAddrA を、符号化レイヤ画像成分 layerPicA のいずれかのスライスセグメントＶＣＬ ＮＡＬユニットＡのslice＿segment＿address とし、スライスセグメントＶＣＬ ＮＡＬユニットＢを、sliceSegAddrB に等しい slice＿segment＿address によって参照として layerPicA を用いる、符号化レイヤ画像成分 layerPicB に帰属する第１の次のＶＣＬ ＮＡＬユニットとする。また、PicWidthInCtbsYA を、layerPicA のＣＴＢを単位とする画像幅とする。そのとき、以下のコンディションは真となる：

【0164】

－ TileId[ CtbAddrRsToTs[ PicWidthInCtbsYA * CtbRowBA(sliceSegAddrB-1) + CtbColBA(sliceSegAddrB-1) ] ] - TileId[ CtbAddrRsToTs[ sliceSegAddrA-1] ] は、 min＿spatial＿segment＿delay と等しいまたは大きくなる。

【0165】

シグナリング７２４は、図２４に図示されたようにＶＰＳ内に配置することができる、ここで：

【0166】

du＿interleaving＿enabled＿flag が１に等しいとき、異なるレイヤに対応するフレームおよびＶＣＬ ＮＡＬユニットに対して、全ての符号化レイヤ画像成分から構成される単一の関連する符号化画像（すなわち、単一の関連ＡＵ）を有するフレームは、インターリーブすることができることをdu＿interleaving＿enabled＿flag は特定する。u＿interleaving＿enabled＿flag が０に等しいとき、複数の関連する符号化画像（すなわち一つ以上の関連するＡＵ）および異なる符号化例や画像成分のＶＣＬ ＮＡＬユニットを有することができるフレームは、インターリーブされない。

【0167】

上記の議論を完了させるため、デコーダ７００に関連する仮定的参照デコーダは、図１８の実施形態によるアラインメントにおいて、シグナリング７２４の設定に従って、バッファ７０２および７０４の１つまたは２つのバッファによって動作する、すなわちシグナリング７２４に従ってこれらのオプションの間をスイッチすることを採用することができる。

【0168】

以下において、本願の他の態様が記述され、それは再び、形態１、形態２または双方とも組み合わせることができる。本願の第３の態様は、多くのアプリケーション、例えばビューの、に対するスケーラビリティシグナリングの拡張に関する。

【0169】

以下に提案される記載の理解の容易のため、存在するスケーラビリティシグナリングのコンセプトの概要が提供される。

【0170】

大部分の技術水準の３Ｄビデオアプリケーションまたは配備は、２つのカメラビューまたはより多いビュー（＞２）によるマルチビューの各々に対するそれぞれの距離画像によるまたはよらない、それぞれの距離画像によるまたはよらない、立体視のコンテンツを特徴とする。

【0171】

高水準ビデオ符号化（ＨＥＶＣ）標準［１］およびその３Ｄおよびマルチビュービデオ［２］［３］に対する拡張は、図２５のシンタックステーブルにおいて与えられる各ＮＡＬユニットのヘッダにおける６ビットのレイヤ識別子（ uh＿layer＿id ）による最高６４枚の異なるレイヤを表現することができるネットワーク・アブストラクション・レイヤ（ＮＡＬ）に関するスケーラビリティシグナリングを特徴づけている。

【0172】

レイヤ識別子の各値は、使用におけるスケーラビリティディメンションに従い、例えば、ビデオパラメータセット拡張を通して、スケーラブル識別子変数（例えば、DependencyID、ViewID、その他）のセットに変換することができ、それは、レイヤ識別子が同様に距離画像を指示するために用いられる場合に、最高６４の専用ビューがＮＡＬレイヤまたは３２の専用ビュー上に指示されることを可能にする。

【0173】

しかしながら、例えば、参考文献［５］［６］［７］において提供されるような多数のカメラによるマルチカメラアレイにおいてまたは多数の視点を必要とするホログラフィックディスプレイにおいて、実質的により大きな数のビューがビデオビットストリームに符号化され、転送され、復号化されてディスプレイされることを必要とするアプリケーションも存在する。以下のセクションは、拡張に対して、ＨＥＶＣ高水準シンタックスの上述された欠点に対処する２つの発明を記述する。

【0174】

ＮＡＬユニットヘッダにおける サイズnuh＿layer＿id フィールドを簡単に拡張することは、問題の有用な解法とは思われない。ヘッダは固定長であることが期待され、それは簡単なアクセスに対して、ルーチンおよび抽出のようなビットストリーム上の動作を実行する非常に単純な（ローコストの）デバイスにおいて必要とされる。これは、非常に少ないビューが使われる場合であっても、全てのケースに対して、追加ビット（またはバイト）が付加されなければならないことを意味する。

【0175】

また、標準の第１のバージョンの仕上げの後、ＮＡＬユニットヘッダを変更することは、もはや可能でない。

【0176】

以下の記載は、上述された要求仕様を満たすために、スケーラビリティシグナリング能力を拡張するＨＥＶＣデコーダまたは中間デバイスの拡張機構を記述する。活性化および拡張データは、ＨＥＶＣ高水準ルシンタックスにおいてシグナリングすることができる。

【0177】

以下は、特に、レイヤ識別子拡張機構（次のセクションで記述されるように）がビデオビットストリームにおいて使用可能とされることを指示するシグナリングを記述する。

【0178】

第１および第２の態様に対する以外に、以下の実施形態の一般化を記述することで、ＨＥＶＣフレームワークにおける第３のコンセプトの可能な実施が、最初に記述される。
コンセプトは、同じアクセスユニット内で、同じ現存するレイヤ識別子（ nuh＿layer＿id ）による多重のビュー成分の出現を可能とする。付加的な識別子拡張が、これらのビュー成分間を区別するために用いられる。この拡張は、ＮＡＬユニットヘッダにおいて符号化されない。このように、それはＮＡＬユニットヘッダにおいてほど容易にアクセスすることはできないが、より多くのビューによる新規な用途ケースを依然として可能とする。特にビュークラスタリング（下記の説明を参照）については、一緒に帰属するビューのグループの抽出に対して、古い摘出機構がいかなる修正もなしに依然として用いることができる。

【0179】

レイヤ識別子値の現存するレンジを拡張するために、本発明は、以下の機構を記述する：

【0180】

ａ．現存するレイヤ識別子の予め定められた値が、特別な値（いわゆる「エスケープコード」）として用いられ、代替の導出プロセスを用いて実際の値が決定されることを指示する（特定の実施形態において）：ＮＡＬユニットヘッダにおけるシンタックスエレメント nuh＿layer＿id の値（例えば、レイヤ識別子の最高値）が用いられる。
ｂ．高水準レベルシンタックス構造における（例えば、本発明の以下の実施形態において与えられるようなスライスヘッダシンタックスにおけるまたはビデオ／シーケンス／画像パラメータセットの拡張における）フラグまたはインデックスまたはビット長の指示は、他のシンタックス構造による実在するレイヤ識別子値の各値の組み合わせを可能とする。

【0181】

拡張機構の活性化は、以下のように実施することができる。

【0182】

ａ）に対して、明確な活性化シグナリングは必要でない、すなわち予約されたエスケープコードは、拡張（ａ１）の使用をシグナリングするために常に用いることができる。しかし、これは、１（エスケープコードの値）による拡張を用いることのない可能なレイヤ／ビューの数を低減させる。このように、下記のスイッチングパラメータは、両方の変形例（ａ２）に対して用いることができる。

【0183】

拡張機構は、ビットストリーム内で、ビデオシーケンスの全部のビットストリーム、ビデオシーケンスまたはビデオシーケンスの部分を通じて持続的である１つ以上のシンタックスエレメントを用いて、使用可能または使用不可にすることができる。

【0184】

実在するレイヤ識別子を表す変数LayerId によって、拡張機能を使用可能とする本発明の特定の実施形態は：
変形例Ｉ）変形例Ｉは、図２６に図示される。ここで、

【0185】

layer＿id＿ext＿flag は、付加的な LayerId 値の使用を可能にする。

【0186】

変形例 II ）変形例 II は、図２７に図示される。ここで、

【0187】

１に等しい layer＿id＿mode＿idc は、LayerId の値の範囲がエスケープコードを用いることによって拡張されることを指示する。２に等しい layer＿id＿mode＿idc は、LayerId の値の範囲がオフセット値によって拡張されることを指示する。０に等しい layer＿id＿mode＿idc は、いかなる拡張機構も LayerId に対して用いられないことを指示する。

【0188】

注：モードに対する値の異なるアサインメントが可能である。

【0189】

変形例 III ）変形例 III は、図２８に図示される。ここで、

【0190】

layer＿id＿ext＿len は、LayerId レンジを拡張するために用いられるビットの数を指示する。

【0191】

上記のシンタックスエレメントは、対応するＮＡＬユニットまたはスライスデータのレイヤ識別子の指示に対するレイヤ識別子拡張機構の使用に対するインジケータとして役立つ。

【0192】

下記の説明において、変数 LayerIdExtEnabled は、拡張機構が使用可能であったことを示す論理インジケータとして用いられる。変数は、記述において、より簡単な参照に対して用いられる。変数名の実施例および本発明の実施形態は、異なる名前または対応するシンタックスエレメントを直接用いることができる。変数 LayerIdExtEnabled は、上記のケースに従って、以下のように導き出される：

【0193】

ａ１）に対して、レイヤ識別子シンタックスエレメントの予め定められた値のみがレイヤ識別拡張機構を使用可能にするために用いられる場合、以下が適用される：

【0194】

if ( nuh＿layer＿id == predetermined value )
LayerIdExtEnabled = true
else
LayerIdExtEnabled = false

【0195】

変形例Ｉの場合、ケースａ２）およびｂ）に対して、すなわち、フラグ（例えば、layer＿id＿ext＿enable＿flag ）が、レイヤ識別子拡張機構を使用可能にするために用いられる場合、以下が適用される：

【0196】

LayerIdExtEnabled = layer＿id＿ext＿enable＿flag

【0197】

変形例 II の場合、ケースａ２）およびｂ）に対して、すなわち、インデックス（例えば、layer＿id＿mode＿idc ）がレイヤ識別子拡張機構を使用可能にするために用いられる場合、以下が適用される：

【0198】

if ( layer＿id＿mode＿idc == predetermined value )
LayerIdExtEnabled = true
else
LayerIdExtEnabled = false

【0199】

変形例 III の場合、ケースａ２）およびｂ）に対して、すなわち、ビット長指示（例えば、layer＿id＿ext＿len ）がレイヤ識別子拡張機構を使用可能にするために用いられる場合、以下が適用される：

【0200】

if ( layer＿id＿ext＿len > 0 )
LayerIdExtEnabled = true
else
LayerIdExtEnabled = false

【0201】

ケースａ２）に対して、予め定められた値が、使用可能にするシンタックスエレメントと組み合わせて用いられる場合、以下が適用される：

【0202】

LayerIdExtEnabled &= ( nuh＿layer＿id == predetermined value )

【0203】

レイヤ識別子拡張は、以下のようにシグナリングすることができる。

【0204】

拡張機構が使用可能である場合（例えば、前のセクションで記述されたようなシグナリングを通して）、予め定められたまたはシグナリングされたビットの数（ layer＿id＿ext＿len ）が、実際の LayerId 値を決定するために用いられる。ＶＣＬ ＮＡＬユニットに対して、スライスヘッダシンタックスにおいて（例えば、現存する拡張を用いることによって）、または、ビデオビットストリームにおける位置によってまたは対応するスライスデータに関連するインデックスによって、ＮＡＬユニットヘッダにおけるレイヤ識別子のシグナリングレンジを拡張するために用いられるＳＥＩメッセージにおいて、追加ビットを含めることができる。

【0205】

非ＶＣＬ ＮＡＬユニット（ＶＰＳ、ＳＰＳ、ＰＰＳ、ＳＥＩメッセージ）に対して、付加的な識別子が、特定の拡張に対してまたは関連するＳＥＩメッセージよっても、加えることができる。
更なる記述において、特定のシンタックスエレメントは、ビットストリームシンタックスにおけるその位置に拘らず、layer＿id＿ext と称される。名前が、実施例として用いられる。以下のシンタックステーブルおよびセマンティクスは、可能な実施形態の実施例を与える。

【0206】

スライスヘッダにおけるレイヤ識別子拡張のシグナリングは、図２９に例証される。

【0207】

スライスヘッダ拡張におけるレイヤ識別子拡張の代替シグナリングは、図３０に示される。

【0208】

ビデオパラメータセット（ＶＰＳ）に対するシグナリングの実施例は、図３１に示される。

【0209】

類似した拡張が、ＳＰＳ、ＰＰＳおよびＳＥＩメッセージに対して存在する。付加的なシンタックスエレメントは、類似した方法でこれらの拡張に加えることができる。

【0210】

関連するＳＥＩメッセージ（例えば、レイヤＩＤ拡張ＳＥＩメッセージ）におけるレイヤ識別子のシグナリングは、図３２に図示される。

【0211】

ＳＥＩメッセージのスコープは、ビットストリームにおけるその位置に基づいて決定することができる。本発明の特定の実施形態において、レイヤＩＤ拡張ＳＥＩメッセージが layer＿id＿ext の値によって関連付けされた後と、新しいアクセスユニットまたは新しいレイヤＩＤ拡張ＳＥＩメッセージの開始までの間、全てのＮＡＬユニットは受け取られる。

【0212】

その位置に従属して、付加的なシンタックスエレメントは、固定（ここで、ｕ（ｖ）と示される）または可変長（ｕｅ（ｖ））の符号によって符号化することができる。

【0213】

特定のＮＡＬユニットおよび／またはスライスデータに対するレイヤ識別子は、ＮＡＬユニットヘッダにおけるレイヤ識別子（ nuh＿layer＿id ）によって提供される数学的に組み合わされた情報およびレイヤ識別子拡張機構（ LayerIdExtEnabled ）の活性化に従うレイヤ識別子拡張機構（ layer＿id＿ext ）によって導き出される。

【0214】

特定の実施形態は、最上位ビットとしての現存するレイヤ識別子（ nuh＿layer＿id ）および以下のように最下位ビットとしての拡張情報を用いて、ここで LayerId と称されたレイヤ識別子を導き出す：

【0215】

if ( LayerIdExtEnabled == true)
LayerId = (nuh＿layer＿id << layer＿id＿ext＿len) + layer＿id＿ext
else
LayerId = nuh＿layer＿id

【0216】

このシグナリングスキームは、nuh＿layer＿id が異なる値を表すことができるケースｂ）において、小さいレンジの layer＿id＿ext 値によって、より異なる LayerId値 をシグナリングすることを可能とする。それは、特定のビューのクラスタリングも可能とする。すなわち、一緒に近くに配置されるビューはそれらが一緒に帰属することを指示するため、nuh＿layer＿id の同じ値を用いることができる。図３３を参照されたい。

【0217】

図３３は、クラスタ（すなわち、物理的に近いカメラのビューのグループ）によって関連する全てのＮＡＬユニットが nuh＿layer＿id の同じ値および layer＿id＿ext の固有の値を持つ、ビュークラスタの構成を図示する。あるいは、シンタックスエレメント layer＿id＿ext がクラスタを構成し、nuh＿layer＿id がビューを識別するために役立つことができる本発明の他の実施形態において用いることができる。

【0218】

本発明の他の実施形態は、以下のように、最下位ビットとして現存するレイヤ識別子（ nuh＿layer＿id ）を、最上位ビットとして拡張情報を用いることによって、ここでは LayerId と称されるレイヤ識別子を導き出す：
if ( LayerIdExtEnabled == true)
LayerId = (layer＿id＿ext << 6) + nuh＿layer＿id
else
LayerId = nuh＿layer＿id

【0219】

このシグナリングスキームは、特定のビューのクラスタリングによってシグナリングを可能とする、すなわちお互いから物理的に離れて配置されたカメラのビューは、それらが異なるクラスタ（すなわちこの実施形態における layer＿id＿ext の値）における nuh＿layer＿id の同じ値によって、カメラのビューに関して同じ予測従属性を利用することを指示するため、nuh＿layer＿id の同じ値を用いることができる。

【0220】

他の実施形態は、LayerId のレンジ（現存するレイヤ識別子レンジ（ nuh＿layer＿id ）の最大許容値を参照する maxNuhLayerId ）を拡張する付加的なスキームを用いる：

【0221】

if ( LayerIdExtEnabled == true)
LayerId = maxNuhLayerId + layer＿id＿ext
else
LayerId = nuh＿layer＿id

【0222】

このシグナリングスキームは、nuh＿layer＿id の予め定められた値が拡張を可能にするために用いられるケースａ）において特に有用である。たとえば、maxNuhLayerId の値は、LayerId 値のレンジのギャップレスの拡張を可能とするために、予め定められたエスケープコードとして用いることができる。

【0223】

［３］の初期のドラフトバージョンとして記述されたＨＥＶＣの３Ｄビデオ符号化拡張のテストモデルのドラフト文脈において、考えられる実施形態が以下のパラグラフにおいて記述される。

【0224】

［３］の初期バージョンのセクションＧ．３．５において、ビュー成分は以下の通りに定められている。

【0225】

ビュー成分：シングルアクセスユニットＡにおけるビュー成分の符号化表現は、奥行きビュー成分およびテクスチャビュー成分を含むことができる。

【0226】

奥行きおよびテクスチャのビュー成分のマッピングは、現存するレイヤ識別子（ nuh＿layer＿id ）に基づいて、ＶＰＳ拡張シンタックスにおいて定められる。本発明は、追加レイヤ識別子値の範囲をマップするためにフレキシビリティを加える。例示的なシンタックスは、図３４に示される。現存するシンタックスに対する変更は、シェーディングを用いて強調される。

【0227】

レイヤ識別子拡張が用いられる場合は、VpsMaxLayerId は vps＿max＿layer＿id に等しく設定され、それ以外は、vps＿max＿ext＿layer＿id に等しく設定される。

【0228】

レイヤ識別子拡張が用いられる場合は、VpsMaxNumLayers は、拡張を用いて符号化することができる最大レイヤ数にセットされ（定義済みの数のビットによってまたは layer＿id＿ext＿len に基づいてのいずれか）、それ以外は、VpsMaxNumLayers は、vps＿max＿layers＿minus1 + 1 にセットされる。

【0229】

vps＿max＿ext＿layer＿id は、最大の使用済み LayerId 値である。

【0230】

layer＿id＿in＿nalu[ i ] は、ｉ番目のレイヤのＶＣＬ ＮＡＬユニットに関連付けられた LayerId 値を特定する。
０ ～ VpsMaxNumLayers - 1 のレンジにおけるｉに対して、包括的に、存在しないときは、layer＿id＿in＿nalu[ i ] の値はｉに等しいと推定される。

【0231】

ｉが０より大きいとき、layer＿id＿in＿nalu[ i ] は layer＿id＿in＿nalu[ i - 1 ] より大きくなる。
splitting＿flag が１に等しいとき、セグメントにおけるビットの合計数が６より小さい場合は、layer＿id＿in＿nuh のＭＳＢは０とする必要がある。

【0232】

０ ～ vps＿max＿layers＿minus1 のレンジにおけるｉに対して、包括的に、変数LayerIdInVps[ layer＿id＿in＿nalu[ i ] ] は、ｉに等しくセットされる。

【0233】

dimension＿id[ i ][ j ] は、ｉ番目のレイヤのｊ番目の現在のスケーラビリティディメンションタイプの識別子を特定する。存在しないとき、dimension＿id[ i ][ j ] の値は０に等しいと推測される。dimension＿id[ i ][ j ] の表現に対して用いられるビットの数は、dimension＿id＿len＿minus1[ j ] + 1 ビットである。splitting＿flag が１に等しいとき、それは、dimension＿id[ i ][ j ] が( ( layer＿id＿in＿nalu[ i ] & ( (1 << dimBitOffset[ j + 1 ] ) - 1) ) >> dimBitOffset[ j ] )に等しくなるビットストリーム一致の必要条件である。

【0234】

ｉ番目のレイヤの smIdx 番目のスケーラビリティディメンションタイプの識別子を特定する変数 ScalabilityId[ i ][ smIdx ] は、ｉ番目のレイヤのビュー識別子を特定する変数 ViewId[ layer＿id＿in＿nuh[ i ] ] およびｉ番目のレイヤの空間／ＳＮＲスケーラビリティ識別子を特定するDependencyId[ layer＿id＿in＿nalu[ i ] ] は、以下のように導き出される：

【0235】

for (i = 0; i < VpsMaxNumLayers; i++) [
for( smIdx= 0, j =0; smIdx< 16; smIdx ++ )
if( ( i ! = 0 ) && scalability＿mask[ smIdx ] )
ScalabilityId[ i ][ smIdx ] = dimension＿id[ i ][ j++ ]
else
ScalabilityId[ i ][ smIdx ] = 0
ViewId[ layer＿id＿in＿nalu[ i ] ] = ScalabilityId[ i ][ 0 ]
DependencyId [ layer＿id＿in＿nalu[ i ] ] = ScalabilityId[ i ][ 1 ]
]

【0236】

初期バージョン［３］のセクション２において、特定のカメラの対応する奥行きビューおよびテクスチャ成分は、他の奥行きビューおよびテクスチャから、初期バージョン［３］のセクション ＮＡＬユニットヘッダセマンティクスにおいて、以下のように導き出され、それらの拡張性識別ビュー順序インデックス（ ViewIdx ）および奥行きフラグ（ DepthFlag ）によって区別することができることが記述されている。

【0237】

ViewIdx = layer＿id >> 1
DepthFlag = layer＿id % 2

【0238】

それ故に、個々のビュー成分（すなわち特定のカメラのテクスチャおよび奥行きビュー成分）は、たとえば 、０の初期のバージョンのセクションＧ．８における復号化プロセスにおいて、変数ViewIdx の値を介して、区別可能な layer＿id の個々の値によって、ＮＡＬユニットへパケット化されなければならない。

【0239】

ちょうど概説されたコンセプトは、異なるビューに対して、ＮＡＬユニットヘッダ（ nuh＿layer＿id ）におけるレイヤ識別子の同じ値を用いることを可能とする。このように、識別子ViewIdx および DepthFlag の導出は、以下のように前に導き出された拡張ビュー識別子を用いるのに適合することを必要とする：

【0240】

ViewIdx = LayerId >> 1
DepthFlag = LayerId % 2

【0241】

第３の形態の一般化した実施形態は、図３５に関して後述され、それはマルチレイヤビデオ信号を復号化するように構成されたデコーダ８００を示す。デコーダは、図２、９または１８に関して上記概説されたように具現化することができる。すなわち、特定の実施形態による、図３５のデコーダ８００のより詳細な説明に対する実施例は、上記概説されたそれらの態様および実施形態を用いて得ることができる。上記の概説された態様とそれらの実施形態および図３５の実施形態の間の考えられるオーバーラップを図示するために、たとえば、同じ参照符号が、図３５におけるマルチレイヤビデオ信号４０に対して用いられている。マルチレイヤビデオ信号４０の多重レイヤは何ができるかに関しては、参照は、第２の態様に関して提案された記述が参照される。

【0242】

図３５に示されるように、マルチレイヤビデオ信号は、パケット８０４のシーケンスからなり、その各々は、上記の概説された特定のＨＥＶＣ拡張実施例においてシンタックスエレメントnuh＿layer＿id を用いて具現化された、レイヤ識別シンタックスエレメント８０６を備える。デコーダ８００は、更に下で概説されるように、それ自身レイヤ識別シンタックスエレメントを部分的に含むことができるマルチレイヤビデオ信号４０におけるレイヤ識別拡張機構のシグナリングに応答するように構成される。レイヤ識別拡張機構のシグナリング８０８は、シグナリング８０８に応答して、パケット８０４の中の予め定められたパケットに対して、矢印８１９を用いてエンタリングデコーダとして図示されるデコーダ８００によって検出される。レイヤ識別拡張機構のシグナリング８０８を介して制御されるデコーダ８００のスイッチ８１２を用いて図示されるように、デコーダ８００は、予め定められたパケット８１０に対して、８１４において、マルチレイヤデータストリーム４０からレイヤ識別拡張を読み込み、このレイヤ識別拡張を用いて、現在のパケット８１０のレイヤ識別インデックスを決定８１６する。シグナリング８０８がレイヤ識別拡張機構の非活性化をシグナリングする場合、レイヤ識別拡張は８１４において読み込み、８１８で図示されるように、現在のパケット８１０自体によって備えることができるか、または、現在のパケット８１０によって関連付け可能な方法で、データストリーム４０内で他の場所に位置決めすることができる。このように、レイヤ識別拡張機構のシグナリング８０８がレイヤ識別拡張機構の活性化をシグナリングする場合、デコーダ８００は、８１４および８１６に従って、現在のパケット８１０に対してレイヤ識別インデックスを決定する。しかしながら、レイヤ識別拡張機構のシグナリング８０８がレイヤ識別拡張機構の非活性化をシグナリングする場合、デコーダ８００は、単に現在のパケット８１０のレイヤ識別シンタックスエレメント８０６から予め定められたパケットのレイヤ識別インデックスを決定８２０する。そのケースにおいて、レイヤ識別拡張８１８、すなわち信号４０内のその存在は不必要である、すなわちそれは存在しない。

【0243】

実施形態において、レイヤ識別シンタックスエレメント８０６は、パケット検出においてレイヤ識別拡張機構のシグナリング８０８に寄与する：現在のパケット８１０のような各パケットが関係する限り、レイヤ識別拡張機構のシグナリング８０８がレイヤ識別拡張機構の活性化または非活性化をシグナリングするかどうかは、デコーダ８００によって、少なくとも部分的に、それぞれのパケット８１０のレイヤ識別シンタックスエレメント８０６がエスケープ値を仮定しているか否かに従って決定される。たとえば、特定のパラメータセット８２４内で、データストリーム４０によって備えられる高水準シンタックスエレメント８２２は、むしろ肉眼的に、またはより高いスコープに関して、レイヤ識別拡張機構のシグナリング８０８に、すなわちレイヤ識別拡張機構の活性化または非活性化をシグナリングすることに寄与することができる。特に、デコーダ８００は、レイヤ識別拡張機構のシグナリング８０８が、高水準シンタックスエレメント８２２に従い、主として予め定められたパケット８１０に対してレイヤ識別拡張機構の活性化または非活性化をシグナリングするかどうか決定するように構成することができる。高水準シンタックスエレメントが第１の状態をとる場合、レイヤ識別拡張機構は、非活性化するシグナリング８０８によってシグナリングされる。上記の概説された実施形態を参照すると、これは layer＿id＿ext＿flag = 0、layer＿id＿mode＿idc = 0または layer＿id＿ext＿len = 0 に関する。言い換えれば、上記の特定のシンタックスの実施例において、それぞれ、layer＿id＿ext＿flag 、layer＿id＿ext＿idc および layer＿id＿ext＿len は、高水準シンタックスエレメント８２２に対する実施例を表している。

【0244】

パケット８１０のような特定のパケットに関して、これは、高水準シンタックスエレメント８２２が第１の状態と異なる状態をとり、そのパケット８１０のレイヤ識別シンタックスエレメント８０６がエスケープ値をとる場合に、パケット８１０に対して、レベル識別拡張機構のシグナリング８０８がレベル識別拡張機構の活性化をシグナリングすることをデコーダ８００が決定することを意味する。しかしながら、パケット８１０に対して有効な高水準シンタックスエレメント８２２が第１の状態をとるまたはそのパケット８１０のレイヤ識別エレメント８０６がエスケープ値と異なる値をとる場合に、デコーダ８００はシグナリング８０８によってシグナリングされるレイヤ識別拡張機構の非活性化を決定する。

【0245】

単に２つの可能な状態だけを有するよりむしろ、上記シンタックス実施例で概説されたように、高水準シンタックスエレメント８２２は、非活性化状態、すなわち第１の状態を越えて、高水準シンタックスエレメント８２４がとることができる複数の更なる状態を備える。これらの可能な更なる状態に従い、決定８１６は、破線８２４を用いて指示されたように、変化することができる。たとえば、上記シンタックス実施例において、layer＿id＿mode＿idc = 2 のケースは、決定８１６が、パケット８１０のレイヤ識別インデックスを得るために、デコーダ８００がパケット８１０のレイヤ識別シンタックスエレメント８０６を表すデジットとレイヤ識別拡張を表すデジットを連結することにおそらく結果としてなることが示されている。それとは異なり、layer＿id＿len≠0 の実施例ケースは、決定８１６が以下を実行しているデコーダ８００におそらく結果としてなることが示されている：デコーダ８００は、予め定められたパケットのレベル識別インデックスを得るために、高水準シンタックスエレメントを用いて、パケット８１０によって関連付けられたレイヤ識別拡張８１８の長さｎを決定し、パケット８１０のレイヤ識別シンタックスエレメント８０６を表すデジットとパケット８１０のレベル識別拡張線８１８を表すｎデジットを連結する。更には、決定８１６は、予め定められｔパケット８１０のレイヤ識別インデックスを得るために、たとえば、レイヤ識別シンタックスエレメント８０６の最大限表すことができる状態（エスケープ値より小さい）を超える数に対応することができる予め定められた値に対して、パケット８１０によって関連付けられたレベル識別拡張８１８を加えることを含むことができる。

【0246】

しかしながら、図３４において８０８’を用いて指示されたように、シンタックスエレメント８０６の全部の表すことができる値／状態が残り、それらのいずれもエスケープコードとして確保されないように、パケット８１０のレイヤ識別シンタックスエレメント８０６を、レイヤ識別拡張機構のシグナリング８０８に寄与することから除外することも可能である。そのケースでは、シグナリング８０８’は、各パケット８１０に対して、レイヤ識別拡張８１８が存在するか否か、および、したがってレイヤ識別インデックスの決定が８１４および８１６または８２０に追従するかどうかを、デコーダ８００に指示する。

【0247】

図３５のデコーダにフィットするエンコーダは、したがって、データストリームを単純に形成する。エンコーダは、たとえば、データストリームに符号化されるレイヤ数に従って、拡張機構を用いるか否かを決定する。

【0248】

本願の第４の態様は、ディメンション従属する直接従属性シグナリングに関する。

【0249】

現在のＨＥＶＣ拡張（［２］、［３］、［４］）において、符号化レイヤは、データの予測に対して、０以上の参照符号化レイヤを利用することができる。各符号化レイヤは、固有の nuh＿layer＿id 値によって識別され、それは layerIdInVps 値に全単射的にマッピングすることができる。layerIdInVps 値は連続的であり、Ａに等しい layerIdinVps が、layerIdInVps Ｂによって参照されるとき、ビットストリーム適合性の必要条件は、ＡがＢより小さいことである。

【0250】

ビットストリーム内の各符号化レイヤに対して、参照符号化レイヤは、ビデオパラメータセットにおいてシグナリングされる。それ故に、バイナリマスクは、各符号化レイヤに対して伝送される。ｂの layerIdinVps 値による符号化レイヤに対して、マスク（ direct＿dependency＿flag[ b ] として表される）は、ｂ－１ビットから構成される。ｘに等しい layerIdinVps によるレイヤが、ｂに等しい layerIdinVps によるレイヤの参照レイヤであるとき、バイナリマスク（ direct＿dependency＿flag[ b ][ x ] として表された）における第ｘ番目のビットは、１に等しい。それ以外に、ｘに等しいlayerIdinVpsによるレイヤが、Ｂに等しい layerIdinVps によるレイヤの参照レイヤでないとき、direct＿dependency＿flag[ b ][ x ] の値は０に等しい。

【0251】

全ての direct＿dependency＿flags を解析した後に、各符号化レイヤに対して、direct＿dependency＿flags によって特定されたように、全ての参照レイヤのnuh＿layer＿id 値を含むリストがクリエイトされる。

【0252】

さらに、各 layerIdinVps 値を、Ｔディメンションのスケーラビリティ空間における位置にマッピングすることを可能にする情報が、ＶＰＳにおいてシグナリングされる。各ディメンションｔは、スケーラビリティのタイプを表し、それは例えばビュースケーラビリティ、空間スケーラビリティまたは距離画像の指示とすることができる。

【0253】

各可能な従属性に対して１ビットをシグナリングするによって、現在の設計は最大限のフレキシビリティを提供する。しかしながら、このフレキシビリティはいくつかの欠点を伴う：

【0254】

１．これは、各スケーラビリティディメンションに対して特定の従属構造が利用される一般的用法のケースである。さらに、直接のディメンション間の従属性は、一般的でなく、却下されるであろう。一般的用法のレイヤセットアップに対する実施例は、図３６に表される。ここで、ディメンション０は、一種の階層的予測構造を利用する、ビュースケーラビリティディメンションとされるであろう。ディメンション１は、ＩＰ構造を用いた空間スケーラビリティディメンションとされるであろう。セットアップに関係する direct＿dependency＿flags は、図３７に示される。
現在の解決法の欠点は、これは direct＿dependency＿flags のアルゴリズム的に複雑な解析を必要とするので、現在のＶＰＳ設計からこの種のディメンション従属する従属性を識別することが直接的でないということである。
２．１つのスケーラブルディメンションタイプのみが利用されるときでさえ、レイヤのサブセットに対して同一の構造が一般的に用いられる。例えばビュースケーラビリティのみのケースに対して、ビューは水平および垂直のカメラ位置によってスパンされる空間にマッピングされるであろう。この種のシナリオに対する実施例は、図３６に表され、ここでディメンション０および１は水平および垂直のカメラ位置のディメンションと解釈される。各カメラ位置のディメンションに対して１つの予測構造を用いるのが一般的な慣習であるが、現在のＶＰＳ設計はこれから結果として生じる冗長性を利用することができない。さらに、現在のＶＰＳ設計において、従属性がディメンション従属であるという直接の指示はない。
３．direct＿dependency＿flags の数は、ビットストリームにおけるレイヤの数の自乗に比例し、それゆえに、６４レイヤによる現在の最悪のケースは、約６４＊６３／２＝２０１６ビットが必要とされる。さらに、ビットストリームにおいて最大数のレイヤが拡張されるとき、これはドラスティックに増加するビットの数に結果としてなる。

【0255】

上述された欠点は、Ｔディメンションの従属性空間の各ディメンションｔに対して、従属性の明確なシグナリングをすることによって解決することができる。

【0256】

ディメンション従属の直接従属性シグナリングは、以下の利益を提供する：
１．各従属性ディメンションに対する従属性は、ビットストリームにおいて直接的に利用可能であり、direct＿dependency＿flags の複雑な解析は必要でない。
２．従属性のシグナリングに対して必要なビット数は、低減することができる。

【0257】

実施形態において、従属性空間は、現在のＭＶ－およびスケーラブルドラフト［２］において記述されているように、例えばスケーラビリティ空間と同じとすることができる。他の実施形態において、従属性空間は、明確にシグナリングすることができ、例えばカメラ位置によってスパンされる空間とすることもできる。

【0258】

ディメンション従属の従属性シグナリングに対する実施例は、図３８に与えられる。ディメンション間の従属性は、２値マスクから直接的に導き出すことができ、必要なビットの量は低減されることが分かる。

【0259】

以下において、各 layerIdInVps 値は、ディメンション 0,1,2,….,(T-1) によるＴ次元の従属性空間に、全単射的にマッピングされると仮定される。それゆえに、各レイヤは、対応するディメンション 0,1,2,…,(T-1) において位置を特定する、d₀,d₁,d₂,…,d_T-1 による関連ベクトル (d₀,d₁,d₂,…,d_T-1 )' を有する。

【0260】

基本的なアイデアは、レイヤ従属性のディメンション従属シグナリングである。それゆえに、ディメンションｔにおける各ディメンション t ∈ [ 0,1 ,2 … (T-1) ] および各位置 d_t に対して、ディメンションｔにおける参照位置セット Ref( d_t ) がシグナリングされる。以下に記述されるように、参照位置セットは、異なるレイヤ間の直接従属性を決定するために利用される：

【0261】

ディメンションｔにおける位置 d_t およびディメンションｘにおける位置 d_x を有する x ∈[ 0,1,2 … (T-1)] / [ t ] によるレイヤは、d_t,RefがRef( d_t ) におけるエレメントであるとき、ディメンションｔにおける位置 d_t,Ref およびディメンションｘにおける位置 d_x を有する x ∈[ 0,1,2 … (T-1)] / [ t ] によるレイヤに従属する。

【0262】

他の特定の実施形態において、全ての従属性は逆にされ、それゆえに Ref( d_t ) における位置は、ディメンションｔにおける位置 d_t におけるレイヤに従属するディメンションｔにおけるレイヤの位置を指示する。

【0263】

従属性空間のシグナリングおよび導出に関する限り、以下に記述されるシグナリングは、例えばＳＥＩメッセージにおけるＶＰＳ、ＳＰＳにおいてまたはビットストリームにおける他の場所において、なすことができる。

【0264】

ディメンションの数およびディメンションにおける位置の数に関しては、以下が注目される。従属性空間は、特定の数のディメンションおよび各ディメンションにおける特定の数の位置によって定められる。

【0265】

特定の実施形態において、ディメンションの数 num＿dims およびディメンションｔにおける位置の数 num＿pos＿minus1[ t ] は、例えば図３９に示されるように、明確にシグナリングすることができる。

【0266】

他の実施形態において、num＿dims の値または num＿pos＿minus1 の値は、固定化することができ、ビットストリームにおいてシグナリングされない。他の実施形態において、num＿dims の値または num＿pos＿minus1 の値は、ビットストリームにおいて存在する他のシンタックスエレメントから導き出すことができる。より詳しくは、現在のＨＥＶＣ拡張設計において、ディメンションの数およびディメンションにおける位置の数は、それぞれスケーラビリティディメンションの数およびスケーラビリティディメンションの長さに等しくすることができる。

【0267】

それゆえに、［２］において定義された NumScalabilityTypes および dimension＿id＿len＿minus1[ t ] によって：
num＿dims = NumScalabilityTypes
num＿pos＿minus1[ t ] = dimension＿id＿len＿minus1[ t ]

【0268】

他の実施形態において、num＿dims の値または num＿pos＿minus1 の値が明確にシグナリングされるかまたはビットストリームに存在する他のシンタックスエレメントから導き出されるかどうかは、ビットストリームにおいてシグナリングすることができる。

【0269】

他の実施形態において、num＿dims の値は、ビットストリームに存在する他のシンタックスエレメントから導き出すことができ、１つ以上のディメンションの分割の付加的なシグナリングによってまたは付加的なディメンションをシグナリングすることによって増やされる。

【0270】

従属性空間における位置に対する layerIdInVps のマッピングに関して、レイヤが従属性空間にマッピングされることが注目される。

【0271】

特定の実施形態において、ディメンションｔにおける layerIdinVps 値ｉによってレイヤの位置を特定するシンタックスエレメント pos＿in＿dim[ i ][ t ] は、例えば、明確に伝送することができる。これは、図４０に図示される。

【0272】

他の実施形態において、pos＿in＿dim[ i ][ t ] の値は、ビットストリームにおいてシグナリングされないが、例えば次のように、layerIdInVps 値ｉから直接的に導き出すことができる。

【0273】

idx = i
dimDiv[ 0 ] = 1
for ( t = 0; t < T 1 ; t++ )
dimDiv[ t + 1 ] = dimDiv[ t ] * ( num＿pos＿minus1[ t ] + 1 )
for ( t = T 1 ; t >= 0; t-- ) [
pos＿in＿dim[ i ][ t ] = idx / dimDiv[ t ] // integer devision
idx = idx pos＿in＿dim[ i ][ t ] * dimDiv[ t ]
｝

【0274】

特に、現在のＨＥＶＣ拡張設計に対して、上述の記載は、dimension＿id[ i ][ t ] 値の現在の明確なシグナリングを置換するかもしれない。

【0275】

他の実施形態において、pos＿in＿dim[ i ][ t ] の値は、ビットストリームにおける他のシンタックスエレメントから導き出される。より詳しくは、現在のＨＥＶＣ拡張設計において、pos＿in＿dim[ i ][ t ] の値は、例えば、dimension＿id[ i ][ t ] 値から導き出すことができる。

【0276】

pos＿in＿dim[ i ][ t ] = dimension＿id[ i ][ t ]

【0277】

他の実施形態において、pos＿in＿dim[ i ][ t ] が明確にシグナリングされるかまたは他のシンタックスエレメントから導き出されるかをシグナリングすることができる。

【0278】

他の実施形態において、ビットストリームに存在する他のシンタックスエレメントから導き出されるpos＿in＿dim[ i ][ t ] に加えて、pos＿in＿dim[ i ][ t ] 値が明確にシグナリングされるどうかを、シグナリングすることができる。

【0279】

従属性のシグナリングおよび導出に関しては、以下が用いられる。

【0280】

直接位置従属性フラグの使用が以下の実施形態の主題である。この実施形態において、参照位置が、例えば図４１に特定されるように、ディメンションｔにおける位置ｎがディメンションｔにおける位置ｍの参照位置セットに含まれるかどうかを指示する、例えばフラグpos＿dependency＿flag[ t ][ m ][ n ] によってシグナリングされる。

【0281】

参照位置セットを用いる実施形態において、ディメンションｔにおける位置ｍに対してディメンションｔにおける参照位置の数を特定する変数 num＿ref＿pos[ t ][ m ] およびディメンションｔにおける位置ｍに対してディメンションｔにおけるｊ番目の参照位置を特定する変数 ref＿pos＿set[ t ][ m ][ j ] は、次のように導き出すことができる：
for( t = 0; t <= num＿dims; t++ )
for( m = 1; m <= num＿pos＿minus1[ t ]; m++ )
num＿ref＿pos[ t ][ m ] = 0
for( n = 0; n < m; n++ ) [
if ( pos＿dependency＿flag[ t ][ m ][ n ] = = true ) [
ref＿pos＿set[ t ][ m ][ num＿ref＿pos[ t ][ m ] ] = n
num＿ref＿pos[ t ][ m ] ++
｝
｝

【0282】

他の実施形態において、参照位置のセットのエレメントは、例えば図４２に特定されるように、直接的にシグナリングすることができる。

【0283】

直接従属性フラグを用いた実施形態において、ｉに等しい layerIdInVps によるレイヤがｊに等しい layerIdInVps によるレイヤに従属することを特定する直接従属性フラグ directDependencyFlag[ i ][ j ] は、参照位置セットから導き出されるであろう。例えば以下において特定されるように、なされるであろう：

【0284】

入力としてのベクトル posVector による関数 posVecToPosIdx( posVector ) は、以下において特定されるように、従属性空間における位置 posVector に関係するインデックス posIdx を導き出す：

【0285】

for ( t = 0, posIdx = 0, offset = 1; t < num＿dims; t++) [
posIdx = posIdx + offset * posVector[ t ]
offset = offset * ( num＿pos＿minus1[ t ] + 1 );
｝

【0286】

pos＿in＿dim[ i ] から導き出されるインデックス idx に従属する layerIdinVps 値ｉを特定する変数 posIdxToLayerIdInVps[ idx ] は、例えば以下において特定されるように導き出すことができる：

【0287】

for (i = 0; i < vps＿max＿layers＿minus1; i++)
posIdxToLayerIdInVps[ posVecToPosIdx( pos＿in＿dim[ i ] )] = i

【0288】

変数 directDependencyFlag[ i ][ j ] は、以下に特定されるように導き出される：

【0289】

for (i = 0; i <= vps＿max＿layers＿minus1; i++) [
for (k = 0; k < i; k++)
directDependencyFlag[ i ][ k ] = 0
curPosVec = pos＿in＿dim[ i ]
for (t = 0; t < num＿dims; t++) [
for (j = 0; j < num＿ref＿pos[ t ][ curPosVec[ t ] ]; j++) [
refPosVec = curPosVec
refPosVec[ t ] = ref＿pos＿set[ t ][ curPosVec[ t ] ][ j ]
directDependencyFlag[ i ][ posIdxToLayerIdInVps[ posVecToPosIdx( refPosVec ) ] ] = 1
]
]
]

【0290】

実施形態において、ｉに等しい layerIdInVps によるレイヤがｊに等しい layerIdInVps によるレイヤに従属することを特定する直接従属性フラグ directDependencyFlag[ i ][ j ] は、pos＿dependency＿flag[ t ][ m ][ n ] フラグから直接的に導き出されるであろう。例えば、以下に特定されるように：

【0291】

for (i = 1; i <= vps＿max＿layers＿minus1; i++) [
curPosVec = pos＿in＿dim[ i ];
for (j = 0; j < i; j++) [
refPosVec = pos＿in＿dim[ j ]
for (t = 0, nD = 0; t < num＿dims; t++)
if ( curPosVec[ t ] ! = refPosVec[ j ][ t ] ) [
nD ++
tD = t
]
if ( nD = = 1 )
directDependencyFlag[ i ][ j ] = pos＿dependency＿flag[ tD ][ curPosVec[ tD ] ][ refPosVec[ tD ] ]
else
directDependencyFlag[ i ][ j ] = 0
]
]

【0292】

参照レイヤセットを用いる実施形態において、ｉに等しい layerIdInVps によるレイヤに対する参照レイヤの数を特定する変数 NumDirectRefLayers[ i ] および ｋ番目の参照レイヤの layerIdInVps の値を特定する変数 RefLayerId[ i ][ k ] は、例えば以下に特定されるように導き出されるであろう：

【0293】

for( i = 1; i <= vps＿max＿layers＿minus1; i++ )
for( j = 0, NumDirectRefLayers[ i ] = 0; j < i; j++ )
if( directDependencyFlag[ i ][ j ] = = 1 )
RefLayerId[ i ][ NumDirectRefLayers[ i ]++ ] = layer＿id＿in＿nuh[ j ]

【0294】

他の実施形態において、例えば以下に特定されるように、参照レイヤは、directDependencyFlag 値を導き出すことなく、参照位置セットから直接的に導き出すことができる：

【0295】

for (i = 0; i <= vps＿max＿layers＿minus1; i++) [
NumDirectRefLayers[ i ] = 0
curPosVec = pos＿in＿dim[ i ]
for (t = 0; t < num＿dims; t++) [
for (j = 0; j < num＿ref＿pos[ t ][ curPosVec[ t ] ]; j++) [
refPosVec = curPosVec
refPosVec[ t ] = ref＿pos＿set[ t ][ curPosVec[ t ] ][ j ]
m = posIdxToLayerIdInVps[ posVecToPosIdx( refPosVec ) ]
RefLayerId[ i ][ NumDirectRefLayers[ i ]++ ] = layer＿id＿in＿nuh[ m ]
]
]

【0296】

他の実施形態において、参照レイヤは、ref＿pos＿set 変数を導き出すことなく、pos＿dependency＿flag 変数から直接的に導き出されるであろう。

【0297】

このように、上記議論された図は、第４の態様によるデータストリームを図示し、レイヤ間予測を用いて、ビデオ材料が情報量の異なるレベル、すなわち数において LayerIdInVps で符号化されるマルチレイヤビデオデータストリームを明らかにする。レベルは、それらの間で定められるシーケンシャル順序を有する。たとえば、それらは、シーケンス 1…vps＿max＿layers＿minus1 に従う。たとえば、図４０を参照されたい。ここで、マルチレイヤビデオデータストリーム内のレイヤの数は、vps＿max＿layers＿minus1 によって９００で与えられる。

【0298】

レイヤ間予測を介して、レイヤがシーケンシャル順序に従って引き続くいかなるレイヤからも従属しないように、ビデオ材料がマルチレイヤビデオデータストリームに符号化される。すなわち、１～ vps＿max＿layers＿minus1 までのナンバリングを用いて、レイヤｉは単にレイヤｊ< ｉに従属することができる。

【0299】

レイヤ間予測を介して、他のレイヤの１つ以上から従属する各レイヤは、ビデオ材料が１つ以上の他のレイヤに符号化される情報量を増大させる。たとえば、増大は、空間分解能、ビューの数、ＳＮＲ精度等、または他のディメンションタイプに関係する。

【0300】

マルチレイヤビデオデータストリームは、たとえば、ＶＰＳレベルにおいて、第１のシンタックス構造を備える。上記実施例において、num＿dims は、図３９において９０２で示されるように、第１のシンタックス構造によって備えることができる。したがって、第１のシンタックス構造は、従属性ディメンション９０４および９０６の数Ｍを定める。図３６において、それは、例示的に２つであり、１つは水平に、他は垂直に導く。この点に関して、上記アイテム２が参照される：レベルが情報量の増加させる観点から、ディメンションの数は、異なるディメンションタイプの数に必ずしも等しいわけではない：ディメンションの数は、たとえば、垂直および水平のビューシフトの間を区別することにより、より高くすることができる。従属性空間９０８にスパンするＭ個の従属性ディメンション９０４および９０６が、図３６に例示的に示される。

【0301】

【0302】

マルチレイヤビデオデータストリームは、従属性ディメンションｉ当り、たとえばＶＰＳレベルにおいて、第２のシンタックス構造９１４を備える。上記実施例において、それは、pos＿dependency＿flag[ t ][ m ][ n ] 、または、num＿ref＿pos[ t ][ m ] ＋ ref＿pos＿set[ t ][ m ][ j ] を包含する。第２のシンタックス構造９１４は、従属性ディメンションｉ当りの従属ディメンションｉのＮiランクレベルの中の従属性を記述する。従属性は、矩形９１０の間の全ての水平矢印または全ての垂直矢印によって、図３６に図示される。

【0303】

全般的に見て、この手段によって、各従属性ディメンションに対して、それぞれのディメンション以外の従属性ディメンションの各々に沿ったサイクリックシフトに対して不変であるそれぞれの従属性ディメンションと平行な従属性によって従属性軸のそれぞれの１つと平行に走り、高いランクレベルから低いランクレベルまでポイントするように制限された方法で、従属性空間における利用可能ポイントの間の従属性が定められる。図３６を参照：矩形の上側線の矩形の間の全ての水平矢印は、矩形の下側行において複製され、同じことが、利用可能ポイントに対応する矩形およびそれらの従属性に対応する矢印によって、矩形の４つの垂直列に関して垂直矢印に対して適用される。この手段によって、全単射マッピングを介して、第２のシンタックス構造は、同時に、レイヤ間の従属性を定める。

【0304】

デコーダのようなネットワークエンティティまたはＭＭＥのようなｍａｎｅは、データストリームの第１および第２のシンタックス構造を読み込み、第１および第２のシンタックス構造に基づいて、レイヤ間の従属性を決定することができる。

【0305】

【0306】

その際、ネットワークエンティティは、レベルの１つ選択することができる；そして、選択されたレベルがレイヤ間の従属性として独立するレイヤに、例えば、nuh＿layer＿id を介して帰属するマルチレイヤビデオデータストリームのパケット、例えばＮＡＬユニットを破棄する。

【0307】

いくつかの態様が装置の文脈で記載されてきたが、これらの態様は対応する方法の記載をも示すことは明らかであり、ここでブロックまたはデバイスが方法ステップまたは方法ステップの特徴に対応する。同様に、方法ステップの文脈において記載された態様は、対応する装置の対応するブロックまたはアイテムまたは特徴の記載をも示す。いくつかのまたは全ての方法ステップは、たとえば、マイクロプロセッサ、プログラム可能なコンピュータまたは電子回路のように、ハードウェア装置によって（または用いて）実行することができる。いくつかの実施形態では、最も重要な方法ステップの１つ以上は、この種の装置によって実行することができる。

【0308】

特定の実施要求に従って、本発明の実施形態は、ハードウェアにおいてまたはソフトウェアにおいて実施することができる。実施は、その上に格納される電子的に読取可能な制御信号を有し、それぞれの方法が実行されるようにプログラム可能なコンピュータシステムと協働する（または協働することができる）、デジタル記憶媒体、たとえばフロッピー（登録商標）ディスク、ＤＶＤ、ブルーレイ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリを用いて実行することができる。それ故に、デジタル記憶媒体は、コンピュータ読取可能とすることができる。

【0309】

本発明によるいくつかの実施形態は、電子的に読取可能な制御信号有し、本願明細書に記載された方法の１つが実行されるプログラム可能なコンピュータシステムと協働することができるデータキャリアを備える。

【0310】

一般に、本発明の実施形態は、コンピュータプログラム製品がコンピュータ上で動作するとき、方法の１つを実行するように動作可能であるプログラムコードを有するコンピュータプログラム製品として実施することができる。プログラムコードは、たとえば機械読取可能キャリアに格納することができる。

【0311】

他の実施形態は、機械読取可能キャリアに格納され、本願明細書に記載された方法の１つを実行するためのコンピュータプログラムを備える。

【0312】

言い換えれば、発明の方法の実施形態は、それ故に、コンピュータプログラムがコンピュータ上で動作するとき、本願明細書に記載された方法の１つを実行するためのプログラムコードを有するコンピュータプログラムである。

【0313】

発明の方法の更なる実施形態は、それ故に、その上に記録され、本願明細書に記載された方法の１つを実行するためのコンピュータプログラムを備え、その上に記録されたデータキャリア（またはデジタル記憶媒体またはコンピュータ読取可能媒体）である。データキャリア、デジタル記憶媒体または記録媒体は、通常は有形および／または固定である。

【0314】

発明の方法の更なる実施形態は、それ故に、本願明細書に記載された方法の１つを実行するためのコンピュータプログラムを表すデータストリームまたは信号のシーケンスである。データストリームまたは信号のシーケンスは、たとえば、データ通信接続を介して、たとえばインターネットを介して転送されるように構成することができる。

【0315】

更なる実施形態は、本願明細書に記載された方法の１つを実行するように構成されたまたは適合された処理手段、たとえばコンピュータまたはプログラマブルロジックデバイスを備える。

【0316】

更なる実施形態は、本願明細書に記載された方法の１つを実行するコンピュータプログラムがインストールされているコンピュータを備える。

【0317】

本発明による更なる実施形態は、本願明細書に記載された方法の１つを実行するコンピュータプログラムをレシーバに転送する（たとえば、電子的にまたは光学的に）ように構成された装置またはシステムを備える。レシーバは、たとえば、コンピュータ、モバイルデバイス、メモリデバイス等とすることができる。装置またはシステムは、たとえば、コンピュータプログラムをレシーバへ転送するファイルサーバを備えることができる。

【0318】

いくつかの実施形態では、プログラマブルロジックデバイス（たとえばフィールドプログラマブルゲートアレイ）を、本願明細書に記載された方法の機能のいくつかまたは全てを実行するために用いることができる。いくつかの実施形態において、フィールドプログラマブルゲートアレイは、本願明細書に記載された方法の１つを実行するためにマイクロプロセッサと協働することができる。一般に、方法は、いかなるハードウェア装置によっても好ましくは実行される。

【0319】

本願明細書に記載された装置は、ハードウェア装置を用いて、またはコンピュータを用いて、またはハードウェア装置とコンピュータの組合せを用いて実施することができる。

【0320】

本願明細書に記載された方法は、ハードウェア装置を用いて、またはコンピュータを用いて、またはハードウェア装置とコンピュータの組合せを用いて実行することができる。

【0321】

上述した実施形態は、単に本発明の原理に対して示したものである。本願明細書に記載された構成および詳細の修正および変更は他の当業者にとって明らかであると理解される。それ故に、本発明は、特許請求の範囲のスコープによってのみ制限され、本願明細書の実施形態の記載および説明によって提供された特定の詳細によっては制限されないことを意図する。

【0322】

［参考文献］
［１］B. Bross et al., "High Efficiency Video Coding (HEVC) text specification draft 10", JCTVC-L1003, Geneva, CH, 14-23 Jan. 2013
［２］G. Tech et al., "MV-HEVC Draft Text 3", JCT3V-C1004, Geneva, CH , 17-23 Jan. 2013
［３］G. Tech et al., "3D-HEVC Test Model 3", JCT3V-C1005, Geneva, CH , 17-23 Jan. 2013
［４］J. Chen et al., "SHVC Draft Text 1", JCT-VCL1008, Geneva, CH , 17-23 Jan. 2013
［５］WILBURN, Bennett, et al. High performance imaging using large camera arrays. ACM Transactions on Graphics, 2005, 24. Jg., Nr. 3, S. 765-776.
［６］WILBURN, Bennett S., et al. Light field video camera. In: Electronic Imaging 2002. International Society for Optics and Photonics, 2001. S. 29-36.
［７］HORIMAI, Hideyoshi, et al. Full-color 3D display system with 360 degree horizontal viewing angle. In: Proc. Int. Symposium of 3D and Contents. 2010. S. 7-10.

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13a】

【図13b】

【図13c】

【図13d】

【図13e】

【図13f】

【図13g】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34a】

【図34b】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】