JP2010258894A - 映像受信装置、映像受信方法及びプログラム - Google Patents

Abstract

【課題】プロトコルの種類によらず、速報性と信頼性とを両立できるようにする。
【解決手段】遅延はあるがフレーム落ちのない第１の映像配信モードと、低遅延だがフレーム落ちのある第２の映像配信モードとを有する映像受信装置において、第１の映像配信モードでフレーム間差分を行い、第２の配信モードで背景差分を行う動体検知手段を有する。また再送機能を有する低遅延かつフレーム落ちのない第３の映像配信モードを有する映像受信装置において、再送発生時にも動体検知を行い仮のイベントを発行する手段と、再送完了時に再度動体検知処理を行い、正イベントないしは訂正イベントを発行する手段とを設ける。
【選択図】図１

Description

本発明は映像受信装置、映像受信方法及びプログラムに関し、特に、ライブ映像を受信するために用いて好適な技術に関する。

近年、ネットワークカメラによるライブ映像配信が実用化されている。また、受信した映像データに対して画像処理による動体検知や不動体検知を行い、検知と連動した外部機器の制御や録画などのイベント通知処理がなされている。

例えば、特許文献１では、動き検出した画像の部分領域は信頼度の高い通信プロトコルを用い、それ以外の部分領域は信頼度の低いプロトコルを用いる映像通信方式が開示されている。また、特許文献２では、動体検知の状態によって、ライブ映像の配信フレームレートを変更する方式が開示されている。

特開２０００−２９８６６１号公報 特開２００６−２７９４６４号公報

ライブ映像の配信方式では、システムによって異なるプロトコルが使用される。例えばネットワークカメラでは、映像伝送のためのプロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）が用いられることが多い。一方、テレビ会議システムでは、映像伝送のためのプロトコルとしてＲＴＰ（Real Time Transfer Protocol）が用いられることが多い。ここで、ＨＴＴＰは仮想回路型通信であるＴＣＰを用いており、データの到着が保証されているが遅延が発生することがある。一方、ＲＴＰはデータグラム型通信であるＵＤＰを用いており、遅延が発生することが少ないもののデータの到着が保証されていない。従来はこのように異なるプロトコルで配送する場合であっても同一の動体検知方式を用いており、その結果検知結果の速報性及び信頼性のいずれかに問題があった。

本発明は前述の問題点に鑑み、プロトコルの種類によらず、速報性と信頼性とを両立できるようにすることを目的としている。

本発明の映像受信装置は、通信手段と画像処理手段とを有する映像受信装置であって、通信プロトコルが異なる複数の映像配信手段に対応する複数の映像受信手段と、前記複数の映像受信手段のそれぞれに対応する複数の画像処理手段とを有することを特徴とする。

本発明によれば、プロトコルの種類に応じて使用する動体検知方法を切り替えることにより、プロトコルの種類に依存しない信頼性の高い動体検知機能を提供できる。また低遅延かつ再送保証を行うプロトコルにおいて、速報性と信頼性を両立したイベント通知機能と提供できる。

本発明の第１の実施形態のシステムの全体構成例を示すブロック図である。 本発明の第１の実施形態における映像配信モードの一例を示す図である。 映像送信装置の映像配信モードの変更処理を示すフローチャートである。 映像受信装置の映像配信モードの変更処理を示すフローチャートである。 映像送信装置と映像受信装置との間のコラボレーションを示す図である。 映像送信装置の映像配信スレッドの処理手順の一例を示すフローチャートである。 映像受信装置のイベント発行処理手順の一例を示すフローチャートである。 映像受信装置のイベント発行処理手順の一例を示すフローチャートである。

（第１の実施形態）
本実施形態ではライブ映像の配信システムにおいて、複数のプロトコルに応じて受信側の動体検知処理を変更する方式を説明する。ここで送信装置はネットワークカメラを想定し、受信装置はビューワアプリケーションや監視カメラアプリケーションを実行するパーソナルコンピュータ（ＰＣ）を想定する。ネットワークカメラ側で動体検知を行うシステムは多数存在するが動体検知機能のない既存カメラやネットワークカメラも多く存在する。したがって、ＰＣ側で動体検知を行うことが要求されることもある。

図１は、本実施形態のシステムの全体構成例を示すブロック図である。図１を用いて本実施形態のシステム構成を説明する。
図１におけるシステムは、ネットワーク経由で接続された映像送信装置１００と映像受信装置２００とから構成される。映像送信装置１００は、映像の撮影と配信を行う機能を有し、例えばネットワークカメラを用いで実現可能である。ここで映像の撮影と配信は同一のデバイスであってもよいし、分離したデバイス構成であってもよい。すなわちビデオキャプチャー機能を持つ映像配信サーバにアナログビデオ信号を入力する構成をとることも可能である。本実施形態は撮影装置の実装方法に依存するものではない。

映像受信装置２００は映像受信部２１１、映像配信制御部２１２、ビデオＲＡＭ２２１、ディスプレイ制御部２２２、動体検知部２４１、動体検知制御部２４２を有する。また、入出力Ｉ／Ｆ２４３、外部記憶制御部２６０、外部記憶装置２６１、ボタン／スイッチ制御部２７０、ボタン／スイッチ２７１を有する。なお、映像受信装置２００は市販のＰＣを用いて実現可能であるが、組み込み機器による実装も可能であり、ＯＳや機器形態に依存するものではない。またディスプレイ２３０は本実施形態において必須ではない。

映像受信装置における処理の流れを説明する。通信インターフェースを有する映像受信部２１１が映像送信装置１００と通信を行い、映像データを取得する。映像データの伝送に使用する通信プロトコルは映像配信制御部２１２が決定し、映像受信部２１１と映像送信装置１００とに伝える。受信した映像データは、ビデオＲＡＭ２２１を経由してディスプレイ２３０に表示される。

また、動体検知部２４１で動体検知処理を行い、その結果を動体検知制御部２４２が判断してイベント通知を発行する。イベント通知は動体検知状態の変化であり、その結果を保存したり、警報装置などの外部機器を入出力Ｉ／Ｆ２４３を経由して制御したり、ネットワーク経由で他の機器に通知したりする。また、映像データは外部記憶制御部２６０経由で外付けのＨＤＤ（Hard Disk Drive）やメモリカードなどの外部記憶装置２６１に保存することも可能である。

図２は、本実施形態における映像配信モードの一例を示す図である。図２おいて、例えば撮影間隔、配送遅延、フレーム欠落、プロトコル、動体検知の異なる二つのモードが存在する。

モード１は、「撮影間隔一定、遅延あり、フレーム欠落なし」であり、プロトコルは例えばＨＴＴＰを使用する。ＨＴＴＰはＴＣＰを用いるコネクション志向のプロトコルであるため、データの到着がプロトコルレベルで保証される代わりに、パケットの送受信状態を確認しながら通信処理を行うためにオーバーヘッドがあり遅延が生じる。モード１はフレーム落ちがないため映像受信装置２００における録画の用途に好適である。

また、モード１における動体検知には画像処理としてフレーム間差分を用いる。フレーム間差分は例えば隣接する２枚のフレーム画像に対する画素値の差分和を用いる動体検知方式であり、処理が軽いことが特徴である。このため、ビューワ側の処理を軽くすることができる。しかし到着フレームの欠落が生じたり、フレーム間の撮影間隔が一定でない場合は正確な検知結果を得ることができなかったりする。

一方、モード２は、「撮影間隔はベストエフォート、遅延なし、フレーム欠落」であり、プロトコルは例えばＲＴＰを使用する。ＲＴＰはＵＤＰを用いるコネクションレス志向のプロトコルであるため、遅延が少ない一方でデータの到着が保証されない。このためフレームに欠落が生じる場合がある。モード２は画像の遅延が少ないためモニタリングやビデオ電話などの用途に好適である。

また、モード２における動体検知処理には画像処理として背景差分を用いる。背景差分は画像の統計的性質に基づいて作成された背景モデルに、現在の画像をあてはめて背景か前景かを判別する方法である。このためフレームの一部が欠落しても背景モデルの作成に与える影響は無視できる。ただしフレーム間差分と比較すると処理の負荷が重く、背景モデル作成時にメモリリソースを消費する。

配信モードの設定は、映像受信装置２００が映像送信装置１００に対して映像配信接続を要求する際に行われる。映像受信装置２００は映像送信装置１００に対してモード情報付の接続要求を行う。これに対して映像送信装置１００は許可または拒否を返信する。このような接続制御を行うプロトコルは例えばＨＴＴＰで実装することが可能である。この場合、例えばＨＴＴＰのBODYにVideoTransferMode=1などと記述して送信を行うと、送信装置からAcceptないしはDeniedなどと返信が返すことにより、許可ないしは拒否が判別できる。同様に他の機器へのイベント通知もＨＴＴＰやＵＰｎＰ（Universal Plug and Play）によって実現が可能である。

図３、図４を用いて本実施形態における映像送信装置１００及び映像受信装置２００の動作手順を説明する。図３は、映像送信装置１００の動作手順のうち、映像配信モードの変更に関する処理手順の一例を示すフローチャートであり、図４は、映像受信装置２００の動作手順のうち、映像配信モードの変更に関する処理手順の一例を示すフローチャートである。

図３において、映像送信装置１００は、処理開始後、ステップＳ３０１でイベントの発生を待つ。そして、イベントの発生を検知すると、ステップＳ３０２で配信モード付き接続要求イベントかどうかを判別する。ここで、配信モード付き接続要求は、接続の開始時、及び配信モード変更時に映像受信装置２００より発行される。

この判別の結果、当該要求でない場合はステップＳ３０９でその他のイベント処理を行い、ステップＳ３０１に戻って次のイベントを待つ。なお、その他のイベントとしては、例えば切断イベントがあるが、詳細な説明を省略する。一方、ステップＳ３０２の判別の結果、配信モード付き接続要求である場合は、ステップＳ３０３で接続可能かどうか判別する。

ここで、配信モードの変更可否は、接続中の映像受信装置の有無、及び他の映像受信装置の接続モードによって決定される。例えば、映像送信装置のリソース上の制約により、映像受信装置ごとに異なるモードでの配信が不可能な場合がある。このような場合、他の映像受信装置がモード１で接続中の場合は、モード２への移行はできない場合がある。これはある映像受信装置においてモード１が録画向けに使用されている場合は、そちらが優先されるからである。

ステップＳ３０３の判別の結果、接続が不可能である場合は、ステップＳ３０８で接続拒否通知を映像受信装置２００に対して返信し、ステップＳ３０１に戻って次のイベントを待つ。一方、ステップＳ３０３の判別の結果、接続が可能である場合は、ステップＳ３０４に進んで接続許可通知を映像受信装置２００に対して返信する。次に、ステップＳ３０５で映像の撮影間隔を設定し、さらにステップＳ３０６で映像配信プロトコルを設定後、ステップＳ３０７で映像配信を開始する。そして、終了後、ステップＳ３０１に戻って次のイベントを待つ。

一方、図４において、映像受信装置２００は処理開始後、ステップＳ４０１でイベントの発生を待つ。イベントには接続要求イベントをはじめとして切断イベントなどがある。これらのイベントは例えば映像受信装置２００の操作者がマウスやボタンなどの入力機器を用いてアプリケーションのＧＵＩ（Graphical User Interface）を操作することにより発生する。そして、イベントの発生を検知すると、ステップＳ４０２で発生したイベントが配信モード付き接続要求かどうか判別する。この判別の結果、配信モード付き接続要求でない場合は、ステップＳ４０８で他のイベント処理を行う。他のイベント処理としては切断イベントがあるが、説明を省略する。そして、処理終了後ステップＳ４０１に戻って処理を続ける。

一方、ステップＳ４０２の判別の結果、配信モード付き接続要求である場合は、ステップＳ４０３で映像送信装置１００に対し、配信モード情報を添付して接続要求を行う。映像送信装置１００は既に説明したようにステップＳ３０１でこの要求を受ける。次に、ステップＳ４０４において、映像受信装置２００は映像送信装置１００からの返信を待ち、接続許可が行われたかどうか判別する。この判別の結果、接続が拒否された場合は、ステップＳ４０１に戻って次のイベントを待つ。

