JP4315827B2 - 画像表示方法及び画像表示装置並びに画像表示プログラム - Google Patents

Description

本発明は、例えば、画像再生方法に関し、特に、例えば、多様な形態で記録されている画像データを効果的に再生する画像再生方法に関する。

ネットワーク通信の普及により、カメラで撮影された画像（動画像、静止画像、静止画像が時系列に連続した間欠的な準動画像等）を、遠隔地のユーザがパーソナルコンピュータやモバイルツール等のクライアント装置で画面表示することができるシステムが実施されている。

このようなシステムは、種々な用途に利用されており、例えば、画像により侵入者や管理対象物の異常を監視する監視システムとして利用されている（例えば、特許文献１）。
特開２００３−２７４３８３号公報

ところで、クライアント装置への画像データの配信は、カメラで撮影した画像データをサーバに蓄積し、当該サーバからクライアント装置へ配信する形態が一般的であるが、上記のようなシステムの普及に伴い、今後、ユーザの利便性向上のために、サーバへ蓄積する画像データの記録形態についても多様化することが想定される。例えば、ネットワークの通信負荷やサーバの記憶容量等を考慮し、同一のカメラの映像であっても、時間帯や、特定の異常が発生した場合等に応じて、画像データの品質（解像度、圧縮率、フレームレート（ｆｐｓ：ｆｒａｍｅ ｐｅｒ ｓｅｃｏｎｄ）等）を変えたりする場合もありえる。しかしながら、従来のシステムは、多用な形態で記録されている画像データを効果的に再生するに十分なシステムではなかった。

本発明は、このような従来の事情に鑑み為されたもので、例えば、多用な形態で記録されている画像データを効果的に再生することができる画像再生方法を提供することを目的とする。

本発明の画像再生方法は、１つの撮像装置により得られる動画像を異なるフレームレートにより複数系統で記録し、該記録された動画像を再生する画像再生方法であって、前記記録された動画像は、複数の静止画像データから構成され、前記記録された動画像の再生の基準となる時間軸に従い、前記複数系統のうちのいずれか１つの系統の動画像を構成する前記静止画像データを再生することように構成される。

ここで、「複数系統で記録」とは、例えば、１つの撮像装置により得られた映像を異なる映像条件により１つの記録装置の複数チャネル或いは異なる記録装置にそれぞれ記録することや、それに準じた状況による記録等のことをいう。ここで、映像条件とは、例えば、上記したフレームレートの他、解像度や、圧縮率等のことをいう。

なお、本明細書では、「画像」という語を用いて説明を行うが、例えば、「映像」といった語についても、同様な用語であり、本発明に包含される。また、本明細書では、「再生」という語を用いて説明を行うが、例えば、「表示」や「閲覧」といった語についても、同様な用語であり、本発明に包含される。また、本明細書では、「記録」という語を用いて説明を行うが、例えば、「記憶」や「録画」といった語についても、同様な用語であり、本発明に包含される。

また、本発明の画像再生方法において、前記複数系統のうち少なくとも２つの系統の動画像を構成する前記静止画像データがそれぞれ同時刻に生成された画像データである場合は、前記フレームレートの高い系統の動画像を構成する前記静止画像データを再生するように構成される。

ここで、「同時刻」であるか否かは、例えば、画像データに時刻情報を付与する際の態様により発生する誤差分の時間等を考慮して判断されても良い。
また、本発明の画像再生方法において、前記フレームレートの高い系統の動画像を構成する前記静止画像データが連続して存在する期間においては、前記フレームレートの高い系統の動画像を構成する前記静止画像データを再生するように構成される。

また、本発明の画像再生方法は、１つの撮像装置により得られる動画像を異なるフレームレート或いは異なる圧縮率或いは異なる解像度の少なくともいずれか１つにより複数系統で記録し、該記録された動画像を再生する画像再生方法であって、前記記録された動画像は、複数の静止画像データから構成され、前記記録された動画像の再生の基準となる時間軸に従い、前記複数系統のうちのいずれか１つの系統の動画像を構成する前記静止画像データを再生することように構成される。

また、本発明の画像再生方法において、前記複数系統のうち少なくとも２つの系統の動画像を構成する前記静止画像データがそれぞれ同時刻に生成された画像データである場合は、前記フレームレートの高い或いは前記圧縮率の低い或いは前記解像度の高い系統の動画像を構成する前記静止画像データを再生するように構成される。

また、本発明の画像再生方法において、前記フレームレートの高い系統或いは前記圧縮率の低い或いは前記解像度の高い系統の動画像を構成する前記静止画像データが連続して存在する期間においては、前記フレームレートの高い系統或いは前記圧縮率の低い或いは前記解像度の高い系統の動画像を構成する前記静止画像データを再生するように構成される。

以上説明したように、本発明に係る画像再生方法によると、例えば、多用な形態で記録されている画像データを効果的に再生することができる。

本発明に係る一実施例を図面を参照して説明する。
以下、本発明の実施例について、図面を参照して説明する。

図１は、本発明による画像再生方法が適用される画像蓄積配信システムの全体構成の１例を示す。
ここに示した画像蓄積配信システムは、画像（音声を含む場合もある）データを蓄積するための記録装置（以下、ディスク装置と言う）３を備えた画像蓄積配信サーバ１と、ネットワーク４を介して上記画像蓄積配信サーバ１に接続された複数のＷｅｂカメラ５（５−１〜５−ｎ）および複数のクライアント端末６（６−１〜６−ｍ）からなる。本発明の画像蓄積配信システムにおいては、１のＷｅｂカメラ５の画像データを、例えば、記録モードに応じて複数のチャネル（本実施例では２つのチャネル）に分けて記録する構成としているため、Ｗｅｂカメラ５−１〜５−ｎは、それぞれ固有のチャネル番号を複数有している。例えば、５−１はチャネル１（ｃｈ１）用、及び、チャネル２（ｃｈ２）用、‥‥‥、５−ｎはチャネルｐ−１（ｃｈｐ−１）用、及び、チャネルｐ（ｃｈｐ）のＷｅｂカメラとする。ここで、ｎ、ｍ、ｐは自然数であり、ｎ＝ｍ＝ｐである必要はなく、その組み合わせは任意に選択できる。

Ｗｅｂカメラ５−１〜５−ｎによる撮影映像の各フレームの画像データは、例えば、ＪＰＥＧ等の画像圧縮方式で圧縮され、ＩＰパケット形式で画像蓄積配信サーバ１に送信される。この場合、圧縮された画像データは、フレーム毎にデータ量の異なる可変長データとなる。画像蓄積配信サーバ１は、Ｗｅｂカメラ５−１〜５−ｎからネットワークを介して受信した各パケットから圧縮画像データ（以下、単に画像データと言う）を抽出し、ディスク装置３に予め確保されたチャネル別の記録領域３０（３０−１〜３０−ｐ）に記録する。したがって、各記憶領域３０には1台のＷｅｂカメラ５の画像が時系列に格納されることとなる。また、記録の際、各画像データには制御のためにフレーム毎にフレーム番号が割り振られる。なお、上記画像蓄積配信システムにおいては、画像蓄積配信サーバ１とディスク装置３等の機能が一体化された装置を用いることも可能である。

各クライアント端末６は、画像蓄積配信サーバ１に対して、チャネル番号とフレーム番号を指定して画像データの配信を要求する。画像蓄積配信サーバ１は、クライアント端末からの要求に応じて、ディスク装置３から読み出した指定チャネル番号／フレーム番号の画像データをＩＰパケット形式で要求元のクライアント端末６に配信サービスする。これにより、各クライアント端末６は、ディスク装置３に記録されている画像データの再生を行うことができる。本発明の画像再生方法は、クライアント端末６が画像蓄積配信サーバ１に対して画像データの配信要求を行い、クライアント端末６のモニタに画像データを再生する際に適用される。

ここで、上記画像蓄積配信システムに実装されている記録モードとしては、そのトリガ要因の違いから、スケジュール録画、手動録画、アラーム録画の３種類がある。スケジュール録画とは、あらかじめユーザにより設定された記録のタイムテーブルに従ってＷｅｂカメラ５から画像データの記録を行うもの、手動録画とは、クライアント端末６のモニタにて画像監視を行っているユーザがクライアント端末６のＧＵＩ操作(録画ボタン押下等)により任意のタイミングでＷｅｂカメラ５から画像データの記録を行うもの、アラーム録画とは、Ｗｅｂカメラ５へのアラーム信号の入力(外部センサからの接点入力、画像認識処理による侵入者検知等)によりＷｅｂカメラ５から画像データの記録を行うものである。なお、これら３つの記録モード以外の記録モードが用いられてもよいことは言うまでもない。また、以下では、スケジュール録画と手動録画とを通常録画と称し、通常録画により記録が行われるディスク装置３の記録領域３０のことを通常チャネル（通常ｃｈ）と称する。また、アラーム録画により記録が行われるディスク装置３の記録領域３０のことをアラームチャネル（アラームｃｈ）と称する。

図２は、本発明の一実施例に係るディスク装置の記録内容を説明するための図である。
図２に示すように、例えば、ディスク装置３の記録容量のコスト制約から、通常録画を行う場合には低フレームレートで通常ｃｈへ画像データの記録を行い、アラーム録画を行う場合にはアラームが発生した時のみ高フレームレートでアラームｃｈへ画像データの記録を行うような態様が用いられる。なお、図２のアラームｃｈに示したように、アラーム録画については、アラーム発生から時系列を遡ってアラーム発生時刻前の所定時間の画像（プリアラーム画像）の記録も行うようにしている。なお、ここでは、通常録画とアラーム録画とでは、記録される画像データのフレームレートのみが異なる場合を例に説明するが、更に画像の圧縮率や解像度を変える等、各記録モードの記録内容は実際のシステムの設定状況に応じて任意に設定することが可能である。一例として、アラーム録画は、通常録画に比べて、高フレームレート、低圧縮率、高解像度で画像データの記録を行うようにすることが可能である。

図３は、本発明の一実施例に係るディスク装置への記録動作を説明するための図である。
図３を用いて、Ｗｅｂカメラ５の画像データを通常録画、及び、アラーム録画によりディスク装置３の記憶領域３０−１（ｃｈ１）、３０−２（ｃｈ２）に記録する際の、Ｗｅｂカメラ５及び画像蓄積配信サーバ１の構成を説明する。なお、ここでは、簡単化のため、Ｗｅｂカメラ５のうちの１台のＷｅｂカメラ５−１を用いて説明を行う。

Ｗｅｂカメラ５−１は、撮影部５０、エンコーダ部５１、送信映像メモリ５２、送信映像メモリ（リングバッファ）５３、ネットワークインタフェース（Ｉ／Ｆ）５４から構成されている。

画像蓄積配信サーバ１は、ネットワークインタフェース（Ｉ／Ｆ）１０、受信映像メモリ１１（１１−１〜１１−２）、ディスクインタフェース（Ｉ／Ｆ）１２から構成されている。ここで、Ｗｅｂカメラ５−１と画像蓄積配信サーバ１とはネットワークＩ／Ｆ５４、１０を介して接続され、画像蓄積配信サーバ１とディスク装置３とはディスクＩ／Ｆ１２を介して接続されている。

Ｗｅｂカメラ５−１の撮影部５０は、所定の視野範囲を撮像する。撮像された映像信号は、例えば、３０ｆｐｓというフレームレート、即ち、１秒間に３０フレームという時間間隔でエンコーダ部５１に入力される。エンコーダ部５１においては、映像信号を、例えば、ＪＰＥＧ形式等で圧縮符号化し、画像データを生成する。

エンコーダ部５１で符号化された画像データは、例えば、３０ｆｐｓで送信映像メモリ５２に入力され、送信映像メモリ５２において一時的に記憶される。送信映像メモリ５２は、エンコーダ部５１より新たな１フレームの画像データが入力されると、それまで記憶していた画像データを破棄し、新たな画像データを記憶するような構成が用いられる。画像蓄積配信サーバ１のＣＰＵ（不図示）は、通常録画を行う際は、予め画像蓄積配信サーバ１内のデータメモリ（不図示）に設定されている通常録画用レート（フレームレート）に従い、Ｗｅｂカメラ５−１に対して画像データの配信要求を送信する。Ｗｅｂカメラ５−１は、画像データの配信要求を受信すると、その時点において送信映像メモリ５２に記憶されている１フレームの画像データを画像蓄積配信サーバ１へ送信する。通常録画の場合、画像蓄積配信サーバ１は、クライアント端末６−１等のユーザにより設定された録画開始から録画終了に至るまで、Ｗｅｂカメラ５−１に対して画像データの配信要求を繰り返す。画像蓄積配信サーバ１は、受信した画像データを受信映像メモリ１１−１に一時的に記憶し、その後、画像データをディスクＩ／Ｆ１２を介してＷｅｂカメラ５−１の通常ｃｈとして使用されるディスク装置３の記憶領域３０−１（ｃｈ１）に記録する。なお、本実施形態では、要求がある毎に画像データを１フレームずつネットワーク４を介して通信する方法を採用しているが、要求がある毎に画像データを複数フレーム分（あるいは１ファイル分）通信するようにしてもよい。また、本実施形態では、Ｗｅｂカメラ５から出力される画像データは間欠的に時系列に連続した準動画像であるが、他の形式が用いられてもよい。また、本実施形態のように、画像蓄積配信サーバ１側からのアクセス（配信要求）を受けて、Ｗｅｂカメラ５が画像データの配信を行うｐｕｌｌ型のシステム構成の他、サーバ１側からのアクセスなしに、例えば、所定のタイミングでＷｅｂカメラ５が画像データの配信を行うｐｕｓｈ型のシステム構成が用いられても良い。

また、エンコーダ部５１で符号化された画像データは、予めＷｅｂカメラ５−１内のデータメモリ（不図示）に設定されているアラーム録画用レート（フレームレート）に従って、送信映像メモリ５３に入力され、送信映像メモリ５３において一時的に記憶される。送信映像メモリ５３は、送信映像メモリ５２の構成とは異なり、例えば、１００フレーム分といった複数フレームの画像データを保持できるような構成となっている。これは、上述した通り、アラーム録画においては、アラームが発生する前の所定期間における画像データ（プリアラーム画像）の記録を行う必要があるためである。Ｗｅｂカメラ５−１に接続されている外部センサ（不図示）が作動しＷｅｂカメラ５−１に対してアラーム信号が入力されると、Ｗｅｂカメラ５−１から画像蓄積配信サーバ１に対してアラーム発生通知が送信される。アラーム発生通知を受信した画像蓄積配信サーバ１のＣＰＵは、アラーム録画を開始する。アラーム録画を行う際は、アラーム発生の所定時間前の時刻を指定してＷｅｂカメラ５−１に対して画像データの配信要求を送信する。Ｗｅｂカメラ５−１は、送信映像メモリ５３から当該指定時刻からの画像データを画像蓄積配信サーバ１へ送信する。画像蓄積配信サーバ１は、受信した画像データを受信映像メモリ１１−２に一時的に記憶し、その後、画像データをディスクＩ／Ｆ１２を介してＷｅｂカメラ５−１のアラームｃｈとして使用されるディスク装置３の記憶領域３０−２（ｃｈ２）に記録する。

なお、Ｗｅｂカメラ５−１から画像蓄積配信サーバ１への画像データの送信は、発生したアラームが終了するまで継続する。すなわち、外部センサの作動が停止しＷｅｂカメラ５−１から画像蓄積配信サーバ１に対してアラーム終了通知が送信されると、アラーム終了通知を受信した画像蓄積配信サーバ１のＣＰＵは、画像データの配信要求を停止する。ここで、送信映像メモリ５３に記憶されている画像データは、Ｗｅｂカメラ５−１のＣＰＵ（不図示）がアラーム録画用レートに従いエンコーダ部５１より読み出して送信映像メモリ５３に記憶したものであるため、通常録画の場合とは異なり、アラーム録画の場合は、画像蓄積配信サーバ１のＣＰＵはＷｅｂカメラ５−１に対して画像データの配信要求を行う際にフレームレートに関する制御は行わず、アラーム発生からアラーム終了まで（プリアラーム画像も含む）の時間帯における送信映像メモリ５３内の画像データすべてについて配信要求を行う。なお、上述したように、画像蓄積配信サーバ１に対してアラーム終了通知が送信され画像データの配信要求を停止するという態様の他、例えば、画像蓄積配信サーバ１がアラーム発生通知を受信した時点から予め設定された所定期間後に画像データの配信要求を停止する（ポストアラーム録画）といった態様が用いられてもよい。

ここで、ディスク装置３の記憶領域３０に記録される画像データには、例えば、当該フレームの時刻情報（以下、タイムスタンプと称する。）、各ｃｈにおける撮影順序を示すフレーム番号、フレームレート情報（通常録画用レート或いはアラーム録画用レート）等が付加情報として付されている。ここで、タイムスタンプは、Ｗｅｂカメラ５のエンコ−ダ部５１により画像データが生成される時刻や、画像蓄積配信サーバ１がＷｅｂカメラ５より画像データを受信した時刻等を用いて生成することができる。例えば、画像蓄積配信サーバ１がＷｅｂカメラ５より画像データを受信した時刻を用いてタイムスタンプを生成する場合、一例として、通常録画の場合は、画像データの受信時刻を当該画像データのタイムスタンプとする。一方、アラーム録画の場合は、送信映像メモリ５３に所定期間画像データが保持される時間があるため、一例として、Ｗｅｂカメラ５がネットワークＩ／Ｆ５４より画像データを配信する時刻とエンコ−ダ部５１により画像データが生成された時刻との差分を求め、求めた差分を画像蓄積配信サ―バ１における画像データの受信時刻から減算した時刻を当該画像データのタイムスタンプとする。

なお、本実施形態では、通常録画用レートは画像蓄積配信サーバ１側に設定し、アラーム録画用レートはＷｅｂカメラ５側に設定しているが、これらの情報の設定先は実際のシステムの構成に応じて任意に選定することが可能である。例えば、図３の送信映像メモリ５３のような複数フレーム分の画像データを一時的に保持するようなメモリをＷｅｂカメラ５側に設けるのではなく、画像蓄積配信サーバ１側に設けるような構成が用いられる場合であれば、アラーム録画用レートについても画像認識サーバ１側に設定すればよい。

次に、本発明の画像再生方法について説明する。
ディスク装置３に記録されている所定のＷｅｂカメラ５の画像データをクライアント端末６のモニタに再生する際の画像再生方法としては、「通常ｃｈのみ再生」、「アラームｃｈのみ再生」、「シームレス再生（詳しくは、後述する）」の３つの画像再生方法が存在する。例えば、クライアント端末６のモニタの表示画面上にこれらの画像再生方法のいずれかを選択するためのＧＵＩが表示され、ユーザはマウス等の入力機器のボタンを押下することで、いずれかの画像再生方法を選択できる。以下、これら３つの画像再生方法について詳細に説明する。

図４は、「通常ｃｈのみ再生」の動作を説明するための図である。図４において、水平方向は時間方向を表し、各ｃｈの録画期間が長方形で表されている。また、太線の矢印で示される再生される部分となる。なお、後述する図５、図６についても同様である。ここで、図４に示す通り、「通常ｃｈのみ再生」を行う場合は、所定の通常ｃｈ、例えば、ディスク装置３の記憶領域３０−１（Ｗｅｂカメラ５−１の通常ｃｈ）に記録されている画像データのみが時系列順に読み出されてクライアント端末６のモニタに再生される。

図５は、「アラームｃｈのみ再生」の動作を説明するための図である。図５に示す通り、「アラームｃｈのみ再生」を行う場合は、所定のアラームｃｈ、例えば、ディスク装置３の記憶領域３０−２（Ｗｅｂカメラ５−１のアラームｃｈ）に記録されている画像データのみが時系列順に読み出されてクライアント端末６のモニタに再生される。なお、図５の点線の矢印で示したように、例えば、画像データが存在しない期間については再生がスキップされ、次の期間における映像の再生が続けられる。例えば、Ｗｅｂカメラ５により生成された画像データをディスク装置３の記憶領域３０に記録する際等に、各画像データに対して撮影順序を示すフレーム番号を付すような構成を用いる場合は、クライアント端末６は画像蓄積配信サーバ１に対してフレーム番号順に画像データの配信要求を行うことで、図４、及び、図５で示した画像再生方法を実現することが可能である。

図６は、本発明の一実施例に係る「シームレス再生」の動作を説明するための図である。ここで、「シームレス再生」とは、図６に示すように、時系列に沿って映像の再生を行う際、例えば、ある時刻において、アラームｃｈに画像データが存在する場合には、通常ｃｈの画像データの有無に関わらずアラームｃｈの画像データを再生し、アラームｃｈに画像データが存在せず、通常ｃｈにのみ記画像データが存在する場合には、通常ｃｈの画像データを再生するといったアルゴリズムによって実施される画像再生方法のことをいう。両ｃｈとも画像データが存在しない場合には、例えば、次にどちらかのｃｈに画像データが存在する時刻までスキップして画像データの再生を続ける。ここで、アラームｃｈの画像データの再生を優先する理由は、上述したように、アラーム録画においては高フレームレートで画像データを記録するようにしたため、図６に示したように、アラームｃｈと通常ｃｈとのどちらも画像データが存在する区間については、アラームｃｈの画像データを再生した方がより詳細に内容の確認を行うことができるためである。なお、実際のシステムにおいては、アラーム録画、及び、通常録画を行う際のフレームレート、画像の解像度や圧縮率などは任意に設定することができるため、同時刻にどちらのｃｈにも画像データが存在する区間について、どのｃｈの画像データの再生を優先するかは、実際のシステムの設定状況に応じて任意に設定することが可能である。なお、後述するように各時刻において各ｃｈに画像データが存在するかの判定は、例えば、画像データの再生開始時に生成する再生基準時刻と、各ｃｈから取出した画像データに付与されたタイムスタンプの比較により行う。ここで、再生基準時刻とは、例えば、再生の基準となる時間軸を意味する。

図７は本発明の一実施例に係る画像再生処理（シームレス再生）７００の基本的な動作を説明するフローチャートである。
図７を用いて、クライアント端末６が実行する画像再生処理（シームレス再生）の流れの一例を説明する。

画像再生処理７００では、まず、現在のシステム時刻（現在時刻）を制御時刻として、クライアント端末１が備えるデータメモリ（不図示）に記憶する（ステップ７０１）。
次に、現在クライアント端末６のモニタに表示している画像データのタイムスタンプを再生基準時刻としてデータメモリに記憶する（ステップ７０２）。このステップ７０２の処理は、画像データの再生開始時刻を設定するための処理であるため、現在クライアント端末６のモニタに表示されている画像データのタイムスタンプを再生開始時刻とする他、例えば、クライアント端末６のユーザに再生開始時刻を指定させる等、種々な態様を用いることができる。

次に、クライアント端末６が現在、画像蓄積配信サーバ１を介してディスク装置３のアラームｃｈ或いは通常ｃｈの画像データを取得している最中であるか否かが判定される（ステップ７０３）。後述するステップ７０９において、クライアント端末６は画像蓄積配信サーバ１に対して所定の画像データの配信要求を行うが、クライアント端末６がその画像データの取得を終えるまでは、次のステップへは分岐しない（ステップ７０３でＹｅｓと判定される）。クライアント端末６が現在、画像データの取得中ではない場合は、次のステップ７０４へ分岐する（ステップ７０３でＮｏと判定される）。

次に、データメモリに記憶されている制御時刻と現在のシステム時刻の差分を算出し、算出された時間を「ディレイ時間」としてデータメモリに記憶する（ステップ７０４）。なお、ディレイ時間を求めた後、現在のシステム時刻を新たな制御時刻としてデータメモリに記憶し、制御時刻の更新を行う。従って、このディレイ時間とは、図７のステップ７０４の処理を終えた後、次にステップ７０４の処理に戻ってくるまでに要した時間を表わすこととなる。

次に、データメモリに記憶されている再生基準時刻にステップ７０４で算出したディレイ時間を加算し、再生基準時刻の更新を行う（ステップ７０５）。ディレイ時間を用いて再生基準時刻を更新するこのステップ７０５の処理と、後述するステップ７０８の処理とにより、クライアント端末６における画像データの再生タイミングを実際の時間経過に合わせることができる。

次に、クライアント端末６が備えるアラームｃｈ用の再生画像メモリと、通常ｃｈ用の再生画像メモリから最新取得画像のフレーム番号及びタイムスタンプを取得する（ステップ７０６）。ここで、再生画像メモリについて説明する。図８は、クライアント端末６が備える再生画像メモリの一構成例を示す図である。再生画像メモリは、通常ｃｈ用の再生画像メモリ８１と、アラームｃｈ用の再生画像メモリ８２とからなり、それぞれのメモリは、前回取得画像記憶領域と、最新取得画像記憶領域という２フレーム分の画像データを一時的に保持する領域を有している。図７に示す画像再生処理を行う際、画像蓄積配信サーバ１を介してディスク装置３のアラームｃｈに記録されている画像データを受信したクライアント端末６は、当該画像データをアラームｃｈ用の再生画像メモリ８２の最新取得画像記憶領域に記憶する。通常ｃｈについても同様である。なお、クライアント端末６は、後述するステップ７０９において、再生画像メモリの更新を行うため、１つ前に取得した画像データについては、前回取得画像記憶領域に記憶されることとなる。

次に、ステップ７０６で取得したアラームｃｈ用の再生画像メモリ８２の最新取得画像のタイムスタンプと、通常ｃｈ用の再生画像メモリ８１の最新取得画像のタイムスタンプをそれぞれ再生基準時刻と比較する（ステップ７０７）。アラームｃｈ或いは通常ｃｈの最新取得画像のタイムスタンプの少なくともいずれか一方が再生基準時刻以前（以下）の時刻を示している場合は、ステップ７０８に分岐する。一方、どちらの最新取得画像のタイムスタンプも再生基準時刻より新しい（大きい）時刻を示している場合は、ステップ７１１に分岐する。

ステップ７０７でＹｅｓと判定された場合、ステップ７０７において最新取得画像が再生基準時刻以下のタイムスタンプを有していると判定されたｃｈについて、次に取得すべき画像データのフレーム番号を算出する（ステップ７０８）。なお、アラームｃｈと通常ｃｈのどちらのｃｈについても最新取得画像のタイムスタンプが再生基準時刻以下であると判定される場合には、両方のｃｈについて、次に取得すべき画像データのフレーム番号の算出を行う。

ここで、フレーム番号の算出は、例えば、ステップ７０４で得られたディレイ時間を用いて行われる。ディスク装置３の各ｃｈに記録されている画像データにはそれぞれ時系列順にフレーム番号が付されているような構成であれば、例えば、ディレイ時間が小さい場合には、次に取得する画像データは現在、クライアント端末６が保持している最新取得画像データの次フレームの画像データとする、即ち、次に取得する画像データのフレーム番号は、ステップ７０６で取得したフレーム番号に１を加えた番号とする。一方、例えば、ディレイ時間が大きい場合には、次に取得する画像データは現在、クライアント端末６が保持している最新取得画像データの３フレーム後の画像データとする、即ち、次に取得する画像データのフレーム番号は、ステップ７０６で取得したフレーム番号に３を加えた番号とする。より具体的には、例えば、ディスク装置３のあるｃｈに記録されている画像データが３０ｆｐｓである場合、３３ｍｓｅｃ間隔でフレーム番号が１増えることになるため、ステップ７０４で得られたディレイ時間が１００ｍｓｅｃである場合には、ディレイ時間（１００ｍｓｅｃ）をフレーム間隔（３３ｍｓｅｃ）で割り、その商である３という値を現在、クライアント端末６が保持している最新取得画像データのフレーム番号に加えて、その番号を次にクライアント端末６が画像蓄積配信サーバ１に対して配信要求を行う画像データのフレーム番号とする。ここで、上記のように、フレーム番号の算出のためのフレームレート情報（上記の例ではフレーム間隔３３ｍｓｅｃ）には、例えば、再生画像メモリの最新取得画像データが付加情報として保持しているフレームレート情報を用いることができる。

次に、クライアント端末６は画像蓄積配信サーバ１に対して、ステップ７０８で算出したフレーム番号の画像データの配信要求を行う（ステップ７０９）。ここで、ステップ７０７で再生基準時刻以下と判定された最新取得画像データがアラームｃｈのものであれば、このステップ７０９ではクライアント端末６はアラームｃｈの画像データの配信要求を行い、再生基準時刻以下と判定された最新取得画像データが通常ｃｈのものであれば、このステップ７０９ではクライアント端末６はアラームｃｈの画像データの配信要求を行うことになる。また、再生基準時刻以下と判定された最新取得画像データがその両者である場合には、このステップ７０９ではクライアント端末６はアラームｃｈ及び通常ｃｈの両方に対して、それぞれステップ７０８で算出したフレーム番号の画像データの配信要求を行う。なお、クライアント端末６は、画像蓄積配信サーバ１に対して新たな画像データの配信要求を行う際、当該配信要求を行うｃｈについて再生画像メモリの更新を行う。例えば、ステップ７０９でアラームｃｈの新たな画像データの配信要求を行う場合には、その前にアラームｃｈ用の再生画像メモリ８２の最新取得画像記憶領域に記憶されていた画像データを前回取得画像記憶領域に記憶する。そして、ステップ７０９で新たに配信要求を行った画像データについては、画像蓄積配信サーバ１より受信した後、アラームｃｈ用の再生画像メモリ８２の最新取得画像記憶領域に記憶する。

次に、クライアント端末６は、再生画像メモリ８１、８２よりモニタに再生する画像データを選択し、当該画像データをモニタに出力する（ステップ７１０）。なお、ステップ７１０の詳細については、図９を用いて後述する。また、本例においては、ステップ７１０の再生画像選択処理を図７に示したフローチャートの中の１つの処理として記載しているが、例えば、画像データをモニタに描画する処理に要する時間を考慮して再生画像選択処理を独立に実行するようにしてもよい。

次に、ステップ７０７でクライアント端末６のいずれのｃｈの最新取得画像のタイムスタンプも再生基準時刻より新しいと判定される場合、新たな画像データの配信要求等（ステップ７０８等の処理）は行わず、アラームｃｈ用及び通常ｃｈ用の再生画像メモリ８１、８２の最新取得画像の内、古い（過去の）時刻を示すタイムスタンプをスキップ判定時刻としてデータメモリに記憶する（ステップ７１１）。

次に、ステップ７１１で設定したスキップ判定時刻と再生基準時刻との差分が３秒以上あるかないかを判定する（ステップ７１２）。差分が３秒以上ある場合には、ステップ７１３に分岐し、差分が３秒以上ない場合には、ステップ７１３の処理は行わず、ステップ７１４に分岐する。

ステップ７１２でＹｅｓと判定された場合、スキップ判定時刻を新たな再生基準時刻としてデータメモリに記憶する（ステップ７１３）。なお、上記３秒は再生基準時刻と、次に再生されるべき画像データのタイムスタンプとの差分から再生基準時刻を所定時刻先へスキップさせるか否かを見定める基準値の一例であり、当該基準値は、実際のシステムの設定状況に応じて任意に設定すればよい。この基準値を適切な値に設定することで、例えば、ディスク装置３のｃｈに画像データが存在しない時間帯をスキップして画像データの再生を行うことができる。なお、スキップ判定時刻を用いて再生基準時刻を更新した後、現在のシステム時刻を新たな制御時刻としてデータメモリに記憶し、制御時刻の更新を行うようにしてもよい。

次に、例えば、クライアント端末６のユーザより画像データの再生停止指示があったか否かを判定し、再生停止指示があった場合には画像再生処理を終了し、再生停止指示がない場合にはステップ７０３に分岐する（ステップ７１４）。

ここで、図７に示したステップ７１０の処理の一例を図９を用いて詳細に説明する。
再生画像選択処理（ステップ７１０）では、まず、通常ｃｈ用の再生画像メモリ８１の前回取得画像のタイムスタンプと、アラームｃｈ用の再生画像メモリ８２の前回取得画像のタイムスタンプとの比較を行う（ステップ９０１）。比較の結果、アラームｃｈ用の再生画像メモリ８２の前回取得画像のタイムスタンプの方が新しいと判定される場合は、ステップ９０２に分岐する。同様に、アラームｃｈ用の再生画像メモリ８２の前回取得画像のタイムスタンプと、通常ｃｈ用の再生画像メモリ８１の前回取得画像のタイムスタンプとが同時刻であると判定される場合も、ステップ９０２に分岐する。一方、比較の結果、通常ｃｈ用の再生画像メモリ８１の前回取得画像のタイムスタンプの方が新しいと判定される場合は、ステップ９０３に分岐する。

ステップ９０１でＹｅｓと判定された場合は、アラームｃｈ用の再生画像メモリ８２より前回取得画像を読み出し、モニタへ出力し画像データの再生を行う（ステップ９０２）。本例では、ステップ７１０を行う際に再生画像メモリ８１、８２の前回取得画像記憶領域に記憶されている画像データのタイムスタンプは、再生基準時刻よりも古い（過去の）時刻となるように構成されるため、アラームｃｈと通常ｃｈの前回取得画像の内、タイムスタンプが新しい方の画像データは、再生基準時刻により近い時刻の画像データということになる。また、アラームｃｈ用の再生画像メモリ８２の前回取得画像のタイムスタンプと、通常ｃｈ用の再生画像メモリ８１の前回取得画像のタイムスタンプとが同時刻であると判定される場合にもステップ９０２に分岐するようにしたのは、図６を用いて上述したように、アラームｃｈと通常ｃｈに同時刻の画像データが存在する場合には、アラームｃｈの画像データの再生を行うようにしたためである。

ステップ９０１でＮｏと判定された場合は、アラームｃｈ用の再生画像メモリ８２の最新取得画像と前回取得画像とのタイムスタンプの差分を算出する（ステップ９０３）。
次に、アラームｃｈ用の再生画像メモリ８２の前回取得画像に付加情報として与えられているフレームレート情報を読み出し、アラーム継続判定値を算出する（ステップ９０４）。例えば、アラームｃｈ用の再生画像メモリ８２の前回取得画像に付加されていたフレームレート情報が１５ｆｐｓであった場合、フレーム間隔は６６ｍｓｅｃと算出され、その値に、例えば２０ｍｓｅｃという余裕値を加えた８６ｍｓｅｃという値をアラーム継続判定値として設定する。

次に、ステップ９０３で算出した差分と、ステップ９０４で算出したアラーム継続判定値とを比較する（ステップ９０５）。比較の結果、差分がアラーム継続値以下の場合はステップ９０２へ分岐する。その理由は、フレームレート情報に基づき算出したアラーム継続判定値とステップ９０３で算出した差分を比較することで、現在クライアント端末６のアラームｃｈ用の再生画像メモリ８２の前回取得画像記憶領域に保持されている画像データが、ディスク装置３のアラームｃｈに画像データが所定のフレームレートで連続して記録されている期間の画像データであるか否かが判断できるためである。つまり、ある時刻に発生したアラームにより開始した１のアラーム録画が継続している期間における画像データであるか、ある時刻に発生したアラームにより開始した１のアラーム録画と、その後の別の時刻に発生したアラームにより開始した他のアラーム録画との境い目となる地点の画像データであるかを判断し、１のアラーム録画が継続している期間は、途中で通常ｃｈの画像データの再生は行わず、アラームｃｈの画像データの再生を優先するようにする。従って、例え、ステップ９０１において、通常ｃｈの前回取得画像の方がアラームｃｈの前回取得画像よりも再生基準時刻により近い時刻の画像データであると判定される場合であっても、１のアラーム録画が継続している期間である場合にはステップ９０２に分岐し、アラームｃｈの前回取得画像の再生を行う。なお、図９で示した処理の具体例については、図１０（Ａ）及び図１１を用いて後述する。一方、ステップ９０５による比較の結果、タイムスタンプの差分がアラーム継続値よりも大きい場合は、ステップ９０６へ分岐する。

ステップ９０５でＹｅｓと判定された場合、通常ｃｈ用の再生画像メモリ８１より前回取得画像を読み出し、モニタへ出力し画像データの再生を行う（ステップ９０６）。
次に、図１０（Ａ）、図１０（Ｂ）、図１０（Ｃ）、図１１を用いて上記図７、図９を用いて説明した画像再生処理の具体例について説明する。

図１０（Ａ）は、ディスク装置３の通常ｃｈ及びアラームｃｈの記録内容の一例を説明するための図である。図１０（Ａ）においては、通常ｃｈには１のＷｅｂカメラ５の画像データが４ｆｐｓで記録されており、アラームｃｈには当該Ｗｅｂカメラ５の画像データが１８ｆｐｓで記録されている。なお、アラームｃｈは、フレーム番号１〜７、及び、フレーム番号８〜１２の計２回のアラーム録画が行われた場合を示している。また、図１０（Ａ）においては、各画像データを示した正方形の図形の左辺の位置が示す時刻が当該画像データが有するタイムスタンプとする。ここで、４ｆｐｓ、１８ｆｐｓという値は、説明の便宜上用いた値であって、上述した通り、通常録画用レート、アラーム録画用レートは、実際のシステムの設定状況に応じて任意に設定することが可能である。例えば、３０ｆｐｓ（３３ｍｓｅｃ間隔）で画像データの取得を行うカメラを用いた場合には、通常録画用レート、又は、アラーム録画用レートとしては、３３ｍｓｅｃの倍数となる３０ｆｐｓ、１５ｆｐｓ、１０ｆｐｓ、６ｆｐｓ、５ｆｐｓ、３ｆｐｓ、２ｆｐｓ、１ｆｐｓ等を設定するのが好適である。

図１１は、ディスク装置３の通常ｃｈ及びアラームｃｈの記録内容が図１０（Ａ）に示した場合において、クライアント端末６が図７、図９で示した画像再生処理を行った場合の通常ｃｈ用の再生画像メモリ８１と、アラームｃｈ用の再生画像メモリ８２の記録内容及び再生される画像データを示したものである。なお、再生基準時刻がｔ１の位置にある場合を図１１（Ａ）、再生基準時刻がｔ２の位置にある場合を図１１（Ｂ）、再生基準時刻がｔ３の位置にある場合を図１１（Ｃ）、再生基準時刻がｔ４の位置にある場合を図１１（Ｄ）にそれぞれ示している。なお、図１１（Ａ）〜（Ｄ）は、図７のステップ７１０の再生画像選択処理が行われた直後の状態を表わすものである。

まず、再生基準時刻がｔ１の位置にある場合について説明する。図７のステップ７０７では、その時点におけるアラームｃｈと通常ｃｈの最新取得画像（図１０（Ａ）では共にフレーム番号２）のタイムスタンプは、再生基準時刻ｔ１と一致するため、ステップ７０８に分岐する。なお、ステップ７０８では、アラームｃｈと通常ｃｈ共に次に取得すべき画像データとしてフレーム番号３が算出されるものとする。次に、ステップ７０９では、クライアント端末６は画像蓄積配信サーバ１に対してアラームｃｈ、通常ｃｈのフレーム番号３の画像データの配信要求を行い、図１１（Ａ）に示す通り、再生画像メモリ８１、８２を更新し、それぞれフレーム番号２の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ７０９において配信要求を行い、現在、画像蓄積配信サーバ１を介して取得中であるフレーム番号３の画像データがそれぞれ記憶されることになる。次に、ステップ７１０の再生画像選択処理では、その時点におけるアラームｃｈと通常ｃｈの前回取得画像（図１０（Ａ）では共にフレーム番号２）のタイムスタンプは一致するため、図９のステップ９０１においてＹｅｓと判定され、ステップ９０２ではアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号２）が選択され、モニタに出力される。

次に、再生基準時刻がｔ２の位置にある場合について説明する。図７のステップ７０７では、その時点におけるアラームｃｈの最新取得画像（図１０（Ａ）ではフレーム番号３）のタイムスタンプは、再生基準時刻ｔ２と一致するため、ステップ７０８に分岐する。なお、ステップ７０８では、次に取得すべきアラームｃｈの画像データとしてフレーム番号４が算出されるものとする。次に、ステップ７０９では、クライアント端末６は画像蓄積配信サーバ１に対してアラームｃｈのフレーム番号４の画像データの配信要求を行い、図１１（Ｂ）に示す通り、再生画像メモリ８２を更新し、フレーム番号３の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ７０９において配信要求を行い、現在、画像蓄積配信サーバ１を介して取得中であるフレーム番号４の画像データが記憶されることになる。次に、ステップ７１０の再生画像選択処理では、その時点におけるアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号３）のタイムスタンプの方が通常ｃｈの前回取得画像（図１０（Ａ）ではフレーム番号２）のタイムスタンプより新しいため、図９のステップ９０１においてＹｅｓと判定され、ステップ９０２ではアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号３）が選択され、モニタに出力される。

次に、再生基準時刻がｔ３の位置にある場合について説明する。図７のステップ７０７では、その時点における通常ｃｈの最新取得画像（図１０（Ａ）ではフレーム番号３）のタイムスタンプは、再生基準時刻ｔ３と一致するため、ステップ７０８に分岐する。ここでは、ステップ７０８では、次に取得すべき通常ｃｈの画像データとしてフレーム番号４が算出されるものとする。次に、ステップ７０９では、クライアント端末６は画像蓄積配信サーバ１に対して通常ｃｈのフレーム番号４の画像データの配信要求を行い、図１１（Ｃ）に示す通り、再生画像メモリ８１を更新し、フレーム番号３の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ７０９において配信要求を行い、現在、画像蓄積配信サーバ１を介して取得中であるフレーム番号４の画像データが記憶されることになる。次に、ステップ７１０の再生画像選択処理では、その時点における通常ｃｈの前回取得画像（図１０（Ａ）ではフレーム番号３）のタイムスタンプの方がアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号６）のタイムスタンプより新しいため、図９のステップ９０１においてＮｏと判定され、ステップ９０３に分岐する。ｔ３の時点では、フレーム番号１〜７よりなる１のアラーム録画が継続している状態であるため、ステップ９０３、９０４の後のステップ９０５では、アラームｃｈの最新取得画像と前回取得画像のタイムスタンプの差分はアラーム継続判定値より小さくなるので、ステップ９０５ではＮｏと判定され、ステップ９０２によりアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号６）が選択され、モニタに出力される。

次に、再生基準時刻がｔ４の位置にある場合について説明する。図７のステップ７０７では、その時点における通常ｃｈの最新取得画像（図１０（Ａ）ではフレーム番号４）のタイムスタンプは、再生基準時刻ｔ４と一致するため、ステップ７０８に分岐する。なお、ステップ７０８では、次に取得すべき通常ｃｈの画像データとしてフレーム番号５が算出されるものとする。次に、ステップ７０９では、クライアント端末６は画像蓄積配信サーバ１に対して通常ｃｈのフレーム番号５の画像データの配信要求を行い、図１１（Ｄ）に示す通り、再生画像メモリ８１を更新し、フレーム番号４の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ７０９において配信要求を行い、現在、画像蓄積配信サーバ１を介して取得中であるフレーム番号５の画像データが記憶されることになる。次に、ステップ７１０の再生画像選択処理では、その時点における通常ｃｈの前回取得画像（図１０（Ａ）ではフレーム番号４）のタイムスタンプの方がアラームｃｈの前回取得画像（図１０（Ａ）ではフレーム番号７）のタイムスタンプより新しいため、図９のステップ９０１においてＮｏと判定され、ステップ９０３に分岐する。ｔ４の時点では、フレーム番号１〜７よりなる１のアラーム録画は終了している状態であるため、ステップ９０３、９０４の後のステップ９０５では、アラームｃｈの最新取得画像と前回取得画像のタイムスタンプの差分はアラーム継続判定値より大きくなるので、ステップ９０５ではＹｅｓと判定され、ステップ９０６により通常ｃｈの前回取得画像（図１０（Ａ）ではフレーム番号４）が選択され、モニタに出力される。

図１０（Ｂ）は、ディスク装置３の通常ｃｈ及びアラームｃｈの記録内容が図１０（Ａ）に示した場合において、クライアント端末６が図７、図９で示した画像再生処理を行った場合に再生される画像データについて説明するための図である。図１０（Ｂ）に示すように、同じ時刻に通常ｃｈ、アラームｃｈ共に画像データが存在する場合は、アラームｃｈの画像データの再生が優先される。例えば、通常ｃｈ及びアラームｃｈのフレーム番号２の画像データはそれぞれ同じタイムスタンプを有するため、アラームｃｈのフレーム番号２の画像データの再生が行われ、通常ｃｈのフレーム番号２の画像データの再生は行われない。また、アラーム録画が継続している期間、即ち、アラームｃｈの画像データが所定のフレームレートで連続して存在する期間であるため、通常ｃｈのフレーム番号３、６の画像データの再生は行われない。

図１０（Ｃ）は、ディスク装置３の通常ｃｈ及びアラームｃｈの記録内容が図１０（Ａ）に示した場合において、クライアント端末６が図７、図９で示した画像再生処理の一部を変更した他の画像再生処理を行った場合に再生される画像データについて説明するための図である。図１０（Ｃ）においては、図９で示したステップ９０３〜９０５の処理は行わず、ステップ９０１でＮｏと判定された場合は、ステップ９０６に分岐するようにした。つまり、アラーム録画が継続している期間はアラームｃｈの画像データの再生を優先するという処理を行わないため、画像データの再生はアラームｃｈ、通常ｃｈに関わらず時系列順に行われる。従って、図１０（Ｃ）に示す通り、通常ｃｈのフレーム番号３、６の画像データの再生も行われる。なお、図１０（Ｃ）においても、アラームｃｈのフレーム番号２の画像データと同じタイムスタンプを有する通常ｃｈのフレーム番号２の画像データについては再生されない。

なお、本発明の画像再生方法の他の実現手段として、ディスク装置３にアラーム録画を行う際に、各Ｗｅｂカメラ５毎に図１４に示すようなアラーム録画の内容を管理するためのテーブルを生成するようにして、クライアント端末６がシームレス再生を行う際に画像蓄積配信サーバ１内に記憶されている当該テーブル参照するようにしてもよい。このようなテーブルを参照することで、予めディスク装置３のアラームｃｈに画像データが記録されている時間帯（アラーム録画開始時刻〜アラーム録画終了時刻）や、その時間帯における画像データのフレーム番号（アラーム録画開始フレーム番号〜アラーム録画終了フレーム番号）が把握できるので、例えば、アラーム録画による画像データが存在しない時間帯においては通常録画による画像データの再生を行うといったアルゴリズムにより、クライアント端末６におけるシームレス再生を実現することが可能である。このようなアルゴリズムを用いた場合であれば、例えば、図９のステップ９０１の処理のように、アラームｃｈと通常ｃｈの画像データのタイムスタンプを比較するといった処理等を、１フレーム分の画像データを再生する度に毎回行う必要はなくなる。

また、上記の実施形態では、画像データを順方向に再生する場合を例に説明したが、例えば、再生基準時刻にディレイ時間を加算するのか減算するのか等といった処理の違いはあるものの、逆方向（新しい時刻から古い時刻へ）の再生についても、同様の処理によりシームレス再生を実現することが可能である。

また、順方向に再生する際に、例えば、１／２倍速再生や、２倍速再生や、４倍速再生といった倍速再生を行う場合には、例えば、図７のステップ７０５において、再生基準時刻にステップ７０４で算出したディレイ時間に倍速係数（例えば、２倍速であれば２）を乗算した結果を加算し、再生基準時刻の更新を行うようにすればよい。

また、上記の例では、図１０（Ａ）に示すように、通常ｃｈと、アラームｃｈの画像データのタイムスタンプにずれ量が発生する場合を例に説明したが（例えば、通常ｃｈのフレーム番号３の画像データと、アラームｃｈのフレーム番号６の画像データ等）、通常録画用レートとアラーム録画用レートを所定のフレームレートに設定するようにして、上述したずれ量が発生しないような構成を用いることも可能である。

また、上記の例では、アラームｃｈの画像データを優先して再生することで、高フレームレートの画像データが再生されるような態様としていたが、例えば、各ｃｈにフレームレート、圧縮率、解像度等が異なる画像データが記録されているような場合には、例えば、低圧縮率の画像データや、高解像度の画像データ等が優先して再生されるような態様を用いることも可能である。

また、上記の実施形態では、１つのディスク装置の異なる記憶領域にアラームｃｈと通常ｃｈとを構成する態様としていたが、アラームｃｈと通常ｃｈとをそれぞれ異なるディスク装置に構成するような態様を用いることも可能である。

以下で、本発明に関する技術の背景を示す。なお、ここで記載する事項は、必ずしも全てが従来の技術であるとは限定しない。
上記の例では、１のＷｅｂカメラ５に対して通常録画とアラーム録画を行う場合は、それぞれ通常ｃｈとアラームｃｈという異なるｃｈを用いて画像データの記録を行う構成としていたが、以下では、通常録画とアラーム録画を行う場合に１つのｃｈに対して画像データの記録を行う構成について、図１２、図１３を用いて説明する。

図１２は、通常録画とアラーム録画による画像データの記録を１つのｃｈに対して行う場合の処理の一例を説明するための図である。図１２に示すように、時刻ｔ０〜ｔ２の期間においては、画像蓄積配信サーバ１はＷｅｂカメラ５の映像を指定のフレームレートで録画する。時刻ｔ２において外部センサからのアラーム信号の入力によりアラームの発生が検知されると、画像蓄積配信サーバ１は時刻ｔ２より一定時間前の時刻ｔ１からの映像をＷｅｂカメラ５から取得して映像の記録を開始する。ここで、時刻ｔ１からの映像を記録するのは、プリアラーム画像も記録するためである。この映像はＷｅｂカメラのアラーム映像用バッファ（例えば、図３の送信映像メモリ５３に相当するもの）にバッファリングされていたもので、画像蓄積配信サーバ１はこれを既に記録済みのｔ１〜ｔ２の映像に上書きし、更にｔ２〜ｔ３の映像を時差記録（通常録画と異なり時系列を遡ってアラーム発生時刻前の映像、即ちプリアラーム画像の記録も行うため、ここでは時差記録と称する）することになる。なお、ここでは時刻ｔ３において外部センサからのアラーム信号の入力が完了し、アラームの終了が検知されるものとする。従って、時刻ｔ１〜ｔ３のＷｅｂカメラ５の映像に対するアラーム録画が終了するのは、時刻ｔ４＝ｔ３＋（ｔ２−ｔ１）である。つまり、アラーム録画として、時刻ｔ２〜ｔ４の期間に時刻ｔ１〜ｔ３の映像を記録する。そして、時刻ｔ４以降、画像蓄積配信サーバ１は通常録画による映像の記録を再開する。

ここで、図１２に示した処理を行うと、時刻ｔ３〜ｔ４が未録画区間（記録欠損）になってしまうという問題がある。図１３は、図１２に示した記録欠損を解決するための処理の一例を説明するための図である。図１３に示す処理では、時刻ｔ２〜ｔ３の期間に時刻ｔ１〜ｔ３の映像を記録する、すなわち記録間隔を通常より短くして、高速に録画を実施する。しかし、この高速録画には、例えば、（１）発生したアラームがいつ終了するかはわからないため、１のアラーム録画が継続する期間は事前には予測がつかず適切な記録間隔の短縮量が算出できない、という問題がある。このような問題はアラーム録画継続期間の最低値を決めることで回避することが可能であるが、システム構築上の制約につながる。また、例えば、（２）高速録画中は、画像蓄積配信サーバ１の処理負荷が通常より大きくなる、といった問題がある。すなわち、画像蓄積配信サーバ１の録画性能に高速録画のための負荷増分をマージンとして織り込んでおく必要が生じる。さらに、アラームの発生は複数台のＷｅｂカメラ５から非同期に入ってくる、すなわち同時に多数のアラームが発生する可能性があるので、それぞれに対して負荷増分のマージンを加算して画像蓄積配信サーバ１の性能仕様を算定しなくてはならず、性能仕様上得策ではない。従って、時差録画区間における録画は、高速録画（図１３）をするより、その時差を守ったまま通常の記録間隔での録画（図１２）を行うほうがよい。１ｃｈで常時、時差を守って通常録画及びアラーム録画を続ける方法もあるが、突然の電源断等による映像の損失等が考えられ、ＵＰＳ（Ｕｎｉｎｔｅｒｒｕｐｔｉｂｌｅ Ｐｏｗｅｒ Ｓｕｐｐｌｙ）を設置する等の対策が必要になり、例えば、システムの高コスト化という問題も発生する。

これに対して本発明の実施例に関わる構成では、通常録画とアラーム録画とでｃｈを分けて記録を行うようにしたため、例えば、図１２及び図１３を用いて説明した上記のような問題を解決することができる。なお、同じ時間帯の映像が、例えば、通常ｃｈとアラームｃｈの２ｃｈに冗長に録画されるため、図１２及び図１３の構成に比べると余計な記録容量を必要となるが、例えば、通常録画とアラーム録画による画像データの記録を同時に実施する場合は、通常録画は低フレームレート（例えば、１ｆｐｓ等）で実施することが多いので、図１２及び図１３を用いて説明した方式において発生する問題に比べると、大きな問題とはならない。

また、アラーム録画は時系列を遡ってアラーム発生時刻前の映像（プリアラーム画像）の記録を行う必要があるため、通常録画とアラーム録画による画像データを同一ｃｈ上には共存させにくい。従って、例えば、１つのｃｈには１つのＷｅｂカメラの映像を時系列に格納し、かつ、例えば、通常ｃｈとアラームｃｈといったように１つのＷｅｂカメラの映像を２つのｃｈに分けて格納するような構成とすると、記録システムの構成を簡略化することができる。なお、１つのＷｅｂカメラの映像を３つ以上のｃｈに分けて格納するような構成を用いることも可能であることは言うまでもない。

また、上述したように、本発明の画像再生方法（シームレス再生）は、例えば、１つのカメラから生成した２種類の録画映像を、１つの再生画面であたかも１つの映像ストリームとしてユーザに対して再生を行うことができる。

ここで、本発明に係る画像再生方法の構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。なお、本発明は、例えば本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムなどとして提供することも可能であり、また、例えば画像再生装置などの種々な装置やシステムとして提供することも可能である。また、本発明の適用分野としては、必ずしも以上に示したものに限られず、本発明は、種々な分野に適用することが可能なものである。例えば、上記の実施形態においては、監視システムのカメラによって発生した映像を例に説明を行ったが、本発明の適用分野としては、これに限られるものではない。例えば、映画やテレビ番組に関する映像を取り扱うといったことも可能である。

また、本発明に係る画像再生方法などにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウエア資源においてプロセッサがＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に格納された制御プログラムを実行することにより制御される構成が用いられてもよく、また、例えば当該処理を実行するための各機能手段が独立したハードウエア回路として構成されてもよい。

また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクやＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体からコンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。

本発明の一実施例に係る画像蓄積配信システムの全体構成を示す図である。 本発明の一実施例に係るディスク装置の記録内容を説明するための図である。 本発明の一実施例に係るディスク装置への記録動作を説明するための図である。 本発明の一実施例に係る画像再生処理を説明するための図である。 本発明の一実施例に係る画像再生処理を説明するための図である。 本発明の一実施例に係る画像再生処理を説明するための図である。 本発明の一実施例に係る画像再生処理を説明するためのフローチャートである。 本発明の一実施例に係るメモリ領域の構成を示す図である。 本発明の一実施例に係る画像再生処理を説明するためのフローチャートである。 本発明の一実施例に係る記録内容や再生内容の一例を説明するための図である。 本発明の一実施例に係る記録内容及び再生内容の一例を説明するための図である。 １つのｃｈに対して異なる記録モードによる記録を行う場合の処理の一例を説明するための図である。 １つのｃｈに対して異なる記録モードによる記録を行う場合の処理の一例を説明するための図である。 本発明の一実施例に係る記録内容を管理するためのテーブルの一例を示す図である。

符号の説明

１：画像蓄積配信サーバ、３：ディスク装置、４：ネットワーク、５：Ｗｅｂカメラ、６：クライアント端末、３０：記憶領域

Claims (7)

1. Ｗｅｂカメラとネットワークを介して接続され、アラームが発生したときに前記Ｗｅｂカメラの画像を所定の画質で記録する画像蓄積配信サーバにおいて、
   前記Ｗｅｂカメラから受信した画像を第１の画質で通常録画すると共に、外部センサの作動によるアラーム発生通知を受信したときには前記Ｗｅｂカメラにアラーム発生より前の時刻の画像データの配信要求をして、前記通常録画を続けながら第２の画質でプリアラーム録画及びアラーム録画を前記通常録画と重複的に行い、
   クライアントからシームレス再生の指示を受けたときには、通常録画とアラーム録画が重複している期間において画質が高い一方を優先させて、時系列に沿って該クライアントで再生されるように、録画された画像を読み出して配信することを特徴とする画像蓄積配信サーバ。
2. 請求項１に記載の画像蓄積配信サーバにおいて、
   前記Ｗｅｂカメラに前記第１の画質で送信させて受信した画像を一時的に記憶する第１メモリと、
   前記アラームの発生に応じて前記Ｗｅｂカメラに前記第２の画質で送信させて受信した画像を一時的に記憶する第２メモリと、
   第１記憶領域と第２記憶領域とを有し、前記第１及び第２メモリの画像を、タイムスタンプと共に前記第１及び第２記憶領域にそれぞれ記憶するディスク装置と、を備え、
   時系列に沿った前記再生は、前記タイムスタンプに基づいて行われることを特徴とする画像蓄積配信サーバ。
3. 請求項２に記載の画像蓄積配信サーバにおいて、前記第２の画質は、前記Ｗｅｂカメラがプリアラーム録画のために前記所定期間記憶している画像の画質であることを特徴とする画像蓄積配信サーバ。
4. 請求項３に記載の画像蓄積配信サーバにおいて、
   前記画質とは、少なくともフレームレート又は圧縮率又は解像度のいずれか１つのことであり、
   前記画質が高いとは、少なくともフレームレートが高いこと又は圧縮率が低いこと又は解像度が高いことのいずれか１つのことである、ことを特徴とする画像蓄積配信サーバ。
5. 前記画像蓄積配信サーバは、前記Ｗｅｂカメラで圧縮された画像をＩＰパケット形式で受信することを特徴とする請求項４に記載の画像蓄積配信サーバ。
6. 前記画像蓄積配信サーバは、前記ＷｅｂカメラからＪＰＥＧ相当の画像圧縮形式で圧縮された静止画像として画像を受信し、前記通常録画及びプリアラーム録画は、当該静止画像が時系列に連続した間欠的な準動画像として録画するものであることを特徴とする請求項５に記載の画像蓄積配信サーバ。
7. Ｗｅｂカメラと、前記Ｗｅｂカメラとネットワークを介して接続される画像蓄積配信サーバと、を備え、外部センサにおいてアラームが発生したときに少なくとも該アラームが発生する前の所定時間におけるＷｅｂカメラの画像を所定のフレームレートで記録しプリアラーム録画を行う画像蓄積配信システムであって、
   前記Ｗｅｂカメラは、撮像された映像信号を一定のフレームレートで圧縮符号化して画像データとして出力するエンコーダ部と、前記画像データのうち最新の１フレームあるいは間欠的に時系列に連続した複数フレームを記憶する第１のメモリと、画像データのうち前記所定時間における画像データを所定のアラーム録画レートで記録する第２のメモリと、を有して、前記画像蓄積配信サーバから画像データの配信要求を受けたとき或いは所定のタイミングで、当該画像蓄積配信サーバに前記第１のメモリの画像データを送信するとともに、前記画像蓄積配信サーバから時刻を指定された画像データの配信要求を受けたときに、前記第２のメモリの画像データを当該画像蓄積配信サーバに前記アラーム録画レートで送信し、
   前記画像蓄積配信サーバは、前記Ｗｅｂカメラに配信要求をして通常録画を行うと共に、前記外部センサの作動によるアラーム発生通知を受信したときには前記Ｗｅｂカメラにアラーム発生の所定時間前の時刻の画像データの配信要求をして、前記通常録画を続けながら前記アラーム録画レートでプリアラーム録画を行い、クライアントからシームレス再生の指示を受けたときには通常録画とプリアラーム録画のうち画質が高い方を優先させて、記録された映像を時系列に沿って再生することを特徴とする画像蓄積配信システム。