(57)【要約】【課題】  動画像データ、音声データ等のメディアデータの管理情報を、オーバーヘッドが少なく、かつ従来規格との互換性を保つことができる方法でＭＰ４を含むのファイルに記録できるようにする。【解決手段】  サンプルデータ及び管理情報を多重化して出力ファイル８に出力するファイル出力部５と、管理情報を出力ファイル８に出力するまでの間、一時的に保管しておく管理情報記憶部６と、上記出力ファイル８に記録されたデータブロックを、ファイル中の別の位置へ移動させるデータ構造再配置部７とから、基本処理を実行する記録部１０を構成して、マージ処理にかかる時間を短縮することができるとともに、管理情報が喪失する危険が少なく、しかも従来規格との互換性に優れたファイル記録を行なうことができるようにする。【選択図】  図４
2005065110.tif 000002
【特許請求の範囲】
【請求項１】
動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録方法であって、
上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成処理と、
上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置処理とを有し、
上記チャンクデータを上記ファイル中の異なる位置に再配置することによって上記予約領域のサイズを変更するようにしたことを特徴とするファイル記録方法。
【請求項２】
動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録装置であって、
上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成手段と、
上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置手段とを備え、
上記データ再配置手段は、上記チャンクデータを上記ファイル中の異なる位置に再配置することによって上記予約領域のサイズを変更することを特徴とするファイル記録装置。
【請求項３】
上記管理情報及び上記予約領域のサイズを管理するサイズ管理手段を備え、
上記サイズ管理手段は、上記管理情報のサイズが上記予約領域のサイズよりも大きい場合には、上記データ再配置手段に対して上記チャンクデータの再配置を行なうように要求し、
上記データ再配置手段により、連続している上記チャンクデータにおける先頭のチャンクデータを上記ファイルの末尾に再配置する処理を行なうことによって、上記管理情報及び上記予約領域のサイズを更新することを特徴とする請求項２に記載のファイル記録装置。
【請求項４】
上記データ再配置手段は、管理情報を出力するのに十分な大きさの予約領域が得られるまで、上記チャンクデータの再配置処理を繰り返し行なうことを特徴とする請求項３に記載のファイル記録装置。
【請求項５】
上記管理情報及び上記予約領域のサイズを管理するサイズ管理手段を備え、
上記サイズ管理手段は、上記予約領域のうち上記管理情報の記録に用いられない未使用領域のサイズを管理し、上記未使用領域のサイズが上記ファイルの末尾に配置されているチャンクデータのサイズ以下である場合には上記データ再配置手段に対して上記チャンクデータの再配置を行なうように要求し、
上記データ再配置手段により、上記ファイルの末尾のチャンクデータを上記未使用領域に再配置する処理を行なうことにより、上記管理情報及び上記予約領域のサイズを更新することを特徴とする請求項２に記載のファイル記録装置。
【請求項６】
上記データ再配置手段は、チャンクデータ以外のデータブロックの再配置及び変更も行ない、チャンク再配置によってファイル形式が規格と矛盾することのないようにして、ファイル構造を正しく保つことを特徴とする請求項２〜５の何れか１項に記載のファイル記録装置。
【請求項７】
動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録方法であって、
上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成処理と、
上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置処理と、
上記データ再配置処理において、上記予約領域のサイズを変更する処理とをコンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項８】
上記請求項７に記載のコンピュータプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル記録方法、ファイル記録装置、コンピュータプログラム及びコンピュータ読み取り可能な記録媒体に関し、さらに詳細には、動画像データ、音声データの管理情報を含むデータ構造を一括して出力するために用いて好適なものである。
【背景技術】
【０００２】
近年、動画像をデジタル化して記録する装置が普及している。例えば、撮影した動画像を、圧縮効率が高い映像音声符号化形式を用いてデジタル符号化し、内蔵メモリやＳＤカードなどの外部記憶媒体に記録することができるデジタルカメラが普及している。また、同様にして記録された動画像データを、電子メールでＩＰネットワークを介して交換することができる携帯電話機も普及しつつある。
【０００３】
この映像音声符号化形式には、ＩＳＯ（International Organization for Standardization）を中心として標準化が進められているMPEG-4(ISO/IEC 14496)などが一般的に用いられる。MPEG-4は、ＤＶＤに採用されているMPEG-2と比較して、低帯域環境であっても動画・音声データを品質の劣化を抑えつつ高い圧縮効率で符号化できるという特性を持っている。こうした特性から、上記のような一般消費者向けの記録装置の多くがMPEG-4を採用している。
【０００４】
また、上記の機器では、動画像データと音声データは多重化され、最終的にファイルとして出力されるのが一般的である。上記ファイルの形式としては、MPEG-4規格の一部として標準化されているMPEG-4 File Format規格（ISO/IEC 14496-14。以下、「ＭＰ４」と記載）が代表的なものとして挙げられる。以下、ＭＰ４ファイルの基本構造について簡単に説明する。
【０００５】
図１は、ＭＰ４ファイル形式の構造を単純化して示した図である。
ＭＰ４ファイルでは、すべてのデータは「アトム」（もしくは「ボックス」）と呼ばれるデータ構造にパッキングして記録するものとしている。各アトムの先頭には、次のような定義を持ったすべてのアトムで共通のヘッダ情報が付加される。
class Atom {
unsigned int(32) size;
byte type[4];
byte data[];
};
【０００６】
上記「size」は、アトムのデータ長を示すフィールドである。「type」は、アトムの種類を示すフィールドであり、各アトムに対して割り当てられている４文字の識別子がセットされる。「data」は、アトムが内包するデータの実体であり、内容はtypeによって異なる。なお、アトムはネスト構造を持つことができ、一つ以上の他のアトムを包含することが可能になっているため、「data」は他のアトムになることもある。
【０００７】
ＭＰ４ファイルのアトム構成は、図１で示されるように、大きく２つに分けることができる。動画像・音声などのメディアデータは、継続時間やフレームといった単位で分割されたごく小さな符号化データ（以下「サンプル」と記載）の連続から構成されるが、ＭＰ４ファイルには、それらのサンプルのサイズやタイムスタンプなどの管理情報もあわせて多重化されて記録される。
【０００８】
ＭＰ４規格においては、前者は「Movie Atom」（typeフィールドの値は‘moov'）と呼ばれる、動画像・音声サンプルの管理情報のようないわゆるメタデータ情報を格納するためのアトムとして定義されている。後者は、動画像・音声のサンプルデータのような、いわゆるメディアデータを格納する「Media Data Atom」（typeフィールドの値は‘mdat'）と呼ばれるアトムとして定義されている。
【０００９】
Media Data Atomのメディアデータは、「チャンク」と呼ばれるデータブロックに論理的に分割された状態で格納される。それぞれのチャンクは、時間的に連続するサンプルデータから構成されており、Media Data Atomのdataフィールドにはチャンクの配列が格納される。なお、このチャンクのサイズや含まれるサンプルの個数には特に制約はなく、環境や状況に応じて任意の大きさやサンプル数を持つチャンクを構成し、格納することができる。
【００１０】
ＭＰ４では、アトムを物理的に複数のパートに分割して記述することは許されていない。したがって、Movie Atomは、記録されるすべての管理情報が格納された単独のアトムとしてファイルに記録されなければならない。上記「Media Data Atom」も同様である。
【００１１】
上記のような装置で撮影される動画像の記録時間が最終的にどれだけの長さになるかは、記録完了の時点にならなければわからない。Movie Atom及びMedia Data Atomのサイズは記録時間が長くなるにつれて増加するので、記録完了時にこれらのアトムの最終的なサイズが確定しなければ、アトムを分割することなく図１のような配置でＭＰ４ファイルに記録することはできない。
【００１２】
それゆえ、図１のようなＭＰ４ファイルを出力するためには、Movie Atomに格納される管理情報とMedia Data Atomに格納されるサンプルデータを別々に記憶あるいは記録しておき、最後に両者をマージするという処理を行なう必要があった。
【００１３】
以上のように、図１の形式で出力を行なう場合、すべての動画像・音声サンプルデータの記録が正しく終了されない限りＭＰ４ファイルを出力することができないという問題がある。例えば、撮影中に電力供給の停止や機器の不具合など不測の事態により記録処理が異常終了した場合、それまでに記録されたデータは消去されてしまうか、あるいは不正な状態で装置や記憶媒体に残ってしまう。この残存データはＭＰ４としては不正な形式であるため再生することはできない。したがって、異常終了した場合は、それまでの記録内容は実質的にすべて失われてしまうことになる。
【００１４】
上記の問題を防ぐためには、サンプルデータと管理情報を定期的にマージして、それまでの記録内容が一時保存されたＭＰ４ファイルを残すという処理が必要になる。しかし、マージ処理は、蓄積されているすべてのサンプルデータと管理情報に対する入出力を伴うため、データ量の増加に比例して一回のマージ処理に要する時間が増大してしまう。
【００１５】
加えて、マージ処理を行なうには、出力されるＭＰ４ファイルを保持するための領域と、それと同程度の大きさを占める、マージされるサンプルデータ及び管理情報を保持するための一時記憶領域がなければならない。すなわち、マージ処理を行なうためには、実際に記録されるデータサイズに対して、およそ２倍の大きさの記憶装置あるいは記憶媒体を設けることが記録装置には要求されることになる。
【００１６】
必要十分な一時記憶領域を得るためには、より多くの記憶装置あるいは記憶媒体を記録装置に搭載するか、さもなければ記録装置で記録可能な時間の上限を短くするといったように、コスト面あるいは性能面で何らかの代償が発生してしまう。
【００１７】
上記の問題を解決しうる方策として、ＭＰ４規格では、図２のように他のファイルのサンプルデータを参照するための「Data Reference Atom」（typeフィールドの値は‘dref'）というアトムを定義している。Data Reference Atomを用いて、サンプルデータと管理情報を別ファイルとして出力するようにすれば、マージ処理は不要になる。
【００１８】
また、ＭＰ４規格の基となるISO Base Media File Format規格（ISO/IEC 14496-12）では、「Movie Fragment Atom」（typeフィールドの値は‘moof'）と呼ばれる、管理情報を複数のアトムに分割して記述するためのアトムが定義されている。
【００１９】
Movie Fragment Atomを用いた仕組みは、ＭＰ４規格や、同じくISO Base Media File Format規格から派生するMotion JPEG 2000規格（ISO/IEC 15444-3）に導入される方向で現在標準化作業が進められている。その他、基本原理を他のデータ形式にも応用したデータ記録方法も提案されている（例えば、特許文献１参照。）。
【００２０】
Movie Fragment Atomを用いる場合のＭＰ４ファイルの例を図３に示す。管理情報は、Movie Atomよりも後方に配置されたMovie Fragment Atomにも記録され、Movie AtomとすべてのMovie Fragment Atomに格納された内容が一つの論理的なメタデータ領域として扱われる。
【００２１】
この仕組みを用いて、一時記憶に蓄積された内容を定期的にマージして図３のような形式になるようにＭＰ４ファイルの末尾に書き出し、一時記憶を解放するという処理を繰り返すことで、一回のマージ処理にかかる時間を短縮することができ、管理情報が喪失する危険も最小限に抑えることができる。
【００２２】
【特許文献１】特開２００３−２２６２１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２３】
しかしながら、上記の解決方法にはそれぞれ問題があった。
まず、Data Reference Atomを用いる方法で記録されたファイルは、全てが欠落することなく揃っている状態でなければ正しく再生されることは保証されない。そのため、メールやファイル転送などで容易・安全に交換できるように、単一のＭＰ４ファイルとして出力されることを望む利用者も決して少なくはないと思われる。そうしたユーザが望む形式で出力するには、最終的には結局すべてのデータをマージし直さなければならないため、問題解決にはならなかった。
【００２４】
また、Movie Fragment Atomは、本願の明細書を記述している時点でＭＰ４規格への編入が完了していないため、既に出荷されているＭＰ４処理装置でMovie Fragment Atomの機能がサポートされている保証はない。おそらく、非サポート装置でMovie Fragment Atomを含むＭＰ４ファイルを再生する場合は、少なくとも最初のMovie Atomに記録された管理情報が示す部分のデータしか再生されず、以降は再生できないと推測される。そのため、出荷済の装置に対しての互換性を十分に保つことができなくなる恐れがある。
【課題を解決するための手段】
【００２５】
本発明のファイル記録方法は、動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録方法であって、上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成処理と、上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置処理とを有し、上記チャンクデータを上記ファイル中の異なる位置に再配置することによって上記予約領域のサイズを変更することを特徴としている。
【００２６】
本発明のファイル記録装置は、動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録装置であって、上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成手段と、上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置手段とを備え、上記データ再配置手段は、上記チャンクデータを上記ファイル中の異なる位置に再配置することによって上記予約領域のサイズを変更することを特徴としている。
【００２７】
本発明のコンピュータプログラムは、動画像または音声の符号化データからなるサンプルデータと、上記サンプルデータの複数からなるチャンクデータと、上記サンプルデータ及びチャンクデータを管理する管理情報とをファイルに記録するファイル記録方法であって、上記ファイル中に上記管理情報を一括して記録するための予約領域を生成する予約領域生成処理と、上記チャンクデータを上記ファイル中の異なる位置に再配置するデータ再配置処理と、上記データ再配置処理において、上記予約領域のサイズを変更する処理とをコンピュータに実行させることを特徴としている。
【００２８】
本発明のコンピュータ読み取り可能な記録媒体は、上記に記載のコンピュータプログラムを記録したことを特徴としている。
【発明の効果】
【００２９】
以上説明したように、本発明によれば、従来規格との互換性が保たれた形式で管理情報をファイルに出力することを、少ないオーバーヘッドで実現することができる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明のファイル記録方法、ファイル記録装置、コンピュータプログラム及びコンピュータ読み取り可能な記録媒体の実施の形態について、図面を参照しながら説明する。本発明は、ファイル中のデータ構造を必要に応じて再配置を行なうことによって、マージ処理を行なうことなく動画像データの管理情報を記録するものである。
【００３１】
なお、本発明の実施形態では、記録された動画像の最終出力形式にはＭＰ４ファイル形式を用いるものとする。しかし、本発明が適用できる対象は必ずしもＭＰ４ファイルに限定されるものではなく、例えば、QuickTime形式のようなＭＰ４ファイルと類似の構造を持ったファイル形式に対しても適用されうることは言うまでもない。
【００３２】
＜第１の実施の形態＞
図４は、本発明の動画像記録装置の基本構成例を示す図である。
図４において、本実施の形態の動画像記録装置は、記録する動画像を取り込む動画像入力部１と、同じく音声を取り込む音声入力部２と、取り込まれた動画像及び音声の圧縮符号化処理を行ない、デジタル符号化形式のサンプルデータ及び各サンプルのサイズやタイムスタンプといった管理情報を生成する動画像符号化部３及び音声符号化部４と、サンプルデータ及び管理情報を多重化して出力ファイル８に出力するファイル出力部５と、管理情報を出力ファイル８に出力するまでの間、一時的に保管しておく管理情報記憶部６と、出力ファイル８に記録されたデータブロックを、ファイル中の別の位置へ移動させるデータ構造再配置部７から構成される。上記のファイル出力部５、管理情報記憶部６、データ構造再配置部７によって、本実施の形態における基本処理を実行する記録部１０が構成される。
【００３３】
動画像入力部１、音声入力部２に入力される動画像及び音声は、カメラあるいはマイクロホンなどの入力装置や、外部記録・記憶装置または媒体から、何らかの伝送手段を介して入力されるものとする。図４ではこれらの装置・媒体の記述は省略している。また、出力される出力ファイル８は、いずれかの記録・記録装置あるいは媒体によって保持されるものとする。
【００３４】
記録部１０に含まれない部分、すなわち、動画像入力部１、音声入力部２、動画像符号化部３及び音声符号化部４は、実施の形態によって異なる構成になる場合もありえる。例えば、図４において、動画像と音声の入力系統はそれぞれ１つずつとしているが、それぞれ任意の数の入力系統が存在してもよい。すなわち、記録部１０に対して複数の動画像・音声チャネルの入力系統が存在していても、動画像あるいは音声のいずれか一方の入力系統のみであってもよい。
【００３５】
また、記録部１０にあらかじめ符号化された状態のデータが直接入力されてもよい。その場合、動画像入力部１、音声入力部２、動画像符号化部３及び音声符号化部４は不要となる。その他、本発明の意図が正しく実現される限りにおいては、各構成部の論理的・物理的配置や実装形態はいかなるものであってもよい。
【００３６】
続いて、図４の記録装置内で行なわれる典型的な処理の流れについて説明する。
まず、上記の記録装置は、動画像を動画像入力部１から取り込む。そして、取り込まれた動画像の映像信号が、動画像符号化部３に逐次渡される。同様にして、音声は音声入力部２から取り込まれ、音声符号化部４に音声信号が渡される。
【００３７】
動画像符号化部３では、入力された映像信号を、MPEG-4等の所定の圧縮符号化形式で符号化して動画像サンプルデータを出力する。音声の場合も同様に、音声符号化部４で入力された音声信号が符号化され、音声サンプルデータが出力される。
【００３８】
上記符号化処理によって得られたサンプルデータは、ファイル出力部５を介して、Media Data Atomに含まれるチャンクデータとして出力ファイル８に書き込まれる。
ファイル出力部５は、ファイルの先頭から少し離れた位置からMedia Data Atomを出力し、以降はファイル末尾にチャンクデータを追加記録する。ファイル先頭からMedia Data Atomの開始位置までの領域は、図１で示されるように、管理情報を格納するMovie Atomを出力するための予約領域として用いられる。
【００３９】
ファイル出力部５は、サンプルデータを受け取った時点で即座に出力ファイル８に記録しても、渡されたサンプルデータを一時的に蓄積し、ある程度のサンプルデータが蓄積された時点でチャンクとしてまとめて記録してもよい。また、複数のサンプルデータあるいはチャンクデータがまとめてファイル出力部５に受け渡されてもよい。
【００４０】
動画像符号化部３及び音声符号化部４では、上記符号化処理によって得られたサンプルのサイズ、タイムスタンプといった管理情報も同時に生成され、ファイル出力部５に受け渡される。渡された管理情報は、さらに管理情報記憶部６に渡される。
【００４１】
管理情報記憶部６では、出力ファイル８に書き出されるデータ構造の管理情報を参照及び更新する機能や、必要に応じてMovie Atomの形式に変換し、ＭＰ４ファイル出力部５に対して出力を要求する機能を有する。管理情報は、実装によっては何らかの一時記憶手段によって保管されることもありえる。この一時記憶は、中間ファイルやＲＡＭファイルなど、比較的大容量の記憶手段として実現されるのが一般的であろう。
【００４２】
さらに、管理情報記憶部６では、Movie Atomの形式で書き出される状態の管理情報のデータサイズを保持する。このデータサイズは、管理情報記憶部６に管理情報データが渡されるたびに再計算が行なわれ、最新の状態に更新される。
【００４３】
サンプルの出力を繰り返し、管理情報の末尾がファイル先頭の予約領域のサイズを越えてしまう場合、管理情報記憶部６はデータ構造再配置部７に対して出力済みのチャンクデータの再配置を要求する。
【００４４】
データ構造再配置部７は、管理情報として保管されているチャンクの位置やサイズなどを管理情報記憶部６から受け取り、先頭のチャンクデータをファイル末尾に再配置する。同時に、再配置されたチャンクの管理情報を、再配置後の位置に合わせて更新する。再配置されたチャンクがあった領域は、Movie Atom用に確保された予約領域として使用できるようになる。すなわち、再配置処理が実行されることによって、ファイル先頭の予約領域が拡張されることになる。
【００４５】
データ構造再配置部７は、管理情報記憶部６で蓄積されている管理情報を出力するのに十分な大きさの予約領域が得られるまで、上記の再配置処理を繰り返す。そして、予約領域が十分な大きさになったら再配置処理を終了し、管理情報記憶部６に制御を戻す。
【００４６】
なお、データ構造再配置部７は、チャンク再配置によってファイル形式が規格と矛盾することのないよう、チャンクデータ以外のデータブロックの再配置や変更も行ない、ファイル構造を正しく保つ処理も行なう。
【００４７】
図４の記録装置において上記の処理が行なわれることによって、管理情報を記録するのに十分な大きさを持った予約領域がファイル先頭に確保されている状態が実現される。この予約領域のあとにはMedia Data Atomが続くため、蓄積されている管理情報をMovie Atom形式にして予約領域に出力するだけで、図１で示されるようなＭＰ４ファイルを作成することができる。
【００４８】
なお、最初に確保される予約領域は原理的には任意の大きさにすることができるが、実用上は再配置の回数を減らすため、ある程度の大きさがある方がよいかもしれない。しかし、あまり大きすぎるとＭＰ４ファイル中に無駄な領域が発生し、ＭＰ４ファイルのサイズが増大してしまうため、適用する形態に応じて妥当な大きさを設定することが望ましい。
【００４９】
空き領域のサイズを０、すなわち初期状態で空き領域を確保しないようにすることも可能である。ただしこの場合、最初にMovie Atomのサイズ計算が行われた時点でチャンクの再配置が発生するため、実質的には最初に空き領域を確保する場合と同等の処理が行われる。
【００５０】
＜ＭＰ４のメタデータ構造＞
引き続き、本実施の形態の詳細を説明するにあたって、ＭＰ４ファイル形式においてサンプルやチャンクの管理情報がどのような形で保持されるかに関して簡単に説明する。なお、本明細書では発明の内容を説明するために不要な部分は省略しているため、説明及び図で示される内容は実際のＭＰ４の構造を完全に反映するものではないことに注意されたい。
【００５１】
図５は、ＭＰ４ファイルにおいてメタデータがどのようなデータ構造を持ち、どのようにメディアデータを参照するかを説明するための図である。
図５において、サンプルＳ１はサンプルを、Ｃ１はサンプルＳ１が含まれるチャンクを示す。すべてのサンプル及びチャンクに関するメタデータ情報はMovie Atomに記録されているため、サンプルＳ１及びＣ１の情報はMovie Atomの内容にアクセスすることで取得することができる。
【００５２】
Movie Atom内には、ＭＰ４ファイル中のデータトラックのメタデータ情報を保管する「Track Atom」（typeフィールドの値は‘trak'）というアトムが格納される。各データトラックは、「トラックＩＤ」と呼ばれるＭＰ４ファイルで一意な識別子で識別されるようになっており、Track Atomには、トラックＩＤなどのデータトラックに関する情報を記述する。また、すべてのチャンク及びサンプルはいずれかのデータトラックに属することになっているため、それぞれのデータトラックを構成する全てのチャンク及びサンプルのメタデータ情報も、Track Atomに記述されるようになっている。
【００５３】
Track Atom中のチャンク及びサンプルに関するメタデータ情報を格納するアトムには、「Sample Size Atom」（typeフィールドの値は‘stsz'）、「Sample to Chunk Atom」（typeフィールドの値は‘stsc'）、「Chunk Offset Atom」（typeフィールドの値は‘stco'）などといったものがある。
【００５４】
Sample Size Atomはサンプルのサイズ（entry-size）を、Sample to Chunk Atomはサンプルが含まれるチャンクの情報を、Chunk Offset Atomはチャンクのファイル内のオフセット位置をそれぞれ管理している。
【００５５】
サンプルＳ１のデータをMedia Data Atomから取得するためには、まず、サンプルＳ１が最初から何番目かのサンプルであるかを示すサンプル番号を確認し、サンプル番号に対応するSample Size AtomのエントリからサンプルＳ１のサンプルサイズを取得する。
【００５６】
そして、そのサンプル番号を用いて、サンプルＳ１が含まれるチャンクの番号をSample to Chunk Atomから取得し、さらに、Chunk Offset Atomから、そのチャンク番号で示されるチャンクの先頭オフセット位置を取得する。この時、サンプルＳ１がチャンクＣ１の最初のサンプルでない場合は、チャンク先頭からサンプルＳ１の間に存在する各サンプルのサイズをSample Size Atomから取得し、サイズの総和を計算する。この総サイズをＣ１のオフセット位置に加えた位置がサンプルＳ１の開始オフセットとなる。以上のようにして得られるサンプルＳ１の開始オフセット及びサイズを用いて、Media Data AtomからサンプルＳ１のサンプルデータを抽出できるようになる。
【００５７】
次に、上記のサンプルデータ取得処理の具体例を図６を用いて説明する。例として、図５におけるサンプルＳ１が、トラックＩＤ＝２のデータトラックの最初のサンプル（サンプル番号＝１）である場合を想定する。
【００５８】
（１）トラックＩＤ＝２のTrack Atomを検索し、その中に含まれるSample Size Atomから、サンプル番号１に対応する最初のエントリＥ１を取得する。サンプルＳ１の場合は、エントリＥ１の値0x2801がサンプルのサイズとなる。なお、すべてのサンプルが同じサイズを持つ場合は、Sample Size Atomにはのデフォルトサンプルサイズをただ一つのエントリが格納される。その場合、サンプルＳ１のサイズはそのデフォルトサンプルサイズとなる。
【００５９】
（２）Sample to Chunk Atomから、サンプル番号＝１に対応する最初のエントリＥ２のfirst-chunkとして記録されているチャンク番号を取得する。
Sample to Chunk Atomのエントリは、同じエントリの内容を持つチャンクが連続している場合、連続するチャンクの先頭のチャンク番号がfirst-chunkに記録され、２番目以降のチャンクの属性は記録されずに省略されるようになっている。
【００６０】
すなわち、図６ではエントリＥ２から次のエントリの間に、（４―１＝２）個のチャンク、（４＊（４−１）＝８）個のサンプルの情報が暗黙裏に記録されていることになる。よって、サンプル番号に対応するエントリの実体がSample to Chunk Atomに存在しない場合は、省略されているエントリのチャンク番号を求めなければならない。今回の例では、サンプル番号＝１に対応するエントリＥ２のfirst-chunkの値１が、サンプルＳ１を含んでいるチャンクＣ１のチャンク番号となる。
【００６１】
（３）チャンク番号＝１に対応するSample Size Atomの最初のエントリＥ３から、チャンクのオフセット位置を取得する。今回の例では、0x05a2aがチャンクＣ１のオフセット位置となる。このオフセット位置に、チャンク先頭から取得対象サンプルの間に存在するサンプルの総サイズを加算して得られた値が、取得対象のサンプルのオフセット位置となる。サンプルＳ１はチャンク先頭のサンプルであるため、サンプルＳ１のオフセット位置は（0x05a2a＋0＝0x05a2a）となる。上記の処理によって、サンプルＳ１のデータはオフセット位置0x05a2aから0x2801バイトの間に記録されていることが導出される。
【００６２】
＜チャンクの再配置＞
サンプル及びチャンクに関するメタデータ情報の検索には、それらの出現順を示す番号が非常に重要な意味を持っているため、基本的にＭＰ４のアトム構造のエントリは、チャンクやサンプルの出現順と同じ順序で時系列に記録されなければならない。
【００６３】
また、Sample to Chunk Atomのようにエントリの内容が直前のエントリの値に依存するようなアトムでは、既存のエントリの値を変更すると後続のエントリに影響が及んでしまうため、エントリの値を変更することはできない。
【００６４】
しかし、Chunk Offset Atomの場合、エントリはアトム中の他のエントリとの依存関係は持たないため、各エントリの内容を変更しても他のエントリに影響が及ぶことはない。Chunk Offset Atomのエントリの内容はファイル中の絶対位置であり、必ずしも昇順に整列していなくてもよい。
【００６５】
したがって、Chunk Offset Atomのエントリの値を変更するだけで、そのエントリが示すチャンクの位置を任意の場所に設定することが可能である。例えば図６の場合は、チャンクＣ１のオフセット位置を変更するには、Chunk Offset AtomのエントリＥ３の値を変更すればよい。本実施の形態では、上記のChunk Offset Atomの特徴を利用してチャンクの再配置処理を行なう。
【００６６】
＜再配置処理のフロー＞
以下、本実施の形態で行われるチャンクの再配置処理の具体的な手順を、図７のフローチャートを用いて説明する。
【００６７】
（ステップＳ７１）図４の記録装置において記録動作が開始されると、まず、ファイル作成部５によって出力ファイル８が初期状態で作成される。
【００６８】
図８は、ファイル作成部５によって作成される出力ファイル８の構成を示す図である。ファイル作成部５は、Media Data Atomより前にMovie Atomを書き込むための予約領域として、あらかじめ任意のサイズの空き領域が設定された状態で出力ファイル８を作成する。空き領域は、ＭＰ４規格では、「Free Space Atom」（typeフィールドの値は‘free'あるいは‘skip'）と呼ばれる空き領域を示すアトムを配置することによって設定できる。以下、この空き領域の先頭オフセット位置をＦｐと表わす。
【００６９】
図８において、Movie Atomの先頭オフセット位置はＭｐ、Movie AtomのサイズはＭｓ（＝Ｆｐ−Ｍｐ）として表される。初期状態ではＦｐはＭｐと同じ位置であるが、出力ファイル８にMovie Atomが書き出されるたびに、Ｆｐの位置は（Ｆｐ＋Ｍｓ）の位置に押し下げられる。
【００７０】
Media Data Atomは空き領域の直後に配置され、以降はファイルの末尾にチャンクデータが順次書き込まれていく。図８では、Media Data Atomの先頭オフセットはＤｐと表わす。すなわち、利用可能な空き領域のサイズは（Ｄｐ−Ｆｐ）となる。
【００７１】
また、図８では、Media Data Atomに格納されるＮ個のチャンクの開始オフセット位置はＣｐ［１］，Ｃｐ［２］・・・Ｃｐ［ｎ］、サイズはＣｓ［１］，Ｃｓ［２］・・・Ｃｓ［ｎ］と表わす。（Ｃｐ［１］−Ｄｐ）は、Media Data Atomのヘッダのバイト長、すなわち（sizeof(size)＋sizeof(type)＝８）となる。図８で示されるオフセット位置及びサイズは、管理情報記憶部６によって初期化され、以降記録動作が終了するまで管理される。
【００７２】
（ステップＳ７２）ファイル出力部５は、サンプルのデータを受け取ると、出力ファイル８の末尾に出力していく。出力はサンプルを受け取るたびに行われても、複数のサンプルをまとめて出力してもよい。
【００７３】
（ステップＳ７３）管理情報記憶部６は、ステップＳ７２において渡されたサンプルの管理情報をファイル出力部５から受け取り、内部的に保管する。同時に、受け取った管理情報を含むすべての管理情報をMovie Atom形式にしたときのサイズを計算し、算出されたサイズをＭｓとして記憶する。
【００７４】
（ステップＳ７４）管理情報記憶部６は、Ｆｐで示されるMovie Atomの末尾オフセット位置が、Media Data Atomの先頭オフセット位置Ｄｐを超えるかどうかをチェックする。
Movie AtomがMedia Data Atomと重なる場合、すなわち（Ｆｐ＞Ｄｐ）の場合は、Media Data Atomの内容がMovie Atomの内容で上書きされてしまうため、チャンク再配置処理を行なうためステップＳ７４以降の処理に進む。（Ｆｐ＜＝Ｄｐ）の場合は、チャンク再配置は不要なのでステップＳ７２に戻る。
【００７５】
（ステップＳ７５）管理情報記憶部６は、データ構造再配置部７にチャンクの再配置を行なうよう要求する。データ構造再配置部７は、管理情報記憶部６に保管されている管理情報からMedia Data Atomの先頭に記録されているチャンクのオフセット位置Ｃｐ［１］及びサイズＣｓ［１］を取得し、Ｃｐ［１］からＣｐ［２］までの先頭チャンクのデータをファイル末尾にコピーする。
【００７６】
その際、データ構造再配置部７は、まずMedia Data Atomのsizeフィールドの値にコピーするチャンクのサイズＣｓ［１］を加算してMedia Data Atomの領域を拡張したのち、ファイル末尾に先頭チャンクのデータを追加する。
【００７７】
なお、管理情報記憶部６は、上記Ｃｐ［１］の取得処理を効率的に行なうため、先頭チャンクの位置を記憶しておくようにしてもよい。先頭チャンクのオフセット位置は初期状態ではファイルの末尾位置であり、以降再配置が発生した時点で更新される。
【００７８】
（ステップＳ７６）データ構造再配置部７は、先頭チャンクのデータをコピーし終えたら、コピーされたチャンクのオフセット位置がコピー先の位置になるよう、管理情報記憶部６で管理されているChunk Offset Atomのエントリを更新する。エントリが更新された時点で、コピー元の位置にあるチャンクのデータはどこからも参照されることはなくなる。
【００７９】
（ステップＳ７７）データ構造再配置部７は、管理情報記憶部６から２番目のチャンクのオフセット位置Ｃｐ［２］を取得し、Media Data AtomのヘッダをＣｐ［２］の直前にコピーする。
【００８０】
データ構造再配置部７は、Media Data Atomのヘッダをコピーする際に、アトムのサイズがＣｓ［２］からＣｓ［ｎ］の総サイズと等しくなるよう、、sizeフィールドの値を更新する。
【００８１】
コピー完了時点で、Media Data Atomのヘッダは２つ存在することになるが、新しくコピーされたヘッダは後続のステップＳ７８の処理が完了した時点ではじめて参照されるようになるため、通常は問題は発生しない。
【００８２】
ただし、再配置されるチャンクのサイズがMedia Data Atomのヘッダよりも小さい場合、すなわち７バイト以下の場合は、ステップＳ７７のコピー処理によって既存のMedia Data Atomのヘッダの内容は破壊されてしまい、ステップＳ７８の処理が完了するまで一時的にMedia Data Atomが参照不能な状態が発生してしまう。したがって、本実施形態においては、チャンクは少なくとも８バイト以上のデータブロックにして記録することが望ましい。
【００８３】
（ステップＳ７８）データ構造再配置部７は、管理情報記憶部６からＦｐ及びステップＳ７７でコピーしたMedia Data Atomの先頭オフセット位置（Ｃｐ［２］−８）を取得し、両者間の領域を空き領域にする。
【００８４】
データ構造再配置部７は、Ｆｐの位置に存在するFree Space Atomのsizeフィールドの値を、（Ｆｐ＋（Ｃｐ［２］−８））に更新することによって、空き領域を拡張する。
Free Space Atomの拡張が完了したら、管理情報記憶部６で記憶されているＤｐの値を、Media Data Atomの先頭オフセット位置（Ｃｐ［２］−８）に更新する。
【００８５】
以降、ステップＳ７４に戻り、Movie Atomの内容が予約領域内に収まるようになるまで再配置処理が繰り返し行われる。なお、ステップＳ７４に戻る前のチャンクのオフセット表現Ｃｐ［２］〜Ｃｐ［ｎ＋１］は、ステップＳ７４に戻った後はＣｐ［１］〜Ｃｐ［ｎ］として処理する。上記のステップによってチャンクの再配置が実行され、出力ファイル８には常に管理情報が十分記録できる領域が確保されている状態が維持される。
【００８６】
図７のフローチャートでは、管理情報を出力ファイル８に出力するタイミングは明記していないが、実際にはステップＳ７２以降の任意のタイミングで管理情報を書き出すことが可能である。管理情報の出力を定期的に行なうようにすれば、その時点で正しく再生可能なＭＰ４ファイルができる。
【００８７】
以上説明した方法によれば、管理情報をファイルに出力する際に、メディアデータのマージ処理を行なわずに管理情報データのみ出力すれば良くなるため、ファイル出力に要する時間を短縮できるようになる。
【００８８】
一般的なＭＰ４ファイルでは、メディアデータの方が管理情報よりもサイズが大きくなるケースが多いため、マージ処理が不要になれば、出力すべきデータ量と出力に要する時間は半分以下になることが期待できる。
【００８９】
チャンクの再配置が発生した場合はメディアデータの再入出力処理が発生するが、その際のデータサイズは処理対象となるチャンクの総量に限定されるため、従来のマージ処理と比較して再入出力されるメディアデータのサイズは小さくて済む。あらかじめ十分な予約領域が確保されていれば、チャンクの再配置が発生しないこともあるため、メディアデータの再入出力を一切行なわずに済むこともある。
【００９０】
また、以上の方法によれば、メディアデータは直接ＭＰ４ファイルに出力されるため、一時記憶領域は管理情報を保持できるだけの容量で済む。その結果、装置に搭載する一時記憶を小さくしてコストを削減させたり、記録可能な時間の上限値を長くして性能を上げたりといった効果が得られるようになる。
【００９１】
＜第２の実施の形態＞
第２の実施の形態として、末尾のチャンクを予約領域に戻すような再配置を行なう処理を説明する。
上記第１の実施の形態において、最初に確保される予約領域のサイズが大きすぎる場合は、記録完了の時点でファイル冒頭部に大量の未使用領域が残ってしまい、結果としてＭＰ４ファイルのサイズが不必要に増大してしまう。第２の実施の形態では、ファイルの領域を有効に活用するため、記録完了後に末尾のチャンクを前方に再配置することによって、予約領域の余剰分をメディアデータ領域として再利用するといった処理について説明する。
【００９２】
なお、環境によっては、ファイルの終了位置を指定することでファイルサイズを拡張・縮小する機能が提供されているものもあるが、本実施の形態の実行環境では、記録完了時にこの機能を利用してファイルサイズを縮小することが可能であるものとする。
【００９３】
＜再配置処理のフロー＞
以下、図９のフローチャートを用いて、メディアデータの記録が完了した後に実行される前方へのチャンク再配置処理を説明する。なお、説明において使用されるオフセット位置やサイズなどの表現は、第１の実施の形態と同様に、図８で示される記号を用いる。
【００９４】
（ステップＳ９１）図４の記録装置においてメディアデータの記録が終了すると、管理情報記憶部６は、現在の空き領域のサイズＦｓと、出力ファイル８の末尾に記録されているチャンクｎのサイズＣｓ［ｎ］とを比較し、チャンクの再配置が可能であるかどうかをチェックする。
【００９５】
このチェックの結果、
（Ｆｓ＞＝Ｃｓ［ｎ］）の場合は、ステップＳ９２に進み、末尾のチャンクを前方に移動する処理を行なう。さもなければ、チャンク再配置処理は不要なので、その時点で処理を終了する。
【００９６】
（ステップＳ９２）管理情報記憶部６は、データ構造再配置部７にチャンクの再配置を行なうよう要求する。データ構造再配置部７はまず、管理情報記憶部６からMedia Data Atomの開始位置Ｄｐ及び再配置対象のチャンクｎのサイズＣｓ［ｎ］を取得し、Media Data Atomのヘッダ部を再配置後のオフセット位置（Ｄｐ−Ｃｓ［ｎ］）にコピーする。
【００９７】
その際、データ構造再配置部７はコピーされるMedia Data Atomのsizeフィールドの値にＣｓ［ｎ］を加算した状態でコピーを行なう。すなわち、コピー直後のMedia Data Atomには、再配置されるチャンクｎが含まれている状態になっている。
【００９８】
Media Data Atomのヘッダ部のコピーが完了したら、管理情報記憶部６で記憶されているＤｐの値を、Media Data Atomの先頭オフセット位置（Ｄｐ−Ｃｓ［ｎ］）に更新する。なお、上記第１の実施の形態のステップＳ７７で説明したように、（Ｃｓ［ｎ］＜８）の場合は、既存のMedia Data Atomのヘッダが上書きされてしまうため、チャンクのサイズは８バイト以上になっていることが望ましい。
【００９９】
（ステップＳ９３）データ構造再配置部７は、管理情報記憶部６からＦｐ及びＦｓを取得し、Ｆｐの位置に存在するFree Space Atomのsizeフィールドの値を、（Ｆｐ―Ｄｐ）に更新することによって、空き領域のサイズを縮小する。同時に、管理情報記憶部６で記憶されているＦｓの値を（Ｆｐ―Ｄｐ）に更新する。
【０１００】
（ステップＳ９４）データ構造再配置部７は、ステップＳ９２で取得されたオフセット位置Ｃｐ［ｎ］及びサイズＣｓ［ｎ］をもとに、末尾のチャンクｎをステップＳ９２でコピーされたMedia Data Atomのヘッダ直後の位置（Ｄｐ＋８）にコピーする。
【０１０１】
（ステップＳ９５）データ構造再配置部７は、末尾チャンクｎのデータをコピーし終えたら、Chunk Offset Atom中の末尾チャンクｎに対応するエントリに記録されているオフセット位置を、コピー先の位置に変更する。エントリが更新された時点で、コピー元の位置にあるチャンクのデータはどこからも参照されることはなくなる。
【０１０２】
（ステップＳ９６）データ構造再配置部７は、ステップＳ９２でコピーされたMedia Data Atomのsizeフィールドの値から、再配置されたチャンクｎのサイズＣｓ［ｎ］を減算した値を再度設定する。その結果、Media Data Atomから再配置を行なう前のチャンクｎのデータは除外され、sizeフィールドの内容は再配置処理が行われる前の状態に戻ることになる。
【０１０３】
（ステップＳ９７）データ構造再配置部７は、実行環境が提供するファイルサイズの変更機能を用いて、ファイルサイズをチャンクｎの再配置前のオフセット位置Ｃｐ［ｎ］に変更する。その結果、ファイルサイズは再配置前と比較してＣｓ［ｎ］だけ縮小される。
【０１０４】
以降、ステップＳ９１に戻り、空き領域が十分に小さくなるまで再配置処理が繰り返し行われる。なお、ステップＳ９１に戻る前のチャンクのオフセット表現Ｃｐ［１］〜Ｃｐ［ｎ−１］は、ステップＳ９１に戻った後はＣｐ［２］〜Ｃｐ［ｎ］として、Ｃｐ［ｎ］はＣｐ［１］として処理する。
【０１０５】
以上説明した方法によれば、上記第１の実施の形態では不必要に大きくなっていた出力ファイルのサイズを、現実的なサイズまで縮小することができるようになる。
【０１０６】
＜他の実施の形態＞
本発明は、複数の機器（例えばホストコンピュータ、インタフェース機器、ライター、エンコーダなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、ビデオカメラ装置など）に適用してもよい。
【０１０７】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１０８】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１０９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１０】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【０１１１】
【図１】ＭＰ４ファイル形式の構造を単純化して示す図である。
【図２】Data Reference Atomを用いたＭＰ４ファイルの構造を示す図である。
【図３】Movie Fragment Atomを用いたＭＰ４ファイルの構造を示す図である。
【図４】本発明の実施形態における動画像記録装置の構成例を示す図である。
【図５】ＭＰ４ファイルにおけるメタデータ構造及びメディアデータとの相関の一例を示す図である。
【図６】ＭＰ４ファイルにおけるサンプルデータ及び管理情報の記録形態の一例を示す図である。
【図７】本発明の第１の実施の形態におけるチャンク再配置処理の一例を示すフローチャートである。
【図８】本発明の実施形態において出力されるＭＰ４ファイルの構造を示す図である。
【図９】本発明の第２の実施の形態におけるチャンク再配置処理の一例を示すフローチャートである。
【符号の説明】
【０１１２】
１  動画像入力部
２  音声入力部
３  動画像符号化部
４  音声符号化部
５  ファイル出力部
６  管理情報記憶部
７  データ構造再配置部
８  出力ファイル
１０  記録部
【図１】
2005065110.tif 000003
【図２】
2005065110.tif 000004
【図３】
2005065110.tif 000005
【図４】
2005065110.tif 000006
【図５】
2005065110.tif 000007
【図６】
2005065110.tif 000008
【図７】
2005065110.tif 000009
【図８】
2005065110.tif 000010
【図９】
2005065110.tif 000011