JP4498002B2

JP4498002B2 - 情報処理装置及び方法

Info

Publication number: JP4498002B2
Application number: JP2004136020A
Authority: JP
Inventors: 弘幸大澤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-04-30
Filing date: 2004-04-30
Publication date: 2010-07-07
Anticipated expiration: 2024-04-30
Also published as: JP2005318412A

Description

本発明は、ネットワークを介して遠隔操作可能な撮像手段を有するカメラサーバ、ネットワークを介して前記カメラサーバと通信を行う情報処理装置、及び前記カメラサーバと情報処理装置とを含むネットワークカメラシステムに関するものである。

従来、ネットワークシステムを接続媒体としたネットワークカメラシステムが存在する。このネットワークカメラシステムは、TCP/IP網などのインターネットに代表される広域ネットワークを用いることで、遠隔地にある監視カメラ等のカメラが撮影した画像をクライアント装置で閲覧することができるシステムである。こういったネットワークカメラシステムの中には、パン・チルト・ズームなど、カメラのコントロールが可能なものが存在する。

さらに、映像だけではなく音声配信が可能なシステムも多く存在している。このような技術によって、遠隔地から動画像だけでなく音声も同時に閲覧が可能になってきている。

これらのネットワークカメラシステムは、従来のアナログベースのCCITVベースの監視システムと違い、デジタル画像をベースとして、画像の転送や画像の蓄積、画像の検索などが可能になっている。そのため多くのアナログベースの監視カメラシステムの欠点を補うことが可能となってきている。

市場では、店舗内の監視や工場ラインの監視、公共施設や学校施設の監視など、様々に適用されている。

特開平１１−２５０３９号公報

類似しているものとしてテレビ電話システムなどが存在するが、プロトコルがＵＤＰ、ＲＴＰ、ＴＣＰベースのものが中心であり、企業や家庭などで用いられているファイヤーウォールを透過することが可能なプロトコルでは作られていなかった。そのため、ファイヤーウォールを透過するために、ファイヤーウォールに特殊な設定等を行う必要があった。

また、従来のネットワークカメラシステムでは、１対１接続を基本とするテレビ電話システムとは異なり、１つのネットワークカメラに複数のクライアント装置が接続することが想定されており、音声通信を双方向で行い、会話が可能なシステムは存在しなかった。

本発明は上記問題点を鑑みてなされたものであり、ネットワークカメラシステムにおいて、双方向の音声通信を行えるようにすることを目的とする。

ネットワークを介して受信した音声データに応じた音声を出力可能なスピーカーを有するカメラサーバと通信可能な本発明の情報処理装置は、前記カメラサーバから配信される画像データを受信する受信手段と、前記受信手段で受信した画像データに応じた画像を表示させる表示手段と、音声データを入力する音声入力手段と、前記カメラサーバのスピーカーを占有するためのスピーカー占有権を取得する取得手段と、前記カメラサーバの撮像装置の方向を制御するための制御量を入力するための制御量入力手段と、前記取得手段によりスピーカー占有権を取得しているときは、前記制御量入力手段で入力した制御量に応じた制御信号を前記カメラサーバに送信可能にすると共に、前記音声入力手段で入力した音声データを、前記ネットワークを介して前記カメラサーバに送信し、前記取得手段によりスピーカー占有権が取得されていないときは、前記制御量に応じた制御信号を送信可能とせず、前記音声データを前記カメラサーバに送信しない送信手段とを有し、前記表示手段は、前記スピーカー占有権の取得に応じて前記送信手段によって送信された音声データに応じた音声が前記カメラサーバのスピーカーで出力されているか否かを更に表示させる。

上記構成によれば、ネットワークカメラシステムにおいて、ネットワークカメラシステムにおいて、双方向の音声通信を行うことができる。

以下、添付図面を参照して本発明を実施するための最良の形態を詳細に説明する。

本発明の実施の形態は、ネットワークカメラサーバに音声配送機能を追加した機能に関するものである。なお、ネットワークカメラサーバとは、接続されたカメラから映像を取得し、デジタル画像データに変換し、通信回線網を用いて遠隔地にあるデジタル画像再生装置によって映像を閲覧することが可能なカメラを指す。

図１は、本実施の形態におけるシステム全体の構成を示す概略図である。

図１において、ネットワーク２００はデジタル化された画像データを搬送するデジタル回線網などの回線やネットワークで、インターネットに代表されるインターネット網やイントラネット網等がある。ネットワーク２００の物理媒体としては、イーサネット（登録商標）や無線ＬＡＮ、光ファイバーなどを用いることが可能であるが、論理的接続が可能であれば、無線、有線などの種類は特に問わない。また、本実施の形態ではTCP/IPを用いるものとして説明するが、同様の目的を果たすことが可能なプロトコルであれば、どのようなプロトコルを用いても構わない。

１００はネットワークに直接もしくは間接的に接続されたカメラサーバであって、ここではカメラを含む構成であるものとする。勿論、外部カメラと接続するように構成することも可能である。また、本実施の形態においては、パン・チルト・ズーム等が可能なカメラを仮定するが、固定単焦点のカメラを用いることもできる。カメラサーバ１００からネットワーク２００への物理接続形態は特に決められたもので無くても良く、論理的に接続されていれば問題無い。

また、カメラサーバ１００は音声入力端子と音声出力端子を有し、それぞれマイク１０１とスピーカー１０２が接続されている。特に、カメラがパン・チルト・ズーム等が可能なカメラである場合、マイク１０１として指向性の高いマイクを用いて、カメラのパン・チルト・ズームと連動させるようにしてもよい。また、マイク１０１及びスピーカー１０２は、カメラサーバ１００に内蔵されていても良く、複数であっても良い。更に、マイク１０１やスピーカー１０２は、カメラサーバ１００に対して音声信号の入力や音声信号の出力が可能な装置であれば、どのような装置でも構わない。例えば、マイク１０１の代わりにＣＤプレイヤーなどの音声信号出力装置を接続したり、スピーカー１０２の代わりに、ＭＤプレイヤー等の音声信号録音装置を接続してもよい。

３００、４００、５００は閲覧装置であるクライアント装置（以下、単に「クライアント」と呼ぶ。）である。図１では３台のクライアントを図示しているが、１台であっても、４台以上であっても良く、本発明はクライアントの数に制限されるものではない。クライアント３００〜５００として、ネットワーク２００に論理的に接続された情報処理装置を用いることができる。図中では、このクライアント３００〜５００に映像出力装置３０１、４０１、５０１や、マウスやキーボードなどの操作入力装置３０２、４０２、５０２が接続されており、カメラサーバ１００の操作及び配信画像の閲覧を可能にしている。

更に、クライアント３００〜５００には、それぞれマイク３０３、４０３、５０３及びスピーカー３０４、４０４、５０４が接続されている。マイク３０３、４０３、５０３及びスピーカー３０４、４０４、５０４により、カメラサーバ１００から配信された音声を聴いたり、カメラサーバ１００へ音声を送信することが可能になる。

なお、映像出力装置、操作入力装置、マイク、スピーカーは、その一部または全部がクライアント装置と一体的に構成されていても良い。

次に、図１を参照しながら、本実施の形態における音声配送処理の概要を説明する。まず、カメラサーバ１００からクライアント３００〜５００に音声を送信する場合について説明する。

カメラサーバ１００の１つの機能として、カメラにより撮影した画像を多数のクライアントに同時に閲覧させることを可能とする機能がある。これと同様の機能を音声に関しても可能にするものである。

カメラサーバ１００は、マイク１０１から音声を入力し、これをサンプリングして、音声データを生成する。この際、キャプチャされた音声信号は、カメラサーバ１００内でデジタル音声データになるばかりでなく、圧縮処理やデジタル音声フィルタ処理、無音検出（Voice Activity Detection：ＶＡＤ）処理など、様々なデジタル音声信号処理が行われる。このような動作の詳細は後述する。

上述したようにして生成された音声データは、ネットワーク２００を通して接続する各クライアント３００〜５００に配信される。これにより、各クライアント３００〜５００は、音声データを受信することが可能となる。

各クライアント３００〜５００では、受信した音声データを処理し、スピーカー３０４、４０４、５０４から音声を出力する。この際、各クライアント３００〜５００は、音声データに対して解凍処理やＶＡＤ処理、ＣＮＧ（Comfort Noise Generator）処理、その他の音声フィルタ処理を行って音声を出力する。

音声データは、多くのクライアントへ出力するために、接続するクライアントの数にあわせてコピーを送信する。そのため、各クライアントでは、ほぼ同時にカメラサーバ１００で録音される音声を再生することが可能になる。ただし、音声データの処理時間や配信時間などによって遅延時間が発生する場合があるが、本実施の形態では特に問題にはならない。

次に、本実施の形態において、クライアント３００〜５００からカメラサーバ１００に音声を送信する場合について説明する。

この機能で重要な点は、カメラサーバ１００の音声出力端子を、複数のクライアント３００〜５００で共有するという点である。つまり、カメラサーバ１００からクライアント３００〜５００への音声配信に関しては、基本的に音声データのコピーを全接続クライアントに送信するだけで良く、これによって複数のクライアント３００〜５００が同時にカメラサーバ１００から配信される音声を聞くことができる。これに対し、逆方向のクライアント３００〜５００からカメラサーバ１００への音声送信処理では、サーバに接続している全クライアントがサーバの音声出力端子を共有しなければならない。なお、本実施の形態では音声出力端子が１つであるものとして説明するが、音声出力端子は、１端子のみであることは必須ではなく、複数の音声出力端子があっても良い。この場合は、音声出力端子の占有化が各端子毎に行われる。

前述した問題を解決する手法の１つとして、クライアント３００〜５００からカメラサーバ１００への音声送信に関しては、排他制御をカメラサーバ１００で行う方法がある。このようにすることで、スピーカー１０２の競合を防ぐことが可能になる。

例えば、クライアント３００及び４００が同時にカメラサーバ１００に対して、音声データを送信したとする。この場合、カメラサーバ１００では、例えば、クライアント３００からの音声データを優先的に受け入れ、受け入れた音声データの圧縮データの解凍や音声フィルタ処理を行った後に、スピーカー１０２から音声として出力する。これにより、クライアント３００から配送された音声のみを聞くことができる。

