JP5610552B2 - マルチビュービデオ符号化の方法および装置 - Google Patents

Description

本出願は、参照により本明細書に組み込まれている、２００６年１月９日に出願した米国仮出願第６０／７５７，２８９号、名称「Multi-View Video Coding System」の利益を主張するものである。さらに、本出願は、同一出願人により、全体として参照により本明細書に組み込まれ、本明細書と同時出願した、整理番号ＰＵ０６０００４、名称「Methods and Apparatus for Multi-View Video Coding」と関連するものである。

本発明は、概してビデオエンコーダおよびデコーダに関するものであり、より詳細にはマルチビュービデオ符号化の方法および装置に関するものである。

マルチビュービデオ符号化（ＭＶＣ）は、マルチビューシーケンスを符号化するための圧縮の構成である。マルチビュービデオ符号化（ＭＶＣ）のシーケンスは、同じシーンを異なるビューポイントから取り込む２つ以上のビデオシーケンスのセットである。

マルチビュービデオ符号化は、自由ビューポイントおよび３Ｄビデオアプリケーションを含む様々なアプリケーション、家庭用娯楽、並びに、監視に役立つ重要な技術であることが、広く認められてきた。このマルチビュービデオアプリケーションでは、含まれるビデオデータ量が膨大である。したがって、個々のビューを同時に放送している現在のビデオ符号化ソリューションの符号化効率を向上させるために、効率的な圧縮技術の必要性がある。

近年、多眼ビデオ（stereoscopic video）を圧縮する効率的な方法の設計に、多大な労力が注がれている。従来の単眼圧縮法（monoscopic compression methods）は、多眼画像の対の左右のビューに個々に適用されることが可能である。しかしながら、高いビュー間の相関関係が活用されれば、さらに高圧縮率を達成することができる。

多眼画像の対の両方のビューが符号化される従来技術の手法に関しては、国際標準化機構／国際電気標準会議（ＩＳＯ／ＩＥＣ）の動画専門家グループ２（ＭＰＥＧ−２；Moving Picture Experts Group-2）標準で、一対のビデオ信号を転送するために、マルチビュープロファイル（ＭＶＰ）が定義された。ＭＶＰは、多階層信号表現手法に依拠し、一方のビュー（多くの場合左のビュー）が基本階層に割り当てられ、もう一方のビューが上位階層に割り当てられる。基本階層には、メインプロファイル（ＭＰ）と同じツールを用いた単眼符号化が適用される。上位階層は、時間スケーラビリティツール（temporal scalability tool）と、動きフィールドおよび視差フィールドのハイブリッド予測とを用いて符号化される。

国際標準化機構／国際電気標準会議（（ＩＳＯ／ＩＥＣ）動画専門家グループ４（ＭＰＥＧ−４）のパート１０高度動画像圧縮符号化（ＡＶＣ；Advanced Video Coding）標準／国際電気通信連合の電気通信部門（ＩＴＵ−Ｔ）のＨ．２６４推奨（以下「ＭＰＥＧ−４ ＡＶＣ標準」）に関する従来技術の方法では、次の２つの異なる方法で、すなわち（ｉ）特定パリティのフィールドがすべて左のビューに割り当てられ、逆パリティのフィールドがすべて多眼視コンテンツの右のビューとみなされるインタレース画像符号化という特殊なケースとして、あるいは（ｉｉ）左右のビューからのフレームを交互にして、単一の単眼ビデオシーケンスを生成することによって、多眼ビデオの符号化を行うことができる。立体視付加拡張情報（stereovision supplemental enhancement information、ＳＥＩ）のメッセージは、符号化されたビデオシーケンスが多眼コンテンツを表すかどうか、対応するコンテンツの符号化にどの方法が用いられたかについてデコーダに表示される。

これまでに知られているこれらの方法には、既存の単眼符号化技術に最小限の変更が必要である。しかしながら、これらは、多眼の対の２つのビューの間に存在する冗長度を軽減する能力が限られている。結果として、多眼視の符号化は、単一の単眼視の符号化と比較すると大きなオーバーヘッドをもたらす。さらに、２つより多いカメラビューを符号化するための先行サポートがない。

従来技術のこれらのおよびその他の欠点および不都合は、マルチビュービデオ符号化の方法および装置に関する本発明によって対処される。

本発明の一態様によりビデオエンコーダが提供される。このビデオエンコーダは、２つのビュー間参照ピクチャのリスト（cross-view reference picture lists）のうちの少なくとも１つを用いてピクチャ中のブロックを符号化するエンコーダを含む。このピクチャは、マルチビュービデオコンテンツに対応し、同じまたは類似のシーンに対して異なるビューポイントを有するピクチャのセットのうちの１つである。このピクチャは、異なるビューポイントのうち現在のビューポイントを表す。２つのビュー間参照ピクチャのリストは、現在のビューポイント以外の異なるビューポイントのうちの１つを有する参照ピクチャに対応する。

本発明の別の態様によりビデオエンコーダが提供される。このビデオエンコーダは、同じまたは類似のシーンの異なるビューポイントのマルチビューコンテンツに対応する復号されたピクチャを格納する少なくとも１つのバッファを含む。

本発明のさらに別の態様によりビデオ符号化方法が提供される。この方法は、２つのビュー間参照ピクチャのリストのうちの少なくとも１つを用いてピクチャ中のブロックを符号化することを含む。このピクチャは、マルチビュービデオコンテンツに対応し、同じまたは類似のシーンに対して異なるビューポイントを有するピクチャのセットのうちの１つである。このピクチャは、異なるビューポイントのうち現在のビューポイントを表す。この２つのビュー間参照ピクチャのリストは、現在のビューポイント以外の異なるビューポイントのうちの１つを有する参照ピクチャに対応する。

本発明のさらに別の態様によりビデオ符号化方法が提供される。この方法は、少なくとも１つのバッファに、同じまたは類似のシーンの異なるビューポイントのマルチビューコンテンツに対応する復号されたピクチャを格納することを含む。

本発明のさらなる態様によりビデオデコーダが提供される。このビデオデコーダは、２つのビュー間参照ピクチャのリストのうちの少なくとも１つを用いてピクチャ中のブロックを復号するデコーダを含む。このピクチャは、マルチビュービデオコンテンツに対応し、同じまたは類似のシーンに対して異なるビューポイントを有するピクチャのセットのうちの１つである。このピクチャは、異なるビューポイントのうち現在のビューポイントを表す。この２つのビュー間参照ピクチャのリストは、現在のビューポイント以外の異なるビューポイントのうちの１つを有する参照ピクチャに対応する。

本発明のさらに別の態様によりビデオデコーダが提供される。ビデオデコーダは、同じまたは類似のシーンの異なるビューポイントのマルチビューコンテンツに対応する復号されたピクチャを格納する少なくとも１つのバッファを含む。

本発明の他の態様によりビデオ復号方法が提供される。この方法は、２つのビュー間参照ピクチャのリストのうちの少なくとも１つを用いてピクチャ中のブロックを復号することを含む。このピクチャは、マルチビュービデオコンテンツに対応し、同じまたは類似のシーンに対して異なるビューポイントを有するピクチャのセットのうちの１つである。このピクチャは、異なるビューポイントのうち現在のビューポイントを表す。この２つのビュー間参照ピクチャのリストは、現在のビューポイント以外の異なるビューポイントのうちの１つを有する参照ピクチャに対応する。

本発明のさらに他の態様によりビデオ復号方法が提供される。この方法は、同じまたは類似のシーンの異なるビューポイントのマルチビューコンテンツに対応する復号されたピクチャを格納する少なくとも１つのバッファを含む。

本発明のこれらのおよびその他の態様、特徴、並びに利点は、添付の図面と併せて読まれる次の例示的実施形態の詳細な説明から明らかになるであろう。

本原理の一実施形態により本原理が適用可能である例示的なマルチビュービデオ符号化（ＭＶＣ）エンコーダのブロック図である。 本原理の一実施形態により本原理が適用可能である例示的なマルチビュービデオ符号化（ＭＶＣ）デコーダのブロック図である。 本原理の一実施形態によりマルチビュービデオコンテンツの参照リストを構成する例示的方法の流れ図である。 本原理の一実施形態により時間／ビュー間モードの判定を行う例示的方法の流れ図である。 本原理の一実施形態により、マルチビュービデオコンテンツに対応する同じスライスに対して動きベクトルおよび視差ベクトルを処理する例示的方法の流れ図である。 本原理の一実施形態により、マルチビュービデオコンテンツに対して動きベクトルおよび視差ベクトルを処理する別の方法の流れ図である。

本発明は、添付の例示的な図と併せてよりよく理解されることが可能である。

本発明は、マルチビュービデオ符号化の方法および装置を対象とする。

本記述は、本発明の原理を説明する。したがって、当業者は、本明細書に明確に記載または表示されていないが、本発明の原理を実現し、本発明の趣旨と範囲内に含まれる様々な構成を考案することができるであろうと認識される。

本明細書に列挙したあらゆる例および仮定的用語は、読者が本発明の原理および発明者によって与えられる概念を理解して当技術を促進する助けとする教育上の目的のためであり、このような具体的に列挙した例および条件への限定ではないと解釈されたい。

さらに、本発明の原理、態様および実施形態、並びに、その特定の例を列挙する本明細書中のあらゆる記載は、その構造的均等物と機能的均等物を共に包含するものである。さらに、このような均等物は、現在知られている均等物および将来開発される均等物、すなわち構造にかかわらず同じ機能を行うように開発されるいかなる要素をも含むものである。

したがって、例えば、当業者には、本明細書に示したブロック図は本発明の原理を実現する例示的回路の概念図を表すことが理解されるであろう。同様に、コンピュータまたはプロセッサが明確に示されているかどうかにかかわらず、いかなるフローチャート、流れ図、状態遷移図、擬似コードなども、実質的にコンピュータ可読媒体で表示されてコンピュータまたはプロセッサによって実行されることが可能である様々なプロセスを表すことが理解されるであろう。

図に示した様々な要素の機能は、専用のハードウェア、および適切なソフトウェアと関連してソフトウェアを実行することができるハードウェアを使用して提供されることが可能である。プロセッサによって提供される場合、この機能は、単一の専用のプロセッサによって、単一の共有プロセッサによって、またはいくつかを共有することができる複数の個々のプロセッサによって、提供されることが可能である。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアを排他的に指すと解釈されるべきではなく、暗に、デジタル信号プロセッサ（「ＤＳＰ」）のハードウェア、ソフトウェアを格納するリードオンリーメモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、および不揮発記憶装置を含む場合がある。

