JPWO2006033275A1 - データ処理装置 - Google Patents

データ処理装置 Download PDF

Info

Publication number
JPWO2006033275A1
JPWO2006033275A1 JP2006536355A JP2006536355A JPWO2006033275A1 JP WO2006033275 A1 JPWO2006033275 A1 JP WO2006033275A1 JP 2006536355 A JP2006536355 A JP 2006536355A JP 2006536355 A JP2006536355 A JP 2006536355A JP WO2006033275 A1 JPWO2006033275 A1 JP WO2006033275A1
Authority
JP
Japan
Prior art keywords
data
kpu
time
clip
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2006536355A
Other languages
English (en)
Other versions
JP4791969B2 (ja
Inventor
洋 矢羽田
洋 矢羽田
岡田　智之
智之 岡田
伊藤　正紀
正紀 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2006536355A priority Critical patent/JP4791969B2/ja
Publication of JPWO2006033275A1 publication Critical patent/JPWO2006033275A1/ja
Application granted granted Critical
Publication of JP4791969B2 publication Critical patent/JP4791969B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/322—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier used signal is digitally coded
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2508—Magnetic discs
    • G11B2220/2516—Hard disks
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/40—Combinations of multiple record carriers
    • G11B2220/41—Flat as opposed to hierarchical combination, e.g. library of tapes or discs, CD changer, or groups of record carriers that together store one title
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/40—Combinations of multiple record carriers
    • G11B2220/41—Flat as opposed to hierarchical combination, e.g. library of tapes or discs, CD changer, or groups of record carriers that together store one title
    • G11B2220/412—Distributed storage methods, i.e. the system may autonomously determine for a storage device that provides enough storage capacity for recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H04N5/77—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television camera
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/78—Television signal recording using magnetic recording
    • H04N5/781—Television signal recording using magnetic recording on disks or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor

Abstract

コンテンツのデータストリームを高速に編集する手段を提供する。 本発明によるデータ処理装置は、メディアに書き込まれたコンテンツを編集することができる。このコンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また、メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。データ処理装置は、ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、ファイルの先頭から、部分削除の範囲内であって、かつクラスタサイズおよびパケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部とを備えている。

Description

本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコンテンツの再生および編集を容易にする技術に関する。
近年、ＤＶＤ等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器（光ディスクレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。
近年はＰＣにもコンテンツの記録、再生および編集機能が実装されており、ＰＣも上述のデジタル機器に含めることができる。ＰＣでは、文書データ等を記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、ＰＣと連携可能なデータ管理構造、例えばＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）を用いたファイルシステムが採用されている。現在多く利用されているＦＡＴ３２ファイルシステムでは、最大４ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が２テラバイトのメディアを管理することができる。
メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。例えば特許文献１では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるＡＶデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。
特開平１１−１５５１３０号公報
コンテンツの再生時間が長くなり、コンテンツの一部を削除する編集処理が頻繁に行われるようになると、従来の処理では編集処理時間が長くなるという問題が生じる。例えば、データストリームの内容を解析し、削除範囲内のピクチャのデータ位置等を特定した後にそのデータを削除すると、解析時間、データ位置の特定時間および削除時間がそれぞれ必要になる。
この問題は、トランスポートストリーム等を構成する固定長のデータパケットに、ＭＰＥＧ規格等による順方向符号化方式および双方向符号化方式で圧縮符号化された映像データを格納しているときに顕著である。例えば、ＭＰＥＧ規格の一連の映像データの一部を削除するとき、まず、編集装置は削除の開始ピクチャおよび終了ピクチャを特定するために、メディアからパケットを読み出してパケット内のデータを解析しなければならない。パケットデータの読み出しは、例えばファイルシステムのクラスタ単位で行われるため、一般には、必要とするパケット以外の不要なパケットも同時に読み出される。よって不要なアクセス時間がかかる。さらに、ピクチャを特定して削除しても、削除直後の開始ピクチャをいわゆるＩピクチャに設定しなければならないため、そのピクチャデータの読み出し、デコードおよび再エンコードが必要になる。
本発明の目的は、コンテンツのデータストリームを高速に編集する手段を提供することである。
本発明によるデータ処理装置は、メディアに書き込まれたコンテンツを編集することができる。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部とを備えている。
前記データストリームは、複数のピクチャから構成され、かつ、基準ピクチャからのデコードを要する復号化単位を１つまたは複数含む再生単位を含んでいる。前記メディア制御部は、データを削除した後のファイル内のデータストリームにおいて初めて現れる再生単位までのデータ量の値を前記メディアに書き込んでもよい。
前記メディアには、データを削除する前のデータストリームに対して、前記コンテンツの一定の再生時間ごとに再生されるピクチャのデータ位置を特定するタイムエントリが予め書き込まれている。前記メディア制御部は、データを削除した後のデータストリームに関し、初めて現れる前記再生単位の先頭から、前記タイムエントリによって特定される初めてのピクチャのデータ位置までのデータ量の値を前記メディアに書き込んでもよい。
前記データストリームは、各々のパケットサイズが１９２バイトである複数のパケットから構成され、前記メディアには３２キロバイトのクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記メディア制御部は、９６キロバイトの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記ファイルの末尾を含む部分削除の範囲の指定を受け取るときには、前記ファイルの末尾から、前記部分削除の範囲内であって、かつ前記パケットサイズの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記部分削除の範囲内であって、前記データストリームの不完全な再生単位のデータを削除してもよい。
本発明によるチップ回路は、メディアに書き込まれたコンテンツを編集する処理を行うためにデータ処理装置に実装される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部を備えている。前記チップ回路は、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを特定する処理と、特定された前記データを削除する指示を出力する処理とを実行する。
本発明によるコンピュータプログラムは、メディアに書き込まれたコンテンツを編集する処理を行うためのデータ処理装置において実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記コンピュータプログラムを実行した前記データ処理装置は、前記ファイルの先頭を含む範囲の指定を受け取るステップと、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを実行する。
本発明によるデータ処理方法は、メディアに書き込まれたコンテンツを編集するために実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理方法は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取るステップと、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを包含する。
本発明によれば、メディア上のデータストリームの一部のデータを削除する際に、ファイルシステムのクラスタサイズとデータストリームのパケットサイズとの最小公倍数を基準として、その整数倍のデータ量のデータを削除する。クラスタサイズの整数倍とすることによってメディアに対するデータ削除処理がアクセス単位で実行でき、またパケットのパケットサイズの整数倍とすることによってデータ削除処理がパケット単位で実行できるため、処理を高速化できる。
また、データストリーム中に格納されていた再生単位のうち、データを削除した後のデータストリームにおいて初めて現れる再生単位までのデータ量の値を保持するため、削除処理において削除直後のピクチャをＩピクチャに変更する必要はない。よってＩピクチャへの変更に必要な処理を排除でき、編集処理時間を短縮できる。
リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図である。 カムコーダ１００の機能ブロックの示す図である。 トランスポートストリーム（ＴＳ）２０のデータ構造を示す図である。 （ａ）はビデオＴＳパケット３０のデータ構造を示し、（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す図である。 （ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。 クリップＡＶストリーム６０のデータ構造を示す図である。 ＴＳ処理部２０４の機能ブロックの構成を示す図である。 （ａ）は本実施形態における１コンテンツの概念を示す図であり、（ｂ）はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、（ｃ）は３つのリムーバブルＨＤＤ１１２を示す図である。 リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す図である。 クリップメタデータ９４に含まれる情報の内容を示す図である。 キーピクチャおよびキーピクチャユニットの関係を示す図である。 （ａ）は、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す図であり、（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示す図であり、（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す図である。 （ａ）は、タイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図であり、（ｂ）はＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図である。 ２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す図である。 カムコーダ１００によるコンテンツの録画処理の手順を示す図である。 メディア切り替え処理の手順を示す図である。 カムコーダ１００によるコンテンツの再生処理の手順を示す図である。 （ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す図である。 カムコーダ１００によるコンテンツの部分削除処理の手順を示す図である。
符号の説明
１００ カムコーダ
１０８ ＰＣ
１１２ リムーバブルＨＤＤ
２０１ａ ＣＣＤ
２０１ｂ マイク
２０２ ＡＤコンバータ
２０３ ＭＰＥＧ−２エンコーダ
２０４ ＴＳ処理部
２０５ メディア制御部
２０６ ＭＰＥＧ−２デコーダ
２０７ グラフィック制御部
２０８ メモリ
２０９ａ ＬＣＤ
２０９ｂ スピーカ
２１０ プログラムＲＯＭ
２１１ ＣＰＵ
２１２ ＲＡＭ
２１３ ＣＰＵバス
２１４ ネットワーク制御部
２１５ 指示受信部
２１６ インターフェース（Ｉ／Ｆ）部
２５０ システム制御部
２６１ ＴＴＳヘッダ付加部
２６２ クロックカウンタ
２６３ ＰＬＬ回路
２６４ バッファ
２６５ ＴＴＳヘッダ除去部
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。
図１は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す。図１では、データ処理装置は、カムコーダ１００−１、カメラ付き携帯電話１００−２、ＰＣ１０８として記載されている。カムコーダ１００−１およびカメラ付き携帯電話１００−２は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして符号化し、そのデータストリームを、それぞれリムーバブルメディア１１２−１および１１２−２に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図１では、リムーバブルメディア１１２−２に複数のファイルが格納されていることが示されている。
各リムーバブルメディア１１２−１および１１２−２はデータ処理装置から取り外し可能であり、例えばＤＶＤ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）等の光ディスク、マイクロドライブ等の超小型ハードディスク、半導体メモリ等である。ＰＣ１０８は、各リムーバブルメディア１１２−１および１１２−２を装填することが可能なスロットを備えている。ＰＣ１０８は、装填されたリムーバブルメディア１１２−１、１１２−２からデータを読み出し、再生処理および編集処理等を実行する。
リムーバブルＨＤＤ１１２では、ＦＡＴ３２ファイルシステムによりデータ管理が行われる。ＦＡＴ３２ファイルシステムでは、１ファイルのファイルサイズの最大値は、例えば４ギガバイトである。よって、ＦＡＴ３２ファイルシステムではデータのサイズが４ギガバイトを超えるときは２以上のファイルに分けて書き込まれる。例えば、容量が８ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが２つ格納され得る。１６ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが４つ格納され得る。なお、分割して書き込まれる単位はファイルサイズの最大値でなくてもよく、ファイルサイズの最大値以下のサイズであればよい。
以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込むデータ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに格納されたデータストリームを再生し編集するデータ処理装置はＰＣであるとして説明する。
さらに、リムーバブルメディア１１２−１は超小型のリムーバブルハードディスクであるとする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆動してデータの書き込みおよび読み出しを行うための機構（ドライブ機構）を含む。以下では、リムーバブルメディア１１２−１を「リムーバブルＨＤＤ１１２」と記述する。説明を簡便化するため、リムーバブルＨＤＤ１１２は４ギガバイトの容量を持つとする。この結果、４ギガバイトを超えるコンテンツは、２以上のリムーバブルＨＤＤに分けて書き込まれる。しかしながら、リムーバブルＨＤＤが４ギガバイト以上の容量を持ち、そこに４ギガバイトを超えるコンテンツが書き込まれる場合にも、２以上のファイルに分割して同じリムーバブルＨＤＤに書き込めばよい。１つのコンテンツが複数のファイルに分けて記録される本質的な点においては、いずれも同じである。単に記録するメディアが同一であるか否かの違いにすぎない。リムーバブルＨＤＤ１１２のクラスタサイズは、例えば３２キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際の最小のアクセス単位である。
図２は、カムコーダ１００の機能ブロックの構成を示す。カムコーダ１００には、複数のリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃを同時に装填することが可能であり、ユーザが撮影した映像および音声に関するコンテンツのデータストリーム（クリップＡＶストリーム）を、リムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに順に書き込む。
カムコーダ１００は、ＣＣＤ２０１ａ、マイク２０１ｂおよびデジタル放送を受信するデジタルチューナ２０１ｃと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、メディア制御部２０５と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、液晶表示装置（ＬＣＤ）２０９ａおよびスピーカ２０９ｂと、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、システム制御部２５０とを含む。
以下、各構成要素の機能を説明する。ＣＣＤ２０１ａおよびマイク２０１ｂは、それぞれ映像および音声のアナログ信号を受け取る。ＣＣＤ２０１ａは、映像をデジタル信号として出力する。マイク２０１ｂは、音声のアナログ信号を出力する。ＡＤコンバータ２０２は入力されたアナログ音声信号をデジタル信号に変換してＭＰＥＧ−２エンコーダ２０３に供給する。
デジタルチューナ２０１ｃは、アンテナ（図示せず）から１以上の番組が含まれるデジタル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。デジタルチューナ２０１ｃは、受信したトランスポートストリームから特定の番組（録画対象のチャンネルの番組）のパケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームであるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼ぶこともある。トランスポートストリームのデータ構造は、図３〜図５を参照しながら後述する。
本実施形態においては、カムコーダ１００はデジタルチューナ２０１ｃを構成要素としているが、これは必須の要件ではない。図２のカムコーダ１００の構成は、図１において言及したカメラ付き携帯電話１００−２等にも適用できるため、デジタル放送の受信および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。
ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給された映像および音声の各デジタルデータをＭＰＥＧ規格に基づいて圧縮符号化する。本実施形態においては、エンコーダ２０３は、映像データをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリーム（以下「ＴＳ」とも記述する）を生成し、ＴＳ処理部２０４に送る。この処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。エンコーダ２０３は双方向圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。なお、映像および音声の符号化形式を一致させる必要はない。例えば、映像はＭＰＥＧ形式で圧縮符号化し、音声はＡＣ−３形式で圧縮符号化するとしてもよい。
本実施形態では、カムコーダ１００はＴＳを生成し処理する。そこでまず、図３〜図５を参照しながら、ＴＳのデータ構造を説明する。
図３は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮符号化されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、符号化されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。
以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図４（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、一般に４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図４（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、一般に４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。ＴＳパケットヘッダにはアダプテーションフィールドと呼ばれるデータを追加してもよく、ＴＳパケットに格納するデータをアライメントする場合などに利用される。この場合ＴＳパケットのペイロード（３０ｂ、３１ｂ）は１８４バイト未満となる。
上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは“０ｘ００２０”であり、オーディオＴＳパケットのＰＩＤは“０ｘ００２１”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図５（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図５（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。
ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図５（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。
ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図５（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
図５（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）などを表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、例えば“００１ｂ”などと決められている。
ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図５（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。
ＴＳに基づいて映像を再生する際、カムコーダ１００はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をＬＣＤ２０９ａ上に再生することができる。
上述のエンコーダ２０３は、映像コンテンツに関しては図５（ｄ）、（ｃ）、（ｂ）および（ａ）に示す順序でＴＳを生成するといえる。
次に、カムコーダ１００のＴＳ処理部２０４（図２）を説明する。ＴＳ処理部２０４は、動画の記録時にはエンコーダ２０３からＴＳを受け取り、またはデジタル放送番組の録画時にはデジタルチューナ２０１ｃからＴＳを受け取って、クリップＡＶストリームを生成する。クリップＡＶストリームとは、リムーバブルＨＤＤ１１２ａ等への格納のために所定の形式を有するデータストリームである。本明細書では、リムーバブルＨＤＤに格納されたクリップＡＶストリームのファイルには拡張子ＴＴＳ（“Ｔｉｍｅｄ ＴＳ”を意味する）を付している。クリップＡＶストリームは、到着時刻情報を付加したＴＳとして実現される。また、ＴＳ処理部２０４は、コンテンツの再生時には、リムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームをメディア制御部２０５から受け取り、そのクリップＡＶストリームに基づいてＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。
以下では図６を参照しながら、ＴＳ処理部２０４の処理に関連するクリップＡＶストリームを説明する。図６は、クリップＡＶストリーム６０のデータ構造を示す。クリップＡＶストリーム６０は、複数のＴＴＳパケット６１から構成される。ＴＴＳパケット６１は、４バイトのＴＴＳヘッダ６１ａと、１８８バイトのＴＳパケット６１ｂとから構成される。すなわちＴＴＳパケット６１は、ＴＴＳヘッダ６１ａをＴＳパケット６１ｂに付加して生成される。なおＴＳパケット６１ｂは、図３、図４（ａ）および（ｂ）等に関連して説明したＴＳパケットである。
ＴＴＳヘッダ６１ａは、２ビットの予約領域６１ａ−１と、３０ビットの到着時刻情報（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ；ＡＴＳ）６１ａ−２とから構成されている。この到着時刻情報６１ａ−２は、エンコーダ２０３から出力されたＴＳパケットがＴＳ処理部２０４に到着した時刻を示している。ＴＳ処理部２０４は、この時刻に基づいてデコーダ２０６にＴＳパケットを出力する。
次に、上述のクリップＡＶストリーム６０を生成するＴＳ処理部２０４の構成を説明する。図７は、ＴＳ処理部２０４の機能ブロックの構成を示す。ＴＳ処理部２０４は、ＴＴＳヘッダ付加部２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ＴＴＳヘッダ除去部２６５とを有する。
ＴＴＳヘッダ付加部２６１は、ＴＳを受け取り、そのＴＳを構成するＴＳパケットの前にＴＴＳヘッダを付加し、ＴＴＳパケットとして出力する。ＴＴＳヘッダ中の到着時刻情報６１ａ−２に記述されるＴＳパケットの到着時刻は、ＴＴＳヘッダ付加部２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。
クロックカウンタ２６２およびＰＬＬ回路２６３は、ＴＴＳヘッダ付加部２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、ＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がカムコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）として設定され、ＳＴＣが基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてＴＴＳヘッダ付加部２６１に出力する。
バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたＴＴＳパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、後述のメディア制御部２０５に出力する。このとき出力される一連のＴＴＳパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、メディア制御部２０５によってリムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ＴＴＳパケット単位で出力する。
ＴＴＳヘッダ除去部２６５は、ＴＴＳパケットを受け取って、ＴＴＳヘッダを除去することによりＴＴＳパケットをＴＳパケットに変換し、ＴＳとして出力する。留意すべきは、ＴＴＳヘッダ除去部２６５は、ＴＴＳヘッダに含まれているＴＳパケットの到着時刻情報ＡＴＳを抽出して、到着時刻情報ＡＴＳとクロックカウンタ２６２から与えられるタイミング情報とに基づいて、元の到着時刻に対応するタイミング（時間間隔）でＴＳパケットを出力することである。リムーバブルＨＤＤ１１２ａ等はランダムアクセスが可能であり、データは不連続にディスク上に配列される。よって、ＴＳパケットの到着時刻情報ＡＴＳを利用すれば、ＴＳ処理部２０４は、データの格納位置にかかわらず記録時のＴＳパケットの到着タイミングと同じタイミングでＴＳパケットを出力することができる。なおＴＴＳヘッダ除去部２６５は、読み出したＴＳの基準時刻を指定するために、例えば最初のＴＴＳパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
カムコーダ１００では、ＴＳ処理部２０４を設けて、ＴＳにＴＴＳヘッダを付加してクリップＡＶストリームを生成するとした。しかし、符号化レートが固定されているＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）で符号化する場合には、ＴＳパケットのデコーダ入力時刻が固定間隔であるため、ＴＳ処理部２０４を省略してＴＳをリムーバブルＨＤＤ１１２に書き込むこともできる。
再び図２を参照しながら、カムコーダ１００の各構成要素を説明する。
メディア制御部２０５は、ＴＳ処理部２０４からクリップＡＶストリームを受け取り、いずれかのリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに出力するかを決定して、そのリムーバブルＨＤＤに出力する。メディア制御部２０５は、書き込み中のリムーバブルＨＤＤの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときには出力先を他のリムーバブルＨＤＤに変更し、クリップＡＶストリームの出力を継続する。このとき、１つのコンテンツを構成するクリップＡＶストリームが２つのリムーバブルＨＤＤ１１２に跨って格納されることになる。
メディア制御部２０５は、本発明の主要な特徴の１つであるクリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）テーブルを生成する。そしてそのテーブルに、クリップＡＶストリームの再生単位であるキーピクチャユニットが、２つのファイルに跨って格納されているか否かを示すフラグを記述する。なお、メディア制御部２０５のより詳細な動作、および、メディア制御部２０５によって生成されるクリップタイムラインテープルの詳細なデータ構造は後述する。
なお、クリップＡＶストリームをリムーバブルＨＤＤ１１２に書き込む処理は、メディア制御部２０５から書き込み指示およびクリップＡＶストリームを受け取ったリムーバブルＨＤＤ１１２が行っている。また、クリップＡＶストリームを読み出す処理は、メディア制御部２０５から読み出し指示を受けたリムーバブルＨＤＤ１１２が行っている。しかし、説明の便宜のため、以下ではメディア制御部２０５がクリップＡＶストリームを書き込み、読み出すとして説明する。
ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたＴＳを解析して、ＴＳパケットから映像および音声の圧縮符号化データを取得する。そして、映像の圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。またデコーダ２０６は、音声の圧縮符号化データを伸長して音声信号を生成し、音声信号をスピーカ２０９ｂに出力する。デコーダ２０６は、ＴＳに関してＭＰＥＧ規格で規定されているシステムターゲットデコーダ（Ｔ−ＳＴＤ）の要件を満たすように構成されている。
グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成した映像信号を出力することができる。液晶表示装置（ＬＣＤ）２０９ａは、グラフィック制御部２０７から出力された映像信号をＬＣＤ上に表示する。スピーカ２０９ｂは、音声信号を音として出力する。コンテンツは、ＬＣＤ２０９ａおよびスピーカ２０９ｂを介して再生され、視聴の対象となる。なお、映像信号および音声信号の出力先は、それぞれＬＣＤ２０９ａおよびスピーカ２０９ｂに限られない。例えば映像信号および音声信号は、外部出力端子（図示せず）を経てカムコーダ１００と別体のテレビやスピーカに伝送されてもよい。
ＣＰＵバス２１３はカムコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。
ネットワーク制御部２１４は、カムコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェイスであり、例えば、イーサネット（登録商標）規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。例えば、ネットワーク制御部２１４は、撮影され生成されたクリップＡＶストリームをネットワーク１０１を介して放送局に伝送してもよい。または、ネットワーク制御部２１４は、カムコーダ１００の動作を制御するためのソフトウェアプログラムが更新されたときは、更新されたプログラムをネットワーク１０１を介して受け取ってもよい。
指示受信部２１５は、カムコーダ１００の本体部に設けられた操作ボタンである。指示受信部２１５は、ユーザから、例えば録画の開始／停止、再生の開始／停止等の指示を受け取る。
インターフェース（Ｉ／Ｆ）部２１６は、カムコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ１００は、ＵＳＢ２．０規格またはＩＥＥＥ１３９４規格の端子を介してＰＣ１０８や、他のカムコーダ（図示せず）、ＢＤ／ＤＶＤレコーダ、ＰＣ等と接続される。
システム制御部２５０は、カムコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはカムコーダ１００を制御するためのソフトウェアプログラムが格納されている。
ＣＰＵ２１１は、カムコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ、カメラ、マイク等を利用して構成されたコンピュータシステムを、本実施形態によるカムコーダ１００と同等の機能を有する機器として動作させることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。
次に、図８（ａ）〜（ｃ）を参照しながら、カムコーダ１００において撮影された、映像および音声に関するコンテンツのデータ管理構造を説明する。図８（ａ）は、本実施形態における１コンテンツの概念を示す。撮影の開始から終了までの期間に得られたコンテンツを、１ショットという。図８（ｂ）は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。１ショット、すなわち１つのコンテンツは、複数のクリップａ〜ｃに分けて各リムーバブルＨＤＤ１１２ａ〜１１２ｃに格納することができる（１つのクリップで完結してもよい）。１つのクリップは、クリップメタデータ８１と、タイムマップ８２と、クリップＡＶストリーム８３の一部（部分ストリーム）とを含む。クリップＡＶストリーム８３は、部分ストリーム８３ａ〜８３ｃから構成されており、クリップａ〜ｃのそれぞれに含まれる。図８（ｂ）には３つのクリップａ〜ｃが記載されているが、各クリップの構成は共通しているため、ここではクリップａを例に挙げて説明する。
クリップａは、クリップメタデータａと、タイムマップａと、部分ストリームａとを含む。このうち、クリップメタデータａおよびタイムマップａは管理情報であり、部分ストリームａがクリップＡＶストリーム８３を構成するデータである。クリップＡＶストリーム８３は原則として１つのファイルに格納されるが、ＦＡＴ３２のファイルサイズの最大値を超えるときには複数のＴＴＳファイルに格納される。図８（ｂ）では、３つの部分ストリーム８３ａ、８３ｂおよび８３ｃが別個のファイルに格納される。なお本実施形態では、各部分ストリームのファイルサイズをＦＡＴ３２ファイルシステムにおけるファイルサイズの最大値（４ギガバイト）とすると、リムーバブルＨＤＤ１１２ａ〜ｃの記録可能容量がなくなって管理情報をリムーバブルＨＤＤ１１２に書き込みできなくなるため、各部分ストリームのファイルサイズは４ギガバイトよりも小さくなることに留意されたい。さらに、ＴＴＳファイルは整数個のＴＴＳパケットから構成されるとし、上記ファイルシステムからの制限である４ギガバイト未満であり、かつ、ＴＴＳパケット（１９２バイト）の整数倍としてもよい。
クリップメタデータａはＸＭＬ形式で記述されており、コンテンツの再生に必要な情報、例えば映像／音声フォーマット等が規定される。クリップメタデータａの詳細は、後に図１０を参照しながら詳述する。
タイムマップａは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」（ＣｌｉｐＴｉｍｅＬｉｎｅ）と呼び、クリップタイムラインが格納されたファイルの拡張子に“ＣＴＬ”を付して図示している。クリップタイムラインの詳細は、後に図１２〜１４を参照しながら詳述する。
部分ストリームａは、図６に示すように複数のＴＴＳパケットから構成される。
なお、１ショットの間にクリップＡＶストリーム８３が複数の部分ストリーム８３ａ〜８３ｃのファイルに格納されたときには、ＴＳパケットの転送タイミングを決定するＡＴＳのクロックカウンタ２６２（図７）がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ２６２（図７）は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。したがって、クリップＡＶストリーム８３を構成する各ＴＴＳパケット中の到着時刻情報ＡＴＳは、１つのショットを構成する連続する２つのＴＴＳファイルの境界において連続している。
図８（ｃ）は、３つのリムーバブルＨＤＤ１１２ａ〜１１２ｃを示す。各クリップａ〜ｃを構成するデータのファイルが各リムーバブルＨＤＤ１１２ａ〜１１２ｃに書き込まれる。
次に、リムーバブルＨＤＤ１１２内にファイルがどのように格納されるかを説明する。図９は、リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す。コンテンツの管理情報とクリップＡＶストリームのファイルは、最上層のルート（ＲＯＯＴ）９０内のコンテンツ（Ｃｏｎｔｅｎｔｓ）フォルダ９１以下に格納される。より具体的には、コンテンツフォルダ９１直下のデータベース（Ｄａｔａｂａｓｅ）フォルダ９２には、管理情報であるクリップメタデータ９４のＸＭＬ形式ファイル、および、クリップタイムライン９５のＣＴＬ形式ファイルが格納される。一方、コンテンツフォルダ９１直下のＴＴＳフォルダ９３には、クリップＡＶストリーム（ＴｉｍｅｄＴｓ）９６のＴＴＳ形式ファイルが格納される。
なお、コンテンツフォルダ９１には、さらにＭＸＦ形式の映像のストリームデータを格納するビデオフォルダ（Ｖｉｄｅｏ）、ＭＸＦ形式の音声のストリームデータを格納するオーディオフォルダ（Ａｕｄｉｏ）、ＢＭＰ形式のサムネイル画像を格納するアイコンフォルダ（Ｉｃｏｎ）、ＷＡＶＥ形式のボイスメモのデータを格納するボイスフォルダ（Ｖｏｉｃｅ）等が設けられてもよく、既存のカムコーダの記録フォーマット等に対応させることができる。
続いて、図１０〜１４を参照しながら、クリップメタデータ９４およびクリップタイムライン９５に記述されたデータの内容を説明する。
図１０は、クリップメタデータ９４に含まれる情報の内容を示す。クリップメタデータ９４は、構成データ（“Ｓｔｒｕｃｔｕｒａｌ”）および記述データ（“Ｄｅｓｃｒｉｐｔｉｖｅ”）の２種類に分類される。
構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ ＩＤｅｎｔｉｆｉｅｒ）が記述される。ＵＭＩＤは、例えば、コンテンツが生成された時刻とそれを生成した機器のＭＡＣ（Ｍｅｄｉａ ＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレスを組み合わせて生成される。さらにＵＭＩＤは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦ＵＭＩＤが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのＵＭＩＤとは異なる値が付加される。よってＵＭＩＤを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。
エッセンスリストには、映像および音声の復号化に必要な情報（ビデオ情報およびオーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はＭＰＥＧ−２方式である。
リレーション情報は、図８（ｂ）に示すような複数のクリップ８１ａ〜８１ｃが存在するときのクリップの間の関係を規定する。具体的には各クリップメタデータ９４には、そのショットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々に対応するクリップＡＶストリーム（部分ストリーム）の再生の先後関係または再生順序を規定しているということができる。クリップを特定する情報は、例えば、ＵＭＩＤおよびそのリムーバブルＨＤＤ１１２固有のシリアル番号とによって規定される。
記述データには、アクセス情報、デバイス、撮影情報、再生情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。再生情報は、再生開始時刻、再生時間長等を特定する情報である。
次に、クリップタイムライン９５を説明する。クリップタイムライン９５では、キーピクチャおよびキーピクチャユニットという概念を導入して、それらに関する情報を規定している。そこでまず図１１を参照しながら、キーピクチャおよびキーピクチャユニットを説明する。
図１１は、キーピクチャおよびキーピクチャユニットの関係を示す。図１１では、Ｉ、ＢおよびＰの各ピクチャを表示される順序で記載している。キーピクチャユニット（Ｋｅｙ Ｐｉｃｔｕｒｅ Ｕｎｉｔ；ＫＰＵ）は、映像に関して規定されるデータ再生単位である。図１１では、キーピクチャユニットＫＰＵの表示は、キーピクチャ４４から開始され、Ｂピクチャ４５において終了する。この間にはＭＰＥＧ規格のグループ・オブ・ピクチャ（ＧＯＰ）が１以上含まれている。Ｂピクチャ４５の次のＩピクチャ４６から、次のキーピクチャユニットＫＰＵの表示が始まる。各キーピクチャユニットの映像再生時間は、０．４秒以上、かつ、１秒以下である。ただし、１ショットの最後のキーピクチャユニットは１秒以下であればよい。撮影の終了タイミングによっては０．４秒に満たないこともあるからである。上記はＧＯＰ先頭のＩピクチャから再生が開始されるとしているが、Ｂピクチャから再生が開始されるＧＯＰ構造の場合には、この限りではない。ＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）は、そのＫＰＵに格納される全ピクチャの再生時間を示しているためである。
キーピクチャユニットの先頭に位置するキーピクチャ４４、４６は、ＭＰＥＧ規格におけるシーケンスヘッダコード（ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅ）およびグループスタートコード（ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ）を含むビデオに関するアクセス単位である。例えば、キーピクチャユニットはＭＰＥＧ２圧縮符号化されたＩピクチャの画像（フレーム画像または１組の２フィールド画像）または、圧縮符号化されたＩフィールドおよびＰフィールドの画像である。
また本実施形態では、ＴＳに付加されたＰＴＳを用いてＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）を定義している。ＫＰＵ期間は、次のキーピクチャユニットＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）と、そのＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）との差分値である。図１１では、キーピクチャ４４の時刻をＰＴＳ（Ｎ）とし、キーピクチャ４６の時刻をＰＴＳ（Ｎ＋１）としたとき、ＫＰＵ期間（Ｎ）は、ＰＴＳ（Ｎ＋１）−ＰＴＳ（Ｎ）として定義される（ともにキーピクチャが表示開始ピクチャとなっている場合）。なお、ＫＰＵ期間の定義から明らかなように、あるＫＰＵ期間の値を決定するためには、次のキーピクチャユニットＫＰＵのピクチャが圧縮符号化され、最初に表示されるピクチャの再生時刻（ＰＴＳ）が確定しなければならない。よって、あるキーピクチャユニットＫＰＵに対するＫＰＵ期間は、次のキーピクチャユニットの生成が開始された後に定まる。なお、ショットで最後のＫＰＵ期間が必要な場合もあるため、符号化したピクチャの表示時間を積算していく方法も可能である。その場合には、次のＫＰＵの生成開始を待たずともＫＰＵ期間を決定することが可能である。
次に、図１２（ａ）〜（ｃ）を参照しながら、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）を説明する。図１２（ａ）は、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す。クリップタイムライン９５は、拡張子に“ＣＴＬ”を有するファイルとして各リムーバブルＨＤＤ１１２に書き込まれる。
クリップタイムライン９５は、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。「再生単位」は、上述のキーピクチャユニットＫＰＵに対応する。
クリップタイムライン９５には、複数のフィールドが規定されている。例えば、クリップタイムライン９５には、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａ、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂ、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃ、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄ、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅ、ＳｔａｒｔＳＴＣフィールド９５ｆ、ＴｉｍｅＥｎｔｒｙフィールド９５ｇ、ＫＰＵＥｎｔｒｙフィールド９５ｈ等を含む。各フィールドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定している。
例えば、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａにはタイムエントリの数が記述され、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂにはＫＰＵエントリの数が記述される。ただしＴｉｍｅＥｎｔｒｙフィールド９５ｇおよびＫＰＵＥｎｔｒｙフィールド９５ｈは、後述のタイムエントリの数およびＫＰＵエントリの数に応じてデータサイズが変動し得る。
図１２（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示す。ＴｉｍｅＥｎｔｒｙフィールド９５ｇには、対応するタイムエントリに関する属性を示す情報が複数のフィールド（ＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａ、ＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂおよびＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃ）に記述されている。
また、図１２（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す。ＫＰＵＥｎｔｒｙフィールド９５ｈには、対応するキーピクチャユニットＫＰＵに関する属性を示す情報が複数のフィールド（ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ、ＫｅｙＰｉｃｔｕｒｅＳｉｚｅフィールド９８ｂ、ＫＰＵＰｅｒｉｏｄフィールド９８ｃおよびＫＰＵＳｉｚｅフィールド９８ｄ）に記述されている。
ここで、図１３（ａ）および（ｂ）を参照しながら、クリップタイムライン９５に含まれる主要なフィールドに規定されるデータの意味を説明する。
図１３（ａ）は、タイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ａ）の横軸の１目盛りは１アクセスユニット時間（Ａｃｃｅｓｓ Ｕｎｉｔ ＴｉＭｅ；ＡＵＴＭ）を示している。これは１ピクチャの表示時間に対応する。ここでいう「ピクチャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プログレッシブビデオに対しては１枚のプログレッシブ走査のフレーム画像に対応し、インターレースビデオに対してはインターレース走査のフィールド画像（１フィールド）に対応する。例えば２４０００／１００１秒間隔で表示されるプログレッシブビデオ（つまり２３．９７ｐ）では、１ＡＵＴＭは１／（２４０００／１００１）秒＝１１２６１２５ｃｌｏｃｋｓ／２７ＭＨｚと表記される。
ここでまず、１ショットにｎ個のクリップが含まれるとしたときの時間の関係を説明する。まず各クリップの再生時間長は、それぞれのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅに記述される。この値はＡＵＴＭを利用して記述される。すべてのクリップについてのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値の和を計算すると、１ショットの再生時間長（撮影時間長）が得られる（数１）。この時間長もまた、ＡＵＴＭを利用して記述される。
Figure 2006033275
一方、図１３（ａ）に示すＫＰＵ＃０から＃（ｋ＋１）までが１クリップに含まれるとすると、上述の各クリップのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅは、そのクリップに含まれる全てのキーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値の総和として得られる（数２）。上述のように、ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）はＡＵＴＭ値を用いて表記されるため、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅもＡＵＴＭ表記である。
Figure 2006033275
各ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値は、上述のとおり、そのキーピクチャユニットＫＰＵに含まれるピクチャのビデオ表示時間（ＡＵＴＭ値）の和に対応する（数３）。
Figure 2006033275
「タイムエントリ」（ＴｉｍｅＥｎｔｒｙ）とは、一定の固定時間（例えば５秒）ごとに設定され、その位置から再生を開始することが可能な時間軸上の飛び込み点を示す。タイムエントリの設定に関連して、先頭のキーピクチャユニットＫＰＵ＃０の再生開始時刻を０としたとき、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。また、各タイムエントリの設定時刻に再生されるキーピクチャユニットＫＰＵを識別する情報がＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａに記述され、そのキーピクチャユニットＫＰＵの先頭からそのタイムエントリの設定時刻までの時間オフセットを示す情報がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃに記述される。
例えば、タイムエントリ＃ｔが指定されると、（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）＋（タイムエントリの間隔・ｔ）を計算することにより、そのタイムエントリ＃ｔが設定された時刻、すなわち先頭キーピクチャユニットＫＰＵ＃０の先頭からの経過時間を得ることができる。
また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。すなわち、ユーザから再生を開始したい時刻の指定を受け取ると、その時刻は、周知の変換処理を利用してＭＰＥＧ規格上の時間情報であるＰＴＳ値に変換される。そして、そのＰＴＳ値が割り当てられたピクチャから、再生が開始される。なおＰＴＳ値は、ビデオＴＳパケット（Ｖ＿ＴＳＰ）３０のトランスポートパケットヘッダ３０ａ（図４（ａ））内に記述されている。
本実施形態では、１つのクリップＡＶストリームが複数の部分ストリームに分けられているため、各クリップ内の部分ストリーム先頭の再生開始時刻（ＰＴＳ）が０でないことがある。そこで、クリップタイムライン９５のＳｔａｒｔＳＴＣフィールド９５ｆ（図１２（ａ））には、そのクリップ内の先頭ＫＰＵの中で最初に表示されるピクチャの再生時刻情報（ＰＴＳ）が記述されている。そのピクチャのＰＴＳ値と指定された時刻に対応するＰＴＳ値とに基づいて、再生開始すべきピクチャまでのＰＴＳ（ＡＵＴＭ）差分値が得られる。なお、各ピクチャに割り振られているＰＴＳ値のデータ量と、ＳｔａｒｔＳＴＣフィールド９５ｆに規定されているＰＴＳ値のデータ量とを一致させることが好ましく、例えば３３ビットで表記される。
上述の差分値がＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値よりも大きければ、再生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に存在すると判断できる。後者のときは、さらにそのＰＴＳ差分値に基づいて、どの程度先の時刻かも容易に特定できる。
図１３（ｂ）は、ＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ｂ）の横軸の１目盛りは１データユニット長（Ｔｉｍｅｄ ＴＳ Ｐａｃｋｅｔ Ｂｙｔｅ Ｌｅｎｇｔｈ；ＴＰＢＬ）を示している。これは１データユニットがＴＴＳパケットのデータ量（１９２バイト）と等しいことを意味する。
各ＫＰＵエントリは、各キーピクチャユニットＫＰＵに対して１つ設けられている。ＫＰＵエントリの設定に関連して、各ＫＰＵのデータサイズがＫＰＵＳｉｚｅフィールド９８ｄに記述され、各タイムエントリごとに対応するＫＰＵの開始アドレスがＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂに記述される。なお、各キーピクチャユニットＫＰＵのデータサイズは、例えば図１３（ｂ）のＫＰＵｓｉｚｅ＃ｋに示すように、そのＫＰＵの中で最初のピクチャのデータを格納した最初のＴＴＳパケットから、次のＫＰＵの最初のピクチャを格納したＴＴＳパケット直前のＴＴＳパケットまでのデータサイズを１データユニット長（ＴＰＢＬ）で示して表される。
さらにＫＰＵエントリには、ファイルの最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定されている。このフィールドを設ける理由は以下のとおりである。例えば１ショットのクリップＡＶストリームのデータが複数のファイルに分けて格納されたとき、２番目以降のファイルの先頭には先のファイル最後尾のＫＰＵの一部が格納されることがある。キーピクチャユニットＫＰＵ内の各ピクチャは、ＫＰＵ先頭のキーピクチャから復号化をしなければならないため、ファイルの先頭に存在するデータは単独で復号化できない。よってそのようなデータは、意味のないデータ（フラグメント）として読み飛ばすことが必要になる。そこで上述のオフセットフィールド９５ｄにそのオフセット値を利用して、読み飛ばしを可能にしている。
ここで、図１４を参照しながら、１ショットのクリップＡＶストリームデータが複数のファイルに分けて格納されたときのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ等を説明する。説明の簡単のために、ここでは１ショットのコンテンツに関する管理情報とクリップＡＶストリームとが、２つのリムーバブルＨＤＤ＃１および＃２に格納されるとして説明し、またクリップメタデータには言及しない。
図１４は、２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す。リムーバブルＨＤＤ＃１および＃２には、それぞれクリップタイムラインのファイル（００００１．ＣＴＬおよび００００２．ＣＴＬ）と、クリップＡＶストリームのファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）とが格納されている。
以下では、ＫＰＵエントリに注目する。まず、リムーバブルＨＤＤ＃１上のＫＰＵエントリ＃（ｄ−１）は、００００１．ＴＴＳ内のクリップＡＶストリームに規定されるキーピクチャユニットＫＰＵ＃（ｄ−１）に対応して設けられている。図１４に示すように、キーピクチャユニットＫＰＵ＃（ｄ−１）のすべてのデータは、００００１．ＴＴＳ内に存在している。その場合には、ＫＰＵエントリ＃（ｄ−１）のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。
次に、ＫＰＵエントリ＃ｄおよび対応するキーピクチャユニットＫＰＵ＃ｄに着目する。図１４に示すキーピクチャユニットＫＰＵ＃ｄは、その一部（キーピクチャユニットＫＰＵ＃ｄ１）がリムーバブルＨＤＤ＃１の００００１．ＴＴＳ内に存在し、他の一部（キーピクチャユニットＫＰＵ＃ｄ２）がリムーバブルＨＤＤ＃２の００００２．ＴＴＳ内に存在している。キーピクチャユニットＫＰＵ＃ｄが２つのリムーバブルＨＤＤに分けて格納されている理由は、例えばリムーバブルＨＤＤ＃１への書き込み中に、記録可能な残り容量が所定値以下になり、それ以上の書き込みが不可能になったためである。この場合には、ＫＰＵエントリ＃ｄのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには１ｂが設定される。
なお、リムーバブルＨＤＤ＃２内のＫＰＵエントリ＃０に対応するキーピクチャユニットＫＰＵは、そのすべてのデータがリムーバブルＨＤＤ内に格納されているから、そのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。
上述のようにＫＰＵエントリ内のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を調べることにより、そのキーピクチャユニットＫＰＵがそのメディア内のファイルに格納されているか否かが判断できる。この利点は、例えば以下の処理において非常に効果的である。
図１４に示すように、ＫＰＵ＃ｄを構成するデータが複数のＴＴＳファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）に跨って格納されているときにおいて、リムーバブルＨＤＤ＃２内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムーバブルＨＤＤ＃１に格納されたデータのみに基づいて１ショットの再生が行われる。
編集処理によって１ショットの再生時間が変化するため、正確な再生時間を算出する必要がある。そこで、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に基づいて再生時間の算出処理を変化させることができる。
以下に、再生が保証されているピクチャまでの再生時間を算出する処理（１）と、現実に再生可能なピクチャまでの再生時間を算出する処理（２）とを説明する。例えば、処理（１）は個人ユーザ向けの機器に実装され、処理（２）は業務ユーザ向けの機器に実装される。
まず、上述の処理（１）から説明する。編集処理が行われた後のリムーバブルＨＤＤ＃１内の最後のＫＰＵ＃ｄに関しては、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値は“１ｂ”である。このときは、先頭からＫＰＵ＃（ｄ−１）までのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和を、リムーバブルＨＤＤ＃１内のクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用する。換言すれば、上述の数２においてキーピクチャユニットＫＰＵ＃ｄのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の値はクリップの再生時間として算入しない。その理由は、実際に再生可能な時間（最初のＫＰＵからＫＰＵ＃（ｄ−１）まで）と数２に基づいて算出した１ショットの再生時間（最初のＫＰＵからＫＰＵ＃ｄまで）との間には、最後のＫＰＵ＃ｄ相当の再生時間（０．４秒以上１秒未満）だけ誤差が発生し得るからである。この算出方法によれば、再生が保証されている映像の再生時間が把握できる。
次に、上述の処理（２）を説明する。処理（１）においては、データが存在するＫＰＵ＃ｄ１の再生時間は考慮されていない。しかし、ＫＰＵ＃ｄ１内のデータに基づいて再生可能なピクチャが存在し得るため、処理（１）によって算出される再生時間は厳密には誤差が含まれうる。機器から提示された再生時間がこのような誤差を含むことは、特に業務用途や特殊用途の機器においてはあってはならないケースが想定される。そこで、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”の時には、フレーム／フィールド単位で連続して再生できるビデオ再生時間をＫＰＵ＃ｄ１を解析して求めればよい。その再生時間を処理（１）によって得られる再生時間に加算することによって、クリップの再生時間を非常に正確に求めることができる。
なお、リムーバブルＨＤＤ＃１内の最後のＫＰＵに対応するＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“０ｂ”のときは、先頭から最後までの各キーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用すればよい。最後のキーピクチャユニットＫＰＵ内の全てのピクチャが再生可能であるため、そのＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）に算入すべきだからである。
以上説明したように、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に応じてクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の算出する処理を変化させることにより、常に正確な再生時間長を算出できる。
また、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を利用して不完全なキーピクチャユニットＫＰＵを削除するか否かを決定し、削除したときには残されたクリップについてクリップタイムラインを修正してもよい。この「不完全なキーピクチャユニット」とは、全てのピクチャのデータが存在しないキーピクチャユニットをいい、ここではＫＰＵ＃ｄ２が存在しないＫＰＵ＃ｄに相当する。
具体的に説明すると、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”のときには、不完全なキーピクチャユニットＫＰＵ＃ｄ１をキーピクチャユニットＫＰＵとして取り扱わないように、ＴＴＳファイルから削除し、リムーバブルＨＤＤ＃１内のクリップタイムラインを修正すればよい。クリップタイムラインの修正は、キーピクチャユニットＫＰＵの数（ＫＰＵＥｎｔｒｙＮｕｍｂｅｒ９５ｂ）を減少させること、ＫＰＵ＃ｄのＫＰＵエントリを削除すること、キーピクチャユニットＫＰＵ＃ｄ１内のタイムエントリ（ＴｉｍｅＥｎｔｒｙ）９５ｇを削除すること等を含む。修正後は、リムーバブルＨＤＤ＃１の００００１．ＴＴＳファイルの最後のキーピクチャユニットはＫＰＵ＃（ｄ−１）になり、最初のＫＰＵから最後のＫＰＵ＃（ｄ−１）までの再生時間の和が１ショットの再生時間になる。よって、上述の数１〜数３を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削除はＦＡＴ３２ファイルシステム上においても、ＴＴＳパケット（１９２バイト）単位で可能である。
なお、キーピクチャユニットＫＰＵ＃ｄ２は、リムーバブルＨＤＤ＃２内ではフラグメントであり、そのデータのみではビデオは復号化できない。よって、リムーバブルＨＤＤ＃２内のクリップＡＶストリームファイル（００００２．ＴＴＳ）の最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定される。さらに、そのキーピクチャユニットＫＰＵ＃０の先頭から、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。なお、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０でないときは、前のリムーバブルＨＤＤからのキーピクチャユニットＫＰＵが格納されていることを表すため、巻き戻し再生時にはまず、クリップメタデータ９４のリレーション情報を参照することで、直前のクリップがあるか否かを特定することができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能であった場合には、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０か否かを確認し、０でないときに前のリムーバブルＨＤＤの最後のキーピクチャユニットＫＰＵに対応するＫＰＵエントリのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値をさらに確認して、キーピクチャユニットＫＰＵの跨ぎが発生しているか否かを確実に判定することもできる。
次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用してコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集する際の処理を説明する。
まず図１５および図１６を参照しながら、コンテンツをリムーバブルＨＤＤに録画するときのカムコーダ１００の処理（録画処理）を説明する。
図１５は、カムコーダ１００によるコンテンツの録画処理の手順を示す。まずステップＳ１５１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから撮影開始の指示を受け取る。そして、ステップＳ１５２において、ＣＰＵ２１１からの指示に基づいて、エンコーダ２０３は入力信号に基づいてＴＳを生成する。なおデジタル放送の録画時には、ステップＳ１５１において録画開始の指示を受け取り、ステップＳ１５２においてデジタルチューナ２０１ｃを用いて録画対象の番組のＴＳパケットを抽出すると読み替えればよい。
ステップＳ１５３では、メディア制御部２０５は、ＴＳ処理部２０４においてＴＴＳヘッダが付加されたＴＳ（クリップＡＶストリーム）を、順次リムーバブルＨＤＤに書き込む。そしてメディア制御部２０５は、ステップＳ１５４において、クリップ（ＴＴＳファイル）を新規に作成するか否かを判断する。新規に作成するか否かは、記録中のクリップのＴＴＳファイルのサイズが所定値よりも大きいか否かや、リムーバブルＨＤＤの残容量に応じて任意に決定できる。新規にクリップを作成しない場合はステップＳ１５５に進み、新規にクリップを生成するときはステップＳ１５６に進む。
ステップＳ１５５では、ＴＳ処理部２０４は、キーピクチャユニットＫＰＵが生成されるごとに、ＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵのすべてのデータはそのクリップのＴＴＳファイル内に書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“０ｂ”を設定する。そしてメディア制御部２０５は、ステップＳ１５７においてＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）をリムーバブルメディアに書き込む。その後、ステップＳ１５８において、ＣＰＵ２１１は撮影終了か否かを判断する。撮影は、例えば指示受信部２１５を介して撮影終了指示を受信したとき、次にデータを書き込むべきリムーバブルＨＤＤが存在しないとき等に終了する。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はステップＳ１５２に戻り、それ以降の処理が繰り返される。
一方ステップＳ１５６では、ＴＳ処理部２０４は、最後に書き込まれたデータによってキーピクチャユニットＫＰＵが完結したか否かを判断する。仮にキーピクチャユニットＫＰＵが完結しなければ、そのキーピクチャユニットＫＰＵの残りのデータは他のリムーバブルＨＤＤに格納されることになる。そのため、キーピクチャユニットＫＰＵのすべてのデータがそのリムーバブルＨＤＤ内に書き込まれたか否かを判断するために、このような判断が必要になる。キーピクチャユニットＫＰＵが完結しているときには処理はステップＳ１５５に進み、完結していないときには処理はステップＳ１５９に進む。
ステップＳ１５９では、ＴＳ処理部２０４によってクリップ切り替え処理が行われる。この処理の具体的な内容を、図１６に示す。
図１６は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ（クリップ）の録画先のメディアを、あるリムーバブルＨＤＤから他のリムーバブルＨＤＤに切り替えたり、同一リムーバブルＨＤＤ上で新規クリップを生成する処理である。以下では説明を簡略化するために、クリップの切り替えが、コンテンツの録画先メディアの変更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブルＨＤＤを「第１リムーバブルＨＤＤ」と呼び、次にコンテンツが録画されるリムーバブルＨＤＤを「第２リムーバブルＨＤＤ」と呼ぶ。
まずステップＳ１６１において、ＣＰＵ２１１は、第２リムーバブルＨＤＤ上に生成されるクリップのクリップ名を決定する。次に、ステップＳ１６２において、カムコーダ１００は第１リムーバブルＨＤＤに完全に記録できなかったキーピクチャユニットＫＰＵが完結するまでＴＳを生成する。そして、ＴＳ処理部２０４はＴＴＳヘッダを付加し、メディア制御部２０５はそのクリップＡＶストリームを第２リムーバブルＨＤＤに書き込む。
次にステップＳ１６３において、メディア制御部２０５は、完結したＫＰＵのＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵは第１リムーバブルＨＤＤおよび第２リムーバブルＨＤＤに跨って書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“１ｂ”を設定する。
ステップＳ１６４において、メディア制御部２０５は、生成したＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を、第１リムーバブルＨＤＤに書き込む。そして、ステップＳ１６５において、第１リムーバブルＨＤＤ上のクリップ・メタデータ（リレーション情報等）を更新する。例えば、メディア制御部２０５は、第１リムーバブルＨＤＤ上のクリップのクリップメタデータに、次のクリップとして第２リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。また、第２リムーバブルＨＤＤ上のクリップのクリップメタデータに、前のクリップとして第１リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。その後、ステップＳ１６６において、メディア制御部２０５は、今後のコンテンツの書き込み先を第２リムーバブルＨＤＤに設定し、処理が終了する。
次に、図１７を参照しながら、カムコーダ１００がリムーバブルＨＤＤからコンテンツを再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初から再生するときの処理は、ＫＰＵエントリ、タイムエントリ等を設けない従来の処理と同じであるため、その説明は省略する。
図１７は、カムコーダ１００によるコンテンツの再生処理の手順を示す。ステップＳ１７１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから再生開始時刻の指示を受け取る。
ステップＳ１７２において、メディア制御部２０５は時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を読み出して、ＣＰＵ２１１が再生開始時刻のピクチャを含むキーピクチャユニット（ＫＰＵ）を特定する。そして、ステップＳ１７３において、ＣＰＵ２１１は、再生開始時刻に対応するＫＰＵの開始位置を特定する。このＫＰＵの開始位置は、ＴＴＳファイル内の復号開始位置（アドレス）を表している。
これらの処理の一例は以下のとおりである。すなわち、ＣＰＵ２１１は、再生開始時刻がタイムエントリ＃ｔとタイムエントリ＃（ｔ＋１）の間の時刻であることを特定し、さらにタイムエントリ＃ｔから起算してｍアクセスユニット時間（ＡＵＴＭ）を１単位として何単位離れているかを特定する。
具体的には、まずタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａの値に基づいて、あるＫＰＵ（ＫＰＵ＃ｋとする）が特定される。そして、タイムエントリ＃ｔが指し示す時刻からＫＰＵ＃ｋの先頭キーピクチャの再生が開始されるまでの時間差がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃの値に基づいて取得される。その結果、再生開始すべきピクチャがＫＰＵ＃ｋの中で最初に表示されるピクチャから何ＡＵＴＭ後か判明する。すると、ＫＰＵ＃ｋからＫＰＵごとにＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）を加算していくことで、再生開始すべきピクチャを含むＫＰＵが特定できる。また、タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレスにＫＰＵ＃ｋから再生開始すべきピクチャを含むＫＰＵの直前のＫＰＵまでのＫＰＵＳｉｚｅを加算していくことで、再生開始時刻に対応するＫＰＵの開始位置を特定できる。なお、「タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレス」は、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値とタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂの値との和を計算することによって取得できる。
なお、上述の説明は、説明の簡略化のためＣｌｏｓｅｄＧＯＰ構造（ＧＯＰ内の全てのピクチャはＧＯＰ内のピクチャを参照するのみ）を前提としている。しかしながら、ＣｌｏｓｅｄＧＯＰ構造が取れない場合や、保証できない場合には、特定された再生開始時刻を含むＫＰＵの一つ前のＫＰＵから復号を開始してもよい。
次のステップＳ１７４では、メディア制御部２０５はそのキーピクチャユニット（ＫＰＵ）のＫＰＵＥｎｔｒｙ中のフラグを読み出し、ステップＳ１７５においてＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”か否かを判断する。値が“１ｂ”のときは、キーピクチャユニットＫＰＵが第１および第２リムーバブルＨＤＤにまたがることを意味しており、処理はステップＳ１７６に進む。一方値が“０ｂ”のときは、跨らないことを意味しており、処理はステップＳ１７７に進む。
ステップＳ１７６において、メディア制御部２０５は第１リムーバブルＨＤＤに格納されたＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。このとき、特定したピクチャによっては、読み出しを開始した第１リムーバブルＨＤＤではなく第２リムーバブルＨＤＤにデータが格納されていることもあるが、復号を正しく行うために２つのクリップ（ＴＴＳファイル）を跨ぐＫＰＵの先頭キーピクチャからデコードが行われる。
ステップＳ１７７では、メディア制御部２０５はＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブルＨＤＤ内に格納されている。
その後、ステップＳ１７８では、再生開始時刻に対応するピクチャのデコード終了後に、グラフィック制御部２０７はそのピクチャから出力を開始する。対応する音声が存在するときには、スピーカ２０９ｂもまたその出力を開始する。その後は、コンテンツの最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終了する。
次に、図１８および図１９を参照しながら、リムーバブルＨＤＤに録画されたコンテンツを編集する処理を説明する。この処理は、カムコーダ１００においても実行されるとして説明するが、他には、コンテンツが録画されたリムーバブルＨＤＤが装填されたＰＣ１０８（図１）等において実行されてもよい。
図１８（ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す。図１８（ａ）に示される範囲Ｄが、削除の対象となる部分である。この範囲Ｄは、ＴＴＳファイルの先頭部分を含む。先頭部分のアドレスをｐ１とし、ｐ１＋Ｄ＝ｐ４とする。これまで説明したように、クリップＡＶストリームは複数のファイルに分けて格納されることがあるが、以下の処理は、各ＴＴＳファイルの先頭部分を含む削除に対して適用される。
図１８（ｂ）は、範囲Ｄを削除した後の管理情報（クリップタイムライン）およびクリップＡＶストリームの関係を示す。本実施形態では、範囲Ｄのすべてを常に削除するのではなく、範囲Ｄに収まるデータ量のうち、９６キロバイトのｎ倍（ｎ：整数）のデータ量だけを削除する。いま、削除後の先頭データ位置をアドレスｐ２とすると、（ｐ２−ｐ１）は、（９６キロバイト）・ｎである。また、ｐ２≦ｐ４である。
上述の範囲Ｄの終端アドレスｐ４は、ユーザの編集位置を示している。換言すれば、この終端アドレスｐ４はユーザにとっては後続のストリームの開始点を示している。アドレスｐ４の値は、（ｐ１＋Ｄ）の値として表される。さらに、例えばそのアドレスに対応するピクチャの再生開始時刻情報（例えばＰＴＳ）を利用して表すこともできる。例えばユーザがアドレスｐ４を始点とし、後続のアドレスを終点とする編集を行うときには、上述のアドレスｐ４に対応するピクチャの再生開始時刻情報とともに、ｐ４からのビデオ再生時間長や、開始時刻情報と同様のビデオの再生終了時刻情報によって、終点を特定することができる。ユーザの編集区間を示す情報（開始点・終了点）は、図９のＣｌｉｐ Ｍｅｔａｄａｔａ（９４）、または、Ｃｌｉｐ Ｔｉｍｅ Ｌｉｎｅ（９５）において管理される。
アドレスｐ４の値またはそのアドレスに対応する時刻情報を保持することにより、ユーザが指定した範囲Ｄの後から再生、編集等を開始することができる。特に本実施形態の処理によれば、ユーザが削除を指定した範囲Ｄのうち、ｐ２からｐ４までのデータが再生可能な状態で残されることがある。ユーザにとってはｐ２からｐ４のデータは削除されており、再生されると違和感を覚える。そこでアドレスｐ４の値等を保持しておくことにより、ｐ２からｐ４までの区間の映像が再生されたり、その間を編集開始位置として誤って認識することを確実に防止することができる。アドレスｐ４の値またはそのアドレスに対応する時刻情報は、図１０に示すクリップメタデータ９４の記述データ（ｄｅｓｃｒｉｐｔｉｖｅ）中の再生情報として格納される。
「９６キロバイト」は、本実施形態において採用するクラスタサイズ（３２キロバイト）と、ＴＴＳパケットのパケットサイズ（１９２バイト）との最小公倍数である。このように処理する理由は、クラスタサイズの整数倍とすることによってリムーバブルＨＤＤに対するデータ削除処理がアクセス単位で実行でき、またＴＴＳパケットのパケットサイズの整数倍とすることによってデータ削除処理がクリップＡＶストリームのＴＴＳパケット単位で実行できるため、処理を高速化かつ簡易にできるからである。なお、本実施形態ではクラスタサイズを３２キロバイトとしているため、９６キロバイトを基準として削除単位を決定したが、この値はクラスタサイズや、採用するクリップＡＶストリームのパケットサイズに応じて変化し得る。
削除処理では、さらにＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃおよびＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値も変更される。これらの値は削除前は０である。削除後は、まずＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに、初めて現れるキーピクチャユニットＫＰＵまでのデータ量が記述される。初めて現れるキーピクチャユニットＫＰＵの格納アドレスをｐ３とすると、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄは（ｐ３−ｐ２）の値が記述される。また、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに、最初のキーピクチャユニットＫＰＵの中で先頭のキーピクチャの再生時刻から最初のタイムエントリまでの時間差がＡＵＴＭ単位で記述される。なお、アドレスｐ２からｐ３までのクリップＡＶストリームのパケットは、単独でデコードできるという保証がないため、フラグメントとして扱われ、再生の対象とはされない。
図１９は、カムコーダ１００によるコンテンツの部分削除処理の手順を示す。まずステップＳ１９１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザからＴＴＳファイルの部分削除指示、および、削除範囲Ｄの指定を受け取る。部分削除指示とは、ＴＴＳファイルの先頭部分および／または末尾部分を削除する指示である。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および／または末尾部分を削除する「後方部分削除処理」が行われる。
ステップＳ１９２において、前方部分削除処理か否かが判定される。前方部分削除処理を行う場合にはステップＳ１９３に進み、前方部分削除でない場合にはステップＳ１９５に進む。ステップＳ１９３では、メディア制御部２０５は、削除範囲に相当するデータ量Ｄのうち、９６キロバイトの整数倍のデータ量を先頭から削除する。そしてステップＳ１９４において、メディア制御部２０５は、時間・アドレス変換テーブル（クリップタイムライン）中の、最初のタイムエントリに対する時間オフセットの値（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）と最初のＫＰＵエントリに対するアドレスオフセット値（ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値）とを修正する。その後、処理はステップＳ１９５に進む。
ステップＳ１９５では、後方部分削除処理か否かが判定される。後方部分削除処理を行う場合にはステップＳ１９６に進み、行わない場合にはステップＳ１９７に進む。ステップＳ１９６では、削除範囲に相当するデータ量のうち、ＴＴＳファイルの最後が完全なＫＰＵとなるよう１９２バイト単位でデータが削除される。これはすなわち、１９２バイトの整数倍のデータ量のデータが削除されることを意味する。その後処理はステップＳ１９７に進む。
ステップＳ１９７では、部分削除処理によって変化したタイムエントリ数やＫＰＵエントリ数等を修正する。具体的には、時間・アドレス変換テーブル（ＣｌｉｐＴｉｍｅＬｉｎｅ）中で、実データを伴わなくなったＫＰＵＥｎｔｒｙエントリ、およびＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤで参照していたＫＰＵＥｎｔｒｙエントリを失ったＴｉｍｅＥｎｔｒｙエントリが削除される。また、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａの値、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂの値等の修正処理が行われる。
なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合にもステップＳ１９７を経由する。これは、例えばＴＴＳファイルの中間部分の削除処理が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削除処理は本明細書においては特に言及しない。
なお、上述のように部分削除処理はＴＴＳファイルの先頭部分に限られず、ＴＴＳファイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の不完全なキーピクチャユニットＫＰＵ（図１４のＫＰＵ＃ｄ１）を削除する際に適用される。不完全なキーピクチャユニットＫＰＵは１クリップの最後に存在しているため、「ＴＴＳファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全なキーピクチャユニットＫＰＵの先頭からＴＴＳファイルの最後までであり、例えばＴＴＳパケットのパケットサイズ（１９２バイト）単位で削除する範囲を決定すればよい。クラスタサイズは特に考慮しなくてもよい。なお、ＴＴＳファイルの最後の部分は不完全なキーピクチャユニットＫＰＵに限られず、ユーザから範囲の指定を受けること等により、任意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行ってもよいし、一方の処理のみを行ってもよい。
以上、本発明の実施形態を説明した。
本実施形態では、データストリーム等を格納するメディアはリムーバブルＨＤＤであるとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば、非可換メディア、例えばデータ処理装置に内蔵されたＨＤＤであってもよい。
タイムマップ（ＣｌｉｐＴｉｍｅＬｉｎｅ）のデータ構造は、ＴｉｍｅＥｎｔｒｙおよびＫＰＵＥｎｔｒｙの２層を含むとした。しかし、再生時間と記録アドレスの変換が可能であればこれに限る必要は一切なく、ＫＰＵＥｎｔｒｙの１層のみからなるタイムマップであっても全く同様である。上述の説明では、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドを設け、その値に基づいてキーピクチャユニットＫＰＵが複数のファイルを跨っていることを示すとして説明した。しかし、複数のファイルを跨っているか否かは、タイムマップに相当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデータ（リレーション情報など）、クリップのファイル名の命名規則（ファイル名の番号が昇順など）、同一フォルダ内に１ショットの全データ（少なくとも１ショットを構成する全ＴＴＳファイルの内、同一記録媒体上に記録されたもの）を格納する等によって、ＫＰＵが跨っている、または、跨っている可能性があることを示してもよい。
なお、図２等の各機能ブロックは典型的には集積回路（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ；ＬＳＩ）のチップとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。例えば、図２においては、ＣＰＵ２１１を含むシステム制御部２５０とメディア制御部２０５とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、システム制御部２５０にメディア制御部２０５の機能を与え、物理的に同一のチップによって実現してもよい。また、メディア制御部２０５およびＴＳ処理部２０４の機能を集積化して、１つのチップ回路として実現してもよいし、さらにエンコーダ２０３およびデコーダ２０６の機能を付加したチップ回路２１７として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外することにより、複数の符号化方式に容易に対応できる。
システム制御部２５０は、プログラムＲＯＭ２１０等に格納されたコンピュータプログラムを実行することにより、本明細書に記載したメディア制御部２０５の機能を実現することができる。このときは、メディア制御部２０５はシステム制御部２５０の一部の機能として実現される。
なお、上述の「ＬＳＩ」は、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。
本発明によれば、コンテンツの録画のために、複数ファイルに跨ってコンテンツのデータストリームが格納されることを想定したデータ構造を得ることができる。このデータ構造によれば、機器はどのファイル内のデータであっても容易にアクセスし、再生を開始することができる。またこのデータ構造を利用してさらにファイルの編集を行うことにより、機器は処理の高速化および処理負荷の軽減を実現できる。
本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコンテンツの再生および編集を容易にする技術に関する。
近年、ＤＶＤ等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器（光ディスクレコーダ、カムコーダ等）の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。
近年はＰＣにもコンテンツの記録、再生および編集機能が実装されており、ＰＣも上述のデジタル機器に含めることができる。ＰＣでは、文書データ等を記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、ＰＣと連携可能なデータ管理構造、例えばＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）を用いたファイルシステムが採用されている。現在多く利用されているＦＡＴ３２ファイルシステムでは、最大４ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が２テラバイトのメディアを管理することができる。
メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。例えば特許文献１では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるＡＶデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。
特開平１１−１５５１３０号公報
コンテンツの再生時間が長くなり、コンテンツの一部を削除する編集処理が頻繁に行われるようになると、従来の処理では編集処理時間が長くなるという問題が生じる。例えば、データストリームの内容を解析し、削除範囲内のピクチャのデータ位置等を特定した後にそのデータを削除すると、解析時間、データ位置の特定時間および削除時間がそれぞれ必要になる。
この問題は、トランスポートストリーム等を構成する固定長のデータパケットに、ＭＰＥＧ規格等による順方向符号化方式および双方向符号化方式で圧縮符号化された映像データを格納しているときに顕著である。例えば、ＭＰＥＧ規格の一連の映像データの一部を削除するとき、まず、編集装置は削除の開始ピクチャおよび終了ピクチャを特定するために、メディアからパケットを読み出してパケット内のデータを解析しなければならない。パケットデータの読み出しは、例えばファイルシステムのクラスタ単位で行われるため、一般には、必要とするパケット以外の不要なパケットも同時に読み出される。よって不要なアクセス時間がかかる。さらに、ピクチャを特定して削除しても、削除直後の開始ピクチャをいわゆるＩピクチャに設定しなければならないため、そのピクチャデータの読み出し、デコードおよび再エンコードが必要になる。
本発明の目的は、コンテンツのデータストリームを高速に編集する手段を提供することである。
本発明によるデータ処理装置は、メディアに書き込まれたコンテンツを編集することができる。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部とを備えている。
前記データストリームは、複数のピクチャから構成され、かつ、基準ピクチャからのデコードを要する復号化単位を１つまたは複数含む再生単位を含んでいる。前記メディア制御部は、データを削除した後のファイル内のデータストリームにおいて初めて現れる再生単位までのデータ量の値を前記メディアに書き込んでもよい。
前記メディアには、データを削除する前のデータストリームに対して、前記コンテンツの一定の再生時間ごとに再生されるピクチャのデータ位置を特定するタイムエントリが予め書き込まれている。前記メディア制御部は、データを削除した後のデータストリームに関し、初めて現れる前記再生単位の先頭から、前記タイムエントリによって特定される初めてのピクチャのデータ位置までのデータ量の値を前記メディアに書き込んでもよい。
前記データストリームは、各々のパケットサイズが１９２バイトである複数のパケットから構成され、前記メディアには３２キロバイトのクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記メディア制御部は、９６キロバイトの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記ファイルの末尾を含む部分削除の範囲の指定を受け取るときには、前記ファイルの末尾から、前記部分削除の範囲内であって、かつ前記パケットサイズの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記部分削除の範囲内であって、前記データストリームの不完全な再生単位のデータを削除してもよい。
本発明によるチップ回路は、メディアに書き込まれたコンテンツを編集する処理を行うためにデータ処理装置に実装される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部を備えている。前記チップ回路は、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを特定する処理と、特定された前記データを削除する指示を出力する処理とを実行する。
本発明によるコンピュータプログラムは、メディアに書き込まれたコンテンツを編集する処理を行うためのデータ処理装置において実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記コンピュータプログラムを実行した前記データ処理装置は、前記ファイルの先頭を含む範囲の指定を受け取るステップと、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを実行する。
本発明によるデータ処理方法は、メディアに書き込まれたコンテンツを編集するために実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理方法は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取るステップと、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを包含する。
本発明によれば、メディア上のデータストリームの一部のデータを削除する際に、ファイルシステムのクラスタサイズとデータストリームのパケットサイズとの最小公倍数を基準として、その整数倍のデータ量のデータを削除する。クラスタサイズの整数倍とすることによってメディアに対するデータ削除処理がアクセス単位で実行でき、またパケットのパケットサイズの整数倍とすることによってデータ削除処理がパケット単位で実行できるため、処理を高速化できる。
また、データストリーム中に格納されていた再生単位のうち、データを削除した後のデータストリームにおいて初めて現れる再生単位までのデータ量の値を保持するため、削除処理において削除直後のピクチャをＩピクチャに変更する必要はない。よってＩピクチャへの変更に必要な処理を排除でき、編集処理時間を短縮できる。
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。
図１は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す。図１では、データ処理装置は、カムコーダ１００−１、カメラ付き携帯電話１００−２、ＰＣ１０８として記載されている。カムコーダ１００−１およびカメラ付き携帯電話１００−２は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして符号化し、そのデータストリームを、それぞれリムーバブルメディア１１２−１および１１２−２に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図１では、リムーバブルメディア１１２−２に複数のファイルが格納されていることが示されている。
各リムーバブルメディア１１２−１および１１２−２はデータ処理装置から取り外し可能であり、例えばＤＶＤ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）等の光ディスク、マイクロドライブ等の超小型ハードディスク、半導体メモリ等である。ＰＣ１０８は、各リムーバブルメディア１１２−１および１１２−２を装填することが可能なスロットを備えている。ＰＣ１０８は、装填されたリムーバブルメディア１１２−１、１１２−２からデータを読み出し、再生処理および編集処理等を実行する。
リムーバブルＨＤＤ１１２では、ＦＡＴ３２ファイルシステムによりデータ管理が行われる。ＦＡＴ３２ファイルシステムでは、１ファイルのファイルサイズの最大値は、例えば４ギガバイトである。よって、ＦＡＴ３２ファイルシステムではデータのサイズが４ギガバイトを超えるときは２以上のファイルに分けて書き込まれる。例えば、容量が８ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが２つ格納され得る。１６ギガバイトのリムーバブルＨＤＤ１１２には４ギガバイトのファイルが４つ格納され得る。なお、分割して書き込まれる単位はファイルサイズの最大値でなくてもよく、ファイルサイズの最大値以下のサイズであればよい。
以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込むデータ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに格納されたデータストリームを再生し編集するデータ処理装置はＰＣであるとして説明する。
さらに、リムーバブルメディア１１２−１は超小型のリムーバブルハードディスクであるとする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆動してデータの書き込みおよび読み出しを行うための機構（ドライブ機構）を含む。以下では、リムーバブルメディア１１２−１を「リムーバブルＨＤＤ１１２」と記述する。説明を簡便化するため、リムーバブルＨＤＤ１１２は４ギガバイトの容量を持つとする。この結果、４ギガバイトを超えるコンテンツは、２以上のリムーバブルＨＤＤに分けて書き込まれる。しかしながら、リムーバブルＨＤＤが４ギガバイト以上の容量を持ち、そこに４ギガバイトを超えるコンテンツが書き込まれる場合にも、２以上のファイルに分割して同じリムーバブルＨＤＤに書き込めばよい。１つのコンテンツが複数のファイルに分けて記録される本質的な点においては、いずれも同じである。単に記録するメディアが同一であるか否かの違いにすぎない。リムーバブルＨＤＤ１１２のクラスタサイズは、例えば３２キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際の最小のアクセス単位である。
図２は、カムコーダ１００の機能ブロックの構成を示す。カムコーダ１００には、複数のリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃを同時に装填することが可能であり、ユーザが撮影した映像および音声に関するコンテンツのデータストリーム（クリップＡＶストリーム）を、リムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに順に書き込む。
カムコーダ１００は、ＣＣＤ２０１ａ、マイク２０１ｂおよびデジタル放送を受信するデジタルチューナ２０１ｃと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、メディア制御部２０５と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、液晶表示装置（ＬＣＤ）２０９ａおよびスピーカ２０９ｂと、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、システム制御部２５０とを含む。
以下、各構成要素の機能を説明する。ＣＣＤ２０１ａおよびマイク２０１ｂは、それぞれ映像および音声のアナログ信号を受け取る。ＣＣＤ２０１ａは、映像をデジタル信号として出力する。マイク２０１ｂは、音声のアナログ信号を出力する。ＡＤコンバータ２０２は入力されたアナログ音声信号をデジタル信号に変換してＭＰＥＧ−２エンコーダ２０３に供給する。
デジタルチューナ２０１ｃは、アンテナ（図示せず）から１以上の番組が含まれるデジタル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。デジタルチューナ２０１ｃは、受信したトランスポートストリームから特定の番組（録画対象のチャンネルの番組）のパケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームであるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼ぶこともある。トランスポートストリームのデータ構造は、図３〜図５を参照しながら後述する。
本実施形態においては、カムコーダ１００はデジタルチューナ２０１ｃを構成要素としているが、これは必須の要件ではない。図２のカムコーダ１００の構成は、図１において言及したカメラ付き携帯電話１００−２等にも適用できるため、デジタル放送の受信および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。
ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給された映像および音声の各デジタルデータをＭＰＥＧ規格に基づいて圧縮符号化する。本実施形態においては、エンコーダ２０３は、映像データをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリーム（以下「ＴＳ」とも記述する）を生成し、ＴＳ処理部２０４に送る。この処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。エンコーダ２０３は双方向圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。なお、映像および音声の符号化形式を一致させる必要はない。例えば、映像はＭＰＥＧ形式で圧縮符号化し、音声はＡＣ−３形式で圧縮符号化するとしてもよい。
本実施形態では、カムコーダ１００はＴＳを生成し処理する。そこでまず、図３〜図５を参照しながら、ＴＳのデータ構造を説明する。
図３は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮符号化されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、符号化されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。
以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図４（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、一般に４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図４（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、一般に４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。ＴＳパケットヘッダにはアダプテーションフィールドと呼ばれるデータを追加してもよく、ＴＳパケットに格納するデータをアライメントする場合などに利用される。この場合ＴＳパケットのペイロード（３０ｂ、３１ｂ）は１８４バイト未満となる。
上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは“０ｘ００２０”であり、オーディオＴＳパケットのＰＩＤは“０ｘ００２１”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図５（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図５（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。
ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図５（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。
ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図５（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
図５（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ ｐｉｃｔｕｒｅ）などを表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、例えば“００１ｂ”などと決められている。
ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図５（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。
ＴＳに基づいて映像を再生する際、カムコーダ１００はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をＬＣＤ２０９ａ上に再生することができる。
上述のエンコーダ２０３は、映像コンテンツに関しては図５（ｄ）、（ｃ）、（ｂ）および（ａ）に示す順序でＴＳを生成するといえる。
次に、カムコーダ１００のＴＳ処理部２０４（図２）を説明する。ＴＳ処理部２０４は、動画の記録時にはエンコーダ２０３からＴＳを受け取り、またはデジタル放送番組の録画時にはデジタルチューナ２０１ｃからＴＳを受け取って、クリップＡＶストリームを生成する。クリップＡＶストリームとは、リムーバブルＨＤＤ１１２ａ等への格納のために所定の形式を有するデータストリームである。本明細書では、リムーバブルＨＤＤに格納されたクリップＡＶストリームのファイルには拡張子ＴＴＳ（“Ｔｉｍｅｄ ＴＳ”を意味する）を付している。クリップＡＶストリームは、到着時刻情報を付加したＴＳとして実現される。また、ＴＳ処理部２０４は、コンテンツの再生時には、リムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームをメディア制御部２０５から受け取り、そのクリップＡＶストリームに基づいてＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。
以下では図６を参照しながら、ＴＳ処理部２０４の処理に関連するクリップＡＶストリームを説明する。図６は、クリップＡＶストリーム６０のデータ構造を示す。クリップＡＶストリーム６０は、複数のＴＴＳパケット６１から構成される。ＴＴＳパケット６１は、４バイトのＴＴＳヘッダ６１ａと、１８８バイトのＴＳパケット６１ｂとから構成される。すなわちＴＴＳパケット６１は、ＴＴＳヘッダ６１ａをＴＳパケット６１ｂに付加して生成される。なおＴＳパケット６１ｂは、図３、図４（ａ）および（ｂ）等に関連して説明したＴＳパケットである。
ＴＴＳヘッダ６１ａは、２ビットの予約領域６１ａ−１と、３０ビットの到着時刻情報（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ；ＡＴＳ）６１ａ−２とから構成されている。この到着時刻情報６１ａ−２は、エンコーダ２０３から出力されたＴＳパケットがＴＳ処理部２０４に到着した時刻を示している。ＴＳ処理部２０４は、この時刻に基づいてデコーダ２０６にＴＳパケットを出力する。
次に、上述のクリップＡＶストリーム６０を生成するＴＳ処理部２０４の構成を説明する。図７は、ＴＳ処理部２０４の機能ブロックの構成を示す。ＴＳ処理部２０４は、ＴＴＳヘッダ付加部２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ＴＴＳヘッダ除去部２６５とを有する。
ＴＴＳヘッダ付加部２６１は、ＴＳを受け取り、そのＴＳを構成するＴＳパケットの前にＴＴＳヘッダを付加し、ＴＴＳパケットとして出力する。ＴＴＳヘッダ中の到着時刻情報６１ａ−２に記述されるＴＳパケットの到着時刻は、ＴＴＳヘッダ付加部２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。
クロックカウンタ２６２およびＰＬＬ回路２６３は、ＴＴＳヘッダ付加部２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、ＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がカムコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）として設定され、ＳＴＣが基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてＴＴＳヘッダ付加部２６１に出力する。
バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたＴＴＳパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、後述のメディア制御部２０５に出力する。このとき出力される一連のＴＴＳパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、メディア制御部２０５によってリムーバブルＨＤＤ１１２ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ＴＴＳパケット単位で出力する。
ＴＴＳヘッダ除去部２６５は、ＴＴＳパケットを受け取って、ＴＴＳヘッダを除去することによりＴＴＳパケットをＴＳパケットに変換し、ＴＳとして出力する。留意すべきは、ＴＴＳヘッダ除去部２６５は、ＴＴＳヘッダに含まれているＴＳパケットの到着時刻情報ＡＴＳを抽出して、到着時刻情報ＡＴＳとクロックカウンタ２６２から与えられるタイミング情報とに基づいて、元の到着時刻に対応するタイミング（時間間隔）でＴＳパケットを出力することである。リムーバブルＨＤＤ１１２ａ等はランダムアクセスが可能であり、データは不連続にディスク上に配列される。よって、ＴＳパケットの到着時刻情報ＡＴＳを利用すれば、ＴＳ処理部２０４は、データの格納位置にかかわらず記録時のＴＳパケットの到着タイミングと同じタイミングでＴＳパケットを出力することができる。なおＴＴＳヘッダ除去部２６５は、読み出したＴＳの基準時刻を指定するために、例えば最初のＴＴＳパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
カムコーダ１００では、ＴＳ処理部２０４を設けて、ＴＳにＴＴＳヘッダを付加してクリップＡＶストリームを生成するとした。しかし、符号化レートが固定されているＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）で符号化する場合には、ＴＳパケットのデコーダ入力時刻が固定間隔であるため、ＴＳ処理部２０４を省略してＴＳをリムーバブルＨＤＤ１１２に書き込むこともできる。
再び図２を参照しながら、カムコーダ１００の各構成要素を説明する。
メディア制御部２０５は、ＴＳ処理部２０４からクリップＡＶストリームを受け取り、いずれかのリムーバブルＨＤＤ１１２ａ、１１２ｂ、・・・、１１２ｃに出力するかを決定して、そのリムーバブルＨＤＤに出力する。メディア制御部２０５は、書き込み中のリムーバブルＨＤＤの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときには出力先を他のリムーバブルＨＤＤに変更し、クリップＡＶストリームの出力を継続する。このとき、１つのコンテンツを構成するクリップＡＶストリームが２つのリムーバブルＨＤＤ１１２に跨って格納されることになる。
メディア制御部２０５は、本発明の主要な特徴の１つであるクリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）テーブルを生成する。そしてそのテーブルに、クリップＡＶストリームの再生単位であるキーピクチャユニットが、２つのファイルに跨って格納されているか否かを示すフラグを記述する。なお、メディア制御部２０５のより詳細な動作、および、メディア制御部２０５によって生成されるクリップタイムラインテーブルの詳細なデータ構造は後述する。
なお、クリップＡＶストリームをリムーバブルＨＤＤ１１２に書き込む処理は、メディア制御部２０５から書き込み指示およびクリップＡＶストリームを受け取ったリムーバブルＨＤＤ１１２が行っている。また、クリップＡＶストリームを読み出す処理は、メディア制御部２０５から読み出し指示を受けたリムーバブルＨＤＤ１１２が行っている。しかし、説明の便宜のため、以下ではメディア制御部２０５がクリップＡＶストリームを書き込み、読み出すとして説明する。
ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたＴＳを解析して、ＴＳパケットから映像および音声の圧縮符号化データを取得する。そして、映像の圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。またデコーダ２０６は、音声の圧縮符号化データを伸長して音声信号を生成し、音声信号をスピーカ２０９ｂに出力する。デコーダ２０６は、ＴＳに関してＭＰＥＧ規格で規定されているシステムターゲットデコーダ（Ｔ−ＳＴＤ）の要件を満たすように構成されている。
グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成した映像信号を出力することができる。液晶表示装置（ＬＣＤ）２０９ａは、グラフィック制御部２０７から出力された映像信号をＬＣＤ上に表示する。スピーカ２０９ｂは、音声信号を音として出力する。コンテンツは、ＬＣＤ２０９ａおよびスピーカ２０９ｂを介して再生され、視聴の対象となる。なお、映像信号および音声信号の出力先は、それぞれＬＣＤ２０９ａおよびスピーカ２０９ｂに限られない。例えば映像信号および音声信号は、外部出力端子（図示せず）を経てカムコーダ１００と別体のテレビやスピーカに伝送されてもよい。
ＣＰＵバス２１３はカムコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。
ネットワーク制御部２１４は、カムコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェイスであり、例えば、イーサネット(登録商標)規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。例えば、ネットワーク制御部２１４は、撮影され生成されたクリップＡＶストリームをネットワーク１０１を介して放送局に伝送してもよい。または、ネットワーク制御部２１４は、カムコーダ１００の動作を制御するためのソフトウェアプログラムが更新されたときは、更新されたプログラムをネットワーク１０１を介して受け取ってもよい。
指示受信部２１５は、カムコーダ１００の本体部に設けられた操作ボタンである。指示受信部２１５は、ユーザから、例えば録画の開始／停止、再生の開始／停止等の指示を受け取る。
インターフェース（Ｉ／Ｆ）部２１６は、カムコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ１００は、ＵＳＢ２．０規格またはＩＥＥＥ１３９４規格の端子を介してＰＣ１０８や、他のカムコーダ（図示せず）、ＢＤ／ＤＶＤレコーダ、ＰＣ等と接続される。
システム制御部２５０は、カムコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはカムコーダ１００を制御するためのソフトウェアプログラムが格納されている。
ＣＰＵ２１１は、カムコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ、カメラ、マイク等を利用して構成されたコンピュータシステムを、本実施形態によるカムコーダ１００と同等の機能を有する機器として動作させることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。
次に、図８（ａ）〜（ｃ）を参照しながら、カムコーダ１００において撮影された、映像および音声に関するコンテンツのデータ管理構造を説明する。図８（ａ）は、本実施形態における１コンテンツの概念を示す。撮影の開始から終了までの期間に得られたコンテンツを、１ショットという。図８（ｂ）は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。１ショット、すなわち１つのコンテンツは、複数のクリップａ〜ｃに分けて各リムーバブルＨＤＤ１１２ａ〜１１２ｃに格納することができる（１つのクリップで完結してもよい）。１つのクリップは、クリップメタデータ８１と、タイムマップ８２と、クリップＡＶストリーム８３の一部（部分ストリーム）とを含む。クリップＡＶストリーム８３は、部分ストリーム８３ａ〜８３ｃから構成されており、クリップａ〜ｃのそれぞれに含まれる。図８（ｂ）には３つのクリップａ〜ｃが記載されているが、各クリップの構成は共通しているため、ここではクリップａを例に挙げて説明する。
クリップａは、クリップメタデータａと、タイムマップａと、部分ストリームａとを含む。このうち、クリップメタデータａおよびタイムマップａは管理情報であり、部分ストリームａがクリップＡＶストリーム８３を構成するデータである。クリップＡＶストリーム８３は原則として１つのファイルに格納されるが、ＦＡＴ３２のファイルサイズの最大値を超えるときには複数のＴＴＳファイルに格納される。図８（ｂ）では、３つの部分ストリーム８３ａ、８３ｂおよび８３ｃが別個のファイルに格納される。なお本実施形態では、各部分ストリームのファイルサイズをＦＡＴ３２ファイルシステムにおけるファイルサイズの最大値（４ギガバイト）とすると、リムーバブルＨＤＤ１１２ａ〜ｃの記録可能容量がなくなって管理情報をリムーバブルＨＤＤ１１２に書き込みできなくなるため、各部分ストリームのファイルサイズは４ギガバイトよりも小さくなることに留意されたい。さらに、ＴＴＳファイルは整数個のＴＴＳパケットから構成されるとし、上記ファイルシステムからの制限である４ギガバイト未満であり、かつ、ＴＴＳパケット（１９２バイト）の整数倍としてもよい。
クリップメタデータａはＸＭＬ形式で記述されており、コンテンツの再生に必要な情報、例えば映像／音声フォーマット等が規定される。クリップメタデータａの詳細は、後に図１０を参照しながら詳述する。
タイムマップａは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」（ＣｌｉｐＴｉｍｅＬｉｎｅ）と呼び、クリップタイムラインが格納されたファイルの拡張子に“ＣＴＬ”を付して図示している。クリップタイムラインの詳細は、後に図１２〜１４を参照しながら詳述する。
部分ストリームａは、図６に示すように複数のＴＴＳパケットから構成される。
なお、１ショットの間にクリップＡＶストリーム８３が複数の部分ストリーム８３ａ〜８３ｃのファイルに格納されたときには、ＴＳパケットの転送タイミングを決定するＡＴＳのクロックカウンタ２６２（図７）がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ２６２（図７）は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。したがって、クリップＡＶストリーム８３を構成する各ＴＴＳパケット中の到着時刻情報ＡＴＳは、１つのショットを構成する連続する２つのＴＴＳファイルの境界において連続している。
図８（ｃ）は、３つのリムーバブルＨＤＤ１１２ａ〜１１２ｃを示す。各クリップａ〜ｃを構成するデータのファイルが各リムーバブルＨＤＤ１１２ａ〜１１２ｃに書き込まれる。
次に、リムーバブルＨＤＤ１１２内にファイルがどのように格納されるかを説明する。図９は、リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す。コンテンツの管理情報とクリップＡＶストリームのファイルは、最上層のルート（ＲＯＯＴ）９０内のコンテンツ（Ｃｏｎｔｅｎｔｓ）フォルダ９１以下に格納される。より具体的には、コンテンツフォルダ９１直下のデータベース（Ｄａｔａｂａｓｅ）フォルダ９２には、管理情報であるクリップメタデータ９４のＸＭＬ形式ファイル、および、クリップタイムライン９５のＣＴＬ形式ファイルが格納される。一方、コンテンツフォルダ９１直下のＴＴＳフォルダ９３には、クリップＡＶストリーム（ＴｉｍｅｄＴＳ）９６のＴＴＳ形式ファイルが格納される。
なお、コンテンツフォルダ９１には、さらにＭＸＦ形式の映像のストリームデータを格納するビデオフォルダ（Ｖｉｄｅｏ）、ＭＸＦ形式の音声のストリームデータを格納するオーディオフォルダ（Ａｕｄｉｏ）、ＢＭＰ形式のサムネイル画像を格納するアイコンフォルダ（Ｉｃｏｎ）、ＷＡＶＥ形式のボイスメモのデータを格納するボイスフォルダ（Ｖｏｉｃｅ）等が設けられてもよく、既存のカムコーダの記録フォーマット等に対応させることができる。
続いて、図１０〜１４を参照しながら、クリップメタデータ９４およびクリップタイムライン９５に記述されたデータの内容を説明する。
図１０は、クリップメタデータ９４に含まれる情報の内容を示す。クリップメタデータ９４は、構成データ（“Ｓｔｒｕｃｔｕｒａｌ”）および記述データ（“Ｄｅｓｃｒｉｐｔｉｖｅ”）の２種類に分類される。
構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ ＩＤｅｎｔｉｆｉｅｒ）が記述される。ＵＭＩＤは、例えば、コンテンツが生成された時刻とそれを生成した機器のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを組み合わせて生成される。さらにＵＭＩＤは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦ＵＭＩＤが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのＵＭＩＤとは異なる値が付加される。よってＵＭＩＤを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。
エッセンスリストには、映像および音声の復号化に必要な情報（ビデオ情報およびオーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はＭＰＥＧ−２方式である。
リレーション情報は、図８（ｂ）に示すような複数のクリップ８１ａ〜８１ｃが存在するときのクリップの間の関係を規定する。具体的には各クリップメタデータ９４には、そのショットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々に対応するクリップＡＶストリーム（部分ストリーム）の再生の先後関係または再生順序を規定しているということができる。クリップを特定する情報は、例えば、ＵＭＩＤおよびそのリムーバブルＨＤＤ１１２固有のシリアル番号とによって規定される。
記述データには、アクセス情報、デバイス、撮影情報、再生情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。再生情報は、再生開始時刻、再生時間長等を特定する情報である。
次に、クリップタイムライン９５を説明する。クリップタイムライン９５では、キーピクチャおよびキーピクチャユニットという概念を導入して、それらに関する情報を規定している。そこでまず図１１を参照しながら、キーピクチャおよびキーピクチャユニットを説明する。
図１１は、キーピクチャおよびキーピクチャユニットの関係を示す。図１１では、Ｉ、ＢおよびＰの各ピクチャを表示される順序で記載している。キーピクチャユニット（Ｋｅｙ Ｐｉｃｔｕｒｅ Ｕｎｉｔ；ＫＰＵ）は、映像に関して規定されるデータ再生単位である。図１１では、キーピクチャユニットＫＰＵの表示は、キーピクチャ４４から開始され、Ｂピクチャ４５において終了する。この間にはＭＰＥＧ規格のグループ・オブ・ピクチャ（ＧＯＰ）が１以上含まれている。Ｂピクチャ４５の次のＩピクチャ４６から、次のキーピクチャユニットＫＰＵの表示が始まる。各キーピクチャユニットの映像再生時間は、０．４秒以上、かつ、１秒以下である。ただし、１ショットの最後のキーピクチャユニットは１秒以下であればよい。撮影の終了タイミングによっては０．４秒に満たないこともあるからである。上記はＧＯＰ先頭のＩピクチャから再生が開始されるとしているが、Ｂピクチャから再生が開始されるＧＯＰ構造の場合には、この限りではない。ＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）は、そのＫＰＵに格納される全ピクチャの再生時間を示しているためである。
キーピクチャユニットの先頭に位置するキーピクチャ４４、４６は、ＭＰＥＧ規格におけるシーケンスヘッダコード（ｓｅｑｕｅｎｃｅ＿ｈｅａｄｅｒ＿ｃｏｄｅ）およびグループスタートコード（ｇｒｏｕｐ＿ｓｔａｒｔ＿ｃｏｄｅ）を含むビデオに関するアクセス単位である。例えば、キーピクチャユニットはＭＰＥＧ２圧縮符号化されたＩピクチャの画像（フレーム画像または１組の２フィールド画像）または、圧縮符号化されたＩフィールドおよびＰフィールドの画像である。
また本実施形態では、ＴＳに付加されたＰＴＳを用いてＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）を定義している。ＫＰＵ期間は、次のキーピクチャユニットＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）と、そのＫＰＵの中で最初に表示されるピクチャの表示時刻（ＰＴＳ）との差分値である。図１１では、キーピクチャ４４の時刻をＰＴＳ（Ｎ）とし、キーピクチャ４６の時刻をＰＴＳ（Ｎ＋１）としたとき、ＫＰＵ期間（Ｎ）は、ＰＴＳ（Ｎ＋１）−ＰＴＳ（Ｎ）として定義される（ともにキーピクチャが表示開始ピクチャとなっている場合）。なお、ＫＰＵ期間の定義から明らかなように、あるＫＰＵ期間の値を決定するためには、次のキーピクチャユニットＫＰＵのピクチャが圧縮符号化され、最初に表示されるピクチャの再生時刻（ＰＴＳ）が確定しなければならない。よって、あるキーピクチャユニットＫＰＵに対するＫＰＵ期間は、次のキーピクチャユニットの生成が開始された後に定まる。なお、ショットで最後のＫＰＵ期間が必要な場合もあるため、符号化したピクチャの表示時間を積算していく方法も可能である。その場合には、次のＫＰＵの生成開始を待たずともＫＰＵ期間を決定することが可能である。
次に、図１２（ａ）〜（ｃ）を参照しながら、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）を説明する。図１２（ａ）は、クリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す。クリップタイムライン９５は、拡張子に“ＣＴＬ”を有するファイルとして各リムーバブルＨＤＤ１１２に書き込まれる。
クリップタイムライン９５は、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。「再生単位」は、上述のキーピクチャユニットＫＰＵに対応する。
クリップタイムライン９５には、複数のフィールドが規定されている。例えば、クリップタイムライン９５には、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａ、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂ、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃ、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄ、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅ、ＳｔａｒｔＳＴＣフィールド９５ｆ、ＴｉｍｅＥｎｔｒｙフィールド９５ｇ、ＫＰＵＥｎｔｒｙフィールド９５ｈ等を含む。各フィールドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定している。
例えば、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａにはタイムエントリの数が記述され、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂにはＫＰＵエントリの数が記述される。ただしＴｉｍｅＥｎｔｒｙフィールド９５ｇおよびＫＰＵＥｎｔｒｙフィールド９５ｈは、後述のタイムエントリの数およびＫＰＵエントリの数に応じてデータサイズが変動し得る。
図１２（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示す。ＴｉｍｅＥｎｔｒｙフィールド９５ｇには、対応するタイムエントリに関する属性を示す情報が複数のフィールド（ＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａ、ＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂおよびＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃ）に記述されている。
また、図１２（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す。ＫＰＵＥｎｔｒｙフィールド９５ｈには、対応するキーピクチャユニットＫＰＵに関する属性を示す情報が複数のフィールド（ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ、ＫｅｙＰｉｃｔｕｒｅＳｉｚｅフィールド９８ｂ、ＫＰＵＰｅｒｉｏｄフィールド９８ｃおよびＫＰＵＳｉｚｅフィールド９８ｄ）に記述されている。
ここで、図１３（ａ）および（ｂ）を参照しながら、クリップタイムライン９５に含まれる主要なフィールドに規定されるデータの意味を説明する。
図１３（ａ）は、タイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ａ）の横軸の１目盛りは１アクセスユニット時間（Ａｃｃｅｓｓ Ｕｎｉｔ ＴｉＭｅ；ＡＵＴＭ）を示している。これは１ピクチャの表示時間に対応する。ここでいう「ピクチャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プログレッシブビデオに対しては１枚のプログレッシブ走査のフレーム画像に対応し、インターレースビデオに対してはインターレース走査のフィールド画像（１フィールド）に対応する。例えば２４０００／１００１秒間隔で表示されるプログレッシブビデオ（つまり２３．９７ｐ）では、１ＡＵＴＭは１／（２４０００／１００１） 秒 ＝ １１２６１２５ ｃｌｏｃｋｓ／２７ＭＨｚと表記される。
ここでまず、１ショットにｎ個のクリップが含まれるとしたときの時間の関係を説明する。まず各クリップの再生時間長は、それぞれのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅに記述される。この値はＡＵＴＭを利用して記述される。すべてのクリップについてのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値の和を計算すると、１ショットの再生時間長（撮影時間長）が得られる（数１）。この時間長もまた、ＡＵＴＭを利用して記述される。
（数１）
１ショットの再生時間長＝ΣＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ
一方、図１３（ａ）に示すＫＰＵ＃０から＃（ｋ＋１）までが１クリップに含まれるとすると、上述の各クリップのＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅは、そのクリップに含まれる全てのキーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値の総和として得られる（数２）。上述のように、ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）はＡＵＴＭ値を用いて表記されるため、ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅもＡＵＴＭ表記である。
（数２）
ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ＝ΣＫＰＵｐｅｒｉｏｄ
各ＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）フィールド９８ｃの値は、上述のとおり、そのキーピクチャユニットＫＰＵに含まれるピクチャのビデオ表示時間（ＡＵＴＭ値）の和に対応する（数３）。
（数３）
ＫＰＵｐｅｒｉｏｄ＝ＫＰＵ内のビデオ総表示時間
「タイムエントリ」（ＴｉｍｅＥｎｔｒｙ）とは、一定の固定時間（例えば５秒）ごとに設定され、その位置から再生を開始することが可能な時間軸上の飛び込み点を示す。タイムエントリの設定に関連して、先頭のキーピクチャユニットＫＰＵ＃０の再生開始時刻を０としたとき、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。また、各タイムエントリの設定時刻に再生されるキーピクチャユニットＫＰＵを識別する情報がＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａに記述され、そのキーピクチャユニットＫＰＵの先頭からそのタイムエントリの設定時刻までの時間オフセットを示す情報がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃに記述される。
例えば、タイムエントリ＃ｔが指定されると、（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）＋（タイムエントリの間隔・ｔ）を計算することにより、そのタイムエントリ＃ｔが設定された時刻、すなわち先頭キーピクチャユニットＫＰＵ＃０の先頭からの経過時間を得ることができる。
また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。すなわち、ユーザから再生を開始したい時刻の指定を受け取ると、その時刻は、周知の変換処理を利用してＭＰＥＧ規格上の時間情報であるＰＴＳ値に変換される。そして、そのＰＴＳ値が割り当てられたピクチャから、再生が開始される。なおＰＴＳ値は、ビデオＴＳパケット（Ｖ＿ＴＳＰ）３０のトランスポートパケットヘッダ３０ａ（図４（ａ））内に記述されている。
本実施形態では、１つのクリップＡＶストリームが複数の部分ストリームに分けられているため、各クリップ内の部分ストリーム先頭の再生開始時刻（ＰＴＳ）が０でないことがある。そこで、クリップタイムライン９５のＳｔａｒｔＳＴＣフィールド９５ｆ（図１２（ａ））には、そのクリップ内の先頭ＫＰＵの中で最初に表示されるピクチャの再生時刻情報（ＰＴＳ）が記述されている。そのピクチャのＰＴＳ値と指定された時刻に対応するＰＴＳ値とに基づいて、再生開始すべきピクチャまでのＰＴＳ（ＡＵＴＭ）差分値が得られる。なお、各ピクチャに割り振られているＰＴＳ値のデータ量と、ＳｔａｒｔＳＴＣフィールド９５ｆに規定されているＰＴＳ値のデータ量とを一致させることが好ましく、例えば３３ビットで表記される。
上述の差分値がＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎフィールド９５ｅの値よりも大きければ、再生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に存在すると判断できる。後者のときは、さらにそのＰＴＳ差分値に基づいて、どの程度先の時刻かも容易に特定できる。
図１３（ｂ）は、ＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す。図１３（ｂ）の横軸の１目盛りは１データユニット長（Ｔｉｍｅｄ ＴＳ Ｐａｃｋｅｔ Ｂｙｔｅ Ｌｅｎｇｔｈ；ＴＰＢＬ）を示している。これは１データユニットがＴＴＳパケットのデータ量（１９２バイト）と等しいことを意味する。
各ＫＰＵエントリは、各キーピクチャユニットＫＰＵに対して１つ設けられている。ＫＰＵエントリの設定に関連して、各ＫＰＵのデータサイズがＫＰＵＳｉｚｅフィールド９８ｄに記述され、各タイムエントリごとに対応するＫＰＵの開始アドレスがＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂに記述される。なお、各キーピクチャユニットＫＰＵのデータサイズは、例えば図１３（ｂ）のＫＰＵｓｉｚｅ＃ｋに示すように、そのＫＰＵの中で最初のピクチャのデータを格納した最初のＴＴＳパケットから、次のＫＰＵの最初のピクチャを格納したＴＴＳパケット直前のＴＴＳパケットまでのデータサイズを１データユニット長（ＴＰＢＬ）で示して表される。
さらにＫＰＵエントリには、ファイルの最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定されている。このフィールドを設ける理由は以下のとおりである。例えば１ショットのクリップＡＶストリームのデータが複数のファイルに分けて格納されたとき、２番目以降のファイルの先頭には先のファイル最後尾のＫＰＵの一部が格納されることがある。キーピクチャユニットＫＰＵ内の各ピクチャは、ＫＰＵ先頭のキーピクチャから復号化をしなければならないため、ファイルの先頭に存在するデータは単独で復号化できない。よってそのようなデータは、意味のないデータ（フラグメント）として読み飛ばすことが必要になる。そこで上述のオフセットフィールド９５ｄにそのオフセット値を利用して、読み飛ばしを可能にしている。
ここで、図１４を参照しながら、１ショットのクリップＡＶストリームデータが複数のファイルに分けて格納されたときのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａ等を説明する。説明の簡単のために、ここでは１ショットのコンテンツに関する管理情報とクリップＡＶストリームとが、２つのリムーバブルＨＤＤ＃１および＃２に格納されるとして説明し、またクリップメタデータには言及しない。
図１４は、２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す。リムーバブルＨＤＤ＃１および＃２には、それぞれクリップタイムラインのファイル（００００１．ＣＴＬおよび００００２．ＣＴＬ）と、クリップＡＶストリームのファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）とが格納されている。
以下では、ＫＰＵエントリに注目する。まず、リムーバブルＨＤＤ＃１上のＫＰＵエントリ＃（ｄ−１）は、００００１．ＴＴＳ内のクリップＡＶストリームに規定されるキーピクチャユニットＫＰＵ＃（ｄ−１）に対応して設けられている。図１４に示すように、キーピクチャユニットＫＰＵ＃（ｄ−１）のすべてのデータは、００００１．ＴＴＳ内に存在している。その場合には、ＫＰＵエントリ＃（ｄ−１）のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。
次に、ＫＰＵエントリ＃ｄおよび対応するキーピクチャユニットＫＰＵ＃ｄに着目する。図１４に示すキーピクチャユニットＫＰＵ＃ｄは、その一部（キーピクチャユニットＫＰＵ＃ｄ１）がリムーバブルＨＤＤ＃１の００００１．ＴＴＳ内に存在し、他の一部（キーピクチャユニットＫＰＵ＃ｄ２）がリムーバブルＨＤＤ＃２の００００２．ＴＴＳ内に存在している。キーピクチャユニットＫＰＵ＃ｄが２つのリムーバブルＨＤＤに分けて格納されている理由は、例えばリムーバブルＨＤＤ＃１への書き込み中に、記録可能な残り容量が所定値以下になり、それ以上の書き込みが不可能になったためである。この場合には、ＫＰＵエントリ＃ｄのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには１ｂが設定される。
なお、リムーバブルＨＤＤ＃２内のＫＰＵエントリ＃０に対応するキーピクチャユニットＫＰＵは、そのすべてのデータがリムーバブルＨＤＤ内に格納されているから、そのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａには０ｂが設定される。
上述のようにＫＰＵエントリ内のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を調べることにより、そのキーピクチャユニットＫＰＵがそのメディア内のファイルに格納されているか否かが判断できる。この利点は、例えば以下の処理において非常に効果的である。
図１４に示すように、ＫＰＵ＃ｄを構成するデータが複数のＴＴＳファイル（００００１．ＴＴＳおよび００００２．ＴＴＳ）に跨って格納されているときにおいて、リムーバブルＨＤＤ＃２内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムーバブルＨＤＤ＃１に格納されたデータのみに基づいて１ショットの再生が行われる。
編集処理によって１ショットの再生時間が変化するため、正確な再生時間を算出する必要がある。そこで、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に基づいて再生時間の算出処理を変化させることができる。
以下に、再生が保証されているピクチャまでの再生時間を算出する処理（１）と、現実に再生可能なピクチャまでの再生時間を算出する処理（２）とを説明する。例えば、処理（１）は個人ユーザ向けの機器に実装され、処理（２）は業務ユーザ向けの機器に実装される。
まず、上述の処理（１）から説明する。編集処理が行われた後のリムーバブルＨＤＤ＃１内の最後のＫＰＵ＃ｄに関しては、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値は“１ｂ”である。このときは、先頭からＫＰＵ＃（ｄ−１）までのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和を、リムーバブルＨＤＤ＃１内のクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用する。換言すれば、上述の数２においてキーピクチャユニットＫＰＵ＃ｄのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の値はクリップの再生時間として算入しない。その理由は、実際に再生可能な時間（最初のＫＰＵからＫＰＵ＃（ｄ−１）まで）と数２に基づいて算出した１ショットの再生時間（最初のＫＰＵからＫＰＵ＃ｄまで）との間には、最後のＫＰＵ＃ｄ相当の再生時間（０．４秒以上１秒未満）だけ誤差が発生し得るからである。この算出方法によれば、再生が保証されている映像の再生時間が把握できる。
次に、上述の処理（２）を説明する。処理（１）においては、データが存在するＫＰＵ＃ｄ１の再生時間は考慮されていない。しかし、ＫＰＵ＃ｄ１内のデータに基づいて再生可能なピクチャが存在し得るため、処理（１）によって算出される再生時間は厳密には誤差が含まれうる。機器から提示された再生時間がこのような誤差を含むことは、特に業務用途や特殊用途の機器においてはあってはならないケースが想定される。そこで、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”の時には、フレーム／フィールド単位で連続して再生できるビデオ再生時間をＫＰＵ＃ｄ１を解析して求めればよい。その再生時間を処理（１）によって得られる再生時間に加算することによって、クリップの再生時間を非常に正確に求めることができる。
なお、リムーバブルＨＤＤ＃１内の最後のＫＰＵに対応するＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“０ｂ”のときは、先頭から最後までの各キーピクチャユニットＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）の和をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の値として採用すればよい。最後のキーピクチャユニットＫＰＵ内の全てのピクチャが再生可能であるため、そのＫＰＵのＫＰＵ期間（ＫＰＵｐｅｒｉｏｄ）をクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）に算入すべきだからである。
以上説明したように、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値に応じてクリップの再生時間（ＣｌｉｐＴｉｍｅＬｉｎｅＤｕｒａｔｉｏｎ９５ｅ）の算出する処理を変化させることにより、常に正確な再生時間長を算出できる。
また、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値を利用して不完全なキーピクチャユニットＫＰＵを削除するか否かを決定し、削除したときには残されたクリップについてクリップタイムラインを修正してもよい。この「不完全なキーピクチャユニット」とは、全てのピクチャのデータが存在しないキーピクチャユニットをいい、ここではＫＰＵ＃ｄ２が存在しないＫＰＵ＃ｄに相当する。
具体的に説明すると、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”のときには、不完全なキーピクチャユニットＫＰＵ＃ｄ１をキーピクチャユニットＫＰＵとして取り扱わないように、ＴＴＳファイルから削除し、リムーバブルＨＤＤ＃１内のクリップタイムラインを修正すればよい。クリップタイムラインの修正は、キーピクチャユニットＫＰＵの数（ＫＰＵＥｎｔｒｙＮｕｍｂｅｒ９５ｂ）を減少させること、ＫＰＵ＃ｄのＫＰＵエントリを削除すること、キーピクチャユニットＫＰＵ＃ｄ１内のタイムエントリ（ＴｉｍｅＥｎｔｒｙ）９５ｇを削除すること等を含む。修正後は、リムーバブルＨＤＤ＃１の００００１．ＴＴＳファイルの最後のキーピクチャユニットはＫＰＵ＃（ｄ−１）になり、最初のＫＰＵから最後のＫＰＵ＃（ｄ−１）までの再生時間の和が１ショットの再生時間になる。よって、上述の数１〜数３を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削除はＦＡＴ３２ファイルシステム上においても、ＴＴＳパケット（１９２バイト）単位で可能である。
なお、キーピクチャユニットＫＰＵ＃ｄ２は、リムーバブルＨＤＤ＃２内ではフラグメントであり、そのデータのみではビデオは復号化できない。よって、リムーバブルＨＤＤ＃２内のクリップＡＶストリームファイル（００００２．ＴＴＳ）の最初から、キーピクチャユニットＫＰＵ＃０の先頭までのフラグメント（データオフセット）がＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに設定される。さらに、そのキーピクチャユニットＫＰＵ＃０の先頭から、最初に設定されたタイムエントリ＃０までの時間オフセットがＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに設定される。なお、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０でないときは、前のリムーバブルＨＤＤからのキーピクチャユニットＫＰＵが格納されていることを表すため、巻き戻し再生時にはまず、クリップメタデータ９４のリレーション情報を参照することで、直前のクリップがあるか否かを特定することができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能であった場合には、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値が０か否かを確認し、０でないときに前のリムーバブルＨＤＤの最後のキーピクチャユニットＫＰＵに対応するＫＰＵエントリのＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値をさらに確認して、キーピクチャユニットＫＰＵの跨ぎが発生しているか否かを確実に判定することもできる。
次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用してコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集する際の処理を説明する。
まず図１５および図１６を参照しながら、コンテンツをリムーバブルＨＤＤに録画するときのカムコーダ１００の処理（録画処理）を説明する。
図１５は、カムコーダ１００によるコンテンツの録画処理の手順を示す。まずステップＳ１５１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから撮影開始の指示を受け取る。そして、ステップＳ１５２において、ＣＰＵ２１１からの指示に基づいて、エンコーダ２０３は入力信号に基づいてＴＳを生成する。なおデジタル放送の録画時には、ステップＳ１５１において録画開始の指示を受け取り、ステップＳ１５２においてデジタルチューナ２０１ｃを用いて録画対象の番組のＴＳパケットを抽出すると読み替えればよい。
ステップＳ１５３では、メディア制御部２０５は、ＴＳ処理部２０４においてＴＴＳヘッダが付加されたＴＳ（クリップＡＶストリーム）を、順次リムーバブルＨＤＤに書き込む。そしてメディア制御部２０５は、ステップＳ１５４において、クリップ（ＴＴＳファイル）を新規に作成するか否かを判断する。新規に作成するか否かは、記録中のクリップのＴＴＳファイルのサイズが所定値よりも大きいか否かや、リムーバブルＨＤＤの残容量に応じて任意に決定できる。新規にクリップを作成しない場合はステップＳ１５５に進み、新規にクリップを生成するときはステップＳ１５６に進む。
ステップＳ１５５では、ＴＳ処理部２０４は、キーピクチャユニットＫＰＵが生成されるごとに、ＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵのすべてのデータはそのクリップのＴＴＳファイル内に書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“０ｂ”を設定する。そしてメディア制御部２０５は、ステップＳ１５７においてＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）をリムーバブルメディアに書き込む。その後、ステップＳ１５８において、ＣＰＵ２１１は撮影終了か否かを判断する。撮影は、例えば指示受信部２１５を介して撮影終了指示を受信したとき、次にデータを書き込むべきリムーバブルＨＤＤが存在しないとき等に終了する。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はステップＳ１５２に戻り、それ以降の処理が繰り返される。
一方ステップＳ１５６では、ＴＳ処理部２０４は、最後に書き込まれたデータによってキーピクチャユニットＫＰＵが完結したか否かを判断する。仮にキーピクチャユニットＫＰＵが完結しなければ、そのキーピクチャユニットＫＰＵの残りのデータは他のリムーバブルＨＤＤに格納されることになる。そのため、キーピクチャユニットＫＰＵのすべてのデータがそのリムーバブルＨＤＤ内に書き込まれたか否かを判断するために、このような判断が必要になる。キーピクチャユニットＫＰＵが完結しているときには処理はステップＳ１５５に進み、完結していないときには処理はステップＳ１５９に進む。
ステップＳ１５９では、ＴＳ処理部２０４によってクリップ切り替え処理が行われる。この処理の具体的な内容を、図１６に示す。
図１６は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ（クリップ）の録画先のメディアを、あるリムーバブルＨＤＤから他のリムーバブルＨＤＤに切り替えたり、同一リムーバブルＨＤＤ上で新規クリップを生成する処理である。以下では説明を簡略化するために、クリップの切り替えが、コンテンツの録画先メディアの変更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブルＨＤＤを「第１リムーバブルＨＤＤ」と呼び、次にコンテンツが録画されるリムーバブルＨＤＤを「第２リムーバブルＨＤＤ」と呼ぶ。
まずステップＳ１６１において、ＣＰＵ２１１は、第２リムーバブルＨＤＤ上に生成されるクリップのクリップ名を決定する。次に、ステップＳ１６２において、カムコーダ１００は第１リムーバブルＨＤＤに完全に記録できなかったキーピクチャユニットＫＰＵが完結するまでＴＳを生成する。そして、ＴＳ処理部２０４はＴＴＳヘッダを付加し、メディア制御部２０５はそのクリップＡＶストリームを第２リムーバブルＨＤＤに書き込む。
次にステップＳ１６３において、メディア制御部２０５は、完結したＫＰＵのＫＰＵエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットＫＰＵは第１リムーバブルＨＤＤおよび第２リムーバブルＨＤＤに跨って書き込まれるため、メディア制御部２０５はＫＰＵエントリ中のＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドに“１ｂ”を設定する。
ステップＳ１６４において、メディア制御部２０５は、生成したＫＰＵエントリおよびタイムエントリを含む時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を、第１リムーバブルＨＤＤに書き込む。そして、ステップＳ１６５において、第１リムーバブルＨＤＤ上のクリップ・メタデータ（リレーション情報等）を更新する。例えば、メディア制御部２０５は、第１リムーバブルＨＤＤ上のクリップのクリップメタデータに、次のクリップとして第２リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。また、第２リムーバブルＨＤＤ上のクリップのクリップメタデータに、前のクリップとして第１リムーバブルＨＤＤ上のクリップを特定するＵＭＩＤ等を書き込む。その後、ステップＳ１６６において、メディア制御部２０５は、今後のコンテンツの書き込み先を第２リムーバブルＨＤＤに設定し、処理が終了する。
次に、図１７を参照しながら、カムコーダ１００がリムーバブルＨＤＤからコンテンツを再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初から再生するときの処理は、ＫＰＵエントリ、タイムエントリ等を設けない従来の処理と同じであるため、その説明は省略する。
図１７は、カムコーダ１００によるコンテンツの再生処理の手順を示す。ステップＳ１７１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザから再生開始時刻の指示を受け取る。
ステップＳ１７２において、メディア制御部２０５は時間・アドレス変換テーブル（クリップタイムラインＣｌｉｐＴｉｍｅＬｉｎｅ）を読み出して、ＣＰＵ２１１が再生開始時刻のピクチャを含むキーピクチャユニット（ＫＰＵ）を特定する。そして、ステップＳ１７３において、ＣＰＵ２１１は、再生開始時刻に対応するＫＰＵの開始位置を特定する。このＫＰＵの開始位置は、ＴＴＳファイル内の復号開始位置（アドレス）を表している。
これらの処理の一例は以下のとおりである。すなわち、ＣＰＵ２１１は、再生開始時刻がタイムエントリ＃ｔとタイムエントリ＃（ｔ＋１）の間の時刻であることを特定し、さらにタイムエントリ＃ｔから起算してｍアクセスユニット時間（ＡＵＴＭ）を１単位として何単位離れているかを特定する。
具体的には、まずタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤフィールド９７ａの値に基づいて、あるＫＰＵ（ＫＰＵ＃ｋとする）が特定される。そして、タイムエントリ＃ｔが指し示す時刻からＫＰＵ＃ｋの先頭キーピクチャの再生が開始されるまでの時間差がＴｉｍｅＥｎｔｒｙＴｉｍｅＯｆｆｓｅｔフィールド９７ｃの値に基づいて取得される。その結果、再生開始すべきピクチャがＫＰＵ＃ｋの中で最初に表示されるピクチャから何ＡＵＴＭ後か判明する。すると、ＫＰＵ＃ｋからＫＰＵごとにＫＰＵ期間（ＫＰＵＰｅｒｉｏｄ）を加算していくことで、再生開始すべきピクチャを含むＫＰＵが特定できる。また、タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレスにＫＰＵ＃ｋから再生開始すべきピクチャを含むＫＰＵの直前のＫＰＵまでのＫＰＵＳｉｚｅを加算していくことで、再生開始時刻に対応するＫＰＵの開始位置を特定できる。なお、「タイムエントリ＃ｔが指し示すＫＰＵの先頭アドレス」は、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値とタイムエントリ＃ｔのＫＰＵＥｎｔｒｙＳｔａｒｔＡｄｄｒｅｓｓフィールド９７ｂの値との和を計算することによって取得できる。
なお、上述の説明は、説明の簡略化のためＣｌｏｓｅｄＧＯＰ構造（ＧＯＰ内の全てのピクチャはＧＯＰ内のピクチャを参照するのみ）を前提としている。しかしながら、ＣｌｏｓｅｄＧＯＰ構造が取れない場合や、保証できない場合には、特定された再生開始時刻を含むＫＰＵの一つ前のＫＰＵから復号を開始してもよい。
次のステップＳ１７４では、メディア制御部２０５はそのキーピクチャユニット（ＫＰＵ）のＫＰＵＥｎｔｒｙ中のフラグを読み出し、ステップＳ１７５においてＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールド９８ａの値が“１ｂ”か否かを判断する。値が“１ｂ”のときは、キーピクチャユニットＫＰＵが第１および第２リムーバブルＨＤＤにまたがることを意味しており、処理はステップＳ１７６に進む。一方値が“０ｂ”のときは、跨らないことを意味しており、処理はステップＳ１７７に進む。
ステップＳ１７６において、メディア制御部２０５は第１リムーバブルＨＤＤに格納されたＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。このとき、特定したピクチャによっては、読み出しを開始した第１リムーバブルＨＤＤではなく第２リムーバブルＨＤＤにデータが格納されていることもあるが、復号を正しく行うために２つのクリップ（ＴＴＳファイル）を跨ぐＫＰＵの先頭キーピクチャからデコードが行われる。
ステップＳ１７７では、メディア制御部２０５はＫＰＵの先頭ピクチャデータからデータを読み出し、ＴＳ処理部２０４がＴＴＳヘッダを除去すると、デコーダ２０６はそのデータからデコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブルＨＤＤ内に格納されている。
その後、ステップＳ１７８では、再生開始時刻に対応するピクチャのデコード終了後に、グラフィック制御部２０７はそのピクチャから出力を開始する。対応する音声が存在するときには、スピーカ２０９ｂもまたその出力を開始する。その後は、コンテンツの最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終了する。
次に、図１８および図１９を参照しながら、リムーバブルＨＤＤに録画されたコンテンツを編集する処理を説明する。この処理は、カムコーダ１００においても実行されるとして説明するが、他には、コンテンツが録画されたリムーバブルＨＤＤが装填されたＰＣ１０８（図１）等において実行されてもよい。
図１８（ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す。図１８（ａ）に示される範囲Ｄが、削除の対象となる部分である。この範囲Ｄは、ＴＴＳファイルの先頭部分を含む。先頭部分のアドレスをｐ１とし、ｐ１＋Ｄ＝ｐ４とする。これまで説明したように、クリップＡＶストリームは複数のファイルに分けて格納されることがあるが、以下の処理は、各ＴＴＳファイルの先頭部分を含む削除に対して適用される。
図１８（ｂ）は、範囲Ｄを削除した後の管理情報（クリップタイムライン）およびクリップＡＶストリームの関係を示す。本実施形態では、範囲Ｄのすべてを常に削除するのではなく、範囲Ｄに収まるデータ量のうち、９６キロバイトのｎ倍（ｎ：整数）のデータ量だけを削除する。いま、削除後の先頭データ位置をアドレスｐ２とすると、（ｐ２−ｐ１）は、（９６キロバイト）・ｎである。また、ｐ２≦ｐ４である。
上述の範囲Ｄの終端アドレスｐ４は、ユーザの編集位置を示している。換言すれば、この終端アドレスｐ４はユーザにとっては後続のストリームの開始点を示している。アドレスｐ４の値は、（ｐ１＋Ｄ）の値として表される。さらに、例えばそのアドレスに対応するピクチャの再生開始時刻情報（例えばＰＴＳ）を利用して表すこともできる。例えばユーザがアドレスｐ４を始点とし、後続のアドレスを終点とする編集を行うときには、上述のアドレスｐ４に対応するピクチャの再生開始時刻情報とともに、ｐ４からのビデオ再生時間長や、開始時刻情報と同様のビデオの再生終了時刻情報によって、終点を特定することができる。ユーザの編集区間を示す情報（開始点・終了点）は、図９のＣｌｉｐ Ｍｅｔａｄａｔａ（９４）、または、Ｃｌｉｐ Ｔｉｍｅ Ｌｉｎｅ（９５）において管理される。
アドレスｐ４の値またはそのアドレスに対応する時刻情報を保持することにより、ユーザが指定した範囲Ｄの後から再生、編集等を開始することができる。特に本実施形態の処理によれば、ユーザが削除を指定した範囲Ｄのうち、ｐ２からｐ４までのデータが再生可能な状態で残されることがある。ユーザにとってはｐ２からｐ４のデータは削除されており、再生されると違和感を覚える。そこでアドレスｐ４の値等を保持しておくことにより、ｐ２からｐ４までの区間の映像が再生されたり、その間を編集開始位置として誤って認識することを確実に防止することができる。アドレスｐ４の値またはそのアドレスに対応する時刻情報は、図１０に示すクリップメタデータ９４の記述データ（ｄｅｓｃｒｉｐｔｉｖｅ）中の再生情報として格納される。
「９６キロバイト」は、本実施形態において採用するクラスタサイズ（３２キロバイト）と、ＴＴＳパケットのパケットサイズ（１９２バイト）との最小公倍数である。このように処理する理由は、クラスタサイズの整数倍とすることによってリムーバブルＨＤＤに対するデータ削除処理がアクセス単位で実行でき、またＴＴＳパケットのパケットサイズの整数倍とすることによってデータ削除処理がクリップＡＶストリームのＴＴＳパケット単位で実行できるため、処理を高速化かつ簡易にできるからである。なお、本実施形態ではクラスタサイズを３２キロバイトとしているため、９６キロバイトを基準として削除単位を決定したが、この値はクラスタサイズや、採用するクリップＡＶストリームのパケットサイズに応じて変化し得る。
削除処理では、さらにＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃおよびＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値も変更される。これらの値は削除前は０である。削除後は、まずＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄに、初めて現れるキーピクチャユニットＫＰＵまでのデータ量が記述される。初めて現れるキーピクチャユニットＫＰＵの格納アドレスをｐ３とすると、ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄは（ｐ３−ｐ２）の値が記述される。また、ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃに、最初のキーピクチャユニットＫＰＵの中で先頭のキーピクチャの再生時刻から最初のタイムエントリまでの時間差がＡＵＴＭ単位で記述される。なお、アドレスｐ２からｐ３までのクリップＡＶストリームのパケットは、単独でデコードできるという保証がないため、フラグメントとして扱われ、再生の対象とはされない。
図１９は、カムコーダ１００によるコンテンツの部分削除処理の手順を示す。まずステップＳ１９１において、カムコーダ１００のＣＰＵ２１１は指示受信部２１５を介して、ユーザからＴＴＳファイルの部分削除指示、および、削除範囲Ｄの指定を受け取る。部分削除指示とは、ＴＴＳファイルの先頭部分および／または末尾部分を削除する指示である。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および／または末尾部分を削除する「後方部分削除処理」が行われる。
ステップＳ１９２において、前方部分削除処理か否かが判定される。前方部分削除処理を行う場合にはステップＳ１９３に進み、前方部分削除でない場合にはステップＳ１９５に進む。ステップＳ１９３では、メディア制御部２０５は、削除範囲に相当するデータ量Ｄのうち、９６キロバイトの整数倍のデータ量を先頭から削除する。そしてステップＳ１９４において、メディア制御部２０５は、時間・アドレス変換テーブル（クリップタイムライン）中の、最初のタイムエントリに対する時間オフセットの値（ＣｌｉｐＴｉｍｅＬｉｎｅＴｉｍｅＯｆｆｓｅｔフィールド９５ｃの値）と最初のＫＰＵエントリに対するアドレスオフセット値（ＣｌｉｐＴｉｍｅＬｉｎｅＡｄｄｒｅｓｓＯｆｆｓｅｔフィールド９５ｄの値）とを修正する。その後、処理はステップＳ１９５に進む。
ステップＳ１９５では、後方部分削除処理か否かが判定される。後方部分削除処理を行う場合にはステップＳ１９６に進み、行わない場合にはステップＳ１９７に進む。ステップＳ１９６では、削除範囲に相当するデータ量のうち、ＴＴＳファイルの最後が完全なＫＰＵとなるよう１９２バイト単位でデータが削除される。これはすなわち、１９２バイトの整数倍のデータ量のデータが削除されることを意味する。その後処理はステップＳ１９７に進む。
ステップＳ１９７では、部分削除処理によって変化したタイムエントリ数やＫＰＵエントリ数等を修正する。具体的には、時間・アドレス変換テーブル（ＣｌｉｐＴｉｍｅＬｉｎｅ）中で、実データを伴わなくなったＫＰＵＥｎｔｒｙエントリ、およびＫＰＵＥｎｔｒｙＲｅｆｅｒｅｎｃｅＩＤで参照していたＫＰＵＥｎｔｒｙエントリを失ったＴｉｍｅＥｎｔｒｙエントリが削除される。また、ＴｉｍｅＥｎｔｒｙＮｕｍｂｅｒフィールド９５ａの値、ＫＰＵＥｎｔｒｙＮｕｍｂｅｒフィールド９５ｂの値等の修正処理が行われる。
なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合にもステップＳ１９７を経由する。これは、例えばＴＴＳファイルの中間部分の削除処理が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削除処理は本明細書においては特に言及しない。
なお、上述のように部分削除処理はＴＴＳファイルの先頭部分に限られず、ＴＴＳファイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の不完全なキーピクチャユニットＫＰＵ（図１４のＫＰＵ＃ｄ１）を削除する際に適用される。不完全なキーピクチャユニットＫＰＵは１クリップの最後に存在しているため、「ＴＴＳファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全なキーピクチャユニットＫＰＵの先頭からＴＴＳファイルの最後までであり、例えばＴＴＳパケットのパケットサイズ（１９２バイト）単位で削除する範囲を決定すればよい。クラスタサイズは特に考慮しなくてもよい。なお、ＴＴＳファイルの最後の部分は不完全なキーピクチャユニットＫＰＵに限られず、ユーザから範囲の指定を受けること等により、任意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行ってもよいし、一方の処理のみを行ってもよい。
以上、本発明の実施形態を説明した。
本実施形態では、データストリーム等を格納するメディアはリムーバブルＨＤＤであるとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば、非可換メディア、例えばデータ処理装置に内蔵されたＨＤＤであってもよい。
タイムマップ（ＣｌｉｐＴｉｍｅＬｉｎｅ）のデータ構造は、ＴｉｍｅＥｎｔｒｙおよびＫＰＵＥｎｔｒｙの２層を含むとした。しかし、再生時間と記録アドレスの変換が可能であればこれに限る必要は一切なく、ＫＰＵＥｎｔｒｙの１層のみからなるタイムマップであっても全く同様である。上述の説明では、ＯｖｅｒｌａｐｐｅｄＫＰＵＦｌａｇフィールドを設け、その値に基づいてキーピクチャユニットＫＰＵが複数のファイルを跨っていることを示すとして説明した。しかし、複数のファイルを跨っているか否かは、タイムマップに相当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデータ（リレーション情報など）、クリップのファイル名の命名規則（ファイル名の番号が昇順など）、同一フォルダ内に１ショットの全データ（少なくとも１ショットを構成する全ＴＴＳファイルの内、同一記録媒体上に記録されたもの）を格納する等によって、ＫＰＵが跨っている、または、跨っている可能性があることを示してもよい。
なお、図２等の各機能ブロックは典型的には集積回路（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ；ＬＳＩ）のチップとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。例えば、図２においては、ＣＰＵ２１１を含むシステム制御部２５０とメディア制御部２０５とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、システム制御部２５０にメディア制御部２０５の機能を与え、物理的に同一のチップによって実現してもよい。また、メディア制御部２０５およびＴＳ処理部２０４の機能を集積化して、１つのチップ回路として実現してもよいし、さらにエンコーダ２０３およびデコーダ２０６の機能を付加したチップ回路２１７として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外することにより、複数の符号化方式に容易に対応できる。
システム制御部２５０は、プログラムＲＯＭ２１０等に格納されたコンピュータプログラムを実行することにより、本明細書に記載したメディア制御部２０５の機能を実現することができる。このときは、メディア制御部２０５はシステム制御部２５０の一部の機能として実現される。
なお、上述の「ＬＳＩ」は、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。
本発明によれば、コンテンツの録画のために、複数ファイルに跨ってコンテンツのデータストリームが格納されることを想定したデータ構造を得ることができる。このデータ構造によれば、機器はどのファイル内のデータであっても容易にアクセスし、再生を開始することができる。またこのデータ構造を利用してさらにファイルの編集を行うことにより、機器は処理の高速化および処理負荷の軽減を実現できる。
リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図である。 カムコーダ１００の機能ブロックの示す図である。 トランスポートストリーム（ＴＳ）２０のデータ構造を示す図である。 （ａ）はビデオＴＳパケット３０のデータ構造を示し、（ｂ）はオーディオＴＳパケット３１のデータ構造を示す図である。 （ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。 クリップＡＶストリーム６０のデータ構造を示す図である。 ＴＳ処理部２０４の機能ブロックの構成を示す図である。 （ａ）は本実施形態における１コンテンツの概念を示す図であり、（ｂ）はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、（ｃ）は３つのリムーバブルＨＤＤ１１２を示す図である。 リムーバブルＨＤＤ１１２内の階層化されたディレクトリ構造を示す図である。 クリップメタデータ９４に含まれる情報の内容を示す図である。 キーピクチャおよびキーピクチャユニットの関係を示す図である。 （ａ）はクリップタイムライン（ＣｌｉｐＴｉｍｅＬｉｎｅ）９５のデータ構造を示す図であり、（ｂ）は１タイムエントリに関するＴｉｍｅＥｎｔｒｙフィールド９５ｇのデータ構造を示す図であり、（ｃ）は１ＫＰＵエントリに関するＫＰＵＥｎｔｒｙフィールド９５ｈのデータ構造を示す図である。 （ａ）はタイムエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図であり、（ｂ）はＫＰＵエントリと、クリップタイムライン９５に含まれるフィールドとの関係を示す図である。 ２つのリムーバブルＨＤＤに分けて格納された、１ショットのコンテンツに関する管理情報とクリップＡＶストリームとを示す図である。 カムコーダ１００によるコンテンツの録画処理の手順を示す図である。 メディア切り替え処理の手順を示す図である。 カムコーダ１００によるコンテンツの再生処理の手順を示す図である。 （ａ）および（ｂ）は、編集によってＴＴＳファイルの先頭部分を削除する前後の管理情報およびクリップＡＶストリームの関係を示す図である。 カムコーダ１００によるコンテンツの部分削除処理の手順を示す図である。
符号の説明
１００ カムコーダ
１０８ ＰＣ
１１２ リムーバブルＨＤＤ
２０１ａ ＣＣＤ
２０１ｂ マイク
２０２ ＡＤコンバータ
２０３ ＭＰＥＧ−２エンコーダ
２０４ ＴＳ処理部
２０５ メディア制御部
２０６ ＭＰＥＧ−２デコーダ
２０７ グラフィック制御部
２０８ メモリ
２０９ａ ＬＣＤ
２０９ｂ スピーカ
２１０ プログラムＲＯＭ
２１１ ＣＰＵ
２１２ ＲＡＭ
２１３ ＣＰＵバス
２１４ ネットワーク制御部
２１５ 指示受信部
２１６ インターフェース（Ｉ／Ｆ）部
２５０ システム制御部
２６１ ＴＴＳヘッダ付加部
２６２ クロックカウンタ
２６３ ＰＬＬ回路
２６４ バッファ
２６５ ＴＴＳヘッダ除去部

Claims (8)

  1. メディアに書き込まれたコンテンツを編集するデータ処理装置であって、
    前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納され、前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されており、
    前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、
    前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部と
    を備えたデータ処理装置。
  2. 前記データストリームは、複数のピクチャから構成され、かつ、基準ピクチャからのデコードを要する復号化単位を１つまたは複数含む再生単位を含んでおり、
    前記メディア制御部は、データを削除した後のファイル内のデータストリームにおいて初めて現れる再生単位までのデータ量の値を前記メディアに書き込む、請求項１に記載のデータ処理装置。
  3. 前記メディアには、データを削除する前のデータストリームに対して、前記コンテンツの一定の再生時間ごとに再生されるピクチャのデータ位置を特定するタイムエントリが予め書き込まれており、
    前記メディア制御部は、データを削除した後のデータストリームに関し、初めて現れる前記再生単位の先頭から、前記タイムエントリによって特定される初めてのピクチャのデータ位置までのデータ量の値を前記メディアに書き込む、請求項２に記載のデータ処理装置。
  4. 前記データストリームは、各々のパケットサイズが１９２バイトである複数のパケットから構成され、前記メディアには３２キロバイトのクラスタサイズ単位でデータにアクセスされるファイルシステムが構築され、
    前記メディア制御部は、９６キロバイトの整数倍のデータ量のデータを削除する、請求項１に記載のデータ処理装置。
  5. 前記メディア制御部は、前記ファイルの末尾を含む部分削除の範囲の指定を受け取るときには、
    前記ファイルの末尾から、前記部分削除の範囲内であって、かつ前記パケットサイズの整数倍のデータ量のデータを削除する、請求項１に記載のデータ処理装置。
  6. 前記メディア制御部は、前記部分削除の範囲内であって、前記データストリームの不完全な再生単位のデータを削除する、請求項５に記載のデータ処理装置。
  7. データ処理装置に実装されて、メディアに書き込まれたコンテンツを編集するための処理を行うチップ回路であって、
    前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納され、前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築され、前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部を備えており、
    前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを特定する処理と、
    特定された前記データを削除する指示を出力する処理と
    を実行するチップ回路。
  8. メディアに書き込まれたコンテンツを編集するデータ処理方法であって、
    前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納され、前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されており、
    前記ファイルの先頭を含む部分削除の範囲の指定を受け取るステップと、
    前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップと
    を包含するデータ処理方法。
JP2006536355A 2004-09-24 2005-09-15 データ処理装置 Expired - Fee Related JP4791969B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006536355A JP4791969B2 (ja) 2004-09-24 2005-09-15 データ処理装置

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2004277594 2004-09-24
JP2004277594 2004-09-24
JP2004326351 2004-11-10
JP2004326351 2004-11-10
PCT/JP2005/017029 WO2006033275A1 (ja) 2004-09-24 2005-09-15 データ処理装置
JP2006536355A JP4791969B2 (ja) 2004-09-24 2005-09-15 データ処理装置

Publications (2)

Publication Number Publication Date
JPWO2006033275A1 true JPWO2006033275A1 (ja) 2008-05-15
JP4791969B2 JP4791969B2 (ja) 2011-10-12

Family

ID=36090038

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006536355A Expired - Fee Related JP4791969B2 (ja) 2004-09-24 2005-09-15 データ処理装置

Country Status (4)

Country Link
US (3) US8032012B2 (ja)
EP (1) EP1802117B1 (ja)
JP (1) JP4791969B2 (ja)
WO (1) WO2006033275A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4613559B2 (ja) * 2004-09-22 2011-01-19 株式会社ニコン 画像データ管理装置
EP2041974A4 (en) * 2006-07-12 2014-09-24 Lg Electronics Inc METHOD AND DEVICE FOR CODING / DECODING A SIGNAL
US7729381B2 (en) * 2006-09-15 2010-06-01 At&T Intellectual Property I, L.P. In-band media performance monitoring
US7903574B2 (en) * 2007-03-15 2011-03-08 Nokia Corporation Service discovery mechanism in broadcast telecommunication network
EP2059049A1 (en) * 2007-11-07 2009-05-13 British Telecmmunications public limited campany Video coding
JP5245940B2 (ja) * 2009-03-13 2013-07-24 ソニー株式会社 オーサリング方法、プログラム、編集データ再生装置
EP2619982A2 (en) * 2011-01-21 2013-07-31 Siemens Aktiengesellschaft Method for processing a compressed video stream

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69833975T2 (de) * 1997-09-17 2006-08-24 Matsushita Electric Industrial Co., Ltd., Kadoma Optische Platte, Aufzeichnungsgerät, und rechnerlesbares Aufzeichnungsmedium
MY115908A (en) * 1997-09-17 2003-09-30 Matsushita Electric Ind Co Ltd Video data editing apparatus, optical disc for use as a recording medium of a video data editing apparatus, and computer-readable recording medium storing an editing program
JP3028517B2 (ja) 1997-09-17 2000-04-04 松下電器産業株式会社 光ディスク、録画装置及び方法、再生装置及び方法並びにプログラム記憶媒体
JP4081729B2 (ja) * 1998-02-23 2008-04-30 ソニー株式会社 編集装置、編集方法、信号記録再生装置及び信号記録再生方法
JP3510783B2 (ja) 1998-03-12 2004-03-29 シャープ株式会社 動画像記録再生方法及び動画像記録再生装置
US6904227B1 (en) * 1999-02-15 2005-06-07 Nec Corporation Device and method for editing video and/or audio data recorded in a disc storage medium
KR100451625B1 (ko) 1999-07-07 2004-10-08 마쯔시다덴기산교 가부시키가이샤 오디오 비디오 데이터 기록장치 및 방법, 상기 오디오비디오 데이터 기록장치 또는 방법으로 기록된 디스크,오디오 비디오 데이터 재생장치 및 방법
US7106946B1 (en) 1999-09-28 2006-09-12 Sony Corporation Transport stream processing device, and associated methodology of generating and aligning source data packets in a physical data structure
US6707778B1 (en) * 1999-11-10 2004-03-16 Thomson Licensing S.A. Edit to picture without decoding and re-encoding of MPEG bit stream for recordable DVD
JP4361674B2 (ja) * 2000-06-26 2009-11-11 パナソニック株式会社 再生装置及びコンピュータ読取可能な記録媒体
JP3937788B2 (ja) * 2001-04-19 2007-06-27 ソニー株式会社 データ記録方法及び装置、データ再生方法及び装置、データ編集方法及び装置
JP4157294B2 (ja) * 2001-11-08 2008-10-01 富士通株式会社 欠陥ファイルの修復を可能とするファイルシステム
JP3795382B2 (ja) * 2001-11-21 2006-07-12 松下電器産業株式会社 情報記録装置および方法ならびに情報再生装置および方法
AU2003201840A1 (en) * 2002-04-01 2003-10-23 Sony Corporation Reproducing method, reproducing apparatus, recording method, recording apparatus, and method for generating a management table
JP2004013276A (ja) 2002-06-04 2004-01-15 Victor Co Of Japan Ltd ファイルシステム及び記録媒体
JP2004079087A (ja) * 2002-08-20 2004-03-11 Sony Corp 記録装置および方法、記録媒体、並びにプログラム
JP2004110876A (ja) * 2002-09-13 2004-04-08 Canon Inc 映像データの符号化レート制御方法
US20040062516A1 (en) * 2002-09-17 2004-04-01 Canon Kabushiki Kaisha Moving picture experts group phase 2 transport stream data editing method
EP1437888A3 (en) * 2003-01-06 2007-11-14 Samsung Electronics Co., Ltd. Video recording and reproducing apparatus
JP2005033383A (ja) * 2003-07-09 2005-02-03 Canon Inc 動画像編集装置及びその制御方法

Also Published As

Publication number Publication date
WO2006033275A1 (ja) 2006-03-30
US8831410B2 (en) 2014-09-09
EP1802117A1 (en) 2007-06-27
JP4791969B2 (ja) 2011-10-12
US20110305125A1 (en) 2011-12-15
EP1802117A4 (en) 2010-09-01
US20070217758A1 (en) 2007-09-20
EP1802117B1 (en) 2014-06-11
US20110305431A1 (en) 2011-12-15
US8032012B2 (en) 2011-10-04
US8824864B2 (en) 2014-09-02

Similar Documents

Publication Publication Date Title
JPWO2006033279A1 (ja) データ処理装置
JP2008053763A (ja) Ａｖデータ記録装置及び方法、ａｖデータ再生装置及び方法、当該ａｖデータ記録装置又は方法で記録された記録媒体
CN100375190C (zh) Av数据记录装置及方法、用该av数据记录装置或方法记录的盘、av数据重放装置及方法
JP4299836B2 (ja) データ処理装置
JP3900050B2 (ja) データ処理装置、ビデオカメラ及びデータ処理方法
US8824864B2 (en) Data processor
US20080301380A1 (en) Data Processor
US20060167936A1 (en) Data processing device
JP4495597B2 (ja) データストリームのフォーマット変換方法およびそのための記録方法
EP1768402A1 (en) Data processor
JP2001223980A (ja) 記録メディアとこれを用いる映像記録／再生装置
JP4426800B2 (ja) Ａｖデータ記録再生装置及び方法、並びに当該ａｖデータ記録再生装置又は方法で記録された記録媒体
JP3986973B2 (ja) Ａｖデータ記録方法、ａｖデータ記録装置、データ記録媒体、及びプログラム
JP3901555B2 (ja) Ａｖデータ記録装置及び方法、当該ａｖデータ記録装置又は方法で記録されたディスク、並びに当該ディスクを再生するａｖデータ再生装置及び方法又はａｖデータ記録再生装置及び方法
JP4481929B2 (ja) データストリームの記録方法および装置
US20060291811A1 (en) Moving picture distribution system
JP4312783B2 (ja) Ａｖデータ再生方法、ａｖデータ再生装置、プログラム、並びに記録媒体
US20070031125A1 (en) Data processing device and data processing method
JP2006115529A (ja) 記録メディアとこれを用いる映像記録／再生装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080627

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110301

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110628

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110722

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140729

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4791969

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees