以下、この発明の実施の一形態を、図面を参照しながら説明する。先ず、理解を容易とするために、この発明に適用可能な一例のフォーマット(以下、AVCHDフォーマットと呼ぶ)について説明する。AVCHDフォーマットは、ビデオデータとオーディオデータとが所定に多重化されたAV(Audio/Video)ストリームを記録可能な記録媒体に記録する記録フォーマットとして現在提案されているもので、記録媒体に記録されたAVストリームを、クリップ単位でプレイリストを用いて管理可能としている。
例えばITU−T(International Telecommunication Union-Telecommunication Standarization Sector)勧告H.264あるいはISO(International Organization for Standarization)/IEC(International Electrotechnical Commission)国際標準14496−10(MPEG−4パート10)Advanced Video Coding(以下、H.264|AVCと略称する)に規定される符号化方式で符号化され、MPEG2システムズに従い多重化されたビットストリームは、クリップAVストリーム(またはAVストリーム)と称される。クリップAVストリームは、所定のファイルシステムによりファイルとしてディスクに記録される。このファイルを、クリップAVストリームファイル(またはAVストリームファイル)と称する。
クリップAVストリームファイルは、ファイルシステム上での管理単位であり、ユーザにとって必ずしも分かりやすい管理単位であるとは限らない。ユーザの利便性を考えた場合、複数のクリップAVストリームファイルに分割された映像コンテンツを一つにまとめて再生する仕組みや、クリップAVストリームファイルの一部だけを再生する仕組み、さらには、特殊再生や頭出し再生を滑らかに行うための情報などをデータベースとしてディスクに記録しておく必要がある。
図1は、この発明に適用可能なAVCHDフォーマットに規定されるデータモデルを概略的に示す。このAVCHDフォーマットによれば、データ構造は、図1に示されるように4層のレイヤよりなる。最も最下層のレイヤは、クリップAVストリームが配置されるレイヤである(便宜上、クリップレイヤと呼ぶ)。その上のレイヤは、クリップAVストリームに対する再生箇所を指定するための、プレイリスト(PlayList)と、プレイアイテム(PlayItem)とが配置されるレイヤである(便宜上、プレイリストレイヤと呼ぶ)。さらにその上のレイヤは、プレイリストに対して再生順などを指定するコマンドからなるムービーオブジェクト(Movie Object)などが配置されるレイヤである(便宜上、オブジェクトレイヤと呼ぶ)。最上層のレイヤは、記録媒体に格納されるタイトルなどを管理するインデックステーブルが配置される(便宜上、インデックスレイヤと呼ぶ)。
クリップレイヤについて説明する。クリップAVストリームは、ビデオデータやオーディオデータがMPEG2 TS(トランスポートストリーム)の形式などに多重化されたビットストリームである。このクリップAVストリームに関する情報がクリップ情報(Clip Information)としてファイルに記録される。
また、クリップAVストリームには、字幕を表示するグラフィクスストリームであるOBストリーム(Overlay Bitmap stream)や、メニュー表示などに用いられるデータ(ボタン画像データなど)をストリームにしたMBストリーム(Menu Bitmap stream)を多重化することができる。
クリップAVストリームファイルと、対応するクリップ情報が記録されたクリップ情報ファイルとをひとまとまりのオブジェクトと見なし、クリップ(Clip)と称する。すなわち、クリップは、クリップAVストリームとクリップ情報とから構成される、一つのオブジェクトである。
ファイルは、一般的に、バイト列として扱われる。クリップAVストリームファイルのコンテンツは、時間軸上に展開され、クリップ中のエントリーポイントは、主に時間ベースで指定される。所定のクリップへのアクセスポイントのタイムスタンプが与えられた場合、クリップAVストリームファイルの中でデータの読み出しを開始すべきアドレス情報を見つけるために、クリップ情報ファイルを用いることができる。
プレイリストレイヤについて説明する。プレイリストは、再生するAVストリームファイルの指定と、指定されたAVストリームファイルの再生箇所を指定する再生開始点(IN点)と再生終了点(OUT点)の集まりとから構成される。この再生開始点と再生終了点の情報を一組としたものは、プレイアイテム(PlayItem)と称される。プレイリストは、プレイアイテムの集合で構成される。プレイアイテムを再生するということは、そのプレイアイテムに参照されるAVストリームファイルの一部分を再生するということになる。すなわち、プレイアイテム中のIN点およびOUT点情報に基づき、クリップ中の対応する区間が再生される。
オブジェクトレイヤについて説明する。ムービーオブジェクトは、ナビゲーションコマンドプログラムと、ムービーオブジェクトとを連携するターミナルインフォメーションを含む。ナビゲーションプログラムは、プレイリストの再生を制御するためのコマンド(ナビゲーションコマンド:navigation command)である。
インデックスレイヤについて説明する。インデックスレイヤは、インデックステーブル(Index Table)からなる。インデックステーブルは、記録媒体に記録されたコンテンツのタイトルを定義する、トップレベルのテーブルである。インデックステーブルに格納されているタイトル情報に基づき、プレーヤに常駐されるシステムソフトウェア中のモジュールマネージャにより記録媒体の再生が制御される。
すなわち、図2に概略的に示されるように、インデックステーブル中の任意のエントリは、タイトルと称され、インデックステーブルにエントリされるファーストプレイバックタイトル(First PlaybackTitle)、メニュータイトル(MenuTitle)およびムービータイトル(MovieTitle)#1、#2、・・・は、全てタイトルである。各タイトルは、ムービーオブジェクトに対するリンクを示す。
理解を容易とするため再生専用の記録媒体を例にとると、例えば、ファーストプレイバックタイトルは、当該記録媒体に格納されるコンテンツが映画であれば、映画本編に先立って映出される映画会社の宣伝用映像(トレーラ)に対応する。メニュータイトルは、例えばコンテンツが映画である場合、本編再生、チャプタサーチ、字幕や言語設定、特典映像再生などを選択するためのメニュー画面に対応する。また、ムービータイトルは、メニュータイトルから選択される各映像である。タイトルがさらにメニュー画面であるような構成も可能である。
図3は、上述のようなクリップAVストリーム、クリップ情報(Stream Attributes)、クリップ、プレイアイテムおよびプレイリストの関係を示すUML(Unified Modeling Language)図である。プレイリストは、1または複数のプレイアイテムに対応付けられ、プレイアイテムは、1のクリップに対応付けられる。1のクリップに対して、それぞれ開始点および/または終了点が異なる複数のプレイアイテムを対応付けることができる。1のクリップから1のクリップAVストリームファイルが参照される。同様に、1のクリップから1のクリップ情報ファイルが参照される。また、クリップAVストリームファイルとクリップ情報ファイルとは、1対1の対応関係を有する。このような構造を定義することにより、クリップAVストリームファイルを変更することなく、任意の部分だけを再生する、非破壊の再生順序指定を行うことが可能となる。
また、図4のように、複数のプレイリストから同一のクリップを参照することもできる。また、1のプレイリストから複数のクリップを指定することもできる。クリップは、プレイリスト中のプレイアイテムに示されるIN点およびOUT点により、参照される。図4の例では、クリップ300は、プレイリスト310のプレイアイテム320から参照されると共に、プレイリスト311を構成するプレイアイテム321および322のうちプレイアイテム321から、IN点およびOUT点で示される区間が参照される。また、クリップ301は、プレイリスト311のプレイアイテム322からIN点およびOUT点で示される区間が参照されると共に、プレイリスト312のプレイアイテム323および324のうち、プレイアイテム323のIN点およびOUT点で示される区間が参照される。図4の例では、クリップ301は、さらに別のプレイリストからも参照されている。
次に、AVCHDフォーマットによる、記録媒体に記録されるファイルの管理構造について、図5を用いて説明する。ファイルは、ディレクトリ構造により階層的に管理される。記録媒体上には、先ず、1つのディレクトリ(図5の例ではルート(root)ディレクトリ)が作成される。このディレクトリの下が、1つの記録再生システムで管理される範囲とする。
ルートディレクトリの下に、ディレクトリ"BDMV"が置かれる。さらに必要に応じて、ルートディレクトリの下にディレクトリ"AVCHDTN"がおかれる。ディレクトリ"AVCHDTN"には、例えばクリップの代表画像を所定サイズに縮小したサムネイルファイルが置かれる。ディレクトリ"BDMV"に、図1を用いて説明したデータ構造が格納される。
ディレクトリ"BDMV"の直下には、ファイルは、ファイル"index.bdmv"およびファイル"MovieObject.bdmv"の2つのみを置くことができる。また、ディレクトリ"BDMV"の下に、ディレクトリ"PLAYLIST"、ディレクトリ"CLIPINF"、ディレクトリ"STREAM"およびディレクトリ"BACKUP"が置かれる。ディレクトリ"BACKUP"は、各ディレクトリおよびファイルのバックアップが格納される。
ファイル"index.bdmv"は、ディレクトリBDMVの内容について記述される。すなわち、このファイル"index.bdmv"が上述した最上層のレイヤであるインデックスレイヤにおけるインデックステーブルに対応する。また、ファイルMovieObject.bdmvは、1つ以上のムービーオブジェクトの情報が格納される。すなわち、このファイル"MovieObject.bdmv"が上述したオブジェクトレイヤに対応する。
ディレクトリ"PLAYLIST"は、プレイリストのデータベースが置かれるディレクトリである。すなわち、ディレクトリ"PLAYLIST"は、プレイリストに関するファイルであるファイル"xxxxx.mpls"を含む。ファイル"xxxxx.mpls"は、プレイリストのそれぞれに対して作成されるファイルである。ファイル名において、"."(ピリオド)の前の"xxxxx"は、5桁の数字とされ、ピリオドの後ろの"mpls"は、このタイプのファイルに固定的とされた拡張子である。
ディレクトリ"CLIPINF"は、クリップのデータベースが置かれるディレクトリである。すなわち、ディレクトリCLIPINF"は、クリップAVストリームファイルのそれぞれに対するクリップインフォメーションファイルであるファイル"zzzzz.clpi"を含む。ファイル名において、"."(ピリオド)の前の"zzzzz"は、5桁の数字とされ、ピリオドの後ろの"clpi"は、このタイプのファイルに固定的とされた拡張子である。
ディレクトリ"STREAM"は、実体としてのAVストリームファイルが置かれるディレクトリである。すなわち、ディレクトリ"STREAM"は、クリップインフォメーションファイルのそれぞれに対応するクリップAVストリームファイルを含む。クリップAVストリームファイルは、MPEG2(Moving Pictures Experts Group 2)のトランスポートストリーム(以下、MPEG2 TSと略称する)からなり、ファイル名が"zzzzz.m2ts"とされる。ファイル名において、ピリオドの前の"zzzzz"は、対応するクリップインフォメーションファイルと同一することで、クリップインフォメーションファイルとこのクリップAVストリームファイルとの対応関係を容易に把握することができる。
なお、ディレクトリ"AVCHDTN"は、2種類のサムネイルファイルthumbnail.tidxおよびthumbnail.tdt2を置くことができる。サムネイルファイルthumbnail.tidxは、所定の方式で暗号化されたサムネイル画像が格納される。サムネイルファイルthumbnail.tdt2は、暗号化されていないサムネイル画像が格納される。例えばビデオカメラでユーザが撮影したクリップに対応するサムネイル画像は、コピーフリーであって暗号化する必要が無いと考えられるため、このサムネイルファイルthumbnail.tdt2に格納される。
図5で示した各ファイルのうち、この発明に関わりの深いものについて、より詳細に説明する。先ず、ディレクトリ"BDMV"の直下に置かれるファイル"index.bdmv"について説明する。図6は、このファイル"index.bdmv"の一例の構造を表すシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるC言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
図6において、フィールドTypeIndicatorは、32ビットのデータ長を有し、このファイルがインデックステーブルであることを示す。フィールドTypeIndicator2は、32ビットのデータ長を有し、このファイル"index.bdmv"のバージョンを示す。フィールドIndexesStartAddressは、32ビットのデータ長を有し、このシンタクス内にあるブロックblkIndexes()の開始アドレスを示す。
フィールドExtensionDataStartAddressは、32ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。フィールドExtensionDataStartAddressは、このファイル"index.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"0"から開始される。若し、このフィールドExtensionDataStartAddressの値が"0"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
フィールドExtensionDataStartAddressに続けて、データ長が192バイトの領域reservedが配される。なお、領域reservedは、バイトアライメントや、将来的なフィールドの追加などのための領域である。これは、以下の説明においても同様である。ブロックblkAppInfoBDMV()は、コンテンツ制作者が任意の情報を記述できるブロックであって、プレーヤの動作などには影響を与えない。
ブロックblkIndexes()は、このファイル"index.bdmv"の実質的な内容であって、このファイル"index.bdmv"に記述された内容により、ディスクをプレーヤに装填した際に再生されるファーストプレイバックや、トップメニューから呼び出されるタイトル(ムービーオブジェクト)が指定される。インデックステーブルにより呼び出されたムービーオブジェクト等に記述されたコマンドに基づき、後述するプレイリストファイルが読み込まれる。
図7は、ブロックblkIndexes()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLength直後からこのブロックblkIndexes()の終わりまでのデータ長を示す。続けて、ブロックFirstPlaybackTitle()およびブロックMenuTitle()が配される。
ブロックFirstPlaybackTitle()は、ファーストプレイバックで用いられるオブジェクトに関する情報が記述される。ブロックFirstPlaybackTitle()は、1ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに31ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、14ビットのデータ長を有する領域reservedを介して、16ビットのデータ長を有するフィールドFirstPlaybackTitleMobjIDRefが配される。このフィールドFirstPlaybackTitleMobjIDRefにより、ファーストプレイバックタイトルで用いられるムービーオブジェクトのIDを示す。
ムービーオブジェクトのIDは、例えば、図8および図9を用いて後述するムービーオブジェクトのシンタクスに基づき、ムービーオブジェクトのforループ文においてループ変数として用いられる値mobj_idで示される。この例では、フィールドFirstPlaybackTitleMobjIDRefは、参照するムービーオブジェクトに対応する値mobj_idが格納される。
なお、ブロックblkIndexes()におけるブロックFirstPlaybackTitle()内のフィールドFirstPlaybackTitleMobjIDRefは、トップメニューのムービーオブジェクトを指していてもよいし、タイトルを指していてもよい。
ブロックMenuTitle()は、トップメニューで用いられるオブジェクトに関する情報が記述される。ブロックMenuTitle()は、1ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに31ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、14ビットのデータ長を有する領域reservedを介して、16ビットのデータ長を有するフィールドMenuTitleMobjIDRefが配される。フィールドMenuTitleMobjIDRefは、メニュータイトルで用いられるムービーオブジェクトのIDを示す。
ブロックMenuTitle()の次のフィールドNumberOfTitlesは、16ビットのデータ長を有し、ユーザが選択、再生可能なタイトルの数を示す。次のforループ文に従い、このフィールドNumberOfTitlesに示される回数だけ、値title_idを引数として、ブロックMovieTitle[title_id]()が記述される。ブロックMovieTitle[title_id]()は、タイトル毎の情報が記述される。値title_idは、"0"からフィールドNumberOfTitlesで示される値までの数値であり、タイトルを識別する。
ブロックMovieTitle[title_id]()において、1ビットのデータ長を有する領域reservedを介して固定値"1"が記述され、さらに、46ビットのデータ長を有する領域reservedを介してフィールドMovieTitleMobjIDRefが記述される。フィールドMovieTitleMobjIDRefは、16ビットのデータ長を有し、このタイトルで用いられるムービーオブジェクトのIDを示す。フィールドMovieTitleMobjIDRefの後ろに、32ビットのデータ長を有する領域reservedが配される。
図8は、ディレクトリ"BDMV"の直下に置かれるファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、32ビット(4バイト)のデータ長を有し、このファイルがファイル"MovieObject.bdmv"であることを示す。フィールドTypeIndicatorは、ISO(International Organization for Standarization)646に規定された符号化方式で符号化した4文字からなる文字列が記述される。この図8の例では、フィールドTypeIndicatorにISO646に既定の方式で符号化された4文字の文字列"MOBJ"が記述され、このファイルがファイル"MovieObject.bdmv"であることが示される。
フィールドTypeIndicator2は、32ビット(4バイト)のデータ長を有し、このファイル"MovieObject.bdmv"のバージョン番号を示す。このファイル"MovieObject.bdmv"では、フィールドTypeIndicator2は、ISO646に規定された符号化方式で符号化した4文字の文字列"0100"でなければならない。
フィールドExtensionDataStartAddressは、32ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、このファイル"MovieObject.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"0"から開始される。若し、このフィールドExtensionDataStartAddressの値が"0"であれば、このファイル"MovieObject.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
なお、この図8に示すシンタクス内のフィールドpadding_wordは、16ビットのデータ長を有し、このファイル"MovieObject.bdmv"のシンタクスに従いforループ文に値N1または値N2で示される回数だけ挿入される。値N1または値N2は、"0"または任意の正の整数である。また、フィールドpadding_wordは、任意の値を用いることができる。
フィールドExtensionDataStartAddressに続けてデータ長が224ビットの領域reservedが配され、その次に、このファイル"MovieObject.bdmv"の本体であるブロックblkMovieObjects()が格納される。
図9は、ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からこのブロックblkMovieObjects()の終わりまでのデータ長を示す。32ビットのデータ長を有する領域reservedを介してフィールドNumberOfMobjsが配される。フィールドNumberOfMobjsは、直後のforループ文に従い格納されるムービーオブジェクトの数を示す。forループ文のループ変数として用いられる値mobj_idで、ムービーオブジェクトが一意に特定される。値mobj_idは、"0"から始まる値で、ムービーオブジェクトは、forループ文中に記述される順序により定義される。
forループ文中のブロックTerminalInfo()は、固定値"1"が記述され、次に15ビットのデータ長を有する領域reservedが配される。その次に、16ビットのデータ長を有するフィールドNumberOfNavigationCommands[mobj_id]が配される。このフィールドNumberOfNavigationCommands[mobj_id]は、値mobj_idによって指し示されるムービーオブジェクトMovieObject[mobj_id]()に含まれるナビゲーションコマンド(NavigationCommand)の数を表す。
次の、値command_idをループ変数とするforループ文により、フィールドNumberOfNavigationCommands[mobj_id]に示される数だけ、ナビゲーションコマンドが記述される。すなわち、このforループ文中に配されるフィールドNavigationCommand[mobj_id][command_id]は、値mobj_idによって指し示されるブロックMovieObject[mobj_id]()に含まれる、値command_idで示される順番のナビゲーションコマンドNavigationCommandを格納する。値command_idは、0から始まる値で、ナビゲーションコマンドNavigationCommandは、このforループ文中に記述される順序で定義される。
図10は、プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、32ビット(4バイト)のデータ長を有し、このファイルがプレイリストファイルであることを示す。フィールドTypeIndicator2は、32ビット(4バイト)のデータ長を有し、このプレイリストファイルのバージョンを示す。フィールドPlayListStartAddressは、32ビットのデータ長を有し、このシンタクス中のブロックblkPlayList()の開始アドレスを示す。
フィールドPlayListMarkStartAddressは、32ビットのデータ長を有し、このシンタクス中のブロックblkPlayListMark()の開始アドレスを示す。フィールドExtensionDataStartAddressは、32ビットのデータ長を有し、このシンタクス中のブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、ブロックblkExtensionData()の開始アドレスを、ファイル"xxxxx.mpls"の最初のバイトからの相対バイト数を表した値である。相対バイト数は、"0"から開始される。若し、このフィールドExtensionDataStartAddressの値が"0"であれば、このファイル"xxxxx.mpls"内に、ブロックblkExtensionData()が存在しないことを示す。
160ビットのデータ長を有する領域reservedを介してブロックblkAppInfoPlayList()が配される。ブロックblkAppInfoPlayList()は、次のブロックblkPlayList()に記述されるプレイリストのタイプ、再生制限などの情報が記述される。ブロックblkPlayList()は、プレイリストが記述される。ブロックblkPlayListMark()は、チャプタジャンプなどでジャンプされるポイントが記述される。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。
図11は、ブロックblkPlayList()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayList()の最後までのデータ長を示す。フィールドLengthに続けて16ビットのデータ長を有する領域reservedが配され、次にフィールドNumberOfPlayItemsが配される。フィールドNumberOfPlayItemsは、16ビットのデータ長を有し、このブロックblkPlayList()に含まれるプレイアイテムの数を示す。フィールドNumberOfSubPathは、このブロックblkPlayList()に含まれるサブパスの数を示す。
次のforループ文に従い、フィールドNumberOfPlayItemsで示される数だけ、プレイアイテムが記述されるブロックblkPlayItem()が記述される。forループ文に基づくカウント数がブロックblkPlayItem()の識別子PlayItem_idとなる。さらに次のforループ文に従い、フィールドNumberOfSubPathで示される数だけ、ブロックblkSubPath()が記述される。forループ文に基づくカウント数がブロックblkSubPath()の識別子SubPath_idとなる。
なお、サブパスは、主として再生されるプレイアイテムに対応するメインパスに対して、サブプレイアイテムに対応して持つことができる。サブパスは、例えば、アフレコ用のオーディオデータの指定や、2枚の映像を合成する際に、プレイアイテムで指定されるクリップと同期して再生する副映像を指定するといった目的で用いられる。
図12は、ブロックblkPlayItem()の一例の構造を表すシンタクスを示す。フィールドLengthは、16ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayItem()の最後までのデータ長を示す。
フィールドClipInformationFileNameは、40ビット(5バイト)のデータ長を有し、このブロックblkPlayItem()が参照するクリップインフォメーションファイルのファイル名が示される。このプレイアイテムにおいて、フィールドClipInformationFileNameで示されるファイル名のクリップインフォメーションファイルが読み出される。フィールドClipCodecIdentifierは、32ビット(4バイト)のデータ長を有し、このブロックblkPlayItem()によるプレイアイテムにおいて用いられるクリップAVストリームのコーデック方式を示す。
12ビットのデータ長を有する領域reservedを介して、フィールドConnectionConditionが配される。フィールドConnectionConditionは、4ビットのデータ長を有し、クリップ間の接続状態に関する情報を示す。記録用途の記録媒体に対しては、フィールドConnectionConditionの値として"1"、"5"または"6"が用いられる。フィールドConnectionConditionの値が"1"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続しないことを示し、フィールドConnectionConditionの値が"5"または"6"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続することを示す。なお、シームレス接続とは、クリップと次のクリップとがフレームタイミングで連続的に再生されるように、クリップ間の再生制御を行うことをいう。
フィールドConnectionConditionの値が"5"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して長くされる(図13A参照)。これにより、クリップとクリップとを接続する際に、オーディオデータのフェイドアウト処理が可能とされる。例えば、ユーザによる記録停止操作によりクリップがクローズされる場合に、フィールドConnectionConditionの値が"5"とされる。以下、このフィールドConnectionConditionの値が"5"で示されるクリップの接続方法を、第1のシームレス接続と呼ぶ。
フィールドConnectionConditionの値が"6"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して同じにされる(図13B参照)。これにより、クリップとクリップとの接続をシームレスに行うことが可能とされる。例えば、ユーザ操作に応じた記録停止以外の理由、例えばシステム要因に基づきクリップがクローズされる場合に、フィールドConnectionConditionの値が"6"とされる。以下、このフィールドConnectionConditionの値が"6"で示されるクリップの接続方法を、第2のシームレス接続と呼ぶ。
フィールドRefToSTCIDは、8ビットのデータ長を有し、システムタイムベース(STC)の不連続点に関する情報を示す。フィールドINTimeおよびフィールドOUTTimeは、それぞれ32ビットのデータ長を有し、メインクリップAVストリームの再生範囲を示す。フィールドINTimeが開始点(IN点)を示し、フィールドOUTTimeが終了点(OUT点)を示す。
ブロックblkUOMaskTable()は、ユーザ入力の受付制限が設定されるテーブルである。1ビットのデータ長を有するフラグPlayItemRandomAccessFlagは、このブロックblkPlayItem()によるプレイアイテムに対してランダムアクセスを許可するか否かを規定する。続けて、7ビットのデータ長を有する領域reservedを介してフィールドStillModeが配される。フィールドStillModeは、8ビットのデータ長を有し、ブロックblkPlayItem()によるプレイアイテムにおいて、最後に表示した映像を静止画として表示させるか否かを示す。フィールドStillModeの値が"0x01"(バイナリ)であれば、if文に基づき、16ビットのデータ長を有するフィールドStillTimeにより静止時間が示される。フィールドStillModeの値が"0x01"以外であれば、当該16ビットのデータ長を有する領域が領域reservedとされる。
なお、数値の記述において"0x"は、その数値が16進表記されていることを示す。これは、以下の同様な表記について共通である。
ブロックblkSTNTable()は、このブロックblkPlayItem()によるプレイアイテムが管理しているクリップAVストリームの属性、PID番号、記録媒体上での記録位置などが管理される。
図14は、ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayListMark()の最後までのデータ長を示す。
フィールドNumberOfPlayListMarksは、16ビットのデータ長を有し、このブロックblkPlayListMark()に含まれるプレイリストマークの数を示す。次のforループ文に従い、フィールドNumberOfPlayListMarksで示される数だけプレイリストマークの情報が記述される。
forループ文内において、8ビットのデータ長を有する領域reserveに続けてフィールドMarkTypeが配される。フィールドMarkTypeは、8ビットのデータ長を有し、マークのタイプを示す。プレイリストマークには、エントリマーク(Entry Mark)およびリンクポイント(Link Point)の2タイプが定義されており、このフィールドMarkTypeにより、何れのタイプであるかが示される。チャプタを定義するためには、エントリマークを用いる。リンクポイントは、この発明と関連性が薄いので、説明を省略する。上述したフィールドNumberOfPlayListMarksは、エントリマークおよびリンクポイントを合計した値を示す。
フィールドRefToPlayItemIDは、16ビットのデータ長を有し、マークが打たれるプレイアイテムを参照する識別情報PlayItem_idが記述される。フィールドMarkTimeStampは、32ビットのデータ長を有し、マークが打たれるポイントを示すタイムスタンプが記述される。フィールドEntryESPIDは、16ビットのデータ長を有し、マークによって指し示されるエレメンタリストリームを含んでいるTSパケットのPIDの値を示す。フィールドDurationは、45kHzのクロックを単位とした計測による、32ビットのデータ長を有する符号無し整数である。このフィールドDurationに格納される値が"0"であれば、このフィールドDurationは、意味を成さない。
図15は、クリップインフォメーションファイルの一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、32ビット(4バイト)のデータ長を有し、このファイルがクリップインフォメーションファイルであることを示す。フィールドTypeIndicator2は、32ビット(4バイト)のデータ長を有し、このクリップインフォメーションファイルのバージョンを示す。
このクリップインフォメーションファイルは、ブロックblkClipInfo()、ブロックblkSequenceInfo()、ブロックblkProgramInfo()、ブロックblkCPI()、ブロックblkClipMark()およびブロックblkExtensionData()を有し、それぞれ32ビットのデータ長を有するフィールドSequenceInfoStartAddress、フィールドProgramInfoStartAddress、フィールドCPIStartAddress、フィールドClipMarkStartAddressおよびフィールドExtensionDataStartAddressは、各々対応するブロックの開始アドレスを示す。
フィールドExtensionDataStartAddressは、このクリップインフォメーションファイルの最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"0"から開始される。若し、このフィールドExtensionDataStartAddressの値が"0"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
ブロックblkClipInfo()は、これらの開始アドレスを示すフィールドに続く、96ビットのデータ長を有する領域reservedの次から開始される。ブロックblkClipInfo()は、このクリップインフォメーションファイルが管理するクリップAVストリームに関する情報が記述される。ブロックblkSequenceInfo()は、STCやATC(アライバルタイムベース)が連続しているシーケンスをまとまりとして管理する情報が記述される。ブロックblkProgramInfo()は、このクリップインフォメーションファイルに管理されるクリップAVストリームの符号化方式、クリップAVストリーム中のビデオデータのアスペクト比などの情報が記述される。ブロックblkCPI()は、ランダムアクセス開始点などの、AVストリーム中の特徴的な箇所を表す特徴点情報CPIに関する情報が格納される。
また、ブロックblkClipMark()は、チャプタ位置などの、クリップに付された頭出しのためのインデックス点(ジャンプポイント)が記述される。ブロックblkExtensionData()は、拡張データを格納することができる領域である。なお、クリップインフォメーションファイル内のブロックblkClipMark()およびブロックblkSequenceInfo()は、この発明との関連性が薄いので、詳細な説明を省略する。
図16は、ブロックblkClipInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkClipInfo()の最後までのデータ長を示す。16ビットのデータ長を有する領域reservedを介して、フィールドClipStreamTypeが配される。
フィールドClipStreamTypeは、8ビットのデータ長を有し、クリップAVストリームの種別を表す。このフィールドClipStreamTypeの値は、例えば"1"に固定的とされる。フィールドApplicationTypeは、8ビットのデータ長を有し、クリップAVストリーム(拡張子が「m2ts」のファイル)がどのような多重化によって作られているかを示す。フィールドApplicationTypeの値が"1"で、対応するクリップAVストリームは、通常の動画が再生される。続けて31ビットのデータ長を有する領域reservedが配される。
データ長が1ビットのフラグIsCC5は、プレイリストにおけるブロックblkPlayItem()によって、対応するクリップと次のクリップとの接続を、上述した第1のシームレス接続、すなわちフィールドConnectionConditionの値が"5"で示される方法で行うか否かを示す。フラグIsCC5の値が"1"(バイナリ値)であれば、クリップ間の接続が第1のシームレス接続によりなされていることを示す。
フィールドTSRecordingRateは、クリップAVストリームファイルの記録レートをバイト/秒で表したものである。フィールドNumberOfSourcePacketsは、クリップAVストリームに含まれるソースパケット数を表す。1024ビットのデータ長を有する領域reservedを介してブロックTSTypeInfoBlock()が配される。ブロックTSTypeInfoBlock()は、クリップAVストリームが格納されるパケットのタイプを示す情報が格納される。このブロックTSTypeInfoBlock()は、この発明との関連性が薄いので、詳細な説明を省略する。
次のif文以下の情報は、上述のフラグIsCC5の値が"1"である場合に記述される。if文の次の8ビットのデータ長を有する領域reservedを介してフィールドFollowingClipStreamTypeが配されるフィールドFollowingClipStreamTypeは、8ビットのデータ長を有し、このクリップインフォメーションファイルに対応するクリップの次のクリップのタイプが記述される。32ビットのデータ長を有する領域reservedを介してフィールドFollowingClipInformationFileNameが配される。
フィールドFollowingClipInformationFileNameは、40ビット(5バイト)のデータ長を有し、このクリップインフォメーションファイルに対応するクリップの次のクリップに対応するクリップインフォメーションファイルのファイル名が記述される。次のフィールドClipCodecIdentifierは、32ビット(4バイト)のデータ長を有し、当該次のクリップの符号化方式を示す。この例では、フィールドClipCodecIdentifierは、ISO646に既定の方式で符号化された4文字の文字列値"M2TS"に固定的とされる。次に8ビットのデータ長を有する領域reservedが配される。
図17は、ブロックblkProgramInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkProgramInfo()の最後までのデータ長を示す。15ビットのデータ長を有する領域reservedを介して、データ長が1ビットで固定値"1"が記述される。
フィールドSPNProgramSequenceStartは、32ビットのデータ長を有し、対応するクリップAVストリームファイルにおいて、プログラムシーケンスが開始されるソースパケットの番号が記述される。フィールドProgramMapPIDは、16ビットのデータ長を有し、プログラムシーケンスに適用可能なプログラムマップセクションを含むとされているTSパケットのPIDの値を示す。フィールドNumberOfStreamsInPSは、8ビットのデータ長を有し、プログラムシーケンスに定義されるエレメンタリストリームの数を示す。フィールドNumberOfStreamsInPSに続けて、8ビットのデータ長を有する領域reservedが配される。
次のforループ文に従い、値[stream_index]をループ変数として、フィールドNumberOfStreamsInPSで示される数だけ、フィールドStreamPID[stream_index]およびブロックblkStreamCodingInfo(stream_index)の組が格納される。フィールドStreamPID[stream_index]は、プログラムシーケンスによって参照されたPMT(Program Map Table)に記述されたエレメンタリストリームに対応するPIDの値を示す。次のブロックblkStreamCodingInfo(stream_index)は、対応するフィールドStreamPID[stream_index]で示されるエレメンタリストリームの符号化方式に関する情報が記述される。
図18は、ブロックblkStreamCodingInfo(stream_index)の一例の構造を表すシンタクスを示す。フィールドLengthは、8ビットのデータ長を有し、このフィールドLengthの直後からブロックblkStreamCodingInfo(stream_index)の終わりまでのデータ長を示す。
フィールドLengthの次に、8ビットのデータ長を有するフィールドStreamCodingTypeが配される。フィールドStreamCodingTypeでは、値[stream_index]で示されるエレメンタリストリームの符号化のタイプが示される。一例として、フィールドStreamCodingTypeの値として値"0x1B"、値"0x80"、値"0x81"、値"0x90"および値"0x91"が定義され、当該ストリームの符号化タイプは、値"0x1B"でビデオストリーム、値"0x80"または値"0x81"でオーディオストリーム、値"0x90"でOBストリーム、値"0x91"でMBストリームであることがそれぞれ示される。次のif文に従い、このフィールドStreamCodingTypeの値に応じた記述がなされる。
フィールドStreamCodingTypeの値が例えば"0x1B"であって、値[stream_index]で示されるエレメンタリストリームがビデオストリームであることが示されれば、if文に従いフィールドVideoFormat、フィールドFrameRateおよびフィールドAspectRatioが記述され、2ビットのデータ長を有する領域reservedを介してさらにフラグCCFlagが記述される。フラグCCFlagの後には、17ビットのデータ長を有する領域reservedと、128ビットのデータ長を有する領域reservedが配される。
フィールドVideoFormatは、4ビットのデータ長を有し、値[stream_index]で示されるビデオデータのフォーマットを示す。図19は、フィールドVideoFormatで示されるビデオデータの一例のフォーマットを一覧で示す。図19に例示されるように、ビデオデータのフォーマットは、4ビットで表現可能な値"0"〜値"15"で識別され、値"0"および値"8"〜値"15"は、予約とされている。値"1"〜値"7"で、それぞれビデオデータのフォーマットの480i、576i、480p、1080i、720p、1080pおよび576pを示す。
なお、このビデオフォーマットの表記において、末尾の「i」および「p」は、それぞれインタレース走査およびプログレッシブ走査を示す。また、数字はライン数を示す。これらのビデオフォーマットは、ITU(International Telecommunication Union)−R BT.601−4(480iおよび576i)、ITU−R BT.1358(576p)、SMPTE(Society of Motion Picture and Television Engineers) 293M(480p)、SMPTE 274M(1080iおよび1080p)およびSMPTE 296M(720p)により標準化されたフォーマットである。
ブロックblkStreamCodingInfo(stream_index)において、フィールドFrameRateは、4ビットのデータ長を有し、値[stream_index]で示されるビデオデータのフレームレートを示す。図20は、フィールドFrameRateで示される一例のフレームレートを一覧で示す。図20に例示されるように、ビデオデータのフレームレートは、4ビットで表現可能な値"0"〜"15"で識別され、値"0"、値"5"および値"8"〜値"15"は、予約とされている。値"1"〜値"4"で、それぞれフレームレート(フィールド周波数)が(24000/1001)Hzすなわち略23.97Hz、24Hz、25Hzおよび(30000/1001)Hzすなわち略29.97Hzを示す。また、値6および値7で、それぞれフレームレートが50Hzおよび(60000/1001)Hzすなわち略59.94Hzを示す。
ブロックblkStreamCodingInfo(stream_index)において、フィールドAspectRatioは、4ビットのデータ長を有し、値[stream_index]で示されるビデオデータのアスペクト比を示す。図21は、フィールドAspectRatioで示される一例のフレームレートを一覧で示す。図21に例示されるように、ビデオデータのアスペクト比は、4ビットで表現可能な値"0"〜値"15"で識別され、値"0"および値"1"、ならびに、値"4"〜値"15"は、予約とされている。値"2"でアスペクト比が4:3を示す。値"3"でアスペクト比が16:9を示す。
ブロックblkStreamCodingInfo(stream_index)において、フィールドStreamCodingTypeの値が例えば"0x80"、"0x81"、"0x90"または"0x91"の場合も、if文における「else if」の記述に従い、それぞれの値が示す符号化タイプに応じた記述がなされる。なお、ビデオストリーム以外の符号化タイプのストリームに関する記述は、この発明と関連性が薄いので、詳細な説明を省略する
図22は、クリップインフォメーションファイルにおけるブロックblkCPI()の一例の構造を表すシンタクスを示す。MPEGストリームのような、フレーム間圧縮を行っている符号化ストリームにおいては、デコード開始可能な箇所は、GOP(Group Of Picture)の先頭など一部の箇所に限定されていることが多い。CPI(Characteristic Point Information)とは、そのデコード可能な開始点の位置の情報を集めたデータベースで、再生時刻と、ファイル内アドレスとが対応付けられたテーブルになっている。すなわち、CPIは、デコード単位の先頭位置を示す情報がテーブル化されている。
このようにデータベースを定めることで、例えば、任意の時刻から再生したい場合、再生時刻を元にCPIを参照することによって再生位置のファイル内アドレスがわかる。このアドレスは、デコード単位の先頭となっているため、プレーヤは、そこからデータを読み出してデコードし、素早く画像を表示することができる。
なお、このCPIに格納される、デコード単位の先頭位置(この例ではGOPの先頭位置)を、EP(Entry Point)エントリと称する。
図22において、フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkCPI()の最後までのデータ長を示す。次のif文に従い、フィールドLengthの値が0でなければ、12ビットのデータ長を有する領域reservedを介してフィールドCPITypeが配される。フィールドCPITypeは、4ビットのデータ長を有し、CPIの種類を示す。次のブロックblkEPMap()は、対応するクリップAVストリームファイルにおけるPTS値とバイトアドレスとの関連付けを行うテーブルが格納される。
図23は、ブロックblkEPMap()の一例の構造を表すシンタクスを示す。8ビットのデータ長を有する領域reservedを介してフィールドNumberOfStreamPIDEntriesが配される。フィールドNumberOfStreamPIDEntriesは、8ビットのデータ長を有し、ブロックblkEPMap()におけるブロックblkEPMapForOneStreamPIDのエントリ数を示す。forループ文に従い、値[k]をループ変数として、フィールドNumberOfStreamPIDEntriesに示される数だけ、エントリポイントに関する情報が記述される。
forループ文内において、フィールドStreamPID[k]は、16ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目にエントリされるブロックblkEPMapForOneStreamPID(以下、[k]番目のブロックblkEPMapForOneStreamPIDと記述する)によって参照されるエレメンタリストリームを伝送するトランスポートパケットのPIDの値を示す。
10ビットのデータ長を有する領域reservedを介してフィールドEPStreamType[k]が配される。フィールドEPStreamType[k]は、4ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDによって参照されるエレメンタリストリームのタイプを示す。フィールドNumberOfEPCoarseEntries[k]は、16ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある粗い検索用のサブテーブル(EP coarse table)のエントリ数を示す。フィールドNumberOfEPFineEntries[k]は、18ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある精密な検索用のサブテーブル(EP fine table)のエントリ数を示す。フィールドEPMapForOneStreamPIDStartAddress[k]は、32ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目のブロックblkEPMapForOneStreamPIDが始まる相対バイト位置を示す。この値は、ブロックblkEPMap()の第1バイト目からのバイト数で示される。
上述のforループ文による記述の後、16ビットの整数倍のデータ長を有するパディングワードを挟んで記述されるforループ文に従い、値[k]をループ変数として、フィールドNumberOfStreamPIDEntriesに示される数だけ、ブロックblkEPMapForOneStreamPID(EPStreamType[k], NumberOfEPCoarseEntries[k], NumberOfEPFineEntries[k])が格納される。すなわち、引数NumberOfEPCoarseEntries[k]は、サブテーブル(EP coarse table)に格納されるエントリPTSEPCoarseおよびエントリSPNEPCoarseの数を示す。同様に、引数NumberOfEPFineEntries[k]は、サブテーブル(EP fine table)に格納されるエントリPTSEPFineおよびエントリSPNEPFineの数を示す。以下では、引数NumberOfEPCoarseEntries[k]および引数NumberOfEPFineEntries[k]を、それぞれ適宜、エントリ数Ncおよびエントリ数Nfと呼ぶ。
図24は、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の一例の構造を表すシンタクスを示す。ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)のセマンティクスを説明するために、先ず、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)に格納されるデータの元となるエントリである、エントリPTSEPStartおよびエントリSPNEPStartの意味について説明する。
エントリPTSEPStartと、エントリPTSEPStartに関連付けられたエントリSPNEPStartは、それぞれAVストリーム上のエントリポイントを指す。そして、エントリPTSEPFineと、エントリPTSEPFineに関連付けられたエントリPTSEPCoarseは、同一のエントリPTSEPStartから導かれる。また、エントリSPNEPFineと、エントリSPNEPFineに関連付けられたエントリSPNEPCoarseは、同一のエントリSPNEPStartから導かれる。
図25は、エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す。PTSすなわちエントリPTSEPStartは、データ長が33ビットの値である。MSBのビットを第32ビット、LSBのビットを第0ビットとするとき、この図25の例では、大まかな単位で検索を行う際に用いられるエントリPTSEPCoarseは、エントリPTSEPStartの第32ビットから第19ビットまでの14ビットが用いられる。エントリPTSEPCoarseにより、解像度が5.8秒で、26.5時間までの範囲で検索が可能である。また、より精密な検索を行うためのエントリPTSEPFineは、エントリPTSEPStartの第19ビットから第9ビットまでの11ビットが用いられる。エントリPTSEPFineにより、解像度が5.7ミリ秒で、11.5秒までの範囲で検索が可能である。なお、第19ビットは、エントリPTSEPCoarseとエントリPTSEPFineとで共通して用いられる。また、LSB側の第0ビットから第8ビットまでの9ビットは、用いられない。
図26は、エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す。ソースパケット番号すなわちエントリSPNEPStartは、データ長が32ビットの値である。MSBのビットを第31ビット、LSBのビットを第0ビットとするとき、この図26の例では、大まかな単位で検索を行う際に用いられるエントリSPNEPCoarseは、エントリSPNEPStartの第31ビットから第0ビットまでの全てのビットが用いられる。また、より精密な検索を行うためのエントリSPNEPFineは、エントリSPNEPStartの第16ビットから第0ビットまでの17ビットが用いられる。エントリSPNEPFineにより、例えば略25MB(Mega Byte)のAVストリームファイルまでの範囲で、検索が可能である。
なお、ソースパケット番号の場合でも、エントリSPNEPCoarseとしてMSB側の所定ビット数の値だけ用いるようにしてもよい。例えば、エントリSPNEPCoarseとして、エントリSPNEPStartの第31ビットから第16ビットまでの17ビットを用い、エントリSPNEPFineは、エントリSPNEPStartの第16ビットから第0ビットまでの17ビットを用いる。
上述に基づき、エントリPTSEPStartおよびエントリSPNEPStartは、次のように定義される。
エントリPTSEPStartは、図25で示したように、データ長が33ビットの符号無し整数であり、AVストリーム中で、ランダムアクセスが可能なピクチャ(例えばIDR(Instantaneous Decoding Refresh)ピクチャやI(Intra)ピクチャ)から開始するビデオアクセスユニットの33ビット長のPTSを示す。
エントリSPNEPStartは、図26で示したように、32ビットの符号無し整数であり、エントリPTSEPStartに関連付けられたビデオアクセスユニットの第1バイト目を含むソースパケットの、AVストリームの中でのアドレスを示す。エントリSPNEPStartは、ソースパケット番号の単位で表され、AVストリームファイル中の最初のソースパケットから、値"0"を初期値として、ソースパケット毎に1ずつ増加する値としてカウントされる。
図24を参照し、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)は、第1のforループ文により大まかな単位での検索を行うためのサブテーブル(EP coarse table)が記述され、第2のforループ文によりサブテーブル(EP coarse table)の検索結果に基づきより詳細な検索を行うためのサブテーブル(EP fine table)が記述される。
第1のforループ文の直前に、フィールドEPFineTableStartAddressが配される。フィールドEPFineTableStartAddressは、32ビットのデータ長を有し、最初の第2のforループにおけるフィールドReservedEPFine[EP_fine_id]の第1バイト目の開始アドレスを、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の第1バイト目からの相対バイト数で示す。相対バイト数は、値"0"から開始する。
第1のforループ文は、ループ変数[i]で以て、サブテーブル(EP coarse table)のエントリ数Ncまで繰り返され、エントリ数Ncの組数だけフィールドRefToEPFineID[i]、エントリPTSEPCoarse[i]およびエントリSPNEPCoarse[i]が格納される。第1のforループ文において、フィールドRefToEPFineID[i]は、18ビットのデータ長を有し、フィールドRefToEPFineID[i]に続くフィールドPTSEPCoarse[i]が示すエントリPTSEPCoarseに関連付けられるエントリPTSEPFineを持つ、サブテーブル(EP fine table)内のエントリ番号を示す。エントリPTSEPFineと、このエントリPTSEPFineに関連付けられるエントリPTSEPCoarseとは、同一のエントリPTSEPStartから導かれる。フィールドRefToEPFineID[i]は、第2のforループ文中で記述される順番で定義されるループ変数[EP_fine_id]の値により与えられる。
第1のforループ文の後に、パディングワードを挟んで第2のforループ文による記述がなされる。第2のforループ文は、ループ変数[EP_fine_id]で以て、サブテーブル(EP fine table)のエントリ数Nfまで繰り返され、エントリ数Nfの組数だけ、1ビットのデータ長を有するフィールドReservedEPFine[EP_fine_id]と、3ビットのデータ長を有するフィールドIEndPositionOffset[EP_fine_id]と、11ビットのデータ長を有するフィールドPTSEPFine[EP_fine_id]と、17ビットのデータ長を有するフィールドSPNEPFine[EP_fine_id]とが格納される。これらのうち、フィールドPTSEPFine[EP_fine_id]およびフィールドSPNEPFine[EP_fine_id]は、ループ変数[EP_fine_id]に基づきサブテーブル(EP fine table)から参照されるエントリPTSEPFineおよびエントリSPNEPFineそれぞれが格納される。
エントリPTSEPCoarseおよびエントリPTSEPFine、ならびに、エントリSPNEPCoarseおよびエントリSPNEPFineは、次のように導かれる。サブテーブル(EP fine table)に、関連するデータSPNEPStartの値の昇順に並んでいるNf個のエントリがあるとする。それぞれのエントリPTSEPFineは、対応するエントリPTSEPStartから、次式(1)のように導かれる。
PTSEPFine[EP_fine_id]=(PTSEPStart[EP_fine_id] >>9)/211 ・・(1)
エントリPTSEPCoarseと、対応するエントリPTSEPFineとの関係は、次式(2)、(3)の通りである。
PTSEPCoarse[i]=(PTSEPStart[RefToEPFineID[i]] >>19)/214 ・・(2)
PTSEPFine[RefToEPFineID[i]]=(PTSEPStart[RefToEPFineID[i]] >>9)/211 ・・(3)
それぞれのエントリSPNEPFineは、対応するエントリSPNEPStartから、次式(4)のように導かれる。
SPNEPFine[EP_fine_id]=SPNEPStart[EP_fine_id]/217 ・・(4)
エントリSPNEPCoarseと、対応するエントリSPNEPFineとの関係は、次式(5)、(6)の通りである。
SPNEPCoarse[i]=SPNEPStart[RefToEPFineID[i]] ・・(5)
SPNEPFine[RefToEPFineID[i]]=SPNEPStart[RefToEPFineID[i]]/217 ・・(6)
なお、上述の式(1)〜(6)において、記号「>>x」は、データのLSB側からxビットを超える桁からビットを用いることを意味する。
次に、拡張データを格納するためのブロックblkExtensionData()について説明する。このブロックblkExtensionData()は、所定の拡張データを格納可能なように定義され、インデックステーブルが格納されるファイル"index.bdmv"、プレイリストが格納されるファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"の各ファイルに記述することができる。
図27は、ブロックblkExtensionData()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkExtensionData()の終わりまでのデータ長をバイト数で示す。このフィールドLengthの示すデータ長が"0"でなければ、if文以下の記述がなされる。
フィールドDataBlockStartAddressは、32ビットのデータ長を有し、このシンタクス中の、拡張データの本体が格納されるブロックDataBlock()の開始アドレスを、このブロックblkExtensionData()の先頭バイトからの相対バイト数で示す。すなわち、相対バイト数は、"0"から開始される。なお、フィールドDataBlockStartAddressは、次に示す32ビットアライメントの条件を満たさなければならない。
DataBlockStartAddress%4=0
24ビットのデータ長を有する領域reservedを介してフィールドNumberOfExtDataEntriesが配される。フィールドNumberOfExtDataEntriesは、8ビットのデータ長を有し、このブロックblkExtensionData()のブロックDataBlock()に格納される拡張データのエントリ数を示す。拡張データのエントリは、拡張データの本体を取得するための情報が格納される。この例では、拡張データのエントリは、フィールドExtDataType、フィールドExtDataVersion、フィールドExtDataStartAddressおよびフィールドExtDataLengthからなるブロックext_data_entry()であって、ブロックblkExtensionData()において、第1のforループ文に従いこのフィールドNumberOfExtDataEntriesに示される個数だけ、このブロックext_data_entry()が存在する。
フィールドExtDataTypeは、16ビットのデータ長を有し、このブロックblkExtensionData()に記述される拡張データが記録装置用の拡張データであることを表す。このフィールドExtDataTypeの値は、拡張データを識別する第1の値であり、このブロックblkExtensionData()を含む規格書のライセンサ(使用認可者)が割り当てると定義することができる。フィールドExtDataVersionは、拡張データを識別する第2の値であり、この拡張データのバージョン番号を表すものと定義することができる。なお、このブロックblkExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionの値が同一のブロックext_data_entry()が2以上、存在してはならない。
フィールドExtDataStartAddressは、32ビットのデータ長を有し、このフィールドExtDataStartAddressが含まれる拡張データのエントリ(ブロックext_data_entry())に対応する拡張データの開始アドレスを示す。フィールドExtDataStartAddressは、ブロックblkExtensionData()の先頭バイトからの相対バイト数で、拡張データext_dataの開始アドレスを示す。なお、フィールドExtDataStartAddressは、次に示す32ビットアライメントの条件を満たさなければならない。
ExtDataStartAddress%4=0
フィールドExtDataLengthは、32ビットのデータ長を有し、このフィールドExtDataStartAddressが含まれる拡張データのエントリ(ブロックext_data_entries())に対応する拡張データのデータ長を示す。データ長は、バイト数で示される。
フィールドNumberOfExtDataEntriesで示された個数だけ、拡張データのエントリ(ブロックext_data_entry())が記述されると、それぞれ16ビットのデータ長を有し任意のデータ列からなるフィールドpadding_wordが、2フィールドを組として任意の回数L1だけ繰り返される。その後、拡張データの本体が格納されるブロックDataBlock()が記述される。ブロックDataBlock()は、1以上の拡張データが格納される。それぞれの拡張データext_dataは、上述したフィールドExtDataStartAddressフィールドExtDataLengthに基づき、ブロックDataBlock()から取り出される。
図28は、ブロックblkExtensionData()における各データの参照関係を模式的に示す。フィールドLengthにより、フィールドLength直後の位置からブロックblkExtensionData()の最後までのデータ長が示される。フィールドDataBlockStartAddressにより、ブロックDataBlock()の開始位置が示される。フィールドNumberOfExtDataEntriesで示される個数だけ、ブロックext_data_entryが記述される。最後のブロックext_data_entryからブロックDataBlock()の間には、任意の長さでフィールドpadding_wordが置かれる。
ブロックDataBlock()内には、ブロックext_data_entry()で示される拡張データext_dataが置かれる。それぞれの拡張データext_dataの位置およびデータ長は、対応するブロックext_data_entry()内のフィールドExtDataStartAddressおよびフィールドExtDataLengthにより示される。したがって、ブロックDataBlock()内での拡張データext_dataの並び順は、対応するブロックext_data_entry()の並び順と一致していなくてもよい。
このように、拡張データを、拡張データの本体が格納されるブロックDataBlock()と、ブロックDataBlock()内の拡張データに対するアクセス情報などが格納されるブロックext_data_entry()とによる2層構造とすることで、複数の拡張データを格納することが可能となる。
次に、上述の拡張データの一例の作成方法および読み出し方法について説明する。図29は、ブロックblkExtensionData()にデータを書き込む際の一例の処理を示すフローチャートである。この図29は、ブロックblkExtensionData()中の(n+1)番目のエントリとして、拡張データを追加し、ブロックblkExtensionData()を書き換える場合の例である。
先ず、ステップS10で、書き込もうとしている拡張データのデータ長を取得し、フィールドExtDataLength[n+1]の値にセットする。なお、「[n+1]」の記述は、(n+1)番目のエントリの番号に対応する。次に、ステップS11で、現在のブロックblkExtensionData()に列挙されているブロックext_data_entry()のフィールドExtDataLengthおよびフィールドExtDataStartAddressの値を調べ、ブロックDataBlock()の使用状況を取得する。
そして、次のステップS12で、ブロックDataBlock()中に、書き込もうとしている拡張データのデータ長であるフィールドExtDataLength[n+1]に示されるデータ長以上の、連続した空き領域があるか否かが判断される。若し、あると判断されれば、処理はステップS14に移行される。
一方、フィールドExtDataLength[n+1]に示されるデータ長以上の連続した空き領域が無いと判断されれば、処理はステップS13に移行され、ブロックblkExtensionData()におけるフィールドLengthの値を大きくし、フィールドExtDataLength[n+1]に示されるデータ長以上の連続した空き領域をブロックDataBlock()内に作る。空き領域ができたら、処理がステップS14に移行される。
ステップS14では、拡張データを書き込む領域の先頭アドレスを決め、その先頭アドレスの値をフィールドExtDataStartAddress[n+1]とする。次のステップS15で、フィールドExtDataStartAddress[n+1]から、上述のステップS10でセットされたフィールドExtDataLength[n+1]の長さの拡張データext_data[n+1]を書き込む。
データの書き込みが終了したら、ステップS16で、ブロックext_data_entry()に対して、フィールドExtDataLength[n+1]と、フィールドExtDataStartAddress[n+1]とを追加する。
なお、上述において、書き換えを行うブロックblkExtensionData()は、すでにディスクなどの記録媒体から読み出されて記録装置のメモリに記憶されているものとする。そのため、ステップS13における、フィールドLengthの値の変更によるブロックblkExtensionData()の拡大は、システムに任され、システムがメモリアロケーションを適切に行うことでなされる。
図30は、ブロックblkExtensionData()から拡張データを読み出す際の一例の処理を示すフローチャートである。なお、この図30のフローチャートによる処理は、再生専用の記録媒体と、記録可能な記録媒体との両方に適用可能なものである。先ず、最初のステップS20で、読み込もうとする拡張データが準拠する規格から、フィールドExtDataTypeの値を取得し、ステップS21で、読み込もうとする拡張データの種別から、フィールドExtDataVersionの値を取得する。
次のステップS22で、ブロックblkExtensionData()に列挙されているブロックext_data_entry()を1つずつ順次、読み込む。そして、ステップS23で、読み込んだブロックext_data_entry()に含まれるフィールドExtDataTypeおよびフィールドExtDataVersionの値が、上述のステップS20およびステップS21で取得したフィールドExtDataTypeおよびフィールドExtDataVersionの値と一致するか否かが判断される。
一致していないと判断されれば、処理はステップS26に移行され、ブロックblkExtensionData()内に列挙されるブロックext_data_entry()を全て読み終えたか否かが判断される。全て読み終えたと判断されれば、処理はステップS27に移行され、このブロックblkExtensionData()には、読み込もうとした拡張データが存在しないとして、一連の処理が終了される。全て読み終えていないと判断されれば、処理はステップS22に戻され、次のブロックext_data_entry()が読み込まれる。
上述のステップS23において、ブロックext_data_entry()に含まれるフィールドExtDataTypeおよびフィールドExtDataVersionの値が、取得したフィールドExtDataTypeおよびフィールドExtDataVersionの値と一致していると判断されれば、処理はステップS24に移行される。ここでは、ブロックblkExtensionData()中の[i]番目のエントリで一致したものとする。
ステップS24では、[i]番目のエントリのブロックext_data_entry()からフィールドExtDataLength[i]の値と、フィールドExtDataStartAddress[i]の値とを読み込む。そして、ステップS25で、ステップS24で読み込んだフィールドExtDataStartAddress[i]で示されるアドレスから、フィールドExtDataLength[i]で示されるデータ長だけ、データを読み出す。
次に、上述した、インデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"にそれぞれ定義可能な、拡張データを格納する拡張データブロックblkExtensionData()について説明する。
先ず、インデックスファイル"index.bdmv"に対して定義される一例の拡張データブロックについて説明する。ここでは、プレイリスト毎に記録可能な記録媒体に特有の属性情報を付加するようにした、一例の拡張データブロックについて説明する。図31は、このプレイリスト属性を記述するための、ファイル"index.bdmv"内のフィールドblkExtensionData()におけるブロックDataBlock()(図27参照)の一例の構造を表すシンタクスを示す。この図31の例では、ブロックDataBlock()がブロックblkIndexExtensionData()として記述されている。
先ず、上述の図27を参照して、ブロックblkExtensionData()においてフィールドExtDataTypeを値"0x1000"、フィールドExtDataVersionを値"0x0100"とする。これらフィールドExtDataTypeおよびフィールドExtDataVersionに記述された値は、例えば再生装置側において、予めROM(Read Only Memory)などに記憶されたテーブルが参照されて識別される。ブロックDataBlock()内のフィールドExtDataStartAddressおよびフィールドExtDataLengthで示される領域に、ブロックblkIndexExtensionData()が格納される。
ブロックblkIndexExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ISO646に規定された符号化方式で符号化した4文字からなる文字列が記述される。この図31の例では、フィールドTypeIndicatorにISO646に既定の方式で符号化された4文字の文字列"IDEX"が記述され、次に続くデータ種類がインデックスファイルにおける拡張データであることが示される。
フィールドTypeIndicatorに続けて32ビットのデータ長を有する領域reservedが配され、その次に、32ビットのデータ長を有するフィールドTableOfPlayListStartAddressが配される。フィールドTableOfPlayListStartAddressは、ブロックblkTableOfPlayList()の、このブロックblkIndexExtensionData()先頭を基準とした開始アドレスが示される。
フィールドTableOfPlayListStartAddressの次に、32ビットのデータ長を有するフィールドMakersPrivateDataStartAddressが配されブロックblkMakersPrivateData()のこのブロックblkIndexExtensionData()先頭を基準とした開始アドレスが示され、192ビットのデータ長を有する領域reservedを介してブロックblkUIAppInfoAVCHD()が配される。16ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkTableOfPlayLists()が配される。さらに続けて、16ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次にブロックblkMakersPrivateData()が配される。このブロックblkMakersPrivateData()の後に、16ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
なお、ブロックblkUIAppInfoAVCHD()およびブロックblkMakersPrivateData()は、この発明と関連性が薄いので、説明を省略する。
図32は、上述したブロックblkTableOfPlayLists()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkTableOfPlayLists()の最後のバイトまでのデータ長をバイト数で示す。フィールドLengthに続けて、プレイバックタイトルを再生するためのプレイリストに関する情報が記述されるブロックblkFirstPlaybackTitlePlayLists()と、メニュータイトルに関する情報が記述されるブロックblkMenuTitlePlayLists()とが配される。これらブロックblkFirstPlaybackTitlePlayLists()およびブロックblkMenuTitlePlayLists()は、この発明と関連性が薄いので、説明を省略する。
次に、16ビットのデータ長を有するフィールドNumberOfTitlePlayListPairが配される。フィールドNumberOfTitlePlayListPairは、プレイバックタイトルおよびメニュータイトル以外のタイトルを再生するためのプレイリストの数が記述される。次のforループ文に従い、フィールドNumberOfTitlePlayListPairで示される数だけ、ブロックblkMovieTitlePlayListPair()が記述される。ブロックblkMovieTitlePlayListPair()は、フィールドPlayListFileName、フィールドPlayListAttributeおよびフィールドRefToTitleIdを含む。すなわち、ブロックblkMovieTitlePlayListPair()は、このforループ文で示される[i]番目のプレイリストについて、当該プレイリストのファイル名、当該プレイリストに付与された属性、ならびに、当該プレイリストの参照タイトルIDからなるプレイリストの情報を構造化したものである。
このforループ文による並び順は、記録順とされる。すなわち、1のプレイリストが追加されると、フィールドNumberOfTitlePlayListPairの値が"1"だけインクリメントされ、既存のプレイリストの情報の後ろに、追加されたプレイリストの情報が追記される。
フィールドPlayListFileNameは、40ビット(5バイト)のデータ長を有し、プレイリストのファイル名がISO646に規定された符号化方式で符号化されて記述される。フィールドPlayListFileNameの次に、6ビットのデータ長を有する領域reservedを介してフィールドPlayListAttributeが配される。フィールドPlayListAttributeは、2ビットのデータ長を有し、当該プレイリストに付与された属性を示す。プレイリストは、その成因に基づき、クリップの生成と共に生成されるプレイリストに対応する第1の種類と、既存のタイトルあるいはプレイリストの一部または全部を用いて作成されるプレイリストに対応する第2の種類と、メニューを再生するために用いる第3の種類との3種類に分けられ、各プレイリストには、プレイリストの種類に応じて、それぞれ対応する属性「Real」(第1の種類)、属性「Virtual」(第2の種類)および属性「Menu」(第3の種類)が付与される。
なお、以下では適宜、属性「Real」が付与されたプレイリストをリアルプレイリスト、属性「Virtual」が付与されたプレイリストをバーチャルプレイリスト、属性「Menu」を付与されたプレイリストをメニュープレイリストと呼ぶ。
フィールドRefToTitleIdは、同一ループ内のフィールドPlayListFileNameに示されるプレイリストが作成時に属するタイトルのID(番号)が記述される。より具体的な例としては、インデックスファイル"index.bdmv"内のブロックblkIndexes()における、対応する値title_idが記述される。なお、当該プレイリストがファーストプレイバックタイトルのみから再生される場合、フィールドRefToTitleIdの値は、第1の固定値、例えば"0xFFFF"とされる。また、当該プレイリストがメニュータイトルのみから再生される場合は、フィールドRefToTitleIdの値は、第2の固定値、例えば"0xFFFE"とされる。
ここで、リアルプレイリスト、バーチャルプレイリストおよびメニュープレイリストについて、概略的に説明する。属性「Real」が付されるリアルプレイリストは、例えばクリップの生成と共に生成され、ディスクに記録される。リアルプレイリストは、素材を指す最初のプレイリストとなることから、オリジナルのプレイリストとも呼ばれる。一例として、リアルプレイリストは、生成されたクリップの先頭をIN点、最後尾をOUT点としてそれぞれ指定する。
リアルプレイリストは、ストリーム実体であるクリップを参照したプレイリストであって、新規にクリップが作成されると、作成されたクリップを参照するリアルプレイリストが必ず作成される。換言すれば、ディスク上において、どのリアルプレイリストからも参照されていないクリップは存在しない。したがって、ディスク上におけるリアルプレイリストの総再生時間は、当該ディスク上に記録されたクリップの総再生時間に一致することになる。すなわち、ディスク上における記録可能な残り時間は、ユーザから見ると、リアルプレイリストまたはリアルプレイリストのみから構成されるタイトルの記録可能時間に一致する。
リアルプレイリストは、素材であるクリップと常に1対1の対応関係を有し、リアルプレイリストを編集などにより削除すると、対応するクリップも、ディスク上から削除される。また、リアルプレイリストにおいて、クリップの参照区間の一部を削除すると、削除された部分に応じて、当該リアルプレイリストに対応するクリップの一部も削除される。このように、リアルプレイリストに対する編集は、ディスク上に記録されるクリップの実体の改変を伴う編集であるため、実体編集あるいはリアル編集などと呼ばれる。
属性「Virtual」が付されるバーチャルプレイリストは、既存のタイトルあるいはプレイリストの一部または全部を用いて作成されるプレイリストである。バーチャルプレイリストは、既存のクリップに対してIN点およびOUT点を設定し、IN点およびOUT点で定義される区間を参照して作成したプレイリストである。
一例として、バーチャルプレイリストは、上述したリアルプレイリストに対してIN点およびOUT点を指定する。例えば、複数のリアルプレイリストに対し、それぞれIN点およびOUT点を指定すると共に、それぞれIN点およびOUT点で指定される複数の区間の再生順を指定する。バーチャルプレイリストを元にして、さらにバーチャルプレイリストを作成することもできる。すなわち、1または複数のバーチャルプレイリストに対して、IN点およびOUT点を指定するバーチャルプレイリストを作成することができる。
バーチャルプレイリストは、編集において、例えばサイズの大きなクリップ(ストリーム実体)を変更すること無しに、高速に作成可能である。また、バーチャルプレイリストは、削除する際も、クリップに対する参照関係のみを削除すればよく、クリップ実体に対して変更を加える必要が無い。このように、バーチャルプレイリストの編集は、クリップの実体の改変を伴わない編集であるため、仮想編集あるいはバーチャル編集などと呼ばれる。
属性「Menu」が付されるメニュープレイリストは、メニューを再生するために用いるプレイリストであり、メニューの作成および更新時に生成される。メニュープレイリストは、すなわち、メニュータイトルを再生するためのムービーオブジェクトから呼び出されるプレイリストである。
次に、プレイリストファイル"xxxxx.mpls"に対して定義される一例の拡張データブロックについて説明する。図33は、プレイリストファイル"xxxxx.mpls"内のブロックblkExtensionData()におけるブロックDataBlock()(図27参照)の一例の構造を表すシンタクスを示す。この図33の例では、ブロックDataBlock()がブロックblkPlayListExtensionData()として記述されている。
先ず、上述の図27を参照し、プレイリストファイル"xxxxx.mpls"内のブロックblkExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionがそれぞれ所定の値、例えば上述と同様にそれぞれ値"0x1000"、値"0x0100"とする。
ブロックblkPlayListExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ISO646に規定された符号化方式で符号化した4文字からなる所定の文字列が記述される。このフィールドTypeIndicatorに記述される文字列によって、次に続くデータ種類がプレイリストファイルにおける拡張データであることが示される。
フィールドTypeIndicatorの次に、32ビット(4バイト)のデータ長を有する領域reservedを介して32ビットのデータ長を有するフィールドPlayListMarkExtStartAddressが配され、その次に、32ビットのデータ長を有するフィールドMakersPrivateDataStartAddressが配される。フィールドPlayListMarkExtStartAddressおよびフィールドMakersPrivateDataStartAddressは、それぞれ、ブロックblkPlayListMarkExt()およびブロックblkMakersPrivateData()の、このブロックblkPlayListExtensionData()先頭を基準とした開始アドレスが示される。
フィールドMakersPrivateDataStartAddressの次に、192ビットのデータ長を有する領域reservedを介してブロックblkPlayListMeta()が配される。16ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkPlayListMarkExt()が配される。さらに、16ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次に、ブロックblkMakersPrivateData()が配される。ブロックblkMakersPrivateData()の後ろには、16ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
図34は、ブロックblkPlayListMeta()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLength直後からこのブロックblkPlayListMeta()の終わりまでのデータ長を示す。フィールドLengthの次に、それぞれ16ビットのデータ長を有するフィールドMakerIDおよびフィールドMakerModelCodeが配される。フィールドMakerIDおよびフィールドMakerModelCodeは、このプレイリストファイルを更新したメーカおよび当該メーカの機種を識別する情報がそれぞれ記述される。
フィールドMakerModelCodeの次に、32ビットのデータ長を有する領域reservedを介して16ビットのデータ長を有するフィールドRefToMenuThumbnailIndexが配される。このフィールドRefToMenuThumbnailIndexは、このプレイリストファイルにより再生される一連のクリップを代表するサムネイル画像が存在する場合、そのサムネイル画像を特定するサムネイル番号が記述される。次に8ビットのデータ長を有するブロックblkTimeZone()が配され、このプレイリストファイルを更新した際に、装置に設定されているタイムゾーンを示す情報が記述される。さらに56ビットのデータ長を有するフィールドRecordTimeAndDateが配され、このプレイリストファイルを更新した時刻および日付が記述される。
フィールドRecordTimeAndDateの次に、8ビットのデータ長を有する領域reservedを介して、それぞれ8ビットのデータ長を有するフィールドPlayListCharacterSetおよびフィールドPlayListNameLengthが配され、さらに続けて、255バイトのデータ長を有するフィールドPlayListNameが配される。これらフィールドPlayListCharacterSet、フィールドPlayListNameLengthおよびフィールドPlayListNameにより、このプレイリストファイルにより示されるプレイリストに付された名前に関する情報が記述される。
すなわち、フィールドPlayListCharacterSetは、フィールドPlayListNameに記述されている文字列の文字セットが示される。フィールドPlayListNameLengthは、フィールドPlayListNameに記述されるプレイリスト名のバイト長を示す。フィールドPlayListNameは、このプレイリストに付された名前が記述される。このフィールドPlayListNameにおいて、左から、フィールドPlayListNameLengthに示されるだけのバイト数が有効な文字列であり、それがこのプレイリストの名前とされる。フィールドPlayListNameの中で、フィールドPlayListNameLengthで示された有効な文字列の後のバイト列には、どのような値が入っていてもよい。
フィールドPlayListNameの次に、ブロックAdditional_data()が配される。このブロックAdditional_data()は、追加的な情報を格納するために予約された領域であって、32ビットのデータ長を有するフィールドLength2に示される値のバイト数分のデータ長を有する領域が予約される。
図35は、プレイリストファイルにおけるブロックblkMakersPrivateData()の一例の構造を表すシンタクスを示す。ブロックblkMakersPrivateData()は、このプレイリストファイルに関して、メーカ独自の情報が記述されるブロックである。フィールドLengthは、32ビットのデータ長を有し、このフィールドLength直後からこのブロックblkMakersPrivateData()の終わりまでのデータ長を示す。このフィールドLengthは、値"0"でこのMakersPrivateData()に情報が記述されていないことを示す。フィールドLengthが値"0"以外で、if文以下の記述がなされる。
フィールドDataBlockStartAddressは、32ビットのデータ長を有し、このシンタクス中の、メーカ独自情報本体が格納されるブロックDataBlock()の開始アドレスを、このブロックblkMakersPrivateData()の先頭バイトからの相対バイト数で示す。24ビットのデータ長を有する領域reservedを介して、8ビットのデータ長を有するフィールドNumberOfMakerEntriesが配される。
次のfor文に従い、フィールドNumberOfMakerEntriesで示される個数だけ拡張データのエントリ、すなわち、フィールドMakerID、フィールドMakerModelCode、フィールドMpdStartAddressおよびフィールドMpdLengthが記述される。フィールドMakerIDおよびフィールドMakerModelCodeは、それぞれ16ビットのデータ長を有し、メーカの識別情報および当該メーカによる機種の識別情報が記述される。また、フィールドMpdStartAddressおよびフィールドMpdLengthは、それぞれ32ビットのデータ長を有し、拡張データの本体が格納されるブロックDataBlock()の、このブロックblkExtensionData()の先頭バイトからの相対バイト数による開始アドレスと、データ長とを示す。
フィールドNumberOfMakerEntriesで示される個数だけ拡張データのエントリが記述されると、それぞれ16ビットのデータ長を有し任意のデータ列からなるフィールドpadding_wordが、2フィールドを組として任意の回数L1だけ繰り返される。その後、拡張データの本体が格納されるブロックDataBlock()が記述される。ブロックDataBlock()は、1以上の拡張データext_dataが格納される。すなわち、フィールドMakerIDおよびフィールドMakerModelCodeで示されるメーカおよび機種毎に、メーカ独自の拡張データがブロックDataBlock()に格納される。それぞれの拡張データは、上述したフィールドMpdStartAddressおよびフィールドMpdLengthに基づき、ブロックDataBlock()から取り出される。
なお、プレイリストファイルにおける拡張データブロックblkPlayListExtensionData()内のブロックblkPlayListMarkExt()は、この発明と関連性が薄いので、説明を省略する。
次に、クリップインフォメーションファイル"zzzzz.clpi"に対して定義される一例の拡張データブロックについて説明する。図36は、クリップインフォメーションファイル内のブロックblkExtensionData()におけるブロックDataBlock()(図27参照)の一例の構造を表すシンタクスを示す。この図36の例では、ブロックDataBlock()がブロックblkClipExtensionData()として記述されている。
ブロックblkClipExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ISO646に規定された符号化方式で符号化した4文字からなる所定の文字列が記述される。このフィールドTypeIndicatorに記述される文字列によって、次に続くデータ種類がクリップインフォメーションファイルにおける拡張データであることが示される。
フィールドTypeIndicatorの次に、32ビット(4バイト)のデータ長を有する領域reservedを介して、それぞれ32ビットのデータ長を有するフィールドProgramInfoExtStartAddressおよびフィールドMakersPrivateDataStartAddressが配される。フィールドProgramInfoExtStartAddressおよびフィールドMakersPrivateDataStartAddressは、それぞれ、このブロックblkClipExtensionData()内のブロックblkProgramInfoExt()およびブロックblkMakersPrivateData()の、このブロックblkClipExtensionData()先頭を基準とした開始アドレスを示す。
フィールドMakersPrivateDataStartAddressの次に、192ビットのデータ長を有する領域reservedを介してブロックblkClipInfoExt()が配される。16ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkProgramInfoExt()が配される。続けて、16ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次に、ブロックblkMakersPrivateData()が配される。ブロックblkMakersPrivateData()の後ろには、16ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
図37は、ブロックblkProgramInfoExt()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkProgramInfoExt()の最後までのデータ長を示す。次に、8ビットのデータ長を有する領域reservedを介して、フィールドNumberOfProgramSequenceが配される。
フィールドNumberOfProgramSequenceは、8ビットのデータ長を有し、このブロックblkProgramInfoExt()に記述されるプログラムシーケンスの情報の数が示される。この例では、フィールドNumberOfProgramSequenceの値が"1"に固定的とされている。次の第1のforループ文に従い、フィールドNumberOfProgramSequenceで示される数だけ、フィールドNumberOfStreamCodingInfoExtInPs[i]およびさらに次の第2のforループ文が繰り返される。第2のforループ文により、8ビットのデータ長を有するフィールドNumberOfStreamCodingInfoExtInPs[i]で示される数だけ、フィールドStreamPID[i][j]およびブロックblkStreamCodingInfoExt(i,j)の組が格納される。
16ビットのデータ長を有するフィールドStreamPID[i][j]は、値[i]および値[j]で指し示されるテーブルを構成し、[i]番目のプログラムシーケンスによって参照されたPMT(Program Map Table)に記述されたエレメンタリストリームに対応するPIDの値を示す。次のブロックblkStreamCodingInfoExt(i,j)は、値[i]および値[j]で示されるエレメンタリストリームの符号化方式に関する情報が記述される。
図38は、ブロックblkStreamCodingInfoExt(i,j)の一例の構造を表すシンタクスを示す。フィールドLengthは、8ビットのデータ長を有し、このフィールドLengthの直後からブロックblkStreamCodingInfoExt(i,j)の最後までのデータ長を示す。次のフィールドStreamCodingTypeは、8ビットのデータ長を有し、対応するストリームの符号化の種類を示す。このフィールドStreamCodingTypeが値"0x1B"で、if文以下の記述がなされ、最初の8ビットのデータ長を有するフィールドHorizontalSizeにより、画面の垂直方向のサイズすなわちライン数を示す。なお、ブロックblkStreamCodingInfoExt(i,j)において、フィールドHorizontalSize以下の情報は、この発明と関連性が薄いので、説明を省略する。
また、クリップインフォメーションファイル内の拡張データブロックblkClipExtensionData()におけるブロックClipEnfoExt()およびブロックblkMakersPrivateData()は、この発明と関連性が薄いので、説明を省略する。
次に、仮想プレーヤについて、概略的に説明する。上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるROM(Read Only Memory)に予め記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにAVCHDフォーマットの規定に従った動作をさせることから、仮想プレーヤと称される。
図39は、この仮想プレーヤの動作を概略的に示す。図39Aは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると(ステップS30)、1のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される(ステップS31)。そして、次のステップS32で、ムービーオブジェクトなどに記述されたプログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
図39Bは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態(ステップS40)に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される(UO:User Operation)。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され(ステップS41)、次のステップS42で、ムービーオブジェクト実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図40を用いて説明する。UOなどにより、タイトル番号#1のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図2に示されるインデックステーブル(Index Table)を参照し、タイトル#1のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル#1のコンテンツ再生を実現するオブジェクトの番号が#1であったとすると、プレーヤは、ムービーオブジェクト#1の実行を開始する。
この図40の例では、ムービーオブジェクト#1に記述されたプログラムは2行からなり、1行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト#1の再生を開始する。プレイリスト#1は、1以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト#1中のプレイアイテムの再生が終了すると、ムービーオブジェクト#1の実行に戻り、2行目のコマンドが実行される。図40の例では、2行目のコマンドが"jump MenuTitle"であって、このコマンドが実行されインデックステーブルに記述されたメニュータイトル(MenuTitle)を実現するムービーオブジェクトの実行が開始される。
次に、この発明の実施の一形態について説明する。この発明では、記録媒体にクリップが記録される際に、記録されるクリップに基づくチャプタを既存のプレイリストに対して追記するようにされる。そして、チャプタを既存のプレイリストに対して追記する際に、プレイリストに所定に設けられた制約に基づき当該クリップに基づくチャプタが当該プレイリストに追記可能か否かを判断する。判断の結果、追記が可能であるとされれば、当該クリップに基づくチャプタを当該プレイリストに対して追記する。一方、追記が不可であると判断されれば、新規にプレイリストを作成し、この新規に作成されたプレイリストに対して、記録されたクリップに基づくチャプタを登録する。
このように記録制御を行うことで、ユーザは、プレイリストに設けられた制約を意識することなくクリップの記録を行うことができ、記録に際する操作性が向上され、利便性に優れる。
図41は、この発明の実施の一形態に適用可能な記録装置の一例の構成を概略的に示す。この記録装置は、入力されたディジタルビデオデータおよびディジタルオーディオデータを、所定の方式で圧縮符号化および多重化したAVストリームを記録媒体に記録するようにしている。
この図41に例示される記録装置は、外部から入力されるビデオデータおよびオーディオデータを記録媒体に記録する、単独の記録装置として用いることもできるし、光学系や撮像素子などを備えたカメラブロックと組み合わせ、撮像した撮像信号に基づくビデオデータを記録媒体に記録する、ビデオカメラ装置の記録ブロックとして用いることもできる。
適用可能な圧縮符号化や多重化の方式としては、様々に考えられる。例えば、H.264|AVCに規定される方式を、この発明の実施の一形態の圧縮符号化として適用することができる。これに限らず、MPEG2方式に基づき圧縮符号化を行うようにしてもよい。また、多重化方式は、例えばMPEG2システムズを適用することができる。以下では、ビデオデータの圧縮符号化をH.264|AVCに規定される方式に準じて行い、ビデオデータおよびオーディオデータの多重化を、MPEG2システムズに規定される方式に準じて行うものとして説明する。
制御部30は、例えばCPU(Central Processing Unit)、RAM(Random Access Memory)およびROM(Read Only Memory)などからなり(図示しない)、ROMに予め記憶されたプログラムやデータに基づき、RAMをワークメモリとして用いてこの記録装置の記録部10の各部を制御する。なお、制御部10と記録部10の各部とを接続する経路は、繁雑さを避けるために、図32では省略している。
UI(User Interface)部31は、この記録装置の動作をユーザが操作するための操作子が所定に設けられ、操作子に対する操作に応じた制御信号を出力する。この制御信号は、制御部30に供給される。制御部30は、ユーザ操作に応じてUI部31から供給された制御信号に基づきなされるプログラムの処理により、記録部10の各部の動作を制御する。例えば、UI部31に対してなされた操作に応じて、記録装置による記録動作の開始および停止の動作が制御部30により制御される。
一例として、制御部30は、所定のプログラムからなりソフトウェアの基本的な機能を提供するOS(Operating System)上で、ユーザインターフェイスの提供や記録部10の各部の制御を提供するアプリケーションソフトウェアを実行させると共に、ソフトウェアと記録部10各部の実際のハードウェアとの間の仲介を行うドライバソフトウェアを実行させる。OSは、さらに、後述する記録媒体20上に記録されたファイルやデータを管理するためのファイルシステムを提供する。アプリケーションソフトウェアは、OSにより提供されるファイルシステムを介して、記録媒体20上に記録されたファイルにアクセスする。
ベースバンドのディジタルビデオデータが端子40から入力される。また、当該ディジタルビデオデータに伴い、ベースバンドのディジタルオーディオデータが端子41から入力される。
ディジタルビデオデータは端子40から記録部10に入力され、ビデオエンコーダ11に供給される。ビデオエンコーダ11は、供給されたディジタルビデオデータを、所定の方式で以て圧縮符号化する。H.264|AVCに規定される方式に準じて圧縮符号化がなされるこの例では、例えば、DCT(Discrete Cosine Transform)と画面内予測とによりフレーム内圧縮を行うと共に、動きベクトルを用いたフレーム間圧縮を行い、さらにエントリピー符号化を行い圧縮効率を高める。ビデオエンコーダ11で圧縮符号化されたディジタルビデオデータは、H.264|AVCのエレメンタリストリーム(ES)として、マルチプレクサ(MUX)13に供給される。
ディジタルオーディオデータは端子41から記録部10に入力され、オーディオエンコーダ12に供給される。オーディオエンコーダ12は、所定の圧縮符号化方式、例えばAC3(Audio Code number 3)により圧縮符号化される。オーディオデータの圧縮符号化方式は、AC3に限られるものではない。オーディオデータを圧縮符号化せず、ベースバンドのデータのまま用いることも考えられる。圧縮符号化されたディジタルオーディオデータは、マルチプレクサ13に供給される。
マルチプレクサ13は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、1本のデータストリームとして出力する。MPEG2システムズに準じて多重化が行われるこの例では、MPEG2のトランスポートストリームを用いて、供給された圧縮ビデオデータおよび圧縮オーディオデータを時分割で多重化する。例えば、マルチプレクサ13は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータをバッファメモリに溜め込む。
バッファメモリに溜め込まれた圧縮ビデオデータは、所定サイズ毎に分割されヘッダが付加されて、PES(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてPESパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すPTSや復号時刻を示すDTS(Decoding Time Stanp)といった、MPEG2システムズに規定される所定の情報が格納される。PESパケットは、さらに分割されてトランスポートパケット(TSパケット)のペイロードに詰め込まれる。TSパケットのヘッダには、ペイロードに詰め込まれたデータを識別するためのPID(Packet Identification)が格納される。マルチプレクサ13から出力されたTSパケットは、ストリームバッファ14に一旦溜め込まれる。
なお、TSパケットは、実際には、MUX/DEMUX13においてさらに所定サイズのヘッダが付加されて出力される。この、TSパケットに対して所定のヘッダを付加したパケットを、ソースパケットと呼ぶ。
記録制御部15は、記録媒体20に対するデータの記録を制御する。記録媒体20としては、例えば記録可能なタイプのDVD(Digital Versatile Disc)を用いることができる。これに限らず、記録媒体20としてハードディスクドライブを用いてもよいし、半導体メモリを記録媒体20に適用することも可能である。また、記録媒体20として、より大容量を実現したBlu−ray Disc(ブルーレイディスク:登録商標)を適用することも考えられる。
記録制御部15は、ストリームバッファ14に溜め込まれたデータ量を監視し、ストリームバッファ14に所定量以上のデータが溜め込まれると、ストリームバッファ14から記録媒体20の記録単位分のデータを読み出して記録媒体20に書き込む。
管理情報処理部16は、例えばCPU、ワークメモリとしてのRAMおよびプログラム所定のデータが予め記憶されるROMからなる(図示しない)。これに限らず、管理情報処理部16は、例えば制御部30におけるプログラム処理で管理情報処理部16の機能を実現することも可能である。この場合、例えば制御部30の有するRAMが揮発性メモリ17として用いられると共に、不揮発性メモリ18が制御部30に接続される。
管理情報処理部16は、記録データに基づき、揮発性メモリ17をワークメモリとして用いて、上述したインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に格納するための情報を生成する。生成された情報は、所定のタイミングで記録媒体20に書き込まれる。
一例として、管理情報処理部16は、マルチプレクサ13から記録データの時間情報を取得すると共に、記録制御部15から記録データの記録媒体20に対するアドレス情報を取得し、取得されたこれら時間情報およびアドレス情報に基づきEP_map情報が生成される。また、UI部31に対する記録開始、記録終了の操作に応じて制御部30から出力される制御信号と、マルチプレクサ13および記録制御部15からの記録データに関する情報とに基づき、クリップインフォメーションファイル"zzzzz.clpi"の生成が行われると共に、生成されたクリップインフォメーションファイルの情報がプレイリストファイルに追記され、プレイリストファイル"xxxxx.mpls"の更新が行われる。
プレイリストファイルの更新の際に、クリップインフォメーションファイルの情報がプレイリストファイルに追記されることでプレイリストファイルに対して所定に設けられた制約を満足するか否かを判断する。判断の結果、制約を満足しないと判断されれば、新規にプレイリストファイルが作成され、生成されたクリップインフォメーションファイルの情報が新規に作成されたプレイリストファイルに記録される。
さらに、記録媒体20に対して新規に記録が行われる際には、インデックスファイル"index.bdmv"やムービーオブジェクトファイル"MovieObject.bdmv"の生成または更新が行われる。
図42は、この発明の実施の一形態に適用可能な一例のデータ構造を示す。インデックスファイル"index.bdmv"は、1乃至複数のタイトルを有する。ムービーオブジェクトファイル"MovieObject.bdmv"は、インデックスファイル"index.bdmv"が有するタイトルに対応して、1乃至複数のムービーオブジェクトを含む。ムービーオブジェクトのそれぞれは、1つのプレイリストファイル"xxxxx.mpls"を呼び出す。プレイリストファイル"xxxxx.mpls"は、1乃至複数のプレイアイテムを含み、プレイアイテムのそれぞれは、クリップインフォメーションファイル"zzzzz.clpi"を参照する。クリップインフォメイションファイル"zzzzz.clpi"は、クリップの実体であるクリップAVストリームファイル"zzzzz.m2ts"と1対1の関係にある。
このような構造において、ユーザには、インデックスファイル"index.bdmv"が有するタイトル単位で、記録媒体に記録されたクリップが見えることになる。ユーザが所望のタイトルを選択すると、ムービーオブジェクトファイル"MovieObject.bdmv"から当該タイトルに対応するムービーオブジェクトが参照される。そして、参照されたムービーオブジェクトに記述されたプレイリストファイル"xxxxx.mpls"が呼び出され、プレイリストファイルに含まれるプレイアイテムに従いクリップインフォメーションファイル"zzzzz.clpi"が参照され対応するクリップAVストリームファイル"zzzzz.m2ts"が再生される。
プレイリストファイル"xxxxx.mpls"に対して時刻情報を示すマーク(プレイリストマーク)を設けることで、ジャンプ位置を設定することができる。マークによってチャプタが定義される。チャプタは、ユーザから見えるタイトル内の再生単位である。記録開始位置には、必ずマークが設けられる。記録開始位置以外の位置にマークを設けることもできる。
すなわち、プレイリストファイル"xxxxx.mpls"に対して、例えば記録開始に伴いプレイリストマークを設定すると共に、クリップを参照するプレイアイテムを登録することで、当該プレイリストファイルに対してチャプタが形成される。換言すれば、プレイリストファイルに対してプレイリストマークを記録すると共に、プレイアイテムを記録することで、当該プレイリストファイルに対してチャプタが記録されるといえる。
上述したように、リアルプレイリストは、クリップと共に生成される。図42の例では、プレイリストファイル"00000.mpls"、"00200.mpls"および"00018.mpls"がリアルプレイリストの属性を有する。
これらのうち、プレイリストファイル"00000.mpls"は、新規に生成されたクリップの情報をプレイリストに追記記録していく例である。例えば、クリップAVストリームファイル"00001.m2ts"に対応するクリップインフォメーションファイル"00001.clpi"を参照するプレイアイテム#0が既に格納されているプレイリストファイル"00000.mpls"に対して、新規に記録されたクリップAVストリームファイル"00125.m2ts"に対応するクリップインフォメーションファイル"00125.m2ts"を参照するプレイアイテム#1が追記記録される。プレイアイテムが示す先頭の時刻には、それぞれマークが設けられる。このプレイリストファイル"00000.mpls"を再生すると、ますプレイアイテム#0に基づきクリップAVストリームファイル"00001.m2ts"が再生され、続けてプレイアイテム#1に基づきクリップAVストリームファイル"00125.m2ts"が再生される。
プレイリストファイル"00200.mpls"は、1のクリップに対して1のプレイリストファイルが生成され、プレイリストファイルが唯一つのプレイアイテムのみを含む例である。
さらに、プレイリストファイル"00018.mpls"は、複数のプレイアイテムが1のクリップを参照する例である。例えば、記録開始および停止によりプレイアイテムが生成されると共に、1のクリップに対してデータが追記されていくような制御が考えられる。プレイアイテム#0の先頭にマークが設けられ、プレイアイテム#0およびプレイアイテム#1を連続的に再生することで、クリップAVストリームファイル"00002.m2ts"の全体が再生される。
一方、バーチャルプレイリストは、図42にプレイリストファイル"00005.mpls"として示されるように、既に存在するクリップに対して再生区間を指定する。この例では、プレイリストファイル"00005.mpls"に含まれるプレイアイテム#0がクリップインフォメーションファイル"00028.clpi"を参照して区間を指定し、プレイアイテム#1がクリップインフォメーションファイル"00002.clpi"を参照して区間を指定している。また、プレイアイテム#0およびプレイアイテム#1の先頭に、マークが設けられている。プレイリストファイル"00005.mpls"を再生すると、先ずプレイアイテム#0に基づきクリップAVストリームファイル"00028.m2ts"の指定区間が再生され、続けて、プレイアイテム#1に基づきクリップAVストリームファイル"00002.m2ts"が再生される。
この発明では、上述したように、新規に記録されるクリップに基づくチャプタを、既存のプレイリストファイルに追記するか、新規プレイリストファイルを作成して記録するかを、プレイリストファイルに所定に設けられた制約に基づき判断している。プレイリストファイルに設けられる制約の一例を以下に示す。制約には、フォーマット上の制約、実装仕様上の制約、商品仕様上の制約などが考えられる。
フォーマット上の制約としては、以下の制約(1)〜制約(7)の各項目が考えられる。
制約(1):1のプレイリストファイルに存在可能なプレイアイテム数の上限。
制約(2):1のプレイリストファイルに存在可能なプレイリストマーク数の上限。
制約(3):1のプレイリストファイルが複数のクリップを参照する場合に、参照される複数のクリップそれぞれの所定のビデオ属性が一致していなければならない。
制約(4):1のプレイリストファイルのファイルサイズの上限。
制約(5):1のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限。
制約(6):1のプレイリストファイルに関連しているクリップインフォメーションファイル内の粗い単位で検索を行うエントリポイントの合計の上限。
制約(7):1のプレイリストファイルに関連しているクリップインフォメーションファイル内の精密な単位で検索を行うエントリポイントの合計の上限。
これらのうち、制約(1)のプレイアイテム数および制約(2)のプレイリストマーク数に関して、フォーマット上、1のプレイリストファイルに存在可能なプレイアイテム数の上限が例えば999個とされ、1のプレイリストファイルに存在可能なプレイリストマーク数の上限が例えば999個とされる。したがって、新規にクリップを記録する際に、当該クリップに基づくチャプタを追記しようとするプレイリストファイルにおいて、チャプタを追記した際にこれらの制約が満足されるか否かを判断する必要がある。
制約(3)のビデオ属性に関して、1のプレイリストファイルが参照する複数のクリップAVストリームファイルにおいて、例えば、画枠サイズ、走査方式、アスペクト比、フレームレート、コーデックの種別といった、ビデオデータの符号化に関わる属性が不変であるように、フォーマットにおいて規定されている。したがって、新規にクリップを記録する際に、当該クリップに基づくチャプタを追記しようとするプレイリストファイルに既に記録されているプレイアイテムにより参照されるクリップにおけるこれらの属性と、新規に記録しようとするクリップにおけるこれらの属性とを比較する必要がある。
制約(4)の1のプレイリストファイルのファイルサイズと、制約(5)の1のプレイリストファイルに関連しているクリップインフォメーションファイルの合計ファイルサイズとに対して、フォーマット上、それぞれ上限が規定されている。このファイルサイズの規定は、記録装置および再生装置のメモリ容量に関連する。
すなわち、例えば記録時に、記録されているクリップに対応するプレイリストや、記録されているクリップのクリップインフォメーションファイルは、一旦、記録装置のメモリに格納され、メモリ上で記録に伴うプレイリストファイルやクリップインフォメーションファイルの更新処理がなされる。そして、メモリに格納されたこれらプレイリストファイルやクリップインフォメーションファイルは、所定のタイミングで記録媒体に書き込まれる。プレイリストファイルや、1のプレイリストファイルに関連しているクリップインフォメーションファイルの合計ファイルサイズに制限を設けることで、例えば記録中にメモリに空き容量が無くなってしまい記録が強制的に停止されるなどの状態になることが防がれる。
プレイリストファイルのファイルサイズの上限は、例えば600kB(キロバイト)が上限とされる。また、1のクリップインフォメーションファイルのファイルサイズの上限が例えば1MB(メガバイト)とされている場合、1のプレイリストファイルに関連しているクリップインフォメーションファイルの合計のファイルサイズの上限は、例えば2MBとされる。
制約(6)および制約(7)の、エントリポイントの上限は、上述のクリップインフォメーションファイルのファイルサイズの上限に関連する。すなわち、既に説明したように、粗い単位で検索を行うエントリポイントおよび精密な単位で検索を行うエントリポイントは、クリップインフォメーションファイル内のブロックblkCPI()におけるブロックblkEPMap()に格納される情報である。すなわち、粗い単位で検索を行うエントリポイントは、ブロックblkEPMap()におけるフィールドPTSEPCoarseおよびフィールドSPNEPCoarseであり、精密な検索を行うエントリポイントは、ブロックblkEPMap()におけるフィールドPTSEPFineおよびフィールドSPNEPFineである。
フォーマット上、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとのそれぞれに対し、1のプレイリストファイルに関連しているクリップインフォメーションファイルについて合計した数に対して上限が規定されている。したがって、新規にクリップを記録しようとする際に、当該クリップを参照するプレイアイテムを追記しようとするプレイリストファイルにおいて、プレイアイテムを追記した際にこれらの制約が満足されるか否かを判断する必要がある。
実装仕様上の制約としては、以下の項目が考えられる。
制約(8):プレイリストファイルにおける拡張データブロック内のブロックblkMakersPrivateData()について、他機で記録したプレイリストファイルのブロックblkMakersPrivateData()の情報を引き継ぐことができない場合は、当該プレイリストファイルを更新してはならない。
例えば、プレイリストファイルにおける拡張データブロック内のブロックblkMakersPrivateData()は、図35においてブロックDataBlock()に示されるように、特にデータサイズが制限されていないため、機器によっては、数100kBといった、比較的大きなデータサイズのデータを書き込む仕様も考えられる。機器の実装によっては、例えばメモリ容量の制限などの要因により、他機で記録されたこのような大きなサイズのブロックblkMakersPrivateData()の情報を引き継いでプレイリストファイルの更新や編集を行うことが困難であることも考えられる。
商品仕様上の制約としては、以下の項目が考えられる。
制約(9):タイトルやチャプタに関して他機と概念が異なる場合でも、ユーザの混乱を招かないようにする必要がある。
制約(10):規定時間以上の連続撮影および記録可能である必要がある。
制約(9)のタイトルおよびチャプタに関して、機器によって、プレイリストおよびチャプタの構成方法が異なることが考えられる。このような機器間で、クリップの記録された記録媒体を交換した場合に、例えば再生時におけるタイトルの表示などに不都合が生じる可能性がある。
一例として、テレビジョン放送を録画するようにされた据置型の記録再生装置(ビデオデッキなど)では、1番組が1プレイリストとし、5分間隔で自動的にプレイリストマークを設けてチャプタを構成する仕様とされ、ビデオカメラ装置では1撮影毎、すなわち記録開始時にプレイリストマークを設けてチャプタを構成し、複数のチャプタを1プレイリストに登録する仕様であるものとする。また、据置型の記録再生機器ではプレイリストの先頭のみサムネイル画像を表示し、チャプタ毎のサムネイル画像を表示しないような仕様であるとする。
このような条件において、据置型の記録再生装置で作成されたプレイリストファイルが記録された記録媒体を、ビデオカメラ装置に装填し、ビデオカメラ装置で記録されたクリップを参照するプレイアイテムを、据置型の記録再生装置で作成されたプレイリストファイルに追記して記録することを考える。この場合、据置型の記録再生装置で記録されたある番組の最後の方のシーンとして、ビデオカメラ装置で撮影された映像がチャプタとして登録されることになる。この記録媒体を、ビデオカメラ装置から再び据置型の記録再生装置に装填して再生させると、ビデオカメラ装置で撮影された映像によるチャプタは、サムネイル画像として表示されず、以前に据置型の記録再生装置で記録された番組の最後のシーンとして再生されてしまい、不自然である。
制約(10)の規定時間以上の連続撮影および記録に関して、記録機の仕様として、所定時間以上の連続記録が保証されるのが一般的である。一方、上述のように、フォーマット上、1のプレイリストに関連するクリップインフォメーションファイルのエントリポイントの合計数に対して上限が設けられている。例えば、記録媒体の空き容量が十分であっても、新規に記録するクリップを参照するプレイアイテムを追記しようとするプレイリストファイルにおいて、既に参照されているクリップインフォメーションファイルにおけるエントリポイントの合計数とフォーマット上規定されている上限とから、保証すべき所定時間分のエントリポイント数を確保できない場合があり得る。したがって、新規にクリップを記録しようとする際に、当該クリップを参照するプレイアイテムを追記しようとするプレイリストファイルに関連するエントリポイント数に基づき所定時間以上の連続記録が可能か否かを判断する必要がある。
次に、この発明の実施の一形態による、新規記録するクリップに基づくチャプタの、プレイリストファイルへの追記可否を判断する処理について説明する。上述した制約(1)〜制約(10)の各項目についてそれぞれ判断を行い、1項目でも追記不可の判断がなされた場合には、新規にプレイリストを作成し、新規記録するクリップに基づくチャプタを、新規に作成されたプレイリストに対して記録する。
図43は、新規記録するクリップに基づくチャプタのプレイリストファイルへの追記可否を判定する一例の処理を示すフローチャートである。先ず、この図43のフローチャートを用いて全体的な処理の流れを概略的に説明する。ここでは、記録媒体20を記録可能なタイプのDVDといった、ディスク状記録媒体(以下、ディスク)であるものとする。また、以下に説明する各判断処理などは、図41を用いて説明した記録装置においては、制御部30において行われる。
記録媒体20が記録装置に装填されると、制御部30により記録制御部15が制御され、記録媒体20からインデックスファイル"index.bdmv"が読み込まれる(ステップS100)。読み込まれたインデックスファイル"index.bdmv"は、例えば管理情報処理部16を介して揮発性メモリ17に記憶される。
次のステップS101で、制御部30は、揮発性メモリ17に記憶されたインデックスファイル"index.bdmv"内に記述された情報に基づき、次に記録されるクリップに基づくチャプタを追記するためのプレイリスト(プレイリストファイル)の候補を特定する。
例えば、インデックスファイル"index.bdmv"における拡張データブロックであるブロックblkIndexExtensionData()内のブロックblkTableOfPlayLists()を参照して、最も新しく記録されたリアルプレイリストを検索してそのリアルプレイリストのファイル名を取得する。
より具体的には、図29を参照し、ブロックblkIndexExtensionData()に列挙されたブロックblkMovieTitlePlayListPair()の中で、フィールドPlayListAttributeが属性「Real」を示しているブロックblkMovieTitlePlayListPair()のうち、最も後ろに記述されているブロックblkMovieTitlePlayListPair()を検索し、検索されたブロックblkMovieTitlePlayListPair()からフィールドPlayListFileNameのデータを取得する。
次のステップS102で、ステップS101で特定された追記候補のプレイリストファイルが記録媒体20から読み込まれ、揮発性メモリ17に記憶される。そして、読み込まれた追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルが記録媒体20から読み込まれる。読み出されたクリップインフォメーションファイルは、揮発性メモリ17に記憶される。
より具体的には、図10〜図12を参照して、追記候補のプレイリストファイルにおいて、ブロックblkPlayList()内の全てのブロックblkPlayItem()が参照され、ブロックblkPlayItem()に記述されるフィールドClipInformationFileNameのデータが全て取得される。そして、取得されたフィールドClipInformationFileNameのデータに示されるクリップインフォメーションファイルを、記録媒体20から全て読み出す。
以下のステップS104〜ステップS111で、揮発性メモリ17に記憶された追記候補のプレイリストファイルおよびクリップインフォメーションファイルに基づき、上述した各制約に基づくチャプタの追記可否の判定がなされる。すなわち、ステップS104で、上述の制約(1)に対応し、ステップS101で取得された追記候補のプレイリストファイルに含まれるプレイアイテム数に基づき追記可否の判定を行う。次のステップS105で、上述した制約(2)に対応し、追記候補のプレイリストファイルに含まれるプレイリストマーク数に基づき追記可否の判定を行う。次のステップS106で、上述した制約(3)に対応し、追記候補のプレイリストファイルに記述されるビデオ属性と、新規に記録しようとするクリップのビデオ属性とに基づき追記可否の判定を行う。
次のステップS107で、上述した制約(4)に対応し、追記候補のプレイリストファイルのファイルサイズに基づき追記可否の判定を行う。次のステップS108で、上述した制約(5)に対応し、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズに基づき追記可否の判定を行う。次のステップS109で、上述した制約(6)および制約(7)に対応し、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルに格納されるエントリポイントの合計数に基づく追記可否の判定を行う。
次のステップS110で、上述した制約(8)に対応し、追記候補とされたプレイリストファイル内における他機による独自の拡張データの有無に基づく追記可否の判定を行う。さらに、次のステップS111で、上述した制約(9)に対応し、追記候補のプレイリストファイルの最終更新者に基づく追記可否の判定を行う。
次のステップS112では、上述したステップS104〜ステップS111までの各判断処理による判定結果に基づき、新規記録されるクリップに基づくチャプタを、追記候補とされたプレイリストファイルに対して追記するか否かの最終的な判断がなされる。例えば、ステップS104〜ステップS111の各処理による判定結果を、制御部30が有するレジスタなどにそれぞれ保持し、ステップS112において、レジスタに保持された各処理による判定結果に基づき判断を行う。
すなわち、ステップS112では、ステップS104〜ステップS111までの各処理の全てにおいて追記可能であると判定されたら、新規記録するクリップにに基づくチャプタを、ステップS101で取得された追記候補のプレイリストファイルに対して追記するように判断する。
一方、上述したステップS104〜ステップS111までの各処理において、追記不可と判定された処理が一つでもあれば、上述のステップS101で取得された追記候補のプレイリストファイルに基づくチャプタの追記が不可であると判断する。この場合、新規にリアルプレイリストのプレイリストファイルを作成し、この新規のプレイリストファイルに対して、新規に記録されるクリップに基づくチャプタを記録する。
なお、上述したステップS104〜ステップS111の各処理の順序は、この順序に限られない。すなわち、ステップS104〜ステップS111の各処理は、任意の順序で行うことができる。また、ステップS104〜ステップS111の各処理を並列的に行うことも可能である。さらに、ステップS104〜ステップS111の各処理の全てを行わず、各処理のうち1または複数の処理を選択的に行ってもよい。
以下に、上述したステップS104〜ステップS111の各処理のそれぞれを、より詳細に説明する。図44は、ステップS104による、制約(1)に対応した、追記候補のプレイリストファイルに含まれるプレイアイテム数に基づく追記可否判断の一例の処理を示す。この処理では、ステップS120に一例が示されるように、追記候補のプレイリストファイル内のブロックblkPlayList()(図11参照)を参照してフィールドNumberOfPlayItemsの値を取得し、取得されたフィールドNumberOfPlayItemsの値と、1のプレイリストファイルに存在可能なプレイアイテム数に対して設定された処理の上限値、例えば値"999"とを比較する。
比較の結果、フィールドNumberOfPlayItemsの値が所定の上限値未満であれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、フィールドNumberOfPlayItemsの値が所定の上限値以上であれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
図45は、ステップS105による、制約(2)に対応した、追記候補のプレイリストファイルに含まれるプレイリストマーク数に基づく追記可否判断の一例の処理を示す。この処理では、ステップS130に一例が示されるように、追記候補のプレイリストファイル内のブロックblkPlayListMark()(図14参照)を参照してフィールドNumberOfPlayListMarksの値を取得し、取得されたフィールドNumberOfPlayListMarksの値と、1のプレイリストファイルに存在可能なプレイリストマーク数に対して設定された所定の上限値、例えば値"999"とを比較する。
比較の結果、フィールドNumberOfPlayListMarksの値が所定の上限値未満であれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、フィールドNumberOfPlayListMarksの値が所定の上限値以上であれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
なお、既に説明したように、プレイリストマークには、エントリマークおよびリンクポイントの2タイプが存在する。このステップS130においては、これらエントリマークおよびリンクポイントの合計数に対して上限値未満であるか否かが判定される。
図46は、ステップS106による、制約(3)に対応した、追記候補のプレイリストファイルに記述されるビデオ属性と、新規に記録しようとするクリップのビデオ属性とに基づく追記可否判断の一例の処理を示す。先ず、最初のステップS140において、記録するビデオデータの属性情報を取得する。この実施の一形態では、記録装置に対して現在設定されている撮影モードや録画モードに基づき、記録するビデオデータの属性情報として画枠サイズ、アスペクト比、フレームレートおよび走査種別(インターレース/プログレッシブ)を取得する。
以下のステップS141〜ステップS144で、追記候補のプレイリストファイルに関連するクリップのビデオ属性が取得される。この実施の一形態では、追記候補のプレイリストファイルに対して複数のプレイアイテムが格納されている場合、最も最初に記録されたプレイアイテムが参照するクリップインフォメーションファイルから、ビデオ属性を取得する。概略的には、ビデオ属性として、ステップS141で画像幅を取得し、ステップS142で画像高(ライン数)および走査種別を取得し、ステップS143でアスペクト比を取得し、ステップS144でフレームレートを取得する。
より具体的には、追記候補のプレイリストファイル内のブロックblkPlayList()(図11参照)において、最も先頭側に格納されるブロックblkPlayItem()(図12参照)を参照し、フィールドClipInformationFileNameのデータを取得し当該プレイアイテムが参照するクリップインフォメーションファイルのファイル名を取得する。上述した図43のフローチャートにおけるステップS103の処理により読み込まれた、追記候補のプレイリストに関連する全てのクリップインフォメーションファイルのうち、取得されたファイル名に対応するクリップインフォメーションファイルを参照する。
ステップS141では、当該クリップインフォメーションファイルにおける拡張データであるブロックblkClipExtensionData()内のブロックblkProgramInfoExt()(図37参照)が参照され、当該ブロックblkProgramInfoExt()において、さらにブロックblkStreamCodingInfoExt(i,j)(図38参照)が参照される。そして、当該ブロックblkStreamCodingInfoExt(i,j)内のフィールドHorizontalSizeの値が取得される。
ステップS142では、当該クリップインフォメーションファイルにおけるブロックblkProgramInfo()(図17参照)内のブロックblkStreamCodingInfo()(図18参照)が参照され、フィールドVideoFormatの値が取得される。フィールドVideoFormatは、図19を用いて既に説明したように、4ビットで表現可能な値を用いて、ビデオデータのライン数と走査方式(インターレース/プログレッシブ)との組み合わせが示されている。
ステップS143では、ステップS142と同様にブロックblkStreamCodingInfo()が参照され、フィールドAspectRatioの値が取得される。フィールドAspectRatioは、図21を用いて既に説明したように、4ビットで表現可能な値を用いて、ビデオデータの画枠のアスペクト比が示されている。
ステップS144では、ステップS143およびステップS143と同様に、ブロックblkStreamCodingInfo()が参照され、フィールドFrameRateの値が取得される。フィールドFrameRateは、図20を用いて既に説明したように、4ビットで表現可能な値を用いて、ビデオデータのフレームレートが示されている。
ステップS145では、ステップS140で記録機から取得された、記録するビデオデータの属性情報のそれぞれと、ステップS141〜ステップS144で取得された、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとが比較される。
比較の結果、記録するビデオデータの属性情報のそれぞれと、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとが全て一致していれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、記録するビデオデータの属性情報のそれぞれと、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとにおいて、一つでも不一致の属性がある場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
図47は、ステップS107による、制約(4)に対応した、追記候補のプレイリストファイルのファイルサイズに基づく追記可否判断の一例の処理を示す。この処理においては、追記候補のプレイリストに対して少なくとも所定チャプタ数を追記しても、1のプレイリストファイルのファイルサイズの上限を超えないことを以て、追記の可否を判断する。
なお、所定チャプタ数は、1チャプタ、複数チャプタ、1のプレイリストファイルに存在可能な最大チャプタ数に対する残りのチャプタ数など、記録機の設計思想などにより様々に考えられる。ここでは、所定のチャプタ数を、1のプレイリストファイルに存在可能な最大チャプタ数に対する残りのチャプタ数であるものとする。
先ず、ステップS150において、予め計算しておいた、1チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPを取得する。すなわち、このステップS150では、例えば1のチャプタを形成するためのプレイアイテムおよびプレイリストマークのデータ量を計算する。
図12を参照し、プレイアイテムにおいて、フィールドStillModeおよびフィールドStillTime、ならびに、ブロックblkUOMaskTable()およびブロックblkSTNTable()は、データ長が変動する可能性のあるデータであるが、実際には、これらのデータは、記録モードや記録機によって固定長とされる。また、プレイリストマークは、図14を参照し、各フィールドの値が固定長とされている。このように、1のクリップを記録する際に生成されるプレイアイテムおよびプレイリストマークのデータサイズは、予め計算することができる。また、計算された値は、記録時間に依らない性質のものである。この1チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPの値は、予め計算され例えば記録機が有するROMなどに記憶される。この図47のフローチャートによる処理を実行する毎に計算してもよい。
プレイリストに対してチャプタを追記する場合には、プレイアイテムとプレイリストマークとが増加することになる。したがって、プレイリストに対してチャプタを追記する際には、制約(1)および制約(2)の、1のプレイリストファイルに存在可能なプレイアイテムおよびプレイリストマーク数も考慮に入れる必要がある。
ステップS151では、追記候補のプレイリストファイルに追記可能なプレイアイテム数PI_REMAINを計算する。すなわち、追記候補のプレイリストファイル内のブロックblkPlayList()(図11参照)を参照してフィールドNumberOfPlayItemsの値を取得し、追記候補のプレイリストに含まれるプレイアイテム数を求める。そして、追記候補のプレイリストに含まれるプレイアイテム数を、1のプレイリストファイルに存在可能なプレイアイテム数に対して設定された所定の上限値PI_MAX、例えば"999"から減じて、追記候補のプレイリストに追記可能なプレイアイテム数PI_REMAINを求める。
すなわち、追記候補のプレイリストファイル追記可能なプレイアイテム数PI_REMAINは、下記の式(1)により求められる。
PI_REMAIN=PI_MAX−NumberOfPlayItems ・・・(1)
ステップS152では、追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINを計算する。すなわち、追記候補のプレイリストファイル内のブロックblkPlayListMark()(図14参照)を参照してフィールドNumberOfPlayListMarksの値を取得し、追記候補のプレイリストに含まれるプレイリストマークの数を求める。そして、追記候補のプレイリストに含まれるプレイリストマーク数を、1のプレイリストに存在可能なプレイアイテム数に対して設定された所定の上限値MARK_MAX、例えば"999"から減じて、追記候補のプレイリストに追記可能なプレイリストマーク数MARK_REMAINを求める。
すなわち、追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINは、下記の式(2)により求められる。
MARK_REMAIN=MARK_MAX−NumberOfPlayListMarks ・・・(2)
次のステップS153では、ステップS151で求められた追記候補のプレイリストに追記可能なプレイアイテム数PI_REMAINと、ステップS152で求められた追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINとのうち小さい方を、追記候補に追記可能なチャプタ数CHAP_REMAINとする。
すなわち、追記候補のプレイリストファイルに追記可能なチャプタ数CHAP_REMAINは、「MIN」を括弧内の値のうち小さい方を選択することを表すものとして、上述の式(1)および式(2)の結果を用いて、下記の式(3)により求められる。なお、「MIN」は、括弧内の値のうち最小の値を選択することを示す。
CHAP_REMAIN=MIN ( PI_REMAIN, MARK_REMAIN ) ・・・(3)
次のステップS154では、追記候補のプレイリストファイルのファイルサイズを取得し、制約(4)の1のプレイリストファイルのファイルサイズの上限PL_SIZE_MAXに対して残されたデータサイズSIZE_REMAINを求める。プレイリストファイルのファイルサイズは、例えばOSのファイルシステムにより提供されるファンクションを利用して取得することができる。データサイズSIZE_REMAIN(kB)は、下記の式(4)により求められる。なお、追記候補のプレイリストファイルのファイルサイズをFILE_SIZE(kB)とする。
SIZE_REMAIN(kB)=PL_SIZE_MAX(kB)−FILE_SIZE(kB) ・・・(4)
次のステップS155で、追記候補のプレイリストファイルに対して追記可能なチャプタ数分のプレイアイテムおよびプレイリストマークを追記した場合に、追記候補のプレイリストファイルのファイルサイズが1のプレイリストファイルのファイルサイズの上限を超えないか否かが判断される。
すなわち、ステップS150で求めた1チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPと、式(3)および式(4)の結果とを用いて、下記の式(5)を満足するか否かが判断される。
SIZE_1CHAP×CHAP_REMAIN≧SIZE_REMAIN ・・・(5)
若し、式(5)が満足されれば、新規記録のクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断される。一方、式(5)が満足されなければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
図48は、上述のステップS108の、制約(5)に対応した、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズに基づく追記可否判断の一例の処理を示す。
上述の制約(5)によれば、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズには、例えば2MBといったように、上限値CLIP_SUM_MAXが設定される。チャプタの追記により追記候補のプレイリストに対してクリップインフォメーションファイルが追加された際に、当該追記候補のプレイリストファイルに関連するクリップインフォメーションファイルの合計サイズが、この上限値CLIP_SUM_MAXを超えないようにする必要がある。
ステップS160で、予め計算しておいた、1のクリップインフォメーションファイルの最大サイズSIZE_1CLIPを取得する。クリップインフォメーションファイルは、ブロックblkEPMap()に、PTS値とクリップAVストリームファイルのバイトアドレスとを関連付けるエントリポイントの情報が格納される(図23〜図26参照)。このエントリポイントの情報は、記録時間により変化する値である。クリップインフォメーションファイルに格納されるその他の情報は、符号化方式などにより記録時間に依らず固定的な値である。一方、上述したように、記録機の仕様として、連続記録を保証する最低時間が設定される。エンコーダにおけるビデオやオーディオの符号化方式により、連続記録を保証する最低時間分のエントリポイント数が決まる。連続記録を保証する最低時間分のエントリポイントの合計データサイズを計算し、計算結果に基づき最大サイズSIZE_1CLIPを求める。
次のステップS161で、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルについてファイルサイズを取得し、合計サイズSIZE_TOTAL_CLIPを計算する。
すなわち、追記候補のプレイリストファイル内の全てのブロックblkPlayItem()(図12参照)を参照し、各ブロックblkPlayItem()についてフィールドClipInformationFileNameのデータを取得する。そして、取得されたフィールドClipInformationFileNameのデータに示されるクリップインフォメーションファイルのファイルサイズを、追記候補のプレイリストファイル内の全てのブロックblkPlayItem()についてそれぞれ求め、合計する。クリップインフォメーションファイルのファイルサイズは、例えばOSのファイルシステムにより提供されるファンクションを利用して取得することができる。
次のステップS162で、下記の式(6)に従い、1のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、ステップS161で計算された、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値と、ステップS160で計算された、1のクリップインフォメーションファイルの最大サイズSIZE_1CLIPとが比較され、追記候補のプレイリストファイルに対して最大サイズSIZE_1CLIPのクリップインフォメーションファイルを追加可能であるか否かが判定される。
CLIP_SUM_MAX−SIZE_TOTAL_CLIP≧SIZE_1CLIP ・・・(6)
比較の結果、若し、1のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値が、1のクリップインフォメーションファイルの最大サイズSIZE_1CLIPよりも大きいと判定されれば、新規記録のクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断される。
一方、1のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値が、1のクリップインフォメーションファイルの最大サイズSIZE_1CLIPよりも小さければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
図49は、上述のステップS109の、制約(6)および制約(7)に対応した、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルに格納されるエントリポイントの合計数に基づく追記可否判断の一例の処理を示す。
既に説明したように、1のプレイリストファイルから参照されるクリップインフォメーションファイルに関し、ブロックblkEPMap()に格納されるエントリポイントの合計数に対して上限が設けられている。チャプタの追記により追記候補のプレイリストに対してクリップインフォメーションファイルが追加された際に、当該追記候補のプレイリストファイルに関連するクリップインフォメーションファイルに格納されるエントリポイントの合計数が、この上限値を超えないようにする必要がある。
なお、制約(6)および制約(7)によれば、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとのそれぞれに対して上限が設けられている。したがって、判定も、クリップインフォメーションファイルに格納される粗い単位で検索を行うエントリポイントおよび精密な単位で検索を行うエントリポイントのそれぞれについて、行う必要がある。
1のプレイリストファイルに関連しているクリップインフォメーションファイル内の、粗い単位で検索を行うエントリポイントの合計値の上限値MAX_EP_COARSEは、例えば24576個とされる。また、精密な単位で検索を行うエントリポイントの合計値の上限値MAX_EP_FINEは、例えば180000個とされる。
先ず、ステップS170で、予め計算しておいた1チャプタ当たりの最大エントリポイント数を取得する。上述したように、記録機の仕様として、一般的に、連続記録が保証される最低時間が設定される。この連続記録が保証される最低時間分の記録を行った際の、最大のエントリポイント数を予め計算しておき、このステップS170で、この値を取得する。
図25および図26を用いて説明したように、粗い単位で検索を行うエントリポイントは、11.5秒毎(PTS:エントリPTSEPCoarse)または25MB毎(ソースパケット番号:エントリSPNEPCoarse)に設けられる。ここで、連続記録が保証される最低時間を時間MIN_TIME(hr)、当該最低時間分の記録を行った場合に生成されるクリップAVストリームファイルのデータ量をデータ量MIN_SIZE(MB)とした場合、粗い単位で検索を行うエントリポイントについて、1チャプタ当たりの最大エントリポイント数NEEDED_EP_COARSEは、次式(7)により求められる。なお、式(7)および後述する式(8)において、「CEIL」は、括弧内の値について小数点を切り上げることを示す。
NEEDED_EP_COARSE=CEIL ( 3600[sec]×MIN_TIME[hr]÷11.5[sec] )+CEIL ( MIN_SIZE[MB]÷25[MB] ) ・・・(7)
また、精密な単位で検索を行うエントリポイントは、GOP毎に、PTSの精度(エントリPTSEPFine)またはソースパケットの精度(エントリSPNEPFine)で設けられる。この実施の一形態では、精密な単位で検索を行うエントリポイントとしてエントリPTSEPFineのみを用いるものとし、フレーム周波数を29.97Hz、1GOPが15フレームから構成されるとした場合、精密な単位で検索を行うエントリポイントについて、1チャプタ当たりの最大エントリポイント数NEEDED_EP_FINEは、次式(8)により求められる。なお、式(8)中、「90[kHz]÷3003」は、PTS精度に基づくフレーム周波数(29.97Hz)を示す。
NEEDED_EP_FINE=CEIL ( 3600[sec]×MIN_TIME[hr]×90[kHz]÷3003÷15[Frame/GOP] ) ・・・(8)
次のステップS171で、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルについて、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとをそれぞれ取得し、粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEと、精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとをそれぞれ求める。
より具体的には、クリップインフォメーションファイル内のフィールドNumberOfStreamPIDEntriesと、フィールドNumberOfEPCoarseEntries[k]およびフィールドNumberOfEPFineEntries[k]とに基づき、粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEと、精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとを求めることができる。
次のステップS172では、追記候補のプレイリストファイルに対してチャプタを追記した際に、粗い単位で検索を行うエントリポイントについて、上限値MAX_EP_COARSEを超えないか否かが判定される。すなわち、上述のステップS170で取得された、粗い単位で検索を行うエントリポイントの1チャプタ当たりの最大エントリポイント数NEEDED_EP_COARSEと、ステップS171で求められた粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEとを用いて、次式(9)に基づき判定がなされる。
MAX_EP_COARSE−TOTAL_EP_COARSE≧NEEDED_EP_COARSE ・・・(9)
若し、各値の関係がこの式(9)を満たしていない、すなわち、1チャプタ当たりの粗い単位で検索を行うエントリポイントの最大エントリポイント数NEEDED_EP_COARSEが、1のプレイリストファイルに関連するクリップインフォメーションファイルの粗い単位で検索を行うエントリポイントの合計値の上限値MAX_EP_COARSEと、追記候補のプレイリストファイルに関連するクリップインフォメーションファイルの粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEとの差分より大きければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
一方、各値の関係が式(9)を満たしていると判定されれば、処理は次のステップS173に移行される。ステップS173では、精密な単位で検索を行うエントリポイントについて、同様の判定がなされる。すなわち、上述のステップS170で取得された、精密な単位で検索を行うエントリポイントの1チャプタ当たりの最大エントリポイント数NEEDED_EP_FINEと、ステップS171で求められた精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとを用いて、粗い単位で検索を行うエントリポイントの上限値MAX_EP_FINEについて、次式(1)に基づき判定がなされる。
MAX_EP_FINE−TOTAL_EP_FINEE≧NEEDED_EP_FINE・・・(10)
若し、各値の関係がこの式(10)を満たしていないと判定されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、各値の関係がこの式(10)を満たしていると判定されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。
図50は、上述のステップS110の、制約(8)に対応した、追記候補とされたプレイリストファイル内における他機による独自の拡張データの有無に基づく追記可否判定の一例の処理を示す。
先ず、最初のステップS180で、追記候補のプレイリストファイルの拡張データから、AVCDHフォーマットに準拠した拡張データを検索する。
すなわち、図10を参照し、追記候補のプレイリストファイルのフィールドExtensionDataStartAddressの値が取得され、取得された値が"0"か否かが判断される(図示しない)。値が"0"でなければ、当該プレイリストファイル内に拡張データブロックblkExtensionData()が存在するので、フィールドExtensionDataStartAddressの値に基づきブロックblkExtensionData()が参照される。そして、図33を参照し、プレイリストファイル内の拡張データブロックblkPlayListExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionがAVCHDフォーマットに規定されている値になっているか否かを調べる。
次のステップS181では、ステップS180の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在するか否かが判断される。
すなわち、ステップS180の検索結果に基づき、追記候補のプレイリストファイル内のフィールドExtensionDataStartAddressの値が"0"であるか、若しくは、拡張データブロックblkPlayListExtensionData()内のフィールドExtDataTypeおよびフィールドExtDataVersionがAVCHDフォーマットに規定されている値ではない場合は、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在しないと判断される。この場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
一方、ステップS181で、ステップS180の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在すると判断されれば、処理はステップS182に移行される。ステップS182では、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データ以外に、さらに拡張データが存在するか否かが判断される。若し、存在すると判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
ステップS182で、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データ以外の拡張データが存在しないと判断されれば、処理はステップS183に移行される。ステップS183では、検索された、追記候補のプレイリストファイルの拡張データブロックblkPlayListExtensionData()のブロックblkMakersPrivateData()が参照され、自機のデータが検索される。すなわち、図35を参照し、ブロックblkMakersPrivateData()内のフィールドMakerIDおよびフィールドMakerModelCodeに基づき、自機を示すデータが検索される。
次のステップS184で、ステップS183の検索結果に基づく判断がなされる。ステップS184では、ステップS183の検索結果に基づき、若し、自機の拡張データが存在しないと判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、ステップS184で、ステップS183の検索結果に基づき自機の拡張データが存在すると判断されれば、処理はステップS185に移行される。
ステップS185では、ステップS183の検索結果に基づき、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在するか否かが判断される。すなわち、ブロックblkMakersPrivateData()内のフィールドMakerIDおよびフィールドMakerModelCodeに、自機を示すデータ以外のデータが存在すれば、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在すると判断することができる。
ステップS185で、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在すると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、ブロックblkMakersPrivateData()内に自機による拡張データのみが存在すると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。
なお、上述のステップS181では、追記候補のプレイリストファイルにAVCHDフォーマットに準拠した拡張データが存在しない場合に、チャプタの追記候補のプレイリストファイルに対する追記が不可であるとしていたが、これはこの例に限定されない。すなわち、記録機の仕様によっては、追記候補のプレイリストファイルに、拡張データブロックblkMakersPrivateDataが全く存在しない場合に、チャプタの追記候補のプレイリストファイルに対する追記が可能とすることも考えられる。
図51は、上述したステップS111の、制約(9)に対応した、追記候補のプレイリストファイルの最終更新者に基づく追記可否判定の一例の処理を示す。追記候補のプレイリストファイルの最終更新者が自機でない場合には、追記候補のプレイリストファイルにおけるタイトルやチャプタの概念が自機とは異なり、再生時に不都合が生じる可能性がある。追記候補のプレイリストファイルの最終更新者情報に基づき、最終更新者が自機である場合にのみ、追記候補のプレイリストファイルに対してチャプタの追記をするように制御することで、1のプレイリストファイル内でのタイトルやチャプタの概念の差異による不都合を回避することが可能である。
先ず、最初のステップS190で、追記候補のプレイリストファイルの拡張データから、AVCDHフォーマットに準拠した拡張データを検索する。そして、次のステップS191で、ステップS190の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在するか否かが判断される。なお、これらステップS190およびステップS191の処理は、図50を用いて説明したステップS180およびステップS181の処理と同一なので、繁雑さを避けるために詳細な説明を省略する。
ステップS191で、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在しないとされた場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
一方、ステップS191で、ステップS190の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、AVCHDフォーマットに準拠した拡張データが存在すると判断されれば、処理はステップS192に移行される。ステップS192では、追記候補のプレイリストファイルの最終更新者が確認される。すなわち、拡張データブロックblkPlayListExtensionData()のブロックblkPlayListMeta()が参照され、フィールドMakerIDおよびフィールドMakerModelCodeのデータが取得される。
ステップS192で追記候補のプレイリストファイルの最終更新者が確認されると、処理はステップS193に移行され、確認された最終更新者が自機であるか否かが判断される。すなわち、拡張データブロックblkPlayListExtensionData()のブロックblkPlayListMeta()におけるフィールドMakerIDおよびフィールドMakerModelCodeのデータが自機を示していれば、最終更新者が自機であると判断できる。
ステップS193で、追記候補のプレイリストファイルの最終更新者が自機であると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、追記候補のプレイリストファイルの最終更新者が自機ではないと判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
なお、最終更新者の情報は、インデックスファイルにも格納することができる。例えば、インデックスファイルにおける拡張データブロックblkIndexExtensionData()内のブロックblkMakersPrivateData()に最終更新者の情報を格納することが考えられる。この場合、このインデックスファイルに格納された最終更新者情報を用いて、この図51のフローチャートによる判断を行ってもよい。
上述した制約(10)の、規定時間以上の連続撮影および記録に関しては、図43のステップS108および図48を用いて説明したクリップインフォメーションファイルのファイルサイズに関する処理、ならびに、図43のステップS109および図49を用いて説明したクリップインフォメーションファイルにおけるエントリポイントに関する処理に含まれるため、詳細な説明を省略する。
上述では、図43を用いて説明した、追記候補のプレイリストファイルに対してチャプタを追記するか、新規にプレイリストファイルを作成するかの一連の判断を、記録媒体20が記録機に装填された際に行われるように説明したが、これはこの例に限定されない。例えば、チャプタの追記毎、例えば記録開始操作毎に判断を行うようにしてもよい。
次に、上述した図43〜図51を用いて説明した処理の結果、追記候補のプレイリストファイルに対してチャプタを追記する際の処理について説明する。図52は、プレイリストファイルに対してチャプタを追記する一例の処理を示すフローチャートである。
ステップS200で記録開始操作が行われると、次のステップS201で、クリップAVストリームの記録媒体20への記録が開始される。例えば、UI部31に設けられた記録開始を指示する記録開始スイッチが操作されることで、記録開始を指示する制御信号がUI部31から制御部30に供給され、制御部30により、この記録開始を指示する制御信号に基づき、記録部10の各部に対し、端子40から入力されるベースバンドのビデオデータと、端子41から入力されるベースバンドのオーディオデータとを記録媒体20に記録するように制御する。
記録開始の制御に応じて、クリップAVストリームが記録媒体20に記録される(ステップS201)。すなわち、入力されたビデオデータおよびオーディオデータがビデオエンコーダ11およびオーディオエンコーダ12でそれぞれ圧縮符号化され、マルチプレクサ13でパケット化されTSパケット(実際にはさらに所定のヘッダが付加されたソースパケット)とされてストリームバッファ14に供給される。ストリームバッファ14に所定量以上のTSパケットが溜め込まれたら、記録制御部15によりストリームバッファ14からTSパケットが読み出される。読み出されたTSパケットは、所定にファイル名が付されたクリップAVストリームファイルに格納されて記録媒体20に記録される。
例えば、記録媒体20に既にファイル名"00001.m2ts"であるクリップAVストリームファイルが記録されている場合には、新たに記録されるクリップAVストリームファイルのファイル名として既に記録されているファイルと重複しないファイル名が選ばれ、例えばファイル名"00002.m2ts"とされる。
なお、クリップAVストリームの記録媒体20への記録に伴い、管理情報処理部16により、記録されるデータの再生時間とアドレスとの対応関係を示す情報がリアルタイムに生成される。このデータは、上述したクリップインフォメーションファイル"zzzzz.clpi"内のブロックblkEPMap()に格納されるデータとして、揮発性メモリ17に記憶される。
次のステップS202で、記録停止操作が行われたか否かが判断される。例えば、ユーザによりUI部31に設けられた記録停止スイッチが操作され、記録が停止されたと判断されれば、処理はステップS203に移行される。一方、記録が停止されていなければ、処理はステップS201に戻され、クリップAVストリームの記録媒体20への記録が継続される。
ステップS203では、記録の停止に伴い、ストリームバッファ14に溜め込まれているストリームが全て記録媒体20に書き込まれる。例えば、記録制御部15は、制御部30からの記録停止の命令に応じて、ストリームバッファ14に溜め込まれているストリーム(TSパケット)を全て読み出し、記録媒体20に書き込む。
また、記録停止の命令に応じて、例えばビデオエンコーダ11およびオーディオエンコーダ12の動作が停止される。このとき、図13Aを用いて説明した第1のシームレス接続を行うために、例えば、オーディオエンコーダ12の動作がビデオエンコーダ11の動作が停止してから所定時間後に停止されるように制御される。
次のステップS204〜ステップS208で、管理情報処理部16により、記録媒体20に書き込まれたクリップAVストリームファイルに関するクリップインフォメーションファイルが生成されると共に、追記候補のプレイリストファイルの更新が成される。
先ず、ステップS204で、管理情報処理部16により、クリップインフォメーションファイル"zzzzz.clpi"が生成される。ファイル名は、例えばこのクリップインフォメーションファイルが示すクリップAVストリームファイルのファイル名と対応するファイル名とされ、当該クリップAVストリームファイルのファイル名が"00002.m2ts"であれば、このクリップインフォメーションファイルのファイル名は、拡張子より前の部分が同一のファイル名"00002.clpi"とされる。
クリップインフォメーションファイル"00002.clpi"に、図15〜図21に例示した各シンタクスに従い、各フィールドやフラグの値が所定に設定され格納される。一例として、TSパケットに関する情報や、再生時間(PTS)に関する情報は、管理情報処理部16により、クリップの記録中にマルチプレクサ13から取得された情報に基づき生成される。また、記録媒体20上の記録アドレスに関する情報は、管理情報処理部16により、クリップの記録中に記録制御部15から取得された情報に基づき生成される。システムにより固有の値は、例えば予めROM(図示しない)などに記憶されている情報に基づく。さらに、再生時間とアドレスとの対応関係を示す上述したブロックblkEPMap()の情報が、クリップインフォメーションファイル"00002.clpi"のブロックblkCPI()に格納される。
また、ブロックblkClipInfo()内のフラグIsCC5は、ユーザ操作によりクリップの記録が停止された場合、値が1(バイナリ値)とされる。それに伴い、ブロックblkClipInfo()内のif文(図16参照)で示されるデータが所定に設定される。
クリップインフォメーションファイルの作成が完了したら、処理は次のステップS205に移行する。ステップS205〜ステップS208の処理は、プレイリストファイルに関する処理である。このステップS205〜ステップS208の処理により、既に記録媒体20上に存在するプレイリストファイルに対して、新たに記録されたクリップAVストリームファイル"00002.m2ts"に対応するプレイアイテムが追加される。
先ず、ステップS205で、プレイリストファイル内のブロックblkPlayItem()におけるフィールドConnectionConditionの値が"5"に設定され、このクリップが次のクリップと第1のシームレス接続を行うことが示される(図12参照)。次にステップS206で、プレイアイテムファイルのフィールドNumberOfPlayItemsの値が"1"だけインクリメントされ、当該プレイリストに対してプレイアイテムが1つ、追加されることが示される(図11参照)。
次のステップS207で、ブロックblkPlayItem()におけるフィールドClipInformationFileName、フィールドINTimeおよびフィールドOUTTimeがそれぞれ設定され、クリップの記録に伴い追加されるブロックblkPlayItem()が作成される。フィールドClipInformationFileNameは、上述のステップS205で作成されたクリップインフォメーションファイルのファイル名"00002.clpi"が格納される。実際には、クリップインフォメーションファイルの拡張子は固定的とされているので、ピリオドの前の部分"00002"が格納される。フィールドINTimeおよびフィールドOUTTimeは、対応するクリップAVストリームファイル"00002.m2ts"に格納されるビデオストリームの先頭および終端の時間を示す情報であって、例えばクリップインフォメーションファイル"00002.clpi"内のブロックblkCPI()におけるブロックblkEPMap()の情報に基づく。
次のステップS208で、追記候補のプレイリストファイル内のブロックblkPlayListMark()におけるフィールドNumberOfPlayListMarksの値が"1"だけインクリメントされ、それに伴いforループ文内に追加されたフィールドMarkTimeStampの値が、上述のステップS207でブロックblkPlayItem()におけるフィールドINTimeの値に設定される。すなわち、新たに記録されたクリップの先頭に、プレイリストマークが打たれる。プレイリストマークが打たれることにより、チャプタが形成される。すなわち、これにより、追記候補のプレイリストファイルに対してチャプタが追記される。
このようにして、新たに記録されたクリップAVストリームファイル"00002.m2ts"に対して、クリップインフォメーションファイル"00002.clpi"が作成されると共に、追記候補のプレイリストファイルの更新がなされる。またこのとき、プレイリストファイルにおける拡張データブロックblkPlayListExtensionData()内のブロックblkPlayListMeta()の情報を更新するようにしてもよい。
なお、上述したステップS203によるストリームバッファ14に溜め込まれたデータの記録媒体20への書き込み処理は、ステップS208の処理の後に行うようにしてもよい。
プレイリストファイルを新規に作成してチャプタを形成する場合には、上述の処理のうち、ステップS205以下の処理が若干、異なることになる。すなわち、プレイリストファイルにおける各フィールドのデータは、それぞれ新規に生成されることになる。これに限らず、例えばプレイリストファイルのテンプレートを用意しておき、テンプレートのデータを変更することも考えられる。
次に、この発明の実施の一形態の他の例について説明する。上述では、この発明が単体の記録装置に適用された例について説明した(図41参照)。これに対し、この実施の一形態の他の例では、この発明を、撮像素子と、被写体からの光を撮像素子に入射させる光学系とを有し、撮像素子で撮像された撮像信号に基づきビデオデータを記録媒体に記録するようにした、ビデオカメラ装置に適用した。
図53は、この発明の実施の一形態の他の例によるビデオカメラ装置100の一例の構成を示す。ビデオカメラ装置100において、記録系の構成は、図41を用いて説明した記録装置の構成を略そのまま適用できるので、図41と共通する部分には同一の符号を付し、詳細な説明を省略する。
図53の構成において、カメラ部50は、映像信号に関する構成として、光学系51、撮像素子52、撮像信号処理部53、カメラ制御部54および表示部55を有し、音声信号に関する構成として、マイクロフォン(MIC)56および音声信号処理部57を有する。制御部30は、カメラ部50の各部との間で各種制御信号や情報のやりとりを行い、カメラ部50の動作を制御する。また、制御部50は、ユーザ操作に応じてUI部31から供給される制御信号に基づき、カメラ部50の動作を制御する。
なお、ビデオカメラ装置100として構成される場合、記録開始操作および記録停止操作は、例えば、UI部31に設けられた単一の記録スイッチを用い、当該記録スイッチが押下される毎に記録開始および記録停止が交互に指示されるようになされるのが一般的である。また、このビデオカメラ装置100では、記録媒体20として、記録可能なタイプのDVDやBlu−ray Discといった、ディスク記録媒体を適用するものとする。
カメラ部50において、光学系51は、被写体からの光を撮像素子52に導くためのレンズ系、絞り調整機構、フォーカス調整機構、ズーム機構、シャッタ機構などを備える。絞り調整機構、フォーカス調整機構、ズーム機構およびシャッタ機構の動作は、制御部30から供給される制御信号に基づき、カメラ制御部54により制御される。
撮像素子52は、例えばCCD(Charge Coupled Device)からなり、光学系51を介して照射された光を光電変換により電気信号に変換し、所定の信号処理を施し撮像信号として出力する。撮像信号処理部53は、撮像素子から出力された撮像信号に対して所定の信号処理を施し、ベースバンドのディジタルビデオデータとして出力する。
例えば撮像信号処理部53は、撮像素子52から出力された撮像信号に対して、CDS(Correlated Double Sampling)回路により画像情報を有する信号だけをサンプリングすると共に、ノイズを除去し、AGC(Auto Gain Control)回路によりゲインを調整する。そして、A/D変換によりディジタル信号に変換する。また、撮像信号処理部53は、このディジタル信号に対して検波系の信号処理を施し、R(赤色)、G(緑色)およびB(青色)各色の成分を取り出し、γ補正やホワイトバランス補正などの処理を行い、最終的に1本のベースバンドのディジタルビデオデータとして出力する。
また、撮像信号処理部53は、撮像素子52から出力された撮像信号の情報を制御部30に送る。制御部30は、この情報に基づき光学系51を制御するための制御信号を生成し、カメラ制御部54に供給する。カメラ制御部54は、この制御信号に基づきフォーカス調整機構や絞り調整機構などの制御を行う。
さらに、撮像信号処理部53は、撮像素子52から出力された撮像信号に基づき、例えばLCD(Liquid Crystal Display)を表示素子として用いた表示部55に映出させる映像信号を生成する。
一方、マイクロフォン56は、周囲の音声を収音して電気信号に変換して出力する。マイクロフォン56から出力された音声信号は、音声信号処理部57に供給される。音声信号処理部57は、供給された音声信号を、リミッタを介してからA/D変換を施してディジタルオーディオデータとし、ノイズ除去や音質補正など所定の音声信号処理を施してベースバンドのディジタルオーディオデータとして出力する。
カメラ部50の撮像信号処理部53から出力されたベースバンドのディジタルビデオデータは、記録部10の端子40に供給される。また、音声信号処理部57から出力されたベースバンドのディジタルオーディオデータは、記録部10の端子41に供給される。
撮影時に、記録媒体20がビデオカメラ装置100に所定に装填されると、図43を用いて説明した処理に従い、撮影して得られるビデオデータに基づくチャプタの追記候補のプレイリストファイルが特定されると共に、特定された追記候補のプレイリストファイルに対してチャプタを追記可能か否かが判断される。
例えば、制御部30の制御に基づき記録媒体20に記録されているインデックスファイルが読み込まれ、管理情報処理部16を介して揮発性メモリ17に記憶される。制御部30は、揮発性メモリ17に記憶されたインデックスファイルの情報に基づき追記候補のプレイリストファイルを特定し、記録制御部15に対して、当該追記候補のプレイリストファイルを記録媒体20から読み出すように命令を出す。この命令に基づき記録媒体20から読み出された追記候補のプレイリストファイルは、管理情報処理部16を介して揮発性メモリ17に記憶される。
制御部30は、揮発性メモリ17に記憶された追記候補のプレイリストファイルの情報に基づき、記録制御部15に対して、当該追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルを記録媒体20から読み出すように命令を出す。この命令に基づき記録媒体20から読み出されたクリップインフォメーションファイルは、揮発性メモリ17に記憶される。制御部30は、揮発性メモリ17に記憶された追記候補のプレイリストファイルと、当該追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルとに基づき、図43のフローチャートにおけるステップS104〜ステップS111までの各判断を行う。各判断の結果は、それぞれ、例えば制御部30のレジスタに保持される。
制御部30は、ステップS104〜ステップS111の各判断が終了すると、図43のステップS112の処理により、ステップS104〜ステップS111の各判断の判断結果に対して総合的な判断を行い、撮影され得られるビデオデータに基づくチャプタを追記候補のプレイリストファイルに追記するか否かを判断する。制御部30は、この判断結果に基づき、追記すると判断された場合は、チャプタを揮発性メモリ17に記憶されている追記候補のプレイリストファイルに対して追記し、追記しないと判断された場合は、新規にプレイリストファイルを生成してこの新規のプレイリストファイルに対して記録するように、管理情報処理部16を制御する。
記録停止状態からUI部31に設けられた記録スイッチが押下されると、記録開始を指示する制御信号がUI部31から制御部30に供給され、制御部30の制御に基づきカメラ部50から出力されたベースバンドのディジタルビデオ信号およびディジタルオーディオデータの記録媒体20への記録が開始される。
すなわち、既に説明したように、制御部30の制御に基づきビデオエンコーダ11およびオーディオエンコーダ12の動作が開始され、ビデオデータおよびオーディオデータがそれぞれビデオエンコーダ11およびオーディオエンコーダ12で圧縮符号化され、マルチプレクサ13で所定にパケット化され多重化されてAVストリームデータとされる。AVストリームデータは、ストリームバッファ14を介して、記録制御部15に供給され、クリップAVストリームファイルとして記録媒体20に記録される。
UI部31の記録スイッチが再び押下されると、記録が停止され、クリップインフォメーションファイルの作成や、プレイリストファイルの更新が行われる。管理情報処理部16は、マルチプレクサ13および記録制御部15からの情報に基づき、記録媒体20に記録されるクリップAVストリームファイルに対応するクリップインフォメーションファイルを作成すると共に、当該クリップインフォメーションファイルを参照するプレイアイテムを生成する。
追記候補のプレイリストファイルにチャプタを追記するように判断されている場合には、当該追記候補のプレイリストファイルに対して、生成されたプレイアイテムを追加すると共プレイリストマークを打ち、チャプタを形成する。追記候補のプレイリストファイルに対するチャプタの追加が不可と判断されている場合には、新規に作成されたプレイリストファイルに対して、生成されたプレイアイテムの追加およびプレイリストマークの設定を行う。
この状態からもう一度記録スイッチが押下されると、再び記録開始が指示され、新たなクリップAVストリームファイルの記録媒体20への記録が開始される。この再度の記録開始の際に、図43のフローチャートに従い再び追記候補のプレイリストファイルに対する新たな記録に基づくチャプタの追記可否判断を行うとよい。
なお、上述では、図41に示す記録装置や図53に示すビデオカメラ装置100の記録部10がハードウェア的に構成されるように説明したが、これはこの例に限定されない。すなわち、記録部10は、ソフトウェアとして構成することも可能である。この場合、ソフトウェアは、例えば制御部30が有する図示されないROMに予め記憶される。これに限らず、記録部10を、パーソナルコンピュータなどのコンピュータ装置上に構成することも可能である。この場合には、記録部10をコンピュータ装置に実行させるソフトウェアは、CD−ROMやDVD−ROMといった記録媒体に記録されて提供される。コンピュータ装置がネットワーク接続可能な場合、インターネットなどのネットワークを介して当該ソフトウェアを提供することも可能である。