JP2007036663A

JP2007036663A - 互換性を考慮した情報記録媒体およびその記録装置、記録方法、記録プログラム

Info

Publication number: JP2007036663A
Application number: JP2005216993A
Authority: JP
Inventors: Shigeki Matsunaga; 繁樹松永; Hiroshi Yabaneta; 洋矢羽田
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2005-07-27
Filing date: 2005-07-27
Publication date: 2007-02-08

Abstract

【課題】映像記録形式で記録されたDiscを映像配布形式で記録されたDisc専用の再生装置では再生出来ないという課題があった。
【解決手段】１つの映像ストリームを映像記録形式用のナビゲーション情報と映像配布形式用のナビゲーション情報の双方から参照可能な形式で記録することで、ＢＤ−ＲＥなどの映像記録形式で記録しつつも、ＢＤ−ＲＯＭなどの映像配布形式として認識、再生可能な情報記録媒体、ならびに映像記録装置、記録方法、記録プログラムを提供可能となる。
【選択図】図４７

Description

本発明は、ＢＤ−ＲＯＭ及びＢＤ―ＲＥ等、映像データを記録した情報記録媒体、その記録装置及び記録方法に関し、特に、映像データとプログラムとを含むコンテンツを互換性を保った状態で記録する場合の改良に関する。

映像データを記録した情報記録媒体の代表格は、ＤＶＤ（以下、ＳＤ−ＤＶＤまたは単にＤＶＤと称する）である。以降、従来のＤＶＤについて説明する。

図１は、ＳＤ−ＤＶＤの構造を示した図である。図１の下段に示すように、ＤＶＤディスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられ、論理アドレス空間の先頭からファイルシステムのボリューム情報が記録され、続いて映像音声などのアプリケーションデータが記録されている。

ファイルシステムとは、ＩＳＯ９６６０やＵＤＦ（ＵｎｉｖｅｒｓａｌＤｉｓｃＦｏｒｍａｔ）のことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。日常使っているＰＣ（パーソナルコンピュータ）の場合でも、ＦＡＴまたはＮＴＦＳと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。ＳＤ−ＤＶＤの場合、ＵＤＦ及びＩＳＯ９６６０両方を使用しており（両方を合わせて「ＵＤＦブリッジ」と呼ぶ事がある）、ＵＤＦまたはＩＳＯ９６６０どちらのファイルシステムドライバによってもデータの読み出し（ここで取り扱うＤＶＤはパッケージメディア用のＲＯＭディスクであり、物理的に書き込みが不可能である）ができるようになっている。

ＤＶＤ上に記録されたデータは、ＵＤＦブリッジを通して、図１左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図中「ＲＯＯＴ」）の直下に「ＶＩＤＥＯ＿ＴＳ」と呼ばれるディレクトリが置かれ、ここにＤＶＤのアプリケーションデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下のものがある。

ＶＩＤＥＯ＿ＴＳ．ＩＦＯディスク再生制御情報ファイル
ＶＴＳ＿０１＿０．ＩＦＯビデオタイトルセット＃１再生制御情報ファイル
ＶＴＳ＿０１＿０．ＶＯＢビデオタイトルセット＃１ストリームファイル
．．．．．
拡張子として２つの種類が存在する。「ＩＦＯ」は再生制御情報が記録されたファイルであって、「ＶＯＢ」はＡＶデータであるＭＰＥＧストリームが記録されたファイルである。再生制御情報とは、ＤＶＤで採用されたインタラクティビティ（ユーザの操作に応じて再生を動的に変化させる技術）を実現するための情報や、メタデータのようなタイトルやＡＶストリームに付属する情報などのことである。また、ＤＶＤでは一般的に再生制御情報のことをナビゲーション情報と呼ぶことがある。

再生制御情報ファイルは、ディスク全体を管理する「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」と、個々のビデオタイトルセット（ＤＶＤでは複数のタイトル、言い換えれば異なる映画や異なるバージョンの映画を１枚のディスクに記録することが可能である。）毎の再生制御情報である「ＶＴＳ＿０１＿０．ＩＦＯ」がある。ここで、ファイル名ボディにある「０１」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット＃２の場合は、「ＶＴＳ＿０２＿０．ＩＦＯ」となる。

図１の右上部は、ＤＶＤのアプリケーション層でのＤＶＤナビゲーション空間であり、前述した再生制御情報が展開された論理構造空間である。「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」内の情報は、ＶＭＧＩ（ＶＩＤＥＯＭａｎａｇｅｒＩｎｆｏｒｍａｔｉｏｎ）として、「ＶＴＳ＿０１＿０．ＩＦＯ」または、他のビデオタイトルセット毎に存在する再生制御情報はＶＴＳＩ（ＶｉｄｅｏＴｉｔｌｅＳｅｔＩｎｆｏｒｍａｔｉｏｎ）としてＤＶＤナビゲーション空間に展開される。

ＶＴＳＩの中にはＰＧＣ（ＰｒｏｇｒａｍＣｈａｉｎ）と呼ばれる再生シーケンスの情報であるＰＧＣＩ（ＰｒｏｇｒａｍＣｈａｉｎＩｎｆｏｒｍａｔｉｏｎ）が記述されている。ＰＧＣＩは、Ｃｅｌｌの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。Ｃｅｌｌ自身はＶＯＢ（ＶｉｄｅｏＯｂｊｅｃｔの略であり、ＭＰＥＧストリームを指す）の一部区間または全部区間の集合であり、Ｃｅｌｌの再生は、当該ＶＯＢのＣｅｌｌによって指定された区間を再生することを意味している。

コマンドは、ＤＶＤの仮想マシンによって処理されるものであり、ブラウザ上で実行されるＪａｖａ（登録商標）スクリプトなどに近いものである。しかしながらＪａｖａ（登録商標）スクリプトが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドを開くなど）を行うのに対して、ＤＶＤのコマンドは、論理演算の他にＡＶタイトルの再生制御、例えば、再生するチャプタの指定などを実行するだけのものである点で異なっている。

Ｃｅｌｌはディスク上に記録されているＶＯＢの開始及び終了アドレス（論理アドレス）をその内部情報として有しており、プレーヤは、Ｃｅｌｌに記述されたＶＯＢの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。

図１はＡＶストリーム中に埋め込まれているナビゲーション情報を説明する概略図である。ＳＤ−ＤＶＤの特長であるインタラクティビティは前述した「ＶＩＤＥＯ＿ＴＳ．ＩＦＯ」や「ＶＴＳ＿０１＿０．ＩＦＯ」などに記録されているナビゲーション情報だけによって実現されているのではなく、幾つかの重要な情報はナビゲーション・パック（ナビパックまたは、ＮＶ＿ＰＣＫと称する）と呼ばれる専用キャリアを使いＶＯＢ内に映像、音声データと一緒に多重化されている。

ここでは簡単なインタラクティビティの例としてメニューを説明する。メニュー画面上には、幾つかのボタンが現れ、夫々のボタンには当該ボタンが選択実行された時の処理が定義されている。また、メニュー上では一つのボタンが選択されており（ハイライトによって選択ボタン上に半透明色がオーバーレイされている）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。リモコンの上下左右キーを使って、選択実行したいボタンまでハイライトを移動させ、決定する（決定キーを押す）ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプタの再生がコマンドによって実行されている。

図２の左上部はＮＶ＿ＰＣＫ内の概要を示している。
ＮＶ＿ＰＣＫ内には、ハイライトカラー情報と個々のボタン情報などが含まれている。ハイライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報（ユーザの上下左右キー操作夫々に対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）が記述されている。

メニュー上のハイライトは、図２の中央右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色をつけた物である。このオーバーレイ画像は右部に示す背景画像と合成されて画面上に表示される。

上述のようにして、ＤＶＤではメニューを実現している。また、何故、ナビゲーションデータの一部をＮＶ＿ＰＣＫを使ってストリーム中に埋め込んでいるのは、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中５分〜１０分の間にだけメニューが表示されるなど、同期タイミングが問題となりやすいアプリケーションの場合でも、問題なく実現できるようにしたためである。

図３は、ＤＶＤのＶＯＢのイメージである。図に示すように、映像、音声、字幕などのデータ（Ａ段）は、ＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格に基づいて、パケット及びパック化し（Ｂ段）、夫々を多重化して１本のＭＰＥＧプログラムストリームにしている（Ｃ段）。また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだＮＶ＿ＰＣＫも一緒に多重化をされている。

ＭＰＥＧシステムの多重化の特徴は、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。これはＭＰＥＧシステムストリームのデコーダモデル（一般にＳｙｓｔｅｍＴａｒｇｅｔＤｅｃｏｄｅｒ、またはＳＴＤと呼ばれる（図３のＤ段））が多重化を解いた後に個々のエレメンタリーストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している事に由来している。このデコーダバッファは、個々のエレメンタリーストリーム毎にサイズが異なり、映像に対しては、２３２ｋＢ、音声に対しては４ｋＢ、字幕に対しては５２ｋＢを夫々有している。このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、ＭＰＥＧシステムストリームとしてビット列を形成する順番と表示（デコード）されるタイミングにずれが生じている。

即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされているわけでは無い。

かかるＤＶＤの構成は、以下の特許文献１に記載されている。
特許第２８１３２４５号公報

ところでビデオカメラで撮影した映像をDiscに記録する形式と、映画などのコンテンツを記録し配布するために映像をDiscに記録する形式とは、撮影と配布という用途の違いにより映像記録形式が異なる。例えば次世代の情報記録媒体であるBDでも録画・撮影用のBD-REと映画等の配布用のBD-ROMという二つの形式に分かれている。
このため、BD-RE形式で録画したDiscをBD-ROM専用の再生装置では再生出来ないという問題が発生する。

本発明の目的は、BD-REなどの映像記録用の形式で記録しつつも、BD-ROMなどの映像配布用の形式として認識、再生可能な情報記録媒体、ならびに記録装置、記録方法、記録プログラムを提供することである。

上記課題を解決するため本発明にかかる情報記録媒体は、１つの映像ストリームを映像記録用の形式のナビゲーション情報と映像配布用の形式のナビゲーション情報の双方から参照可能な形式で記録されていることを特徴としている。

上述した構成では、ビデオカメラ等で映像を撮影、録画したDiscを、映画等の商用配布されたDiscの再生専用装置において最適な形式で再生可能となる。

（実施の形態１）
まず最初に本発明の第１の実施の形態について説明する。
（ディスク上の論理データ構造）
図４は、ＢＤ−ＲＯＭ（以降、「ＢＤ」と称する場合もある）の構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、ＢＤディスクをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の記録媒体としてしようすることも当然のことながら可能である。

図５は、上述したＢＤディスクに記録されている論理データを示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（ＢｕｒｓｔＣｕｔｔｉｎｇＡｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。

論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。

本実施の形態の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータ（図４で説明した１０１、１０２、１０３）が記録されているディレクトリである。

ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。

ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わるプログラムを記録したファイルである。

ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（ＰｌａｙＬｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。

ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。

ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。

ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。

ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。

（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図６及び図７を用いて説明する。

図６は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに記録される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々記録される。

プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。

プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する
。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、実行処理する。

管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリスト及びプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。

プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）及びイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。

図６で示すように、ＢＤプレーヤは図４で示したＢＤディスクに記録されているデータ構成に基づいた構成をとっている。

図７は前述したプレーヤ構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。

ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）及びサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。

イメージメモリ（３０８）に記録されたＰＮＧは、次の２つの処理方法がある。イメージデータが字幕用の場合は、プレゼンテーションコントローラ（３０６）によってデコードタイミングが指示される。クロック（３０７）からの時刻情報をシナリオプロセッサ（３０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ（３０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（３０６）からデコード／表示の指示を受けたイメージプロセッサ（３１１）は対応するＰＮＧデータをイメージメモリ（３０８）から抜き出し、デコードし、イメージプレーン（３１４）に描画する。

次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（３０２）によってデコードタイミングが指示される。プログラムプロセッサ（３０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（３０２）が処理しているＢＤプログラムに因るものであって一概には決まらない。

イメージデータ及び映像データは、図６で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に記録され、合成処理部（３１６）によって合成出力される。

ＢＤディスク（２０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（３０４）に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（３０５）によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（３０６）によって読み出され処理される。

シナリオプロセッサ（３０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（３０６）に指示し、プレゼンテーションコントローラ（３０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（３１７）に指示を出す。

ドライブコントローラ（３１７）はプレゼンテーションコントローラ（３０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（３０８）またはトラックバッファ（３０９）に記録される。

また、シナリオプロセッサ（３０５）は、クロック（３０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（３０２）に投げる。

プログラム記録メモリ（３０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ（３０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（３０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（３０３）からイベントが送られたきた場合である。ＵＯＰマネージャ（３０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（３０２）にイベントを生成する。

（アプリケーション空間）
図８は、ＢＤ−ＲＯＭのアプリケーション空間をを示す図である。

ＢＤ−ＲＯＭのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤ−ＲＯＭの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択することである。

ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。

時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図７で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。

ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。

二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する）を実装することができる。

プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にタイムマップ（ＴｉｍｅＭａｐまたはＴＭ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。

（ＶＯＢの詳細）
図９は、本実施の形態で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。図９に示すように、ＶＯＢは複数のＶＯＢＵ（ＶｉｄｅｏＯｂｊｅｃｔＵｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（ＧｒｏｕｐＯｆＰｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは０．４秒から１．０秒の時間を持ち、通常は０．５秒の再生時間を持っている。これはＭＰＥＧのＧＯＰの構造が通常は１５フレーム／秒（ＮＴＳＣの場合）によって導かれるものである。

ＶＯＢＵは、その内部にビデオパック（Ｖ＿ＰＣＫ）とオーディオパック（Ａ＿ＰＣＫ）を有している。各パックは１セクタ、本実施の形態の場合は２ｋＢ単位で構成されている。

図１０は、パックの構成を示した図である。
図１０に示すように、ビデオデータ及びオーディオデータといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ１つのパケットを構成する。パケットヘッダには、ペイロードに格納してあるデータがどのストリームなのか、ビデオなのかオーディオなのか、また、ビデオまたはオーディオが夫々複数ストリームある場合は、どのストリームのデータなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）と、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプＤＴＳ及びＰＴＳが夫々記録されている。ＰＴＳ／ＤＴＳは必ずしも全てのパケットヘッダに記録されている訳ではなく、ＭＰＥＧによって記録するルールが規定されている。ルールの詳細についてはＭＰＥＧシステム（ＩＳＯ／ＩＥＣ１３８１８−１）規格書に記述されているので省略する。

パケットには更にヘッダ（パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプＳＣＲ（ＳｙｓｔｅｍＣｌｏｃｋＲｅｆｅｒｅｎｃｅ）が記録されている。

（ＶＯＢのインターリーブ記録）
次に図１１及び図１２を用いてＶＯＢファイルのインターリーブ記録について説明する。

図１１上段は、前述したプレーヤ構成図の一部である。図の通り、ＢＤディスク上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファへ入力され、ＰＮＧ即ちイメージデータであればイメージメモリへと入力される。

トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＳＣＲに従って個々のパックはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。

図１１下段は、ＢＤディスク上でのＶＯＢファイル及びＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤ−ＲＯＭの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。

字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、非現実的である。

そこで、本実施の形態では、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図１１下段はそのインターリーブ記録を説明した図である。ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。

図１２は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。

既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レートとトラックバッファからのデータ出力レートの間に差を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。ここでトラックバッファへの入力レートをＶａ、トラックバッファからの出力レートをＶｂとする。図１２の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。

図１２の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。

Ｂ（ｔ２）＝（Ｖａ−Ｖｂ）×（ｔ２−ｔ１）（式１）
この後、ＢＤディスク上のアドレス”ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである”−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”ａ３”まで、時刻でいう”ｔ３”までになる。

ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。

この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２）（式２）
即ち、式２を満たすようにイメージデータの配置を決めればよい事になる。
（ナビゲーションデータ構造）
図１３から図１９を用いて、ＢＤ−ＲＯＭのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。図１３は、ＶＯＢ管理情報情報ファイル（”ＹＹＹ．ＶＯＢＩ”）の内部構造を示した図である。

ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップ（ＴＭＡＰ）を有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、データフィールドの有無を示している。

下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）
６０
５９．９４
５０
３０
２９．９７
２５
２４
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドと夫々が持ち得る値である。

圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵの再生時間長（Ｄｕｒａｔｉｏｎ）とＶＯＢＵのデータサイズ（Ｓｉｚｅ）を夫々有している。

図１４はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧストリームは時間的側面とデータサイズとしての側面との２つを有している。例えば、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一般式の形で表現することは不可能である。

当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータとを一般式の形で表現することは不可能である。これに代わって、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。図１４に示すように、各ＶＯＢＵ毎にＶＯＢＵ内のフレーム数と、ＶＯＢＵ内のパック数を夫々エントリーとして持つテーブルがタイムマップ（ＴＭＡＰ）である。

図１５を使って、タイムマップ（ＴＭＡＰ）の使い方を説明する。
図１５に示すように時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索する。これは、タイム亜マップのＶＯＢＵ毎のフレーム数を加算して行き、フレーム数の和が当該時刻を（フレーム数に換算して）超えるまたは一致するＶＯＢＵが当該ＶＯＢＵになる。次にタイムマップのＶＯＢＵ毎のサイズを当該ＶＯＢＵの直前のＶＯＢＵまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレスになっている。

次に図１６を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。

セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。

セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。有効区間開始時刻（Ｉｎ）及び有効区間終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップ（ＴＭＡＰ）を使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。

字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）最初の情報も言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）から構成されている。

各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇｕａｇｅ）と、個々に表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）から構成され、字幕情報（Ｓｐｅｅｃｈ＃）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）及び字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）から構成されている。

イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内であげられるイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）から構成され、個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント生成時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。

図１７は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（”ＸＸＸ．ＰＲＯＧ”）である。

イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。

次に図１８を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。

ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＴａｂｌｅ）から構成されている。

タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。

チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、チャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。

イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。

図１９は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。本テーブルは、図１７で説明したイベントハンドラテーブルと同一内容である。
（イベント発生のメカニズム）
図２０から図２２を使ってイベント発生のメカニズムについて説明する。

図２０はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、２つのボタンイメージの描画を行うなどを行うことができる。

図２１はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効規格情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。

図２１に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、プレイリスト＃２の再生を開始する。

生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。

図２２はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。

ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合ではプレイリスト＃３の再生を開始している。

本実施の形態では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。

（仮想プレーヤマシン）
図２３を用いてプログラムプロセッサの機能構成を説明する。

プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤ−ＲＯＭとして定義された機能モデルであって、各ＢＤ−ＲＯＭプレーヤの実装には依存しないものである。即ち、どのＢＤ−ＲＯＭプレーヤにおいても同様の機能を実行するできることを保証している。

仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ−ＲＯＭ固有関数として定義している。

リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃：プレイリスト名
Ｃｅｌｌ＃：セル番号
ｔｉｍｅ：セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ：ＰＮＧファイル名
Ｘ：Ｘ座標位置
Ｙ：Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ：Ｘ座標位置
Ｙ：Ｙ座標位置
Ｗ：Ｘ方向幅
Ｈ：Ｙ方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。

図２４はシステムパラメータ（ＳＰＲＭ）の一覧である。
ＳＰＲＭ（０）：言語コード
ＳＰＲＭ（１）：音声ストリーム番号
ＳＰＲＭ（２）：字幕ストリーム番号
ＳＰＲＭ（３）：アングル番号
ＳＰＲＭ（４）：タイトル番号
ＳＰＲＭ（５）：チャプタ番号
ＳＰＲＭ（６）：プログラム番号
ＳＰＲＭ（７）：セル番号
ＳＰＲＭ（８）：選択キー情報
ＳＰＲＭ（９）：ナビゲーションタイマー
ＳＰＲＭ（１０）：再生時刻情報
ＳＰＲＭ（１１）：カラオケ用ミキシングモード
ＳＰＲＭ（１２）：パレンタル用国情報
ＳＰＲＭ（１３）：パレンタルレベル
ＳＰＲＭ（１４）：プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５）：プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６）：音声ストリーム用言語コード
ＳＰＲＭ（１７）：音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８）：字幕ストリーム用言語コード
ＳＰＲＭ（１９）：字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０）：プレーヤリージョンコード
ＳＰＲＭ（２１）：予備
ＳＰＲＭ（２２）：予備
ＳＰＲＭ（２３）：再生状態
ＳＰＲＭ（２４）：予備
ＳＰＲＭ（２５）：予備
ＳＰＲＭ（２６）：予備
ＳＰＲＭ（２７）：予備
ＳＰＲＭ（２８）：予備
ＳＰＲＭ（２９）：予備
ＳＰＲＭ（３０）：予備
ＳＰＲＭ（３１）：予備
なお、本実施の形態では、仮想プレーヤのプログラミング関数をＪａｖａ（登録商標）Ｓｃｒｉｐｔベースとしたが、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔではなく、ＵＮＩＸ（登録商標）ＯＳなどで使われているＢ−Ｓｈｅｌｌや、ＰｅｒｌＳｃｒｉｐｔなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はＪａｖａ（登録商標）Ｓｃｒｉｐｔに限定されるものでは無い。

（プログラムの例）
図２５及び図２６は、イベントハンドラでのプログラムの例である。

図２５は、２つの選択ボタンを持ったメニューの例である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２５左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に”１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている事を初期値として持たされている。

次に、ＰＮＧの描画を描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行っている。ボタン１は、座標（１０、２００）を起点（左端）としてＰＮＧイメージ”１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左端）としてＰＮＧイメージ”２ｗｈｉｔｅ．ｐｎｇ”を描画している。

また、本セル最後ではタイムイベントを使って図２５右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。

図２６は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図２１で説明したとおり、ユーザイベントが生成され、図２６のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。

条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右ボタン２に変更する。

ボタン１、ボタン２のイメージを夫々書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合、プレ
イリスト＃２の再生を開始する
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合、プレイリスト＃３の再生を開始する
上記のようにして実行処理が行われる。

（プレーヤ処理フロー）
次に図２７から図３０を用いてプレーヤでの処理フローを説明する。

図２７は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤ−ＲＯＭプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯ及びＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。

続いて、シナリオプロセッサは、ＢＤ．ＩＮＦＯファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。

ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。この場合、ユーザイベントを受け付けるのを待ち続けることになる（Ｓ２０１）。ＢＤ−ＲＯＭプレーヤはがユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。

プログラムマネージャは、ＵＯＰイベントがメニューキーによるものであるかを判別し（Ｓ２０３）、メニューキーの場合は、シナリオプロセッサにＵＯＰイベントを流し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。

図２８は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。

ＡＶ再生の開始（Ｓ４０１）を開始すると、プレゼンテーションコントローラは再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）を読み込み及び解析をする（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出し（Ｓ４０３）、ＶＯＢデータがデコーダに送られ再生が開始される（Ｓ４０４）。ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。

図２９は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤ−ＲＯＭプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。

Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。

ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。

Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。

ステップＳ６０５でＵＯＰイベントがメニューコールで無いと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し（Ｓ６０６）、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行処理する（Ｓ６０８）。

ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。

図３０は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。

字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。

（実施の形態２）
次に本発明の第２の実施の形態について説明する。

第２の実施の形態は、ＢＤアプリケーションにおいてより豊かなインタラクティブ性を実現するため、Ｊａｖａ（登録商標）のようなプログラミング環境を導入することに関する内容である。基本的には第１の実施の形態に基づく内容であり、拡張または異なる部分を中心に説明する。

（プログラミング環境の導入）
実施の形態１において、図４が示す「ＢＤ再生プログラミング」の主な目的は、ＡＶデータの再生順序を規定する、あるいは、ユーザーの操作によりＡＶの再生順序を変更することであった。しかし、ＢＤ再生プログラミングとしてＪａｖａ（登録商標）のような汎用的なプログラミング環境を利用するのであれば、ＡＶ再生の制御のみならず様々なアプリケーションを提供することが可能である。本実施の形態では、汎用的なプログラミング環境としてＪａｖａ（登録商標）を想定しているが、Ｃ言語やその他のプログラミング言語であっても、同様である。

ＡＶ再生以外のアプリケーションが利用可能になったとしても、あるカテゴリーごとにＡＶ再生やアプリケーションを認識する方が、ユーザーには分かりやすくなる。カテゴリーとは映画本編や本編以外の付属のコンテンツとして提供される各種ゲームといったカテゴリーであり、カテゴリーをユーザーに認識できるようにするため、タイトルという単位を用意することとする。

実施の形態１においては、図１８が示すとおり、タイトルとは再生順序が記述されているプレイリストへのリンク情報であり、タイトルが指定されると関連付けられたプレイリストを参照して、プレイリストが参照しているセルやＡＶストリームが再生された。

本実施の形態においてタイトルが指定されると、プログラムを介したＡＶストリームが再生される場合もあれば、ＡＶストリームを再生しないアプリケーションが起動する場合もある。

図３１は図６を本実施の形態に合わせて拡張したものである。ディスクより読み込まれたプログラム（３１０１）は、プログラム処理部（３１０２）で処理される。プログラムは管理情報処理部やプレゼンテーション処理部に指示を出し、プレイリストを介してＡＶストリームを再生するものもあれば、通常のＪａｖａ（登録商標）アプリケーション同様にイメージプレーン（３１０４）に対して描画指示（３１０５）を行うものもある。

ＡＶストリームの再生のみを指示するアプリケーションの例としては、本編映画再生をユーザーの指示に従って行う単純な再生アプリケーションが挙げられる。ＡＶ再生を行わないアプリケーションの例としては、フル画面をプログラムで描画するゲームのようなアプリケーションが挙げられる。ＡＶを再生しながらアプリケーションとして描画することも可能であり、再生中のＡＶの上にプログラムが描画したイメージ図を重ねたり、移動させてアニメーションを行ったりすることも可能である。

タイトルはユーザーに認識されるＡＶストリームの再生及びアプリケーションの実行の単位であるが、同時にプレーヤがＡＶストリームの再生及びアプリケーションの実行を管理する単位でもある。
（アプリケーションの管理）
図３２はタイトルリスト（３２０１）が、アプリケーションの管理単位としてのタイトルを指し示している様子を示している。

タイトル＃１は映画本編が再生されるタイトルである。タイトル＃１が選択されると、本編映像再生用のアプリケーション（３２０２）が起動され、本編映像の再生が開始される。本編再生用のアプリケーションは、リモコンキーによる早送り・スキップなどのイベントを受けて、再生制御部に指示を出しプレーヤの動作をコントロールする。タイトル＃１が起動されると本編再生用アプリケーションとともに、ポップアップメニューを出現させるためのアプリケーション（３２０３）や、本編再生中の映像に出てきた品物を購入できるようなショッピングカートアプリケーション（３２０４）なども起動させる。

本編再生から別の目的のタイトルに移りたい場合は、タイトル切替を行う。たとえば本編再生中に出てきた品物を購入するためにオンラインショッピングアプリケーションを起動させたければ、オンラインショッピングを行うタイトル＃２に移動する。

