(57)【特許請求の範囲】
【請求項１】
ネットワークを介して他の撮像装置、及び受信装置と接続される撮像装置であって、
撮像手段と、
前記撮像手段の撮像により取得される第１の映像データの前記受信装置への送信要求を、前記受信装置から受信する受信手段と、
前記撮像装置の処理負荷、前記撮像装置の最大配信数、及び前記ネットワークの状態のうちの少なくとも１つに基づいて、前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信するか否かを判定する判定手段と、
前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信しないと前記判定手段により判定された場合、前記他の撮像装置が有する撮像手段の撮像により取得される第２の映像データであって、前記第１の映像データとは異なる第２の映像データの送信要求の送信先として前記他の撮像装置へのアクセス情報を取得する取得手段と、
前記取得手段により前記第２の映像データの送信要求の送信先として取得された前記他の撮像装置へのアクセス情報を、前記第１の映像データの送信要求を送信した前記受信装置に対して送信する送信手段と
を有することを特徴とする撮像装置。
【請求項２】
前記判定手段は、前記撮像装置が映像データを送信している受信装置の数が予め設定された閾値未満である場合に前記第１の映像データの前記受信装置への送信を実行すると判定し、前記撮像装置が映像データを送信している受信装置の数が前記閾値以上である場合に前記第１の映像データの前記受信装置への送信を実行しないと判定することを特徴とする請求項１記載の撮像装置。
【請求項３】
前記第１の映像データを前記受信装置へ送信しないと前記判定手段により判定された場合、前記他の撮像装置に対して、前記第２の映像データの前記受信装置への送信が可能であるか否かを問い合わせる問い合わせ手段を有し、
前記送信手段は、前記判定手段により前記第１の映像データを前記受信装置へ送信しないと判定され、且つ、前記問い合わせ手段による問い合わせの結果、前記他の撮像装置が前記第２の映像データを前記受信装置へ送信できると判定された場合、前記受信装置に前記取得手段により取得された前記他の撮像装置へのアクセス情報を送信することを特徴とする請求項１記載の撮像装置。
【請求項４】
前記第１の映像データを前記受信装置へ送信しないと前記判定手段によりされた場合、前記他の撮像装置に対して、前記第２の映像データの前記受信装置への送信が可能であるか否かを問い合わせる問い合わせ手段を有し、
前記送信手段は、前記判定手段により前記第１の映像データを前記受信装置へ送信しないと判定され、且つ、前記問い合わせ手段による問い合わせの結果、前記他の撮像装置が前記第２の映像データを前記受信装置へ送信できないと判定された場合、前記受信装置へ前記第１の映像データを送信しないことを示す応答を前記受信装置に送信することを特徴とする請求項１記載の撮像装置。
【請求項５】
ネットワークを介して他の撮像装置、及び受信装置と接続する撮像装置であって、撮像手段を有する撮像装置が実行する情報処理方法であって、
前記撮像手段の撮像により取得される第１の映像データの前記受信装置への送信要求を、前記受信装置から受信する受信ステップと、
前記撮像装置の処理負荷、前記撮像装置の最大配信数、及び前記ネットワークの状態のうちの少なくとも１つに基づいて、前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信するか否かを判定する判定ステップと、
前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信しないと前記判定ステップで判定された場合、前記他の撮像装置が有する撮像手段の撮像により取得される第２の映像データであって、前記第１の映像データとは異なる第２の映像データの送信要求の送信先として前記他の撮像装置へのアクセス情報を取得する取得ステップと、
前記取得ステップで前記第２の映像データの送信要求の送信先として取得された前記他の撮像装置へのアクセス情報を、前記第１の映像データの送信要求を送信した前記受信装置に対して送信する送信ステップと
を含むことを特徴とする情報処理方法。
【請求項６】
撮像手段に接続されたコンピュータを、請求項１乃至４何れか１項記載の撮像装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、撮像装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
現在、インターネット等のＩＰネットワークを用いたメディア伝送が普及しており、カメラ等で撮影した動画像や音声等のメディアデータをネットワーク経由でリアルタイムに伝送するプロトコルであるＲＴＰが利用されてきている。ここで、ＩＰとは、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌの略である。また、ＲＴＰとは、Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌの略である。
また、ライブカメラや監視カメラ等に代表されるように、メディアデータを送信するサーバ機能を有する送信装置に対して、複数のメディアデータ受信装置がメディアデータ送信を要求する利用形態もある。更に、異なる角度からの映像の取得や故障時の代替装置としての役割のため、複数のデータ送信装置が同一の被撮像対象物を撮影し、撮影した映像データをデータ受信装置に送信する形態も存在する。
【０００３】
メディアデータのリアルタイム送信においては、データ受信装置における再生時のメディアの品質維持のために、データ送信装置の処理負荷やネットワーク負荷を考慮して、データ受信装置の接続数を制限する等の制御が必要である。従来、接続数を制限する方法としては、閾値として最大接続数を予め設定しておき、閾値を超える接続要求については要求を拒否する技術が一般的であった（例えば、特許文献１参照）。
また、データ受信装置自身にデータ転送機能を持たせ、ネットワークのツリー構造を踏まえた上でデータを転送させることで、処理負荷やネットワーク負荷を軽減しつつ、多くのデータ受信装置にメディアデータを伝送する技術があった（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−１６４５５９号公報
【特許文献２】特開２００９−０７１５３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の接続数制限方法では、複数のデータ送信装置が存在していたとしても、接続要求を受信したデータ送信装置が、既に接続上限数までデータ受信装置と接続済みであった場合には、別のデータ送信装置が送信可能であっても接続を拒否してしまう。そのため、複数のデータ送信装置のリソースを最大限利用するためには、データ受信装置が予め複数のデータ送信装置の存在を把握しつつ、接続拒否された場合に改めて別のデータ送信装置に接続要求を送信しなければならないという問題があった。
また、データ受信装置間でメディアデータを転送する技術については、データ受信装置がその他複数のデータ受信装置のネットワーク構造を把握していなければならないうえに、データ転送機能を持たなければならないという問題があった。
【０００６】
本発明はこのような問題点に鑑みなされたもので、メディアデータ受信装置が複数のデータ送信装置のネットワーク構造を把握せずともリソースを効率的に使用することを可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明は、ネットワークを介して他の撮像装置、及び受信装置と接続される撮像装置であって、撮像手段と、前記撮像手段の撮像により取得される第１の映像データの前記受信装置への送信要求を、前記受信装置から受信する受信手段と、前記撮像装置の処理負荷、前記撮像装置の最大配信数、及び前記ネットワークの状態のうちの少なくとも１つに基づいて、前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信するか否かを判定する判定手段と、前記撮像手段の撮像により取得される第１の映像データを前記受信装置へ送信しないと前記判定手段により判定された場合、前記他の撮像装置が有する撮像手段の撮像により取得される第２の映像データであって、前記第１の映像データとは異なる第２の映像データの送信要求の送信先として前記他の撮像装置へのアクセス情報を取得する取得手段と、前記取得手段により前記第２の映像データの送信要求の送信先として取得された前記他の撮像装置へのアクセス情報を、前記第１の映像データの送信要求を送信した前記受信装置に対して送信する送信手段とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、メディアデータ受信装置が複数のデータ送信装置のネットワーク構造を把握せずともリソースを効率的に使用することを可能とすることができる。
【図面の簡単な説明】
【０００９】
【図１】システム構成等の一例を示す図である。
【図２】メディアデータ送信装置のハードウェア構成の一例を示す図である。
【図３】命令実行可否判定部における処理の流れを示すフローチャートである。
【図４】実施形態１の概要を示す図である。
【図５】実施形態１のＲＴＳＰを用いた詳細な処理の例を示す図である。
【図６】第二のメディアデータ送信装置もメディアデータの送信不可状態であった場合の処理の例を示す図である。
【図７】実施形態２の概要を示す図である。
【図８】命令実行可否判定部１０９における処理の流れを示すフローチャートである。
【図９】実施形態２のＲＴＳＰを用いた詳細な処理の例を示す図である。
【図１０】実施形態３の概要を示す図である。
【図１１】実施形態３のＲＴＳＰを用いた詳細な処理の例を示す図である。
【図１２】実施形態４のＲＴＳＰを用いた詳細な処理の例を示す図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面に基づいて説明する。
【００１１】
＜実施形態１＞
本実施形態のメディアデータ送信装置等の構成について、図１を参照して説明する。
図１において、メディアデータ送信装置１０１は、メディアデータを送信する通信機能を備えた単一若しくは複数のコンピュータ装置で実現してもよいし、通信機能を備えたカメラであってもよい。
メディアデータ受信装置１０２は、メディアデータ送信装置１０１より送信されるメディアデータを受信する通信機能を備えたコンピュータで実現してもよいし、通信機能を備えたストレージ装置やテレビであってもよい。
これらメディアデータ送信装置１０１とメディアデータ受信装置１０２とは、互いに通信可能なようにネットワーク１０３で接続されている。
【００１２】
メディアデータ送信装置１０１は、機能構成として、メディアデータ入力部１０４、メディアデータ符号化部１０５、パケット生成部１０６、パケット送信部１０７、パケット受信部１０８、命令実行可否判定部１０９、アドレス情報取得部１１０を含む。また、メディアデータ送信装置１０１は、機能構成として、音声データ復号化部１１１、音声データ再生部１１２を含む。なお、メディアデータ送信装置１０１は、機能構成として、音声データ復号化部１１１、音声データ再生部１１２を含んでいなくてもよい。各機能構成はそれぞれハードウェアとしてメディアデータ送信装置１０１に実装されていてもよいし、ＣＰＵが記憶装置に記憶されたプログラムに基づき実行することによって実現されるソフトウェアとしてメディアデータ送信装置１０１に実装されていてもよい。但し、本実施形態では、後述する図２に示すように、図１に示される各機能構成は、ＣＰＵが記憶装置に記憶されたプログラムに基づき実行することによって実現されるソフトウェアとしてメディアデータ送信装置１０１に実装されているものとして説明を行う。
【００１３】
まず、メディアデータ送信装置１０１における大まかな処理の流れを説明する。
メディアデータ入力部１０４は、ネットワーク１０３を介して伝送する映像データや音声データを、記憶装置やビデオカメラ、ネットワークカメラ等の映像センサ、音声センサから受け取り、デジタル信号に変換し、メディアデータ符号化部１０５へ入力する。
メディアデータ符号化部１０５は、入力されたメディアデータを圧縮符号化方式に従い符号化する。ここで圧縮符号化方式とは、例えば、映像データであれば、Ｈ．２６４／ＡＶＣやＭｏｔｉｏｎ−ＪＰＥＧ、音声データであれば、Ｇ．７１１やＧ．７２６等が挙げられるが、これら以外の方式でもよい。符号化したメディアデータはパケット生成部１０６に入力される。
パケット生成部１０６は、符号化されたメディアデータを通信に最適なパケットに分割する。通信プロトコルとしてＲＴＰを用いる場合、一般的には１５００バイト程度のＲＴＰパケットが生成される。生成されたメディアデータパケットはパケット送信部１０７に入力される。
パケット送信部１０７は、前記生成されたメディアデータパケットをネットワーク１０３経由でメディアデータ受信装置１０２へと送信する。
【００１４】
パケット受信部１０８は、メディアデータ受信装置１０２からネットワーク１０３経由で送信されるパケットを受信する。ここで受信されるパケットは、メディアデータ受信装置１０２が要求する命令実行情報を含む。ここでの命令実行情報とは、例えば、メディアデータの送信要求やメディアデータ受信装置１０２から送信する音声データの出力要求を意味する。本実施形態では、メディアデータの送信要求を例に説明する。
命令実行可否判定部１０９は、メディアデータ受信装置１０２が要求する命令の実行可否を判定する。判定方法については後述する。判定の可否についての情報は、パケット送信部１０７からメディアデータ受信装置１０２に通知される。通知方法は、セッション制御プロトコルとしてのＲＴＳＰやＳＩＰプロトコル等を用いて実現されるが、これら以外の方式でもよい。本実施形態では、ＲＴＳＰを用いた方式により説明する。ここで、ＲＴＳＰとは、Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌの略である。また、ＳＩＰとは、Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌの略である。
【００１５】
メディアデータ受信装置１０２の要求する命令の実行が不可であった場合、アドレス情報取得部１１０は、ネットワーク１０３に接続された第二のメディアデータ送信装置のＩＰアドレスを取得する。パケット生成部１０６は、アドレス情報取得部１１０が取得した第二のメディアデータ送信装置のＩＰアドレスを含めたメディアセッション情報を生成する。パケット送信部１０７は、前記生成されたメディアセッション情報をメディアデータ受信装置１０２に送信する。メディアセッション情報についても後述する。
音声データ復号化部１１１は、メディアデータ受信装置１０２から送信された音声データを復号化する。
複合化した音声データは、音声データ再生部１１２により、スピーカーやイヤフォン等のオーディオデバイスに出力され、再生される。
【００１６】
続いて、メディアデータ受信装置１０２における大まかな処理の流れを説明する。
命令実行要求生成部１１３は、命令実行要求を生成する。そして、パケット生成部１２０は、前記命令実行要求をパケット化する。パケット送信部１１４は、パケット化された前記命令実行要求（メディアデータパケット）をメディアデータ送信装置１０１に送信する。ここでの命令実行要求とは、先述した通り、メディアデータの送信要求や音声データの出力要求等である。送信プロトコルはＲＴＳＰやＳＩＰでもよいし、それ以外の方式でもよい。
パケット受信部１１５は、メディアデータ送信装置１０１より送信されたメディアデータパケットを受信する。メディアデータ復号化部１１６は、それぞれの符号化方式に従い、前記メディアデータパケットを復号化する。メディアデータ再生部１１７は、復号化されたメディアデータを再生する。
音声データ入力部１１８は、マイクロフォン等から音声データを入力する。入力された音声データはデジタル信号に変換された後、音声データ符号化部１１９により符号化される。
【００１７】
図２は、メディアデータ送信装置のハードウェア構成の一例を示す図である。
図２に示されるように、メディアデータ送信装置１０１は、ＣＰＵ１１と、記憶装置１２と、ネットワークＩ／Ｆ１３と、を含む。
ＣＰＵ１１は、記憶装置に記憶されたプログラムを実行することによって、図１に示されるメディアデータ送信装置１０１の機能や後述するメディアデータ送信装置１０１のフローチャートに係る情報処理を実現する。また、ＣＰＵ１１は、システムバスに接続される各ハードウェアを総括的に制御する。記憶装置１２は、例えば、ＲＡＭ、ＲＯＭ、ＨＤＤ等であり、プログラムを記憶すると共にＣＰＵ１１の主メモリ、ワークエリア等として機能する。ネットワークＩ／Ｆ１３は、ネットワークを介した他の装置との通信を制御する。
なお、メディアデータ送信装置のハードウェア構成として、撮像装置や音声出力装置等を含んでいてもよい。
また、メディアデータ受信装置１０２も少なくとも図２に示されるようなハードウェア構成を有するものとする。即ち、メディアデータ受信装置１０２のＣＰＵが、メディアデータ受信装置１０２の記憶装置に記憶されているプログラムを実行することによって、図１に示されるメディアデータ受信装置１０２の機能等を実現する。
同様に、クライアントも少なくとも図２に示されるようなハードウェア構成を有するものとする。即ち、クライアントのＣＰＵがクライアントの記憶装置に記憶されているプログラムを実行することによって、後述するクライアントの機能等を実現する。
【００１８】
次に、図３を用いて、命令実行可否判定部１０９における処理の流れを説明する。
命令実行可否判定部１０９は、パケット受信部１０８によって受信されたメディアデータ送信要求から要求メディア情報を取得する（Ｓ２０１）。要求メディア情報は一つとは限らず、例えば、映像データ、音声データ、メタデータ等複数のメディアデータの送信を要求する可能性がある。
命令実行可否判定部１０９は、取得した要求メディアの現在の配信数を取得する（Ｓ２０２）。そして、命令実行可否判定部１０９は、現配信数と予め設定された最大配信数とを比較する（Ｓ２０３）。本実施形態では、最大配信数を静的に設定している。しかしながら、例えば、命令実行可否判定部１０９等が、ネットワークの帯域やメディアデータ送信装置１０１のＣＰＵ処理負荷から動的に設定してもよいし、要求メディア情報毎に異なる値を設定してもよい。
【００１９】
命令実行可否判定部１０９は、現配信数が最大配信数以上（つまり、閾値以上）であれば（Ｓ２０３においてＹｅｓ）、命令実行（送信）不可と判定する（Ｓ２０４）。
命令実行可否判定部１０９は、現配信数が最大配信数未満（つまり、閾値未満）であれば（Ｓ２０３においてＮｏ）、全ての要求メディアについて判定したか否かを確認する（Ｓ２０５）。
命令実行可否判定部１０９は、全要求メディアを網羅していれば（Ｓ２０５においてＹｅｓ）、命令実行（送信）可と判定する（Ｓ２０６）。命令実行可否判定部１０９は、全要求メディアを網羅していなければ（Ｓ２０５においてＮｏ）、次の要求メディア情報を取得する（Ｓ２０１）。本実施形態では、全要求メディアについて最大配信数未満でなければ送信不可と判定しているが、最大配信数未満のメディアが一つでもあれば送信可と判定してもよい。
【００２０】
次に、命令実行可否判定部１０９において実行不可と判定された場合に、ネットワークに接続された別のメディアデータ送信装置に要求命令実行を委託する方法について説明する。本実施形態では、ＲＴＳＰを用いたより具体的な方法を示すが、これに限らない。
図４は、本実施形態の概要を示す図である。
メディアデータ送信装置であるカメラ（１）３０１及びカメラ（２）３０２がルータ３０５を介して同ＬＡＮ上に存在している。また、メディアデータ受信装置であるｎ個のクライアント３０３がネットワーク１０３を介して撮像メディアデータ３０６を受信している。この状態で新たなメディアデータ受信装置であるクライアント（ｎ＋１）３０４がメディアデータ送信要求をカメラ（１）３０１に送信してきた様子を示している。複数のメディアデータ送信装置は、同ＬＡＮ上に存在していなくてもよいし、ルータ３０５を介していなくてもよい。
【００２１】
ここで、カメラ（１）３０１がメディアデータを送信できる最大配信数をｎとする。カメラ（１）３０１は、既にクライアント群（１）−（ｎ）３０３に対し、メディアデータを配信中であり、クライアント（ｎ＋１）３０４に対するメディアデータ配信は実行不可状態である。このときカメラ（１）３０１は、同ＬＡＮ上に存在するカメラ（２）３０２に対してメディアデータの代替配信が可能かどうかを問い合わせる。問い合わせの結果、配信可能であると判断すると、カメラ（１）３０１は、カメラ（２）３０２のＩＰアドレスを含むメディアデータ情報をクライアント（ｎ＋１）３０４に送信する。クライアント（ｎ＋１）３０４は、カメラ（１）３０１から受信したメディアデータ情報を参照し、カメラ（２）３０２とのセッションを確立することで、カメラ（２）３０２から撮像メディアデータ３０８を受信する。
【００２２】
次に、図５を用いて、ＲＴＳＰを用いた詳細な処理の例を示す。
ここで、カメラ（１）３０１のＩＰアドレスをｘｘｘ．ｘｘｘ．ｘｘｘ．１とする。また、カメラ（２）３０２のＩＰアドレスをｘｘｘ．ｘｘｘ．ｘｘｘ．２とする。
クライアント（ｎ＋１）３０４は、カメラ（１）３０１に対し、メディアデータ送信要求３０７を送信する。ＲＴＳＰでメディアデータストリームを要求する場合、クライアント（ｎ＋１）３０４は、まず、ＤＥＳＣＲＩＢＥメソッドを用いてＳＤＰによるメディアデータ情報を要求するのが通例である。ここで、ＳＤＰは、Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌの略である。このメディアデータ情報には、映像や音声の符号化方式やメディアストリーム要求用のＵＲＬ等が含まれている。
カメラ（１）３０１は、新規メディアデータ送信不可状態であるため、カメラ（２）３０２にＤＥＳＣＲＩＢＥメソッド４０１によりメディアデータ情報を要求する。
カメラ（２）３０２は、新規メディアデータ送信可能であれば、成功応答（２００：ＯＫ）と共にメディアデータ情報を含むＳＤＰ４０２をカメラ（１）３０１に送信する。
【００２３】
カメラ（１）３０１は、カメラ（２）３０２から受信したカメラ（２）３０２のメディアデータ情報をクライアント（ｎ＋１）３０４に転送する。
クライアント（ｎ＋１）３０４は、カメラ（１）３０１から受信したカメラ（２）３０２のメディアデータ情報を参照し、カメラ（２）３０２とのメディアセッションを確立するための要求ＳＥＴＵＰメソッド４０３をカメラ（２）３０２に送信する。メディアセッションは、例えば、ＲＴＰ／ＵＤＰで接続し、セッション制御用のＲＴＳＰのセッションとは別に確立する。プロトコルはＲＴＰ／ＵＤＰでなくてもよく、ＲＴＳＰやＨＴＴＰ等のＴＣＰプロトコルでカプセル化してもよい。
クライアント（ｎ＋１）３０４は、メディアセッション確立後は、メディアデータの再生開始要求ＰＬＡＹメソッド４０４をカメラ（２）３０２に送信し、カメラ（２）３０２から撮像メディアデータ３０８を受信する。
【００２４】
続いて、図６を用いて、第二のメディアデータ送信装置もメディアデータの送信不可状態であった場合の処理の例を示す。
クライアント（ｎ＋１）３０４からのメディアデータ送信要求３０７を受信したカメラ（１）３０１は、メディアデータ送信不可状態であるため、第二のメディアデータ送信装置であるカメラ（２）３０２に対し、ＤＥＳＣＲＩＢＥメソッド４０１を送信する。
ここで、カメラ（２）３０２もメディアデータの送信不可状態であるとする。
カメラ（２）３０２自身が第二の代替メディアデータ送信装置情報を保持していない場合は、ＲＴＳＰのエラー応答５０１、例えば、エラーコード４０６：  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅをカメラ（１）３０１に送信する。
カメラ（２）３０２自身が第二の代替メディアデータ送信装置情報を保持している場合は、同じようにＤＥＳＣＲＩＢＥメソッドによりメディアデータ情報を要求してもよい。
【００２５】
カメラ（２）３０２からエラー応答（４０６：  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅ）５０１を受信したカメラ（１）３０１は、カメラ（２）３０２以外の第二の代替メディアデータ送信装置情報を保持している場合は、以下の処理を行ってもよい。即ち、カメラ（１）３０１は、代替メディアデータ送信装置情報の代替メディアデータ送信装置にＤＥＳＣＲＩＢＥメソッドを送信してもよい。
カメラ（１）３０１が保持している全ての代替メディアデータ送信装置がメディアデータの配信不可状態（つまり、実行不可能）であった場合は、カメラ（１）３０１は、クライアント（ｎ＋１）３０４に対しＲＴＳＰのエラー応答５０１を送信する。つまり、このことで、カメラ（１）３０１は、メディアデータ送信要求を拒否する。なお、ＲＴＳＰのエラー応答５０１のエラーコードは４０６：  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅでなくてもよい。また、ＤＥＳＣＲＩＢＥメソッドではメディアデータ配信の可否を判定せずに、ＳＥＴＵＰメソッドで判定し、拒否してもよい。
本実施形態では、カメラ（１）３０１が、第二のメディアデータ送信装置であるカメラ（２）３０２に対し、ＤＥＳＣＲＩＢＥメソッドによってメディアデータ情報を取得するよう説明を行った。しかしながら、カメラ（１）３０１が、メディアデータ情報を予め保持しておき、カメラ（２）３０２に問い合わせずにクライアント（ｎ＋１）３０４に送信してもよい。
また、本実施形態では、第二のメディアデータ送信装置を一個として説明したが、複数個存在する場合、所定のアルゴリズム等を用いて優先順位を付け、問い合わせ先を決定するようにしてもよい。
【００２６】
以上のように本実施形態においては、メディアデータ送信装置がメディアデータ受信装置からのメディアデータ配信不可状態で新たなメディアデータ配信要求があった場合、第二のメディアデータ送信装置にメディアデータ配信を委託する。これにより、メディアデータ受信装置が複数のメディアデータ送信装置の存在を把握せずにリソースを効率的に使用することが可能となる。
【００２７】
＜実施形態２＞
次に、メディアデータ送信装置が、メディアデータ受信装置から音声出力を要求される実施形態を図７に示す。
メディアデータ送信装置であるカメラ（１）３０１及びカメラ（２）３０２は、音声データを出力するインタフェースを備えており、一つのメディアデータ受信装置からの音声データを出力できるものとする。ここで、カメラ（１）３０１が既にクライアント（１）６０１からの音声データを出力中に、第二のクライアント（２）６０２から音声データ出力要求６０４を受信した場合の処理について説明する。
【００２８】
図８は、命令実行可否判定部１０９における処理の流れを示すフローチャートである。
命令実行可否判定部１０９は、メディアデータ受信装置から音声出力要求を受信する（Ｓ７０１）。
すると、命令実行可否判定部１０９は、現在の音声出力数と最大音声出力数（＝１）とを比較する（Ｓ７０２）。
命令実行可否判定部１０９は、現在の音声出力数が、最大音声出力数未満（つまり、閾値未満）であれば（Ｓ７０２においてＮｏ）、要求された音声出力可能であると判定する（Ｓ７０３）。
一方、命令実行可否判定部１０９は、最大音声出力数以上（つまり、閾値以上）であれば（Ｓ７０２においてＹｅｓ）、音声出力不可能と判定する（Ｓ７０４）。
本実施形態では最大音声出力数を１としているが、例えば、オーディオミキサー機能や複数の音声出力インタフェース等を備えている場合はこの限りではない。
図７におけるカメラ（１）３０１は、命令実行可否判定部１０９において、命令実行不可と判定された場合、要求された音声出力をネットワークに接続された第二のメディアデータ送信装置であるカメラ（２）３０２に委託する。クライアント（２）６０２は、カメラ（２）３０２に対して音声データ６０５を送信する。
【００２９】
次に、図９を用いて、ＲＴＳＰを用いた詳細な処理の例を示す。
クライアント（２）６０２は、カメラ（１）３０１に対し、音声データ出力要求６０４をＲＴＳＰのＤＥＳＣＲＩＢＥメソッドにより送信する。
ここで、カメラ（１）３０１は既に、クライアント（１）６０１からの音声データを出力中であるため、クライアント（２）６０２から要求された新たな音声データ出力不可の状態である。したがって、カメラ（１）３０１は、カメラ（２）３０２にＤＥＳＣＲＩＢＥメソッド８０１により音声出力用のセッション情報を要求する。
カメラ（２）３０２は、音声出力可能であれば、成功応答（２００：  ＯＫ）と共に音声出力用のセッション情報ＳＤＰ８０２をカメラ（１）３０１に送信する。
カメラ（１）３０１は、カメラ（２）３０２から受信したカメラ（２）３０２の音声出力用のセッション情報をクライアント（２）６０２に転送する。
クライアント（２）６０２は、カメラ（１）３０１から受信したカメラ（２）３０２の音声出力用のセッション情報ＳＤＰを参照し、カメラ（２）３０２とのメディアセッションを確立するためのＳＥＴＵＰメソッド８０４をカメラ（２）３０２に送信する。
メディアセッション確立後は、クライアント（２）６０２は、音声出力開始要求ＰＬＡＹメソッド８０５をカメラ（２）３０２に送信し、カメラ（２）３０２に音声データ６０５を送信する。
【００３０】
以上のように本実施形態においては、メディアデータ送信装置がメディアデータ受信装置からの音声出力不可状態で新たな音声データ出力要求があった場合、別のメディアデータ送信装置に音声データ出力を委託する。これにより、メディアデータ受信装置が複数のメディアデータ送信装置の存在を把握せずにリソースを効率的に使用することが可能となる。
【００３１】
＜実施形態３＞
次に、メディアデータ送信装置が、メディアデータ受信装置から音声出力を要求される実施形態２と異なる実施形態を図１０に示す。
ここで、メディアデータ送信装置であるカメラ（１）３０１が既にクライアント（１）６０１からの音声データを出力中に、別のクライアント（２）６０２から音声データ出力要求６０４を受信した場合の処理について説明する。
カメラ（１）３０１は、命令実行可否判定部１０９において、命令実行不可と判定された場合、要求された音声出力をネットワークに接続された第二のメディアデータ送信装置であるカメラ（２）３０２に委託する。命令実行可否判定部１０９の処理については実施形態２と同様であるため省略する。クライアント（２）６０２は、カメラ（１）３０１に対して音声データ９０１を送信し、カメラ（１）３０１は、受信した音声データ９０１を自機では再生せずに、カメラ（２）３０２に同じペイロードの音声データ９０２を転送する。
【００３２】
次に、図１１を用いて、ＲＴＳＰを用いた詳細な処理の例を示す。
クライアント（２）６０２は、カメラ（１）３０１に対し、音声データ出力要求６０４をＲＴＳＰのＤＥＳＣＲＩＢＥメソッドにより送信する。ここで、カメラ（１）３０１は既に、クライアント（１）６０１からの音声データを出力中であるため、クライアント（２）６０２から要求された新たな音声データ出力不可の状態である。
したがって、カメラ（１）３０１は、カメラ（２）３０２にＤＥＳＣＲＩＢＥメソッド８０１により音声出力用のセッション情報を要求する。
カメラ（２）３０２は、音声出力可能であれば、成功応答（２００：  ＯＫ）と共に音声出力用のセッション情報ＳＤＰ８０２をカメラ（１）３０１に送信する。
カメラ（１）３０１はカメラ（２）３０２から受信したカメラ（２）３０２の音声出力用のセッション情報ＳＤＰ内のセッション制御用ＵＲＬをカメラ（１）３０１の制御用ＵＲＬに書き換えたセッション情報ＳＤＰ１００１をクライアント（２）６０２に転送する。
【００３３】
クライアント（２）６０２は、カメラ（１）３０１から受信したセッション情報ＳＤＰを参照し、カメラ（１）３０１とのメディアセッションを確立するためのＳＥＴＵＰメソッド１００２をカメラ（１）３０１に送信する。
クライアント（２）６０２からＳＥＴＵＰメソッド１００２を受信したカメラ（１）３０１は、カメラ（２）３０２から受信していたカメラ（２）３０２の音声出力用のセッション情報ＳＤＰを参照する。そして、カメラ（１）３０１は、カメラ（２）３０２とのメディアセッションを確立するためのＳＥＴＵＰメソッド１００３をカメラ（２）３０２に送信する。これにより、クライアント（２）６０２はカメラ（１）３０１と、カメラ（１）３０１はカメラ（２）３０２とそれぞれメディアセッションが確立した状態となり、それぞれ、ＰＬＡＹメソッド１００４、１００５により音声データの送信を開始する。
クライアント（２）６０２から送信された音声データ９０１は、カメラ（１）３０１を経由し、同じペイロードの音声データ９０２がカメラ（２）３０２に送信され、カメラ（２）３０２にて再生される。
【００３４】
以上のように本実施形態においては、メディアデータ送信装置がメディアデータ受信装置からの音声出力不可状態で新たな音声データ出力要求があった場合、第二のメディアデータ送信装置に音声データ出力を委託する。これにより、メディアデータ受信装置が複数のメディアデータ送信装置の存在を把握せずにリソースを効率的に使用することが可能となる。
【００３５】
＜実施形態４＞
次に、メディアデータ送信装置が、メディアデータ受信装置から要求された命令の実行を、リソース不足のために第二のメディアデータ送信装置に委託した後、リソースが回復し、要求された命令を実行可能状態に復帰した場合の実施形態について説明する。なお、メディアデータ送信装置が、メディアデータ受信装置から要求された命令の実行を第二のメディアデータ送信装置に委託するまでの処理は、実施形態１と共通であるため省略する。
【００３６】
図１２は、ＲＴＳＰを用いた詳細な処理の例を示す。
カメラ（１）３０１は、クライアント（ｎ）３０３からメディアデータ送信要求を受け、ＰＬＡＹメソッド１１０１によりメディアデータ送信が開始され、カメラ（１）３０１が新規メディアデータ送信不可能状態となった状況とする。
続いて、カメラ（１）３０１に対し、クライアント（ｎ＋１）３０４から新規メディアデータ送信要求としてＤＥＳＣＲＩＢＥメソッド１１０２が送信される。そして、実施形態１で説明した一連のＲＴＳＰ処理（ＤＥＳＣＲＩＢＥ１１０３−ＳＥＴＵＰ１１０４−ＰＬＡＹ１１０５）により、カメラ（１）３０１は、カメラ（２）３０２にメディアデータ送信を委託する。ここで、カメラ（１）３０１は、要求命令実行を委託した別のカメラを特定できる識別子をリストとして保持する。保持する情報は、要求命令実行を委託した第二のカメラを特定できる情報であれば何でもよい。
【００３７】
ここで、クライアント（ｎ）３０３がカメラ（１）３０１に対し、ＴＥＡＲＤＯＷＮメソッド１１０６によりメディアデータの再生を停止する。これにより、カメラ（１）３０１は、メディアデータを送信するリソースが回復し、新規メディアデータ送信が可能な状態となる。
カメラ（１）３０１は、先に保持していた要求命令実行を委託した第二のカメラ（２）３０２に対し、新規メディアデータ送信可能状態となった旨を通知する。本実施形態では、ＲＴＳＰのＳＥＴ＿ＰＡＲＡＭＥＴＥＲメソッド１１０７により通知しているが、別のメソッドでもよいし、ＲＴＳＰでなく別のプロトコルでもよい。
クライアント（ｎ＋１）へのメディアデータ送信をカメラ（１）３０１から委託されているカメラ（２）３０２は、カメラ（１）３０１からの状態変更通知を受け、クライアント（ｎ＋１）に対し、ＲＥＤＩＲＥＣＴメソッド１１０８を送信する。ＲＥＤＩＲＥＣＴメソッド１１０８には、再接続先のカメラ（１）３０１へのアクセスＵＲＬをＬｏｃａｔｉｏｎとして含む。
クライアント（ｎ＋１）は、カメラ（２）３０２より受信したＲＥＤＩＲＥＣＴメソッド１１０８を参照し、カメラ（１）３０１に対し、ＤＥＳＣＲＩＢＥメソッド１１０９により改めてメディアデータ送信要求を送信する。
【００３８】
以上のように本実施形態においては、メディアデータ送信装置がメディアデータ受信装置から要求されたメディアデータ送信を第二のメディアデータ送信装置に委託した後、リソースの回復により新規メディアデータ送信可能となる。その場合、メディアデータ送信装置は、新規メディアデータ送信可能である旨を第二のメディアデータ送信装置に通知する。これにより、複数のメディアデータ送信装置のリソースを効率的に使用しつつ、できる限りメディアデータ受信装置が本来要求したメディアデータ送信装置からのメディアデータを受信することが可能となる。
【００３９】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００４０】
以上、上述した各実施形態によれば、データ送信装置がデータ受信装置からの要求命令実行不可状態で新たな命令実行要求があった場合、第二のデータ送信装置に命令実行を委託する。このことにより、メディアデータ受信装置が複数のデータ送信装置のネットワーク構造を把握せずともリソースを効率的に使用することを可能とすることができる。
【００４１】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００４２】
１０１  メディアデータ送信装置、１０２  メディアデータ受信装置
【図１】
0005991734.tif 000002
【図２】
0005991734.tif 000003
【図３】
0005991734.tif 000004
【図４】
0005991734.tif 000005
【図５】
0005991734.tif 000006
【図６】
0005991734.tif 000007
【図７】
0005991734.tif 000008
【図８】
0005991734.tif 000009
【図９】
0005991734.tif 000010
【図１０】
0005991734.tif 000011
【図１１】
0005991734.tif 000012
【図１２】
0005991734.tif 000013