JP2008053763A - Ａｖデータ記録装置及び方法、ａｖデータ再生装置及び方法、当該ａｖデータ記録装置又は方法で記録された記録媒体 - Google Patents

Abstract

【課題】本発明の目的は、編集者が毎秒２４フレームの映像編集時に、ユーザがＩＮ／ＯＵＴ点を簡易に指定できることを目的とする。
【解決手段】本発明によるＡＶデータ記録装置は、毎秒２４フレームの映像を３：２プルダウンして毎秒６０フレームのＭＰＥＧ−２ビデオとして記録する場合に、先頭フレームのタイムコード値と、イントラフレーム毎にＰＴＳ値と記録先アドレスの両方を記録する。さらに、ピクチャヘッダ内に毎秒２４フレームのタイムコード値を格納する。編集時にピクチャヘッダ内のタイムコード値が表示され、その値を使ってプレイリストの編集点を指定する。プレイリスト再生時は、指定されたタイムコード値から格納先アドレスを算出して再生を開始する。
【選択図】図２７

Description

本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコンテンツの再生および編集を容易にする技術に関する。

近年、ＤＶＤ等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器（光ディスクレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。

近年はＰＣにもコンテンツの記録、再生および編集機能が実装されており、ＰＣも上述のデジタル機器に含めることができる。ＰＣでは、文書データ等を記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、ＰＣと連携可能なデータ管理構造、例えばＦＡＴ（File Allocation Table）を用いたファイルシステムが採用されている。現在多く利用されているＦＡＴ３２ファイルシステムでは、最大４ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が２テラバイトのメディアを管理することができる。

メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。例えば特許文献１では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるＡＶデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。

また一方、近年、フィルムの様な映像を毎秒２４フレームで記録する機能を持つカムコーダが登場してきた。これにより、映画制作がより身近なものになりつつある。

一般にＭＰＥＧ−２の動画ストリーム中に毎秒２４フレームの映像を記録する場合、３：２プルダウンにより記録される。テレビの再生可能なフレーム数は、ＮＴＳＣ圏の場合は毎秒６０フレームであるため、これに合わせて３：２プルダウンで記録される。図３３は、毎秒６０フレーム、横と縦の画素数が１２８０×７２０のＭＰＥＧ−２の動画ストリーム中に、毎秒２４フレームの映像を３：２プルダウン記録する場合の説明図である。２４フレーム中のそれぞれのフレームは、毎秒６０フレーム中の３フレーム区間と２フレーム区間を交互に表示する様に符号化される。

この時、毎秒６０フレームの映像と同時に、毎秒６０フレームで更新されるタイムコードが表示される。例えば、開始点であれば０時間０分０秒０フレームと表示される。また、開始点から５０フレーム後であれば０時間０分０秒５０フレームと表示される。
特開平１１−１５５１３０号公報

毎秒２４フレームの映像の内、映像編集時にＩＮ点／ＯＵＴ点を決める際に毎秒６０フレーム中の時刻で指定すると、３フレーム分もしくは２フレーム分の時刻の間、同じ映像が表示されることになり、煩わしかった。

本発明の目的は、編集者が毎秒２４フレームの映像編集時に、ユーザがＩＮ／ＯＵＴ点を簡易に指定できることを目的とする。

また、このことを実現するために、動画の符号化の際にＭＰＥＧエンコーダとの間で通信量を増やす事無く実現可能であり、特別なＭＰＥＧエンコーダを使用する必要が無い様にする。

本発明によるＡＶデータ記録装置は、符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録装置であって、前記管理情報は前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、前記所定のピクチャに対応したタイムコード値を有し、前記タイムコード値は、前記オブジェクト内の各ピクチャに一意に対応し、前記各ピクチャの再生間隔と前記タイムコードが示す再生間隔は異なる値を設定する。

これによりピクチャに対して一意に決まるタイムコードが存在するので、編集点の指定が容易になる。

また本発明によるＡＶデータ記録装置は、符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録装置であって、前記映像データはピクチャ内符号化が施されたピクチャデータ（イントラピクチャデータ）とピクチャ間符号化が施されたピクチャデータとを有し、前記管理情報は、前記オブジェクト中の最初のイントラピクチャデータの再生時刻と、前記イントラピクチャデータの記録位置とを対応付けるマップ情報を有し、さらに、先頭の前記オブジェクト中の前記最初のイントラピクチャよりも先に再生されるピクチャの再生時間長に関する情報を有する。

これにより、マップ情報を生成する際に、ＭＰＥＧエンコーダが生成するストリームを解析して実現可能であり、ＭＰＥＧエンコーダが動画信号を符号化する際に、ＭＰＥＧエンコーダとの間でほとんど通信量を増やす事無く実現可能であり、したがって特別なＭＰＥＧエンコーダを使用する必要が無い。

本発明によれば、３：２プルダウンして記録された毎秒２４フレームの映像を編集する際に、モニタに表示される毎秒２４フレームのタイムコードを使って、編集者がＩＮ／ＯＵＴ点を簡易に指定して、プレイリストの作成ができる編集環境の提供を目的とする。毎秒２４フレームの各フレームを直接指定可能なので、編集作業時間を短縮できる。

また、このことを実現するために、動画の符号化の際にＭＰＥＧエンコーダとの間で通信量を増やす事無く実現可能であり、特別なＭＰＥＧエンコーダを使用する必要が無い。

以下、添付の図面を参照して、本発明によるデータ処理装置の実施の形態を説明する。

（実施の形態１）
図１は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す。図１では、データ処理装置は、カムコーダ１００−１、カメラ付き携帯電話１００−２、ＰＣ１０８として記載されている。カムコーダ１００−１およびカメラ付き携帯電話１００−２は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして符号化し、そのデータストリームを、それぞれリムーバブルメディア１１２−１および１１２−２に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図１では、リムーバブルメディア１１２−２に複数のファイルが格納されていることが示されている。

各リムーバブルメディア１１２−１および１１２−２はデータ処理装置から取り外し可能であり、例えばＤＶＤ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）等の光ディスク、マイクロドライブ等の超小型ハードディスク、半導体メモリ等である。ＰＣ１０８は、各リムーバブルメディア１１２−１および１１２−２を装填することが可能なスロットを備えている。ＰＣ１０８は、装填されたリムーバブルメディア１１２−１、１１２−２からデータを読み出し、再生処理および編集処理等を実行する。

リムーバブルＨＤＤ１１２では、ＦＡＴ３２ファイルシステムによりデータ管理が行われる。ＦＡＴ３２ファイルシステムでは、１ファイルのファイルサイズの最大値は、例えば４ギガバイトである。よって、ＦＡＴ３２ファイルシステムではデータのサイズが４ギガバイトを超えるときは２以上のファイルに分けて書き込まれる。例えば、容量が８ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが２つ格納され得る。１６ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが４つ格納され得る。なお、分割して書き込まれる単位はファイルサイズの最大値でなくてもよく、ファイルサイズの最大値以下のサイズであればよい。

以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込むデータ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに格納されたデータストリームを再生し編集するデータ処理装置はＰＣであるとして説明する。

さらに、リムーバブルメディア１１２−１は超小型のリムーバブルハードディスクであるとする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆動してデータの書き込みおよび読み出しを行うための機構（ドライブ機構）を含む。以下では、リムーバブルメディア１１２−１を「リムーバブルＨＤＤ１１２」と記述する。説明を簡便化するため、リムーバブルＨＤＤ１１２は４ギガバイトの容量を持つとする。この結果、４ギガバイトを超えるコンテンツは、２以上のリムーバブルＨＤＤに分けて書き込まれる。しかしながら、リムーバブルＨＤＤが４ギガバイト以上の容量を持ち、そこに４ギガバイトを超えるコンテンツが書き込まれる場合にも、２以上のファイルに分割して同じリムーバブルＨＤＤに書き込めばよい。１つのコンテンツが複数のファイルに分けて記録される本質的な点においては、いずれも同じである。単に記録するメディアが同一であるか否かの違いにすぎない。リムーバブルＨＤＤ１１２のクラスタサイズは、例えば３２キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際の最小のアクセス単位である。

図２は、カムコーダ１００の機能ブロックの構成を示す。カムコーダ１００には、複数のリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃを同時に装填することが可能であり、ユーザが撮影した映像および音声に関するコンテンツのデータストリーム（クリップＡＶストリーム）を、リムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに順に書き込む。

カムコーダ１００は、ＣＣＤ２０１ａ、マイク２０１ｂおよびデジタル放送を受信するデジタルチューナ２０１ｃと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、メディア制御部２０５と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、液晶表示装置（ＬＣＤ）２０９ａおよびスピーカ２０９ｂと、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、システム制御部２５０とを含む。

以下、各構成要素の機能を説明する。ＣＣＤ２０１ａおよびマイク２０１ｂは、それぞれ映像および音声のアナログ信号を受け取る。ＣＣＤ２０１ａは、映像をデジタル信号として出力する。マイク２０１ｂは、音声のアナログ信号を出力する。ＡＤコンバータ２０２は入力されたアナログ音声信号をデジタル信号に変換してＭＰＥＧ−２エンコーダ２０３に供給する。

デジタルチューナ２０１ｃは、アンテナ（図示せず）から１以上の番組が含まれるデジタル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。デジタルチューナ２０１ｃは、受信したトランスポートストリームから特定の番組（録画対象のチャンネルの番組）のパケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームであるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼ぶこともある。トランスポートストリームのデータ構造は、図３〜図５を参照しながら後述する。

本実施の形態においては、カムコーダ１００はデジタルチューナ２０１ｃを構成要素としているが、これは必須の要件ではない。図２のカムコーダ１００の構成は、図１において言及したカメラ付き携帯電話１００−２等にも適用できるため、デジタル放送の受信および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。

ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給された映像および音声の各デジタルデータをＭＰＥＧ規格に基づいて圧縮符号化する。本実施形態においては、エンコーダ２０３は、映像データをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリーム（以下「ＴＳ」とも記述する）を生成し、ＴＳ処理部２０４に送る。この処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。エンコーダ２０３は双方向圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。なお、映像および音声の符号化形式を一致させる必要はない。例えば、映像はＭＰＥＧ形式で圧縮符号化し、音声はＡＣ−３形式で圧縮符号化するとしてもよい。

本実施形態では、カムコーダ１００はＴＳを生成し処理する。そこでまず、図３〜図５を参照しながら、ＴＳのデータ構造を説明する。

図３は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮符号化されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、符号化されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。

以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図４（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、一般に４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図４（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、一般に４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。

オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。ＴＳパケットヘッダにはアダプテーションフィールドと呼ばれるデータを追加してもよく、ＴＳパケットに格納するデータをアライメントする場合などに利用される。この場合ＴＳパケットのペイロード（３０ｂ、３１ｂ）は１８４バイト未満となる。

上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは“０ｘ００２０”であり、オーディオＴＳパケットのＰＩＤは“０ｘ００２１”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。

以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図５（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図５（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。

ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図５（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。

ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図５（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。

図５（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）などを表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、例えば“００１ｂ”などと決められている。

ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図５（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。

ＴＳに基づいて映像を再生する際、カムコーダ１００はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をＬＣＤ２０９ａ上に再生することができる。

上述のエンコーダ２０３は、映像コンテンツに関しては図５（ｄ）、（ｃ）、（ｂ）および（ａ）に示す順序でＴＳを生成するといえる。

次に、カムコーダ１００のＴＳ処理部２０４（図２）を説明する。ＴＳ処理部２０４は、動画の記録時にはエンコーダ２０３からＴＳを受け取り、またはデジタル放送番組の録画時にはデジタルチューナ２０１ｃからＴＳを受け取って、クリップＡＶストリームを生成する。クリップＡＶストリームとは、リムーバブルＨＤＤ１１２ａ等への格納のために所定の形式を有するデータストリームである。本明細書では、リムーバブルＨＤＤに格納されたクリップＡＶストリームのファイルには拡張子ＴＴＳ（“Ｔｉｍｅｄ ＴＳ”を意味する）を付している。クリップＡＶストリームは、到着時刻情報を付加したＴＳとして実現される。また、ＴＳ処理部２０４は、コンテンツの再生時には、リムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームをメディア制御部２０５から受け取り、そのクリップＡＶストリームに基づいてＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。

以下では図６を参照しながら、ＴＳ処理部２０４の処理に関連するクリップＡＶストリームを説明する。図６は、クリップＡＶストリーム６０のデータ構造を示す。クリップＡＶストリーム６０は、複数のＴＴＳパケット６１から構成される。ＴＴＳパケット６１は、４バイトのＴＴＳヘッダ６１ａと、１８８バイトのＴＳパケット６１ｂとから構成される。すなわちＴＴＳパケット６１は、ＴＴＳヘッダ６１ａをＴＳパケット６１ｂに付加して生成される。なおＴＳパケット６１ｂは、図３、図４（ａ）および（ｂ）等に関連して説明したＴＳパケットである。

ＴＴＳヘッダ６１ａは、２ビットの予約領域６１ａ−１と、３０ビットの到着時刻情報（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ；ＡＴＳ）６１ａ−２とから構成されている。この到着時刻情報６１ａ−２は、エンコーダ２０３から出力されたＴＳパケットがＴＳ処理部２０４に到着した時刻を示している。ＴＳ処理部２０４は、この時刻に基づいてデコーダ２０６にＴＳパケットを出力する。

次に、上述のクリップＡＶストリーム６０を生成するＴＳ処理部２０４の構成を説明する。図７は、ＴＳ処理部２０４の機能ブロックの構成を示す。ＴＳ処理部２０４は、ＴＴＳヘッダ付加部２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ＴＴＳヘッダ除去部２６５とを有する。

ＴＴＳヘッダ付加部２６１は、ＴＳを受け取り、そのＴＳを構成するＴＳパケットの前にＴＴＳヘッダを付加し、ＴＴＳパケットとして出力する。ＴＴＳヘッダ中の到着時刻情報６１ａ−２に記述されるＴＳパケットの到着時刻は、ＴＴＳヘッダ付加部２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。

クロックカウンタ２６２およびＰＬＬ回路２６３は、ＴＴＳヘッダ付加部２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、ＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がカムコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）として設定され、ＳＴＣが基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてＴＴＳヘッダ付加部２６１に出力する。

バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたＴＴＳパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、後述のメディア制御部２０５に出力する。このとき出力される一連のＴＴＳパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、メディア制御部２０５によってリムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ＴＴＳパケット単位で出力する。

ＴＴＳヘッダ除去部２６５は、ＴＴＳパケットを受け取って、ＴＴＳヘッダを除去することによりＴＴＳパケットをＴＳパケットに変換し、ＴＳとして出力する。留意すべきは、ＴＴＳヘッダ除去部２６５は、ＴＴＳヘッダに含まれているＴＳパケットの到着時刻情報ＡＴＳを抽出して、到着時刻情報ＡＴＳとクロックカウンタ２６２から与えられるタイミング情報とに基づいて、元の到着時刻に対応するタイミング（時間間隔）でＴＳパケットを出力することである。リムーバブルＨＤＤ１１２ａ等はランダムアクセスが可能であり、データは不連続にディスク上に配列される。よって、ＴＳパケットの到着時刻情報ＡＴＳを利用すれば、ＴＳ処理部２０４は、データの格納位置にかかわらず記録時のＴＳパケットの到着タイミングと同じタイミングでＴＳパケットを出力することができる。なおＴＴＳヘッダ除去部２６５は、読み出したＴＳの基準時刻を指定するために、例えば最初のＴＴＳパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。

カムコーダ１００では、ＴＳ処理部２０４を設けて、ＴＳにＴＴＳヘッダを付加してクリップＡＶストリームを生成するとした。しかし、符号化レートが固定されているＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）で符合化する場合には、ＴＳパケットのデコーダ入力時刻が固定間隔であるため、ＴＳ処理部２０４を省略してＴＳをリムーバブルＨＤＤ１１２に書き込むこともできる。

再び図２を参照しながら、カムコーダ１００の各構成要素を説明する。

メディア制御部２０５は、ＴＳ処理部２０４からクリップＡＶストリームを受け取り、いずれかのリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに出力するかを決定して、そのリムーバブルＨＤＤに出力する。メディア制御部２０５は、書き込み中のリムーバブルＨＤＤの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときには出力先を他のリムーバブルＨＤＤに変更し、クリップＡＶストリームの出力を継続する。このとき、１つのコンテンツを構成するクリップＡＶストリームが２つのリムーバブルＨＤＤ１１２に跨って格納されることになる。

メディア制御部２０５は、本発明の主要な特徴の１つであるクリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）テーブルを生成する。そしてそのテーブルに、クリップＡＶストリームの再生単位であるキーピクチャユニットが、２つのファイルに跨って格納されているか否かを示すフラグを記述する。なお、メディア制御部２０５のより詳細な動作、および、メディア制御部２０５によって生成されるクリップタイムラインテーブルの詳細なデータ構造は後述する。

なお、クリップＡＶストリームをリムーバブルＨＤＤ１１２に書き込む処理は、メディア制御部２０５から書き込み指示およびクリップＡＶストリームを受け取ったリムーバブルＨＤＤ１１２が行っている。また、クリップＡＶストリームを読み出す処理は、メディア制御部２０５から読み出し指示を受けたリムーバブルＨＤＤ１１２が行っている。しかし、説明の便宜のため、以下ではメディア制御部２０５がクリップＡＶストリームを書き込み、読み出すとして説明する。

ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたＴＳを解析して、ＴＳパケットから映像および音声の圧縮符号化データを取得する。そして、映像の圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。またデコーダ２０６は、音声の圧縮符号化データを伸長して音声信号を生成し、音声信号をスピーカ２０９ｂに出力する。デコーダ２０６は、ＴＳに関してＭＰＥＧ規格で規定されているシステムターゲットデコーダ（Ｔ−ＳＴＤ）の要件を満たすように構成されている。

グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成した映像信号を出力することができる。液晶表示装置（ＬＣＤ）２０９ａは、グラフィック制御部２０７から出力された映像信号をＬＣＤ上に表示する。スピーカ２０９ｂは、音声信号を音として出力する。コンテンツは、ＬＣＤ２０９ａおよびスピーカ２０９ｂを介して再生され、視聴の対象となる。なお、映像信号および音声信号の出力先は、それぞれＬＣＤ２０９ａおよびスピーカ２０９ｂに限られない。例えば映像信号および音声信号は、外部出力端子（図示せず）を経てカムコーダ１００と別体のテレビやスピーカに伝送されてもよい。

ＣＰＵバス２１３はカムコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。

ネットワーク制御部２１４は、カムコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェースであり、例えば、イーサネット（登録商標）規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。例えば、ネットワーク制御部２１４は、撮影され生成されたクリップＡＶストリームを、ネットワーク１０１を介して放送局に伝送してもよい。または、ネットワーク制御部２１４は、カムコーダ１００の動作を制御するためのソフトウェアプログラムが更新されたときは、更新されたプログラムを、ネットワーク１０１を介して受け取ってもよい。

指示受信部２１５は、カムコーダ１００の本体部に設けられた操作ボタンである。指示受信部２１５は、ユーザから、例えば録画の開始／停止、再生の開始／停止等の指示を受け取る。

インターフェース（Ｉ／Ｆ）部２１６は、カムコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ１００は、ＵＳＢ２．０規格またはＩＥＥＥ１３９４規格の端子を介してＰＣ１０８や、他のカムコーダ（図示せず）、ＢＤ／ＤＶＤレコーダ、ＰＣ等と接続される。

システム制御部２５０は、カムコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはカムコーダ１００を制御するためのソフトウェアプログラムが格納されている。

ＣＰＵ２１１は、カムコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ、カメラ、マイク等を利用して構成されたコンピュータシステムを、本実施形態によるカムコーダ１００と同等の機能を有する機器として動作させることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。

次に、図８（ａ）〜（ｃ）を参照しながら、カムコーダ１００において撮影された、映像および音声に関するコンテンツのデータ管理構造を説明する。図８（ａ）は、本実施形態における１コンテンツの概念を示す。撮影の開始から終了までの期間に得られたコンテンツを、１ショットという。図８（ｂ）は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。１ショット、すなわち１つのコンテンツは、複数のクリップａ〜ｃに分けて各リムーバブルＨＤＤ１１２ａ〜１１２ｃに格納することができる（１つのクリップで完結してもよい）。１つのクリップは、クリップメタデータ８１と、タイムマップ８２と、クリップＡＶストリーム８３の一部（部分ストリーム）とを含む。クリップＡＶストリーム８３は、部分ストリーム８３ａ〜８３ｃから構成されており、クリップａ〜ｃのそれぞれに含まれる。図８（ｂ）には３つのクリップａ〜ｃが記載されているが、各クリップの構成は共通しているため、ここではクリップａを例に挙げて説明する。

クリップａは、クリップメタデータａと、タイムマップａと、部分ストリームａとを含む。このうち、クリップメタデータａおよびタイムマップａは管理情報であり、部分ストリームａがクリップＡＶストリーム８３を構成するデータである。クリップＡＶストリーム８３は原則として１つのファイルに格納されるが、ＦＡＴ３２のファイルサイズの最大値を超えるときには複数のＴＴＳファイルに格納される。図８（ｂ）では、３つの部分ストリーム８３ａ、８３ｂおよび８３ｃが別個のファイルに格納される。なお本実施形態では、各部分ストリームのファイルサイズをＦＡＴ３２ファイルシステムにおけるファイルサイズの最大値（４ギガバイト）とすると、リムーバブルＨＤＤ１１２ａ〜ｃの記録可能容量がなくなって管理情報をリムーバブルＨＤＤ１１２に書き込みできなくなるため、各部分ストリームのファイルサイズは４ギガバイトよりも小さくなることに留意されたい。さらに、ＴＴＳファイルは整数個のＴＴＳパケットから構成されるとし、上記ファイルシステムからの制限である４ギガバイト未満であり、かつ、ＴＴＳパケット（１９２バイト）の整数倍としてもよい。

クリップメタデータａはＸＭＬ形式で記述されており、コンテンツの再生に必要な情報、例えば映像／音声フォーマット等が規定される。クリップメタデータａの詳細は、後に図１０を参照しながら詳述する。

タイムマップａは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」（ＣｌｉｐＴｉｍｅＬｉｎｅ）と呼び、クリップタイムラインが格納されたファイルの拡張子に“ＣＴＬ”を付して図示している。クリップタイムラインの詳細は、後に図１２〜１４を参照しながら詳述する。

部分ストリームａは、図６に示すように複数のＴＴＳパケットから構成される。

なお、１ショットの間にクリップＡＶストリーム８３が複数の部分ストリーム８３ａ〜８３ｃのファイルに格納されたときには、ＴＳパケットの転送タイミングを決定するＡＴＳのクロックカウンタ２６２（図７）がリセットされたり、それまでのカウント値とは無関係な値が設定されたりすることはない。クロックカウンタ２６２（図７）は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。したがって、クリップＡＶストリーム８３を構成する各ＴＴＳパケット中の到着時刻情報ＡＴＳは、１つのショットを構成する連続する２つのＴＴＳファイルの境界において連続している。

図８（ｃ）は、３つのリムーバブルＨＤＤ１１２ａ〜１１２ｃを示す。各クリップａ〜ｃを構成するデータのファイルが各リムーバブルＨＤＤ１１２ａ〜１１２ｃに書き込まれる。

次に、リムーバブルＨＤＤ１１２内にファイルがどのように格納されるかを説明する。図９は、リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す。コンテンツの管理情報とクリップＡＶストリームのファイルは、最上層のルート（ＲＯＯＴ）９０内のコンテンツ（Ｃｏｎｔｅｎｔｓ）フォルダ９１以下に格納される。より具体的には、コンテンツフォルダ９１直下のデータベース（Ｄａｔａｂａｓｅ）フォルダ９２には、管理情報であるクリップメタデータ９４のＸＭＬ形式ファイル、および、クリップタイムライン９５のＣＴＬ形式ファイルが格納される。一方、コンテンツフォルダ９１直下のＴＴＳフォルダ９３には、クリップＡＶストリーム（ＴｉｍｅｄＴｓ）９６のＴＴＳ形式ファイルが格納される。

なお、コンテンツフォルダ９１には、さらにＭＸＦ形式の映像のストリームデータを格納するビデオフォルダ（Ｖｉｄｅｏ）、ＭＸＦ形式の音声のストリームデータを格納するオーディオフォルダ（Ａｕｄｉｏ）、ＢＭＰ形式のサムネイル画像を格納するアイコンフォルダ（Ｉｃｏｎ）、ＷＡＶＥ形式のボイスメモのデータを格納するボイスフォルダ（Ｖｏｉｃｅ）等が設けられてもよく、既存のカムコーダの記録フォーマット等に対応させることができる。

続いて、図１０〜１４を参照しながら、クリップメタデータ９４およびクリップタイムライン９５に記述されたデータの内容を説明する。

図１０は、クリップメタデータ９４に含まれる情報の内容を示す。クリップメタデータ９４は、構成データ（“Ｓｔｒｕｃｔｕｒａｌ”）および記述データ（“Ｄｅｓｃｒｉｐｔｉｖｅ”）の２種類に分類される。

構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ ＩＤｅｎｔｉｆｉｅｒ）が記述される。ＵＭＩＤは、例えば、コンテンツが生成された時刻とそれを生成した機器のＭＡＣ（Ｍｅｄｉａ ＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレスを組み合わせて生成される。さらにＵＭＩＤは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦ＵＭＩＤが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのＵＭＩＤとは異なる値が付加される。よってＵＭＩＤを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。

エッセンスリストには、映像および音声の復号化に必要な情報（ビデオ情報およびオーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はＭＰＥＧ−２方式である。

リレーション情報は、図８（ｂ）に示すような複数のクリップ８１ａ〜８１ｃが存在するときのクリップの間の関係を規定する。具体的には各クリップメタデータ９４には、そのショットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々に対応するクリップＡＶストリーム（部分ストリーム）の再生の先後関係または再生順序を規定しているということができる。クリップを特定する情報は、例えば、ＵＭＩＤおよびそのリムーバブルＨＤＤ１１２固有のシリアル番号によって規定される。

記述データには、アクセス情報、デバイス、撮影情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。

次に、クリップタイムライン９５を説明する。クリップタイムライン９５では、キーピクチャおよびキーピクチャユニットという概念を導入して、それらに関する情報を規定している。そこでまず図１１を参照しながら、キーピクチャおよびキーピクチャユニットを説明する。

図１１は、キーピクチャおよびキーピクチャユニットの関係を示す。図１１では、Ｉ、ＢおよびＰの各ピクチャを表示される順序で記載している。キーピクチャユニット（Ｋｅｙ Ｐｉｃｔｕｒｅ Ｕｎｉｔ；ＫＰＵ）は、映像に関して規定されるデータ再生単位である。図１１では、キーピクチャユニットＫＰＵの表示は、キーピクチャ４４から開始され、Ｂピクチャ４５において終了する。この間にはＭＰＥＧ規格のグループ・オブ・ピクチャ（ＧＯＰ）が１以上含まれている。Ｂピクチャ４５の次のＩピクチャ４６から、次のキーピクチャユニットＫＰＵの表示が始まる。各キーピクチャユニットの映像再生時間は、０．４秒以上、かつ、１秒以下である。ただし、１ショットの最後のキーピクチャユニットは１秒以下であればよい。撮影の終了タイミングによっては０．４秒に満たないこともあるからである。上記はＧＯＰ先頭のＩピクチャから再生が開始されるとしているが、Ｂピクチャから再生が開始されるＧＯＰ構造の場合には、この限りではない。ＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）は、そのＫＰＵに格納される全ピクチャの再生時間を示しているためである。

キーピクチャユニットの先頭に位置するキーピクチャ４４、４６は、ＭＰＥＧ規格におけるシーケンスヘッダコード（ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅ）およびグループスタートコード（ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ）を含むビデオに関するアクセス単位である。例えば、キーピクチャユニットはＭＰＥＧ２圧縮符号化されたＩピクチャの画像（フレーム画像または１組の２フィールド画像）または、圧縮符号化されたＩフィールドおよびＰフィールドの画像である。

また、本実施の形態では、ＴＳに付加されたＰＴＳを用いてＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）を定義している。ＫＰＵ期間は、次のキーピクチャユニットＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）と、そのＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）との差分値である。図１１では、キーピクチャ４４の時刻をＰＴＳ（Ｎ）とし、キーピクチャ４６の時刻をＰＴＳ（Ｎ＋１）としたとき、ＫＰＵ期間（Ｎ）は、ＰＴＳ（Ｎ＋１）−ＰＴＳ（Ｎ）として定義される（ともにキーピクチャが表示開始ピクチャとなっている場合）。なお、ＫＰＵ期間の定義から明らかなように、あるＫＰＵ期間の値を決定するためには、次のキーピクチャユニットＫＰＵのピクチャが圧縮符号化され、最初に表示されるピクチャの再生時刻（ＰＴＳ）が確定しなければならない。よって、あるキーピクチャユニットＫＰＵに対するＫＰＵ期間は、次のキーピクチャユニットの生成が開始された後に定まる。なお、ショットで最後のＫＰＵ期間が必要な場合もあるため、符合化したピクチャの表示時間を積算していく方法も可能である。その場合には、次のＫＰＵの生成開始を待たずともＫＰＵ期間を決定することが可能である。

次に、図１２（ａ）〜（ｃ）を参照しながら、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）を説明する。図１２（ａ）は、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す。クリップタイムライン９５は、拡張子に“ＣＴＬ”を有するファイルとして各リムーバブルＨＤＤ１１２に書き込まれる。

クリップタイムライン９５は、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。「再生単位」は、上述のキーピクチャユニットＫＰＵに対応する。

クリップタイムライン９５には、複数のフィールドが規定されている。例えば、クリップタイムライン９５には、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａ、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂ、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃ、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄ、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅ、ＳｔａｒｔＫｅｙＳＴＣフィールド７５ｆ、ＴｉｍｅＥｎｔｒｙフィールド９５ｇ、ＫＰＵＥｎｔｒｙフィールド９５ｈ等を含む。各フィールドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定している。

例えば、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａにはタイムエントリの数が記述され、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂにはＫＰＵエントリの数が記述される。ただしＴｉｍｅＥｎｔｒｙフィールド９５ｇおよびＫＰＵＥｎｔｒｙフィールド９５ｈは、後述のタイムエントリの数およびＫＰＵエントリの数に応じてデータサイズが変動し得る。

図１２（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示す。ＴｉｍｅＥｎｔｒｙフィールド９５ｇには、対応するタイムエントリに関する属性を示す情報が複数のフィールド（ＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａ、ＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂおよびＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃ）に記述されている。

また、図１２（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す。ＫＰＵＥｎｔｒｙフィールド９５ｈには、対応するキーピクチャユニットＫＰＵに関する属性を示す情報が複数のフィールド（ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ、ＫｅｙＰｉｃｔｕｒｅＳｉｚｅフィールド９８ｂ、ＫＰＵＰｅｒｉｏｄフィールド９８ｃおよびＫＰＵＳｉｚｅフィールド９８ｄ）に記述されている。

ここで、図１３（ａ）および（ｂ）を参照しながら、クリップタイムライン９５に含まれる主要なフィールドに規定されるデータの意味を説明する。

図１３（ａ）は、タイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ａ）の横軸の１目盛りは１アクセスユニット時間（Ａｃｃｅｓｓ Ｕｎｉｔ ＴｉＭｅ；ＡＵＴＭ）を示している。これは１ピクチャの表示時間に対応する。ここでいう「ピクチャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プログレッシブビデオに対しては１枚のプログレッシブ走査のフレーム画像に対応し、インターレースビデオに対してはインターレース走査のフィールド画像（１フィールド）に対応する。例えば、２４０００／１００１秒間隔で表示されるプログレッシブビデオ（つまり２３．９７ｐ）では、１ＡＵＴＭは１／（２４０００／１００１） 秒 ＝ １１２６１２５ ｃｌｏｃｋｓ／２７ＭＨｚと表記される。

ここでまず、１ショットにｎ個のクリップが含まれるとしたときの時間の関係を説明する。まず各クリップの再生時間長は、それぞれのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅに記述される。この値はＡＵＴＭを利用して記述される。すべてのクリップについてのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値の和を計算すると、１ショットの再生時間長（撮影時間長）が得られる（数１）。この時間長もまた、ＡＵＴＭを利用して記述される。
（数１）
１ショットの再生時間長＝ΣＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ
一方、図１３（ａ）に示すＫＰＵ＃０から＃（ｋ＋１）までが１クリップに含まれるとすると、上述の各クリップのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅは、そのクリップに含まれる全てのキーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値の総和として得られる（数２）。上述のように、ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）はＡＵＴＭ値を用いて表記されるため、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅもＡＵＴＭ表記である。
（数２）
ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ＝ΣＫＰＵｐｅｒｉｏｄ
各ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値は、上述のとおり、そのキーピクチャユニットＫＰＵに含まれるピクチャのビデオ表示時間（ＡＵＴＭ値）の和に対応する（数３）。
（数３）
ＫＰＵｐｅｒｉｏｄ＝ＫＰＵ内のビデオ総表示時間
「タイムエントリ」（ＴｉｍｅＥｎｔｒｙ）とは、一定の固定時間（例えば５秒）ごとに設定され、その位置から再生を開始することが可能な時間軸上の飛び込み点を示す。タイムエントリの設定に関連して、先頭のキーピクチャユニットＫＰＵ＃０の再生開始時刻を０としたとき、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。また、各タイムエントリの設定時刻に再生されるキーピクチャユニットＫＰＵを識別する情報がＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａに記述され、そのキーピクチャユニットＫＰＵの先頭からそのタイムエントリの設定時刻までの時間オフセットを示す情報がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃに記述される。

例えば、タイムエントリ＃ｔが指定されると、（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）＋（タイムエントリの間隔・ｔ）を計算することにより、そのタイムエントリ＃ｔが設定された時刻、すなわち先頭キーピクチャユニットＫＰＵ＃０の先頭からの経過時間を得ることができる。

また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。すなわち、ユーザから再生を開始したい時刻の指定を受け取ると、その時刻は、周知の変換処理を利用してＭＰＥＧ規格上の時間情報であるＰＴＳ値に変換される。そして、そのＰＴＳ値が割り当てられたピクチャから、再生が開始される。なおＰＴＳ値は、ビデオＴＳパケット（Ｖ＿ＴＳＰ）３０のトランスポートパケットヘッダ３０ａ（図４（ａ））内に記述されている。

本実施形態では、１つのクリップＡＶストリームが複数の部分ストリームに分けられているため、各クリップ内の部分ストリーム先頭の再生開始時刻（ＰＴＳ）が０でないことがある。そこで、クリップタイムライン９５のＳｔａｒｔＳＴＣフィールド９５ｆ（図１２（ａ））には、そのクリップ内の先頭ＫＰＵの中で最初に表示されるピクチャの再生時刻情報（ＰＴＳ）が記述されている。そのピクチャのＰＴＳ値と指定された時刻に対応するＰＴＳ値とに基づいて、再生開始すべきピクチャまでのＰＴＳ（ＡＵＴＭ）差分値が得られる。なお、各ピクチャに割り振られているＰＴＳ値のデータ量と、ＳｔａｒｔＳＴＣフィールド９５ｆに規定されているＰＴＳ値のデータ量とを一致させることが好ましく、例えば３３ビットで表記される。

上述の差分値がＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値よりも大きければ、再生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に存在すると判断できる。後者のときは、さらにそのＰＴＳ差分値に基づいて、どの程度先の時刻かも容易に特定できる。

図１３（ｂ）は、ＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ｂ）の横軸の１目盛りは１データユニット長（Ｔｉｍｅｄ ＴＳ Ｐａｃｋｅｔ Ｂｙｔｅ Ｌｅｎｇｔｈ；ＴＰＢＬ）を示している。これは１データユニットがＴＴＳパケットのデータ量（１９２バイト）と等しいことを意味する。

各ＫＰＵエントリは、各キーピクチャユニットＫＰＵに対して１つ設けられている。ＫＰＵエントリの設定に関連して、各ＫＰＵのデータサイズがＫＰＵＳｉｚｅフィールド９８ｄに記述され、各タイムエントリごとに対応するＫＰＵの開始アドレスがＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂに記述される。なお、各キーピクチャユニットＫＰＵのデータサイズは、例えば図１３（ｂ）のＫＰＵｓｉｚｅ＃ｋに示すように、そのＫＰＵの中で最初のピクチャのデータを格納した最初のＴＴＳパケットから、次のＫＰＵの最初のピクチャを格納したＴＴＳパケット直前のＴＴＳパケットまでのデータサイズを１データユニット長（ＴＰＢＬ）で示して表される。

さらにＫＰＵエントリには、ファイルの最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定されている。このフィールドを設ける理由は以下のとおりである。例えば１ショットのクリップＡＶストリームのデータが複数のファイルに分けて格納されたとき、２番目以降のファイルの先頭には先のファイル最後尾のＫＰＵの一部が格納されることがある。キーピクチャユニットＫＰＵ内の各ピクチャは、ＫＰＵ先頭のキーピクチャから復号化をしなければならないため、ファイルの先頭に存在するデータは単独で復号化できない。よってそのようなデータは、意味のないデータ（フラグメント）として読み飛ばすことが必要になる。そこで上述のオフセットフィールド９５ｄに
そのオフセット値を利用して、読み飛ばしを可能にしている。

ここで、図１４を参照しながら、１ショットのクリップＡＶストリームデータが複数のファイルに分けて格納されたときのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ等を説明する。説明の簡単のために、ここでは１ショットのコンテンツに関する管理情報とクリップＡＶストリームとが、２つのリムーバブルＨＤＤ＃１および＃２に格納されるとして説明し、またクリップメタデータには言及しない。

図１４は、２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す。リムーバブルＨＤＤ＃１および＃２には、それぞれクリップタイムラインのファイル（００００１．ＣＴＬおよび００００２．ＣＴＬ）と、クリップＡＶストリームのファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）とが格納されている。

以下では、ＫＰＵエントリに注目する。まず、リムーバブルＨＤＤ＃１上のＫＰＵエントリ＃（ｄ−１）は、００００１．ＴＴＳ内のクリップＡＶストリームに規定されるキーピクチャユニットＫＰＵ＃（ｄ−１）に対応して設けられている。図１４に示すように、キーピクチャユニットＫＰＵ＃（ｄ−１）のすべてのデータは、００００１．ＴＴＳ内に存在している。その場合には、ＫＰＵエントリ＃（ｄ−１）のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。

次に、ＫＰＵエントリ＃ｄおよび対応するキーピクチャユニットＫＰＵ＃ｄに着目する。図１４に示すキーピクチャユニットＫＰＵ＃ｄは、その一部（キーピクチャユニットＫＰＵ＃ｄ１）がリムーバブルＨＤＤ＃１の００００１．ＴＴＳ内に存在し、他の一部（キーピクチャユニットＫＰＵ＃ｄ２）がリムーバブルＨＤＤ＃２の００００２．ＴＴＳ内に存在している。キーピクチャユニットＫＰＵ＃ｄが２つのリムーバブルＨＤＤに分けて格納されている理由は、例えばリムーバブルＨＤＤ＃１への書き込み中に、記録可能な残り容量が所定値以下になり、それ以上の書き込みが不可能になったためである。この場合には、ＫＰＵエントリ＃ｄのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには１ｂが設定される。

なお、リムーバブルＨＤＤ＃２内のＫＰＵエントリ＃０に対応するキーピクチャユニットＫＰＵは、そのすべてのデータがリムーバブルＨＤＤ内に格納されているから、そのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。

上述のようにＫＰＵエントリ内のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を調べることにより、そのキーピクチャユニットＫＰＵがそのメディア内のファイルに格納されているか否かが判断できる。この利点は、例えば以下の処理において非常に効果的である。

図１４に示すように、ＫＰＵ＃ｄを構成するデータが複数のＴＴＳファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）に跨って格納されているときにおいて、リムーバブルＨＤＤ＃２内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムーバブルＨＤＤ＃１に格納されたデータのみに基づいて１ショットの再生が行われる。

編集処理によって１ショットの再生時間が変化するため、正確な再生時間を算出する必要がある。そこで、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に基づいて再生時間の算出処理を変化させることができる。具体的に説明すると、リムーバブルＨＤＤ＃１内の最後のＫＰＵ＃ｄに関してはＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値は“１ｂ”である。このときは、先頭からＫＰＵ＃（ｄ−１）までのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和を、リムーバブルＨＤＤ＃１内のクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用すればよい。換言すれば、上述の数２においてキーピクチャユニットＫＰＵ＃ｄのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の値はクリップの再生時間として算入しない。その理由は、実際に再生可能な時間（最初のＫＰＵからＫＰＵ＃（ｄ−１）まで）と数２に基づいて算出した１ショットの再生時間（最初のＫＰＵからＫＰＵ＃ｄまで）との間には、最後のＫＰＵ＃ｄ相当の再生時間（０．４秒以上１秒未満）だけ誤差が発生し得るからである。機器から提示された再生時間がこのような大きな誤差を含むことは、特に業務用途の機器においては決してあってはならないことはいうまでもない。

一方、仮に、リムーバブルＨＤＤ＃１内の最後のＫＰＵに対応するＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“０ｂ”のときは、先頭から最後までの各キーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用すればよい。最後のキーピクチャユニットＫＰＵ内の全てのピクチャが再生可能であるため、そのＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）に算入すべきだからである。

以上説明したように、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に応じてクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の算出する処理を変化させることにより、常に正確な再生時間長を算出できる。

また、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を利用して不完全なキーピクチャユニットＫＰＵを削除するか否かを決定し、削除したときには残されたクリップについてクリップタイムラインを修正してもよい。この「不完全なキーピクチャユニット」とは、全てのピクチャのデータが存在しないキーピクチャユニットをいい、ここではＫＰＵ＃ｄ２が存在しないＫＰＵ＃ｄに相当する。

具体的に説明すると、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”のときには、不完全なキーピクチャユニットＫＰＵ＃ｄ１をキーピクチャユニットＫＰＵとして取り扱わないように、ＴＴＳファイルから削除し、リムーバブルＨＤＤ＃１内のクリップタイムラインを修正すればよい。クリップタイムラインの修正は、キーピクチャユニットＫＰＵの数（ＫＰＵＥｎｔｒｙＮｕｍｂｅｒ９５ｂ）を減少させること、ＫＰＵ＃ｄのＫＰＵエントリを削除すること、キーピクチャユニットＫＰＵ＃ｄ１内のタイムエントリ（ＴｉｍｅＥｎｔｒｙ）９５ｇを削除すること等を含む。修正後は、リムーバブルＨＤＤ＃１の００００１．ＴＴＳファイルの最後のキーピクチャユニットはＫＰＵ＃（ｄ−１）になり、最初のＫＰＵから最後のＫＰＵ＃（ｄ−１）までの再生時間の和が１ショットの再生時間になる。よって、上述の数１〜数３を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削除はＦＡＴ３２ファイルシステム上においても、ＴＴＳパケット（１９２バイト）単位で可能である。

他の利点は以下のとおりである。所定の再生時刻から再生を開始するような場合、図１３に示すような再生時刻と記録アドレスのテーブル情報であるタイムマップ（ＣｌｉｐＴｉｍｅＬｉｎｅ）を使って、飛び込むべきキーピクチャユニットＫＰＵを特定することができる。しかしながら、ＭＰＥＧ規格等に採用されている順方向符号化方式および双方向符号化方式を利用して映像データを圧縮符号化する時、復号はイントラコーディングピクチャ（Ｉピクチャ）から開始しなければ、後続のピクチャが正しく復号できない。従って、再生開始すべきピクチャが含まれるキーピクチャユニットＫＰＵ（厳密にはＫＰＵＰｅｒｉｏｄ）を特定できた場合であっても、そのピクチャから再生するためには、そのピクチャが属するキーピクチャユニットＫＰＵの先頭であるキーピクチャから復号を開始しなければならない。そこで、まずＫＰＵエントリ＃ｄのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を確認し、そのＫＰＵの先頭であるキーピクチャが記録されているファイルを確かめる必要がある。

具体的にはＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”のときは、再生開始のピクチャから正しく復号できるようにリムーバブルＨＤＤ＃１のキーピクチャユニットＫＰＵ＃ｄ１の先頭からデータを読み出すように動作を制御することができる。誤ってリムーバブルＨＤＤ＃２の先頭からデータを読み出し、参照ピクチャが取得できず、デコードができないと判断する処理を行わなくてすむため、読み出し時間、デコードができるか否かの判断に要する時間およびそれらの処理に要する処理負荷を低減できる。または、復号に失敗した映像を表示することを防ぐことができる。一方、値が“０ｂ”のときは、そのＫＰＵエントリが存在するリムーバブルＨＤＤと同じメディアからデータの読み出しを開始すればよい。ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドを設けることは、上記のように例えばタイムマップを利用した飛び込み再生や、早送り再生や巻き戻し再生のような高速かつ複雑な処理に特に有効である。

なお、キーピクチャユニットＫＰＵ＃ｄ２は、リムーバブルＨＤＤ＃２内ではフラグメントであり、そのデータのみではビデオは復号化できない。よって、リムーバブルＨＤＤ＃２内のクリップＡＶストリームファイル（００００２．ＴＴＳ）の最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定される。さらに、そのキーピクチャユニットＫＰＵ＃０の先頭から、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。なお、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０でないときは、前のリムーバブルＨＤＤからのキーピクチャユニットＫＰＵが格納されていることを表すため、上述の巻き戻し再生時にはまず、クリップメタデータ９４のリレーション情報を参照することで、直前のクリップがあるか否かを特定することができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能であった場合には、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０か否かを確認し、０でないときに前のリムーバブルＨＤＤの最後のキーピクチャユニットＫＰＵに対応するＫＰＵエントリのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値をさらに確認して、キーピクチャユニットＫＰＵの跨ぎが発生しているか否かを確実に判定することもできる。

次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用してコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集する際の処理を説明する。

まず図１５および図１６を参照しながら、コンテンツをリムーバブルＨＤＤに録画するときのカムコーダ１００の処理（録画処理）を説明する。

図１５は、カムコーダ１００によるコンテンツの録画処理の手順を示す。まずステップＳ１５１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから撮影開始の指示を受け取る。そして、ステップＳ１５２において、ＣＰＵ２１１からの指示に基づいて、エンコーダ２０３は入力信号に基づいてＴＳを生成する。なおデジタル放送の録画時には、ステップＳ１５１において録画開始の指示を受け取り、ステップＳ１５２においてデジタルチューナ２０１ｃを用いて録画対象の番組のＴＳパケットを抽出すると読み替えればよい。

ステップＳ１５３では、メディア制御部２０５は、ＴＳ処理部２０４においてＴＴＳヘッダが付加されたＴＳ（クリップＡＶストリーム）を、順次リムーバブルＨＤＤに書き込む。そしてメディア制御部２０５は、ステップＳ１５４において、クリップ（ＴＴＳファイル）を新規に作成するか否かを判断する。新規に作成するか否かは、記録中のクリップのＴＴＳファイルのサイズが所定値よりも大きいか否か、あるいはリムーバブルＨＤＤの残容量に応じて任意に決定できる。新規にクリップを作成しない場合はステップＳ１５５に進み、新規にクリップを生成するときはステップＳ１５６に進む。

ステップＳ１５５では、ＴＳ処理部２０４は、キーピクチャユニットＫＰＵが生成されるごとに、ＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵのすべてのデータはそのクリップのＴＴＳファイル内に書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“０ｂ”を設定する。そしてメディア制御部２０５は、ステップＳ１５７においてＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）をリムーバブルメディアに書き込む。その後、ステップＳ１５８において、ＣＰＵ２１１は撮影終了か否かを判断する。撮影は、例えば指示受信部２１５を介して撮影終了指示を受信したとき、次にデータを書き込むべきリムーバブルＨＤＤが存在しないとき等に終了する。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はステップＳ１５２に戻り、それ以降の処理が繰り返される。

一方ステップＳ１５６では、ＴＳ処理部２０４は、最後に書き込まれたデータによってキーピクチャユニットＫＰＵが完結したか否かを判断する。仮にキーピクチャユニットＫＰＵが完結しなければ、そのキーピクチャユニットＫＰＵの残りのデータは他のリムーバブルＨＤＤに格納されることになる。そのため、キーピクチャユニットＫＰＵのすべてのデータがそのリムーバブルＨＤＤ内に書き込まれたか否かを判断するために、このような判断が必要になる。キーピクチャユニットＫＰＵが完結しているときには処理はステップＳ１５５に進み、完結していないときには処理はステップＳ１５９に進む。

ステップＳ１５９では、ＴＳ処理部２０４によってクリップ切り替え処理が行われる。この処理の具体的な内容を、図１６に示す。

図１６は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ（クリップ）の録画先のメディアを、あるリムーバブルＨＤＤから他のリムーバブルＨＤＤに切り替えたり、同一リムーバブルＨＤＤ上で新規クリップを生成したりする処理である。以下では説明を簡略化するために、クリップの切り替えが、コンテンツの録画先メディアの変更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブルＨＤＤを「第１リムーバブルＨＤＤ」と呼び、次にコンテンツが録画されるリムーバブルＨＤＤを「第２リムーバブルＨＤＤ」と呼ぶ。

まずステップＳ１６１において、ＣＰＵ２１１は、第２リムーバブルＨＤＤ上に生成されるクリップのクリップ名を決定する。次に、ステップＳ１６２において、カムコーダ１００は第１リムーバブルＨＤＤに完全に記録できなかったキーピクチャユニットＫＰＵが完結するまでＴＳを生成する。そして、ＴＳ処理部２０４はＴＴＳヘッダを付加し、メディア制御部２０５はそのクリップＡＶストリームを第２リムーバブルＨＤＤに書き込む。

次にステップＳ１６３において、メディア制御部２０５は、完結したＫＰＵのＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵは第１リムーバブルＨＤＤおよび第２リムーバブルＨＤＤに跨って書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“１ｂ”を設定する。

ステップＳ１６４において、メディア制御部２０５は、生成したＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を、第１リムーバブルＨＤＤに書き込む。そして、ステップＳ１６５において、第１リムーバブルＨＤＤ上のクリップ・メタデータ（リレーション情報等）を更新する。例えば、メディア制御部２０５は、第１リムーバブルＨＤＤ上のクリップのクリップメタデータに、次のクリップとして第２リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。また、第２リムーバブルＨＤＤ上のクリップのクリップメタデータに、前のクリップとして第１リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。その後、ステップＳ１６６において、メディア制御部２０５は、今後のコンテンツの書き込み先を第２リムーバブルＨＤＤに設定し、処理が終了する。

次に、図１７を参照しながら、カムコーダ１００がリムーバブルＨＤＤからコンテンツを再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初から再生するときの処理は、ＫＰＵエントリ、タイムエントリ等を設けない従来の処理と同じであるため、その説明は省略する。

図１７は、カムコーダ１００によるコンテンツの再生処理の手順を示す。ステップＳ１７１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから再生開始時刻の指示を受け取る。

ステップＳ１７２において、メディア制御部２０５は時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を読み出して、ＣＰＵ２１１が再生開始時刻のピクチャを含むキーピクチャユニット（ＫＰＵ）を特定する。そして、ステップＳ１７３において、ＣＰＵ２１１は、再生開始時刻に対応するＫＰＵの開始位置を特定する。このＫＰＵの開始位置は、ＴＴＳファイル内の復号開始位置（アドレス）を表している。

これらの処理の一例は以下のとおりである。すなわち、ＣＰＵ２１１は、再生開始時刻がタイムエントリ＃ｔとタイムエントリ＃（ｔ＋１）の間の時刻であることを特定し、さらにタイムエントリ＃ｔから起算してｍアクセスユニット時間（ＡＵＴＭ）を１単位として何単位離れているかを特定する。

具体的には、まずタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａの値に基づいて、あるＫＰＵ（ＫＰＵ＃ｋとする）が特定される。そして、タイムエントリ＃ｔが指し示す時刻からＫＰＵ＃ｋの先頭キーピクチャの再生が開始されるまでの時間差がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃの値に基づいて取得される。その結果、再生開始すべきピクチャがＫＰＵ＃ｋの中で最初に表示されるピクチャから何ＡＵＴＭ後か判明する。すると、ＫＰＵ＃ｋからＫＰＵごとにＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）を加算していくことで、再生開始すべきピクチャを含むＫＰＵが特定できる。また、タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレスにＫＰＵ＃ｋから再生開始すべきピクチャを含むＫＰＵの直前のＫＰＵまでのＫＰＵＳｉｚｅを加算していくことで、再生開始時刻に対応するＫＰＵの開始位置を特定できる。なお、「タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレス」は、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値とタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂの値との和を計算することによって取得できる。

なお、上述の説明は、説明の簡略化のためＣｌｏｓｅｄＧＯＰ構造（ＧＯＰ内の全てのピクチャはＧＯＰ内のピクチャを参照するのみ）を前提としている。しかしながら、ＣｌｏｓｅｄＧＯＰ構造が取れない場合や、保証できない場合には、特定された再生開始時刻を含むＫＰＵの一つ前のＫＰＵから復号を開始してもよい。

次のステップＳ１７４では、メディア制御部２０５はそのキーピクチャユニット（ＫＰＵ）のＫＰＵＥｎｔｒｙ中のフラグを読み出し、ステップＳ１７５においてＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”か否かを判断する。値が“１ｂ”のときは、キーピクチャユニットＫＰＵが第１および第２リムーバブルＨＤＤにまたがることを意味しており、処理はステップＳ１７６に進む。一方値が“０ｂ”のときは、跨らないことを意味しており、処理はステップＳ１７７に進む。

ステップＳ１７６において、メディア制御部２０５は第１リムーバブルＨＤＤに格納されたＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。このとき、特定したピクチャによっては、読み出しを開始した第１リムーバブルＨＤＤではなく第２リムーバブルＨＤＤにデータが格納されていることもあるが、復号を正しく行うために２つのクリップ（ＴＴＳファイル）を跨ぐＫＰＵの先頭キーピクチャからデコードが行われる。

ステップＳ１７７では、メディア制御部２０５はＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブルＨＤＤ内に格納されている。

その後、ステップＳ１７８では、再生開始時刻に対応するピクチャのデコード終了後に、グラフィック制御部２０７はそのピクチャから出力を開始する。対応する音声が存在するときには、スピーカ２０９ｂもまたその出力を開始する。その後は、コンテンツの最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終了する。

次に、図１８および図１９を参照しながら、リムーバブルＨＤＤに録画されたコンテンツを編集する処理を説明する。この処理は、カムコーダ１００においても実行されるとして説明するが、他には、コンテンツが録画されたリムーバブルＨＤＤが装填されたＰＣ１０８（図１）等において実行されてもよい。

図１８（ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す。図１８（ａ）に示される範囲Ｄが、削除の対象となる部分である。この範囲Ｄは、ＴＴＳファイルの先頭部分を含む。先頭部分のアドレスをｐ１とし、ｐ１＋Ｄ＝ｐ４とする。これまで説明したように、クリップＡＶストリームは複数のファイルに分けて格納されることがあるが、以下の処理は、各ＴＴＳファイルの先頭部分を含む削除に対して適用される。

図１８（ｂ）は、範囲Ｄを削除した後の管理情報（クリップタイムライン）およびクリップＡＶストリームの関係を示す。本実施形態では、範囲Ｄのすべてを常に削除するのではなく、範囲Ｄに収まるデータ量のうち、９６キロバイトのｎ倍（ｎ：整数）のデータ量だけを削除する。いま、削除後の先頭データ位置をアドレスｐ２とすると、（ｐ２−ｐ１）は、（９６キロバイト）×ｎである。また、ｐ２≦ｐ４である。

「９６キロバイト」は、本実施の形態において採用するクラスタサイズ（３２キロバイト）と、ＴＴＳパケットのパケットサイズ（１９２バイト）との最小公倍数である。このように処理する理由は、クラスタサイズの整数倍とすることによってリムーバブルＨＤＤに対するデータ削除処理がアクセス単位で実行でき、またＴＴＳパケットのパケットサイズの整数倍とすることによってデータ削除処理がクリップＡＶストリームのＴＴＳパケット単位で実行できるため、処理を高速化かつ簡易にできるからである。なお、本実施形態ではクラスタサイズを３２キロバイトとしているため、９６キロバイトを基準として削除単位を決定したが、この値はクラスタサイズや、採用するクリップＡＶストリームのパケットサイズに応じて変化し得る。

削除処理では、さらにＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃおよびＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値も変更される。これらの値は、削除前は０である。削除後は、まずＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに、初めて現れるキーピクチャユニットＫＰＵまでのデータ量が記述される。初めて現れるキーピクチャユニットＫＰＵの格納アドレスをｐ３とすると、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄは（ｐ３−ｐ２）の値が記述される。また、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに、最初のキーピクチャユニットＫＰＵの中で先頭のキーピクチャの再生時刻から最初のタイムエントリまでの時間差がＡＵＴＭ単位で記述される。なお、アドレスｐ２からｐ３までのクリップＡＶストリームのパケットは、単独でデコードできるという保証がないため、フラグメントとして扱われ、再生の対象とはされない。

図１９は、カムコーダ１００によるコンテンツの部分削除処理の手順を示す。まずステップＳ１９１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザからＴＴＳファイルの部分削除指示、および、削除範囲Ｄの指定を受け取る。部分削除指示とは、ＴＴＳファイルの先頭部分および／または末尾部分を削除する指示である。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および／または末尾部分を削除する「後方部分削除処理」が行われる。

ステップＳ１９２において、前方部分削除処理か否かが判定される。前方部分削除処理を行う場合にはステップＳ１９３に進み、前方部分削除でない場合にはステップＳ１９５に進む。ステップＳ１９３では、メディア制御部２０５は、削除範囲に相当するデータ量Ｄのうち、９６キロバイトの整数倍のデータ量を先頭から削除する。そしてステップＳ１９４において、メディア制御部２０５は、時間・アドレス変換テーブル（クリップタイムライン）中の、最初のタイムエントリに対する時間オフセットの値（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）と最初のＫＰＵエントリに対するアドレスオフセット値（ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値）とを修正する。その後、処理はステップＳ１９５に進む。

ステップＳ１９５では、後方部分削除処理か否かが判定される。後方部分削除処理を行う場合にはステップＳ１９６に進み、行わない場合にはステップＳ１９７に進む。ステップＳ１９６では、削除範囲に相当するデータ量のうち、ＴＴＳファイルの最後が完全なＫＰＵとなるよう１９２バイト単位でデータが削除される。これはすなわち、１９２バイトの整数倍のデータ量のデータが削除されることを意味する。その後処理はステップＳ１９７に進む。

ステップＳ１９７では、部分削除処理によって変化したタイムエントリ数やＫＰＵエントリ数等を修正する。具体的には、時間・アドレス変換テーブル（ＣｌｉｐＴｉｍｅＬｉｎｅ）中で、実データを伴わなくなったＫＰＵＥｎｔｒｙエントリ、およびＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤで参照していたＫＰＵＥｎｔｒｙエントリを失ったＴｉｍｅＥｎｔｒｙエントリが削除される。また、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａの値、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂの値等の修正処理が行われる。

なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合にもステップＳ１９７を経由する。これは、例えばＴＴＳファイルの中間部分の削除処理が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削除処理は本明細書においては特に言及しない。

なお、上述のように部分削除処理はＴＴＳファイルの先頭部分に限られず、ＴＴＳファイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の不完全なキーピクチャユニットＫＰＵ（図１４のＫＰＵ＃ｄ１）を削除する際に適用される。不完全なキーピクチャユニットＫＰＵは１クリップの最後に存在しているため、「ＴＴＳファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全なキーピクチャユニットＫＰＵの先頭からＴＴＳファイルの最後までであり、例えばＴＴＳパケットのパケットサイズ（１９２バイト）単位で削除する範囲を決定すればよい。クラスタサイズは特に考慮しなくてもよい。なお、ＴＴＳファイルの最後の部分は不完全なキーピクチャユニットＫＰＵに限られず、ユーザから範囲の指定を受けること等により、任意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行ってもよいし、一方の処理のみを行ってもよい。

（実施の形態２）
次に、本発明の実施の形態２について説明する。実施の形態１との主な違いは、第1に毎秒６０フレームのＭＰＥＧ−２の動画ストリーム中に毎秒２４フレームの映像を３：２プルダウンにより記録する点である。第２に、毎秒２４フレームでカウントしたタイムコード値をクリップメタデータファイル内に記録する点である。

図２０は、毎秒６０フレーム、横と縦の画素数が１２８０×７２０のＭＰＥＧ−２の動画ストリーム中に、毎秒２４フレームの映像を３：２プルダウン記録する場合の説明図である。図中にクリップＡＶストリームの先頭部分のピクチャ構造、および対応する管理パラメータを示す。クリップＡＶストリームの先頭ＫＰＵ＃０、および次のＫＰＵ＃１は、表示順で記載した場合、ＢＢＩＢＢＰＢＢ・・・の各ピクチャから構成される（記録順は、ＩＢＢＰＢＢ・・・）。クリップＡＶストリームの各ピクチャ層のユーザデータ（ＭＰＥＧ２ビデオ規格のｅｘｔｅｎｔｉｏｎ＿ｕｓｅｒ＿ｄａｔａ（２））内には、毎秒２４フレームでカウントされるタイムコードが記録される。具体的には、表示順が先頭のＢピクチャには００：００：００：００が記録され、次のＢピクチャには００：００：００：０１が記録される。次のＩピクチャには００：００：００：０２が記録される。毎秒２４フレームなので００：００：００：２３の次は、桁が上がり００：００：０１：００となる。なお、ＭＰＥＧ−２ビデオ規格上、ユーザデータ内には基本的に自由に値を格納することができる。だだし、特定の４バイトコード（たとえば、シーケンヘッダーコードである０ｘ０００００１Ｂ３）とは重複しない様に、４バイト周期で特定のビットを１にする等の配慮は必要である。

また一方、ＧＯＰ層のＧＯＰヘッダ内のタイムコードフィールドには、ＭＰＥＧ−２ビデオ規格の規定に従って、毎秒６０フレームでカウントされるタイムコードが記録される。具体的にはＫＰＵ＃０のＧＯＰヘッダには図２０の先頭のＢピクチャに対応する００：００：００：００が記録され、ＫＰＵ＃１のＧＯＰヘッダにはＫＰＵ＃１の先頭ピクチャに対応する００：００：００：３０が記録される。ＧＯＰヘッダのタイムコードは、００：００：００：５９の次に桁上がりして００：００：０１：００の様にカウントされる。

図２１はクリップメタデータファイルが含むデータ構造を示す。内部にクリップ名、再生時間長、ＥｄｉｔＵｎｉｔ長、リレーション、エッセンスリストの各フィールドを含む。さらにエッセンスリストには、フォーマット種別、ピークビットレート、映像の各フィールドを含む。さらに映像フィールドには、コーデック情報、プロファイル／レベル、フ
レームレート情報、画素数、ドロップフレームフラグ、プルダウン情報、開始タイムコード、終了タイムコード、アスペクト比、再生しない区間長、先頭３フレームフラグの各フィールドを含む。

再生時間長フィールドは、１クリップの再生時間長をＥｄｉｔＵｎｉｔ単位で表現する。ＥｄｉｔＵｎｉｔ長フィールドは、１単位のＥｄｉｔＵｎｉｔ長の時間長を指定する。図２１中では１／２４秒が指定されている。

リレーション情報フィールドは、同じショット内の後続クリップのＴＴＳファイルの名前（MOV00002.TTS）が記録されている。フォーマット種別フィールドには、クリップのＡＶデータのフォーマット種別がＴｉｍｅｄ ＴＳとして登録されている。ピークビットレートフィールドには、ＭＰＥＧ−２トランスポートストリームのピークビットレートが２４Ｍｂｐｓであることが登録されている。映像フィールドには、コーデック情報、プロファイル／レベル情報、フレームレート情報、画素数情報（横×縦）、ドロップフレームフラグ、プルダウン情報、アスペクト比として、それぞれＭＰＥＧ−２Ｖｉｄｅｏ、ＭＰ＠ＨＬ、１／６０、１２８０×７２０、ノンドロップ、３：２プルダウン、１６：９、０ＥｄｉｔＵｎｉｔが記録されている。また、クリップ中で再生される先頭ピクチャのタイムコード、を開始タイムコードとして記録する。また、再生される最終ピクチャの次のタイムコード値を終了タイムコードとして記録する。これらのタイムコード値は時：分：秒：フレーム番号として記録される。図２１では、それぞれ００：００：００：００、および００：０１：００：００（１分の長さ）の値が登録されている。なお、終了タイムコードは最終ピクチャのタイムコード値であっても良い。

先頭３フレームフラグ３００ｓは、開始タイムコード３００ｏに対応する先頭ピクチャが、３フレーム区間に対応するのか、それとは２フレーム区間に対応するのかを示す。前者の場合、値は１であり、後者の場合値は０である。図２１では、値は１に設定されているものとする。

図２２は実施の形態２におけるＣｌｉｐＴｉｍｅＬｉｎｅファイルのデータ構造を示す。実施の形態１との違いは、タイムエントリ９５ｇが無いことである。

図２３は、タイムコード値からそのタイムコード値に対応するピクチャの格納先アドレスを算出する際の変換手順を示す。

図２４は、１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図である。この図で、各ＫＰＵは表示順に配置されている。開始タイムコード（300o）、およびＫＰＵＰｅｒｉｏｄ（２９８ｃ）は図２０で説明済みである。また、再生時間長、ＳｔａｒｔＳＴＣ、およびＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎは実施の形態１と同様である。

図２５は、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔが零でなく、かつ１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図である。図２４と較べて、再生しない区間長が零でない点、および最後のＫＰＵの後半を再生しない点（具体的には再生時間長から除外している）が異なる。また、図２５中に図１８のｐ２、ｐ３、ｐ４に対応する箇所を示す。

図２６は、１ショットが複数のＴＴＳファイルのチェーンで構成される場合の管理パラメータを示す図である。各ＴＴＳファイルのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎは、それぞれのＴＴＳファイルに対応するタイムマップファイルのＫＰＵＥｎｔｒｙ（２９５ｈ）のＫＰＵＰｅｒｉｏｄの合計となる。

実施の形態２におけるＡＶデータ記録再生装置の基本的な構成は、図２と同様であるが、各部の動作は実施の形態１とほぼ同様であるが、以下で説明する様な異なる動作を含む。

カムコーダ１００は、ＣＣＤ２０１aが出力する毎秒２４フレームの映像をＭＰＥＧ−２エンコーダ２０３で毎秒６０フレームのＭＰＥＧ−２トランスポートストリームを生成し、ショットとしてリムーバブルＨＤＤへ記録する。この時、ＭＰＥＧ−２エンコーダ２０３は、ピクチャ層のユーザデータ内に毎秒２４フレーム毎にカウントアップするタイムコードを格納する。また、ＭＰＥＧ−２エンコーダは、３：２プルダウン記録するために、一枚のピクチャを１／６０回の周期で数えて３周期分、もしくは２周期分だけ交互に表示するようにＭＰＥＧ−２ビデオストリームを生成する。３周期分、もしくは２周期分表示するための指示は、ＭＰＥＧ規格に従ってピクチャヘッダ内に格納する。具体的にはｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔの値が両方共に１の場合は、３周期分を意味し、それぞれの値が１と０の場合は２周期分を意味する。

再生時はリムーバブルＨＤＤに記録されたクリップＡＶストリームを読出し、ＭＰＥＧ−２デコーダ２０６で復号を行う。このとき、ピクチャ層のユーザデータ内に記録された毎秒２４フレームでカウントするタイムコードを読出し、その値を映像上にオーバーレイ表示する。

編集時において、ユーザは映像上にオーバーレイ表示されたタイムコード値を見て、ＩＮ点、ＯＵＴ点、もしくは注目点として取り扱いたい映像のタイムコード値を確認可能である。また、カムコーダはその映像のタイムコード値を取得し、その取得したタイムコード値を、たとえばプレイリスト内でＩＮ点、ＯＵＴ点の値として設定する。

この様なプレイリストを再生する場合、毎秒２４フレーム毎にカウントされるタイムコード値から、図２３に示す手順により、対応するピクチャの記録アドレスへの変換処理が実施される。すなわち、タイムコード値を入力すると（Ｓ３１０）、まずその入力したタイムコード値と開始タイムコード値（２９５ｆ）との差分に、再生しない区間長（３００ｒ）を加算した値を、差分タイムコード値として算出する（Ｓ３１１）。次にその差分タイムコード値を使って、対応するＳＴＣ値である目標ＳＴＣ値を算出する。先頭３フレームフラグの値が１の場合の計算式をＳ３１２に示す。Ｓ３１２のＣｅｉｌ（ｘ）関数（ここでｘは実数）は、値ｘ以上で、かつ最もｘに近い整数値を関数値とする。ここで差分タイムコード値を５／２倍しているのは、毎秒３：２プルダウンしたＭＰＥＧストリームとして記録しているためである。

なお、先頭３フレームフラグの値が０の場合は、目標ＳＴＣ値は次式より求まる。

（数４）
目標ＳＴＣ値＝ＳｔａｒｔＳＴＣ値（２９５ｆ）
＋ｆｌｏｏｒ（差分タイムコード×（５／２）×（２７，０００，０００／６０））
ここで、ｆｌｏｏｒ（ｘ）関数（ここでｘは実数）は、値ｘ以下で、かつ最もｘに近い整数値を関数値の値とする。

次に各ＫＰＵＥｎｔｒｙ（２９５ｈ）のＫＰＵＰｅｒｉｏｄ（２９８ｃ）を、ＫＰＵ＃０のＫＰＵＥｎｔｒｙから順に加算し、
（数５）
目標ＳＴＣ値≦ＳｔａｒｔＳＴＣ値（２９５ｆ）＋ΣＫＰＵＰｅｒｉｏｄ
となる初めてのＫＰＵ番号（その番号をｋとする）を導出する（Ｓ３１３）。ここで、指定されたタイムコード値に対応するピクチャのアドレスは、ＫＰＵ＃ｋに含まれることになる。次にこのＫＰＵ＃ｋの格納先アドレスを次式より求める（Ｓ３１４）。

（数６）
ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔ（２９５ｄ）＋ΣＫＰＵＳｉｚｅ
ただし、ΣＫＰＵＳｉｚｅはＫＰＵ＃０から、ＫＰＵ＃ｋまで
さらに、ＫＰＵ＃ｋの先頭ピクチャ（ただし表示順）と、タイムコード値に対応するピクチャとの間の差分ＳＴＣを次式より求める（Ｓ３１５）。

（数７）
差分ＳＴＣ＝目標ＳＴＣ値−（ＳｔａｒｔＳＴＣ値＋ΣＫＰＵＰｅｒｉｏｄ）
差分ＳＴＣ＞０の場合には、この時間差分だけ表示スキップする必要がある。

以上の様に、ユーザは毎秒２４フレーム中の１画像をＩＮ点、ＯＵＴ点、もしくはチャプターの分割点として直接指定して、そのフレームのタイムコードを使ってプレイリスト
を使った仮想編集や、クリップＡＶストリームの分割編集を実施できる。これにより、編集作業を効率的に進めることができる。

なお、実施の形態２においてショットの前方削除を実施する場合は、実施の形態１と同様の処理が必要となることに加えて、開始タイムコード（３００o）、および再生しない
区間長（３００ｒ）の変更が必要となることは言うまでも無い。

（実施の形態３）
次に、本発明の実施の形態３について説明する。実施の形態３と実施の形態２とは、ＫＰＵＥｎｔｒｙのデータ構造が異なる。

図２７は、毎秒６０フレーム、横と縦の画素数が１２８０×７２０のＭＰＥＧ−２の動画ストリーム中に、毎秒２４フレームの映像を３：２プルダウン記録する場合の説明図である。実施の形態２の図２０との違いは、第1にＫＰＵＥｎｔｒｙ内で、ＫＰＵＰｅｒｉｏｄに代わってＰＴＳＤｉｆｆｒｅｎｃｅ（３９８ｃ）を管理する点である。第２にＳｔａｒｔＳＴＣ（２９５ｆ）の代わりにＳｔａｒｔＫｅｙＳＴＣ（３９５ｆ）を管理する点である。第３にＴｉｍｅＯｆｆｓｅｔ（３９５ｉ）を管理する点である。ＰＴＳ Ｄｉｆｆｅｒｅｎｃｅは、あるＫＰＵと直後のＫＰＵの間で、キーピクチャのＰＴＳ間の差分を、ＡＵＴＭを単位として表現したフィールドである。ＳｔａｒｔＫｅｙＳＴＣフィールドは、ひとつのＴＴＳファイル中の先頭ＫＰＵであるＫＰＵ＃０内の最初のＩピクチャの表示タイミングを、ＡＵＴＭの単位で表現したものである。ＴｉｍｅＯｆｆｓｅｔフィールドは、先頭のＫＰＵであるＫＰＵ＃０の中で最初に表示されるピクチャ（図２７では、Ｂピクチャ）と、ＫＰＵ＃０内の最初のＩピクチャ間の時間差（図２７では、毎秒６０フレーム中の５フレーム区間）をＡＵＴＭの単位で示すものである。

図２８は実施の形態３におけるクリップメタデータファイルのデータ構造を示す。実施の形態２における図２１と同様であるが、再生時間長（４００ｂ）の設定値が図２１と異なる。この図２８は、１ショットが３個のクリップから構成される場合の、１個目のクリップのクリップメタデータファイルである。

図２９は実施の形態３におけるＣｌｉｐＴｉｍｅＬｉｎｅファイルのデータ構造を示す。実施の形態２の図２２との違いは、第1にＫＰＵＥｎｔｒｙ内で、ＫＰＵＰｅｒｏｄに代わってＰＴＳＤｉｆｆｒｅｎｃｅ（３９８ｃ）を管理する点である。第２にＳｔａｒｔＳＴＣ（２９５ｆ）の代わりにＳｔａｒｔＫｅｙＳＴＣ（３９５ｆ）を管理する点である。第３にＴｉｍｅＯｆｆｓｅｔ（３９５ｉ）を管理する点である。

図３０は、タイムコード値からそのタイムコード値に対応するピクチャの格納先アドレスを算出する際の変換手順を示す。

図３１は、１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図である。開始タイムコード（４００ｏ）は図２４と同じ意味である。再生時間長、およびＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎは実施の形態１と同じ意味である。実施の形態２の図２４と異なる点はＳｔａｒｔＳＴＣフィールド（２９５ｆ）がＳｔａｒｔＫｅｙＳＴＣフィールド（３９５ｆ）へ変更されている点である。

図３２は、実施の形態３におけるＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔが零でなく、かつ１ショットが３個のＴＴＳファイルで構成される場合の管理パラメータを示す図である。図３１と較べて、再生しない区間長が零でない点、および最後のＫＰＵの後半を再生しない点（具体的には、終了タイムコードで指定し、かつ再生時間長に含めない）が異なる。また、図３２中に図１８のｐ２、ｐ３、ｐ４に対応する箇所を示す。実施の形態３と異なる点は、第1にＴＴＳファイルの再生時間長は、開始タイムコードで参照される再生開始点から、後続する次のＴＴＳファイル内の最初の完全なＫＰＵ中のキーピクチャまでをＥｄｉｔＵｎｉｔ単位でカウントする点である。また、２番目のＴＴＳファイルの再生時間長は、同ＴＴＳファイル内の最初の完全なＫＰＵ中のキーピクチャから、後続する次のＴＴＳファイル中の最初の完全なＫＰＵのキーピクチャまでの時間差をＥｄｉｔＵｎｉｔ単位でカウントする点である。そして、１ショットの最後のＴＴＳファイルの再生時間長は、同ＴＴＳファイル中の最初の完全なＫＰＵ中のキーピクチャから、最後の再生すべきピクチャまでをＥｄｉｔＵｎｉｔ単位でカウントする。なお、１ショットが図３２の様に３個ではなくて、４個以上のＴＴＳファイルから構成される場合、先頭のファイルと最後のファイルを除いた、あいだのＴＴＳファイルの再生時間長は、図３１の２番目のＴＴＳファイルの再生時間長と同様な値を設定する。

また、実施の形態３において特徴的なのは、ＴＴＳファイルチェーンのうち、最初のＴＴＳファイルのみＴｉｍｅＯｆｆｓｅｔ（３９５ｉ）を管理する点である。ＣｌｉｐＴｉｍｅＬｉｎｅファイルで、ＴｉｍｅＯｆｆｓｅｔおよびＰＴＳ Ｄｉｆｆｒｅｎｃeを管理することにより、１ショットの再生時間長をピクチャ精度で管理することができる。ここで、ＰＴＳ Ｄｉｆｆｅｒｎｃｅは、ＭＰＥＧ−２ストリームのIピクチャのみ検出すれば良いので、全ピクチャ数をカウントする場合に較べて簡単な処理で済む。このことは、ＭＰＥＧエンコーダの外部回路でも容易にＰＴＳ Ｄｉｆｆｅｒｎｄｃｅを検出可能なことを意味する。また、ＰＴＳ Ｄｉｆｆｒｅｎｃｅの導入により、カムコーダの１３９４入力やチューナー等を介して放送波を記録する場合であっても、容易にＫＰＵ Ｅｎｔｒｙを生成可能となる。

また一方、ＴｉｍｅＯｆｆｓｅｔは、ショットの先頭部分だけIピクチャよりも前のフレーム数を検出することにより、容易に設定可能である。もしくは、ＭＰＥＧエンコーダ部が、ショットの先頭部分だけ、Ｉピクチャよりも前のフレーム数として固定値を使うことにより、容易にＴｉｍｅＯｆｆｓｅｔの値を設定可能である。またもしくは、外部機器等からクリップＡＶストリームを一旦記録した後で解析することにより容易にＴｉｍｅＯｆｆｓｅｔの値を設定可能である。

ここでショットの先頭部分だけＴｉｍｅＯｆｆｓｅｔを管理することは、ＭＰＥＧ−２ビデオストリームのＧＯＰを構成するピクチャの構造が、ストリームの途中で変化しても、ＴｉｍｅＯｆｆｓｅｔやＰＴＳ Ｄｉｆｆｅｒｅｎｃｅの生成方法には影響しない。例えば、1個のＧＯＰを構成するピクチャ構造が、ストリームの途中において、（記録順で）ＩＢＢＰＢＢからＩＰＢＢへ、もしくはＩＰＩＰへ変化したとしても、管理データの生成手順には影響しない。これによりストリームのＧＯＰ構造は自由に変更できることになるので、シーンチェンジの検出直後にＩＰＢＢのＧＯＰ構造を一時的にとることができ、画質の向上を図ることができる。

以上の様に、ＴｉｍｅＯｆｆｓｅｔの値は設定容易なので、ＭＰＥＧエンコーダの外部回路で検出可能なので、ＫＰＵ毎にＫＰＵ ＰｅｒｉｏｄをＭＰＥＧエンコーダの外部に送出する必要が無くなり、ＭＰＥＧエンコーダＬＳＩのＡＰＩ（アプリケーションインタフェース）を軽くすることができる。また同時に、汎用のＭＰＥＧエンコーダＬＳＩを使用可能になる。

実施の形態３におけるＡＶデータ記録再生装置の基本的な構成は、図２と同様であるが、各部の動作は実施の形態２とほぼ同様であるが、以下で説明する様な異なる動作を含む。

カムコーダ１００は、ＣＣＤ２０１aが出力する毎秒２４フレームの映像をＭＰＥＧ−２エンコーダ２０３で毎秒６０フレームのＭＰＥＧ−２トランスポートストリームを生成し、ショットとしてリムーバブルＨＤＤへ記録する。この時、ＭＰＥＧ−２エンコーダ２０３は、ピクチャ層のユーザデータ内に毎秒２４フレーム毎にカウントアップするタイムコードを格納する。また、ＭＰＥＧ−２エンコーダは、３：２プルダウン記録するために、一枚のピクチャを１／６０回の周期で数えて３周期分、もしくは２周期分だけ交互に表示するようにＭＰＥＧ−２ビデオストリームを生成する。３周期分、もしくは２周期分表示するための指示は、ＭＰＥＧ規格に従ってピクチャヘッダ内に格納する。具体的にはｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄとｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔの値が両方共に１の場合は、３周期分を意味し、それぞれの値が１と０の場合は２周期分を意味する。

再生時はリムーバブルＨＤＤに記録されたクリップＡＶストリームを読出し、ＭＰＥＧ−２デコーダ２０６で復号を行う。このとき、ピクチャ層のユーザデータ内に記録された毎秒２４フレームでカウントするタイムコードを読出し、その値を映像上にオーバーレイ表示する。

編集時において、ユーザは映像上にオーバーレイ表示されたタイムコード値を見て、ＩＮ点、ＯＵＴ点、もしくは注目点として取り扱いたい映像のタイムコード値を確認可能である。また、カムコーダはその映像のタイムコード値を取得し、その取得したタイムコード値を、たとえばプレイリスト内でＩＮ点、ＯＵＴ点の値として設定する。

この様なプレイリストを再生する場合、毎秒２４フレーム毎にカウントされるタイムコード値から、図３０に示す手順により、対応するピクチャの記録アドレスへの変換処理が実施される。すなわち、タイムコード値を入力すると（Ｓ４１０）、まずその入力したタイムコード値と開始タイムコード値（４００ｏ）との差分に、再生しない区間長（４００ｒ）を加算した値を、差分タイムコード値として算出する（Ｓ４１１）。次にその差分タイムコード値を使って、対応するＳＴＣ値である目標ＳＴＣ値を算出する。ここで先頭３フレームフラグの値が１の場合の計算式をＳ４１２に示す。Ｓ４１２のＣｅｉｌ（ｘ）関数（ここでｘは実数）は、値ｘ以上で、かつ最もｘに近い整数値を関数値とする。ここで差分タイムコード値を５／２倍しているのは、毎秒３：２プルダウンしたＭＰＥＧストリームとして記録しているためである。

なお、先頭３フレームフラグの値が０の場合は、目標ＳＴＣ値は次式より求まる。

（数８）
目標ＳＴＣ値＝ＳｔａｒｔＳＴＣ（３９５ｆ）
−ＴｉｍｅＯｆｆｓｅｔ（３９５ｉ）×（２７，０００，０００／６０）
＋ｆｌｏｏｒ（差分タイムコード×（５／２）×（２７，０００，０００／６０））
ここで、ｆｌｏｏｒ（ｘ）関数（ここでｘは実数）は、値ｘ以下で、かつ最もｘに近い整数値を関数値の値とする。

次に各ＫＰＵＥｎｔｒｙ（３９５ｈ）のＰＴＳ Ｄｉｆｆｒｅｎｃｅ（３９８ｃ）を、ＫＰＵ＃０のＫＰＵＥｎｔｒｙから順に加算し、
（数９）
目標ＳＴＣ値≦ＳｔａｒｔＫｅｙＳＴＣ値（３９５ｆ）
＋ΣＰＴＳ Ｄｉｆｆｅｒｅｎｃｅ
となる初めてのＫＰＵ番号（その番号をｋとする）を導出する（Ｓ４１３）。ここで、指定されたタイムコード値に対応するピクチャのアドレスは、ＫＰＵ＃ｋに含まれることになる。次にこのＫＰＵ＃ｋの格納先アドレスを次式より求める（Ｓ４１４）。

（数１０）
ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔ（３９５ｄ）＋ΣＫＰＵＳｉｚｅ
ただし、ΣＫＰＵＳｉｚｅはＫＰＵ＃０から、ＫＰＵ＃ｋまで
さらに、ＫＰＵ＃ｋの先頭ピクチャ（ただし表示順）と、タイムコード値に対応するピクチャとの間の差分ＳＴＣを次式より求める（Ｓ４１５）。

（数１１）
差分ＳＴＣ＝
目標ＳＴＣ値−（ＳｔａｒｔＫｅｙＳＴＣ値＋ΣＫＰＵ Ｄｉｆｆｅｒｅｎｃｅ）
差分ＳＴＣ＞０の場合には、この時間差分だけ表示スキップする必要がある。

以上の様に、ユーザは毎秒２４フレーム中の１画像をＩＮ点、ＯＵＴ点、もしくはチャプターの分割点として直接指定して、そのフレームのタイムコードを使ってプレイリストを使った仮想編集や、クリップＡＶストリームの分割等の実体編集を実施できる。また、毎秒２４フレーム中のタイムコードを使ってプレイリストを使った再生も実施できる。これにより、編集作業を効率的に進めることができる。

また、これらのタイムコードを使った指定を実現するためのクリップメタデータファイルおよびＣｌｉｐＴｉｍｅｌｉｎｅファイルの生成が、ＭＰＥＧエンコーダからＧＯＰを構成するピクチャ構成についてＧＯＰ毎に通知を受けなくとも容易に実現できる。

言い換えれば、クリップＡＶストリームのＧＯＰを構成するピクチャ構成が変化する場合であっても、これらのタイムコードを使った指定を実現するためのクリップメタデータファイルおよびＣｌｉｐＴｉｍｅｌｉｎｅファイルの生成が、容易に実現できる。

また、ＰＴＳ Ｄｉｆｆｅｒｅｎｃｅ（３９８ｃ）の他にＴｉｍｅＯｆｆｓｅｔ（３９５ｉ）が管理されているので、ユーザは１ショット内に、記録されているフレームの正確な数を把握可能となる。このことは、フレーム精度の編集を可能とする。

なお、実施の形態３においてショットの前方削除を実施する場合は、実施の形態１と同様の処理が必要となることに加えて、開始タイムコード（３００ｏ）、および再生しない区間長（３００ｒ）、ＴｉｍｅＯｆｆｓｅｔ（２９５ｉ）の変更が必要となることは言うまでも無い。

なお、本発明の実施の形態２および３では、毎秒２４フレームの例を使ったが、毎秒２３．９７フレーム（１００１／２４０００フレーム）であっても良い。また、毎秒６０フレームのＭＰＥＧ−２ストリームの例を使ったが、毎秒５９．９４フレーム（１００１／６００００フレーム）であっても良い。また、毎秒６０フレームのＭＰＥＧ−２ストリーム内に毎秒２４フレームの映像を３：２プルダウン記録する場合を例としたが、毎秒６０フレームのＭＰＥＧ−２ストリーム内に毎秒３０フレームの映像を２：２プルダウン記録する場合であっても良い。また、毎秒６０フレームのＭＰＥＧ−２ストリーム内に毎秒６０フレームの映像を普通に記録する場合であっても良い。

なお、本発明の実施の形態２、および３では、毎秒６０フレームのＭＰＥＧ−２ビデオストリームに毎秒２４フレームの映像を３：２プルダウンする例を示したが、毎秒６０フィールド（もしくは５９．９４フィールド）のＭＰＥＧ−２ビデオストリームに毎秒２４フレームの映像を３：２プルダウンする場合であっても良い。ただし、この場合、先頭３フレームフラグ（３００ｓ、４００ｓ）の代わりに、開始タイムコード（３００ｏ、４００ｏ）で参照されるピクチャが、６０フィールド中の３フィールドに対応する場合に値が１であり、２フィールドに対応する場合に値が０となる様な仕様の管理データを設ける必要がある。この管理データは先頭３フィールドフラグと呼ぶことができる。

なお、本発明の実施の形態２、および３では、毎秒６０フレームのＭＰＥＧ−２ビデオストリームに毎秒２４フレームの映像を３：２プルダウンする例を示したが、毎秒５０フィールドのＭＰＥＧ−２ビデオストリームに毎秒２４フレームの映像を１フレーム対１フレームの比率で符号化する場合であっても良い。

なお、本発明の実施の形態２、および３では、先頭３フレームフラグを記録するものとしたが、あらかじめ開始タイムコード（３００ｏ、４００ｏ）で参照されるピクチャを３フレームに対応させるか、２フレームに対応させるか決めておいても良い。ただしこの場合、ＭＰＥＧストリームの編集後において、常に３フレームに対応するように注意が必要になる。

なお、本発明の実施の形態２、および３では先頭３フレームフラグは、開始タイムコードで参照されるピクチャに関する情報であるものとしたが、再生しない区間長（３００ｒ、４００ｒ）分スキップした、再生を開始すべきピクチャに関する情報であっても良い。さらに、その再生開始ピクチャの再生開始時刻（単位はＰＴＭ）、および２４フレームでカウントするタイムコードを管理データとして保持しても良い。この場合、その再生開始ピクチャの再生開始時刻およびそのタイムコードを基準として、タイムコード値から対応するピクチャの記録アドレスへ変換可能となる。

なお、本発明の実施の形態２、および３では、クリップＡＶストリームの先頭ＫＰＵは毎秒６０フレーム中の３フレーム分に対応するフレームから始まり、次に２フレーム分に対応するフレームが続くものとした。しかし、逆に毎秒６０フレーム中の２フレーム分に対応するフレームから始まり、次に３フレーム分に対応するフレームが続いても良い。

なお、本発明の実施の形態２、および３では、先頭３フレームフラグを記録し、さらに参照するものとしたが、例えば、クリップＡＶストリームの先頭ＫＰＵのピクチャのｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔフラグを解析し、その値が１であれば、先頭３フレームフラグ＝１と同等の処理を実施し、その値が０であれば、先頭フレームフラグ＝０と同等の処理を実施するものとしても良い。３：２プルダウンで記録される場合、ピクチャヘッダ内のｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ＝１のピクチャは、そのピクチャが３フレーム周期分表示され、ｔｏｐ＿ｆｉｅｌｄ＿ｆｉｒｓｔ＝０のピクチャは２フレーム周期分表示されるからである。ただし、この場合、ピクチャのデータ解析が必要となることは言うまでもない。

また、毎秒６０フィールドのＭＰＥＧ−２ビデオストリームに毎秒２４フレームの映像を３：２プルダウンする場合も同様に、例えば、クリップＡＶストリームの先頭ＫＰＵのピクチャのｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄフラグを解析し、その値が１であれば、先頭３フィールドフラグ＝１と同等の処理を実施し、その値が０であれば、先頭フィールドフラグ＝０と同等の処理を実施するものとしても良い。３：２プルダウンで記録される場合、ピクチャヘッダ内のｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ＝１のピクチャは、そのピクチャが３フィールド周期分表示され、ｒｅｐｅａｔ＿ｆｉｒｓｔ＿ｆｉｅｌｄ＝０のピクチャは２フィールド周期分表示されるからである。ただし、この場合も、ピクチャのデータ解析が必要となることは言うまでもない。

なお、本発明の実施の形態２および３では、再生時間長（３００ｂ、および４００ｂ）をＥｄｉｔＵｎｉｔ単位で指定したが、ＡＵＴＭ単位であっても良いことは言うまでも無い。両者は変換可能だからである。このことは再生しない区間長（３００ｒ、および４００ｒ）も同様である。

なお、本発明の実施の形態２および３では、クリップＡＶストリーム中のＭＰＥＧ−２トランスポートストリームは連続しているものとした。つまり、ＰＴＳ、ＤＴＳ、ＰＣＲは連続したＳＴＣに基づいて付与されているものとした。また、毎秒２４フレームのタイムコードも連続して付与されているものとした。

なお、本発明の実施の形態２、および３では、ドロップフレームフラグがオフであるものとしたが、オンの設定となっていても良い。オンとなっている場合でも、カウント値をスキップするルールは決まっているので、オフの時とオンの時の間で変換は一意に可能だからである。

なお、本発明の実施の形態２、および３では、毎秒２４フレームのタイムコードは００：００：００：００から開始される例を示したが、撮影開始時刻（時：分：秒：フレーム数）からスタートしても良いし、また、ＨＤＤ上で通し番号となる様な値からスタートしても良い。これらのタイムコードの初期値をユーザがカスタマイズする機能は、業務用カムコーダでは一般的である。

なお、本発明の実施の形態２、および３では、ＭＰＥＧ−２ビデオストリームは、ＫＰＵの先頭でＩピクチャよりも２枚のＢピクチャが先に再生される例を用いたが、ＫＰＵの先頭でＩピクチャの方が先に再生される様に符号化しても良いのは言うまでも無い。

以上、本発明の実施の形態を説明した。

本実施の形態では、データストリーム等を格納するメディアはリムーバブルＨＤＤであるとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば、非可換メディア、例えばデータ処理装置に内蔵されたＨＤＤであってもよい。

実施の形態１では、タイムマップ（ＣｌｉｐＴｉｍｅＬｉｎｅ）のデータ構造は、ＴｉｍｅＥｎｔｒｙおよびＫＰＵＥｎｔｒｙの２層を含むとした。しかし、再生時間と記録アドレスの変換が可能であればこれに限る必要は一切なく、ＫＰＵＥｎｔｒｙの１層のみからなるタイムマップであっても全く同様である。上述の説明では、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドを設け、その値に基づいてキーピクチャユニットＫＰＵが複数のファイルを跨っていることを示すとして説明した。しかし、複数のファイルを跨っているか否かは、タイムマップに相当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデータ（リレーション情報など）、クリップのファイル名の命名規則（ファイル名の番号が昇順など）、同一フォルダ内に１ショットの全データ（少なくとも１ショットを構成する全ＴＴＳファイルの内、同一記録媒体上に記録されたもの）を格納する等によって、ＫＰＵが跨っている、または、跨っている可能性があることを示してもよい。

なお、図２等の各機能ブロックは典型的には集積回路（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ；ＬＳＩ）のチップとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。例えば、図２においては、ＣＰＵ２１１を含むシステム制御部２５０とメディア制御部２０５とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、システム制御部２５０にメディア制御部２０５の機能を与え、物理的に同一のチップによって実現してもよい。また、メディア制御部２０５およびＴＳ処理部２０４の機能を集積化して、１つのチップ回路として実現してもよいし、さらにエンコーダ２０３およびデコーダ２０６の機能を付加したチップ回路２１７として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外することにより、複数の符合化方式に容易に対応できる。

システム制御部２５０は、プログラムＲＯＭ２１０等に格納されたコンピュータプログラムを実行することにより、本明細書に記載したメディア制御部２０５の機能を実現することができる。このときは、メディア制御部２０５はシステム制御部２５０の一部の機能として実現される。

なお、上述の「ＬＳＩ」は、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。

なお、各実施の形態において、記憶媒体はリムーバブルＨＤＤであるものとしたが、特にこれに限定するものではなく、例えばＤＶＤ−ＲＡＭ、ＭＯ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＣＤ−Ｒ、ＣＤ−ＲＷ等の光ディスクやハードディスク等のディスク形状を有する記録媒体であれば何でも良い。また、フラッシュメモリ、ＦｅＲＡＭ、ＭＲＡＭ等の半導体メモリであっても良い。

また、各実施の形態において、クリップＡＶストリームはトランスポートストリームを含むものとしてが、プログラムストリームやＰＥＳストリーム等の他のマルチメディア情報を含むビットストリームであっても良い。

なお、各実施の形態において、映像はＭＰＥＧ−２ビデオストリームを例としたが、ＭＰＥＧ−４ビデオストリームやＭＰＥＧ−４ＡＶＣストリーム（Ｈ．２６４ストリーム）であっても良い。また、音声もリニアＰＣＭオーディオストリームやＡＣ−３ストリーム等であっても良い。

本発明のＡＶデータ記録装置及び方法、ＡＶデータ再生装置及び方法、当該ＡＶデータ記録装置又は方法で記録された記録媒体によれば、毎秒２４フレームの映像の内、映像編集時にＩＮ点／ＯＵＴ点を決める際に、ユーザがＩＮ／ＯＵＴ点を簡易に指定できる。また、このことを実現するために、動画の符号化の際にＭＰＥＧエンコーダとの間で通信量を増やす事無く実現可能であり、特別なＭＰＥＧエンコーダを使用する必要が無い。従って、２４フレーム／秒のＡＶデータを扱う種々の機器、装置等において有用である。

リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図 カムコーダ１００の機能ブロックの示す図 トランスポートストリーム（ＴＳ）２０のデータ構造を示す図 （ａ）はビデオＴＳパケット３０のデータ構造を示す図、（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す図 （ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図 クリップＡＶストリーム６０のデータ構造を示す図 ＴＳ処理部２０４の機能ブロックの構成を示す図 （ａ）は本実施形態における１コンテンツの概念を示す図、（ｂ）はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図、（ｃ）は３つのリムーバブルＨＤＤ１１２を示す図 リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す図 クリップメタデータ９４に含まれる情報の内容を示す図 キーピクチャおよびキーピクチャユニットの関係を示す図 （ａ）は、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す図、（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示示す図、（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す図 （ａ）は、タイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図、（ｂ）はＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図 ２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す図 カムコーダ１００によるコンテンツの録画処理の手順を示す図 メディア切り替え処理の手順を示す図 カムコーダ１００によるコンテンツの再生処理の手順を示す図 （ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す図 カムコーダ１００によるコンテンツの部分削除処理の手順を示す図 実施の形態２において３：２プルダウンする場合のデータ構造を示す図 実施の形態２においてクリップメタデータファイルが含むデータ構造を示す図 実施の形態２におけるＣｌｉｐＴｉｍｅＬｉｎｅファイルのデータ構造を示す図 実施の形態２におけるタイムコード値からそのタイムコード値に対応するピクチャの格納先アドレスを算出する際の変換手順を示す図 実施の形態２における１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図 実施の形態２におけるＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔが零でなく、１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図 実施の形態２における１ショットが複数のＴＴＳファイルのチェーンで構成される場合の管理パラメータを示す図 実施の形態３における毎秒２４フレームの映像を３：２プルダウン記録する場合のデータ構造を示す図 実施の形態３におけるクリップメタデータファイルのデータ構造を示す図 実施の形態３におけるＣｌｉｐＴｉｍｅＬｉｎｅファイルのデータ構造を示す図 実施の形態３におけるタイムコード値からそのタイムコード値に対応するピクチャの格納先アドレスを算出する際の変換手順を示す図 実施の形態３における１ショットが１個のＴＴＳファイルで構成される場合の管理パラメータを示す図 実施の形態３におけるＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔが零でなく、かつ１ショットが３個のＴＴＳファイルで構成される場合の管理パラメータを示す図 従来の毎秒２４フレームの映像を３：２プルダウン記録する場合のデータ構造を示す図

符号の説明

１００ カムコーダ
１０８ ＰＣ
１１２ リムーバブルＨＤＤ
２０１ａ ＣＣＤ
２０１ｂ マイク
２０２ ＡＤコンバータ
２０３ ＭＰＥＧ−２エンコーダ
２０４ ＴＳ処理部
２０５ メディア制御部
２０６ ＭＰＥＧ−２デコーダ
２０７ グラフィック制御部
２０８ メモリ
２０９ａ ＬＣＤ
２０９ｂ スピーカ
２１０ プログラムＲＯＭ
２１１ ＣＰＵ
２１２ ＲＡＭ
２１３ ＣＰＵバス
２１４ ネットワーク制御部
２１５ 指示受信部
２１６ インターフェース（Ｉ／Ｆ）部
２５０ システム制御部
２６１ ＴＴＳヘッダ付加部
２６２ クロックカウンタ
２６３ ＰＬＬ回路
２６４ バッファ
２６５ ＴＴＳヘッダ除去部

Claims (28)

1. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録装置であって、
   前記管理情報は、前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、前記所定のピクチャに対応したタイムコード値を有し、
   前記タイムコード値は、前記オブジェクト内の各ピクチャに一意に対応し、前記各ピクチャの再生間隔と前記タイムコードが示す再生間隔は異なることを特徴とするＡＶデータ記録装置。
2. 前記再生時刻情報は、それぞれの前記オブジェクト中で最初に記録されたピクチャの再生時刻情報を含むことを特徴とする請求項１記載のＡＶデータ記録装置。
3. 前記再生時刻情報は、それぞれの前記オブジェクト中の最初のピクチャ内符号化が施されたピクチャデータ（イントラピクチャデータ）の再生時刻情報であることを特徴とする請求項１記載のＡＶデータ記録装置。
4. 前記最初のイントラピクチャデータの再生時刻情報は、隣接する２つのオブジェクトにおいて前記最初のイントラピクチャデータの再生時刻の時間間隔に相当する情報を含むことを特徴とする請求項３記載のＡＶデータ記録装置。
5. 前記管理情報は、さらに、先頭の前記オブジェクト中の最初のイントラピクチャよりも時間的に早く再生されるピクチャ数を有する請求項４記載のＡＶデータ記録装置。
6. 前記再生時刻情報は、前記オブジェクトの再生時間長であることを特徴とする請求項２記載のＡＶデータ記録装置。
7. 前記１つ以上のオブジェクトは、複数のＡＶファイルから構成されるＡＶファイルチェーンに順番に詰めて格納されることを特徴とする請求項１記載のＡＶデータ記録装置。
8. 前記管理情報は、前記複数のＡＶファイルにそれぞれ一意に対応する複数の管理ファイルに格納される請求項１記載のＡＶデータ記録装置。
9. 前記オブジェクトは前記タイムコード値を含む請求項１記載のＡＶデータ記録装置。
10. 前記タイムコードは各ピクチャ毎に含まれている請求項１記載のＡＶデータ記録装置。
11. 前記ピクチャの再生間隔と、前記タイムコードが示す再生間隔は周期性を持った所定の関係にあり、さらに前記周期の開始タイミングに関する補助情報を記録する請求項１記載のＡＶデータ記録装置。
12. 前記ピクチャの再生間隔と、前記タイムコードが示す再生時刻は３：２プルダウンの関係にあり、前記補助情報は前記タイムコードが示す再生時刻に対応するピクチャが３フレームに対応するのか、２フレームに対応するのかを示す請求項１記載のＡＶデータ記録装置。
13. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録装置であって、
    前記映像データは、ピクチャ内符号化が施されたピクチャデータ（イントラピクチャデータ）とピクチャ間符号化が施されたピクチャデータとを有し、
    前記管理情報は、前記オブジェクト中の最初のイントラピクチャデータの再生時刻と、前記イントラピクチャデータの記録位置とを対応付けるマップ情報を有し、
    さらに、先頭の前記オブジェクト中の前記最初のイントラピクチャよりも先に再生されるピクチャの再生時間長に関する情報を有することを特徴とするＡＶデータ記録装置。
14. 前記１つ以上のオブジェクトは、複数のＡＶファイルから構成されるＡＶファイルチェーンに順番に詰めて格納されることを特徴とする請求項１３記載のＡＶデータ記録装置。
15. 前記管理情報は、前記複数のＡＶファイルにそれぞれ一意に対応する複数の管理ファイルに格納される請求項１３記載のＡＶデータ記録装置。
16. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録する記録部と、
    ユーザから指定された与えられたタイムコード値を受け取り、前記タイムコード値に対応する映像データより時間的に前方部分を削除する削除部を有するＡＶデータ記録装置であって、
    前記管理情報は、前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、前記所定のピクチャに対応したタイムコード値を有し、
    前記タイムコード値は、前記オブジェクト内の各ピクチャに一意に対応し、また前記タイムコードの再生間隔は前記各ピクチャの再生間隔と異なっており、
    前記削除部は、ユーザから与えられたタイムコード値を受け取り、前記タイムコード値に対応するピクチャの前記再生時刻情報を算出し、さらに前記前方部分に関連する前記タイムマップおよび前記所定のピクチャに対応したタイムコード値を変更することを特徴とするＡＶデータ記録装置。
17. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを読み出す読出し部と、
    与えられたタイムコード値を受け取り、前記タイムコード値に対応する映像データを再生する再生部を有するＡＶデータ再生装置であって、
    前記管理情報は、前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、前記所定のピクチャに対応したタイムコード値を有し、
    前記タイムコード値は前記オブジェクト内の各ピクチャに一意に対応し、また前記タイムコードの再生間隔は前記各ピクチャの再生間隔と異なっており、
    前記再生部は前記与えられたタイムコード値を受け取り、前記与えられたタイムコード値に対応するピクチャの再生時刻情報を算出し、さらに前記タイムマップを参照して前記記録位置を特定することを特徴とするＡＶデータ再生装置。
18. 前記ピクチャの再生間隔と、前記タイムコードが示す再生間隔は周期性を持った所定の関係にあり、
    前記管理情報はさらに前記周期の開始タイミングに関する補助情報を記録し、
    前記再生部は、前記記録位置を特定する際に前記補助情報をさらに参照することを特徴とする請求項１７記載のＡＶデータ再生装置。
19. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録方法であって、
    前記管理情報として前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップを生成するステップと、
    前記管理情報として前記所定のピクチャに対応したタイムコード値を生成するステップを有し、
    前記タイムコード値は、前記オブジェクト内の各ピクチャに一意に対応し、前記各ピクチャの再生間隔と前記タイムコードが示す再生間隔は異なることを特徴とするＡＶデータ記録方法。
20. 前記ピクチャの再生間隔と、前記タイムコードが示す再生間隔は周期性を持った所定の関係にあり、
    さらに前記周期の開始タイミングに関する補助情報を記録する記録ステップを有する請求項１９記載のＡＶデータ記録方法。
21. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するＡＶデータ記録方法であって、
    前記映像データとしてピクチャ内符号化が施されたピクチャデータ（イントラピクチャデータ）とピクチャ間符号化が施されたピクチャデータとを生成するステップと、
    前記管理情報として、前記オブジェクト中の最初のイントラピクチャデータの再生時刻と、前記イントラピクチャデータの記録位置とを対応付けるマップ情報を生成するステップを有し、
    さらに、先頭の前記オブジェクト中の前記最初のイントラピクチャよりも先に再生されるピクチャの再生時間長に関する情報を生成するステップを有することを特徴とするＡＶデータ記録方法。
22. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを記録するステップと、
    ユーザから指定された与えられたタイムコード値を受け取り、前記タイムコード値に対応する映像データより時間的に前方部分を削除するステップを有するＡＶデータ記録方法であって、
    前記管理情報として前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、
    前記所定のピクチャに対応したタイムコード値を生成するステップを有し、
    前記タイムコード値は前記オブジェクト内の各ピクチャに一意に対応し、また前記タイムコードの再生間隔は前記各ピクチャの再生間隔と異なっており、
    前記削除するステップはユーザから与えられたタイムコード値を受け取り、前記タイムコード値に対応するピクチャの前記再生時刻情報を算出し、さらに前記前方部分に関連する前記タイムマップおよび前記所定のピクチャに対応したタイムコード値を変更することを特徴とするＡＶデータ記録方法。
23. 符号化された映像データと符号化された音声データとが多重化される１つ以上のオブジェクトと、１つ以上の前記オブジェクトを管理する管理情報とを読み出すステップと、
    与えられたタイムコード値を受け取り、前記タイムコード値に対応する映像データを再生するステップを有するＡＶデータ再生方法であって、
    前記管理情報は前記オブジェクト内の所定のピクチャの再生時刻情報と、前記所定のピクチャの記録位置とを対応付けるタイムマップと、
    前記所定のピクチャに対応したタイムコード値を有し、
    前記タイムコード値は前記オブジェクト内の各ピクチャに一意に対応し、また前記タイムコードの再生間隔は前記各ピクチャの再生間隔と異なっており、
    前記再生するステップは前記与えられたタイムコード値を受け取り、前記与えられたタイムコード値に対応するピクチャの再生時刻情報を算出し、さらに前記タイムマップを参照して前記記録位置を特定することを特徴とするＡＶデータ再生方法。
24. 前記ピクチャの再生間隔と、前記タイムコードが示す再生間隔は周期性を持った所定の関係にあり、
    前記管理情報はさらに前記周期の開始タイミングに関する補助情報を有し、
    前記再生するステップは、前記記録位置を特定する際に前記補助情報をさらに参照することを特徴とする請求項２３記載のＡＶデータ再生方法。
25. 請求項１から１６のいずれかに記載のＡＶデータ記録装置により記録された記録媒体。
26. 請求項１９から２２のいずれかに記載のＡＶデータ記録方法により記録された記録媒体。
27. 請求項１９から２２のいずれかに記載のＡＶデータ記録方法により記録するプログラムを格納する記録媒体。
28. 請求項１９から２２のいずれかに記載のＡＶデータ記録方法により記録するチップ回路。

Images