(57)【要約】  本発明は、複数のサイトのビデオ・カンファランスを管理する多地点通信制御ユニット（ＭＣＵ）内に連続的存在（ＣＰ）イメージを生成することに関する。本発明は、ＩＴＵ  Ｈ．２６＊標準のビット構造を用いて、セルフ・ビューの無いＣＰビューを生成する為に、ＭＣＵ内の処理時間と処理要件を低減する。符号化されたＣＰイメージをからのマクロブロックを再配置することにより、ＣＰイメージ内の流域を取り除き、セルフ・ビューの無いＣＰビューを会議の参加者に送信する。この再配置処理が、ＭＣＵ内の符号化資源の要件を大幅に減らす。
2007522761.tif 000002
【特許請求の範囲】
【請求項１】
ビデオ符号化標準により、所定の順番のマクロブロックを含む複数の符号化ビデオ信号から符号化対象連続的存在（Conitnuou Picture:CP）イメージ（以下、ＣＰイメージと称する）を形成する方法において、
前記マクロブロックは、それぞれのエンドポイント・ビデオイメージに対応し、多地点ビデオ・カンファレンスに参加しているエンドポイントから受信した符号化ビデオ信号を含み、
（Ａ）  前記符号化ビデオ信号を復号化するステップと、
（Ｂ）  前記符号化された符号化ビデオ信号を空間的に混合するステップと、
その結果、前記エンドポイントのビデオイメージにそれぞれ関連する領域から構成される複数のＣＰイメージが形成され、
（Ｃ）  前記ＣＰイメージを符号化するステップと、
（Ｄ）  前記符号化されたＣＰイメージのマクロブロックを、再配列するステップと
（Ｅ）  これにより、前記符号化対象ＣＰイメージを形成するステップと
を有する
ことを特徴とする符号化対象連続的存在（ＣＰ）イメージを生成する方法。
【請求項２】
前記（Ｅ）ステップの前に、
（Ｆ）  前記エンドポイントに対し、それぞれのエンドポイント・ビデオイメージを、ビデオ標準、解像度、ビットレート、スケーリングに従って、符号化することを要求するステップ
をさらに有する
ことを特徴とする請求項１記載の方法。
【請求項３】
前記（Ｃ）ステップは、
（Ｃ１）  ビデオ符号化標準に従って、前記マクロブロックの所定の順番を確立するステップと、
（Ｃ２）  領域境界とマクロブロック境界を合併するステップと
を有する
ことを特徴とする請求項１記載の方法。
【請求項４】
前記符号化ＣＰイメージと符号化対象ＣＰイメージは、それぞれ、２２個のマクロブロックを有するブロック群（Group of Block (GOB)）を１８個有するＣＩＦフォーマットでスタック形式で配置され、
その結果、最初の９個のブロック群（ＧＯＢ）は、上部領域を表し、最後の９個のブロック群（ＧＯＢ）は、下部領域を表す
ことを特徴とする請求項３記載の方法。
【請求項５】
前記（Ｅ）ステップは、
（Ｅ１）  第１の符号化ＣＰイメージの領域高さを表すｎ個の連続するブロック群（ＧＯＢ）内の領域幅を表すｍ個のマクロブロックを、第２の符号化ＣＰイメージからのｎ個の連続するブロック群（ＧＯＢ）内のｍ個のマクロブロックで、置換するステップ
を有する
ことを特徴とする請求項４記載の方法。
【請求項６】
ｍ＝１１、ｎ＝９であり、
前記領域は、それぞれ、ＣＰイメージ内の１個の１／４象限領域を表す
ことを特徴とする請求項５記載の方法。
【請求項７】
ｍ＝７又はｍ＝８、ｎ＝６であり、
前記領域は、それぞれ、ＣＰイメージ内の１個の１／８象限領域を表す
ことを特徴とする請求項５記載の方法。
【請求項８】
ビデオ符号化標準により、所定の順番のマクロブロックを含む複数の符号化ビデオ信号から符号化対象連続的存在（Conitnuou Picture:CP）イメージ（以下、ＣＰイメージと称する）を形成する装置において、
前記マクロブロックは、それぞれのエンドポイント・ビデオイメージに対応し、多地点ビデオ・カンファレンスに参加しているエンドポイントから受信した符号化ビデオ信号を含み、
（Ａ）  前記符号化ビデオ信号を復号化する復号化器と、
（Ｂ）  前記符号化された符号化ビデオ信号を空間的に混合するミキシング／スケーリングユニットと、
その結果、前記エンドポイントのビデオイメージにそれぞれ関連する領域から構成される複数のＣＰイメージが形成され、
（Ｃ）  前記ＣＰイメージを符号化する複数の符号化器と、
（Ｄ）  前記符号化されたＣＰイメージのマクロブロックを、再配列し、前記符号化対象ＣＰイメージを形成するリパッカーと
を有する
ことを特徴とする符号化対象連続的存在（ＣＰ）イメージを生成する装置。
【請求項９】
前記符号化ＣＰイメージと符号化対象ＣＰイメージは、それぞれ、２２個のマクロブロックを有するブロック群（Group of Block (GOB)）を１８個有するＣＩＦフォーマットでスタック形式で配置され、
その結果、最初の９個のブロック群（ＧＯＢ）は、上部領域を表し、最後の９個のブロック群（ＧＯＢ）は、下部領域を表す
ことを特徴とする請求項８記載の装置。
【請求項１０】
前記リパッカーは、第１の符号化ＣＰイメージの領域高さを表すｎ個の連続するブロック群（ＧＯＢ）内の領域幅を表すｍ個のマクロブロックを、第２の符号化ＣＰイメージからのｎ個の連続するブロック群（ＧＯＢ）内のｍ個のマクロブロックで、置換する
ことを特徴とする請求項９記載の装置。
【請求項１１】
ｍ＝１１、ｎ＝９であり、
前記領域は、それぞれ、ＣＰイメージの１個の１／４象限領域を表す
ことを特徴とする請求項１０記載の装置。
【請求項１２】
ｍ＝７又はｍ＝８、ｎ＝６であり、
前記領域は、それぞれ、ＣＰイメージ内の１個の１／８象限領域を表す
ことを特徴とする請求項１０記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ・カンファレンスに関し、特に、多地点通信制御ユニット（Multipoint Control Unit (MCU)）内の連続的存在（Continuous Presence (CP)）のイメージを形成する方法に関する。
【背景技術】
【０００２】
リアルタイムで動くピクチャの伝送は、いくつかのアプリケーションで用いられている。例えば、テレビ会議（ビデオ・カンファレンス）、ネット・ミーティング、テレビ放送、テレビ電話である。
【０００３】
しかし、動くピクチャを表示することは大量の情報を必要とする。これは、デジタル動画像（ビデオ）が、通常８ビット（１バイト）でピクチャ内の各画素を表すことにより記述されるからである。このような圧縮前の動画像（ビデオ）データは大量のビット容量となり、従来の通信ネットワーク／伝送ラインを介してリアルタイムで伝送することはできない。帯域が限られているからである。
【０００４】
かくして、リアルタイムで動画像を伝送するには、大幅なデータ圧縮が必要である。しかし、データ圧縮は、ピクチャの品質と妥協して行われる。それ故に、多大な努力が圧縮技術を開発するためになされている。これにより高品質の動画像のリアルタイムの伝送が、帯域が限られたデータ接続を介しても可能となる。
【０００５】
動画像圧縮システムの主要な目的は、できるだけ少ない容量で動画像情報を表すことである。容量は、ビットで定義され、定数値としてあるいはビット／時間単位として定義される。両方の場合とも目的はビット数を減らすことである。
【０００６】
最も一般的な動画像符号化方法は、ＭＰＥＧ＊とＨ．２６＊標準に記載されている。動画像データは、伝送前に４つの主要なプロセスで処理される。すなわち、予測符号化と、変換と、量子化と、エントロピー符号化である。
【０００７】
予測符号化プロセスは、伝送すべき動画像シーケンス内の各ピクチャに必要とされるビット数を大幅に減らすことができる。この予測符号化方法は、シーケンスの一部と他の部分との類似性を利用している。予測符号化器部分は、符号化器と復号器の両方にとって公知であり、差分のみが伝送される。この差分は通常その表示よりも遙かに少ない容量でよい。予測符号化は、主に前に再構成されたピクチャからのピクチャ・コンテンツに基づいて行われる。このコンテンツの場所は、動きベクトルにより規定される。この予測プロセスは通常、四角形のブロックサイズ（例、１６×１６画素）上で実行される。
【０００８】
ビデオ・カンファレンス・システムにより、複数のカンファレンス・サイトでオーディオ情報、ビデオ情報、データ情報の瞬時の交換が可能となる。このようなシステムは、多地点通信制御ユニット（Multipoint Control Unit：ＭＣＵ）として公知である。多地点通信制御ユニットは、切りえ機能を実行し、これにより複数のサイトがカンファレンス内で相互に通信することが可能となる。多地点通信制御ユニット（ＭＣＵ）は、複数のサイトをリンクするが、これは、サイトからカンファレンス信号のフレームを受信し、この受信した信号を処理し、この処理された信号を適宜のサイトに再度送信することにより、行う。カンファレンス信号は、オーディオ情報、ビデオ情報、データ情報、制御情報を含む。切り換え型のカンファレンス（switched conference）においては、１つのカンファレンス・サイトからのビデオ信号、通常最も声の大きい話者からの信号が、各参加者にブロードキャスト（放送）される。連続的存在型カンファレンス（continuous presence conference）においては、複数のサイトからのビデオ信号を空間的に（画面内で）混合し、合成ビデオ信号を生成し、カンファレンスの参加者が見えるようにしている。連続的存在（continuous presence）すなわち合成イメージ（combined image）は、合成されたピクチャであり、このピクチャは、カンファレンスの参加者からの、生の動画ストリーム、静止画、メニューまたは他のビジュアルイメージを含む。
【０００９】
一般的な連続的存在型カンファレンスにおいては、ビデオ・ディスプレイは、複数の領域（例えば１／４象限領域）からなる合成レイアウトに分割される。サイトは、領域内に表示するために、カンファレンスの設定時に、カンファレンスに接続されたサイトから選択される。一般的な合成レイアウトは、４個、９個、１６個の領域を含む。レイアウトが選択され、その後会議の間中、固定される。
【００１０】
ある種のカンファレンス装置は、様々な合成信号あるいはビデオ混合画面を提供する。その結果、各サイトは、複数のサイトの様々な混合画面を見ることができる。別のカンファレンス装置は、音声により活性化される１／４象限領域の選択プロセスを用いて、サイトと特定の１／４象限領域とを関連付ける。この装置により、カンファレンスの参加者は、固定された動画混合サイトのみならず、音声活性化により選択されたサイトも見ることができる。しかし、このレイアウトは、領域の数あるいは１／４象限領域の数の観点から、会議の間中、固定されている。
【００１１】
【特許文献１】米国特許第５，６００，６４６号明細書
【特許文献２】ヨーロッパ特許第６，４０４，７４５号明細書
【特許文献３】米国特許出願第１０／６０１，０９５号
【００１２】
図１を参照すると、特許文献１に開示された多地点通信制御ユニット（ＭＣＵ）１０の実施例のブロック図が示されている。多地点通信制御ユニット（ＭＣＵ）１０は、特許文献２に開示されたＨ．３２３機能を有する。さらに、ＭＣＵ内のビデオ処理が強化されているが、これについては後述する。多地点通信制御ユニット（ＭＣＵ）１０に対し記載した特徴は、タンベルグ（Tandberg）社の多地点通信制御ユニット（ＭＣＵ）で実現できる。
【００１３】
多地点通信制御ユニット（ＭＣＵ）１０は、少なくとも１個のネットワーク・インターフェース・ユニット（Network Interface Unit: ＮＩＵ）１２０と、少なくとも１個のブリッジ処理ユニット（Bridge Processing Unit: ＢＰＵ）１２２と、動画処理ユニット（Video Processing Unit: ＶＰＵ）１２４と、データ処理ユニット（Date Processing Unit: ＤＰＵ）１２６と、ホスト処理ユニット（Host Processing Unit: ＨＰＵ）１３０とを有する。ホスト工業標準アーキテクチャ（host Industry Standard Architecture (ISA)）の制御バス１３２に加えて、多地点通信制御ユニット（ＭＣＵ）１０は、さらに、ネットワーク・バス１３４と、ＢＰＵバス１３６と、Ｘ−バス１３８とを有する。ＢＰＵバス１３６は、マルチ・ベンダー・インテグレーション・プロトコル（Multi-Vendor Integration Protocol (MVIP)）に適合し、ＢＰＵバス１３６とＸ−バス１３８は、ＭＶＩＰの仕様から派生したものである。ホスト処理ユニット（ＨＰＵ）１３０は、多地点通信制御ユニット（ＭＣＵ）操作に対し、管理インターフェース（management interface）を提供する。前述したＭＣＵの構成要素のそれぞれは、前掲の特許文献１、２に記載されている。
【００１４】
Ｈ．３２３の機能は、ゲートウエイ処理ユニット（Gateway Processing Unit: ＧＰＵ）１２８と、ＢＰＵ−Ｇと称する修正ＢＰＵ１２２Ａを追加することにより、提供できる。ゲートウエイ処理ユニット（ＧＰＵ）１２８は、コール・シグナリングに対しＨ．３２３プロトコルを実行し、イーサネット（登録商標）あるいは他のＬＡＮインターフェース１４０を介して、エンドポイント端末に、オーディオ・ストリーム、ビデオ・ストリーム、データ・ストリームの創設と制御を行う。ＢＰＵ−Ｇ１２２Ａは、ゲートウエイ処理ユニット（ＧＰＵ）１２８から受信したオーディオ・パケット、ビデオ・パケット、データ・パケットを処理するようプログラムされたブリッジ処理ユニット（ＢＰＵ）１２２である。
【００１５】
多地点通信制御ユニット（ＭＣＵ）の操作を、ハイレベルで、最初に回路切り換えカンファレンスについて説明し、次にパケット交換Ｈ．３２３カンファレンスについて説明する。回路切り換えカンファレンスにおいては、Ｈ．３２０回路切り換えエンドポイント・ターミナルからのデジタル・データ・フレームは、ネットワーク・インターフェース１４２を介したネットワーク・インターフェース・ユニット（ＮＩＵ）１２０へ繋がるネットワーク・バス１３４上に存在する。ブリッジ処理ユニット（ＢＰＵ）１２２は、ネットワーク・バス１３４からのデータ・フレームを処理し、ＢＰＵバス１３６上の他のブリッジ処理ユニット（ＢＰＵ）１２２が利用可能なデータ・フレームを生成する。ブリッジ処理ユニット（ＢＰＵ）１２２は、このデータ・フレームからオーディオ情報を抽出する。
【００１６】
ブリッジ処理ユニット（ＢＰＵ）１２２は、圧縮されたビデオ（動画）情報と混合された符号化オーディオ情報とをフレームに結合し、このフレームが、ネットワーク・バス１３４上に配置され、それぞれのＨ．３２０ターミナル（端末）に送信される。
【００１７】
複数のオーディオビジュアル端末が、異なる伝送レートあるいは異なる圧縮アルゴリズムで動作するか、あるいは合成イメージに混合する場合には、複数のビデオ入力が、ビデオ処理ユニット（ＶＰＵ）１２４に送られる。そこで、ビデオ入力が解凍（脱圧縮）され、混合され、１個のビデオ・ストリームに再度圧縮される。この１個のビデオ・ストリームは、ビデオ・ストリームを切り換えるＢＰＵ１２２を介して、適宜のエンドポイント・ターミナルに戻される。
【００１８】
パケット・ベースのＨ．３２３カンファレンスにおいては、ゲートウエイ処理ユニット（ＧＰＵ）１２８は、オーディオ・パケット、ビデオ・パケット、データ・パケットを、ネットワーク・バス１３４に送信（利用可能に）する。このデータ・パケットは、データ処理ユニット（ＤＰＵ）１２６で処理される。ＢＰＵ−Ｇ  １２２Ａは、ネットワーク・バス１３４上のオーディオ・パケットとビデオ・パケットを処理して、オーディオ、ビデオのブロードキャスト混合情報を生成し、それをネットワーク・バス１３４上に送信して、それぞれのエンドポイント・ターミナルに、ゲートウエイ処理ユニット（ＧＰＵ）１２８を介して、送信する。さらに、ＢＰＵ−Ｇ  １２２Ａは、オーディオ・パケットとビデオ・パケットを処理してデータ・フレームを生成する。このデータ・フレームは、ＢＰＵバス１３６上のブリッジ処理ユニット（ＢＰＵ）１２２が利用可能である。かくして多地点通信制御ユニット（ＭＣＵ）１０は、ゲートウェイ機能を提供する。これにより、通常のブリッジ処理ユニット（ＢＰＵ）１２２とＢＰＵ−Ｇ  １２２Ａが、Ｈ．３２０（回路交換）端末とＨ．３２３（パケット交換）端末との間で、透明にオーディオ、ビデオ情報を交換できる。
【００１９】
基本的なカンファレンス・ブリッジング機能（conference bridging function）を可能とする多地点通信制御ユニット（ＭＣＵ）１０の構成要素について上記したが、次に、ビデオ処理ユニット（ＶＰＵ）１２４により提供されるフレキシブル性を図２の機能ブロックを参照して詳述する。多地点通信制御ユニット（ＭＣＵ）１０において、同一のカンファレンスにある最大５個のオーディオビジュアル端末からの圧縮ビデオ情報は、特定のビデオ処理ユニット（ＶＰＵ）１２４に、ＢＰＵバス１３６を介して配送（ルーティング）される。このビデオ処理ユニット（ＶＰＵ）１２４は、５個のビデオ圧縮プロセッサ（ＶＣＰ０−ＶＣＰ４）を有する。各ビデオ圧縮プロセッサは、画素・スケーリング・ブロック（１０４−ｉ、１０８−ｉ）と、ビデオ復号化器／符号化器対（１０２−ｉ、１０６−ｉ）を有する。
【００２０】
ビデオ復号化器／符号化器対１０２−ｉ、１０６−ｉは、カンファレンス内の各特定のサイトに関連する圧縮ビデオ情報ストリームに割り当てられる。ビデオ復号化器１０２−ｉは、圧縮されたビデオ情報を、その関連サイトの符号化アルゴリズムに合ったアルゴリズムを用いて、復号化する。ビデオ復号化器１０２−ｉの一部として、フレーミング、パケット、チェックサム（これらは、伝送プロトコルの一部でもある）を決定する処理装置が含まれる。プロセッサが符号化したビデオ・ストリームは、複数のサイト（例、会議の６個以上のサイトを有する連続的存在アプリケーション）に割り当てることができる。さらに、ビデオ復号化器／符号化器対１０２−ｉ、１０６−ｉは、カンファレンス内で、サイトを切り換えることができる。
【００２１】
復号化されたビデオ情報（例、画素）は、必要によっては、画素・スケーリング・ブロック１０４−ｉにより、スケール・アップあるいはスケール・ダウンされる。これにより、カンファレンス内の他のサイトの画素解像度の要件に合わせ、このサイトが、スケール・アップあるいはスケール・ダウンされた画素を符号化する。例えば、デスクトップのシステムは、２５６×２４０画素の解像度で符号化できるが、Ｈ．３２０端末は、共通中間フォーマット（Common Intermediate Format (CIF) image）に対し、３５２×２８８画素の画素解像度が必要である。他の共通フォーマットは、クォ１／４象限共通中間フォーマット（Quarter Common Intermediate Format (QCIF)）（１７６×１４４画素）、４ＣＩＦ（７０４×５７６画素）、ＳＩＦ（３５２×２４０画素）、４ＳＩＦ（７０４×４８０画素）、ＶＧＡ（６４０×４８０画素）、ＳＶＧＡ（８００×６００画素）、ＸＧＡ（１０２４×７６８画素）を含む。
【００２２】
ビデオ処理ユニット（ＶＰＵ）１２４は、画素・バス１８２とメモリ１２３とを有する。特許文献１に開示されたシステムは、時分割多重化バスを使用する。特に、各復号化器１０２−ｊは、メモリ１２３へ接続される画素・バス１８２上に画素を出力する。各符号化器１０６−ｊは、画素・パス上のメモリ１２３から如何なるタイプのイメージも取り出すことができ、再符号化および／または空間混合、即ち合成を、行う。画素・スケーリング・ブロック１０８−ｊが、画素・バス１８２と符号化器１０６−ｊとの間に配置され、必要に応じて、サンプリングされたイメージの画素解像度を調整する。
【００２３】
次に、連続的存在アプリケーションを図３、４を参照して説明する。単純化するために、エンドポイント・ターミナル（端末）は、Ｈ．３２０端末として示す。図３において、サイト３８からのデータは、通信ネットワークを介してそれぞれのネットワーク・インターフェース・ユニット（ＮＩＵ）１２０に到達する。５個のサイト３（Ａ、Ｂ、Ｃ、Ｄ、Ｅ）は、カンファレンスの際、接続されている。サイトＡ、サイトＢは、特定（同一）のネットワーク・インターフェース・ユニット（ＮＩＵ）１２０に接続されている。このネットワーク・インターフェース・ユニット（ＮＩＵ）１２０は、複数のコーデック接続（例えば、Ｔ１インターフェース）をサポートする。他のサイトＣ、Ｄ、Ｅは、１個のコーデック接続（例、ＩＳＤＮインターフェース）のみをサポートするネットワーク・インターフェース・ユニット（ＮＩＵ）１２０に接続される。各サイト３８は、デジタル・データからなる１個あるいは複数個のオクテット（octet）を、ネットワーク−バス１３８上に、非同期Ｈ．２２１フレーム化データとして送出する。ブリッジ処理ユニット（ＢＰＵ）１２２は、その後、Ｈ．２２１フレーム化処理とオクテット整合を決定する。この整合したデータは、ＢＰＵバス１３６上の他の全てのユニットがアクセスできる。ブリッジ処理ユニット（ＢＰＵ）１２２は、Ｈ．２２１フレームからオーディオ情報を抽出し、このオーディオ情報を１６ビットのＰＣＭデータに復号化する。この復号化されたオーディオ・データは、ＢＰＵバス１３６上に送信され、他のカンファレンス・サイトからのオーディオ・データと混合される。
【００２４】
整合したＨ．２２１フレームを、ビデオ処理ユニット（ＶＰＵ）１２４が受信し、ビデオ圧縮プロセッサ（video compression processor (VCP)）と称する符号化／復号化要素で処理する。ビデオ処理ユニット（ＶＰＵ）１２４は、５個のビデオ圧縮プロセッサ（ＶＣＰ）を有し（図２）、これらは、この実施例では、サイトＡ、Ｂ、Ｃ、Ｄ、Ｅに割り当てられる。ビデオ処理ユニット（ＶＰＵ）１２４上の、サイトＥに割り当てられたＶＣＰ機能を図４に示す。圧縮されたビデオ情報（Ｈ．２６１）は、ビデオ処理ユニット（ＶＰＵ）により、Ｈ．２２１フレームから抽出され、イメージＸとして復号化される。復号化されたビデオ・イメージＸが、画素・バス１８２上に、スケーリング・ブロック（図示せず）を介して送出される。図４は、サイトＡ、Ｂ、Ｃ、Ｄ、Ｅからの復号化されたビデオ・フレームを有する画素・バス１８２を示す。これらのビデオ・フレームは、連続的に、それぞれのＲＡＭアドレスにより指定され、メモリ１２３から連続的に取り出されたものである。サイトＥに割り当てられたビデオ圧縮プロセッサ（ＶＣＰ）は、サイトＡ、Ｂ、Ｃ、Ｄから復号化されたビデオ・フレームを受信する。このビデオ・フレームはその後、１個の合成イメージＩにタイル貼りされる（空間的に混合される）。このタイル貼りされたイメージＩは、Ｈ．２２１フレーム化処理ではＨ．２６１ビデオ（動画）として符号化され、ＢＰＵバス１３６上に送出され（図３）、上記したように、ブリッジ処理ユニット（ＢＰＵ）で処理される。
【００２５】
上記の説明から分かるように、トランスコーディング（transcoding）は、かなりの処理資源を必要とする。その理由は、生の画素・データを混合し、その後符号化して混合ビュー（即ち、連続的存在ビュー）を形成しなければならないからである。セルフ・ビュー（self view：参加者が自己のピクチャを見ること）を回避するため、すなわち、連続的存在ビューが、ビデオフレームが送信されるそれぞれの参加者の自己のピクチャを含むのを回避するために、多地点通信制御ユニット（ＭＣＵ）は、連続的存在ビュー内の各ピクチャ用に少なくとも１個の符号化器を有しなければならない。１６個の連続的存在が可能となるためには、ＭＣＵは、少なくとも１６個の符号化器を有しなければらない。
【発明の開示】
【発明が解決しようとする課題】
【００２６】
本発明の目的は、セルフ・ビューを回避するために、必要な符号化器の数と処理時間を低減する方法と装置を提供することである。
【課題を解決するための手段】
【００２７】
本発明の第１の態様によれば、上記の目的と他の利点は、請求項１に記載した符号化された対象の連続的存在（ＣＰ）イメージを生成する方法によって得られる。
【００２８】
本発明の第２の態様によれば、上記の目的および他の利点は、請求項８に記載した符号化された対象の連続的存在（ＣＰ）イメージを形成する装置を、多地点通信制御ユニット（ＭＣＵ）内に配置することにより、得られる。
【実施例】
【００２９】
本発明は、ＩＴＵのＨ．２６＊標準のビット構造を用いて、セルフ・ビューのないＣＰビューを生成するために、ＭＣＵ内の処理時間と処理要件を低減する。使用されるビット構造の特徴を理解するために、Ｈ．２６３標準によるピクチャ・ブロック構造を下記する。
【００３０】
Ｈ．２６３標準によれば、各ピクチャは、８×８個の画素からなるブロックに分割される。これらのブロックは、マクロブロックになるよう配置され、画素のルミネセンスに対しては、１６（８×８）個のブロックを用い、画素のクロミナンスに対しては、４（２×２）個のブロックを用いる。ブロック群（Group Of Block: ＧＯＢ）は、通常２２個のマクロブロックからなる。ピクチャ当たりのブロック群（ＧＯＢ）の数は、サブ−ＱＣＩＦに対しては６個、ＱＣＩＦに対しては９個、ＣＩＦ、４ＣＩＦ、１６ＣＩＦに対しては１８個である。ブロック群（ＧＯＢ）の番号付けは、ブロック群（ＧＯＢ）を垂直方向に、即ち、最上部のＧＯＢ（番号０）からスタートして、最下部のＧＯＢで終了するよう、スキャンする。ピクチャ内のＧＯＢの配列の一例を図５のＣＩＦピクチャ・フォーマットに示す。各ＧＯＢのデータは、ＧＯＢヘッダと、その後のマクロブロックのデータからなる。ＧＯＢのデータは、ＧＯＢ当たり、ＧＯＢの番号を増加する方法で送信する。ＧＯＢのスタートは、ブロック群スタート・コード（Group of Block Start Code (GBSC)）で特定される。ＧＯＢ層の構造を図６に示す。
【００３１】
各マクロブロックのデータは、マクロブロック・ヘッダと、その後のブロック用のデータからなる。この構造を図７に示す。ＣＯＤは、これらのピクチャの各マクロブロックに対して、「ＩＮＴＲＡ」のタイプでない場合にのみ、ピクチャに表われる。ビットは、「０」に設定されている時は、マクロブロックが符号化されていることを示す。「１」に設定されている時は、このマクロブロックに対しては更なる情報は送信されないことを示す。この場合、復号化器は、マクロブロックを、全ブロックの動きベクトルがゼロに等しく、係数データのない「ＩＮＴＥＲ」マクロブロックとして、処理しなければならない。
【００３２】
ＣＯＤが「０」に設定されている場合には、マクロブロックのデータ部分は、マクロブロック内のそれぞれのブロックの情報を含む。この情報は、動きベクトルにより表され、含まれる画素が等しい前のピクチャ内の画素の位置を示す。
【００３３】
従来は、ＣＰピクチャ内にセルフ・ビューが含まれるのを回避するために、各参加者に対する特殊な符号化が必要であり、多地点通信制御ユニット（ＭＣＵ）内の各出力データ・ストリームに対し、１個の符号化器が必要であった（図２）。これに対し、本発明は、既に符号化されたビデオ・データのマクロブロック構造を利用し、受信器に依存してＣＰピクチャの混合情報を得る。本発明の以下の実施例において、５か所のエンドポイント・サイトが、ＣＩＰフォーマットのビデオ・ピクチャを捕獲し、Ｈ．２６３標準に従ってピクチャを符号化するビデオ・カンファレンスを考える。多地点通信制御ユニット（ＭＣＵ）内で、それぞれの参加者からのデータ・ストリームは、Ｈ．２６３標準に従って、それぞれの多地点通信制御ユニット（ＭＣＵ）入力に関連する復号化器により復号化される。復号化後、各参加者からの生の画素・データが、多地点通信制御ユニット（ＭＣＵ）内の内部バス上で得られ、混合（mixing）と符号化／復号化（transcoding）がなされる。
【００３４】
５人の参加者の場合、それぞれのサイトに戻されるべき混合ピクチャのＣＰ４フォーマットを選択する。この混合フォーマットは、「ベストインプレッション」原理（”Best Impression” principals）に従って、多地点通信制御ユニット（ＭＣＵ）により選択される。この「ベストインプレッション」原理は、特許文献３に開示されている。
【００３５】
この実施例によれば、２個のＣＰ４イメージ（即ち、ＣＰイメージ１とＣＰイメージ２）が、それぞれの符号化器により符号化される（図８）。ＣＰイメージ１は、サイト１、２、３、４から受信した複数のイメージを含む。ＣＰイメージ２は、サイト５から受信したイメージを含み、１個のイメージが１／４象限領域（quadrant）にあり、残りの３個の１／４象限領域は空である。ＣＰイメージを符号化し、この符号化されたデータを上記のブロックシステムに配置すると、１／４象限領域の境界は、ブロック群（ＧＯＢ）内のマクロブロック境界と一致する。ＣＰイメージ１に対して、第１のブロック群（ＧＯＢ）内の最初の１１個のマクロブロックは、サイト１のイメージからのデータを含み、第１のＧＯＢ内の最後の１１個のマクロブロックは、サイト２のイメージからのデータを含む。
【００３６】
本発明によれば、多地点通信制御ユニット（ＭＣＵ）は、受信器に応じて、各ＣＰイメージ内のマクロブロックを再配列する。一例として、サイト４に送信されたＣＰイメージにおいて、ＣＰイメージ１の最後の９個のブロック群（ＧＯＢ）のそれぞれの最後の１１個のマクロブロックは、それぞれ、ＣＰイメージ２の最初の９個のブロック群（ＧＯＢ）のそれぞれの最初の１１個のマクロブロックにより置換される。その結果、新たに復号化されたＣＰイメージができあがる。このイメージは、サイト４から受信したイメージの代わりに、サイト５から受信したイメージを含む。このＣＰイメージは、サイト４に戻され、その結果、そのサイトにおけるセルフ・ビューを回避できる。
【００３７】
対応する再置換と再配置が、他のサイトにそれぞれ関連する４個の他のＣＰイメージに対して行われる。
【００３８】
図９は、本発明により多地点通信制御ユニット（ＭＣＵ）の内部アーキテクチャの一例を示す。このアーキテクチャが、本発明により、図２に示した従来のビデオ処理ユニット（ＶＰＵ）１２４の代わりに使用される。画素・バス１８２、メモリ１２３、画素・スケーリング・ユニット１０４、１０８が、図９のミキシング／スケーリング・ユニット（ＭＳＵ）１５６で置換されている。図９の第１データバス１７６と第２データ・バス１７７は、交互に１本の共通データ・バスに併合される。図９は、実際の構成とは異なるが、本発明の関連する装置のみを示す。
【００３９】
入力データ・ストリーム１７１、１７２、１７３、１７４、１７５は、復号化器１５１、１５２、１５３、１５４、１５５により、それぞれ復号化される。各サイトに１個の復号化器が設けられている。この復号化処理は、使用される符号化標準に従って行われ、本発明の場合、Ｈ．２６３標準である。復号化されたデータは、ＰＣＭデータの形態であり、第１データバス１７６上のミキシング／スケーリング・ユニット（ＭＳＵ）１５６は、それにアクセス可能である。
【００４０】
ミキシング／スケーリング・ユニット（ＭＳＵ）１５６は、第１、第２、第３、第４のサイトからのＰＣＭデータである入力データ・ストリーム１７１、１７２、１７３、１７４を、空間的に混合（mixing）して、第１のＣＰイメージを形成する。第２のＣＰイメージは、第１の１／４象限領域内にサイト５からのＰＣＭデータ１７５を配置し、残りの３個の１／４象限領域を空にするか、あるいはダミーのデータを入れて、形成する。この２個の空間的に混合されたイメージのＰＣＭデータは、第２データ・バス１７７上の第１符号化器１５７と第２符号化器１５８にアクセス可能である。
【００４１】
符号化器１５７、１５８は、ミキシング／スケーリング・ユニット（ＭＳＵ）１５６により生成されたＣＰイメージのＰＣＭデータを、第２データ・バス１７７から取りだし、各イメージを符号化する。この符号化プロセスの結果、ブロック群（ＧＯＢ）内で組み立てられた複数のマクロブロックが得られる。Ｈ．２６３標準によるＣＩＦフォーマットの場合には、ブロック群（ＧＯＢ）は２２個のマクロブロックからなり、各イメージは１８個のブロック群（ＧＯＢ）からなる。このイメージを符号化した後、ブロック群（ＧＯＢ）は、引き続き、関連するバッファー１５９、１６０内にそれぞれ挿入される。バッファー１５９、１６０のサイズは、十分大きく、少なくとも１個のイメージのブロック群（ＧＯＢ）を記憶できる。バッファー１５９、１６０の出力は、第３データ・バス１７８に接続され、この第３データ・バス１７８は、リパッカー１６１、１６２、１６３、１６４、１６５の入力に接続される。
【００４２】
符号化イメージを表すビットの数は、一定ではなく、１つのイメージから別のイメージへの動きとイメージのコンテンツに応じて、変わる。ビットの数も、イメージがＩＮＴＲＡ符号化されるか、あるいはＩＮＴＥＲ符号化されるかによって、すなわち同一の画像内の近隣のマクロブロックからの予測符号化、あるいは前のイメージからの予測（画像間）符号化に依存する。
【００４３】
完全に同期したピクチャの符号化データが、それぞれのバッファに挿入されると、リパッカー１６１、１６２、１６３、１６４、１６５は、マクロブロックの順番を組み換えて、関連する出力１８１、１８２、１８３、１８４、１８５用にそれぞれ必要とされる連続的存在（ＣＰ）イメージを生成する。リパッカーは、マクロブロックを、ブロック群（ＧＯＢ）とマクロブロックのヘッダの手段により、識別し分離することができる。各ブロック群（ＧＯＢ）のスタートは、ブロック群スタートコード（ＧＢＳＣ：Group of Block Start Code）と称する独自のスタート・コードと、その後に続くブロック群（ＧＯＢ）番号を示す群番号（ＧＮ：Group Number）により指定される。マクロブロックのヘッダ内では、ＣＯＤは、マクロブロックが符号化されているか否かを示す。ＣＯＤが「１」の時には、そのマクロブロックにはこれ以上の情報は存在しないことを示し、全ブロックの動きベクトルがゼロに等しく、係数データを具備しない。ＣＯＤが「０」の場合には、マクロブロックのさらなるデータが続く。更なるデータの一部は、可変長であり、別の符号が、各符号の長さが規定されるよう、定義される。
【００４４】
マクロブロックは、識別可能であり、一時的にバッファー１５９、１６０内に記憶されるために、リパッカー１６１、１６２、１６３、１６４、１６５は、如何なる順番でもマクロブロックを読み出すことができる。これにより、５箇所のサイトのイメージからＣＰ４イメージの如何なる変形例も形成できる。一例として、リパッカー１６４が、第４サイトに対しＣＰイメージを生成する場合、即ち、サイト４出力１８４を出力する場合を考える。第１バッファー１５９は、ＣＰイメージ１の符号化データを有し、第２バッファー１６０は、ＣＰイメージ２の符号化データを有する。リパッカー１６４は、ＣＰイメージ１のブロック群（ＧＯＢ）１−９を、第１バッファー１５９内で起こるのと同一の順番で、取り出し、新たなＣＰイメージを形成する。しかし、ブロック群（ＧＯＢ）１０を生成する時には、リパッカー１６４は、第１バッファー１５９内でブロック群（ＧＯＢ）１０の１１個の第１マクロブロックと、それに続いて、第２バッファー１６０内のブロック群（ＧＯＢ）１の１１個の第１マクロブロックとを、識別し取り出す。さらに、ブロック群（ＧＯＢ）１１は、第１バッファー１５９内のブロック群（ＧＯＢ）１１の１１個の第１マクロブロックと、それに続いて、第２バッファー１６０内のブロック群（ＧＯＢ）２の１１個の第１マクロブロックを取り出すことにより、生成される。残りの７個のブロック群（ＧＯＢ）も同様に形成され、ブロック群（ＧＯＢ）１８で終了する。このブロック群（ＧＯＢ）１８は、第１バッファー１５９内のブロック群（ＧＯＢ）１８の１１個の第１マクロブロックと、それに続いて、第２バッファー１６０内のブロック群（ＧＯＢ）９の１１個の第１マクロブロックを取り出すことに、生成される。
【００４５】
リパッカー１６１、１６２、１６３、１６４、１６５は、バッファー１５９、１６０からマクロブロックを取り出すよう、プログラムされるが、これは、一定の順番、あるいは制御ユニット（図示せず）により制御されるマクロブロックの順番に従って、行われる。これにより、リパッカーは、さまざまなＣＰイメージを形成できる。
【００４６】
図１０は、本発明の方法の一実施例を表すブロック図である。
【００４７】
図１０に示す方法のステップは、ビデオ符号化標準に従った符号化された対象連続的存在（ＣＰ）イメージ（coded target Continuous Presence (CP) image）を、所定の順番のマクロブロックを含む複数の符号化ビデオ信号から形成する方法を示す。各マクロブロックは、それぞれのエンドポイント・ビデオ・イメージに対応する符号化ビデオ信号を含む。このエンドポイント・ビデオ・イメージは、マルチポイント・ビデオ・カンファレンスに参加するエンドポイントから受信されたものである。
【００４８】
本発明の方法は、ステップ２０２で開始する。
【００４９】
最初に、復号化ステップ２０４が実行される。このステップにおいて、ビデオ信号は、対応するエンドポイント・ビデオ・イメージに復号化される。
【００５０】
次に、ミキシング（混合）・ステップ２０６において、エンドポイント・ビデオ・イメージは、空間的に混合されて、複数のＣＰイメージとなる。各ＣＰイメージは、各エンドポイント・ビデオ・イメージに関連する領域からなる。
【００５１】
次に、符号化ステップ２０８において、ＣＰイメージは、それぞれ、複数の符号化ＣＰイメージに符号化される。このステップは、ビデオ符号化標準に従ったマクロブロックの所定の順番を確立し、領域境界とマクロブロック境界を合併する。
【００５２】
これらの３個の前段階のステップ２０４、２０６、２０８の後、形成ステップ２１０が実行される。形成ステップ２１０において、符号化された目標ＣＰイメージが、所定の方法あるいは制御しながらの方法で、マクロブロックの前記順番を再度配列することにより、形成される。
【００５３】
形成ステップ２１０は、第１の符号化ＣＰイメージの領域高さを表すｎ個の連続するブロック群（ＧＯＢ）内の領域幅を表す最初のｍ個のマクロブロックを、第２の符号化ＣＰイメージからのｎ個の連続するブロック群（ＧＯＢ）内のｍ個のマクロブロックで、置換するステップを含む。
【００５４】
この方法は、ステップ２１２で終了する。
【００５５】
他の構成として、図１０を参照して説明したプロセスの上記の３個の予備的ステップ、すなわち復号化ステップ２０４、ミキシング・ステップ２０６、符号化ステップ２１０は、１個の要求ステップ（図示せず）で置換してもよい。この要求ステップでは、エンドポイントは、ビデオ符号化標準、ある解像度、ビット・レート、スケーリングに従って、それぞれのエンドポイント・ビデオ・イメージを符号化するよう、要求される。
【００５６】
最も基本的な形態においては、本発明の方法は、形成ステップ２１０を含むだけである。
【００５７】
上記した実施例は、Ｈ．２６３標準によるＣＩＦフォーマットのＣＰ４イメージの形成に関する。しかし、本発明の基本的原理を、他のフォーマットのＣＰイメージにも適用できる。一例として、本発明は、ＣＰ９イメージを形成する際にも用いられる。各ブロック群（ＧＯＢ）（ＣＩＦ、Ｈ．２６３の場合）内のイメージ境界は、７’番目と１４’番目（あるいは８’番目と１５’番目、あるいは７’番目と１５’番目）のマクロブロックの後に見出される。
【００５８】
いずれの場合にも、１個のリパッカー（あるいは少なくとも１個のリパッカー手順）が、各多地点通信制御ユニット（ＭＣＵ）出力に必要である。符号化器の数は、ＣＰピクチャ内の領域数とＣＰイメージの領域を満たすサイトの数の関係に依存する。各サイトに対し、１個の領域を形成するのに十分な数の符号化器を有さなければならない。ＣＰ４と８個のサイトの場合、２個の符号化器で、全部で８個の１／４象限領域のそれぞれ内の各サイトに対し、１つの領域を配置するのに、十分である。しかし、サイトの数を９個に増やすことは、第９領域が存在する第３のＣＰ４イメージを形成するために、さらに１個の符号化器が必要である。
【００５９】
本発明のより一般的な実施例においては、復号化処理とスケーリング／ミキシング処理は、多地点通信制御ユニット（ＭＣＵ）内で実行する必要はない。その代わりに、エンドポイントは、標準、解像度、ビット・レート、スケーリングに従って、符号化イメージを送信するよう、要求される。来入データ・ストリームのマクロブロックは、その後直接バッファ（好ましくは各データ・ストリームに対し１個のバッファ）内に入力され、リパッカーが、予めプログラムされたあるいは制御された手順に従って、マクロブロックを再度配置し、セルフ・ビューのないＣＰイメージを形成し、それぞれのカンファレンスのサイトに送信する。一例として、カンファレンスに５個のサイトが参加している場合を考える。ＣＰ４のビューは、エンドポイントが、符号化する前に、それぞれのイメージを全体イメージ内の１／４象限領域の１個内に配置することを、要求する。この要求は、標準、解像度、ビット・レート、スケーリングのような符号化情報と共に、エンドポイントに要求される。リパッカーは、マクロブロックがそれぞれのバッファ内に存在する場合には、来入データ・ストリームのマクロブロックを再配置できる。
【００６０】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。
【図面の簡単な説明】
【００６１】
【図１】多地点通信制御ユニット（ＭＣＵ）のブロック図（従来技術）。
【図２】ビデオ処理ユニット（ＶＰＵ）の一実施例のブロック図（従来技術）。
【図３】連続的存在（ＣＰ）カンファレンス用のデータの流れを表す多地点通信制御ユニット（ＭＣＵ）のブロック図（従来技術）。
【図４】連続的存在（ＣＰ）カンファレンスで、イメージがタイル貼りされた状態を表すブロック図（従来技術）。
【図５】共通中間フォーマト（ＣＩＦ）ピクチャ内のブロック群（ＧＯＢ）の配置を表すブロック図。
【図６】Ｈ．２６３標準によるブロック群（ＧＯＢ）層を表す図。
【図７】Ｈ．２６３標準によるマクロブロック層を表す図。
【図８】本発明の一実施例で使用される３個の連続的存在（ＣＰ）イメージを表すブロック図。左から、ＣＰイメージ１、ＣＰイメージ２、サイト４に送信された再配置されたＣＰイメージ。
【図９】本発明の一実施例を表すロック図。
【図１０】本発明の方法の一実施例を表すフローチャート図。
【符号の説明】
【００６２】
１０  多地点通信制御ユニット（ＭＣＵ）
１４  ＭＣＵ
３８  サイト
１２０  ネットワーク・インターフェース・ユニット（ＮＩＵ）
１２２  ブリッジ処理ユニット（ＢＰＵ）
１２２Ａ  ＢＰＵ−Ｇ
１２４  ビデオ処理ユニット（ＶＰＵ）
１２６  データ処理ユニット（ＤＰＵ）
１２６  データ処理ユニット（ＤＰＵ）
１２８  ゲートウエイ処理ユニット（ＧＰＵ）
１３０  ホスト処理ユニット（ＨＰＵ）
１３２  制御バス
１３４  ネットワーク・バス
１３６  ＢＰＵバス
１３２  制御バス
１３８  Ｘ−バス
１４０  ＬＡＮインターフェース
１４２  ネットワーク・インターフェース
１０２−ｉ，１０６−ｉ  ビデオ復号化器／符号化器対
１０２−ｉ  ビデオ復号化器
１０２−ｊ  復号化器
１０４−ｉ，１０８−ｉ  画素・スケーリング・ブロック
１０６−ｊ  符号化器
１０８−ｉ  画素・スケーリング・ブロック
１０８−ｊ  画素・スケーリング・ブロック
１８２  画素・バス
１２３  メモリ
１０２−ｊ  復号化器
ＧＯＢ  ブロック群（Group Of Blocks）
１７１−１７４  入力データ・ストリーム
１７６  第１データ・バス
１７７  第２データ・バス
１７８  第３データ・バス
１５１−１５５  復号化器
１５６  ミキシング／スケーリング・ユニット（ＭＳＵ）
１５７  第１符号化器
１５８  第２符号化器
１５７，１５８  符号化器
１５９，１６０  バッファー
１６１−１６５  リパッカー
１８１−１８５  出力
２０２  開始
２０４  ビデオ信号を復号化する
２０６  ＥＰイメージを空間的に混合する
２０８  ＣＰイメージを符号化する
２１０  復号化された対象ＣＰイメージを形成する
２１２  終了
【図１】
2007522761.tif 000003
【図２】
2007522761.tif 000004
【図３】
2007522761.tif 000005
【図４】
2007522761.tif 000006
【図５】
2007522761.tif 000007
【図６】
2007522761.tif 000008
【図７】
2007522761.tif 000009
【図８】
2007522761.tif 000010
【図９】
2007522761.tif 000011
【図１０】
2007522761.tif 000012
【国際調査報告】
2007522761.tif 000013
2007522761.tif 000014