本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコンテンツの再生および編集を容易にする技術に関する。
近年、DVD等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器(光ディスクレコーダ、カムコーダ等)の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。
近年はPCにもコンテンツの記録、再生および編集機能が実装されており、PCも上述のデジタル機器に含めることができる。PCでは、文書データ等を記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、PCと連携可能なデータ管理構造、例えばFAT(File Allocation Table)を用いたファイルシステムが採用されている。現在多く利用されているFAT32ファイルシステムでは、最大4ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が2テラバイトのメディアを管理することができる。
メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。例えば特許文献1では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるAVデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。
特開平11−155130号公報
コンテンツの再生時間が長くなり、コンテンツの一部を削除する編集処理が頻繁に行われるようになると、従来の処理では編集処理時間が長くなるという問題が生じる。例えば、データストリームの内容を解析し、削除範囲内のピクチャのデータ位置等を特定した後にそのデータを削除すると、解析時間、データ位置の特定時間および削除時間がそれぞれ必要になる。
この問題は、トランスポートストリーム等を構成する固定長のデータパケットに、MPEG規格等による順方向符号化方式および双方向符号化方式で圧縮符号化された映像データを格納しているときに顕著である。例えば、MPEG規格の一連の映像データの一部を削除するとき、まず、編集装置は削除の開始ピクチャおよび終了ピクチャを特定するために、メディアからパケットを読み出してパケット内のデータを解析しなければならない。パケットデータの読み出しは、例えばファイルシステムのクラスタ単位で行われるため、一般には、必要とするパケット以外の不要なパケットも同時に読み出される。よって不要なアクセス時間がかかる。さらに、ピクチャを特定して削除しても、削除直後の開始ピクチャをいわゆるIピクチャに設定しなければならないため、そのピクチャデータの読み出し、デコードおよび再エンコードが必要になる。
本発明の目的は、コンテンツのデータストリームを高速に編集する手段を提供することである。
本発明によるデータ処理装置は、メディアに書き込まれたコンテンツを編集することができる。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部とを備えている。
前記データストリームは、複数のピクチャから構成され、かつ、基準ピクチャからのデコードを要する復号化単位を1つまたは複数含む再生単位を含んでいる。前記メディア制御部は、データを削除した後のファイル内のデータストリームにおいて初めて現れる再生単位までのデータ量の値を前記メディアに書き込んでもよい。
前記メディアには、データを削除する前のデータストリームに対して、前記コンテンツの一定の再生時間ごとに再生されるピクチャのデータ位置を特定するタイムエントリが予め書き込まれている。前記メディア制御部は、データを削除した後のデータストリームに関し、初めて現れる前記再生単位の先頭から、前記タイムエントリによって特定される初めてのピクチャのデータ位置までのデータ量の値を前記メディアに書き込んでもよい。
前記データストリームは、各々のパケットサイズが192バイトである複数のパケットから構成され、前記メディアには32キロバイトのクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記メディア制御部は、96キロバイトの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記ファイルの末尾を含む部分削除の範囲の指定を受け取るときには、前記ファイルの末尾から、前記部分削除の範囲内であって、かつ前記パケットサイズの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記部分削除の範囲内であって、前記データストリームの不完全な再生単位のデータを削除してもよい。
本発明によるチップ回路は、メディアに書き込まれたコンテンツを編集する処理を行うためにデータ処理装置に実装される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部を備えている。前記チップ回路は、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを特定する処理と、特定された前記データを削除する指示を出力する処理とを実行する。
本発明によるコンピュータプログラムは、メディアに書き込まれたコンテンツを編集する処理を行うためのデータ処理装置において実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記コンピュータプログラムを実行した前記データ処理装置は、前記ファイルの先頭を含む範囲の指定を受け取るステップと、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを実行する。
本発明によるデータ処理方法は、メディアに書き込まれたコンテンツを編集するために実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理方法は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取るステップと、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを包含する。
本発明によれば、メディア上のデータストリームの一部のデータを削除する際に、ファイルシステムのクラスタサイズとデータストリームのパケットサイズとの最小公倍数を基準として、その整数倍のデータ量のデータを削除する。クラスタサイズの整数倍とすることによってメディアに対するデータ削除処理がアクセス単位で実行でき、またパケットのパケットサイズの整数倍とすることによってデータ削除処理がパケット単位で実行できるため、処理を高速化できる。
また、データストリーム中に格納されていた再生単位のうち、データを削除した後のデータストリームにおいて初めて現れる再生単位までのデータ量の値を保持するため、削除処理において削除直後のピクチャをIピクチャに変更する必要はない。よってIピクチャへの変更に必要な処理を排除でき、編集処理時間を短縮できる。
リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図である。
カムコーダ100の機能ブロックの示す図である。
トランスポートストリーム(TS)20のデータ構造を示す図である。
(a)はビデオTSパケット30のデータ構造を示し、(b)は、オーディオTSパケット31のデータ構造を示す図である。
(a)〜(d)は、ビデオTSパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。
クリップAVストリーム60のデータ構造を示す図である。
TS処理部204の機能ブロックの構成を示す図である。
(a)は本実施形態における1コンテンツの概念を示す図であり、(b)はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、(c)は3つのリムーバブルHDD112を示す図である。
リムーバブルHDD112内の階層化されたディレクトリ構造を示す図である。
クリップメタデータ94に含まれる情報の内容を示す図である。
キーピクチャおよびキーピクチャユニットの関係を示す図である。
(a)は、クリップタイムライン(ClipTimeLine)95のデータ構造を示す図であり、(b)は1タイムエントリに関するTimeEntryフィールド95gのデータ構造を示す図であり、(c)は1KPUエントリに関するKPUEntryフィールド95hのデータ構造を示す図である。
(a)は、タイムエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す図であり、(b)はKPUエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す図である。
2つのリムーバブルHDDに分けて格納された、1ショットのコンテンツに関する管理情報とクリップAVストリームとを示す図である。
カムコーダ100によるコンテンツの録画処理の手順を示す図である。
メディア切り替え処理の手順を示す図である。
カムコーダ100によるコンテンツの再生処理の手順を示す図である。
(a)および(b)は、編集によってTTSファイルの先頭部分を削除する前後の管理情報およびクリップAVストリームの関係を示す図である。
カムコーダ100によるコンテンツの部分削除処理の手順を示す図である。
符号の説明
100 カムコーダ
108 PC
112 リムーバブルHDD
201a CCD
201b マイク
202 ADコンバータ
203 MPEG−2エンコーダ
204 TS処理部
205 メディア制御部
206 MPEG−2デコーダ
207 グラフィック制御部
208 メモリ
209a LCD
209b スピーカ
210 プログラムROM
211 CPU
212 RAM
213 CPUバス
214 ネットワーク制御部
215 指示受信部
216 インターフェース(I/F)部
250 システム制御部
261 TTSヘッダ付加部
262 クロックカウンタ
263 PLL回路
264 バッファ
265 TTSヘッダ除去部
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。
図1は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す。図1では、データ処理装置は、カムコーダ100−1、カメラ付き携帯電話100−2、PC108として記載されている。カムコーダ100−1およびカメラ付き携帯電話100−2は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして符号化し、そのデータストリームを、それぞれリムーバブルメディア112−1および112−2に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図1では、リムーバブルメディア112−2に複数のファイルが格納されていることが示されている。
各リムーバブルメディア112−1および112−2はデータ処理装置から取り外し可能であり、例えばDVD、BD(Blu−ray Disc)等の光ディスク、マイクロドライブ等の超小型ハードディスク、半導体メモリ等である。PC108は、各リムーバブルメディア112−1および112−2を装填することが可能なスロットを備えている。PC108は、装填されたリムーバブルメディア112−1、112−2からデータを読み出し、再生処理および編集処理等を実行する。
リムーバブルHDD112では、FAT32ファイルシステムによりデータ管理が行われる。FAT32ファイルシステムでは、1ファイルのファイルサイズの最大値は、例えば4ギガバイトである。よって、FAT32ファイルシステムではデータのサイズが4ギガバイトを超えるときは2以上のファイルに分けて書き込まれる。例えば、容量が8ギガバイトのリムーバブルHDD112には4ギガバイトのファイルが2つ格納され得る。16ギガバイトのリムーバブルHDD112には4ギガバイトのファイルが4つ格納され得る。なお、分割して書き込まれる単位はファイルサイズの最大値でなくてもよく、ファイルサイズの最大値以下のサイズであればよい。
以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込むデータ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに格納されたデータストリームを再生し編集するデータ処理装置はPCであるとして説明する。
さらに、リムーバブルメディア112−1は超小型のリムーバブルハードディスクであるとする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆動してデータの書き込みおよび読み出しを行うための機構(ドライブ機構)を含む。以下では、リムーバブルメディア112−1を「リムーバブルHDD112」と記述する。説明を簡便化するため、リムーバブルHDD112は4ギガバイトの容量を持つとする。この結果、4ギガバイトを超えるコンテンツは、2以上のリムーバブルHDDに分けて書き込まれる。しかしながら、リムーバブルHDDが4ギガバイト以上の容量を持ち、そこに4ギガバイトを超えるコンテンツが書き込まれる場合にも、2以上のファイルに分割して同じリムーバブルHDDに書き込めばよい。1つのコンテンツが複数のファイルに分けて記録される本質的な点においては、いずれも同じである。単に記録するメディアが同一であるか否かの違いにすぎない。リムーバブルHDD112のクラスタサイズは、例えば32キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際の最小のアクセス単位である。
図2は、カムコーダ100の機能ブロックの構成を示す。カムコーダ100には、複数のリムーバブルHDD112a、112b、・・・、112cを同時に装填することが可能であり、ユーザが撮影した映像および音声に関するコンテンツのデータストリーム(クリップAVストリーム)を、リムーバブルHDD112a、112b、・・・、112cに順に書き込む。
カムコーダ100は、CCD201a、マイク201bおよびデジタル放送を受信するデジタルチューナ201cと、ADコンバータ202と、MPEG−2エンコーダ203と、TS処理部204と、メディア制御部205と、MPEG−2デコーダ206と、グラフィック制御部207と、メモリ208と、液晶表示装置(LCD)209aおよびスピーカ209bと、CPUバス213と、ネットワーク制御部214と、指示受信部215と、インターフェース(I/F)部216と、システム制御部250とを含む。
以下、各構成要素の機能を説明する。CCD201aおよびマイク201bは、それぞれ映像および音声のアナログ信号を受け取る。CCD201aは、映像をデジタル信号として出力する。マイク201bは、音声のアナログ信号を出力する。ADコンバータ202は入力されたアナログ音声信号をデジタル信号に変換してMPEG−2エンコーダ203に供給する。
デジタルチューナ201cは、アンテナ(図示せず)から1以上の番組が含まれるデジタル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。デジタルチューナ201cは、受信したトランスポートストリームから特定の番組(録画対象のチャンネルの番組)のパケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームであるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼ぶこともある。トランスポートストリームのデータ構造は、図3〜図5を参照しながら後述する。
本実施形態においては、カムコーダ100はデジタルチューナ201cを構成要素としているが、これは必須の要件ではない。図2のカムコーダ100の構成は、図1において言及したカメラ付き携帯電話100−2等にも適用できるため、デジタル放送の受信および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。
MPEG−2エンコーダ203(以下「エンコーダ203」と記述する)は、録画の開始指示を受け取ると、供給された映像および音声の各デジタルデータをMPEG規格に基づいて圧縮符号化する。本実施形態においては、エンコーダ203は、映像データをMPEG−2形式に圧縮符号化してトランスポートストリーム(以下「TS」とも記述する)を生成し、TS処理部204に送る。この処理は、エンコーダ203が録画の終了指示を受け取るまで継続される。エンコーダ203は双方向圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ(図示せず)等を有している。なお、映像および音声の符号化形式を一致させる必要はない。例えば、映像はMPEG形式で圧縮符号化し、音声はAC−3形式で圧縮符号化するとしてもよい。
本実施形態では、カムコーダ100はTSを生成し処理する。そこでまず、図3〜図5を参照しながら、TSのデータ構造を説明する。
図3は、トランスポートストリーム(TS)20のデータ構造を示す。TSパケットは、例えば、圧縮符号化されたビデオデータが格納されたビデオTSパケット(V_TSP)30、符号化されたオーディオデータが格納されたオーディオTSパケット(A_TSP)31の他、番組表(プログラム・アソシエーション・テーブル;PAT)が格納されたパケット(PAT_TSP)、番組対応表(プログラム・マップ・テーブル;PMT)が格納されたパケット(PMT_TSP)およびプログラム・クロック・リファレンス(PCR)が格納されたパケット(PCR_TSP)等を含む。各TSパケットのデータ量は188バイトである。また、PAT_TSP、PMT_TSP等のTSの番組構成を記述するTSパケットを一般に、PSI/SIパケットと呼ぶ。
以下、本発明の処理に関連するビデオTSパケットおよびオーディオTSパケットを説明する。図4(a)はビデオTSパケット30のデータ構造を示す。ビデオTSパケット30は、一般に4バイトのトランスポートパケットヘッダ30a、および、184バイトのトランスポートパケットペイロード30bを有する。ペイロード30bにはビデオデータ30bが格納されている。一方、図4(b)は、オーディオTSパケット31のデータ構造を示す。オーディオTSパケット31も同様に、一般に4バイトのトランスポートパケットヘッダ31a、および、184バイトのトランスポートパケットペイロード31bを有する。オーディオデータ31bはトランスポートパケットペイロード31bに格納されている。TSパケットヘッダにはアダプテーションフィールドと呼ばれるデータを追加してもよく、TSパケットに格納するデータをアライメントする場合などに利用される。この場合TSパケットのペイロード(30b、31b)は184バイト未満となる。
上述の例から理解されるように、一般にTSパケットは4バイトのトランスポートパケットヘッダと、184バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子(Packet IDentifier;PID)が記述されている。例えば、ビデオTSパケットのPIDは“0x0020”であり、オーディオTSパケットのPIDは“0x0021”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図5(a)〜(d)は、ビデオTSパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図5(a)に示すように、TS40は、ビデオTSパケット40a〜40dを含む。なお、TS40には、他のパケットも含まれ得るが、ここではビデオTSパケットのみを示している。ビデオTSパケットは、ヘッダ40a−1に格納されたPIDによって容易に特定される。
ビデオデータ40a−2等の各ビデオTSパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図5(b)は、パケット化エレメンタリストリーム(PES)41のデータ構造を示す。PES41は、複数のPESパケット41a、41b等から構成される。PESパケット41aは、PESヘッダ41a−1およびPESペイロード41a−2から構成されており、これらのデータがビデオTSパケットのビデオデータとして格納されている。
PESペイロード41a−2は、それぞれが1つのピクチャのデータを含んでいる。PESペイロード41a−2から、エレメンタリストリームが構成される。図5(c)は、エレメンタリストリーム(ES)42のデータ構造を示す。ES42は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
図5(c)に示すピクチャヘッダ42aには、その後に配置されたピクチャデータ42bのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ42cにはピクチャデータ42dのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Iピクチャ(Intra−coded picture)、Pピクチャ(Predictive−coded picture)またはBピクチャ(Bidirectionally−predictive−coded picture)などを表す。種別がIピクチャであれば、そのピクチャコーディングタイプは、例えば“001b”などと決められている。
ピクチャデータ42b、42d等は、そのデータのみによって、または、そのデータとその前および/または後に復号化されるデータとによって構築可能な1枚分のフレームのデータである。例えば図5(d)は、ピクチャデータ42bから構築されるピクチャ43aおよびピクチャデータ42dから構築されるピクチャ43bを示す。
TSに基づいて映像を再生する際、カムコーダ100はビデオTSパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をLCD209a上に再生することができる。
上述のエンコーダ203は、映像コンテンツに関しては図5(d)、(c)、(b)および(a)に示す順序でTSを生成するといえる。
次に、カムコーダ100のTS処理部204(図2)を説明する。TS処理部204は、動画の記録時にはエンコーダ203からTSを受け取り、またはデジタル放送番組の録画時にはデジタルチューナ201cからTSを受け取って、クリップAVストリームを生成する。クリップAVストリームとは、リムーバブルHDD112a等への格納のために所定の形式を有するデータストリームである。本明細書では、リムーバブルHDDに格納されたクリップAVストリームのファイルには拡張子TTS(“Timed TS”を意味する)を付している。クリップAVストリームは、到着時刻情報を付加したTSとして実現される。また、TS処理部204は、コンテンツの再生時には、リムーバブルHDD112a等から読み出されたクリップAVストリームをメディア制御部205から受け取り、そのクリップAVストリームに基づいてTSを生成してMPEG−2デコーダ206に出力する。
以下では図6を参照しながら、TS処理部204の処理に関連するクリップAVストリームを説明する。図6は、クリップAVストリーム60のデータ構造を示す。クリップAVストリーム60は、複数のTTSパケット61から構成される。TTSパケット61は、4バイトのTTSヘッダ61aと、188バイトのTSパケット61bとから構成される。すなわちTTSパケット61は、TTSヘッダ61aをTSパケット61bに付加して生成される。なおTSパケット61bは、図3、図4(a)および(b)等に関連して説明したTSパケットである。
TTSヘッダ61aは、2ビットの予約領域61a−1と、30ビットの到着時刻情報(Arrival Time Stamp;ATS)61a−2とから構成されている。この到着時刻情報61a−2は、エンコーダ203から出力されたTSパケットがTS処理部204に到着した時刻を示している。TS処理部204は、この時刻に基づいてデコーダ206にTSパケットを出力する。
次に、上述のクリップAVストリーム60を生成するTS処理部204の構成を説明する。図7は、TS処理部204の機能ブロックの構成を示す。TS処理部204は、TTSヘッダ付加部261と、クロックカウンタ262と、PLL回路263と、バッファ264と、TTSヘッダ除去部265とを有する。
TTSヘッダ付加部261は、TSを受け取り、そのTSを構成するTSパケットの前にTTSヘッダを付加し、TTSパケットとして出力する。TTSヘッダ中の到着時刻情報61a−2に記述されるTSパケットの到着時刻は、TTSヘッダ付加部261に与えられる基準時刻からのカウント値(カウント情報)に基づいて特定される。
クロックカウンタ262およびPLL回路263は、TTSヘッダ付加部261がTSパケットの到着時刻を特定するために必要な情報を生成する。まずPLL回路263は、TSに含まれるPCRパケット(図2のPCR_TSP)を抽出して、基準時刻を示すPCR(Program Clock Reference:プログラム時刻基準参照値)を取得する。PCRの値と同じ値がカムコーダ100のシステム基準時刻STC(System Time Clock)として設定され、STCが基準時刻とされる。システム基準時刻STCのシステムクロックの周波数は27MHzである。PLL回路263は、27MHzのクロック信号をクロックカウンタ262に出力する。クロックカウンタ262はクロック信号を受け取り、そのクロック信号をカウント情報としてTTSヘッダ付加部261に出力する。
バッファ264は、ライトバッファ264aおよびリードバッファ264bを有する。ライトバッファ264aは、送られてきたTTSパケットを逐次保持し、合計のデータ量が所定値(例えばバッファの全容量)になったときに、後述のメディア制御部205に出力する。このとき出力される一連のTTSパケット列(データストリーム)を、クリップAVストリームと呼ぶ。一方、リードバッファ264bは、メディア制御部205によってリムーバブルHDD112a等から読み出されたクリップAVストリームを一時的にバッファして、TTSパケット単位で出力する。
TTSヘッダ除去部265は、TTSパケットを受け取って、TTSヘッダを除去することによりTTSパケットをTSパケットに変換し、TSとして出力する。留意すべきは、TTSヘッダ除去部265は、TTSヘッダに含まれているTSパケットの到着時刻情報ATSを抽出して、到着時刻情報ATSとクロックカウンタ262から与えられるタイミング情報とに基づいて、元の到着時刻に対応するタイミング(時間間隔)でTSパケットを出力することである。リムーバブルHDD112a等はランダムアクセスが可能であり、データは不連続にディスク上に配列される。よって、TSパケットの到着時刻情報ATSを利用すれば、TS処理部204は、データの格納位置にかかわらず記録時のTSパケットの到着タイミングと同じタイミングでTSパケットを出力することができる。なおTTSヘッダ除去部265は、読み出したTSの基準時刻を指定するために、例えば最初のTTSパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ262に送る。これにより、クロックカウンタ262においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
カムコーダ100では、TS処理部204を設けて、TSにTTSヘッダを付加してクリップAVストリームを生成するとした。しかし、符号化レートが固定されているCBR(Constant Bit Rate)で符号化する場合には、TSパケットのデコーダ入力時刻が固定間隔であるため、TS処理部204を省略してTSをリムーバブルHDD112に書き込むこともできる。
再び図2を参照しながら、カムコーダ100の各構成要素を説明する。
メディア制御部205は、TS処理部204からクリップAVストリームを受け取り、いずれかのリムーバブルHDD112a、112b、・・・、112cに出力するかを決定して、そのリムーバブルHDDに出力する。メディア制御部205は、書き込み中のリムーバブルHDDの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときには出力先を他のリムーバブルHDDに変更し、クリップAVストリームの出力を継続する。このとき、1つのコンテンツを構成するクリップAVストリームが2つのリムーバブルHDD112に跨って格納されることになる。
メディア制御部205は、本発明の主要な特徴の1つであるクリップタイムライン(ClipTimeLine)テーブルを生成する。そしてそのテーブルに、クリップAVストリームの再生単位であるキーピクチャユニットが、2つのファイルに跨って格納されているか否かを示すフラグを記述する。なお、メディア制御部205のより詳細な動作、および、メディア制御部205によって生成されるクリップタイムラインテープルの詳細なデータ構造は後述する。
なお、クリップAVストリームをリムーバブルHDD112に書き込む処理は、メディア制御部205から書き込み指示およびクリップAVストリームを受け取ったリムーバブルHDD112が行っている。また、クリップAVストリームを読み出す処理は、メディア制御部205から読み出し指示を受けたリムーバブルHDD112が行っている。しかし、説明の便宜のため、以下ではメディア制御部205がクリップAVストリームを書き込み、読み出すとして説明する。
MPEG−2デコーダ206(以下「デコーダ206」と記述する)は、供給されたTSを解析して、TSパケットから映像および音声の圧縮符号化データを取得する。そして、映像の圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部207に供給する。またデコーダ206は、音声の圧縮符号化データを伸長して音声信号を生成し、音声信号をスピーカ209bに出力する。デコーダ206は、TSに関してMPEG規格で規定されているシステムターゲットデコーダ(T−STD)の要件を満たすように構成されている。
グラフィック制御部207には内部演算用のメモリ208が接続されており、オン・スクリーン・ディスプレイ(On Screen Display;OSD)機能を実現できる。例えば、グラフィック制御部207は種々のメニュー画像と映像とを合成した映像信号を出力することができる。液晶表示装置(LCD)209aは、グラフィック制御部207から出力された映像信号をLCD上に表示する。スピーカ209bは、音声信号を音として出力する。コンテンツは、LCD209aおよびスピーカ209bを介して再生され、視聴の対象となる。なお、映像信号および音声信号の出力先は、それぞれLCD209aおよびスピーカ209bに限られない。例えば映像信号および音声信号は、外部出力端子(図示せず)を経てカムコーダ100と別体のテレビやスピーカに伝送されてもよい。
CPUバス213はカムコーダ100内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、CPUバス213には、後述するシステム制御部250の各構成要素も接続されている。
ネットワーク制御部214は、カムコーダ100をインターネット等のネットワーク101に接続するためのインターフェイスであり、例えば、イーサネット(登録商標)規格に準拠した端子およびコントローラである。ネットワーク制御部214は、ネットワーク101を介してデータを授受する。例えば、ネットワーク制御部214は、撮影され生成されたクリップAVストリームをネットワーク101を介して放送局に伝送してもよい。または、ネットワーク制御部214は、カムコーダ100の動作を制御するためのソフトウェアプログラムが更新されたときは、更新されたプログラムをネットワーク101を介して受け取ってもよい。
指示受信部215は、カムコーダ100の本体部に設けられた操作ボタンである。指示受信部215は、ユーザから、例えば録画の開始/停止、再生の開始/停止等の指示を受け取る。
インターフェース(I/F)部216は、カムコーダ100が他の機器と通信するためのコネクタおよびその通信を制御する。I/F部216は、例えばUSB2.0規格の端子、IEEE1394規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ100は、USB2.0規格またはIEEE1394規格の端子を介してPC108や、他のカムコーダ(図示せず)、BD/DVDレコーダ、PC等と接続される。
システム制御部250は、カムコーダ100内の信号の流れを含む全体的な処理を制御する。システム制御部250は、プログラムROM210と、CPU211と、RAM212とを有している。それぞれはCPUバス213に接続されている。プログラムROM210にはカムコーダ100を制御するためのソフトウェアプログラムが格納されている。
CPU211は、カムコーダ100の全体の動作を制御する中央制御ユニットである。CPU211は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、CPUバス213を介して各構成要素に出力する。メモリ212は、CPU211がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、CPU211は、CPUバス213を使用してプログラムROM210からプログラムをランダムアクセスメモリ(RAM)212に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、CD−ROM等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、PC、カメラ、マイク等を利用して構成されたコンピュータシステムを、本実施形態によるカムコーダ100と同等の機能を有する機器として動作させることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。
次に、図8(a)〜(c)を参照しながら、カムコーダ100において撮影された、映像および音声に関するコンテンツのデータ管理構造を説明する。図8(a)は、本実施形態における1コンテンツの概念を示す。撮影の開始から終了までの期間に得られたコンテンツを、1ショットという。図8(b)は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。1ショット、すなわち1つのコンテンツは、複数のクリップa〜cに分けて各リムーバブルHDD112a〜112cに格納することができる(1つのクリップで完結してもよい)。1つのクリップは、クリップメタデータ81と、タイムマップ82と、クリップAVストリーム83の一部(部分ストリーム)とを含む。クリップAVストリーム83は、部分ストリーム83a〜83cから構成されており、クリップa〜cのそれぞれに含まれる。図8(b)には3つのクリップa〜cが記載されているが、各クリップの構成は共通しているため、ここではクリップaを例に挙げて説明する。
クリップaは、クリップメタデータaと、タイムマップaと、部分ストリームaとを含む。このうち、クリップメタデータaおよびタイムマップaは管理情報であり、部分ストリームaがクリップAVストリーム83を構成するデータである。クリップAVストリーム83は原則として1つのファイルに格納されるが、FAT32のファイルサイズの最大値を超えるときには複数のTTSファイルに格納される。図8(b)では、3つの部分ストリーム83a、83bおよび83cが別個のファイルに格納される。なお本実施形態では、各部分ストリームのファイルサイズをFAT32ファイルシステムにおけるファイルサイズの最大値(4ギガバイト)とすると、リムーバブルHDD112a〜cの記録可能容量がなくなって管理情報をリムーバブルHDD112に書き込みできなくなるため、各部分ストリームのファイルサイズは4ギガバイトよりも小さくなることに留意されたい。さらに、TTSファイルは整数個のTTSパケットから構成されるとし、上記ファイルシステムからの制限である4ギガバイト未満であり、かつ、TTSパケット(192バイト)の整数倍としてもよい。
クリップメタデータaはXML形式で記述されており、コンテンツの再生に必要な情報、例えば映像/音声フォーマット等が規定される。クリップメタデータaの詳細は、後に図10を参照しながら詳述する。
タイムマップaは、再生単位ごとの、表示時刻とその格納位置(アドレス)との関係を規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」(ClipTimeLine)と呼び、クリップタイムラインが格納されたファイルの拡張子に“CTL”を付して図示している。クリップタイムラインの詳細は、後に図12〜14を参照しながら詳述する。
部分ストリームaは、図6に示すように複数のTTSパケットから構成される。
なお、1ショットの間にクリップAVストリーム83が複数の部分ストリーム83a〜83cのファイルに格納されたときには、TSパケットの転送タイミングを決定するATSのクロックカウンタ262(図7)がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ262(図7)は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。したがって、クリップAVストリーム83を構成する各TTSパケット中の到着時刻情報ATSは、1つのショットを構成する連続する2つのTTSファイルの境界において連続している。
図8(c)は、3つのリムーバブルHDD112a〜112cを示す。各クリップa〜cを構成するデータのファイルが各リムーバブルHDD112a〜112cに書き込まれる。
次に、リムーバブルHDD112内にファイルがどのように格納されるかを説明する。図9は、リムーバブルHDD112内の階層化されたディレクトリ構造を示す。コンテンツの管理情報とクリップAVストリームのファイルは、最上層のルート(ROOT)90内のコンテンツ(Contents)フォルダ91以下に格納される。より具体的には、コンテンツフォルダ91直下のデータベース(Database)フォルダ92には、管理情報であるクリップメタデータ94のXML形式ファイル、および、クリップタイムライン95のCTL形式ファイルが格納される。一方、コンテンツフォルダ91直下のTTSフォルダ93には、クリップAVストリーム(TimedTs)96のTTS形式ファイルが格納される。
なお、コンテンツフォルダ91には、さらにMXF形式の映像のストリームデータを格納するビデオフォルダ(Video)、MXF形式の音声のストリームデータを格納するオーディオフォルダ(Audio)、BMP形式のサムネイル画像を格納するアイコンフォルダ(Icon)、WAVE形式のボイスメモのデータを格納するボイスフォルダ(Voice)等が設けられてもよく、既存のカムコーダの記録フォーマット等に対応させることができる。
続いて、図10〜14を参照しながら、クリップメタデータ94およびクリップタイムライン95に記述されたデータの内容を説明する。
図10は、クリップメタデータ94に含まれる情報の内容を示す。クリップメタデータ94は、構成データ(“Structural”)および記述データ(“Descriptive”)の2種類に分類される。
構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のUMID(Unique Material IDentifier)が記述される。UMIDは、例えば、コンテンツが生成された時刻とそれを生成した機器のMAC(Media AccessControl)アドレスを組み合わせて生成される。さらにUMIDは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦UMIDが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのUMIDとは異なる値が付加される。よってUMIDを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。
エッセンスリストには、映像および音声の復号化に必要な情報(ビデオ情報およびオーディオ情報)が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はMPEG−2方式である。
リレーション情報は、図8(b)に示すような複数のクリップ81a〜81cが存在するときのクリップの間の関係を規定する。具体的には各クリップメタデータ94には、そのショットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々に対応するクリップAVストリーム(部分ストリーム)の再生の先後関係または再生順序を規定しているということができる。クリップを特定する情報は、例えば、UMIDおよびそのリムーバブルHDD112固有のシリアル番号とによって規定される。
記述データには、アクセス情報、デバイス、撮影情報、再生情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。再生情報は、再生開始時刻、再生時間長等を特定する情報である。
次に、クリップタイムライン95を説明する。クリップタイムライン95では、キーピクチャおよびキーピクチャユニットという概念を導入して、それらに関する情報を規定している。そこでまず図11を参照しながら、キーピクチャおよびキーピクチャユニットを説明する。
図11は、キーピクチャおよびキーピクチャユニットの関係を示す。図11では、I、BおよびPの各ピクチャを表示される順序で記載している。キーピクチャユニット(Key Picture Unit;KPU)は、映像に関して規定されるデータ再生単位である。図11では、キーピクチャユニットKPUの表示は、キーピクチャ44から開始され、Bピクチャ45において終了する。この間にはMPEG規格のグループ・オブ・ピクチャ(GOP)が1以上含まれている。Bピクチャ45の次のIピクチャ46から、次のキーピクチャユニットKPUの表示が始まる。各キーピクチャユニットの映像再生時間は、0.4秒以上、かつ、1秒以下である。ただし、1ショットの最後のキーピクチャユニットは1秒以下であればよい。撮影の終了タイミングによっては0.4秒に満たないこともあるからである。上記はGOP先頭のIピクチャから再生が開始されるとしているが、Bピクチャから再生が開始されるGOP構造の場合には、この限りではない。KPU期間(KPUPeriod)は、そのKPUに格納される全ピクチャの再生時間を示しているためである。
キーピクチャユニットの先頭に位置するキーピクチャ44、46は、MPEG規格におけるシーケンスヘッダコード(sequence_header_code)およびグループスタートコード(group_start_code)を含むビデオに関するアクセス単位である。例えば、キーピクチャユニットはMPEG2圧縮符号化されたIピクチャの画像(フレーム画像または1組の2フィールド画像)または、圧縮符号化されたIフィールドおよびPフィールドの画像である。
また本実施形態では、TSに付加されたPTSを用いてKPU期間(KPUperiod)を定義している。KPU期間は、次のキーピクチャユニットKPUの中で最初に表示されるピクチャの表示時刻(PTS)と、そのKPUの中で最初に表示されるピクチャの表示時刻(PTS)との差分値である。図11では、キーピクチャ44の時刻をPTS(N)とし、キーピクチャ46の時刻をPTS(N+1)としたとき、KPU期間(N)は、PTS(N+1)−PTS(N)として定義される(ともにキーピクチャが表示開始ピクチャとなっている場合)。なお、KPU期間の定義から明らかなように、あるKPU期間の値を決定するためには、次のキーピクチャユニットKPUのピクチャが圧縮符号化され、最初に表示されるピクチャの再生時刻(PTS)が確定しなければならない。よって、あるキーピクチャユニットKPUに対するKPU期間は、次のキーピクチャユニットの生成が開始された後に定まる。なお、ショットで最後のKPU期間が必要な場合もあるため、符号化したピクチャの表示時間を積算していく方法も可能である。その場合には、次のKPUの生成開始を待たずともKPU期間を決定することが可能である。
次に、図12(a)〜(c)を参照しながら、クリップタイムライン(ClipTimeLine)を説明する。図12(a)は、クリップタイムライン(ClipTimeLine)95のデータ構造を示す。クリップタイムライン95は、拡張子に“CTL”を有するファイルとして各リムーバブルHDD112に書き込まれる。
クリップタイムライン95は、再生単位ごとの、表示時刻とその格納位置(アドレス)との関係を規定したテーブルである。「再生単位」は、上述のキーピクチャユニットKPUに対応する。
クリップタイムライン95には、複数のフィールドが規定されている。例えば、クリップタイムライン95には、TimeEntryNumberフィールド95a、KPUEntryNumberフィールド95b、ClipTimeLineTimeOffsetフィールド95c、ClipTimeLineAddressOffsetフィールド95d、ClipTimeLineDurationフィールド95e、StartSTCフィールド95f、TimeEntryフィールド95g、KPUEntryフィールド95h等を含む。各フィールドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定している。
例えば、TimeEntryNumberフィールド95aにはタイムエントリの数が記述され、KPUEntryNumberフィールド95bにはKPUエントリの数が記述される。ただしTimeEntryフィールド95gおよびKPUEntryフィールド95hは、後述のタイムエントリの数およびKPUエントリの数に応じてデータサイズが変動し得る。
図12(b)は1タイムエントリに関するTimeEntryフィールド95gのデータ構造を示す。TimeEntryフィールド95gには、対応するタイムエントリに関する属性を示す情報が複数のフィールド(KPUEntryReferenceIDフィールド97a、KPUEntryStartAddressフィールド97bおよびTimeEntryTimeOffsetフィールド97c)に記述されている。
また、図12(c)は1KPUエントリに関するKPUEntryフィールド95hのデータ構造を示す。KPUEntryフィールド95hには、対応するキーピクチャユニットKPUに関する属性を示す情報が複数のフィールド(OverlappedKPUFlagフィールド98a、KeyPictureSizeフィールド98b、KPUPeriodフィールド98cおよびKPUSizeフィールド98d)に記述されている。
ここで、図13(a)および(b)を参照しながら、クリップタイムライン95に含まれる主要なフィールドに規定されるデータの意味を説明する。
図13(a)は、タイムエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す。図13(a)の横軸の1目盛りは1アクセスユニット時間(Access Unit TiMe;AUTM)を示している。これは1ピクチャの表示時間に対応する。ここでいう「ピクチャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プログレッシブビデオに対しては1枚のプログレッシブ走査のフレーム画像に対応し、インターレースビデオに対してはインターレース走査のフィールド画像(1フィールド)に対応する。例えば24000/1001秒間隔で表示されるプログレッシブビデオ(つまり23.97p)では、1AUTMは1/(24000/1001)秒=1126125clocks/27MHzと表記される。
ここでまず、1ショットにn個のクリップが含まれるとしたときの時間の関係を説明する。まず各クリップの再生時間長は、それぞれのClipTimeLineDurationフィールド95eに記述される。この値はAUTMを利用して記述される。すべてのクリップについてのClipTimeLineDurationフィールド95eの値の和を計算すると、1ショットの再生時間長(撮影時間長)が得られる(数1)。この時間長もまた、AUTMを利用して記述される。
一方、図13(a)に示すKPU#0から#(k+1)までが1クリップに含まれるとすると、上述の各クリップのClipTimeLineDurationフィールド95eは、そのクリップに含まれる全てのキーピクチャユニットKPUのKPU期間(KPUperiod)フィールド98cの値の総和として得られる(数2)。上述のように、KPU期間(KPUperiod)はAUTM値を用いて表記されるため、ClipTimeLineDurationフィールド95eもAUTM表記である。
各KPU期間(KPUperiod)フィールド98cの値は、上述のとおり、そのキーピクチャユニットKPUに含まれるピクチャのビデオ表示時間(AUTM値)の和に対応する(数3)。
「タイムエントリ」(TimeEntry)とは、一定の固定時間(例えば5秒)ごとに設定され、その位置から再生を開始することが可能な時間軸上の飛び込み点を示す。タイムエントリの設定に関連して、先頭のキーピクチャユニットKPU#0の再生開始時刻を0としたとき、最初に設定されたタイムエントリ#0までの時間オフセットがClipTimeLineTimeOffsetフィールド95cに設定される。また、各タイムエントリの設定時刻に再生されるキーピクチャユニットKPUを識別する情報がKPUEntryReferenceIDフィールド97aに記述され、そのキーピクチャユニットKPUの先頭からそのタイムエントリの設定時刻までの時間オフセットを示す情報がTimeEntryTimeOffsetフィールド97cに記述される。
例えば、タイムエントリ#tが指定されると、(ClipTimeLineTimeOffsetフィールド95cの値)+(タイムエントリの間隔・t)を計算することにより、そのタイムエントリ#tが設定された時刻、すなわち先頭キーピクチャユニットKPU#0の先頭からの経過時間を得ることができる。
また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。すなわち、ユーザから再生を開始したい時刻の指定を受け取ると、その時刻は、周知の変換処理を利用してMPEG規格上の時間情報であるPTS値に変換される。そして、そのPTS値が割り当てられたピクチャから、再生が開始される。なおPTS値は、ビデオTSパケット(V_TSP)30のトランスポートパケットヘッダ30a(図4(a))内に記述されている。
本実施形態では、1つのクリップAVストリームが複数の部分ストリームに分けられているため、各クリップ内の部分ストリーム先頭の再生開始時刻(PTS)が0でないことがある。そこで、クリップタイムライン95のStartSTCフィールド95f(図12(a))には、そのクリップ内の先頭KPUの中で最初に表示されるピクチャの再生時刻情報(PTS)が記述されている。そのピクチャのPTS値と指定された時刻に対応するPTS値とに基づいて、再生開始すべきピクチャまでのPTS(AUTM)差分値が得られる。なお、各ピクチャに割り振られているPTS値のデータ量と、StartSTCフィールド95fに規定されているPTS値のデータ量とを一致させることが好ましく、例えば33ビットで表記される。
上述の差分値がClipTimeLineDurationフィールド95eの値よりも大きければ、再生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に存在すると判断できる。後者のときは、さらにそのPTS差分値に基づいて、どの程度先の時刻かも容易に特定できる。
図13(b)は、KPUエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す。図13(b)の横軸の1目盛りは1データユニット長(Timed TS Packet Byte Length;TPBL)を示している。これは1データユニットがTTSパケットのデータ量(192バイト)と等しいことを意味する。
各KPUエントリは、各キーピクチャユニットKPUに対して1つ設けられている。KPUエントリの設定に関連して、各KPUのデータサイズがKPUSizeフィールド98dに記述され、各タイムエントリごとに対応するKPUの開始アドレスがKPUEntryStartAddressフィールド97bに記述される。なお、各キーピクチャユニットKPUのデータサイズは、例えば図13(b)のKPUsize#kに示すように、そのKPUの中で最初のピクチャのデータを格納した最初のTTSパケットから、次のKPUの最初のピクチャを格納したTTSパケット直前のTTSパケットまでのデータサイズを1データユニット長(TPBL)で示して表される。
さらにKPUエントリには、ファイルの最初から、キーピクチャユニットKPU#0の先頭までのフラグメント(データオフセット)がClipTimeLineAddressOffsetフィールド95dに設定されている。このフィールドを設ける理由は以下のとおりである。例えば1ショットのクリップAVストリームのデータが複数のファイルに分けて格納されたとき、2番目以降のファイルの先頭には先のファイル最後尾のKPUの一部が格納されることがある。キーピクチャユニットKPU内の各ピクチャは、KPU先頭のキーピクチャから復号化をしなければならないため、ファイルの先頭に存在するデータは単独で復号化できない。よってそのようなデータは、意味のないデータ(フラグメント)として読み飛ばすことが必要になる。そこで上述のオフセットフィールド95dにそのオフセット値を利用して、読み飛ばしを可能にしている。
ここで、図14を参照しながら、1ショットのクリップAVストリームデータが複数のファイルに分けて格納されたときのOverlappedKPUFlagフィールド98a等を説明する。説明の簡単のために、ここでは1ショットのコンテンツに関する管理情報とクリップAVストリームとが、2つのリムーバブルHDD#1および#2に格納されるとして説明し、またクリップメタデータには言及しない。
図14は、2つのリムーバブルHDDに分けて格納された、1ショットのコンテンツに関する管理情報とクリップAVストリームとを示す。リムーバブルHDD#1および#2には、それぞれクリップタイムラインのファイル(00001.CTLおよび00002.CTL)と、クリップAVストリームのファイル(00001.TTSおよび00002.TTS)とが格納されている。
以下では、KPUエントリに注目する。まず、リムーバブルHDD#1上のKPUエントリ#(d−1)は、00001.TTS内のクリップAVストリームに規定されるキーピクチャユニットKPU#(d−1)に対応して設けられている。図14に示すように、キーピクチャユニットKPU#(d−1)のすべてのデータは、00001.TTS内に存在している。その場合には、KPUエントリ#(d−1)のOverlappedKPUFlagフィールド98aには0bが設定される。
次に、KPUエントリ#dおよび対応するキーピクチャユニットKPU#dに着目する。図14に示すキーピクチャユニットKPU#dは、その一部(キーピクチャユニットKPU#d1)がリムーバブルHDD#1の00001.TTS内に存在し、他の一部(キーピクチャユニットKPU#d2)がリムーバブルHDD#2の00002.TTS内に存在している。キーピクチャユニットKPU#dが2つのリムーバブルHDDに分けて格納されている理由は、例えばリムーバブルHDD#1への書き込み中に、記録可能な残り容量が所定値以下になり、それ以上の書き込みが不可能になったためである。この場合には、KPUエントリ#dのOverlappedKPUFlagフィールド98aには1bが設定される。
なお、リムーバブルHDD#2内のKPUエントリ#0に対応するキーピクチャユニットKPUは、そのすべてのデータがリムーバブルHDD内に格納されているから、そのOverlappedKPUFlagフィールド98aには0bが設定される。
上述のようにKPUエントリ内のOverlappedKPUFlagフィールド98aの値を調べることにより、そのキーピクチャユニットKPUがそのメディア内のファイルに格納されているか否かが判断できる。この利点は、例えば以下の処理において非常に効果的である。
図14に示すように、KPU#dを構成するデータが複数のTTSファイル(00001.TTSおよび00002.TTS)に跨って格納されているときにおいて、リムーバブルHDD#2内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムーバブルHDD#1に格納されたデータのみに基づいて1ショットの再生が行われる。
編集処理によって1ショットの再生時間が変化するため、正確な再生時間を算出する必要がある。そこで、OverlappedKPUFlagフィールド98aの値に基づいて再生時間の算出処理を変化させることができる。
以下に、再生が保証されているピクチャまでの再生時間を算出する処理(1)と、現実に再生可能なピクチャまでの再生時間を算出する処理(2)とを説明する。例えば、処理(1)は個人ユーザ向けの機器に実装され、処理(2)は業務ユーザ向けの機器に実装される。
まず、上述の処理(1)から説明する。編集処理が行われた後のリムーバブルHDD#1内の最後のKPU#dに関しては、OverlappedKPUFlagフィールド98aの値は“1b”である。このときは、先頭からKPU#(d−1)までのKPU期間(KPUperiod)の和を、リムーバブルHDD#1内のクリップの再生時間(ClipTimeLineDuration95e)の値として採用する。換言すれば、上述の数2においてキーピクチャユニットKPU#dのKPU期間(KPUperiod)の値はクリップの再生時間として算入しない。その理由は、実際に再生可能な時間(最初のKPUからKPU#(d−1)まで)と数2に基づいて算出した1ショットの再生時間(最初のKPUからKPU#dまで)との間には、最後のKPU#d相当の再生時間(0.4秒以上1秒未満)だけ誤差が発生し得るからである。この算出方法によれば、再生が保証されている映像の再生時間が把握できる。
次に、上述の処理(2)を説明する。処理(1)においては、データが存在するKPU#d1の再生時間は考慮されていない。しかし、KPU#d1内のデータに基づいて再生可能なピクチャが存在し得るため、処理(1)によって算出される再生時間は厳密には誤差が含まれうる。機器から提示された再生時間がこのような誤差を含むことは、特に業務用途や特殊用途の機器においてはあってはならないケースが想定される。そこで、OverlappedKPUFlagフィールド98aの値が“1b”の時には、フレーム/フィールド単位で連続して再生できるビデオ再生時間をKPU#d1を解析して求めればよい。その再生時間を処理(1)によって得られる再生時間に加算することによって、クリップの再生時間を非常に正確に求めることができる。
なお、リムーバブルHDD#1内の最後のKPUに対応するOverlappedKPUFlagフィールド98aの値が“0b”のときは、先頭から最後までの各キーピクチャユニットKPUのKPU期間(KPUperiod)の和をクリップの再生時間(ClipTimeLineDuration95e)の値として採用すればよい。最後のキーピクチャユニットKPU内の全てのピクチャが再生可能であるため、そのKPUのKPU期間(KPUperiod)をクリップの再生時間(ClipTimeLineDuration95e)に算入すべきだからである。
以上説明したように、OverlappedKPUFlagフィールド98aの値に応じてクリップの再生時間(ClipTimeLineDuration95e)の算出する処理を変化させることにより、常に正確な再生時間長を算出できる。
また、OverlappedKPUFlagフィールド98aの値を利用して不完全なキーピクチャユニットKPUを削除するか否かを決定し、削除したときには残されたクリップについてクリップタイムラインを修正してもよい。この「不完全なキーピクチャユニット」とは、全てのピクチャのデータが存在しないキーピクチャユニットをいい、ここではKPU#d2が存在しないKPU#dに相当する。
具体的に説明すると、OverlappedKPUFlagフィールド98aの値が“1b”のときには、不完全なキーピクチャユニットKPU#d1をキーピクチャユニットKPUとして取り扱わないように、TTSファイルから削除し、リムーバブルHDD#1内のクリップタイムラインを修正すればよい。クリップタイムラインの修正は、キーピクチャユニットKPUの数(KPUEntryNumber95b)を減少させること、KPU#dのKPUエントリを削除すること、キーピクチャユニットKPU#d1内のタイムエントリ(TimeEntry)95gを削除すること等を含む。修正後は、リムーバブルHDD#1の00001.TTSファイルの最後のキーピクチャユニットはKPU#(d−1)になり、最初のKPUから最後のKPU#(d−1)までの再生時間の和が1ショットの再生時間になる。よって、上述の数1〜数3を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削除はFAT32ファイルシステム上においても、TTSパケット(192バイト)単位で可能である。
なお、キーピクチャユニットKPU#d2は、リムーバブルHDD#2内ではフラグメントであり、そのデータのみではビデオは復号化できない。よって、リムーバブルHDD#2内のクリップAVストリームファイル(00002.TTS)の最初から、キーピクチャユニットKPU#0の先頭までのフラグメント(データオフセット)がClipTimeLineAddressOffsetフィールド95dに設定される。さらに、そのキーピクチャユニットKPU#0の先頭から、最初に設定されたタイムエントリ#0までの時間オフセットがClipTimeLineTimeOffsetフィールド95cに設定される。なお、ClipTimeLineAddressOffsetフィールド95dの値が0でないときは、前のリムーバブルHDDからのキーピクチャユニットKPUが格納されていることを表すため、巻き戻し再生時にはまず、クリップメタデータ94のリレーション情報を参照することで、直前のクリップがあるか否かを特定することができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能であった場合には、ClipTimeLineAddressOffsetフィールド95dの値が0か否かを確認し、0でないときに前のリムーバブルHDDの最後のキーピクチャユニットKPUに対応するKPUエントリのOverlappedKPUFlagフィールド98aの値をさらに確認して、キーピクチャユニットKPUの跨ぎが発生しているか否かを確実に判定することもできる。
次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用してコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集する際の処理を説明する。
まず図15および図16を参照しながら、コンテンツをリムーバブルHDDに録画するときのカムコーダ100の処理(録画処理)を説明する。
図15は、カムコーダ100によるコンテンツの録画処理の手順を示す。まずステップS151において、カムコーダ100のCPU211は指示受信部215を介して、ユーザから撮影開始の指示を受け取る。そして、ステップS152において、CPU211からの指示に基づいて、エンコーダ203は入力信号に基づいてTSを生成する。なおデジタル放送の録画時には、ステップS151において録画開始の指示を受け取り、ステップS152においてデジタルチューナ201cを用いて録画対象の番組のTSパケットを抽出すると読み替えればよい。
ステップS153では、メディア制御部205は、TS処理部204においてTTSヘッダが付加されたTS(クリップAVストリーム)を、順次リムーバブルHDDに書き込む。そしてメディア制御部205は、ステップS154において、クリップ(TTSファイル)を新規に作成するか否かを判断する。新規に作成するか否かは、記録中のクリップのTTSファイルのサイズが所定値よりも大きいか否かや、リムーバブルHDDの残容量に応じて任意に決定できる。新規にクリップを作成しない場合はステップS155に進み、新規にクリップを生成するときはステップS156に進む。
ステップS155では、TS処理部204は、キーピクチャユニットKPUが生成されるごとに、KPUエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットKPUのすべてのデータはそのクリップのTTSファイル内に書き込まれるため、メディア制御部205はKPUエントリ中のOverlappedKPUFlagフィールドに“0b”を設定する。そしてメディア制御部205は、ステップS157においてKPUエントリおよびタイムエントリを含む時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)をリムーバブルメディアに書き込む。その後、ステップS158において、CPU211は撮影終了か否かを判断する。撮影は、例えば指示受信部215を介して撮影終了指示を受信したとき、次にデータを書き込むべきリムーバブルHDDが存在しないとき等に終了する。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はステップS152に戻り、それ以降の処理が繰り返される。
一方ステップS156では、TS処理部204は、最後に書き込まれたデータによってキーピクチャユニットKPUが完結したか否かを判断する。仮にキーピクチャユニットKPUが完結しなければ、そのキーピクチャユニットKPUの残りのデータは他のリムーバブルHDDに格納されることになる。そのため、キーピクチャユニットKPUのすべてのデータがそのリムーバブルHDD内に書き込まれたか否かを判断するために、このような判断が必要になる。キーピクチャユニットKPUが完結しているときには処理はステップS155に進み、完結していないときには処理はステップS159に進む。
ステップS159では、TS処理部204によってクリップ切り替え処理が行われる。この処理の具体的な内容を、図16に示す。
図16は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ(クリップ)の録画先のメディアを、あるリムーバブルHDDから他のリムーバブルHDDに切り替えたり、同一リムーバブルHDD上で新規クリップを生成する処理である。以下では説明を簡略化するために、クリップの切り替えが、コンテンツの録画先メディアの変更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブルHDDを「第1リムーバブルHDD」と呼び、次にコンテンツが録画されるリムーバブルHDDを「第2リムーバブルHDD」と呼ぶ。
まずステップS161において、CPU211は、第2リムーバブルHDD上に生成されるクリップのクリップ名を決定する。次に、ステップS162において、カムコーダ100は第1リムーバブルHDDに完全に記録できなかったキーピクチャユニットKPUが完結するまでTSを生成する。そして、TS処理部204はTTSヘッダを付加し、メディア制御部205はそのクリップAVストリームを第2リムーバブルHDDに書き込む。
次にステップS163において、メディア制御部205は、完結したKPUのKPUエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットKPUは第1リムーバブルHDDおよび第2リムーバブルHDDに跨って書き込まれるため、メディア制御部205はKPUエントリ中のOverlappedKPUFlagフィールドに“1b”を設定する。
ステップS164において、メディア制御部205は、生成したKPUエントリおよびタイムエントリを含む時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)を、第1リムーバブルHDDに書き込む。そして、ステップS165において、第1リムーバブルHDD上のクリップ・メタデータ(リレーション情報等)を更新する。例えば、メディア制御部205は、第1リムーバブルHDD上のクリップのクリップメタデータに、次のクリップとして第2リムーバブルHDD上のクリップを特定するUMID等を書き込む。また、第2リムーバブルHDD上のクリップのクリップメタデータに、前のクリップとして第1リムーバブルHDD上のクリップを特定するUMID等を書き込む。その後、ステップS166において、メディア制御部205は、今後のコンテンツの書き込み先を第2リムーバブルHDDに設定し、処理が終了する。
次に、図17を参照しながら、カムコーダ100がリムーバブルHDDからコンテンツを再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初から再生するときの処理は、KPUエントリ、タイムエントリ等を設けない従来の処理と同じであるため、その説明は省略する。
図17は、カムコーダ100によるコンテンツの再生処理の手順を示す。ステップS171において、カムコーダ100のCPU211は指示受信部215を介して、ユーザから再生開始時刻の指示を受け取る。
ステップS172において、メディア制御部205は時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)を読み出して、CPU211が再生開始時刻のピクチャを含むキーピクチャユニット(KPU)を特定する。そして、ステップS173において、CPU211は、再生開始時刻に対応するKPUの開始位置を特定する。このKPUの開始位置は、TTSファイル内の復号開始位置(アドレス)を表している。
これらの処理の一例は以下のとおりである。すなわち、CPU211は、再生開始時刻がタイムエントリ#tとタイムエントリ#(t+1)の間の時刻であることを特定し、さらにタイムエントリ#tから起算してmアクセスユニット時間(AUTM)を1単位として何単位離れているかを特定する。
具体的には、まずタイムエントリ#tのKPUEntryReferenceIDフィールド97aの値に基づいて、あるKPU(KPU#kとする)が特定される。そして、タイムエントリ#tが指し示す時刻からKPU#kの先頭キーピクチャの再生が開始されるまでの時間差がTimeEntryTimeOffsetフィールド97cの値に基づいて取得される。その結果、再生開始すべきピクチャがKPU#kの中で最初に表示されるピクチャから何AUTM後か判明する。すると、KPU#kからKPUごとにKPU期間(KPUPeriod)を加算していくことで、再生開始すべきピクチャを含むKPUが特定できる。また、タイムエントリ#tが指し示すKPUの先頭アドレスにKPU#kから再生開始すべきピクチャを含むKPUの直前のKPUまでのKPUSizeを加算していくことで、再生開始時刻に対応するKPUの開始位置を特定できる。なお、「タイムエントリ#tが指し示すKPUの先頭アドレス」は、ClipTimeLineAddressOffsetフィールド95dの値とタイムエントリ#tのKPUEntryStartAddressフィールド97bの値との和を計算することによって取得できる。
なお、上述の説明は、説明の簡略化のためClosedGOP構造(GOP内の全てのピクチャはGOP内のピクチャを参照するのみ)を前提としている。しかしながら、ClosedGOP構造が取れない場合や、保証できない場合には、特定された再生開始時刻を含むKPUの一つ前のKPUから復号を開始してもよい。
次のステップS174では、メディア制御部205はそのキーピクチャユニット(KPU)のKPUEntry中のフラグを読み出し、ステップS175においてOverlappedKPUFlagフィールド98aの値が“1b”か否かを判断する。値が“1b”のときは、キーピクチャユニットKPUが第1および第2リムーバブルHDDにまたがることを意味しており、処理はステップS176に進む。一方値が“0b”のときは、跨らないことを意味しており、処理はステップS177に進む。
ステップS176において、メディア制御部205は第1リムーバブルHDDに格納されたKPUの先頭ピクチャデータからデータを読み出し、TS処理部204がTTSヘッダを除去すると、デコーダ206はそのデータからデコードを開始する。このとき、特定したピクチャによっては、読み出しを開始した第1リムーバブルHDDではなく第2リムーバブルHDDにデータが格納されていることもあるが、復号を正しく行うために2つのクリップ(TTSファイル)を跨ぐKPUの先頭キーピクチャからデコードが行われる。
ステップS177では、メディア制御部205はKPUの先頭ピクチャデータからデータを読み出し、TS処理部204がTTSヘッダを除去すると、デコーダ206はそのデータからデコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブルHDD内に格納されている。
その後、ステップS178では、再生開始時刻に対応するピクチャのデコード終了後に、グラフィック制御部207はそのピクチャから出力を開始する。対応する音声が存在するときには、スピーカ209bもまたその出力を開始する。その後は、コンテンツの最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終了する。
次に、図18および図19を参照しながら、リムーバブルHDDに録画されたコンテンツを編集する処理を説明する。この処理は、カムコーダ100においても実行されるとして説明するが、他には、コンテンツが録画されたリムーバブルHDDが装填されたPC108(図1)等において実行されてもよい。
図18(a)および(b)は、編集によってTTSファイルの先頭部分を削除する前後の管理情報およびクリップAVストリームの関係を示す。図18(a)に示される範囲Dが、削除の対象となる部分である。この範囲Dは、TTSファイルの先頭部分を含む。先頭部分のアドレスをp1とし、p1+D=p4とする。これまで説明したように、クリップAVストリームは複数のファイルに分けて格納されることがあるが、以下の処理は、各TTSファイルの先頭部分を含む削除に対して適用される。
図18(b)は、範囲Dを削除した後の管理情報(クリップタイムライン)およびクリップAVストリームの関係を示す。本実施形態では、範囲Dのすべてを常に削除するのではなく、範囲Dに収まるデータ量のうち、96キロバイトのn倍(n:整数)のデータ量だけを削除する。いま、削除後の先頭データ位置をアドレスp2とすると、(p2−p1)は、(96キロバイト)・nである。また、p2≦p4である。
上述の範囲Dの終端アドレスp4は、ユーザの編集位置を示している。換言すれば、この終端アドレスp4はユーザにとっては後続のストリームの開始点を示している。アドレスp4の値は、(p1+D)の値として表される。さらに、例えばそのアドレスに対応するピクチャの再生開始時刻情報(例えばPTS)を利用して表すこともできる。例えばユーザがアドレスp4を始点とし、後続のアドレスを終点とする編集を行うときには、上述のアドレスp4に対応するピクチャの再生開始時刻情報とともに、p4からのビデオ再生時間長や、開始時刻情報と同様のビデオの再生終了時刻情報によって、終点を特定することができる。ユーザの編集区間を示す情報(開始点・終了点)は、図9のClip Metadata(94)、または、Clip Time Line(95)において管理される。
アドレスp4の値またはそのアドレスに対応する時刻情報を保持することにより、ユーザが指定した範囲Dの後から再生、編集等を開始することができる。特に本実施形態の処理によれば、ユーザが削除を指定した範囲Dのうち、p2からp4までのデータが再生可能な状態で残されることがある。ユーザにとってはp2からp4のデータは削除されており、再生されると違和感を覚える。そこでアドレスp4の値等を保持しておくことにより、p2からp4までの区間の映像が再生されたり、その間を編集開始位置として誤って認識することを確実に防止することができる。アドレスp4の値またはそのアドレスに対応する時刻情報は、図10に示すクリップメタデータ94の記述データ(descriptive)中の再生情報として格納される。
「96キロバイト」は、本実施形態において採用するクラスタサイズ(32キロバイト)と、TTSパケットのパケットサイズ(192バイト)との最小公倍数である。このように処理する理由は、クラスタサイズの整数倍とすることによってリムーバブルHDDに対するデータ削除処理がアクセス単位で実行でき、またTTSパケットのパケットサイズの整数倍とすることによってデータ削除処理がクリップAVストリームのTTSパケット単位で実行できるため、処理を高速化かつ簡易にできるからである。なお、本実施形態ではクラスタサイズを32キロバイトとしているため、96キロバイトを基準として削除単位を決定したが、この値はクラスタサイズや、採用するクリップAVストリームのパケットサイズに応じて変化し得る。
削除処理では、さらにClipTimeLineTimeOffsetフィールド95cおよびClipTimeLineAddressOffsetフィールド95dの値も変更される。これらの値は削除前は0である。削除後は、まずClipTimeLineAddressOffsetフィールド95dに、初めて現れるキーピクチャユニットKPUまでのデータ量が記述される。初めて現れるキーピクチャユニットKPUの格納アドレスをp3とすると、ClipTimeLineAddressOffsetフィールド95dは(p3−p2)の値が記述される。また、ClipTimeLineTimeOffsetフィールド95cに、最初のキーピクチャユニットKPUの中で先頭のキーピクチャの再生時刻から最初のタイムエントリまでの時間差がAUTM単位で記述される。なお、アドレスp2からp3までのクリップAVストリームのパケットは、単独でデコードできるという保証がないため、フラグメントとして扱われ、再生の対象とはされない。
図19は、カムコーダ100によるコンテンツの部分削除処理の手順を示す。まずステップS191において、カムコーダ100のCPU211は指示受信部215を介して、ユーザからTTSファイルの部分削除指示、および、削除範囲Dの指定を受け取る。部分削除指示とは、TTSファイルの先頭部分および/または末尾部分を削除する指示である。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および/または末尾部分を削除する「後方部分削除処理」が行われる。
ステップS192において、前方部分削除処理か否かが判定される。前方部分削除処理を行う場合にはステップS193に進み、前方部分削除でない場合にはステップS195に進む。ステップS193では、メディア制御部205は、削除範囲に相当するデータ量Dのうち、96キロバイトの整数倍のデータ量を先頭から削除する。そしてステップS194において、メディア制御部205は、時間・アドレス変換テーブル(クリップタイムライン)中の、最初のタイムエントリに対する時間オフセットの値(ClipTimeLineTimeOffsetフィールド95cの値)と最初のKPUエントリに対するアドレスオフセット値(ClipTimeLineAddressOffsetフィールド95dの値)とを修正する。その後、処理はステップS195に進む。
ステップS195では、後方部分削除処理か否かが判定される。後方部分削除処理を行う場合にはステップS196に進み、行わない場合にはステップS197に進む。ステップS196では、削除範囲に相当するデータ量のうち、TTSファイルの最後が完全なKPUとなるよう192バイト単位でデータが削除される。これはすなわち、192バイトの整数倍のデータ量のデータが削除されることを意味する。その後処理はステップS197に進む。
ステップS197では、部分削除処理によって変化したタイムエントリ数やKPUエントリ数等を修正する。具体的には、時間・アドレス変換テーブル(ClipTimeLine)中で、実データを伴わなくなったKPUEntryエントリ、およびKPUEntryReferenceIDで参照していたKPUEntryエントリを失ったTimeEntryエントリが削除される。また、TimeEntryNumberフィールド95aの値、KPUEntryNumberフィールド95bの値等の修正処理が行われる。
なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合にもステップS197を経由する。これは、例えばTTSファイルの中間部分の削除処理が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削除処理は本明細書においては特に言及しない。
なお、上述のように部分削除処理はTTSファイルの先頭部分に限られず、TTSファイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の不完全なキーピクチャユニットKPU(図14のKPU#d1)を削除する際に適用される。不完全なキーピクチャユニットKPUは1クリップの最後に存在しているため、「TTSファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全なキーピクチャユニットKPUの先頭からTTSファイルの最後までであり、例えばTTSパケットのパケットサイズ(192バイト)単位で削除する範囲を決定すればよい。クラスタサイズは特に考慮しなくてもよい。なお、TTSファイルの最後の部分は不完全なキーピクチャユニットKPUに限られず、ユーザから範囲の指定を受けること等により、任意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行ってもよいし、一方の処理のみを行ってもよい。
以上、本発明の実施形態を説明した。
本実施形態では、データストリーム等を格納するメディアはリムーバブルHDDであるとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば、非可換メディア、例えばデータ処理装置に内蔵されたHDDであってもよい。
タイムマップ(ClipTimeLine)のデータ構造は、TimeEntryおよびKPUEntryの2層を含むとした。しかし、再生時間と記録アドレスの変換が可能であればこれに限る必要は一切なく、KPUEntryの1層のみからなるタイムマップであっても全く同様である。上述の説明では、OverlappedKPUFlagフィールドを設け、その値に基づいてキーピクチャユニットKPUが複数のファイルを跨っていることを示すとして説明した。しかし、複数のファイルを跨っているか否かは、タイムマップに相当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデータ(リレーション情報など)、クリップのファイル名の命名規則(ファイル名の番号が昇順など)、同一フォルダ内に1ショットの全データ(少なくとも1ショットを構成する全TTSファイルの内、同一記録媒体上に記録されたもの)を格納する等によって、KPUが跨っている、または、跨っている可能性があることを示してもよい。
なお、図2等の各機能ブロックは典型的には集積回路(Large Scale Integrated Circuit;LSI)のチップとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。例えば、図2においては、CPU211を含むシステム制御部250とメディア制御部205とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、システム制御部250にメディア制御部205の機能を与え、物理的に同一のチップによって実現してもよい。また、メディア制御部205およびTS処理部204の機能を集積化して、1つのチップ回路として実現してもよいし、さらにエンコーダ203およびデコーダ206の機能を付加したチップ回路217として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外することにより、複数の符号化方式に容易に対応できる。
システム制御部250は、プログラムROM210等に格納されたコンピュータプログラムを実行することにより、本明細書に記載したメディア制御部205の機能を実現することができる。このときは、メディア制御部205はシステム制御部250の一部の機能として実現される。
なお、上述の「LSI」は、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。
本発明によれば、コンテンツの録画のために、複数ファイルに跨ってコンテンツのデータストリームが格納されることを想定したデータ構造を得ることができる。このデータ構造によれば、機器はどのファイル内のデータであっても容易にアクセスし、再生を開始することができる。またこのデータ構造を利用してさらにファイルの編集を行うことにより、機器は処理の高速化および処理負荷の軽減を実現できる。
本発明は、メディア上でコンテンツのデータストリームを効率的に管理し、そのコンテンツの再生および編集を容易にする技術に関する。
近年、DVD等の光ディスク、ハードディスク等の磁気ディスク、半導体メモリ等のメディアにコンテンツのデジタルデータを書き込み、保存できるデジタル機器(光ディスクレコーダ、カムコーダ等)の普及が進んでいる。このようなコンテンツは、例えば、放送された番組やカムコーダ等によって撮影された映像および音声である。
近年はPCにもコンテンツの記録、再生および編集機能が実装されており、PCも上述のデジタル機器に含めることができる。PCでは、文書データ等を記録するために、従来からハードディスク、光ディスク、半導体メモリ等のメディアが利用されている。したがって、そのようなメディアでは、PCと連携可能なデータ管理構造、例えばFAT(File Allocation Table)を用いたファイルシステムが採用されている。現在多く利用されているFAT32ファイルシステムでは、最大4ギガバイトのサイズを有するファイルを取り扱うことができ、また最大記録可能容量が2テラバイトのメディアを管理することができる。
メディアの最大記録可能容量の増加に伴い、記録されるコンテンツの再生時間が長くなっている。光ディスク、ハードディスク、半導体メモリ等はいわゆるランダムアクセスが可能なメディアであるため、そのようなメディアに長時間のコンテンツのデータストリームを格納するときには、コンテンツの任意の位置から再生できると便利である。例えば特許文献1では、データストリームの先頭から一定の時間間隔ごとに、再生時刻とその時刻に再生されるAVデータの格納アドレスとの対応を規定したタイムマップ情報を生成している。ユーザ指定された開始時刻、終了時刻それぞれを、タイムマップ情報を参照して開始アドレス、終了アドレスに変換し、そのアドレスに格納されているデータを読み出すことにより、その時刻からコンテンツを再生することが可能になっている。
特開平11−155130号公報
コンテンツの再生時間が長くなり、コンテンツの一部を削除する編集処理が頻繁に行われるようになると、従来の処理では編集処理時間が長くなるという問題が生じる。例えば、データストリームの内容を解析し、削除範囲内のピクチャのデータ位置等を特定した後にそのデータを削除すると、解析時間、データ位置の特定時間および削除時間がそれぞれ必要になる。
この問題は、トランスポートストリーム等を構成する固定長のデータパケットに、MPEG規格等による順方向符号化方式および双方向符号化方式で圧縮符号化された映像データを格納しているときに顕著である。例えば、MPEG規格の一連の映像データの一部を削除するとき、まず、編集装置は削除の開始ピクチャおよび終了ピクチャを特定するために、メディアからパケットを読み出してパケット内のデータを解析しなければならない。パケットデータの読み出しは、例えばファイルシステムのクラスタ単位で行われるため、一般には、必要とするパケット以外の不要なパケットも同時に読み出される。よって不要なアクセス時間がかかる。さらに、ピクチャを特定して削除しても、削除直後の開始ピクチャをいわゆるIピクチャに設定しなければならないため、そのピクチャデータの読み出し、デコードおよび再エンコードが必要になる。
本発明の目的は、コンテンツのデータストリームを高速に編集する手段を提供することである。
本発明によるデータ処理装置は、メディアに書き込まれたコンテンツを編集することができる。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部と、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するメディア制御部とを備えている。
前記データストリームは、複数のピクチャから構成され、かつ、基準ピクチャからのデコードを要する復号化単位を1つまたは複数含む再生単位を含んでいる。前記メディア制御部は、データを削除した後のファイル内のデータストリームにおいて初めて現れる再生単位までのデータ量の値を前記メディアに書き込んでもよい。
前記メディアには、データを削除する前のデータストリームに対して、前記コンテンツの一定の再生時間ごとに再生されるピクチャのデータ位置を特定するタイムエントリが予め書き込まれている。前記メディア制御部は、データを削除した後のデータストリームに関し、初めて現れる前記再生単位の先頭から、前記タイムエントリによって特定される初めてのピクチャのデータ位置までのデータ量の値を前記メディアに書き込んでもよい。
前記データストリームは、各々のパケットサイズが192バイトである複数のパケットから構成され、前記メディアには32キロバイトのクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記メディア制御部は、96キロバイトの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記ファイルの末尾を含む部分削除の範囲の指定を受け取るときには、前記ファイルの末尾から、前記部分削除の範囲内であって、かつ前記パケットサイズの整数倍のデータ量のデータを削除してもよい。
前記メディア制御部は、前記部分削除の範囲内であって、前記データストリームの不完全な再生単位のデータを削除してもよい。
本発明によるチップ回路は、メディアに書き込まれたコンテンツを編集する処理を行うためにデータ処理装置に実装される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理装置は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取る受信部を備えている。前記チップ回路は、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを特定する処理と、特定された前記データを削除する指示を出力する処理とを実行する。
本発明によるコンピュータプログラムは、メディアに書き込まれたコンテンツを編集する処理を行うためのデータ処理装置において実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記コンピュータプログラムを実行した前記データ処理装置は、前記ファイルの先頭を含む範囲の指定を受け取るステップと、前記ファイルの先頭から、前記範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを実行する。
本発明によるデータ処理方法は、メディアに書き込まれたコンテンツを編集するために実行される。前記コンテンツは、パケットサイズが同一の複数のパケットから構成されたデータストリームとしてファイルに格納されている。また前記メディアにはクラスタサイズ単位でデータにアクセスされるファイルシステムが構築されている。前記データ処理方法は、前記ファイルの先頭を含む部分削除の範囲の指定を受け取るステップと、前記ファイルの先頭から、前記部分削除の範囲内であって、かつ前記クラスタサイズおよび前記パケットサイズの最小公倍数の整数倍のデータ量のデータを削除するステップとを包含する。
本発明によれば、メディア上のデータストリームの一部のデータを削除する際に、ファイルシステムのクラスタサイズとデータストリームのパケットサイズとの最小公倍数を基準として、その整数倍のデータ量のデータを削除する。クラスタサイズの整数倍とすることによってメディアに対するデータ削除処理がアクセス単位で実行でき、またパケットのパケットサイズの整数倍とすることによってデータ削除処理がパケット単位で実行できるため、処理を高速化できる。
また、データストリーム中に格納されていた再生単位のうち、データを削除した後のデータストリームにおいて初めて現れる再生単位までのデータ量の値を保持するため、削除処理において削除直後のピクチャをIピクチャに変更する必要はない。よってIピクチャへの変更に必要な処理を排除でき、編集処理時間を短縮できる。
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。
図1は、リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す。図1では、データ処理装置は、カムコーダ100−1、カメラ付き携帯電話100−2、PC108として記載されている。カムコーダ100−1およびカメラ付き携帯電話100−2は、ユーザが撮影した映像および音声を受け取ってデジタルデータストリームとして符号化し、そのデータストリームを、それぞれリムーバブルメディア112−1および112−2に書き込む。各リムーバブルメディアに書き込まれたデータは、リムーバブルメディア上に構築されたファイルシステム上の「ファイル」として取り扱われる。例えば図1では、リムーバブルメディア112−2に複数のファイルが格納されていることが示されている。
各リムーバブルメディア112−1および112−2はデータ処理装置から取り外し可能であり、例えばDVD、BD(Blu−ray Disc)等の光ディスク、マイクロドライブ等の超小型ハードディスク、半導体メモリ等である。PC108は、各リムーバブルメディア112−1および112−2を装填することが可能なスロットを備えている。PC108は、装填されたリムーバブルメディア112−1、112−2からデータを読み出し、再生処理および編集処理等を実行する。
リムーバブルHDD112では、FAT32ファイルシステムによりデータ管理が行われる。FAT32ファイルシステムでは、1ファイルのファイルサイズの最大値は、例えば4ギガバイトである。よって、FAT32ファイルシステムではデータのサイズが4ギガバイトを超えるときは2以上のファイルに分けて書き込まれる。例えば、容量が8ギガバイトのリムーバブルHDD112には4ギガバイトのファイルが2つ格納され得る。16ギガバイトのリムーバブルHDD112には4ギガバイトのファイルが4つ格納され得る。なお、分割して書き込まれる単位はファイルサイズの最大値でなくてもよく、ファイルサイズの最大値以下のサイズであればよい。
以下の説明では、コンテンツのデータストリームをリムーバブルメディアに書き込むデータ処理装置は、カムコーダであるとして説明する。また、リムーバブルメディアに格納されたデータストリームを再生し編集するデータ処理装置はPCであるとして説明する。
さらに、リムーバブルメディア112−1は超小型のリムーバブルハードディスクであるとする。リムーバブルメディアは、周知のマイクロドライブ等のようにハードディスクを駆動してデータの書き込みおよび読み出しを行うための機構(ドライブ機構)を含む。以下では、リムーバブルメディア112−1を「リムーバブルHDD112」と記述する。説明を簡便化するため、リムーバブルHDD112は4ギガバイトの容量を持つとする。この結果、4ギガバイトを超えるコンテンツは、2以上のリムーバブルHDDに分けて書き込まれる。しかしながら、リムーバブルHDDが4ギガバイト以上の容量を持ち、そこに4ギガバイトを超えるコンテンツが書き込まれる場合にも、2以上のファイルに分割して同じリムーバブルHDDに書き込めばよい。1つのコンテンツが複数のファイルに分けて記録される本質的な点においては、いずれも同じである。単に記録するメディアが同一であるか否かの違いにすぎない。リムーバブルHDD112のクラスタサイズは、例えば32キロバイトである。「クラスタ」とは、データの書き込みおよび読み出しを行う際の最小のアクセス単位である。
図2は、カムコーダ100の機能ブロックの構成を示す。カムコーダ100には、複数のリムーバブルHDD112a、112b、・・・、112cを同時に装填することが可能であり、ユーザが撮影した映像および音声に関するコンテンツのデータストリーム(クリップAVストリーム)を、リムーバブルHDD112a、112b、・・・、112cに順に書き込む。
カムコーダ100は、CCD201a、マイク201bおよびデジタル放送を受信するデジタルチューナ201cと、ADコンバータ202と、MPEG−2エンコーダ203と、TS処理部204と、メディア制御部205と、MPEG−2デコーダ206と、グラフィック制御部207と、メモリ208と、液晶表示装置(LCD)209aおよびスピーカ209bと、CPUバス213と、ネットワーク制御部214と、指示受信部215と、インターフェース(I/F)部216と、システム制御部250とを含む。
以下、各構成要素の機能を説明する。CCD201aおよびマイク201bは、それぞれ映像および音声のアナログ信号を受け取る。CCD201aは、映像をデジタル信号として出力する。マイク201bは、音声のアナログ信号を出力する。ADコンバータ202は入力されたアナログ音声信号をデジタル信号に変換してMPEG−2エンコーダ203に供給する。
デジタルチューナ201cは、アンテナ(図示せず)から1以上の番組が含まれるデジタル信号を受け取る受信部として機能する。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。デジタルチューナ201cは、受信したトランスポートストリームから特定の番組(録画対象のチャンネルの番組)のパケットを抜き出して出力する。出力されるストリームもまたトランスポートストリームであるが、当初のストリームと区別するために「パーシャルトランスポートストリーム」と呼ぶこともある。トランスポートストリームのデータ構造は、図3〜図5を参照しながら後述する。
本実施形態においては、カムコーダ100はデジタルチューナ201cを構成要素としているが、これは必須の要件ではない。図2のカムコーダ100の構成は、図1において言及したカメラ付き携帯電話100−2等にも適用できるため、デジタル放送の受信および視聴が可能なカメラ付き携帯電話等についての構成要素と考えればよい。
MPEG−2エンコーダ203(以下「エンコーダ203」と記述する)は、録画の開始指示を受け取ると、供給された映像および音声の各デジタルデータをMPEG規格に基づいて圧縮符号化する。本実施形態においては、エンコーダ203は、映像データをMPEG−2形式に圧縮符号化してトランスポートストリーム(以下「TS」とも記述する)を生成し、TS処理部204に送る。この処理は、エンコーダ203が録画の終了指示を受け取るまで継続される。エンコーダ203は双方向圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ(図示せず)等を有している。なお、映像および音声の符号化形式を一致させる必要はない。例えば、映像はMPEG形式で圧縮符号化し、音声はAC−3形式で圧縮符号化するとしてもよい。
本実施形態では、カムコーダ100はTSを生成し処理する。そこでまず、図3〜図5を参照しながら、TSのデータ構造を説明する。
図3は、トランスポートストリーム(TS)20のデータ構造を示す。TSパケットは、例えば、圧縮符号化されたビデオデータが格納されたビデオTSパケット(V_TSP)30、符号化されたオーディオデータが格納されたオーディオTSパケット(A_TSP)31の他、番組表(プログラム・アソシエーション・テーブル;PAT)が格納されたパケット(PAT_TSP)、番組対応表(プログラム・マップ・テーブル;PMT)が格納されたパケット(PMT_TSP)およびプログラム・クロック・リファレンス(PCR)が格納されたパケット(PCR_TSP)等を含む。各TSパケットのデータ量は188バイトである。また、PAT_TSP、PMT_TSP等のTSの番組構成を記述するTSパケットを一般に、PSI/SIパケットと呼ぶ。
以下、本発明の処理に関連するビデオTSパケットおよびオーディオTSパケットを説明する。図4(a)はビデオTSパケット30のデータ構造を示す。ビデオTSパケット30は、一般に4バイトのトランスポートパケットヘッダ30a、および、184バイトのトランスポートパケットペイロード30bを有する。ペイロード30bにはビデオデータ30bが格納されている。一方、図4(b)は、オーディオTSパケット31のデータ構造を示す。オーディオTSパケット31も同様に、一般に4バイトのトランスポートパケットヘッダ31a、および、184バイトのトランスポートパケットペイロード31bを有する。オーディオデータ31bはトランスポートパケットペイロード31bに格納されている。TSパケットヘッダにはアダプテーションフィールドと呼ばれるデータを追加してもよく、TSパケットに格納するデータをアライメントする場合などに利用される。この場合TSパケットのペイロード(30b、31b)は184バイト未満となる。
上述の例から理解されるように、一般にTSパケットは4バイトのトランスポートパケットヘッダと、184バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子(Packet IDentifier;PID)が記述されている。例えば、ビデオTSパケットのPIDは“0x0020”であり、オーディオTSパケットのPIDは“0x0021”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図5(a)〜(d)は、ビデオTSパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図5(a)に示すように、TS40は、ビデオTSパケット40a〜40dを含む。なお、TS40には、他のパケットも含まれ得るが、ここではビデオTSパケットのみを示している。ビデオTSパケットは、ヘッダ40a−1に格納されたPIDによって容易に特定される。
ビデオデータ40a−2等の各ビデオTSパケットのビデオデータから、パケット化エレメンタリストリームが構成される。図5(b)は、パケット化エレメンタリストリーム(PES)41のデータ構造を示す。PES41は、複数のPESパケット41a、41b等から構成される。PESパケット41aは、PESヘッダ41a−1およびPESペイロード41a−2から構成されており、これらのデータがビデオTSパケットのビデオデータとして格納されている。
PESペイロード41a−2は、それぞれが1つのピクチャのデータを含んでいる。PESペイロード41a−2から、エレメンタリストリームが構成される。図5(c)は、エレメンタリストリーム(ES)42のデータ構造を示す。ES42は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
図5(c)に示すピクチャヘッダ42aには、その後に配置されたピクチャデータ42bのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ42cにはピクチャデータ42dのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Iピクチャ(Intra−coded picture)、Pピクチャ(Predictive−coded picture)またはBピクチャ(Bidirectionally−predictive−coded picture)などを表す。種別がIピクチャであれば、そのピクチャコーディングタイプは、例えば“001b”などと決められている。
ピクチャデータ42b、42d等は、そのデータのみによって、または、そのデータとその前および/または後に復号化されるデータとによって構築可能な1枚分のフレームのデータである。例えば図5(d)は、ピクチャデータ42bから構築されるピクチャ43aおよびピクチャデータ42dから構築されるピクチャ43bを示す。
TSに基づいて映像を再生する際、カムコーダ100はビデオTSパケットを取得して上述の処理にしたがってピクチャデータを取得し、映像を構成するピクチャを取得する。これにより映像をLCD209a上に再生することができる。
上述のエンコーダ203は、映像コンテンツに関しては図5(d)、(c)、(b)および(a)に示す順序でTSを生成するといえる。
次に、カムコーダ100のTS処理部204(図2)を説明する。TS処理部204は、動画の記録時にはエンコーダ203からTSを受け取り、またはデジタル放送番組の録画時にはデジタルチューナ201cからTSを受け取って、クリップAVストリームを生成する。クリップAVストリームとは、リムーバブルHDD112a等への格納のために所定の形式を有するデータストリームである。本明細書では、リムーバブルHDDに格納されたクリップAVストリームのファイルには拡張子TTS(“Timed TS”を意味する)を付している。クリップAVストリームは、到着時刻情報を付加したTSとして実現される。また、TS処理部204は、コンテンツの再生時には、リムーバブルHDD112a等から読み出されたクリップAVストリームをメディア制御部205から受け取り、そのクリップAVストリームに基づいてTSを生成してMPEG−2デコーダ206に出力する。
以下では図6を参照しながら、TS処理部204の処理に関連するクリップAVストリームを説明する。図6は、クリップAVストリーム60のデータ構造を示す。クリップAVストリーム60は、複数のTTSパケット61から構成される。TTSパケット61は、4バイトのTTSヘッダ61aと、188バイトのTSパケット61bとから構成される。すなわちTTSパケット61は、TTSヘッダ61aをTSパケット61bに付加して生成される。なおTSパケット61bは、図3、図4(a)および(b)等に関連して説明したTSパケットである。
TTSヘッダ61aは、2ビットの予約領域61a−1と、30ビットの到着時刻情報(Arrival Time Stamp;ATS)61a−2とから構成されている。この到着時刻情報61a−2は、エンコーダ203から出力されたTSパケットがTS処理部204に到着した時刻を示している。TS処理部204は、この時刻に基づいてデコーダ206にTSパケットを出力する。
次に、上述のクリップAVストリーム60を生成するTS処理部204の構成を説明する。図7は、TS処理部204の機能ブロックの構成を示す。TS処理部204は、TTSヘッダ付加部261と、クロックカウンタ262と、PLL回路263と、バッファ264と、TTSヘッダ除去部265とを有する。
TTSヘッダ付加部261は、TSを受け取り、そのTSを構成するTSパケットの前にTTSヘッダを付加し、TTSパケットとして出力する。TTSヘッダ中の到着時刻情報61a−2に記述されるTSパケットの到着時刻は、TTSヘッダ付加部261に与えられる基準時刻からのカウント値(カウント情報)に基づいて特定される。
クロックカウンタ262およびPLL回路263は、TTSヘッダ付加部261がTSパケットの到着時刻を特定するために必要な情報を生成する。まずPLL回路263は、TSに含まれるPCRパケット(図2のPCR_TSP)を抽出して、基準時刻を示すPCR(Program Clock Reference:プログラム時刻基準参照値)を取得する。PCRの値と同じ値がカムコーダ100のシステム基準時刻STC(System Time Clock)として設定され、STCが基準時刻とされる。システム基準時刻STCのシステムクロックの周波数は27MHzである。PLL回路263は、27MHzのクロック信号をクロックカウンタ262に出力する。クロックカウンタ262はクロック信号を受け取り、そのクロック信号をカウント情報としてTTSヘッダ付加部261に出力する。
バッファ264は、ライトバッファ264aおよびリードバッファ264bを有する。ライトバッファ264aは、送られてきたTTSパケットを逐次保持し、合計のデータ量が所定値(例えばバッファの全容量)になったときに、後述のメディア制御部205に出力する。このとき出力される一連のTTSパケット列(データストリーム)を、クリップAVストリームと呼ぶ。一方、リードバッファ264bは、メディア制御部205によってリムーバブルHDD112a等から読み出されたクリップAVストリームを一時的にバッファして、TTSパケット単位で出力する。
TTSヘッダ除去部265は、TTSパケットを受け取って、TTSヘッダを除去することによりTTSパケットをTSパケットに変換し、TSとして出力する。留意すべきは、TTSヘッダ除去部265は、TTSヘッダに含まれているTSパケットの到着時刻情報ATSを抽出して、到着時刻情報ATSとクロックカウンタ262から与えられるタイミング情報とに基づいて、元の到着時刻に対応するタイミング(時間間隔)でTSパケットを出力することである。リムーバブルHDD112a等はランダムアクセスが可能であり、データは不連続にディスク上に配列される。よって、TSパケットの到着時刻情報ATSを利用すれば、TS処理部204は、データの格納位置にかかわらず記録時のTSパケットの到着タイミングと同じタイミングでTSパケットを出力することができる。なおTTSヘッダ除去部265は、読み出したTSの基準時刻を指定するために、例えば最初のTTSパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ262に送る。これにより、クロックカウンタ262においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
カムコーダ100では、TS処理部204を設けて、TSにTTSヘッダを付加してクリップAVストリームを生成するとした。しかし、符号化レートが固定されているCBR(Constant Bit Rate)で符号化する場合には、TSパケットのデコーダ入力時刻が固定間隔であるため、TS処理部204を省略してTSをリムーバブルHDD112に書き込むこともできる。
再び図2を参照しながら、カムコーダ100の各構成要素を説明する。
メディア制御部205は、TS処理部204からクリップAVストリームを受け取り、いずれかのリムーバブルHDD112a、112b、・・・、112cに出力するかを決定して、そのリムーバブルHDDに出力する。メディア制御部205は、書き込み中のリムーバブルHDDの記録可能容量をモニタし、残された記録可能容量が所定値以下になったときには出力先を他のリムーバブルHDDに変更し、クリップAVストリームの出力を継続する。このとき、1つのコンテンツを構成するクリップAVストリームが2つのリムーバブルHDD112に跨って格納されることになる。
メディア制御部205は、本発明の主要な特徴の1つであるクリップタイムライン(ClipTimeLine)テーブルを生成する。そしてそのテーブルに、クリップAVストリームの再生単位であるキーピクチャユニットが、2つのファイルに跨って格納されているか否かを示すフラグを記述する。なお、メディア制御部205のより詳細な動作、および、メディア制御部205によって生成されるクリップタイムラインテーブルの詳細なデータ構造は後述する。
なお、クリップAVストリームをリムーバブルHDD112に書き込む処理は、メディア制御部205から書き込み指示およびクリップAVストリームを受け取ったリムーバブルHDD112が行っている。また、クリップAVストリームを読み出す処理は、メディア制御部205から読み出し指示を受けたリムーバブルHDD112が行っている。しかし、説明の便宜のため、以下ではメディア制御部205がクリップAVストリームを書き込み、読み出すとして説明する。
MPEG−2デコーダ206(以下「デコーダ206」と記述する)は、供給されたTSを解析して、TSパケットから映像および音声の圧縮符号化データを取得する。そして、映像の圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部207に供給する。またデコーダ206は、音声の圧縮符号化データを伸長して音声信号を生成し、音声信号をスピーカ209bに出力する。デコーダ206は、TSに関してMPEG規格で規定されているシステムターゲットデコーダ(T−STD)の要件を満たすように構成されている。
グラフィック制御部207には内部演算用のメモリ208が接続されており、オン・スクリーン・ディスプレイ(On Screen Display;OSD)機能を実現できる。例えば、グラフィック制御部207は種々のメニュー画像と映像とを合成した映像信号を出力することができる。液晶表示装置(LCD)209aは、グラフィック制御部207から出力された映像信号をLCD上に表示する。スピーカ209bは、音声信号を音として出力する。コンテンツは、LCD209aおよびスピーカ209bを介して再生され、視聴の対象となる。なお、映像信号および音声信号の出力先は、それぞれLCD209aおよびスピーカ209bに限られない。例えば映像信号および音声信号は、外部出力端子(図示せず)を経てカムコーダ100と別体のテレビやスピーカに伝送されてもよい。
CPUバス213はカムコーダ100内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、CPUバス213には、後述するシステム制御部250の各構成要素も接続されている。
ネットワーク制御部214は、カムコーダ100をインターネット等のネットワーク101に接続するためのインターフェイスであり、例えば、イーサネット(登録商標)規格に準拠した端子およびコントローラである。ネットワーク制御部214は、ネットワーク101を介してデータを授受する。例えば、ネットワーク制御部214は、撮影され生成されたクリップAVストリームをネットワーク101を介して放送局に伝送してもよい。または、ネットワーク制御部214は、カムコーダ100の動作を制御するためのソフトウェアプログラムが更新されたときは、更新されたプログラムをネットワーク101を介して受け取ってもよい。
指示受信部215は、カムコーダ100の本体部に設けられた操作ボタンである。指示受信部215は、ユーザから、例えば録画の開始/停止、再生の開始/停止等の指示を受け取る。
インターフェース(I/F)部216は、カムコーダ100が他の機器と通信するためのコネクタおよびその通信を制御する。I/F部216は、例えばUSB2.0規格の端子、IEEE1394規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、カムコーダ100は、USB2.0規格またはIEEE1394規格の端子を介してPC108や、他のカムコーダ(図示せず)、BD/DVDレコーダ、PC等と接続される。
システム制御部250は、カムコーダ100内の信号の流れを含む全体的な処理を制御する。システム制御部250は、プログラムROM210と、CPU211と、RAM212とを有している。それぞれはCPUバス213に接続されている。プログラムROM210にはカムコーダ100を制御するためのソフトウェアプログラムが格納されている。
CPU211は、カムコーダ100の全体の動作を制御する中央制御ユニットである。CPU211は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、CPUバス213を介して各構成要素に出力する。メモリ212は、CPU211がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、CPU211は、CPUバス213を使用してプログラムROM210からプログラムをランダムアクセスメモリ(RAM)212に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、CD−ROM等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、PC、カメラ、マイク等を利用して構成されたコンピュータシステムを、本実施形態によるカムコーダ100と同等の機能を有する機器として動作させることができる。本明細書では、そのような機器もまたデータ処理装置と呼ぶ。
次に、図8(a)〜(c)を参照しながら、カムコーダ100において撮影された、映像および音声に関するコンテンツのデータ管理構造を説明する。図8(a)は、本実施形態における1コンテンツの概念を示す。撮影の開始から終了までの期間に得られたコンテンツを、1ショットという。図8(b)は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。1ショット、すなわち1つのコンテンツは、複数のクリップa〜cに分けて各リムーバブルHDD112a〜112cに格納することができる(1つのクリップで完結してもよい)。1つのクリップは、クリップメタデータ81と、タイムマップ82と、クリップAVストリーム83の一部(部分ストリーム)とを含む。クリップAVストリーム83は、部分ストリーム83a〜83cから構成されており、クリップa〜cのそれぞれに含まれる。図8(b)には3つのクリップa〜cが記載されているが、各クリップの構成は共通しているため、ここではクリップaを例に挙げて説明する。
クリップaは、クリップメタデータaと、タイムマップaと、部分ストリームaとを含む。このうち、クリップメタデータaおよびタイムマップaは管理情報であり、部分ストリームaがクリップAVストリーム83を構成するデータである。クリップAVストリーム83は原則として1つのファイルに格納されるが、FAT32のファイルサイズの最大値を超えるときには複数のTTSファイルに格納される。図8(b)では、3つの部分ストリーム83a、83bおよび83cが別個のファイルに格納される。なお本実施形態では、各部分ストリームのファイルサイズをFAT32ファイルシステムにおけるファイルサイズの最大値(4ギガバイト)とすると、リムーバブルHDD112a〜cの記録可能容量がなくなって管理情報をリムーバブルHDD112に書き込みできなくなるため、各部分ストリームのファイルサイズは4ギガバイトよりも小さくなることに留意されたい。さらに、TTSファイルは整数個のTTSパケットから構成されるとし、上記ファイルシステムからの制限である4ギガバイト未満であり、かつ、TTSパケット(192バイト)の整数倍としてもよい。
クリップメタデータaはXML形式で記述されており、コンテンツの再生に必要な情報、例えば映像/音声フォーマット等が規定される。クリップメタデータaの詳細は、後に図10を参照しながら詳述する。
タイムマップaは、再生単位ごとの、表示時刻とその格納位置(アドレス)との関係を規定したテーブルである。本明細書では、このタイムマップを「クリップタイムライン」(ClipTimeLine)と呼び、クリップタイムラインが格納されたファイルの拡張子に“CTL”を付して図示している。クリップタイムラインの詳細は、後に図12〜14を参照しながら詳述する。
部分ストリームaは、図6に示すように複数のTTSパケットから構成される。
なお、1ショットの間にクリップAVストリーム83が複数の部分ストリーム83a〜83cのファイルに格納されたときには、TSパケットの転送タイミングを決定するATSのクロックカウンタ262(図7)がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ262(図7)は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。したがって、クリップAVストリーム83を構成する各TTSパケット中の到着時刻情報ATSは、1つのショットを構成する連続する2つのTTSファイルの境界において連続している。
図8(c)は、3つのリムーバブルHDD112a〜112cを示す。各クリップa〜cを構成するデータのファイルが各リムーバブルHDD112a〜112cに書き込まれる。
次に、リムーバブルHDD112内にファイルがどのように格納されるかを説明する。図9は、リムーバブルHDD112内の階層化されたディレクトリ構造を示す。コンテンツの管理情報とクリップAVストリームのファイルは、最上層のルート(ROOT)90内のコンテンツ(Contents)フォルダ91以下に格納される。より具体的には、コンテンツフォルダ91直下のデータベース(Database)フォルダ92には、管理情報であるクリップメタデータ94のXML形式ファイル、および、クリップタイムライン95のCTL形式ファイルが格納される。一方、コンテンツフォルダ91直下のTTSフォルダ93には、クリップAVストリーム(TimedTS)96のTTS形式ファイルが格納される。
なお、コンテンツフォルダ91には、さらにMXF形式の映像のストリームデータを格納するビデオフォルダ(Video)、MXF形式の音声のストリームデータを格納するオーディオフォルダ(Audio)、BMP形式のサムネイル画像を格納するアイコンフォルダ(Icon)、WAVE形式のボイスメモのデータを格納するボイスフォルダ(Voice)等が設けられてもよく、既存のカムコーダの記録フォーマット等に対応させることができる。
続いて、図10〜14を参照しながら、クリップメタデータ94およびクリップタイムライン95に記述されたデータの内容を説明する。
図10は、クリップメタデータ94に含まれる情報の内容を示す。クリップメタデータ94は、構成データ(“Structural”)および記述データ(“Descriptive”)の2種類に分類される。
構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のUMID(Unique Material IDentifier)が記述される。UMIDは、例えば、コンテンツが生成された時刻とそれを生成した機器のMAC(Media Access Control)アドレスを組み合わせて生成される。さらにUMIDは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦UMIDが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのUMIDとは異なる値が付加される。よってUMIDを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。
エッセンスリストには、映像および音声の復号化に必要な情報(ビデオ情報およびオーディオ情報)が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はMPEG−2方式である。
リレーション情報は、図8(b)に示すような複数のクリップ81a〜81cが存在するときのクリップの間の関係を規定する。具体的には各クリップメタデータ94には、そのショットの先頭のクリップを特定する情報、そのクリップの直前および直後のクリップを特定する情報がそれぞれ記述される。すなわちリレーション情報は、複数クリップの各々に対応するクリップAVストリーム(部分ストリーム)の再生の先後関係または再生順序を規定しているということができる。クリップを特定する情報は、例えば、UMIDおよびそのリムーバブルHDD112固有のシリアル番号とによって規定される。
記述データには、アクセス情報、デバイス、撮影情報、再生情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。再生情報は、再生開始時刻、再生時間長等を特定する情報である。
次に、クリップタイムライン95を説明する。クリップタイムライン95では、キーピクチャおよびキーピクチャユニットという概念を導入して、それらに関する情報を規定している。そこでまず図11を参照しながら、キーピクチャおよびキーピクチャユニットを説明する。
図11は、キーピクチャおよびキーピクチャユニットの関係を示す。図11では、I、BおよびPの各ピクチャを表示される順序で記載している。キーピクチャユニット(Key Picture Unit;KPU)は、映像に関して規定されるデータ再生単位である。図11では、キーピクチャユニットKPUの表示は、キーピクチャ44から開始され、Bピクチャ45において終了する。この間にはMPEG規格のグループ・オブ・ピクチャ(GOP)が1以上含まれている。Bピクチャ45の次のIピクチャ46から、次のキーピクチャユニットKPUの表示が始まる。各キーピクチャユニットの映像再生時間は、0.4秒以上、かつ、1秒以下である。ただし、1ショットの最後のキーピクチャユニットは1秒以下であればよい。撮影の終了タイミングによっては0.4秒に満たないこともあるからである。上記はGOP先頭のIピクチャから再生が開始されるとしているが、Bピクチャから再生が開始されるGOP構造の場合には、この限りではない。KPU期間(KPUPeriod)は、そのKPUに格納される全ピクチャの再生時間を示しているためである。
キーピクチャユニットの先頭に位置するキーピクチャ44、46は、MPEG規格におけるシーケンスヘッダコード(sequence_header_code)およびグループスタートコード(group_start_code)を含むビデオに関するアクセス単位である。例えば、キーピクチャユニットはMPEG2圧縮符号化されたIピクチャの画像(フレーム画像または1組の2フィールド画像)または、圧縮符号化されたIフィールドおよびPフィールドの画像である。
また本実施形態では、TSに付加されたPTSを用いてKPU期間(KPUperiod)を定義している。KPU期間は、次のキーピクチャユニットKPUの中で最初に表示されるピクチャの表示時刻(PTS)と、そのKPUの中で最初に表示されるピクチャの表示時刻(PTS)との差分値である。図11では、キーピクチャ44の時刻をPTS(N)とし、キーピクチャ46の時刻をPTS(N+1)としたとき、KPU期間(N)は、PTS(N+1)−PTS(N)として定義される(ともにキーピクチャが表示開始ピクチャとなっている場合)。なお、KPU期間の定義から明らかなように、あるKPU期間の値を決定するためには、次のキーピクチャユニットKPUのピクチャが圧縮符号化され、最初に表示されるピクチャの再生時刻(PTS)が確定しなければならない。よって、あるキーピクチャユニットKPUに対するKPU期間は、次のキーピクチャユニットの生成が開始された後に定まる。なお、ショットで最後のKPU期間が必要な場合もあるため、符号化したピクチャの表示時間を積算していく方法も可能である。その場合には、次のKPUの生成開始を待たずともKPU期間を決定することが可能である。
次に、図12(a)〜(c)を参照しながら、クリップタイムライン(ClipTimeLine)を説明する。図12(a)は、クリップタイムライン(ClipTimeLine)95のデータ構造を示す。クリップタイムライン95は、拡張子に“CTL”を有するファイルとして各リムーバブルHDD112に書き込まれる。
クリップタイムライン95は、再生単位ごとの、表示時刻とその格納位置(アドレス)との関係を規定したテーブルである。「再生単位」は、上述のキーピクチャユニットKPUに対応する。
クリップタイムライン95には、複数のフィールドが規定されている。例えば、クリップタイムライン95には、TimeEntryNumberフィールド95a、KPUEntryNumberフィールド95b、ClipTimeLineTimeOffsetフィールド95c、ClipTimeLineAddressOffsetフィールド95d、ClipTimeLineDurationフィールド95e、StartSTCフィールド95f、TimeEntryフィールド95g、KPUEntryフィールド95h等を含む。各フィールドには所定のバイト数が割り当てられ、それぞれその値に応じた特定の意味を規定している。
例えば、TimeEntryNumberフィールド95aにはタイムエントリの数が記述され、KPUEntryNumberフィールド95bにはKPUエントリの数が記述される。ただしTimeEntryフィールド95gおよびKPUEntryフィールド95hは、後述のタイムエントリの数およびKPUエントリの数に応じてデータサイズが変動し得る。
図12(b)は1タイムエントリに関するTimeEntryフィールド95gのデータ構造を示す。TimeEntryフィールド95gには、対応するタイムエントリに関する属性を示す情報が複数のフィールド(KPUEntryReferenceIDフィールド97a、KPUEntryStartAddressフィールド97bおよびTimeEntryTimeOffsetフィールド97c)に記述されている。
また、図12(c)は1KPUエントリに関するKPUEntryフィールド95hのデータ構造を示す。KPUEntryフィールド95hには、対応するキーピクチャユニットKPUに関する属性を示す情報が複数のフィールド(OverlappedKPUFlagフィールド98a、KeyPictureSizeフィールド98b、KPUPeriodフィールド98cおよびKPUSizeフィールド98d)に記述されている。
ここで、図13(a)および(b)を参照しながら、クリップタイムライン95に含まれる主要なフィールドに規定されるデータの意味を説明する。
図13(a)は、タイムエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す。図13(a)の横軸の1目盛りは1アクセスユニット時間(Access Unit TiMe;AUTM)を示している。これは1ピクチャの表示時間に対応する。ここでいう「ピクチャ」とはどのようなビデオを対象とするかに応じて異なる。すなわち、「ピクチャ」は、プログレッシブビデオに対しては1枚のプログレッシブ走査のフレーム画像に対応し、インターレースビデオに対してはインターレース走査のフィールド画像(1フィールド)に対応する。例えば24000/1001秒間隔で表示されるプログレッシブビデオ(つまり23.97p)では、1AUTMは1/(24000/1001) 秒 = 1126125 clocks/27MHzと表記される。
ここでまず、1ショットにn個のクリップが含まれるとしたときの時間の関係を説明する。まず各クリップの再生時間長は、それぞれのClipTimeLineDurationフィールド95eに記述される。この値はAUTMを利用して記述される。すべてのクリップについてのClipTimeLineDurationフィールド95eの値の和を計算すると、1ショットの再生時間長(撮影時間長)が得られる(数1)。この時間長もまた、AUTMを利用して記述される。
(数1)
1ショットの再生時間長=ΣClipTimeLineDuration
一方、図13(a)に示すKPU#0から#(k+1)までが1クリップに含まれるとすると、上述の各クリップのClipTimeLineDurationフィールド95eは、そのクリップに含まれる全てのキーピクチャユニットKPUのKPU期間(KPUperiod)フィールド98cの値の総和として得られる(数2)。上述のように、KPU期間(KPUperiod)はAUTM値を用いて表記されるため、ClipTimeLineDurationフィールド95eもAUTM表記である。
(数2)
ClipTimeLineDuration=ΣKPUperiod
各KPU期間(KPUperiod)フィールド98cの値は、上述のとおり、そのキーピクチャユニットKPUに含まれるピクチャのビデオ表示時間(AUTM値)の和に対応する(数3)。
(数3)
KPUperiod=KPU内のビデオ総表示時間
「タイムエントリ」(TimeEntry)とは、一定の固定時間(例えば5秒)ごとに設定され、その位置から再生を開始することが可能な時間軸上の飛び込み点を示す。タイムエントリの設定に関連して、先頭のキーピクチャユニットKPU#0の再生開始時刻を0としたとき、最初に設定されたタイムエントリ#0までの時間オフセットがClipTimeLineTimeOffsetフィールド95cに設定される。また、各タイムエントリの設定時刻に再生されるキーピクチャユニットKPUを識別する情報がKPUEntryReferenceIDフィールド97aに記述され、そのキーピクチャユニットKPUの先頭からそのタイムエントリの設定時刻までの時間オフセットを示す情報がTimeEntryTimeOffsetフィールド97cに記述される。
例えば、タイムエントリ#tが指定されると、(ClipTimeLineTimeOffsetフィールド95cの値)+(タイムエントリの間隔・t)を計算することにより、そのタイムエントリ#tが設定された時刻、すなわち先頭キーピクチャユニットKPU#0の先頭からの経過時間を得ることができる。
また、さらに以下の方法によって任意の再生時刻から再生を開始することもできる。すなわち、ユーザから再生を開始したい時刻の指定を受け取ると、その時刻は、周知の変換処理を利用してMPEG規格上の時間情報であるPTS値に変換される。そして、そのPTS値が割り当てられたピクチャから、再生が開始される。なおPTS値は、ビデオTSパケット(V_TSP)30のトランスポートパケットヘッダ30a(図4(a))内に記述されている。
本実施形態では、1つのクリップAVストリームが複数の部分ストリームに分けられているため、各クリップ内の部分ストリーム先頭の再生開始時刻(PTS)が0でないことがある。そこで、クリップタイムライン95のStartSTCフィールド95f(図12(a))には、そのクリップ内の先頭KPUの中で最初に表示されるピクチャの再生時刻情報(PTS)が記述されている。そのピクチャのPTS値と指定された時刻に対応するPTS値とに基づいて、再生開始すべきピクチャまでのPTS(AUTM)差分値が得られる。なお、各ピクチャに割り振られているPTS値のデータ量と、StartSTCフィールド95fに規定されているPTS値のデータ量とを一致させることが好ましく、例えば33ビットで表記される。
上述の差分値がClipTimeLineDurationフィールド95eの値よりも大きければ、再生を開始すべきピクチャはそのクリップ内に存在せず、小さければそのクリップ内に存在すると判断できる。後者のときは、さらにそのPTS差分値に基づいて、どの程度先の時刻かも容易に特定できる。
図13(b)は、KPUエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す。図13(b)の横軸の1目盛りは1データユニット長(Timed TS Packet Byte Length;TPBL)を示している。これは1データユニットがTTSパケットのデータ量(192バイト)と等しいことを意味する。
各KPUエントリは、各キーピクチャユニットKPUに対して1つ設けられている。KPUエントリの設定に関連して、各KPUのデータサイズがKPUSizeフィールド98dに記述され、各タイムエントリごとに対応するKPUの開始アドレスがKPUEntryStartAddressフィールド97bに記述される。なお、各キーピクチャユニットKPUのデータサイズは、例えば図13(b)のKPUsize#kに示すように、そのKPUの中で最初のピクチャのデータを格納した最初のTTSパケットから、次のKPUの最初のピクチャを格納したTTSパケット直前のTTSパケットまでのデータサイズを1データユニット長(TPBL)で示して表される。
さらにKPUエントリには、ファイルの最初から、キーピクチャユニットKPU#0の先頭までのフラグメント(データオフセット)がClipTimeLineAddressOffsetフィールド95dに設定されている。このフィールドを設ける理由は以下のとおりである。例えば1ショットのクリップAVストリームのデータが複数のファイルに分けて格納されたとき、2番目以降のファイルの先頭には先のファイル最後尾のKPUの一部が格納されることがある。キーピクチャユニットKPU内の各ピクチャは、KPU先頭のキーピクチャから復号化をしなければならないため、ファイルの先頭に存在するデータは単独で復号化できない。よってそのようなデータは、意味のないデータ(フラグメント)として読み飛ばすことが必要になる。そこで上述のオフセットフィールド95dにそのオフセット値を利用して、読み飛ばしを可能にしている。
ここで、図14を参照しながら、1ショットのクリップAVストリームデータが複数のファイルに分けて格納されたときのOverlappedKPUFlagフィールド98a等を説明する。説明の簡単のために、ここでは1ショットのコンテンツに関する管理情報とクリップAVストリームとが、2つのリムーバブルHDD#1および#2に格納されるとして説明し、またクリップメタデータには言及しない。
図14は、2つのリムーバブルHDDに分けて格納された、1ショットのコンテンツに関する管理情報とクリップAVストリームとを示す。リムーバブルHDD#1および#2には、それぞれクリップタイムラインのファイル(00001.CTLおよび00002.CTL)と、クリップAVストリームのファイル(00001.TTSおよび00002.TTS)とが格納されている。
以下では、KPUエントリに注目する。まず、リムーバブルHDD#1上のKPUエントリ#(d−1)は、00001.TTS内のクリップAVストリームに規定されるキーピクチャユニットKPU#(d−1)に対応して設けられている。図14に示すように、キーピクチャユニットKPU#(d−1)のすべてのデータは、00001.TTS内に存在している。その場合には、KPUエントリ#(d−1)のOverlappedKPUFlagフィールド98aには0bが設定される。
次に、KPUエントリ#dおよび対応するキーピクチャユニットKPU#dに着目する。図14に示すキーピクチャユニットKPU#dは、その一部(キーピクチャユニットKPU#d1)がリムーバブルHDD#1の00001.TTS内に存在し、他の一部(キーピクチャユニットKPU#d2)がリムーバブルHDD#2の00002.TTS内に存在している。キーピクチャユニットKPU#dが2つのリムーバブルHDDに分けて格納されている理由は、例えばリムーバブルHDD#1への書き込み中に、記録可能な残り容量が所定値以下になり、それ以上の書き込みが不可能になったためである。この場合には、KPUエントリ#dのOverlappedKPUFlagフィールド98aには1bが設定される。
なお、リムーバブルHDD#2内のKPUエントリ#0に対応するキーピクチャユニットKPUは、そのすべてのデータがリムーバブルHDD内に格納されているから、そのOverlappedKPUFlagフィールド98aには0bが設定される。
上述のようにKPUエントリ内のOverlappedKPUFlagフィールド98aの値を調べることにより、そのキーピクチャユニットKPUがそのメディア内のファイルに格納されているか否かが判断できる。この利点は、例えば以下の処理において非常に効果的である。
図14に示すように、KPU#dを構成するデータが複数のTTSファイル(00001.TTSおよび00002.TTS)に跨って格納されているときにおいて、リムーバブルHDD#2内のデータを全て削除する編集処理を想定する。この編集処理の結果、リムーバブルHDD#1に格納されたデータのみに基づいて1ショットの再生が行われる。
編集処理によって1ショットの再生時間が変化するため、正確な再生時間を算出する必要がある。そこで、OverlappedKPUFlagフィールド98aの値に基づいて再生時間の算出処理を変化させることができる。
以下に、再生が保証されているピクチャまでの再生時間を算出する処理(1)と、現実に再生可能なピクチャまでの再生時間を算出する処理(2)とを説明する。例えば、処理(1)は個人ユーザ向けの機器に実装され、処理(2)は業務ユーザ向けの機器に実装される。
まず、上述の処理(1)から説明する。編集処理が行われた後のリムーバブルHDD#1内の最後のKPU#dに関しては、OverlappedKPUFlagフィールド98aの値は“1b”である。このときは、先頭からKPU#(d−1)までのKPU期間(KPUperiod)の和を、リムーバブルHDD#1内のクリップの再生時間(ClipTimeLineDuration95e)の値として採用する。換言すれば、上述の数2においてキーピクチャユニットKPU#dのKPU期間(KPUperiod)の値はクリップの再生時間として算入しない。その理由は、実際に再生可能な時間(最初のKPUからKPU#(d−1)まで)と数2に基づいて算出した1ショットの再生時間(最初のKPUからKPU#dまで)との間には、最後のKPU#d相当の再生時間(0.4秒以上1秒未満)だけ誤差が発生し得るからである。この算出方法によれば、再生が保証されている映像の再生時間が把握できる。
次に、上述の処理(2)を説明する。処理(1)においては、データが存在するKPU#d1の再生時間は考慮されていない。しかし、KPU#d1内のデータに基づいて再生可能なピクチャが存在し得るため、処理(1)によって算出される再生時間は厳密には誤差が含まれうる。機器から提示された再生時間がこのような誤差を含むことは、特に業務用途や特殊用途の機器においてはあってはならないケースが想定される。そこで、OverlappedKPUFlagフィールド98aの値が“1b”の時には、フレーム/フィールド単位で連続して再生できるビデオ再生時間をKPU#d1を解析して求めればよい。その再生時間を処理(1)によって得られる再生時間に加算することによって、クリップの再生時間を非常に正確に求めることができる。
なお、リムーバブルHDD#1内の最後のKPUに対応するOverlappedKPUFlagフィールド98aの値が“0b”のときは、先頭から最後までの各キーピクチャユニットKPUのKPU期間(KPUperiod)の和をクリップの再生時間(ClipTimeLineDuration95e)の値として採用すればよい。最後のキーピクチャユニットKPU内の全てのピクチャが再生可能であるため、そのKPUのKPU期間(KPUperiod)をクリップの再生時間(ClipTimeLineDuration95e)に算入すべきだからである。
以上説明したように、OverlappedKPUFlagフィールド98aの値に応じてクリップの再生時間(ClipTimeLineDuration95e)の算出する処理を変化させることにより、常に正確な再生時間長を算出できる。
また、OverlappedKPUFlagフィールド98aの値を利用して不完全なキーピクチャユニットKPUを削除するか否かを決定し、削除したときには残されたクリップについてクリップタイムラインを修正してもよい。この「不完全なキーピクチャユニット」とは、全てのピクチャのデータが存在しないキーピクチャユニットをいい、ここではKPU#d2が存在しないKPU#dに相当する。
具体的に説明すると、OverlappedKPUFlagフィールド98aの値が“1b”のときには、不完全なキーピクチャユニットKPU#d1をキーピクチャユニットKPUとして取り扱わないように、TTSファイルから削除し、リムーバブルHDD#1内のクリップタイムラインを修正すればよい。クリップタイムラインの修正は、キーピクチャユニットKPUの数(KPUEntryNumber95b)を減少させること、KPU#dのKPUエントリを削除すること、キーピクチャユニットKPU#d1内のタイムエントリ(TimeEntry)95gを削除すること等を含む。修正後は、リムーバブルHDD#1の00001.TTSファイルの最後のキーピクチャユニットはKPU#(d−1)になり、最初のKPUから最後のKPU#(d−1)までの再生時間の和が1ショットの再生時間になる。よって、上述の数1〜数3を画一的に適用して正確な再生時間を得ることができる。尚、このような後方部分削除はFAT32ファイルシステム上においても、TTSパケット(192バイト)単位で可能である。
なお、キーピクチャユニットKPU#d2は、リムーバブルHDD#2内ではフラグメントであり、そのデータのみではビデオは復号化できない。よって、リムーバブルHDD#2内のクリップAVストリームファイル(00002.TTS)の最初から、キーピクチャユニットKPU#0の先頭までのフラグメント(データオフセット)がClipTimeLineAddressOffsetフィールド95dに設定される。さらに、そのキーピクチャユニットKPU#0の先頭から、最初に設定されたタイムエントリ#0までの時間オフセットがClipTimeLineTimeOffsetフィールド95cに設定される。なお、ClipTimeLineAddressOffsetフィールド95dの値が0でないときは、前のリムーバブルHDDからのキーピクチャユニットKPUが格納されていることを表すため、巻き戻し再生時にはまず、クリップメタデータ94のリレーション情報を参照することで、直前のクリップがあるか否かを特定することができる。直前のクリップが存在しないまたは、アクセスできない場合には、巻き戻し再生は終了する。ショットの途中のクリップであって、前のクリップがアクセス可能であった場合には、ClipTimeLineAddressOffsetフィールド95dの値が0か否かを確認し、0でないときに前のリムーバブルHDDの最後のキーピクチャユニットKPUに対応するKPUエントリのOverlappedKPUFlagフィールド98aの値をさらに確認して、キーピクチャユニットKPUの跨ぎが発生しているか否かを確実に判定することもできる。
次に、上述のデータ構造に基づいてコンテンツを録画し、そのデータ構造を利用してコンテンツを再生するための処理を説明し、その後、そのようなコンテンツを編集する際の処理を説明する。
まず図15および図16を参照しながら、コンテンツをリムーバブルHDDに録画するときのカムコーダ100の処理(録画処理)を説明する。
図15は、カムコーダ100によるコンテンツの録画処理の手順を示す。まずステップS151において、カムコーダ100のCPU211は指示受信部215を介して、ユーザから撮影開始の指示を受け取る。そして、ステップS152において、CPU211からの指示に基づいて、エンコーダ203は入力信号に基づいてTSを生成する。なおデジタル放送の録画時には、ステップS151において録画開始の指示を受け取り、ステップS152においてデジタルチューナ201cを用いて録画対象の番組のTSパケットを抽出すると読み替えればよい。
ステップS153では、メディア制御部205は、TS処理部204においてTTSヘッダが付加されたTS(クリップAVストリーム)を、順次リムーバブルHDDに書き込む。そしてメディア制御部205は、ステップS154において、クリップ(TTSファイル)を新規に作成するか否かを判断する。新規に作成するか否かは、記録中のクリップのTTSファイルのサイズが所定値よりも大きいか否かや、リムーバブルHDDの残容量に応じて任意に決定できる。新規にクリップを作成しない場合はステップS155に進み、新規にクリップを生成するときはステップS156に進む。
ステップS155では、TS処理部204は、キーピクチャユニットKPUが生成されるごとに、KPUエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットKPUのすべてのデータはそのクリップのTTSファイル内に書き込まれるため、メディア制御部205はKPUエントリ中のOverlappedKPUFlagフィールドに“0b”を設定する。そしてメディア制御部205は、ステップS157においてKPUエントリおよびタイムエントリを含む時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)をリムーバブルメディアに書き込む。その後、ステップS158において、CPU211は撮影終了か否かを判断する。撮影は、例えば指示受信部215を介して撮影終了指示を受信したとき、次にデータを書き込むべきリムーバブルHDDが存在しないとき等に終了する。撮影終了と判断されると録画処理は終了する。撮影が継続されるときには処理はステップS152に戻り、それ以降の処理が繰り返される。
一方ステップS156では、TS処理部204は、最後に書き込まれたデータによってキーピクチャユニットKPUが完結したか否かを判断する。仮にキーピクチャユニットKPUが完結しなければ、そのキーピクチャユニットKPUの残りのデータは他のリムーバブルHDDに格納されることになる。そのため、キーピクチャユニットKPUのすべてのデータがそのリムーバブルHDD内に書き込まれたか否かを判断するために、このような判断が必要になる。キーピクチャユニットKPUが完結しているときには処理はステップS155に進み、完結していないときには処理はステップS159に進む。
ステップS159では、TS処理部204によってクリップ切り替え処理が行われる。この処理の具体的な内容を、図16に示す。
図16は、クリップ切り替え処理の手順を示す。この処理は、コンテンツ(クリップ)の録画先のメディアを、あるリムーバブルHDDから他のリムーバブルHDDに切り替えたり、同一リムーバブルHDD上で新規クリップを生成する処理である。以下では説明を簡略化するために、クリップの切り替えが、コンテンツの録画先メディアの変更であるとして説明するが、同一記録媒体で新規クリップに記録する場合と本質的に同等である。また、便宜的にそれまでコンテンツが録画されていたリムーバブルHDDを「第1リムーバブルHDD」と呼び、次にコンテンツが録画されるリムーバブルHDDを「第2リムーバブルHDD」と呼ぶ。
まずステップS161において、CPU211は、第2リムーバブルHDD上に生成されるクリップのクリップ名を決定する。次に、ステップS162において、カムコーダ100は第1リムーバブルHDDに完全に記録できなかったキーピクチャユニットKPUが完結するまでTSを生成する。そして、TS処理部204はTTSヘッダを付加し、メディア制御部205はそのクリップAVストリームを第2リムーバブルHDDに書き込む。
次にステップS163において、メディア制御部205は、完結したKPUのKPUエントリおよびタイムエントリを生成する。このとき、キーピクチャユニットKPUは第1リムーバブルHDDおよび第2リムーバブルHDDに跨って書き込まれるため、メディア制御部205はKPUエントリ中のOverlappedKPUFlagフィールドに“1b”を設定する。
ステップS164において、メディア制御部205は、生成したKPUエントリおよびタイムエントリを含む時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)を、第1リムーバブルHDDに書き込む。そして、ステップS165において、第1リムーバブルHDD上のクリップ・メタデータ(リレーション情報等)を更新する。例えば、メディア制御部205は、第1リムーバブルHDD上のクリップのクリップメタデータに、次のクリップとして第2リムーバブルHDD上のクリップを特定するUMID等を書き込む。また、第2リムーバブルHDD上のクリップのクリップメタデータに、前のクリップとして第1リムーバブルHDD上のクリップを特定するUMID等を書き込む。その後、ステップS166において、メディア制御部205は、今後のコンテンツの書き込み先を第2リムーバブルHDDに設定し、処理が終了する。
次に、図17を参照しながら、カムコーダ100がリムーバブルHDDからコンテンツを再生する処理、より具体的には、指定された再生開始時刻に基づいて、その時刻に対応する位置からコンテンツを再生する処理を説明する。なお、コンテンツの最初から再生するときの処理は、KPUエントリ、タイムエントリ等を設けない従来の処理と同じであるため、その説明は省略する。
図17は、カムコーダ100によるコンテンツの再生処理の手順を示す。ステップS171において、カムコーダ100のCPU211は指示受信部215を介して、ユーザから再生開始時刻の指示を受け取る。
ステップS172において、メディア制御部205は時間・アドレス変換テーブル(クリップタイムラインClipTimeLine)を読み出して、CPU211が再生開始時刻のピクチャを含むキーピクチャユニット(KPU)を特定する。そして、ステップS173において、CPU211は、再生開始時刻に対応するKPUの開始位置を特定する。このKPUの開始位置は、TTSファイル内の復号開始位置(アドレス)を表している。
これらの処理の一例は以下のとおりである。すなわち、CPU211は、再生開始時刻がタイムエントリ#tとタイムエントリ#(t+1)の間の時刻であることを特定し、さらにタイムエントリ#tから起算してmアクセスユニット時間(AUTM)を1単位として何単位離れているかを特定する。
具体的には、まずタイムエントリ#tのKPUEntryReferenceIDフィールド97aの値に基づいて、あるKPU(KPU#kとする)が特定される。そして、タイムエントリ#tが指し示す時刻からKPU#kの先頭キーピクチャの再生が開始されるまでの時間差がTimeEntryTimeOffsetフィールド97cの値に基づいて取得される。その結果、再生開始すべきピクチャがKPU#kの中で最初に表示されるピクチャから何AUTM後か判明する。すると、KPU#kからKPUごとにKPU期間(KPUPeriod)を加算していくことで、再生開始すべきピクチャを含むKPUが特定できる。また、タイムエントリ#tが指し示すKPUの先頭アドレスにKPU#kから再生開始すべきピクチャを含むKPUの直前のKPUまでのKPUSizeを加算していくことで、再生開始時刻に対応するKPUの開始位置を特定できる。なお、「タイムエントリ#tが指し示すKPUの先頭アドレス」は、ClipTimeLineAddressOffsetフィールド95dの値とタイムエントリ#tのKPUEntryStartAddressフィールド97bの値との和を計算することによって取得できる。
なお、上述の説明は、説明の簡略化のためClosedGOP構造(GOP内の全てのピクチャはGOP内のピクチャを参照するのみ)を前提としている。しかしながら、ClosedGOP構造が取れない場合や、保証できない場合には、特定された再生開始時刻を含むKPUの一つ前のKPUから復号を開始してもよい。
次のステップS174では、メディア制御部205はそのキーピクチャユニット(KPU)のKPUEntry中のフラグを読み出し、ステップS175においてOverlappedKPUFlagフィールド98aの値が“1b”か否かを判断する。値が“1b”のときは、キーピクチャユニットKPUが第1および第2リムーバブルHDDにまたがることを意味しており、処理はステップS176に進む。一方値が“0b”のときは、跨らないことを意味しており、処理はステップS177に進む。
ステップS176において、メディア制御部205は第1リムーバブルHDDに格納されたKPUの先頭ピクチャデータからデータを読み出し、TS処理部204がTTSヘッダを除去すると、デコーダ206はそのデータからデコードを開始する。このとき、特定したピクチャによっては、読み出しを開始した第1リムーバブルHDDではなく第2リムーバブルHDDにデータが格納されていることもあるが、復号を正しく行うために2つのクリップ(TTSファイル)を跨ぐKPUの先頭キーピクチャからデコードが行われる。
ステップS177では、メディア制御部205はKPUの先頭ピクチャデータからデータを読み出し、TS処理部204がTTSヘッダを除去すると、デコーダ206はそのデータからデコードを開始する。読み出されるすべてのピクチャデータは、そのリムーバブルHDD内に格納されている。
その後、ステップS178では、再生開始時刻に対応するピクチャのデコード終了後に、グラフィック制御部207はそのピクチャから出力を開始する。対応する音声が存在するときには、スピーカ209bもまたその出力を開始する。その後は、コンテンツの最後まで、または再生の終了指示があるまでコンテンツが再生され、その後処理は終了する。
次に、図18および図19を参照しながら、リムーバブルHDDに録画されたコンテンツを編集する処理を説明する。この処理は、カムコーダ100においても実行されるとして説明するが、他には、コンテンツが録画されたリムーバブルHDDが装填されたPC108(図1)等において実行されてもよい。
図18(a)および(b)は、編集によってTTSファイルの先頭部分を削除する前後の管理情報およびクリップAVストリームの関係を示す。図18(a)に示される範囲Dが、削除の対象となる部分である。この範囲Dは、TTSファイルの先頭部分を含む。先頭部分のアドレスをp1とし、p1+D=p4とする。これまで説明したように、クリップAVストリームは複数のファイルに分けて格納されることがあるが、以下の処理は、各TTSファイルの先頭部分を含む削除に対して適用される。
図18(b)は、範囲Dを削除した後の管理情報(クリップタイムライン)およびクリップAVストリームの関係を示す。本実施形態では、範囲Dのすべてを常に削除するのではなく、範囲Dに収まるデータ量のうち、96キロバイトのn倍(n:整数)のデータ量だけを削除する。いま、削除後の先頭データ位置をアドレスp2とすると、(p2−p1)は、(96キロバイト)・nである。また、p2≦p4である。
上述の範囲Dの終端アドレスp4は、ユーザの編集位置を示している。換言すれば、この終端アドレスp4はユーザにとっては後続のストリームの開始点を示している。アドレスp4の値は、(p1+D)の値として表される。さらに、例えばそのアドレスに対応するピクチャの再生開始時刻情報(例えばPTS)を利用して表すこともできる。例えばユーザがアドレスp4を始点とし、後続のアドレスを終点とする編集を行うときには、上述のアドレスp4に対応するピクチャの再生開始時刻情報とともに、p4からのビデオ再生時間長や、開始時刻情報と同様のビデオの再生終了時刻情報によって、終点を特定することができる。ユーザの編集区間を示す情報(開始点・終了点)は、図9のClip Metadata(94)、または、Clip Time Line(95)において管理される。
アドレスp4の値またはそのアドレスに対応する時刻情報を保持することにより、ユーザが指定した範囲Dの後から再生、編集等を開始することができる。特に本実施形態の処理によれば、ユーザが削除を指定した範囲Dのうち、p2からp4までのデータが再生可能な状態で残されることがある。ユーザにとってはp2からp4のデータは削除されており、再生されると違和感を覚える。そこでアドレスp4の値等を保持しておくことにより、p2からp4までの区間の映像が再生されたり、その間を編集開始位置として誤って認識することを確実に防止することができる。アドレスp4の値またはそのアドレスに対応する時刻情報は、図10に示すクリップメタデータ94の記述データ(descriptive)中の再生情報として格納される。
「96キロバイト」は、本実施形態において採用するクラスタサイズ(32キロバイト)と、TTSパケットのパケットサイズ(192バイト)との最小公倍数である。このように処理する理由は、クラスタサイズの整数倍とすることによってリムーバブルHDDに対するデータ削除処理がアクセス単位で実行でき、またTTSパケットのパケットサイズの整数倍とすることによってデータ削除処理がクリップAVストリームのTTSパケット単位で実行できるため、処理を高速化かつ簡易にできるからである。なお、本実施形態ではクラスタサイズを32キロバイトとしているため、96キロバイトを基準として削除単位を決定したが、この値はクラスタサイズや、採用するクリップAVストリームのパケットサイズに応じて変化し得る。
削除処理では、さらにClipTimeLineTimeOffsetフィールド95cおよびClipTimeLineAddressOffsetフィールド95dの値も変更される。これらの値は削除前は0である。削除後は、まずClipTimeLineAddressOffsetフィールド95dに、初めて現れるキーピクチャユニットKPUまでのデータ量が記述される。初めて現れるキーピクチャユニットKPUの格納アドレスをp3とすると、ClipTimeLineAddressOffsetフィールド95dは(p3−p2)の値が記述される。また、ClipTimeLineTimeOffsetフィールド95cに、最初のキーピクチャユニットKPUの中で先頭のキーピクチャの再生時刻から最初のタイムエントリまでの時間差がAUTM単位で記述される。なお、アドレスp2からp3までのクリップAVストリームのパケットは、単独でデコードできるという保証がないため、フラグメントとして扱われ、再生の対象とはされない。
図19は、カムコーダ100によるコンテンツの部分削除処理の手順を示す。まずステップS191において、カムコーダ100のCPU211は指示受信部215を介して、ユーザからTTSファイルの部分削除指示、および、削除範囲Dの指定を受け取る。部分削除指示とは、TTSファイルの先頭部分および/または末尾部分を削除する指示である。指示の内容に応じて、先頭部分を削除する「前方部分削除処理」および/または末尾部分を削除する「後方部分削除処理」が行われる。
ステップS192において、前方部分削除処理か否かが判定される。前方部分削除処理を行う場合にはステップS193に進み、前方部分削除でない場合にはステップS195に進む。ステップS193では、メディア制御部205は、削除範囲に相当するデータ量Dのうち、96キロバイトの整数倍のデータ量を先頭から削除する。そしてステップS194において、メディア制御部205は、時間・アドレス変換テーブル(クリップタイムライン)中の、最初のタイムエントリに対する時間オフセットの値(ClipTimeLineTimeOffsetフィールド95cの値)と最初のKPUエントリに対するアドレスオフセット値(ClipTimeLineAddressOffsetフィールド95dの値)とを修正する。その後、処理はステップS195に進む。
ステップS195では、後方部分削除処理か否かが判定される。後方部分削除処理を行う場合にはステップS196に進み、行わない場合にはステップS197に進む。ステップS196では、削除範囲に相当するデータ量のうち、TTSファイルの最後が完全なKPUとなるよう192バイト単位でデータが削除される。これはすなわち、192バイトの整数倍のデータ量のデータが削除されることを意味する。その後処理はステップS197に進む。
ステップS197では、部分削除処理によって変化したタイムエントリ数やKPUエントリ数等を修正する。具体的には、時間・アドレス変換テーブル(ClipTimeLine)中で、実データを伴わなくなったKPUEntryエントリ、およびKPUEntryReferenceIDで参照していたKPUEntryエントリを失ったTimeEntryエントリが削除される。また、TimeEntryNumberフィールド95aの値、KPUEntryNumberフィールド95bの値等の修正処理が行われる。
なお、前方部分削除処理および後方部分削除処理のいずれもが行われない場合にもステップS197を経由する。これは、例えばTTSファイルの中間部分の削除処理が行われた場合にも修正処理が行われることを想定している。ただし、中間部分の削除処理は本明細書においては特に言及しない。
なお、上述のように部分削除処理はTTSファイルの先頭部分に限られず、TTSファイルの末尾部分を含む範囲の削除処理をしてもよい。この処理は、例えば上述の不完全なキーピクチャユニットKPU(図14のKPU#d1)を削除する際に適用される。不完全なキーピクチャユニットKPUは1クリップの最後に存在しているため、「TTSファイルの最後の部分を含む範囲」に相当する。このとき削除される範囲は、不完全なキーピクチャユニットKPUの先頭からTTSファイルの最後までであり、例えばTTSパケットのパケットサイズ(192バイト)単位で削除する範囲を決定すればよい。クラスタサイズは特に考慮しなくてもよい。なお、TTSファイルの最後の部分は不完全なキーピクチャユニットKPUに限られず、ユーザから範囲の指定を受けること等により、任意に決定できる。なお、先頭部分の削除処理と末尾部分の削除処理とを連続して行ってもよいし、一方の処理のみを行ってもよい。
以上、本発明の実施形態を説明した。
本実施形態では、データストリーム等を格納するメディアはリムーバブルHDDであるとした。しかし、上述したファイルシステムによりファイルを管理するメディアであれば、非可換メディア、例えばデータ処理装置に内蔵されたHDDであってもよい。
タイムマップ(ClipTimeLine)のデータ構造は、TimeEntryおよびKPUEntryの2層を含むとした。しかし、再生時間と記録アドレスの変換が可能であればこれに限る必要は一切なく、KPUEntryの1層のみからなるタイムマップであっても全く同様である。上述の説明では、OverlappedKPUFlagフィールドを設け、その値に基づいてキーピクチャユニットKPUが複数のファイルを跨っていることを示すとして説明した。しかし、複数のファイルを跨っているか否かは、タイムマップに相当するデータが存在しない場合であっても表すことができる。例えば、クリップメタデータ(リレーション情報など)、クリップのファイル名の命名規則(ファイル名の番号が昇順など)、同一フォルダ内に1ショットの全データ(少なくとも1ショットを構成する全TTSファイルの内、同一記録媒体上に記録されたもの)を格納する等によって、KPUが跨っている、または、跨っている可能性があることを示してもよい。
なお、図2等の各機能ブロックは典型的には集積回路(Large Scale Integrated Circuit;LSI)のチップとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。例えば、図2においては、CPU211を含むシステム制御部250とメディア制御部205とは別個の機能ブロックとして示されている。これらはそれぞれ別個の半導体チップとして実装されてもよいし、システム制御部250にメディア制御部205の機能を与え、物理的に同一のチップによって実現してもよい。また、メディア制御部205およびTS処理部204の機能を集積化して、1つのチップ回路として実現してもよいし、さらにエンコーダ203およびデコーダ206の機能を付加したチップ回路217として実現してもよい。ただし、例えば符号化または復号化の対象となるデータを格納するメモリのみを集積化の対象から除外することにより、複数の符号化方式に容易に対応できる。
システム制御部250は、プログラムROM210等に格納されたコンピュータプログラムを実行することにより、本明細書に記載したメディア制御部205の機能を実現することができる。このときは、メディア制御部205はシステム制御部250の一部の機能として実現される。
なお、上述の「LSI」は、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオテクノロジーを利用したいわゆるバイオ素子として集積化を行ってもよい。
本発明によれば、コンテンツの録画のために、複数ファイルに跨ってコンテンツのデータストリームが格納されることを想定したデータ構造を得ることができる。このデータ構造によれば、機器はどのファイル内のデータであっても容易にアクセスし、再生を開始することができる。またこのデータ構造を利用してさらにファイルの編集を行うことにより、機器は処理の高速化および処理負荷の軽減を実現できる。
リムーバブルメディアを介して連携する複数種類のデータ処理装置を示す図である。
カムコーダ100の機能ブロックの示す図である。
トランスポートストリーム(TS)20のデータ構造を示す図である。
(a)はビデオTSパケット30のデータ構造を示し、(b)はオーディオTSパケット31のデータ構造を示す図である。
(a)〜(d)は、ビデオTSパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。
クリップAVストリーム60のデータ構造を示す図である。
TS処理部204の機能ブロックの構成を示す図である。
(a)は本実施形態における1コンテンツの概念を示す図であり、(b)はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、(c)は3つのリムーバブルHDD112を示す図である。
リムーバブルHDD112内の階層化されたディレクトリ構造を示す図である。
クリップメタデータ94に含まれる情報の内容を示す図である。
キーピクチャおよびキーピクチャユニットの関係を示す図である。
(a)はクリップタイムライン(ClipTimeLine)95のデータ構造を示す図であり、(b)は1タイムエントリに関するTimeEntryフィールド95gのデータ構造を示す図であり、(c)は1KPUエントリに関するKPUEntryフィールド95hのデータ構造を示す図である。
(a)はタイムエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す図であり、(b)はKPUエントリと、クリップタイムライン95に含まれるフィールドとの関係を示す図である。
2つのリムーバブルHDDに分けて格納された、1ショットのコンテンツに関する管理情報とクリップAVストリームとを示す図である。
カムコーダ100によるコンテンツの録画処理の手順を示す図である。
メディア切り替え処理の手順を示す図である。
カムコーダ100によるコンテンツの再生処理の手順を示す図である。
(a)および(b)は、編集によってTTSファイルの先頭部分を削除する前後の管理情報およびクリップAVストリームの関係を示す図である。
カムコーダ100によるコンテンツの部分削除処理の手順を示す図である。
符号の説明
100 カムコーダ
108 PC
112 リムーバブルHDD
201a CCD
201b マイク
202 ADコンバータ
203 MPEG−2エンコーダ
204 TS処理部
205 メディア制御部
206 MPEG−2デコーダ
207 グラフィック制御部
208 メモリ
209a LCD
209b スピーカ
210 プログラムROM
211 CPU
212 RAM
213 CPUバス
214 ネットワーク制御部
215 指示受信部
216 インターフェース(I/F)部
250 システム制御部
261 TTSヘッダ付加部
262 クロックカウンタ
263 PLL回路
264 バッファ
265 TTSヘッダ除去部