また、従来型および／またはカスタム型の他のハードウェアを含む場合もある。同様に、図に示したいかなるスイッチも、単に概念上のものである。これらの機能は、プログラム論理の動作によって、専用論理によって、プログラム制御と専用論理の相互作用によって、または手動でも実行されることが可能であり、特定の技術は、状況からより具体的に理解されるように実装者によって選択可能である。

特許請求の範囲では、特定の機能を行う手段として表されるいかなる要素も、この機能を行ういかなる方法をも包含するものとし、例えば、ａ）この機能を実行する回路素子の組合せ、または、ｂ）この機能を実行する、ソフトウェアを実行するための適切な回路と結合される、ファームウェア、マイクロコードなどを含む任意の形態の該ソフトウェアを含む。このような特許請求の範囲によって定義される本発明は、説明される様々な手段によって提供される機能が、特許請求の範囲が要求する方法で組み合わされ、１つにまとめられるということに属する。したがって、これらの機能を提供することができるいかなる手段も、本明細書に示した手段と同等であるとみなす。

本明細書における、本原理の「１つの実施形態」または「一実施形態」への言及は、本実施形態と関連して説明した特定の特徴、構造、特性、その他が、本原理の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書にわたって様々な箇所で現れる「１つの実施形態では」または「一実施形態では」という語句は、必ずしもすべて同じ実施形態を指しているとは限らない。

図１を参照すると、全体として参照符号１００で例示的なマルチビュービデオ符号化（ＭＶＣ）エンコーダを示している。エンコーダ１００は、出力を変換器１１０の入力と通信（signal communication）で接続された結合器１０５を含む。変換器１１０の出力は、量子化器１１５の入力と通信で接続されている。量子化器１１５の出力は、エントロピ符号器１２０の入力および逆量子化器１２５の入力と通信で接続されている。逆量子化器１２５の出力は、逆変換器１３０の入力と通信で接続されている。逆変換器１３０の出力は、結合器１３５の第１の非反転入力と通信で接続されている。結合器１３５の出力は、イントラ予測器１４５の入力およびデブロッキングフィルタ１５０の入力と通信で接続されている。デブロッキングフィルタ１５０の出力は、（ビューｉ用）参照ピクチャ記憶装置１５５の入力と通信で接続されている。参照ピクチャ記憶装置１５５の出力は、動き補償器１７５の第１の入力および動き推定器１８０の第１の入力と通信で接続されている。動き推定器１８０の出力は、動き補償器１７５の第２の入力と通信で接続されている。

（その他のビュー用）参照ピクチャ記憶装置１６０の出力は、視差／照度推定器（disparity/illumination estimator）１７０の第１の入力および視差／照度補償器１６５の第１の入力と通信で接続されている。視差／照度推定器１７０の出力は、視差／照度補償器（disparity/illumination compensator）１６５の第２の入力と通信で接続されている。

エントロピ符号器１２０の出力は、エンコーダ１００の出力として利用可能である。結合器１０５の非反転入力は、エンコーダ１００の入力として利用可能であり、視差／照度推定器１７０の第２の入力、および動き推定器１８０の第２の入力と通信で接続されている。スイッチ１８５の出力は、結合器１３５の第２の非反転入力、および結合器１０５の非反転入力と通信で接続されている。スイッチ１８５は、動き補償器１７５の出力と通信で接続された第１の入力と、視差／照度補償器１６５の出力と通信で接続された第２の入力と、イントラ予測器１４５の出力と通信で接続された第３の入力とを含む。

モード判定モジュール１４０は、出力をスイッチ１８５に接続され、スイッチ１８５によってどの入力が選択されるかを制御するようになっている。

図２を参照すると、全体として参照符号２００で例示的なマルチビュービデオ符号化（ＭＶＣ）デコーダを示している。デコーダ２００は、出力を逆量子化器２１０の入力と通信で接続されたエントロピ復号器２０５を含む。逆量子化器の出力は、逆変換器２１５の入力と通信で接続されている。逆変換器２１５の出力は、結合器２２０の第１の非反転入力と通信で接続されている。結合器２２０の出力は、デブロッキングフィルタ２２５の入力およびイントラ予測器２３０の入力と通信で接続されている。デブロッキングフィルタ２２５の出力は、（ビューｉ用）参照ピクチャ記憶装置２４０の入力と通信で接続されている。参照ピクチャ記憶装置２４０の出力は、動き補償器２３５の第１の入力と通信で接続されている。

（その他のビュー用）参照ピクチャ記憶装置２４５の出力は、視差／照度補償器２５０の第１の入力と通信で接続されている。

エントロピ符号器２０５の入力は、デコーダ２００への入力として利用可能であり、残りのビットストリームを受信する。さらに、モードモジュール２６０の入力も、デコーダ２００への入力として利用可能であり、制御構文(control syntax)を受信してスイッチ２５５によってどの入力が選択されるかを制御する。さらに、動き補償器２３５の第２の入力が、デコーダ２００の入力として利用可能であり、動きベクトルを受信する。また、視差／照度補償器２５０の第２の入力が、デコーダ２００の入力として利用可能であり、視差ベクトルおよび照度補償構文を受信する。

スイッチ２５５の出力は、結合器２２０の第２の非反転入力と通信で接続されている。スイッチ２５５の第１の入力は、視差／照度補償器２５０の出力と通信で接続されている。スイッチ２５５の第２の入力は、動き補償器２３５の出力と通信で接続されている。スイッチ２５５の第３の入力は、イントラ予測器２３０の出力と通信で接続されている。モードモジュール２６０の出力は、スイッチ２５５と通信で接続され、スイッチ２５５によってどの入力が選択されるかを制御する。デブロッキングフィルタ２２５の出力は、デコーダの出力として利用可能である。

マルチビュービデオ符号化（ＭＶＣ）は、マルチビューシーケンスを符号化するための圧縮の構成である。マルチビュービデオ符号化（ＭＶＣ）シーケンスは、異なるビューポイントから同じシーンを取り込む２つ以上のビデオシーケンスのセットである。

マルチビュービデオソースは、同じシーンの複数のビューを含むので、複数のビューの画像間には高い相関関係がある。したがって、時間冗長度（temporal redundancy）に加えてビュー冗長度（view redundancy）を利用することができ、異なるビューポイントにわたってビュー予測を行うことによってこれを実行する。結果として、本明細書に記載した本発明の原理の実施形態は、時間予測とビュー間予測の両方を含むことができる。

説明のために、本原理の実施形態を、本明細書ではＭＰＥＧ−４ ＡＶＣ標準に関して説明する。しかしながら、本発明は、ＭＰＥＧ−４ ＡＶＣ標準に限定されず、本原理の教示が本明細書で提供されると、当技術分野および関連技術分野の専門家は、本原理の範囲を維持しながら本原理を適用することができる、マルチビュービデオ符号化が可能であるこのビデオ符号化標準およびその他のビデオ符号化標準を企図するであろうことが理解される。ＭＰＥＧ−４ ＡＶＣ標準に関して、本明細書に説明された本原理の実施形態は、例えばデブロッキングフィルタの変更、および／または構文のエントロピ符号化を含むことができる。

一実施形態では、スライスレベルにおいて、ビュー間予測リストを導入して視差予測を可能にし、ビュー間符号化タイプの構文を付加して視差予測の符号化タイプを示す。マクロブロック（ＭＢ）レベルでは、フラグ構文を導入して、各信号ブロックに動き補償または視差補償が用いられているかどうかを示す。さらに、ＭＰＥＧ−４ ＡＶＣ標準を対象とする実施形態で利用することができる他の変更は、例えばデブロッキングフィルタ、コンテキスト適応型２値算術符号化（Context Adaptive Binary Arithmetic Coding、ＣＡＢＡＣ）の新しい構文のコンテキスト、並びに、パラメータセットレベルおよびスライスヘッダレベルの追加構文を含む。

次に、本原理の一実施形態によるビュー間符号化タイプおよびビュー間参照リストに関して説明する。

ＭＰＥＧ−４ ＡＶＣ標準は、２つの予測リスト、Ｌｉｓｔ０およびＬｉｓｔ１を形成することにより、フレーム間予測を行う。したがって、Ｌｉｓｔ０の１つの参照ピクチャのみを用いることにより、または２つの参照ピクチャ、すなわち各リストから１つずつを用いることにより、現フレームの画像ブロックを補償することができる。スライスヘッダでは、ｓｌｉｃｅ＿ｔｙｐｅ構文が送信されて、各スライスの時間的符号化タイプを示す。ｓｌｉｃｅ＿ｔｙｐｅ＝Ｐ＿ＳＬＩＣＥのとき、Ｌｉｓｔ０のみが、動き補償に使用される。ｓｌｉｃｅ＿ｔｙｐｅ＝Ｂ＿ＳＬＩＣＥのとき、Ｌｉｓｔ０およびＬｉｓｔ１の両方が、動き補償に使用されることが可能である。

異なるビューポイント間でビュー間予測を可能にするために、本原理の一実施形態は、２つの新しい予測リスト、ＶｉｅｗＬｉｓｔ０およびＶｉｅｗＬｉｓｔ１を使用することを含む。ＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１のピクチャは、現在のビューポイント以外のカメラビューからの参照ピクチャである。スライスヘッダの新しい構文ｖｉｅｗ＿ｓｌｉｃｅ＿ｔｙｐｅは、ビュー間予測の符号化タイプを示すために使用される。例えば、特定のスライスが、ｓｌｉｃｅ＿ｔｙｐｅ＝Ｂ＿ＳＬＩＣＥおよびｖｉｅｗ＿ｓｌｉｃｅ＿ｔｙｐｅ＝Ｐ＿ＳＬＩＣＥを有する場合、このスライスのマクロブロック（ＭＢ）は、Ｂ＿ＳＬＩＣＥ符号化タイプとして時間的に符号化されるか、Ｐ＿ＳＬＩＣＥ符号化タイプとしてビュー間符号化されることが可能である。

ＭＰＥＧ−４ ＡＶＣ標準フレームワークでビュー間予測を可能にする代替的方法は、新しいビュー予測リストおよびビュー間符号化タイプを導入せずに、リストすなわちＬｉｓｔ０／Ｌｉｓｔ１の他のビューから参照ピクチャを挿入することを含む。しかしながら、第１の手法の利点は、次のようなものである。第１の手法の１つの利点は、ＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１の参照ピクチャが、ビュー間参照を含むだけであるので、ｒｅｆ＿ｉｄｘを送信することは、同じリストに同一ビュー参照とビュー間参照とを共に有するほどビットを費やさないということである。第１の手法の別の利点は、２つの新しいリスト、ＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１を有することで、時間的予測およびビュー間予測を与える個々の方法を提供することである。これは、Ｌｉｓｔ０／Ｌｉｓｔ１が時間的参照およびビュー間参照を共に含む場合に関し、したがってＭＰＥＧ−４ ＡＶＣ標準の参照ピクチャのリストの構成を再命令する処理は、変更されることが必要となり、必然的により複雑になる。