タイトル＃１からタイトル＃２に移動すると、タイトル＃１の場合同様にタイトル＃２に関連したアプリケーション（３２０５）が起動されるとともに、タイトル＃２に関係ないアプリケーション（３２０２、３２０３）は停止する。タイトル＃１にもタイトル＃２にも関係するアプリケーション（３２０４）は、どちらのタイトルでも起動し続けることができ、タイトル＃１とタイトル＃２の間のタイトル遷移中に停止と再起動が起こるわけではない。

タイトル＃３はタイトル＃１及びタイトル＃２とは独立したタイトルであり、タイトル＃３が選択されると、タイトル＃１及びタイトル＃２で起動されていたアプリは停止し、タイトル＃３に関連したアプリケーション（３２０６）が起動される。

図３３はこれまで述べたような、タイトル単位でのアプリケーションの管理を実現するための管理情報について示している。

アプリケーション管理情報（３３０１）は、タイトル番号（３３０２）とアプリケーションＩＤ（３３０３）のペアを管理しており、指定されたタイトル中でどのアプリケーションが起動されるかを管理している。図３３中の例では、タイトル＃１において、アプリケーション＃１とアプリケーション＃２が起動され、タイトル＃２においてアプリケーション＃３が起動される。

タイトルが選択されるとすぐにアプリケーション管理情報にしたがって願連するアプリケーションが起動され（３３０４）、タイトルが変わると次のタイトルで関連付けられていないアプリケーションは終了し（３３０５）、次のタイトルに関連付けられているアプリケーションが起動される（３３０６）。

なお、アプリケーションＩＤとしては、Ａｐｐｌｅｔやｘｌｅｔなどの起動インターフェースを持ったクラスファイル名などでよい。

図３４は、拡張することによりタイトル開始時の起動状態を設定可能にしたアプリケーション管理情報について示している。

図３３で示されたアプリケーション管理情報は、あるタイトルが開始されたときには必ず関連付けられたアプリケーションが起動された。そこでタイトルが開始されたときに起動されるアプリケーションと起動されないアプリケーションを区別するために、タイトル開始時の起動状態（３４０１）を持たせることにする。

アプリケーション＃１はタイトル＃１に開始時に自動的に起動されるアプリケーションである。アプリケーション＃２は同じくタイトル＃１に関連付けられているが、タイトル開始時に自動的に起動はされない。アプリケーション＃２は、他のアプリケーションによって起動される（３４０２）、あるいはユーザー操作などのイベントにより起動される。

アプリケーション＃２は、タイトル＃１開始時に自動的に起動されることはないが、タイトル＃２に切り替わるときに起動していて、かつ、タイトル＃２に登録されていなければ、自動的に終了する。

アプリケーションの終了の仕方としては、アプリケーション＃２のように他のアプリやイベントによって起動する場合と同様、他のアプリやイベントによって終了することもある（３４０４）。このような場合、起動属性がＡｕｔｏＲｕｎ（自動的に起動）であっても、タイトル中で自動的に再起動することはない。タイトルが切り替わり、再びタイトル＃１が開始されたときは、自動的に起動される。

図３５は、アプリケーション管理情報の起動状態の拡張を行い、複数タイトル間で継続的にアプリケーションを起動しておく方法、アプリケーションのサスペンド状態を実現する方法を説明するためのものである。

複数のタイトルに対して、同じアプリケーションを登録しておくことにより、タイトルを越えてアプリケーションを起動させ続けることが可能となる。アプリケーション管理情報において、アプリケーション＃１はタイトル＃１にもタイトル＃２にも登録（３５０１、３５０２）されている。アプリケーション＃１はタイトル＃１開始時にＡｕｔｏＲｕｎ属性により自動的に起動される。タイトル＃１からタイトル＃２に遷移する際、アプリケーション＃１はタイトル＃２にも登録されているため、タイトル＃１終端で終了することなく、タイトル＃２に遷移する。このように複数タイトルに同一アプリケーションを登録しておけば、登録されているタイトル間を遷移する際にアプリケーションが終了後再起動されるようなことはない。

複数タイトルをまたげるアプリケーションであったとしても、登録されていないタイトルに遷移する際は終了される。アプリケーション＃１の例では、タイトル＃２からタイトル＃３に遷移する際は、アプリケーション＃１は終了される。次に、アプリケーションをサスペンド状態に遷移させる方法を説明する。通常の起動状態では、Ｊａｖａ（登録商標）ＶＭなどの実行環境において、実行環境内のメモリを割り当てられ、ＣＰＵリソースも割り当てられることにより実行されている。起動していないアプリケーションは、メモリもＣＰＵリソースも割り当てられていない。それに対して、サスペンド状態とは、実行環境内のメモリに格納されているが、ＣＰＵリソースは割り当てられていない状態であり、ＣＰＵリソースを割り当てられれば、いつでも実行可能となる。このようなサスペンド状態を管理するために、起動属性として「サスペンド」を追加する。起動属性としてサスペンドを指定されているアプリケーションは、起動していればサスペンド状態に遷移する。

図３５においてアプリケーション＃２がサスペンドされるアプリケーションである。アプリケーション＃２はタイトル＃１において起動され、タイトル＃２に遷移する際に自動的にサスペンド状態となる。アプリケーション＃２はタイトル＃２中において、実行環境のメモリ内には存在できるがＣＰＵリソースは割り当てられない状態である。タイトル＃３のアプリケーション管理情報では、アプリケーション＃２は通常状態（サスペンドではない）の起動属性を持っているため、タイトル＃２からタイトル＃３に遷移する際にアプリケーション＃２はレジュームされ、再び起動状態に戻る。

図３６は、起動属性によって、タイトル間遷移時に状態がどのように変化するかを示した図表である。これまでの例として述べてきたように、アプリケーションが起動していない状態で起動属性としてＡｕｔｏＲｕｎが指定されているタイトルに遷移すると、アプリケーションは自動的に起動される。すでにアプリケーションが起動された状態で起動属性がサスペンドであるタイトルに遷移すると、アプリケーションはサスペンドされる。アプリケーションがサスペンドされた状態で、起動属性がＡｕｔｏＲｕｎあるいは指定されていない（サスペンドではない）タイトルに遷移すると、アプリケーションはレジュームされ、起動状態に戻る。それ以外の場合はアプリケーションの状態に変化は起こらず、前の状態をそのまま継続する。

なお、アプリケーションは他のアプリケーションからの制御やイベントを受けてアプリケーション自体が反応することによって、アプリケーションの状態を変更することもある。図３４のアプリケーション＃２は、他のアプリケーションからの起動される例である。

なお、アプリケーションがサスペンドされている状態で、起動属性が指定されてないタイトルに遷移した際、レジュームするのではなく何もしなくてもよい。図３７はアプリケーション管理情報の管理単位の区分を示している。各単位ごとの管理情報は、単位ごと（タイトルの場合はタイトルごと、図３７の例）に管理情報を分割して別々に記録（３７０１）してもよいし、タイトルごとの管理情報でもまとめて図３５のアプリケーション管理情報ように管理してもよい。

ここまでのアプリケーション管理情報は、カテゴリの単位としてのタイトルを基本とし、タイトル単位でアプリケーションの起動や終了を管理していた。アプリケーションによっては複数のタイトルをまたげるものもあるが、ディスクに存在する全てのタイトルで有効なアプリケーションの場合は、全ての管理テーブルに書かなければならず、煩雑になる。そこで、ディスク全体で有効なアプリケーションに関しては、ディスク単位の管理情報（３７０２）を用意すれば、ディスクで一括して管理できるため管理が容易になる。

同様に、ディスク３枚組のようなパッケージがある場合は、ディスクセット単位でアプリケーションを管理するアプリケーション管理情報（３７０３）を、どのディスクにも同じ情報を記録しておくことで実現可能である。

また、これらの階層別のアプリケーション管理情報を組み合わせて使うことも可能である。組み合わせて利用する場合で、どちらか一方にしか登録されていない場合（たとえばディスクのアプリケーション管理情報には登録されていて、タイトルのアプリケーション管理情報には登録されていない場合）は、管理テーブルの和集合をとってプレーヤ内で独自のアプリケーション管理情報を構成すればよい。２つの管理テーブルで情報が異なる場合は、より有効範囲が狭い管理テーブル（先ほどの例では、タイトルのアプリケーション管理情報）を優先するようにしてもよい。

複数のディスクにまたがっても、アプリケーションを一意に指定するため、アプリケーションＩＤとして、オーサーが決めた独自の番号だけではなく、オーサーごとに割り振られた一意なＩＤとオーサーが決めた独自の番号を組み合わせることにより、他社製のコンテンツとアプリケーションＩＤが重なることを防ぐことも可能である。

なお、複数ディスクにまたがる管理情報の場合、ディスクが抜かれた状態でのアプリケーションの動作を規定することも可能である。ディスクが抜かれた状態ではアプリケーションを一時停止状態にする、あるいは、使用できる機能を限定しなければ、悪意を持ったアプリケーションやバグにより、ディスク交換時あるいはディスクを抜いたあともアプリケーションが起動し続け、ユーザーが気づかないうちにデータの改変あるいはネットワークへのアクセスを行うかもしれない。

