JP4767729B2 - 監視システムおよび映像蓄積配信装置 - Google Patents

Description

この発明は、複数の監視映像を遠隔で監視する監視システムおよびイベント発生前の映像を集信装置から入手して監視端末に配信する映像蓄積配信装置に関するものである。

監視システムの一般的な構成形態として、複数の監視先に多数の監視カメラを設置し、各カメラで撮影した映像をネットワークで接続された遠隔の監視センタに送信して、センタに設置された複数の監視端末により集中的に監視するようにしたものがある。このような監視システムでは、監視先において事故や災害、犯罪の発生タイミングを予知できるようにはなっておらず、発生時のライブ映像や発生前後の蓄積映像を確認可能とするためには、監視先に設定された全てのカメラの映像を遠隔の監視センタで常時受信できるようにしておく必要がある。そのためには、ネットワークの帯域を監視カメラの全映像を受信可能にする大容量ネットワークが必要であり、また、全映像を蓄積する蓄積装置が要求されるが、これに対応することは現実的には難しい。

上記課題に対応する方法として、次のような技術が提案されている（例えば、特許文献１、特許文献２参照）。特許文献１の技術では、カメラが接続された映像入力配信装置内に映像をエンドレス蓄積するようにリングバッファが設けられている。この映像入力配信装置は、伝送路を介して映像監視サーバに接続されており、この映像監視サーバのリクエストに対応して、リングバッファにエンドレス蓄積した任意の部分をマルチキャスト送信する。映像監視サーバでは、受信した映像を蓄積し、同時に、映像監視サーバに接続された映像監視端末でそのマルチキャスト映像を閲覧できるようにしている。映像監視サーバは蓄積した映像を配信する機能も有している。この技術によれば、例えば監視センタでは、イベントが発生した際に関連するカメラが接続されている映像入力配信装置に対してイベント発生前後の映像をダウンロードする命令を送信することにより、イベントの発生状況を撮影した重要映像のみを監視センタに蓄積することが可能になる。したがって、全てのカメラの映像を遠隔の監視センタで受信する必要がなく、イベントに関連した重要な映像のみを監視センタに蓄積することが可能になる。

一方、特許文献２の技術によれば、映像配信装置に蓄積されている映像データを管理単位のブロックに分割して映像受信再生装置側に配信して閲覧できるようにするシステムを備えている。この映像受信再生装置では、既に過去に受信した映像データに関しては内部に蓄積しておき、映像を再生する際に、再生する映像の管理ブロックが内部に蓄積されている場合にはその映像を再生し、一方、該当する管理ブロックが内部に蓄積されていない場合には映像配信装置から映像を受信して再生を行うようにしている。

特開２００３−１５３１６５号公報 特開２００２−２６２２６７号公報

上記特許文献１の技術を用いた監視システムの場合、イベントが発生した時にはカメラ側に蓄積した映像ファイルをイベント前後で切り出して遠隔の監視センタに送信することが考えられる。例えばイベント前後ｎ分間の映像を切り出す場合、映像はｎ分前の映像から受信する必要があり、映像はデータ容量が大きいため、一番重要なイベント発生時の映像の到着が遅れリアルタイムで無くなるという問題がある。また、イベント発生時に、イベント発生直後を指定して映像受信した場合には、監視映像は映像監視端末でほぼリアルタイムに表示可能となるが、ライブ映像の表示後にイベント発生前の映像を表示する際に、監視員がイベント発生前の時間を指定して明示的にリクエストを行うことでイベント発生前の映像を受信する必要があり、操作が煩雑になるという問題がある。一方、上記特許文献２の技術においては、映像コンテンツの配信を主なアプリケーションとして考えているため、映像監視におけるイベントデータに基づいて映像の再生を制御することができないという問題がある。

この発明は、上記問題点を解決するためになされたもので、簡単なイベントデータ指定によるイベント発生前後の蓄積された監視映像のシームレスな表示を可能にする監視システムおよび映像蓄積配信装置を得ることを目的とする。

この発明に係る監視システムは、監視先でイベントの発生がない通常時において、監視先に設置した監視カメラで撮影した映像をイベント前映像として一次蓄積映像データベースに蓄積しておき、監視先でイベントが発生した場合において、当該イベントに対応する監視カメラのライブ映像を、イベント後映像としてイベント後再生時間を指定して蓄積映像データベースに蓄積し、ライブ映像の蓄積後で、発生履歴のあるイベントを指定して受信許可を与えた監視端末から蓄積映像送信要求が出された場合において、イベント前再生時間を指定することにより、一次蓄積映像データベースから指定イベントに対応するイベント前映像のイベント前再生時間分を取得し、取得した当該イベント前映像と蓄積映像データベースに蓄積されている指定イベントに対応するイベント後映像とを、最後に受信したイベント前映像のパケットの次に来るパケットをイベント後映像の配信開始パケットに切り替え、連続するストリームにして蓄積映像送信要求を出した監視端末に配信するものである。

この発明によれば、複数のカメラで撮影した映像をネットワークで接続された遠隔の監視センタの監視端末で集中監視する監視システムに適用して、大容量ネットワークを必要とせず、また全映像を蓄積する蓄積装置を必要とすることなく、監視先の事故、災害、犯罪等のイベントが発生した場合に、そのイベント発生前後の蓄積映像を確認できるようにしている。特に、蓄積された監視映像を閲覧する際には、ユーザが監視端末でイベントデータを指定するだけで、再生する時間、時刻を意識することなく、イベント発生前後のシームレスな映像の閲覧を可能にする。

実施の形態１．
この実施の形態１では、監視先でイベントが発生していない通常状態にある時に監視映像をイベント発生前の映像（以下、イベント前映像とする）として蓄積していき、イベントが発生した場合にはその後のライブ映像を監視端末で閲覧できるようにすると同時に、そのライブ映像をイベント発生後の映像（以下、イベント後映像とする）として蓄積しておき、その後、任意の監視端末からの要求に応じて蓄積されたイベント前後の映像を閲覧できるようにすることについて説明する。
ここでは、以下映像を主体とした蓄積、配信について説明するが、音声等の他のメディアについても同様であるものとする。映像はＭＰＥＧ−４ Ｓｉｍｐｌｅ Ｐｒｏｆｉｌｅを例にして説明する。また、映像の配信については、例えばＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ３５５０で規定されているＲＴＰ（Real-Time Transport Protocol）を用い、ＭＰＥＧ−４ペイロード形式はＩＥＴＦのＲＦＣ３０１６を用いる。ビデオ配信制御については、主にＩＥＴＦのＲＦＣ２３２６で規定されているＲＴＳＰ（Real Time Streaming Protocol）を用いた方式について説明を行う。

図１はこの発明の実施の形態１による監視システムの機能構成を示すブロック図である。
この監視システムでは、複数の監視先にそれぞれ監視カメラＣ１〜Ｃｎ（ｎ≧１）とイベント発生装置Ｅ１〜Ｅｎ（ｎ≧１）が設置されている。監視カメラＣ１〜Ｃｎとイベント発生装置Ｅ１〜Ｅｎは、カメラネットワーク８を介して集信装置３に接続されている。また、集信装置３は、一次蓄積映像ＤＢ（一次蓄積映像データベース）４に接続されており、ネットワーク５を介して監視センタ６に接続されている。監視センタ（監視センタ装置）６は、映像蓄積配信装置１、蓄積映像ＤＢ（蓄積映像データベース）２および複数の監視端末Ｔ１〜Ｔｍ（ｍ≧１）を備えている。なお、ネットワーク５，８には、例えばＩＰネットワークが使用されるが、カメラネットワーク８は必ずしもＩＰネットワークである必要はなく、接続により映像データが送信できればどのようなものを使用してもよい。なお、図１の例は、監視カメラ、イベント発生装置、一次蓄積映像ＤＢおよび集信装置から成る一つの監視先グループ（監視先グループ装置）について示しているが、同様な組み合わせの他の監視先グループが存在する場合には、同様にネットワーク５を介して監視センタ６に接続されるものとする。
なお、この例の監視システムに接続されている機器は、時刻サーバあるいはＧＰＳ等により時刻同期されているものとする。

監視カメラＣ１〜Ｃｎは、それぞれが設置された監視先を撮影し、得られた映像信号をデジタル化した後、符号化を施し、ＲＴＰパケットの映像データにして予め登録されている集信装置３のアドレスに対して送信する手段である。イベント発生装置Ｅ１〜Ｅｎは、監視カメラＣ１〜Ｃｎの各監視先における予め設定された条件に基づいてイベントが発生した際に所定のイベントデータを生成し映像蓄積配信装置１に送信する手段である。一次蓄積映像ＤＢ４は、監視カメラＣ１〜Ｃｎのそれぞれに対応した映像のファイル化されたＲＴＰパケットデータを個別にリングバッファに格納し管理する手段である。集信装置３は、監視カメラＣ１〜Ｃｎで撮影したイベント前映像をそれぞれ順次に一次蓄積映像ＤＢ４に蓄積し、イベント発生後に映像蓄積配信装置１からの映像送信要求に従って、イベントに対応する監視カメラからのライブ映像または一次蓄積した映像を映像蓄積配信装置１に対して配信する手段である。蓄積映像ＤＢ２は、イベント発生後に映像蓄積配信装置１が受信したライブ映像をイベント後映像として蓄積する手段である。映像蓄積配信装置１は、イベントが発生した際に、該当するイベント発生装置から受信したイベントデータに基づいて対応する監視カメラで撮影されるライブ映像の受信許可を監視端末Ｔ１〜Ｔｍのいずれかに対して与えると共に、当該ライブ映像を蓄積映像ＤＢ２に蓄積し、また、イベント発生後において監視端末Ｔ１〜Ｔｍのいずれかから映像送信要求があった場合に、集信装置３に要求して一次蓄積映像ＤＢ４に一次蓄積されたイベント前映像を取得し、このイベント前映像と蓄積映像ＤＢ２から読み出した対応するイベント後映像をつなげて、要求があった監視端末に配信する手段である。監視端末Ｔ１〜Ｔｍは、イベント発生時に映像蓄積配信装置１から受信許可を受けた場合に、集信装置３から配信された監視カメラのライブ映像を受信再生し、また、蓄積映像送信要求を映像蓄積配信装置１に送信した場合に、イベント発生前に一次蓄積されたイベント前映像とイベント発生後に蓄積されたイベント後映像の連続した映像を再生する手段である。

次に、図１の監視システムの全体動作について説明する。
先ず、各監視カメラからの映像の一次蓄積、イベント発生後のライブ映像の閲覧、およびそのイベント発生後の映像の蓄積について説明する。これらの一連動作は図２に表される。
監視カメラＣ１〜Ｃｎでは、それぞれの監視対象となる領域を撮影し、その映像信号をデジタル化してＭＰＥＧ−４に符号化した後、ＲＴＰパケット化された映像データに生成し、カメラネットワーク８を介して予め登録された集信装置３に対して送信する。集信装置３では、イベントが発生していない通常時において、受信した監視カメラＣ１〜Ｃｎからの映像データを、それぞれファイル化してＲＴＰパケットに生成して順次に一次蓄積映像ＤＢ４の個別のリングバッファに蓄積していく。

イベント発生装置Ｅ１〜Ｅｎの一つでイベントが発生したとすると、そのイベント発生装置は後述する図４に示すデータ構成のイベントデータを生成して映像蓄積配信装置１へ送信する。映像蓄積配信装置１では、受信したイベントデータに基づいて当該イベントデータを送信したイベント発生装置に対応する監視カメラと集信装置を指定してイベント発生後のライブ映像の送信要求（以下、ライブ映像送信要求とする）を、該当する集信装置（この例では集信装置３）へ送信する。ここで、ライブ映像送信要求は、実際には図３に例示されているものと同様な複数のリクエストで構成され、かつそれらへの応答処理も伴うが、ここではこれらの一連の手続きを一つにまとめて単に「ライブ映像送信要求」として説明する。また、映像蓄積配信装置１は、この時受信したイベントデータに基づいて形成されたイベント発生通知を監視端末Ｔ１〜Ｔｍに対して送信する。監視端末Ｔ１〜Ｔｍでは、イベント発生通知を受信すると、受信したイベントデータ発生通知のデータを蓄積する共に、イベントに対応する映像データの受信可否を映像蓄積配信装置１へ応答する。映像蓄積配信装置１は、映像データを受信可能とする監視端末から受信可能応答を受信した場合には、その最初に応答した監視端末Ｔｙ（１≦ｙ≦ｍ）に対して映像受信許可を与える。

集信装置３では、ライブ映像送信要求を受信すると、イベント発生のあったイベント発生装置に対応する監視カメラからのライブ映像の一次蓄積映像ＤＢ４への蓄積を休止し、代わってイベント発生後のライブ映像を、ネットワーク５を介して映像蓄積配信装置１と映像受信許可を受けた監視端末Ｔｙにマルチキャスト送信する。この場合、再送中の該当映像の一次蓄積は、映像蓄積配信装置１へ配信を開始した数秒後に停止される。ここで、イベント発生に関連する監視カメラからの映像で、一次蓄積映像ＤＢ４へ蓄積されている映像データは当該イベント発生前の映像（すなわち、イベント前映像）であり、再送中の映像データは当該イベント発生後のライブ映像（すなわち、イベント後映像）ということになる。
映像受信許可が与えられた監視端末Ｔｙでは、イベント発生後に送られてくるライブ映像を受信復号して表示手段で再生する。この受信したライブ映像の再生は、受信開始から予め設定された一定時間経過するまでの間、あるいは受信開始から映像停止ボタンがユーザインタフェースで押下される時点まで行われる。このことにより、イベント発生後の監視対象の領域の現状を把握することができる。
一方、映像蓄積配信装置１では、集信装置３から再送されたイベント発生後のライブ映像を受信すると、予め設定されたイベント後再生時間分だけ蓄積映像ＤＢ２に蓄積する。これにより、蓄積映像ＤＢ２には、一次蓄積映像ＤＢ４へ蓄積されているイベント前映像に対応するイベント後映像が蓄積されたことになる。
一定量のイベント発生後の映像が蓄積映像ＤＢ２に蓄積され、かつ監視端末Ｔｙがライブ映像の再生を終了した場合、集信装置３に対して映像蓄積配信装置１から送信終了通知が与えられる。送信終了通知を受信すると、集信装置３では、上記イベントに関連した監視カメラからの映像の一次蓄積のための受信を再開する。しかし、この時、一次蓄積映像ＤＢ４において、イベント発生前の一定時間の映像が蓄積されているブロックに対してファイルのロックを行って、上書き不可としておく。

次に、蓄積されたイベント前映像とイベント後映像の配信・再生についての動作を説明する。これらの一連の動作は図３に表される。なお、図３において複数のリクエストとそれらへの応答が記載されているが、個々については後述する映像蓄積配信装置、映像蓄積配信装置および監視端末の詳細動作で説明しているので、ここでは、これらの手続きを一つにまとめて「蓄積映像送信要求」として説明するものとする。
ライブ再生終了後、監視端末Ｔ１〜Ｔｍの一台（Ｔｙとする）において、ユーザが発生イベントの一つの閲覧を選択したとする。この場合の選択は、これまでの発生イベントのライブ映像閲覧に関してイベントデータ発生通知を保存しているので、そのイベントＩＤを指定して用いて行うことになる。監視端末Ｔｙは、この選択されたイベントＩＤに関する蓄積映像送信要求を映像蓄積配信装置１に対して送信する。
映像蓄積配信装置１では、受信した蓄積映像送信要求を、イベントＩＤに対応する監視カメラの映像を管理する集信装置３に対して送信する。このときの蓄積映像送信要求には、要求するイベント前映像に対して、イベント発生時刻から予め設定されたイベント前再生時間分前の時刻が読み出し開始時刻（または送信開始時刻）として指定される。
集信装置３では、映像蓄積配信装置１から蓄積映像送信要求を受信すると、一次蓄積映像ＤＢ４に蓄積されている該当イベントに対応した監視カメラからのイベント前映像のデータを指定され時刻から読み出して、映像蓄積配信装置１へ送信する。この場合の送信は、指定され時刻からイベント発生時刻までの長さ分のストリーミングで行い、蓄積されているＲＴＰタイムスタンプのタイミングで送信される。

映像蓄積配信装置１では、集信装置３からイベント前映像を受信すると、蓄積映像送信要求の送信を行った監視端末Ｔｙに対して配信する。映像蓄積配信装置１は、監視端末Ｔｙに送信しているイベント前映像のデータがイベント発生時刻に達すると、次に蓄積映像ＤＢ２中の当該イベントに対応するイベント後映像を読み出して配信を開始する。この場合、配信されるイベント後映像のデータは、前述したように、蓄積時に指定したイベント発生時刻からイベント後再生時間分の長さとなる。また、このときのイベント前後の映像の切り替えは、最後に受信したイベント前映像のＲＴＰパケットの次のＲＴＰパケットよりイベント後映像の送信を開始することで、イベント発生前後の映像データはシームレスに連続したものとなる。蓄積映像送信要求を送信した監視端末Ｔｙでは、映像蓄積配信装置１からのイベント発生前後の連続した映像データを受信すると、それを復号して映像表示を行う。
以上のように、映像蓄積配信装置１が、集信装置３側と映像蓄積配信装置１側にそれぞれ蓄積されている発生イベントに関するイベント前映像とイベント後映像の切り替えをシームレスにとなるようにして配信しているため、蓄積映像の閲覧機能に限れば、監視装置ＴｙはＲＴＳＰに対応したＭＰＥＧ−４を復号可能な一般的な再生装置であれば特に特別な機能は無くてもよく、映像蓄積配信装置１にアクセスするだけでシームレスに蓄積映像を閲覧することが可能である。

次に、図１に示されるイベント発生装置Ｅ１〜Ｅｎ、集信装置３、一次蓄積映像ＤＢ４、蓄積映像ＤＢ２および監視端末Ｔ１〜Ｔｍの構成および動作の詳細について説明する。
（１）イベント発生装置Ｅ１〜Ｅｎ
イベント発生装置Ｅ１〜Ｅｎは、周囲の条件等に応じてイベントを発生する装置であり、例えば温度センサを搭載しており、温度が設定されている閾値以上になった場合にイベントを発生するものである。また、イベント発生装置の他の例として、人感センサを搭載し、感知領域に入った人間を感知するとイベントを発生させるものもあり、映像変化を分析して異常を検出する監視カメラと一体化したものもある。イベント発生装置Ｅ１〜Ｅｎでは、イベントが発生すると予め設定されている映像蓄積配信装置１のアドレスとポート番号に対して、ネットワーク８，５を介して、図４に示すような構成のイベントデータを送信する。このイベントデータの構成は、イベント発生装置ＩＤ３００、イベント種別ＩＤ３０１、イベント発生時刻３０２、付属データ３０３等を含んでいる。イベント発生装置ＩＤ３００にはイベントを発生させた装置のＩＤが格納される。イベント種別ＩＤ３０１には、発生したイベントの種類を示すＩＤが格納される。イベント発生時刻３０２には、イベントの発生した日時が格納される。付属データ３０３には、イベント種別ＩＤ３０１ごとに格納されるデータ内容が規定されており、例えば高温イベントであれば、イベント発生させた際の温度の情報が格納される。

（２）集信装置３
集信装置３は、図５に示すように、ＤＢ入力部（データベース入力部）１０１、リクエスト送受信部１０２、再送信部１０３、蓄積ストリーム送信部１０４、カメラ属性ＤＢ（カメラ属性データベース）１６０、受信部Ｒ１〜Ｒｎ（ｎ≧１）およびファイルデータ化部Ｆ１〜Ｆｎ（ｎ≧１）を備えている。
（２−１）イベントが発生していない通常時における監視カメラＣ１〜Ｃｎ毎の映像データを一次蓄積する際の詳細動作
受信部Ｒ１〜Ｒｎは、常時、監視カメラＣ１〜Ｃｎ毎の映像データを受信する。これら受信部Ｒ１〜Ｒｎには、それぞれが受信対象とする監視カメラのカメラＩＤが割り当てられており、予め登録されているポート番号で映像のＲＴＰパケットを待ち受けている。受信部Ｒ１〜Ｒｎは、先頭パケットが到着すると、その受信時刻（日付及び時刻）を蓄積開始時刻とし、蓄積開始時刻をファイルデータ化部Ｆ１〜Ｆｎに出力すると共に、受信したＲＴＰパケットを次々にファイルデータ化部Ｆ１〜Ｆｎに出力する。また、受信部Ｒ１〜Ｒｎは、ＲＴＰパケットの順序の入れ替わり等の補正を内部に有するバッファを用いて行っている。

ファイルデータ化部Ｆ１〜Ｆｎは、入力された各映像のＲＴＰパケットをファイルに蓄積する形式のデータに変換する。この場合、ファイルデータ化部Ｆ１〜Ｆｎは、受信部Ｒ１〜Ｒｎから蓄積開始時刻を受け取った場合、時間情報をリセットし、受け取ったＲＴＰパケットの先頭にパケット長を付与し、パケットを時間順に結合する。このような映像データを後述する一次蓄積ＤＢのリングバッファのブロックに納まる一定サイズ分まとめると、その先頭パケットを受信した時刻、最終パケットを受信した時刻、およびカメラＩＤをＤＢ入力部１０１に対して出力する。ＤＢ入力部１０１では、ファイルデータ化部Ｆ１〜Ｆｎにおいてファイル化された各データを一次蓄積映像ＤＢ４に蓄積する。ここで、先頭パケットを受信した時刻は、受信開始時刻を受信部Ｒ１〜Ｒｎから受け取った場合には、その時刻とし、受け取らなかった場合には、以前受信した時刻にＲＴＰパケットのタイムスタンプから換算した時間を足した時刻により作成する。最終パケット時刻も同様にして、先頭パケット受信時刻を基に最後に受信したＲＴＰパケットのタイムスタンプにより計算を行う。

