JP4582659B2 - コンティニュアス・プレゼンス・イメージを生成する方法と装置 - Google Patents

コンティニュアス・プレゼンス・イメージを生成する方法と装置 Download PDF

Info

Publication number
JP4582659B2
JP4582659B2 JP2006553078A JP2006553078A JP4582659B2 JP 4582659 B2 JP4582659 B2 JP 4582659B2 JP 2006553078 A JP2006553078 A JP 2006553078A JP 2006553078 A JP2006553078 A JP 2006553078A JP 4582659 B2 JP4582659 B2 JP 4582659B2
Authority
JP
Japan
Prior art keywords
image
encoded
video
continuous presence
images
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006553078A
Other languages
English (en)
Other versions
JP2007522761A (ja
Inventor
ライア,トム,エリク
ヨハンセン,トム−イバー
Original Assignee
タンベルグ テレコム エーエス
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by タンベルグ テレコム エーエス filed Critical タンベルグ テレコム エーエス
Publication of JP2007522761A publication Critical patent/JP2007522761A/ja
Application granted granted Critical
Publication of JP4582659B2 publication Critical patent/JP4582659B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • H04N7/152Multipoint control units therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • H04N7/157Conference systems defining a virtual conference space and using avatars or agents

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
  • Investigating Or Analysing Biological Materials (AREA)
  • Detergent Compositions (AREA)
  • Polysaccharides And Polysaccharide Derivatives (AREA)
  • Organic Low-Molecular-Weight Compounds And Preparation Thereof (AREA)

Description

本発明は、ビデオ・カンファレンスに関し、特に、多地点通信制御ユニット(Multipoint Control Unit (MCU))内に連続的存在(コンティニュアス・プレゼンス)のイメージを形成する方法に関する。以下発明の詳細な説明では、Continuous Presence の訳語として、「連続的存在」を使用し、発明の名称と特許請求の範囲では、「コンティニュアス・プレゼンス」を使用する。

リアルタイムで動くピクチャの伝送は、いくつかのアプリケーションで用いられている。例えば、テレビ会議(ビデオ・カンファレンス)、ネット・ミーティング、テレビ放送、テレビ電話である。
しかし、動くピクチャを表示することは大量の情報を必要とする。これは、デジタル動画像(ビデオ)が、通常8ビット(1バイト)でピクチャ内の各画素を表すことにより記述されるからである。このような圧縮前の動画像(ビデオ)データは大量のビット容量となり、従来の通信ネットワーク/伝送ラインを介してリアルタイムで伝送することはできない。帯域が限られているからである。
かくして、リアルタイムで動画像を伝送するには、大幅なデータ圧縮が必要である。しかし、データ圧縮は、ピクチャの品質と妥協して行われる。それ故に、多大な努力が圧縮技術を開発するためになされている。これにより高品質の動画像のリアルタイムの伝送が、帯域が限られたデータ接続を介しても可能となる。
動画像圧縮システムの主要な目的は、できるだけ少ない容量で動画像情報を表すことである。容量は、ビットで定義され、定数値としてあるいはビット/時間単位として定義される。両方の場合とも目的はビット数を減らすことである。
最も一般的な動画像符号化方法は、MPEG*とH.26*標準に記載されている。動画像データは、伝送前に4つの主要なプロセスで処理される。すなわち、予測符号化と、変換と、量子化と、エントロピー符号化である。
予測符号化プロセスは、伝送すべき動画像シーケンス内の各ピクチャに必要とされるビット数を大幅に減らすことができる。この予測符号化方法は、シーケンスの一部と他の部分との類似性を利用している。予測符号化器部分は、符号化器と復号器の両方にとって公知であり、差分のみが伝送される。この差分は通常その表示よりも遙かに少ない容量でよい。予測符号化は、主に前に再構成されたピクチャからのピクチャ・コンテンツに基づいて行われる。このコンテンツの場所は、動きベクトルにより規定される。この予測プロセスは通常、四角形のブロックサイズ(例、16×16画素)上で実行される。
ビデオ・カンファレンス・システムにより、複数のカンファレンス・サイトでオーディオ情報、ビデオ情報、データ情報の瞬時の交換が可能となる。このようなシステムは、多地点通信制御ユニット(Multipoint Control Unit:MCU)として公知である。多地点通信制御ユニットは、切りえ機能を実行し、これにより複数のサイトがカンファレンス内で相互に通信することが可能となる。多地点通信制御ユニット(MCU)は、複数のサイトをリンクするが、これは、サイトからカンファレンス信号のフレームを受信し、この受信した信号を処理し、この処理された信号を適宜のサイトに再度送信することにより、行う。カンファレンス信号は、オーディオ情報、ビデオ情報、データ情報、制御情報を含む。切り換え型のカンファレンス(switched conference)においては、1つのカンファレンス・サイトからのビデオ信号、通常最も声の大きい話者からの信号が、各参加者にブロードキャスト(放送)される。連続的存在型カンファレンス(continuous presence conference)においては、複数のサイトからのビデオ信号を空間的に(画面内で)混合し、合成ビデオ信号を生成し、カンファレンスの参加者が見えるようにしている。連続的存在(continuous presence)すなわち合成イメージ(combined image)は、合成されたピクチャであり、このピクチャは、カンファレンスの参加者からの、生の動画ストリーム、静止画、メニューまたは他のビジュアルイメージを含む。
一般的な連続的存在型カンファレンスにおいては、ビデオ・ディスプレイは、複数の領域(例えば1/4象限領域)からなる合成レイアウトに分割される。サイトは、領域内に表示するために、カンファレンスの設定時に、カンファレンスに接続されたサイトから選択される。一般的な合成レイアウトは、4個、9個、16個の領域を含む。レイアウトが選択され、その後会議の間中、固定される。
ある種のカンファレンス装置は、様々な合成信号あるいはビデオ混合画面を提供する。その結果、各サイトは、複数のサイトの様々な混合画面を見ることができる。別のカンファレンス装置は、音声により活性化される1/4象限領域の選択プロセスを用いて、サイトと特定の1/4象限領域とを関連付ける。この装置により、カンファレンスの参加者は、固定された動画混合サイトのみならず、音声活性化により選択されたサイトも見ることができる。しかし、このレイアウトは、領域の数あるいは1/4象限領域の数の観点から、会議の間中、固定されている。
米国特許第5,600,646号明細書 ヨーロッパ特許第6,404,745号明細書 米国特許出願第10/601,095号
図1を参照すると、特許文献1に開示された多地点通信制御ユニット(MCU)10の実施例のブロック図が示されている。多地点通信制御ユニット(MCU)10は、特許文献2に開示されたH.323機能を有する。さらに、MCU内のビデオ処理が強化されているが、これについては後述する。多地点通信制御ユニット(MCU)10に対し記載した特徴は、タンベルグ(Tandberg)社の多地点通信制御ユニット(MCU)で実現できる。
多地点通信制御ユニット(MCU)10は、少なくとも1個のネットワーク・インターフェース・ユニット(Network Interface Unit: NIU)120と、少なくとも1個のブリッジ処理ユニット(Bridge Processing Unit: BPU)122と、動画処理ユニット(Video Processing Unit: VPU)124と、データ処理ユニット(Date Processing Unit: DPU)126と、ホスト処理ユニット(Host Processing Unit: HPU)130とを有する。ホスト工業標準アーキテクチャ(host Industry Standard Architecture (ISA))の制御バス132に加えて、多地点通信制御ユニット(MCU)10は、さらに、ネットワーク・バス134と、BPUバス136と、X−バス138とを有する。BPUバス136は、マルチ・ベンダー・インテグレーション・プロトコル(Multi-Vendor Integration Protocol (MVIP))に適合し、BPUバス136とX−バス138は、MVIPの仕様から派生したものである。ホスト処理ユニット(HPU)130は、多地点通信制御ユニット(MCU)操作に対し、管理インターフェース(management interface)を提供する。前述したMCUの構成要素のそれぞれは、前掲の特許文献1、2に記載されている。
H.323の機能は、ゲートウエイ処理ユニット(Gateway Processing Unit: GPU)128と、BPU−Gと称する修正BPU122Aを追加することにより、提供できる。ゲートウエイ処理ユニット(GPU)128は、コール・シグナリングに対しH.323プロトコルを実行し、イーサネット(登録商標)あるいは他のLANインターフェース140を介して、エンドポイント端末に、オーディオ・ストリーム、ビデオ・ストリーム、データ・ストリームの創設と制御を行う。BPU−G122Aは、ゲートウエイ処理ユニット(GPU)128から受信したオーディオ・パケット、ビデオ・パケット、データ・パケットを処理するようプログラムされたブリッジ処理ユニット(BPU)122である。
多地点通信制御ユニット(MCU)の操作を、ハイレベルで、最初に回路切り換えカンファレンスについて説明し、次にパケット交換H.323カンファレンスについて説明する。回路切り換えカンファレンスにおいては、H.320回路切り換えエンドポイント・ターミナルからのデジタル・データ・フレームは、ネットワーク・インターフェース142を介したネットワーク・インターフェース・ユニット(NIU)120へ繋がるネットワーク・バス134上に存在する。ブリッジ処理ユニット(BPU)122は、ネットワーク・バス134からのデータ・フレームを処理し、BPUバス136上の他のブリッジ処理ユニット(BPU)122が利用可能なデータ・フレームを生成する。ブリッジ処理ユニット(BPU)122は、このデータ・フレームからオーディオ情報を抽出する。
ブリッジ処理ユニット(BPU)122は、圧縮されたビデオ(動画)情報と混合された符号化オーディオ情報とをフレームに結合し、このフレームが、ネットワーク・バス134上に配置され、それぞれのH.320ターミナル(端末)に送信される。
複数のオーディオビジュアル端末が、異なる伝送レートあるいは異なる圧縮アルゴリズムで動作するか、あるいは合成イメージに混合する場合には、複数のビデオ入力が、ビデオ処理ユニット(VPU)124に送られる。そこで、ビデオ入力が解凍(脱圧縮)され、混合され、1個のビデオ・ストリームに再度圧縮される。この1個のビデオ・ストリームは、ビデオ・ストリームを切り換えるBPU122を介して、適宜のエンドポイント・ターミナルに戻される。
パケット・ベースのH.323カンファレンスにおいては、ゲートウエイ処理ユニット(GPU)128は、オーディオ・パケット、ビデオ・パケット、データ・パケットを、ネットワーク・バス134に送信(利用可能に)する。このデータ・パケットは、データ処理ユニット(DPU)126で処理される。BPU−G 122Aは、ネットワーク・バス134上のオーディオ・パケットとビデオ・パケットを処理して、オーディオ、ビデオのブロードキャスト混合情報を生成し、それをネットワーク・バス134上に送信して、それぞれのエンドポイント・ターミナルに、ゲートウエイ処理ユニット(GPU)128を介して、送信する。さらに、BPU−G 122Aは、オーディオ・パケットとビデオ・パケットを処理してデータ・フレームを生成する。このデータ・フレームは、BPUバス136上のブリッジ処理ユニット(BPU)122が利用可能である。かくして多地点通信制御ユニット(MCU)10は、ゲートウェイ機能を提供する。これにより、通常のブリッジ処理ユニット(BPU)122とBPU−G 122Aが、H.320(回路交換)端末とH.323(パケット交換)端末との間で、透明にオーディオ、ビデオ情報を交換できる。
基本的なカンファレンス・ブリッジング機能(conference bridging function)を可能とする多地点通信制御ユニット(MCU)10の構成要素について上記したが、次に、ビデオ処理ユニット(VPU)124により提供されるフレキシブル性を図2の機能ブロックを参照して詳述する。多地点通信制御ユニット(MCU)10において、同一のカンファレンスにある最大5個のオーディオビジュアル端末からの圧縮ビデオ情報は、特定のビデオ処理ユニット(VPU)124に、BPUバス136を介して配送(ルーティング)される。このビデオ処理ユニット(VPU)124は、5個のビデオ圧縮プロセッサ(VCP0−VCP4)を有する。各ビデオ圧縮プロセッサは、画素・スケーリング・ブロック(104−i、108−i)と、ビデオ復号化器/符号化器対(102−i、106−i)を有する。
ビデオ復号化器/符号化器対102−i、106−iは、カンファレンス内の各特定のサイトに関連する圧縮ビデオ情報ストリームに割り当てられる。ビデオ復号化器102−iは、圧縮されたビデオ情報を、その関連サイトの符号化アルゴリズムに合ったアルゴリズムを用いて、復号化する。ビデオ復号化器102−iの一部として、フレーミング、パケット、チェックサム(これらは、伝送プロトコルの一部でもある)を決定する処理装置が含まれる。プロセッサが符号化したビデオ・ストリームは、複数のサイト(例、会議の6個以上のサイトを有する連続的存在アプリケーション)に割り当てることができる。さらに、ビデオ復号化器/符号化器対102−i、106−iは、カンファレンス内で、サイトを切り換えることができる。
復号化されたビデオ情報(例、画素)は、必要によっては、画素・スケーリング・ブロック104−iにより、スケール・アップあるいはスケール・ダウンされる。これにより、カンファレンス内の他のサイトの画素解像度の要件に合わせ、このサイトが、スケール・アップあるいはスケール・ダウンされた画素を符号化する。例えば、デスクトップのシステムは、256×240画素の解像度で符号化できるが、H.320端末は、共通中間フォーマット(Common Intermediate Format (CIF) image)に対し、352×288画素の画素解像度が必要である。他の共通フォーマットは、クォ1/4象限共通中間フォーマット(Quarter Common Intermediate Format (QCIF))(176×144画素)、4CIF(704×576画素)、SIF(352×240画素)、4SIF(704×480画素)、VGA(640×480画素)、SVGA(800×600画素)、XGA(1024×768画素)を含む。
ビデオ処理ユニット(VPU)124は、画素・バス182とメモリ123とを有する。特許文献1に開示されたシステムは、時分割多重化バスを使用する。特に、各復号化器102−jは、メモリ123へ接続される画素・バス182上に画素を出力する。各符号化器106−jは、画素・パス上のメモリ123から如何なるタイプのイメージも取り出すことができ、再符号化および/または空間混合、即ち合成を、行う。画素・スケーリング・ブロック108−jが、画素・バス182と符号化器106−jとの間に配置され、必要に応じて、サンプリングされたイメージの画素解像度を調整する。
次に、連続的存在アプリケーションを図3、4を参照して説明する。単純化するために、エンドポイント・ターミナル(端末)は、H.320端末として示す。図3において、サイト38からのデータは、通信ネットワークを介してそれぞれのネットワーク・インターフェース・ユニット(NIU)120に到達する。5個のサイト3(A、B、C、D、E)は、カンファレンスの際、接続されている。サイトA、サイトBは、特定(同一)のネットワーク・インターフェース・ユニット(NIU)120に接続されている。このネットワーク・インターフェース・ユニット(NIU)120は、複数のコーデック接続(例えば、T1インターフェース)をサポートする。他のサイトC、D、Eは、1個のコーデック接続(例、ISDNインターフェース)のみをサポートするネットワーク・インターフェース・ユニット(NIU)120に接続される。各サイト38は、デジタル・データからなる1個あるいは複数個のオクテット(octet)を、ネットワーク−バス138上に、非同期H.221フレーム化データとして送出する。ブリッジ処理ユニット(BPU)122は、その後、H.221フレーム化処理とオクテット整合を決定する。この整合したデータは、BPUバス136上の他の全てのユニットがアクセスできる。ブリッジ処理ユニット(BPU)122は、H.221フレームからオーディオ情報を抽出し、このオーディオ情報を16ビットのPCMデータに復号化する。この復号化されたオーディオ・データは、BPUバス136上に送信され、他のカンファレンス・サイトからのオーディオ・データと混合される。
整合したH.221フレームを、ビデオ処理ユニット(VPU)124が受信し、ビデオ圧縮プロセッサ(video compression processor (VCP))と称する符号化/復号化要素で処理する。ビデオ処理ユニット(VPU)124は、5個のビデオ圧縮プロセッサ(VCP)を有し(図2)、これらは、この実施例では、サイトA、B、C、D、Eに割り当てられる。ビデオ処理ユニット(VPU)124上の、サイトEに割り当てられたVCP機能を図4に示す。圧縮されたビデオ情報(H.261)は、ビデオ処理ユニット(VPU)により、H.221フレームから抽出され、イメージXとして復号化される。復号化されたビデオ・イメージXが、画素・バス182上に、スケーリング・ブロック(図示せず)を介して送出される。図4は、サイトA、B、C、D、Eからの復号化されたビデオ・フレームを有する画素・バス182を示す。これらのビデオ・フレームは、連続的に、それぞれのRAMアドレスにより指定され、メモリ123から連続的に取り出されたものである。サイトEに割り当てられたビデオ圧縮プロセッサ(VCP)は、サイトA、B、C、Dから復号化されたビデオ・フレームを受信する。このビデオ・フレームはその後、1個の合成イメージIにタイル貼りされる(空間的に混合される)。このタイル貼りされたイメージIは、H.221フレーム化処理ではH.261ビデオ(動画)として符号化され、BPUバス136上に送出され(図3)、上記したように、ブリッジ処理ユニット(BPU)で処理される。
上記の説明から分かるように、トランスコーディング(transcoding)は、かなりの処理資源を必要とする。その理由は、生の画素・データを混合し、その後符号化して混合ビュー(即ち、連続的存在ビュー)を形成しなければならないからである。セルフ・ビュー(self view:参加者が自己のピクチャを見ること)を回避するため、すなわち、連続的存在ビューが、ビデオフレームが送信されるそれぞれの参加者の自己のピクチャを含むのを回避するために、多地点通信制御ユニット(MCU)は、連続的存在ビュー内の各ピクチャ用に少なくとも1個の符号化器を有しなければならない。16個の連続的存在が可能となるためには、MCUは、少なくとも16個の符号化器を有しなければらない。
本発明の目的は、セルフ・ビューを回避するために、必要な符号化器の数と処理時間を低減する方法と装置を提供することである。
本発明の第1の態様によれば、上記の目的と他の利点は、請求項1に記載した符号化された対象の連続的存在(CP)イメージを生成する方法によって得られる。
本発明の第2の態様によれば、上記の目的および他の利点は、請求項8に記載した符号化された対象の連続的存在(CP)イメージを形成する装置を、多地点通信制御ユニット(MCU)内に配置することにより、得られる。
本発明は、ITUのH.26*標準のビット構造を用いて、セルフ・ビューのないCPビューを生成するために、MCU内の処理時間と処理要件を低減する。使用されるビット構造の特徴を理解するために、H.263標準によるピクチャ・ブロック構造を下記する。
H.263標準によれば、各ピクチャは、8×8個の画素からなるブロックに分割される。これらのブロックは、マクロブロックになるよう配置され、画素のルミネセンスに対しては、16(8×8)個のブロックを用い、画素のクロミナンスに対しては、4(2×2)個のブロックを用いる。ブロック群(Group Of Block: GOB)は、通常22個のマクロブロックからなる。ピクチャ当たりのブロック群(GOB)の数は、サブ−QCIFに対しては6個、QCIFに対しては9個、CIF、4CIF、16CIFに対しては18個である。ブロック群(GOB)の番号付けは、ブロック群(GOB)を垂直方向に、即ち、最上部のGOB(番号0)からスタートして、最下部のGOBで終了するよう、スキャンする。ピクチャ内のGOBの配列の一例を図5のCIFピクチャ・フォーマットに示す。各GOBのデータは、GOBヘッダと、その後のマクロブロックのデータからなる。GOBのデータは、GOB当たり、GOBの番号を増加する方法で送信する。GOBのスタートは、ブロック群スタート・コード(Group of Block Start Code (GBSC))で特定される。GOB層の構造を図6に示す。
各マクロブロックのデータは、マクロブロック・ヘッダと、その後のブロック用のデータからなる。この構造を図7に示す。CODは、これらのピクチャの各マクロブロックに対して、「INTRA」のタイプでない場合にのみ、ピクチャに表われる。ビットは、「0」に設定されている時は、マクロブロックが符号化されていることを示す。「1」に設定されている時は、このマクロブロックに対しては更なる情報は送信されないことを示す。この場合、復号化器は、マクロブロックを、全ブロックの動きベクトルがゼロに等しく、係数データのない「INTER」マクロブロックとして、処理しなければならない。
CODが「0」に設定されている場合には、マクロブロックのデータ部分は、マクロブロック内のそれぞれのブロックの情報を含む。この情報は、動きベクトルにより表され、含まれる画素が等しい前のピクチャ内の画素の位置を示す。
従来は、CPピクチャ内にセルフ・ビューが含まれるのを回避するために、各参加者に対する特殊な符号化が必要であり、多地点通信制御ユニット(MCU)内の各出力データ・ストリームに対し、1個の符号化器が必要であった(図2)。これに対し、本発明は、既に符号化されたビデオ・データのマクロブロック構造を利用し、受信器に依存してCPピクチャの混合情報を得る。本発明の以下の実施例において、5か所のエンドポイント・サイトが、CIPフォーマットのビデオ・ピクチャを捕獲し、H.263標準に従ってピクチャを符号化するビデオ・カンファレンスを考える。多地点通信制御ユニット(MCU)内で、それぞれの参加者からのデータ・ストリームは、H.263標準に従って、それぞれの多地点通信制御ユニット(MCU)入力に関連する復号化器により復号化される。復号化後、各参加者からの生の画素・データが、多地点通信制御ユニット(MCU)内の内部バス上で得られ、混合(mixing)と符号化/復号化(transcoding)がなされる。
5人の参加者の場合、それぞれのサイトに戻されるべき混合ピクチャのCP4フォーマットを選択する。この混合フォーマットは、「ベストインプレッション」原理(”Best Impression” principals)に従って、多地点通信制御ユニット(MCU)により選択される。この「ベストインプレッション」原理は、特許文献3に開示されている。
この実施例によれば、2個のCP4イメージ(即ち、CPイメージ1とCPイメージ2)が、それぞれの符号化器により符号化される(図8)。CPイメージ1は、サイト1、2、3、4から受信した複数のイメージを含む。CPイメージ2は、サイト5から受信したイメージを含み、1個のイメージが1/4象限領域(quadrant)にあり、残りの3個の1/4象限領域は空である。CPイメージを符号化し、この符号化されたデータを上記のブロックシステムに配置すると、1/4象限領域の境界は、ブロック群(GOB)内のマクロブロック境界と一致する。CPイメージ1に対して、第1のブロック群(GOB)内の最初の11個のマクロブロックは、サイト1のイメージからのデータを含み、第1のGOB内の最後の11個のマクロブロックは、サイト2のイメージからのデータを含む。
本発明によれば、多地点通信制御ユニット(MCU)は、受信器に応じて、各CPイメージ内のマクロブロックを再配列する。一例として、サイト4に送信されたCPイメージにおいて、CPイメージ1の最後の9個のブロック群(GOB)のそれぞれの最後の11個のマクロブロックは、それぞれ、CPイメージ2の最初の9個のブロック群(GOB)のそれぞれの最初の11個のマクロブロックにより置換される。その結果、新たに復号化されたCPイメージができあがる。このイメージは、サイト4から受信したイメージの代わりに、サイト5から受信したイメージを含む。このCPイメージは、サイト4に戻され、その結果、そのサイトにおけるセルフ・ビューを回避できる。
対応する再置換と再配置が、他のサイトにそれぞれ関連する4個の他のCPイメージに対して行われる。
図9は、本発明により多地点通信制御ユニット(MCU)の内部アーキテクチャの一例を示す。このアーキテクチャが、本発明により、図2に示した従来のビデオ処理ユニット(VPU)124の代わりに使用される。画素・バス182、メモリ123、画素・スケーリング・ユニット104、108が、図9のミキシング/スケーリング・ユニット(MSU)156で置換されている。図9の第1データバス176と第2データ・バス177は、交互に1本の共通データ・バスに併合される。図9は、実際の構成とは異なるが、本発明の関連する装置のみを示す。
入力データ・ストリーム171、172、173、174、175は、復号化器151、152、153、154、155により、それぞれ復号化される。各サイトに1個の復号化器が設けられている。この復号化処理は、使用される符号化標準に従って行われ、本発明の場合、H.263標準である。復号化されたデータは、PCMデータの形態であり、第1データバス176上のミキシング/スケーリング・ユニット(MSU)156は、それにアクセス可能である。
ミキシング/スケーリング・ユニット(MSU)156は、第1、第2、第3、第4のサイトからのPCMデータである入力データ・ストリーム171、172、173、174を、空間的に混合(mixing)して、第1のCPイメージを形成する。第2のCPイメージは、第1の1/4象限領域内にサイト5からのPCMデータ175を配置し、残りの3個の1/4象限領域を空にするか、あるいはダミーのデータを入れて、形成する。この2個の空間的に混合されたイメージのPCMデータは、第2データ・バス177上の第1符号化器157と第2符号化器158にアクセス可能である。
符号化器157、158は、ミキシング/スケーリング・ユニット(MSU)156により生成されたCPイメージのPCMデータを、第2データ・バス177から取りだし、各イメージを符号化する。この符号化プロセスの結果、ブロック群(GOB)内で組み立てられた複数のマクロブロックが得られる。H.263標準によるCIFフォーマットの場合には、ブロック群(GOB)は22個のマクロブロックからなり、各イメージは18個のブロック群(GOB)からなる。このイメージを符号化した後、ブロック群(GOB)は、引き続き、関連するバッファー159、160内にそれぞれ挿入される。バッファー159、160のサイズは、十分大きく、少なくとも1個のイメージのブロック群(GOB)を記憶できる。バッファー159、160の出力は、第3データ・バス178に接続され、この第3データ・バス178は、リパッカー161、162、163、164、165の入力に接続される。
符号化イメージを表すビットの数は、一定ではなく、1つのイメージから別のイメージへの動きとイメージのコンテンツに応じて、変わる。ビットの数も、イメージがINTRA符号化されるか、あるいはINTER符号化されるかによって、すなわち同一の画像内の近隣のマクロブロックからの予測符号化、あるいは前のイメージからの予測(画像間)符号化に依存する。
完全に同期したピクチャの符号化データが、それぞれのバッファに挿入されると、リパッカー161、162、163、164、165は、マクロブロックの順番を組み換えて、関連する出力181、182、183、184、185用にそれぞれ必要とされる連続的存在(CP)イメージを生成する。リパッカーは、マクロブロックを、ブロック群(GOB)とマクロブロックのヘッダの手段により、識別し分離することができる。各ブロック群(GOB)のスタートは、ブロック群スタートコード(GBSC:Group of Block Start Code)と称する独自のスタート・コードと、その後に続くブロック群(GOB)番号を示す群番号(GN:Group Number)により指定される。マクロブロックのヘッダ内では、CODは、マクロブロックが符号化されているか否かを示す。CODが「1」の時には、そのマクロブロックにはこれ以上の情報は存在しないことを示し、全ブロックの動きベクトルがゼロに等しく、係数データを具備しない。CODが「0」の場合には、マクロブロックのさらなるデータが続く。更なるデータの一部は、可変長であり、別の符号が、各符号の長さが規定されるよう、定義される。
マクロブロックは、識別可能であり、一時的にバッファー159、160内に記憶されるために、リパッカー161、162、163、164、165は、如何なる順番でもマクロブロックを読み出すことができる。これにより、5箇所のサイトのイメージからCP4イメージの如何なる変形例も形成できる。一例として、リパッカー164が、第4サイトに対しCPイメージを生成する場合、即ち、サイト4出力184を出力する場合を考える。第1バッファー159は、CPイメージ1の符号化データを有し、第2バッファー160は、CPイメージ2の符号化データを有する。リパッカー164は、CPイメージ1のブロック群(GOB)1−9を、第1バッファー159内で起こるのと同一の順番で、取り出し、新たなCPイメージを形成する。しかし、ブロック群(GOB)10を生成する時には、リパッカー164は、第1バッファー159内でブロック群(GOB)10の11個の第1マクロブロックと、それに続いて、第2バッファー160内のブロック群(GOB)1の11個の第1マクロブロックとを、識別し取り出す。さらに、ブロック群(GOB)11は、第1バッファー159内のブロック群(GOB)11の11個の第1マクロブロックと、それに続いて、第2バッファー160内のブロック群(GOB)2の11個の第1マクロブロックを取り出すことにより、生成される。残りの7個のブロック群(GOB)も同様に形成され、ブロック群(GOB)18で終了する。このブロック群(GOB)18は、第1バッファー159内のブロック群(GOB)18の11個の第1マクロブロックと、それに続いて、第2バッファー160内のブロック群(GOB)9の11個の第1マクロブロックを取り出すことに、生成される。
リパッカー161、162、163、164、165は、バッファー159、160からマクロブロックを取り出すよう、プログラムされるが、これは、一定の順番、あるいは制御ユニット(図示せず)により制御されるマクロブロックの順番に従って、行われる。これにより、リパッカーは、さまざまなCPイメージを形成できる。
図10は、本発明の方法の一実施例を表すブロック図である。
図10に示す方法のステップは、ビデオ符号化標準に従った符号化された対象連続的存在(CP)イメージ(coded target Continuous Presence (CP) image)を、所定の順番のマクロブロックを含む複数の符号化ビデオ信号から形成する方法を示す。各マクロブロックは、それぞれのエンドポイント・ビデオ・イメージに対応する符号化ビデオ信号を含む。このエンドポイント・ビデオ・イメージは、マルチポイント・ビデオ・カンファレンスに参加するエンドポイントから受信されたものである。
本発明の方法は、ステップ202で開始する。
最初に、復号化ステップ204が実行される。このステップにおいて、ビデオ信号は、対応するエンドポイント・ビデオ・イメージに復号化される。
次に、ミキシング(混合)・ステップ206において、エンドポイント・ビデオ・イメージは、空間的に混合されて、複数のCPイメージとなる。各CPイメージは、各エンドポイント・ビデオ・イメージに関連する領域からなる。
次に、符号化ステップ208において、CPイメージは、それぞれ、複数の符号化CPイメージに符号化される。このステップは、ビデオ符号化標準に従ったマクロブロックの所定の順番を確立し、領域境界とマクロブロック境界を合併する。
これらの3個の前段階のステップ204、206、208の後、形成ステップ210が実行される。形成ステップ210において、符号化された目標CPイメージが、所定の方法あるいは制御しながらの方法で、マクロブロックの前記順番を再度配列することにより、形成される。
形成ステップ210は、第1の符号化CPイメージの領域高さを表すn個の連続するブロック群(GOB)内の領域幅を表す最初のm個のマクロブロックを、第2の符号化CPイメージからのn個の連続するブロック群(GOB)内のm個のマクロブロックで、置換するステップを含む。
この方法は、ステップ212で終了する。
他の構成として、図10を参照して説明したプロセスの上記の3個の予備的ステップ、すなわち復号化ステップ204、ミキシング・ステップ206、符号化ステップ210は、1個の要求ステップ(図示せず)で置換してもよい。この要求ステップでは、エンドポイントは、ビデオ符号化標準、ある解像度、ビット・レート、スケーリングに従って、それぞれのエンドポイント・ビデオ・イメージを符号化するよう、要求される。
最も基本的な形態においては、本発明の方法は、形成ステップ210を含むだけである。
上記した実施例は、H.263標準によるCIFフォーマットのCP4イメージの形成に関する。しかし、本発明の基本的原理を、他のフォーマットのCPイメージにも適用できる。一例として、本発明は、CP9イメージを形成する際にも用いられる。各ブロック群(GOB)(CIF、H.263の場合)内のイメージ境界は、7’番目と14’番目(あるいは8’番目と15’番目、あるいは7’番目と15’番目)のマクロブロックの後に見出される。
いずれの場合にも、1個のリパッカー(あるいは少なくとも1個のリパッカー手順)が、各多地点通信制御ユニット(MCU)出力に必要である。符号化器の数は、CPピクチャ内の領域数とCPイメージの領域を満たすサイトの数の関係に依存する。各サイトに対し、1個の領域を形成するのに十分な数の符号化器を有さなければならない。CP4と8個のサイトの場合、2個の符号化器で、全部で8個の1/4象限領域のそれぞれ内の各サイトに対し、1つの領域を配置するのに、十分である。しかし、サイトの数を9個に増やすことは、第9領域が存在する第3のCP4イメージを形成するために、さらに1個の符号化器が必要である。
本発明のより一般的な実施例においては、復号化処理とスケーリング/ミキシング処理は、多地点通信制御ユニット(MCU)内で実行する必要はない。その代わりに、エンドポイントは、標準、解像度、ビット・レート、スケーリングに従って、符号化イメージを送信するよう、要求される。来入データ・ストリームのマクロブロックは、その後直接バッファ(好ましくは各データ・ストリームに対し1個のバッファ)内に入力され、リパッカーが、予めプログラムされたあるいは制御された手順に従って、マクロブロックを再度配置し、セルフ・ビューのないCPイメージを形成し、それぞれのカンファレンスのサイトに送信する。一例として、カンファレンスに5個のサイトが参加している場合を考える。CP4のビューは、エンドポイントが、符号化する前に、それぞれのイメージを全体イメージ内の1/4象限領域の1個内に配置することを、要求する。この要求は、標準、解像度、ビット・レート、スケーリングのような符号化情報と共に、エンドポイントに要求される。リパッカーは、マクロブロックがそれぞれのバッファ内に存在する場合には、来入データ・ストリームのマクロブロックを再配置できる。
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。
多地点通信制御ユニット(MCU)のブロック図(従来技術)。 ビデオ処理ユニット(VPU)の一実施例のブロック図(従来技術)。 連続的存在(CP)カンファレンス用のデータの流れを表す多地点通信制御ユニット(MCU)のブロック図(従来技術)。 連続的存在(CP)カンファレンスで、イメージがタイル貼りされた状態を表すブロック図(従来技術)。 共通中間フォーマト(CIF)ピクチャ内のブロック群(GOB)の配置を表すブロック図。 H.263標準によるブロック群(GOB)層を表す図。 H.263標準によるマクロブロック層を表す図。 本発明の一実施例で使用される3個の連続的存在(CP)イメージを表すブロック図。左から、CPイメージ1、CPイメージ2、サイト4に送信された再配置されたCPイメージ。 本発明の一実施例を表すロック図。 本発明の方法の一実施例を表すフローチャート図。
符号の説明
10 多地点通信制御ユニット(MCU)
14 MCU
38 サイト
120 ネットワーク・インターフェース・ユニット(NIU)
122 ブリッジ処理ユニット(BPU)
122A BPU−G
124 ビデオ処理ユニット(VPU)
126 データ処理ユニット(DPU)
126 データ処理ユニット(DPU)
128 ゲートウエイ処理ユニット(GPU)
130 ホスト処理ユニット(HPU)
132 制御バス
134 ネットワーク・バス
136 BPUバス
132 制御バス
138 X−バス
140 LANインターフェース
142 ネットワーク・インターフェース
102−i,106−i ビデオ復号化器/符号化器対
102−i ビデオ復号化器
102−j 復号化器
104−i,108−i 画素・スケーリング・ブロック
106−j 符号化器
108−i 画素・スケーリング・ブロック
108−j 画素・スケーリング・ブロック
182 画素・バス
123 メモリ
102−j 復号化器
GOB ブロック群(Group Of Blocks)
171−174 入力データ・ストリーム
176 第1データ・バス
177 第2データ・バス
178 第3データ・バス
151−155 復号化器
156 ミキシング/スケーリング・ユニット(MSU)
157 第1符号化器
158 第2符号化器
157,158 符号化器
159,160 バッファー
161−165 リパッカー
181−185 出力
202 開始
204 ビデオ信号を復号化する
206 EPイメージを空間的に混合する
208 CPイメージを符号化する
210 復号化された対象CPイメージを形成する
212 終了

Claims (11)

  1. ビデオ符号化標準により、所定の順番のマクロブロックを含む複数の符号化されたビデオ信号から、符号化された目標とするコンティニュアス・プレゼンス・イメージを生成する方法において、
    前記符号化されたビデオ信号は、、多地点ビデオ・カンファレンスに参加しているエンドポイントから受信したそれぞれのエンドポイント・ビデオイメージに対応し、
    (A) 前記符号化されたビデオ信号を復号化するステップと、
    その結果、エンドポイント・ビデオイメージが生成され
    (B) 前記エンドポイント・ビデオイメージを空間的に混合するステップと、
    その結果、前記エンドポイント・ビデオイメージにそれぞれ関連する領域から構成される複数のコンティニュアス・プレゼンス・イメージが生成され、
    (C) 前記コンティニュアス・プレゼンス・イメージを符号化するステップと、
    の結果、符号化されたコンティニュアス・プレゼンス・イメージが生成され、
    (D) 前記符号化されたコンティニュアス・プレゼンス・イメージのマクロブロックを、再配列するステップと、
    その結果、符号化された目標とするコンティニュアス・プレゼンス・イメージが生成され、
    を有する
    ことを特徴とする符号化された目標とするコンティニュアス・プレゼンス・イメージを生成する方法。
  2. 前記(C)ステップは、
    (C1) ビデオ符号化標準に従って、前記マクロブロックの所定の順番を確立するステップと、
    (C2) 領域境界とマクロブロック境界を合併するステップと
    を有する
    ことを特徴とする請求項1記載の方法。
  3. 前記符号化されたコンティニュアス・プレゼンス・イメージと符号化された目標とするコンティニュアス・プレゼンス・イメージは、それぞれ22個のマクロブロックを有するブロック群を18個有するCIFフォーマットであり、最初の9個のブロック群は上部領域を表し、最後の9個のブロック群は下部領域を表すよう、スタック形式で配置される
    ことを特徴とする請求項2記載の方法。
  4. 前記符号化された目標とするコンティニュアス・プレゼンス・イメージの生成は、
    第1の符号化されたコンティニュアス・プレゼンス・イメージの領域高さを表すn個の連続するブロック群内の領域幅を表すm個のマクロブロックを、第2の符号化されたコンティニュアス・プレゼンス・イメージからのn個の連続するブロック群内のm個のマクロブロックで、置換することにより行う
    ことを特徴とする請求項3記載の方法。
  5. m=11、n=9であり、
    前記領域は、それぞれ、コンティニュアス・プレゼンス・イメージの1/4象限領域を表す
    ことを特徴とする請求項4記載の方法。
  6. m=7又はm=8、n=6であり、
    前記領域は、それぞれ、コンティニュアス・プレゼンス・イメージの1/8象限領域を表す
    ことを特徴とする請求項4記載の方法。
  7. ビデオ符号化標準により、所定の順番のマクロブロックを含む複数の符号化されたビデオ信号から、符号化された目標とするコンティニュアス・プレゼンス・イメージを生成する方法において、
    前記符号化されたビデオ信号は、、多地点ビデオ・カンファレンスに参加しているエンドポイントから受信したそれぞれのエンドポイント・ビデオイメージに対応し、
    (A) 前記符号化されたビデオ信号を復号化する復号化器と、
    その結果、エンドポイント・ビデオイメージが生成され
    (B) 前記エンドポイント・ビデオイメージを空間的に混合するミキシング/スケーリングユニットと、
    その結果、前記エンドポイント・ビデオイメージにそれぞれ関連する領域から構成される複数のコンティニュアス・プレゼンス・イメージが生成され、
    (C) 前記コンティニュアス・プレゼンス・イメージを符号化する複数の符号化器と、
    の結果、符号化されたコンティニュアス・プレゼンス・イメージが生成され、
    (D) 前記符号化されたコンティニュアス・プレゼンス・イメージのマクロブロックを再配列し、符号化された目標とするコンティニュアス・プレゼンス・イメージを生成生成するリパッカーと
    を有する
    ことを特徴とする符号化された目標とするコンティニュアス・プレゼンス・イメージを生成する装置。
  8. 前記符号化されたコンティニュアス・プレゼンス・イメージと符号化された目標とするコンティニュアス・プレゼンス・イメージは、それぞれ22個のマクロブロックを有するブロック群を18個有するCIFフォーマットであり、最初の9個のブロック群は上部領域を表し、最後の9個のブロック群は下部領域を表すよう、スタック形式で配置される
    ことを特徴とする請求項7記載の装置。
  9. 前記リパッカーは、第1の符号化されたコンティニュアス・プレゼンス・イメージの領域高さを表すn個の連続するブロック群内の領域幅を表すm個のマクロブロックを、第2の符号化されたコンティニュアス・プレゼンス・イメージからのn個の連続するブロック群内のm個のマクロブロックで、置換する
    ことを特徴とする請求項8記載の装置。
  10. m=11、n=9であり、
    前記領域は、それぞれ、コンティニュアス・プレゼンス・イメージの1/4象限領域を表す
    ことを特徴とする請求項9記載の装置。
  11. m=7又はm=8、n=6であり、
    前記領域は、それぞれ、コンティニュアス・プレゼンス・イメージの1/8象限領域を表す
    ことを特徴とする請求項9記載の装置。
JP2006553078A 2004-02-13 2005-02-11 コンティニュアス・プレゼンス・イメージを生成する方法と装置 Expired - Fee Related JP4582659B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO20040661A NO320115B1 (no) 2004-02-13 2004-02-13 Anordning og fremgangsmate for a generere CP-bilder.
PCT/NO2005/000050 WO2005079068A1 (en) 2004-02-13 2005-02-11 Arrangement and method for generating continuous presence images

Publications (2)

Publication Number Publication Date
JP2007522761A JP2007522761A (ja) 2007-08-09
JP4582659B2 true JP4582659B2 (ja) 2010-11-17

Family

ID=34793425

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006553078A Expired - Fee Related JP4582659B2 (ja) 2004-02-13 2005-02-11 コンティニュアス・プレゼンス・イメージを生成する方法と装置

Country Status (9)

Country Link
US (1) US7720157B2 (ja)
EP (1) EP1721462B1 (ja)
JP (1) JP4582659B2 (ja)
CN (1) CN100559865C (ja)
AT (1) ATE471631T1 (ja)
DE (1) DE602005021859D1 (ja)
ES (1) ES2345893T3 (ja)
NO (1) NO320115B1 (ja)
WO (1) WO2005079068A1 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8542266B2 (en) 2007-05-21 2013-09-24 Polycom, Inc. Method and system for adapting a CP layout according to interaction between conferees
US8446454B2 (en) * 2007-05-21 2013-05-21 Polycom, Inc. Dynamic adaption of a continuous presence videoconferencing layout based on video content
US8116372B1 (en) * 2007-10-26 2012-02-14 Xilinx, Inc. Data structure and method using same for encoding video information
US8319820B2 (en) * 2008-06-23 2012-11-27 Radvision, Ltd. Systems, methods, and media for providing cascaded multi-point video conferencing units
DE102009011251A1 (de) * 2009-03-02 2010-09-09 Siemens Enterprise Communications Gmbh & Co. Kg Multiplexverfahren und zugehörige funktionelle Datenstruktur zum Zusammenfassen digitaler Videosignale
US9516272B2 (en) 2010-03-31 2016-12-06 Polycom, Inc. Adapting a continuous presence layout to a discussion situation
DE102010023954A1 (de) * 2010-06-16 2011-12-22 Siemens Enterprise Communications Gmbh & Co. Kg Verfahren und Vorrichtung zum Mischen von Videoströmen auf der Makroblock-Ebene
JP2012074981A (ja) * 2010-09-29 2012-04-12 Nec Corp 多地点会議接続装置、多地点会議システム、多地点会議接続方法およびプログラム
US8537195B2 (en) * 2011-02-09 2013-09-17 Polycom, Inc. Automatic video layouts for multi-stream multi-site telepresence conferencing system
US20140028788A1 (en) * 2012-07-30 2014-01-30 Polycom, Inc. Method and system for conducting video conferences of diverse participating devices
US9215413B2 (en) 2013-03-15 2015-12-15 Cisco Technology, Inc. Split frame multistream encode
EP2974292B1 (en) * 2013-03-15 2020-12-30 Cisco Technology, Inc. Split frame multistream encode
US9118807B2 (en) 2013-03-15 2015-08-25 Cisco Technology, Inc. Split frame multistream encode
CN105635636B (zh) * 2015-12-30 2019-05-03 随锐科技股份有限公司 一种视频会议系统及其实现视频图像传输控制的方法
AU2020208640A1 (en) * 2019-01-17 2021-08-05 Adeia Media Holdings Llc Optimal multi-codec ABR ladder design

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0795553A (ja) * 1993-09-22 1995-04-07 Nippon Telegr & Teleph Corp <Ntt> 多地点間画像通信システム
JP3586484B2 (ja) * 1993-12-10 2004-11-10 日本電気エンジニアリング株式会社 多地点会議用画面合成システムおよび方法
US5446491A (en) * 1993-12-21 1995-08-29 Hitachi, Ltd. Multi-point video conference system wherein each terminal comprises a shared frame memory to store information from other terminals
JPH08251567A (ja) * 1995-03-15 1996-09-27 Toshiba Corp テレビ会議装置
JPH1066088A (ja) * 1996-08-16 1998-03-06 Ricoh Co Ltd 多地点テレビ会議制御装置
EP0950308A2 (en) 1996-11-18 1999-10-20 MCI Worldcom, Inc. A communication system architecture
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
US6731625B1 (en) * 1997-02-10 2004-05-04 Mci Communications Corporation System, method and article of manufacture for a call back architecture in a hybrid network with support for internet telephony
JPH10262228A (ja) * 1997-03-18 1998-09-29 Toshiba Corp 通信システム、多地点制御装置、映像情報表示方法
JPH11239331A (ja) * 1998-02-23 1999-08-31 Kyocera Corp 多地点通信システム
US6288740B1 (en) * 1998-06-11 2001-09-11 Ezenia! Inc. Method and apparatus for continuous presence conferencing with voice-activated quadrant selection
EP1024643A1 (en) 1999-01-29 2000-08-02 International Business Machines Corporation Method, apparatus and communication system for setting up a communication session
US6606112B1 (en) * 2000-03-16 2003-08-12 Tandberg Telecom As Composite-video generation from different-rate constituents
US6535240B2 (en) * 2001-07-16 2003-03-18 Chih-Lung Yang Method and apparatus for continuously receiving frames from a plurality of video channels and for alternately continuously transmitting to each of a plurality of participants in a video conference individual frames containing information concerning each of said video channels
EP1470491A4 (en) 2002-01-30 2006-06-21 Larry E Roher AUDIOVISUAL MULTIPORT CONFERENCE SYSTEM
US7352809B2 (en) * 2003-02-21 2008-04-01 Polycom, Inc. System and method for optimal transmission of a multitude of video pictures to one or more destinations
US20050008240A1 (en) * 2003-05-02 2005-01-13 Ashish Banerji Stitching of video for continuous presence multipoint video conferencing

Also Published As

Publication number Publication date
CN100559865C (zh) 2009-11-11
ATE471631T1 (de) 2010-07-15
EP1721462A1 (en) 2006-11-15
US7720157B2 (en) 2010-05-18
ES2345893T3 (es) 2010-10-05
NO320115B1 (no) 2005-10-24
WO2005079068A1 (en) 2005-08-25
EP1721462B1 (en) 2010-06-16
US20050195275A1 (en) 2005-09-08
CN1918912A (zh) 2007-02-21
JP2007522761A (ja) 2007-08-09
NO20040661D0 (no) 2004-02-13
DE602005021859D1 (de) 2010-07-29

Similar Documents

Publication Publication Date Title
JP4582659B2 (ja) コンティニュアス・プレゼンス・イメージを生成する方法と装置
US6535240B2 (en) Method and apparatus for continuously receiving frames from a plurality of video channels and for alternately continuously transmitting to each of a plurality of participants in a video conference individual frames containing information concerning each of said video channels
US7616591B2 (en) Video conferencing system
US8228363B2 (en) Method and system for conducting continuous presence conferences
US5453780A (en) Continous presence video signal combiner
US7787007B2 (en) Method and system for preparing video communication image for wide screen display
AU2002355089A1 (en) Method and apparatus for continuously receiving frames from a pluarlity of video channels and for alternatively continuously transmitting to each of a plurality of participants in a video conference individual frames containing information concerning each of said video channels
US8184142B2 (en) Method and system for composing video images from a plurality of endpoints
JP2001238221A (ja) ビデオ通信システム、デコーダ回路、ビデオディスプレイシステム、エンコーダ回路、及びビデオデータ受信方法
CN101095350A (zh) 用于低延迟视频混合的方法和系统
US6313863B1 (en) Image communication apparatus and system
US6560280B1 (en) Video transmission system
JP3927606B2 (ja) 画像通信装置及びシステム、並びに画像受信装置及び受信画像データの処理方法
JPH0846928A (ja) 画像符号化前処理装置
KR19990070821A (ko) 화상회의 시스템에서 참가자 4명까지의 비디오를 단일 비디오 스트림으로 변환하는 서버
JPH1028260A (ja) 映像データ伝送方法および多地点テレビ会議装置
JPH0846792A (ja) 画像通信装置及びシステム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091110

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100205

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100215

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100310

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100317

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100409

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100421

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100510

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100826

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100826

R150 Certificate of patent or registration of utility model

Ref document number: 4582659

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130910

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130910

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130910

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees