特許 6367968 映像記録装置および映像記録方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6367968

(24)【登録日】2018年7月13日

(45)【発行日】2018年8月1日

(54)【発明の名称】映像記録装置および映像記録方法

(51)【国際特許分類】

   H04N 5/76 20060101AFI20180723BHJP

   H04N 5/77 20060101ALI20180723BHJP

   H04N 5/915 20060101ALI20180723BHJP

   H04N 7/18 20060101ALI20180723BHJP

   G11B 27/00 20060101ALI20180723BHJP

【ＦＩ】

   H04N5/76

   H04N5/77

   H04N5/915

   H04N7/18 U

   G11B27/00 D

【請求項の数】6

【全頁数】17

(21)【出願番号】特願2016-562627(P2016-562627)

(86)(22)【出願日】2015年12月1日

(86)【国際出願番号】JP2015083707

(87)【国際公開番号】WO2016088741

(87)【国際公開日】20160609

【審査請求日】2017年5月26日

(31)【優先権主張番号】特願2014-243154(P2014-243154)

(32)【優先日】2014年12月1日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000001122

【氏名又は名称】株式会社日立国際電気

(72)【発明者】

【氏名】高田 智巳

(72)【発明者】

【氏名】村田 茂幸

(72)【発明者】

【氏名】笠井 聡

【審査官】 松元 伸次

(56)【参考文献】

【文献】 特許第４５８３２７０（ＪＰ，Ｂ２）

【文献】 特開２０００−２０３６５（ＪＰ，Ａ）

【文献】 特許第４２３７５４９（ＪＰ，Ｂ２）

【文献】 特許第４４０１１３２（ＪＰ，Ｂ２）

【文献】 特開２０１０−２８７５４（ＪＰ，Ａ）

【文献】 特開平８−１１１０８０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ１１Ｂ２０／１０−２０／１６

２７／００−２７／３４

Ｈ０４Ｎ５／７６−５／７７５

５／８０−５／９５６

７／１０

７／１４−７／５６

２１／００−２１／８５８

(57)【特許請求の範囲】

【請求項1】

映像データ領域と配置情報領域とを有する記録デバイスを備えた映像記録装置であって、
前記映像データ領域は、１ＭＢ以上の同一のサイズを有する複数のブロックから構成され、
前記配置情報領域は、前記映像データ領域に記憶しているブロックの配置情報を記憶し、
前記複数のブロックのそれぞれは、複数のフレームの映像データを格納し、前記複数のブロックの内の一部の複数のブロックは、当該ブロックを基準として過去の連続する複数のブロックの目次情報を格納する目次領域を備えたことを特徴とする映像記録装置。

【請求項2】

前記目次領域は、当該ブロックの後端に設けられるか、当該ブロック内の所定のサイズに満たない余り領域を利用して設けられることを特徴とする請求項１記載の映像記録装置。

【請求項3】

前記映像データ領域は、映像源毎に分割され、
前記目次領域は、前記分割された映像データ領域毎に、複数のブロックに設けられることを特徴とする請求項１又は２に記載の映像記録装置。

【請求項4】

映像源毎に分割され、は、複数のブロックの目次領域に亘って分散的に記憶された目次情報以外に、目次情報を有せず、起動の都度、当該目次領域の目次情報から、使用されている前記複数のブロックの全ての目次を復元することを特徴とする請求項２又は３に記載の映像記録装置。

【請求項5】

前記配置情報領域は、前記複数のブロックにインデックス番号を付与して管理し、
前記映像データ領域は、所定の規則で定まる前記複数のブロックの一部を、前記目次領域を優先的に配置する目次優先ブロックとして用い、当該目次優先ブロックが壊れていない限り、当該目次優先ブロックのみの読出しにより、前記映像データ領域で使用されている前記複数のブロックの全ての目次を復元することを特徴とする請求項２又は３に記載の映像記録装置。

【請求項6】

１ＭＢ以上の同一のサイズを有する複数のブロックから構成された映像データ領域と配置情報領域とを有する記録デバイスを備えた映像記録装置の映像記録方法であって、
前記配置情報領域に、前記映像データ領域に記憶しているブロックの配置情報を記憶し、
前記複数のブロックのそれぞれに、複数のフレームの映像データを格納し、
前記複数のブロックの内の一部の複数のブロックに、当該ブロックを基準として過去の連続する複数のブロックの目次情報を格納することを特徴とする映像記録方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ハードディスク等のランダムアクセス記憶媒体を用いた映像記録装置に関する。

【背景技術】

【0002】

従来、監視カメラの映像を記録する循環記録装置が知られる（例えば特許文献１乃至３参照。）。
図３は、特許文献１等に記載された従来の循環記録装置におけるファイルシステムの模式図である。
この循環型ファイルシステムは、記録デバイス１５上に構築され、配置情報領域３０、目次情報領域３１、映像データ領域３２から構成されている。
目次情報領域３１の１単位は目次情報３３であり、映像データ領域３２の１単位は映像MBblock(Mega-BytesBlock)３４であり、目次情報３３と映像MBblock３４は一対一で対応している。
目次情報領域３１と映像データ領域３２は、カメラ（チャンネル）毎に領域が小分けされる。本例では、３台のカメラA〜カメラCに対応して、目次情報として領域３１−１〜領域３１−３が、映像データとして領域３２−１〜領域３２−３が、それぞれ割り当てられる。

【0003】