カメラサーバ１００における音声の再生制御に関しては、上記に限るものではなく、別方式を採用しても良い。例えば、カメラサーバ１００は、クライアント３００及び４００から同時に配送された音声データを両方とも受け入れ、受け入れた音声データを合成して合成音声データを生成し、生成した合成音声データを再生してもよい。つまり、２つの音声データをミキシングして再生する。これにより、スピーカー１０２からは、２つのクライアント３００及び４００からの音声のミキシング音声が再生されるため、両方のクライアントから送信された音声を同時に聞くことが可能になる。

なお、上記例では、２つのクライアントから配送された音声データの合成に関して説明したが、クライアント数は２台に限るものでは無く、任意の数のクライアントに対して同様の処理を行うことができる。

ただし、あまりに多くのクライアントがカメラサーバ１００に対して同時に音声を配信すると、再生された音声がはっきりと聞き取れないものになってしまう恐れがある。そこで、カメラサーバ１００は、排他制御と音声のミキシングを組み合わせて実施するようにすることも可能である。

例えば、音声を配信したクライアント数が５台未満の場合には音声のミキシングを行い、５台以上の場合には排他制御を実施し、ミキシングする音声の音源が常に５台以下になるようにする、といった制御を行うことも可能である。なお、具体的な台数はこれに限るものではない。

上述したような各設定は、カメラサーバ１００が制御プログラムを保持することで可能となる。

このように、カメラサーバ１００に接続されたスピーカー１０２の占有などのアルゴリズムは重要な要素であり、他の排他制御方法も合わせて後述する。

図２は、カメラサーバ１００のハードウェア構成を示すブロック図である。

カメラサーバ１００は基本的に一般のコンピュータと同一の構成を有し、具体的には、中央演算部（ＣＰＵ）１１０、主記憶部１１１、ハードディスクやフラッシュメモリ等の外部記憶部１１２、ネットワーク接続部１１３、カメラ部１１４、画像入力部１１５、雲台部１１６、音声入力部１１７、音声出力部１１８を含む。これら各部はバスラインで接続されており、連帯して動作することが可能である。

主記憶部１１１はプログラムや情報を一時記憶する。ＣＰＵ１１０は、主記憶部１１１に記憶されたプログラムを実行し、全体の装置を制御し、画像データ及び音声データの配送を行う。外部記憶部１１２は、プログラムや蓄積画像情報、蓄積音声情報などをファイルとして記憶する。ネットワーク接続部１１３は、ネットワーク２００に接続するために用いられる。

画像入力部１１５は、カメラ部１１４からの画像情報をデジタル化する。画像入力部１１５により、ＣＰＵ１１０でカメラ部１１４から入力されたデジタル画像データをカメラサーバ１００で処理することが可能となる。

カメラ部１１４は、光学系カメラの画像を電気信号に変換する装置である。カメラ部１１４と画像入力部１１５として用いる方式としてはいくつかの方式が存在する。例えばＣＣＤのように直接光学画像を電気信号に変換することが可能でかつデジタル信号で読み出せる場合もあるし、一度、アナログ電気信号による画像信号に変換したあとにデジタル化を行う場合もある。なお、カメラ部１１４はカメラサーバ１００に内蔵されている必要は無く、外部に接続されていても良い。

雲台部１１６は、カメラ部１１４のパン・チルト動作を行う装置である。雲台部１１６によって、ＣＰＵ１１０からのカメラのパン・チルト情報を用いてカメラ部１１５の方向を自由にコントロールすることが可能となる。

音声入力部１１７には、外部マイク１０１が接続される。上述したように、マイク１０１は、空気振動を電気信号に変えるマイクであっても良いし、ＣＤレコーダーのような音声信号発生装置でも構わない。これらのマイク１０１が、音声入力部に接続されることで、音声信号をデジタル化することが可能となり、ＣＰＵ１１０がデジタル化された音声データの処理を行う。

音声出力部１１８には、外部スピーカー１０２が接続される。音声出力部１１８は、デジタル化された音声データをアナログ電気信号に変換し、スピーカー１０２に出力することで、音声の再生を可能とする。なお、上述したように、スピーカー１０２は、電気信号を空気振動に変換する装置であっても良いし、音声信号を録音するＭＤレコーダのような音声録音装置を接続してもよい。

次に、図３を参照してクライアント３００のハードウェア構成を説明する。なお、ここでは代表的としてクライアント３００の構成を説明するが、他のクライアント４００及び５００も同様の構成を有する。

クライアント３００は基本的にパーソナルコンピュータ（ＰＣ）により構成され、具体的には、中央演算処理部（ＣＰＵ）３１０、主記憶部３１１、ハードディスクやフラッシュメモリ等の外部記憶部３１２、ネットワーク接続部３１３、画像出力部３１４、入力部３１５、音声入力部３１６、音声出力部３１７を含む。これら各部はバスラインで接続されており、連帯して動作することが可能である。

主記憶部３１１はプログラムや演算結果を一時的に記憶し、ＣＰＵ３１０は主記憶部３１１からプログラムを読み出して実行し、その結果を各構成に送ることで装置全体を制御している。同様に、各構成からの情報を読み取り演算することで、各構成の状態を把握することができる。外部記憶部３１２には、ファイルやソフトウェアなどの情報が記録される。ネットワーク接続部３１３は、ネットワーク２００と接続するために用いられる。

画像出力部３１４は、ビデオＲＡＭを搭載しているメモリ空間とそのメモリ空間から画像信号情報を作成する。映像出力装置３０１に接続することで、クライアント３００で得られた画像を実際に画像信号を目に見える状態にすることができる。入力部３１５は、主にオペレータの指示を入力するための操作入力部３０２に接続するための構成であり、例えば、キーボードやマウス、タッチパネル等が接続される。音声入力部３１６にはマイク３０３が接続され、入力する音声をデジタル化してデジタル音声データを作成する装置である。音声出力部３１７は、デジタル音声データをアナログ音声信号に変換する。この音声出力部３１７にスピーカー３０４を接続することで、デジタル音声データがオペレータの耳に聞こえる音声となる。

なお、外部装置３０１〜３０４は、クライアント３００と一体化されている場合がある。その例として、ノート型パソコンや携帯電話などが挙げられる。このように、本実施の形態ではクライアント３００の形態を特に問うものではなく、どのような構成や形状であっても同様の動作を行うのであれば構わない。

図４は、カメラサーバ１００のソフトウェア構成を示すブロック図である。

カメラサーバ１００とクライアント３００、４００、５００の音声部分のハードウェア構成は殆ど同一である。これは双方向に音声を送受信する必要性があるため、当然ながら似ている。ソフトウェア構成に関しても同様に、カメラサーバ１００とクライアント３００、４００、５００で類似していると言える。

カメラサーバ１００の音声配信に関連するソフトウェアの構成は、大きくわけて２つの音声データの流れに対応するものに分かれる。１つは音声を送信する音声データの流れに対応するもので、もう１つは音声を受信する音声データの流れに対応するものである。

まず、音声の送信に関するソフトウェア構成について説明する。

音声信号は、マイク１０１によってアナログ音声データ６０１としてカメラサーバ１００に取り込まれる。アナログ音声データ６０１は、音声入力部１１７によってデジタル化され、デジタル音声データ６０２に変換される。その後、ＶＡＤ判定部１３０によって有音か静音かが判定され、静音であれば、音声波形データから音声パワー値を計算し、データ量の削減を図る。有音データであれば圧縮部１３１によってデジタル音声データ６０２を圧縮し、圧縮音声データ６０３に変換する。なお、音声コーデックの種類によっては、ＶＡＤ判定部１３０などの処理が音声コーデックに組み込まれている場合もあるが、圧縮コーデックにＶＡＤ機能が組み込まれていたとしても特に問題にはならない。

このようにしてアナログ音声データ６０１は、圧縮音声データ６０３として送信可能な状態にデータが変換される。

実際の音声データの送信は、クライアント３００、４００、５００が接続された場合に行われる。ネットワーク２００を介してクライアント３００、４００、５００が接続すると、送信部１３２はクライアント３００、４００、５００からの音声送信要求を受け、これに対して圧縮音声データ６０３をクライアント３００、４００、５００へ送信することが可能となる。

次に、音声を受信するソフトウェア構成に関して説明する。音声の受信は、ネットワーク２００を介してクライアント３００、４００、５００が接続し、音声を受信部１３３で受けることで開始される。

カメラサーバ１００は、接続してきたクライアント３００、４００、５００からの音声データの受信の許可不許可をスピーカー占有権管理部１３４によって判断する。このとき、スピーカー占有権管理部１３４はスピーカー占有権データ６１２に状態を保持することでスピーカー１０２への音声出力を制御する。

このような処理によって許可を受けたクライアント３００、４００、５００から圧縮音声データ６１１を受信する。受信した圧縮音声データ６１１は、解凍部１３５によってデコード処理が行われる。このような処理の過程で静音データは、ＣＮＧ発声部１３６によって音波形データであるデジタル音声データ６１３に変換される。

このように生成されたデジタル音声データ６１３は、一次蓄積部１３７に蓄積される。この一次蓄積部１３７は、キュー構造（ＦＩＦＯ）のデータの蓄積が可能であり、音声データの再生スピードと、通信によって得られる音声データの受信スピードの揺らぎを調整するためのバッファである。

また、複数のクライアントからの音声受信を許可しているのであれば、この時点でミキシング部１３８によって音声のミキシングを行う。最終的に、音声出力部１１８によってデジタル音声データ６１３が、アナログ音声データ６１４に変換され、スピーカー１０２に出力される。

図５は、クライアントのソフトウェア構成に関して説明をした図である。図３と同様に、ここでは便宜上クライアント３００に関して説明するが、クライアント４００及び５００も同様の構成を有する。

クライアント３００の音声送信に関連するソフトウェアの構成は、カメラサーバ１００と同様に、大きくわけて２つの音声データの流れに対応するものに分かれる。１つは音声を送信する音声データの流れに対応するもので、もう１つは音声を受信する音声データの流れに対応するものである。

まず、音声の送信に関するソフトウェア構成に関して説明する。

