(57)【特許請求の範囲】
【請求項１】
デジタルストリームを記録した光ディスクであって、
デジタルストリームは、n個のセグメントに分割されて光ディスクに記録されていて、
n個のセグメントのうち、第i番目に再生されるものの前に、インターリーブユニットが記録されており、
ここでi,nは、i＜nを満たす整数であり、
インターリーブユニットは、第i番目のセグメントの再生に同期するプログラムによって構成される
ことを特徴とする光ディスク。
【請求項２】
インターリーブユニットは終了時点情報を含み、
終了時点情報は、デジタルストリームの再生時間軸上におけるどの時点でメモリに読み出されたプログラムを削除するかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項３】
インターリーブユニットは開始時点情報を含み、
開始時点情報は、インターリーブユニット内に含まれるプログラムの利用が、デジタルストリームの再生時間軸上におけるどの時点から、可能になるかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項４】
第i番目のセグメントと、第i+1番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されている
ことを特徴とする請求項１記載の光ディスク。
【請求項５】
第i番目のセグメントと、第i+1番目のセグメントとの境界は、プログラムの生存区間の途中にあたる
ことを特徴とする請求項４記載の光ディスク。
【請求項６】
第i番目のセグメントと、第i+1番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあたる
ことを特徴とする請求項４記載の光ディスク。
【請求項７】
i番目のセグメントは、複数のアクセスユニットからなり、各アクセスユニットはイントラ符号化されたピクチャを有した動画データを含み、
光ディスクにはマップ情報が記録されており、
マップ情報は、i番目セグメントに先行するインターリーブユニットを、第i番目セグメントに属するアクセスユニットのアドレス又は再生時間と対応づけて示す
ことを特徴とする請求項１記載の光ディスク。
【請求項８】
前記iは2以上であり、
i番目のセグメントと、i-1番目のセグメントとの境界は、デジタルストリームの再生時間軸において、プログラムの生存区間の開始点にあたる  ことを特徴とする請求項１記載の光ディスク。
【請求項９】
前記生存区間とは、デジタルストリームの再生時間軸上において、インターリーブユニット内のプログラムの利用が可能となる区間である、請求項８記載の光ディスク。
【請求項１０】
前記プログラムは所定のイベントで駆動されるイベントハンドラであり、
イベントハンドラを含むインターリーブユニットは、デジタルストリームの再生時間上において、前記イベントが発生する時点より前に記録されている、請求項１記載の光ディスク。
【請求項１１】
所定のイベントとは、現在の再生時点が再生時間軸上の所定の時点に到達したことを示すイベント、
再生時間軸上の所定の時間帯にてユーザ操作がなされたことを示すイベント、  再生経路による再生に先立ち発生するイベント、
再生経路による再生後に発生するイベント、
再生装置が発生するイベント、
他のプログラムにより発生されるイベントの何れかである、請求項１０記載の光ディスク。
【請求項１２】
光ディスクには、インターリーブユニット統合情報が記録されており、
インターリーブユニット統合情報は、光ディスクに記録された複数インターリーブユニットのそれぞれの識別情報を、プログラムのサイズ及び生存区間に対応づけて示す情報である
ことを特徴とする請求項１記載の光ディスク。
【請求項１３】
前記光ディスクにはプレイリスト情報、動的シナリオが記録されており、
プレイリスト情報は、動画データにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、
動的シナリオは、1つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、
インターリーブユニットは、識別情報を有しており、
識別情報は、再生経路、再生区間、映像タイトル全体、映像タイトルの章の何れかを、プログラムの生存区間として示す
ことを特徴とする請求項１記載の光ディスク。
【請求項１４】
インターリーブユニットはロケータを含んでおり。
ロケータは、ドライブ情報と、パス情報とを含み、
ドライブ情報は、プログラムを読み出すべき読出先のドライブを示し、
パス情報は、そのドライブの階層構造のうち、どの階層にプログラムが存在するかを示す
ことを特徴とする請求項１記載の光ディスク。
【請求項１５】
デジタルストリームを記録した光ディスクについての再生装置であって、
デジタルストリームを構成するn個のセグメントのうちi番目セグメントを、i番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出手段と(i,nは、i＜nを満たす整数)、
読み出されたi番目セグメントを再生する再生手段と、
読み出されたインターリーブユニット内のプログラムを用いて、セグメント再生と同期した処理を行う処理手段と
を備えることを特徴とする再生装置。
【請求項１６】
前記読出手段により読み出されたインターリーブユニットを格納するメモリと、
読出手段により読み出されたセグメントを格納するトラックバッファとを備え、
前記再生手段は、トラックバッファを介してセグメントの供給を受け、
前記処理手段は、メモリを介してインターリーブユニットの供給を受ける
ことを特徴とする請求項１５記載の再生装置。
【請求項１７】
前記再生装置は、スイッチャを備え、
前記読出手段は、光ディスクにおけるセクタを読み取る度に、そのセクタのアドレスの通知を行い、
スイッチャは、読出手段から通知されたセクタアドレスが、インターリーブユニットの占有領域内であれば、セクタからの読取情報をメモリに書き込み、
読出手段から通知されたアドレスが、セグメントの占有領域内であれば、セクタからの読取情報を順次トラックバッファに書き込み、
前記メモリ上のインターリーブユニットは、スイッチャによりメモリに書き込まれた読取情報から構成され、
前記トラックバッファ上のセグメントは、スイッチャによりトラックバッファに書き込まれた読取情報から構成されることを特徴とする請求項１６記載の再生装置。
【請求項１８】
前記インターリーブユニットと、デジタルストリームとは光ディスクにおいて別々のファイルに格納されており、
光ディスクにはファイル管理情報が記録されており、
ファイル管理情報は、ファイルの識別情報と、光ディスクにおけるデジタルストリーム又はインターリーブユニットのアドレスとを対応づけて示し、
現在の読取位置が光ディスクにおけるインターリーブユニットの占有領域内であるか、セグメントの占有領域内であるかのスイッチャによる判定は、ファイル管理情報を参照してなされることを特徴とする請求項１７記載の再生装置。
【請求項１９】
前記インターリーブユニットと、デジタルストリームとは光ディスクにおいて複数ファイルのそれぞれに格納されており、
光ディスクにはファイル管理情報が記録されており、
ファイル管理情報は、ファイルの識別情報と、光ディスクにおけるデジタルストリーム又はインターリーブユニットのアドレスとを対応づけて示し、
読出手段は、前記複数ファイルをオープンして、インターリーブユニットを格納したファイルの読出先をメモリに指定し、デジタルストリームを格納したファイルの読出先をトラックバッファに指定した上で読み出しを行う
ことを特徴とする請求項１６記載の再生装置。
【請求項２０】
前記インターリーブユニットは終了時点情報を含み、
前記処理手段は、
再生手段による現在の再生時点が終了時点情報に示される終了時点になれば、メモリからインターリーブユニットを削除する
ことを特徴とする請求項１６記載の再生装置。
【請求項２１】
前記処理手段は仮想マシン部を備え、
処理手段は、アプリケーションプログラムからの要求に応じて、前記メモリ上のインターリーブユニット内のプログラムを仮想マシン部内のワーク領域に供給して、仮想マシン部に実行させる
ことを特徴とする請求項１６記載の再生装置。
【請求項２２】
前記インターリーブユニットは開始時点情報を含み、
処理手段が、アプリケーションプログラムからの要求に応じて、前記メモリ上のインターリーブユニット内のプログラムを仮想マシン部内のワーク領域に供給するのは、再生手段による現在の再生時点が開始時点情報に示される開始時点に達した場合であり、
再生手段による現在の再生時点が開始時点情報に示される開始時点に達していなければ、アプリケーションプログラムからの要求があってもインターリーブユニット内のプログラムを仮想マシン部内のワーク領域に供給しない、請求項２１記載の再生装置。
【請求項２３】
前記第i番目のセグメントと、第i+1番目のセグメントとの境界は、プログラムの生存区間の途中にあたる位置であり、
第i番目のセグメントと、第i+1番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されており、
前記読出手段は、
i番目セグメントの内部に頭出しを行う場合、前記複製物を光ディスクから読み出す、請求項１５記載の再生装置。
【請求項２４】
前記第i番目のセグメントと、第i+1番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあり、
第i番目のセグメントと、第i+1番目のセグメントとの間にインターリーブユニットの複製物が、記録されており、
前記読出手段がi番目セグメントを読み出すのは、再生手段が通常再生を行う場合であり、
再生手段が逆方向再生を行う場合、デジタルストリームを構成する複数セグメントのうちi+1番目セグメントを、i+1番目セグメントに先行する複製物と共に光ディスクから読み出すことを特徴とする請求項１５記載の再生装置。
【請求項２５】
前記i番目のセグメントは、複数のアクセスユニットからなり、各アクセスユニットはイントラ符号化されたピクチャを有した動画データを含み、
光ディスクにはマップ情報が記録されており、
マップ情報は、i番目セグメントに先行するインターリーブユニットを、第i番目セグメントに属するアクセスユニットのアドレス又は再生時間と対応づけて示しており、
前記読出手段によるインターリーブユニットの読み出しは、マップ情報を参照してなされることを特徴とする請求項１５記載の再生装置。
【請求項２６】
前記処理手段は、仮想マシン部を備え、
再生手段は、デジタルストリームを再生すると共に、再生に同期したイベントの発生を行い、
前記仮想マシン部は、再生手段がイベントを発生すると、インターリーブユニット内のプログラムを実行することを特徴とする請求項１５記載の再生装置。
【請求項２７】
前記イベントとは、
現在の再生位置が、動画データの再生時間軸における所定の時点に到達したことを示すイベント、
再生装置が発生するイベント、
他のプログラムにより発生されるイベントの何れかである、
ことを特徴とする請求項２６記載の再生装置。
【請求項２８】
前記光ディスクにはマーク情報が記録されており、
マーク情報は、
前記再生時間軸における所定の時点、及び、所定の時間間隔を定義する情報であり、
再生手段によるイベント発生は、このマーク情報に基づいて行われる
ことを特徴とする請求項２７記載の再生装置。
【請求項２９】
前記再生装置は、ユーザ操作を受け付ける受付手段を備え、
前記イベントとは、
動画データの再生時間軸上の所定の時間帯において、受付手段がユーザ操作を受け付けたことを示すイベントである請求項２７記載の再生装置。
【請求項３０】
光ディスクには、インターリーブユニット統合情報が記録されており、  インターリーブユニット統合情報は、光ディスクに記録された複数インターリーブユニットに対する管理情報であり、
前記再生装置は、メモリ、再生制御手段を備え、
再生制御手段は、複数インターリーブユニットを、前記メモリに格納することができるか否かを、インターリーブユニット統合情報に基づき判定し、
前記読出手段は、前記再生制御手段が読み出すことができると判定した場合に複数インターリーブユニットの一部又は全部の読み出しを行う、請求項１５記載の再生装置。
【請求項３１】
前記光ディスクにはプレイリスト情報が記録されており、
プレイリスト情報は、デジタルストリームにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、
前記再生装置は、再生制御手段を備え、
前記再生制御手段は、プレイリスト情報及び動的シナリオを用いたデジタルストリームの再生を行うよう読出手段及び再生手段を制御する
ことを特徴とする請求項１５記載の再生装置。
【請求項３２】
インターリーブユニットは、識別情報を有しており、
前記再生装置は、再生制御手段を備え、
前記再生制御手段は、プレイリスト情報を用いたデジタルストリームの再生を行うにあたって、
そのプレイリスト情報の識別情報を有したインターリーブユニット、
そのプレイリスト情報における再生区間を示す情報の識別情報を有したインターリーブユニット、
の何れかを光ディスクから読み出すよう読出手段を制御する
ことを特徴とする請求項３１記載の再生装置。
【請求項３３】
前記光ディスクには動的シナリオが記録されており、
動的シナリオは、プレイリスト情報に示される1つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、
前記再生装置は、再生制御手段を備え、
前記再生制御手段は、
その動的シナリオに対応するタイトルの識別情報を有したインターリーブユニット、
その動的シナリオに対応するタイトル中のチャプターの識別情報を有したインターリーブユニット、
の何れかを光ディスクから読み出すよう読出手段を制御する
ことを特徴とする請求項３１記載の再生装置。
【請求項３４】
インターリーブユニットはロケータを含んでおり。
ロケータは、ドライブ情報と、パス情報とを含み、
ドライブ情報は、プログラムを読み出すべき読出先のドライブを示し、
パス情報は、そのドライブの階層構造のうち、この階層にプログラムが配されるべきかを示し、
前記再生装置は、ロケータのドライブ情報に示されるドライブの階層構造のうち、パス情報に示される階層に、プログラムを配する
ことを特徴とする請求項１５記載の再生装置。
【請求項３５】
デジタルストリームを記録した光ディスクについての再生プログラムであって、
デジタルストリームを構成する複数セグメントのうちi番目セグメントを、i番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出ステップと、
読み出されたi番目セグメントを再生する再生ステップと、
読み出されたインターリーブユニット内のプログラムを用いて、セグメント再生と同期した処理を行う処理ステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項３６】
デジタルストリームを記録した光ディスクについての再生方法であって、
デジタルストリームを構成する複数セグメントのうちi番目セグメントを、i番目セグメントに先行するインターリーブユニットと共に光ディスクから読み出す読出ステップと、
読み出されたi番目セグメントを再生する再生ステップと、
読み出されたインターリーブユニット内のプログラムを用いて、セグメント再生と同期した処理を行う処理ステップと
を有する再生方法。
【請求項３７】
光ディスクの記録方法であって、
アプリケーションデータを作成するステップと、
作成したデータを光ディスクに記録するステップとを有し、
前記アプリケーションデータは、デジタルストリームと、インターリーブユニットとを含み、
デジタルストリームは、n個のセグメントに分割されて光ディスクに記録されており、
n個のセグメントのうち、i番目に再生されるものの前に、インターリーブユニットが記録され、
ここでi,nは、i＜nを満たす整数であり、
インターリーブユニットは、i番目のセグメントの再生に同期するプログラムによって構成される
ことを特徴とする記録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Blu-Ray Disc Read Only Memory(以下BD-ROMと略す)等のデジタルストリーム用の光ディスク、光ディスクの再生装置、プログラム、再生方法、記録方法に関し、光ディスクにより映画作品等を頒布する技術に関する。
【背景技術】
【０００２】
光ディスクによる映画作品の頒布にあたっては、キャラクタについての映画作品と、キャラクタに関するゲームとを同じ光ディスクに記録して販売するというキャラクタビジネスがある。光ディスクに記録されるゲームは、クイズ形式の簡単なものから、三次元コンピュ−タ・グラフィックスを取り入れた本格的なものに発展する傾向がある。映画作品本編を構成するAVデータと同じ光ディスクに、ゲームプログラムのような非AVデータを記録しておく先行技術には、以下の特許文献1に記載された技術がある。
【先行文献】
【０００３】
【特許文献】
【０００４】
【特許文献１】
特許3069324号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながらコンピュ−タ・グラフィックスを用いた本格的なゲームは、動作のためにコンピュ−タ・グラフィックス描画のためのライブラリ等、様々なライブラリをメモリにロードしておき、アプリケーションプログラムに利用させる必要がある。そのためDVDプレーヤ等の民生機器のハードウェアスペックでは、かかる動作環境を満足させることはできず、パソコン等の他の動作環境での使用をユーザに喚起せねばならない。そうなると、ゲーム等の実行にあたっては、「推奨メモリ:128Mバイト以上」というような動作環境での使用をユーザに求めることが多くなる。
【０００６】
たとえ本格的なゲームが記録されていたとしても、ゲームの動作環境が、映画作品本編の動作環境と著しくかけ離れているのなら、ユーザの消費欲を冷めさせてしまう恐れがある。これでは、多大な開発費用をかけてゲームを制作し、映画作品と同じ光ディスクに記録する意義がなくなってしまう。
【０００７】
本発明の目的は、ゲームを実現するようなプログラムを光ディスクに記録して頒布する場合に、そのプログラムの動作環境を、映画作品本編の動作環境に近づけることができる光ディスクを提供することである。
【課題を解決するための手段】
【０００８】
上記目的は、デジタルストリームを記録した光ディスクであって、デジタルストリームは、n個のセグメントに分割されて光ディスクに記録されていて、n個のセグメントのうち、第i番目に再生されるものの前に、インターリーブユニットが記録されており、ここでi,nは、i＜nを満たす整数であり、インターリーブユニットは、第i番目のセグメントの再生に同期するプログラムによって構成される光ディスクにより達成される。
【発明の効果】
【０００９】
セグメント再生と同期実行すべきプログラムはインターリーブユニットという形でセグメントの前に配置されており、セグメントの再生時にあたっては光ピックアップによる読み取り位置をセグメントの先頭位置からずらせば、デジタルストリームを構成するセグメントを、同期実行すべきプログラムと共に読み出すことができる。同期処理に必要なプログラムは、セグメントの読み出し時にセグメントと併せて光ディスクから読み出せば足り、セグメントとの同期処理が済めば、メモリから削除すればよいので、デジタルストリーム再生の全区間を通じてプログラムを常駐しておく必要はない。デジタルストリームとの同期処理を行うべきプログラムが複数あっても、個々のプログラムの実行が終わる度に、プログラムからメモリを回収するという原則でリソース管理を行えば、セグメント再生との同期時に、プログラムをロードし得るだけのメモリを再生装置に実装しておけばよい。必要最低限のメモリ規模で、デジタルストリーム再生と、様々なプログラムとの同期処理を実現することができる。
【００１０】
ここでインターリーブユニットは終了時点情報を含み、終了時点情報は、デジタルストリームの再生時間軸上におけるどの時点でメモリに読み出されたプログラムを削除するかを示していてもよい。
【００１１】
インターリーブユニットにおける終了時点情報の設定により、インターリーブユニットを何時からメモリに読み込み、何時までにインターリーブユニットをメモリから削除するかというリソース管理を、光ディスクのプレオーサリングの段階で決めておくことができる。これに基づくプログラミングを行えば、デジタルストリームにおけるAV再生との同期を行うようなゲームソフトを、小メモリ規模で実現することができる。ソフトハウスのプログラマにとって、AV再生との同期を小メモリ規模で実現できる動作環境は魅力的であり、多くのソフトハウスの参入を促すことにより映画業界や民生機器業界を活性化することができる。
【００１２】
インターリーブユニットは開始時点情報を含み、開始時点情報は、インターリーブユニット内に含まれるプログラムの利用が、デジタルストリームの再生時間軸上におけるどの時点から、可能になるかを示していてもよい。
【００１３】
たとえ3つのライブラリが光ディスク上でバラバラに配置されたとしても、これらを同じ時点で利用可能とするよう、ヘッダにおける開始時点情報で調整することができる。
ここで第i番目のセグメントと、第i+1番目のセグメントとの間には、前記インターリーブユニットの複製物が記録されていてもよい。
【００１４】
第i番目のセグメントと、第i+1番目のセグメントとの境界は、プログラムの生存区間の途中にあたる位置であってもよい。
セグメントのうち、再生区間の開始点等頭出しが多く発生しうる位置の後にインターリーブユニット複製物を配置しておけば、セグメント前に配置されているインターリーブユニットまでディスクシークを行わなくとも、アプリケ−ションプログラムによるライブラリ利用が可能となる。再生経路情報に基づく再生を行うため頭出しが多く発生したとしても、スムーズな読み取りが可能となる。
【００１５】
ここで第i番目のセグメントと、第i+1番目のセグメントとの境界は、前記プログラムの生存区間の終了点より後にあたる位置であってもよい。
デジタルストリームの再生時間軸を未来から過去に遡って行き、プログラムの生存区間に到達した場合でも、不要なシークを行うことなく光ディスクからメモリへのプログラム読み出しを実現することができる。逆方向再生のような変則的な再生進行が行われる場合でも、メモリへのプログラム読み出しを実現出来るので、AV再生との同期を前提とした様々なな処理を、逆方向再生時でも実現することができる。
【００１６】
ここで前記光ディスクにはプレイリスト情報、動的シナリオが記録されており、プレイリスト情報は、動画データにおける再生区間を示す情報を、再生順序に従って配列することにより再生経路を定義する情報であり、動的シナリオは、1つ以上の再生経路の再生手順を示すことにより、映像タイトルを定義する情報であり、インターリーブユニットは、識別情報を有しており、識別情報は、再生経路、再生区間、映像タイトル全体、映像タイトルの章の何れかを、プログラムの生存区間として示していてもよい。
【００１７】
動的シナリオ、プレイリスト情報の番号等を用いて生存区間を定義しているので、インターリーブユニット同士の生存区間の重なりの把握が容易となり、リソース管理を念頭においたインターリーブユニットの読み取り計画が立て易くなる。
【図面の簡単な説明】
【００１８】
【図１】本発明に係る光ディスクの使用行為についての形態を示す図である。
【図２】BD-ROMの構成を示す図である。
【図３】ディレクトリ構造を用いてBD-ROMの応用層フォーマットを表現した図である。
【図４】機能的な観点から、ファイルを分類した場合の分類図である。
【図５】BD-ROMが対象としているソフトウェアのレイアモデルを示す図である。
【図６】AVストリームがどのように構成されているかを模式的に示す図である。
【図７】AVストリームがどのようにBD-ROMに記録されるかを模式的に示す図である。
【図８】ストリーム管理情報の内部構成を示す図である。
【図９】PL情報の内部構成を示す図である。
【図１０】PL情報による間接参照を模式化した図である。
【図１１】図１０に示したPLと、別のPLを定義する場合の一例を示す図である。
【図１２】レイヤモデルの第４層(動的シナリオ)における再生モードを示す図である。
【図１３】Java言語が対象とする制御ソフトウェアのレイアモデルを示す図である。
【図１４】生存区間設定の対象となるAVストリームを示す図である。
【図１５】  （ａ）BD-ROMに対しセグメントがどのように記録されるかを示す図である。
【００１９】
（ｂ）セグメントi、セグメントi+1を順次読み出す場合の、光ピックアップによる読み出し経路を示す。
【図１６】セグメントi+1内に頭出しが発生した場合の光ピックアップの移動経路を示す図である。
【図１７】AVストリームの再生時間軸上の4つの時点t1,t2,t3,t4においてメモリへのライブラリの読み出し、及び、Java仮想マシンのワーク領域へのライブラリロードがどのように行われるかを示す図である。
【図１８】インターリーブユニットの構成を示す図である。
【図１９】TMAPにおけるACCESS UNITエントリーの改良を示す図である。
【図２０】AVストリームを構成するセグメントが読み取られる際のトラックバッファの状態遷移を示す図である。
【図２１】映画作品の動画を背景画とし、コンピュ−タ・グラフィックスを前景画とした合成画面から構成されるゲームプログラムを示す図である。
【図２２】  （ａ）ライブラリ＃1,＃2,＃3,＃4の生存区間を示す図である。
【００２０】
（ｂ）各ライブラリの生存区間のIN点と、セグメントとの関係を示す図である。
【図２３】BD-ROMに対し、セグメントがどのように記録されているかを示す図である。
【図２４】インターリーブユニットの内部構成を示す図である。
【図２５】本発明に係る再生装置の内部構成を示す図である。
【図２６】再生制御エンジン１２の実行手順を示すフローチャートである。
【図２７】図２５に示した構成要素のうち、ライブラリに係るものを抜き出して描いた図である。
【図２８】Java言語が対象とするレイアモデルにおいて、表示用データが何処に位置するかを示す図である。
【図２９】表示用データたるインターリーブユニットの構成を示す図である。
【図３０】再生装置内部における表示用データが表示に至るまでの経路を示す。
【図３１】セグメント内部のどこに、インターリーブユニット複製物を組み込むかを示す図である。
【図３２】セグメントiの内部に対して頭出しを行う場合、プログラムがどのように読み取られるかを示す図である。
【図３３】図２２に示した4つのライブラリ＃1,＃2,＃3,＃4と、セグメントとの関係を示す図である。
【図３４】  （ａ）インターリーブユニット、セグメント、インターリーブユニット複製物の配置を示す図である。
【００２１】
（ｂ）図３４（ａ）に、i+1番目のセグメントを書き加えた図である。
【図３５】インターリーブユニット複製物がない場合に逆方向再生がどのように行われるかを示す図である。
【図３６】インターリーブユニット複製物が配置されたBD-ROMにおけるシーク動作を示す図である。
【図３７】図２２に示した4つのライブラリ＃1,＃2,＃3,＃4と、セグメントとの関係を示す図である。
【図３８】ユーザにより逆方向再生操作が命じられた際の再生制御エンジン１２の処理手順を示すフローチャートである。
【図３９】第５実施形態に係るBD-ROMのファイル構成を示す図である。
【図４０】PLMark及びClipMarkの共通構成を示す図である。
【図４１】（ａ）（ｂ）プレイリスト＃1の再生中に出現するTimeEventを定義する場合のPLMarkの記述例を示す図である。
【図４２】プレイリスト＃1の再生中においてUserEventを定義する場合のPLMarkの記述例を示す図である。
【図４３】ClipMark、PLにてTimeEvent、UserEventが定義されている場合のインターリーブユニットの配置例を示す図である。
【図４４】再生制御エンジン１２の処理手順を示す図である。
【図４５】インターリーブユニットに関する情報の間接参照がどのように行われるかを示す図である。
【図４６】AVストリームに組み込まれた3つのインターリーブユニットと、インターリーブユニット統合情報との対応を示す図である。
【図４７】第７実施形態に係るインターリーブユニットにて、生存区間がどのように表記されるかを示す図である。
【図４８】ロケータの記述によるプログラム又は表示用データの階層化配置を模式的に示す図である。
【図４９】第９実施形態に係る再生装置の内部構成を示す図である。
【図５０】第１１実施形態に係るBD-ROMの製造工程を示すフローチャートである。
【図５１】複数の表示データたるインターリーブユニットを示す図である。
【発明を実施するための形態】
【００２２】
(第１実施形態)
以降、本発明に係る光ディスクの実施形態について説明する。先ず始めに、本発明に係る光ディスクの実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る光ディスクの、使用行為についての形態を示す図である。図１において、本発明に係る光ディスクは、BD-ROM１００である。このBD-ROM１００は、再生装置２００、テレビ３００、リモコン４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００２３】
続いて本発明に係る光ディスクの実施行為のうち、生産行為についての形態について説明する。本発明に係る光ディスクは、BD-ROMの応用層に対する改良により実施することができる。図２は、BD-ROMの構成を示す図である。
【００２４】
図２は、BD-ROMの構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。図２に示すようなデータフォーマットを、BD-ROMの応用層上に形成することにより本発明に係る光ディスクは、工業的に生産される。
【００２５】
図３は、ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーション)を表現した図である。本図に示すようにBD-ROMには、ROOTディレクトリの下にBD-AVディレクトリがあり、その下にJCLASSディレクトリ、BROWSERディレクトリがある。
【００２６】
BDAVディレクトリの配下には、INFO.BD,XXX.M2TS,XXX.CLPI,YYY.PL,ZZZ.MOVIEといったファイルが存在する。JCLASSディレクトリの配下には、ZZZ.CLASSというファイルが、BROWSERディレクトリの配下には、ZZZ.HTMというファイルが配置されている。
【００２７】
図４は、機能的な観点から、これらのファイルを分類した場合の分類図である。本図において、第１層、第２層、第３層、第４層からなる階層が本図における分類を象徴的に示す。本図においてXXX.M2TSは第２層に分類される。XXX.CLPI,YYY.PLは、第３層(静的シナリオ)に分類される。BDAVディレクトリ配下のZZZ.MOVIE、JCLASSディレクトリ配下のZZZ.CLASS、BROWSERディレクトリ配下のZZZ.HTMは、第４層に分類される。
【００２８】
本図の分類(第１層〜第４層)は、図５に示すようなレイヤモデルを対象とした分類である。以降、図５を参照しながら、BD-ROMが対象としている、制御ソフトウェアのレイアモデルについて説明する。
【００２９】
図５の第１層は、物理層であり、処理対象たるストリーム本体の供給制御である。この第１層に示すように、処理対象たるストリームは、BD-ROMだけではなく、HD、メモリカード、ネットワークといったあらゆる記録媒体、通信媒体を供給源としている。これらHD、メモリカード、ネットワークといった供給源に対する制御(ディスクアクセス、カードアクセス、ネットワーク通信)が第１層の制御である。
【００３０】
第２層は、復号化方式のレイアである。第１層で供給されたストリームを、どのような復号化方式を用いて復号するのかを規定しているのがこの第２層である。本実施形態で採用する復号化方式は、MPEG2の復号化方式である。
【００３１】
第３層(静的シナリオ)は、ストリームの静的なシナリオを規定するレイアである。静的なシナリオとは、ディスク制作者によって予め規定された再生経路情報、ストリーム管理情報であり、これらに基づく再生制御を規定しているのがこの第３層(静的シナリオ)である。
【００３２】
第４層は、ストリームにおける動的なシナリオを実現するレイヤである。動的なシナリオとは、ユーザ操作や装置の状態によって再生進行を動的に変化させるためのシナリオであり、これらに基づく再生制御を規定しているのがこの第４層である。以降、このレイヤモデルに従い、ストリーム本体、静的なシナリオにあたるファイルについて説明してゆく。
【００３３】
先ず第２層に属するストリーム(XXX.M2TS)について説明する。
AVストリーム(XXX.M2TS)は、MPEG-TS(Transport Stream)形式のデジタルストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、1つ以上の副映像ストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、副映像ストリームは、映画の字幕をそれぞれ示している。図６は、AVストリームがどのように構成されているかを模式的に示す図である。
【００３４】
AVストリームは(第４段目)、複数のビデオフレーム(ピクチャpj1,2,3)からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを(第１段目)、PESパケット列に変換し(第２段目)、更にTSパケット列に変換し(第３段目)、同じく副映像ストリーム(第７段目)を、PESパケット列に変換し(第６段目)、更にTSパケット列に変換して(第５段目)、これらを多重化することで構成される。この多重化は、オーディオフレームが、同じ時刻にBD-ROMから読み出されるべきビデオフレームの近くにくるように、ビデオフレームを格納したTSパケット、オーディオフレームを格納したTSパケットを並べるというものである。
【００３５】
かかる過程を経て生成されたAVストリームは、通常のコンピュータファイル同様、複数のセグメントに分割され、BD-ROM上の領域に記録される。図７はAVストリームがどのようにBD-ROMに記録されるかを模式的に示す図である。
【００３６】
AVストリームを構成する各セグメントが、どれだけの長さであり、BD-ROMにおいてどのアドレスに記録されているかは、ファイル管理情報fk1に記述される。
ファイル管理情報fk1には、AVストリームを分割することで得られる3つのセグメント1/3,2/3,3/3のそれぞれについて、セグメントのアドレス(adr1,2,3)、長さ(length1,2,3)が記述されていることがわかる。AVストリームは、1つ以上のACCESS UNITとからなり、このACCESS UNITの単位で頭出し可能である。ACCESS UNITとは、1つのGOP(Group Of Picture)と、このGOPと同時に読み出されるべきオーディオフレームとを含む最小デコード単位である。GOPは、過去方向および未来方向に再生されるべき画像との時間相関特性を用いて圧縮されているBidirectionally predictive Predictive(B)ピクチャ、過去方向に再生されるべき画像との時間相関特性を用いて圧縮されているPredictive(P)ピクチャ、時間相関特性を用いず、一フレーム分の画像内での空間周波数特性を利用して圧縮されているIntra(Ｉ)ピクチャを含む。
【００３７】
尚、ファイル名XXX.M2TSのファイルボディ「XXX」は、BD-ROMにおいてAVストリームに付与される3桁の識別番号を抽象化している。つまり本図におけるAVストリームは、このXXXを用いて一意に識別される。以上がストリーム(XXX.M2TS)についての説明である(ここでの3桁という桁数は例示に過ぎず、何桁でもよい。)。＜静的なシナリオ＞
続いて、静的なシナリオであるファイル(XXX.CLPI,YYY.PL)について説明する。
【００３８】
ストリーム管理情報(XXX.CLPI)は、個々のAVストリームについての管理情報である。図８は、ストリーム管理情報の内部構成を示す図である。AVストリームはビデオストリーム、オーディオストリームを多重化することで得られ、AVストリームはACCESS UNITと呼ばれる単位での頭出しが可能なので、各ビデオストリーム、オーディオストリームはどのような属性をもっているか、頭出し位置がAVストリーム内の何処に存在するかが、ストリーム管理情報の管理項目になる。図中の引き出し線はストリーム管理情報の構成をクローズアップしている。引き出し線hn1に示すように、ストリーム管理情報(XXX.CLPI)は、ビデオストリーム、オーディオストリームについての「属性情報」と、ACCESS UNITを頭出しするためのリファレンステーブルである「TMAP」とからなる。
【００３９】
属性情報(Attribute)は、破線の引き出し線hn2に示すようにビデオストリームについての属性情報(Video属性情報)、属性情報数(Number)、AVストリームに多重化される複数オーディオストリームのそれぞれについての属性情報(Audio属性情報＃1〜＃m)からなる。ビデオストリームについての管理情報は、破線の引き出し線hn3に示すようにそのビデオストリームがどのような圧縮方式で圧縮されたか(Coding)、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか(Resolution)、アスペクト比はどれだけであるか(Aspect)、フレームレートはどれだけであるか(Framerate)を示す。
一方、オーディオストリームについての属性情報(Audio属性情報＃1〜＃m)は、破線の引き出し線hn4に示すようにそのオーディオストリームがどのような圧縮方式で圧縮されたか(Coding)、そのオーディオストリームのチャネル番号が何であるか(Ch.)、何という言語に対応しているか(Lang)を示す。
【００４０】
タイムマップ(TMAP)は、複数の頭出し位置のアドレスを、時刻情報を用いて間接参照するためのリファレンステーブルであり、破線の引き出し線hn5に示すように複数のエントリー情報(ACCESS UNIT＃1エントリー情報、ACCESS UNIT＃2エントリー情報、ACCESS UNIT＃3エントリー情報・・・・・)と、エントリー情報数(Number)とからなる。各エントリー情報は、引き出し線hn6に示すように、対応するACCESS UNITの再生時間(Duration)と、対応するACCESS UNITのデータサイズ(Size)とを対応づけてなる。可変長符号圧縮方式が採用されるため、GOPを含む各ACCESS UNITのサイズや再生時間がバラバラであっても、この『エントリー情報』を参照することにより、任意の再生時刻から、その再生時刻に対応するACCESS UNIT内のピクチャデータへと頭出しを行うことが可能になる。尚、ファイル名「XXX.CLPI」のファイルボディ「XXX」は、ストリーム管理情報が対応しているAVストリームと同じ名称が使用される。つまり本図におけるAVストリームのファイルボディはXXXであるから、AVストリーム(XXX.M2TS)に対応していることを意味する。以上がストリーム管理情報についての説明である。続いてプレイリスト情報について説明する。
【００４１】
YYY.PL(プレイリスト情報)は、再生経路であるプレイリストを構成するテーブルであり、CellListからなる。図９は、PL情報の内部構成を示す図である。
CellListは、複数のCELL情報(CELL情報＃1,＃2,＃3・・・＃n)と、これらCELL情報数(Number)とからなる。セル情報は、ポインタ情報であり、プレイリストを構成する1つ以上の論理的な再生区間を定義する。セル情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにセル情報は、再生区間のIn点及びOut点が属するAVストリームの名称を示す『Stream Name』と、再生区間の始点を示す情報『IN点情報』と、再生区間の終点を示す情報『Out点情報』とから構成される。
【００４２】
セル情報の特徴は、その表記法にある。つまりタイムマップをリファレンステーブルとして用いた間接参照の形式で、再生区間が定義されている。図１０は、PL情報による間接参照を模式化した図である。本図においてAVストリームは、複数のACCESS UNITから構成されている。ストリーム管理情報内のTMAPは、これら複数ACCESS UNITのセクタアドレスを、矢印ay1,2,3,4に示すように指定している。図中の矢印jy1,2,3,4は、CELL情報によるACCESS UNITの参照を模式化して示している。つまり、CELL情報による参照(矢印jy1,2,3,4)は、TMAPを介することにより、AVストリーム内に含まれる複数ACCESS UNITのアドレスを指定するという間接参照であることがわかる。
【００４３】
CELL情報−ストリーム管理情報−AVストリームの組みからなるBD-ROM上の再生区間を『セル』という。PL情報−ストリーム管理情報−AVストリームの組みからなるBD-ROM上の論理的な再生単位を『プレイリスト(PLと略す)』という。BD-ROMに記録された映画作品は、この論理的な再生単位(PL)にて構成される。論理的な再生単位にて、BD-ROMにおける映画作品は構成されるので、本編たる映画作品とは別に、あるキャラクタが登場するようなシーンのみを指定するようなPLを定義すれば、そのキャラクタが登場するシーンのみからなる映画作品を簡単に制作することができる。図１１は、図１０に示したPL情報(PL情報＃1)とは、別のPL(PL情報＃2)を定義する場合の一例を示す図である。
【００４４】
様々なPL情報を定義するだけで、映画作品のバリエーションは増えるので、映画制作者の表現の幅を増やせることが、静的なシナリオの最大のメリットである。
また、BD-ROMにおける再生単位には、PL、CELLといったものの他、Chapterがある。Chapterは、1つ、2つ以上のCELLから構成される。
【００４５】
尚、PL情報のファイル名におけるファイルボディYYYは、BD-ROMにおいてPL情報に付与される3桁の識別番号を抽象化している。つまり本図におけるPL情報は、この識別番号YYYを用いて一意に識別される。PL情報の識別番号を”YYY”と表現しているのは、PL情報の識別番号が、AVストリーム及びAVストリーム管理情報の識別番号XXXとは別の番号体系であることを意味している(ここでの3桁という桁数は例示に過ぎず、何桁でもよい。)。
【００４６】
以上が、静的なシナリオについての説明である。続いて動的なシナリオについて説明する。
＜動的なシナリオ＞
続いて動的シナリオ「ZZZ.MOVIE」,「ZZZ.HTM」,「ZZZ.CLASS」について説明する。動的なシナリオは、AVストリームの再生制御手順を示す。動的なシナリオによる再生制御手順は、装置に対するユーザ操作に応じて変化するものであり、プログラム的な性質をもつ。ここでの動的な再生制御には、2つのモードがある。2つのモードのうち1つは、AV機器特有の再生環境で、BD-ROMに記録された動画データを再生するモード(ノーマルモード)であり、もう1つはBD-ROMに記録された動画データの付加価値を高めるモード(エンハンスドモード)である。図１２は、レイヤモデルの第４層における再生モードを示す図である。本図において第４層には、1つのノーマルモードと、2つのエンハンスドモードとが記述されている。1つのノーマルモードは、DVDライクな再生環境での再生モードでありMOVIEモードと呼ばれる。2つのエンハンスドモードのうち、1つ目は、Java仮想マシンを主体とした再生モードであり、Javaモードと呼ばれる。2つ目のエンハンスドモードのうち、2つ目はブラウザを主体とした再生モードであり、Browserモードと呼ばれる。
【００４７】
尚、ファイル名ZZZ.MOVIE、ZZZ.CLASS、ZZZ.HTMにおけるファイルボディ「ZZZ」は、BD-ROMにおいて動的シナリオに付与される3桁の識別番号を抽象化している。つまり本図におけるシナリオは、この識別番号ZZZを用いて一意に識別される。シナリオの識別番号を”ZZZ”と表現しているのは、シナリオの識別番号が、AVストリームの識別番号XXX、PL情報の識別番号YYYとは別の番号体系であることを意味している(ここでの3桁という桁数は例示に過ぎず、何桁でもよい。)。
【００４８】
以降各モードの動的シナリオについてより詳しく説明する。
「ZZZ.MOVIE」は、MOVIEモードを対象とした動的シナリオである。この動的シナリオでは、既存のDVD再生装置と良く似た再生制御を再生装置に実行させることができる。
【００４９】
「ZZZ.HTM」は、Browserモードを対象とした動的シナリオである。この動的シナリオでは、ネットワーク上のサイトをアクセスしたり、ファイルをダウンロードするような制御手順を記述することができる。
【００５０】
「ZZZ.CLASS」は、Javaモードを対象とした動的シナリオであり、Java言語のアプリケーションプログラムである。Java言語のアプリケーションプログラムなのでJavaモードの動的シナリオの実行主体は、Javaプラットフォームとなる。ここでJavaモードのアプリケーションと、Javaプラットフォームとの関係を図１３を参照しながら詳しく説明する。図１３は、Java言語が対象とするJavaプラットフォームのレイアモデルを示す図である。Javaモードのアプリケーションは、このレイヤモデルの最上位のレイアに位置する。このJavaモードのアプリケーションの下位にAPI(Application Interface)がある。更にその下位のレイアにJavaプラットフォームがある。ネイティブ描画系は、再生装置が本来具備しているイメージ描画機能であり、Javaプラットフォームと同一階層にあたる。
【００５１】
Javaプラットフォームは、「Java仮想マシン(JavaVM)」、「コンフィグレーション」、「プロファイル」、「オプション」からなる。Java仮想マシンは、Java言語で記述されたJavaモードアプリケーションを、再生装置におけるCPUのネィティブコードに変換して、CPUに実行させる。コンフィグレーションは、再生装置における簡単な入出力を実現する。プロファイルは、再生装置におけるIP通信や、画面描画を行う。
【００５２】
「オプション」は、様々なライブラリを含む。これらはJavaプラットフォームからは供給され得ない様々な機能をJavaモードのアプリケーションに供給するものである。具体的にいえば、再生装置におけるセキュリティ確保の処理やBD-ROM〜Javaアプリケーション間の入出力がこのライブラリで規定されることになる。
【００５３】
再生装置においてJava仮想マシン、コンフィグレーション、プロファイル及びネイティブ描画系は、再生装置に予めインプリメントされる。また図１２に示した第１層〜第３層の制御ソフトウェアも再生装置に予めインプリメントされる。しかしオプションは、BDから読み出させねばならい。何故なら、Javaモードのアプリケーションが必要とするオプションは、様々なものがあり、これらの全てを再生装置に予めインプリメントしておくことは困難だからである。以上がJavaプラットフォームについての説明である。
【００５４】
インターリーブユニット「ILUsss.CLASS」は、インターリーブ記録されたファイルであり、プログラムやライブラリを格納している。「ILUsss.CLASS」におけるプログラムは、アプリケ−ション固有の処理を記述したバイトコード列であり、アプリケ−ションの主体となる。ライブラリとは、部品化されたプログラムであり、様々なアプリケ−ションにより利用されうるバイトコード列である。
【００５５】
以降、ライブラリについて詳しく説明する。本実施形態におけるライブラリは、AVストリーム(PL)の再生時間軸上に生存区間をもつ。生存区間とは、アプリケ−ションによるライブラリの利用が可能となるAVストリーム(PL)の再生時間軸上の一期間をいう。
【００５６】
アプリケーションによるライブラリ利用とは、アプリケ−ションからの関数呼出に従い、ライブラリに含まれる関数をJava仮想マシンに実行させることである。Java仮想マシンにライブラリを実行させるには、大きな前提条件がある。その前提条件とは、ライブラリをJava仮想マシン内のワーク領域(ヒープ領域)にロードしておくことである。そのため、ライブラリ利用にあたってアプリケ−ションプログラムは、再生装置内のキャッシュメモリからJava仮想マシンのワーク領域へのロードを命じておく必要がある。ここでBD-ROMに記録されているファイルが、BD-ROMから再生装置内のキャッシュメモリに予め読み込まれていれば、上述したロード命令は正常終了することになる。一方ライブラリが再生装置内のキャッシュメモリに読み込まれていなければ、アプリケ−ションプログラムによるロード命令は例外終了(エラー終了)することになる。ロード命令の正常終了を期待するなら、ライブラリファイルは、再生装置内のキャッシュメモリに読み出しておくことが望ましい。そうしておけば再生装置内メモリにおけるライブラリをJava仮想マシン内のワーク領域に何時でもロードすることができるからである。
【００５７】
ここでライブラリの生存区間を定めるということは、ライブラリを再生装置内のキャッシュメモリに読み出しておくことと等価であると考えることができる。しかしBD-ROM再生装置のような民生機器のハードウェアスペックでは、メモリが小規模であり、利用され得るライブラリが複数であれば、各ライブラリについての生存区間を必要最低限にしなければならない。
【００５８】
ここで生存区間をどのように決めるべきかについて説明する。図１４は、生存区間設定の対象となるAVストリームを示す図である。AVストリームの再生と同期するようなゲームアプリのプログラミングにあたっては、特定の映像が、出現している等の理由でアプリケ−ションプログラムによるライブラリ利用が多く予想される期間を生存区間に定めることが望ましい。様々なライブラリの実行を、AVストリームの再生と同期させることができるからである。例えば図１４のAVストリームは、本来映画作品を構成するものであり、人物同士の会話のシーンや、街並みを撮影したようなシーン等様々なシーンが含まれている。このうち街並みを撮影したようなシーンは、ゲームアプリケーションがコンピュ−タ・グラフィックスを描画するにあたって、背景画に利用される可能性が極めて高い。このようにゲームアプリによる利用の可能性が高いAVストリーム上の一期間をライブラリの生存区間に定め、この生存区間において、再生装置のメモリにライブラリを読み出せるようにしておく。そうするとアプリケ−ションプログラムがロードを命じた場合、確実にワーク領域にライブラリをロードすることができる。以上のことを考慮すれば、生存区間を決めるにあたっては、アプリケ−ションプログラムの背景画として使用したいシーン等、ライブラリを同期させたいシーンがAVストリームの再生時間軸上において何時出現するかを、プレオーサリングの段階で明らかにしておくことが必要となる。そして、ライブラリ同士の生存区間重複がなるべく発生しないように、各ライブラリの生存区間を定めることも、生存区間決定にあたっての責務となる。以上がライブラリの生存区間についての説明である。
【００５９】
続いてライブラリの記録形態であるインターリーブ記録について説明する。インターリーブ記録とは、BD-ROMに記録されるべき客体をAVストリームを構成する複数セグメントの合間に記録するというものである。図７でいえば、「他のファイル」にあたる箇所に客体を記録しようとするのがインターリーブ記録である。ここでインターリーブ記録される客体を”インターリーブユニット”という。インターリーブ記録される客体がライブラリである場合、インターリーブユニットたるライブラリはどのように記録されるかを以下に説明する。ライブラリがインターリーブユニットである場合、インターリーブユニットはライブラリの生存区間のIN点を含むセグメントの直前に記録される。図１５（ａ）は、BD-ROMに対しセグメントがどのように記録されるかを示す図である。AVストリームが複数のセグメントに分割されて、そのうちセグメントi+1があるライブラリ＃xの生存区間IN点を含んでいる場合、そのライブラリ＃xを含むインターリーブユニットはセグメントi+1の直前に記録される。このように生存区間IN点を含むセグメントの直前に、記録されるというのがインターリーブユニットの特徴である。
【００６０】
インターリーブユニット＃x、セグメントiは、図１５（ａ）のように記録されているため、セグメントの読み出しは図１５（ｂ）に示すように行われる。図１５（ｂ）は、セグメントi、セグメントi+1を順次読み出す場合の、光ピックアップによる読み出し経路を示す。セグメントiを読み込んだ後、本来なら光ピックアップは破線の矢印sf1に示すようなシークを行い、セグメントi+1を読み出さねばならない。セグメントi+1の前にはインターリーブユニットが存在しており、このインターリーブユニットはセグメントi+1の再生期間中に生存区間をもつライブラリを含んでいる。sf2は、先行するインターリーブユニット＃xが存在する場合の光ピックアップ読み出し位置であり、sf3は光ピックアップによるディスクスキャンを示す。このディスクスキャンsf3によりインターリーブユニット＃x、セグメントi+1は、セグメントiの読み出し後、シークを行うことなくそのまま連続的に読み取られることになる。
【００６１】
図１５（ｂ）は、1つのAVストリームを構成するセグメントを連続して読み取るものであった。続いて、ライブラリの生存区間を含むセグメント内へと頭出しが発生した場合、光ピックアップによる読み取りがどのように行われるかを図１６を参照しながら説明する。
【００６２】
図１６は、セグメントi+1内に頭出しが発生した場合の光ピックアップの移動経路を示す図である。図中の頭出し位置aP1に光ピックアップを移動させる場合にあたって、セグメントi+1に先行するインターリーブユニットの存否が判定される。(2)は、先行するインターリーブユニットが存在する場合の光ピックアップ読み出し位置であり、(3)は光ピックアップによるディスクスキャンを示す。セグメントに先行するインターリーブユニットが存在する場合、インターリーブユニット先頭からセグメントへの光ピックアップスキャンがなされてインターリーブユニット、セグメントが再生装置により読み出される。このように光ピックアップを移動させれば、光ピックアップによる一回のスキャン(3)にて、動画再生に必要なACCESS UNITと、このACCESS UNITに関連するライブラリとを一度に読み出すことができる。
【００６３】
インターリーブユニットという形態でライブラリが記録されるため、現在の再生時点が生存区間に入ったタイミングでライブラリは、メモリに読み出されることになる。そのため、生存区間内にアプリケーションプログラムがロード命令を発すれば、再生装置内のメモリからJava仮想マシン内のワーク領域へのロードが確実に成功する。図１７は、AVストリームの再生時間軸上の4つの時点t1,t2,t3,t4においてメモリへのライブラリの読み出し、及び、Java仮想マシンのワーク領域へのライブラリロードがどのように行われるかを示す図である。
【００６４】
時点t1は、ライブラリの生存区間外の時点である。生存区間外であるため、キャッシュメモリにはライブラリが読み出されていない。そのため、矢印py1に示すようにアプリケ−ションプログラムがロード命令を発したとしてもライブラリをJava仮想マシンワーク領域にロードすることはできず、ロードは矢印py2に示すように例外終了することになる。
【００６５】
時点t2はライブラリの生存区間IN点である。生存区間IN点に到達したため、矢印py3に示すようにライブラリはメモリに読み出される。
時点t3は、ライブラリの生存区間内であって、アプリケ−ションプログラムによりロードが命じられた時点である。メモリにはライブラリがロードされているので、矢印py5に示すようなアプリケ−ションプログラムによるロード命令に応じてライブラリがJava仮想マシンのワーク領域内にロードされることになる(矢印py6)。これによりアプリケ−ションプログラムは、ライブラリ内の関数を自由に呼び出すことができる。
【００６６】
時点t4は、ライブラリ生存区間である。生存区間OUT点に達したため、ライブラリは矢印py7に示すようにメモリから削除される。そのため以降アプリケ−ションプログラムからロードが命じられたとしても、時点t0同様ロード命令は例外終了することになる。
【００６７】
続いてインターリーブユニットの内部構成について説明する。図１８は、インターリーブユニットの構成を示す図である。インターリーブユニットは、本図に示すようにヘッダと、本体部とからなる。本実施形態において本体部とはライブラリのことである。
【００６８】
ヘッダは、本体部にあたるライブラリがメモリにおいて何処に存在するかを示す『ロケータ』、本体部にあたるライブラリの生存区間のIN点となる時点を示す『生存区間IN点情報』、本体部にあたるライブラリの生存区間のOUT点となる時点を示す『生存区間OUT点情報』を含む。ロケータは、再生装置上のメモリにおいて、ライブラリを識別するために設けられる。ライブラリは、生存区間に関する情報が記述されたヘッダが付与され、インターリーブユニットという形態でBD-ROMに記録されるのである。
【００６９】
『ロケータ』を設けることの技術的意義について以下に説明する。インターリーブユニットに含まれるライブラリを、キャッシュメモリ上において、Javaディレクトリの配下にあるファイル「J001.CLASS」として扱いたい場合、ロケータを「CM://Java/J001.CLASS」と記述する。このロケータにおける「CM://」とは、再生装置内部におけるインターリーブユニットの置き場所がキャッシュメモリであることを示す。一方再生装置内部におけるインターリーブユニットの置き場所がハードディスクであるなら、ロケータを「HD://」と記述すればよい。一方「Java/J001.CLASS」は、インターリーブユニットの置き場所のファイルパスである。再生装置は、インターリーブユニットの読み込みの際、キャッシュメモリ上にJavaディレクトリと、ファイルJ001.CLASSとをクリエイト又はオープンし、インターリーブユニット内のライブラリをJavaディレクトリ配下のファイルJ001.CLASSに格納しておく。こうすることでアプリケ−ションプログラムは、キャッシュメモリからJava仮想マシン内ワーク領域へのライブラリ転送を命じる際、ファイルパス「Java/J001.CLASS」を用いてキャッシュメモリ上のライブラリを指定することができる。
【００７０】
『生存区間IN点情報』をインターリーブユニットヘッダに設けておくことの技術的意義について説明する。インターリーブユニットに含まれる生存区間の開始点は、原則AVストリームの再生時間軸上において、そのライブラリがメモリ上に存在している時点となる。しかしヘッダにおける生存区間IN点情報は、このメモリ上に存在している時点とは別の時点を、記述することができる。これは以下のようなケースを想定しているためである。Java言語におけるプログラミング作法には、3つのライブラリのうち1つのみがメモリがある状態でのアプリケ−ションプログラムによるライブラリの利用を許さず、3つのライブラリがメモリ上で揃ったときのみアプリケ−ションプログラムによるライブラリの利用を許すというものがある。ところがかかる3つのライブラリが3つのインターリーブユニットとしてBD-ROM上のバラバラの位置に記録された場合、3つのライブラリがメモリに読み込まれる時点は、ライブラリ毎に異なってくる。この場合3つのうち、1つ、2つがメモリ上にある状態でのアプリケ−ションプログラムによるライブラリ利用を禁じる必要があるので、各インターリーブユニットのヘッダにおける生存区間In点情報を、メモリ上で3つのライブラリが揃う時点に設定しておく。
【００７１】
そうすると、3つのライブラリのうち、1つ目、2つ目のものがメモリにロードされた時点ではライブラリは利用可能とならず、3つ目のライブラリがメモリにロードされた段階で初めて利用可能となる。たとえ3つのライブラリがBD-ROM上でバラバラに配置されたとしても、これらを同じ時点で利用可能とするよう、ヘッダにおける生存区間In点情報で調整することができる。
【００７２】
『生存区間OUT点情報』をインターリーブユニットヘッダに設けておくことの技術的意義について説明する。上述したように、BD-ROM再生装置のハードウェアスペックではメモリ規模は限られており、キャッシュメモリ上に様々なライブラリを格納しておこうとすると、ライブラリ同士の上書きが発生してハングアップを招く恐れがある。そのためには、生存区間が過ぎたライブラリは速やかにキャッシュメモリから削除することが必要になる。かかる削除を促すべく、生存区間のヘッダに『生存区間OUT点情報』が記されている。以上がインターリーブユニットのヘッダについての説明である。
【００７３】
生存区間In点情報及び生存区間Out点情報の表記について説明する。ここでAVストリームの再生時間軸とは、AVストリームに多重化されるビデオストリーム、オーディオストリームを構成するビデオフレーム、オーディオフレームの個々の再生タイミング、ビデオフレームのデコードタイミングの基準となる時間軸である。かかる再生時間軸上の任意の位置は、AVストリーム内の先頭ビデオフレームの時間情報を基準として、これとの相対値により表現される。かかる再生時間軸で再生タイミング、デコードタイミングが規定されているので、オーディオフレーム−ビデオフレーム間の同期再生が可能になる。生存区間のIn点、Out点も、再生時間軸上の一点と考えられるから、生存区間はビデオストリームの先頭ビデオフレームの時間情報を基準とした相対値で表現される。故に上述した生存区間In点情報及び生存区間Out点情報は、ビデオストリームの先頭ビデオフレームの時間情報を基準とした相対値を用いて生存区間のIn点、Out点を指定している。
【００７４】
ACCESS UNITの頭出し時にあたって、ACCESS UNIT−インターリーブユニットを一度に読み出すには以下の改良が必要となる。それらの改良を以下に説明する。セグメントのうち、インターリーブユニットの直後にあたるACCESS UNITについては、TMAPにおけるACCESS UNITのエントリーを図１９に示すように改変せねばならない。図１９は、TMAPにおけるACCESS UNITエントリーの改良を示す図である。本図におけるACCESS UNITエントリーは、インターリーブユニットの直後にあたるACCESS UNITについて示している。本図において特徴的なのは、セグメントの先頭に位置するACCESS UNIT＃10,＃20,＃30のエントリーに、インターリーブユニットのファイル名のファイルボディ(ILU001,ILU002,ILU003)が格納されている点である。このインターリーブユニットは、このセグメントに先行するインターリーブユニットである。かかるインターリーブユニットのファイル名を、ACCESS UNITエントリーに格納しておくことで、セグメント先頭のACCESS UNITと、インターリーブユニットとをまとめて読み込むとの処理を効率的に行うことができる。
【００７５】
尚、ILUsss.CLASSの「sss」は、BD-ROMにおいてインターリーブユニットに付与される3桁の識別番号を抽象化している。つまり本図におけるインターリーブユニットは、このsssを用いて一意に識別される。インターリーブユニットの識別番号を”sss”と表現しているのは、インターリーブユニットが、AVストリーム及びAVストリーム管理情報の識別番号XXX、プレイリスト情報の識別番号YYY、動的シナリオの識別番号ZZZとは別の番号体系であることを意味している(ここでの3桁という桁数は例示に過ぎず、何桁でもよい。)。
【００７６】
続いて、各セグメントにどれだけ連続長をもたせるかについて説明する。AVストリームを分割して配置するとはいえ、AVストリームの記録にあたっては、このセグメントが読み出されるバッファ(トラックバッファという)がアンダーフローしない長さに定めねばならない。図２０の上段は、AVストリームを構成するセグメントの1つを示す図であり、BD-ROMの位置a1から位置a2までを占めている。図２０下段のグラフは、本セグメントが読み取られる際のトラックバッファの状態遷移を示す。このグラフの横軸は、時間軸であり、縦軸はトラックバッファの蓄積量を表す。このグラフにおける状態遷移は、Va-Vbという増加率での単調増加と、-Vbという減少率での単調減少とからなる。この単調増加は、時点t1からt2までの期間であり、単調減少は、時点t2からt3までの期間である。ここで時点t1は、セグメントのうち、位置a1の読み込み時点を示し、時点t2は、セグメントのうち、位置a1の読み込み時点を示す。時点t3は次のセグメントの先頭位置a3の読み込み時点を示す。Vaはトラックバッファへの入力速度であり、Vbはトラックバッファからの出力速度である。時点t2におけるトラックバッファの蓄積量B(t2)は、式1により現される。      B（t２）  =  （Va-Vb）×（t2-t1）・・・・（式1）
セグメントの読出先たるトラックバッファが、かかる状態遷移を行う場合、アンダーフローを避けるには、式2に示すようにt1からt2までの増加量B(t2)が、t2からt3までの減少量Vb(t3-t2)を上回ればよい。式2を満たすように、セグメントの連続長を決めれば、トラックバッファはアンダーフローすることはない。      B（t２）  ≧  Vb×（t3-t2）        ・・・・（式2）
以上が「ILUsss.CLASS」に格納されたライブラリの説明である。続いて「ILUsss.CLASS」に格納されるプログラムについて説明する。「ILUsss.CLASS」に格納されたプログラムが、「ZZZ.CLASS」のアプリケ−ションと異なるのは、「ZZZ.CLASS」は動的シナリオの再生制御を記述するという処理に限られ、生存区間をもっていない。これに対し「ILUsss.CLASS」におけるアプリケ−ションは、動的シナリオの再生制御に限らず、ゲーム、クライアント処理等多様な制御の記述が可能であり、生存区間を有している(無論、「ILUsss.CLASS」内のプログラムは、再生制御のためのコードをもっていてもよい)。「ILUsss.CLASS」プログラムは、他のアプリケ−ション(「ZZZ.CLASS」に格納されたアプリケ−ションを含む)から、呼び出され得る区間を生存区間としている。そのためプログラムを格納した「ILUsss.CLASS」は、その生存区間のIn点より前にインターリーブ記録される。これにより「ILUsss.CLASS」内のプログラムは、「ZZZ.CLASS」のアプリケ−ションから呼出されうる時点より前に、メモリ１４に読み出され、メモリ１４からJava仮想マシン内のワーク領域に転送されることになる。
【００７７】
インターリーブ記録には、よく似た先行技術がある。これは多重化という技術である。AVストリームへの多重化と比較すると、本実施形態に示したインターリーブ記録には、次のような利点がある。多重化では、動画ストリーム及び音声ストリームと共に、ライブラリをAVストリームに埋め込んでおくため、非AVデータたるライブラリの帯域を予め確保しておかなければならない。つまり非AVデータたるライブラリを動画ストリーム、音声ストリームと共に読み出すには、本来、動画ストリームに割り当てるべき帯域を低く抑えて、ライブラリを読み出すための帯域を確保せねばならない。映画作品の場合、結果的に映像、音声の帯域が狭くなり、映像あるいは音声の品質が落ちる結果となる。また映像、音声の帯域を狭くしないように、常に最適なライブラリ用の帯域を確保する場合は、各国の言語ごとにAVストリームも多重化し直す必要が出てくる。これは映画作品を作る際には非常に手間がかかる。
【００７８】
それに対し、ライブラリをBD-ROMにインターリーブ記録しようとする場合、ライブラリは別のファイルとして記録されるため、インターリーブユニットをセグメントの合間に挟んだとしても、ファイルとしては論理的につながったデータとして利用することができる。そのため、AVストリームの生成のための多重化工程は、ライブラリ作成とは別の行程になり、オーサリング作業の負担を減らすことができる。
【００７９】
以降、図２１〜図２４を参照しながらインターリーブユニットの設定例について説明する。この設定例では、図２１に示すようなゲームプログラムを作成することを前提にしている。図２１のゲームプログラムは、映画作品の動画を背景画とし、コンピュ−タ・グラフィックスを前景画とした合成画面から構成される。前景画たるコンピュ−タ・グラフィックスは、航空機を現したものであり、ユーザの操作に応じて姿勢や方向舵を変える。
【００８０】
一方背景画たる動画は、上空から都市を撮影した映像である。これらを合成した画像がユーザに提示されるため、ユーザはリアルなフライトシュミレーションを体感することができる。一方、ソフトウェアの制御面から考えれば、動画を背景画にしているため、JavaモードのアプリケーションはAVストリーム再生と同期して、コンピュ−タ・グラフィックス描画を行う必要がある。
【００８１】
この説明で引用するライブラリは、図２２（ａ）に示すような生存区間をもつ4つのライブラリ(＃1,＃2,＃3,＃4)であるものとする。これらは、航空機の形状データの投影像を作成するレンダリングライブラリ、航空機表面の模様を示すテクスチャパタンを投影像に貼りつけるテクスチャマッッピングライブラリ、投影像に陰影を施すシェーディング処理ライブラリ等であるものとする。図２２（ａ）は、ライブラリ＃1,＃2,＃3,＃4の生存区間を示す図である。本図の横軸は、AVストリームの再生時間軸であり、この時間軸にそって、各ライブラリの生存区間を描いている。ライブラリ＃1,＃2,＃3,＃4のうち、ライブラリ＃1の生存区間IN点が最も早く、以降ライブラリ＃2,＃3,＃4の生存区間IN点が続く。一方OUT点についても、インターリーブユニット＃1の生存区間OUT点が最も早く、以降インターリーブユニット＃2,＃3,＃4のOut点が続く。
【００８２】
動画を構成するAVストリームは、BDにおいて4つのセグメント(セグメント1/4、セグメント2/4、セグメント3/4、セグメント4/4)に分割されてBDに記録される。AVストリームの分割境界は、ライブラリの生存区間のIN点を基準にしている。図２２（ｂ）は、各ライブラリの生存区間のIN点と、セグメントとの関係を示す図である。セグメントの境界(破線)は、時間軸におけるライブラリ＃1,＃2,＃3,＃4の生存区間のIN点からやや手前に設定されている。つまりライブラリの生存区間のIN点を基準に、AVストリームは分割されているのである。
【００８３】
図２３は、BDに対し、セグメントがどのように記録されているかを示す。各インターリーブユニットは、セグメント1/4の前にインターリーブユニット＃1を配置し、セグメント1/4〜セグメント2/4の間にインターリーブユニット＃2を配置し、セグメント2/4〜セグメント3/4の間にインターリーブユニット＃3を配置するように記録されている。図２４は、インターリーブユニットの内部構成を示す図である。各インターリーブユニットは、ヘッダと、本体部たるライブラリ(ライブラリ＃1,＃2,＃3,＃4)とからなり、ヘッダはライブラリ＃1,＃2,＃3,＃4の生存区間のIN点、OUT点を示している。
【００８４】
インターリーブユニット、セグメントが図２３のように記録されることにより、各ライブラリの生存区間直前に、各ライブラリはBDからメモリ上に読み出されることになる。またインターリーブユニットのヘッダには、生存区間のOUT点が示されているので、AVストリームの再生時点が生存区間のOUT点に達すれば、メモリにおける各ライブラリは削除されることになる。かかる制御が実現可能になるので、生存区間が重なる期間において、各ライブラリを常駐させておくだけのメモリ資源を再生装置側に設けばよい。各ライブラリの生存区間から、必要最低限のメモリ規模を導きだし、これを満たすような推奨メモリ規模を定めれば良いので、動作環境をBD再生装置のハードウェアスペックに近づけることができる。以上が本発明に係る光ディスクの実施形態である。
【００８５】
続いて本発明に係る再生装置の実施形態について説明する。図２５は、本発明に係る再生装置の内部構成を示す図である。本図に示すように、再生装置は、BDドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、ピクチャプレーン５、オーディオデコーダ６、イメージプレーン８、イメージデコーダ９、加算器１０、静的シナリオメモリ１１、再生制御エンジン１２、プレーヤレジスタ１３、メモリ１４、スイッチャ１５、DVDライクモジュール１６、Javaモジュール１７、BROWSERモジュール１８、UOマネージャ１９、トラックバッファ２１から構成される。
【００８６】
BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する。
トラックバッファ２は、FIFOメモリであり、BD-ROMから読み出されたACCESS UNITが先入れ先出し式に格納される。このトラックバッファ２に対する入力速度を図中のVa、出力速度を図中のVbとした場合の、トラックバッファ２のバッファ状態は図２０のグラフに示すものとなる。
【００８７】
デマルチプレクサ３は、トラックバッファ２からACCESS UNITを取り出して多重分離を行い、GOPを構成するビデオフレームと、オーディオフレームとを得てビデオフレームをビデオデコーダ４に出力し、オーディオフレームをオーディオデコーダ６に出力する。副映像ストリームを構成する副映像ユニットはイメージデコーダ９に出力する。デマルチプレクサ３による多重分離は、TSパケットをPESパケットに変換するという変換処理を含む。
【００８８】
ビデオデコーダ４は、デマルチプレクサ３から出力されたビデオフレームを復号して非圧縮形式のピクチャをピクチャプレーン５に書き込む。
ピクチャプレーン５は、非圧縮形式のピクチャを格納しておくためのメモリである。
【００８９】
オーディオデコーダ６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。
イメージプレーン８は、一画面分の領域をもったメモリであり、コンピュ−タ・グラフィックスや字幕等、表示されるべきイメージが配置される。
【００９０】
イメージデコーダ９は、図１３に示したネイティブ描画系にあたる構成要素であり、デマルチプレクサ３から出力された副映像ストリームを伸長してイメージプレーン８に書き込む。この他、Java仮想マシンからの指示に応じてコンピュ−タ・グラフィックスの描画を行い、イメージプレーン８に書き込む。
【００９１】
加算器１０は、ピクチャプレーン５に格納された非圧縮形式のピクチャデータに、イメージプレーン８に展開されたイメージを合成して出力する。図２１に示した合成画面(動画を表示した画面の前にコンピュ−タ・グラフィックス(航空機)が合成されるような画面)は、この加算器１０が、イメージプレーン８内のイメージと、ピクチャプレーン５内のピクチャとを合成することで出力される。合成にあたって加算器１０は、混合率αの指示を受け付けて、この混合率αに応じて、ピクチャプレーン５、イメージプレーン８に格納されている画像の画素値を混合して表示する。これによりコンピュ−タ・グラフィックスの背後に、動画データの再生画像が透けて見えるような合成画像を表示することができる。混合率αは、動的シナリオが変更できるようにしてもよい。
【００９２】
静的シナリオメモリ１１は、カレントのPL情報やカレントのストリーム管理情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数PL情報のうち、現在処理対象になっているものをいう。カレントストリーム管理情報とは、BD-ROMに記録されている複数ストリーム管理情報のうち、現在処理対象になっているものをいう。
【００９３】
再生制御エンジン１２は、AV再生機能(1)、プレイリストの再生機能(2)、再生装置における状態取得／設定機能(3)といった諸機能を実行する。再生装置のAV再生機能とは、DVDプレーヤ、CDプレーヤから踏襲した機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの逆方向再生(Backward Play(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(Ungle Change)といった処理をユーザからの操作に応じて実行することである。PL再生機能とは、このAV再生機能のうち、再生開始や再生停止をPL情報に従って行うことをいう。このPL再生機能の実行により、再生制御エンジン１２はレイヤモデルの第３層(静的なシナリオに基づく再生制御)の役割を果たす。再生制御エンジン１２は、AV再生機能をユーザからの操作に従って実行する。一方、機能(2)〜(3)を、DVDライクモジュール１６〜BROWSERモジュール１８からの関数呼出に応じて実行する。つまり再生制御エンジン１２は、ユーザ操作による指示やレイヤモデルにおける上位層からの指示に応じて、自身の機能を実行する。
【００９４】
プレーヤレジスタ１３は、32個のSystem Parameter Registerと、32個のGeneral Purppose Registerとからなる。これらのレジスタの格納値は変数SPRM,GPRMとしてプログラミングに利用される。System Parameter Register、及び、General Purppose Registerは、DVDライクモジュール１６〜BROWSERモジュール１８から分離した再生制御エンジン１２で管理されるため、たとえ再生モードの切り換わりが生じたとしても、切換後の再生モードを実行するモジュールは、再生制御エンジン１２におけるSPRM(0)〜(31)、GPRM(0)〜(31)を参照しさえすれば、再生装置の再生状態を知得することができる。
【００９５】
Player Status Registerの設定値(SPRM)がどのような意味をもつかは、以下に示す通りである。以下のSPRM(x)という表記は、x番目のPlayer Status Registerの設定値を意味する。
SPRM(0)      ：  Reserved
SPRM(1)      ：  デコード対象たるオーディオストリーム
のストリーム番号
SPRM(2)      ：  デコード対象たる副映像ストリームのストリーム番号
SPRM(3)      ：  ユーザによるアングル設定を示す番号
SPRM(4)      ：  現在再生対象とされているタイトルの番号
SPRM(5)      ：  現在再生対象とされているChapterの番号
SPRM(6)      ：  現在再生対象とされているPLの番号
SPRM(7)      ：  現在再生対象とされているCELLの番号
SPRM(8)      ：  現在の再生時点を示す時刻情報
SPRM(9)      ：  ナビゲーションタイマのカウント値
SPRM(10)      ：  現在選択状態にあるボタンの番号
SPRM(11)〜(12)：  Reserved
SPRM(13)     ：  ユーザによるパレンタルレベルの設定
SPRM(14)      ：  再生装置の映像再生に関する設定
SPRM(15)      ：  再生装置の音声再生に関する設定
SPRM(16)      ：  再生装置における音声設定を示す言語コード
SPRM(17)      ：  再生装置における字幕設定を示す言語コード
SPRM(18)      ：  メニュー描画のための言語設定
SPRM(19)〜(31)：  Reserved
ここでSPRM(10)は、AVストリームに属する各ピクチャデータが表示される度に更新される。つまり再生装置が新たなピクチャデータを表示させれば、その新たなピクチャデータの表示開始時刻(Presentation Time)を示す値にSPRM(10)は更新される。このSPRM(10)を参照すれば、現在の再生時点を知得することができる。同じくSPRM(6)を参照すれば、現在再生対象とされているPLの番号を知得することができ、SPRM(7)を参照すれば、現在再生対象とされているCELLの番号を知得することができる。
メモリ１４は、BDから読み出されたインターリーブユニットを格納しておくキャッシュメモリである。メモリ１４がトラックバッファ２と異なるのは、メモリ１４はFIFO（First In First Out）のキュー型のメモリではない点である。他の構成要素は、必要なデータをこのメモリ１４から取り出すことができる。一方、他の構成要素からの要求に応じて、インターリーブユニットを削除する。
【００９６】
スイッチャ１５は、BDドライブ１の光ピックアップがBD-ROM上のセクタから情報を読み取る度に、セクタからの読み取り情報をトラックバッファ２、メモリ１４の何れかに書き込む。読み取り情報をトラックバッファ２、メモリ１４の何れに書き込むかは、ファイル管理情報を参照してなされる。つまり、ファイル管理情報には、各ファイルを構成するセグメントの所在が、ファイル名と対応づけられて示されているので、光ピックアップによる現在の読取位置のセクタアドレスを、ファイル管理情報と照合することで、セクタからの読み取り情報は、トラックバッファ２、メモリ１４の何れかに書き込まれる。現在の読取位置を示すセクタアドレスがファイルXXX.M2TSの記録領域内のものなら、BD-ROMからの読み取り情報を順次トラックバッファ２に書き込んでゆく。現在の読取位置を示すセクタアドレスがライブラリの記録領域内のものなら、BD-ROMからの読み取り情報を順次メモリ１４に書き込んでゆく。BD-ROMからの読み取り情報はセクタ単位であるが、読み取り情報のトラックバッファ２、メモリ１４への書き込みを繰り返せば1つのACCESS UNITやライブラリがトラックバッファ２、メモリ１４上に得られることになる。
【００９７】
DVDライクモジュール１６は、MOVIEモードの実行主体となるDVD仮想プレーヤであり、動的シナリオメモリ１５に読み出されたカレントのMOVIEモードの動的シナリオを実行する。
【００９８】
Javaモジュール１７は、図１３に示したJavaプラットフォームにあたる構成要素であり、メモリ１４に読み出されたライブラリを用いて、カレントのJavaモードの動的シナリオを実行する。
【００９９】
BROWSERモジュール１８は、Browserモードの実行主体となるブラウザであり、動的シナリオメモリ１５に読み出されたカレントのブラウザモードの動的シナリオを実行する。BROWSERモジュール１８が使用することができるプロトコルには、HTTP、IP、ARP、RARP、TCP,telnet,SMTP,ftpがある。
【０１００】
UOマネージャ１９は、リモコンや再生装置のフロントパネルに対してなされたユーザ操作を検出して、ユーザ操作を示す情報(以降UO(User Operation)という)を出力する。
動的シナリオメモリ２１は、カレント動的シナリオを格納しておき、カレントの動的シナリオをDVDライクモジュール１６〜BROWSERモジュール１８による処理に供するメモリである。カレント動的シナリオとは、BD-ROMに記録されている複数シナリオのうち、現在実行対象になっているものをいう。
【０１０１】
以上がBDドライブ１〜動的シナリオメモリ２１の説明である。続いて本実施形態に係る再生装置がインターリーブユニット読み出しをどのように行うかについて説明する。インターリーブユニット読み出しは、再生制御エンジン１２がPL再生を実行する際、AVストリームを構成するACCESS UNITと共にメモリ１４に読み出される。PL再生は、図２６に示したフローチャートの処理手順に従ってなされる。再生制御エンジン１２は、DVDライクモジュール１６〜BROWSERモジュール１８からのPlayPL関数の呼出時に、図２６のフローチャートに従いPL再生を行う。PlayPL関数とはPlayPL(XX,YY)という表記で呼び出される関数であり、第１引数XXに指定されるPLを、第２引数YYに示されるCELLから再生させるというものである。
【０１０２】
図２６のフローチャートにおいて処理対象たるPLをPLx、処理対象たるCELLをCELLy、処理対象たるACCESS UNITをACCESS UNITvとする。本フローチャートに先立ち、PLPlay関数の引数で指定されたPLをPLxに設定し、PLxをメモリに読み込んでから、処理対象たるCELLを特定する。関数呼出にもし引数指定がなければ、CELLyをPLxの先頭CELLに設定し、CELLzをPLxの最後のCELLに設定する。CELLzとは、読出範囲の最後を規定するCELLである。
【０１０３】
引数指定があれば、CELLyを引数指定されたCELLに設定し、CELLzを同じ引数指定されたCELLに設定する。CELLy、CELLzを、引数指定されたCELLに設定しておくのは、引数でCELLが指定されている場合は、そのCELLさえ読み出せばよいからである。
【０１０４】
ステップＳ１〜ステップＳ１９は、CELLyを構成するACCESS UNITの読み出しと、復号手順とを示す。この手順は、CELLyのIn点ビデオフレームを含むACCESS UNITvをTMAPから特定し(ステップＳ１)、ステップＳ２〜ステップＳ５の判定を経てからACCESS UNITvの読み出しをBD-ROMドライブ１に命じて(ステップＳ６)、ステップＳ７−ステップＳ８の判定を経てから、ACCESS UNITvに含まれるビデオフレームのデコードを行うようビデオデコーダ４に指示して(ステップＳ９)、ACCESS UNITvを次のACCESS UNITに設定する(ステップＳ１０)というものである。
【０１０５】
ステップＳ２は、ACCESS UNITvが属するセグメントは、未読出であるか否かを判定するものである。ACCESS UNITvが属するセグメントにおいて、ACCESS UNITvが初めて読み出されるACCESS UNITであるなら(ステップＳ２でYes)、ACCESS UNITvが属するセグメントをセグメントiに設定し(ステップＳ１１)、TMAPを参照して、セグメントiに先行するインターリーブユニットiを読み出してから(ステップＳ１２)、ACCESS UNITvの読み出しをBDドライブ１に命じる(ステップＳ６)。これにより、ACCESS UNITvは、その先行するインターリーブユニットとともにBDから読み出されることになる。
【０１０６】
ここでACCESS UNITを含むセグメントはファイル「XXX.M2TS」に格納されており、これに先行するライブラリはファイル「ILUsss.CLASS」に格納されている。セグメント及びライブラリはそれぞれ別々の2つのファイルに格納されているので、再生制御エンジン１２は、ファイル「ILUsss.CLASS」からの読み出しと「XXX.M2TS」からの読み出しとを連続して行う必要がある。
【０１０７】
ファイル「ILUsss.CLASS」からの読み出しは、ファイル「ILUsss.CLASS」をオープンし、オープンされたファイル「ILUsss.CLASS」の先頭位置を指定するようファイルポインタを設定してから、以降、ファイル「ILUsss.CLASS」の全体長を設定したREADコマンドをBDドライブ１に発行することでなされる。このコマンド発行により、ファイル「ILUsss.CLASS」は再生装置２００のメモリ１４に読み出されることになる。
【０１０８】
ファイル「XXX.M2TS」からの読み出しは、ファイル「XXX.M2TS」をオープンし、オープンされたファイル「XXX.M2TS」のうち、ACCESS UNITvの先頭位置を指定するようファイルポインタを設定してから、以降、ACCESS UNITvの全体長を設定したREADコマンドをBDドライブ１に発行することでなされる。このコマンド発行により、ACCESS UNITvは再生装置２００のトラックバッファ２に読み出されることになる。
【０１０９】
ファイル「ILUsss.CLASS」をBDドライブ１からの読み出した段階で、ファイルポインタはファイル「ILUsss.CLASS」(インターリーブユニット)の終了位置を指している。ACCESS UNITvを含むセグメントはインターリーブユニットの直後に位置しているので、光ピックアップの位置を僅かにずらすだけでACCESS UNITvの先頭位置を指定するようファイルポインタを設定することができる。
【０１１０】
ファイル「ILUsss.CLASS」からの読み出しと「XXX.M2TS」からの読み出しとにより、光ピックアップはシーク動作を行うことなく、セグメントとこれに先行するインターリーブユニットとをまとめて読み出すことができる。
【０１１１】
ステップＳ３は、メモリにあるどれかのインターリーブユニットの生存区間In点に現在の再生時点が到達したかのどうかの判定であり、もしどれかのインターリーブユニットの生存区間IN点に到達していれば(ステップＳ３でYes)、そのインターリーブユニット内のライブラリを利用可能にして(ステップＳ１３)、ステップＳ６に移行する。
【０１１２】
インターリーブユニット内のライブラリが利用可能とされる前は、アプリケーションプログラム(Javaモードの動的シナリオのことである)がメモリ１４からJava仮想マシン内のワーク領域へのライブラリロードを命じたとしても、このロードを行わず例外終了する。これは、ライブラリがメモリ１４に読み出されていない場合と同じである。インターリーブユニット内のライブラリが利用可能になれば、アプリからのロード命令に応じてJava仮想マシン内のワーク領域にライブラリを転送する。かかる転送にて、ライブラリはJava仮想マシンにて実行されることになる。
【０１１３】
ステップＳ４は、ユーザ操作があったかどうかの判定であり、もしユーザ操作があれば、それがSTOP操作であるかを判定し(ステップＳ１５)、もしSTOP操作であれば(ステップＳ１５でYes)、本フローチャートの処理を終える。それ以外なら、ユーザ操作に対応する処理を行い、ステップＳ２〜ステップＳ１０からなるループ処理に戻る。
【０１１４】
ステップＳ５は、現在の再生時点がメモリにあるどれかのインターリーブユニットの生存区間Out点に到達したかの判定であり、もし到達していれば、そのインターリーブユニットをメモリから削除して(ステップＳ１４)ステップＳ６に移行する。
【０１１５】
ステップＳ７は、ACCESS UNITvがIn点ビデオフレームを含んでいるかどうかの判定である。もしIN点ビデオフレームを含んでいる場合は(ステップＳ７でYes)、In点のビデオフレームからACCESS UNITvの最後のビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから(ステップＳ１６)、ステップＳ９に移行する。
【０１１６】
ステップＳ８は、Out点vがCELLyのOut点ビデオフレームを含んでいるかどうかの判定である。もしOut点ビデオフレームを含んでいる場合は(ステップＳ８でYes)、ACCESS UNITvの先頭ビデオフレームからOut点ビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから(ステップＳ１７)、ステップＳ１８の判定を行う。ステップＳ１８は、本フローチャートの終了判定であり、CELLyがCELLzになったかを判定している。もしステップＳ１８がYesなら本フローチャートを終了し、そうでないなら、CELLyを次のCELLに設定して(ステップＳ１９)、ステップＳ１に戻る。以降、ステップＳ１８がYesと判定されるまで、ステップＳ１〜ステップＳ１９の処理は繰り返される。以上が再生制御エンジン１２の処理手順である。
【０１１７】
図２７は、図２５に示した構成要素のうち、ライブラリに係るものを抜き出して描いた図である。本図では、「ILUsss.CLASS」としてメモリ１４に読み出されたライブラリ又はプログラムが、アプリケ−ションによる利用又は呼出に至るまでの経路を模式的に示している。ライブラリ及びプログラムは、インターリーブユニットの形態でセグメントの前に記録されている。そのためセグメントと共に矢印gy1に示すようにメモリ１４に読み出される。矢印gy2は、ライブラリがアプリケ−ションにより利用されるに至るまでの経路であり、メモリ１４からJavaモジュール１７内のワーク領域にロードされる。このロードによりアプリケ−ションは、矢印gy3に示すようにライブラリ内の関数をコールすることができる。
【０１１８】
矢印(gy4)は、「ILUsss.CLASS」内のプログラムが呼び出されるまでの経路であり、メモリ１４からJavaモジュール１７内のワーク領域にロードされる。このロードにより、「ILUsss.CLASS」内のプログラムは”アプリケ−ション”と対等な地位になり、Javaモジュール１７により実行されることになる。
【０１１９】
Java仮想マシンのワーク領域にロードされたライブラリ又はアプリケーションが、イメージデコーダ９に対する制御(gy5)を行うものなら、イメージデコーダ９により伸長処理が行われ、イメージプレーン８に伸長後のイメージが格納される。一方ビデオデコーダ４にはトラックバッファ２、デマルチプレクサ３を介してACCESS UNITが読み出されているので、ピクチャプレーン５には非圧縮型のピクチャがえられることになる。イメージデコーダ９が得たイメージと、ビデオデコーダ４が得たピクチャとを加算器１０が合成することにより、図２１のような合成画像が得られる。
【０１２０】
以上のように本実施形態によれば、セグメント再生と同期実行すべきライブラリはインターリーブユニットという形でセグメントの前に配置されており、セグメントの再生時にあたっては光ピックアップによる読み取り位置をセグメントの先頭位置からずらせば、セグメントを、同期実行すべきライブラリと共に読み出すことができる。同期処理に必要なライブラリは、セグメントの読み出し時にセグメントと併せてBD-ROMから読み出せば足り、セグメントとの同期処理が済めば、メモリから削除すればよいので、デジタルストリーム再生の全区間を通じてライブラリを常駐しておく必要はない。デジタルストリームとの同期処理を行うべきライブラリが複数あっても、個々のプログラムの実行が終わる度に、ライブラリをメモリから回収するという原則でリソース管理を行えば、セグメント再生との同期時に、プログラムを格納し得るだけのメモリを再生装置に実装しておけばよい。必要最低限のメモリ規模で、デジタルストリーム再生と、様々なライブラリとの同期処理を実現することができる。
【０１２１】
(第２実施形態)
第１実施形態は、インターリーブ記録の客体はライブラリプログラムであったが、第２実施形態のインターリーブ記録の客体は、表示用データである。表示用データには、イメージ系データ、文書系データ、描画系データがある。イメージ系データには、JPEG,GIF,PNG,MNGデータ等があり、イメージデコーダ９がダイレクトに伸長処理を行うことにより、表示可能となるデータをいう。文書系データには、HTML/SMIL,XML文書,テキスト文書があり、BROWSERモジュール１８により解釈されて、イメージデコーダ９が解釈結果に基づく表示制御を受けることにより表示可能となるデータをいう。
【０１２２】
描画系データとは、いわゆるdraw系エディタを対象としたデータであり、立体形状や図形を、座標、ベクトル、曲率等で表現しているデータである。Javaモジュール１７により解釈され、イメージデコーダ９が解釈結果に基づく制御を受けることにより表示可能となるデータをいう。
【０１２３】
インターリーブユニットたる表示用データは、セグメント再生と同期して表示される。ここでの同期表示は、セグメントの再生中にJPEG,GIF,PNG,MNGデータを表示して合成したり、HTML/SMIL文書,XML文書,テキスト文書を別ウィンドゥに表示させることを含む。HTML/SMIL文書,XML文書,テキスト文書は、ブラウザモードのアプリケーションプログラムにより利用され、JPEG,GIF,PNG,MNGデータはJavaモードのアプリケーションプログラムにより利用される。Javaモードのアプリケーションプログラムは、AVストリームの再生中において特定のシーンが出現した場合、キャッシュメモリからJava仮想マシン内ワーク領域へのロードを命じてくるだろうから、同期表示すべき期間より前に、表示用データをキャッシュメモリに読み出しておく必要がある。同様にブラウザモードのアプリケーションプログラムも、AVストリームの再生中において特定のシーンが出現した場合、アプリケーションプログラムの利用を求めてくるだろうから、同期表示すべき期間より前に、表示用データをキャッシュメモリに読み出しておく必要がある。そこで第２実施形態では、表示用データを同期させたい期間から生存区間を求めて、生存区間のIN点にあたる位置に、表示用データたるインターリーブユニットをインターリーブ記録する。こうすることでインターリーブユニットは、同期表示される期間の直前に再生装置のキャッシュメモリに読み出されることになる。
【０１２４】
図２８は、Java言語が対象とするレイアモデルにおいて、かかるデータが何処に位置するかを示す図である。本図に示すようにセグメント再生と同期表示されるべきデータは、Native描画系の上位層に配置される。
【０１２５】
BD-ROMへの表示用データの記録にあたって、表示用データはライブラリと同様BD-ROMにインターリーブ記録される。
図２９は、表示用データを格納したインターリーブユニットの構成を示す図である。本図におけるヘッダは、第１実施形態に示したロケータ、生存区間IN点情報、生存区間OUT点情報に加え、ファイルの「File Name」「Start_address」言語属性(language_type)」、AVストリームの再生時間軸におけるファイルの「表示開始時刻情報」、「表示終了時刻情報」、画面における「表示座標情報」、表示エフェクトをかけるための「エフェクト情報」、「強制出力フラグ」をもっている。
【０１２６】
「表示開始時刻情報」、「表示終了時刻情報」をヘッダにもたせているのは、インターリーブユニットに含まれる表示用データを、AVストリームを構成する動画データの再生と同期させて表示させるには、表示用データの表示タイミングが必要となるからである。また生存区間とは別に「表示開始時刻情報」、「表示終了時刻情報」を定めているのは、メモリ上にインターリーブユニットを読み出しつつも、表示させたくないケースや、メモリ上にインターリーブユニットを配置しておいて表示用データの表示／非表示を繰り返すケースがあり、これらへの対処を念頭に置いているからである。
【０１２７】
「言語属性(language_type)」をヘッダにもたせているのは、表示用データが文章、会話に関する場合、どの言語で記述されているかを明示しておく必要があるためである。
「表示座標」をヘッダにもしているのは、動画データとの合成を想定した場合、背景たる動画データの絵柄によっては、表示用データが非常に見づらくなってしまう場合があり、見易い位置に表示用データを表示させるためである。
【０１２８】
「エフェクト情報」をヘッダ内に設けておくのは、表示用データの表示開始時や表示終了時に、フェードインあるいはフェードアウトなどのエフェクトをかけたいとの要望に応えるためである。
【０１２９】
「強制出力フラグ」をヘッダ内に設けておくのは、字幕を表示しないとユーザーが選択していた場合でも強制的に表示させたいという要望に応えるためである。本実施形態において表示用データは、図２９に示したヘッダが付されてインターリーブユニットの形態で、セグメントの前に記録される。以上が本実施形態におけるインターリーブユニットの改良である。続いて本実施形態に係る再生装置の改良について説明する(イメージデコーダ９、スイッチャ１５)。
【０１３０】
スイッチャ１５は、BDドライブ１の光ピックアップがインターリーブユニットが記録されているセクタ列から情報を読み取る度に、セクタからの読み取り情報をメモリ１４に書き込む。読み取り情報のメモリ１４への書き込みを繰り返せばインターリーブユニットがメモリ１４上に得られることになる。
【０１３１】
イメージデコーダ９は、メモリ１４に格納されたインターリーブユニットのヘッダを参照し、現在の再生時点が何れかのインターリーブユニット内の表示用データの表示開始時刻に到達すれば、インターリーブユニット内の表示用データを描画してイメージプレーン８に書き込む。一方、現在の再生時点が何れかのインターリーブユニット内の表示用データの表示終了時刻に到達すれば、イメージプレーン８に書き込まれた表示用データを消去する。
【０１３２】
図３０は、インターリーブユニットとしてメモリ１４に読み出されたイメージ系データ、文書系データ、描画系データが表示に至るまでの経路を示す図である。矢印my1は、イメージ系データが表示に至るまでの経路を模式的に示す。イメージ系データは、インターリーブユニットの形態でBD-ROMからメモリ１４に読み出され(gy1)、メモリ１４からダイレクトにイメージデコーダ９に供給される(my1)。このイメージデコーダ９がデコード処理を行うことにより、表示に至る。
【０１３３】
矢印my2,my3は、文書系データが表示に至るまでの経路であり、文書系データは、メモリ１４から一旦BROWSERモジュール１８に読み出される(my2)。BROWSERモジュール１８は、文書系データの解釈を行い、その解釈結果を出力し(my3)、解釈結果に基づきイメージデコーダ９に対する表示制御(ky1)を行うことにより、文書系データは表示に至る。
【０１３４】
矢印my4,my5は、描画系データが表示に至るまでの経路である。描画系データは、メモリ１４から一旦Javaモジュール１７内のワーク領域にロードされる(my4)。Javaモジュール１７は、描画系データの解釈結果を出力し(my5)、解釈結果に基づきイメージデコーダ９に対する表示制御(ky2)を行うことにより、描画系データは表示に至る。
【０１３５】
以上のように本実施形態によれば、表示用データをインターリーブ記録するので、セグメントの読み出しと共に表示用データを再生装置内のメモリに読み出すことができ、セグメント再生と、表示用データの表示との同期を容易に実現することができる。表示用データのための情報をインターリーブユニットのヘッダに設けておくことにより、インターリーブユニットの本体部にあたる表示用データの形式を変えることなく、AVストリーム再生と同期して、各種データを表示させることができる。
【０１３６】
(第３実施形態)
第１実施形態では、プログラムの生存区間の開始点より前にインターリーブユニットを配置することでインターリーブユニットとプログラムとの同時読み込みを実現した。しかし第１実施形態では、生存区間の途中位置へと頭出しを行う場合でも、インターリーブユニット先頭から読み出しを行わねばならず、読み出しに長い時間がかかってしまう。BD-ROMにおいては、プレイリスト情報による再生経路の定義が可能であり、再生経路に従った再生にあたっては、AVストリームを先頭から再生してゆくことは稀で、AVストリームの途中から再生を開始してゆくことが頻繁に起こり得る。
【０１３７】
AVストリームやセグメントの途中からの頭出しが頻繁に発生するのなら、セグメントの前にインターリーブユニットを置くという配置では好適なインターリーブユニット読み出しを実行し得ない。そこで本実施形態は、インターリーブユニットに冗長性をもたせることを提案する。どのような冗長性かというと、あるセグメントに先行するインターリーブユニットと同じもの(複製物)を、組み込んでおくというものである。複製物を組み込む箇所は、インターリーブユニットに含まれるライブラリの生存区間の途中にあたる位置である。図３１は、セグメント内部のどこに、インターリーブユニット複製物を組み込むかを示す図である。本図においてAVストリームは、ライブラリ＃xの生存区間の途中にあたる位置でセグメントiと、セグメントi+1とに分割されている。そしてセグメントiとセグメントi+1との間にインターリーブユニットが配置されている。セグメントiとセグメントi+1との間のインターリーブユニットは、ライブラリ＃xを含んだものであり、セグメント直前に位置するインターリーブユニットの複製物である。つまりセグメントの前にあるインターリーブユニットの複製物が、ライブラリ＃xの生存区間の途中にあたる位置に存在しているのである。
【０１３８】
図３２は、セグメントiの内部に対して頭出しを行う場合、プログラムがどのように読み取られるかを示す図である。図中の(1)は、セグメントi内部に対する頭出し位置を示す。
【０１３９】
インターリーブユニットはセグメントiの前に存在するので、本来ならセグメントiの前((2)にあたる位置)から光ピックアップによる読み出しを行わねばならない。しかし本実施形態では、プログラムの生存区間の途中にあたる位置に、インターリーブユニット複製物が存在するから、図３２における頭出し位置(1)から(3)に示すように読み出しを行えば、頭出し位置(1)からインターリーブユニット複製物を読み出すことができる。ライブラリ＃xの生存区間の途中に、そのライブラリを含むインターリーブユニット＃xの複製物が記録されるので、生存区間途中に位置するACCESS UNITから頭出しをする場合、間近のインターリーブユニット複製物から、読み取りを行うことでAVストリーム読み出しを開始することができる。セグメントに先行するインターリーブユニットまで光ピックアップを移動させなくてもよいので、デジタルストリームの頭出し位置からの読み出しやライブラリを用いた処理が容易になる。
【０１４０】
続いて、図２２〜図２４に示したような4つのライブラリを、1つのAVストリームに組み込む場合の改良について説明する。図３３は、図２２に示した4つのライブラリ＃1,＃2,＃3,＃4と、セグメントとの関係を示す図である。セグメント1/5〜セグメント5/5のうち、セグメント2/5〜セグメント5/5の境界は、図２２（ａ）に示したライブラリ＃1,＃2,＃3,＃4の生存区間のIn点と一致している。しかしセグメント1/5と2/5との境界は、ライブラリ＃1の生存区間の途中にある。セグメント2/5の前にインターリーブユニット＃1の複製物が配置され、以降セグメント3/5、セグメント4/5、セグメント5/5の前にインターリーブユニット＃2、インターリーブユニット＃3、インターリーブユニット＃4が配置されている。セグメント2/5の前に、インターリーブユニット＃1の複製物が配置されているので、セグメント2/5に含まれるACCESS UNITへの頭出しが生じた場合、セグメント2/5に先行するインターリーブユニット＃1の複製物から光ピックアップによるスキャンを行えば、セグメント1/5に先行するインターリーブユニット＃1まで光ピックアップを移動させなくても、インターリーブユニット＃1をメモリに読み出することができる。
【０１４１】
以上のように本実施形態によれば、AVストリームを構成するACCESS UNITのうち、CELLのIN点等頭出しが多く発生しうる位置の後にインターリーブユニット複製物を配置しておけば、セグメント前に配置されているインターリーブユニットまでディスクシークを行わなくとも、アプリケ−ションプログラムによるライブラリ利用が可能となる。PL情報に基づく再生を行うため頭出しが多く発生したとしても、ディスクシークが最低限となり、スムーズな読み取りが可能となる。
【０１４２】
(第４実施形態)
第１実施形態ではプログラム生存区間の開始点より前に、第３実施形態ではプログラム生存区間の途中にインターリーブユニット(若しくはその複製物)を配置していた。しかし何れの実施形態においても、デジタルストリームの逆方向再生が行われる場合、再生装置はインターリーブユニット読み出しを好適に行うことはできない。何故なら逆方向再生は、AVストリームの再生時間軸を未来から過去方向に遡ってゆくからである。逆方向再生をスムーズに行わせるため、本実施形態では、インターリーブユニットに冗長性をもたせる。どのような冗長性かというと、あるセグメントに先行するインターリーブユニットと同じものを、そのセグメントの後ろに組み込んでおくというものである。
【０１４３】
図３４（ａ）は、インターリーブユニット、セグメント、インターリーブユニット複製物の配置を示す図である。図３４においてi番目に再生されるセグメントiの前には、この再生時間内に生存区間をもつインターリーブユニットiが配置されている。セグメントiは、ライブラリ＃xの生存区間In点を含み、インターリーブユニットiは、ライブラリ＃xを含む。更にこのセグメントiの後には、セグメントiの前に配置されていたインターリーブユニットの複製物が配置されている。
【０１４４】
図３４（ｂ）は、図３４（ａ）に、i+1番目のセグメントを書き加えた図である。図３４（ａ）同様、セグメントiの後ろには、インターリーブユニットiの複製物が配置され、その後ろにはインターリーブユニットi+1が配置されている。かかるインターリーブユニット複製物を置くことの技術的意義は、逆方向再生を効率的に行うためである。
【０１４５】
インターリーブユニット複製物がある場合と、無い場合とで逆方向再生がどのように行われるか対比して説明する。図３５は、インターリーブユニット複製物がある場合に逆方向再生がどのように行われるかを示す図である。逆方向再生は、各セグメントに含まれるACCESS UNITを、後ろのものから順に読み出していかねばならない。図３５の丸記号１、２、３、４が付された矢印は、セグメントにACCESS UNIT＃8が存在し、セグメントにACCESS UNIT＃4〜＃7が存在する場合のディスクシークを示す。最初の丸記号１は、セグメントi+1内のACCESS UNIT＃8に属するピクチャデータを、先頭から読み出すというディスクシーク、
丸記号２は、インターリーブユニットiを読み出すというディスクシーク、丸記号３は、ACCESS UNIT＃7を読み出すとのディスクシークである。図中のロングシーク1は、i+1番目のセグメント内のACCESS UNIT＃8を読み出してから、i番目のセグメントの直前にあるインターリーブユニットiをアクセスするまでの長いシーク動作を示す。ロングシーク2は、インターリーブユニットiを読み出してから、セグメント内のACCESS UNIT＃7を読み取るまでの長いシーク動作を示す。
【０１４６】
i+1番目のセグメントを全て読み出してから、インターリーブユニットiまでジャンプし(ロングシーク1)、インターリーブユニットiからi番目のセグメントの最後のACCESS UNITをジャンプせねばならないので(ロングシーク2)、シーク動作に無駄が多い。
【０１４７】
図３６は、インターリーブユニット複製物が配置されたBD-ROMにおけるシーク動作を示す図である。本図と図３５との違いは、i+1番目のセグメントの前に、インターリーブユニットi+1が配置され、インターリーブユニットi+1の前にインターリーブユニットiの複製物が配置されている点である。シーク（１）は、i番目のインターリーブユニットの複製物と、i+1番目のインターリーブユニットと、セグメントi+1内のACCESS UNITとを読み出すディスクシークであり、シーク２は、i番目のセグメント内のACCESS UNIT＃7を読み出すディスクシーク、シーク３は、i番目のセグメント内のACCESS UNIT＃6を読み出すディスクシークである。
【０１４８】
インターリーブユニットiの複製物が、インターリーブユニットi+1の直前に配置されているため、逆方向再生ではシーク（１）にて、i+1番目のセグメント内の先頭ACCESS UNITと共に、インターリーブユニットiが読み出される。セグメントの読み取りと共に、インターリーブユニットが読み取られるので、図３６ではロングシークが不要となり、即座にセグメントiについてのインターリーブユニットiが読み取られることになる。以上のようにインターリーブユニットの複製物を、各セグメントの後ろ側に配置することで、逆方向再生時のロングシークの発生を回避することができる。
【０１４９】
続いて、図２２〜図２４に示したような4つのライブラリを、1つのAVストリームに組み込む場合の改良について説明する。図３７は、図２２に示した4つのライブラリ＃1,＃2,＃3,＃4と、セグメントとの関係を示す図である。つまり本実施形態では、セグメント1/4の後ろ、インターリーブユニット＃2の前にインターリーブユニット＃1の複製物が記録され、セグメント2/4の後ろ、インターリーブユニット＃3の前にインターリーブユニット＃2の複製物が、セグメント3/4の後ろ、インターリーブユニット＃4の前にインターリーブユニット＃3の複製物が記録されることになる。かかる複製物の配置により、逆方向再生におけるロングシークの発生を回避することができる。
【０１５０】
以上が本実施形態に係る光ディスク側の改良である。続いて本実施形態に係る再生装置側の改良について説明する。図３６に示したディスクアクセスは、逆方向再生時に再生制御エンジン１２が図３８のフローチャートに基づく処理を行うことにより実現される。図３８のフローチャートは、図２６のフローチャートにおいてユーザにより逆方向再生操作が命じられた際、実行されるものである。
【０１５１】
ステップＳ３２〜ステップＳ４０は、CELLyを構成するACCESS UNITの読み出しと、復号手順とを示す。この手順は、ステップＳ３２〜ステップＳ３５の判定を経てからACCESS UNITvの読み出しをBD-ROMドライブ１に命じて(ステップＳ３６)、ステップＳ３７−ステップＳ３８の判定を経てから、ACCESS UNITvに含まれるビデオフレームのデコードを行うようビデオデコーダ４に指示して(ステップＳ３９)、ACCESS UNITvを次のACCESS UNITに設定する(ステップＳ４０)というものである。
【０１５２】
ステップＳ３２は、ACCESS UNITvが属するセグメントは、未読出であるか否かを判定するものである。もし未読出であるなら、ACCESS UNITvが属するセグメントは2番目以降であるかを判定し(ステップＳ４２)、2番目以降であるなら(ステップＳ４２でYes)、ACCESS UNITが属するセグメントをセグメントi+1に設定して(ステップＳ４３)、TMAPを参照してセグメントi+1に先行するインターリーブユニットi+1と、インターリーブユニットiとを読み出す(ステップＳ４４)。1番目なら(ステップＳ４２でNo)、ACCESS UNITが属するセグメントをセグメントiに設定して(ステップＳ１１)、TMAPを参照してセグメントiに先行するインターリーブユニットiを読み出す(ステップＳ１２)。ここで、ACCESS UNITvと、これに先行する2つのインターリーブユニットとはそれぞれ別々の3つのファイルに格納されているので、Javaモードのアプリケーションには、2つのインターリーブユニットにあたる2つのファイルを読み出すコマンド、XXX.M2TSを読み出す読出コマンドを連続発行する必要がある。インターリーブユニット複製物の先頭アドレスに光ピックアップを移動させさえすれば、光ピックアップの一回の読み取り操作で、セグメントとこれに先行する2つのインターリーブユニットとをまとめて読み出すことができる。
【０１５３】
ステップＳ３３は、図２６のステップＳ３と同じ処理であり、メモリにあるどれかのインターリーブユニットの生存区間In点に現在の再生時点が到達したかのどうかの判定であり、もしどれかのインターリーブユニットの生存区間IN点に到達していれば、そのインターリーブユニット内のライブラリを利用可能にする。
【０１５４】
ステップＳ３５は、図２６のステップＳ５と同じ処理であり、現在の再生時点がメモリにあるどれかのインターリーブユニットの生存区間Out点に到達したかを判定し、もし到達していれば、そのインターリーブユニットをメモリから削除する。
【０１５５】
ステップＳ３７は、ACCESS UNITvがOut点ビデオフレームを含んでいるかどうかの判定である。もしOut点ビデオフレームを含んでいる場合は(ステップＳ３７でYes)、ACCESS UNITvの先頭ビデオフレームからOut点ビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから(ステップＳ４５)、ステップＳ３９に移行する。
【０１５６】
ステップＳ３８は、ACCESS UNITvがCELLyのIn点ビデオフレームを含んでいるかどうかの判定である。もしIn点ビデオフレームを含んでいる場合は(ステップＳ３８でYes)、In点のビデオフレームからACCESS UNITvの最後のビデオフレームまでのデコードを行うようビデオデコーダ４に指示してから(ステップＳ４６)、ステップＳ４７の判定を行う。ステップＳ４７は、本フローチャートの終了判定であり、CELLyがPLを構成する最初のCELLになったかを判定している。もしステップＳ４７がYesなら本フローチャートを終了し、そうでないなら、PLを構成する1つ前のCELLにCELLyを設定し(ステップＳ４８)、CELLのIN点ビデオフレームを含むACCESS UNITをTMAPから特定してから(ステップＳ４９)ステップＳ３２に戻る。以降、ステップＳ４７がYesと判定されるまで、ステップＳ３２〜ステップＳ４９の処理は繰り返される。以上が本実施形態に係る再生制御エンジン１２の処理手順である。
【０１５７】
以上のように本実施形態によれば、デジタルストリームの再生時間軸を未来から過去に遡って行き、ライブラリの生存区間に到達した場合でも、不要なシークを行うことなくBD-ROMからメモリへのライブラリ読み出しを実現することができる。逆方向再生のような変則的な再生進行が行われる場合でも、メモリへのライブラリ読み出しを実現出来るので、AV再生との同期を前提とした様々な処理を、逆方向再生時でも実現可能となる。
【０１５８】
(第５実施形態)
第５実施形態は、PLの再生を行い、この再生に同期して様々な再生制御を行うJavaモードのアプリケーションについて説明する。
【０１５９】
図３９は、本実施形態に係るBD-ROMのファイル構成を示す図である。本図において新規なのは、YYY.Mark(PLMark),XXX.Mark(ClipMark)が追加されている点である。
PLMarkは、PLの再生中において、再生装置が拡張制御を行うべき区間を示す情報である。ファイル名「YYY.Mark」のファイルボディYYYは、PLMarkが対応しているPLと同じ名称が使用される。つまり本図におけるPLMarkのファイル名のファイルボディはYYYであるから、PL(YYY.PL)に対応していることを意味する。
【０１６０】
ClipMarkは、AVストリームの再生中において、再生装置が拡張制御を行うべき区間を示す情報である。XXX.Markのファイル名におけるファイルボディ「XXX」は、ClipMarkが対応しているAVストリームと同じ名称が使用される。つまり本図におけるClipMarkのファイル名におけるファイルボディは「XXX」であるから、AVストリーム(XXX.M2TS)に対応していることを意味する。
【０１６１】
ClipMarkとPLMarkとの違いは以下の通りである。ClipMarkは、拡張制御を行うべき区間をAVストリームに対して指定しているのに対し、PLMarkはPLに対して指定している。
例えば、図１１に示したように1つのAVストリームに対し、2つのPL情報が定義されている場合に、ClipMarkにて拡張制御を行うべき区間を指定すれば、この指定は、このAVストリームを指定している2つのPL情報の何れに対しても及ぶ。一方、PLMarkにて拡張制御を行うべき区間を指定すれば、PLMarkに対応するPLにのみ、拡張制御指定の効力は及ぶ。PLMarkに対応するPLがPL＃1ならPL＃1のみに及び、PL＃2には及ばない。つまり、拡張制御を行うべき区間をClipMarkにて指定すれば、AVストリームを含むPLの全てに対しClipMarkの効力が及び、拡張制御を行うべき区間をPLMarkにて指定すれば、そのPLMarkに対応するPLに対してのみClipMarkの効力が及ぶのである。これがClipMarkとPLMarkとの違いである。
【０１６２】
本実施形態における拡張制御とは、再生装置にイベントを発生させるというものである。イベントを発生させるため、PLMark及びClipMarkは、図４０に示す共通のデータ構造をもつ。図４０は、PLMark及びClipMarkの共通構成を示す図である。本図に示すようにPLMarkは、イベント数（Number）、個々のイベント（Event＃1〜Event＃m）とから構成され、再生中に発生すべきイベントを定義する。個々のイベント（Event＃）は、イベントの種類（Type）と、イベントのID（ID）と、イベントが発生する時刻（Time）と、このイベントが有効となる時間帯の時間長（Duration）を示す。
【０１６３】
かかるデータ構造にて定義されるイベントには、TimeEvent、UserEventというものがある。TimeEventとは、プレイリストの再生時間軸において、現在の再生位置が予め定められた時点Tに到達した場合に発生するイベントである。UserEventとは、現在の再生位置が予め定められた時間帯に到達し、この時間帯でユーザにより操作がなされた場合に発生するイベントである。
【０１６４】
プレイリスト＃1の再生中に出現するTimeEventを定義する場合、PLMarkをどのように記述するかについて図４１（ａ）を参照しながら説明する。図中の下段の時間軸は、PL＃1が再生される時間軸を示す。この時間軸において時刻t1から発生するTimeEventEx1を定義するケースを想定する。このTimeEventを定義する場合のPLMarkの記述例が、図中のPLMarkmt1である。本PLMarkは、Typeの項目が”TimeEvent”と記述され、IDの項目に”Ex1”、Timeの項目が”t1”、Durationの項目が”0”と記述されている。図中の矢印は、時刻t1の到来で生じるTimeEventを示す。このTimeEventの発生により、図中のイベントハンドラが駆動されることになる。
【０１６５】
一方、再生時間軸上の時刻t1から、間隔TでTimeEventを発生させる場合のPLMarkの記述例を図４１（ｂ）に示す。図４１（ｂ）が（ａ）と違うのは、PLMarkのDuration項目が”T”と記述されている点である。項目Durationの記述により、時点t1の経過後、間隔T置きにTimeEventを発生させることができる。
【０１６６】
プレイリスト＃1の再生中においてUserEventを定義する場合、PLMarkをどのように記述するかについて図４２を参照しながら説明する。図４２の中段の時間軸は、PL＃1が再生される再生時間軸を示す。この時間軸上において現在の再生時点がどこであるかは、SPRM(10)に示されている。この時間軸において時刻t1から期間T1の間、有効となるUserEventEv1を定義するケースを想定する。このUserEventを定義したPLMarkが、図中のPLMarkmt2である。本PLMarkは、Typeの項目が”UserEvent”と記述され、IDの項目に”Ev1”、Timeの項目が”t1”、Durationの項目が”T1”と記述されている。本図におけるリモコンrm1は、ユーザ操作を受け付ける機器であり、図中の矢印uv1は、リモコンのENTERキーの押下で生じるUOを示す。UOが、時刻t1から期間T1の時間帯に発生すれば、UOに基づきUserEventEv1が発生する。このUserEventにより、図中のイベントハンドラが駆動される。以上がPLMarkにより定義されるイベントである。尚ClipMarkにより定義されるイベントについての説明は省略する。何故なら、PLMarkがPL再生中に発生すべきイベントを定義しているのに対し、ClipMarkはAVストリーム再生中に発生すべきイベントを定義しているにすぎず、PLMarkにおけるイベント定義とあまり変わらないからである。
【０１６７】
図４３は、ClipMark、PLにてかかるTimeEvent、UserEventが定義されている場合のインターリーブユニットの配置例を示す図である。本図においてAVストリームは、TimeEventを発生すべき時点t1の直前で分割され、この位置にイベントハンドラEx1を格納したインターリーブユニットが記録されている。
【０１６８】
このように記録しておくことで、時点t1を含むセグメントと共に、イベントハンドラを含むインターリーブユニットがメモリに読み出されることになる。イベントハンドラがメモリに読み出されれば、アプリケ−ションプログラムからのロード命令に応じてJava仮想マシン内のワーク領域に、イベントハンドラをロードすることができるので、再生時点が時点t1に達すれば、このイベントハンドラを即座に駆動することができる。
【０１６９】
以上が本実施形態に係るBD-ROMの改良である。続いて、本実施形態における再生装置の改良点について説明する。上述したようなTimeEvent、UserEventを発生させるには、再生制御エンジン１２に図４４に示すような処理手順を行わせればよい。
【０１７０】
図４４は、本実施形態に係る再生制御エンジン１２の処理手順を示す図である。本フローチャートは、図２２のフローチャートの改良であり、同じ処理手順のものは同一の参照符号を付すか或は、図示を省略している。本フローチャートにおいて新規なのは、CELLを構成するACCESS UNITを読み出し、復号するという一連の処理(図２６のステップＳ２〜ステップＳ１０のうち、ステップＳ５とＳ６との間)に、ステップＳ２０、ステップＳ２２という2つの判定ステップが挿入されている点である。ステップＳ２０は、PL再生において、現在の再生時点を発生時刻としたTimeEventが、PLMark、ClipMarkに定義されているかどうかを判定するステップである。ステップＳ２０がYesなら、TimeEventを発生して(ステップＳ２１)、ステップＳ６に移行する。TimeEventを駆動要件とするイベントハンドラは、インターリーブユニットの形態でBD-ROMに記録されており、セグメントと共に再生装置のメモリに読み出されるので、TimeEventを駆動要件とするイベントハンドラが即座に駆動される。
【０１７１】
ステップＳ２２は、UOが発生したかどうかを判定しているステップである。ステップＳ２２がYesなら、PLMark、ClipMarkを参照し、そのUOを有効としている時間帯であるかを判定する(ステップＳ２３)。もしその時間帯であれば、UserEventの発生して(ステップＳ２４)、ステップＳ６に戻る。UserEventを駆動要件とするイベントハンドラは、インターリーブユニットの形態でBD-ROMに記録されており、セグメントと共に再生装置のメモリに読み出されるので、UserEventを駆動要件とするイベントハンドラが即座に駆動される。
【０１７２】
以上のように本実施形態によれば、AVストリームの再生時間上において、イベントハンドラの駆動が予定されている位置に、イベントハンドラをインターリーブユニットの形態でセグメント間に組み込んでおくので、アプリケーションプログラムによりロードが命じられた場合、メモリからJava仮想マシン内のワーク領域へのロードを好適に行うことができる。
【０１７３】
尚、TimeEvent、ILVUの他、PLの再生に先立ち発生するイベント(Preイベント)、PLの再生後発生するイベント(Posetイベント)を再生制御エンジン１２に発生させ、これにより駆動されるイベントハンドラをインターリーブユニットに格納してもよい。この場合、プレイリスト情報における先頭のCELL情報にて指定されている時点及びプレイリスト情報における最後のCELL情報にて指定されている時点のインターリーブユニットに格納しておくことが望ましい。
【０１７４】
本実施形態では、Mark情報にて定義されるイベントについてのイベントハンドラを説明したが、インターリーブ記録されるイベントハンドラは、他のプログラムにより発生されるイベントにて駆動されてもよい。機器により発生されるイベントにて駆動されてもよい。機器により発生されるイベントとは、BD-ROMのオープン／クローズがなされたことを示すイベント、電源異常等、機器の状態を示すイベント等がある。
【０１７５】
(第６実施形態)
第１実施形態、第２実施形態においてライブラリ及び表示用データの生存区間に関する情報は、インターリーブユニットのヘッダに直接記述されていた。これに対し第６実施形態ではライブラリ及び表示用データの生存区間に関する情報を、間接参照の形式で記述するものである。
【０１７６】
図４５は、インターリーブユニットに関する情報の間接参照がどのように行われるかを示す図である。
本図の第１段たるAVストリームは、2つのセグメントに分割されてBD-ROMに記録されており、このセグメントの合間にインターリーブユニットが記録されている。このインターリーブユニットはライブラリ、表示用データを含んでいる。ここまでは第１実施形態と変わりない。しかしヘッダのロケータ、生存区間In点情報、生存区間Out点情報がIDに置き換えられている。一方、第２段目、第３段目における静的なシナリオには、インターリーブユニット統合情報がある。このインターリーブユニット統合情報には、AVストリームに組み込まれた複数インターリーブユニットのそれぞれについて、生存区間の情報が記述される。このインターリーブユニット統合情報は、各インターリーブユニットの生存区間In点情報、生存区間Out点情報、インターリーブユニットのサイズを対応づけて示している。ヘッダに直接生存区間In点情報、生存区間Out点情報を記述せず、ヘッダにIDを記述しておき、このIDを介してインターリーブユニット統合情報から生存区間In点情報、生存区間Out点情報を取得できるようにしている。これが生存区間In点情報、生存区間Out点情報の間接参照である。
【０１７７】
図４６は、AVストリームに組み込まれた3つのインターリーブユニットと、インターリーブユニット統合情報との対応を示す図である。AVストリーム内にID=1,2,3・・・・をもったインターリーブユニットが組み込まれている場合、ID=1,2,3・・・・がインターリーブユニット統合情報に記述され、これらのID毎に、インターリーブユニットの生存区間In点情報、生存区間Out点情報、サイズが記述される。各インターリーブユニットに付されたIDは、インターリーブユニット自身がどのAVストリームに属しているか(1)、そのAVストリームにおいて何個目のインターリーブユニットであるか(2)を一意に識別する。
【０１７８】
かかるインターリーブユニット統合情報が静的なシナリオ内に存在することにより、再生制御エンジン１２はAVストリームに組み込まれた複数インターリーブユニットの集中管理を行うことができる。集中管理の具体的な内容としては、生存区間が重なり合う複数インターリーブユニットが存在する場合、メモリ１４へのインターリーブユニット読み出しを制限するというインターリーブユニットの読み出し本数制限がある。
【０１７９】
インターリーブユニット統合情報は、各インターリーブユニットのIDと対応づけて各インターリーブユニットのサイズを示しているので、各インターリーブユニットのサイズを積算してゆけば、生存区間が重なり合う複数インターリーブユニットを同時にメモリ１４に格納しようとした場合、メモリ１４上に存在するインターリーブユニットの総サイズがどれだけになるかを、計算しておくことができる。もし計算された総サイズが、メモリ１４のメモリサイズより大きくなれば、生存区間が重なり合う複数インターリーブユニットの全てをメモリ１４に読み出すのではなく、一部のインターリーブユニットのみをメモリ１４に読み出す。かかる読み出し本数の制限により、インターリーブユニット同士の上書きが回避され、メモリ１４上でのインターリーブユニット破壊を回避することができる。
【０１８０】
以上のように本実施形態によれば、キャッシュメモリ上に読み出し可能なインターリーブユニット本数を、インターリーブユニットの読み出しに先立ち事前に見積もることができるので、インターリーブユニットの生存区間が重なってる場合のキャッシュメモリの容量不足を回避することができる。
【０１８１】
自機のメモリ規模に応じてどれだけインターリーブユニットを読み出すことができるかを調整することができるので、BD-ROMプレーヤモデルの策定にあたっては、「どれだけの規模のキャッシュメモリを具備せねばならない」というメモリ規模の指針を数値化しなくてもよくなる。メモリ規模の数値化が不要になるため、再生装置のメモリ規模がどれだけにすればよいかという、メモリ規模設計の自由度が高まり、BD-ROM再生装置の普及に貢献することができる。
【０１８２】
尚インターリーブユニット統合情報は、静的なシナリオにおいて1つ設けておいたが、ストリーム管理情報の1つの情報要素として組み込んでおいてもよい。この場合、個々のインターリーブユニットがどのAVストリームに組み込まれているかという識別(1)が不要であり、個々のインターリーブユニットがAVストリームにおける何番目のインターリーブユニットであるかを識別できればよいので、IDのビット長を短くすることができる。またPL情報の1つの情報要素として組み込んでもよい。
【０１８３】
(第７実施形態)
第１実施形態及び第２実施形態では、再生時間軸上の生存区間のIn点及びOut点を生存区間In点情報、生存区間Out点情報で記述するという表記により、生存区間を表現していた。これに対し第７実施形態では、間接的な表記を提案する。どのような表記かというと、CELL情報の番号、PL(プレイリスト)情報の番号、Mark情報の番号、タイトルの番号、チャプターの番号、SkipPointの番号を用いて生存区間を表記するのである。図４７は、第７実施形態に係るインターリーブユニットにて、生存区間がどのように表記されるかを示す図である。
【０１８４】
ここで『CELL情報』は、第１実施形態に示したようにAVストリーム上の1つの再生区間を指定するものである。インターリーブユニットのヘッダに、生存区間情報としてCELL情報の番号を記述しておくことにより”再生区間”をインターリーブユニットの”生存区間”として定義することができる。図中のインターリーブユニットヘッダにおけるCELL情報の番号が、Cell情報＃1を示しているなら、図中のck1に示すようにCELL情報＃1にて指定される再生区間(図中のay1〜ay2で示される区間)が生存区間になる。
【０１８５】
『PL情報』は、第１実施形態に示したように1つ以上の再生区間から構成される再生経路を指定するものである。インターリーブユニットのヘッダに生存区間情報としてPL情報の番号を記述すれば、PL情報にて指定された再生経路を、インターリーブユニットの生存区間として定義することができる。
【０１８６】
『Mark情報(ClipMark,PLMark)』とは、第５実施形態に示したように拡張制御を行うべき区間を指定するものである。インターリーブユニットのヘッダに、生存区間情報としてMark情報の番号を記述しておくことで、そのMark情報にて指定される区間をインターリーブユニットの生存区間として定義することができる。
【０１８７】
『タイトル』とは、1つ以上の再生経路と、動的シナリオとから構成される1つの映画作品のことである。このタイトルの番号を生存区間情報としてインターリーブユニットのヘッダに記述しておくことにより、映画作品といった広汎な範囲の生存区間を定義することができる。
【０１８８】
『チャプター』とは、映画作品の「章」としてユーザに認識される単位であり、1つ以上のCELL情報にて規定される。このチャプターの番号を生存区間としてインターリーブユニットのヘッダに記述しておくことにより、映画作品の「章」という、わかり易い単位で生存区間を定義することができる。
【０１８９】
『SkipPoint』とは、章のうち、ユーザがマーキングを行った位置をいう。かかる位置は、Mark情報で定義される。このSkipPointの番号を生存区間In点情報、生存区間Out点情報としてインターリーブユニットのヘッダに記述しておくことにより、SkipPointというユーザにとってわかり易い単位で生存区間を定義することができる。
【０１９０】
以上が本実施形態に係る生存区間の表記である。続いてかかる生存区間を有している場合の、ライブラリ及び表示用データのインターリーブ記録について説明する。CELL情報、PL情報、Mark情報、タイトル、チャプター、SkipPointの番号で生存区間が表現されているとはいえ、生存区間がAVストリーム上に存在していることは、第１実施形態と同様である。そのためライブラリ及び表示用データは、AVストリームのうち、CELL情報、PL情報〜SkipPointにより指定されている位置の直前に記録すれば良い。かかる位置の前後でAVストリームを複数セグメントに分割しておき、かかるセグメント間にライブラリ及び表示用データを含むインターリーブユニットを記録しておけばよいのである。そうすればCELL情報、PL情報〜SkipPointを用いた再生の開始にあたって、インターリーブユニットは、かかるAVストリームを構成するセグメントと共にメモリ１４に読み出されることになる。
【０１９１】
ここでCELL情報により指定される位置とは、CELL情報のIn点情報により指定されるAVストリーム上の位置であり、PL情報により指定される位置とは、PL情報における最初のCELL情報のIn点情報により指定されるAVストリーム上の位置である。
【０１９２】
タイトルにより指定される位置とは、そのタイトルを構成する1つ以上のPL情報のうち、最初のPL情報の最初のCELL情報のIn点情報により指定されるAVストリーム上の位置であり、Mark情報により指定される位置とは、AVストリーム上においてそのMark情報の時刻情報で指定される位置、チャプター番号、SkipPoint番号で指定される位置とは、AVストリーム上においてそのチャプター、SkipPointにより指定されるAVストリーム上の位置をいう。
【０１９３】
以上が本実施形態に係るBD-ROMの改良である。生存区間が、PL情報、CELL情報、タイトルの番号で表現されているので、第７実施形態に係る再生装置の再生制御エンジン１２は、以下のような処理を行う。
【０１９４】
PL情報、CELL情報、Mark情報、タイトル、SkipPointの番号により再生が命じられた場合、本実施形態に係る再生制御エンジン１２は、これらで指定されている位置にあたるACCESS UNITを特定し、TMAPにおけるそのACCESS UNITに対応するACCESS UNITエントリーを参照する。そのACCESS UNITエントリーにインターリーブユニットのファイル名が記述されていれば、そのファイル名のACCESS UNITと、ACCESS UNITとを連続してBD-ROMから読み出す。
【０１９５】
かかる連続読み出しは、以下の6つのタイミングにおいて、なされることになる。
1つ目のタイミングとは、タイトルが一覧表示され、このメニューに対してユーザが選択操作を行ったタイミングである。タイトル選択がなされれば、再生制御エンジン１２は、このタイトルにて指定される位置のACCESS UNITに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをACCESS UNITと共にBD-ROMからメモリ１４に読み出す。メモリ１４におけるインターリーブユニットの格納は、そのタイトルの再生が終了するまで継続してなされる。タイトル再生が終了すれば、再生制御エンジン１２はメモリ１４からインターリーブユニットを削除する。
【０１９６】
2つ目のタイミングとは、あるPL情報がカレントPL情報として静的シナリオメモリ１１に読み出されるタイミングである。再生制御エンジン１２はそのカレントPL情報にて指定される位置のACCESS UNITにインターリーブユニットが先行しているかのサーチを行い、もし先行していればACCESS UNITと共に、そのインターリーブユニットをBD-ROMからメモリ１４に読み出す。メモリ１４におけるインターリーブユニットの格納は、カレントPL情報による再生が終了するまで継続してなされる。再生制御エンジン１２は現在の再生時点がカレントPL情報を構成する最後のCELL情報のOut点に到達するのを待ち、到達すれば、インターリーブユニットをメモリ１４から削除する。Javaモードのアプリケーションプログラムは、上述したPL情報の再生が行われている間、ロード命令を発行することにより、ライブラリをメモリ１４からJava仮想マシン内のワーク領域に供給することができる。
【０１９７】
3つ目のタイミングとは、カレントPL情報内のCELL情報が再生の対象(図２６のフローチャートにおけるCELLy)として指定されるタイミングである。そのタイミングにおいて再生制御エンジン１２は、そのCELLにて指定される位置のACCESS UNITに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。再生制御エンジン１２は現在の再生時点がCELL情報のOut点に到達するのを待ち、到達すれば、インターリーブユニットをメモリ１４から削除する。かかる処理により、Javaモードのアプリケーションプログラムは、上述したCELL情報の再生が行われている間、ロード命令を発行することにより、ライブラリをメモリ１４からJava仮想マシン内のワーク領域に供給することができる。
【０１９８】
4つ目のタイミングとは、現在の再生時点がMark情報に示される時点に達したタイミングである。再生制御エンジン１２は、そのMark情報により指定された位置にあたるACCESS UNITに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。
【０１９９】
5つ目のタイミングとは、ユーザがチャプターメニューからチャプターを選ぶ操作を行ったタイミングである。チャプター選択操作を行えば、再生制御エンジン１２はそのチャプターにより指定された位置にあたるACCESS UNITに、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。尚、現在の再生時点がチャプターの先頭に到達した場合もそのチャプターにあたる位置に、インターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。
【０２００】
6つ目のタイミングとは、ユーザがSkipPointを選ぶ操作を行ったタイミングである。SkipPointを選ぶ操作をを行えば、再生制御エンジン１２はそのSkipPointにより指定された位置にあたるACCESS UNITにインターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。尚、現在の再生時点がSkipPointに到達した場合もそのSkipPointにあたるACCESS UNITにインターリーブユニットが先行しているかのサーチを行い、もし先行していればそのインターリーブユニットをBD-ROMからメモリ１４に読み出す。
【０２０１】
以上のように本実施形態によれば、CELL情報、PL情報の番号を用いて生存区間を定義しているので、インターリーブユニット同士の生存区間の重なりの把握が容易となり、リソース管理を念頭においたインターリーブユニットの読み取り計画が立て易くなる。
【０２０２】
尚、再生制御エンジン１２によるサーチを容易とするため、各インターリーブユニットの生存区間情報は、第１実施形態におけるインターリーブユニット統合情報において統合管理しておくことが望ましい。こうすることにより、インターリーブユニット統合情報を参照するだけで全てのインターリーブユニットに対するサーチが可能になる。
【０２０３】
また本実施形態では、PL情報、CELL情報、タイトル、チャプター、SkipPointと、インターリーブユニットとを番号で対応づけたが、PL情報、CELL情報、タイトル、チャプター、SkipPointを一意に識別できるものなら、どのような識別情報であってもよい。また第６実施形態に示したようなインターリーブユニットの識別情報を、PL情報、CELL情報に付与することで識別してもよい。
【０２０４】
(第８実施形態)
第１実施形態、第２実施形態では、ロケータにファイルパスを記述することによりメモリ１４における個々のライブラリ及びプログラムを識別していたが、第８実施形態はロケータにおけるファイルパスの記述により、メモリ１４上のライブラリ、表示用データの配置を階層化しようという改良に関する。図４８は、ロケータの記述によるプログラム又は表示用データの階層化配置を模式的に示す図である。本図の第１段目は、AVストリームと、AVストリームの合間にインターリーブ記録されたインターリーブユニットとを示す。第２段目は、各インターリーブユニットの内部構成と、ヘッダにおけるロケータの記述とを示す。第３段目は、メモリ１４上のプログラム及び表示用データの配置を示す。第２段目において各インターリーブユニットのロケータは、「CM://Java/Image」,「CM://Java/Game」,「CM://Java/Character」と記述されているため、再生制御エンジン１２は各インターリーブユニットのヘッダを参照した際、メモリ１４上のJavaディレクトリを生成し、このディレクトリに「Image」,「Game」,「Character」というファイルを生成してこれらファイルに、インターリーブユニット内のプログラム又は表示用データを配置してゆく。図中の矢印ty1,ty2,ty3は、この配置を模式的に示す。ここで第２段目の生存区間情報を見ると、インターリーブユニットの生存区間は、インターリーブユニット1の生存区間は1〜6、インターリーブユニット2の生存区間は3〜5,インターリーブユニット3の生存区間は0〜10なので、各インターリーブユニットの生存区間は互いに重複し合っている。互いに重なり合うライブラリ及び表示用データを、「Image」,「Game」,「Character」というファイルに格納して1つのjavaディレクトリの配下に配置するので、Javaディレクトリをアクセスすることにより、Javaモードのアプリケ−ションプログラムはインターリーブユニット内のライブラリ及び表示用データをJava仮想マシン内のワーク領域にロードすることができる。
(第９実施形態)
これまでの実施形態では、ライブラリや表示用データのインターリーブ記録を行っていた。これに対し第９実施形態では、ライブラリや表示用データを、データカルーセルと同様の形式でAVストリーム内に組み込むという改良に関する。データカルーセルとは、対話的な放送の実現のために同一内容を繰り返しするという放送方式である。BD-ROMは、放送されたデータを格納するものではないが、このデータカルーセルの格納形式に倣ってライブラリ及び表示用データを格納するようにしている。
【０２０５】
ここでデータカルーセルでの送信について説明する。データカルーセルの客体は複数に分割される。分割により得られた個々の分割部分は、DDB(Dawnload Datablock)というブロックになり、DII(DownloadinfoIndicatin)と呼ばれる固有の制御情報と共にAVストリーム内に組み込まれる。このDIIは、DDBに先立つ位置に配置され、DDBのデータ長が記述される。
【０２０６】
このデータカルーセル方式の客体が、ライブラリ及び表示用データであると考えれば、ライブラリ及びデータはヘッダが付加された上で、複数のDDBに分割される。そしてこれらのDDBは、AVストリームのうち、生存区間In点にあたる位置の前に配置される。こうすることで、生存区間In点にあたるACCESS UNITが再生装置により読み出されたタイミングで、ライブラリ及び表示用データにあたるDDBは、再生装置に読み出されるのである。
【０２０７】
以上が、第９実施形態に係るAVストリーム側の改良である。続いて本実施形態に係る再生装置側の改良について説明する。図４９は第９実施形態に係る再生装置の内部構成を示す図である。
【０２０８】
AVストリーム内にデータカルーセル形式のライブラリ及びデータが存在するため、インターリーブユニットとAVストリームとを分離するスイッチャ１５は再生装置から省かれている。メモリ１４には、デマルチプレクサ３からライブラリ及びデータが供給されるようになっている。本図の再生装置においてデマルチプレクサ３は、AVストリームに対して多重分離を行い、ビデオストリーム、オーディオストリーム、副映像ストリーム、そしてデータカルーセル形式のライブラリ及びデータを得る。このうちデータカルーセル形式のライブラリ及びデータはメモリ１４に格納される。データカルーセル形式のライブラリ及びデータはメモリ１４に格納されるので、Javaモードアプリケーションからのロード命令に応じて、データカルーセル形式のライブラリ及びデータはメモリ１４からJava仮想マシン内のワーク領域に読み出されることになる。
【０２０９】
以上のように本実施形態によれば、Javaモードのアプリケ−ションプログラムにて利用され得るライブラリ及び表示用データを、データカルーセルと同様の形式で再生装置に供給するので、再生装置の内部構成をデジタル放送の受信装置と共通化することができる。これにより、デジタル放送の受信装置の機能を兼ねるような再生装置を構成することができる。
(第１０実施形態)
第１０実施形態は、ライブラリ−表示用データをインターリーブ記録の形態でBD-ROMに記録しつつも、再生装置からスイッチャ１５を省略する改良に関する。スイッチャ１５がなくなったため第１０実施形態に係るアプリケ−ションプログラムは、以下のようにインターリーブユニットの読み出しを行う。
【０２１０】
インターリーブユニットをACCESS UNITと共に読み出す場合、アプリケーションプログラムは、ファイル「ILUsss.CLASS」からの読み出しと「XXX.M2TS」からの読み出しとを連続して行う。
【０２１１】
ファイル「ILUsss.CLASS」からの読み出しは、ファイル「ILUsss.CLASS」をオープンし、オープンされたファイル「ILUsss.CLASS」の先頭位置を指定するようファイルポインタを設定する。ここまでは第１実施形態と同様である。この際アプリケーションプログラムは、ファイル「ILUsss.CLASS」の読出先となる領域を宣言しておく。そしてファイル「ILUsss.CLASS」の全体長を設定したREADコマンドをBDドライブ１に発行する。ここでいう読出先領域とは、メモリ１４のことであり、このコマンド発行により、ファイル「ILUsss.CLASS」は再生装置２００のメモリ１４に読み出されることになる。
【０２１２】
ファイル「XXX.M2TS」からの読み出しは、ファイル「XXX.M2TS」をオープンし、オープンされたファイル「XXX.M2TS」のうち、ACCESS UNITvの先頭位置を指定するようファイルポインタを設定する。ここまでは第１実施形態と同様である。この際アプリケーションプログラムは、ファイル「XXX.M2TS」の読出先となる領域を宣言しておく。ここでの読出先領域とは、トラックバッファ２のことである。そして以降、ACCESS UNITvの全体長を設定したREADコマンドをBDドライブ１に発行する。このコマンド発行により、ACCESS UNITvは再生装置２００のトラックバッファ２に読み出されることになる。
【０２１３】
以上のように本実施形態によれば、アプリケーションプログラムがファイルを読み出すにあたって、ファイル「ILUsss.CLASS」を読み出す場合の読出先と、ファイル「XXX.M2TS」を読み出す場合の読出先とを切り換えることにより、スイッチャ１５を用いずにインターリーブユニット読み出しと、AVストリーム読み出しとを実行することができる。
(第１１実施形態)
本実施形態は、BD-ROMの製造工程に関する実施形態である。図５０は、第１１実施形態に係るBD-ROMの製造工程を示すフローチャートである。
【０２１４】
BD-ROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ１０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ１０２、BD-ROMの原盤を作成し、プレス・貼り合わせを行って、BD-ROMを完成させるプレス工程１０３を含む。
【０２１５】
これらの工程のうち、BD-ROMを対象としたオーサリング工程は、シナリオ編集工程Ｓ２０１、素材エンコード工程Ｓ２０２、多重化工程Ｓ２０３、フォーマッティング工程Ｓ２０４という工程とからなる。
【０２１６】
シナリオ編集工程Ｓ２０１とは、企画段階において作成された筋書きを再生装置が理解できる形式に変換する工程である。シナリオ編集の結果は、BD-ROM用の静的シナリオとして生成される。また、このシナリオ編集において、多重化を実現するため多重化パラメータの等も生成される。
【０２１７】
素材エンコード工程Ｓ２０２とは、ビデオ素材、オーディオ素材、副映像素材のそれぞれをエンコードして、ビデオストリーム、オーディオストリーム、副映像ストリームを得る作業である。
【０２１８】
多重化工程Ｓ２０３では、素材エンコードにより得られた、ビデオストリーム、オーディオストリーム、副映像ストリームをインターリーブ多重化して、これらを1本のAVストリームに変換する。
【０２１９】
一方、これらの工程と並行して、Java言語によるプログラム(工程Ｓ２０４、Ｓ２０５)が実行される。
Javaアプリケーション制作工程Ｓ２０４は、Java言語を用いてJavaアプリケーションを制作する工程である。
【０２２０】
ライブラリ制作工程Ｓ２０５は、ライブラリを制作する工程である。
フォーマッティング工程Ｓ２０６は、工程Ｓ２０１〜Ｓ２０５にて得られたAVストリーム、静的シナリオ、動的シナリオ、ライブラリをBD-ROMのフォーマットに適合させる。この適合にあたって、第１実施形態に示したように、AVストリームを複数のセグメントに分割し、各セグメントの合間にライブラリを記録するとの処理がなされる。
【０２２１】
上述した工程のうち、工程Ｓ２０４において、Javaアプリケーションである動的シナリオは、Java言語を用いた記述が可能であるから、通常のコンピュータ向けのソフトウェアを開発するのと同じ感覚で、開発することができる。よって本実施形態では、このシナリオ制作の効率を高めることができるという効果がある。
【０２２２】
(第１２実施形態)
本実施形態では、BDにおけるAVストリームを、BD-R,BD-RE等の記録型記録媒体にコピーする実施形態である。その際記録装置は、動的シナリオ、テーブルをWEBサイトからダウンロードする。このテーブルは、図２２（ａ）に示したようなAVストリーム再生時間軸に対する、ライブラリ生存区間の割り付けを示す。テーブルには、生存区間割り付けが示されているので、第１実施形態に示したように生存区間IN点を基準にしてAVストリームを分割し、セグメントの合間にセグメント内に生存区間をもつライブラリを記録する。この記録にあたってライブラリはインターリーブユニットに変換しておく。
【０２２３】
こうすることで、ライブラリが記録されていないバージョンのBDを、ライブラリや動的シナリオが記録されたバージョンにアップグレードすることができる。  （備考）
上記実施形態に基づいて説明してきたが、現状において最善の効果が期待できるシステム例として提示したに過ぎない。本発明はその要旨を逸脱しない範囲で変更実施することができる。代表的な変更実施の形態として、以下(A)(B)(C)・・・・のものがある。
【０２２４】
(A)第２実施形態では、1つの表示用データのみインターリーブユニットに格納していたが、複数の表示用データを1つのインターリーブユニットに変換してBD-ROMに記録してもよい。図５１は、複数の表示用データを格納したインターリーブユニットを示す図である。本図におけるイメージ系データ、文書系データ、描画系データは、それぞれ複数の表示用データであり、かかるインターリーブユニットをBD-ROMに記録しておくことにより、インターリーブユニットの一回の読み出しにて複数の表示用データをメモリに格納しておくことができる。尚、この場合、ヘッダには、インターリーブユニットに含まれるそれぞれのファイルについての情報を記述しておく必要がある。
【０２２５】
(B)図１２に示したレイアモデルにおいて、Javaモードの上にブラウザモード及びMOVIEモードを配置してもよい。特にMOVIEモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、MOVIEモードをJavaモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が1つのモードで済むからである。
【０２２６】
更に3つのモードを設けず、JavaモードだけでJavaモードの処理を実行してもよい。JavaモードでもPLの再生と同期した再生制御が可能になるから、強いてMOVIEモードを設けなくてもよいという理由による。更に動的シナリオにおける制御は、MOVIEモードだけでも、ブラウザモードだけでもよい。
【０２２７】
(B)全ての実施形態では、本発明に係る光ディスクをBD-ROMとして実施したが、本発明の光ディスクは、記録されるインターリーブユニットがあり、この特徴は、BD-ROMの物理的性質に依存するものではない。光ディスクなら、どのような光ディスクであってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。
【０２２８】
動的シナリオ、プレイリスト情報は、AVストリーム及びストリーム管理情報と別々の記録媒体に記録されてもよい。そしてこれらをパラレルに読み出して、1つの映画作品として再生させてもよい。
【０２２９】
(C) 全ての実施形態における再生装置は、BD-ROMに記録されたAVストリームをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０２３０】
(D)図２６、図３８、図４４に示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(E)図２６、図３８、図４４のフロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０２３１】
(F)Javaモードのアプリケーションは、コンピュ−タ・グラフィックスを描画するようなアプリケーションであったが、Java言語で記述されるアプリケーションであればどのようなものであってもよい。例えば電子商取引(EC(Electronic Commerce))のクライアントアプリケーションであってもよい。映画作品の動画を交えながら商品案内を行うようなJavaモードのアプリケーションを実現することができるので、映画作品に関連するキャラクタビジネスを成功に導くことができる。またJavaモードのアプリケーションは、ネット対戦型のオンラインゲームであってもよい。更に、Javaモードのアプリケーションにてコンピュ−タ・グラフィックスにて表現されるキャラクタは、エージェントとしての処理を行うものであてもよい。エージェントとしてのキャラクタは、再生装置のヘルプ機能を実現するものであったり、ユーザに助言を行うものでもよい。
【０２３２】
WebPageオブジェクトがWEBサイトから取得する情報は、WEBページであってもよいし、画像データであってもよい。また、AVストリーム、ストリーム管理情報、PL情報であってもよい。またWebPageオブジェクトは、検索エンジンと連携して処理を行ってもよい。
【０２３３】
更に、エンハンスドモードにおける記述言語は、C++やC＃言語であってもよい。
(G)BD-ROMに記録するにあたって、AVストリームを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arribval_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”Aligned Unit”という。
【０２３４】
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、Aligned Unitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArribval_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置２００はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
【０２３５】
(H)第１２実施形態では、AVストリームにコピー世代情報(CGI)を埋め込んで、AVストリームの制限付きコピーを認めてもよい。コピー世代情報には、自由にコピー可能な旨を示す『copy free』と、１世代の複製物の記録が許可されている旨を示す『one generation copy』と、複製物の更なる複製は禁止されている旨を示す『no more copy』と、一切のコピーを認めない旨を示す『never copy』とがある。つまり、コンテンツに埋め込まれたコピー世代情報が『copy free』や『one generation copy』を示している場合のみ、HDからDVDへのバックアップを行い、『no more copy』『never copy』を示している場合、バックアップは行わないのである。
【０２３６】
(I)AVストリームに権利管理情報は付加されている場合、第１２実施形態では権利管理情報に定められた利用条件において、AVストリームのコピーを行うべきである。
権利管理情報において回数指定で、コピーの許可条件が規定されているなら、この条件内でコピーを行う。有効期間の指定(年月日の指定がでコピーの条件が規定されているのならこの条件内でコピーを行う。
【０２３７】
(J)コピー処理に、移動やマイグレイト、チェックアウトといったバリエーションが存在する場合、これらバリエーション毎に、定められた利用条件に基づきバックアップを行っても良い。移動とは、コピー元のコンテンツの削除が伴うコピー処理であり、複数記録媒体間でコンテンツを移動する場合に用いられる。
【０２３８】
マイグレイトとは、コピー先記録媒体において、利用条件情報を生成させることを前提にしたコピー処理である。
チェックアウトとは、回数制限されたコピーの一種であり、コピー回数を1回デクリメントした上でコンテンツのコピーが実行される。一般にいう回数制限付きのコピーと、チェックアウトとの違いは、コピー回数のインクリメントが可能である点である。コピー回数のインクリメントは、コピーにより記録媒体に記録されたコンテンツを再生不能にするという処理("チェックイン"と呼ばれる。)を行った後でなされる。
【０２３９】
(K)各実施形態におけるAVストリームは、DVD-Video規格、DVD-Video Recording規格のVOB(Video Object)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。また、各実施形態におけるAVストリームを、”AVClip”と呼んでもよい。この場合、ストリーム管理情報はClip情報と呼ぶことになる。またAVストリームにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式であってもよい。
【０２４０】
(L)各実施形態におけるCell情報は、時間情報により再生区間の開始点、終了点を指定していたが、BD-ROMにおける論理アドレスを用いて再生区間の開始点、終了点を指定してもよい。また、各実施形態におけるCELLを”PlayItem”と呼んでもよい。
【０２４１】
(M)ストリーム管理情報におけるTMAPは、EP_mapと呼んでもよい。この場合、ACCESS UNITの再生開始時刻を、ACCESS UNIT先頭に位置するピクチャデータのタイムスタンプ(Presentation Time Stamp)で表現するのが望ましい。またACCESS UNITにおけるアドレスは、PESパケットの連番(SPN(Serial Packet Number))で表現するのが望ましい。
【０２４２】
(N)再生装置の構成において、動的シナリオメモリ２１には、カレントの動的シナリオのみを格納し、静的シナリオメモリ１１には、カレントのストリーム管理情報、カレントのPL情報のみを格納するとしたが、複数のシナリオ、ストリーム管理情報、PL情報を予め格納しておいてもよい。こうすれば、これらのデータをBD-ROMから読み出すまでのタイムラグを短くすることができる。
【０２４３】
(O)PLを構成する2以上のCELLを連続再生させるには、これらのCELLがシームレス接続されよう、加工を施しておくことが望ましい。
シームレス接続のための加工は、動画データにおいて先行する側の再生区間の終端部と、後続する側の再生区間の先端部とを複製することにより、予め複製部分を作成しておき、これらを再エンコードすることで、実現される。尚、シームレス接続のために作成された複製部分を、Bridge-Clipと呼んでもよい。
【０２４４】
ここで終端部、先端部は、以下のように設定するのが望ましい。
つまり先行するVOB＃xのうち先行再生区間のOut点を含むACCESS UNITから、2個先のACCESS UNITまでを終端部とし、また後続するCELL情報＃x+1のうち後続再生区間のIn点を含むACCESS UNITを先端部とするのが望ましい。終端部及び先端部をこのように定める根拠は、同出願人の先行技術米国特許USP,6148,140公報により記載されているので、詳細に関してはこの公報を参照されたい。
【０２４５】
更に、シームレス接続のために作成された複製部分については、シームレス接続情報を設けておくことが望ましい。シ−ムレス接続情報とは、最初のビデオフレームの再生開始時刻、最後のビデオフレームの再生終了時刻、オーディオギャップの開始時刻、オーディオギャップの時間長、オーディオギャップの位置情報を含む情報である。かかるシームレス接続情報が定義されていれば、最初のビデオフレームの再生開始時刻、最後のビデオフレームの再生終了時刻から、両区間のタイムスタンプの差(STC-Offset)を計算して、再生装置に設定することができる。また、これらオーディオギャップの情報を参照して、オーディオデコーダを制御すれば、1つの区間から別の区間への移行する際の音声の途切れを防止することができる。
【０２４６】
(P)各実施形態における映画作品は、テレビ映画、ゲームソフト等、映像をもって表現されている全ての著作物を意味する。何故なら、各実施形態における映画作品は、ブラウン管や液晶での表示など、視覚的又は視聴覚的効果を生じさせる方法で表現され(i)、BD-ROMという有体物に、何らかの方法で結びつくことにより同一性を保ちながら存続しており(ii)、かつ再現が可能な状態におかれているので(iii)、映画の著作物の存在形式としての要件を満たすからである。
【０２４７】
しかし本発明の本質的要素は、この映画作品であることに限定されるものではないので、本発明の動画データは、監視カメラの映像や家庭用ビデオカメラの映像であってもよい。
【０２４８】
(Q)第２実施形態において描画系データは、コンピュ−タ・グラフィックスのデータであってもよい。かかるデータには、NURBS(Non Uniform Rational B-Splline)形式のデータ、ポリゴン形式がある。NURBSとは、ベジェ曲線の束であって(このようなベジェ曲線の束はB-Spllineと呼ばれる。)、それぞれのベジェ曲線の曲率が不均一なものをいう。
【０２４９】
ポリゴン形式とは、多面体近似により特定の立体形状を表現するよう規定されたデータ形式であり、アメリカ・オートキャド社が規定したData eXcange Format(DXF)を初め、HRC,WAVEFRONT,IV,VRML形式等のものが広く知られている。
【０２５０】
また第２実施形態に示したイメージ系データを、テクスチャマッピングに利用してもよい。テクスチャマッピングとは、三次元形状の平面又は曲面に、静止画、ビットマップ等のテクスチャパターンを貼り付けて表示させる処理をいう。    コンピュ−タ・グラフィックスの描画のため、OPEN-GLやJava3D等のプログラムを、インターリブ記録しておいてもよい。
【０２５１】
(R)各実施形態では、ユーザによる映画作品の選択操作を、リモコンから受け付けたが、再生装置のフロントパネルから受け付けてもよい。キーボード、タッチパネル、マウスやパッド、トラックボール等の入力機器にてユーザの指定を受け付けてもよい。この場合は、クリック操作、ドラッグ操作でこれらの操作を受け付けてもよい。
【０２５２】
(S)各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
【０２５３】
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０２５４】
(T)Javaモジュール１７は、衛星放送受信のために機器に組み込まれたJavaプラットフォームであってもよい。Javaモジュール１７がかかるJavaプラットフォームであれば、本発明に係る再生装置は、MHP用STBとしての処理を兼用することになる。
【０２５５】
更に携帯電話の処理制御のために機器に組み込まれたJavaプラットフォームであってもよい。かかるJavaモジュール１７がかかるJavaプラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
【０２５６】
またBROWSERモジュール１８は、MicroSoft社のInternet Explore等、パソコン組み込み型のブラウザソフトであってもよい。
【符号の説明】
【０２５７】
１     BDドライブ
２    トラックバッファ
３    デマルチプレクサ
４    ビデオデコーダ
５    ピクチャプレーン
６    オーディオデコーダ
８    イメージプレーン
９    イメージデコーダ
１０    加算器
１１    静的シナリオメモリ
１２    再生制御エンジン
１３    プレーヤレジスタ
１４    メモリ
１５    スイッチャ
１６    DVDライクモジュール
１８    BROWSERモジュール
１７    Javaモジュール
１９    UOマネージャ
２１    動的シナリオメモリ
２００    再生装置
３００    テレビ
４００    リモコン
【産業上の利用可能性】
【０２５８】
本発明に係る光ディスクは、ゲームソフトの動作環境を、映画作品を再生するための動作環境に近づけることができるので、より魅力ある映画作品を市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る光ディスク、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
【図１】
0004764631.tif 000002
【図２】
0004764631.tif 000003
【図３】
0004764631.tif 000004
【図４】
0004764631.tif 000005
【図５】
0004764631.tif 000006
【図６】
0004764631.tif 000007
【図７】
0004764631.tif 000008
【図８】
0004764631.tif 000009
【図９】
0004764631.tif 000010
【図１０】
0004764631.tif 000011
【図１１】
0004764631.tif 000012
【図１２】
0004764631.tif 000013
【図１３】
0004764631.tif 000014
【図１４】
0004764631.tif 000015
【図１５】
0004764631.tif 000016
【図１６】
0004764631.tif 000017
【図１７】
0004764631.tif 000018
【図１８】
0004764631.tif 000019
【図１９】
0004764631.tif 000020
【図２０】
0004764631.tif 000021
【図２１】
0004764631.tif 000022
【図２２】
0004764631.tif 000023
【図２３】
0004764631.tif 000024
【図２４】
0004764631.tif 000025
【図２５】
0004764631.tif 000026
【図２６】
0004764631.tif 000027
【図２７】
0004764631.tif 000028
【図２８】
0004764631.tif 000029
【図２９】
0004764631.tif 000030
【図３０】
0004764631.tif 000031
【図３１】
0004764631.tif 000032
【図３２】
0004764631.tif 000033
【図３３】
0004764631.tif 000034
【図３４】
0004764631.tif 000035
【図３５】
0004764631.tif 000036
【図３６】
0004764631.tif 000037
【図３７】
0004764631.tif 000038
【図３８】
0004764631.tif 000039
【図３９】
0004764631.tif 000040
【図４０】
0004764631.tif 000041
【図４１】
0004764631.tif 000042
【図４２】
0004764631.tif 000043
【図４３】
0004764631.tif 000044
【図４４】
0004764631.tif 000045
【図４５】
0004764631.tif 000046
【図４６】
0004764631.tif 000047
【図４７】
0004764631.tif 000048
【図４８】
0004764631.tif 000049
【図４９】
0004764631.tif 000050
【図５０】
0004764631.tif 000051
【図５１】
0004764631.tif 000052