JP4481889B2 - データ記録装置及びその方法、プログラム、記録媒体 - Google Patents

Description

本発明は比較的長時間にわたるマルチメディアファイルの記録に好適なデータ記録方法および装置およびプログラムに関する。

近年、動画・音声符号化形式の多様化にともない、様々な形式を均一的な枠組みの中で相互接続可能な形で処理出来るようにする必要性が高まってきている。そこで、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ／Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ）によって、ＭＰＥＧなどの動画・音声のコンテンツデータをファイルに記録するために「ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ」という汎用のファイル形式が規格化されている（非特許文献１参照）。

このファイル形式は特定の符号化形式を前提とはしていない基本ファイル形式として定義されており、所定の符号化形式や目的に適合させるにはこの規格を部分的に拡張した規格を別途定義することによって対応するといった特徴を持っている。その拡張の代表例として、ＭＰＥＧ−４の動画・音声符号化データを記録するための標準ファイル形式である「ＭＰ４ファイル形式」（非特許文献２参照）のようなものがある。また、同じくＭＰＥＧ−４の動画・音声を扱う形式であるが、第三世代携帯電話を中心とする無線端末上での利用を前提に制約が課せられた動画ファイル規格として、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）によって定められた３ＧＰＰファイル形式（非特許文献３参照）のようなものもある。

近年では、デジタルカメラや携帯電話などの機器で動画・音声データをＭＰＥＧ−４形式で符号化してファイルに記録する際の記録形式として、上記のようなファイル形式を採用するケースが増えてきており、今後更に普及するものと考えられる。
ＩＳＯ／ＩＥＣ １４４９６−１２；"Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−−Ｃｏｄｉｎｇ ｏｆ ａｕｄｉｏ−ｖｉｓｕａｌ ｏｂｊｅｃｔｓ−−Ｐａｒｔ １２：ＩＳＯ ｂａｓｅ ｍｅｄｉａ ｆｉｌｅ ｆｏｒｍａｔ"；ＩＳＯ／ＩＥＣ；２００４−０１−２３ ＩＳＯ／ＩＥＣ １４４９６−１４；"Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−−Ｃｏｄｉｎｇ ｏｆ ａｕｄｉｏ−ｖｉｓｕａｌ ｏｂｊｅｃｔｓ−−Ｐａｒｔ １４：ＭＰ４ ｆｉｌｅ ｆｏｒｍａｔ"；ＩＳＯ／ＩＥＣ；２００３−１１−２４ ３ＧＰＰ ＴＳ ２６．２４４"Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｓｙｓｔｅｍ Ａｓｐｅｃｔｓ Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ−ｔｏ−ｅｎｄ ｐａｃｋｅｔ ｓｗｉｔｃｈｅｄ ｓｔｒｅａｍｉｎｇ ｓｅｒｖｉｃｅ （ＰＳＳ）；３ＧＰＰ ｆｉｌｅ ｆｏｒｍａｔ （３ＧＰ） （Ｒｅｌｅａｓｅ ６）"３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ；２００３−０２−２８

ＭＰＥＧ−４は比較的高圧縮な符号化方式であり、ストリーミング配信などにおいてもエラー訂正技術などにおいて優れていることから、記録データの蓄積も考慮した監視カメラ（監視ビデオ）などへの応用も進められている。そこで、監視映像及び音声の蓄積に注目すると、長時間の監視映像及び音声を記録メディアに残したいというニーズに対しては、記録メディアに十分な容量が用意されていない場合、記録メディアの容量を使い切った時点で記録を終了されていた。

最新のデータは残しておきたいというニーズに対しては、ファイルを分割して記録するなどして、容量が足りなくなったら古いデータを削除して新しいデータを追記するような処理方法が考えられるが、この処理方法で最新のデータを記録メディアに残す場合、ファイルがバラバラで記録されるためハンドリングを良くするためにプレイリストなどで対応付けする手法などが考えられる。しかし、この場合、他の再生処理系にデータを移動した場合にプレイリストの機能が使用できないなど、データの汎用性やハンドリングの点で問題が発生する可能性が高い。

このように、監視ビデオのように比較的長時間の動画像や音声データを、容量に限りのある記録メディアに最新のデータを優先して記録する場合には、記録したデータの扱いの点において、汎用性やハンドリングなどの点で問題があった。

本発明は前記の問題を解決するため、容量に限りのある記録メディアに、最新のデータを優先して残すように記録することが可能で、尚且つ記録したデータの汎用性を損なわない技術を提供することを目的とする。

上記の目的を達成するため、本発明に係るデータ記録装置は、動画像データと音声データのうち少なくとも１つのメディアデータを記録するデータ記録装置であって、前記メディアデータをフラグメント単位で記録する記録手段と、前記フラグメントを時系列順に連結する連結手段と、前記動画像データあるいは音声データに閾値を超える変化があった場合、前記閾値を超える変化があった動画像データあるいは音声データのメディアデータのフラグメントに、変化があったことを示すフラグをセットする設定手段と、前記フラグメントが前記記録手段によりクラスタ境界から記録されるように制御すると共に、前記記録手段により記録されたデータ容量が所定のデータ容量に達したあとに記録されるフラグメントが、前記記録手段により記録済のフラグメントであって前記変化があったことを示すフラグがセットされていないフラグメントのうち記録順序が最も古いフラグメントが記録されたクラスタ境界から記録されるように制御する記録制御手段と、前記記録手段により記録されたデータ容量が前記所定のデータ容量に達したあとに前記メディアデータの先頭のフラグメントに上書きでフラグメントを記録した場合、当該フラグメントの記録後に記録されているフラグメントのうち記録順序が最も古いフラグメントのヘッダ情報を先頭のフラグメントであることを示す形式のヘッダ情報に変換するヘッダ変換手段と、前記ヘッダ変換手段によって変換されたヘッダ情報と、前記記録手段によりクラスタ境界から記録され前記連結手段により時系列順に連結されたフラグメントとに基づいて、ファイルを生成するファイル生成手段とを有する。

また本発明に係るデータ記録方法は、動画像データと音声データのうち少なくとも１つのメディアデータをフラグメント単位で記録手段に記録するデータ記録装置が行うデータ記録方法であって、前記フラグメントを時系列順に連結する連結工程と、前記フラグメントが前記記録手段によりクラスタ境界から記録されるように制御すると共に、前記記録工程により記録されたデータ容量が所定のデータ容量に達したあとに記録されるフラグメントが、前記記録手段により記録済のフラグメントのうち記録順序が最も古いフラグメントが記録されたクラスタ境界から記録されるように制御する記録制御工程と、前記記録手段により記録されたデータ容量が前記所定のデータ容量に達したあとにフラグメントを記録した場合、当該フラグメントの記録後に記録されているフラグメントのうち記録順序が最も古いフラグメントのヘッダ情報を先頭のフラグメントであることを示すヘッダ情報に変換するヘッダ変換工程と、前記ヘッダ変換工程によって変換されたヘッダ情報と、前記記録手段によりクラスタ境界から記録され前記連結工程により時系列順に連結されたフラグメントとに基づいて、ファイルを生成するファイル生成工程とを有することを特徴とする。

本発明によれば、容量に限りのある記録メディアに長時間の動画像及び音声を記録する場合などに、最新のデータを優先して、汎用性に優れたファイル形式で記録することが可能になる。

以下、本発明の実施形態を、図面を参照しながら詳細に説明する。

なお、本発明の実施形態は処理対象のファイルがＭＰ４ファイル形式である場合を中心に解説しているが、ＭＰ４に限らず類似のファイル形式を用いるケースに対しても適用できる。例えば、ＩＳＯではＭＰ４と同様の基本構造を持つファイル形式規格として、「Ｍｏｔｉｏｎ ＪＰＥＧ ２０００ファイル形式」（ＩＳＯ／ＩＥＣ １５４４４−３）や、「ＡＶＣファイル形式」（ＩＳＯ／ＩＥＣ １４４９６−１５）といった標準規格が制定されている。これらの標準規格や、前述の３ＧＰＰファイル形式など、ＭＰ４で規定されるものと類似のファイル形式およびアーキテクチャが採用されている規格に対しても、本発明の一部あるいは全部を適用することが可能である。

図１は、上記のＭＰ４ファイル形式におけるデータ構造を説明するための概念図である。

ＭＰ４ファイル１０１は、映像・音声データの物理的位置、時間的位置や特性情報を示すメタデータ（ヘッダ情報）１０２と、符号化された映像・音声データの実体を示すメディアデータ１０３から構成されている。

ＭＰ４形式では、コンテンツ全体のプレゼンテーションを「ムービー」、コンテンツを構成するメディアストリームのプレゼンテーションを「トラック」と呼んでいるが、メタデータ１０２には、典型的には、動画像のデータ全体を論理的に取り扱うビデオトラック１０４と音声のデータ全体を論理的に取り扱うオーディオトラック１０５が含まれており、ビデオトラック１０４とオーディオトラック１０５の基本的な構成内容は、ほとんど同等のものとなっている。

すなわち、それぞれのトラックは、実際のメディアデータの様々なメタデータ情報を記録しており、その内容がメディアデータの特性に応じて多少異なっているだけである。

ビデオトラック１０４に含まれるデータは、例えば、符号化データを復号化するための所謂デコーダの構成情報や動画像の矩形サイズなどの情報が含まれ、加えて、メディアデータが実際に記録されているファイル上の位置を示すオフセット１０６や、メディアデータのそれぞれのフレームデータ（ピクチャと呼ばれることもある）のサイズを示すサンプルサイズ１０７、それぞれのフレームデータのデコード時間を示すタイムスタンプ１０８などが記録されている。

一方、メディアデータ１０３には、符号化データの基本単位を示す「サンプル」が連続して１つ以上記録されている「チャンク」と呼ばれるデータ構造により、動画像のデータと音声のデータの実体が記録されている。このチャンクは、メタデータ１０２のトラックに従って、動画像のメディアデータを含むビデオチャンク１０９と音声のメディアデータを含むオーディオチャンク３１０とにより構成されている。

図１に示す構成は、ビデオチャンク１０９とオーディオチャンク３１０が交互に記録されているように示しているが、その記録位置や順序は必ずしもこのようになっている必要はない。この例は、一般的に記録される形式の一例に過ぎない。しかしながら、このような交互の配置（インターリーブ）は、ほぼ同時刻に再生されるべき動画と音声のデータを近い位置に配置することにより、ファイルに記録されたデータのアクセス性を高めるといった効果があり、極めて一般的に見られる方法である。

チャンクには、個々のメディアデータのサンプルがひとつ以上含まれている。例えば、図１に示すように、ビデオチャンク１０９には、ビデオサンプル（フレーム）３１１が連続して記録される。一般的には、このビデオサンプル（フレーム）３１１は、ビデオのひとつのフレームデータ（ピクチャ）に相当する。

それぞれのトラックとチャンクは次のように関連付けられている。

例えば動画像のデータの場合、ビデオトラック１０４に含まれる情報は、メディアデータ１０３に含まれるそれぞれのビデオチャンク１０９に関する情報を含んでいる。

オフセット１０６は、ビデオチャンク１０９のそれぞれのファイル上の相対位置を示す情報のテーブルから構成されており、テーブルの個々のエントリを参照することにより、どの位置に実際のビデオチャンクが記録されていてもその位置を知ることができるようになっている。

サンプルサイズ１０７は、複数のチャンク内に含まれる複数のサンプル、すなわちビデオのフレームのそれぞれのサイズをテーブルとして記載している。より正確には、個々のチャンクの中に含まれるサンプルの数を記載した情報もビデオトラック１０４の中に記載されており、これらの情報から、個々のビデオチャンク１０９の中に含まれるサンプルを正確に取得することが可能となっている。

タイムスタンプ１０８は、個々のサンプルのデコード時間をサンプル間の差分としてテーブルに記録するようになっている。このテーブルを参照することにより、それぞれのサンプルの所謂タイムスタンプを積算時間を計算することにより取得することが可能となる。

このような、トラックとチャンクの関係は、オーディオトラック１０５とオーディオチャンク３１０についても同様に成立するよう定義されている。

これによって、ＭＰ４ファイルおよびＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔにおいては、メタデータ１０２とメディアデータ１０３により、符号化データを必要な単位で任意の位置からタイムスタンプなどの付加情報を持って取得することが出来るようになっている。

なお、説明を簡単にするために、ここには規格化されているすべての記録情報については記載していないことに注意しなければならない。規格化されている定義内容の詳細は、ＩＳＯ／ＩＥＣ １４４９６の該当部分を参照することで知ることができる。

ＭＰ４ファイル形式では、ファイルに記録されるデータは「ＢＯＸ」と呼ばれるデータ構造の内部に記述され、ＢＯＸを単位としてファイルに記録される。

図２はＢＯＸのフィールド定義を示す図である。ＢＯＸは、次のようなフィールドから構成される。

Ｓｉｚｅ：ｓｉｚｅフィールド自体を含む、ＢＯＸ全体のサイズ。

Ｔｙｐｅ：ＢＯＸの種類を表す４バイトのタイプ識別子。通常は４文字の英数字で表される。

その他のフィールドはＢＯＸによってはオプションであるため、ここでは説明を省略する。

ファイル中に記録されるデータは、その種類によって異なるタイプのＢＯＸに保持される。例えば、メディアデータ１０３は符号化データを格納するＭｅｄｉａ Ｄａｔａ ＢＯＸ（ｔｙｐｅフィールドの内容は‘ｍｄａｔ’。以降の説明でＢＯＸのタイプを示す識別子が用いられる場合は、そのタイプで示されるＢＯＸを表現しているものとする）として、メタデータ１０２はコンテンツ全体のメタデータ情報を格納するＭｏｖｉｅ ＢＯＸ（‘ｍｏｏｖ’）として記録される。

また、前述のチャンクおよびサンプルに関する情報については、チャンクのファイル中でのオフセット位置はＣｈｕｎｋ Ｏｆｆｓｅｔ ＢＯＸ（‘ｓｔｃｏ’）、サンプルとチャンクとの対応関係はＳａｍｐｌｅ Ｔｏ Ｃｈｕｎｋ ＢＯＸ（‘ｓｔｓｃ’）、各サンプルの時間情報はＴｉｍｅ Ｔｏ Ｓａｍｐｌｅ ＢＯＸ（‘ｓｔｔｓ’）、各サンプルのサイズ情報はＳａｍｐｌｅ Ｓｉｚｅ ＢＯＸ（‘ｓｔｓｚ’）、ランダムアクセス可能なサンプルの情報はＳｙｎｃ Ｓａｍｐｌｅ ＢＯＸ（‘ｓｔｓｓ’）、サンプルに適用される特性情報はＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ＢＯＸ（‘ｓｔｓｄ’）といったＢＯＸとして、Ｍｏｖｉｅ ＢＯＸの内部にトラック毎に記録される。

また、ＭＰ４ファイル形式では、ｍｏｏｖにすべてのメタデータを記録する形だけではなく、メタデータを時系列順に複数の領域に分割して記録するような形式も許可している。この形式は「フラグメントムービー」（Ｆｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅ）と呼ばれている。

図３に、フラグメントムービー形式のファイルの構造を示す。フラグメントムービー形式では、コンテンツのメディアデータおよびメタデータは任意の時間単位で分割することができ、分割された「フラグメント」はファイルの先頭から時系列順に記録される。例えば図３では、ｍｏｏｖ３０１は最初のフラグメントのメタデータを示しており、ｍｄａｔ３０２に含まれるデータに関する情報を保持する。次に出現するｍｏｏｆ３０３は２番目のフラグメントのメタデータであり、ｍｄａｔ３０４の情報を保持する、というように以下同様にして記録される。

このように、ＭＰ４ファイル形式のファイルでは、メディアデータに関する各種属性をメタデータ領域としてメディアデータと分離して保持することによって、メディアデータが物理的にどのように格納されているかに関わらず、所望のサンプルデータに容易にアクセスすることが可能になる。

本発明における動画像及び音声データの記録方法は、図４に示すように、フラグメントムービー形式で記録メディアに書き込む際に、各フラグメントはクラスタの境界から記録を始め、ある一定時間記録したら、次のクラスタ境界から続きのフラグメントの記録を開始するという動作を繰り返す。

即ち、ｍｏｏｖ４０１はクラスタ境界から記録を始め、ある一定時間分ｍｏｏｖ４０１とｍｄａｔ４０２を記録したら、ｍｄａｔ４０２の最後から次の空き領域のクラスタ境界まで移動（４０７）して、次のフラグメントｍｏｏｆ４０３とｍｄａｔ４０４の記録を行ない、このフラグメントの記録が終了したら再び次の空き領域のクラスタ境界まで移動（４０８）して、同様にフラグメントｍｏｏｆ４０５とｍｄａｔ４０６の記録を行なうという動作を繰り返す。

通常は各フラグメントの記録をクラスタ境界から始める必要は無いが、各フラグメントの記録はクラスタ境界から始めることで、高速に各フラグメントを時間順に並び替えて連結することが可能となる。この連結手段については後で詳細に説明する。

尚、ｍｄａｔのデータの終端から次のクラスタ境界までの空き領域は最終的にＦｒｅｅ Ｓｐａｃｅ ＢＯＸ（‘ｆｒｅｅ’）に設定する必要があるが、この設定は、記録中に随時行なっても、記録終了時にまとめて行なっても良い。

この記録メディアには、メモリカードやハードディスク、又はＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）に代表される書き込み可能なディスクメディアなどが考えられるが、これらの記録メディアにはそれぞれ記録可能な容量に制限があるため、前記の動作で動画像及び音声データを記録していくと記録容量に達した時点で新しいデータを書き込むことが出来なくなる。

そこで本発明では、図５のように記録したデータが、記録メディアの容量一杯や又は任意に設定した容量制限に達した時点で、先頭のｍｏｏｖ形式のヘッダ情報を持つデータも含めて、最も古いフラグメントからデータを削除し、新しいデータはその削除した領域に記録していく。

即ち、容量制限に達した時点で最初に削除されるデータは、通常、フラグメントムービーの先頭にあたるｍｏｏｖ形式のヘッダ情報（メタデータ）と、そのｍｏｏｖに対応するｍｄａｔ（メディアデータ）となり、このデータを削除してｍｏｏｆ形式のメタデータとそれに対応するｍｄａｔの形で新しいデータを記録する。続いて削除されるデータはｍｏｏｆ形式で最初に記録されたメタデータとそれに対応するｍｄａｔであり、削除した領域にはやはりｍｏｏｆとｍｄａｔの形式で新しいデータを記録するという動作を繰り返すことで、常に新しいデータがファイルに上書きされていくようになる。

なお実際には、符号化形式にも因るが、一定時間分のメディアデータのサイズは必ずしも一定のサイズにはならないため、前述のようなデータの上書き処理を行なう際には、新しく書き込むデータのサイズが、書き込み用に用意した領域のサイズより大きくなってしまわないように制御する必要がある。つまり、２つ以上のフラグメントを一度に削除して、新しいデータを書き込む領域を確保する場合もあり得る。

記録終了時、図６のように先頭のデータ（ｍｏｏｖ形式のメタデータ）が残されている場合には、ｍｏｏｖ６０５内にある全フラグメントを含む最終的なコンテンツ全体のｄｕｒａｔｉｏｎをセットし、各フラグメント間にある空き領域（６０１，６０２）がｆｒｅｅに設定されていなければこれを設定（６０３，６０４）して、フラグメントムービー形式のＭＰ４ファイルを生成する。

一方、図７のように先頭のデータが削除されて残っていない場合には、まず残されたフラグメントの中で時間的に最も古いデータをファイルの先頭にするため、ｍｏｏｆ形式のメタデータをｍｏｏｖ形式のメタデータに変換する必要がある。以降、ファイル構成上、時間順に各フラグメントを並び替えて連結し、各フラグメントのｍｏｏｆに含まれるオフセット情報を正しい値にセットする必要がある。更に各フラグメント間の空き領域がｆｒｅｅに設定されていなければこれを設定して、フラグメントムービー形式のＭＰ４ファイルを生成する。

（第１の実施の形態）
図８は、本実施形態における動画像及び音声のマルチメディアデータの最新データを記録メディアに残すように記録するための情報処理装置の構成を示すブロック図である。

図８において、ＣＰＵ８０１はＲＯＭ８０２あるいはＲＡＭ８０３あるいは外部記憶装置８０４に格納された制御プログラムとして記述された記録処理を実行する。外部記憶装置８０４によって格納された制御プログラムは、ＲＡＭ８０３にロードされ、ＣＰＵ８０１によって実行されることになる。

映像入力装置８１０から映像Ｉ／Ｆ８０５を介して入力された映像データ、および、音声入力装置８１１から音声Ｉ／Ｆ８０６を介して入力された音声データは、メディアドライブＩ／Ｆ８０８を介してメモリカードやＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＤＶＤなどのメディア８１２に記録される。また、ネットワークＩ／Ｆ８０７を介してネットワーク（インターネット、ＬＡＮを含む。有線、無線を問わない）越しの外部ストレージに記録しても良い。

また、上記各構成はバス８０９により相互に通信可能に接続され、各種機能が達成される。

図９は本発明の実施形態において、上記のマルチメディアデータの記録処理を実行する機能モジュールの構成例である。このモジュール構成は、図８の情報処理装置において、ＣＰＵが実行するマルチメディアデータ記録処理プログラムの構成要素を示す。

図９においてデータ記録処理部９０１は、まず始めに動作制御に必要なパラメータとして、これから記録する各フラグメントの時間長、記録するメディアの空き容量、出力するファイルサイズの上限値、入力される動画像または音声データのビットレートなどを受け取り、記録するデータとして動画像或いは音声のデータが入力され、上記パラメータによる制御を行ないながらファイルにデータを記録していく。

連結処理部９０２は、ファイルへのデータ記録処理が終了した後、各フラグメントの順番を時系列順に整列して連結する（再構成する）機能を有する。

ファイル出力部９０３は、再構成されたファイルをＭＰ４のフラグメントムービー形式として正しいデータになるように、メタデータの変換処理や、オフセット値の補正処理などを行ない、出力ファイルとして記録メディアに出力する。

続いて、本実施形態で行われるデータ記録処理の基本的な手順について、図１０のフローチャートを用いて説明する。

まず、ステップＳ１０１において、動作制御に必要なパラメータとして、これから記録する各フラグメントの時間長、記録するメディアの空き容量、出力するファイルサイズの上限値、入力される動画像または音声データのデータレート（ビットレート）などを受け取り、メモリ上などに保持する。

次にステップＳ１０２において、入力されるメディアデータのデコードのために必要な情報や、ファイルの識別のために任意に入力される情報などを受け取り、また、これから生成するフラグメントムービー形式のヘッダ情報（メタデータ）を形成するために必要なメモリの初期化処理などを行なう。

続いてステップＳ１０３において、入力されたメディアデータをファイルに記録する処理を開始する。

続くステップＳ１０４では、データ記録中に任意のタイミングで記録終了の指示が行なわれた場合に、ステップＳ１０５の動画記録終了処理へと処理を移行させる。動画記録終了処理の内容については図１１の説明の中で後述する。

次にステップＳ１０６において、現在記録中のフラグメントに記録されたデータの再生時間長がステップＳ１０１にて入力されたフラグメントの時間長に達したか否かの判定が行なわれる。まだ達していない場合（Ｙｅｓ）は、ステップＳ１０３に戻りさらにデータを記録し、達している場合（Ｎｏ）は、ステップＳ１０７の処理へと移行する。

ステップＳ１０７では、記録中のファイルサイズが出力ファイルサイズの上限値に達したか否かの判定が行なわれる。上限に達している場合（Ｙｅｓ）、ステップＳ１０８へ進み、記録されたファイル中の先頭を含めたフラグメントのなかで最も古いデータからデータ削除を実行し、ステップＳ１０３に戻り、データ削除を行なった領域に新しいデータの記録を実行する。この時のデータ削除は、実際にファイル中に書き込まれているデータを初期化する必要は無く、現在書き込まれている有効なフラグメントの物理的および時間軸上の位置を識別できるように、メモリ上や別ファイルなどに有効なフラグメント全ての先頭アドレスとサイズ、及び録画開始時間を記録し、随時更新することで対応可能である。

一方、まだ上限に達していない場合（Ｎｏ）は、ステップＳ１０９において、現在のメディアデータの書き込み位置から最も近いクラスタ境界までの領域をＦｒｅｅ Ｓｐａｃｅ ＢＯＸ（‘ｆｒｅｅ’）に設定し、ステップＳ１１０へ移行する。

ステップＳ１１０では、次のフラグメントの書き出し位置をクラスタ境界に設定し、ステップＳ１０３に戻り処理を継続する。

引き続き、図１０のステップＳ１０５における動画記録終了処理の内容について説明するにあたり、フラグメントムービーの先頭以外のヘッダ情報（メタデータ）を先頭のヘッダ情報（メタデータ）の形式に再構成しなければならないケースが生じる。そのため、まずフラグメントムービー形式における分割されたメタデータの、先頭とそれ以外の形式の違いについて簡単に説明する。

＜メタデータの再構成（変換）処理＞
図１２は、フラグメントムービー形式のファイル構成の概略を示すものである。図において、フラグメントムービー形式のファイルの場合、最初のｍｏｏｖに含まれるＭｏｖｉｅ Ｅｘｔｅｎｄｓ ＢＯＸ（‘ｍｖｅｘ’）に含まれるＭｏｖｉｅ Ｅｘｔｅｎｄｓ Ｈｅａｄｅｒ ＢＯＸ（‘ｍｅｈｄ’）のｆｒａｇｍｅｎｔ＿ｄｕｒａｔｉｏｎフィールドには、全フラグメントを含むコンテンツ全体のｄｕｒａｔｉｏｎをセットしなければならない。また、ｍｏｏｆに含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ ＢＯＸ（‘ｔｒａｆ’）に含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ Ｈｅａｄｅｒ（‘ｔｆｈｄ’）のｂａｓｅ＿ｄａｔａ＿ｏｆｆｓｅｔフィールド、およびｔｒａｆに含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ Ｒｕｎ ＢＯＸ（‘ｔｒｕｎ’）のｄａｔａ＿ｏｆｆｓｅｔフィールドには、それぞれ後続のｍｄａｔの基準オフセット、および基準オフセットからの相対オフセットをセットしなければならない。

したがって、メタデータの再構成処理では、上記に述べたような形式の違いを考慮した変換処理を行わなければならない。

続いて、図１０のステップＳ１０５における動画記録終了処理の内容について、図１１のフローチャートを用いて説明する。

まずステップＳ２０１において、フラグメントムービー形式のＭＰ４の先頭のヘッダ情報形式であるｍｏｏｖが、有効なフラグメントとして残されているかどうかチェックする。

ｍｏｏｖ形式のヘッダ情報（メタデータ）が残されている場合、フラグメントの削除は発生していないので、ファイル中の論理的なデータの並び順は時系列順に並んでいるので、この場合、フラグメント単位でのデータの並べ替えを行なう必要は無く、記録終了時に確定したムービー全体のｄｕｒａｔｉｏｎを設定すれば正しいＭＰ４ファイルを生成できる。

即ち、図６のように先頭のデータ（ｍｏｏｖ形式のメタデータ）が残されている場合には、ｍｏｏｖ６０５内にあるＭｏｖｉｅ Ｅｘｔｅｎｄｓ ＢＯＸ （‘ｍｖｅｘ’）に含まれるＭｏｖｉｅ Ｅｘｔｅｎｄｓ Ｈｅａｄｅｒ ＢＯＸ（‘ｍｅｈｄ’）のｆｒａｇｍｅｎｔ＿ｄｕｒａｔｉｏｎフィールドに、全フラグメントを含む最終的なコンテンツ全体のｄｕｒａｔｉｏｎをセットすることでフラグメントムービー形式のＭＰ４ファイルを生成できる。

一方、ｍｏｏｖ形式のヘッダ情報（メタデータ）が残されていない場合、ステップＳ２０３のヘッダ形式変換処理により、ｍｏｏｖ形式のヘッダ情報を生成する必要がある。

即ち、図７のように先頭のデータ（ｍｏｏｖ形式のメタデータ）が削除されて残っていない場合には、記録されたｍｏｏｆ形式のヘッダを持つフラグメントの中で時系列的に最も古いデータをファイルの先頭にするため、そのｍｏｏｆ形式のヘッダをｍｏｏｖ形式のヘッダに変換し、以降、ステップＳ２０４において、時系列順にフラグメントを並び替えて連結する。ｍｏｏｆ形式のヘッダをｍｏｏｖ形式のヘッダに変換する方法、及び、時系列順にフラグメントを並び替えて連結する方法については後述する。

続いてステップＳ２０５において、フラグメント単位の並び変えにより、各フラグメントのヘッダ情報にもともと設定されていた、ファイル中の位置を表すオフセット値が正しくない値になるため、このオフセット値を再設定する必要がある。

即ち、各フラグメントのｍｏｏｆに含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ ＢＯＸ（‘ｔｒａｆ’）に含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ Ｈｅａｄｅｒ（‘ｔｆｈｄ’）のｂａｓｅ＿ｄａｔａ＿ｏｆｆｓｅｔフィールド、およびｔｒａｆに含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ Ｒｕｎ ＢＯＸ（‘ｔｒｕｎ’）のｄａｔａ＿ｏｆｆｓｅｔフィールドに、それぞれ後続のｍｄａｔの基準オフセット、および基準オフセットからの相対オフセットを正しい値に再設定する必要がある。

この時、基準オフセット（ｂａｓｅ＿ｄａｔａ＿ｏｆｆｓｅｔ）には、予め各フラグメントの先頭のオフセット値を設定するようにしておくと、本実施形態のようにフラグメント単位でファイル中での配置が変更されても変更を要するのは基準オフセットのみで、相対オフセット（ｄａｔａ＿ｏｆｆｓｅｔ）の値は変更する必要が無いため、処理が容易になる。

最後に、ステップＳ２０６において、ファイルをクローズし、ムービーフラグメント形式のＭＰ４として正しいファイルを出力する。ステップＳ２０１からステップＳ２０２を経てステップＳ２０６に至る処理のものは、通常のムービーフラグメント形式のＭＰ４生成と同様の処理手順である。

なお、図１１のステップＳ２０３とステップＳ２０４は処理の順番が入れ替わっても良い。但し、ステップＳ２０３のヘッダ変換処理により、基のｍｏｏｆ形式のヘッダ領域よりも変換後のｍｏｏｖ形式のヘッダ領域の方が大きくなる場合には、オフセット値に影響が出る可能性があるので、図１１の通りの順番で処理した方が処理の冗長性を防ぐ意味では望ましい。

ここで、図１１のステップＳ２０３におけるｍｏｏｆからｍｏｏｖへの変換処理について、図１３のフローチャートを用いて説明する。

なお説明を簡略化するため、本実施形態では処理対象ファイルのサンプルはすべて同じ再生時間を持ち（動画像データの場合、フレームレート固定。音声データの場合、サンプリングレート固定）、優先度、パディングビットなどは設定されていないものと想定する。また、同一トラックの全てのサンプルは符号化形式などにおいて同一の情報をもつものとする。

＜ｍｏｏｆからｍｏｏｖへのメタデータ形式変換＞
まず、ステップＳ３０１において、連結処理部９０２は処理対象のフラグメントのメタデータ部に含まれるＴｒａｃｋ Ｆｒａｇｍｅｎｔ ＢＯＸ（‘ｔｆｈｄ’）から ｔｒａｃｋ＿ＩＤ、ｂａｓｅ＿ｄａｔａ＿ｏｆｆｓｅｔ、ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎを取得する。

次に、ステップＳ３０２において、新しく作成するｍｏｏｖヘッダに含まれるＴｒａｃｋ Ｈｅａｄｅｒ ＢＯＸ （‘ｔｋｈｄ’）のｔｒａｃｋ＿ｉｄ に、取得したｔｒａｃｋ＿ＩＤを設定する。

次に、ステップＳ３０３において、新しく作成するｍｏｏｖヘッダに含まれる上記のｔｒａｃｋ＿ＩＤを設定したトラックに含まれるＳａｍｐｌｅ Ｔａｂｌｅ ＢＯＸ ￥（‘ｓｔｔｓ’）のｓａｍｐｌｅ＿ｄｅｌｔａ にｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎを設定し、ｓｔｔｓのｅｎｔｒｙ＿ｃｏｕｎｔは１を設定する。

次に、ステップＳ３０４において、通常複数存在するチャンク単位での処理を実行するため、ループ処理の初期化を行う。ここでは、処理対象チャンクのインデックスとして用いられる変数ｉを１に初期化する。

次に、ステップＳ３０５において、ｉ番目のチャンクに対応するｔｒｕｎ［ｉ］から、ｓａｍｐｌｅ＿ｃｏｕｎｔとｄａｔａ＿ｏｆｆｓｅｔを取得する。この値はそれぞれ、新しく作成するｍｏｏｖヘッダ内の当該トラック内のｉ番目のチャンクに含まれるサンプルの数とチャンクのオフセット値に相当する。

次に、ステップＳ３０６において、新しく作成するｍｏｏｖヘッダに含まれる上記のｔｒａｃｋ＿ＩＤを設定したトラックに含まれるＣｈｕｎｋ Ｏｆｆｓｅｔ ＢＯＸ（‘ｓｔｃｏ’）のｉ番目のｃｈｕｎｋ＿ｏｆｆｓｅｔに ｂａｓｅ＿ｄａｔａ＿ｏｆｆｓｅｔ＋ｄａｔａ＿ｏｆｆｓｅｔの値を設定する。

次に、ステップＳ３０７において、通常１つのチャンクに複数存在するサンプル単位での処理を実行するため、ループ処理の初期化を行う。ここでは、処理対象チャンク内のサンプル番号として用いられる変数ｋを１に初期化する。

次に、ステップＳ３０８において、ｉ番目のチャンク内のｋ番目のサンプルのｓａｍｐｌｅ＿ｓｉｚｅを取得し、新しく作成するｍｏｏｖヘッダに含まれる上記のｔｒａｃｋ＿ＩＤを設定したトラックに含まれるＳａｍｐｌｅ Ｓｉｚｅ ＢＯＸ（‘ｓｔｓｚ’）のｋ番目のｓａｍｐｌｅ＿ｓｉｚｅ に設定する。

次に、ステップＳ３０９において、ｉ番目のチャンク内のｋ番目のサンプルのｓａｍｐｌｅ＿ｆｌａｇｓを取得する。

次に、ステップＳ３１０において、ステップＳ３０９において取得したｓａｍｐｌｅ＿ｆｌａｇｓがキーフレームを示しているかチェックする。チェックの結果、キーフレームであることを示している場合、ステップＳ３１１へと処理を進め、新しく作成するｍｏｏｖヘッダに含まれる上記のｔｒａｃｋ＿ＩＤを設定したトラックに含まれるＳｙｎｃ Ｓａｍｐｌｅ ＢＯＸ（‘ｓｔｓｓ’）のｓａｍｐｌｅ＿ｎｕｍｂｅｒに処理対象のトラックに含まれる先頭からの累計のサンプル番号を設定する。

次に、ステップＳ３１２において、ｉ番目のチャンクのすべてのサンプルが処理されたかチェックする。変数ｋがｉ番目のチャンク内のサンプル数に満たない場合は、変数ｋをインクリメントし、ステップＳ３０８からＳ３１２までの処理を繰り返す。

次に、ステップＳ３１３において、すべてのチャンクが処理されたかチェックする。未処理のｔｒｕｎが存在する場合は、変数ｉをインクリメントし、ステップＳ３０５からＳ３１３までの処理を繰り返す。

以上の処理を変換対象の各トラックに対して行う。即ち、ｍｏｏｆに含まれる全てのｔｆｈｄ以下の構成情報に対して行なうことで、処理対象フラグメントのｍｏｏｆ形式のメタデータをｍｏｏｖ形式のメタデータに再構成することができる。

