JP5317738B2

JP5317738B2 - 記録装置

Info

Publication number: JP5317738B2
Application number: JP2009023719A
Authority: JP
Inventors: 秀一細川
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2009-02-04
Filing date: 2009-02-04
Publication date: 2013-10-16
Anticipated expiration: 2029-02-04
Also published as: JP2010183247A

Description

本発明は、記録装置に関する。

特開２００７−２３５５７０号公報

従来、記録媒体にビデオデータを記録するためのフォーマットとして、ＭＸＦ（Material Exchange Format）が知られている。また、ＭＸＦフォーマットでビデオデータを記録する記録装置が、例えば、特許文献１に記載されている。

ＭＸＦデータは、デジタルビデオデータに、当該デジタルビデオデータに対するアクセス情報からなるインデックステーブルを組み合わせたフォーマットである。ＭＸＦデータのインデックステーブル（ＩＴ）は、デジタルビデオデータのフレーム境界を示す。ＩＴを用いることで、デジタルビデオデータに対してフレーム単位でランダムアクセスが可能になる。

ＭＸＦデータを記録媒体に記録している間に、瞬断等の要因により記録が不完全停止すると、ＭＸＦデータの修復が必要になる。ＭＸＦデータの修復には、不完全なビデオフレームの破棄等に加えて、インデックステーブルの修復が必要となる。

インデックステーブルは、ＭＸＦデータに含まれる動画データを、フレーム単位でランダムアクセスするのに用いられる。そのために、インデックステーブルには、内包する全ビデオフレームの境界を格納する必要がある。そこで、インデックステーブルの修復には、ＭＸＦデータのフレーム境界をサーチする。別の方法として、記録時にフレーム境界を予め不揮発性メモリ等に保存しておき、その不揮発性メモリの記憶データを参照する方法がある。

前者の方法は、フレーム境界をサーチするために時間を要する。後者の方法は、不揮発性メモリの搭載が必要であり、コストアップに繋がる。

本発明は、特別のメモリを必要とせずに、インデックステーブルの修復を短時間に実行できる記録装置を提示することを目的とする。

本発明に係る記録装置は、動画データを入力する入力手段と、ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、前記記録媒体に記録されたファイルを修復する修復手段とを備え、前記ファイルフッタは前記ファイルフッタのオフセットに関する情報を含み、前記記録手段は、前記所定フレーム数の動画データと、その次の領域に格納される前記第１の情報と前記第２の情報とを記録単位として前記記録媒体に記録し、前記ファイルフッタの記録を停止した後、前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納し、前記修復手段は、前記ファイルフッタのオフセットに関する情報を複数の前記領域における前記第１の情報に格納する前に記録が停止された場合、前記ファイルフッタに格納された前記ファイルフッタのオフセットに関する情報を前記記録媒体から読み出し、読み出した前記ファイルフッタのオフセットに関する情報を複数の前記領域における前記第１の情報にそれぞれ格納することにより修復を行うことを特徴とする。
本発明に係る記録装置は、動画データを入力する入力手段と、ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、前記記録媒体に記録されたファイルを修復する修復手段とを備え、前記ファイルフッタは前記ファイルフッタのオフセットに関する情報を含み、前記記録手段は、前記所定フレーム数の動画データと、その次の領域に格納される前記第１の情報と前記第２の情報とを記録単位として前記記録媒体に記録し、前記ファイルフッタの記録を停止した後、前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納し、前記修復手段は、前記ファイルフッタが記録される前に前記ファイルの記録が停止された場合、前記ファイルにおける最後の前記領域に格納された前記第１の情報を前記ファイルフッタのオフセットに関する情報として変更し、変更された前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納することにより修復を行うことを特徴とする。
本発明に係る記録装置は、動画データを入力する入力手段と、ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、前記記録媒体に記録されたファイルを修復する修復手段とを備え、前記ファイルフッタは、前記ファイルにおける複数の前記領域それぞれのオフセットに関する情報を含み、前記第１の情報は、一つ前の前記領域のオフセットに関する情報を更に含み、前記修復手段は、前記ファイルフッタが記録される前に前記ファイルの記録が停止された場合、複数の前記領域の前記第１の情報に基づいて複数の前記領域それぞれのオフセットを検出し、検出した複数の前記領域それぞれのオフセットを含むファイルフッタを生成して前記記録媒体に記録することにより修復を行うことを特徴とする。

本発明によれば、上述の書込み単位を採用することで、瞬断等の要因により記録が不完全停止した際に、インデックステーブルの修復が不要になり、短時間で不完全なＭＸＦデータを修復できる。

本実施例の概略構成ブロック図である。ロングＧＯＰの場合の復号処理を説明する図である。インターリーブＭＸＦファイルを説明する図である。インターリーブＭＸＦファイルを説明する図である。インターリーブＭＸＦファイルを説明する図である。本実施例で、記録媒体に記録されるインターリーブＭＸＦファイルの状態遷移の説明例である。本実施例の不完全インターリーブＭＸＦファイルを修復する動作のフローチャートである。

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