一実施形態では、各スライスのビュー間参照リストは、次のルールに従って形成されることが可能である。第１のルールに関しては、スライスヘッダにおいて、ビュー間参照ピクチャの数およびそのｖｉｅｗ＿ｉｄ’ｓが、ＶｉｅｗＬｉｓｔ０およびＶｉｅｗＬｉｓｔ１に送られる。このｖｉｅｗ＿ｉｄ’ｓは、２つのビュー間予測リストの各々で特有のものである。第２のルールに関しては、ビュー間予測リストの参照ピクチャが、スライスヘッダに見えるのと同じ順序で配列されている。参照される各ビューについて、最も近いピクチャ順序カウント（Picture Order Count、ＰＯＣ）数を有する参照ピクチャが、現スライスのビュー間予測リストで使用される。

ビュー間参照ピクチャをさらに柔軟に処理することができるように、追加の参照再命令構文を含むことができる。

図３を参照すると、全体として参照符号３００でマルチビュービデオコンテンツに参照リストを構成する例示的な方法を示している。この方法３００は、判定ブロック３１０へ制御を渡す開始ブロック３０５を含む。判定ブロック３１０は、現スライスタイプがＰスライスまたはＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック３１５へ渡される。そうでない場合、制御は判定ブロック３３０へ渡される。

機能ブロック３１５は、時間的参照を用いてＬｉｓｔ０を構成し、判定ブロック３２０へ制御を渡す。判定ブロック３２０は、現スライスタイプがＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック３２５へ渡される。そうでない場合、制御は判定ブロック３３０へ渡される。

機能ブロック３２５は、時間的参照を用いてＬｉｓｔ１を構成し、判定ブロック３３０へ制御を渡す。

判定ブロック３３０は、現在のビューポイントのスライスタイプがＰスライスまたはＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック３３５へ渡される。そうでない場合、制御はループ端ブロック（loop limit block）３５０へ渡される。

機能ブロック３３５は、ビュー間参照を用いてＶｉｅｗＬｉｓｔ０を構成し、判定ブロック３４０へ制御を渡す。判定ブロック３４０は、現在のビューポイントのスライスタイプがＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック３４５へ渡される。そうでない場合、制御はループ端ブロック３５０へ渡される。

機能ブロック３４５は、ビュー間参照を用いてＶｉｅｗＬｉｓｔ０を構成し、ループ端ブロック３５０へ制御を渡す。

ループ端ブロック３５０は、可変ｍｂ＝０からＭａｃｒｏＢｌｏｃｋｓＩｎＰｉｃ−１を用いてループの範囲を設定することを含み、各マクロブロックでループを開始し、機能ブロック３５５へ制御を渡す。機能ブロック３５５は、Ｌｉｓｔ０／Ｌｉｓｔ１を用いて現マクロブロックを符号化し、判定ブロック３６０へ制御を渡す。判定ブロック３６０は、現在のビューポイントのスライスタイプがＰスライスまたはＢスライスに等しいかどうかを判定する。そうである場合、制御は機能ブロック３６５へ渡される。そうでない場合、制御は判定ブロック３７０へ渡される。

機能ブロック３６５は、ＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１を用いて現マクロブロックを符号化し、機能ブロック３７０へ制御を渡す。

機能ブロック３７０は、ベストモードを選択し、ｍｖｃ＿ｐｒｅｄｉｃｔｉｏｎ＿ｆｌａｇを設定し、機能ブロック３７５へ制御を渡す。機能ブロック３７５は、動き／視差ベクトルのバッファ処理を行い、ループ端ブロック３８０へ制御を渡す。ループ端ブロックがループを終了し、機能ブロック３８５へ制御を渡す。機能ブロック３８５は、符号化されたピクチャを復号されたピクチャのバッファ（ｄｐｂ）に保存し、終了ブロック３９０へ制御を渡す。

各スライスのビュー間予測は、ビュー間符号化タイプおよびビュー予測リストを用いて十分に設定可能であるので、マルチビュービデオ符号化（ＭＶＣ）コーデックは、任意のビューの符号化順序およびビュースケーラビリティをサポートすることができる。

一実施形態では、ＭＢレベルにおいてｍｖｃ＿ｐｒｅｄ＿ｆｌａｇと呼ばれる新しい構文が、各信号ブロックの符号化に時間的予測またはビュー間予測が使用されるかどうかを示す。ｍｖｃ＿ｐｒｅｄ＿ｆｌａｇ＝０の場合、ｓｌｉｃｅ＿ｔｙｐｅに応じて動き補償にＬｉｓｔ０／Ｌｉｓｔ１を利用する。ｍｖｃ＿ｐｒｅｄ＿ｆｌａｇ＝１のとき、ｖｉｅｗ＿ｓｌｉｃｅ＿ｔｙｐｅに応じてＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１を利用する。

図４を参照すると、全体として参照符号４００で時間的／ビュー間モードの判定を行う例示的方法を示している。この方法４００は、判定ブロック４１０へ制御を渡す開始ブロック４０５を含む。判定ブロック４１０は、現スライスタイプがＰスライスまたはＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック４１５へ渡される。そうでない場合、制御は判定ブロック４３０へ渡される。

機能ブロック４１５は、時間的参照を用いてＬｉｓｔ０を構成し、判定ブロック４２０へ制御を渡す。判定ブロック４２０は、現スライスタイプがＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック４２５へ渡される。そうでない場合、制御は判定ブロック４３０へ渡される。

機能ブロック４２５は、時間的参照を用いてＬｉｓｔ１を構成し、判定ブロック４３０へ制御を渡す。

判定ブロック４３０は、現在のビューポイントのスライスタイプがＰスライスまたはＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック４３５へ渡される。そうでない場合、制御はループ端ブロック４５０へ渡される。

機能ブロック４３５は、ビュー間参照を用いてＶｉｅｗＬｉｓｔ０を構成し、判定ブロック４４０へ制御を渡す。判定ブロック４４０は、現在のビューポイントのスライスタイプがＢスライスであるかどうかを判定する。そうである場合、制御は機能ブロック４４５へ渡される。そうでない場合、制御はループ端ブロック４５０へ渡される。

機能ブロック４４５は、ビュー間参照を用いてＶｉｅｗＬｉｓｔ０を構成し、ループ端ブロック４５０へ制御を渡す。

ループ端ブロック４５０は、可変ｍｂ＝０からＭａｃｒｏＢｌｏｃｋｓＩｎＰｉｃ−１を用いてループの範囲を設定することを含み、各マクロブロックでループを開始し、判定ブロック４５５へ制御を渡す。判定ブロック４５５は、ｍｖｃ＿ｐｒｅｄｉｃｔｉｏｎ＿ｆｌａｇが１に等しいかどうかを判定する。そうである場合、制御は機能ブロック４６０へ渡される。そうでない場合、制御は機能ブロック４６５へ渡される。

機能ブロック４６０は、ＶｉｅｗＬｉｓｔ０／ＶｉｅｗＬｉｓｔ１を用いてマクロブロックを復号し、機能ブロック４７０へ制御を渡す。

機能ブロック４６５は、Ｌｉｓｔ０／Ｌｉｓｔ１を用いてマクロブロックを復号し、機能ブロック４７０へ制御を渡す。

機能ブロック４７０は、動き／視差ベクトルのバッファ処理を行い、ループ端ブロック４７５へ制御を渡す。ループ端ブロック４７５がループを終了し、機能ブロック４８０へ制御を渡す。機能ブロック４８０は、復号されたピクチャを復号されたピクチャのバッファ（ｄｐｂ）に保存し、終了ブロック４８５へ制御を渡す。

ｍｖｃ＿ｐｒｅｄ＿ｄｉｒ構文を符号化するために、３つの新しいＣＡＢＡＣコンテキストを追加する。コンテキストモデリングは、ｔｒａｎｓｆｏｒｍ＿ｓｉｚｅ＿８×８＿ｆｌａｇ構文と同じものである。

ＭＰＥＧ−４ ＡＶＣ標準におけるマルチビュー拡張機能では、復号されたピクチャのバッファ（ｄｐｂ）が、複数のビューからの復号されたピクチャを処理することができる必要がある。Ｎ個の入力ビューがあるとすると、本原理の一実施形態は、Ｎ個の個々のｄｐｂを含むことができる。各ｄｐｂは、１つの特定のビューからの復号されたピクチャを格納する。

ｄｐｂを管理する代替的方法は、すべてのビューのピクチャを単一ｄｐｂに入れることである。しかしながら、第１の手法には、次の利点がある。第１の手法の１つの利点は、各ビューが、ＭＰＥＧ−４ ＡＶＣ標準と同じ復号された参照のマーキング処理を用いた、独自のｄｐｂを有することである。このより簡略化された手法により、同じｄｐｂで異なるビューポイントのピクチャを管理する複雑さを軽減する。第１の手法の別の利点は、時間相関関係が、一般にビュー間相関関係より強力であるので、利用可能な時間的参照フレームの数を削減することが好ましくないことに関連する。各ビューがそのｄｐｂで独自の参照ピクチャを管理すれば、時間的予測は、同時放送の場合と同じ複数の参照フレームの予測能力を有する。

従来のビデオ符号化と比較したＭＶＣ特有の特徴は、動きと視差とが共存していることである。ビュー間予測の視差ベクトル（ＤＶ）に対して、時間的に予測されるブロックは、動きベクトル（ＭＶ）を送る必要がある。

同じスライスに動きベクトルと視差ベクトルの両方を処理する２つの例示的方法について、本明細書で説明する。しかしながら、本明細書で提供される本発明の教示があれば、当技術および関連技術の専門家は、本発明の範囲を維持しながら、これらの同様の方法およびその他の同様の方法を企図するであろうと理解される。

第１の方法では、各ブロックに対して、動きベクトルまたは視差ベクトルを送って格納するが、両方を送って格納しない。動きベクトルまたは視差ベクトルのどちらかが、構文ｍｖｃ＿ｐｒｅｄ＿ｆｌａｇに応じて送られ、格納される。これは、必要となる記憶装置は少なくなるが、結合されたベクトル場は、整合性がない。

第２の方法では、各ブロックに、動きベクトルと視差ベクトルを共に格納する。これは、両方のベクトルを送るか、または単に一方を送り、もう一方をベクトル場の補間を用いて埋めることで達成されることが可能である。この手法は、より多くの記憶領域を利用するが、動きおよび視差フィールドの両方の整合性をよりよく保存することができる。

第１の方法の例示的実施形態について、図５と関連して示して説明する。第２の方法の例示的実施形態について、図６と関連して示して説明する。

図５を参照すると、全体として参照符号５００で、マルチビュービデオコンテンツに対応する同じスライスに動きベクトルおよび視差ベクトルを処理する例示的方法が示されている。この方法５００は、判定ブロック５１０へ制御を渡す開始ブロック５０５を含む。判定ブロック５１０は、ｍｖｃ＿ｐｒｅｄ＿ｆｌａｇが０に等しいかどうかを判定する。そうである場合、制御は機能ブロック５１５へ渡される。そうでない場合、制御は判定ブロック５２０へ渡される。機能ブロック５１５は、視差ベクトル予測子（display vector predictor）を形成し、視差ベクトルＤＶを処理し、視差ベクトルＤＶをＶｅｃｔｏｒＢｕｆｆｅｒに格納し、終了ブロック５２５へ制御を渡す。

機能ブロック５２０は、動きベクトル予測子（motion vector predictor）を形成し、動きベクトルＭＶを処理し、動きベクトルＭＶをＶｅｃｔｏｒＢｕｆｆｅｒに格納し、終了ブロック５２５へ制御を渡す。

図６を参照すると、全体として参照符号６００で、マルチビュービデオコンテンツに動きベクトルおよび視差ベクトルを処理する別の方法を示している。この方法６００は、機能ブロック６１０へ制御を渡す開始ブロック６０５を含む。機能ブロック６１０は、視差ベクトル予測子を形成し、視差ベクトルＤＶを処理し、視差ベクトルＤＶをＶｅｃｔｏｒＢｕｆｆｅｒ１に格納し、機能ブロック６１５へ制御を渡す。機能ブロック６１５は、動きベクトル予測子を形成し、動きベクトルＭＶを処理し、動きベクトルＭＶをＶｅｃｔｏｒＢｕｆｆｅｒ２に格納し、終了ブロック６２０へ制御を渡す。

同じスライスの符号化に動きベクトルと視差ベクトルとを共に有する意味は、次の側面、すなわち（１）動き／視差ベクトルの予測符号化と、（２）ＤｉｒｅｃｔおよびＳｋｉｐモードとに現れる。

ＭＰＥＧ−４ ＡＶＣ標準では、動きベクトルの成分は、隣接ブロックから中央値または方向予測のいずれかを用いて差分符号化される。マルチビュービデオ符号化では、隣接ブロックは現ブロックとは異なる予測方向を有する可能性がある。動き／視差ベクトルの符号化におけるビットを節約するためには、最も相関性のある情報を用いて予測子を形成することが好ましい。隣接ブロックに利用可能である動きベクトルと視差ベクトルが共にあるかどうかに応じて、第１の方法では、同じ予測方向を有する隣接ブロックのみを使用し、第２の方法では、動きベクトルの予測を形成する際に隣接ブロックの動きベクトルのみを使用し、視差予測を形成する際に隣接ブロックの視差ベクトルのみを使用する。

視差フィールドは、通常時間次元で不変であるので、空間的隣接ブロックの他に、時間的に同一場所に配置されるブロックを用いて視差予測を向上させることができる。

ＭＰＥＧ−４ ＡＶＣ標準のＳｋｉｐおよびＤｉｒｅｃｔモードは、動きベクトルを送信することなく動きを表すことができるため、隣接するマクロブロック間にある時空相関関係をより有効に使う効果的な符号化ツールである。マルチビュービデオ符号化では、付加的なビュー間相関関係を考慮するために、これらのモードが適用されるべきである。

Ｐ＿Ｓｋｉｐモードでは、復元信号は、Ｌｉｓｔ０のインデックス０に位置するピクチャを参照するＰ＿１６×１６マクロブロックタイプの予測信号と同様に取得される。Ｐ＿Ｓｋｉｐマクロブロックを復元するために使用される動きベクトルは、１６×１６ブロックの動きベクトル予測子と同様である。ＭＶＣでは、上述の動き／視差ベクトル予測子の適用が、Ｐ＿Ｓｋｉｐモードをより有用にするのに役立つ。

Ｂ＿ＳＬＩＣＥ符号化については、Ｂ＿Ｓｋｉｐ／Ｂ＿Ｄｉｒｅｃｔ＿１６×１６／Ｂ＿Ｄｉｒｅｃｔ＿８×８モードが、動きと視差を結びつけることを考えるように適合されるべきである。ＭＰＥＧ−４ ＡＶＣ標準では、２つの異なるＤｉｒｅｃｔモード、すなわち時間Ｄｉｒｅｃｔおよび空間Ｄｉｒｅｃｔがサポートされている。

時間Ｄｉｒｅｃｔモードでは、動きベクトルは、第１のＬｉｓｔ１参照で同一位置から導かれる。第１のＬｉｓｔ１参照が視差予測であるとき、システムは他のＬｉｓｔ１参照（ｒｅｆ＿ｉｄｘ＞０）で同一位置にある動きベクトルを探すか、または空間的動きベクトル予測子を利用することができる。

