(57)【要約】【課題】クライアントがカメラからの画像を適切に受信できるようにする。【解決手段】外部装置から映像を受信する受信処理を実行する情報処理装置は、外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する。情報処理装置は、映像ストリームが受信されたと判定された場合は外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、映像ストリームが受信されなかったと判定された場合は外部装置へ映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する。【選択図】  図６
2019050487.tif 000002
【特許請求の範囲】
【請求項１】
外部装置から映像を受信する受信処理を実行する情報処理装置であって、
前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定手段と、
前記判定手段により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行手段と、を備えることを特徴とする情報処理装置。
【請求項２】
前記受信処理の起動時に、前記判定手段を実行することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信処理は起動時に前記ストリーム受信動作を実行し、
前記実行手段は、前記判定手段により映像ストリームが受信されたと判定された場合は前記ストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は、前記ストリームリクエストをキャンセルして前記個別受信動作を開始することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記実行手段が前記個別受信動作を実行した場合、前記受信処理の次回の起動時に、前記ストリームリクエストを用いた判定を行わずに前記個別受信動作を実行することを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
前記実行手段が前記個別受信動作を実行して画像を受信できた場合、前記受信処理の次回の起動時には前記判定手段による判定を行わずに前記個別受信動作を実行し、
前記実行手段が前記個別受信動作を実行して画像を受信できなかった場合、前記受信処理の次回の起動時には前記ストリーム受信動作を実行して前記判定手段による判定を行う、ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記ストリーム受信動作により受信された映像ストリームまたは前記個別受信動作により受信した画像を表示装置に表示させる表示制御手段をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
前記表示制御手段は、前記ストリーム受信動作と前記個別受信動作のいずれが実行されているかを明示する表示を行わせることを特徴とする請求項６に記載の情報処理装置。
【請求項８】
外部装置から映像を受信する受信処理を実行する情報処理装置であって、
前記受信処理の起動時に、個別リクエストを送信して対応する返答を受信するまでの第１の時間と、所定のデータ量のストリームを送信させる部分ストリームリクエストを送信して対応する返答を受信するまでの第２の時間とを計測する計測手段と、
前記第１の時間と前記第２の時間との比または差に基づいて、前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作と、前記外部装置へ個別リクエストを送信して画像を受信する個別受信動作のいずれを実行するかを決定する決定手段と、を備えることを特徴とする情報処理装置。
【請求項９】
前記個別リクエストに対応する返答は前記外部装置が撮影した個別の画像であり、前記部分ストリームリクエストに対応する返答は前記外部装置が撮影した所定枚数の映像のストリームであることを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記決定手段は、前記第１の時間を前記第２の時間で割った値が所定値以上の場合に、前記ストリーム受信動作を実行すると決定することを特徴とする請求項８または９に記載の情報処理装置。
【請求項１１】
前記決定手段は、前記第１の時間と前記第２の時間の差が閾値以下の場合に、前記ストリーム受信動作を実行すると決定することを特徴とする請求項８乃至１０のいずれか１項に記載の情報処理装置。
【請求項１２】
外部装置から映像を受信する受信処理を実行する情報処理装置の制御方法であって、
前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定工程と、
前記判定工程により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定工程により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項１３】
外部装置から映像を受信する受信処理を実行する情報処理装置の制御方法であって、
前記受信処理の起動時に、個別リクエストを送信して対応する返答を受信するまでの第１の時間と、所定のデータ量のストリームを送信させる部分ストリームリクエストを送信して対応する返答を受信するまでの第２の時間とを計測する計測工程と、
前記第１の時間と前記第２の時間と比または差に基づいて、前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作と、前記外部装置へ個別リクエストを送信して画像を受信する個別受信動作のいずれを実行するかを決定する決定工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項１４】
コンピュータを、請求項１乃至１１のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびその制御方法に関する。
【背景技術】
【０００２】
ネットワークカメラからの映像の配信はクライアントからの１つのリクエストに対して複数の画像（映像ストリーム）を配信するストリーム配信と、クライアントからの１つのリクエストに対して１つの画像（個別画像）を送信する個別配信がある。一般に、ストリーム受信可能なクライアントは高速受信するためにストリーム配信をリクエストし、映像ストリームを受信して表示する。一方、ストリーム受信不可能なクライアントは個別配信をリクエストし、個別画像を受信して表示する。
【０００３】
ストリーム配信では、ネットワークカメラがクライアントからリクエストを受信すると一方的に配信を行うため高速な配信が可能となる。よって、ストリーム配信は高速で映像を表示したい時に利用される。個別配信では、ネットワークカメラがクライアントから個別リクエストを受信して個別の画像を送信するという動作が繰り返される。個別配信はクライアントの環境を選ばず例えばブラウザ上でも表示が可能である。
【０００４】
このようなストリーム配信と個別配信の両方を場合に応じて選択して利用するクライアントが提案されている。特許文献１では、通常はストリーム配信を表示し、映像ストリームの切り替えの際に画像が乱れてしまう場合に、個別配信の画像を表示する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２１１５０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、クライアントがストリーム受信をリクエストした場合に、特にプロキシを介した通信により映像ストリームの受信を行う際には映像ストリームを受信できない場合がある。これは、画像ソースからデータが分割送信された場合に、プロキシがそれらの分割されたデータを貯め込み、すべてのデータを受信してからまとめて送信する場合があるからである。映像ストリームのような分割データの送信は、例えばｈｔｔｐのチャンク形式などを用いて行われる。チャンク形式では、分割されたデータが途中データなのか最終データなのか分かる形式で送信される。プロキシは、画像ソースから最終データが受信されるまでデータ（途中データ）を蓄積し、最終データが受信されると、それまでに蓄積したデータをまとめてクライアントへ送信する。
【０００７】
画像ソースがカメラの場合、映像ストリームのデータ（分割データ）は例えばチャンク形式における途中データが送り続けられる。この場合、最終データが受信されないため、プロキシはカメラから受信した映像を貯め込むだけでクライアントに送信しない。その結果、映像はいつまでたってもクライアントに届かず、クライアントでは映像がまったく表示されないという課題が発生する。
【０００８】
本発明は、上記の課題に鑑みてなされたものであり、クライアントがカメラからの画像を適切に受信できるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一態様による情報処理装置は以下の構成を備える。すなわち、
外部装置から映像を受信する受信処理を実行する情報処理装置であって、
前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定手段と、
前記判定手段により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行手段と、を備える。
【発明の効果】
【００１０】
本発明によれば、クライアントがカメラからの画像を適切に受信できる。
【図面の簡単な説明】
【００１１】
【図１】カメラのストリーム配信と個別配信を説明する図。
【図２】プロキシの介在による分割送信の動作を説明する図。
【図３】プロキシの介在によりクライアントに映像ストリームが届かない様子を示す図。
【図４】実施形態によるカメラおよびクライアントの機能構成例を示すブロック図。
【図５】クライアントで表示されるビューワ画面を示す図。
【図６】第１実施形態のクライアント、プロキシ、カメラの動作を説明する図。
【図７】クライアントで表示されるビューワ画面を示す図。
【図８】第１実施形態のクライアント、プロキシ、カメラの動作を説明する図。
【図９Ａ】第１実施形態の受信処理を示すフローチャート。
【図９Ｂ】第１実施形態の受信処理を示すフローチャート。
【図１０】第２実施形態のクライアント、プロキシ、カメラの動作を説明する図。
【図１１】第２実施形態の受信処理を示すフローチャート。
【図１２】実施形態によるクライアントのハードウエア構成例を示すブロック図。
【発明を実施するための形態】
【００１２】
＜第１実施形態＞
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。
【００１３】
まず、実施形態によるストリーム配信と個別配信について図１を用いて説明する。図１（ａ）はストリーム配信をクライアントで受信して表示する場合のシーケンス図である。クライアント１０１が映像ストリームを要求するためのストリームリクエストを送信し（ステップ１１０）、それをカメラ１０２が受信すると（ステップ１１１）、カメラ１０２はストリーム配信を行う（ステップ１１２）。ストリーム配信では、カメラ１０２により撮影された映像が映像ストリームとして送信される。クライアント１０１はカメラ１０２から送信された映像ストリームを受信し表示を行う（ステップ１１３）。
【００１４】
図１（ｂ）はカメラ１０２から個別配信された画像をクライアント１０１で受信して表示する場合のシーケンス図である。クライアント１０１が個別リクエストを送信し（ステップ１２０）、カメラ１０２はこの個別リクエストを受信すると個別配信を行う（ステップ１２１）。個別配信では、カメラ１０２により撮影された映像のうちの１コマ（フレーム）の画像（以下、個別画像ともいう）が配信される。個別配信では、１コマではなく、２コマや３コマなど、複数コマの画像を要求及び配信するようにしてもよい。クライアント１０１は、カメラ１０２が送信した画像を受け取り、表示する（ステップ１２３）。続いて、クライアント１０１は次の個別リクエストを送ると（ステップ１２４）、カメラ１０２はこの個別リクエストを受信し（ステップ１２５）、次の画像を配信する（ステップ１２６）。クライアント１０１はこの画像を受信し、表示する（ステップ１２７）。この様な動作を繰り返すことにより、クライアント１０１は、カメラ１０２から個別配信により受信された画像を表示する。
【００１５】
次に、図２、図３を参照して、クライアント１０１と画像ソースの間にデータ送信を中継するプロキシ１０３が介在し、プロキシ１０３が分割された途中データを貯め込んでから送信する設定となっている場合を説明する。
【００１６】
図２（ａ）は、クライアント１０１がプロキシ１０３経由で画像ソースとしてのサーバ１０４と繋がっている事を示している。図２（ｂ）は、途中データを溜め込んでから一度に送信する設定となっているプロキシ１０３が介在する場合の動作を示すシーケンス図である。まず、クライアント１０１はサーバ１０４に対してリクエストを送信する（ステップ２００）。プロキシ１０３はこのリクエストを受け取るとそのままサーバ１０４へ送信する（ステップ２１０）。サーバ１０４はリクエストを受信すると（ステップ２２０）、送信対象のデータを分割して送信することにより返答を行う（ステップ２２１）。データの分割および配信には、例えばｈｔｔｐのチャンク形式が用いられ得る。ステップ２２１において送信されるデータはデータが終了という情報が付加されていない途中データであり、プロキシ１０３はこれらのデータを貯めておく（ステップ２１１）。その後、サーバ１０４が分割データの最終であることを示した最終データを送信する（ステップ２２２）。プロキシ１０３は、この最終データを受信すると（ステップ２１２）、プロキシ１０３は、それまでに貯めておいた途中データと最終データをまとめてクライアント１０１へ送信する（ステップ２１３）。こうして、クライアント１０１は、分割して送信されたデータをまとめて受信する（ステップ２０１）。
【００１７】
次に、図３（ａ）を参照して、途中データを貯め込むプロキシ１０３を介して、カメラ１０２の映像を図１（ａ）のようなストリーム配信で受信しようとした場合の動作を説明する。
【００１８】
クライアント１０１はプロキシ１０３を経由してインターネット上にあるカメラ１０２につながっている。まず、クライアント１０１はストリームリクエストを送信する（ステップ３００）。プロキシ１０３はこのストリームリクエストを受信すると、そのままカメラ１０２に送信する（ステップ３１０）。カメラ１０２では、ストリームリクエストを受信すると（ステップ３２０）、撮影により得られた映像をストリーム映像の形式で返信する（ステップ３２１）。ここで、カメラ１０２からは、例えばチャンク形式における終了情報のない途中データとして、映像ストリームが送り続けられる。カメラ１０２からはいつまでたっても終了データが付加されたデータが送信されないので、プロキシ１０３は途中データであるストリームデータを貯め込むだけでクライアント１０１に映像を送信しない（ステップ３１１）。その結果、クライアント１０１では映像をいつまでたっても受信することができず、映像を表示することができない（ステップ３０１）。
【００１９】
図４は、本実施形態のクライアント１０１およびカメラ１０２の機能構成例を示すブロック図である。クライアント１０１は、外部装置であるカメラ１０２から映像を受信する受信処理を実行する。
【００２０】
本実施形態では、クライアント１０１とカメラ１０２がネットワーク４５０によって、不図示のプロキシを介して接続されている。ネットワーク４５０に接続されるクライアントおよびカメラの数に制限はないが、説明の簡略化のため各々１台ずつが接続されていると仮定する。ネットワーク４５０に関しても、後で述べるカメラ制御信号、圧縮した画像信号を通すのに十分な帯域があるディジタルネットワークであれば、インターネットやイントラネット等、どのようなものでもよい。なお、本実施形態ではネットワークプロトコルとしてＴＣＰ／ＩＰ（ＵＤＰ／ＩＰ）プロトコルを仮定し、以下アドレスといった場合にはＩＰアドレスを指すこととする。また、クライアント１０１およびカメラ１０２は、共にＩＰアドレスを割り当てられているものとする。
【００２１】
本実施形態のカメラ１０２はカメラ機能と映像を配信するサーバ機能を有する、カメラサーバ装置である。なお、カメラ機能とサーバ機能は別体の装置により実現されてもよいし、１つの装置として実現されてもよい。カメラ１０２は、通信制御部４１４でクライアントから受信したコマンドに応じて、ネットワーク４５０を介して画像データを配信するともに、各種カメラ制御を実行する。画像入力部４１５はビデオカメラ４１１による撮影画像（動画および静止画）を取り込む。画像入力部４１５は、全体画像を扱うように設定されている場合は画像全体を取り込み、切り出し画像を扱うように設定されている場合には画像の一部を取り込む。取り込まれた撮影画像は、画像圧縮部４１６によってクライアント１０１に配信しやすいデータサイズに圧縮される。記憶部４１８は各種設定値およびデータを保持する。
【００２２】
ビデオカメラ４１１は可動雲台４１２に取り付けられている。カメラ・雲台制御部４１３は、通信制御部４１４が受信し、コマンド解釈部４１７が解釈したコマンドによって指定される制御内容に応じて可動雲台４１２を制御する。これにより、例えばビデオカメラ４１１のパン・チルト・ローテート角度が制御される。
【００２３】
認証部４１９は通信制御部４１４を介して認証情報が送られてきたときに認証を許可するか否かを判断する。カメラ１０２にはゲストと管理者というユーザ操作モードがあるが、ゲストと管理者では実行可能な機能が異なる。認証部４１９ではユーザが入力した文字列とパスワードを用いて認証を行い、認証に成功すればユーザが管理者であると認定して、管理者用の操作モードへ移行する。管理者用の操作モードでは、管理者でなければ行えない機能等を受け付ける。
【００２４】
画像圧縮部４１６は、ビデオカメラ４１１からのＮＴＳＣ画像信号を取り込み、Ａ／Ｄ変換後、ＭｏｔｉｏｎＪＥＰＧで圧縮して、通信制御部４１４に渡す。通信制御部４１４は、圧縮された画像をネットワーク４５０に送出する。なお、ここでは画像の圧縮形式として、ＭｏｔｉｏｎＪＥＰＧ圧縮としたが、この圧縮形式に限定されるものではない。また、カメラ１０２は一つのストリームリクエストで映像ストリームを配信するストリーム配信と、一つの個別リクエストで一つの画像（個別画像）を送信する個別配信の両方に対応している。
【００２５】
クライアント１０１は、カメラ１０２に割り当てられているＩＰアドレスを指定して、ネットワーク４５０を介してカメラ１０２に接続し、通信を確立する。クライアント１０１において、通信制御部４２１は、カメラ１０２から送信された撮影画像データ（映像ストリームまたは個別画像）、および記憶部４１８に保持されていたパノラマ画像データを受信する。また、通信制御部４２１は、カメラ１０２から各種カメラ制御の結果を受信する。制御部４２４は、クライアント１０１によるストリーム受信モードの動作、個別受信モードの動作を含む、各種動作を制御する。また、制御部４２４は、図９Ａ、９Ｂにより後述する受信処理を実行する。また、制御部４２４は、画像伸長部４２５で展開された撮影画像およびパノラマ画像、各種カメラ制御の結果からグラフィカルユーザインタフェース（ＧＵＩ）を生成し、表示部４２６に表示するよう制御する。操作入力部４２３はユーザのマウスやキーボードによるＧＵＩ操作を受け付ける。コマンド生成部４２２は、パノラマ画像上でのマウスクリックや、ビデオカメラ４１１のパン・チルト・ローテート・ズーム位置を表す枠のドラッグといったＧＵＩ操作から各種カメラ制御コマンドを生成する。受信する画像のサイズのコマンド、切り出し配信のコマンドなどもコマンド生成部４２２で生成される。生成された各種カメラ制御コマンドは通信制御部４２１からカメラ１０２に送信される。またタイマ４３０はストリームリクエストを発行してからの時間を計測する。タイマ４３０は、表示制御のタイムアウト判定などに使用される。
【００２６】
図１２は、クライアント１０１のハードウエア構成例を示すブロック図である。クライアント１０１は情報処理装置であり、たとえば汎用コンピュータ装置により実現される。ＣＰＵ１２０１は、ＲＯＭ１２０２またはＲＡＭ１２０３に格納されたプログラムを実行することにより種々の制御を実現する。ＲＯＭ１２０２およびＲＡＭ１２０３はＣＰＵ１２０１に接続されたメモリの一例である。ＲＯＭ１２０２は読み出し専用の不揮発性メモリである。ＲＡＭ１２０３は、随時書き込みが可能な揮発性メモリである。図４に示したクライアント１０１の各機能部の少なくとも一部は、ＣＰＵ１２０１が所定のプログラムを実行することにより実現される。
【００２７】
表示装置１２０４は表示部４２６を構成し、ＣＰＵ１２０１の制御下で種々の表示を行う。二次記憶装置１２０５は例えばハードディスクであり、各種データを保存する。なお、二次記憶装置１２０５にＣＰＵ１２０１が実行するためのプログラムを格納しておき、必要に応じてＲＡＭ１２０３に展開し、ＣＰＵ１２０１により実行されるようにしてもよい。入力装置１２０６は、キーボード、マウスなどを有し、操作入力部４２３を構成する。なお、入力装置１２０６は、表示装置１２０４の表示画面に設けられたタッチパネルを備えてもよい。ネットワークインターフェース１２０７はネットワーク４５０とクライアント１０１を接続するインターフェースである。上述した各構成は、バス１２０８を介して相互に通信可能に接続されている。
【００２８】
次に図５を参照して本実施形態のＧＵＩ画面（ビューワ画面５００）について説明する。ビューワ画面５００において、映像表示領域５０１にカメラ１０２から配信された映像が表示される。操作バー５１１，５１２，５１３によりパン、チルト、ズームの操作が可能である。スナップショットボタン５１４は、静止画を取るときに利用される。画像サイズ設定セレクタ５１５は、現在の映像サイズを表示するとともに、表示する映像サイズを切り換えるのに用いられる。映像表示領域５０１には、図１（ａ）で説明したストリーム配信により得られた画像、および、図１（ｂ）で説明した個別配信により得られた画像を表示する事が可能となっている。
【００２９】
次に図６を参照してクライアント１０１とカメラ１０２と間の映像のやりとりを説明する。
【００３０】
本実施形態のクライアント１０１で稼働する受信処理（ビューワ）は、最初にストリームリクエストをカメラに投げる。クライアント１０１は、通常は図１（ａ）の様な手順で映像ストリームを受信し、映像を表示する。これに対して、図６に示されている動作シーケンスは、図３で説明したような、クライアント１０１とカメラ１０２の間に分割データを貯めてから一度に送信するプロキシ１０３が介在する場合の動作を示している。まずクライアント１０１はストリームリクエストをカメラ１０２に対して送信する（ステップ６００）。プロキシ１０３は、このリクエストを受信すると、そのままカメラ１０２に送信する（ステップ６１０）。こうして、クライアント１０１から送信されたストリームリクエストはプロキシ１０３を経由してカメラ１０２により受信される（ステップ６２０）。カメラ１０２は、このストリームリクエストに応じて映像ストリームを配信する（ステップ６２１）。配信される映像ストリームは途中データであり、プロキシ１０３が途中データを貯め込む（ステップ６１１）ためクライアント１０１は映像を受信しない。
【００３１】
クライアント１０１では、ストリームリクエストを送信した後、タイマ４３０を起動し（ステップ６３０）、ストリームリクエストを送信してからの経過時間を計測する。タイマ４３０の値が所定値（例えば３秒）になるまでに映像ストリームが受信されなかった場合（ステップ６３１）、クライアント１０１は個別配信により画像を受信するべく個別リクエストの送信を始める（ステップ６０２）。個別リクエストがプロキシ１０３を介してカメラ１０２に受信されると、カメラ１０２は画像を送信する（ステップ６２３）。送信された画像はプロキシ１０３を介してクライアント１０１により受信され、映像表示領域５０１に表示される（ステップ６０２）。個別の画像が送信される場合、分割データの形式ではないため、プロキシ１０３で貯め込まれることはない。以上のような個別配信が繰り返されることで（ステップ６０３、６２４、６０４）、クライアント１０１はカメラ１０２が配信した画像を受信し映像として表示することができる。
【００３２】
図７は図６のステップ６０２以降の個別配信により映像を表示している時のＧＵＩを示す図である。図７で示すように映像表示領域５０１には個別配信により受信した画像が表示される。また、領域７０１には「映像ストリームタイムアウトにより個別リクエストで映像を引いています。」と表示され、ストリーム配信から個別配信に切り替わった事をユーザに明示している。この表示により、ユーザは、クライアント１０１が、ストリームリクエストに応じた映像ストリームを受信するストリーム受信動作を実行しているのか、個別リクエストに応じた個別画像を受信する個別受信動作を実行しているのかを把握できる。
【００３３】
図８（ａ）は、図６の様にタイムアウトが発生して個別配信に切り替わった後に受信処理が終了し、その後、受信処理が起動された場合に、クライアント１０１がカメラ１０２から画像を取得する際のやり取りを示している。この場合、再度、図６と同じシーケンスにすると、すなわち、ストリームリクエストにより映像ストリームを受信しようとすると、映像を受信しないまま３秒のタイムアウトが発生する可能性が高い。したがって、クライアント１０１は、最初から図１（ｂ）で説明した個別配信により映像を受信して表示する。すなわち、受信処理が起動されると、クライアント１０１は個別リクエストを送信（ステップ８００、８０２、８０４）する。カメラ１０２はこれを受信して（ステップ８２０、８２２，８２４）画像を送信する（ステップ８２１、８２３、８２５）。クライアント１０１は、画像を受信し表示を行う（ステップ８０１、８０３、８０５）。
【００３４】
なお、図８（ａ）に示されるように、初めから個別配信に処理が切り替わるのは、図６で示した個別リクエストに切り替えて画像を表示できた場合に限るようにするのがよい。その理由は次のとおりである。図８（ｂ）で示すように、クライアント１０１は、ストリームリクエストを送信した後（ステップ８０５）、映像を受信できずにタイムアウトすると個別リクエストを送信する（ステップ８０６、８０７）。図８（ｂ）に示されるように、これら個別リクエストに対してもカメラ１０２から返事がない場合は、カメラ１０２側に不具合があると考えらえる。カメラ１０２の不具合が解消された後は、高速で映像表示を行う事が可能なストリーム受信で受信を行いたいため、まずはストリーム配信を試すことが望ましい。
【００３５】
次に、以上に説明した処理について図９Ａのフローチャートを参照してさらに説明する。図９Ａは図５で示したビューワを開いた時にクライアント１０１で開始される処理（受信処理）である。
【００３６】
まずステップＳ９０１で、制御部４２４は個別フラグがＯｎであるか否かを判断する。この個別フラグは初期時にはＯｆｆが設定されている。この個別フラグをＯｎにするタイミングについては後述する。ステップＳ９０１で個別フラグがＯｎでないと判断された場合、ステップＳ９０２において、制御部４２４は、ストリーム配信により配信されたストリームを受信するために、受信モードをストリーム受信モードに設定し、映像ストリームを受信する準備を行う。次に、制御部４２４は、ステップＳ９０３においてカメラ１０２にストリームリクエストを送信し、ステップＳ９０４においてタイマ４３０を起動してストリームリクエストを送信してからの経過時間の計測（タイムアウトカウント）を開始する。
【００３７】
次に、ステップＳ９０５において、制御部４２４は、映像ストリームの受信が開始されたか否かを判断する。ステップＳ９０５で映像ストリームの受信が開始されていないと判断された場合、ステップＳ９０８において、制御部４２４は、ステップＳ９０４で開始したタイムアウトカウントが３秒を超えたか否かを判断する。タイムアウトカウントが３秒以内であれば、ステップＳ９０５の処理を繰り返す。
【００３８】
ステップＳ９０５で映像受信が開始されたと判断された場合、ステップＳ９０６において、制御部４２４はストリーム受信動作を継続する。すなわち、ステップＳ９０１で設定されたストリーム受信モードによるストリーム受信動作が継続される。ステップＳ９０７でストリーム受信動作の終了か否かを判断する。ステップＳ９０７でストリーム受信動作の終了と判断された場合、本処理は終了する。ストリーム受信動作の終了ではないと判断された場合は、ステップＳ９０６のストリーム受信動作が繰り返される。ここでストリーム受信動作の終了とはビューワのアプリケーションを閉じるなどの事を指す。
【００３９】
一方、ステップＳ９０８でタイムアウトカウントが３秒より大きいと判断された場合は、途中データを貯め込むプロキシが介在していると判断し、ステップＳ９０９において、制御部４２４は、映像ストリームをキャンセルする。そして、ステップＳ９１０において、制御部４２４は、受信モードを個別配信による画像を受信するための個別受信モードに設定する。個別受信モードでは、制御部４２４は、映像ストリームに含まれる画像を個別に要求する個別リクエストにより個別画像を受信し、表示する。以下、具体的に説明する。
【００４０】
まず、ステップＳ９１１で制御部４２４は、個別フラグをＯｎにする。この個別フラグがＯｎであることにより、ステップＳ９０１で示すように、次回の起動時に個別配信での動作が実行される。次に、ステップＳ９１２において、制御部４２４は、個別リクエストを送信して個別画像のリクエストを行う。そして、ステップＳ９１３において、制御部４２４は、個別画像を受信し、表示する。ステップＳ９１４において、制御部４２４は、個別受信動作の終了か否かを判断する。個別受信動作の終了であると判断した場合、本処理は終了する。個別受信動作の終了でないと判断した場合、ステップＳ９１２以降の処理が繰り返される。個別フラグがＯｎの状態で受信処理が終了した場合、すなわち個別受信動作が実行された場合は、受信処理の次回の起動時には、ストリームリクエストを用いた判定を行わずに個別受信動作を実行するのが好ましい。なぜなら、ストリームリクエストを行ってもプロキシ１０３の介在によりタイムアウトしてしまう可能性が高いからである。したがって、本実施形態の受信処理では、起動時に個別フラグがＯｎである場合には、最初から個別受信モードで動作するようにしている（ステップＳ９０１でＹＥＳ→ステップＳ９１０）。
【００４１】
また、上述したように、個別リクエストに対してもカメラ１０２から返事がない場合は、カメラ１０２側に不具合があると考えられる。そのような場合は、ユーザは、不具合が解消された後は高速で映像表示を行う事が可能なストリーム受信で受信を行いたいと考えるであろう。したがって、ステップＳ９１３において、個別リクエストに対する画像が所定時間内に受信されなかった場合、制御部４２４は、ステップＳ９１１でＯｎにした個別フラグをＯｆｆにして本処理を終了する。この処理を図９Ｂに示す。図９ＢのステップＳ９２１〜Ｓ９２５は、ステップＳ９１２〜Ｓ９１３の処理の詳細を示している。制御部４２４は、ステップＳ９２１において個別リクエストを送信するとともに、タイマ４３０を起動してタイムアウトカウントを開始する。ステップＳ９２２において、制御部４２４は、個別リクエストに対する画像が受信されたか否かを判定する。画像が受信された場合、ステップＳ９２３において、制御部４２４は、個別画像の受信を行う。一方、ステップＳ９２２において画像が受信されていないと判定された場合、ステップＳ９２４において、制御部４２４は、タイムアウトカウントが所定値を超えたか否かを判定する。タイムアウトカウントが所定値以下であれば、処理はステップＳ９２２に戻る。ステップＳ９２４においてタイムアウトカウントが所定値を超えた場合、ステップＳ９２５において、制御部４２４は個別フラグをＯｆｆにして、受信処理を終了する。こうして、個別受信動作を実行して画像を受信できた場合には、受信処理の次回の起動時に最初から個別受信モードが設定される。また、個別受信動作を実行しても画像を受信できなかった場合には、受信処理の次回の起動時には、ストリーム受信モードが設定されて、ステップＳ９０３〜Ｓ９０８の判定が行われる。
【００４２】
以上説明したように、第１実施形態によれば、途中に映像を貯めこんでしまうプロキシサーバが介在した場合には、映像ストリームを受信し表示する動作から個別画像を受信し表示する動作に切り替える事が可能となる。したがって、そのようなプロキシが介在する環境下、介在しない環境下のいずれにおいてもカメラからの映像を見ることができる。
【００４３】
＜第２実施形態＞
第１実施形態では、ストリームリクエストを送信してから所定時間内に映像ストリームの受信を開始できない場合に個別リクエストによる映像の受信に切り替えるように制御した。第２実施形態では、個別リクエストによる個別画像の到着に要した時間と、部分ストリームリクエストによる映像ストリームの到着に要した時間とに基づいて、ストリーム配信か個別配信のいずれかを選択する。なお、第２実施形態のクライアント１０１、カメラ１０２の構成、ストリーム配信および個別配信の基本的な動作は第１実施形態と同様である。
【００４４】
図１０は、第２実施形態において、映像の本配信をリクエストする前のカメラ１０２とクライアント１０１のやり取りを示したシーケンス図である。この処理により、本配信をリクエストする前に、図２あるいは図３で示したような、途中データを貯め込むプロキシが介在する環境であるか否かを判断する。以下、この処理を環境判定処理と称する。クライアント１０１は、環境判定処理により、カメラ１０２による本番の映像の配信（以下、本配信）をストリーム配信で行うか個別配信で行うかを、本配信の実行前に決定することができる。
【００４５】
環境判定処理により途中データを貯め込むプロキシ１０３が介在するか否かの判断に仕方について説明する。個別リクエストの場合、途中データを貯め込む設定のプロキシが介在する場合でもすぐにカメラ１０２からの返信が届く。一方、ストリーム配信の場合、途中データを貯め込む設定のプロキシが介在すると、すべてのデータが貯まった時点でデータが返ってくるため、最初のデータが返ってくるまでの時間が多くかかる。これを用いて、個別リクエストの送信から最初の返答までの時間と、ストリームリクエストの送信から最初の返答までの時間との差が大きい時には、プロキシが途中でデータを貯め込んでいると判断する。
【００４６】
図１０（ａ）は、途中データを貯め込むプロキシが介在しないネットワークの環境でこの判定を行った時のシーケンス図である。クライアント１０１は、まず個別リクエストを送る（ステップ１０００）。カメラ１０２はこの個別リクエストを受信すると（ステップ１０１０）、個別リクエストに対する返答（個別画像）を送信する（ステップ１０１１）。クライアント１０１は、この返答を受信し（ステップ１００１）、個別リクエストの送信（ステップ１０００）から返答の受信（ステップ１００１）での時間を第１の時間として保持しておく。次に、クライアント１０１は部分ストリームリクエストを送る（ステップ１００２）。部分ストリームリクエストは、カメラ１０２に所定のデータ量のストリームを配信させるものである。本実施形態では、所定枚数の映像をストリーム、例えば５枚の映像ストリームを配信させるものとする。カメラ１０２は、この部分ストリームリクエストを受信すると（ステップ１０１２）、リクエストされた部分ストリーム（５枚の映像）を返す（ステップ１０１３〜ステップ１０１７）。クライアント１０１は、カメラ１０２から送信された映像を受け取る（ステップ１００３〜ステップ１００７）。クライアント１０１は、部分ストリームリクエストの送信（ステップ１００２）から最初の映像の受信（ステップ１００３）までの時間を第２の時間として得る。
【００４７】
本実施形態では、環境判定処理において第１の時間と第２の時間との比または差に基づいて、ストリーム受信動作と、個別受信動作のいずれを実行するかが決定される。例えば、第１の時間と第２の時間の差が閾値以下の場合、または、第１の時間を第２の時間で割った値が所定値以上の場合に、ストリーム受信動作を実行すると決定する。図１０（ａ）では、保持されているステップ１０００からステップ１００１までの第１の時間と、ステップ１００２からステップ１００３までの第２の時間との差は小さいため、通常の環境（データを貯め込むプロキシが介在しない環境）であると判断する。なお、第１の時間と第２の時間の比を用いて決定を行う場合、本実施形態では、誤差を考慮して、第１の時間と第２の時間に２倍以上の差がない場合は、両者の差は小さいと判断している。
【００４８】
次に図１０（ｂ）を用いて図１０（ａ）と同じ処理を、途中データを貯め込むプロキシが介在した状態で行った場合を説明する。まず、クライアント１０１は個別リクエストをカメラ１０２に送信する（ステップ１０２０）。カメラ１０２は、このリクエストを受信し（ステップ１０３０）、受信したリクエストに対する返答（個別画像）を送信する（ステップ１０３１）。クライアント１０１はこの返答を受信する（ステップ１０２１）。クライアント１０１は、個別リクエストの送信（ステップ１０２０）から返答の受信（ステップ１０２１）までの時間を求め、第１の時間として保持しておく。
【００４９】
次に、クライアント１０１は、部分ストリームリクエストを送信する（ステップ１０２２）。部分ストリームリクエストについては上述したとおりである。カメラ１０２は、部分ストリームリクエストを受信すると（ステップ１０３２）、リクエストされた部分ストリームを返す（ステップ１０３３〜ステップ１０３７）。プロキシ１０３は、終了の情報がある部分ストリームが来るまで、これらの部分ストリームを貯め込む（ステップ１０４０）。プロキシは、終了の情報を有する部分ストリームを受信すると、貯め込んだすべての部分ストリームをクライアント１０１に送信する（ステップ１０４１）。クライアント１０１では、これを部分ストリームリクエストに対する返答として受け取る（ステップ１００３）。クライアント１０１は、部分ストリームリクエストの送信（ステップ１０２２）から返答の受信（ステップ１０２３）までの第２の時間を求める。図１０（ｂ）の場合、ステップ１０２０からステップ１０２１までの第１の時間と、ステップ１０２２からステップ１０２３までの第２の時間との差が大きいため、データを貯め込むプロキシが介在する環境であると判断する。上述のように、第１の時間と第２の時間に２倍以上の差がある場合に両者の差は大きいと判断する。
【００５０】
以上説明した環境判定処理を含む、第２実施形態のクライアント１０１によるビューワの受信処理について図１１のフローチャートを用いて説明する。図１１において、ステップＳ１１０１〜Ｓ１１０９が環境判定処理に対応する。
【００５１】
ステップＳ１１０１で、制御部４２４は、個別リクエストを送信する。次にステップＳ１１０２で、タイマ４３０を起動する。この際、タイマ４３０のカウントは０から開始される。次にステップＳ１１０３において、制御部４２４は、ステップＳ１１０１で送信したリクエストに対応する返答を受信したかどうかを判断する。返答が受信されるまでステップＳ１１０３が繰り返される。ステップＳ１１０３で返答が受信されると、ステップＳ１１０４において、制御部４２４は、タイマ４３０の値（タイマカウントという）をカウント１に代入する。結果、カウント１には個別リクエストを送信してからその返答を受信するまでの時間が入る。
【００５２】
次に、ステップＳ１１０５において、制御部４２４は、部分ストリームリクエストをカメラ１０２に送信する。そして、ステップＳ１１０６において、制御部４２４は、タイマ４３０を開始する。タイマ４３０は０から開始される。その後、ステップＳ１１０７において、制御部４２４は、部分ストリームリクエストに対する最初の返答が受信されるのを待つ。返答が受信されると、ステップＳ１１０８において、制御部４２４は、カウント２に現在のタイマカウントを代入する。結果、カウント２には部分ストリームリクエストを送信してから最初の返答が受信されるまでの時間が入る。
【００５３】
ステップＳ１１０９において、制御部４２４は、カウント１とカウント２に保持されている時間を比較し、カウント１÷カウント２の値が０．５より大きいか否かを判断する。つまり個別リクエストに対する返答に要した第１の時間と部分ストリームリクエストに対する返答に要した第２の時間があまり変わらないのか否かが判断される。ステップＳ１１０９で０．５より大きい場合は、カウント１とカウント２の時間に大きな差はない、すなわち、途中データを貯め込むプロキシ１０３は介在しないと判断する。この場合、処理はステップＳ１１１０へ進み、映像ストリーム配信を用いて本配信が行われる。すなわち、ステップＳ１１１０において、制御部４２４は、受信モードを、映像ストリームを受信するストリーム受信モードに設定し、ステップＳ１１１１でストリームリクエストを送信する。ステップＳ１１１２で、制御部４２４は、映像ストリームを受信し、表示する。映像ストリームの配信が終了するまでステップＳ１１１２、Ｓ１１１３が繰り返される。
【００５４】
一方、ステップＳ１１０９で０．５以下と判断された場合、処理はステップＳ１１１４に進み、個別配信を用いて本配信が行われる。すなわち、ステップＳ１１１４において、制御部４２４は、受信モードを、個別リクエストにより個別に画像を受信する個別受信モードに設定する。そして、制御部４２４は、ステップＳ１１１５において個別リクエストを送信し、ステップＳ１１１６において個別画像を受信、表示する。ステップＳ１１１７において、制御部４２４は、個別配信の終了か否かを判断し、終了と判断されると本処理を終了する。ステップＳ１１１７で終了でないと判断された場合、処理はステップＳ１１１５に戻り、個別配信が終了するまでステップＳ１１１５〜Ｓ１１１７が繰り返される。
【００５５】
以上説明したように、第２実施形態では、カメラに映像の本配信を開始させる前に、個別リクエストと部分ストリームリクエストについて返答の受信に要する時間を比較する事で、データ（画像）を貯め込むプロキシが介在するか否かを判断する。第２実施形態では、この判断結果に応じて、個別配信にするかストリーム配信にするかを決めるので、ビューワ動作の開始時から適切な受信モードで映像を受信することができる。
【００５６】
なお、上記では、本配信前の環境判定処理で実行される個別リクエストによる配信と部分ストリームリクエストによる配信において、それぞれカメラ１０２が撮影した映像がリクエストに対応する返答として用いられたがこれに限られるものではない。環境判定処理においては、映像、画像以外の予め定められたデータが、リクエストに対応する返答として用いられてもよい。
【００５７】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５８】
１０１：クライアント、１０２：カメラ、１０３：プロキシ、４２１：通信制御部、４２２：コマンド生成部、４２３：操作入力部、４２４：制御部、４２５：画像伸長部、４２６：表示部、４３０：タイマ４
【図１】
2019050487.tif 000003
【図２】
2019050487.tif 000004
【図３】
2019050487.tif 000005
【図４】
2019050487.tif 000006
【図５】
2019050487.tif 000007
【図６】
2019050487.tif 000008
【図７】
2019050487.tif 000009
【図８】
2019050487.tif 000010
【図９Ａ】
2019050487.tif 000011
【図９Ｂ】
2019050487.tif 000012
【図１０】
2019050487.tif 000013
【図１１】
2019050487.tif 000014
【図１２】
2019050487.tif 000015