JP2008282471A - 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム - Google Patents

記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム Download PDF

Info

Publication number
JP2008282471A
JP2008282471A JP2007125642A JP2007125642A JP2008282471A JP 2008282471 A JP2008282471 A JP 2008282471A JP 2007125642 A JP2007125642 A JP 2007125642A JP 2007125642 A JP2007125642 A JP 2007125642A JP 2008282471 A JP2008282471 A JP 2008282471A
Authority
JP
Japan
Prior art keywords
stream data
recording
data
recording medium
stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007125642A
Other languages
English (en)
Inventor
Atsushi Mae
篤 前
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2007125642A priority Critical patent/JP2008282471A/ja
Publication of JP2008282471A publication Critical patent/JP2008282471A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Management Or Editing Of Information On Record Carriers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

【課題】ディスクの認識処理や初期化処理に要する時間をユーザに意識させずに記録を継続可能とする。
【解決手段】連続的に供給されるストリームデータをディスク５０Ａに記録し、時点Ａでディスク５０Ａからディスク５０Ｂに交換される。ディスク交換時のストリームデータをディスクに記録できない期間、ストリームデータの記録先をディスクから内蔵記録媒体５１に切り替え、ディスク交換時におけるディスクに対するデータ記録不可期間に供給されたストリームデータを内蔵記録媒体５１に退避させる。装填されたディスク５０Ｂに対する認識処理などが終了し、ディスク５０Ｂに対するストリームデータの記録が可能となると、ストリームデータの記録先を内蔵記録媒体５１からディスク５０Ｂに切り替え、内蔵記録媒体５１内の退避データをディスク５０Ｂにコピーし、その後、供給されるストリームデータをディスク５０Ｂに記録する。
【選択図】図３１

Description