一方、ステップＳ４０４の判別の結果、接続が許可された場合は、ステップＳ４０５で映像受信プロトコルを設定し、ステップＳ４０６で動体検知方式を設定した後に、ステップＳ４０７で映像受信を開始する。そして、処理を終了後ステップＳ４０１に戻って次のイベントを待つ。

以上の説明からも明らかなように、本実施形態によれば、映像配信プロトコルによって動体検知方式を変えることにより、プロトコルによらず、有効な動体検知結果を提供できる。

（第２の実施形態）
本発明に関わる別の実施形態として、第１の実施形態におけるモード２において、フレーム欠落のない新たな配信モードを設ける。このモードをモード３とする。モード３ではモード２と同様に映像伝送プロトコルとしてＲＴＰを用いるものの、フレーム落ちが発生した場合には、アプリケーションから再送を要求する。このため低遅延かつフレーム落ちのない映像配信が実現される。本実施形態ではこの第３の配信モードにおいて速報性と信頼性を両立するイベント通知機能の例を説明する。なお、本実施形態の映像送信装置及び映像受信装置は、図１と同様であるため、説明は省略する。

図５を用いて本実施形態における映像配信と動体検知方法を説明する。図５は映像送信装置１００と映像受信装置２００との間のコラボレーションを示す図である。このほかに映像受信装置２００で実行される動体検知スレッド２０１がある。映像送信装置１００から映像受信装置２００に対して、フレームが送信される。
図５で映像フレームは撮影順にシーケンス番号が振られている。撮影されたフレーム１（６０１）はバッファに保存される。次にＲＴＰにより送信され映像受信装置２００でフレーム１（６０３）として受信される。映像受信装置２００側でも同フレームをバッファに保存する。

ここで、次のフレーム２は映像受信装置２００に届かずに消失すると仮定する。さらにフレーム３が送信されると、映像受信装置２００ではフレーム３を受信した時点でフレーム２の消失が分かるので、再送要求を行う。このようなＲＴＰにおける再送要求のしくみはＲＴＣＰ（Real Time Control Protocol）を用いた公知の手法により実装が可能である。

また、動体検知方法として隣接フレーム間差分を用いる場合を考える。フレーム２が欠落した場合、フレーム２とフレーム１との間で差分を行うことができないので、代わりにフレーム３とフレーム１との間で差分を行う。そして差分の結果をイベントとして通知する。このイベントを「仮イベント」と称す。イベント通知のしくみは第１の実施形態と同じなので説明を省略する。次に再送によりフレーム２を受信すると、バッファに保存していたフレーム１との間で改めてフレーム間差分を行う。その結果を再度イベントとして通知する。このイベントを「正イベント」と称す。仮イベントと正イベントの違いは、イベントの通知にＨＴＴＰを用いる場合、ＨＴＴＰメッセージのBODYにイベントの種類を記載することで判別が可能である。

なお、以上の説明では、説明の単純化のためにフレーム単位で欠落生じるとしたが、実際にはパケット単位で欠落が生じる。またパケットの到着順が前後する場合もある。そのためフレームが完全に再現する以前に当該フレームの欠落が分かる場合もある。そのような場合は次のフレームの受信を待たずに再送要求を出すことができる。

次に、図６及び図７を用いて、本実施形態における映像送信装置１００と映像受信装置２００の処理手順を説明する。図６は、映像送信装置１００の映像配信スレッドの処理手順の一例を示すフローチャートである。本実施形態における接続処理手順は図３を用いて説明した第１の実施形態と同一であるので説明を省略する。以下、本実施形態に特有の再送要求時のイベント通知処理に限定して説明する。

開始後、ステップＳ６０１で通常の送信要求か再送要求イベントかを判別する。この判別の結果通常の送信要求である場合は、ステップＳ６０２で撮影部より画像を取得する。次に、ステップＳ６０３で画像をバッファに保存する。これはフレームの欠落が生じることを想定してあらかじめ一定フレームをバッファに保存するものである。次に、ステップＳ６０４で画像を送信する。送信後、ステップＳ６０１に戻って処理を続ける。

一方、ステップＳ６０１の判別の結果、映像受信装置２００より再送要求がある場合は、ステップＳ６０５で当該フレームのバッファがあるかどうかを確認する。この判別の結果、存在した場合は、当該フレームないしはフレームの一部分を再送する。再送後、ステップＳ６０１に戻って処理を続ける。一方、ステップＳ６０５の判別の結果、当該フレームがバッファに残っていなかった場合は、ステップＳ６０７で再送不可通知を映像受信装置２００に対して行う。

次に、図７を用いて本実施形態における映像受信装置２００の処理手順を述べる。図７は、映像受信装置２００の画像取得・動体検出スレッドの処理手順の一例を示すフローチャートである。映像送信装置１００と同様に接続処理手順は第１の実施形態と同じなので説明を省略する。

開始後、ステップＳ７０１で画像データの取得を行う。そして、ステップＳ７０２で最新フレームかどうかを確認する。この確認の結果、最新フレームである場合には、ステップＳ７０３でフレーム落ちがないかどうかを確認する。この確認の結果、フレーム落ちがある場合は、ステップＳ７０９で再送を要求する。その後、ステップＳ７０１に戻って処理を続ける。

一方、ステップＳ７０３の確認の結果、フレーム落ちがない場合は、ステップＳ７０５に進み、動体検知処理を行う。この動体検知処理は最新フレームと利用可能な直前フレームとを用いたフレーム間差分処理である。次に、ステップＳ７０６で保存バッファの消去を行う。バッファはバッファに保存したフレームと次のフレームとの間でフレーム間差分を行った後に消去する。例えばフレーム１０がバッファされているときに、フレーム１１とフレーム１０との間で隣接フレーム間差分が行われたら、フレーム１０のバッファは消去する。フレーム１１が到着せずにフレーム１２とフレーム１０との間でフレーム間差分が行われた場合にはフレーム１１が到着するまでフレーム１０をバッファに保存する。

次に、ステップＳ７０７で動体検知処理の結果、検知状態に変化があったかどうかを判別する。この判別の結果、変化があった場合は、ステップＳ７０８で動体検知イベントを発行する。一方、ステップＳ７０７の判別の結果、変化がなかった場合は、ステップＳ７０１に戻り、処理を続ける。

ここで、検知イベントは、前述したように仮イベントと正イベントとがある。フレーム落ちがなく、隣接フレーム間差分が行われた場合には「正イベント」として発行し、フレーム落ちがあったため、隣接フレーム間差分が行われなかった場合には「仮イベント」として発行する。

一方、ステップＳ７０２の判別の結果、到着したフレームが最新フレームでなかった場合は、ステップＳ７１０で到着フレームの直前のフレームをバッファから読み出す。次に、ステップＳ７１１で動体検知処理を行う。ここでの動体検知処理はステップＳ７０５と同じ処理であり、２枚の画像を用いたフレーム間差分である。次にステップＳ７１２で読み出したバッファ画像を消去する。次に、ステップＳ７１３で正イベントを発行する。そしてステップＳ７０１に戻って処理を続ける。

本実施形態においては録画を行うことも可能である。録画時には発生したイベントも同時に記録することが一般に行われる。そこで録画を行う場合のイベント記録処理は正イベントのみを記録する。仮イベントは後で正イベントが必ず通知されるため記録は不要である。正イベントはステップＳ７０８において隣接フレームである場合、及びステップＳ７１３において再送フレームを用いて隣接フレーム間差分を行った場合に発行される。

以上説明したように、本実施形態によれば、フレーム落ちがあった場合は前後のフレームを用いた動体検知により仮イベントを発行する。そして、当該フレームの再送がなされた時点で再度動き検知処理を行い、正イベントを発行する。これにより、再送機能付きの低遅延配信プロトコルにおいて、イベントの速報性と信頼性を両立できる。