本発明の一実施例を説明する前に、デジタルビデオデータの代表的な圧縮符号化形式であるＭＰＥＧ（ＭｏｖｉｅＰｉｃｔｕｒｅｓＥｘｐｅｒｔｓＧｒｏｕｐ）２方式と組み合わせて利用する場合を例に、ＭＸＦフォーマットの構成を説明する。

ＭＰＥＧ２は、動き補償予測符号化とＤＣＴ（離散コサイン変換）による変換符号化とを組み合わせたものである。ＭＰＥＧ２のデータ構造は階層構造をなしており、下層からブロック層、マクロブロック層、スライス層、ピクチャ層、ＧＯＰ層及びシーケンス層からなる。ブロック層は、ＤＣＴを行う単位であるＤＣＴブロックからなる。マクロブロック層は、複数のＤＣＴブロックからなる。スライス層は、ヘッダ部と１以上のマクロブロックからなる。ピクチャ層は、ヘッダ部と１以上のスライスからなる。ピクチャは１画面に対応する。各層の境界は、それぞれ所定の識別符号で識別可能になっている。

ＧＯＰ層は、ヘッダ部（シーケンスヘッダ）と、所定数の画面についての符号化画像データからなる。ＭＰＥＧ２では、各画面の符号化方式には、フレーム内符号化と、順方向予測符号化と、双方向予測符号化が用意されている。フレーム内符号化画像（イントラ符号化画像）は、Ｉ（Ｉｎｔｒａ−ｃｏｄｅｄ）ピクチャと呼ばれる。順方向予測符号化画像は、Ｐ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ）ピクチャと呼ばれる。双方向予測符号化画像は、Ｂ（Ｂｉ−ｄｉｒｅｃｔｉｏｎａｌｌｙｐｒｅｄｉｃｔｉｖｅｃｏｄｅｄ）ピクチャと呼ばれる。

Ｉピクチャは、それ自身の情報のみで復号が可能である。これに対し、Ｐピクチャ及びＢピクチャは、参照画像として前画像又は前後の画像が必要であり、単独では復号化できない。例えば、Ｐピクチャは、自身より時間的に前のＩピクチャまたはＰピクチャを参照画像として符号化されている。Ｂピクチャは自身の前後のＩピクチャまたはＰピクチャからなる２枚の画像を参照画像として符号化されている。復号化にはこれらの参照画像の画像データが必要になる。但し、Ｐピクチャ及びＢピクチャも、画面内の小ブロックについて画面内で符号化されていることもある。

最低１枚のＩピクチャを含みそれ自身で完結しているグループが、ＧＯＰ（ＧｒｏｕｐＯｆＰｉｃｔｕｒｅ）と呼ばれる。ＭＰＥＧストリームでは、ＧＯＰが独立してアクセス可能な最小単位とされている。ＧＯＰは、１又は複数のピクチャから構成される。以下では、便宜上、１枚のＩピクチャのみで構成されるＧＯＰをシングルＧＯＰと呼び、ＩピクチャとＰ／Ｂピクチャを含む複数のピクチャからなるＧＯＰをロングＧＯＰと呼ぶ。さらに、ロングＧＯＰのうち、ＧＯＰ内で完全に復号可能な、閉じた構造をもつＧＯＰをクローズドＧＯＰと呼び、一つ前のＧＯＰに含まれる画像を復号に必要とするＧＯＰをオープンＧＯＰと呼ぶこととする。

図２を参照して、ロングＧＯＰの復号処理を説明する。図２（Ａ）は入力フレーム順、同（Ｂ）は伝送順、同（Ｃ）は復号化後の表示順をそれぞれ示す。ここでは、１枚のＩピクチャ、４枚のＰピクチャ及び１０枚のＢピクチャの計１５枚から構成されるオープンＧＯＰであるものとする。ＧＯＰ内の各フレームを、ピクチャタイプを示すＩ，Ｐ又はＢと、これに続くフレーム番号で表記する。入力フレームは、ＧＯＰ内のＩ／Ｂ／Ｐの位置は、図２（Ａ）に示すように、Ｂ０，Ｂ１，Ｉ２，Ｂ３，Ｂ４，Ｐ５，Ｂ６，Ｂ７，Ｐ８，Ｂ９，Ｂ１０，Ｐ１１，Ｂ１２，Ｂ１３，Ｐ１４となる。この例では、フレームＢ０及びＢ１は、一つ前のＧＯＰのフレームＰ１４とこのＧＯＰ内のフレームＩ２を用いて復号される。フレームＰ５はフレームＩ２から予測され、フレームＰ８／Ｐ１１／Ｐ１４はそれぞれ、一つ前のＰピクチャであるフレームから予測される。

Ｂピクチャは、前後のＩピクチャ及びＰピクチャのフレームから予測される。このため、伝送路又は記録媒体上では、Ｉ／Ｂ／Ｐピクチャの並び順は、復号順を考慮して決める必要がある。図２の例では、図２（Ｂ）に示されるように、Ｉ２，Ｂ０，Ｂ１，Ｐ５，Ｂ３，Ｂ４，Ｐ８，Ｂ６，Ｂ７，Ｐ１１，Ｂ９，Ｂ１０，Ｐ１４，Ｂ１２，Ｂ１３の順となる。

復号器は、図２（Ｃ）に示すように、まずフレームＩ２を復号する。そして、このフレームＩ２と一つ前のＧＯＰのフレームＰ１４を用いてフレームＢ０，Ｂ１を復号して出力し、次に、フレームＩ２を出力する。

次に、フレームＰ５を、フレームＩ２を用いて復号する。フレームＢ３，Ｂ４をフレームＩ２，Ｐ５を用いて復号して出力し、続けてフレームＰ５を出力する。

以下同様に、Ｂピクチャの復号に必要なＩピクチャ及びＰピクチャをこのＢピクチャより先に復号して出力し、その後、Ｉ／Ｐピクチャを出力する。

図３、図４および図５を参照して、ＭＸＦフォーマットのＭＰＥＧストリームに対するマッピング構造例を説明する。

ＭＸＦは、ＳＭＰＴＥ（Society of Motion Picture and Television Engineers）に規定されるファイルフォーマット規格である。ここで説明するＭＰＥＧストリームに対するマッピング構造は、ＳＭＰＴＥ−３８１Ｍに規定されている。以下、ＭＳＰＴＥ−３８１ＭなどのＭＸＦ規定に準じ、映像データと音声データがフレームインターリーブされた構造をもつＭＸＦファイルを、インターリーブＭＸＦファイルと呼ぶ。

図３（Ａ）は、インターリーブＭＸＦファイルのファイル構造を示す。図３（Ａ）に示されるように、インターリーブＭＸＦファイルは、ファイルヘッダ（ＦＨ）、ファイルボディ（ＦＢ）およびファイルフッタ（ＦＦ）からなる。ファイルヘッダは、ヘッダパーティションパック（ＨＰＰ）とヘッダメタデータからなる。ＨＰＰは、ヘッダ識別子と、ファイルボディに配置されるデータの形式又はファイルフォーマットを示す情報と、フッタパーティションパック（ＦＰＰ）格納開始オフセットなどからなる。ヘッダメタデータには、ファイル作成日時などファイル単位のメタデータが格納される。

ファイルボディは、ボディパーティションパック（ＢＰＰ）、エディットユニット（ＥＵ）及びインデックステーブル（ＩＴ）からなる。ＢＰＰは、ボディ識別子と、直前に配置されるパーティションパック（ＨＰＰ又はＢＰＰである）、並びに、自身およびＦＰＰの格納開始オフセットなどからなる。ＢＰＰで区分される領域には、０または１個のＩＴと、１又は複数のエディットユニット（ＥＵ）が配置される。ＥＵには、フレーム毎の映像音声データが可能される。ＩＴには、ＢＰＰで区切られる一つ前の領域内に含まれるＥＵの情報が格納される。ＥＵ及びＩＴの詳細は、後述する。

ファイルフッタ（ＦＦ）は、フッタパーティションパック（ＦＰＰ）、インデックステーブル（ＩＴ）およびランダムインデックスパック（ＲＩＰ）から成る。ＦＰＰは、フッタ識別子と、直前に配置されるＢＰＰと自身の格納開始オフセットなどからなる。ＲＩＰは、ＲＩＰを示すヘッダと、このインターリーブＭＸＦファイルにおける各パーティションパックの格納開始オフセットと、ＲＩＰ自身のデータサイズからなる。インターリーブＭＸＦファイルを構成する各要素（ＰＰ及びＩＴ等）の直後には、境界調整用のフィルアイテム（ＮＵＬＬデータ）が配置される。但し、説明簡略化のため、図面及び以下の説明から省略する。

ＢＰＰで区切られる領域毎のＥＵの集合体は、エッセンスコンテナ（Essence Container）と呼ばれる。すなわち、エッセンスコンテナは、このインターリーブＭＸＦファイルに基づき実際に再生される映像音声データを収容する。

ファイルボディとファイルフッタに配置されるＩＴは、図３（Ｂ）に示すように、インデックステーブルセグメントの集合体である。例えば、このインターリーブＭＸＦをシステムが読み込んだ際、各ＩＴをサーチして読み出し、ＭＸＦファイル全体のＩＴを再構築する。これにより、ＭＸＦファイル全体のＥＵに関する情報を得ることができる。

図３（Ｃ）はＩＴの一構成例を示す。ＩＴは、ＫＬＶ（Key-Length-Value）符号を用いて符号化される。ＫＬＶ符号において、キー（Key）部は、ＳＭＰＴＥ−３３５Ｍ／ＲＰ２１０Ａに準拠したデータ項目を示す識別子であって、１６バイトのデータ長を有する。長さ（Length）部は４バイトのデータ長を有し、長さ（Length）部以降のデータ長をバイト単位で表記した値を保持する。バリュー（Value）部は、データ本体を格納する領域である。バリュー（Value）部は、２バイト長のローカルタグ部、２バイト長の長さ（Length）部、および、データ本体を格納する可変長のデータ部からなる。

ＩＴの内容を具体的に説明する。ＩＴの先頭には、１６バイトのインデックステーブルセグメントキーが配置される。バリュー（Value）部には、まずインスタンスＩＤ情報に対して、インスタンスＩＤを示すローカルタグ、長さ（Length）、及びインスタンスＩＤの実体が、ＵＵＩＤ（Universal Unique ID）形式で格納される。

続けて、インデックスエディットレート（Index Edit Rate）のために、ローカルタグ、長さ（Length）、及びインデックスエディットレートの実体が格納される。インデックスエディットレートは、映像データのフレームレートが２９．９７Ｈｚ／２５．００Ｈｚ／２３．９８Ｈｚのいずれであるかを示す。

続けて、インデックス開始位置（Index Start Position）が、同様に、ローカルタグ、長さ（Length）及び実体の順に格納される。インデックス開始位置は、このＩＴが管理するＥＵの、インターリーブＭＸＦファイルの先頭からの番号を示す。

続けて、インデックスデュレーション（Index Duration）が、同様に、ローカルタグ、長さ（Length）及び実体の順で格納される。インデックスデュレーションは、このＩＴが管理するＥＵの個数の情報を保持する。

続けて、エディットユニットバイトカウント（Edit Unit Byte Count）が同様に、ローカルタグ、長さ（Length）及び実体の順で格納される。エディットユニットバイトカウントは、映像フレームが固定長の場合に映像フレームのデータ長を保持し、可変長の場合には”０”を保持する。

続けて、インデックスＳＩＤが同様に、ローカルタグ、長さ（Length）及び実体の順で格納される。さらに続いて、ボディＳＩＤが同様に、ローカルタグ、長さ（Length）及び実体の順で格納される。インデックスＳＩＤ及びボディＳＩＤは、ＭＸＦファイル内で固定値となる。

続けて、スライスカウント（Slice Count）、デルタエントリアレイ（ＤＥＡ：Delta Entry Array）、及びインデックスエントリアレイ（ＩＥＡ：Index Entry Array）が同様の構造で格納される。スライスカウント、デルタエントリアレイ及びインデックスエントリアレイについては後述する。

図４は、ＥＵ及びＤＥＡの一例を示す。すなわち、図４（Ａ）はＥＵの構成を示す。図４（Ｂ）は、図３（Ｃ）に示すＩＴのＤＥＡの構成を示す。ＥＵは１フレーム分のデータを保持する。ＥＵは、当該フレームに対応するメタデータ、ＭＰＥＧ２データ及びオーディオＥＳをそれぞれ含むシステムアイテム、ピクチャアイテム及びサウンドアイテムから成る。システムアイテム（ＳＹＳ−Ｉ）及びサウンドアイテム（ＳＩ）は、固定長（ＣＢＥ：Constant Bytes per Element）である。ピクチャアイテム（ＰＩ）は可変長（ＶＢＥ：Variable Bytes per Element）である。１つのＥＵは、可変長データ毎にスライスが切られる。図４に示す例では、ＰＩが可変長であるので、ＰＩの終端でスライスが切られ、前半がスライス０、後半がスライス１とされる。ＩＴのスライスカウントには、（スライス数−１）が格納される。ＤＥＡには、ＥＵに含まれるＳＹＳ−Ｉ、ＰＩ及びＳＩの各スライス先頭からのオフセットとサイズが格納される。

図５は、エッセンスコンテナとＩＥＡの構成例を示す。すなわち、図５（Ａ）はエッセンスコンテナの構成を示す。図５（Ｂ）は、図３（Ｃ）に示すＩＴのＩＥＡの構成を示す。各インデックスエントリは、テンポラルオフセット、キーフレームオフセット、フラグ、ストリームオフセット及びスライスオフセットから成る。テンポラルオフセット（Temporal Offset）は、復号順と出力順の並べ替えの情報を示す。キーフレームオフセット（Key-Frame Offset）は、復号化に用いるキーフレームの位置情報を示す。フラグ（Flags）はフレームのタイプを格納する。ストリームオフセット（Stream Offset）は、当該ＥＵのエッセンスコンテナにおけるオフセットを示す。スライスオフセット（Slice Offset）は、当該ＥＵ内の各スライスの、ＥＵ先頭からのオフセットを格納する。

図１は、本発明の一実施例である記録装置であって、ＭＸＦで動画像データを記録媒体に記録する記録装置の概略構成ブロック図を示す。音声入力端子１０に記録すべき音声データが入力し、映像入力端子１２に記録すべき映像データが入力する。ＭＸＦ生成部１４は、入力端子１０、１２からの音声データ及び映像データからインターリーブＭＸＦファイルデータを生成して一時蓄積メモリ１６に格納する。ＭＸＦ生成部１４は、一時蓄積メモリ１６に格納したインターリーブＭＸＦファイルデータに関する情報を制御部２２に供給する。