図３８はタイトルより短い単位でアプリケーションを管理する方法を示している。ＡＶストリームが再生されるタイトルの場合、タイトル再生中にいくつかのチャプター（３８０１）が用意されていることがある。チャプターはＡＶストリームの再生時間軸上に順番に並んでいるため、時間軸上の特定の区間でのみ有効なアプリケーションを規定したい場合、タイトル指定とともにさらに時間の限定を加えてチャプターあるいはチャプターの範囲を指定する（３８０２）ことにより、アプリケーションの有効期間をタイトル中の時間軸上の特定期間に限定する（３８０３）ことができる。

なお、さらに細かい単位でアプリケーションを管理したい場合には、タイトル内のストリームの時間軸を利用し、再生開始時点よりＡ秒後からＢ秒後のように時間指定することも可能である。

（アプリケーションマネージャ）
アプリケーション管理情報を利用して、アプリケーションを起動及び終了させる仕組みについて述べる。

図３９はプログラミング環境を用いて再生を制御する部分の大まかなブロック図である。ディスク（３９０１）から読み込まれたプログラムやプログラムから使用するイメージデータは、ローカルメモリ（３９０２）に蓄積される。ローカルメモリは図６のプログラム記憶メモリと同等であるが、プログラムだけではなくイメージデータなども格納される。ローカルメモリ上のプログラム及びデータは、Ｊａｖａ（登録商標）仮想マシン（３９０３）などのプログラム処理部が必要とした時に、プログラム処理部のワークメモリ（３９０４）内に読み込まれる。ワークメモリはプログラムを実行する際にプログラム処理部が利用するメモリであり、Ｊａｖａ（登録商標）仮想マシンではヒープ領域あるいはヒープメモリなどと呼ばれるメモリである。ワークメモリに読み込まれプログラム処理部によりプログラムが実行されるとアプリケーション（３９０５）が起動される。図６におけるプログラム処理部は、Ｊａｖａ（登録商標）仮想マシンとワークメモリが含まれている。アプリケーションの動作によっては、プログラム処理部を介して、ＡＶストリーム再生部（３９０６）に指示を出すことも可能である。

アプリケーション管理情報は、アプリケーションマネージャ（３９０７）によって読み込まれ、アプリケーションマネージャがプログラム処理部を制御することのより、アプリケーションの起動や終了を行う。タイトル遷移時に、アプリケーションマネージャはアプリケーション管理情報を参照し、該当するアプリケーションのプログラムをローカルメモリより読み込んで実行、あるいは必要ないアプリケーションを終了する。

なお、ディスクからローカルメモリにデータが読み込まれる時、あるいは、ローカルメモリからワークメモリにデータが読み込まれるときに、プログラムやイメージデータのサイズをチェック、プログラムのコードにデータ落ちなどが存在しないか、プログラムを動作させるＪａｖａ（登録商標）仮想マシンとバージョンが合っているかなどチェックする機能があってもよい。また、不正なプログラムが動作することを防ぐためプログラムを暗号化してディスクに記録しておき、読み込む際に複合化するなどセキュリティを確保する機能があってもよい。

図４０はアプリケーションマネージャによるアプリケーションの起動及び終了の様子を示している。

タイトル管理情報を参照してタイトル開始時にアプリケーションマネージャがアプリケーションの起動する（４００１）以外に、ユーザー操作により発生するイベントや時間イベントに応じて、アプリケーションマネージャがアプリケーションを起動（４００２）してもよい。また、他のアプリケーションからの制御によりアプリケーションを起動する（４００３）ことも可能である。この場合、アプリケーションが直接他のアプリを起動してもよいし、アプリケーションマネージャに指定のアプリケーションを起動するように問い合わせてもよい。

アプリケーションの終了は、タイトル開始時と同様、タイトル終了時にアプリケーションマネージャが次のタイトルで登録されていないアプリケーションＩＤを持つアプリを終了（４００４）させる、あるいは、ユーザー操作により発生するイベントや時間イベントに応じてアプリケーションを終了（４００５）させてもよい。他のアプリケーションから終了（４００６）してもよい。この場合、直接アプリケーションを終了させてもよいし、アプリケーションマネージャに、指定のアプリケーションを終了するように問い合わせてもよい。

図４１はアプリケーションマネージャによるアプリケーションの終了方法について示している。アプリケーションを終了させる際は、アプリケーションマネージャより終了させたいアプリケーションに対して終了イベントを通知し、アプリケーションのイベント受信部（４１０１）がイベントを受け、アプリケーション内の終了プロセス（４１０２）を実行することによりアプリケーションが自ら終了する。アプリケーションが終了イベント受信部と対応した終了プロセスを持たない（４１０３）ため自ら終了しない、あるいは、終了プロセスが間違っておりアプリケーションが自ら終了しない場合などは、一定時間経過後アプリケーションマネージャがアプリケーションを強制的に終了させる。

この方法はサスペンド時やレジューム時にも応用可能であり、アプリケーションマネージャがアプリケーションを強制的にサスペンドあるいはレジュームする前に、アプリケーション独自のプロセスを処理する仕組みを提供することが可能である。

また、アプリケーションマネージャは、アプリケーション自体に終了やサスペンドの処理を任せるのだけではなく、アプリケーションが終了やサスペンドなどのイベントに正常に反応しなかった場合、強制的に処理することにより、個々のアプリケーションだけではなく全体の動作を管理することが可能となる。この仕組みにより、たとえあるタイトル内でアプリケーションの動作がおかしくなったとしても、タイトルを切り替えることによりアプリケーションマネージャにより登録されていないアプリケーションは終了され、アプリケーションの管理を保証する仕組みを提供することが可能となる。全てのアプリケーションを終了させるために、どのアプリケーションも実行されないタイトルを用意しておくことにより、そのタイトルに遷移することで全てのアプリケーションを停止することも可能である。このようなどのアプリケーションも動作できない、あるいは安全な特別なアプリケーションしか起動できないタイトルは、アプリケーションの動作がおかしくなったときに正常状態に復帰する手段として有効である。映画コンテンツなどの場合は、メニューや再生開始時の注意書きを表示するタイトルなどを利用するとよい。

（実施の形態３）
次に本発明の第３の実施の形態について説明する。

本実施の形態は、ビデオカメラやDiscレコーダー等で撮影、録画した映像を次世代Discに記録するＢＤ−ＲＥの構成に関する。

ＢＤ−ＲＥは基本的に、本発明の第１の実施の形態及び第２の実施の形態で説明したＢＤ−ＲＯＭからインタラクティブを実現するプログラムに関する部分を除いたものであり、図４を用いて説明すると、ＢＤディスク部分やＡＶデータ部分、ＢＤ管理データ部分はほぼ同じであり、ＢＤ再生プログラム部分が存在しない。
（ディスク上の論理データ構造）
図４２は、上述したＢＤディスクにＢＤ−ＲＥによって記録した論理データを示した図である。基本的な構造は第１の実施の形態で説明したＢＤ―ＲＯＭと同様であり、本実施の形態ではＢＤ−ＲＯＭと異なる部分のみを説明する。ＢＤ−ＲＯＭにおけるファイル構成では、ルートディレクトリ直下に、例としてＢＤＶＩＤＥＯディレクトリが置かれその下にＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータが記録されていたが、ＢＤ−ＲＥではＢＤＶＩＤＥＯディレクトリとは異なるディレクトリ、例えばＢＤＲＥＣＯＲＤディレクトリ以下に、撮影したＡＶコンテンツや管理情報などのデータが記録される。

ＢＤＲＥＣＯＲＤディレクトリの下には、次の５種類のファイルが記録されている。
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。

ＢＤ−ＲＯＭにおけるＢＤ．ＩＮＦＯの構造とは異なり、詳しい内容は省略するが記録した映像に関する情報が記録されている。

ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（ＰｌａｙＬｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
図１６を用いて説明したＢＤ−ＲＯＭにプレイリスト情報の内部構造と同様の内部構造を持つ。

ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
図９から図１２までを用いて説明したＢＤ−ＲＯＭにおけるＶＯＢデータと基本的に同様の構造を持つが、ＢＤ−ＲＯＭにおけるＢＤ再生プログラム（ＮＶ＿ＰＣＫ）に関するデータは含まれない。

ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
図１３を用いて説明したＢＤーＲＯＭにおけるＶＯＢ管理情報ファイルと同様の内部構造を持つ。

ＺＺＺ．TNL（「ＺＺＺ」は可変、拡張子「TNL」は固定）
サムネイル画像が記録されたサムネイル情報ファイルであり、記録したVOBに関して先頭画像や、前述したEVENT発生時点の画像がサムネイルとして記録されている。
サムネイル情報ファイルの構造の例を図４３に示す。

図４３に示すようにサムネイル情報ファイルは、ThumbnailInfoListブロックとImageListブロックとに分かれる。YhubnailInfoListは複数のThumbnailInfoから構成され、ThumbnailInfoListに含まれるThumbnailInfoの数を示すNumberとそれぞれのThumbnailInfoからなる。ThumbnailInfoは、当該ThumbnailInfoがどのVOBの何に対するサムネイルに対するものかが記述されたInfoと、後述するImageList中のどのサムネイル画像に関する情報なのかが記述されたImageRefと、ImageRefで参照したサムネイル画像の画像サイズが記述されたDataSize、ImageRefで参照したサムネイル画像の横方向の画素数が記述されたHorizontalSize、ImageRefで参照したサムネイル画像の縦方向の画素数が記述されたVerticalSizeの５つの情報からなる。ImageListはサムネイル画像本体が記録されたものであり、ImageListに含まれるサムネイル画像数が記述されたNumberと、それぞれのサムネイル画像からなる。

なお、本実施の形態におけるサムネイル情報ファイルはあくまでも例であり、ThumnailInfoListとImageListとを別のファイルとしてもよい。また、VOBの先頭画像用のサムネイルとEvent用のサムネイルとを別のファイルとして分けても良い。

（実施の形態４）
次に本発明の第４の実施の形態について説明する。

第４の実施の形態は、ビデオカメラ等で映像を撮影、録画するための映像記録用フォーマットであるＢＤ−ＲＥで記録したDiscを、映画等の商用配布などの映像配布用フォーマットであるＢＤ−ＲＯＭのの再生専用装置に再生可能とする記録方法に関する内容である。基本的には第１の実施の形態と第２の実施の形態と第３の実施の形態とに基づく内容であり、拡張または異なる部分を中心に説明する。

まず、図４４に示すように、ビデオカメラ等で撮影、録画したBD-REで記録した場合のディレクトリ、ファイル構成と、BD-ROMで記録された場合のディレクトリやファイル構成は大きく異なるため、BD-REで記録したDiscをBD-ROMの再生専用装置（以下、BDプレーヤと呼ぶ）で再生することはできない。具体的説明すると、まずBDプレーヤはルートディレクトリ直下にあるBDVIDEOディレクトリのBD.INFOを参照し再生を開始するが、既存のビデオカメラで撮影したBD-REで記録されたDiscではルートディレクトリ直下にBDRECORDディレクトリしか存在しない。このほか、BD.INFOの内容もBD-ROMとBD-REでは異なり、BD-REには再生プログラムであるMOVIE.PROGが存在しない。この他、プレイリスト情報ファイル（＊。PL）、AVデータ（*.VOB）、ＡＶデータ管理情報ファイル（*.VOBI）に関してもBD-ROMとBD-REではほぼ同じデータ構造であるものの、それぞれBDVIDEOとBDRECORDとに格納されている。

以上の様に、BD-REで記録したDiscとBD-ROMで記録したDiscとは異なるため、ビデオカメラ等で撮影したBD-REで記録したDiscをBDプレーヤで再生するには何らかの変換処理が必要になる。

（BD-REからBD-ROMへの変換）
以下、BD-REで記録したDiscをBD-ROM形式に変換する方法について図４５を用いて述べる。

まず、ビデオカメラで撮影した直後のDiscのファイル構成の例を図４５の左に示す。前述した様に、BD-RE形式では、BDRECORDディレクトリ以下に、BD管理情報であるBD.INFOとサムネイル情報ファイルであるZZZ.TNL、そして撮影した映像データであるAVデータYYY.VOBとその管理情報であるYYY.VOBI、そして再生シナリオであるXXX.PLとを持つ。
まず変換処理を開始するにあたり、DiscにBDVIDEOディレクトリを作成する。

次に、BD-REのBD.INFOを元に、BD-ROMのBD.INFOを新規作成する。BD-ROMのBD.INFOはタイトル情報であるTitleListを持つが、タイトルの数はBD-REのBD.INFOに記述されるプレイリストの数とする。このように、１タイトルは１つのプレイリストの再生となり、それに基づいて再生プログラムであるBD-ROMのMOVIE.PROGを新規作成する。次に、BD-ROMの該当ファイルとほぼ同様の構造であるBD-REのXXX.PLとYYY.VOBIを、BDVIDEOディレクトリにコピーする。この際各々のファイルに対してBD-ROM用に修正するべき項目があれば修正しておく。次に、BD-REのBDRECORD以下にあるYYY.VOBをBDVIDEO以下にコピーしても良いが、この場合AVデータであるYYY.VOBのファイルサイズは他のファイルに比べ大きいためコピーに時間が掛かったり、Disc上に同様のファイルが二つ存在することとなりDiscの空き容量が減ってしまう。従って本実施の形態では、YYY.VOBのコピーは行わないものとし、例えば/BDRECORD/STREAM以下にYYY.VOB画存在するならばディレクトリ名を/BDVIDEO/SREAMに変換することで、YYY.VOBのファイルをBDプレーヤから参照可能にする。

