JP4952581B2 - 多地点会議システム、多地点会議方法及びプログラム - Google Patents

Description

本発明は、多地点会議システム、多地点会議方法及びプログラムに関し、特に、複数の映像データを終端し、端末に映像ストリームを送信する所謂多地点テレビ会議システム、これに用いる機器、プログラム及び多地点テレビ会議方法に関する。

特開２００２−２９０９４０号公報（特許文献１）に、ネットワーク上にサーバを置き、該サーバが各端末から送信された映像ストリームを一旦受信し、該サーバが全端末に映像データをストリーミング配信するテレビ会議システムが紹介されている。この方式では、サーバはすべての端末からそれぞれ映像データを受信し、各端末に配信する。各端末は受信した複数の映像ストリームをデコードし、等分割画面結合表示、発言者アップ等の所定のテレビ会議用表示形式で表示する。

また、前記したネットワーク上のサーバ側で、各端末から受信したすべての映像データをデコードし、必要な画像処理を行った後でエンコードし、各端末からの要求に応じた映像ストリームのみを送信する方式も知られている。この方式によれば、サーバ側で端末の性能に合わせて映像ストリームを加工可能であるため、符号化方式、符号化設定、オプション等を任意に設定できるという利点がある。
特開２００２−２９０９４０号公報

しかしながら、ネットワーク上のサーバ側が必要な映像ストリームだけを送信するという後者の方式にも、実際には要求された映像ストリームしか必要としないにも拘らず、すべての映像ストリームを用意（デコード等）しておかねばならないという問題点がある。計算リソースの増大は、１サーバあたりの処理チャネル数の制約等となって表れるため好ましいものでないが、映像ストリームには時間方向の圧縮が掛かっているため、切替要求が行われたとしても任意の地点（箇所）からデコードを開始することができないという事情が存在する。

従って本発明は、端末からの映像ストリームの切替要求に迅速に対応でき、かつ計算量の少ない多地点会議システム、多地点会議方法及びプログラムを提供することをその目的とする。

本発明の第１の視点によれば、映像ストリームを送信する複数の端末と接続され、前記各端末から要求された映像ストリームをエンコードし前記各端末に送信する多地点会議サーバであって、前記各端末に送信する分の映像ストリームのみをデコードし、その他の切り替え候補の映像ストリームはバッファしておき、切替要求があった場合に過去に遡ってデコードする多地点会議サーバが提供される。前記多地点会議サーバは、各端末に送信する分の映像ストリームのみをデコードするデコーダと、送信対象外の映像ストリームをデコードせずに蓄積するバッファと、前記端末からの映像ストリームの切り替え要求に応じて、前記バッファに蓄積した映像ストリームを選択し所定時間分過去に遡ってデコードし、該端末に送信する映像ストリームを切り替える切替制御部と、を備えて構成される。

また、本発明の第２の視点によれば、前記多地点会議サーバを構成するコンピュータに実行させるプログラムと、前記多地点会議サーバと端末群を接続して構成可能な多地点会議システムが提供される。

また、本発明の第３の視点によれば、前記した多地点会議サーバを用いて実施する多地点会議方法であって、（ａ）前記多地点会議サーバが、前記各端末に送信する分の映像ストリームのみをデコードするステップと、（ｂ）前記多地点会議サーバが、送信対象外の映像ストリームをデコードせずにバッファに蓄積するステップと、（ｃ）前記多地点会議サーバが、前記端末からの映像ストリームの切り替え要求に応じて、前記バッファに蓄積した映像ストリームを選択し所定時間分過去に遡ってデコードし、該端末に送信する映像ストリームを切り替えるステップと、を含むこと、を特徴とする多地点会議方法が提供される。

本発明によれば、端末からの切替要求への応答性を損なわずに、多地点会議サーバとして使用されるサーバの計算リソースを抑えることが可能となる。また、映像ストリームに時間方向の圧縮が掛かっていることを考慮した切替処理を行うため、画質の劣化は生じないものとなっている。

続いて、本発明を実施するための最良の形態について図面を参照して詳細に説明する。図１は、本発明の一実施の形態に係る多地点会議システムの概略構成を表した図である。図１を参照すると、ｎ台（以下、ｎは２以上の整数を表す）の端末１０１〜１０ｎと、多地点会議サーバ（以下、単にサーバという）２００とをネットワーク５００を介して接続してなる多地点会議システムが示されている。

図２は、上記多地点会議システムにおける各端末とサーバ２００間の接続を表した図である。図２に例示された端末１０１は、ネットワーク５００を介して、サーバ２００の映像受信部２１０、制御信号受信部２２０、映像送信部２９０と、それぞれ通信を行い、所定の制御信号の送受信とともに、映像ストリーミングの送信、受信を実行する。

図３は、上記多地点会議システムにおけるサーバ２００にｎ台の端末が接続している際の詳細構成を表した図である。サーバ２００は、制御信号受信部２２０、制御部２５０のほか、ｎ台の端末に対応すべく、ｎ組の映像受信部２１１〜２１ｎ、バッファ２３１〜２３ｎ、デコーダ２４１〜２４ｎ、選択・合成部２６１〜２６ｎ、リサイズ部２７１〜２７ｎ、エンコーダ２８１〜２８ｎ、（映像）送信部２９１〜２９ｎにより、端末１０１〜１０ｎとそれぞれ通信可能となっている。

制御信号受信部２２０は、端末１０１〜１０ｎから制御信号を受信し、制御部２５０に伝える手段であり、制御部２５０は、サーバ２００全体の制御のほか、制御信号に基づいて各端末１０１〜１０ｎに配信すべき映像ストリームを決定し、デコーダ２４１〜２４ｎを含む各ユニットに指令を与える手段である。

映像受信部２１１〜２１ｎは、ネットワーク５００を介して端末１０１〜１０ｎから映像ストリームを含んだパケットを受信する手段である。また、バッファ２３１〜２３ｎは、サーバ２００のメモリに構築された映像ストリームの一時的な格納先である。

デコーダ２４１〜２４ｎは、映像ストリームをデコードし、画像を作成する手段であり、後記するように、各端末から受信した映像ストリームが現在デコード対象であるか否かをアクティブ／非アクティブで表すフラグを有している。

選択・合成部２６１〜２６ｎは、制御部２５０の指示に従い、デコーダ２４１〜２４ｎから出力される画像を選択し、あるいは、デコーダ２４１〜２４ｎからの画像を複数選択し結合する手段である。また、リサイズ部２７１〜２７ｎは、選択・合成部２６１〜２６ｎから出力された画像について、各端末１０１〜１０ｎに適合するサイズに拡大・縮小するための手段である。

エンコーダ２８１〜２８ｎは、各端末１０１〜１０ｎに適合する符号化方式、符号化設定、パラメータで画像をエンコードし、映像ストリームに変換する手段である。また、（映像）送信部２９１〜２９ｎは、エンコーダ２８１〜２８ｎで作成された映像ストリームを、ネットワーク５００を介して、それぞれ対応付けられた端末１０１〜１０ｎに送信する手段である。

また、本発明の理解を助けるため図示省略したが、多地点会議サーバ２００には、音声ストリームを扱う各処理手段が備えられている。

続いて、図３を用いてサーバ２００の動作の概要を説明する。各端末１０１〜１０ｎが、それぞれ映像ストリームをパケットとしてサーバ２００に送信すると、サーバ２００の映像受信部２１１〜２１ｎがそれぞれ個別に各端末からのパケットを受信・解析し、映像ストリームを取り出す。

受信したストリームのすべてを使用する（受信したストリームのすべてがいずれかへの端末への送信対象である）と仮定すると、バッファ２３１〜２３ｎは使用されず、デコーダ２４１〜２４ｎにてそれぞれ個別にデコードされ、１〜ｎ個の画像が作成される。

そして、選択・合成部２６１〜２６ｎは、制御部２５０の指示に従って画像を選択・合成し、エンコーダ２８１〜２８ｎが各端末用にエンコード処理を行う。エンコードにより作成された映像ストリームはパケット化され、（映像）送信部２９１〜２９ｎにより端末１０１〜１０ｎへ個別に送信される。

そして、端末１０１〜１０ｎは、サーバ２００の制御信号受信部２２０に対し制御信号を送り、サーバ２００に要求を伝達し、サーバ２００から受信する映像ストリームを切り替えることができる。

本発明の効果が顕著に現れる、受信したストリームのすべてが送信対象でない場合の動作は、以下のとおりとなる。サーバ２００の映像受信部２１１〜２１ｎがそれぞれ個別に各端末からのパケットを受信・解析し、映像ストリームを取り出すまでは上記したケースと同様である。

続いて、デコーダ２４１〜２４ｎのフラグが参照される。ここで、デコーダ２４１〜２４ｎのフラグがアクティブ（デコード対象）である場合には、上記したケースと同様デコードされる。一方、デコーダ２４１〜２４ｎのフラグが非アクティブ（デコード対象外）である場合には、一旦バッファ２３１〜２３ｎに格納する処理が行われる。

図４は、非アクティブ（デコード対象外）状態の時に制御部２５０からアクティブ化の指令を受けた際のデコーダ２４１〜２４ｎの動作を表したフローチャートである。アクティブ化の指令を受けたデコーダ２４１〜２４ｎは、バッファ２３１〜２３ｎに映像ストリームが格納されているかを確認する（ステップＳ００１）。

ここで、バッファ２３１〜２３ｎに映像ストリームが格納されている場合、デコーダ２４１〜２４ｎは、格納されたデータ（ストリームデータ）をデコードする（ステップＳ００３）。なお後記するように、バッファ２３１〜２３ｎには必ずイントラフレーム（フレーム内符号化されたフレーム；以下、Ｉフレームという）から格納されているため、Ｉフレームからデコードを行うことになる。

デコードを行った分のデータは、バッファから削除され、まだバッファ２３１〜２３ｎにデータが格納されている場合は、上記ステップＳ００１、Ｓ００２が繰り返される。この間、デコーダ２４１〜２４ｎは時間情報を無視して、バッファ２３１〜２３ｎに格納されているストリームを一気にデコードする。デコードにより生成される複数の画像のうち最新の画像が選択合成部２６１〜２６ｎにより利用される。

一方、バッファ２３１〜２３ｎが空になったら（ステップＳ００１のＮ）、デコーダ２４１〜２４ｎはフラグをアクティブ（デコード対象）にしたデコード状態に遷移する（ステップＳ００２）。

図５は、アクティブ（デコード対象）状態の時に制御部２５０から非アクティブ化の指令を受けた際のデコーダ２４１〜２４ｎの動作を表したフローチャートである。非アクティブ化の指令を受けたデコーダ２４１〜２４ｎは、直ちにデコードを停止するのではなく、指令後、映像受信部が受信したデータによって挙動を決定する。

ステップＳ１０１で受信したパケットの映像ストリームがＩフレームのデータでない場合は（ステップＳ１０２のＮ）、デコーダ２４１〜２４ｎは、上記アクティブ（デコード対象）状態と同様にデコードを行う（ステップＳ１０３）。

一方、受信したパケットの映像ストリームがＩフレームのデータであった場合は（ステップＳ１０２のＹ）、デコーダ２４１〜２４ｎは、当該データをデコードせずに、バッファ２３１〜２３ｎに格納する（ステップＳ１０４）。

Ｉフレームはデータサイズが大きくなるため、複数のパケットに分割されていることがある。そこで、デコーダ２４１〜２４ｎは、受信したデータがＩフレームの最後のデータであるか否かを確認し（ステップＳ１０５）、格納したデータがＩフレームの最後のデータでない場合は、ステップＳ１０１に戻って、Ｉフレームの分割された後続データを受信する。

一方、受信したデータがＩフレームの最後のデータであった場合は（ステップＳ１０５のＹ）、デコーダ２４１〜２４ｎは、デコード処理を停止し、フラグを非アクティブ（デコード対象外）にした非デコード状態に遷移する（ステップＳ１０６）。

このように、バッファ２３１〜２３ｎは、それぞれ必ずＩフレームの先頭から格納するよう、そして、新しくＩフレームのデータを格納する場合は以前のデータを削除するよう制御される。

図６は、上述した手順によって実現されるバッファ２３１〜２３ｎにおけるフレーム格納制御を説明するための図である。図６の左側２３ｘ＿Ｔ０〜２３ｘ＿Ｔ５は、同一のバッファ２３ｘを時間の流れ（Ｔ０〜Ｔ５）に従い内部の状態の変化を表したものである。図６の右側Ｐ＿Ｔ０〜Ｐ＿Ｔ４は、各時点で到達した映像ストリームのデータを表しており、Ｉｘ（ｘは到達順序）は、Ｉフレームのストリームデータを表し、Ｐｘ（ｘは到達順序）は、Ｉフレーム以外のストリームデータを表している。

図６の２３ｘ＿Ｔ０の状態では、バッファは空であり、そこにＩフレームでないデータＰ＿Ｔ０が到達するが、バッファ２３１〜２３ｎには、必ずＩフレームから格納するという制御が行われるため、この場合、データＰ＿Ｔ０は破棄される。

図６の２３ｘ＿Ｔ１の状態では、前時点同様バッファは空であり、そこにＩフレームのデータＰ＿Ｔ１が到達すると、データＰ＿Ｔ１は格納されて２３ｘ＿Ｔ２の状態になる。図６の２３ｘ＿Ｔ２の状態で、さらに、データＰ＿Ｔ２が到達すると、既にＩフレームのデータＰ＿Ｔ１が格納されているため、データＰ＿Ｔ２も続けて格納され、２３ｘ＿Ｔ３の状態になる。図６の２３ｘ＿Ｔ３の状態で、さらに、データＰ＿Ｔ３が到達すると、同様にしてデータＰ＿Ｔ３も続けて格納され、図６の２３ｘ＿Ｔ４の状態になる。

図６の２３ｘ＿Ｔ４の状態では、新しいＩフレームであるデータＰ＿Ｔ４が到達すると、それ以前のデータはすべて破棄され、データＰ＿Ｔ４が先頭に格納されて２３ｘ＿Ｔ５の状態になる。

上述したようにＩフレームはデータサイズが大きくなるため、複数のパケットに分割されていることがある。図７は、複数のパケットに分割されたＩフレームが到達した場合におけるフレーム格納制御を説明するための図である。図７の左側２３ｘ＿Ｔ１０〜２３ｘ＿Ｔ１３は、同一のバッファ２３ｘを時間の流れ（Ｔ１０〜Ｔ１３）に従い内部の状態の変化を表したものである。図７の右側Ｐ＿Ｔ１０〜Ｐ＿Ｔ１２は、各時点で到達した映像ストリームのデータを表しており、Ｉｘｙ（ｘは到達順序、ｙは分割番号）は、Ｉフレームのストリームデータを表し、Ｐｘは、Ｉフレーム以外のデータを表している。

図７の２３ｘ＿Ｔ１０の状態で、到達したデータＰ１＿Ｔ１０、Ｐ２＿Ｔ１０は、前後２つに分割されたＩフレームのデータ（Ｉ２ａ、Ｉ２ｂ）である。まず、前半部分であるデータＰ１＿Ｔ１０がバッファに格納されるが、この段階では新規のＩフレーム到達による既存データの破棄は行われずに、２３ｘ＿Ｔ１１の状態になる。そして、図７の２３ｘ＿Ｔ１１の状態からさらに、後半部分であるデータＰ＿Ｔ１１をバッファに格納する時点で新規のＩフレームのデータ（Ｉ２ａ、Ｉ２ｂ）以前のデータはすべて破棄され、２３ｘ＿Ｔ１２の状態になる。

そして、図７の２３ｘ＿Ｔ１２の状態からは、既に説明したとおり、非ＩフレームのデータＰ＿Ｔ１２が到達すると続けて格納され、２３ｘ＿Ｔ１３の状態になる。

再度、図３を参照して、上記デコーダ２４１〜２４ｎによってデコードが行われた後の動作を説明する。選択合成部２６１〜２６ｎは、制御部２５０の指示に基づいて、デコーダ２４１〜２４ｎからデコードされた画像を取得する。

続いて、選択合成部２６１〜２６ｎは、端末１０１〜１０ｎ側の設定に応じて、複数の画像を上下左右に結合する処理（合成処理）を行う。更に、取得ないし合成した画像サイズと、端末１０１〜１０ｎに送信する映像ストリームのサイズが異なっている場合、制御部２５０の指示に基づき、リサイズ部２７１〜２７ｎが画像の拡大・縮小処理を行う。

続いて、エンコーダ２８１〜２８ｎが、送信先の端末１０１〜１０ｎにあったビットレート、パラメータで画像をエンコードし、映像ストリームに変換する。

更に、（映像）送信部２９１〜２９ｎが、変換された映像ストリームをパケット化し、ネットワーク５００を介して、端末１０１〜１０ｎに送信する。

以上のとおり、本実施の形態によれば、端末台数ｎより少ないｍ本（１＜ｍ≦ｎ）の映像ストリームのデコードで済み、サーバにおける計算量の増大を抑止することができ、１装置あたりの処理チャネル数を増加させることが可能となる。その理由は、映像ストリームの切換要求は、時々起こるだけなので、不必要なデコードをせずにすむためである。

また、本実施の形態によれば、上記計算量の増大を抑止できる構成でありながら、端末からの映像ストリームの切替要求に対して迅速に対応することが可能である。その理由は、使用されていないストリームデータをバッファに貯め、いつでもデコードできる状態に保持しているためである。また、上記切替要求時には、過去にさかのぼりＩフレームからデコードを行うこととしたため、画質の劣化も抑止される。

続いて、本発明をＭＰＥＧ−４ストリームによる多地点テレビ会議システムに適用した第２の実施の形態について図面を参照してより詳細に説明する。図８は、本発明の第２の実施の形態に係る多地点会議システムのサーバ３００の詳細構成を表した図である。

図８を参照すると、サーバ３００は、ＤＴＭＦ（Ｄｕａｌ Ｔｏｎｅ Ｍｕｌｔｉ Ｆｒｅｑｕｅｎｃｙ）受信部３２０、制御部３５０のほか、ｎ台の端末に対応すべく、ｎ組のＲＴＰ（Ｒｅａｌ Ｔｉｍｅ ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）受信部３１１〜３１ｎ、バッファ３３１〜３３ｎ、ＭＰＥＧ−４デコーダ３４１〜３４ｎ、選択・合成部３６１〜３６ｎ、リサイズ部３７１〜３７ｎ、ＭＰＥＧ−４エンコーダ３８１〜３８ｎ、ＲＴＰ送信部３９１〜３９ｎにより、ｎ台の端末とそれぞれ通信可能となっている。

ＤＴＭＦ受信部３２０は、第１の実施形態における制御信号受信部２２０に相当する手段であり、各端末からＤＴＭＦ信号を受信し、制御部３５０に伝える手段であり、制御部３５０は、サーバ３００全体の制御のほか、ＤＴＭＦ信号に基づいて各端末に配信すべきＭＰＥＧ−４ストリームを決定し、ＭＰＥＧ−４デコーダ３４１〜３４ｎを含む各ユニットに指令を与える手段である。

ＲＴＰ受信部３１１〜３１ｎは、第１の実施形態における映像受信部２１１〜２１ｎに相当する手段であり、ネットワーク５００を介して端末からＭＰＥＧ−４ストリームを含んだＲＴＰパケットを受信・解析し、ＭＰＥＧ−４ストリームを取り出す手段である。また、バッファ３３１〜３３ｎは、サーバ３００のメモリに構築された映像ストリームの一時的な格納先である。

ＭＰＥＧ−４デコーダ３４１〜３４ｎは、第１の実施形態におけるデコーダ２４１〜２４ｎに相当する手段であり、映像ストリームをデコードし、画像を作成する手段であり、上記した第１の実施形態同様、各端末から受信した映像ストリームが現在デコード対象であるか否かをアクティブ／非アクティブで表すフラグを有している。

選択・合成部３６１〜３６ｎは、制御部３５０の指示に従い、ＭＰＥＧ−４デコーダ３４１〜３４ｎから出力される画像を選択し、あるいは、ＭＰＥＧ−４デコーダ３４１〜３４ｎからの画像を複数選択し上下左右に割り付けた状態に結合する手段である。また、リサイズ部３７１〜３７ｎは、選択・合成部３６１〜３６ｎから出力された画像について、各端末に適合するサイズに拡大・縮小するための手段である。

ＭＰＥＧ−４エンコーダ３８１〜３８ｎは、第１の実施形態におけるエンコーダ２８１〜２８ｎに相当する手段であり、各端末に適合する符号化方式、符号化設定、パラメータで画像をエンコードし、ＭＰＥＧ−４ストリームに変換する手段である。

ＲＴＰ送信部３９１〜３９ｎは、第１の実施形態における（映像）送信部２９１〜２９ｎに相当する手段であり、ＭＰＥＧ−４エンコーダ３８１〜３８ｎで作成されたＭＰＥＧ−４ストリームをＲＴＰパケットにし、ネットワーク５００を介して、それぞれ対応付けられた端末１０１〜１０ｎに送信する手段である。

また、本発明の理解を助けるため図示省略したが、多地点会議サーバ３００には、音声ストリームを扱う各処理手段が備えられている。

続いて、図８を用いてサーバ３００の動作について説明する。各端末が、それぞれＭＰＥＧ−４ストリームをＲＴＰパケットにしてサーバ３００に送信すると、サーバ３００のＲＴＰ受信部３１１〜３１ｎがそれぞれ個別に各端末からのパケットを受信・解析し、ＭＰＥＧ−４ストリームを取り出す。

ＭＰＥＧ−４デコーダ３４１〜３４ｎは、保持するフラグがアクティブ状態であるか否かによって以下のとおり動作を変える。まず、アクティブ状態にあるＭＰＥＧ−４デコーダ３４１〜３４ｎは、ＭＰＥＧ−４ストリームをデコードし、各端末から送られた画像を作成する。

アクティブ状態から非アクティブ状態に切り替えられた場合は、ＭＰＥＧ−４デコーダ３４１〜３４ｎは直ちにデコードを中止するのではなく、Ｉフレームが到達するまでデコード処理を継続し、Ｉフレームが到達した後にフラグを書き換え非デコード状態へと遷移する。

非アクティブ状態に遷移したＭＰＥＧ−４デコーダ３４１〜３４ｎは、前記到達したＩフレームのＭＰＥＧ−４ストリームデータをバッファ３３１〜３３ｎに格納する。バッファ３３１〜３３ｎの内容は上記した第１の実施形態と同様に、新しいＩフレームの全体が到達する（Ｉフレームが分割されている場合は最後のデータを待つ。）まで保持され、新しいＩフレームが到達した段階でクリアされる。

上記非アクティブ状態からアクティブ状態に切り替えられた場合は、ＭＰＥＧ−４デコーダ３４１〜３４ｎは、前記バッファに蓄積された最も新しいフレーム（Ｉフレーム）まで遡ってデコードする。

一方、選択・合成部３６１〜３６ｎは、制御部３５０の指示に従って画像を選択・合成し、適宜リサイズ部３７１〜３７ｎによる拡大・縮小処理を経た後、ＭＰＥＧ−４エンコーダ３８１〜３８ｎが各端末用にエンコード処理を行う。エンコードにより作成されたＭＰＥＧ−４ストリームは、ＲＴＰ送信部３９１〜３９ｎによりＲＴＰパケット化され、端末へ個別に送信される。

また、端末は、サーバ３００のＤＴＭＦ受信部３２０に対し、ＤＴＭＦ信号にて制御信号を送り、サーバ３００に要求を伝達し、サーバ３００から受信する映像を切り替えることができる。

以上の本発明の第２の実施形態では、制御信号としてＤＴＭＦ信号を用いる例を挙げたが、ＤＴＭＦ信号の代わりにＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などを使用することも可能である。

また、上記した各実施形態では、サーバは、最新のＩフレーム以降のデータをそのバッファに保持するものとし、切替要求があった場合にはバッファの先頭（即ち、最新のＩフレーム）からデコードするものとして説明したが、映像ストリームをバッファに蓄積しておき、切替要求があった場合には所定時間分過去に遡ってデコードするという本発明の要旨を逸脱しない範囲で、各種の変形・置換をなしうることが可能であることはいうまでもない。例えば、バッファの更新ロジックとは別にバッファの読み出しロジック（Ｉフレームのサーチ）を設けてもよいことはもちろんである。

本発明の一実施の形態に係る多地点会議システムの概略構成を表した図である。 本発明の一実施の形態に係る多地点会議システムにおける各端末とサーバ間の接続を表した図である。 本発明の一実施の形態に係る多地点会議サーバの詳細構成を表した図である。 本発明の一実施の形態に係る多地点会議サーバの動作を説明するための図である。 本発明の一実施の形態に係る多地点会議サーバの動作を説明するための図である。 本発明の一実施の形態に係る多地点会議サーバのバッファの状態遷移を説明するための図である。 本発明の一実施の形態に係る多地点会議サーバのバッファの状態遷移を説明するための別の図である。 本発明の第２の実施の形態に係る多地点会議サーバの動作を説明するための図である。

符号の説明

１０１〜１０ｎ 端末
２００、３００ 多地点会議サーバ（サーバ）
５００ ネットワーク
２１０、２１１〜２１ｎ 映像受信部
２２０ 制御信号受信部
２３１〜２３ｎ、３３１〜３３ｎ バッファ
２３ｘ＿Ｔ０〜２３ｘ＿Ｔ５、２３ｘ＿Ｔ１０〜２３ｘ＿Ｔ１３ バッファ
２４１〜２４ｎ デコーダ
２５０、３５０ 制御部
２６１〜２６ｎ、３６１〜３６ｎ 選択・合成部
２７１〜２７ｎ、３７１〜３７ｎ リサイズ部
２８１〜２８ｎ エンコーダ
２９０、２９１〜２９ｎ 映像送信部（送信部）
３１１〜３１ｎ ＲＴＰ受信部
３２０ ＤＴＭＦ受信部
３４１〜３４ｎ ＭＰＥＧ−４デコーダ
３８１〜３８ｎ ＭＰＥＧ−４エンコーダ
３９１〜３９ｎ ＲＴＰ送信部
Ｐ＿Ｔ０〜Ｐ＿Ｔ４、Ｐ１＿Ｔ１０、Ｐ２＿Ｔ１０、Ｐ＿Ｔ１１、Ｐ＿Ｔ１２ 映像ストリームデータ

Claims (13)

1. 映像ストリームを送信する複数の端末と接続され、前記各端末から要求された映像ストリームをエンコードし前記各端末に送信する多地点会議サーバであって、
   前記各端末に送信する分の映像ストリームのみをデコードするデコーダと、
   送信対象外の映像ストリームをデコードせずにイントラフレームから蓄積するバッファと、
   前記端末からの映像ストリームの切り替え要求に応じて、前記バッファに蓄積した映像ストリームを選択し所定時間分過去に遡ってイントラフレームからデコードし、該端末に送信する映像ストリームを切り替える切替制御部と、を備え、
   前記デコーダが前記切替制御部よりデコード停止の指令を受けた後に、
   受信したデータが映像ストリームのイントラフレームの場合に当該イントラフレームを前記バッファに格納し、かつ当該データが前記イントラフレームの最後のデータであるときに、前記デコーダが、デコードを停止する
   ことを特徴とする多地点会議サーバ。
2. 前記切替制御部は、前記バッファに蓄積された最も新しいイントラフレームまで遡ってデコードすること、
   を特徴とする請求項１に記載の多地点会議サーバ。
3. 更に、イントラフレームが入力される毎に前記バッファの蓄積内容を削除するバッファ更新手段を備えること、
   を特徴とする請求項１又は２に記載の多地点会議サーバ。
4. 更に、前記端末から要求された複数の映像ストリームを結合し、送信用の映像ストリームを合成する選択合成部を備えること、
   を特徴とする請求項１乃至３いずれか一に記載の多地点会議サーバ。
5. 請求項１乃至３いずれか一に記載の多地点会議サーバと、
   前記多地点会議サーバと映像ストリームを送受信する複数の端末とを接続してなる多地点会議システム。
6. 映像ストリームを送信する複数の端末と接続され、前記各端末から要求された映像ストリームをエンコードし前記各端末に送信する多地点会議サーバを構成するコンピュータに実行させるプログラムであって、
   前記各端末から受信した映像ストリームのうち、前記各端末に送信する分の映像ストリームを選択してデコードする処理と、
   前記各端末への送信対象外の映像ストリームをデコードすることなくイントラフレームからバッファに蓄積する処理と、
   前記端末からの映像ストリームの切り替え要求に応じて、前記バッファに蓄積した映像ストリームを選択し所定時間分過去に遡ってイントラフレームからデコードし、該端末に送信する映像ストリームを切り替える処理と、
   デコード停止の指令を受けた後に、
   受信したデータが映像ストリームのイントラフレームの場合に当該イントラフレームを前記バッファに格納し、かつ当該データが前記イントラフレームの最後のデータであるときに、デコードを停止する処理と
   を前記コンピュータに実行させるプログラム。
7. 前記端末に送信する映像ストリームを切り替える処理において、前記バッファに蓄積した最も新しいイントラフレームまで遡ってデコードして該端末に送信すること、
   を特徴とする請求項６に記載のプログラム。
8. 更に、イントラフレームが入力される毎に前記バッファの蓄積内容を削除する処理を、
   前記コンピュータに実行させる請求項６又は７に記載のプログラム。
9. 更に、前記端末から要求された複数の映像ストリームを結合し、送信用の映像ストリームを合成する処理を、
   前記コンピュータに実行させる請求項６乃至８いずれか一に記載のプログラム。
10. 映像ストリームを送信する複数の端末と、前記各端末から要求された映像ストリームをエンコードし前記各端末に送信する多地点会議サーバとを用いて実施する多地点会議方法であって、
    前記多地点会議サーバが、前記各端末に送信する分の映像ストリームのみをデコードするステップと、
    前記多地点会議サーバが、送信対象外の映像ストリームをデコードせずにイントラフレームからバッファに蓄積するステップと、
    前記多地点会議サーバが、前記端末からの映像ストリームの切り替え要求に応じて、前記バッファに蓄積した映像ストリームを選択し所定時間分過去に遡ってイントラフレームからデコードし、該端末に送信する映像ストリームを切り替えるステップと、
    前記多地点会議サーバが、デコード停止の指令を受けた後に、
    受信したデータが映像ストリームのイントラフレームの場合に当該イントラフレームを前記バッファに格納し、かつ当該データが前記イントラフレームの最後のデータであるときに、デコードを停止するステップと
    を含むこと、
    を特徴とする多地点会議方法。
11. 前記端末に送信する映像ストリームを切り替えるステップにおいて、前記多地点会議サーバは、前記バッファに蓄積した最も新しいイントラフレームまで遡ってデコードして該端末に送信すること、
    を特徴とする請求項１０に記載の多地点会議方法。
12. 更に、前記多地点会議サーバが、イントラフレームが入力される毎に、
    前記バッファの蓄積内容を削除するステップを含むこと、
    を特徴とする請求項１０又は１１に記載の多地点会議方法。
13. 更に、前記多地点会議サーバが、前記端末から要求された複数の映像ストリームを結合し、送信用の映像ストリームを合成するステップを含むこと、
    を特徴とする請求項１０乃至１２いずれか一に記載の多地点会議方法。

Images