（第３の実施形態）
本実施形態においては、必ず正イベントを発行する必要はなく、仮イベントの内容を訂正する必要がある場合にのみ訂正を行うイベントを発行することも可能である。以下、これを「訂正イベント」と称する。したがって、本実施形態では仮イベントも正イベントとして発行する。図８を用いて本実施形態における映像受信装置の動作手順を説明する。なお、図８において図７と同一の処理については同一の番号を付している。したがって、図７との相違点のみを説明する。なお、本実施形態の映像送信装置及び映像受信装置は、図１と同様であるため、説明は省略する。

訂正イベントを発行するタイミングは再送によって遅延フレームが到着した場合である。これはステップＳ７０２でＮＯに分岐した場合に相当する。以下、ステップＳ７１２の動体検知処理後、ステップＳ８１３で訂正イベントが必要かどうかを判別する。ここでは、必要かどうかは以前に行われた動体検知の結果と今回行われた動体検知の結果とが同じかどうかで判別する。この判別の結果、結果が異なる場合には訂正イベントが必要であることから、ステップＳ８１４で訂正イベントを発行する。一方、ステップＳ８１３の判別の結果、訂正イベントが必要ない場合は、ステップＳ７０１に戻る。

ここで、訂正イベントには複数の種類がある。１つは新規の動体検知イベントであり、ひとつは動体検知の取り消しイベントである。このほかにも動体検知結果の内容を訂正するイベントを設けてもよい。これは動体領域の検知結果が異なる場合などに、物体領域情報を更新するものである。

また、本実施形態においては第２の実施形態と同様に、録画を行うことも可能である。本実施形態におけるイベントは訂正される可能性がある。そこで基本的に全てのイベントを記録するが、訂正イベントが発行された場合には、対応する旧イベントの記録から抹消する。本実施形態においてイベントはステップＳ７０８とステップＳ８１４とで発行される。このうち訂正イベントが発行されるステップＳ８１４で発行と同時に対応する旧イベントの記録を抹消する。

以上説明したように、本実施形態によればフレーム落ちがあった場合は前後のフレームを用いた動体検知により仮イベントを発行する。そして、当該フレームの再送がなされた時点で再度動き検知処理を行い、仮イベントと結果が異なるのであれば訂正イベントを発行する。これにより、再送機能付きの低遅延配信プロトコルにおいて、イベントの速報性と信頼性を両立できる。

（本発明に係る他の実施形態）
前述した本発明の実施形態における映像受信装置を構成する各手段、並びに映像受信方法の各工程は、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録（記憶）したコンピュータ読み取り可能な記録媒体（記憶媒体）は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体（記憶媒体）等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図３、図４、図６〜図８に示すフローチャートに対応したプログラム）を、システムまたは装置に直接、または遠隔から供給する場合も含む。そして、そのシステムまたは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体（記憶媒体）としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスクなどがある。さらに、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する方法がある。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体（記憶媒体）にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、その他の方法として、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体（記憶媒体）に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。さらに、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、その他の方法として、まず記録媒体（記憶媒体）から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

２１１ 映像受信部、２４１ 動体検知部、２４２ 動体検知制御部

Claims (4)

1. 通信手段と画像処理手段とを有する映像受信装置であって、
   通信プロトコルが異なる複数の映像配信手段に対応する複数の映像受信手段と、
   前記複数の映像受信手段のそれぞれに対応する複数の画像処理手段とを有することを特徴とする映像受信装置。
2. 前記複数の映像受信手段は、映像フレームの再送を保証するプロトコルを用いた映像配信に対応するものと、映像フレームの再送が保証されない他の映像配信に対応するものとを含むことを特徴とする請求項１に記載の映像受信装置。
3. 通信手段と画像処理手段とを有する映像受信装置の映像受信方法であって、
   通信プロトコルが異なる複数の映像配信手段に対応する複数の映像受信工程と、
   前記複数の映像受信工程のそれぞれに対応する複数の画像処理工程とを有することを特徴とする映像受信方法。
4. 請求項３に記載の映像受信方法の各工程をコンピュータに実行させるためのプログラム。

Images