以上により、BD-RE形式で記録したDiscをBDプレーヤにて再生可能となるが、さらにBD-ROMのナビパック（NV_PCK）によるボタンや、前述したJAVA(登録商標）プログラムを用いて、撮影したAVデータのプレイリストを一覧表示して、選択の後再生させる再生メニューを付加しても良い。

図４６に再生メニューの例を示す。
図４６に示した再生メニュー４６００は、画面に最大６つのプレイリストを横に３つ、縦に２つ表示させた例である。メニューのタイトル４６０１は例えば、BD-REのBD.INFOに含まれるDisc名を表示しても良い。

また、再生メニュー４６００は、それぞれのプレイリストA〜Fのサムネイル画像４６０２を表示し、それをリモコンの十字キーで選択し、押下することで当該プレイリストを再生させるが、当該Discに幾つのプレイリストが存在し、それがどのプレイリストファイルにあたるのかはBD-REのBD.INFOを参照すれば判別可能である。また、表示する各プレイリストのサムネイル画像は、BDRECORDディレクトリ以下にあるサムネイル情報ファイルZZZ.TNLを参照すれば良い。また、各プレイリストのプレイリスト名や撮影日時などのプレイリスト付属情報４６０３も表示可能であり、これらの情報はBD.INFOや当該プレイリスト情報ファイルに格納されている。

このような再生メニューをナビパック（NV_PCK）によるボタンで実現する場合は、再生メニュー用のストリームを新規作成して図４５に示すように例えばZZZ.VOBとして配置し、ZZZ.VOB用のストリーム管理情報ファイルZZZ.VOBIと、ZZZ.VOBを再生させるプレイリストファイルZZZ.PLを新規作成した上で、ディスク挿入時にZZZ.PLを再生させるようBD-ROMのBD.INFOタイトル定義を設定する。また、各プレイリストのサムネイルはボタンとして実現され、当該ボタン選択、押下された場合は当該プレイリストに対応するタイトルを再生するように設定される。

また、再生メニューをJAVA(登録商標）プログラムで実現する場合は、前述の再生メニューに相当するJAVA(登録商標）プログラムを、BD-REのBD.INFO、ZZZ.TNL、YYY.PLを元に作成し、当該JAVA(登録商標）プログラムをディスク挿入時に実行させるようBD-ROMのBD.INFOタイトル定義を設定する。

以上、BD-REで記録したDiscをBDプレーヤで再生可能とするようにBD-ROMに変換する変換処理について説明したが、例えば、AVデータであるYYY.VOBをコピーする場合は前述のように変換に時間が掛かったり、Disc容量を圧迫したりする問題がある。また、前述したようにVOBの保存位置を変更する場合でも、変換後BD-ROMとしてBDプレーヤで再生可能となるが、BD-RE Discとして当該AVデータを例えばビデオカメラなどで再生することができなくなるという問題がある。

（BD-ROMストリーム参照）
この問題点を解決するため、本実施の形態ではさらにBD-REのAVデータ管理情報を拡張する方式について図４７を用いて説明する。

前述したようにBD-REでは撮影、録画したAVデータをBDRECORDディレクトリ以下に例えばYYY.VOBとして記録するが、本方式ではBD-ROM形式として直接参照可能なようにBDVIDEOディレクトリ以下に直接記録する（図４７左）。既存のBD-REのAVデータ管理情報YYY.VOBIは、AVデータがBDRECORD以下にあるものとして定義されているが、本方式ではAVデータがBDVIDEOディレクトリに記録されることにあわせてBD-REのAVデータ管理情報を拡張し、BDVIDEOディレクトリに記録されたAVデータを参照可能にする。この方法としては例えばAVデータが従来通りBDRECORDディレクトリ以下に存在するのかそれともBDVIDEOディレクトリ以下に存在するのかを切り分けるフラグをAVデータ管理情報に設ける拡張方法でも良いし、従来AVデータの指定方法がファイル名だけだったのを拡張し、フルパスでも指定可能なように拡張する方法でもよい（この場合、例えば”/BDVIDEO/YYY.VOB”という指定方法になる）。なお、本実施の形態ではAVデータ管理情報を拡張する方法を挙げているが、例えばAVデータに加え、AVデータ管理情報もBDVIDEOデータ以下に記録し、BD-REのプレイリスト情報ファイルを拡張してBDVIDEOディレクトリ以下のAVデータ管理情報を参照する方法でも良い。

上記の処理以外は「BD-REからBD-ROMへの変換」で前述した処理と同様であり、BD-REのBD.INFOを元に、BD-ROMのBD.INFOとBD-ROMのMOVIE.PROGを新規作成する。次に、ほぼ同様の構造であるBD-REのXXX.PLとYYY.VOBIを、BDVIDEOディレクトリにコピーする。

また、BD-REのBD管理情報であるBD.INFOとプレイリスト情報ファイルXXX.PL、サムネイル情報ファイルZZZ.TNLを元に再生メニューを前述したように作成してBDVIDEOディレクトリに配置し、ディスク挿入時に提示されるようBD-ROMのBD.INFOを設定しても良い。

以上の拡張により、前述した「BD-REからBD-ROMへの変換」において発生していたAVデータのコピーやAVデータのディレクトリ移動などが必要なく、Discに１つだけ存在するAVデータをBD-ROMとしてもBD-REとしても参照、再生可能となる。

また、本方式ではビデオカメラ等で撮影、録画する度（または同時に）に、BD.INFOやMOVIE.PROGの新規作成、XXX.PLとYYY.VOBIのコピー、再生メニューの作成、設定を行っても良い。このように撮影、録画の度に上記処理を行うことで、ユーザが変換処理を意識せずとも、常にビデオカメラなどのBD-RE再生記録装置や、BDプレーヤなどのBD-ROM再生装置の双方で本方式で記録された影像を再生することができる。
（BD-REストリーム参照）
前記「BD-ROMストリーム参照」では、ビデオカメラ等で撮影、録画したAVデータをBDVIDEOディレクトリに直接記録し、BD-REのAVデータ管理情報から参照する方法について述べたが、本方式ではそれとは反対に撮影、録画したAVデータは既存のBD-RE形式通りにBDRECORDディレクトリ以下に記録し、BD-ROMからBDRECORDディレクトリ以下に記録されたAVデータを参照する方式について図４８を用いて述べる。

図４８の左側に図示するように、ビデオカメラ等で影像を撮影、録画した時点では、BD-RE形式どおりに、BDRECORDディレクトリ以下に、BD.INFO、ZZZ.TNL、XXX.PL、YYY.VOBI、YYY.VOBが記録される。

次にBDプレーヤなどのBD-ROM再生装置による再生用に、「BD-REからBD-ROMへの変換」及び「BD-ROMストリーム参照」で前述した処理と同様に、BD-REのBD.INFOを元に、BD-ROMのBD.INFOとBD-ROMのMOVIE.PROGを新規作成する。次に、ほぼ同様の構造であるBD-REのXXX.PLとYYY.VOBIを、BDVIDEOディレクトリにコピーする。また、BD-REのBD管理情報であるBD.INFOとプレイリスト情報ファイルXXX.PL、サムネイル情報ファイルZZZ.TNLを元に再生メニューを前述したように作成してBDVIDEOディレクトリに配置し、ディスク挿入時に提示されるようBD-ROMのBD.INFOを設定する。

上記の処理に加え、BDRECORDディレクトリ以下に記録されたAVデータを参照するために、本方式では例えば、BD-ROMのAVデータ管理情報を拡張し、BDRECORDディレクトリに記録されたAVデータを参照可能にする。この方法としては例えばAVデータが従来通りBDVIDEOディレクトリ以下に存在するのかそれともBDRECORDディレクトリ以下に存在するのかを切り分けるフラグをAVデータ管理情報に設ける拡張方法でも良いし、従来AVデータの指定方法がファイル名だけだったのを拡張し、フルパスでも指定可能なように拡張する方法でもよい（この場合、例えば”/BDRECORD/YYY.VOB”という指定方法になる）。

そのほかの方法としては、例えばAVデータに加え、AVデータ管理情報もBD-REのAVデータ管理情報を参照するものとし、BD-ROMのプレイリスト情報ファイルを拡張してBDRECORDディレクトリ以下のAVデータ管理情報を参照させる方法でも良い。

また、再生メニューをJAVA(登録商標）プログラムで生成し、BDRECORDディレクトリ以下に記録されたプレイリスト情報ファイルをサムネイルとして提示させ、JAVA(登録商標）プログラムから選択されたBDRECORDディレクトリ以下のプレイリスト並びにAVデータを再生させる方法でも良い。

そのほかにも、BDVIDEOディレクトリ以下にBDRECORDのAVデータに対するリンクファイルを生成し、BDRECORDディレクトリに配置されたAVデータがあたかもBDVIDEOディレクトリ以下に存在するように見せかける方法でも良い。

また、BF-ROMとして再生する際に、BDRECORDディレクトリ上のAVデータをあたかもBDVIDEOディレクトリ上に存在するように見せかけるファイルマウントシステムを用いることで、BDプレーヤにBDRECORDディレクトリ上のAVデータを再生させても良い。なおこの際、BD-ROMの再生プログラム開始時にBDRECORDディレクトリ上のAVデータをマウントする必要があるか否かを判断し、必要があればBDRECORDディレクトリ上のAVデータをマウントする。

以上、本発明に基づく、第一から第四の実施の形態について説明したが、本発明は、ＢＤ−ＲＥとＢＤ−ＲＯＭの双方の互換性を保つ形で記録される情報記録媒体と、それを記録する記録装置、記録方法、記録プログラムに適用される。

本発明によれば、商用配布用のフォーマットとも互換性を持つ形で映像記録用のフォーマットを次世代記録媒体に記録可能であり、特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用される可能性をもつ。

ＤＶＤの構成図である。ハイライトの構成図である。ＤＶＤでの多重化の例を示す図である。ＢＤ−ＲＯＭのデータ階層図である。ＢＤ−ＲＯＭ上の論理空間の構成図である。ＢＤ−ＲＯＭプレーヤの概要ブロック図である。ＢＤ−ＲＯＭプレーヤの構成ブロック図である。ＢＤ−ＲＯＭのアプリケーション空間の説明図である。ＭＰＥＧストリーム（ＶＯＢ）の構成図である。パックの構成図である。ＡＶストリームとプレーヤ構成の関係を説明する図である。トラックバッファへのＡＶデータ連続供給モデル図である。ＶＯＢ情報ファイル構成図である。タイムマップの説明図である。タイムマップを使ったアドレス情報取得方法説明図である。プレイリストファイルの構成図である。プレイリストに対応するプログラムファイルの構成図である。ＢＤディスク全体管理情報ファイルの構成図である。グローバルイベントハンドラを記録するファイルの構成図である。タイムイベントの例を説明する図である。ユーザイベントの例を説明する図である。グローバルイベントハンドラの例を説明する図である。仮想マシンの構成図である。プレーヤ変数テーブルの図である。イベントハンドラ（タイムイベント）の例を示す図である。イベントハンドラ（ユーザイベント）の例を示す図である。プレーヤの基本処理のフローチャートである。プレイリスト再生処理のフローチャートである。イベント処理のフローチャートである。字幕処理のフローチャートである。プログラム実行環境を鑑みたプレーヤの概要ブロック図である。アプリケーション管理単位の説明図である。アプリケーション管理情報の説明図である。起動状態情報を備えたアプリケーション管理情報の説明図である。起動状態情報に休止状態を備えたアプリケーション管理情報の説明図である。起動属性によるタイトル間状態遷移の説明図である。階層的なアプリケーション管理単位の説明図である。チャプター単位の管理単位を備えたアプリケーション管理情報の説明図である。データ及びアプリケーションの管理に関わるプレーヤの概要ブロック図である。アプリケーションの起動及び終了の説明図である。イベントを利用したアプリケーション終了方法の説明図である。ＢＤ−ＲＥ上の論理空間の構成図である。サムネイル情報ファイルの構成図である。ＢＤ−ＲＯＭの論理空間とＢＤ−ＲＥの論理空間との差異を示した図である。ＢＤ−ＲＥからＢＤ−ＲＯＭへの変換方法を示した図である。再生メニューの例を示した図である。ＢＤ−ＲＯＭ上のストリームをＢＤ−ＲＥから参照する方法を示した図である。ＢＤ−ＲＥ上のストリームをＢＤ−ＲＯＭから参照する方法を示した図である。

符号の説明

２０１ＢＤディスク
２０２光ピックアップ
２０３プログラム記録メモリ
２０４管理情報記録メモリ
２０５ＡＶ記録メモリ
２０６プログラム処理部
２０７管理情報処理部
２０８プレゼンテーション処理部
２０９イメージプレーン
２１０ビデオプレーン
２１１合成処理部
３０１プログラム記録メモリ
３０２プログラムプロセッサ
３０３ＵＯＰマネージャ
３０４管理情報記録メモリ
３０５シナリオプロセッサ
３０６プレゼンテーションコントローラ
３０７クロック
３０８イメージメモリ
３０９トラックバッファ
３１０デマルチプレクサ
３１１イメージプロセッサ
３１２ビデオプロセッサ
３１３サウンドプロセッサ
３１４イメージプレーン
３１５ビデオプレーン
３１６合成処理部
３１７ドライブコントローラ
３１０１プログラム
３１０２プログラム処理部
３１０３プログラム処理部から管理情報処理部の制御
３１０４イメージプレーン
３１０５プログラム処理部からイメージプレーンの制御
３２０１タイトルリスト
３２０２本編映像データを再生するアプリケーション
３２０３ポップアップメニューを表示するアプリケーション
３２０４オンラインショッピング購入品を蓄えておくアプリケーション
３２０５オンラインショッピングを実現するアプリケーション
３２０６ゲームアプリケーション
３３０１アプリケーション管理情報
３３０２タイトル番号
３３０３アプリケーションＩＤ
３３０４アプリケーション＃１の起動
３３０５アプリケーション＃１の終了
３３０６アプリケーション＃３の起動
３４０１起動属性
３４０２アプリケーション＃１によるアプリケーション＃２の起動
３４０３タイトル終端におけるアプリケーションの終了
３４０４アプリケーション＃２によるアプリケーション＃１の終了
３５０１タイトル＃１におけるアプリケーション＃１の登録情報
３５０２タイトル＃２におけるアプリケーション＃１の登録情報
３７０１タイトル単位のアプリケーション管理情報
３７０２ディスク単位のアプリケーション管理情報
３７０３ディスクセット単位のアプリケーション管理情報
３８０１チャプター
３８０２チャプター単位で管理されたアプリケーション管理情報
３８０３チャプター単位で管理されたアプリケーション
３９０１ディスク
３９０２ローカルメモリ
３９０３Ｊａｖａ（登録商標）仮想マシン
３９０４ワークメモリ
３９０５Ｊａｖａ（登録商標）アプリケーション
３９０６再生制御部
３９０７アプリケーションマネージャ
４００１アプリケーションマネージャによるタイトル開始時の起動
４００２アプリケーションマネージャによるイベント発生時の起動
４００３アプリケーションによる起動
４００４アプリケーションマネージャによるタイトル終了時の終了
４００５アプリケーションマネージャによるイベント発生時の終了
４００６アプリケーションによる終了
４１０１終了イベント受信部
４１０２終了プロセス
４１０３終了イベント及び終了プロセスを持たないアプリケーション
Ｓ１０１ディスク挿入ステップ
Ｓ１０２ＢＤ．ＩＮＦＯ読み込みステップ
Ｓ１０３ＢＤ．ＰＲＯＧ読み込みステップ
Ｓ１０４ファーストイベント生成ステップ
Ｓ１０５イベントハンドラ実行ステップ
Ｓ２０１ＵＯＰ受付ステップ
Ｓ２０２ＵＯＰイベント生成ステップ
Ｓ２０３メニューコール判定ステップ
Ｓ２０４イベント生成ステップ
Ｓ２０５イベントハンドラ実行ステップ
Ｓ３０１プレイリスト再生開始ステップ
Ｓ３０２プレイリスト情報（ＸＸＸ．ＰＬ）読み込みステップ
Ｓ３０３プレイリストプログラム（ＸＸＸ．ＰＲＯＧ）
読み込みステップ
Ｓ３０４セル再生開始ステップ
Ｓ３０５ＡＶ再生開始ステップ
Ｓ４０１ＡＶ再生開始ステップ
Ｓ４０２ＶＯＢ情報（ＹＹＹ．ＶＯＢＩ）読み込みステップ
Ｓ４０３ＶＯＢ（ＹＹＹ．ＶＯＢ）読み込みステップ
Ｓ４０４ＶＯＢ再生開始ステップ
Ｓ４０５ＶＯＢ再生終了ステップ
Ｓ４０６次セル存在判定ステップ
Ｓ５０１プレイリスト再生開始ステップ
Ｓ５０２プレイリスト再生終了判定ステップ
Ｓ５０３タイムイベント時刻判定ステップ
Ｓ５０４イベント生成ステップ
Ｓ５０５イベントハンドラ実行ステップ
Ｓ６０１プレイリスト再生開始ステップ
Ｓ６０２プレイリスト再生終了判定ステップ
Ｓ６０３ＵＯＰ受付判定ステップ
Ｓ６０４ＵＯＰイベント生成ステップ
Ｓ６０５メニューコール判定ステップ
Ｓ６０６ユーザーイベント有効期間判定ステップ
Ｓ６０７イベント生成ステップ
Ｓ６０８イベントハンドラ実行ステップ
Ｓ７０１プレイリスト再生開始ステップ
Ｓ７０２プレイリスト再生終了判定ステップ
Ｓ７０３字幕描画開始判定ステップ
Ｓ７０４字幕描画ステップ
Ｓ７０５字幕表示終了判定ステップ
Ｓ７０６字幕消去ステップ
４６００再生メニュー
４６０１メニューのタイトル
４６０２サムネイル画像
４６０３プレイリスト付属情報
４６０４メニューページ戻し
４６０５メニューページ送り

Claims

映像記録用のデータ形式としても映像配布用のデータ形式としても認識可能な形式で記録された情報記録媒体であって、
双方のデータ形式から参照可能な状態で映像データが記録される
ことを特徴とする情報記録媒体。
映像を前記映像記録用のデータ形式として前記情報記録媒体に記録した後に、
前記映像記録用のデータ形式で記録された情報を元に前記のデータ形式のデータが生成され記録される
ことを特徴とする請求項１記載の情報記録媒体。
前記映像記録用のデータ形式による映像の記録と同時に、
前記映像記録用データ形式で記録された情報から映像配布用のデータ形式のデータが生成され記録される
ことを特徴とする請求項１記載の情報記録媒体。
前記映像記録用データ形式で記録された情報から映像配布用のデータ形式のデータが生成され記録される際に、
前記映像記録用データ形式で記録される映像のサムネイル画像を元に前記映像配布用のデータ形式用の再生メニューも生成され記録される
ことを特徴とする請求項１記載の情報記録媒体。
前記映像データは映像配布用のデータ形式として記録され、
前記映像記録用のデータ形式から参照される
ことを特徴とする請求項１記載の情報記録媒体。
前記映像データは映像記録用のデータ形式として記録され、
前記映像配布用のデータ形式から参照される
ことを特徴とする請求項１記載の情報記録媒体。
情報記録媒体に映像を記録する映像記録装置であって、
映像を映像ストリームに変換するストリーム変換部と、
前記映像ストリームを映像記録データ形式として情報記録媒体に記録する映像記録部と、
映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録部と
前記映像記録データ形式の制御データを元に前記映像ストリームを参照する映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録部
とを備えることを特徴とする映像記録装置。
情報記録媒体に映像を記録する映像記録装置であって、
映像を映像ストリームに変換するストリーム変換部と、
前記映像ストリームを映像配布データ形式として情報記録媒体に記録する映像記録部と、
前記映像ストリームを参照する映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録部と
前記映像記録データ形式の制御データを元に映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録部
とを備えることを特徴とする映像記録装置。
前記第二制御データ記録部は、前記第一制御データ記録部にて記録される映像のサムネイル画像を元に再生メニューを生成し記録する再生メニュー記録部
を内部に備えることを特徴とする請求項７または８記載の映像記録装置。
情報記録媒体に映像を記録する映像記録方法であって、
映像を映像ストリームに変換するストリーム変換ステップと、
前記映像ストリームを映像記録データ形式として情報記録媒体に記録する映像記録ステップと、
映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録ステップと
前記映像記録データ形式の制御データを元に前記映像ストリームを参照する映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録ステップ
とを含むことを特徴とする映像記録方法。
情報記録媒体に映像を記録する映像記録方法であって、
映像を映像ストリームに変換するストリーム変換ステップと、
前記映像ストリームを映像配布データ形式として情報記録媒体に記録する映像記録ステップと、
前記映像ストリームを参照する映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録ステップと
前記映像記録データ形式の制御データを元に映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録ステップ
とを含むことを特徴とする映像記録方法。
前記第二制御データ記録ステップは、前記第一制御データ記録ステップにて記録される映像のサムネイル画像を元に再生メニューを生成し記録する再生メニュー記録ステップ
を内部に含むことを特徴とする請求項１０または１１記載の映像記録方法。
情報記録媒体に映像を記録する映像記録プログラムであって、
映像を映像ストリームに変換するストリーム変換ステップと、
前記映像ストリームを映像記録データ形式として情報記録媒体に記録する映像記録ステップと、
映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録ステップと
前記映像記録データ形式の制御データを元に前記映像ストリームを参照する映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録ステップ
とをコンピュータに実行させることを特徴とする映像記録プログラム。
情報記録媒体に映像を記録する映像記録プログラムであって、
映像を映像ストリームに変換するストリーム変換ステップと、
前記映像ストリームを映像配布データ形式として情報記録媒体に記録する映像記録ステップと、
前記映像ストリームを参照する映像記録データ形式の制御データを生成し情報記録媒体に記録する第一制御データ記録ステップと
前記映像記録データ形式の制御データを元に映像配布データ形式の制御データを生成し情報記録媒体に記録する第二制御データ記録ステップ
とをコンピュータに実行させることを特徴とする映像記録プログラム。
前記第二制御データ記録ステップは、前記第一制御データ記録ステップにて記録される映像のサムネイル画像を元に再生メニューを生成し記録する再生メニュー記録ステップ
を内部的にコンピュータに実行させることを特徴とする請求項１３または１４記載の映像記録プログラム。