JPWO2006059661A1

JPWO2006059661A1 - 再生装置、画像合成方法、画像合成プログラム及び集積回路

Info

Publication number: JPWO2006059661A1
Application number: JP2006547988A
Authority: JP
Inventors: 敏史橋本; 大蘆　雅弘; 雅弘大蘆; 岡田　智之; 智之岡田; 航池田
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2004-12-01
Filing date: 2005-11-30
Publication date: 2008-06-05
Anticipated expiration: 2025-11-30
Also published as: CN101600122A; US20080089660A1; CN100514441C; JP4949853B2; CN101600122B; KR101193397B1; US8306386B2; EP1818907A4; EP1818907A1; CN101069229A; KR20070090906A; WO2006059661A1

Abstract

記録媒体に記録されているアプリケーションを実行しながら、当該記録媒体に記録されている動画を再生する再生装置において、アプリケーションに関連する画像と動画像を合成する際のメモリバスの利用効率を高めることを目的とする。アプリケーションによって使用される動画やメニューなどのＧＵＩのグラフィックの背景に用いる背景画像を合成するかどうかを動画像が背景画像全体を覆うかどうかの判断によって決定する。動画像が背景画像を覆う場合に背景画像を合成する必要がなくなるので、背景画像を読み出すために用いるメモリバスを、記録媒体から読み出された動画データをメモリへに書き込む事などに用いることができ、メモリバスバンド幅を有効活用できる。

Description

本発明は、動画を再生しながらアプリケーションを実行する再生装置に関し、画像を合成する際におけるメモリバスの活用方法に関する発明である。

近年ＤＶＤ（ＤｉｇｉｔａｌＶｅｒｓａｔｉｌｅＤｉｓｃ）プレーヤ、ＢＤ（Ｂｌｕ−ｒａｙＤｉｓｃ）プレーヤなどの映像再生装置が開発されている。これらのプレーヤでは、ＤＶＤ、ＢＤなどの記録媒体から動画ストリームデータを読み出して動画を再生することができる。このとき動画を再生しながら、記録媒体に記録されているアプリケーションを実行することもあり、動画とは別にアプリケーションに関連する画像も表示することがある。例えば、動画の横位置に動画に係るメニューＧＵＩ（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ）などの表示、あるいは字幕の表示などがこれにあたる。

このとき、プレーヤは動画と、アプリケーションにより表示制御される画像とを合成して表示すべき画像データを生成してディスプレイに表示させている。この合成される基となるデータは逐次、記録媒体から読み出され、一旦プレーヤのメモリのそれぞれ対応する領域に書き込まれる。そしてプレーヤは、そのメモリから画像データを読み出し、合成して出力するということを行っている。ここで、プレーヤのメモリのそれぞれに対応する領域とは、メモリにおいて、動画の画像データを格納するビデオプレーン、動画と共に表示するＧＵＩメニューの画像データを格納するＩＧ（ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓ）プレーンなどのことである。プレーヤは画像を合成する際には各プレーンにアクセスする必要がある。

プレーヤにおいては合成画像を生成する際に高速で各プレーンにアクセスする必要があり、遅延することなく動画を再生するためには当該アクセスにおけるメモリバスの有効活用は重要な課題となる。
メモリへの書き込みに係る技術が特許文献１に記載されており、この技術によれば、あるＧＵＩオブジェクトにおいて再描画が発生した場合に、修復する必要がある領域を決定するチェック手段、及び、再描画する必要があるオブジェクトを決定する生成手段とによって、メモリへの不必要な書き込みを抑制するので、書き込みが抑制された分だけメモリバスバンド幅を有効に活用することができる。
日本国特許公開２００４−１０２３４３号公報

ところで上述したようにプレーヤはプレーンへの書き込みと読み出しを行っているが、メモリへの書き込みと読み出しに用いるメモリバスは、コストや設置スペースの問題から共有化されている。例えばＨＤ画質（１９２０×１０８０ピクセル）の画像を表示しようとする場合において、動画像の書き込みにおいて用いるメモリバスバンド幅は、２Ｂ／ピクセル、３０ｆｐｓとすると約１２０ＭＢ／ｓｅｃ（１９２０×１０８０×２×３０）、読み出しの場合にも同様に約１２０ＭＢ／ｓｅｃの性能を要求されることになる。また、背景画像の書き込みや読み出しについては夫々約１２０ＭＢ／ｓｅｃ、ＧＵＩなどのメニューなどのグラフィックスの書き込みや読み出しについては、４Ｂ／ピクセル、３０ｆｐｓとすると夫々約２４０ＭＢ／ｓｅｃ（１９２０×１０８０×４×３０）のメモリバスバンド幅を要求される。また、字幕がある場合には、このデータもメモリに書き込んで読み出す必要があり、やはり夫々約１２０ＭＢ／ｓｅｃのメモリバス幅を要求される。動画再生時には、読み出しと書き込みが平行して行われるので、これらのプレーンの画像データを合成するために２ＧＢ／ｓｅｃ近くの帯域が必要となってくる。これからも画質の高品質化によって更なるメモリバスバンド幅が必要となることが見込まれているが、同時にこれはプレーヤの低価格化を妨げる一要因にもなっている。

そこで本発明においては、画像データの読み出しに用いられるメモリバスバンド幅の有効活用を図るために資することができる新たな再生装置を提供することを目的とする。

上記課題を解決するため、本発明に係る再生装置は、動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段と、前記ビデオプレーンに動画像を格納する動画像格納手段と、前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納手段と、前記スチルプレーンに前記背景画像を格納する背景画像格納手段と、前記動画像が前記背景画像を遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力手段とを備えることを特徴としている。

上記の構成を備えた再生装置は、背景画像を必要としないとき、即ち、動画像が背景画像を覆ってしまうときには背景画像を合成する必要がないためメモリから読み出す必要がなくなるので、そのときには背景画像のデータは読み出さないようにする。動画像が背景画像を覆う所定のサイズ例えばフルスクリーンサイズで表示されるときには、背景画像を読み出さないようにすることで再生装置の負担は軽くなり、また読み出しに用いるメモリバスバンド幅があくことになる。

こうして、必要のない背景画像の読み出しを制限することで、背景画像の読み出しに用いていたメモリバスを他の目的、例えばＧＵＩ画像のメモリへの書き込みなどに用いることができるので、メモリバスバンド幅を有効活用でき、ディスプレイへの表示の遅延といった問題も軽減できるようになる。
通常、合成するプレーンは同サイズのプレーンを重畳して合成するが、動画像は元のフルスクリーンサイズからサイズを変更して表示する場合、即ち背景画像を覆い隠さない場合もあり、このときには背景画像は必要になるので合成する。

上述したようなＨＤ画質の場合において、再生装置が背景画像の読み出しに用いる１２０ＭＢ／ｓｅｃ分のメモリバスバンド幅を、例えば動画の書き込みに用いれば動画の書き込みの速度が倍になると言え、読み出し時に動画のデータが書き込まれておらず読出しができなかったために動画の再生が遅延するといった事態を防げる。
また、前記所定のサイズとは前記動画像が表示画面においてフルスクリーンで表示されるサイズのことであり、前記再生装置は更に、前記動画像に係るアプリケーションを実行する仮想マシン部を備え、前記合成出力手段は、前記アプリケーションの前記ビデオプレーンに対する縮小指示を受けて、前記背景画像を合成し、縮小指示がない場合には、前記背景画像を合成しないこととしてよい。

ここでフルスクリーンとは、再生装置に接続されている外部機器のテレビなどに代表される表示装置、若しくは内蔵されているモニターなどにおいて、その表示画面全体を覆うサイズのことである。
再生装置は、実行しているアプリケーションの指示に基づき動画像のサイズ変更を行っており、当該変更指示は通常ビデオプレーンに対してのみなされるが、この指示を受けて合成出力手段は、スチルプレーンからのデータの読み出しを実行するかどうかを判断する。この構成を備えることでスチルプレーンからのデータの出力の必要性の判断を容易に行うことができる。

また、前記スチルプレーンは、更に、前記動画像とは異なる時間に応じて切り替わる画像を格納するためのものであって、前記再生装置は更に、前記スチルプレーンに前記時間に応じて切り替わる画像を格納する画像格納手段を備え、前記合成出力手段は、前記動画像が表示画面においてフルスクリーンで表示されるサイズである場合に、前記ビデオプレーンに格納された動画像と前記イメージプレーンに格納されたＧＵＩ画像と前記スチルプレーンに格納された時間に応じて切り替わる画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像がフルスクリーンで表示されるサイズでない場合に、前記ビデオプレーンに格納された動画像と前記イメージプレーンに格納されたＧＵＩ画像と前記スチルプレーンに格納された背景画像とを読み出し、重畳し合成した合成画像を表す画像信号を出力することとしてよい。

ここで、時間に応じて切り替わる画像とは、動画像格納手段で格納する動画とは異なる画像であって、かつ時間に応じて表示内容が異なるものであり、例えば字幕を表示するための画像などのことをいう。
これにより、記憶手段において、従来通常スチルプレーンと字幕を格納するための字幕プレーンとに別々に用意されたメモリ領域が共用されることによってプレーン一つ分のメモリ領域が空くことになり、空いたメモリ領域は他のデータの記憶に割り当てることができるようになるので、メモリを有効に活用できる。また、従来のようにスチルプレーンと字幕プレーンがある場合に比べてプレーン一つ分減少しており、当然にプレーン一つ減少した分だけアクセスするメモリバスバンド幅も少なくてすむ。

また、前記合成出力手段及び前記各格納手段は、前記記憶手段に接続されているメモリバスを共有しており、前記イメージ格納手段は、前記合成出力手段がスチルプレーンの読み出しを行わないと判断した場合に、スチルプレーンの読み出しに割り当てられている前記メモリバスの帯域又は時間を、イメージプレーンへの書き込みに用いることとしてよい。

これにより、再生装置は、背景画像の読み出しにあてられていたメモリバスバンド幅をイメージプレーンへの書き込みに用い、有効にメモリバスバンド幅を利用できると言える。イメージプレーンへの書き込みに関しては、ＧＵＩ画像は動画像や背景画像と比して高品質であるため、その書き込みに要する時間が長くなったり、メモリバスバンド幅が広くなったりするが、スチルプレーンからのデータの読み出しに用いる予定であったメモリバスをイメージプレーンへの書き込みに用いることで高速化することができる。

また、動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段を備える再生装置における、画像を合成する画像合成方法であって、前記ビデオプレーンに動画像を格納する動画像格納ステップと、前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納ステップと、前記スチルプレーンに前記背景画像を格納する背景画像格納ステップと、前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力ステップとを含むこととしてよい。

この方法を実行することで、再生装置は、必要でない場合にスチルプレーンからのデータの読み出しを行わないのでメモリバスバンド幅をその分だけ開けることができる。
また、動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段を備える再生装置のコンピュータに画像を合成させるための処理手順を示した画像合成プログラムであって、前記ビデオプレーンに動画像を格納する動画像格納ステップと、前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納ステップと、前記スチルプレーンに前記背景画像を格納する背景画像格納ステップと、前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力ステップとを含むこととしてよい。

このプログラムを再生装置のコンピュータが実行することで、再生装置は、必要でない場合にスチルプレーンからのデータの読み出しを行わなくなるのでメモリバスバンド幅をその分だけ開けることができる。
また、画像を合成して出力する再生装置に搭載される集積回路であって、動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段と、前記ビデオプレーンに動画像を格納する動画像格納手段と、前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納手段と、前記スチルプレーンに前記背景画像を格納する背景画像格納手段と、前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力手段とを備えることとしてよい。

この集積回路を搭載することで再生装置は、必要でない場合にスチルプレーンからのデータの読み出しを行わないのでメモリバスバンド幅をその分だけ開けることができる。

本発明に係る再生装置の使用行為を示す図である。実施の形態１に係る再生装置１００の機能構成を示したブロック図である。ソフトウェアとハードウェアとからなる部分をレイア構成に置き換えて描いた図である。Ｊａｖａ（登録商標）仮想マシン３６の機能構成を示した図である。ＢＤ−ＲＯＭ１１０に格納されているデータのディレクトリ構造を示した図である。拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示した図である。Ｃｌｉｐ情報の構成を示した図である。映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。Ｐｌａｙｌｉｓｔ情報のデータ構造を示した図である。ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。Ｐｌａｙｌｉｓｔ情報に含まれるＳＴＮテーブルを示した図である。（ａ）〜（ｄ）は、ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細を示す図である。ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報の内部構成を示す図である。ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報によるチャプター位置の指定を示す図である。ＢＤ−ＪＯｂｊｅｃｔの内部構成を示す図である。アーカイブファイルにより収められているプログラム、データを示す図である。（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。ディスクコンテンツにおける状態遷移を示す図である。（ａ）は、ＢＤ−ＲＯＭ全体の時間軸を示す図である。（ｂ）は、ＢＤ−ＲＯＭ全体の時間軸における構成を示す図である。（ａ）（ｂ）ＢＤ−ＲＯＭ全体の時間軸において、ＢＤ−ＪＯｂｊｅｃｔから特定されるタイトル再生区間を示す図である。図２０（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。カレントタイトルがとり得る三態様（プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つ無指定、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ）と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。（ａ）は、プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。（ｂ）は、図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。（ｂ）は、図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。スチルプレーンを合成するかどうかを判断する再生装置１００の動作を示すフローチャートである。実施の形態２における再生装置１００の機能構成を示したブロック図である。実施の形態２においてアプリケーションの指示にビデオスケーリングの指示に基づいてＳｔｉｌｌプレーン並びにＰＧプレーンからのデータの出力制御の流れを示したフローチャートである。

符号の説明

１ＢＤ−ＲＯＭドライブ
２リードバッファ
３デマルチプレクサ
４ビデオデコーダ
５ビデオプレーン
６サウンドプロセッサ
７サウンドプロセッサ
８ミキサー
９サウンドコントローラ
１０Ｄ／Ａコンバータ
１１ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓデコーダ
１２ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓプレーン
１３ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓデコーダ
１４ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓプレーン
１５ＪＰＥＧデコーダ
１６Ｓｔｉｌｌプレーン
１７Ｓｔｉｌｌプレーン制御部
１８ａ、１８ｂ、１８ｃ合成部
１９ＳＴＣ−ＤＥＬＴＡ付加部
２０ＡＴＣ−ＤＥＬＴＡ付加部
２１ローカルストレージ
２２命令ＲＯＭ
２３ユーザイベント処理部
２４ＰＳＲセット
２５ＣＰＵ
２６シナリオメモリ
２７ローカルメモリ
２８ＰＧプレーン制御部
１００再生装置

＜実施の形態１＞
以下、本発明の一実施形態である再生装置について図面を用いて説明する。
＜構成＞
＜使用形態の構成＞
まず、図１には再生装置の使用行為についての形態を示した。

図１に示すように、再生装置１００は、ＢＤ−ＲＯＭ１１０を装着してＢＤ−ＲＯＭ１１０に記録されている動画を再生して、有線若しくは無線で接続しているテレビ１３０に表示させる。また、再生装置１００は、ＢＤ−ＲＯＭ１１０に記録されているＪａｖａ（登録商標）アプリケーションを実行し、当該アプリケーションに基づく画像も表示させる。
ユーザ操作を受けるためにリモコン１２０があり、当該リモコン１３０には、再生装置１００を制御するための各種キーが搭載されている。この各種キーには、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（ＰａｕｓｅＯｎ）、一時停止の解除（ＰａｕｓｅＯｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌｏｆｆ）、速度指定付きの早送り（ＦｏｒｗａｒｄＰｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（ＢａｃｋｗａｒｄＰｌａｙ（ｓｐｅｅｄ））、音声切り換え（ＡｕｄｉｏＣｈａｎｇｅ）、副映像切り換え（ＳｕｂｔｉｔｌｅＣｈａｎｇｅ）、アングル切り換え（ＡｎｇｌｅＣｈａｎｇｅ）を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付けるＭｏｖｅＵｐキー、ＭｏｖｅＤｏｗｎキー、ＭｏｖｅＲｉｇｈｔキー、ＭｏｖｅＬｅｆｔキー、メニュー表示操作を受け付けるＰｏｐ−ｕｐキー、数値入力を受け付けるＮｕｍｅｒｉｃキーが含まれる。

以上が、本発明に係る再生装置１００の使用行為の形態についての説明である。
＜再生装置１００のハードウェア構成＞
次に、図２を用いて、再生装置１００の機能構成について説明する。
本発明に係る再生装置１００は、本図に示す内部構成に基づき、工業的に生産される。本発明に係る再生装置１００は、主としてシステムＬＳＩ（ＬａｒｇｅＳｃａｌｅＩｎｔｅｇｒａｔｉｏｎ）と、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置１００は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、サウンドプロセッサ６、サウンドプロセッサ７、ミキサー８、サウンドコントローラ９、Ｄ／Ａコンバータ１０、ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓデコーダ１１、ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓプレーン１２、ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓデコーダ１３、ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓプレーン１４、ＪＰＥＧデコーダ１５、Ｓｔｉｌｌプレーン１６、Ｓｔｉｌｌプレーン制御部１７、合成部１８ａ、１８ｂ、１８ｃ、ＳＴＣ−ＤＥＬＴＡ付加部１９、ＡＴＣ−ＤＥＬＴＡ付加部２０、ローカルストレージ２１、命令ＲＯＭ２２、ユーザイベント処理部２３、ＰＳＲセット２４、ＣＰＵ２５、シナリオメモリ２６、ローカルメモリ２７を含んで構成される。

ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する機能を有する。
リードバッファ２は、ＦＩＦＯ（ＦｉｒｓｔＩｎＦｉｒｓｔＯｕｔ）メモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットを順に格納した先に格納されたパケットから順次出力する機能を有する。
デマルチプレクサ（Ｄｅ−ＭＵＸ）３は、リードバッファ２からＳｏｕｒｃｅパケットを取り出して、このＳｏｕｒｃｅパケットを構成するＴＳパケットをＰＥＳパケットに変換する機能を有する。そして変換により得られたＰＥＳパケットのうち、ＳＴＮ＿Ｔａｂｌｅに記載されたものの中からＰＩＤ（ＰａｃｋｅｔＩＤｅｎｔｉｆｉｅｒ）をもつものをビデオデコーダ４、オーディオデコーダ６、ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓデコーダ１１、ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓデコーダ１３のいずれかに出力する機能も有する。Ｓｏｕｒｃｅパケット及び、ＳＴＮ＿Ｔａｂｌｅの詳細に関しては後述する。

ビデオデコーダ４は、デマルチプレクサ３から出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む機能を有する。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置１００において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーンはビデオでコーダによって書き込まれたデータを格納し出力する機能を有する。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の１／４（クオータという）、１／１（フルスケールという）のどちらかに変化させることである。かかるスケーリングを、ＢＤ−ＪモードにおいてＣＰＵ２５からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。

サウンドプロセッサ６は、オーディオストリームを構成するＰＥＳパケットをＰＩＤフィルタ３が出力した際、このＰＥＳパケットを格納しておく機能を有するオーディオバッファ６ａと、このバッファに格納されたＰＥＳパケットをデコーダして、ＰＣＭ（ＰｕｌｓｅＣｏｄｅＭｏｄｕｌａｔｉｏｎ）状態のオーディオデータを出力する機能を有するオーディオデコーダ６ｂとを含む。
サウンドプロセッサ７は、ＢＤ−ＲＯＭから読み出されたファイルｓｏｕｎｄ．ｂｄｍｖをプリロードしておく機能を有するプリロードバッファ７ａと、プリロードされたファイルｓｏｕｎｄ．ｂｄｍｖにおける複数のサウンドデータのうち、ＣＰＵ２５により指示されたものをデコードして、ＰＣＭ状態のオーディオデータを出力する機能を有するオーディオデコーダ７ｂとを含む。プリロードバッファ７ａへのプリロードは、ＢＤ−ＲＯＭの装填時やタイトル切替時に行うことが望ましい。何故なら、ＡＶＣｌｉｐの再生中にファイルｓｏｕｎｄ．ｂｄｍｖを読み出そうとすると、ＡＶＣｌｉｐとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、ＢＤ−ＲＯＭの装填時やタイトル切替時には、ＡＶＣｌｉｐの再生が継続していることは希なので、かかるタイミングにファイルｓｏｕｎｄ．ｂｄｍｖを読み出すことにより、ＡＶＣｌｉｐ再生が途切れないことを、保証することができる。

サウンドミキサ８は、サウンドプロセッサ６、及び、サウンドプロセッサ７から出力されるＰＣＭ状態のサウンドデータをミキシングする機能を有する。
サウンドコントローラ９は、サウンドミキサ８から出力された展開された状態のオーディオデータ、及び、サウンドプロセッサ６を介さずに圧縮された状態のオーディオデータのうち、どちらを出力するか切り換える機能を有する。圧縮された状態のオーディオデータを出力する場合は、その出力先の機器（テレビ）においてデコードされる。

Ｄ／Ａ変換部１０は、サウンドミキサ８から出力されるディジタルのオーディオデータをＤ／Ａ変換して、アナログ音声を出力する機能を有する。
Ｉ−Ｇｒａｐｈｉｃｓデコーダ（ＩＧデコーダ）１１は、ＢＤ−ＲＯＭ又はローカルストレージ２１から読み出されたＩＧストリームをデコードして、非圧縮グラフィクスをＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓプレーン１２に書き込む機能を有する。

ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓ（ＩＧ）プレーン１２には、ＨＤＭＶモードにおいてＩ−Ｇｒａｐｈｉｃｓデコーダ１１によるデコードで得られた非圧縮グラフィクスが書き込まれる。またＢＤ−Ｊモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３は、ＢＤ−ＲＯＭ又はローカルストレージ２１から読み出されたＰＧストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓ（ＰＧ）プレーン１１に書き込む機能を有する。Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３によってデコードされ、ＰｒｅｎｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓプレーン１１に書き込まれたデータが合成されることにより字幕が画面上に現れることになる。

ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓプレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
ＪＰＥＧデコーダ１５は、ＢＤ−ＲＯＭ又はローカルストレージ２１に記録されているＪＰＥＧデータをデコードして、Ｓｔｉｌｌプレーン１６に書き込む機能を有する。
Ｓｔｉｌｌプレーン１６は、ＪＰＥＧデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Ｊａｖａ（登録商標）アプリが描画する、ＧＵＩフレームワークのいわゆる“壁紙”として用いられる。

Ｓｔｉｌｌプレーン制御部１７は、Ｓｔｉｌｌプレーン１６からのデータの出力を制御する機能を有する。具体的には、ＣＰＵ２５からＶｉｄｅｏプレーン５に対するスケーリング指示を受けて、当該スケーリング指示がテレビ１３０の全体への表示指示であるフルスケールスケーリングである場合に、Ｓｔｉｌｌプレーン１６からのデータの読み出しを抑止する。そして、スケーリング指示がフルスケールの１／４であるクォータスケーリングである場合には、Ｓｔｉｌｌプレーン１６から合成部１８ｃに対して格納しているスチルデータを出力させる。

合成部１８ａ、ｂ、ｃは、ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓプレーン１２に格納されているデータと、ＰｒｅｓｅｎｔａｔｉｏｎＧｒａｐｈｉｃｓプレーン１１に格納されているデータと、ビデオプレーン５に格納されているデータと、Ｓｔｉｌｌプレーン１６に格納されているデータとを夫々合成し、得られた合成画像の画像信号を出力する機能を有する。なお、プレーンから画像信号が出力されなかった場合には合成せずに出力されてきた信号をそのまま出力する。

ＳＴＣ＿ｄｅｌｔａ付加部１８は、ＳＴＣ（ＳｙｓｔｅｍＴｉｍｅＣｌｏｃｋ）を生成する機能を有する。そしてＳＴＣ＿Ｓｅｑｕｅｎｃｅの切り換わり時において、それまでのＳＴＣ＿ＳｅｑｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）に、ＳＴＣ＿ｄｅｌｔａと呼ばれるオフセット値を加算することにより、新しいＳＴＣ＿ＳｅｑｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）を求めて、それまでのＳＴＣ＿ＳｅｑｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）と、新しいＳＴＣ＿ＳｅｑｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）とを連続した値にする。

先行ＳＴＣ＿Ｓｅｑｕｅｎｃｅにおいて最後に再生されるピクチャの表示開始時刻をＰＴＳ１（１ｓｔＥＮＤ）、ピクチャの表示期間をＴｐｐとし、後続ＳＴＣ＿Ｓｅｑｕｅｎｃｅにおいて最初に表示されるピクチャの開始時刻をＰＴＳ２（２ｎｄＳＴＡＲＴ）とした場合、ＳＴＣ＿ｄｅｌｔａは、
ＳＴＣ＿ｄｅｌｔａ＝ＰＴＳ１（１ｓｔＥＮＤ）＋Ｔｐｐ−ＰＴＳ２（２ｎｄＳＴＡＲＴ）
として表現される。以上のようにＳＴＣ＿ｄｅｌｔａを求め、これが足し合わされたクロックの計数値を各デコーダに出力する。これにより各デコーダは、２つのＳＴＣ＿Ｓｅｑｕｅｎｃｅにあたるストリームを途切れなく再生してゆくことができる。以上のにより、１つのＡＶＣｌｉｐの中に、２以上のＳＴＣ＿Ｓｅｑｕｅｎｃｅが存在したとしても、また、連続して再生されるべき２以上のＡＶＣｌｉｐのそれぞれが、異なるＳＴＣ＿Ｓｅｑｕｅｎｃｅをもっていたとしても、これらのＳＴＣ＿Ｓｅｑｕｅｎｃｅ間のデコード処理を、シームレスに実行することができる。

なお、バッファリングの連続性をみたすには、以下の条件１）、２）を満たせば良い。
１）ＳＴＣ２（２ｎｄＳＴＡＲＴ）＞ＳＴＣ２（１ｓｔＥＮＤ）をみたすこと。
２）ＴＳ１からのＴＳパケットの取り出しと、ＴＳ２からのＴＳパケットの取り出しとが、同じ時間軸に投影されたＳＴＣ１と、ＳＴＣ２とにより定義され、バッファのアンダーフローや、オーバーフローをもたらさないこと。

なお、１）においてＳＴＣ２（１ｓｔＥＮＤ）は、ＳＴＣ１（１ｓｔＥＮＤ）を、ＳＴＣ２の時間軸に投影した値であり、ＳＴＣ２（１ｓｔＥＮＤ）＝ＳＴＣ１（１ｓｔＥＮＤ）−ＳＴＣ＿ｄｅｌｔａという計算式で与えられる。
ＡＴＣ＿ｄｅｌｔａ付加部１９は、ＡＴＣ（ＡｒｒｉｖａｌＴｉｍｅＣｌｏｃｋ）を生成する機能を有する。そしてＡＴＣ＿Ｓｅｑｕｅｎｃｅの切り換わり時において、それまでのＡＴＣ＿ＳｅｑｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）に、ＡＴＣ＿ｄｅｌｔａと呼ばれるオフセット値を加算することにより、それまでのＡＴＣ＿ＳｅｑｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）と、新しいＡＴＣ＿ＳｅｑｕｅｎｃｅのＡＴＣ値（ＡＴＣ２）とを連続した値にする。この加算により、ＡＴＣ２＝ＡＴＣ１＋ＡＴＣ＿ｄｅｌｔａになる。ＡＴＣ＿ｄｅｌｔａとは、これまで読み出されているトランスポートストリーム（ＴＳ１）の最後のＴＳパケットの入力時点Ｔ１から、新たに読み出されたトランスポートストリーム（ＴＳ２）の最初のＴＳパケットの入力時点Ｔ２までのオフセット値をいい、“ＡＴＣ＿ｄｅｌｔａ≧Ｎ１／ＴＳ＿ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ”という計算式で与えられる。ここで入力時点Ｔ２は、ＴＳ２の最初のＴＳパケットの入力時点を、ＴＳ１の時間軸上に投影した時点を意味する。またＮ１は、ＴＳ１の最後のビデオＰＥＳパケットに後続する、ＴＳパケットのパケット数である。ＢＤ−ＲＯＭにおいてかかるＡＴＣ＿ｄｅｌｔａは、Ｃｌｉｐ情報に記述されるので、これを用いることにより、ＡＴＣ＿ｄｅｌｔａを計算することができる。以上の計算により、これまでのＡＴＣ＿ＳｅｑｕｅｎｃｅがもっているＡＴＣ値（ＡＴＣ１）と、新たなＡＴＣ＿ＳｅｑｕｅｎｃｅがもっているＡＴＣ値（ＡＴＣ２）とを、連続した値にすることができる。ＡＴＣ＿ｄｅｌｔａが足し合わされたクロックの計数値をデマルチプレクサ（Ｄｅ−ＭＵＸ）３に出力することで、シームレスなバッファ制御を実現することができる。

以上がＡＶＣｌｉｐの再生に係る構成要素である。続いてＢＤ−Ｊモードでの動作に係る構成要素（ローカルストレージ２１〜ローカルメモリ２７）について説明する。
ローカルストレージ２１は、ｗｅｂサイトからダウンロードされたコンテンツ等、ＢＤ−ＲＯＭ以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておく機能を有するハードディスクである。このメタデータは、ダウンロードコンテンツをローカルストレージ２１にバインドして管理するための情報であり、このローカルストレージ２１をアクセスすることで、ＢＤ−Ｊモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。

続いて、再生装置における統合制御を実現する構成要素（命令ＲＯＭ２２〜ローカルメモリ２６）について説明する。
命令ＲＯＭ２２は、再生装置の制御を規定するソフトウェアを記憶している。
ユーザイベント処理部２３は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをＣＰＵ２５に出力する。

ＰＳＲ（ＰｌａｙｅｒＳｔａｔｕｓＲｅｇｉｓｔｅｒ）セット２４は、再生装置に内蔵されるレジスタであり、６４個のＰＳＲと、４０９６個のＧＰＲ（ＧｅｎｅｒａｌＰｕｒｐｏｓｅＲｅｇｉｓｔｅｒ）とからなる。ＰｌａｙｅｒＳｔａｔｕｓＲｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。
ＰＳＲ４は、１〜１００の値に設定されることで、現在の再生時点が属するタイトルを示し、０に設定されることで、現在の再生時点がトップメニューであることを示す。

ＰＳＲ５は、１〜９９９の値に設定されることで、現在の再生時点が属するチャプター番号を示し、０ｘＦＦＦＦに設定されることで、再生装置においてチャプター番号が無効であることを示す。
ＰＳＲ６は、０〜９９９の値に設定されることで、現在の再生時点が属するプレイリスト（カレントＰＬ）の番号を示す。

ＰＳＲ７は、０〜２５５の値に設定されることで、現在の再生時点が属するＰｌａｙＩｔｅｍ（カレントＰｌａｙＩｔｅｍ）の番号を示す。
ＰＳＲ８は、０〜ＯｘＦＦＦＦＦＦＦＦの値に設定されることで、４５ＫＨｚの時間精度を用いて現在の再生時点（カレントＰＴＭ（ＰｒｅｓｅｎｔａｔｉｏｎＴｉＭｅ））を示す。以上のＰＳＲ４〜ＰＳＲ８により、図１８（ａ）におけるＢＤ−ＲＯＭ全体の時間軸において、現在の再生時点はどこであるかを特定することができる。

ＣＰＵ２５は、命令ＲＯＭ２２に格納されているソフトウェアを実行して、再生装置全体の制御を実行する機能を有する。この制御の内容は、ユーザイベント処理部２３から出力されたユーザイベント、及び、ＰＳＲセット２４における各ＰＳＲの設定値に応じて動的に変化する。
シナリオメモリ２６は、カレントのＰＬ情報やカレントのＣｌｉｐ情報を格納しておく機能を有するメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭに記録されている複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。

ローカルメモリ２７は、ＢＤ−ＲＯＭからの読み出しは低速である故、ＢＤ−ＲＯＭの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２７が存在することにより、ＢＤ−Ｊモードにおけるアプリケーション実行は、効率化されることになる。
以上が、本実施形態に係る再生装置のハードウェア構成である。
＜再生装置１００のソフトウェア構成＞
続いて本実施形態に係る再生装置のソフトウェア構成について説明する。

図３には、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のａ），ｂ），ｃ）からなる。つまり、
ａ）ＢＤＰｌａｙｅｒＤｅｖｉｃｅの第１階層、
ｂ）ＢＤＰｌａｙｅｒＭｏｄｅｌの第２階層、
ｃ）ＡｐｐｌｉｃａｔｉｏｎＲｕｎｔｉｍｅＥｎｖｉｒｏｍｅｎｔの第３階層からなる。

これらの階層のうち図３に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”ＢＤＰｌａｙｅｒＤｅｖｉｃｅ”には、図２に示したハードウェア構成のうちビデオデコーダ４、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１１、オーディオデコーダ６等にあたる”デコーダ”と、ビデオプレーン５、ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓプレーン１２等にあたる”プレーン”、ＢＤ−ＲＯＭ１１０及びそのファイルシステム、ローカルストレージ２１及びそのファイルシステムを含む。

第２階層”ＢＤＰｌａｙｅｒＭｏｄｅｌ”は、以下のｂ１），ｂ２）の層からなる。つまり、
ｂ１）ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０及びＰｒｅｓｅｎｔａｔｉｏｎＥｎｇｉｎｅ３１の層
ｂ２）ＰｌａｙｂａｃｋＣｏｎｔｒｏｌＥｎｇｉｎｅ３２の層
からなり、自身より上位の階層に対し、ファンクションＡＰＩを提供する。
第３階層”ＡｐｐｌｉｃａｔｉｏｎＲｕｎｔｉｍｅＥｎｖｉｒｏｍｅｎｔ”は、以下のｃ１），ｃ２）の階層からなる。つまり、
ｃ１）モジュールマネージャ３４が存在する層、
ｃ２）ＢＤ−Ｊプラットフォーム３５が存在する層
からなる。

先ず初めに、第２層に属するＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０〜モジュールマネージャ３４について説明する。
ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０は、ローカルストレージ２１に格納されたダウンロードコンテンツを、ＢＤ−ＲＯＭにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージ２１に格納されたダウンロードコンテンツは、ＳｕｂＣｌｉｐ、Ｃｌｉｐ情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はＢＤ−ＲＯＭ及びローカルストレージ２１のどちらに存在するＣｌｉｐ情報であっても、指定できる点で、ＢＤ−ＲＯＭ上のプレイリスト情報と異なる。この指定にあたって、ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０上のプレイリスト情報は、ＢＤ−ＲＯＭやローカルストレージ２１におけるファイルをフルパスで指定する必要はない。ＢＤ−ＲＯＭ上のファイルシステムやローカルストレージ２１上のファイルシステムは、仮想的な１つのファイルシステム（ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０）として、認識されるからである。故に、ＰｌａｙＩｔｅｍ情報におけるＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる５桁の数値を指定することにより、ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０、ＢＤ−ＲＯＭ上のＡＶＣｌｉｐを指定することができる。ＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０を介してローカルストレージ２１の記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージ２１と、ＢＤ−ＲＯＭとを組合せてなるディスクコンテンツは、ＢＤ−ＲＯＭにおけるディスクコンテンツと対等に扱われるので、本発明においてＢＤ−ＲＯＭには、ローカルストレージ２１＋ＢＤ−ＲＯＭの組合せからなる仮想的な記録媒体をも含むことにする。

ＰｒｅｓｅｎｔａｔｉｏｎＥｎｇｉｎｅ３１は、ＡＶ再生ファンクションを実行する。再生装置のＡＶ再生ファンクションとは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（ＰａｕｓｅＯｎ）、一時停止の解除（ＰａｕｓｅＯｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌｏｆｆ）、速度指定付きの早送り（ＦｏｒｗａｒｄＰｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（ＢａｃｋｗａｒｄＰｌａｙ（ｓｐｅｅｄ））、音声切り換え（ＡｕｄｉｏＣｈａｎｇｅ）、副映像切り換え（ＳｕｂｔｉｔｌｅＣｈａｎｇｅ）、アングル切り換え（ＡｎｇｌｅＣｈａｎｇｅ）といった機能である。ＡＶ再生ファンクションを実現するべく、ＰｒｅｓｅｎｔａｔｉｏｎＥｎｇｉｎｅ３１は、リードバッファ２上に読み出されたＡＶＣｌｉｐのうち、所望時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ６を制御する。所望の時刻としてＰＳＲ８（カレントＰＴＭ）に示される箇所のデコードを行わせることにより、ＡＶＣｌｉｐにおいて、任意の時点を再生を可能することができる。

再生制御エンジン（ＰｌａｙｂａｃｋＣｏｎｔｒｏｌＥｎｇｉｎｅ（ＰＣＥ））３２は、プレイリストに対する再生制御ファンクション（ｉ）、ＰＳＲセット２３における状態取得／設定ファンクション（ｉｉ）といった諸機能を実行する。プレイリストに対する再生制御ファンクションとは、ＰｒｅｓｅｎｔａｔｉｏｎＥｎｇｉｎｅ３１が行うＡＶ再生ファンクションのうち、再生開始や再生停止を、カレントＰＬ情報及びＣｌｉｐ情報に従って行わせることをいう。これらの機能（ｉ）、（ｉｉ）は、ＨＤＭＶモジュール３３〜ＢＤ−Ｊプラットフォーム３５からのファンクションコールに応じて実行する。

モジュールマネージャ３４は、ＢＤ−ＲＯＭから読み出されたＩｎｄｅｘ．ｂｄｍｖを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにＴｅｒｍｉｎａｔｅイベントを発行し、分岐先タイトルを構成する動的シナリオにＡｃｔｉｖａｔｅイベントを発行することでなされる。
以上がＰｒｅｓｅｎｔａｔｉｏｎＥｎｇｉｎｅ３１〜モジュールマネージャ３４についての説明である。続いてＢＤ−Ｊプラットフォーム３５について説明する。

ＢＤ−Ｊプラットフォーム３５は、いわゆるＪａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン３６を中核にした構成になっている。ＢＤ−Ｊプラットフォーム３５は、上述したＪａｖａ（登録商標）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）ＰｅｒｓｏｎａｌＢａｓｉｓＰｒｏｆｉｌｅ（ＰＢＰ１．０）と、ＧｌｏｂａｌｌｙＥｘｅｃｕｔａｂｌｅＭＨＰｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ［１．０．２］）ｆｏｒｐａｃｋａｇｅｍｅｄｉａｔａｒｇｅｔｓに加え、ＢＤ−ＪＥｘｔｅｎｔｉｏｎを実装している。ＢＤ−ＪＥｘｔｅｎｔｉｏｎは、ＧＥＭ［１．０．２］を越えた機能を、ＢＤ−Ｊプラットフォームに与えるために特化された、様々なパッケージを含んでいる。

先ず初めに、ＢＤ−Ｊプラットフォーム３５の中核となるＪａｖａ（登録商標）仮想マシン３６について説明する。
＜Ｊａｖａ（登録商標）仮想マシン３６＞
図４は、Ｊａｖａ（登録商標）仮想マシン３６の内部構成を示す図である。本図に示すようにＪａｖａ（登録商標）仮想マシン３６は、図３３に示したＣＰＵ２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５ａ，ｂ・・・ｎ、Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎとから構成される。

ユーザクラスローダ５２は、ＢＤＪＡディレクトリのＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３７がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがＶｉｒｔｕａｌＦｉｌｅＳｙｓｔｅｍ３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ＢＤ−ＲＯＭ又はローカルストレージ２０からワークメモリ５４に読み出す。アプリケーションの起動制御は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３７に通知することになる。

メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２７から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３に示したアプリケーションマネージャ３７は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するｘｌｅｔプログラムである。かかるｘｌｅｔプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。

図３のレイアモデルでは、このワークメモリ５４上のアプリケーションマネージャ３７を、Ｊａｖａ（登録商標）仮想マシン３６上に描いていたが、これはわかり易すさを意図した配慮に過ぎない。アプリケーションマネージャ３７及びアプリケーションはインスタンスとしてスレッド５５ａ，ｂ・・・ｎにより実行されるというのが、現実的な記述になる。
スレッド５５ａ，ｂ・・・ｎは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ｋｙ１，ｋｙ２，ｋｙｎは、ワークメモリ５４からスレッド５５ａ，ｂ・・・ｎへのメソッド供給を象徴的に示している。物理的な実行主体がＣＰＵ唯１つであるのに対し、論理的な実行主体たるスレッドは、最大６４個Ｊａｖａ（登録商標）仮想マシン３６内に存在し得る。この６４個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Ｊａｖａ（登録商標）仮想マシン３６の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより１つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではＣＰＵ２４と、スレッドとの対応関係は、１対多の関係にしているが、ＣＰＵが複数ある場合、ＣＰＵとスレッドとの対応関係は多対多の関係になりうる。スレッド５５ａ，ｂ・・・ｎによるメソッド実行は、メソッドをなすバイトコードを、ＣＰＵ２４のネイティブコードに変換した上、ＣＰＵ２４に発行することでなされる。

Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎは、スレッド５５ａ，ｂ・・・ｎと１対１の比率で存在しており、プログラムカウンタ（図中のＰＣ）と、１つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する１回のコールに対して割り当てられたスタック式の領域であり、その１回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック（図中のローカル変数）”とからなる。フレームは、コールが１回なされる度にＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、１つ積み上げられることになる。

以上がＪａｖａ（登録商標）仮想マシンについての説明である。
＜アプリケーションマネージャ３７＞
続いてアプリケーションマネージャ３７について、説明する。アプリケーションマネージャ３７は、Ｊａｖａ（登録商標）仮想マシン３６内のワークメモリ上で動作するシステムソフトウェアであり、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではＡｕｔｏＲｕｎの起動属性を有するアプリケーションを起動するようＪａｖａ（登録商標）仮想マシン３６に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントＢＤ−ＪＯｂｊｅｃｔにおけるアプリケーション管理テーブルを参照した上でなされる。
＜ＢＤ−ＲＯＭの構成＞
次にＢＤ−ＲＯＭ１１０に記録されているデータに関して説明する。

まず、図５を用いてＢＤ−ＲＯＭ１１０のデータのファイルディレクトリ構造について説明する。
図５に示すように、ＢＤ−ＲＯＭ１１０には、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。
ＢＤＭＶディレクトリには、拡張子ｂｄｍｖが付与されたファイル（ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ）がある。そしてこのＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＢＪディレクトリ、ＢＤＪＡディレクトリ、ＡＵＸＤＡＴＡディレクトリと呼ばれる６つのサブディレクトリが存在する。

ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）がある。
ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）がある。
ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）がある。

ＢＤＢＪディレクトリには、拡張子ＢＯＢＪが付与されたファイル（００００１．ＢＯＢＪ，００００２．ｂｏｂｊ，００００３．ｂｏｂｊ）が存在する。
ＢＤＪＡディレクトリには、拡張子ｊａｒが付与されたファイル（００００１．ｊａｒ，００００２．ｊａｒ，００００３．ｊａｒ）がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。

ＡＵＸＤＡＴＡディレクトリには、ファイルｓｏｕｎｄ．ｂｄｍｖが格納される。
＜ＢＤ−ＲＯＭの構成その１．ＡＶＣｌｉｐ＞
先ず初めに、拡張子．ｍ２ｔｓが付与されたファイルについて説明する。図６は、拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示した図である。拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ、００００２．ｍ２ｔｓ、００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐはＭＰＥＧ２−ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデジタルストリームである。このデジタルストリームは、フィルム映像、ＮＴＳＣ（ＮａｔｉｏｎａｌＴｅｌｅｖｉｓｉｏｎＳｔａｎｄａｒｄｓＣｏｍｍｉｔｔｅｅ）映像、ＰＡＬ（ＰｈａｓｅＡｌｔｅｒｎａｔｉｏｎｂｙＬｉｎｅ）処理をデジタル化することにより得られたデジタルビデオ、ＬＰＣＭ（ＬｉｎｅａｒＰｕｌｓｅＣｏｄｅＭｏｄｕｌａｔｉｏｎ）音源、ＡＣ−３音源、ＤＴＳ（ＤｉｇｉｔａｌＳｕｒｒｏｕｎｄ）音源をデジタル化することにより得られたデジタルオーディオを（上１段目）、ＰＥＳパケットからなるエレメンタリストリームに変換し（上２段目）、更にＴＳパケットに変換して（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（ＰｒｅｓｅｎｔａｔｉｉｏｎＧｒａｐｈｉｃｓ（ＰＧ）ストリーム）及び対話系のインタラクティブグラフィクスストリーム（ＩｎｔｅｒａｃｔｉｖｅＧｒａｐｈｉｃｓ（ＩＧ）ストリーム）を（下１段目）を、ＰＥＳパケット列に変換し（下２段目）、更にＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。

ＰＧストリームとは、動画の再生進行に伴った字幕表示を実現するエレメンタリストリームであり、ＩＧストリームは、動画の再生進行に伴ったＧＵＩを実現するエレメンタリストリームである。これらＩＧストリーム、及びＰＧストリームについては、本発明の主眼ではないので、説明を省略する。
ビデオストリームのうち、１つのＰＴＳで再生される再生単位（ピクチャ等）を、“ＶｉｄｅｏＰｒｅｓｅｎｔａｔｉｏｎＵｎｉｔ”という。オーディオストリームのうち、１つのＰＴＳで再生される再生単位を、“ＡｕｄｉｏＰｒｅｓｅｎｔａｔｉｏｎＵｎｉｔ”という。

ここでＡＶＣｌｉｐを構成するＰＥＳパケットは、１つ以上の“ＳＴＣ＿Ｓｅｑｕｅｎｃｅ”を構成する。“ＳＴＣ＿Ｓｅｑｕｅｎｃｅ”とは、ＰＥＳパケットの配列であって、そのＰＴＳ、ＤＴＳが参照しているＳｙｓｔｅｍＴｉｍｅＣｌｏｃｋ（ＳＴＣ）の値に、ＳＴＣ不連続点（ｓｙｓｔｅｍｔｉｍｅ−ｂａｓｅｄｉｓｃｏｎｔｉｎｕｉｔｙ）が存在しないものをいう。ＳＴＣ不連続点がないことがＳＴＣ＿Ｓｅｑｕｅｎｃｅの要件であるので、１つのＳＴＣ＿Ｓｅｑｕｅｎｃｅを構成するＰＥＳパケット列のうち、ＳＴＣ不連続点の直後に位置するＰＥＳパケットであって、ＰＣＲ（ＰｒｏｇｒａｍＣｌｏｃｋＲｅｆｅｒｅｎｃｅ）を包含したものから、次のＳＴＣ不連続点の直前までが１つのＳＴＣ＿Ｓｅｑｕｅｎｃｅになる。

＜Ｃｌｉｐ情報＞
続いて拡張子．ｃｌｐｉが付与されたファイルについて説明する。拡張子．ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、Ｃｌｉｐ情報を格納している。Ｃｌｉｐ情報は、個々のＡＶＣｌｉｐについての管理情報である。図７は、Ｃｌｉｐ情報の内部構成を示す図である。本図の左側に示すようにＣｌｉｐ情報は、
ｉ）ＡＶＣｌｉｐについての情報を格納した『ＣｌｉｐＩｎｆｏ（）』、
ｉｉ）ＡＴＣＳｅｑｕｅｎｃｅ，ＳＴＣＳｅｑｕｅｎｃｅに関する情報を格納した『ＳｅｑｕｅｎｃｅＩｎｆｏ（）』
ｉｉｉ）ＰｒｏｇｒａｍＳｅｑｕｅｎｃｅに関する情報を格納した『ＰｒｏｇｒａｍＩｎｆｏ（）』
ｉｖ）『ＣｈａｒａｃｔｅｒｉｓｔｉｃＰｏｉｎｔＩｎｆｏ（ＣＰＩ（））』
を含んで構成される。

ＳｅｑｕｅｎｃｅＩｎｆｏは、ＡＶＣｌｉｐに含まれる、１つ以上のＳＴＣ−Ｓｅｑｕｅｎｃｅ、ＡＴＣ−Ｓｅｑｕｅｎｃｅについての情報である。これらの情報を設けておくことの意義は、ＳＴＣ、ＡＴＣの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、ＡＶＣｌｉｐ内において同じ値のＰＴＳ，ＰＣＲが出現する可能性があり、再生時に不都合が生じる。ＳＴＣ，ＡＴＣが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、ＳｅｑｕｅｎｃｅＩｎｆｏは設けられている。

ＰｒｏｇｒａｍＩｎｆｏとは、Ｐｒｏｇｒａｍ内容が一定である区間（ＰｒｏｇｒａｍＳｅｑｕｅｎｃｅ）を示す情報である。Ｐｒｏｇｒａｍとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ＰｒｏｇｒａｍＳｅｑｕｅｎｃｅ情報を設けておくことの意義は、Ｐｒｏｇｒａｍ内容の変化点を、予め再生装置に通知するためである。ここでのＰｒｏｇｒａｍ内容の変化点とは、ビデオストリームのＰＩＤが変化したり、ビデオストリームの種類がＳＤＴＶ（ＳｔａｎｄａｒｄＤｅｆｉｎｉｔｉｏｎＴｅｌｅＶｉｓｉｏｎ）からＨＤＴＶ（Ｈｉｇｈ−ＤｅｆｉｎｉｔｉｏｎＴｅｌｅＶｉｓｉｏｎ）に変化している点等をいう。

続いてＣｈａｒａｃｔｅｒｉｓｔｉｃＰｏｉｎｔＩｎｆｏについて説明する。図７中の引き出し線ｃｕ２は、ＣＰＩの構成をクローズアップしている。引き出し線ｃｕ２に示すように、ＣＰＩは、Ｎｅ個のＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（０）〜ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（Ｎｅ−１））からなる。これらＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、ＡＶＣｌｉｐに属する個々のエレメンタリストリームについてのＥＰ＿ｍａｐである。ＥＰ＿ｍａｐは、１つのエレメンタリストリーム上において、ＡｃｃｅｓｓＵｎｉｔＤｅｌｉｍｉｔｅｒが存在するエントリー位置のパケット番号（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を、エントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）と対応づけて示す情報である。図中の引き出し線ｃｕ３は、ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤの内部構成をクローズアップしている。

同図からＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、Ｎｃ個のＥＰ＿Ｈｉｇｈ（ＥＰ＿Ｈｉｇｈ（０）〜ＥＰ＿Ｈｉｇｈ（Ｎｃ−１））と、Ｎｆ個のＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ（０）〜ＥＰ＿Ｌｏｗ（ＮＦ−１））とが含まれることがわかる。ここでＥＰ＿Ｈｉｇｈは、ＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ−ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの上位ビットを表す役割をもち、ＥＰ＿Ｌｏｗは、ＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ＿ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの下位ビットを示す役割をもつ。

図７中の引き出し線ｃｕ４は、ＥＰ＿Ｈｉｇｈの内部構成をクローズアップしている。この引き出し線に示すように、ＥＰ＿Ｈｉｇｈ（ｉ）は、ＥＰ＿Ｌｏｗに対する参照値である『ｒｅｆ＿ｔｏ＿ＥＰ＿Ｌｏｗ＿ｉｄ［ｉ］』と、ＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ−ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＰＴＳの上位ビットを示す『ＰＴＳ＿ＥＰ＿Ｈｉｇｈ［ｉ］』と、ＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ−ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＳＰＮの上位ビットを示す『ＳＰＮ＿ＥＰ＿Ｈｉｇｈ［ｉ］』とからなる。ここでｉとは、任意のＥＰ＿Ｈｉｇｈを識別するための識別子である。

図７中の引き出し線ｃｕ５は、ＥＰ＿Ｌｏｗの構成をクローズアップしている。引き出し線ｃｕ５に示すように、ＥＰ＿Ｌｏｗは、対応するＡｃｃｅｓｓＵｎｉｔがＩＤＲピクチャか否かを示す『ｉｓ＿ａｎｇｌｅ＿ｃｈａｎｇｅ＿ｐｏｉｎｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓＵｎｉｔのサイズを示す『Ｉ＿ｅｎｄ＿ｐｏｓｉｔｉｏｎ＿ｏｆｆｓｅｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ−ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＰＴＳの下位ビットを示す『ＰＴＳ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓＵｎｉｔ（Ｎｏｎ−ＩＤＲＩピクチャ、ＩＤＲピクチャ）のＳＰＮの下位ビットを示す『ＳＰＮ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』とからなる。ここでＥＰ＿Ｌｏｗ＿ｉｄとは、任意のＥＰ＿Ｌｏｗを識別するための識別子である。

＜Ｃｌｉｐ情報の説明その２．ＥＰ＿ｍａｐ＞
以下、具体例を通じて、ＥＰ＿ｍａｐについて説明する。図８は、映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。第１段目は、表示順序に配置された複数のピクチャ（ＭＰＥＧ４−ＡＶＣに規定されたＢピクチャ、ＩＤＲピクチャ、Ｐピクチャ）を示し、第２段目は、そのピクチャにおける時間軸を示す。第４段目は、ＢＤ−ＲＯＭ上のＴＳパケット列を示し、第３段目は、ＥＰ＿ｍａｐの設定を示す。

第２段目の時間軸において、時点ｔ１〜ｔ７に、ＡｃｃｅｓｓＵｎｉｔとなるＩＤＲピクチャが存在するものとする。そしてこれらのｔ１〜ｔ７の時間間隔が、１秒程度であるとすると、映画に用いられるビデオストリームにおけるＥＰ＿ｍａｐは、ｔ１〜ｔ７をエントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）として示し、これに対応づけてエントリー位置（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を示すよう、設定される。
＜ＰｌａｙＬｉｓｔ情報＞
続いて、ＰｌａｙＬｉｓｔ情報について説明する。拡張子“ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ）は、ＰｌａｙＬｉｓｔ（ＰＬ）情報を格納したファイルである。ＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈと呼ばれる再生経路と、これに対応する再生情報とをプレイリスト（ＰＬ）として定義する情報である。

図９は、ＰｌａｙＬｉｓｔ情報のデータ構造を示す図であり、本図に示すようにＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈを定義するＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））と、チャプターを定義するＰｌａｙＬｉｓｔＭａｒｋ情報（ＰｌａｙＬｉｓｔＭａｒｋ（））とからなる。
ＭａｉｎＰａｔｈとは、主たるＡＶＣｌｉｐ上に定義される再生経路である。一方Ｓｕｂｐａｔｈは、ＳｕｂＣｌｉｐ上に定義される再生経路である。ここでＳｕｂＣｌｉｐとは、動画像たるビデオストリームを含まないＡＶＣｌｉｐである。

＜ＰｌａｙＬｉｓｔ情報の説明その１．ＭａｉｎＰａｔｈ情報＞
先ずＭａｉｎＰａｔｈについて説明する。ＭａｉｎＰａｔｈは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
ＭａｉｎＰａｔｈは、矢印ｍｐ１で示すように複数のＰｌａｙＩｔｅｍ情報＃１・・・・＃ｍから定義される。
ＰｌａｙＩｔｅｍ情報は、ＭａｉｎＰａｔｈを構成する１つ以上の論理的な再生区間を定義する。ＰｌａｙＩｔｅｍ情報の構成は、引き出し線ｈｓ１によりクローズアップされている。この引き出し線に示すようにＰｌａｙＩｔｅｍ情報は、再生区間のＩＮ点及びＯｕｔ点が属するＡＶＣｌｉｐの再生区間情報のファイル名を示す『Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、ＡＶＣｌｉｐの符号化方式を示す『Ｃｌｉｐ＿ｃｏｄｅｃ＿ｉｄｅｎｔｉｆｉｅｒ』と、再生区間の始点を示す時間情報『ＩＮ＿ｔｉｍｅ』と、再生区間の終点を示す時間情報『ＯＵＴ＿ｔｉｍｅ』と、『ＳＴＮ＿ｔａｂｌｅ』とから構成される。

図１０は、ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。第１段目は、ＰｌａｙＬｉｓｔ情報がもつ時間軸を示す。第２段目から第５段目は、ＥＰ＿ｍａｐにて参照されているビデオストリーム（図６に示したものと同じ）を示す。
ＰｌａｙＬｉｓｔ情報は、ＰｌａｙＩｔｅｍ情報＃１，＃２という２つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ情報＃１，＃２のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、２つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第１段目に示すＰｌａｙＩｔｅｍ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる時間軸の定義が可能になる。

＜ＳＴＮ＿ｔａｂｌｅ＞
ＳＴＮ＿ｔａｂｌｅは、ＰｌａｙＩｔｅｍのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＡＶＣｌｉｐに多重化された複数エレメンタリストリームのうち、再生可能なものを示すテーブルである。具体的にいうとＳＴＮ＿ｔａｂｌｅは、複数エレメンタリストリームのそれぞれについてのｅｎｔｒｙを、ａｔｔｒｉｂｕｔｅと対応付けることで構成される。

図１１は、ＳＴＮ＿ｔａｂｌｅの内部構成を示す図である。本図に示すようにＳＴＮ＿ｔａｂｌｅは、ＳＴＮ＿ｔａｂｌｅにおけるｅｎｔｒｙと、ａｔｔｒｉｂｕｔｅとの組み（ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅ）を複数含み、これらｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みの個数（ｎｕｍｂｅｒ＿ｏｆ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＰＧ＿ｔｅｘｔＳＴ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＩＧ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ）を示すデータ構造になっている。

ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みは、図中の括弧記号“｛”に示すように、ＰｌａｙＩｔｅｍにおいて再生可能なビデオストリーム、オーディオストリーム、ＰＧ＿ｔｅｘｔＳＴ＿ｓｔｒｅａｍ、ＩＧストリームのそれぞれに対応している。
ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細について説明する。図１１は、ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細を示す図である。

図１２（ａ）は、ビデオストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ビデオストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ビデオストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。
ビデオストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ０２に設定された『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、ビデオストリームの表示レートを示す『Ｆｒａｍｅ＿ｒａｔｅ』等を含む。

図１２（ｂ）は、オーディオストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
オーディオストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該オーディオストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。

オーディオストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ８０（ＬｉｎｅａｒＰＣＭ），０ｘ８１（ＡＣ−３），０ｘ８２（ＤＴＳ）の何れかに設定されることによりオーディオストリームのコーデイングタイプを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するオーディオストリームのチャネル構成を示し、マルチチャネル出力の可否を示す『ａｕｄｉｏ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｙｐｅ』と、対応するオーディオストリームの言語属性を示す『ａｕｄｉｏ＿ｌａｎｇｕａｇｅｃｏｄｅ』等からなる。

マルチチャネルには、５．１ＣＨのサラウンド音声の他、ステレオ音声も含まれるが、以降の説明では、マルチチャネルは、５．１ＣＨのサラウンド音声のみを意味するとして説明を進める。
図１２（ｃ）は、ＰＧストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ＰＧストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ＰＧストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。

ＰＧストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ９０に設定されることによりＰＧストリームのコーディックを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するＰＧストリームの言語属性を示す『ＰＧ＿ｌａｎｇｕａｇｅｃｏｄｅ』とからなる。
図１２（ｄ）は、ＩＧストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ＩＧストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ＩＧストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。

ＩＧストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ９１に設定されることによりＩＧストリームのコーディックを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するＩＧストリームの言語属性を示す『ｌａｎｇｕａｇｅｃｏｄｅ』とからなる。
＜ＰｌａｙＬｉｓｔ情報の説明その２．ＰｌａｙＬｉｓｔＭａｒｋ＞
以上が、本実施形態に係るＰｌａｙＩｔｅｍ情報についての説明である。続いてＰｌａｙＬｉｓｔＭａｒｋ情報について説明する。

図１３は、ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報の内部構成を示す図である。本図の図中の引き出し線ｐｍ０に示すように、ＰｌａｙＬｉｓｔＭａｒｋ情報は、複数のＰＬＭａｒｋ情報（＃１〜＃ｎ）からなる。ＰＬｍａｒｋ情報（ＰＬｍａｒｋ（））は、ＰＬ時間軸のうち、任意の区間を、チャプター点として指定する情報である。引き出し線ｐｍ１に示すようにＰＬｍａｒｋ情報は、チャプター指定の対象たるＰｌａｙＩｔｅｍを示す『ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、そのＰｌａｙＩｔｅｍにおける、チャプター位置を時間表記により示す『ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ』とを含む。

図１４は、ＰｌａｙＬｉｓｔ情報の、ＰＬＭａｒｋ情報によるチャプター位置の指定を示す図である。本図の第２段目から第５段目は、図１０に示した、ＥＰ＿ｍａｐと、ＡＶＣｌｉｐとを示す。
本図の第１段目は、ＰＬＭａｒｋ情報と、ＰＬ時間軸とを示す。この第１段目には、２つのＰＬＭａｒｋ情報＃１〜＃２が存在する。矢印ｋｔ１，２は、ＰＬＭａｒｋ情報のｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄによる指定を示す。この矢印からもわかるように、ＰＬＭａｒｋ情報のｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、ＰｌａｙＩｔｅｍ情報のそれぞれを指定していることがわかる。また、Ｍａｒｋ＿ｔｉｍｅ＿Ｓｔａｍｐは、ＰｌａｙＩｔｅｍ時間軸のうち、Ｃｈａｐｔｅｒ＃１，＃２になるべき時点を示す。このように、ＰＬＭａｒｋ情報は、ＰｌａｙＩｔｅｍ時間軸上に、チャプター点を定義することができる。

ＡＶＣｌｉｐ−ＳｕｂＣｌｉｐを同期させ得る同期区間の定義を可能とするのが、ＢＤ−ＲＯＭにおけるプレイリスト情報の特徴である。以上のＣｌｉｐ情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のＣｌｉｐ情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。

続いて”動的なシナリオ”について説明する。動的シナリオとは、ＡＶＣｌｉｐの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、この再生制御の動作環境として２つのモードを想定している。１つ目は、ＤＶＤ再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。２つ目は、Ｊａｖａ（登録商標）仮想マシンの動作環境である。これら２つの動作環境のうち１つ目は、ＨＤＭＶモードと呼ばれる。２つ目は、ＢＤ−Ｊモードと呼ばれる。これら２つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。ＨＤＭＶモードを想定した動的シナリオはＭｏｖｉｅＯｂｊｅｃｔと呼ばれる。一方ＢＤ−Ｊモードを想定した動的シナリオはＢＤ−ＪＯｂｊｅｃｔと呼ばれる。

先ず初めにＭｏｖｉｅＯｂｊｅｃｔについて説明する。
＜ＭｏｖｉｅＯｂｊｅｃｔ＞
ＭｏｖｉｅＯｂｊｅｃｔは、図５に示したＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖというファイルに格納され、ナビゲーションコマンド列を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。ＭｏｖｉｅＯｂｊｅｃｔにおいて記述可能なコマンドを以下に示す。
１）ＰｌａｙＰＬコマンド
書式：ＰｌａｙＰＬ（第１引数，第２引数）
第１引数は、プレイリストの番号で、再生すべきプレイリストを指定することができる。第２引数は、そのプレイリストに含まれるＰｌａｙＩｔｅｍや、そのプレイリストにおける任意の時刻、Ｃｈａｐｔｅｒ、Ｍａｒｋを用いて再生開始位置を指定することができる。

ＰｌａｙＩｔｅｍによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＰｌａｙＩｔｅｍ（）、
ＣｈａｐｔｅｒによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＣｈａｐｔｅｒ（）、
時刻情報によりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＳｐｅｃｉｆｉｅｄＴｉｍｅ（）という。
２）ＪＭＰコマンド
書式：ＪＭＰ引数
ＪＭＰコマンドは、現在の動的シナリオを途中で廃棄し（ｄｉｓｃａｒｄ）、引数たる分岐先動的シナリオを実行するという分岐である。ＪＭＰ命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。

ＭｏｖｉｅＯｂｊｅｃｔにおけるナビゲーションコマンドの記述は、ＤＶＤにおけるナビゲーションコマンドの記述方式と良く似ているので、ＤＶＤ上のディスクコンテンツを、ＢＤ−ＲＯＭに移植するという作業を効率的に行うことができる。ＭｏｖｉｅＯｂｊｅｃｔについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。

国際公開公報Ｗ０２００４／０７４９７６
以上でＭｏｖｉｅＯｂｊｅｃｔについての説明を終える。続いてＢＤ−ＪＯｂｊｅｃｔについて説明する。
＜ＢＤ−ＪＯｂｊｅｃｔ＞
ＢＤ−ＪＯｂｊｅｃｔは、Ｊａｖａ（登録商標）プログラミング環境で記述された、ＢＤ−Ｊモードの動的シナリオであり、００００１〜００００３．ｂｏｂｊというファイルに格納される。

図１５は、ＢＤ−ＪＯｂｊｅｃｔの内部構成を示す図である。アプリケーション管理テーブル（ＡＭＴ）、プレイリスト管理テーブル（ＰＬＭＴ）とを含んで構成される。ＭｏｖｉｅＯｂｊｅｃｔとの違いは、ＢＤ−ＪＯｂｊｅｃｔにコマンドが直接記述されていない点である。つまりＭｏｖｉｅＯｂｊｅｃｔにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しＢＤ−ＪＯｂｊｅｃｔでは、Ｊａｖａ（登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。

またＭｏｖｉｅＯｂｊｅｃｔにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド（ＰｌａｙＰｌコマンド）の記述によりなされるが、ＢＤ−ＪＯｂｊｅｃｔにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをＢＤ−ＪＯｂｊｅｃｔに組み込むことで記述が可能になる。
このＢＤ−ＪモードにおけるＪａｖａ（登録商標）アプリケーションについて説明する。ここでＢＤ−Ｊモードが想定しているＪａｖａ（登録商標）プラットフォームは、Ｊａｖａ（登録商標）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）ＰｅｒｓｏｎａｌＢａｓｉｓＰｒｏｆｉｌｅ（ＰＢＰ１．０）と、ＧｌｏｂａｌｌｙＥｘｅｃｕｔａｂｌｅＭＨＰｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ１．０．２）ｆｏｒｐａｃｋａｇｅｍｅｄｉａｔａｒｇｅｔｓとをフル実装したものである。

このＢＤ−ＪモードにおけるＪａｖａ（登録商標）アプリケーションは、ｘｌｅｔインターフェイスを通じて、ＡｐｐｌｉｃａｔｉｏｎＭａｎａｇｅｒにより、制御される。ｘｌｅｔインターフェイスは、“ｌｏａｄｅｄ”，“ｐａｕｓｅｄ”、“ａｃｔｉｖｅ”，“ｄｅｓｔｒｏｙｅｄ”といった４つの状態をもつ。
上述したＪａｖａ（登録商標）プラットフォームは、ＪＦＩＦ（ＪＰＥＧ）やＰＮＧ，その他のイメージデータを表示するためのスタンダードＪａｖａ（登録商標）ライブラリを含む。このため、Ｊａｖａ（登録商標）アプリケーションは、ＨＤＭＶモードにおいてＩＧストリームにより実現されるＧＵＩとは異なるＧＵＩフレームワークを実現することができる。Ｊａｖａ（登録商標）アプリケーションにおけるＧＵＩフレームワークは、ＧＥＭ１．０．２にて規定されたＨＡＶｉ（ＨｏｍｅＡｕｄｉｏ／Ｖｉｄｅｏｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）フレームワークを含み、ＧＥＭ１．０．２におけるリモートコントロールナビゲーション機構を含む。

これにより、Ｊａｖａ（登録商標）アプリケーションは、ＨＡＶｉフレームワークに基づくボタン表示、テキスト表示、オンライン表示（ＢＢＳの内容）といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるＢＤＭＶディレクトリ配下のＢＤＪＡディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）である。以降、Ｊａｖａ（登録商標）アーカイブファイルについて、図１６を参照しながら説明する。

＜Ｊａｖａ（登録商標）アーカイブファイル＞
Ｊａｖａ（登録商標）アーカイブファイル（図２の００００１．ｊａｒ，００００２．ｊａｒ）は、１つ以上のクラスファイル、１つ以上のデータファイル等を１つにまとめることで得られるファイルであり、ＢＤ−Ｊモードにおいて動作すべきＪａｖａ（登録商標）アプリケーションを構成する。
図１６は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるプログラム、データは、枠内に示すディレクトリ構造が配置された複数ファイルを、ｊａｖａ（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Ｒｏｏｔディレクトリ、Ｊａｖａ（登録商標）１，２，３ディレクトリ、Ｉｍａｇｅ１，２，３ディレクトリとからなり、Ｒｏｏｔディレクトリにｃｏｍｍｏｎ．ｐｋｇが、Ｊａｖａ（登録商標）１，Ｊａｖａ（登録商標）２，Ｊａｖａ（登録商標）３ディレクトリにクラスファイル（００００１．ｃｌａｓｓ〜００００７．ｃｌａｓｓ）が、Ｉｍａｇｅ１，Ｉｍａｇｅ２，Ｉｍａｇｅ３ディレクトリに、００００１．ＪＰＥＧ〜００００３．ＪＰＥＧ、００００４．ＰＮＧ〜００００６．ＰＮＧが配置されている。ｊａｖａ（登録商標）アーカイブファイルは、これらをｊａｖａ（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａ（登録商標）アーカイブファイルのファイル名における″ｚｚｚｚｚ″という５桁の数値は、アプリケーションのＩＤ（ａｐｐｌｉｃａｔｉｏｎＩＤ）を示す。本Ｊａｖａ（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のＪａｖａ（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。

尚、本実施形態においてアプリケーションを構成するプログラム、データは、Ｊａｖａ（登録商標）アーカイブファイルにまとめられたが、ＬＺＨファイル、ｚｉｐファイルであってもよい。
以上が、ＢＤ−Ｊモードにおける動的シナリオについての説明である。
＜Ｉｎｄｅｘ．ｂｄｍｖ＞
Ｉｎｄｅｘ．ｂｄｍｖは、タイトルを構成する、ＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−ＪＯｂｊｅｃｔを示すテーブルである。

Ｔｉｔｌｅにおいて、あるＴｉｔｌｅの構成要素となるＭｏｖｉｅＯｂｊｅｃｔはどれであるか、又は、あるＴｉｔｌｅの構成要素となるＢＤ−ＪＯｂｊｅｃｔはどれであるのかを定義する。
Ｉｎｄｅｘ．ｂｄｍｖについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報ＷＯ２００４／０２５６５１Ａ１公報
以降、図１５に示したアプリケーション管理テーブル、プレイリスト管理テーブルのそれぞれについてより詳しく説明する。

＜アプリケーション管理テーブル＞
アプリケーション管理テーブル（ＡＭＴ）について説明する。アプリケーション管理テーブル（ＡＭＴ）とは、上述したＧＥＭ１．０．２ｆｏｒｐａｃｋａｇｅｍｅｄｉａｔａｒｇｅｔｓにおける“アプリケーションシグナリング”を実装するテーブルである。“アプリケーションシグナリング”とは、ＧＥＭ１．０．２が規定するＭＨＰ（ＭｕｌｔｉｍｅｄｉａＨｏｍｅＰｌａｔｆｏｒｍ）において、“サービス”を生存区間としてアプリケーションの起動、実行を行う制御をいう。本実施形態におけるアプリケーション管理テーブルは、この“サービス”の代わりに、ＢＤ−ＲＯＭにおける“タイトル”を生存区間にして、アプリケーションの起動、実行の制御を実現する。

図１７（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『ｌｉｆｅ＿ｃｙｃｌｅ』と、『ａｐｌｉ＿ｉｄ＿ｒｅｆ』と、『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』と、『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』からなる。
図１７（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。

『ｌｉｆｅ＿ｃｙｃｌｅ』は、アプリケーションの”生存区間”を示す。
『ａｐｌｉ＿ｉｄ＿ｒｅｆ』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Ｊａｖａ（登録商標）アーカイブファイルにおいて、ファイル名として付与された５桁の数値ｚｚｚｚｚで表現される。『ａｐｌｉ＿ｉｄ＿ｒｅｆ』には、この５桁の数値が記述される。

『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、ＡｕｔｏＲｕｎ、Ｐｒｅｓｅｎｔ、Ｓｕｓｐｅｄといった種別がある。
『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。ＢＤ−ＪＯｂｊｅｃｔでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
ここでアプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。

生存区間とは、ＢＤ−ＲＯＭに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するｘｌｅｔプログラムが、Ｊａｖａ（登録商標）仮想マシン内のワークメモリに読み出され、Ｊａｖａ（登録商標）仮想マシンによる実行が可能になっている状態をいう。
Ｊａｖａ（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。

一方、ＤＶＤ−Ｖｉｄｅｏのような読出専用ディスクで供給されるディスクコンテンツは、トップメニュータイトルを中核とした構造になっている。そのトップメニュータイトルから、個々の著作物へと分岐して再生を行い、その後再び、トップメニュータイトルに戻るという独特の状態遷移をなす。図１８は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Ｔｉｔｌｅである。Ｔｉｔｌｅとは、ディスクコンテンツ特有の状態遷移において、１つの”状態”にあたる再生単位であり、このタイトルが、Ｊａｖａ（登録商標）アプリケーションの生存区間として取り扱われる。

Ｔｉｔｌｅには、ＢＤ−ＲＯＭのローディング時に最初に再生される『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』、Ｔｏｐ−Ｍｅｎｕを構成する『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』、これら以外の一般的な『Ｔｉｔｌｅ』がある。また、図中の矢印ｊｈ１，２，３，４，５，６，７，８は、Ｔｉｔｌｅ間の分岐を象徴的に示す。本図に示される状態遷移とは、ＢＤ−ＲＯＭローディング時に、『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』が再生され、『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』への分岐が発生して、トップメニューに対する選択待ちになるというものである。

トップメニューに対する選択操作がユーザによりなされれば、選択に従って該当Ｔｉｔｌｅの再生を行い、再びＴｏｐＭｅｎｕＴｉｔｌｅに戻るとの処理を、ＢＤ−ＲＯＭのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
それでは、図１８のような状態遷移をなすディスクコンテンツにおいて、Ｔｉｔｌｅは、どのように生存区間として規定されるのであろうか。ＢＤ−ＲＯＭのローディングがなされた後、図１８において矢印ｊｈ１，２，３，４・・・・・に示された参照符号の数値順に分岐がなされ、ＢＤ−ＲＯＭがイジェクトされたものとする。そうすると、ＢＤ−ＲＯＭがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図１９（ａ）は、ディスク全体の時間軸を示す図であり、図１９（ｂ）は、この時間軸における構成を示す。図１９（ｂ）に示すように、ディスク全体の時間軸は、ＦｉｒｓｔＰｌａｙＴｉｔｌｅが再生されている区間、ＴｏｐＭｅｎｕＴｉｔｌｅが再生されている区間、ｔｉｔｌｅ＃１が再生されている区間等からなる。これらＴｉｔｌｅの再生区間はどのように規定されているかというと、Ｔｉｔｌｅは、唯一のＢＤ−ＪＯｂｊｅｃｔから構成されるから、どれかのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−ＪＯｂｊｅｃｔが、有効になっている期間をＴｉｔｌｅの再生区間と考えることができる。

つまりＦｉｒｓｔＰｌａｙＴｉｔｌｅ、ＴｏｐＭｅｎｕＴｉｔｌｅ、その他のＴｉｔｌｅは、何れも動的シナリオから構成されるから、Ｔｉｔｌｅを構成するＢＤ−ＪＯｂｊｅｃｔのうち、どれかカレントＢＤ−ＪＯｂｊｅｃｔとしてＡｃｔｉｖａｔｅｄされ、再生装置内において解読・実行に供されている期間を、Ｔｉｔｌｅの再生区間と定義することができる。図２０（ａ）は、ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−ＪＯｂｊｅｃｔから特定されるタイトル再生区間を示す図である。ここで識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−ＪＯｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−ＪＯｂｊｅｃｔが有効になっているＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。

ここでＢＤ−ＪＯｂｊｅｃｔがＡｃｔｉｖａｔｅされている期間の終期は、Ｔｉｔｌｅ分岐がなされるまでである。つまり、Ｔｉｔｌｅ分岐がなされるまで、実行の対象になっている動的シナリオは、カレントＢＤ−ＪＯｂｊｅｃｔとして扱われるから、そのＢＤ−ＪＯｂｊｅｃｔにおいてＪｕｍｐＴｉｔｌｅが発生するまでの１つの区間を、Ｔｉｔｌｅ区間として扱う。
続いてＴｉｔｌｅ区間と、ＰＬ時間軸との関係について説明する。上述したようにＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−ＪＯｂｊｅｃｔでは、１つの処理手順としてプレイリスト再生手順を記述することができる。プレイリスト再生手順の記述があれば、上述したＰＬ時間軸の全部又は一部がＴｉｔｌｅ区間に帰属することになる。図２０（ａ）の一例においてＢＤ−ＪＯｂｊｅｃｔに、プレイリスト管理テーブルが記述されているとする。この場合、ＢＤ−ＪＯｂｊｅｃｔに対応するＴｉｔｌｅ区間には、図２０（ｂ）に示すように、ＰＬ時間軸が帰属する。このＰＬ時間軸には更に、複数チャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義され得るため、ＢＤ−ＲＯＭ上の時間軸には、ＢＤ−ＲＯＭ全体−Ｔｉｔｌｅ−プレイリスト−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Ｔｉｔｌｅ分岐が発生することがある。この場合、１つのＴｉｔｌｅ再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり１つのＴｉｔｌｅの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Ｔｉｔｌｅ分岐が何時発生するかによって変わる。

図２１は、図２０（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Ｔｉｔｌｅを生存区間にした”タイトルバウンダリアプリケーション”、Ｔｉｔｌｅ内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、ＢＤ−ＲＯＭ全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という３つの典型がある。

このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。
プラットフォームが動作していたとしても、Ｔｉｔｌｅやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。

近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル（ｔｉｔｌｅ＃１）、オンラインショッピングを構成するオンラインショッピングタイトル（ｔｉｔｌｅ＃２）、ゲームアプリケーションを構成するゲームタイトル（ｔｉｔｌｅ＃３）という、性格が異なる３つのタイトルを含むものである。図２２は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはＩｎｄｅｘ．ｂｄｍｖを記述しており、左側には３つのタイトルを記述している。

右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。３つのタイトルのうちｔｉｔｌｅ＃１は、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３という３つのアプリケーションからなる。ｔｉｔｌｅ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３、ａｐｐｌｉｃａｔｉｏｎ＃４という２つのアプリケーション、ｔｉｔｌｅ＃３は、ａｐｐｌｉｃａｔｉｏｎ＃５を含む。図２２の一例においてａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２の双方で起動される。

図２２の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２３（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃４は、ｔｉｔｌｅ＃２のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃２内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃５は、ｔｉｔｌｅ＃３のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃３内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１及びｔｉｔｌｅ＃２に帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、ｔｉｔｌｅ＃１，＃２，＃３のアプリケーション管理テーブルは図２３（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、ｔｉｔｌｅ＃１の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３をワークメモリにロードしておく。そしてｔｉｔｌｅ＃２の開始時にａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をワークメモリから削除してａｐｐｌｉｃａｔｉｏｎ＃３のみにするという制御を行う。これと同様にｔｉｔｌｅ＃２の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃４をワークメモリにロードしておき、ｔｉｔｌｅ＃３の開始時にａｐｐｌｉｃａｔｉｏｎ＃３，＃４をワークメモリから削除するという制御を行いうる。

更に、ｔｉｔｌｅ＃３の再生中においてａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリにロードしておき、ｔｉｔｌｅ＃３の再生終了時にａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。

続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「ＡｕｔｏＲｕｎ」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Ｐｒｅｓｅｎｔ」、仮想マシンのワークメモリにはおかれるが、ＣＰＵパワーの割り当ては不可となる「Ｓｕｓｐｅｎｄ」がある。
「ＡｕｔｏＲｕｎ」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて生存しており、かつ起動属性がＡｕｔｏＲｕｎに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。

起動属性「Ｐｒｅｓｅｎｔ」は、継続属性であり、分岐元ｔｉｔｌｅにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Ｐｒｅｓｅｎｔ」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから呼出があると、そのアプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤが、アプリケーション管理テーブルに記述されていて、起動属性が「Ｐｒｅｓｅｎｔ」であるか否かを判定する。「Ｐｒｅｓｅｎｔ」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Ｐｒｅｓｅｎｔ」が付与されたアプリケーションに限られることになる。「Ｐｒｅｓｅｎｔ」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのＰｒｅｓｅｎｔであることを意味する。

「Ｓｕｓｐｅｎｄ」とは、リソースは割り付けられているが、ＣＰＵパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるＳｕｓｐｅｎｄは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２４は、起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。

直前状態が”非起動”であり、起動属性が”Ｐｒｅｓｅｎｔ”、”Ｓｕｓｐｅｎｄ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Ｐｒｅｓｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。

起動属性が”Ｓｕｓｐｅｎｄ”であるなら、アプリケーションの状態はＳｕｓｐｅｎｄされることになる。直前状態が”Ｓｕｓｐｅｎｄ”である場合、分岐先タイトルの起動属性が”Ｓｕｓｐｅｎｄ”ならＳｕｓｐｅｎｄを維持することになる。”Ｐｒｅｓｅｎｔ”又は”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。

尚、直前状態が”Ｓｕｓｐｅｎｄ”であり、分岐先タイトルの起動属性が”Ｐｒｅｓｅｎｔ”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、０〜２５５の値をとり、メモリリソース枯渇時や、ＣＰＵ負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。

また起動優先度は、再生中プレイリストに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中プレイリストのポーズを行う。

以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブル（ＰＬＭＴ）について説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のＦａｉｌＳａｆｅ機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくＡＶＣｌｉｐ再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。

チャプターバウンダリアプリケーションは、１つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、１つ以上のＴｉｔｌｅからなる生存区間に定義されることになる。
図２５（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『ＰＬ＿ｉｄ＿ｒｅｆ』と、『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』とからなる。

図２５（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『ＰＬ＿ｉｄ＿ｒｅｆ』は、プレイリスト識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるプレイリストがどれであるかを示す。プレイリスト識別子は、ファイルＹＹＹＹＹ．ＭＰＬＳにおいて、ファイル名として付与された５桁の数値ＹＹＹＹＹで表現される。このＹＹＹＹＹが記述されることにより、『ＰＬ＿ｉｄ＿ｒｅｆ』は、対応するＴｉｔｌｅにおいて再生可能となるプレイリストがどれであるかを示す。

『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『ＰＬ＿ｉｄ＿ｒｅｆ』に記述されたプレイリストを、タイトル開始時において、どのように再生するかを規定する再生属性である。プレイリストに対する再生属性には、『ＡｕｔｏＰｌａｙ』、『Ｐｒｅｓｅｎｔ』といった種別がある。
『ＡｕｔｏＰｌａｙ』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がＡｕｔｏＰｌａｙに設定されたプレイリストの再生を開始する。これにより起動属性がＡｕｔｏＰｌａｙに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。

『Ｐｒｅｓｅｎｔ』とは、起動属性におけるＰｒｅｓｅｎｔ同様、継続属性であり、分岐元ｔｉｔｌｅにおけるプレイリストの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される２つのＴｉｔｌｅがあり、前のタイトル側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がＡｕｔｏＰｌａｙに設定され、カレントタイトル側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がＰｒｅｓｅｎｔに設定されているものとする。ここでプレイリストの再生時間が２時間長であり、このうち１時間が経過した時点で分岐が発生したとする。この場合カレントタイトルでは、再生属性がＰｒｅｓｅｎｔに設定されているので、カレントタイトルにおいて、そのプレイリストは、１時間という再生済み区間の直後から、再生されることになる。このように再生属性をＰｒｅｓｅｎｔに設定しておけば、Ｔｉｔｌｅ間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のＴｉｔｌｅにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもＰｒｅｓｅｎｔにしておけば、複数のうちどれに分岐したとしても、１つの共通のプレイリスト再生を継続させることができる。

尚Ｔｉｔｌｅの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Ｔｉｔｌｅ間で１つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Ｐｒｅｓｅｎｔ」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆが、プレイリスト管理テーブルに記述されていて、再生属性が「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかか否かを判定する。「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかが付与されたプレイリストに限られることになる。「Ｐｒｅｓｅｎｔ」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのＰｒｅｓｅｎｔであることを意味する。

図２６は、プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。図２６の第１段目は、Ｔｉｔｌｅの再生映像を示し、第２段目は、Ｔｉｔｌｅの時間軸を示す。第３段目はＰＬＭＴにより再生が規定されるプレイリスト、第４段目は、アプリケーション実行を示す。第４段目においてａｐｐｌｉｃａｔｉｏｎ＃１は、Ｔｉｔｌｅの開始と共に起動されており、その後、時点ｔ１において動作状態になる。一方ＰｌａｙＬｉｓｔ＃１は、Ｔｉｔｌｅの開始と共に再生が開始されている。Ｐｌａｙｌｉｓｔ＃１の再生は、Ｔｉｔｌｅの開始と同じ時点に開始されているので、第１段目の左側に示すように、Ｔｉｔｌｅの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像ｇｊ１がフルスクリーン表示される。プレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておくことにより、Ｊａｖａ（登録商標）アプリケーションが動作状態になるまで５〜１０秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。

一方、ａｐｐｌｉｃａｔｉｏｎ＃１は、時点ｔ１で動作状態になるので、プレイリスト再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像ｇｊ２が時点ｔ１において表示されることになる。アプリケーションの実行画像は、Ｓｔａｒｔボタン，ｃｏｎｔｉｎｕｅボタン、ＰＯＷＥＲインディケータを配置したゲーム用のＧＵＩフレームワークであり、かかるＧＵＩフレームワークの描画処理をＪａｖａ（登録商標）アプリケーションが実行することでなされる。

こうした、プレイリストの再生映像と、Ｊａｖａ（登録商標）アプリケーションのＧＵＩフレームワークとを組み合わせた再生映像をなすタイトルを構成することができるのが、ＰＬＭＴの特徴である。
図２７は、カレントタイトルがとり得る三態様（プレイリスト管理テーブル無し（ｉ）、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ（ｉｉ）、プレイリスト管理テーブル有りで尚且つ無指定（ｉｉｉ））と、直前タイトルにおけるプレイリストの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。

本図における６通りの組合せのうち、”直前状態＝非再生状態”と、”カレントタイトル＝プレイリスト管理テーブル有り、尚且つ、カレントタイトルの再生属性＝ＡｕｔｏＰｌａｙ”との組合せにおいて、分岐先タイトルにおけるプレイリストの再生は、自動的に開始することになる。
また”直前状態＝再生中状態”と、”カレントタイトル＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのプレイリストの再生は、自動的に停止することになる。

そしてこれら２つの組合せ以外は全て、前のタイトルの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてＡｕｔｏＰｌａｙ属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。

プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２８（ａ）を参照しながら説明する。ここで想定する具体例は、２つの連続するＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）であり、そのうちｔｉｔｌｅ＃１では、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。ｔｉｔｌｅ＃２ではＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。一方、ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述されているものとする。図２８（ｂ）は、図２８（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。

ｔｉｔｌｅ＃１においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が自動的に起動され、ＰｌａｙＬｉｓｔ＃１の再生が自動的に開始される。
ｔｉｔｌｅ＃２においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１側に記載はあるが、ｔｉｔｌｅ＃２側には記載がないａｐｐｌｉｃａｔｉｏｎ＃１の実行は停止させられる。同じくｔｉｔｌｅ＃１側に記載があるが、ｔｉｔｌｅ＃２側に記載がないＰｌａｙＬｉｓｔ＃１の再生も停止させられる。

ｔｉｔｌｅ＃１側に記載はないが、ｔｉｔｌｅ＃２側に記載があるＰｌａｙＬｉｓｔ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。

また図２８では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３にはそれぞれ２００，１２８，２００の起動優先度が与えられている。これらの起動優先度を付与することにより、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２に対する制御要求が競合した場合の調停を行わせることができる。ここでａｐｐｌｉｃａｔｉｏｎ＃１がＰｌａｙＬｉｓｔ＃１に対し早送りを命じているものとする。一方、ａｐｐｌｉｃａｔｉｏｎ＃２がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、ａｐｐｌｉｃａｔｉｏｎ＃２による要求を退け、ａｐｐｌｉｃａｔｉｏｎ＃１による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。

プレイリスト管理テーブル記述の他の具体例について説明する。図２９（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、２つの連続するタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）において、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述され、ｔｉｔｌｅ＃１側のアプリケーション管理テーブルには、ＡｕｔｏＰｌａｙアプリケーションであるａｐｐｌｉｃａｔｉｏｎ＃１と、実行可能なアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。一方ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述され、アプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。図２９（ｂ）は、図２９（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１が自動起動される。一方、ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、実行可能アプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１からの呼出ｙｄ１によりａｐｐｌｉｃａｔｉｏｎ＃２が起動される。

ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が非生存になっており、代わりにＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。そのためｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２の境界部では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２を停止し、ａｐｐｌｉｃａｔｉｏｎ＃３を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルは、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２が再生可能と記述されており、そのうちＰｌａｙＬｉｓｔ＃１はＡｕｔｏＰｌａｙ属性になっている。そのためＰｌａｙＬｉｓｔ＃１は、ｔｉｔｌｅ＃１の開始時において自動的に再生される。

ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＰｌａｙＬｉｓｔ＃１の他、ＰｌａｙＬｉｓｔ＃２が再生可能であると記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１はＰｌａｙＬｉｓｔ＃１の再生を停止させ、代わりにＰｌａｙＬｉｓｔ＃２の再生を要求することにより、プレイリスト交代を実行することができる。
ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そしてＡｕｔｏＰｌａｙ属性が付与されたプレイリストはない。そのため、仮にｔｉｔｌｅ＃１開始時において自動再生されたＰｌａｙＬｉｓｔ＃１の再生がｔｉｔｌｅ＃２まで継続したとしても、ＰｌａｙＬｉｓｔ＃１の再生は自動的に終了することになる。

しかしＰｌａｙＬｉｓｔ＃２再生が継続したままｔｉｔｌｅ＃２に至れば、ＰｌａｙＬｉｓｔ＃２再生はｔｉｔｌｅ＃２開始以降も継続する。ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そのため、ｔｉｔｌｅ＃２で実行中となるａｐｐｌｉｃａｔｉｏｎ＃３は、ＰｌａｙＬｉｓｔ＃２の再生を停止し、代わりにＰｌａｙＬｉｓｔ＃３の再生を要求することにより、再生中のプレイリストを交代させることができる。

以上のようにプレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておけば、Ｊａｖａ（登録商標）アプリケーションの起動に、５〜１０秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。

アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
＜動作＞
次に、本実施の形態の再生装置１００のＢＤ−ＲＯＭ１１０をロードして動画が再生されたり、メニュー表示されるまでの動作を図３０に示すフローチャートを用いて説明する。当該動作はアプリケーションマネージャ３７による処理でもある。

図３０に示すように、まず、Ｔｉｔｌｅｊｕｍｐがなされたかどうかを判定する（ステップＳ１）。
Ｔｉｔｌｅｊｕｍｐがあった場合（ステップＳ１のＹＥＳ）には、タイトル切替を実行し（ステップＳ７）、次にカレントタイトルに対応するＢＤ−ＪＯｂｊｅｃｔにＰＬＭＴが存在するかどうかをみる（ステップＳ８）。

