【課題】記録開始から停止の間に生成されるＡＶデータをファイルとして記録する際のユーザの利便性を向上させる。
【解決手段】記録開始から停止の間に生成されるＡＶデータをファイルとして記録し、再生区間を示す情報とジャンプ位置を示すマーク情報とを再生リストファイルに追記する。このとき、追記候補の再生リストファイルと、ＡＶデータの再生時刻とアドレスとを対応付ける属性ファイルとに基づき、追記に際して、再生リストファイルや属性ファイルに予め設定された制約を満足するか否かが判断される。満足すると判断されれば、再生区間情報とマーク情報とが追記候補の再生リストファウルに追記される。満足しないと判断されれば、新規に再生リストファイルが生成される。ユーザは、再生リストファイルや属性ファイルに予め設定された制約を意識せずに、ＡＶデータの記録操作を行うことができる。

【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ビデオデータとオーディオデータとを多重化したストリームデータを記録媒体に記録するのに適した記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラムに関する。
【背景技術】
【０００２】
従来から、記録可能で記録再生装置から取り外し可能とされると共に、記録容量が比較的大きく、ビデオデータとオーディオデータとからなるＡＶ(Audio/Video)データを記録するのに適した記録媒体として、４．７ＧＢ(Giga Byte)以上の記録容量を有するＤＶＤ(Digital Versatile Disc)が普及している。特許文献１には、記録可能なタイプのＤＶＤに対してＤＶＤ−Ｖｉｄｅｏフォーマットで記録する撮像装置が記載されている。
【特許文献１】特開２００４−３５０２５１
【０００３】
ところで、記録媒体に対するビデオデータおよびオーディオデータの記録は、一般的には、記録開始操作から記録停止操作の間に生成されるビデオデータを単位として行われる。そして、記録開始操作から記録停止操作の間に生成されるビデオデータ対して、再生リスト情報を用いて再生区間や再生順序を指定することが一般的に行われている。記録されたＡＶストリームを、記録開始操作から記録停止操作の間に生成されるビデオデータを単位として、再生リスト情報を用いて管理することで、記録媒体上のＡＶストリームを加工することなく、当該ＡＶストリームの再生区間や再生順序を自在に設定した編集を容易に行うことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ここで、ビデオデータおよびオーディオデータをファイルとして記録媒体に記録することを考える。例えば、ビデオデータおよびオーディオデータを、記録開始操作から記録停止操作の間に生成されるデータを単位としてファイルとして記録する。ビデオデータおよびオーディオデータをファイルとして記録することで、コンピュータ装置などの他の装置との親和性が増し、記録されたデータをより有効に活用することができることが期待される。
【０００５】
このように、ビデオデータおよびオーディオデータをファイルとして記録する場合、一連の記録開始および停止の操作に伴い１の記録媒体に順次記録されていく複数単位のビデオデータおよびオーディオデータを記録順に連続的に再生するためには、何らかの工夫が必要となる。例えば、一連の記録開始および停止の操作に伴い１の記録媒体に順次記録されていく複数単位のビデオデータおよびオーディオデータの情報を、再生リスト情報が格納される１の再生リストファイルに対して順次、追記していくように制御することが考えられる。このように記録制御を行うことで、記録媒体に単位毎に記録された一連の複数単位のビデオデータおよびオーディオデータを連続的に再生するのが容易となる。
【０００６】
記録開始操作および停止操作毎に順次記録されるビデオデータおよびオーディオデータの情報を再生リストファイルに対して追記していくように制御する場合、記録開始および停止の操作が繰り返される度に、再生リストファイルのデータサイズが増大することになる。一方、記録装置や再生装置では、再生リストファイルを一旦メモリに読み込んで、ファイルとして記録されたビデオデータおよびオーディオデータの再生制御を行うことが考えられる。メモリには、記録媒体に記録されるビデオデータおよびオーディオデータを管理する他の管理情報も読み込まれるため、再生リストファイルのサイズが増大するとメモリの容量を圧迫してしまい、他の処理に支障が出るおそれがあるという問題点があった。
【０００７】
また、ビデオデータおよびオーディオデータをファイルとして記録する場合、再生時にビデオデータ内のフレームを検索したり、フレーム単位での編集を容易に行えるような仕組みを提供する必要がある。このためには、例えばビデオデータにおける再生時間情報と、ビデオデータが格納されるファイル内のアドレスとを対応付けることが考えられる。この再生時間情報とファイル内アドレスとの対応関係を示すデータは、記録に伴い増加するため、この場合においても、記録時や再生時においてメモリ容量を圧迫してしまい、他の処理に支障が出るおそれがあるという問題点があった。
【０００８】
さらに、メモリ容量が圧迫された状態で例えば記録を続行しようとした場合、システムによって強制的にビデオデータおよびオーディオデータの記録が停止されたり、システムがハングアップしてしまう可能性があるという問題点があった。
【０００９】
また、近年では、一般的に用いられるビデオフォーマットの種類がより多彩になってきている。例えば、ライン数と走査方法に関しては、インタレース走査のフォーマットでは、ライン数が４８０本の４８０ｉ、ライン数が５７６本の５７６ｉ、ライン数が１０８０本の１０８０ｉなどがあり、プログレッシブ走査のフォーマットでは、ライン数がそれぞれ４８０本、５７６本、７２０本および１０８０本の、４８０ｐ、５７６ｐ、７２０ｐおよび１０８０ｐなどが規定されている。
【００１０】
記録装置においても、上述のような多種類のフォーマットに対応した記録が可能なことが求められる。それと共に、１の記録媒体に対して複数種類のフォーマットによるビデオデータを混在して記録可能なことが求められる。しかしながら、上述したように、記録媒体にファイルとして順次記録されるビデオデータおよびオーディオデータの情報を、１の再生リストファイルに対して追記していくように記録制御を行う場合、当該記録媒体を再生する再生装置側で問題が発生する可能性がある。例えば、再生リストファイルに従い順次、ファイルとして記録されたビデオデータおよびオーディオデータを再生していく際に、今まで再生していたビデオデータとフォーマットが異なるビデオデータを次に連続的に再生しようとしても、デコーダの処理の切り換えが間に合わなかったり、デコーダがハングアップして動作が停止してしまうおそれがあるという問題点があった。
【００１１】
したがって、この発明の目的は、記録開始操作から記録停止操作の間に生成されるビデオデータおよびオーディオデータをファイルとして記録する際のユーザの利便性を向上させることができる記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、第１の発明は、ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録装置において、ビデオデータおよびオーディオデータが入力されるデータ入力部と、ビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力部と、ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録部と、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成部とを有し、管理情報生成部は、既存の再生管理情報に基づき、記録指示入力部による記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする記録装置である。
【００１３】
また、第２の発明は、ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録方法において、データ入力部に入力されたビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力のステップと、ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップとを有し、管理情報生成のステップは、既存の再生管理情報に基づき、記録指示入力のステップによる記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする記録方法である。
【００１４】
また、第３の発明は、ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録方法をコンピュータ装置に実行させる記録プログラムにおいて、記録方法は、データ入力部に入力されたビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力のステップと、ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップとを有し、管理情報生成のステップは、既存の再生管理情報に基づき、記録指示入力のステップによる記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする記録プログラムである。
【００１５】
また、第４の発明は、撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置において、被写体を撮像してビデオデータを出力する撮像部と、音声を収音してオーディオデータを出力する収音部と、ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録部と、ビデオデータおよびオーディオデータの記録媒体への記録開始および記録停止を指示するユーザ操作を受け付ける操作部と、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成部とを有し、管理情報生成部は、既存の再生管理情報に基づき、操作部に対するユーザ操作に応じた記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする撮像装置である。
【００１６】
また、第５の発明は、撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置の撮像方法において、撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、操作部に対するビデオデータおよびオーディオデータの記録媒体への記録開始および記録停止を指示するユーザ操作を受け付けるステップと、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップとを有し、管理情報生成のステップは、既存の再生管理情報に基づき、操作部に対するユーザ操作に応じた記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする撮像方法である。
【００１７】
また、第６の発明は、撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置の撮像方法をコンピュータ装置に実行させる撮像プログラムにおいて、撮像方法は、撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、操作部に対するビデオデータおよびオーディオデータの記録媒体への記録開始および記録停止を指示するユーザ操作を受け付けるステップと、ストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップとを有し、管理情報生成のステップは、既存の再生管理情報に基づき、操作部に対するユーザ操作に応じた記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うことを特徴とする撮像プログラムである。
【００１８】
上述したように、第１、第２および第３の発明は、ビデオデータおよびオーディオデータが多重化されたストリームからなるストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成するようにされ、既存の再生管理情報に基づき、ビデオデータの記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うようにしているため、記録開始操作および記録停止操作を繰り返し行った場合でも、ユーザが意識することなく、第２の管理情報の生成が適切に制御される。
【００１９】
また、第４、第５および第６の発明は、撮像されて得られたビデオデータと収音されて得られたオーディオデータとが多重化されたストリームからなるストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成するようにされ、既存の再生管理情報に基づき、操作部に対するユーザ操作に応じた記録開始の指示に従い、記録媒体に記録される被写体を撮影して得られたビデオデータからなるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うようにしているため、撮影に際して記録開始操作および記録停止操作を繰り返し行った場合でも、ユーザが意識することなく、第２の管理情報の生成が適切に制御される。
【発明の効果】
【００２０】
第１、第２および第３の発明は、上述したように、ビデオデータおよびオーディオデータが多重化されたストリームからなるストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成するようにされ、既存の再生管理情報に基づき、ビデオデータの記録開始の指示に従い記録媒体に記録されるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うようにしているため、記録開始操作および記録停止操作を繰り返し行った場合でも、ユーザが意識することなく、第２の管理情報の生成が適切に制御される効果がある。
【００２１】
また、第４、第５および第６の発明は、上述したように、撮像されて得られたビデオデータと収音されて得られたオーディオデータとが多重化されたストリームからなるストリームファイルの属性情報を示す第１の管理情報と、ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、記録媒体に記録されるストリームファイルの再生を制御するための再生管理情報を生成するようにされ、既存の再生管理情報に基づき、操作部に対するユーザ操作に応じた記録開始の指示に従い、記録媒体に記録される被写体を撮影して得られたビデオデータからなるストリームファイルに対する再生方法を示す情報を、既存の再生管理情報に含まれる所定の第２の管理情報に対して追記するか否かの追記可否判断を行うようにしているため、撮影に際して記録開始操作および記録停止操作を繰り返し行った場合でも、ユーザが意識することなく、第２の管理情報の生成が適切に制御される効果がある。
【発明を実施するための最良の形態】
【００２２】
以下、この発明の実施の一形態を、図面を参照しながら説明する。先ず、理解を容易とするために、この発明に適用可能な一例のフォーマット（以下、ＡＶＣＨＤフォーマットと呼ぶ）について説明する。ＡＶＣＨＤフォーマットは、ビデオデータとオーディオデータとが所定に多重化されたＡＶ(Audio/Video)ストリームを記録可能な記録媒体に記録する記録フォーマットとして現在提案されているもので、記録媒体に記録されたＡＶストリームを、クリップ単位でプレイリストを用いて管理可能としている。
【００２３】
例えばＩＴＵ−Ｔ(International Telecommunication Union-Telecommunication Standarization Sector)勧告Ｈ．２６４あるいはＩＳＯ(International Organization for Standarization)／ＩＥＣ(International Electrotechnical Commission)国際標準１４４９６−１０（ＭＰＥＧ−４パート１０）Advanced Video Coding（以下、Ｈ．２６４｜ＡＶＣと略称する）に規定される符号化方式で符号化され、ＭＰＥＧ２システムズに従い多重化されたビットストリームは、クリップＡＶストリーム（またはＡＶストリーム）と称される。クリップＡＶストリームは、所定のファイルシステムによりファイルとしてディスクに記録される。このファイルを、クリップＡＶストリームファイル（またはＡＶストリームファイル）と称する。
【００２４】
クリップＡＶストリームファイルは、ファイルシステム上での管理単位であり、ユーザにとって必ずしも分かりやすい管理単位であるとは限らない。ユーザの利便性を考えた場合、複数のクリップＡＶストリームファイルに分割された映像コンテンツを一つにまとめて再生する仕組みや、クリップＡＶストリームファイルの一部だけを再生する仕組み、さらには、特殊再生や頭出し再生を滑らかに行うための情報などをデータベースとしてディスクに記録しておく必要がある。
【００２５】
図１は、この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す。このＡＶＣＨＤフォーマットによれば、データ構造は、図１に示されるように４層のレイヤよりなる。最も最下層のレイヤは、クリップＡＶストリームが配置されるレイヤである（便宜上、クリップレイヤと呼ぶ）。その上のレイヤは、クリップＡＶストリームに対する再生箇所を指定するための、プレイリスト(PlayList)と、プレイアイテム(PlayItem)とが配置されるレイヤである（便宜上、プレイリストレイヤと呼ぶ）。さらにその上のレイヤは、プレイリストに対して再生順などを指定するコマンドからなるムービーオブジェクト(Movie Object)などが配置されるレイヤである（便宜上、オブジェクトレイヤと呼ぶ）。最上層のレイヤは、記録媒体に格納されるタイトルなどを管理するインデックステーブルが配置される（便宜上、インデックスレイヤと呼ぶ）。
【００２６】
クリップレイヤについて説明する。クリップＡＶストリームは、ビデオデータやオーディオデータがＭＰＥＧ２ ＴＳ（トランスポートストリーム）の形式などに多重化されたビットストリームである。このクリップＡＶストリームに関する情報がクリップ情報(Clip Information)としてファイルに記録される。
【００２７】
また、クリップＡＶストリームには、字幕を表示するグラフィクスストリームであるＯＢストリーム(Overlay Bitmap stream)や、メニュー表示などに用いられるデータ（ボタン画像データなど）をストリームにしたＭＢストリーム(Menu Bitmap stream)を多重化することができる。
【００２８】
クリップＡＶストリームファイルと、対応するクリップ情報が記録されたクリップ情報ファイルとをひとまとまりのオブジェクトと見なし、クリップ(Clip)と称する。すなわち、クリップは、クリップＡＶストリームとクリップ情報とから構成される、一つのオブジェクトである。
【００２９】
ファイルは、一般的に、バイト列として扱われる。クリップＡＶストリームファイルのコンテンツは、時間軸上に展開され、クリップ中のエントリーポイントは、主に時間ベースで指定される。所定のクリップへのアクセスポイントのタイムスタンプが与えられた場合、クリップＡＶストリームファイルの中でデータの読み出しを開始すべきアドレス情報を見つけるために、クリップ情報ファイルを用いることができる。
【００３０】
プレイリストレイヤについて説明する。プレイリストは、再生するＡＶストリームファイルの指定と、指定されたＡＶストリームファイルの再生箇所を指定する再生開始点（ＩＮ点）と再生終了点（ＯＵＴ点）の集まりとから構成される。この再生開始点と再生終了点の情報を一組としたものは、プレイアイテム(PlayItem)と称される。プレイリストは、プレイアイテムの集合で構成される。プレイアイテムを再生するということは、そのプレイアイテムに参照されるＡＶストリームファイルの一部分を再生するということになる。すなわち、プレイアイテム中のＩＮ点およびＯＵＴ点情報に基づき、クリップ中の対応する区間が再生される。
【００３１】
オブジェクトレイヤについて説明する。ムービーオブジェクトは、ナビゲーションコマンドプログラムと、ムービーオブジェクトとを連携するターミナルインフォメーションを含む。ナビゲーションプログラムは、プレイリストの再生を制御するためのコマンド（ナビゲーションコマンド：navigation command）である。
【００３２】
インデックスレイヤについて説明する。インデックスレイヤは、インデックステーブル(Index Table)からなる。インデックステーブルは、記録媒体に記録されたコンテンツのタイトルを定義する、トップレベルのテーブルである。インデックステーブルに格納されているタイトル情報に基づき、プレーヤに常駐されるシステムソフトウェア中のモジュールマネージャにより記録媒体の再生が制御される。
【００３３】
すなわち、図２に概略的に示されるように、インデックステーブル中の任意のエントリは、タイトルと称され、インデックステーブルにエントリされるファーストプレイバックタイトル(First PlaybackTitle)、メニュータイトル(MenuTitle)およびムービータイトル(MovieTitle)＃１、＃２、・・・は、全てタイトルである。各タイトルは、ムービーオブジェクトに対するリンクを示す。
【００３４】
理解を容易とするため再生専用の記録媒体を例にとると、例えば、ファーストプレイバックタイトルは、当該記録媒体に格納されるコンテンツが映画であれば、映画本編に先立って映出される映画会社の宣伝用映像（トレーラ）に対応する。メニュータイトルは、例えばコンテンツが映画である場合、本編再生、チャプタサーチ、字幕や言語設定、特典映像再生などを選択するためのメニュー画面に対応する。また、ムービータイトルは、メニュータイトルから選択される各映像である。タイトルがさらにメニュー画面であるような構成も可能である。
【００３５】
図３は、上述のようなクリップＡＶストリーム、クリップ情報(Stream Attributes)、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ(Unified Modeling Language)図である。プレイリストは、１または複数のプレイアイテムに対応付けられ、プレイアイテムは、１のクリップに対応付けられる。１のクリップに対して、それぞれ開始点および／または終了点が異なる複数のプレイアイテムを対応付けることができる。１のクリップから１のクリップＡＶストリームファイルが参照される。同様に、１のクリップから１のクリップ情報ファイルが参照される。また、クリップＡＶストリームファイルとクリップ情報ファイルとは、１対１の対応関係を有する。このような構造を定義することにより、クリップＡＶストリームファイルを変更することなく、任意の部分だけを再生する、非破壊の再生順序指定を行うことが可能となる。
【００３６】
また、図４のように、複数のプレイリストから同一のクリップを参照することもできる。また、１のプレイリストから複数のクリップを指定することもできる。クリップは、プレイリスト中のプレイアイテムに示されるＩＮ点およびＯＵＴ点により、参照される。図４の例では、クリップ３００は、プレイリスト３１０のプレイアイテム３２０から参照されると共に、プレイリスト３１１を構成するプレイアイテム３２１および３２２のうちプレイアイテム３２１から、ＩＮ点およびＯＵＴ点で示される区間が参照される。また、クリップ３０１は、プレイリスト３１１のプレイアイテム３２２からＩＮ点およびＯＵＴ点で示される区間が参照されると共に、プレイリスト３１２のプレイアイテム３２３および３２４のうち、プレイアイテム３２３のＩＮ点およびＯＵＴ点で示される区間が参照される。図４の例では、クリップ３０１は、さらに別のプレイリストからも参照されている。
【００３７】
次に、ＡＶＣＨＤフォーマットによる、記録媒体に記録されるファイルの管理構造について、図５を用いて説明する。ファイルは、ディレクトリ構造により階層的に管理される。記録媒体上には、先ず、１つのディレクトリ（図５の例ではルート(root)ディレクトリ）が作成される。このディレクトリの下が、１つの記録再生システムで管理される範囲とする。
【００３８】
ルートディレクトリの下に、ディレクトリ"BDMV"が置かれる。さらに必要に応じて、ルートディレクトリの下にディレクトリ"AVCHDTN"がおかれる。ディレクトリ"AVCHDTN"には、例えばクリップの代表画像を所定サイズに縮小したサムネイルファイルが置かれる。ディレクトリ"BDMV"に、図１を用いて説明したデータ構造が格納される。
【００３９】
ディレクトリ"BDMV"の直下には、ファイルは、ファイル"index.bdmv"およびファイル"MovieObject.bdmv"の２つのみを置くことができる。また、ディレクトリ"BDMV"の下に、ディレクトリ"PLAYLIST"、ディレクトリ"CLIPINF"、ディレクトリ"STREAM"およびディレクトリ"BACKUP"が置かれる。ディレクトリ"BACKUP"は、各ディレクトリおよびファイルのバックアップが格納される。
【００４０】
ファイル"index.bdmv"は、ディレクトリBDMVの内容について記述される。すなわち、このファイル"index.bdmv"が上述した最上層のレイヤであるインデックスレイヤにおけるインデックステーブルに対応する。また、ファイルMovieObject.bdmvは、１つ以上のムービーオブジェクトの情報が格納される。すなわち、このファイル"MovieObject.bdmv"が上述したオブジェクトレイヤに対応する。
【００４１】
ディレクトリ"PLAYLIST"は、プレイリストのデータベースが置かれるディレクトリである。すなわち、ディレクトリ"PLAYLIST"は、プレイリストに関するファイルであるファイル"xxxxx.mpls"を含む。ファイル"xxxxx.mpls"は、プレイリストのそれぞれに対して作成されるファイルである。ファイル名において、"."（ピリオド）の前の"xxxxx"は、５桁の数字とされ、ピリオドの後ろの"mpls"は、このタイプのファイルに固定的とされた拡張子である。
【００４２】
ディレクトリ"CLIPINF"は、クリップのデータベースが置かれるディレクトリである。すなわち、ディレクトリCLIPINF"は、クリップＡＶストリームファイルのそれぞれに対するクリップインフォメーションファイルであるファイル"zzzzz.clpi"を含む。ファイル名において、"."（ピリオド）の前の"zzzzz"は、５桁の数字とされ、ピリオドの後ろの"clpi"は、このタイプのファイルに固定的とされた拡張子である。
【００４３】
ディレクトリ"STREAM"は、実体としてのＡＶストリームファイルが置かれるディレクトリである。すなわち、ディレクトリ"STREAM"は、クリップインフォメーションファイルのそれぞれに対応するクリップＡＶストリームファイルを含む。クリップＡＶストリームファイルは、ＭＰＥＧ２(Moving Pictures Experts Group 2)のトランスポートストリーム（以下、ＭＰＥＧ２ ＴＳと略称する）からなり、ファイル名が"zzzzz.m2ts"とされる。ファイル名において、ピリオドの前の"zzzzz"は、対応するクリップインフォメーションファイルと同一することで、クリップインフォメーションファイルとこのクリップＡＶストリームファイルとの対応関係を容易に把握することができる。
【００４４】
なお、ディレクトリ"AVCHDTN"は、２種類のサムネイルファイルthumbnail.tidxおよびthumbnail.tdt2を置くことができる。サムネイルファイルthumbnail.tidxは、所定の方式で暗号化されたサムネイル画像が格納される。サムネイルファイルthumbnail.tdt2は、暗号化されていないサムネイル画像が格納される。例えばビデオカメラでユーザが撮影したクリップに対応するサムネイル画像は、コピーフリーであって暗号化する必要が無いと考えられるため、このサムネイルファイルthumbnail.tdt2に格納される。
【００４５】
図５で示した各ファイルのうち、この発明に関わりの深いものについて、より詳細に説明する。先ず、ディレクトリ"BDMV"の直下に置かれるファイル"index.bdmv"について説明する。図６は、このファイル"index.bdmv"の一例の構造を表すシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるＣ言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
【００４６】
図６において、フィールドTypeIndicatorは、３２ビットのデータ長を有し、このファイルがインデックステーブルであることを示す。フィールドTypeIndicator2は、３２ビットのデータ長を有し、このファイル"index.bdmv"のバージョンを示す。フィールドIndexesStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkIndexes()の開始アドレスを示す。
【００４７】
フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。フィールドExtensionDataStartAddressは、このファイル"index.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
【００４８】
フィールドExtensionDataStartAddressに続けて、データ長が１９２バイトの領域reservedが配される。なお、領域reservedは、バイトアライメントや、将来的なフィールドの追加などのための領域である。これは、以下の説明においても同様である。ブロックblkAppInfoBDMV()は、コンテンツ制作者が任意の情報を記述できるブロックであって、プレーヤの動作などには影響を与えない。
【００４９】
ブロックblkIndexes()は、このファイル"index.bdmv"の実質的な内容であって、このファイル"index.bdmv"に記述された内容により、ディスクをプレーヤに装填した際に再生されるファーストプレイバックや、トップメニューから呼び出されるタイトル（ムービーオブジェクト）が指定される。インデックステーブルにより呼び出されたムービーオブジェクト等に記述されたコマンドに基づき、後述するプレイリストファイルが読み込まれる。
【００５０】
図７は、ブロックblkIndexes()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLength直後からこのブロックblkIndexes()の終わりまでのデータ長を示す。続けて、ブロックFirstPlaybackTitle()およびブロックMenuTitle()が配される。
【００５１】
ブロックFirstPlaybackTitle()は、ファーストプレイバックで用いられるオブジェクトに関する情報が記述される。ブロックFirstPlaybackTitle()は、１ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに３１ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、１４ビットのデータ長を有する領域reservedを介して、１６ビットのデータ長を有するフィールドFirstPlaybackTitleMobjIDRefが配される。このフィールドFirstPlaybackTitleMobjIDRefにより、ファーストプレイバックタイトルで用いられるムービーオブジェクトのＩＤを示す。
【００５２】
ムービーオブジェクトのＩＤは、例えば、図８および図９を用いて後述するムービーオブジェクトのシンタクスに基づき、ムービーオブジェクトのforループ文においてループ変数として用いられる値mobj_idで示される。この例では、フィールドFirstPlaybackTitleMobjIDRefは、参照するムービーオブジェクトに対応する値mobj_idが格納される。
【００５３】
なお、ブロックblkIndexes()におけるブロックFirstPlaybackTitle()内のフィールドFirstPlaybackTitleMobjIDRefは、トップメニューのムービーオブジェクトを指していてもよいし、タイトルを指していてもよい。
【００５４】
ブロックMenuTitle()は、トップメニューで用いられるオブジェクトに関する情報が記述される。ブロックMenuTitle()は、１ビットのデータ長を有する領域reservedに続けて固定値"1"が記述される。さらに３１ビットのデータ長を有する領域reservedを介して固定値"1"が記述される。そして、１４ビットのデータ長を有する領域reservedを介して、１６ビットのデータ長を有するフィールドMenuTitleMobjIDRefが配される。フィールドMenuTitleMobjIDRefは、メニュータイトルで用いられるムービーオブジェクトのＩＤを示す。
【００５５】
ブロックMenuTitle()の次のフィールドNumberOfTitlesは、１６ビットのデータ長を有し、ユーザが選択、再生可能なタイトルの数を示す。次のforループ文に従い、このフィールドNumberOfTitlesに示される回数だけ、値title_idを引数として、ブロックMovieTitle[title_id]()が記述される。ブロックMovieTitle[title_id]()は、タイトル毎の情報が記述される。値title_idは、"０"からフィールドNumberOfTitlesで示される値までの数値であり、タイトルを識別する。
【００５６】
ブロックMovieTitle[title_id]()において、１ビットのデータ長を有する領域reservedを介して固定値"1"が記述され、さらに、４６ビットのデータ長を有する領域reservedを介してフィールドMovieTitleMobjIDRefが記述される。フィールドMovieTitleMobjIDRefは、１６ビットのデータ長を有し、このタイトルで用いられるムービーオブジェクトのＩＤを示す。フィールドMovieTitleMobjIDRefの後ろに、３２ビットのデータ長を有する領域reservedが配される。
【００５７】
図８は、ディレクトリ"BDMV"の直下に置かれるファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがファイル"MovieObject.bdmv"であることを示す。フィールドTypeIndicatorは、ＩＳＯ(International Organization for Standarization)６４６に規定された符号化方式で符号化した４文字からなる文字列が記述される。この図８の例では、フィールドTypeIndicatorにＩＳＯ６４６に既定の方式で符号化された４文字の文字列"MOBJ"が記述され、このファイルがファイル"MovieObject.bdmv"であることが示される。
【００５８】
フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このファイル"MovieObject.bdmv"のバージョン番号を示す。このファイル"MovieObject.bdmv"では、フィールドTypeIndicator2は、ＩＳＯ６４６に規定された符号化方式で符号化した４文字の文字列"0100"でなければならない。
【００５９】
フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス内にあるブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、このファイル"MovieObject.bdmv"の最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"MovieObject.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
【００６０】
なお、この図８に示すシンタクス内のフィールドpadding_wordは、１６ビットのデータ長を有し、このファイル"MovieObject.bdmv"のシンタクスに従いforループ文に値N1または値N2で示される回数だけ挿入される。値N1または値N2は、"０"または任意の正の整数である。また、フィールドpadding_wordは、任意の値を用いることができる。
【００６１】
フィールドExtensionDataStartAddressに続けてデータ長が２２４ビットの領域reservedが配され、その次に、このファイル"MovieObject.bdmv"の本体であるブロックblkMovieObjects()が格納される。
【００６２】
図９は、ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からこのブロックblkMovieObjects()の終わりまでのデータ長を示す。３２ビットのデータ長を有する領域reservedを介してフィールドNumberOfMobjsが配される。フィールドNumberOfMobjsは、直後のforループ文に従い格納されるムービーオブジェクトの数を示す。forループ文のループ変数として用いられる値mobj_idで、ムービーオブジェクトが一意に特定される。値mobj_idは、"０"から始まる値で、ムービーオブジェクトは、forループ文中に記述される順序により定義される。
【００６３】
forループ文中のブロックTerminalInfo()は、固定値"1"が記述され、次に１５ビットのデータ長を有する領域reservedが配される。その次に、１６ビットのデータ長を有するフィールド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は、０から始まる値で、ナビゲーションコマンドNavigationCommandは、このforループ文中に記述される順序で定義される。
【００６５】
図１０は、プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがプレイリストファイルであることを示す。フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このプレイリストファイルのバージョンを示す。フィールドPlayListStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkPlayList()の開始アドレスを示す。
【００６６】
フィールドPlayListMarkStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkPlayListMark()の開始アドレスを示す。フィールドExtensionDataStartAddressは、３２ビットのデータ長を有し、このシンタクス中のブロックblkExtensionData()の開始アドレスを示す。フィールドExtensionDataStartAddressは、ブロックblkExtensionData()の開始アドレスを、ファイル"xxxxx.mpls"の最初のバイトからの相対バイト数を表した値である。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"xxxxx.mpls"内に、ブロックblkExtensionData()が存在しないことを示す。
【００６７】
１６０ビットのデータ長を有する領域reservedを介してブロックblkAppInfoPlayList()が配される。ブロックblkAppInfoPlayList()は、次のブロックblkPlayList()に記述されるプレイリストのタイプ、再生制限などの情報が記述される。ブロックblkPlayList()は、プレイリストが記述される。ブロックblkPlayListMark()は、チャプタジャンプなどでジャンプされるポイントが記述される。ブロックblkExtensionData()は、所定の拡張データを格納可能とするためのブロックである。
【００６８】
図１１は、ブロックblkPlayList()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayList()の最後までのデータ長を示す。フィールドLengthに続けて１６ビットのデータ長を有する領域reservedが配され、次にフィールドNumberOfPlayItemsが配される。フィールドNumberOfPlayItemsは、１６ビットのデータ長を有し、このブロックblkPlayList()に含まれるプレイアイテムの数を示す。フィールドNumberOfSubPathは、このブロックblkPlayList()に含まれるサブパスの数を示す。
【００６９】
次のforループ文に従い、フィールドNumberOfPlayItemsで示される数だけ、プレイアイテムが記述されるブロックblkPlayItem()が記述される。forループ文に基づくカウント数がブロックblkPlayItem()の識別子PlayItem_idとなる。さらに次のforループ文に従い、フィールドNumberOfSubPathで示される数だけ、ブロックblkSubPath()が記述される。forループ文に基づくカウント数がブロックblkSubPath()の識別子SubPath_idとなる。
【００７０】
なお、サブパスは、主として再生されるプレイアイテムに対応するメインパスに対して、サブプレイアイテムに対応して持つことができる。サブパスは、例えば、アフレコ用のオーディオデータの指定や、２枚の映像を合成する際に、プレイアイテムで指定されるクリップと同期して再生する副映像を指定するといった目的で用いられる。
【００７１】
図１２は、ブロックblkPlayItem()の一例の構造を表すシンタクスを示す。フィールドLengthは、１６ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayItem()の最後までのデータ長を示す。
【００７２】
フィールドClipInformationFileNameは、４０ビット（５バイト）のデータ長を有し、このブロックblkPlayItem()が参照するクリップインフォメーションファイルのファイル名が示される。このプレイアイテムにおいて、フィールドClipInformationFileNameで示されるファイル名のクリップインフォメーションファイルが読み出される。フィールドClipCodecIdentifierは、３２ビット（４バイト）のデータ長を有し、このブロックblkPlayItem()によるプレイアイテムにおいて用いられるクリップＡＶストリームのコーデック方式を示す。
【００７３】
１２ビットのデータ長を有する領域reservedを介して、フィールドConnectionConditionが配される。フィールドConnectionConditionは、４ビットのデータ長を有し、クリップ間の接続状態に関する情報を示す。記録用途の記録媒体に対しては、フィールドConnectionConditionの値として"１"、"５"または"６"が用いられる。フィールドConnectionConditionの値が"１"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続しないことを示し、フィールドConnectionConditionの値が"５"または"６"で、そのプレイアイテムから参照されているクリップと手前のプレイアイテムから参照されているクリップとがシームレス接続することを示す。なお、シームレス接続とは、クリップと次のクリップとがフレームタイミングで連続的に再生されるように、クリップ間の再生制御を行うことをいう。
【００７４】
フィールドConnectionConditionの値が"５"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して長くされる（図１３Ａ参照）。これにより、クリップとクリップとを接続する際に、オーディオデータのフェイドアウト処理が可能とされる。例えば、ユーザによる記録停止操作によりクリップがクローズされる場合に、フィールドConnectionConditionの値が"５"とされる。以下、このフィールドConnectionConditionの値が"５"で示されるクリップの接続方法を、第１のシームレス接続と呼ぶ。
【００７５】
フィールドConnectionConditionの値が"６"で、当該プレイアイテムが参照するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して同じにされる（図１３Ｂ参照）。これにより、クリップとクリップとの接続をシームレスに行うことが可能とされる。例えば、ユーザ操作に応じた記録停止以外の理由、例えばシステム要因に基づきクリップがクローズされる場合に、フィールドConnectionConditionの値が"６"とされる。以下、このフィールドConnectionConditionの値が"６"で示されるクリップの接続方法を、第２のシームレス接続と呼ぶ。
【００７６】
フィールドRefToSTCIDは、８ビットのデータ長を有し、システムタイムベース（ＳＴＣ）の不連続点に関する情報を示す。フィールドINTimeおよびフィールドOUTTimeは、それぞれ３２ビットのデータ長を有し、メインクリップＡＶストリームの再生範囲を示す。フィールドINTimeが開始点（ＩＮ点）を示し、フィールドOUTTimeが終了点（ＯＵＴ点）を示す。
【００７７】
ブロックblkUOMaskTable()は、ユーザ入力の受付制限が設定されるテーブルである。１ビットのデータ長を有するフラグPlayItemRandomAccessFlagは、このブロックblkPlayItem()によるプレイアイテムに対してランダムアクセスを許可するか否かを規定する。続けて、７ビットのデータ長を有する領域reservedを介してフィールドStillModeが配される。フィールドStillModeは、８ビットのデータ長を有し、ブロックblkPlayItem()によるプレイアイテムにおいて、最後に表示した映像を静止画として表示させるか否かを示す。フィールドStillModeの値が"0x01"（バイナリ）であれば、if文に基づき、１６ビットのデータ長を有するフィールドStillTimeにより静止時間が示される。フィールドStillModeの値が"0x01"以外であれば、当該１６ビットのデータ長を有する領域が領域reservedとされる。
【００７８】
なお、数値の記述において"0x"は、その数値が１６進表記されていることを示す。これは、以下の同様な表記について共通である。
【００７９】
ブロックblkSTNTable()は、このブロックblkPlayItem()によるプレイアイテムが管理しているクリップＡＶストリームの属性、ＰＩＤ番号、記録媒体上での記録位置などが管理される。
【００８０】
図１４は、ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayListMark()の最後までのデータ長を示す。
【００８１】
フィールドNumberOfPlayListMarksは、１６ビットのデータ長を有し、このブロックblkPlayListMark()に含まれるプレイリストマークの数を示す。次のforループ文に従い、フィールドNumberOfPlayListMarksで示される数だけプレイリストマークの情報が記述される。
【００８２】
forループ文内において、８ビットのデータ長を有する領域reserveに続けてフィールドMarkTypeが配される。フィールドMarkTypeは、８ビットのデータ長を有し、マークのタイプを示す。プレイリストマークには、エントリマーク(Entry Mark)およびリンクポイント(Link Point)の２タイプが定義されており、このフィールドMarkTypeにより、何れのタイプであるかが示される。チャプタを定義するためには、エントリマークを用いる。リンクポイントは、この発明と関連性が薄いので、説明を省略する。上述したフィールドNumberOfPlayListMarksは、エントリマークおよびリンクポイントを合計した値を示す。
【００８３】
フィールドRefToPlayItemIDは、１６ビットのデータ長を有し、マークが打たれるプレイアイテムを参照する識別情報PlayItem_idが記述される。フィールドMarkTimeStampは、３２ビットのデータ長を有し、マークが打たれるポイントを示すタイムスタンプが記述される。フィールドEntryESPIDは、１６ビットのデータ長を有し、マークによって指し示されるエレメンタリストリームを含んでいるＴＳパケットのＰＩＤの値を示す。フィールドDurationは、４５ｋＨｚのクロックを単位とした計測による、３２ビットのデータ長を有する符号無し整数である。このフィールドDurationに格納される値が"０"であれば、このフィールドDurationは、意味を成さない。
【００８４】
図１５は、クリップインフォメーションファイルの一例の構造を表すシンタクスを示す。フィールドTypeIndicatorは、３２ビット（４バイト）のデータ長を有し、このファイルがクリップインフォメーションファイルであることを示す。フィールドTypeIndicator2は、３２ビット（４バイト）のデータ長を有し、このクリップインフォメーションファイルのバージョンを示す。
【００８５】
このクリップインフォメーションファイルは、ブロックblkClipInfo()、ブロックblkSequenceInfo()、ブロックblkProgramInfo()、ブロックblkCPI()、ブロックblkClipMark()およびブロックblkExtensionData()を有し、それぞれ３２ビットのデータ長を有するフィールドSequenceInfoStartAddress、フィールドProgramInfoStartAddress、フィールドCPIStartAddress、フィールドClipMarkStartAddressおよびフィールドExtensionDataStartAddressは、各々対応するブロックの開始アドレスを示す。
【００８６】
フィールドExtensionDataStartAddressは、このクリップインフォメーションファイルの最初のバイトからの相対バイト数で、ブロックblkExtensionData()の開始アドレスを示す。相対バイト数は、"０"から開始される。若し、このフィールドExtensionDataStartAddressの値が"０"であれば、このファイル"index.bdmv"内に、ブロックblkExtensionData()が存在しないことを示す。
【００８７】
ブロックblkClipInfo()は、これらの開始アドレスを示すフィールドに続く、９６ビットのデータ長を有する領域reservedの次から開始される。ブロックblkClipInfo()は、このクリップインフォメーションファイルが管理するクリップＡＶストリームに関する情報が記述される。ブロックblkSequenceInfo()は、ＳＴＣやＡＴＣ（アライバルタイムベース）が連続しているシーケンスをまとまりとして管理する情報が記述される。ブロックblkProgramInfo()は、このクリップインフォメーションファイルに管理されるクリップＡＶストリームの符号化方式、クリップＡＶストリーム中のビデオデータのアスペクト比などの情報が記述される。ブロックblkCPI()は、ランダムアクセス開始点などの、ＡＶストリーム中の特徴的な箇所を表す特徴点情報ＣＰＩに関する情報が格納される。
【００８８】
また、ブロックblkClipMark()は、チャプタ位置などの、クリップに付された頭出しのためのインデックス点（ジャンプポイント）が記述される。ブロックblkExtensionData()は、拡張データを格納することができる領域である。なお、クリップインフォメーションファイル内のブロックblkClipMark()およびブロックblkSequenceInfo()は、この発明との関連性が薄いので、詳細な説明を省略する。
【００８９】
図１６は、ブロックblkClipInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkClipInfo()の最後までのデータ長を示す。１６ビットのデータ長を有する領域reservedを介して、フィールドClipStreamTypeが配される。
【００９０】
フィールドClipStreamTypeは、８ビットのデータ長を有し、クリップＡＶストリームの種別を表す。このフィールドClipStreamTypeの値は、例えば"１"に固定的とされる。フィールドApplicationTypeは、８ビットのデータ長を有し、クリップＡＶストリーム（拡張子が「m2ts」のファイル）がどのような多重化によって作られているかを示す。フィールドApplicationTypeの値が"１"で、対応するクリップＡＶストリームは、通常の動画が再生される。続けて３１ビットのデータ長を有する領域reservedが配される。
【００９１】
データ長が１ビットのフラグIsCC5は、プレイリストにおけるブロックblkPlayItem()によって、対応するクリップと次のクリップとの接続を、上述した第１のシームレス接続、すなわちフィールドConnectionConditionの値が"５"で示される方法で行うか否かを示す。フラグIsCC5の値が"１"（バイナリ値）であれば、クリップ間の接続が第１のシームレス接続によりなされていることを示す。
【００９２】
フィールドTSRecordingRateは、クリップＡＶストリームファイルの記録レートをバイト／秒で表したものである。フィールドNumberOfSourcePacketsは、クリップＡＶストリームに含まれるソースパケット数を表す。１０２４ビットのデータ長を有する領域reservedを介してブロックTSTypeInfoBlock()が配される。ブロックTSTypeInfoBlock()は、クリップＡＶストリームが格納されるパケットのタイプを示す情報が格納される。このブロックTSTypeInfoBlock()は、この発明との関連性が薄いので、詳細な説明を省略する。
【００９３】
次のif文以下の情報は、上述のフラグIsCC5の値が"１"である場合に記述される。if文の次の８ビットのデータ長を有する領域reservedを介してフィールドFollowingClipStreamTypeが配されるフィールドFollowingClipStreamTypeは、８ビットのデータ長を有し、このクリップインフォメーションファイルに対応するクリップの次のクリップのタイプが記述される。３２ビットのデータ長を有する領域reservedを介してフィールドFollowingClipInformationFileNameが配される。
【００９４】
フィールドFollowingClipInformationFileNameは、４０ビット（５バイト）のデータ長を有し、このクリップインフォメーションファイルに対応するクリップの次のクリップに対応するクリップインフォメーションファイルのファイル名が記述される。次のフィールドClipCodecIdentifierは、３２ビット（４バイト）のデータ長を有し、当該次のクリップの符号化方式を示す。この例では、フィールドClipCodecIdentifierは、ＩＳＯ６４６に既定の方式で符号化された４文字の文字列値"M2TS"に固定的とされる。次に８ビットのデータ長を有する領域reservedが配される。
【００９５】
図１７は、ブロックblkProgramInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkProgramInfo()の最後までのデータ長を示す。１５ビットのデータ長を有する領域reservedを介して、データ長が１ビットで固定値"１"が記述される。
【００９６】
フィールドSPNProgramSequenceStartは、３２ビットのデータ長を有し、対応するクリップＡＶストリームファイルにおいて、プログラムシーケンスが開始されるソースパケットの番号が記述される。フィールドProgramMapPIDは、１６ビットのデータ長を有し、プログラムシーケンスに適用可能なプログラムマップセクションを含むとされているＴＳパケットのＰＩＤの値を示す。フィールドNumberOfStreamsInPSは、８ビットのデータ長を有し、プログラムシーケンスに定義されるエレメンタリストリームの数を示す。フィールドNumberOfStreamsInPSに続けて、８ビットのデータ長を有する領域reservedが配される。
【００９７】
次のforループ文に従い、値[stream_index]をループ変数として、フィールドNumberOfStreamsInPSで示される数だけ、フィールドStreamPID[stream_index]およびブロックblkStreamCodingInfo(stream_index)の組が格納される。フィールドStreamPID[stream_index]は、プログラムシーケンスによって参照されたＰＭＴ(Program Map Table)に記述されたエレメンタリストリームに対応するＰＩＤの値を示す。次のブロックblkStreamCodingInfo(stream_index)は、対応するフィールドStreamPID[stream_index]で示されるエレメンタリストリームの符号化方式に関する情報が記述される。
【００９８】
図１８は、ブロックblkStreamCodingInfo(stream_index)の一例の構造を表すシンタクスを示す。フィールドLengthは、８ビットのデータ長を有し、このフィールドLengthの直後からブロックblkStreamCodingInfo(stream_index)の終わりまでのデータ長を示す。
【００９９】
フィールドLengthの次に、８ビットのデータ長を有するフィールドStreamCodingTypeが配される。フィールドStreamCodingTypeでは、値[stream_index]で示されるエレメンタリストリームの符号化のタイプが示される。一例として、フィールドStreamCodingTypeの値として値"0x1B"、値"0x80"、値"0x81"、値"0x90"および値"0x91"が定義され、当該ストリームの符号化タイプは、値"0x1B"でビデオストリーム、値"0x80"または値"0x81"でオーディオストリーム、値"0x90"でＯＢストリーム、値"0x91"でＭＢストリームであることがそれぞれ示される。次のif文に従い、このフィールドStreamCodingTypeの値に応じた記述がなされる。
【０１００】
フィールドStreamCodingTypeの値が例えば"0x1B"であって、値[stream_index]で示されるエレメンタリストリームがビデオストリームであることが示されれば、if文に従いフィールドVideoFormat、フィールドFrameRateおよびフィールドAspectRatioが記述され、２ビットのデータ長を有する領域reservedを介してさらにフラグCCFlagが記述される。フラグCCFlagの後には、１７ビットのデータ長を有する領域reservedと、１２８ビットのデータ長を有する領域reservedが配される。
【０１０１】
フィールドVideoFormatは、４ビットのデータ長を有し、値[stream_index]で示されるビデオデータのフォーマットを示す。図１９は、フィールドVideoFormatで示されるビデオデータの一例のフォーマットを一覧で示す。図１９に例示されるように、ビデオデータのフォーマットは、４ビットで表現可能な値"０"〜値"１５"で識別され、値"０"および値"８"〜値"１５"は、予約とされている。値"１"〜値"７"で、それぞれビデオデータのフォーマットの４８０ｉ、５７６ｉ、４８０ｐ、１０８０ｉ、７２０ｐ、１０８０ｐおよび５７６ｐを示す。
【０１０２】
なお、このビデオフォーマットの表記において、末尾の「ｉ」および「ｐ」は、それぞれインタレース走査およびプログレッシブ走査を示す。また、数字はライン数を示す。これらのビデオフォーマットは、ＩＴＵ(International Telecommunication Union)−Ｒ ＢＴ.６０１−４（４８０ｉおよび５７６ｉ）、ＩＴＵ−Ｒ ＢＴ.１３５８（５７６ｐ）、ＳＭＰＴＥ(Society of Motion Picture and Television Engineers) ２９３Ｍ（４８０ｐ）、ＳＭＰＴＥ ２７４Ｍ（１０８０ｉおよび１０８０ｐ）およびＳＭＰＴＥ ２９６Ｍ（７２０ｐ）により標準化されたフォーマットである。
【０１０３】
ブロックblkStreamCodingInfo(stream_index)において、フィールドFrameRateは、４ビットのデータ長を有し、値[stream_index]で示されるビデオデータのフレームレートを示す。図２０は、フィールドFrameRateで示される一例のフレームレートを一覧で示す。図２０に例示されるように、ビデオデータのフレームレートは、４ビットで表現可能な値"０"〜"１５"で識別され、値"０"、値"５"および値"８"〜値"１５"は、予約とされている。値"１"〜値"４"で、それぞれフレームレート（フィールド周波数）が（２４０００／１００１）Ｈｚすなわち略２３.９７Ｈｚ、２４Ｈｚ、２５Ｈｚおよび（３００００／１００１）Ｈｚすなわち略２９.９７Ｈｚを示す。また、値６および値７で、それぞれフレームレートが５０Ｈｚおよび（６００００／１００１）Ｈｚすなわち略５９.９４Ｈｚを示す。
【０１０４】
ブロックblkStreamCodingInfo(stream_index)において、フィールドAspectRatioは、４ビットのデータ長を有し、値[stream_index]で示されるビデオデータのアスペクト比を示す。図２１は、フィールドAspectRatioで示される一例のフレームレートを一覧で示す。図２１に例示されるように、ビデオデータのアスペクト比は、４ビットで表現可能な値"０"〜値"１５"で識別され、値"０"および値"１"、ならびに、値"４"〜値"１５"は、予約とされている。値"２"でアスペクト比が４：３を示す。値"３"でアスペクト比が１６：９を示す。
【０１０５】
ブロックblkStreamCodingInfo(stream_index)において、フィールドStreamCodingTypeの値が例えば"0x80"、"0x81"、"0x90"または"0x91"の場合も、if文における「else if」の記述に従い、それぞれの値が示す符号化タイプに応じた記述がなされる。なお、ビデオストリーム以外の符号化タイプのストリームに関する記述は、この発明と関連性が薄いので、詳細な説明を省略する
【０１０６】
図２２は、クリップインフォメーションファイルにおけるブロックblkCPI()の一例の構造を表すシンタクスを示す。ＭＰＥＧストリームのような、フレーム間圧縮を行っている符号化ストリームにおいては、デコード開始可能な箇所は、ＧＯＰ(Group Of Picture)の先頭など一部の箇所に限定されていることが多い。ＣＰＩ(Characteristic Point Information)とは、そのデコード可能な開始点の位置の情報を集めたデータベースで、再生時刻と、ファイル内アドレスとが対応付けられたテーブルになっている。すなわち、ＣＰＩは、デコード単位の先頭位置を示す情報がテーブル化されている。
【０１０７】
このようにデータベースを定めることで、例えば、任意の時刻から再生したい場合、再生時刻を元にＣＰＩを参照することによって再生位置のファイル内アドレスがわかる。このアドレスは、デコード単位の先頭となっているため、プレーヤは、そこからデータを読み出してデコードし、素早く画像を表示することができる。
【０１０８】
なお、このＣＰＩに格納される、デコード単位の先頭位置（この例ではＧＯＰの先頭位置）を、ＥＰ(Entry Point)エントリと称する。
【０１０９】
図２２において、フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkCPI()の最後までのデータ長を示す。次のif文に従い、フィールドLengthの値が０でなければ、１２ビットのデータ長を有する領域reservedを介してフィールドCPITypeが配される。フィールドCPITypeは、４ビットのデータ長を有し、ＣＰＩの種類を示す。次のブロックblkEPMap()は、対応するクリップＡＶストリームファイルにおけるＰＴＳ値とバイトアドレスとの関連付けを行うテーブルが格納される。
【０１１０】
図２３は、ブロックblkEPMap()の一例の構造を表すシンタクスを示す。８ビットのデータ長を有する領域reservedを介してフィールドNumberOfStreamPIDEntriesが配される。フィールドNumberOfStreamPIDEntriesは、８ビットのデータ長を有し、ブロックblkEPMap()におけるブロックblkEPMapForOneStreamPIDのエントリ数を示す。forループ文に従い、値[k]をループ変数として、フィールドNumberOfStreamPIDEntriesに示される数だけ、エントリポイントに関する情報が記述される。
【０１１１】
forループ文内において、フィールドStreamPID[k]は、１６ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目にエントリされるブロックblkEPMapForOneStreamPID（以下、[k]番目のブロックblkEPMapForOneStreamPIDと記述する）によって参照されるエレメンタリストリームを伝送するトランスポートパケットのＰＩＤの値を示す。
【０１１２】
１０ビットのデータ長を有する領域reservedを介してフィールドEPStreamType[k]が配される。フィールドEPStreamType[k]は、４ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDによって参照されるエレメンタリストリームのタイプを示す。フィールドNumberOfEPCoarseEntries[k]は、１６ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある粗い検索用のサブテーブル(EP coarse table)のエントリ数を示す。フィールドNumberOfEPFineEntries[k]は、１８ビットのデータ長を有し、[k]番目のブロックblkEPMapForOneStreamPIDの中にある精密な検索用のサブテーブル(EP fine table)のエントリ数を示す。フィールドEPMapForOneStreamPIDStartAddress[k]は、３２ビットのデータ長を有し、ブロックblkEPMap()の中で[k]番目のブロックblkEPMapForOneStreamPIDが始まる相対バイト位置を示す。この値は、ブロックblkEPMap()の第１バイト目からのバイト数で示される。
【０１１３】
上述のforループ文による記述の後、１６ビットの整数倍のデータ長を有するパディングワードを挟んで記述される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と呼ぶ。
【０１１４】
図２４は、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の一例の構造を表すシンタクスを示す。ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)のセマンティクスを説明するために、先ず、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)に格納されるデータの元となるエントリである、エントリPTSEPStartおよびエントリSPNEPStartの意味について説明する。
【０１１５】
エントリPTSEPStartと、エントリPTSEPStartに関連付けられたエントリSPNEPStartは、それぞれＡＶストリーム上のエントリポイントを指す。そして、エントリPTSEPFineと、エントリPTSEPFineに関連付けられたエントリPTSEPCoarseは、同一のエントリPTSEPStartから導かれる。また、エントリSPNEPFineと、エントリSPNEPFineに関連付けられたエントリSPNEPCoarseは、同一のエントリSPNEPStartから導かれる。
【０１１６】
図２５は、エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す。ＰＴＳすなわちエントリPTSEPStartは、データ長が３３ビットの値である。ＭＳＢのビットを第３２ビット、ＬＳＢのビットを第０ビットとするとき、この図２５の例では、大まかな単位で検索を行う際に用いられるエントリPTSEPCoarseは、エントリPTSEPStartの第３２ビットから第１９ビットまでの１４ビットが用いられる。エントリPTSEPCoarseにより、解像度が５．８秒で、２６．５時間までの範囲で検索が可能である。また、より精密な検索を行うためのエントリPTSEPFineは、エントリPTSEPStartの第１９ビットから第９ビットまでの１１ビットが用いられる。エントリPTSEPFineにより、解像度が５．７ミリ秒で、１１．５秒までの範囲で検索が可能である。なお、第１９ビットは、エントリPTSEPCoarseとエントリPTSEPFineとで共通して用いられる。また、ＬＳＢ側の第０ビットから第８ビットまでの９ビットは、用いられない。
【０１１７】
図２６は、エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す。ソースパケット番号すなわちエントリSPNEPStartは、データ長が３２ビットの値である。ＭＳＢのビットを第３１ビット、ＬＳＢのビットを第０ビットとするとき、この図２６の例では、大まかな単位で検索を行う際に用いられるエントリSPNEPCoarseは、エントリSPNEPStartの第３１ビットから第０ビットまでの全てのビットが用いられる。また、より精密な検索を行うためのエントリSPNEPFineは、エントリSPNEPStartの第１６ビットから第０ビットまでの１７ビットが用いられる。エントリSPNEPFineにより、例えば略２５ＭＢ(Mega Byte)のＡＶストリームファイルまでの範囲で、検索が可能である。
【０１１８】
なお、ソースパケット番号の場合でも、エントリSPNEPCoarseとしてＭＳＢ側の所定ビット数の値だけ用いるようにしてもよい。例えば、エントリSPNEPCoarseとして、エントリSPNEPStartの第３１ビットから第１６ビットまでの１７ビットを用い、エントリSPNEPFineは、エントリSPNEPStartの第１６ビットから第０ビットまでの１７ビットを用いる。
【０１１９】
上述に基づき、エントリPTSEPStartおよびエントリSPNEPStartは、次のように定義される。
【０１２０】
エントリPTSEPStartは、図２５で示したように、データ長が３３ビットの符号無し整数であり、ＡＶストリーム中で、ランダムアクセスが可能なピクチャ（例えばＩＤＲ(Instantaneous Decoding Refresh)ピクチャやＩ(Intra)ピクチャ）から開始するビデオアクセスユニットの３３ビット長のＰＴＳを示す。
【０１２１】
エントリSPNEPStartは、図２６で示したように、３２ビットの符号無し整数であり、エントリPTSEPStartに関連付けられたビデオアクセスユニットの第１バイト目を含むソースパケットの、ＡＶストリームの中でのアドレスを示す。エントリSPNEPStartは、ソースパケット番号の単位で表され、ＡＶストリームファイル中の最初のソースパケットから、値"０"を初期値として、ソースパケット毎に１ずつ増加する値としてカウントされる。
【０１２２】
図２４を参照し、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)は、第１のforループ文により大まかな単位での検索を行うためのサブテーブル(EP coarse table)が記述され、第２のforループ文によりサブテーブル(EP coarse table)の検索結果に基づきより詳細な検索を行うためのサブテーブル(EP fine table)が記述される。
【０１２３】
第１のforループ文の直前に、フィールドEPFineTableStartAddressが配される。フィールドEPFineTableStartAddressは、３２ビットのデータ長を有し、最初の第２のforループにおけるフィールドReservedEPFine[EP_fine_id]の第１バイト目の開始アドレスを、ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の第１バイト目からの相対バイト数で示す。相対バイト数は、値"０"から開始する。
【０１２４】
第１のforループ文は、ループ変数[i]で以て、サブテーブル(EP coarse table)のエントリ数Ncまで繰り返され、エントリ数Ncの組数だけフィールドRefToEPFineID[i]、エントリPTSEPCoarse[i]およびエントリSPNEPCoarse[i]が格納される。第１のforループ文において、フィールドRefToEPFineID[i]は、１８ビットのデータ長を有し、フィールドRefToEPFineID[i]に続くフィールドPTSEPCoarse[i]が示すエントリPTSEPCoarseに関連付けられるエントリPTSEPFineを持つ、サブテーブル(EP fine table)内のエントリ番号を示す。エントリPTSEPFineと、このエントリPTSEPFineに関連付けられるエントリPTSEPCoarseとは、同一のエントリPTSEPStartから導かれる。フィールドRefToEPFineID[i]は、第２のforループ文中で記述される順番で定義されるループ変数[EP_fine_id]の値により与えられる。
【０１２５】
第１のforループ文の後に、パディングワードを挟んで第２のforループ文による記述がなされる。第２のforループ文は、ループ変数[EP_fine_id]で以て、サブテーブル(EP fine table)のエントリ数Nfまで繰り返され、エントリ数Nfの組数だけ、１ビットのデータ長を有するフィールドReservedEPFine[EP_fine_id]と、３ビットのデータ長を有するフィールドIEndPositionOffset[EP_fine_id]と、１１ビットのデータ長を有するフィールドPTSEPFine[EP_fine_id]と、１７ビットのデータ長を有するフィールド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から、次式（１）のように導かれる。
PTSEPFine[EP_fine_id]＝（PTSEPStart[EP_fine_id] >>９）／２¹¹ ・・（１）
【０１２７】
エントリPTSEPCoarseと、対応するエントリPTSEPFineとの関係は、次式（２）、（３）の通りである。
PTSEPCoarse[i]＝（PTSEPStart[RefToEPFineID[i]] >>１９）／２¹⁴ ・・（２）
PTSEPFine[RefToEPFineID[i]]＝（PTSEPStart[RefToEPFineID[i]] >>９）／２¹¹ ・・（３）
【０１２８】
それぞれのエントリSPNEPFineは、対応するエントリSPNEPStartから、次式（４）のように導かれる。
SPNEPFine[EP_fine_id]＝SPNEPStart[EP_fine_id]／２¹⁷ ・・（４）
【０１２９】
エントリSPNEPCoarseと、対応するエントリSPNEPFineとの関係は、次式（５）、（６）の通りである。
SPNEPCoarse[i]＝SPNEPStart[RefToEPFineID[i]] ・・（５）
SPNEPFine[RefToEPFineID[i]]＝SPNEPStart[RefToEPFineID[i]]／２¹⁷ ・・（６）
【０１３０】
なお、上述の式（１）〜（６）において、記号「>>ｘ」は、データのＬＳＢ側からｘビットを超える桁からビットを用いることを意味する。
【０１３１】
次に、拡張データを格納するためのブロックblkExtensionData()について説明する。このブロックblkExtensionData()は、所定の拡張データを格納可能なように定義され、インデックステーブルが格納されるファイル"index.bdmv"、プレイリストが格納されるファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"の各ファイルに記述することができる。
【０１３２】
図２７は、ブロックblkExtensionData()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkExtensionData()の終わりまでのデータ長をバイト数で示す。このフィールドLengthの示すデータ長が"０"でなければ、if文以下の記述がなされる。
【０１３３】
フィールドDataBlockStartAddressは、３２ビットのデータ長を有し、このシンタクス中の、拡張データの本体が格納されるブロックDataBlock()の開始アドレスを、このブロックblkExtensionData()の先頭バイトからの相対バイト数で示す。すなわち、相対バイト数は、"０"から開始される。なお、フィールドDataBlockStartAddressは、次に示す３２ビットアライメントの条件を満たさなければならない。
DataBlockStartAddress％４＝０
【０１３４】
２４ビットのデータ長を有する領域reservedを介してフィールドNumberOfExtDataEntriesが配される。フィールドNumberOfExtDataEntriesは、８ビットのデータ長を有し、このブロックblkExtensionData()のブロックDataBlock()に格納される拡張データのエントリ数を示す。拡張データのエントリは、拡張データの本体を取得するための情報が格納される。この例では、拡張データのエントリは、フィールドExtDataType、フィールドExtDataVersion、フィールドExtDataStartAddressおよびフィールドExtDataLengthからなるブロックext_data_entry()であって、ブロックblkExtensionData()において、第１のforループ文に従いこのフィールドNumberOfExtDataEntriesに示される個数だけ、このブロックext_data_entry()が存在する。
【０１３５】
フィールドExtDataTypeは、１６ビットのデータ長を有し、このブロックblkExtensionData()に記述される拡張データが記録装置用の拡張データであることを表す。このフィールドExtDataTypeの値は、拡張データを識別する第１の値であり、このブロックblkExtensionData()を含む規格書のライセンサ（使用認可者）が割り当てると定義することができる。フィールドExtDataVersionは、拡張データを識別する第２の値であり、この拡張データのバージョン番号を表すものと定義することができる。なお、このブロックblkExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionの値が同一のブロックext_data_entry()が２以上、存在してはならない。
【０１３６】
フィールドExtDataStartAddressは、３２ビットのデータ長を有し、このフィールドExtDataStartAddressが含まれる拡張データのエントリ（ブロックext_data_entry()）に対応する拡張データの開始アドレスを示す。フィールドExtDataStartAddressは、ブロックblkExtensionData()の先頭バイトからの相対バイト数で、拡張データext_dataの開始アドレスを示す。なお、フィールドExtDataStartAddressは、次に示す３２ビットアライメントの条件を満たさなければならない。
ExtDataStartAddress％４＝０
【０１３７】
フィールドExtDataLengthは、３２ビットのデータ長を有し、このフィールドExtDataStartAddressが含まれる拡張データのエントリ（ブロックext_data_entries()）に対応する拡張データのデータ長を示す。データ長は、バイト数で示される。
【０１３８】
フィールドNumberOfExtDataEntriesで示された個数だけ、拡張データのエントリ（ブロックext_data_entry()）が記述されると、それぞれ１６ビットのデータ長を有し任意のデータ列からなるフィールドpadding_wordが、２フィールドを組として任意の回数L1だけ繰り返される。その後、拡張データの本体が格納されるブロックDataBlock()が記述される。ブロックDataBlock()は、１以上の拡張データが格納される。それぞれの拡張データext_dataは、上述したフィールドExtDataStartAddressフィールドExtDataLengthに基づき、ブロックDataBlock()から取り出される。
【０１３９】
図２８は、ブロック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()とによる２層構造とすることで、複数の拡張データを格納することが可能となる。
【０１４２】
次に、上述の拡張データの一例の作成方法および読み出し方法について説明する。図２９は、ブロックblkExtensionData()にデータを書き込む際の一例の処理を示すフローチャートである。この図２９は、ブロックblkExtensionData()中の（ｎ＋１）番目のエントリとして、拡張データを追加し、ブロックblkExtensionData()を書き換える場合の例である。
【０１４３】
先ず、ステップＳ１０で、書き込もうとしている拡張データのデータ長を取得し、フィールドExtDataLength[n+1]の値にセットする。なお、「[n+1]」の記述は、（ｎ＋１）番目のエントリの番号に対応する。次に、ステップＳ１１で、現在のブロックblkExtensionData()に列挙されているブロックext_data_entry()のフィールドExtDataLengthおよびフィールドExtDataStartAddressの値を調べ、ブロックDataBlock()の使用状況を取得する。
【０１４４】
そして、次のステップＳ１２で、ブロックDataBlock()中に、書き込もうとしている拡張データのデータ長であるフィールドExtDataLength[n+1]に示されるデータ長以上の、連続した空き領域があるか否かが判断される。若し、あると判断されれば、処理はステップＳ１４に移行される。
【０１４５】
一方、フィールドExtDataLength[n+1]に示されるデータ長以上の連続した空き領域が無いと判断されれば、処理はステップＳ１３に移行され、ブロックblkExtensionData()におけるフィールドLengthの値を大きくし、フィールドExtDataLength[n+1]に示されるデータ長以上の連続した空き領域をブロックDataBlock()内に作る。空き領域ができたら、処理がステップＳ１４に移行される。
【０１４６】
ステップＳ１４では、拡張データを書き込む領域の先頭アドレスを決め、その先頭アドレスの値をフィールドExtDataStartAddress[n+1]とする。次のステップＳ１５で、フィールドExtDataStartAddress[n+1]から、上述のステップＳ１０でセットされたフィールドExtDataLength[n+1]の長さの拡張データext_data[n+1]を書き込む。
【０１４７】
データの書き込みが終了したら、ステップＳ１６で、ブロックext_data_entry()に対して、フィールドExtDataLength[n+1]と、フィールドExtDataStartAddress[n+1]とを追加する。
【０１４８】
なお、上述において、書き換えを行うブロックblkExtensionData()は、すでにディスクなどの記録媒体から読み出されて記録装置のメモリに記憶されているものとする。そのため、ステップＳ１３における、フィールドLengthの値の変更によるブロックblkExtensionData()の拡大は、システムに任され、システムがメモリアロケーションを適切に行うことでなされる。
【０１４９】
図３０は、ブロックblkExtensionData()から拡張データを読み出す際の一例の処理を示すフローチャートである。なお、この図３０のフローチャートによる処理は、再生専用の記録媒体と、記録可能な記録媒体との両方に適用可能なものである。先ず、最初のステップＳ２０で、読み込もうとする拡張データが準拠する規格から、フィールドExtDataTypeの値を取得し、ステップＳ２１で、読み込もうとする拡張データの種別から、フィールドExtDataVersionの値を取得する。
【０１５０】
次のステップＳ２２で、ブロックblkExtensionData()に列挙されているブロックext_data_entry()を１つずつ順次、読み込む。そして、ステップＳ２３で、読み込んだブロックext_data_entry()に含まれるフィールドExtDataTypeおよびフィールドExtDataVersionの値が、上述のステップＳ２０およびステップＳ２１で取得したフィールドExtDataTypeおよびフィールドExtDataVersionの値と一致するか否かが判断される。
【０１５１】
一致していないと判断されれば、処理はステップＳ２６に移行され、ブロックblkExtensionData()内に列挙されるブロックext_data_entry()を全て読み終えたか否かが判断される。全て読み終えたと判断されれば、処理はステップＳ２７に移行され、このブロックblkExtensionData()には、読み込もうとした拡張データが存在しないとして、一連の処理が終了される。全て読み終えていないと判断されれば、処理はステップＳ２２に戻され、次のブロックext_data_entry()が読み込まれる。
【０１５２】
上述のステップＳ２３において、ブロックext_data_entry()に含まれるフィールドExtDataTypeおよびフィールドExtDataVersionの値が、取得したフィールドExtDataTypeおよびフィールドExtDataVersionの値と一致していると判断されれば、処理はステップＳ２４に移行される。ここでは、ブロックblkExtensionData()中の[i]番目のエントリで一致したものとする。
【０１５３】
ステップＳ２４では、[i]番目のエントリのブロックext_data_entry()からフィールドExtDataLength[i]の値と、フィールドExtDataStartAddress[i]の値とを読み込む。そして、ステップＳ２５で、ステップＳ２４で読み込んだフィールドExtDataStartAddress[i]で示されるアドレスから、フィールドExtDataLength[i]で示されるデータ長だけ、データを読み出す。
【０１５４】
次に、上述した、インデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"にそれぞれ定義可能な、拡張データを格納する拡張データブロックblkExtensionData()について説明する。
【０１５５】
先ず、インデックスファイル"index.bdmv"に対して定義される一例の拡張データブロックについて説明する。ここでは、プレイリスト毎に記録可能な記録媒体に特有の属性情報を付加するようにした、一例の拡張データブロックについて説明する。図３１は、このプレイリスト属性を記述するための、ファイル"index.bdmv"内のフィールドblkExtensionData()におけるブロックDataBlock()（図２７参照）の一例の構造を表すシンタクスを示す。この図３１の例では、ブロックDataBlock()がブロックblkIndexExtensionData()として記述されている。
【０１５６】
先ず、上述の図２７を参照して、ブロックblkExtensionData()においてフィールドExtDataTypeを値"0x1000"、フィールドExtDataVersionを値"0x0100"とする。これらフィールドExtDataTypeおよびフィールドExtDataVersionに記述された値は、例えば再生装置側において、予めＲＯＭ(Read Only Memory)などに記憶されたテーブルが参照されて識別される。ブロックDataBlock()内のフィールドExtDataStartAddressおよびフィールドExtDataLengthで示される領域に、ブロックblkIndexExtensionData()が格納される。
【０１５７】
ブロックblkIndexExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ＩＳＯ６４６に規定された符号化方式で符号化した４文字からなる文字列が記述される。この図３１の例では、フィールドTypeIndicatorにＩＳＯ６４６に既定の方式で符号化された４文字の文字列"IDEX"が記述され、次に続くデータ種類がインデックスファイルにおける拡張データであることが示される。
【０１５８】
フィールドTypeIndicatorに続けて３２ビットのデータ長を有する領域reservedが配され、その次に、３２ビットのデータ長を有するフィールドTableOfPlayListStartAddressが配される。フィールドTableOfPlayListStartAddressは、ブロックblkTableOfPlayList()の、このブロックblkIndexExtensionData()先頭を基準とした開始アドレスが示される。
【０１５９】
フィールドTableOfPlayListStartAddressの次に、３２ビットのデータ長を有するフィールドMakersPrivateDataStartAddressが配されブロックblkMakersPrivateData()のこのブロックblkIndexExtensionData()先頭を基準とした開始アドレスが示され、１９２ビットのデータ長を有する領域reservedを介してブロックblkUIAppInfoAVCHD()が配される。１６ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkTableOfPlayLists()が配される。さらに続けて、１６ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次にブロックblkMakersPrivateData()が配される。このブロックblkMakersPrivateData()の後に、１６ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
【０１６０】
なお、ブロックblkUIAppInfoAVCHD()およびブロックblkMakersPrivateData()は、この発明と関連性が薄いので、説明を省略する。
【０１６１】
図３２は、上述したブロックblkTableOfPlayLists()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkTableOfPlayLists()の最後のバイトまでのデータ長をバイト数で示す。フィールドLengthに続けて、プレイバックタイトルを再生するためのプレイリストに関する情報が記述されるブロックblkFirstPlaybackTitlePlayLists()と、メニュータイトルに関する情報が記述されるブロックblkMenuTitlePlayLists()とが配される。これらブロックblkFirstPlaybackTitlePlayLists()およびブロックblkMenuTitlePlayLists()は、この発明と関連性が薄いので、説明を省略する。
【０１６２】
次に、１６ビットのデータ長を有するフィールドNumberOfTitlePlayListPairが配される。フィールドNumberOfTitlePlayListPairは、プレイバックタイトルおよびメニュータイトル以外のタイトルを再生するためのプレイリストの数が記述される。次のforループ文に従い、フィールドNumberOfTitlePlayListPairで示される数だけ、ブロックblkMovieTitlePlayListPair()が記述される。ブロックblkMovieTitlePlayListPair()は、フィールドPlayListFileName、フィールドPlayListAttributeおよびフィールドRefToTitleIdを含む。すなわち、ブロックblkMovieTitlePlayListPair()は、このforループ文で示される[i]番目のプレイリストについて、当該プレイリストのファイル名、当該プレイリストに付与された属性、ならびに、当該プレイリストの参照タイトルＩＤからなるプレイリストの情報を構造化したものである。
【０１６３】
このforループ文による並び順は、記録順とされる。すなわち、１のプレイリストが追加されると、フィールドNumberOfTitlePlayListPairの値が"１"だけインクリメントされ、既存のプレイリストの情報の後ろに、追加されたプレイリストの情報が追記される。
【０１６４】
フィールドPlayListFileNameは、４０ビット（５バイト）のデータ長を有し、プレイリストのファイル名がＩＳＯ６４６に規定された符号化方式で符号化されて記述される。フィールドPlayListFileNameの次に、６ビットのデータ長を有する領域reservedを介してフィールドPlayListAttributeが配される。フィールドPlayListAttributeは、２ビットのデータ長を有し、当該プレイリストに付与された属性を示す。プレイリストは、その成因に基づき、クリップの生成と共に生成されるプレイリストに対応する第１の種類と、既存のタイトルあるいはプレイリストの一部または全部を用いて作成されるプレイリストに対応する第２の種類と、メニューを再生するために用いる第３の種類との３種類に分けられ、各プレイリストには、プレイリストの種類に応じて、それぞれ対応する属性「Real」（第１の種類）、属性「Virtual」（第２の種類）および属性「Menu」（第３の種類）が付与される。
【０１６５】
なお、以下では適宜、属性「Real」が付与されたプレイリストをリアルプレイリスト、属性「Virtual」が付与されたプレイリストをバーチャルプレイリスト、属性「Menu」を付与されたプレイリストをメニュープレイリストと呼ぶ。
【０１６６】
フィールドRefToTitleIdは、同一ループ内のフィールドPlayListFileNameに示されるプレイリストが作成時に属するタイトルのＩＤ（番号）が記述される。より具体的な例としては、インデックスファイル"index.bdmv"内のブロックblkIndexes()における、対応する値title_idが記述される。なお、当該プレイリストがファーストプレイバックタイトルのみから再生される場合、フィールドRefToTitleIdの値は、第１の固定値、例えば"0xFFFF"とされる。また、当該プレイリストがメニュータイトルのみから再生される場合は、フィールドRefToTitleIdの値は、第２の固定値、例えば"0xFFFE"とされる。
【０１６７】
ここで、リアルプレイリスト、バーチャルプレイリストおよびメニュープレイリストについて、概略的に説明する。属性「Real」が付されるリアルプレイリストは、例えばクリップの生成と共に生成され、ディスクに記録される。リアルプレイリストは、素材を指す最初のプレイリストとなることから、オリジナルのプレイリストとも呼ばれる。一例として、リアルプレイリストは、生成されたクリップの先頭をＩＮ点、最後尾をＯＵＴ点としてそれぞれ指定する。
【０１６８】
リアルプレイリストは、ストリーム実体であるクリップを参照したプレイリストであって、新規にクリップが作成されると、作成されたクリップを参照するリアルプレイリストが必ず作成される。換言すれば、ディスク上において、どのリアルプレイリストからも参照されていないクリップは存在しない。したがって、ディスク上におけるリアルプレイリストの総再生時間は、当該ディスク上に記録されたクリップの総再生時間に一致することになる。すなわち、ディスク上における記録可能な残り時間は、ユーザから見ると、リアルプレイリストまたはリアルプレイリストのみから構成されるタイトルの記録可能時間に一致する。
【０１６９】
リアルプレイリストは、素材であるクリップと常に１対１の対応関係を有し、リアルプレイリストを編集などにより削除すると、対応するクリップも、ディスク上から削除される。また、リアルプレイリストにおいて、クリップの参照区間の一部を削除すると、削除された部分に応じて、当該リアルプレイリストに対応するクリップの一部も削除される。このように、リアルプレイリストに対する編集は、ディスク上に記録されるクリップの実体の改変を伴う編集であるため、実体編集あるいはリアル編集などと呼ばれる。
【０１７０】
属性「Virtual」が付されるバーチャルプレイリストは、既存のタイトルあるいはプレイリストの一部または全部を用いて作成されるプレイリストである。バーチャルプレイリストは、既存のクリップに対してＩＮ点およびＯＵＴ点を設定し、ＩＮ点およびＯＵＴ点で定義される区間を参照して作成したプレイリストである。
【０１７１】
一例として、バーチャルプレイリストは、上述したリアルプレイリストに対してＩＮ点およびＯＵＴ点を指定する。例えば、複数のリアルプレイリストに対し、それぞれＩＮ点およびＯＵＴ点を指定すると共に、それぞれＩＮ点およびＯＵＴ点で指定される複数の区間の再生順を指定する。バーチャルプレイリストを元にして、さらにバーチャルプレイリストを作成することもできる。すなわち、１または複数のバーチャルプレイリストに対して、ＩＮ点およびＯＵＴ点を指定するバーチャルプレイリストを作成することができる。
【０１７２】
バーチャルプレイリストは、編集において、例えばサイズの大きなクリップ（ストリーム実体）を変更すること無しに、高速に作成可能である。また、バーチャルプレイリストは、削除する際も、クリップに対する参照関係のみを削除すればよく、クリップ実体に対して変更を加える必要が無い。このように、バーチャルプレイリストの編集は、クリップの実体の改変を伴わない編集であるため、仮想編集あるいはバーチャル編集などと呼ばれる。
【０１７３】
属性「Menu」が付されるメニュープレイリストは、メニューを再生するために用いるプレイリストであり、メニューの作成および更新時に生成される。メニュープレイリストは、すなわち、メニュータイトルを再生するためのムービーオブジェクトから呼び出されるプレイリストである。
【０１７４】
次に、プレイリストファイル"xxxxx.mpls"に対して定義される一例の拡張データブロックについて説明する。図３３は、プレイリストファイル"xxxxx.mpls"内のブロックblkExtensionData()におけるブロックDataBlock()（図２７参照）の一例の構造を表すシンタクスを示す。この図３３の例では、ブロックDataBlock()がブロックblkPlayListExtensionData()として記述されている。
【０１７５】
先ず、上述の図２７を参照し、プレイリストファイル"xxxxx.mpls"内のブロックblkExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionがそれぞれ所定の値、例えば上述と同様にそれぞれ値"0x1000"、値"0x0100"とする。
【０１７６】
ブロックblkPlayListExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ＩＳＯ６４６に規定された符号化方式で符号化した４文字からなる所定の文字列が記述される。このフィールドTypeIndicatorに記述される文字列によって、次に続くデータ種類がプレイリストファイルにおける拡張データであることが示される。
【０１７７】
フィールドTypeIndicatorの次に、３２ビット（４バイト）のデータ長を有する領域reservedを介して３２ビットのデータ長を有するフィールドPlayListMarkExtStartAddressが配され、その次に、３２ビットのデータ長を有するフィールドMakersPrivateDataStartAddressが配される。フィールドPlayListMarkExtStartAddressおよびフィールドMakersPrivateDataStartAddressは、それぞれ、ブロックblkPlayListMarkExt()およびブロックblkMakersPrivateData()の、このブロックblkPlayListExtensionData()先頭を基準とした開始アドレスが示される。
【０１７８】
フィールドMakersPrivateDataStartAddressの次に、１９２ビットのデータ長を有する領域reservedを介してブロックblkPlayListMeta()が配される。１６ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkPlayListMarkExt()が配される。さらに、１６ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次に、ブロックblkMakersPrivateData()が配される。ブロックblkMakersPrivateData()の後ろには、１６ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
【０１７９】
図３４は、ブロックblkPlayListMeta()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLength直後からこのブロックblkPlayListMeta()の終わりまでのデータ長を示す。フィールドLengthの次に、それぞれ１６ビットのデータ長を有するフィールドMakerIDおよびフィールドMakerModelCodeが配される。フィールドMakerIDおよびフィールドMakerModelCodeは、このプレイリストファイルを更新したメーカおよび当該メーカの機種を識別する情報がそれぞれ記述される。
【０１８０】
フィールドMakerModelCodeの次に、３２ビットのデータ長を有する領域reservedを介して１６ビットのデータ長を有するフィールドRefToMenuThumbnailIndexが配される。このフィールドRefToMenuThumbnailIndexは、このプレイリストファイルにより再生される一連のクリップを代表するサムネイル画像が存在する場合、そのサムネイル画像を特定するサムネイル番号が記述される。次に８ビットのデータ長を有するブロックblkTimeZone()が配され、このプレイリストファイルを更新した際に、装置に設定されているタイムゾーンを示す情報が記述される。さらに５６ビットのデータ長を有するフィールドRecordTimeAndDateが配され、このプレイリストファイルを更新した時刻および日付が記述される。
【０１８１】
フィールドRecordTimeAndDateの次に、８ビットのデータ長を有する領域reservedを介して、それぞれ８ビットのデータ長を有するフィールドPlayListCharacterSetおよびフィールドPlayListNameLengthが配され、さらに続けて、２５５バイトのデータ長を有するフィールドPlayListNameが配される。これらフィールドPlayListCharacterSet、フィールドPlayListNameLengthおよびフィールドPlayListNameにより、このプレイリストファイルにより示されるプレイリストに付された名前に関する情報が記述される。
【０１８２】
すなわち、フィールドPlayListCharacterSetは、フィールドPlayListNameに記述されている文字列の文字セットが示される。フィールドPlayListNameLengthは、フィールドPlayListNameに記述されるプレイリスト名のバイト長を示す。フィールドPlayListNameは、このプレイリストに付された名前が記述される。このフィールドPlayListNameにおいて、左から、フィールドPlayListNameLengthに示されるだけのバイト数が有効な文字列であり、それがこのプレイリストの名前とされる。フィールドPlayListNameの中で、フィールドPlayListNameLengthで示された有効な文字列の後のバイト列には、どのような値が入っていてもよい。
【０１８３】
フィールドPlayListNameの次に、ブロックAdditional_data()が配される。このブロックAdditional_data()は、追加的な情報を格納するために予約された領域であって、３２ビットのデータ長を有するフィールドLength2に示される値のバイト数分のデータ長を有する領域が予約される。
【０１８４】
図３５は、プレイリストファイルにおけるブロックblkMakersPrivateData()の一例の構造を表すシンタクスを示す。ブロックblkMakersPrivateData()は、このプレイリストファイルに関して、メーカ独自の情報が記述されるブロックである。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLength直後からこのブロックblkMakersPrivateData()の終わりまでのデータ長を示す。このフィールドLengthは、値"０"でこのMakersPrivateData()に情報が記述されていないことを示す。フィールドLengthが値"０"以外で、if文以下の記述がなされる。
【０１８５】
フィールドDataBlockStartAddressは、３２ビットのデータ長を有し、このシンタクス中の、メーカ独自情報本体が格納されるブロックDataBlock()の開始アドレスを、このブロックblkMakersPrivateData()の先頭バイトからの相対バイト数で示す。２４ビットのデータ長を有する領域reservedを介して、８ビットのデータ長を有するフィールドNumberOfMakerEntriesが配される。
【０１８６】
次のfor文に従い、フィールドNumberOfMakerEntriesで示される個数だけ拡張データのエントリ、すなわち、フィールドMakerID、フィールドMakerModelCode、フィールドMpdStartAddressおよびフィールドMpdLengthが記述される。フィールドMakerIDおよびフィールドMakerModelCodeは、それぞれ１６ビットのデータ長を有し、メーカの識別情報および当該メーカによる機種の識別情報が記述される。また、フィールドMpdStartAddressおよびフィールドMpdLengthは、それぞれ３２ビットのデータ長を有し、拡張データの本体が格納されるブロックDataBlock()の、このブロックblkExtensionData()の先頭バイトからの相対バイト数による開始アドレスと、データ長とを示す。
【０１８７】
フィールドNumberOfMakerEntriesで示される個数だけ拡張データのエントリが記述されると、それぞれ１６ビットのデータ長を有し任意のデータ列からなるフィールドpadding_wordが、２フィールドを組として任意の回数L1だけ繰り返される。その後、拡張データの本体が格納されるブロックDataBlock()が記述される。ブロックDataBlock()は、１以上の拡張データext_dataが格納される。すなわち、フィールドMakerIDおよびフィールドMakerModelCodeで示されるメーカおよび機種毎に、メーカ独自の拡張データがブロックDataBlock()に格納される。それぞれの拡張データは、上述したフィールドMpdStartAddressおよびフィールドMpdLengthに基づき、ブロックDataBlock()から取り出される。
【０１８８】
なお、プレイリストファイルにおける拡張データブロックblkPlayListExtensionData()内のブロックblkPlayListMarkExt()は、この発明と関連性が薄いので、説明を省略する。
【０１８９】
次に、クリップインフォメーションファイル"zzzzz.clpi"に対して定義される一例の拡張データブロックについて説明する。図３６は、クリップインフォメーションファイル内のブロックblkExtensionData()におけるブロックDataBlock()（図２７参照）の一例の構造を表すシンタクスを示す。この図３６の例では、ブロックDataBlock()がブロックblkClipExtensionData()として記述されている。
【０１９０】
ブロックblkClipExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ＩＳＯ６４６に規定された符号化方式で符号化した４文字からなる所定の文字列が記述される。このフィールドTypeIndicatorに記述される文字列によって、次に続くデータ種類がクリップインフォメーションファイルにおける拡張データであることが示される。
【０１９１】
フィールドTypeIndicatorの次に、３２ビット（４バイト）のデータ長を有する領域reservedを介して、それぞれ３２ビットのデータ長を有するフィールドProgramInfoExtStartAddressおよびフィールドMakersPrivateDataStartAddressが配される。フィールドProgramInfoExtStartAddressおよびフィールドMakersPrivateDataStartAddressは、それぞれ、このブロックblkClipExtensionData()内のブロックblkProgramInfoExt()およびブロックblkMakersPrivateData()の、このブロックblkClipExtensionData()先頭を基準とした開始アドレスを示す。
【０１９２】
フィールドMakersPrivateDataStartAddressの次に、１９２ビットのデータ長を有する領域reservedを介してブロックblkClipInfoExt()が配される。１６ビットのデータ長を有するパディングワードpadding_wordが値N1で示される回数だけ繰り返され、次に、ブロックblkProgramInfoExt()が配される。続けて、１６ビットのデータ長を有するパディングワードpadding_wordが値N2で示される回数だけ繰り返され、次に、ブロックblkMakersPrivateData()が配される。ブロックblkMakersPrivateData()の後ろには、１６ビットのデータ長を有するパディングワードpadding_wordが値N3で示される回数だけ繰り返される。
【０１９３】
図３７は、ブロックblkProgramInfoExt()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkProgramInfoExt()の最後までのデータ長を示す。次に、８ビットのデータ長を有する領域reservedを介して、フィールドNumberOfProgramSequenceが配される。
【０１９４】
フィールドNumberOfProgramSequenceは、８ビットのデータ長を有し、このブロックblkProgramInfoExt()に記述されるプログラムシーケンスの情報の数が示される。この例では、フィールドNumberOfProgramSequenceの値が"１"に固定的とされている。次の第１のforループ文に従い、フィールドNumberOfProgramSequenceで示される数だけ、フィールドNumberOfStreamCodingInfoExtInPs[i]およびさらに次の第２のforループ文が繰り返される。第２のforループ文により、８ビットのデータ長を有するフィールドNumberOfStreamCodingInfoExtInPs[i]で示される数だけ、フィールドStreamPID[i][j]およびブロックblkStreamCodingInfoExt(i,j)の組が格納される。
【０１９５】
１６ビットのデータ長を有するフィールドStreamPID[i][j]は、値[i]および値[j]で指し示されるテーブルを構成し、[i]番目のプログラムシーケンスによって参照されたＰＭＴ(Program Map Table)に記述されたエレメンタリストリームに対応するＰＩＤの値を示す。次のブロックblkStreamCodingInfoExt(i,j)は、値[i]および値[j]で示されるエレメンタリストリームの符号化方式に関する情報が記述される。
【０１９６】
図３８は、ブロックblkStreamCodingInfoExt(i,j)の一例の構造を表すシンタクスを示す。フィールドLengthは、８ビットのデータ長を有し、このフィールドLengthの直後からブロックblkStreamCodingInfoExt(i,j)の最後までのデータ長を示す。次のフィールドStreamCodingTypeは、８ビットのデータ長を有し、対応するストリームの符号化の種類を示す。このフィールドStreamCodingTypeが値"0x1B"で、if文以下の記述がなされ、最初の８ビットのデータ長を有するフィールドHorizontalSizeにより、画面の垂直方向のサイズすなわちライン数を示す。なお、ブロックblkStreamCodingInfoExt(i,j)において、フィールドHorizontalSize以下の情報は、この発明と関連性が薄いので、説明を省略する。
【０１９７】
また、クリップインフォメーションファイル内の拡張データブロックblkClipExtensionData()におけるブロックClipEnfoExt()およびブロックblkMakersPrivateData()は、この発明と関連性が薄いので、説明を省略する。
【０１９８】
次に、仮想プレーヤについて、概略的に説明する。上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるＲＯＭ(Read Only Memory)に予め記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにＡＶＣＨＤフォーマットの規定に従った動作をさせることから、仮想プレーヤと称される。
【０１９９】
図３９は、この仮想プレーヤの動作を概略的に示す。図３９Ａは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると（ステップＳ３０）、１のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される（ステップＳ３１）。そして、次のステップＳ３２で、ムービーオブジェクトなどに記述されたプログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
【０２００】
図３９Ｂは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態（ステップＳ４０）に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される（ＵＯ：User Operation）。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され（ステップＳ４１）、次のステップＳ４２で、ムービーオブジェクト実行フェイズに移行する。
【０２０１】
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図４０を用いて説明する。ＵＯなどにより、タイトル番号＃１のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図２に示されるインデックステーブル(Index Table)を参照し、タイトル＃１のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル＃１のコンテンツ再生を実現するオブジェクトの番号が＃１であったとすると、プレーヤは、ムービーオブジェクト＃１の実行を開始する。
【０２０２】
この図４０の例では、ムービーオブジェクト＃１に記述されたプログラムは２行からなり、１行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト＃１の再生を開始する。プレイリスト＃１は、１以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト＃１中のプレイアイテムの再生が終了すると、ムービーオブジェクト＃１の実行に戻り、２行目のコマンドが実行される。図４０の例では、２行目のコマンドが"jump MenuTitle"であって、このコマンドが実行されインデックステーブルに記述されたメニュータイトル(MenuTitle)を実現するムービーオブジェクトの実行が開始される。
【０２０３】
次に、この発明の実施の一形態について説明する。この発明では、記録媒体にクリップが記録される際に、記録されるクリップに基づくチャプタを既存のプレイリストに対して追記するようにされる。そして、チャプタを既存のプレイリストに対して追記する際に、プレイリストに所定に設けられた制約に基づき当該クリップに基づくチャプタが当該プレイリストに追記可能か否かを判断する。判断の結果、追記が可能であるとされれば、当該クリップに基づくチャプタを当該プレイリストに対して追記する。一方、追記が不可であると判断されれば、新規にプレイリストを作成し、この新規に作成されたプレイリストに対して、記録されたクリップに基づくチャプタを登録する。
【０２０４】
このように記録制御を行うことで、ユーザは、プレイリストに設けられた制約を意識することなくクリップの記録を行うことができ、記録に際する操作性が向上され、利便性に優れる。
【０２０５】
図４１は、この発明の実施の一形態に適用可能な記録装置の一例の構成を概略的に示す。この記録装置は、入力されたディジタルビデオデータおよびディジタルオーディオデータを、所定の方式で圧縮符号化および多重化したＡＶストリームを記録媒体に記録するようにしている。
【０２０６】
この図４１に例示される記録装置は、外部から入力されるビデオデータおよびオーディオデータを記録媒体に記録する、単独の記録装置として用いることもできるし、光学系や撮像素子などを備えたカメラブロックと組み合わせ、撮像した撮像信号に基づくビデオデータを記録媒体に記録する、ビデオカメラ装置の記録ブロックとして用いることもできる。
【０２０７】
適用可能な圧縮符号化や多重化の方式としては、様々に考えられる。例えば、Ｈ．２６４｜ＡＶＣに規定される方式を、この発明の実施の一形態の圧縮符号化として適用することができる。これに限らず、ＭＰＥＧ２方式に基づき圧縮符号化を行うようにしてもよい。また、多重化方式は、例えばＭＰＥＧ２システムズを適用することができる。以下では、ビデオデータの圧縮符号化をＨ．２６４｜ＡＶＣに規定される方式に準じて行い、ビデオデータおよびオーディオデータの多重化を、ＭＰＥＧ２システムズに規定される方式に準じて行うものとして説明する。
【０２０８】
制御部３０は、例えばＣＰＵ(Central Processing Unit)、ＲＡＭ(Random Access Memory)およびＲＯＭ(Read Only Memory)などからなり（図示しない）、ＲＯＭに予め記憶されたプログラムやデータに基づき、ＲＡＭをワークメモリとして用いてこの記録装置の記録部１０の各部を制御する。なお、制御部１０と記録部１０の各部とを接続する経路は、繁雑さを避けるために、図３２では省略している。
【０２０９】
ＵＩ(User Interface)部３１は、この記録装置の動作をユーザが操作するための操作子が所定に設けられ、操作子に対する操作に応じた制御信号を出力する。この制御信号は、制御部３０に供給される。制御部３０は、ユーザ操作に応じてＵＩ部３１から供給された制御信号に基づきなされるプログラムの処理により、記録部１０の各部の動作を制御する。例えば、ＵＩ部３１に対してなされた操作に応じて、記録装置による記録動作の開始および停止の動作が制御部３０により制御される。
【０２１０】
一例として、制御部３０は、所定のプログラムからなりソフトウェアの基本的な機能を提供するＯＳ(Operating System)上で、ユーザインターフェイスの提供や記録部１０の各部の制御を提供するアプリケーションソフトウェアを実行させると共に、ソフトウェアと記録部１０各部の実際のハードウェアとの間の仲介を行うドライバソフトウェアを実行させる。ＯＳは、さらに、後述する記録媒体２０上に記録されたファイルやデータを管理するためのファイルシステムを提供する。アプリケーションソフトウェアは、ＯＳにより提供されるファイルシステムを介して、記録媒体２０上に記録されたファイルにアクセスする。
【０２１１】
ベースバンドのディジタルビデオデータが端子４０から入力される。また、当該ディジタルビデオデータに伴い、ベースバンドのディジタルオーディオデータが端子４１から入力される。
【０２１２】
ディジタルビデオデータは端子４０から記録部１０に入力され、ビデオエンコーダ１１に供給される。ビデオエンコーダ１１は、供給されたディジタルビデオデータを、所定の方式で以て圧縮符号化する。Ｈ．２６４｜ＡＶＣに規定される方式に準じて圧縮符号化がなされるこの例では、例えば、ＤＣＴ(Discrete Cosine Transform)と画面内予測とによりフレーム内圧縮を行うと共に、動きベクトルを用いたフレーム間圧縮を行い、さらにエントリピー符号化を行い圧縮効率を高める。ビデオエンコーダ１１で圧縮符号化されたディジタルビデオデータは、Ｈ．２６４｜ＡＶＣのエレメンタリストリーム（ＥＳ）として、マルチプレクサ（ＭＵＸ）１３に供給される。
【０２１３】
ディジタルオーディオデータは端子４１から記録部１０に入力され、オーディオエンコーダ１２に供給される。オーディオエンコーダ１２は、所定の圧縮符号化方式、例えばＡＣ３(Audio Code number 3)により圧縮符号化される。オーディオデータの圧縮符号化方式は、ＡＣ３に限られるものではない。オーディオデータを圧縮符号化せず、ベースバンドのデータのまま用いることも考えられる。圧縮符号化されたディジタルオーディオデータは、マルチプレクサ１３に供給される。
【０２１４】
マルチプレクサ１３は、それぞれ圧縮符号化されて供給されたディジタルビデオデータおよびディジタルオーディオデータを所定の方式で多重化し、１本のデータストリームとして出力する。ＭＰＥＧ２システムズに準じて多重化が行われるこの例では、ＭＰＥＧ２のトランスポートストリームを用いて、供給された圧縮ビデオデータおよび圧縮オーディオデータを時分割で多重化する。例えば、マルチプレクサ１３は、バッファメモリを有し、供給された圧縮ビデオデータおよび圧縮オーディオデータをバッファメモリに溜め込む。
【０２１５】
バッファメモリに溜め込まれた圧縮ビデオデータは、所定サイズ毎に分割されヘッダが付加されて、ＰＥＳ(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてＰＥＳパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すＰＴＳや復号時刻を示すＤＴＳ(Decoding Time Stanp)といった、ＭＰＥＧ２システムズに規定される所定の情報が格納される。ＰＥＳパケットは、さらに分割されてトランスポートパケット（ＴＳパケット）のペイロードに詰め込まれる。ＴＳパケットのヘッダには、ペイロードに詰め込まれたデータを識別するためのＰＩＤ(Packet Identification)が格納される。マルチプレクサ１３から出力されたＴＳパケットは、ストリームバッファ１４に一旦溜め込まれる。
【０２１６】
なお、ＴＳパケットは、実際には、ＭＵＸ／ＤＥＭＵＸ１３においてさらに所定サイズのヘッダが付加されて出力される。この、ＴＳパケットに対して所定のヘッダを付加したパケットを、ソースパケットと呼ぶ。
【０２１７】
記録制御部１５は、記録媒体２０に対するデータの記録を制御する。記録媒体２０としては、例えば記録可能なタイプのＤＶＤ(Digital Versatile Disc)を用いることができる。これに限らず、記録媒体２０としてハードディスクドライブを用いてもよいし、半導体メモリを記録媒体２０に適用することも可能である。また、記録媒体２０として、より大容量を実現したＢｌｕ−ｒａｙ Ｄｉｓｃ（ブルーレイディスク：登録商標）を適用することも考えられる。
【０２１８】
記録制御部１５は、ストリームバッファ１４に溜め込まれたデータ量を監視し、ストリームバッファ１４に所定量以上のデータが溜め込まれると、ストリームバッファ１４から記録媒体２０の記録単位分のデータを読み出して記録媒体２０に書き込む。
【０２１９】
管理情報処理部１６は、例えばＣＰＵ、ワークメモリとしてのＲＡＭおよびプログラム所定のデータが予め記憶されるＲＯＭからなる（図示しない）。これに限らず、管理情報処理部１６は、例えば制御部３０におけるプログラム処理で管理情報処理部１６の機能を実現することも可能である。この場合、例えば制御部３０の有するＲＡＭが揮発性メモリ１７として用いられると共に、不揮発性メモリ１８が制御部３０に接続される。
【０２２０】
管理情報処理部１６は、記録データに基づき、揮発性メモリ１７をワークメモリとして用いて、上述したインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に格納するための情報を生成する。生成された情報は、所定のタイミングで記録媒体２０に書き込まれる。
【０２２１】
一例として、管理情報処理部１６は、マルチプレクサ１３から記録データの時間情報を取得すると共に、記録制御部１５から記録データの記録媒体２０に対するアドレス情報を取得し、取得されたこれら時間情報およびアドレス情報に基づきＥＰ＿ｍａｐ情報が生成される。また、ＵＩ部３１に対する記録開始、記録終了の操作に応じて制御部３０から出力される制御信号と、マルチプレクサ１３および記録制御部１５からの記録データに関する情報とに基づき、クリップインフォメーションファイル"zzzzz.clpi"の生成が行われると共に、生成されたクリップインフォメーションファイルの情報がプレイリストファイルに追記され、プレイリストファイル"xxxxx.mpls"の更新が行われる。
【０２２２】
プレイリストファイルの更新の際に、クリップインフォメーションファイルの情報がプレイリストファイルに追記されることでプレイリストファイルに対して所定に設けられた制約を満足するか否かを判断する。判断の結果、制約を満足しないと判断されれば、新規にプレイリストファイルが作成され、生成されたクリップインフォメーションファイルの情報が新規に作成されたプレイリストファイルに記録される。
【０２２３】
さらに、記録媒体２０に対して新規に記録が行われる際には、インデックスファイル"index.bdmv"やムービーオブジェクトファイル"MovieObject.bdmv"の生成または更新が行われる。
【０２２４】
図４２は、この発明の実施の一形態に適用可能な一例のデータ構造を示す。インデックスファイル"index.bdmv"は、１乃至複数のタイトルを有する。ムービーオブジェクトファイル"MovieObject.bdmv"は、インデックスファイル"index.bdmv"が有するタイトルに対応して、１乃至複数のムービーオブジェクトを含む。ムービーオブジェクトのそれぞれは、１つのプレイリストファイル"xxxxx.mpls"を呼び出す。プレイリストファイル"xxxxx.mpls"は、１乃至複数のプレイアイテムを含み、プレイアイテムのそれぞれは、クリップインフォメーションファイル"zzzzz.clpi"を参照する。クリップインフォメイションファイル"zzzzz.clpi"は、クリップの実体であるクリップＡＶストリームファイル"zzzzz.m2ts"と１対１の関係にある。
【０２２５】
このような構造において、ユーザには、インデックスファイル"index.bdmv"が有するタイトル単位で、記録媒体に記録されたクリップが見えることになる。ユーザが所望のタイトルを選択すると、ムービーオブジェクトファイル"MovieObject.bdmv"から当該タイトルに対応するムービーオブジェクトが参照される。そして、参照されたムービーオブジェクトに記述されたプレイリストファイル"xxxxx.mpls"が呼び出され、プレイリストファイルに含まれるプレイアイテムに従いクリップインフォメーションファイル"zzzzz.clpi"が参照され対応するクリップＡＶストリームファイル"zzzzz.m2ts"が再生される。
【０２２６】
プレイリストファイル"xxxxx.mpls"に対して時刻情報を示すマーク（プレイリストマーク）を設けることで、ジャンプ位置を設定することができる。マークによってチャプタが定義される。チャプタは、ユーザから見えるタイトル内の再生単位である。記録開始位置には、必ずマークが設けられる。記録開始位置以外の位置にマークを設けることもできる。
【０２２７】
すなわち、プレイリストファイル"xxxxx.mpls"に対して、例えば記録開始に伴いプレイリストマークを設定すると共に、クリップを参照するプレイアイテムを登録することで、当該プレイリストファイルに対してチャプタが形成される。換言すれば、プレイリストファイルに対してプレイリストマークを記録すると共に、プレイアイテムを記録することで、当該プレイリストファイルに対してチャプタが記録されるといえる。
【０２２８】
上述したように、リアルプレイリストは、クリップと共に生成される。図４２の例では、プレイリストファイル"00000.mpls"、"00200.mpls"および"00018.mpls"がリアルプレイリストの属性を有する。
【０２２９】
これらのうち、プレイリストファイル"00000.mpls"は、新規に生成されたクリップの情報をプレイリストに追記記録していく例である。例えば、クリップＡＶストリームファイル"00001.m2ts"に対応するクリップインフォメーションファイル"00001.clpi"を参照するプレイアイテム＃０が既に格納されているプレイリストファイル"00000.mpls"に対して、新規に記録されたクリップＡＶストリームファイル"00125.m2ts"に対応するクリップインフォメーションファイル"00125.m2ts"を参照するプレイアイテム＃１が追記記録される。プレイアイテムが示す先頭の時刻には、それぞれマークが設けられる。このプレイリストファイル"00000.mpls"を再生すると、ますプレイアイテム＃０に基づきクリップＡＶストリームファイル"00001.m2ts"が再生され、続けてプレイアイテム＃１に基づきクリップＡＶストリームファイル"00125.m2ts"が再生される。
【０２３０】
プレイリストファイル"00200.mpls"は、１のクリップに対して１のプレイリストファイルが生成され、プレイリストファイルが唯一つのプレイアイテムのみを含む例である。
【０２３１】
さらに、プレイリストファイル"00018.mpls"は、複数のプレイアイテムが１のクリップを参照する例である。例えば、記録開始および停止によりプレイアイテムが生成されると共に、１のクリップに対してデータが追記されていくような制御が考えられる。プレイアイテム＃０の先頭にマークが設けられ、プレイアイテム＃０およびプレイアイテム＃１を連続的に再生することで、クリップＡＶストリームファイル"00002.m2ts"の全体が再生される。
【０２３２】
一方、バーチャルプレイリストは、図４２にプレイリストファイル"00005.mpls"として示されるように、既に存在するクリップに対して再生区間を指定する。この例では、プレイリストファイル"00005.mpls"に含まれるプレイアイテム＃０がクリップインフォメーションファイル"00028.clpi"を参照して区間を指定し、プレイアイテム＃１がクリップインフォメーションファイル"00002.clpi"を参照して区間を指定している。また、プレイアイテム＃０およびプレイアイテム＃１の先頭に、マークが設けられている。プレイリストファイル"00005.mpls"を再生すると、先ずプレイアイテム＃０に基づきクリップＡＶストリームファイル"00028.m2ts"の指定区間が再生され、続けて、プレイアイテム＃１に基づきクリップＡＶストリームファイル"00002.m2ts"が再生される。
【０２３３】
この発明では、上述したように、新規に記録されるクリップに基づくチャプタを、既存のプレイリストファイルに追記するか、新規プレイリストファイルを作成して記録するかを、プレイリストファイルに所定に設けられた制約に基づき判断している。プレイリストファイルに設けられる制約の一例を以下に示す。制約には、フォーマット上の制約、実装仕様上の制約、商品仕様上の制約などが考えられる。
【０２３４】
フォーマット上の制約としては、以下の制約（１）〜制約（７）の各項目が考えられる。
制約（１）：１のプレイリストファイルに存在可能なプレイアイテム数の上限。
制約（２）：１のプレイリストファイルに存在可能なプレイリストマーク数の上限。
制約（３）：１のプレイリストファイルが複数のクリップを参照する場合に、参照される複数のクリップそれぞれの所定のビデオ属性が一致していなければならない。
制約（４）：１のプレイリストファイルのファイルサイズの上限。
制約（５）：１のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限。
制約（６）：１のプレイリストファイルに関連しているクリップインフォメーションファイル内の粗い単位で検索を行うエントリポイントの合計の上限。
制約（７）：１のプレイリストファイルに関連しているクリップインフォメーションファイル内の精密な単位で検索を行うエントリポイントの合計の上限。
【０２３５】
これらのうち、制約（１）のプレイアイテム数および制約（２）のプレイリストマーク数に関して、フォーマット上、１のプレイリストファイルに存在可能なプレイアイテム数の上限が例えば９９９個とされ、１のプレイリストファイルに存在可能なプレイリストマーク数の上限が例えば９９９個とされる。したがって、新規にクリップを記録する際に、当該クリップに基づくチャプタを追記しようとするプレイリストファイルにおいて、チャプタを追記した際にこれらの制約が満足されるか否かを判断する必要がある。
【０２３６】
制約（３）のビデオ属性に関して、１のプレイリストファイルが参照する複数のクリップＡＶストリームファイルにおいて、例えば、画枠サイズ、走査方式、アスペクト比、フレームレート、コーデックの種別といった、ビデオデータの符号化に関わる属性が不変であるように、フォーマットにおいて規定されている。したがって、新規にクリップを記録する際に、当該クリップに基づくチャプタを追記しようとするプレイリストファイルに既に記録されているプレイアイテムにより参照されるクリップにおけるこれらの属性と、新規に記録しようとするクリップにおけるこれらの属性とを比較する必要がある。
【０２３７】
制約（４）の１のプレイリストファイルのファイルサイズと、制約（５）の１のプレイリストファイルに関連しているクリップインフォメーションファイルの合計ファイルサイズとに対して、フォーマット上、それぞれ上限が規定されている。このファイルサイズの規定は、記録装置および再生装置のメモリ容量に関連する。
【０２３８】
すなわち、例えば記録時に、記録されているクリップに対応するプレイリストや、記録されているクリップのクリップインフォメーションファイルは、一旦、記録装置のメモリに格納され、メモリ上で記録に伴うプレイリストファイルやクリップインフォメーションファイルの更新処理がなされる。そして、メモリに格納されたこれらプレイリストファイルやクリップインフォメーションファイルは、所定のタイミングで記録媒体に書き込まれる。プレイリストファイルや、１のプレイリストファイルに関連しているクリップインフォメーションファイルの合計ファイルサイズに制限を設けることで、例えば記録中にメモリに空き容量が無くなってしまい記録が強制的に停止されるなどの状態になることが防がれる。
【０２３９】
プレイリストファイルのファイルサイズの上限は、例えば６００ｋＢ（キロバイト）が上限とされる。また、１のクリップインフォメーションファイルのファイルサイズの上限が例えば１ＭＢ（メガバイト）とされている場合、１のプレイリストファイルに関連しているクリップインフォメーションファイルの合計のファイルサイズの上限は、例えば２ＭＢとされる。
【０２４０】
制約（６）および制約（７）の、エントリポイントの上限は、上述のクリップインフォメーションファイルのファイルサイズの上限に関連する。すなわち、既に説明したように、粗い単位で検索を行うエントリポイントおよび精密な単位で検索を行うエントリポイントは、クリップインフォメーションファイル内のブロックblkCPI()におけるブロックblkEPMap()に格納される情報である。すなわち、粗い単位で検索を行うエントリポイントは、ブロックblkEPMap()におけるフィールドPTSEPCoarseおよびフィールドSPNEPCoarseであり、精密な検索を行うエントリポイントは、ブロックblkEPMap()におけるフィールドPTSEPFineおよびフィールドSPNEPFineである。
【０２４１】
フォーマット上、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとのそれぞれに対し、１のプレイリストファイルに関連しているクリップインフォメーションファイルについて合計した数に対して上限が規定されている。したがって、新規にクリップを記録しようとする際に、当該クリップを参照するプレイアイテムを追記しようとするプレイリストファイルにおいて、プレイアイテムを追記した際にこれらの制約が満足されるか否かを判断する必要がある。
【０２４２】
実装仕様上の制約としては、以下の項目が考えられる。
制約（８）：プレイリストファイルにおける拡張データブロック内のブロックblkMakersPrivateData()について、他機で記録したプレイリストファイルのブロックblkMakersPrivateData()の情報を引き継ぐことができない場合は、当該プレイリストファイルを更新してはならない。
【０２４３】
例えば、プレイリストファイルにおける拡張データブロック内のブロックblkMakersPrivateData()は、図３５においてブロックDataBlock()に示されるように、特にデータサイズが制限されていないため、機器によっては、数１００ｋＢといった、比較的大きなデータサイズのデータを書き込む仕様も考えられる。機器の実装によっては、例えばメモリ容量の制限などの要因により、他機で記録されたこのような大きなサイズのブロックblkMakersPrivateData()の情報を引き継いでプレイリストファイルの更新や編集を行うことが困難であることも考えられる。
【０２４４】
商品仕様上の制約としては、以下の項目が考えられる。
制約（９）：タイトルやチャプタに関して他機と概念が異なる場合でも、ユーザの混乱を招かないようにする必要がある。
制約（１０）：規定時間以上の連続撮影および記録可能である必要がある。
【０２４５】
制約（９）のタイトルおよびチャプタに関して、機器によって、プレイリストおよびチャプタの構成方法が異なることが考えられる。このような機器間で、クリップの記録された記録媒体を交換した場合に、例えば再生時におけるタイトルの表示などに不都合が生じる可能性がある。
【０２４６】
一例として、テレビジョン放送を録画するようにされた据置型の記録再生装置（ビデオデッキなど）では、１番組が１プレイリストとし、５分間隔で自動的にプレイリストマークを設けてチャプタを構成する仕様とされ、ビデオカメラ装置では１撮影毎、すなわち記録開始時にプレイリストマークを設けてチャプタを構成し、複数のチャプタを１プレイリストに登録する仕様であるものとする。また、据置型の記録再生機器ではプレイリストの先頭のみサムネイル画像を表示し、チャプタ毎のサムネイル画像を表示しないような仕様であるとする。
【０２４７】
このような条件において、据置型の記録再生装置で作成されたプレイリストファイルが記録された記録媒体を、ビデオカメラ装置に装填し、ビデオカメラ装置で記録されたクリップを参照するプレイアイテムを、据置型の記録再生装置で作成されたプレイリストファイルに追記して記録することを考える。この場合、据置型の記録再生装置で記録されたある番組の最後の方のシーンとして、ビデオカメラ装置で撮影された映像がチャプタとして登録されることになる。この記録媒体を、ビデオカメラ装置から再び据置型の記録再生装置に装填して再生させると、ビデオカメラ装置で撮影された映像によるチャプタは、サムネイル画像として表示されず、以前に据置型の記録再生装置で記録された番組の最後のシーンとして再生されてしまい、不自然である。
【０２４８】
制約（１０）の規定時間以上の連続撮影および記録に関して、記録機の仕様として、所定時間以上の連続記録が保証されるのが一般的である。一方、上述のように、フォーマット上、１のプレイリストに関連するクリップインフォメーションファイルのエントリポイントの合計数に対して上限が設けられている。例えば、記録媒体の空き容量が十分であっても、新規に記録するクリップを参照するプレイアイテムを追記しようとするプレイリストファイルにおいて、既に参照されているクリップインフォメーションファイルにおけるエントリポイントの合計数とフォーマット上規定されている上限とから、保証すべき所定時間分のエントリポイント数を確保できない場合があり得る。したがって、新規にクリップを記録しようとする際に、当該クリップを参照するプレイアイテムを追記しようとするプレイリストファイルに関連するエントリポイント数に基づき所定時間以上の連続記録が可能か否かを判断する必要がある。
【０２４９】
次に、この発明の実施の一形態による、新規記録するクリップに基づくチャプタの、プレイリストファイルへの追記可否を判断する処理について説明する。上述した制約（１）〜制約（１０）の各項目についてそれぞれ判断を行い、１項目でも追記不可の判断がなされた場合には、新規にプレイリストを作成し、新規記録するクリップに基づくチャプタを、新規に作成されたプレイリストに対して記録する。
【０２５０】
図４３は、新規記録するクリップに基づくチャプタのプレイリストファイルへの追記可否を判定する一例の処理を示すフローチャートである。先ず、この図４３のフローチャートを用いて全体的な処理の流れを概略的に説明する。ここでは、記録媒体２０を記録可能なタイプのＤＶＤといった、ディスク状記録媒体（以下、ディスク）であるものとする。また、以下に説明する各判断処理などは、図４１を用いて説明した記録装置においては、制御部３０において行われる。
【０２５１】
記録媒体２０が記録装置に装填されると、制御部３０により記録制御部１５が制御され、記録媒体２０からインデックスファイル"index.bdmv"が読み込まれる（ステップＳ１００）。読み込まれたインデックスファイル"index.bdmv"は、例えば管理情報処理部１６を介して揮発性メモリ１７に記憶される。
【０２５２】
次のステップＳ１０１で、制御部３０は、揮発性メモリ１７に記憶されたインデックスファイル"index.bdmv"内に記述された情報に基づき、次に記録されるクリップに基づくチャプタを追記するためのプレイリスト（プレイリストファイル）の候補を特定する。
【０２５３】
例えば、インデックスファイル"index.bdmv"における拡張データブロックであるブロックblkIndexExtensionData()内のブロックblkTableOfPlayLists()を参照して、最も新しく記録されたリアルプレイリストを検索してそのリアルプレイリストのファイル名を取得する。
【０２５４】
より具体的には、図２９を参照し、ブロックblkIndexExtensionData()に列挙されたブロックblkMovieTitlePlayListPair()の中で、フィールドPlayListAttributeが属性「Real」を示しているブロックblkMovieTitlePlayListPair()のうち、最も後ろに記述されているブロックblkMovieTitlePlayListPair()を検索し、検索されたブロックblkMovieTitlePlayListPair()からフィールドPlayListFileNameのデータを取得する。
【０２５５】
次のステップＳ１０２で、ステップＳ１０１で特定された追記候補のプレイリストファイルが記録媒体２０から読み込まれ、揮発性メモリ１７に記憶される。そして、読み込まれた追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルが記録媒体２０から読み込まれる。読み出されたクリップインフォメーションファイルは、揮発性メモリ１７に記憶される。
【０２５６】
より具体的には、図１０〜図１２を参照して、追記候補のプレイリストファイルにおいて、ブロックblkPlayList()内の全てのブロックblkPlayItem()が参照され、ブロックblkPlayItem()に記述されるフィールドClipInformationFileNameのデータが全て取得される。そして、取得されたフィールドClipInformationFileNameのデータに示されるクリップインフォメーションファイルを、記録媒体２０から全て読み出す。
【０２５７】
以下のステップＳ１０４〜ステップＳ１１１で、揮発性メモリ１７に記憶された追記候補のプレイリストファイルおよびクリップインフォメーションファイルに基づき、上述した各制約に基づくチャプタの追記可否の判定がなされる。すなわち、ステップＳ１０４で、上述の制約（１）に対応し、ステップＳ１０１で取得された追記候補のプレイリストファイルに含まれるプレイアイテム数に基づき追記可否の判定を行う。次のステップＳ１０５で、上述した制約（２）に対応し、追記候補のプレイリストファイルに含まれるプレイリストマーク数に基づき追記可否の判定を行う。次のステップＳ１０６で、上述した制約（３）に対応し、追記候補のプレイリストファイルに記述されるビデオ属性と、新規に記録しようとするクリップのビデオ属性とに基づき追記可否の判定を行う。
【０２５８】
次のステップＳ１０７で、上述した制約（４）に対応し、追記候補のプレイリストファイルのファイルサイズに基づき追記可否の判定を行う。次のステップＳ１０８で、上述した制約（５）に対応し、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズに基づき追記可否の判定を行う。次のステップＳ１０９で、上述した制約（６）および制約（７）に対応し、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルに格納されるエントリポイントの合計数に基づく追記可否の判定を行う。
【０２５９】
次のステップＳ１１０で、上述した制約（８）に対応し、追記候補とされたプレイリストファイル内における他機による独自の拡張データの有無に基づく追記可否の判定を行う。さらに、次のステップＳ１１１で、上述した制約（９）に対応し、追記候補のプレイリストファイルの最終更新者に基づく追記可否の判定を行う。
【０２６０】
次のステップＳ１１２では、上述したステップＳ１０４〜ステップＳ１１１までの各判断処理による判定結果に基づき、新規記録されるクリップに基づくチャプタを、追記候補とされたプレイリストファイルに対して追記するか否かの最終的な判断がなされる。例えば、ステップＳ１０４〜ステップＳ１１１の各処理による判定結果を、制御部３０が有するレジスタなどにそれぞれ保持し、ステップＳ１１２において、レジスタに保持された各処理による判定結果に基づき判断を行う。
【０２６１】
すなわち、ステップＳ１１２では、ステップＳ１０４〜ステップＳ１１１までの各処理の全てにおいて追記可能であると判定されたら、新規記録するクリップにに基づくチャプタを、ステップＳ１０１で取得された追記候補のプレイリストファイルに対して追記するように判断する。
【０２６２】
一方、上述したステップＳ１０４〜ステップＳ１１１までの各処理において、追記不可と判定された処理が一つでもあれば、上述のステップＳ１０１で取得された追記候補のプレイリストファイルに基づくチャプタの追記が不可であると判断する。この場合、新規にリアルプレイリストのプレイリストファイルを作成し、この新規のプレイリストファイルに対して、新規に記録されるクリップに基づくチャプタを記録する。
【０２６３】
なお、上述したステップＳ１０４〜ステップＳ１１１の各処理の順序は、この順序に限られない。すなわち、ステップＳ１０４〜ステップＳ１１１の各処理は、任意の順序で行うことができる。また、ステップＳ１０４〜ステップＳ１１１の各処理を並列的に行うことも可能である。さらに、ステップＳ１０４〜ステップＳ１１１の各処理の全てを行わず、各処理のうち１または複数の処理を選択的に行ってもよい。
【０２６４】
以下に、上述したステップＳ１０４〜ステップＳ１１１の各処理のそれぞれを、より詳細に説明する。図４４は、ステップＳ１０４による、制約（１）に対応した、追記候補のプレイリストファイルに含まれるプレイアイテム数に基づく追記可否判断の一例の処理を示す。この処理では、ステップＳ１２０に一例が示されるように、追記候補のプレイリストファイル内のブロックblkPlayList()（図１１参照）を参照してフィールドNumberOfPlayItemsの値を取得し、取得されたフィールドNumberOfPlayItemsの値と、１のプレイリストファイルに存在可能なプレイアイテム数に対して設定された処理の上限値、例えば値"９９９"とを比較する。
【０２６５】
比較の結果、フィールドNumberOfPlayItemsの値が所定の上限値未満であれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、フィールドNumberOfPlayItemsの値が所定の上限値以上であれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０２６６】
図４５は、ステップＳ１０５による、制約（２）に対応した、追記候補のプレイリストファイルに含まれるプレイリストマーク数に基づく追記可否判断の一例の処理を示す。この処理では、ステップＳ１３０に一例が示されるように、追記候補のプレイリストファイル内のブロックblkPlayListMark()（図１４参照）を参照してフィールドNumberOfPlayListMarksの値を取得し、取得されたフィールドNumberOfPlayListMarksの値と、１のプレイリストファイルに存在可能なプレイリストマーク数に対して設定された所定の上限値、例えば値"９９９"とを比較する。
【０２６７】
比較の結果、フィールドNumberOfPlayListMarksの値が所定の上限値未満であれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、フィールドNumberOfPlayListMarksの値が所定の上限値以上であれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０２６８】
なお、既に説明したように、プレイリストマークには、エントリマークおよびリンクポイントの２タイプが存在する。このステップＳ１３０においては、これらエントリマークおよびリンクポイントの合計数に対して上限値未満であるか否かが判定される。
【０２６９】
図４６は、ステップＳ１０６による、制約（３）に対応した、追記候補のプレイリストファイルに記述されるビデオ属性と、新規に記録しようとするクリップのビデオ属性とに基づく追記可否判断の一例の処理を示す。先ず、最初のステップＳ１４０において、記録するビデオデータの属性情報を取得する。この実施の一形態では、記録装置に対して現在設定されている撮影モードや録画モードに基づき、記録するビデオデータの属性情報として画枠サイズ、アスペクト比、フレームレートおよび走査種別（インターレース／プログレッシブ）を取得する。
【０２７０】
以下のステップＳ１４１〜ステップＳ１４４で、追記候補のプレイリストファイルに関連するクリップのビデオ属性が取得される。この実施の一形態では、追記候補のプレイリストファイルに対して複数のプレイアイテムが格納されている場合、最も最初に記録されたプレイアイテムが参照するクリップインフォメーションファイルから、ビデオ属性を取得する。概略的には、ビデオ属性として、ステップＳ１４１で画像幅を取得し、ステップＳ１４２で画像高（ライン数）および走査種別を取得し、ステップＳ１４３でアスペクト比を取得し、ステップＳ１４４でフレームレートを取得する。
【０２７１】
より具体的には、追記候補のプレイリストファイル内のブロックblkPlayList()（図１１参照）において、最も先頭側に格納されるブロックblkPlayItem()（図１２参照）を参照し、フィールドClipInformationFileNameのデータを取得し当該プレイアイテムが参照するクリップインフォメーションファイルのファイル名を取得する。上述した図４３のフローチャートにおけるステップＳ１０３の処理により読み込まれた、追記候補のプレイリストに関連する全てのクリップインフォメーションファイルのうち、取得されたファイル名に対応するクリップインフォメーションファイルを参照する。
【０２７２】
ステップＳ１４１では、当該クリップインフォメーションファイルにおける拡張データであるブロックblkClipExtensionData()内のブロックblkProgramInfoExt()（図３７参照）が参照され、当該ブロックblkProgramInfoExt()において、さらにブロックblkStreamCodingInfoExt(i,j)（図３８参照）が参照される。そして、当該ブロックblkStreamCodingInfoExt(i,j)内のフィールドHorizontalSizeの値が取得される。
【０２７３】
ステップＳ１４２では、当該クリップインフォメーションファイルにおけるブロックblkProgramInfo()（図１７参照）内のブロックblkStreamCodingInfo()（図１８参照）が参照され、フィールドVideoFormatの値が取得される。フィールドVideoFormatは、図１９を用いて既に説明したように、４ビットで表現可能な値を用いて、ビデオデータのライン数と走査方式（インターレース／プログレッシブ）との組み合わせが示されている。
【０２７４】
ステップＳ１４３では、ステップＳ１４２と同様にブロックblkStreamCodingInfo()が参照され、フィールドAspectRatioの値が取得される。フィールドAspectRatioは、図２１を用いて既に説明したように、４ビットで表現可能な値を用いて、ビデオデータの画枠のアスペクト比が示されている。
【０２７５】
ステップＳ１４４では、ステップＳ１４３およびステップＳ１４３と同様に、ブロックblkStreamCodingInfo()が参照され、フィールドFrameRateの値が取得される。フィールドFrameRateは、図２０を用いて既に説明したように、４ビットで表現可能な値を用いて、ビデオデータのフレームレートが示されている。
【０２７６】
ステップＳ１４５では、ステップＳ１４０で記録機から取得された、記録するビデオデータの属性情報のそれぞれと、ステップＳ１４１〜ステップＳ１４４で取得された、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとが比較される。
【０２７７】
比較の結果、記録するビデオデータの属性情報のそれぞれと、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとが全て一致していれば、新規記録するクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、記録するビデオデータの属性情報のそれぞれと、追記候補のプレイリストファイルに関連するクリップのビデオ属性のそれぞれとにおいて、一つでも不一致の属性がある場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０２７８】
図４７は、ステップＳ１０７による、制約（４）に対応した、追記候補のプレイリストファイルのファイルサイズに基づく追記可否判断の一例の処理を示す。この処理においては、追記候補のプレイリストに対して少なくとも所定チャプタ数を追記しても、１のプレイリストファイルのファイルサイズの上限を超えないことを以て、追記の可否を判断する。
【０２７９】
なお、所定チャプタ数は、１チャプタ、複数チャプタ、１のプレイリストファイルに存在可能な最大チャプタ数に対する残りのチャプタ数など、記録機の設計思想などにより様々に考えられる。ここでは、所定のチャプタ数を、１のプレイリストファイルに存在可能な最大チャプタ数に対する残りのチャプタ数であるものとする。
【０２８０】
先ず、ステップＳ１５０において、予め計算しておいた、１チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPを取得する。すなわち、このステップＳ１５０では、例えば１のチャプタを形成するためのプレイアイテムおよびプレイリストマークのデータ量を計算する。
【０２８１】
図１２を参照し、プレイアイテムにおいて、フィールドStillModeおよびフィールドStillTime、ならびに、ブロックblkUOMaskTable()およびブロックblkSTNTable()は、データ長が変動する可能性のあるデータであるが、実際には、これらのデータは、記録モードや記録機によって固定長とされる。また、プレイリストマークは、図１４を参照し、各フィールドの値が固定長とされている。このように、１のクリップを記録する際に生成されるプレイアイテムおよびプレイリストマークのデータサイズは、予め計算することができる。また、計算された値は、記録時間に依らない性質のものである。この１チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPの値は、予め計算され例えば記録機が有するＲＯＭなどに記憶される。この図４７のフローチャートによる処理を実行する毎に計算してもよい。
【０２８２】
プレイリストに対してチャプタを追記する場合には、プレイアイテムとプレイリストマークとが増加することになる。したがって、プレイリストに対してチャプタを追記する際には、制約（１）および制約（２）の、１のプレイリストファイルに存在可能なプレイアイテムおよびプレイリストマーク数も考慮に入れる必要がある。
【０２８３】
ステップＳ１５１では、追記候補のプレイリストファイルに追記可能なプレイアイテム数PI_REMAINを計算する。すなわち、追記候補のプレイリストファイル内のブロックblkPlayList()（図１１参照）を参照してフィールドNumberOfPlayItemsの値を取得し、追記候補のプレイリストに含まれるプレイアイテム数を求める。そして、追記候補のプレイリストに含まれるプレイアイテム数を、１のプレイリストファイルに存在可能なプレイアイテム数に対して設定された所定の上限値PI_MAX、例えば"９９９"から減じて、追記候補のプレイリストに追記可能なプレイアイテム数PI_REMAINを求める。
【０２８４】
すなわち、追記候補のプレイリストファイル追記可能なプレイアイテム数PI_REMAINは、下記の式（１）により求められる。
PI_REMAIN＝PI_MAX−NumberOfPlayItems ・・・（１）
【０２８５】
ステップＳ１５２では、追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINを計算する。すなわち、追記候補のプレイリストファイル内のブロックblkPlayListMark()（図１４参照）を参照してフィールドNumberOfPlayListMarksの値を取得し、追記候補のプレイリストに含まれるプレイリストマークの数を求める。そして、追記候補のプレイリストに含まれるプレイリストマーク数を、１のプレイリストに存在可能なプレイアイテム数に対して設定された所定の上限値MARK_MAX、例えば"９９９"から減じて、追記候補のプレイリストに追記可能なプレイリストマーク数MARK_REMAINを求める。
【０２８６】
すなわち、追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINは、下記の式（２）により求められる。
MARK_REMAIN＝MARK_MAX−NumberOfPlayListMarks ・・・（２）
【０２８７】
次のステップＳ１５３では、ステップＳ１５１で求められた追記候補のプレイリストに追記可能なプレイアイテム数PI_REMAINと、ステップＳ１５２で求められた追記候補のプレイリストファイルに追記可能なプレイリストマーク数MARK_REMAINとのうち小さい方を、追記候補に追記可能なチャプタ数CHAP_REMAINとする。
【０２８８】
すなわち、追記候補のプレイリストファイルに追記可能なチャプタ数CHAP_REMAINは、「MIN」を括弧内の値のうち小さい方を選択することを表すものとして、上述の式（１）および式（２）の結果を用いて、下記の式（３）により求められる。なお、「MIN」は、括弧内の値のうち最小の値を選択することを示す。
CHAP_REMAIN＝MIN ( PI_REMAIN, MARK_REMAIN ) ・・・（３）
【０２８９】
次のステップＳ１５４では、追記候補のプレイリストファイルのファイルサイズを取得し、制約（４）の１のプレイリストファイルのファイルサイズの上限PL_SIZE_MAXに対して残されたデータサイズSIZE_REMAINを求める。プレイリストファイルのファイルサイズは、例えばＯＳのファイルシステムにより提供されるファンクションを利用して取得することができる。データサイズSIZE_REMAIN(kB)は、下記の式（４）により求められる。なお、追記候補のプレイリストファイルのファイルサイズをFILE_SIZE(kB)とする。
SIZE_REMAIN(kB)＝PL_SIZE_MAX(kB)−FILE_SIZE(kB) ・・・（４）
【０２９０】
次のステップＳ１５５で、追記候補のプレイリストファイルに対して追記可能なチャプタ数分のプレイアイテムおよびプレイリストマークを追記した場合に、追記候補のプレイリストファイルのファイルサイズが１のプレイリストファイルのファイルサイズの上限を超えないか否かが判断される。
【０２９１】
すなわち、ステップＳ１５０で求めた１チャプタ当たりのプレイリストファイルのサイズ増加分SIZE_1CHAPと、式（３）および式（４）の結果とを用いて、下記の式（５）を満足するか否かが判断される。
SIZE_1CHAP×CHAP_REMAIN≧SIZE_REMAIN ・・・（５）
【０２９２】
若し、式（５）が満足されれば、新規記録のクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断される。一方、式（５）が満足されなければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０２９３】
図４８は、上述のステップＳ１０８の、制約（５）に対応した、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズに基づく追記可否判断の一例の処理を示す。
【０２９４】
上述の制約（５）によれば、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズには、例えば２ＭＢといったように、上限値CLIP_SUM_MAXが設定される。チャプタの追記により追記候補のプレイリストに対してクリップインフォメーションファイルが追加された際に、当該追記候補のプレイリストファイルに関連するクリップインフォメーションファイルの合計サイズが、この上限値CLIP_SUM_MAXを超えないようにする必要がある。
【０２９５】
ステップＳ１６０で、予め計算しておいた、１のクリップインフォメーションファイルの最大サイズSIZE_1CLIPを取得する。クリップインフォメーションファイルは、ブロックblkEPMap()に、ＰＴＳ値とクリップＡＶストリームファイルのバイトアドレスとを関連付けるエントリポイントの情報が格納される（図２３〜図２６参照）。このエントリポイントの情報は、記録時間により変化する値である。クリップインフォメーションファイルに格納されるその他の情報は、符号化方式などにより記録時間に依らず固定的な値である。一方、上述したように、記録機の仕様として、連続記録を保証する最低時間が設定される。エンコーダにおけるビデオやオーディオの符号化方式により、連続記録を保証する最低時間分のエントリポイント数が決まる。連続記録を保証する最低時間分のエントリポイントの合計データサイズを計算し、計算結果に基づき最大サイズSIZE_1CLIPを求める。
【０２９６】
次のステップＳ１６１で、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルについてファイルサイズを取得し、合計サイズSIZE_TOTAL_CLIPを計算する。
【０２９７】
すなわち、追記候補のプレイリストファイル内の全てのブロックblkPlayItem()（図１２参照）を参照し、各ブロックblkPlayItem()についてフィールドClipInformationFileNameのデータを取得する。そして、取得されたフィールドClipInformationFileNameのデータに示されるクリップインフォメーションファイルのファイルサイズを、追記候補のプレイリストファイル内の全てのブロックblkPlayItem()についてそれぞれ求め、合計する。クリップインフォメーションファイルのファイルサイズは、例えばＯＳのファイルシステムにより提供されるファンクションを利用して取得することができる。
【０２９８】
次のステップＳ１６２で、下記の式（６）に従い、１のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、ステップＳ１６１で計算された、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値と、ステップＳ１６０で計算された、１のクリップインフォメーションファイルの最大サイズSIZE_1CLIPとが比較され、追記候補のプレイリストファイルに対して最大サイズSIZE_1CLIPのクリップインフォメーションファイルを追加可能であるか否かが判定される。
CLIP_SUM_MAX−SIZE_TOTAL_CLIP≧SIZE_1CLIP ・・・（６）
【０２９９】
比較の結果、若し、１のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値が、１のクリップインフォメーションファイルの最大サイズSIZE_1CLIPよりも大きいと判定されれば、新規記録のクリップに基づくチャプタの追記候補のプレイリストファイルに対する追記が可能であると判断される。
【０３００】
一方、１のプレイリストファイルに関連できるクリップインフォメーションファイルの合計ファイルサイズの上限値から、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルの合計サイズSIZE_TOTAL_CLIPを減じた値が、１のクリップインフォメーションファイルの最大サイズSIZE_1CLIPよりも小さければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３０１】
図４９は、上述のステップＳ１０９の、制約（６）および制約（７）に対応した、追記候補とされたプレイリストファイルから参照されるクリップインフォメーションファイルに格納されるエントリポイントの合計数に基づく追記可否判断の一例の処理を示す。
【０３０２】
既に説明したように、１のプレイリストファイルから参照されるクリップインフォメーションファイルに関し、ブロックblkEPMap()に格納されるエントリポイントの合計数に対して上限が設けられている。チャプタの追記により追記候補のプレイリストに対してクリップインフォメーションファイルが追加された際に、当該追記候補のプレイリストファイルに関連するクリップインフォメーションファイルに格納されるエントリポイントの合計数が、この上限値を超えないようにする必要がある。
【０３０３】
なお、制約（６）および制約（７）によれば、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとのそれぞれに対して上限が設けられている。したがって、判定も、クリップインフォメーションファイルに格納される粗い単位で検索を行うエントリポイントおよび精密な単位で検索を行うエントリポイントのそれぞれについて、行う必要がある。
【０３０４】
１のプレイリストファイルに関連しているクリップインフォメーションファイル内の、粗い単位で検索を行うエントリポイントの合計値の上限値MAX_EP_COARSEは、例えば２４５７６個とされる。また、精密な単位で検索を行うエントリポイントの合計値の上限値MAX_EP_FINEは、例えば１８００００個とされる。
【０３０５】
先ず、ステップＳ１７０で、予め計算しておいた１チャプタ当たりの最大エントリポイント数を取得する。上述したように、記録機の仕様として、一般的に、連続記録が保証される最低時間が設定される。この連続記録が保証される最低時間分の記録を行った際の、最大のエントリポイント数を予め計算しておき、このステップＳ１７０で、この値を取得する。
【０３０６】
図２５および図２６を用いて説明したように、粗い単位で検索を行うエントリポイントは、１１．５秒毎（ＰＴＳ：エントリPTSEPCoarse）または２５ＭＢ毎（ソースパケット番号：エントリSPNEPCoarse）に設けられる。ここで、連続記録が保証される最低時間を時間MIN_TIME(hr)、当該最低時間分の記録を行った場合に生成されるクリップＡＶストリームファイルのデータ量をデータ量MIN_SIZE(MB)とした場合、粗い単位で検索を行うエントリポイントについて、１チャプタ当たりの最大エントリポイント数NEEDED_EP_COARSEは、次式（７）により求められる。なお、式（７）および後述する式（８）において、「CEIL」は、括弧内の値について小数点を切り上げることを示す。
NEEDED_EP_COARSE＝CEIL ( 3600[sec]×MIN_TIME[hr]÷11.5[sec] )＋CEIL ( MIN_SIZE[MB]÷25[MB] ) ・・・（７）
【０３０７】
また、精密な単位で検索を行うエントリポイントは、ＧＯＰ毎に、ＰＴＳの精度（エントリPTSEPFine）またはソースパケットの精度（エントリSPNEPFine）で設けられる。この実施の一形態では、精密な単位で検索を行うエントリポイントとしてエントリPTSEPFineのみを用いるものとし、フレーム周波数を２９．９７Ｈｚ、１ＧＯＰが１５フレームから構成されるとした場合、精密な単位で検索を行うエントリポイントについて、１チャプタ当たりの最大エントリポイント数NEEDED_EP_FINEは、次式（８）により求められる。なお、式（８）中、「90[kHz]÷3003」は、ＰＴＳ精度に基づくフレーム周波数（２９．９７Ｈｚ）を示す。
NEEDED_EP_FINE＝CEIL ( 3600[sec]×MIN_TIME[hr]×90[kHz]÷3003÷15[Frame/GOP] ) ・・・（８）
【０３０８】
次のステップＳ１７１で、追記候補のプレイリストファイルから参照されている全てのクリップインフォメーションファイルについて、粗い単位で検索を行うエントリポイントと、精密な単位で検索を行うエントリポイントとをそれぞれ取得し、粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEと、精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとをそれぞれ求める。
【０３０９】
より具体的には、クリップインフォメーションファイル内のフィールドNumberOfStreamPIDEntriesと、フィールドNumberOfEPCoarseEntries[k]およびフィールドNumberOfEPFineEntries[k]とに基づき、粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEと、精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとを求めることができる。
【０３１０】
次のステップＳ１７２では、追記候補のプレイリストファイルに対してチャプタを追記した際に、粗い単位で検索を行うエントリポイントについて、上限値MAX_EP_COARSEを超えないか否かが判定される。すなわち、上述のステップＳ１７０で取得された、粗い単位で検索を行うエントリポイントの１チャプタ当たりの最大エントリポイント数NEEDED_EP_COARSEと、ステップＳ１７１で求められた粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEとを用いて、次式（９）に基づき判定がなされる。
MAX_EP_COARSE−TOTAL_EP_COARSE≧NEEDED_EP_COARSE ・・・（９）
【０３１１】
若し、各値の関係がこの式（９）を満たしていない、すなわち、１チャプタ当たりの粗い単位で検索を行うエントリポイントの最大エントリポイント数NEEDED_EP_COARSEが、１のプレイリストファイルに関連するクリップインフォメーションファイルの粗い単位で検索を行うエントリポイントの合計値の上限値MAX_EP_COARSEと、追記候補のプレイリストファイルに関連するクリップインフォメーションファイルの粗い単位で検索を行うエントリポイントの合計TOTAL_EP_COARSEとの差分より大きければ、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３１２】
一方、各値の関係が式（９）を満たしていると判定されれば、処理は次のステップＳ１７３に移行される。ステップＳ１７３では、精密な単位で検索を行うエントリポイントについて、同様の判定がなされる。すなわち、上述のステップＳ１７０で取得された、精密な単位で検索を行うエントリポイントの１チャプタ当たりの最大エントリポイント数NEEDED_EP_FINEと、ステップＳ１７１で求められた精密な単位で検索を行うエントリポイントの合計TOTAL_EP_FINEとを用いて、粗い単位で検索を行うエントリポイントの上限値MAX_EP_FINEについて、次式（１）に基づき判定がなされる。
MAX_EP_FINE−TOTAL_EP_FINEE≧NEEDED_EP_FINE・・・（１０）
【０３１３】
若し、各値の関係がこの式（１０）を満たしていないと判定されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、各値の関係がこの式（１０）を満たしていると判定されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。
【０３１４】
図５０は、上述のステップＳ１１０の、制約（８）に対応した、追記候補とされたプレイリストファイル内における他機による独自の拡張データの有無に基づく追記可否判定の一例の処理を示す。
【０３１５】
先ず、最初のステップＳ１８０で、追記候補のプレイリストファイルの拡張データから、ＡＶＣＤＨフォーマットに準拠した拡張データを検索する。
【０３１６】
すなわち、図１０を参照し、追記候補のプレイリストファイルのフィールドExtensionDataStartAddressの値が取得され、取得された値が"０"か否かが判断される（図示しない）。値が"０"でなければ、当該プレイリストファイル内に拡張データブロックblkExtensionData()が存在するので、フィールドExtensionDataStartAddressの値に基づきブロックblkExtensionData()が参照される。そして、図３３を参照し、プレイリストファイル内の拡張データブロックblkPlayListExtensionData()において、フィールドExtDataTypeおよびフィールドExtDataVersionがＡＶＣＨＤフォーマットに規定されている値になっているか否かを調べる。
【０３１７】
次のステップＳ１８１では、ステップＳ１８０の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在するか否かが判断される。
【０３１８】
すなわち、ステップＳ１８０の検索結果に基づき、追記候補のプレイリストファイル内のフィールドExtensionDataStartAddressの値が"０"であるか、若しくは、拡張データブロックblkPlayListExtensionData()内のフィールドExtDataTypeおよびフィールドExtDataVersionがＡＶＣＨＤフォーマットに規定されている値ではない場合は、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在しないと判断される。この場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３１９】
一方、ステップＳ１８１で、ステップＳ１８０の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在すると判断されれば、処理はステップＳ１８２に移行される。ステップＳ１８２では、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データ以外に、さらに拡張データが存在するか否かが判断される。若し、存在すると判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３２０】
ステップＳ１８２で、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データ以外の拡張データが存在しないと判断されれば、処理はステップＳ１８３に移行される。ステップＳ１８３では、検索された、追記候補のプレイリストファイルの拡張データブロックblkPlayListExtensionData()のブロックblkMakersPrivateData()が参照され、自機のデータが検索される。すなわち、図３５を参照し、ブロックblkMakersPrivateData()内のフィールドMakerIDおよびフィールドMakerModelCodeに基づき、自機を示すデータが検索される。
【０３２１】
次のステップＳ１８４で、ステップＳ１８３の検索結果に基づく判断がなされる。ステップＳ１８４では、ステップＳ１８３の検索結果に基づき、若し、自機の拡張データが存在しないと判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、ステップＳ１８４で、ステップＳ１８３の検索結果に基づき自機の拡張データが存在すると判断されれば、処理はステップＳ１８５に移行される。
【０３２２】
ステップＳ１８５では、ステップＳ１８３の検索結果に基づき、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在するか否かが判断される。すなわち、ブロックblkMakersPrivateData()内のフィールドMakerIDおよびフィールドMakerModelCodeに、自機を示すデータ以外のデータが存在すれば、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在すると判断することができる。
【０３２３】
ステップＳ１８５で、ブロックblkMakersPrivateData()内に自機以外の機器による拡張データが存在すると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。一方、ブロックblkMakersPrivateData()内に自機による拡張データのみが存在すると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。
【０３２４】
なお、上述のステップＳ１８１では、追記候補のプレイリストファイルにＡＶＣＨＤフォーマットに準拠した拡張データが存在しない場合に、チャプタの追記候補のプレイリストファイルに対する追記が不可であるとしていたが、これはこの例に限定されない。すなわち、記録機の仕様によっては、追記候補のプレイリストファイルに、拡張データブロックblkMakersPrivateDataが全く存在しない場合に、チャプタの追記候補のプレイリストファイルに対する追記が可能とすることも考えられる。
【０３２５】
図５１は、上述したステップＳ１１１の、制約（９）に対応した、追記候補のプレイリストファイルの最終更新者に基づく追記可否判定の一例の処理を示す。追記候補のプレイリストファイルの最終更新者が自機でない場合には、追記候補のプレイリストファイルにおけるタイトルやチャプタの概念が自機とは異なり、再生時に不都合が生じる可能性がある。追記候補のプレイリストファイルの最終更新者情報に基づき、最終更新者が自機である場合にのみ、追記候補のプレイリストファイルに対してチャプタの追記をするように制御することで、１のプレイリストファイル内でのタイトルやチャプタの概念の差異による不都合を回避することが可能である。
【０３２６】
先ず、最初のステップＳ１９０で、追記候補のプレイリストファイルの拡張データから、ＡＶＣＤＨフォーマットに準拠した拡張データを検索する。そして、次のステップＳ１９１で、ステップＳ１９０の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在するか否かが判断される。なお、これらステップＳ１９０およびステップＳ１９１の処理は、図５０を用いて説明したステップＳ１８０およびステップＳ１８１の処理と同一なので、繁雑さを避けるために詳細な説明を省略する。
【０３２７】
ステップＳ１９１で、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在しないとされた場合、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３２８】
一方、ステップＳ１９１で、ステップＳ１９０の検索結果に基づき、追記候補のプレイリストファイルの拡張データに、ＡＶＣＨＤフォーマットに準拠した拡張データが存在すると判断されれば、処理はステップＳ１９２に移行される。ステップＳ１９２では、追記候補のプレイリストファイルの最終更新者が確認される。すなわち、拡張データブロックblkPlayListExtensionData()のブロックblkPlayListMeta()が参照され、フィールドMakerIDおよびフィールドMakerModelCodeのデータが取得される。
【０３２９】
ステップＳ１９２で追記候補のプレイリストファイルの最終更新者が確認されると、処理はステップＳ１９３に移行され、確認された最終更新者が自機であるか否かが判断される。すなわち、拡張データブロックblkPlayListExtensionData()のブロックblkPlayListMeta()におけるフィールドMakerIDおよびフィールドMakerModelCodeのデータが自機を示していれば、最終更新者が自機であると判断できる。
【０３３０】
ステップＳ１９３で、追記候補のプレイリストファイルの最終更新者が自機であると判断されれば、チャプタの追記候補のプレイリストファイルに対する追記が可能であると判断する。一方、追記候補のプレイリストファイルの最終更新者が自機ではないと判断されれば、当該チャプタの追記候補のプレイリストファイルに対する追記が不可であると判断する。
【０３３１】
なお、最終更新者の情報は、インデックスファイルにも格納することができる。例えば、インデックスファイルにおける拡張データブロックblkIndexExtensionData()内のブロックblkMakersPrivateData()に最終更新者の情報を格納することが考えられる。この場合、このインデックスファイルに格納された最終更新者情報を用いて、この図５１のフローチャートによる判断を行ってもよい。
【０３３２】
上述した制約（１０）の、規定時間以上の連続撮影および記録に関しては、図４３のステップＳ１０８および図４８を用いて説明したクリップインフォメーションファイルのファイルサイズに関する処理、ならびに、図４３のステップＳ１０９および図４９を用いて説明したクリップインフォメーションファイルにおけるエントリポイントに関する処理に含まれるため、詳細な説明を省略する。
【０３３３】
上述では、図４３を用いて説明した、追記候補のプレイリストファイルに対してチャプタを追記するか、新規にプレイリストファイルを作成するかの一連の判断を、記録媒体２０が記録機に装填された際に行われるように説明したが、これはこの例に限定されない。例えば、チャプタの追記毎、例えば記録開始操作毎に判断を行うようにしてもよい。
【０３３４】
次に、上述した図４３〜図５１を用いて説明した処理の結果、追記候補のプレイリストファイルに対してチャプタを追記する際の処理について説明する。図５２は、プレイリストファイルに対してチャプタを追記する一例の処理を示すフローチャートである。
【０３３５】
ステップＳ２００で記録開始操作が行われると、次のステップＳ２０１で、クリップＡＶストリームの記録媒体２０への記録が開始される。例えば、ＵＩ部３１に設けられた記録開始を指示する記録開始スイッチが操作されることで、記録開始を指示する制御信号がＵＩ部３１から制御部３０に供給され、制御部３０により、この記録開始を指示する制御信号に基づき、記録部１０の各部に対し、端子４０から入力されるベースバンドのビデオデータと、端子４１から入力されるベースバンドのオーディオデータとを記録媒体２０に記録するように制御する。
【０３３６】
記録開始の制御に応じて、クリップＡＶストリームが記録媒体２０に記録される（ステップＳ２０１）。すなわち、入力されたビデオデータおよびオーディオデータがビデオエンコーダ１１およびオーディオエンコーダ１２でそれぞれ圧縮符号化され、マルチプレクサ１３でパケット化されＴＳパケット（実際にはさらに所定のヘッダが付加されたソースパケット）とされてストリームバッファ１４に供給される。ストリームバッファ１４に所定量以上のＴＳパケットが溜め込まれたら、記録制御部１５によりストリームバッファ１４からＴＳパケットが読み出される。読み出されたＴＳパケットは、所定にファイル名が付されたクリップＡＶストリームファイルに格納されて記録媒体２０に記録される。
【０３３７】
例えば、記録媒体２０に既にファイル名"00001.m2ts"であるクリップＡＶストリームファイルが記録されている場合には、新たに記録されるクリップＡＶストリームファイルのファイル名として既に記録されているファイルと重複しないファイル名が選ばれ、例えばファイル名"00002.m2ts"とされる。
【０３３８】
なお、クリップＡＶストリームの記録媒体２０への記録に伴い、管理情報処理部１６により、記録されるデータの再生時間とアドレスとの対応関係を示す情報がリアルタイムに生成される。このデータは、上述したクリップインフォメーションファイル"zzzzz.clpi"内のブロックblkEPMap()に格納されるデータとして、揮発性メモリ１７に記憶される。
【０３３９】
次のステップＳ２０２で、記録停止操作が行われたか否かが判断される。例えば、ユーザによりＵＩ部３１に設けられた記録停止スイッチが操作され、記録が停止されたと判断されれば、処理はステップＳ２０３に移行される。一方、記録が停止されていなければ、処理はステップＳ２０１に戻され、クリップＡＶストリームの記録媒体２０への記録が継続される。
【０３４０】
ステップＳ２０３では、記録の停止に伴い、ストリームバッファ１４に溜め込まれているストリームが全て記録媒体２０に書き込まれる。例えば、記録制御部１５は、制御部３０からの記録停止の命令に応じて、ストリームバッファ１４に溜め込まれているストリーム（ＴＳパケット）を全て読み出し、記録媒体２０に書き込む。
【０３４１】
また、記録停止の命令に応じて、例えばビデオエンコーダ１１およびオーディオエンコーダ１２の動作が停止される。このとき、図１３Ａを用いて説明した第１のシームレス接続を行うために、例えば、オーディオエンコーダ１２の動作がビデオエンコーダ１１の動作が停止してから所定時間後に停止されるように制御される。
【０３４２】
次のステップＳ２０４〜ステップＳ２０８で、管理情報処理部１６により、記録媒体２０に書き込まれたクリップＡＶストリームファイルに関するクリップインフォメーションファイルが生成されると共に、追記候補のプレイリストファイルの更新が成される。
【０３４３】
先ず、ステップＳ２０４で、管理情報処理部１６により、クリップインフォメーションファイル"zzzzz.clpi"が生成される。ファイル名は、例えばこのクリップインフォメーションファイルが示すクリップＡＶストリームファイルのファイル名と対応するファイル名とされ、当該クリップＡＶストリームファイルのファイル名が"00002.m2ts"であれば、このクリップインフォメーションファイルのファイル名は、拡張子より前の部分が同一のファイル名"00002.clpi"とされる。
【０３４４】
クリップインフォメーションファイル"00002.clpi"に、図１５〜図２１に例示した各シンタクスに従い、各フィールドやフラグの値が所定に設定され格納される。一例として、ＴＳパケットに関する情報や、再生時間（ＰＴＳ）に関する情報は、管理情報処理部１６により、クリップの記録中にマルチプレクサ１３から取得された情報に基づき生成される。また、記録媒体２０上の記録アドレスに関する情報は、管理情報処理部１６により、クリップの記録中に記録制御部１５から取得された情報に基づき生成される。システムにより固有の値は、例えば予めＲＯＭ（図示しない）などに記憶されている情報に基づく。さらに、再生時間とアドレスとの対応関係を示す上述したブロックblkEPMap()の情報が、クリップインフォメーションファイル"00002.clpi"のブロックblkCPI()に格納される。
【０３４５】
また、ブロックblkClipInfo()内のフラグIsCC5は、ユーザ操作によりクリップの記録が停止された場合、値が１（バイナリ値）とされる。それに伴い、ブロックblkClipInfo()内のif文（図１６参照）で示されるデータが所定に設定される。
【０３４６】
クリップインフォメーションファイルの作成が完了したら、処理は次のステップＳ２０５に移行する。ステップＳ２０５〜ステップＳ２０８の処理は、プレイリストファイルに関する処理である。このステップＳ２０５〜ステップＳ２０８の処理により、既に記録媒体２０上に存在するプレイリストファイルに対して、新たに記録されたクリップＡＶストリームファイル"00002.m2ts"に対応するプレイアイテムが追加される。
【０３４７】
先ず、ステップＳ２０５で、プレイリストファイル内のブロックblkPlayItem()におけるフィールドConnectionConditionの値が"５"に設定され、このクリップが次のクリップと第１のシームレス接続を行うことが示される（図１２参照）。次にステップＳ２０６で、プレイアイテムファイルのフィールドNumberOfPlayItemsの値が"１"だけインクリメントされ、当該プレイリストに対してプレイアイテムが１つ、追加されることが示される（図１１参照）。
【０３４８】
次のステップＳ２０７で、ブロックblkPlayItem()におけるフィールドClipInformationFileName、フィールドINTimeおよびフィールドOUTTimeがそれぞれ設定され、クリップの記録に伴い追加されるブロックblkPlayItem()が作成される。フィールドClipInformationFileNameは、上述のステップＳ２０５で作成されたクリップインフォメーションファイルのファイル名"00002.clpi"が格納される。実際には、クリップインフォメーションファイルの拡張子は固定的とされているので、ピリオドの前の部分"00002"が格納される。フィールドINTimeおよびフィールドOUTTimeは、対応するクリップＡＶストリームファイル"00002.m2ts"に格納されるビデオストリームの先頭および終端の時間を示す情報であって、例えばクリップインフォメーションファイル"00002.clpi"内のブロックblkCPI()におけるブロックblkEPMap()の情報に基づく。
【０３４９】
次のステップＳ２０８で、追記候補のプレイリストファイル内のブロックblkPlayListMark()におけるフィールドNumberOfPlayListMarksの値が"１"だけインクリメントされ、それに伴いforループ文内に追加されたフィールドMarkTimeStampの値が、上述のステップＳ２０７でブロックblkPlayItem()におけるフィールドINTimeの値に設定される。すなわち、新たに記録されたクリップの先頭に、プレイリストマークが打たれる。プレイリストマークが打たれることにより、チャプタが形成される。すなわち、これにより、追記候補のプレイリストファイルに対してチャプタが追記される。
【０３５０】
このようにして、新たに記録されたクリップＡＶストリームファイル"00002.m2ts"に対して、クリップインフォメーションファイル"00002.clpi"が作成されると共に、追記候補のプレイリストファイルの更新がなされる。またこのとき、プレイリストファイルにおける拡張データブロックblkPlayListExtensionData()内のブロックblkPlayListMeta()の情報を更新するようにしてもよい。
【０３５１】
なお、上述したステップＳ２０３によるストリームバッファ１４に溜め込まれたデータの記録媒体２０への書き込み処理は、ステップＳ２０８の処理の後に行うようにしてもよい。
【０３５２】
プレイリストファイルを新規に作成してチャプタを形成する場合には、上述の処理のうち、ステップＳ２０５以下の処理が若干、異なることになる。すなわち、プレイリストファイルにおける各フィールドのデータは、それぞれ新規に生成されることになる。これに限らず、例えばプレイリストファイルのテンプレートを用意しておき、テンプレートのデータを変更することも考えられる。
【０３５３】
次に、この発明の実施の一形態の他の例について説明する。上述では、この発明が単体の記録装置に適用された例について説明した（図４１参照）。これに対し、この実施の一形態の他の例では、この発明を、撮像素子と、被写体からの光を撮像素子に入射させる光学系とを有し、撮像素子で撮像された撮像信号に基づきビデオデータを記録媒体に記録するようにした、ビデオカメラ装置に適用した。
【０３５４】
図５３は、この発明の実施の一形態の他の例によるビデオカメラ装置１００の一例の構成を示す。ビデオカメラ装置１００において、記録系の構成は、図４１を用いて説明した記録装置の構成を略そのまま適用できるので、図４１と共通する部分には同一の符号を付し、詳細な説明を省略する。
【０３５５】
図５３の構成において、カメラ部５０は、映像信号に関する構成として、光学系５１、撮像素子５２、撮像信号処理部５３、カメラ制御部５４および表示部５５を有し、音声信号に関する構成として、マイクロフォン（ＭＩＣ）５６および音声信号処理部５７を有する。制御部３０は、カメラ部５０の各部との間で各種制御信号や情報のやりとりを行い、カメラ部５０の動作を制御する。また、制御部５０は、ユーザ操作に応じてＵＩ部３１から供給される制御信号に基づき、カメラ部５０の動作を制御する。
【０３５６】
なお、ビデオカメラ装置１００として構成される場合、記録開始操作および記録停止操作は、例えば、ＵＩ部３１に設けられた単一の記録スイッチを用い、当該記録スイッチが押下される毎に記録開始および記録停止が交互に指示されるようになされるのが一般的である。また、このビデオカメラ装置１００では、記録媒体２０として、記録可能なタイプのＤＶＤやＢｌｕ−ｒａｙ Ｄｉｓｃといった、ディスク記録媒体を適用するものとする。
【０３５７】
カメラ部５０において、光学系５１は、被写体からの光を撮像素子５２に導くためのレンズ系、絞り調整機構、フォーカス調整機構、ズーム機構、シャッタ機構などを備える。絞り調整機構、フォーカス調整機構、ズーム機構およびシャッタ機構の動作は、制御部３０から供給される制御信号に基づき、カメラ制御部５４により制御される。
【０３５８】
撮像素子５２は、例えばＣＣＤ(Charge Coupled Device)からなり、光学系５１を介して照射された光を光電変換により電気信号に変換し、所定の信号処理を施し撮像信号として出力する。撮像信号処理部５３は、撮像素子から出力された撮像信号に対して所定の信号処理を施し、ベースバンドのディジタルビデオデータとして出力する。
【０３５９】
例えば撮像信号処理部５３は、撮像素子５２から出力された撮像信号に対して、ＣＤＳ(Correlated Double Sampling)回路により画像情報を有する信号だけをサンプリングすると共に、ノイズを除去し、ＡＧＣ(Auto Gain Control)回路によりゲインを調整する。そして、Ａ／Ｄ変換によりディジタル信号に変換する。また、撮像信号処理部５３は、このディジタル信号に対して検波系の信号処理を施し、Ｒ（赤色）、Ｇ（緑色）およびＢ（青色）各色の成分を取り出し、γ補正やホワイトバランス補正などの処理を行い、最終的に１本のベースバンドのディジタルビデオデータとして出力する。
【０３６０】
また、撮像信号処理部５３は、撮像素子５２から出力された撮像信号の情報を制御部３０に送る。制御部３０は、この情報に基づき光学系５１を制御するための制御信号を生成し、カメラ制御部５４に供給する。カメラ制御部５４は、この制御信号に基づきフォーカス調整機構や絞り調整機構などの制御を行う。
【０３６１】
さらに、撮像信号処理部５３は、撮像素子５２から出力された撮像信号に基づき、例えばＬＣＤ(Liquid Crystal Display)を表示素子として用いた表示部５５に映出させる映像信号を生成する。
【０３６２】
一方、マイクロフォン５６は、周囲の音声を収音して電気信号に変換して出力する。マイクロフォン５６から出力された音声信号は、音声信号処理部５７に供給される。音声信号処理部５７は、供給された音声信号を、リミッタを介してからＡ／Ｄ変換を施してディジタルオーディオデータとし、ノイズ除去や音質補正など所定の音声信号処理を施してベースバンドのディジタルオーディオデータとして出力する。
【０３６３】
カメラ部５０の撮像信号処理部５３から出力されたベースバンドのディジタルビデオデータは、記録部１０の端子４０に供給される。また、音声信号処理部５７から出力されたベースバンドのディジタルオーディオデータは、記録部１０の端子４１に供給される。
【０３６４】
撮影時に、記録媒体２０がビデオカメラ装置１００に所定に装填されると、図４３を用いて説明した処理に従い、撮影して得られるビデオデータに基づくチャプタの追記候補のプレイリストファイルが特定されると共に、特定された追記候補のプレイリストファイルに対してチャプタを追記可能か否かが判断される。
【０３６５】
例えば、制御部３０の制御に基づき記録媒体２０に記録されているインデックスファイルが読み込まれ、管理情報処理部１６を介して揮発性メモリ１７に記憶される。制御部３０は、揮発性メモリ１７に記憶されたインデックスファイルの情報に基づき追記候補のプレイリストファイルを特定し、記録制御部１５に対して、当該追記候補のプレイリストファイルを記録媒体２０から読み出すように命令を出す。この命令に基づき記録媒体２０から読み出された追記候補のプレイリストファイルは、管理情報処理部１６を介して揮発性メモリ１７に記憶される。
【０３６６】
制御部３０は、揮発性メモリ１７に記憶された追記候補のプレイリストファイルの情報に基づき、記録制御部１５に対して、当該追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルを記録媒体２０から読み出すように命令を出す。この命令に基づき記録媒体２０から読み出されたクリップインフォメーションファイルは、揮発性メモリ１７に記憶される。制御部３０は、揮発性メモリ１７に記憶された追記候補のプレイリストファイルと、当該追記候補のプレイリストファイルに関連する全てのクリップインフォメーションファイルとに基づき、図４３のフローチャートにおけるステップＳ１０４〜ステップＳ１１１までの各判断を行う。各判断の結果は、それぞれ、例えば制御部３０のレジスタに保持される。
【０３６７】
制御部３０は、ステップＳ１０４〜ステップＳ１１１の各判断が終了すると、図４３のステップＳ１１２の処理により、ステップＳ１０４〜ステップＳ１１１の各判断の判断結果に対して総合的な判断を行い、撮影され得られるビデオデータに基づくチャプタを追記候補のプレイリストファイルに追記するか否かを判断する。制御部３０は、この判断結果に基づき、追記すると判断された場合は、チャプタを揮発性メモリ１７に記憶されている追記候補のプレイリストファイルに対して追記し、追記しないと判断された場合は、新規にプレイリストファイルを生成してこの新規のプレイリストファイルに対して記録するように、管理情報処理部１６を制御する。
【０３６８】
記録停止状態からＵＩ部３１に設けられた記録スイッチが押下されると、記録開始を指示する制御信号がＵＩ部３１から制御部３０に供給され、制御部３０の制御に基づきカメラ部５０から出力されたベースバンドのディジタルビデオ信号およびディジタルオーディオデータの記録媒体２０への記録が開始される。
【０３６９】
すなわち、既に説明したように、制御部３０の制御に基づきビデオエンコーダ１１およびオーディオエンコーダ１２の動作が開始され、ビデオデータおよびオーディオデータがそれぞれビデオエンコーダ１１およびオーディオエンコーダ１２で圧縮符号化され、マルチプレクサ１３で所定にパケット化され多重化されてＡＶストリームデータとされる。ＡＶストリームデータは、ストリームバッファ１４を介して、記録制御部１５に供給され、クリップＡＶストリームファイルとして記録媒体２０に記録される。
【０３７０】
ＵＩ部３１の記録スイッチが再び押下されると、記録が停止され、クリップインフォメーションファイルの作成や、プレイリストファイルの更新が行われる。管理情報処理部１６は、マルチプレクサ１３および記録制御部１５からの情報に基づき、記録媒体２０に記録されるクリップＡＶストリームファイルに対応するクリップインフォメーションファイルを作成すると共に、当該クリップインフォメーションファイルを参照するプレイアイテムを生成する。
【０３７１】
追記候補のプレイリストファイルにチャプタを追記するように判断されている場合には、当該追記候補のプレイリストファイルに対して、生成されたプレイアイテムを追加すると共プレイリストマークを打ち、チャプタを形成する。追記候補のプレイリストファイルに対するチャプタの追加が不可と判断されている場合には、新規に作成されたプレイリストファイルに対して、生成されたプレイアイテムの追加およびプレイリストマークの設定を行う。
【０３７２】
この状態からもう一度記録スイッチが押下されると、再び記録開始が指示され、新たなクリップＡＶストリームファイルの記録媒体２０への記録が開始される。この再度の記録開始の際に、図４３のフローチャートに従い再び追記候補のプレイリストファイルに対する新たな記録に基づくチャプタの追記可否判断を行うとよい。
【０３７３】
なお、上述では、図４１に示す記録装置や図５３に示すビデオカメラ装置１００の記録部１０がハードウェア的に構成されるように説明したが、これはこの例に限定されない。すなわち、記録部１０は、ソフトウェアとして構成することも可能である。この場合、ソフトウェアは、例えば制御部３０が有する図示されないＲＯＭに予め記憶される。これに限らず、記録部１０を、パーソナルコンピュータなどのコンピュータ装置上に構成することも可能である。この場合には、記録部１０をコンピュータ装置に実行させるソフトウェアは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭといった記録媒体に記録されて提供される。コンピュータ装置がネットワーク接続可能な場合、インターネットなどのネットワークを介して当該ソフトウェアを提供することも可能である。
【図面の簡単な説明】
【０３７４】
【図１】この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す略線図である。
【図２】インデックステーブルを説明するための略線図である。
【図３】クリップＡＶストリーム、クリップ情報、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ図である。
【図４】複数のプレイリストから同一のクリップを参照する方法を説明するための略線図である。
【図５】記録媒体に記録されるファイルの管理構造を説明するための略線図である。
【図６】ファイル"index.bdmv"の一例の構造を表すシンタクスを示す略線図である。
【図７】ブロックblkIndexes()の一例の構造を表すシンタクスを示す略線図である。
【図８】ファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す略線図である。
【図９】ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す略線図である。
【図１０】プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す略線図である。
【図１１】ブロックblkPlayList()の一例の構造を表すシンタクスを示す略線図である。
【図１２】ブロックblkPlayItem()の一例の構造を表すシンタクスを示す略線図である。
【図１３】第１および第２のシームレス接続を説明するための略線図である。
【図１４】ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す略線図である。
【図１５】クリップインフォメーションファイルの一例の構造を表すシンタクスを示す略線図である。
【図１６】ブロックblkClipInfo()の一例の構造を表すシンタクスを示す略線図である。
【図１７】ブロックblkProgramInfo()の一例の構造を表すシンタクスを示す略線図である。
【図１８】ブロックblkStreamCodingInfo(stream_index)の一例の構造を表すシンタクスを示す略線図である。
【図１９】フィールドVideoFormatで示されるビデオデータの一例のフォーマットを一覧で示す略線図である。
【図２０】フィールドFrameRateで示される一例のフレームレートを一覧で示す略線図である。
【図２１】フィールドAspectRatioで示される一例のフレームレートを一覧で示す略線図である。
【図２２】ブロックblkCPI()の一例の構造を表すシンタクスを示す略線図である。
【図２３】ブロックblkEPMap()の一例の構造を表すシンタクスを示す略線図である。
【図２４】ブロックblkEPMapForOneStreamPID(EP_stream_type, Nc, Nf)の一例の構造を表すシンタクスを示す略線図である。
【図２５】エントリPTSEPCoarseおよびエントリPTSEPFineの一例のフォーマットについて示す略線図である。
【図２６】エントリSPNEPCoarseおよびエントリSPNEPFineの一例のフォーマットについて示す略線図である。
【図２７】ブロックblkExtensionData()の一例の構造を表すシンタクスを示す略線図である。
【図２８】ブロックblkExtensionData()における各データの参照関係を模式的に示す略線図である。
【図２９】ブロックblkExtensionData()にデータを書き込む際の一例の処理を示すフローチャートである。
【図３０】ブロックblkExtensionData()から拡張データを読み出す際の一例の処理を示すフローチャートである。
【図３１】ファイル"index.bdmv"内のフィールドblkExtensionData()におけるブロックDataBlock()の一例の構造を表すシンタクスを示す略線図である。
【図３２】ブロックblkTableOfPlayList()の一例の構造を表すシンタクスを示す略線図である。
【図３３】プレイリストファイル"xxxxx.mpls"内のブロックblkExtensionData()におけるブロックDataBlock()の一例の構造を表すシンタクスを示す略線図である。
【図３４】ブロックblkPlayListMeta()の一例の構造を表すシンタクスを示す略線図である。
【図３５】プレイリストファイルにおけるブロックblkMakersPrivateData()の一例の構造を表すシンタクスを示す略線図である。
【図３６】クリップインフォメーションファイル内のブロックblkExtensionData()におけるブロックDataBlock()の一例の構造を表すシンタクスを示す。
【図３７】ブロックblkProgramInfoExt()の一例の構造を表すシンタクスを示す略線図である。
【図３８】ブロックblkStreamCodingInfoExt(i,j)の一例の構造を表すシンタクスを示す略線図である。
【図３９】仮想プレーヤの動作を概略的に示すフローチャートである。
【図４０】仮想プレーヤの動作を概略的に示す略線図である。
【図４１】この発明の実施の一形態に適用可能な記録装置の一例の構成を概略的に示すブロック図である。
【図４２】この発明の実施の一形態に適用可能な一例のデータ構造を示す略線図である。
【図４３】チャプタのプレイリストファイルへの追記可否を判定する一例の処理を示すフローチャートである。
【図４４】プレイアイテム数に基づく追記可否判断の一例の処理を示すフローチャートである。
【図４５】プレイリストマーク数に基づく追記可否判断の一例の処理を示すフローチャートである。
【図４６】ビデオ属性に基づく追記可否判断の一例の処理を示すフローチャートである。
【図４７】ファイルサイズに基づく追記可否判断の一例の処理を示すフローチャートである。
【図４８】追記候補プレイリストファイルから参照されるクリップインフォメーションファイルの合計ファイルサイズに基づく追記可否判断の一例の処理を示すフローチャートである。
【図４９】追記候補プレイリストファイルから参照されるクリップインフォメーションファイルに格納されるエントリポイントの合計数に基づく追記可否判断の一例の処理を示すフローチャートである。
【図５０】他機による独自の拡張データの有無に基づく追記可否判定の一例の処理を示すフローチャートである。
【図５１】追記候補プレイリストファイルの最終更新者に基づく追記可否判定の一例の処理を示すフローチャートである。
【図５２】この発明の実施の一形態によるクリップの一例の記録方法を示すフローチャートである。
【図５３】この発明の実施の一形態の他の例によるビデオカメラ装置の一例の構成を示す。
【符号の説明】
【０３７５】
１０ 記録部
１１ ビデオエンコーダ
１２ オーディオエンコーダ
１３ マルチプレクサ
１４ ストリームバッファ
１５ 記録制御部
１６ 管理情報処理部
１７ 揮発性メモリ
１８ 不揮発性メモリ
２０ 記録媒体
３０ 制御部
３１ ユーザインターフェイス部
５０ カメラ部
１００ ビデオカメラ装置

【特許請求の範囲】
【請求項１】
ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録装置において、
ビデオデータおよびオーディオデータが入力されるデータ入力部と、
上記ビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力部と、
上記ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録部と、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成部と
を有し、
上記管理情報生成部は、
既存の上記再生管理情報に基づき、上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする記録装置。
【請求項２】
請求項１に記載の記録装置において、
上記管理情報生成部は、
上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を上記既存の再生管理情報に含まれる上記所定の第２の管理情報に対して追記しないと判断した場合、上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を含む上記第２の管理情報を新規に生成する
ことを特徴とする記録装置。
【請求項３】
請求項１に記載の記録装置において、
上記管理情報生成部は、
上記ストリームファイルの記録に伴い更新されるようにされた上記第２の管理情報のうち、最も新しく更新された該第２の管理情報を、上記所定の第２の管理情報とする
ことを特徴とする記録装置。
【請求項４】
請求項１に記載の記録装置において、
上記第１の管理情報は、
上記記録媒体に記録される上記ストリームファイルに対し、少なくとも、該ストリームファイルの再生時刻情報とアドレス情報との対応関係を示す情報が格納されたファイルからなり、
上記第２の管理情報は、
該ストリームファイルに対して再生開始点と再生終了点とを設定することにより再生区間を指定する１以上の再生区間情報が格納され、上記ストリームファイルに対する再生時刻情報を示すマーク情報が格納可能とされたファイルからなり、
上記第２の管理情報は、上記再生区間情報から上記第１の管理情報を参照することで上記ストリームファイルの再生方法を示すようにされた
ことを特徴とする記録装置。
【請求項５】
請求項４に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記再生区間情報の数に基づく
ことを特徴とする記録装置。
【請求項６】
請求項５に記載の記録装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に既に格納された上記再生区間情報の数が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項７】
請求項４に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記マーク情報の数に基づく
ことを特徴とする記録装置。
【請求項８】
請求項７に記載の記録装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に既に格納された上記マーク情報の数が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項９】
請求項４に記載の記録装置において、
上記第１の管理情報は、対応する上記ストリームファイルに格納される上記ビデオデータの属性を示すビデオ属性情報をさらに格納し、
上記管理情報生成部による上記追記可否判断は、
上記第１の管理情報に格納される上記ビデオ属性情報に基づく
ことを特徴とする記録装置。
【請求項１０】
請求項９に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
現在の記録モードに基づくビデオ属性と、上記所定の第２の管理情報から参照される上記第１の管理情報のうち少なくとも１の上記管理情報に格納されるビデオ属性とに基づきなされる
ことを特徴とする記録装置。
【請求項１１】
請求項１０に記載の記録装置において、
上記管理情報生成部は、
上記記録モードに基づくビデオ属性と、上記１の第１の管理情報に格納されるビデオ属性との間で、画枠サイズ、アスペクト比、フレームレートおよび走査方式のうち少なくとも１つが一致しない場合に、
上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記しないように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項１２】
請求項４に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報のファイルサイズに基づく
ことを特徴とする記録装置。
【請求項１３】
請求項１２に記載の記録装置において、
上記管理情報生成部は、
１の上記ストリームファイルの記録に伴い生成される上記再生区間情報および上記マーク情報のデータサイズに基づき、１の上記ストリームファイルが記録されることで上記第２の管理情報のファイルサイズが予め設定された上限を超えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項１４】
請求項４に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報から参照される全ての上記第１の管理情報の合計ファイルサイズに基づく
ことを特徴とする記録装置。
【請求項１５】
請求項１４に記載の記録装置において、
上記管理情報生成部は、
１の上記ストリームファイルの保証された最低連続時間の記録に伴い生成される上記第１の管理情報のデータサイズに基づき、１の上記ストリームファイルが記録されることで、上記所定の第２の管理情報から参照される上記第１の管理情報の合計ファイルサイズが予め設定された上限を越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項１６】
請求項４に記載の記録装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報から参照される全ての上記第１の管理情報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の数に基づく
ことを特徴とする記録装置。
【請求項１７】
請求項１６に記載の記録装置において、
上記管理情報生成部は、
１の上記ストリームファイルの保証された最低連続時間の記録に伴い生成される上記第１の管理情報に含まれる上記再生時刻情報とアドレス情報との対応関係を示す情報の数に基づき、１の上記ストリームファイルが記録されることで、上記第２の管理情報から参照される全ての上記第１の管理情報での合計が上記第２の管理情報に対して予め設けられた上限を越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項１８】
請求項４に記載の記録装置において、
上記第２の管理情報は、機器独自の情報をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記機器独自の情報に基づく
ことを特徴とする記録装置。
【請求項１９】
請求項１８に記載の記録装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に上記機器独自の情報が格納される場合に、該機器独自の情報が自機または自機と同等の機器により生成されたと判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項２０】
請求項４に記載の記録装置において、
上記第２の管理情報は、該第２の管理情報の最終更新者を示す情報をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記最終更新者情報に基づく
ことを特徴とする記録装置。
【請求項２１】
請求項２０に記載の記録装置において、
上記所定の第２の管理情報に上記最終更新者情報が格納される場合に、該最終更新者情報が自機を示していると判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項２２】
請求項１に記載の記録装置において、
上記管理情報生成部は、
１または複数の項目について上記追記可否判断を行い、該追記可否判断の結果、該１または複数の項目のうち１つでも追記不可を示していれば、上記記録媒体に記録される上記ストリームファイルに対応する上記第２の管理情報を、上記所定の第２の管理情報に対して追記しないように上記追記可否判断を行う
ことを特徴とする記録装置。
【請求項２３】
請求項２２に記載の記録装置において、
上記１または複数の項目は、
上記所定の第２の管理情報に格納される再生区間情報の数と、上記所定の第２の管理情報に格納されるマーク情報の数と、上記第１の管理情報に格納されるビデオ属性情報と、上記所定の第２の管理情報のファイルサイズと、上記所定の第２の管理情報から参照される全ての上記第１の管理情報の合計ファイルサイズと、上記所定の第２の管理情報から参照される全ての上記第１の管理情報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の数と、上記所定の第２の管理情報に格納される機器独自の情報と、上記所定の第２の管理情報に格納される最終更新者情報とのうち、少なくとも１の項目を含む
ことを特徴とする記録装置。
【請求項２４】
ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録方法において、
データ入力部に入力されたビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力のステップと、
上記ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップと
を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、上記記録指示入力のステップによる上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする記録方法。
【請求項２５】
ビデオデータとオーディオデータとを多重化して記録媒体に記録する記録方法をコンピュータ装置に実行させる記録プログラムにおいて、
上記記録方法は、
データ入力部に入力されたビデオデータおよびオーディオデータの記録開始および記録停止の指示が入力される記録指示入力のステップと、
上記ビデオデータおよびオーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップと
を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、上記記録指示入力のステップによる上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする記録プログラム。
【請求項２６】
撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置において、
被写体を撮像してビデオデータを出力する撮像部と、
音声を収音してオーディオデータを出力する収音部と、
上記ビデオデータおよび上記オーディオデータを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録部と、
上記ビデオデータおよび上記オーディオデータの上記記録媒体への記録開始および記録停止を指示するユーザ操作を受け付ける操作部と、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成部と
を有し、
上記管理情報生成部は、
既存の上記再生管理情報に基づき、上記操作部に対する上記ユーザ操作に応じた上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする撮像装置。
【請求項２７】
請求項２６に記載の撮像装置において、
上記管理情報生成部は、
上記操作部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を上記既存の再生管理情報に含まれる上記所定の第２の管理情報に対して追記しないと判断した場合、上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を含む上記第２の管理情報を新規に生成する
ことを特徴とする撮像装置。
【請求項２８】
請求項２６に記載の撮像装置において、
上記管理情報生成部は、
上記ストリームファイルの記録に伴い更新されるようにされた上記第２の管理情報のうち、最も新しく更新された該第２の管理情報を、上記所定の第２の管理情報とする
ことを特徴とする撮像装置。
【請求項２９】
請求項２６に記載の撮像装置において、
上記第１の管理情報は、
上記記録媒体に記録される上記ストリームファイルに対し、少なくとも、該ストリームファイルの再生時刻情報とアドレス情報との対応関係を示す情報が格納されたファイルからなり、
該ストリームファイルに対して再生開始点と再生終了点とを設定することにより再生区間を指定する１以上の再生区間情報が格納され、上記ストリームファイルに対する再生時刻情報を示すマーク情報が格納可能とされたファイルからなり、
上記第２の管理情報は、上記再生区間情報から上記第１の管理情報を参照することで上記ストリームファイルの再生方法を示すようにされた
ことを特徴とする撮像装置。
【請求項３０】
請求項２９に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記再生区間情報の数に基づく
ことを特徴とする撮像装置。
【請求項３１】
請求項３０に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に既に格納された上記再生区間情報の数が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項３２】
請求項２９に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記マーク情報の数に基づく
ことを特徴とする撮像装置。
【請求項３３】
請求項３２に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に既に格納された上記マーク情報の数が予め設定された上限未満であると判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項３４】
請求項２９に記載の撮像装置において、
上記第１の管理情報は、対応する上記ストリームファイルに格納される上記ビデオデータの属性を示すビデオ属性情報をさらに格納し、
上記管理情報生成部による上記追記可否判断は、
上記第１の管理情報に格納される上記ビデオ属性情報に基づく
ことを特徴とする撮像装置。
【請求項３５】
請求項３４に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
現在の記録モードに基づくビデオ属性と、上記所定の第２の管理情報から参照される上記第１の管理情報のうち少なくとも１の上記管理情報に格納されるビデオ属性とに基づきなされる
ことを特徴とする撮像装置。
【請求項３６】
請求項３５に記載の撮像装置において、
上記管理情報生成部は、
上記記録モードに基づくビデオ属性と、上記１の第１の管理情報に格納されるビデオ属性との間で、画枠サイズ、アスペクト比、フレームレートおよび走査方式のうち少なくとも１つが一致しない場合に、
上記記録指示入力部による上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記しないように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項３７】
請求項２９に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報のファイルサイズに基づく
ことを特徴とする撮像装置。
【請求項３８】
請求項３７に記載の撮像装置において、
上記管理情報生成部は、
１の上記ストリームファイルの記録に伴い生成される上記再生区間情報および上記マーク情報のデータサイズに基づき、１の上記ストリームファイルが記録されることで上記第２の管理情報のファイルサイズが予め設定された上限を超えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項３９】
請求項２９に記載の撮像装置において、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報から参照される全ての上記第１の管理情報の合計ファイルサイズに基づく
ことを特徴とする撮像装置。
【請求項４０】
請求項３９に記載の撮像装置において、
上記管理情報生成部は、
１の上記ストリームファイルの保証された最低連続時間の記録に伴い生成される上記第１の管理情報のデータサイズに基づき、１の上記ストリームファイルが記録されることで、上記所定の第２の管理情報から参照される上記第１の管理情報の合計ファイルサイズが予め設定された上限のサイズを越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項４１】
請求項２９に記載の撮像装置において、
上記第２の管理情報は、上記再生区間情報から上記第１の管理情報を参照することで、上記ストリームファイルの再生を制御するようにされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報から参照される全ての上記第１の管理情報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の数に基づく
ことを特徴とする撮像装置。
【請求項４２】
請求項４１に記載の撮像装置において、
上記管理情報生成部は、
１の上記ストリームファイルの保証された最低連続時間の記録に伴い生成される上記第１の管理情報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の数に基づき、１の上記ストリームファイルが記録されることで、上記第２の管理情報から参照される全ての上記第１の管理情報での合計が上記第２の管理情報に対して予め設けられた上限を越えないと判断したら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項４３】
請求項２９に記載の撮像装置において、
上記第２の管理情報は、機器独自の情報をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記機器独自の情報に基づく
ことを特徴とする撮像装置。
【請求項４４】
請求項４３に記載の撮像装置において、
上記管理情報生成部は、
上記所定の第２の管理情報に上記機器独自の情報が格納される場合に、該機器独自の情報が自機または自機と同等の機器により生成されたと判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項４５】
請求項２９に記載の撮像装置において、
上記第２の管理情報は、該第２の管理情報の最終更新者を示す情報をさらに格納可能とされ、
上記管理情報生成部による上記追記可否判断は、
上記所定の第２の管理情報に格納される上記最終更新者情報に基づく
ことを特徴とする撮像装置。
【請求項４６】
請求項４５に記載の撮像装置において、
上記所定の第２の管理情報に上記最終更新者情報が格納される場合に、該最終更新者情報が自機を示していると判断されたら、
上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記所定の第２の管理情報に対して追記するように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項４７】
請求項２６に記載の撮像装置において、
上記管理情報生成部は、
１または複数の項目について上記追記可否判断を行い、該追記可否判断の結果、該１または複数の項目のうち１つでも追記不可を示していれば、上記記録媒体に記録される上記ストリームファイルに対応する上記第２の管理情報を、上記所定の第２の管理情報に対して追記しないように上記追記可否判断を行う
ことを特徴とする撮像装置。
【請求項４８】
請求項４７に記載の撮像装置において、
上記１または複数の項目は、
上記所定の第２の管理情報に格納される再生区間情報の数と、上記所定の第２の管理情報に格納されるマーク情報の数と、上記第１の管理情報に格納されるビデオ属性情報と、上記所定の第２の管理情報のファイルサイズと、上記所定の第２の管理情報から参照される全ての上記第１の管理情報の合計ファイルサイズと、上記所定の第２の管理情報から参照される全ての上記第１の管理情報に含まれる再生時刻情報とアドレス情報との対応関係を示す情報の数と、上記所定の第２の管理情報に格納される機器独自の情報と、上記所定の第２の管理情報に格納される最終更新者情報とのうち、少なくとも１の項目を含む
ことを特徴とする撮像装置。
【請求項４９】
撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置の撮像方法において、
撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、
操作部に対する上記ビデオデータおよび上記オーディオデータの上記記録媒体への記録開始および記録停止を指示するユーザ操作を受け付けるステップと、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップと
を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、上記操作部に対する上記ユーザ操作に応じた上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする撮像方法。
【請求項５０】
撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化して記録媒体に記録する撮像装置の撮像方法をコンピュータ装置に実行させる撮像プログラムにおいて、
上記撮像方法は、
撮像部で被写体を撮像して得られたビデオデータと、収音部で音声を収音して得られたオーディオデータとを多重化し、多重化されたストリームをストリームファイルとして記録媒体に記録する記録のステップと、
操作部に対する上記ビデオデータおよび上記オーディオデータの上記記録媒体への記録開始および記録停止を指示するユーザ操作を受け付けるステップと、
上記ストリームファイルの属性情報を示す第１の管理情報と、上記ストリームファイルの再生方法を示す情報を含む第２の管理情報とからなる、上記記録媒体に記録される上記ストリームファイルの再生を制御するための再生管理情報を生成する管理情報生成のステップと
を有し、
上記管理情報生成のステップは、
既存の上記再生管理情報に基づき、上記操作部に対する上記ユーザ操作に応じた上記記録開始の指示に従い上記記録媒体に記録される上記ストリームファイルに対する上記再生方法を示す情報を、上記既存の再生管理情報に含まれる所定の上記第２の管理情報に対して追記するか否かの追記可否判断を行う
ことを特徴とする撮像プログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【図４９】

【図５０】

【図５１】

【図５２】

【図５３】

【公開番号】特開２００７−３１２０７１（Ｐ２００７−３１２０７１Ａ）
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願番号】特願２００６−１３８７０１（Ｐ２００６−１３８７０１）
【出願日】平成１８年５月１８日（２００６．５．１８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】