JP2006042360A - オフラインマルチビュービデオ圧縮のシステムおよび方法 - Google Patents

Abstract

【課題】新しいタイプのビデオキャプチャシステム、ビデオフォーマット、ビデオ圧縮アルゴリズム、およびサービスを提示するインタラクティブマルチビュービデオを提供すること。
【解決手段】多数のビデオカメラを、様々な関連する位置および方向からイベントをキャプチャするために割り当てる。キャプチャされたビデオを、圧縮し、リアルタイムでサーバに送信する。計算の複雑さをさらに減らすために、このスタティックモードを使用するか否かの判断は、すべてのビューの間で共同して判定される。スタティックモードでは、用いられるマクロブロック（ＭＢ）が、伝統的なインターモードのようにコーディングされ、それに対応する基準イメージ（次のフレームで時間予測に使用される）は、その前に構築されたイメージから単純にコピーされる。
【選択図】図１１Ａ

Description

本発明は、新しいタイプのオンラインビデオ圧縮を含むインタラクティブマルチビュービデオのシステムおよび方法を対象とする。

現在一般に使用されているビデオの形は、シングルビュービデオである。これは、１つのビデオカメラから、またはシーケンシャル時間期間を使用して連結された複数のビデオクリップからキャプチャされた１つのビデオクリップからなる。どの瞬間にも、あるイベントの１つのビューだけがある。この種類のビデオの形は、テレビジョン（ＴＶ）、パーソナルコンピュータ（ＰＣ）、および他のデバイスで、ビデオストリーミング、放送、および通信に広く使用されている。

従来のマルチメディアサービス（伝統的なＴＶ、ビデオオンデマンド、ビデオストリーミング、デジタルビデオディスク（ＤＶＤ）など）をレビューする場合に、複数の制限が存在する。例えば、従来のマルチメディアサービスでは、どの瞬間にも１つのイベントに関する１つのビデオストリームだけがある。さらに、従来のマルチメディアサービスでは、どの瞬間でも、ビューイング方向が番組編集者によって選択されている。ユーザは、受動的な立場にあり、カメラアングルまたは視点を変更することができない。さらに、ユーザは、記録され、供給された物を見ることだけができ、ビューイングアングルを選択する能力を有しない。

伝統的なシングルビュービデオの拡張として、ＥｙｅＶｉｓｉｏｎ［１］は、カーネギーメロン大学のコンピュータビジョン教授Ｔａｋｅｏ Ｋａｎａｄｅによって協同開発されたスポーツ放送システムである。ＥｙｅＶｉｓｉｏｎは、３０台のカムコーダを使用して、Ｓｕｐｅｒｂｏｗｌ ２００１のゲームを撮影した。３０台のカムコーダからキャプチャされたビデオのすべてが、ビデオルーティングスイッチャに入力され、編集されたビデオが、ＴＶ視聴者に放送された。しかし、ＥｙｅＶｉｓｉｏｎシステムは、ユーザがビューイング方向を選択し、カメラ制御を行使する能力なしで、１つの編集されたビデオをユーザに提供しただけである。ＥｙｅＶｉｓｉｏｎシステムは、ＴＶ聴衆だけにサービスし、他のマルチメディアフォーマットで使用可能ではない。

ＥｙｅＶｉｓｉｏｎの他に、もう１つのマルチメディアデバイスである３Ｄビデオレコーダが、自由視点（ｆｒｅｅ−ｖｉｅｗｐｏｉｎｔ）ビデオ［３］の記録および再生のために設計された。これは、まず２Ｄビデオをキャプチャし、その後、バックグラウンドからフォアグラウンドを抽出する。ソースコーディングを適用して、３Ｄフォアグラウンドオブジェクト（例えば、人間）を作成する。しかし、ＥｙｅＶｉｓｉｏｎと同様に、３Ｄレコーダは、ユーザがカメラを制御することを許容しない。さらに、３Ｄビデオレコーダによって使用される処理は、バックグラウンドからのフォアグラウンドの分類を必要とし、これは、かなりの計算資産を必要とする。

マルチビュービデオの需要の高まりにつれて、標準化の努力が最近行われた［４］［５］。ＭＰＥＧコミュニティは、２００１年１２月以降、３ＤＡＶ（３Ｄオーディオビジュアル）テクノロジに取り組んでいる。多数の非常に異なるアプリケーションおよびテクノロジが、用語３Ｄビデオに関して議論されてきた。これらのアプリケーションのどれもが、ユーザが動的でリアルなオーディオビデオシーン内でまたは実際にキャプチャされたイメージから再構成された３Ｄオブジェクトを含む動的シーン内で自分の視点および／または方向を選択する可能性を有するという意味でのインタラクティビティに焦点を合わせていない。アプリケーションシナリオに関して、マルチビュービデオが、最も不完全な要素、非効率的な要素、および入手不能な要素を有する最も困難なシナリオであることがわかっている。この領域は、近い将来に最大の標準化の努力を必要とする。さらに、標準化の労力は、インタラクティビティを扱ってこなかった。

したがって、必要な物は、所与の瞬間のビデオの多数のストリームを有し、ユーザがビューイング方向選択およびカメラ制御に参加できるようにする、ビデオを効率的にキャプチャし、見るシステムおよび方法である。このシステムおよび方法は、その較正において高い度合の精度を有し、効率的な圧縮技法を提供しなければならない。さらに、この圧縮技法は、様々なビューイング経験の披露を容易にしなければならない。最適には、このハードウェアは、比較的安価でなければならない。そのようなシステムは、見る聴衆が様々なビューイング経験に参加し、特殊効果を提供することを可能にしなければならない。さらに、このシステムおよび方法は、計算的に効率的でなければならず、大量のイメージデータおよびオーディオデータならびにユーザインタラクションを処理するのに堅牢でなければならない。

本明細書の残りで、大括弧の対に挟まれた符号によって示される様々な個々の文献に言及することに留意されたい。例えば、そのような文献は、「参考文献［１］」または単に「［１］」と示すことによって識別することができる。各指定子に対応する文献のリストは、詳細な説明セクションの末尾にある。

カメラの使用が一般的になり、コンピュータ処理能力がより強力になり、ネットワーク帯域幅がより広くなるにつれて、ユーザは、これらの利益を活用して、より豊かなマルチメディア経験を追求することを望む。さらに、外科のイベントまたはスポーツチャンピオンシップイベントなどの重要なイベントを、様々な視点およびアングルから包括的にキャプチャすることが非常に望ましい。

前に述べたシングルビュービデオの形に対する自然な拡張が、本発明のマルチビュービデオの形である。マルチビュービデオでは、あるイベントまたはイベントスペースの複数のビデオが、異なる視点およびアングルで同時にキャプチャされる。これらのマルチビュービデオが、圧縮され、伝送され、ストアされ、最終的にユーザに配布される。本発明のマルチビュービデオの重要な特徴の１つが、ユーザがビデオのキャプチャを制御でき、異なる方向からイベントを見るのを選択できることである。

新しいタイプのビデオキャプチャシステムは、ビデオカメラ、コントロールＰＣ、サーバ、ネットワークコンポーネント、およびクライアントからなる。オーディオコンポーネントも、関連するオーディオのキャプチャに使用することができる。複数のカメラ、一実施形態では数十台または数百台のビデオカメラを、マスタスレーブ構成で、イベント場でイベントをキャプチャするために割り当てる。これらのカメラは、１つまたは複数のコントロールＰＣによって制御される。イベントスペースでのイベントを、これらのカメラによって、様々な視点および方向から同時にキャプチャする。その後、これらのキャプチャされたビデオを、リアルタイムで、コントロールＰＣで圧縮し、１つまたは複数のサーバに送信する。圧縮されたビデオを、リアルタイムでエンドユーザに配布するか、その間の空間相関および時間相関を利用することによってさらに圧縮することができる。

新規のオンライン圧縮プロシージャが、本発明のインタラクティブビデオのシステムおよび方法と共に使用されるが、従来の圧縮アルゴリズムを使用することができる。オンライン圧縮プロシージャは、リアルタイムマルチビュービデオキャプチャ用に設計されている。その出力は、オンラインサービスに直接に使用するか、将来の処理（例えば、オフライン圧縮および／または再生）のためにディスクに保存することができる。

普通のビデオコーディングと似て、本発明のオンライン圧縮アルゴリズムのフレームに、「Ｉ」フレームと「Ｐ」フレームの２タイプがある。各「Ｉ」フレームの圧縮は、そのフレームの相関だけに基づくが、「Ｐ」フレームの圧縮は、そのフレームと前のフレームの相関に基づく。

しかし、普通のスキームと本発明のインタラクティブマルチビュービデオシステムのオンライン圧縮の大きな相違は、予測コーディングをスピードアップするために導入された独自の「スタティック」モードにある。スタティックモードを見つけるためには、オリジナルイメージと基準イメージの間の差を計算する必要がある。計算の複雑さをさらに減らすために、このスタティックモードを使用するか否かの判断は、すべてのビューの間で共同して判定される。この共同判断では、あるビューのスタティック領域が、まず検出される。次に、隣接するビューとオーバーラップするその対応する領域が、スタティックになる可能性が高いと考えられる。最後に、非常に単純な検査を適用して、この判断を確認する。本発明の一実施形態では、ピクセルの非常に小さい部分だけが、オリジナルイメージと基準イメージの間の差を計算するのに使用される。スタティックモードでは、用いられるマクロブロック（ＭＢ）が、伝統的なインターモードのようにコーディングされ、それに対応する基準イメージ（次のフレームで時間予測に使用される）は、その前に構築されたイメージから単純にコピーされる。その結果、逆量子化、逆離散コサイン変換（ＤＣＴ）、および動き補償のどれもが、このＭＢの基準イメージの作成に必要でなくなる。