ＰＬＭＴが存在する場合には（ステップＳ８のＹＥＳ）、前のタイトルではＰＬＭＴに記載されていなかったが、カレントタイトルではＰＬＭＴに記載されており、ＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生を開始する。ＰＬＭＴが存在しなかった場合には（ステップＳ８のＮＯ）、前タイトルではＰＬＭＴに記載されていたが、カレントタイトルではＰＬＭＴに記載されていないＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生を停止する。

次に、カレントタイトルに対応するアプリケーション管理テーブルがあるかどうかを判断する（ステップＳ１１）。
アプリケーション管理テーブルがあった場合（ステップＳ１１のＹＥＳ）には、前タイトルを生存区間としていないが、カレントタイトルを生存区間としているＪａｖａ（登録商標）アプリケーションのうち、ＡｕｔｏＲｕｎ属性を付与されているアプリケーションを起動する。アプリケーション管理テーブルがなかった場合（ステップＳ１１のＮＯ）には、前タイトルを生存区間としているがカレントタイトルを生存区間としていないアプリケーションを終了する。

続いて、アプリケーションの起動に成功したかどうかを判断する（ステップＳ１４）。アプリの起動に成功していた場合（ステップＳ１４のＹＥＳ）には、ビデオプレーン５及びビデオプレーン制御部１７に対してＡｕｔｏＰｌａｙ属性を付与されているプレイリストの再生画像のクォーター化の指示を実行する。また、当該指示を受けたＳｔｉｌｌプレーン制御部１７は、Ｓｔｉｌｌプレーン１６からのスチルデータの出力を実行する（ステップＳ１５）。そしてテレビ１３０にはＳｔｉｌｌプレーン１６のスチルデータも合成された画像が表示される。アプリケーションの起動に失敗した場合（ステップＳ１４のＮＯ）には、ステップＳ２３に移行して以降の処理を実行する。

ＴｉｔｌｅＪｕｍｐが発生しなかった場合（ステップＳ１のＮＯ）には、メインアプリが終了しているかどうかを検出する（ステップＳ２）。
メインとなるアプリケーションが終了していた場合（ステップＳ２のＹＥＳ）には、当該アプリケーションが正常に終了したかどうかを判断する（ステップＳ５）。正常に終了していた場合（ステップＳ５のＹＥＳ）には、ステップＳ１に戻り、以降の処理を実行する。

メインとなるアプリケーションが異常終了していた場合（ステップＳ５のＮＯ）には、ＡｕｔｏＰｌａｙＰＬの再生中であったかどうかをみる（ステップＳ２１）。再生中であった場合（ステップＳ２１のＹＥＳ）には、ＣＰＵ２５は、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン化するようにビデオプレーン５のデータをフルスクリーンサイズで出力させる。また、Ｓｔｉｌｌプレーン制御部１７に、対しても同じ指示をだし、当該指示を受けてＳｔｉｌｌプレーン制御部１７は、Ｓｔｉｌｌプレーン１６に格納されているスチルデータの出力を抑止する（ステップＳ２２）。そしてテレビ１３０には、スチルデータが合成されていない合成画像が表示される。

そして再起動カウンタが０であるかどうかを判定する（ステップＳ２３）。ここで再起動カウンタとはアプリケーションの再起動回数を規定するための制御変数である。再起動カウンタが０である場合（ステップＳ２３のＹＥＳ）にはステップＳ１に戻り、以降の処理を実行する。再起動カウンタが０でなかった場合（ステップＳ２３のＮＯ）には、再起動カウンタをデクリメントしてステップＳ１２に移行して以降の処理を実行する。ステップＳ２３、Ｓ２４の手順を踏むことでアプリケーションの起動を保証する。なお再起動カウンタは本フローチャートの起動時においてリセットされる。

メインとなるアプリケーションが終了していなかった場合（ステップＳ２のＮＯ）には、次に、ＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生が終了しているかどうかを判断する（ステップＳ３）。ＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生が終了していた場合（ステップＳ３のＹＥＳ）には、ステップＳ１に戻り以降の処理を実行する。ＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生が終了していなかった場合（ステップＳ３のＮＯ）には、ＢＤドライバ１にＢＤ−ＲＯＭがあるかどうかを検出する（ステップＳ４）。

ＢＤドライバ１にまだＢＤ−ＲＯＭが存在する場合（ステップＳ４のＹＥＳ）には、ステップＳ１に戻り以降の処理を実行する。ＢＤドライバ１にＢＤ−ＲＯＭが存在しない場合（ステップＳ４のＮＯ）には、全アプリケーションの終了指示を実行し（ステップＳ６）、終了する。
以上が、ＢＤ−ＲＯＭ１１０が再生装置１００に装着されてから取り出されるまでの動作である。ここに述べたように、再生画像がフルスクリーンの場合と、クォータの場合とで、Ｓｔｉｌｌプレーン１６からのデータの出力の可否を決定する。フルスクリーンの場合においては、Ｓｔｉｌｌプレーン１６のデータの合成は必要ないため出力せず、こうすることでＳｔｉｌｌプレーン１６の読み出しに用いられるメモリバスバンド幅を開けることができる。
＜実施の形態２＞
次に本発明に係る実施の形態２について図面を参照しながら説明する。

実施の形態２においては、ＢＤアプリケーションにおいて、より豊かなインタラクティブ性を実現するためにＪａｖａ（登録商標）のようなプログラミング環境を導入すると伴に、Ｓｔｉｌｌプレーン又はＰＧプレーンからのデータの出力を制御することでメモリバスバンド幅を有効活用する内容を示す。基本的には実施の形態１に基づく内容であり、拡張または異なる部分についての説明を行う。
＜再生装置１００のハードウェア構成＞
再生装置１００については、実施の形態１と異なり更に、ＰＧプレーン制御部２８が追加されている。ここではＰＧプレーン制御部２８の機能について説明する。その他の各部については、実施の形態１に示したものと変わらない。

ＰＧプレーン制御部２８は、ＰＧプレーン１４からのデータの出力を制御する機能を有する。具体的には、ＣＰＵ２５からビデオプレーン５に対するスケーリング指示を受けて、当該スケーリング指示がテレビ１３０の全体への表示指示であるフルスケーリングである場合に、ＰＧプレーン１４からのデータを出力させる。そしてスケーリング指示がフルスケーリングの１／４であるクォータスケーリングである場合に、ＰＧプレーン１４からのデータの読み出しを抑制する。
＜動作＞
図３２は、実施の形態２においてアプリケーションの要求に基づいて、ＰＧプレーン１４並びにＳｔｉｌｌプレーン１６からのデータの出力制御を行うことを示したフローチャートである。

図３２に示すように、まずアプリケーションからビデオスケーリングを要求されてＣＰＵ２５はビデオプロセッサ（図示せず）へビデオスケーリングを指示する（ステップＳ１０１）。
次いで、ビデオプロセッサは、ビデオスケーリングが成功したかどうかをＣＰＵ２５に通知する（ステップＳ１０２）。ビデオスケーリングが成功した場合（ステップＳ１０２のＹＥＳ）には、当該スケーリング指示が、テレビ１３０の表示画面全体への表示指示であるフルスケーリング指示であるかどうかを判定する（ステップＳ１０３）。

フルスケーリング指示であった場合（ステップＳ１０３のＹＥＳ）には、ＣＰＵ２５は、Ｓｔｉｌｌプレーン制御部１７に対してＳｔｉｌｌプレーン１６からのデータの出力を抑制するように指示する（ステップＳ１０４）。また、ＣＰＵ２５は、ＰＧプレーン制御部２８に対してＰＧプレーン１４からのデータの出力を実行するように指示し（ステップＳ１０６）、終了する。

フルスケーリング指示でなかった場合（ステップＳ１０３のＮＯ）、即ちビデオスケーリングの指示がフルスケーリングの１／４であるクォータスケーリングであった場合には、ＣＰＵ２５は、Ｓｔｉｌｌプレーン制御部１７に対してＳｔｉｌｌプレーン１６からのデータの出力を実行するように指示する（ステップＳ１０５）。また、ＣＰＵ２５は、ＰＧプレーン制御部２８に対してＰＧプレーン１４からのデータの出力を抑制するよう指示し（ステップＳ１０７）、終了する。

なお、ステップＳ１０２において、ビデオスケーリングに失敗していた場合（ステップＳ１０２のＮＯ）においても、本フローチャートを終了する。
以上のようにアプリケーションによる全画面へのビデオスケーリングが成功した場合には、Ｓｔｉｌｌプレーン１６からのデータの読み出しを抑制し、ＰＧプレーン１４からのデータの読み出しを実行することができる。またアプリケーションによる全画面の１／４サイズへのビデオスケーリングが成功した場合には、Ｓｔｉｌｌプレーン１６からのデータの読み出しを実行し、ＰＧプレーン１４からのデータの読み出しを抑制することができる。

ＰＧプレーン１４に関してもここに示したようにビデオスケーリングに基づく読み出しの制御を行い、ビデオスケーリングがクォータスケーリングである場合にはデータの出力を抑制することで、当該出力に用いるはずだったメモリバスバンド幅を空けることができる。
＜実施の形態３＞
実施の形態１においてはＳｔｉｌｌプレーン１６の出力制御を行い、Ｓｔｉｌｌプレーン１６のデータの出力が必要ない場合にはメモリバスバンド幅をその分だけ開けることができることを示した。

実施の形態３においては、メモリバスバンド幅並びにメモリ領域を有効活用できる別の手法を示す。ここでは実施の形態１とは異なる部分についてのみ記述する。
実施の形態１及び２に示したようにＳｔｉｌｌプレーン１６からのデータの出力はビデオスケーリングがフルスケールの場合にはＳｔｉｌｌプレーン１６からのデータの出力を抑制し、ビデオスケーリングがクォータサイズの場合にはＳｔｉｌｌプレーン１６からのデータの出力を実行する。

また、ＰＧプレーン１４に関してもビデオスケーリングに基づく出力制御を実行することを実施の形態２において記述した。上述したようにＰＧプレーン１４に関しては、Ｓｔｉｌｌプレーン１６の場合とは逆にビデオスケーリングがフルスケールの場合においてはデータの出力を実行し、ビデオスケーリングがクォータサイズの場合においてはデータの出力を抑制する。

つまり、ＰＧプレーン１４並びにＳｔｉｌｌプレーン１６からのデータの出力に関しては排他的であるといえ、一方が出力を実行しているともう一方は出力を実行しない構成になる。
よって実施の形態３においては、実施の形態１とは異なり、ＰＧプレーン１６とＳｔｉｌｌプレーン１６とで使用するメモリ領域を共有する。この場合、アプリケーションからのビデオスケーリングに関する指示がフルスケールである場合には、当該メモリ領域は、ＰＧプレーン１４用のメモリ領域として使用される。そしてビデオスケーリングに関する指示がクォータサイズである場合には、当該メモリ領域はＳｔｉｌｌプレーン１６として用いる。具体的には、ＰＧプレーン１４とＳｔｉｌｌプレーン１６とはメモリの同じアドレスの領域を共有することになる。

こうすることで実質的に１つ分のプレーンのメモリ領域を開けることができ、そのメモリ領域を他の用途に用いることができる。例えば、Ｓｔｉｌｌプレーン１６に表示するはずＪＰＥＧデータを圧縮した状態で格納しておき、Ｓｔｉｌｌプレーン１６からのデータの出力が必要な場合には、圧縮しておいたＪＰＥＧデータを展開してＳｔｉｌｌプレーンに書き込む構成にしてもよい。

また、データの読み出しの際についても実質的にアクセスするメモリ領域がプレーン一つ分減っているのと同じであり、メモリバスバンド幅もその分だけ空くことになると言える。
＜補足＞
上記実施の形態に基づいて本発明に係る再生装置に関して説明してきたが、本発明の実施の形態は上述のものに限るものではない。以下、その変形例について説明していく。

（１）上記実施の形態においては再生装置をＢＤ−ＲＯＭ再生装置として説明してきたが、これは特にＢＤ−ＲＯＭ再生装置に限定するものではなく、ＤＶＤプレーヤなどであってもよい。
（２）上記実施の形態においてはＳｔｉｌｌプレーン制御部１７はビデオプレーンのスケール変更がなされるかどうかに基づいてＳｔｉｌｌプレーンからのスチルデータの読み出しを行うかどうかを判断していたが、字幕データを格納するためのＰＧプレーンに合成すべきデータがあるかどうかによって判断しても良い。

字幕データは、基本的にフルスクリーン表示を行うときのためのフォントサイズでＢＤ−ＲＯＭ１１０に記憶されており、スケールを変更して縮小した場合に字がつぶれてしまうことがあるため、ＰＧプレーンを合成する場合には必ず、フルスクリーンでの表示が行われる。よって、Ｓｔｉｌｌプレーン制御部１７は、ＰＧプレーンがある場合にはフルスクリーンでの表示が行われると判断し、このときには、Ｓｔｉｌｌプレーンからのスチルデータの読み出しを行わないようにしてもよい。

（３）上記実施の形態１においては、動画像がフルスクリーン表示の場合には、Ｓｔｉｌｌプレーンの読み出しに用いられる予定であったメモリバスバンド幅があくことを記載した。このあいたメモリバスバンド幅は当然にその他の用途に用いられて良い。
例えば、Ｓｔｉｌｌプレーンの読み出しに換えて、ビデオプレーンへの動画用の画像データの書き込みに用いたり、あるいは、ＩＧプレーンへのＧＵＩ画像の書き込みの用いたりすることも可能である。当該構成を備えることにより、再生装置は書き込みと読み出しのサイクルを早めることができると言え、テレビでの画像の表示の遅延をなるべく抑えることができるようになる。

（４）上記実施の形態においては、ビデオストリームは、ＢＤ−ＲＯＭ規格のＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−ＶｉｄｅｏＲｅｃｏｒｄｉｎｇ規格のＶＯＢ（ＶｉｄｅｏＯＢｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、ｄｔｓ方式であってもよい。

（５）上記実施の形態においては、ＭＰＥＧ４−ＡＶＣ（Ｈ．２６４やＪＶＴとも呼ばれる）をもとに説明したが、ＭＰＥＧ２ビデオストリームであってもよく、また、その他の形式（ＶＣ−１等）の画像の場合でも単独でデコード可能な画像であれば、容易に応用可能である。
（６）上記実施の形態においては、ビデオプレーンが、フルスクリーンの場合についてのみＳｔｉｌｌプレーンを合成しないこととしたが、これはＳｔｉｌｌプレーンとビデオプレーンが共に通常フルスクリーンサイズで用意されるからである。しかし、ビデオプレーン及びＳｔｉｌｌプレーンが共にフルスクリーンサイズでなくとも、ビデオプレーンのデータが、Ｓｔｉｌｌプレーンのデータの全てを覆い隠すならば、Ｓｔｉｌｌプレーンの合成を実行しない構成にしてもよい。

（７）上記実施の形態においては、ビデオプレーン、即ち動画のスケーリングを行う際にフルスケールにするかクォータにするかによってＳｔｉｌｌプレーン１６からのデータの出力を制御したが、ビデオスケーリング時でなくともＳｔｉｌｌプレーン１６からのデータの出力制御を行ってもよい。
この場合、アプリケーションにＳｔｉｌｌプレーン制御部１７に対してのデータの出力の抑制あるいは実行の機能を持たせる。こうすることで、ビデオスケーリング時のみならず、Ｓｔｉｌｌプレーン１６からのデータの出力制御を実行することができるようになる。

また、実施の形態２において、ＰＧプレーン１４からのデータの出力制御に関してもビデオスケーリング時だけでなく、アプリケーションにＰＧプレーン制御部２８に対しての出力の制御あるいは実行の機能を持たせてもよい。こうすることでビデオスケーリング時のみならず、ＰＧプレーン１４からのデータの出力制御を実行することができるようになる。

（８）上記実施の形態においては、Ｓｔｉｌｌプレーン１６のデータの出力制御をアプリケーションの指示に基づく形で行ったが、ＢＤ−ＲＯＭにスチルデータの出力制御に関するフラグを持たせ、当該フラグに基づく出力制御を行ってもよい。
（９）上記実施の形態においては、ＰＧプレーン１４には、字幕のみを格納することとしたが、字幕の画像データだけでなく、ビデオプレーンに格納されている動画とは別の動画を格納してもよい。こうすると、例えば表示画面を２つの領域に分割してそれぞれ別の動画を表示できるようになる。

（１０）本発明は、上記実施の形態において示したＳｔｉｌｌプレーンのスチルデータの合成制御に示す方法であってもよく、当該方法に示される処理手順を再生装置のコンピュータに実行させるコンピュータプログラムであってもよい。また、当該コンピュータプログラムは、フレキシブルディスク、ハードディスク、ＣＤ（ＣｏｍｐａｃｔＤｉｓｃ）、ＭＯ（ＭａｇｎｅｔｏＯｐｔｉｃａｌｄｉｓｃ）、ＤＶＤ、ＢＤ、半導体メモリなどに記録されたものであってもよい。

（１１）上記実施の形態において再生装置１００は、システムＬＳＩによって実現するとしたが、再生装置１００の各機能は、複数のＬＳＩによって実現されても良い。

本発明に係る再生装置は、ＢＤ−ＲＯＭからデータを読み出しアプリケーションを実行しながら画像を再生装置において表示の遅延がない再生装置として活用することができる。

近年ＤＶＤ（Digital Versatile Disc）プレーヤ、ＢＤ（Blu-ray Disc）プレーヤなどの映像再生装置が開発されている。これらのプレーヤでは、ＤＶＤ、ＢＤなどの記録媒体から動画ストリームデータを読み出して動画を再生することができる。このとき動画を再生しながら、記録媒体に記録されているアプリケーションを実行することもあり、動画とは別にアプリケーションに関連する画像も表示することがある。例えば、動画の横位置に動画に係るメニューＧＵＩ（GraphicalUser Interface）などの表示、あるいは字幕の表示などがこれにあたる。

このとき、プレーヤは動画と、アプリケーションにより表示制御される画像とを合成して表示すべき画像データを生成してディスプレイに表示させている。この合成される基となるデータは逐次、記録媒体から読み出され、一旦プレーヤのメモリのそれぞれ対応する領域に書き込まれる。そしてプレーヤは、そのメモリから画像データを読み出し、合成して出力するということを行っている。ここで、プレーヤのメモリのそれぞれに対応する領域とは、メモリにおいて、動画の画像データを格納するビデオプレーン、動画と共に表示するＧＵＩメニューの画像データを格納するIG（InteractiveGraphics）プレーンなどのことである。プレーヤは画像を合成する際には各プレーンにアクセスする必要がある。

ところで上述したようにプレーヤはプレーンへの書き込みと読み出しを行っているが、メモリへの書き込みと読み出しに用いるメモリバスは、コストや設置スペースの問題から共有化されている。例えばＨＤ画質（１９２０×１０８０ピクセル）の画像を表示しようとする場合において、動画像の書き込みにおいて用いるメモリバスバンド幅は、２B/ピクセル、３０fpsとすると約１２０MB/sec（１９２０×１０８０×２×３０）、読み出しの場合にも同様に約１２０MB/secの性能を要求されることになる。また、背景画像の書き込みや読み出しについては夫々約１２０MB/sec、ＧＵＩなどのメニューなどのグラフィックスの書き込みや読み出しについては、４B/ピクセル、３０fpsとすると夫々約２４０MB/sec（１９２０×１０８０×４×３０）のメモリバスバンド幅を要求される。また、字幕がある場合には、このデータもメモリに書き込んで読み出す必要があり、やはり夫々約１２０MB/secのメモリバス幅を要求される。動画再生時には、読み出しと書き込みが平行して行われるので、これらのプレーンの画像データを合成するために２GB/sec近くの帯域が必要となってくる。これからも画質の高品質化によって更なるメモリバスバンド幅が必要となることが見込まれているが、同時にこれはプレーヤの低価格化を妨げる一要因にもなっている。

上述したようなＨＤ画質の場合において、再生装置が背景画像の読み出しに用いる１２０MB/sec分のメモリバスバンド幅を、例えば動画の書き込みに用いれば動画の書き込みの速度が倍になると言え、読み出し時に動画のデータが書き込まれておらず読出しができなかったために動画の再生が遅延するといった事態を防げる。
また、前記所定のサイズとは前記動画像が表示画面においてフルスクリーンで表示されるサイズのことであり、前記再生装置は更に、前記動画像に係るアプリケーションを実行する仮想マシン部を備え、前記合成出力手段は、前記アプリケーションの前記ビデオプレーンに対する縮小指示を受けて、前記背景画像を合成し、縮小指示がない場合には、前記背景画像を合成しないこととしてよい。

