(57)【要約】【課題】  フレーム内圧縮されたキーフレームとフレーム間圧縮された内挿フレームとを生成する映像圧縮方式を用いて映像を符号化するクライアントと、サーバとを有する双方向画像通信システムにおいて、サーバと各クライアント間の帯域を有効利用可能とする技術を提供する。【解決手段】  符号化データをクライアントから受信する手段と、受信した符号化データを複製してバッファに蓄積する手段と、サーバからクライアントへの送信状態に基づき、クライアントから受信する内挿フレームに対する符号化データ、又は、クライアントから受信するキーフレームに対する符号化データのいずれかを選択してクライアントに送信する手段と、サーバからクライアントへの送信状態に基づき、クライアントにおける映像符号化のリフレッシュレート値を決定し、少なくとも１つのクライアントへ当該リフレッシュレート値を送信する手段とをサーバに備える。【選択図】  図５
2006109011.tif 000002
【特許請求の範囲】
【請求項１】
フレーム内圧縮されたキーフレームとフレーム間圧縮された内挿フレームとを生成する映像圧縮方式を用いて映像を符号化する複数のクライアントと、映像の複製及び分配を行うサーバとを有する双方向画像通信システムにおいて使用されるサーバであって、
符号化データをクライアントから受信する手段と、
受信した符号化データを複製してバッファに蓄積する手段と、
サーバからクライアントへの送信状態に基づき、クライアントから受信する内挿フレームに対する符号化データ、又は、クライアントから受信するキーフレームに対する符号化データのいずれかを選択してクライアントに送信する手段と、
サーバからクライアントへの送信状態に基づき、クライアントにおける映像符号化のリフレッシュレート値を決定し、少なくとも１つのクライアントへ当該リフレッシュレート値を送信する手段と
を有することを特徴とするサーバ。
【請求項２】
前記サーバは、前記送信状態を、符号化データを送信してから該符号化データに対する応答をクライアントから受信するまでの応答時間として取得し、当該応答時間がフレーム間隔時間未満の場合には、前記応答を受信後に前記送信元クライアントから受信する最新の内挿フレームに対する符号化データを送信し、前記応答時間がフレーム間隔時間以上の場合には、前記応答を受信後に前記送信元クライアントから受信する最新のキーフレームに対する符号化データを送信する請求項１に記載のサーバ。
【請求項３】
前記応答時間がフレーム間隔時間以上となるクライアントが少なくとも１つ存在する場合において、前記サーバは、前記応答時間がフレーム間隔時間以上となるクライアントの中での前記応答時間の最小値と予め定めた最小リフレッシュレート値とを比較し、大きいほうの値をクライアントで使用すべきリフレッシュレート値とし、そのリフレッシュレート値をクライアントに送信する請求項２に記載のサーバ。
【請求項４】
前記応答時間がフレーム間隔時間以上となるクライアントが少なくとも１つ存在する場合において、前記サーバは、前記応答時間がフレーム間隔時間以上となるクライアントの中での前記応答時間の最小値をクライアントで使用すべきリフレッシュレート値とし、そのリフレッシュレート値をクライアントに送信する請求項２に記載のサーバ。
【請求項５】
フレーム内圧縮されたキーフレームとフレーム間圧縮された内挿フレームとを生成する映像圧縮方式を用いて映像を符号化する複数のクライアントと、映像の複製及び分配を行うサーバとを有する双方向画像通信システムにおいて使用されるサーバに処理を実行させるプログラムであって、前記サーバを、
符号化データをクライアントから受信する手段、
受信した符号化データを複製してバッファに蓄積する手段、
サーバからクライアントへの送信状態に基づき、クライアントから受信する内挿フレームに対する符号化データ、又は、クライアントから受信するキーフレームに対する符号化データのいずれかを選択してクライアントに送信する手段、
サーバからクライアントへの送信状態に基づき、クライアントにおける映像符号化のリフレッシュレート値を決定し、少なくとも１つのクライアントへ当該リフレッシュレート値を送信する手段、
として機能させるプログラム。
【請求項６】
フレーム内圧縮されたキーフレームとフレーム間圧縮された内挿フレームとを生成する映像圧縮方式を用いて映像を符号化する複数のクライアントと、映像の複製及び分配を行うサーバとを有する双方向画像通信システムにおいて使用されるサーバが処理を実行する方法であって、
符号化データをクライアントから受信するステップと、
受信した符号化データを複製してバッファに蓄積するステップと、
サーバからクライアントへの送信状態に基づき、クライアントから受信する内挿フレームに対する符号化データ、又は、クライアントから受信するキーフレームに対する符号化データのいずれかを選択してクライアントに送信するステップと、
サーバからクライアントへの送信状態に基づき、クライアントにおける映像符号化のリフレッシュレート値を決定し、少なくとも１つのクライアントへ当該リフレッシュレート値を送信するステップと、
を有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ・クライアント方式のビデオ会議システムにおけるサーバに関する技術に係り、特に、サーバとクライアント間の通信帯域を有効利用したデータ送受信を可能とする技術に関する。
【背景技術】
【０００２】
ＩＰネットワークを用いたビデオ会議システムにおいて、ネットワークの通信帯域が変動して伝送速度が低下した場合、伝送遅延が大きくなるため、受信側での動画像や音声の質に支障が生じるという問題がある。
【０００３】
このような問題を解決すべく、ＫＤＤＩが製品化しているＱｕａｌｉｔｙ  Ｍｅｅｔｉｎｇ（http://avs.kddlabs.co.jp/qmeet/body.html）では、通信可能な帯域を監視し、クライアント側でエンコーダのビットレートを変化させ、帯域に応じた通信を行っている（特許文献１参照）。
【０００４】
しかしながら、上記の従来技術を用いても、サーバ・クライアント形式のビデオ会議システムにおいては以下のような問題が生ずる。
【０００５】
例えばサーバにクライアント１とクライアント２が接続されている構成において、クライアント１がサーバを介してクライアント２に符号化データを送信する場合、上記の従来技術では、クライアント１とサーバ間の帯域しか考慮できないので、クライアント２とサーバ間の帯域がクライアント１とサーバ間の帯域より狭い場合には、クライアント２でクライアント１の映像が受信できない場合が生じる。従って、クライアント１のエンコーダのビットレートは、帯域の狭い方に合わせて設定しておかなければならない。
【０００６】
従って、３つ以上のクライアントがサーバに接続している場合に、３つのクライアント間で双方向通信を実現するためには、最も帯域の狭い回線に合わせてエンコーダのビットレートを設定しなければならず、サーバと各クライアント間の帯域を有効利用できないという問題がある。この問題を解決するために、サーバで符号化データをデコードし、クライアント毎に適切なビットレートでエンコードすることが考えられるが、この方法ではサーバ側で複雑な処理を要し、サーバの負担が大きくなるという問題がある。
【特許文献１】特開２００３−１１６１３３号公報
【非特許文献１】「要点チェック式Ｈ．３２３／ＭＰＥＧ４教科書」、（株）ＩＥインスティチュート、２００１年
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は上記の点を鑑みてなされたものであり、サーバに多大な負担をかけることなく、サーバと各クライアント間の帯域を有効利用可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記フレーム内圧縮されたキーフレームとフレーム間圧縮された内挿フレームとを生成する映像圧縮方式を用いて映像を符号化する複数のクライアントと、映像の複製及び分配を行うサーバとを有する双方向画像通信システムにおいて使用されるサーバであって、符号化データをクライアントから受信する手段と、受信した符号化データを複製してバッファに蓄積する手段と、サーバからクライアントへの送信状態に基づき、クライアントから受信する内挿フレームに対する符号化データ、又は、クライアントから受信するキーフレームに対する符号化データのいずれかを選択してクライアントに送信する手段と、サーバからクライアントへの送信状態に基づき、クライアントにおける映像符号化のリフレッシュレート値を決定し、少なくとも１つのクライアントへ当該リフレッシュレート値を送信する手段とを有することを特徴とするサーバにより解決される。
【０００９】
前記サーバは、前記送信状態を、符号化データを送信してから該符号化データに対する応答をクライアントから受信するまでの応答時間として取得し、当該応答時間がフレーム間隔時間未満の場合には、前記応答を受信後に前記送信元クライアントから受信する最新の内挿フレームに対する符号化データを送信し、前記応答時間がフレーム間隔時間以上の場合には、前記応答を受信後に前記送信元クライアントから受信する最新のキーフレームに対する符号化データを送信する。
【００１０】
また、前記応答時間がフレーム間隔時間以上となるクライアントが少なくとも１つ存在する場合において、前記サーバは、前記応答時間がフレーム間隔時間以上となるクライアントの中での前記応答時間の最小値と予め定めた最小リフレッシュレート値とを比較し、大きいほうの値をクライアントで使用すべきリフレッシュレート値とし、そのリフレッシュレート値をクライアントに送信する。
【００１１】
なお、上記の比較を行わず、前記応答時間の最小値をクライアントで使用すべきリフレッシュレート値とし、そのリフレッシュレート値をクライアントに送信してもよい。
【発明の効果】
【００１２】
上記のように本発明によれば、各クライアントへの送信状態に応じて、内挿フレームに対する符号化データもしくはキーフレームに対する符号化データのいずれかを、送信先クライアントに送信する符号化データとして選択することとしたので、サーバ−クライアント間のネットワークの帯域に適したデータ送受信が可能となる。また、各クライアントへの送信状態に応じて、符号化時のキーフレームの送信間隔であるリフレッシュレート値を適切に変更できるので、上記の選択の結果キーフレームしか受信できないクライアントでも帯域に適したフレームレートで映像を受信できる。また、帯域が変動する場合においても、変動する帯域に動的に対応した符号化データの送受信が可能となる。
【００１３】
更に、本発明によれば、従来技術のように帯域を監視する必要がないので、ネットワークの帯域が急激に変動する場合にも、その帯域に適したレートで適切な符号化データを送信先クライアントに送信することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本願発明の実施の形態を図面を参照して説明する。本実施の形態において、映像の符号化にはフレーム内圧縮されたフレーム（本明細書及び特許請求の範囲ではキーフレームと称する）とフレーム間圧縮されたフレーム（本明細書及び特許請求の範囲では内挿フレームと称する）とを生成する映像圧縮方式を用いる。このような映像圧縮方式としては、例えば、ＭＰＥＧ４やＨ．２６３（非特許文献１参照）等がある。
【００１５】
図１に、本発明の実施の形態におけるビデオ会議システムの構成を示す。図１に示すように、本発明の実施の形態におけるビデオ会議システムは、サーバ３、クライアントＡ（４）、クライアントＢ（５）、クライアントＣ（６）を有し、クライアントＡ及びクライアントＢはネットワーク１を介してサーバ３と接続され、クライアントＣはネットワーク２を介してサーバ３と接続される。
【００１６】
また、各クライアントにはカメラが接続されており、カメラの映像は予め設定されたビットレートで符号化される。各クライアントに接続されたカメラは、例えば、ＵＳＢ接続カメラやキャプチャボードを介して接続されたＮＴＳＣのＴＶカメラ等である。
【００１７】
ネットワーク１及びネットワーク２はインターネットやイントラネット等であり、ネットワーク１においてサーバ・クライアント間の上りの最大ビットレートを上りビットレート１、下りの最大ビットレートを下りビットレート１とする。
【００１８】
同様に、ネットワーク２におけるサーバ・クライアント間の上りの最大ビットレートを上りビットレート２、下りの最大ビットレートを下りビットレート２とする。ここで、下りビットレート２は上りビットレート１より小さく、下りビットレート１は上りビットレート１及び上りビットレート２より十分に大きい（少なくともそれらの２倍以上）とする。
【００１９】
サーバ３は、サーバ・クライアント方式のビデオ会議システムにおけるサーバとしての一般的な機能を有するとともに、後述する本願発明に係る機能を有している。サーバ３は、ＣＰＵ、メモリ、ハードディスク、ネットワーク通信装置等を備えた一般的なハードウェア構成を有し、本願発明に係る各手段は、サーバ３に搭載されるプログラムが実行されることにより実現される。当該プログラムはCD-ROM等の記録媒体からサーバにインストールすることもできるし、ネットワークを介してサーバにダウンロードし、インストールすることもできる。
【００２０】
また、各クライアントには映像を符号化する機能を含むビデオ会議用プログラムがインストールされている。映像を符号化する機能は、符号化パラメータを設定する機能、及びサーバから受信したリフレッシュレート値を符号化パラメータの一つとして利用する機能を有している。
【００２１】
図２に、図１に示したビデオ会議システムの動作を表すフローチャートを示す。図２を参照して、本実施の形態におけるビデオ会議システムの動作概要を説明する。なお、以下の動作の前に、符号化パラメータ（ビットレート、フレームレート、フレーム内圧縮されたキーフレームの間隔を示すリフレッシュレート値等）の設定を行っておく。リフレッシュレート値としては予め定めた最大リフレッシュレート値を設定しておく。
【００２２】
まず、各クライアントにおいてカメラ映像の取得を行う（ステップ１）。そして、サーバから受信したリフレッシュレート値の設定を行なう（ステップ２）。このリフレッシュレート値の設定は、サーバから更新されたリフレッシュレート値を受信した場合にのみ行えばよい。
【００２３】
次に、各クライアントでカメラ映像の符号化処理を行う（ステップ３）。ここでは、クライアントＡ及びクライアントＢは各々、上りビットレート１と同じビットレートでカメラ映像を符号化し、クライアントＣは上りビットレート２と同じビットレートでカメラ映像を符号化することにする。また、フレームレートは全てのクライアントで同じ（例えば３０ｆｐｓ）とする。
【００２４】
次に、映像の符号化データを各クライアントからサーバへ送信する（ステップ４）。ここでは、通信プロトコルとして、例えばＲＴＰ／ＵＤＰや、ＲＴＰをＨＴＴＰでカプセリングしたＴＣＰを用い、符号化データをフレーム単位で分割したビデオパケットとして送信する。
【００２５】
次に、サーバ３において受信した符号化データを各クライアント毎に複製し蓄積する（ステップ５）。そして、サーバからクライアントへの送信状態に基づいて符号化データを選択するとともに、各クライアントで設定すべきリフレッシュレート値の決定を行う（ステップ６）。そして、サーバ３は符号化データ及びリフレッシュレート値を各クライアントに送信する（ステップ７）。なお、リフレッシュレート値の送信は、リフレッシュレート値が変更された場合にのみ行えばよい。
【００２６】
上記符号化データの選択及びリフレッシュレート値の決定は、送信状態に基づき行うが、その送信状態とは、本実施の形態ではサーバがクライアントに送信した符号化データに対する応答を、サーバがクライアントから受信するまでの時間であるものとしている。この処理については後に詳細に説明する。その後、符号化データを受信したクライアントは受信データの復号化及び表示処理を行う（ステップ８）。
【００２７】
以下、上記のステップ５〜７におけるビデオパケットの複製と蓄積から送信までのサーバにおける処理を図３〜図５を用いてより詳細に説明する。この処理は本発明に係るプログラムにより実現されるものである。まず、基本的な処理について説明し、その後のリフレッシュレート値の変更について説明する。
【００２８】
（基本的な処理）
まず、図３の場合について説明する。図３は、クライアントＣから受信したビデオパケットをクライアントＡ、クライアントＢに送信する場合を示す。前述したように、図１における下りビットレート１は上りビットレート２より十分に大きく、クライアントＣは上りビットレート２と同じビットレートでカメラ映像を符号化するので、図３の場合、サーバからクライアントＡもしくはクライアントＢへの下りビットレート１は、送信されるデータのビットレートより十分に大きい。
【００２９】
図３において、ＩはＩピクチャ（フレーム内圧縮されたキーフレーム）、ＰはＰピクチャ（順方向予測の内挿フレーム）、ＢはＢピクチャ（双方向予測の内挿フレーム）に対するビデオパケットを示す。
【００３０】
サーバがクライアントＣからビデオパケットを受信すると、サーバは、ビデオパケットの受信順に、接続されているクライアント数分だけビデオパケットを複製し、クライアント毎に用意されたバッファに蓄積する。なお、バッファは例えばサーバにおけるメモリ内の所定のエリアとして実現される。
【００３１】
ここで用意するバッファ量は、少なくとも１つ以上のＩピクチャのビデオパケットが含まれるように設定される。例えば、図３の場合では、Ｉ，Ｂ，Ｐ，Ｂが蓄積できるバッファ量を設定している。
【００３２】
次にサーバにおいて送信状態に基づいて符号化データ（ビデオパケット）の選択を行う処理について説明する。
【００３３】
まず、バッファに蓄積されたＩピクチャのビデオパケットを各クライアントへ送信する。各クライアントはビデオパケットを受け取った直後に応答を返し、Ｉピクチャのビデオパケットを受信したことをサーバへ通知する。この場合、下りのビットレートが十分に確保されているので、ビデオパケット送信から応答受信までの時間がフレーム間隔時間未満となる。
【００３４】
この場合、バッファをクリアし次のＢピクチャのビデオパケットを待つ。クライアントＣからのＢピクチャのビデオパケットが到着したら、バッファに蓄積し、Ｉピクチャのビデオパケットと同様に各クライアントへＢピクチャのビデオパケットを送信し応答を待つ。これを繰り返し行うことにより、各クライアントヘビデオパケットを送信できる。ここでは、送信と応答のパケットの同定は、パケットに付加されたタイムスタンプの一致で判断する。
【００３５】
以上説明したように、ビデオパケット送信から応答受信までの時間がフレーム間隔時間未満の場合には、送信元のクライアントから送信されたビデオパケットと同じビデオパケットが送信先のクライアントに送信されることになる。
【００３６】
次に、図４に示す場合について説明する。図４は、クライアントＡから受信したビデオパケットをクライアントＣに送信する場合を示す。前述したように、図１における下りビットレート２は上りビットレート１より小さく、クライアントＡは上りビットレート１と同じビットレートでカメラ映像を符号化するので、図４の場合、サーバからクライアントＣへの下りビットレート２は、送信されるデータのビットレートより小さい。
【００３７】
まず、図３の場合と同様に、クライアントＡからＩピクチャのビデオパケットを受信し、複製してバッファに蓄積し、バッファに蓄積されたＩピクチャのビデオパケットをクライアントＣへ送信する。
【００３８】
しかしながら、図４に示す場合には、下りのビットレートが低いため、次のＢフレームのビデオパケットがクライアントＡからサーバに到着しても、クライアントＣからの応答をサーバは未だ受信していない。
【００３９】
この場合、図３の場合と異なり、バッファをクリアすることなく、Ｉピクチャのビデオパケットの後ろに続くバッファ内にＢピクチャのビデオパケットを保持する。同様に、続くＰパケットとＢパケットのビデオパケットもバッファ内に保持される。この間に、クライアントＣからの応答があれば、次のＩピクチャのビデオパケットをクライアントＡからサーバが受け取ったときに、バッファを全てクリアし、同様にＩピクチャのビデオパケットをクライアントＣへ送信する。ただし、次のＩピクチャのビデオパケットをクライアントＡから受け取っても、クライアントＣから応答がない場合には送信は行わず、応答がくるまでバッファの蓄積とクリアを繰り返す。図４の場合も、送信と応答のパケットの同定は、パケットに付加されたタイムスタンプの一致で判断する。なお、クライアントＡからビデオパケットを受信した旨を示す情報とそれに対応するタイムスタンプは、バッファにビデオパケットを蓄積することとは別に保持する。
【００４０】
以上説明したように、ビデオパケット送信から応答受信までの時間がフレーム間隔時間以上の場合には、送信元のクライアントから送信されたビデオパケットのうちＩピクチャのビデオパケットのみが送信先のクライアントに送信されることになる。
【００４１】
（リフレッシュレート値の変更処理について）
さて、図３の場合のように帯域が十分でありビデオパケット送信から応答受信までの時間がフレーム間隔時間未満である場合、受信した全てのフレームをクライアントに送信できるので、リフレッシュレート値を大きく（例えば、５秒）とって圧縮効率を上げることにより高画質を保つことができる。
【００４２】
一方、図４の場合のように、応答時間がフレーム間隔時間以上である場合、クライアントはＩフレームのみを受け取ることになる。ここで、サーバはＩフレームをリフレッシュレート間隔で受信するので、図４の場合のようにリフレッシュレート値が応答時間に比べて大きいときは、クライアントは、応答時間より大きなリフレッシュレートの時間間隔でしかＩフレームを受け取れない。すなわち、この場合、クライアントはより短時間間隔である応答時間間隔でＩフレームを受け取れるにもかかわらず、リフレッシュレートの制約でそれができないこととなり、サーバからクライアントへの帯域が有効活用されないことになる。
【００４３】
そこで、図４のような場合、サーバが、その時点でのリフレッシュレート値よりも小さいリフレッシュレート値を各クライアントに送信し、図４のような状態にあるクライアントが応答時間に近い時間間隔でＩフレームを受け取れるようにする。
【００４４】
リフレッシュレート値を小さくすると圧縮効率が低下して画質が低下する。従って、リフレッシュレート値を小さくするとしても、できるだけ大きな値としておくことが好ましい。そこで本実施形態では以下のようにする。
【００４５】
各クライアントには、予め定めた最大リフレッシュレート値がリフレッシュレート値として予め設定されている。サーバもその最大リフレッシュレート値を保持する。また、サーバは、予め定めた最小リフレッシュレート値（例えば１秒）を保持する。なお、最小リフレッシュレート値は、主観評価で許容される画質から決定される値である。
【００４６】
そして、各クライアントによる映像通信中、サーバは各クライアント毎に上記の応答時間を（例えば一定時間間隔で更新しながら）メモリ等に保持し、応答受信までの時間がフレーム間隔時間以上となるクライアントが存在するか否かをチェックする。応答受信までの時間がフレーム間隔時間以上となるクライアントが存在する場合、そのようなクライアントの中における応答時間の最小値（そのようなクライアントが１つであればそのクライアントの応答時間）と最小リフレッシュレート値とを比較し、大きいほうの値をリフレッシュレート値として決定し（同じであればその同じ値とすればよい）、そのリフレッシュレート値を各クライアントに送信する。各クライアントでは、サーバから受信したリフレッシュレート値で映像符号化を行う。
【００４７】
上記の状態にあるクライアントの中での応答時間の最小値と最小リフレッシュレート値とを比較して大きい値をリフレッシュレート値として決定することにより、上記の状態にある全てのクライアントが自身の応答時間間隔もしくはそれに近い時間間隔でＩフレームを受け取れるようになる。また、上記の状態にあるクライアントの中での応答時間の最小値と最小リフレッシュレート値とを比較して大きい値をリフレッシュレート値として決定することにより、必要以上にリフレッシュレート値を小さくすることがなくなり、最大限画質を良好に保つことができる。なお、上記の状態にあるクライアントの応答時間が概ね最小リフレッシュレート値より大きくなることが分かっている場合等では、応答時間の最小値と最小リフレッシュレート値との比較を行うことなく、応答時間の最小値をリフレッシュレート値として決定してもよい。
【００４８】
一例として、図４の状態になったため、サーバがリフレッシュレート値をクライアントＣの応答時間と同じ値として決定し、各クライアントにリフレッシュレート値を送信した後における通信状況を図５に示す。図５の場合、図４の場合と比べてクライアントＣは約１／２の時間間隔でＩフレームを受信できるため、クライアントＣにおけるフレームレートは図４の場合に比べて約２倍となり、帯域をより有効に活用できるとともに、クライアントＣはより良好な映像を受信できる。
【００４９】
上記のリフレッシュレート値の更新処理は、サーバが常時応答時間をチェックして最小応答時間が変化する度に行ってもよいし、一定時間間隔をおいて行ってもよい。なお、リフレッシュレート値は、応答時間の最小値が大きくなれば大きくなるが、応答時間の最小値が最大リフレッシュレート値以上となった場合には、リフレッシュレート値は最大リフレッシュレート値とする。
【００５０】
また、更新後のリフレッシュレート値を、映像通信に参加しているクライアント全てに送信する代わりに、特定のクライアントにのみ送ってもよい。例えば、クライアントＡ〜Ｄが映像通信に参加する場合において、クライアントＡ〜Ｂ間は通信状態が良好であることがわかっていて、かつクライアントＡ〜Ｂ間の画質を優先的に良好に保ちたい場合において、例えばクライアントＤが上記の状態になった場合には、更新後のリフレッシュレート値はクライアントＣ、Ｄのみに送るようにする。
【００５１】
上記のように、クライアントで受信する符号化データは、送信元と同じ符号化データ又はＩフレームのみを含む符号化データである。従って、どちらの符号化データが届いても、クライアント側で場合分けして処理する必要なく復号化し、表示することが出来る。このように、サーバと各クライアント間の帯域に適した送受信が可能となる。また、Ｉフレームのみを受信する場合であっても、リフレッシュレート値を適宜変更することによって、サーバと各クライアント間の帯域に適した送受信が可能となる。また、帯域が変動する場合においても、変動する帯域に動的に対応した符号化データの送受信が可能となる。
【００５２】
更に、従来技術のように帯域を監視する必要がないので、ネットワークの帯域が急激に変動する場合にも、その帯域に適したレートで符号化データを送信先クライアントに送信することができる。
【００５３】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内で種々変更・応用が可能である。
【図面の簡単な説明】
【００５４】
【図１】本発明の実施の形態におけるビデオ会議システムの構成を示す図である。
【図２】図１に示したビデオ会議システムの動作を表すフローチャートである。
【図３】クライアントＣから受信したビデオパケットをクライアントＡ、クライアントＢに送信する場合におけるサーバの動作を説明するための図である。
【図４】クライアントＡから受信したビデオパケットをクライアントＣに送信する場合におけるサーバの動作を説明するための図である。
【図５】リフレッシュレート値を変更した後におけるサーバの動作を説明するための図である。
【符号の説明】
【００５５】
１、２  ネットワーク
３  サーバ
４  クライアントＡ
５  クライアントＢ
６  クライアントＣ
【図１】
2006109011.tif 000003
【図２】
2006109011.tif 000004
【図３】
2006109011.tif 000005
【図４】
2006109011.tif 000006
【図５】
2006109011.tif 000007