この発明は、リアルタイムで取得されるストリームデータを記録可能なタイプの光ディスクに記録するようにした記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラムに関する。
記録可能なタイプの光ディスクは、安価且つ長期保存可能な記録媒体であることから、利便性が高く広く利用されている。そのため、近年では、ディジタルビデオカメラなどにおいても、ビデオデータを記録する記録媒体として、従来からの磁気テープに代わり、光ディスクを用いるようにした製品が多く出現している。記録可能なタイプのＤＶＤ(Digital Versatile Disc)に対してＤＶＤ−Ｖｉｄｅｏフォーマットで記録する撮像装置が記載されている。
特開２００４−３５０２５１
ドライブ装置に装填された光ディスクは、システムに対してマウントされることで、システムから利用可能となる。マウント処理は、例えば光ディスクをドライブに装填した際に光ディスクの所定領域のデータを読み出し、読み出したデータの基づき光ディスクがシステムに認識されることでなされる。また、記録可能なタイプの光ディスクを記録媒体として用いる場合、新規のディスクにデータを記録しようとする際には、光ディスクを予め所定のフォーマットに従い初期化する必要がある。例えば、上述の記録可能なタイプのＤＶＤでは、ファイルシステムにＵＤＦ(Universal Disk Format)が用いられており、ディスクを予めＵＤＦに従い初期化する必要がある。初期化処理は、例えばディスクの管理領域にフォーマットに基づく管理情報を書き込むことでなされる。これら初期化処理や認識処理の間は、当然のことながら、当該光ディスクに対して他のデータを書き込むことができない。
このように、記録可能なタイプの光ディスクでは、ドライブ装置への装填時に認識処理や初期化処理が行われる。したがって、長時間に亘って連続的な記録を行いたいと思っても、光ディスクの記録容量の上限などにより記録途中でディスクを交換する必要に迫られた場合、ディスクの交換時に交換されたディスクに対して認識処理や初期化処理がなされるため、その間の記録が中断してしまうという問題点があった。
すなわち、現在、記録可能なタイプの光ディスクとして主流を占めている、記録可能なタイプのＤＶＤは、ビデオデータの記録ビットレートに比べて記録容量が十分大きいとはいえないため、撮影現場においては、複数枚のディスクに亘って記録が行われる場合も往々にしてある。この場合、ディスクの交換作業中に記録が継続できないのは勿論のこと、交換によりドライブに新規に装填されたディスクに対する認識処理を行う必要があり、この認識処理中もデータの記録を行えず、複数枚のディスクに亘って連続的に記録を行うことができないという問題点があった。
さらに、仮に何らかの方法によって複数枚のディスクに亘って連続的に記録を行うことが可能となった場合に、これら複数枚のディスクに記録されているデータが連続的に記録されたデータであるか否かを容易に判断可能とされていることが望まれている。
一例として、後にユーザが、これら複数枚のディスクに分割して記録されたデータを、例えばより大きな記録容量を有する記録媒体に対して、時系列順に整列した一つのデータに結合して記録することが考えられる。この場合に、あるディスクに記録されたデータと別のディスクに記録されたデータとが連続的に記録されたものであるか否かを判断する必要がある。そして、あるデータと別のデータとが連続的に記録されたデータであると判断された場合には、それらのデータを時間的に連続した１のデータに結合する処理を行う。
さらに、ディジタルビデオカメラの記録媒体として記録可能なタイプの光ディスクを用いた場合、上述したような光ディスクの認識処理や初期化処理に長時間を要してしまい、貴重な撮影機会などを逃してしまうおそれがあるという問題点があった。
例えば、新規にディスクをドライブに装填して初めて撮影を開始する場合、装填されたディスクに対して初期化処理および認識処理を行った後に、初めてディスクにデータを記録することが可能となる。そのため、咄嗟に撮影を開始できず、撮影機会を逃してしまうおそれがあるという問題点があった。
したがって、この発明の目的は、記録可能なタイプの光ディスクを記録媒体として用いる場合に、ディスクの認識処理や初期化処理に要する時間をユーザに意識させずに記録を継続可能とした記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラムを提供することにある。
また、この発明の別の目的は、記録可能なタイプの光ディスクを記録媒体として用い複数枚の光ディスクに連続的に記録を行ったような場合に、一連の記録が複数枚の光ディスクに分割してなされたことをユーザが意識しなくても、分割されたデータを１のデータに結合する処理を実行可能なようにした記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラムを提供することにある。
上述した課題を解決するために、第１の発明は、ディスク状記録媒体にストリームデータを記録する記録装置において、着脱可能なディスク状記録媒体にデータを記録する第１の記録部と、筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録部と、連続的に供給されるストリームデータを一時的に溜め込むバッファ部と、第１の記録部がディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断部と、判断部の判断結果に基づき、バッファ部から読み出されたストリームデータの記録先をディスク状記録媒体と記録媒体とで切り替える記録制御部とを有することを特徴とする記録装置である。
また、第２の発明は、ディスク状記録媒体にストリームデータを記録する記録方法において、着脱可能なディスク状記録媒体にデータを記録する第１の記録のステップと、筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録のステップと、連続的に供給されるストリームデータを一時的にバッファ部に溜め込むステップと、第１の記録のステップによりディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断のステップと、判断のステップによる判断結果に基づき、バッファ部から読み出されたストリームデータの記録先をディスク状記録媒体と記録媒体とで切り替える記録制御のステップとを有することを特徴とする記録方法である。
また、第３の発明は、ディスク状記録媒体にストリームデータを記録する記録方法をコンピュータに実行させる記録プログラムにおいて、記録方法は、着脱可能なディスク状記録媒体にデータを記録する第１の記録のステップと、筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録のステップと、連続的に供給されるストリームデータを一時的にバッファ部に溜め込むステップと、第１の記録のステップによりディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断のステップと、判断のステップによる判断結果に基づき、バッファ部から読み出されたストリームデータの記録先をディスク状記録媒体と記録媒体とで切り替える記録制御のステップとを有することを特徴とする記録プログラムである。
また、第４の発明は、複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集方法において、第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断のステップと、判断のステップによる判断の結果、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、第１のストリームデータと第２のストリームデータのうち時間的に先行する側のストリームデータに対し、ストリームデータに後続するストリームデータとシームレスに接続することを示す接続情報を対応付けるステップとを有することを特徴とする編集方法である。
また、第５の発明は、複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集方法をコンピュータに実行させる編集プログラムにおいて、編集方法は、第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断のステップと、判断のステップによる判断の結果、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、第１のストリームデータと第２のストリームデータのうち時間的に先行する側のストリームデータに対し、ストリームデータに後続するストリームデータとシームレスに接続することを示す接続情報を対応付けるステップとを有することを特徴とする編集プログラムである。
また、第６の発明は、複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集装置において、第１のストリームデータと第１のストリームデータの接続状態を示す第１の接続状態管理情報とが記録された第１のディスク状記録媒体と、第２のストリームデータと第２のストリームデータの接続状態を示す第２の接続状態管理情報とが記録された第２のディスク状記録媒体とからデータを読み出す読み出し部と、第１の接続状態管理情報と第２の接続状態管理情報とに基づき、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断部と、判断のステップによる判断の結果、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、第１のストリームデータと第２のストリームデータのうち時間的に先行する側のストリームデータに対し、ストリームデータに後続するストリームデータとシームレスに接続することを示す接続情報を対応付ける編集部と、第１および第２のストリームデータと、第１および第２のストリームデータのうち時間的に先行する側のストリームデータに対して対応付けられた接続情報とを記録媒体に記録する記録部とを有することを特徴とする編集装置である。
上述したように、第１、第２および第３の発明は、着脱可能なディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断し、判断結果に基づき、連続的に供給されるストリームデータを一時的に溜め込むバッファ部から読み出されたストリームデータの記録先を、ディスク状記録媒体と筐体に対して固定的に用いられる記録媒体とで切り替えるようにしているため、記録に際して、ディスク状記録媒体の交換、認識処理、初期化処理などディスク状記録媒体がストリームデータを記録できない状態であっても、記録を継続させることができる。
また、第４、第５および第６の発明は、第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断し、判断の結果、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、第１のストリームデータと第２のストリームデータのうち時間的に先行する側のストリームデータに対し、ストリームデータに後続するストリームデータとシームレスに接続することを示す接続情報を対応付けるようにしているため、１のストリームデータを複数のディスク状記録媒体に分割して記録した場合でも、分割されたストリームデータを時間的に連続して再生させることが容易である。
第１、第２および第３の発明は、上述したように、着脱可能なディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断し、判断結果に基づき、連続的に供給されるストリームデータを一時的に溜め込むバッファ部から読み出されたストリームデータの記録先を、ディスク状記録媒体と筐体に対して固定的に用いられる記録媒体とで切り替えるようにしているため、記録に際して、ディスク状記録媒体の交換、認識処理、初期化処理などディスク状記録媒体がストリームデータを記録できない状態であっても、記録を継続させることができる効果がある。
また、第４、第５および第６の発明は、第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断し、判断の結果、第１のストリームデータと第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、第１のストリームデータと第２のストリームデータのうち時間的に先行する側のストリームデータに対し、ストリームデータに後続するストリームデータとシームレスに接続することを示す接続情報を対応付けるようにしているため、１のストリームデータを複数のディスク状記録媒体に分割して記録した場合でも、分割されたストリームデータを時間的に連続して再生させることが容易である効果がある。
さらに、第１〜第６の発明によれば、ユーザは、複数のディスク状記録媒体に亘って連続的にストリームデータの記録を行うことができ、再生時に、これら複数のディスク状記録媒体に分割して記録されたストリームデータを、１のコンテンツとして連続的に再生することを容易に行うことができる効果がある。
以下、この発明の実施の形態について、下記の順序に従って説明する。
１．発明に適用可能な一例のフォーマットについて
１−１．データモデルについて
１−２．ファイルの管理構造について
１−２−１．光ディスク以外の記録媒体に適用されるファイルの管理構造について
１−３．各ファイルの構造について
１−３−１．拡張データの構造について
１−３−２．拡張データの具体的な例
１−４．仮想プレーヤについて
２．発明に適用可能な記録装置について
３．発明に適用可能なデータ構造について
４．実施の第１の形態について
４−１．実施の第１の形態による記録制御について
４−２．実施の第１の形態によるストリームデータファイルの結合処理について
４−２−１．接続状態管理情報について
４−２−１−１．圧縮符号化方式に関する概略的な説明
４−２−１−２．ストリームの分割および結合について
４−２−２．オーサリング処理について
４−２−３．接続状態管理情報に基づくチャプタ結合可否判定処理
４−２−３−１．クリップインフォメーションファイルの編集の有無の判定について
５．実施の第２の形態について
６．実施の第３の形態について
１．発明に適用可能な一例のフォーマットについて
先ず、理解を容易とするために、この発明に適用可能な一例のフォーマット（以下、ＡＶＣＨＤフォーマットと呼ぶ）について説明する。ＡＶＣＨＤフォーマットは、ビデオデータとオーディオデータとが所定に多重化されたＡＶ(Audio/Video)ストリームを記録可能な記録媒体に記録する記録フォーマットとして現在提案されているもので、記録媒体に記録されたＡＶストリームを、クリップ単位でプレイリストを用いて管理可能としている。
例えばＩＴＵ−Ｔ(International Telecommunication Union-Telecommunication Standarization Sector)勧告Ｈ．２６４あるいはＩＳＯ(International Organization for Standarization)／ＩＥＣ(International Electrotechnical Commission)国際標準１４４９６−１０（ＭＰＥＧ−４パート１０）Advanced Video Coding（以下、Ｈ．２６４｜ＡＶＣと略称する）に規定される符号化方式や、ＭＰＥＧ(Moving Pictures Experts Group)ビデオやＭＰＥＧオーディオといった符号化方式で符号化され、ＭＰＥＧ２システムズに従い多重化されたビットストリームは、クリップＡＶストリーム（またはＡＶストリーム）と称される。クリップＡＶストリームは、所定のファイルシステムによりファイルとしてディスクに記録される。このファイルを、クリップＡＶストリームファイル（またはＡＶストリームファイル）と称する。
クリップＡＶストリームファイルは、ファイルシステム上での管理単位であり、ユーザにとって必ずしも分かりやすい管理単位であるとは限らない。ユーザの利便性を考えた場合、複数のクリップＡＶストリームファイルに分割された映像コンテンツを一つにまとめて再生する仕組みや、クリップＡＶストリームファイルの一部だけを再生する仕組み、さらには、特殊再生や頭出し再生を滑らかに行うための情報などをデータベースとしてディスクに記録しておく必要がある。
１−１．データモデルについて
図１は、この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す。このＡＶＣＨＤフォーマットによれば、データ構造は、図１に示されるように４層のレイヤよりなる。最も最下層のレイヤは、クリップＡＶストリームが配置されるレイヤである（便宜上、クリップレイヤと呼ぶ）。その上のレイヤは、クリップＡＶストリームに対する再生箇所を指定するための、プレイリスト(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"に格納される。
１−２−１．光ディスク以外の記録媒体に適用されるファイルの管理構造について
なお、光ディスク以外の記録媒体（例えば記録装置に内蔵されるハードディスクやフラッシュメモリ、記録装置に脱着可能なフラッシュメモリなど）にストリームデータファイルを記録する場合、この図５に示される管理構造とは若干異なった管理構造が適用される。図６は、ＡＶＣＨＤフォーマットによる、この光ディスク以外の記録媒体に適用可能な一例の管理構造を示す。
この図６の例では、ルートディレクトリの下にディレクトリ"AVCHD"が置かれ、このディレクトリ"AVCHD"の下に、ディレクトリ"BDMV"が置かれる。そして、このディレクトリ"BDMV"の直下に、２つのファイル、インデックスファイル"INDEX.BDM"およびムービーオブジェクトファイル"MOVIEOBJ.BDM"が置かれると共に、プレイリストファイルが格納されるディレクトリ"PLAYLIST"、クリップインフォメーションファイルが格納されるディレクトリ"CLIPINFO"およびストリームデータファイルが格納されるディレクトリ"STREAM"がそれぞれ置かれる。
なお、図６では省略されているが、サムネイルファイルを格納するディレクトリは、ディレクトリ"AVCHD"の下に、上述のディレクトリ"BDMV"と並列的に置かれる。
また、各ディレクトリにおいて、格納されるファイル名が、図５に示す、光ディスクに適用される管理構造の例とは異ならされる。例えばファイル名は、大文字を用いると共に"."（ピリオド）の後ろの部分が３文字とされる。図６の例では、インデックスファイルがファイル"INDEX.BDM"、ムービーオブジェクトファイルがファイル"MOVIEOBJ.BDM"、プレイリストファイルがファイル"XXXXX.MPL"、クリップインフォメーションファイルがファイル"ZZZZZ.CPI"、クリップＡＶストリームファイルがファイル"ZZZZZ.MTS"とされている。
これらファイル"INDEX.BDM"、ファイル"MOVIEOBJ.BDM"、ファイル"XXXXX.MPL"、ファイル"ZZZZZ.CPI"、ファイル"ZZZZZ.MTS"は、それぞれ図５のファイル"index.bdmv"、ファイル"MovieObject.bdmv"、ファイル"xxxxx.mpls"、ファイル"zzzzz.clpi"、ファイル"zzzzz.m2ts"に対応する。
１−３．各ファイルの構造について
図５および図６で示した各ファイルのうち、この発明に関わりの深いものについて、より詳細に説明する。なお、図６に示す各ファイルの説明は、図５に示す対応するファイルの説明で読み替えるものとする。先ず、ディレクトリ"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"の実質的な内容であって、このブロックblkIndexes()に記述された内容により、ディスクをプレーヤに装填した際に再生されるファーストプレイバックや、トップメニューから呼び出されるタイトル（ムービーオブジェクト）が指定される。インデックステーブルにより呼び出されたムービーオブジェクト等に記述されたコマンドに基づき、後述するプレイリストファイルが読み込まれる。
図８は、ブロック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)６４６に規定された符号化方式で符号化した４文字からなる文字列が記述される。この図９の例では、フィールドtype_indicatiorにＩＳＯ６４６に既定の方式で符号化された４文字の文字列"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()は、所定の拡張データを格納可能とするためのブロックである。
なお、この図１１に示すシンタクス内のフィールドpadding_wordは、１６ビットのデータ長を有し、このファイル"xxxxx.mpls"のシンタクスに従いforループ文に値N1、値N2および値N3で示される回数だけ挿入される。値N1、値N2または値N3は、０または任意の正の整数である。また、フィールドpadding_wordは、任意の値を用いることができる。
図１２は、ブロック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[0]は、４０ビット（５バイト）のデータ長を有し、このブロックblkPlayItem()が参照するクリップインフォメーションファイルのファイル名が示される。このプレイアイテムにおいて、フィールドClipInformationFileName[0]で示されるファイル名のクリップインフォメーションファイルが読み出される。フィールドClipCodecIdentifier[0]は、３２ビット（４バイト）のデータ長を有し、このブロックblkPlayItem()によるプレイアイテムにおいて用いられるクリップＡＶストリームのコーデック方式を示す。
１２ビットのデータ長を有する領域reservedを介して、フィールドConnectionConditionが配される。フィールドConnectionConditionは、４ビットのデータ長を有し、クリップ間の接続状態に関する情報を示す。記録用途の記録媒体に対しては、フィールドConnectionConditionの値として"１"、"５"または"６"が用いられる。フィールドConnectionConditionの値が"１"で、そのクリップと直前のクリップとがシームレス接続しないことを示し、フィールドConnectionConditionの値が"５"または"６"で、そのクリップと直前のクリップとがシームレス接続することを示す。なお、シームレス接続とは、クリップとクリップとがフレームタイミングで連続的に再生されるように、クリップ間の再生制御を行うことをいう。
フィールドConnectionConditionの値が"５"で、対応するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して長くされる（図１４Ａ参照）。これにより、クリップとクリップとを接続する際に、オーディオデータのフェイドアウト処理が可能とされる。例えば、ユーザによる記録停止操作によりクリップがクローズされる場合に、フィールドConnectionConditionの値が"５"とされる。以下、このフィールドConnectionConditionの値が"５"で示されるクリップの接続方法を、第１のシームレス接続と呼ぶ。
フィールドConnectionConditionの値が"６"で、対応するクリップにおいて、オーディオデータの記録長がビデオデータの記録長に対して同じか若しくは短いくされる（図１４Ｂ参照）。これにより、クリップとクリップとの接続をシームレスに行うことが可能とされる。例えば、ユーザ操作に応じた記録停止以外の理由、例えばシステム要因に基づきクリップがクローズされる場合に、フィールドConnectionConditionの値が"６"とされる。以下、このフィールドConnectionConditionの値が"６"で示されるクリップの接続方法を、第２のシームレス接続と呼ぶ。
なお、この第２のシームレス接続は、ファイルブレイク(File Break)と称され、フィールドConnectionConditionの値が"６"で以て、一続きのストリームファイルを複数のストリームファイルに分割して記録する際の境界の状態または条件が示される。
フィールドRefToSTCID[0]は、８ビットのデータ長を有し、ＳＴＣ(System Time Clock)の不連続点に関する情報を示す。フィールドINTimeおよびフィールドOUTTimeは、それぞれ３２ビットのデータ長を有し、メインクリップＡＶストリームの再生範囲を示す。フィールドINTimeが開始点（ＩＮ点）を示し、フィールドOUTTimeが終了点（ＯＵＴ点）を示す。
ブロックblkUOMaskTable()は、ユーザ入力の受付制限が設定されるテーブルである。１ビットのデータ長を有するフラグPlayItemRandomAccessFlagは、このブロックblkPlayItem()によるプレイアイテムに対してランダムアクセスを許可するか否かを規定する。続けて、７ビットのデータ長を有する領域reservedを介してフィールドStillModeが配される。フィールドStillModeは、８ビットのデータ長を有し、ブロックblkPlayItem()によるプレイアイテムにおいて、最後に表示した映像を静止画として表示させるか否かを示す。フィールドStillModeの値が"0x01"（バイナリ）であれば、if文に基づき、１６ビットのデータ長を有するフィールドStillTimeにより静止時間が示される。フィールドStillModeの値が"0x01"以外であれば、当該１６ビットのデータ長を有する領域がワードアライメントのために予約された領域reservedとされる。
ブロックblkSTNTable()は、このブロックblkPlayItem()によるプレイアイテムが管理しているクリップＡＶストリームの属性、ＰＩＤ番号、記録媒体上での記録位置などが管理される。
図１５は、ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkPlayListMark()の最後までのデータ長を示す。
フィールドNumberOfPlayListMarksは、１６ビットのデータ長を有し、このブロックblkPlayListMark()に含まれるプレイリストマークの数を示す。次のforループ文に従い、フィールドNumberOfPlayListMarksで示される数だけプレイリストマークの情報が記述される。
forループ文内において、８ビットのデータ長を有する領域reserveに続けてフィールドMarkTypeが配される。フィールドMarkTypeは、８ビットのデータ長を有し、マークのタイプを示す。フィールド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()は、このクリップインフォメーションファイルに管理されるクリップＡＶストリームの符号化方式、クリップＡＶストリーム中のビデオデータのアスペクト比などの情報が記述される。ブロックblkClipMark()は、チャプタ位置などの、クリップに付された頭出しのためのインデックス点（ジャンプポイント）が記述される。
ブロックblkCPI()は、ランダムアクセス開始点などの、ＡＶストリーム中の特徴的な箇所を表す特徴点情報ＣＰＩに関する情報が格納される。ＭＰＥＧストリームのような、フレーム間圧縮を行っている符号化ストリームにおいては、デコード開始可能な箇所は、ＧＯＰ(Group Of Picture)の先頭など一部の箇所に限定されていることが多い。ＣＰＩ(Characteristic Point Information)とは、そのデコード可能な開始点の位置の情報を集めたデータベースで、再生時刻と、ファイル内アドレスとが対応付けられたテーブルになっている。
すなわち、ＣＰＩは、デコード単位の先頭位置を示す情報がテーブル化されている。このようにデータベースを定めることで、例えば、任意の時刻から再生したい場合、再生時刻を元にＣＰＩを参照することによって再生位置のファイル内アドレスがわかる。このアドレスは、デコード単位の先頭となっているため、プレーヤは、そこからデータを読み出してデコードし、素早く画像を表示することができる。なお、このＣＰＩに格納される、デコード単位の先頭位置（この例ではＧＯＰの先頭位置）を、ＥＰ(Entry Point)エントリと称する。ＥＰエントリの数は、クリップＡＶストリームの記録が進むのに伴い、増加する。
図１７は、ブロック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が配される。
図１８は、ブロックblkSequenceInfo()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkSequenceInfo()の最後までのデータ長を示す。１５ビットのデータ長を有する領域reservedを介してデータ長が１ビットで固定値"１"が記述される。
次のフィールドSPNATCStartは、３２ビットのデータ長を有し、連続した時間に記録されたことを表すシーケンス（シーケンスATCSequenceと呼ぶ）の開始をパケット番号で表す。この図１８の例では、フィールドSPNATCStartは、値を"０"としてクリップＡＶストリームファイルの先頭と一致させている。フィールドNumberOfSTCSequenceは、シーケンスATCSequence上のシーケンスSTCSequenceの数を表す。フィールドNumberOfSTCSequenceは、値が"１"以上とされる。
次のforループ文に従い、フィールドNumberOfSTCSequenceで示される数だけ、シーケンスSTCSequenceの情報が記述される。シーケンスSTCSequenceは、ＭＰＥＧ２ ＴＳ(Transport Stream)における時間軸の基準であるＰＣＲ(Program Clock Reference)が連続な範囲を表す。シーケンスSTCSequenceには、クリップ内で一意な番号STC_idが割り当てられる。このシーケンスSTCSequence内では、不連続の無い一貫した時間軸を定義できるので、プレイアイテムの開始時刻および終了時刻を一意に定めることができる。つまり、各プレイアイテムの開始点と終了点は、同一のシーケンスSTCSequenceに存在していなければならない。このforループ文においては、値stc_idによりシーケンスSTCSequenceが指定される。
フィールドPCRPID[stc_id]は、１６ビットのデータ長を有し、ＭＰＥＧ２ ＴＳにおいて、ＰＣＲ(Program Clock Reference)が含まれるＴＳパケットのＰＩＤを表す。フィールドSPNSTCStart[stc_id]は、３２ビットのデータ長を有し、シーケンスSTCSequenceの開始をパケット番号で表す。フィールドPresentationStartTimeおよびフィールドPresentationEndTimeは、それぞれ３２ビットのデータ長を有し、クリップＡＶストリーム中の有効な範囲を表す。フィールドPresentationStartTimeおよびフィールドPresentationEndTimeで示される範囲がプレイアイテムから参照できる範囲となる。
図１６のクリップインフォメーションファイルの一例の構造を表すシンタクスにおいて、ブロックblkExtensionData()は、拡張データを格納することができる領域である。次に、このブロックblkExtensionData()について説明する。このブロックblkExtensionData()は、所定の拡張データを格納可能なように定義され、インデックステーブルが格納されるファイル"index.bdmv"、プレイリストが格納されるファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"の各ファイルに記述することができる。
１−３−１．拡張データの構造について
図１９は、ブロックblkExtensionData()の一例の構造を表すシンタクスを示す。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLengthの直後からブロックblkExtensionData()の終わりまでのデータ長をバイト数で示す。このフィールドLengthの示すデータ長が"０"でなければ、if文以下の記述がなされる。
ブロックDataBlock()StartAddressは、３２ビットのデータ長を有し、このシンタクス中の、拡張データの本体が格納されるブロックDataBlock()の開始アドレスを、このブロックblkExtensionData()の先頭バイトからの相対バイト数で示す。すなわち、相対バイト数は、"０"から開始される。なお、ブロックDataBlock()StartAddressは、次に示す３２ビットアライメントの条件を満たさなければならない。
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が、２フィールドを組として任意の回数Ｌ１だけ繰り返される。その後、拡張データの本体が格納されるブロックDataBlock()が記述される。ブロックDataBlock()は、１以上の拡張データが格納される。それぞれの拡張データext_dataは、上述したフィールドExtDataStartAddressフィールドExtDataLengthに基づき、ブロックDataBlock()から取り出される。
図２０は、ブロックblkExtensionData()における各データの参照関係を模式的に示す。フィールドLengthにより、フィールドLength直後の位置からブロックblkExtensionData()の最後までのデータ長が示される。ブロックDataBlock()StartAddressにより、ブロック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"およびクリップインフォメーションファイル"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()が格納される。なお、数値の記述において"0x"は、その数値が１６進表記されていることを示す。
ブロックblkIndexExtensionData()において、フィールドTypeIndicatorは、次に続くデータの種類を示す、ＩＳＯ６４６に規定された符号化方式で符号化した４文字からなる文字列が記述される。この図２３の例では、フィールドTypeIndicatorにＩＳＯ６４６に既定の方式で符号化された４文字の文字列"IDEX"が記述され、次に続くデータ種類が「IndexExtensionData」であることが示される。
フィールド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の直後からブロックblkTableOfPlayList()の最後のバイトまでのデータ長をバイト数で示す。フィールド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"とされる。
次に、クリップインフォメーションファイル"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で示される回数だけ繰り返される。
図２６は、クリップインフォメーションファイルにおけるブロックblkMakersPrivateData()の一例の構造を表すシンタクスを示す。ブロックblkMakersPrivateData()は、このクリップインフォメーションファイルに関して、メーカ独自の情報が記述されるブロックである。フィールドLengthは、３２ビットのデータ長を有し、このフィールドLength直後からこのブロックblkMakersPrivateData()の終わりまでのデータ長を示す。このフィールドLengthは、値"０"でこのMakersPrivateData()に情報が記述されていないことを示す。フィールドLengthが値"０"以外で、if文以下の記述がなされる。
ブロックDataBlock()StartAddressは、３２ビットのデータ長を有し、このシンタクス中の、メーカ独自情報本体が格納されるブロック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()内のブロックblkClipInfoExt()およびブロックblkProgramInfoExt()は、この発明と関連性が薄いので、説明を省略する。
１−４．仮想プレーヤについて
次に、仮想プレーヤについて、概略的に説明する。上述したようなデータ構造を有するディスクがプレーヤに装填されると、プレーヤは、ディスクから読み出されたムービーオブジェクトなどに記述されたコマンドを、プレーヤ内部のハードウェアを制御するための固有のコマンドに変換する必要がある。プレーヤは、このような変換を行うためのソフトウェアを、プレーヤに内蔵されるＲＯＭ(Read Only Memory)に予め記憶している。このソフトウェアは、ディスクとプレーヤを仲介してプレーヤにＡＶＣＨＤフォーマットの規定に従った動作をさせることから、仮想プレーヤと称される。
図２７は、この仮想プレーヤの動作を概略的に示す。図２７Ａは、ディスクのローディング時の動作の例を示す。ディスクがプレーヤに装填されディスクに対するイニシャルアクセスがなされると（ステップＳ３０）、１のディスクにおいて共有的に用いられる共有パラメータが記憶されるレジスタが初期化される（ステップＳ３１）。そして、次のステップＳ３２で、ムービーオブジェクトなどに記述されたプログラムがディスクから読み込まれて実行される。なお、イニシャルアクセスは、ディスク装填時のように、ディスクの再生が初めて行われることをいう。
図２７Ｂは、プレーヤが停止状態からユーザにより例えばプレイキーが押下され再生が指示された場合の動作の例を示す。最初の停止状態（ステップＳ４０）に対して、ユーザにより、例えばリモートコントロールコマンダなどを用いて再生が指示される（ＵＯ：User Operation）。再生が指示されると、先ず、レジスタすなわち共通パラメータが初期化され（ステップＳ４１）、次のステップＳ４２で、ムービーオブジェクト実行フェイズに移行する。
ムービーオブジェクトの実行フェイズにおけるプレイリストの再生について、図２８を用いて説明する。ＵＯなどにより、タイトル番号＃１のコンテンツを再生開始する指示があった場合について考える。プレーヤは、コンテンツの再生開始指示に応じて、上述した図２に示されるインデックステーブル(Index Table)を参照し、タイトル＃１のコンテンツ再生に対応するオブジェクトの番号を取得する。例えばタイトル＃１のコンテンツ再生を実現するオブジェクトの番号が＃１であったとすると、プレーヤは、ムービーオブジェクト＃１の実行を開始する。
この図２８の例では、ムービーオブジェクト＃１に記述されたプログラムは２行からなり、１行目のコマンドが"Play PlayList(1)"であるとすると、プレーヤは、プレイリスト＃１の再生を開始する。プレイリスト＃１は、１以上のプレイアイテムから構成され、プレイアイテムが順次再生される。プレイリスト＃１中のプレイアイテムの再生が終了すると、ムービーオブジェクト＃１の実行に戻り、２行目のコマンドが実行される。図２８の例では、２行目のコマンドが"jump MenuTitle"であって、このコマンドが実行されインデックステーブルに記述されたメニュータイトル(MenuTitle)を実現するムービーオブジェクトの実行が開始される。
２．発明に適用可能な記録装置について
次に、この発明に適用可能な記録装置について説明する。図２９は、この発明に適用可能な記録再生装置１の一例の構成を示す。この記録再生装置１は、入力されたディジタルビデオデータおよびディジタルオーディオデータを、所定の方式で圧縮符号化および多重化したＡＶストリームを記録媒体に記録するようにしている。
記録再生装置１に適用可能な圧縮符号化や多重化の方式としては、様々に考えられる。例えば、Ｈ．２６４｜ＡＶＣに規定される方式を、この発明の実施の一形態の圧縮符号化として適用することができる。これに限らず、ＭＰＥＧ２方式に基づき圧縮符号化を行うようにしてもよい。また、多重化方式は、例えばＭＰＥＧ２システムズを適用することができる。以下では、ビデオデータの圧縮符号化をＨ．２６４｜ＡＶＣに規定される方式に準じて行い、ビデオデータおよびオーディオデータの多重化を、ＭＰＥＧ２システムズに規定される方式に準じて行うものとして説明する。
なお、この図２９に例示される記録再生装置１は、外部から入力されるビデオデータおよびオーディオデータを記録媒体に記録する、単独の記録装置として用いることもできるし、光学系や撮像素子などを備えたカメラブロックと組み合わせ、撮像した撮像信号に基づくビデオデータを記録媒体に記録する、ビデオカメラ装置の記録ブロックとして用いることもできる。
記録再生装置１は、端子３０から入力されたビデオデータおよびオーディオデータを、記録可能なタイプの光ディスクのような記録媒体に所定に記録し、また、記録媒体に記録されたビデオデータおよびオーディオデータを所定に再生し、端子３１から出力する。記録再生装置１は、入力されたビデオデータおよびオーディオデータの記録媒体への記録、ならびに、記録媒体に記録されたビデオデータおよびオーディオデータの再生を行う記録再生部２０と、この記録再生装置１の全体を制御する制御部１０とを有する。制御部１０には、ユーザがこの記録再生装置１を操作するための操作子などが設けられるＵＩ(User Interface)部１７が接続される。
制御部１０は、ＣＰＵ(Central Processing Unit)１２、ＲＡＭ(Random Access Memory)１３、ＲＯＭ(Read Only Memory)１４、入出力インターフェイス（入出力Ｉ／Ｆ）１５および表示制御部１６とがバス１１に接続されてなる。ＣＰＵ１２は、ＲＯＭ１４に予め記憶されたプログラムに従い、ＲＡＭ１３をワークメモリとして用いてこの記録再生装置１の全体を制御する。
入出力Ｉ／Ｆ１５は、外部とのデータのやりとりを制御する。例えば、入出力Ｉ／Ｆ１５を介して外部からプログラムデータを供給し、供給されたプログラムデータによりＲＯＭ１４に記憶されるプログラムを更新することができる。表示制御部１６は、例えばＣＰＵ１２で生成された表示制御信号を、図示されない表示デバイスに表示可能な信号に変換する。
ＵＩ(User Interface)部１７は、この記録再生装置１の動作をユーザが操作するための操作子が所定に設けられ、操作子に対する操作に応じた制御信号を出力する。ＣＰＵ１２は、ユーザ操作に応じてＵＩ部１７から供給された制御信号に基づきなされるプログラムの処理により、この記録再生装置１の各部の動作を制御する。例えば、ＵＩ部１７に対してなされた操作に応じて、記録再生装置１による記録動作の開始および停止の動作がＣＰＵ１２により制御される。また、後述するドライブ装置２５に対する光ディスク５０の装填動作、ならびに、ドライブ装置２５に装填された光ディスク５０の排出動作も、ＵＩ部１７に対する操作に応じてＣＰＵ１２により制御される。
記録再生部２０は、ＡＶ入出力制御部２１、エンコーダ／デコーダ（ＥＮＣ／ＤＥＣ）部２２、ストリームバッファ２３とおよびリード／ライト制御部２４、ならびに、リード／ライト制御部２４に接続されるドライブ装置２５および内蔵記録媒体５１を有する。
ＡＶ入出力制御部２１は、例えばバッファメモリを有し、制御部１０の制御に基づき、端子３０からのビデオデータおよびオーディオデータの入力や、端子３１に対するビデオデータおよびオーディオデータの出力を制御する。なお、繁雑さを避けるため図２９では省略されているが、実際には、ビデオデータおよびオーディオデータは、それぞれ別の経路で以て入出力および伝送される。
ＥＮＣ／ＤＥＣ部２２は、入力されたベースバンドのビデオデータおよびオーディオデータの符号化を行う。また、ＥＮＣ／ＤＥＣ部２２は、記録媒体から再生されたデータを復号し、ベースバンドのビデオデータおよびオーディオデータを出力する。ＥＮＣ／ＤＥＣ部２２における符号化処理および復号化処理の開始および停止は、制御部１０により制御することができる。また、ＥＮＣ／ＤＥＣ部２２は、圧縮符号化されたビデオデータおよびオーディオデータを多重化してＡＶストリームデータとして出力する機能や、ビデオデータおよびオーディオデータが多重化されたＡＶストリームから、これらビデオデータおよびオーディオデータを分離する機能を有する。
リード／ライト制御部２４は、例えば記録可能なタイプの光ディスク５０に対応するドライブ装置２５と、例えばハードディスクからなる内蔵記録媒体５１とが接続される。内蔵記録媒体５１は、ハードディスクに限らず、例えばフラッシュメモリといった不揮発性の半導体メモリを用いることもできる。また、内蔵記録媒体５１は、記録再生装置１に対して固定的に用いられるようにされていれば、記録再生装置１に予め内蔵されていなくてもよい。リード／ライト制御部２４は、制御部１０からの命令に基づき、ドライブ装置２５に装填された光ディスク５０と、内蔵記録媒体５１とのうち選択された側へのデータの書き込みや、同じく選択された側からのデータの読み出しを制御する。
ストリームバッファ２３は、ＥＮＣ／ＤＥＣ部２２とリード／ライト制御部２４との間にあって、リード／ライト制御部２４による記録媒体５１または光ディスク５１におけるデータの書き込みおよび読み出しの際の転送速度と、ＥＮＣ／ＤＥＣ部２２における処理速度との差を吸収する。
このような構成における記録時の動作について、概略的に説明する。なお、ここでは、ビデオデータおよびオーディオデータを、ドライブ装置２５に装填された光ディスク５０に記録するものとして説明する。
記録時には、ベースバンドのビデオデータおよびオーディオデータが端子３０から入力され、ＡＶ入出力制御部２１を介してＥＮＣ／ＤＥＣ部２２に供給される。ＥＮＣ／ＤＥＣ部２２は、供給されたビデオデータおよびオーディオデータを所定の方式で以て圧縮符号化する。この例では、ビデオデータの圧縮符号化をＨ．２６４｜ＡＶＣに規定される方式に準じて行うようにされ、例えば、ＤＣＴ(Discrete Cosine Transform)と画面内予測とによりフレーム内圧縮を行うと共に、動きベクトルを用いたフレーム間圧縮を行い、さらにエントリピー符号化を行い圧縮効率を高める。オーディオデータは、例えばＡＣ３(Audio Code number 3)により圧縮符号化される。オーディオデータの圧縮符号化方式は、ＡＣ３に限られるものではない。オーディオデータを圧縮符号化せず、ベースバンドのデータのまま用いることも考えられる。
ＥＮＣ／ＤＥＣ部２２は、それぞれ所定に圧縮符号化されたビデオデータおよびオーディオデータを所定の方式で多重化し、１本のデータストリームとして出力する。ＭＰＥＧ２システムズに準じて多重化が行われるこの例では、ＭＰＥＧ２のトランスポートストリームを用いて、供給された圧縮ビデオデータおよび圧縮オーディオデータを時分割で多重化する。
例えば、ＥＮＣ／ＤＥＣ部２２は、バッファメモリを有し、それぞれ圧縮符号化されたビデオデータおよびオーディオデータをバッファメモリに溜め込む。バッファメモリに溜め込まれた圧縮ビデオデータは、所定サイズ毎に分割されヘッダが付加されて、ＰＥＳ(Packetized Elementary Stream)パケット化される。圧縮オーディオデータも同様に、所定サイズ毎に分割されヘッダが付加されてＰＥＳパケット化される。ヘッダには、パケットに格納されるデータの再生時刻を示すＰＴＳ(Presentation Time Stamp)や復号時刻を示すＤＴＳ(Decoding Time Stanp)といった、ＭＰＥＧ２システムズに規定される所定の情報が格納される。ＰＥＳパケットは、さらに分割されてトランスポートパケット（ＴＳパケット）のペイロードに詰め込まれる。ＴＳパケットのヘッダには、ペイロードに詰め込まれたデータを識別するためのＰＩＤ(Packet Identification)が格納される。ＥＮＣ／ＤＥＣ部２２から出力されたＴＳパケットは、ストリームバッファ２３に一旦溜め込まれる。
なお、ＴＳパケットは、実際には、さらに所定のヘッダが付加されてＥＮＣ／ＤＥＣ部２２から出力される。この、ＴＳパケットに対して所定のヘッダを付加したパケットを、ソースパケットと呼ぶ。
ストリームバッファ２３に溜め込まれたデータ量は、ＣＰＵ１２に監視される。ＣＰＵ１２は、ストリームバッファ２３に所定量以上のデータが溜め込まれたことを検出すると、リード／ライト制御部２４に対して、ストリームバッファ２３から光ディスク５０の記録単位分のデータを読み出して、光ディスク５０に書き込むように命令を出す。これに限らず、リード／ライト制御部２４がストリームバッファ２３に溜め込まれたデータ量を監視するようにしてもよい。
また、ＣＰＵ１２は、記録データに基づき、ＲＡＭ１３を用いて上述したインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に格納するための情報を生成する。生成された情報は、所定のタイミングで光ディスク５０に書き込まれる。
一例として、ＣＰＵ１２は、ＥＮＣ／ＤＥＣ部２２から記録データの時間情報を取得すると共に、リード／ライト制御部２４から記録データの光ディスク５０に対するアドレス情報を取得し、取得されたこれら時間情報およびアドレス情報に基づきＥＰエントリ情報が生成される。また、ＵＩ部１７に対する記録開始、記録終了の操作に応じてＣＰＵ１２から出力される制御信号と、ＥＮＣ／ＤＥＣ部２２およびリード／ライト制御部２４からの記録データに関する情報とに基づき、クリップインフォメーションファイル"zzzzz.clpi"の生成が行われると共に、生成されたクリップインフォメーションファイルの情報がプレイリストファイルに追記され、プレイリストファイル"xxxxx.mpls"の更新が行われる。さらに、光ディスク５０に対して新規に記録が行われる際には、インデックスファイル"index.bdmv"やムービーオブジェクトファイル"MovieObject.bdmv"の生成または更新が行われる。
再生時には、光ディスク５０が記録再生装置１のドライブ装置２５に装填されると、光ディスク５０から、インデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"が読み込まれ、ＣＰＵ１２に渡される。ＣＰＵ１２は、これらの情報をＲＡＭ１３に記憶させ、例えば、クリップに関する情報を表示させる表示制御信号を生成して表示制御部１６に供給し、図示されない表示デバイスに対して当該情報を表示させる。ユーザは、この情報に基づきＵＩ部１６に対して所定の操作を行うことで、光ディスク５０に記録されているクリップの再生を指示することができる。なお、ここでは、簡単のために、クリップの先頭から再生を開始させるものとする。
ＣＰＵ１２は、ＵＩ部１６に対する操作に応じて、ＲＡＭ１３からプレイリストファイルの情報を読み出し、このプレイリストファイルに基づき、リード／ライト制御部２４に対して、当該プレイリストファイルに格納されるプレイアイテムに参照されるクリップインフォメーションファイルと、対応するクリップＡＶストリームファイルを光ディスク５０から読み出すように命令を出す。リード／ライト制御部２４は、この命令に従い、光ディスク５０からクリップインフォメーションファイルとクリップＡＶストリームファイルとを読み出す。クリップＡＶストリームファイルは、光ディスク５０からＴＳパケット毎に読み出され、リード／ライト制御部２４を介してストリームバッファ２３に溜め込まれる。
なお、上述もしたように、実際には、光ディスク５０から読み出されるＴＳパケットは、本来のＴＳパケットに対して所定サイズのヘッダが付加されたソースパケットである。
ＣＰＵ１２は、ストリームバッファ２３に溜め込まれたデータのデータ量を監視し、ストリームバッファ２３に所定量以上のＴＳパケットが溜め込まれると、復号に必要とする分のデータをストリームバッファ２３からＴＳパケット単位で読み出し、ＥＮＣ／ＤＥＣ部２２に供給する。ＥＮＣ／ＤＥＣ部２２がストリームバッファ２３に溜め込まれたデータ量を監視するようにしてもよい。
ＴＳパケットは、ＥＮＣ／ＤＥＣ部２２が有するバッファメモリに一旦格納され、ＰＩＤに基づきデータ種類毎に振り分けられペイロードに格納されたデータからＰＥＳパケットが再構築される。さらに、ＰＥＳパケットのぺーロードからデータが取り出されると共に、ＰＥＳヘッダの情報に基づき、ＤＴＳやＰＴＳといったデコードや再生の時刻を指定する情報など、所定にヘッダ情報などが付加され、圧縮符号化されたビデオデータおよびオーディオデータのエレメンタリストリームがそれぞれ生成される。
ＥＮＣ／ＤＥＣ部２２は、圧縮ビデオデータをバッファメモリに溜め込み、所定ピクチャ分のデータが溜め込まれたら当該データに対して復号処理を開始する。復号されたビデオデータは、例えば図示されないシステムクロックから供給されるＳＴＣ(System Time Clock)に基づき、ＰＴＳに従いフレームタイミングで順次出力される。
ＥＮＣ／ＤＥＣ部２２は、圧縮オーディオデータに対しても、所定に復号処理を施す。復号されたオーディオデータは、復号されたビデオデータと同期的にＥＮＣ／ＤＥＣ部２２から出力され、ＡＶ入出力制御部２１を介して端子３１に導出される。オーディオデータとビデオデータとの同期処理をＡＶ入出力制御部２１で行ってもよい。
３．発明に適用可能なデータ構造について
図３０は、この発明に適用可能な一例のデータ構造を示す。インデックスファイル"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"が再生される。
４．実施の第１の形態について
次に、この発明の実施の第１の形態について説明する。この発明の実施の第１の形態では、連続して供給される記録データであるストリームデータを光ディスクに記録する際に、光ディスクの交換操作や、交換時のディスクの認識処理および初期化処理の間など、一時的に光ディスクに対する記録が行えない場合に、その間のストリームデータを記録装置に内蔵の記録媒体に一旦記録する。そして、後に光ディスクに記録可能となった際に、内蔵記録媒体に記録されたストリームデータを光ディスクに書き込むようにする。これによれば、時間的に連続した、１枚の光ディスクの記録容量を超えたデータ容量のストリームデータを、時間的に連続的な状態で複数の光ディスクに跨って記録させることができる。
なお、以下では、ストリームデータを一時的に光ディスクに記録できない場合に、当該ストリームデータを記録装置に内蔵の記録媒体に記録することを、「ストリームデータを内蔵の記録媒体に退避する」と呼び、内蔵の記録媒体に退避されるストリームデータを「退避データ」と呼ぶ。
４−１．実施の第１の形態による記録制御について
図３１を用いて、この実施の第１の形態による記録制御を概略的に説明する。図３１Ａに例示されるように、連続的に供給される、例えばビデオデータおよびオーディオデータからなるストリームデータを複数の光ディスク５０Ａ、５０Ｂ、・・・に亘って記録する場合について考える。記録再生装置１には、当初、光ディスク５０Ａが装填され、この光ディスク５０Ａに対してストリームデータの記録がなされている（図３１Ｂ参照）。例えば、時点Ａで光ディスク５０Ａに対して記録されるストリームデータのデータ量が光ディスク５０Ａの記録可能容量の上限に達し、記録が継続されたまま、ユーザにより光ディスク５０Ａが排出され新規に光ディスク５０Ｂが記録再生装置１に装填される。
ユーザが光ディスク５０Ａを排出し光ディスク５０Ｂを装填する動作を行うには、所定の時間を必要とし、この動作中は光ディスク５０Ａ、５０Ｂに対するストリームデータの記録を実行することができない。また、光ディスク５０Ｂが装填された直後は、記録再生装置１において光ディスク５０Ｂの認識処理および初期化処理が行われ、この処理中も、光ディスク５０Ｂに対するストリームデータの記録を行うことができない。
そこで、この実施の第１の形態では、光ディスク５０Ａから光ディスク５０Ｂへ交換する際の、ストリームデータを光ディスク５０Ａ、５０Ｂに記録できない期間に、ストリームデータの記録先を光ディスクから記録再生装置１に内蔵される内蔵記録媒体５１に切り替える。そして、光ディスクの交換時における光ディスクに対するデータ記録不可期間に供給されたストリームデータを、この内蔵記録媒体５１に書き込み、当該ストリームデータを内蔵記録媒体５１に退避させる（図３１Ｃ参照）。
新たに装填された光ディスク５０Ｂに対する認識処理や初期化処理が終了し、当該光ディスク５０Ｂに対するストリームデータの記録が可能となると、ストリームデータの記録先を内蔵記録媒体５１から光ディスク５０Ｂに切り替え、内蔵記録媒体５１に退避されたストリームデータすなわち退避データを光ディスク５０Ｂにコピーし、次いで新たに供給されたストリームデータを光ディスク５０Ｂに記録する（図３１Ｄ参照）。
新たに装填された光ディスク５０Ｂに対して記録されたストリームデータのデータ量が光ディスク５０Ｂの記録可能容量の上限に達した際の制御も、同様である。すなわち、光ディスク５０Ｂに対して例えば排出操作がなされると、ストリームデータの記録先が光ディスク５０Ｂから内蔵記録媒体５１に切り替えられ、供給されるストリームデータが内蔵記録媒体５１に退避される（図３１Ｅ）。新たに装填された光ディスク５０Ｃに対して認識処理や初期化処理がなされ、これらの処理が終了して当該光ディスク５０Ｃへのストリームデータの記録が可能な状態とされると、内蔵記録媒体５１に退避された退避データが光ディスク５０Ｃにコピーされ、次いで新たに供給されたストリームデータを光ディスク５０Ｃに記録する（図３１Ｆ）。
光ディスクの交換時におけるストリームデータの記録制御をこのように行うことで、連続的に供給されたＡＶデータを、複数枚の光ディスク５０Ａ、５０Ｂ、・・・に対し、時間的に連続的な状態で記録することができる。
図３２は、光ディスク５０の交換処理における光ディスク５０Ａ、５０Ｂおよび内蔵記録媒体５１に対するデータ書き込みの一例のタイミングを示す。図３２Ａは、ストリームバッファ２３に溜め込まれたデータ量（ストリームバッファ畜量と呼ぶ）の一例の変化を示す。上述したように、ストリームバッファ２３に対して所定量Ｄth以上のストリームデータが溜め込まれると、ストリームバッファ２３から光ディスク５０の記録単位分のストリームデータが読み出される。ここでは、ストリームバッファ２３には、略一定のデータレートで連続的にストリームデータが供給され続けるものとする。
当初、ドライブ装置２５には光ディスク５０Ａが装填され、ストリームバッファ２３から読み出されたストリームデータは、この光ディスク５０Ａに書き込まれる。光ディスク５０Ａに対するストリームデータの書き込みは、図３２Ｂに例示されるように、ストリームバッファ２３のデータ畜量に応じて間欠的に行われる。すなわち、ストリームバッファ２３に所定量Ｄth以上のストリームデータが溜め込まれると、ストリームバッファ２３から光ディスク５０Ａの記録単位分のストリームデータが読み出されて光ディスク５０Ａに書き込まれ、再びストリームバッファ２３に所定量Ｄth以上のストリームデータが溜め込まれると、同様にしてストリームバッファ２３から記録単位分のストリームデータが読み出されて光ディスク５０Ａに対して書き込まれる。
ここで、図３２Ａに時点Ａで示されるタイミングで、光ディスク５０Ａに対するイジェクト操作が行われた場合について考える。例えば、ＵＩ部１７に所定に設けられたイジェクトボタンがユーザにより操作され、イジェクトボタンが操作されたことを示す制御信号がＵＩ部１７からＣＰＵ１２に対して供給される。ＣＰＵ１２は、この制御信号に応じて、光ディスク５０Ａを排出させるために記録再生装置１の各部を制御する。
先ず、ＣＰＵ１２は、時点Ａにおいてストリームバッファ２３に溜め込まれているデータを所定に読み出し、リード／ライト制御部２４に供給する。リード／ライト制御部２４は、供給されたデータを光ディスク５０Ａに書き込む（図３２Ｂ参照）。ストリームバッファ２３中のストリームデータの光ディスク５０Ａに対する書き込みが完了したら、ＣＰＵ１２は、ＲＡＭ１３上に生成された管理情報、すなわちインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"に格納するための情報をリード／ライト制御部２４に供給し、それぞれファイルとして光ディスク５０Ａに書き込む（図３２Ｂの期間ｇ参照）。光ディスク５０Ａに対する管理情報の書き込みが完了すると、光ディスク５０Ａがドライブ装置２５から取り出し可能な状態となる。
光ディスク５０Ａがドライブ装置２５から取り出され、次の光ディスク５０Ｂがドライブ装置２５に新規に装填される。光ディスク５０Ｂがドライブ装置２５に装填されると、例えばドライブ装置２５により光ディスク５０Ｂの所定領域の情報が読み出され、読み出された情報に基づきＣＰＵ１２により光ディスク５０Ｂの認識処理が行われる（図３２Ｄの期間ｉ参照）。光ディスク５０Ｂの認識処理が完了すると、必要ならば、次に光ディスク５０Ｂの初期化処理が行われる（図３２Ｄの期間ｊ参照）。
この、ディスク交換および認証処理を行う期間ｉおよびディスクに対して初期化処理を行う期間ｊは、光ディスク５０Ｂに対してストリームデータを記録することができない。また、上述の、光ディスク５０Ａに対して管理情報を書き込んでいる期間ｇも、同様に、光ディスク５０Ａに対してストリームデータを記録することができない。一方、ストリームバッファ２３には、これら期間ｇ、期間ｉおよび期間ｊにも、ストリームデータが継続的に供給され蓄積される。
そこで、これら期間ｇ、期間ｉおよび期間ｊの間は、ストリームバッファ２３に溜め込まれたストリームデータを、内蔵記録媒体５１に退避させる処理が行われる。より具体的には、例えばリード／ライト制御部２４は、ストリームデータを記録する記録先をドライブ装置２５から内蔵記録媒体５１に切り替える。例えば、図３２Ｃに例示されるように、光ディスク５０Ａに対して管理情報を書き込んでいる期間ｇや、光ディスク５０Ａを排出し、次の光ディスク５０Ｂをドライブ装置２５に装填するまでの期間やドライブ装置２５に装填された光ディスク５０Ｂに対する認識処理および初期化処理を行っている期間ｉおよび期間ｊにおいて、ストリームバッファ２３のデータ畜量が所定量Ｄth以上となったら、ストリームバッファ２３から例えば光ディスク５０の記録単位分のストリームデータを読み出し、読み出されたストリームデータを内蔵記録媒体５１に記録し、ストリームデータの内蔵記録媒体５１への退避を行う（図３２Ｃの期間ｈ参照）。
新規に装填された光ディスク５０Ｂの認識処理および初期化が完了し、当該光ディスク５０Ｂに対してストリームバッファ２３から読み出したストリームデータの書き込みが可能な状態となると、先ず、内蔵記録媒体５１から上述の期間ｈ、期間ｉおよび期間ｊにおいて書き込まれたストリームデータすなわち退避データを内蔵記録媒体５１から読み出し、光ディスク５０Ｂに対して書き込む（図３２Ｄの期間ｋ参照）。このとき、内蔵記録媒体５１から、光ディスク５０の記録単位分毎に連続的に退避データが読み出され、光ディスク５０Ｂに書き込まれる。
ここで、内蔵記録媒体５１から退避データを読み出して光ディスク５０Ｂに書き込んでいる間にも、ストリームバッファ２３には、ＥＮＣ／ＤＥＣ部２２から出力されたストリームデータが継続的に溜め込まれることになる。ＣＰＵ１２は、ストリームバッファ２３のデータ畜量と内蔵記録媒体５１に書き込まれている退避データとを監視し、ストリームバッファ２３に対して所定量Ｄthのストリームデータが溜め込まれた時点で、内蔵記録媒体５１に、光ディスク５０Ｂに未だ書き込んでいない退避データが存在するか否かを判断する。
光ディスク５０Ｂに未だ書き込んでいない退避データが内蔵記録媒体５１内に存在すると判断された場合には、ストリームバッファ２３から記録単位分が読み出されたストリームデータが内蔵記録媒体５１に書き込まれ退避されると共に、内蔵記録媒体５１中に存在する、光ディスク５０Ｂに未だ書き込んでいない退避データを光ディスク５０Ｂに書き込む。一方、光ディスク５０Ｂに未だ書き込んでいない退避データが内蔵記録媒体５１内に存在しないと判断された場合には、ストリームバッファ２３からから記録単位分が読み出されたストリームデータを、光ディスク５０Ｂに書き込む。そして、これ以降は、ストリームバッファ２３から読み出されたストリームデータは、光ディスク５０Ｂに書き込まれる。
図３３は、光ディスク交換時の一例の記録制御を示す。この図３３の各処理は、主にＣＰＵ１２により制御される。先に書き込みを行っていた光ディスク５０Ａが排出され、次に光ディスク５０Ｂが装填されると、ＣＰＵ１２により、この光ディスク５０Ｂがストリームデータの書き込み可能な状態となっているか否かが判断される（ステップＳ５０）。
若し、例えば光ディスク５０Ｂに対する認識処理や初期化処理が未だ完了しておらず、当該光ディスク５０Ｂが書き込み可能な状態となっていないとステップＳ５０で判断されれば、処理はステップＳ５１に移行され、ストリームバッファ２３に所定量Ｄthのストリームデータが溜め込まれたか否かが判断される。溜め込まれていないと判断されれば、処理はステップＳ５０に戻され、溜め込まれたと判断されれば、ストリームバッファ２３から記録単位分のデータを読み出し、読み出されたデータを内蔵記録媒体５１に書き込み、ストリームデータを退避させる（ステップＳ５２）。そして、処理がステップＳ５０に戻される。
ステップＳ５０で、新規に装填された光ディスク５０Ｂがストリームデータの書き込み可能な状態となったと判断されれば、処理はステップＳ５３に移行される。ステップＳ５３では、内蔵記録媒体５１内に、光ディスク５０Ｂに書き込むべきストリームデータすなわち退避データが存在するか否かが判断される。若し、存在すると判断されれば、処理はステップＳ５４に移行され、ストリームバッファ２３に所定量Ｄth以上のストリームデータが溜め込まれたか否かが判断される。
若し、ステップＳ５４で、所定量Ｄth以上のストリームデータがストリームバッファ２３に溜め込まれていると判断されれば、処理はステップＳ５５に移行される。ステップＳ５５では、ストリームバッファ２３から記録単位分のストリームデータを読み出し、読み出した当該ストリームデータを内蔵記録媒体５１に書き込む。記録単位分のストリームデータが内蔵記録媒体５１に書き込まれ、ストリームデータが内蔵記録媒体５１に退避されると、処理はステップＳ５３に戻される。
一方、ステップＳ５４で、所定量Ｄth以上のストリームデータがストリームバッファ２３に溜め込まれていないと判断されれば、処理はステップＳ５６に移行される。ステップＳ５６では、内蔵記録媒体５１に書き込まれている記録単位分の退避データが光ディスク５０Ｂに書き込まれる。記録単位分の退避データが光ディスク５０Ｂに書き込まれると、処理はステップＳ５３に戻される。
若し、ステップＳ５３で、内蔵記録媒体５１内に、光ディスク５０Ｂに書き込むべき退避データが存在しないと判断されれば、処理はステップＳ５７に移行される。そして、ストリームバッファ２３に溜め込まれたストリームデータが光ディスク５０Ｂに書き込まれる。すなわち、ステップＳ５７では、ストリームバッファ２３に所定量Ｄth以上のストリームデータが溜め込まれる毎に、記録単位分のストリームデータを光ディスク５０Ｂに書き込む、通常の光ディスクに対する間欠的な書き込み処理に移行される。
なお、上述では、光ディスク５０Ａから光ディスク５０Ｂへの交換に伴い内蔵記録媒体５１に書き込まれた退避データを、交換後の光ディスク５０Ｂが書き込み可能となったタイミングで当該光ディスク５０Ｂに書き込むようにしているが、これはこの例に限定されない。
例えば、ストリームデータの記録動作の停止後に、内蔵記録媒体５１に書き込まれた退避データを光ディスク５０Ｂに書き込むようにしてもよい。一例として、ユーザによりＵＩ部１７に対して記録停止の操作がなされた時点で、内蔵記録媒体５１に書き込まれた退避データを光ディスク５０Ｂに書き込むことが考えられる。これは、ユーザが光ディスクの交換に手間取り、内蔵記録媒体５１に書き込まれた退避データのデータ量が多くなりすぎた場合や、光ディスクに対する書き込み速度が遅い場合に、特に有効である。
またこの場合、光ディスク５０の書き込み速度、内蔵記録媒体５１の書き込み速度および読み出し速度、ストリームデータの記録ビットレート、光ディスク５０の交換時に内蔵記録媒体５１に書き込まれたデータ量などに基づき、内蔵記録媒体５１に書き込まれた退避データを、交換後の光ディスク５０Ｂが書き込み可能となったタイミングで当該光ディスク５０Ｂに書き込むか、ストリームデータの記録動作の停止後に、内蔵記録媒体５１に書き込まれた退避データを光ディスク５０に書き込むかを自動的に選択することも可能である。
なお、内蔵記録媒体５１に書き込まれた退避データを、ストリームデータの記録動作の停止後に記録する場合、内蔵記録媒体５１に書き込まれた当該データを交換後の光ディスク５０Ｂに書き込むことを前提として、光ディスク５０Ｂの記録可能容量などを確認する必要がある。
図３４は、内蔵記録媒体５１における退避データの一例の管理構造を示す。内蔵記録媒体５１に対して退避データを記録する際には、図６を用いて説明した、通常の記録時に内蔵記録媒体５１に対してストリームデータを記録する際の管理構造とは異なる管理構造でデータを格納する。より具体的な例として、図３４に例示されるように、ルートディレクトリの直下に置かれるディレクトリを例えばディレクトリ"AVCHD_TMP"として、図６に例示される、通常記録時のディレクトリ構造と異ならせる。これにより、例えば記録再生装置１における電源の瞬断などのような不測の事態においても、内蔵記録媒体５１に記録された退避データを即座に判別することができる。
また、退避データのディレクトリ構造において、ディレクトリ"BDMV"直下のファイル"INDEX.BDM"およびファイル"MOVIEOBJ.BDM"は、作成されない。同様に、ディレクトリ"PLAYLIST"下のプレイリストに関するファイルであるファイル"00000.MPL"も作成されない。また、クリップインフォメーションファイル"00000.CPI"は、省略することができる。
４−２．実施の第１の形態によるストリームデータファイルの結合処理について
次に、ストリームデータファイルの結合処理について説明する。連続的に生成され複数枚の光ディスク５０Ａ、５０Ｂ、・・・に亘って分割して記録したストリームデータファイルを、後に、より記録容量の大きな１の記録媒体に纏めて保存することが考えられる。この場合、この記録媒体を再生した際に、ユーザが意識することなく、これら複数のストリームファイルが時間的に連続した１のコンテンツとして再生できるようにオーサリングされることが望ましい。
そこで、この実施の第１の形態では、時間的に先行するクリップＡＶストリームファイルとの接続状態を管理するための接続状態管理情報を定義し、この接続状態管理情報をクリップＡＶストリームファイルに対応付けて、光ディスク５０に記録する。そして、複数枚の光ディスク５０Ａ、５０Ｂ、・・・に亘って分割して記録したストリームデータファイルに対する上述のオーサリングを行う際に、この接続状態管理情報に基づき、オーサリング対象の複数のストリームデータファイルが時間的に連続したコンテンツであって、且つ、未編集であるか否かを確認する。
接続状態管理情報に基づく確認の結果、オーサリング対象の複数のストリームデータファイルが時間的に連続したコンテンツ、且つ、未編集のコンテンツであるとされれば、チャプタを結合し、オーサリング対象の複数のストリームデータファイルを時間的に連続したコンテンツとして再生可能とする。
接続状態管理情報は、ＣＰＵ１２によりＲＡＭ１３上に生成され、例えば光ディスク５０の排出時や、光ディスク５０をドライブ装置２５に装填したまま記録再生装置１の電源をＯＦＦにした際に、管理情報、すなわちインデックスファイル"index.bdmv"、ムービーオブジェクトファイル"MovieObject.bdmv"、プレイリストファイル"xxxxx.mpls"およびクリップインフォメーションファイル"zzzzz.clpi"と共に、光ディスク５０に対して記録される。
４−２−１．接続状態管理情報について
図３５は、接続状態管理情報の一例の構造を示す。それぞれ３２ビットのデータ長で、データPRODUCT_SERIAL_NUMBER、データCONTENTS_SERIAL_NUMBER、データPRESENTATION_START_STC_ID、データPRESENTATION_START_TIME、データPRESENTATION_START_ENABLE_TIME、データPRESENTATION_END_STC_IDおよびデータPRESENTATION_END_TIMEが記述される。この接続状態管理情報の構造体は、例えば、図２６を用いて説明した、クリップインフォメーションファイルにおけるブロックblkMakersPrivateData()内の、ブロックDataBlock()に格納される。この接続状態管理情報は、対応するクリップＡＶストリームファイルの生成時におけるオリジナルの情報を保持する。
データPRODUCT_SERIAL_NUMBERは、対応するクリップＡＶストリームファイルを記録したセットの製造番号が記述される。データCONTENTS_SERIAL_NUMBERは、対応するクリップＡＶストリームファイルに対して付される連続番号が記述される。この連続番号は、例えば、記録再生装置１においてクリップＡＶストリームファイルが生成される毎に１ずつインクリメントされて生成され、十分大きな所定値でリセットするような値を用いることができる。以下では、データCONTENTS_SERIAL_NUMBERは、０から開始され、クリップＡＶストリームファイルの生成毎に１ずつインクリメントされ、所定の最大値Maximun_Numberでリセットされ再び０からインクリメントされるものとする。
データPRESENTATION_START_STC_IDおよびデータPRESENTATION_START_TIMEは、対応するクリップＡＶストリームファイルの表示を開始する時刻に対応する情報を、それぞれＳＴＣのＩＤおよびＰＴＳで示す。また、データPRESENTATION_START_ENABLE_TIMEは、対応するクリップＡＶストリームファイルを表示可能な時刻をＰＴＳで示す。また、データPRESENTATION_END_STC_IDおよびデータPRESENTATION_END_TIMEは、対応するクリップＡＶストリームファイルの表示が終了される時刻に対応する情報を、それぞれＳＴＣのＩＤおよびＰＴＳで示す。
４−２−１−１．圧縮符号化方式に関する概略的な説明
ここで、これらクリップＡＶストリームファイルの表示を開始する時刻および表示可能な時刻に関する理解を深めるために、この実施の第１の形態に適用可能なディジタルビデオデータの圧縮符号化方式であるＭＰＥＧ２およびＨ．２６４｜ＡＶＣにおける圧縮符号化処理について、概略的に説明する。これらＭＰＥＧ２およびＨ．２６４｜ＡＶＣにおいては、直交変換などを用いたフレーム内符号化を行うと共に、動き補償を用いた予測符号化によるフレーム間符号化をさらに行い、圧縮率を高めている。以下、ＭＰＥＧ２を例にとって、予測符号化によるフレーム間圧縮について説明する。
先ず、ＭＰＥＧ２のデータストリーム構造について、概略的に説明する。ＭＰＥＧ２は、動き補償予測符号化と、ＤＣＴによる圧縮符号化とを組み合わせたものである。ＭＰＥＧ２のデータ構造は、階層構造をなしており、下位から、ブロック層、マクロブロック層、スライス層、ピクチャ層、ＧＯＰ層およびシーケンス層となっている。ブロック層は、ＤＣＴを行う単位であるＤＣＴブロックからなる。マクロブロック層は、複数のＤＣＴブロックで構成される。スライス層は、ヘッダ部と、１以上のマクロブロックより構成される。ピクチャ層は、ヘッダ部と、１以上のスライスとから構成される。ピクチャは、１画面に対応する。各層の境界は、それぞれ所定の識別符号で識別可能なようになっている。
ＧＯＰ層は、ヘッダ部と、フレーム内符号化に基づくピクチャであるＩ(Intra-coded)ピクチャと、予測符号化に基づくピクチャであるＰ(Predictive-coded)ピクチャＢ(Bi-directionally predictive coded)ピクチャとから構成される。Ｉピクチャは、それ自身の情報のみでデコードが可能であり、ＰおよびＢピクチャは、基準画像として前あるいは前後の画像が必要とされ、単独ではデコードされない。例えばＰピクチャは、自身より時間的に前のＩピクチャまたはＰピクチャを基準画像として用いてデコードされる。また、Ｂピクチャは、自身の前後のＩピクチャまたはＰピクチャの２枚のピクチャを基準画像として用いてデコードされる。最低１枚のＩピクチャを含むそれ自身で完結したグループをＧＯＰ(Group Of Picture)と呼び、ＭＰＥＧのストリームにおいて独立してアクセス可能な最小の単位とされる。
ＧＯＰは、１または複数のピクチャから構成される。以下では、ＧＯＰは、複数のピクチャから構成されるものとする。ＧＯＰにおいて、ＧＯＰ内で完全にデコードが可能な、ＧＯＰで閉じた構造を持つクローズドＧＯＰと、デコードの際に符号化順で１つ前のＧＯＰの情報を用いることができるオープンＧＯＰとの２種類がある。オープンＧＯＰは、クローズドＧＯＰと比較して、より多くの情報を用いてデコードできるため高画質を得られ、一般的に用いられている。
図３６を用いて、フレーム間圧縮を行ったデータのデコード処理について説明する。ここでは、１ＧＯＰが１枚のＩピクチャ、４枚のＰピクチャおよび１０枚のＢピクチャの、計１５枚のピクチャから構成されるものとする。ＧＯＰ内のＩ、ＰおよびＢピクチャの表示順は、図３６Ａに一例が示されるように、「Ｂ0Ｂ1Ｉ2Ｂ3Ｂ4Ｐ5Ｂ6Ｂ7Ｐ8Ｂ9Ｂ10Ｐ11Ｂ12Ｂ13Ｐ14」のようになる。なお、添え字は表示順を示す。
この例では、最初の２枚のＢ0ピクチャおよびＢ1ピクチャは、１つ前のＧＯＰにおける最後尾のＰ14ピクチャと、このＧＯＰ内のＩ2ピクチャを用いて予測されデコードされたピクチャである。ＧＯＰ内の最初のＰ5ピクチャは、Ｉ2ピクチャから予測されデコードされたピクチャである。他のＰ8ピクチャ、Ｐ11ピクチャおよびＰ14は、それぞれ１つ前のＰピクチャを用いて予測されデコードされたピクチャである。また、Ｉピクチャ以降の各Ｂピクチャは、それぞれ前後のＩおよび／またはＰピクチャから予測されデコードされたピクチャである。
一方、Ｂピクチャは、時間的に前後のＩまたはＰピクチャを用いて予測されデコードされるため、ストリームや記録媒体上におけるＩ、ＰおよびＢピクチャの並び順は、デコーダにおけるデコードの順序を考慮して決める必要がある。すなわち、ＢピクチャをデコードするためのＩおよび／またはＰピクチャは、当該Ｂピクチャよりも常に先にデコードされていなければならない。
上述の例では、ストリームや記録媒体上の各ピクチャの配列は、図３６Ｂに例示されるように、「Ｉ2Ｂ0Ｂ1Ｐ5Ｂ3Ｂ4Ｐ8Ｂ6Ｂ7Ｐ11Ｂ9Ｂ10Ｐ14Ｂ12Ｂ13」のようになり、この順でデコーダに入力される。なお、添え字は、図３６Ａに対応し、表示順を示す。
デコーダにおけるデコード処理は、図３６Ｃに示されるように、先ずＩ2ピクチャをデコードし、デコードされたこのＩ2ピクチャと１つ前のＧＯＰにおける最後尾（表示順）のＰ14ピクチャとによりＢ0ピクチャおよびＢ1ピクチャを予測しデコードする。そして、Ｂ0ピクチャおよびＢ1ピクチャをデコードされた順にデコーダから出力し、次にＩ2ピクチャを出力する。Ｂ1ピクチャが出力されると、次にＰ5ピクチャがＩ2ピクチャを用いて予測されデコードされる。そして、Ｉ2ピクチャおよびＰ5ピクチャを用いてＢ3ピクチャおよびＢ4ピクチャが予測されデコードされる。そして、デコードされたＢ3ピクチャおよびＢ4ピクチャをデコードされた順にデコーダから出力し、次にＰ5ピクチャを出力する。
以下、同様にして、Ｂピクチャの予測に用いるＰまたはＩピクチャをＢピクチャより先にデコードし、このデコードされたＰまたはＩピクチャを用いてＢピクチャを予測してデコードし、デコードされたＢピクチャを出力してから、当該Ｂピクチャをデコードするために用いたＰまたはＩピクチャを出力する処理が繰り返される。記録媒体上やストリームにおける図３６Ｂのようなピクチャ配列は、一般的に用いられるものである。
４−２−１−２．ストリームの分割および結合について
この実施の第１の形態のように、時間的に連続するビデオストリームを複数の光ディスク５０Ａ、５０Ｂ、・・・に分割して記録するような場合に、光ディスク５０Ａ、５０Ｂ、・・・それぞれ単体でのビデオストリームの再生を可能とするためには、ビデオストリームの分割位置をＧＯＰ境界とする必要がある。例えば、図３７Ａに例示されるように、ＧＯＰ＃１、ＧＯＰ＃２の順にビデオストリームがＥＮＣ／ＤＥＣ部２２で生成されるとき、ＧＯＰ＃１とＧＯＰ＃２の境界位置Ａでビデオストリームを分割する。すなわち、境界位置Ａは、ストリーム上の位置では、ＧＯＰ＃１の最後尾のＢ13ピクチャと、ＧＯＰ＃２の先頭のＩ2ピクチャとの間、表示上の時刻では、ＧＯＰ＃１の最後に表示されるＰピクチャ14とＧＯＰ＃２の最初に表示されるＢ0ピクチャの間となる。
このようにして分割されたストリームを分割面で結合し、１のストリームとしてデコードする場合にについて考える。図３７Ｂに例示されるように、境界位置Ａに対して時間的に直前のＧＯＰ＃１は、ストリーム上の最後尾のＢ13ピクチャの末尾が分割面とされ、境界位置Ａに対して時間的に直後のＧＯＰ＃２は、ストリーム上の先頭のＩ2ピクチャの先頭が分割面とされる。したがって、これらＧＯＰ＃１およびＧＯＰ＃２を分割面で結合した場合、ＧＯＰ＃２の表示順で先頭および２番目となるＢ0ピクチャおよびＢ1ピクチャは、ＧＯＰ＃１のＰ14ピクチャと、ＧＯＰ＃１のＩ2ピクチャとを用いてデコードが可能である。これは、ＧＯＰ＃１とＧＯＰ＃２とがシームレス接続可能であることを意味する。
一方、分割されたストリームを単独でデコードする場合には、図３７Ｃに例示されるように、例えばＧＯＰ＃２がオープンＧＯＰであれば、表示順で先頭および２番目となるＢ0ピクチャおよびＢ1ピクチャは、先行する参照ピクチャであるＰ14ピクチャを用いることができないため、デコードできない。そのため、ＧＯＰ＃２は、Ｉ2ピクチャから表示が可能となり、Ｂ0ピクチャおよびＢ1ピクチャは、捨てられる。この場合、ＧＯＰ＃２は、例えば先行するＧＯＰ＃１に対してシームレス接続できない。
図３５の接続状態管理情報の説明に戻り、データPRESENTATION_START_TIMEは、より具体的には、ストリームを分割した境界位置に対して時間的に直後のＧＯＰにおける、表示順で先頭となるピクチャの表示開始時刻を示す。
図３７Ｂを用いて説明した、連続したＧＯＰ＃１とＧＯＰ＃２との境界位置Ａでストリームを分割した例では、ＧＯＰ＃１の最終ピクチャの直後にＧＯＰ＃２の先頭ピクチャが表示されることで、ＧＯＰ＃１とＧＯＰ＃２とがシームレスに接続される。すなわち、ＧＯＰ＃２は、表示順で先頭であるＢ0ピクチャから表示が開始される。したがって、境界位置Ａの直後のＧＯＰ＃２において、Ｂ0ピクチャに対して定義された表示開始時刻が、データPRESENTATION_START_TIMEによりＰＴＳで示される。また、データPRESENTATION_START_STC_IDは、表示開始されるＳＴＣシーケンスのＩＤ(stc_id)が示される。
一方、図３７Ｃを用いて説明した、単独でデコードされるストリームの例では、図３７Ｃに示すＧＯＰ＃２がオープンＧＯＰであれば、Ｉ2ピクチャから表示が開始されることになる。そこで、表示順で先頭とされるＩ2ピクチャに対して定義された表示開始時刻が、データPRESENTATION_START_TIMEによりＰＴＳで示される。また、データPRESENTATION_START_STC_IDは、表示開始されるＳＴＣシーケンスのＩＤ(stc_id)が示される。
このように、ストリームの構成がオープンＧＯＰとなっている場合、先行するストリームとシームレス接続するか否かで、表示開示時刻が異なる。
データPRESENTATION_END_TIMEは、より具体的には、ストリームを分割した境界位置に対して時間的に直前のＧＯＰにおける、表示順で最後尾となるピクチャの表示終了時刻を示す。図３７Ｂを用いて説明した、境界位置Ａの直前のＧＯＰ＃１を含むクリップＡＶストリームファイルの例では、ＧＯＰ＃１の表示順で最後のＰ14ピクチャに対して定義された表示終了時刻が、データPRESENTATION_END_TIMEによりＰＴＳで示される。また、データPRESENTATION_END_STC_IDは、表示終了されるＳＴＣシーケンスのＩＤ(stc_id)が示される。
データPRESENTATION_START_ENABLE_TIMEは、分割されたストリームの先頭のＧＯＰにおいて表示開始が可能となるピクチャに対して定義された表示開始時刻がＰＴＳで示される。ＧＯＰにおいて表示順で先頭となるＢ0ピクチャは、オープンＧＯＰであっても、先行するＧＯＰに対応する参照ピクチャであるＰ14ピクチャが存在すれば、当該Ｂ0ピクチャから表示開始可能となる。したがって、Ｂ0ピクチャに対して定義された表示開始時刻が、データPRESENTATION_START_ENABLE_TIMEによりＰＴＳで示される。
すなわち、図３７Ｂに例示されるストリームのうちＧＯＰ＃２側において、オープンＧＯＰであれば、先頭のＢ0ピクチャおよびＢ1ピクチャは、ＧＯＰ＃２を単独でデコードした場合には、先行する参照ピクチャである、直前のＧＯＰにおけるＰ14ピクチャが無いのでデコードできない。しかしながら、図３７ＢにＧＯＰ＃１として示されるように、これらＢ0ピクチャおよびＢ1ピクチャに対する、先行する参照ピクチャであるＰ14ピクチャが存在する場合には、これらＢ0ピクチャおよびＢ1ピクチャは、このＧＯＰ＃１のＰ14ピクチャと、ＧＯＰ＃２のＩ2ピクチャとを用いてデコード可能である。そのため、データPRESENTATION_START_ENABLE_TIMEとして、Ｂ0ピクチャに対して定義された表示開始時刻が用いられる。
４−２−２．オーサリング処理について
次に、複数の光ディスク５０Ａ、５０Ｂ、・・・に分割して記録されたクリップＡＶストリームファイルを、時間的に連続した１のコンテンツとして再生可能とするためのオーサリング処理について説明する。先ず、図３８および図３９を用いて、このオーサリング処理について概略的に説明する。
一例として、図３８に示されるように、光ディスク５０Ａには、リアルプレイリストファイル７０中のプレイアイテム７１Ａ、７１Ｂおよび７１Ｃにそれぞれ再生位置を指定されるクリップＡＶストリームファイル７２Ａ、７２Ｂおよび７２Ｃが記録されているものとする。これらクリップＡＶストリームファイル７２Ａ、７２Ｂおよび７２Ｃは、それぞれクリップインフォメーションファイル７３Ａ、７３Ｂおよび７３Ｃが対応付けられている。また、リアルプレイリストファイル７０において、プレイアイテム７１Ａ、７１Ｂおよび７１Ｃそれぞれに指定されるＩＮ点に対応する位置に、マーク＃０、＃１および＃２が打たれ、チャプタが定義されている。さらに、リアルプレイリストファイル７０は、インデックスファイル７４から参照されるムービーオブジェクトファイル７５から呼び出される。
同様に、光ディスク５０Ｂには、リアルプレイリストファイル７６中のプレイアイテム７７Ａおよび７７Ｂにそれぞれ再生位置を指定されるクリップＡＶストリームファイル７８Ａおよび７８Ｂが記録されているものとする。これらクリップＡＶストリームファイル７８Ａおよび７８Ｂは、それぞれクリップインフォメーションファイル７９Ａおよび７９Ｂが対応付けられている。また、リアルプレイリストファイル７６において、プレイアイテム７７Ａおよび７７Ｂそれぞれに指定されるＩＮ点に対応する位置に、マーク＃３および＃４が打たれ、チャプタが定義されている。さらに、リアルプレイリストファイル７６は、インデックスファイル８０から参照されるムービーオブジェクトファイル８１に呼び出される。
ここで、光ディスク５０Ａに記録されるクリップＡＶストリームファイル７２Ｃと、光ディスク５０Ｂに記録されるクリップインフォメーションファイル７７Ａとが、記録時に、連続的に供給されたストリームデータが分割されて生成されたファイルであるものとする。
すなわち、継続的に供給されるストリームデータの記録に際し、当初、記録再生装置１のドライブ装置２５に光ディスク５０Ａが装填され、当該ストリームデータがクリップＡＶストリームファイル７２Ｃとしてこの光ディスク５０Ａに記録される。そして、所定のタイミングで光ディスク５０Ａがドライブ装置２５から排出され、次の光ディスク５０Ｂがドライブ装置２５に装填される。既に説明したようにしてストリームデータの退避処理および退避データの光ディスク５０Ｂへの書き込みなどが所定に行われた後、ストリームデータがクリップＡＶストリームファイル７７Ａとして光ディスク５０Ｂに記録される。
これら光ディスク５０Ａおよび５０Ｂに記録されたクリップＡＶストリームファイル７２Ａ〜７２Ｃ、ならびに、７７Ａおよび７７Ｂを、図３９に例示されるように、記録容量の十分大きな記録媒体５２に纏めて記録する。このときに、記録時にストリームデータを分割して生成されたクリップＡＶストリームファイル７２ＣとクリップＡＶストリームファイル７８Ａとが、時間的に連続した１のコンテンツとして再生可能なようにオーサリングする。
なお、記録媒体５２は、例えば光ディスク５０Ａや光ディスク５０Ｂより十分容量の大きな他の光ディスクである。このオーサリング処理は、記録再生装置１により行ってもよいし、パーソナルコンピュータなど、光ディスク５０Ａ、５０Ｂが対応する他の機器を用いて行ってもよい。記録再生装置１を用いる場合は、光ディスク５０Ａおよび５０Ｂの記録内容を内蔵記録媒体５１にそれぞれコピーし、コピーされたデータを用いてオーサリング処理を行うことが考えられる。パーソナルコンピュータを用いる場合にも同様に、パーソナルコンピュータに内蔵または接続されるハードディスクに対して光ディスク５０Ａおよび５０Ｂの記録内容をそれぞれコピーする。パーソナルコンピュータに、光ディスク５０に対応したドライブ装置を複数設け、光ディスク５０Ａおよび５０Ｂと、光ディスクである記録媒体５２とをそれぞれドライブ装置に装填して処理を行うこともできる。
概略的なオーサリングの例としては、光ディスク５０Ａを基準とし、クリップＡＶストリームファイル７２Ａ〜７２Ｃが記録媒体５２にコピーされると共に、光ディスク５０Ｂ上のクリップＡＶストリームファイル７８Ａおよび７８Ｂが、それぞれファイル名が重複しないように所定に変更されて、記録媒体５２にコピーされる。同様に、光ディスク５０Ａ上のクリップインフォメーションファイル７３Ａ〜７３Ｃが記録媒体５２にコピーされる。また、光ディスク５０Ｂ上のクリップインフォメーションファイル７９Ａおよび７９Ｂに対し、それぞれファイル名が重複しないように所定に変更されると共に、対応するクリップＡＶストリームファイル７８Ａおよび７８Ｂのファイル名の変更が反映される。
クリップＡＶストリームファイル７２Ａ〜７２Ｃ、ならびに、クリップインフォメーションファイル７９Ａおよび７９Ｂをそれぞれ参照するプレイアイテム８３Ａ〜８３Ｅを含むリアルプレイリストファイル８２が生成され、記録媒体５２に記録される。また、リアルプレイリストファイル８２を呼び出すためのムービーオブジェクトファイル８４と、当該ムービーオブジェクトファイル８４を参照するインデックスファイル８５とが記録媒体５２に記録される。
リアルプレイリストファイル８２は、光ディスク５０Ａおよび５０Ｂに記録されているリアルプレイリストファイル７０および７６の設定を引き継いで生成することができる。例えば、リアルプレイリストファイル７０および７６それぞれに含まれるプレイアイテムの情報や、マーク情報（図１５参照）が、記録媒体５２上に生成されるリアルプレイリストファイル８２に対して引き継がれる。
リアルプレイリストファイル８２の生成時に、クリップＡＶストリームファイル７２Ｃに対応するクリップインフォメーションファイル７３Ｃと、クリップＡＶストリームファイル７８Ａに対応するクリップインフォメーションファイル７９Ａとにそれぞれ格納される接続状態管理情報に基づき、クリップＡＶストリームファイル７２ＣとクリップＡＶストリームファイル７８Ａとが時間的に連続したコンテンツであって、且つ、未編集であるか否かを確認する。
確認の結果、クリップＡＶストリームファイル７２ＣとクリップＡＶストリームファイル７８Ａとが時間的に連続したコンテンツであって、且つ、未編集であるとされた場合、クリップＡＶストリームファイル７２ＣとクリップＡＶストリームファイル７８Ａとが１のチャプタとして連続的に再生可能となるように、所定に処理がなされる。
すなわち、プレイアイテム８３Ｄにおいて、フィールドConnectionConditionの値が"６"とされ、クリップＡＶストリームファイル７２ＣとクリップＡＶストリームファイル７７Ａとの接続方法が、上述した第２のシームレス接続となるように設定される（図１３および図１４Ｂ参照）。
また、リアルプレイリストファイル８２において、クリップＡＶストリームファイル７８Ａの先頭に対応して打たれていたマークが削除される。すなわち、リアルプレイリストファイル８２に格納されるブロックblkPlayListMark()において（図１５参照）、クリップＡＶストリームファイル７８Ａに対してＩＮ点およびＯＵＴ点を指定するプレイアイテムに対応するマーク情報が削除される。
これらの、フィールドConnectionConditionの値の設定と、マーク情報の削除により、クリップＡＶストリームファイル７２ＣおよびクリップＡＶストリームファイル７８Ａが１チャプタに結合され、１の連続したコンテンツとして再生可能とされる。
なお、上述では、記録媒体５２が光ディスク５０Ａや光ディスク５０Ｂより十分容量の大きな他の光ディスクであるとして説明したが、これはこの例に限定されない。例えば、記録媒体５２は、記録再生装置１の入出力Ｉ／Ｆ１５で以て接続可能な大容量なハードディスク装置でもよい。記録媒体５２として十分に記録容量の大きな半導体メモリを用いることも考えられる。
４−２−３．接続状態管理情報に基づくチャプタ結合可否判定処理
図４０および図４１のフローチャートを用いて、接続状態管理情報に基づくチャプタ結合可否判定の一例の処理について説明する。なお、図４０および図４１のフローチャートにおいて、符号「Ａ」は、対応する符号に処理が移行されることを示す。ここでは、図３８および図３９を用いて上述した、光ディスク５０Ａおよび光ディスク５０Ｂの記録内容を、より記録容量の大きな例えば他の光ディスクである記録媒体５２に対して纏めて保存し、その際に、光ディスク５０Ａに記録されるクリップＡＶストリームファイル７２Ｃと、光ディスク５０Ｂに記録されるクリップＡＶストリームファイル７７Ａとを、１チャプタに結合して１の連続したコンテンツとして再生可能なようにオーサリングする場合を例にとって説明する。
最初のステップＳ１００で、結合判定を行う境界に対して先行するディスクのリアルプレイリストにより参照されるクリップインフォメーションファイルのうち、最終のクリップインフォメーションファイル（以下、先行ディスクの最終クリップインフォメーションファイルと呼ぶ）から、接続状態管理情報が取得される。結合判定境界は、例えば記録時に光ディスクの交換に伴いストリームデータの分割を行った境界位置に対応し、結合判定境界に対して先行するディスクは、図３８の例では、光ディスク５０Ａに相当する。光ディスク５０Ａのリアルプレイリストファイル７０から最終のプレイアイテム７１Ｃが検索され、当該プレイアイテム７１Ｃに参照されるクリップインフォメーションファイル７３Ｃに格納されるブロックblkExtensionData()中のブロックblkMakersPrivateData()から、ブロックDataBlock()の値が取り出される（図１６、図２５および図２６参照）。
ステップＳ１０１では、ステップＳ１００で先行ディスクから接続状態管理情報が取得できたか否かが判断される。若し、取得できたと判断されれば、処理はステップＳ１０２に移行される。一方、先行ディスクから接続状態管理情報が取得できないと判断された場合には、結合不可とされ、一連の処理が終了される。
ステップＳ１０２では、ステップＳ１００と同様にして、結合判定境界に対して後続するディスクのリアルプレイリストにより参照されるクリップインフォメーションファイルのうち、先頭のクリップインフォメーションファイル（以下、後続ディスクの先頭クリップインフォメーションファイルと呼ぶ）から、接続状態管理情報が取得される。図３８の例では、光ディスク５０Ｂが結合判定境界に対して後続するディスクであって、光ディスク５０Ｂのリアルプレイリストファイル７６から先頭のプレイアイテムに参照されるクリップインフォメーションファイル７８Ａに格納されるブロックblkExtensionData()中のブロックblkMakersPrivateData()から、ブロックDataBlock()の値が取り出される。
ステップＳ１０３では、ステップＳ１０２で後続ディスクから接続状態管理情報が取得できたか否かが判断される。若し、取得できたと判断されれば、処理はステップＳ１０４に移行される。一方、先行ディスクから接続状態管理情報が取得できないと判断された場合には、結合不可とされ、一連の処理が終了される。
なお、ステップＳ１０１およびステップＳ１０３において、先行または後続ディスクから接続状態管理情報が取得できないと判断される要因としては、光ディスク５０Ａまたは５０Ｂにおいて、ディスクエラーなどの原因により当該データにアクセスできなかった場合が考えられる。また、光ディスク５０Ａまたは５０Ｂのうち一方が他機により記録されたディスクであって、接続状態管理情報が当初から存在していない場合も考えられる。
ステップＳ１０４では、先行ディスクから取得された接続状態管理情報のデータPRODUCT_SERIAL_NUMBERと、先行ディスクから取得された接続状態管理情報のデータPRODUCT_SERIAL_NUMBERとが比較される。比較の結果、両者が一致すると判断されれば（ステップＳ１０５）、処理はステップＳ１０６に移行される。一方、両者が一致しないと判断されれば、結合不可とされ、一連の処理が終了される。
ステップＳ１０６では、先行ディスクから取得された接続状態管理情報のデータCONTENTS_SERIAL_NUMBERと、後続ディスクから取得された接続状態管理情報のデータCONTENTS_SERIAL_NUMBERとが比較される。比較の結果に基づき、ステップＳ１０７で、両者が連続値であるか否かが判断される。例えば、先行ディスクにおけるデータCONTENTS_SERIAL_NUMBERに１を加えた値が、後続ディスクにおけるデータCONTENTS_SERIAL_NUMBERの値と一致すれば、両者が連続値であると判断できる。
なお、上述したように、データCONTENTS_SERIAL_NUMBERは、所定の最大値Maximun_Numberでリセットされ再び０からインクリメントされる。このステップＳ１０６の比較処理でも、このことが考慮され、先行ディスクにおけるデータCONTENTS_SERIAL_NUMBERが所定の最大値Maximun_Numberであった場合には、後続ディスクにおけるデータCONTENTS_SERIAL_NUMBERが０であれば、両者が連続値であると判断する。
ステップＳ１０６での比較の結果、両者が連続値であると判断されれば（ステップＳ１０７）、処理はステップＳ１０８に移行される。一方、両者が一致しないと判断されれば、結合不可とされ、一連の処理が終了される。
ステップＳ１０８では、先行ディスクの最終クリップインフォメーションファイルが編集されているか否かがチェックされる。これは、すなわち、当該クリップインフォメーションファイルに対応するクリップＡＶストリームファイルが編集されているか否かをチェックすることに他ならない。これは、後述するステップＳ１１０におけるチェックでも同様である。チェック結果に基づきステップＳ１０９で当該クリップインフォメーションファイルが編集されているか否かが判断され、編集されていると判断されれば、結合不可とされ、一連の処理が終了される。一方、編集されていないと判断されれば、処理はステップＳ１１０に移行される。
ステップＳ１１０では、同様にして、後続ディスクの先頭クリップインフォメーションファイルが編集されているか否かがチェックされ、チェック結果に基づき、ステップＳ１１１で、当該クリップインフォメーションファイルが編集されているか否かが判断される。編集されていると判断されれば、結合不可とされ、一連の処理が終了される。一方、編集されていないと判断されれば、処理は図４１のステップＳ１１２に移行される。ステップＳ１０８およびステップＳ１１０におけるクリップインフォメーションファイルが編集されているか否かをチェックするための処理については、後述する。
説明は図４１のフローチャートに移り、ステップＳ１１２では、後続ディスクの先頭クリップインフォメーションファイルにおける接続状態管理情報について、データPRESENTATION_START_ENABLE_TIMEと、データPRESENTATION_START_TIMEとが比較される。この比較の結果に基づき、ステップＳ１１３で、表示開始可能時刻すなわちデータPRESENTATION_START_ENABLE_TIMEが、データPRESENTATION_START_TIMEで示される表示開始時刻よりも先行しているか否かが判断される。
このステップＳ１１３の判断により、この後続ディスクの先頭クリップインフォメーションファイルが対応するクリップＡＶストリームが、先行ディスクの最終クリップインフォメーションファイルが対応するクリップＡＶストリームに対してシームレス接続されるか否かが判断される。
すなわち、図３７を用いて既に説明したように、後続ディスクの先頭クリップインフォメーションファイルの先頭のＧＯＰが、先行ディスクの最終クリップインフォメーションファイルの最終ＧＯＰとシームレス接続される場合には、後続ディスクの先頭クリップインフォメーションファイルの接続状態管理情報において、データPRESENTATION_START_ENABLE_TIMEと、上述したデータPRESENTATION_START_TIMEとが等しくなる。一方、シームレス接続を行わない場合には、データPRESENTATION_START_TIMEがＩ2ピクチャの表示開始時間となるため、このデータPRESENTATION_START_ENABLE_TIMEと、上述したデータPRESENTATION_START_TIMEとが等しくならず、データPRESENTATION_START_ENABLE_TIMEがデータPRESENTATION_START_TIMEに対して先行することになる。
したがって、ステップＳ１１３で、データPRESENTATION_START_ENABLE_TIMEで示される時刻が、データPRESENTATION_START_TIMEで示される表示開始時刻よりも先行していると判断された場合には、処理はステップＳ１１４に移行され、シームレス接続を行わないとされる。すなわち、ステップＳ１１４では、リアルプレイリストファイルに格納される、対応するブロックblkPlayItem()中のフィールドConnectionConditionの値が、シームレス接続を行わないことを示す値"１"とされる。そして、処理は後述するステップＳ１１９に移行される。
一方、ステップＳ１１３で、データPRESENTATION_START_ENABLE_TIMEで示される時刻が、データPRESENTATION_START_TIMEで示される表示開始時刻よりも先行していないと判断されれば、シームレス接続を行うとされ、処理はステップＳ１１５に移行され、第２のシームレス接続方法で以てシームレス接続を行うとされる。そして、ステップＳ１１６で、後続ディスクの先頭のプレイアイテムの接続状態を、第２のシームレス接続を行うことを示す値"６"とする。より具体的には、光ディスク５０Ｂのリアルプレイリストファイル７６に格納される、先頭のプレイアイテム７７Ａに対応するブロックblkPlayItem()中のフィールドConnectionConditionの値が"６"とされる。
さらに、次のステップＳ１１７で、後続ディスクの先頭のプレイアイテムに記述されるＩＮ点の情報を、データPRESENTATION_START_ENABLE_TIMEで示される時刻に変更する。より具体的には、例えば、図１３を参照し、光ディスク５０Ｂのリアルプレイリストファイル７６に格納される、先頭のプレイアイテム７７Ａに対応するブロックblkPlayItem()中のフィールドINTimeの値が、データPRESENTATION_START_ENABLE_TIMEの値に変更される。
そして、次のステップＳ１１８で、後続ディスクの先頭クリップインフォメーションファイルの先頭ＳＴＣの表示開始時刻を、データPRESENTATION_START_ENABLE_TIMEで示される時刻に変更する。より具体的には、例えば、図１８を参照し、光ディスク５０Ｂのクリップインフォメーションファイル７９Ａに格納されるブロックblkSequenceInfo()中においてforループ文で記述されるフィールドSPNSTCStart[stc_id]のうち、ループ変数stc_id＝０であるフィールドSPNSTCStart[stc_id]の値が、データPRESENTATION_START_ENABLE_TIMEの値に変更される。そして、処理がステップＳ１１９に移行される。
ステップＳ１１９では、後続ディスクの先頭のチャプタマークを削除し、後続ディスクの先頭リアルプレイリストを、先行ディスクの最終リアルプレイリストに結合する。
このステップＳ１１９の処理について、より具体的に説明する。例えば図３８の例では、後続ディスクである光ディスク５０Ｂ上には、プレイリストファイルはリアルプレイリストファイル７６の１つのみが存在する。このリアルプレイリストファイル７６に格納されるブロックblkPlayListMark()中のforループ文において、最初のマーク、すなわち、図１５を参照して、ループ変数PL_mark_idが０のループとして記述されるフィールドreserved、フィールドMarkType、フィールドRefToPlayItemID、フィールドMarkTimeStamp、フィールドEntryESPIDおよびフィールドDurationの値が削除されると共に、フィールドNumberOfPlayMarksの値が１だけ減ぜられる。
また、図３８の例では、先行ディスクである光ディスク５０Ａ上には、プレイリストファイルはリアルプレイリストファイル７０の１つのみが存在する。このリアルプレイリストファイル７０と、後続ディスクである光ディスク５０Ｂ上の、上述のステップＳ１１６〜ステップＳ１１８までの処理とステップＳ１１９によるマーク情報の削除処理がなされ変更されたリアルプレイリストファイル７６とから、記録媒体５２に記録すべき新たなリアルプレイリストファイル８２が生成される。例えば、リアルプレイリストファイル７０に対して、変更されたプレイリストファイル７６の内容を追加することが考えられる。
一例として、リアルプレイリストファイル７０の内容に対し、図１５に示されるブロックblkPlayListMark()について、変更されたリアルプレイリストファイル７６のブロックblkPlayListMark()の内容が追加されると共に、図１１に示されるブロックblkPlayList()について、変更されたリアルプレイリストファイル７６に含まれるブロックblkPlayItem()が追加され、フィールドNumberOfPlayItemsの値が変更される。これらに伴い、図１０に示される変更されたリアルプレイリストファイル７６の内容において、各スタートアドレスの値が所定に変更される。
４−２−３−１．クリップインフォメーションファイルの編集の有無の判定について
次に、上述したステップＳ１０８およびステップＳ１１０における、クリップインフォメーションファイルが編集されているか否かをチェックする一例の処理について説明する。この実施の第１の形態においては、接続状態管理情報に格納されるＳＴＣの情報、すなわちデータPRESENTATION_START_STC_IDに基づき、クリップインフォメーションファイルに格納される、対応するクリップＡＶストリームのＳＴＣに関する情報が変更されているか否かを判断することで、編集の有無をチェックする。
ここで、ＳＴＣについて、図４２を用いて概略的に説明する。図１８を用いて既に説明したように、ＭＰＥＧ２ ＴＳにおける時間軸の基準であるＰＣＲが連続な範囲を表すシーケンスSTCSequence（以下、ＳＴＣシーケンスと呼ぶ）は、１のクリップ内で複数を含むことができる。ＳＴＣシーケンス内では時間的に連続である必要があるが、１のクリップ内において、ＳＴＣシーケンス同士は、時間的に不連続であってもよい。図４２Ａに例示されるように、ＳＴＣシーケンスのそれぞれに対し、クリップの先頭から１ずつインクリメントされるＩＤ(ブロックblkSequenceInfo()中の値stc_id：図１８参照)が付与されると共に、各々、開始時刻(ブロックblkSequenceInfo()中のフィールドPresentationStartTime：図１８参照、図４２中では「ST」と表記)および終了時刻(ブロックblkSequenceInfo()中のフィールドPresentationEndTime：図１８参照、図４２中では「EN」と表記)が定義される。この時刻STおよび時刻ENで示される範囲がこのクリップの有効な範囲であって、プレイアイテムから参照できる範囲とされる。
ここで、クリップに対して編集を行い、クリップの一部を削除することを考える。クリップの端部、例えば先頭側を削除した場合、図４２Ｂに例示されるように、例えば値stc_idの最も小さいＳＴＣシーケンスにおいて、開始時刻STが削除後の開始時刻ST'に変更され、開始時刻ST'より前部が削除される。これは、クリップの後端側を削除した場合も同様である。
一方、クリップの中間部分を削除した場合には、ＡＴＣ(Arrival Time Clock)シーケンスの連続性も考慮に入れる必要がある。ＡＴＣシーケンスは、図４２Ｄに例示されるように、クリップ内で連続している必要がある。編集などでＡＴＣシーケンスがクリップ内で不連続になってしまった場合には、そのクリップは、１のファイルとして存在できず、例えば不連続点を境界として２のファイルに分割される。
すなわち、ＳＴＣシーケンスの観点から見た場合、図４２Ｃに例示されるように、クリップは、削除部分の前後でファイル＃１およびファイル＃２のように分割され、それに伴い、ＳＴＣシーケンスの開始時刻および終了時刻も変更または新たに設定される。図４２Ｃの例では、削除部分の前側のファイル＃１において、開始時刻STは変更されないが、終了時刻および終了時刻が含まれるＳＴＣシーケンスが変更される。削除部分の後側のファイル＃２についても同様に、終了時刻ENは変更されないが、開始時刻および開始時刻が含まれるＳＴＣシーケンスが変更される。また、この図４２Ｃの例では、ファイル＃１およびファイル＃２それぞれにおいて、元のクリップに対し、ＳＴＣシーケンスの数が変更される。
図４３は、クリップインフォメーションファイルに対する編集の有無をチェックする一例の処理を示すフローチャートである。この図４３に例示されるフローチャートによる処理は、図４０を用いて説明したフローチャートにおけるステップＳ１０８およびステップＳ１１０において実行されるものである。
最初のステップＳ１２０において、接続状態管理情報におけるデータPRESENTATION_START_STC_IDが指すＳＴＣシーケンスの開始時刻を、当該接続情報管理情報におけるデータPRESENTATION_START_TIMEと比較する。より具体的には、図１８を参照し、クリップインフォメーションファイルに格納されるブロックblkSequenceInfo()中のforループ文において、ループ変数stc_idがデータPRESENTATION_START_STC_IDの値と一致するフィールドPresentationStartTimeの値が取り出され、データPRESENTATION_START_TIMEと比較される。
ステップＳ１２０での比較の結果、一致すると判断されれば（ステップＳ１２１）、処理はステップＳ１２２に移行される。一方、一致しないと判断されれば、当該クリップインフォメーションファイルは編集されていると判断される。
ステップＳ１２２では、接続状態管理情報におけるデータPRESENTATION_END_STC_IDが指すＳＴＣシーケンスの終了時刻を、当該接続情報管理情報におけるデータPRESENTATION_END_TIMEと比較する。より具体的には、図１８を参照し、クリップインフォメーションファイルに格納されるブロックblkSequenceInfo()中のforループ文において、ループ変数stc_idがデータPRESENTATION_END_STC_IDの値と一致するフィールドPresentationEndTimeの値が取り出され、データPRESENTATION_END_TIMEと比較される。
ステップＳ１２２での比較の結果、一致すると判断されれば（ステップＳ１２３）、処理はステップＳ１２４に移行される。一方、一致しないと判断されれば、当該クリップインフォメーションファイルは編集されていると判断される。
ステップＳ１２４では、当該クリップインフォメーションファイルに記述されるＳＴＣシーケンスの総数がチェックされる。より具体的には、図１８を参照し、クリップインフォメーションファイルに格納されるブロックblkSequenceInfo()中のフィールドNumberOfSTCSequenceの値が取り出され、接続状態管理情報におけるデータPRESENTATION_END_STC_IDの値に１を加えた値と比較される。なお、データPRESENTATION_END_STC_IDの値に１を加えるのは、ブロックblkSequenceInfo()において、ＳＴＣシーケンスの情報をフィールドNumberOfSTCSequenceに示される数だけ記述するforループ文のループ変数が０から始まるからである。
ステップＳ１２４の比較の結果、一致すると判断されれば（ステップＳ１２５）、当該クリップインフォメーションファイルは、編集されていないと判断される。一方、一致しないと判断されれば、当該クリップインフォメーションファイルは編集されていると判断される。
このように、この実施の第１の形態によれば、連続したストリームデータを光ディスクなどの着脱可能な記録媒体に記録する際に、ディスクを交換した際の認識処理や初期化処理などにより、当該光ディスクに対するストリームデータの記録が行えない場合に、当該光ディスクに記録できない期間のストリームデータを内蔵記録媒体に退避させる。そして、退避させたストリームは、交換後の光ディスクが記録可能となった時点で、内蔵記録媒体から当該交換後の光ディスクに書き込むようにしている。そのため、連続したストリームデータを、時間的に連続した状態で、複数の光ディスクに分割して記録することができる。
また、連続したストリームデータを複数の光ディスクに分割して記録する際に、ストリームデータの接続状態を管理する情報を生成し、この接続状態管理情報をストリームデータの管理情報に含めて記録するようにしている。そのため、ストリームデータが分割して記録された複数の光ディスクの記録内容を纏め、分割されたストリームデータを１チャプタに結合し、１の連続したコンテンツとして再生可能なようにオーサリングする処理を、容易に行うことができる。
５．実施の第２の形態について
次に、この発明の実施の第２の形態について説明する。この実施の第２の形態では、この発明を、撮像素子と、被写体からの光を撮像素子に入射させる光学系とを有し、撮像素子で撮像された撮像信号に基づきビデオデータを記録媒体に記録するようにした、ビデオカメラ装置に適用した。
図４４は、この発明の実施の第２の形態によるビデオカメラ装置１００の一例の構成を示す。記録系および制御系の構成は、図２９を用いて説明した記録再生装置１の構成を略そのまま適用できるので、図２９と共通する部分には同一の符号を付し、詳細な説明を省略する。
図４４の構成において、カメラ部１１０は、映像信号に関する構成として、光学系１１１、撮像素子１１２、撮像信号処理部１１３、カメラ制御部１１４および表示部１１５を有し、音声信号に関する構成として、マイクロフォン（ＭＩＣ）１１６および音声信号処理部１１７を有する。制御部１０は、カメラ部１１０の各部との間で各種制御信号や情報のやりとりを行い、カメラ部１１０の動作を制御する。また、制御部１０は、ユーザ操作に応じてＵＩ部１７から供給される制御信号に基づき、カメラ部１１０の動作を制御する。
なお、ビデオカメラ装置１００として構成される場合、記録開始操作および記録停止操作は、例えば、ＵＩ部１７に設けられた単一の記録スイッチを用い、当該記録スイッチが押下される毎に記録開始および記録停止が交互に指示されるようになされるのが一般的である。また、光ディスク５０のイジェクト動作も、ＵＩ部１７に対する所定の操作に応じて、制御部１０により制御されて行われる。
カメラ部１１０において、光学系１１１は、被写体からの光を撮像素子１１２に導くためのレンズ系、絞り調整機構、フォーカス調整機構、ズーム機構、シャッタ機構などを備える。絞り調整機構、フォーカス調整機構、ズーム機構およびシャッタ機構の動作は、制御部１０から供給される制御信号に基づき、カメラ制御部１１４により制御される。
撮像素子１１２は、例えばＣＣＤ(Charge Coupled Device)からなり、光学系１１１を介して照射された光を光電変換により電気信号に変換し、所定の信号処理を施し撮像信号として出力する。撮像信号処理部１１３は、撮像素子から出力された撮像信号に対して所定の信号処理を施し、ベースバンドのディジタルビデオデータとして出力する。
例えば撮像信号処理部１１３は、撮像素子１１２から出力された撮像信号に対して、ＣＤＳ(Correlated Double Sampling)回路により画像情報を有する信号だけをンプリングすると共に、ノイズを除去し、ＡＧＣ(Auto Gain Control)回路によりゲインを調整する。そして、Ａ／Ｄ変換によりディジタル信号に変換する。また、撮像信号処理部１１３は、このディジタル信号に対して検波系の信号処理を施し、Ｒ（赤色）、Ｇ（緑色）およびＢ（青色）各色の成分を取り出し、γ補正やホワイトバランス補正などの処理を行い、最終的に１本のベースバンドのディジタルビデオデータとして出力する。
また、撮像信号処理部１１３は、撮像素子１１２から出力された撮像信号の情報を制御部１０に送る。制御部１０は、この情報に基づき光学系１１１を制御するための制御信号を生成し、カメラ制御部１１４に供給する。カメラ制御部１１４は、この制御信号に基づきフォーカス調整機構や絞り調整機構などの制御を行う。
さらに、撮像信号処理部１１３は、撮像素子１１２から出力された撮像信号に基づき、例えばＬＣＤ(Liquid Crystal Display)を表示素子として用いた表示部１１５に映出させる映像信号を生成する。
一方、マイクロフォン１１６は、周囲の音声を収音して電気信号に変換して出力する。マイクロフォン１１６から出力された音声信号は、音声信号処理部１１７に供給される。音声信号処理部１１７は、供給された音声信号を、リミッタを介してからＡ／Ｄ変換を施してディジタルオーディオデータとし、ノイズ除去や音質補正など所定の音声信号処理を施してベースバンドのディジタルオーディオデータとして出力する。
カメラ部１１０の撮像信号処理部１１３から出力されたベースバンドのディジタルビデオデータや、音声信号処理部１１７から出力されたベースバンドのディジタルオーディオデータは、記録部２０に供給され、端子３０を介してＡＶ入出力制御部２１に供給される。
記録停止状態からＵＩ部１７に設けられた記録スイッチが押下されると、記録開始を指示する制御信号がＵＩ部１７から制御部１０に供給され、制御部１０の制御に基づきカメラ部１１０から出力されたベースバンドのディジタルビデオ信号およびディジタルオーディオデータの光ディスク５０への記録が開始される。
すなわち、既に説明したように、ビデオデータおよびオーディオデータは、ＡＶ入出力制御部２１を介してＥＮＣ／ＤＥＣ部２２に供給される。制御部１０の制御に基づきＥＮＣ／ＤＥＣ部２２の動作が開始され、ビデオデータおよびオーディオデータがそれぞれ圧縮符号化され、所定にパケット化され多重化されて、ＡＶストリームデータとされる。ＡＶストリームデータは、ストリームバッファ２３を介してリード／ライト制御部２４に供給され、ドライブ装置２５に装填された光ディスク５０Ａに対してクリップＡＶストリームとして記録される。
例えば、光ディスク５０Ａに対するクリップＡＶストリームの記録容量が所定以上になり、ユーザによりＵＩ部１７に設けられたイジェクトボタンが操作される。このとき、光ディスク５０Ａに対して管理情報が書き込まれる。
例えば制御部１０は、ＥＮＣ／ＤＥＣ部２１やリード／ライト制御部２４からの情報に基づき、光ディスク５０Ａに記録されるクリップＡＶストリームファイルに対応するクリップインフォメーションファイルを作成する。このとき、図３５を用いて説明した接続状態管理情報が制御部１０により作成され、クリップインフォメーションファイルに対して所定に格納される。また、制御部１０は、当該クリップインフォメーションファイルを参照するプレイアイテムを生成し、既にプレイリストが存在する場合には、生成されたプレイアイテムを当該プレイリストに対して追加すると共に、プレイリストに対してプレイリストマークを打つ。
光ディスク５０Ａへの管理情報の書き込みに伴い、ＡＶストリームデータの記録先が内蔵記録媒体５１に切り替えられる。ＥＮＣ／ＤＥＣ部２２から出力されたクリップＡＶストリームは、ストリームバッファ２３を介してリード／ライト制御部２４に供給され、内蔵記録媒体５１に退避データとして記録される。
光ディスク５０Ａに対する管理情報の書き込みが終了すると、制御部１０の制御により光ディスク５０Ａがドライブ装置２５から排出される。ユーザは、撮影データの記録を継続させるために、次の光ディスク５０Ｂをドライブ装置２５に装填する。光ディスク５０Ｂに対して認識処理および初期化処理が行われている間、ＡＶストリームデータは、退避データとして内蔵記録媒体５１に記録される。光ディスク５０Ｂに対する認識処理および初期化処理が終了し、光ディスク５０Ｂに対するＡＶストリームデータの書き込みが可能な状態になると、内蔵記録媒体５１に記録された退避データが光ディスク５０Ｂに対してコピーされ、その後、ＡＶストリームデータの記録先が光ディスク５０Ｂに切り替えられ、ストリームバッファ２３から読み出されたＡＶストリームデータが光ディスク５０Ｂに所定に記録される。
ＵＩ部１７の記録スイッチが押下されると、記録が停止され、クリップインフォメーションファイルの作成や、プレイリストファイルの更新が行われる。制御部１０は、ＥＮＣ／ＤＥＣ部２２およびリード／ライト制御部２４からの情報に基づき、光ディスク５０Ｂに記録されるクリップＡＶストリームファイルに対応するクリップインフォメーションファイルを作成すると共に、接続状態管理情報を作成し、当該クリップインフォメーションファイルに所定に格納する。また、制御部１０は、当該クリップインフォメーションファイルを参照するプレイアイテムを生成し、既にプレイリストが存在する場合には、生成されたプレイアイテムを当該プレイリストに対して追加すると共に、プレイリストに対してプレイリストマークを打つ。
この実施の第２の形態のように、この発明をビデオカメラ装置１００に適用することで、ユーザは、光ディスク５０に記録可能なデータ容量を超えて連続的に撮影を行うことができる。
また、光ディスク５０に記録されたＡＶストリームデータの管理情報に、接続状態管理情報を含めるようにしているため、光ディスク５０に記録可能なデータ容量を超えて連続的に撮影され、複数の光ディスク５０、５０、・・・に分割して記録されたＡＶストリームデータを、撮影時の状態で連続的に再生できるようにオーサリングする処理を、容易に行うことができる。なお、このオーサリング処理は、上述した実施の第１の形態による処理と共通なので、ここでの説明は省略する。
６．実施の第３の形態について
次に、この発明の実施の第３の形態について説明する。上述した実施の第１および第２の形態では、光ディスク５０の交換時に、ストリームデータを内蔵記録媒体５１に退避させるようにしている。これに対して、この実施の第３の形態では、記録装置の起動時や、記録開始に際して最初に装填された光ディスクの認識処理および初期化処理時に、ストリームデータを内蔵記録媒体に退避させる。そして、装填された光ディスクに対する認識処理や初期化処理が終了し、当該光ディスクに対するストリームデータの記録が可能となったら、内蔵記録媒体に退避された退避データを光ディスクにコピーし、その後、ストリームバッファから読み出したストリームデータを光ディスクに記録する。
図４５を用いてより具体的に説明する。なお、この実施の第３の形態では、図２９を用いて説明した記録再生装置１や、図４４を用いて説明したビデオカメラ装置１００をそのまま適用できる。以下では、図２９に例示される記録再生装置１をこの実施の第３の形態に適用したものとして説明する。
一例として、予め光ディスク５０がドライブ装置２５に装填された状態で、記録再生装置１の電源をＯＮとし、記録再生装置１を起動させた場合について考える。制御部１０は、電源ＯＮに応じて、記録再生装置１の各部に対する初期化処理など、装置起動時の所定の動作を行うように制御する。このとき、ドライブ装置２５に光ディスク５０が装填されていれば、当該光ディスクの認識処理が行われ、必要であれば、光ディスク５０に対する初期化処理も行われる。
起動時の所定の動作により、記録再生部２０の各部が作動可能な状態となり、内蔵記録媒体５１が記録可能な状態とされる。端子３０から入力されたビデオデータおよびオーディオデータは、ＡＶ入出力制御部２１を介してＥＮＣ／ＤＥＣ部２２に供給される。ＥＮＣ／ＤＥＣ部２２では、ビデオデータおよびオーディオデータに対して所定に圧縮符号化処理を行い、さらにビデオデータおよびオーディオデータの多重化処理を行い、ストリームデータを生成する。このストリームデータは、ストリームバッファ２３に溜め込まれる（図４５Ａ参照）。
一方、制御部１０は、起動時の所定の動作により記録再生部２０の各部が作動可能な状態となると、ドライブ装置２５に装填された光ディスク５０に対して認識処理を行い、必要ならば初期化処理を行う（図４５Ｃ参照）。この認識処理および初期化処理の間は、光ディスク５０に対するストリームデータの記録は行えない。この間に、ストリームバッファ２３に所定量Ｄth以上のデータが溜め込まれると、ストリームバッファ２３から記録単位分のデータが読み出され、読み出されたデータがリード／ライト制御部２４により内蔵記録媒体５１に対して退避データとして書き込まれる（図４５Ｂ）。
図３３のフローチャートを用いて説明したような記録制御により、光ディスク５０に対するストリームデータの記録が可能となったと判断されたら、内蔵記録媒体５１に記録された退避データが光ディスク５０に所定にコピーされ、その後、ストリームバッファ２３から記録単位毎に読み出されたデータが光ディスク５０に記録される（図４５Ｃ参照）。
このように、この実施の第３の形態によれば、記録再生装置１の起動時や、記録開始に際して最初に装填された光ディスク５０の認識処理時などに供給されるストリームデータも、光ディスク５０に記録することができる。これは、例えばこの実施の第３の形態を、実施の第２の形態のようなビデオカメラ装置１００に適用した場合に、撮影機会を逃すことなく撮影を行うことができることを意味する。
なお、上述では、この発明においてストリームデータが記録される記録媒体が光ディスクであるように説明したが、これはこの例に限定されない。例えば、着脱可能な不揮発性の半導体メモリにストリームデータを記録するような場合にも、この発明を同様に適用することができる。
この発明に適用可能なＡＶＣＨＤフォーマットに規定されるデータモデルを概略的に示す略線図である。 インデックステーブルを説明するための略線図である。 クリップＡＶストリーム、クリップ情報、クリップ、プレイアイテムおよびプレイリストの関係を示すＵＭＬ図である。 複数のプレイリストから同一のクリップを参照する方法を説明するための略線図である。 記録媒体に記録されるファイルの管理構造を説明するための略線図である。 光ディスク以外の記録媒体に適用可能な一例の管理構造を示す略線図である。 ファイル"index.bdmv"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkIndexes()の一例の構造を表すシンタクスを示す略線図である。 ファイル"MovieObject.bdmv"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkMovieObjects()の一例の構造を表すシンタクスを示す略線図である。 プレイリストファイル"xxxxx.mpls"の一例の構造を表すシンタクスを示す略線図である。 ブロックblkPlayList()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkPlayItem()の一例の構造を表すシンタクスを示す略線図である。 第１および第２のシームレス接続を説明するための略線図である。 ブロックblkPlayListMark()の一例の構造を表すシンタクスを示す略線図である。 クリップインフォメーションファイルの一例の構造を表すシンタクスを示す略線図である。 ブロックblkClipInfo()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkSequenceInfo()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkExtensionData()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkExtensionData()における各データの参照関係を模式的に示す略線図である。 ブロックblkExtensionData()にデータを書き込む際の一例の処理を示すフローチャートである。 ブロックblkExtensionData()から拡張データを読み出す際の一例の処理を示すフローチャートである。 ファイル"index.bdmv"内のフィールドblkExtensionData()におけるブロックDataBlock()の一例の構造を表すシンタクスを示す略線図である。 ブロックblkTableOfPlayList()の一例の構造を表すシンタクスを示す略線図である。 クリップインフォメーションファイル内のブロックblkExtensionData()におけるブロックDataBlock()の一例の構造を表すシンタクスを示す略線図である。 クリップインフォメーションファイルにおけるブロックblkMakersPrivateData()の一例の構造を表すシンタクスを示す略線図である。 仮想プレーヤの動作を概略的に示すフローチャートである。 仮想プレーヤの動作を概略的に示す略線図である。 この発明に適用可能な記録再生装置の一例の構成を示すブロック図である。 この発明に適用可能な一例のデータ構造を示す略線図である。 実施の第１の形態による記録制御を概略的に説明するための略線図である。 光ディスクの交換処理における光ディスクおよび内蔵記録媒体に対するデータ書き込みの一例のタイミングを示すタイミングチャートである。 光ディスク交換時の一例の記録制御を示すフローチャートである。 内蔵記録媒体における退避データの一例の管理構造を示す略線図である。 接続状態管理情報の一例の構造を示す略線図である。 フレーム間圧縮を行ったデータのデコード処理について説明するための略線図である。 再生開始時刻および再生開始可能時刻を説明するための略線図である。 複数の光ディスクに分割して記録されたクリップＡＶストリームファイルを、時間的に連続した１のコンテンツとして再生可能とするためのオーサリング処理について説明するための略線図である。 複数の光ディスクに分割して記録されたクリップＡＶストリームファイルを、時間的に連続した１のコンテンツとして再生可能とするためのオーサリング処理について説明するための略線図である。 接続状態管理情報に基づくチャプタ結合可否判定の一例の処理について説明するフローチャートである。 接続状態管理情報に基づくチャプタ結合可否判定の一例の処理について説明するフローチャートである。 ＳＴＣについて概略的に説明するための略線図である。 クリップインフォメーションファイルに対する編集の有無をチェックする一例の処理を示すフローチャートである。 この発明の実施の第２の形態によるビデオカメラ装置の一例の構成を示すブロック図である。 この発明の実施の第３の形態について説明するための略線図である。
符号の説明
１ 記録再生装置
１０ 制御部
１２ ＣＰＵ
１７ ＵＩ部
２０ 記録再生部
２２ ＥＮＣ／ＤＥＣ部
２３ ストリームバッファ
２４ リード／ライト制御部
２５ ドライブ装置
５０，５０Ａ，５０Ｂ，５０Ｃ 光ディスク
５１ 内蔵記録媒体
７０，７６，８２ リアルプレイリストファイル
７１Ａ〜７１Ｃ，７７Ａ，７７Ｂ，８３Ａ〜８３Ｅ プレイアイテム
７２Ａ〜７２Ｃ，７８Ａ，７８Ｂ クリップＡＶストリームファイル
７３Ａ〜７３Ｃ，７９Ａ，７９Ｂ クリップインフォメーションファイル
１００ ビデオカメラ装置