音声信号は、マイク３０３によってアナログ音声データ７０１としてクライアント３００に取り込まれる。アナログ音声データ７０１は、音声入力部３１６によってデジタル化され、デジタル音声データ７０２に変換される。その後、ＶＡＤ判定部３３０によって有音か静音かが判定され、静音であれば、音声波形データから音声パワー値を計算し、データ量の削減を図る。有音データであれば圧縮部３３１によってデジタル音声データ７０２を圧縮し、圧縮音声データ７０３に変換する。なお、音声コーデックの種類によっては、ＶＡＤ判定部３３０などの処理が音声コーデックに組み込まれている場合もあるが、圧縮コーデックにＶＡＤ機能が取り込まれていたとしても特に問題にはならない。

このようにしてアナログ音声データ７０１は、圧縮音声データ７０３として送信可能な状態にデータが変換される。

実際の音声データの送信は、カメラサーバ１００に接続した場合に行われ、スピーカー占有権取得部３３２によって、接続後にカメラサーバ１００のスピーカー占有権取得を促し、スピーカー占有権取得要求の送受信や音声送信を行う。

クライアント３００からカメラサーバ１００への音声送信では、カメラサーバ１００の１つのスピーカー１０２を他のクライアント装置と共同して使用する必要が生じる。このときのカメラサーバ１００が管理するスピーカー１０２を使用する権利をカメラサーバ１００から取得する必要がある。このためにスピーカー占有権取得を判断するソフトウェアとしてスピーカー占有権取得部３３２を設け、圧縮音声データ７０３の送信の可否を判断する。スピーカー占有権取得部３３２はカメラサーバ１００のスピーカー占有権の状態等をスピーカー制御権データ７０４として保持することでこれを可能としている。

なお、クライアント３００における音声を受信するためのソフトウェア構成は、図４に示すカメラサーバ１００のものと同様であるため説明を省略する。ただし、クライアント３００においては、ミキシング部３３８は無くても構わない。

以上のようなソフトウェア構成によって、カメラサーバ１００とクライアント３００、４００、５００間で音声データの送受信が行われる。

次に、図６を参照して、クライアント３００〜５００上で表示されるソフトウェアグラフィカルユーザーインターフス（ＧＵＩ）について説明する。なお、以下の説明では、クライアント３００として説明するが、クライアント４００、５００においても同様のＧＵＩが用いられる。

図６において、９００はＧＵＩ画面であり、カメラサーバ１００から配信された画像を表示するための表示窓９０１、パン制御スライドバー９０２、チルト制御スライドバー９０３、ズーム制御スライドバー９０４、カメラ制御権取得ボタン９０５を含む。

これらの構成要素はカメラ制御を行う目的で配置されており、パン制御スライドバー９０２、チルト制御スライドバー９０３、ズーム制御スライドバー９０４を操作することで、カメラサーバ１００のカメラ部１１４の方向の制御を行うことができる。

また、カメラ制御権取得ボタン９０５を操作することによって、カメラ部１１４のパン・チルト・ズーム動作の制御を占有する権利を取得することができる。この制御権取得ボタン９０５は、１つのカメラサーバ１００のカメラ制御のリソースを多数のクライアントから同時にアクセスされる場合に、カメラ制御の混乱を避け、特定の１クライアントのみに制御を許可する仕組みである。なお、図６に示す例では、このカメラ制御権取得ボタン９０５をスピーカー占有権を取得するためのボタンとしても用いる場合を示しており、このような構成では、カメラ制御権を取得したクライアント装置に対して、スピーカー占有権を与えるようにしても良い。

更に、音声用ＧＵＩの構成要素として、音声出力レベルゲージ９０６、音声入力レベルゲージ９０７、クライアント３００の音声入力を中止するミュートボタン９０８、クライアント３００のスピーカー３０４への音声出力を中止するミュートボタン９０９がある。音声出力レベルゲージ９０６、音声入力レベルゲージ９０７のゲージによって音声の入出力状態を確認することができる。なお、これらのゲージは、特にゲージの形で表示する必要はなく、例えば、音声の大きさを示すアイコンやアニメーション、文字情報などを用いて表現しても良い。

図７は、クライアント装置のソフトウェアのグラフィカルユーザーインターフェース（ＧＵＩ）の別の例を示す。なお、図６と同様の構成には同じ参照番号を付し、説明を省略する。

図６に示すＧＵＩとの差異点は、スピーカー占有権ボタン９２０が追加されている点にある。つまり、カメラサーバ１００が、カメラ制御権とスピーカー占有権を別々に設定することが可能な場合のＧＵＩである。このようなスピーカー占有権ボタン９２０の追加によって、カメラ制御に関する占有クライアントとスピーカーに関する占有クライアントを別々に運用することが可能になる。

図８は、クライアント装置のソフトウェアＧＵＩのダイアログ１００１を示している。

ダイアログ１００１は、図６や図７のウィンドウからメニューなどを通して使用することが可能になる。しかしながら、図６及び図７に示すＧＵＩと別ウィンドウになっていなくても良い。

ダイアログ１００１は主に、音声再生や音声録音の強さを調整すると同時に、ＶＡＤ機能（無音検出機能）のための設定を行うＧＵＩを提供している。

図８において、１００２はクライアント３００の音声再生音量を制御する再生音量制御スライドバー、１００３はカメラサーバ１００からの音声の入力音量を調整する入力音量制御スライドバーである。各スライドバーの隣には、音量の大きさを示すレベルゲージが表示される。

また、１００４及び１００５は、ＶＡＤ機能に関するパラメータでＶＡＤの判定の強弱を示す値を設定する場合に用いるスライドバーである。ＶＡＤの判定では、強弱に関しては閾値以下の音声出力で、かつ所定時間以上継続した場合無音と判定するので、スライドバー１００４は閾値を、スライドバー１００５は継続時間を調節するために用いる。

図９は、クライアント３００のソフトウェアＧＵＩのダイアログ１０１１を示す図である。ダイアログ１０１１も図８のダイアログと同様に、図６や図７のウィンドウからメニューを通して使用することが可能になる。しかしながら、図６及び図７に示すＧＵＩと別ウィンドウになっている必要はなく、同一ウィンドウ上に表示しても構わない。

このダイアログ１０１１は主に、ネットワーク帯域の制限に関わる値を設定することを目的としている。１０１３は画像帯域調整を行うためのスライドバー、１０１２はその画像通信で使用している使用帯域を示すゲージ及び数値である。また、１０１５は音声帯域調整を行うためのスライドバー、１０１４はその音声通信で使用している使用帯域を示すゲージ及び数値である。

このように画像と音声に関しては、使用帯域を変動させることが可能である。特に、画像通信用の使用帯域は容量が多いため、帯域を使い切ってしまうと音声配信に影響が出てしまう。そのため、これらの調整機能によって、その問題を解決することができる。

図１０は、クライアント３００のソフトウェアＧＵＩのダイアログ１０２１を示している。このダイアログ１０２１は、音声監視機能によるＧＵＩであり、ＶＡＤ機能を用いて実現可能である。

ＶＡＤ機能の閾値の与え方で、静音を判断することが可能であると同時に、ある一定以上の音量の判断を行うことも可能である。そこで、ある一定以上の音量が音声入力部３１６に入力された場合に、異常を通知するダイアログ１０２１を表示させるようにすることができる。この機能は、カメラサーバ１００の入力音声音量や、クライアント装置の出力音量がミュートの状態であっても表示される。この機能によって、オペレータは、ある一定以上の音量の発生を視覚的に監視することが可能となる。

図１１は、クライアント装置のソフトウェアのＧＵＩの音声情報表示機能に関して説明する図である。なお、図６と同様の構成には同じ参照番号を付し、説明を省略する。

音声情報表示機能とは、カメラサーバ１００に入力している音量や、出力している音量についての情報をＧＵＩ画面上に表示する機能である。図１１では、文字列１０３１がその情報を表示している。カメラサーバ１００の音声出力は、カメラサーバ１００が遠隔地にあり、実際に出力している音が聞こえないため、仮に大音量であってもクライアント装置を操作するオペレータには分からない場合がある。

また、カメラサーバ１００からの音声入力をされていても、ミュートボタン９０９によりクライアント３００でスピーカー３０４による音声出力がミュートされている場合には、クライアント３００を操作するオペレータには、カメラサーバ１００の音声入力がミュートになっているのか、クライアント３００の音声出力がミュートになっているのか、瞬間の判断が難しい。

そこで、カメラサーバ１００の音声の入力や再生状態を表示させることによって、クライアント３００を操作するオペレータが視覚的に認識できるようにすることができる。

図１２〜図１５は、スピーカー占有権の付与の仕方の方式について、その方式の動作シーケンスを示す図である。

スピーカー占有権とは、上述したように、カメラサーバ１００に接続されるスピーカー１０２の占有権のことを示している。複数のクライアント３００〜５００からの音声データを同時に再生すると、音声再生の競合が発生してしまう。場合によってはミキシングを許可することも有効であるが、逆に、これが不都合になってしまう場合もある。

そのため、本実施の形態ではスピーカー占有権という概念を導入し、カメラサーバ１００に接続されるスピーカー１０２の占有関係をクリアにし、多数のクライアント装置からの音声データを排他的に再生する方式について説明する。

スピーカー占有権は、様々な方式を取ることができ、本実施の形態のシステムを使う人のニーズによって切り替えることが可能である。ここでは例として、４方式を説明をする。

図１２はＡ方式の動作シーケンスを示す図で、早いもの勝ちでスピーカー占有権を取得する方式を示す。カメラサーバ１００にクライアント３００、４００、５００が接続を行う場合に、最初にスピーカー占有権を要求したクライアントにスピーカー占有権が付与される。

クライアント３００がスピーカー占有権を要求した時（Ｓ１）、スピーカー占有権が他のクライアントに付与されていなければ、カメラサーバ１００はクライアント３００にスピーカー占有権を付与する（Ｓ２）。これにより、クライアント３００がスピーカー占有権を保有することになるが、クライアント３００がスピーカー占有権を保有している間にクライアント４００がスピーカー占有権を要求すると（Ｓ３）、まだクライアント３００にスピーカー占有権が付与されている状態であるために、カメラサーバ１００はクライアント４００に対してスピーカーの占有権の要求の失敗を通知する（Ｓ４）。