図１に示すように、再生装置１００は、BD-ROM１１０を装着してBD-ROM１１０に記録されている動画を再生して、有線若しくは無線で接続しているテレビ１３０に表示させる。また、再生装置１００は、BD-ROM１１０に記録されているJava（登録商標）アプリケーションを実行し、当該アプリケーションに基づく画像も表示させる。
ユーザ操作を受けるためにリモコン１２０があり、当該リモコン１３０には、再生装置１００を制御するための各種キーが搭載されている。この各種キーには、再生開始(Play)、再生停止(Stop)、一時停止(PauseOn)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(BackwardPlay(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(AngleChange)を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付けるMoveUpキー、MoveDownキー、MoveRightキー、MoveLeftキー、メニュー表示操作を受け付けるPop-upキー、数値入力を受け付けるNumericキーが含まれる。

以上が、本発明に係る再生装置１００の使用行為の形態についての説明である。
＜再生装置１００のハードウェア構成＞
次に、図２を用いて、再生装置１００の機能構成について説明する。
本発明に係る再生装置１００は、本図に示す内部構成に基づき、工業的に生産される。本発明に係る再生装置１００は、主としてシステムLSI（Large ScaleIntegration）と、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置１００は、BD-ROMドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、サウンドプロセッサ６、サウンドプロセッサ７、ミキサー８、サウンドコントローラ９、D/Aコンバータ１０、InteractiveGraphicsデコーダ１１、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、PresentationGraphicsプレーン１４、JPEGデコーダ１５、Stillプレーン１６、Stillプレーン制御部１７、合成部１８ａ、１８ｂ、１８ｃ、ＳＴＣ−ＤＥＬＴＡ付加部１９、ＡＴＣ−ＤＥＬＴＡ付加部２０、ローカルストレージ２１、命令ＲＯＭ２２、ユーザイベント処理部２３、ＰＳＲセット２４、ＣＰＵ２５、シナリオメモリ２６、ローカルメモリ２７を含んで構成される。

BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する機能を有する。
リードバッファ２は、FIFO（First In First Out）メモリであり、BD-ROMから読み出されたTSパケットを順に格納した先に格納されたパケットから順次出力する機能を有する。
デマルチプレクサ(De-MUX)３は、リードバッファ２からSourceパケットを取り出して、このSourceパケットを構成するTSパケットをPESパケットに変換する機能を有する。そして変換により得られたPESパケットのうち、STN_Tableに記載されたものの中からPID（PacketIDentifier）をもつものをビデオデコーダ４、オーディオデコーダ６、Interactive Graphicsデコーダ１１、PresentationGraphicsデコーダ１３のいずれかに出力する機能も有する。Sourceパケット及び、STN_Tableの詳細に関しては後述する。

ビデオデコーダ４は、デマルチプレクサ３から出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む機能を有する。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置１００において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーンはビデオでコーダによって書き込まれたデータを格納し出力する機能を有する。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の1/4(クオータという)、1/1(フルスケールという)のどちらかに変化させることである。かかるスケーリングを、BD-JモードにおいてＣＰＵ２５からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。

サウンドプロセッサ６は、オーディオストリームを構成するPESパケットをPIDフィルタ３が出力した際、このPESパケットを格納しておく機能を有するオーディオバッファ６aと、このバッファに格納されたPESパケットをデコーダして、PCM（PulseCode Modulation）状態のオーディオデータを出力する機能を有するオーディオデコーダ６ｂとを含む。
サウンドプロセッサ７は、BD-ROMから読み出されたファイルsound.bdmvをプリロードしておく機能を有するプリロードバッファ７aと、プリロードされたファイルsound.bdmvにおける複数のサウンドデータのうち、ＣＰＵ２５により指示されたものをデコードして、PCM状態のオーディオデータを出力する機能を有するオーディオデコーダ７bとを含む。プリロードバッファ７aへのプリロードは、BD-ROMの装填時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、AVClip再生が途切れないことを、保証することができる。

サウンドミキサ８は、サウンドプロセッサ６、及び、サウンドプロセッサ７から出力されるPCM状態のサウンドデータをミキシングする機能を有する。
サウンドコントローラ９は、サウンドミキサ８から出力された展開された状態のオーディオデータ、及び、サウンドプロセッサ６を介さずに圧縮された状態のオーディオデータのうち、どちらを出力するか切り換える機能を有する。圧縮された状態のオーディオデータを出力する場合は、その出力先の機器(テレビ)においてデコードされる。

D/A変換部１０は、サウンドミキサ８から出力されるディジタルのオーディオデータをD/A変換して、アナログ音声を出力する機能を有する。
I-Graphicsデコーダ(IGデコーダ)１１は、BD-ROM又はローカルストレージ２１から読み出されたIGストリームをデコードして、非圧縮グラフィクスをInteractiveGraphicsプレーン１２に書き込む機能を有する。

Interactive Graphics(IG)プレーン１２には、HDMVモードにおいてI-Graphicsデコーダ１１によるデコードで得られた非圧縮グラフィクスが書き込まれる。またBD-Jモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
P-Graphicsデコーダ１３は、BD-ROM又はローカルストレージ２１から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentationGraphics（PG）プレーン１１に書き込む機能を有する。P-Graphicsデコーダ１３によってデコードされ、Prensentation Graphicsプレーン１１に書き込まれたデータが合成されることにより字幕が画面上に現れることになる。

Presentation Graphicsプレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
JPEGデコーダ１５は、BD-ROM又はローカルストレージ２１に記録されているJPEGデータをデコードして、Stillプレーン１６に書き込む機能を有する。
Stillプレーン１６は、JPEGデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Java（登録商標）アプリが描画する、GUIフレームワークのいわゆる“壁紙”として用いられる。

Still プレーン制御部１７は、Still プレーン１６からのデータの出力を制御する機能を有する。具体的には、ＣＰＵ２５からVideo プレーン５に対するスケーリング指示を受けて、当該スケーリング指示がテレビ１３０の全体への表示指示であるフルスケールスケーリングである場合に、Stillプレーン１６からのデータの読み出しを抑止する。そして、スケーリング指示がフルスケールの1/4であるクォータスケーリングである場合には、Still プレーン１６から合成部１８ｃに対して格納しているスチルデータを出力させる。

合成部１８ａ、ｂ、ｃは、Interactive Graphicsプレーン１２に格納されているデータと、Presentation Graphicsプレーン１１に格納されているデータと、ビデオプレーン５に格納されているデータと、Stillプレーン１６に格納されているデータとを夫々合成し、得られた合成画像の画像信号を出力する機能を有する。なお、プレーンから画像信号が出力されなかった場合には合成せずに出力されてきた信号をそのまま出力する。

STC_delta付加部１８は、STC（System Time Clock）を生成する機能を有する。そしてSTC_Sequenceの切り換わり時において、それまでのSTC_SequenceにおけるSTC値(STC1)に、STC_deltaと呼ばれるオフセット値を加算することにより、新しいSTC_SequenceのSTC値(STC2)を求めて、それまでのSTC_SequenceにおけるSTC値(STC1)と、新しいSTC_SequenceのSTC値(STC2)とを連続した値にする。

先行STC_Sequenceにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STC_Sequenceにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、STC_deltaは、

STC_delta＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)

として表現される。以上のようにSTC_deltaを求め、これが足し合わされたクロックの計数値を各デコーダに出力する。これにより各デコーダは、2つのSTC_Sequenceにあたるストリームを途切れなく再生してゆくことができる。以上のにより、1つのAVClipの中に、2以上のSTC_Sequenceが存在したとしても、また、連続して再生されるべき2以上のAVClipのそれぞれが、異なるSTC_Sequenceをもっていたとしても、これらのSTC_Sequence間のデコード処理を、シームレスに実行することができる。

なお、バッファリングの連続性をみたすには、以下の条件1）、2）を満たせば良い。

1) STC2(2ndSTART)＞STC2(1stEND)をみたすこと。
2) TS1からのTSパケットの取り出しと、TS2からのTSパケットの取り出しとが、同じ時間軸に投影されたSTC1と、STC2とにより定義され、バッファのアンダーフローや、オーバーフローをもたらさないこと。

なお、１）においてSTC2(1stEND)は、STC1(1stEND)を、STC2の時間軸に投影した値であり、STC2(1stEND)=STC1(1stEND)-STC_deltaという計算式で与えられる。
ATC_delta付加部１９は、ATC（Arrival Time Clock）を生成する機能を有する。そしてATC_Sequenceの切り換わり時において、それまでのATC_SequenceにおけるATC値(ATC1)に、ATC_deltaと呼ばれるオフセット値を加算することにより、それまでのATC_SequenceにおけるATC値(ATC1)と、新しいATC_SequenceのATC値(ATC2)とを連続した値にする。この加算により、ATC2=ATC1+ATC_deltaになる。ATC_deltaとは、これまで読み出されているトランスポートストリーム(TS1)の最後のTSパケットの入力時点T1から、新たに読み出されたトランスポートストリーム(TS2)の最初のTSパケットの入力時点T2までのオフセット値をいい、“ATC_delta≧N1/TS_recording_rate”という計算式で与えられる。ここで入力時点T2は、TS2の最初のTSパケットの入力時点を、TS1の時間軸上に投影した時点を意味する。またN1は、TS1の最後のビデオPESパケットに後続する、TSパケットのパケット数である。BD-ROMにおいてかかるATC_deltaは、Clip情報に記述されるので、これを用いることにより、ATC_deltaを計算することができる。以上の計算により、これまでのATC_SequenceがもっているATC値(ATC1)と、新たなATC_SequenceがもっているATC値(ATC2)とを、連続した値にすることができる。ATC_deltaが足し合わされたクロックの計数値をデマルチプレクサ(De-MUX)３に出力することで、シームレスなバッファ制御を実現することができる。

以上がAVClipの再生に係る構成要素である。続いてBD-Jモードでの動作に係る構成要素(ローカルストレージ２１〜ローカルメモリ２７)について説明する。
ローカルストレージ２１は、webサイトからダウンロードされたコンテンツ等、BD-ROM以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておく機能を有するハードディスクである。このメタデータは、ダウンロードコンテンツをローカルストレージ２１にバインドして管理するための情報であり、このローカルストレージ２１をアクセスすることで、BD-Jモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。

続いて、再生装置における統合制御を実現する構成要素(命令ＲＯＭ２２〜ローカルメモリ２６)について説明する。
命令ＲＯＭ２２は、再生装置の制御を規定するソフトウェアを記憶している。
ユーザイベント処理部２３は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをＣＰＵ２５に出力する。

ＰＳＲ（Player Status Register）セット２４は、再生装置に内蔵されるレジスタであり、64個のPSRと、4096個のGPR（GeneralPurpose Register）とからなる。Player Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
PSR4は、1〜100の値に設定されることで、現在の再生時点が属するタイトルを示し、0に設定されることで、現在の再生時点がトップメニューであることを示す。

PSR5は、1〜999の値に設定されることで、現在の再生時点が属するチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、現在の再生時点が属するプレイリスト(カレントPL)の番号を示す。

PSR7は、0〜255の値に設定されることで、現在の再生時点が属するPlayItem(カレントPlay Item)の番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM(PresentationTiMe))を示す。以上のPSR4〜PSR8により、図１８（ａ）におけるBD-ROM全体の時間軸において、現在の再生時点はどこであるかを特定することができる。

ＣＰＵ２５は、命令ＲＯＭ２２に格納されているソフトウェアを実行して、再生装置全体の制御を実行する機能を有する。この制御の内容は、ユーザイベント処理部２３から出力されたユーザイベント、及び、ＰＳＲセット２４における各PSRの設定値に応じて動的に変化する。
シナリオメモリ２６は、カレントのPL情報やカレントのClip情報を格納しておく機能を有するメモリである。カレントPL情報とは、BD-ROMに記録されている複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROMに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。

ローカルメモリ２７は、BD-ROMからの読み出しは低速である故、BD-ROMの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２７が存在することにより、BD-Jモードにおけるアプリケーション実行は、効率化されることになる。
以上が、本実施形態に係る再生装置のハードウェア構成である。
＜再生装置１００のソフトウェア構成＞
続いて本実施形態に係る再生装置のソフトウェア構成について説明する。

図３には、ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のa),b),c)からなる。つまり、
a)BD Player Deviceの第１階層、
b)BD Player Modelの第２階層、
c)Application Runtime Enviromentの第３階層からなる。

これらの階層のうち図３に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”BD Player Device”には、図２に示したハードウェア構成のうちビデオデコーダ４、I-Graphicsデコーダ１１、オーディオデコーダ６等にあたる”デコーダ”と、ビデオプレーン５、InteractiveGraphicsプレーン１２等にあたる”プレーン”、BD-ROM１１０及びそのファイルシステム、ローカルストレージ２１及びそのファイルシステムを含む。

第２階層”BD Player Model”は、以下のb1),b2)の層からなる。つまり、
b1)Virtual File System３０及びPresentation Engine３１の層
b2)Playback Control Engine３２の層
からなり、自身より上位の階層に対し、ファンクションAPIを提供する。
第３階層”Application Runtime Enviroment”は、以下のc1),c2)の階層からなる。つまり、
c1)モジュールマネージャ３４が存在する層、
c2)BD-Jプラットフォーム３５が存在する層
からなる。

先ず初めに、第２層に属するVirtual File System３０〜モジュールマネージャ３４について説明する。
Virtual File System３０は、ローカルストレージ２１に格納されたダウンロードコンテンツを、BD-ROMにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージ２１に格納されたダウンロードコンテンツは、SubClip、Clip情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はBD-ROM及びローカルストレージ２１のどちらに存在するClip情報であっても、指定できる点で、BD-ROM上のプレイリスト情報と異なる。この指定にあたって、VirtualFile System３０上のプレイリスト情報は、BD-ROMやローカルストレージ２１におけるファイルをフルパスで指定する必要はない。BD-ROM上のファイルシステムやローカルストレージ２１上のファイルシステムは、仮想的な1つのファイルシステム(VirtualFile System３０)として、認識されるからである。故に、PlayItem情報におけるClip_Information_file_nameは、Clip情報の格納したファイルのファイルボデイにあたる5桁の数値を指定することにより、VirtualFile System３０、BD-ROM上のAVClipを指定することができる。Virtual File System３０を介してローカルストレージ２１の記録内容を読み出し、BD-ROMの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージ２１と、BD-ROMとを組合せてなるディスクコンテンツは、BD-ROMにおけるディスクコンテンツと対等に扱われるので、本発明においてBD-ROMには、ローカルストレージ２１＋BD-ROMの組合せからなる仮想的な記録媒体をも含むことにする。

Presentation Engine３１は、AV再生ファンクションを実行する。再生装置のAV再生ファンクションとは、DVDプレーヤ、CDプレーヤから踏襲した伝統的な機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(PauseOn)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(BackwardPlay(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(AngleChange)といった機能である。AV再生ファンクションを実現するべく、Presentation Engine３１は、リードバッファ２上に読み出されたAVClipのうち、所望時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、P-Graphicsデコーダ１３、I-Graphicsデコーダ１０、オーディオデコーダ６を制御する。所望の時刻としてPSR8(カレントPTM)に示される箇所のデコードを行わせることにより、AVClipにおいて、任意の時点を再生を可能することができる。

再生制御エンジン(Playback Control Engine(PCE))３２は、プレイリストに対する再生制御ファンクション(i)、PSRセット２３における状態取得／設定ファンクション(ii)といった諸機能を実行する。プレイリストに対する再生制御ファンクションとは、PresentationEngine３１が行うAV再生ファンクションのうち、再生開始や再生停止を、カレントPL情報及びClip情報に従って行わせることをいう。これらの機能(i)、(ii)は、HDMVモジュール３３〜BD-Jプラットフォーム３５からのファンクションコールに応じて実行する。

モジュールマネージャ３４は、BD-ROMから読み出されたIndex.bdmvを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにTerminateイベントを発行し、分岐先タイトルを構成する動的シナリオにActivateイベントを発行することでなされる。
以上がPresentation Engine３１〜モジュールマネージャ３４についての説明である。続いてBD-Jプラットフォーム３５について説明する。

BD-Jプラットフォーム３５は、いわゆるJava（登録商標）プラットフォームであり、Java（登録商標）仮想マシン３６を中核にした構成になっている。BD-Jプラットフォーム３５は、上述したJava（登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM[1.0.2])for package media targetsに加え、BD-J Extentionを実装している。BD-JExtentionは、GEM[1.0.2]を越えた機能を、BD-Jプラットフォームに与えるために特化された、様々なパッケージを含んでいる。

先ず初めに、BD-Jプラットフォーム３５の中核となるJava（登録商標）仮想マシン３６について説明する。
＜Java（登録商標）仮想マシン３６＞
図４は、Java（登録商標）仮想マシン３６の内部構成を示す図である。本図に示すようにJava（登録商標）仮想マシン３６は、図３３に示したCPU２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５a,b・・・n、Java（登録商標）スタック５６a,b・・・nとから構成される。

ユーザクラスローダ５２は、BDJAディレクトリのJava（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３７がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがVirtualFile System３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、BD-ROM又はローカルストレージ２０からワークメモリ５４に読み出す。アプリケーションの起動制御は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３７に通知することになる。

メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２７から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３に示したアプリケーションマネージャ３７は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するxletプログラムである。かかるxletプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。

図３のレイアモデルでは、このワークメモリ５４上のアプリケーションマネージャ３７を、Java（登録商標）仮想マシン３６上に描いていたが、これはわかり易すさを意図した配慮に過ぎない。アプリケーションマネージャ３７及びアプリケーションはインスタンスとしてスレッド５５a,b・・・nにより実行されるというのが、現実的な記述になる。
スレッド５５a,b・・・nは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ky1,ky2,kynは、ワークメモリ５４からスレッド５５a,b・・・nへのメソッド供給を象徴的に示している。物理的な実行主体がCPU唯1つであるのに対し、論理的な実行主体たるスレッドは、最大64個Java（登録商標）仮想マシン３６内に存在し得る。この64個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Java（登録商標）仮想マシン３６の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより1つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではCPU２４と、スレッドとの対応関係は、1対多の関係にしているが、CPUが複数ある場合、CPUとスレッドとの対応関係は多対多の関係になりうる。スレッド５５a,b・・・nによるメソッド実行は、メソッドをなすバイトコードを、CPU２４のネイティブコードに変換した上、CPU２４に発行することでなされる。

Java（登録商標）スタック５６a,b・・・nは、スレッド５５a,b・・・nと1対1の比率で存在しており、プログラムカウンタ(図中のPC)と、1つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する1回のコールに対して割り当てられたスタック式の領域であり、その1回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック(図中のローカル変数)”とからなる。フレームは、コールが1回なされる度にJava（登録商標）スタック５６a,b・・・n上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、1つ積み上げられることになる。

以上がJava（登録商標）仮想マシンについての説明である。
＜アプリケーションマネージャ３７＞
続いてアプリケーションマネージャ３７について、説明する。アプリケーションマネージャ３７は、Java（登録商標）仮想マシン３６内のワークメモリ上で動作するシステムソフトウェアであり、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではAutoRunの起動属性を有するアプリケーションを起動するようJava（登録商標）仮想マシン３６に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントBD-JObjectにおけるアプリケーション管理テーブルを参照した上でなされる。
＜BD-ROMの構成＞
次にBD-ROM１１０に記録されているデータに関して説明する。

まず、図５を用いてBD-ROM１１０のデータのファイルディレクトリ構造について説明する。
図５に示すように、BD-ROM１１０には、Rootディレクトリの下に、BDMVディレクトリがある。
BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDBJディレクトリ、BDJAディレクトリ、AUXDATAディレクトリと呼ばれる6つのサブディレクトリが存在する。

PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls,00003mpls)がある。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts)がある。

BDBJディレクトリには、拡張子BOBJが付与されたファイル(00001.BOBJ,00002.bobj,00003.bobj)が存在する。
BDJAディレクトリには、拡張子jarが付与されたファイル(00001.jar,00002.jar,00003.jar)がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。

AUXDATAディレクトリには、ファイルsound.bdmvが格納される。
＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図６は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示した図である。拡張子.m2tsが付与されたファイル(00001.m2ts、00002.m2ts、00003.m2ts・・・・・)は、AVClipを格納している。AVClipはMPEG2-TransportStream形式のデジタルストリームである。このデジタルストリームは、フィルム映像、NTSC（National Television StandardsCommittee）映像、PAL（Phase Alternation by Line）処理をデジタル化することにより得られたデジタルビデオ、LPCM（LinearPulse Code Modulation）音源、AC-3音源、DTS（Digital Surround）音源をデジタル化することにより得られたデジタルオーディオを(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１段目)を、PESパケット列に変換し(下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。

PGストリームとは、動画の再生進行に伴った字幕表示を実現するエレメンタリストリームであり、IGストリームは、動画の再生進行に伴ったGUIを実現するエレメンタリストリームである。これらIGストリーム、及びPGストリームについては、本発明の主眼ではないので、説明を省略する。
ビデオストリームのうち、1つのPTSで再生される再生単位(ピクチャ等)を、“Video Presentation Unit”という。オーディオストリームのうち、1つのPTSで再生される再生単位を、“AudioPresentation Unit”という。

ここでAVClipを構成するPESパケットは、1つ以上の“STC_Sequence”を構成する。“STC_Sequence”とは、PESパケットの配列であって、そのPTS、DTSが参照しているSystemTime Clock(STC)の値に、STC不連続点(system time-base discontinuity)が存在しないものをいう。STC不連続点がないことがSTC_Sequenceの要件であるので、1つのSTC_Sequenceを構成するPESパケット列のうち、STC不連続点の直後に位置するPESパケットであって、PCR(ProgramClock Reference)を包含したものから、次のSTC不連続点の直前までが1つのSTC_Sequenceになる。

＜Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi・・・・・)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図７は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、
i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』
を含んで構成される。

Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,PCRが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。

Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramSequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSDTV（StandardDefinition TeleVision）からHDTV（High-Definition TeleVision）に変化している点等をいう。

続いてCharacteristic Point Infoについて説明する。図７中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP_map_for_one_stream_PID(EP_map_for_one_stream_PID(0)〜EP_map_for_one_stream_PID(Ne-1))からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、1つのエレメンタリストリーム上において、AccessUnit Delimiterが存在するエントリー位置のパケット番号(SPN_EP_start)を、エントリー時刻(PTS_EP_start)と対応づけて示す情報である。図中の引き出し線cu3は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。

同図からEP_map_for_one_stream_PIDは、Nc個のEP_High(EP_High(0)〜EP_High(Nc-1))と、Nf個のEP_Low(EP_Low(0)〜EP_Low(Nf-1))とが含まれることがわかる。ここでEP_Highは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。

図７中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN_EP_High[i]』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。

図７中の引き出し線cu5は、EP_Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point(EP_Low_id)』と、対応するAccessUnitのサイズを示す『I_end_position_offset(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS_EP_Low(EP_Low_id)』と、対応するAccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN_EP_Low(EP_Low_id)』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。

＜Clip情報の説明その２.EP_map＞
以下、具体例を通じて、EP_mapについて説明する。図８は、映画のビデオストリームに対するEP_map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたBピクチャ、IDRピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP_mapの設定を示す。

第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t1〜t7をエントリー時刻(PTS_EP_start)として示し、これに対応づけてエントリー位置(SPN_EP_start)を示すよう、設定される。
＜PlayList情報＞
続いて、PlayList情報について説明する。拡張子“mpls”が付与されたファイル(00001.mpls)は、PlayList(PL)情報を格納したファイルである。PlayList情報は、MainPathと呼ばれる再生経路と、これに対応する再生情報とをプレイリスト(PL)として定義する情報である。

図９は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())とからなる。
MainPathとは、主たるAVClip上に定義される再生経路である。一方Subpathは、SubClip上に定義される再生経路である。ここでSubClipとは、動画像たるビデオストリームを含まないAVClipである。

＜PlayList情報の説明その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
MainPathは、矢印mp1で示すように複数のPlayItem情報#1・・・・#mから定義される。PlayItem情報は、MainPathを構成する1つ以上の論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVClipの符号化方式を示す『Clip_codec_identifier』と、再生区間の始点を示す時間情報『IN_time』と、再生区間の終点を示す時間情報『OUT_time』と、『STN_table』とから構成される。

図１０は、AVClipと、PlayList情報との関係を示す図である。第1段目は、PlayList情報がもつ時間軸を示す。第2段目から第5段目は、EP_mapにて参照されているビデオストリーム(図６に示したものと同じ)を示す。
PlayList情報は、PlayItem情報#1,#2という2つのPlayItem情報を含んでおり、これらPlayItem情報#1,#2のIn_time,Out_timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayItem時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる時間軸の定義が可能になる。

＜STN_table＞
STN_tableは、Play ItemのClip_Information_file_nameで指定されているAVClipに多重化された複数エレメンタリストリームのうち、再生可能なものを示すテーブルである。具体的にいうとSTN_tableは、複数エレメンタリストリームのそれぞれについてのentryを、attributeと対応付けることで構成される。