Claims (21)

  1. ディスク状記録媒体にストリームデータを記録する記録装置において、
    着脱可能なディスク状記録媒体にデータを記録する第１の記録部と、
    筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録部と、
    連続的に供給されるストリームデータを一時的に溜め込むバッファ部と、
    上記第１の記録部が上記ディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断部と、
    上記判断部の判断結果に基づき、上記バッファ部から読み出された上記ストリームデータの記録先を上記ディスク状記録媒体と上記記録媒体とで切り替える記録制御部と
    を有する
    ことを特徴とする記録装置。
  2. 請求項１に記載の記録装置において、
    上記記録制御部は、
    上記記録先を上記ディスク状記録媒体と上記記録媒体とで切り替える際に、上記ディスク状記録媒体に記録されるストリームデータと、上記記録媒体に記録されるストリームデータとが時間的に連続するように制御する
    ことを特徴とする記録装置。
  3. 請求項２に記載の記録装置において、
    上記記録制御部は、
    上記記録媒体に記録された上記ストリームデータを上記ディスク状記録媒体に記録するように制御する
    ことを特徴とする記録装置。
  4. 請求項３に記載の記録装置において、
    上記記録制御部は、
    上記判断部の判断結果に基づき、上記記録可能な状態になったとされたら、上記記録媒体に記録された上記ストリームデータを上記ディスク状記録媒体に記録し、その後、上記バッファ部から読み出された上記ストリームデータを該ディスク状記録媒体に記録するように制御する
    ことを特徴とする記録装置。
  5. 請求項３に記載の記録装置において、
    上記記録制御部は、
    上記判断部の判断結果に基づき、上記記録可能な状態になったとされたら、上記バッファ部から読み出された上記ストリームデータを上記ディスク状記録媒体に記録し、その後、上記記録媒体に記録された上記ストリームデータを上記ディスク状記録媒体に記録するように制御する
    ことを特徴とする記録装置。
  6. 請求項３に記載の記録装置において、
    上記記録制御部は、
    上記判断部の判断結果に基づき上記記録可能な状態になったとされたときに、
    上記記録媒体に記録された上記ストリームデータの上記ディスク状記録媒体への記録を、上記判断部の判断結果に基づき上記記録可能な状態になったとされた直後から行うか、上記バッファ部から読み出された上記ストリームデータの上記ディスク状記録媒体への記録が行われた後に行うかを、上記ディスク状記録媒体に対するデータの書き込み速度、上記記録媒体のデータの読み書きの速度、上記ストリームデータのビットレート、ならびに、上記記録媒体に記録された上記ストリームデータの容量に基づき自動的に判断するようにした
    ことを特徴とする記録装置。
  7. 請求項３に記載の記録装置において、
    上記記録制御部は、
    上記ディスク状記録媒体に対して、該ディスク状記録媒体に記録される上記ストリームデータの接続状態を示す接続状態管理情報を該ストリームデータに対応付けて記録するように制御する
    ことを特徴とする記録装置。
  8. 請求項７に記載の記録装置において、
    上記接続状態管理情報は、
    対応するストリームデータと、他のディスク状記録媒体に記録されるストリームデータとの連続性を示す情報を含む
    ことを特徴とする記録装置。
  9. 請求項８に記載の記録装置において、
    上記接続状態管理情報は、
    上記記録制御部により上記ディスク状記録媒体に上記ストリームデータがファイルとして記録される毎にインクリメントされる値と、該ストリームデータが該ディスク状記録媒体に記録されたセットを識別する情報とを、上記連続性を示す情報として含む
    ことを特徴とする記録装置。
  10. 請求項８に記載の記録装置において、
    上記接続状態管理情報は、
    上記ストリームデータに対して定義された表示開始時刻および表示終了時刻を示す情報をさらに含む
    ことを特徴とする記録装置。
  11. 請求項１０に記載の記録装置において、
    上記接続状態管理情報は、
    対応するストリームデータの直前に、該ストリームデータに対して時間的に連続して接続可能なストリームデータが存在することで表示開始が可能となる時刻を示す情報をさらに含む
    ことを特徴とする記録装置。
  12. ディスク状記録媒体にストリームデータを記録する記録方法において、
    着脱可能なディスク状記録媒体にデータを記録する第１の記録のステップと、
    筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録のステップと、
    連続的に供給されるストリームデータを一時的にバッファ部に溜め込むステップと、
    上記第１の記録のステップにより上記ディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断のステップと、
    上記判断のステップによる判断結果に基づき、上記バッファ部から読み出された上記ストリームデータの記録先を上記ディスク状記録媒体と上記記録媒体とで切り替える記録制御のステップと
    を有する
    ことを特徴とする記録方法。
  13. ディスク状記録媒体にストリームデータを記録する記録方法をコンピュータに実行させる記録プログラムにおいて、
    上記記録方法は、
    着脱可能なディスク状記録媒体にデータを記録する第１の記録のステップと、
    筐体に対して固定的に用いられる記録媒体にデータを記録する第２の記録のステップと、
    連続的に供給されるストリームデータを一時的にバッファ部に溜め込むステップと、
    上記第１の記録のステップにより上記ディスク状記録媒体にストリームデータを記録可能な状態であるか否かを判断する判断のステップと、
    上記判断のステップによる判断結果に基づき、上記バッファ部から読み出された上記ストリームデータの記録先を上記ディスク状記録媒体と上記記録媒体とで切り替える記録制御のステップと
    を有する
    ことを特徴とする記録プログラム。
  14. 複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集方法において、
    第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断のステップと、
    上記判断のステップによる判断の結果、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、該第１のストリームデータと該第２のストリームデータのうち時間的に後行する側のストリームデータに対し、該ストリームデータに先行するストリームデータとシームレスに接続することを示す接続情報を対応付けるステップと
    を有する
    ことを特徴とする編集方法。
  15. 請求項１４に記載の編集方法において、
    上記接続状態管理情報は、
    対応するストリームデータと、他のディスク状記録媒体に記録されるストリームデータとの連続性を示す情報を含み、
    上記判断のステップは、上記連続性を示す情報に基づき上記第１のストリームデータと上記第２のストリームデータとを１のコンテンツとして時間的に連続して再生可能か否かを判断する
    ことを特徴とする編集方法。
  16. 請求項１５に記載の編集方法において、
    上記接続状態管理情報は、
    上記ディスク状記録媒体に上記ストリームデータがファイルとして記録される毎にインクリメントされる値と、該ストリームデータが該ディスク状記録媒体に記録されたセットを識別する情報とを、上記連続性を示す情報として含む
    ことを特徴とする編集方法。
  17. 請求項１５に記載の編集方法において、
    上記接続状態管理情報は、
    上記ストリームデータに対して定義された表示開始時刻および表示終了時刻を示す情報と、該表示開始時刻および該表示終了時刻にそれぞれ対応する、記録時のシステムクロックに基づく時刻情報とを、上記連続性を示す情報としてさらに含み、
    上記判断のステップは、
    上記表示開始時刻および表示終了時刻を示す情報と、該表示開始時刻および該表示終了時刻にそれぞれ対応する、上記記録時のシステムクロックに基づく時刻情報とに基づき対応するストリームデータが編集されたか否かを判定し、編集されたと判定された場合に、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生できないと判断する
    ことを特徴とする編集方法。
  18. 請求項１７に記載の編集方法において、
    上記接続状態管理情報は、
    対応するストリームデータの直前に、該ストリームデータに対して時間的に連続して接続可能なストリームデータが存在することで表示開始が可能となる時刻を示す情報を、上記連続性を示す情報としてさらに含み、
    上記判断のステップは、
    上記第１のストリームデータと上記第２のストリームデータのうち時間的に後続する側のストリームデータに対応する上記接続状態管理情報の上記表示開始時刻を示す情報と上記表示開始が可能となる時刻を示す情報とを比較し、比較結果に基づき該表示開始が可能となる時刻が該表示開始時刻よりも先行している場合に、該第１のストリームデータと該第２のストリームデータとを１のコンテンツとして時間的に連続して再生可能であると判断するようにした
    ことを特徴とする編集方法。
  19. 請求項１４に記載の編集方法において、
    上記第１および上記第２のストリームデータと、該第１および該第２のストリームデータのうち時間的に後行する側のストリームデータに対して対応付けられた上記接続情報とを１の記録媒体に記録する記録のステップをさらに有する
    ことを特徴とする編集方法。
  20. 複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集方法をコンピュータに実行させる編集プログラムにおいて、
    上記編集方法は、
    第１のディスク状記録媒体に記録された第１のストリームデータに対応付けられた第１の接続状態管理情報と、第２のディスク状記録媒体に記録された第２のストリームデータに対応付けられた第２の接続状態管理情報とに基づき、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断のステップと、
    上記判断のステップによる判断の結果、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、該第１のストリームデータと該第２のストリームデータのうち時間的に後行する側のストリームデータに対し、該ストリームデータに先行するストリームデータとシームレスに接続することを示す接続情報を対応付けるステップと
    を有する
    ことを特徴とする編集プログラム。
  21. 複数のディスク状記録媒体に記録されたストリームデータを１のコンテンツとして再生可能に編集する編集装置において、
    第１のストリームデータと該第１のストリームデータの接続状態を示す第１の接続状態管理情報とが記録された第１のディスク状記録媒体と、第２のストリームデータと該第２のストリームデータの接続状態を示す第２の接続状態管理情報とが記録された第２のディスク状記録媒体とからデータを読み出す読み出し部と、
    上記第１の接続状態管理情報と上記第２の接続状態管理情報とに基づき、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるか否かを判断する判断部と、
    上記判断のステップによる判断の結果、上記第１のストリームデータと上記第２のストリームデータとを、１のコンテンツとして時間的に連続して再生可能であるとされたら、該第１のストリームデータと該第２のストリームデータのうち時間的に後行する側のストリームデータに対し、該ストリームデータに先行するストリームデータとシームレスに接続することを示す接続情報を対応付ける編集部と、
    上記第１および上記第２のストリームデータと、該第１および該第２のストリームデータのうち時間的に先行する側のストリームデータに対して対応付けられた上記接続情報とを記録媒体に記録する記録部と
    を有する
    ことを特徴とする編集装置。
