JP5291026B2 - ３ｄ映像を再生する再生装置、および配信装置 - Google Patents

Description

本発明は、再生装置において２グラフィクスデコーダ構成を採用した場合のグラフィクスの立体視に関する。

近年、次世代光ディスク規格であるＢｌｕ−ｒａｙ Ｄｉｓｃ（以下、「ＢＤ」という）の普及が加速している。BD-ROM規格に準拠した再生装置では、当該再生装置に接続されたディスプレイなどの表示装置に、字幕やグラフィクスが重ね合わされた、高画質なビデオストリームを出力することで、高い臨場感を持つ映像を楽しむことができる（例えば特許文献１参照）。

一方、表示装置の技術動向として、フラットな映像だけではなく、飛び出るような映像を楽しむことができる立体視ディスプレイが普及し始めている。立体視ディスプレイにはさまざまな方式があるが、基本的な原理としては、レフトビューとライトビューとで左右の目に異なる絵を見せる仕組みを導入し、両目間の視差を利用することにより、立体的な映像を擬似的に作るものである。

ＷＯ２００５−１１９６７５号公報

ところで、ビデオと合成して再生されるべきグラフィクスの立体視表示をどのように行わせるかという問題がある。ここでグラフィクスが、字幕やメニューであれば、非圧縮グラフィクスであるグラフィクスオブジェクトを構成する画素データの座標を、レフトビュー再生時と、ライトビュー再生時とでそれぞれシフトさせることで、字幕やメニューを画面から手前に見せることができる。ところがこの座標シフトでは、グラフィクスが平面的な状態のまま手前に見えるだけで、グラフィクスそのものが立体的に見える訳ではない。

近年の映画作品では、字幕を主たる用途として導入されているPresentation Graphicsストリームのデータ構造を用いて、映画作品内の登場人物と緻密に同期するようなアニメーショングラフィクスを実現している例がある。
グラフィクスが例えばアニメーションキャラクターを表す場合には、座標シフトによる立体視では、平面的なキャラクターが手前に見えるにすぎず、アニメーションキャラクターの顔のくぼみや鼻の出っ張り具合などを立体的に再現することができない。そのため、アミューズメントの用途では物足りないという意見がある。

そこで、アニメーションキャラクターを立体的に見せるために、レフトビュー用のグラフィクスデータ及びライトビュー用のグラフィクスデータのそれぞれを1つのグラフィクスストリーム内に組込んでおいて、このグラフィクスストリームをデコードすることにより、立体視を実現させるという考えがある。
しかしながら、この考えでは、グラフィクスデコーダにおけるデコードの負荷が二倍になるため、グラフィクスデコーダの動作の基準となるクロック周波数を高くせねばならず、製品の低コスト化を妨げる。

クロック周波数の高周波数化を避けるには、グラフィクスデータを２ストリーム構成にし、尚且つ再生装置を２デコーダ構成にすればよい。つまり、レフトビュー用のグラフィクスデータとライトビュー用のグラフィクスデータとを、個別のグラフィクスストリームに組み込んでおき、また、再生装置には２つのグラフィクスデコーダを装備させる。そして、この２つのグラフィクスストリームを、２つのグラフィクスデコーダに処理させれば、クロック周波数をそれ程高くしなくても、再生装置にレフトビュー及びライトビューのグラフィクスデータをデコードさせることができる。

ところが、再生装置において２デコーダ構成を採用した場合、ランダムアクセスの際のグラフィクスの立体視が保証されないという問題がある。この問題について具体的に説明する。レフトビュー用及びライトビュー用のグラフィクスストリームはそれぞれ、ディスプレイセット（以下、「ＤＳ」という）を複数含んで構成され、各ＤＳは、一画面分のグラフィクスの表示に用いられるべきデータ群である。このＤＳには複数の類型があり、一画面分のグラフィクスの表示に必要な全てのデータを含んでいるＤＳや、直前のＤＳからの差分のみを含むＤＳがある。直前のＤＳからの差分のみを含むＤＳは、単独ではグラフィクス全体の表示を行えない。ここで、レフトビューから見える像とライトビューから見える像とでは見え方に差があるため、一方のＤＳでは、直前のＤＳからのアニメーションキャラクターの変化が大きく、一画面分のグラフィクスの表示に必要な全てのデータを含んでいる場合であっても、他方のＤＳでは、死角によりアニメーションキャラクターの変化が大きくなく、直前のＤＳからの差分のみを含んでいればよい場合も考えられる。

そうすると、再生装置において、これらのＤＳから頭出しをする場合に、一方のグラフィクスについては正しくデコードすることができても、他方に関しては再生に必要なデータがデコーダに供給されずデコードすることができない、といった問題が発生し得る。その結果、ランダムアクセス時におけるグラフィクスの立体視が不可能になる場合がある。
本発明は、ランダムアクセス時のグラフィクスの立体視を保証する記録媒体を提供することを目的とする。

上記目的を達成するために、本発明の一実施態様である再生装置は、配信装置から配信されたデジタルストリームを受信し再生する再生装置であって、前記デジタルストリームは、ビデオストリームと、レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームとを含み、前記レフトビューグラフィクスストリーム及び前記ライトビューグラフィクスストリームは、何れも１つ以上のディスプレイセットを含み、前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に用いられるデータ群であり、前記レフトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットは、前記ライトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットと１対１で対応しており、対応するディスプレイセットには、前記ビデオストリームの再生時間軸上において同一の再生時間が設定されており、前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に必要な全てのデータを含んでいるか、直前のディスプレイセットからの差分であるのかを示す状態情報を含み、前記レフトビューグラフィクスストリームと前記ライトビューグラフィクスストリームとで対応するディスプレイセットに含まれる状態情報が、同一の内容を示しており、前記配信装置から放送またはネットワークを経由して配信されたデジタルストリームを受信する受信手段と、前記ビデオストリームをデコードするビデオデコーダと、前記レフトビューグラフィクスストリームをデコードするレフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスストリームをデコードするライトビューグラフィクスデコーダとを備え、前記レフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスデコーダはそれぞれ、前記データ群のうちグラフィクスオブジェクトを定義するデータをデコードしてグラフィクスオブジェクトを得るプロセッサと、デコードにより得られたグラフィクスオブジェクトを格納するオブジェクトバッファと、前記データ群のうちグラフィクスオブジェクトを用いた画面構成を規定するデータを格納するコンポジションバッファと、を備え、前記レフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスデコーダは、共通の構成要素として、グラフィクスコントローラを備え、前記グラフィクスコントローラは、前記再生時間になると、前記レフトビューグラフィクスデコーダ内のコンポジションバッファに格納された、画面構成を規定する前記データ、及び前記ライトビューグラフィクスデコーダ内のコンポジションバッファに格納された、画面構成を規定する前記データを解読して、解読したこれらのデータに基づき、前記レフトビューグラフィクスデコーダ内のオブジェクトバッファのグラフィクスオブジェクトを用いてレフトビュー用の画面構成を行うとともに、前記ライトビューグラフィクスデコーダ内のオブジェクトバッファのグラフィクスオブジェクトを用いてライトビュー用の画面構成を行うことを特徴とする。

上記課題を解決するための手段に記載の構成により、レフトビューグラフィクスストリームの各ディスプレイセットの状態情報と、当該ディスプレイセットに対応する、ライトビューグラフィクスストリームのディスプレイセットの状態情報とが、同一の内容を示している。そのため、一方のグラフィクスストリームのディスプレイセットにおいて、その状態情報が、一画面分のグラフィクスの表示に必要な全てのデータを含んでいることを示すものである場合には、対応する、他方のグラフィクスストリームのディスプレイセットにおいても、その状態情報は、一画面分のグラフィクスの表示に必要な全てのデータを含んでいるものであることを示す。

したがって、これらのディスプレイセットを頭出しがなされることが判明している位置に配置することで、ランダムアクセスの際、一方のグラフィクスストリームがデコード可能であれば、必ず、他方のグラフィクスストリームのデコードも可能となる。ゆえに、ランダムアクセス時におけるグラフィクスの立体視を保証することができる。

ホームシアターシステムの構成を示す図である。 BD-ROMの内部構成を示す図である。 BD-ROMのアプリケーションフォーマットを示す図である。 レフトビューストリーム、ライトビューストリームを構成する各ソースパケットがどのような過程を経てAVデータ領域に書き込まれるかを示す図である。 BD-ROMの物理単位と、1つのファイルエクステントを構成するソースパケットとの対応関係を示す図である。 TSパケットのパケットIDがとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。 インターリーブ配置の一例を示す図である。 立体視のためのベースビューストリーム、エンハンスドビューストリームの内部構成の一例を示す図である。 ゴーグルの透光／遮光を、図８のタイミングに従って切り替えることにより、どのような映像が再生に供されるかを示す図である。 目の残像反応により形成される立体映像を示す図である。 ＰＧストリームの構成を示す図である。 様々な種別の機能セグメントにて構成される論理構造を示す図である。 ODS、PDSのデータ構造を示す。 WDS、PCSのデータ構造を示す。 レフトビューＰＧストリームとライトビューＰＧストリームとで対応するＤＳにおけるＤＳの類型、composition＿number、及びforced＿on＿flagを示す図である。 レフトビューのＤＳに属するWDS、PCSの記述例を示す図である。 ライトビューのＤＳに属するWDS、PCSの記述例を示す図である。 レフトビューＰＧストリームとライトビューＰＧストリームとで対応するＤＳのobject＿idを示す図である。 ＤＳｎが割り当てられた、AVClipの再生時間軸を示す図である。 クリップ情報ファイルの一例を示す図である。 エントリーマップテーブルの内部構成を示す図である。 エントリーマップによるエントリーポイントの登録を示す。 レフトビュー及びライトビューのそれぞれに対応するエントリーマップが、どのように設定されているかを示す図である。 プレイリスト情報のデータ構造を示す図である。 サブパス情報テーブルの内部構成を示す図である。 レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。 ビデオストリーム番号テーブルの内部構成を示す図である。 STN＿tableにおけるＰＧストリーム情報テーブルの内部構成を示す。 プレイリスト情報におけるエクステンションデータの内部構成を示す図である。 ビデオストリーム番号テーブルの内部構成を示す図である。 再生装置の内部構成を示す図である。 再生部１の内部構成を示す図である。 プレイリス再生処理の処理手順を示すフローチャートである。 STN＿table＿extensionに基づく再生手順を示すフローチャートである。 装置状態変化時及びストリーム変化の要求時におけるPSR2の設定手順を示すフローチャートである。 PSR2設定手順を示すフローチャートである。 変形例１−１における再生部１の内部構成を示す図である。 ＩＧストリームの構成を示す図である。 様々な種別の機能セグメントにて構成される論理構造を示す図である。 ICSとInteractive＿compositionとの対応関係を示す図である。 ICSの内部構成を示す図である。 複数ページのうち、任意のもの(x枚目のページ)についてのページ情報の内部構成を示す図である。 レフトビューのＤＳに属するICSの記述例を示す図である。 ライトビューのＤＳに属するICSの記述例を示す図である。 実施の形態２における再生部１の内部構成を示す図である。 レフトビューＰＧストリーム及びライトビューＰＧストリームの多重化順序の制限に関する図である。 PCSのデータ構造の変形例を示す図である。 3D-PCSを含むＤＳを示す図である。

以下、図面を参照しながら本発明の実施の形態を説明する。
（実施の形態１）
＜全体構成＞
図１は、記録媒体及び再生装置の使用行為についての形態を示す図である。図１（ａ）に示すように、記録媒体の一例であるBD-ROM１００、及び再生装置２００は、テレビ３００、液晶シャッタゴーグル４００、リモコン５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。

BD-ROM１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、テレビ３００と接続され、BD-ROM１００を再生する。
テレビ３００は、映画作品の再生映像を表示したり、メニュー等を表示したりすることで、対話的な操作環境をユーザに提供する。
液晶シャッタゴーグル４００は、液晶シャッタと、制御部とから構成され、ユーザの両目における視差を用いて立体視を実現する。液晶シャッタゴーグル４００の液晶シャッタは、印加電圧を変えることにより、光の透過率が変化する性質を有する液晶レンズを用いたシャッタである。液晶シャッタゴーグル４００の制御部は、ライトビュー用の画像とレフトビュー用の画像の出力切り替えのための同期信号を再生装置から受信し、この同期信号に従って、第１の状態と第２の状態とを切り替える。

図１（ｂ）は、第１の状態を示す。第１の状態とは、ライトビューに対応する液晶レンズが光を透過しないように印加電圧を調節し、レフトビューに対応する液晶レンズが光を透過するように印加電圧を調節した状態である。この状態において、レフトビュー用の画像が視聴に供されることになる。
図１（ｃ）は、第２の状態を示す。第２の状態とは、ライトビューに対応する液晶レンズが光を透過するように印加電圧を調節し、レフトビューに対応する液晶レンズが光を透過しないように印加電圧を調節した状態である。この状態において、ライトビュー用の画像が視聴に供されることになる。

一般的に、ライトビューから見える像とレフトビューから見える像には見え方に若干の差がある。これは、ライトビューとレフトビューとの位置の差に起因する。そして、この差を利用して、人間は、目に見える像を立体として認識できるのである。そこで、液晶シャッタゴーグル４００が、以上のような第１の状態と第２の状態との切り替えを、ライトビュー用の画像とレフトビュー用の画像の出力の切り替えタイミングに同期させれば、ユーザは、平面的な表示が立体的に見えると錯覚する。

次に、ライトビュー映像、及びレフトビュー映像を表示するにあたっての時間間隔について説明する。
具体的には、平面表示の画像において、ライトビュー用の画像とレフトビュー用の画像には、人間の両目の視差による見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。

この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。
図１（ａ）に戻って、リモコン５００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、及び数値キーを備える。

以上がホームシアターシステムについての説明である。
＜記録媒体＞
続いて、再生装置２００が再生の対象としている記録媒体について説明する。再生装置２００により再生されるのは、BD-ROM１００である。図２は、BD-ROM１００の内部構成を示す図である。

第１段目は、多層化された光ディスクであるBD-ROMを示し、第２段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いている。この螺旋トラックは、1つの連続した記録領域として扱われる。この記録領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域から構成される。

第３段目は、BD-ROMにおけるファイルシステム領域を示す。ファイルシステム領域は、"ボリューム管理領域"と、"論理アドレス空間"とから構成される。
"ボリューム管理領域"は、第１記録層の記録領域、第２記録層の記録領域、及び第３記録層の記録領域を、1つの連続したファイルシステム空間として扱うためのファイルシステム管理情報が記録されている領域である。

"論理アドレス空間"は、セクタが連続する論理ブロック番号(LBN)によって指示されるアドレス空間である。つまり、第２段目における第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域は、1つの連続した論理アドレス空間を構成することになる。
第４段目は、ファイルシステム管理領域の論理アドレス空間における領域割り当てを示す。ファイルシステム管理記録のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。

第５段目は、これら非AVデータ記録領域及びAVデータ記録領域に記録されるエクステントを示す。AVデータ記録領域には、AVファイルを構成する構成するエクステント(図中のEXT,EXT,EXT・・・・)が存在する。非AVデータ記録領域には、AVファイル以外のファイルを構成するエクステント(図中のEXT,EXT,EXT・・・・)が存在する。
図３は、BD-ROMのアプリケーションフォーマットを示す図である。

「BDMVディレクトリ」は、BD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「JARディレクトリ」、「BDJOディレクトリ」、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」と呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」、「MovieObject.bdmv」の２種類のファイルが配置されている。

『index.bdmv』は、BD-ROM全体に関する管理情報であり、再生装置へのディスク挿入後に、index.bdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。加えて、index.bdmvは、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するBD-Jオブジェクト又はムービーブジェクトとの対応付けを示す。

『MovieObject.bdmv』は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定する管理オブジェクトであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。

『JARディレクトリ』は、アーカイブファイルに対応するJARファイルが配置されるディレクトリである。アーカイブファイルは、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルである。1つ以上のクラスファイル、1つ以上のデータファイル等は例えば、アーカイバ（図示せず）により、１つにまとめることができる。

ここでは、アーカイブファイルの一例として、Java（登録商標）のアーカイブファイルを例に説明をする。
例えば、再生装置が備えるバイトコードインタプリタであるJava仮想マシンを制御主体とした動作モード(BD-Jモード)において、再生装置が行うべき制御手順を規定する。JARファイルを格納したファイルは、５桁の数字zzzzzと、拡張子jarとによって識別される。

『BDJOディレクトリ』は、バイトコードインタプリタであるJava仮想マシンを制御主体とした動作モード(BD-Jモード)において、再生装置が行うべき制御手順を規定する管理オブジェクト(BDJオブジェクト)を格納したファイルが格納されるディレクトリである。BDJオブジェクトを格納したファイルは、５桁の数字zzzzzと、拡張子bdjoとによって識別される。

『PLAYLISTディレクトリ』は、ベースビュービデオストリームに対する再生区間を指定するメインパス情報、エンハンスドビュービデオストリームに対する再生区間を指定するサブパス情報を含むプレイリスト情報を格納したファイルが配置される。このプレイリスト情報を格納したファイルは、"yyyyy"という５桁の識別番号と、拡張子"mpls"とによって識別される。ここでベースビュービデオストリームとは、レフトビュー又はライトビューを構成するビデオストリームのうち、平面視表示を実現しうるものである。一方、ライトビュー又はレフトビューを構成するビデオストリームのうち、ベースビュービデオストリームではないものを"エンハンスドビュービデオストリーム"という。エンハンスドビュービデオストリームを構成するピクチャデータは、ベースビュービデオストリームを構成するピクチャデータとのフレーム相関性に基づき圧縮符号化されている。

このような視点間の相関を利用したビデオ圧縮の方法としては、Multiview Video Coding（MVC）と呼ばれるMPEG-４AVC/H.２６４の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共同プロジェクトであるJoint Video Team（JVT）は、２００８年7月にMultiview Video Coding（MVC）と呼ばれるMPEG-４ AVC/H.２６４の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。

ベースビュー、エンハンスドビューを構成するストリームは、ビデオストリームだけではない。プレゼンテーショングラフィクス（ＰＧ）ストリームも、ベースビュー、エンハンスドビューを構成する。以降、ベースビュービデオストリームとベースビューＰＧストリームとを併せて、"ベースビューストリーム"と呼ぶ。また、エンハンスドビュービデオストリームとエンハンスドビューＰＧストリームとを併せて、"エンハンスドビューストリーム"と呼ぶ。

『CLIPINFディレクトリ』は、クリップ情報を格納したファイル(クリップ情報ファイル)が配置されるディレクトリである。クリップ情報ファイルは、"xxxxx"という５桁の識別番号と、拡張子"clpi"とによって識別される。このクリップ情報ファイルの内部には、レフトビューのビデオストリーム及びライトビューのビデオストリームのそれぞれに対応するエントリーマップが存在する。

以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
『STREAMディレクトリ』は、平面視ビデオストリームを格納したAVクリップファイル、及び立体視ビデオストリームを格納したAVクリップファイルが配置されるディレクトリである。平面視ビデオストリームを格納したファイルは、"xxxxx"という５桁の識別番号と、拡張子"m2ts"とによって識別される。立体視ビデオストリームを格納したファイルは、"xxxxx"という５桁の識別番号と、拡張子"ilts"とによって識別される。

STREAMディレクトリに格納されるベースビューストリームのファイルを構成するエクステント、STREAMディレクトリに格納されるべきエンハンスドビューストリームのファイルを構成するエクステントは、AVデータ記録領域に記録される。
図４は、ベースビューストリームを構成する各ソースパケット、及びエンハンスドビューストリームを構成する各ソースパケットがどのような過程を経てAVデータ領域に書き込まれるかを示す。本図の第１段目は、ベースビューストリームまたはエンハンスドビューストリームを構成するTSパケットを示す。

ベースビューストリームまたはエンハンスドビューストリームを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS＿extra＿header(図中のハッチング部)が付されて、192バイト長のソースパケットになる。このTS＿extra＿headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival＿Time＿Stampを含む。
ベースビューストリームまたはエンハンスドビューストリームを構成するソースパケットは、1つ以上の"ATCシーケンス"を構成する。"ATCシーケンス"とは、ATSの時間軸を構成するソースパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(no arrival time-base discontinutiy)が存在しないものをいう。言い換えれば、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、連続性が存在するソースパケット列を"ATCシーケンス"という。ATSは、TSパケットの先頭につけられ、デコーダへの転送時刻を示す。

かかるATCシーケンスがAVクリップになり、xxxxx.m2tsというファイル名で記録層に記録される。
かかるAVクリップは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、各記録層上の領域に記録される。第３段目はAVクリップを示し、第4段目はAVクリップがどのように各記録層に記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたサイズ(このサイズを、Ｓ＿EXTという)以上のデータ長を有する。

図５は、BD-ROMの物理単位と、1つのファイルエクステントを構成するソースパケットとの対応関係を示す図である。第２段目に示すように、BD-ROMのAVファイル記録領域には複数セクタが形成されている。ファイルエクステントを構成するソースパケットは、第1段目に示すように、複数個毎にグループ化されて、連続するセクタに書き込まれる。この複数個のソースパケットを"Aligned Unit"といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。

第３段目においてセクタは、複数個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unit単位でBD-ROMをアクセスする限り、複数個の完結したソースパケットを得ることができる。以上がBD-ROMに対するAVクリップの書き込みのプロセスである。
図６（ａ）は、TSパケットのパケットID(PID)がとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。

0x0100のパケットIDを有するTSパケットは、プログラムマップ（Program＿map）を構成し、0x1001のパケットIDを有するTSパケットは、プログラムクロックレファレンス(PCR)を構成する。
0x1011のパケットIDを有するTSパケットは、ベースビュービデオストリームを構成し、0x1012のTSパケットは、エンハンスドビュービデオストリームを構成する。

0x1100〜0x111FのパケットIDを有するTSパケットは、オーディオストリームを構成する。
0x1220〜x123FのパケットIDを有するTSパケットは、ベースビューＰＧストリームを構成する。0x1240〜0x125FのパケットIDを有するTSパケットは、エンハンスドビューＰＧストリームを構成する。なお、平面視のためのグラフィクスＰＧストリームを構成するTSパケットであって、ベースビューＰＧストリームになりえないもののパケットIDは、0x1200〜0x121Fの数値範囲となる。

これらのビデオストリームを構成するTSパケット、ＰＧストリームを構成するTSパケットは、ベースビューを構成するもの同士、エンハンスドビューを構成するもの同士でまとめられる。図６（ｂ）は、その一例を示す。
本図に示すように、ベースビューを構成するソースパケットのグループは、0x1011のPIDが付与されたベースビュービデオストリームのソースパケット(図中のVideo)、0x1100のPIDが付与されたオーディオストリームのソースパケット(図中のAudio)、0x1220,0x1221,0x1222,0x1223,0x1224,0x1225,0x1226のPIDが付与されたＰＧストリームのソースパケット(図中のＰＧ)から構成される。

一方、エンハンスドビューを構成するソースパケットのグループは、0x1012のPIDが付与されたエンハンスドビュービデオストリーム(図中のVideo)のソースパケット、0x1101のPIDが付与されたオーディオストリームのソースパケット(図中のAudio)、0x1240,0x1241,0x1242,0x1243,0x1244,0x1245のPIDが付与されたＰＧストリームのソースパケット(図中のＰＧ)から構成される。

ベースビュー、エンハンスドビューを構成するソースパケットのグループは、インターリーブ配置される。図７は、インターリーブ配置の一例を示す図である。本図におけるインターリーブ配置とは、ベースビュー、エンハンスドビューを構成するエクステントが、"ベースビュー"、"エンハンスドビュー"、"ベースビュー"、"エンハンスドビュー"・・・・・という規則性をもって記録されていることである。

第１段目は、AVファイルを示し、第２段目は、AVファイルを構成するエクステントEXT＿L[i],EXT＿L[i+1],EXT＿R[i],EXT＿R[i+1]を示す。第３段目は、各エクステント内に属するソースパケット列を示し、第４段目は、記録層におけるセクタ列を示す。ここで、括弧書きにおける変数i,i+1は、何番目のエクステントとして再生されるかを示す。この記法からすると、変数iによって指示される2つのエクステント、つまり、EXT＿L[i],EXT＿R[i]は同時に再生され、変数i+1によって指示される2つのエクステント、つまり、EXT＿L[i+1],EXT＿R[i+1]は同時に再生されることがわかる。

エクステントEXT＿L[i],EXT＿L[i+1]は、PID＝0x1011のソースパケットによって構成されている。破線の矢印h1,h2,h3,h4は、エクステントEXT＿L[i],EXT＿L[i+1]が、ベースビューストリーム、エンハンスドビューストリームのうちどちらに帰属するという帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT＿L[i],EXT＿L[i+1]は、ベースビューストリームに帰属していることがわかる。矢印h3,h4に示される帰属関係によると、エクステントEXT＿R[i],EXT＿R[i+1]は、エンハンスドビューストリームに帰属していることがわかる。

エクステントEXT＿L[i]のサイズをSEXT＿L[i]と呼び、エクステントEXT＿R[i]のサイズをSEXT＿R[i]と呼ぶ。
これらSEXT＿L、SEXT＿Rのサイズをどのように定めるかについて説明する。ここでエクステントは、再生装置においてライトビュー用リードバッファ、レフトビュー用リードバッファという2つのバッファに交互に読み出されてビデオデコーダに供される。そうすると、SEXT＿L、SEXT＿Rのサイズは、ライトビュー用リードバッファ及びレフトビュー用リードバッファをバッファフルにする時間を考慮して定める必要がある。つまり、ライトビュー用リードバッファへの転送レートを、Rmax1とすると、

ライトビュー用リードバッファ＝Rmax1×"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"

という関係を満たすよう、ライトビュー用リードバッファの容量を定めねばならない。ここでジャンプとは、ディスクシークと同義である。何故なら、BD-ROMにおいて記録に確保できる連続領域は有限であり、ベースビューストリーム及びエンハンスドビューストリームは、必ずしも、隣合わせで記録されるとは限らず、飛び飛びの領域に記録されることも有り得るからである。

続いて"ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間"について考える。レフトビュー用リードバッファにおけるTSパケット蓄積は、Rud-Rmax2という転送レートでなされる。これは、レフトビュー用リードバッファからの出力レートRmax2と、レフトビュー用リードバッファへの入力レートRudとの差分を意味する。そうすると、レフトビュー用リードバッファをフルにする時間は、RB2/(Rud-Rmax2)となる。

レフトビュー用リードバッファにデータを読み出すにあたっては、ライトビュービデオストリームからレフトビュービデオストリームへのジャンプ時間(Tjump)と、レフトビュービデオストリームからライトビュービデオストリームへのジャンプ時間(Tjump)とを考慮する必要があるので、レフトビュー用リードバッファの蓄積には（2×Tjump+RB2/(Rud-Rmax2)）という時間が必要になる。

ライトビュー用リードバッファの転送レートをRmax1とすると、上述したレフトビュー用リードバッファの蓄積時間において、Rmax1という転送レートで、ライトビュー用リードバッファ内の全てのソースパケットは出力されねばならないから、ライトビュー用リードバッファのサイズRB1は、

RB1≧Rmax1×{2×Tjump+RB2/(Rud-Rmax2)}

となる。

同様の手順で、レフトビュー用リードバッファの容量RB2を求めると、

RB2≧Rmax2×{2×Tjump+RB1/(Rud-Rmax1)}

となる。

ライトビュー用リードバッファ、レフトビュー用リードバッファのメモリサイズの具体的な値としては、1.5Mbyte以下であり、本実施の形態においてエクステントサイズSEXT＿R、SEXT＿Lは、このライトビュー用リードバッファ、レフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。以上がベースビューストリーム、エンハンスドビューストリームの記録のされ方についての説明である。

続いて、ベースビューストリーム及びエンハンスドビューストリームの内部構成について説明する。
図８は、立体視のためのベースビューストリーム、エンハンスドビューストリームの内部構成の一例を示す図である。
ベースビューストリーム、エンハンスドビューストリームは例えば、ピクチャデータを含む。ピクチャデータには複数種類があり、Ｉピクチャ、Ｐピクチャ、Ｂピクチャといったピクチャデータを含む。

Ｉピクチャとは、一画面分のピクチャデータである。
Ｐピクチャとは、基準となるＩピクチャとの差分を示すピクチャデータである。
Ｂピクチャとは、基準となるＩピクチャとＰピクチャにより生成されるピクチャデータである。
本図の第２段目は、ベースビューストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。

これらのピクチャデータは、DTS（デコーディングタイムスタンプ：デコーダによる復号の開始時刻を示す情報）に従いデコードされる。第１段目は、レフトビュー画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、レフトビュー画像が再生されることになる。

第４段目は、エンハンスドビューストリームの内部構成を示す。このセカンダリビデオストリームには、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第３段目は、ライトビュー画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTS（プレゼンテーションタイムスタンプ：ビデオ・オーディオの提示時刻を示す情報）に従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、ライトビュー画像が再生されることになる。

第５段目は、液晶シャッタゴーグル４００の状態をどのように変化させるかを示す。この第５段目に示すように、レフトビュー映像の視聴時は、ライトビューの液晶シャッタを閉じ、ライトビュー映像の視聴時は、レフトビューの液晶シャッタを閉じていることがわかる。
また、エンハンスドビューストリームは、時間方向の冗長性を利用したピクチャ間予測符号化に加えて、視点間の冗長性を利用したピクチャ間予測符号化によって圧縮されている。すなわち、エンハンスドビューストリームのピクチャは、ベースビューストリームの同じ表示時刻のピクチャを参照して圧縮されている。

例えば、エンハンスドビューストリームの先頭Pピクチャは、ベースビューストリームのIピクチャを参照し、エンハンスドビューストリームのBピクチャは、ベースビューストリームのBrピクチャを参照し、エンハンスドビューストリームの二つ目のPピクチャは、ベースビューストリームのPピクチャを参照している。
図９は、ゴーグルの透光／遮光を、図８のタイミングに従って切り替えることにより、どのような映像が再生に供されるかを示す図である。ここでフレーム表示期間が、１／２４秒であり、ゴーグルにおけるライトビュー、レフトビューの透光／遮光を、１／４８秒おきに変化させれば、ライトビュー、レフトビューのピクチャは、それぞれ交互に現れることになる。図９に示されるレフトビューの画像及びライトビューの画像は、画像内に現れる人物の顔の向きや位置が、レフトビュー画像と、ライトビュー画像とで僅かながらずれていることを模式的に示している(なお、図９、図１０における人物の顔の向きや位置のズレは模式的なものである)。

図１０は、目の残像反応により形成される立体映像を示す図である。ゴーグルの透光／遮光を、図８のタイミングに従って切り替えることにより、立体映像として認識することができる。
続いてＰＧストリームについて説明する。図１１は、ＰＧストリームの構成を示す図である。図１１（ａ）の第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、ＰＧストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。

第３段目は、ＰＧストリームの構成を示す。ＰＧストリームは、PCS(Presentation Composition Segment)、WDS(Window Definition Segment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、PCSは、画面構成セグメントと呼ばれ、WDS,PDS,ODS,ENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、または1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBD-ROMに記録されるか、またはフラグメント化され、複数PESパケットに変換されてBD-ROMに記録される。

図１１（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図１１（ｂ）に示すようにPESパケットは、『パケットヘッダ』と、『ペイロード』とからなり、このペイロードが機能セグメントの実体にあたる。また、パケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。

これら様々な種別の機能セグメントは、図１２のような論理構造を構築する。図１２は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第４段目に機能セグメントを、第３段目にDisplay Setの類型を、第２段目にDisplay Setを、第１段目にEpochをそれぞれ示す。第２段目のDisplay Set(ＤＳと略す)とは、ＰＧストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。また、図中の破線kz1は、第４段目の機能セグメントが、どのＤＳに帰属しているかという帰属関係を示す。PCS-WDS-PDS-ODS-ENDという一連の機能セグメントが、1つのＤＳを構成していることがわかる。再生装置は、このＤＳを構成する複数機能セグメントをBD-ROMから読み出せば、一画面分のグラフィクスを構成することができる。

第１段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に連続性があるというのは、このEpochにあたる期間を通じて、これらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィクスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう(※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである)。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィクスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィクスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像−グラフィクスの同期は保証されない。

また、Epochにおけるグラフィクスの位置関係に例えれば、再生時間軸上において、画面上のある決まった矩形領域内にグラフィクスが出現している期間が、Epochということができる。
以上がEpochについての説明である。続いてDisplay Setについて説明する。
図１２における破線hk1,2は、第２段目のＤＳが、第３段目のＤＳの類型のうちどの類型と対応しているかを示している。また、Epoch Start、Acquisition Point、Normal Caseという一連のＤＳは、第１段目のEpochを構成していることがわかる。『Epoch Start』、『Acquisition Point』、『Normal Case』は、ＤＳの類型である。本図におけるAcquisition Point、Normal Caseの順序は、一例にすぎず、どちらが先であってもよい。

『Epoch Start』は、新たなEpochの開始を示す。そのためEpoch Startは、次の画面合成に必要な全ての機能セグメントを含んでいる。Epoch Startは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Acquisition Point』は、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるDisplay Setである。Acquisition PointたるＤＳから頭出しを行えば、グラフィクス表示を確実に実現することができる。つまりAcquisition PointたるＤＳは、Epochの途中からの画面構成を可能にするという役割をもつ。Acquisition PointたるDisplay Setは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisition Pointを設けておくことにより、タイムサーチ時のＰＧストリーム再生を好適に行うことができる。

『Normal Case』は、前のDisplay Setからの差分のみを含む。例えば、あるＤＳvのグラフィクスは、先行するＤＳuと同じ内容であるが、画面構成が、この先行するＤＳuとは異なる場合、PCSと、ENDのみのＤＳvを設けて、このＤＳvをNormal CaseのＤＳにする。こうすれば、重複するODSを設ける必要はなくなるので、BD-ROMにおける容量削減に寄与することができる。一方、Normal CaseのＤＳは、差分にすぎないので、Normal Case単独では画面構成を行えない。

続いてDefinition Segment(ODS,WDS,PDS)について説明する。
『Object＿Definition＿Segment』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。
BD-ROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BD-ROMでは、例えば劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示やアニメーションキャラクターを鮮やかに再現できる。グラフィクスオブジェクトは、複数のランレングスデータからなる。ランレングスデータとは、ピクセル値を示すピクセルコードと、ピクセル値の連続長とにより、画素列を表現したデータである。ピクセルコードは、8ビットの値であり、1〜255の値をとる。ランレングスデータでは、このピクセルコードによりフルカラーの16,777,216色から任意の256色を選んで画素の色として設定することができる。なお、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。

ODSによるグラフィクスオブジェクトの定義は、図１３（ａ）に示すようなデータ構造をもってなされる。ODSは、図１３（ａ）に示すように、自身がODSであることを示す『segment＿type』と、ODSのデータ長を示す『segment＿length』と、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する『object＿id』と、EpochにおけるODSのバージョンを示す『object＿version＿number』と、『last＿in＿sequence＿flag』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『object＿data＿fragment』とからなる。

グラフィクスストリームのEpochには、同じIDをもつODSが複数含まれる。同じIDをもつ複数のODSは縦横のサイズが同じであり、オブジェクトバッファの共通の領域が割り当てられる。同じIDをもつ複数ODSのうち1つが、この領域に読み出されれば、オブジェクトバッファにおけるODSは、同じIDをもつ後続のODSにより上書きされる。このように、ビデオストリームの再生進行に伴い、オブジェクトバッファ上のODSが、同じ識別子をもつ後続のODSにて上書きされることにより、ODSにおける絵柄は、時間的な変遷を遂げる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わってもよい。

『last＿insequence＿flag』、『object＿data＿fragment』について説明する。PESパケットのペイロードの制限から、ＰＧを構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分(フラグメント)がobject＿data＿fragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、ＤＳにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、last＿sequence＿flagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であってもよい。以上がODSの説明である。

『Palette＿Difinition＿Segment(PDS)』は、パレットデータを格納する機能セグメントである。パレットデータとは、1〜255のピクセルコードと、ピクセル値との組合せを示すデータである。ここでピクセル値は、赤色差成分(Cr値),青色差成分(Cb値),輝度成分(Y値),透明度(T値)から構成される。各ランレングスデータが有するピクセルコードを、パレットに示されるピクセル値に置き換えることで、ランレングスデータは発色されることになる。PDSのデータ構造を図１３（ｂ）に示す。図１３（ｂ）に示すように、PDSは、自身がPDSであることを示す『segment＿type』、PDSのデータ長を示す『segment＿length』、このPDSに含まれるパレットを一意に識別する『pallet＿id』、EpochにおけるEpochのPDSのバージョンを示す『pallet＿version＿number』、各エントリーについての情報『pallet＿entry』からなる。『pallet＿entry』は、各エントリーにおける赤色差成分(Cr値),青色差成分(Cb値),輝度成分Y値,透明度(T値)を示す。

続いてWDSについて説明する。
『window＿definition＿segment』は、グラフィクスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィクスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィクスプレーンにおける矩形領域は"window"と呼ばれ、このWDSで定義される。図１４（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィクスプレーンにおいてウィンドゥを一意に識別する『window＿id』と、グラフィクスプレーンにおける左上画素の水平位置を示す『window＿horizontal＿position』と、グラフィクスプレーンにおける左上画素の垂直位置を示す『window＿vertical＿position』と、グラフィクスプレーンにおけるウィンドゥの横幅を示す『window＿width』と、グラフィクスプレーンにおける縦幅を示す『window＿height』とを用いて表現される。

window＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightがとりうる値について説明する。これらが想定している座標系は、グラフィクスプレーンの内部領域であり、このグラフィクスプレーンは、縦:video＿height、横:video＿widthという二次元状の大きさをもつ。
window＿horizontal＿positionは、グラフィクスプレーンにおける左上画素の水平アドレスであるので、1〜video＿widthの値をとり、window＿vertical＿positionは、グラフィクスプレーンにおける左上画素の垂直アドレスであるので1〜video＿heightの値をとる。

window＿widthは、グラフィクスプレーンにおけるウィンドゥの横幅であるので、1〜video＿width-window＿horizontal＿positionの値をとり、window＿heightは、グラフィクスプレーンにおける縦幅であるので1〜video＿height-window＿vertical＿positionの値をとる。
WDSのwindow＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightにより、グラフィクスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これにより、例えばグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。

続いて『END of Display Set Segment』について説明する。END of Display Set Segmentは、Display Setの伝送の終わりを示す指標であり、Display Setにおける機能セグメントのうち、最後のODSの直後に配置される。この END of Display Set Segmentの内部構成は、自身が END of Display Set Segmentであることを示す『segment＿type』と、当該機能セグメントのデータ長を示す『segment＿length』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。

以上がODS、PDS、WDS、ENDについての説明である。
続いて、PCSについて説明する。PCSは、対話的な画面を構成する機能セグメントである。PCSは、図１４（ｂ）に示すデータ構造で構成される。本図に示すようにPCSは、『segment＿type』と、『segment＿length』と、『composition＿number』と、『composition＿state』と、『pallet＿update＿flag』と、『pallet＿id』と、『composition＿object(1)〜(m)』とから構成される。

『composition＿number』は、0から15までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition＿numberは設定される。
『composition＿state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、Acquisition Pointであるか、Epoch Startであるかを示す。

『pallet＿update＿flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnly Displey Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは"1"に設定される。
『pallet＿id』は、PalletOnly Displey Updateに用いられるべきパレットを示す。

『composition＿object(1)・・・(m)』は、このPCSが属するDisplay Setにおける画面構成を実現するための制御情報である。図１４（ｂ）の破線wd1は、任意のcomposition＿object(i)の内部構成をクローズアップしている。この破線wd1に示すように、composition＿object(i)は、『object＿id＿ref』、『window＿id＿ref』、『forced＿on＿flag』、『object＿cropped＿flag』、『object＿horizontal＿position』、『object＿vertical＿position』、『cropping＿rectangle情報(1)(2)・・・・・(n)』からなる。

『object＿id＿ref』は、グラフィクスオブジェクト識別子(object＿id)の参照値である。この参照値は、composition＿object(i)に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『window＿id＿ref』は、ウィンドゥ識別子(window＿id)の参照値である。この参照値は、composition＿object(i)に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。

『forced＿on＿flag』は、再生装置の設定でグラフィクスオブジェクトがOFFになっている際でも強制的に表示されるべきグラフィクスオブジェクトを示す場合に1になる。
『object＿cropped＿flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。"1"と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、"0"と設定された場合、グラフィクスオブジェクトは非表示となる。

『object＿horizontal＿position』は、グラフィクスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object＿vertical＿position』は、グラフィクスプレーンにおける左上画素の垂直位置を示す。
『cropping＿rectangle情報(1)(2)・・・・・(n)』は、『object＿cropped＿flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping＿rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping＿rectangle情報(i)は、『object＿cropping＿horizontal＿position』、『object＿cropping＿vertical＿position』、『object＿cropping＿width』、『object＿cropping＿height』からなる。

『object＿cropping＿horizontal＿position』は、グラフィクスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSI EN 300 743標準規格における"Region"に相当する。
『object＿cropping＿vertical＿position』は、グラフィクスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。

『object＿cropping＿width』は、グラフィクスプレーンにおけるクロップ矩形の横幅を示す。
『object＿cropping＿height』は、グラフィクスプレーンにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。
＜２デコーダモデルを採用する場合の制限＞
続いて、レフトビューＰＧストリーム及びライトビューＰＧストリームのそれぞれについて、上述した各機能セグメントの各フィールドをどのように設定するのかについて説明する。

図１５は、レフトビューＰＧストリームに含まれるＤＳの類型、composition＿number、及びforced＿on＿flagと、ライトビューＰＧストリームに含まれるＤＳの類型、composition＿number、及びforced＿on＿flagとの対応関係を示す図である。本図に示すように、Epoch StartであるＤＳ及びAcquisition PointであるＤＳは必ず、レフトビューとライトビューとがペアで存在するようになっている。なぜなら、Epoch Start及びAcquisition Pointは、それ単体でグラフィクスオブジェクトの描写を完結できる単位であり、必ずペアで存在しなければ３Ｄ再生ができないからである。つまり、レフトビューのＤＳがEpoch Startである場合には、必ずペアとなるライトビューのＤＳが存在し、かつ、そのcomposition＿stateもEpoch Startでなければならない。

同様に、レフトビューのＤＳがAcquisition Pointである場合にも、必ずペアとなるライトビューのＤＳが存在し、かつ、そのcomposition＿stateもAcquisition Pointである必要がある。
レフトビューのＤＳがNormal Caseである場合にも、対応するライトビューのＤＳはNormal Caseであることが望ましい。

このように、対応するＤＳの類型を共通にすることで、例えば、ランダムアクセスを行う際の立体視を保証することができる。つまり、レフトビューのＤＳが例えばEpoch Startであれば、これに対応するライトビューのＤＳもEpoch Startであるので、これらを頭出しがなされることが判明している位置に配置することで、レフトビュー及びライトビューの一方だけがデコード可能であり、他方がデコード不可能であるといった状況を回避することができる。

また、本図に示すように、３Ｄとしてペアで再生される、レフトビューのＤＳのcomposition＿numberとライトビューのＤＳのcomposition＿numberとは等しくなければならない。このようにレフトビューとライトビューのＤＳを対応付けるためにcomposition＿numberを等しくしておくことで、グラフィクスデコーダは、再生時にどのレフトビューのＤＳとライトビューのＤＳを出力すべきか容易に判定できる。

さらに、レフトビューＰＧストリームのＤＳにおけるforced＿on＿flagと、ライトビューＰＧストリームの対応するＤＳにおけるforced＿on＿flagとは、同じ値に設定する必要がある。なぜなら、再生中にライトビューのグラフィクスオブジェクト（あるいはレフトビューのグラフィクスオブジェクト）だけが出力され、それに対応するレフトビューのグラフィクスオブジェクト（あるいはライトビューのグラフィクスオブジェクト）が出力されないと、グラフィクスオブジェクトの立体視が不可能となるからである。

また、画面構成セグメントがPESパケットに格納されていることは既に述べたが、当然ながら、レフトビューのＤＳに含まれる画面構成セグメントと、これに対応するライトビューのＤＳに含まれる画面構成セグメントとでは、それら画面構成セグメントを格納した各PESパケットのPTSの値を同一の値にする必要がある。
また、レフトビューのＤＳのパレット定義セグメントと、これに対応するライトビューのＤＳのパレット定義セグメントとでは、コード値と、輝度及び色差との対応関係が同一の内容に設定されており、palette＿idについても両者で同一になっている。

続いて、WDSの各フィールド、及びPCSにおいて上述した以外のフィールドをどのように記述するかについて説明する。図１６、１７は、Display Setに属するWDS、PCSの記述例を示す図である。ここでは、グラフィクスがアニメーションキャラクターの場合を例に挙げて説明するが、グラフィクスが、装飾文字等からなる字幕であってもよい。
図１６は、レフトビューのＤＳに属するWDS、PCSの記述例である。図１６（ａ）において、WDSのwindow＿horizontal＿position(left)、window＿vertical＿positionは、グラフィクスプレーンにおけるウィンドゥの左上座標を、window＿width,window＿heightは、ウィンドゥの表示枠の横幅、縦幅を示す。ここで、window＿horizontal＿position(left)の(left)は、このwindow＿horizontal＿positionが、対応するライトビューのwindow＿horizontal＿position(Right)とは異なる値であることを意味する。

図１６（ａ）におけるクロップ情報のobject＿cropping＿horizontal＿position(left),object＿cropping＿vertical＿positionは、オブジェクトバッファにおけるグラフィクスの左上座標を原点とした座標系においてクロップ範囲の基準点を示している。そして基準点からobject＿cropping＿width、object＿cropping＿heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスは、グラフィクスプレーンの座標系においてobject＿horizontal＿position(left),object＿vertical＿positionを基準点(左上)とした矩形範囲cp1に配置される。こうすることにより、グラフィクスがグラフィクスプレーンにおけるウィンドゥ内に書き込まれる。これにより、グラフィクスは動画像と合成され表示される。

図１７は、ライトビューのＤＳに属するWDS、PCSの記述例である。図１７（ａ）において、WDSのwindow＿horizontal＿position(Right)、window＿vertical＿positionは、グラフィクスプレーンにおけるウィンドゥの左上座標を、window＿width,window＿heightは、ウィンドゥの表示枠の横幅、縦幅を示す。ここで、window＿horizontal＿position(Right)の(Right)は、このwindow＿horizontal＿positionが、対応するレフトビューのwindow＿horizontal＿position(left)とは異なる値であることを意味する。

図１７（ａ）におけるクロップ情報のobject＿cropping＿horizontal＿position(Right),object＿cropping＿vertical＿positionは、オブジェクトバッファにおけるグラフィクスの左上座標を原点とした座標系においてクロップ範囲の基準点を示している。そして基準点からobject＿cropping＿width、object＿cropping＿heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスは、グラフィクスプレーンの座標系においてobject＿horizontal＿position(Right),object＿vertical＿positionを基準点(左上)とした矩形範囲cp2に配置される。こうすることにより、グラフィクスがグラフィクスプレーンにおけるウィンドゥ内に書き込まれる。これにより、グラフィクスは動画像と合成され表示される。

上述のように、WDSについては、Window＿width及びwindow＿heightが、レフトビューとライトビューとで同じ値に設定されている。ウィンドゥの表示枠の横幅及び縦幅が、レフトビューとライトビューとで異なると、一方ではウィンドゥの表示枠内にグラフィクスが収まるが、他方では収まりきらない場合も考えられ、その場合には、映像とグラフィクスとの同期が保障されないからである。また、グラフィクスプレーンにおけるウィンドゥの左上座標に関して、window＿vertical＿positionはレフトビューとライトビューとで共通の値になっているが、window＿horizontal＿positionは、レフトビューとライトビューとで値が異なっている。これは通常、左右の目では水平方向においては物体の見える位置が異なるからである。ただし、グラフィクスの生成の仕方によっては、window＿vertical＿positionの値がレフトビューとライトビューとで違っていてもよいし、window＿horizontal＿positionがレフトビューとライトビューとで同じであってもよい。

また、object＿cropping＿width及びobject＿cropping＿heightが、レフトビューとライトビューとで同じ値に設定されている。クロップの範囲が異なると、レフトビューとライトビューとでグラフィクスプレーンに配置されたグラフィクスに違いが出るからである。また、クロップ範囲の基準点に関して、object＿cropping＿vertical＿positionはレフトビューとライトビューとで共通の値になっているが、object＿cropping＿horizontal＿positionは、レフトビューとライトビューとで値が異なっている。ただし、object＿cropping＿vertical＿positionの値がレフトビューとライトビューとで違っていてもよいし、object＿cropping＿horizontal＿positionがレフトビューとライトビューとで同じであってもよい。

また、矩形範囲の基準点に関して、object＿vertical＿positionはレフトビューとライトビューとで共通の値になっているが、object＿horizontal＿positionは、レフトビューとライトビューとで値が異なっている。これは、上述したように、通常、左右の目では水平方向において物体の見える位置が異なるからである。ただし、グラフィクスの生成の仕方によっては、object＿vertical＿positionの値がレフトビューとライトビューとで違っていてもよいし、object＿horizontal＿positionがレフトビューとライトビューとで同じであってもよい。

さらに、図１６、１７に示すように、レフトビューのグラフィクスと、ライトビューのグラフィクスとは、異なる角度から見たグラフィクスであるので、両者のODSのobject＿data＿flagmentは、当然異なる。ただし、図１８に示すように、object＿idには共通の値が設定される。これは、再生装置において２デコーダ構成を採用した場合、グラフィクスコントローラを２つのデコーダで共通にする構成が採用される場合があり得、その場合には、レフトビューとライトビューとで対応するグラフィクスオブジェクトのobject＿idを同じ値に設定しておかないと、グラフィクスコントローラは、どのグラフィクスオブジェクト同士が対応関係にあるのか判別できないためである。

以上の制限を加えることで、２デコーダ構成において、レフトビューＰＧストリームとライトビューＰＧストリームとによる立体視を実現することができる。
続いて、これらPCS、ODSを有したDisplay Setが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplay Setから構成されるので、Display SetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。Display Set内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplay Setの割り当てである。

Epochに属するDisplay Setのうち、任意のDisplay SetをＤＳnとすると、ＤＳnは、図１９に示すようなDTS、PTS設定によりAVClipの再生時間軸に割り当てられる。図１９は、ＤＳnが割り当てられた、AVClipの再生時間軸を示す図である。本図においてＤＳnの始期は、ＤＳnに属するPCSのDTS値(DTS(ＤＳn[PCS]))により示されており、終期は、ＤＳnに属するPCSのPTS値(PTS(ＤＳn[PCS]))により示されている。そしてＤＳnにおいて最初の表示が行われるタイミングも、PCSのPTS値(PTS(ＤＳn[PCS]))に示されている。AVClip再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、PTS(ＤＳn[PCS])とを一致させれば、ＤＳnの最初の表示は、そのビデオストリームと同期することになる。

PTS(ＤＳn[PCS])は、DTS(ＤＳn[PCS])に、ODSのデコードに要する期間(DECODEDURATION)を足し合わせた値である。
最初の表示に必要なODSのデコードは、このDECODEDURATION内に行われることになる。図１９の期間mc1は、ＤＳnに属する任意のODS(ODSm)のデコードがなされる期間を示す。このデコード期間の開始点は、DTS(ODSn[ODSm])により示され、このデコードの終了点は、PTS(ODSn[ODSm])により示される。

以上のような再生時間軸への割り付けを、Epochに属する全てのODSに対して行うことで、Epochは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
＜クリップ情報ファイル＞
図２０は、クリップ情報ファイルの一例を示す図である。クリップ情報ファイルは、本図に示すようにAVクリップの管理情報であり、AVクリップと１対１に対応し、クリップ情報と、ストリーム属性テーブルと、エントリーマップテーブルとから構成される。

引き出し線zh1は、ストリーム属性テーブルの内部構成をクローズアップして示している。ストリーム属性テーブルには、この引出線に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。属性情報は、ベースビューストリーム、エンハンスドビューストリーム毎に異なる情報を持つ。
引き出し線zh2は、ベースビューストリームの内部構成をクローズアップして示している。引出線に示すように、PID＝0x1011のTSパケットによって構成されるベースビューのストリーム属性情報として、コーディック、解像度、アスペクト比、フレームレートが記述される。

続いて、エントリーマップテーブルの内部構成について説明する。
エントリーマップは、あるパケットIDを用いて特定されるSTC時間軸のうち、任意のソースパケットのソースパケット番号と、STC時間軸におけるPTSとの対応付けを示すテーブルである。
STC時間軸は、デコード時刻、表示時刻を表すMPEG2-TSの時間軸である。AVストリームのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)が存在しない1つのソースパケットのまとまりを"STCシーケンス"と呼ぶ。

図２１（ａ）は、エントリーマップテーブルの内部構成を示す図である。引き出し線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。
引出線eh1に示すように、エントリーマップテーブルには、PID＝0x1011のTSパケットによって構成されるベースビューストリームについてのエントリーマップ、PID＝0x1012のTSパケットによって構成されるエンハンスドビューストリームについてのエントリーマップというように、複数種別のTSパケットによって構成されるパケッタイズドエレメンタリストリームのそれぞれについて、エントリーマップが存在する。エントリーマップにおいて、一対となるPTSとSPNとの組みを含む情報を"エントリーポイント"と呼ぶ。エントリーポイントは、PTSとSPNとの組みに、当該SPNからのデコードが可能であるか否かを示す表示方式フラグ(is＿angle＿changeフラグ)を対応付けた情報である。また、先頭を０としてエントリーポイント毎にインクリメントした値を"エントリーポイントID（以下EP＿ID）"と呼ぶ。

このエントリーマップを利用することにより、再生装置は、ビデオストリームの時間軸上の任意の地点に対応するソースパケット位置を特定することが出来るようになる。例えば、早送り・巻戻しの特殊再生の際には、エントリーマップに登録されるIピクチャを特定し選択して再生することにより、AVクリップを解析することなく効率的に処理を行うことができる。また、エントリーマップは、AVクリップ内に多重化されるビデオストリーム毎に作られ、PIDで管理される。

引き出し線eh2は、PID＝0x1011のエントリーマップの内部構成をクローズアップして示している。EP＿ID=0に対応するエントリーポイント、EP＿ID=1に対応するエントリーポイント、EP＿ID=2に対応するエントリーポイント、EP＿ID=3に対応するエントリーポイントを含んで構成される。EP＿ID=0に対応するエントリーポイントは、オンに設定されたis＿angle＿changeフラグと、SPN=3と、PTS=80000とから構成される。EP＿ID=1に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=1500と、PTS=270000とから構成される。

EP＿ID=2に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=3200と、PTS=360000とから構成される。EP＿ID=3に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=4800と、PTS=450000とを含んでいる。
本図（ｂ）は、（ａ）に示したPID＝0x1011のTSパケットに対応するエントリーマップ内の複数のエントリーポイントによって、どのソースパケットを指示されるかを示す。EP＿ID=0に対応するエントリーポイントは、SPN=3を指し示しており、このソースパケット番号をPTS=80000と対応付けている。EP＿ID=1に対応するエントリーポイントは、SPN=1500を指し示しており、このソースパケット番号をPTS=270000に対応付けている。

EP＿ID=2に対応するエントリーポイントは、SPN=3200のソースパケットを指し示しており、このソースパケット番号をPTS=360000に対応付けている。EP＿ID=3に対応するエントリーポイントは、SPN=4800のソースパケットを指し示しおり、このソースパケット番号をPTS=450000と対応付けている。
図２２は、エントリーマップによるエントリーポイントの登録を示す。第１段目は、STCシーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、ATCシーケンスを構成するソースパケット列を示す。

矢印te1,te2,te3,te4は、STC時間軸における再生時点t1,t11,t21,t31と、エントリーポイントとの対応関係を模式的に示しており、矢印sh1,sh2,sh3,sh4は、ATCシーケンスにおけるSPN=n1,n11,n21,n31と、エントリーポイントとの対応関係を模式的に示している。
エントリーマップが、ATCシーケンスのうちSPN＝n1のソースパケットを指定している場合、このエントリーマップのPTSを、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおけるSPN＝n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうちSPN＝n21のソースパケットを指定している場合、このエントリーマップのPTSを、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおけるSPN＝n21からのランダムアクセスを再生装置に実行させることができる。

図２３は、レフトビュー、及びライトビューのそれぞれに対応するエントリーマップが、どのように設定されているかを示す図である。本図における対応付けは、エントリーマップにおける各エントリーポイントのソースパケット番号に、STCシーケンスにおけるソースパケット番号を記述しておき、エントリーマップにおける各エントリーポイントのPTSに、STCシーケンスにおけるPTSを記述しておくことでなされる。時間軸のソースパケットと、時間軸との対応付けが、エントリーマップによってどのようにとられているかを示す。

矢印th1,th2,th3,th4は、STC時間軸における再生時点t1,t2と、エントリーポイントとの対応関係を模式的に示しており、矢印sh1,sh2,sh3,sh4は、ATCsequeceにおけSPN=n1,n11,n8,n18と、エントリーポイントとの対応関係を模式的に示している。
第５段目は、インターリーブ記録されたレフトビュー、ライトビューのエクステントであり、これまでの図に示したものと同一である。第３段目は、PID＝0x1011、PID＝0x1012のそれぞれに対応するエントリーマップである。PID＝0x1011に対応するエントリーマップは、n1を指し示すエントリーポイント、n8を指し示すエントリーポイントを含む。これらのエントリーポイントは、n1,n8と、STC時間軸におけるt1、t2との対応付けを示す。PID＝0x1012に対応するエントリーマップは、n11を指し示すエントリーポイント、n18を指し示すエントリーポイントを含む。これらのエントリーポイントは、n11,n18と、STC時間軸におけるt1、t2との対応付けを示す。

以上により、時間軸において、同じ再生時点で再生されるべきレフトビュー、ライトビューのエクステントは、AVデータ記録領域においてバラバラな位置に記録されつつも、各々に対応付けられたエントリーマップを用いることで、レフトビューのエクステント、ライトビューのエクステントの先頭となるソースパケットは、PTSを用いて一意にアクセスされることになる。

以上がクリップ情報ファイルについての説明である。
＜プレイリスト情報＞
続いて、プレイリスト情報の詳細について説明する。
図２４は、プレイリスト情報のデータ構造を示す図であり、本図において、プレイリスト情報は、再生属性情報、メインパス情報、サブパス情報テーブル、エクステンションデータを含む。

先ず再生属性情報について説明する。引出線mp3は、再生属性情報の内部構成をクローズアップして示している。引出線mp3に示すように、再生属性情報は、該当コンテンツがベースとしている規格の「バージョン番号」、「再生タイプ」、「立体表示フラグ」を含む。バージョン番号としては、BD-ROMアプリケーションフォーマットバージョン２.００等というバージョン番号を格納することができる。また、再生タイプとしては、プレイリストに含まれるプレイアイテムを先頭から順番に再生していくことを意味する"シーケンシャル"や、"ランダム／シャッフル"に再生することを再生装置に指示することができる。

次にメインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃Nから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線mp2によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVクリップの再生区間情報のファイル名を示す『Clip＿Information＿file＿name』と、AVクリップの符号化方式を示す『Clip＿codec＿identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is＿multi＿angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection＿condition』と、このPlayItemが対象としているSTC＿Sequenceを一意に示す『ref＿to＿STC＿id[0]』と、再生区間の始点を示す時間情報『In＿time』と、再生区間の終点を示す時間情報『Out＿time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO＿mask＿table』と、『STN＿table』と、『BaseView＿indicator』と、『multi＿clip＿entry』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『In＿time』、再生区間の終点を示す時間情報『Out＿time』の組みであり、再生経路情報とは、この『In＿time』及び『Out＿time』の組みから構成される。

STN＿table(STream Number＿table)は、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN＿tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。
BaseView＿indicatorは、0ならばBaseViewはLeftであり、1ならばBaseViewはRightであることを示す。

図２５は、サブパス情報テーブルの内部構成を示す図である。引き出し線su1は、サブパス情報の内部構成をクローズアップして示している。引出線su1に示すように、サブパス情報テーブルは複数のサブパス情報1,2,3・・・mを含む。これらのサブパス情報は、1つのクラス構造体から派生した複数のインスタンスであり、その内部構成は共通のものとなる。引き出し線su2は、Subpath情報の共通の内部構成をクローズアップして示している。この引き出し線に示すように、各Subpath情報は、サブパスの類型を示すSubPath＿typeと、1つ以上のサブプレイアイテム情報(・・・サブプレイアイテム情報＃1〜＃m・・・)とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、サブプレイアイテム情報は、『Clip＿information＿file＿name』、『Clip＿codec＿identifier』、『ref＿to＿STC＿id[0]』、『SubPlayItem＿In＿time』、『SubPlayItem＿Out＿time』、『sync＿PlayItem＿id』、『sync＿start＿PTS＿of＿PlayItem』からなる。以降、SubPlayItemの内部構成について説明する。

『Clip＿information＿file＿name』は、クリップ情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip＿codec＿identifier』は、AVクリップの符号化方式を示す。
『ref＿to＿STC＿id[0]』は、このSubPlayItemが対象としているSTC＿Sequenceを一意に示す。

『SubPlayItem＿In＿time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。
『SubPlayItem＿Out＿time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
『sync＿PlayItem＿id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem＿In＿timeは、このsync＿PlayItem＿idで指定されたPlay Itemの再生時間軸上に存在する。

『sync＿start＿PTS＿of＿PlayItem』は、sync＿PlayItem＿idで指定されたPlay Itemの再生時間軸上において、SubPlayItem＿In＿timeで指定されたSubPlayItemの始点が、どこに存在するかを45KHzの時間精度で示す。
図２６は、レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。本図は、図２３をベースとして作図されており、このベースとなる図の第２段目の時間軸に、PlayItemのIn＿Time及びOut＿Timeを描いている。第１段目の時間軸に、SubPlayItemのIn＿Time及びOut＿Timeを描いている。第３段目から第５段目は、図２３の第３段目から第５段目と同一である。レフトビュー、ライトビューのIピクチャは、時間軸において同じ時点になる。

レフトビューと、ライトビューとは、プレイアイテム情報、サブプレイアイテム情報とによって、対応付けられることになる。
図２７は、ビデオストリーム番号テーブルの内部構成を示す図である。引き出し線mh1に示すように、ビデオストリーム番号テーブルは、stream＿entry及びstream＿attributeの組みから構成される。

「Stream＿entry」は、プライマリビデオストリームを構成するPESパケットのPIDに対する参照値を示す『ref＿to＿stream＿PID＿of＿main＿Clip』、NTSC,PAL等のビデオの表示方式を示す『video＿format』、1/24秒、1/29.94秒などフレームレートを示す『frame＿rate』を含む。
図２８は、STN＿tableにおけるＰＧストリーム情報テーブルの内部構成を示す。STN＿tableにおけるＰＧストリーム情報テーブルは、「表示方式情報」と、「N個のストリーム情報」とから構成される。n個のストリーム情報のそれぞれは、ストリーム番号のそれぞれに対応付けられており、stream＿entryと、stream＿attributeとから構成される。引き出し線gh1は、stream＿entryの内部構成をクローズアップして示している。stream＿entryには、『ref＿to＿stream＿PID＿of＿mainClip』、又は、『ref＿to＿Sub＿Path＿id』、『ref＿to＿SubClip＿＿entry＿id』、『ref＿to＿stream＿PID＿of＿subClip』のどちらが設定される。『ref＿to＿stream＿PID＿of＿SubClip』は、ストリーム番号に対応するＰＧストリームが、ビデオストリームと同じAVClipに存在する場合に、そのＰＧストリームについてのPIDを示す。

続いて、エクステンションデータについて説明する。図２９は、プレイリスト情報におけるエクステンションデータの内部構成を示す図である。引き出し線et1は、エクステンションデータの内部構成をクローズアップして示している。この引き出し線に示すように、エクステンションデータは、プレイアイテム情報＃1〜＃Nのそれぞれがに対応するSTN＿table＿extentionから構成される。引き出し線et2は、PlayItem情報＃1に対応するSTN＿table＿extentionの内部構成をクローズアップして示している。この引き出し線に示すように、PlayItem情報＃1に対応するSTN＿table＿extentionは、"ビデオストリーム番号テーブル"を含む。

図３０は、ビデオストリーム番号テーブルの内部構成を示す図である。
Ｎ個のenhanced＿view＿is＿availableフラグe1と、Ｎ個のstream＿entry及びstream＿attributeの組みf1とから構成される。これらは、１〜Ｎのストリーム番号に対応付けられており、enhanced＿view＿is＿availableフラグは、１〜Ｎのストリーム番号を用いることで一意に特定することができる。stream＿entry及びstream＿attributeの組みも、１〜Ｎのストリーム番号を用いることで一意に特定することができる。

「Stream＿entry」は、引き出し線vh1に示すように、プライマリビデオストリームを構成するPESパケットのPIDに対する参照値を示す『ref＿to＿stream＿PID＿of＿main＿Clip』を含み、stream＿attributeは、引出線vh2に示すように、『video＿format』、『frame＿rate』を含む。
これらのテーブルにおけるstream＿entryの順位は、再生装置がストリームを選択するにあたって、ストリーム選択の優先順位を意味する。つまり、テーブルにおいてエントリーが高い順位にあるものを再生装置は、優先的に選択することになる。

enhanced＿view＿is＿availableフラグがオンであり、エンハンスドビューに設定されている場合、ref＿to＿stream＿of＿MainCLipには、0x1011のパケットIDと、0x1012のパケットIDとが記述される。
続いて、STN＿table＿extensionにおけるＰＧストリーム情報テーブルについて説明する。STN＿table＿extensionにおけるＰＧストリーム情報テーブルの内部構成は、N個のストリーム情報を含んで構成される。n個のストリーム情報のそれぞれは、ストリーム番号のそれぞれに対応付けられており、「stream＿entry」と、「stream＿attribute」とを含む。stream＿entryは、再生可能なレフトビューPGストリームを構成するPESパケットのPIDに対する参照値、及びライトビューPGストリームを構成するPESパケットのPIDに対する参照値の組みを含む。

ここで、STN＿table＿extentionには、STN＿tableにおけるstream＿entry及びstream＿attributeの組みの数と同数のstream＿entry及びstream＿attributeの組みが存在する。STN＿table＿extentionのstream＿entry及びstream＿attributeの組みと、STN＿table のstream＿entry及びstream＿attributeの組みとが１対１に対応しており、それらは同一のストリーム番号となる。STN＿table＿extentionのstream＿entryにより示されるレフトビュー及びライトビューの各ストリームと、対応する、STN＿table のstream＿entryにより示されるストリームとは、基本的には同一のものであり、表示位置が水平方向に異なるだけである。すなわち、STN＿table のstream＿entryにより示されるストリームに、人間の両目の視差に相当する差を加えたものが、STN＿table＿extentionのstream＿entryにより示されるレフトビュー及びライトビューの各ストリームである。

なお、本願明細書におけるコンテンツとは、あるタイトル番号にて管理されるプレイリスト情報と、このプレイリスト情報から参照されるAVクリップに多重化されているビデオストリームとを包含する単位であり、"タイトル"と呼ばれる。
以上がプレイリスト情報についての説明である。
＜再生装置＞
続いて、再生装置の詳細について説明する。図３１は、再生装置の内部構成を示す図である。再生装置２００は、BDドライブ２０１、システムLSI（再生部）１、HDMIインタフェース２０２、再生状態／設定レジスタ(Player Status/Setting Register)セット２０３、静的シナリオメモリ２０５、再生制御エンジン２０６、ヒープメモリ２０７、BD-Jプラットフォーム２０８、動的シナリオメモリ２０９、モード管理モジュール２１０、コマンドインタプリタ２１１、及びUO検知モジュール２１２を含んで構成される。

BDドライブ２０１は、BD-ROMのローディング／リード／イジェクトを行い、BD-ROMに対するアクセスを実行する。具体的な構成としては、半導体レーザ（図示せず）、コリメートレンズ（図示せず）、ビームスプリッタ（図示せず）、対物レンズ（図示せず）、集光レンズ（図示せず）、光検出器（図示せず）を有する光学ヘッド（図示せず）を備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。集光された光ビームは、光ディスク上で反射／回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、生成された信号がBD-ROMから読み出されたデータに対応する。

システムLSI（再生部）１は、図３２に示すように、Read Buffer２、PID Filter３、Transport Buffer ４a,４b,４c,４d,４e、周辺回路４ｆ、Video Decoder for Left view５ａ、Video Decoder for Right view５ｂ、Video Plane（L）６a、Video Plane（R）６ｂ、切り替え器７、Graphics Decoder for Left view８a 、Graphics Decoder for Right view８ｂ 、Graphics Plane for Left view９a、Graphics Plane for Right view９ｂ、CLUT UNIT for L１０a、CLUT UNIT for R１０ｂ、OFFSET UNIT for L１１a、OFFSET UNIT for R１１ｂ、CLUT出力切り替え器１２、加算器１３、Audio Decoder１４を含んで構成される。

Read Buffer２は、典型的にはFIFOメモリであり、BD-ROMから読み出されたソースパケットを一旦格納しておき、転送速度を調整した上、PIDフィルタ３に転送するためのバッファである。具体的には、Read Buffer２は、ライトビュー用のソースパケットを格納するためのライトビューRead Bufferと、レフトビュー用のソースパケットを格納するためのレフトビューRead Bufferとからなる。

PIDフィルタ３は、Read Buffer２から出力される複数TSパケットに対してフィルタリングを施す。PIDフィルタ３によるフィルタリングは、TSパケットのうち、所望のPIDをもつもののみをTransport Buffer ４a,４b,４c,４d,４eの何れかに書き込むことでなされる。PID Filter３によるフィルタリングでは、バッファリングは必要ではない。従って、PID Filter３に入力されたTSパケットは、当該TSパケットのPIDに基づいて、時間遅延なく、Transport Buffer ４a,４b,４c,４d,４eの何れかに書き込まれる。

Transport Buffer４a,４b,４c,４d,４eは、PID Filter３から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。このTransport Buffer４a,４b,４c,４d,４eからTSパケットが取り出される速度を、速度Rxとする。
周辺回路４ｆは、Transport Buffer４ｃ、４ｄから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイヤロジックである。変換により得られた機能セグメントはCoded Data Buffer(EB)に格納される。

Video Decoder for Left view５ａは、PID Filter３から出力された複数TSパケットを復号して非圧縮形式のレフトビューピクチャを得てVideo Plane（L）６aに書き込む。
Video Decoder for Right view５ｂは、PID Filter３から出力された複数TSパケットを復号して非圧縮形式のライトビューピクチャを得てVideo Plane（R）６ｂに書き込む。
Video Plane（L）６aは、非圧縮形式のレフトビューピクチャを格納しておくためのメモリである。

Video Plane（R）６ｂは、非圧縮形式のライトビューピクチャを格納しておくためのメモリである。
切り替え器７は、レフトビューピクチャ及びライトビューピクチャの何れを加算器１３に出力するか切り替える。
Graphics Decoder for Left view８aは、レフトビューのＰＧスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてGraphics Plane for Left view９aに書き込む。具体的には、図３２に示すように、Coded Data Buffer(EB)８１a、PERIPHERAL CIRCUITRY８２a、Stream Graphics Processor８３a、Object Buffer(OB)８４a、Composition Buffer(CB)８５a、Graphics Controller８６aから構成される。

Coded Data Buffer(EB)８１aは、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、Transport Buffer４ｃに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS／DTSは、PESパケットと対応付けて格納される。

PERIPHERAL CIRCUITRY８２aは、Coded Data Buffer(EB)８１a−Stream Graphics Processor８３a間の転送、Coded Data Buffer(EB)８１a−Composition Buffer８５a間の転送を実現するワイヤロジックである。この転送処理において、現在時点がODSのDTSに示される時刻になれば、ODSを、Coded Data Buffer(EB)８１aからStream Graphics Processor８３aに転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをComposition Buffer(CB)８５aに転送するという処理を行う。

Stream Graphics Processor８３aは、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObject Buffer(OB)８４aに書き込む。このStream Graphics Processor８３aによるデコードは、ODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。上述したグラフィックオブジェクトのデコードレートRdは、このStream Graphics Processor８３aの出力レートである。

Object Buffer(OB)８４aは、ETSI EN 300 743標準規格におけるピクセルバッファに相当するバッファであり、Stream Graphics Processor８３aのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer８５aは、PCS、PDSが配置されるメモリである。
Graphics Controller８６aは、Composition Buffer８５aに配置されたPCSを解読して、PCSに基づく制御をする。具体的には、グラフィクスのObject Buffer(OB)８４aへの書き込み、及びObject Buffer(OB)８４aからのグラフィクスの読み出し、グラフィクスの表示を実行する。この制御の実行は、PCSを格納したPESパケットのPTSの値に示される時点においてなされる。

Graphics Decoder for Right view８ｂは、ライトビューのＰＧスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてGraphics Plane for Right view９ｂに書き込む。詳細な構成については、Graphics Decoder for Left view８aと同様であるので説明を省略する。
Graphics Plane for Left view９aは、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクス（レフトビュー）が格納される。

Graphics Plane for Right view９ｂは、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクス（ライトビュー）が格納される。
CLUT UNIT for L１０aは、設定されているpalette＿idにより示されるPDSのカラールックアップテーブルを用いて、Graphics Plane for Left view９aに格納されている画素コードを、Y,Cr,Cbといったピクセル値に変換する。

CLUT UNIT for R１０ｂは、設定されているpalette＿idにより示されるPDSのカラールックアップテーブルを用いて、Graphics Plane for Right view９ｂに格納されている画素コードを、Y,Cr,Cbといったピクセル値に変換する。
ここで、CLUT UNIT for L１０a及びCLUT UNIT for R１０ｂには、共通のpalette＿idが設定されている。

OFFSET UNIT for L１１aは、色変換されたレフトビュー非圧縮グラフィクスの奥行きを調整する。
OFFSET UNIT for R１１ｂは、色変換されたライトビュー非圧縮グラフィクスの奥行きを調整する。
CLUT出力切り替え器１２は、加算器１３に出力すべき非圧縮グラフィクスを、レフトビュー非圧縮グラフィクスとライトビュー非圧縮グラフィクスとの間で切り替える。

加算器１３は、CLUT UNIT for L１０a（またはCLUT UNIT for R１０ｂ）により色変換された非圧縮グラフィクスに、PDSに示されるT値(透過率)を乗じて、Video Plane（L）６a（またはVideo Plane（R）６ｂ）に格納された非圧縮状態のピクチャデータと加算し、合成画像を得て出力する。
Audio Decoder１４は、PID Filter３から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。

以上が再生部１の構成要素である。
図３１に戻って、HDMI送受信部２０２は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）に準拠したインタフェースを含み、再生装置とHDMI接続する装置（この例ではテレビ３００）との間でHDMI規格に準拠するように送受信を行うものであり、加算器１３により加算された映像と、オーディオデコーダ１４によってデコードされた非圧縮のオーディオデータとを、HDMI送受信部２０２を介してテレビ３００に伝送する。

テレビ３００は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からHDMI送受信部２０２を介して要求があると、要求された必要な情報（例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報）を再生装置へ返す。

このように、HDMI送受信部２０２を介することで、テレビ３００が立体視表示に対応しているかどうかの情報を、テレビ３００から取得することができる。
再生状態／設定レジスタ（PSR）セット２０３は、プレイリストの再生状態を格納する再生状態レジスタ、再生装置におけるコンフィグレーションを示すコンフィグレーション情報を格納する再生設定レジスタ、コンテンツが利用する任意の情報を格納できる汎用レジスタを含む、レジスタの集まりである。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置（時刻）を再生しているかなどの状態を現す。プレイリストの再生状態が変化した際は、再生制御エンジン２０６がPSRセット２０３に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJavaプラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。

また、PSRセット２０３には、例えば立体視再生ケーパビリティや立体視再生表示方式フラグ等が存在する。
立体視ケーパビリティは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。
立体視再生フラグは、ユーザが、立体視再生を実行することを意図しているかどうかを示す。

静的シナリオメモリ２０５は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。

再生制御エンジン２０６は、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、AV再生機能、プレイリストの再生機能を実行する。AV再生機能とは、DVDプレーヤ、CDプレーヤから踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、副映像切り替え、アングル切り替えといった処理である。プレイリスト再生機能とは、このＡＶ再生機能のうち、再生開始や再生停止をプレイリスト情報に従って行うことをいう。

ヒープメモリ２０７は、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である。
BD-Jプラットフォーム２０８は、BD-Jモードの動作主体であるJavaプラットフォームであり、Java2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsとをフル実装しており、クラスローダ、バイトコードインタプリタを含む。クラスローダは、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリに格納することにより、BD-Jアプリケーションのロードを行う。バイトコードインタプリタは、ヒープメモリ２０７に格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネイティブコードに変換して、MPUに実行させる。

動的シナリオメモリ２０９は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。

モード管理モジュールの一例であるモジュールマネージャ２１０は、BD-ROMから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モジュールマネージャ２１０によるモード管理とは、動的シナリオをコマンドインタプリタ２１１とＢＤ−Ｊモジュール２０８のどちらに実行させるかという、モジュールの割り当てである。
HDMVモジュールの一例であるコマンドインタプリタ２１１は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。HDMVモードの動作主体であるコマンドインタプリタは、シナリオプログラムを構成するナビゲーションコマンドを解読して実行するものである。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

UO探知モジュール２１２は、リモコン５００や再生装置２００のフロントパネルに対してなされたユーザ操作を検出して、ユーザ操作を示す情報（以降UO（User Operation）という）をモード管理モジュール２１０に出力する。そのUOから、現在の再生装置におけるモードに適切なUOのみを選んで、そのモードを実行するモジュールに受け渡す。例えばHDMVモードの実行中に、上下左右、アクティベートといったUOを受け付けた場合、HDMVモードのモジュールにこれらのUOを出力する。
＜プレイリスト再生処理＞
続いて、プレイリスト再生処理の詳細について説明する。

図３３は、プレイリス再生処理の処理手順を示すフローチャートである。
ステップＳ１においてプレイリスト情報ファイルを読み込み、ステップＳ２〜ステップＳ５の処理に突入する。ステップＳ２は、再生装置にケーパビリティが存在するか否かの判定である。ステップＳ３は、再生装置の接続相手であるテレビに、立体視再生の処理能力が存在するか否かの判定である。ステップＳ４は、カレントプレイリストの再生属性情報における表示方式フラグが有効かどうかの判定である。ステップＳ２〜ステップＳ４の何れかがNoと判定されれば、ステップＳ５に移行して、各プレイアイテム情報におけるSTN＿tableに基づくプレイアイテム再生を実行する。

ステップＳ２〜ステップＳ４の全てがYesであれば、ステップＳ５において各プレイアイテム情報におけるSTN＿table＿extensionに基づくプレイアイテム再生を実行する。
図３４は、STN＿table＿extensionに基づく再生手順を示すフローチャートである。
ステップＳ５１において、カレントPlayItem番号を"１"に初期化して、ステップＳ５２〜Ｓ６２のループに移る。このループは、カレントプレイアイテム番号に対してステップＳ５２〜ステップＳ６０の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップＳ６１)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップＳ６２でYes)。ステップＳ５２〜ステップＳ６０は、以下のものである。

ステップＳ５２において、ベースビューストリームのパケットIDに対応するエントリーマップを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿TimeをStart＿SPN[i]及びEnd＿SPN[i]に変換する。
エンハンスドビューストリームを選択し、カレントＰＧストリームを選択して(ステップＳ５３)、選択したストリームのカレントストリーム番号をPSRに書き込み(ステップＳ５４)、カレントストリーム番号に対応するSubPlayItemを特定する(ステップＳ５５)。エンハンスドビューストリームのパケットID[j]に対応するエントリーマップ[j]を用いて特定されたSubPlayItemIn＿Time、SubPlayItemOut＿TimeをStart＿SPN[j]、End＿SPN[j]に変換する(ステップＳ５６)。

パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップＳ５７)、パケットID[j]のTSパケット[j]をStart＿SPN[j]からEnd＿SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップＳ５８)。そしてステップＳ５９において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップＳ６０においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。以上がSTN＿table＿extensionに基づく再生手順である。

次にPGストリーム選択手順について説明する。STN＿table、またはSTN＿table＿extensionに基づき、PGストリームを選択する選択手順には、『Procedure when playback condition is changed』と、『Procedure when Stream change is requested』という2つの選択手順がある。PGストリーム選択は、再生制御エンジン２０６によりなされる。
Procedure when playback condition is changedは、何等かの事象が再生装置に生じたため、再生装置の状態が変化した際に実行すべき処理手順を示す。

Procedure when Stream Change is requestedは、ユーザがストリームの切り換えを要求した際、実行すべき処理手順を示す。
図３５（ａ）は、装置状態変化時におけるPSR2の設定手順を示すフローチャートである。ここで、PSR2は、PGのカレントストリーム番号を示すものとする。
ステップＳ１１は、STN＿tableにおけるentry数が0であるか否かの判定であり、もし0であればPSR2の値を維持する(ステップＳ１３)。

ステップＳ１２は、STN＿tableにおけるentry数は0ではない場合に、PSR２よりSTN＿tableのentry数が多く、尚且つ、条件(A)が真であるかを判定するものである。条件(A)とは、PSR２で特定されるPGストリームを再生する能力が再生装置に存在することである。もしステップＳ１２がYesであればPSR２を維持する(ステップＳ１４)。もしPSR２の値がentry数より大きいか、或は条件(A)を満たさない場合は、PSR2を再設定する(ステップＳ１５)。

図３５（ｂ）は、ストリーム変化時におけるPSR2の設定手順を示すフローチャートである。本フローチャートと、同図（ａ）との違いは、（ａ）におけるPSR2の表記がXに置き換えられている点である。このXは、User Operationに基づく値である。
本フローチャートにおけるステップＳ２０は、XよりSTN＿tableのentry数が多く、尚且つ、条件(A)が真であるかを判定するものである。条件(A)とは、PSR2で特定されるPGストリームを再生する能力が再生装置に存在することであり、PSR15（字幕ケーパビリティを示す）と、PGストリームのStream＿coding＿typeの比較で判定される。もしXがこの条件を満たすなら、PSR2にXを設定する(ステップＳ２１)。

もしXがentry数より大きいか、或は条件(A)を満たさない場合は、Xが、0xFFFFであるか否かを判定する(ステップＳ２２)。もしOxFFFFでなければ、ユーザが選択を意図するPGストリームの番号は無効であると考えられるので、ユーザ操作に基づく値Xを無視し、PSR2の設定値を維持する(ステップＳ２４)。もしPSR2の設定値が0xFFFFであるなら、PSR2を設定する(ステップＳ２３)。

図３６は、PSR2設定手順を示すフローチャートである。本フローチャートのステップＳ３１、ステップＳ３２は、STN＿tableに記述されているPGストリームのそれぞれについて、ステップＳ３３〜ステップＳ３５の処理を繰り返すループ処理になっている。本ループ処理において処理対象となるPGストリームをPGストリームiとする。ステップＳ３３は、PGストリームiが、グラフィクス字幕ストリームであるか、テキスト字幕ストリームであるかの判定であり、もしグラフィクス字幕であるならステップＳ３４に移行する。

ステップＳ３４は、グラフィクス字幕ストリームiが、以下の(a)(b)を満たすか否かの判定である。
(a)グラフィクス字幕ストリームiを再生する能力が再生装置に存在すること
(b)グラフィクス字幕ストリームiの言語属性が再生装置の言語設定と一致すること
この(b)の条件は、STN＿tableにおけるPG＿language＿codeがPSR16（装置の言語設定を示す）と一致するか否かの判定でなされる。

一方、ステップＳ３５は、テキスト字幕ストリームiが(a)(b)を満たすかを否かの判定である。
(a)テキスト字幕ストリームiをフォントで展開して再生する能力が再生装置に存在すること
(b)テキスト字幕ストリームiの言語属性が再生装置の言語設定と一致すること
(a)の条件を具備しているかの判定は、再生装置のPSR30が"再生能力有"を示すかどうかでなされる。(b)の条件を具備しているかの判定は、STN＿tableのtextST＿language＿codeがPSR16の設定値と一致しているかどうかでなされる。

以上のステップＳ３３〜ステップＳ３５の処理が全てのPGストリームについて繰り返されれば、ステップＳ３６〜ステップＳ４１の処理が実行される。
ステップＳ３６は、(a)を満たすグラフィクス字幕が存在しないかどうかの判定であり、もし存在しないのなら、Invalidな値(0xFFFF)をPSR2に設定する(ステップＳ３８)。
ステップＳ３７は、(a)(b)の双方を満たすPGストリームが存在するかどうかの判定であり、もし存在するのなら(a)(b)を満たすPGストリームのうち、STN＿tableにおけるエントリー順位が最も高いものをPSR2に設定する(ステップＳ４１)。

ステップＳ３９は、(a)のみを満たすグラフィクス字幕ストリーム、(a)のみを満たすテキスト字幕ストリームのうち、STN＿tableにおけるエントリー順位が最も高いものをPSR2に設定する。
PRS2が設定されると、再生装置においてレフトビュー及びライトビューを用いた３D再生が可能か否かを判定する。３D再生が可能である場合には、PSR2のストリーム番号に対応するレフトビューPGストリーム及びライトビューPGストリームのPIDをPID Filter３に設定して、パケットフィルタリングを行わせる。

そして、レフトビューグラフィクスデコーダ及びライトビューグラフィクスデコーダを起動して、２系統のTSパケット系列のデコードを行わせる。
以上のように本実施の形態によれば、レフトビューＰＧストリームの複数のＤＳとライトビューＰＧストリームの複数のＤＳとは、1対1に対応しており、対応するＤＳの画面構成セグメントには、同一のPTSが設定されている。また、対応するＤＳの画面構成セグメントにおいて、composition＿stateが同一の内容に設定されている。

そのため、一方のＰＧストリームのＤＳにおいて、そのcomposition＿stateが、例えばEpoch Startである場合には、対応する、他方のＰＧストリームのＤＳにおいても、そのcomposition＿stateは、Epoch Startである。
したがって、これらのＤＳを頭出しがなされることが判明している位置に配置することで、ランダムアクセスの際、一方のＰＧストリームがデコード可能であれば、必ず、他方のＰＧストリームのデコードも可能となる。ゆえに、ランダムアクセス時におけるグラフィクスの立体視を保証することができる。

また、レフトビューＰＧストリームとライトビューＰＧストリームとで対応するＤＳにおいて、composition＿number及びforced＿on＿flagが、同一の内容に設定されており、対応するＤＳのPDSが同一の内容に設定されている。さらに、WDSにおいてWindow＿width、window＿height、及びwindow＿vertical＿positionが同一の内容に設定されており、PCSにおいて、object＿cropping＿width、object＿cropping＿height、object＿cropping＿vertical＿position、及びobject＿vertical＿positionが同一の内容に設定されている。

このように、レフトビューＰＧストリームとライトビューＰＧストリームとで対応するＤＳにおいて、オブジェクト及び表示位置の水平座標（window＿ horizontal ＿position 、object＿horizontal＿position、object＿cropping＿horizontal＿position、）以外のフィールドが同一内容に設定されているため、再生装置において２つのグラフィクスコントローラの制御内容をほぼ同一内容にすることができ、ハードウェア構成の簡易化が可能になる。
（変形例１−１）
再生装置において、レフトビュー用にCLUT UNIT for L１０a、ライトビュー用にCLUT UNIT for R１０ｂを備える構成を示した。ただし、各CLUT UNITに設定すべきパレットのidが共通であったため、CLUT UNITを共通にすることが可能である。以下、レフトビュー及びライトビューとで共通のCLUT UNITへと替えた一変形例について説明する。

図３７は、変形例１−１における再生装置に搭載されるシステムLSIの内部構成を示す図である。
Graphics Plane for Left view９a及びGraphics Plane for Right view９ｂはそれぞれ、CLUT出力切り替え器１５に接続されている。
CLUT出力切り替え器１５は、CLUT UNIT１０に出力すべき非圧縮グラフィクスを、レフトビュー非圧縮グラフィクスとライトビュー非圧縮グラフィクスとの間で切り替える。

OFFSET UNIT１１は、CLUT UNIT１０により色変換されたレフトビューまたはライトビューの非圧縮グラフィクスの奥行きを調整し、加算器１３に出力する。
上述のように、Graphics Plane for Left view９a及びGraphics Plane for Right view９ｂの出力が、CLUT出力切り替え器１５を介して共通のCLUT UNIT１０に接続されているため、ハードウェア規模を削減できるとともに、２Ｄ用のGraphics Decoderから、少ない変更で３Ｄ用Graphics Decoderを構成できるというメリットがある。
（実施の形態２）
実施の形態１では、２デコーダモデルにおいて、ＰＧグラフィクスストリームの立体視を実現する手段について説明したが、本実施の形態では、２デコーダモデルにおけるインタラクティブグラフィクス（以下、「ＩＧ」という）ストリームの立体視について説明する。

ＩＧスストリームは、グラフィクスオブジェクトの対話的な表示を実現するグラフィクスストリームである。図３８（ａ）は、ＩＧストリームの構成を示す図である。第１段目は、AVClipを構成するTSパケット列を示す。第２段目は、グラフィクスストリームを構成するPESパケット列を示す。第２段目におけるPESパケット列は、第１段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ICS(Interactive Composition Segment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)、END(END of Display Set Segment)と呼ばれる機能セグメントからなる。ICSは、画面構成セグメントと呼ばれ、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。PESパケットと機能セグメントとの対応関係、及び他の機能セグメントについては、ＰＧと同様であるので説明を省略する。

図３８（ｂ）は、機能セグメントを変換することで得られるPESパケットを示す図である。図３８（ｂ）についてもＰＧと同様であるため、説明を省略する。
図３９は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にEpochを、第２段目にDisplay Setを、第３段目にDisplay Setの類型を、第４段目にDisplay Setに属する機能セグメントを、それぞれ示す。ＩＧストリームにも、Epoch Start、Acquisition Point、Normal Caseという類型があるが、これはPGで説明した通りである。

ＩＧストリームは、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための構成は、ICS内のInteractive＿compositionに存在する。以降ICS、Interactive＿compositionの内部構成について以下説明する。
図４０（ａ）（ｂ）は、ICSとInteractive＿compositionとの対応関係を示す図である。ICSとInteractive＿compositionとの対応関係には、図４０（ａ）に示すような1対1のものと、図４０（ｂ）に示すような1対多のものとがある。

対応関係が1対1になるのは、Interactive＿compositionのサイズが小さく、1つのICS内にInteractive＿compositionが収まる場合である。
1対多の対応関係になるのは、Interactive＿compositionのサイズが大きく、Interactive＿compositionがフラグメント化され、複数ICSに格納される場合である。複数ICSへの格納が可能なので、Interactive＿compositionサイズには制限がなく、512Kバイトであろうと、1Mバイトであろうと、Interactive＿compositionのサイズを大きくすることができる。ICS、Interactive＿compositionには1対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ICS、Interactive＿compositionの対応関係は、1対1であるとする。

図４１は、ICSの内部構成を示す図である。ICSには、Interactive＿Compositionの全体、又は、Interactive＿Compositionをフラグメント化することで得られた一部が格納されている。図４１の左側に示すように、ICSは、自身がICSであることを示す『segment＿descriptor』と、本ICSが想定している縦横の画素数、フレームレートを示す『video＿descriptor』と、『composition＿descriptor』と、Interactive＿Compositionの全体、又は、Interactive＿Compositionをフラグメント化することで得られた一部である『Interactive＿composition＿data＿fragment』とからなる。

図４１中の矢印cu1は、『composition＿descriptor』の内部構成をクローズアップして示す。この矢印cu1に示すように『composition＿descriptor』は、本ICSが属するDisplay Setが、Normal Case、Acquisition Point、Epoch Start、Effect＿Sequenceの何れであるかを示す『composition＿state』と、画面合成の回数を示す『Composition＿Number』とを含む。

図４１の矢印cu2は、Interactive＿compositionの内部構成をクローズアップしている。この矢印に示すようにInteractive＿compositionは、『Interactive＿composition＿length』,『Stream＿model』,『user＿interface＿model』,『composition＿time＿out＿pts』,『selection＿time＿out＿pts』,『user＿time＿out＿duration』、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報(1)(2)・・・(i)・・・(number＿of＿page-1)』を含む。

『Interactive＿composition＿length』は、Interactive＿compositionのデータ長を示す。
『Stream＿model』は、Interactive＿compositionが想定しているストリームモデルのタイプを示す。ストリームモデルとは、Interactive＿compositionがどのような形態でBD-ROMに記録されて、再生装置におけるコンポジションバッファ上でどのように扱われるかを示すものであり、Stream＿modelは、グラフィクスストリームがAVClipから多重分離されてコンポジションバッファ上にロードされたものであるか(i)、SubClipとして、コンポジションバッファにプリロードされたものであるか(ii)を示す。

『user＿interface＿model』は、Interactive＿compositionが想定しているユーザインタフェースモデルが、Always-onU/IであるかPop-upU/Iであるかを示す。Always-onU/Iとは、AVClipの再生進行に伴ってメニューの表示・消去がなされるユーザインタフェースであり、ポップアップU/Iとは、ユーザによる操作をトリガにしてメニューの表示・消去がなされるユーザインタフェースである。

『Composition＿time＿out＿pts』は、ICSが帰属するEpochの終期(Epoch END)を示す。ICSによる対話制御は、このEpoch終期(Epoch END)においてもはや不可能となるので、このcomposition＿time＿out＿ptsに示される時点が、対話制御の終期を意味する。
『selection＿time＿out＿pts』は、セレクテッド状態にあるボタンを自動的にアクティベートするためのタイムアウト時刻を示す。ボタンとは、マルチページメニューにおける個々の選択項目であり、かかるボタンの状態をアクティブ状態に変化させる時間を規定しているのがこのselection＿time＿out＿ptsである。

図中のIF文(if(Stream＿model=='0b'))は、上述したcomposition＿time＿out＿pts及びselection＿time＿out＿ptsが、Stream＿model=Multiplexedの際、出現する任意の情報要素であることを示している。ICSが想定しているストリームモデルがプリロードである場合、これらcomposition＿time＿out＿pts、selection＿time＿out＿ptsは存在しない。
『user＿time＿out＿dutration』は、ユーザ操作により表示され得るページを消去するためのタイムアウト時刻を示す。Always-onU/Iでは、2ndPage以降のPage(SubPageという)がユーザ操作により表示されるので、このuser＿time＿out＿dutrationのタイムアウトにより、SubPageのみが消去され、1stPageのみとなる。Pop-upU/Iでは、SubPageだけではなく、マルチページメニュー全体がユーザ操作により表示されるので、user＿time＿out＿dutrationのタイムアウトにより、全てのページが消去され何も表示されない状態(No Menu Display)になる。

図４２は、複数ページのうち、任意のもの(x枚目のページ)についてのページ情報の内部構成を示す図である。この図４２の左側に示すようにページ情報(x)は、ページxを一意に識別する識別子である『page＿id』, 『page＿version＿number』,『UO＿mask＿table』,ページ(x)の表示開始時あたって再生すべき表示効果を示す『in＿effect』,ページ(x)の表示終了時あたって再生すべき表示効果を示す『out＿effect』,ページ(x)にアニメーションを実行する際、適用すべきフレームレートを記述する『animation＿frame＿rate＿code』,『default＿selected＿button＿id＿ref』、『default＿activated＿button＿id＿ref』,『pallet＿id＿ref』,ページ(x)上の複数ボタンのそれぞれに対応する『ボタン情報(1)(2)・・・・・(number＿of＿buttons-1)』を含む。

『UO＿Mask＿Table』は、page(x)におけるユーザ操作の許可／不許可を示す。このマスクフィールドが不許可に設定されていれば、再生装置に対するユーザ操作は無効になる。
『default＿selected＿button＿id＿ref』は、Page(x)の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”OxFF”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ(Player Status Register(PSR))の設定値が優先的に解釈され、PSRに示されるボタンがセレクテッド状態になる。本フィールドが0xFFでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『default＿selected＿button＿id＿ref』に規定されたボタン番号でPSRを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。

『default＿activated＿button＿id＿ref』は、selection＿time＿out＿ptsに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。default＿activated＿button＿id＿refが”FF”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このdefault＿activated＿button＿id＿refが00であれば、自動選択はなされない。00,FF以外の値であれば本フィールドは、有効なボタン番号として解釈される。

『pallet＿id＿ref』は、Page(x)において、CLUT Unitに設定すべきパレットのidを示す。
『ボタン情報(Button＿info)』は、Page(x)上に表示される各ボタンを定義する情報である。以上のフィールドにより、Multi-Pageメニューにおける個々のページは特定される。続いてボタン情報の内部構成について説明する。Page(x)における任意のボタンをボタン(i)であると仮定した場合、このボタン(i)の内部構成が、どのようにして規定されるかについて説明する。図４２における破線の矢印cx1は、ボタン(i)を規定するボタン情報iの内部構成をクローズアップしている。

ページに表示される個々のボタンには、ノーマル状態、セレクテッド状態、アクティブ状態という3つの状態がある。ノーマル状態とは、単に表示されているに過ぎない状態である。これに対しセレクテッド状態とは、ユーザ操作によりフォーカスが当てられているが、確定に至っていない状態をいう。アクティブ状態とは、確定に至った状態をいう。かかる状態があるので、ボタン情報iには、以下の情報要素が規定されている。

『button＿id』は、ボタン(i)を、Interactive＿compositionにおいて一意に識別する数値である。
『button＿numeric＿select＿value』は、ボタン(i)の数値選択を許可するか否かを示すフラグである。
『auto＿action＿flag』は、ボタン(i)を自動的にアクティブ状態にするかどうかを示す。auto＿action＿flagがオン(ビット値1)に設定されれば、ボタン(i)は、セレクテッド状態になる代わりにアクティブ状態になる。auto＿action＿flagがオフ(ビット値0)に設定されれば、ボタン(i)は、選択されたとしてもセレクテッド状態になるにすぎない。

『button＿horizontal＿position』、『button＿vertical＿position』は、対話画面におけるボタン(i)の左上画素の水平位置、垂直位置を示す。
『neighbor＿info』は、ボタン(i)がセレクテッド状態になっていて、上下左右方向へのフォーカス移動が命じられた場合、どのボタンをセレクテッド状態に設定するかを示す情報であり、『upper＿button＿id＿ref』,『lower＿button＿id＿ref』,『left＿button＿id＿ref』,『Right＿button＿id＿ref』からなる。

『upper＿button＿id＿ref』は、ボタン(i)がセレクテッド状態である場合においてリモコンが操作され、上方向へのフォーカス移動を命じるキー(MOVEUPキー)が押下された場合、ボタン(i)の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、MOVEUPキーの押下は無視される。
『lower＿button＿id＿ref』,『left＿button＿id＿ref』,『Right＿button＿id＿ref』は、ボタン(i)がセレクテッド状態である場合において、リモコンが操作され、下方向へのフォーカス移動を命じるキー(MOVE Downキー),左方向へのフォーカス移動を命じるキー(MOVE Left キー),右方向へのフォーカス移動を命じるキー(MOVE Right キー)が押下された場合、ボタン(i)の押下の代わりに、セレクテッド状態にすべきボタンの番号を示す。もしこのフィールドにボタン(i)の番号が設定されていれば、これらのキーの押下は無視される。

『normal＿state＿info』は、ボタン(i)のノーマル状態を規定する情報であり、『normal＿start＿object＿id＿ref』、『normal＿end＿object＿id＿ref』、『normal＿repeated＿flag』を含む。
『normal＿start＿object＿id＿ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのnormal＿start＿object＿id＿refに記述される。

『normal＿end＿object＿id＿ref』は、ノーマル状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object＿ID』のうち、最後の番号がこのnormal＿end＿object＿id＿refに記述される。このactivated＿end＿object＿id＿refに示されるIDが、normal＿start＿object＿id＿refに示されるIDと同じである場合、このIDにて示されるグラフィクスオブジェクトの静止画が、ボタン(i)の絵柄になる。

『normal＿repeat＿flag』は、ノーマル状態にあるボタン(i)のアニメーション表示を反復継続させるかどうかを示す。
『selected＿state＿info』は、ボタン(i)のセレクテッド状態を規定する情報であり、『selected＿state＿sound＿id＿ref』、『selected＿start＿object＿id＿ref』、『selected＿end＿object＿id＿ref』、『selected＿repeat＿flag』を含む。

『selected＿state＿sound＿id＿ref』は、ボタン(i)の状態がセレクテッド状態に変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvと呼ばれるファイルに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。

『selected＿start＿object＿id＿ref』は、セレクテッド状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのselected＿start＿object＿id＿refに記述される。
『selected＿end＿object＿id＿ref』は、セレクト状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object＿ID』のうち、最後の番号がこのselected＿end＿object＿id＿refに記述される。このselected＿end＿object＿id＿refに示されるIDが、selected＿start＿object＿id＿refに示されるIDと同じである場合、このIDにて示されるグラフィクスオブジェクトの静止画が、ボタン(i)の絵柄になる。

『selected＿repeat＿flag』は、セレクテッド状態にあるボタン(i)のアニメーション表示を、反復継続するかどうかを示す。selected＿start＿object＿id＿refと、selected＿end＿object＿id＿refとが同じ値になるなら、本フィールド00に設定される。
『activated＿state＿info』は、ボタン(i)のアクティブ状態を規定する情報であり、 『activated＿state＿sound＿id＿ref』、『activated＿start＿object＿id＿ref』、『activated＿end＿object＿id＿ref』を含む。

『activated＿state＿sound＿id＿ref』は、button情報に対応するボタンのセレクテッド状態が変化した際、クリック音として再生させるべきサウンドデータを指定する情報である。この指定は、sound.bdmvに格納されているサウンドデータの識別子を記述することでなされる。本フィールドが0xFFである場合、サウンドデータは指定されていないことを意味し、クリック音再生はなされない。

『activated＿start＿object＿id＿ref』は、アクティブ状態のボタン(i)をアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番のうち、最初の番号がこのactivated＿start＿object＿id＿refに記述される。
『activated＿end＿object＿id＿ref』は、アクティブ状態のボタンをアニメーションで描画する場合、アニメーションを構成する複数ODSに付加された連番たる『object＿ID』のうち、最後の番号がこのactivated＿end＿object＿id＿refに記述される。

『ナビゲーションコマンド(navigation＿command)』は、ボタン(i)がアクティブ状態になれば、実行されるコマンドである。ナビゲーションコマンドの代表的なものは、SetButtonPageコマンドである。SetButtonPageコマンドは、Multi-Pageメニューの所望のページを表示させ、そのページにおける所望のボタンをセレクテッド状態に設定させることを再生装置に命じるコマンドである。かかるナビゲーションコマンドを用いることにより、オーサリング担当者は、ページ切り換えを簡易に記述することができる。

以上がボタン情報の内部構成である。
＜２デコーダモデルを採用する場合の制限＞
続いて、レフトビュー及びライトビューのそれぞれについて、上述した各機能セグメントの各フィールドをどのように設定するのかについて説明するが、基本的にはＰＧの場合と同様である。すなわち、レフトビューＩＧストリームに含まれるＤＳの類型、及びcomposition＿numberと、これに対応する、ライトビューＩＧストリームに含まれるＤＳの類型、及びcomposition＿numberとが、同一の内容に設定されている。

また、レフトビューのＤＳに含まれる画面構成セグメントと、これに対応するライトビューのＤＳに含まれる画面構成セグメントとでは、それら画面構成セグメントを格納した各PESパケットのPTSの値が同一の値に設定されている。
さらに、レフトビューのＤＳのパレット定義セグメントと、これに対応するライトビューのＤＳのパレット定義セグメントとでは、コード値と、輝度及び色差との対応関係が同一の内容に設定されており、palette＿idについても両者で同一になっている。

続いて、ICSにおいて上述した以外のフィールドをどのように記述するかについて説明する。図４３、４４は、Display Setに属するICSの記述例を示す図である。これらの図は、複数のボタンがグラフィクスプレーンに描画されている例を示している。
図４３は、レフトビューのＤＳに属するICSの記述例である。図４３に示すように、button情報（０）により定義されるタイトル１ボタンは、グラフィクスプレーンの座標系においてbutton＿horizontal＿position 1(left), button＿vertical＿positionを基準点(左上)とした範囲に配置される。また、button情報（number＿of＿buttons-1）により定義されるタイトルｍボタンは、グラフィクスプレーンの座標系においてbutton＿horizontal＿position m(left), button＿vertical＿positionを基準点(左上)とした範囲に配置される。こうすることにより、各タイトルボタンがグラフィクスプレーンに書き込まれる。これにより、タイトルボタンは動画像と合成され表示される。

図４４は、ライトビューのＤＳに属するICSの記述例である。図４４に示すように、button情報（０）により定義されるタイトル１ボタンは、グラフィクスプレーンの座標系においてbutton＿horizontal＿position 1(Right), button＿vertical＿positionを基準点(左上)とした範囲に配置される。また、button情報（number＿of＿buttons-1）により定義されるタイトルｍボタンは、グラフィクスプレーンの座標系においてbutton＿horizontal＿position m(Right), button＿vertical＿positionを基準点(左上)とした範囲に配置される。こうすることにより、グラフィクスがグラフィクスプレーンに書き込まれる。これにより、グラフィクスは動画像と合成され表示される。

上述のように、基準点として、button＿vertical＿positionはレフトビューとライトビューとで共通の値になっているが、button＿horizontal＿positionは、レフトビューとライトビューとで値が異なっている。
また、レフトビューとライトビューとでbutton ＿idには共通の値が設定される。これは、２デコーダ構成を採用した再生装置において、グラフィクスコントローラを２つのデコーダで共通にする構成をとっているからである。そのため、レフトビューとライトビューとで対応するＤＳのグラフィクスオブジェクトのbutton ＿idを同じ値に設定しておかないと、グラフィクスコントローラは、どのグラフィクスオブジェクト同士が対応関係にあるのか判別できないためである。

button＿情報における上記以外の項目である、neighbor＿info、normal＿state＿info、selectd＿state＿info、activated＿state＿info、navigation＿commandについては、レフトビューとライトビューとで同一の内容になる。
さらに、レフトビューとライトビューとで対応するＤＳにおいて、composition＿time＿out＿pts、selection＿time＿out＿pts、user＿time＿out＿dutrationが、同一の内容に設定されている。

以上の制限を加えることで、２デコーダ構成において、レフトビューＩＧストリームとライトビューＩＧストリームとによる立体視を実現することができる。
＜再生装置＞
続いて、本実施の形態における再生装置に搭載されるシステムLSIの詳細について説明する。図４５は、本実施の形態におけるシステムLSIの内部構成を示す図である。基本的な構成は図３２と同様である。図３２と異なる点は、グラフィクスコントローラ８６がレフトビューグラフィクスデコーダとライトビューグラフィクスデコーダとで共通になっていることである。以下、この理由を説明する。ＩＧの場合には、グラフィクスデコーダは、UO検知モジュールからUOの通知を受け付けることが想定される。そのため、グラフィクスコントローラが２つあると、各々がUO検知モジュールからUOの通知を受け付けることになる。そうすると、UO検知モジュールからグラフィクスコントローラへのUOの通知はシリアルにしか行えないため、グラフィクスコントローラ間に時間差が生じることになる。その結果、UOに基づく処理を実行する際に、グラフィクスコントローラ間で不具合が生じる可能性がある。そのため、グラフィクスコントローラ８６をレフトビューとライトビューとで共通にしている。

レフトビューとライトビューとで共通のGraphics Controller８６は、Composition Buffer８５aに配置されたICSを解読して、ICSに基づく制御をするとともに、Composition Buffer８５ｂに配置されたICSを解読して、ICSに基づく制御をする。
また、UO検知モジュール２１２からUOの通知を受け取ったときには、このUOに対応した制御をGraphics Decoder for Left view及びGraphics Decoder for Right viewのそれぞれに対して行う。

より詳細には、Graphics Controller８６は、Composition Buffer８５ａに配置されたICSにおける複数ページ情報のうち、PSR11により指定されているもの(カレントページ情報)のボタン情報を参照して、グラフィクスの描画を行う。この描画は、カレントページ情報内の各ボタン情報において、normal＿state＿infoのnormal＿start＿object＿id及びnormal＿end＿object＿idにより指定されているグラフィクスをObject Buffer８４ａから読み出し、Graphics Plane for Left view９ａに書き込むことでなされる。カレントページ情報内のボタン情報のうち、PSR10により指定されているものについては、selected＿state＿infoのselected＿start＿object＿id及びselected＿end＿object＿idにより指定されているグラフィクスをObject Buffer８４ａから読み出し、Graphics Plane for Left view９ａに書き込むこと描画される。かかる描画により、タイトル１ボタン〜タイトルｍボタンが配されたページがGraphics Plane for Left view９ａに現れ、動画に合成されることになる。ライトビューについても同様である。

以上のように本実施の形態によれば、レフトビューＩＧストリームとライトビューＩＧストリームとで対応するＤＳにおいて、composition＿stateが同一の内容に設定されているので、これらのＤＳを頭出しがなされることが判明している位置に配置することで、ＰＧストリームの場合と同様に、ランダムアクセス時におけるグラフィクスの立体視を保証することができる。

また、再生装置内のグラフィクスコントローラをレフトビューとライトビューとで共通化することにより、２コントローラ構成を採用する場合と比較し、ハードウェア規模の削減が可能になり、製品の低コスト化を実現することができる。
（補足）
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、本発明は上記実施の形態に限られないことは勿論である。
（１）再生装置２００は、ローカルストレージをさらに備えていてもよい。ローカルストレージは、ビルドインメディア、リムーバブルメディアを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。また、ダウンロードした追加コンテンツをどのようにBD-ROM上のデータとマージされるか、マージ規則が記載されたマージ管理情報もこのビルドインメディア、リムーバブルメディアに保存される。

ビルドインメディアとは例えば再生装置に内蔵されたハードディスクドライブ、メモリなどの書き込み可能な記録媒体である。
リムーバブルメディアとは、例えば可搬性を有する記録媒体であり、好適にはＳＤカードなどの可搬性を有する半導体メモリカードである。
リムーバブルメディアを半導体メモリカードとしたときを例に説明をすると、再生装置にはリムーバブルメディアを装着するためのスロット（図示せず）およびスロットに装着されたリムーバブルメディアを読み取るためのインターフェース（例えばメモリーカードI/F）が備えられており、スロットに半導体メモリを装着すると、リムーバブルメディアと再生装置とが電気的に接続され、インターフェース（例えばメモリーカードI/F）を利用して、半導体メモリに記録されたデータを電気信号に変換して読み出すことが可能となる。

再生装置２００がローカルストレージを備える場合には、さらに仮想ファイルシステムを備えるとしてもよい。仮想ファイルシステムは、追加コンテンツと共にローカルストレージにダウンロードされたマージ管理情報を元に、ローカルストレージに格納された追加コンテンツとBD-ROM上のコンテンツをマージさせた、仮想的なBD-ROM（仮想パッケージ）を構築する。HDMVモードの動作主体であるコマンドインタプリタやBD-Jモードの動作主体であるBD-Jプラットフォームからは、仮想パッケージとオリジナルBD-ROMを区別なく参照することができる。仮想パッケージ再生中、再生装置はBD-ROM上のデータとローカルストレージ上のデータの両方を用いて再生制御を行うことになる。

また、再生装置２００は、ネットワークインタフェースをさらに備えるとしてもよい。ネットワークインタフェースは、再生装置の外部と通信を行うためのものであり、インターネットでアクセス可能なサーバにアクセスしたり、ローカルネットワークで接続されたサーバにアクセスしたりすることが可能である。例えば、インターネット上に公開されたBD-ROM追加コンテンツのダウンロードに用いられたり、コンテンツが指定するインターネット上のサーバとの間でデータ通信を行うこうことでネットワーク機能を利用したコンテンツの再生を可能としたりする。BD-ROM追加コンテンツとは、オリジナルのBD-ROMにないコンテンツで、例えば追加の副音声、字幕、特典映像、アプリケーションなどである。BD-Jプラットフォームからネットワークインタフェースを制御することができ、インターネット上に公開された追加コンテンツをローカルストレージにダウンロードすることができる。
（２）追加コンテンツとして、レフトビュー及びライトビューのＰＧストリームを別途ダウンロードすることにより取得することがある。その場合に、一つのAVClip内に、レフトビュー及びライトビューのＰＧストリームのみが存在する場合が考えられる。この場合の制限について説明する。

図４６はＰＧストリーム（L）とＰＧストリーム（R）とを多重化する模式図である。ここで、1番上の段は、ＰＧストリーム（L）の構成例を示しており、ここではDisplay Set（L）1とDisplay Set（L）2の２つのＤＳから構成されている。
上から2段目は、ＰＧストリーム（L）をTSパケット化している様子を示している。
1番下の段は、ＰＧストリーム（Ｒ）の構成例を示しており、ここではDisplay Set（R）1とDisplay Set（R）2の２つのＤＳから構成されている。

下から2段目は、ＰＧストリーム（R）をTSパケット化している様子を示している。
ここで、3D表示のためにはレフトビューとライトビューとでペアになるＤＳが必要であるが、この図ではDisplay Set（L)1とDisplay Set（R)1、及びDisplay Set（L)2とDisplay Set（R)2が、それぞれペアとして3D表示のために用いられる。多重化の際には、ペアとなるレフトビューのＤＳとライトビューのＤＳは、本図に示すように、常にレフトビューのＤＳの方が、ストリーム上で先行するよう配置される。すなわち、レフトビューのＤＳの方が、TSパケットナンバーが小さくなるよう配置される。それに加えて、エントリーマップテーブルをレフトビューストリームに対して設定する。これにより、飛び込み再生時であっても、レフトビューのＤＳをデコードした直後にライトビューのＤＳをデコードできるため、常にレフトビューＤＳとライトビューＤＳをペアでデコードできる。よって、ペアのうち片方だけがデコードでき、もう一方がデコードできないといった事態を回避することができる。

また、本図に、飛び込み再生や特殊再生で用いられるエントリーの位置を記載しているが、レフトビューとライトビューとでペアとなるＤＳの両方ともが、エントリーで示されるTSパケットより後方に配置されることで、前述のエントリーを元に飛び込み再生が行われた際にも、ペアとなるレフトビュー及びライトビューのＤＳが正しく表示される。
なお、この例ではエントリーの後方にペアとなるＤＳを配置するように記載したが、両方のＤＳをエントリーの前方に配置するようにしてもよい。この場合、エントリーを元に飛び込み再生を行った場合、ペアとなる両方のＤＳがデコードできないため、レフトビュー及びライトビューのどちらか片方だけが表示されることを防ぐことができ、視聴者の違和感を軽減できる。
（３）上記各実施の形態では、レフトビューとライトビューとで別々のＰＧストリームを用意する場合について説明したが、ここでは1本のＰＧストリームで３Ｄ表示に対応させる第1の方法について説明する。図４７は、3D-PCSのデータ構造を示している。図１４で説明したPCSと3D-PCSとの差は、composition＿object()で示されるフィールドにおいて、objectが左目用か右目用かを示すL＿R＿flagが追加されていることである。例えば、あるcomposition＿object()が左目用を示す場合には、L＿R＿flagは0に設定され、右目用を示す場合には、L＿R＿flagは1に設定される。

通常3DでPGを表示する場合、左目用のObjectと右目用のObjectとがペアとなっている必要がある。つまり、3D-PCS内においてnumber＿of＿compositionの値は、必ず偶数である必要があり、また左目用composition＿object()と右目用composition＿object()とは同じ数だけ存在しなければならない。
また、機能セグメントとしての3D-PCSは、多重化（2Ｄ用のPCSを含む）される際、図４８（ａ）で示すように、ストリーム上において、2D用のPCSよりも先行した位置に配置されている。言い換えると、2D用のPCSよりもTSパケットナンバーが小さくなるよう配置されており、これにより、3D対応再生装置は、3D-PCSを先に見つけることが可能となるため、3D表示に必要ない2D用のPCSを読み飛ばすことが可能となる。

また、図中で3D-ODSとして表記されているのは、3D-PCSからしか参照されないObjectを含むODSを示しており、3D-ODSのsegment＿typeを、ODSのsegment＿typeと異なる値に設定しておくことによって、3D未対応の再生装置においては、3D-ODSを読み飛ばすことができるため、デコード負荷を軽減することが可能となる。さらに、あるObjectが２Ｄ用のPCSと3D-PCSとの両方から参照されている場合には、3D-ODSではなく、ODSとして定義しておくことで、2D用と3D用のObjectを共用することが可能となる。

また、例えば複数のcomposition＿object()が3D-PCSに存在する場合には、左目用のcomposition＿object()の次に必ず対応する右目用のcomposition＿object()を置くようにするとしてもよい。このようにペアとなるL用とR用のcomposition＿object()を連続して配置することにより、L用とR用のそれぞれのcomposition＿object()が持つforced＿on＿flagが同じであることを容易に検証可能となる利点がある。また、このようにLとRの並ぶ順序を制限することによって、各composition＿object()がL用かR用かを示すL-R＿flagを削除することも可能となるため、既存の2D用PCSとまったく同じデータ構造を採用することが可能となり、２D用PCSの解釈プログラムをほとんど変更することなく３D-PCSを解釈することも可能になる。

次に、1本のPGストリームで3D対応させる第２の方法について説明する。図４８（ａ）との違いは、左目用の3D-PCS（3D-PCS(L)）と右目用の3D-PCS（3D-PCS(R)）とを個別に用意していることである（図４８（ｂ）参照）。このように、予め左目用と右目用の3D-PCSを分ける利点について説明する。先ほどのLとRの両方の情報を含む3D-PCSの場合には、参照するObjectが左目用か、右目用かを示すためのフラグ(L＿R＿flag)を新規に設定する必要がある。また、フラグを設けない場合には、奇数番目のcomposition＿object()がL用で、偶数番目のcomposition＿object()がR用である、などの配置の制限が必要であった。つまり、3D-PCSをデコードする際には、2D用のPCSを解釈するプログラムを変更して、L＿R＿flagという新規フィールドを読めるようにする必要があり、または奇数番目のcomposition＿object()と偶数番目のcomposition＿onject()をそれぞれL用R用として処理する必要があった。

これに対して3D-PCS(L)と3D-PCS(R)のようにセグメントを分けて伝送することで、3D-PCS(L)及び3D-PCS(R)の構造は、2D用のPCSと同じ構造をとることができるため、2D用のPCSを解釈するプログラムをそのまま流用することができる。この場合、3D-PCS(L)及び3D-PCS(R)と2D用のPCSをデコーダが区別するために、segment＿typeを異なるものに設定すればよい。例えば、通常の2D用PCSのsegment＿typeが0x00と設定されているときに3D-PCS(L)用のsegment＿typeの値を0x01、3D-PCS(R)のsegment＿typeの値を0x02と設定する。または、3D-PCS(L)と3D-PCS(R)との配置に関して、3D-PCS(L)のＴＳパケット番号の方が小さくなるようにすることで、3D-PCS(L)と3D-PCS(R)との両方のsegment＿typeを0x01に設定したとしても、デコーダは、2D用のPCSと3D-PCSとを区別することが可能となる。

また、3D-PCS(L)と3D-PCS(R)と2D用のPCSの配置に関しても、3D-PCS(L)及び3D-PCS(R)を先に配置し、その後2D用のPCSを配置することで、3D対応再生装置では3D-PCSを先に見つけた場合には、続く2D用PCSを読み飛ばすことが可能となるため、デコード負荷を軽減することが可能となる。
（４）上記実施の形態では、レフトビューとライトビューとで対応するＤＳにおいてcomposition＿numberを等しく設定するとしたが、新しいフィールド(例えばL＿R＿Pairing＿number)を設けて、このフィールドが、対応するＤＳで等しくなるよう設定してもよい。
（５）上記実施の形態では、レフトビューＰＧストリームは、当該ストリーム内のオブジェクトを参照し、ライトビューＰＧストリームは、当該ストリーム内のオブジェクトを参照するとしたが、例えば、ライトビューＰＧストリームからレフトビューＰＧストリームのオブジェクトを参照するようにしてもよい。このように左右のＰＧストリームが、互いのオブジェクトを参照できるようにすることで、左右で同じオブジェクトを伝送する必要がなくなり、伝送に必要な帯域を節約できるというメリットがある。
（６）上記実施の形態では、液晶シャッタゴーグル１０４は、液晶シャッタと制御部とから構成され、視聴者の左目にレフトビュー用の画像を、右目にライトビュー用の画像を供する仕組みとしたが、これに限定される必要はない。例えば、液晶ではなく偏光フィルタを用いることにより立体視を実現する眼鏡が市販されているが、そのような機構が用いられた眼鏡を用いてももちろんよい。
（７）上記実施の形態では、液晶シャッタゴーグル１０４を用いて立体視視聴を行う方法を前提に説明したが、レフトビュー画像・ライトビュー画像をそれぞれ左眼・右眼に視聴させる他の方式を利用してもよい。例えば、サイドバイサイド方式や、レンチキュラレンズなどを表示ディスプレイに使い、眼鏡などの特別な視聴器具を利用しない方式を用いていても構わない。

さらに、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施の形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。
＜記録装置としての実施＞
再生装置２００が、ローカルストレージおよびリムーバブルメディアを具備している場合、これらへの書き込みを想定した構成になっているので、本願明細書に記載された再生装置は、記録装置としての機能を兼備しているといえる。再生装置２００が記録装置として機能する場合、以下の2つの態様によって、管理オブジェクトの書き込みを実行する。

i)再生装置２００が仮想パッケージを再生する機能をもつ場合、BD-Jオブジェクトの書き込みを以下のように行う。つまり、BD-ROMが装填された際、アプリケーションからの要求に従い、前記BD-ROMに対応する追加コンテンツを、ネットワークを介して、WWWサーバから取得する。取得された追加コンテンツはGUI管理テーブルが記述されてあるBD-Jオブジェクトを含む。「GUI管理テーブル」は、動作中のアプリケーションがGUIを行う際の管理テーブルであり、GUI表示を実行するにあたっての解像度や、GUIに用いるフォントデータ、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。

再生装置２００において、記録制御を行う制御部は、前記アプリケーションからの要求に従い、取得したBD-Jオブジェクトをローカルストレージに書き込む。こうすることで、BD-ROMに記録されたコンテンツと、前記ローカルストレージに記録された追加コンテンツとを組み合わせることで、前記仮想パッケージを構築することが可能になる。
ここで、前記BD-ROMには、ディスクルート証明書の識別子、BD-ROMコンテンツを頒布した組織の識別子、BD-ROMの識別子が記録されており、追加コンテンツが格納されるべき領域は、ディスクルート証明書識別子と、組織識別子と、BD-ROM識別子とを含むファイルパスによって特定される。

前記アプリケーションは、追加コンテンツが格納されるべき領域を特定するファイルパスを、制御部に引き渡すことで書き込みを行う。
前記ローカルストレージが、ディレクトリ名、及び、ファイル名が２５５文字以下に制限されたファイルシステムを有している場合、前記ローカルストレージへの書き込みに用いられるファイルパスは、８文字以下のディレクトリ名、及び、ファイル名で、かつ拡張子名が３文字以下である８.３形式のファイルシステムにおけるファイル名と、拡張子との指定を含む。

ii)再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービス(MODEST)の供給を受ける機能をもつ場合、BD-Jオブジェクトの書き込みを以下のように行う。
つまり再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービスによってBD-Jオブジェクトの供給を受ける際、リムーバブルメディアにおけるルートディレクトリの配下に、デフォルトのディレクトリと、MODESTディレクトリとをクリエイトして、MODESTディレクトリの配下に、BDMVディレクトリをクリエイトする。MODESTディレクトリは、ファーストMODESTディレクトリであり、ファーストMODESTディレクトリは、前記サービスを初めて受けた際、クリエイトされるMODESTディレクトリである。ユーザが２回目以降にサービスを受ける際、再生装置２００における制御部は、２回目以降のサービスに対応するMODESTディレクトリをクリエイトする。

そして、上述したように、GUI管理テーブルが記述されたBD-Jオブジェクトを取得すると、制御部は、デフォルトディレクトリにスタートアッププログラムを書き込み、MODESTディレクトリ配下のBDMVディレクトリにBD-Jオブジェクトを書き込む。このスタートアッププログラムは、記録媒体が再生装置２００に装填された際、最初に実行されるべきプログラムであり、BDMVディレクトリを選択する操作をユーザから受け付けるためのメニューを再生装置２００に表示させて、ルート変更機能を再生装置２００に実行させる。このルート変更機能は、メニューに対する選択操作がユーザによってなされた場合、選択されたBDMVディレクトリが属するMODESTディレクトリをルートディレクトリとして認識させる機能である。かかるルート変更機能によって、BD-ROMを再生するのと同じ制御手順によって取得したBD-Jオブジェクトに基づく再生制御を実行することができる。
＜Java(登録商標)アプリケーション＞
BD-Jアプリケーションは、例えば電子商取引(EC(Electronic Commerce))のクライアントアプリケーションであってもよいし、ネット対戦型のオンラインゲームであってもよい。更に、検索エンジンと連携して、様々なオンラインサービスを、ユーザに供給するものでもよい。
＜GUI管理テーブルを組込む単位＞
GUI管理テーブルをBD-Jオブジェクトに設けてもよい。また、GUI管理テーブルをプレイリスト情報やプレイアイテム情報に対応付けるように設けて、カレントプレイリストが特定のプレイリストになったタイミングまたはカレントプレイアイテムが、特定のプレイアイテムになった際、プレーンメモリの解放を行った上で、立体視再生のためのプレーンメモリの確保又は平面視再生のためのプレーンメモリの確保を実行してもよい。このようにすることで、メモリデバイスの領域管理がより決め細かい時間精度でなされることになる。
＜立体視のためのビデオストリーム＞
レフトビュー用、ライトビュー用のビデオストリームをBD-ROMに記録しておくというのは、一例に過ぎない。ピクチャ毎に、画素毎の奥行き値を表すビデオストリームをエンハンスドビュービデオストリームとしてBD-ROMに記録しておいて、再生に供してもよい。
＜実装すべきパッケージ＞
再生装置の実施にあたっては、以下のBD-J Extensionを再生装置に実装するのが望ましい。BD-J Extensionは、GEM[1.0.2]を越えた機能を、Java(登録商標)プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-J Extensionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java(登録商標) Media FrameWorkに追加すべき、特殊機能を提供する。アングル、音声、字幕の選択についての制御が、このパッケージに追加される。
・org.bluray.ti
このパッケージは、GEM[1.0.2]における"サービス"を"タイトル"にマップして動作するためのAPIや、BD-ROMからタイトル情報を問い合わせる機構や新たなタイトルを選択する機構を含む。
・org.bluray.application
このパッケージは、アプリケーションの生存区間を管理するためのAPIを含む。また、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問い合わせるAPIを含む。
・org.bluray.ui
このパッケージは、BD-ROMに特化されたキーイベントのための定数を定義し、映像再生との同期を実現するようなクラスを含む。
・org.bluray.vfs
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、BD-ROMに記録されたコンテンツ(on-discコンテンツ)と、BD-ROMに記録されていないLocal Storage上のコンテンツ(off-discコンテンツ)とをバインドする機構(Binding Scheme)を提供する。

Binding Schemeとは、BD-ROM上のコンテンツ(AVクリップ、字幕、BD-Jアプリケーション)と、Local Storage上の関連コンテンツとを関連付けるものである。このBinding Schemeは、コンテンツの所在に拘らず、シームレス再生を実現する。
＜プログラミング言語の適用範囲＞
上記実施形態では、仮想マシンのプログラミング言語としてJava（登録商標）を利用したが、Java（登録商標）ではなく、UNIX（登録商標） OSなどで使われているB-Shellや、Perl Script、ECMA Scriptなど他のプログラミング言語であっても良い。
＜マルチドライブ化＞
上記実施形態では、記録媒体の一例としてBD-ROM、BD-ROMからデータを読み出す機能を有する具体的な手段の一例としてBD-ROMドライブを例に挙げて説明をした。しかしながら、BD-ROMは単なる一例であり、記録媒体としてBD-R、BD-RE、DVD、CDなどの光ディスク媒体であっても、これらの記録媒体に上述したデータ構造を有するデータが格納されていること、これらの記録媒体を読み取るドライブ装置があれば、上述の実施の形態で説明した動作が可能である。

各実施の形態における記録媒体は、光ディスク、半導体メモリカード等、パッケージメディア全般を含んでいる。上記実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をしたが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ３Ｄコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。

また、記録媒体は光ディスク以外にも例えば、SDメモリカードなどのリムーバブルメディア（半導体メモリカード）であっても本発明の実施は可能である。
BD-ROMの代わりに半導体メモリを用いた場合には、半導体メモリカード内のデータを読み出すためのインタフェース（メモリカードＩ／Ｆ）を介してリードバッファ２、ヒープメモリ２０７、動的シナリオメモリ２０９、静的シナリオメモリ２０５に、データが転送されるように構成すればよい。

より詳細には、再生装置２００のスロット（図示せず）に半導体メモリカードが挿入されると、メモリカードＩ／Ｆを経由して再生装置２００と半導体メモリカードが電気的に接続される。半導体メモリカードに記録されたデータはメモリカードＩ／Ｆを介してリードバッファ２、ヒープメモリ２０７、動的シナリオメモリ２０９、静的シナリオメモリ２０５に転送されるように構成すればよい。

続いて、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。BD-ROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。
例えば、BD-ROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。

以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。
一方、BD-ROMには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するMKB（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びMKBに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、MKB、及び暗号化タイトルキーは対になっており、さらにBD-ROM上の通常コピーできない領域（BCAと呼ばれる領域）に書き込まれた識別子（例えばボリュームID）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。

装填されたBD-ROMを再生装置において再生する場合、例えばBD-ROM内の暗号化タイトルキー、MKBと対になっている（または対応する）デバイスキーが再生装置内になければ、暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵（タイトルキー）は、鍵自体が暗号化されて（暗号化タイトルキー）BD-ROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵を導き出すことができないからである。

逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しければ、例えば上述の暗号解読に必要な鍵（デバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。

以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み／書込み可能な半導体メモリ（例えばSDカードなどの可搬性を有する半導体メモリカード）に適用した場合においても、実施が可能である。
例えば、BD-ROMに記録されるデータに相応するデータを例えば電子配信を利用して半導体メモリカードに記録して、半導体メモリカードから再生をするような構成としても良い。電子配信を利用して必要なデータを配信し、配信されたデータを記録する場合においても、配信されたデータのうちの一部または全てのデータに対して必要に応じて暗号化を行なって配信し、半導体メモリに必要なデータについては暗号化がなされたままで記録するのが望ましい。

電子配信を利用して、本実施の形態で説明をしたデータに相応するデータ（配信データ）を半導体メモリに記録する動作について説明をする。
上述の動作は本実施の形態において説明をした再生装置がそのような動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリとしてSDカードを例に説明をする。

再生装置が備えるスロットに挿入されたSDメモリカードに配信データを記録する場合、まず配信データを蓄積する配信サーバ（図示せず）へ配信データの送信を要求する。このとき再生装置は挿入したSDメモリカードを一意に識別するための識別情報（例えば個々のSDメモリカード固有の識別番号、より具体的には、例えばSDメモリカードのシリアル番号等）をSDメモリカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。

この、SDメモリカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。

例えば配信サーバは、秘密鍵を保持しており、半導体メモリカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。

生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリ固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモリ固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。

次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリカードの記録領域に記録する。
次に、半導体メモリカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）、署名情報、半導体メモリカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。

署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。

半導体メモリカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
具体的には、
（１） 公開鍵情報に含まれる半導体メモリ固有の識別情報と半導体メモリカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック
（２） 再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック
（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番どのような順序で行なってもよい。

上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリ固有の識別情報と半導体メモリに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。

また、公開鍵情報に含まれる半導体メモリカードの固有の識別情報と半導体メモリカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリ固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリ固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いて、暗号化されたデータの解読を行なう。

例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。

このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリ固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。

また半導体メモリカードに予め記録されている半導体メモリカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリカードに予め記録されている固有の識別番号（例えばSDメモリカードを例にすればSDメモリカードのシリアル番号等）は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の（１）の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。

従って、半導体メモリカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリカードは、半導体メモリカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域（第１の記録領域と称す）とは別の記録領域（第２の記録領域と称す）に設けること、およびこの第２の記録領域へのアクセスをするための制御回路を設けるとともに、第２の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。

例えば、第２の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第２の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第２の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。

再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリカードに記録する要求するアプリケーションは、メモリカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行すると、要求を受けた制御回路は第２の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第１の記録領域に記録するように構成すればよい。

また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリカードに記録を要求するアプリケーションは、メモリカードＩ／Ｆを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のＸ.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。

また、半導体メモリカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリカードが有する制御回路を介してアクセスする必要は必ずしもない。
＜プログラムの実施形態＞
各実施の形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。

ここで生成されたオブジェクトプログラムは、各実施の形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネイティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
＜システムLSIの単体実施＞
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。

ここでパッケージの種別に着目するとシステムLSIには、QFP(クッドフラッド アレイ)、ＰＧA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。ＰＧAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、他の回路とのインタフェースとしての役割を担っている。システムLSIにおけるピンには、こうしたインタフェースの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置２００の中核としての役割を果たす。

かかるシステムLSIは、再生装置２００は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。
上記実施の形態で示したように、バッファやビデオデコーダ、オーディオデコーダ、グラフィクスデコーダをも、一体のシステムLSIにする場合、システムLSIのアーキテクチャは、Uniphierアーキテクチャに準拠させるのが望ましい。

Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。
・データ並列プロセッサDPP
これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。

・命令並列プロセッサIPP
これは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなる「Local Memory Controller」、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなる「Processing Unit部」、複数アプリケーションの並列実行をProcessing Unit部に行わせる「Virtual Multi Processor Unit部」で構成される。

・MPUブロック
これは、ARMコア、外部バスインタフェース(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(General Purpose Input Output)、同期シリアルインタフェースなどの周辺インタフェースで構成される。
・ストリームI/Oブロック
これは、USBインタフェースやATA Packetインタフェースを介して、外部バス上に接続されたドライブ装置、ハードディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。

・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。
・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。

具体的な生産手順の詳細は以下のものになる。まず各実施の形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。
そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインタフェース等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証したりする等の調整を加えながら、回路図を完成させてゆく。

回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。
こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施の形態に示した再生装置２００の内部構成図を基に作ることができる。

尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUT(Look Up Table)に記載されている入出力の組合せに基づき、縦・横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFＰＧAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。

本実施の形態においては、ミドルウェアとシステムLSIに対応するハードウェア、システムLSI以外のハードウェア、ミドルウェアに対するインタフェースの部分、ミドルウェアとシステムLSIとの間のインタフェースの部分、ミドルウェアとシステムLSI以外の必要なハードウェアとの間のインタフェースの部分、ユーザインタフェースの部分で実現し、これらを組み込んで再生装置を構成したとき、それぞれが連携して動作することにより特有の機能が提供されることになる。

ミドルウェアに対するインタフェース、および、ミドルウェアとシステムLSIのインタフェースを適切に定義することにより、再生装置のユーザインタフェース部分、ミドルウェア部分、システムLSI部分をそれぞれ独立して並行開発することができ、より効率よく開発することが可能となる。なお、それぞれのインタフェースの部分のきり方には、様々なきり方がある。例えば、ビデオデコーダ、グラフィクスデコーダ、オーディオデコーダ、加算器（合成部）を一チップ化したとき、これらを制御するミドルウェアおよびこれらと対応するミドルウェアとの間のインタフェースの部分について、チップを開発する側で開発をし、完成後、チップを再生装置に組み込むとともに、開発したミドルウェア、インタフェース部分を再生装置内のメモリなどの記憶部に組み入れることにより、再生装置側の開発とチップ側の開発を並行して行なうことができるようになり、開発効率が向上する。

開発したチップと開発したチップに関連するミドルウェアとの間のインタフェース部分について、共通にすると、汎用性が高くなる。
なお、システムLSIにて構成をした部分に関しては、LSIでしか構成ができないというものではなく、システムLSIに含まれるべき機能に対応する信号処理回路を用いて構成をしても良いことは言うまでもない。
＜記録方法＞
記録媒体の作り方、つまり、所定のデータが記録された記録媒体を得るための記録方法の使用形態について説明する。

上記各実施の形態に係る記録方法は、AVクリップやそれ以外のデータをリアルタイムに作成して、記録媒体の領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するという間接的な書き込み、つまり、プレフォーマットレコーディングも含む。上記各実施の形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマッティングレコーディングによる記録方法の何れの記録方法によっても特定されるものでもある。

この記録方法は、動画、音声、字幕、メニューといったデータ素材のインポートを行うステップと、インポートされたデータ素材をデジタル化して圧縮符号化し、MPEGに従ったエンコードを行うことでPESストリームを得るステップと、PESストリームを多重化してAVクリップを得るステップと、Java(登録商標)プログラム、多重化ステップで得られたAVクリップを入力とし、BD-ROMに準拠したファイルシステムフォーマットでAVファイル,非AVファイルを作成するステップと、BD-ROMに記録されるべきデータのうち、非AVファイルを記録媒体に書き込むステップ、AVファイルを記録媒体に書き込むステップとを含む。
＜ボリューム領域におけるエクステントの位置付け＞
所定のデータがファイルに格納されて記録媒体に記録されている場合、ファイルシステム上では、“エクステント”という態様で扱われることはすでに説明した。記録媒体において、このエクステントのアドレスは、以下のようにして管理されている。

エクステントは、ボリューム領域におけるパーティション空間において、物理的に連続する複数のセクタ上に形成される。パーティション空間は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。

「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。

「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリについての説明である。続いて、ディレクトリファイルの詳細について説明する。

「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。

「下位ファイルのファイル識別記述子」は、自身の配下にある下位ファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。

これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリからBDMVディレクトリのファイルエントリに到達することができ、また、BDMVディレクトリのファイルエントリからPLAYLISTディレクトリのファイルエントリに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリにも到達することができる。

「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。

「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261”が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号（LBN）を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位２ビットは、“０”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“１”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“０”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。

上述したようなファイルエントリのアロケーション識別子を参照することで、プレイリスト情報ファイル、クリップ情報ファイル、AVクリップファイル、BD-Jオブジェクトファイル、JARアーカイブファイルを構成するエクステントのアドレスを知得することができる。
本願の主眼となるストリーム、データ、フラグを格納したファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリにおけるアロケーション識別子を辿ってゆくことで、アクセスすることができる。
＜ファイルオープン＞
記録媒体上のファイルを、装置内に読み込む際の処理について説明する。

上述したようなAVストリーム、Index.bdmv、JARファイル、BD-Jオブジェクトは、ファイル構造、ディレクトリ構造に従ってBD-ROMに記録されているので、再生装置は、ファイルオープンのためのシステムコールを行うことで、これらをメモリに読み出すことができる。
ファイルオープンとは、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCB(File Control Block)を確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。
＜リアルタイムレコーディングへの適用＞
AVクリップ、プレイリスト情報は、オーサリングシステムにおけるプリレコーディング技術にて、BD-ROMに記録され、ユーザに供給されることを前提としたが、リアルタイムレコーディングにてBD-RE又はBD-R、ハードディスク、半導体メモリカードに記録され、ユーザに供給されるものであってもよい。

この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。
リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TS形式のデジタルストリームを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBD-RE,BD-R等に書き込む。

デジタルストリームの書き込みと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
そして、装置外部から入力されるトランスポートストリームからビデオストリームにおけるGOPの先頭位置が検出されるか、エンコーダによってビデオストリームのGOPが生成されれば、記録装置の制御部は、このGOPにおいて、先頭に位置するイントラピクチャのPTSと、このGOPの先頭部分を格納したソースパケットのパケット番号とを取得して、このPTS及びパケット番号の組みを、EP＿PTSエントリー及びEP＿SPNエントリーの組みとして、クリップ情報ファイルのエントリーマップに追記する。以降、GOPが生成される度に、EP＿PTSエントリー及びEP＿SPNエントリーの組みを、クリップ情報ファイルのエントリーマップに追記してゆく。この際、GOPの先頭がIDRピクチャである場合は、“オン”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。GOPの先頭がIDRピクチャでなければ場合は、“オフ”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。

また、クリップ情報ファイルにおけるストリームの属性情報については、記録されるべきストリームの属性に従い設定する。以上のようにしてAVクリップ、クリップ情報が生成されてBD-RE,BD-Rに書き込まれれば、このクリップ情報内のエントリーマップを介して、再生経路を定義するプレイリスト情報を生成し、BD-RE,BD-Rに書き込む。このような処理を、リアルタイムレコーディング技術において実行することで、AVクリップ−クリップ情報−プレイリスト情報という階層構造をBD-RE,BD-R上に得ることができる。
＜マネージドコピーを実現する記録装置としての実施＞
各実施の形態で説明した再生装置は、マネージドコピーによってデジタルストリームの書き込む機能を有していてもよい。

マネージドコピーとは、BD-ROM等の読み出し専用記録媒体に記録されているデジタルストリームやプレイリスト情報、クリップ情報、アプリケーションプログラムを、別の光ディスク（BD-R，BD-RE，DVD-R，DVD-RW，DVD-RAM等）やハードディスク、リムーバブルメディア（SDメモリカード、メモリスティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等）などの読み書き可能な記録媒体へコピーする際、サーバと通信を行い、認証が行われ許可された状態においてのみコピー実行可能にする技術である。この技術により、バックアップ回数を制限したり、課金された状態でのみバックアップを許したりする等の制御を行うことができる。

BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。
マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで“トランスコード”とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させたりする処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディング技術の処理を行うことで、AVClip、Clip情報、プレイリスト情報を得る必要がある。
＜オンデマンドマニュファクチャサービス又は電子的セルスルーサービス(MODEST)で使用される記録装置＞
再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービス(MODEST)の供給を受ける機能をもつ場合、BD-Jオブジェクトの書き込みを以下のように行う。つまり再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービスによってBD-Jオブジェクトの供給を受ける際、リムーバブルメディアにおけるルートディレクトリの配下に、デフォルトのディレクトリと、MODESTディレクトリとをクリエイトして、MODESTディレクトリの配下に、BDMVディレクトリをクリエイトする。MODESTディレクトリは、ファーストMODESTディレクトリであり、ファーストMODESTディレクトリは、前記サービスを初めて受けた際、クリエイトされるMODESTディレクトリである。ユーザが２回目以降にサービスを受ける際、再生装置２００における制御部は、２回目以降のサービスに対応するMODESTディレクトリをクリエイトする。

そして、上述したように、GUI管理テーブルが記述されたBD-Jオブジェクトを取得すると、制御部は、デフォルトディレクトリにスタートアッププログラムを書き込み、MODESTディレクトリ配下のBDMVディレクトリにBD-Jオブジェクトを書き込む。このスタートアッププログラムは、記録媒体が再生装置２００に装填された際、最初に実行されるべきプログラムであり、BDMVディレクトリを選択する操作をユーザから受け付けるためのメニューを再生装置２００に表示させて、ルート変更機能を再生装置２００に実行させる。このルート変更機能は、メニューに対する選択操作がユーザによってなされた場合、選択されたBDMVディレクトリが属するMODESTディレクトリをルートディレクトリとして認識させる機能である。かかるルート変更機能によって、BD-ROMを再生するのと同じ制御手順によって取得したBD-Jオブジェクトに基づく再生制御を実行することができる。
＜データ構造の記述の仕方＞
各実施の形態に示したデータ構造のうち、ある決まった型の情報が複数存在するという繰り返し構造は、for文に、制御変数の初期値と、繰り返し条件とを設定することで定義することができる。

また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。このように、各実施の形態に示したデータ構造は、高級プログラミング言語の文法によって記述することができるので、各実施の形態に示したデータ構造は、構文解析、最適化、資源割付、コード生成といった、コンパイラによる翻訳過程を経て、上記プログラムと同様、コンピュータが読み取り可能なコンピュータコードに変換された状態で記録媒体に記録される。こうして、高級プログラミング言語によって記述されたデータ構造は、オブジェクト指向言語においては、クラス構造体のメソッド以外の部分、つまり、クラス構造体における配列型のメンバー変数として扱われ、プログラムの一部をなす。つまり、各実施形態のデータ構造は、コンピュータコードに変換されて記録媒体に記録され、プログラムのメンバー変数となるため、実質的にはプログラムと同じものであり、コンピュータ関連発明として保護を受けるものである。
＜プログラムにおけるプレイリスト情報、クリップ情報の位置付け＞
プレイリスト情報に基づきAV再生を行う実行形式のプログラムは、記録媒体からメモリにロードされ、コンピュータによる実行に供された際、メモリ上において、textセクション、dataセクション、bssセクション、stackセクションといった複数のセクションから構成されることになる。

textセクションは、プログラムコード列や、初期値、書き換えられることがないデータから構成される。
dataセクションは、初期値をもち、実行中に書き換えられる可能性があるデータが配置される。記録媒体において、ファイルに格納され、随時アクセスされるようなデータは、このdataセクションに格納される。

bssセクションは、初期値をもたないデータが配置される。textセクションは、bssセクションのデータをアドレス指定でアクセスするため、コンパイル、リンク時に決定したRAMに、bssセクションのための領域を確保せねばならない。
stackセクションは、必要に応じて一時的にプログラムに与えられる領域であり、各フローチャートの処理を実現するにあたって、一時的に使用されるようなローカル変数は、ここに格納される。

bssセクションは、プログラムの初期化時に、初期値が設定され、stackセクションは、プログラムの初期化時に、必要領域が確保される。
プレイリスト情報及びクリップ情報は、上述したようにコンピュータコードに変換されて記録媒体に記録されているため、プログラムの実行時において、上述したtextセクションにおける“書き換えられることのないデータ”、又は、上述したdataセクションにおける“ファイルに格納され、随時アクセスされるようなデータ”として管理されることになる。各実施形態に示したプレイリスト情報、クリップ情報は、プログラムの実行時において、プログラムの構成要素となるべきものであり、プレイリスト情報、クリップ情報は、単なるデータの提示に該当しない。

上記実施の形態及び上記補足をそれぞれ組み合わせるとしてもよい。

本発明は、３D映像コンテンツを記録する記録媒体に適用可能であり、特に、レフトビュー及びライトビューのPGストリームにより３Dキャラクターの立体視を実現する場合に有効である。

１００ BD-ROM
２００ 再生装置
３００ テレビ
４００ 液晶シャッタゴーグル
５００ リモコン
２０１ BDドライブ
２０２ HDMIインタフェース
２０３ 再生状態／設定レジスタセット
２０４ 不揮発メモリ
２０５ 静的シナリオメモリ
２０６ 再生制御エンジン
２０７ ヒープメモリ
２０８ BD-Jプラットフォーム
２０９ 動的シナリオメモリ
２１０ モード管理モジュール
２１１ コマンドインタプリタ
２１２ UO検知モジュール
１ 再生部
２ Read Buffer
３ PID Filter
４a,４b,４c,４d,４e Transport Buffer
４ｆ 周辺回路
５ａ Video Decoder for Left view
５ｂ Video Decoder for Right view
６ａ Video Plane（L）
６ｂ Video Plane（R）
７ 切り替え器
８a Graphics Decoder for Left view
８ｂ Graphics Decoder for Right view
９a Graphics Plane for Left view
９ｂ Graphics Plane for Right view
１０a CLUT UNIT for L
１０ｂ CLUT UNIT for R
１１a OFFSET UNIT for L
１１ｂ OFFSET UNIT for R
１２ CLUT出力切り替え器
１３ 加算器
１４ Audio Decoder

Claims (2)

1. 配信装置から配信されたデジタルストリームを受信し再生する再生装置であって、
   前記デジタルストリームは、ビデオストリームと、レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームとを含み、
   前記レフトビューグラフィクスストリーム及び前記ライトビューグラフィクスストリームは、何れも１つ以上のディスプレイセットを含み、
   前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に用いられるデータ群であり、
   前記レフトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットは、前記ライトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットと１対１で対応しており、対応するディスプレイセットには、前記ビデオストリームの再生時間軸上において同一の再生時間が設定されており、
   前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に必要な全てのデータを含んでいるか、直前のディスプレイセットからの差分であるのかを示す状態情報を含み、
   前記レフトビューグラフィクスストリームと前記ライトビューグラフィクスストリームとで対応するディスプレイセットに含まれる状態情報が、同一の内容を示しており、
   前記配信装置から放送またはネットワークを経由して配信されたデジタルストリームを受信する受信手段と、
   前記ビデオストリームをデコードするビデオデコーダと、
   前記レフトビューグラフィクスストリームをデコードするレフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスストリームをデコードするライトビューグラフィクスデコーダと
   を備え、
   前記レフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスデコーダはそれぞれ、
   前記データ群のうちグラフィクスオブジェクトを定義するデータをデコードしてグラフィクスオブジェクトを得るプロセッサと、
   デコードにより得られたグラフィクスオブジェクトを格納するオブジェクトバッファと、
   前記データ群のうちグラフィクスオブジェクトを用いた画面構成を規定するデータを格納するコンポジションバッファと、
   を備え、
   前記レフトビューグラフィクスデコーダ及び前記ライトビューグラフィクスデコーダは、共通の構成要素として、グラフィクスコントローラを備え、
   前記グラフィクスコントローラは、前記再生時間になると、前記レフトビューグラフィクスデコーダ内のコンポジションバッファに格納された、画面構成を規定する前記データ、及び前記ライトビューグラフィクスデコーダ内のコンポジションバッファに格納された、画面構成を規定する前記データを解読して、解読したこれらのデータに基づき、前記レフトビューグラフィクスデコーダ内のオブジェクトバッファのグラフィクスオブジェクトを用いてレフトビュー用の画面構成を行うとともに、前記ライトビューグラフィクスデコーダ内のオブジェクトバッファのグラフィクスオブジェクトを用いてライトビュー用の画面構成を行う
   ことを特徴とする再生装置。
2. デジタルストリームを放送またはネットワークを経由して再生装置に配信する配信装置であって、
   前記デジタルストリームは、ビデオストリームと、レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームとを含み、
   前記レフトビューグラフィクスストリーム及び前記ライトビューグラフィクスストリームは、何れも１つ以上のディスプレイセットを含み、
   前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に用いられるデータ群であり、
   前記レフトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットは、前記ライトビューグラフィクスストリームに含まれる１つ以上のディスプレイセットと１対１で対応しており、対応するディスプレイセットには、前記ビデオストリームの再生時間軸上において同一の再生時間が設定されており、
   前記各ディスプレイセットは、一画面分のグラフィクスオブジェクトの表示に必要な全てのデータを含んでいるか、直前のディスプレイセットからの差分であるのかを示す状態情報を含み、
   前記レフトビューグラフィクスストリームと前記ライトビューグラフィクスストリームとで対応するディスプレイセットに含まれる状態情報が、同一の内容を示しており、
   前記デジタルストリームを放送またはネットワークを経由して前記再生装置に配信する配信手段を備える
   ことを特徴とする配信装置。

Images