JP3554999B2 - 多地点テレビ会議システム - Google Patents
多地点テレビ会議システム Download PDFInfo
- Publication number
- JP3554999B2 JP3554999B2 JP07931496A JP7931496A JP3554999B2 JP 3554999 B2 JP3554999 B2 JP 3554999B2 JP 07931496 A JP07931496 A JP 07931496A JP 7931496 A JP7931496 A JP 7931496A JP 3554999 B2 JP3554999 B2 JP 3554999B2
- Authority
- JP
- Japan
- Prior art keywords
- video conference
- image
- video
- data
- unit
- 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
Links
Images
Description
【０００１】
【発明の属する技術分野】
符号化されたままの伝送動画情報の合成を伴う多地点テレビ会議システムに関する。
【０００２】
【従来の技術】
従来の多地点テレビ会議制御装置においては動画情報の切り出し、合成を行う際には、特開平４−６３０８４号公報に見られるように、回線によって接続された各テレビ会議端末からの受信動画情報を一旦復号化した後に合成等の処理を行い、再符号化して送信している。
【０００３】
しかしながら上記の方法では、多地点テレビ会議制御装置は、接続されるテレビ会議端末数分の動画復号化器を備える必要があり、装置のコストの増大を招いていた。
【０００４】
そのため、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．４．３項に示す様に、受信動画像の完全な復号化を行わずに（完全な復号化とは、ＩＴＵ−Ｔ勧告Ｈ．２６１に示される復号化の手順を全て実行する事を指す）、符号化されている動画情報の内、ＧＯＢ番号のみを書き換える（この処理はＴ．１２８内には記述されていないが、Ｈ．２６１との整合を考えるとこの処理が必要である）ことによって、４つのＱＣＩＦ動画情報を１つのＦＣＩＦ動画情報へ合成する様な方法が提案されている。
【０００５】
しかしながら、上記の方法では、特開平４−６３０８４号公報に開示された多地点間テレビ会議システムの様に画像の一部分の切り出しを伴う様な場合（ただし、この多地点間テレビ会議システムでは一旦復号化を行ってから切り出し、合成を行っているので、本発明の構成とは異なる）には、テレビ会議端末からの受信動画情報において動きベクトルが切り出し領域の外を参照している様な場合に対応する事ができない為、テレビ会議端末側ではフレームの全体を動きベクトル情報無しのまま符号化（ＩＴＵ−Ｔ勧告Ｈ．２６１規定のＭＴＹＰＥをＩＮＴＲＡもしくはＩＮＴＥＲ）するしかなく、符号量が増大し、ひいては画質の低下を招くという不具合が発生する。
【０００６】
テレビ会議端末側で、切り出し領域の画像のみを符号化して送信するような構成もあり得るが、その場合にはＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．１項に示されているスイッチクングサービスとの併用（あるテレビ会議端末にはアレイプロセッサによる合成画像を送信し、別のテレビ会議端末にはスイッチングサービスによって、合成していないあるテレビ会議端末からの画像を送信するような場合、例えば、発言者と前発言者のテレビ会議端末にはお互いの画像をスイッチングサービスで提供し、それら以外のテレビ会議端末にはアレイプロセッサで合成画像を提供する場合に対応することができない。
【０００７】
また、多地点テレビ会議制御装置における画像合成の方法には、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．４項に示されているマルチプレクスモード、トランスコーダ及びアレイプロセッサの３通りの方法が提案されている。
【０００８】
これらのうち、マルチプレクスモード、アレイプロセッサにおいては、送信側テレビ会議端末に設定される動画情報の通信帯域の容量を１とすると、受信側のテレビ会議端末には動画情報のために容量４の通信帯域を設定する事が前提となる。
【０００９】
しかしながら、通常の回線交換による回線（パケットではない）では、回線の持つ帯域は固定であり、その固定の帯域内を送信、受信で対称に、音声用、データ用、動画用に分割して利用するのが常である。これらの手順はＩＴＵ−Ｔ勧告Ｈ．２２１・２４２に定義される。勧告Ｈ．２２１では、送信、受信非対称の帯域の設定も可能であるが、通常用いられない。また、動画の帯城は音声及びデータで使われた残りが割り当てられるため、送信に対して正確に４倍の受信帯域を割り当てる事はできない。
【００１０】
また、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．１項に示されているスイッチングサービスでは、ソースとして選択された動画の帯城に受信側の帯域を合わせる必要があり、通常、スイッチングサービスに対応するために、各テレビ会議端末の送信、受信の帯城を対称にし、かつ各端末での帯域も同一に合わせるような動作が想定される。
【００１１】
以上を鑑みて、上記２通りの画像合成の方法を考えると、
マルチプレクスモードでは、
ａ）送信側及び受信側のテレビ会議端末に対称の通信帯城を割り当てた場合には、多地点テレビ会議制御装置の送信バッファのオーバーフローが発生する。つまり、対称の通信帯域を割り当てた場合には、実用に供さない。
ｂ）送信側及び受信側のテレビ会議端末に非対称の通信帯域を割り当てた場合にも、通信帯域を正確に１：４に設定する事はできない為、バッファのオーバーフローが発生する（アンダーフローも発生しうるが、これは誤り訂正フレームでのフィルビット挿入により回避できる：ＩＴＵ−Ｔ勧告Ｈ．２６１参照）。また、スイッチングサービスとコンティニュアスプレゼンスモードの切り替えの度にビデオ帯城を再設定する必要があり、切り替えに時間がかかる。
アレイプロセッサでは、
ａ）送信側及び受信側のテレビ会議端末に対称の通信帯域を割り当てた場合には、多地点テレビ会議制御装置の送信バッファにオーバーフローが発生する。つまり、対象の通信帯城を割り当てた場合には、実用に供さない。
ｂ）送信側及び受信側のテレビ会議端末に非対称の通信帯城を割り当てた場合にも、通信帯域を正確に１：４に設定する事はできない為、バッファのオーバーフローが発生する。また、スイッチングサービスとコンティニュアスプレゼンスモードの切り替えの度にビデオ帯域を再設定する必要があり、切り替えに時間がかかる。さらに、多地点テレビ会議制御装において動画情報の切り出しを伴うような場合には、ＧＯＢ番号だけでなく、各層でのアドレスや動きベクトル情報も書き換える必要があり、そのことによる符号量の増大によって、送信バッファのオーバーフローが発生する可能性がある。
【００１２】
また、アレイプロセッサにより画像合成を行っている多地点テレビ会議制御装置を介して各テレビ会議端末が多地点会議を行っている場合に、あるテレビ会議端末からＶＣＵ（ビデオコマンド−ファーストアップデイトリクエスト：ＩＴＵ−Ｔ勧告Ｈ．２３０参照）の指示があると、多地点テレビ会議制御装置は回線を介して接続されている全てのテレビ会議端末にＶＣＵを発行して各テレビ会議端末からのＩＮＴＲＡフレーム（１フレーム全体がＩＮＴＲＡモードで符号化されたフレームを指す：通常このようなフレームでは、ＩＴＵ−Ｔ勧告Ｈ．２６１に規定されているＰＴＹＰＥ−第３ビット（Ｆｒｅｅｚｅ Ｒｅｌｅａｓｅ）をオン（＝１）し、そのビットによりＩＮＴＲＡフレームか否かを判別する）の動画情報を合成してテレビ会議端末に送信するように動作する。
【００１３】
しかしながら、多地点テレビ会議制御装置から発行されたＶＣＵに対する各テレビ会議端末の応答には時間的なズレがあるために、同一構成のテレビ会議端末でかつ伝送バッファ状態が同様であったとしても、最大（１／フレームレート）秒のズレが発生するため、すべてのテレビ会議端末からのＩＮＴＲＡフレームの動画情報が揃うまでは、合成後の動画情報をＩＮＴＲＡフレームとしてテレビ会議端末に送信できないケースが発生する。
【００１４】
もっとも、多地点テレビ会議端末が伝送バッファで全てのテレビ会議端末からのＩＮＴＲＡフレームの動画情報を待つ事により、合成動画情報のＩＮＴＲＡフレームを構成する事はできるが、各テレビ会議端末からの動画情報には、端末ごとに異なる大きな遅延が発生することになるため、特別な処理を行わない限りＩＮＴＲＡフレームの送信後も、合成動画情報を構成する各テレビ会議端末からの動画情報は、互いに時間的にズレたままになってしまう。
【００１５】
また、ＶＣＵを発行したテレビ会議端末が、受信した動画データをデコードし続けていれば問題なく動画像は復旧するが、通常、交信中にテレビ会議端末がＶＣＵを発行するのは、受信データにエラーが検出された場合である。その場合、多くのテレビ会議端末は、受信動画像をフリーズして多地点テレビ会議制御装置からのＩＮＴＲＡフレームを待ち、ＩＮＴＲＡフレームの受信によってフリーズを解除する様に動作する。そのため、多地点テレビ会議制御装置の受信する各テレビ会議端末からＶＣＵに応答して送信されたＩＮＴＲＡフレームにズレが生じると、多地点テレビ会議制御装置から各テレビ会議端末への合成動画情報のＩＮＴＲＡフレームの送信も遅れることになり、その遅れの分だけ、ＶＣＵを発行したテレビ会議端末は受信動画像のフリーズを解除する事ができずに一定時間動画が停止してしまい、ＩＴＵ−Ｔ勧告Ｈ．２６１に規定されたタイムアウトによりフリーズが解除されてしまうと、タイムアウトによって復号化を再開しても、受信したＩＮＴＥＲフレームに対して参照すべき、ＩＮＴＲＡフレームをまだ受信していなため、その後の受信動画像が乱れた映像になってしまう。
【００１６】
上記の場合とは逆に、多地点テレビ会議制御装置で、あるテレビ会議端末からの受信動画データにエラーを検出した場合には、通常、多地点テレビ会議制御装置はテレビ会議端末に対してＶＣＵを発行する。しかし、多地点テレビ会議制御装置がアレイプロセッサにより画像合成を行っている場合には、受信した動画データの復号化を行っていないため、前述したテレビ会議端末での受信動画像の処理の様に、受信動画像を暫時フリーズするといった処理はできない。
【００１７】
このような場合の多地点テレビ会議制御装置の動作としては、
ａ）エラーフレームをそのまま、あるいはエラーを検出したフレームのみを破棄する。
ｂ）ＶＣＵのレスポンスがあるまで、無効データ（フィルフレーム）を挿入する。
が考えられる。
【００１８】
しかし、ａ）の場合にはエラーフレームを含む合成動画情報を受信したテレビ会議端末側でデコードエラーが発生して画像が乱れる。また、ｂ）の場合には画像の一部分だけが静止する。したがって、テレビ会議端末では合成後の１端末分の画像領域のデータが欠落した形になるので、その部分の画像は更新されず見た目でフリーズするため、エラーなのか、本当に静止しているのかの判別ができない。
【００１９】
【発明が解決しようとする課題】
以上説明したように、多地点テレビ会議制御装置において各テレビ会議端末から受信した動画像情報の切り出し、合成を行う際には、上記したような不具合が生じる問題点があった。
【００２０】
本発明は、係る事情に鑑みてなされたものであり、各テレビ会議端末から受信した符号化されたままの動画像情報を多地点テレビ会議制御装置が切り出し、合成してその合成動画情報をテレビ会議端末に送信する際に生じる不具合を解消することができるテレビ会議システムを提供することを目的とする。
【００２１】
【課題を解決するための手段】
請求項１記載の多地点テレビ会議システムは、複数の地点に設けられたテレビ会議端末を多地点テレビ会議制御装置に接続し、前記各テレビ会議端末から多地点テレビ会議制御装置に符号化された動画情報を伝送するとともに、前記多地点テレビ会議制御装置が前記各テレビ会議端末からの動画情報の一部を切り出して得た切り出し領域を合成し、その合成動画情報を各テレビ会議端末へ送信する多地点テレビ会議システムにおいて、前記多地点テレビ会議制御装置は、前記切り出し領域を前記各テレビ会議端末へ通知する手段を備える一方、前記各テレビ会議端末は、前記多地点テレビ会議制御装置から通知された前記切り出し領域に基づいて動きベクトル情報の付加領域を設定する手段と、その設定された付加領域にのみ動きベクトル情報を付加して前記多地点テレビ会議制御装置に送信する手段とを備えたことを特徴とする。
【００２７】
【発明の実施の形態】
以下、添付図面を参照しながら本発明の実施の形態に係るテレビ会議システムの制御方法について詳細に説明する。
【００２８】
図１は、本実施の形態に係るテレビ会議システムの制御方法が適用されるテレテレビ会議システムの構成を示している。
【００２９】
同図において、１、１９、２０は、本発明に関係する、同一構成のテレビ会議端末であり、ＩＳＤＮ回線１８により、ＩＳＤＮネットワークに接続されている。なお、図示していないが、本発明に関係するテレビ会議端末は、１、１９及び２０の３装置に限られない。また、２１は多地点テレビ会議制御装置であり、ＩＳＤＮ回線３１によりＩＳＤＮネットワークに接続されている。
【００３０】
図２は、本発明に関係するテレビ会議端末のうちのテレビ会議端末１について、そのブロック構成を示したものである。
【００３１】
同図において、２はシステム全体の制御を司り、ＣＰＵ、メモリ、タイマー等からなるシステム制御部、３は各種プログラムやデータを記憶するための磁気ディスク装置、４はＩＳＤＮのレイヤ１の信号処理とＤチャネルのレイヤ２の信号処理とを行うＩＳＤＮインターフェイス部、５はＩＴＵ−Ｔ勧告Ｈ．２２１に規定された信号処理によって、複数メディアのデータの多重・分離を行うマルチメデイア多重・分離部、６は音声入力のためのマイク、７は、マイク６からの入力信号を増幅した後Ａ／Ｄ変換を行う音声入力処理部、８は音声信号の符号化・復号化・エコーキャンセルを行う音声符号・復号化部、９は音声符号・復号化部８で復号化された音声信号をＤ／Ａ変換の後増幅する、音声出力処理部、１０は音声出力処理部９からの音声を出力するためのスピーカ、１１は映像入力のためのビデオカメラ、１２はビデオカメラ１１からの映像信号をＮＴＳＣデコード、Ａ／Ｄ変換等の信号処理を行う映像入力処理部、１３はＩＴＵ−Ｔ勧告Ｈ．２６１に準拠した動画像の符号化・復号化を行う動画符号化・復号化部、１４は、動画符号化・復号化装置１３で復号化された映像信号をＤ／Ａ変換、ＮＴＳＣエンコード、グラフイックス合成等の信号処理を行う映像出力処理部、１５は受信動画映像やグラフィックス情報を表示するためのモニター、１６はコンソールを制御するユーザーインターフェイス制御部、１７は操作キー及び表示部よりなるコンソール、１８はＩＳＤＮ回線である。
【００３２】
図３は、多地点テレビ会議制御装置２１のブロック構成を示している。同図において、２２はシステム全体の制御を司りＣＰＵ、メモリ、タイマー等からなるシステム制御部である。
【００３３】
２３はＩＳＤＮインターフェイス部、２４はマルチメデイア多重・分離部、２５は音声信号の符号化・復号化を行う音声符号・復号化部、２６は送信する動画データに訂正符号を付加してフレーム化する動画訂正符号生成部（ＩＴＵ−Ｔ勧告Ｈ．２６１参照）、２７は動画データの送信バッファ、２８は受信した動画データのフレーム同期を検出しエラー検出、訂正を行う動画エラー訂正・検出部（ＩＴＵ一Ｔ勧告Ｈ．２６１参照）、２９は、動画データの受信バッファであり、２３ないし２９の構成要素により、通信チャネル１が構成されている。
【００３４】
以上の構成は、通信チャネル１の構成であるが、図示するように、多地点テレビ会議制御装置２１は、１ないしｎの通信チャネルを備え、通信チャネル１以外の通信チャネルも、図示を省略しているが通信チャネル１と同一構成を備え、それぞれがＩＳＤＮ回線に接続されている。
【００３５】
また、図３に示されている接続のうち、各通信チャネルと音声・動画マルチプレクス部３０間の接続（音声データ送受、動画データ送受）は、詳細には、図４に示される様に各チャネル毎に別々の接続となっている。なお、図４については、後述する。
【００３６】
その音声・動画マルチプレクス部３０は、各通信チャネル１ないしｎで復号化された音声および動画のデータをチャネル間で合成し配送する者である。３１は、各通信チャネルに接続されたＩＳＤＮ回線である。
【００３７】
次に、テレビ会議システムの基本的な動作について図５を参照して説明する。同図において、テレビ会議を起動する際には、まず回線の接続を行う必要がある。これはＬＡＰＤを通じて行う通常の発呼手順に従う。ＳＥＴＵＰ（呼設定メッセージ）は、伝達能力（ＢＣ）を非制限デジタル、下位レイヤ整合性（ＬＬＣ）をＨ．２２１、高位レイヤ整合性（ＨＬＣ）を会議として送出する。
【００３８】
相手端末がＳＥＴＵＰを解析し、通信可能性が承認されると、相手端末はＣＯＮＮ（応答）を返し、呼が確立される。ここで、下位レイヤ整合性においてＨ．２２１とは、図２におけるマルチメデイア多重・分離部５で実行されるＩＴＵ−Ｔ勧告Ｈ．２２１がインプリメントされていることを示している。
【００３９】
呼が確立されると、システム制御部２はマルチメデイア多重・分離部５を制御し、マルチフレーム同期信号の送出を行いマルチフレーム同期を確立する。更に、システム制御部２はＩＴＵ一Ｔ勧告Ｈ．２４２に従いマルチメデイア多重・分離部５を制御して能力通知を行い、交信モードを確立する。これは、Ｈ．２２１上のＢＡＳ信号上で行い、共通能力で必要なチャネルの設定、ビットレートの割り当てを行う。本実施例では、音声、動画、デー夕（ＭＬＰ）の３つのチャネルがアサインされる。交信モードが確定すると、各チャネルは各々独立したデータとして取り扱う事が可能となり、テレビ会議としての動作を開始する。
【００４０】
以上の手順が、各テレビ会議端末と、多地点テレビ会議制御装置２１の各通信チャネルとの間で行われることにより、多地点テレビ会議制御装置２１を介して多地点テレビ会議が可能となる。
【００４１】
なお、動画データの通信帯城を送信、受信とで非対称１：４に設定する為には、ダミーのデータチャネル（ＬＳＤ）を確立する。例えば、回線の通信帯城がＩＳＤＮのＢＲＩ：１２８ｋｂｐｓであったとすると、
受信側 ： ３．２Ｋ（ＦＡＳ／ＢＡＳ）＋６．４Ｋ（ＭＬＰ）＋６４Ｋ（音声）＋５４．４Ｋ（動画）
送信側 ： ３．２Ｋ（ＦＡＳ／ＢＡＳ）＋６．４Ｋ（ＭＬＰ）＋６４Ｋ（音声）＋４０Ｋ（ＬＳＤ）＋１４．４Ｋ（動画）
といった設定を行い、送信側の動画データの通信帯域（１４．４Ｋ）を、送信側の動画データの通信帯域（５４．４Ｋ）の約４分の１に設定し、残りの約４分の３（４０ｋ）をダミーのＬＳＤに設定する。
【００４２】
しかしながら、上記の例でも明らかなように、ＬＳＤの取り得る通信帯域は、任意の容量を選択することはできず、予め決められたものの中から選択するしかない（ＩＴＵ−Ｔ勧告Ｈ．２２１参照）ため、通信帯域からその他のデータに配分される通信容量を差し引いた残りの通信帯域が配分される動画データには、正確に１：４の通信帯域を設定する事はできない。
【００４３】
テレビ会議が起動されると、システム制御部２は、音声符号・復号化部８及び動画符号・復号化部１３を起動し、音声、動画、及びデータの双方向通信が可能となる。
【００４４】
データチャネル（ＭＬＰ）上では、ＩＴＵ−Ｔ勧告草案Ｔ．１２０シリーズに規定されている会議運営にまつわる各種データの授受が行われる。データチャネル上のデータは、マルチメデイア多重・分離部５（多地点テレビ会議制御装置２１側では２４、以下同）で音声、動画データと分離、合成される。システム制御部２（あるいは２２）は、マルチメディア多重・分離部５（あるいは２４）へデータの読み出し、書き込みを行い、上記勧告草案で示される各プロトコルは、システム制御部２（あるいは２２）上において実行される。
【００４５】
テレビ会議終了時には、システム制御部２は、音声符号・復号化部８及び動画符号・復号化部１３を停止すると共に、ＩＳＤＮインターフェイス部４を制御し図５に示した手順に従い呼を解放する。
【００４６】
ユーザは、これまで述べた各動作（発呼、会議終了）の起動を、コンソール１７を操作して行う。入力された操作データは、ユーザーインターフェイス制御部１６を介してシステム制御部２へ通知される。システム制御部２は、操作データを解析し、操作内容に応じた動作の起動あるいは停止を行うと共に、ユーザーへのガイダンスの表示データを作成し、ユーザーインターフェイス制御部１６を介して、コンソール１７上へ表示させる。
【００４７】
多地点テレビ会議制御装置２１側では、上述した様な手順で、各通信チャネル毎に１つのテレビ会議端末と接続し、多地点間でのテレビ会議を運営する。なお、上述した例では、テレビ会議端末側からの発呼により接続する例について説明したが、あらかじめ定められた時刻に定められたテレビ会議端末へ多地点テレビ会議制御装置２１側から発呼し、接続することもできる。
【００４８】
次に、音声、動画のマルチプレクスの処理について説明する。図４は、多地点テレビ会議制御装置２１の音声・動画マルチプレクス部３０の構成を示している。同図において、１０１は各通信チャネルからのデコードされた音声データの音量レベルを監視し、どのチャネル（テレビ会議通信端末）からの音量レベルが最大であるかを検出する話者検出部、１０２は各通信チャネルからの音声データに重みづけを行ってミキシングを行う音声ミキシング部、１０３はマトリクススイッチからなり、各通信チャネルからの音声データ及び音声ミキシング部１０２からのミキシングデータを各通信チャネルに配信する音声切替部、１０４は各通信チャネルからの動画データ（デコードはされておらず、符号データのまま）をＩＴＵ−Ｔ勧告草案Ｔ１２８の１３．４．３項に示すような方法により合成を行うアレイプロセッサ部、１０５はマトリクススイッチからなり、各通信チャネルからの動画データ及びアレイプロセッサ部１０４からの合成データを各通信チャネルに配信する動画切替部である。
【００４９】
システム制御部２２は、ＩＴＵ−Ｔ勧告草案Ｔ．１２０シリーズのプロトコルに従って、または／及び、システム制御部２２にあらかじめ設定されているパラメータに基づく適応制御によって、音声、動画の合成形態（音声ミキシング部１０２における各チャネルの重みづけ、アレイプロセッサ部１０４における動画の合成位置、形状、音声切替部１０３における配信形態、動画切替部１０５における配信形態）を決定して、各部に設定する。また、上記合成形態の決定要因として話者の特定を行う必要のある場合には、話者検出部１０１から話者と判別されたチャネル番号（端末番号）を読み出し、要因として使用する。
【００５０】
一例として、９つのテレビ会議端末が接続され会議を行っている際に、話者として端末番号２が、また直前の話者として端末番号３が検出されていた場合の、各チャネルへの出力データの例を図６に示す。また、このときの音声ミキシング部１０２での合成形態（比率）の例を図７に、アレイプロセッサ部１０４での合成形態を図８に示す。
【００５１】
図８ではまた、画像切りだしを伴うアレイプロセッサ部１０４での処理の一例を示している。アレイプロセッサでは、送信する画像フォーマットに対して１／４の画像（縦横とも１／２）の画像を受信して合成を行うが、この例では更に受信した画像の一部を切り出して合成している。ここでは、送信がＦＣＩＦ、受信がＱＣＩＦフォーマットの例を示している。図中「ＭＢ」とあるのはマクロブロックを示しており、切りだし、合成はこのＭＢを最小単位として処理される。
【００５２】
符号データのまま（デコードせずに）図８に示すような画像の合成を行うには、ＩＴＵ−Ｔ勧告Ｈ．２６１におけるフレーム構造中の各層でのアドレス情報を書き換える必要がある。また、量子化ステップサイズの値も、必要に応じて（この値は必ずしもＭＢ層で付加されていないため、ＧＯＢ層で付加された値や前にＭＢ層で変更された値を管理し、合成位置でのＧＯＢ層や前の値と比較して必要に応じて付加する）書き換える。動きベクトルについては画像中の切りだし領域外が指し示された場合に参照する術を持たない為、付加する事はできない（テレビ会議端末側で全てのフレームを動きベクトル無しで符号化する）。
【００５３】
次に、本発明に係るテレビ会議システムにおけるいくつかの動作手順について、各実施形態に分けて説明する。
【００５４】
先ず第１実施形態ついて説明する。第１実施形態では、多地点テレビ会議制御装置装置は、アレイプロセッサで合成処理を行う際には、テレビ会議端末へ切りだし領域を通知し、テレビ会議端末は、通知された切りだし領域に基づいて動きベクトル付加領域を設定して動画の符号化を行う。
【００５５】
切り出し領域の通知は、アレイプロセッサ部１０４の起動時及び同部での合成形態の変更時に、Ｈ．２２１上のＢＡＳコマンド（ＭＢＥ）を用いて通知する（切りだしを行わない１フレーム全体を使用する場合にも通知は行う）。そのため、第１実施形態では、図５に示した能力交換の際にＭＢＥ能力有りとして能力交換を行う。（他の方法としてＭＬＰ上のプロトコルを用いても良い。）
【００５６】
多地点テレビ会議制御装置２１からの切りだし領域の通知に応じてテレビ会議端末が動きベクトル付加領域を設定して動画の符号化を行う処理の手順について図９を参照して説明する。なお、多地点テレビ会議制御装置装置に回線を介して接続されるテレビ会議端末の代表として、テレビ会議端末１についてのみ説明するが、その他のテレビ会議端末についても同様である（以後説明する実施形態においても同様である）。
【００５７】
図９において、テレビ会議端末１は、多地点テレビ会議制御装置２１からＢＡＳを受信すると、システム制御部２がそれをマルチメデイア多重・分離部５から読み込み、それが切りだし領域の通知かどうかをチェックする（判断１００１）。
【００５８】
図１０にその場合のＢＡＳコマンドの例を示す。同図において、最初のデータはＭＢＥの開始を示すＨ．２２１に規定されたデータ（コマンド：０ｘＦ９）、続いてデータのバイト数（５ｂｙｔｅ）、データが切りだし領域通知であることを示す識別子（０ｘ１Ｄ）、切りだし領域を示すデータとなっている。切りだし領域を示すデータは、４角形の４頂点のうちの１つ（左上の頂点）を切り出し開始位置としてそのｘ座標及びｙ座標をマクロブロック（ＭＢ）単位で指定するためのデータと４角形の大きさをｘ座標及びｙ座標方向のマクロブロック（ＭＢ）単位の長さで指定するためのデータにより構成されている。
【００５９】
さて、図９の手順において、受信したＢＡＳが切りだし領域の通知であると（判断１００１のＹｅｓ）、システム制御部２は、動きベクトル情報の付加領域を判定する（処理１００２）。
【００６０】
設定する付加領域は、
（１）切りだし領域より１ＭＢ分画像の内側の領域を動きベクトル付加領域とする。
（２）ただし、切りだし領域が画像領域の縁面に接する場合には、その辺については切りだし領域と同一とする。
の２点の法則に従って判定する。
【００６１】
図１１に画像切りだし領域と動きベクトル付加領域の関係について示す。切り出し領域の辺縁のマクロブロックは、その動きベクトルを求めるために切り出し領域外を参照する場合があるため、多地点テレビ会議制御装置２１において、動きベクトルの復号化を保証するために、同図（ａ）に示すように、動きベクトルの付加領域は、切り出し領域の１マクロブロック幅分の辺縁を除外した領域としている。これより、多地点テレビ会議制御装置２１においては、テレビ会議端末で付加された動きベクトルを確実に復号化できる（上記（１）の場合）。
【００６２】
また、同図（ｂ）、（ｃ）及び（ｄ）の例が、上述した（２）の場合にあたり、切り出し領域のいずれかの辺が、元の画像のいずれかの辺と接する場合は、その接する部分のマクロブロックには、元々動きベクトルは付加されていないため、その接する部分のマクロブロックは、動きベクトル付加領域とはしない。
【００６３】
さて、図９の手順において、処理１００２により上記したように動きベクトル付加領域を判定したシステム制御部２は、判定した動きベクトル付加領域を動画符号・復号化部１３に設定する（処理１００３）。
【００６４】
これにより、アレイプロセッサにより画像切り出しを伴う画像合成を行う際にも、動きベクトル情報を使用して画質の向上を図ることができる。
【００６５】
次に、第２実施形態について説明する。本実施形態では、多地点テレビ会議制御装置２１で行われる画像合成の方式をテレビ会議端末へ通知し、テレビ会議端末は、通知された方式に基づいて符号化された動画データに所定量の無効情報を付加して送信する。
【００６６】
切り出し領域の通知は、通信の開始時及び音声・動画マルチプレクス部３０での合成方式の変更時に、Ｈ．２２１上のＢＡＳコマンド（ＭＢＥ）を用いて通知する（合成を行わない場合にも通知は行う）。そのため、第２実施形態では、図５に示した能力交換の際にＭＢＥ能力有りとして能力交換を行う。（他の方法としてＭＬＰ上のプロトコルを用いても良い。）
【００６７】
第２実施形態の処理手順について、図１２を参照して説明する。同図において、、テレビ会議端末１は、ＢＡＳを受信すると、システム制御部２がそれをマルチメディア多重・分離部５から読み込み、それが合成方式の通知かどうかをチェックする（判断２００１）。
【００６８】
図１３に、その場合のＢＡＳコマンドの例を示す。同図において、最初のデータはＭＢＥの開始を示すＨ．２２１に規定されたデータ（コマンド）、続いてデータのバイト数、データが合成方式通知であることを示す識別子、合成方式を示すデータとなっている。
【００６９】
さて、図１２に示す手順において、受信したＢＡＳが合成方式の通知であると（判断２００１のＹｅｓ）、システム制御部２は、あらかじめ記憶されている図１４に示すような、合成方法に対応した評価値Ｑを判定する（処理２００３）。そして、システム制御部２は、判定して得た評価値から付加すべき無効情報量Ｉｉｎｖを算出する（処理２００３）。
【００７０】
無効情報量Ｉｉｎｖは、動画の送信伝送帯域をＢｔｘ、受信伝送帯域をＢｒｘ、評価値をＱとし、以下の式１で示される。
Ｉｉｎｖ＝Ｂｔｘ−（Ｂｒｘ×Ｑ）／１００ −（式１）
【００７１】
なお、図１４において、トランスコーダでの評価値が８０となっているのは、トランスコードの際の縮小または／及び切りだしの際の画像の高周波成分の増加に伴ってフレームレートが落ちてしまわないように、あらかじめ端末からの送信時に情報量を削減してしまうような動作を想定している。また、マルチプレクでの評価値は、４つのソース画像がマルチプレクスで処理される場合を想定している。
【００７２】
さて、システム制御部２は、算出した無効情報量Ｉｉｎｖを動画符号化・復号化部１３に設定する（処理２００４）。動画符号化・復号化部１３における無効情報の付加の方法には、ＩＴＵ−Ｔ勧告Ｈ．２６１で規定されている２つの方法（マクロブロックフィル／フィルビット挿入）のうちの、何れかあるいは両方を使用する。
【００７３】
以上の手順により、多地点テレビ会議制御装置２１における画像合成方式に応じて、多地点テレビ会議制御装置２１の動画送信バッファ２７がオーバーフローしないように、テレビ会議端末１側で本来の動画データに付加する無効情報を適応的に増減させるため、多地点テレビ会議制御装置２１における動画送信バッファのオーバーフロー回避することができる。
【００７４】
次に第３実施形態について説明する。本実施形態では、アレイプロセッサ（あるいはマルチプレクス）により画像合成が行われている際に、動画の送信バッファのオーバーフローを避ける為に図１５に示す手順の処理を行う。
【００７５】
同図において、通信中、アレイプロセッサ（あるいはマルチプレクス）によって画像合成が開始されると、多地点テレビ会議制御装置のシステム制御部２２は、各通信チャネルの動画送信バッファ２７の蓄積量を監視する（処理３００１、判断３００２のＮｏループ）。
【００７６】
所定量以上の蓄積量が検出されると（判断３００２のＹｅｓ）、システム制御部２２は、画像合成のソースとなっている通信チャネルの動画受信バッファ２９を検索する（処理３００３）。ＩＮＴＲＡモード（フレーム内での符号化処理）で符号化されているマクロブロック（ＭＢ）を検出すると（判断３００４のＹｅｓ）、システム制御部２２は、そのＭＢの合成後の画像位置を求め、処理３００１で検出した動画送信バッファ２７から、同じ画像位置の動画データを削除する（処理３００５）。
【００７７】
システム制御部２２は、以上の処理３００３〜３００５までの処理を、ソースとなっている全通信チヤネルに対して繰り返し行う（判断３００６のＮｏループ）。さらに、システム制御部２２は、判断３００２で検出した動画送信バッファ２７の蓄積量を確認し（判断３００７）、改善されていなければ（判断３００７のＮｏ）（まだ蓄積量が所定量以上であったら）従来のバツファオーバーフロ一のエラー処理（例えば、動画送信バッファ２７をクリアし、ソースとなっている全通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する）を行う（処理３００８）。
【００７８】
これにより、多地点テレビ会議制御装置２１でアレイプロセッサにより画像合成を行う際に、送信バッファの蓄積量が所定量以上になると、受信バッファからＩＮＴＲＡ−ＭＢのデータを検索し、合成画像上の同位置のデータが送信バッファから削除されるため、動画送信バッファ２７のオーバーフローを回避することができる。
【００７９】
次に、第４実施形態について説明する。本実施形態では、アレイプロセッサにより画像合成が行われている際に、テレビ会議端末からのＶＣＵコマンドを受信すると、そのレスポンスとして図１６に示す手順の処理を行う。
【００８０】
同図において、通信中、アレイプロセッサによって画像合成が開始されると、多地点テレビ会議制御装置２１のシステム制御部２２は、画像合成された動画を送信している各通信チャネルのマルチメディア多重分離部２４のＣ＆Ｉ符号（ＩＴＵ−Ｔ勧告Ｈ．２３０参照：ＶＣＵコマンドはＣ＆Ｉ符号の一つである）を読み出し、監視する（処理４００１及び判断４００２のＮｏループ）。
【００８１】
ＶＣＵコマンドが検出されると（判断４００２のＹｅｓ）、システム制御部２２は、画像合成のソースとなっている全通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する（全通信チャネルのマルチメデイア多重・分離部２４にＶＣＵコマンドのＣ＆Ｉ符号を書き込む）（処理４００３）。
【００８２】
さらにシステム制御部２２は、アレイプロセッサ部１０４に記憶画像データの送信を指示して、アレイプロセッサ部１０４は、あらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている画像データ（このデータは１フレーム分の画像データで、ＩＮＴＲＡモードで符号化されている）を出力すると共に、画像合成の処理を停止する（処理４００４）。その後、システム制御部２２は画像合成のソースとなっていた全通信チャネルの動画データを監視し（処理４００５、判断４００６のＮｏループ）、ＩＮＴＲＡフレームを検出すると（判断４００６のＹｅｓ）、その通信チャネルの画像合成を再開する（処理４００７）。
【００８３】
以上の処理４００５ないし４００７の処理を、画像合成のソースとなっていた全通信チャネルの画像合成が再開されるまで繰り返す（判断４００８のＮｏループ）。
【００８４】
以上の処理中における、テレビ会議端末側での画像の変化を、図１７に示す。同図において、（Ａ）は上述した図１６に示す手順における処理４００４での画像、（Ｂ）は処理４００５ないし４００７で一部の通信チャネルの画像合成が再開されている画像、（Ｃ）は全ての画像合成が再開されている画像（ＥＮＤ）を示している。
【００８５】
これにより、多地点テレビ会議制御装置２１がテレビ会議端末からＶＣＵコマンドを受信した場合には、他のテレビ会議端末にＶＣＵコマンドを発行すると共に、一旦あらかじめ記憶されているＩＮＴＲＡフレームの画像データを送信するため、多地点テレビ会議制御装置２１において合成される画像間の遅延差の発生を回避することができる。まは、テレビ会議端末における、画像のロックあるいは画像乱れを回避することができる。
【００８６】
次に、第５実施形態について説明する。本実施形態では、アレイプロセッサにより画像合成が行われている際に、そのソースとなっている通信チャネルで伝送エラーを検出した際に、そのレスポンスとして図１８に示す手順の処理を行う。
【００８７】
同図において、通信中、アレイプロセッサによって画像合成が開始されると、多地点テレビ会議制御装置２１のシステム制御部２２は、画像合成のソースとなっている各通信チャネルの動画エラー訂正・検出部２８のエラー情報を読み出し、監視する（処理５００１、判断５００２のＮｏループ）。訂正不能な伝送エラーが検出されると（判断５００２のＹｅｓ）、システム制御部２２は、エラーを検出した通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する（通信チャネルのマルチメデイア多重・分離部２４にＶＣＵコマンドのＣ＆Ｉ符号を書き込む）（処理５００３）。
【００８８】
さらにシステム制御部２２は、アレイプロセッサ部１０４に記憶画像データの合成を指示して、アレイプロセッサ部１０４は、あらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている画像データ（このデータは１フレーム分の画像データで、ＩＮＴＲＡモードで符号化されている）をエラーを検出した通信チャネルの画像データとして画像合成を行う（処理５００４）。その後、システム制御部２２はエラーを検出した通信チヤネルの動画データを監視し（処理５００５、判断５００５のＮｏループ）、ＩＮＴＲＡフレームを検出すると（判断５００６のＹｅｓ）、その通信チャネルから受信したデータによる画像合成を再開する（処理５００７）。
【００８９】
以上の処理中における、テレビ会議端末側での画像の変化を、図１９に示す。同図において、（Ａ）は上述した処理５００４での画像、（Ｂ）は、処理５００７において受信したデータによる画像合成が再開されている画像（ＥＮＤ）を示している。
【００９０】
これにより、多地点テレビ会議制御装置２１がテレビ会議端末からの動画データに伝送エラーを検出した場合には、テレビ会議端末にＶＣＵコマンドを発行すると共に、一旦あらかじめ記憶されているＩＮＴＲＡフレームの画像データを合成するため、テレビ会議端末における、画像乱れを回避することができる、また、テレビ会議端末において、ユーザーに画像更新中であることを明示することができる。
【００９１】
第５実施形態は、上記した利点を有するが、あるテレビ会議端末からの受信動画データにエラーが発すると、多地点テレビ会議制御装置２１が、あらかじめ記憶してある符号化された画像データを、エラーを検出した受信動画データの代わりに伝送する場合に、その画像データのサイズが一定であると（１つのテレビ会議端末に割り当てられている（帯域／フレームレート）以上であると）伝送バッファがオーバーフローしてしまう（アレイプロセッサでは、フレームレートを落とす（フレームスキップにより情報を削減する）ことができないため）。
【００９２】
その問題を解決する、第６実施形態にいつて以下説明する。本実施形態では、第５実施形態に係る図１８に示した処理手順における処理５００４で使用する画像データとして、それぞれデータ長の異なる複数の画像データを持ち、動画送信の伝送レートと合成数に従って適宜選択して使用する。
【００９３】
図２０に記憶画像データのデータ長の例を示す。多地点テレビ会議制御装置２１のアレイプロセッサ部１０４には図２０に示すような複数のデータ長の画像データが、画像データ番号に対応してあらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている。なお、これらの画像データは内容は同一のもので、符号化における圧縮率が異なる（精細度が異なる）ものである。
【００９４】
システム制御部２２は、図１８に示す処理５００４においてアレイプロセッサ部１０４に記憶画像データの合成を指示する際に、（動画送信に割り当てられている帯域／合成数（画像合成のソースの数））を算出し、それを基に、あらかじめシステム制御部２２内に記憶されている図２０に示すテーブルを参照して、使用する画像データ番号を決定してアレイプロセッサ部１０４に通知する。アレイプロセッサ部１０４は、通知された画像データ番号に従って、画像データを合成し出力する。
【００９５】
なお、第６実施形態では、フレームレートが１５ｆｐｓ固定の場合について示したが、フレームレートもオーバーフローの要因となるため、これに適応する複数の画像データを持つ事も有効である。同一内容で圧縮率の異なる複数の画像データを記憶している例について示したが、画像内容そのものを異なるものとし、同一の圧縮率でデータ長の異なるものを記憶しておいても良い。
【００９６】
【発明の効果】
請求項１に係る発明によれば、多地点テレビ会議制御装置において符号化されたままの動画情報を、画像切り出しを伴って画像合成を行う際には、画像の切りだし領域を各テレビ会議端末通知し、各テレビ会議端末では、通知された画像の切りだし領域に基づいて動きベクトルの付加領域を設定し、その付加領域にのみ動くベクトル情報を付加するため、符号化されたままの動画情報を、画像切り出しを伴って画像合成を行う際にも動きベクトル情報を使用して画質の向上を計ることができる。また、いわゆるアレイプロセッサにより画像切りだしを伴う画像合成とスイッチングサービスとを併用して運用することができる利点もある。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るテレビ会議システムの構成を示す図である。
【図２】本発明の実施の形態に係るテレビ会議端末のブロック構成を示す図である。
【図３】本発明の実施の形態に係る多地点地点テレビ会議制御装置のブロック構成を示す図である。
【図４】本発明の実施の形態に係る多地点地点テレビ会議制御装置のの音声・動画マルチプレクス部３０の構成を示している。
【図５】本発明の実施の形態に係るテレビ会議システムの基本的な動作を示す図である。
【図６】各通信チャネルへ出力される音声及び動画データの例を示す図である。
【図７】音声ミキシング部での各通信チャネル別の重み付けの合成形態（比率）の例を示す図である。
【図８】アレイプロセッサ部での画像合成形態及び、画像切り出しを伴うアレイプロセッサ部での処理の一例を示す図である。
【図９】本発明に係るテレビ会議システムにおける第１実施形態の処理手順を示すフローチャートである。
【図１０】第１実施形態に係る処理手順におけるＢＡＳコマンドの一例を示す図である。
【図１１】第１実施形態に係る画像切りだし領域と動きベクトル付加領域の関係について示す図である。
【図１２】本発明に係るテレビ会議システムにおける第２実施形態の処理手順を示すフローチャートである。
【図１３】第２実施形態に係る処理手順におけるＢＡＳコマンドの一例を示す図である。
【図１４】第２実施形態に係る処理手順における合成方法と評価値との対応例を示す図である。
【図１５】本発明に係るテレビ会議システムにおける第３実施形態の処理手順を示すフローチャートである。
【図１６】本発明に係るテレビ会議システムにおける第４実施形態の処理手順を示すフローチャートである。
【図１７】第４実施形態に係る処理手順におけるテレビ会議端末側での画像の変化を示す図である。
【図１８】本発明に係るテレビ会議システムにおける第５実施形態の処理手順を示すフローチャートである。
【図１９】第４実施形態に係る処理手順におけるテレビ会議端末側での画像の変化を示す図である。
【図２０】第５実施形態に係る記憶画像データのデータ長の一例を示す図である。
【符号の説明】
１、１９、２０ テレビ会議端末
２ システム制御部
３ 磁気ディスク装置
４ ＩＳＤＮインターフェイス部
５ マルチメデイア多重・分離部
６ マイク
７ 音声入力処理部
８ 音声符号・復号化部
９ 音声出力処理部
１０ スピーカ
１１ ビデオカメラ
１２ 映像入力処理部
１３ 動画符号化・復号化部
１４ 映像出力処理部
１５ モニター
１６ ユーザーインターフェイス制御部
１７ コンソール
１８、３１ ＩＳＤＮ回線
２２ システム制御部
２３ ＩＳＤＮインターフェイス部
２４ マルチメデイア多重・分離部
２５ 音声符号・復号化部
２６ 動画訂正符号生成部
２７ 動画送信バッファ
２８ 動画エラー訂正・検出部
２９ 動画データ受信バッファ
３０ 音声・動画マルチプレクス部
１０１ 話者検出部
１０２ 音声ミキシング部
１０３ 音声切替部
１０４ アレイプロセッサ部
１０５ 動画切替部
【発明の属する技術分野】
符号化されたままの伝送動画情報の合成を伴う多地点テレビ会議システムに関する。
【０００２】
【従来の技術】
従来の多地点テレビ会議制御装置においては動画情報の切り出し、合成を行う際には、特開平４−６３０８４号公報に見られるように、回線によって接続された各テレビ会議端末からの受信動画情報を一旦復号化した後に合成等の処理を行い、再符号化して送信している。
【０００３】
しかしながら上記の方法では、多地点テレビ会議制御装置は、接続されるテレビ会議端末数分の動画復号化器を備える必要があり、装置のコストの増大を招いていた。
【０００４】
そのため、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．４．３項に示す様に、受信動画像の完全な復号化を行わずに（完全な復号化とは、ＩＴＵ−Ｔ勧告Ｈ．２６１に示される復号化の手順を全て実行する事を指す）、符号化されている動画情報の内、ＧＯＢ番号のみを書き換える（この処理はＴ．１２８内には記述されていないが、Ｈ．２６１との整合を考えるとこの処理が必要である）ことによって、４つのＱＣＩＦ動画情報を１つのＦＣＩＦ動画情報へ合成する様な方法が提案されている。
【０００５】
しかしながら、上記の方法では、特開平４−６３０８４号公報に開示された多地点間テレビ会議システムの様に画像の一部分の切り出しを伴う様な場合（ただし、この多地点間テレビ会議システムでは一旦復号化を行ってから切り出し、合成を行っているので、本発明の構成とは異なる）には、テレビ会議端末からの受信動画情報において動きベクトルが切り出し領域の外を参照している様な場合に対応する事ができない為、テレビ会議端末側ではフレームの全体を動きベクトル情報無しのまま符号化（ＩＴＵ−Ｔ勧告Ｈ．２６１規定のＭＴＹＰＥをＩＮＴＲＡもしくはＩＮＴＥＲ）するしかなく、符号量が増大し、ひいては画質の低下を招くという不具合が発生する。
【０００６】
テレビ会議端末側で、切り出し領域の画像のみを符号化して送信するような構成もあり得るが、その場合にはＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．１項に示されているスイッチクングサービスとの併用（あるテレビ会議端末にはアレイプロセッサによる合成画像を送信し、別のテレビ会議端末にはスイッチングサービスによって、合成していないあるテレビ会議端末からの画像を送信するような場合、例えば、発言者と前発言者のテレビ会議端末にはお互いの画像をスイッチングサービスで提供し、それら以外のテレビ会議端末にはアレイプロセッサで合成画像を提供する場合に対応することができない。
【０００７】
また、多地点テレビ会議制御装置における画像合成の方法には、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．４項に示されているマルチプレクスモード、トランスコーダ及びアレイプロセッサの３通りの方法が提案されている。
【０００８】
これらのうち、マルチプレクスモード、アレイプロセッサにおいては、送信側テレビ会議端末に設定される動画情報の通信帯域の容量を１とすると、受信側のテレビ会議端末には動画情報のために容量４の通信帯域を設定する事が前提となる。
【０００９】
しかしながら、通常の回線交換による回線（パケットではない）では、回線の持つ帯域は固定であり、その固定の帯域内を送信、受信で対称に、音声用、データ用、動画用に分割して利用するのが常である。これらの手順はＩＴＵ−Ｔ勧告Ｈ．２２１・２４２に定義される。勧告Ｈ．２２１では、送信、受信非対称の帯域の設定も可能であるが、通常用いられない。また、動画の帯城は音声及びデータで使われた残りが割り当てられるため、送信に対して正確に４倍の受信帯域を割り当てる事はできない。
【００１０】
また、ＩＴＵ−Ｔ勧告草案Ｔ．１２８の１３．１項に示されているスイッチングサービスでは、ソースとして選択された動画の帯城に受信側の帯域を合わせる必要があり、通常、スイッチングサービスに対応するために、各テレビ会議端末の送信、受信の帯城を対称にし、かつ各端末での帯域も同一に合わせるような動作が想定される。
【００１１】
以上を鑑みて、上記２通りの画像合成の方法を考えると、
マルチプレクスモードでは、
ａ）送信側及び受信側のテレビ会議端末に対称の通信帯城を割り当てた場合には、多地点テレビ会議制御装置の送信バッファのオーバーフローが発生する。つまり、対称の通信帯域を割り当てた場合には、実用に供さない。
ｂ）送信側及び受信側のテレビ会議端末に非対称の通信帯域を割り当てた場合にも、通信帯域を正確に１：４に設定する事はできない為、バッファのオーバーフローが発生する（アンダーフローも発生しうるが、これは誤り訂正フレームでのフィルビット挿入により回避できる：ＩＴＵ−Ｔ勧告Ｈ．２６１参照）。また、スイッチングサービスとコンティニュアスプレゼンスモードの切り替えの度にビデオ帯城を再設定する必要があり、切り替えに時間がかかる。
アレイプロセッサでは、
ａ）送信側及び受信側のテレビ会議端末に対称の通信帯域を割り当てた場合には、多地点テレビ会議制御装置の送信バッファにオーバーフローが発生する。つまり、対象の通信帯城を割り当てた場合には、実用に供さない。
ｂ）送信側及び受信側のテレビ会議端末に非対称の通信帯城を割り当てた場合にも、通信帯域を正確に１：４に設定する事はできない為、バッファのオーバーフローが発生する。また、スイッチングサービスとコンティニュアスプレゼンスモードの切り替えの度にビデオ帯域を再設定する必要があり、切り替えに時間がかかる。さらに、多地点テレビ会議制御装において動画情報の切り出しを伴うような場合には、ＧＯＢ番号だけでなく、各層でのアドレスや動きベクトル情報も書き換える必要があり、そのことによる符号量の増大によって、送信バッファのオーバーフローが発生する可能性がある。
【００１２】
また、アレイプロセッサにより画像合成を行っている多地点テレビ会議制御装置を介して各テレビ会議端末が多地点会議を行っている場合に、あるテレビ会議端末からＶＣＵ（ビデオコマンド−ファーストアップデイトリクエスト：ＩＴＵ−Ｔ勧告Ｈ．２３０参照）の指示があると、多地点テレビ会議制御装置は回線を介して接続されている全てのテレビ会議端末にＶＣＵを発行して各テレビ会議端末からのＩＮＴＲＡフレーム（１フレーム全体がＩＮＴＲＡモードで符号化されたフレームを指す：通常このようなフレームでは、ＩＴＵ−Ｔ勧告Ｈ．２６１に規定されているＰＴＹＰＥ−第３ビット（Ｆｒｅｅｚｅ Ｒｅｌｅａｓｅ）をオン（＝１）し、そのビットによりＩＮＴＲＡフレームか否かを判別する）の動画情報を合成してテレビ会議端末に送信するように動作する。
【００１３】
しかしながら、多地点テレビ会議制御装置から発行されたＶＣＵに対する各テレビ会議端末の応答には時間的なズレがあるために、同一構成のテレビ会議端末でかつ伝送バッファ状態が同様であったとしても、最大（１／フレームレート）秒のズレが発生するため、すべてのテレビ会議端末からのＩＮＴＲＡフレームの動画情報が揃うまでは、合成後の動画情報をＩＮＴＲＡフレームとしてテレビ会議端末に送信できないケースが発生する。
【００１４】
もっとも、多地点テレビ会議端末が伝送バッファで全てのテレビ会議端末からのＩＮＴＲＡフレームの動画情報を待つ事により、合成動画情報のＩＮＴＲＡフレームを構成する事はできるが、各テレビ会議端末からの動画情報には、端末ごとに異なる大きな遅延が発生することになるため、特別な処理を行わない限りＩＮＴＲＡフレームの送信後も、合成動画情報を構成する各テレビ会議端末からの動画情報は、互いに時間的にズレたままになってしまう。
【００１５】
また、ＶＣＵを発行したテレビ会議端末が、受信した動画データをデコードし続けていれば問題なく動画像は復旧するが、通常、交信中にテレビ会議端末がＶＣＵを発行するのは、受信データにエラーが検出された場合である。その場合、多くのテレビ会議端末は、受信動画像をフリーズして多地点テレビ会議制御装置からのＩＮＴＲＡフレームを待ち、ＩＮＴＲＡフレームの受信によってフリーズを解除する様に動作する。そのため、多地点テレビ会議制御装置の受信する各テレビ会議端末からＶＣＵに応答して送信されたＩＮＴＲＡフレームにズレが生じると、多地点テレビ会議制御装置から各テレビ会議端末への合成動画情報のＩＮＴＲＡフレームの送信も遅れることになり、その遅れの分だけ、ＶＣＵを発行したテレビ会議端末は受信動画像のフリーズを解除する事ができずに一定時間動画が停止してしまい、ＩＴＵ−Ｔ勧告Ｈ．２６１に規定されたタイムアウトによりフリーズが解除されてしまうと、タイムアウトによって復号化を再開しても、受信したＩＮＴＥＲフレームに対して参照すべき、ＩＮＴＲＡフレームをまだ受信していなため、その後の受信動画像が乱れた映像になってしまう。
【００１６】
上記の場合とは逆に、多地点テレビ会議制御装置で、あるテレビ会議端末からの受信動画データにエラーを検出した場合には、通常、多地点テレビ会議制御装置はテレビ会議端末に対してＶＣＵを発行する。しかし、多地点テレビ会議制御装置がアレイプロセッサにより画像合成を行っている場合には、受信した動画データの復号化を行っていないため、前述したテレビ会議端末での受信動画像の処理の様に、受信動画像を暫時フリーズするといった処理はできない。
【００１７】
このような場合の多地点テレビ会議制御装置の動作としては、
ａ）エラーフレームをそのまま、あるいはエラーを検出したフレームのみを破棄する。
ｂ）ＶＣＵのレスポンスがあるまで、無効データ（フィルフレーム）を挿入する。
が考えられる。
【００１８】
しかし、ａ）の場合にはエラーフレームを含む合成動画情報を受信したテレビ会議端末側でデコードエラーが発生して画像が乱れる。また、ｂ）の場合には画像の一部分だけが静止する。したがって、テレビ会議端末では合成後の１端末分の画像領域のデータが欠落した形になるので、その部分の画像は更新されず見た目でフリーズするため、エラーなのか、本当に静止しているのかの判別ができない。
【００１９】
【発明が解決しようとする課題】
以上説明したように、多地点テレビ会議制御装置において各テレビ会議端末から受信した動画像情報の切り出し、合成を行う際には、上記したような不具合が生じる問題点があった。
【００２０】
本発明は、係る事情に鑑みてなされたものであり、各テレビ会議端末から受信した符号化されたままの動画像情報を多地点テレビ会議制御装置が切り出し、合成してその合成動画情報をテレビ会議端末に送信する際に生じる不具合を解消することができるテレビ会議システムを提供することを目的とする。
【００２１】
【課題を解決するための手段】
請求項１記載の多地点テレビ会議システムは、複数の地点に設けられたテレビ会議端末を多地点テレビ会議制御装置に接続し、前記各テレビ会議端末から多地点テレビ会議制御装置に符号化された動画情報を伝送するとともに、前記多地点テレビ会議制御装置が前記各テレビ会議端末からの動画情報の一部を切り出して得た切り出し領域を合成し、その合成動画情報を各テレビ会議端末へ送信する多地点テレビ会議システムにおいて、前記多地点テレビ会議制御装置は、前記切り出し領域を前記各テレビ会議端末へ通知する手段を備える一方、前記各テレビ会議端末は、前記多地点テレビ会議制御装置から通知された前記切り出し領域に基づいて動きベクトル情報の付加領域を設定する手段と、その設定された付加領域にのみ動きベクトル情報を付加して前記多地点テレビ会議制御装置に送信する手段とを備えたことを特徴とする。
【００２７】
【発明の実施の形態】
以下、添付図面を参照しながら本発明の実施の形態に係るテレビ会議システムの制御方法について詳細に説明する。
【００２８】
図１は、本実施の形態に係るテレビ会議システムの制御方法が適用されるテレテレビ会議システムの構成を示している。
【００２９】
同図において、１、１９、２０は、本発明に関係する、同一構成のテレビ会議端末であり、ＩＳＤＮ回線１８により、ＩＳＤＮネットワークに接続されている。なお、図示していないが、本発明に関係するテレビ会議端末は、１、１９及び２０の３装置に限られない。また、２１は多地点テレビ会議制御装置であり、ＩＳＤＮ回線３１によりＩＳＤＮネットワークに接続されている。
【００３０】
図２は、本発明に関係するテレビ会議端末のうちのテレビ会議端末１について、そのブロック構成を示したものである。
【００３１】
同図において、２はシステム全体の制御を司り、ＣＰＵ、メモリ、タイマー等からなるシステム制御部、３は各種プログラムやデータを記憶するための磁気ディスク装置、４はＩＳＤＮのレイヤ１の信号処理とＤチャネルのレイヤ２の信号処理とを行うＩＳＤＮインターフェイス部、５はＩＴＵ−Ｔ勧告Ｈ．２２１に規定された信号処理によって、複数メディアのデータの多重・分離を行うマルチメデイア多重・分離部、６は音声入力のためのマイク、７は、マイク６からの入力信号を増幅した後Ａ／Ｄ変換を行う音声入力処理部、８は音声信号の符号化・復号化・エコーキャンセルを行う音声符号・復号化部、９は音声符号・復号化部８で復号化された音声信号をＤ／Ａ変換の後増幅する、音声出力処理部、１０は音声出力処理部９からの音声を出力するためのスピーカ、１１は映像入力のためのビデオカメラ、１２はビデオカメラ１１からの映像信号をＮＴＳＣデコード、Ａ／Ｄ変換等の信号処理を行う映像入力処理部、１３はＩＴＵ−Ｔ勧告Ｈ．２６１に準拠した動画像の符号化・復号化を行う動画符号化・復号化部、１４は、動画符号化・復号化装置１３で復号化された映像信号をＤ／Ａ変換、ＮＴＳＣエンコード、グラフイックス合成等の信号処理を行う映像出力処理部、１５は受信動画映像やグラフィックス情報を表示するためのモニター、１６はコンソールを制御するユーザーインターフェイス制御部、１７は操作キー及び表示部よりなるコンソール、１８はＩＳＤＮ回線である。
【００３２】
図３は、多地点テレビ会議制御装置２１のブロック構成を示している。同図において、２２はシステム全体の制御を司りＣＰＵ、メモリ、タイマー等からなるシステム制御部である。
【００３３】
２３はＩＳＤＮインターフェイス部、２４はマルチメデイア多重・分離部、２５は音声信号の符号化・復号化を行う音声符号・復号化部、２６は送信する動画データに訂正符号を付加してフレーム化する動画訂正符号生成部（ＩＴＵ−Ｔ勧告Ｈ．２６１参照）、２７は動画データの送信バッファ、２８は受信した動画データのフレーム同期を検出しエラー検出、訂正を行う動画エラー訂正・検出部（ＩＴＵ一Ｔ勧告Ｈ．２６１参照）、２９は、動画データの受信バッファであり、２３ないし２９の構成要素により、通信チャネル１が構成されている。
【００３４】
以上の構成は、通信チャネル１の構成であるが、図示するように、多地点テレビ会議制御装置２１は、１ないしｎの通信チャネルを備え、通信チャネル１以外の通信チャネルも、図示を省略しているが通信チャネル１と同一構成を備え、それぞれがＩＳＤＮ回線に接続されている。
【００３５】
また、図３に示されている接続のうち、各通信チャネルと音声・動画マルチプレクス部３０間の接続（音声データ送受、動画データ送受）は、詳細には、図４に示される様に各チャネル毎に別々の接続となっている。なお、図４については、後述する。
【００３６】
その音声・動画マルチプレクス部３０は、各通信チャネル１ないしｎで復号化された音声および動画のデータをチャネル間で合成し配送する者である。３１は、各通信チャネルに接続されたＩＳＤＮ回線である。
【００３７】
次に、テレビ会議システムの基本的な動作について図５を参照して説明する。同図において、テレビ会議を起動する際には、まず回線の接続を行う必要がある。これはＬＡＰＤを通じて行う通常の発呼手順に従う。ＳＥＴＵＰ（呼設定メッセージ）は、伝達能力（ＢＣ）を非制限デジタル、下位レイヤ整合性（ＬＬＣ）をＨ．２２１、高位レイヤ整合性（ＨＬＣ）を会議として送出する。
【００３８】
相手端末がＳＥＴＵＰを解析し、通信可能性が承認されると、相手端末はＣＯＮＮ（応答）を返し、呼が確立される。ここで、下位レイヤ整合性においてＨ．２２１とは、図２におけるマルチメデイア多重・分離部５で実行されるＩＴＵ−Ｔ勧告Ｈ．２２１がインプリメントされていることを示している。
【００３９】
呼が確立されると、システム制御部２はマルチメデイア多重・分離部５を制御し、マルチフレーム同期信号の送出を行いマルチフレーム同期を確立する。更に、システム制御部２はＩＴＵ一Ｔ勧告Ｈ．２４２に従いマルチメデイア多重・分離部５を制御して能力通知を行い、交信モードを確立する。これは、Ｈ．２２１上のＢＡＳ信号上で行い、共通能力で必要なチャネルの設定、ビットレートの割り当てを行う。本実施例では、音声、動画、デー夕（ＭＬＰ）の３つのチャネルがアサインされる。交信モードが確定すると、各チャネルは各々独立したデータとして取り扱う事が可能となり、テレビ会議としての動作を開始する。
【００４０】
以上の手順が、各テレビ会議端末と、多地点テレビ会議制御装置２１の各通信チャネルとの間で行われることにより、多地点テレビ会議制御装置２１を介して多地点テレビ会議が可能となる。
【００４１】
なお、動画データの通信帯城を送信、受信とで非対称１：４に設定する為には、ダミーのデータチャネル（ＬＳＤ）を確立する。例えば、回線の通信帯城がＩＳＤＮのＢＲＩ：１２８ｋｂｐｓであったとすると、
受信側 ： ３．２Ｋ（ＦＡＳ／ＢＡＳ）＋６．４Ｋ（ＭＬＰ）＋６４Ｋ（音声）＋５４．４Ｋ（動画）
送信側 ： ３．２Ｋ（ＦＡＳ／ＢＡＳ）＋６．４Ｋ（ＭＬＰ）＋６４Ｋ（音声）＋４０Ｋ（ＬＳＤ）＋１４．４Ｋ（動画）
といった設定を行い、送信側の動画データの通信帯域（１４．４Ｋ）を、送信側の動画データの通信帯域（５４．４Ｋ）の約４分の１に設定し、残りの約４分の３（４０ｋ）をダミーのＬＳＤに設定する。
【００４２】
しかしながら、上記の例でも明らかなように、ＬＳＤの取り得る通信帯域は、任意の容量を選択することはできず、予め決められたものの中から選択するしかない（ＩＴＵ−Ｔ勧告Ｈ．２２１参照）ため、通信帯域からその他のデータに配分される通信容量を差し引いた残りの通信帯域が配分される動画データには、正確に１：４の通信帯域を設定する事はできない。
【００４３】
テレビ会議が起動されると、システム制御部２は、音声符号・復号化部８及び動画符号・復号化部１３を起動し、音声、動画、及びデータの双方向通信が可能となる。
【００４４】
データチャネル（ＭＬＰ）上では、ＩＴＵ−Ｔ勧告草案Ｔ．１２０シリーズに規定されている会議運営にまつわる各種データの授受が行われる。データチャネル上のデータは、マルチメデイア多重・分離部５（多地点テレビ会議制御装置２１側では２４、以下同）で音声、動画データと分離、合成される。システム制御部２（あるいは２２）は、マルチメディア多重・分離部５（あるいは２４）へデータの読み出し、書き込みを行い、上記勧告草案で示される各プロトコルは、システム制御部２（あるいは２２）上において実行される。
【００４５】
テレビ会議終了時には、システム制御部２は、音声符号・復号化部８及び動画符号・復号化部１３を停止すると共に、ＩＳＤＮインターフェイス部４を制御し図５に示した手順に従い呼を解放する。
【００４６】
ユーザは、これまで述べた各動作（発呼、会議終了）の起動を、コンソール１７を操作して行う。入力された操作データは、ユーザーインターフェイス制御部１６を介してシステム制御部２へ通知される。システム制御部２は、操作データを解析し、操作内容に応じた動作の起動あるいは停止を行うと共に、ユーザーへのガイダンスの表示データを作成し、ユーザーインターフェイス制御部１６を介して、コンソール１７上へ表示させる。
【００４７】
多地点テレビ会議制御装置２１側では、上述した様な手順で、各通信チャネル毎に１つのテレビ会議端末と接続し、多地点間でのテレビ会議を運営する。なお、上述した例では、テレビ会議端末側からの発呼により接続する例について説明したが、あらかじめ定められた時刻に定められたテレビ会議端末へ多地点テレビ会議制御装置２１側から発呼し、接続することもできる。
【００４８】
次に、音声、動画のマルチプレクスの処理について説明する。図４は、多地点テレビ会議制御装置２１の音声・動画マルチプレクス部３０の構成を示している。同図において、１０１は各通信チャネルからのデコードされた音声データの音量レベルを監視し、どのチャネル（テレビ会議通信端末）からの音量レベルが最大であるかを検出する話者検出部、１０２は各通信チャネルからの音声データに重みづけを行ってミキシングを行う音声ミキシング部、１０３はマトリクススイッチからなり、各通信チャネルからの音声データ及び音声ミキシング部１０２からのミキシングデータを各通信チャネルに配信する音声切替部、１０４は各通信チャネルからの動画データ（デコードはされておらず、符号データのまま）をＩＴＵ−Ｔ勧告草案Ｔ１２８の１３．４．３項に示すような方法により合成を行うアレイプロセッサ部、１０５はマトリクススイッチからなり、各通信チャネルからの動画データ及びアレイプロセッサ部１０４からの合成データを各通信チャネルに配信する動画切替部である。
【００４９】
システム制御部２２は、ＩＴＵ−Ｔ勧告草案Ｔ．１２０シリーズのプロトコルに従って、または／及び、システム制御部２２にあらかじめ設定されているパラメータに基づく適応制御によって、音声、動画の合成形態（音声ミキシング部１０２における各チャネルの重みづけ、アレイプロセッサ部１０４における動画の合成位置、形状、音声切替部１０３における配信形態、動画切替部１０５における配信形態）を決定して、各部に設定する。また、上記合成形態の決定要因として話者の特定を行う必要のある場合には、話者検出部１０１から話者と判別されたチャネル番号（端末番号）を読み出し、要因として使用する。
【００５０】
一例として、９つのテレビ会議端末が接続され会議を行っている際に、話者として端末番号２が、また直前の話者として端末番号３が検出されていた場合の、各チャネルへの出力データの例を図６に示す。また、このときの音声ミキシング部１０２での合成形態（比率）の例を図７に、アレイプロセッサ部１０４での合成形態を図８に示す。
【００５１】
図８ではまた、画像切りだしを伴うアレイプロセッサ部１０４での処理の一例を示している。アレイプロセッサでは、送信する画像フォーマットに対して１／４の画像（縦横とも１／２）の画像を受信して合成を行うが、この例では更に受信した画像の一部を切り出して合成している。ここでは、送信がＦＣＩＦ、受信がＱＣＩＦフォーマットの例を示している。図中「ＭＢ」とあるのはマクロブロックを示しており、切りだし、合成はこのＭＢを最小単位として処理される。
【００５２】
符号データのまま（デコードせずに）図８に示すような画像の合成を行うには、ＩＴＵ−Ｔ勧告Ｈ．２６１におけるフレーム構造中の各層でのアドレス情報を書き換える必要がある。また、量子化ステップサイズの値も、必要に応じて（この値は必ずしもＭＢ層で付加されていないため、ＧＯＢ層で付加された値や前にＭＢ層で変更された値を管理し、合成位置でのＧＯＢ層や前の値と比較して必要に応じて付加する）書き換える。動きベクトルについては画像中の切りだし領域外が指し示された場合に参照する術を持たない為、付加する事はできない（テレビ会議端末側で全てのフレームを動きベクトル無しで符号化する）。
【００５３】
次に、本発明に係るテレビ会議システムにおけるいくつかの動作手順について、各実施形態に分けて説明する。
【００５４】
先ず第１実施形態ついて説明する。第１実施形態では、多地点テレビ会議制御装置装置は、アレイプロセッサで合成処理を行う際には、テレビ会議端末へ切りだし領域を通知し、テレビ会議端末は、通知された切りだし領域に基づいて動きベクトル付加領域を設定して動画の符号化を行う。
【００５５】
切り出し領域の通知は、アレイプロセッサ部１０４の起動時及び同部での合成形態の変更時に、Ｈ．２２１上のＢＡＳコマンド（ＭＢＥ）を用いて通知する（切りだしを行わない１フレーム全体を使用する場合にも通知は行う）。そのため、第１実施形態では、図５に示した能力交換の際にＭＢＥ能力有りとして能力交換を行う。（他の方法としてＭＬＰ上のプロトコルを用いても良い。）
【００５６】
多地点テレビ会議制御装置２１からの切りだし領域の通知に応じてテレビ会議端末が動きベクトル付加領域を設定して動画の符号化を行う処理の手順について図９を参照して説明する。なお、多地点テレビ会議制御装置装置に回線を介して接続されるテレビ会議端末の代表として、テレビ会議端末１についてのみ説明するが、その他のテレビ会議端末についても同様である（以後説明する実施形態においても同様である）。
【００５７】
図９において、テレビ会議端末１は、多地点テレビ会議制御装置２１からＢＡＳを受信すると、システム制御部２がそれをマルチメデイア多重・分離部５から読み込み、それが切りだし領域の通知かどうかをチェックする（判断１００１）。
【００５８】
図１０にその場合のＢＡＳコマンドの例を示す。同図において、最初のデータはＭＢＥの開始を示すＨ．２２１に規定されたデータ（コマンド：０ｘＦ９）、続いてデータのバイト数（５ｂｙｔｅ）、データが切りだし領域通知であることを示す識別子（０ｘ１Ｄ）、切りだし領域を示すデータとなっている。切りだし領域を示すデータは、４角形の４頂点のうちの１つ（左上の頂点）を切り出し開始位置としてそのｘ座標及びｙ座標をマクロブロック（ＭＢ）単位で指定するためのデータと４角形の大きさをｘ座標及びｙ座標方向のマクロブロック（ＭＢ）単位の長さで指定するためのデータにより構成されている。
【００５９】
さて、図９の手順において、受信したＢＡＳが切りだし領域の通知であると（判断１００１のＹｅｓ）、システム制御部２は、動きベクトル情報の付加領域を判定する（処理１００２）。
【００６０】
設定する付加領域は、
（１）切りだし領域より１ＭＢ分画像の内側の領域を動きベクトル付加領域とする。
（２）ただし、切りだし領域が画像領域の縁面に接する場合には、その辺については切りだし領域と同一とする。
の２点の法則に従って判定する。
【００６１】
図１１に画像切りだし領域と動きベクトル付加領域の関係について示す。切り出し領域の辺縁のマクロブロックは、その動きベクトルを求めるために切り出し領域外を参照する場合があるため、多地点テレビ会議制御装置２１において、動きベクトルの復号化を保証するために、同図（ａ）に示すように、動きベクトルの付加領域は、切り出し領域の１マクロブロック幅分の辺縁を除外した領域としている。これより、多地点テレビ会議制御装置２１においては、テレビ会議端末で付加された動きベクトルを確実に復号化できる（上記（１）の場合）。
【００６２】
また、同図（ｂ）、（ｃ）及び（ｄ）の例が、上述した（２）の場合にあたり、切り出し領域のいずれかの辺が、元の画像のいずれかの辺と接する場合は、その接する部分のマクロブロックには、元々動きベクトルは付加されていないため、その接する部分のマクロブロックは、動きベクトル付加領域とはしない。
【００６３】
さて、図９の手順において、処理１００２により上記したように動きベクトル付加領域を判定したシステム制御部２は、判定した動きベクトル付加領域を動画符号・復号化部１３に設定する（処理１００３）。
【００６４】
これにより、アレイプロセッサにより画像切り出しを伴う画像合成を行う際にも、動きベクトル情報を使用して画質の向上を図ることができる。
【００６５】
次に、第２実施形態について説明する。本実施形態では、多地点テレビ会議制御装置２１で行われる画像合成の方式をテレビ会議端末へ通知し、テレビ会議端末は、通知された方式に基づいて符号化された動画データに所定量の無効情報を付加して送信する。
【００６６】
切り出し領域の通知は、通信の開始時及び音声・動画マルチプレクス部３０での合成方式の変更時に、Ｈ．２２１上のＢＡＳコマンド（ＭＢＥ）を用いて通知する（合成を行わない場合にも通知は行う）。そのため、第２実施形態では、図５に示した能力交換の際にＭＢＥ能力有りとして能力交換を行う。（他の方法としてＭＬＰ上のプロトコルを用いても良い。）
【００６７】
第２実施形態の処理手順について、図１２を参照して説明する。同図において、、テレビ会議端末１は、ＢＡＳを受信すると、システム制御部２がそれをマルチメディア多重・分離部５から読み込み、それが合成方式の通知かどうかをチェックする（判断２００１）。
【００６８】
図１３に、その場合のＢＡＳコマンドの例を示す。同図において、最初のデータはＭＢＥの開始を示すＨ．２２１に規定されたデータ（コマンド）、続いてデータのバイト数、データが合成方式通知であることを示す識別子、合成方式を示すデータとなっている。
【００６９】
さて、図１２に示す手順において、受信したＢＡＳが合成方式の通知であると（判断２００１のＹｅｓ）、システム制御部２は、あらかじめ記憶されている図１４に示すような、合成方法に対応した評価値Ｑを判定する（処理２００３）。そして、システム制御部２は、判定して得た評価値から付加すべき無効情報量Ｉｉｎｖを算出する（処理２００３）。
【００７０】
無効情報量Ｉｉｎｖは、動画の送信伝送帯域をＢｔｘ、受信伝送帯域をＢｒｘ、評価値をＱとし、以下の式１で示される。
Ｉｉｎｖ＝Ｂｔｘ−（Ｂｒｘ×Ｑ）／１００ −（式１）
【００７１】
なお、図１４において、トランスコーダでの評価値が８０となっているのは、トランスコードの際の縮小または／及び切りだしの際の画像の高周波成分の増加に伴ってフレームレートが落ちてしまわないように、あらかじめ端末からの送信時に情報量を削減してしまうような動作を想定している。また、マルチプレクでの評価値は、４つのソース画像がマルチプレクスで処理される場合を想定している。
【００７２】
さて、システム制御部２は、算出した無効情報量Ｉｉｎｖを動画符号化・復号化部１３に設定する（処理２００４）。動画符号化・復号化部１３における無効情報の付加の方法には、ＩＴＵ−Ｔ勧告Ｈ．２６１で規定されている２つの方法（マクロブロックフィル／フィルビット挿入）のうちの、何れかあるいは両方を使用する。
【００７３】
以上の手順により、多地点テレビ会議制御装置２１における画像合成方式に応じて、多地点テレビ会議制御装置２１の動画送信バッファ２７がオーバーフローしないように、テレビ会議端末１側で本来の動画データに付加する無効情報を適応的に増減させるため、多地点テレビ会議制御装置２１における動画送信バッファのオーバーフロー回避することができる。
【００７４】
次に第３実施形態について説明する。本実施形態では、アレイプロセッサ（あるいはマルチプレクス）により画像合成が行われている際に、動画の送信バッファのオーバーフローを避ける為に図１５に示す手順の処理を行う。
【００７５】
同図において、通信中、アレイプロセッサ（あるいはマルチプレクス）によって画像合成が開始されると、多地点テレビ会議制御装置のシステム制御部２２は、各通信チャネルの動画送信バッファ２７の蓄積量を監視する（処理３００１、判断３００２のＮｏループ）。
【００７６】
所定量以上の蓄積量が検出されると（判断３００２のＹｅｓ）、システム制御部２２は、画像合成のソースとなっている通信チャネルの動画受信バッファ２９を検索する（処理３００３）。ＩＮＴＲＡモード（フレーム内での符号化処理）で符号化されているマクロブロック（ＭＢ）を検出すると（判断３００４のＹｅｓ）、システム制御部２２は、そのＭＢの合成後の画像位置を求め、処理３００１で検出した動画送信バッファ２７から、同じ画像位置の動画データを削除する（処理３００５）。
【００７７】
システム制御部２２は、以上の処理３００３〜３００５までの処理を、ソースとなっている全通信チヤネルに対して繰り返し行う（判断３００６のＮｏループ）。さらに、システム制御部２２は、判断３００２で検出した動画送信バッファ２７の蓄積量を確認し（判断３００７）、改善されていなければ（判断３００７のＮｏ）（まだ蓄積量が所定量以上であったら）従来のバツファオーバーフロ一のエラー処理（例えば、動画送信バッファ２７をクリアし、ソースとなっている全通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する）を行う（処理３００８）。
【００７８】
これにより、多地点テレビ会議制御装置２１でアレイプロセッサにより画像合成を行う際に、送信バッファの蓄積量が所定量以上になると、受信バッファからＩＮＴＲＡ−ＭＢのデータを検索し、合成画像上の同位置のデータが送信バッファから削除されるため、動画送信バッファ２７のオーバーフローを回避することができる。
【００７９】
次に、第４実施形態について説明する。本実施形態では、アレイプロセッサにより画像合成が行われている際に、テレビ会議端末からのＶＣＵコマンドを受信すると、そのレスポンスとして図１６に示す手順の処理を行う。
【００８０】
同図において、通信中、アレイプロセッサによって画像合成が開始されると、多地点テレビ会議制御装置２１のシステム制御部２２は、画像合成された動画を送信している各通信チャネルのマルチメディア多重分離部２４のＣ＆Ｉ符号（ＩＴＵ−Ｔ勧告Ｈ．２３０参照：ＶＣＵコマンドはＣ＆Ｉ符号の一つである）を読み出し、監視する（処理４００１及び判断４００２のＮｏループ）。
【００８１】
ＶＣＵコマンドが検出されると（判断４００２のＹｅｓ）、システム制御部２２は、画像合成のソースとなっている全通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する（全通信チャネルのマルチメデイア多重・分離部２４にＶＣＵコマンドのＣ＆Ｉ符号を書き込む）（処理４００３）。
【００８２】
さらにシステム制御部２２は、アレイプロセッサ部１０４に記憶画像データの送信を指示して、アレイプロセッサ部１０４は、あらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている画像データ（このデータは１フレーム分の画像データで、ＩＮＴＲＡモードで符号化されている）を出力すると共に、画像合成の処理を停止する（処理４００４）。その後、システム制御部２２は画像合成のソースとなっていた全通信チャネルの動画データを監視し（処理４００５、判断４００６のＮｏループ）、ＩＮＴＲＡフレームを検出すると（判断４００６のＹｅｓ）、その通信チャネルの画像合成を再開する（処理４００７）。
【００８３】
以上の処理４００５ないし４００７の処理を、画像合成のソースとなっていた全通信チャネルの画像合成が再開されるまで繰り返す（判断４００８のＮｏループ）。
【００８４】
以上の処理中における、テレビ会議端末側での画像の変化を、図１７に示す。同図において、（Ａ）は上述した図１６に示す手順における処理４００４での画像、（Ｂ）は処理４００５ないし４００７で一部の通信チャネルの画像合成が再開されている画像、（Ｃ）は全ての画像合成が再開されている画像（ＥＮＤ）を示している。
【００８５】
これにより、多地点テレビ会議制御装置２１がテレビ会議端末からＶＣＵコマンドを受信した場合には、他のテレビ会議端末にＶＣＵコマンドを発行すると共に、一旦あらかじめ記憶されているＩＮＴＲＡフレームの画像データを送信するため、多地点テレビ会議制御装置２１において合成される画像間の遅延差の発生を回避することができる。まは、テレビ会議端末における、画像のロックあるいは画像乱れを回避することができる。
【００８６】
次に、第５実施形態について説明する。本実施形態では、アレイプロセッサにより画像合成が行われている際に、そのソースとなっている通信チャネルで伝送エラーを検出した際に、そのレスポンスとして図１８に示す手順の処理を行う。
【００８７】
同図において、通信中、アレイプロセッサによって画像合成が開始されると、多地点テレビ会議制御装置２１のシステム制御部２２は、画像合成のソースとなっている各通信チャネルの動画エラー訂正・検出部２８のエラー情報を読み出し、監視する（処理５００１、判断５００２のＮｏループ）。訂正不能な伝送エラーが検出されると（判断５００２のＹｅｓ）、システム制御部２２は、エラーを検出した通信チャネル（テレビ会議端末）に対してＶＣＵコマンドを発行する（通信チャネルのマルチメデイア多重・分離部２４にＶＣＵコマンドのＣ＆Ｉ符号を書き込む）（処理５００３）。
【００８８】
さらにシステム制御部２２は、アレイプロセッサ部１０４に記憶画像データの合成を指示して、アレイプロセッサ部１０４は、あらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている画像データ（このデータは１フレーム分の画像データで、ＩＮＴＲＡモードで符号化されている）をエラーを検出した通信チャネルの画像データとして画像合成を行う（処理５００４）。その後、システム制御部２２はエラーを検出した通信チヤネルの動画データを監視し（処理５００５、判断５００５のＮｏループ）、ＩＮＴＲＡフレームを検出すると（判断５００６のＹｅｓ）、その通信チャネルから受信したデータによる画像合成を再開する（処理５００７）。
【００８９】
以上の処理中における、テレビ会議端末側での画像の変化を、図１９に示す。同図において、（Ａ）は上述した処理５００４での画像、（Ｂ）は、処理５００７において受信したデータによる画像合成が再開されている画像（ＥＮＤ）を示している。
【００９０】
これにより、多地点テレビ会議制御装置２１がテレビ会議端末からの動画データに伝送エラーを検出した場合には、テレビ会議端末にＶＣＵコマンドを発行すると共に、一旦あらかじめ記憶されているＩＮＴＲＡフレームの画像データを合成するため、テレビ会議端末における、画像乱れを回避することができる、また、テレビ会議端末において、ユーザーに画像更新中であることを明示することができる。
【００９１】
第５実施形態は、上記した利点を有するが、あるテレビ会議端末からの受信動画データにエラーが発すると、多地点テレビ会議制御装置２１が、あらかじめ記憶してある符号化された画像データを、エラーを検出した受信動画データの代わりに伝送する場合に、その画像データのサイズが一定であると（１つのテレビ会議端末に割り当てられている（帯域／フレームレート）以上であると）伝送バッファがオーバーフローしてしまう（アレイプロセッサでは、フレームレートを落とす（フレームスキップにより情報を削減する）ことができないため）。
【００９２】
その問題を解決する、第６実施形態にいつて以下説明する。本実施形態では、第５実施形態に係る図１８に示した処理手順における処理５００４で使用する画像データとして、それぞれデータ長の異なる複数の画像データを持ち、動画送信の伝送レートと合成数に従って適宜選択して使用する。
【００９３】
図２０に記憶画像データのデータ長の例を示す。多地点テレビ会議制御装置２１のアレイプロセッサ部１０４には図２０に示すような複数のデータ長の画像データが、画像データ番号に対応してあらかじめ同部の中の不揮発性メモリ（ＲＯＭ等）に記憶されている。なお、これらの画像データは内容は同一のもので、符号化における圧縮率が異なる（精細度が異なる）ものである。
【００９４】
システム制御部２２は、図１８に示す処理５００４においてアレイプロセッサ部１０４に記憶画像データの合成を指示する際に、（動画送信に割り当てられている帯域／合成数（画像合成のソースの数））を算出し、それを基に、あらかじめシステム制御部２２内に記憶されている図２０に示すテーブルを参照して、使用する画像データ番号を決定してアレイプロセッサ部１０４に通知する。アレイプロセッサ部１０４は、通知された画像データ番号に従って、画像データを合成し出力する。
【００９５】
なお、第６実施形態では、フレームレートが１５ｆｐｓ固定の場合について示したが、フレームレートもオーバーフローの要因となるため、これに適応する複数の画像データを持つ事も有効である。同一内容で圧縮率の異なる複数の画像データを記憶している例について示したが、画像内容そのものを異なるものとし、同一の圧縮率でデータ長の異なるものを記憶しておいても良い。
【００９６】
【発明の効果】
請求項１に係る発明によれば、多地点テレビ会議制御装置において符号化されたままの動画情報を、画像切り出しを伴って画像合成を行う際には、画像の切りだし領域を各テレビ会議端末通知し、各テレビ会議端末では、通知された画像の切りだし領域に基づいて動きベクトルの付加領域を設定し、その付加領域にのみ動くベクトル情報を付加するため、符号化されたままの動画情報を、画像切り出しを伴って画像合成を行う際にも動きベクトル情報を使用して画質の向上を計ることができる。また、いわゆるアレイプロセッサにより画像切りだしを伴う画像合成とスイッチングサービスとを併用して運用することができる利点もある。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るテレビ会議システムの構成を示す図である。
【図２】本発明の実施の形態に係るテレビ会議端末のブロック構成を示す図である。
【図３】本発明の実施の形態に係る多地点地点テレビ会議制御装置のブロック構成を示す図である。
【図４】本発明の実施の形態に係る多地点地点テレビ会議制御装置のの音声・動画マルチプレクス部３０の構成を示している。
【図５】本発明の実施の形態に係るテレビ会議システムの基本的な動作を示す図である。
【図６】各通信チャネルへ出力される音声及び動画データの例を示す図である。
【図７】音声ミキシング部での各通信チャネル別の重み付けの合成形態（比率）の例を示す図である。
【図８】アレイプロセッサ部での画像合成形態及び、画像切り出しを伴うアレイプロセッサ部での処理の一例を示す図である。
【図９】本発明に係るテレビ会議システムにおける第１実施形態の処理手順を示すフローチャートである。
【図１０】第１実施形態に係る処理手順におけるＢＡＳコマンドの一例を示す図である。
【図１１】第１実施形態に係る画像切りだし領域と動きベクトル付加領域の関係について示す図である。
【図１２】本発明に係るテレビ会議システムにおける第２実施形態の処理手順を示すフローチャートである。
【図１３】第２実施形態に係る処理手順におけるＢＡＳコマンドの一例を示す図である。
【図１４】第２実施形態に係る処理手順における合成方法と評価値との対応例を示す図である。
【図１５】本発明に係るテレビ会議システムにおける第３実施形態の処理手順を示すフローチャートである。
【図１６】本発明に係るテレビ会議システムにおける第４実施形態の処理手順を示すフローチャートである。
【図１７】第４実施形態に係る処理手順におけるテレビ会議端末側での画像の変化を示す図である。
【図１８】本発明に係るテレビ会議システムにおける第５実施形態の処理手順を示すフローチャートである。
【図１９】第４実施形態に係る処理手順におけるテレビ会議端末側での画像の変化を示す図である。
【図２０】第５実施形態に係る記憶画像データのデータ長の一例を示す図である。
【符号の説明】
１、１９、２０ テレビ会議端末
２ システム制御部
３ 磁気ディスク装置
４ ＩＳＤＮインターフェイス部
５ マルチメデイア多重・分離部
６ マイク
７ 音声入力処理部
８ 音声符号・復号化部
９ 音声出力処理部
１０ スピーカ
１１ ビデオカメラ
１２ 映像入力処理部
１３ 動画符号化・復号化部
１４ 映像出力処理部
１５ モニター
１６ ユーザーインターフェイス制御部
１７ コンソール
１８、３１ ＩＳＤＮ回線
２２ システム制御部
２３ ＩＳＤＮインターフェイス部
２４ マルチメデイア多重・分離部
２５ 音声符号・復号化部
２６ 動画訂正符号生成部
２７ 動画送信バッファ
２８ 動画エラー訂正・検出部
２９ 動画データ受信バッファ
３０ 音声・動画マルチプレクス部
１０１ 話者検出部
１０２ 音声ミキシング部
１０３ 音声切替部
１０４ アレイプロセッサ部
１０５ 動画切替部
Claims (1)
- 複数の地点に設けられたテレビ会議端末を多地点テレビ会議制御装置に接続し、前記各テレビ会議端末から多地点テレビ会議制御装置に符号化された動画情報を伝送するとともに、前記多地点テレビ会議制御装置が前記各テレビ会議端末からの動画情報の一部を切り出して得た切り出し領域を合成し、その合成動画情報を各テレビ会議端末へ送信する多地点テレビ会議システムにおいて、
前記多地点テレビ会議制御装置は、前記切り出し領域を前記各テレビ会議端末へ通知する手段を備える一方、
前記各テレビ会議端末は、前記多地点テレビ会議制御装置から通知された前記切り出し領域に基づいて動きベクトル情報の付加領域を設定する手段と、その設定された付加領域にのみ動きベクトル情報を付加して前記多地点テレビ会議制御装置に送信する手段とを備えたことを特徴とする多地点テレビ会議システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP07931496A JP3554999B2 (ja) | 1996-03-08 | 1996-03-08 | 多地点テレビ会議システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP07931496A JP3554999B2 (ja) | 1996-03-08 | 1996-03-08 | 多地点テレビ会議システム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003370539A Division JP3913726B2 (ja) | 2003-10-30 | 2003-10-30 | 多地点テレビ会議制御装置及び多地点テレビ会議システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09247643A JPH09247643A (ja) | 1997-09-19 |
| JP3554999B2 true JP3554999B2 (ja) | 2004-08-18 |
Family
ID=13686410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP07931496A Expired - Fee Related JP3554999B2 (ja) | 1996-03-08 | 1996-03-08 | 多地点テレビ会議システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3554999B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11341471A (ja) | 1998-05-28 | 1999-12-10 | Hitachi Ltd | 映像配信装置および映像配信システム |
| WO2005004450A1 (en) | 2003-06-19 | 2005-01-13 | Sony Ericsson Mobile Communications Ab | Media stream mixing |
| US8917985B2 (en) | 2007-08-29 | 2014-12-23 | Nintendo Co., Ltd. | Imaging apparatus |
| CN112511768B (zh) * | 2020-11-27 | 2024-01-02 | 上海网达软件股份有限公司 | 多画面合成方法、装置、设备及存储介质 |
-
1996
- 1996-03-08 JP JP07931496A patent/JP3554999B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09247643A (ja) | 1997-09-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5623312A (en) | Compressed-domain bit rate reduction system | |
| JP3431373B2 (ja) | マルチメディア通信システムのための符号化領域画像複合化 | |
| US5687095A (en) | Video transmission rate matching for multimedia communication systems | |
| EP0771120B1 (en) | Video encoding apparatus | |
| US8848790B2 (en) | Encoding processing apparatus and method for a moving image | |
| KR20040036936A (ko) | 화상 음성 복호화 장치와 화상 음성 부호화 장치 및 정보전송 시스템 | |
| US20050195275A1 (en) | Arrangement and method for generating CP images | |
| US6313863B1 (en) | Image communication apparatus and system | |
| JPH11234644A (ja) | 多地点会議システム | |
| US20040005002A1 (en) | Mobile terminal with camera | |
| JPH11220711A (ja) | 多地点会議システム及び会議端末装置 | |
| JP3554999B2 (ja) | 多地点テレビ会議システム | |
| JP3913726B2 (ja) | 多地点テレビ会議制御装置及び多地点テレビ会議システム | |
| JPH07203434A (ja) | 画像送信装置 | |
| JPH0884331A (ja) | 画像通信装置およびその画像通信方法 | |
| JP2002125227A (ja) | 画像情報変換装置及び方法 | |
| JP3927606B2 (ja) | 画像通信装置及びシステム、並びに画像受信装置及び受信画像データの処理方法 | |
| JPH07298231A (ja) | 多地点動画像通信システム、その制御装置及び動画像通信端末 | |
| JPH10108160A (ja) | データ配信システム | |
| JPH0884329A (ja) | 画像通信端末装置 | |
| JP4196085B2 (ja) | 映像信号符号化装置およびそれを用いたテレビ会議システム | |
| JP2007166479A (ja) | 動画像表示装置および動画像表示方法 | |
| JP2001346214A (ja) | 画像情報変換装置及び方法 | |
| JPH0918846A (ja) | 多地点間通信装置 | |
| JPH09247644A (ja) | 多地点制御装置およびテレビ会議通信端末装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20040427 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040427 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080521 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090521 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100521 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110521 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120521 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130521 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130521 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |