(57)【要約】マルチビュー・ビデオ符号化における使用のための方法および装置が提供される。装置は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカー映像および非アンカー映像をエンコードするためのエンコーダ（１００）を含む。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
2009543514.tif 000002
【特許請求の範囲】
【請求項１】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューについてのアンカー映像および非アンカー映像をエンコードするためのエンコーダを含む装置であって、前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、装置。
【請求項２】
請求項１記載の装置であって、前記エンコーダが前記依存構造を帯域内または帯域外の少なくとも一方で信号伝達する、装置。
【請求項３】
請求項１記載の装置であって、前記エンコーダが前記依存構造を高レベルのシンタックスを使って信号伝達する、装置。
【請求項４】
請求項３記載の装置であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つにおいて信号伝達される、装置。
【請求項５】
請求項３記載の装置であって、前記依存構造がフラグを使って信号伝達される、装置。
【請求項６】
請求項５記載の装置であって、前記フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表される、装置。
【請求項７】
請求項３記載の装置であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために、前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われる、装置。
【請求項８】
請求項３記載の装置であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われる、装置。
【請求項９】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をエンコードするステップを含む方法であって、前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造が、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、方法。
【請求項１０】
請求項９記載の方法であって、前記エンコードするステップが前記依存構造を帯域内または帯域外の少なくとも一方で信号伝達することを含む、方法。
【請求項１１】
請求項９記載の方法であって、前記エンコードするステップが前記依存構造を高レベルのシンタックスを使って信号伝達することを含む、方法。
【請求項１２】
請求項１１記載の方法であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つにおいて信号伝達される、方法。
【請求項１３】
請求項１１記載の方法であって、前記依存構造がフラグを使って信号伝達される、方法。
【請求項１４】
請求項１３記載の方法であって、前記フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表される、方法。
【請求項１５】
請求項１１記載の方法であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために、前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われる、方法。
【請求項１６】
請求項１１記載の方法であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われる、方法。
【請求項１７】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカー映像および非アンカー映像をデコードするためのデコーダをもつ装置であって、前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造が、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、装置。
【請求項１８】
請求項１７記載の装置であって、前記デコーダが前記依存構造を帯域内または帯域外の少なくとも一方で受領する、装置。
【請求項１９】
請求項１７記載の装置であって、前記デコーダが前記依存構造を高レベルのシンタックスを使って判別する、装置。
【請求項２０】
請求項１９記載の装置であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つを使って判別される、装置。
【請求項２１】
請求項１９記載の装置であって、前記依存構造がフラグを使って判別される、装置。
【請求項２２】
請求項２１記載の装置であって、前記フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表される、装置。
【請求項２３】
請求項１９記載の装置であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われる、装置。
【請求項２４】
請求項１９記載の装置であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われる、装置。
【請求項２５】
請求項１７記載の装置であって、前記デコーダが、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスのために前記少なくとも二つのビューにおけるアンカー映像のどれをバッファリングするべきかを、前記依存構造が表示順において前のアンカー映像または次のアンカー映像のどちらに従うかに基づいて、決定する、装置。
【請求項２６】
請求項２５記載の装置であって、前記デコーダが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より後に配されているアンカー映像と同じであるとき、前記ランダム・アクセス点より前に配されているアンカー映像をバッファリングのために選択する、装置。
【請求項２７】
請求項２５記載の装置であって、前記デコーダが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より前に配されているアンカー映像と同じであるとき、ランダム・アクセス点より前に配されているアンカー映像をバッファリングから省略する、装置。
【請求項２８】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカー映像および非アンカー映像をデコードするステップを含む方法であって、前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、方法。
【請求項２９】
請求項２８記載の方法であって、前記デコードするステップが前記依存構造を帯域内または帯域外の少なくとも一方で受領することを含む、方法。
【請求項３０】
請求項２８記載の方法であって、前記デコードするステップが前記依存構造を高レベルのシンタックスを使って判別することを含む、方法。
【請求項３１】
請求項２８記載の方法であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つを使って判別される、方法。
【請求項３２】
請求項３０記載の方法であって、前記依存構造がフラグを使って判別される、方法。
【請求項３３】
請求項３０記載の方法であって、前記フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表される、方法。
【請求項３４】
請求項３２記載の方法であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われる、方法。
【請求項３５】
請求項３０記載の方法であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われる、方法。
【請求項３６】
請求項２８記載の方法であって、前記デコードするステップが、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスのために前記少なくとも二つのビューにおけるアンカー映像のどれをバッファリングするべきかを、前記依存構造が表示順において前のアンカー映像または次のアンカー映像のどちらに従うかに基づいて、決定することを含む、方法。
【請求項３７】
請求項３６記載の方法であって、前記デコードするステップが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より後に配されているアンカー映像と同じであるとき、前記ランダム・アクセス点より前に配されているアンカー映像をバッファリングのために選択することを含む、方法。
【請求項３８】
請求項３６記載の方法であって、前記デコードするステップが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より前に配されているアンカー映像と同じであるとき、ランダム・アクセス点より前に配されているアンカー映像をバッファリングから省略することを含む、方法。
【請求項３９】
ビットストリームから、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューをデコードするためのデコーダを有する装置であって、前記少なくとも二つのビューの一つまたは複数に対応する少なくとも二つのピクチャー・グループは異なる依存構造をもち、前記デコーダは、前記少なくとも二つのビューにおいて、前記少なくとも二つのビューの少なくとも一つへのランダム・アクセスのためにデコードされる必要がある映像を、少なくとも一つの依存性マップに基づいて選択する、装置。
【請求項４０】
請求項３９記載の装置であって、前記ランダム・アクセスが、前記ランダム・アクセスより表示順において早い、最も近いイントラ符号化された映像において始まる、装置。
【請求項４１】
請求項４０記載の装置であって、前記ビットストリームがアンカー映像および非アンカー映像を含み、前記デコーダが、前記少なくとも二つのビューにおいて、前記ランダム・アクセスより早い前記最も近いイントラ符号化された映像に時間的に対応するアンカー映像をバッファリングする、装置。
【請求項４２】
請求項３９記載の装置であって、前記ランダム・アクセスが、前記ランダム・アクセスより遅い、最も近いイントラ符号化された映像において始まる、装置。
【請求項４３】
請求項３９記載の装置であって、前記少なくとも一つの依存性マップが、前記ランダム・アクセスに対してより早いイントラ符号化された映像およびより遅いイントラ符号化された映像の依存性マップを含み、前記デコーダが、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップを比較することによって、必要とされる映像を選択する、装置。
【請求項４４】
請求項４３記載の装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが同じである、装置。
【請求項４５】
請求項４４記載の装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップのうち任意のものが必要とされる映像を決定するために使われる、装置。
【請求項４６】
請求項４３記載の装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが異なる、装置。
【請求項４７】
請求項４６記載の装置であって、前記少なくとも一つの依存性マップが、少なくとも一つのアンカー映像依存性マップを含み、前記デコーダが、前記少なくとも二つのビューのうちの前記少なくとも一つが、前記少なくとも二つのビューのどれに依存しているかを判定するために、前記少なくとも一つのアンカー映像依存性マップを検査する、装置。
【請求項４８】
請求項４７記載の装置であって、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存する各ビューについて、前記デコーダがそれに対応する依存性テーブルを検査する、装置。
【請求項４９】
請求項４８記載の装置であって、前記アンカー映像が、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存する各ビューからデコードされる、装置。
【請求項５０】
請求項４７記載の装置であって、前記デコーダが、前記より遅いイントラ符号化された映像と同じ依存性マップを使う何らかの特定の映像が前記ランダム・アクセスのためにデコードされることが必要とされるかどうかを、前記少なくとも二つのピクチャー・グループの一つについての変化した依存構造および前記少なくとも二つのピクチャー・グループの別の一つについての変化していない依存構造の組み合わせから形成される依存性マップに基づいて判定する、装置。
【請求項５１】
ビットストリームから、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューをデコードするステップを有する方法であって、前記少なくとも二つのビューの一つまたは複数に対応する少なくとも二つのピクチャー・グループは異なる依存構造をもち、前記デコードするステップは、前記少なくとも二つのビューにおいて、前記少なくとも二つのビューの少なくとも一つへのランダム・アクセスのためにデコードされる必要がある映像を、少なくとも一つの依存性マップに基づいて選択することを含む、方法。
【請求項５２】
請求項５１記載の方法であって、前記ランダム・アクセスが、前記ランダム・アクセスより表示順において早い、最も近いイントラ符号化された映像において始まる、方法。
【請求項５３】
請求項５２記載の方法であって、前記ビットストリームがアンカー映像および非アンカー映像を含み、前記デコードするステップが、前記少なくとも二つのビューにおいて、前記ランダム・アクセスより早い前記最も近いイントラ符号化された映像に時間的に対応するアンカー映像をバッファリングする、方法。
【請求項５４】
請求項５１記載の方法であって、前記ランダム・アクセスが、前記ランダム・アクセスより遅い、最も近いイントラ符号化された映像において始まる、方法。
【請求項５５】
請求項５１記載の方法であって、前記少なくとも一つの依存性マップが、前記ランダム・アクセスに対してより早いイントラ符号化された映像およびより遅いイントラ符号化された映像の依存性マップを含み、前記デコードするステップが、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップを比較することによって、必要とされる映像を選択する、方法。
【請求項５６】
請求項５５記載の方法であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが同じである、方法。
【請求項５７】
請求項５６記載の方法であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップのうち任意のものが必要とされる映像を決定するために使われる、方法。
【請求項５８】
請求項５５記載の方法であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが異なる、方法。
【請求項５９】
請求項５８記載の方法であって、前記少なくとも一つの依存性マップが、少なくとも一つのアンカー映像依存性マップを含み、前記デコードするステップが、前記少なくとも二つのビューのうちの前記少なくとも一つが、前記少なくとも二つのビューのどれに依存しているかを判定するために、前記少なくとも一つのアンカー映像依存性マップを検査する、方法。
【請求項６０】
請求項５９記載の方法であって、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存する各ビューについて、前記デコードするステップがそれに対応する依存性テーブルを検査する、方法。
【請求項６１】
請求項６０記載の方法であって、前記アンカー映像が、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存する各ビューからデコードされる、方法。
【請求項６２】
請求項５９記載の方法であって、前記デコードするステップが、前記より遅いイントラ符号化された映像と同じ依存性マップを使う何らかの特定の映像が前記ランダム・アクセスのためにデコードされることが必要とされるかどうかを、前記少なくとも二つのピクチャー・グループの一つについての変化した依存構造および前記少なくとも二つのピクチャー・グループの別の一つについての変化していない依存構造の組み合わせから形成される依存性マップに基づいて判定する、方法。
【請求項６３】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューについてエンコードされるアンカー映像および非アンカー映像を含む、ビデオ・エンコードのためのビデオ信号構造であって：前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、信号構造。
【請求項６４】
マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューについてエンコードされるアンカー映像および非アンカー映像を含むビデオ信号データがエンコードされている記憶媒体であって：前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである、記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
〈関連出願のための相互参照〉
本願は2006年7月11日に出願された米国仮出願第60/830,206号の利益を主張するものであり、この文献はここに参照によりその全体において組み込まれる。
【０００２】
〈技術分野〉
本願の原理は、概括的にはビデオのエンコードおよびデコードに、より詳細には、マルチビュー・ビデオ符号化（MVC:  Multi-view  Video  Coding）における使用のための方法および装置に関する。
【背景技術】
【０００３】
国際標準化機関／国際電気標準会議（ISO/IEC）動画像専門家グループ４（MPEG-4）パート10の先進ビデオ符号化（AVC）規格／国際電気通信連合・電気通信部門（ITU-T）H.264勧告（以下では「MPEG-4-AVC規格」）に準拠するマルチビュー・ビデオ符号化（MVC）の現行の実装では、特定のビューを同定し、カメラ・パラメータを信号伝達する用意はない。このビュー情報は、いくつかの理由のために必要とされる。ビュー・スケーラビリティ、ビュー・ランダム・アクセス、並列処理、ビュー生成およびビュー合成はみな、ビューid情報を利用するマルチビュー・ビデオ符号化要件（requirements）である。さらに、これらの要件のいくつかは、現在標準化しされた仕方で通用されて（passed）いないカメラ・パラメータをも利用する。
【０００４】
第一の従来技術のアプローチでは、マルチビューの圧縮されたビットストリームにおける効率的なランダム・アクセスを可能にする方法が提案される。提案される方法では、新しいV映像型（V-picture  type）および新しいビュー依存SEIメッセージ（View  Dependency  SEI  message）が定義される。提案されたV映像型において要求される特徴は、V映像は同じカメラにおける他の映像に対する時間的な依存性をもってはならず、同じ時刻における他のカメラにおける映像のみから予測されうるということである。提案されたビュー依存SEIメッセージは、V映像ならびに先行するおよび後続するシーケンスの映像が実際どのビューに依存してよいかを記載する。以下は提案された変更の詳細である。
【０００５】
V映像シンタックスおよびセマンティクスに関し、MPEG-4/AVC規格に関係する特定のシンタックス・テーブルが、V映像に対応する、ネットワーク抽象化層（NAL:  Network  Abstraction  Layer）ユニット型14を含むよう拡張される。また、V映像型は、以下のセマンティクスをもつよう定義される。
【０００６】
V映像（V-picture）：すべてのスライスが、同じ時間的インデックスをもつスライスのみ（すなわち、他のビュー内のスライスのみであって、当該ビュー内のスライスではない）を参照する符号化された映像。V映像が出力または表示されるとき、デコード・プロセスは、同じビューからの、IDR映像やV映像でなく、出力順において前記V映像に先行するすべての映像を「参照に未使用（unused  for  reference）」としてマークする。各V映像は同じNAL内に生起するビュー依存SEIメッセージに関連付けられる。
【０００７】
ビュー依存補足向上情報メッセージ（view  dependency  Supplemental  Enhancement  Information  message）のシンタックスおよびセマンティクスに関し、ビュー依存補足向上情報メッセージは、次のシンタックスで定義される。
【０００８】
【表１】
2009543514.tif 000003
ここで、num_seq_reference_views／num_pic_reference_viewsは、現在のシーケンス／映像のための参照として使うことができる潜在的なビューの数を表す。seq_reference_view_i／pic_reference_view_iはi番目の参照ビューについてのビュー番号を表す。
【０００９】
ビュー依存補足向上情報メッセージに関連付けられた映像は、pic_reference_view_iによって記述される指定されたビューしか参照できない。同様に、そのビューの出力順における、そのビューにおける次のビュー依存補足向上情報メッセージまでのすべての後続の映像は、seq_reference_view_iによって記述される指定されたビューしか参照できない。
【００１０】
ビュー依存補足向上情報メッセージは、それぞれの瞬時デコード・リフレッシュ（IDR:  Instantaneous  Decoding  Refresh）映像およびV映像と関連付けられる。
【００１１】
第一の従来技術方法は、基本ビューが時間とともに変化できる場合を扱う利点をもつが、どの映像を破棄すべきかを決定する前に映像の追加的なバッファリングを要求する。さらに、第一の従来技術方法は、依存性を決定するために再帰プロセスをもつという欠点がある。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
従来技術のこれらおよびその他の欠点および不都合な点が本願の原理によって対処される。本願の原理は、マルチビュー・ビデオ符号化（MVC）における使用のための方法および装置に向けられている。
【課題を解決するための手段】
【００１３】
本願の原理のある側面によれば、装置が提供される。該装置は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をエンコードするためのエンコーダを含む。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【００１４】
本願の原理のもう一つの側面によれば、方法が提供される。該方法は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をエンコードすることを含む。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【００１５】
本願の原理のさらにもう一つの側面によれば、装置が提供される。該装置は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をデコードするためのデコーダを含む。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【００１６】
本願の原理のさらにもう一つの側面によれば、方法が提供される。該方法は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をデコードすることを含む。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【００１７】
本願の原理のさらなる側面によれば、装置が提供される。該装置は、ビットストリームから、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューをデコードするためのデコーダを含む。前記少なくとも二つのビューの一つまたは複数に対応する少なくとも二つのピクチャー・グループ（Groups  of  Pictures）は、異なる依存構造（dependency  structure）をもつ。デコーダは、前記少なくとも二つのビューにおいて、前記少なくとも二つのビューの少なくとも一つへのランダム・アクセスのためにデコードされる必要がある映像を、少なくとも一つの依存性マップに基づいて、選択する。
【００１８】
本願の原理の今ひとつのさらなる側面によれば、方法が提供される。該方法は、ビットストリームから、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューをデコードすることを含む。前記少なくとも二つのビューの一つまたは複数に対応する少なくとも二つのピクチャー・グループ（Groups  of  Pictures）は、異なる依存構造（dependency  structure）をもつ。デコード・ステップは、前記少なくとも二つのビューにおいて、前記少なくとも二つのビューの少なくとも一つへのランダム・アクセスのためにデコードされる必要がある映像を、少なくとも一つの依存性マップに基づいて、選択する。
【００１９】
本願の原理のこれらおよびその他の側面、特徴および利点が、付属の図面との関連で読まれるべき、例示的な実施形態の以下の詳細な記述から明白となるであろう。
【００２０】
本願の原理は、以下の例示的な図に基づいてよりよく理解されうる。
【発明を実施するための最良の形態】
【００２１】
本願の原理は、マルチビュー・ビデオ符号化（MVC）における使用のための方法および装置に向けられる。
【００２２】
本記載は本願の原理を例解する。よって、当業者が、本稿に明示的に記載や図示はされていなくても、本発明の原理を具現し、よってその精神および範囲内に含まれるさまざまな構成を当業者が考案できるであろうことは理解されるであろう。
【００２３】
本稿で記載されるあらゆる例および条件付きの言辞は、読者が、本発明の原理および当該技術を進歩させる発明者によって寄与される概念を理解するのを支援するという教育目的のために意図されているのであって、そのような個別的に記載されている例および条件に限定することなく解釈されるものである。
【００２４】
さらに、本発明の原理、側面および実施形態ならびにその個別的な例を記載する本稿におけるあらゆる陳述は、その構造的および機能的な等価物の両方を包含することが意図されている。さらに、そのような等価物は、現在知られている等価物および将来開発される等価物、すなわち構造にかかわりなく同じ機能を実行する任意の開発された要素の両方を含むことが意図されている。
【００２５】
よって、たとえば、当業者は、本稿に呈示されるブロック図が本発明の原理を具現する例示的な回路の概念図を表すものであることを理解するであろう。同様に、フローチャート、流れ図、状態遷移図、擬似コードなどはいずれも、コンピュータ可読媒体において実質的に表現され、コンピュータまたはプロセッサによって実行されうるさまざまなプロセスを表すことが理解されるであろう。これはそのようなコンピュータまたはプロセッサが明示的に示されているかどうかにはよらない。
【００２６】
図面に示されるさまざまな要素の機能は、専用ハードウェアの使用を通じて提供されても、適切なソフトウェアとの関連でソフトウェアを実行することのできるハードウェアの使用を通じて提供されてもよい。プロセッサによって提供されるとき、機能は単一の専用プロセッサによって、単一の共有されるプロセッサによって、あるいは一部が共有されていてもよい複数の個別プロセッサによって提供されうる。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行することのできるハードウェアのみを指すものと解釈されるべきではなく、暗黙的に、限定なしに、デジタル信号プロセッサ（「DSP」）ハードウェア、ソフトウェアを記憶するための読み出し専用メモリ（「ROM」）、ランダム・アクセス・メモリ（「RAM」）および不揮発性記憶装置を含みうる。
【００２７】
通常のものおよび／またはカスタムのものを含め他のハードウェアも含まれてもよい。同様に、図面に示されるスイッチがあったとしても、それは単に概念的なものである。その機能はプログラム論理の動作を通じて、専用論理を通じて、プログラム制御と専用論理の相互作用を通じて、あるいはさらに手動で実行されてもよい。特定の技法は、コンテキストからより個別に理解されるように実装者によって選択可能である。
【００２８】
本願の請求項では、特定の機能を実行する手段として表現されたいかなる要素も、その機能を実行するいかなる仕方をも、たとえばａ）その機能を実行する回路素子の組み合わせまたはｂ）任意の形の、したがってファームウェア、マイクロコードなどを含む、当該機能を実行するソフトウェアを実行するための適切な回路と組み合わされたソフトウェアを包含することが意図されている。そのような請求項によって定義される本願の原理は、前記さまざまな記載される手段によって提供される機能性が請求項が記載する仕方で組み合わされ、一緒にされるという事実にある。よって、これらの機能性を提供できる任意の手段が本願で示されている手段と等価であると見なされる。
【００２９】
明細書における本願の原理の「一つの実施形態」または「ある実施形態」への言及は、その実施形態との関連で記載されている特定の特徴、構造、特性などが本願の原理の少なくとも一つの実施形態に含まれることを意味する。よって、本明細書を通じた随所における「一つの実施形態では」または「ある実施形態では」といった句の出現は、必ずしもみな同じ実施形態を指すのではない。
【００３０】
本稿での用法では、「高レベルのシンタックス」は、マクロブロック層より階層的に上にあるビットストリームに存するシンタックスを指す。たとえば、本稿で使われるところの高レベルのシンタックスは、これに限られないが、スライス・ヘッダ・レベル、補足向上情報（SEI）レベル、映像パラメータ・セット・レベル、シーケンス・パラメータ・セット・レベルおよびNALユニット・ヘッダ・レベルでのシンタックスを指しうる。
【００３１】
本稿での用法では、「アンカー・スロット（anchor  slot）」はある映像が各ビューからサンプリングされた時を指し、各ビューからのサンプリングされた映像のそれぞれはアンカー映像（anchor  picture）である。
【００３２】
図１に目を向けると、例示的なマルチビュー・ビデオ符号化（MVC）エンコーダが概括的に参照符号１００によって示されている。エンコーダ１００は、変換器（transformer）１１０の入力と信号通信で接続された出力をもつ組み合わせ器（combiner）１０５を含む。変換器１１０の出力は量子化器１１５と信号通信で接続されている。量子化器１１５の出力は、エントロピー符号化器１２０の入力および逆量子化器１２５の入力と信号通信で接続されている。逆量子化器の出力１２５は、逆変換器１３０の入力と信号通信で接続されている。逆変換器１３０の出力は、組み合わせ器１３５の第一の非反転入力と信号通信で接続されている。組み合わせ器１３５の出力は、イントラ予測器１４５の入力およびブロック解除フィルタ（deblocking  filter）１５０の入力と信号通信で接続されている。ブロック解除フィルタ１５０の出力は、（ビューiについての）参照映像記憶１５５の入力と信号通信で接続されている。参照映像記憶１５５の出力は、動き補償器１７５の第一の入力および動き推定器１８０の第一の入力と信号通信で接続されている。動き推定器１８０の出力は、動き補償器１７５の第二の入力と信号通信で接続されている。
【００３３】
（他のビューについての）参照映像記憶１６０の出力は不均等性（disparity）推定器１７０の第一の入力および不均等性補償器１６５の第一の入力と信号通信で接続されている。不均等性推定器１７０の出力は、不均等性補償器１６５の第二の入力と信号通信で接続されている。
【００３４】
エントロピー・デコーダ１２０の出力は、エンコーダ１００の出力として利用可能である。組み合わせ器１０５の非反転入力は、エンコーダ１００の入力として利用可能であり、不均等性推定器１７０の第二の入力および動き推定器１８０の第二の入力と信号通信で接続されている。スイッチ１８５の出力は、組み合わせ器１３５の第二の非反転入力および組み合わせ器１０５の反転入力と信号通信で接続されている。スイッチ１８５は、動き補償器１７５の出力と信号通信で接続されている第一の入力、不均等性補償器１６５の出力と信号通信で接続されている第二の入力およびイントラ予測器１４５の出力と信号通信で接続されている第三の入力を含む。
【００３５】
図２に目を向けると、例示的なマルチビュー・ビデオ符号化（MVC）デコーダが、参照符号２００によって概括的に示されている。デコーダ２００は、逆量子化器２１０の入力と信号通信で接続された出力をもつエントロピー・デコーダ２０５を含む。逆量子化器の出力は、逆変換器２１５の入力と信号通信で接続されている。逆変換器２１５の出力は、組み合わせ器２２０の第一の非反転入力と信号通信で接続されている。組み合わせ器２２０の出力は、ブロック解除フィルタ２２５の入力およびイントラ予測器２３０の入力と信号通信で接続されている。ブロック解除フィルタ２２５の出力は、（ビューiについての）参照映像記憶２４０の入力と信号通信で接続されている。参照映像記憶２４０の出力は、動き補償器２３５の第一の入力と信号通信で接続されている。
【００３６】
（他のビューについての）参照映像記憶２４５の出力は、不均等性補償器２５０の第一の入力と信号通信で接続されている。
【００３７】
エントロピー符号化器２０５の入力は、デコーダ２００への入力として、残留ビットストリーム（residual  bitstream）を受領するために利用可能である。さらに、スイッチ２５５の制御入力も、デコーダ２００への入力として、どの入力がスイッチ２５５によって選択されるかを制御するための制御シンタックスを受領するために利用可能である。さらに、動き補償器２３５の第二の入力は、デコーダ２００の入力として、動きベクトルを受領するために利用可能である。また、不均等性補償器２５０の第二の入力が、デコーダ２００への入力として、不均等性ベクトル（disparity  vector）を受領するために利用可能である。
【００３８】
スイッチ２５５の出力は、組み合わせ器２２０の第二の非反転入力と信号通信で接続されている。スイッチ２５５の第一の入力は、不均等性補償器２５０の出力と信号通信で接続されている。スイッチ２５５の第二の入力は、動き補償器２３５の出力と信号通信で接続されている。スイッチ２５５の第三の入力は、イントラ予測器２３０の出力と信号通信で接続されている。モード・モジュール２６０の出力は、スイッチ２５５によってどの入力が選択されるかを制御するために、スイッチ２５５と信号通信で接続されている。ブロック解除フィルタ２２５の出力は、当該デコーダの出力として利用可能である。
【００３９】
本願の原理のある実施形態では、高レベルのシンタックスが、マルチビュー・シーケンスの効率的な処理のために提案される。特に、我々は、マルチビュー・スライスをサポートするために、ビュー・パラメータ・セット（VPS:  View  Parameter  Set）と呼ばれる、独自のNALユニット型およびさらに二つの新しいNALユニット型をもつ新しいパラメータ・セットを作成することを提案する。NALユニット型は、スライスがどのビューに属しているかを識別するための、NALヘッダ内のビュー識別子（id）を含む。ビューのスケーラビリティおよびMPEG-4/AVC規格準拠デコーダに対する上位互換性のため、我々は、我々が「MPEG-4/AVC準拠基本ビュー」と呼ぶ一つのMPEG-4/AVC準拠ビューを維持することを提案する。
【００４０】
本稿での用法では、「高レベルのシンタックス」は、マクロブロック層より階層的に上にあるビットストリームに存するシンタックスを指す。たとえば、本稿で使われるところの高レベルのシンタックスは、これに限られないが、スライス・ヘッダ・レベル、補足向上情報（SEI）レベル、映像パラメータ・セット・レベルおよびシーケンス・パラメータ・セット・レベルでのシンタックスを指しうる。
【００４１】
特定のビューを同定し、カメラ・パラメータを信号伝達する用意がないとして上記したマルチビュー・ビデオ符号化システムの現行の実装では、異なるビューを別個のビューとして扱うのではなく、異なるビューがインターリーブされて単一のシーケンスを形成する。シンタックスは上記のようにMPEG-4/AVC規格と互換なので、現在のところ、所与のスライスがどのビューに属するかを識別することは可能ではない。このビュー情報は、いくつかの理由で必要とされる。ビュー・スケーラビリティ、ビュー・ランダム・アクセス、並列処理、ビュー生成およびビュー合成は、みな、ビューを識別する必要があるマルチビュー・ビデオ符号化の要件である。ビュー・ランダム・アクセスの効率的なサポートのためには、必要な映像だけがデコードされるよう、異なる映像がどのように互いに依存しあっているかをデコーダが知ることが重要である。カメラ・パラメータはビュー合成のために必要とされる。ビュー合成が結果的にデコード・ループにおいて使用される場合、カメラ・パラメータを信号伝達する標準化された方法が指定される必要がある。ある実施形態によれば、ビュー・パラメータ・セットが使われる。
【００４２】
ある実施形態では、非MVC互換だがMPEG-4/AVC互換のデコーダをサポートする目的のため、MPEG-4/AVC規格に対して完全に上位互換な一つのビューが必要とされる。ある実施形態では、高速のビュー・ランダム・アクセスを容易にするために独立にデコード可能なビューがあると想定される。我々は、これらのビューのことを「基本ビュー（base  view）」と称する。基本ビューはMPEG-4/AVC規格と互換であってもなくてもよいが、MPEG-4/AVC互換なビューは常に基本ビューである。
【００４３】
図３に目を向けると、階層的B映像を使った、MPEG-4/AVC規格に基づくビュー間時間的（inter-view-temporal）予測構造が概括的に参照符号３００によって示されている。図３において、変数Iはイントラ符号化された（intra  coded）映像を表し、変数Pは予測符号化された）（predictively  coded）映像を表し、変数Bは双方向予測符号化された（bi-predictively  coded）映像を表し、変数Tは特定の映像の位置を表し、変数Sは特定の映像が対応する特定のビューを表す。
【００４４】
ある実施形態によれば、以下の用語が定義される。
【００４５】
「アンカー映像（anchor  picture）」は、デコードするのに、異なる時点でサンプリングされた映像が全く関わってこない映像として定義される。アンカー映像は、nal_ref_idcを3に設定することによって合図される。図３では、位置T0、T8、…、T96およびT100にあるすべての映像がアンカー映像の例である。
【００４６】
「非アンカー映像（non-anchor  picture）」は、アンカー映像について指定された上記の制約をもたない映像として定義される。図３では、映像B2、B3およびB4が非アンカー映像である。
【００４７】
「基本ビュー（base  view）」は、他のビューに全く依存せず、独立してデコードできるビューである。図３では、ビューS0が基本ビューの例である。
【００４８】
また、ある実施形態では、マルチビュー・ビデオ符号化スライスをサポートするために、ビュー・パラメータ・セットと呼ばれる、独自のNALユニット型および二つの新しいNALユニット型をもつ新しいパラメータ・セットが提案される。我々はまた、使用されるべきview_idおよびビュー・パラメータ・セットを示すために、スライス・ヘッダ・シンタックスを修正する。
【００４９】
MPEG-4/AVC規格は次の二つのパラメータ・セットを含む：（１）シーケンス・パラメータ・セット（SPS:  Sequence  Parameter  Set）。これはシーケンス全体にわたって変化しないと期待される情報を含む。（２）映像パラメータ・セット（PPS:  Picture  Parameter  Set）。これは、各映像について変化しないと期待される情報を含む。
【００５０】
マルチビュー・ビデオ符号化は、各ビューに固有な追加的情報をもつので、我々は、この情報を伝送するために別個のビュー・パラメータ・セット（VPS）を作成した。異なるビューの間の依存性を決定するのに必要とされる情報のすべては、ビュー・パラメータ・セットにおいて示される。提案されるビュー・パラメータ・セットについてのシンタックス・テーブルが表１（ビュー・パラメータ・セットRBSPシンタックス）に示されている。このビュー・パラメータ・セットは、新しいNALユニット型、たとえば表２（NALユニット型コード）に示される型14に含まれる。
【００５１】
本発明の記載によれば、以下の用語が定義される。
【００５２】
view_parameter_set_idは、スライス・ヘッダにおいて参照されるビュー・パラメータ・セットを同定する。view_parameter_set_idの値は0から255の範囲である。
【００５３】
number_of_views_minus_1に1を加えたものは、ビットストリーム中のビューの総数を同定する。number_of_view_minus_1の値は0から255の範囲である。
【００５４】
avc_compatible_view_idは、AVC互換ビューのview_idを示す。avc_compatible_view_idの値は0から255の範囲である。
【００５５】
is_base_view_flag[i]が1に等しいことは、ビューiが基本ビューであり、独立してデコード可能であることを示す。is_base_view_flag[i]が0に等しいことは、ビューiが基本ビューではないことを示す。is_base_view_flag[i]の値は、AVC互換ビューiについて1に等しくなる。
【００５６】
dependency_update_flagが1に等しいことは、このビューについての依存性情報がVPSにおいて更新されていることを示す。dependency_update_flagが0に等しいことは、このビューについての依存性情報が更新されておらず、変更されるべきでないことを示す。
【００５７】
anchor_picture_dependency_maps[i][j]が1に等しいことは、view_idがjに等しいアンカー映像がview_idがiに等しいアンカー映像に依存することを示す。
【００５８】
non_anchor_picture_dependency_maps[i][j]が1に等しいことは、view_idがjに等しい非アンカー映像がview_idがiに等しい非アンカー映像に依存することを示す。non_anchor_picture_dependency_maps[i][j]はanchor_picture_dependency_maps[i][i]が1に等しいときにのみ存在する。anchor_picture_dependency_maps[i][j]が存在し、0に等しい場合は、non_anchor_picture_dependency_maps[i][j]は0に等しいと推定される。
【００５９】
【表２】
2009543514.tif 000004
【００６０】
【表３】
2009543514.tif 000005
ビュー・パラメータ・セットにおける任意的なパラメータは次のものを含む。
【００６１】
camera_parameters_present_flagが1に等しいことは、以下のように投影マトリクス（projection  matrix）が信号伝達される（signaled）ことを示す。
【００６２】
camera_parameters  カメラ・パラメータが3×4の投影マトリクスPの形で伝達されると想定すると、これは3Dの世界における点を2D画像座標にマッピングするために使うことができる：I＝P*[Xw：Yw：Zw：1]。ここで、Iは斉次座標（homogeneous  coordinates）においてI＝[λ・Ix：λ・Iy：λ]である。
【００６３】
各エレメントのcamera_parameters_*_*は、IEEE単精度浮動小数点（32ビット）規格に従って表現できる。
【００６４】
この情報を別個のパラメータ・セットに入れる利点は、MPEG-4/AVC規格と互換なシーケンス・パラメータ・セット（SPS）および映像パラメータ・セット（PPS）がいまだに維持されるということである。この情報をシーケンス・パラメータ・セットまたはピクチャー・パラメータ・セットに入れると、各ビューについて、別個のシーケンス・パラメータ・セットおよび映像パラメータ・セットを送る必要がある。これは制限が強すぎる。また、この情報は、シーケンス・パラメータ・セットにも映像パラメータ・セットにもうまくフィットしない。もう一つの理由は、MPEG-4/AVC規格互換の基本ビューをもつことを提案するので、そのようなビューのための別個の（MPEG-4/AVC互換な）シーケンス・パラメータ・セットおよび映像パラメータ・セットならびに他のすべてのビューのためのシーケンス・パラメータ・セット／映像パラメータ・セットを使う必要があるということである。
【００６５】
シーケンスのまさに最初においてすべての依存性情報を単一のビュー・パラメータ・セットに入れることは、非常に有益である。デコーダは、いったんビュー・パラメータ・セットを受領すれば、その依存性情報のすべてを使ってマップを作成できる。これは、スライスを一つも受け取らないうちに、特定のビューをデコードするためにどのビューが必要とされるかを知ることを可能にする。この結果として、view_idを得るためにスライス・ヘッダをパースして（parse）、このビューがユーザーによって示された目標ビューをデコードするのに必要とされているかどうかを判定するだけでよい。こうして、フレームをバッファリングしたり、特定のビューをデコードするためにどのフレームが必要とされているかを決定するのにある時点まで待ったりする必要はない。
【００６６】
依存性情報および基本ビューであるかどうかは、ビュー・パラメータ・セットにおいて示される。MPEG-4/AVC互換の基本ビューでさえ、そのビューに固有の情報（たとえば、カメラ・パラメータ）が関連付けられている。この情報は、ビュー補間／合成を含むいくつかの目的のために他のビューによって使用されてもよい。我々は、MPEG-4/AVC互換ビューを一つのみサポートすることを提案する。というのも、複数のMPEG-4/AVC互換ビューがある場合、そのような各スライスについて、それがどのビューに属しているかを識別するのが難しくなり、非マルチビュー・ビデオ符号化デコーダが簡単に混乱することがありうるからである。
【００６７】
そのようなビューはただ一つに制限することにより、非マルチビュー・ビデオ符号化デコーダはビューを正しくデコードでき、マルチビュー・ビデオ符号化デコーダはシンタックスavc_compatible_view_idを使ってビュー・パラメータ・セットからそのようなビューを簡単に識別できることが保証される。他のすべての基本ビュー（非MPEG-4/AVC互換）は、is_base_view_flagを使って同定できる。
【００６８】
マルチビュー・ビデオ符号化スライスのための新しいスライス・ヘッダが提案される。ビュー・スケーラビリティ、ビュー・ランダム・アクセスなどをサポートするために、現在スライスがどのビューに依存しているかを知る必要がある。ビュー合成およびビュー補間のためには、潜在的にはカメラ・パラメータも必要とすることがありうる。この情報は、表１で上に示したようなビュー・パラメータ・セット中に存在する。ビュー・パラメータ・セットは、view_parameter_set_idを使って識別される。我々は、view_parameter_set_idを、表３に示されるように、すべての非MPEG-4/AVC互換スライスのスライス・ヘッダ内に加えることを提案する。ビュー補間／合成、ビュー・ランダム・アクセス、並列処理などを含むいくつかのマルチビュー・ビデオ符号化要件のためにview_id情報が必要とされる。この情報は、ビュー横断（cross-view）予測にのみ関係する特殊な符号化モードにも有用でありうる。このビューについてのビュー・パラメータ・セットから対応するパラメータを見出すために、view_idをスライス・ヘッダにおいて送る必要がある。
【００６９】
【表４】
2009543514.tif 000006
新しいマルチビュー・ビデオ符号化スライスのために、我々は、各スライス型（瞬時デコード・リフレッシュ（IDR）および非IDR）について新しいNALユニット型を作成することを提案する。我々は、表２に示されるように、IDRスライスのために型22を、非IDRスライスのために型23を使うことを提案する。
【００７０】
view_parameter_set_idは使用中のビュー・パラメータ・セットを指定する。view_parameter_set_idの値は0から255の範囲とする。
【００７１】
view_idは現在ビューのビューIDを示す。view_ idの値は0から255の範囲とする。
【００７２】
ビュー・ランダム・アクセスの例についてこれから本願の原理のある実施形態に従って記述する。
【００７３】
ビュー・ランダム・アクセスはマルチビュー・ビデオ符号化要件である。目標は、最小のデコード努力で任意のビューへのアクセスを得ることである。図３に示される予測構造についてのビュー・ランダム・アクセスの簡単な例を考えよう。
【００７４】
ユーザーがビューS3をデコードすることを要求するとする。図３から、このビューはビューS0、ビューS2およびビューS4に依存していることが見て取れる。例示的なビュー・パラメータ・セットが以下に例解される。
【００７５】
ビューについてのview_idはスライス・ヘッダ・シンタックスにおいて0から7まで連続的に番号付けられており、view_parameter_setが0に等しいビュー・パラメータ・セットは一つしか存在しないと想定しよう。number_of_views_minus_1は7に設定されている。avc_compatible_view_idは0に設定されることができる。
【００７６】
ビューS0については、is_base_view_flagは1に設定され、他のビューについては0に設定される。S0、S1、S2、S3およびS4についての依存性マップは、表４Ａ（S0のanchor_picture_dependency_mapについての依存性テーブル）および表４Ｂ（S0のnon_anchor_picture_dependency_mapについての依存性テーブル）に示されるように見えるであろう。他のビューについての依存性マップは同様の仕方で書ける。
【００７７】
ひとたびこのテーブルがデコーダで利用可能になると、デコーダは、受信するスライスが特定のビューをデコードするために必要とされているかどうかを、簡単に決定できる。デコーダはスライス・ヘッダをパースして現在スライスのview_idを決定する必要があるだけで、目標ビューS3について、二つのテーブル（表４Ａおよび表４Ｂ）におけるS3の列を索表して現在スライスを保持すべきかどうかを決定できる。デコーダは、アンカー映像と非アンカー映像との間の区別をする必要がある。というのも、表４ａおよび表４ｂから見て取れるように、両者が異なる依存性をもつことがあるからである。目標ビューS3については、ビューS0、S2およびS4のアンカー映像をデコードする必要があるが、ビューS2およびS4の非アンカー映像をデコードする必要があるのみである。
【００７８】
【表５】
2009543514.tif 000007
図４に目を向けると、マルチビュー・ビデオ・コンテンツの複数のビューをエンコードする例示的な方法が概括的に参照符号４００によって示されている。
【００７９】
方法４００は、開始ブロック４０５を含む。これは制御を機能ブロック４１０に渡す。機能ブロック４１０は前記複数のビューをエンコードするために使われるべきエンコード・パラメータのための構成設定ファイルを読み、制御を機能ブロック４１５に渡す。この機能ブロックはNをエンコードされるべきビューの数に等しく設定し、制御を機能ブロック４２０に渡す。機能ブロック４２０は、number_of_views_minus_1をN−1に等しく設定し、avc_compatible_view_idをMPEG-4/AVC互換ビューのview_idに等しく設定し、制御を機能ブロック４２５に渡す。機能ブロック４２５は、view_parameter_set_idを有効な整数に等しく設定し、変数iを0に等しく設定し、制御を判断ブロック４３０に渡す。判断ブロック４３０は、iがNより大きいかどうかを判定する。もしそうであれば、制御は判断ブロック４３５に渡される。そうでなければ、制御は機能ブロック４７０に渡される。
【００８０】
判断ブロック４３５は、現在ビューが基本ビューであるかどうかを判定する。もしそうであれば、制御は機能ブロック４４０に渡される。それ以外の場合には制御は機能ブロック４８０に渡される。
【００８１】
機能ブロック４４０はis_base_view_flag[i]を1に等しく設定し、制御を判断ブロック４４５に渡す。判断ブロック４４５は、依存性が更新されているところかどうかを判定する。もしそうであれば、制御は機能ブロック４５０に渡される。それ以外の場合には、制御は機能ブロック４８５に渡される。
【００８２】
機能ブロック４５０は、dependency_update_flagを1に等しく設定し、制御を機能ブロック４５５に渡す。機能ブロック４５５は変数jを0に等しく設定し、制御を判断ブロック４６０に渡す。判断ブロック４６０は、jがNより小さいかどうかを判定する。もしそうであれば、制御は機能ブロック４６５に渡される。それ以外の場合には、制御は機能ブロック４８７に渡される。
【００８３】
機能ブロック４６５はanchor_picture_dependency_maps[i][j]およびnon_anchor_picture_dependency_maps[i][j]を、構成設定ファイルによって示される値に設定し、制御を機能ブロック４６７に渡す。機能ブロック４６７は変数jを1インクリメントし、制御を判断ブロック４６０に返す。
【００８４】
機能ブロック４７０は、カメラ・パラメータが存在するときはcamera_parameters_present_flagを1に等しく設定し、そうでない場合にはcamera_parameters_present_flagを0に等しく設定し、制御を判断ブロック４７２に渡す。判断ブロック４７２はcamera_parameters_present_flagが1に等しいかどうかを判定する。もしそうであれば、制御は機能ブロック４３２に渡される。それ以外の場合には、制御は機能ブロック４３４に渡される。
【００８５】
機能ブロック４３２は、カメラ・パラメータを書き込み、制御を機能ブロック４３４に渡す。
【００８６】
機能ブロック４３４はビュー・パラメータ・セット（VPS）またはシーケンス・パラメータ・セット（SPS）を書き込み、制御を終了ブロック４９９に渡す。
【００８７】
機能ブロック４８０はis_base_view_flag[i]を0に等しく設定し、制御を判断ブロック４４５に渡す。
【００８８】
機能ブロック４８５はdependency_update_flagを0に等しく設定し、制御を機能ブロック４８７に渡す。機能ブロック４８７は変数iを1インクリメントし、制御を判断ブロック４３０に返す。
【００８９】
図５に目を転ずると、マルチビュー・ビデオ・コンテンツの複数のビューをデコードする例示的な方法が、概括的に参照符号５００によって示されている。
【００９０】
方法５００は、開始ブロック５０５を含み、これは制御を機能ブロック５１０に渡す。機能ブロック５１０はシーケンス・パラメータ・セット（SPS）またはビュー・パラメータ・セット（VPS）、view_parameter_set_id、number_of_views_minus_1、avc_compatible_view_idをパースし、変数iおよびjを0に等しく設定し、Nをnumber_of_views_minus_1に等しく設定し、制御を判断ブロック５１５に渡す。判断ブロック５１５は、iがN以下であるかどうかを判定する。もしそうであれば、制御は機能ブロック５７０に渡される。それ以外の場合には、制御は機能ブロック５２５に渡される。
【００９１】
機能ブロック５７０はcamera_parameters_present_flagをパースし、制御を判断ブロック５７２に渡す。判断ブロック５７２は、camera_parameters_present_flagが1に等しいかどうかを判定する。もしそうであれば、制御は機能ブロック５７４に渡される。それ以外の場合には、制御は機能ブロック５７６に渡される。
【００９２】
機能ブロック５７４はカメラ・パラメータをパースし、制御を機能ブロック５７６に渡す。
【００９３】
機能ブロック５７６はデコードを続け、制御を終了ブロック５９９に渡す。
機能ブロック５２５はis_base_view_flag[i]およびdependency_update_flagをパースし、制御を判断ブロック５３０に渡す。判断ブロック５３０は、dependency_update_flagが0に等しいかどうかを判定する。もしそうであれば、制御は機能ブロック５３２に渡される。それ以外の場合には、制御は判断ブロック５３５に渡される。
【００９４】
機能ブロック５３２はiを1インクリメントし、制御を判断ブロック５１５に返す。
【００９５】
判断ブロック５３５はjがN以下かどうかを判定する。もしそうであれば、制御は機能ブロック５４０に渡される。それ以外の場合には制御は機能ブロック５３７に渡される。
【００９６】
機能ブロック５４０はanchor_picture_dependency_maps[i][j]をパースし、制御を判断ブロック５４５に渡す。判断ブロック５４５はnon_anchor_picture_dependency_maps[i][j]が1に等しいかどうかを判定する。もしそうであれば、制御は機能ブロック５５０に渡される。それ以外の場合には制御は機能ブロック５４７に渡される。
【００９７】
機能ブロック５５０はnon_anchor_picture_dependency_maps[i][j]をパースし、制御を機能ブロック５４７に渡す。
【００９８】
機能ブロック５４７はjを1インクリメントし、制御を判断ブロック５３５に渡す。
【００９９】
機能ブロック５３７はiを1インクリメントし、制御を機能ブロック５１５に渡す。
【０１００】
以上の実施形態は、バッファリングの必要なしのランダム・アクセスに取り組む効率的な方法を提供する。これらの方法は、あるピクチャー・グループ（GOP）から他のピクチャー・グループへと依存構造が変化しない場合によく機能する。しかしながら、依存性が変化するケースが生じる場合には、前記方法は破綻しうる。この概念は図６Ａおよび６Ｂに示されている。
【０１０１】
図６Ａを見ると、のちのアンカー・スロットと同じ依存性をもつ非アンカー・フレームにおける例示的な依存性変化を示す図が概括的に参照符号６００によって示されている。図６Ｂを見ると、前のアンカー・スロットと同じ依存性をもつ非アンカー・フレームにおける例示的な依存性変化を示す図が概括的に参照符号６５０によって示されている。
【０１０２】
図６Ａに示されるように、GOP1ではI映像（イントラ符号化映像）はビュー0内に位置しているが、GOP2ではI映像の位置はビュー1に変わる。GOP1内のアンカー・フレームの依存構造がGOP2とは異なっていることが明らかに見て取れる。前記二つのアンカー・スロット間にあるフレームは、GOP2のアンカー・フレームと同じ依存構造をもつことも見て取れる。結果として、両GOPについてのVPSは異なってくる。ランダム・アクセスが、依存構造が前の依存構造から変化した部分で開始され、かつバッファリングが行われない場合、ランダム・アクセス・ビューのために必要とされないフレームを破棄するために、前の依存構造が使用されることになる。二つのGOPにおいて依存構造が異なっているので、これは問題である。
【０１０３】
したがって、本願の原理のさまざまな他の実施形態に基づき、我々は、これまでの実施形態において提案されたのとは異なる方法および装置を提案する。以下で述べる実施形態は、異なるGOPの間で時間とともに依存性が変化するケースに対処する。依存構造は、いくつかの理由のために変化できる。一つの理由は、異なるGOP上でのあるビューから別のビューへのI映像位置の変化である。これは、上記の図６Ａおよび６Ｂにおいて示されている。この場合、次のGOPの依存構造は前のGOPの依存構造とは異なっている。この情報は、新しいビュー・パラメータ・セットを使って伝達される必要がある。
【０１０４】
具体的には、この変化する依存構造に対処する二つの例示的な方法を提案する。第一の方法では、二つのアンカー時間スロットの間の依存構造を考慮に入れる。第一の方法では、ビューのサブセットをデコードするために必要とされるフレームを、依存構造が、あるアンカー時間スロットから別のアンカー時間スロットへと変化するときの、時間の間の依存構造に基づいて決定する。第二の方法では、依存構造が変化したGOPの依存構造を前の依存構造と組み合わせて、上記の問題に対処する新しい依存性マップを得る。これら二つの方法についてこれからさらに詳細に述べる。もちろん、本稿に記載される本願の原理の教示を与えられれば、当該技術分野および関連技術分野の当業者は、本願の原理の精神を維持しながら、時間とともに異なるピクチャー・グループの間で依存性が変化するときにマルチビュー・ビデオ・コンテンツをエンコードおよび／またはデコードするための、これらおよびさまざまな他の方法およびその変形を考えるであろう。
【０１０５】
第一の方法では、上記の問題を、二つのアンカー・スロット間にあるフレームの依存構造を考慮に入れることによって解決する。
【０１０６】
依存構造の選択は、エンコーダにおいて決定される。二つのGOPの間で依存構造の変化があるとき、二つのアンカー・スロットの中間にあるフレームは、前のアンカー・スロットまたは次のアンカー・スロットと同じ依存構造をもつ。これはやはりエンコーダによって決定される。二つの異なるオプションは図６Ａおよび６Ｂに示されている。
【０１０７】
あるビューのサブセットをデコードするために、あるいは特定のビューのランダム・アクセスのために、これら二つのアンカー・スロットの中間での依存構造を知ることが有用である。この情報が事前に知られれば、追加的な処理なしで、デコードのためにどのフレームが必要とされるかを判定することが容易になる。
【０１０８】
二つのアンカー・スロットの間のこの依存構造を決定するために、我々は、これらの非アンカー・フレームが、表示順における前のアンカー・スロットまたは次のアンカー・スロットのどちらの依存構造に従うかを示す新しいシンタックス要素を提案する。この信号／フラグは、ビットストリームにおける高レベルにおいて存在すべきである。この情報は、帯域内で（in-band）または帯域外で（out-of-band）伝送できる。
【０１０９】
ある例示的な実施形態では、この信号／フラグは、MPEG-4/AVC規格のMVC拡張のビュー・パラメータ・セットまたはシーケンス・パラメータ・セットにおいて存在できる。例示的な信号／フラグが表５Ａおよび５Ｂに示される。
【０１１０】
【表６】
2009543514.tif 000008
本実施形態では、previous_anchor_dep_struct_flagが0に等しいことは、その非アンカー・フレームが次のアンカー・スロットの依存構造に従うことを示し、previous_anchor_dep_struct_flagが1に等しいことは、その非アンカー・フレームが前の（previous）アンカー・スロットの依存構造（dependency  structure）に従うことを示す。
【０１１１】
ランダム・アクセスまたはサブセット・ビュー・デコードのプロセスは、このフラグに依存することになる。このフラグが1に設定されているとき、図６Ｂにおいて示されるように、非アンカー・フレームが表示順において前のアンカー・スロットの依存構造に従うことが、デコーダに伝達される。
【０１１２】
これが該当する場合、デコーダは、いかなるフレームもバッファリングする必要がないことを知る。ある例示的な実施形態では、ビューのランダム・アクセスのためにデコーダによって実行される方法は、以下の通りであり、図６Ｂからも見て取れる。ランダム・アクセスはビュー2および時間T6について要求されているとする。
【０１１３】
依存構造があるGOPから別のGOPへと変化するケースに向けられる第一の方法についてこれから概括的に記載する。これについてのさらなる記載が図７に関して続く。以下のステップは、課された順序付け（imposed  ordering）に関して記載される。しかしながら、この順序付けが例示および明快のためであることは理解しておくべきである。したがって、本稿で与えられる本願の原理の教示が与えられれば、本願の原理の範囲を維持しながら、当該技術分野および関連技術分野の当業者によって容易に決定されるように、そのような順序付けは再配列され、および／または他の仕方で修正されうる。
【０１１４】
第１ステップでは、目標ビュー（ビュー2）について、T6より早い最も近いI映像を位置特定する。第２ステップでは、このI映像に対応するアンカー・スロットについての依存構造を、表７Ａを見て決定する。第３ステップでは、previous_anchor_dep_struct_flagが0に設定されていると判定される場合、そのアンカー映像をこのスロット内でバッファリングする。それ以外の場合には、表７Ａから、どの映像がデコードされる必要があるかを決定する。第４ステップでは、GOP2のアンカー・スロットのために、表７Ｃを見て、目標ビューをデコードするためにどの映像が必要とされているかを決定する。previous_anchor_dep_struct_flagが0に等しい場合、以下の第５、第６および第７ステップをたどって、前のアンカー・スロットからのどのフレームがデコードされる必要があるかを決定する。それ以外の場合には、第８ステップに続く。第５ステップにおいて、目標ビュー（ビュー2）について、アンカー依存性テーブル（表６Ｃ）において、どのビュー（ビュー1）が必要とされているかを検査する。第６ステップでは、目標ビュー（ビュー2）について必要とされる各ビュー（ビュー1）について、そのVPSの依存性テーブル（表６Ａ）を見て、どのビュー（ビュー0、ビュー2）が必要とされているかを検査する。第７ステップでは、前記ビュー（ビュー0、ビュー2）からのアンカー・フレームを、それらのフレームが目標ビュー／時間より時間的に先行するI映像のビュー・パラメータ・セット（VPS）をポイントしているなら、デコードする。第８ステップでは、すべての非アンカーについてどの映像が必要とされているかを決定するために、previous_anchor_dep_struct_flagが1に設定されている場合、前のアンカー・スロットの依存構造を使って、目標ビューのためにどのフレームがデコードされる必要があるかを決定し；それ以外の場合には、次のアンカー・スロットの依存構造を使う。
【０１１５】
【表７】
2009543514.tif 000009
【０１１６】
【表８】
2009543514.tif 000010
図７に目を転じると、ランダム・アクセス点を使ってマルチビュー・ビデオ・コンテンツをデコードする例示的な方法が、参照符号７００によって概括的に示されている。
【０１１７】
本方法は、開始ブロック７０２を含む。これは制御を機能ブロック７０５に渡す。機能ブロック７０５はランダム・アクセス点を要求し、制御を機能ブロック７１０に渡す。機能ブロック７１０は、前記のランダム・アクセス時間より早い最も近いI映像（A）を位置特定し、制御を機能ブロック７１５に渡す。機能ブロック７１５は、アンカー・スロットAについての依存構造を決定し、制御を判断ブロック７２０に渡す。判断ブロック７２０は、previous_anchor_dep_struct_flagが0に等しいかどうかを判定する。もしそうであれば、制御は機能ブロック７４０に渡される。それ以外の場合には、制御は機能ブロック７２５に渡される。
【０１１８】
機能ブロック７４０は、この時間スロットに対応するすべてのアンカー映像をバッファリングすることを開始し、制御を機能ブロック７４５に渡す。機能ブロック７４５は、前記のランダム・アクセス時間より遅い最も近いI映像（B）を位置特定し、制御を判断ブロック７５０に渡す。判断ブロック７５０は、依存性マップがI映像（A）およびI映像（B）について異なっているかどうかを判定する。もしそうであれば、制御は機能ブロック７５５に渡される。それ以外の場合には、制御は機能ブロック７７５に渡される。
【０１１９】
機能７５５は、目標ビューについて、前記アンカー依存性マップを検査して、どのビューが必要とされているかを見て、制御を機能ブロック７６０に渡す。機能ブロック７６０は、上記のマップから必要とされる各ビューについて、対応するビュー・パラメータ・セット（VPS）からの依存性テーブルを見ることによって、どのビューが必要かを検査し、制御を機能ブロック７６５に渡す。機能ブロック７６５は、機能ブロック７６０によって同定される必要とされるビューのアンカー・フレームをデコードし、制御を機能ブロック７７０に渡す。機能ブロック７７０は、他のすべてのフレームについてI映像（B）によって示される依存性マップを使い、制御を終了ブロック７９９に渡す。
【０１２０】
機能ブロック７２５は、依存性グラフ（dependency  graph）から目標ビューをデコードするためにどの映像が必要とされているかを判定し、機能ブロック７３０に渡す。機能ブロック７３０は、次のアンカー・スロットについて、対応する依存性グラフを見ることによって必要とされる映像を決定し、制御を機能ブロック７３５に渡す。機能ブロック７３５は、非アンカー映像について、前記のランダム・アクセス点に先行するアンカー・スロットの依存性グラフを使って、デコードに必要とされる映像を決定し、制御を終了ブロック７９９に渡す。
【０１２１】
機能ブロック７７５は、依存性テーブルを読み、要求されたビューをデコードするために必要とされないフレームを破棄し、制御を終了ブロック７９９に渡す。
【０１２２】
依存構造があるGOPから別のGOPへと変化するケースに向けられる第二の方法についてこれから概括的に記載する。これについてのさらなる記載が図８に関して続く。以下のステップは、課された順序付け（imposed  ordering）に関して記載される。しかしながら、この順序付けが例示および明快のためであることは理解しておくべきである。したがって、本稿で与えられる本願の原理の教示が与えられれば、本願の原理の範囲を維持しながら、当該技術分野および関連技術分野の当業者によって容易に決定されるように、そのような順序付けは再配列され、および／または他の仕方で修正されうる。
【０１２３】
上述したように、第一の方法では、依存構造があるGOPから別のGOPにかけて変化する上記の問題を解決するのに、二つのGOPの依存構造を、正しいフレームが破棄されるように組み合わせる。ランダム・アクセスのプロセスは図６Ａを使って示されている。
【０１２４】
アンカー映像および非アンカー映像についてのGOP1およびGOP2についての依存性マップは表６Ａ、６Ｂ、６Ｃおよび６Ｄに示されている。
【０１２５】
目標ビューがビュー2であり、目標時間はT6であるとする。このビューへのランダム・アクセスのためには、現在の目標ビュー／時間目標に（単に時間において）先行する最も近いI映像を位置特定する必要がある。このI映像のVPS-IDを記録し（note）、この時間区間におけるすべてのアンカー映像をバッファリングする。（単に時間において）後の次のI映像が到着するやいなや、VPS-IDが前のI映像と同じかどうかを検査する。IDが同じであれば、このVPSにおいて示されている依存構造を使って、どのフレームを保持し、どのフレームを破棄するかを決定する。
【０１２６】
VPS  IDが異なっている場合、以下のステップが実行されるべきである。第１ステップにおいて、目標ビュー（ビュー2）について、アンカー依存性テーブル（表６Ｃ）において、どのビュー（ビュー1）が必要とされているかを検査する。第２ステップでは、目標ビュー（ビュー2）について必要とされる各ビュー（ビュー1）について、そのVPSの依存性テーブル（表６Ａ）を見て、どのビュー（ビュー0、ビュー2）が必要とされているかを検査する。第３ステップでは、前記ビュー（ビュー0、ビュー2）からのアンカー・フレームを、それらのフレームが目標ビュー／時間より時間的に先行するI映像のVPSをポイントしているなら、デコードする。第４ステップでは、目標ビュー／時間より時間的に遅いI映像と同じVPS-IDをポイントするまたは使用するすべてのフレームについて、そのVPSにおいて示されている依存性マップ（表６Ｃ、６Ｄ）を使用する。
【０１２７】
この第二の方法は、たとえビュー間でI映像の位置が変わるときでも、効率的な仕方でランダム・アクセスができることを保証する。時間的にランダム・アクセス点より早い最も近いI映像に対応するアンカー映像をバッファリングする必要があるだけである。
【０１２８】
図８に目を向けると、ランダム・アクセス点を使ってマルチビュー・コンテンツをデコードするもう一つの例示的な方法が、概括的に参照符号８００によって示されている。
【０１２９】
方法８００は開始ブロック８０２を含み、このブロックは制御を機能ブロック８０５に渡す。機能ブロック８０５はランダム・アクセス点を要求し、制御を機能ブロック８１０に渡す。機能ブロック８１０は、ランダム・アクセス時間より早い最も近いI映像（A）を位置特定し、制御を機能ブロック８１５に渡す。機能ブロック８１５はこの時間スロットに対応するすべてのアンカー映像をバッファリングすることを開始し、制御を機能ブロック８２０に渡す。機能ブロック８２０は、ランダム・アクセス時間より遅い最も近いI映像（B）を位置特定し、制御を判断ブロック８２５に渡す。判断ブロック８２５は、I映像（A）とI映像（B）について依存性マップが異なっているかどうかを判定する。もしそうであれば、制御は機能ブロック８３０に渡される。それ以外の場合には制御は機能ブロック８５０に渡される。
【０１３０】
機能ブロック８３０は、目標ビューについて、前記アンカー依存性マップを検査して、どのビューが必要とされているかを見て、制御を機能ブロック８３５に渡す。機能ブロック８３５は、上記のマップから必要とされる各ビューについて、対応するビュー・パラメータ・セット（VPS）からの依存性テーブルを見ることによって、どのビューが必要かを検査し、制御を機能ブロック８４０に渡す。機能ブロック８４０は、機能ブロック８３５によって同定される必要とされるビューのアンカー・フレームをデコードし、制御を機能ブロック８４５に渡す。機能ブロック８４５は、他のすべてのフレームについてI映像（B）によって示される依存性マップを使い、制御を終了ブロック８９９に渡す。
【０１３１】
機能ブロック８５０は、依存性テーブルを読み、要求されたビューをデコードするために必要とされないフレームを破棄し、制御を終了ブロック８９９に渡す。
【０１３２】
図９に目を向けると、マルチビュー・ビデオ・コンテンツをエンコードする例示的な方法が概括的に参照符号９００によって示されている。
【０１３３】
方法９００は、機能ブロック９０５に制御を渡す開始ブロック９０２を含む。機能ブロック９０５は、エンコーダ構成設定ファイルを読み、制御を判断ブロック９１０に渡す。判断ブロック９１０は、非アンカー映像が前のアンカー映像の依存性に従っているかどうかを判定する。もしそうであれば、制御は機能ブロック９１５に渡される。それ以外の場合には、制御は機能ブロック９２０に渡される。
【０１３４】
機能ブロック９１５は、previous_anchor_dep_struct_flagを1に等しく設定し、制御を機能ブロック９２５に渡す。
【０１３５】
機能ブロック９２０は、previous_anchor_dep_struct_flagを0に等しく設定し、制御を機能ブロック９２５に渡す。
【０１３６】
機能ブロック９２５は、シーケンス・パラメータ・セット（SPS）、ビュー・パラメータ・セット（VPS）および／または映像パラメータ・セット（PPS）を書き込み、制御を機能ブロック９３０に渡す。機能ブロック９３０は、ビューの数（the  number  of  views）をNとし、変数iおよびjを0に等しくなるよう初期化し、制御を判断ブロック９３５に渡す。判断ブロック９３５は、iがNより小さいかどうかを判定する。もしそうであれば、制御は判断ブロック９４０に渡される。そうでない場合、制御は終了ブロック９９９に渡される。
【０１３７】
判断ブロック９４０は、jがビューi内の映像の数より小さいかどうかを判定する。もしそうであれば、制御は判断ブロック９４５に渡される。それ以外の場合には、制御は判断ブロック９３５に返される。
【０１３８】
判断ブロック９４５は、現在の映像がアンカー映像かどうかを判定する。もしそうであれば、制御は判断ブロック９５０に渡される。判断ブロック９５０は、依存性変化があるかどうかを判定する。もしそうであれば、制御は判断ブロック９５５に渡される。そうでなければ、制御は機能ブロック９８０に渡される。
【０１３９】
判断ブロック９５５は、非アンカー映像が前のアンカー映像の依存性に従っているかどうかを判定する。もしそうであれば、制御は機能ブロック９６０に渡される。それ以外の場合には、制御は機能ブロック９７０に渡される。
【０１４０】
機能ブロック９６０はprevious_anchor_dep_struct_flagを1に等しく設定し、制御を機能ブロック９７５に渡す。
【０１４１】
機能ブロック９７０は、previous_anchor_dep_struct_flagを0に等しく設定し、制御を機能ブロック９７５に渡す。
【０１４２】
機能ブロック９７５は、シーケンス・パラメータ・セット（SPS）、ビュー・パラメータ・セット（VPS）および／または映像パラメータ・セット（PPS）を書き込み、制御を機能ブロック９８０に渡す。
【０１４３】
機能ブロック９８０は現在の映像をエンコードし、制御を機能ブロック９８５に渡す。機能ブロック９８５は、変数jをインクリメントし、制御を機能ブロック９９０に渡す。機能ブロック９９０はframe_numおよび映像順カウント（POC:  Picture  Order  Count）をインクリメントし、制御を判断ブロック９４０に返す。
【０１４４】
ここで、本発明の多くの付随する利点／特徴のいくつかの記載を与えておく。そのいくつかはすでに上述されている。たとえば、一つの利点／特徴は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューについてのアンカー映像および非アンカー映像をエンコードするためのエンコーダを含む装置である。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【０１４５】
もう一つの利点／特徴は、上記のようなエンコーダをもつ装置であって、前記エンコーダが前記依存構造を帯域内または帯域外の少なくとも一方で信号伝達する（signal）ものである。
【０１４６】
さらにもう一つの利点／特徴は、上記のようなエンコーダをもつ装置であって、前記エンコーダが前記依存構造を高レベルのシンタックスを使って信号伝達するものである。
【０１４７】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を信号伝達するエンコーダをもつ装置であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つにおいて信号伝達されるものである。
【０１４８】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を信号伝達するエンコーダをもつ装置であって、前記依存構造がフラグを使って信号伝達されるものである。
【０１４９】
また、もう一つの利点／特徴は、上記のような、フラグを使って依存構造を信号伝達するエンコーダをもつ装置であって、フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表されるものである。
【０１５０】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を信号伝達するエンコーダをもつ装置であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われるものである。
【０１５１】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を信号伝達するエンコーダをもつ装置であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われるものである。
【０１５２】
また、もう一つの利点／特徴は、マルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューのためのアンカーおよび非アンカー映像をデコードするためのデコーダをもつ装置である。前記少なくとも二つのビューの少なくとも一つにおける、表示順において前のアンカー映像と次のアンカー映像の間に配される非アンカー映像のセットにおける各非アンカー映像の依存構造は、表示順における前記前のアンカー映像または前記次のアンカー映像と同じである。
【０１５３】
さらに、もう一つの利点／特徴は、上記のようなデコーダをもつ装置であって、前記デコーダが前記依存構造を帯域内または帯域外の少なくとも一方で受領するものである。
【０１５４】
さらに、もう一つの利点／特徴は、上記のようなデコーダをもつ装置であって、前記デコーダが前記依存構造を高レベルのシンタックスを使って判別するものである。
【０１５５】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を判別するデコーダをもつ装置であって、前記依存構造が、シーケンス・パラメータ・セット、ビュー・パラメータ・セットおよび映像パラメータ・セットのうちの少なくとも一つを使って判別されるものである。
【０１５６】
また、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を判別するデコーダをもつ装置であって、前記依存構造がフラグを使って判別されるものである。
【０１５７】
さらに、もう一つの利点／特徴は、上記のような、フラグを使って依存構造を判別するデコーダをもつ装置であって、フラグがprevious_anchor_dep_struct_flagシンタックス要素によって表されるものである。
【０１５８】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を判別するデコーダをもつ装置であって、前記依存構造が、非アンカー映像の前記セットを少なくとも部分的にデコードするために前記少なくとも二つのビューの任意のものにおける他のどの映像が使われるべきかを決定するために使われるものである。
【０１５９】
さらに、もう一つの利点／特徴は、上記のような、高レベルのシンタックスを使って依存構造を判別するデコーダをもつ装置であって、前記依存構造が、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスの間に非アンカー映像の前記セットをデコードするために、前記少なくとも二つのビューにおける他のどの映像が使われるべきかを決定するために使われるものである。
【０１６０】
また、もう一つの利点は、上記のようなデコーダをもつ装置であって、前記デコーダが、前記少なくとも二つのビューの前記少なくとも一つへのランダム・アクセスのために前記少なくとも二つのビューにおけるアンカー映像のどれをバッファリングするべきかを、前記依存構造が表示順において前のアンカー映像または次のアンカー映像のどちらに従うかに基づいて、決定するものである。
【０１６１】
さらに、もう一つの利点／特徴は、上記のような、ランダム・アクセスのために前記少なくとも二つのビューにおけるアンカー映像のどれをバッファリングするべきかを決定するデコーダをもつ装置であって、前記デコーダが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より後に配されているアンカー映像と同じであるとき、ランダム・アクセス点より前に配されているアンカー映像をバッファリングのために選択するものである。
【０１６２】
さらに、もう一つの利点／特徴は、上記のような、ランダム・アクセスのために前記少なくとも二つのビューにおけるアンカー映像のどれをバッファリングするべきかを決定するデコーダをもつ装置であって、前記デコーダが、非アンカー映像の前記セット内の非アンカー映像の依存構造が表示順においてランダム・アクセス点より前に配されているアンカー映像と同じであるとき、ランダム・アクセス点より前に配されているアンカー映像をバッファリングから省略するものである。
【０１６３】
さらに、もう一つの利点／特徴は、ビットストリームからのマルチビュー・ビデオ・コンテンツに対応する少なくとも二つのビューをデコードするためのデコーダをもつ装置である。前記少なくとも二つのビューの一つまたは複数に対応する少なくとも二つのピクチャー・グループ（Groups  of  Pictures）は、異なる依存構造（dependency  structure）をもつ。デコーダは、前記少なくとも二つのビューにおいて、前記少なくとも二つのビューの少なくとも一つへのランダム・アクセスのためにデコードされる必要がある映像を、少なくとも一つの依存性マップに基づいて、選択する。
【０１６４】
また、もう一つの利点／特徴は、上記のようなデコーダをもつ装置であって、ランダム・アクセスが、ランダム・アクセスより表示順において早い、最も近いイントラ符号化された映像において始まるものである。
【０１６５】
さらに、もう一つの利点／特徴は、上記のような、ランダム・アクセスが、ランダム・アクセスより表示順において早い、最も近いイントラ符号化された映像において始まるデコーダをもつ装置であって、前記ビットストリームがアンカー映像および非アンカー映像を含み、前記デコーダが、前記少なくとも二つのビューにおいて、ランダム・アクセスより早い前記最も近いイントラ符号化された映像に時間的に対応するアンカー映像をバッファリングするものである。
【０１６６】
さらに、もう一つの利点／特徴は、上記のようなデコーダをもつ装置であって、ランダム・アクセスが、ランダム・アクセスより遅い、最も近いイントラ符号化された映像において始まるものである。
【０１６７】
さらに、もう一つの利点／特徴は、上記のようなデコーダをもつ装置であって、前記少なくとも一つの依存性マップが、前記ランダム・アクセスに対してより早いイントラ符号化された映像およびより遅いイントラ符号化された映像の依存性マップを含み、前記デコーダが、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップを比較することによって必要とされる映像を選択するものである。
【０１６８】
また、もう一つの利点／特徴は、上記のような、依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが同じであるものである。
【０１６９】
さらに、もう一つの利点／特徴は、上記のような、同じである依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップのうち任意のものが必要とされる映像を決定するために使われるものである。
【０１７０】
さらに、もう一つの利点／特徴は、上記のような、依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記より早いイントラ符号化された映像および前記より遅いイントラ符号化された映像の依存性マップが異なるものである。
【０１７１】
さらに、もう一つの利点／特徴は、上記のような、異なる依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記少なくとも一つの依存性マップが、少なくとも一つのアンカー映像依存性マップを含み、前記デコーダが、前記少なくとも二つのビューのうちの前記少なくとも一つが、前記少なくとも二つのビューのどれに依存しているかを判定するために、前記少なくとも一つのアンカー映像依存性マップを検査するものである。
【０１７２】
また、もう一つの利点／特徴は、上記のような、異なる依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存するそれぞれについて、前記デコーダがそれに対応する依存性テーブルを検査するものである。
【０１７３】
さらに、もう一つの利点／特徴は、上記のような、異なる依存性マップを比較することおよび依存性テーブルによって必要とされる映像を選択するデコーダをもつ装置であって、前記アンカー映像が、前記少なくとも二つのビューのうち、前記少なくとも二つのビューの前記少なくとも一つが依存するそれぞれからデコードされるものである。
【０１７４】
さらに、もう一つの利点／特徴は、上記のような、異なる依存性マップを比較することによって必要とされる映像を選択するデコーダをもつ装置であって、前記デコーダが、前記より遅いイントラ符号化された映像と同じ依存性マップを使う何らかの特定の映像が前記ランダム・アクセスのためにデコードされることが必要とされるかどうかを、前記少なくとも二つのピクチャー・グループの一つについての変化した依存構造および前記少なくとも二つのピクチャー・グループの別の一つについての変化していない依存構造の組み合わせから形成される依存性マップに基づいて判定するものである。
【０１７５】
本願の原理のこれらおよびその他の特徴および利点は、本稿の教示に基づいて、当業者によって容易に見きわめられうる。本願のゲイン理の教示がさまざまな形のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサまたはそれらの組み合わせにおいて実装されうることは理解しておくべきである。
【０１７６】
最も好ましくは、本願の原理の教示は、ハードウェアおよびソフトウェアの組み合わせとして実装される。さらに、ソフトウェアは、プログラム記憶ユニット上に具体的に具現されたアプリケーション・プログラムとして実装されてもよい。該アプリケーション・プログラムは、いかなる好適なアーキテクチャをもつ機械にアップロードされ、これによって実行されてもよい。好ましくは、前記機械は、一つまたは複数の中央処理ユニット（「CPU」）、ランダム・アクセス・メモリ（「RAM」）および入出力（「I/O」）インターフェースといったハードウェアをもつコンピュータ・プラットフォーム上で実装される。該コンピュータ・プラットフォームはまた、オペレーティング・システムおよびマイクロ命令コードを含んでいてもよい。本稿に記載されるさまざまなプロセスおよび機能は、マイクロ命令コードの一部もしくはアプリケーション・プログラムの一部またはそれらのいかなる組み合わせであってもよく、CPUによって実行されうる。さらに、追加的なデータ記憶ユニットおよび印刷ユニットといったさまざまな他の周辺ユニットがコンピュータ・プラットフォームに接続されていてもよい。
【０１７７】
さらに、付属の図面に描かれている構成するシステム・コンポーネントおよび方法の一部は好ましくはソフトウェアにおいて実装されるので、システム・コンポーネントまたはプロセス機能ブロック間の実際の接続は、本願の原理がプログラムされる仕方に依存して異なりうることは理解しておくべきである。本稿の教示を与えられれば、当業者は本願の原理のこれらおよび同様の実装または構成を考えることができるであろう。
【０１７８】
例示的な実施形態は付属の図面を参照して本稿で記載されてきたが、本願の原理がこれらの厳密な実施形態に限定されないこと、本願の原理の範囲および精神から外れることなく当業者はそれにさまざまな変更および修正をなしうることは理解しておくべきである。そのようなすべての変更および修正は、付属の請求項に記載される本願の原理の範囲内に含められることが意図される。
【図面の簡単な説明】
【０１７９】
【図１】本願の原理のある実施形態に基づく、本願の原理が適用されうる例示的なマルチビュー・ビデオ符号化（MVC）エンコーダのブロック図である。
【図２】本願の原理のある実施形態に基づく、本願の原理が適用されうる例示的なマルチビュー・ビデオ符号化（MVC）デコーダのブロック図である。
【図３】本願の原理のある実施形態に基づく、階層的B映像（hierarchical  B  pictures）を使った、MPEG-4/AVC規格に基づく、インター・ビュー時間的予測（inter-view-temporal  prediction）構造を示す図である。
【図４】本願の原理のある実施形態に基づく、マルチビュー・ビデオ・コンテンツの複数ビューをエンコードする例示的な方法の流れ図である。
【図５】本願の原理のある実施形態に基づく、マルチビュー・ビデオ・コンテンツの複数ビューをデコードする例示的な方法の流れ図である。
【図６Ａ】本願の原理のある実施形態に基づく、本願の原理が適用されうる、のちのアンカー・スロットと同じ依存性をもつ非アンカー・フレームにおける例示的な依存性変化を示す図である。
【図６Ｂ】本願の原理のある実施形態に基づく、本願の原理が適用されうる、前のアンカー・スロットと同じ依存性をもつ非アンカー・フレームにおける例示的な依存性変化を示す図である。
【図７】本願の原理のある実施形態に基づく、ランダム・アクセス点を使った、マルチビュー・ビデオ・コンテンツをデコードする例示的な方法の流れ図である。
【図８】本願の原理のある実施形態に基づく、ランダム・アクセス点を使った、マルチビュー・コンテンツをデコードするもう一つの例示的な方法の流れ図である。
【図９】本願の原理のある実施形態に基づく、マルチビュー・ビデオ・コンテンツをエンコードする例示的な方法の流れ図である。
【図１】
2009543514.tif 000011
【図２】
2009543514.tif 000012
【図３】
2009543514.tif 000013
【図４】
2009543514.tif 000014
【図５】
2009543514.tif 000015
【図６Ａ】
2009543514.tif 000016
【図６Ｂ】
2009543514.tif 000017
【図７】
2009543514.tif 000018
【図８】
2009543514.tif 000019
【図９】
2009543514.tif 000020
【国際調査報告】
2009543514.tif 000021
2009543514.tif 000022