配置情報領域３０は、どのカメラ領域の何番目の映像MBblockが、記録デバイス上に配置される位置を示すアドレス（例えばＬＢＡ：Logical Block Address）を集めた配置情報が記憶されている。
配置情報領域３０、目次情報領域３１、及び、映像データ領域３２はそれぞれ、原則として、アドレス空間上で連続するように配置され、例えば対をなす領域３１−１と領域３２−１は、アドレス上（及び物理的にも）離れている。

【0004】

図４は、従来の循環記録装置における目次情報３２と映像MBblock３４との関係を説明する図である。
目次情報３３は３２Byte、映像MBblock３４は１ＭＢ以上の固定長を有する。
映像MBblock３４には、１フレーム分の映像フレームデータ３４２を複数含み、複数の映像フレームデータ３４２の列は、複数のPack３４３−１〜Pack３４３−４に分割される。

【0005】

一方、目次情報３３は、先頭フレーム番号３３１、フラグ領域３３２、先頭フレーム時刻３３３、Pack開始アドレス３３４−１〜３３４−Ｑ、Pack内フレーム数３３５−１〜３３５−Ｑのフィールドを含む。Ｑは映像MBblockのサブブロック数（Pack数）の最大値であり、１０とする。
先頭フレーム番号３３１は、ペアとなる映像MBblock３４の先頭映像データのフレーム番号を示す。フレーム番号は、このファイルシステムで独自に管理される、カメラ領域３１を作成した時を０とした単調増加の値である。
フラグ領域３３２は、その目次情報３３の状態を示すフラグを格納する。状態は、ペアとなる映像MBblockが存在するか、修復処理で前後の目次情報からの推測で作られたダミー値なのか、を示す。
先頭フレーム時刻３３３は、ペアとなる映像MBblock３４の先頭映像データの映像時刻を示す。
Pack開始アドレス３３４とPack内フレーム数３３５は、１Byte（Octet）のサイズを有し、交互に配置され、映像MBblock内のPACK先頭の相対位置と、フレーム数をそれぞれ示す。注目するPackのサイズ（バイト数）は、そのPACKのアドレスと次PACKのアドレスの差分で求まる。

【0006】

なお、映像MBblock３４のMBblockヘッダ３４１内には、目次情報３３と全く同じデータを保持する、当該映像MBblock目次情報３３−ｂが存在する。
循環記録装置は、映像の記録を映像MBblock３４単位で行う。つまり少なくとも１個の映像MBblock３４分の書込みデータ（目次情報を含む）が揃ってから、それを一度に書込む。一方で目次情報３３の記録デバイスへの書込みは、映像MBblock３４よりも低い頻度で行われる。つまり複数の目次情報３３を一度に纏めて更新する。

【0007】

他の先行技術としては、特許文献４には、映像音声データを複数の映像記録端末に分散して記録することにより、１端末の蓄積媒体への最大記録可能レートに制限されずに複数の映像出力手段からの映像音声データを記録でき、その上、一連の映像音声データを再生可能な最小単位で複数の端末に分散して記録することにより、映像音声データが記録されている端末が故障しても全データが参照できなくなる可能性を抑制することができる発明が開示されている。

【0008】

また、特許文献５には、光ディスクにおけるセクタ群の位置情報を所定の情報量毎に分割し、セクタ群内の複数のセクタに分散して設けるため、オーバーヘッドを低減することができ、また、ディフェクトのような局所的な欠落に対する影響を低減して、位置情報検出の信頼性を高めることができる発明が開示されている。

【先行技術文献】

【特許文献】

【0009】

【特許文献1】特許第４２３７５４９号公報

【特許文献2】特許第４４０１１３２号公報

【特許文献3】特許第４５８３２７０号公報

【特許文献4】特許第４５５４１１１号公報

【特許文献5】特開２０１１−１０３１７４号公報

【特許文献6】米国特許第６６３６８７９号公報

【発明の概要】

【発明が解決しようとする課題】

【0010】

従来の映像記録装置は、映像記録装置が終了処理を実施できずに電源断すると、目次情報と映像データ間で不整合が生ずる事がある。電源再投入時に記録データのチェックを行い、修復が必要な場合には修復を実施するが、修復時間は不定であるため、記録開始までに相当の時間を要することがあった。
本発明の目的は、長時間稼働の映像記録装置において、電源断後の電源再投入から記録開始までの時間を短縮することにある。

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

【0011】

上記目的を達成するため、本発明の映像記録装置は、配置情報領域と映像データ領域を有する記録デバイスを備えた映像記録装置であって、配置情報領域は映像データ領域に記憶している映像データの配置情報を記憶し、映像データ領域は映像データと、映像データの最後尾の目次領域に映像データの目次情報を記憶することを特徴としている。

【0012】

なお、前記目次情報は映像データ領域の目次領域に最古から最新の順に記憶することが好ましい。

【0013】

また、前記目次情報は１映像データ領域に複数個を記憶することが好ましい。

【0014】

また、上記目的を達成するため、本発明の映像記録装置の映像記録方法は、配置情報領域と映像データ領域を有する記録デバイスを備えた映像記録装置の映像記録方法であって、記録デバイスに配置情報領域と映像データ領域を設定し、映像データ領域に映像データと映像データの最後尾の目次領域に映像データの目次情報を記憶し、映像データ領域に記憶している映像データの配置情報を配置情報領域に記憶することを特徴としている。

【0015】

さらに、本発明の映像記録装置の映像記録方法は、上記の映像記録装置の映像記録方法であって、映像データ領域の目次領域に目次情報を最古から最新の順に記憶することが好ましい。

【発明の効果】

【0016】

本発明によれば、電源断後の電源再投入から記録開始までの時間を短縮することができる。

【図面の簡単な説明】

【0017】

【図1】実施例１に係る映像記録装置を含む監視システムの構成図。

【図2】実施例１の映像記録装置のブロック図。

【図3】従来の映像記録装置における記録デバイスの循環型ファイルシステムを説明する図。

【図4】従来の映像記録装置における目次情報３２と映像MBblock３４との関係を説明する図。

【図5】実施例１の記録デバイス１５のファイルシステムを説明する図。

【図6】記録デバイス１５の目次情報４３と映像MBblock３４との関係を説明する図。

【図7】実施例１の映像記録装置の最新映像探索を説明する図。

【図8】実施例１の映像記録装置の目次情報合成を説明する図。

【図9】実施例１の映像記録装置における記録デバイスの高速化を説明する図。

【図10】実施例３の映像記録装置の構成図。

【図11】実施例３の映像記録装置の終了処理のフロー。

【図12】従来の映像記録装置の終了処理のフロー。

【発明を実施するための形態】

【0018】

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

【実施例1】

【0019】

図１は実施例１に係る映像記録装置を含む監視システムの構成図である。
図１の監視システムは、ＮＤＲ（ネットワークデジタルレコーダ）等の映像記録装置１と、カメラ２Ａ，２B，…，２ｍと、ＰＣ（PersonalComputer）３−１〜３−ｎ等の表示操作装置がネットワーク２０を介して接続されている。
ｍ台あるカメラ２Ａ〜２ｍは、映像データをネットワーク２０に配信できるネットワーク型カメラである。
ＰＣ３−１〜３−ｎは、映像記録装置１と、カメラ２Ａ〜２ｍの設定等の制御と、映像記録装置１の録画データの再生等を行う。

【0020】

図２は映像記録装置１のブロック図である。
映像記録装置１は、内部バス１１に、ＣＰＵ（Central Processing Unit）部１０と、メモリ部１２と、ネットワークインターフェイス（ＩＦ）１３と、記録デバイスＩＦ１４が接続している。
メモリ部１２は、メインメモリと、オペレーティングシステム（ＯＳ）等を保持する補助記憶装置（フラッシュメモリ等）とを有する。

【0021】

記録デバイスＩＦ１４には記録デバイス１５が接続されている。記録デバイス１５はＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等であり、ＯＳからブロックデバイスとして扱われる。
記録デバイス１５の中に、論理的な領域を、記録対象とするカメラの分だけ設ける。このカメラ毎の論理的な領域をカメラ領域１６と総称する。図２ではカメラ領域１６は、記録するカメラの数に対応してｍ個のカメラ領域１６−１〜１６−ｍが存在する。
カメラ領域１６は、循環記録を行う。カメラ領域内にアドレスを振り、アドレスの先頭から映像データを書き始め、書き込み先アドレスが末尾に達すると、先頭から順に映像データを上書き記憶していく。

【0022】

図５は、記録デバイス１５のファイルシステムを説明する図である。
図５の記録デバイス１５には、循環型ファイルシステムが構築されている。循環型ファイルシステムは、主に配置情報領域４０と、映像データ領域４２の２領域で構成されている。なお、図５と図３との違いは、目次情報領域を、独立した領域から映像データ領域内に収めるようにした点である。

【0023】

映像データ領域４２は、MBBlockの集合で構成され、各カメラに対応する領域へ分割される。映像データ領域４２内には、カメラＡ用映像データ領域４２−１、カメラＢ用映像データ領域４２−２、カメラＣ用映像データ領域４２−３、空き領域４２−４が存在する。カメラ領域の容量は、各カメラに割り当てたMBBlockの数にMBBlockサイズを乗じたものであり、便宜的にカMBBlockの数をカメラ領域の容量と同義に扱う。

【0024】

配置情報領域４０は、映像データ領域４２内の各映像MBblockの記録位置の情報を保持する。複数の記録デバイスを横断して或いは分散させて記録できるよう、どの記録デバイスの何番目のMBBlockをどのカメラ領域の何番目のMBBlcokへ割り当てたかを特定できる情報を保持しなければならない。前者をデバイス内MBBlock番号、後者をカメラ領域内MBBlock番号と呼び区別する。
本例の循環型ファイルシステムは、初期化時に、記録デバイス１５内を、規定のMBBlockサイズ単位で分割し、先頭を０として昇順にデバイス内MBBlock番号を付与する。同時に使用されうる複数の記録デバイスには数ビットのデバイス番号を付与し、固有番号と対応付けて記憶する。
各カメラ領域においても、カメラ領域内で使用する順序を示す番号として、カメラ領域内MBBlock番号が付与される。カメラ領域内MBBlock番号は、先頭番号は0、末尾の番号は「カメラ領域容量Block数」−１である。映像データの記録時には、カメラ領域内MBBlock番号の順で記録される。

【0025】

不良セクタの存在に無関係に等分割し、先頭アドレスから順に番号付けした場合、デバイス内MBBlock番号は、先頭アドレスと分割サイズ、分割数の情報があれば生成できる。なお、不良セクタは、記録デバイス１５自体のファームウェアの管理によって代替セクターに取って代わられるほか、循環型ファイルシステムによってそれを含む映像MBBlockを使用禁止にすることでも避けられる。
カメラ領域内MBBlock番号も単純に昇順に付与した場合、カメラ領域内MBBlock番号はデバイス内MBBlock番号とのオフセットの情報があれば生成できる。
あるいは、デバイス内MBBlock番号（デバイス番号を含む）とカメラ領域内MBBlock番号との対の全てをテーブルとして保持してもよい。ある特別の値のカメラ領域内MBBlock番号は、対応するデバイス内MBBlock番号が未使用であることを示すために使用されうる。

【0026】

映像MBblock４４は、映像データ領域４２を構成する単位であり、１ＭＢまたは１ＭＢの２の倍数の固定長のサイズを有し、符号化レートにも依るが約150フレーム程度の映像データを格納する。格納はフレーム単位で行い、１フレームの映像データが複数の映像MBblock４４に跨ることはない。この単位をメガバイトまで大型化したことで、複数のカメラ映像の同時記録や読出しを行う際に、単位内のセクタを連続的に読み出せシーク回数が減ることで、パフォーマンス（同時記録数、寿命等）が向上する。仮にPackというサブブロック構造を有しないとしても、映像MBblock４４の末尾には、１フレームのサイズに満たないような余りが生じうる。
本例では、カメラ領域内のMBBlockを、カメラ領域内MBBlock番号順に、先頭から使用していき、末尾に達した際、また先頭からMBBlockを使用することで循環書き込みが実現される。
ここで、通算MBBlock番号という概念を導入する。これはカメラ領域内の通算のMBBLock番号であり、カメラ領域が作成されてから、何番目に書き込まれたMBBLockかの番号を示し、格納先のMBBlockの更新等に影響されない。

【0027】

図６は、記録デバイス１５の目次情報４３と映像MBblock３４との関係を説明する図である。
なお、図６と図４との違いは、映像MBblock４４の末尾に、目次領域を設けた事が異なる。

【0028】

目次情報４３は、映像MBblock４４の目次となる情報であり、１つの映像MBblock４４に対し１つの目次情報４３が存在する。目次情報４３内には、先頭フレーム番号４３１、フラグ領域４３２、先頭フレーム時刻４３３、Pack開始アドレス４３４−１〜４３４−Ｑ、Pack内フレーム数４３５−１〜４３５−Ｑで構成する。Ｑは映像MBblock当たりのPack（後述）の最大数であり、この例では１０とする。
先頭フレーム番号４３１は、ペアとなる映像MBblock４４の先頭映像データのフレーム番号（通算フレーム番号）を示す。この通算フレーム番号は、映像データ領域４２を作成した時を０とした単調増加の値である。

【0029】

フラグ領域４３２は、状態を示すフラグを記憶する。状態は、ペアとなる映像MBblockが存在するか、目次情報がダミー値なのか、を示す。
先頭フレーム時刻４３３は、ペアとなる映像MBblock４４の先頭映像データの映像時刻を示す。
Pack開始アドレス４３４とPack内フレーム数４３５は、１Byte（Octet）のサイズを有し、交互に配置され、映像MBblock内のPACK先頭の相対位置と、フレーム数をそれぞれ示す。映像MBblock内のPACKのアドレスと、フレーム数を示す。Packのバイト数は、注目PACKのアドレスと次PACKのアドレスの差分で求まる。

【0030】

一方、映像MBblock４４は、MBblockヘッダ４４１と、複数のフレームデータ４４２と、Pack４４３−１〜４４３−５で構成する。
MBblockヘッダ４４１は、目次情報４３と同じ内容を有する当該映像MBblock目次情報４３−ｂと、通算MBBlock番号とを保持する。

【0031】

フレームデータ４４２は、録画映像データの１単位であり、MBblockヘッダ４４１に続けて、符号化順のまま詰めて配置される。MBblock４４内は１０程度の領域にサブブロック化する。このサブブロックをPack４４３と呼称する。サブブロック化は映像データ読み出し時に、特にランダムアクセスに対して有効に働く。Pack４４３の境界は、できるだけGOV境界（IピクチャやIDRフレーム）と一致するように選ぶこともできる。再生アプリによる制御の容易性を考慮すると、Packは、単純に一定のフレーム数或いは時間の基準で区切られうる。その場合、映像MBblock４４は、映像データで十分埋められないままPack数の上限に達し、その末部に大きな未使用領域が残されうる。
なおPack４４３の境界は、Pack開始アドレス４３４が８ビットであるがために、映像MBblockのサイズの1/256の単位でのみ選ぶことができ、また当然（物理的な）セクタサイズの単位の制約も受けるため、実際のPack４４３の末尾には図示しない小さな未使用領域が存在する場合がある。

【0032】

本例の特徴として、映像MBblock４４内の後端にある目次領域４４３−５は、末尾目次情報４５を格納する。
目次領域４４３−５は、目次情報４３においてはPackの一種として扱われ、対応するPack開始アドレス４３４−５が保持されている。対応するPack内フレーム数４３５が“０”の場合は、Packが目次領域であることを示している。

【0033】

MBblock内目次領域４５はその内部に、複数個の映像MBblock４４に対応する複数の目次情報４３を記録順に連続的に配置する。
先頭に位置する最古目次情報４３−ｃは、過去映像MBblockの目次情報であり、そのMBblock内目次領域４５に格納されるものとしては最も古い。末尾に位置する最新目次情報４３−ｄは、MBblock内目次領域４５に格納されるものの中では最新の目次情報である。

【0034】

本例では、最新目次情報４３−ｄは、その映像MBblock４４の作成時に最新のMBblock（つまりその映像MBblock４４自体）の目次情報とし、最古目次情報４３−ｃは、MBblock内目次領域４５に格納できる範囲で最も古い目次情報とする。このとき、MBblock内目次領域４５のサイズを１個の目次情報のサイズ（３２Byte）で除算した数が、そのMBblock内目次領域４５に格納できる目次情報４３の個数を表す。
また、目次情報４３−ｄは目次情報４３−ｂと同値となる。そのため、映像データの読み出し時、目次情報４３−ｂと４３−ｄが同値でなければ、該映像Block４４は途中までしか書き込まれなかった異常な状態であると判定できる。

【0035】

なお、MBblock内目次領域４５の最後尾には、図示しない、３２Byteに満たない領域が残されうる。
また、目次領域４４３−５は、全てのMBblock内目次領域４５にそれぞれ設ける必要は無く、間欠的に設けてもよい。目次領域４４３−５には数千から数万個分の映像MBblock４４の目次情報を格納でき、間欠的に設けても十分冗長性を確保できる。結果的に、従来の目次情報領域３１に相当する情報が、分散的かつ冗長的に記録されたことになる。

【0036】

図７は、実施例１の映像記録装置１の最新映像探索を説明する図である。本例の映像記録装置は、起動時または再起動時に、記録デバイス１５に記憶されている各カメラ領域から最新MBblockを探索し、従来の目次情報領域３１に相当する目次情報をメモリ部１２内で合成する。これにより、カメラ領域内のどこにいつの映像データがあるか検索可能としている。
最新MBblockの探索する方法は、まず、カメラ毎の映像領域４２−aを、例えば、１１等分してサンプリングポイント５１−ｔ０〜５１−ｔ１０を決定する。サンプリングポイント５１は、映像MBblock４４の先頭を指し示すよう整列される。
記録デバイス１５からサンプリングポイント５１に基づいて１１個の映像MBblock４４にアクセスし、ヘッダ４４１内の当該MBblock目次情報４３−ｂを読み出す。

【0037】

その結果、例えば、ｔ２の目次情報のフレーム番号が最大だったとする。その場合、ｔ２〜ｔ５の区間で二分探索を行い、フレーム番号最大（最新MBblock）を探索する。
ｔ２（最大）とｔ３（最少）の間で二分探索を行わないのは、ｔ３のブロックが書き換わっていなく、ｔ３〜ｔ４の区間にフレーム番号最大がある場合を疑うからである。ｔ２〜ｔ４の区間での二分探索では、初回がｔ３になり、ｔ３を疑う意味がない。このため、ｔ２〜ｔ５の区間で二分探索を行う。

【0038】

図８は、実施例１の映像記録装置１の目次情報合成を説明する図である。
最新MBblockの特定後、ターン１が実行される。バーで示したアドレス空間４２−aは、カメラ領域４２のリング状の記録構造を、特定された最新映像MBblockの位置で切り開いたもので、左端がおおよそ最古の映像、右端がおおよそ最新の映像に対応する。

【0039】

ターン１では、特定された最新映像MBblock４４−１を、記録デバイス１５のカメラ領域４２−aから読み出す。最新映像MBblock４４−１は、MBblock内目次領域４５−１（以下、単に目次領域と呼ぶ）を含んでいる。
メモリ部１２に設けられる合成目次領域６に目次領域４５−１の目次情報を書き込み、読み出し済み目次領域６１−１とする。

【0040】

次に、目次領域６１−１の目次情報を用いて、次ターンに読み出す映像MBblockを選択する。目次領域６１−１内の各目次情報からは、それぞれ、ペアとなる映像MBblockに含まれる目次領域の大きさと目次領域先頭目次情報４５１の古さが求まる。比較していき、最も古い目次情報４５１をもつ映像MBblockを、次ターンで読み出す映像MBblockとする。

【0041】

ターン２では、まず、前ターンで選択した映像MBblockを読み出す。読み出した映像MBblock４４−２に含まれる目次領域４５−２から目次領域６１−２を取得する。そして、メモリ上合成目次領域６に目次領域６１−２を書き込むことで、目次情報を合成する。
この動作を最古に達するまで繰り返す。
すなわち、最新映像MBblockの目次領域から過去方向に遡りながら、メモリ上合成目次領域６に目次情報を書き込むことにより、カメラ領域分の目次情報を合成できる。

【0042】

図９は、実施例１の映像記録装置１における起動処理の高速化を説明する図である。
目次優先MBblock４４−ｂは、ヘッダ４４１と映像Pack４４３−ｂと目次領域で構成されている。通常のMBblock４４では、映像Pack４４３を１０程度格納した残りに目次領域を配置するが、目次優先MBblock４４−ｂでは、目次情報を主に格納する事を目的に、映像Pack４４３を１個とし、残りの領域を目次領域とする。なお４４−ｂは、映像Pack４４３なしで全てを目次領域としてもよい。

【0043】

この特別な目次優先MBblock４４−ｂは、カメラ領域４２−ｂ内に規定の位置に配置される。例えば、映像の録画（記録）時、カメラ領域４２−ｂに等間隔に設けられるポイント５２−Ｐ１〜５２−Ｐ６に、目次優先MBblock４４−ｂは配置される。この間隔は、１つの目次優先MBblock４４−ｂが含むことができる目次情報４３の数に依存する。例として、ポイント５２−Ｐ６の目次優先MBblock４４−ｂの目次領域内の最古の目次情報が、ポイント５２−Ｐ５となるのが好ましい。仮に目次優先MBblock４４−ｂが28672個の目次情報を常に含む場合、ポイント５２の間隔も28672（MBblock４４の28672個分）となる。

【0044】

このように、目次優先MBblock４４−ｂは、カメラ領域４２−ｂに必要最小限の個数で書き込まれる。これにより、目次情報合成時の記録デバイス１５へのアクセス回数が減り、高速化が図れる。もし、目次優先MBblock４４−ｂのいずれかが破損していた場合、図８で説明した、目次領域４４３−５を含んだ通常の映像MBblock４４を辿っていく方法に切り替えて、目次の合成を継続できる。

【0045】

本実施例１の映像記録装置は、終了処理を必要とせず、起動時の所要時間を一定とする、改良型循環型ファイルシステムを実現することができる。

【実施例2】

【0046】

本実施例２の映像記録装置は、各カメラ領域における目次優先MBBlockの配置間隔等の管理情報を、明示的に備えた点などで実施例１と異なる。
本実施例２は、概略的に述べると、各カメラ領域の管理情報として少なくとも、容量変更時点での最古の映像データを格納したMBBLock番号と、目次優先MBBlockの配置間隔と、の2つの値を持つ。上記２値は、カメラ領域の「新規作成」or「容量サイズ変更」を行った際に、算出し格納する。
また、録画アプリ稼働中の映像記録時に、上記２値を用いて「目次優先MBBlock」の格納箇所かを判定する。該当箇所であれば、目次優先MBBlockを格納する。
その後、録画或いは再生アプリ起動時には、各カメラ領域毎に、上記２値を用いて目次優先MBBLockを読み出して、カメラ領域の目次領域を合成する。これにより処理の単純化と、記録デバイスの読み出し回数の低減により高速化を、実現する。

【0047】

［目次優先MBBlockの配置間隔の算出方法］
本例で用いるカメラ領域毎の管理情報の構造体を表１に示す。管理情報は、記録デバイス１５の所定の場所に保持され、例えば、従来の目次情報領域３１のような独立した領域を設けてもよく、配置情報４０内に含めてもよく、空き領域４２−４内の未使用の映像MBBlockに格納してもよい。

【表1】

【0048】

本例では、目次優先MBBlockは、任意のカメラ領域内に一定間隔で配置し、その位置は記録が循環しても不変とする。カメラ領域内の目次優先MBBlockの配置の基点は、以下の規則で決定する。
カメラ領域のサイズ変更が行われてない時は 0,
カメラ領域のサイズ変更が行われている時は、
カメラ領域のサイズ変更直後の、最古MBBlockの「通算MBBlock番号」とする。

【0049】

目次優先MBBlockの配置の間隔（”Interval_IndexMBBlock”）は、カメラ領域の容量確保時またはカメラの容量変更時に算出し、カメラ領域の管理領域に格納する。具体的には、表１の４項目以下の式を用いて、カメラ領域の容量（NumOf_MBBlocks)とMBBlockのバイトサイズ（MBBlock_Size）と目次情報のバイトサイズ（Index_Size）から算出される。ただし最小値は4とする。
表１中のtmp_IndexMBBlocksの定義は、サンプリング点を、目次優先MBBlock内の最古の目次情報が、２つ前の目次優先MBBlockと重なる間隔とすることを意図している。2つ前の目次優先MBBlockと重ねる理由は、目次優先MBlcokが１つ破損していても、前又は後の目次優先MBBlockから、目次情報を補間できるようにするためである。

【0050】

ＣＰＵ１０により実行される録画アプリは、映像データの格納時、以下の式で、記録先が目次優先MBBlockであるか否かを判定する。ただし記号「%」は剰余を示す。
判定値=((現MBBlockの通算MBBlock番号 - 基点)% NumOf_MBBlock)%(Interval_IndexMBBlock)
判定値が0の時は、目次優先MBBlockとする。
判定値が0以外の時は、映像データMBBLockとする。

【0051】

［録画アプリの起動時の処理］
録画アプリの起動時あるいは起動前に、録画アプリ自身或いはＯＳによって、メモリ部１２上に、表１の構造体１２Ａと、カメラ領域の目次領域１２Ｂと、カメラ領域の目次領域の個々の目次情報が読み込み済みかを示すフラグ配列１２Ｃとが、確保される。
その後、実施例１におけるターンに相当する以下の複数の処理を実行する。

【0052】

［処理１：起動時サンプリング］
起動時には、基点から一定間隔でMBBlockを読み出す。この処理を起動時サンプリングと呼ぶ。起動時サンプリングの開始のカメラ領域内MBBlock番号は、サンプリング開始点と呼ばれ、以下の式で決定される。
サンプリング開始点=「基点」%NumOf_MBBlock基点が０であれば、サンプリング開始点も０である。

【0053】

サンプリングは、iを初期値が0のループ変数としたときに、((Interval_IndexMBBlock)×ｉ < カメラ領域容量MBBlock数)を満たす間、行われる。
iの時にサンプリングで読み出すカメラ領域内MBBlock番号を、「サンプリング点i」と呼び、以下の式で定まる。
サンプリング点ｉ = (サンプリング開始点 + (Interval_IndexMBBlock)×i)% NumOf_MBBlock.
配置情報４０を参照することで、カメラ領域内MBBlock番号は、適宜デバイス内MBBlock番号やＬＢＡ（論理ブロックアドレス）等に変換され、MBBlockへのアクセスが可能になる。サンプリング点のMBBlockが全て空(無効)の時は、該カメラ領域は未書き込みと判断する。

【0054】

録画アプリを実行するＣＰＵ１０は、MBBlockを読み出す都度、MBBlock末尾の目次領域の目次情報を検査し、条件を満たせば、カメラ領域の目次領域１２Ｂに格納する。検査は下記の規則により行う。

【0055】

定義
(B)：読み出したMBBlock.
(Bi):(B)末尾の目次領域内の注目する目次情報.
(Ci): 目次情報(Bi)に対応する位置の、「カメラ領域の目次領域」内の目次情報.
(fi):「カメラ領域のフラグ配列」の(Ci)に対応するフラグ値.
(B_通算MBBlock番号):(B)の通算MBBlock番号. 読み出した（B）のヘッダ領域に格納されている.
(Bi_通算MBBlock番号):(Bi)が指し示す通算MBBlock.
tmp_Bi = (Bi)の格納位置が、(B)の何個前かの値. ただし(B)の目次領域内の末尾は、(B)の目次情報である.
(Bi_通算MBBlock番号) = (B_通算MBBlock番号) - tmp_Bi.

【0056】

規則：下記２つの条件を両方満たすとき、(Bi)を(Ci)の位置に格納する。その際には、(fi)を1とする。
[基点] <= (Bi_通算MBBlock番号),
((fi)==0)または((Ci)の通算フレーム番号<(Bi)の通算フレーム番号).

【0057】

これにより、各サンプリング点iは、記録時の目次優先MBBlockをちょうど指し示し、それらを読み出すことで、サンプリング点間の目次情報は取得できる。ただし、どこが真に最新なのかはまだわからない。

【0058】

［処理２：最新MBBlock探索のための二分探索］
処理２では、実施例１と同様にサンプリング点での最新と、その３つ後ろのサンプリング点間で、最新MBBlockを二分探索する。ただし、この探索の間も、MBBlockの読み出し時に、MBBlock末尾の目次領域を、カメラ領域の目次情報に格納（上書き更新）する。

【0059】

［処理３：フラグ配列を最新から最古の方向で探索］
フラグ配列を走査し、未読込の箇所を発見した際に、該当箇所のMBBlockを記録デバイスから読みだし、MBBlock末尾の末尾目次情報４５（もしあれば）或いは該MBlock目次情報４３−ｂを、カメラ領域の目次領域の目次情報へと格納する。

【0060】

本発明の実施形態である映像記録装置は、初期サンプリングで読み出す MBBlockを目次優先MBBlockとなるようにし、初期サンプリングだけで目次情報の読み出しが終わり、後の処理はメモリ上で行うことができる、記録デバイスへのアクセス回数を削減し、電源断後の電源再投入から記録開始までの時間を更に短縮することができる。

【実施例3】

【0061】

先の実施例１や２において、記録中に電源を切断すると、記録アプリ等によるバッファ、あるいはＯＳのバッファは遅延書込みによりメモリ上に保持されていた数秒分の映像データは、記録デバイスに書き出されることなく消失する。
本実施例３の映像記録装置は、実施例１や２に、正規の終了処理自体を高速化する構成を追加したものである。

【0062】

まず、正規の終了処理に時間がかかる理由を説明する。図１２に、POSIX系ＯＳにおける通常の終了処理のフローを示す。
従来の記録装置は、動作しているリアルタイムOSが動作させているプロセス(アプリケーション)をひとつずつ終了させて、全てのアプリケーションが終了した後に電源を切断する。この全てのアプリケーションを終了させる処理が時間を掛けている要因となっている。記録媒体にデータを書き込むためのアプリケーションとログを書き込むアプリケーションもこの終了プロセスの中の一つである。

【0063】

従来の記録装置で終了処理中に電源断を行ってしまうと記録媒体の書き込み及びログ書込みのアプリケーションが終了する前に電源が落ちる場合があるため、再起動後には直前のデータが記録媒体に書き込まれていない為、記録データがないとか途中までしかデータを書き込んでいないので、データとの整合性が取れず、データが破損してしまう等の問題が発生する。
記録装置においては記録媒体に書き込みを行うこととログを書き込むことが最重要であり、他のアプリケーションは基本的に途中で止まっても再起動を行えば最初から動き始めるので問題ない。

【0064】

図１０に、本実施例３の映像記録装置の構成図を示す。本例の映像記録装置は、記録媒体にデータを書き込む等の主用で動作しているメイン基板１０１、メイン基板１０１へ電源供給する電源部１０２、メイン基板１０１への電源供給を制御する電源制御基板１０３、メイン基板１０１を介して電源供給されるネットワーク制御回路１０４および記録デバイス１０５、電源SW１０６を備える。メイン基板１０１と電源制御基板１０３との間は、シリアル通信路Ｃ等で接続される。

【0065】

メイン基板１０１は、多機能を実現するためにデータの処理部にＣＰＵが採用され、各データの通信はＳＣＨ(System Control Hub)を用いてやり取りされる。CPUは、ネットワークを介して撮像装置から送出された画像データ(デジタルデータ)を読み取り、記録装置に格納する。さらにCPUは所定のタイミングで伝送媒体によりデータの送受信を制御するネットワーク制御回路１０４に転送する。ネットワーク制御回路１０４は、フォーマッティングされた圧縮画像データをネットワークの通信プロトコルに対応したフォーマットに再構成したデータに変換してネットワークに送出する。

【0066】

電源部１０２は、供給される交流電力を、低電圧直流に変換するスイッチング電源等である。交流電力の供給を受けている間、常に電源制御基板へ電源供給する。

【0067】

電源制御基板１０３は、マイコンや表示器、スイッチ類等を備えた基板であり、外部(使用者)からの命令を受けて、メイン基板１０１に終了処理命令信号を送る他、メイン基板１０１からの終了処理信号或いは電源制御基板１０３自身の判断により、メイン基板１０１への電源供給を切断する。また、メイン基板１０１からの終了処理信号やエラー通知信号等を受け取ると、外部に通知（表示）を行う。
外部に通知する信号は、メイン基板１０１から発信（表示）することも可能であるが、スタンバイ状態(電源供給はされているが記録装置として機能しておらず、最低限の電気だけで動作している状態)の場合は、任意の通知をすることはできない。そこで、電源制御基板１０３に常に電気が供給されているようにし、代わりにメイン基板１０１への電源供給は完全に遮断する。電源制御基板１０３の消費電力は、電源制御基板１０３のスタンバイ状態のそれとほとんど変わらず省電力であるため、実運用上では問題にはならない。
メイン基板１０１に供給する電源を切断するには、マイクロプロセッサからの制御が必要だが、電源を切断するには電力が微小であるため、微小信号を受け取って電気経路を機械的に開閉するスイッチ（ラッチングリレー）を用いる場合と、FET(Field Effect Transistor)を用いて切断する方法が適用できる。終了処理信号を受取って直ちに遮断してもよいし、タイマーで所定時間遅らせてもよい。

【0068】

ネットワーク制御部１０４は、外部から送られてくるEthernet（商標）に準拠したデジタルデータを受信しメイン制御に送る他、メイン基板から送られてくるデジタルデータを外部へ送信する役目を行う。

【0069】

記録デバイス１０５は、ネットワークを介して送られてきた画像データを記憶する他、メイン基板１０１から画像データを要求された場合、自身からデータを抽出しメイン基板１０１に送信する。本装置に搭載する記録媒体は、電子記録媒体である。

【0070】

電源SW１０６は、映像記録装置に起動又は終了を通知するスイッチである。一般に記録装置の電源SWは物理的に電気を切断するものではなく、電源終了の信号を外部からの行動によってメイン基板１０１に通知することで、メイン基板１０１のリアルタイムOSが動作中のアプリケーションおよびそれ自身を終了させる。そのとき発せられるシステムコールはBIOSに引き継がれ、メイン基板１０１をスタンバイ状態(次に電源SWが押下されて起動の信号を受理するまで待機)に移行させる。

【0071】

図１１に、本実施例３の映像記録装置の終了処理のフローを示す。構成図を示す。
本例の終了処理においても、Ｓ１６として、ランレベル 0に対応するスクリプト（rcスクリプト）が実行されるが、スクリプトの内容は、システム時刻のハードウェア時計への書き込み、記録デバイスのアンマウント、及び、ロギングプロセス（syslogd等）を（正常）終了させることのみである。ここで映像の記録デバイス１０５と、ログファイルが書き込まれるディスク（パーティション）が別々であれば、アンマウントとログ書込みに順序は無く、同時に行うこともできる。なおアンマウントには通常、カーネルによるキャッシュをディスクに書き出させるsync処理を含む。

【0072】

その後、Ｓ１７として、シリアルデバイス（tty）等を通じて、電源制御基板１０３へ終了処理完了通知を行う。これは数バイト程度の簡易な電文でよい。なおこの終了処理完了通知を行うコマンドを、rcスクリプトに記載してもよい。
Ｓ１８において、終了処理完了通知が電源制御基板１０３で受信されれば、Ｓ１９として、メイン基板１０１へ供給している電源が遮断される。Ｓ１７の終了処理完了通知を行うコマンドの後ろに、rcスクリプトの続きがあったとしても、強制的に電源ＯＦＦされるため、それらは実行されないだろう。
組込みＯＳの分野では、システム（ＯＳ）のディスク（パーティション）が、リードオンリーでマウントされることが多い。その場合、システムディスクをアンマウントせずに電源断されても、悪影響はない。

【0073】

正常に機器を短時間で終了させることができるので、メンテナンスや保守等の作業時間が減るため作業費用が削減できることと機器としての信頼性及びシステムとしての品質も向上も確保できる。

【産業上の利用可能性】

【0074】

本発明は、ファイルシステムが利用された記録媒体に、データを恒常的に記録する装置に利用でき、特に電源を突然遮断される、或いは遮断の通知があってからごく短時間で安全にシャットダウンする必要のある、車載の記録装置等に好適である。

【符号の説明】

【0075】

１：映像記録装置、 ２Ａ〜２ｍ：カメラ、 ３−１〜３−ｎ：ＰＣ、 ２０：ネットワーク １０：ＣＰＵ部、 １１：内部バス、 １２：メモリ部、 １３ネットワークＩＦ、 １４：記録デバイスＩＦ、 １５：記録デバイス、
１０１：メイン基板、 １０２：電源部、 １０３：電源制御基板、 １０４：ネットワーク制御部、 １０５：記録デバイス、 １０６：電源SW。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】