また、ｍｏｏｖを生成する際に必要な情報で、ｍｏｏｆには含まれない情報が存在する。例えば、Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ＢＯＸ（‘ｓｔｓｄ’）に含まれる“デコード固有情報”は、ｍｏｏｆには含まれないので、ｍｏｏｖを削除する際には、このような情報をメモリに保持しておく必要がある。即ち、連結処理部９０２では、すでに処理されているｍｏｏｖの内容をＲＡＭ上に保持しておき、ｍｏｏｆからｍｏｏｖへの変換を行う際に、変換元のｍｏｏｆに存在しない情報をＲＡＭ上に保持されているｍｏｏｖから補充するという形の処理が行われることが求められる。

＜ｍｖｅｘの再生成処理＞
また上述の通り、フラグメントムービー形式の場合、ｍｏｏｖにはｍｖｅｘを付加しなければならないが、本実施形態において、動画像及び音声データの記録中にｍｏｏｖを削除したことにより、改めてｍｏｏｆをｍｏｏｖに変換することでｍｏｏｖを生成する際に、ｍｖｅｘも再生成する必要がある。

ｍｖｅｘにはＴｒａｃｋ Ｅｘｔｅｎｄｓ ＢＯＸ（‘ｔｒｅｘ’）という、図１４で示されるフィールド定義のＢＯＸが含まれる。各トラックを構成するすべてのサンプルが同じ属性を持つ場合に、全サンプルに適用されるデフォルト属性を保持することが出来る。そのため、各トラックの全サンプルに適用すべき属性がある場合、ｔｒｅｘに値をセットするようにする。例えば本実施形態の例では、サンプルの時間間隔はすべて同一であるものとして、ｄｅｆａｕｌｒ＿ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎフィールドにデフォルトのサンプルの時間間隔を設定するものとする。

＜シーケンスナンバーの整列処理＞
フラグメントムービーでは、ｍｏｏｆに含まれるＭｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｈｅａｄｅｒ ＢＯＸ（‘ｍｆｈｄ’）内に、通常１からスタートしてファイル中のムービーフラグメント毎に、それらの出現順に増加するｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒが含まれる。

本実施形態では、限られた記録容量に最新のデータを残すために、古いフラグメントのデータを新しいフラグメントのデータで上書きする処理を行なうため、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒの乱れが発生する。そこで、本実施形態では、最も古いｍｏｏｆのｍｏｏｖへの変換処理を実行する際、即ち、フラグメントの上書き処理により、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒに乱れが発生した場合には、フラグメントを時間順に並び替える際に、ｍｏｏｖに変換したｍｏｏｆの次に古いｍｏｏｆデータのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを１として、順に１ずつ加算したｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒをｍｏｏｆの出現順に各々のｍｆｈｄの領域に設定し直さなければならない。

続いて、図１１のステップＳ２０４の各フラグメントの時系列順の連結処理について説明する。

＜フラグメントの時系列連結処理＞
フラグメントムービー形式のＭＰ４では、前述の通り、各フラグメントのシーケンスナンバーは出現順に増加しなければならない。つまり、各フラグメントのファイル先頭からの出現順序は時系列で整列されている必要がある。本実施形態では、データ記録処理部９０１においてファイルサイズがある閾値を超えないように、古いデータを新しいデータで上書きする処理を行なうため、ファイル中の各フラグメントのファイル先頭からの出現順序は、上書き処理が発生した時点で時系列順には並ばなくなる。そこでファイルを記録するメディアのファイルシステムとしてＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）ファイルシステムを採用し、このＦＡＴ領域の情報を操作することにより、各フラグメントの時系列順の整列を行なう。

ＦＡＴを採用したファイルシステムでは、記憶媒体の読み書きをクラスタ（ｃｌｕｓｔｅｒ）単位で扱い、１クラスタに収まらないような大きさのファイルは、複数のクラスタに分けて格納される。このときのクラスタのアドレスは連続しているとは限らないので、どの順番でクラスタが連なっているかをＦＡＴ領域に記録する。このクラスタの連なりのことをクラスタ・チェーン（Ｃｌｕｓｔｅｒ Ｃｈａｉｎ）と呼ぶ。

なおクラスタは、通常５１２バイトを１つの単位とするセクタ（ｓｅｃｔｏｒ）と呼ばれる基本ブロックを複数まとめたもので、フォーマットされる記録メディアの容量などにより、最適なクラスタのサイズは変化する。

本実施形態では、図４に示すように、クラスタの境界から各フラグメントの記録を開始しているので、連結処理部９０２において、各フラグメントの書き出し位置のＦＡＴエントリを任意に書き換えることにより、ファイル中の各フラグメントの論理的な並び順を、時系列順に整列させることが可能になる。

この連結処理を行なうと、各フラグメントのファイル先頭からのオフセット値が変化するため、正しい値に修正する必要があるが、この処理内容については図１１の説明で述べた通りである。

（第２の実施の形態）
本発明の第１の実施形態では、限られた容量の記録メディアに最新の動画像及び音声データを１つのファイルとして記録する方法について述べた。

そこで次に第２の実施の形態として、第１の実施形態の実現方法に加えて、入力された動画像データ又は音声データに、ある閾値を超える変化があった部分のデータを別ファイルとして記録メディアに書き出す手段について説明する。

図１５は、本実施形態におけるデータ記録処理部９０１での処理フローを示す。基本的な処理フローは、第１の実施形態における図１０の場合と同様であるので、図１０における処理フローと異なる点について重点的に説明を行なう。

まず、ステップＳ４０１において、各フラグメントの時間長、記録するメディアの空き容量、出力するファイルサイズの上限値、入力される動画像または音声データのデータレート（ビットレート）などに加えて、入力するデータの種類に対応したイベント検出のための閾値を受け取り、ＲＡＭ８０３や外部記憶装置８０４或いは記録メディア８１２などに保持する。このイベント検出のための閾値は、例えば動画像データの場合、ある一定時間内における動きベクトルや、明度の変化量などがあげられる。一方、音声データの場合、音の大きさ（絶対値）やある一定時間内における音の大きさの変化量などがあげられる。

次にステップＳ４０２において、入力されるメディアデータのデコードのために必要な情報や、ファイルの識別のために任意に入力される情報などを受け取り、また、これから生成するフラグメントムービー形式のヘッダ情報（メタデータ）を形成するために必要なメモリの初期化処理などを行ない、続いてステップＳ４０３において、入力されたメディアデータをファイルに記録する処理を開始する。

次にステップＳ４０４では、ステップＳ４０３でファイルに記録したメディアデータに、イベント発生を示す変化があったか否かの判定を行なう。

このイベント検出のため、データ記録処理部９０２では、映像Ｉ／Ｆ８０５及び音声Ｉ／Ｆ８０６から、記録するメディアデータと共に、映像の場合は動きベクトルや一定時間内の明度の変化量、音声の場合は音の大きさや一定時間内の音の大きさの変化量などを受け取り、ステップＳ４０１で受け取った閾値との比較を行なう。

閾値を超える変化があった場合、記録中のフラグメント部に変化があったことを示すフラグをセットする（ステップＳ４０９）。以下、本実施形態ではこのフラグをイベントフラグと呼ぶ。

イベントフラグは、例えば図１６のような表形式でＲＡＭ上に保持し、フラグメント毎にそのフラグメントの開始アドレスを示す基準オフセットと、そのフラグメントのｆｒｅｅ領域まで含めた全体のサイズと共に、そのフラグメントに記録されたデータにイベントが発生したか否かを示すイベントフラグを記録する。

ステップＳ４０５において、記録中のファイルサイズが出力ファイルサイズの上限値に達した場合（Ｙｅｓ）、本実施形態では、削除対象となる古いフラグメントのデータにイベントフラグがセットされているかを確認し、イベントフラグが設定されていた場合は、このフラグメントのデータは削除せず、ステップＳ４０７において、単独の別ファイルとして記録メディアに書き出す。

この時、書き出すフラグメントがｍｏｏｆ形式のヘッダ情報を持つ場合は、前述した手段により、ｍｏｏｆ形式からｍｏｏｖ形式のヘッダとなるようにメタデータの変換処理を行なう。この変換処理を実行するタイミングは、最終的にファイルの記録を終了するまでの間の、いつ実行しても良い。

また、フラグメント毎の設定時間が短い場合など、フラグメント１つを単独のファイルに変換しても視聴する上で短すぎる場合などは、例えばイベントフラグが設定されたフラグメントを中心として、複数のフラグメントを別ファイルとして書き出しても良い。この処理方法に関しては、本明細書では説明を割愛する。

ステップＳ４０７において古いデータを別ファイルとして書き出した場合、更にステップＳ４０８において、その次に古いフラグメントのデータを削除し、新しいデータを記録するための領域を確保する。

図１５の説明において、特に説明を行なっていない部分は、第１の実施形態における図１０の場合と同様である。また、説明を行った部分以外の処理や構成は、第１の実施形態と同様である。

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

本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＤＶＤ−ＲＡＭ）、ＨＤＤＶＤ、Ｂｌｕ−ｒａｙＤｉｓｃなどがある。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

ＭＰ４或いは類似のファイル形式におけるメタデータ、メディアデータの概念を説明する図である。 ＢＯＸのフィールド定義を示す図である。 フラグメントムービーの概念を説明する図である。 本発明における基本的なデータ記録の方法を説明する図である。 本発明における最新のデータをファイルに記録する方法を説明する図である。 本発明における記録終了時の基本的なデータ処理の方法を説明する図である。 本発明における記録終了時の最新のデータを記録したファイルを正しいＭＰ４ファイル形式に変換するための方法を説明する図である。 本発明の実施形態における動画像及び音声のマルチメディアデータの最新データを記録メディアに残すように記録するための情報処理装置の構成を示すブロック図である。 本発明の実施形態におけるマルチメディアデータの記録処理を実行する機能モジュールの構成例である。 本発明の実施形態におけるデータ記録処理の基本的な手順を示すフローチャートである。 本発明の実施形態における動画記録終了処理の手順を示すフローチャートである。 フラグメントムービー形式のファイル構成の概略を示すものである。 本発明の実施形態におけるｍｏｏｆをｍｏｏｖに変換する処理を説明するフローチャートである。 Ｔｒａｃｋ Ｅｘｔｅｎｄｓ Ｂｏｘ（‘ｔｒｅｘ’）のフィールド定義を示す図である。 本発明の実施形態におけるデータ記録処理において、イベント発生時のデータを記録する手順を示すフローチャートである。 本発明の実施形態におけるイベントフラグの記録方法を説明する図である。

Claims (3)

1. 動画像データと音声データのうち少なくとも１つのメディアデータを記録するデータ記録装置であって、
   前記メディアデータをフラグメント単位で記録する記録手段と、
   前記フラグメントを時系列順に連結する連結手段と、
   前記動画像データあるいは音声データに閾値を超える変化があった場合、前記閾値を超える変化があった動画像データあるいは音声データのメディアデータのフラグメントに、変化があったことを示すフラグをセットする設定手段と、
   前記フラグメントが前記記録手段によりクラスタ境界から記録されるように制御すると共に、前記記録手段により記録されたデータ容量が所定のデータ容量に達したあとに記録されるフラグメントが、前記記録手段により記録済のフラグメントであって前記変化があったことを示すフラグがセットされていないフラグメントのうち記録順序が最も古いフラグメントが記録されたクラスタ境界から記録されるように制御する記録制御手段と、
   前記記録手段により記録されたデータ容量が前記所定のデータ容量に達したあとに前記メディアデータの先頭のフラグメントに上書きでフラグメントを記録した場合、当該フラグメントの記録後に記録されているフラグメントのうち記録順序が最も古いフラグメントのヘッダ情報を先頭のフラグメントであることを示す形式のヘッダ情報に変換するヘッダ変換手段と、
   前記ヘッダ変換手段によって変換されたヘッダ情報と、前記記録手段によりクラスタ境界から記録され前記連結手段により時系列順に連結されたフラグメントとに基づいて、ファイルを生成するファイル生成手段と
   を有することを特徴とするデータ記録装置。
2. 前記連結手段は、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）のクラスタ連結情報を書き換えることで、前記フラグメント単位のデータを時系列順に連結することを特徴とする請求項１に記載のデータ記録装置。
3. 前記ファイルは、ＭＰ４におけるフラグメントムービー形であることを特徴とする請求項１又は２に記載のデータ記録装置。

Images