新しいコーディングモードの他に、ジョイント動き推定（ＭＥ）も、ＭＥの複雑さを減らすために適用される。この新しいＭＥでは、伝統的なＭＥが、まず、あるビューに適用される。次に、３Ｄ ＭＶを、そのビューの見つかったＭＶに基づいて作成する。その後、３Ｄ ＭＶを隣接するビューに射影して、それ自体のＭＶを予測する。予測されたＭＶに基づいて、これらのビューの検索範囲を減らし、したがって、複雑さを大幅に減らすことができる。

インタラクティブマルチビュービデオは、メディアストリーミング、放送、および通信に一般に使用されている現在のシングルビュービデオに対する自然な拡張である。インタラクティブマルチビュービデオは、テクノロジ開発およびカスタマ要求の傾向に合致する。インタラクティブマルチビュービデオは、メディアプレイヤ、メッセージングシステム、およびミーティングシステムなどの様々なマルチメディアアプリケーションに対する強い影響を有する可能性がある。

本発明のインタラクティブマルチビュービデオシステムは、多数の長所を有する。このシステムは、ビデオストリームの選択およびカメラの制御をユーザに与え、これによって、ユーザが、どの瞬間でもビューイング方向を選択できるようになる。従来のシステムと異なり、本発明のこのインタラクティブマルチビュービデオシステムに関して、フォアグラウンドオブジェクトとバックグラウンドオブジェクトの分類は不要である。さらに、このインタラクティブマルチビュービデオシステムによって、特殊効果の表現を容易にするより豊かな機能と共に、従来のビデオシステムより効率的なコーディングが採用されている。

上で述べた利益の他に、本発明の他の長所は、添付図面と共に解釈される場合に下の詳細な説明から明白になる。

本発明の特定の特徴、態様、および長所は、次の説明、添付請求項、および添付図面に関してよりよく理解される。

本発明の好ましい実施形態の以下の説明では、添付図面を参照するが、添付図面は、本明細書の一部を形成し、本発明を実践できる特定の実施形態を例として示す。他の実施形態を使用することができ、本発明の範囲から逸脱せずに、構造的変更を行えることを理解されたい。

１．０ 例示的なオペレーティング環境
図１に、本発明を実施できる適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の１つの例にすぎず、本発明の使用または機能性の範囲に関する制限を提案することを意図された物ではない。また、コンピューティング環境１００を、例示的なオペレーティング環境１００に示されたコンポーネントのいずれかまたはその組合せに対する依存性または要件を有するものと解釈してはならない。

本発明は、多数の他の汎用のまたは特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成と共に動作する。本発明と共に使用することができる周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例に、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これらに制限はされない。

本発明を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールに、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実践することができる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体の両方に置くことができる。

図１を参照すると、本発明を実施する例示的なシステムに、コンピュータ１１０の形の汎用コンピューティングデバイスが含まれる。コンピュータ１１０のコンポーネントに、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバス、メモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。

コンピュータ１１０に、通常は、様々なコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピュータ１１０によってアクセスでき、揮発性媒体および不揮発性媒体、リムーバブル媒体およびノンリムーバブル媒体の両方を含む使用可能な媒体のいずれかとすることができる。制限ではなく例として、コンピュータ可読媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報をストアする任意の方法またはテクノロジで実施された、揮発性および不揮発性、リムーバブルおよびノンリムーバブルの両方の媒体が含まれる。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、および他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報の保管に使用でき、コンピュータ１１０によってアクセスできる他のすべての媒体が含まれるが、これに制限はされない。通信媒体によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施され、通信媒体には、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれなければならない。

システムメモリ１３０に、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ １３１に保管される。ＲＡＭ １３２には、通常は、処理ユニット１２０から即座にアクセス可能、および／または処理ユニット１２０によって現在操作中のデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０に、他のリムーバブル／ノンリムーバブル、揮発性／不揮発性のコンピュータ記憶媒体も含めることができる。例のみとして、図１に、ノンリムーバブル不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取るかこれに書き込む磁気ディスクドライブ１５１、ＣＤ−ＲＯＭまたは他の光媒体などのリムーバブル不揮発性光ディスク１５６から読み取るかこれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用できる他のリムーバブル／ノンリムーバブル、揮発性／不揮発性のコンピュータ記憶媒体に、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに制限はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などのノンリムーバブルメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などのリムーバブルメモリインターフェースによってシステムバス１２１に接続される。

上で説明し、図１に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージをコンピュータ１１０に提供する。図１では、例えば、ハードドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一の物または異なる物のいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低限でも異なるコピーであることを示すために、異なる符号を与えられている。ユーザは、キーボード１６２および、一般にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、システムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタの他に、コンピュータに、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介して接続できる他の周辺出力デバイスも含めることができる。本発明にとって特に重要なことに、イメージのシーケンス１９３をキャプチャすることができるカメラ１９２（デジタル／電子スチルカメラ、デジタル／電子ビデオカメラ、またはフィルム／写真スキャナ）も、パーソナルコンピュータ１１０への入力デバイスとして含めることができる。さらに、１つのカメラだけが図示されているが、複数のカメラを、パーソナルコンピュータ１１０への入力デバイスとして含めることができる。１つまたは複数のカメラからのイメージ１９３は、適当なカメラインターフェース１９４を介してコンピュータ１１０に入力される。このインターフェース１９４は、システムバス１２１に接続され、これによって、イメージをＲＡＭ １３２またはコンピュータ１１０に関連する他のデータストレージデバイスの１つにルーティングし、ストアすることが可能になる。しかし、イメージデータを、カメラ１９２の使用を必要とせずに、前述のコンピュータ可読媒体のいずれかからコンピュータ１１０に入力することもできることに留意されたい。オーディオレコーダ１９８を、オーディオデータをキャプチャするためにオーディオインターフェースデバイス１９９を介してコンピュータに接続することもできる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、上でコンピュータ１１０に関して説明した要素の多くまたはすべてが含まれるが、図１には、メモリストレージデバイス１８１だけを示した。図１に示された論理接続に、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。

ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ １７１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１１０に、通常は、インターネットなどのＷＡＮ １７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な手段を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して図示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。制限ではなく例として、図１に、メモリデバイス１８１に常駐するものとしてリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを諒解されたい。

例示的なオペレーティング環境を説明したので、この説明セクションの残りの部分は、本発明を実施するプログラムモジュールの説明に捧げられる。

２．０ インタラクティブマルチビュービデオのシステムおよび方法
本発明によるシステムおよび方法を、次のセクションで詳細に説明する。インタラクティブマルチビュービデオのシステムは、３つの主要な部分すなわち、キャプチャコンポーネント、サーバコンポーネント、およびクライアントコンポーネントからなる。

２．１．キャプチャコンポーネント
本発明のインタラクティブマルチビューカメラシステムのキャプチャコンポーネント２０２は、カメラ（例えば、ビデオカメラ）、レンズ、パンチルトヘッド、コントロールＰＣ、および同期化ユニットからなる。図２からわかるように、本発明の一実施形態で、それぞれがそれ自体のパンチルトヘッド２０６ａおよび２０６ｂならびにレンズ（例えば、ズームレンズ）２０８ａおよび２０８ｂを有する２つのビデオカメラ２０４ａおよび２０４ｂが、それぞれ１つのコントロールＰＣ ２１０および１３９４ポート（図示せず）に接続されている。各カメラは、それ自体のＩＤ番号を有する。コントロールＰＣ ２１０は、例えばＲＳ２３２インターフェースを介して、パンチルトヘッド２０６およびレンズ２０８を制御することによって、カメラの視点およびアングルを変更することができる。同期化ユニット２１４は、１つまたは複数のコントロールＰＣ ２１０に、好ましくはその１３９４ポートまたは他の適切な手段を介してリンクされる。このシステムのキャプチャコンポーネントに、ある位置でのすべてのオーディオを記録するオーディオ記録機器２０９も含めることができる。

同期化ユニット２１４は、すべてのカメラに同じ瞬間にトリガさせ、撮影させるのに使用される。したがって、コントロールＰＣは、カメラからのビデオを同時につかむ。これらのカメラのすべてから、１つがマスタカメラになるように選択され、残りはスレーブカメラと呼ばれる。マスタカメラは、カメラマンによって制御され、スレーブカメラは、マスタカメラと同一の関心ポイントをポイントするように駆動される。これは、いわゆるマスタスレーブトラッキングプロセスによって実現されている。通常、カメラマンは人である。しかし、いくつかの場合に、マスタカメラを、実際のカメラマンからのコマンドなしで、オブジェクトトラッキングアルゴリズムによって制御することができる。