（２−２）イベント発生後のライブ映像を再送信（転送）する際の詳細動作
イベントが発生した際、映像蓄積配信装置１からライブ映像送信要求がある。ここで、ライブ映像送信要求は、ＤＥＳＣＲＩＢＥリクエスト、ＳＥＴＵＰリクエスト、ＰＬＡＹリクエストとこれらのリクエストに対するそれぞれの応答からなる。
リクエスト送受信部１０２では、イベント発生直後に映像蓄積配信装置１からＤＥＳＣＲＩＢＥリクエストを受信した場合、カメラ属性ＤＢ１６０を検索し、リクエストされた監視カメラの属性情報を抽出する。カメラ属性ＤＢ１６０には、各監視カメラの属性情報がＳＤＰ（Session Description Protocol）のメディア記述の形式で格納されている。リクエスト送受信部１０２では、抽出したＳＤＰのメディア記述をＳＤＰのメディア部分に格納することで監視カメラに対応した映像の属性情報を生成する。ＭＰＥＧ−４の場合、主に格納される情報としてはプロファイルレベルＩＤとＤＣＩ（Decoder Configuration Information:ＭＰＥＧ−４規格ＩＳＯ／ＩＥＣ１４４９６−２ＡｎｎｅｘＫに定義）となる。リクエスト送受信部１０２は、抽出した監視カメラの属性情報をＳＤＰにより格納するＤＥＳＣＲＩＢＥ応答を映像蓄積配信装置１に送信する。
また、リクエスト送受信部１０２は、ＤＥＳＣＲＩＢＥ応答を送信することで映像蓄積配信装置１から送信されるＳＥＴＵＰリクエストを受信すると、予めカメラ毎に決められた送信先のマルチキャストアドレスと、ポート番号を検索し、その情報をＳＥＴＵＰ応答に格納して映像蓄積配信装置１に対して送信する。さらに、リクエスト送受信部１０２では、ＳＥＴＵＰ応答を送信することで映像蓄積配信装置１から送信されるＰＬＡＹリクエストを受信すると、再送信部１０３のスレッドを生成し、ＰＬＡＹリクエストの内容である、送信対象とするカメラ番号および送信先のマルチキャストアドレスとポート番号を再送信部１０３に通知する。なお、再送信部１０３は、リクエストが同時に複数発生した場合には複数起動し、複数の送信先（監視端末）への再送信を行うものとする。

再送信部１０３では、ＰＬＡＹリクエストで要求されたカメラ番号に対応する受信部Ｒｘ（ＲｘはＲ１〜Ｒｎのうちで該当イベントに対応する受信部とする）で受信しているライブ映像のＲＴＰパケットを映像蓄積配信装置１に対して送信する。再送信部１０３では、要求されたカメラからのＲＴＰパケットを、フレームの切り替わりのタイミングで、ＰＬＡＹリクエストで指定されたマルチキャストアドレスとポート番号に対して送信する。この場合の再送を行うライブ映像は、監視センタ６側で蓄積されるので、一次蓄積映像ＤＢ４への蓄積は不要となる。そのため、該当映像の一次蓄積は映像蓄積配信装置１への再送を開始した数秒後に対応する受信部により停止される。

リクエスト送受信部１０２は、映像の再送を行っている時に、映像蓄積配信装置１からＴＥＡＲＤＯＷＮリクエストを受信すると、再送信部１０３に対して終了の命令を送信する。再送信部１０３は、送信するＲＴＰパケットをコピーする受信部Ｒｘに対して送信終了通知を与えて、自身のスレッドを終了する。一方、送信終了通知を受信した受信部Ｒｘは、一次蓄積のための受信を再開する。この時、一次蓄積映像ＤＢ４において、イベント発生前の一定時間の映像が蓄積されているブロックに対してファイルのロックを行い、上書き不可とする。再送終了処理が完了すると、リクエスト送受信部１０２は、映像蓄積配信装置１に対してＴＥＡＲＤＯＷＮの応答を返す。
なお、一次蓄積のための受信を再開する時にイベント発生前の一定時間の映像が蓄積されているブロックのファイルをロックしているが、別の方法として、イベント専用のリングバッファや他の専用の記憶手段を設け、そこにイベント発生前の一定時間の映像を移し替えておいて、読み出せるようにしてもよい。

（２−３）一次蓄積したイベント発生前の映像を送信する際の詳細動作
イベント発生後にイベント発生前後の映像を閲覧する場合、任意の監視端末Ｔｒから蓄積映像送信要求が映像蓄積配信装置１に対して送信される。ここで、蓄積映像送信要求は、図３に示すように、ＤＥＳＣＲＩＢＥリクエスト、ＳＥＴＵＰリクエスト、ＰＬＡＹリクエストとこれらのリクエストに対するそれぞれの応答からなる。
リクエスト送受信部１０２は、監視端末ＴｒからのＳＥＴＵＰリクエストを映像蓄積配信装置１から受信した場合（図３ ＳＱ４）、該当するカメラＩＤの映像のファイルが一次蓄積映像ＤＢ４に蓄積されているかを調べ、存在する場合には、映像蓄積配信装置１に対して、その送信ポート情報と共にＳＥＴＵＰ応答を返す（図３ ＳＱ５）。リクエスト送受信部１０２では、送信した上記ＳＥＴＵＰ応答に対して、予め設定されたイベント前再生時間分前の時刻を読み出し開始時刻（または送信開始時刻）として指定したＰＬＡＹリクエストを映像蓄積配信装置１から受信すると（図３ ＳＱ８）、蓄積ストリーム送信部１０４のスレッドを起動し、カメラＩＤと送信開始時刻と映像蓄積配信装置１のアドレスと送信先ポートを蓄積ストリーム送信部１０４に通知する。蓄積ストリーム送信部１０４は、一次蓄積映像ＤＢ４内のファイル管理テーブル２０５の該当するカメラＩＤのテーブルを検索し、指定された送信開始時刻が格納されているブロックのファイル位置を特定する。そして、そのファイル位置にアクセスし、先頭パケットのＲＴＰパケットと受信開始時刻の関係から、必要な送信開始時刻より前で一番近いＲＴＰパケットを抽出し、そのパケットを送信開始パケットとする。ここで、送信開始パケットを選択する際に、送信開始時刻より前で一番近いイントラフレームの先頭パケットを選択することも可能である。そのために、ここでは監視カメラＣ１〜Ｃｎから送信される映像には定期的にイントラフレームが挿入されているものとする。

送信開始パケットを特定した蓄積ストリーム送信部１０４は、リクエスト送受信部１０２に対して、通知された送信開始時刻とその時間の映像が格納されているＲＴＰパケットのタイムスタンプを返す。ここで、送信開始時刻とそれに対応するＲＴＰパケットのタイムスタンプのペアにより、蓄積した時刻情報と、各ＲＴＰパケットで送信する映像データの時刻情報とを対応付けることが可能となる。リクエスト送受信部１０２は、この時刻情報とタイムスタンプの対応付け情報を格納したＰＬＡＹ応答を映像蓄積配信装置１に対して送信する（図３ ＳＱ９）。また、リクエスト送受信部１０２は、ＰＬＡＹ応答の送信が終了すると、蓄積ストリーム送信部１０４に対してストリームの送信開始通知を行う。なお、蓄積ストリーム送信部１０４は、複数同時に送信する場合には、複数起動されるものとする。

ストリーム送信開始通知を受け取ると、蓄積ストリーム送信部１０４は、一次蓄積映像ＤＢ４に蓄積しているＲＴＰパケットを、特定した送信開始位置から映像蓄積配信装置１に対して送信する（図３ ＳＱ１１）。送信はストリーミングで行い、ＲＴＰタイムスタンプのタイミングで送信するものとする。ただし、同一のＶＯＰ（Video Object Plane:ＭＰＥＧ４規格ＩＳＯ／ＩＥＣ１４４９６−２に定義されたビデオのフレーム）のパケットはすべて同一のタイムスタンプが付与されるため、ＶＯＰ間の時間間隔でビットレートが平滑化されるよう計算して送信する。送信中にリングバッファのブロックが終了したら、受信開始時刻を検索し、時間的に連続するブロックの先頭から送信を継続する。その後、リクエスト送受信部１０２は、映像蓄積配信装置１からのＴＥＡＲＤＯＷＮを受信すると（図３ ＳＱ１５）、蓄積ストリーム送信部１０４に終了通知を行ってストリーム送信を終了させた後、ＴＥＡＲＤＯＷＮ応答を映像蓄積配信装置１へ送信する（図３ ＳＱ１６）。

（３）一次蓄積映像ＤＢ４
一次蓄積映像ＤＢ４は、ハードディスク等のストレージ装置で構成され、図６に示すように、各監視カメラからの映像のＲＴＰパケットデータを個別に格納するリングバッファＢ１〜Ｂｎを備えている。リングバッファＢ１〜Ｂｎは、周知のように、一定量以上のデータを受信すると一番古いデータから、次に与えられるデータを上書きする構成になっており、エンドレスに一定量の映像データを蓄積していくことができるものである。リングバッファに蓄積するファイルの蓄積形式を図７に示す。ファイルは、図７（ａ）に示すようにパケット長２０１とＲＴＰパケット２０２で構成されている。管理に用いるファイル管理テーブルは、図７（ｂ）に示すように、カメラＩＤ２１０、ブロック番号２１１、ファイル位置２１２、先頭パケット受信時刻２１３および終了パケット受信時刻２１４で構成されている。
一次蓄積映像ＤＢ４において、ファイル化されたＲＴＰパケットデータはリングバッファＢ１〜Ｂｎの中のカメラＩＤに対応したバッファに書き込まれる。バッファにはパケット長２０１、ＲＴＰパケット２０２が連続して格納される。リングバッファは一定サイズのＸ個のブロックから構成されている。このようなリングバッファに書き込むために、集信装置３のファイルデータ化部Ｆ１〜Ｆｎでは、このブロックサイズ以下のデータにして結合した映像データを生成している。映像データがブロックに書き込まれると同時に、該当するカメラＩＤ２１０のファイル管理テーブル２０５のブロックＩＤ２１１の行に、そのブロックのファイル位置を示すファイル位置２１２、先頭パケット受信時刻２１３および終了パケット受信時刻２１４が記録される。一巡してすべてのブロックにデータが蓄積されると、一番古いデータが格納されたブロックに上書きされることで受信データをエンドレスに蓄積していく。

（４）映像蓄積配信装置
映像蓄積配信装置１は、図８に示すように、イベント受信部４００、蓄積ストリームリクエスト部４０１、ストリーム受信部４０２、ストリーム蓄積部４０３、イベントデータ管理部４０４、映像配信管理部４０５、ストリーム送信部４０６、配信ストリーム受信部４０７、イベント・映像対応ＤＢ（イベント・映像対応データベース）４５０、イベントＤＢ（イベントデータベース）４５１、イベント映像再生時間ＤＢ（イベント映像再生時間データベース）４５２、監視端末管理ＤＢ（監視端末管理データベース）４５３を備えている。
（４−１）イベント発生後のライブ映像を監視端末へ与え、かつそのライブ映像を蓄積する際の詳細動作
イベント受信部４００では、例えばイベント発生装置Ｅ１〜Ｅｎの一つから図４に示すイベントデータを受信した場合、そのイベントデータを蓄積ストリームリクエスト部４０１に出力する。蓄積ストリームリクエスト部４０１では、そのイベントデータに含まれているイベント発生装置ＩＤに基づいてイベント・映像対応ＤＢ４５０を検索し、イベントデータを送信したイベント発生装置に関連したカメラＩＤ、集信装置ＩＤ、集信装置アドレスを抽出する。イベント・映像対応ＤＢ４５０のデータ構成は、図９に示すように、イベント発生装置ＩＤ５００、集信装置ＩＤ５０１、集信装置アドレス５０２およびカメラＩＤ５０３を含んでいる。例えば図１で示されたイベント発生装置Ｅ１〜Ｅｎ、監視カメラＣ１〜Ｃｎ、およびこれらに関わる集信装置３の関係が映像対応ＤＢ４５０で予め設定される。ここで、集信装置アドレス５０２は集信装置のＩＰアドレスを表している。

蓄積ストリームリクエスト部４０１がイベント発生装置ＩＤに関連する集信装置ＩＤ、集信装置アドレス、カメラＩＤを抽出すると、イベントデータ管理部４０４は受信したイベントデータの内容をイベントＤＢ４５１へ登録する。イベントＤＢ４５１のデータ構成は、図１０に示すように、受信したイベントデータの内容であるイベント発生装置ＩＤ９０１、イベント種別ＩＤ９０２、発生時刻９０３、付属データ９０４およびそのイベントに対して設定したイベントＩＤ９００を含んでいる。イベントデータ管理部４０４は、設定したイベントＩＤ９００を蓄積ストリームリクエスト部４０１に送る。すると、蓄積ストリームリクエスト部４０１は、イベントに対応する集信装置アドレス５０２の予め決められているポート番号に対して、ライブ映像送信要求を送信する。ライブ映像送信要求にはＲＴＳＰが使用される。集信装置３には複数の監視カメラＣ１〜Ｃｎが接続されているため、ＲＴＳＰリクエストを行うＵＲＬによりカメラ映像に対するリクエストを行う。ここでは、「ｒｔｓｐ：／／集信装置のＩＰアドレス／ｌｉｖｅ／カメラＩＤ」を使用することで集信装置３に対し、カメラＩＤで指定した監視カメラのライブ映像送信要求を行う。このライブ映像送信要求中の集信装置のＩＰアドレスとカメラＩＤには対応するデータが記入されることになる。

ライブ映像送信要求は、ＤＥＳＣＲＩＢＥリクエスト、ＳＥＴＵＰリクエスト、ＰＬＡＹリクエスト等の複数の命令とこれらのリクエストに対する応答で構成されている。蓄積ストリームリクエスト部４０１は、始めに、ＤＥＳＣＲＩＢＥリクエストを集信装置３に送信する。蓄積ストリームリクエスト部４０１は、送信したＤＥＳＣＲＩＢＥリクエストに対するＤＥＳＣＲＩＢＥ応答を集信装置３から受信すると、そのＤＥＳＣＲＩＢＥ応答に格納されたリクエストした監視カメラに対応した映像の属性情報を取り出して記憶すると共に、ＳＥＴＵＰリクエストを生成して集信装置３に対して送信する。蓄積ストリームリクエスト部４０１は、送信したＳＥＴＵＰリクエストに対するＳＥＴＵＰ応答を集信装置３から受信すると、ＳＥＴＵＰ応答に含まれたマルチキャストアドレスとポート番号を取り出し、ストリーム受信部４０２のスレッドを生成して、受信したマルチキャストアドレスとポート番号をストリーム受信部４０２に通知した後、集信装置３に対してＰＬＡＹリクエストを送信する。ストリーム受信部４０２では、通知されたマルチキャストアドレスとポート番号に対して受信を開始し、ＲＴＰパケットの到着を待機する。

また、蓄積ストリームリクエスト部４０１では、上記ＰＬＡＹリクエストの送信と平行して、全監視端末Ｔ１〜Ｔｍに対して、イベントデータ発生通知を送信する。この場合、監視端末管理ＤＢ４５３に全監視端末Ｔ１〜Ｔｍの端末ＩＤとＩＰアドレス情報が予め登録されており、監視端末管理ＤＢ４５３を検索することにより、抽出した各監視端末のＩＰアドレスに対してイベントデータ発生通知の送信を行うことになる。イベントデータ発生通知は、図１１に示すように、イベントＩＤ７００、イベント発生装置ＩＤ７０１、イベント種別ＩＤ７０２、発生時刻７０３、付属データ７０４、集信装置ＩＤ７０５、集信装置アドレス７０６、マルチキャストアドレス７０７、ポート番号７０８および映像属性情報７０９を含んでいる。イベントＩＤ７００は、映像蓄積配信装置１内で採番したイベントを識別するＩＤである。イベント発生装置ＩＤ７０１、イベント種別ＩＤ７０２および発生時刻７０３は、イベント発生装置Ｅ１〜Ｅｎが発信するイベントデータ（図４）と同一である。集信装置ＩＤ７０５は、映像を配信する集信装置３のＩＤである。集信装置アドレス７０６は、集信装置３のＩＰアドレスである。マルチキャストアドレス７０７とポート番号７０８は、イベントに関連した映像が配信されるマルチキャストアドレスとポート番号である。映像の属性情報７０９は、プロファイルレベルＩＤとＤＣＩの情報を含んでいる。

蓄積ストリームリクエスト部４０１では、送信したイベントデータ発生通知に対する各監視端末からの応答を受信すると、最初に到着した受信可能応答に対応する監視端末（これをＴｙとする）に対して映像受信許可を送信し、その後に受信可能応答を受信した他の監視端末に対しては再生不許可のメッセージを送信する。これにより、イベント発生後の対応する監視カメラからのライブ映像の再生を行う監視端末Ｔｙが決定する。この場合、集信装置１を経由するライブ映像のＲＴＰパケットはネットワーク５を介して監視端末Ｔ１〜Ｔｍに送られるようになっているが、映像受信許可が与えられた監視端末Ｔｙのみがそのライブ映像を受信することになる。
一方、ストリーム受信部４０２では、集信装置３からライブ映像のＲＴＰパケットの受信を開始すると、一定時間バッファリングすることで、パケットの順序の入れ替わりを補正し、ＲＴＰパケットデータをストリーム蓄積部４０３に出力する。ストリーム蓄積部４０３では、蓄積ストリームリクエスト部４０１から映像属性情報であるＤＣＩ情報とイベントＩＤを予め受信しておき、ストリーム受信部４０２から入力されたライブ映像のＲＴＰパケットを蓄積映像ＤＢ２に蓄積する。映像の蓄積フォーマットはどのようなフォーマットでもよいが、この実施の形態１では図７に示したフォーマットで蓄積するものとする。

イベント映像再生時間ＤＢ４５２では、各イベントに対応する映像について、イベント発生前後に再生する時間を設定している。このデータ構成は、図１２に示すように、イベント前再生時間１０００とイベント後再生時間１００１からなる。ストリーム蓄積部４０３ではイベント発生後のライブ映像のＲＴＰパケットを蓄積映像ＤＢ２に蓄積する動作を行うが、その際、映像配信管理部４０５は、このライブ映像を、イベント発生時刻からイベント映像再生時間ＤＢ４５２で設定したイベント後再生時間１００１の時間長にして蓄積するよう蓄積映像ＤＢ２を制御する。そして、映像配信管理部４０５は、このイベント後映像の蓄積を行うと、その蓄積内容を表す映像管理テーブル８１０を生成して蓄積映像ＤＢ２に格納すると共に、蓄積ストリームリクエスト部４０１からＴＥＡＲＤＯＷＮメッセージを集信装置３に対して送信する。これに対して集信装置３からＴＥＡＲＤＯＷＮの応答を受け取ると、蓄積ストリームリクエスト部４０１はストリーム受信部４０２とストリーム蓄積部４０３に対して通知し、蓄積動作を終了させる。上記映像管理テーブル８１０は、図１４に示すように、蓄積したイベント後映像に対応する、イベントＩＤ８００、蓄積ファイルＩＤ８０１、ＤＣＩ８０２および蓄積時間８０３のデータで構成されている。ここで、蓄積時間とは、蓄積映像ＤＢ２に蓄積されたイベント後映像の時間長を表しており、イベント映像再生時間ＤＢ４５２で設定したイベント後再生時間１００１に該当する。

（４−２）イベント発生前に一次蓄積した映像とイベント発生後に蓄積した映像を監視端末Ｔｙへ配信する際の詳細動作
イベント発生後のライブ映像の送信と蓄積が終了した後、任意の監視端末（例えばＴｙとする）から蓄積映像送信要求が送信される。映像配信管理部４０５は、監視端末ＴｙからＤＥＳＣＲＩＢＥリクエストを受信した場合（図３ ＳＱ１）、そのＤＥＳＣＲＩＢＥリクエストから、後述するようなリクエストＵＲＬのイベントＩＤを取り出す。イベントデータ管理部４０４では、映像配信管理部４０５が取り出したイベントＩＤに基づいて図１０に示されるイベントＤＢ４５１を検索し、対応するイベント発生装置ＩＤ９０１、イベント種別ＩＤ９０２、発生時刻９０３および付属データ９０４を抽出して映像配信管理部４０５に与える。映像配信管理部４０５は、このイベントデータを受け取ると、図９に示すイベント・映像対応ＤＢ４５０を検索し、イベント発生装置ＩＤ９０１に対応する集信装置ＩＤ５０１、集信装置アドレス５０２およびカメラＩＤ５０３を抽出し、続けて、蓄積映像ＤＢ２内の図１４に示す映像管理テーブル８１０から、リクエストを受けたイベントＩＤに対応する蓄積ファイルＩＤ８０１とＤＣＩ８０２を抽出して、ＳＤＰに格納するプロファイルレベルＩＤとＤＣＩ情報を生成し、ＤＥＳＣＲＩＢＥ応答として、ＤＥＳＣＲＩＢＥリクエストを送信した監視端末Ｔｙに対して返信する（図３ ＳＱ２）。

ここで、図１３にＭＰＥＧ−４のＳＤＰの例１９００を示す。下線部分に関しては、実際のＳＤＰでは数値やバイト列が記述される。ビットレート１９０１は、伝送する映像のビットレートを示す。ＵＲＬ１９０２は、伝送する映像のＵＲＬ示す。再生時間１９０３は、映像の再生時間を示し、予め設定されているイベント映像再生時間ＤＢ４５２内のイベント前再生時間１０００とイベント後再生時間１００１を加算した時間を格納している。ＰＴ値１９０４は、ペイロードタイプ値を格納しており、ＲＴＰでＭＰＥＧ−４用に割り当てたペイロードタイプを記述する。通常ＭＰＥＧ−４のＲＴＰ伝送におけるペイロードタイプは、９６から割り当てられているダイナミックレンジの一つを使用する。プロファイルレベルＩＤ１９０５は、送信するＭＰＥＧ−４映像のプロファイルレベルＩＤを格納している。プロファイルレベルＩＤはＤＣＩ８０２から作成可能である。ＤＣＩ１９０６には、送信するＭＰＥＧ―４のＤＣＩ８０２が格納される。デコーダはＤＣＩ１９０６から、符号化された映像データの復号を行うパラメータを取得することが可能となる。

ＤＥＳＣＲＩＢＥ応答に対してＳＥＴＵＰリクエストを監視端末Ｔｙから受信すると（図３ ＳＱ３）、映像配信管理部４０５では、該当イベントに対応するイベント前映像を蓄積管理している集信装置３のＩＰアドレスに対して、このＳＥＴＵＰリクエストを送信する（図３ ＳＱ４）。この場合の送信先となる集信装置３では、ＤＥＳＣＲＩＢＥリクエスト受信時に検索した情報を使用するため、集信装置３に対しては、リクエストＵＲＬとして、
ｒｔｓｐ：／／集信装置アドレス／ｆｉｌｅ／カメラＩＤ
を使用する。ここで、集信装置アドレスとカメラＩＤには、対応するデータが記入される。
ＳＥＴＵＰリクエストの送信先の集信装置３から、対応する一次蓄積ファイルが存在することを表すＳＥＴＵＰ応答を受信すると（図３ ＳＱ５）、映像配信管理部４０５は、配信ストリーム受信部４０７のスレッドを起動し、蓄積映像の送信元になる集信装置３のアドレスと受信ポート番号を指定することで、ＲＴＰパケットの受信準備を開始すると共に、ストリーム送信部４０６のスレッドを起動し、送信先のポート番号と監視端末Ｔｙのアドレス情報を指定する。なお、配信ストリーム受信部４０７およびストリーム送信部４０６は、複数の配信を行う場合には複数のスレッドの起動を行うものとする。その後、監視端末Ｔｙに対して送信先のポート番号を格納したＳＥＴＵＰ応答を送信する（図３ ＳＱ６）。このＳＥＴＵＰ応答に対するＰＬＡＹリクエストを監視端末Ｔｙから受信すると（図３ ＳＱ７）、映像配信管理部４０５は、イベント発生時刻に対してイベント映像再生時間ＤＢ４５２で設定したイベント前再生時間１０００分前の時刻を指定したＰＬＡＹリクエストを集信装置３に対して送信する（図３ ＳＱ８）。

映像配信管理部４０５では、送信したＰＬＡＹリクエストに対するＰＬＡＹ応答を集信装置３から受信すると（図３ ＳＱ９）、そのＰＬＡＹ応答メッセージから時刻情報とタイムスタンプの関係を示す情報を取り出し、図１４に示すような蓄積映像ＤＢ２内の映像管理テーブル８１０を検索して、イベントデータに対応する映像データのファイルＩＤを特定し、同時にＰＬＡＹ応答を監視端末Ｔｙに対して送信する（図３ ＳＱ１０）。ここでは、検索したファイルＩＤをオープンし、先頭ＲＴＰパケットのタイムスタンプを読み出し、これを集信装置３から受信した時刻情報とタイムスタンプの関係情報から時刻情報に変換し、イベント発生時の時刻情報をストリーム送信部４０６に通知する。同時にＲＴＰタイムスタンプと時刻情報の関係情報も送信する。ここで、一次蓄積映像ＤＢ４と蓄積映像ＤＢ２に蓄積しているＲＴＰパケットはもともと同じストリームの前後を蓄積したものであるため、タイムスタンプ情報の変換は必要ない。配信ストリーム受信部４０７は、集信装置３から送信されるイベント前映像を受信し（図３ ＳＱ１１）、ＲＴＰパケットの形式でストリーム送信部４０６に対して入力する。ストリーム送信部４０６では、ストリーム受信部４０７から入力されたＲＴＰパケットのタイムスタンプを時刻情報に変換して、時刻情報が次に送信するイベント後映像の開始時刻に達していないかの確認を行う。達していない場合には、入力されたＲＴＰパケットを監視端末Ｔｙに対して送信する（図３ ＳＱ１２）。

一方、ストリーム送信部４０６は、時刻情報がイベント後映像の開始時刻に達した場合には、映像配信管理部４０５にイベント時刻到達通知を行う。このイベント時刻到達通知を受けた映像配信管理部４０５は、ストリーム送信部４０６に対して、蓄積映像ＤＢ２の配信対象とする映像ファイルの蓄積ファイルＩＤ８０１を通知すると共に、集信装置３に対して、ＲＴＳＰのＴＥＡＲＤＯＷＮリクエストを送信し、イベント前映像の送信の終了を行わせる（図３ ＳＱ１５）。ストリーム送信部４０６は、通知されたファイルＩＤの映像ファイルをオープンし、先頭から時間情報をチェックし、最後に受信したイベント前映像のＲＴＰパケットの次のＲＴＰパケットよりイベント後映像の送信を開始する（図３ ＳＱ１４）。ここで、集信装置３からのイベント前映像と同様にＲＴＰタイムスタンプに合わせて監視端末Ｔｙに対してストリーム配信を行う。したがって、イベント前映像とイベント後映像をシームレスにして配信することができる。そして、ストリーム送信部４０５は、イベント映像再生時間ＤＢ４５２で設定されているイベント後再生時間１００１のイベント後映像を送信すると、配信を終了する。

（５）蓄積映像ＤＢ２
蓄積映像ＤＢ２は、映像蓄積配信装置１で受信したイベント発生後のライブ映像をイベント後映像として蓄積する手段である。詳しくは、映像蓄積配信装置１で説明したように、予め設定されているイベント後再生時間１００１の長さの映像が蓄積される。この蓄積映像ＤＢ２には、図１４に示す映像管理テーブル８１０も格納される。前述したように、映像管理テーブル８１０のデータである、イベントＩＤ８００、蓄積ファイルＩＤ８０１、ＤＣＩ８０２および蓄積時間８０３は、映像蓄積配信装置１において、蓄積ストリームリクエスト部４０１から蓄積終了通知を受け取ったストリーム蓄積部４０３が映像ファイルをクローズしたときに生成され格納される。

（６）監視端末Ｔ１〜Ｔｍ
監視端末Ｔｙ（１≦ｙ≦ｍ）は、図１５に示すように、リクエスト送受信部６００、映像受信部６０１、映像復号部６０２、表示部６０３、イベント一覧管理部６０４およびイベントＤＢ（イベントデータベース）６０５を備えている。
（６−１）イベント発生後のライブ映像を受信再生する際の詳細動作
リクエスト送受信部６００は、映像蓄積配信装置１からイベントデータ発生通知を受信した場合、イベント一覧管理部６０４に通知すると共に、現在の監視映像（ライブ映像）を再生可能である場合には受信可能応答を、また、例えば既に他のイベントが発生した映像を再生している場合などで再生不可である場合には受信不可能応答を映像蓄積配信装置１に送信する。これらの受信可能応答と受信不可能応答には、イベントＩＤと受信可能・不可能を示すフラグが格納されている。また、イベント一覧管理部６０４は、受信したイベントデータ発生通知のデータをイベントＤＢ６０５のイベント一覧に蓄積する。このイベントＤＢ６０５の構成は、映像蓄積配信装置１のイベントＤＢ４５１と同様である。

リクエスト送受信部６００は、送信した受信可能応答に対する映像受信許可を映像蓄積配信装置１から受信すると、映像受信部６０１、映像復号部６０２および表示部６０３のスレッドを起動し、映像受信部６０１にマルチキャストアドレスとポート番号を通知し、また映像復号部６０２に対して映像属性情報であるプロファイルレベルＩＤとＤＣＩを通知する。映像受信部６０１は、受信を開始して集信装置３からネットワーク５を経由して与えられるライブ映像のＲＴＰパケットを受信すると、一定時間バッファリングを行うことで到着順序の補正を行った後、ＲＴＰパケットのタイムスタンプとＲＴＰペイロードに格納されている映像符号データを映像復号部６０２に入力する。映像復号部６０２では、映像データの復号を行い、ＲＴＰタイムスタンプ情報とそれに対応する復号映像を表示部６０３へ送信する。表示部６０３では、ＲＴＰタイムスタンプのタイミングに合わせて、ライブ映像を再生表示する。

（６−２）イベント発生前に一次蓄積した映像とイベント発生後に蓄積した映像の連続映像を受信再生する際の詳細動作
イベント発生後のライブ再生の終了後において、イベントＤＢ６０５で管理している発生イベントの中の一つをユーザが選択した場合、イベント一覧管理部６０４は選択されたイベントＩＤをリクエスト送受信部６００に通知する。リクエスト送受信部６００は、通知されたイベントＩＤに関する蓄積映像送信要求を映像蓄積配信装置１に対して送信する。この蓄積映像送信要求にはＲＴＳＰを使用する。ＤＥＳＣＲＩＢＥリクエストにするＵＲＬは、
ｒｔｓｐ：／／映像蓄積配信装置のＩＰアドレス／イベントＩＤ
とする。ここで、映像蓄積配信装置のＩＰアドレスとイベントＩＤには、対応するデータが記入される。

リクエスト送受信部６００は、始めに、映像蓄積配信装置１に対して上記リクエストＵＲＬでＤＥＳＣＲＩＢＥリクエストを送信する（図３ ＳＱ１）。このＤＥＳＣＲＩＢＥリクエストに対するＤＥＳＣＲＩＢＥ応答を映像蓄積配信装置１から受信すると（図３ ＳＱ２）、リクエスト送受信部６００は、ＳＤＰ１９００（図１３）内に格納されているＤＣＩ１９０６と再生時間１９０３を取り出し記憶した後、ＳＥＴＵＰリクエストを映像蓄積配信装置１に対して送信する（図３ ＳＱ３）。このＳＥＴＵＰリクエストに対するＳＥＴＵＰ応答を映像蓄積配信装置１から受信すると（図３ ＳＱ６）、リクエスト送受信部６００は、このＳＥＴＵＰ応答に格納されているポート番号を映像受信部６０１に通知し、ポートを開いて待機させる。その後、映像蓄積配信装置１に対してＰＬＡＹリクエスト（図３ ＳＱ７）を送信する。ＰＬＡＹリクエストに対するＰＬＡＹ応答を映像蓄積配信装置１から受信すると（図３ ＳＱ１０）、リクエスト送受信部６００は映像受信部６０１、映像復号部６０２、表示部６０３を起動して、映像のＲＴＰパケットの受信に待機させる。
映像受信部６０１は、集信装置３が一次蓄積映像ＤＢ４から読み出したイベント前映像と映像蓄積配信装置１が蓄積映像ＤＢから読み出したイベント前映像の連続映像をストリーム受信すると（図３ ＳＱ１２、ＳＱ１４）、受信したＲＴＰパケットをバッファで一定時間バッファリングし、パケットの入れ替わりを修正した後、１ＶＯＰ単位毎にＲＴＰタイムスタンプと共に映像復号部６０２に入力する。映像復号部６０２は、入力された映像データを復号し、復号映像とＲＴＰタイムスタンプを表示部６０３に出力し再生映像を得る。

以上のように、この実施の形態１によれば、イベントが発生していない通常状態において、監視カメラＣ１〜Ｃｎの各映像をイベント前映像として集信装置３により一次蓄積映像ＤＢ４に蓄積しておき、イベントが発生した場合には対応する監視カメラのライブ映像をイベント後映像として映像蓄積配信装置１によりイベント後再生時間を指定して蓄積映像ＤＢ２に蓄積すると共に、イベント発生後のライブ映像を許可した監視端末で再生するようにしたので、イベント発生時刻を境に前後のイベントに対応する映像を確保できると共に、このときのネットワーク５で使用する映像データはイベント発生後のライブ映像だけとなる。また、任意の監視端末で発生履歴のあるイベントデータを指定することで、集信装置３が一次蓄積映像ＤＢ４に蓄積されているイベント前映像を設定したイベント前再生時間分蓄積監視装置１に配信し、映像蓄積配信装置１において、このイベント前映像と蓄積映像ＤＢ２に蓄積されているイベント後映像を、イベント発生時刻を境に切り替えて連続して蓄積映像送信要求を出した監視端末に対して配信するようにしたので、シームレスのイベント前後の蓄積映像を閲覧することが可能となる。

実施の形態２．
この実施の形態２では、実施の形態１で説明した映像蓄積装置において、イベント時間再生ＤＢ内の再生時間データを変更設定することを可能にする機能について説明する。
図１６はこの発明の実施の形態２に係る映像蓄積配信装置の機能構成を示すブロック図である。図において、図８に相当する部分には同一符号を付して示す。この実施の形態２の映像蓄積配信装置１１では、図８の構成に対して、新たにイベント映像再生時間設定部１１０１が設けられており、また、イベント映像再生時間ＤＢ４５２に代わって、異なるデータ構成のイベント映像再生時間ＤＢ１２００が設けられている。
イベント映像再生時間設定部１１０１は、イベント映像再生時間ＤＢ１２００内のイベント前再生時間１０００および／もしくはイベント後再生時間１００１の値を変更する手段である。
イベント映像再生時間ＤＢ１２００は、図１７に示すように、イベント種別ＩＤ２０１、イベント前再生時間１２０２およびイベント後再生時間１２０３で構成されている。図１２のイベント映像再生時間ＤＢ４５２の場合にはイベントの種類に係わらずイベント再生時間が一律に設定されているのに対し、この実施の形態２の動作で用いるイベント映像再生時間ＤＢ１２００は、イベント再生時間をイベント種別ＩＤ毎に異なる値に設定可能とするデータ構成となっている。

イベント発生装置として、例えばカード操作で入退出を行う入退出管理システムを考えた場合、カード操作時にイベントが発生することになるので、入退出者を監視するためのイベント前後の映像は、１０〜数１０秒程度の設定で十分である。また、イベント発生装置が監視先の異常温度検出に対応するものである場合、発生したイベントデータが意味する背景として、温度上昇が徐々に起こり高温に達した可能性もある。そのような場合には、イベント前映像の時間長を状況に応じて、例えば５分程度に設定しておくことが望まれる。そのため、イベント再生時間ＤＢ１２００において、イベント前再生時間１２０２および／もしくはイベント後再生時間１２０３をイベント種別ＩＤ毎に設定するようにしておくことにより、イベント特性に合わせたイベント種類毎の再生時間を得ることが可能となる。これらに対応するために、イベント映像再生時間設定部１１０１では、イベント映像再生時間ＤＢ１２００におけるイベント種別毎にイベント前後の再生時間の変更設定を行う。この場合、映像配信管理部４０５では、イベントデータ管理部４０４より受信したイベントデータにあるイベント種別ＩＤに基づいてイベント映像再生時間ＤＢ１２００を検索し、そのイベント種別に対応するイベント前再生時間１２０２とイベント後再生時間１２０３を抽出する。そして、集信装置３から配信してもらうイベント前映像の頭出し位置（すなわち、イベント発生時刻に対してイベント前再生時間１２０２分前の時刻）を指定し、また、映像蓄積ＤＢ２に蓄積するイベント後映像の頭出し位置と時間長（すなわち、イベント発生時刻からイベント後再生時間１２０３分前の時刻）設定する。これにより、イベント種別毎に異なるイベント映像の再生時間でイベント前映像とイベント後映像の再生を行うことが可能となる。

上記例では、イベント前再生時間および／もしくはイベント後再生時間の設定を、イベント種別毎に行う方法について述べたが、これに限定されるものではない。例えば、イベント発生装置ＩＤ毎による設定、集信装置ＩＤ毎による設定、カメラＩＤ毎による設定としてもよい。その場合、例えば建物外部あるいは建物外部に通じる入り口に設置されている機器についてはイベント前再生時間やイベント後再生時間を長めに設定しておき、一方、建物内部に設置されている機器についてはイベント前再生時間やイベント後再生時間を短く設定しておくことが好ましい。

上記のように、イベント映像再生時間ＤＢ１２００の内容を変更できるようにした場合、蓄積時と再生時でイベント再生時間ＤＢ１２００の値が異なる場合が発生する。そのため、映像配信管理部４０５では、映像蓄積配信装置１１から監視端末Ｔｙに対して返信するＤＥＳＣＲＩＢＥ応答に格納する再生時間を作成する際に、図１４に示す映像管理テーブル８１０中のイベントＩＤに対応する映像ファイルの蓄積時間８０３と、図１７に示すイベント映像再生時間ＤＢ１２００のイベント後再生時間１２０３とを比較して短い時間の方を選択し、イベント映像再生時間ＤＢ１２００のイベント前再生時間と加算した値を再生時間として設定する。また、映像蓄積配信装置１１がイベント後映像に切り替えて、監視端末Ｔｙに対して映像を配信している際の映像配信の終了時間の決定も、前記と同様に、映像管理テーブル８１０の蓄積時間８０３と、イベント映像再生時間ＤＢ４５２のイベント後再生時間１００１とを比較して短い方の時間を選択し、配信時間とする。これにより、例えば監視員が複数人で監視を行っている時間帯には、イベント前映像、イベント後映像を長めに設定して、詳細を確認できるようにし、また、監視員が少数で監視を行っている時間帯にはイベント前映像、イベント後映像を短めに設定して、効率的に監視を行えるようにすることが可能となる。

以上のように、この実施の形態２によれば、蓄積映像に対するイベント前再生時間および／もしくはイベント後再生時間を設定変更する手段を設けているので、イベントの種類別毎に応じて、あるいは監視状況に合わせて、最適な時間帯の蓄積映像を再生することができる。

実施の形態３．
この実施の形態３では、イベント発生後のライブ映像の映像蓄積配信装置内への蓄積開始や監視端末への配信開始をイントラフレームから行うようにする例について述べる。
図１８はこの発明の実施の形態３に係る映像蓄積配信装置の機能構成を示すブロック図である。図において、図８に相当する部分には同一符号を付して示す。この実施の形態３の映像蓄積配信装置１３では、図８の構成に対して、図８の蓄積ストリームリクエスト部４０１、ストリーム受信部４０２、イベント・映像対応ＤＢ４５０の代わりに、一部動作が異なる蓄積ストリームリクエスト部１３０１、ストリーム受信部１３０２、イベント・映像対応ＤＢ１３５０がそれぞれ設けられ、また、ストリーム受信部１３０２に対して、新たにイントラ判定部１３０３が設けられている。
映像蓄積配信装置１３がイベントデータを受信する部分までの動作は実施の形態１と同様とする。蓄積ストリームリクエスト部１３０１は、イベント発生時に図４に示したイベントデータを受信すると、イベント発生装置ＩＤ３００をキーにして、図１９に示されるデータ構成を持つイベント・映像対応ＤＢ１３５０を検索し、一致するするイベント発生装置ＩＤ５００に関連する集信装置ＩＤ５０１、集信装置アドレス５０２、カメラＩＤ５０３、カメラアドレス１４００を抽出する。そして、抽出したカメラアドレス１４００に対応するカメラＣｚ（１≦ｚ≦ｎ）に対して、イントラフレーム要求メッセージを送信する。このイントラフレーム要求メッセージはライブ映像送信要求のＰＬＡＹリクエストに添付されて集信装置３系由でカメラＣｚに渡される。映像蓄積配信装置１３からイントラフレーム要求メッセージを受けたカメラＣｚは、登録されている一定時間の間に、指定された間隔で、イントラフレームを発生する。

映像蓄積配信装置１３から集信装置３、監視端末Ｔ１〜Ｔｍに対する通信動作は実施の形態１と同様とする。次に、映像蓄積配信装置１３では、ＲＴＳＰのＰＬＡＹリクエストを送信することにより、集信装置３から送られてきた映像データをストリーム受信部１３０２で受信する。ストリーム受信部１３０２では、ＲＴＰパケットのタイムスタンプが一つ前のパケットと異なるＲＴＰパケットを受信すると、イントラ判定部１３０３に対してＲＴＰパケットデータのコピーを送信する。イントラ判定部１３０３では、受信したＲＴＰパケット内のペイロードに格納されているＶＯＰヘッダを解析し、「ｖｏｐ＿ｃｏｄｉｎｇ＿ｔｙｐｅ」の値からイントラフレームか否かを判定し、その判定結果をストリーム受信部１３０２に返す。ストリーム受信部１３０２では、判定結果が、受信したＲＴＰパケットがイントラフレームであることを示した場合には、そのＲＴＰパケットをストリーム蓄積部４０３に出力して蓄積映像ＤＢ２への蓄積を開始する。一方、判定結果がイントラフレームでない場合には、受信したＲＴＰパケットを削除し、蓄積は開始せず、次のパケットの状態を待つ。

以上のように、この実施の形態３によれば、ライブ映像送信要求の送信時に、発生イベントに対応する監視カメラに対してイントラフレーム要求メッセージを送信し、蓄積映像ＤＢ２に蓄積するイベント発生後のライブ映像の先頭画像を、前記イントラフレーム要求メッセージに従って前記監視カメラが出力するイントラフレーム（Ｉフレーム）とするようにしたので、図１２に示すイベント映像再生時間ＤＢ４５２でイベント前再生時間が０に設定されていた場合でも、イントラフレームから映像配信を開始することが可能となる。

実施の形態４．
上記実施の形態１においても、集信装置３からの一次蓄積されたイベント前映像の配信はイントラフレームから開始することも可能であることについて記述した。そのような場合において、蓄積映像ＤＢ２に蓄積されているイベント後映像がイントラフレームから蓄積されておらず、かつイベント映像再生時間ＤＢ４５２のイベント前再生時間が０に設定される場合に、蓄積映像の配信時に常にイントラフレームから配信できる例について説明する。
図２０はこの発明の実施の形態４に係る映像蓄積配信装置の機能構成を示すブロック図である。図において、図８に相当する部分には同一符号を付して示す。この実施の形態４の映像蓄積配信装置１５では、図８の映像配信管理部４０５の代わりに、一部動作が異なる映像配信管理部１５０２が設けられ、この映像配信管理部１５０２に対して、新たにイントラ判定部１５０１が設けられている。

映像蓄積配信装置１５に対して監視端末Ｔｙからのイベントの指定による蓄積映像送信要求を送信する動作については実施の形態１と同様とする。図１２に示すイベント映像再生時間ＤＢ４５２のイベント前再生時間が０に設定されていた場合、映像配信管理部１５０２は、蓄積映像ＤＢ２に蓄積されているイベント後映像の配信を行う際、蓄積映像ＤＢ２から該当ファイルを検索し、イントラ判定部１５０１に出力する。イントラ判定部１５０１では、ＶＯＰヘッダ中の「ｖｏｐ＿ｃｏｄｅｉｎｇ＿ｔｙｐｅ」を検索することにより、そのパケットがイントラフレームか否かを判定する。判定結果がイントラフレームでなかった場合、実施の形態１と同様に、蓄積映像送信要求のＰＬＡＹリクエスト時には送信開始時間としてイベント発生時刻を指定して、当該イベントデータに対応する集信装置３に対して、一次蓄積映像のイントラフレームからの配信を要求する。なお、この場合の集信装置３は、実施の形態１で説明したイントラフレームからの一次蓄積映像の配信を開始する設定になっているものとする。集信装置３は、蓄積映像送信要求で送信開始時間としてイベント発生時刻が指定されている場合にはイベント発生時刻近傍のイベント前映像をイントラフレームから映像蓄積配信装置１５に送信する。映像蓄積配信装置１５は、イントラフレームからのイベント前映像を受信すると、実施の形態１と同一の処理により監視端末Ｔｙに対して配信を開始する。その後は、映像蓄積配信装置１５は、イベント発生時刻のタイミングで蓄積映像ＤＢ２に蓄積している対応したイベント後再生時間長のイベント後映像のデータに切り替えて配信する。

以上のように、この実施の形態４によれば、集信装置３は、蓄積映像送信要求で送信開始時間としてイベント発生時刻が指定されている場合には、一次蓄積映像ＤＢ４に蓄積されたイベント発生時刻近傍のイベント前映像をイントラフレームから送信するようにし、映像蓄積配信装置１５は、受信したイベント発生時刻近傍のイントラフレームで開始されるイベント前映像に続けて蓄積映像ＤＢ２に蓄積された対応するイベント後映像を、蓄積映像送信要求を送信した監視端末Ｔｒに配信するようにしたので、イベント後映像について、蓄積時には特にイントラフレームを意識せずに行った場合においても、蓄積映像の配信時には常にイントラフレームから配信することができる。特に、イベント映像再生時間ＤＢ４５２でイベント前再生時間が０に設定されている場合、蓄積映像送信要求のイベントデータに対応する蓄積映像ＤＢ２に蓄積されているイベント後映像がイントラフレームで再生開始されなくても、補足されたイントラフレームからの映像データを配信することができるので、監視端末Ｔｙでは、イントラフレームから表示を開始することが可能となる。

実施の形態５．
実施の形態５では、複数の関連するイベントデータの蓄積映像を連携させて配信する例について説明する。
図２１はこの発明の実施の形態５に係る映像蓄積配信装置の機能構成を示すブロック図である。図において、図８に相当する部分には同一符号を付して示す。この実施の形態５の映像蓄積配信装置１６では、図８の映像配信管理部４０５、イベントデータ管理部４０４、ストリーム送信部４０６の代わりに、一部動作が異なる映像配信管理部１６０２、イベントデータ管理部１６０３、ストリーム送信部１６０４がそれぞれ設けられ、また、映像配信管理部１６０２に対して新たに配信スケジュール管理部１６０１が設けられている。

映像蓄積配信装置１６におけるイベント発生後の映像の蓄積処理は実施の形態１と同様とする。監視端末Ｔｙから実施の形態１と同様にイベントＩＤを指定した蓄積映像送信要求が映像配信管理部１６０２に到着した場合、映像配信管理部１６０２では、イベント映像再生時間ＤＢ４５２から設定されたイベント前後の再生時間（イベント前再生時間とイベント後再生時間）を取得する。次に、映像配信管理部１６０２は、イベントデータ管理部１６０３に対して、イベントＩＤとイベント前後の再生時間を渡す。イベントデータ管理部１６０３は、受信したイベントＩＤをキーにしてイベントＤＢ４５１を検索し、対応するイベントデータを抽出すると共に、上記イベント前後の再生時間内に発生した別のイベントのイベントデータを抽出する。このように関連付けた両イベントデータが抽出された場合には、イベントデータ管理部１６０３は、両イベントデータを映像配信管理部１６０２に返す。

次に、上記関連付けた両イベントデータを受信した場合、映像配信管理部１６０２は、配信スケジュール管理部１６０１に対して、関連付けた両イベントデータおよびイベント映像再生時間ＤＢ４５２から得たイベント前再生時間とイベント後再生時間を出力する。配信スケジュール管理部１６０１では、入力された両イベントデータおよびイベント前再生時間とイベント後再生時間に基づいて、対応するそれぞれの映像を連続して再生するためのスケジュール情報を生成する。このスケジュール情報は、各イベントデータを発生時刻順に整列し、その順に再生する映像のスケジュールを示す情報である。なお、イベントデータ管理部１６０３による検索で関連付けたイベントデータが抽出されなかった場合には、実施の形態１と同様な方法で蓄積映像が配信される。

配信スケジュール管理部１６０１おけるスケジュール情報の生成方法は図２２に示される。図２２は、時間軸１７１３に対して、イベント１とそれに関連するイベント２の発生状況と、それぞれのイベントに対応した蓄積映像を再生するスケジュール情報１７０２を表している。
まず、イベント１の発生タイミング１７０４とイベント映像再生時間ＤＢ４５２からのイベント１のイベント前再生時間１７０３に基づいて、イベント１の映像開始タイミングを決定する。次に、イベント２の発生タイミング１７０７とイベント２のイベント前再生時間１７０６に基づいて、イベント１とイベント２に対応して蓄積された映像の再生切り替え時間を決定する。次に、イベント１とイベント２の両者のイベント後再生時間の関係から終了時間を決定する。さらに、各イベントの発生タイミングにおいて一次蓄積映像ＤＢ４中のイベント前映像から蓄積映像ＤＢ２中のイベント後映像に切替えを行うための切り替えポイントを決定する。
イベント１の発生タイミング１７０４において、一次蓄積映像ＤＢ４に蓄積されているイベント１前映像１７０９から蓄積映像ＤＢ２に蓄積されているイベント１後映像に切り替える。同様に、イベント２の発生タイミング１７０７において、イベント２前映像１７１１からイベント２後映像１７１２に切り替える。これによりスケジュール情報１７０２が得られる。
なお、イベント１とイベント２に対応する映像の切り替え時間が、イベント１の発生タイミング１７０４より時間的に先になる場合には、イベント２に対応する映像はイベント２の発生タイミング１７０７で切り替えることとする。

スケジュール情報の構成を図２３に示す。スケジュール情報１８００は、イベント数１８０１、イベントＩＤ１８０２、フラグ１８０３、イベント前映像開始時刻１８０４およびイベント後映像開始時刻１８０５から成る。イベント数１８０１は、スケジュールデータに格納されているイベントの数を示すデータである。イベントＩＤ１８０２からはイベントの表示順序を認識することが可能となる。フラグ１８０３は、続くイベント前映像開始時刻が有効か否かを示すフラグであり、前述したイベント同士の発生タイミングの関係によりイベント前映像を配信しない場合に使用する。イベント前映像開始時刻１８０４は、イベントＩＤに対応して集信装置３に対してリクエストを行うイベント前映像の時刻を示すものである。ここでいう時刻には、撮影された日付と時刻を示す。イベント後映像開始時刻１８０５は、同様に蓄積映像ＤＢ２に蓄積されているイベントＩＤに対応した映像の開始時刻であり、同様に撮影された日付と時刻を示している。

映像配信管理部１６０２は、配信スケジュール管理部１６０１からスケジュール情報を受けると、そのスケジュール情報に従って監視端末Ｔｒに対してイベント前後の蓄積映像の配信を開始する。このときの映像配信の方法について図２２を例に説明すると、イベント１前映像１７０９とイベント１後映像１７１０の配信に関しては、スケジュール情報に従って配信を行うが、基本的には実施の形態１と同様の方式で配信することになる。イベント１後映像１７１０の配信後、イベント２前映像１７１１に切り替える部分については、次のようにする。映像配信管理部１６０２は、ストリーム送信部１６０４に対して予めイベント１後映像１７１０からイベント２前映像１７１１に切り替えるタイミング情報を通知しておく。ストリーム送信部１６０４では、イベント１後映像１７１０の送信中に、次の配信対象のイベント２前映像１７１１の配信開始時刻とイベント１後映像１７１０の配信中の時刻を比較し、その差が予め設定されている閾値よりも小さくなったときに、映像配信管理部１６０２に通知する。映像配信管理部１６０２では、イベント２前映像を蓄積管理している集信装置３に対してＲＴＳＰを使用して映像のリクエストを送信する。ここで、上記予め設定されている閾値は、リクエスト送受信に要する時間や映像の伝送遅延などを考慮し、設定されるものとする。

集信装置３への映像のリクエストから配信ストリーム受信部４０７が映像を受信し始めるまでの処理は、イベント１前映像１７０９の受信リクエストからその映像を受信するまでの処理と同様である。ここで、映像配信管理部１６０２は、ＰＬＡＹリクエスト送信時に受信した集信装置３からの先頭パケットの時刻情報を配信ストリーム受信部４０７に通知しておく。映像受信を行った配信ストリーム受信部４０７はストリーム送信部１６０４に対して、受信した映像のＲＴＰパケットを入力する。この実施の形態５のストリーム送信部１６０４はバッファを有しており、現在送信しているイベント１後映像１７１０が、スケジュール情報１７０２におけるイベント２映像前映像の先頭時刻になるまでイベント１後映像１７１０のバッファリングを行い、先頭時刻になった時点で、送信する映像をイベント１後映像１７１０からイベント２前映像１７１１に切り替える。ここで、イベント１後映像１７１０の最終ＲＴＰパケットはＶＯＰの最終で切り替えることとする。切り替え後のＲＴＰパケットは、切り替え前のＲＴＰパケットと別ストリームになるため、シーケンス番号およびタイムスタンプを、切り替え前のイベント１後映像１７１０の最終パケットから連続的に変化するように付け替えて送信する。ここで、受信側の監視端末Ｔｙが切り替わりポイントを認識する必要がある場合には、ＲＴＰパケットのＳＳＲＣを利用して認識を行うことが可能となる。また、イベント１映像とイベント２映像は、映像を復号するための情報であるＤＣＩは同一であるとした。切り替え後は同一イベントの映像配信になるので、実施の形態１で述べたと同様に行うことになる。

上記例では、特定されたイベントの蓄積映像に対するイベント前後の再生時間内に発生した別のイベントを関連付けるイベントとして説明したが、他の方法でイベントの関連付けを行ってもよい。例えば、同一イベント種別ＩＤを有するイベント同士、あるいはイベント種別ＩＤ毎に決められている付属データが同一であるイベント同士がある。後者に該当する例としては、ＩＤカードと暗証番号を用いる入退出管理システムがある。このケースでは、暗証番号を規定回誤ったことをイベント種別ＩＤとして表し、付属データとしてはその際に使用しているＩＤカードの個人ＩＤとする。もしイベント前後の再生時間内に同一のイベント種別ＩＤで、同一の個人ＩＤを有しているイベントが存在した場合には関連イベントとして抽出すればよい。これにより、複数の入り口で同一のＩＤカードにより不正な暗証番号を利用する不審人物の存在が効率的に確認可能となる。また、同一フロア、同一建物などのカメラレイアウト情報と関連づけてもよい。
また、上記例では特定のイベントに関連付けられたイベントが一つの場合について説明したが、関連付ける別のイベントが複数の場合でも同じように処理することは可能である。

以上のように、この実施の形態５によれば、映像蓄積配信装置１６は、関連付けたイベント同士の情報を管理しており、監視端末Ｔｒからの蓄積映像送信要求で指定された特定のイベントに関連付けられる一つ以上のイベントが存在した場合に、それぞれのイベントのイベントデータ、イベント前再生時間とイベント後再生時間に基づいて上記関連付けられたイベントの蓄積映像を配信するスケジュール情報を生成し、生成されたスケジュール情報に基づいて全ての関連付けられたイベントの蓄積映像をイベントの発生順に並べて切り替え、蓄積映像送信要求を送信した監視端末に対して配信するようにしたので、監視先で生じた事象に対する多角的な把握が容易となる。また、ユーザが一度の操作でそれらの連続映像を閲覧できるため、映像監視業務を効率化することができる。

この発明の実施の形態１による監視システムの全体構成を示すブロック図である。 この発明の実施の形態１に係るイベントに関連する映像を蓄積する際の動作を示すシーケンス図である。 この発明の実施の形態１に係るイベントに関連する蓄積映像を閲覧する際の動作順序を示すシーケンス図である。 この発明の実施の形態１に係るイベント発生装置が出すイベントデータ構成を示す説明図である。 この発明の実施の形態１に係る集信装置の機能構成を示すブロック図である。 この発明の実施の形態１に係る一次蓄積映像ＤＢの構成を示す説明図である。 この発明の実施の形態１に係る一次蓄積映像ＤＢに蓄積するファイルの蓄積形式を示す説明図である。 この発明の実施の形態１に係る映像蓄積配信装置の機能構成を示すブロック図である。 この発明の実施の形態１に係るイベント・映像対応ＤＢのデータ構成を示す説明図である。 この発明の実施の形態１に係るイベントデータＤＢのデータ構成を示す説明図である。 この発明の実施の形態１に係るイベントデータ発生通知のデータ構成を示す説明図である。 この発明の実施の形態１に係るイベント映像再生時間ＤＢのデータ構成を示す説明図である。 ＭＰＥＧ−４のＳＤＰの例を示す説明図である。 この発明の実施の形態１に係る蓄積映像ＤＢ内の映像管理テーブルの構成を示す説明図である。 この発明の実施の形態１に係る監視端末の機能構成を示すブロック図である。 この発明の実施の形態２による映像蓄積配信装置の機能構成を示すブロック図である。 この発明の実施の形態２に係るイベント映像再生時間ＤＢのデータ構成を示す説明図である。 この発明の実施の形態３に係る映像蓄積配信装置の機能構成を示すブロック図である。 この発明の実施の形態３に係るイベント・映像対応ＤＢのデータ構成を示す説明図である。 この発明の実施の形態４に係る映像蓄積配信装置の機能構成を示すブロック図である。 この発明の実施の形態５に係る映像蓄積配信装置の機能構成を示すブロック図である。 この発明の実施の形態５に係る配信スケジュール管理部のスケジュール情報生成方法について示す説明図である。 この発明の実施の形態５に係るスケジュール情報のデータ構成を示す説明図である。