JP2007125642A 2007-05-10 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム Pending JP2008282471A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007125642A JP2008282471A (ja) 2007-05-10 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007125642A JP2008282471A (ja) 2007-05-10 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Publications (1)

Publication Number Publication Date
JP2008282471A true JP2008282471A (ja) 2008-11-20

Family

ID=40143164

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007125642A Pending JP2008282471A (ja) 2007-05-10 2007-05-10 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Country Status (1)

Country Link
JP (1) JP2008282471A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009260733A (ja) * 2008-04-17 2009-11-05 Canon Inc 画像記録装置及び画像記録方法
WO2010084781A1 (ja) * 2009-01-26 2010-07-29 パナソニック株式会社 映像記録装置
JP2014022868A (ja) * 2012-07-17 2014-02-03 Canon Inc 画像処理装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105474A (ja) * 1996-09-27 1998-04-24 Pioneer Electron Corp 情報記録方法
JP2002074839A (ja) * 2000-09-01 2002-03-15 Hitachi Ltd ディジタル信号記録再生方法及び装置
JP2002157824A (ja) * 2000-11-17 2002-05-31 Toshiba Corp データ記録装置及びデータ記録方法
JP2002182694A (ja) * 2000-12-14 2002-06-26 Tdk Corp ディジタル式記録装置およびディジタル式再生装置
JP2005328146A (ja) * 2004-05-12 2005-11-24 Matsushita Electric Ind Co Ltd 継続録画コンテンツ結合ダビング装置、継続録画コンテンツ結合ダビング方法、継続録画コンテンツ結合ダビングプログラム、及びコンピュータ読み取り可能な記録媒体
JP2006244653A (ja) * 2005-03-04 2006-09-14 Matsushita Electric Ind Co Ltd ストリームデータ記録装置、およびストリームデータ記録方法
JP2006323953A (ja) * 2005-05-20 2006-11-30 Hitachi Ltd 情報記録装置及び情報記録再生装置
JP2007109123A (ja) * 2005-10-17 2007-04-26 Olympus Corp 記録装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105474A (ja) * 1996-09-27 1998-04-24 Pioneer Electron Corp 情報記録方法
JP2002074839A (ja) * 2000-09-01 2002-03-15 Hitachi Ltd ディジタル信号記録再生方法及び装置
JP2002157824A (ja) * 2000-11-17 2002-05-31 Toshiba Corp データ記録装置及びデータ記録方法
JP2002182694A (ja) * 2000-12-14 2002-06-26 Tdk Corp ディジタル式記録装置およびディジタル式再生装置
JP2005328146A (ja) * 2004-05-12 2005-11-24 Matsushita Electric Ind Co Ltd 継続録画コンテンツ結合ダビング装置、継続録画コンテンツ結合ダビング方法、継続録画コンテンツ結合ダビングプログラム、及びコンピュータ読み取り可能な記録媒体
JP2006244653A (ja) * 2005-03-04 2006-09-14 Matsushita Electric Ind Co Ltd ストリームデータ記録装置、およびストリームデータ記録方法
JP2006323953A (ja) * 2005-05-20 2006-11-30 Hitachi Ltd 情報記録装置及び情報記録再生装置
JP2007109123A (ja) * 2005-10-17 2007-04-26 Olympus Corp 記録装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009260733A (ja) * 2008-04-17 2009-11-05 Canon Inc 画像記録装置及び画像記録方法
WO2010084781A1 (ja) * 2009-01-26 2010-07-29 パナソニック株式会社 映像記録装置
JP2014022868A (ja) * 2012-07-17 2014-02-03 Canon Inc 画像処理装置

Similar Documents

Publication Publication Date Title
JP4715633B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム
TWI405466B (zh) A regeneration device, a regeneration program, a regeneration method, and a regeneration system
TWI401955B (zh) A reproducing apparatus, a recording medium reproducing program, a reproducing method, and a reproducing system
JP4321628B2 (ja) 記憶装置、記憶方法および記憶プログラム、ならびに、データ処理装置、データ処理方法およびデータ処理プログラム
JP4337849B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP4622950B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
JP4910475B2 (ja) 記録装置、記録方法および記録プログラム、ならびに、撮像装置、撮像方法および撮像プログラム
TWI410962B (zh) A recording device, a recording method and a recording program, and an imaging device, an imaging method, and an imaging program
KR101375058B1 (ko) 정보 처리 장치, 및 정보 처리 방법, 및 컴퓨터 프로그램이 기록된 기록 매체
JP4779797B2 (ja) 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
CA2473309C (en) Recording medium having data structure for managing reproduction of multiple reproduction path video data recorded thereon and recording and reproducing methods and apparatuses
JP2008282471A (ja) 記録装置、記録方法および記録プログラム、ならびに、編集装置、編集方法および編集プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100428

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110825

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110906

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120131