制御コマンドは、マスタカメラのコントロールＰＣに入力される。パンチルトパラメータが、計算され、スレーブカメラのすべてを駆動するために他のコントロールＰＣに送信される。キャプチャされたビデオが、コントロールＰＣによって受け取られ、圧縮され、サーバに送信される。本発明の一実施形態では、各ビデオが、６４０×４８０のサイズと３０フレーム毎秒のフレームレートでキャプチャされる。本発明の一実施形態で使用される詳細なオンライン圧縮プロシージャは、セクション３．１で提示する。

２．１．１ カメラ較正
マスタスレーブトラッキングの前に、カメラを較正しなければならない。組込みパラメータ、外来パラメータ、および手目関係を判定する較正プロセスが、本発明のマルチビュービデオシステムで使用される。このプロセスの全般的な流れ図を、図３に示す。まず、組込みカメラパラメータを計算し（処理アクション３０２）、次に、外来カメラパラメータを判定する（処理アクション３０４）。次に、手目パラメータを判定する（処理アクション３０６）。最後に、判定された組込みパラメータ、外来パラメータ、および手目パラメータを使用して、共通の座標系ですべてのカメラの外来パラメータを調整することによってカメラを較正する。マスタカメラのこれらのパラメータおよびパンチルトパラメータのすべてを与えられれば、スレーブカメラがマスタカメラと同一の関心ポイントをポイントするようにするスレーブカメラのパンチルトパラメータを、効率的に計算し、調整することができる。

組込みパラメータは、基本的なピンホールカメラモデルを使用して定義される。これは、カメラの組込み構造だけに依存する。これには、１イメージピクセルの幅に対する焦点距離の比、１イメージピクセルの高さに対する焦点距離の比、主点のｘ座標、および主点のｙ座標が含まれる。外来パラメータは、カメラの組込み構造に依存しない。これは、既知の世界基準フレームに関するカメラ基準フレームの位置および方位を定義する。これには、通常、回転行列および３Ｄ並進ベクトルが含まれる。手目関係パラメータには、そのパンチルトヘッドに関する各カメラの位置および方位が含まれる。

２つの較正方法すなわち、パターンベース較正およびパターンフリー較正が、本発明のマルチビューインタラクティブビデオのシステムおよび方法で採用されている。パターンベース較正は、基平面または他の適当な基準平面に置かれることが好ましい大きい較正パターンを使用することによって実現され、パターンフリー較正は、基平面によってもたらされる情報を活用する。この２つの方法を、下で詳細に説明する。

２．１．２ パターンベース較正
本発明の一実施形態では、その精度および単純さに起因して、プレーンベースアルゴリズム［２］を、組込みパラメータの較正に使用する。そのような較正は、組込みパラメータが非常にわずかに変化するので、数週間に１回だけ実行されなければならない。すべてのカメラの外来パラメータは、共通のワールド座標系で、好ましくはパターンプレーンの座標系で較正される。その後、各カメラの手目関係も、３パンチルト位置以内で、その外来パラメータから較正される。

パターンベース方法では、正確に既知のジオメトリを有するプレーナパターンのイメージを使用する。パターンベース較正を自動的にするために、本発明の一実施形態では、３種類の色（赤、緑、青）を使用してすべてのコーナーポイントの位置を符号化した、図４Ｂに示された特殊な較正パターンを設計した。自動プロシージャは、異なるパンチルトモーションを受けるカメラによってパターンのイメージをキャプチャし、その後、カラー符号化された位置に沿ってパターンのコーナーを検出するように設計された。

パターンベース較正の単純化された流れ図を、図４Ａに示す。パターンは、そのコーナーおよび多分他の基準点を既知の位置に置かれた状態で、地面または他の適当な基準フレームに置かれる（処理アクション４０２）。次に、すべてのカメラが、較正パターンのイメージをキャプチャする（処理アクション４０４）。イメージから抽出された特徴点と、その座標が既知である基準パターン点との間の対応を見つけ、使用することによって、普通の技法を使用して外来カメラパラメータを正確に推定することができる（処理アクション４０６）。正確な較正を得るために、基準パターンは、正確に製造されなければならず、較正に使用されるイメージの大部分を占めなければならない。さらに、大規模なシステムでは、高い精度の大きい基準パターンをセットアップすることが、特殊な機器を必要とする、些細でない作業である。不便を避けるために、パターンフリー較正方法が開発されたが、これを下で説明する。

２．１．３ パターンフリー較正
２．１．３．１ パターンフリー較正プロシージャの概要
本発明の一実施形態で、自動パターンフリー較正ツールが使用されている。イメージ点とパターン点の間の対応を使用してカメラ外来パラメータを判定するパターンベース方法と対照的に、パターンフリー較正方法は、異なるカメラからのイメージ点の間の対応に基づく。図５に、本発明のインタラクティブマルチビュービデオシステムで使用されるパターンフリー較正プロシージャの全般的な流れ図を示す。第１に、処理アクション５０２に示されているように、マスタカメラとスレーブカメラの両方の各イメージ内の特徴点を抽出する。これらの特徴点を使用して、各イメージの特徴をマスタカメラのイメージにマッピングするイメージ間相同の集合を推定する（処理アクション５０４）。次に、処理アクション５０６および５０８に示されているように、外来パラメータの線形解を、好ましくは特異値分解（ＳＶＤ）演算を使用して、これらの相同に基づいて入手することができる。ＳＶＤは、行列の固有値および固有ベクトルを見つけるのに使用できる、古典的な数学演算である。本発明で使用される方法では、ＳＶＤが、特徴点の相同の積行列およびその転置行列の固有値および対応する固有ベクトルを見つけるのに使用される。これらの得られた固有成分に基づいて、カメラの外来パラメータを、線形方程式の組に対する最小自乗解として推定することができる。この後に、処理アクション５１０に示されているように、外来カメラパラメータのバンドル調整を適用して、すべての特徴対応の再射影誤差の合計を最小にすることによって、これらを洗練する。推定された外来パラメータを使用することによって、マスタイメージ（例えば、マスタカメラによって撮影された）内の特徴をスレーブイメージ（例えば、スレーブカメラによって撮影された）に射影することができる。用語「再射影誤差」は、スレーブイメージに射影されたこれらの特徴と、マスタイメージの対応する特徴との間の誤差を指す。射影誤差の合計を使用することが、較正されたパラメータの精度を評価する便利な形である。本発明の一実施形態で、推定されたパラメータは、Ｌｅｖｅｎｂｅｒｇ−Ｍａｒｑｕａｒｄｔ（ＬＭ）法を使用して射影誤差を最小にすることによって洗練される。

２．１．３．２ 相同推定
本発明のパターンフリー較正技法は、次のように、より具体的に説明することができる。ほとんどの環境で、通常は基平面である支配的な平面がある。複数のカメラがそのようなシナリオでセットアップされる場合に、カメラのそれぞれが、支配的平面などの共通の平面のイメージを形成する。例えば、異なる位置から基平面を見る２つのカメラ（一方はマスタカメラ、他方はスレーブカメラ）からの２つのイメージは、

によって定義される３×３相同Ｈによってリンクされる。ここで、Ａ₁およびＡ₂は、それぞれマスタカメラおよびスレーブカメラの組込み行列である。記号

は、相同をあるスケールまでしか推定できないので、非０スケールまで等しいことを示す。Ｒおよびｔは、マスタの基準座標フレームでのスレーブカメラの外来パラメータ（回転および並進）であり、ｎは、基平面の単位法線ベクトルである。

２つのイメージ（コリニアでない）の間の４つを超える点対応を与えられて、相同を推定できる様々な従来の技法がある。例えば、相同は、Ｄｉｒｅｃｔ Ｌｉｎｅａｒ Ｔｒａｎｓｆｏｒｍ（ＤＬＴ）という名前の基本的なコンピュータビジョンアルゴリズムによって推定することができる。本発明の一実施形態は、Ｒａｎｄｏｍ Ｓａｍｐｌｅ Ｃｏｎｓｅｎｓｕｓ（ＲＡＮＳＡＣ）技法を使用して、相同を推定する。この方法は、次の５つのステップからなる。

１．特徴点を検出する。一実施形態では、コーナー検出演算子を使用して、２つのイメージから特徴を検出する。

２．特徴点の周囲の輝度のイメージ間類似性を利用することによって、対応する特徴セットの仮説を得る。

３．ＲＡＮＳＡＣアルゴリズムによって相同を初期化する。

４．Ｌｅｖｅｎｂｅｒｇ−Ｍａｒｑｕａｒｄｔアルゴリズムによってすべての対応する特徴点での再射影誤差を最小にするために相同を洗練する。

５．推定された相同を使用して、より多くの対応する特徴対を見つける。ここで、ステップ４および５を複数回繰り返して、相同を改善する。

相同を得たならば、カメラ外来パラメータを、次のプロセスによって線形に推定することができる。

２．１．３．３ 外来パラメータの判定
相同Ｈについて、

をＭによって表し、Ｍの固有ベクトルをｖ_j（ｊ＝１，２，３）によって表す。Ｈの特性により、ｎに関する次の３つの式を確立することができる。