符号の説明

１，１１，１３，１５，１６ 映像蓄積配信装置、２ 蓄積映像ＤＢ、３ 集信装置、４ 一次蓄積映像ＤＢ、５，８ ネットワーク、６ 監視センタ、８ カメラネットワーク、Ｃ１〜Ｃｎ 監視カメラ、Ｅ１〜Ｅｎ イベント発生装置、Ｔ１〜Ｔｍ 監視端末。

Claims (15)

1. 監視先でイベントの発生がない通常時において、監視先に設置した監視カメラで撮影した映像をイベント前映像として一次蓄積映像データベースに蓄積しておき、
   監視先でイベントが発生した場合において、当該イベントに対応する監視カメラのライブ映像を、イベント後映像としてイベント後再生時間を指定して蓄積映像データベースに蓄積し、
   前記ライブ映像の蓄積後で、発生履歴のあるイベントを指定して受信許可を与えた監視端末から蓄積映像送信要求が出された場合において、イベント前再生時間を指定することにより、前記一次蓄積映像データベースから前記指定イベントに対応するイベント前映像の前記イベント前再生時間分を取得し、取得した当該イベント前映像と前記蓄積映像データベースに蓄積されている前記指定イベントに対応するイベント後映像とを、最後に受信したイベント前映像のパケットの次に来るパケットをイベント後映像の配信開始パケットに切り替え、連続するストリームにして前記蓄積映像送信要求を出した監視端末に配信することを特徴とする監視システム。
2. 蓄積映像に対するイベント前再生時間および／もしくはイベント後再生時間を、イベントデータの種別毎に設定変更することを特徴とする請求項１から請求項３のうちのいずれか１項記載の監視システム。
3. 蓄積映像送信要求により送信開始時間が指定されている場合には、一次蓄積映像データベースに蓄積された前記送信開始時間近傍のイベント前映像をイントラフレームから取得し、この取得した前記送信開始時間近傍のイントラフレームで開始されるイベント前映像に続けて、蓄積映像データベースに蓄積された対応するイベント後映像を、前記蓄積映像送信要求を出した監視端末に対して配信することを特徴とする請求項１記載の監視システム。
4. 関連付けたイベント同士の情報を管理しており、監視端末からの蓄積映像送信要求で指定された特定のイベントに関連付けられる一つ以上のイベントが存在した場合に、それぞれのイベントのイベントデータ、イベント前再生時間とイベント後再生時間に基づいて関連付けられたイベントの蓄積映像を配信するスケジュール情報を生成し、生成されたスケジュール情報に基づいて全ての関連付けられたイベントの蓄積映像をイベントの発生順に並べて切り替え、蓄積映像送信要求を出した監視端末に対して配信することを特徴とする請求項１記載の監視システム。
5. 監視カメラの映像の一次蓄積およびライブ映像と一次蓄積映像の送信を行う少なくとも一組の監視先グループ装置と、当該監視先グループ装置からネットワークを介して送信されたライブ映像の再生と蓄積および蓄積映像の再生を行う監視センタ装置とからなる監視システムであって、
   前記監視先グループ装置は、
   監視先に設置され撮影した映像の符号化したストリームを送信する監視カメラと、
   前記監視カメラが設置された監視先に設置され、監視先毎の予め設定された条件に基づいてイベントが発生した際にイベント発生装置ＩＤ、イベントＩＤ、イベント発生時刻を含むイベントデータをそれぞれ生成して前記監視センタ装置に送信するイベント発生装置と、
   複数の映像のファイル化されたパケットデータを、個別に格納し管理する一次蓄積映像データベースと、
   イベント発生前における前記監視カメラで撮影した映像を、イベント前映像として前記一次蓄積映像データベースに蓄積し、イベント発生後に前記監視センタ装置から受信するライブ映像送信要求に基づいて当該発生イベントに対応する監視カメラからのライブ映像を前記監視センタ装置に再送信し、また、前記ライブ映像の再送信後において前記監視センタ装置から受信する蓄積映像送信要求に基づいて、該当イベントに対応する蓄積されたイベント前映像の指定されたイベント前再生時間分を前記監視センタ装置に配信する集信装置を備え、
   前記監視センタ装置は、
   イベント発生時に通知されたイベントデータに関連する情報を登録し、また、イベント発生後においてイベントを指定して蓄積映像送信要求を送信することにより受信した対応する蓄積映像を再生する少なくとも一つの監視端末と、
   前記集信装置から配信された監視カメラのイベント発生後のライブ映像を蓄積する蓄積映像データベースと、
   前記イベント発生装置からイベントデータを受信した場合に、当該イベントデータに関連する情報を前記監視端末のいずれかに対して通知すると共に、ライブ映像送信要求を生成して前記集信装置に送信することにより前記集信装置から配信されたイベント発生後の監視カメラのライブ映像の予め設定されたイベント後再生時間分を、イベント後映像として前記蓄積映像データベースに蓄積し、また、前記蓄積映像データベースへの映像蓄積後に前記監視端末のいずれかからイベントを指定した蓄積映像送信要求を受信した場合に、前記集信装置から前記一次蓄積映像データベースに蓄積された対応するイベント前映像の予め設定されたイベント前再生時間分を取得し、この取得したイベント前映像と前記蓄積映像データベースから読み出した対応するイベント後映像とを、前記集信装置から最後に受信したイベント前映像のパケットの次に来るパケットをイベント後映像の配信開始パケットに切り替え、連続するストリームにして前記蓄積映像送信要求を出した監視端末に配信する映像蓄積配信装置を備えたことを特徴とする監視システム。
6. 映像蓄積配信装置は、蓄積映像に対するイベント前再生時間および／もしくはイベント後再生時間を、イベントデータの種別毎に設定変更することを特徴とする請求項５記載の監視システム。
7. 映像蓄積配信装置は、ライブ映像送信要求の送信時に、発生イベントに対応する監視カメラに対してイントラフレーム要求メッセージを送信し、蓄積映像データベースに蓄積するイベント発生後のライブ映像の先頭画像を、前記イントラフレーム要求メッセージに従って前記監視カメラが出力するイントラフレームとするようにしたことを特徴とする請求項５記載の監視システム。
8. 集信装置は、蓄積映像送信要求で送信開始時間が指定されている場合には、一次蓄積映像データベースに蓄積された前記送信開始時間近傍のイベント前映像をイントラフレームから送信するようにし、
   映像蓄積配信装置は、受信した前記送信開始時間近傍のイントラフレームで開始されるイベント前映像に続けて蓄積映像データベースに蓄積された対応するイベント後映像を、前記蓄積映像送信要求を送信した監視端末に対して配信することを特徴とする請求項５記載の監視システム。
9. 映像蓄積配信装置は、関連付けたイベント同士の情報を管理しており、監視端末からの蓄積映像送信要求で指定された特定のイベントに関連付けられる一つ以上のイベントが存在した場合に、それぞれのイベントのイベントデータ、イベント前再生時間とイベント後再生時間に基づいて関連付けられたイベントの蓄積映像を配信するスケジュール情報を生成し、生成されたスケジュール情報に基づいて全ての関連付けられたイベントの蓄積映像をイベントの発生順に並べて切り替え、蓄積映像送信要求を送信した監視端末に対して配信することを特徴とする請求項５記載の監視システム。
10. 集信装置は、イベント発生前において、監視先に設置された監視カメラで撮影した映像を、イベント前映像として一次蓄積映像データベースに蓄積し、イベント発生後において、前記監視センタ装置内の映像蓄積配信装置から受信するライブ映像送信要求に基づいて当該発生イベントに対応する監視カメラからのライブ映像を前記監視センタ装置内の前記映像蓄積配信装置と受信許可された監視端末に再送信し、また、前記ライブ映像の再送信後において、前記映像蓄積配信装置から受信する蓄積映像送信要求に基づいて、該当イベントに対応する蓄積されたイベント前映像の指定されたイベント前再生時間分を前記映像蓄積配信装置に配信することを特徴とする請求項５記載の監視システム。
11. 監視カメラの映像の一次蓄積およびライブ映像と一次蓄積映像の送信を行う監視先グループ装置と、当該監視先グループ装置からネットワークを介して送信されたライブ映像の再生と蓄積および蓄積映像の再生を行う監視センタ装置とからなる監視システムの監視センタ装置に適用される映像蓄積配信装置であって、
    監視カメラが設置された各監視先に設置されたイベント発生装置からイベント発生装置ＩＤ、イベントＩＤ、イベント発生時刻を含むイベントデータを受信した場合に、当該イベントデータに関する情報を監視端末に与えると共に、ライブ映像送信要求を生成して前記監視先グループ装置の集信装置に送信することにより前記集信装置から配信されたイベント発生後の監視カメラのライブ映像の予め設定されたイベント後再生時間分を、イベント後映像として前記監視センタ装置内の蓄積映像データベースに蓄積し、また、前記蓄積映像データベースへの映像蓄積後に前記監視端末からイベントを指定した蓄積映像送信要求を受信した場合に、前記集信装置から前記監視先グループ装置の一次蓄積映像データベースに蓄積された対応するイベント前映像の予め設定されたイベント前再生時間分を取得し、この取得したイベント前映像と前記蓄積映像データベースから読み出した対応するイベント後映像とを、前記集信装置から最後に受信したイベント前映像のパケットの次に来るパケットをイベント後映像の配信開始パケットに切り替え、連続するストリームにして前記蓄積映像送信要求を出した監視端末に配信することを特徴とする映像蓄積配信装置。
12. 蓄積映像に対するイベント前再生時間および／もしくはイベント後再生時間を、イベントデータの種別毎に設定変更することを特徴とする請求項１１記載の映像蓄積配信装置。
13. ライブ映像送信要求の送信時に、発生イベントに対応する監視カメラに対してイントラフレーム要求メッセージを送信し、蓄積映像データベースに蓄積するイベント発生後のライブ映像の先頭画像を、前記イントラフレーム要求メッセージに従って前記監視カメラが出力するイントラフレームとするようにしたことを特徴とする請求項１１記載の映像蓄積配信装置。
14. 蓄積映像送信要求で送信開始時間としてイベント発生時刻を指定し、集信装置からイベント発生時刻近傍のイベント前映像をイントラフレームから受信できる場合において、受信したイントラフレームで開始されるイベント発生時刻近傍のイベント前映像に続けて蓄積映像データベースに蓄積された対応するイベント後映像を、前記蓄積映像送信要求を送信した監視端末に配信することを特徴とする請求項１１記載の映像蓄積配信装置。
15. 関連付けたイベント同士の情報を管理しており、監視端末からの蓄積映像送信要求で指定された特定のイベントに関連付けられる一つ以上のイベントが存在した場合に、それぞれのイベントのイベントデータ、イベント前再生時間とイベント後再生時間に基づいて前記関連付けられたイベントの蓄積映像を配信するスケジュール情報を生成し、生成されたスケジュール情報に基づいて全ての関連付けられたイベントの蓄積映像をイベントの発生順に並べて切り替え、蓄積映像送信要求を送信した監視端末に対して配信することを特徴とする請求項１１記載の映像蓄積配信装置。

Images