(57)【要約】ＡＶストリームは、複数のセグメントに分割されて光ディスクに記録されており、複数セグメントのうち、ｉ番目に再生されるものの前に、インターリーブユニットが記録されている。インターリーブユニットは、ｉ番目のセグメントの再生時間内に、生存区間の開始点をもつライブラリを含む。
2004034395.tif 000002
【特許請求の範囲】
【請求項１】
デジタルストリームを記録した光ディスクであって、
デジタルストリームは、ｎ個のセグメントに分割されて光ディスクに記録されていて、
ｎ個のセグメントのうち、第ｉ番目に再生されるものの前に、インターリーブユニットが記録されており、
ここでｉ，ｎは、ｉ＜ｎを満たす整数であり、
インターリーブユニットは、第ｉ番目のセグメントの再生に同期するプログラム、又は、
第ｉ番目のセグメントの再生に同期して表示されるデータを含むことを特徴とする光ディスク。
【請求項２】
インターリーブユニットは終了時点情報を含み、
終了時点情報は、デジタルストリームの再生時間軸上におけるどの時点でメモリに読み出されたプログラム又はデータを削除するかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項３】
インターリーブユニットは開始時点情報を含み、
開始時点情報は、インターリーブユニット内に含まれるプログラム又はデータの利用が、デジタルストリームの再生時間軸上におけるどの時点から、可能になるかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項４】
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されている
ことを特徴とする請求項１記載の光ディスク。
【請求項５】
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、プログラム又はデータの生存区間の途中にあたる
ことを特徴とする請求項４記載の光ディスク。
【請求項６】
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあたる
ことを特徴とする請求項４記載の光ディスク。
【請求項７】
ｉ番目のセグメントは、複数のアクセスユニットからなり、各アクセスユニットはイントラ符号化されたピクチャを有した動画データを含み、
光ディスクにはマップ情報が記録されており、
マップ情報は、ｉ番目セグメントに先行するインターリーブユニットを、第ｉ番目セグメントに属するアクセスユニットのアドレス又は再生時間と対応づけて示す
ことを特徴とする請求項１記載の光ディスク。
【請求項８】
前記ｉは２以上であり、
ｉ番目のセグメントと、ｉ−１番目のセグメントとの境界は、デジタルストリームの再生時間軸において、プログラム又はデータの生存区間の開始点にあたる  ことを特徴とする請求項１記載の光ディスク。
【請求項９】
前記生存区間とは、デジタルストリームの再生時間軸上において、インターリーブユニット内のプログラム又はデータの利用が可能となる区間である、請求項８記載の光ディスク。
【請求項１０】
前記プログラムは所定のイベントで駆動されるイベントハンドラであり、
イベントハンドラを含むインターリーブユニットは、デジタルストリームの再生時間上において、前記イベントが発生する時点より前に記録されている、請求項１記載の光ディスク。
【請求項１１】
所定のイベントとは、現在の再生時点が再生時間軸上の所定の時点に到達したことを示すイベント、
再生時間軸上の所定の時間帯にてユーザ操作がなされたことを示すイベント、再生経路による再生に先立ち発生するイベント、
再生経路による再生後に発生するイベント、
再生装置が発生するイベント、
他のプログラムにより発生されるイベントの何れかである、請求項１０記載の光ディスク。
【請求項１２】
光ディスクには、インターリーブユニット統合情報が記録されており、
インターリーブユニット統合情報は、光ディスクに記録された複数インターリーブユニットのそれぞれの識別情報を、プログラム又はデータのサイズ及び生存区間に対応づけて示す情報である
ことを特徴とする請求項１記載の光ディスク。
【請求項１３】
前記光ディスクにはプレイリスト情報、動的シナリオが記録されており、
プレイリスト情報は、動画データにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、
動的シナリオは、１つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、
インターリーブユニットは、識別情報を有しており、
識別情報は、再生経路、再生区間、映像タイトル全体、映像タイトルの章の何れかを、プログラム又はデータの生存区間として示す
ことを特徴とする請求項１記載の光ディスク。
【請求項１４】
インターリーブユニットはロケータを含んでおり。
ロケータは、ドライブ情報と、パス情報とを含み、
ドライブ情報は、プログラム又はデータを読み出すべき読出先のドライブを示し、
パス情報は、そのドライブの階層構造のうち、どの階層にプログラム又はデータが存在するかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項１５】
デジタルストリームを記録した光ディスクについての再生装置であって、
デジタルストリームを構成するｎ個のセグメントのうちｉ番目セグメントを、ｉ番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出手段と（ｉ，ｎは、ｉ＜ｎを満たす整数）、
読み出されたｉ番目セグメントを再生する再生手段と、
読み出されたインターリーブユニット内のプログラム又はデータを用いて、セグメント再生と同期した処理を行う処理手段と
を備えることを特徴とする再生装置。
【請求項１６】
前記読出手段により読み出されたインターリーブユニットを格納するメモリと、
読出手段により読み出されたセグメントを格納するトラックバッファとを備え、
前記再生手段は、トラックバッファを介してセグメントの供給を受け、
前記処理手段は、メモリを介してインターリーブユニットの供給を受ける
ことを特徴とする請求項１５記載の再生装置。
【請求項１７】
前記再生装置は、スイッチャを備え、
前記読出手段は、光ディスクにおけるセクタを読み取る度に、そのセクタのアドレスの通知を行い、
スイッチャは、読出手段から通知されたセクタアドレスが、インターリーブユニットの占有領域内であれば、セクタからの読取情報をメモリに書き込み、
読出手段から通知されたアドレスが、セグメントの占有領域内であれば、セクタからの読取情報を順次トラックバッファに書き込み、
前記メモリ上のインターリーブユニットは、スイッチャによりメモリに書き込まれた読取情報から構成され、
前記トラックバッファ上のセグメントは、スイッチャによりトラックバッファに書き込まれた読取情報から構成されることを特徴とする請求項１６記載の再生装置。
【請求項１８】
前記インターリーブユニットと、デジタルストリームとは光ディスクにおいて別々のファイルに格納されており、
光ディスクにはファイル管理情報が記録されており、
ファイル管理情報は、ファイルの識別情報と、光ディスクにおけるデジタルストリーム又はインターリーブユニットのアドレスとを対応づけて示し、
現在の読取位置が光ディスクにおけるインターリーブユニットの占有領域内であるか、セグメントの占有領域内であるかのスイッチャによる判定は、ファイル管理情報を参照してなされることを特徴とする請求項１７記載の再生装置。
【請求項１９】
前記インターリーブユニットと、デジタルストリームとは光ディスクにおいて別々のファイルに格納されており、
光ディスクにはファイル管理情報が記録されており、
ファイル管理情報は、ファイルの識別情報と、光ディスクにおけるデジタルストリーム又はインターリーブユニットのアドレスとを対応づけて示し、
読出手段は、前記複数ファイルをオープンして、インターリーブユニットを格納したファイルの読出先をメモリに指定し、デジタルストリームを格納したファイルの読出先をトラックバッファに指定した上で読み出しを行う
ことを特徴とする請求項１６記載の再生装置。
【請求項２０】
前記インターリーブユニットは終了時点情報を含み、
前記処理手段は、
再生手段による現在の再生時点が終了時点情報に示される終了時点になれば、メモリからインターリーブユニットを削除する
ことを特徴とする請求項１６記載の再生装置。
【請求項２１】
前記処理手段は仮想マシン部を備え、
処理手段は、アプリケーションプログラムからの要求に応じて、前記メモリ上のインターリーブユニット内のプログラム又はデータを仮想マシン部内のワーク領域に供給して、仮想マシン部に実行させる
ことを特徴とする請求項１６記載の再生装置。
【請求項２２】
前記インターリーブユニットは開始時点情報を含み、
処理手段が、アプリケーションプログラムからの要求に応じて、前記メモリ上のインターリーブユニット内のプログラムを仮想マシン部内のワーク領域に供給するのは、再生手段による現在の再生時点が開始時点情報に示される開始時点に達した場合であり、
再生手段による現在の再生時点が開始時点情報に示される開始時点に達していなければ、アプリケーションプログラムからの要求があってもインターリーブユニット内のプログラムを仮想マシン部内のワーク領域に供給しない、請求項２１記載の再生装置。
【請求項２３】
前記第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、プログラム又はデータの生存区間の途中にあたる位置であり、
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されており、
前記読出手段は、
ｉ番目セグメントの内部に頭出しを行う場合、前記複製物を光ディスクから読み出す、請求項１５記載の再生装置。
【請求項２４】
前記第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあり、
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの間にインターリーブユニットの複製物が、記録されており、
前記読出手段がｉ番目セグメントを読み出すのは、再生手段が通常再生を行う場合であり、
再生手段が逆方向再生を行う場合、デジタルストリームを構成する複数セグメントのうちｉ＋１番目セグメントを、ｉ＋１番目セグメントに先行する複製物と共に光ディスクから読み出すことを特徴とする請求項１５記載の再生装置。
【請求項２５】
前記ｉ番目のセグメントは、複数のアクセスユニットからなり、各アクセスユニットはイントラ符号化されたピクチャを有した動画データを含み、
光ディスクにはマップ情報が記録されており、
マップ情報は、ｉ番目セグメントに先行するインターリーブユニットを、第ｉ番目セグメントに属するアクセスユニットのアドレス又は再生時間と対応づけて示しており、
前記読出手段によるインターリーブユニットの読み出しは、マップ情報を参照してなされることを特徴とする請求項１５記載の再生装置。
【請求項２６】
前記処理手段は、仮想マシン部を備え、
再生手段は、デジタルストリームを再生すると共に、再生に同期したイベントの発生を行い、
前記仮想マシン部は、再生手段がイベントを発生すると、インターリーブユニット内のプログラムを実行することを特徴とする請求項１５記載の再生装置。
【請求項２７】
前記イベントとは、
現在の再生位置が、動画データの再生時間軸における所定の時点に到達したことを示すイベント、
再生装置が発生するイベント、
他のプログラムにより発生されるイベントの何れかである、
ことを特徴とする請求項２６記載の再生装置。
【請求項２８】
前記光ディスクにはマーク情報が記録されており、
マーク情報は、
前記再生時間軸における所定の時点、及び、所定の時間間隔を定義する情報であり、
再生手段によるイベント発生は、このマーク情報に基づいて行われる
ことを特徴とする請求項２７記載の再生装置。
【請求項２９】
前記再生装置は、ユーザ操作を受け付ける受付手段を備え、
前記イベントとは、
動画データの再生時間軸上の所定の時間帯において、受付手段がユーザ操作を受け付けたことを示すイベントである請求項２７記載の再生装置。
【請求項３０】
光ディスクには、インターリーブユニット統合情報が記録されており、インターリーブユニット統合情報は、光ディスクに記録された複数インターリーブユニットに対する管理情報であり、
前記再生装置は、メモリ、再生制御手段を備え、
再生制御手段は、複数インターリーブユニットを、前記メモリに格納することができるか否かを、インターリーブユニット統合情報に基づき判定し、
前記読出手段は、前記再生制御手段が読み出すことができると判定した場合に複数インターリーブユニットの一部又は全部の読み出しを行う、請求項１５記載の再生装置。
【請求項３１】
前記光ディスクにはプレイリスト情報が記録されており、
プレイリスト情報は、デジタルストリームにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、
前記再生制御手段は、プレイリスト情報及び動的シナリオを用いたデジタルストリームの再生を行うよう読出手段及び再生手段を制御する
ことを特徴とする請求項１５記載の再生装置。
【請求項３２】
インターリーブユニットは、識別情報を有しており、
前記再生制御手段は、プレイリスト情報を用いたデジタルストリームの再生を行うにあたって、
そのプレイリスト情報の識別情報を有したインターリーブユニット、
そのプレイリスト情報における再生区間を示す情報の識別情報を有したインターリーブユニット、
の何れかを光ディスクから読み出すよう読出手段を制御する
ことを特徴とする請求項３１記載の再生装置。
【請求項３３】
前記光ディスクには動的シナリオが記録されており、
動的シナリオは、プレイリスト情報に示される１つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、
前記再生制御手段は、
その動的シナリオに対応するタイトルの識別情報を有したインターリーブユニット、
その動的シナリオに対応するタイトル中のチャプターの識別情報を有したインターリーブユニット、
の何れかを光ディスクから読み出すよう読出手段を制御する
ことを特徴とする請求項３１記載の再生装置。
【請求項３４】
インターリーブユニットはロケータを含んでおり。
ロケータは、ドライブ情報と、パス情報とを含み、
ドライブ情報は、プログラム又はデータを読み出すべき読出先のドライブを示し、
パス情報は、そのドライブの階層構造のうち、この階層にプログラム又はデータが配すべきかを示し、
前記再生装置は、ロケータのドライブ情報に示されるドライブの階層構造のうち、パス情報に示される階層に、プログラム又はデータを配する
ことを特徴とする請求項１５記載の再生装置。
【請求項３５】
デジタルストリームを記録した光ディスクについての再生プログラムであって、
デジタルストリームを構成する複数セグメントのうちｉ番目セグメントを、ｉ番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出ステップと、
読み出されたｉ番目セグメントを再生する再生ステップと、
読み出されたインターリーブユニット内のプログラム又はデータを用いて、セグメント再生と同期した処理を行う処理ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項３６】
デジタルストリームを記録した光ディスクについての再生方法であって、
デジタルストリームを構成する複数セグメントのうちｉ番目セグメントを、ｉ番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出ステップと、
読み出されたｉ番目セグメントを再生する再生ステップと、
読み出されたインターリーブユニット内のプログラム又はデータを用いて、セグメント再生と同期した処理を行う処理ステップと
を有する再生方法。
【請求項３７】
光ディスクの記録方法であって、
アプリケーションデータを作成するステップと、
作成したデータを光ディスクに記録するステップとを有し、
前記アプリケーションデータは、デジタルストリームと、インターリーブユニットとを含み、
デジタルストリームは、ｎ個のセグメントに分割されて光ディスクに記録されており、
ｎ個のセグメントのうち、ｉ番目に再生されるものの前に、インターリーブユニットが記録され、
ここでｉ，ｎは、ｉ＜ｎを満たす整数であり、
インターリーブユニットは、ｉ番目のセグメントの再生に同期するプログラム、又は、
ｉ番目のセグメントの再生に同期して表示されるデータを含む。
ことを特徴とする記録方法。
【発明の詳細な説明】
【技術分野】  本発明は、Ｂｌｕ−Ｒａｙ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（以下ＢＤ−ＲＯＭと略す）等のデジタルストリーム用の光ディスク、光ディスクの再生装置、プログラム、再生方法、記録方法に関し、光ディスクにより映画作品等を頒布する技術に関する。
【背景技術】  光ディスクによる映画作品の頒布にあたっては、キャラクタについての映画作品と、キャラクタに関するゲームとを同じ光ディスクに記録して販売するというキャラクタビジネスがある。光ディスクに記録されるゲームは、クイズ形式の簡単なものから、三次元コンピュータ・グラフィックスを取り入れた本格的なものに発展する傾向がある。映画作品本編を構成するＡＶデータと同じ光ディスクに、ゲームプログラムのような非ＡＶデータを記録しておく先行技術には、以下の特許文献１に記載された技術がある。
＜特許文献１＞  特許３０６９３２４号公報
しかしながらコンピュータ・グラフィックスを用いた本格的なゲームは、動作のためにコンピュータ・グラフィックス描画のためのライブラリ等、様々なライブラリをメモリにロードしておき、アプリケーションプログラムに利用させる必要がある。そのためＤＶＤプレーヤ等の民生機器のハードウェアスペックでは、かかる動作環境を満足させることはできず、パソコン等の他の動作環境での使用をユーザに喚起せねばならない。そうなると、ゲーム等の実行にあたっては、「推奨メモリ：１２８Ｍバイト以上」というような動作環境での使用をユーザに求めることが多くなる。
たとえ本格的なゲームが記録されていたとしても、ゲームの動作環境が、映画作品本編の動作環境と著しくかけ離れているのなら、ユーザの消費欲を冷めさせてしまう恐れがある。これでは、多大な開発費用をかけてゲームを制作し、映画作品と同じ光ディスクに記録する意義がなくなってしまう。
【発明の開示】
本発明の目的は、ゲームを実現するようなプログラムを光ディスクに記録して頒布する場合に、そのプログラムの動作環境を、映画作品本編の動作環境に近づけることができる光ディスクを提供することである。
上記目的は、デジタルストリームを記録した光ディスクであって、デジタルストリームは、ｎ個のセグメントに分割されて光ディスクに記録されていて、ｎ個のセグメントのうち、第ｉ番目に再生されるものの前に、インターリーブユニットが記録されており、ここでｉ，ｎは、ｉ＜ｎを満たす整数であり、インターリーブユニットは、第ｉ番目のセグメントの再生に同期するプログラム、又は、第ｉ番目のセグメントの再生に同期して表示されるデータを含む光ディスクにより達成される。
セグメント再生と同期実行すべきプログラムはインターリーブユニットという形でセグメントの前に配置されており、セグメントの再生時にあたっては光ピックアップによる読み取り位置をセグメントの先頭位置からずらせば、デジタルストリームを構成するセグメントを、同期実行すべきプログラムと共に読み出すことができる。同期処理に必要なプログラムは、セグメントの読み出し時にセグメントと併せて光ディスクから読み出せば足り、セグメントとの同期処理が済めば、メモリから削除すればよいので、デジタルストリーム再生の全区間を通じてプログラムを常駐しておく必要はない。デジタルストリームとの同期処理を行うべきプログラムが複数あっても、個々のプログラムの実行が終わる度に、プログラムからメモリを回収するという原則でリソース管理を行えば、セグメント再生との同期時に、プログラムをロードし得るだけのメモリを再生装置に実装しておけばよい。必要最低限のメモリ規模で、デジタルストリーム再生と、様々なプログラムとの同期処理を実現することができる。
ここでインターリーブユニットは終了時点情報を含み、終了時点情報は、デジタルストリームの再生時間軸上におけるどの時点でメモリに読み出されたプログラム又はデータを削除するかを示していてもよい。
インターリーブユニットにおける終了時点情報の設定により、インターリーブユニットを何時からメモリに読み込み、何時までにインターリーブユニットをメモリから削除するかというリソース管理を、光ディスクのプレオーサリングの段階で決めておくことができる。これに基づくプログラミングを行えば、デジタルストリームにおけるＡＶ再生との同期を行うようなゲームソフトを、小メモリ規模で実現することができる。ソフトハウスのプログラマにとって、ＡＶ再生との同期を小メモリ規模で実現できる動作環境は魅力的であり、多くのソフトハウスの参入を促すことにより映画業界や民生機器業界を活性化することができる。
インターリーブユニットは開始時点情報を含み、開始時点情報は、インターリーブユニット内に含まれるプログラム又はデータの利用が、デジタルストリームの再生時間軸上におけるどの時点から、可能になるかを示していてもよい。
たとえ３つのライブラリが光ディスク上でバラバラに配置されたとしても、これらを同じ時点で利用可能とするよう、ヘッダにおける開始時点情報で調整することができる。
ここで第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されていてもよい。
第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、プログラム又はデータの生存区間の途中にあたる位置であってもよい。
セグメントのうち、再生区間の開始点等頭出しが多く発生しうる位置の後にインターリーブユニット複製物を配置しておけば、セグメント前に配置されているインターリーブユニットまでディスクシークを行わなくとも、アプリケーションプログラムによるライブラリ利用が可能となる。再生経路情報に基づく再生を行うため頭出しが多く発生したとしても、スムーズな読み取りが可能となる。
ここで第ｉ番目のセグメントと、第ｉ＋１番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあたる位置であってもよい。
デジタルストリームの再生時間軸を未来から過去に遡って行き、プログラムの生存区間に到達した場合でも、不要なシークを行うことなく光ディスクからメモリへのプログラム読み出しを実現することができる。逆方向再生のような変則的な再生進行が行われる場合でも、メモリへのプログラム読み出しを実現出来るので、ＡＶ再生との同期を前提とした様々なな処理を、逆方向再生時でも実現することができる。
ここで前記光ディスクにはプレイリスト情報、動的シナリオが記録されており、プレイリスト情報は、動画データにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、動的シナリオは、１つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、インターリーブユニットは、識別情報を有しており、識別情報は、再生経路、再生区間、映像タイトル全体、映像タイトルの章の何れかを、プログラム又はデータの生存区間として示していてもよい。
動的シナリオ、プレイリスト情報の番号等を用いて生存区間を定義しているので、インターリーブユニット同士の生存区間の重なりの把握が容易となり、リソース管理を念頭においたインターリーブユニットの読み取り計画が立て易くなる。
【図面の簡単な説明】  図１は、本発明に係る光ディスクの使用行為についての形態を示す図である。
図２は、ＢＤ−ＲＯＭの構成を示す図である。
図３は、ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマットを表現した図である。
図４は、機能的な観点から、ファイルを分類した場合の分類図である。
図５は、ＢＤ−ＲＯＭが対象としているソフトウェアのレイアモデルを示す図である。
図６は、ＡＶストリームがどのように構成されているかを模式的に示す図である。
図７は、ＡＶストリームがどのようにＢＤ−ＲＯＭに記録されるかを模式的に示す図である。
図８は、ストリーム管理情報の内部構成を示す図である。
図９は、ＰＬ情報の内部構成を示す図である。
図１０は、ＰＬ情報による間接参照を模式化した図である。
図１１は、図１０に示したＰＬとは、別のＰＬを定義する場合の一例を示す図である。
図１２は、レイヤモデルの第４層（動的シナリオ）における再生モードを示す図である。
図１３は、Ｊａｖａ言語が対象とする制御ソフトウェアのレイアモデルを示す図である。
図１４は、生存区間設定の対象となるＡＶストリームを示す図である。
図１５（ａ）は、ＢＤ−ＲＯＭに対しセグメントがどのように記録されるかを示す図である。
図１５（ｂ）は、セグメントｉ、セグメントｉ＋１を順次読み出す場合の、光ピックアップによる読み出し経路を示す。
図１６は、セグメントｉ＋１内に頭出しが発生した場合の光ピックアップの移動経路を示す図である。
図１７は、ＡＶストリームの再生時間軸上の４つの時点ｔ１，ｔ２，ｔ３，ｔ４においてメモリへのライブラリの読み出し、及び、Ｊａｖａ仮想マシンのワーク領域へのライブラリロードがどのように行われるかを示す図である。
図１８は、インターリーブユニットの構成を示す図である。
図１９は、ＴＭＡＰにおけるＡＣＣＥＳＳ  ＵＮＩＴエントリーの改良を示す図である。
図２０は、ＡＶストリームを構成するセグメントが読み取られる際のトラックバッファの状態遷移を示す図である。
図２１は、映画作品の動画を背景画とし、コンピュータ・グラフィックスを前景画とした合成画面から構成されるゲームプログラムを示す図である。
図２２（ａ）は、ライブラリ＃１，＃２，＃３，＃４の生存区間を示す図である。
図２２（ｂ）は、各ライブラリの生存区間のＩＮ点と、セグメントとの関係を示す図である。
図２３は、ＢＤ−ＲＯＭに対し、セグメントがどのように記録されているかを示す図である。
図２４は、インターリーブユニットの内部構成を示す図である。
図２５は、本発明に係る再生装置の内部構成を示す図である。
図２６は、再生制御エンジン１２の実行手順を示すフローチャートである。
図２７は、図２５に示した構成要素のうち、ライブラリに係るものを抜き出して描いた図である。
図２８は、Ｊａｖａ言語が対象とするレイアモデルにおいて、表示用データが何処に位置するかを示す図である。
図２９は、表示用データたるインターリーブユニットの構成を示す図である。
図３０は、再生装置内部における表示用データが表示に至るまでの経路を示す。
図３１は、セグメント内部のどこに、インターリーブユニット複製物を組み込むかを示す図である。
図３２は、セグメントｉの内部に対して頭出しを行う場合、プログラムがどのように読み取られるかを示す図である。
図３３は、図２２に示した４つのライブラリ＃１，＃２，＃３，＃４と、セグメントとの関係を示す図である。
図３４（ａ）は、インターリーブユニット、セグメント、インターリーブユニット複製物の配置を示す図である。
図３４（ｂ）は、図３４（ａ）に、ｉ＋１番目のセグメントを書き加えた図である。
図３５は、インターリーブユニット複製物がない場合に逆方向再生がどのように行われるかを示す図である。
図３６は、インターリーブユニット複製物が配置されたＢＤ−ＲＯＭにおけるシーク動作を示す図である。
図３７は、図２２に示した４つのライブラリ＃１，＃２，＃３，＃４と、セグメントとの関係を示す図である。
図３８は、ユーザにより逆方向再生操作が命じられた際の再生制御エンジン１２の処理手順を示すフローチャートである。
図３９は、第５実施形態に係るＢＤ−ＲＯＭのファイル構成を示す図である。
図４０は、ＰＬＭａｒｋ及びＣｌｉｐＭａｒｋの共通構成を示す図である。
図４１（ａ）（ｂ）は、プレイリスト＃１の再生中に出現するＴｉｍｅＥｖｅｎｔを定義する場合のＰＬＭａｒｋの記述例を示す図である。
図４２は、プレイリスト＃１の再生中においてＵｓｅｒＥｖｅｎｔを定義する場合のＰＬＭａｒｋの記述例を示す図である。
図４３は、ＣｌｉｐＭａｒｋ、ＰＬにてＴｉｍｅＥｖｅｎｔ、ＵｓｅｒＥｖｅｎｔが定義されている場合のインターリーブユニットの配置例を示す図である。
図４４は、再生制御エンジン１２の処理手順を示す図である。
図４５は、インターリーブユニットに関する情報の間接参照がどのように行われるかを示す図である。
図４６は、ＡＶストリームに組み込まれた３つのインターリーブユニットと、インターリーブユニット統合情報との対応を示す図である。
図４７は、第７実施形態に係るインターリーブユニットにて、生存区間がどのように表記されるかを示す図である。
図４８は、ロケータの記述によるプログラム又は表示用データの階層化配置を模式的に示す図である。
図４９は、第９実施形態に係る再生装置の内部構成を示す図である。
図５０は、第１１実施形態に係るＢＤ−ＲＯＭの製造工程を示すフローチャートである。
図５１は、複数の表示用データを格納したインターリーブユニットを示す図である。
【発明を実施するための最良の形態】  （第１実施形態）
以降、本発明に係る光ディスクの実施形態について説明する。先ず始めに、本発明に係る光ディスクの実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る光ディスクの、使用行為についての形態を示す図である。図１において、本発明に係る光ディスクは、ＢＤ−ＲＯＭ１００である。このＢＤ−ＲＯＭ１００は、再生装置２００、テレビ３００、リモコン４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
続いて本発明に係る光ディスクの実施行為のうち、生産行為についての形態について説明する。本発明に係る光ディスクは、ＢＤ−ＲＯＭの応用層に対する改良により実施することができる。図２は、ＢＤ−ＲＯＭの構成を示す図である。
図２は、ＢＤ−ＲＯＭの構成を示す図である。本図の第４段目にＢＤ−ＲＯＭを示し、第３段目にＢＤ−ＲＯＭ上のトラックを示す。本図のトラックは、ＢＤ−ＲＯＭの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。図２に示すようなデータフォーマットを、ＢＤ−ＲＯＭの応用層上に形成することにより本発明に係る光ディスクは、工業的に生産される。
図３は、ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット（アプリケーション）を表現した図である。本図に示すようにＢＤ−ＲＯＭには、ＲＯＯＴディレクトリの下にＢＤ−ＡＶディレクトリがあり、その下にＪＣＬＡＳＳディレクトリ、ＢＲＯＷＳＥＲディレクトリがある。
ＢＤＡＶディレクトリの配下には、ＩＮＦＯ．ＢＤ，ＸＸＸ．Ｍ２ＴＳ，ＸＸＸ．ＣＬＰＩ，ＹＹＹ．ＰＬ，ＺＺＺ．ＭＯＶＩＥといったファイルが存在する。ＪＣＬＡＳＳディレクトリの配下には、ＺＺＺ．ＣＬＡＳＳというファイルが、ＢＲＯＷＳＥＲディレクトリの配下には、ＺＺＺ．ＨＴＭというファイルが配置されている。
図４は、機能的な観点から、これらのファイルを分類した場合の分類図である。本図において、第１層、第２層、第３層、第４層からなる階層が本図における分類を象徴的に示す。本図においてＸＸＸ．Ｍ２ＴＳは第２層に分類される。ＸＸＸ．ＣＬＰＩ，ＹＹＹ．ＰＬは、第３層（静的シナリオ）に分類される。ＢＤＡＶディレクトリ配下のＺＺＺ．ＭＯＶＩＥ、ＪＣＬＡＳＳディレクトリ配下のＺＺＺ．ＣＬＡＳＳ、ＢＲＯＷＳＥＲディレクトリ配下のＺＺＺ．ＨＴＭは、第４層に分類される。
本図の分類（第１層〜第４層）は、図５に示すようなレイヤモデルを対象とした分類である。以降、図５を参照しながら、ＢＤ−ＲＯＭが対象としている、制御ソフトウェアのレイアモデルについて説明する。
図５の第１層は、物理層であり、処理対象たるストリーム本体の供給制御である。この第１層に示すように、処理対象たるストリームは、ＢＤ−ＲＯＭだけではなく、ＨＤ、メモリカード、ネットワークといったあらゆる記録媒体、通信媒体を供給源としている。これらＨＤ、メモリカード、ネットワークといった供給源に対する制御（ディスクアクセス、カードアクセス、ネットワーク通信）が第１層の制御である。
第２層は、復号化方式のレイアである。第１層で供給されたストリームを、どのような復号化方式を用いて復号するのかを規定しているのがこの第２層である。本実施形態で採用する復号化方式は、ＭＰＥＧ２の復号化方式である。
第３層（静的シナリオ）は、ストリームの静的なシナリオを規定するレイアである。静的なシナリオとは、ディスク制作者によって予め規定された再生経路情報、ストリーム管理情報であり、これらに基づく再生制御を規定しているのがこの第３層（静的シナリオ）である。
第４層は、ストリームにおける動的なシナリオを実現するレイヤである。動的なシナリオとは、ユーザ操作や装置の状態によって再生進行を動的に変化させるためのシナリオであり、これらに基づく再生制御を規定しているのがこの第４層である。以降、このレイヤモデルに従い、ストリーム本体、静的なシナリオにあたるファイルについて説明してゆく。
先ず第２層に属するストリーム（ＸＸＸ．Ｍ２ＴＳ）について説明する。
ＡＶストリーム（ＸＸＸ．Ｍ２ＴＳ）は、ＭＰＥＧ−ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）形式のデジタルストリームであり、ビデオストリーム、１つ以上のオーディオストリーム、１つ以上の副映像ストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、副映像ストリームは、映画の字幕をそれぞれ示している。図６は、ＡＶストリームがどのように構成されているかを模式的に示す図である。
ＡＶストリームは（第４段目）、複数のビデオフレーム（ピクチャｐｊ１，２，３）からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを（第１段目）、ＰＥＳパケット列に変換し（第２段目）、更にＴＳパケット列に変換し（第３段目）、同じく副映像ストリーム（第７段目）を、ＰＥＳパケット列に変換し（第６段目）、更にＴＳパケット列に変換して（第５段目）、これらを多重化することで構成される。この多重化は、オーディオフレームが、同じ時刻にＢＤ−ＲＯＭから読み出されるべきビデオフレームの近くにくるように、ビデオフレームを格納したＴＳパケット、オーディオフレームを格納したＴＳパケットを並べるというものである。
かかる過程を経て生成されたＡＶストリームは、通常のコンピュータファイル同様、複数のセグメントに分割され、ＢＤ−ＲＯＭ上の領域に記録される。図７はＡＶストリームがどのようにＢＤ−ＲＯＭに記録されるかを模式的に示す図である。
ＡＶストリームを構成する各セグメントが、どれだけの長さであり、ＢＤ−ＲＯＭにおいてどのアドレスに記録されているかは、ファイル管理情報ｆｋ１に記述される。
ファイル管理情報ｆｋ１には、ＡＶストリームを分割することで得られる３つのセグメント１／３，２／３，３／３のそれぞれについて、セグメントのアドレス（ａｄｒ１，２，３）、長さ（ｌｅｎｇｔｈ１，２，３）が記述されていることがわかる。ＡＶストリームは、１つ以上のＡＣＣＥＳＳ  ＵＮＩＴとからなり、このＡＣＣＥＳＳ  ＵＮＴＴの単位で頭出し可能である。ＡＣＣＥＳＳ  ＵＮＩＴとは、１つのＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅ）と、このＧＯＰと同時に読み出されるべきオーディオフレームとを含む最小デコード単位である。ＧＯＰは、過去方向および未来方向に再生されるべき画像との時間相関特性を用いて圧縮されているＢｉｄｉｒｅｃｔｉｏｎａｌｌｙ  ｐｒｅｄｉｃｔｉｖｅ  Ｐｒｅｄｉｃｔｉｖｅ（Ｂ）ピクチャ、過去方向に再生されるべき画像との時間相関特性を用いて圧縮されているＰｒｅｄｉｃｔｉｖｅ（Ｐ）ピクチャ、時間相関特性を用いず、一フレーム分の画像内での空間周波数特性を利用して圧縮されているＩｎｔｒａ（Ｉ）ピクチャを含む。
尚、ファイル名ＸＸＸ．Ｍ２ＴＳのファイルボディ「ＸＸＸ」は、ＢＤ−ＲＯＭにおいてＡＶストリームに付与される３桁の識別番号を抽象化している。つまり本図におけるＡＶストリームは、このＸＸＸを用いて一意に識別される。以上がストリーム（ＸＸＸ．Ｍ２ＴＳ）についての説明である（ここでの３桁という桁数は例示に過ぎず、何桁でもよい。）。
＜静的なシナリオ＞
続いて、静的なシナリオであるファイル（ＸＸＸ．ＣＬＰＩ，ＹＹＹ．ＰＬ）について説明する。
ストリーム管理情報（ＸＸＸ．ＣＬＰＩ）は、個々のＡＶストリームについての管理情報である。図８は、ストリーム管理情報の内部構成を示す図である。ＡＶストリームはビデオストリーム、オーディオストリームを多重化することで得られ、ＡＶストリームはＡＣＣＥＳＳ  ＵＮＩＴと呼ばれる単位での頭出しが可能なので、各ビデオストリーム、オーディオストリームはどのような属性をもっているか、頭出し位置がＡＶストリーム内の何処に存在するかが、ストリーム管理情報の管理項目になる。図中の引き出し線はストリーム管理情報の構成をクローズアップしている。引き出し線ｈｎ１に示すように、ストリーム管理情報（ＸＸＸ．ＣＬＰＩ）は、ビデオストリーム、オーディオストリームについての「属性情報」と、ＡＣＣＥＳＳ  ＵＮＩＴを頭出しするためのリファレンステーブルである「ＴＭＡＰ」とからなる。
属性情報（Ａｔｔｒｉｂｕｔｅ）は、破線の引き出し線ｈｎ２に示すようにビデオストリームについての属性情報（Ｖｉｄｅｏ属性情報）、属性情報数（Ｎｕｍｂｅｒ）、ＡＶストリームに多重化される複数オーディオストリームのそれぞれについての属性情報（Ａｕｄｉｏ属性情報＃１〜＃ｍ）からなる。ビデオストリームについての管理情報は、破線の引き出し線ｈｎ３に示すようにそのビデオストリームがどのような圧縮方式で圧縮されたか（Ｃｏｄｉｎｇ）、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか（Ｒｅｓｏｌｕｔｉｏｎ）、アスペクト比はどれだけであるか（Ａｓｐｅｃｔ）、フレームレートはどれだけであるか（Ｆｒａｍｅｒａｔｅ）を示す。
一方、オーディオストリームについての属性情報（Ａｕｄｉｏ属性情報＃１〜＃ｍ）は、破線の引き出し線ｈｎ４に示すようにそのオーディオストリームがどのような圧縮方式で圧縮されたか（Ｃｏｄｉｎｇ）、そのオーディオストリームのチャネル番号が何であるか（Ｃｈ．）、何という言語に対応しているか（Ｌａｎｇ）を示す。
タイムマップ（ＴＭＡＰ）は、複数の頭出し位置のアドレスを、時刻情報を用いて間接参照するためのリファレンステーブルであり、破線の引き出し線ｈｎ５に示すように複数のエントリー情報（ＡＣＣＥＳＳ  ＵＮＩＴ＃１エントリー情報、ＡＣＣＥＳＳ  ＵＮＩＴ＃２エントリー情報、ＡＣＣＥＳＳ  ＵＮＩＴ＃３エントリー情報・・・・・）と、エントリー情報数（Ｎｕｍｂｅｒ）とからなる。各エントリー情報は、引き出し線ｈｎ６に示すように、対応するＡＣＣＥＳＳ  ＵＮＩＴの再生時間（Ｄｕｒａｔｉｏｎ）と、対応するＡＣＣＥＳＳ  ＵＮＩＴのデータサイズ（Ｓｉｚｅ）とを対応づけてなる。可変長符号圧縮方式が採用されるため、ＧＯＰを含む各ＡＣＣＥＳＳ  ＵＮＩＴのサイズや再生時間がバラバラであっても、この『エントリー情報』を参照することにより、任意の再生時刻から、その再生時刻に対応するＡＣＣＥＳＳ  ＵＮＩＴ内のピクチャデータへと頭出しを行うことが可能になる。尚、ファイル名「ＸＸＸ．ＣＬＰＩ」のファイルボディ「ＸＸＸ」は、ストリーム管理情報が対応しているＡＶストリームと同じ名称が使用される。つまり本図におけるＡＶストリームのファイルボディはＸＸＸであるから、ＡＶストリーム（ＸＸＸ．Ｍ２ＴＳ）に対応していることを意味する。以上がストリーム管理情報についての説明である。続いてプレイリスト情報について説明する。
ＹＹＹ．ＰＬ（プレイリスト情報）は、再生経路であるプレイリストを構成するテーブルであり、ＣｅｌｌＬｉｓｔからなる。図９は、ＰＬ情報の内部構成を示す図である。
ＣｅｌｌＬｉｓｔは、複数のＣＥＬＬ情報（ＣＥＬＬ情報＃１，＃２，＃３・・・＃ｎ）と、これらＣＥＬＬ情報数（Ｎｕｍｂｅｒ）とからなる。セル情報は、ポインタ情報であり、プレイリストを構成する１つ以上の論理的な再生区間を定義する。セル情報の構成は、引き出し線ｈｓ１によりクローズアップされている。この引き出し線に示すようにセル情報は、再生区間のＩｎ点及びＯｕｔ点が属するＡＶストリームの名称を示す『Ｓｔｒｅａｍ  Ｎａｍｅ』と、再生区間の始点を示す情報『ＩＮ点情報』と、再生区間の終点を示す情報『Ｏｕｔ点情報』とから構成される。
セル情報の特徴は、その表記法にある。つまりタイムマップをリファレンステーブルとして用いた間接参照の形式で、再生区間が定義されている。図１０は、ＰＬ情報による間接参照を模式化した図である。本図においてＡＶストリームは、複数のＡＣＣＥＳＳ  ＵＮＩＴから構成されている。ストリーム管理情報内のＴＭＡＰは、これら複数ＡＣＣＥＳＳ  ＵＮＩＴのセクタアドレスを、矢印ａｙ１，２，３，４に示すように指定している。図中の矢印ｊｙ１，２，３，４は、ＣＥＬＬ情報によるＡＣＣＥＳＳ  ＵＮＩＴの参照を模式化して示している。つまり、ＣＥＬＬ情報による参照（矢印ｊｙ１，２，３，４）は、ＴＭＡＰを介することにより、ＡＶストリーム内に含まれる複数ＡＣＣＥＳＳ  ＵＮＩＴのアドレスを指定するという間接参照であることがわかる。
ＣＥＬＬ情報−ストリーム管理情報−ＡＶストリームの組みからなるＢＤ−ＲＯＭ上の再生区間を『セル』という。ＰＬ情報−ストリーム管理情報−ＡＶストリームの組みからなるＢＤ−ＲＯＭ上の論理的な再生単位を『プレイリスト（ＰＬと略す）』という。ＢＤ−ＲＯＭに記録された映画作品は、この論理的な再生単位（ＰＬ）にて構成される。論理的な再生単位にて、ＢＤ−ＲＯＭにおける映画作品は構成されるので、本編たる映画作品とは別に、あるキャラクタが登場するようなシーンのみを指定するようなＰＬを定義すれば、そのキャラクタが登場するシーンのみからなる映画作品を簡単に制作することができる。図１１は、図１０に示したＰＬ情報（ＰＬ情報＃１）とは、別のＰＬ（ＰＬ情報＃２）を定義する場合の一例を示す図である。
様々なＰＬ情報を定義するだけで、映画作品のバリエーションは増えるので、映画制作者の表現の幅を増やせることが、静的なシナリオの最大のメリットである。
また、ＢＤ−ＲＯＭにおける再生単位には、ＰＬ、ＣＥＬＬといったものの他、Ｃｈａｐｔｅｒがある。Ｃｈａｐｔｅｒは、１つ、２つ以上のＣＥＬＬから構成される。
尚、ＰＬ情報のファイル名におけるファイルボディＹＹＹは、ＢＤ−ＲＯＭにおいてＰＬ情報に付与される３桁の識別番号を抽象化している。つまり本図におけるＰＬ情報は、この識別番号ＹＹＹを用いて一意に識別される。ＰＬ情報の識別番号を”ＹＹＹ”と表現しているのは、ＰＬ情報の識別番号が、ＡＶストリーム及びＡＶストリーム管理情報の識別番号ＸＸＸとは別の番号体系であることを意味している（ここでの３桁という桁数は例示に過ぎず、何桁でもよい。）。
以上が、静的なシナリオについての説明である。続いて動的なシナリオについて説明する。
＜動的なシナリオ＞
続いて動的シナリオ「ＺＺＺ．ＭＯＶＩＥ」，「ＺＺＺ．ＨＴＭ」，「ＺＺＺ．ＣＬＡＳＳ」について説明する。動的なシナリオは、ＡＶストリームの再生制御手順を示す。動的なシナリオによる再生制御手順は、装置に対するユーザ操作に応じて変化するものであり、プログラム的な性質をもつ。ここでの動的な再生制御には、２つのモードがある。２つのモードのうち１つは、ＡＶ機器特有の再生環境で、ＢＤ−ＲＯＭに記録された動画データを再生するモード（ノーマルモード）であり、もう１つはＢＤ−ＲＯＭに記録された動画データの付加価値を高めるモード（エンハンスドモード）である。図１２は、レイヤモデルの第４層における再生モードを示す図である。本図において第４層には、１つのノーマルモードと、２つのエンハンスドモードとが記述されている。１つのノーマルモードは、ＤＶＤライクな再生環境での再生モードでありＭＯＶＩＥモードと呼ばれる。２つのエンハンスドモードのうち、１つ目は、Ｊａｖａ仮想マシンを主体とした再生モードであり、Ｊａｖａモードと呼ばれる。２つ目のエンハンスドモードのうち、２つ目はブラウザを主体とした再生モードであり、Ｂｒｏｗｓｅｒモードと呼ばれる。
尚、ファイル名ＺＺＺ．ＭＯＶＩＥ、ＺＺＺ．ＣＬＡＳＳ、ＺＺＺ．ＨＴＭにおけるファイルボディ「ＺＺＺ」は、ＢＤ−ＲＯＭにおいて動的シナリオに付与される３桁の識別番号を抽象化している。つまり本図におけるシナリオは、この識別番号ＺＺＺを用いて一意に識別される。シナリオの識別番号を”ＺＺＺ”と表現しているのは、シナリオの識別番号が、ＡＶストリームの識別番号ＸＸＸ、ＰＬ情報の識別番号ＹＹＹとは別の番号体系であることを意味している（ここでの３桁という桁数は例示に過ぎず、何桁でもよい。）。
以降各モードの動的シナリオについてより詳しく説明する。
「ＺＺＺ．ＭＯＶＩＥ」は、ＭＯＶＩＥモードを対象とした動的シナリオである。この動的シナリオでは、既存のＤＶＤ再生装置と良く似た再生制御を再生装置に実行させることができる。
「ＺＺＺ．ＨＴＭ」は、Ｂｒｏｗｓｅｒモードを対象とした動的シナリオである。この動的シナリオでは、ネットワーク上のサイトをアクセスしたり、ファイルをダウンロードするような制御手順を記述することができる。
「ＺＺＺ．ＣＬＡＳＳ」は、Ｊａｖａモードを対象とした動的シナリオであり、Ｊａｖａ言語のアプリケーションプログラムである。Ｊａｖａ言語のアプリケーションプログラムなのでＪａｖａモードの動的シナリオの実行主体は、Ｊａｖａプラットフォームとなる。ここでＪａｖａモードのアプリケーションと、Ｊａｖａプラットフォームとの関係を図１３を参照しながら詳しく説明する。図１３は、Ｊａｖａ言語が対象とするＪａｖａプラットフォームのレイアモデルを示す図である。Ｊａｖａモードのアプリケーションは、このレイヤモデルの最上位のレイアに位置する。このＪａｖａモードのアプリケーションの下位にＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｒｆａｃｅ）がある。更にその下位のレイアにＪａｖａプラットフォームがある。ネイティブ描画系は、再生装置が本来具備しているイメージ描画機能であり、Ｊａｖａプラットフォームと同一階層にあたる。
Ｊａｖａプラットフォームは、「Ｊａｖａ仮想マシン（ＪａｖａＶＭ）」、「コンフィグレーション」、「プロファイル」、「オプション」からなる。Ｊａｖａ仮想マシンは、Ｊａｖａ言語で記述されたＪａｖａモードアプリケーションを、再生装置におけるＣＰＵのネイティブコードに変換して、ＣＰＵに実行させる。コンフィグレーションは、再生装置における簡単な入出力を実現する。プロファイルは、再生装置におけるＩＰ通信や、画面描画を行う。
「オプション」は、様々なライブラリを含む。これらはＪａｖａプラットフォームからは供給され得ない様々な機能をＪａｖａモードのアプリケーションに供給するものである。具体的にいえば、再生装置におけるセキュリティ確保の処理やＢＤ−ＲＯＭ〜Ｊａｖａアプリケーション間の入出力がこのライブラリで規定されることになる。
再生装置においてＪａｖａ仮想マシン、コンフィグレーション、プロファイル及びネイティブ描画系は、再生装置に予めインプリメントされる。また図１２に示した第１層〜第３層の制御ソフトウェアも再生装置に予めインプリメントされる。しかしオプションは、ＢＤから読み出させねばならい。何故なら、Ｊａｖａモードのアプリケーションが必要とするオプションは、様々なものがあり、これらの全てを再生装置に予めインプリメントしておくことは困難だからである。以上がＪａｖａプラットフォームについての説明である。
インターリーブユニット「ＩＬＵｓｓｓ．ＣＬＡＳＳ」は、インターリーブ記録されたファイルであり、プログラムやライブラリを格納している。「ＩＬＵｓｓｓ．ＣＬＡＳＳ」におけるプログラムは、アプリケーション固有の処理を記述したバイトコード列であり、アプリケーションの主体となる。ライブラリとは、部品化されたプログラムであり、様々なアプリケーションにより利用されうるバイトコード列である。
以降、ライブラリについて詳しく説明する。本実施形態におけるライブラリは、ＡＶストリーム（ＰＬ）の再生時間軸上に生存区間をもつ。生存区間とは、アプリケーションによるライブラリの利用が可能となるＡＶストリーム（ＰＬ）の再生時間軸上の一期間をいう。
アプリケーションによるライブラリ利用とは、アプリケーションからの関数呼出に従い、ライブラリに含まれる関数をＪａｖａ仮想マシンに実行させることである。Ｊａｖａ仮想マシンにライブラリを実行させるには、大きな前提条件がある。その前提条件とは、ライブラリをＪａｖａ仮想マシン内のワーク領域（ヒープ領域）にロードしておくことである。そのため、ライブラリ利用にあたってアプリケーションプログラムは、再生装置内のキャッシュメモリからＪａｖａ仮想マシンのワーク領域へのロードを命じておく必要がある。ここでＢＤ−ＲＯＭに記録されているファイルが、ＢＤ−ＲＯＭから再生装置内のキャッシュメモリに予め読み込まれていれば、上述したロード命令は正常終了することになる。一方ライブラリが再生装置内のキャッシュメモリに読み込まれていなければ、アプリケーションプログラムによるロード命令は例外終了（エラー終了）することになる。ロード命令の正常終了を期待するなら、ライブラリファイルは、再生装置内のキャッシュメモリに読み出しておくことが望ましい。そうしておけば再生装置内メモリにおけるライブラリをＪａｖａ仮想マシン内のワーク領域に何時でもロードすることができるからである。
ここでライブラリの生存区間を定めるということは、ライブラリを再生装置内のキャッシュメモリに読み出しておくことと等価であると考えることができる。しかしＢＤ−ＲＯＭ再生装置のような民生機器のハードウェアスペックでは、メモリが小規模であり、利用され得るライブラリが複数であれば、各ライブラリについての生存区間を必要最低限にしなければならない。
ここで生存区間をどのように決めるべきかについて説明する。図１４は、生存区間設定の対象となるＡＶストリームを示す図である。ＡＶストリームの再生と同期するようなゲームアプリのプログラミングにあたっては、特定の映像が、出現している等の理由でアプリケーションプログラムによるライブラリ利用が多く予想される期間を生存区間に定めることが望ましい。様々なライブラリの実行を、ＡＶストリームの再生と同期させることができるからである。例えば図１４のＡＶストリームは、本来映画作品を構成するものであり、人物同士の会話のシーンや、街並みを撮影したようなシーン等様々なシーンが含まれている。このうち街並みを撮影したようなシーンは、ゲームアプリケーションがコンピュータ・グラフィックスを描画するにあたって、背景画に利用される可能性が極めて高い。このようにゲームアプリによる利用の可能性が高いＡＶストリーム上の一期間をライブラリの生存区間に定め、この生存区間において、再生装置のメモリにライブラリを読み出せるようにしておく。そうするとアプリケーションプログラムがロードを命じた場合、確実にワーク領域にライブラリをロードすることができる。以上のことを考慮すれば、生存区間を決めるにあたっては、アプリケーションプログラムの背景画として使用したいシーン等、ライブラリを同期させたいシーンがＡＶストリームの再生時間軸上において何時出現するかを、プレオーサリングの段階で明らかにしておくことが必要となる。そして、ライブラリ同士の生存区間重複がなるべく発生しないように、各ライブラリの生存区間を定めることも、生存区間決定にあたっての責務となる。以上がライブラリの生存区間についての説明である。
続いてライブラリの記録形態であるインターリーブ記録について説明する。インターリーブ記録とは、ＢＤ−ＲＯＭに記録されるべき客体をＡＶストリームを構成する複数セグメントの合間に記録するというものである。図７でいえば、「他のファイル」にあたる箇所に客体を記録しようとするのがインターリーブ記録である。ここでインターリーブ記録される客体を”インターリーブユニット”という。インターリーブ記録される客体がライブラリである場合、インターリーブユニットたるライブラリはどのように記録されるかを以下に説明する。ライブラリがインターリーブユニットである場合、インターリーブユニットはライブラリの生存区間のＩＮ点を含むセグメントの直前に記録される。図１５（ａ）は、ＢＤ−ＲＯＭに対しセグメントがどのように記録されるかを示す図である。ＡＶストリームが複数のセグメントに分割されて、そのうちセグメントｉ＋１があるライブラリ＃ｘの生存区間ＩＮ点を含んでいる場合、そのライブラリ＃ｘを含むインターリーブユニットはセグメントｉ＋１の直前に記録される。このように生存区間ＩＮ点を含むセグメントの直前に、記録されるというのがインターリーブユニットの特徴である。
インターリーブユニット＃ｘ、セグメントｉは、図１５（ａ）のように記録されているため、セグメントの読み出しは図１５（ｂ）に示すように行われる。図１５（ｂ）は、セグメントｉ、セグメントｉ＋１を順次読み出す場合の、光ピックアップによる読み出し経路を示す。セグメントｉを読み込んだ後、本来なら光ピックアップは破線の矢印ｓｆ１に示すようなシークを行い、セグメントｉ＋１を読み出さねばならない。セグメントｉ＋１の前にはインターリーブユニットが存在しており、このインターリーブユニットはセグメントｉ＋１の再生期間中に生存区間をもつライブラリを含んでいる。ｓｆ２は、先行するインターリーブユニット＃ｘが存在する場合の光ピックアップ読み出し位置であり、ｓｆ３は光ピックアップによるディスクスキャンを示す。このディスクスキャンｓｆ３によりインターリーブユニット＃ｘ、セグメントｉ＋１は、セグメントｉの読み出し後、シークを行うことなくそのまま連続的に読み取られることになる。
図１５（ｂ）は、１つのＡＶストリームを構成するセグメントを連続して読み取るものであった。続いて、ライブラリの生存区間を含むセグメント内へと頭出しが発生した場合、光ピックアップによる読み取りがどのように行われるかを図１６を参照しながら説明する。
図１６は、セグメントｉ＋１内に頭出しが発生した場合の光ピンクアップの移動経路を示す図である。図中の頭出し位置ａＰ１に光ピックアップを移動させる場合にあたって、セグメントｉ＋１に先行するインターリーブユニットの存否が判定される。（２）は、先行するインターリーブユニットが存在する場合の光ピックアップ読み出し位置であり、（３）は光ピックアップによるディスクスキャンを示す。セグメントに先行するインターリーブユニットが存在する場合、インターリーブユニット先頭からセグメントへの光ピックアップスキャンがなされてインターリーブユニット、セグメントが再生装置により読み出される。このように光ピックアップを移動させれば、光ピックアップによる一回のスキャン（３）にて、動画再生に必要なＡＣＣＥＳＳ  ＵＮＩＴと、このＡＣＣＥＳＳ  ＵＮＩＴに関連するライブラリとを一度に読み出すことができる。
インターリーブユニットという形態でライブラリが記録されるため、現在の再生時点が生存区間に入ったタイミングでライブラリは、メモリに読み出されることになる。そのため、生存区間内にアプリケーションプログラムがロード命令を発すれば、再生装置内のメモリからＪａｖａ仮想マシン内のワーク領域へのロードが確実に成功する。図１７は、ＡＶストリームの再生時間軸上の４つの時点ｔ１，ｔ２，ｔ３，ｔ４においてメモリへのライブラリの読み出し、及び、Ｊａｖａ仮想マシンのワーク領域へのライブラリロードがどのように行われるかを示す図である。
時点ｔ１は、ライブラリの生存区間外の時点である。生存区間外であるため、キャッシュメモリにはライブラリが読み出されていない。そのため、矢印ｐｙ１に示すようにアプリケーションプログラムがロード命令を発したとしてもライブラリをＪａｖａ仮想マシンワーク領域にロードすることはできず、ロードは矢印ｐｙ２に示すように例外終了することになる。
時点ｔ２はライブラリの生存区間ＩＮ点である。生存区間ＩＮ点に到達したため、矢印ｐｙ３に示すようにライブラリはメモリに読み出される。
時点ｔ３は、ライブラリの生存区間内であって、アプリケーションプログラムによりロードが命じられた時点である。メモリにはライブラリがロードされているので、矢印ｐｙ５に示すようなアプリケーションプログラムによるロード命令に応じてライブラリがＪａｖａ仮想マシンのワーク領域内にロードされることになる（矢印ｐｙ６）。これによりアプリケーションプログラムは、ライブラリ内の関数を自由に呼び出すことができる。
時点ｔ４は、ライブラリ生存区間である。生存区間ＯＵＴ点に達したため、ライブラリは矢印ｐｙ７に示すようにメモリから削除される。そのため以降アプリケーションプログラムからロードが命じられたとしても、時点ｔ０同様ロード命令は例外終了することになる。
続いてインターリーブユニットの内部構成について説明する。図１８は、インターリーブユニットの構成を示す図である。インターリーブユニットは、本図に示すようにヘッダと、本体部とからなる。本実施形態において本体部とはライブラリのことである。
ヘッダは、本体部にあたるライブラリがメモリにおいて何処に存在するかを示す『ロケータ』、本体部にあたるライブラリの生存区間のＩＮ点となる時点を示す『生存区間ＩＮ点情報』、本体部にあたるライブラリの生存区間のＯＵＴ点となる時点を示す『生存区間ＯＵＴ点情報』を含む。ロケータは、再生装置上のメモリにおいて、ライブラリを識別するために設けられる。ライブラリは、生存区間に関する情報が記述されたヘッダが付与され、インターリーブユニットという形態でＢＤ−ＲＯＭに記録されるのである。
『ロケータ』を設けることの技術的意義について以下に説明する。インターリーブユニットに含まれるライブラリを、キャッシュメモリ上において、Ｊａｖａディレクトリの配下にあるファイル「Ｊ００１．ＣＬＡＳＳ」として扱いたい場合、ロケータを「ＣＭ：／／Ｊａｖａ／Ｊ００１．ＣＬＡＳＳ」と記述する。このロケータにおける「ＣＭ：／／」とは、再生装置内部におけるインターリーブユニットの置き場所がキャッシュメモリであることを示す。一方再生装置内部におけるインターリーブユニットの置き場所がハードディスクであるなら、ロケータを「ＨＤ：／／」と記述すればよい。一方「Ｊａｖａ／Ｊ００１．ＣＬＡＳＳ」は、インターリーブユニットの置き場所のファイルパスである。再生装置は、インターリーブユニットの読み込みの際、キャッシュメモリ上にＪａｖａディレクトリと、ファイルＪ００１．ＣＬＡＳＳとをクリエイト又はオープンし、インターリーブユニット内のライブラリをＪａｖａディレクトリ配下のファイルＪ００１．ＣＬＡＳＳに格納しておく。こうすることでアプリケーションプログラムは、キャッシュメモリからＪａｖａ仮想マシン内ワーク領域へのライブラリ転送を命じる際、ファイルパス「Ｊａｖａ／Ｊ００１．ＣＬＡＳＳ」を用いてキャッシュメモリ上のライブラリを指定することができる。
『生存区間ＩＮ点情報』をインターリーブユニットヘッダに設けておくことの技術的意義について説明する。インターリーブユニットに含まれる生存区間の開始点は、原則ＡＶストリームの再生時間軸上において、そのライブラリがメモリ上に存在している時点となる。しかしヘッダにおける生存区間ＩＮ点情報は、このメモリ上に存在している時点とは別の時点を、記述することができる。これは以下のようなケースを想定しているためである。Ｊａｖａ言語におけるプログラミング作法には、３つのライブラリのうち１つのみがメモリがある状態でのアプリケーションプログラムによるライブラリの利用を許さず、３つのライブラリがメモリ上で揃ったときのみアプリケーションプログラムによるライブラリの利用を許すというものがある。ところがかかる３つのライブラリが３つのインターリーブユニットとしてＢＤ−ＲＯＭ上のバラバラの位置に記録された場合、３つのライブラリがメモリに読み込まれる時点は、ライブラリ毎に異なってくる。この場合３つのうち、１つ、２つがメモリ上にある状態でのアプリケーションプログラムによるライブラリ利用を禁じる必要があるので、各インターリーブユニットのヘッダにおける生存区間Ｉｎ点情報を、メモリ上で３つのライブラリが揃う時点に設定しておく。
そうすると、３つのライブラリのうち、１つ目、２つ目のものがメモリにロードされた時点ではライブラリは利用可能とならず、３つ目のライブラリがメモリにロードされた段階で初めて利用可能となる。たとえ３つのライブラリがＢＤ−ＲＯＭ上でバラバラに配置されたとしても、これらを同じ時点で利用可能とするよう、ヘッダにおける生存区間Ｉｎ点情報で調整することができる。
『生存区間ＯＵＴ点情報』をインターリーブユニットヘッダに設けておくことの技術的意義について説明する。上述したように、ＢＤ−ＲＯＭ再生装置のハードウェアスペックではメモリ規模は限られており、キャッシュメモリ上に様々なライブラリを格納しておこうとすると、ライブラリ同士の上書きが発生してハングアップを招く恐れがある。そのためには、生存区間が過ぎたライブラリは速やかにキャッシュメモリから削除することが必要になる。かかる削除を促すべく、生存区間のヘッダに『生存区間ＯＵＴ点情報』が記されている。以上がインターリーブユニットのヘッダについての説明である。
生存区間Ｉｎ点情報及び生存区間Ｏｕｔ点情報の表記について説明する。ここでＡＶストリームの再生時間軸とは、ＡＶストリームに多重化されるビデオストリーム、オーディオストリームを構成するビデオフレーム、オーディオフレームの個々の再生タイミング、ビデオフレームのデコードタイミングの基準となる時間軸である。かかる再生時間軸上の任意の位置は、ＡＶストリーム内の先頭ビデオフレームの時間情報を基準として、これとの相対値により表現される。かかる再生時間軸で再生タイミング、デコードタイミングが規定されているので、オーディオフレーム−ビデオフレーム間の同期再生が可能になる。生存区間のＩｎ点、Ｏｕｔ点も、再生時間軸上の一点と考えられるから、生存区間はビデオストリームの先頭ビデオフレームの時間情報を基準とした相対値で表現される。故に上述した生存区間Ｉｎ点情報及び生存区間Ｏｕｔ点情報は、ビデオストリームの先頭ビデオフレームの時間情報を基準とした相対値を用いて生存区間のＩｎ点、Ｏｕｔ点を指定している。
ＡＣＣＥＳＳ  ＵＮＩＴの頭出し時にあたって、ＡＣＣＥＳＳ  ＵＮＩＴ−インターリーブユニットを一度に読み出すには以下の改良が必要となる。それらの改良を以下に説明する。セグメントのうち、インターリーブユニットの直後にあたるＡＣＣＥＳＳ  ＵＮＩＴについては、ＴＭＡＰにおけるＡＣＣＥＳＳ  ＵＮＩＴのエントリーを図１９に示すように改変せねばならない。図１９は、ＴＭＡＰにおけるＡＣＣＥＳＳ  ＵＮＩＴエントリーの改良を示す図である。本図におけるＡＣＣＥＳＳ  ＵＮＩＴエントリーは、インターリーブユニットの直後にあたるＡＣＣＥＳＳ  ＵＮＩＴについて示している。本図において特徴的なのは、セグメントの先頭に位置するＡＣＣＥＳＳ  ＵＮＩＴ＃１０，＃２０，＃３０のエントリーに、インターリーブユニットのファイル名のファイルボディ（ＩＬＵ００１，ＩＬＵ００２，ＩＬＵ００３）が格納されている点である。このインターリーブユニットは、このセグメントに先行するインターリーブユニットである。かかるインターリーブユニットのファイル名を、ＡＣＣＥＳＳ  ＵＮＩＴエントリーに格納しておくことで、セグメント先頭のＡＣＣＥＳＳ  ＵＮＩＴと、インターリーブユニットとをまとめて読み込むとの処理を効率的に行うことができる。
尚、ＩＬＵｓｓｓ．ＣＬＡＳＳの「ｓｓｓ」は、ＢＤ−ＲＯＭにおいてインターリーブユニットに付与される３桁の識別番号を抽象化している。つまり本図におけるインターリーブユニットは、このｓｓｓを用いて一意に識別される。インターリーブユニットの識別番号を”ｓｓｓ”と表現しているのは、インターリーブユニットが、ＡＶストリーム及びＡＶストリーム管理情報の識別番号ＸＸＸ、プレイリスト情報の識別番号ＹＹＹ、動的シナリオの識別番号ＺＺＺとは別の番号体系であることを意味している（ここでの３桁という桁数は例示に過ぎず、何桁でもよい。）。
続いて、各セグメントにどれだけ連続長をもたせるかについて説明する。ＡＶストリームを分割して配置するとはいえ、ＡＶストリームの記録にあたっては、このセグメントが読み出されるバッファ（トラックバッファという）がアンダーフローしない長さに定めねばならない。図２０の上段は、ＡＶストリームを構成するセグメントの１つを示す図であり、ＢＤ−ＲＯＭの位置ａ１から位置ａ２までを占めている。図２０下段のグラフは、本セグメントが読み取られる際のトラックバッファの状態遷移を示す。このグラフの横軸は、時間軸であり、縦軸はトラックバッファの蓄積量を表す。このグラフにおける状態遷移は、Ｖａ−Ｖｂという増加率での単調増加と、−Ｖｂという減少率での単調減少とからなる。この単調増加は、時点ｔ１からｔ２までの期間であり、単調減少は、時点ｔ２からｔ３までの期間である。ここで時点ｔ１は、セグメントのうち、位置ａ１の読み込み時点を示し、時点ｔ２は、セグメントのうち、位置ａ１の読み込み時点を示す。時点ｔ３は次のセグメントの先頭位置ａ３の読み込み時点を示す。Ｖａはトラックバッファへの入力速度であり、Ｖｂはトラックバッファからの出力速度である。時点ｔ２におけるトラックバッファの蓄積量Ｂ（ｔ２）は、式１により現される。
Ｂ（ｔ２）  ＝  （Ｖａ−Ｖｂ）×（ｔ２−ｔ１）・・・・（式１）
セグメントの読出先たるトラックバッファが、かかる状態遷移を行う場合、アンダーフローを避けるには、式２に示すようにｔ１からｔ２までの増加量Ｂ（ｔ２）が、ｔ２からｔ３までの減少量Ｖｂ（ｔ３−ｔ２）を上回ればよい。式２を満たすように、セグメントの連続長を決めれば、トラックバッファはアンダーフローすることはない。
Ｂ（ｔ２）  ≧  Ｖｂ×（ｔ３−ｔ２）          ・・・・（式２）
以上が「ＩＬＵｓｓｓ．ＣＬＡＳＳ」に格納されたライブラリの説明である。続いて「ＩＬＵｓｓｓ．ＣＬＡＳＳ」に格納されるプログラムについて説明する。「ＩＬＵｓｓｓ．ＣＬＡＳＳ」に格納されたプログラムが、「ＺＺＺ．ＣＬＡＳＳ」のアプリケーションと異なるのは、「ＺＺＺ．ＣＬＡＳＳ」は動的シナリオの再生制御を記述するという処理に限られ、生存区間をもっていない。これに対し「ＩＬＵｓｓｓ．ＣＬＡＳＳ」におけるアプリケーションは、動的シナリオの再生制御に限らず、ゲーム、クライアント処理等多様な制御の記述が可能であり、生存区間を有している（無論、「ＩＬＵｓｓｓ．ＣＬＡＳＳ」内のプログラムは、再生制御のためのコードをもっていてもよい）。「ＩＬＵｓｓｓ．ＣＬＡＳＳ」プログラムは、他のアプリケーション（「ＺＺＺ．ＣＬＡＳＳ」に格納されたアプリケーションを含む）から、呼び出され得る区間を生存区間としている。そのためプログラムを格納した「ＩＬＵｓｓｓ．ＣＬＡＳＳ」は、その生存区間のＩｎ点より前にインターリーブ記録される。これにより「ＩＬＵｓｓｓ．ＣＬＡＳＳ」内のプログラムは、「ＺＺＺ．ＣＬＡＳＳ」のアプリケーションから呼出されうる時点より前に、メモリ１４に読み出され、メモリ１４からＪａｖａ仮想マシン内のワーク領域に転送されることになる。
インターリーブ記録には、よく似た先行技術がある。これは多重化という技術である。ＡＶストリームへの多重化と比較すると、本実施形態に示したインターリーブ記録には、次のような利点がある。多重化では、動画ストリーム及び音声ストリームと共に、ライブラリをＡＶストリームに埋め込んでおくため、非ＡＶデータたるライブラリの帯域を予め確保しておかなければならない。つまり非ＡＶデータたるライブラリを動画ストリーム、音声ストリームと共に読み出すには、本来、動画ストリームに割り当てるべき帯域を低く抑えて、ライブラリを読み出すための帯域を確保せねばならない。映画作品の場合、結果的に映像、音声の帯域が狭くなり、映像あるいは音声の品質が落ちる結果となる。また映像、音声の帯域を狭くしないように、常に最適なライブラリ用の帯域を確保する場合は、各国の言語ごとにＡＶストリームも多重化し直す必要が出てくる。これは映画作品を作る際には非常に手間がかかる。
それに対し、ライブラリをＢＤ−ＲＯＭにインターリーブ記録しようとする場合、ライブラリは別のファイルとして記録されるため、インターリーブユニットをセグメントの合間に挟んだとしても、ファイルとしては論理的につながったデータとして利用することができる。そのため、ＡＶストリームの生成のための多重化工程は、ライブラリ作成とは別の行程になり、オーサリング作業の負担を減らすことができる。
以降、図２１〜図２４を参照しながらインターリーブユニットの設定例について説明する。この設定例では、図２１に示すようなゲームプログラムを作成することを前提にしている。図２１のゲームプログラムは、映画作品の動画を背景画とし、コンピュータ・グラフィックスを前景画とした合成画面から構成される。前景画たるコンピュータ・グラフィックスは、航空機を現したものであり、ユーザの操作に応じて姿勢や方向舵を変える。
一方背景画たる動画は、上空から都市を撮影した映像である。これらを合成した画像がユーザに提示されるため、ユーザはリアルなフライトシュミレーションを体感することができる。一方、ソフトウェアの制御面から考えれば、動画を背景画にしているため、ＪａｖａモードのアプリケーションはＡＶストリーム再生と同期して、コンピュータ・グラフィックス描画を行う必要がある。
この説明で引用するライブラリは、図２２（ａ）に示すような生存区間をもつ４つのライブラリ（＃１，＃２，＃３，＃４）であるものとする。これらは、航空機の形状データの投影像を作成するレンダリングライブラリ、航空機表面の模様を示すテクスチャパタンを投影像に貼りつけるテクスチャマッッピングライブラリ、投影像に陰影を施すシェーディング処理ライブラリ等であるものとする。図２２（ａ）は、ライブラリ＃１，＃２，＃３，＃４の生存区間を示す図である。本図の横軸は、ＡＶストリームの再生時間軸であり、この時間軸にそって、各ライブラリの生存区間を描いている。ライブラリ＃１，＃２，＃３，＃４のうち、ライブラリ＃１の生存区間ＩＮ点が最も早く、以降ライブラリ＃２，＃３，＃４の生存区間ＩＮ点が続く。一方ＯＵＴ点についても、インターリーブユニット＃１の生存区間ＯＵＴ点が最も早く、以降インターリーブユニット＃２，＃３，＃４のＯｕｔ点が続く。
動画を構成するＡＶストリームは、ＢＤにおいて４つのセグメント（セグメント１／４、セグメント２／４、セグメント３／４、セグメント４／４）に分割されてＢＤに記録される。ＡＶストリームの分割境界は、ライブラリの生存区間のＩＮ点を基準にしている。図２２（ｂ）は、各ライブラリの生存区間のＩＮ点と、セグメントとの関係を示す図である。セグメントの境界（破線）は、時間軸におけるライブラリ＃１，＃２，＃３，＃４の生存区間のＩＮ点からやや手前に設定されている。つまりライブラリの生存区間のＩＮ点を基準に、ＡＶストリームは分割されているのである。
図２３は、ＢＤに対し、セグメントがどのように記録されているかを示す。各インターリーブユニットは、セグメント１／４の前にインターリーブユニット＃１を配置し、セグメント１／４〜セグメント２／４の間にインターリーブユニット＃２を配置し、セグメント２／４〜セグメント３／４の間にインターリーブユニット＃３を配置するように記録されている。図２４は、インターリーブユニットの内部構成を示す図である。各インターリーブユニットは、ヘッダと、本体部たるライブラリ（ライブラリ＃１，＃２，＃３，＃４）とからなり、ヘッダはライブラリ＃１，＃２，＃３，＃４の生存区間のＩＮ点、ＯＵＴ点を示している。
インターリーブユニット、セグメントが図２３のように記録されることにより、各ライブラリの生存区間直前に、各ライブラリはＢＤからメモリ上に読み出されることになる。またインターリーブユニットのヘッダには、生存区間のＯＵＴ点が示されているので、ＡＶストリームの再生時点が生存区間のＯＵＴ点に達すれば、メモリにおける各ライブラリは削除されることになる。かかる制御が実現可能になるので、生存区間が重なる期間において、各ライブラリを常駐させておくだけのメモリ資源を再生装置側に設けばよい。各ライブラリの生存区間から、必要最低限のメモリ規模を導きだし、これを満たすような推奨メモリ規模を定めれば良いので、動作環境をＢＤ再生装置のハードウェアスペックに近づけることができる。以上が本発明に係る光ディスクの実施形態である。
続いて本発明に係る再生装置の実施形態について説明する。図２５は、本発明に係る再生装置の内部構成を示す図である。本図に示すように、再生装置は、ＢＤドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、ピクチャプレーン５、オーディオデコーダ６、イメージプレーン８、イメージデコーダ９、加算器１０、静的シナリオメモリ１１、再生制御エンジン１２、プレーヤレジスタ１３、メモリ１４、スイッチャ１５、ＤＶＤライクモジュール１６、Ｊａｖａモジュール１７、ＢＲＯＷＳＥＲモジュール１８、ＵＯマネージャ１９、トラックバッファ２１から構成される。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
トラックバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＡＣＣＥＳＳ  ＵＮＩＴが先入れ先出し式に格納される。このトラックバッファ２に対する入力速度を図中のＶａ、出力速度を図中のＶｂとした場合の、トラックバッファ２のバッファ状態は図２０のグラフに示すものとなる。
デマルチプレクサ３は、トラックバッファ２からＡＣＣＥＳＳ  ＵＮＩＴを取り出して多重分離を行い、ＧＯＰを構成するビデオフレームと、オーディオフレームとを得てビデオフレームをビデオデコーダ４に出力し、オーディオフレームをオーディオデコーダ６に出力する。副映像ストリームを構成する副映像ユニットはイメージデコーダ９に出力する。デマルチプレクサ３による多重分離は、ＴＳパケットをＰＥＳパケットに変換するという変換処理を含む。
ビデオデコーダ４は、デマルチプレクサ３から出力されたビデオフレームを復号して非圧縮形式のピクチャをピクチャプレーン５に書き込む。
ピクチャプレーン５は、非圧縮形式のピクチャを格納しておくためのメモリである。
オーディオデコーダ６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。
イメージプレーン８は、一画面分の領域をもったメモリであり、コンピュータ・グラフィックスや字幕等、表示されるべきイメージが配置される。
イメージデコーダ９は、図１３に示したネイティブ描画系にあたる構成要素であり、デマルチプレクサ３から出力された副映像ストリームを伸長してイメージプレーン８に書き込む。この他、Ｊａｖａ仮想マシンからの指示に応じてコンピュータ・グラフィックスの描画を行い、イメージプレーン８に書き込む。
加算器１０は、ピクチャプレーン５に格納された非圧縮形式のピクチャデータに、イメージプレーン８に展開されたイメージを合成して出力する。図２１に示した合成画面（動画を表示した画面の前にコンピュータ・グラフィックス（航空機）が合成されるような画面）は、この加算器１０が、イメージプレーン８内のイメージと、ピクチャプレーン５内のピクチャとを合成することで出力される。合成にあたって加算器１０は、混合率αの指示を受け付けて、この混合率αに応じて、ピクチャプレーン５、イメージプレーン８に格納されている画像の画素値を混合して表示する。これによりコンピュータ・グラフィックスの背後に、動画データの再生画像が透けて見えるような合成画像を表示することができる。混合率αは、動的シナリオが変更できるようにしてもよい。
静的シナリオメモリ１１は、カレントのＰＬ情報やカレントのストリーム管理情報を格納しておくためのメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数ＰＬ情報のうち、現在処理対象になっているものをいう。カレントストリーム管理情報とは、ＢＤ−ＲＯＭに記録されている複数ストリーム管理情報のうち、現在処理対象になっているものをいう。
再生制御エンジン１２は、ＡＶ再生機能（１）、プレイリストの再生機能（２）、再生装置における状態取得／設定機能（３）といった諸機能を実行する。再生装置のＡＶ再生機能とは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ  ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの逆方向再生（Ｂａｃｋｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ  Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ  Ｃｈａｎｇｅ）、アングル切り換え（Ｕｎｇｌｅ  Ｃｈａｎｇｅ）といった処理をユーザからの操作に応じて実行することである。ＰＬ再生機能とは、このＡＶ再生機能のうち、再生開始や再生停止をＰＬ情報に従って行うことをいう。このＰＬ再生機能の実行により、再生制御エンジン１２はレイヤモデルの第３層（静的なシナリオに基づく再生制御）の役割を果たす。再生制御エンジン１２は、ＡＶ再生機能をユーザからの操作に従って実行する。一方、機能（２）〜（３）を、ＤＶＤライクモジュール１６〜ＢＲＯＷＳＥＲモジュール１８からの関数呼出に応じて実行する。つまり再生制御エンジン１２は、ユーザ操作による指示やレイヤモデルにおける上位層からの指示に応じて、自身の機能を実行する。
プレーヤレジスタ１３は、３２個のＳｙｓｔｅｍ  Ｐａｒａｍｅｔｅｒ  Ｒｅｇｉｓｔｅｒと、３２個のＧｅｎｅｒａｌ  Ｐｕｒｐｐｏｓｅ  Ｒｅｇｉｓｔｅｒとからなる。これらのレジスタの格納値は変数ＳＰＲＭ，ＧＰＲＭとしてプログラミングに利用される。Ｓｙｓｔｅｍ  Ｐａｒａｍｅｔｅｒ  Ｒｅｇｉｓｔｅｒ、及び、Ｇｅｎｅｒａｌ  Ｐｕｒｐｐｏｓｅ  Ｒｅｇｉｓｔｅｒは、ＤＶＤライクモジュール１６〜ＢＲＯＷＳＥＲモジュール１８から分離した再生制御エンジン１２で管理されるため、たとえ再生モードの切り換わりが生じたとしても、切換後の再生モードを実行するモジュールは、再生制御エンジン１２におけるＳＰＲＭ（０）〜（３１）、ＧＰＲＭ（０）〜（３１）を参照しさえすれば、再生装置の再生状態を知得することができる。
Ｐｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒの設定値（ＳＰＲＭ）がどのような意味をもつかは、以下に示す通りである。以下のＳＰＲＭ（ｘ）という表記は、ｘ番目のＰｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒの設定値を意味する。
ＳＰＲＭ（０）            ：  Ｒｅｓｅｒｖｅｄ
ＳＰＲＭ（１）            ：  デコード対象たるオーディオストリームのストリーム番号
ＳＰＲＭ（２）            ：  デコード対象たる副映像ストリームのストリーム番号
ＳＰＲＭ（３）            ：  ユーザによるアングル設定を示す番号
ＳＰＲＭ（４）            ：  現在再生対象とされているタイトルの番号
ＳＰＲＭ（５）            ：  現在再生対象とされているＣｈａｐｔｅｒの番号
ＳＰＲＭ（６）            ：  現在再生対象とされているＰＬの番号
ＳＰＲＭ（７）            ：  現在再生対象とされているＣＥＬＬの番号
ＳＰＲＭ（８）            ：  現在の再生時点を示す時刻情報
ＳＰＲＭ（９）            ：  ナビゲーションタイマのカウント値
ＳＰＲＭ（１０）          ：  現在選択状態にあるボタンの番号
ＳＰＲＭ（１１）〜（１２）：  Ｒｅｓｅｒｖｅｄ
ＳＰＲＭ（１３）          ：  ユーザによるパレンタルレベルの設定
ＳＰＲＭ（１４）          ：  再生装置の映像再生に関する設定
ＳＰＲＭ（１５）          ：  再生装置の音声再生に関する設定
ＳＰＲＭ（１６）          ：  再生装置における音声設定を示す言語コード
ＳＰＲＭ（１７）          ：  再生装置における字幕設定を示す言語コード
ＳＰＲＭ（１８）          ：  メニュー描画のための言語設定
ＳＰＲＭ（１９）〜（３１）：  Ｒｅｓｅｒｖｅｄ
ここでＳＰＲＭ（１０）は、ＡＶストリームに属する各ピクチャデータが表示される度に更新される。つまり再生装置が新たなピクチャデータを表示させれば、その新たなピクチャデータの表示開始時刻（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ）を示す値にＳＰＲＭ（１０）は更新される。このＳＰＲＭ（１０）を参照すれば、現在の再生時点を知得することができる。同じくＳＰＲＭ（６）を参照すれば、現在再生対象とされているＰＬの番号を知得することができ、ＳＰＲＭ（７）を参照すれば、現在再生対象とされているＣＥＬＬの番号を知得することができる。
メモリ１４は、ＢＤから読み出されたインターリーブユニットを格納しておくキャッシュメモリである。メモリ１４がトラックバッファ２と異なるのは、メモリ１４はＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）のキュー型のメモリではない点である。他の構成要素は、必要なデータをこのメモリ１４から取り出すことができる。一方、他の構成要素からの要求に応じて、インターリーブユニットを削除する。
スイッチャ１５は、ＢＤドライブ１の光ピックアップがＢＤ−ＲＯＭ上のセクタから情報を読み取る度に、セクタからの読み取り情報をトラックバッファ２、メモリ１４の何れかに書き込む。読み取り情報をトラックバッファ２、メモリ１４の何れに書き込むかは、ファイル管理情報を参照してなされる。つまり、ファイル管理情報には、各ファイルを構成するセグメントの所在が、ファイル名と対応づけられて示されているので、光ピックアップによる現在の読取位置のセクタアドレスを、ファイル管理情報と照合することで、セクタからの読み取り情報は、トラックバッファ２、メモリ１４の何れかに書き込まれる。現在の読取位置を示すセクタアドレスがファイルＸＸＸ．Ｍ２ＴＳの記録領域内のものなら、ＢＤ−ＲＯＭからの読み取り情報を順次トラックバッファ２に書き込んでゆく。現在の読取位置を示すセクタアドレスがライブラリの記録領域内のものなら、ＢＤ−ＲＯＭからの読み取り情報を順次メモリ１４に書き込んでゆく。ＢＤ−ＲＯＭからの読み取り情報はセクタ単位であるが、読み取り情報のトラックバッファ２、メモリ１４への書き込みを繰り返せば１つのＡＣＣＥＳＳ  ＵＮＩＴやライブラリがトラックバッファ２、メモリ１４上に得られることになる。
ＤＶＤライクモジュール１６は、ＭＯＶＩＥモードの実行主体となるＤＶＤ仮想プレーヤであり、動的シナリオメモリ１５に読み出されたカレントのＭＯＶＩＥモードの動的シナリオを実行する。
Ｊａｖａモジュール１７は、図１３に示したＪａｖａプラットフォームにあたる構成要素であり、メモリ１４に読み出されたライブラリを用いて、カレントのＪａｖａモードの動的シナリオを実行する。
ＢＲＯＷＳＥＲモジュール１８は、Ｂｒｏｗｓｅｒモードの実行主体となるブラウザであり、動的シナリオメモリ１５に読み出されたカレントのブラウザモードの動的シナリオを実行する。ＢＲＯＷＳＥＲモジュール１８が使用することができるプロトコルには、ＨＴＴＰ、ＩＰ、ＡＲＰ、ＲＡＲＰ、ＴＣＰ，ｔｅｌｎｅｔ，ＳＭＴＰ，ｆｔｐがある。
ＵＯマネージャ１９は、リモコンや再生装置のフロントパネルに対してなされたユーザ操作を検出して、ユーザ操作を示す情報（以降ＵＯ（Ｕｓｅｒ  Ｏｐｅｒａｔｉｏｎ）という）を出力する。
動的シナリオメモリ２１は、カレント動的シナリオを格納しておき、カレントの動的シナリオをＤＶＤライクモジュール１６〜ＢＲＯＷＳＥＲモジュール１８による処理に供するメモリである。カレント動的シナリオとは、ＢＤ−ＲＯＭに記録されている複数シナリオのうち、現在実行対象になっているものをいう。
以上がＢＤドライブ１〜動的シナリオメモリ２１の説明である。続いて本実施形態に係る再生装置がインターリーブユニット読み出しをどのように行うかについて説明する。インターリーブユニット読み出しは、再生制御エンジン１２がＰＬ再生を実行する際、ＡＶストリームを構成するＡＣＣＥＳＳ  ＵＮＩＴと共にメモリ１４に読み出される。ＰＬ再生は、図２６に示したフローチャートの処理手順に従ってなされる。再生制御エンジン１２は、ＤＶＤライクモジュール１６〜ＢＲＯＷＳＥＲモジュール１８からのＰｌａｙＰＬ関数の呼出時に、図２６のフローチャートに従いＰＬ再生を行う。ＰｌａｙＰＬ関数とはＰｌａｙＰＬ（ＸＸ，ＹＹ）という表記で呼び出される関数であり、第１引数ＸＸに指定されるＰＬを、第２引数ＹＹに示されるＣＥＬＬから再生させるというものである。
図２６のフローチャートにおいて処理対象たるＰＬをＰＬｘ、処理対象たるＣＥＬＬをＣＥＬＬｙ、処理対象たるＡＣＣＥＳＳ  ＵＮＩＴをＡＣＣＥＳＳ  ＵＮＴＴｖとする。本フローチャートに先立ち、ＰＬＰｌａｙ関数の引数で指定されたＰＬをＰＬｘに設定し、ＰＬｘをメモリに読み込んでから、処理対象たるＣＥＬＬを特定する。関数呼出にもし引数指定がなければ、ＣＥＬＬｙをＰＬｘの先頭ＣＥＬＬに設定し、ＣＥＬＬｚをＰＬｘの最後のＣＥＬＬに設定する。ＣＥＬＬｚとは、読出範囲の最後を規定するＣＥＬＬである。
引数指定があれば、ＣＥＬＬｙを引数指定されたＣＥＬＬに設定し、ＣＥＬＬｚを同じ引数指定されたＣＥＬＬに設定する。ＣＥＬＬｙ、ＣＥＬＬｚを、引数指定されたＣＥＬＬに設定しておくのは、引数でＣＥＬＬが指定されている場合は、そのＣＥＬＬさえ読み出せばよいからである。
ステップＳ１〜ステップＳ１９は、ＣＥＬＬｙを構成するＡＣＣＥＳＳ  ＵＮＩＴの読み出しと、復号手順とを示す。この手順は、ＣＥＬＬｙのＩｎ点ビデオフレームを含むＡＣＣＥＳＳ  ＵＮＩＴｖをＴＭＡＰから特定し（ステップＳ１）、ステップＳ２〜ステップＳ５の判定を経てからＡＣＣＥＳＳ  ＵＮＩＴｖの読み出しをＢＤ−ＲＯＭドライブ１に命じて（ステップＳ６）、ステップＳ７−ステップＳ８の判定を経てから、ＡＣＣＥＳＳ  ＵＮＩＴｖに含まれるビデオフレームのデコードを行うようビデオデコーダ４に指示して（ステップＳ９）、ＡＣＣＥＳＳ  ＵＮＩＴｖを次のＡＣＣＥＳＳ  ＵＮＩＴに設定する（ステップＳ１０）というものである。
ステップＳ２は、ＡＣＣＥＳＳ  ＵＮＩＴｖが属するセグメントは、未読出であるか否かを判定するものである。ＡＣＣＥＳＳ  ＵＮＩＴｖが属するセグメントにおいて、ＡＣＣＥＳＳ  ＵＮＩＴｖが初めて読み出されるＡＣＣＥＳＳ  ＵＮＩＴであるなら（ステップＳ２でＹｅｓ）、ＡＣＣＥＳＳ  ＵＮＩＴｖが属するセグメントをセグメントｉに設定し（ステップＳ１１）、ＴＭＡＰを参照して、セグメントｉに先行するインターリーブユニットｉを読み出してから（ステップＳ１２）、ＡＣＣＥＳＳ  ＵＮＩＴｖの読み出しをＢＤドライブ１に命じる（ステップＳ６）。これにより、ＡＣＣＥＳＳ  ＵＮＩＴｖは、その先行するインターリーブユニットとともに  ＢＤから読み出されることになる。
ここでＡＣＣＥＳＳ  ＵＮＩＴを含むセグメントはファイル「ＸＸＸ．Ｍ２ＴＳ」に格納されており、これに先行するライブラリはファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」に格納されている。セグメント及びライブラリはそれぞれ別々の２つのファイルに格納されているので、再生制御エンジン１２は、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」からの読み出しと「ＸＸＸ．Ｍ２ＴＳ」からの読み出しとを連続して行う必要がある。
ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」からの読み出しは、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」をオープンし、オープンされたファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」の先頭位置を指定するようファイルポインタを設定してから、以降、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」の全体長を設定したＲＥＡＤコマンドをＢＤドライブ１に発行することでなされる。このコマンド発行により、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」は再生装置２００のメモリ１４に読み出されることになる。
ファイル「ＸＸＸ．Ｍ２ＴＳ」からの読み出しは、ファイル「ＸＸＸ．Ｍ２ＴＳ」をオープンし、オープンされたファイル「ＸＸＸ．Ｍ２ＴＳ」のうち、ＡＣＣＥＳＳ  ＵＮＩＴｖの先頭位置を指定するようファイルポインタを設定してから、以降、ＡＣＣＥＳＳ  ＵＮＩＴｖの全体長を設定したＲＥＡＤコマンドをＢＤドライブ１に発行することでなされる。このコマンド発行により、ＡＣＣＥＳＳ  ＵＮＩＴｖは再生装置２００のトラックバッファ２に読み出されることになる。
ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」をＢＤドライブ１からの読み出した段階で、ファイルポインタはファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」（インターリーブユニット）の終了位置を指している。ＡＣＣＥＳＳ  ＵＮＩＴｖを含むセグメントはインターリーブユニットの直後に位置しているので、光ピックアップの位置を僅かにずらすだけでＡＣＣＥＳＳ  ＵＮＩＴｖの先頭位置を指定するようファイルポインタを設定することができる。
ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」からの読み出しと「ＸＸＸ．Ｍ２ＴＳ」からの読み出しとにより、光ピックアップはシーク動作を行うことなく、セグメントとこれに先行するインターリーブユニットとをまとめて読み出すことができる。
ステップＳ３は、メモリにあるどれかのインターリーブユニットの生存区間Ｉｎ点に現在の再生時点が到達したかのどうかの判定であり、もしどれかのインターリーブユニットの生存区間ＩＮ点に到達していれば（ステップＳ３でＹｅｓ）、そのインターリーブユニット内のライブラリを利用可能にして（ステップＳ１３）、ステップＳ６に移行する。
インターリーブユニット内のライブラリが利用可能とされる前は、アプリケーションプログラム（Ｊａｖａモードの動的シナリオのことである）がメモリ１４からＪａｖａ仮想マシン内のワーク領域へのライブラリロードを命じたとしても、このロードを行わず例外終了する。これは、ライブラリがメモリ１４に読み出されていない場合と同じである。インターリーブユニット内のライブラリが利用可能になれば、アプリからのロード命令に応じてＪａｖａ仮想マシン内のワーク領域にライブラリを転送する。かかる転送にて、ライブラリはＪａｖａ仮想マシンにて実行されることになる。
ステップＳ４は、ユーザ操作があったかどうかの判定であり、もしユーザ操作があれば、それがＳＴＯＰ操作であるかを判定し（ステップＳ１５）、もしＳＴＯＰ操作であれば（ステップＳ１５でＹｅｓ）、本フローチャートの処理を終える。それ以外なら、ユーザ操作に対応する処理を行い、ステップＳ２〜ステップＳ１０からなるループ処理に戻る。
ステップＳ５は、現在の再生時点がメモリにあるどれかのインターリーブユニットの生存区間Ｏｕｔ点に到達したかの判定であり、もし到達していれば、そのインターリーブユニットをメモリから削除して（ステップＳ１４）ステップＳ６に移行する。
ステップＳ７は、ＡＣＣＥＳＳ  ＵＮＩＴｖがＩｎ点ビデオフレームを含んでいるかどうかの判定である。もしＩＮ点ビデオフレームを含んでいる場合は（ステップＳ７でＹｅｓ）、Ｉｎ点のビデオフレームからＡＣＣＥＳＳ  ＵＮＩＴｖの最後のビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから（ステップＳ１６）、ステップＳ９に移行する。
ステップＳ８は、Ｏｕｔ点ｖがＣＥＬＬｙのＯｕｔ点ビデオフレームを含んでいるかどうかの判定である。もしＯｕｔ点ビデオフレームを含んでいる場合は（ステップＳ８でＹｅｓ）、ＡＣＣＥＳＳ  ＵＮＩＴｖの先頭ビデオフレームからＯｕｔ点ビデオフレームまでのデコードを行うようビデオデゴーダ４に指示してから（ステップＳ１７）、ステップＳ１８の判定を行う。ステップＳ１８は、本フローチャートの終了判定であり、ＣＥＬＬｙがＣＥＬＬｚになったかを判定している。もしステップＳ１８がＹｅｓなら本フローチャートを終了し、そうでないなら、ＣＥＬＬｙを次のＣＥＬＬに設定して（ステップＳ１９）、ステップＳ１に戻る。以降、ステップＳ１８がＹｅｓと判定されるまで、ステップＳ１〜ステップＳ１９の処理は繰り返される。以上が再生制御エンジン１２の処理手順である。
図２７は、図２５に示した構成要素のうち、ライブラリに係るものを抜き出して描いた図である。本図では、「ＩＬＵｓｓｓ．ＣＬＡＳＳ」としてメモリ１４に読み出されたライブラリ又はプログラムが、アプリケーションによる利用又は呼出に至るまでの経路を模式的に示している。ライブラリ及びプログラムは、インターリーブユニットの形態でセグメントの前に記録されている。そのためセグメントと共に矢印ｇｙ１に示すようにメモリ１４に読み出される。矢印ｇｙ２は、ライブラリがアプリケーションにより利用されるに至るまでの経路であり、メモリ１４からＪａｖａモジュール１７内のワーク領域にロードされる。このロードによりアプリケーションは、矢印ｇｙ３に示すようにライブラリ内の関数をコールすることができる。
矢印（ｇｙ４）は、「ＩＬＵｓｓｓ．ＣＬＡＳＳ」内のプログラムが呼び出されるまでの経路であり、メモリ１４からＪａｖａモジュール１７内のワーク領域にロードされる。このロードにより、「ＩＬＵｓｓｓ．ＣＬＡＳＳ」内のプログラムは”アプリケーション”と対等な地位になり、Ｊａｖａモジュール１７により実行されることになる。
Ｊａｖａ仮想マシンのワーク領域にロードされたライブラリ又はアプリケーションが、イメージデコーダ９に対する制御（ｇｙ５）を行うものなら、イメージデコーダ９により伸長処理が行われ、イメージプレーン８に伸長後のイメージが格納される。一方ビデオデコーダ４にはトラックバッファ２、デマルチプレクサ３を介してＡＣＣＥＳＳ  ＵＮＩＴが読み出されているので、ピクチャプレーン５には非圧縮型のピクチャがえられることになる。イメージデコーダ９が得たイメージと、ビデオデコーダ４が得たピクチャとを加算器１０が合成することにより、図２１のような合成画像が得られる。
以上のように本実施形態によれば、セグメント再生と同期実行すべきライブラリはインターリーブユニットという形でセグメントの前に配置されており、セグメントの再生時にあたっては光ピックアップによる読み取り位置をセグメントの先頭位置からずらせば、セグメントを、同期実行すべきライブラリと共に読み出すことができる。同期処理に必要なライブラリは、セグメントの読み出し時にセグメントと併せてＢＤ−ＲＯＭから読み出せば足り、セグメントとの同期処理が済めば、メモリから削除すればよいので、デジタルストリーム再生の全区間を通じてライブラリを常駐しておく必要はない。デジタルストリームとの同期処理を行うべきライブラリが複数あっても、個々のプログラムの実行が終わる度に、ライブラリをメモリから回収するという原則でリソース管理を行えば、セグメント再生との同期時に、プログラムを格納し得るだけのメモリを再生装置に実装しておけばよい。必要最低限のメモリ規模で、デジタルストリーム再生と、様々なライブラリとの同期処理を実現することができる。
（第２実施形態）
第１実施形態は、インターリーブ記録の客体はライブラリプログラムであったが、第２実施形態のインターリーブ記録の客体は、表示用データである。表示用データには、イメージ系データ、文書系データ、描画系データがある。イメージ系データには、ＪＰＥＧ，ＧＩＦ，ＰＮＧ，ＭＮＧデータ等があり、イメージデコーダ９がダイレクトに伸長処理を行うことにより、表示可能となるデータをいう。文書系データには、ＨＴＭＬ／ＳＭＩＬ，ＸＭＬ文書，テキスト文書があり、ＢＲＯＷＳＥＲモジュール１８により解釈されて、イメージデコーダ９が解釈結果に基づく表示制御を受けることにより表示可能となるデータをいう。
描画系データとは、いわゆるｄｒａｗ系エディタを対象としたデータであり、立体形状や図形を、座標、ベクトル、曲率等で表現しているデータである。Ｊａｖａモジュール１７により解釈され、イメージデコーダ９が解釈結果に基づく制御を受けることにより表示可能となるデータをいう。
インターリーブユニットたる表示用データは、セグメント再生と同期して表示される。ここでの同期表示は、セグメントの再生中にＪＰＥＧ，ＧＩＦ，ＰＮＧ，ＭＮＧデータを表示して合成したり、ＨＴＭＬ／ＳＭＩＬ文書，ＸＭＬ文書，テキスト文書を別ウィンドゥに表示させることを含む。ＨＴＭＬ／ＳＭＩＬ文書，ＸＭＬ文書，テキスト文書は、ブラウザモードのアプリケーションプログラムにより利用され、ＪＰＥＧ，ＧＩＦ，ＰＮＧ，ＭＮＧデータはＪａｖａモードのアプリケーションプログラムにより利用される。Ｊａｖａモードのアプリケーションプログラムは、ＡＶストリームの再生中において特定のシーンが出現した場合、キャッシュメモリからＪａｖａ仮想マシン内ワーク領域へのロードを命じてくるだろうから、同期表示すべき期間より前に、表示用データをキャッシュメモリに読み出しておく必要がある。同様にブラウザモードのアプリケーションプログラムも、ＡＶストリームの再生中において特定のシーンが出現した場合、アプリケーションプログラムの利用を求めてくるだろうから、同期表示すべき期間より前に、表示用データをキャッシュメモリに読み出しておく必要がある。そこで第２実施形態では、表示用データを同期させたい期間から生存区間を求めて、生存区間のＩＮ点にあたる位置に、表示用データたるインターリーブユニットをインターリーブ記録する。こうすることでインターリーブユニットは、同期表示される期間の直前に再生装置のキャッシュメモリに読み出されることになる。
図２８は、Ｊａｖａ言語が対象とするレイアモデルにおいて、かかるデータが何処に位置するかを示す図である。本図に示すようにセグメント再生と同期表示されるべきデータは、Ｎａｔｉｖｅ描画系の上位層に配置される。
ＢＤ−ＲＯＭへの表示用データの記録にあたって、表示用データはライブラリと同様ＢＤ−ＲＯＭにインターリーブ記録される。
図２９は、表示用データを格納したインターリーブユニットの構成を示す図である。本図におけるヘッダは、第１実施形態に示したロケータ、生存区間ＩＮ点情報、生存区間ＯＵＴ点情報に加え、ファイルの「Ｆｉｌｅ  Ｎａｍｅ」「Ｓｔａｒｔ＿ａｄｄｒｅｓｓ」言語属性（ｌａｎｇｕａｇｅ＿ｔｙｐｅ）」、ＡＶストリームの再生時間軸におけるファイルの「表示開始時刻情報」、「表示終了時刻情報」、画面における「表示座標情報」、表示エフェクトをかけるための「エフェクト情報」、「強制出力フラグ」をもっている。
「表示開始時刻情報」、「表示終了時刻情報」をヘッダにもたせているのは、インターリーブユニットに含まれる表示用データを、ＡＶストリームを構成する動画データの再生と同期させて表示させるには、表示用データの表示タイミングが必要となるからである。また生存区間とは別に「表示開始時刻情報」、「表示終了時刻情報」を定めているのは、メモリ上にインターリーブユニットを読み出しつつも、表示させたくないケースや、メモリ上にインターリーブユニットを配置しておいて表示用データの表示／非表示を繰り返すケースがあり、これらへの対処を念頭に置いているからである。
「言語属性（ｌａｎｇｕａｇｅ＿ｔｙｐｅ）」をヘッダにもたせているのは、表示用データが文章、会話に関する場合、どの言語で記述されているかを明示しておく必要があるためである。
「表示座標」をヘッダにもしているのは、動画データとの合成を想定した場合、背景たる動画データの絵柄によっては、表示用データが非常に見づらくなってしまう場合があり、見易い位置に表示用データを表示させるためである。
「エフェクト情報」をヘッダ内に設けておくのは、表示用データの表示開始時や表示終了時に、フェードインあるいはフェードアウトなどのエフェクトをかけたいとの要望に応えるためである。
「強制出力フラグ」をヘッダ内に設けておくのは、字幕を表示しないとユーザーが選択していた場合でも強制的に表示させたいという要望に応えるためである。本実施形態において表示用データは、図２９に示したヘッダが付されてインターリーブユニットの形態で、セグメントの前に記録される。以上が本実施形態におけるインターリーブユニットの改良である。続いて本実施形態に係る再生装置の改良について説明する（イメージデコーダ９、スイッチャ１５）。
スイッチャ１５は、ＢＤドライブ１の光ピックアップがインターリーブユニットが記録されているセクタ列から情報を読み取る度に、セクタからの読み取り情報をメモリ１４に書き込む。読み取り情報のメモリ１４への書き込みを繰り返せばインターリーブユニットがメモリ１４上に得られることになる。
イメージデコーダ９は、メモリ１４に格納されたインターリーブユニットのヘッダを参照し、現在の再生時点が何れかのインターリーブユニット内の表示用データの表示開始時刻に到達すれば、インターリーブユニット内の表示用データを描画してイメージプレーン８に書き込む。一方、現在の再生時点が何れかのインターリーブユニット内の表示用データの表示終了時刻に到達すれば、イメージプレーン８に書き込まれた表示用データを消去する。
図３０は、インターリーブユニットとしてメモリ１４に読み出されたイメージ系データ、文書系データ、描画系データが表示に至るまでの経路を示す図である。矢印ｍｙ１は、イメージ系データが表示に至るまでの経路を模式的に示す。イメージ系データは、インターリーブユニットの形態でＢＤ−ＲＯＭからメモリ１４に読み出され（ｇｙ１）、メモリ１４からダイレクトにイメージデコーダ９に供給される（ｍｙ１）。このイメージデコーダ９がデコード処理を行うことにより、表示に至る。
矢印ｍｙ２，ｍｙ３は、文書系データが表示に至るまでの経路であり、文書系データは、メモリ１４から一旦ＢＲＯＷＳＥＲモジュール１８に読み出される（ｍｙ２）。ＢＲＯＷＳＥＲモジュール１８は、文書系データの解釈を行い、その解釈結果を出力し（ｍｙ３）、解釈結果に基づきイメージデコーダ９に対する表示制御（ｋｙ１）を行うことにより、文書系データは表示に至る。
矢印ｍｙ４，ｍｙ５は、描画系データが表示に至るまでの経路である。描画系データは、メモリ１４から一旦Ｊａｖａモジュール１７内のワーク領域にロードされる（ｍｙ４）。Ｊａｖａモジュール１７は、描画系データの解釈結果を出力し（ｍｙ５）、解釈結果に基づきイメージデコーダ９に対する表示制御（ｋｙ２）を行うことにより、描画系データは表示に至る。
以上のように本実施形態によれば、表示用データをインターリーブ記録するので、セグメントの読み出しと共に表示用データを再生装置内のメモリに読み出すことができ、セグメント再生と、表示用データの表示との同期を容易に実現することができる。表示用データのための情報をインターリーブユニットのヘッダに設けておくことにより、インターリーブユニットの本体部にあたる表示用データの形式を変えることなく、ＡＶストリーム再生と同期して、各種データを表示させることができる。
（第３実施形態）
第１実施形態では、プログラムの生存区間の開始点より前にインターリーブユニットを配置することでインターリーブユニットとプログラムとの同時読み込みを実現した。しかし第１実施形態では、生存区間の途中位置へと頭出しを行う場合でも、インターリーブユニット先頭から読み出しを行わねばならず、読み出しに長い時間がかかってしまう。ＢＤ−ＲＯＭにおいては、プレイリスト情報による再生経路の定義が可能であり、再生経路に従った再生にあたっては、ＡＶストリームを先頭から再生してゆくことは稀で、ＡＶストリームの途中から再生を開始してゆくことが頻繁に起こり得る。
ＡＶストリームやセグメントの途中からの頭出しが頻繁に発生するのなら、セグメントの前にインターリーブユニットを置くという配置では好適なインターリーブユニット読み出しを実行し得ない。そこで本実施形態は、インターリーブユニットに冗長性をもたせることを提案する。どのような冗長性かというと、あるセグメントに先行するインターリーブユニットと同じもの（複製物）を、組み込んでおくというものである。複製物を組み込む箇所は、インターリーブユニットに含まれるライブラリの生存区間の途中にあたる位置である。図３１は、セグメント内部のどこに、インターリーブユニット複製物を組み込むかを示す図である。本図においてＡＶストリームは、ライブラリ＃ｘの生存区間の途中にあたる位置でセグメントｉと、セグメントｉ＋１とに分割されている。そしてセグメントｉとセグメントｉ＋１との間にインターリーブユニットが配置されている。セグメントｉとセグメントｉ＋１との間のインターリーブユニットは、ライブラリ＃ｘを含んだものであり、セグメント直前に位置するインターリーブユニットの複製物である。つまりセグメントの前にあるインターリーブユニットの複製物が、ライブラリ＃ｘの生存区間の途中にあたる位置に存在しているのである。
図３２は、セグメントｉの内部に対して頭出しを行う場合、プログラムがどのように読み取られるかを示す図である。図中の（１）は、セグメントｉ内部に対する頭出し位置を示す。
インターリーブユニットはセグメントｉの前に存在するので、本来ならセグメントｉの前（（２）にあたる位置）から光ピックアップによる読み出しを行わねばならない。しかし本実施形態では、プログラムの生存区間の途中にあたる位置に、インターリーブユニット複製物が存在するから、図３２における頭出し位置（１）から（３）に示すように読み出しを行えば、頭出し位置（１）からインターリーブユニット複製物を読み出すことができる。ライブラリ＃ｘの生存区間の途中に、そのライブラリを含むインターリーブユニット＃ｘの複製物が記録されるので、生存区間途中に位置するＡＣＣＥＳＳ  ＵＮＩＴから頭出しをする場合、間近のインターリーブユニット複製物から、読み取りを行うことでＡＶストリーム読み出しを開始することができる。セグメントに先行するインターリーブユニットまで光ピックアップを移動させなくてもよいので、デジタルストリームの頭出し位置からの読み出しやライブラリを用いた処理が容易になる。
続いて、図２２〜図２４に示したような４つのライブラリを、１つのＡＶストリームに組み込む場合の改良について説明する。図３３は、図２２に示した４つのライブラリ＃１，＃２，＃３，＃４と、セグメントとの関係を示す図である。セグメント１／５〜セグメント５／５のうち、セグメント２／５〜セグメント５／５の境界は、図２２（ａ）に示したライブラリ＃１，＃２，＃３，＃４の生存区間のＩｎ点と一致している。しかしセグメント１／５と２／５との境界は、ライブラリ＃１の生存区間の途中にある。セグメント２／５の前にインターリーブユニット＃１の複製物が配置され、以降セグメント３／５、セグメント４／５、セグメント５／５の前にインターリーブユニット＃２、インターリーブユニット＃３、インターリーブユニット＃４が配置されている。セグメント２／５の前に、インターリーブユニット＃１の複製物が配置されているので、セグメント２／５に含まれるＡＣＣＥＳＳ  ＵＮＩＴへの頭出しが生じた場合、セグメント２／５に先行するインターリーブユニット＃１の複製物から光ピックアップによるスキャンを行えば、セグメント１／５に先行するインターリーブユニット＃１まで光ピックアップを移動させなくても、インターリーブユニット＃１をメモリに読み出することができる。
以上のように本実施形態によれば、ＡＶストリームを構成するＡＣＣＥＳＳ  ＵＮＩＴのうち、ＣＥＬＬのＩＮ点等頭出しが多く発生しうる位置の後にインターリーブユニット複製物を配置しておけば、セグメント前に配置されているインターリーブユニットまでディスクシークを行わなくとも、アプリケーションプログラムによるライブラリ利用が可能となる。ＰＬ情報に基づく再生を行うため頭出しが多く発生したとしても、ディスクシークが最低限となり、スムーズな読み取りが可能となる。
（第４実施形態）
第１実施形態ではプログラム生存区間の開始点より前に、第３実施形態ではプログラム生存区間の途中にインターリーブユニット（若しくはその複製物）を配置していた。しかし何れの実施形態においても、デジタルストリームの逆方向再生が行われる場合、再生装置はインターリーブユニット読み出しを好適に行うことはできない。何故なら逆方向再生は、ＡＶストリームの再生時間軸を未来から過去方向に遡ってゆくからである。逆方向再生をスムーズに行わせるため、本実施形態では、インターリーブユニットに冗長性をもたせる。どのような冗長性かというと、あるセグメントに先行するインターリーブユニットと同じものを、そのセグメントの後ろに組み込んでおくというものである。
図３４（ａ）は、インターリーブユニット、セグメント、インターリーブユニット複製物の配置を示す図である。図３４においてｉ番目に再生されるセグメントｉの前には、この再生時間内に生存区間をもつインターリーブユニットｉが配置されている。セグメントｉは、ライブラリ＃ｘの生存区間Ｉｎ点を含み、インターリーブユニットｉは、ライブラリ＃ｘを含む。更にこのセグメントｉの後には、セグメントｉの前に配置されていたインターリーブユニットの複製物が配置されている。
図３４（ｂ）は、図３４（ａ）に、ｉ＋１番目のセグメントを書き加えた図である。図３４（ａ）同様、セグメントｉの後ろには、インターリーブユニットｉの複製物が配置され、その後ろにはインターリーブユニットｉ＋１が配置されている。かかるインターリーブユニット複製物を置くことの技術的意義は、逆方向再生を効率的に行うためである。
インターリーブユニット複製物がある場合と、無い場合とで逆方向再生がどのように行われるか対比して説明する。図３５は、インターリーブユニット複製物がある場合に逆方向再生がどのように行われるかを示す図である。逆方向再生は、各セグメントに含まれるＡＣＣＥＳＳ  ＵＮＩＴを、後ろのものから順に読み出していかねばならない。図３５の矢印▲１▼▲２▼▲３▼▲４▼は、セグメントに  ＡＣＣＥＳＳ  ＵＮＩＴ＃８が存在し、セグメントにＡＣＣＥＳＳ  ＵＮＩＴ＃４〜＃７が存在する場合のディスクシークを示す。最初の▲１▼は、セグメントｉ＋１内のＡＣＣＥＳＳ  ＵＮＩＴ＃８に属するピクチャデータを、先頭から読み出すというディスクシーク、
▲２▼は、インターリーブユニットｉを読み出すというディスクシーク、▲３▼は、ＡＣＣＥＳＳ  ＵＮＩＴ＃７を読み出すとのディスクシークである。図中のロングシーク１は、ｉ＋１番目のセグメント内のＡＣＣＥＳＳ  ＵＮＩＴ＃８を読み出してから、ｉ番目のセグメントの直前にあるインターリーブユニットｉをアクセスするまでの長いシーク動作を示す。ロングシーク２は、インターリーブユニットｉを読み出してから、セグメント内のＡＣＣＥＳＳ  ＵＮＩＴ＃７を読み取るまでの長いシーク動作を示す。
ｉ＋１番目のセグメントを全て読み出してから、インターリーブユニットｉまでジャンプし（ロングシーク１）、インターリーブユニットｉからｉ番目のセグメントの最後のＡＣＣＥＳＳ  ＵＮＩＴをジャンプせねばならないので（ロングシーク２）、シーク動作に無駄が多い。
図３６は、インターリーブユニット複製物が配置されたＢＤ−ＲＯＭにおけるシーク動作を示す図である。本図と図３５との違いは、ｉ＋１番目のセグメントの前に、インターリーブユニットｉ＋１が配置され、インターリーブユニットｉ＋１の前にインターリーブユニットｉの複製物が配置されている点である。シーク▲１▼は、ｉ番目のインターリーブユニットの複製物と、ｉ＋１番目のインターリーブユニットと、セグメントｉ＋１内のＡＣＣＥＳＳ  ＵＮＩＴとを読み出すディスクシークであり、シーク▲２▼は、ｉ番目のセグメント内のＡＣＣＥＳＳ  ＵＮＩＴ＃７を読み出すディスクシーク、シーク▲３▼は、ｉ番目のセグメント内のＡＣＣＥＳＳ  ＵＮＩＴ＃６を読み出すディスクシークである。
インターリーブユニットｉの複製物が、インターリーブユニットｉ＋１の直前に配置されているため、逆方向再生ではシーク▲１▼にて、ｉ＋１番目のセグメント内の先頭ＡＣＣＥＳＳ  ＵＮＩＴと共に、インターリーブユニットｉが読み出される。セグメントの読み取りと共に、インターリーブユニットが読み取られるので、図３６ではロングシークが不要となり、即座にセグメントｉについてのインターリーブユニットｉが読み取られることになる。以上のようにインターリーブユニットの複製物を、各セグメントの後ろ側に配置することで、逆方向再生時のロングシークの発生を回避することができる。
続いて、図２２〜図２４に示したような４つのライブラリを、１つのＡＶストリームに組み込む場合の改良について説明する。図３７は、図２２に示した４つのライブラリ＃１，＃２，＃３，＃４と、セグメントとの関係を示す図である。つまり本実施形態では、セグメント１／４の後ろ、インターリーブユニット＃２の前にインターリーブユニット＃１の複製物が記録され、セグメント２／４の後ろ、インターリーブユニット＃３の前にインターリーブユニット＃２の複製物が、セグメント３／４の後ろ、インターリーブユニット＃４の前にインターリーブユニット＃３の複製物が記録されることになる。かかる複製物の配置により、逆方向再生におけるロングシークの発生を回避することができる。
以上が本実施形態に係る光ディスク側の改良である。続いて本実施形態に係る再生装置側の改良について説明する。図３６に示したディスクアクセスは、逆方向再生時に再生制御エンジン１２が図３８のフローチャートに基づく処理を行うことにより実現される。図３８のフローチャートは、図２６のフローチャートにおいてユーザにより逆方向再生操作が命じられた際、実行されるものである。
ステップＳ３２〜ステップＳ４０は、ＣＥＬＬｙを構成するＡＣＣＥＳＳ  ＵＮＩＴの読み出しと、復号手順とを示す。この手順は、ステップＳ３２〜ステップＳ３５の判定を経てからＡＣＣＥＳＳ  ＵＮＩＴｖの読み出しをＢＤ−ＲＯＭドライブ１に命じて（ステップＳ３６）、ステップＳ３７−ステップＳ３８の判定を経てから、ＡＣＣＥＳＳ  ＵＮＩＴｖに含まれるビデオフレームのデコードを行うようビデオデコーダ４に指示して（ステップＳ３９）、ＡＣＣＥＳＳ  ＵＮＩＴｖを次のＡＣＣＥＳＳ  ＵＮＩＴに設定する（ステップＳ４０）というものである。
ステップＳ３２は、ＡＣＣＥＳＳ  ＵＮＩＴｖが属するセグメントは、未読出であるか否かを判定するものである。もし未読出であるなら、ＡＣＣＥＳＳ  ＵＮＩＴｖが属するセグメントは２番目以降であるかを判定し（ステップＳ４２）、２番目以降であるなら（ステップＳ４２でＹｅｓ）、ＡＣＣＥＳＳ  ＵＮＩＴが属するセグメントをセグメントｉ＋１に設定して（ステップＳ４３）、ＴＭＡＰを参照してセグメントｉ＋１に先行するインターリーブユニットｉ＋１と、インターリーブユニットｉとを読み出す（ステップＳ４４）。１番目なら（ステップＳ４２でＮｏ）、ＡＣＣＥＳＳ  ＵＮＩＴが属するセグメントをセグメントｉに設定して（ステップＳ１１）、ＴＭＡＰを参照してセグメントｉに先行するインターリーブユニットｉを読み出す（ステップＳ１２）。ここで、ＡＣＣＥＳＳ  ＵＮＩＴｖと、これに先行する２つのインターリーブユニットとはそれぞれ別々の３つのファイルに格納されているので、Ｊａｖａモードのアプリケーションには、２つのインターリーブユニットにあたる２つのファイルを読み出すコマンド、ＸＸＸ．Ｍ２ＴＳを読み出す読出コマンドを連続発行する必要がある。インターリーブユニット複製物の先頭アドレスに光ピックアップを移動させさえすれば、光ピックアップの一回の読み取り操作で、セグメントとこれに先行する２つのインターリーブユニットとをまとめて読み出すことができる。
ステップＳ３３は、図２６のステップＳ３と同じ処理であり、メモリにあるどれかのインターリーブユニットの生存区間Ｉｎ点に現在の再生時点が到達したかのどうかの判定であり、もしどれかのインターリーブユニットの生存区間ＩＮ点に到達していれば、そのインターリーブユニット内のライブラリを利用可能にする。
ステップＳ３５は、図２６のステップＳ５と同じ処理であり、現在の再生時点がメモリにあるどれかのインターリーブユニットの生存区間Ｏｕｔ点に到達したかを判定し、もし到達していれば、そのインターリーブユニットをメモリから削除する。
ステップＳ３７は、ＡＣＣＥＳＳ  ＵＮＩＴｖがＯｕｔ点ビデオフレームを含んでいるかどうかの判定である。もしＯｕｔ点ビデオフレームを含んでいる場合は（ステップＳ３７でＹｅｓ）、ＡＣＣＥＳＳ  ＵＮＩＴｖの先頭ビデオフレームからＯｕｔ点ビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから（ステップＳ４５）、ステップＳ３９に移行する。
ステップＳ３８は、ＡＣＣＥＳＳ  ＵＮＩＴｖがＣＥＬＬｙのＩｎ点ビデオフレームを含んでいるかどうかの判定である。もしＩｎ点ビデオフレームを含んでいる場合は（ステップＳ３８でＹｅｓ）、Ｉｎ点のビデオフレームから  ＡＣＣＥＳＳ  ＵＮＩＴｖの最後のビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから（ステップＳ４６）、ステップＳ４７の判定を行う。ステップＳ４７は、本フローチャートの終了判定であり、ＣＥＬＬｙがＰＬを構成する最初のＣＥＬＬになったかを判定している。もしステップＳ４７がＹｅｓなら本フローチャートを終了し、そうでないなら、ＰＬを構成する１つ前のＣＥＬＬにＣＥＬＬｙを設定し（ステップＳ４８）、ＣＥＬＬのＩＮ点ビデオフレームを含むＡＣＣＥＳＳ  ＵＮＩＴをＴＭＡＰから特定してから（ステップＳ４９）ステップＳ３２に戻る。以降、ステップＳ４７がＹｅｓと判定されるまで、ステップＳ３２〜ステップＳ４９の処理は繰り返される。以上が本実施形態に係る再生制御エンジン１２の処理手順である。
以上のように本実施形態によれば、デジタルストリームの再生時間軸を未来から過去に遡って行き、ライブラリの生存区間に到達した場合でも、不要なシークを行うことなくＢＤ−ＲＯＭからメモリへのライブラリ読み出しを実現することができる。逆方向再生のような変則的な再生進行が行われる場合でも、メモリへのライブラリ読み出しを実現出来るので、ＡＶ再生との同期を前提とした様々な処理を、逆方向再生時でも実現可能となる。
（第５実施形態）
第５実施形態は、ＰＬの再生を行い、この再生に同期して様々な再生制御を行うＪａｖａモードのアプリケーションについて説明する。
図３９は、本実施形態に係るＢＤ−ＲＯＭのファイル構成を示す図である。本図において新規なのは、ＹＹＹ．Ｍａｒｋ（ＰＬＭａｒｋ），ＸＸＸ．Ｍａｒｋ（ＣｌｉｐＭａｒｋ）が追加されている点である。
ＰＬＭａｒｋは、ＰＬの再生中において、再生装置が拡張制御を行うべき区間を示す情報である。ファイル名「ＹＹＹ．Ｍａｒｋ」のファイルボディＹＹＹは、ＰＬＭａｒｋが対応しているＰＬと同じ名称が使用される。つまり本図におけるＰＬＭａｒｋのファイル名のファイルボディはＹＹＹであるから、ＰＬ（ＹＹＹ．ＰＬ）に対応していることを意味する。
ＣｌｉｐＭａｒｋは、ＡＶストリームの再生中において、再生装置が拡張制御を行うべき区間を示す情報である。ＸＸＸ．Ｍａｒｋのファイル名におけるファイルボディ「ＸＸＸ」は、ＣｌｉｐＭａｒｋが対応しているＡＶストリームと同じ名称が使用される。つまり本図におけるＣｌｉｐＭａｒｋのファイル名におけるファイルボディは「ＸＸＸ」であるから、ＡＶストリーム（ＸＸＸ．Ｍ２ＴＳ）に対応していることを意味する。
ＣｌｉｐＭａｒｋとＰＬＭａｒｋとの違いは以下の通りである。ＣｌｉｐＭａｒｋは、拡張制御を行うべき区間をＡＶストリームに対して指定しているのに対し、ＰＬＭａｒｋはＰＬに対して指定している。
例えば、図１１に示したように１つのＡＶストリームに対し、２つのＰＬ情報が定義されている場合に、ＣｌｉｐＭａｒｋにて拡張制御を行うべき区間を指定すれば、この指定は、このＡＶストリームを指定している２つのＰＬ情報の何れに対しても及ぶ。一方、ＰＬＭａｒｋにて拡張制御を行うべき区間を指定すれば、ＰＬＭａｒｋに対応するＰＬにのみ、拡張制御指定の効力は及ぶ。ＰＬＭａｒｋに対応するＰＬがＰＬ＃１ならＰＬ＃１のみに及び、ＰＬ＃２には及ばない。つまり、拡張制御を行うべき区間をＣｌｉｐＭａｒｋにて指定すれば、ＡＶストリームを含むＰＬの全てに対しＣｌｉｐＭａｒｋの効力が及び、拡張制御を行うべき区間をＰＬＭａｒｋにて指定すれば、そのＰＬＭａｒｋに対応するＰＬに対してのみＣｌｉｐＭａｒｋの効力が及ぶのである。これがＣｌｉｐＭａｒｋとＰＬＭａｒｋとの違いである。
本実施形態における拡張制御とは、再生装置にイベントを発生させるというものである。イベントを発生させるため、ＰＬＭａｒｋ及びＣｌｉｐＭａｒｋは、図４０に示す共通のデータ構造をもつ。図４０は、ＰＬＭａｒｋ及びＣｌｉｐＭａｒｋの共通構成を示す図である。本図に示すようにＰＬＭａｒｋは、イベント数（Ｎｕｍｂｅｒ）、個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）とから構成され、再生中に発生すべきイベントを定義する。個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）と、イベントのＩＤ（ＩＤ）と、イベントが発生する時刻（Ｔｉｍｅ）と、このイベントが有効となる時間帯の時間長（Ｄｕｒａｔｉｏｎ）を示す。
かかるデータ構造にて定義されるイベントには、ＴｉｍｅＥｖｅｎｔ、ＵｓｅｒＥｖｅｎｔというものがある。ＴｉｍｅＥｖｅｎｔとは、プレイリストの再生時間軸において、現在の再生位置が予め定められた時点Ｔに到達した場合に発生するイベントである。ＵｓｅｒＥｖｅｎｔとは、現在の再生位置が予め定められた時間帯に到達し、この時間帯でユーザにより操作がなされた場合に発生するイベントである。
プレイリスト＃１の再生中に出現するＴｉｍｅＥｖｅｎｔを定義する場合、ＰＬＭａｒｋをどのように記述するかについて図４１（ａ）を参照しながら説明する。図中の下段の時間軸は、ＰＬ＃１が再生される時間軸を示す。この時間軸において時刻ｔ１から発生するＴｉｍｅＥｖｅｎｔＥｘ１を定義するケースを想定する。このＴｉｍｅＥｖｅｎｔを定義する場合のＰＬＭａｒｋの記述例が、図中のＰＬＭａｒｋｍｔ１である。本ＰＬＭａｒｋは、Ｔｙｐｅの項目が”ＴｉｍｅＥｖｅｎｔ”と記述され、ＩＤの項目に”Ｅｘ１”、Ｔｉｍｅの項目が”ｔ１”、Ｄｕｒａｔｉｏｎの項目が”０”と記述されている。図中の矢印は、時刻ｔ１の到来で生じるＴｉｍｅＥｖｅｎｔを示す。このＴｉｍｅＥｖｅｎｔの発生により、図中のイベントハンドラが駆動されることになる。
一方、再生時間軸上の時刻ｔ１から、間隔ＴでＴｉｍｅＥｖｅｎｔを発生させる場合のＰＬＭａｒｋの記述例を図４１（ｂ）に示す。図４１（ｂ）が（ａ）と違うのは、ＰＬＭａｒｋのＤｕｒａｔｉｏｎ項目が”Ｔ”と記述されている点である。項目Ｄｕｒａｔｉｏｎの記述により、時点ｔ１の経過後、間隔Ｔ置きにＴｉｍｅＥｖｅｎｔを発生させることができる。
プレイリスト＃１の再生中においてＵｓｅｒＥｖｅｎｔを定義する場合、ＰＬＭａｒｋをどのように記述するかについて図４２を参照しながら説明する。図４２の中段の時間軸は、ＰＬ＃１が再生される再生時間軸を示す。この時間軸上において現在の再生時点がどこであるかは、ＳＰＲＭ（１０）に示されている。この時間軸において時刻ｔ１から期間Ｔ１の間、有効となるＵｓｅｒＥｖｅｎｔＥｖ１を定義するケースを想定する。このＵｓｅｒＥｖｅｎｔを定義したＰＬＭａｒｋが、図中のＰＬＭａｒｋｍｔ２である。本ＰＬＭａｒｋは、Ｔｙｐｅの項目が”ＵｓｅｒＥｖｅｎｔ”と記述され、ＩＤの項目に”Ｅｖ１”、Ｔｉｍｅの項目が”ｔ１”、Ｄｕｒａｔｉｏｎの項目が”Ｔ１”と記述されている。本図におけるリモコンｒｍ１は、ユーザ操作を受け付ける機器であり、図中の矢印ｕｖ１は、リモコンのＥＮＴＥＲキーの押下で生じるＵＯを示す。ＵＯが、時刻ｔ１から期間Ｔ１の時間帯に発生すれば、ＵＯに基づきＵｓｅｒＥｖｅｎｔＥｖ１が発生する。このＵｓｅｒＥｖｅｎｔにより、図中のイベントハンドラが駆動される。以上がＰＬＭａｒｋにより定義されるイベントである。尚ＣｌｉｐＭａｒｋにより定義されるイベントについての説明は省略する。何故なら、ＰＬＭａｒｋがＰＬ再生中に発生すべきイベントを定義しているのに対し、ＣｌｉｐＭａｒｋはＡＶストリーム再生中に発生すべきイベントを定義しているにすぎず、ＰＬＭａｒｋにおけるイベント定義とあまり変わらないからである。
図４３は、ＣｌｉｐＭａｒｋ、ＰＬにてかかるＴｉｍｅＥｖｅｎｔ、ＵｓｅｒＥｖｅｎｔが定義されている場合のインターリーブユニットの配置例を示す図である。本図においてＡＶストリームは、ＴｉｍｅＥｖｅｎｔを発生すべき時点ｔ１の直前で分割され、この位置にイベントハンドラＥｘ１を格納したインターリーブユニットが記録されている。
このように記録しておくことで、時点ｔ１を含むセグメントと共に、イベントハンドラを含むインターリーブユニットがメモリに読み出されることになる。イベントハンドラがメモリに読み出されれば、アプリケーションプログラムからのロード命令に応じてＪａｖａ仮想マシン内のワーク領域に、イベントハンドラをロードすることができるので、再生時点が時点ｔ１に達すれば、このイベントハンドラを即座に駆動することができる。
以上が本実施形態に係るＢＤ−ＲＯＭの改良である。続いて、本実施形態における再生装置の改良点について説明する。上述したようなＴｉｍｅＥｖｅｎｔ、ＵｓｅｒＥｖｅｎｔを発生させるには、再生制御エンジン１２に図４４に示すような処理手順を行わせればよい。
図４４は、本実施形態に係る再生制御エンジン１２の処理手順を示す図である。本フローチャートは、図２２のフローチャートの改良であり、同じ処理手順のものは同一の参照符号を付すか或は、図示を省略している。本フローチャートにおいて新規なのは、ＣＥＬＬを構成するＡＣＣＥＳＳ  ＵＮＩＴを読み出し、復号するという一連の処理（図２６のステップＳ２〜ステップＳ１０のうち、ステップＳ５とＳ６との間）に、ステップＳ２０、ステップＳ２２という２つの判定ステップが挿入されている点である。ステップＳ２０は、ＰＬ再生において、現在の再生時点を発生時刻としたＴｉｍｅＥｖｅｎｔが、ＰＬＭａｒｋ、ＣｌｉｐＭａｒｋに定義されているかどうかを判定するステップである。ステップＳ２０がＹｅｓなら、ＴｉｍｅＥｖｅｎｔを発生して（ステップＳ２１）、ステップＳ６に移行する。ＴｉｍｅＥｖｅｎｔを駆動要件とするイベントハンドラは、インターリーブユニットの形態でＢＤ−ＲＯＭに記録されており、セグメントと共に再生装置のメモリに読み出されるので、ＴｉｍｅＥｖｅｎｔを駆動要件とするイベントハンドラが即座に駆動される。
ステップＳ２２は、ＵＯが発生したかどうかを判定しているステップである。ステップＳ２２がＹｅｓなら、ＰＬＭａｒｋ、ＣｌｉｐＭａｒｋを参照し、そのＵＯを有効としている時間帯であるかを判定する（ステップＳ２３）。もしその時間帯であれば、ＵｓｅｒＥｖｅｎｔの発生して（ステップＳ２４）、ステップＳ６に戻る。ＵｓｅｒＥｖｅｎｔを駆動要件とするイベントハンドラは、インターリーブユニットの形態でＢＤ−ＲＯＭに記録されており、セグメントと共に再生装置のメモリに読み出されるので、ＵｓｅｒＥｖｅｎｔを駆動要件とするイベントハンドラが即座に駆動される。
以上のように本実施形態によれば、ＡＶストリームの再生時間上において、イベントハンドラの駆動が予定されている位置に、イベントハンドラをインターリーブユニットの形態でセグメント間に組み込んでおくので、アプリケーションプログラムによりロードが命じられた場合、メモリからＪａｖａ仮想マシン内のワーク領域へのロードを好適に行うことができる。
尚、ＴｉｍｅＥｖｅｎｔ、ＩＬＶＵの他、ＰＬの再生に先立ち発生するイベント（Ｐｒｅイベント）、ＰＬの再生後発生するイベント（Ｐｏｓｅｔイベント）を再生制御エンジン１２に発生させ、これにより駆動されるイベントハンドラをインターリーブユニットに格納してもよい。この場合、プレイリスト情報における先頭のＣＥＬＬ情報にて指定されている時点及びプレイリスト情報における最後のＣＥＬＬ情報にて指定されている時点のインターリーブユニットに格納しておくことが望ましい。
本実施形態では、Ｍａｒｋ情報にて定義されるイベントについてのイベントハンドラを説明したが、インターリーブ記録されるイベントハンドラは、他のプログラムにより発生されるイベントにて駆動されてもよい。機器により発生されるイベントにて駆動されてもよい。機器により発生されるイベントとは、ＢＤ−ＲＯＭのオープン／クローズがなされたことを示すイベント、電源異常等、機器の状態を示すイベント等がある。
（第６実施形態）
第１実施形態、第２実施形態においてライブラリ及び表示用データの生存区間に関する情報は、インターリーブユニットのヘッダに直接記述されていた。これに対し第６実施形態ではライブラリ及び表示用データの生存区間に関する情報を、間接参照の形式で記述するものである。
図４５は、インターリーブユニットに関する情報の間接参照がどのように行われるかを示す図である。
本図の第１段たるＡＶストリームは、２つのセグメントに分割されてＢＤ−ＲＯＭに記録されており、このセグメントの合間にインターリーブユニットが記録されている。このインターリーブユニットはライブラリ、表示用データを含んでいる。ここまでは第１実施形態と変わりない。しかしヘッダのロケータ、生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報がＩＤに置き換えられている。一方、第２段目、第３段目における静的なシナリオには、インターリーブユニット統合情報がある。このインターリーブユニット統合情報には、ＡＶストリームに組み込まれた複数インターリーブユニットのそれぞれについて、生存区間の情報が記述される。このインターリーブユニット統合情報は、各インターリーブユニットの生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報、インターリーブユニットのサイズを対応づけて示している。ヘッダに直接生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報を記述せず、ヘッダにＩＤを記述しておき、このＩＤを介してインターリーブユニット統合情報から生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報を取得できるようにしている。これが生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報の間接参照である。
図４６は、ＡＶストリームに組み込まれた３つのインターリーブユニットと、インターリーブユニット統合情報との対応を示す図である。ＡＶストリーム内にＩＤ＝１，２，３・・・・をもったインターリーブユニットが組み込まれている場合、ＩＤ＝１，２，３・・・・がインターリーブユニット統合情報に記述され、これらのＩＤ毎に、インターリーブユニットの生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報、サイズが記述される。各インターリーブユニットに付されたＩＤは、インターリーブユニット自身がどのＡＶストリームに属しているか（１）、そのＡＶストリームにおいて何個目のインターリーブユニットであるか（２）を一意に識別する。
かかるインターリーブユニット統合情報が静的なシナリオ内に存在することにより、再生制御エンジン１２はＡＶストリームに組み込まれた複数インターリーブユニットの集中管理を行うことができる。集中管理の具体的な内容としては、生存区間が重なり合う複数インターリーブユニットが存在する場合、メモリ１４へのインターリーブユニット読み出しを制限するというインターリーブユニットの読み出し本数制限がある。
インターリーブユニット統合情報は、各インターリーブユニットのＩＤと対応づけて各インターリーブユニットのサイズを示しているので、各インターリーブユニットのサイズを積算してゆけば、生存区間が重なり合う複数インターリーブユニットを同時にメモリ１４に格納しようとした場合、メモリ１４上に存在するインターリーブユニットの総サイズがどれだけになるかを、計算しておくことができる。もし計算された総サイズが、メモリ１４のメモリサイズより大きくなれば、生存区間が重なり合う複数インターリーブユニットの全てをメモリ１４に読み出すのではなく、一部のインターリーブユニットのみをメモリ１４に読み出す。かかる読み出し本数の制限により、インターリーブユニット同士の上書きが回避され、メモリ１４上でのインターリーブユニット破壊を回避することができる。
以上のように本実施形態によれば、キャッシュメモリ上に読み出し可能なインターリーブユニット本数を、インターリーブユニットの読み出しに先立ち事前に見積もることができるので、インターリーブユニットの生存区間が重なってる場合のキャッシュメモリの容量不足を回避することができる。
自機のメモリ規模に応じてどれだけインターリーブユニットを読み出すことができるかを調整することができるので、ＢＤ−ＲＯＭプレーヤモデルの策定にあたっては、「どれだけの規模のキャッシュメモリを具備せねばならない」というメモリ規模の指針を数値化しなくてもよくなる。メモリ規模の数値化が不要になるため、再生装置のメモリ規模がどれだけにすればよいかという、メモリ規模設計の自由度が高まり、ＢＤ−ＲＯＭ再生装置の普及に貢献することができる。
尚インターリーブユニット統合情報は、静的なシナリオにおいて１つ設けておいたが、ストリーム管理情報の１つの情報要素として組み込んでおいてもよい。この場合、個々のインターリーブユニットがどのＡＶストリームに組み込まれているかという識別（１）が不要であり、個々のインターリーブユニットがＡＶストリームにおける何番目のインターリーブユニットであるかを識別できればよいので、ＩＤのビット長を短くすることができる。またＰＬ情報の１つの情報要素として組み込んでもよい。
（第７実施形態）
第１実施形態及び第２実施形態では、再生時間軸上の生存区間のＩｎ点及びＯｕｔ点を生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報で記述するという表記により、生存区間を表現していた。これに対し第７実施形態では、間接的な表記を提案する。どのような表記かというと、ＣＥＬＬ情報の番号、ＰＬ（プレイリスト）情報の番号、Ｍａｒｋ情報の番号、タイトルの番号、チャプターの番号、ＳｋｉｐＰｏｉｎｔの番号を用いて生存区間を表記するのである。図４７は、第７実施形態に係るインターリーブユニットにて、生存区間がどのように表記されるかを示す図である。
ここで『ＣＥＬＬ情報』は、第１実施形態に示したようにＡＶストリーム上の１つの再生区間を指定するものである。インターリーブユニットのヘッダに、生存区間情報としてＣＥＬＬ情報の番号を記述しておくことにより”再生区間”をインターリーブユニットの”生存区間”として定義することができる。図中のインターリーブユニットヘッダにおけるＣＥＬＬ情報の番号が、Ｃｅｌｌ情報＃１を示しているなら、図中のｃｋ１に示すようにＣＥＬＬ情報＃１にて指定される再生区間（図中のａｙ１〜ａｙ２で示される区間）が生存区間になる。
『ＰＬ情報』は、第１実施形態に示したように１つ以上の再生区間から構成される再生経路を指定するものである。インターリーブユニットのヘッダに生存区間情報としてＰＬ情報の番号を記述すれば、ＰＬ情報にて指定された再生経路を、インターリーブユニットの生存区間として定義することができる。
『Ｍａｒｋ情報（ＣｌｉｐＭａｒｋ，ＰＬＭａｒｋ）』とは、第５実施形態に示したように拡張制御を行うべき区間を指定するものである。インターリーブユニットのヘッダに、生存区間情報としてＭａｒｋ情報の番号を記述しておくことで、そのＭａｒｋ情報にて指定される区間をインターリーブユニットの生存区間として定義することができる。
『タイトル』とは、１つ以上の再生経路と、動的シナリオとから構成される１つの映画作品のことである。このタイトルの番号を生存区間情報としてインターリーブユニットのヘッダに記述しておくことにより、映画作品といった広汎な範囲の生存区間を定義することができる。
『チャプター』とは、映画作品の「章」としてユーザに認識される単位であり、１つ以上のＣＥＬＬ情報にて規定される。このチャプターの番号を生存区間としてインターリーブユニットのヘッダに記述しておくことにより、映画作品の「章」という、わかり易い単位で生存区間を定義することができる。
『ＳｋｉｐＰｏｉｎｔ』とは、章のうち、ユーザがマーキングを行った位置をいう。かかる位置は、Ｍａｒｋ情報で定義される。このＳｋｉｐＰｏｉｎｔの番号を生存区間Ｉｎ点情報、生存区間Ｏｕｔ点情報としてインターリーブユニットのヘッダに記述しておくことにより、ＳｋｉｐＰｏｉｎｔというユーザにとってわかり易い単位で生存区間を定義することができる。
以上が本実施形態に係る生存区間の表記である。続いてかかる生存区間を有している場合の、ライブラリ及び表示用データのインターリーブ記録について説明する。ＣＥＬＬ情報、ＰＬ情報、Ｍａｒｋ情報、タイトル、チャプター、ＳｋｉｐＰｏｉｎｔの番号で生存区間が表現されているとはいえ、生存区間がＡＶストリーム上に存在していることは、第１実施形態と同様である。そのためライブラリ及び表示用データは、ＡＶストリームのうち、ＣＥＬＬ情報、ＰＬ情報〜ＳｋｉｐＰｏｉｎｔにより指定されている位置の直前に記録すれば良い。かかる位置の前後でＡＶストリームを複数セグメントに分割しておき、かかるセグメント間にライブラリ及び表示用データを含むインターリーブユニットを記録しておけばよいのである。そうすればＣＥＬＬ情報、ＰＬ情報〜ＳｋｉｐＰｏｉｎｔを用いた再生の開始にあたって、インターリーブユニットは、かかるＡＶストリームを構成するセグメントと共にメモリ１４に読み出されることになる。
ここでＣＥＬＬ情報により指定される位置とは、ＣＥＬＬ情報のＩｎ点情報により指定されるＡＶストリーム上の位置であり、ＰＬ情報により指定される位置とは、ＰＬ情報における最初のＣＥＬＬ情報のＩｎ点情報により指定されるＡＶストリーム上の位置である。
タイトルにより指定される位置とは、そのタイトルを構成する１つ以上のＰＬ情報のうち、最初のＰＬ情報の最初のＣＥＬＬ情報のＩｎ点情報により指定されるＡＶストリーム上の位置であり、Ｍａｒｋ情報により指定される位置とは、ＡＶストリーム上においてそのＭａｒｋ情報の時刻情報で指定される位置、チャプター番号、ＳｋｉｐＰｏｉｎｔ番号で指定される位置とは、ＡＶストリーム上においてそのチャプター、ＳｋｉｐＰｏｉｎｔにより指定されるＡＶストリーム上の位置をいう。
以上が本実施形態に係るＢＤ−ＲＯＭの改良である。生存区間が、ＰＬ情報、ＣＥＬＬ情報、タイトルの番号で表現されているので、第７実施形態に係る再生装置の再生制御エンジン１２は、以下のような処理を行う。
ＰＬ情報、ＣＥＬＬ情報、Ｍａｒｋ情報、タイトル、ＳｋｉｐＰｏｉｎｔの番号により再生が命じられた場合、本実施形態に係る再生制御エンジン１２は、これらで指定されている位置にあたるＡＣＣＥＳＳ  ＵＮＩＴを特定し、ＴＭＡＰにおけるそのＡＣＣＥＳＳ  ＵＮＩＴに対応するＡＣＣＥＳＳ  ＵＮＩＴエントリーを参照する。そのＡＣＣＥＳＳ  ＵＮＩＴエントリーにインターリーブユニットのファイル名が記述されていれば、そのファイル名のＡＣＣＥＳＳ  ＵＮＩＴと、ＡＣＣＥＳＳ  ＵＮＩＴとを連続してＢＤ−ＲＯＭから読み出す。
かかる連続読み出しは、以下の６つのタイミングにおいて、なされることになる。
１つ目のタイミングとは、タイトルが一覧表示され、このメニューに対してユーザが選択操作を行ったタイミングである。タイトル選択がなされれば、再生制御エンジン１２は、このタイトルにて指定される位置のＡＣＣＥＳＳ  ＵＮＩＴに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＡＣＣＥＳＳ  ＵＮＩＴと共にＢＤ−ＲＯＭからメモリ１４に読み出す。メモリ１４におけるインターリーブユニットの格納は、そのタイトルの再生が終了するまで継続してなされる。タイトル再生が終了すれば、再生制御エンジン１２はメモリ１４からインターリーブユニットを削除する。
２つ目のタイミングとは、あるＰＬ情報がカレントＰＬ情報として静的シナリオメモリ１１に読み出されるタイミングである。再生制御エンジン１２はそのカレントＰＬ情報にて指定される位置のＡＣＣＥＳＳ  ＵＮＩＴにインターリーブユニットが先行しているかのサーチを行い、もし先行していればＡＣＣＥＳＳ  ＵＮＩＴと共に、そのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。メモリ１４におけるインターリーブユニットの格納は、カレントＰＬ情報による再生が終了するまで継続してなされる。再生制御エンジン１２は現在の再生時点がカレントＰＬ情報を構成する最後のＣＥＬＬ情報のＯｕｔ点に到達するのを待ち、到達すれば、インターリーブユニットをメモリ１４から削除する。Ｊａｖａモードのアプリケーションプログラムは、上述したＰＬ情報の再生が行われている間、ロード命令を発行することにより、ライブラリをメモリ１４からＪａｖａ仮想マシン内のワーク領域に供給することができる。
３つ目のタイミングとは、カレントＰＬ情報内のＣＥＬＬ情報が再生の対象（図２６のフローチャートにおけるＣＥＬＬｙ）として指定されるタイミングである。そのタイミングにおいて再生制御エンジン１２は、そのＣＥＬＬにて指定される位置のＡＣＣＥＳＳ  ＵＮＩＴに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。再生制御エンジン１２は現在の再生時点がＣＥＬＬ情報のＯｕｔ点に到達するのを待ち、到達すれば、インターリーブユニットをメモリ１４から削除する。かかる処理により、Ｊａｖａモードのアプリケーションプログラムは、上述したＣＥＬＬ情報の再生が行われている間、ロード命令を発行することにより、ライブラリをメモリ１４からＪａｖａ仮想マシン内のワーク領域に供給することができる。
４つ目のタイミングとは、現在の再生時点がＭａｒｋ情報に示される時点に達したタイミングである。再生制御エンジン１２は、そのＭａｒｋ情報により指定された位置にあたるＡＣＣＥＳＳ  ＵＮＩＴに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。
５つ目のタイミングとは、ユーザがチャプターメニューからチャプターを選ぶ操作を行ったタイミングである。チャプター選択操作を行えば、再生制御エンジン１２はそのチャプターにより指定された位置にあたるＡＣＣＥＳＳ  ＵＮＩＴに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。尚、現在の再生時点がチャプターの先頭に到達した場合もそのチャプターにあたる位置に、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。
６つ目のタイミングとは、ユーザがＳｋｉｐＰｏｉｎｔを選ぶ操作を行ったタイミングである。ＳｋｉｐＰｏｉｎｔを選ぶ操作をを行えば、再生制御エンジン１２はそのＳｋｉｐＰｏｉｎｔにより指定された位置にあたるＡＣＣＥＳＳ  ＵＮＩＴにインターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。尚、現在の再生時点がＳｋｉｐＰｏｉｎｔに到達した場合もそのＳｋｉｐＰｏｉｎｔにあたるＡＣＣＥＳＳ  ＵＮＩＴにインターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをＢＤ−ＲＯＭからメモリ１４に読み出す。
以上のように本実施形態によれば、ＣＥＬＬ情報、ＰＬ情報の番号を用いて生存区間を定義しているので、インターリーブユニット同士の生存区間の重なりの把握が容易となり、リソース管理を念頭においたインターリーブユニットの読み取り計画が立て易くなる。
尚、再生制御エンジン１２によるサーチを容易とするため、各インターリーブユニットの生存区間情報は、第１実施形態におけるインターリーブユニット統合情報において統合管理しておくことが望ましい。こうすることにより、インターリーブユニット統合情報を参照するだけで全てのインターリーブユニットに対するサーチが可能になる。
また本実施形態では、ＰＬ情報、ＣＥＬＬ情報、タイトル、チャプター、ＳｋｉｐＰｏｉｎｔと、インターリーブユニットとを番号で対応づけたが、ＰＬ情報、ＣＥＬＬ情報、タイトル、チャプター、ＳｋｉｐＰｏｉｎｔを一意に識別できるものなら、どのような識別情報であってもよい。また第６実施形態に示したようなインターリーブユニットの識別情報を、ＰＬ情報、ＣＥＬＬ情報に付与することで識別してもよい。
（第８実施形態）
第１実施形態、第２実施形態では、ロケータにファイルパスを記述することによりメモリ１４における個々のライブラリ及びプログラムを識別していたが、第８実施形態はロケータにおけるファイルパスの記述により、メモリ１４上のライブラリ、表示用データの配置を階層化しようという改良に関する。図４８は、ロケータの記述によるプログラム又は表示用データの階層化配置を模式的に示す図である。本図の第１段目は、ＡＶストリームと、ＡＶストリームの合間にインターリーブ記録されたインターリーブユニットとを示す。第２段目は、各インターリーブユニットの内部構成と、ヘッダにおけるロケータの記述とを示す。第３段目は、メモリ１４上のプログラム及び表示用データの配置を示す。第２段目において各インターリーブユニットのロケータは、「ＣＭ：／／Ｊａｖａ／Ｉｍａｇｅ」，「ＣＭ：／／Ｊａｖａ／Ｇａｍｅ」，「ＣＭ：／／Ｊａｖａ／Ｃｈａｒａｃｔｅｒ」と記述されているため、再生制御エンジン１２は各インターリーブユニットのヘッダを参照した際、メモリ１４上のＪａｖａディレクトリを生成し、このディレクトリに「Ｉｍａｇｅ」，「Ｇａｍｅ」，「Ｃｈａｒａｃｔｅｒ」というファイルを生成してこれらファイルに、インターリーブユニット内のプログラム又は表示用データを配置してゆく。図中の矢印ｔｙ１，ｔｙ２，ｔｙ３は、この配置を模式的に示す。ここで第２段目の生存区間情報を見ると、インターリーブユニットの生存区間は、インターリーブユニット１の生存区間は１〜６、インターリーブユニット２の生存区間は３〜５，インターリーブユニット３の生存区間は０〜１０なので、各インターリーブユニットの生存区間は互いに重複し合っている。互いに重なり合うライブラリ及び表示用データーを、「Ｉｍａｇｅ」，「Ｇａｍｅ」，「Ｃｈａｒａｃｔｅｒ」というファイルに格納して１つのｊａｖａディレクトリの配下に配置するので、Ｊａｖａディレクトリをアクセスすることにより、Ｊａｖａモードのアプリケーションプログラムはインターリーブユニット内のライブラリ及び表示用データをＪａｖａ仮想マシン内のワーク領域にロードすることができる。
（第９実施形態）
これまでの実施形態では、ライブラリや表示用データのインターリーブ記録を行っていた。これに対し第９実施形態では、ライブラリや表示用データを、データカルーセルと同様の形式でＡＶストリーム内に組み込むという改良に関する。データカルーセルとは、対話的な放送の実現のために同一内容を繰り返しするという放送方式である。ＢＤ−ＲＯＭは、放送されたデータを格納するものではないが、このデータカルーセルの格納形式に倣ってライブラリ及び表示用データを格納するようにしている。
ここでデータカルーセルでの送信について説明する。データカルーセルの客体は複数に分割される。分割により得られた個々の分割部分は、ＤＤＢ（Ｄａｗｎｌｏａｄ  Ｄａｔａｂｌｏｃｋ）というブロックになり、ＤＩＩ（ＤｏｗｎｌｏａｄｉｎｆｏＩｎｄｉｃａｔｉｎ）と呼ばれる固有の制御情報と共にＡＶストリーム内に組み込まれる。このＤＩＩは、ＤＤＢに先立つ位置に配置され、ＤＤＢのデータ長が記述される。
このデータカルーセル方式の客体が、ライブラリ及び表示用データであると考えれば、ライブラリ及びデータはヘッダが付加された上で、複数のＤＤＢに分割される。そしてこれらのＤＤＢは、ＡＶストリームのうち、生存区間Ｉｎ点にあたる位置の前に配置される。こうすることで、生存区間Ｉｎ点にあたるＡＣＣＥＳＳ  ＵＮＩＴが再生装置により読み出されたタイミングで、ライブラリ及び表示用データにあたるＤＤＢは、再生装置に読み出されるのである。
以上が、第９実施形態に係るＡＶストリーム側の改良である。続いて本実施形態に係る再生装置側の改良について説明する。図４９は第９実施形態に係る再生装置の内部構成を示す図である。
ＡＶストリーム内にデータカルーセル形式のライブラリ及びデータが存在するため、インターリーブユニットとＡＶストリームとを分離するスイッチャ１５は再生装置から省かれている。メモリ１４には、デマルチプレクサ３からライブラリ及びデータが供給されるようになっている。本図の再生装置においてデマルチプレクサ３は、ＡＶストリームに対して多重分離を行い、ビデオストリーム、オーディオストリーム、副映像ストリーム、そしてデータカルーセル形式のライブラリ及びデータを得る。このうちデータカルーセル形式のライブラリ及びデータはメモリ１４に格納される。データカルーセル形式のライブラリ及びデータはメモリ１４に格納されるので、Ｊａｖａモードアプリケーションからのロード命令に応じて、データカルーセル形式のライブラリ及びデータはメモリ１４からＪａｖａ仮想マシン内のワーク領域に読み出されることになる。
以上のように本実施形態によれば、Ｊａｖａモードのアプリケーションプログラムにて利用され得るライブラリ及び表示用データを、データカルーセルと同様の形式で再生装置に供給するので、再生装置の内部構成をデジタル放送の受信装置と共通化することができる。これにより、デジタル放送の受信装置の機能を兼ねるような再生装置を構成することができる。
（第１０実施形態）
第１０実施形態は、ライブラリ−表示用データをインターリーブ記録の形態でＢＤ−ＲＯＭに記録しつつも、再生装置からスイッチャ１５を省略する改良に関する。スイッチャ１５がなくなったため第１０実施形態に係るアプリケーションプログラムは、以下のようにインターリーブユニットの読み出しを行う。
インターリーブユニットをＡＣＣＥＳＳ  ＵＮＩＴと共に読み出す場合、アプリケーションプログラムは、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」からの読み出しと「ＸＸＸ．Ｍ２ＴＳ」からの読み出しとを連続して行う。
ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」からの読み出しは、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」をオープンし、オープンされたファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」の先頭位置を指定するようファイルポインタを設定する。ここまでは第１実施形態と同様である。この際アプリケーションプログラムは、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」の読出先となる領域を宣言しておく。そしてファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」の全体長を設定したＲＥＡＤコマンドをＢＤドライブ１に発行する。ここでいう読出先領域とは、メモリ１４のことであり、このコマンド発行により、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」は再生装置２００のメモリ１４に読み出されることになる。
ファイル「ＸＸＸ．Ｍ２ＴＳ」からの読み出しは、ファイル「ＸＸＸ．Ｍ２ＴＳ」をオープンし、オープンされたファイル「ＸＸＸ．Ｍ２ＴＳ」のうち、ＡＣＣＥＳＳ  ＵＮＩＴｖの先頭位置を指定するようファイルポインタを設定する。ここまでは第１実施形態と同様である。この際アプリケーションプログラムは、ファイル「ＸＸＸ．Ｍ２ＴＳ」の読出先となる領域を宣言しておく。ここでの読出先領域とは、トラックバッファ２のことである。そして以降、ＡＣＣＥＳＳ  ＵＮＩＴｖの全体長を設定したＲＥＡＤコマンドをＢＤドライブ１に発行する。このコマンド発行により、ＡＣＣＥＳＳ  ＵＮＩＴｖは再生装置２００のトラックバッファ２に読み出されることになる。
以上のように本実施形態によれば、アプリケーションプログラムがファイルを読み出すにあたって、ファイル「ＩＬＵｓｓｓ．ＣＬＡＳＳ」を読み出す場合の読出先と、ファイル「ＸＸＸ．Ｍ２ＴＳ」を読み出す場合の読出先とを切り換えることにより、スイッチャ１５を用いずにインターリーブユニット読み出しと、ＡＶストリーム読み出しとを実行することができる。
（第１１実施形態）
本実施形態は、ＢＤ−ＲＯＭの製造工程に関する実施形態である。図５０は、第１１実施形態に係るＢＤ−ＲＯＭの製造工程を示すフローチャートである。
ＢＤ−ＲＯＭの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ１０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ１０２、ＢＤ−ＲＯＭの原盤を作成し、プレス・貼り合わせを行って、ＢＤ−ＲＯＭを完成させるプレス工程１０３を含む。
これらの工程のうち、ＢＤ−ＲＯＭを対象としたオーサリング工程は、シナリオ編集工程Ｓ２０１、素材エンコード工程Ｓ２０２、多重化工程Ｓ２０３、フォーマッティング工程Ｓ２０４という工程とからなる。
シナリオ編集工程Ｓ２０１とは、企画段階において作成された筋書きを再生装置が理解できる形式に変換する工程である。シナリオ編集の結果は、ＢＤ−ＲＯＭ用の静的シナリオとして生成される。また、このシナリオ編集において、多重化を実現するため多重化パラメータの等も生成される。
素材エンコード工程Ｓ２０２とは、ビデオ素材、オーディオ素材、副映像素材のそれぞれをエンコードして、ビデオストリーム、オーディオストリーム、副映像ストリームを得る作業である。
多重化工程Ｓ２０３では、素材エンコードにより得られた、ビデオストリーム、オーディオストリーム、副映像ストリームをインターリーブ多重化して、これらを１本のＡＶストリームに変換する。
一方、これらの工程と並行して、Ｊａｖａ言語によるプログラム（工程Ｓ２０４、Ｓ２０５）が実行される。
Ｊａｖａアプリケーション制作工程Ｓ２０４は、Ｊａｖａ言語を用いてＪａｖａアプリケーションを制作する工程である。
ライブラリ制作工程Ｓ２０５は、ライブラリを制作する工程である。
フォーマッティング工程Ｓ２０６は、工程Ｓ２０１〜Ｓ２０５にて得られたＡＶストリーム、静的シナリオ、動的シナリオ、ライブラリをＢＤ−ＲＯＭのフォーマットに適合させる。この適合にあたって、第１実施形態に示したように、ＡＶストリームを複数のセグメントに分割し、各セグメントの合間にライブラリを記録するとの処理がなされる。
上述した工程のうち、工程Ｓ２０４において、Ｊａｖａアプリケーションである動的シナリオは、Ｊａｖａ言語を用いた記述が可能であるから、通常のコンピュータ向けのソフトウェアを開発するのと同じ感覚で、開発することができる。よって本実施形態では、このシナリオ制作の効率を高めることができるという効果がある。
（第１２実施形態）
本実施形態では、ＢＤにおけるＡＶストリームを、ＢＤ−Ｒ，ＢＤ−ＲＥ等の記録型記録媒体にコピーする実施形態である。その際記録装置は、動的シナリオ、テーブルをＷＥＢサイトからダウンロードする。このテーブルは、図２２（ａ）に示したようなＡＶストリーム再生時間軸に対する、ライブラリ生存区間の割り付けを示す。テーブルには、生存区間割り付けが示されているので、第１実施形態に示したように生存区間ＩＮ点を基準にしてＡＶストリームを分割し、セグメントの合間にセグメント内に生存区間をもつライブラリを記録する。この記録にあたってライブラリはインターリーブユニットに変換しておく。
こうすることで、ライブラリが記録されていないバージョンのＢＤを、ライブラリや動的シナリオが記録されたバージョンにアップグレードすることができる。（備考）
上記実施形態に基づいて説明してきたが、現状において最善の効果が期待できるシステム例として提示したに過ぎない。本発明はその要旨を逸脱しない範囲で変更実施することができる。代表的な変更実施の形態として、以下（Ａ）（Ｂ）（Ｃ）・・・・のものがある。
（Ａ）第２実施形態では、１つの表示用データのみインターリーブユニットに格納していたが、複数の表示用データを１つのインターリーブユニットに変換してＢＤ−ＲＯＭに記録してもよい。図５１は、複数の表示用データを格納したインターリーブユニットを示す図である。本図におけるイメージ系データ、文書系データ、描画系データは、それぞれ複数の表示用データであり、かかるインターリーブユニットをＢＤ−ＲＯＭに記録しておくことにより、インターリーブユニットの一回の読み出しにて複数の表示用データをメモリに格納しておくことができる。尚、この場合、ヘッダには、インターリーブユニットに含まれるそれぞれのファイルについての情報を記述しておく必要がある。
（Ｂ）図１２に示したレイアモデルにおいて、Ｊａｖａモードの上にブラウザモード及びＭＯＶＩＥモードを配置してもよい。特にＭＯＶＩＥモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、ＭＯＶＩＥモードをＪａｖａモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が１つのモードで済むからである。
更に３つのモードを設けず、ＪａｖａモードだけでＪａｖａモードの処理を実行してもよい。ＪａｖａモードでもＰＬの再生と同期した再生制御が可能になるから、強いてＭＯＶＩＥモードを設けなくてもよいという理由による。更に動的シナリオにおける制御は、ＭＯＶＩＥモードだけでも、ブラウザモードだけでもよい。
（Ｂ）全ての実施形態では、本発明に係る光ディスクをＢＤ−ＲＯＭとして実施したが、本発明の光ディスクは、記録されるインターリーブユニットがあり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。光ディスクなら、どのような光ディスクであってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。
動的シナリオ、プレイリスト情報は、ＡＶストリーム及びストリーム管理情報と別々の記録媒体に記録されてもよい。そしてこれらをパラレルに読み出して、１つの映画作品として再生させてもよい。
（Ｃ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶストリームをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
（Ｄ）図２６、図３８、図４４に示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
（Ｅ）図２６、図３８、図４４のフローチャートにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフローチャートによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフローチャートの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
（Ｆ）Ｊａｖａモードのアプリケーションは、コンピュータ・グラフィックスを描画するようなアプリケーションであったが、Ｊａｖａ言語で記述されるアプリケーションであればどのようなものであってもよい。例えば電子商取引（ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ））のクライアントアプリケーションであってもよい。映画作品の動画を交えながら商品案内を行うようなＪａｖａモードのアプリケーションを実現することができるので、映画作品に関連するキャラクタビジネスを成功に導くことができる。またＪａｖａモードのアプリケーションは、ネット対戦型のオンラインゲームであってもよい。更に、Ｊａｖａモードのアプリケーションにてコンピュータ・グラフィックスにて表現されるキャラクタは、エージェントとしての処理を行うものであてもよい。エージェントとしてのキャラクタは、再生装置のヘルプ機能を実現するものであったり、ユーザに助言を行うものでもよい。
ＷｅｂＰａｇｅオブジェクトがＷＥＢサイトから取得する情報は、ＷＥＢページであってもよいし、画像データであってもよい。また、ＡＶストリーム、ストリーム管理情報、ＰＬ情報であってもよい。またＷｅｂＰａｇｅオブジェクトは、検索エンジンと連携して処理を行ってもよい。
更に、エンハンスドモードにおける記述言語は、Ｃ＋＋やＣ＃言語であってもよい。
（Ｇ）ＢＤ−ＲＯＭに記録するにあたって、ＡＶストリームを構成する各ＴＳパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケット（以下ＥＸ付きＴＳパケットと略す）は、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＥＸ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。３個のセクタに収められた３２個のＥＸ付きＴＳパケットを”Ａｌｉｇｎｅｄ  Ｕｎｉｔ”という。
ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてＡｌｉｇｎｅｄ  Ｕｎｉｔの送信を行う。つまり送り手側の機器は、Ａｌｉｇｎｅｄ  Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置２００はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
（Ｈ）第１２実施形態では、ＡＶストリームにコピー世代情報（ＣＧＩ）を埋め込んで、ＡＶストリームの制限付きコピーを認めてもよい。コピー世代情報には、自由にコピー可能な旨を示す『ｃｏｐｙ  ｆｒｅｅ』と、１世代の複製物の記録が許可されている旨を示す『ｏｎｅ  ｇｅｎｅｒａｔｉｏｎ  ｃｏｐｙ』と、複製物の更なる複製は禁止されている旨を示す『ｎｏ  ｍｏｒｅ  ｃｏｐｙ』と、一切のコピーを認めない旨を示す『ｎｅｖｅｒ  ｃｏｐｙ』とがある。つまり、コンテンツに埋め込まれたコピー世代情報が『ｃｏｐｙ  ｆｒｅｅ』や『ｏｎｅ  ｇｅｎｅｒａｔｉｏｎ  ｃｏｐｙ』を示している場合のみ、ＨＤからＤＶＤへのバックアップを行い、『ｎｏ  ｍｏｒｅ  ｃｏｐｙ』『ｎｅｖｅｒ  ｃｏｐｙ』を示している場合、バックアップは行わないのである。
（Ｉ）ＡＶストリームに権利管理情報は付加されている場合、第１２実施形態では権利管理情報に定められた利用条件において、ＡＶストリームのコピーを行うべきである。
権利管理情報において回数指定で、コピーの許可条件が規定されているなら、この条件内でコピーを行う。有効期間の指定（年月日の指定がでコピーの条件が規定されているのならこの条件内でコピーを行う。
（Ｊ）コピー処理に、移動やマイグレイト、チェックアウトといったバリエーションが存在する場合、これらバリエーション毎に、定められた利用条件に基づきバックアップを行っても良い。移動とは、コピー元のコンテンツの削除が伴うコピー処理であり、複数記録媒体間でコンテンツを移動する場合に用いられる。
マイグレイトとは、コピー先記録媒体において、利用条件情報を生成させることを前提にしたコピー処理である。
チェックアウトとは、回数制限されたコピーの一種であり、コピー回数を１回デクリメントした上でコンテンツのコピーが実行される。一般にいう回数制限付きのコピーと、チェックアウトとの違いは、コピー回数のインクリメントが可能である点である。コピー回数のインクリメントは、コピーにより記録媒体に記録されたコンテンツを再生不能にするという処理（”チェックイン”と呼ばれる。）を行った後でなされる。
（Ｋ）各実施形態におけるＡＶストリームは、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ  Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。また、各実施形態におけるＡＶストリームを、”ＡＶＣｌｉｐ”と呼んでもよい。この場合、ストリーム管理情報はＣｌｉｐ情報と呼ぶことになる。またＡＶストリームにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式であってもよい。
（Ｌ）各実施形態におけるＣｅｌｌ情報は、時間情報により再生区間の開始点、終了点を指定していたが、ＢＤ−ＲＯＭにおける論理アドレスを用いて再生区間の開始点、終了点を指定してもよい。また、各実施形態におけるＣＥＬＬを”ＰｌａｙＩｔｅｍ”と呼んでもよい。
（Ｍ）ストリーム管理情報におけるＴＭＡＰは、ＥＰ＿ｍａｐと呼んでもよい。この場合、ＡＣＣＥＳＳ  ＵＮＩＴの再生開始時刻を、ＡＣＣＥＳＳ  ＵＮＩＴ先頭に位置するピクチャデータのタイムスタンプ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）で表現するのが望ましい。またＡＣＣＥＳＳ  ＵＮＩＴにおけるアドレスは、ＰＥＳパケットの連番（ＳＰＮ（Ｓｅｒｉａｌ  Ｐａｃｋｅｔ  Ｎｕｍｂｅｒ））で表現するのが望ましい。
（Ｎ）再生装置の構成において、動的シナリオメモリ２１には、カレントの動的シナリオのみを格納し、静的シナリオメモリ１１には、カレントのストリーム管理情報、カレントのＰＬ情報のみを格納するとしたが、複数のシナリオ、ストリーム管理情報、ＰＬ情報を予め格納しておいてもよい。こうすれば、これらのデータをＢＤ−ＲＯＭから読み出すまでのタイムラグを短くすることができる。
（Ｏ）ＰＬを構成する２以上のＣＥＬＬを連続再生させるには、これらのＣＥＬＬがシームレス接続されよう、加工を施しておくことが望ましい。
シームレス接続のための加工は、動画データにおいて先行する側の再生区間の終端部と、後続する側の再生区間の先端部とを複製することにより、予め複製部分を作成しておき、これらを再エンコードすることで、実現される。尚、シームレス接続のために作成された複製部分を、Ｂｒｉｄｇｅ−Ｃｌｉｐと呼んでもよい。
ここで終端部、先端部は、以下のように設定するのが望ましい。
つまり先行するＶＯＢ＃ｘのうち先行再生区間のＯｕｔ点を含むＡＣＣＥＳＳ  ＵＮＩＴから、２個先のＡＣＣＥＳＳ  ＵＮＩＴまでを終端部とし、また後続するＣＥＬＬ情報＃ｘ＋１のうち後続再生区間のＩｎ点を含むＡＣＣＥＳＳ  ＵＮＩＴを先端部とするのが望ましい。終端部及び先端部をこのように定める根拠は、同出願人の先行技術米国特許ＵＳＰ，６１４８，１４０公報により記載されているので、詳細に関してはこの公報を参照されたい。
更に、シームレス接続のために作成された複製部分については、シームレス接続情報を設けておくことが望ましい。シームレス接続情報とは、最初のビデオフレームの再生開始時刻、最後のビデオフレームの再生終了時刻、オーディオギャップの開始時刻、オーディオギャップの時間長、オーディオギャップの位置情報を含む情報である。かかるシームレス接続情報が定義されていれば、最初のビデオフレームの再生開始時刻、最後のビデオフレームの再生終了時刻から、両区間のタイムスタンプの差（ＳＴＣ−Ｏｆｆｓｅｔ）を計算して、再生装置に設定することができる。また、これらオーディオギャップの情報を参照して、オーディオデコーダを制御すれば、１つの区間から別の区間への移行する際の音声の途切れを防止することができる。
（Ｐ）各実施形態における映画作品は、テレビ映画、ゲームソフト等、映像をもって表現されている全ての著作物を意味する。何故なら、各実施形態における映画作品は、ブラウン管や液晶での表示など、視覚的又は視聴覚的効果を生じさせる方法で表現され（ｉ）、ＢＤ−ＲＯＭという有体物に、何らかの方法で結びつくことにより同一性を保ちながら存続しており（ｉｉ）、かつ再現が可能な状態におかれているので（ｉｉｉ）、映画の著作物の存在形式としての要件を満たすからである。
しかし本発明の本質的要素は、この映画作品であることに限定されるものではないので、本発明の動画データは、監視カメラの映像や家庭用ビデオカメラの映像であってもよい。
（Ｑ）第２実施形態において描画系データは、コンピュータ・グラフィックスのデータであってもよい。かかるデータには、ＮＵＲＢＳ（Ｎｏｎ  Ｕｎｉｆｏｒｍ  Ｒａｔｉｏｎａｌ  Ｂ−Ｓｐｌｌｉｎｅ）形式のデータ、ポリゴン形式がある。ＮＵＲＢＳとは、ベジェ曲線の束であって（このようなベジェ曲線の束はＢ−Ｓｐｌｌｉｎｅと呼ばれる。）、それぞれのベジェ曲線の曲率が不均一なものをいう。
ポリゴン形式とは、多面体近似により特定の立体形状を表現するよう規定されたデータ形式であり、アメリカ・オートキャド社が規定したＤａｔａ  ｅＸｃａｎｇｅ  Ｆｏｒｍａｔ（ＤＸＦ）を初め、ＨＲＣ，ＷＡＶＥＦＲＯＮＴ，ＩＶ，ＶＲＭＬ形式等のものが広く知られている。
また第２実施形態に示したイメージ系データを、テクスチャマッピングに利用してもよい。テクスチャマッピングとは、三次元形状の平面又は曲面に、静止画、ビットマップ等のテクスチャパターンを貼り付けて表示させる処理をいう。コンピュータ・グラフィックスの描画のため、ＯＰＥＮ−ＧＬやＪａｖａ３Ｄ等のプログラムを、インターリブ記録しておいてもよい。
（Ｒ）各実施形態では、ユーザによる映画作品の選択操作を、リモコンから受け付けたが、再生装置のフロントパネルから受け付けてもよい。キーボード、タッチパネル、マウスやパッド、トラックボール等の入力機器にてユーザの指定を受け付けてもよい。この場合は、クリック操作、ドラッグ操作でこれらの操作を受け付けてもよい。
（Ｓ）各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
（Ｔ）Ｊａｖａモジュール１７は、衛星放送受信のために機器に組み込まれたＪａｖａプラットフォームであってもよい。Ｊａｖａモジュール１７がかかるＪａｖａプラットフォームであれば、本発明に係る再生装置は、ＭＨＰ用ＳＴＢとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたＪａｖａプラットフォームであってもよい。かかるＪａｖａモジュール１７がかかるＪａｖａプラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
またＢＲＯＷＳＥＲモジュール１８は、ＭｉｃｒｏＳｏｆｔ社のＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅ等、パソコン組み込み型のブラウザソフトであってもよい。
【符号の説明】
１    ＢＤドライブ
２    トラックバッファ
３    デマルチプレクサ
４    ビデオデコーダ
５    ピクチャプレーン
６    オーディオデコーダ
８    イメージプレーン
９    イメージデコーダ
１０    加算器
１１    静的シナリオメモリ
１２    再生制御エンジン
１３    プレーヤレジスタ
１４    メモリ
１５    スイッチャ
１６    ＤＶＤライクモジュール
１８    ＢＲＯＷＳＥＲモジュール
１７    Ｊａｖａモジュール
１９    ＵＯマネージャ
２１    動的シナリオメモリ
２００    再生装置
３００    テレビ
４００    リモコン
【産業上の利用可能性】本発明に係る光ディスクは、ゲームソフトの動作環境を、映画作品を再生するための動作環境に近づけることができるので、より魅力ある映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る光ディスク、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図１】
2004034395.tif 000003
【図２】
2004034395.tif 000004
【図３】
2004034395.tif 000005
【図４】
2004034395.tif 000006
【図５】
2004034395.tif 000007
【図６】
2004034395.tif 000008
【図７】
2004034395.tif 000009
【図８】
2004034395.tif 000010
【図９】
2004034395.tif 000011
【図１０】
2004034395.tif 000012
【図１１】
2004034395.tif 000013
【図１２】
2004034395.tif 000014
【図１３】
2004034395.tif 000015
【図１４】
2004034395.tif 000016
【図１５】
2004034395.tif 000017
【図１６】
2004034395.tif 000018
【図１７】
2004034395.tif 000019
【図１８】
2004034395.tif 000020
【図１９】
2004034395.tif 000021
【図２０】
2004034395.tif 000022
【図２１】
2004034395.tif 000023
【図２２】
2004034395.tif 000024
【図２３】
2004034395.tif 000025
【図２４】
2004034395.tif 000026
【図２５】
2004034395.tif 000027
【図２６】
2004034395.tif 000028
【図２７】
2004034395.tif 000029
【図２８】
2004034395.tif 000030
【図２９】
2004034395.tif 000031
【図３０】
2004034395.tif 000032
【図３１】
2004034395.tif 000033
【図３２】
2004034395.tif 000034
【図３３】
2004034395.tif 000035
【図３４】
2004034395.tif 000036
【図３５】
2004034395.tif 000037
【図３６】
2004034395.tif 000038
【図３７】
2004034395.tif 000039
【図３８】
2004034395.tif 000040
【図３９】
2004034395.tif 000041
【図４０】
2004034395.tif 000042
【図４１】
2004034395.tif 000043
【図４２】
2004034395.tif 000044
【図４３】
2004034395.tif 000045
【図４４】
2004034395.tif 000046
【図４５】
2004034395.tif 000047
【図４６】
2004034395.tif 000048
【図４７】
2004034395.tif 000049
【図４８】
2004034395.tif 000050
【図４９】
2004034395.tif 000051
【図５０】
2004034395.tif 000052
【図５１】
2004034395.tif 000053
【国際調査報告】
2004034395.tif 000054
2004034395.tif 000055
2004034395.tif 000056