ここで、ｂ_jおよびａ_jは、２つの中間変数であり、｜ｂ_j｜およびａ_jの値は、Ｍの固有値から導出することができる。これは、１つのイメージ間相同から、未知の符号を有するｎの３つの式が得られることを意味する。マスタカメラを含むｍ＋１台のカメラによってキャプチャされた平坦なシーンのｍ＋１個のイメージがある場合に、マスタイメージから他のイメージへのｍ個の相同を推定することができる。その後、各Ｍからの固有値および固有ベクトルを、さらに判定することができる。これらに基づいて、上の制約が、３ｍ個の線形方程式を作ることができる。これは、法線ベクトルｎを推定する潜在的な形を提示する。実際には、初期化ステップによってｎの初期値を得ることができ、その後、上の式の符号を判定することができる。これに基づいて、ｎをさらに推定することができる。本発明の一実施形態では、投票ベースの初期化ステップを採用して、ｂ_jの符号を判定する。というのは、１つの相同から２つの可能な解を得ることができるからである。

具体的に言うと、全体的なプロシージャは、次のように説明することができる。
ステップ１。イメージの獲得。特徴点を検出し、普通の方法を介してまたは上で説明したように相同Ｈを推定する。
ステップ２。標準ＳＶＤ分解演算によってＭ^TＭの固有値および固有ベクトルを計算する。
ステップ３。投票方法によって法線ベクトルｎの初期値を推定する。
ステップ４。式の符号を判定し、その後、ベクトルｎを洗練する。
ステップ５。並進ｔ（スケールまで）および回転Ｒを推定する。
ステップ６。すべての特徴対応の再射影誤差の合計を最小にすることによって外来カメラパラメータをバンドル調整する。

２．２．サーバコンポーネント
サーバは、インタラクティブマルチビュービデオシステムで最も強力なユニットである。サーバは、大量のビデオデータの伝送およびストレージを管理し、多数のクライアントにサービスを提供する。図２からわかるように、サーバ２１６は、２つのネットワーク２１８および２２０に接続されている。例えば広帯域ネットワークバックボーンなどのネットワーク２１８は、サーバ２１６とコントロールＰＣ ２１０を接続し、その結果、圧縮ビデオをコントロールＰＣ ２１０からサーバ２１６に配布できるようにするために採用される。本発明の一実施形態では、本発明のマルチビュービデオシステムが、１ＧＢネットワークを使用して、サーバ２１６とすべてのコントロールＰＣ ２１０を接続する。外部ネットワーク２２０（例えば、ＬＡＮ、ＷＡＮ、またはインターネット）は、サーバ２１６とクライアント２２２を接続するのに使用される。本発明の一実施形態では、クライアント２２２が、１０／１００ＭＢ以上のネットワークを介してサーバ２１６に接続される。本発明のもう１つの実施形態では、クライアント２２２が、インターネットを介してサーバ２１６に接続される。

２．２．１ マルチビュービデオフォーマット
サーバ２１６は、コントロールＰＣ ２１０からビデオを受信し、これをマルチビュービデオまたはビデオビームの形で保存する。ビデオビームは、ビデオと、好ましくは同一のイベントまたはイベントスペースから同時にとられたオーディオストリームのセットからなる。本発明のインタラクティブマルチビュービデオのストレージスキームは、大量のビデオデータと、ビデオビームの効率的な検索とをサポートする。本発明の一実施形態で、インデックス構造が、検索を高速化するために作成される。本発明のマルチビュービデオは、大量のビデオビームをサポートし、同時にビームにアクセスする膨大な数のユーザをサポートすることができる。そのコア技法は、任意の瞬間のオーディオビットストリームおよびビデオビットストリームの検索を容易にするためにインデックスを使用することである。このインデックス構造の例を、図６Ａおよび６Ｂに示す。図６Ａは、ビデオビットストリーム６０２のフォーマットを示し、図６Ｂは、ビデオビットストリームに対応するオーディオビットストリーム６０４のフォーマットを示す。実際のビデオデータおよびオーディオデータは、インデックスファイルと共に、しばしば、サーバにストアされる。これらを、オフライン再生のためにクライアントでローカルにストアすることができる。例えば、ビデオビームを、ＤＶＤディスクにストアし、クライアント側でＰＣによって再生することができる。

マルチビュービデオのサイズは、非常に巨大になる可能性があるので、本発明の一実施形態では、６４ビットポインタを使用して、圧縮されたマルチビュービデオフレームの開始点を表す。その一方で、３２ビットポインタが、圧縮されたオーディオフレームの開始点を表すのに使用するのに十分である。さらに、ビデオビットストリームの突き止めの時間消費を減らし、ビデオインデックスファイルのサイズを減らすために、６４ビットポインタを、３２ビット上位アドレスポインタおよび３２ビット下位アドレスポインタに分割する。フラグ（例えば、「ｂＣｒｏｓｓ４Ｇ」と命名された）を使用して、上アドレスポインタに推移があるかどうかをシグナリングする。このフラグに「真」がセットされている場合に、下位アドレスを検査しなければならない。その場合に、現在の下位アドレスの値が、前の下位アドレスの値より小さい場合に、現在のポインタから始めて、残りのポインタについて上位アドレスを１つ増分しなければならない。

オーディオおよびビデオのインデックスは、異なるファイルに別々に保存される。ビデオインデックスファイルは、階層構造によって編成される。第１レイヤは、多数のフィールド６０６（例えば、「ＶｉｄｅｏＩｎｄｅｘＩｎｆｏＨｅａｄｅｒ」フィールド）からなり、このそれぞれに、タイムスタンプ、ビデオインデックスデータのオフセット、３２ビット上位アドレス、上位アドレスポインタに推移があるか否かを示すフラグ（例えば、「ｂＣｒｏｓｓ４Ｇ」フラグ）、およびその瞬間に使用されていたカメラの台数が含まれる。第２レイヤに、図６Ａに示された第１レイヤ６０８によってポイントされる、同一のタイムスタンプを有する詳細なビデオインデックスデータ６１０（例えば、「ＶｉｄｅｏＩｎｄｅｘ」フィールド）が含まれる。第２レイヤの各フィールドは、カメラＩＤ、そのフレームのコーディングタイプ、および３２ビット下位アドレスポインタからなる。あるタイムスタンプの「ＶｉｄｅｏＩｎｄｅｘ」フィールドの個数が、「ＶｉｄｅｏＩｎｄｅｘＩｎｆｏＨｅａｄｅｒ」フィールドの「ｂｙＣａｍｅｒａＮｕｍ」によって表されるカメラの総数と等しいことに留意されたい。また、異なるタイムスタンプのカメラの台数が、異なる場合があることに留意されたい。

ビデオインデックスの構造の例を、下に示す。

オーディオインデックスファイル６０４も、階層構造によって編成されている。第１レイヤは、多数のフィールド６１４（例えば、「ＡｕｄｉｏＩｎｄｅｘＩｎｆｏＨｅａｄｅｒ」）からなり、このフィールドのそれぞれに、タイムスタンプ、オーディオインデックスデータのオフセット、およびその瞬間のオーディオレコードの個数が含まれる。第２レイヤ６１６に、図６Ｂに示されているように、同一のタイムスタンプを有する詳細なオーディオインデックスデータ（例えば、「ＡｕｄｉｏＩｎｄｅｘ」フィールド）が含まれる。あるタイムスタンプの「ＡｕｄｉｏＩｎｄｅｘ」フィールドの個数が、「ＡｕｄｉｏＩｎｄｅｘＩｎｆｏＨｅａｄｅｒ」フィールドの「ｂｙＡｕｄｉｏＮｕｍ」によって表されるオーディオストリームの総数と等しいことに留意されたい。また、異なるタイムスタンプのオーディオストリームの個数が、異なる可能性があることに留意されたい。

オーディオインデックスの構造の例を、下に示す。

２．３ クライアントコンポーネント
受信されたビデオビームは、オンラインインタラクティブサービスに直接に使用するか、オフライン処理のためにディスクに保存することができる。本発明によるシステムおよび方法の一実施形態の文脈で、オンラインは、見られるビデオビームがリアルタイムでキャプチャされることを意味する。オフラインは、ビデオビームが取り込まれ、記憶媒体にストアされていることを意味する。オフライン再生には、２つのタイプがある。１つは、例えばビデオオンデマンド（ＶＯＤ）で行われているように、ビデオビームが、サーバにストアされ、クライアントが、ストリーミングプロセスによってそれを再生することである。このモードでは、サーバは、ストリーミングサーバとして働く。したがって、このタイプのオフライン再生を、「ストリーミングサービス」と称する。オフライン再生のもう１つのタイプは、ビデオビームがローカルディスクまたは別の場所にストアされる場合に発生する。このモードでは、クライアントが、サーバの助けなしでそのビデオビームを再生することができる。

