以下、この発明の実施の一形態を、図面を参照しながら説明する。先ず、理解を容易とするために、この発明に適用可能な一例のフォーマット(以下、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"の実質的な内容であって、このブロックblkIndexes()に記述された内容により、ディスクをプレーヤに装填した際に再生されるファーストプレイバックや、トップメニューから呼び出されるタイトル(ムービーオブジェクト)が指定される。インデックステーブルにより呼び出されたムービーオブジェクト等に記述されたコマンドに基づき、後述するプレイリストファイルが読み込まれる。
図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の例では、フィールドtype_indicatiorに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()は、所定の拡張データを格納可能とするためのブロックである。
なお、この図10に示すシンタクス内のフィールドpadding_wordは、16ビットのデータ長を有し、このファイル"xxxxx.mpls"のシンタクスに従いforループ文に値N1、値N2および値N3で示される回数だけ挿入される。値N1、値N2または値N3は、0または任意の正の整数である。また、フィールドpadding_wordは、任意の値を用いることができる。
図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[0]で示されるファイル名のクリップインフォメーションファイルが読み出される。フィールドClipCodecIdentifier[0]は、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[0]は、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()およびクリップインフォメーションファイル内のブロックblkExtensionData()は、この発明との関連性が薄いので、詳細な説明を省略する。
図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は、ブロックblkSequenceInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkSequenceInfo()の最後までのデータ長を示す。15ビットのデータ長を有する領域reservedを介して、データ長が1ビットで固定値"1"が記述される。
次のフィールドSPNATCStartは、32ビットのデータ長を有し、連続した時間に記録されたことを表すシーケンス(シーケンスATCSequenceと呼ぶ)の開始をパケット番号で表す。この図17の例では、フィールドSPNATCStartは、値を"0"としてクリップAVストリームファイルの先頭と一致させている。フィールドNumberOfSTCSequenceは、シーケンスATCSequence上のシーケンスSTCSequenceの数を表す。フィールドNumberOfSTCSequenceは、値が"1"以上とされる。
次のforループ文に従い、フィールドNumberOfSTCSequenceで示される数だけ、シーケンスSTCSequenceの情報が記述される。シーケンスSTCSequenceは、MPEG2 TS(Transport Stream)における時間軸の基準であるPCR(Program Clock Reference)が連続な範囲を表す。シーケンスSTCSequenceには、クリップ内で一意な番号STC_idが割り当てられる。このシーケンスSTCSequence内では、不連続の無い一貫した時間軸を定義できるので、プレイアイテムの開始時刻および終了時刻を一意に定めることができる。つまり、各プレイアイテムの開始点と終了点は、同一のシーケンスSTCSequenceに存在していなければならない。このforループ文においては、値stc_idによりシーケンスSTCSequenceが指定される。
フィールドPCRPID[stc_id]は、16ビットのデータ長を有し、MPEG2 TSにおいて、PCR(Program Clock Reference)が含まれるTSパケットのPIDを表す。フィールドSPNSTCStart[stc_id]は、32ビットのデータ長を有し、シーケンスSTCSequenceの開始をパケット番号で表す。フィールドPresentationStartTimeおよびフィールドPresentationEndTimeは、それぞれ32ビットのデータ長を有し、クリップAVストリーム中の有効な範囲を表す。フィールドPresentationStartTimeおよびフィールドPresentationEndTimeで示される範囲がプレイアイテムから参照できる範囲となる。
図18は、ブロック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]で示されるエレメンタリストリームの符号化方式に関する情報が記述される。
例えば、ブロックblkStreamCodingInfo(stream_index)は、対応するエレメンタリストリームがビデオストリーム、オーディオストリーム、OBストリームおよびMBストリームの何れであるかの情報が記述され、ビデオストリームであれば、ビデオフォーマット、フレームレートおよびアスペクト比の情報がさらに記述される。
図19は、ブロックblkCPI()の一例の構造を表すシンタクスを示す。MPEGストリームのような、フレーム間圧縮を行っている符号化ストリームにおいては、デコード開始可能な箇所は、GOP(Group Of Picture)の先頭など一部の箇所に限定されていることが多い。CPI(Characteristic Point Information)とは、そのデコード可能な開始点の位置の情報を集めたデータベースで、再生時刻と、ファイル内アドレスとが対応付けられたテーブルになっている。すなわち、CPIは、デコード単位の先頭位置を示す情報がテーブル化されている。
このようにデータベースを定めることで、例えば、任意の時刻から再生したい場合、再生時刻を元にCPIを参照することによって再生位置のファイル内アドレスがわかる。このアドレスは、デコード単位の先頭となっているため、プレーヤは、そこからデータを読み出してデコードし、素早く画像を表示することができる。
なお、このCPIに格納される、デコード単位の先頭位置(この例ではGOPの先頭位置)を、EP(Entry Point)エントリと称する。
図19において、フィールドLengthは、32ビットのデータ長を有し、このフィールドLengthの直後からブロックblkCPI()の最後までのデータ長を示す。次のif文に従い、フィールドLengthの値が0でなければ、12ビットのデータ長を有する領域reservedを介してフィールドCPITypeが配される。フィールドCPITypeは、4ビットのデータ長を有し、CPIの種類を示す。次のブロックblkEPMap()は、対応するクリップAVストリームファイルにおけるPTS値とバイトアドレスとの関連付けを行うテーブルが格納される。
図20は、ブロック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と呼ぶ。
図21は、ブロック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から導かれる。
図22は、エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す。PTSすなわちエントリPTSEPStartは、データ長が33ビットの値である。MSBのビットを第32ビット、LSBのビットを第0ビットとするとき、この図22の例では、大まかな単位で検索を行う際に用いられるエントリ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ビットは、用いられない。
図23は、エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す。ソースパケット番号すなわちエントリSPNEPStartは、データ長が32ビットの値である。MSBのビットを第31ビット、LSBのビットを第0ビットとするとき、この図23の例では、大まかな単位で検索を行う際に用いられるエントリ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は、図22で示したように、データ長が33ビットの符号無し整数であり、AVストリーム中で、ランダムアクセスが可能なピクチャ(例えばIDR(Instantaneous Decoding Refresh)ピクチャやI(Intra)ピクチャ)から開始するビデオアクセスユニットの33ビット長のPTSを示す。
エントリSPNEPStartは、図23で示したように、32ビットの符号無し整数であり、エントリPTSEPStartに関連付けられたビデオアクセスユニットの第1バイト目を含むソースパケットの、AVストリームの中でのアドレスを示す。エントリSPNEPStartは、ソースパケット番号の単位で表され、AVストリームファイル中の最初のソースパケットから、値"0"を初期値として、ソースパケット毎に1ずつ増加する値としてカウントされる。
図21を参照し、ブロック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"の各ファイルに記述することができる。
図24は、ブロック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()から取り出される。
図25は、ブロック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層構造とすることで、複数の拡張データを格納することが可能となる。
次に、上述の拡張データの一例の作成方法および読み出し方法について説明する。図26は、ブロックblkExtensionData()にデータを書き込む際の一例の処理を示すフローチャートである。この図26は、ブロック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()の拡大は、システムに任され、システムがメモリアロケーションを適切に行うことでなされる。
図27は、ブロックblkExtensionData()から拡張データを読み出す際の一例の処理を示すフローチャートである。なお、この図27のフローチャートによる処理は、再生専用の記録媒体と、記録可能な記録媒体との両方に適用可能なものである。先ず、最初のステップ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"に対して定義される一例の拡張データブロックについて説明する。ここでは、プレイリスト毎に記録可能な記録媒体に特有の属性情報を付加するようにした、一例の拡張データブロックについて説明する。図28は、このプレイリスト属性を記述するための、ファイル"index.bdmv"内のフィールドblkExtensionData()におけるブロックDataBlock()(図24参照)の一例の構造を表すシンタクスを示す。この図28の例では、ブロックDataBlock()がブロックblkIndexExtensionData()として記述されている。
先ず、上述の図24を参照して、ブロックblkExtensionData()においてフィールドExtDataTypeを値"0x1000"、フィールドExtDataVersionを値"0x0100"とする。これらフィールドExtDataTypeおよびフィールドExtDataVersionに記述された値は、例えば再生装置側において、予めROM(Read Only Memory)などに記憶されたテーブルが参照されて識別される。ブロックDataBlock()内のフィールドExtDataStartAddressおよびフィールドExtDataLengthで示される領域に、ブロックblkIndexExtensionData()が格納される。
ブロックblkIndexExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ISO646に規定された符号化方式で符号化した4文字からなる文字列が記述される。この図28の例では、フィールド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()は、この発明と関連性が薄いので、説明を省略する。
図29は、上述したブロック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"とされる。
次に、仮想プレーヤについて、概略的に説明する。上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるROM(Read Only Memory)に予め記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにAVCHDフォーマットの規定に従った動作をさせることから、仮想プレーヤと称される。
図30は、この仮想プレーヤの動作を概略的に示す。図30Aは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると(ステップS30)、1のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される(ステップS31)。そして、次のステップS32で、ムービーオブジェクトなどに記述されたプログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
図30Bは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態(ステップS40)に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される(UO:User Operation)。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され(ステップS41)、次のステップS42で、ムービーオブジェクト実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図31を用いて説明する。UOなどにより、タイトル番号#1のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図2に示されるインデックステーブル(Index Table)を参照し、タイトル#1のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル#1のコンテンツ再生を実現するオブジェクトの番号が#1であったとすると、プレーヤは、ムービーオブジェクト#1の実行を開始する。
この図31の例では、ムービーオブジェクト#1に記述されたプログラムは2行からなり、1行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト#1の再生を開始する。プレイリスト#1は、1以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト#1中のプレイアイテムの再生が終了すると、ムービーオブジェクト#1の実行に戻り、2行目のコマンドが実行される。図31の例では、2行目のコマンドが"jump MenuTitle"であって、このコマンドが実行されインデックステーブルに記述されたメニュータイトル(MenuTitle)を実現するムービーオブジェクトの実行が開始される。
次に、この発明の実施の一形態について説明する。この発明では、記録されたビデオデータおよびオーディオデータの管理情報を、CPUのワークメモリとしての、揮発性のメモリであるRAM(Random Access Memory)上に一時的に保持すると共に、フラッシュメモリといった不揮発性メモリにも書き込み保持する。管理情報は、例えば、ビデオデータおよびオーディオデータによるクリップAVストリームファイルに対応するクリップインフォメーションファイルに格納される情報である。不揮発性メモリに書き込まれた管理情報は、所定のタイミング、例えば記録媒体の排出時や、記録機に対して電源OFFの操作がなされた場合などに、ビデオデータおよびオーディオデータが記録される記録媒体に書き込むようにする。
このように、記録されたビデオデータおよびオーディオデータの管理情報を不揮発性メモリに書き込み保持することで、記録機における電源が予期せず切断されたような場合に記録媒体を交換しないで電源ON操作を行うことで、当該記録媒体に記録されたビデオデータおよびオーディオデータの再生制御などを、不揮発性メモリに書き込まれた管理情報を用いて行うことができる。勿論、このときに、不揮発性メモリに書き込まれた管理情報を当該記録媒体に対して記録することもできる。
さらに、管理情報が不揮発性メモリに書き込まれた後に、記録媒体が交換されていなければ、当該記録媒体に記録されたビデオデータおよびオーディオデータの再生制御や編集作業を、不揮発性メモリに書き込まれた管理情報に基づき行うことができる。管理情報を一々記録媒体から読み出さないので、処理を高速に行うことができる。
なお、不揮発性メモリに書き込まれる管理情報は、クリップインフォメーションファイルに格納される情報のみに限られない。例えば、クリップインフォメーションファイルと共に、当該クリップインフォメーションファイルを参照するプレイアイテムを含むプレイリストファイルを、さらに管理情報として不揮発性メモリに書き込むようにしてもよい。
図32は、この発明の実施の一形態に適用可能な記録再生装置の一例の構成を概略的に示す。この図32に例示される記録再生装置は、外部から入力されるビデオデータおよびオーディオデータを記録媒体に記録し、記録媒体に記録されたビデオデータおよびオーディオデータを再生する、単独の記録再生装置として用いることもできるし、光学系や撮像素子などを備えたカメラブロックと組み合わせ、撮像した撮像信号に基づくビデオデータを記録媒体に記録する、ビデオカメラ装置の記録ブロックとして用いることもできる。
適用可能な圧縮符号化や多重化の方式としては、様々に考えられる。例えば、H.264|AVCに規定される方式を、この発明の実施の一形態の圧縮符号化として適用することができる。また、多重化方式は、例えばMPEG2システムズが適用される。
制御部30は、例えば図示されないCPU(Central Processing Unit)上で動作するプログラムであって、CPUに接続されるROM(Read Only Memory)に予め記憶されたプログラムやデータに基づき、同じくCPUに接続されるRAM(Random Access Memory)をワークメモリとして用いてこの記録装置の記録部10の各部を制御する。なお、制御部30と記録部10の各部とを接続する経路は、繁雑さを避けるために、図32では省略している。
制御部30上で動作するプログラムにより、この記録装置で用いられるファイルシステムが提供される。例えば、制御部30は、このファイルシステムに基づき、データが記録媒体20に記録される際の、記録媒体20の物理的なアドレスと当該データが格納されるファイルとの関連付けを行うと共に、各データが格納されるファイルの論理的な管理情報を生成する。上述した図6に示すディレクトリ構造は、ファイルの論理的な管理情報の一例である。新規ファイルの作成やファイルオープン、クローズは、ファイルシステム基づき制御部30により制御される。
UI(User Interface)部31は、この記録装置の動作をユーザが操作するための操作子が所定に設けられ、操作子に対する操作に応じた制御信号を出力する。この制御信号は、制御部30に供給される。制御部30は、ユーザ操作に応じてUI部31から供給された制御信号に基づきなされるプログラムの処理により、記録再生部10の各部の動作を制御する。また、UI部31は、簡易的な表示部を有し、所定の表示、例えば記録媒体32に記録されるタイトル情報などを表示することができるようになっている。
例えば、UI部31に対してなされた操作に応じて、記録再生装置による記録媒体32に対してデータを記録する動作の開始および停止の動作や、記録媒体32からデータを再生する再生動作が制御部30により制御される。また例えば、UI部31に対して、この記録再生装置の電源のON/OFFを指示するための電源スイッチが設けられる。
例えば、この電源スイッチに対する電源OFFの操作に応じて、記録再生装置の各部の停止準備がなされると共に、図示されない電源部が制御されて記録再生装置の各部に対する電源の供給が停止され、記録再生装置の動作が停止される。また例えば、電源ONの操作時には、電源部が制御され記録再生装置の各部に対する電源の供給が開始されると共に、電源が供給された各部において初期化処理など動作開始準備がなされる。
なお、電源スイッチに対する電源OFF操作による記録再生装置における電源切断は、正常な手順による電源切断である。正常な手順による電源切断の別の例としては、例えば記録再生装置がバッテリを電源として駆動される場合に、バッテリの容量が所定以下になった場合に、自動的に電源を切断する処理が考えられる。すなわち、記録再生装置のシステムによる所定の手順を経て電源が切断される場合が、正常な手順による電源切断である。例えば電源コードの引き抜きやバッテリパックの脱抜といった、記録再生装置のシステムが関わらない強制的な電源切断を、不意の電源切断と呼ぶことにする。
ビデオエンコーダ11は、複数フレームのビデオデータを格納可能なバッファメモリを有し、供給されたベースバンドのディジタルビデオデータをバッファメモリに溜め込んで、所定の方式で以て圧縮符号化する。H.264|AVCに規定される方式に準じて圧縮符号化がなされるこの例では、例えば、DCT(Discrete Cosine Transform)と画面内予測とによりフレーム内圧縮を行うと共に、動きベクトルを用いたフレーム間圧縮を行い、さらにエントロピー符号化を行い圧縮効率を高める。ビデオエンコーダ11で圧縮符号化されたディジタルビデオデータは、H.264|AVCエレメンタリストリーム(ES)として出力される。
ビデオデコーダ20は、複数フレームのビデオデータを格納可能なバッファメモリを有し、供給された圧縮ビデオデータをバッファメモリに溜め込んで、圧縮符号化方式に対応した復号化方式でデコードし、ベースバンドのディジタルビデオデータとして出力する。例えば、ビデオエンコーダ11がH.264|AVCに規定される方式に準じて圧縮符号化を行うこの例では、ビデオデコーダ20もビデオエンコーダ11に対応して、H.264|AVCに規定される方式に準じてデコード処理を行う。ビデオデコーダ20は、後述するマルチプレクサ/デマルチプレクサ13(以下、MUX/DEMUX13)で抽出される、DTS(Decoding Time Stamp)およびPTS(Presentation Time Stamp)で示される時刻に基づき、デコードおよび出力を行うことができる。ビデオデコーダ20でデコードされて得られたベースバンドのディジタルビデオデータは、端子42から出力される。
オーディオエンコーダ12は、端子41から供給されたベースバンドのディジタルオーディオデータを所定の圧縮符号化方式、例えばAC3(Audio Code number 3)方式により圧縮符号化する。オーディオデータの圧縮符号化方式は、AC3方式に限られるものではない。オーディオデータを圧縮符号化せず、ベースバンドのデータのまま用いることも考えられる。
オーディオデコーダ21は、供給された圧縮オーディオデータを圧縮符号化方式に対応した復号化方式でデコードし、ベースバンドのディジタルオーディオデータとして出力する。オーディオエンコーダ12がドルビーディジタル方式により圧縮符号化されるこの例では、オーディオデコーダ21もオーディオエンコーダ12に対応して、ドルビーディジタル方式に準じた復号化方式でデコードがなされる。デコードされたオーディオデータは、ビデオデコーダ20から出力されるビデオデータと同期的に、端子43から出力される。
MUX/DEMUX13は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、1本のデータストリームとして出力するマルチプレクサ機能と、ディジタルビデオデータとディジタルオーディオデータとが所定に多重化されたデータストリームから、ディジタルビデオデータとディジタルオーディオデータとを分離してそれぞれ取り出す、デマルチプレクサ機能とを有する。
マルチプレクサ機能は、例えば、MPEG2システムズに準じて多重化が行われるこの例では、MPEG2のトランスポートストリームを用いて、供給された圧縮ビデオデータおよび圧縮オーディオデータを時分割で多重化する。例えば、MUX/DEMUX13は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータを一旦バッファメモリに格納する。バッファメモリに格納された圧縮ビデオデータは、所定サイズ毎に分割されヘッダが付加されて、PES(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてPESパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すPTSや復号時刻を示すDTSといった、MPEG2システムズに規定される所定の情報が格納される。PESパケットは、さらに分割されてトランスポートパケット(TSパケット)のペイロードに詰め込まれる。TSパケットのヘッダには、ペイロードに詰め込まれたデータ種別などを識別するためのPID(Packet Identification)が格納される。TSパケットに対してさらに所定データ長のヘッダが付加され、ソースパケットが形成される。
デマルチプレクサ機能は、マルチプレクサ機能と逆の処理を行い、パケットから圧縮ビデオデータおよび圧縮オーディオデータを抽出する。例えば、供給されたソースパケットからヘッダを分離してTSパケットとし、TSパケットのヘッダからPIDを検出し、TSパケットをペイロードに格納されるデータ種別毎に振り分ける。そして、振り分けられたTSパケットのそれぞれについて、ペイロードに格納されたデータを取り出し、PESパケットを再構築する。さらに、PESパケットのペイロードに格納された圧縮ビデオデータや圧縮オーディオデータを取り出し、PESヘッダに格納された情報などに基づきヘッダ情報などを付加し、それぞれ1本のエレメンタリストリームとして出力する。
ストリームバッファ14は、MUX/DEMUX13(記録時)または記録再生制御部15(再生時)から供給されたソースパケットを一時的に格納する。ストリームバッファ14に対するソースパケットの読み書きのタイミングを所定に制御することで、記録媒体32に対するアクセス速度と、オーディオおよびビデオデータエンコードやデコードなどの信号処理速度との間の整合性をとる。
記録再生制御部15は、記録媒体32に対するデータの記録と、記録媒体32からのデータの再生を制御する。すなわち、記録再生制御部15は、例えば制御部30といった上位からの命令に基づき、指定されたアドレスに対するデータの書き込みや、指定されたアドレスからのデータの読み出しを行う。
記録媒体32としては、例えば記録可能なタイプのDVD(Digital Versatile Disc)を用いることができる。これに限らず、記録媒体32としてハードディスクドライブを用いてもよいし、半導体メモリを記録媒体32に適用することも可能である。また、記録媒体32として、より大容量を実現したBlu−ray Disc(ブルーレイディスク:登録商標)を適用することも考えられる。
記録媒体32が記録再生装置に対して脱着可能な記録媒体である場合、少なくとも当該記録媒体32の排出動作は、制御部30の制御に基づきなされる。例えば、UI部31や、記録再生装置の筐体の他の部分に設けられたイジェクトボタンの操作に応じて、制御部30により記録媒体32の排出機構(図示しない)が制御され、記録媒体32が排出される。さらに、当該記録媒体32の記録再生装置に対する装填動作を制御部30の制御に基づき行うようにしてもよい。
管理情報処理部16は、上述したインデックスファイル("index.bdmv")、ムービーオブジェクトファイル("MovieObject.bdmv")、プレイリストファイル("xxxxx.mpls")およびクリップインフォメーションファイル("zzzzz.clpi")に関する処理を行う。
管理情報処理部16は、例えば、上述した制御部30と共に、CPU上で動作するプログラムにより機能が実現される。勿論、管理情報処理部16を制御部30とは異なるハードウェアで構成することも可能である。管理情報処理部16が制御部30上で動作するプログラムで実現される場合、制御部30が有するRAMが揮発性メモリ17に対応し、不揮発性メモリ18が制御部30に接続される。
不揮発性メモリ18は、記録再生装置のシステムからの電源供給が無くても記憶した情報が保存されるメモリであって、例えばフラッシュメモリを用いることができる。これに限らず、DRAMなどの揮発性メモリに内蔵の電池などで電源を常時供給し、記録再生装置自身の電源をOFFとしても記憶内容を保持できるようにして、不揮発性メモリ18を構成することもできる。
このような構成を有する記録再生装置における、この発明の実施の一形態による記録時の動作について説明する。ベースバンドのディジタルビデオデータが端子40から記録再生部10に入力され、ビデオエンコーダ11に供給される。例えば、UI部31に対して記録開始の操作がなされると、ビデオエンコーダ11は、供給されたディジタルビデオデータの圧縮符号化を開始する。ビデオエンコーダ11は、ベースバンドのディジタルビデオデータを圧縮符号化してH.264|AVCのエレメンタリストリーム(ES)として出力する。このエレメンタリストリームは、MUX/DEMUX13に供給される。
ベースバンドのディジタルオーディオデータが端子41から記録再生部10に入力され、オーディオエンコーダ12に供給される。オーディオエンコーダ12は、上述のUI部31に対する記録開始の操作に応じたタイミングで供給されたオーディオデータの圧縮符号化を開始する。オーディオエンコーダ12で圧縮符号化されたディジタルオーディオデータは、MUX/DEMUX13に供給される。
MUX/DEMUX13は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、1本のデータストリームとして出力する。例えば、MUX/DEMUX13は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータを一旦バッファメモリに格納する。
バッファメモリに格納された圧縮ビデオデータは、所定構造毎に分割されヘッダが付加されて、PESパケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてPESパケット化される。ヘッダには、PTSやDTSといった、MPEG2システムズに規定される所定の情報が格納される。PESパケットは、さらに分割されてトランスポートパケット(TSパケット)のペイロードに詰め込まれ、ペイロードに詰め込まれたデータを識別するためのPIDがヘッダに格納される。TSパケットに対して、ソースパケットを識別するためのソースパケット番号などが格納される所定長のヘッダがさらに付加され、ソースパケットが形成される。MUX/DEMUX13から出力されたソースパケットは、ストリームバッファ14に一旦溜め込まれる。
記録制御部15は、ストリームバッファ14に溜め込まれたデータ量を監視し、ストリームバッファ14に所定量以上のデータが溜め込まれると、ストリームバッファ14から記録媒体32の記録単位毎にデータを読み出して記録媒体32に書き込む。
管理情報処理部16は、記録データに基づき、揮発性メモリ17をワークメモリとして用いて、上述したインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルおよびクリップインフォメーションファイルに格納するための情報を生成する。
この発明の実施の一形態では、管理情報処理部16で生成された情報のうち少なくともクリップインフォメーションファイルに格納される情報は、揮発性メモリ17に保持されると共に、その一部または全部が不揮発性メモリ18に書き込まれる。
一例として、管理情報処理部16は、制御部30の制御に従い、制御部30、MUX/DEMUX13および記録再生制御部15から供給される情報に基づき、揮発性メモリ17をワークメモリとして用いながら、記録中のクリップAVストリームファイルに対応するクリップ情報を生成する。クリップ情報は、換言すれば、クリップインフォメーションファイルを作成するために必要な情報である。生成された情報は、揮発性メモリ17上に保持されると共に、その一部または全部が不揮発性メモリ18に所定に書き込まれる。
なお、不揮発性メモリ18は、例えば512バイトといった比較的大きな記録単位でデータの書き込みがなさる場合が多い。そのため、例えば揮発性メモリ17において、不揮発性メモリ18の記録単位に対応したブロック単位でアドレス管理を行い、揮発性メモリ17からこのブロック単位でデータを読み出して、不揮発性メモリ18にデータを書き込むことが考えられる。
ここで、クリップインフォメーションファイルに格納される情報のうちブロックblkCPI()内のEPエントリは、記録に対して動的な情報であって、記録の経過に伴い順次、生成される情報である。管理情報処理部16は、MUX/DEMUX13から、ビデオアクセスユニットのPTSと、ビデオアクセスユニットの第1バイト目を含むソースパケットのソースパケット番号とを取得し、揮発性メモリ17をワークメモリとして用いてエントリPTSEPStartおよびエントリSPNEPStartを生成する。生成されたエントリPTSEPStartおよびエントリSPNEPStartは、揮発性メモリ17上に保持されると共に、不揮発性メモリ18に書き込まれる。
すなわち、不揮発性メモリ18に書き込まれた情報は、エントリPTSEPStartおよびエントリSPNEPStartの生成毎に更新されることになる。これに限らず、不揮発性メモリ18に書き込まれた情報を、例えば所定数のエントリPTSEPStartおよびエントリSPNEPStartの生成毎に更新するようにしてもよい。
一方、クリップインフォメーションファイルに格納される情報のうち、記録に対して固定的な情報は、クリップAVストリームファイルの記録終了時に不揮発性メモリ18に書き込めばよい。例えば、UI部31に対して記録停止操作がなされ、記録停止操作に応じてビデオエンコーダ11およびオーディオエンコーダ12の動作が停止され、ストリームバッファ14に溜め込まれたソースパケットが全て記録媒体32に記録された後に、このクリップインフォメーションファイルに格納されるべき固定的な情報が不揮発性メモリ18に書き込まれる。
上述したEPエントリのような、クリップインフォメーションファイルに格納される情報のうち、記録に対して動的な情報の例としては、ブロックblkClipInfo()内のフィールドNumberOfSourcePackets(図16参照)、ブロックblkSequenceInfo()内のフィールドNumberOfSTCSequence、forループ文内に記述されるフィールドPCRPID、フィールドSPNSTCStart、フィールドPresentationStartTimeおよびフィールドPresentationEndTime(図17参照)、ブロックblkProgramInfo()内のフィールドNumberOfStreamInPS、forループ文内に記述されるフィールドStreamPID(図18参照)などが挙げられる。なお、これらのような動的な情報であっても、例えばフィールドNumberOfSourcePackets、フィールドNumberOfSTCSequence、フィールドNumberOfStreamInPSのような、1のクリップAVストリームファイルの生成に伴い、単純に所定の値をカウントして得られるような情報は、クリップAVストリームファイルの記録停止時点において固定値として扱うことが可能である。
この記録再生装置が記録開始に伴い記録開始位置にプレイリストマークを設けるようにされている場合、UI部31に対する記録開始操作に応じて生成される先頭のフレームに対応する再生時刻をフィールドMarkTimeStampの値として持つプレイリストマークが、管理情報処理部16において作成される。作成されたプレイリストマークは、揮発性メモリ17上のプレイリストファイルに格納される情報に対して追加され保持される。
不揮発性メモリ18に記憶されたクリップ情報は、所定のタイミングで記録媒体32に書き込まれる。例えば、記録媒体32が記録再生装置に対して脱着可能な記録媒体であれば、記録媒体32の記録再生装置からの排出時に、不揮発性メモリ18の記憶内容の記録媒体32への書き出しを行うようにできる。
例えば、図示されないイジェクトボタンの操作に応じて、制御部30により管理情報処理部16が制御され、不揮発性メモリ18に記憶されたクリップ情報が不揮発性メモリ18から読み出される。管理情報処理部16は、不揮発性メモリ18から読み出されたクリップ情報に基づきクリップインフォメーションファイルを作成し、MUX/DEMUX13およびストリームバッファ14を介して、若しくは、管理情報処理部16から直接的に記録再生制御部15に供給する。記録再生制御部15は、供給されたクリップインフォメーションファイルを記録媒体32に書き込む。これら不揮発性メモリ18から読み出されたクリップ情報に基づくクリップインフォメーションファイルの記録媒体32への書き込みが終了したら、制御部30により記録媒体32の排出機構が制御され、記録媒体32が記録再生装置から排出される。
なお、不揮発性メモリ18に記憶されたクリップ情報が、記録媒体32の排出動作に伴いクリップインフォメーションファイルとして記録媒体32に書き込まれたら、当該クリップ情報は、不揮発性メモリ18から削除される。
記録媒体32の排出が行われていない場合、不揮発性メモリ18に記憶された情報の記録媒体32への書き出しを、電源OFF操作時にも行うようにできる。例えば、図示されない電源スイッチに対して電源OFFの操作がなされたら、制御部30により管理情報処理部16が制御され、上述と同様にして、不揮発性メモリ18に記憶されたクリップ情報が不揮発性メモリ18から読み出され、管理情報処理部16によりクリップインフォメーションファイルとされて所定に記録再生制御部15に供給され、記録媒体32に書き込まれる。これら不揮発性メモリ18から読み出されたクリップ情報に基づくクリップインフォメーションファイルの記録媒体32への書き込みが終了したら、制御部30により図示されない電源部や記録再生装置の各部が制御され、記録再生装置の動作が停止される。
なお、不揮発性メモリ18に記憶されたクリップ情報が、電源OFF操作に伴いクリップインフォメーションファイルとして記録媒体32に書き込まれた場合には、当該クリップ情報は、不揮発性メモリ18から削除されない。
再生時の動作について説明する。記録媒体32が例えば記録再生装置に対して装填されると、記録媒体32から、インデックスファイル、ムービーオブジェクトファイルが読み込まれ、管理情報処理部16に渡される。管理情報処理部16は、これらのファイルに格納される情報を、揮発性メモリ17に記憶する。
制御部30は、管理情報処理部16から揮発性メモリ17に記憶された情報を取得し、取得された情報に基づき、例えば、UI部31が有する表示部に対して記録媒体32に記録されているクリップに関する情報を表示させる。ユーザは、この表示に基づきUI部31に対して所定の操作を行うことで、記録媒体32に記録されているクリップの再生を指示することができる。
制御部30は、UI部31に対する操作に応じて管理情報処理部16および記録再生制御部15を制御し、揮発性メモリ17に記憶されているインデックスファイルの情報を参照してムービーオブジェクトファイルに記述されるコマンドを呼び出し、コマンドに記述されるプレイリストファイルを記録媒体32から読み出す。そして、読み出されたプレイリストファイルに基づき当該プレイリストファイルに格納されるプレイアイテムに参照されるクリップインフォメーションファイルを記録媒体32から読み出す。記録媒体32から読み出されたこれらプレイリストファイルおよびクリップインフォメーションファイルに格納される情報は、揮発性メモリ17に記憶される。
また、記録媒体32から読み出されたクリップインフォメーションファイルに格納されるクリップ情報は、不揮発性メモリ18にも書き込まれる。
なお、記録媒体32に、プレイリストファイルから参照されるべきクリップインフォメーションファイルが存在しない場合があり得る。例えば、記録中に、正常な電源OFF操作にによる手順を経ずに、何らかの原因で記録再生装置の各部に対する電源の供給が不意に停止されたような場合が考えられる。この場合、不揮発性メモリ18に記憶されたクリップインフォメーションファイルが記録媒体32に対して書き出されないことになり、プレイリストファイル内のプレイアイテムから参照されるべきクリップインフォメーションファイルが記録媒体32に記録されていないことになる。
読み出すべきクリップインフォメーションファイルが記録媒体32上に存在しない場合、制御部30は、不揮発性メモリ18の記憶内容を参照し、対応するクリップ情報が記憶されていれば当該クリップ情報を読み出し、揮発性メモリ17に書き込む。そして、揮発性メモリ17に書き込まれたこのクリップ情報を用いて、対応するクリップAVストリームファイルの再生制御を行うようにする。
なお、記録媒体32に、プレイリストファイルから参照されるべきクリップインフォメーションファイルが存在せず、不揮発性メモリ18に記憶されるクリップ情報を用いる場合、不揮発性メモリ18に記憶されているクリップ情報と、記録媒体32とが対応しているか否かを照合する手段を設けると、好ましい。例えば、記録媒体32に対して固有の識別情報を記録するようにし、当該記録媒体32に対するクリップAVストリームの記録中に生成されるクリップ情報を不揮発性メモリ18に書き込む際に、当該記録媒体32の識別情報と対応する識別情報を当該クリップ情報に関連付けて、不揮発性メモリ18に書き込む。不揮発性メモリ18に記憶されるクリップ情報を用いる際に、当該クリップ情報に関連付けられた識別情報と、記録媒体32に固有の識別情報とを照合するようにする。
制御部30は、揮発性メモリ17上に記憶されたクリップインフォメーションファイルに基づき、対応するクリップAVストリームファイルを読み出すように命令を出す。記録再生制御部15は、この命令に従い、記録媒体32からクリップインフォメーションファイルとクリップAVストリームファイルとを読み出す。クリップAVストリームファイルは、記録媒体32からソースパケット単位で読み出され、記録再生制御部15を介してストリームバッファ14に溜め込まれる。
MUX/DEMUX13は、ストリームバッファ14に溜め込まれたデータ量を監視し、ストリームバッファ14に所定量以上のソースパケットが溜め込まれると、ストリームバッファ14からビデオデコーダ20がデコードに必要とする分のデータを、ソースパケット単位で読み出す。読み出されたソースパケットは、MUX/DEMUX13に供給されバッファメモリに一旦格納され、ヘッダを分離されTSパケットとされる。そして、TSパケットのPIDに基づきデータ種類毎に振り分けられペイロードに格納されたデータからPESパケットが再構築される。さらに、PESパケットのペイロードからデータが取り出されると共に、PESヘッダの情報に基づき、DTSやPTSといったデコードや再生の時刻を指定する情報など、所定にヘッダ情報などが付加され、圧縮符号化されたビデオデータおよびオーディオデータのエレメンタリストリームがそれぞれ生成される。
圧縮ビデオデータは、ビデオデコーダ20に供給される。ビデオデコーダ20は、供給された圧縮ビデオデータをバッファメモリに溜め込み、所定ピクチャ分のデータが溜め込まれたら、バッファメモリに溜め込まれたデータに対してデコード処理を開始する。デコードされたビデオデータは、例えば図示されないシステムクロックから供給されるSTC(System Time Clock)に基づき、PTSに従いフレームタイミングで順次出力される。
一方、圧縮オーディオデータは、オーディオデコーダ21に供給され、所定にデコード処理がなされる。デコードされたオーディオデータは、ビデオデコーダ20から出力されるビデオデータと同期的に、オーディオデコーダ21から出力される。
次に、図33のフローチャートと、上述した図32のブロック図とを用いて、この発明の実施の一形態によるクリップインフォメーションファイルの一例の記録方法について説明する。なお、ここでは、記録媒体32が記録可能なタイプのDVDであるものとし、ディスクと呼ぶことにする。
ステップS30で、ディスクが記録再生装置に装填される。例えばUI部31に対して記録開始操作がなされると(ステップS31)、制御部30により記録再生装置の各部が制御され、端子40から入力されるビデオデータと、端子41から入力されるオーディオデータのディスクに対する記録が開始される。
すなわち、ビデオデータおよびオーディオデータは、ビデオエンコーダ11およびオーディオエンコーダ12でそれぞれエンコードされ、ビデオストリームデータおよびオーディオストリームデータとされ、MUX/DEMUX13に供給される。MUX/DEMUX13は、供給されたストリームデータのそれぞれPESパケット化し、PESパケットを所定サイズに分割してPIDをそれぞれ付加してTSパケットとし、さらに、所定サイズのヘッダを付加してソースパケット化する。ソースパケットは、ストリームバッファ14に一旦溜め込まれてから記録再生制御部15に供給され、クリップAVストリームファイルとしてディスクに記録される。
クリップAVストリームファイルのディスクへの記録と並行して、管理情報処理部16は、MUX/DEMUX13から時刻情報およびパケット情報を取得し、取得された情報に基づき、揮発性メモリ17をワークメモリとして用いてEPエントリを生成する(ステップS32)。生成されたEPエントリは、揮発性メモリ17上に保持される。また、生成されたEPエントリは、不揮発性メモリ18の所定の領域に書き込まれる(ステップS33)。このとき、不揮発性メモリ18上のEPエントリと、対応するクリップAVストリームファイルと、記録中のディスクとを関連付ける情報を生成して、不揮発性メモリ18などに書き込むとよい。記録停止操作がなされるまで記録が継続され、EPエントリの生成および生成されたEPエントリの不揮発性メモリ18への書き込みが繰り返される(ステップS34)。
なお、ここでは、EPエントリの不揮発性メモリ18への書き込みが、EPエントリが生成される度に行われるように説明したが、これはこの例に限定されない。例えば、揮発性メモリ17に保持されるEPエントリ数の所定数毎や、記録の所定時間毎に、EPエントリを不揮発性メモリ18に書き込むようにできる。一例として、10秒や1分といった所定時間間隔で、揮発性メモリ17上のEPエントリを不揮発性メモリ18に書き込むことが考えられる。
UI部31に対して記録停止操作がなされると(ステップS34)、処理はステップS35に移行され、クリップインフォメーションファイルに格納される固定的な情報が生成される。また、1のクリップAVストリームファイルにおける所定の値をカウントした情報といった、記録停止時に確定される情報も、このステップS35で生成される。ステップS35では、これらの情報を揮発性メモリ17をワークメモリとして用いて生成し、生成された情報を揮発性メモリ17上に保持する。ステップS35で生成された情報は、次のステップS36で、不揮発性メモリ18の所定の領域に書き込まれる(ステップS36)。このとき、不揮発性メモリ18上の当該情報と、対応するクリップAVストリームファイルと、記録中のディスクとを関連付ける情報を生成して、不揮発性メモリ18などに書き込むとよい。
記録停止操作後に、ディスクのイジェクト操作がなされた場合(ステップS37)、処理はステップS38に移行され、不揮発性メモリ18に書き込まれた情報がクリップインフォメーションファイルとしてディスクに書き出される。例えば、図示されないイジェクトボタンに対するイジェクト操作に応じた制御部30の制御に基づき、管理情報処理部16は、不揮発性メモリ18に書き込まれている情報を読み出してクリップインフォメーションファイルを作成し、所定に記録再生制御部15に供給してディスクに書き込む。
不揮発性メモリ18に書き込まれた情報がディスクに書き出されたら、ステップS39で、不揮発性メモリ18の記憶内容がクリアされる。そして、制御部30によりディスクの排出機構が制御され、記録再生装置からディスクが排出される(ステップS40)。電源OFF操作がなされたら(ステップS41)、処理はステップS42に移行され、図示されない電源部からの記録再生装置の各部に対する電源供給停止など、所定の動作停止処理がなされる。電源OFF操作を行わない場合、処理をステップS30に戻し別のディスクを装填して記録を開始することができる。
一方、ディスクのイジェクト操作を行わずに電源OFF操作を行うこともできる。すなわち、上述のステップS37において、記録停止操作後にイジェクト操作が行われず、且つ、電源OFF操作が行われた場合(ステップS43)、処理はステップS44に移行され、不揮発性メモリ18に書き込まれた情報がクリップインフォメーションファイルとしてディスクに書き出される。その後、処理がステップS42に移行され、所定の動作停止処理がなされる。
ステップS43で、電源OFF操作を行わない場合、処理をステップS31に戻し、現在装填されているディスクに対して記録を開始させることができる。この場合、クリップAVストリームファイルが新規に作成されることになる。また、この新規に作成されるクリップAVストリームファイルに対応するクリップインフォメーションファイルに格納されるクリップ情報は、不揮発性メモリ18に対し、前回作成されたクリップAVストリームファイルに対応するクリップ情報とは異なる領域に書き込まれる。
この図33に示す処理によれば、例えばステップS34の記録停止操作を行い、ステップS35およびステップS36により、クリップインフォメーションファイルに格納されるクリップ情報が不揮発性メモリ18に書き込まれた後であれば、電源OFF操作によらず不意に電源が切断されても、クリップ情報が不揮発性メモリ18上に保持されている。そのため、次に電源ONにした際に、不揮発性メモリ18上に保持されているクリップ情報を用いて、ディスクに記録されているクリップAVストリームファイルの再生制御を行うことができる。
また、ステップS34の記録停止操作以前に、不意の電源切断が生じた場合でも、電源切断の直前の記録までに生成されたEPエントリ情報が不揮発性メモリ18上に保持されている(ステップS32およびステップS33)ので、次に電源ONした際に、不揮発性メモリ18上に保持されているEPエントリ情報を用いて、ディスクに記録されているクリップAVストリームファイルの再生制御を行うことが可能である。
図34は、この発明の実施の一形態による記録再生装置におけるディスクの一例の再生処理を示すフローチャートである。前回の装置停止時においてディスクが装填されたままの状態でなければ、先ず、記録再生装置にディスクが装填される(ステップS50)。次のステップS51で、ディスクに記録されているインデックスファイルおよびムービーオブジェクトファイルが読み出される。制御部30は、管理情報処理部16からインデックスファイルの情報を取得し、取得された情報に基づき、例えばUI部31に設けられる図示されない表示部にタイトル情報を表示させる。この表示に基づきユーザによりUI部31が操作され、再生するタイトルが指示される(ステップS52)。
再生するタイトルが指示されると、ムービーオブジェクトファイルから当該タイトルにリンクするムービーオブジェクトが参照され、ナビゲーションコマンドに基づきプレイリストファイルがディスクから読み出され(ステップS53)、プレイリストファイルの記述に従いクリップAVストリームファイルの再生が開始される。すなわち、プレイリストファイルに記述されるプレイアイテムから参照されるクリップインフォメーションファイルがディスクから読み出され、クリップインフォメーションファイルの情報に基づき、対応するクリップAVストリームファイルが再生される。
ステップS54で、プレイリストファイルに記述されるプレイアイテムから参照されるクリップインフォメーションファイルが、ディスクに記録されているか否かが判断される(ステップS54)。若し、記録されていると判断されれば、処理はステップS55に移行し、ディスクから当該クリップインフォメーションファイルが読み出される。読み出されたクリップインフォメーションファイルに格納されるクリップ情報は、ステップS56で、不揮発性メモリ18に書き込まれる。このクリップ情報は、揮発性メモリ17にも書き込まれる(ステップS57)。そして、揮発性メモリ17に書き込まれたクリップ情報に基づき、対応するクリップAVストリームファイルの再生制御がなされる(ステップS58)。
一方、上述のステップS54で、現在再生しようとしているプレイアイテムから参照されるクリップインフォメーションファイルがディスクに記録されていないと判断された場合、処理はステップS59に移行される。例えば、記録停止操作後に、正常な手順を踏まず、不意に電源が切断されたような場合、不揮発性メモリ18上に書き込まれているクリップ情報がクリップインフォメーションファイルとしてディスクに書き出されずに、記録再生装置の動作が停止してしまう。記録中に不意に電源が切断された場合も、同様である。
ステップS59では、不揮発性メモリ18の記憶内容が参照される。そして、不揮発性メモリ18に記憶されているクリップ情報が、現在再生しようとしているプレイアイテムから参照されるクリップインフォメーションファイルに格納されるべきクリップ情報に対応しているか否かが判断される。若し、対応していると判断されれば、処理はステップS57に移行され、不揮発性メモリ18上のクリップ情報を揮発性メモリ17に書き込み、揮発性メモリ17に書き込まれた当該クリップ情報に基づきクリップAVストリームファイルの再生制御がなされる。
一方、ステップS60で、不揮発性メモリ18に記憶されているクリップ情報が、現在再生しようとしているプレイアイテムから参照されるクリップインフォメーションファイルに格納されるべきクリップ情報に対応していないと判断されれば、処理はステップS61に移行され、エラー処理がなされる。なお、上述のステップS59において、不揮発性メモリ18にクリップ情報が何も記憶されていないとされた場合にも、処理をステップS61に移行させエラー処理とすることができる。
この発明の実施の一形態では、このように、ディスクがイジェクト操作により排出された場合以外の状態では、当該クリップ情報が記録再生装置の不揮発性メモリ18上に保持されている。そのため、不意の電源切断により、ディスク上に記録されたクリップAVストリームファイルに対応するクリップインフォメーションファイルがディスク上に記録されていなくても、不揮発性メモリ18上に保持されているクリップ情報に基づき当該クリップAVストリームファイルの再生を制御することができる。
なお、上述では、不揮発性メモリ18に対して、クリップインフォメーションファイルに格納されるクリップ情報を書き込み保持するように説明したが、これはこの例に限定されない。例えば、クリップインフォメーションファイルに格納される情報に加え、プレイリストファイルに格納される情報を不揮発性メモリ18に書き込み保持するようにできる。この場合、プレイリストファイルも、クリップインフォメーションファイルと同様に、電源OFFの操作時や、ディスクのイジェクト操作時に不揮発性メモリ18から読み出し、ディスクに書き出すようにする。
図35は、この発明の実施の一形態の他の例によるビデオカメラ装置100の一例の構成を示す。ビデオカメラ装置100において、記録再生系の構成は、図32を用いて説明した記録再生装置の構成を略そのまま適用できるので、図32と共通する部分には同一の符号を付し、詳細な説明を省略する。
図35の構成において、カメラ部50は、映像信号に関する構成として、光学系51、撮像素子52、撮像信号処理部53、カメラ制御部54、ビデオ信号処理部58および表示部55を有し、音声信号に関する構成として、マイクロフォン(MIC)56、音声信号処理部57およびスピーカ部SP60を有する。制御部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は、撮像素子52から出力された撮像信号の情報を制御部30に送る。制御部30は、この情報に基づき光学系51を制御するための制御信号を生成し、カメラ制御部54に供給する。カメラ制御部54は、この制御信号に基づきフォーカス調整機構や絞り調整機構などの制御を行う。
ビデオ信号処理部58は、供給されたディジタル信号に対して所定の信号処理を施す。例えば、ビデオ信号処理部58は、供給されたディジタル信号に対して検波系の信号処理を施し、R(赤色)、G(緑色)およびB(青色)各色の成分を取り出す。そして、取り出された各色成分に基づきγ補正やホワイトバランス補正などの処理を行い、最終的に1本のベースバンドのディジタルビデオデータとして出力する。
表示部55は、例えばLCD(Liquid Crystal Display)を表示素子として用い、ビデオ信号処理部58から供給されたディジタルビデオデータに基づく表示を行うことができる。表示部55は、撮影時には撮影画像のモニタとして用いられ、再生時には、再生画像を映出させることができる。
音声信号処理部57は、例えばマイクロフォンMIC56から供給されるアナログ音声信号をA/D変換してディジタルオーディオデータとし、ノイズ除去や音質補正など所定の音声信号処理を施してベースバンドのディジタルオーディオデータとして出力する。また、音声信号処理部57は、供給されるディジタルオーディオデータに対して音質補正や音量調整などの所定の音声信号処理を施してD/A変換してアナログ音声信号とし、増幅処理などを行いスピーカ部SP60に供給する。
する。
撮影時には、光学系51を介して撮像素子52に入射された光が光電変換により電気信号に変換され撮像信号として出力される。撮像信号は、撮像信号処理部53で所定に信号処理され、A/D変換されディジタルビデオ信号として出力される。このディジタルビデオ信号は、ビデオ信号処理部58に供給される。ビデオ信号処理部58は、供給されたディジタルビデオ信号に対して画質補正などの所定の信号処理を施してディジタルビデオデータとして出力する。このディジタルビデオデータは、記録再生部10に供給され端子40に入力される。
また、ビデオ信号処理部58は、撮像信号処理部53から供給されたディジタル信号に基づき、表示部55に表示するためのディジタルビデオデータを生成する。さらに、ビデオ信号処理部58は、制御部30とやりとりを行い、制御部30で所定に生成された表示制御信号に基づく画像を生成することができる。このディジタルビデオデータや画像は、表示部55に供給され、映出される。
一方、マイクロフォン56から出力された音声信号は、音声信号処理部57でノイズ除去、リミッタ処理、音質補正などの所定の信号処理を施され、さらにA/D変換され、ディジタルオーディオデータとして出力される。このディジタルオーディオデータは、記録再生部10に供給され、端子41に入力される。
記録停止状態からUI部31に設けられた記録スイッチが押下されると、記録開始を指示する制御信号がUI部31から制御部30に供給され、制御部30の制御に基づきカメラ部50から出力されたベースバンドのディジタルビデオデータおよびディジタルオーディオデータの記録媒体32への記録が開始される。
すなわち、図32を用いて既に説明したように、制御部30の制御に基づきビデオエンコーダ11およびオーディオエンコーダ12の動作が開始され、ビデオデータおよびオーディオデータがそれぞれビデオエンコーダ11およびオーディオエンコーダ12で圧縮符号化され、MUX/DEMUX13で所定にパケット化され多重化されてAVストリームデータとされる。AVストリームデータは、ストリームバッファ14を介して、記録制御部15に供給され、クリップAVストリームファイルとして記録媒体32に記録される。
クリップAVストリームファイルの記録に伴い、EPエントリが生成される。EPエントリの生成は揮発性メモリ17を用いて行われ、生成されたEPエントリは、所定のタイミングで不揮発性メモリ18に書き込み保持される。
UI部31の記録スイッチが次に押下されると、記録が停止され、上述した図33のフローチャートにおけるステップS35以降の処理に従い、クリップインフォメーションファイルに格納するクリップ情報の生成、生成されたクリップ情報の不揮発性メモリ18に対する書き込みなどが行われる。また、プレイリストファイルに格納する情報、例えばプレイアイテムやプレイリストマークの追加や更新が行われる。そして、電源OFFの操作やディスクのイジェクト操作により、不揮発性メモリ18に書き込み保持されたクリップ情報などがディスクに書き出される。ディスクのイジェクト操作の場合には、さらに不揮発性メモリ18の記憶内容がクリアされる。
再生時には、記録媒体32がビデオカメラ装置100に装填されると、記録媒体32に記録されているインデックスファイル、ムービーオブジェクトファイルなどのファイルが読み出され、管理情報処理部16に供給される。制御部30は、管理情報処理部16からインデックスファイルの情報を取得し、取得された情報に基づき所定のメニュー画面を表示するための表示制御信号を生成する。この表示制御信号は、ビデオ信号処理部58に供給され、表示部55に表示される。この表示に応じてUI部31に対して所定の操作を行うと、例えば、記録媒体32から再生が指示されたプレイリストファイルが読み出され、このプレイリストファイルの記述に従い、記録媒体32に記録されたクリップの再生がなされる。
すなわち、図34を用いて既に説明したように、制御部30は、UI部31に対する操作に応じて管理情報処理具16からプレイリストファイルの情報を取得し、取得された情報に基づき、記録再生制御部15に対して記録媒体32からクリップインフォメーションファイルやクリップAVストリームファイルを読み出すように命令を出す。
このとき、上述した図34のステップS54以降の処理に従い、プレイリストファイルの情報に基づき読み出すべきクリップインフォメーションファイルが記録媒体32に記録されているか否かが判断され、記録されていると判断されれば、当該クリップインフォメーションファイルが記録媒体32から読み出され、クリップ情報が不揮発性メモリ18に書き込み保持され、さらに揮発性メモリ17に書き込まれる。一方、読み出すべきクリップインフォメーションファイルが記録媒体32に記録されていないと判断されれば、不揮発性メモリ18が参照され、対応するクリップ情報が保持されているか否かが判断される。保持されていれば、当該クリップ情報が揮発性メモリ17に書き込まれる。そして、揮発性メモリ17に記憶されるクリップ情報に基づき、クリップAVストリームファイルが再生制御される。
記録媒体32から読み出されたクリップAVストリームファイルは、ストリームバッファ14を介してMUX/DEMUX13に供給され、パケットのヘッダ情報などに基づき多重化が分離され圧縮ビデオデータと圧縮オーディオデータとが取り出される。圧縮ビデオデータは、ビデオデコーダ20に供給されデコードされて、例えばPTSに従い端子42から出力される。圧縮オーディオデータは、オーディオデコーダ21に供給されデコードされ、ビデオデコーダ20から出力されるビデオデータと同期的に端子43から出力される。
端子42から出力されたビデオデータは、ビデオ信号処理部58で所定の信号処理を施され、表示部55に供給される。表示部55は、供給されたビデオデータに基づく画像を映出する。端子43から出力されたオーディオデータは、音声信号処理部57で所定に信号処理され、増幅処理なども行われ、スピーカ部60に供給される。
なお、上述では、図32に示したように、この発明の実施の一形態としてこの発明が記録再生装置に適用された場合について説明したが、これはこの例に限定されない。すなわち、図33のフローチャートを用いて説明したような、この発明による記録の際の処理は、記録のみを行う記録装置にも同様に適用することができる。
また、上述では、図32に示す記録再生装置や図35に示すビデオカメラ装置100の記録再生部10がハードウェア的に構成されるように説明したが、これはこの例に限定されない。すなわち、記録再生部10は、ソフトウェアとして構成することも可能である。この場合、ソフトウェアは、例えば制御部30が有する図示されないROMに予め記憶される。これに限らず、記録再生部10を、パーソナルコンピュータなどのコンピュータ装置上に構成することも可能である。この場合には、記録再生部10をコンピュータ装置に実行させるソフトウェアは、CD−ROMやDVD−ROMといった記録媒体に記録されて提供される。コンピュータ装置がネットワーク接続可能な場合、インターネットなどのネットワークを介して当該ソフトウェアを提供することも可能である。