図１１は、STN_tableの内部構成を示す図である。本図に示すようにSTN_tableは、STN_tableにおけるentryと、attributeとの組み(entry-attribute)を複数含み、これらentry−attributeの組みの個数(number_of_video_stream_entries,number_of_audio_stream_entries,number_of_PG_textST_stream_entries,number_of_IG_stream_entries)を示すデータ構造になっている。

entry-attributeの組みは、図中の括弧記号“｛”に示すように、Play Itemにおいて再生可能なビデオストリーム、オーディオストリーム、PG_textST_stream、IGストリームのそれぞれに対応している。
entry−attributeの詳細について説明する。図１１は、entry−attributeの詳細を示す図である。

図１２（ａ）は、ビデオストリームに対応したentry−attributeの組みを示す図である。
ビデオストリームにおけるentryは、AVClipを多重分離するにあたって、当該ビデオストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。
ビデオストリームにおけるattributeは、0x02に設定された『stream_coding_type』と、ビデオストリームの表示レートを示す『Frame_rate』等を含む。

図１２（ｂ）は、オーディオストリームに対応したentry−attributeの組みを示す図である。
オーディオストリームにおけるentryは、AVClipを多重分離するにあたって、当該オーディオストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。

オーディオストリームにおけるattributeは、0x80(LinearPCM),0x81(AC-3),0x82(DTS)の何れかに設定されることによりオーディオストリームのコーデイングタイプを示す『stream_coding_type』と、対応するオーディオストリームのチャネル構成を示し、マルチチャネル出力の可否を示す『audio_presentation_type』と、対応するオーディオストリームの言語属性を示す『audio_languagecode』等からなる。

マルチチャネルには、5.1CHのサラウンド音声の他、ステレオ音声も含まれるが、以降の説明では、マルチチャネルは、5.1CHのサラウンド音声のみを意味するとして説明を進める。
図１２（ｃ）は、PGストリームに対応したentry−attributeの組みを示す図である。
PGストリームにおけるentryは、AVClipを多重分離するにあたって、当該PGストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。

PGストリームにおけるattributeは、0x90に設定されることによりPGストリームのコーディックを示す『stream_coding_type』と、対応するPGストリームの言語属性を示す『PG_languagecode』とからなる。
図１２（ｄ）は、IGストリームに対応したentry−attributeの組みを示す図である。
IGストリームにおけるentryは、AVClipを多重分離するにあたって、当該IGストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。

IGストリームにおけるattributeは、0x91に設定されることによりIGストリームのコーディックを示す『stream_coding_type』と、対応するIGストリームの言語属性を示す『languagecode』とからなる。
＜PlayList情報の説明その２.PlayListMark＞
以上が、本実施形態に係るPlayItem情報についての説明である。続いてPlayListMark情報について説明する。

図１３は、PlayList情報の、PlayListMark情報の内部構成を示す図である。本図の図中の引き出し線pm0に示すように、PlayListMark情報は、複数のPLMark情報(#1〜#n)からなる。PLmark情報(PLmark())は、PL時間軸のうち、任意の区間を、チャプター点として指定する情報である。引き出し線pm1に示すようにPLmark情報は、チャプター指定の対象たるPlayItemを示す『ref_to_PlayItem_Id』と、そのPlayItemにおける、チャプター位置を時間表記により示す『mark_time_stamp』とを含む。

図１４は、PlayList情報の、PLMark情報によるチャプター位置の指定を示す図である。本図の第2段目から第5段目は、図１０に示した、EP_mapと、AVClipとを示す。
本図の第1段目は、PLMark情報と、PL時間軸とを示す。この第1段目には、2つのPLMark情報#1〜#2が存在する。矢印kt1,2は、PLMark情報のref_to_PlayItem_Idによる指定を示す。この矢印からもわかるように、PLMark情報のref_to_PlayItem_Idは、PlayItem情報のそれぞれを指定していることがわかる。また、Mark_time_Stampは、PlayItem時間軸のうち、Chapter#1,#2になるべき時点を示す。このように、PLMark情報は、PlayItem時間軸上に、チャプター点を定義することができる。

AVClip−SubClipを同期させ得る同期区間の定義を可能とするのが、BD-ROMにおけるプレイリスト情報の特徴である。以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。

続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java（登録商標）仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovieObjectと呼ばれる。一方BD-Jモードを想定した動的シナリオはBD-J Objectと呼ばれる。

先ず初めにMovie Objectについて説明する。
＜Movie Object＞
Movie Objectは、図５に示したMovieObject.bdmvというファイルに格納され、ナビゲーションコマンド列を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。
１）PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきプレイリストを指定することができる。第２引数は、そのプレイリストに含まれるPlayItemや、そのプレイリストにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。

PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。
２）JMPコマンド
書式：JMP 引数
JMPコマンドは、現在の動的シナリオを途中で廃棄し(discard)、引数たる分岐先動的シナリオを実行するという分岐である。JMP命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。

Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。MovieObjectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。

国際公開公報W0 2004/074976

以上でMovie Objectについての説明を終える。続いてBD-J Objectについて説明する。
＜BD-J Object＞
BD-J Objectは、Java（登録商標）プログラミング環境で記述された、BD-Jモードの動的シナリオであり、00001〜00003.bobjというファイルに格納される。

図１５は、BD-J Objectの内部構成を示す図である。アプリケーション管理テーブル(AMT)、プレイリスト管理テーブル(PLMT)とを含んで構成される。MovieObjectとの違いは、BD-J Objectにコマンドが直接記述されていない点である。つまりMovie Objectにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-JObjectでは、Java（登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。

またMovieObjectにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド(PlayPlコマンド)の記述によりなされるが、BD-JObjectにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをBD-J Objectに組み込むことで記述が可能になる。
このBD-JモードにおけるJava（登録商標）アプリケーションについて説明する。ここでBD-Jモードが想定しているJava（登録商標）プラットフォームは、Java（登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM1.0.2)for package media targetsとをフル実装したものである。

このBD-JモードにおけるJava（登録商標）アプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destroyed”といった4つの状態をもつ。
上述したJava（登録商標）プラットフォームは、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードJava（登録商標）ライブラリを含む。このため、Java（登録商標）アプリケーションは、HDMVモードにおいてIGストリームにより実現されるGUIとは異なるGUIフレームワークを実現することができる。Java（登録商標）アプリケーションにおけるGUIフレームワークは、GEM1.0.2にて規定されたHAVi（HomeAudio/Video interoperability）フレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含む。

これにより、Java（登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このJava（登録商標）アプリケーションの実体にあたるのが、図２におけるBDMVディレクトリ配下のBDJAディレクトリに格納されたJava（登録商標）アーカイブファイル(00001.jar,00002.jar)である。以降、Java（登録商標）アーカイブファイルについて、図１６を参照しながら説明する。

＜Java（登録商標）アーカイブファイル＞
Java（登録商標）アーカイブファイル(図２の00001.jar,00002.jar)は、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルであり、BD-Jモードにおいて動作すべきJava（登録商標）アプリケーションを構成する。
図１６は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるプログラム、データは、枠内に示すディレクトリ構造が配置された複数ファイルを、java（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Rootディレクトリ、Java（登録商標）1,2,3ディレクトリ、Image1,2,3ディレクトリとからなり、Rootディレクトリにcommon.pkgが、Java（登録商標）1,Java（登録商標）2,Java（登録商標）3ディレクトリにクラスファイル(00001.class〜00007.class)が、Image1,Image2,Image3ディレクトリに、00001.JPEG〜00003.JPEG、00004.PNG〜00006.PNGが配置されている。java（登録商標）アーカイブファイルは、これらをjava（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、BD-ROMからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Java（登録商標）アーカイブファイルのファイル名における"zzzzz"という5桁の数値は、アプリケーションのID(applicationID)を示す。本Java（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のJava（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。

尚、本実施形態においてアプリケーションを構成するプログラム、データは、Java（登録商標）アーカイブファイルにまとめられたが、LZHファイル、zipファイルであってもよい。
以上が、BD-Jモードにおける動的シナリオについての説明である。
＜Index.bdmv＞
Index.bdmvは、タイトルを構成する、Movie Object又はBD-J Objectを示すテーブルである。

Titleにおいて、あるTitleの構成要素となるMovieObjectはどれであるか、又は、あるTitleの構成要素となるBD-J Objectはどれであるのかを定義する。
Index.bdmvについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。

国際公開公報WO 2004/025651 A1公報

以降、図１５に示したアプリケーション管理テーブル、プレイリスト管理テーブルのそれぞれについてより詳しく説明する。

＜アプリケーション管理テーブル＞
アプリケーション管理テーブル(AMT)について説明する。アプリケーション管理テーブル(AMT)とは、上述したGEM1.0.2for packagemedia targetsにおける“アプリケーションシグナリング”を実装するテーブルである。“アプリケーションシグナリング”とは、GEM1.0.2が規定するMHP(MultimediaHome Platform)において、“サービス”を生存区間としてアプリケーションの起動、実行を行う制御をいう。本実施形態におけるアプリケーション管理テーブルは、この“サービス”の代わりに、BD-ROMにおける“タイトル”を生存区間にして、アプリケーションの起動、実行の制御を実現する。

図１７（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『life_cycle』と、『apli_id_ref』と、『run_attribute』と、『run_priority』からなる。
図１７（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。

『life_cycle』は、アプリケーションの”生存区間”を示す。
『apli_id_ref』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Java（登録商標）アーカイブファイルにおいて、ファイル名として付与された5桁の数値zzzzzで表現される。『apli_id_ref』には、この5桁の数値が記述される。

『run_attribute』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、AutoRun、Present、Suspedといった種別がある。
『run_priority』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。BD-J Objectでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
ここでアプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。

生存区間とは、BD-ROMに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するxletプログラムが、Java（登録商標）仮想マシン内のワークメモリに読み出され、Java（登録商標）仮想マシンによる実行が可能になっている状態をいう。

Java（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。

一方、DVD-Videoのような読出専用ディスクで供給されるディスクコンテンツは、トップメニュータイトルを中核とした構造になっている。そのトップメニュータイトルから、個々の著作物へと分岐して再生を行い、その後再び、トップメニュータイトルに戻るという独特の状態遷移をなす。図１８は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Titleである。Titleとは、ディスクコンテンツ特有の状態遷移において、1つの”状態”にあたる再生単位であり、このタイトルが、Java（登録商標）アプリケーションの生存区間として取り扱われる。

Titleには、BD-ROMのローディング時に最初に再生される『FirstPlayTitle』、Top-Menuを構成する『Top_menuTitle』、これら以外の一般的な『Title』がある。また、図中の矢印jh1,2,3,4,5,6,7,8は、Title間の分岐を象徴的に示す。本図に示される状態遷移とは、BD-ROMローディング時に、『FirstPlayTitle』が再生され、『Top_menuTitle』への分岐が発生して、トップメニューに対する選択待ちになるというものである。

トップメニューに対する選択操作がユーザによりなされれば、選択に従って該当Titleの再生を行い、再びTopMenu Titleに戻るとの処理を、BD-ROMのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
それでは、図１８のような状態遷移をなすディスクコンテンツにおいて、Titleは、どのように生存区間として規定されるのであろうか。BD-ROMのローディングがなされた後、図１８において矢印jh1,2,3,4・・・・・に示された参照符号の数値順に分岐がなされ、BD-ROMがイジェクトされたものとする。そうすると、BD-ROMがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図１９（ａ）は、ディスク全体の時間軸を示す図であり、図１９（ｂ）は、この時間軸における構成を示す。図１９（ｂ）に示すように、ディスク全体の時間軸は、FirstPlayTitleが再生されている区間、TopMenu Titleが再生されている区間、title#1が再生されている区間等からなる。これらTitleの再生区間はどのように規定されているかというと、Titleは、唯一のBD-JObjectから構成されるから、どれかのMovieObject又はBD-J Objectが、有効になっている期間をTitleの再生区間と考えることができる。

つまりFirstPlay Title、TopMenu Title、その他のTitleは、何れも動的シナリオから構成されるから、Titleを構成するBD-JObjectのうち、どれかカレントBD-J ObjectとしてActivatedされ、再生装置内において解読・実行に供されている期間を、Titleの再生区間と定義することができる。図２０（ａ）は、BD-ROM全体の時間軸において、識別子bobj_idにより特定されるBD-JObjectから特定されるタイトル再生区間を示す図である。ここで識別子bobj_idにより特定されるBD-J Objectが、1つのTitleを構成しているなら、その識別子bobj_idにより特定されるBD-JObjectが有効になっているBD-ROM時間軸上の一区間を、Titleの再生区間と考えることができる。