一時蓄積メモリ１６は、ＭＸＦ生成部１４からのインターリーブＭＸＦファイルデータを一時蓄積する。一時蓄積メモリ１６はまた、記録媒体２０への書き出し／読み出しバッファとして、制御部２２のワークメモリとしても使用される。記録媒体制御部１８は、一時蓄積メモリ１６に記憶されるデータを記録媒体２０に書込み、また、記録媒体２０に記録されるデータを読み出して一時蓄積メモリ１６に格納することができる。

制御部２２は、図示した記録装置の全体を制御する。制御部２２はまた、記録媒体２０から一時蓄積メモリ１６に読み出され展開されたファイルの内容をチェックし、データを書換え・追加する機能を有する。記録媒体制御部１８は、データを書換え・追加されたファイルを一時蓄積メモリ１６から読み出して記録媒体２０に記録する。制御部２２は更に、記録媒体制御部１８を介して、記録媒体２０の記録済みインターリーブＭＸＦファイルの完全性をチェックし、不完全な場合に修復作業も行う。

ＭＸＦ生成部１４の構成と基本機能を説明する。ＭＰＥＧ２符号化部３０は、映像入力端子１２からの映像データをＭＰＥＧ２形式で圧縮符号化し、圧縮データをピクチャアイテム（ＰＩ）生成部３２に出力する。ＰＩ生成部３２は、ＭＰＥＧ２符号化部３０からのＭＰＥＧ２形式のフレーム単位の圧縮データに所定のヘッダを付加してピクチャアイテム化する。サウンドアイテム（ＳＩ）生成部３４は、音声入力端子１０からの音声データを対応する映像データのフレーム単位で分断し、所定のヘッダを付加してサウンドアイテム化する。システムアイテム（ＳＹＳ−Ｉ）生成部３６は、インターリーブＭＸＦファイルの各ＥＵ先頭に付随するシステムアイテム（ＳＹＳ−Ｉ）を生成する。ＰＩ生成部３２、ＳＩ生成部３４及びＳＹＳ−Ｉ生成部３６はそれぞれ、生成したアイテムをエディットユニット（ＥＵ）生成部３８に供給する。

ＥＵ生成部３８は、ＰＩ生成部３２、ＳＩ生成部３４およびＳＹＳ−Ｉ生成部３６からそれぞれ入力される各アイテムを結合してＥＵを生成する。生成されたＥＵは、ファイルボディ生成部４０に供給される。ＥＵ生成部３８はまた、生成したＥＵの全体サイズと各スライスのサイズをインデックステーブル（ＩＴ）生成部４２に供給する。

ＩＴ生成部４２は、ＥＵ生成部３８から受け取った全体サイズと各スライスサイズからＩＥＡとＤＥＡを生成してインデックステーブル（ＩＴ）とする。そして、ＩＴ生成部４２は、生成したＩＴをファイルボディ生成部４０及びファイルフッタ生成部４６に出力する。なお、ＩＴ生成部４２が生成するＩＴは、本実施例では固定サイズであり、ＥＵのサイズがその固定サイズに足りない場合にはフィルアイテムを詰められる。

ファイルボディ生成部４０は、ＥＵ生成部３８からのＥＵを一時蓄積メモリ１６に出力する。ファイルボディ生成部４０はまた、所定数のＥＵを一時蓄積メモリ１６に出力する毎に、ボディパーティションパック（ＢＰＰ）にＩＴを連結したデータを一時蓄積メモリ１６に出力する。詳細は後述するが、ＢＰＰは、ファイルヘッダ生成部４８からのファイルヘッダサイズを用いて生成され、ＩＴは、ＩＴ生成部４２から供給される。ファイルボディ生成部４０は、ＢＰＰを出力するまでに一時蓄積メモリ１６に出力したＥＵのデータサイズをカウントしており、そのカウント値にファイルヘッダサイズを加えたものをＲＩＰ生成部４４に出力する。

ＲＩＰ生成部４４は、ファイルボディ生成部４０から取得したＢＰＰの挿入位置を元に、ランダムインデックスパック（ＲＩＰ）を生成してファイルフッタ生成部４６に出力する。

ファイルヘッダ生成部４８は、ファイルヘッダを生成して一時蓄積メモリ１６に出力する。ファイルヘッダ生成部４８は、生成したファイルヘッダのサイズ情報を、ファイルボディ生成部４０及びファイルフッタ生成部４６に出力する。

ファイルフッタ生成部４６は、ファイルヘッダ生成部４８からのファイルヘッダサイズ情報と、ＲＩＰ生成部４４からのＲＩＰを元にフッタパーティションパック（ＦＰＰ）を生成する。ファイルフッタ生成部４６は、生成したＦＰＰを一時蓄積メモリ１６に供給する。ファイルフッタ生成部４６はまた、ＩＴ生成部４２で生成されたＩＴにＲＩＰ生成部４４が生成したＲＩＰを連結して、一時蓄積メモリ１６に出力する。

図６を参照して、図１に示す実施例の特徴的な動作を説明する。図６は、記録媒体２０上に生成されるインターリーブＭＸＦファイルの内容例を示す。

ユーザインターフェースの図示しない指示手段からの記録指示を受けると、制御部２２は、ＭＸＦ生成部１４に指示してインターリーブＭＸＦファイルの生成を開始させる。ＭＸＦ生成部１４では、制御部２２から記録指示を受けると、ファイルヘッダ生成部４８が符号化方式に適応するファイルヘッダを生成し、一時蓄積メモリ１６に格納する。ただし、この時点で、ＦＰＰ格納開始オフセット値は未定であるので、ダミー値（ここでは”０”）が代入されている。ファイルヘッダ生成部４８はまた、生成したファイルヘッダのサイズをファイルボディ生成部４０とファイルフッタ生成部４６に通知する。

ＭＸＦ生成部１４のＭＰＥＧ２符号化部３０が、映像入力端子１２から入力された非圧縮の映像データをＭＰＥＧ２方式で圧縮符号化し、圧縮映像データをＰＩ生成部３２に供給する。ＰＩ生成部３２は、ＭＰＥＧ２符号化部３０からの圧縮映像データにフレーム単位で所定ヘッダを付加して、ＥＵ生成部３８に出力する。同時に、ＳＩ生成部３４は、音声入力端子１０からの非圧縮の音声データをＭＰＥＧ２符号化部３０による符号化のフレーム間隔にあわせて分割し、所定ヘッダを付加してＥＵ生成部３８に出力する。ＳＹＳ−Ｉ生成部３６は、ＭＰＥＧ２符号化部３０による符号化のフレームに間隔にあわせてＳＹＳ−Ｉを生成し、ＥＵ生成部３８に出力する。

ＥＵ生成部３８は、アイテム生成部３２，３４，３６からのＰＩ、ＳＩおよびＳＹＳ−Ｉを結合してＥＵを生成し、ファイルボディ生成部４０に出力する。また、ＥＵ生成部３８は同時に、ＩＴを生成するのに必要な情報をＩＴ生成部４２に供給する。例えば、ＤＥＡ、生成したＥＵのサイズ、内包するＳＹＳ−Ｉ、ＰＩおよびＳＩのサイズ、並びに、ＰＩに含まれるＭＰＥＧ２フレームデータの符号化形式（Ｉ／Ｂ／Ｐ）である。

ＩＴ生成部４２は、ＥＵ生成部３８から受け取った情報が所定数のＥＵ分だけ貯まる毎にＩＴを生成する。生成されたＩＴは、ファイルボディ生成部４０とファイルフッタ生成部４６に供給される。

ファイルボディ生成部４０は、制御部２２からの記録指示に応じて、先頭のボディパーティションを一時蓄積メモリ１６に出力し、一時蓄積メモリ１６への出力を制御部２２に通知する。ただし、この時点では、ＦＰＰ格納開始オフセット値は未定であるので、ダミー値（ここでは”０”）が代入される。その後、ファイルボディ生成部４０は、ＥＵ生成部３８からのＥＵを一時蓄積メモリ１６に出力する。入出力したＥＵが所定数に達する毎に、ファイルボディ生成部４０は、ファイルヘッダ生成部４８から入力されるファイルヘッダサイズと、自身が一時蓄積メモリ１６に出力したデータサイズをカウントする。そして、ファイルボディ生成部４０は、直前及び自身のパーティションパックのインターリーブＭＸＦファイル上の格納開始オフセットを決定し、それらの値を使ってＢＰＰを生成する。ただし、この時点で、ＦＰＰ格納開始オフセット値が未定であるので、ダミー値（ここでは”０”）が代入される。

更に、ファイルボディ生成部４０は、生成したＢＰＰにＩＴ生成部４２からのＩＴを合わせて一時蓄積メモリ１６に出力する。そして、ファイルボディ生成部４０は、ＩＴを一時蓄積メモリ１６に出力したことを制御部２２に通知する。ファイルボディ生成部４０は、演算したＢＰＰの格納開始位置オフセットをＲＩＰ生成部４４へ出力する。

制御部２２は、ＭＸＦ生成部１４から一時蓄積メモリ１６への出力状況を取得する。記録開始直後、ファイルヘッダと先頭のＢＰＰの一時蓄積メモリ１６への出力をＭＸＦ生成部１４から通知されると、制御部２２は、記録媒体制御部１８を制御してこのファイルヘッダ及び先頭のＢＰＰを記録媒体２０に書き込ませる（図６（Ａ））。

以降、ＭＸＦ生成部１４からＩＴを一時蓄積メモリ１６に出力した通知を受ける毎に、制御部２２は記録媒体制御部１８に、未出力のＥＵから通知を受けたＩＴまでを同様に記録媒体２０に書き込ませる（図６（Ｂ））。このＩＴまでを一括りとした記録媒体２０への出力を継続的に行うことで、記録媒体２０にインターリーブＭＸＦファイルのファイルボディ部が形成される（図６（Ｃ））。すなわち、本実施例では、インデックステーブル境界を書込み単位とする。インデックステーブルにフィルが続く場合には、そのフィル境界又は終端を書込み単位とする。

ユーザインターフェースの図示しない指示手段から記録停止指示を受けると、制御部２２は、ＭＸＦ生成部１４に記録停止を指示する。記録停止指示をうけると、ＭＰＥＧ２符号化部３０、アイテム生成部３２，３４，３６、ＥＵ生成部３８およびファイルボディ生成部４０は、ＥＵの境界で記録動作を終了する。ＩＴ生成部４２は、最後に生成したＩＴをファイルフッタ生成部４６に出力する。ＲＩＰ生成部４４は、ファイルボディ生成部４０から受け取った情報を元にＲＩＰを生成し、ファイルフッタ生成部４６に出力する。

ファイルフッタ生成部４６は、ファイルボディ生成部４０が最終ＥＵを一時蓄積メモリ１６に出力したことを確認すると、ＲＩＰ生成部４４からのＲＩＰを参照して、フッタパーティションパック（ＦＰＰ）を生成する。すなわち、ファイルフッタ生成部４６は、直前に配置されるＢＰＰと、ＦＰＰ格納開始オフセットなどの情報をＲＩＰから取得し、これらを用いてＦＰＰを生成する。次に、ファイルフッタ生成部４６は、生成したＦＰＰ、入力された最終ＩＴおよびＲＩＰを順に一時蓄積メモリ１６に出力し、その旨を制御部２２に通知する。

制御部２２は、一時蓄積メモリ１６にＦＰＰ、最終のＩＴと、ＲＩＰが出力された通知をＭＸＦ生成部１４から受けると、記録媒体制御部１８にこれらを記録媒体２０に出力させる（図６（Ｄ））。次に、制御部２２は、一時蓄積メモリ１６に蓄積されたＲＩＰを用いて、記録媒体２０からＨＰＰおよびＢＰＰを一時蓄積メモリ１６に出力させる。一時蓄積メモリ上のＲＩＰを用いて、ＦＰＰ格納開始オフセットを取得する。そして、先ほど一時蓄積メモリ１６に読み出したＨＰＰ，ＢＰＰ内のＦＰＰ格納開始オフセット（記録動作中に未定であったので’０’が代入されている）に、ＢＰＰおよびＨＰＰの順で上書きする（図６（Ｅ））。その後、ＨＰＰ及びＢＰＰを一時蓄積メモリ１６から記録媒体２０に上書きで記録する。これで、記録媒体２０上にインターリーブＭＸＦファイルが完成する。

図７を参照して、瞬断発生等の要因による不完全なインターリーブＭＸＦファイルのチェック及び修復方法を説明する。図７は、記録媒体２０の不完全インターリーブＭＸＦファイルをチェック及び修復する制御部２２の動作フローチャートを示す。

瞬断から復帰すると、図７に示す制御フローがスタートする。インターリーブＭＸＦファイルの終端を記録媒体２０から一時蓄積メモリ１６に読み出し、制御部２２は、ＲＩＰが付与されているかどうかをチェックする（Ｓ１）。具体的には、終端に本来格納されているＲＩＰ自身のデータサイズ分戻った位置に、ＲＩＰを示すヘッダがあるか否かで判定する。

ＲＩＰがある場合（Ｓ１）、ＨＰＰにＦＰＰ格納開始オフセットが登録済みか否かを調べる（Ｓ２）。登録されていない、すなわち、ダミー値”０”が格納されている場合（Ｓ２）、当該インターリーブＭＸＦファイルが図６（Ｄ）に示す状態であると判断される。この場合、ＲＩＰからＨＰＰ及び各ＢＰＰの格納開始オフセットを取得する（Ｓ３）。次に、Ｓ３で取得したＢＰＰ格納開始オフセットを用いて、記録媒体２０から各ＢＰＰを一時蓄積メモリ１６に読み出し、正しいＦＰＰ格納開始オフセットを設定して記録媒体２０に書き戻す。同様に、記録媒体２０のＨＰＰのＦＰＰ格納開始オフセットを更新する（Ｓ５）。これで、当該インターリーブＭＸＦファイルの修復処理が終了する。

ＨＰＰにＦＰＰ格納開始オフセットが格納されている場合（Ｓ２）、当該インターリーブＭＸＦファイルが図６（Ｅ）に示す状態にあると判断される。従って、修復処理を行わずに終了する。

終端にＲＩＰが無いと判断された場合（Ｓ１）、当該インターリーブＭＸＦファイルの終端がＩＴであるか否かをチェックする（Ｓ６）。本実施例の記録装置が生成するＩＴは固定サイズである。従って、終端からその固定サイズ分だけ遡って、ＩＴを示すヘッダを検出できるかどうかで、終端がＩＴかどうかを判断できる。

終端がＩＴでない場合（Ｓ６）、当該インターリーブＭＸＦファイルは図６（Ａ）に示す状態であり、有効な映像データが１フレームもないと判断される。そこで、当該インターリーブＭＸＦファイルを記録媒体２０から削除して（Ｓ７）、終了する。

終端がＩＴである場合（Ｓ６）、当該インターリーブＭＸＦファイルは図６（Ｂ）又は同（Ｃ）に示す状態であると判断される。ＩＴの直前に配置されているＰＰ（修復処理中に再度の瞬断がなければ、このＰＰはＢＰＰである。）のヘッダ領域を、ＦＰＰを示すものに書き換えることでＦＰＰに変更する（Ｓ８）。Ｓ８でＦＰＰにしたＰＰ自身の格納開始オフセットを取得し、ＦＰＰ格納開始オフセットとし、一時蓄積メモリ１６のワーク領域に退避する。次に、処理中のＰＰに、Ｓ９で退避したＦＰＰ格納開始オフセットを取り出して設定する（Ｓ１０）。処理中のＰＰ自身の格納開始オフセットを取得し、一時蓄積メモリ１６のワーク領域に退避する（Ｓ１１）。

処理中のＰＰがＨＰＰかどうかをそのヘッダで判定する（Ｓ１２）。ＨＰＰである場合（Ｓ１２）、Ｓ７９及びＳ１１で一時蓄積メモリ１６に退避した各ＰＰ格納開始オフセットを用いてＲＩＰを生成して、当該インターリーブＭＸＦファイルの終端に追記する（Ｓ１３）。処理中のＰＰがＨＰＰで無い場合（Ｓ１２）、処理中のＰＰから一つ前のＰＰの格納開始オフセットを取得し（Ｓ１４）、処理対象一つ前のＰＰに変更する（Ｓ１５）。そして、その一つ前のパーティションパックを同様に記録媒体２０から一時蓄積メモリ１６に読み出し、Ｓ１０以降の処理を繰り返す。

本実施例では、フレーム単位で全ビデオフレームの境界を格納するインデックステーブルの修復に、ＭＸＦデータ内のフレーム境界をサーチする必要がなくなる。また、ＭＸＦファイルデータの修復のために、記録時にフレーム境界を予め不揮発性メモリ等に保存する必要が無い。従って、本実施例では、短時間で不完全なＭＸＦデータを修復でき、また、不揮発性メモリ等などのコストアップ要因を避けることができる。

Claims

動画データを入力する入力手段と、
ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、
前記記録媒体に記録されたファイルを修復する修復手段
とを備え、
前記ファイルフッタは前記ファイルフッタのオフセットに関する情報を含み、
前記記録手段は、前記所定フレーム数の動画データと、その次の領域に格納される前記第１の情報と前記第２の情報とを記録単位として前記記録媒体に記録し、前記ファイルフッタの記録を停止した後、前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納し、
前記修復手段は、前記ファイルフッタのオフセットに関する情報を複数の前記領域における前記第１の情報に格納する前に記録が停止された場合、前記ファイルフッタに格納された前記ファイルフッタのオフセットに関する情報を前記記録媒体から読み出し、読み出した前記ファイルフッタのオフセットに関する情報を複数の前記領域における前記第１の情報にそれぞれ格納することにより修復を行う
ことを特徴とする記録装置。
動画データを入力する入力手段と、
ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、
前記記録媒体に記録されたファイルを修復する修復手段
とを備え、
前記ファイルフッタは前記ファイルフッタのオフセットに関する情報を含み、
前記記録手段は、前記所定フレーム数の動画データと、その次の領域に格納される前記第１の情報と前記第２の情報とを記録単位として前記記録媒体に記録し、前記ファイルフッタの記録を停止した後、前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納し、
前記修復手段は、前記ファイルフッタが記録される前に前記ファイルの記録が停止された場合、前記ファイルにおける最後の前記領域に格納された前記第１の情報を前記ファイルフッタのオフセットに関する情報として変更し、変更された前記ファイルフッタのオフセットに関する情報を、複数の前記領域における前記第１の情報にそれぞれ格納することにより修復を行う
ことを特徴とする記録装置。
動画データを入力する入力手段と、
ファイルヘッダと、ファイルフッタと、前記動画データが格納される複数の領域からなるファイルボディとを含むファイルを記録媒体に記録する手段であって、前記領域のファイル先頭からのオフセットに関する第１の情報と、一つ前の前記領域に格納された所定フレーム数の前記動画データにおける各フレームの位置に関する第２の情報と、前記所定フレーム数の動画データとを、前記第１の情報、前記第２の情報、前記所定フレーム数の動画データ、の順に多重して一つの前記領域に格納する記録手段と、
前記記録媒体に記録されたファイルを修復する修復手段
とを備え、
前記ファイルフッタは、前記ファイルにおける複数の前記領域それぞれのオフセットに関する情報を含み、
前記第１の情報は、一つ前の前記領域のオフセットに関する情報を更に含み、
前記修復手段は、前記ファイルフッタが記録される前に前記ファイルの記録が停止された場合、複数の前記領域の前記第１の情報に基づいて複数の前記領域それぞれのオフセットを検出し、検出した複数の前記領域それぞれのオフセットを含むファイルフッタを生成して前記記録媒体に記録することにより修復を行う
ことを特徴とする記録装置。