オンラインインタラクティブサービスについて、サービスは、クライアントからのユーザコマンドに応答する。本発明の１つの例示的な実施形態でサポートされるコマンドに、ＶＣＲなどの通常のメディアプレイヤの普通のコマンドに加えて、スイッチ、スイープ、フリーズおよび回転、ならびに、ヒストリレビューが含まれる。ユーザコマンドに従って、サーバは、キャプチャされたビデオからビデオストリームを生成し、クライアントに送信する。本発明の一実施形態に、１つのクライアントについて２つの通信チャネルがある。１つは、レイテンシを減らすためにオーディオ／ビデオデータを送信するのに使用されるユーザデータグラムプロトコル（ＵＤＰ）であり、もう１つは、正しさを保証するためにキャプチャするカメラを制御するコマンドおよび制御データを送信するのに使用される伝送制御プロトコル（ＴＣＰ）である。オフライン処理に関して、ビデオビームは、データ量をさらに減らすためにトランスコーディングされる。詳細なオフライン圧縮プロシージャは、セクション３．２で提示する。クライアントコンポーネントの詳細を、下で述べる。

２．３．１ オンラインサービス
オンラインサービスでは、クライアントが、ＬＡＮ、ＷＡＮ、およびインターネットでサーバにリモート接続することができる。クライアントとサーバの間の接続が確立されたならば、ユーザは、通常のメディアプレイヤのように普通のコマンドにクライアント部分でサブスクライブし、インタラクティブマルチビューと同様に、独自コマンド（例えば、スイッチ、スイープ、フリーズおよび回転、ならびにヒストリレビュー）を発行する能力にもサブスクライブする。

クライアントは、コマンドをサーバに送信する。ユーザのコマンドに応答して、サーバは、ユーザのコマンドに従って、期待されたビデオを生成し、各クライアントに送信する。一言でいえば、ユーザは、マルチビュービデオをインタラクティブに再生することができる。いくつかの場合に、ユーザは、カメラＩＤおよびパンチルト値などのパラメータをクライアントに入力することもできる。クライアントは、これらのパラメータをサーバに送信し、その後、コントロールＰＣに送信して、キャプチャするカメラを制御する。

２．３．２ オフラインサービス
オフライン再生では、クライアントが、ローカルディスクまたは別の場所にストアされたマルチビュービデオビームを直接にオープンし、再生することができる。通常のビデオプレイヤの普通の効果（例えば、再生、早送り、巻き戻し、一時停止、停止など）の他に、ユーザは、例えば、異なるビデオストリームの間での切り替え、スイープ効果、ならびにフリーズおよび回転効果などの変わった特殊効果を経験することができる。これらの特殊効果の短い説明を、下で提供する。

ストリーミングモードでは、クライアントが、オンラインモードと同様に、ＬＡＮ、ＷＡＮ、およびインターネットを介してサーバにリモート接続することができる。このモードでは、サーバコンポーネントが、クライアントの接続およびビデオビームを管理するストリーミングサーバとして働き、ユーザは、コマンドをサーバにサブスクライブして、ビデオビームから所望のコンテンツを選択し、異なるビデオ効果（例えば、スイッチ、スイープ、フリーズおよび回転、ヒストリレビュー、ならびにスクリプト）を見ることができる。このモードは、現在のビデオオンデマンド（ＶｏＤ）システムの拡張である。ストリーミングサービスとオンラインサービスの主要な相違は、ストリーミングモードで、ビデオビームがキャプチャされ、サーバコンポーネントでストアされており、リアルタイムでキャプチャされていないことである。ストリーミングサービスは、下にリストしたユーザコマンドのすべてをサポートする。

スイッチ効果：スイッチ効果は、ビデオが時間的に連続しているあいだに、あるカメラ視点と別のカメラ視点の間で切り替えることを伴う。これには、所望の視点を提供する異なるカメラからのビデオストリームにアクセスすることが含まれる。１つの例が、ユーザが、シーケンス内で第２カメラの視点から第５カメラの視点に切り替えることである。

スイープ効果：スイープ効果は、時間が動いている間に隣接するカメラのビューを通って掃引することが含まれる。これによって、ユーザが異なる視点からイベントを見ることが可能になる。１つの例が、合計８つの視点があると仮定して、ユーザが、第１視点から開始し、第２視点、第３視点から第８視点まで継続的に切り替え、その後、第８視点で見ることである。

フリーズおよび回転効果：フリーズおよび回転効果では、時間が凍結され、カメラ視点が、所与の点の回りで回転する。１つの例が、合計８つの視点があると仮定して、ユーザが、第１視点から開始し、第２視点、第３視点から第８視点まで前後に継続的に切り替えることである。

ヒストリ効果：ヒストリ効果では、ユーザが、前に見たまたは前に作成されたビデオシーケンスを再生することができる。

スクリプト：ユーザは、オンデマンドで再生できるビューおよび特殊効果のセットのスクリプトも作成することができる。ユーザは、このスクリプトを他のユーザに送ることもでき、このユーザは、スクリプトがアクティブ化された場合に、同一のスクリプト化されたビデオシーケンスを観察する。

スイープ効果、スイッチ効果、ならびにフリーズおよび回転効果は、オンラインモードでも使用可能とすることができる。

３．０ 圧縮プロシージャ
オンラインおよびオフラインの両方の圧縮プロシージャを、本発明のインタラクティブマルチビュービデオのシステムおよび方法と共に使用することができる。オンライン圧縮プロシージャは、リアルタイムマルチビュービデオキャプチャ用に設計されている。その出力は、オンラインサービスに直接に使用するか、将来の処理（例えば、将来のオフライン圧縮または将来の再生）のためにディスクに保存することができる。オフライン圧縮プロシージャは、事前に符号化されたビットストリームをさらに効率的に圧縮するために、トランスコーディングプロセスで採用されている。その後に、出力ビットストリームが、ストレージおよびオフラインサービスのためにディスクに保存される。

特定の新規のオフラインおよびオンラインの圧縮プロシージャを、下のセクションで説明するが、本発明のシステムおよび方法が、これらのタイプの圧縮に制限されないことに留意されたい。普通の圧縮アルゴリズムも使用することができる。

３．１ オンライン圧縮
一般に、普通のシングルビュービデオコーディングに似て、本発明のインタラクティブマルチビュービデオシステムの一実施形態で使用されるオンライン圧縮では、ビデオの各ビューを、ＩＰＰＰフレームのフォーマットでコーディングすることができる。

背景として、通常のビデオ圧縮は、２つの基本的な圧縮技法すなわち、インターフレーム（Ｐフレーム）圧縮およびイントラフレーム（Ｉフレーム）圧縮を使用する。インターフレーム圧縮は、フレーム間の圧縮であり、連続する絵の間のデータ冗長性（例えば、時間的冗長性）を最小にするように設計されている。イントラフレーム圧縮は、個々のフレーム内で行われ、各絵のデータの重複（例えば、空間的冗長性）を最小にするように設計されている。普通のビデオコーディングでは、イントラピクチャフレームは、本質的に、ソースイメージをＪＰＥＧフォーマット（多少の差はある）で符号化する。通常、ピクセルのブロックが、離散コサイン変換（ＤＣＴ）を受け、マクロブロックごとの基礎で量子化される。イントラピクチャフレームは、他のフレームに依存せず、ランダムアクセスの「ジャンプイン」点として使用される。予測フレーム（Ｐフレーム）とも称するインターフレームは、前のＩフレームまたはＰフレームを利用して、現在のフレームの内容を「予測」し、次に、予測と実際のフレーム内容の間の差を圧縮する。予測は、類似するピクセルを含む、前のフレーム内の現在のマクロブロックの位置に近い領域を見つけることを試みることによって行われる。前の予測された領域を現在のマクロブロックに移動する（通常は１／２ピクセル精度）動きベクトルを計算する。動きベクトルは、動きがない場合に正当にヌルベクトルにすることができ、これは、もちろん、非常に効率的に符号化される。予測されたピクセルと実際の値の間の差を計算し、ＤＣＴ変換し、係数を量子化する（ＩフレームＤＣＴ係数より粗く）。十分に似たピクセルのグループを前のフレームで見つけることができない場合には、Ｐフレームは、単純に、Ｉフレームであるかのようにマクロブロックを空間符号化する。

普通のビデオコーディングと似て、本発明のオンライン圧縮アルゴリズムのフレームに、「Ｉ」フレームと「Ｐ」フレームの２タイプがある。各「Ｉ」フレームの圧縮は、そのフレームの相関だけに基づくが、「Ｐ」フレームの圧縮は、そのフレームと前のフレームの相関に基づく。基本的に言って、「Ｐ」フレームの圧縮効率は、「Ｉ」フレームの圧縮効率よりはるかに高い。「Ｉ」フレームは、効率的な圧縮を与えることができないが、エラーに対して非常に堅牢である。さらに、各「Ｉ」フレームは、他のフレームに依存しないので、簡単にアクセスすることができる。これは、通常のビデオエンコーダが、フレームを周期的に「Ｉ」フレームとして圧縮する理由である。

しかし、普通のスキームと本発明のインタラクティブマルチビュービデオシステムのオンライン圧縮の大きな相違は、予測コーディングをスピードアップするために導入された独自の「スタティック」モードにある。スタティックモードを見つけるためには、オリジナルイメージと基準イメージの間の差を計算する必要がある。計算の複雑さをさらに減らすために、このスタティックモードを使用するか否かの判断は、すべてのビューの間で共同して判定される。この共同判断では、あるビューのスタティック領域が、まず検出される。次に、隣接するビューとオーバーラップするその対応する領域が、スタティックになる可能性が高いと考えられる。最後に、非常に単純な検査を適用して、この判断を確認する（本発明の一実施形態では、ピクセルの非常に小さい部分だけが、オリジナルイメージと基準イメージの間の差を計算するのに使用される）。スタティックモードでは、用いられるマクロブロック（ＭＢ）が、伝統的なインターモードのようにコーディングされ、それに対応する基準イメージ（次のフレームで時間予測に使用される）は、その前に構築されたイメージから単純にコピーされる。その結果、逆量子化、逆ＤＣＴ、および動き補償のどれもが、このＭＢの基準イメージの作成に必要でなくなる。

