オーサリング方法、プログラム、編集データ再生装置
【課題】オーサリング工程の効率化、時短化。
【解決手段】クリップやUDFイメージ等として、大容量の素材データを加工したファイルを生成せず、仮想的にマルチプレクサを行う。即ち素材データのコピー処理を不要とした仮想クリップ、仮想UDFイメージを生成するようにし、従来コピー処理のために長時間を要していた作業時間を短縮する。また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
【解決手段】クリップやUDFイメージ等として、大容量の素材データを加工したファイルを生成せず、仮想的にマルチプレクサを行う。即ち素材データのコピー処理を不要とした仮想クリップ、仮想UDFイメージを生成するようにし、従来コピー処理のために長時間を要していた作業時間を短縮する。また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えばブルーレイディスク(Blu-ray Disc(登録商標):以下「BD」)における再生専用ディスク(BD-ROM)等の製造において、記録するコンテンツを作成するオーサリングシステムにおけるオーサリング方法、プログラムに関する。さらに編集データ再生装置に関する。
【先行技術文献】
【特許文献】
【0002】
【特許文献1】特開平7−78102号公報
【背景技術】
【0003】
図25により、BD−ROM等の再生専用光ディスクの製造までの流れを説明する。
まず素材製作として、映像素材の撮影、音声素材の録音、編集等が行われる(S1)。
この撮影・編集等で得られたデータは、制作するコンテンツの素材データ(映像素材、音声素材、字幕データ等)として格納される(S2)。
【0004】
各種素材データは、オーサリングスタジオに持ち込まれ、ディスクデータ(コンテンツ)制作に供される。
オーサリングスタジオでは、オーサリング処理のためのプログラムをインストールしたパーソナルコンピュータや所要のハードウエアを用いて、各種素材データを利用したコンテンツ制作を行う。
映像素材、音声素材はビデオエンコード、オーディオエンコードの各処理により、それぞれ所定の形式に符号化される。また字幕データ等から、メニューデータ、字幕データ等が作成される(S3)。次にコンテンツの構成としてのシナリオやメニュー作成が行われる(S4)。また各種データ編集が行われる(S5)。
【0005】
その後、マルチプレクサ処理(S6)として、コンテンツを構成するストリームデータを形成する。マルチプレクサ処理は、符号化された映像データや音声データ、メニュ−などを多重化するためのものである。この場合、例えばハードディスク内等に格納された画像、音声、字幕などの符号化された素材データをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。後述するが、ここではクリップ作成、UDFイメージ作成等が行われる。
最終的に作成された多重化データは、ディスク製造用のカッティングマスタとして、例えばパーソナルコンピュータ内のハードディスク等に格納される。
そのカッティングマスタは、ディスク製造のために工場に送られることになる(S7)。
【0006】
工場では、プリマスタリング(S8)として、データの暗号化やディスク記録データとしてのエンコード等の各種データ処理を行い、マスタリングデータを作成する。そしてマスタリング(S9)として、ディスク原盤のカッティングからスタンパ作成までの工程を行う。最後にリプリケーション(S10)として、スタンパを用いたディスク基板の制作や、ディスク基板上への所定の層構造形成を行い、完成品として光ディスク(BD−ROM)を得る。
【0007】
オーサリングスタジオで行われている従来のオーサリング工程(S3〜S6)を図26に示す。これは特にマルチプレクサ処理(S6)を詳しく示したものである。
ステップF1として、上述のように素材データ処理としてのエンコード(S3)がおこなわれ、またステップF2として、オーサリングアプリケーションによるデータ作成が行われる。これは上記S4,S5のメニュー作成や編集等となる。
そしてマルチプレクサ処理(S6)として、ステップF3〜F10が行われる。
【0008】
ステップF3としてクリップ作成が行われる。クリップとは、素材データを時分割多重したストリームデータである。図27にBD−ROMにおけるUDF(Unversal Disk Format)イメージのディレクトリ構成例を示すが、ここで「STREAM」ディレクトリにおけるm2tsファイルが、ここでいうクリップとなる。
【0009】
ステップF4としてクリップの再生確認が行われる。即ちクリップ段階で映像/音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
クリップの再生確認がOKとなったら、次にステップF5としてUDFイメージの作成が行われる。UDFイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものである。
UDFイメージを作成したら、ステップF6でエラーチェックが行われる。この場合PC上でベリファイヤによる論理チェックなどが行われる。
エラーチェックOKであれば、ステップF7でUDFイメージの再生確認が行われる。この場合UDFイメージについて、ハードウエアプレーヤで再生を行い、UDFイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【0010】
UDFイメージの再生確認がOKであれば、ステップF8でBD−R(書込可能型ブルーレイディスク)に対して、UDFイメージによるコンテンツ書込を行う。実際に生産するBD−ROMに近い光ディスク状態でのチェックを行うためである。そしてステップF9でBD−Rの再生を行い、内容を確認する。
その段階でOKであれば、ステップF10で、工場に転送するマスターデータとしてのカッティングマスタを作成することになる。
【0011】
以上の処理において、ステップF4,F6,F7,F9の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら、その修正を要する状況に応じて、ステップF1の素材データ段階、またはステップF2のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
【発明の概要】
【発明が解決しようとする課題】
【0012】
上記のオーサリング、特にマルチプレクサ処理においては、作業の効率化、高速化が求められている。
図28にクリップ作成、UDFイメージ作成の作業を模式的に示している。
ここで、Lドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにES(Elementary Stream)ファイル群が格納されているとする。ESファイルとは、素材データのファイルである。Cドライブは、パーソナルコンピュータ内部のワーク領域とする。
【0013】
上述のように、クリップ作成の際には、符号化された素材データ(ESファイルのデータ)の多重化処理が行われる。
クリップ100は、例えばMPEG2方式のストリームデータとされるが、管理情報としての4バイトのTPエクストラヘッダ(TP extra header)102や4バイトのパケットインフォメーション(Packet information)103とともに、184バイトのアダプテーションフィールド/データフィールド(adaptation field / data field)101が含まれる。データフィールドには、ESファイルの素材データがPES(Packetized Elementary Stream)パケットで転送され、コピーされる。
これらのコピーされる素材データは、かなり大容量となることが多く、マルチプレクサの処理時間は、データコピーに多く費やされて膨大なものとなる。
またUDFイメージ200は、クリップ100にメタデータ201等を付加したものとして生成されるが、大容量のクリップ100がコピーされるため、UDFイメージ200の生成の際も膨大な時間を要する。
【0014】
さらに、上記のようにクリップ100やUDFイメージ200の再生確認が行われて、再生結果に不具合などがあれば、再度マルチプレクサの工程前まで戻ることも多々ある。すると、上記の素材データのコピーを何度もやり直す状況が発生することになる。
このコピー処理時間は、データ量に比例するが、1つの工程に数時間を要することもあった。
【0015】
一方、作業の高速化の手法としては、処理の分散化なども考慮された。例えばコンテンツの部分毎に並行してマルチプレクサ処理を行うなどである。しかしその場合、データの分割、あるいは接続などが必要となり、分割点や接続点に、これまでの処理との互換性が取れない場合が想定された。
このようなことからオーサリング作業の長時間化が問題となっており、作業の効率化が求められている。
【0016】
なお、上記した特許文献1には、シミュレーションのターンアラウンドを短縮する技術が開示されているが、ディスク等に記録する実データの作成に関しての効率化は解決されていない。
【課題を解決するための手段】
【0017】
本発明のオーサリング方法は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程とを有する。
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する。
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する。
本発明のプログラムは、このようなオーサリング方法を情報処理装置において実行させるプログラムである。
また、上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材IDを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材IDについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする。
本発明の編集データ再生装置は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段とを有する。
【0018】
このような本発明では、クリップやUDFイメージ等として、大容量の素材データを加工したファイルを生成せず、仮想的にマルチプレクサを行うものである。即ち素材データのコピー処理を不要とし、従来コピー処理のために長時間を要していた作業時間を著しく短縮する。
また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
【発明の効果】
【0019】
本発明により、マルチプレクサの処理が従来に比して著しく時短化できる。例えば実際の使用においては、同等のクリップファイルやUDFイメージファイルを生成する場合において、従来比で約7倍高速とすることができた。このようなマルチプレクス処理の高速化により、オーサリング作業は格段に効率化される。
【図面の簡単な説明】
【0020】
【図1】本発明の実施の形態の仮想クリップ及び仮想UDFイメージの説明図である。
【図2】実施の形態のオーサリング工程のフローチャートである。
【図3】実施の形態のマルチプレクサモジュールの説明図である。
【図4】実施の形態で用いる素材データのディレクトリ構成例の説明図である。
【図5】実施の形態のクリップ生成時のディレクトリ構成例の説明図である。
【図6】実施の形態のES参照テーブルを構成するファイルの説明図である。
【図7】実施の形態のシークリストの説明図である。
【図8】UDFファイルシステムの説明図である。
【図9】従来のUDFイメージ生成時のディレクトリ構成例の説明図である。
【図10】実施の形態のUDFイメージ生成時のディレクトリ構成例の説明図である。
【図11】実施の形態の仮想クリップ参照テーブルを構成するファイルの説明図である。
【図12】実施の形態のエクステントマップ例の説明図である。
【図13】従来のUDFイメージ生成の説明図である。
【図14】実施の形態のUDFイメージ生成の説明図である。
【図15】実施の形態の仮想イメージを実体イメージにデコードした例の説明図である。
【図16】実施の形態のCPTBLファイルの説明図である。
【図17】実施の形態のカッティングマスタファイルの説明図である。
【図18】実施の形態の再生システムの説明図である。
【図19】実施の形態の仮想イメージ再生処理のフローチャートである。
【図20】実施の形態の仮想クリップ再生処理のフローチャートである。
【図21】実施の形態の他の再生システムの説明図である。
【図22】実施の形態のさらに他の再生システムの説明図である。
【図23】実施の形態のBD−R記録の説明図である。
【図24】実施の形態のBD−R書込処理のフローチャートである。
【図25】ディスク製造の流れの説明図である。
【図26】従来のオーサリング工程の説明図である。
【図27】BD−ROMのディレクトリ構成例の説明図である。
【図28】従来のクリップ・UDFイメージ作成の説明図である。
【発明を実施するための形態】
【0021】
以下、本発明の実施の形態を次の順序で説明する。
[1.システム動作概要]
[2.オーサリング工程]
[3.仮想クリップ]
[4.仮想UDFイメージ]
[5.カッティングマスタファイル]
[6.仮想クリップ・仮想UDFイメージの再生]
[7.編集データ再生装置]
[8.BD−R書込]
[9.実施の形態の効果及び変形例]
【0022】
[1.システム動作概要]
実施の形態において、ディスク製造の全体の流れは、図25で説明したものと同様である。本実施の形態では、特にクリップの仮想化、UDFイメージの仮想化を行うことで、マルチプレクサ処理(図25のS6)の効率化を実現する。
【0023】
図1にマルチプレクサ処理の際に生成する仮想クリップ、仮想UDFイメージを模式的に示す。
Lドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにES(Elementary Stream)ファイル群が格納されている。
マルチプレクサ処理の際には、まず仮想クリップ10の作成を行う。
従来は図28で述べたように、クリップ100が、実際の素材データがコピーされて生成されるが、本例の場合、素材データを含まない仮想クリップ10が生成される。
【0024】
仮想クリップ10は、管理情報としての4バイトのTPエクストラヘッダ(TP extra header)12や4バイトのパケットインフォメーション(Packet information)13とともに、ES参照テーブル11を有するファイル構造として形成される。
本来クリップは、MPEG2方式のストリームデータとしてPESパケット単位の実データの集合であるが、ここでは、各PESパケットは、そのTPエクストラヘッダ12とパケットインフォメーション13のみで表現されているということができる。
そしてTPエクストラヘッダ12に対応する実素材データのポインタ情報が、ES参照テーブル11に格納されている。
つまり、仮想クリップ生成処理では、ESファイルの実データコピーは行われない。
また仮想クリップ10の再生には、ES参照テーブル11を用いて実際の素材データを特定し、ESファイル群の中からリードしてくることによって行う。
【0025】
仮想UDFイメージ20は、管理情報としてのメタデータ22と、仮想クリップ参照テーブル21を有する。
この仮想UDFイメージ20も、素材データとしての実データはコピーされない。仮想クリップ参照テーブル21によって、仮想的に実データが表現される。
仮想UDFイメージ20の再生は、仮想クリップ参照テーブル21から、仮想クリップ10のES参照テーブル11を参照し、そのES参照テーブル11から実際のESファイルを指定して、読み出すことにより実現する。
【0026】
このように本例では、大容量の素材データを加工したファイルを生成せず、エンコードした素材データ(ESファイル)を直接リードしながら仮想的にマルチプレクサを行い、ハードディスク(Lドライブ)などの媒体のI/O部分を極力減らした仮想処理を実行する。
【0027】
[2.オーサリング工程]
図25のS3〜S6として示したオーサリングスタジオで行われる工程として、実施の形態のオーサリング工程を図2に示す。
図2のステップF101として、素材データ処理としてのエンコードがおこなわれ、映像、音声等の素材データが符号化される。符号化された素材データは、ESファイルとして図1のLドライブに格納された状態となる。
【0028】
ステップF102として、オーサリングアプリケーションによるデータ作成が行われる。これは図25のS4,S5のメニュー作成や編集等となる。
そしてマルチプレクサ処理(図25のS6)として、ステップF103〜F110が行われる。
【0029】
マルチプレクサ処理は、オーサリング作業に用いるパーソナルコンピュータにおいて起動されるマルチプレクサモジュールとしてのプログラムに基づいて行われる。
なお、従来のマルチプレクサモジュールは、オーサリングスタジオに配布され実際のディスクタイトル製作のために運用されてきている。そのため、たとえ処理速度が高速化したとしても、互換性がないものや、置き換えによって信頼性が落ちるものは、許容されるものでない。そのため、本例で導入する新たなマルチプレクサモジュールは、従来のマルチプレクサモジュールをコールしていたものと同じオーサリングアプリケーションや再生装置、ベリファイヤ(Verifier)が利用できるシステム設計を行うことが適切である。
【0030】
本例におけるマルチプレクサモジュールは、図3(a)に示すように、大きくわけて仮想クリップ生成部1,メタデータ生成部2,仮想UDFイメージ/カッティングマスタ生成部3の3つのパートから構成される。
仮想クリップ生成部1は、MPEG2トランスポートストリームフォーマットのクリップファイル生成を仮想的に行う。
メタデータ生成部2は、ディスクに記録するメタデータ生成を行う。
仮想UDFイメージ/カッティングマスタ生成部3は、仮想的にUDFイメージを作成し、またカッティングマスタを作成する。これらは、DLL(ダイナミックリンクライブラリ)として、オーサリングスタジオで使用される、一般にオーサリングアプリケーションと呼ばれるソフトウェアから動的にリンクして実行される。
従来のマルチプレクサモジュールからの置き換えは、このDLLの入れ替えのみなので、使用中のシステムへの本実施の形態の導入は容易である。
【0031】
なお、本例のマルチプレクサモジュールとしてのプログラムは、パーソナルコンピュータ等の機器に内蔵されている記録媒体としてのHDD、ROM、フラッシュメモリ等に予め記録しておくことができる。
あるいはまた、フレキシブルディスク、CD−ROM(Compact Disc Read Only Memory)、MO(Magnet optical)ディスク、DVD、ブルーレイディスク、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納(記録)しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、プログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、LAN(Local Area Network)、インターネットなどのネットワークを介してダウンロードすることもできる。
【0032】
図2のステップF103では、仮想クリップ生成部1により仮想クリップ10の作成が行われる。本来クリップとは、素材データを時分割多重したストリームデータである。例えば図3(b)に示すように、エレメンタリストリームとしての素材データ(映像、音声、IG(Interactive Graphics)、PG(Presentation Graphics)、テキストサブタイトル)等をマルチプレクスしてトランスポートストリーム(TS)としたものである。
本例の場合、実際の素材データはコピーせずに、図1に示したように、TPエクストラヘッダ12、パケットインフォメーション13、ES参照テーブル11を有するファイル構造として仮想クリップ10を生成する。
【0033】
ステップF104として仮想クリップ10を用いた再生確認が行われる。即ちクリップ段階で映像/音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
【0034】
仮想クリップ10によるクリップ内容の再生確認がOKとなったら、次にステップF105として、仮想UDFイメージ/カッティングマスタ生成部3により、仮想UDFイメージ20の作成が行われる。本来のUDFイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものであるが、これを仮想的に生成する。
メタデータはメタデータ生成部2が作成する。そして仮想UDFイメージ/カッティングマスタ生成部3の処理により、仮想UDFイメージ20が作成される。
仮想UDFイメージ20は、図1に示すようにメタデータ22と、仮想クリップ参照テーブル21を含むものとされる。
なお、カッティングマスタファイル(CMF)の一部データの作成も同時に行われる。例えばコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが作成される。
【0035】
仮想UDFイメージ20を作成したら、ステップF106でエラーチェックが行われる。この場合PC上でベリファイヤによる論理チェックなどが行われる。
エラーチェックOKであれば、ステップF107で仮想UDFイメージ20の再生確認が行われる。即ち仮想UDFイメージ20における仮想クリップ参照テーブル21、及びES参照テーブル11に基づいて再生を行い、UDFイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【0036】
仮想UDFイメージ20の再生確認がOKであれば、ステップF108でBD−R(書込可能型ブルーレイディスク)に対して、仮想UDFイメージ20によるコンテンツ書込を行う。実際に生産するBD−ROMに近い光ディスク状態でのチェックを行うためである。この場合、仮想クリップ参照テーブル21、及びES参照テーブル11に基づいて書込データとしてのストリームが形成され、BD−Rへの書込が行われることになる。
そしてステップF109でBD−Rの再生を行い、内容を確認する。
【0037】
その段階でOKであれば、ステップF110で、仮想UDFイメージ/カッティングマスタ生成部3により、工場に転送するマスターデータとしてのカッティングマスタが作成される。即ち仮想UDFイメージから実体化されたUDFイメージを作成し、さらに上記のコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどを付加して、カッティングマスタファイルが作成される。
【0038】
以上の処理においては、ステップF104,F106,F107,F109の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら内容修正を行う。即ちその修正を要する状況に応じて、ステップF101の素材データ段階、またはステップF102のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
以下では、この図2の処理で作成される仮想クリップ10、仮想UDFイメージ20の内容、さらにはこれらの再生動作、BD−Rへの書込について説明する。
【0039】
[3.仮想クリップ]
先に述べたように従来は、クリップとして素材データの実体をコピーしたクリップを生成していたところ、本例では素材データの実体を含まない仮想クリップ10を生成するものである。従来のクリップファイルと比較しながら、本例の仮想クリップ10について説明する。
【0040】
まず図4は、図1のLドライブにESファイルとして格納される素材データについてのディレクトリ構成を示している。
図のように、「ESData」ディレクトリ下に「VIDEO」「AUDIO」ディレクトリが配置される。そして「VIDEO」下に「MPEG2」「AVC」ディレクトリが配置され、「MPEG2」下の「MOVIE1」「MOVIE2」等のディレクトリ下にESファイルとしての「sample1.ves」等が配置される。また「AVC」下にもESファイルとしての「sample2.ves」等が配置される。
従来では、「sample1.ves」「sample2.ves」等のESファイルがクリップ作成時にコピーされていたものである。
【0041】
図5(a)に、従来のクリップのディレクトリ構造を示してる。図のように例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のクリップファイルが配される。この「00001.m2ts」等のクリップファイルが、素材データがマルチプレクスされてコピーされたストリームデータであり、これらはデータサイズが大きなものとなっていた。
【0042】
本例の場合、従来最も容量を必要としていたクリップファイル(m2tsファイル)を仮想化する。
図5(b)が仮想化した場合のディレクトリ構造の例である。例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のディレクトリを配置する。
即ち従来のファイルが図5(a)のように単一ファイル「00001.m2ts」等であったところ、本例の仮想ファイルシステムでは「00001.m2ts」等をディレクトリとして配置する。そして「00001.m2ts」等のディレクトリ下に、「Packetbase」「Packetinfo」「Seek.lst」「ES.List」としての各ファイルを配置する。
この4つのファイル「Packetbase」「Packetinfo」「Seek.lst」「ES.List」が、図1に示したES参照テーブル11を構成するものとなる。
【0043】
各ファイルを説明する。
・Packetbase (パケットベース)
パケットベースは、TSパケット(TSPacket)のヘッダー/システムパケットの集まりである。
図6(b)にパケットベースを示すが、その説明のため、先に図6(a)で仮想化されたクリップを実体のあるクリップにデコードした状態を説明する。
クリップの実体は、192バイトのTSパケット(図6(a)の一行)から構成される。
ここでは1行目、2行目のTSパケットには、TP_extra_header(4バイト)、PacketInformation(4バイト)、 adaptation_field(184バイト)が含まれるものとし、3行目以降のTSパケットには、TP_extra_header(4バイト)、PacketInformation(4バイト)、 data_field(184バイト)が含まれるものとしている。データフィールド(data_field)とは、実際にESファイルの一部(素材データの一部)がコピーされているものである。
これは図28で模式的に示した従来のクリップの構造に相当する。
【0044】
本例の仮想クリップ10を構成するパケットベースは、図6(b)のようになり、図6(a)におけるdata_fieldが無い構成となる。つまりパケットベースは、素材データの実体がない状態でクリップ実体の管理情報を集めたものと言える。
具体的には、図6(b)の1行目、2行目のTSパケットには、TPエクストラヘッダ(TP_extra_header:4バイト)、パケットインフォメーション(PacketInformation:4バイト)、アダプテーションフィールド(adaptation_field:184バイト)が含まれる。
図6(b)の3行目以降は、それぞれTPエクストラヘッダ(TP_extra_header:4バイト)、パケットインフォメーション(PacketInformation:4バイト)の8バイトの構造となる。パケットインフォメーションには、実際のESファイルの一部である実体データのパケットを示すPIDが含まれている。
パケットベースを構成するそれぞれのTSパケットのサイズは 次のPacketinfoファイルに示されることになる。
【0045】
・Packetinfo(パケットインフォファイル)
図6(c)にパケットインフォファイル(Packetinfo)を示す。パケットインフォファイルは、先頭から1バイトずつがパケットベースファイル中のTSパケットのサイズを示すものとされる。
実データとしてのTSパケットは、図6(a)のように192バイトであるが、図6(b)のようにパケットベースにはデータフィールドが存在しないTSパケットもある。TSパケットの最小サイズは、図6(b)の3行目のようにTPエクストラヘッダとパケットインフォメーションの8バイトである。
このためパケットインフォファイルの各バイトは、8〜192バイトの範囲で、パケットベースファイル中の各TSパケットのサイズを示す。
【0046】
・ES.list(ESリストファイル)
ESリストは、TSパケットのパケットベース以外のデータ部分の参照元のファイル名とPIDの関係を示すテキストファイルが記述される。
フォーマットは、
PID,ファイルパス[改行]
PID,ファイルパス[改行]
・
・
とされる。
【0047】
例えば図6(d)に例を示す。
「PID3,L:\ESData\VIDEO\MOVIE\MPEG-2\sample1.ves」
とは、「PID3」というPIDに対応するデータとしての「sample1.ves」について、図4のディレクトリ構造での「sample1.ves」ファイルに至るディレクトリパスが記述されていることになる。
同様に「PID5,L:\ESData\VIDEO\AVC\sample2.ves」は、「PID5」というPIDに対応するデータとしての「sample2.ves」について、図4のディレクトリ構造での「sample2.ves」ファイルに至るパスが記述されている。
【0048】
つまり、パケットベース内の或るTSパケットにおけるパケットインフォメーションに示されているPIDに対応して、例えば図6(a)(e)の関係のように、本来データフィールドにコピーされるべきESファイルが示される。つまり仮想クリップ再生時に読み出されるべき、ESファイルが示されることになる。
【0049】
・Seek.lst(シークリストファイル)
シークリストファイルは、シーク用の情報を示すファイルである。
上記の他の3つのファイルでもデコードは可能であるが、シーク情報を追加することによって高速シークに対応できる。
実際に、仮想クリップ10の映像などを再生するときには、このシーク情報がないと再生が間に合わない場合も生ずる。
【0050】
シークリストファイルには、PIDごとの対応のフォーマットで例えば、100SPN(Source Packet Number)として19200バイトごとのポジション情報が記述されている。
例えば図7に示すように、先頭に「version」として、この構成(フォーマット)のバージョン番号(例えば「0x00000001」)が示される。次に、「SPN interval」としてインターバル値が示される。ここで「0x0064」=100であり、100SPN間隔であることが示されている。また「PID Count」としてPID(素材に割り振られる個体番号)の個数が示される。以降は、100SPN毎のリストが続く。
【0051】
リスト内では、TSパケットのヘッダファイル(パケットベース)のポジションが示される。例えば図では「0A18」としているが、これによってパケットベースの位置が示される。
また、PIDに対応するESファイルのポジションが示される。例えば図のように「00A5」として、PID=1011とされた素材ファイル内の位置が示される。
【0052】
シークの例を説明する。
仮に19200byteからデータを読み出したい場合、シークリストファイルの2つめのリストを読み込む。そしてパケットベースの位置「0A18」に基づいてパケットベースファイルを参照する。
またPIDに対応するESファイルのポジションを読み込む。そして例えば「00A5」として、素材ファイル内の位置を確認し、素材ファイル(ESファイル)を読み出す。
【0053】
以上の各ファイルで構成される仮想クリップ10に基づくデータの読み込みは次の(P1)〜(P6)のように行われる。
(P1)パケットインフォファイルを1バイト読む。(「A」とする)
(P2)パケットベースファイルから (A)バイト数読み込む。(「B」とする)
(P3) ((B)[5]&1F)<<8 + (B)[6] (TSパケット中のPIDの位置) (「C」とする)
(P4)ESリストファイルのPIDと(C)が一致するファイルから、1パケットサイズは192バイト固定であることから、 (192-(A))バイト読み込む 。(「D」とする)
(P5) (B)のバイト列 と (D)のバイト列 を結合したものをファイルとして出力する。
(P6)上記(P1)に戻る。これをパケットインフォファイルの終了まで繰り返す。
よって、復元されたファイルのサイズは、
ファイルのサイズ=(パケットベースファイルサイズ)×192
となる。
【0054】
以上のように仮想クリップ10は、TPエクストラヘッダ12、パケットインフォメーション13とともに、ES参照テーブル(「Packetbase」「Packetinfo」「Seek.lst」「ES.List」)11を有するファイル構造として形成される。
この場合、MPEG2方式のストリームデータとしてPESパケット単位の実データの集合であるクリップが、仮想的に表現されるものとなる。そして、仮想クリップ生成時には大容量のESファイルデータのコピーは行われないため、作成時間は非常に短縮される。また仮想クリップ10の再生には、ES参照テーブル11を用いて実際のESファイルデータを特定し、ESファイル群の中からリードしてくることによって行うことができる。
【0055】
[4.仮想UDFイメージ]
次に仮想UDFイメージ20について説明する。
図3(a)に示したマルチプレクサモジュールでは、仮想クリップ生成部1が生成した上述した仮想クリップ10や、メタデータ生成部2が生成したメタデータ22に基づいて、仮想UDFイメージ/カッティングマスタ生成部3がUDF2.5イメージを生成する。図2のステップF105の処理である。
一例としてUDF1.02ブリッジファイルシステムを図8に示す。UDFは、管理情報(メタデータ)とファイル実体に分けて考える。
【0056】
まず比較のため、従来のUDFイメージ生成時のディレクトリ構造例を図9に示す。
図9において実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」までの構造は上記図5(a)と同様である。即ちクリップファイル部分を示している。
UDFイメージ生成によって、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルが配置される。なお「ImageFile0」「ImageFile1」は、UDFイメージ変換されたストリームデータである。また「CPTBL0」「CPTBL1」はコピープロテクションテーブルとしてのファイルである。また「UCD0」「UCD1」はユーザコントロールデータとしてのファイルである。
【0057】
図10はクリップからUDFイメージへの変換を模式的に示したものである。例えば記録層が2層のブルーレイディスクのオーサリング工程における例として、第1層用のファイル、第2層用のファイルとしてのUDFイメージ生成時を示している。第1層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」を生成する。また第2層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」を生成する。
これらのファイルが、図9のように「SAMPLEIMAGE」ディレクトリ下に配置される。
【0058】
ここで図9の構造において、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルは、実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」の各ファイルの実データを用いてUDF変換するものであり、サイズが大きい。
このため、実体としてUDFイメージ生成を行っていた従来は、その処理時間が長時間化していた。
【0059】
これに対し、本例の仮想UDFイメージ20のディレクトリ構造を図11に示す。
図11において「00001.m2ts」「00002.m2ts」「00003.m2ts」等は、上述したように実体ファイルではなく仮想クリップ10を構成するディレクトリである。これらのディレクトリ下に上述した、ES参照テーブル11を構成するパケットベースファイル、パケットインフォファイル、シークリストファイル、ESリストファイルが配されるが、これらのデータサイズは小さい。実際の素材データがコピーされているわけではないためである。
【0060】
UDFイメージ変換により、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」が、それぞれ実体ファイルではなくディレクトリとして配置される。
「ImageFile0」「ImageFile1」ディレクトリ下には、「Extent.map」「SourceFileList.map」「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルが配置される。
特に「Extent.map」「SourceFileList.map」が、図1の仮想クリップ参照テーブル21を構成するものとなる。
また「CPTBL0」「CPTBL1」ディレクトリ下には、「Extent.map」「Header.map」の各ファイルが配置され、また「UCD0」「UCD1」ディレクトリ下には「Extent.map」ファイルが配置される。
【0061】
図12にクリップからUDFイメージへの変換を模式的に示すが、例えば記録層が2層のブルーレイディスクのオーサリング工程における例として、第1層(レイヤ0)用のファイル、第2層(レイヤ1)用のファイルとしてのUDFイメージ生成を行う場合である。第1層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」ディレクトリを生成し、また第2層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」ディレクトリを生成する。そして、各ディレクトリ下に上記「Extent.map」等のファイルを配置して図11の「SAMPLEIMAGE」ディレクトリ下に配置する。このUDFイメージ変換においては、素材データとしての実データのコピーは伴わない。
【0062】
ここで図11において「ImageFile0」「ImageFile1」ディレクトリ下の「Extent.map」「SourceFileList.map」等のファイルは、素材データによるストリームデータがコピーされているものではないためデータサイズは小さいものとなる。「CPTBL0」「CPTBL1」「UCD0」「UCD1」の各ディレクトリ下のファイルも同様にデータサイズは小さい。
つまり、大容量データのコピーを伴わずにUDFイメージ生成が行われる。
【0063】
形成されるファイルについて説明する。
・Extent.map(エクステントマップファイル)
「ImageFile0」「ImageFile1」等のディレクトリ下に配置されるエクステントマップファイルには、UDF上に配置されるファイルそれぞれの論理アドレスであるエクステント情報が記録されている。
エクステント情報では、例えば「m2ts」ファイルが物理的にインターリーブして配置される場合などの、それぞれのブロックの論理アドレスとバイトサイズが記録されている。
【0064】
エクステントマップファイルは例えば図13(a)のように構成される。即ちエクステントマップファイルのID、バージョンナンバ、トータルブロック、レイヤオフセットLSN(Logical Sector Number)が記述される。トータルブロックは、イメージ内のセクタ数である。2層ディスク(デュアルレイヤディスク)でレイヤが別ファイルになる場合はレイヤ毎のセクタ数となる。レイヤオフセットLSNは、第2記録層(レイヤ1)の論理セクタナンバである。
そしてエクステント情報として、エクステントナンバー毎に、開始LSN、エクステントサイズ、登録元ファイル、登録元ファイル内オフセットが記述される。
【0065】
例えば仮想化されているUDFイメージを実体のあるイメージにデコードした状態を図14に示すが、イメージ化では図示のように1つのファイルを複数のブロックに分割して配置することができる。図では例えば00001.m2tsファイルを「00001.m2ts(1)」「00001.m2ts(2)」「00001.m2ts(3)」に分割している。
このような例の場合、エクステントマップファイルには、次のように各参照ファイルのエクステント(アドレス)情報が入る。
00001.m2ts:A0, A1, A2
00002.m2ts:B0
00003.m2ts:C0
【0066】
・SourceFileList.map(ソースファイルリストマップ)
ソースファイルリストマップは、ファイルそれぞれの実体のPC上の絶対ファイルパスが記録されている。
ソースファイルリストマップの例を図13(a)に示す。
ソースファイルリストマップには、図のようにファイルバージョン、リスト数が記述され、「File0」「File1」「File2」・・・として各ファイルの絶対ファイルパス、サイズ、作成日時、更新日時が記述される。
【0067】
例えば図14の例においていえば、各ファイルの情報として、次のように記述される。
00001.m2ts:C:\SAMPLE\BDMV\STREAM\00001.m2ts
00002.m2ts:C:\SAMPLE\BDMV\STREAM\00002.m2ts
00003.m2ts:C:\SAMPLE\BDMV\STREAM\00003.m2ts
【0068】
「ImageFile0」「ImageFile1」等のディレクトリ下に配置される「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルは、UDFの管理情報用ファイルである。これらのファイルは、図14の例ではxxxxx.m2ts以外の仮想化されていない情報が入る。
図15にUDFイメージファイルを示すが、「UDFHeader.map」ファイルは、UDFイメージ内のボリュームシーケンス(Anchorを含む)のデータである。
「UDFFooter.map」ファイルは、UDFイメージ内のリザーブボリュームシーケンス(Anchorを含む)のデータである。
「UDFMetadata.map」ファイルは、UDFイメージ内のメタデータのファイルである。
「UDFMetadataMirror.map」は、UDFイメージ内のメタデータミラーのファイルである。
【0069】
仮想UDFイメージ20の再生時においては、エクステントマップファイルによって各ファイルが指定され、ソースファイルリストマップによって、各ファイルのパスが判別される。各ファイルのパスは、仮想クリップ10としてのディレクトリ(「00001.m2ts」「00002.m2ts」「00003.m2ts」等)を示すものとなる。
上述したように、これらの仮想クリップ10としてのディレクトリには、ES参照テーブル11を構成するファイルが配置されている。
このため、上述した(P1)〜(P6)の手順で仮想クリップ10に基づく素材データの読み込みが行われる。
即ち、仮想UDFイメージ20の再生では、仮想クリップ参照テーブル(「Extent.map」「SourceFileList.map」)21から、ES参照テーブル(「Packetbase」「Packetinfo」「Seek.lst」「ES.List」)11を参照し、ES参照テーブル11に基づいて実体としてのESファイルを読み出すことになる。
【0070】
なお、「UCD0」「UCD1」ディレクトリ下の「Extent.map」ファイルは図16(a)のようになる。
ここには、UCDマップID、バージョンナンバ、UCDファイルサイズ、レイヤオフセットLSN、UCDアイテムサイズが記述される。
そしてUCDのエクステント情報として、エクステントナンバー毎に、開始LSN、ブロック数、データが記述される。
【0071】
また「CPTBL0」「CPTBL1」ディレクトリ下の「Extent.map」ファイルは図16(b)のようになる。
ここには、CPTマップID、バージョンナンバ、CPTBLファイルサイズ、ヘッダーサイズ、レイヤオフセットLSNが記述される。
そしてCPTのエクステント情報として、エクステントナンバー毎に、開始LSN、ブロック数、クリップナンバ等が記述される。
「CPTBL0」「CPTBL1」ディレクトリ下の「Header」ファイルは図17のように、ジェネラルブロックデータ、ロケーションブロックデータを含む。
【0072】
以上のように仮想UDFイメージ20は、仮想クリップ参照テーブル(「Extent.map」「SourceFileList.map」)21によって、仮想的に実データが表現されるものとなる。仮想UDFイメージ作成時にはESファイルの実データはコピーされない。従って仮想UDFイメージ20の作成時間は著しく短縮される。
また仮想UDFイメージ20の再生は、仮想クリップ参照テーブル21から、仮想クリップ10のES参照テーブル11を参照し、そのES参照テーブル11から実際のESファイルを指定して、読み出すことにより実現できる。
【0073】
[5.カッティングマスタファイル]
本例のマルチプレクサモジュールでは、仮想UDFイメージ/カッティングマスタ生成部3は、UDFイメージのほかに、ディスクプラントでディスク生成に必要なカッティングマスタファイルも生成する。
カッティングマスタの例としては、次のようなファイルがある。
・UDFイメージファイル
・コントロールデータファイル
・暗号化テーブルファイル
・物理情報ファイル
【0074】
UDFイメージファイルは上述のように高速化処理が行われる。コントロールデータファイル、暗号化テーブルファイルも、圧縮した形でマルチプレクサから出力することによって高速化を行う。
例えば、コントロールデータファイルは、イメージファイルの1024分の18のサイズがあるが、全てゼロデータであるとき、ファイルサイズ4バイトまで圧縮を行うことができる。
これらのカッティングマスタファイルへの復号は、次の工程のディスクプラント転送(通称ダウンローダ)によって行われる。
ダウンローダは、ディスクプラントへの出荷時1回だけ実施されるため、この工程によるオーサリングスタジオでのワークフロー全体から見るとオーバーヘッドは少ない。
【0075】
[6.仮想クリップ・仮想UDFイメージの再生]
上述した仮想クリップ10、仮想UDFイメージ20の再生の具体例を説明する。
再生は、ファイルシステムを管理するソフトウェアをバックグラウンドで実行することで行う。仮想ファイルシステムには、以下の第1〜第3の再生システムのいずれかで実現できる。
【0076】
<第1の再生システム>
任意のディレクトリを指定すると、そのディレクトリ以下のファイルが任意のファイルシステムとして見えるようにしたシステムである。
【0077】
図18に構成を示す。なお図において太線で示すVFSインターフェース(Virtual File System Interface)30、アザーファイルシステム(Other File System)31は、OS(Operating System)のモジュールである。ここではWindows(登録商標)のOSとする。また破線で示すシステムサービス(System Service(Client))33,システムサービス(System Service(Server))34、フューズモジュール(Fuse Module)32、DLL(Dynamic Link Library)35はオープンソースである。ファイルシステムアプリケーション(File System Application)36が新規開発したモジュールとなる。
【0078】
ファイルシステムアプリケーション36は、仮想化されたクリップやイメージファイルが、あたかも実体のあるクリップやイメージファイルに見えるファイルシステムに変換するモジュールである。即ち素材データのファイルパスやオフセット、サイズなどを参照する。
なお通常のファイルシステムは、OSのカーネルの一部として実装されているが,FUSEというカーネルモジュールを利用するとファイルシステムをユーザランドで実装することができる。
DLL35では、ユーザスペースとカーネル部のフューズモジュール32との橋渡しが行われる。
フューズモジュール32では、任意のディレクトリはユーザー指定のファイルシステムとして参照される。フューズモジュール32はOSへはデバイスドライバとして登録する。
アザーファイルシステム31は、指定外のファイルへのリクエストに対応するファイルシステムであり、OSで決められたファイルシステム(例えばFAT32,NTFS)などでファイルを参照する。
【0079】
この構成においてカーネル部では、OSからのファイルのCREATE、READなどのサービスをユーザスペースのアプリケーションプログラムへ通知を行う。アプリケーションプログラムでは、仮想ファイルシステムを各サービスに対して処理し、カーネル部に完了通知を行う。
【0080】
UDFイメージの再生手順を図19に示す。
例えばソフトウエアプレーヤなどのアプリケーションからUDFイメージファイルのアクセスがリクエストされることで、ステップF201からの処理が行われる。
ステップF201ではリクエストされたイメージファイルが仮想UDFイメージ20として仮想化されているものであるか否かを判別する。
【0081】
リクエスト対象が仮想化されたUDFイメージの場合は、ステップF202で、ファイルシステムアプリケーション36が、リクエストされたUDFイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル21を参照する。そして仮想UDFイメージ20を実イメージに変換する。
例えばアプリケーションが、「ImageFile0」を実体ファイルとしてリクエストしたとする。本例の場合、図11で示したように同じ名前の「ImageFile0」ディレクトリが形成され、そのディレクトリ下にエクステントマップファイル、ソースファイルリストマップによる仮想クリップ参照テーブル21が形成されている。
ファイルシステムアプリケーション36は、仮想クリップ参照テーブル21、及びそこから参照されるES参照テーブル11を用いて、ローカル(例えばLドライブ)、あるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
なお仮想化されていない実体のUDFイメージがリクエスト対象であれば、そのまま当該UDFイメージファイルを再生すればよい(F201→NO)。
【0082】
ここで、UDFイメージ内でクリップファイル「xxxxx.m2ts」が含まれている場合、ステップF203からF204に進み、当該リクエストされたクリップが仮想化されたクリップであるか否かを判断する。
仮想化されたクリップである場合は、ファイルシステムアプリケーション36はステップF205で、アプリケーションなどでリクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を読み出す。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
なお、UDFイメージファイル内に実体があるクリップとして「xxxxx.m2ts」ファイルが含まれているときは、当該「xxxxx.m2ts」をそのままアプリケーションなどのリクエストに応じて再生できる(F204→NO)。
【0083】
クリップの再生手順は図20のようになる。
アプリケーションからクリップファイルのアクセスがリクエストされることで、ステップF250からの処理が行われる。
ステップF250ではリクエストされたクリップが仮想クリップ10として仮想化されているものであるか否かを判別する。
仮想化されていない実体クリップであれば、そのまま当該クリップファイルを再生すればよい(F250→NO)。
【0084】
リクエストが仮想化されたクリップであった場合は、ファイルシステムアプリケーション16はステップF251で、リクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を読み出す。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、実クリップに変換し、元のクリップファイルを再生する。
【0085】
<第2の再生システム>
第2の再生システムは、任意のディレクトリ以下のファイルが、ファイルシステムの規格であるUDF2.5あるいはUDF2.01を参照するシステムである。
【0086】
図21に構成を示す。この場合、太線で示すVFSインターフェース(Virtual File System Interface)30、アザーファイルシステム(Other File System)31は、OS(Operating System)のモジュールである。またシステムサービス(System Service(Client))33A,システムサービス(System Service(Server))34A、フューズモジュール(Fuse Module)32A、DLL(Dynamic Link Library)35A、ファイルシステムアプリケーション(File System Application)36が新規開発したモジュールとなる。
【0087】
ファイルシステムアプリケーション36は仮想化イメージファイルが実体のある光ディスク(BD)に見えるファイルシステムに変換する。
DLL35Aでは、ユーザスペースとカーネル部のフューズモジュール32との橋渡しが行われる。
フューズモジュール32Aでは、任意のUDF2.5(UDF2.01)のUDFイメージファイルは、ディレクトリに見えるようになる。OSへはデバイスドライバとして登録する。
アザーファイルシステム31は、指定外のファイルへのリクエストについて、OSで決められたファイルシステム(例FAT32,NTFS)などでファイルを参照する。
【0088】
BDはUDF2.5の規定があるため、マルチプレクサが出力するUDFイメージは、この構成においては、ディレクトリとしてOS上見えることになる。
なおWindowsXP(登録商標)のようにUDF2.5を標準サポートしていないOSにおいては、標準サポートしているUDF2.01へファイルシステムアプリケーション36で変換する。
【0089】
この場合、仮想UDFイメージの再生手順は上記図19と同様となる。
仮想クリップ10については、この構成では再生できない。UDFではないためである。
再生するときは、仮想化されたクリップを含んだディレクトリで仮想化UDFイメージ20、あるいは実体のあるUDFイメージを生成する必要がある。その再生手順は、図19のステップF203〜F205によるものとなる。
しかしながら、仮想化UDFイメージ20の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想UDFイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
【0090】
<第3の再生システム>
第3の再生システムを図22に示す。これはハードウェアエミュレータ(Hエミュレータ)による再生システムである。
ハードウェアエミュレータとは、ATA(SATA)接続したPCホスト、あるいはCEプレーヤーから、あたかもドライブが接続したかのように見えるシステムである。本例は、ハードウェアエミュレータのイメージファイルの再生部にフィルタリングを行うことによって、仮想ファイルを実際のイメージファイルとして見せかけるシステムである。
【0091】
図22(a)(b)に示すように、ホストPC50とHエミュレータ用PC51が、PCI基板52においてSATA等で接続される。
図22(a)の再生処理前の状態では、ホストPC50から、Hエミュレータ用PC51内のHDD53において仮想UDFイメージ構造が認識される。
再生時は、Hエミュレータ用PC51側で仮想クリップ参照テーブル21を用いて直接素材ファイルの読み出しを行う。ホストPC50からは、図22(b)のように、光ディスクのファイルシステムがあたかもHエミュレータ用PC51側にマウントされたかのように見える。つまり本来のUDFイメージファイルにデコードされて見える。
このシステムでは、SATAなどのインターフェースを持つ専用のPCI基板52などのハードウェアの追加が必要となるが、Hエミュレータを実現するアプリケーションへの少ない対応で再生システムを実現できる。
【0092】
UDFイメージファイルの再生手順は次のようになる。
仮想化されたUDFイメージファイルをホストPC50上のアプリケーションなど(例ソフトウェアプレーヤーなど)からリクエストされることで再生処理を行う。この場合、Hエミュレータ用PC51上で機能しているアプリケーションプログラムでリクエストされたUDFイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル21を参照する。そしてローカルあるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
【0093】
UDFイメージファイル内にクリップが含まれているときは次のようになる。例えば「xxxxx.m2ts」ファイルがアプリケーションなどでリクエストされたとき、Hエミュレータ用PC51上で走るアプリケーションプログラムで「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を参照する。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
【0094】
なお、この構成では、UDFではないので仮想化されたクリップは再生することはできない。仮想クリップ10を再生するときは、仮想化されたクリップを含んだディレクトリで仮想UDFイメージ20、あるいは実体のあるUDFイメージを生成する必要がある。
しかしながら、仮想化UDFイメージ20の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想UDFイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
【0095】
[7.編集データ再生装置]
ところで、さらに図22のHエミュレータ用PC51で実行するアプリケーションに、上述した本実施の形態のマルチプレクサ処理を行わせることも可能である。
即ち当該アプリケーションにおけるソフトウエア及びHエミュレータ用PC51におけるハードウエアを用いて、仮想クリップ生成手段と、仮想イメージ生成手段と、仮想イメージ再生手段を形成する。
仮想クリップ生成手段は、図2のステップF103の処理を行う。即ち仮想クリップ生成手段は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対するES参照テーブル11を有する仮想クリップ10を生成する。
仮想イメージ生成手段は、図2のステップF105の処理を行う。即ち仮想イメージ生成手段は、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、仮想クリップ10を参照する仮想クリップ参照テーブル21を有するイメージファイル構造としての仮想イメージ20を生成する。
仮想イメージ再生手段は、図2のステップF107の処理を行う。即ち仮想イメージ再生手段は、仮想イメージ20の再生を、仮想クリップ参照テーブル21を用い、ES参照テーブル11を介して素材データを読み出すことで実現する。
【0096】
通常Hエミュレータが再生できるUDFイメージファイルは、ディスクのイメージとして1つのファイルでなければならない。このためマルチプレクサ処理を行ったUDFイメージファイルを再生の対象として、Hエミュレータのアプリケーションに登録していた。ここで、UDFイメージ化する前の多数のフォルダおよびファイルから構成されるコンテンツをアプリケーションに登録し、上述した仮想的なファイル形成を行うマルチプレクサ処理を行って仮想化されたUDFイメージを作成する。すると、それを再生することができるようになる。
【0097】
このように、Hエミュレータのアプリケーションに本実施の形態のマルチプレクサ処理を行わせることにより、フォルダおよびファイルの状態から短時間でUDFイメージファイルに変換することができ、Hエミュレータで再生確認を行うことができるようになる。これにより、オーサリング処理で行っていた、映像データ、音声データ、メニューデータ、字幕データ、JAVAプログラム等の差し替え作業を、オーサリング処理を介さずにファイルを差し替えるだけで再生確認ができるようになり、オーサリングの効率化が実現できる。
つまり、本発明の編集データ再生装置としてのエミュレータを実現できる。
【0098】
[8.BD−R書込]
続いて図2のステップF108のBD−R書込について説明する。
図25,図3等で上述してきたように、オーサリングシステムにおけるマルチプレクサは、エンコーダにより符号化された映像データや音声データ、メニュなどを多重化するためのものである。そしてハードディスク内に格納された画像、音声、字幕などの符号化されたデータをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。
作成された多重化データは、最終的にはディスク製造用のカッティングマスタとしてハードディスク内に格納される。
【0099】
また、オーサリングスタジオでは、図2のステップF108として述べたように、カッティングマスタの一部であるUDFイメージデータを市販のBurnツールなどでBD−Rに記録する。そしてステップF109で、実際に工場でマスタリングするBD−ROMと同じような挙動を行うか、任意のプレーヤーで動作確認を行う。
このBD−Rに書込を行うプロセスに、従来はいくつかの課題があった。
【0100】
まず、UDFイメージデータのサイズは大きいもので、一旦ハードディスクに出力するだけでも、時間がかかってしまう。
これに対しては上述してきたように、大容量のデータを加工したファイルを生成せず、PC上のファイルを直接リードしながら、あるいはエンコードした素材を直接リードしながら仮想クリップ10、仮想UDFイメージ20を生成するプロセスを行うことで解決できる。
BD−Rに記録する際は、仮想UDFイメージ20に基づいて再生されるデータをデコードすることでデータ書込の際の前処理時間を短縮することができる。
【0101】
もう1つの課題として、BD−RとBD−ROMの配置が同じになる保証がないということがある。
例えば2層BD−Rの記録を行うときは、図23(a)に示すように、1層目を全て書き込んでから、2層目に折り返すことになっている。図23(a)において示すように、1層目(レイヤL0)の書込は、ディスク内周側から外周側に進行し、外周側において設定されているアンユースドスペースまで達した時点で、レイヤーブレイクLBを行って2層目(レイヤL1)に折り返す。
【0102】
一方、最終製品としてのBD−ROMに関しては、例えばコンテンツ内容などに応じて、レイヤーブレイクLBのポイントが設定される。BD−ROM製造段階で1層目に書き込むサイズを任意に指定できるためである。例えば図23(b)のようにA点がレイヤーブレイクLBのポイントとして設定される。これによって図の斜線部のようにデータ記録が行われた状態となる。
すると、通常にBD−R書込を行ってしまうと、図23(a)(b)から分かるように、同じ内容であっても、BD−RはBD−ROMとは異なる状態で各レイヤに記録が行われてしまう。
【0103】
図2のステップF108、F109のBD−R書込及び再生確認は、BD−Rを通常のプレーヤで再生することで、最終製品としてのBD−ROMの挙動を確認するために行うものである。
プレーヤーの再生確認は、データの配置によってシーク時間やレイヤー(層)ジャンプなどのアクセスタイムを考慮して評価を行わなければならないのだが、それができなくなる。たとえば、レイヤ間をまたぐシーク時間は、BDドライブの性能上、同じレイヤでのシーク時間よりも大きくなる。しかし、BD−RとBD−ROMでレイヤーブレイクLBのポイントが異なることとなると、このような点を考慮した再生確認ができないこととなる。
【0104】
そこで本例では、仮想UDFイメージに基づくBD−R書込において、BD−ROMと同じ配置でBD−R書込ができるようにする。例えば図23(c)のように書込を行う。
BD−R書込においては、レイヤ0からレイヤ1へのレイヤーブレイクLBのポイントは、アンユースドスペースに達した位置である。そこで、図23(c)のように、ダミデータDMを配置し、コンテンツファイル内容から見たレイヤブレイクポイントがBD−ROMの場合と同じ箇所となるようにする。
なお、最終製品となるBD−ROMについても、同様にダミーデータを配置し、図23(c)と同様の配置となるようにするものである。つまり、例えば図23(b)のようにBD−ROMのレイヤーブレイクLBのポイントがコンテンツ内容等から決められる場合、BD−Rでは、アンユースドスペースに達した位置とされるレイヤーブレイクLBのポイントが、そのBD−ROMの内容的な位置としてのレイヤーブレイクLBのポイントと一致するようにする。その上で、最終製品のBD−ROMは、図23(c)と同様にダミーデータを付加した配置を行う。結局、図23(c)のBD−Rは、BD−ROMと同一の配置とされ、再生確認を適切なものとできる。
【0105】
このようなBD−R書込を実現するために、本例では、例えばマルチプレクサモジュールが図24の処理を行う。
ステップF401でパラメータ入力処理を行う。ここでは、ダミーファイルの最大サイズ、アンユース度スペースの最大サイズ、ディスク片面(1つの記録層)の最大サイズ、クリップのインターリーブ用情報等の入力を受け付ける。
【0106】
ステップF402では、BD−R書込を行おうとする仮想UDFイメージ20についてのディレクトリパスを取得する。
ステップF403では、入力されたパラメータから、UDFイメージの配置を決定する。この場合、2層ディスクが対象の場合は、ユーザが指定した位置でレイヤブレイクが行われるようにする。またダミーファイルやアンユースドスペースのサイズと配置を決定する。
この際、クリップのインターリーブをBDのジャンプモデルを考慮して決定する。BD等の光ディスクでは、シークやレイヤージャンプなどの再生時のオーバーヘッドを考慮したクリップを、UDFイメージ上で配置する必要があるためである。
なおインターリーブは、マルチアングルなどのタイトルで主に使用される。BDやDVDでは、マルチアングル、マルチストリーを編集されることが多く、その場合インターリーブは必須の機能になる。マルチアングルとは、同一時間内に進行する映像を異なるカメラアングルからアングルを記録し、プレイヤーの操作によりユーザーが任意に選択できる機能である。マルチストーリーとはユーザーがメニューで選択したり製作者が分岐先等を指定することにより、見る人の選択によってストーリー展開を自由に選べる機能である。
【0107】
以上の処理で、図23(c)のような書込のためのUDFイメージの配置が決定される。そこでステップF404で、仮想UDFイメージ20の仮想クリップ参照テーブル21(エクステント情報)を元に、BD−R書込のためのストリーム再生を行い、BD−R書込プログラムに受け渡して、BD−Rに対する書込を実行する。
【0108】
即ち本例の場合、仮想UDFイメージ20を再生してBD−R書込ストリームを形成する際に、ダミーファイルサイズ等の入力パラメータを反映された書き込み用ストリームが形成されるようにする。これにより、入力パラメータに応じて図23のように書込が行われ、結果として、BD−ROMと同じ位置(コンテンツ内容から見ての同じ位置)でレイヤーブレイクが行われるようにできるなど、確認用として適切なBD−R記録を行うことができる。
従来は、記録用のイメージファイルを生成してから、そのイメージファイルをBD−Rに書き込むか、或いはディレクトリ指定して、その指定されたディレクトリのファイルを書き込むことが行われていた。BD−R記録用のイメージファイルを生成することは、工程の効率を悪化させる。またディレクトリ指定で行う場合は、BD−R上での物理的な位置を規定できない。
これに対して本例では、仮想UDFイメージ20の再生において、ダミーファイルサイズ、アンユースドスペースのサイズ、1層最大サイズ、インターリーブ用情報等が反映されるようにする。このため、上記のように物理的な位置を任意に設定でき、かつ予めBD−R書込用のイメージファイルを別に作成するという必要もなくなる。
【0109】
[9.実施の形態の効果及び変形例]
以上説明してきたように、本実施の形態では、オーサリング工程におけるマルチプレクサ処理が、仮想クリップ10、仮想UDFイメージ20による処理とすることで著しく時短化できる。例えば、従来と同等のサイズのストリームファイルやUDFイメージファイルを生成する場合で比較して、約7倍の高速化(工程時間が1/7への時間短縮)を実現できた。これによって、効率のよいオーサリング工程を実現できる。
【0110】
なお実施の形態の変形例として以下のようなものが想定される。
仮想クリップ10、仮想UDFイメージ20等の仮想データを専用のソフトウェアで再生することもできる。即ちオーサリング工程とは独立して再生を行う再生モジュールを形成してもよい。市販の再生用ソフトウェアなどは利用できないが、例えば仮想ファイルシステムによるデータの再構成に所要するオーバーヘッドを考慮した場合に想定される。
【0111】
またマルチプレクサでは、アプリケーションフォーマットに準拠したプレゼンテーションデータに変換加工するが、メニュー画面のナビゲーション等はSTD(System Target Decoder)のバッファ管理を考慮しないで、オーサリング時に再生確認を行いたいことが多い。この再生システムをシミュレータと一般に呼ぶ。このシミュレータも、マルチプレクサと同様に素材を直接読み出すことで再生することが可能である。この場合、素材の置き換えを行うと、短時間で再生確認を行うことができる。
【0112】
またMPEG2トランスポートフォームのほかに、MPEG2プログラムストリームなど同様のマルチプレクサシステムにおいて、仮想ファイルシステムによる高速化を行うことができる。
また素材の参照テーブルファイル(ES参照テーブル)のフォーマットは各種変形可能である。再生可能であればサイズが小さい方がマルチプレクサの再生時間は高速になる。
【0113】
また、オーサリング工程を並列に行う並列処理を組み合わせることによって、さらなる高速化が可能となる。
また従来マルチプレクサ処理、つまり実データとしてのクリップファイル等を作成するシステムと併用できるシステムとしても実現可能である。即ちユーザ指示により、仮想化処理をするか否かを選択可能とするものである。
【符号の説明】
【0114】
1 仮想クリップ生成部、2 メタデータ生成部、3 仮想UDFイメージ/カッティングマスタ生成部、10 仮想クリップ、11 ES参照テーブル、20 仮想UDFイメージ、21 仮想クリップ参照テーブル
【技術分野】
【0001】
本発明は、例えばブルーレイディスク(Blu-ray Disc(登録商標):以下「BD」)における再生専用ディスク(BD-ROM)等の製造において、記録するコンテンツを作成するオーサリングシステムにおけるオーサリング方法、プログラムに関する。さらに編集データ再生装置に関する。
【先行技術文献】
【特許文献】
【0002】
【特許文献1】特開平7−78102号公報
【背景技術】
【0003】
図25により、BD−ROM等の再生専用光ディスクの製造までの流れを説明する。
まず素材製作として、映像素材の撮影、音声素材の録音、編集等が行われる(S1)。
この撮影・編集等で得られたデータは、制作するコンテンツの素材データ(映像素材、音声素材、字幕データ等)として格納される(S2)。
【0004】
各種素材データは、オーサリングスタジオに持ち込まれ、ディスクデータ(コンテンツ)制作に供される。
オーサリングスタジオでは、オーサリング処理のためのプログラムをインストールしたパーソナルコンピュータや所要のハードウエアを用いて、各種素材データを利用したコンテンツ制作を行う。
映像素材、音声素材はビデオエンコード、オーディオエンコードの各処理により、それぞれ所定の形式に符号化される。また字幕データ等から、メニューデータ、字幕データ等が作成される(S3)。次にコンテンツの構成としてのシナリオやメニュー作成が行われる(S4)。また各種データ編集が行われる(S5)。
【0005】
その後、マルチプレクサ処理(S6)として、コンテンツを構成するストリームデータを形成する。マルチプレクサ処理は、符号化された映像データや音声データ、メニュ−などを多重化するためのものである。この場合、例えばハードディスク内等に格納された画像、音声、字幕などの符号化された素材データをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。後述するが、ここではクリップ作成、UDFイメージ作成等が行われる。
最終的に作成された多重化データは、ディスク製造用のカッティングマスタとして、例えばパーソナルコンピュータ内のハードディスク等に格納される。
そのカッティングマスタは、ディスク製造のために工場に送られることになる(S7)。
【0006】
工場では、プリマスタリング(S8)として、データの暗号化やディスク記録データとしてのエンコード等の各種データ処理を行い、マスタリングデータを作成する。そしてマスタリング(S9)として、ディスク原盤のカッティングからスタンパ作成までの工程を行う。最後にリプリケーション(S10)として、スタンパを用いたディスク基板の制作や、ディスク基板上への所定の層構造形成を行い、完成品として光ディスク(BD−ROM)を得る。
【0007】
オーサリングスタジオで行われている従来のオーサリング工程(S3〜S6)を図26に示す。これは特にマルチプレクサ処理(S6)を詳しく示したものである。
ステップF1として、上述のように素材データ処理としてのエンコード(S3)がおこなわれ、またステップF2として、オーサリングアプリケーションによるデータ作成が行われる。これは上記S4,S5のメニュー作成や編集等となる。
そしてマルチプレクサ処理(S6)として、ステップF3〜F10が行われる。
【0008】
ステップF3としてクリップ作成が行われる。クリップとは、素材データを時分割多重したストリームデータである。図27にBD−ROMにおけるUDF(Unversal Disk Format)イメージのディレクトリ構成例を示すが、ここで「STREAM」ディレクトリにおけるm2tsファイルが、ここでいうクリップとなる。
【0009】
ステップF4としてクリップの再生確認が行われる。即ちクリップ段階で映像/音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
クリップの再生確認がOKとなったら、次にステップF5としてUDFイメージの作成が行われる。UDFイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものである。
UDFイメージを作成したら、ステップF6でエラーチェックが行われる。この場合PC上でベリファイヤによる論理チェックなどが行われる。
エラーチェックOKであれば、ステップF7でUDFイメージの再生確認が行われる。この場合UDFイメージについて、ハードウエアプレーヤで再生を行い、UDFイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【0010】
UDFイメージの再生確認がOKであれば、ステップF8でBD−R(書込可能型ブルーレイディスク)に対して、UDFイメージによるコンテンツ書込を行う。実際に生産するBD−ROMに近い光ディスク状態でのチェックを行うためである。そしてステップF9でBD−Rの再生を行い、内容を確認する。
その段階でOKであれば、ステップF10で、工場に転送するマスターデータとしてのカッティングマスタを作成することになる。
【0011】
以上の処理において、ステップF4,F6,F7,F9の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら、その修正を要する状況に応じて、ステップF1の素材データ段階、またはステップF2のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
【発明の概要】
【発明が解決しようとする課題】
【0012】
上記のオーサリング、特にマルチプレクサ処理においては、作業の効率化、高速化が求められている。
図28にクリップ作成、UDFイメージ作成の作業を模式的に示している。
ここで、Lドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにES(Elementary Stream)ファイル群が格納されているとする。ESファイルとは、素材データのファイルである。Cドライブは、パーソナルコンピュータ内部のワーク領域とする。
【0013】
上述のように、クリップ作成の際には、符号化された素材データ(ESファイルのデータ)の多重化処理が行われる。
クリップ100は、例えばMPEG2方式のストリームデータとされるが、管理情報としての4バイトのTPエクストラヘッダ(TP extra header)102や4バイトのパケットインフォメーション(Packet information)103とともに、184バイトのアダプテーションフィールド/データフィールド(adaptation field / data field)101が含まれる。データフィールドには、ESファイルの素材データがPES(Packetized Elementary Stream)パケットで転送され、コピーされる。
これらのコピーされる素材データは、かなり大容量となることが多く、マルチプレクサの処理時間は、データコピーに多く費やされて膨大なものとなる。
またUDFイメージ200は、クリップ100にメタデータ201等を付加したものとして生成されるが、大容量のクリップ100がコピーされるため、UDFイメージ200の生成の際も膨大な時間を要する。
【0014】
さらに、上記のようにクリップ100やUDFイメージ200の再生確認が行われて、再生結果に不具合などがあれば、再度マルチプレクサの工程前まで戻ることも多々ある。すると、上記の素材データのコピーを何度もやり直す状況が発生することになる。
このコピー処理時間は、データ量に比例するが、1つの工程に数時間を要することもあった。
【0015】
一方、作業の高速化の手法としては、処理の分散化なども考慮された。例えばコンテンツの部分毎に並行してマルチプレクサ処理を行うなどである。しかしその場合、データの分割、あるいは接続などが必要となり、分割点や接続点に、これまでの処理との互換性が取れない場合が想定された。
このようなことからオーサリング作業の長時間化が問題となっており、作業の効率化が求められている。
【0016】
なお、上記した特許文献1には、シミュレーションのターンアラウンドを短縮する技術が開示されているが、ディスク等に記録する実データの作成に関しての効率化は解決されていない。
【課題を解決するための手段】
【0017】
本発明のオーサリング方法は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程とを有する。
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する。
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する。
本発明のプログラムは、このようなオーサリング方法を情報処理装置において実行させるプログラムである。
また、上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材IDを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材IDについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする。
本発明の編集データ再生装置は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段とを有する。
【0018】
このような本発明では、クリップやUDFイメージ等として、大容量の素材データを加工したファイルを生成せず、仮想的にマルチプレクサを行うものである。即ち素材データのコピー処理を不要とし、従来コピー処理のために長時間を要していた作業時間を著しく短縮する。
また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
【発明の効果】
【0019】
本発明により、マルチプレクサの処理が従来に比して著しく時短化できる。例えば実際の使用においては、同等のクリップファイルやUDFイメージファイルを生成する場合において、従来比で約7倍高速とすることができた。このようなマルチプレクス処理の高速化により、オーサリング作業は格段に効率化される。
【図面の簡単な説明】
【0020】
【図1】本発明の実施の形態の仮想クリップ及び仮想UDFイメージの説明図である。
【図2】実施の形態のオーサリング工程のフローチャートである。
【図3】実施の形態のマルチプレクサモジュールの説明図である。
【図4】実施の形態で用いる素材データのディレクトリ構成例の説明図である。
【図5】実施の形態のクリップ生成時のディレクトリ構成例の説明図である。
【図6】実施の形態のES参照テーブルを構成するファイルの説明図である。
【図7】実施の形態のシークリストの説明図である。
【図8】UDFファイルシステムの説明図である。
【図9】従来のUDFイメージ生成時のディレクトリ構成例の説明図である。
【図10】実施の形態のUDFイメージ生成時のディレクトリ構成例の説明図である。
【図11】実施の形態の仮想クリップ参照テーブルを構成するファイルの説明図である。
【図12】実施の形態のエクステントマップ例の説明図である。
【図13】従来のUDFイメージ生成の説明図である。
【図14】実施の形態のUDFイメージ生成の説明図である。
【図15】実施の形態の仮想イメージを実体イメージにデコードした例の説明図である。
【図16】実施の形態のCPTBLファイルの説明図である。
【図17】実施の形態のカッティングマスタファイルの説明図である。
【図18】実施の形態の再生システムの説明図である。
【図19】実施の形態の仮想イメージ再生処理のフローチャートである。
【図20】実施の形態の仮想クリップ再生処理のフローチャートである。
【図21】実施の形態の他の再生システムの説明図である。
【図22】実施の形態のさらに他の再生システムの説明図である。
【図23】実施の形態のBD−R記録の説明図である。
【図24】実施の形態のBD−R書込処理のフローチャートである。
【図25】ディスク製造の流れの説明図である。
【図26】従来のオーサリング工程の説明図である。
【図27】BD−ROMのディレクトリ構成例の説明図である。
【図28】従来のクリップ・UDFイメージ作成の説明図である。
【発明を実施するための形態】
【0021】
以下、本発明の実施の形態を次の順序で説明する。
[1.システム動作概要]
[2.オーサリング工程]
[3.仮想クリップ]
[4.仮想UDFイメージ]
[5.カッティングマスタファイル]
[6.仮想クリップ・仮想UDFイメージの再生]
[7.編集データ再生装置]
[8.BD−R書込]
[9.実施の形態の効果及び変形例]
【0022】
[1.システム動作概要]
実施の形態において、ディスク製造の全体の流れは、図25で説明したものと同様である。本実施の形態では、特にクリップの仮想化、UDFイメージの仮想化を行うことで、マルチプレクサ処理(図25のS6)の効率化を実現する。
【0023】
図1にマルチプレクサ処理の際に生成する仮想クリップ、仮想UDFイメージを模式的に示す。
Lドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにES(Elementary Stream)ファイル群が格納されている。
マルチプレクサ処理の際には、まず仮想クリップ10の作成を行う。
従来は図28で述べたように、クリップ100が、実際の素材データがコピーされて生成されるが、本例の場合、素材データを含まない仮想クリップ10が生成される。
【0024】
仮想クリップ10は、管理情報としての4バイトのTPエクストラヘッダ(TP extra header)12や4バイトのパケットインフォメーション(Packet information)13とともに、ES参照テーブル11を有するファイル構造として形成される。
本来クリップは、MPEG2方式のストリームデータとしてPESパケット単位の実データの集合であるが、ここでは、各PESパケットは、そのTPエクストラヘッダ12とパケットインフォメーション13のみで表現されているということができる。
そしてTPエクストラヘッダ12に対応する実素材データのポインタ情報が、ES参照テーブル11に格納されている。
つまり、仮想クリップ生成処理では、ESファイルの実データコピーは行われない。
また仮想クリップ10の再生には、ES参照テーブル11を用いて実際の素材データを特定し、ESファイル群の中からリードしてくることによって行う。
【0025】
仮想UDFイメージ20は、管理情報としてのメタデータ22と、仮想クリップ参照テーブル21を有する。
この仮想UDFイメージ20も、素材データとしての実データはコピーされない。仮想クリップ参照テーブル21によって、仮想的に実データが表現される。
仮想UDFイメージ20の再生は、仮想クリップ参照テーブル21から、仮想クリップ10のES参照テーブル11を参照し、そのES参照テーブル11から実際のESファイルを指定して、読み出すことにより実現する。
【0026】
このように本例では、大容量の素材データを加工したファイルを生成せず、エンコードした素材データ(ESファイル)を直接リードしながら仮想的にマルチプレクサを行い、ハードディスク(Lドライブ)などの媒体のI/O部分を極力減らした仮想処理を実行する。
【0027】
[2.オーサリング工程]
図25のS3〜S6として示したオーサリングスタジオで行われる工程として、実施の形態のオーサリング工程を図2に示す。
図2のステップF101として、素材データ処理としてのエンコードがおこなわれ、映像、音声等の素材データが符号化される。符号化された素材データは、ESファイルとして図1のLドライブに格納された状態となる。
【0028】
ステップF102として、オーサリングアプリケーションによるデータ作成が行われる。これは図25のS4,S5のメニュー作成や編集等となる。
そしてマルチプレクサ処理(図25のS6)として、ステップF103〜F110が行われる。
【0029】
マルチプレクサ処理は、オーサリング作業に用いるパーソナルコンピュータにおいて起動されるマルチプレクサモジュールとしてのプログラムに基づいて行われる。
なお、従来のマルチプレクサモジュールは、オーサリングスタジオに配布され実際のディスクタイトル製作のために運用されてきている。そのため、たとえ処理速度が高速化したとしても、互換性がないものや、置き換えによって信頼性が落ちるものは、許容されるものでない。そのため、本例で導入する新たなマルチプレクサモジュールは、従来のマルチプレクサモジュールをコールしていたものと同じオーサリングアプリケーションや再生装置、ベリファイヤ(Verifier)が利用できるシステム設計を行うことが適切である。
【0030】
本例におけるマルチプレクサモジュールは、図3(a)に示すように、大きくわけて仮想クリップ生成部1,メタデータ生成部2,仮想UDFイメージ/カッティングマスタ生成部3の3つのパートから構成される。
仮想クリップ生成部1は、MPEG2トランスポートストリームフォーマットのクリップファイル生成を仮想的に行う。
メタデータ生成部2は、ディスクに記録するメタデータ生成を行う。
仮想UDFイメージ/カッティングマスタ生成部3は、仮想的にUDFイメージを作成し、またカッティングマスタを作成する。これらは、DLL(ダイナミックリンクライブラリ)として、オーサリングスタジオで使用される、一般にオーサリングアプリケーションと呼ばれるソフトウェアから動的にリンクして実行される。
従来のマルチプレクサモジュールからの置き換えは、このDLLの入れ替えのみなので、使用中のシステムへの本実施の形態の導入は容易である。
【0031】
なお、本例のマルチプレクサモジュールとしてのプログラムは、パーソナルコンピュータ等の機器に内蔵されている記録媒体としてのHDD、ROM、フラッシュメモリ等に予め記録しておくことができる。
あるいはまた、フレキシブルディスク、CD−ROM(Compact Disc Read Only Memory)、MO(Magnet optical)ディスク、DVD、ブルーレイディスク、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納(記録)しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、プログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、LAN(Local Area Network)、インターネットなどのネットワークを介してダウンロードすることもできる。
【0032】
図2のステップF103では、仮想クリップ生成部1により仮想クリップ10の作成が行われる。本来クリップとは、素材データを時分割多重したストリームデータである。例えば図3(b)に示すように、エレメンタリストリームとしての素材データ(映像、音声、IG(Interactive Graphics)、PG(Presentation Graphics)、テキストサブタイトル)等をマルチプレクスしてトランスポートストリーム(TS)としたものである。
本例の場合、実際の素材データはコピーせずに、図1に示したように、TPエクストラヘッダ12、パケットインフォメーション13、ES参照テーブル11を有するファイル構造として仮想クリップ10を生成する。
【0033】
ステップF104として仮想クリップ10を用いた再生確認が行われる。即ちクリップ段階で映像/音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
【0034】
仮想クリップ10によるクリップ内容の再生確認がOKとなったら、次にステップF105として、仮想UDFイメージ/カッティングマスタ生成部3により、仮想UDFイメージ20の作成が行われる。本来のUDFイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものであるが、これを仮想的に生成する。
メタデータはメタデータ生成部2が作成する。そして仮想UDFイメージ/カッティングマスタ生成部3の処理により、仮想UDFイメージ20が作成される。
仮想UDFイメージ20は、図1に示すようにメタデータ22と、仮想クリップ参照テーブル21を含むものとされる。
なお、カッティングマスタファイル(CMF)の一部データの作成も同時に行われる。例えばコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが作成される。
【0035】
仮想UDFイメージ20を作成したら、ステップF106でエラーチェックが行われる。この場合PC上でベリファイヤによる論理チェックなどが行われる。
エラーチェックOKであれば、ステップF107で仮想UDFイメージ20の再生確認が行われる。即ち仮想UDFイメージ20における仮想クリップ参照テーブル21、及びES参照テーブル11に基づいて再生を行い、UDFイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【0036】
仮想UDFイメージ20の再生確認がOKであれば、ステップF108でBD−R(書込可能型ブルーレイディスク)に対して、仮想UDFイメージ20によるコンテンツ書込を行う。実際に生産するBD−ROMに近い光ディスク状態でのチェックを行うためである。この場合、仮想クリップ参照テーブル21、及びES参照テーブル11に基づいて書込データとしてのストリームが形成され、BD−Rへの書込が行われることになる。
そしてステップF109でBD−Rの再生を行い、内容を確認する。
【0037】
その段階でOKであれば、ステップF110で、仮想UDFイメージ/カッティングマスタ生成部3により、工場に転送するマスターデータとしてのカッティングマスタが作成される。即ち仮想UDFイメージから実体化されたUDFイメージを作成し、さらに上記のコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどを付加して、カッティングマスタファイルが作成される。
【0038】
以上の処理においては、ステップF104,F106,F107,F109の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら内容修正を行う。即ちその修正を要する状況に応じて、ステップF101の素材データ段階、またはステップF102のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
以下では、この図2の処理で作成される仮想クリップ10、仮想UDFイメージ20の内容、さらにはこれらの再生動作、BD−Rへの書込について説明する。
【0039】
[3.仮想クリップ]
先に述べたように従来は、クリップとして素材データの実体をコピーしたクリップを生成していたところ、本例では素材データの実体を含まない仮想クリップ10を生成するものである。従来のクリップファイルと比較しながら、本例の仮想クリップ10について説明する。
【0040】
まず図4は、図1のLドライブにESファイルとして格納される素材データについてのディレクトリ構成を示している。
図のように、「ESData」ディレクトリ下に「VIDEO」「AUDIO」ディレクトリが配置される。そして「VIDEO」下に「MPEG2」「AVC」ディレクトリが配置され、「MPEG2」下の「MOVIE1」「MOVIE2」等のディレクトリ下にESファイルとしての「sample1.ves」等が配置される。また「AVC」下にもESファイルとしての「sample2.ves」等が配置される。
従来では、「sample1.ves」「sample2.ves」等のESファイルがクリップ作成時にコピーされていたものである。
【0041】
図5(a)に、従来のクリップのディレクトリ構造を示してる。図のように例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のクリップファイルが配される。この「00001.m2ts」等のクリップファイルが、素材データがマルチプレクスされてコピーされたストリームデータであり、これらはデータサイズが大きなものとなっていた。
【0042】
本例の場合、従来最も容量を必要としていたクリップファイル(m2tsファイル)を仮想化する。
図5(b)が仮想化した場合のディレクトリ構造の例である。例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のディレクトリを配置する。
即ち従来のファイルが図5(a)のように単一ファイル「00001.m2ts」等であったところ、本例の仮想ファイルシステムでは「00001.m2ts」等をディレクトリとして配置する。そして「00001.m2ts」等のディレクトリ下に、「Packetbase」「Packetinfo」「Seek.lst」「ES.List」としての各ファイルを配置する。
この4つのファイル「Packetbase」「Packetinfo」「Seek.lst」「ES.List」が、図1に示したES参照テーブル11を構成するものとなる。
【0043】
各ファイルを説明する。
・Packetbase (パケットベース)
パケットベースは、TSパケット(TSPacket)のヘッダー/システムパケットの集まりである。
図6(b)にパケットベースを示すが、その説明のため、先に図6(a)で仮想化されたクリップを実体のあるクリップにデコードした状態を説明する。
クリップの実体は、192バイトのTSパケット(図6(a)の一行)から構成される。
ここでは1行目、2行目のTSパケットには、TP_extra_header(4バイト)、PacketInformation(4バイト)、 adaptation_field(184バイト)が含まれるものとし、3行目以降のTSパケットには、TP_extra_header(4バイト)、PacketInformation(4バイト)、 data_field(184バイト)が含まれるものとしている。データフィールド(data_field)とは、実際にESファイルの一部(素材データの一部)がコピーされているものである。
これは図28で模式的に示した従来のクリップの構造に相当する。
【0044】
本例の仮想クリップ10を構成するパケットベースは、図6(b)のようになり、図6(a)におけるdata_fieldが無い構成となる。つまりパケットベースは、素材データの実体がない状態でクリップ実体の管理情報を集めたものと言える。
具体的には、図6(b)の1行目、2行目のTSパケットには、TPエクストラヘッダ(TP_extra_header:4バイト)、パケットインフォメーション(PacketInformation:4バイト)、アダプテーションフィールド(adaptation_field:184バイト)が含まれる。
図6(b)の3行目以降は、それぞれTPエクストラヘッダ(TP_extra_header:4バイト)、パケットインフォメーション(PacketInformation:4バイト)の8バイトの構造となる。パケットインフォメーションには、実際のESファイルの一部である実体データのパケットを示すPIDが含まれている。
パケットベースを構成するそれぞれのTSパケットのサイズは 次のPacketinfoファイルに示されることになる。
【0045】
・Packetinfo(パケットインフォファイル)
図6(c)にパケットインフォファイル(Packetinfo)を示す。パケットインフォファイルは、先頭から1バイトずつがパケットベースファイル中のTSパケットのサイズを示すものとされる。
実データとしてのTSパケットは、図6(a)のように192バイトであるが、図6(b)のようにパケットベースにはデータフィールドが存在しないTSパケットもある。TSパケットの最小サイズは、図6(b)の3行目のようにTPエクストラヘッダとパケットインフォメーションの8バイトである。
このためパケットインフォファイルの各バイトは、8〜192バイトの範囲で、パケットベースファイル中の各TSパケットのサイズを示す。
【0046】
・ES.list(ESリストファイル)
ESリストは、TSパケットのパケットベース以外のデータ部分の参照元のファイル名とPIDの関係を示すテキストファイルが記述される。
フォーマットは、
PID,ファイルパス[改行]
PID,ファイルパス[改行]
・
・
とされる。
【0047】
例えば図6(d)に例を示す。
「PID3,L:\ESData\VIDEO\MOVIE\MPEG-2\sample1.ves」
とは、「PID3」というPIDに対応するデータとしての「sample1.ves」について、図4のディレクトリ構造での「sample1.ves」ファイルに至るディレクトリパスが記述されていることになる。
同様に「PID5,L:\ESData\VIDEO\AVC\sample2.ves」は、「PID5」というPIDに対応するデータとしての「sample2.ves」について、図4のディレクトリ構造での「sample2.ves」ファイルに至るパスが記述されている。
【0048】
つまり、パケットベース内の或るTSパケットにおけるパケットインフォメーションに示されているPIDに対応して、例えば図6(a)(e)の関係のように、本来データフィールドにコピーされるべきESファイルが示される。つまり仮想クリップ再生時に読み出されるべき、ESファイルが示されることになる。
【0049】
・Seek.lst(シークリストファイル)
シークリストファイルは、シーク用の情報を示すファイルである。
上記の他の3つのファイルでもデコードは可能であるが、シーク情報を追加することによって高速シークに対応できる。
実際に、仮想クリップ10の映像などを再生するときには、このシーク情報がないと再生が間に合わない場合も生ずる。
【0050】
シークリストファイルには、PIDごとの対応のフォーマットで例えば、100SPN(Source Packet Number)として19200バイトごとのポジション情報が記述されている。
例えば図7に示すように、先頭に「version」として、この構成(フォーマット)のバージョン番号(例えば「0x00000001」)が示される。次に、「SPN interval」としてインターバル値が示される。ここで「0x0064」=100であり、100SPN間隔であることが示されている。また「PID Count」としてPID(素材に割り振られる個体番号)の個数が示される。以降は、100SPN毎のリストが続く。
【0051】
リスト内では、TSパケットのヘッダファイル(パケットベース)のポジションが示される。例えば図では「0A18」としているが、これによってパケットベースの位置が示される。
また、PIDに対応するESファイルのポジションが示される。例えば図のように「00A5」として、PID=1011とされた素材ファイル内の位置が示される。
【0052】
シークの例を説明する。
仮に19200byteからデータを読み出したい場合、シークリストファイルの2つめのリストを読み込む。そしてパケットベースの位置「0A18」に基づいてパケットベースファイルを参照する。
またPIDに対応するESファイルのポジションを読み込む。そして例えば「00A5」として、素材ファイル内の位置を確認し、素材ファイル(ESファイル)を読み出す。
【0053】
以上の各ファイルで構成される仮想クリップ10に基づくデータの読み込みは次の(P1)〜(P6)のように行われる。
(P1)パケットインフォファイルを1バイト読む。(「A」とする)
(P2)パケットベースファイルから (A)バイト数読み込む。(「B」とする)
(P3) ((B)[5]&1F)<<8 + (B)[6] (TSパケット中のPIDの位置) (「C」とする)
(P4)ESリストファイルのPIDと(C)が一致するファイルから、1パケットサイズは192バイト固定であることから、 (192-(A))バイト読み込む 。(「D」とする)
(P5) (B)のバイト列 と (D)のバイト列 を結合したものをファイルとして出力する。
(P6)上記(P1)に戻る。これをパケットインフォファイルの終了まで繰り返す。
よって、復元されたファイルのサイズは、
ファイルのサイズ=(パケットベースファイルサイズ)×192
となる。
【0054】
以上のように仮想クリップ10は、TPエクストラヘッダ12、パケットインフォメーション13とともに、ES参照テーブル(「Packetbase」「Packetinfo」「Seek.lst」「ES.List」)11を有するファイル構造として形成される。
この場合、MPEG2方式のストリームデータとしてPESパケット単位の実データの集合であるクリップが、仮想的に表現されるものとなる。そして、仮想クリップ生成時には大容量のESファイルデータのコピーは行われないため、作成時間は非常に短縮される。また仮想クリップ10の再生には、ES参照テーブル11を用いて実際のESファイルデータを特定し、ESファイル群の中からリードしてくることによって行うことができる。
【0055】
[4.仮想UDFイメージ]
次に仮想UDFイメージ20について説明する。
図3(a)に示したマルチプレクサモジュールでは、仮想クリップ生成部1が生成した上述した仮想クリップ10や、メタデータ生成部2が生成したメタデータ22に基づいて、仮想UDFイメージ/カッティングマスタ生成部3がUDF2.5イメージを生成する。図2のステップF105の処理である。
一例としてUDF1.02ブリッジファイルシステムを図8に示す。UDFは、管理情報(メタデータ)とファイル実体に分けて考える。
【0056】
まず比較のため、従来のUDFイメージ生成時のディレクトリ構造例を図9に示す。
図9において実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」までの構造は上記図5(a)と同様である。即ちクリップファイル部分を示している。
UDFイメージ生成によって、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルが配置される。なお「ImageFile0」「ImageFile1」は、UDFイメージ変換されたストリームデータである。また「CPTBL0」「CPTBL1」はコピープロテクションテーブルとしてのファイルである。また「UCD0」「UCD1」はユーザコントロールデータとしてのファイルである。
【0057】
図10はクリップからUDFイメージへの変換を模式的に示したものである。例えば記録層が2層のブルーレイディスクのオーサリング工程における例として、第1層用のファイル、第2層用のファイルとしてのUDFイメージ生成時を示している。第1層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」を生成する。また第2層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」を生成する。
これらのファイルが、図9のように「SAMPLEIMAGE」ディレクトリ下に配置される。
【0058】
ここで図9の構造において、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルは、実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」の各ファイルの実データを用いてUDF変換するものであり、サイズが大きい。
このため、実体としてUDFイメージ生成を行っていた従来は、その処理時間が長時間化していた。
【0059】
これに対し、本例の仮想UDFイメージ20のディレクトリ構造を図11に示す。
図11において「00001.m2ts」「00002.m2ts」「00003.m2ts」等は、上述したように実体ファイルではなく仮想クリップ10を構成するディレクトリである。これらのディレクトリ下に上述した、ES参照テーブル11を構成するパケットベースファイル、パケットインフォファイル、シークリストファイル、ESリストファイルが配されるが、これらのデータサイズは小さい。実際の素材データがコピーされているわけではないためである。
【0060】
UDFイメージ変換により、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」が、それぞれ実体ファイルではなくディレクトリとして配置される。
「ImageFile0」「ImageFile1」ディレクトリ下には、「Extent.map」「SourceFileList.map」「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルが配置される。
特に「Extent.map」「SourceFileList.map」が、図1の仮想クリップ参照テーブル21を構成するものとなる。
また「CPTBL0」「CPTBL1」ディレクトリ下には、「Extent.map」「Header.map」の各ファイルが配置され、また「UCD0」「UCD1」ディレクトリ下には「Extent.map」ファイルが配置される。
【0061】
図12にクリップからUDFイメージへの変換を模式的に示すが、例えば記録層が2層のブルーレイディスクのオーサリング工程における例として、第1層(レイヤ0)用のファイル、第2層(レイヤ1)用のファイルとしてのUDFイメージ生成を行う場合である。第1層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」ディレクトリを生成し、また第2層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」ディレクトリを生成する。そして、各ディレクトリ下に上記「Extent.map」等のファイルを配置して図11の「SAMPLEIMAGE」ディレクトリ下に配置する。このUDFイメージ変換においては、素材データとしての実データのコピーは伴わない。
【0062】
ここで図11において「ImageFile0」「ImageFile1」ディレクトリ下の「Extent.map」「SourceFileList.map」等のファイルは、素材データによるストリームデータがコピーされているものではないためデータサイズは小さいものとなる。「CPTBL0」「CPTBL1」「UCD0」「UCD1」の各ディレクトリ下のファイルも同様にデータサイズは小さい。
つまり、大容量データのコピーを伴わずにUDFイメージ生成が行われる。
【0063】
形成されるファイルについて説明する。
・Extent.map(エクステントマップファイル)
「ImageFile0」「ImageFile1」等のディレクトリ下に配置されるエクステントマップファイルには、UDF上に配置されるファイルそれぞれの論理アドレスであるエクステント情報が記録されている。
エクステント情報では、例えば「m2ts」ファイルが物理的にインターリーブして配置される場合などの、それぞれのブロックの論理アドレスとバイトサイズが記録されている。
【0064】
エクステントマップファイルは例えば図13(a)のように構成される。即ちエクステントマップファイルのID、バージョンナンバ、トータルブロック、レイヤオフセットLSN(Logical Sector Number)が記述される。トータルブロックは、イメージ内のセクタ数である。2層ディスク(デュアルレイヤディスク)でレイヤが別ファイルになる場合はレイヤ毎のセクタ数となる。レイヤオフセットLSNは、第2記録層(レイヤ1)の論理セクタナンバである。
そしてエクステント情報として、エクステントナンバー毎に、開始LSN、エクステントサイズ、登録元ファイル、登録元ファイル内オフセットが記述される。
【0065】
例えば仮想化されているUDFイメージを実体のあるイメージにデコードした状態を図14に示すが、イメージ化では図示のように1つのファイルを複数のブロックに分割して配置することができる。図では例えば00001.m2tsファイルを「00001.m2ts(1)」「00001.m2ts(2)」「00001.m2ts(3)」に分割している。
このような例の場合、エクステントマップファイルには、次のように各参照ファイルのエクステント(アドレス)情報が入る。
00001.m2ts:A0, A1, A2
00002.m2ts:B0
00003.m2ts:C0
【0066】
・SourceFileList.map(ソースファイルリストマップ)
ソースファイルリストマップは、ファイルそれぞれの実体のPC上の絶対ファイルパスが記録されている。
ソースファイルリストマップの例を図13(a)に示す。
ソースファイルリストマップには、図のようにファイルバージョン、リスト数が記述され、「File0」「File1」「File2」・・・として各ファイルの絶対ファイルパス、サイズ、作成日時、更新日時が記述される。
【0067】
例えば図14の例においていえば、各ファイルの情報として、次のように記述される。
00001.m2ts:C:\SAMPLE\BDMV\STREAM\00001.m2ts
00002.m2ts:C:\SAMPLE\BDMV\STREAM\00002.m2ts
00003.m2ts:C:\SAMPLE\BDMV\STREAM\00003.m2ts
【0068】
「ImageFile0」「ImageFile1」等のディレクトリ下に配置される「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルは、UDFの管理情報用ファイルである。これらのファイルは、図14の例ではxxxxx.m2ts以外の仮想化されていない情報が入る。
図15にUDFイメージファイルを示すが、「UDFHeader.map」ファイルは、UDFイメージ内のボリュームシーケンス(Anchorを含む)のデータである。
「UDFFooter.map」ファイルは、UDFイメージ内のリザーブボリュームシーケンス(Anchorを含む)のデータである。
「UDFMetadata.map」ファイルは、UDFイメージ内のメタデータのファイルである。
「UDFMetadataMirror.map」は、UDFイメージ内のメタデータミラーのファイルである。
【0069】
仮想UDFイメージ20の再生時においては、エクステントマップファイルによって各ファイルが指定され、ソースファイルリストマップによって、各ファイルのパスが判別される。各ファイルのパスは、仮想クリップ10としてのディレクトリ(「00001.m2ts」「00002.m2ts」「00003.m2ts」等)を示すものとなる。
上述したように、これらの仮想クリップ10としてのディレクトリには、ES参照テーブル11を構成するファイルが配置されている。
このため、上述した(P1)〜(P6)の手順で仮想クリップ10に基づく素材データの読み込みが行われる。
即ち、仮想UDFイメージ20の再生では、仮想クリップ参照テーブル(「Extent.map」「SourceFileList.map」)21から、ES参照テーブル(「Packetbase」「Packetinfo」「Seek.lst」「ES.List」)11を参照し、ES参照テーブル11に基づいて実体としてのESファイルを読み出すことになる。
【0070】
なお、「UCD0」「UCD1」ディレクトリ下の「Extent.map」ファイルは図16(a)のようになる。
ここには、UCDマップID、バージョンナンバ、UCDファイルサイズ、レイヤオフセットLSN、UCDアイテムサイズが記述される。
そしてUCDのエクステント情報として、エクステントナンバー毎に、開始LSN、ブロック数、データが記述される。
【0071】
また「CPTBL0」「CPTBL1」ディレクトリ下の「Extent.map」ファイルは図16(b)のようになる。
ここには、CPTマップID、バージョンナンバ、CPTBLファイルサイズ、ヘッダーサイズ、レイヤオフセットLSNが記述される。
そしてCPTのエクステント情報として、エクステントナンバー毎に、開始LSN、ブロック数、クリップナンバ等が記述される。
「CPTBL0」「CPTBL1」ディレクトリ下の「Header」ファイルは図17のように、ジェネラルブロックデータ、ロケーションブロックデータを含む。
【0072】
以上のように仮想UDFイメージ20は、仮想クリップ参照テーブル(「Extent.map」「SourceFileList.map」)21によって、仮想的に実データが表現されるものとなる。仮想UDFイメージ作成時にはESファイルの実データはコピーされない。従って仮想UDFイメージ20の作成時間は著しく短縮される。
また仮想UDFイメージ20の再生は、仮想クリップ参照テーブル21から、仮想クリップ10のES参照テーブル11を参照し、そのES参照テーブル11から実際のESファイルを指定して、読み出すことにより実現できる。
【0073】
[5.カッティングマスタファイル]
本例のマルチプレクサモジュールでは、仮想UDFイメージ/カッティングマスタ生成部3は、UDFイメージのほかに、ディスクプラントでディスク生成に必要なカッティングマスタファイルも生成する。
カッティングマスタの例としては、次のようなファイルがある。
・UDFイメージファイル
・コントロールデータファイル
・暗号化テーブルファイル
・物理情報ファイル
【0074】
UDFイメージファイルは上述のように高速化処理が行われる。コントロールデータファイル、暗号化テーブルファイルも、圧縮した形でマルチプレクサから出力することによって高速化を行う。
例えば、コントロールデータファイルは、イメージファイルの1024分の18のサイズがあるが、全てゼロデータであるとき、ファイルサイズ4バイトまで圧縮を行うことができる。
これらのカッティングマスタファイルへの復号は、次の工程のディスクプラント転送(通称ダウンローダ)によって行われる。
ダウンローダは、ディスクプラントへの出荷時1回だけ実施されるため、この工程によるオーサリングスタジオでのワークフロー全体から見るとオーバーヘッドは少ない。
【0075】
[6.仮想クリップ・仮想UDFイメージの再生]
上述した仮想クリップ10、仮想UDFイメージ20の再生の具体例を説明する。
再生は、ファイルシステムを管理するソフトウェアをバックグラウンドで実行することで行う。仮想ファイルシステムには、以下の第1〜第3の再生システムのいずれかで実現できる。
【0076】
<第1の再生システム>
任意のディレクトリを指定すると、そのディレクトリ以下のファイルが任意のファイルシステムとして見えるようにしたシステムである。
【0077】
図18に構成を示す。なお図において太線で示すVFSインターフェース(Virtual File System Interface)30、アザーファイルシステム(Other File System)31は、OS(Operating System)のモジュールである。ここではWindows(登録商標)のOSとする。また破線で示すシステムサービス(System Service(Client))33,システムサービス(System Service(Server))34、フューズモジュール(Fuse Module)32、DLL(Dynamic Link Library)35はオープンソースである。ファイルシステムアプリケーション(File System Application)36が新規開発したモジュールとなる。
【0078】
ファイルシステムアプリケーション36は、仮想化されたクリップやイメージファイルが、あたかも実体のあるクリップやイメージファイルに見えるファイルシステムに変換するモジュールである。即ち素材データのファイルパスやオフセット、サイズなどを参照する。
なお通常のファイルシステムは、OSのカーネルの一部として実装されているが,FUSEというカーネルモジュールを利用するとファイルシステムをユーザランドで実装することができる。
DLL35では、ユーザスペースとカーネル部のフューズモジュール32との橋渡しが行われる。
フューズモジュール32では、任意のディレクトリはユーザー指定のファイルシステムとして参照される。フューズモジュール32はOSへはデバイスドライバとして登録する。
アザーファイルシステム31は、指定外のファイルへのリクエストに対応するファイルシステムであり、OSで決められたファイルシステム(例えばFAT32,NTFS)などでファイルを参照する。
【0079】
この構成においてカーネル部では、OSからのファイルのCREATE、READなどのサービスをユーザスペースのアプリケーションプログラムへ通知を行う。アプリケーションプログラムでは、仮想ファイルシステムを各サービスに対して処理し、カーネル部に完了通知を行う。
【0080】
UDFイメージの再生手順を図19に示す。
例えばソフトウエアプレーヤなどのアプリケーションからUDFイメージファイルのアクセスがリクエストされることで、ステップF201からの処理が行われる。
ステップF201ではリクエストされたイメージファイルが仮想UDFイメージ20として仮想化されているものであるか否かを判別する。
【0081】
リクエスト対象が仮想化されたUDFイメージの場合は、ステップF202で、ファイルシステムアプリケーション36が、リクエストされたUDFイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル21を参照する。そして仮想UDFイメージ20を実イメージに変換する。
例えばアプリケーションが、「ImageFile0」を実体ファイルとしてリクエストしたとする。本例の場合、図11で示したように同じ名前の「ImageFile0」ディレクトリが形成され、そのディレクトリ下にエクステントマップファイル、ソースファイルリストマップによる仮想クリップ参照テーブル21が形成されている。
ファイルシステムアプリケーション36は、仮想クリップ参照テーブル21、及びそこから参照されるES参照テーブル11を用いて、ローカル(例えばLドライブ)、あるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
なお仮想化されていない実体のUDFイメージがリクエスト対象であれば、そのまま当該UDFイメージファイルを再生すればよい(F201→NO)。
【0082】
ここで、UDFイメージ内でクリップファイル「xxxxx.m2ts」が含まれている場合、ステップF203からF204に進み、当該リクエストされたクリップが仮想化されたクリップであるか否かを判断する。
仮想化されたクリップである場合は、ファイルシステムアプリケーション36はステップF205で、アプリケーションなどでリクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を読み出す。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
なお、UDFイメージファイル内に実体があるクリップとして「xxxxx.m2ts」ファイルが含まれているときは、当該「xxxxx.m2ts」をそのままアプリケーションなどのリクエストに応じて再生できる(F204→NO)。
【0083】
クリップの再生手順は図20のようになる。
アプリケーションからクリップファイルのアクセスがリクエストされることで、ステップF250からの処理が行われる。
ステップF250ではリクエストされたクリップが仮想クリップ10として仮想化されているものであるか否かを判別する。
仮想化されていない実体クリップであれば、そのまま当該クリップファイルを再生すればよい(F250→NO)。
【0084】
リクエストが仮想化されたクリップであった場合は、ファイルシステムアプリケーション16はステップF251で、リクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を読み出す。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、実クリップに変換し、元のクリップファイルを再生する。
【0085】
<第2の再生システム>
第2の再生システムは、任意のディレクトリ以下のファイルが、ファイルシステムの規格であるUDF2.5あるいはUDF2.01を参照するシステムである。
【0086】
図21に構成を示す。この場合、太線で示すVFSインターフェース(Virtual File System Interface)30、アザーファイルシステム(Other File System)31は、OS(Operating System)のモジュールである。またシステムサービス(System Service(Client))33A,システムサービス(System Service(Server))34A、フューズモジュール(Fuse Module)32A、DLL(Dynamic Link Library)35A、ファイルシステムアプリケーション(File System Application)36が新規開発したモジュールとなる。
【0087】
ファイルシステムアプリケーション36は仮想化イメージファイルが実体のある光ディスク(BD)に見えるファイルシステムに変換する。
DLL35Aでは、ユーザスペースとカーネル部のフューズモジュール32との橋渡しが行われる。
フューズモジュール32Aでは、任意のUDF2.5(UDF2.01)のUDFイメージファイルは、ディレクトリに見えるようになる。OSへはデバイスドライバとして登録する。
アザーファイルシステム31は、指定外のファイルへのリクエストについて、OSで決められたファイルシステム(例FAT32,NTFS)などでファイルを参照する。
【0088】
BDはUDF2.5の規定があるため、マルチプレクサが出力するUDFイメージは、この構成においては、ディレクトリとしてOS上見えることになる。
なおWindowsXP(登録商標)のようにUDF2.5を標準サポートしていないOSにおいては、標準サポートしているUDF2.01へファイルシステムアプリケーション36で変換する。
【0089】
この場合、仮想UDFイメージの再生手順は上記図19と同様となる。
仮想クリップ10については、この構成では再生できない。UDFではないためである。
再生するときは、仮想化されたクリップを含んだディレクトリで仮想化UDFイメージ20、あるいは実体のあるUDFイメージを生成する必要がある。その再生手順は、図19のステップF203〜F205によるものとなる。
しかしながら、仮想化UDFイメージ20の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想UDFイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
【0090】
<第3の再生システム>
第3の再生システムを図22に示す。これはハードウェアエミュレータ(Hエミュレータ)による再生システムである。
ハードウェアエミュレータとは、ATA(SATA)接続したPCホスト、あるいはCEプレーヤーから、あたかもドライブが接続したかのように見えるシステムである。本例は、ハードウェアエミュレータのイメージファイルの再生部にフィルタリングを行うことによって、仮想ファイルを実際のイメージファイルとして見せかけるシステムである。
【0091】
図22(a)(b)に示すように、ホストPC50とHエミュレータ用PC51が、PCI基板52においてSATA等で接続される。
図22(a)の再生処理前の状態では、ホストPC50から、Hエミュレータ用PC51内のHDD53において仮想UDFイメージ構造が認識される。
再生時は、Hエミュレータ用PC51側で仮想クリップ参照テーブル21を用いて直接素材ファイルの読み出しを行う。ホストPC50からは、図22(b)のように、光ディスクのファイルシステムがあたかもHエミュレータ用PC51側にマウントされたかのように見える。つまり本来のUDFイメージファイルにデコードされて見える。
このシステムでは、SATAなどのインターフェースを持つ専用のPCI基板52などのハードウェアの追加が必要となるが、Hエミュレータを実現するアプリケーションへの少ない対応で再生システムを実現できる。
【0092】
UDFイメージファイルの再生手順は次のようになる。
仮想化されたUDFイメージファイルをホストPC50上のアプリケーションなど(例ソフトウェアプレーヤーなど)からリクエストされることで再生処理を行う。この場合、Hエミュレータ用PC51上で機能しているアプリケーションプログラムでリクエストされたUDFイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル21を参照する。そしてローカルあるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
【0093】
UDFイメージファイル内にクリップが含まれているときは次のようになる。例えば「xxxxx.m2ts」ファイルがアプリケーションなどでリクエストされたとき、Hエミュレータ用PC51上で走るアプリケーションプログラムで「xxxxx.m2ts」ディレクトリ以下のES参照テーブル11を参照する。そしてES参照テーブル11をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
【0094】
なお、この構成では、UDFではないので仮想化されたクリップは再生することはできない。仮想クリップ10を再生するときは、仮想化されたクリップを含んだディレクトリで仮想UDFイメージ20、あるいは実体のあるUDFイメージを生成する必要がある。
しかしながら、仮想化UDFイメージ20の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想UDFイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
【0095】
[7.編集データ再生装置]
ところで、さらに図22のHエミュレータ用PC51で実行するアプリケーションに、上述した本実施の形態のマルチプレクサ処理を行わせることも可能である。
即ち当該アプリケーションにおけるソフトウエア及びHエミュレータ用PC51におけるハードウエアを用いて、仮想クリップ生成手段と、仮想イメージ生成手段と、仮想イメージ再生手段を形成する。
仮想クリップ生成手段は、図2のステップF103の処理を行う。即ち仮想クリップ生成手段は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対するES参照テーブル11を有する仮想クリップ10を生成する。
仮想イメージ生成手段は、図2のステップF105の処理を行う。即ち仮想イメージ生成手段は、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、仮想クリップ10を参照する仮想クリップ参照テーブル21を有するイメージファイル構造としての仮想イメージ20を生成する。
仮想イメージ再生手段は、図2のステップF107の処理を行う。即ち仮想イメージ再生手段は、仮想イメージ20の再生を、仮想クリップ参照テーブル21を用い、ES参照テーブル11を介して素材データを読み出すことで実現する。
【0096】
通常Hエミュレータが再生できるUDFイメージファイルは、ディスクのイメージとして1つのファイルでなければならない。このためマルチプレクサ処理を行ったUDFイメージファイルを再生の対象として、Hエミュレータのアプリケーションに登録していた。ここで、UDFイメージ化する前の多数のフォルダおよびファイルから構成されるコンテンツをアプリケーションに登録し、上述した仮想的なファイル形成を行うマルチプレクサ処理を行って仮想化されたUDFイメージを作成する。すると、それを再生することができるようになる。
【0097】
このように、Hエミュレータのアプリケーションに本実施の形態のマルチプレクサ処理を行わせることにより、フォルダおよびファイルの状態から短時間でUDFイメージファイルに変換することができ、Hエミュレータで再生確認を行うことができるようになる。これにより、オーサリング処理で行っていた、映像データ、音声データ、メニューデータ、字幕データ、JAVAプログラム等の差し替え作業を、オーサリング処理を介さずにファイルを差し替えるだけで再生確認ができるようになり、オーサリングの効率化が実現できる。
つまり、本発明の編集データ再生装置としてのエミュレータを実現できる。
【0098】
[8.BD−R書込]
続いて図2のステップF108のBD−R書込について説明する。
図25,図3等で上述してきたように、オーサリングシステムにおけるマルチプレクサは、エンコーダにより符号化された映像データや音声データ、メニュなどを多重化するためのものである。そしてハードディスク内に格納された画像、音声、字幕などの符号化されたデータをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。
作成された多重化データは、最終的にはディスク製造用のカッティングマスタとしてハードディスク内に格納される。
【0099】
また、オーサリングスタジオでは、図2のステップF108として述べたように、カッティングマスタの一部であるUDFイメージデータを市販のBurnツールなどでBD−Rに記録する。そしてステップF109で、実際に工場でマスタリングするBD−ROMと同じような挙動を行うか、任意のプレーヤーで動作確認を行う。
このBD−Rに書込を行うプロセスに、従来はいくつかの課題があった。
【0100】
まず、UDFイメージデータのサイズは大きいもので、一旦ハードディスクに出力するだけでも、時間がかかってしまう。
これに対しては上述してきたように、大容量のデータを加工したファイルを生成せず、PC上のファイルを直接リードしながら、あるいはエンコードした素材を直接リードしながら仮想クリップ10、仮想UDFイメージ20を生成するプロセスを行うことで解決できる。
BD−Rに記録する際は、仮想UDFイメージ20に基づいて再生されるデータをデコードすることでデータ書込の際の前処理時間を短縮することができる。
【0101】
もう1つの課題として、BD−RとBD−ROMの配置が同じになる保証がないということがある。
例えば2層BD−Rの記録を行うときは、図23(a)に示すように、1層目を全て書き込んでから、2層目に折り返すことになっている。図23(a)において示すように、1層目(レイヤL0)の書込は、ディスク内周側から外周側に進行し、外周側において設定されているアンユースドスペースまで達した時点で、レイヤーブレイクLBを行って2層目(レイヤL1)に折り返す。
【0102】
一方、最終製品としてのBD−ROMに関しては、例えばコンテンツ内容などに応じて、レイヤーブレイクLBのポイントが設定される。BD−ROM製造段階で1層目に書き込むサイズを任意に指定できるためである。例えば図23(b)のようにA点がレイヤーブレイクLBのポイントとして設定される。これによって図の斜線部のようにデータ記録が行われた状態となる。
すると、通常にBD−R書込を行ってしまうと、図23(a)(b)から分かるように、同じ内容であっても、BD−RはBD−ROMとは異なる状態で各レイヤに記録が行われてしまう。
【0103】
図2のステップF108、F109のBD−R書込及び再生確認は、BD−Rを通常のプレーヤで再生することで、最終製品としてのBD−ROMの挙動を確認するために行うものである。
プレーヤーの再生確認は、データの配置によってシーク時間やレイヤー(層)ジャンプなどのアクセスタイムを考慮して評価を行わなければならないのだが、それができなくなる。たとえば、レイヤ間をまたぐシーク時間は、BDドライブの性能上、同じレイヤでのシーク時間よりも大きくなる。しかし、BD−RとBD−ROMでレイヤーブレイクLBのポイントが異なることとなると、このような点を考慮した再生確認ができないこととなる。
【0104】
そこで本例では、仮想UDFイメージに基づくBD−R書込において、BD−ROMと同じ配置でBD−R書込ができるようにする。例えば図23(c)のように書込を行う。
BD−R書込においては、レイヤ0からレイヤ1へのレイヤーブレイクLBのポイントは、アンユースドスペースに達した位置である。そこで、図23(c)のように、ダミデータDMを配置し、コンテンツファイル内容から見たレイヤブレイクポイントがBD−ROMの場合と同じ箇所となるようにする。
なお、最終製品となるBD−ROMについても、同様にダミーデータを配置し、図23(c)と同様の配置となるようにするものである。つまり、例えば図23(b)のようにBD−ROMのレイヤーブレイクLBのポイントがコンテンツ内容等から決められる場合、BD−Rでは、アンユースドスペースに達した位置とされるレイヤーブレイクLBのポイントが、そのBD−ROMの内容的な位置としてのレイヤーブレイクLBのポイントと一致するようにする。その上で、最終製品のBD−ROMは、図23(c)と同様にダミーデータを付加した配置を行う。結局、図23(c)のBD−Rは、BD−ROMと同一の配置とされ、再生確認を適切なものとできる。
【0105】
このようなBD−R書込を実現するために、本例では、例えばマルチプレクサモジュールが図24の処理を行う。
ステップF401でパラメータ入力処理を行う。ここでは、ダミーファイルの最大サイズ、アンユース度スペースの最大サイズ、ディスク片面(1つの記録層)の最大サイズ、クリップのインターリーブ用情報等の入力を受け付ける。
【0106】
ステップF402では、BD−R書込を行おうとする仮想UDFイメージ20についてのディレクトリパスを取得する。
ステップF403では、入力されたパラメータから、UDFイメージの配置を決定する。この場合、2層ディスクが対象の場合は、ユーザが指定した位置でレイヤブレイクが行われるようにする。またダミーファイルやアンユースドスペースのサイズと配置を決定する。
この際、クリップのインターリーブをBDのジャンプモデルを考慮して決定する。BD等の光ディスクでは、シークやレイヤージャンプなどの再生時のオーバーヘッドを考慮したクリップを、UDFイメージ上で配置する必要があるためである。
なおインターリーブは、マルチアングルなどのタイトルで主に使用される。BDやDVDでは、マルチアングル、マルチストリーを編集されることが多く、その場合インターリーブは必須の機能になる。マルチアングルとは、同一時間内に進行する映像を異なるカメラアングルからアングルを記録し、プレイヤーの操作によりユーザーが任意に選択できる機能である。マルチストーリーとはユーザーがメニューで選択したり製作者が分岐先等を指定することにより、見る人の選択によってストーリー展開を自由に選べる機能である。
【0107】
以上の処理で、図23(c)のような書込のためのUDFイメージの配置が決定される。そこでステップF404で、仮想UDFイメージ20の仮想クリップ参照テーブル21(エクステント情報)を元に、BD−R書込のためのストリーム再生を行い、BD−R書込プログラムに受け渡して、BD−Rに対する書込を実行する。
【0108】
即ち本例の場合、仮想UDFイメージ20を再生してBD−R書込ストリームを形成する際に、ダミーファイルサイズ等の入力パラメータを反映された書き込み用ストリームが形成されるようにする。これにより、入力パラメータに応じて図23のように書込が行われ、結果として、BD−ROMと同じ位置(コンテンツ内容から見ての同じ位置)でレイヤーブレイクが行われるようにできるなど、確認用として適切なBD−R記録を行うことができる。
従来は、記録用のイメージファイルを生成してから、そのイメージファイルをBD−Rに書き込むか、或いはディレクトリ指定して、その指定されたディレクトリのファイルを書き込むことが行われていた。BD−R記録用のイメージファイルを生成することは、工程の効率を悪化させる。またディレクトリ指定で行う場合は、BD−R上での物理的な位置を規定できない。
これに対して本例では、仮想UDFイメージ20の再生において、ダミーファイルサイズ、アンユースドスペースのサイズ、1層最大サイズ、インターリーブ用情報等が反映されるようにする。このため、上記のように物理的な位置を任意に設定でき、かつ予めBD−R書込用のイメージファイルを別に作成するという必要もなくなる。
【0109】
[9.実施の形態の効果及び変形例]
以上説明してきたように、本実施の形態では、オーサリング工程におけるマルチプレクサ処理が、仮想クリップ10、仮想UDFイメージ20による処理とすることで著しく時短化できる。例えば、従来と同等のサイズのストリームファイルやUDFイメージファイルを生成する場合で比較して、約7倍の高速化(工程時間が1/7への時間短縮)を実現できた。これによって、効率のよいオーサリング工程を実現できる。
【0110】
なお実施の形態の変形例として以下のようなものが想定される。
仮想クリップ10、仮想UDFイメージ20等の仮想データを専用のソフトウェアで再生することもできる。即ちオーサリング工程とは独立して再生を行う再生モジュールを形成してもよい。市販の再生用ソフトウェアなどは利用できないが、例えば仮想ファイルシステムによるデータの再構成に所要するオーバーヘッドを考慮した場合に想定される。
【0111】
またマルチプレクサでは、アプリケーションフォーマットに準拠したプレゼンテーションデータに変換加工するが、メニュー画面のナビゲーション等はSTD(System Target Decoder)のバッファ管理を考慮しないで、オーサリング時に再生確認を行いたいことが多い。この再生システムをシミュレータと一般に呼ぶ。このシミュレータも、マルチプレクサと同様に素材を直接読み出すことで再生することが可能である。この場合、素材の置き換えを行うと、短時間で再生確認を行うことができる。
【0112】
またMPEG2トランスポートフォームのほかに、MPEG2プログラムストリームなど同様のマルチプレクサシステムにおいて、仮想ファイルシステムによる高速化を行うことができる。
また素材の参照テーブルファイル(ES参照テーブル)のフォーマットは各種変形可能である。再生可能であればサイズが小さい方がマルチプレクサの再生時間は高速になる。
【0113】
また、オーサリング工程を並列に行う並列処理を組み合わせることによって、さらなる高速化が可能となる。
また従来マルチプレクサ処理、つまり実データとしてのクリップファイル等を作成するシステムと併用できるシステムとしても実現可能である。即ちユーザ指示により、仮想化処理をするか否かを選択可能とするものである。
【符号の説明】
【0114】
1 仮想クリップ生成部、2 メタデータ生成部、3 仮想UDFイメージ/カッティングマスタ生成部、10 仮想クリップ、11 ES参照テーブル、20 仮想UDFイメージ、21 仮想クリップ参照テーブル
【特許請求の範囲】
【請求項1】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程と、
を有するオーサリング方法。
【請求項2】
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する請求項1に記載のオーサリング方法。
【請求項3】
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する請求項2に記載のオーサリング方法。
【請求項4】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程と、
を情報処理装置に実行させるプログラム。
【請求項5】
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する請求項4に記載のプログラム。
【請求項6】
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する請求項5に記載のプログラム。
【請求項7】
上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材IDを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材IDについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする請求項4に記載のプログラム。
【請求項8】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、
編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段と、
を有する編集データ再生装置。
【請求項1】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程と、
を有するオーサリング方法。
【請求項2】
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する請求項1に記載のオーサリング方法。
【請求項3】
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する請求項2に記載のオーサリング方法。
【請求項4】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程と、
を情報処理装置に実行させるプログラム。
【請求項5】
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込/再生工程を有する請求項4に記載のプログラム。
【請求項6】
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有する請求項5に記載のプログラム。
【請求項7】
上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材IDを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材IDについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする請求項4に記載のプログラム。
【請求項8】
素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、
編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段と、
を有する編集データ再生装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【公開番号】特開2010−218589(P2010−218589A)
【公開日】平成22年9月30日(2010.9.30)
【国際特許分類】
【出願番号】特願2009−60397(P2009−60397)
【出願日】平成21年3月13日(2009.3.13)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成22年9月30日(2010.9.30)
【国際特許分類】
【出願日】平成21年3月13日(2009.3.13)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]