ここでBD-J ObjectがActivateされている期間の終期は、Title分岐がなされるまでである。つまり、Title分岐がなされるまで、実行の対象になっている動的シナリオは、カレントBD-JObjectとして扱われるから、そのBD-J ObjectにおいてJumpTitleが発生するまでの1つの区間を、Title区間として扱う。
続いてTitle区間と、PL時間軸との関係について説明する。上述したようにMovieObject、BD-J Objectでは、1つの処理手順としてプレイリスト再生手順を記述することができる。プレイリスト再生手順の記述があれば、上述したPL時間軸の全部又は一部がTitle区間に帰属することになる。図２０（ａ）の一例においてBD-JObjectに、プレイリスト管理テーブルが記述されているとする。この場合、BD-J Objectに対応するTitle区間には、図２０（ｂ）に示すように、PL時間軸が帰属する。このPL時間軸には更に、複数チャプター(Chapter#1,#2,#3)が定義され得るため、BD-ROM上の時間軸には、BD-ROM全体−Title−プレイリスト−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Title分岐が発生することがある。この場合、1つのTitle再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり1つのTitleの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Title分岐が何時発生するかによって変わる。

図２１は、図２０（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Titleを生存区間にした”タイトルバウンダリアプリケーション”、Title内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、BD-ROM全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という3つの典型がある。

このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。
プラットフォームが動作していたとしても、Titleやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。

近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル(title#1)、オンラインショッピングを構成するオンラインショッピングタイトル(title#2)、ゲームアプリケーションを構成するゲームタイトル(title#3)という、性格が異なる3つのタイトルを含むものである。図２２は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはIndex.bdmvを記述しており、左側には3つのタイトルを記述している。

右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。3つのタイトルのうちtitle#1は、application#1、application#2、application#3という3つのアプリケーションからなる。title#2は、application#3、application#4という2つのアプリケーション、title#3は、application#5を含む。図２２の一例においてapplication#3は、title#1、title#2の双方で起動される。

図２２の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２３（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでapplication#1、application#2は、title#1のみに帰属しているので、これらの生存区間は、title#1内に留まっている。application#4は、title#2のみに帰属しているので、これらの生存区間は、title#2内に留まっている。application#5は、title#3のみに帰属しているので、これらの生存区間は、title#3内に留まっている。application#3は、title#1及びtitle#2に帰属しているので、これらの生存区間は、title#1−title#2にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、title#1,#2,#3のアプリケーション管理テーブルは図２３（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、title#1の再生開始時においてapplication#1、application#2、application#3をワークメモリにロードしておく。そしてtitle#2の開始時にapplication#1、application#2をワークメモリから削除してapplication#3のみにするという制御を行う。これと同様にtitle#2の再生開始時においてapplication#4をワークメモリにロードしておき、title#3の開始時にapplication#3,#4をワークメモリから削除するという制御を行いうる。

更に、title#3の再生中においてapplication#5をワークメモリにロードしておき、title#3の再生終了時にapplication#5をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。

続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「AutoRun」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Present」、仮想マシンのワークメモリにはおかれるが、CPUパワーの割り当ては不可となる「Suspend」がある。
「AutoRun」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて生存しており、かつ起動属性がAutoRunに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。

起動属性「Present」は、継続属性であり、分岐元titleにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Present」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから呼出があると、そのアプリケーションのapplicationIDが、アプリケーション管理テーブルに記述されていて、起動属性が「Present」であるか否かを判定する。「Present」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのapplicationIDがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Present」が付与されたアプリケーションに限られることになる。「Present」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのPresentであることを意味する。

「Suspend」とは、リソースは割り付けられているが、CPUパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるSuspendは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２４は、起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。

直前状態が”非起動”であり、起動属性が”Present”、”Suspend”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Present”、”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。

起動属性が”Suspend”であるなら、アプリケーションの状態はSuspendされることになる。直前状態が”Suspend”である場合、分岐先タイトルの起動属性が”Suspend”ならSuspendを維持することになる。”Present”又は”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。

尚、直前状態が”Suspend”であり、分岐先タイトルの起動属性が”Present”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、0〜255の値をとり、メモリリソース枯渇時や、CPU負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。

以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブル(PLMT)について説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のFailSafe機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくAVClip再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。

チャプターバウンダリアプリケーションは、1つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、1つ以上のTitleからなる生存区間に定義されることになる。
図２５（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『PL_id_ref』と、『Playback_Attribute』とからなる。

図２５（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『PL_id_ref』は、プレイリスト識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるプレイリストがどれであるかを示す。プレイリスト識別子は、ファイルYYYYY.MPLSにおいて、ファイル名として付与された5桁の数値YYYYYで表現される。このYYYYYが記述されることにより、『PL_id_ref』は、対応するTitleにおいて再生可能となるプレイリストがどれであるかを示す。

『Playback_Attribute』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『PL_id_ref』に記述されたプレイリストを、タイトル開始時において、どのように再生するかを規定する再生属性である。プレイリストに対する再生属性には、『AutoPlay』、『Present』といった種別がある。
『AutoPlay』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がAutoPlayに設定されたプレイリストの再生を開始する。これにより起動属性がAutoPlayに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。

『Present』とは、起動属性におけるPresent同様、継続属性であり、分岐元titleにおけるプレイリストの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される2つのTitleがあり、前のタイトル側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がAutoPlayに設定され、カレントタイトル側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がPresentに設定されているものとする。ここでプレイリストの再生時間が2時間長であり、このうち1時間が経過した時点で分岐が発生したとする。この場合カレントタイトルでは、再生属性がPresentに設定されているので、カレントタイトルにおいて、そのプレイリストは、1時間という再生済み区間の直後から、再生されることになる。このように再生属性をPresentに設定しておけば、Title間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のTitleにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもPresentにしておけば、複数のうちどれに分岐したとしても、1つの共通のプレイリスト再生を継続させることができる。

尚Titleの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Title間で1つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Present」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのPL_id_refが、プレイリスト管理テーブルに記述されていて、再生属性が「AutoPlay」か「Present」のいずれかか否かを判定する。「AutoPlay」か「Present」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのPL_id_refがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「AutoPlay」か「Present」のいずれかが付与されたプレイリストに限られることになる。「Present」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのPresentであることを意味する。

図２６は、プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。図２６の第1段目は、Titleの再生映像を示し、第2段目は、Titleの時間軸を示す。第3段目はPLMTにより再生が規定されるプレイリスト、第4段目は、アプリケーション実行を示す。第4段目においてapplication#1は、Titleの開始と共に起動されており、その後、時点t1において動作状態になる。一方PlayList#1は、Titleの開始と共に再生が開始されている。Playlist#1の再生は、Titleの開始と同じ時点に開始されているので、第1段目の左側に示すように、Titleの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像gj1がフルスクリーン表示される。プレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておくことにより、Java（登録商標）アプリケーションが動作状態になるまで5〜10秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。

一方、application#1は、時点t1で動作状態になるので、プレイリスト再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像gj2が時点t1において表示されることになる。アプリケーションの実行画像は、Startボタン,continueボタン、POWERインディケータを配置したゲーム用のGUIフレームワークであり、かかるGUIフレームワークの描画処理をJava（登録商標）アプリケーションが実行することでなされる。

こうした、プレイリストの再生映像と、Java（登録商標）アプリケーションのGUIフレームワークとを組み合わせた再生映像をなすタイトルを構成することができるのが、PLMTの特徴である。
図２７は、カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し(i)、プレイリスト管理テーブル有りで尚且つAutoPlay(ii)、プレイリスト管理テーブル有りで尚且つ無指定(iii))と、直前タイトルにおけるプレイリストの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。

本図における6通りの組合せのうち、”直前状態＝非再生状態”と、”カレントタイトル＝プレイリスト管理テーブル有り、尚且つ、カレントタイトルの再生属性＝AutoPlay”との組合せにおいて、分岐先タイトルにおけるプレイリストの再生は、自動的に開始することになる。
また”直前状態＝再生中状態”と、”カレントタイトル＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのプレイリストの再生は、自動的に停止することになる。

そしてこれら2つの組合せ以外は全て、前のタイトルの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてAutoPlay属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。

プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２８（ａ）を参照しながら説明する。ここで想定する具体例は、2つの連続するTitle(title#1、title#2)であリ、そのうちtitle#1では、AutoRunアプリケーションとしてapplication#1、application#2が記述されている。title#2ではAutoRunアプリケーションとしてapplication#2、application#3が記述されている。一方、title#1のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、title#2のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#2が記述されているものとする。図２８（ｂ）は、図２８（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。

title#1においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1の開始時にはapplication#1、application#2が自動的に起動され、PlayList#1の再生が自動的に開始される。
title#2においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1側に記載はあるが、title#2側には記載がないapplication#1の実行は停止させられる。同じくtitle#1側に記載があるが、title#2側に記載がないPlayList#1の再生も停止させられる。

title#1側に記載はないが、title#2側に記載があるPlayList#2、application#3は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。

また図２８では、application#1、application#2、application#3にはそれぞれ200,128,200の起動優先度が与えられている。これらの起動優先度を付与することにより、PlayList#1、PlayList#2に対する制御要求が競合した場合の調停を行わせることができる。ここでapplication#1がPlayList#1に対し早送りを命じているものとする。一方、application#2がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、application#2による要求を退け、application#1による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。

プレイリスト管理テーブル記述の他の具体例について説明する。図２９（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、2つの連続するタイトル(title#1、title#2)において、title#1側のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、再生可能なプレイリストとしてPlayList#2が記述され、title#1側のアプリケーション管理テーブルには、AutoPlayアプリケーションであるapplication#1と、実行可能なアプリケーションとしてapplication#2が記述されている。一方title#2側のプレイリスト管理テーブルには再生可能なプレイリストとしてPlayList#2、PlayList#3が記述され、アプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#3が記述されている。図２９（ｂ）は、図２９（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。title#1のアプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#1が記述されているので、title#1の開始時にはapplication#1が自動起動される。一方、title#1のアプリケーション管理テーブルには、実行可能アプリケーションとしてapplication#2が記述されているので、application#1からの呼出yd1によりapplication#2が起動される。

title#2側のアプリケーション管理テーブルにおいてapplication#1、application#2が非生存になっており、代わりにAutoRunアプリケーションとしてapplication#3が記述されている。そのためtitle#1−title#2の境界部では、application#1、application#2を停止し、application#3を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、title#1側のプレイリスト管理テーブルは、PlayList#1、PlayList#2が再生可能と記述されており、そのうちPlayList#1はAutoPlay属性になっている。そのためPlayList#1は、title#1の開始時において自動的に再生される。

title#1側のプレイリスト管理テーブルには、PlayList#1の他、PlayList#2が再生可能であると記述されているので、application#1はPlayList#1の再生を停止させ、代わりにPlayList#2の再生を要求することにより、プレイリスト交代を実行することができる。
title#2側のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そしてAutoPlay属性が付与されたプレイリストはない。そのため、仮にtitle#1開始時において自動再生されたPlayList#1の再生がtitle#2まで継続したとしても、PlayList#1の再生は自動的に終了することになる。

しかしPlayList#2再生が継続したままtitle#2に至れば、PlayList#2再生はtitle#2開始以降も継続する。title#2のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そのため、title#2で実行中となるapplication#3は、PlayList#2の再生を停止し、代わりにPlayList#3の再生を要求することにより、再生中のプレイリストを交代させることができる。

以上のようにプレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておけば、Java（登録商標）アプリケーションの起動に、5〜10秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。

アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
＜動作＞
次に、本実施の形態の再生装置１００のBD-ROM１１０をロードして動画が再生されたり、メニュー表示されるまでの動作を図３０に示すフローチャートを用いて説明する。当該動作はアプリケーションマネージャ３７による処理でもある。

図３０に示すように、まず、Title jumpがなされたかどうかを判定する（ステップＳ１）。
Title jumpがあった場合（ステップＳ１のＹＥＳ）には、タイトル切替を実行し（ステップＳ７）、次にカレントタイトルに対応するBD-JObjectにPLMTが存在するかどうかをみる（ステップＳ８）。

PLMTが存在する場合には（ステップＳ８のＹＥＳ）、前のタイトルではPLMTに記載されていなかったが、カレントタイトルではPLMTに記載されており、AutoPlay 属性が付与されているプレイリストの再生を開始する。PLMTが存在しなかった場合には（ステップＳ８のＮＯ）、前タイトルではPLMTに記載されていたが、カレントタイトルではPLMTに記載されていないAutoPlay 属性が付与されているプレイリストの再生を停止する。

次に、カレントタイトルに対応するアプリケーション管理テーブルがあるかどうかを判断する（ステップＳ１１）。
アプリケーション管理テーブルがあった場合（ステップＳ１１のＹＥＳ）には、前タイトルを生存区間としていないが、カレントタイトルを生存区間としているJava（登録商標）アプリケーションのうち、AutoRun属性を付与されているアプリケーションを起動する。アプリケーション管理テーブルがなかった場合（ステップＳ１１のＮＯ）には、前タイトルを生存区間としているがカレントタイトルを生存区間としていないアプリケーションを終了する。

続いて、アプリケーションの起動に成功したかどうかを判断する（ステップＳ１４）。アプリの起動に成功していた場合（ステップＳ１４のＹＥＳ）には、ビデオプレーン５及びビデオプレーン制御部１７に対してAutoPlay属性を付与されているプレイリストの再生画像のクォーター化の指示を実行する。また、当該指示を受けたStillプレーン制御部１７は、Stillプレーン１６からのスチルデータの出力を実行する（ステップＳ１５）。そしてテレビ１３０にはStillプレーン１６のスチルデータも合成された画像が表示される。アプリケーションの起動に失敗した場合（ステップＳ１４のＮＯ）には、ステップＳ２３に移行して以降の処理を実行する。

Title Jumpが発生しなかった場合（ステップＳ１のＮＯ）には、メインアプリが終了しているかどうかを検出する（ステップＳ２）。
メインとなるアプリケーションが終了していた場合（ステップＳ２のＹＥＳ）には、当該アプリケーションが正常に終了したかどうかを判断する（ステップＳ５）。正常に終了していた場合（ステップＳ５のＹＥＳ）には、ステップＳ１に戻り、以降の処理を実行する。

メインとなるアプリケーションが異常終了していた場合（ステップＳ５のＮＯ）には、Auto Play PLの再生中であったかどうかをみる（ステップＳ２１）。再生中であった場合（ステップＳ２１のＹＥＳ）には、ＣＰＵ２５は、AutoPlay PLの再生画像をフルスクリーン化するようにビデオプレーン５のデータをフルスクリーンサイズで出力させる。また、Stillプレーン制御部１７に、対しても同じ指示をだし、当該指示を受けてStillプレーン制御部１７は、Stillプレーン１６に格納されているスチルデータの出力を抑止する（ステップＳ２２）。そしてテレビ１３０には、スチルデータが合成されていない合成画像が表示される。

メインとなるアプリケーションが終了していなかった場合（ステップＳ２のＮＯ）には、次に、Auto Play属性が付与されているプレイリストの再生が終了しているかどうかを判断する（ステップＳ３）。AutoPlay 属性が付与されているプレイリストの再生が終了していた場合（ステップＳ３のＹＥＳ）には、ステップＳ１に戻り以降の処理を実行する。Auto Play 属性が付与されているプレイリストの再生が終了していなかった場合（ステップＳ３のＮＯ）には、BDドライバ１にBD-ROMがあるかどうかを検出する（ステップＳ４）。

BDドライバ１にまだBD-ROMが存在する場合（ステップＳ４のＹＥＳ）には、ステップＳ１に戻り以降の処理を実行する。BDドライバ１にBD-ROMが存在しない場合（ステップＳ４のＮＯ）には、全アプリケーションの終了指示を実行し（ステップＳ６）、終了する。
以上が、BD-ROM１１０が再生装置１００に装着されてから取り出されるまでの動作である。ここに述べたように、再生画像がフルスクリーンの場合と、クォータの場合とで、Stillプレーン１６からのデータの出力の可否を決定する。フルスクリーンの場合においては、Stillプレーン１６のデータの合成は必要ないため出力せず、こうすることでStillプレーン１６の読み出しに用いられるメモリバスバンド幅を開けることができる。
＜実施の形態２＞
次に本発明に係る実施の形態２について図面を参照しながら説明する。

実施の形態２においては、ＢＤアプリケーションにおいて、より豊かなインタラクティブ性を実現するためにJava（登録商標）のようなプログラミング環境を導入すると伴に、Stillプレーン又はPGプレーンからのデータの出力を制御することでメモリバスバンド幅を有効活用する内容を示す。基本的には実施の形態１に基づく内容であり、拡張または異なる部分についての説明を行う。
＜再生装置１００のハードウェア構成＞
再生装置１００については、実施の形態１と異なり更に、PGプレーン制御部２８が追加されている。ここではPGプレーン制御部２８の機能について説明する。その他の各部については、実施の形態１に示したものと変わらない。

PGプレーン制御部２８は、PGプレーン１４からのデータの出力を制御する機能を有する。具体的には、CPU２５からビデオプレーン５に対するスケーリング指示を受けて、当該スケーリング指示がテレビ１３０の全体への表示指示であるフルスケーリングである場合に、PGプレーン１４からのデータを出力させる。そしてスケーリング指示がフルスケーリングの1/4であるクォータスケーリングである場合に、PGプレーン１４からのデータの読み出しを抑制する。
＜動作＞
図３２は、実施の形態２においてアプリケーションの要求に基づいて、PGプレーン１４並びにStillプレーン１６からのデータの出力制御を行うことを示したフローチャートである。

フルスケーリング指示であった場合（ステップＳ１０３のＹＥＳ）には、ＣＰＵ２５は、Stillプレーン制御部１７に対してStillプレーン１６からのデータの出力を抑制するように指示する（ステップＳ１０４）。また、ＣＰＵ２５は、ＰＧプレーン制御部２８に対してＰＧプレーン１４からのデータの出力を実行するように指示し（ステップＳ１０６）、終了する。

フルスケーリング指示でなかった場合（ステップＳ１０３のＮＯ）、即ちビデオスケーリングの指示がフルスケーリングの1/4であるクォータスケーリングであった場合には、ＣＰＵ２５は、Stillプレーン制御部１７に対してStillプレーン１６からのデータの出力を実行するように指示する（ステップＳ１０５）。また、ＣＰＵ２５は、ＰＧプレーン制御部２８に対してＰＧプレーン１４からのデータの出力を抑制するよう指示し（ステップＳ１０７）、終了する。

なお、ステップＳ１０２において、ビデオスケーリングに失敗していた場合（ステップＳ１０２のＮＯ）においても、本フローチャートを終了する。
以上のようにアプリケーションによる全画面へのビデオスケーリングが成功した場合には、Stillプレーン１６からのデータの読み出しを抑制し、PGプレーン１４からのデータの読み出しを実行することができる。またアプリケーションによる全画面の1/4サイズへのビデオスケーリングが成功した場合には、Stillプレーン１６からのデータの読み出しを実行し、PGプレーン１４からのデータの読み出しを抑制することができる。

PGプレーン１４に関してもここに示したようにビデオスケーリングに基づく読み出しの制御を行い、ビデオスケーリングがクォータスケーリングである場合にはデータの出力を抑制することで、当該出力に用いるはずだったメモリバスバンド幅を空けることができる。
＜実施の形態３＞
実施の形態１においてはStillプレーン１６の出力制御を行い、Stillプレーン１６のデータの出力が必要ない場合にはメモリバスバンド幅をその分だけ開けることができることを示した。

実施の形態３においては、メモリバスバンド幅並びにメモリ領域を有効活用できる別の手法を示す。ここでは実施の形態１とは異なる部分についてのみ記述する。
実施の形態１及び２に示したようにStillプレーン１６からのデータの出力はビデオスケーリングがフルスケールの場合にはStillプレーン１６からのデータの出力を抑制し、ビデオスケーリングがクォータサイズの場合にはStillプレーン１６からのデータの出力を実行する。

また、PGプレーン１４に関してもビデオスケーリングに基づく出力制御を実行することを実施の形態２において記述した。上述したようにPGプレーン１４に関しては、Stillプレーン１６の場合とは逆にビデオスケーリングがフルスケールの場合においてはデータの出力を実行し、ビデオスケーリングがクォータサイズの場合においてはデータの出力を抑制する。

つまり、PGプレーン１４並びにStillプレーン１６からのデータの出力に関しては排他的であるといえ、一方が出力を実行しているともう一方は出力を実行しない構成になる。
よって実施の形態３においては、実施の形態１とは異なり、PGプレーン１６とStillプレーン１６とで使用するメモリ領域を共有する。この場合、アプリケーションからのビデオスケーリングに関する指示がフルスケールである場合には、当該メモリ領域は、PGプレーン１４用のメモリ領域として使用される。そしてビデオスケーリングに関する指示がクォータサイズである場合には、当該メモリ領域はStillプレーン１６として用いる。具体的には、PGプレーン１４とStillプレーン１６とはメモリの同じアドレスの領域を共有することになる。

こうすることで実質的に１つ分のプレーンのメモリ領域を開けることができ、そのメモリ領域を他の用途に用いることができる。例えば、Stillプレーン１６に表示するはずのＪＰＥＧデータを圧縮した状態で格納しておき、Stillプレーン１６からのデータの出力が必要な場合には、圧縮しておいたＪＰＥＧデータを展開してStillプレーンに書き込む構成にしてもよい。

（１）上記実施の形態においては再生装置をBD-ROM再生装置として説明してきたが、これは特にBD-ROM再生装置に限定するものではなく、DVDプレーヤなどであってもよい。
（２）上記実施の形態においてはStillプレーン制御部１７はビデオプレーンのスケール変更がなされるかどうかに基づいてStillプレーンからのスチルデータの読み出しを行うかどうかを判断していたが、字幕データを格納するためのPGプレーンに合成すべきデータがあるかどうかによって判断しても良い。

字幕データは、基本的にフルスクリーン表示を行うときのためのフォントサイズでBD-ROM１１０に記憶されており、スケールを変更して縮小した場合に字がつぶれてしまうことがあるため、PGプレーンを合成する場合には必ず、フルスクリーンでの表示が行われる。よって、Stillプレーン制御部１７は、PGプレーンがある場合にはフルスクリーンでの表示が行われると判断し、このときには、Stillプレーンからのスチルデータの読み出しを行わないようにしてもよい。

（３）上記実施の形態１においては、動画像がフルスクリーン表示の場合には、Stillプレーンの読み出しに用いられる予定であったメモリバスバンド幅があくことを記載した。このあいたメモリバスバンド幅は当然にその他の用途に用いられて良い。
例えば、Stillプレーンの読み出しに換えて、ビデオプレーンへの動画用の画像データの書き込みに用いたり、あるいは、ＩＧプレーンへのＧＵＩ画像の書き込みの用いたりすることも可能である。当該構成を備えることにより、再生装置は書き込みと読み出しのサイクルを早めることができると言え、テレビでの画像の表示の遅延をなるべく抑えることができるようになる。

（４）上記実施の形態においては、ビデオストリームは、BD-ROM規格のAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(VideoOBject)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。

（５）上記実施の形態においては、MPEG４-AVC（H.264やJVTとも呼ばれる）をもとに説明したが、MPEG２ビデオストリームであってもよく、また、その他の形式(VC-1等)の画像の場合でも単独でデコード可能な画像であれば、容易に応用可能である。
（６）上記実施の形態においては、ビデオプレーンが、フルスクリーンの場合についてのみStillプレーンを合成しないこととしたが、これはStillプレーンとビデオプレーンが共に通常フルスクリーンサイズで用意されるからである。しかし、ビデオプレーン及びStillプレーンが共にフルスクリーンサイズでなくとも、ビデオプレーンのデータが、Stillプレーンのデータの全てを覆い隠すならば、Stillプレーンの合成を実行しない構成にしてもよい。

（７）上記実施の形態においては、ビデオプレーン、即ち動画のスケーリングを行う際にフルスケールにするかクォータにするかによってStillプレーン１６からのデータの出力を制御したが、ビデオスケーリング時でなくともStillプレーン１６からのデータの出力制御を行ってもよい。
この場合、アプリケーションにStill プレーン制御部１７に対してのデータの出力の抑制あるいは実行の機能を持たせる。こうすることで、ビデオスケーリング時のみならず、Stillプレーン１６からのデータの出力制御を実行することができるようになる。

（８）上記実施の形態においては、Stillプレーン１６のデータの出力制御をアプリケーションの指示に基づく形で行ったが、BD-ROMにスチルデータの出力制御に関するフラグを持たせ、当該フラグに基づく出力制御を行ってもよい。
（９）上記実施の形態においては、PGプレーン１４には、字幕のみを格納することとしたが、字幕の画像データだけでなく、ビデオプレーンに格納されている動画とは別の動画を格納してもよい。こうすると、例えば表示画面を２つの領域に分割してそれぞれ別の動画を表示できるようになる。

（１０）本発明は、上記実施の形態において示したStillプレーンのスチルデータの合成制御に示す方法であってもよく、当該方法に示される処理手順を再生装置のコンピュータに実行させるコンピュータプログラムであってもよい。また、当該コンピュータプログラムは、フレキシブルディスク、ハードディスク、CD（CompactDisc）、MO（Magneto Optical disc）、DVD、BD、半導体メモリなどに記録されたものであってもよい。

本発明に係る再生装置は、BD-ROMからデータを読み出しアプリケーションを実行しながら画像を再生装置において表示の遅延がない再生装置として活用することができる。

本発明に係る再生装置の使用行為を示す図である。実施の形態１に係る再生装置１００の機能構成を示したブロック図である。ソフトウェアとハードウェアとからなる部分をレイア構成に置き換えて描いた図である。 Java（登録商標）仮想マシン３６の機能構成を示した図である。 BD-ROM１１０に格納されているデータのディレクトリ構造を示した図である。拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示した図である。 Clip情報の構成を示した図である。映画のビデオストリームに対するEP_map設定を示す図である。 Playlist情報のデータ構造を示した図である。 AVClipと、PlayList情報との関係を示す図である。 Playlist情報に含まれるＳＴＮテーブルを示した図である。（ａ）〜（ｄ）は、entry−attributeの詳細を示す図である。 PlayList情報の、PlayListMark情報の内部構成を示す図である。 PlayList情報の、PlayListMark情報によるチャプター位置の指定を示す図である。 BD-J Objectの内部構成を示す図である。アーカイブファイルにより収められているプログラム、データを示す図である。（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。ディスクコンテンツにおける状態遷移を示す図である。（ａ）は、BD-ROM全体の時間軸を示す図である。（ｂ）は、BD-ROM全体の時間軸における構成を示す図である。（ａ）（ｂ）BD-ROM全体の時間軸において、BD-J Objectから特定されるタイトル再生区間を示す図である。図２０（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つ無指定、プレイリスト管理テーブル有りで尚且つAutoPlay)と、直前タイトルにおけるPLの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。（ａ）は、プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。（ｂ）は、図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。（ｂ）は、図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。スチルプレーンを合成するかどうかを判断する再生装置１００の動作を示すフローチャートである。実施の形態２における再生装置１００の機能構成を示したブロック図である。実施の形態２においてアプリケーションの指示にビデオスケーリングの指示に基づいてStillプレーン並びにPGプレーンからのデータの出力制御の流れを示したフローチャートである。

符号の説明

１ BD-ROMドライブ
２リードバッファ
３デマルチプレクサ
４ビデオデコーダ
５ビデオプレーン
６サウンドプロセッサ
７サウンドプロセッサ
８ミキサー
９サウンドコントローラ
１０ D/Aコンバータ
１１ Interactive Graphics デコーダ
１２ Interactive Graphics プレーン
１３ Presentation Graphicsデコーダ
１４ Presentation Graphics プレーン
１５ JPEGデコーダ
１６ Still プレーン
１７ Still プレーン制御部
１８ａ、１８ｂ、１８ｃ合成部
１９ＳＴＣ−ＤＥＬＴＡ付加部
２０ＡＴＣ−ＤＥＬＴＡ付加部
２１ローカルストレージ
２２命令ＲＯＭ
２３ユーザイベント処理部
２４ＰＳＲセット
２５ＣＰＵ
２６シナリオメモリ
２７ローカルメモリ
２８ PGプレーン制御部
１００再生装置

Claims

動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段と、
前記ビデオプレーンに動画像を格納する動画像格納手段と、
前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納手段と、
前記スチルプレーンに前記背景画像を格納する背景画像格納手段と、
前記動画像が前記背景画像を遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力手段とを備える
ことを特徴とする再生装置。
前記所定のサイズとは前記動画像が表示画面においてフルスクリーンで表示されるサイズのことであり、
前記再生装置は更に、
前記動画像に係るアプリケーションを実行する仮想マシン部を備え、
前記合成出力手段は、前記アプリケーションの前記ビデオプレーンに対する縮小指示を受けて、前記背景画像を合成し、縮小指示がない場合には、前記動前記背景画像を合成しない
ことを特徴とする請求の範囲第１項記載の再生装置。
前記スチルプレーンは更に、前記動画像とは異なる時間に応じて切り替わる画像を格納するためのものであって、
前記再生装置は更に、
前記スチルプレーンに前記時間に応じて切り替わる画像を格納する画像格納手段を備え、
前記合成出力手段は、前記動画像が表示画面においてフルスクリーンで表示されるサイズである場合に、前記ビデオプレーンに格納された動画像と前記イメージプレーンに格納されたＧＵＩ画像と前記スチルプレーンに格納された時間に応じて切り替わる画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像がフルスクリーンで表示されるサイズでない場合に、前記ビデオプレーンに格納された動画像と前記イメージプレーンに格納されたＧＵＩ画像と前記スチルプレーンに格納された背景画像とを読み出し、重畳し合成した合成画像を表す画像信号を出力する
ことを特徴とする請求の範囲第１項記載の再生装置。
前記合成出力手段及び前記各格納手段は、前記記憶手段に接続されているメモリバスを共有しており、
前記イメージ格納手段は、前記合成出力手段がスチルプレーンの読み出しを行わないと判断した場合に、スチルプレーンの読み出しに割り当てられている前記メモリバスの帯域又は時間を、イメージプレーンへの書き込みに用いる
ことを特徴とする請求の範囲第１項記載の再生装置。
動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段を備える再生装置における、画像を合成する画像合成方法であって、
前記ビデオプレーンに動画像を格納する動画像格納ステップと、
前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納ステップと、
前記スチルプレーンに前記背景画像を格納する背景画像格納ステップと、
前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力ステップとを含む
ことを特徴とする画像合成方法。
前記合成出力ステップ及び前記各格納ステップにおいて、読み出し及び格納に用いる前記記憶手段に接続されているメモリバスを共有しており、
前記イメージ格納ステップでは、前記合成出力ステップにおいてスチルプレーンの読み出しを行わないと判断した場合に、スチルプレーンの読み出しに割り当てられている前記メモリバスの帯域又は時間を、イメージプレーンへの書き込みに用いる
ことを特徴とする請求の範囲第５項記載の画像合成方法。
動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段を備える再生装置のコンピュータに画像を合成させるための処理手順を示した画像合成プログラムであって、
前記ビデオプレーンに動画像を格納する動画像格納ステップと、
前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納ステップと、
前記スチルプレーンに前記背景画像を格納する背景画像格納ステップと、
前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力ステップとを含む
ことを特徴とする画像合成プログラム。
前記合成出力ステップ及び前記各格納ステップにおいては、読み出し及び格納に用いる前記記憶手段に接続されているメモリバスを共有しており、
前記イメージ格納ステップでは、前記合成出力ステップにおいてスチルプレーンの読み出しを行わないと判断した場合に、スチルプレーンの読み出しに割り当てられている前記メモリバスの帯域又は時間を、イメージプレーンへの書き込みに用いる
ことを特徴とする請求の範囲第７項記載の画像合成プログラム。
画像を合成して出力する再生装置に搭載される集積回路であって、
動画像を格納するためのビデオプレーンと、ＧＵＩとして表示する画像であるＧＵＩ画像を格納するためのイメージプレーンと、背景画像を格納するためのスチルプレーンとのメモリ領域を有する記憶手段と、
前記ビデオプレーンに動画像を格納する動画像格納手段と、
前記イメージプレーンに前記ＧＵＩ画像を格納するイメージ格納手段と、
前記スチルプレーンに前記背景画像を格納する背景画像格納手段と、
前記動画像が前記背景画像を完全に遮蔽できる所定のサイズである場合に、前記背景画像を読み出さず、前記動画像と前記ＧＵＩ画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力し、前記動画像が前記所定のサイズでない場合に、前記動画像と前記ＧＵＩ画像と前記背景画像とを読み出し、重畳して合成した合成画像を表す画像信号を出力する合成出力手段とを備える
ことを特徴とする集積回路。
前記合成出力手段及び前記各格納手段は、前記記憶手段に接続されているメモリバスを共有しており、
前記イメージ格納手段は、前記合成出力手段がスチルプレーンの読み出しを行わないと判断した場合に、スチルプレーンの読み出しに割り当てられている前記メモリバスの帯域又は時間を、イメージプレーンへの書き込みに用いる
ことを特徴とする請求の範囲第９項記載の集積回路。