空間Ｄｉｒｅｃｔモードでは、動きベクトルは、Ｐ＿ＳＫＩＰにより用いられる同様の方法で、ただしＬｉｓｔ０／Ｌｉｓｔ１を共に考慮に入れて導かれる。Ｐ＿ＳＫＩＰで行われた同じ適合は、Ｌｉｓｔ１で拡張されることも可能である。

表１〜４は、本発明の原理の様々な実施形態による構文を含むマルチビュービデオ符号化の様々な構文を示している。表１は、マルチビュービデオ符号化のシーケンスパラメータセットのＲＢＳＰ構文を示している。表２は、マルチビュービデオ符号化のピクチャパラメータセットのＲＢＳＰ構文を示している。表３は、マルチビュービデオ符号化のスライスヘッダの構文を示している。表４は、マルチビュービデオ符号化のマクロブロック層の構文を示している。

次に、いくつかについては上述したが、本発明の多くの付随する利点／特徴のいくつかについて説明する。例えば、１つの利点／特徴は、２つのビュー間参照ピクチャのリストのうちの少なくとも１つを利用してピクチャ中のブロックを符号化するエンコーダを含むビデオエンコーダである。このピクチャは、マルチビュービデオコンテンツに対応し、同じまたは類似のシーンに対して異なるビューポイントを有するピクチャのセットのうちの１つである。このピクチャは、異なるビューポイントのうち現在のビューポイントを表す。この２つのビュー間参照ピクチャのリストは、異なるビューポイントのうち現在のビューポイント以外のビューポイントを有する参照ピクチャに対応する。

別の利点／特徴は、２つのビュー間参照ピクチャのリストが、国際標準化機構／国際電気標準会議動画専門グループ４パート１０の高度動画像圧縮符号化標準／国際電気通信連合の電気通信部門によるＨ．２６４の勧告のＬｉｓｔ０およびＬｉｓｔ１とは異なる、上述したビデオエンコーダである。

さらに別の利点／特徴は、同じまたは類似のシーンの異なるビューポイントのマルチビューコンテンツに対応する復号されたピクチャを格納する少なくとも１つのバッファを含むビデオエンコーダである。

さらに、別の利点／特徴は、少なくとも１つのバッファが異なるビューポイントの各々に個々のバッファを含む、上述したビデオエンコーダである。

本発明のこれらのおよびその他の特徴並びに利点は、本明細書の教示に基づいて当業者によって容易に確認されることが可能である。本発明の教示は、ハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、またはその組合せの様々な形態で実装されることが可能であることを理解されたい。

最も好ましくは、本発明の教示は、ハードウェアとソフトウェアの組合せとして実装される。さらに、ソフトウェアは、プログラム記憶装置に実体的に組み込まれたアプリケーションプログラムとして実装されることが可能である。アプリケーションプログラムは、任意の好適なアーキテクチャを含むマシンにアップロードされ、実行されることが可能である。好ましくは、マシンは、１つまたは複数の中央演算処理装置（［ＣＰＵ」）、ランダムアクセスメモリ（［ＲＡＭ」）、および入力／出力（「Ｉ／Ｏ」）インターフェースなどのハードウェアを有するコンピュータプラットフォームに実装される。またコンピュータプラットフォームは、オペレーティングシステムおよびマイクロ命令コードを含む。本明細書に記載した様々な処理および機能は、マイクロ命令コードの一部、またはアプリケーションプログラムの一部、またはその任意の組合せとすることができ、ＣＰＵによって実行されることが可能である。また、追加のデータ記憶装置および印刷装置など、他の様々な周辺装置が、コンピュータプラットフォームに接続されることが可能である。

さらに、添付の図面に描かれた構成システムの構成要素および方法のいくつかは、ソフトウェアに実装されることが好ましいので、システム構成要素またはプロセスの機能ブロック間の実際の関係は、本発明がプログラムされる方法に応じて異なる可能性があることを理解されたい。本明細書の教示があれば、当業者は、本発明のこれらのおよび同様の実装または構成を企図することができるであろう。

添付の図面を参照して説明のための実施形態を記載したが、本発明は、これらの厳密な実施形態に限定されず、本発明の範囲または趣旨から逸脱することなく、当業者によって様々な変更および修正がもたらされることが可能であると理解されたい。このような変更および修正はすべて、添付の特許請求の範囲に示す本発明の範囲内に含まれるものとする。

Claims (1)

1. ２つのビュー間参照ピクチャのリストのうちの少なくとも１つを用いてビットストリームからのピクチャ中のブロックを復号するデコーダであって、前記ピクチャはマルチビュービデオコンテンツに対応するピクチャのセットのうちの１つであり、そして同じまたは類似のシーンに対して異なるビューポイントを有しており、前記ピクチャは前記異なるビューポイントのうちの現在のビューポイントを表しており、前記２つのビュー間参照ピクチャのリストは前記現在のビューポイント以外の前記異なるビューポイントのうちの１つを有する参照ピクチャに対応する、前記デコーダを含み、
   前記ビュー間参照ピクチャの数および前記ビュー間参照ピクチャに対応するビュー識別子が前記２つのビュー間参照ピクチャのリストの各々のビットストリーム内に示されており、
   前記ビュー間参照ピクチャに対応するビュー識別子は、スライスヘッダで示される、ビデオデコーダ。

Images