新しいコーディングモードの他に、ジョイント動き推定（ＭＥ）も、ＭＥの複雑さを減らすために適用される。この新しいＭＥでは、伝統的なＭＥが、まず、あるビューに適用される。次に、３Ｄ ＭＶを、そのビューの見つかったＭＶに基づいて作成する。その後、３Ｄ ＭＶを隣接するビューに射影して、それ自体のＭＶを予測する。予測されたＭＶに基づいて、これらのビューの検索範囲を減らし、したがって、複雑さを大幅に減らすことができる。例えば、普通のシングルビュービデオコーディングでは、エンコーダは、通常、あるマクロブロックの動きベクトルを見つけるために、３２×３２領域内を検索しなければならない。しかし、本発明によるシステムおよび方法のマルチビュービデオコーディングでは、３Ｄ動きが入手され、あるビューに射影されたならば、そのビューの検索範囲を狭める（例えば、８×８ピクセルに）ことができ、したがって、そのビューの動きベクトルを見つける計算が、大幅に減る。その一方で、これは、異なるビューの動きベクトルが相関することも暗示する。したがって、これらの動きベクトルを、さらに圧縮することができる。本発明の一実施形態では、真の動きベクトルＶと、他のビューから得られた予測されたベクトル

の間の差だけが符号化される。

１つのカメラに関する本発明のオンライン符号化スキームの全般的な例示的な流れ図を、図７に示す。この例では、システムが、それぞれが毎秒３０フレームでキャプチャする３台のカメラを有すると仮定する。したがって、フレームサイズは６４０×４８０ピクセルである。したがって、毎秒３×３０フレームを圧縮する必要がある。単一のカメラによってキャプチャされたフレームの圧縮を、まず考慮し、次に、複数ビデオの場合を述べる。

図７からわかるように、処理アクション７０２は、フレームを符号化する時に、まず、フレームのタイプに無関係に、フレームをブロック、好ましくはマクロブロック（ＭＢ）に分割する。ＭＢのサイズは、１６×１６ピクセルである、すなわち、上の例では、１フレームあたり６４０×４８０／１６／１６個のＭＢが得られる。次に、各フレームを、事前に決定されたコーディングタイプに従って圧縮する。各「Ｉ」フレームについて、すべてのＭＢを、イントラモード（処理アクション７０４、７０８）を用いてコーディングするが、「Ｐ」フレームについて、各ＭＢを符号化する時に３つのコーディングモードを選択することができる。モード判断は、ＭＢベースである。言い換えると、「Ｐ」フレームの異なるＭＢは、異なるコーディングモードを有することができる。使用すべきモードを判定するために、エンコーダは、まず、各ＭＢの動き推定動作を実行して、現在のフレームとその前のフレームの類似性を計算する（処理アクション７１０）。差が非常に大きい（そのＭＢにほとんど相関がないことを示す）場合に、イントラモードを選択する（処理アクション７１２および７１４）。差が非常に小さい場合には、「スタティック」モードを選択する（処理アクション７１６および７１８）。残りの場合に関して、「インター」モードを選択する（処理アクション７２０）。これが、１つのビデオストリームだけからの入力に関するモード判断である。

下は、オンライン圧縮に関する３つの符号化モードの説明である。図１１Ａ、１１Ｂ、および１１Ｃに、上で説明したモード（それぞれインターモード、イントラモード、およびスタティックモード）の符号化アーキテクチャを示す。

１）イントラモード：図８からわかるように、各ＭＢの係数を、まず変換モジュールまたは「Ｔ」モジュールによって変換して、空間相関を除去する（処理アクション８０２）。その後、変換された係数を「Ｑ」モジュールによって量子化する（処理アクション８０４）（量子化処理の単純な例は、次の通りである：２つの係数、６７および１６を有し、量子化レベルが６４であると仮定する。量子化の後に、第１の係数は６４になり、第２の係数は０になる。量子化の目的が、係数の不確実性を除去し、その結果、簡単にコーディングできるようにすることであることがわかる。もちろん、情報の一部が、量子化の後に失われる）。量子化された係数を符号化する（例えば、「エントロピコーディング」モジュールを使用することによって）（処理アクション８０６）。最後に、圧縮されたビットストリームを得る（処理アクション８０８）。その一方で、次のフレームがＰフレームである場合には、次のフレームのために基準イメージを更新することも必要である。これは、逆量子化モジュール（「Ｑ^-1」）および逆変換モジュール（「Ｔ^-1」）によって達成される（処理アクション８１０）。その後、得られた結果をフレームバッファに保存する。

２）インターモード：図９からわかるように、現在のＭＢおよび前の基準フレームを、まず入力する（処理アクション９０２）。次に、「フレームバッファ」に保存された前の基準フレームに対して「動き推定」を実行して、現在のＭＢの最も類似する領域を見つける（処理アクション９０４）（動き推定プロセスが、通常、図７に示されたモード判断処理によって現在のＭＢに対して実行され、したがって、ここでもう一度行う必要がないことに留意されたい）。その後、処理アクション９０６に示されているように、動き補償（ＭＣ）モジュールによって動き補償動作を適用して、見つかった領域を「フレームバッファ」からコピーする。この時に、２つのＭＢが得られ、一方はオリジナルフレームからのＭＢ、他方は「ＭＣ」モジュールからのＭＢである。この２つのＭＢは、似ているが、その間にまだ多少の差がある。残差と称するその差を、「Ｔ」モジュールによって変換し、「Ｑ」モジュールによって量子化する（処理アクション９０８および９１０）。最後に、量子化結果を「エントロピコーディング」モジュールによってコーディングする（処理アクション９１２）。次のフレームのために基準イメージを更新する必要もある。これは、逆量子化モジュール（「Ｑ^-1」および逆変換モジュール（「Ｔ^-1」）（処理アクション９１４および９１６に示されているように）と、その後、これらのアクションの結果として回復された残差を動き補償された結果に加算すること（処理アクション９１８）によって達成される。その後、エンコーダは、デコーダと同一の基準イメージを有する。

３）スタティックモード：スタティックモードは、本発明のシステムおよび方法によって使用される新しいモードである。その最初の部分は、インターモードの最初の部分に非常に似ている。しかし、大きな相違が第２の部分すなわち、基準フレームの作成にある。この新しいモードでは、新しい基準が、前の基準からコピーされるが、以前のインターモードでは、逆量子化、逆変換、および残差加算が必要である。その結果、膨大な量の計算を節約することができる。スタティックモード処理の流れ図を、図１０に示す。図１０からわかるように、現在のＭＢおよび前の基準フレームを、まず入力する（処理アクション１００２）。次に、「フレームバッファ」に保存された前の基準フレームに対して「動き推定」処理を実行して、現在のＭＢの最も類似する領域を見つける（処理アクション１００４）（動き推定プロセスが、通常、図７に示されたモード判断処理によって現在のＭＢに対して実行されることに留意されたい。したがって、ここでもう一度行う必要はない）。その後、処理アクション１００６に示されているように、「ＭＣ」モジュール（すなわち、動き補償）を適用して、見つかった領域を「フレームバッファ」からコピーする。この時に、２つのＭＢが得られ、一方はオリジナルフレームからのＭＢ、他方は「ＭＣ」モジュールからのＭＢである。この２つのＭＢの間の差を、「Ｔ」モジュールによって変換し、「Ｑ」モジュールによって量子化する（処理アクション１００８および１０１０）。最後に、量子化結果を「エントロピコーディング」モジュールによってコーディングする（処理アクション１０１２）。新しい基準フレームに関して、これは、動き補償されたＭＢをコピーすることによって簡単に得られる（処理アクション１０１４）。このスタティックモードで、ＭＢが、実際にスタティック（静的）である必要はなく、動きを含めることができることを指摘することが重要である。さらに、ＭＢをインターモードまたはスタティックモードのどちらとしてコーディングするかを判定するモード判断閾値が非常に大きくなる場合に、インターモードＭＢのほとんどがスタティックモードとしてコーディングされるようになる。その場合に、複雑さを大幅に減らすことができると同時に、性能が少しだけ犠牲になる。本発明の一実施形態では、上のモード判断閾値が、複雑さと性能の間の適当なトレードオフを達成するように制御される。

復号化プロセスは、符号化プロセスの逆である。例えば、圧縮されたビットストリームが、まずエントロピデコーダに入力されて、量子化された係数が獲得される（各ＭＢのコーディングモードなどの他の必要な情報と共に）。ＭＢごとに、そのコーディングモードに従って、量子化された係数が、逆量子化、逆変換などを行われる。

