WO2005074274A1

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

Info

Publication number: WO2005074274A1
Application number: PCT/JP2005/001113
Authority: WO
Inventors: Seiichi Hirai; Shinya Ogura; Takashi Mito; Shigeyuki Murata
Original assignee: Hitachi Kokusai Electric Inc.
Priority date: 2004-01-29
Filing date: 2005-01-27
Publication date: 2005-08-11
Also published as: GB2427521A; JP2005217791A; GB2427521B; GB0614541D0; US8015586B2; JP4315827B2; US20070124782A1

Abstract

　記録装置に多様な形態で記録されている画像データを効果的に再生する画像再生機能を提供する。１つの撮像装置により得られる動画像を異なるフレームレートにより複数系統で記録し、該記録された動画像を再生する場合において、前記記録された動画像は、複数の静止画像データから構成されており、前記記録された動画像の再生の基準となる時間軸に従って、前記複数系統のうちのいずれか１つの系統の動画像を構成する前記静止画像データを再生するようにする。

Description

明細書

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

参照による取り込み

[0001] 本出願は、 2004年 1月 29日に出願された日本特許出願第 2004—022106号の優先権を主張し、その内容を参照することにより本出願に取り込む。

技術分野

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

背景技術

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

[0004] このようなシステムは、種々な用途に利用されており、例えば、画像により、侵入者や管理対象物の異常を監視する監視システムとして利用されている (例えば、特開 2 003— 274383号公報）。

発明の開示

発明が解決しょうとする課題

[0005] ところで、クライアント装置への画像データの配信は、カメラで撮影した画像データをサーバに蓄積し、当該サーバからクライアント装置へ配信する形態が一般的である

。しかし、上記のようなシステムの普及に伴レ、、今後、ユーザの利便性向上のために、サーバへ蓄積する画像データの記録形態が多様化することが想定される。例えば

、ネットワークの通信負荷やサーバの記憶容量等を考慮し、同一のカメラの映像であつても、時間帯や、特定の異常が発生した場合等に応じて、画像データの品質 (解像度、圧縮率、フレームレート（fps : frame per second)等）が変えられる場合もありえる。

し力しながら、従来のシステムは、多用な形態で記録されている画像データを効果的に再生するには十分なシステムではなかった。

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

課題を解決するための手段

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

[0008] ここで、「複数系統で記録」とは、例えば、 1つの撮像装置により得られた映像を異なる映像条件により 1つの記録装置の複数チャネル或いは異なる記録装置にそれぞれ記録することや、それに準じた状況による記録すること等をいう。

ここで、「映像条件」とは、例えば、上記したフレームレートの他、解像度や、圧縮率等のことをいう。

[0009] なお、本明細書では、「画像」という語を用いて説明を行うが、例えば、「映像」といつた語についても、同様な用語であり、本発明に包含される。

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

また、本明細書では、「記録」や「記憶」という語を用いて説明を行うが、例えば、「レコード」や「録画」といった語についても、同様な用語であり、本発明に包含される。

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

[0012] ここで、前記生成された画像データのそれぞれの時刻が「同時刻」であるか否かは、例えば、画像データに時刻情報を付与する際に発生する誤差分の時間等を考慮して判断されても良い。

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

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

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

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

発明の効果

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

発明を実施するための最良の形態

[0018] 本発明に係る一実施例を図面を参照して説明する。

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

[0019] 図 1は、本発明による画像再生方法が適用される画像蓄積配信システムの全体構成の一実施例を示す。本実施例に示した画像蓄積配信システムは、画像 (音声を含む場合もある）データを蓄積するためのランダムアクセス可能な記録装置 (以下、ディスク装置と言う） 3を備えた画像蓄積配信サーバ 1と、ネットワーク 4を介して上記画像蓄積配信サーバ 1に接続された複数の Webカメラ 5 (5—1 5— n)と、複数のクライアント端末 6 (6-1-6- m)と、力なる。

本実施例の画像蓄積配信システムにおいては、 1つの Webカメラ 5の画像データを、記録モードに応じて複数のチャネル (本実施例では 2つのチャネル）に分けて記録する構成としているため、 Webカメラ 5—1— 5_nは、それぞれ固有のチャネル番号を複数有している。例えば、 5—1はチャネル 1 (chl)用、及び、チャネル 2 (ch2)用、 - - ■■■■、 5— nはチャネル p— 1 (chp— 1)用、及び、チャネル p (chp)の Webカメラとする。ここで、 n、 m、 pは自然数であり、 n=m=pである必要はなぐその組み合わせは任意に選択できる。

[0020] Webカメラ 5-1— 5-nによる撮影映像の各フレームの画像データは、例えば、 JPE G等の画像圧縮方式で圧縮され、 IPパケット形式で画像蓄積配信サーバ 1に送信される。この場合、圧縮された画像データは、フレーム毎にデータ量の異なる可変長データとなる。画像蓄積配信サーバ 1は、 Webカメラ 5—1— 5_n力らネットワークを介して受信した各パケットから圧縮画像データ (以下、単に画像データと言う）を抽出し、ディスク装置 3に予め確保されたチャネル別の記憶領域 30 (30-1— 30-p)に記憶する。

したがって、各記憶領域 30には 1台の Webカメラ 5の画像が時系列に格納されることとなる。また、記録の際、各画像データには制御のためにフレーム毎にフレーム番号が割り振られる。なお、上記画像蓄積配信システムにおいては、画像蓄積配信サーバ 1とディスク装置 3等の機能が一体化された装置を用レ、ることも可能である。

[0021] 各クライアント端末 6は、画像蓄積配信サーバ 1に対して、チャネル番号とフレーム番号とを指定して画像データの配信を要求する。画像蓄積配信サーバ 1は、クライアント端末からの要求に応じて、ディスク装置 3から読み出した指定チャネル番号/フレーム番号の画像データを IPパケット形式で要求元のクライアント端末 6に配信サービスする。これにより、各クライアント端末 6は、ディスク装置 3に記録されている画像データの再生を行うことができる。

本発明の画像再生方法は、クライアント端末 6が画像蓄積配信サーバ 1に対して画像データの配信要求を行い、クライアント端末 6のモニタに画像データを再生する際に適用される。

[0022] ここで、上記画像蓄積配信システムに実装されている記録モードとしては、そのトリガ要因の違いから、スケジュール録画、手動録画、アラーム録画の 3種類がある。スケジュール録画とは、あらかじめユーザにより設定されたタイムテーブルに従って Webカメラ 5から画像データの記録を行うものである。手動録画とは、クライアント端末 6のモニタにて画像監視を行っているユーザがクライアント端末 6の GUI操作 (録画ボタン押下等)により任意のタイミングで Webカメラ 5から画像データの記録を行うものである。アラーム録画とは、 Webカメラ 5へのアラーム信号の入力 (外部センサからの接点入力、または画像認識処理による侵入者検知等)により Webカメラ 5から画像データの記録を行うものである。

なお、これら 3つの記録モード以外の記録モードが用いられてもよレ、。また、以下では、スケジュール録画と手動録画とを通常録画と称し、通常録画により記録が行われるディスク装置 3の記憶領域 30のことを通常チャネル (通常 ch)と称する。また、ァラーム録画により記録が行われるディスク装置 3の記憶領域 30のことをアラームチヤネノレ（アラーム ch)と称する。

[0023] 図 2は、本発明の一実施例に係るディスク装置の記録内容を説明するための図である。

図 2に示すように、ディスク装置 3の記録容量の物理的な制約等から、通常録画を行う場合には低フレームレートで通常 chへ画像データの記録を行レ、、アラーム録画を行う場合にはアラームが発生した時のみ高フレームレートでアラーム chへ画像データの記録を行うような態様が用いられる。なお、図 2のアラーム chに示したように、ァラーム録画にっレ、ては、アラーム発生から時系列を遡ってアラーム発生時刻前の所定時間の画像 (プリアラーム画像）の記録も行うようにしてレ、る。

なお、ここでは、通常録画とアラーム録画とでは、記録される画像データのフレームレートのみが異なる場合を例に説明するが、更に画像の圧縮率や解像度を変える等、各記録モードの記録内容を実際のシステムの設定状況に応じて任意に設定することが可能である。別の実施例として、アラーム録画は、通常録画に比べて、高フレームレート、低圧縮率、高解像度で画像データの記録を行うようにすることが可能である

[0024] 図 3は、本発明の一実施例に係るディスク装置への記録動作を説明するための図である。

図 3を用いて、 Webカメラ 5の画像データを通常録画、及び、アラーム録画によりデイスク装置 3の記憶領域 30—1 (chl)、 30-2 (ch2)に記録する際の、 Webカメラ 5及び画像蓄積配信サーバ 1の構成を説明する。なお、ここでは、簡単化のため、 Web力メラ 5のうちの 1台の Webカメラ 5—1を用いて説明を行う。

[0025] Webカメラ 5— 1は、撮影部 50、エンコーダ部 51、送信映像メモリ 52、送信映像メモリ（リングバッファ） 53、ネットワークインタフェース（IZF) 54から構成されてレ、る。

[0026] 画像蓄積配信サーバ 1は、ネットワークインタフェース（I/F) 10、受信映像メモリ 11

(11—1一 11—2)、ディスクインタフェース（I/F) 12から構成されている。ここで、 We bカメラ 5-1と画像蓄積配信サーバ 1とはネットワーク I/F54、 10を介して接続され、画像蓄積配信サーバ 1とディスク装置 3とはディスク I/F12を介して接続されている。

[0027] Webカメラ 5— 1の撮影部 50は、所定の視野範囲を撮像する。撮像された映像信号は、例えば、 30fpsというフレームレート、即ち、 1秒間に 30フレームという時間間隔でエンコーダ部 51に入力される。エンコーダ部 51は、映像信号を、例えば、 JPEG形式等で圧縮符号化し、画像データを生成する。

[0028] エンコーダ部 51で符号ィ匕された画像データは、例えば、 30fpsで送信映像メモリ 5 2に入力され、送信映像メモリ 52において一時的に記憶される。送信映像メモリ 52は、エンコーダ部 51より新たな 1フレームの画像データが入力されると、それまで記憶していた画像データを破棄し、新たな画像データを記憶する。画像蓄積配信サーバ 1 の CPU (不図示）は、通常録画を行う際は、予め画像蓄積配信サーバ 1内のデータメモリ（不図示）に設定されている通常録画用レート（フレームレート）に従レ、、 Webカメラ 5— 1に対して画像データの配信要求を送信する。

Webカメラ 5— 1は、画像データの配信要求を受信すると、その時点において送信映像メモリ 52に記憶されている 1フレームの画像データを画像蓄積配信サーバ 1へ送信する。通常録画の場合、画像蓄積配信サーバ 1は、クライアント端末 6— 1等のュ一ザにより、設定された録画開始力録画終了に至るまで、 Webカメラ 5-1に対して画像データの配信要求を繰り返す。画像蓄積配信サーバ 1は、受信した画像データを受信映像メモリ 11_1に一時的に記憶し、その後、画像データをディスク IZF12を介して Webカメラ 5—1の通常 chとして使用されるディスク装置 3の記憶領域 30—1 (c hi)に記録する。

なお、本実施例では、要求がある毎に画像データが 1フレームずつ、ネットワーク 4 を介して配信される方法を採用しているが、別の実施例として、要求がある毎に画像データが複数フレーム分 (あるいは 1ファイル分)配信される方法を採用してもよい。また、本実施例では、 Webカメラ 5から出力される画像データは間欠的であると共に時系列に連続した動画像である力他の形式が用いられてもよい。

また、本実施例のように、画像蓄積配信サーバ 1側からのアクセス（配信要求）を受けて、 Webカメラ 5が画像データの配信を行う pull型のシステム構成の他、別の実施例として、サーバ 1側からのアクセスなしに、例えば、所定のタイミングで Webカメラ 5 が画像データの配信を行う push型のシステム構成が用いられても良い。

また、エンコーダ部 51で符号化された画像データは、予め Webカメラ 5-1内のデ一タメモリ（不図示）に設定されているアラーム録画用レート（フレームレート）で、送信映像メモリ 53に入力され、送信映像メモリ 53に一時的に記憶される。送信映像メモリ 53は、送信映像メモリ 52の構成とは異なり、例えば、 100フレーム分といった複数フレームの画像データを保持できるような構成となっている。これは、上述した通り、ァラーム録画においては、アラームが発生する前の所定期間における画像データ（ブリアラーム画像）の記録を行う必要があるためである。

Webカメラ 5—1に接続されてレ、る外部センサ（不図示）が作動し Webカメラ 5—1に対してアラーム信号が入力されると、 Webカメラ 5— 1から画像蓄積配信サーバ 1に対してアラーム発生通知が送信される。アラーム発生通知を受信した画像蓄積配信サーバ 1の CPUは、アラーム録画を開始する。アラーム録画を行う際は、画像蓄積配信サーバ 1の CPUは、アラーム発生時刻から所定時間だけ前の時刻を指定して Web カメラ 5-1に対して画像データの配信要求を送信する。 Webカメラ 5-1は、送信映像メモリ 53内に記憶されている当該指定時刻からの画像データを画像蓄積配信サーバ 1へ送信する。

画像蓄積配信サーバ 1は、受信した画像データを受信映像メモリ 11 - 2に一時的に記憶し、その後、画像データをディスク I/F12を介して Webカメラ 5— 1のアラーム ch として使用されるディスク装置 3の記憶領域 30_2 (ch2)に記憶する。

[0030] なお、 Webカメラ 5—1から画像蓄積配信サーバ 1への画像データの送信は、発生したアラームが終了するまで継続する。すなわち、外部センサの作動が停止し Webカメラ 5— 1から画像蓄積配信サーバ 1に対してアラーム終了通知が送信されると、アラーム終了通知を受信した画像蓄積配信サーバ 1の CPUは、画像データの配信要求を停止する。

ここで、送信映像メモリ 53に記憶されている画像データは、 Webカメラ 5—1の CPU (不図示）がアラーム録画用レートに従いエンコーダ部 51より読み出して送信映像メモリ 53に記憶したものである。そのため、通常録画の場合とは異なり、アラーム録画の場合は、画像蓄積配信サーバ 1の CPUは Webカメラ 5—1に対して画像データの配信要求を行う際にフレームレートに関する制御は行わず、アラーム発生からアラーム終了まで（プリアラーム画像も含む）の時間帯における送信映像メモリ 53内の画像データすべてにっレ、て配信要求を行う。なお、上述したように、画像蓄積配信サーバ 1に対してアラーム終了通知が送信されることによって画像データの配信要求が停止されるという態様の他、別の実施例として、例えば、画像蓄積配信サーバ 1がアラーム発生通知を受信した時点から予め設定された所定期間後に画像データの配信要求が停止される（ポストアラーム録画）といった態様が用いられてもよい。

[0031] ここで、ディスク装置 3の記憶領域 30に記録される画像データには、例えば、当該フレームの時刻情報（以下、タイムスタンプと称する。）、各 chにおける撮影順序を示すフレーム番号、フレームレート情報（通常録画用レート或いはアラーム録画用レート )等が付加情報として付されてレ、る。

ここで、タイムスタンプは、 Webカメラ 5のエンコーダ部 51により画像データが生成される時刻や、画像蓄積配信サーバ 1が Webカメラ 5より画像データを受信した時刻等を用いて生成される。例えば、画像蓄積配信サーバ 1が Webカメラ 5より画像データを受信した時刻を用いてタイムスタンプを生成する場合については、以下の手法でタィムスタンプを算出しても良レ、。

一例として、通常録画の場合は、画像データの受信時刻を当該画像データのタイムスタンプとする。一方、アラーム録画の場合は、送信映像メモリ 53に画像データが保持される所定期間がある。係る場合、一例として、 Webカメラ 5がネットワーク IZF5 4から画像データを配信する時刻とエンコーダ部 51が画像データを生成した時刻との差分を求め、求めた差分を画像蓄積配信サーバ 1における画像データの受信時刻から減算する。従って、アラーム録画の場合は、当該減算値を当該画像データのタイムスタンプとする。

[0032] なお、本実施例では、通常録画用レートは画像蓄積配信サーバ 1によって設定され、アラーム録画用レートは Webカメラ 5によって設定されている力これらの情報の設定先は実際のシステムの構成に応じて任意に選定することが可能である。

例えば、図 3の送信映像メモリ 53のような複数フレーム分の画像データを一時的に保持するようなメモリを Webカメラ 5側に設けるような構成が用いられる場合ではなぐ画像蓄積配信サーノく1側に設けるような構成が用いられる場合であれば、アラーム録画用レートも画像認識サーバ 1によって設定されていればよい。

[0033] 次に、本発明の画像再生方法について説明する。

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

[0034] 図 4は、「通常 chのみ再生」の動作を説明するための図である。図 4において、水平方向は時間方向を表し、各 chの録画期間が長方形で表されている。また、図 4中の太線の矢印で示される部分が再生される。なお、後述する図 5、図 6についても同様である。ここで、図 4に示す通り、「通常 chのみ再生」を行う場合は、所定の通常 ch、例えば、ディスク装置 3の記憶領域 30-1 (Webカメラ 5-1の通常 ch)に記録されている画像データのみが時系列順に読み出されてクライアント端末 6のモニタに再生される。

[0035] 図 5は、「アラーム chのみ再生」の動作を説明するための図である。図 5に示す通り、「アラーム chのみ再生」を行う場合は、所定のアラーム ch (例えば、ディスク装置 3の記憶領域 30—2 (Webカメラ 5—1のアラーム ch) )に記録されている画像データのみが時系列順に読み出されてクライアント端末 6のモニタに再生される。

なお、図 5の点線の矢印で示したように、画像データが存在しない期間については再生がスキップされ、次の画像データが存在する期間についての映像の再生が続けられる。 Webカメラ 5により生成された画像データがディスク装置 3の記憶領域 30に記録される際に、各画像データに対して撮影順序を示すフレーム番号が付されるような構成を用いる場合は、クライアント端末 6は画像蓄積配信サーバ 1に対してフレーム番号順に画像データの配信要求を行うことで、図 4、及び、図 5で示した画像再生方法を実現することが可能である。

[0036] 図 6は、本発明の一実施例に係る「シームレス再生」の動作を説明するための図である。ここで、「シームレス再生」とは、図 6に示すように、時系列に沿って映像の再生を行う際、ある時刻において、アラーム chに画像データが存在する場合には、通常 c hの画像データの有無に関わらずアラーム chの画像データを再生し、アラーム chに画像データが存在せず通常 chにのみ画像データが存在する場合には、通常 chの画像データを再生するといつたアルゴリズムによって実施される画像再生方法のことをいう。両 chとも画像データが存在しない場合には、次にどちらかの chに画像データが存在する時刻までスキップして画像データの再生を続けても良い。

ここで、アラーム chの画像データの再生を優先する理由は、図 6に示したようなァラーム chと通常 chとのどちらも画像データが存在する区間については、高フレームレートで画像データが記録されているアラーム chの画像データを再生した方力より詳細に内容の確認を行うことができるためである。なお、本実施例のシステムは、アラーム録画、及び、通常録画を行う際のフレームレート、画像の解像度や圧縮率などは任意に設定することができるため、同時刻にどちらの chにも画像データが存在する場合に、どの chの画像データの再生を優先するかは、実際のシステムの設定状況に応じて任意に設定することが可能である。なお、後述するように各時刻において各 chに画像データが存在するかの判定は、画像データの再生開始時に生成する再生基準時刻と、各 chから取出した画像データに付与されたタイムスタンプとの比較により行ってもよい。ここで、再生基準時刻とは、例えば、再生の基準となる時間軸を意味する。

[0037] 図 7は本発明の一実施例に係る画像再生処理（シームレス再生） 700の基本的な動作を説明するフローチャートである。

図 7を用いて、クライアント端末 6が実行する画像再生処理 (シームレス再生）の流れの一例を説明する。

[0038] 画像再生処理 700では、まず、現在のシステム時刻（現在時刻）が制御時刻として、クライアント端末 1が備えるデータメモリ（不図示）に記憶される (ステップ 701)。次に、現在のクライアント端末 6のモニタに表示してレ、る画像データのタイムスタンプが再生基準時刻としてデータメモリに記憶される（ステップ 702)。このステップ 702 の処理は、画像データの再生開始時刻を設定するための処理であるため、上述したような現在のクライアント端末 6のモニタに表示されている画像データのタイムスタンプを再生開始時刻とする態様の他、別の実施例として、クライアント端末 6のユーザに再生開始時刻を指定させる等、種々な態様を用いても良い。

[0039] 次に、クライアント端末 6が現在、画像蓄積配信サーバ 1を介してディスク装置 3のァラーム ch或いは通常 chの画像データを取得している最中であるか否かが判定される (ステップ 703)。後述するステップ 709において、クライアント端末 6は画像蓄積配信サーバ 1に対して所定の画像データの配信要求を行うが、クライアント端末 6がその画像データの取得を終えるまでは、処理は次のステップ 704へは分岐しなレ、（ステツプ 703で Yesと判定される）。クライアント端末 6が現在、画像データの取得中ではない場合は、処理は次のステップ 704へ分岐する（ステップ 703で Noと判定される）。

[0040] 次に、クライアント端末 6は、データメモリに記憶されている制御時刻と現在のシステム時刻との差分を算出し、算出された時間を「ディレイ時間」としてデータメモリに記憶する（ステップ 704)。なお、クライアント端末 6は、ディレイ時間を求めた後、現在のシステム時刻を新たな制御時刻としてデータメモリに記憶し、制御時刻の更新を行う。従って、このディレイ時間とは、図 7のステップ 704の処理を終えてから、再度ステップ 704の処理に戻ってくるまでに要する時間である。

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

[0042] 次に、クライアント端末 6は、アラーム ch用の再生画像メモリと、通常 ch用の再生画像メモリと、力も最新取得画像のフレーム番号及びタイムスタンプを取得する（ステツプ 706)。

ここで、再生画像メモリについて説明する。図 8は、クライアント端末 6が備える再生画像メモリの一構成例を示す図である。再生画像メモリは、通常 ch用の再生画像メモリ 81と、アラーム ch用の再生画像メモリ 82とからなる。それぞれのメモリ 81 , 82は、前回取得画像記憶領域の 1フレーム分と、最新取得画像記憶領域の 1フレーム分という少なくとも 2フレーム分の画像データを一時的に保持する領域を有している。図 7に示す画像再生処理を行う際、画像蓄積配信サーバ 1を介してディスク装置 3のアラーム chに記録されている画像データを受信したクライアント端末 6は、当該画像データをアラーム ch用の再生画像メモリ 82の最新取得画像記憶領域に記憶する。通常 ch についても同様である。

なお、クライアント端末 6は、後述するステップ 709において、再生画像メモリの更新を行うため、 1つ前に取得した画像データは、前回取得画像記憶領域に記憶される。

[0043] 次に、ステップ 706で取得したアラーム ch用の再生画像メモリ 82の最新取得画像のタイムスタンプと、通常 ch用の再生画像メモリ 81の最新取得画像のタイムスタンプとのそれぞれを、再生基準時刻と比較する（ステップ 707)。アラーム ch或いは通常 c hの最新取得画像のタイムスタンプの少なくともいずれか一方が再生基準時刻以前（再生基準時刻より古い時刻）の時刻を示している場合は、処理はステップ 708に分岐する。一方、どちらの最新取得画像のタイムスタンプも再生基準時刻以後（再生基準時刻より新しい時刻）の時刻を示している場合は、処理はステップ 711に分岐する。

[0044] ステップ 707で Yesと判定された場合、ステップ 707において最新取得画像が再生基準時刻以前のタイムスタンプを有していると判定された chについて、クライアント端末 6は、次に取得すべき画像データのフレーム番号を算出する（ステップ 708)。なお、アラーム chと通常 chのどちらの chについても最新取得画像のタイムスタンプが再生基準時刻以前であると判定される場合には、クライアント端末 6は、両方の chについて、次に取得すべき画像データのフレーム番号の算出を行う。

[0045] ここで、フレーム番号の算出は、例えば、ステップ 704で得られたディレイ時間を用いて行われる。

ディスク装置 3の各 chに記録されている画像データがそれぞれ時系列順にフレーム番号が付されているような構成において、ディレイ時間が小さい場合には、次に取得する画像データは、現在、クライアント端末 6が保持している最新取得画像データの次フレームの画像データとする（即ち、次に取得する画像データのフレーム番号は、ステップ 706で取得したフレーム番号に 1をカ卩えた番号とする）。一方、ディレイ時間が大きい場合には、次に取得する画像データは、現在、クライアント端末 6が保持している最新取得画像データの 3フレーム後の画像データとする（即ち、次に取得する画像データのフレーム番号は、ステップ 706で取得したフレーム番号に 3を加えた番号とする)。

より具体的には、例えば、ディスク装置 3のある chに記録されている画像データが 3 Ofpsである場合、 33msec間隔でフレーム番号が 1増える。ステップ 704で得られたディレイ時間が 100msecである場合には、ディレイ時間（100msec)をフレーム間隔 (33msec)で割り、その商である 3という値が、現在、クライアント端末 6が保持している最新取得画像データのフレーム番号に加えられる。このフレーム番号は、次にクライアント端末 6が画像蓄積配信サーバ 1に対して配信要求を行う画像データのフレーム番号とする。ここで、上記のように、フレーム番号の算出のためのフレームレート情報（上記の例ではフレーム間隔 33msec)には、例えば、再生画像メモリの最新取得画像データが付加情報として保持しているフレームレート情報を用いることができる。

[0046] 次に、クライアント端末 6は画像蓄積配信サーバ 1に対して、ステップ 708で算出したフレーム番号の画像データの配信要求を行う（ステップ 709)。

ここで、ステップ 707で再生基準時刻以前と判定された最新取得画像データがァラーム chのものであれば、このステップ 709ではクライアント端末 6はアラーム chの画像データの配信要求を行う。再生基準時刻以前と判定された最新取得画像データが通常 chのものであれば、このステップ 709ではクライアント端末 6はアラーム chの画像データの配信要求を行うことになる。

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

[0047] 次に、クライアント端末 6は、再生画像メモリ 81、 82からモニタに再生する画像データを選択し、当該画像データをモニタに出力する（ステップ 710)。

なお、ステップ 710の詳細については、図 9を用いて後述する。また、本実施例においては、ステップ 710の再生画像選択処理が図 7に示したフローチャートの中の 1 つの処理 (ステップ）として記載されている力例えば、画像データがモニタに描画される処理に要する時間を考慮して、再生画像選択処理が独立に実行されるようにしてもよい。

[0048] 次に、ステップ 707でクライアント端末 6のいずれの chの最新取得画像のタイムスタンプも再生基準時刻より以後であると判定された場合、クライアント端末 6は、新たな画像データの配信要求等（ステップ 708等の処理）を行わず、アラーム ch用及び通常 ch用の再生画像メモリ 81、 82の最新取得画像の内で古い (過去の）方の時刻を示すタイムスタンプをスキップ判定時刻としてデータメモリに記憶する（ステップ 711)

[0049] 次に、クライアント端末 6は、ステップ 711で設定したスキップ判定時刻と再生基準時刻との差分が 3秒以上あるかないかを判定する (ステップ 712)。差分が 3秒以上ある場合には、処理はステップ 713に分岐し、差分が 3秒以上ない場合には、ステップ 713の処理は行わず、処理はステップ 714に分岐する。

[0050] ステップ 712で Yesと判定された場合、クライアント端末 6は、スキップ判定時刻を新たな再生基準時刻としてデータメモリに記憶する (ステップ 713)。

なお、上記 3秒は、再生基準時刻と、次に再生されるべき画像データのタイムスタンプとの差分から再生基準時刻を所定期間だけスキップさせるか否かを見定める基準値の一例である。当該基準値は、実際のシステムの設定状況に応じて任意に設定されればよい。この基準値を適切な値に設定することで、例えば、クライアント端末 6は、ディスク装置 3の chに画像データが存在しない時間帯をスキップして画像データの再生を行うことができる。なお、クライアント端末 6は、スキップ判定時刻を用いて再生基準時刻を更新した後、現在のシステム時刻を新たな制御時刻としてデータメモリに記憶し、制御時刻の更新を行うようにしてもょレ、。

[0051] 次に、クライアント端末 6は、クライアント端末 6のユーザより画像データの再生停止指示があつたか否かを判定する。再生停止指示があった場合には画像再生処理が終了し、再生停止指示がない場合には処理はステップ 703に分岐する（ステップ 714

[0052] ここで、図 7に示したステップ 710の処理の一例を図 9を用いて詳細に説明する。

再生画像選択処理 (ステップ 710)では、まず、クライアント端末 6は、通常 ch用の再生画像メモリ 81の前回取得画像のタイムスタンプと、アラーム ch用の再生画像メモリ 82の前回取得画像のタイムスタンプとの比較を行う（ステップ 901)。

比較の結果、アラーム ch用の再生画像メモリ 82の前回取得画像のタイムスタンプの方が新しいと判定される場合は、処理はステップ 902に分岐する。同様に、アラーム ch用の再生画像メモリ 82の前回取得画像のタイムスタンプと、通常 ch用の再生画像メモリ 81の前回取得画像のタイムスタンプとが同時刻であると判定される場合も、処理はステップ 902に分岐する。一方、比較の結果、通常 ch用の再生画像メモリ 81 の前回取得画像のタイムスタンプの方が新しいと判定される場合は、処理はステップ 903に分岐する。

[0053] ステップ 901で Yesと判定された場合は、クライアント端末 6は、アラーム ch用の再生画像メモリ 82より前回取得画像を読み出し、モニタへ出力し画像データの再生を行う（ステップ 902)。本実施例では、ステップ 710を行う際に再生画像メモリ 81、 82 の前回取得画像記憶領域に記憶されてレ、る画像データのタイムスタンプは、再生基準時刻よりも古レ、 (過去の）時刻となるように構成されるため、アラーム chと通常 chの前回取得画像の内、タイムスタンプが新しい方の画像データは、再生基準時刻により近い時刻の画像データということになる。

また、アラーム ch用の再生画像メモリ 82の前回取得画像のタイムスタンプと、通常 c h用の再生画像メモリ 81の前回取得画像のタイムスタンプとが同時刻であると判定される場合にも処理がステップ 902に分岐するようにした理由は、図 6を用いて上述したように、アラーム chと通常 chとに同時刻の画像データが存在する場合には、アラーム chの画像データの再生を行うように構成したためである。

[0054] ステップ 901で Noと判定された場合は、クライアント端末 6は、アラーム ch用の再生画像メモリ 82の最新取得画像と前回取得画像とのタイムスタンプの差分を算出する（ステップ 903)。

次に、クライアント端末 6は、アラーム ch用の再生画像メモリ 82の前回取得画像に付加情報として与えられているフレームレート情報を読み出し、アラーム継続判定値を算出する (ステップ 904)。例えば、アラーム ch用の再生画像メモリ 82の前回取得画像に付加されていたフレームレート情報が 15fpsであった場合、フレーム間隔は 6 6msecと算出される。クライアント端末 6は、その値に、例えば 20msecという余裕値をカロえた 86msecという値をアラーム継続判定値として設定する。

[0055] 次に、クライアント端末 6は、ステップ 903で算出した差分と、ステップ 904で算出したアラーム継続判定値とを比較する（ステップ 905)。比較の結果、差分がアラーム継続値以下の場合、処理はステップ 902へ分岐する。その理由は、フレームレート情報に基づき算出したアラーム継続判定値とステップ 903で算出した差分とを比較することで、現在クライアント端末 6のアラーム ch用の再生画像メモリ 82の前回取得画像記憶領域に保持されてレ、る画像データが、ディスク装置 3のアラーム chに所定のフレームレートで連続して記録されている期間の画像データであるか否かが判断できるためである。

つまり、クライアント端末 6は、上記保持されている画像データが、ある時刻から発生したアラームにより開始した 1のアラーム録画が継続している期間における画像データであるか、若しくは、上記保持されている画像データが、ある時刻に発生したアラームにより開始した 1のアラーム録画と、その後の別の時刻に発生したアラームにより開始した他のアラーム録画との境い目となる地点の画像データであるかを判断する。その結果、 1のアラーム録画が継続している期間は、途中で通常 chの画像データの再生は行わず、アラーム chの画像データの再生を優先するようにする。

従って、例え、ステップ 901において、通常 chの前回取得画像の方がアラーム ch の前回取得画像よりも再生基準時刻により近い時刻の画像データであると判定される場合であっても、 1のアラーム録画が継続している期間である場合には処理はステップ 902に分岐し、アラーム chの前回取得画像が再生される。

なお、図 9で示した処理の具体例については、図 10A及び図 11A— 11Dを用いて後述する。一方、ステップ 905による比較の結果、タイムスタンプの差分がアラーム継続値よりも大きレ、場合は、処理はステップ 906へ分岐する。

[0056] ステップ 905で Yesと判定された場合、クライアント端末 6は、通常 ch用の再生画像メモリ 81より前回取得画像を読み出し、モニタへ出力し画像データの再生を行う（ステツプ 906)。

次に、図 10A、図 10B、図 10C、図 11A一 11Dを用レヽて上記図 7、図 9を用レヽて説明した画像再生処理の具体例について説明する。

[0057] 図 10Aは、ディスク装置 3の通常 ch及びアラーム chの記録内容の一例を説明するための図である。図 10Aにおいては、通常 chには 1の Webカメラ 5の画像データが 4f psで記録されており、アラーム chには当該 Webカメラ 5の画像データが 18fpsで記録されている。なお、アラーム chは、フレーム番号 1一 7、及び、フレーム番号 8— 12の計 2回のアラーム録画が行われた場合を示してレ、る。

また、図 10Aにおいては、各画像データを示した正方形の図形の左辺の位置が示す時刻が、当該画像データが有するタイムスタンプとする。ここで、 4fps、 18fpsという値は、説明の便宜上用いた値であって、上述した通り、通常録画用レートやアラーム録画用レートは、実際のシステムの設定状況に応じて任意に設定することが可能である。例えば、 30fps (33msec間隔）で画像データの取得を行うカメラを用いた場合には、通常録画用レート、又は、アラーム録画用レートとしては、 33msecの倍数となる 30fps、 15fps、 10fps、 6fps、 5fps、 3fps、 2fps、 lfps等を設定するのが好適である。

[0058] 図 11A 11Dは、ディスク装置 3の通常 ch及びアラーム chの記録内容が図 10Aに示した場合において、クライアント端末 6が図 7、図 9で示した画像再生処理を行った場合の通常 ch用の再生画像メモリ 81と、アラーム ch用の再生画像メモリ 82と、の記録内容及び再生される画像データを示したものである。

なお、再生基準時刻が tlの位置にある場合を図 1 1A、再生基準時刻が t2の位置にある場合を図 11B、再生基準時刻が t3の位置にある場合を図 11C、再生基準時刻が t4の位置にある場合を図 11Dにそれぞれ示している。なお、図 11A— 11Dは、図 7のステップ 710の再生画像選択処理が行われた直後の状態を表わすものである

[0059] まず、再生基準時刻が tlの位置にある場合について説明する。図 7のステップ 707 では、その時点におけるアラーム chと通常 chの最新取得画像（図 10Aでは共にフレーム番号 2)のタイムスタンプは、再生基準時刻 tlと一致するため、処理はステップ 7 08に分岐する。なお、ステップ 708では、アラーム chと通常 ch共に次に取得すべき画像データとしてフレーム番号 3が算出されるものとする。

次に、ステップ 709では、クライアント端末 6は画像蓄積配信サーバ 1に対してァラーム ch、通常 chのフレーム番号 3の画像データの配信要求を行う。次に、クライアント端末 6は、図 11Aに示す通り、再生画像メモリ 81、 82を更新し、それぞれフレーム番号 2の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ 709において配信要求を行レ、、現在、画像蓄積配信サーバ 1を介して取得中であるフレーム番号 3の画像データがそれぞれ記憶されることになる。

次に、ステップ 710の再生画像選択処理では、その時点におけるアラーム chと通常 chの前回取得画像（図 10Aでは共にフレーム番号 2)のタイムスタンプは一致するため、図 9のステップ 901において Yesと判定される。

ステップ 902ではアラーム chの前回取得画像（図 1 OAではフレーム番号 2)が選択され、モニタに出力される。

[0060] 次に、再生基準時刻が t2の位置にある場合について説明する。

図 7のステップ 707では、その時点におけるアラーム chの最新取得画像（図 10Aではフレーム番号 3)のタイムスタンプは、再生基準時刻 t2と一致するため、処理はステップ 708に分岐する。なお、ステップ 708では、次に取得すべきアラーム chの画像データとしてフレーム番号 4が算出されるものとする。

次に、ステップ 709では、クライアント端末 6は画像蓄積配信サーバ 1に対してァラーム chのフレーム番号 4の画像データの配信要求を行い、図 11Bに示す通り、再生画像メモリ 82を更新し、フレーム番号 3の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ 709において配信要求を行い、現在、画像蓄積配信サーバ 1を介して取得中であるフレーム番号 4の画像データが記憶されることになる。

次に、ステップ 710の再生画像選択処理では、その時点におけるアラーム chの前回取得画像（図 10Aではフレーム番号 3)のタイムスタンプの方が通常 chの前回取得画像（図 10Aではフレーム番号 2)のタイムスタンプより新しいため、図 9のステップ 90 1におレ、て Yesと判定される。

ステップ 902ではアラーム chの前回取得画像（図 1 OAではフレーム番号 3)が選択され、モニタに出力される。

[0061] 次に、再生基準時刻が t3の位置にある場合について説明する。図 7のステップ 707 では、その時点における通常 chの最新取得画像（図 10Aではフレーム番号 3)のタイムスタンプは、再生基準時刻 t3と一致するため、処理はステップ 708に分岐する。ステツプ 708では、次に取得すべき通常 chの画像データとしてフレーム番号 4が算出されるものとする。

次に、ステップ 709では、クライアント端末 6は画像蓄積配信サーバ 1に対して通常 chのフレーム番号 4の画像データの配信要求を行い、図 11Cに示す通り、再生画像メモリ 81を更新し、フレーム番号 3の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ 709において配信要求を行レ、、現在、画像蓄積配信サーバ 1を介して取得中であるフレーム番号 4の画像データが記憶されることになる。

次に、ステップ 710の再生画像選択処理では、その時点における通常 chの前回取得画像（図 10Aではフレーム番号 3)のタイムスタンプの方がアラーム chの前回取得画像（図 10Aではフレーム番号 6)のタイムスタンプより新しいため、図 9のステップ 90 1におレ、て Noと半 IJ定され、処理はステップ 903に分岐する。 t3の時点では、フレーム番号 1一 7よりなる 1のアラーム録画が継続している状態であるため、ステップ 903、 9 04の後のステップ 905では、アラーム chの最新取得画像と前回取得画像のタイムスタンプの差分はアラーム継続判定値より小さくなる。よって、ステップ 905では Noと判定される。

ステップ 902によりアラーム chの前回取得画像（図 10Aではフレーム番号 6)が選択され、モニタに出力される。

次に、再生基準時刻が t4の位置にある場合について説明する。

図 7のステップ 707では、その時点における通常 chの最新取得画像（図 1 OAではフレーム番号 4)のタイムスタンプは、再生基準時刻 t4と一致するため、処理はステツプ 708に分岐する。なお、ステップ 708では、次に取得すべき通常 chの画像データとしてフレーム番号 5が算出されるものとする。

次に、ステップ 709では、クライアント端末 6は画像蓄積配信サーバ 1に対して通常 chのフレーム番号 5の画像データの配信要求を行い、図 11Dに示す通り、再生画像メモリ 81を更新し、フレーム番号 4の画像データを前回取得画像記憶領域に記憶する。最新取得画像記憶領域には、ステップ 709において配信要求を行レ、、現在、画像蓄積配信サーバ 1を介して取得中であるフレーム番号 5の画像データが記憶されることになる。次に、ステップ 710の再生画像選択処理では、その時点における通常 chの前回取得画像（図 10Aではフレーム番号 4)のタイムスタンプの方がアラーム chの前回取得画像（図 10Aではフレーム番号 7)のタイムスタンプより新しいため、図 9のステップ 90 1におレ、て Noと半 IJ定され、処理はステップ 903に分岐する。

t4の時点では、フレーム番号 1一 7よりなる 1のアラーム録画は終了している状態であるため、ステップ 903、 904の後のステップ 905では、アラーム chの最新取得画像と前回取得画像のタイムスタンプの差分はアラーム継続判定値より大きくなる。よって、ステップ 905では Yesと判定され、ステップ 906により通常 chの前回取得画像（図 1 OAではフレーム番号 4)が選択され、モニタに出力される。

[0063] 図 10Bは、ディスク装置 3の通常 ch及びアラーム chの記録内容が図 10Aに示したような内容である場合において、クライアント端末 6が図 7、図 9で示した画像再生処理を行った画像データの再生について説明するための図である。

図 10Bに示すように、同じ時刻に通常 ch、アラーム ch共に画像データが存在する場合は、アラーム chの画像データの再生が優先される。例えば、通常 ch及びアラーム chのフレーム番号 2の画像データはそれぞれ同じタイムスタンプを有するため、ァラーム chのフレーム番号 2の画像データの再生が行われ、通常 chのフレーム番号 2 の画像データの再生は行われない。また、アラーム録画が継続している期間（即ち、アラーム chの画像データが所定のフレームレートで連続して存在する期間）は、通常 chのフレーム番号 3、 6の画像データの再生は行われない。

[0064] 図 10Cは、ディスク装置 3の通常 ch及びアラーム chの記録内容が図 10Aに示したような内容である場合において、クライアント端末 6が図 7、図 9で示した画像再生処理の一部を変更した他の画像再生処理を行った場合に再生される画像データについて説明するための図である。

図 10Cにおいては、図 9で示したステップ 903 905の処理は行われない。ステツプ 901で Noと判定された場合は、処理はステップ 906に分岐するようにした。つまり、アラーム録画が継続している期間はアラーム chの画像データの再生を優先するという処理を行わないため、画像データの再生はアラーム ch、通常 chに関わらず時系列順に行われる。従って、図 10Cに示す通り、通常 chのフレーム番号 3、 6の画像データの再生も行われる。なお、図 10Cにおいても、アラーム chのフレーム番号 2の画像データと同じタイムスタンプを有する通常 chのフレーム番号 2の画像データについては再生されない。

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

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

[0067] また、順方向に再生する際に、例えば、 1/2倍速再生や、 2倍速再生や、 4倍速再生といった倍速再生を行う場合には、図 7のステップ 705において、再生基準時刻にステップ 704で算出したディレイ時間に倍速係数 (例えば、 2倍速であれば 2)を乗算した結果を加算し、再生基準時刻の更新を行う構成にすればよい。

[0068] また、上記の例では、図 10Aに示すように、通常 chと、アラーム chの画像データのタイムスタンプにずれ量が発生する場合を例に説明したが（例えば、通常 chのフレーム番号 3の画像データと、アラーム chのフレーム番号 6の画像データ等）、別の実施例として、通常録画用レートとアラーム録画用レートを所定のフレームレートに設定するようにして、上述したずれ量が発生しないような構成を用いることも可能である。

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

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

[0071] 以下で、本発明に関する技術の背景を示す。なお、ここで記載する事項は、必ずしも全てが従来の技術であるとは限定しない。

上記の例では、 1の Webカメラ 5に対して通常録画とアラーム録画を行う場合は、それぞれ通常 chとアラーム chという異なる chを用いて画像データの記録を行う構成としていたが、以下では、通常録画とアラーム録画を行う場合に 1つの chに対して画像データの記録を行う構成について、図 12、図 13を用いて説明する。

[0072] 図 12は、通常録画とアラーム録画による画像データの記録を 1つの chに対して行う場合の処理の一例を説明するための図である。

図 12に示すように、時刻 tO— 12の期間においては、画像蓄積配信サーバ 1は Web カメラ 5の映像を指定のフレームレートで録画する。時刻 t2において外部センサからのアラーム信号の入力によりアラームの発生が検知されると、画像蓄積配信サーバ 1 は時刻 t2より一定時間前の時刻 tlからの映像を Webカメラ 5から取得して映像の記録を開始する。

ここで、時刻 tlからの映像を記録するのは、プリアラーム画像も記録するためである。この映像は Webカメラのアラーム映像用バッファ（例えば、図 3の送信映像メモリ 53 に相当するもの）にバッファリングされていたものであって、画像蓄積配信サーバ 1はこれを既に記録済みの tl一 t2の映像に上書きされ、更に t2 3の映像を時差記録 (通常録画と異なり、時系列を遡ってアラーム発生時刻前の映像（即ちプリアラーム画像）の記録も行うため、ここでは時差記録と称する）をすることになる。なお、ここでは時刻 t3において外部センサからのアラーム信号の入力の継続が完了し、アラームの終了が検知されるものとする。従って、時刻 tl一 t3の Webカメラ 5の映像に対するアラーム録画が終了するのは、時刻 t4 = t3 + (t2— tl)である。つまり、画像蓄積配信サーバ 1は、アラーム録画として、時刻 t2— 14の期間に時刻 tl一 t3の映像を記録する。そして、時刻 t4以降、画像蓄積配信サーバ 1は通常録画による映像の記録を再開する。

[0073] ここで、図 12に示した処理を行うと、時刻 t3 4が未録画区間（記録欠損）になつてしまうという問題がある。図 13は、図 12に示した記録欠損を解決するための処理の一例を説明するための図である。図 13に示す処理では、時刻 t2— 3の期間に時刻 t 1一 t3の映像を記録する、すなわち記録間隔を通常より短くして、高速に録画を実施する。しかし、この高速録画には、例えば、（1)発生したアラームがいつ終了するかはわからないため、 1のアラーム録画が継続する期間は事前には予測がつかず適切な記録間隔の短縮量が算出できない、という問題がある。このような問題はアラーム録画継続期間の最低値を決めることで回避することが可能であるが、システム構築上の制約につながる。また、例えば、（2)高速録画中は、画像蓄積配信サーバ 1の処理負荷が通常より大きくなる、といった問題がある。すなわち、画像蓄積配信サーバ 1の録画性能に高速録画のための負荷増分をマージンとして織り込んでおく必要が生じる。さらに、アラームの発生は複数台の Webカメラ 5から非同期に入ってくる、すなわち同時に多数のアラームが発生する可能性があるので、それぞれに対して負荷増分のマージンを加算して画像蓄積配信サーバ 1の性能仕様を算定しなくてはならず、性能仕様上得策ではない。従って、時差録画区間における録画は、高速録画（図 13 )をするより、その時差を守ったまま通常の記録間隔での録画（図 12)を行うほうがよレ、。 lchで常時、時差を守って通常録画及びアラーム録画を続ける方法もある力突然の電源断等による映像の損失等が考えられ、 UPS (Uninterruptible Power S upply)を設置する等の対策が必要になり、例えば、システムの高コスト化という問題も発生する。

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

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

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

[0077] ここで、本発明に係る画像再生方法の構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。

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

[0078] また、本発明に係る画像再生方法などにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウェア資源にぉレ、てプロセッサが ROM (Rea d Only Memory)に格納された制御プログラムを実行することにより制御される構成が用いられてもよぐまた、例えば当該処理を実行するための各機能手段が独立したハードウェア回路として構成されてもよい。

[0079] また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクや C D (Compact Disc)_ROM等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体力コンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。

[0080] 上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者には明らかである。

産業上の利用可能性

[0081] 本発明は、例えば本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムなどとして利用することも可能であり、また、例えば画像再生装置などの種々な装置やシステムとして利用することも可能である。図面の簡単な説明

[0082] [図 1]本発明の一実施例に係る画像蓄積配信システムの全体構成を示す図である。

[図 2]本発明の一実施例に係るディスク装置の記録内容を説明するための図である。

[図 3]本発明の一実施例に係るディスク装置への記録動作を説明するための図である。

[図 4]本発明の一実施例に係る画像再生処理を説明するための図である。

[図 5]本発明の一実施例に係る画像再生処理を説明するための図である。

[図 6]本発明の一実施例に係る画像再生処理を説明するための図である。

[図 7]本発明の一実施例に係る画像再生処理を説明するためのフローチャートである園 8]本発明の一実施例に係るメモリ領域の構成を示す図である。

[図 9]本発明の一実施例に係る画像再生処理を説明するためのフロ [図 10A]本発明の一実施例に係る記録内容や再生内容の一例を説明するための図である。

[図 10B]本発明の一実施例に係る記録内容や再生内容の一例を説明するための図である。

[図 10C]本発明の一実施例に係る記録内容や再生内容の一例を説明するための図である。

[図 11A]本発明の一実施例に係る記録内容及び再生内容の一例を説明するための図である。

[図 11B]本発明の一実施例に係る記録内容及び再生内容の一例を説明するための図である。

[図 11C]本発明の一実施例に係る記録内容及び再生内容の一例を説明するための図である。

[図 11D]本発明の一実施例に係る記録内容及び再生内容の一例を説明するための図である。

[図 12]本発明の一実施例に係る 1つの chに対して異なる記録モードによる記録を行う場合の処理の一例を説明するための図である。

[図 13]本発明の一実施例に係る 1つの chに対して異なる記録モードによる記録を行う場合の処理の一例を説明するための図である。

[図 14]本発明の一実施例に係る記録内容を管理するためのテーブルの一例を示す図である。

符号の説明

1 画像蓄積配信サーバ

3 ディスク装置

4 ネットワーク

5 Webカメラ

6 クライアント端末

30 記憶領域

Claims

請求の範囲

[1] 1つの撮像装置により得られる複数の静止画像から構成される動画像を異なる画質により複数系統で記録装置に記録し、該記録装置に記録された動画像を表示する画像表示方法であって、

前記記録装置から前記動画像を構成する静止画像を取得する画像取得ステップと前記取得された静止画像を表示する画像表示ステップとを備え、

前記複数系統のうちの画質が高い系統の動画像を構成する前記静止画像を優先して表示することを特徴とする画像表示方法。

[2] 請求項 1に記載の画像表示方法において、

前記静止画像は時刻情報を有しており、

前記画像取得ステップは、前記時刻情報と、再生基準時刻に基づいて前記記録装置から取得する前記動画像を構成する静止画像を選択する、

ことを特徴とする画像表示方法。

[3] 請求項 1に記載の画像再生方法において、

前記画像表示ステップは、前記画質が高い系統の動画像を構成する前記静止画像が連続して存在する期間においては、前記画質が高い系統の動画像を構成する前記静止画像を表示することを特徴とする画像表示方法。

[4] 請求項 1に記載の画像表示方法において、

前記画質とは、少なくともフレームレート又は圧縮率又は解像度のいずれ力、 1つのことであり、

前記画質が高いとは、少なくともフレームレートが高いこと又は圧縮率が低いこと又は解像度が高レ、ことのレ、ずれか 1つのことである、

ことを特徴とする画像表示方法。

[5] 1つの撮像装置により得られる複数の静止画像から構成される動画像を異なる画質により複数系統で記録装置に記録し、該記録装置に記録された動画像を表示する画像表示装置であって、

前記記録装置から前記動画像を構成する静止画像を取得する画像取得手段と、前記取得された静止画像を表示する画像表示手段とを備え、

前記複数系統のうちの画質が高い系統の動画像を構成する前記静止画像を優先して表示することを特徴とする画像表示装置。

[6] 請求項 5に記載の画像表示装置において、

前記静止画像は時刻情報を有しており、

前記画像取得手段は、前記時刻情報と、再生基準時刻に基づいて前記記録装置から取得する前記動画像を構成する静止画像を選択する、

ことを特徴とする画像表示装置。

[7] 請求項 5に記載の画像再生装置において、

前記画像表示手段は、前記画質が高い系統の動画像を構成する前記静止画像が連続して存在する期間においては、前記画質が高い系統の動画像を構成する前記静止画像を表示することを特徴とする画像表示装置。

[8] 請求項 5に記載の画像表示装置において、

前記画質とは、少なくともフレームレート又は圧縮率又は解像度のいずれ力 1つのことであり、

ことを特徴とする画像表示装置。

[9] 1つの撮像装置により得られる複数の静止画像から構成される動画像を異なる画質により複数系統で記録装置に記録し、該記録装置に記録された動画像を表示する画像表示装置を構成するコンピュータに実行させるプログラムであって、

前記記録装置から前記動画像を構成する静止画像を取得する画像取得機能と、前記取得された静止画像を表示する画像表示機能とを有し、

前記複数系統のうちの画質が高い系統の動画像を構成する前記静止画像を優先して表示することを前記コンピュータにより実現することを特徴とするプログラム。

[10] 請求項 9に記載のプログラムにおいて、

前記静止画像は時刻情報を有しており、

前記画像取得機能は、前記時刻情報と、再生基準時刻に基づいて前記記録装置から取得する前記動画像を構成する静止画像を選択する、

ことを特徴とするプログラム。

[11] 請求項 9に記載のプログラムにおいて、

前記画像表示機能は、前記画質が高レ、系統の動画像を構成する前記静止画像が連続して存在する期間においては、前記画質が高い系統の動画像を構成する前記静止画像を表示することを特徴とするプログラム。

[12] 請求項 9に記載のプログラムにおいて、

ことを特徴とするプログラム。