次に、クライアント３００がスピーカー占有権の終了を要求し（Ｓ５）、カメラサーバ１００はこれを受け付けて、スピーカー占有権の終了を通知する（Ｓ６）。これにより、スピーカー占有権がどのクライアントにも付与されていない状態となる。このタイミングでクライアント５００がスピーカー占有権の取得を要求すると（Ｓ７）、カメラサーバ１００はクライアント５００にスピーカー占有権を付与する（Ｓ８）。以下、新たにスピーカー占有権が要求される度に、同様の制御を行う。

図１３はＢ方式の動作シーケンスを示す図で、最後にスピーカー占有権を要求したクライアント装置にスピーカー占有権を付与する方式を示している。

まず、クライアント３００がカメラサーバ１００にスピーカー占有権を要求する（Ｓ１１）。スピーカー占有権が他のクライアントに付与されていなければ、カメラサーバ１００は、すぐにスピーカー占有権をクライアント装置３００に付与する（Ｓ１２）。

しかし、この後で、クライアント４００がスピーカー占有権をカメラサーバ１００に要求すると（Ｓ１３）、カメラサーバ１００は、スピーカー占有権の終了をクライアント装置３００に通知し（Ｓ１４）、クライアント４００にスピーカー占有権を与える（Ｓ１５）。この後、更にクライアント５００がスピーカー占有権を要求すると（Ｓ１６）、同様にしてカメラサーバ１００はスピーカー占有権の終了をクライアント装置４００に通知し（Ｓ１７）、クライアント５００にスピーカー占有権を与える（Ｓ１８）。以下、新たにスピーカー占有権が要求される度に、同様の制御を行う。

図１４はＣ方式の動作シーケンスを示す図で、ユーザーレベルによってスピーカー占有権を取得する方式を示している。なお、基本的な動作はＡ方式と同様で、先にスピーカー占有権を要求したクライアントにスピーカー占有権が付与されるものとする。

まず、低レベルのクライアント３００がカメラサーバ１００にスピーカー占有権を要求する（Ｓ２１）。スピーカー占有権が他のクライアントに付与されていなければ、カメラサーバ１００は、すぐにスピーカー占有権をクライアント装置３００に付与する（Ｓ２２）。

クライアント３００にスピーカー占有権を付与後、クライアント３００と同じ低レベルのクライアント４００がスピーカー占有権の要求をした場合（Ｓ２３）、スピーカー占有権の取得を拒否する（Ｓ２４）。しかし、クライアント３００よりもレベルが高いクライアント５００がスピーカー占有権を要求すると（Ｓ２５）、クライアント３００へのスピーカー占有権の付与を終了し（Ｓ２６）、クライアント５００に対してスピーカー占有権を付与する（Ｓ２７）。

このようにユーザーレベルの高いクライアント装置に優先的にスピーカー占有権を与える方式も実施することが可能である。

図１５はＤ方式の動作シーケンスを示す図で、一定の時間によってスピーカー占有権を終了する方式である。Ａ方式の場合、他のクライントがスピーカー占有権を保有していると、新たにスピーカー占有権を要求したクライアントはスピーカー占有権を取得できずエラーとなるが、Ｄ方式は、このような要求をキューに貯め、一定時間後に、スピーカー占有権を次にスピーカー占有権を要求したクライアント装置に付与する。

まず、クライアント３００がカメラサーバ１００にスピーカー占有権を要求する（Ｓ３１）。スピーカー占有権が他のクライアントに付与されていなければ、カメラサーバ１００は、すぐにスピーカー占有権をクライアント装置３００に付与する（Ｓ３２）。

次に、クライアント４００がカメラサーバ１００にスピーカー占有権を要求すると（Ｓ３３）、カメラサーバ１００はスピーカー占有権が他のクライアントに付与されているかどうかを判断する。この場合はクライアント３００に付与されているので、クライアント４００をスピーカー占有権待ちのキューに追加する（Ｓ３４）。その後、クライアント５００がスピーカー占有権を要求した場合にも（Ｓ３５）、同様にキューに追加する（Ｓ３６）。

そして、クライアント３００にスピーカー占有権を付与してから所定時間が経過すると、カメラサーバ１００はクライアント３００にスピーカー占有権の終了を通知し（Ｓ３７）、クライアント４００にスピーカー占有権を付与し（Ｓ３８）、クライアント４００をスピーカー占有権待ちのキューから削除する（Ｓ３９）。同様に、クライアント４００にスピーカー占有権を付与してから所定時間経過するとスピーカー占有権の終了を通知し（Ｓ４０）、クライアント５００にスピーカー占有権を付与し（Ｓ４１）、クライアント４００をスピーカー占有権待ちのキューから削除する（Ｓ４２）。そして、所定時間経過後に、クライアント５００のスピーカー占有権を終了する（Ｓ４３）。

このように一定の時間によってスピーカー占有権の付与先を変更することによって、複数のクライアント装置が競合することなくスピーカーの使用が可能になる。

なお、本実施の形態では、スピーカー占有権を１つのクライアントに付与する場合について説明をしたが、これに限るものではなく所定数の複数のスピーカー占有権を用意し、複数のクライアント装置に同時に付与しても構わない。このような場合、同時に発生された音声データをミキシングしたり、カメラサーバ１００に複数のスピーカーを接続できる構成にして、それぞれのクライアントから受信した音声をそれぞれ再生するようにすることも可能である。

更に、スピーカー占有権の付与方法は、上記Ａ方式、Ｂ方式、Ｃ方式、Ｄ方式を組み合わせた方法であっても構わない。例えば、基本的にＤ方式でスピーカー占有権を制御し、ユーザーレベルが高いクライアント装置が接続した場合はＣ方式に従って付与するというように制御したり、スピーカー占有権を有するクライアント装置が所定時間経過前にスピーカー占有権の終了を要求した場合に、キューの次のクライアント装置にスピーカー占有権を付与するというように、組み合わせて制御することができる。

図１６は、画像データと音声データの同期に関して説明した図である。

カメラサーバ１００は、映像と音声のデジタル化を行って、画像データと音声データをネットワーク２００に配信している。一方、クライアント３００〜５００は、配信されたデータを受信している。本実施の形態では、このデータの送受信に関して２つの論理的接続を行っている。１つが画像データの送信を行う論理的接続であり、もう１つが音声データの送受信を行う論理的接続である。この際に、２種類のデータである画像データと音声データは、フレーム毎のタイムスタンプによって時間の同期性を保証している。

なお、本実施の形態では２つの論理的接続によって説明をしているが、１つの論理的接続で画像データと音声データの送受信を行っても構わない。

図１６において、（ａ）は画像データを各フレーム（一定時間）毎に概念的に示す図、また（ｂ）は音声データを映像の各フレーム（一定時間）毎に概念的に示す図である。画像データ及び音声データいずれにも、最初のフレームにはタイムスタンプ00:00が付与されており、これを受信したクライアント３００〜５００は、この時間情報を元にして画像データと音声データの同期をとって再生を行う。

図１７は、音声送信用パケットの詳細構成図である。

この通信パケットは、カメラサーバ１００からクライアント３００〜５００への音声通信や、クライアント３００〜５００からカメラサーバ１００への音声通信などに使用することができる。全てのパケットは、パケットの長さのフィールド（Packet Size）とパケットの種類を示すフィールド（id）を共通して有する。

図１７において、通信結果通知パケットは、それぞれの通信処理を行っている際に発生するエラーなどの状態を送信するためのパケット、有音パケットは有音音声データであって、圧縮された音声データである。有音パケットにはタイムスタンプも付加されている。静音パケットは静音音声データであって、音声の強さを示す値とタイムスタンプが付加されている。以下、有音パケット及び静音パケットであって、種類を区別しない場合には、音声パケットと呼ぶ。基準時間通知パケットは、有音パケット及び静音パケットの基準時間を示すパケットである。基準時間からの差異情報だけを有音パケット及び静音パケットが扱うことによって通信負荷を低減させている。

また、コーデック情報パケットは、音声パケットで使用される音声コーデックを示している。使用可能コーデックパケットは、音声コーデックが複数使用できる場合、その情報を伝えるためのパケットである。コネクションＩＤ通知パケットは、HTTPの通信におけるセッションを維持する目的で使用される値であり、この値の継続性で、ステートレスなHTTPにセッション管理機能を与える。なお、この動作に関しては後述する。プロトコルバージョン通知パケットは、将来プロトコルが変更になった場合にそれを判断するためのパケットである。

上述した音声送受信用パケットを用いて実際に音声の配信を可能としている。

図１８は、音声操作用のパケットの詳細説明図である。図１７のパケットと図１８のパケットは組み合わせて動作する。

図１８において、サーバスピーカーコントロールパケットは、カメラサーバ１００の音声出力レベルを調整するためのパケット、サーバマイクコントロールパケットは、カメラサーバ１００の音声入力レベルを調整するためのパケット、ＶＡＤ機能on-off機能パケットは、ＶＡＤ機能自体を使用せず、全て有音パケットとして音声を配信したい場合に使用するパケットである。また、ＶＡＤの強さ設定パケットは、無音判定に用いる音声出力の閾値を設定するためのパケット、ＶＡＤの継続時間パケットは無音判定に用いる無音の継続時間の閾値を設定するためのパケット、プリセット音声再生パケットは予め蓄積された音声データの出力を指示するためのパケットである。

カメラサーバ１００とクライアント３００〜５００装置は、これらの通信パケットを相互に通信することで、音声の送受信を実現している。

図１９は、カメラサーバ１００からクライアント３００へのHTTPによる音声配信方式について説明するためのシーケンス図、図２０は、クライアント３００からカメラサーバ１００へのHTTPによる音声配送方式について説明するためのシーケンス図である。なお、代表的にクライアント３００を例として説明するが、他のクライアントについても同様に実施される。

この両者の違いは、カメラサーバ１００→クライアント３００方向の通信であるか、クライアント３００→カメラサーバ１００方向の通信であるかの差であるが、HTTPで音声再生をするには、二つの通信方式を導入する必要がある。

カメラサーバ１００→クライアント３００方向の通信は、図１９に示すように１回のGETを行うことによって可能となる。まず、クライアント３００からGETメソッドが送信される（Ｓ１０１）。このメソッドをカメラサーバ１００が受信し、このメソッドの返答としてリザルトコードを返信する（Ｓ１０２）。その後、HTTPの返答のペイロード部分（Ｓ１０３）にて、音声配送にかかわる基準時間通知パケットや音声パケットの送信を連続して行う。

クライアント３００は、リザルトコードを受信すると、以降、HTTPのペイロード部分に含まれる音声パケットを受信し、再生を続ける。

このような動作によって、カメラサーバ１００→クライアント３００方向の音声配送が可能となる。

一方、クライアント３００→カメラサーバ１００の通信は、複雑であり、複数回のPOSTによって行われる。クライアント３００からPOSTメソッドが送られる（Ｓ１１０）。そして、POSTメソッドのアップロードするペイロード部分に、音声関連パケット（基準時間通知パケット、音声パケット）などを付加してPOSTメソッドを実行する（Ｓ１１１）。

これによって、カメラサーバ１００は、POSTメソッドを受信し、以降、音声関連パケットをPOSTメソッドのペイロード部分として受け取る。

もし、このクライアント３００からの音声配送が正常で、且つ、クライアント３００がスピーカー占有権を取得できたのであれば、これらの音声パケットは、カメラサーバ１００で再生される。

そして、POSTメソッドのリザルトコードが送信される（Ｓ１１２）と同時に、ペイロード部分にて、コネクションIDパケットがクライアントに送信される（Ｓ１１３）。

クライアント３００は送信されたリザルトコードを受信し、正常にスピーカー占有権の取得ができ、音声配送が正常であることが確認できると、受信されたコネクションIDパケットを次のPOSTメソッドに付加し（Ｓ１１４）、更に、音声パケットをペイロード部分に入れてカメラサーバ１００にアップロードする（Ｓ１１５）。

このコネクションＩＤは、一連の音声ストリーム配信の流れで常に同じである必要はない。Ｓ１１３で送信されるコネクションIDと、Ｓ１１７で送信されるコネクションIDは、異なる値でもよい。その場合、クライアント３００は、直前のリザルトコードで通知されたコネクションＩＤを次のＨＴＴＰメソッドコールで用いる必要がある。こうしたコネクションＩＤを用いて、音声ストリームをクライアント３００からカメラサーバ１００へ送信する他の方法としては、接続するクライアントごとにコネクションＩＤを発行し、クライアントは一連の音声ストリーム送信中は常に同じコネクションＩＤを用いる方法がある。この方法では、カメラサーバ１００で接続クライアントの数分のコネクションＩＤを管理する必要があるのに比べ、本実施の形態の方法では、カメラサーバ１００は最後に発行した最新のＩＤを１つだけ管理すればよいため、カメラサーバ１００における処理の負担が軽くなる。

カメラサーバ１００は、Ｓ１１４で送られたPOSTメソッドを受信し、そのペイロード部分で、音声パケットを受信し（Ｓ１１５）、音声を再生する。

このような動作が、以降繰り返されることによって、クライアント３００→カメラサーバ１００方向の音声通信が行われる。

このような通信は、HTTPのPOSTのペイロードの大きさを後述するように400msec程度にしているためであり、１回のPOSTの応答時間よりも短ければ、問題なく音声再生を行うことができる。また、最初のPOSTメソッド（Ｓ１１０）にて音声パケットを付加して送っている（Ｓ１１１）。

このPOSTメソッドを受信後、カメラサーバ１００は、正当に接続可能なクライアントであるかどうか、スピーカー占有権の取得が可能かを判断する。そのため、場合によっては、Ｓ１１１で送られた音声パケットは再生されず廃棄されてしまう可能性がある。にもかかわらず、最初のメソッドで音声パケットを付加して送るのは、音声配送にかかわる通信量の低減が図れるためである。これ以外の方法として、最初に音声配信を行う正当性を判断するためのいくつかのHTTPメソッドをカメラサーバ１００とクライアント３００の間でやりとりし、正当性の確認後、音声配信を開始する方法が考えられる。しかし、正当性判断のやりとりの分（実測では約１０msec程度）音声を再生するまでの時間がかかってしまう。そのため最低限度HTTPの通信によって認証と音声配信を可能とする方法を両立した結果が本実施の形態の方式となる。

また、本実施の形態ではペイロードサイズを400[msec]程度としている。これは、上述のように認証を行う上で、捨てられてしまう音声パケットが発生することがあるが、もしＳ１１１で送る音声パケットが非常に大きい場合に、その音声パケットを送りきった後のリザルトコード（Ｓ１１２）でしか、クライアント装置の認証結果が分からないためである。

さらに、HTTP/1.0の規約に従えば、クライアント３００からの送信の途中にカメラサーバ１００がリザルトコードを送信することができず、また、途中で切断することもできない。逆に、もしこの音声パケットが非常に小さいと、音声パケットを付加したPOSTメソッドを何回も送らねばならず、ＨＴＴＰのヘッダ情報等を含め、通信量が多くなってしまう。

以上のような動作によって、HTTPを用いて、カメラサーバ１００→クライアント３００方向とクライアント１００→カメラサーバ３００方向の音声通信を実現している。

図２１は、クライアント３００の音声バッファの制御に関して説明した図である。このような動作は、他のクライアント４００、５００及びカメラサーバ１００でも同様に行われるが、本実施の形態では、クライアント３００の内部動作についてのみ説明する。

受信された音声データは、図２１（ａ）に示すように音声バッファ（図５の一次蓄積部３３７）にFIFO構造で受信される。再生速度に対して、データ送信量が非常に大きいと、音声再生スピードがデータ通信スピードに追いつかず、この音声バッファに音声データがバッファリングされることによって、音声再生されるまでに遅延が生じてしまう。この状態が、図２１（ｂ）に示される状態である。

これを避ける為に、ある程度のバッファ許容量閾値を超えて音声データがバッファリングされた場合、音声バッファの音声パケットの縮小化を行う動作を実施する。

このとき、音声バッファに溜まっている音声データの内、静音データは、比較的人間の耳には、小さい音である場合が多く、これを省いても違和感が比較的少ない。そこで、バッファ許容量閾値を超えた場合は、静音パケットの削除を行う。こうして、音声バッファを更新したものが図２１（ｃ）に示されている。

このような動作によって音声バッファ量は常に削減され、人間の耳にとって意味のある有音パケットを優先的に再生することが可能になる。

図２２は、カメラサーバ１００において実施される音声のミキシングの動作について説明した図である。音声のミキシング動作は、音声バッファ（例えば、図２の外部記憶部１１２を利用）によって行われている。

ここでは音声バッファの初期状態は、図２２（ａ）に示す状態であるものとする。この状態で、図２２（ｂ）に示すように別のクライアントから送信された音声データを受信した場合、有音パケットや静音パケットに記録されているタイムスタンプを元にして、受信した時点で音声バッファに存在している音声パケットの音声とのミキシングを行う。

このような処理によって図２２（ｃ）に示すように、音声バッファは、追加された有音パケットや静音パケットが合成された形で、音声バッファに記録される。

このような動作を実施することで、複数のクライアントからの音声をミキシングし、再生することが可能となる。

次に、図２３〜図３０のフローチャートを参照して、カメラサーバ１００のソフトウェアの処理について説明する。

図２３は、カメラサーバ１００の全体の処理の流れを示すフローチャートである。

カメラサーバ１００の電源がＯＮするなどして処理が開始されると、カメラサーバ１００のソフトウエア全体の初期化を行う（ステップＳ１００１）。次に、音声関連のスレッドの起動を行う（ステップＳ１００２）。この音声関連のスレッドは、音声入力部１１７及び音声出力部１１８において実施される。なお、これらの音声関連スレッドの処理の詳細については後述する。

次に、ネットワーク接続を待つ（ステップＳ１００３）。ネットワーク２００からの接続があれば（ステップＳ１００４でＹＥＳ）、通信スレッドを立ち上げる（ステップＳ１００５）。通信スレッドは、ネットワーク接続１回につき１回立ち上げる。通信スレッドの処理の詳細については後述する。

着信が無い場合には（ステップＳ１００５でＮＯ）、ユーザーが終了を指示するなどによりカメラサーバ１００の処理を終了するのかどうかを判定し（ステップＳ１００６）、終了しないのであればステップＳ１００３へ戻って再び接続を待つ。

また、終了するのであれば、終了処理（通信の切断、他スレッドへの終了の指示、他スレッドの動作の停止を待つ処理、リソースやメモリの開放など）を行った後に（ステップＳ１００７）、カメラサーバ１００の処理を終了する。

次に、ステップＳ１００２で音声スレッドが立ち上げられた後に音声入力部１１７及び音声出力部１１８で行う処理について、図２４及び図２５をそれぞれ参照して説明する。

図２４において、音声入力部１１７が起動すると（ステップＳ１０１０）、まず、音声入力部１１７の初期化を行う（ステップＳ１０１１）。この処理により音声のデジタル化ができる状態になる。そして、ステップＳ１０１２〜Ｓ１０１４の音声入力ループが行われる。

音声入力ループは、カメラサーバ１００が停止の指示を受けるまで続けられ、音声の入力をフレーム単位で行って音声バッファ（例えば、図２の外部記憶部１１２を利用）に音声データを格納する。このループでは、まず、音声データのキャプチャを行う（ステップＳ１０１２）。キャプチャ単位は、本実施の形態では10[msec]を１フレーム単位としているが、可変サイズであっても構わない。次にこのフレーム毎に入力された音声データを音声録音バッファに格納する（ステップＳ１０１３）。

音声バッファは、１つの装置に２つ存在している。１つは音声録音バッファであり、入力した音声を一時的に蓄積するFIFOバッファである。もう一つは音声再生バッファであり、出力する音声を一時的に蓄積するFIFOバッファである。

このようにして、音声入力ループは、ステップＳ１０１４でユーザーの終了指示があったと判定されるまで続けられる。そして、ユーザーの終了指示をステップＳ１０１４で検知すると、ステップＳ１０１５で音声入力部１１７を停止するなどの必要な終了処理を行ってから、実際に処理を終了する。

一方、図２５において、音声出力部１１８が起動すると（ステップＳ１０２０）、まず、音声出力部１１８の初期化を行う（ステップＳ１０２１）。この初期化では、音声が直ぐに再生できるように外部記憶部１１２の設定を行う。そして、ステップＳ１０２２〜Ｓ１０２８の音声出力ループが行われる。

まず、音声のミキシングを行うかどうかを判断する（ステップＳ１０２２）。ミキシングを行うのであれば（ステップＳ１０２２でＹＥＳ）、ステップＳ１０２３で音声再生バッファ（例えば、図２の外部記憶部１１２を利用）に溜まった音声データのミキシング処理を実施する。ここでは、図２２を参照して上述した方法で実施される。

次に音声再生バッファ量が一定量を超えているかを判断する（ステップＳ１０２４）。音声再生バッファ量が一定量を超えている場合は（ステップＳ１０２４でＹＥＳ）、ステップＳ１０２５で静音データの削減を実施してバッファ量を減らす。ここでは、図２１を参照して上述した方法で実施される。

そして、ステップＳ１０２６にて音声再生バッファから再生すべき音声データを１フレーム分取り出す。なお、本実施の形態では、１フレームあたり10[msec]として処理をしているが、このサイズは可変であっても構わない。そして、ステップＳ１０２７にて、取り出した音声データの再生を行う。音声データの再生は、音声出力部１１８に音声データを渡すことで、スピーカー１０２により実施される。

そして、ステップＳ１０２８にて、ユーザーが終了を指示しているかどうかを判定し、終了を指示していなければ（ステップＳ１０２８でＮＯ）、ステップＳ１０２２へ戻り、ユーザーが終了を指示していれば（ステップＳ１０２８でＹＥＳ）、ステップＳ１０２９で終了処理を行う。この終了処理では、音声出力部１１８の終了処理などを実施する。

次に、図２３のステップＳ１００５で立ち上げれられた通信スレッドの処理について、図２６を参照して説明する。なお起動された送信部１３２及び受信部１３３は、HTTP通信を処理するために実行される。

ステップＳ１０３１にてHTTPメソッドの受信を待つ。そして、クライアントからのHTTPメソッドを受信すると、ステップＳ１０３２においてHTTPパスによるコマンドの分析を行う。クライアントからの音声送信要求であれば、ステップＳ１０３３に進んで音声送信処理を行い、音声受信要求であれば、ステップＳ１０３４で音声受信処理を行う。ステップＳ１０３３及びＳ１０３４で行う処理については、図２７、図２８を参照して後述する。

ステップＳ１０３３またはステップＳ１０３４の処理が終了したのちに、ステップＳ１０３５で通信の終了、もしくは、ユーザーの終了の指示があるかどうかを判断し、通信続行と判断された場合は（ステップＳ１０３５でＮＯ）、ステップＳ１０３１に戻って再びHTTPのメソッドの受信を待ち、終了であれば、ステップＳ１０３６にて通信終了処理を行ってから、処理を終了させる。

次に、図２６のステップＳ１０３３で行う音声送信処理について図２７を参照して説明する。

図２６のステップＳ１０３２で受信したコマンドが音声送信要求であると判断されると、ステップＳ１０３３で図２７に示すサブルーチンがコールされる。

ステップＳ１０４１においてHTTPのリザルトコードをクライアントに送信し、ステップＳ１０４２において音声録音バッファから１フレーム分の音声データを読み込む。そして、ＶＡＤ判定処理を行い（ステップＳ１０４３）、このＶＡＤ判定処理の結果を判断する（ステップＳ１０４４）。

ＶＡＤ判定結果、有音の場合には音声データを圧縮し（ステップＳ１０４６）、有音パケットを作成する（ステップＳ１０４７）。一方、静音であると判定された場合、静音パケットを作成する（ステップＳ１０４５）。そして、このようにして作成された有音パケットもしくは静音パケットを、ネットワーク２００へ送信する（ステップＳ１０４８）。

更に、カメラサーバ１００の内部ステータス（時間など）をチェックし、クライアントが必要とした情報が存在する場合は（ステップＳ１０４９でＹＥＳ）、クライアントへのデータ送信パケットを作成し（ステップＳ１０５０）、ネットワーク２００へ情報パケットを送信する（ステップＳ１０５１）。

ステップＳ１０５２では、ユーザーからの終了指示があるかどうかを判断し、無ければ（ステップＳ１０５２でＮＯ）、ステップＳ１０４２に戻って上述した音声送信処理を続ける。一方、ユーザーからの終了指示がある場合は（ステップＳ１０５２でＹＥＳ）、このサブルーチンを終了し、図２６の処理に戻る。

次に、図２６のステップＳ１０３４で行う音声受信処理について図２８を参照して説明する。

図２６のステップＳ１０３２で受信したコマンドが音声受信要求であると判断されると、ステップＳ１０３４で図２８に示すサブルーチンがコールされる。

ステップＳ１０６１においてHTTPのリザルトコードをクライアントに送信し、ステップＳ１０６２において、スピーカー占有権管理部１３４を呼び出し、図１２〜図１５を参照して上述したスピーカー占有権管理処理を実施して、接続したクライアントがスピーカー占有権を保持しているかどうか判断を行う（ステップＳ１０６３）。

音声受信要求を送信したクライアントがスピーカー占有権を保持していない、または付与できない場合は、ステップＳ１０７０でスピーカー占有権の保持ができなかったことを伝えるパケットを作成し、ステップＳ１０７１でクライアントへ送信し、図２６の処理に戻る。

一方、スピーカー占有権を保持しるか、または付与可能である場合、ステップＳ１０６４で音声パケットの受信を待ち、クライアントから音声データを受信する。音声データを受信すると、受信した音声パケットの種類を判断する（ステップＳ１０６５）。有音パケットであればステップＳ１０６６で圧縮音声データを解凍し、音声再生バッファに音声データを格納する（ステップＳ１０６７）。

一方、静音パケットであればステップＳ１０６８でＣＮＧ波形作成を行い、この擬似音声波形のＣＮＧ波形データを音声再生バッファに格納する（ステップＳ１０６９）。

ステップＳ１０７２では、ユーザーからの終了指示があるかどうかを判断し、無ければ（ステップＳ１０７２でＮＯ）、ステップＳ１０６２に戻って上述した音声受信処理を続ける。一方、ユーザーからの終了指示がある場合は（ステップＳ１０７２でＹＥＳ）、このサブルーチンを終了し、図２６の処理に戻る。

次に、スピーカー占有権管理部１３４で行われる処理について、図２９及び図３０のフローチャートを参照して説明する。この処理は、図２８のステップＳ１０６２において呼び出される処理である。

上述したように、本実施の形態では２種類のスピーカー占有権制御方式を想定しており、１つはスピーカー占有権を単独で管理する場合、もう一つはスピーカー占有権がカメラ制御権と連動している場合である。

図２９はスピーカー占有権が独立している場合に行われ、ステップＳ１０８１〜Ｓ１０８５の処理で、スピーカー占有権の権利付与の条件を確認する。

具体的には、ステップＳ１０８１においてミキシングを行うか、ステップＳ１０８２ではスピーカー占有権を既に他のクライアントに付与していないか、ステップＳ１０８３ではスピーカー占有権を持っているクライアントか、ステップＳ１０８４では他のクライアントのスピーカー占有権保持期間が、一定時間以上経っているか、また、ステップＳ１０８５では現在スピーカー占有権を有しているクライアントよりも高いレベルのクライアントか、をそれぞれ判断する。いずれかでＹＥＳであればスピーカー占有権保持可能と判断し、ステップＳ１０８７の処理に移り、呼び出したクライアントにスピーカー占有権に与えるか、またはすでに保有している場合にはそのままスピーカー占有権を有効とし、更に、新たにスピーカー占有権を与えた場合には、スピーカ占有権の取得時間を記憶する。

また、ステップＳ１０８１でいずれもＮＯであれば、スピーカー占有権を付与できないと判断し、ステップＳ１０８６でスピーカー占有権失敗を通知する。

上記処理終了後、サブルーチンを終了し、図２８の処理に戻る。

次に、スピーカー占有権とカメラ制御権が連動している場合について、図３０のフローチャートを参照して説明する。

ステップＳ１０９１にて、この処理を呼び出したクライアントがカメラ制御権を保持しているかどうかを判定し、カメラ制御権を保持しているのであれば、ステップＳ１０９３でスピーカー占有権を要求したクライアントに与える。逆に、カメラ制御権を保持していないのであれば、ステップＳ１０９２で、スピーカー占有権を要求したクライアントにスピーカー占有権取得失敗を通知する。

上記処理後、サブルーチンを終了し、図２８の処理に戻る。

次に、図３１〜図３５のフローチャートを参照して、クライアント３００〜５００のソフトウェアの処理について説明する。

図３１は、クライアントの全体の流れを示すフローチャートである。クライアントの電源がＯＮされたり、ビューワが起動されるなどして処理が開始されると、クライアントのソフトウェア全体の初期化を行う（ステップＳ１１０１）。次に、接続先を指定するユーザーからの入力に基づいて、接続先を決定する（ステップＳ１１０２）。そして、音声関連のスレッドを起動する（ステップＳ１１０３）。この音声関連のスレッドは、それぞれ音声入力部３１６及び音声出力部３１７において実施される。なお、これらの音声関連スレッドの処理の詳細については後述する。

次に通信スレッドを立ち上げる（ステップＳ１１０４）。クライアントは、音声送信処理及び音声受信処理それぞれに対して通信スレッドを立ち上げる。なお、音声送信処理及び音声受信処理については、後述する。

そして、ステップＳ１１０５でユーザーの終了指示を待ち、終了が選択されると（ステップＳ１１０６でＹＥＳ）、ステップＳ１１０７で終了処理（通信の切断、他スレッドへの終了の指示、他スレッドの動作の停止を待つ処理、リソースやメモリの開放など）を行った後に、処理を終了する。

次に、ステップＳ１１０３で音声スレッドが立ち上げられた後に音声入力部３１６及び音声出力部３１７で行う処理について説明する。

図３２において、音声入力部３１６が起動すると（ステップＳ１１１０）、まず、音声入力部３１６の初期化を行う（ステップＳ１１１１）。この処理により音声のデジタル化ができる状態になる。そして、ステップＳ１１１２〜Ｓ１１１４の音声入力ループが行われる。

音声入力ループは、クライアントが停止の指示を受けるまで続けられ、音声の入力をフレーム単位で行って音声バッファ（例えば、図３の外部記憶部３１２を利用）に音声データを格納する。このループでは、まず、音声データのキャプチャを行う（ステップＳ１１１２）。キャプチャ単位は、本実施の形態では10[msec]を１フレーム単位としているが、可変サイズであっても構わない。次にこのフレーム毎に分けて入力された音声データを音声録音バッファに格納する（ステップＳ１１１３）。

音声バッファは、カメラサーバ１００と同様に１つの装置に２つ存在している。１つは音声録音バッファであり、入力した音声を一時的に蓄積するFIFOバッファである。もう一つは音声再生バッファであり、出力する音声を一時的に蓄積するFIFOバッファである。

このようにして、音声入力ループは、ステップＳ１１１４でユーザーの終了指示があったと判定されるまで続けられる。そして、ユーザーの終了指示をステップＳ１１１４で検知すると、ステップＳ１１１５で音声入力部３１６を停止するなどの必要な終了処理を行ってから、実際に処理を終了する。

一方、図３３において、音声出力部３１７が起動すると（ステップＳ１１２０）、まず、音声出力部３１７の初期化を行う（ステップＳ１１２１）。この初期化では、音声が直ぐに再生できるようにハードウェア装置の設定を行う。そして、ステップＳ１１２２〜Ｓ１１２６の音声出力ループが行われる。

まず、音声再生バッファ量が一定量を超えているかを判断する（ステップＳ１１２２）。音声再生バッファ量が一定量を超えている場合は（ステップＳ１１２２でＹＥＳ）、ステップＳ１１２３で静音データの削減を実施してバッファ量を減らす。ここでは、図２１を参照して上述した方法で実施される。

そして、ステップＳ１１２４にて音声再生バッファから再生すべき音声データを１フレーム分取り出す。なお、本実施の形態では、１フレームあたり10[msec]として処理をしているが、このサイズは可変であっても構わない。そして、ステップＳ１１２５にてこの音声データの再生を行う。音声データの再生は、音声出力部３１７に音声データを渡すことで、スピーカー３０４により実施される。

そして、ステップＳ１１２６にて、ユーザーが終了を指示しているかどうかを判定し、終了を指示していなければ（ステップＳ１１２６でＮＯ）、ステップＳ１１２２へ戻り、ユーザーが終了を指示していれば（ステップＳ１１２６でＹＥＳ）、ステップＳ１１２７で終了処理を行う。この終了処理では、音声出力部３１７の終了処理などを実施する。

次に、図３１のステップＳ１１０４で立ち上げれられた通信スレッドの処理について、音声送信処理を図３４、音声受信処理を図３５を参照して説明する。

まず、図３４を参照して、音声送信要求処理について説明する。なお、ステップＳ１１３６〜ステップＳ１１４６はカメラサーバ１００側の処理である。

ステップＳ１１３１において接続処理を行って、カメラサーバ１００と接続する。ステップＳ１１３２でこの接続が正常かどうかの判定を行い、接続の失敗であれば、ステップＳ１１４９に進んで終了処理を行う。一方、成功であれば、ステップＳ１１３３に進んで音声送信要求としてHTTPのPOSTメソッドを送信する。このメソッドの送信に問題があれば（ステップＳ１１３４でＹＥＳ）、ステップＳ１１４９に進んで終了処理を行う。問題なければ（ステップＳ１１３４でＮＯ）、ステップＳ１１３５でカメラサーバ１００からの応答からスピーカー占有権の確保ができたかどうかを判断する。確保できなければ、ステップＳ１１３１に戻ってもう１度スピーカー占有権の確保を行う。

一方、スピーカー占有権の確保が確認されると（ステップＳ１１３５でＹＥＳ）、音声録音バッファから１フレーム分の音声信号を読み出す（ステップＳ１１３６）、そして、ＶＡＤ判定処理を行い（ステップＳ１１３７）このＶＡＤ判定処理の結果を判断する（ステップＳ１１３８）。

ＶＡＤ判定結果、有音の場合には音声データを圧縮し（ステップＳ１１４０）、有音パケットを作成する（ステップＳ１１４１）。一方、静音であると判定された場合、静音パケットを作成する（ステップＳ１１３９）。そして、このようにして作成された有音パケットもしくは静音パケットを、ネットワーク２００へ送信する（ステップＳ１１４２）。

更に、カメラサーバ１００の内部ステータス（時間など）をチェックし、クライアントが必要とした情報が存在する場合は（ステップＳ１１４３でＹＥＳ）、クライアントへのデータ送信パケットを作成し（ステップＳ１１４４）、ネットワーク２００へ情報パケットを送信する（ステップＳ１１４５）。

次に、ステップＳ１１４６において、送信した音声情報パケットが一定以上のパケットサイズになったかどうかを判断する。HTTPのPOSTメソッドの長さを有限にする必要があるため、10パケット程度を1つのPOSTメソッドで処理するために行うループ処理である。このような段階を経て、音声データは、HTTPのPOSTメソッドによって送信される。一定以上のパケットサイズになると、POSTメソッドの返信として、ステップＳ１１４７でコネクションＩＤを受信し、次の接続のときにこのパラメータを使用する。

ステップＳ１１４８では、ユーザーからの終了指示があるかどうかを判断し、無ければ（ステップＳ１１４８でＮＯ）、ステップＳ１１３１に戻って上述した音声送信処理を続ける。一方、ユーザーからの終了指示がある場合は（ステップＳ１１４８でＹＥＳ）、ステップＳ１１４９で修了処理を行ってから、処理を終了する。

次に、図３５を参照して音声受信処理について説明する。

まず、ステップＳ１１５１において接続処理を行って、カメラサーバ１００に接続する。ステップＳ１１５２でこの接続が成功かどうかの判断を行い、接続の失敗であれば、ステップＳ１１６２に進んで終了処理を行う。一方、成功であれば、ステップＳ１１５３に進んで音声受信要求の送信を行う。この要求はHTTPのGETメソッドを用いて呼び出される。ステップＳ１１５４でこの呼び出しが成功したかどうかを判断する。HTTPでエラーが発生しているのであれば、ステップＳ１１６２に進んで終了処理を行う。

一方、成功であれば、ステップＳ１１５５で音声パケットを受信する。音声データを受信すると、受信した音声パケットの内容を判断する（ステップＳ１１５６）。有音パケットであればステップＳ１１５７で圧縮音声データを解凍し、音声再生バッファに音声データを格納する（ステップＳ１１５８）。

一方、静音パケットであればステップＳ１１５９でＣＮＧ波形作成を行い、この擬似音声波形のＣＮＧ波形データを音声再生バッファに格納する（ステップＳ１１６０）。

ステップＳ１１６１では、ユーザーからの終了指示があるかどうかを判断し、無ければ（ステップＳ１１６１でＮＯ）、ステップＳ１１５２に戻って上述した音声受信処理を続ける。一方、ユーザーからの終了指示がある場合は（ステップＳ１１６１でＹＥＳ）、ステップＳ１１６２で終了処理を行ってからこのサブルーチンを終了する。

通常、ファイヤーウォールでは、インターネットとの通信のためにHTTPに関しては最も優先度が高く透過が可能となっているので、本実施の形態によれば、ネットワークカメラの音声の配送をHTTPベースによって双方向に音声のやりとりを行うことを可能とし、ファイヤーウォールが存在したとしても、簡単に双方向通話が可能になる。

＜変形例１＞
図３６は、本発明の実施の形態の変形例１におけるカメラサーバ１００の音声情報を中継するサーバを用いた場合のシステムの概略全体構成を示すブロック図である。なお、図３６において、図１と同様の構成には同じ参照番号を付し、詳細説明は省略する。また、図３６において、カメラサーバ１００及びクライアント３００〜５００の周辺装置（マイク、スピーカーなど）は省略している。

上記実施の形態の音声配送は、HTTPプロトコルがベースになっているため、図３６に示すようにHTTPプロキシサーバ６００を介して音声データの配信を行うことができる。

カメラサーバ１００は、接続されているマイク１０１からの音声データをネットワーク２００を通して、プロキシサーバ６００を通してクライアント３００へ送信することが可能である。そして、音声データをクライアント３００がスピーカ３０４を使用して再生を行う。このようにしてクライアント３００はプロキシサーバ６００を介してカメラサーバ１００の音声を再生することが可能になる。

また、クライアント３００〜５００からカメラサーバ１００への音声配送もプロキシサーバ６００を介して行うことが可能である。

クライアント３００〜５００は、接続されたマイクから音声データを入力し、プロキシーサーバ６００を通してカメラサーバ１００に接続することで入力した音声データの送信が可能となる。こうして、カメラサーバ１００はクライアント３００〜５００からの音声データをスピーカーから再生することが可能となる。

このような仕組みによって、ファイヤーウォールの設置されているネットワークでHTTPプロキシーサーバが設置されているネットワークの場合でも、ファイヤウォールを透過して音声の送信と受信が可能となる。

＜変形例２＞
図３７は、本発明の実施の形態の変形例２におけるカメラサーバ１００の音声配送を中継サーバ７００を用いて行う場合のシステムの概略全体構成を示すブロック図である。なお、図３７において、図１と同様の構成には同じ参照番号を付し、詳細説明は省略する。また、図３７において、カメラサーバ１００及びクライアント３００〜５００の周辺装置（マイク、スピーカーなど）は省略している。

図３６で示されるプロキシーサーバ６００と非常に類似しているが相違点がある。それは中継サーバ７００が、音声データのコピーを作成し、各クライアント３００〜５００に配信する点である。ネットワークプロトコル上では、クライアント３００〜５００からは、中継サーバ７００は、カメラサーバ１００とほぼ同一のプロトコルを使用する。このことからクライアント３００〜５００は、中継サーバ７００に接続しているのか、カメラサーバ１００に接続しているのかを意識せずに動作することが可能である。

中継サーバ７００にクライアントが接続すると、その要求によって中継サーバ７００は、カメラサーバ１００へ接続をする。

逆に、ネットワークプロトコル上では、カメラサーバ１００からは、中継サーバ７００は、クライアントとほぼ同一のプロトコルを使用している。このことからカメラサーバ１００は、クライアントか中継サーバ７００かを意識せず、音声データを中継サーバ７００に配信することができる。中継サーバ７００は、その時点で接続しているクライアント全てに音声データをコピーして送信を行う。このような仕組みによって、中継サーバ７００に接続する全てのクライアントに対して音声データを配送することが可能になる。

逆に、クライアントからカメラサーバ１００への音声配送は、中継サーバ７００を介しても、そのままカメラサーバ１００に対して送信を行ってもよい。これは、カメラサーバ１００からクライアントへのデータ量に対して、クライアントからカメラサーバ１００のデータ量の方が低いため特にデータの変更はせずに送信することができるからである。

このような仕組みを導入することで、カメラサーバ１００のＣＰＵ１１０やネットワーク接続部１１３のデータ送出能力などが低く、大量の音声データの配送ができない場合でも、中継サーバ７００に高性能なコンピュータを配置することで、非常に多くのクライアントに対して、音声情報の送信が可能となる。

＜変形例３＞
図３８は、本発明の実施の形態の変形例３における画像音声蓄積サーバ８００を用いて画像データと音声データの記録を行う場合のシステムの概略全体構成を示すブロック図である。なお、図３８において、図１と同様の構成には同じ参照番号を付し、詳細説明は省略する。また、図３８において、カメラサーバ及びクライアント３００〜５００の周辺装置（マイク、スピーカーなど）は省略している。

図３８で示されるネットワーク２００には、２台のカメラサーバ装置１００ａ、１００ｂと、画像音声蓄積サーバ８００が接続されている。

画像音声蓄積サーバ８００は、クライアントとしてカメラサーバ１００ａ、１００ｂに接続を行い、それぞれから画像データと音声データとを取り込む。このように、画像音声蓄積サーバ８００は、複数台のカメラサーバ１００ａ、１００ｂからの画像データと音声データを随時取得し、蓄積を行う。なお、図３８では便宜上２台のカメラサーバを示しているが、３台以上のカメラサーバと接続することも勿論可能である。

これらの蓄積されたデータは、ネットワークを介してクライアント３００〜５００によって閲覧が可能である。

次に、クライアントにおけるソフトウェアＧＵＩに関して図３９を参照して説明する。

図３９は、画像音声蓄積サーバ用のクライアントソフトウェアＧＵＩの一構成例を示す図である。

画像音声蓄積サーバ８００は、カメラサーバ１００ａ、１００ｂを含む複数のカメラサーバに接続することが可能である。そのため、クライアントソフトＧＵＩも複数のカメラサーバから得られた複数の画像がカメラサーバ毎に表示される。表示された画像の１つを選択することで（図３９では８１０）、操作対象のカメラサーバを選択することができる。なお、図３９では、選択したカメラサーバの画像をウィンドウ８１１に大きく表示するようになっている。

音声の出力に関しても選択したカメラサーバの蓄積音声が再生される。

また、蓄積した画像や音声の時間方向の状況に関しては、８０１が示すようなタイムゲージと音声の出力状態を同時に表示したＧＵＩを備えることで、視覚的に把握することができる。

タイムゲージの時間を選ぶことで、その瞬間の動画と音声を瞬時に再生することも可能になる。

本発明の実施の形態におけるシステムの概略全体構成を示すブロック図である。本発明の実施の形態におけるカメラサーバのハードウェア構成を示すブロック図である。本発明の実施の形態におけるクライアントのハードウェア構成を示すブロック図である。本発明の実施の形態におけるカメラサーバの音声関連ソフトウェア構成を示すブロック図である。本発明の実施の形態におけるクライアントの音声関連ソフトウェア構成を示すブロック図である。本発明の実施の形態におけるクライアント上で表示されるソフトウェアＧＵＩの一例を示す図である。本発明の実施の形態におけるクライアント上で表示されるソフトウェアＧＵＩの別の例を示す図である。本発明の実施の形態におけるクライアントソフトウェアＧＵＩのダイアログを示す図である。本発明の実施の形態におけるクライアントソフトウェアＧＵＩのダイアログを示す図である。本発明の実施の形態におけるクライアントソフトウェアＧＵＩのダイアログを示す図である。本発明の実施の形態におけるクライアントソフトウェアＧＵＩの音声情報表示機能を説明するための図である。本発明の実施の形態におけるＡ方式のスピーカー占有権の付与方式を説明するシーケンス図である。本発明の実施の形態におけるＢ方式のスピーカー占有権の付与方式を説明するシーケンス図である。本発明の実施の形態におけるＣ方式のスピーカー占有権の付与方式を説明するシーケンス図である。本発明の実施の形態におけるＤ方式のスピーカー占有権の付与方式を説明するシーケンス図である。本発明の実施の形態における画像データと音声データの同期を説明するための図である。本発明の実施の形態における音声送信用パケットの詳細構成図である。本発明の実施の形態における音声操作用パケットの詳細構成図である。本発明の実施の形態におけるカメラサーバからクライアント方向へのHTTPによる音声配送方式を示すシーケンス図である。本発明の実施の形態におけるクライアントからカメラサーバ方向へのHTTPによる音声配送方式を示すシーケンス図である。本発明の実施の形態のクライアントにおいて実施される音声バッファのバッファ量制御動作を説明する図である。本発明の実施の形態のカメラサーバにおいて実施される音声データのミキシング動作を説明する図である。本発明の実施の形態のカメラサーバにおける全体処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける音声入力部の処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける音声出力部の処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける通信スレッドの処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける音声送信処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける音声受信処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおけるスピーカー占有権管理処理を示すフローチャートである。本発明の実施の形態のカメラサーバにおける別のスピーカー占有権管理処理を示すフローチャートである。本発明の実施の形態のクライアントにおける全体処理を示すフローチャートである。本発明の実施の形態のクライアントにおける音声入力部の処理を示すフローチャートである。本発明の実施の形態のクライアントにおける音声出力部の処理を示すフローチャートである。本発明の実施の形態のクライアントにおける音声送信処理を示すフローチャートである。本発明の実施の形態のクライアントにおける音声受信処理を示すフローチャートである。本発明の実施の形態の変形例１におけるProxyサーバ使用時のシステムの概略全体構成を示すブロック図である。本発明の実施の形態の変形例２における中継サーバ使用時のシステムの概略全体構成を示すブロック図である。画像音声蓄積サーバ使用時のシステム全体図画像音声蓄積サーバ用クライアントソフトウェアGUI図

符号の説明

１００カメラサーバ
１０１マイク
１０２スピーカー
２００ネットワーク
３００、４００、５００クライアント
３０１、４０１、５０１映像出力装置
３０２、４０２、５０２操作入力装置
３０３、４０３、５０３マイク
３０４、４０４、５０４スピーカー
６００プロキシーサーバ
７００中継サーバ
８００画像音声蓄積サーバ

Claims

ネットワークを介して受信した音声データに応じた音声を出力可能なスピーカーを有するカメラサーバと通信可能な情報処理装置であって、
前記カメラサーバから配信される画像データを受信する受信手段と、
前記受信手段で受信した画像データに応じた画像を表示させる表示手段と、
音声データを入力する音声入力手段と、
前記カメラサーバのスピーカーを占有するためのスピーカー占有権を取得する取得手段と、
前記カメラサーバの撮像装置の方向を制御するための制御量を入力するための制御量入力手段と、
前記取得手段によりスピーカー占有権を取得しているときは、前記制御量入力手段で入力した制御量に応じた制御信号を前記カメラサーバに送信可能にすると共に、前記音声入力手段で入力した音声データを、前記ネットワークを介して前記カメラサーバに送信し、前記取得手段によりスピーカー占有権が取得されていないときは、前記制御量に応じた制御信号を送信可能とせず、前記音声データを前記カメラサーバに送信しない送信手段とを有し、
前記表示手段は、前記スピーカー占有権の取得に応じて前記送信手段によって送信された音声データに応じた音声が前記カメラサーバのスピーカーで出力されているか否かを更に表示させることを特徴とする情報処理装置。
前記表示手段は、前記送信手段から前記カメラサーバへ出力される音声データの音量を表示させることを特徴とする請求項１に記載の情報処理装置。
ネットワークを介して受信した音声データに応じた音声を出力可能なスピーカーを有するカメラサーバと通信可能な情報処理装置が行う情報処理方法であって、
前記カメラサーバから配信される画像データを受信する受信工程と、
前記受信工程で受信した画像データに応じた画像を表示させる表示工程と、
音声データを入力する音声入力工程と、
前記カメラサーバのスピーカーを占有するためのスピーカー占有権を取得する取得工程と、
前記カメラサーバの撮像装置の方向を制御するための制御量を入力するための制御量入力工程と、
前記取得工程によりスピーカー占有権を取得しているときは、前記制御量入力工程で入力した制御量に応じた制御信号を前記カメラサーバに送信可能にすると共に、前記音声入力工程で入力した音声データを、前記ネットワークを介して前記カメラサーバに送信し、前記取得工程によりスピーカー占有権が取得されていないときは、前記制御量に応じた制御信号を送信可能とせず、前記音声データを前記カメラサーバに送信しない送信工程とを有し、
前記表示工程では、前記スピーカー占有権の取得に応じて前記送信工程で送信された音声データに応じた音声が前記カメラサーバのスピーカーで出力されているか否かを更に表示させることを特徴とする情報処理方法。
ネットワークを介して受信した音声データに応じた音声を出力可能なスピーカーを有するカメラサーバと通信可能なコンピュータに、
前記カメラサーバから配信される画像データを受信する受信手順と、
前記受信手順で受信した画像データに応じた画像を表示させる表示手順と、
前記音声データを入力する音声入力手順と、
前記カメラサーバのスピーカーを占有するためのスピーカー占有権を取得する取得手順と、
前記カメラサーバの撮像装置の方向を制御するための制御量を入力するための制御量入力手順と、
前記取得手順によりスピーカー占有権を取得しているときは、前記制御量入力手順で入力した制御量に応じた制御信号を前記カメラサーバに送信可能にすると共に、前記音声入力手順で入力した音声データを、前記ネットワークを介して前記カメラサーバに送信し、前記取得手順によりスピーカー占有権が取得されていないときは、前記制御量に応じた制御信号を送信可能とせず、前記音声データを前記カメラサーバに送信しない送信手順とを実行させ、
前記表示手順は、前記スピーカー占有権の取得に応じて前記送信手順によって送信された音声データに応じた音声が前記カメラサーバのスピーカーで出力されているか否かを更に表示させることを特徴とするプログラム。