では、複数のカメラがある場合のモード判断についてはどうであろうか。３つのカメラに戻り、図１２Ａおよび１２Ｂを参照する。第１カメラからのビデオは、前に示したものと正確に同一の形でモード判断を実行される（処理アクション１２０２〜１２２２）。その後、エピポーラ幾何学およびイメージ領域の類似性を使用して、第１カメラと残りの２つのカメラの間の対応を確立することを試みる（処理アクション１２２４）。この対応に基づいて、第２のカメラおよび第３のカメラのコーディングモードを推定する（処理アクション１２２６）。推定は、必ず正しいとは限らないので、ここで見つかったコーディングモードおよび動きベクトルは、洗練される必要があり、この洗練は、より少ない計算コストを有する第２モード判断プロセス（処理アクション１２２８）によって達成される。次に、見つかったコーディングモードに基づいて各ＭＢをコーディングする（処理アクション１２３０）。シングルビューのモード判断に似て、この第２判断プロセスも、オリジナルＭＢと動き補償されたＭＢの間の差を計算する。しかし、ピクセルの小さい部分の差だけを計算する。その結果、複雑さの多くが減らされる。

マルチビューの場合に、各ビューが、シングルビューの場合と同一の形で独立に復号化される。ＭＶが隣接ビューから予測される場合に、隣接ビューのＭＶをまず復号化しなければならない。

３．２ オフライン圧縮
オフライン圧縮を使用して、ビデオデータストリームを圧縮するか、さらに圧縮することができる。図１３および１４からわかるように、オフライン圧縮の主要なアイデアは、すべてのビューを３Ｄマッピングに分解することであり、この３Ｄマッピングは、３Ｄ環境内の特徴点のグループからなる。図１３からわかるように、処理アクション１３０２では、各特徴点を、その３Ｄ座標（ｘ，ｙ，ｚ）および対応する色成分（Ｙ，Ｕ，Ｖ）によって表す。作成されたマッピングは、各ビューのすべてのピクセルを再構成することができる特徴点の最小限の集合である。ＤＣＴおよびＤＷＴなどの変換ベースの分解と異なって、この種の分解は、マルチビュービデオのデコリレートに関する最も効率的な分解である。明らかに、ビューの数が増えた場合に、新しい特徴点（すなわち、新しい情報）だけを記録する必要があり、他の特徴点は、既存マッピングから見つけることができる。

３Ｄマッピング作成の後に、処理アクション１３０４に示されているように、得られた特徴点を変換して、それらの間の相関をさらに分解する。変換された結果を量子化し、「ベースレイヤ」ビットストリームとして符号化する（処理アクション１３０６および１３０８）。逆量子化された特徴点を、各ビューにマッピングし戻して、予測されたビューイメージを形成する（処理アクション１３１０）。予測されたイメージは、オリジナルイメージに近いが、これらの間にはまだ多少の差がある。処理アクション１３１２および１３１４に示されているように、その差を、各ビューイメージの「エンハンスメントレイヤ」として独立に符号化する（エンハンスメントレイヤビットストリームをスケーラブルな形で符号化して、ネットワーク適合能力を改善することができる）。さらに、この２種類のレイヤを符号化する時に、時間相関をさらに使用することができる。これは、時間領域で、マッピング情報およびエンハンスメント残差の静的部分が不変であるからである。移動する部分について、まだ、３Ｄ動き構造によって圧縮することができる。

オフライン圧縮の例示的なコーディングアーキテクチャを、図１４に示す。これには、３Ｄマッピング作成モジュール１４０２、変換モジュール１４０４、量子化モジュール１４０６、逆変換モジュール１４０８、逆量子化モジュール１４１０、逆マッピングモジュール１４１２、およびエントロピ符号化モジュール１４１４、ならびにビューバッファ１４１６が含まれる。提示を単純にするために、この例では２つのビューだけを検討する。第ｉ時刻にキャプチャされたビューについて、すべてのビューイメージおよびカメラの位置が、「３Ｄマッピング作成」モジュールに入力されて、特徴点集合Ｍ_iが抽出される。次に、前に再構成された特徴点集合

からマッピング情報Ｍ_iを予測して、時間相関を除去する。予測された残差

を変換し、量子化する（ここでは、ＤＣＴ変換、離散ウェーブレット変換（ＤＷＴ）変換、または他の変換を採用することができる）。最後に、エントロピコーディングを適用して、ベースレイヤビットストリームを生成する。再構成されたマッピング情報

を、カメラの位置と共に「逆マッピング」モジュールに入力する。その後、各ビューの予測されたイメージを獲得する。予測されたイメージとオリジナルイメージの間の差を、時間予測によってさらにデコリレートする。残差を変換し、量子化する（ここではＤＣＴまたはＤＷＴのいずれかあるいは他の変換を採用することができる）。最後に、エントロピコーディングを適用して、エンハンスメントレイヤビットストリームを生成する（この例では、ビューごとに１ビットストリームの、２つのエンハンスメントレイヤビットストリームが作られる）。

復号化プロセスは、次の通りである。あるビューの再構成が望まれると仮定する。ベースレイヤを、まず、エントロピ復号化、逆量子化、逆変換など（例えば、そのレイヤのコーディングプロセスの逆）を介して復号化する。その後に、そのビューのエンハンスメントレイヤを、エントロピ復号化、逆量子化、逆変換などを介して復号化する。最後に、得られた共通の特徴点（ベースレイヤからの）を、そのビューに逆マッピングする。獲得されたイメージおよび復号化されたエンハンスメントレイヤ結果が、そのビューの再構成されたイメージを形成する。

本発明の前述の説明は、例示および説明のために提示された物である。網羅的であること、または本発明を開示された正確な形に制限することは、意図されていない。多数の修正形態および変形形態が、上の教示に鑑みて可能である。本発明の範囲が、この詳細な説明によって制限されるのではなく、請求項によって制限されることが意図されている。

本発明を実施する例示的なシステムを構成する汎用コンピューティングデバイスを示す図である。 本発明によるインタラクティブマルチビュービデオシステムを示す単純化されたブロック図である。 本発明のインタラクティブマルチビュービデオシステムで使用される較正プロシージャ全体を示す単純化された流れ図である。 本発明のインタラクティブマルチビュービデオシステムで使用されるパターンベース較正を示す流れ図である。 本発明によるシステムおよび方法の一実施形態で使用される例示的な較正パターンを示すイメージを示す図である。 本発明のインタラクティブマルチビュービデオシステムで使用されるパターンフリー較正を示す流れ図である。 本発明のインタラクティブマルチビュービデオシステムで使用されるビデオインデックステーブルを示す図である。 本発明のインタラクティブマルチビュービデオシステムで使用されるオーディオインデックステーブルを示す図である。 本発明の一実施形態の１つのカメラに関するオンライン圧縮スキームを示す流れ図である。 本発明の一実施形態のイントラモード符号化を示す流れ図である。 本発明の一実施形態のインターモード符号化を示す流れ図である。 本発明の一実施形態のスタティックモード符号化を示す流れ図である。 本発明の一実施形態の符号化アーキテクチャすなわち、インターモードの概略を示す図である。 本発明の一実施形態の符号化アーキテクチャすなわち、イントラモードの概略を示す図である。 本発明の一実施形態の符号化アーキテクチャすなわち、スタティックモードの概略を示す図である。 複数のカメラのビットストリームを符号化する符号化ロジックを示す流れ図である。 複数のカメラのビットストリームを符号化する符号化ロジックを示す流れ図である。 本発明の一実施形態のオフライン圧縮スキームを示す流れ図である。 本発明の一実施形態のオフライン圧縮システムを示すアーキテクチャである。

符号の説明

１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１９８ オーディオレコーダ
１２０ 処理ユニット
１９９ オーディオインターフェース
１９４ カメラインターフェース
１９０ ビデオインターフェース
１９５ 出力周辺インターフェース
１９２ カメラ
１９１ モニタ
１９６ プリンタ
１９７ スピーカ
１２１ システムバス
１４０ ノンリムーバブル不揮発性メモリインターフェース
１５０ リムーバブル不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１６１ マウス
１６２ キーボード
１７２ モデム
１７３ 広域ネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム

Claims (20)

1. ビデオ信号を符号化するシステムであって、
   汎用コンピューティングデバイスと、
   前記汎用コンピューティングデバイスによって実行可能なプログラムモジュールを含むコンピュータプログラムと
   を含み、前記コンピューティングデバイスは、前記コンピュータプログラムの前記プログラムモジュールによって、
   ビデオフレームを入力し、
   前記フレームをブロックに分割し、
   前記ビデオフレームがイントラフレームまたはインターフレームのどちらであるかを判定し、
   前記フレームタイプがイントラフレームである場合に、前記フレームのすべてのブロックをイントラブロックモードでコーディングし、
   前記フレームタイプがインターフレームである場合に、前記フレームの前記ブロックのそれぞれのコーディングのために、イントラブロック、インターブロック、またはスタティックブロックのコーディングモードの中で選択し、
   選択されたモードで各ブロックをコーディングする
   ように指示されることを特徴とするシステム。
2. 各ブロックは、１６×１６ピクセルのマクロブロック（ＭＢ）であることを特徴とする請求項１に記載のシステム。
3. 前記フレームの前記ブロックのそれぞれのコーディングのために、イントラブロック、インターブロック、またはスタティックブロックのコーディングモードを選択する前記プログラムモジュールは、
   入力フレーム内の各ブロックの前の入力フレームとの差を判定するために、ブロックごとに動き推定動作を実行するサブモジュールと、
   前記差が非常に大きい場合に、前記ブロックをコーディングするのに前記イントラブロックコーディングモードを選択するサブモジュールと、
   前記差が非常に小さい場合に、前記ブロックをコーディングするのに前記スタティックブロックコーディングモードを選択するサブモジュールと、
   前記差が非常に大きくも非常に小さくもない場合に、前記ブロックをコーディングするのに前記インターブロックコーディングモードを選択するサブモジュールと
   を含むことを特徴とする請求項１に記載のシステム。
4. 前記差が非常に大きいかどうかを判定する前記サブモジュール、前記差が非常に小さいかどうかを判定する前記サブモジュール、または前記差が非常に大きくも非常に小さくもないかどうかを判定する前記サブモジュールは、閾値の組を使用することを特徴とする請求項１に記載のシステム。
5. イントラフレームのコーディングモードを選択する前記プログラムモジュールは、
   各ブロックの空間相関を除去するために、各ブロックを表す係数を変換するサブモジュールと、
   前記変換された係数を量子化するサブモジュールと、
   前記量子化された変換された係数を符号化するサブモジュールと、
   前記変換された量子化された係数を逆量子化するサブモジュールと、
   更新された基準フレームを入手するために、前記逆量子化された係数を逆変換するサブモジュールと
   を含むことを特徴とする請求項１に記載のシステム。
6. 各ブロックを表す係数を変換する前記サブモジュールは、変換モジュールを使用することを特徴とする請求項５に記載のシステム。
7. 前記変換された係数を量子化する前記サブモジュールは、量子化モジュールを使用することを特徴とする請求項５に記載のシステム。
8. 前記量子化された変換された係数を符号化する前記サブモジュールは、エントロピ符号化モジュールを使用することを特徴とする請求項５に記載のシステム。
9. インターブロックのコーディングモードを選択する前記サブモジュールは、
   前記フレームおよびストアされた基準フレームのブロックを入力するモジュールと、
   入力された前記フレームの前記ブロック内の最も似た領域を見つけるために、前記ストアされた基準フレームに対して動き推定処理を実行するモジュールと、
   動き補償動作から得られる第２ブロックを得るために、見つかった前記最も似た領域をコピーするために、前記入力フレームの前記ブロック内の前記最も似た領域に前記動き補償動作を適用するモジュールと、
   前記入力ブロックと前記動き補償動作から得られた前記第２ブロックとの間の差を判定するモジュールと、
   前記差を変換するモジュールと、
   前記差を量子化するモジュールと、
   前記差をコーディングするモジュールと、
   前記入力ブロックと前記動き補償動作から得られた前記第２ブロックとの間の前記差を逆量子化するモジュールと、
   前記入力ブロックと前記動き補償動作から得られた前記第２ブロックとの間の前記差を逆変換するモジュールと、
   更新された基準フレームを得るために、前記動き補償動作から得られた前記第２ブロックに前記逆量子化され逆変換された差を加算するモジュールと
   を含むことを特徴とする請求項３に記載のシステム。
10. 前記更新された基準フレームをフレームバッファに保存するモジュールをさらに含むことを特徴とする請求項９に記載のシステム。
11. スタティックのコーディングモードを選択する前記プログラムサブモジュールは、
    前記フレームおよびストアされた基準フレームのブロックを入力するモジュールと、
    入力された前記フレームの前記ブロック内の最も似た領域を見つけるために、前記ストアされた基準フレームに対して動き推定処理を実行するモジュールと、
    動き補償動作から得られる第２ブロックを得るために、見つかった前記最も似た領域をコピーするために、前記入力フレームの前記ブロック内の前記最も似た領域に前記動き補償動作を適用するモジュールと、
    前記入力ブロックと前記動き補償動作から得られた前記第２ブロックとの間の差を判定するモジュールと、
    前記差を変換するモジュールと、
    前記差を量子化するモジュールと、
    前記差をコーディングするモジュールと、
    前記動き補償動作から得られた前記第２ブロックをコピーし、更新された基準フレームとしてこれを保存するモジュールと
    を含むことを特徴とする請求項３に記載のシステム。
12. 前記ビデオ信号は、リアルタイムでコーディングされることを特徴とする請求項１に記載のシステム。
13. 複数のカメラからのビデオ信号を符号化するコンピュータ実施された処理であって、
    第１カメラからのビデオについて、
    ビデオフレームを入力する処理アクションと、
    前記フレームをブロックに分割する処理アクションと、
    前記ビデオフレームがイントラフレームまたはインターフレームのどちらであるかを判定する処理アクションと、
    前記フレームタイプがイントラフレームである場合に、前記フレーム内のすべてのブロックをイントラブロックモードでコーディングする処理アクションと、
    前記フレームタイプがインターフレームである場合に、前記フレームの前記ブロックのそれぞれのコーディングのためにイントラブロック、インターブロック、またはスタティックブロックのコーディングモードの中で選択する処理アクションと、
    １つまたは複数の後続カメラからのビデオについて、
    前記第１カメラからの前記ビデオと１つまたは複数の後続カメラからの前記ビデオとの間の対応を確立する処理アクションと、
    前記対応に基づいて前記１つまたは複数の後続カメラのコーディングモードを推定する処理アクションと
    を含むことを特徴とするコンピュータ実施された処理。
14. 前記対応に基づいて前記１つまたは複数の後続カメラのコーディングモードを推定する前記処理アクションは、
    第１ビュー内のスタティック領域を判定することと、
    前記第１ビュー内の前記スタティック領域に対応する隣接ビュー内の領域をスタティックとみなすことと、
    前記隣接ビュー内の前記領域の小さい部分が実際にスタティックであるかどうかを判定するために、前記隣接ビュー内の前記領域の前記小さい部分の検査を実行することと
    を含むことを特徴とする請求項１３に記載のコンピュータ実施された処理。
15. 汎用コンピューティングデバイスと、
    前記汎用コンピューティングデバイスによって実行可能なプログラムモジュールを含むコンピュータプログラムと
    を含み、前記コンピューティングデバイスは、前記コンピュータプログラムの前記プログラムモジュールによって、
    圧縮されたビデオフレームを入力し、
    前記圧縮されたビデオフレームを表す量子化された係数を獲得するために、前記圧縮されたビデオフレームをエントロピ復号化し、
    前記ビデオフレームをブロックに分割し、
    前記圧縮解除されたビデオフレームがイントラフレームまたはインターフレームのどちらであるかを判定し、
    前記フレームタイプがイントラフレームである場合に、前記フレーム内のすべてのブロックをイントラブロックモードで復号化し、
    前記フレームタイプがインターフレームである場合に、前記フレームの前記ブロックのそれぞれを復号化するために、イントラブロック、インターブロック、またはスタティックブロックの復号化モードの中で選択し、
    前記選択されたモードで各ブロックを復号化する
    ように指示されることを特徴とするビデオ信号を復号化するシステム。
16. 前記フレームの前記ブロックのそれぞれを復号化するために、イントラブロック、インターブロック、またはスタティックブロックの復号化モードを選択する前記プログラムモジュールは、
    前記入力フレーム内の各ブロックの前の入力フレームとの差を判定するために、ブロックごとに動き推定動作を実行するサブモジュールと、
    前記差が非常に大きい場合に、前記ブロックを復号化するために前記イントラブロック復号化を選択するサブモジュールと、
    前記差が非常に小さい場合に、前記ブロックを復号化するために前記スタティックロック復号化を選択するサブモジュールと、
    前記差が非常に大きくも非常に小さくもない場合に、前記ブロックを復号化するために前記インターブロック復号化を選択するサブモジュールと
    を含むことを特徴とする請求項１５に記載のシステム。
17. イントラブロックモードですべてのブロックを復号化する前記プログラムモジュールは、
    前記量子化された係数を逆量子化することと、
    前記復号化されたビデオフレームを得るために、前記逆量子化された係数を逆変換することと
    を含むことを特徴とする請求項１５に記載のシステム。
18. インターブロックモードですべてのブロックを復号化する前記プログラムモジュールは、
    前記量子化された係数を逆量子化することと、
    前記逆量子化された係数を逆変換することと
    復号化されたビデオフレームを得るために、基準フレームの係数に前記逆変換された逆量子化された係数を加算することと
    を含むことを特徴とする請求項１５に記載のシステム。
19. スタティックモードですべてのブロックを復号化する前記プログラムモジュールは、
    前記量子化された係数を逆量子化することと、
    前記逆量子化された係数を逆変換することと
    復号化されたビデオフレームを得るために、基準フレームの係数に前記逆変換された逆量子化された係数を加算することと
    を含むことを特徴とする請求項１５に記載のシステム。
20. 同一イベントの異なるカメラ視点からの複数のビデオフレームは、入力され、前記ビデオフレームのどれを最初に復号化しなければならないかを判定するために、動きベクトル（ＭＶ）動作は使用されることを特徴とする請求項１５に記載のシステム。
    

Images