JPWO2009157159A1 - 記録媒体、再生装置、集積回路、再生方法、プログラム - Google Patents

Abstract

多層化されたBD-ROMには、複数のコンテンツと、BD-Jオブジェクトとが記録されている。前記複数のコンテンツには、平面視映像を構成するものと、立体視映像を構成するものとがあり、BD-Jオブジェクトは、アプリケーション管理テーブルと、GUI管理テーブルとを含む。アプリケーション管理テーブルは、複数のコンテンツのうち、特定のものが再生対象になった際、起動すべきアプリケーションを再生装置に指示する情報である。GUI管理テーブルのコンフィグレーション情報におけるフラグは、グラフィクスの立体視を実現するために、複数のプレーンメモリを確保する必要があるか否かを示す。

Description

本発明は、立体視再生の技術分野に属する発明である。

立体視再生とは、ライトビュー用とレフトビュー用の２つの視点の映像を準備することにより、立体視を実現する技術である。技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。継時分離方式とは、レフトビュー用映像及びライトビュー用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。この方式では、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。これらの左右の映像を、別々のメモリに格納して合成に供する必要があるので、一フレーム分の画素データを格納するためのメモリ(プレーンメモリ)は、2つ必要になる。

尚、平面表示と立体表示を動的に切り換える手法としては、特開２００４-１０９３３０号公報に記載されている切り替え方法がある。特開２００４-１０９３３０号公報に記載されている再生装置は、キー入力手段と、平面表示（２D）と立体表示（３D）の表示切り換え手段を備え、前記キー入力手段によるキー入力に応じて、前記表示切り換え手段による平面表示と立体表示を切り換える。

特開２００４−１０９３３０号公報

ところで立体視コンテンツの再生時に、アプリケーションを起動して、アプリケーションにGUIを描画させることで、立体視コンテンツの再生時におけるユーザ操作を容易に行わせたいという要望がある。これは、既存のBD-ROMコンテンツにおいて、コンテンツと、アプリケーションとを連動させて、アプリケーションにGUI処理を行わせるという高度な処理が実現されており、これを立体視コンテンツでも実現したいというコンテンツ制作者側からの要望による。しかしGUIを描画するためのプレーンメモリであるグラフィクスプレーンは、動画像の立体視を実現するためのプレーンメモリ(ビデオプレーン)とは別に確保にする必要があるので、再生装置では、平面視コンテンツの再生と比較して、倍のビデオプレーン、倍のグラフィクスプレーンの確保が必要になる。そして、GUIにHDTV向けの画質を解像度に求めようとすると、そのために必要となるメモリ規模も倍になり、これとビデオストリームの格納のためのビデオプレーンと併せて、再生装置に実装されるメモリデバイスのほとんどの領域が、プレーンメモリに占有されることになる。具体的には、HDTV向けの画質は1920×1080という解像度が必要であり、一画素当たりのインデックスのビット長を32ビットとすると、グラフィクスプレーンの総容量は8Mバイト(≒1920×1080×32)になる。立体視を行うにあたって、このグラフィクスプレーンを、ライトビュー用、レフトビュー用のそれぞれに割り当てたとすると、16Mバイトものメモリが費やされることになり、リソースを圧迫する。

一方、動作に必要なリソースが欠乏すると、アプリケーションの動作が不安定になり、ブラックアウトやハングアップの多発を招く恐れがある。特に、複数のコンテンツのうち、一部のものが立体視コンテンツであり、残りは平面視コンテンツであるような場合、立体視のためのプレーンメモリの追加が必要になるのは、一部のコンテンツの再生時に限られる。にもかかわらず、一旦立体視コンテンツが再生されれば、そのグラフィクスプレーンが確保されたままになって、上述したような動作の不安定化をむやみに引き起こすというのは、不合理である。

上述した先行技術文献に記載されている立体視の切り替えは、ユーザが積極的な意思をもって立体視を実現するか、平面視を実現するかを切り替えるものであり、かかる技術を適用したとしても、ユーザが積極的な意思をもって立体視再生を平面視再生に切り替えない限り、立体視のためのプレーンメモリは確保されたままになるので、かかる文献記載発明は、上述したような技術的課題の解決をもたらすものではない。

本発明の目的は、一部のものが立体視コンテンツであり、残りは平面視コンテンツであるような複数のコンテンツを再生する場合に、リソースの欠乏を避けることができる記録媒体を提供することである。

上記課題を解決するため、本発明にかかる再生装置は、映像データと、管理オブジェクトと、アプリケーションを含む複数のコンテンツが記録されている記録媒体であって、前記コンテンツに含まれる映像データには、平面視映像を構成するものと、立体視映像を構成するものとがあり、前記複数のコンテンツのそれぞれに含まれる管理オブジェクトは、アプリケーション管理テーブルと、コンフィグレーション情報とを含み、前記アプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションを再生装置に指示する情報を含み、前記コンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報およびフラグを含み、前記フラグは、グラフィクスの立体視を実現するために、複数のグラフィクスプレーンを前記メモリデバイス上に確保する必要があるか否かを示すことを特徴としている。

上述したようなコンフィグレーション情報におけるフラグは、グラフィクスの立体視を実現するために、複数のグラフィクスプレーンを確保する必要があるか否かを示すので、グラフィクスプレーンの追加が必要ではないコンテンツの再生時にあたっては、確保すべきグラフィクスプレーンの規模が一つに戻ることになる。立体視コンテンツのために、グラフィクスプレーンを追加したとしても、その追加のグラフィクスプレーンが確保されたままになって、メモリにおける空き容量が圧迫を受けることはない。そのため、アプリケーションの動作を安定させることができる。多くのコンテンツのうち、唯一つだけが立体視再生を実現し、その他は平面視再生しか実現しえないようなBD-ROMを再生対象にする場合、立体視コンテンツの再生後に、即座に、立体視のための複数のグラフィクスプレーンを解放することができる。

先行文献における特許文献１に記載された技術では、立体視の要否をユーザが切り替えるため、プレーンメモリを確保したり強制的に解放するような制御を実現することはできないが、本発明では、オーサリング側が意図するような確保を実現することができるので、アプリケーションの安定動作を実現することができる。

記録媒体、再生装置の、使用行為についての形態を示す図である。 BD-ROMの内部構成を示す。 BD-ROMのアプリケーションフォーマットを示す図である。 レフトビューストリーム、ライトビューストリームを構成する各ソースパケットがどのような過程を経てAVデータ領域に書き込まれるかを示す。 BD-ROMの物理単位と、1つのファイルエクステントを構成するソースパケットとの対応関係を示す図である。 TSパケットのパケットIDがとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。 インターリーブ配置の一例を示す図である。 立体視のためのベースビューストリーム、エンハンスドビューストリームの内部構成の一例を示す図である。 ゴーグルの透光／遮光を、図８のタイミングに従って切り替えることにより、どのような映像が再生に供されるかを示す図である。 目の残像反応により形成される立体映像を示す図である。 クリップ情報ファイルの一例を示す図である。 エントリーマップテーブルの内部構成を示す図である。 エントリーマップによるエントリーポイントの登録を示す。 レフトビュー、ライトビューのそれぞれに対応するエントリーマップが、どのように設定されているかを示す図である。 プレイリスト情報のデータ構造を示す図である。 サブパス情報テーブルの内部構成を示す図である。 レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。 プレイリスト情報におけるエクステンションデータの内部構成を示す図である。 ビデオストリーム番号テーブルの内部構成を示す図である。 JARアーカイブファイルの内部構成を示す図である。 BD-Jオブジェクトの内部構成を示す図である。 GUI管理テーブルの内部構成を示す図である。 ビデオプレーンの解像度と、グラフィクスプレーンとの対応関係を示す。 GUI管理テーブルの設定と、メモリの内容とを示す。 解像度コード＝"２"、"３"で確保されるグラフィクスプレーンを示す。 グラフィクスプレーンの確保、解放の時間的遷移を示す。 BD-Jアプリケーションによるグラフィクスの書き込みを示す。 ベースビューストリーム、エンハンスドビューストリームの再生と、BD-JアプリケーションによるGUI処理とが、連動する場合に再生される立体視映像の一例を示す。 再生装置の内部構成を示す図である。 フロントエンド部１０５〜バックエンド部１０８内の構成要素を示す図である。 再生装置におけるソフトウェアレイヤモデルを示す図である。 左側に、Index.bdmv、BD-Jオブジェクトを描き、右側に、ソフトウェアのレイヤモデルを描いた図である。 ソフトウェアレイヤモデル上に存在するBD-Jアプリケーションと、ビデオプレーン、グラフィクスプレーンとを1つにまとめて描いた図である。 モジュールマネージャ４２による処理手順を示すフローチャートである。 プレイリスト情報の再生手順を示すフローチャートである。 プレーンコントローラの処理手順を示すフローチャートである。 BD-JアプリケーションによるGUI処理の処理手順を示すフローチャートである。 フレーム精度アニメーション実行部８０を示す図である。

(第１実施形態)
図面を参照しながら、上記課題解決手段を具備した記録媒体、再生装置の実施形態について説明する。

図１は、記録媒体、再生装置の、使用行為についての形態を示す図である。本図に示すように、記録媒体の一例である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を含む。

ベースビューストリーム及びエンハンスドビューストリームを構成するソースパケットは、第3段目において、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段目に示すように、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のソースパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のソースパケットを"Aligned Unit"といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。

第３段目においてセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unitの単位でBD-ROMをアクセスする限り、32個の完結したソースパケットを得ることができる。以上がBD-ROMに対するAVクリップの書き込みのプロセスである。

図６は、TSパケットのパケットIDがとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。

0x0100のパケットIDをを有するTSパケットはプログラムマップ（Program＿map）を構成し、0x1001のパケットIDをを有するTSパケットはプログラムクロックレファレンス(PCR)を構成する。

0x1011のパケットIDを有するTSパケットはベースビューストリーム、Ox1012のTSパケットはエンハンスドビューストリームを構成する。

0x1100-11FのパケットIDを有するTSパケットはオーディオストリームを構成する。

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

第１段目は、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ピクチャを参照している。

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

図１０は、目の残像反応により形成される立体映像を示す図である。

以上で、ベースビューストリーム、エンハンスドビューストリームの内部構成についての説明を終える。続いて、クリップ情報ファイルについて説明する。

＜クリップ情報ファイル＞
図１１は、クリップ情報ファイルの一例を示す図である。クリップ情報ファイルは、本図に示すように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シーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、STCシーケンスを構成するソースパケット列を示す。

矢印te1,te2,te3,te4は、STC時間軸における再生時点t1,t11,t21,t31と、エントリーポイントとの対応関係を模式的に示しており、矢印sh1,sh2,sh3,sh4は、ATCsequeceにおける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を用いて一意にアクセスされることになる。

以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。

図１５は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、メインパス情報、サブパス情報テーブル、エクステンションデータを含む。

先ずメインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。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』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem＿random＿access＿flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still＿mode』と、『STN＿table』と、『BaseView＿indicator』と、『STN＿table』と、『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つ以上のSubPlayItem情報(・・・SubPlayItem情報＃１〜＃ｍ・・・)とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、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ピクチャは、時間軸において同じ時点になる。

レフトビューと、ライトビューとは、プレイアイテム情報、SubPlayItem情報とによって、対応付けられることになる。

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

図１９は、ビデオストリーム番号テーブルの内部構成を示す図である。

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

「Stream＿entry」は、プライマリビデオストリームを構成するPESパケットのPIDに対する参照値を示す『ref＿to＿stream＿PID＿of＿main＿Clip』『video＿format』『frame＿rate』を含む。

これらのテーブルにおけるstream＿entryの順位は、再生装置がストリームを選択するにあたって、ストリーム選択の優先順位を意味する。つまり、テーブルにおけるにおいてエントリーが高い順位にあるものを再生装置は、優先的に選択することになる。

enhanced＿view＿is＿availableフラグがオンであり、エンハンスドビューに設定されている場合、ref＿to＿stream＿of＿MainCLipには、0x1011のパケットIDと、0x1012のパケットIDとが記述される。

本願明細書におけるコンテンツとは、あるタイトル番号にて管理されるプレイリスト情報と、このプレイリスト情報から参照されるAVクリップに多重化されているビデオストリームおよび後述するBD-Jオブジェクトと、BD-Jオブジェクトによって示される起動が許されたアプリケーションとを包含する単位であり、"タイトル"と呼ばれる。

以上がプレイリスト情報についての説明である。

＜JARディレクトリ＞
続いて、JARディレクトリについて説明する。JARディレクトリは、JARアーカイブファイル(XXXXX.JAR)を格納している。

JARアーカイブファイルは、http：//java(TM).sun.com/j2se/1.4.2/docs/guide/jar/jar.htmlに記載された仕様に準じたファイルである。JARアーカイブファイルは複数のファイルをディレクトリ構造の形で格納している。図２０は、JARアーカイブファイルの内部構成を示す図である。

この内部構成は、ルートディレクトリ直下に「XXXXX.class」「XXXXX.PNG」が存在し、META-INFディレクトリにファイル「MANIFEST.MF」、ファイル「SIG-BD.SF」、ファイル「SIG-BD.RSA」、ファイル「bd.XXXXX.perm」が存在するというものである。

このXXXXX.class(クラスファイル)は、Java言語等のオブジェクト指向言語で記述されたクラス構造体をコンパイルすることで得られたバイトコードを格納している。かかるクラスファイルは、BD-Jアプリケーションを定義するものであり、Java(TM)仮想マシン上で実行可能となる。MANIFEST.MFは、デジタル証明書に対応するものであり、SIG-BD.SFは、MANIFEST.MFのハッシュ値が記載されているファイルである。SIG-BD.RSAは、デジタル証明書チェーン、署名情報が記載されているファイルである。bd.XXXXX.permは、パーミッションリクエストファイルであり、実行されるBD-Jアプリケーションにどのようなファイルへのアクセスを許可するのかを示すパーミッションに関する情報を格納する。

JARアーカイブファイルにおけるクラスファイルにて定義されるBD-Jアプリケーションは、Xletインターフェイスを通じて、アプリケーションマネージャにより、制御されるJava(TM) Xletである。Xletインターフェイスは、"loaded","paused"、"active","destoryed"といった4つの状態をもつ。

またJava(TM)アプリケーションは、JFIF(JPEG)やPNG,その他のグラフィクスデータを表示するためのスタンダードJavaライブラリを用いて、GEM1.0.2にて規定されたHAViフレームワークを実現する。HAViフレームワークは、GEM1.0.2におけるリモートコントロールナビゲーション機構を含むGUIフレームワークであり、Java(TM)アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。

図中のPNGファイルは、例えばBD-JアプリケーションがGUIに用いるアニメーションデータを格納している。

以上がJARファイルについて説明である。

続いて、BD-Jオブジェクトについて説明する。図２１は、BD-Jオブジェクトの内部構成を示す図である。本図に示すように、BD-Jオブジェクトは、「アプリケーション管理テーブル」、「GUI管理テーブル」、「プレイリスト管理テーブル」から構成される。

以下、これらの構成要素について説明する。

「アプリケーション管理テーブル」は、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。引き出し線bj1は、アプリケーション管理テーブルの内部構成をクローズアップして示している。この引き出し線に示すように、アプリケーション管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定する『アプリケーション識別子』と、『制御コード』とを含む。制御コードは、AutoRunに設定された場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、他のアプリケーションからのコールを待って、起動すべき旨を示す。

「GUI管理テーブル」は、動作中のアプリケーションがGUIを行う際の管理テーブルであり、GUI表示を実行するにあたってのコンフィグレーション情報や、GUIに用いるフォントデータ、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。このコンフィグレーション情報は、BD-Jオブジェクト内のアプリケーション管理テーブルによって起動されるべきアプリケーションがグラフィクスを描画するにあたって、再生されるビデオストリームの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報である。

引き出し線bj2は、プレイリスト管理テーブルの内部構成をクローズアップして示している。プレイリスト管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、自動的に再生されるべきプレイリストの指定を含む。また、プレイリスト管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させることができるアプリケーションが選択できるプレイリストの指定を含む。

続いて、GUI管理テーブルの内部構成について詳細に説明する。

図２２（ａ）は、GUI管理テーブルの内部構成を示す図である。引き出し線gh1は、GUI管理テーブルの構成をクローズアップしている。引出線gh1に示すように、GUI管理テーブルは「基本プレーンコンフィグレーション」、「表示方式フラグ」、「拡張プレーンコンフィグレーション」から構成される。「基本プレーンコンフィグレーション」は、ベースビューストリームに合成すべきグラフィクス(ベースビューグラフィクス)のために確保すべき、グラフィクスプレーンのコンフィグレーションを示す。「拡張プレーンコンフィグレーション」は、エンハンスドビューストリームに合成すべきグラフィクス(エンハンスドビューグラフィクス)のために確保すべき、グラフィクスプレーンのコンフィグレーションを示す。これら基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションを併せて、本願では、"コンフィグレーション情報"とよぶ。引き出し線gh2,gh3は、基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションの設定内容を示す。この引出線に示すように、基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションには何も、解像度コードが設定される。

図２２（ｂ）は、表示方式フラグのビットアサインを示す図である。"０"である場合、GUIの平面視を行うから、確保すべきグラフィクス用のプレーンメモリ(グラフィクスプレーン、又は、イメージプレーンと呼ばれる。)は単一である旨を示す。"１"である場合、GUIの立体視を実行するから、確保すべきグラフィクスプレーンは複数である旨を示す。

図２２（ｃ）は、解像度コードの意味内容を示す。解像度コードが"1"に設定された場合、確保すべきグラフィクスプレーンの規模は、720×480画素であることを示す。解像度コードが"２"に設定された場合、確保すべきグラフィクスプレーンの規模は、960×540画素であることを示す。解像度コードが"３"に設定された場合、確保すべきグラフィクスプレーンの規模は、1920×1080画素であることを示す。解像度コードが"４"に設定された場合、確保すべきグラフィクスプレーンの規模は、1280×720画素であることを示す。

図２３は、ビデオプレーンの解像度と、グラフィクスプレーンとの対応関係を示す。左側はビデオプレーンの解像度を示し、右側は、グラフィクスプレーンの解像度を示す。真ん中の矢印は、許容されるビデオプレーンの解像度と、グラフィクスプレーンの解像度との組合せを示す。ビデオプレーンの解像度コードが720×480画素であれば、矢印kw1に示すように、グラフィクスプレーンの解像度コードとして、720×480画素の解像度コードの設定が許容される。

ビデオプレーンの解像度が、1920×1080画素であれば、矢印kw2,kw3に示すように、グラフィクスプレーンの解像度コードとして、960×540画素の解像度コード、又は、1920×1080画素の解像度コードの設定が許容される。

ビデオプレーンの解像度コードが、1280×720画素を意味するものであれば、矢印kw4に示すように、グラフィクスプレーンの解像度コードとして、1280×720画素の解像度コードの設定が許容される。

図２４（ａ）は、GUI管理テーブルの設定と、メモリの内容とを示す。

GUI管理テーブルにおいて、表示方式フラグが"０"に設定されている場合、基本プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリが、メモリに確保される。ここで、基本プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthB,縦画素数＝HeightBである場合、WidthB×HeightBという規模のプレーンメモリがメモリに確保されることになる。一方、表示方式フラグ"=0"であれば、拡張グラフィクスプレーンは確保されない。

図２４（ｂ）は、GUI管理テーブルの設定と、メモリの内容とを示す。GUI管理テーブルにおいて、表示方式フラグが"１"に設定されている場合、基本プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリと、拡張プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリとが、メモリに確保される。ここで、基本プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthB,縦画素数＝HeightBである場合、WidthB×HeightBという規模のプレーンメモリがメモリに確保されることになる。一方、表示方式フラグ"1"であるので、拡張グラフィクスプレーンが確保される。ここで、拡張プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthE,縦画素数＝HeightEである場合、WidthE×HeightEのプレーンメモリがメモリに確保されることになる。

図２５（ａ）は、解像度コードが"２"で確保されるグラフィクスプレーンを示す。解像度コードが"２"で確保されるグラフィクスプレーンとは、960×縦540の32ビット領域からなる。つまり解像度コードが"２"で復号されるグラフィクスプレーンとは、960×540の解像度で、1画素当たり32ビットのRGB値を格納できるメモリアロケーションである。32ビットのRGB値は、８ビットの赤画素の輝度(Ｒ値)、８ビットの緑画素の輝度(Ｇ値)、８ビットの青画素の輝度(Ｂ値)、透明度であるα値を含む。

図２５（ｂ）は、解像度コードが"３"で確保されるグラフィクスプレーンを示す。解像度コードが＝"３"で確保されるグラフィクスプレーンとは、横1920×縦1080の32 ビット領域からなる。これは1920×1080の解像度で、1画素当たり32 ビットのＲＧＢ値を格納できるメモリアロケーションをもつ領域ことをいう。

アプリケーションがGUI管理テーブルにおけるコンフィグレーション情報にて規定された解像度コードの座標系を基準にして、グラフィクスの書き込み位置を定める。具体的には、1920×1080 720×480といった解像度コードの画素のうち、左上画素を原点とした座標系にて、グラフィクスの書き込み座標は規定される。

図２６は、グラフィクスプレーンの確保、解放の時間的遷移を示す。第1段目は、映像内容を示し、第2段目は、時間軸を示す。第3段目は、BD-Jオブジェクトの内部構成を示し、第4段目は、メモリデバイスの内容を示す。 第2段目に示すように、タイトル#1、#3が平面視コンテンツであり、タイトル#2が立体視コンテンツであり、タイトル#1、#3に対応するBD-Jオブジェクト内のGUI管理テーブルが表示方式フラグが"0"に設定されているものとする。またタイトル#2に対応するBD-JオブジェクトのGUI管理テーブルが表示方式フラグが"1"に設定されているものとする。

以上の条件下におけるメモリデバイスのグラフィクスプレーン確保の時間的遷移は、第4段目に示す通りになる。第4段目では、カレントタイトルがタイトル#1になったタイミングにおいて、メモリデバイスにおけるグラフィクスプレーンがクリアされて、その後、基本グラフィクスプレーンがメモリデバイスに確保される。カレントタイトルがタイトル#2になると、メモリデバイスにおけるグラフィクスプレーンがクリアされて、その後、基本グラフィクスプレーン、及び、拡張グラフィクスプレーンがメモリデバイスに確保される。

カレントタイトルがタイトル#3になると、基本グラフィクスプレーン、拡張グラフィクスプレーンがクリアされて、基本グラフィクスプレーンのみが確保される。

カレントタイトルがタイトル#2になった期間だけ拡張グラフィクスプレーンがメモリデバイスに確保され、カレントタイトルがタイトル#3になれば、拡張グラフィクスプレーンは解放されるので、メモリデバイスにおける容量が、グラフィクスプレーンによって長く占有されることはない。

以上が、GUI管理テーブルの説明である。続いて、BD-JアプリケーションによるGUI処理の詳細について説明する。

＜アニメーションの実現＞
GUI処理において、BD-Jアプリケーションによって描画されるグラフィクスの代表的なものは、メニュー、アニメーションである。メニューには、複数のボタン部材が存在し、個々のボタン部材は、ノーマル状態、フォーカス状態、アクティブ状態といった状態をもつ。リモコンにおける左右キーを押下することにより、フォーカス状態になるべきボタンを切り換えることができ、またBD-Jアプリケーションは、リモコンにおけるEnterキーの押下に応じて、現在フォーカス状態にあるボタンに対応する処理を実行する。

アニメーションは、グラフィクスに既に書き込まれたグラフィクスを、ある時間間隔において、順次上書きしてゆくことでなされる。以下、アニメーションを実現するためのグラフィクス書き込みについて説明する。

グラフィクスプレーンにおいて、アニメーションを構成するグラフィクスは、グラフィクス管理のための数値にて管理されており、この数値に対応するグラフィクスデータの画像は、画面上に一定時間だけ表されることになる。一方、その一定時間のあいだ、アプリケーションの側では、新たなグラフィクスの生成がなされている。一定時間が経過すれば、グラフィクスプレーンの格納内容は、新たに生成されたグラフィクスデータを用いて上書きされることになる。かかる上書きにおいて、グラフィクス管理のための数値は更新される。こういった動作、つまり、"アプリケーションによるグラフィクスの生成"、"生成されたグラフィクスの更新"、"グラフィクスの上書き"、"グラフィクス管理のための数値の更新"という一連の動作の繰り返しにより、グラフィクスのアニメーション表示は実現されることになる。

また単位時間（例えば一秒間など）における上述の一連の動作の繰り返しの回数（以後アプリケーションの実行速度と称す）を変えることにより、グラフィクスプレーンの格納内容が単位時間あたりに更新されるタイミングの数を増減させることが可能となる。これにより結果として、入力に対するアプリケーションによるグラフィクス描画によるGUI表示の応答性を高くしたり、低くしたりすることが可能となる。

このような処理に加え、立体視時には、グラフィクスを立体視を実現するため、当該座標系におけるグラフィクスの書き込み位置をずらす。こうすることで、グラフィクスの立体視を実現する。

図２７は、BD-Jアプリケーションによるグラフィクスの書き込みを示す。表示方式フラグが"１"である場合、拡張グラフィクスプレーンが追加される。BD-Jアプリケーションは、これらの基本グラフィクスプレーン、拡張グラフィクスプレーンのそれぞれにグラフィクスを書き込む。

このように、１つのグラフィクスデータを左右にずらして基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込むことにより、グラフィクスが、映像より前に浮き出て見える。

図２８は、ベースビューストリーム、エンハンスドビューストリームの再生と、BD-JアプリケーションによるGUI処理とが、連動する場合に再生される立体視映像の一例を示す。基本グラフィクスプレーン、拡張グラフィクスプレーンのそれぞれに、グラフィクスを書き込むので、立体視映像には、メニューやアニメーションが立体的に現れることになる。

以上でBD-Jオブジェクト及びGUI管理テーブルについての説明を終える。

図２９は、再生装置の内部構成を示す図である。本図において再生装置を構成する主だった部品は、フロントエンド部１０５、システムLSI１０６、メモリデバイス１０７、バックエンド部１０８である。

フロントエンド部１０５は、データ入力源である。

後述する図３０において、フロントエンド部１０５は例えば、BD-ROMドライブ１０９、ローカルストレージ１１０を含む。

システムLSI１０６は、論理素子から構成され、再生装置中核をなす。

後述する図３０において、システムＬＳＩ１０６は例えば、MPU２１、プレーンコントローラ１７、デマルチプレクサ６、ビデオデコーダ７ａ、ビデオデコーダ７ｂ、オーディオデコーダ９、色変換部１８ａ、色変換部１８ｂ、合成器１９ａ、合成器１９ｂを含む。システムＬＳＩは一チップで構成しても良いし、複数のチップで構成しても良い。

メモリデバイス１０７は、SDRAM等のメモリ素子のアレイによって構成される。

後述する図３０において、メモリデバイス１０７は例えば、リードバッファ１、リードバッファ２、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３、バイトコードインタプリタ、コマンドインタプリタ、組込みＲＯＭ２２、再生制御エンジン１４、ＰＳＲセット１２、基本グラフィクスプレーン１５、拡張グラフィクスプレーン１６、基本ビデオプレーン８ａ、拡張ビデオプレーン８ｂを含む。

例えば、メモリデバイス１０７にバンクメモリ方式を採用する場合、メモリデバイス上の領域は、統一したメモリ空間として認識されるので、BD-Jアプリケーションの動作時においては、かかるメモリデバイスの領域を、リソースとしてBD-Jアプリケーションによる利用に供する。そしてCPUにおけるメモリ空間の一部に、複数のプレーンメモリがマッピングされることになる。

バックエンド部１０８は、再生装置内部と、他の装置との接続インターフェイスである。

後述する図３０において、バックエンド部１０８は例えば、HDMI送受信部１０を含む。

上述したように、フロントエンド部１０５は例えば、BD-ROMドライブ１０９、ローカルストレージ１１０を含む。

BD-ROMドライブ１０９は、BD-ROMのローディング/イジェクトを行い、システムLSI１０６からの指示に応じて、ベースビューストリームを構成するエクステント、エンハンスドビューストリームを構成するエクステントをBD-ROMから読み出す。

BD-ROMドライブ109は例えば、半導体レーザ（図示せず）、コリメートレンズ（図示せず）、ビームスプリッタ（図示せず）、対物レンズ（図示せず）、集光レンズ（図示せず）、光検出器（図示せず）を有する光学ヘッド（図示せず）を備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。集光された光ビームは、光ディスク上で反射／回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、生成された信号がBD-ROMから読み出されたデータに対応する。

ローカルストレージ１１０は、ビルドインメディア、リムーバブルメディアを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。また、ダウンロードした追加コンテンツをどのようにBD-ROM上のデータとマージされるか、マージ規則が記載されたマージ管理情報もこのビルドインメディア、リムーバブルメディアに保存される。

ビルドインメディアとは例えば再生装置に内蔵されたハードディスクドライブ、メモリなどの書き込み可能な記録媒体である。

リムーバブルメディアとは、例えば可搬性を有する記録媒体であり、好適にはＳＤカードなどの可搬性を有する半導体メモリーカードである。

リムーバブルメディアを半導体メモリーカードとしたときを例に説明をすると、再生装置にはリムーバブルメディアを装着するためのスロット（図示せず）およびスロットに装着されたリムーバブルメディアを読み取るためのインターフェース（例えばメモリーカードＩ／Ｆ）が備えられており、スロットに半導体メモリを装着すると、リムーバブルメディアと再生装置とが電気的に接続され、インターフェース（例えばメモリーカードＩ／Ｆ）を利用して、半導体メモリに記録されたデータを電気信号に変換して読み出すことが可能となる。
＜再生装置における詳細構成＞
これらフロントエンド部１０５〜バックエンド部１０８内の構成要素を更に詳細に説明する。図３０は、フロントエンド部１０５〜バックエンド部１０８内の構成要素を示す図である。本図に示すように、フロントエンド部１０５〜バックエンド部１０８内には、リードバッファ１,２、デマルチプレクサ６、ビデオデコーダ７a,b、基本ビデオプレーン８a,b、オーディオデコーダ９、HDMIインターフェイス１０、再生状態／設定レジスタセット１２、静的シナリオメモリ１３、再生制御エンジン１４、基本グラフィクスプレーン１５、拡張グラフィクスプレーン１６、プレーンコントローラ１７、色変換部１８a,b、合成器１９a,b、MPU２１、ROM２２、動的シナリオメモリ３０、ヒープメモリ３１といった構成要素が存在する。

リードバッファ１は、BD-ROMドライブ１か読み出されたベースビューストリームを構成するエクステントを構成するソースパケットを一旦格納しておき、転送速度を調整した上、デマルチプレクサ６に転送するためのバッファであり、上述したような"RB1"という規模をもつ。

リードバッファ２は、BD-ROMドライブ１か読み出されたエンハンスドビューストリームを構成するエクステントを構成するソースパケットを一旦格納しておき、転送速度を調整した上、デマルチプレクサ６に転送するためのバッファであり、上述したような"RB2"という規模をもつ。

デマルチプレクサ６は、ソースパケットデパケッタイザー、PIDフイルタから構成され、ベースビューストリームを構成するエクステント、エンハンスドビューストリームを構成するエクステントが、リードバッファ１、２を介して転送されれば、ベースビュービデオストリームを構成するTSパケット、エンハンスドビュービデオストリームを構成するTSパケットを当該エクステントから分離して、ビデオデコーダ７a、ビデオデコーダ７ｂに転送する。

ビデオデコーダ７aは、デマルチプレクサ６から出力されたベースビューストリームを構成するTSパケットを復号して非圧縮形式のピクチャを基本ビデオプレーン８aに書き込む。

ビデオデコーダ７ｂは、デマルチプレクサ６から出力されたエンハンスドビューストリームを復号してTSパケットを復号して非圧縮形式のピクチャを拡張ビデオプレーン８ｂに書き込む。

基本ビデオプレーン８aは、ベースビューストリームを構成する非圧縮形式のピクチャを格納しておくためのメモリである。

拡張ビデオプレーン８bは、エンハンスドビューストリームを構成する非圧縮形式のピクチャを格納しておくためのメモリである。

オーディオデコーダ９は、デマルチプレクサ６から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。

HDMI送受信部１０は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）に準拠したインターフェイスを含み、再生装置とHDMI接続する装置（この例ではテレビ１０３）とHDMI規格に準拠するように送受信を行うものであり、基本ビデオプレーン８a、拡張ビデオプレーン８bに格納されたピクチャデータと、オーディオデコーダ１３によってデコードされた非圧縮のオーディオデータとを、HDMIインターフェイス１０を介してテレビ１０３に伝送する。テレビ１０３は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からＨＤＭＩインターフェイスを介して要求があると、テレビ１０３は要求された必要な情報（例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報）を再生装置へ返す。このように、HDMI送受信部１０を介することで、テレビ１０３が立体視表示に対応しているかどうかの情報を、テレビ１０３から取得することができる。

再生状態／設定レジスタ(Player Status/Setting Register)セット１２は、プレイリストの再生状態や、コンテンツが利用する任意の情報を格納できる領域である。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置（時刻）を再生しているか、などの状態を現すものである。プレイリストの再生状態が変化した際は、再生制御エンジン１４がPSRセット１２に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJavaプラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。以降、PSRのうち、代表的なものについて説明する。

PSR4は、1〜100の値に設定されることで、カレントのタイトル番号を示す。

PSR5は、1〜999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。

PSR6は、0〜999の値に設定されることで、カレントプレイリストの番号を示す。

PSR7は、0〜255の値に設定されることで、カレントプレイアイテムの番号を示す。

PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM)を示す。以上がPSRについての説明である。

静的シナリオメモリ１３は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。

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

基本グラフィクスプレーン１５は、BD-Jオブジェクトにおける基本プレーンコンフィグレーション情報に応じて確保されるプレーンメモリである。

拡張グラフィクスプレーン１６は、表示方式フラグが"１"、つまり立体表示する（オンにする）に設定された場合、BD-Jオブジェクトにおける拡張プレーンコンフィグレーション情報に応じて確保されるプレーンメモリである。

プレーンコントローラ１７は、表示プレーン切換指示に従って、基本グラフィクスプレーン内のグラフィクスデータと、基本ビデオプレーン内のピクチャデータとを合成した画像を出力して、平面表示を行わせるか、あるいは、基本グラフィクスプレーン内のグラフィクスデータと、基本ビデオプレーン内のピクチャデータとを合成した画像とをレフトビュー動画像として出力し、拡張グラフィクスプレーン内のグラフィクスデータと、拡張ビデオプレーン内のピクチャデータとをライトビュー動画像として出力することで、立体表示を行わせるかを制御する。立体表示を行なわせる場合、基本グラフィクスプレーンと基本ビデオプレーンとを合成した画像、及び、拡張グラフィクスプレーンと拡張ビデオプレーンを合成した画像をそれぞれ短い時間間隔の間に切り替えて表示する。

色変換部１８aは、カラールックアップテーブルを用いて、基本グラフィクスプレーン１５に格納されている画素コードを、Y,Cr,Cbといった画素値に変換する。

色変換部１８bは、カラールックアップテーブルを用いて、拡張グラフィクスプレーン１６に格納されている画素コードを、Y,Cr,Cbといった画素値に変換する。

合成器１９aは、基本ビデオプレーン８aに格納された非圧縮形式のピクチャデータの各画素と、基本グラフィクスプレーン１５に展開されたグラフィクスの各画素とを合成する。

合成器１９bは、拡張ビデオプレーン８ｂに格納された非圧縮形式のピクチャデータの各画素と、拡張グラフィクスプレーン１６に展開されたグラフィクスの各画素とを合成する。

MPU２１は、再生装置におけるコンピュータアーキテクチャの中核をなし、ROM２２に格納されているネィティブコードをフェッチして解読し、ネィティブコードに基づき、再生装置の処理を実行する。

ROM２２は、再生装置における組込みプログラムが予め格納されている。

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

ヒープメモリ３１は、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である。

以上が再生装置の内部構成についての説明である。続いて、再生装置のソフトウェアレイヤモデルの詳細について説明する。

図３１は、再生装置におけるソフトウェアレイヤモデルを示す図である。このソフトウェアレイヤモデルでは、HDMVモジュール、BD-Jモジュール、モード管理モジュールという3つの動作主体がMPU２１上に存在する。これらは、動的シナリオメモリ３０に存在するIndex.bdmv、BD-Jオブジェクト、ムービオブジェクトによって制御を行う。

以降、HDMVモジュール、BD-Jモジュール、モード管理モジュールについて説明する。

HDMVモジュールの一例であるコマンドインタプリタ４０は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。HDMVモードの動作主体であるコマンドインタプリタは、シナリオプログラムを構成するナビゲーションコマンドを解読して実行するものである。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

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とをフル実装している。

モード管理モジュールの一例であるモジュールマネージャ４２は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モジュールマネージャ４２によるモード管理とは、動的シナリオをどのコマンドインタプリタ４０、BD-Jモジュールに実行させるかという、モジュールの割り当てである。

以上がコマンドインタプリタ４０、BD-Jモジュール、モジュールマネージャ４２という3についての説明である。続いて、BD-Jプラットフォーム部４１の内部構成について説明する。

BD-Jモジュールは、ミドルウェア３５と、バイトコードインタプリタ３２と、ヒープメモリ３１上に存在するシステムアプリケーションとによって構成される。ヒープメモリ３１上のシステムアプリケーションには、クラスローダ３３、アプリケーションマネージャ３４、ミドルウェア３５に含まれるクラスライブラリの中で、ヒープメモリ３１上に配置されて実行されるものなどがある。以下、これらの構成要素について説明する。

バイトコードインタプリタ３２は、ヒープメモリ３１に格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPU２１に実行させる。

クラスローダ３３は、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、BD-Jアプリケーションのロードを行う。

アプリケーションマネージャ３４は、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。

ミドルウェア３５は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。

メモリデバイスの各領域は、このミドルウェア３５によって、例えばメモリプール管理機能、ヒープエリア管理機能にて管理されている。メモリプール管理機能とは、空きのメモリ領域を管理し、必要に応じて要求されたメモリサイズをアプリケーションに与え、使用が終了すると、メモリに蓄積された状態に戻す。ヒープエリア管理では、メモリの空き領域にメモリプールを設定し、タスクの要求に応じて、必要サイズのメモリを提供する。

以上がBD-Jプラットフォーム部４１についての説明である。続いて、GUI処理を描画するにあたってのBD-Jプラットフォーム部４１の改良について説明する。

あるタイトルがカレントタイトルになった際、BD-Jプラットフォーム４１は、そのカレントタイトルに対応付けられたGUI管理テーブルに記述されているコンフィグレーション情報にもとづいて、プレーンコントローラ１７に対する描画を指示する。

この際、平面表示する場合は、基本グラフィクスプレーンへの描画のみを指示する。立体表示する場合は、基本グラフィクスプレーンに、レフトビュー用のグラフィクス描画、および、拡張グラフィクスプレーンへライトビュー用のグラフィクス描画を指示する。レフトビュー用のグラフィクス描画とは、視点の位置を視聴者のレフトビューの位置でレンダリングした画像であり、ライトビュー用のグラフィクス描画とは、視点の位置を視聴者のライトビューの位置でレンダリングした画像である。

以上がBD-Jプラットフォーム部４１による描画の改良についての説明である。

図３２は、左側に、Index.bdmv、BD-Jオブジェクトを描き、右側に、ソフトウェアのレイヤモデルを描いた図である。矢印は、Index.bdmv、BD-Jオブジェクトの構成要素が、どのように引き渡されるかを示す。丸記号"１"の矢印は、モジュールマネージャ４２によるタイトル番号及び動作モードオブジェクトIDの読み込みを模式的に示している。丸記号"２"の矢印は、アプリケーションマネージャによるアプリケーション管理テーブルの読み込みを模式的に示している。丸記号"３"の矢印は、再生制御エンジン１４によるプレイリスト管理テーブルの読み込みを模式的に示し、丸記号"４"の矢印は、プレーンコントローラ１７によるGUI管理テーブルの読み込みを模式的に示している。

プレーンコントローラ１７は、平面表示する場合は、基本グラフィクスプレーン１５と基本ビデオプレーン８ａの合成出力を合成器１９ａに指示し、立体表示する場合は、基本グラフィクスプレーン１５と基本ビデオプレーン８ａへの合成出力を合成器１９ａに指示するとともに、拡張グラフィクスプレーン１６と拡張ビデオプレーン８ｂの合成出力を合成器１９ｂに指示する。

図３３は、ソフトウェアレイヤモデル上に存在するBD-Jアプリケーションと、ビデオプレーン、グラフィクスプレーンとを1つにまとめて描いた図である。メモリには、アニメーションを構成する複数のグラフィクスが展開されている。矢印は、BD-Jアプリケーションによる書き込みを模式的に示す。つまり、BD-Jアプリケーションは、アニメーションにおける一コマ、一コマにあたるグラフィクスを、ビデオストリームの再生進行に伴い、一枚ずつ基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込んでいることがわかる。

以降、ソフトウェアによるアプリケーションマネージャ３７の実装について説明する。図３４は、モジュールマネージャ４２による処理手順を示すフローチャートである。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、ユーザ操作に応じて、カレントタイトルが新たに選択されたか否かの判定であり、もし選択されれば、ステップＳ７において、メモリデバイスにおけるグラフィクスプレーンを全て解放してステップＳ８に移行する
ステップＳ８は、カレントタイトルに対応するBD-Jオブジェクトに、プレイリスト管理テーブルが存在するか否かの判定である。もし存在しないのであれば、前のタイトルでは、プレイリスト管理テーブルに記載されていたプレイリストの再生を停止させる(ステップＳ９)。

もし存在するのであれば、前のタイトルではプレイリスト管理テーブルに記載されていなかったが、カレントタイトルでは、プレイリスト管理テーブルに記載されており、当該プレイリスト管理テーブルに、AutoPlayプレイリストが存在すれば、AutoPlayプレイリストの再生を開始させる(ステップＳ１０)。

ステップＳ１１では、カレントタイトルに対応するBD-Jオブジェクトに、GUI管理テーブルが存在するか否かの判定を行う。ステップＳ１２は、GUI管理テーブルが存在する場合に実行される判定ステップであり、そのGUI管理テーブルにおけるコンフィグレーション情報をプレーンコントローラ１７に設定して、初期化を実行する(ステップＳ１２)。

ステップＳ１５は、カレントタイトルに対応するBD-Jオブジェクトにアプリケーション管理テーブルが存在するか否かの判定であり、もし存在するなら、前のタイトルを生存区間としていないが、カレントタイトルを生存区間としているJava（登録商標）アプリケーションであって、AutoRun属性を有するものを起動する(ステップＳ１６)。もし存在しないなら、前のタイトルを生存区間としているが、カレントタイトルを生存区間としていないアプリを停止する(ステップＳ１７)。

その後、Java（登録商標）アプリケーションの起動に成功したか否かの判定を行い(ステップＳ１８)、起動に成功すれば(ステップＳ１８でYes)、AutoPlayプレイリストの再生画像をクオータ(1/4)に変換する(ステップＳ１９)という手順を実現するものである。

一方このステップＳ１８がNoであればステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、本フローチャートの起動時にリセットされ、ステップＳ２３において、0か否かの判定がなされる。0でない場合、ステップＳ２４において再起動カウンタはデクリメントされる。以上のステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８〜ステップＳ１９からなるループ処理により、再起動カウンタが0でない限り、AutoRunアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。

ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ２１、ステップＳ２２の処理を実行する。正常終了していればステップＳ２１〜ステップＳ２２を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。

ステップＳ２１は、AutoPlayプレイリストの再生中であるか否かの判定であり、もし再生中なら、AutoPlayプレイリストの再生画像をフルスクリーン化するよう再生制御エンジンに指示する(ステップＳ２２)。その後、ステップＳ２３に移行する。ステップＳ２３への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これにより再起動カウンタの回数が0になるまで、アプリケーションの再起動は繰り返されることになる。

ステップＳ４は、BDドライブ１にBD-ROMが存在しているか否かの判定であり、もしBD-ROMが存在しなければ、全てのアプリケーションに対し、終了指示を発する(ステップＳ６)。

図３５は、プレイリスト情報の再生手順を示すフローチャートである。

ステップＳ３１において、カレント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]からエクステンションデータ[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップＳ３７)、パケットID[j]のTSパケット[j]をStart＿SPN[j]からEnd＿SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップＳ３８)。そしてステップＳ３９において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップＳ４０においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。

図３６は、プレーンコントローラの処理手順を示すフローチャートである。ステップＳ５１において、BD-JオブジェクトのGUI管理テーブルにおける基本プレーンコンフィグレーション情報における縦画素数×横画素数×１画素当たりのバイト数のプレーンメモリをRAM上に確保し、ステップＳ５２、ステップＳ５３に移行する。ステップＳ５２は、HDMIを介して再生装置に接続された相手側機器であるテレビ１０３に立体視の処理能力が存在するかどうかの判定ステップであり、ステップＳ５３は、BD-Jオブジェクトの表示方式フラグが"１" であるか否かの判定ステップである。どちらかの判定がNoであれば、平面視のためのプレーン制御を実行する。何れのステップもYesであれば、立体視による表示が可能と判断し、ステップＳ５４において、BD-JオブジェクトのGUI管理テーブルにおける拡張プレーンコンフィグレーション情報における縦画素数×横画素数×１画素当たりのバイト数のプレーンメモリをRAM上に確保し、ステップＳ５５に移行する。ステップＳ５５は、１／４８秒の表示期間が到来したかどうかの監視であり、もし到来すれば、ステップＳ５５がYesになって、ステップＳ５６〜ステップＳ６０の処理を実行する。具体的には、表示対象になるビデオプレーン、グラフィクスプレーンを決定して(ステップＳ５６)、グラフィクスプレーンに格納されている１ライン分の画素データを読み出して、Y,Cr,CBに変換し(ステップＳ５９)、ビデオプレーンから読み出された1ライン分のY,Cr,CBと画素毎に合成する(ステップＳ６０)という処理を、グラフィクスプレーン、ビデオプレーンにおける全てのラインについて繰り返す(ステップＳ５７、ステップＳ５８)。

なお、本実施の形態において、ステップ５２は、再生装置に接続された相手側機器であるテレビ１０３に立体視の処理能力が存在するかどうかを問い合わせたが、再生装置１０２にユーザインターフェースが存在し、事前に立体視の出力を行うかどうかをユーザに設定させてもよい。

図３７は、BD-JアプリケーションによるGUI処理の処理手順を示すフローチャートである。ステップＳ７１ではコンフィグレーション情報における解像度と、アニメーションデータを構成するグラフィクスの解像度とからグラフィクスのスケーリングファクターを決定し、ステップＳ７２においてベースビューグラフィクスの表示時期が到来するのを待つ。到来すれば、ステップＳ７３において、決定したスケーリングファクターで、ベースビューグラフィクスを表示するための座標((X,Y))を算出し(ステップＳ７３)、基本グラフィクスプレーンの座標(ＸB,ＹB)に、ベースビューグラフィクスを書き込む(ステップＳ７４)。

ステップＳ７５は、表示方式フラグがオンであるか否かの判定であり、表示方式フラグが"0"（つまりオフ）ならステップＳ７２に戻る。

表示方式フラグが"1" （つまりオン）であるなら、ステップＳ７６においてエンハンスドビューグラフィクスの表示時期が到来するのを待つ。到来すれば、ステップＳ７７において、決定したスケーリングファクターで、エンハンスドビューグラフィクスを表示するための座標((X,Y))を算出し(ステップＳ７７)、拡張グラフィクスプレーンの座標(ＸE,ＹE)に、エンハンスドビューグラフィクスを書き込む(ステップＳ７８)。その後、ステップＳ７２に戻る。

以上のように本実施形態によれば、GUI管理テーブルにおけるコンフィグレーション情報の表示方式フラグは、グラフィクスの立体視を実現するために、複数のプレーンメモリ（複数のグラフィクスプレーンおよび複数のビデオプレーン）を確保する必要があるか否かを示すので、プレーンメモリの追加が必要ではないコンテンツの再生時にあたっては、確保すべきグラフィクスプレーン、ビデオプレーンのそれぞれに対応するプレーンメモリの規模が一つに戻る（つまり、基本ビデオプレーン、基本グラフィクスプレーンをそれぞれ確保すればよい）ことになる。平面視のコンテンツを含んだタイトルをカレントタイトルとした再生から立体視のコンテンツを含んだタイトルをカレントタイトルに切り替えて再生したとき、立体視コンテンツのために、プレーンメモリを追加したとしても、その後、立体視のコンテンツを含んだタイトルをカレントタイトルとした再生から再度平面視のコンテンツを含んだタイトルをカレントタイトルに切り替えて再生したとき、その追加のプレーンメモリが確保されたままになって、メモリにおける空き容量が圧迫を受けることはない。そのため、アプリケーションの動作を安定させることができる。多くのコンテンツのうち、唯一つだけが立体視再生を実現し、その他は平面視再生しか実現しえないようなBD-ROMを再生対象にする場合、立体視コンテンツの再生後に、即座に、立体視のための複数のプレーンメモリを解放することができる。

(第２実施形態)
本実施形態は、アニメーションを実現するAPIを、ミドルウェアに設ける改良に関する。かかるAPIは、フレーム精度アニメーション実行部によってBD-Jアプリケーションに提供される。

図３８は、フレーム精度アニメーション実行部８０を示す図である。

フレーム精度アニメーション実行部８０は、カレントタイトルが切り替わった際、BD-Jオブジェクト内のGUI管理テーブルにおけるコンフィグレーション情報を取り込み、このコンフィグレーション情報に示される座標系をアニメーション描画の基準とする。そしてフレーム精度アニメーション実行部は、アニメーションデータを格納したファイルを指定するファイルパスと、アニメーションにおける表示レートとを表示比率とした機能呼び出しがなされれば、アニメーションデータに含まれる個々のグラフィクスを、指定された表示レートで再生して、動画像と合成する。この際、拡張グラフィクスプレーンへの書き込みにあたっては、視差を考慮して、グラフィクスの書き込み位置をずらしつつも、アニメーションデータを基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込む。

APIの呼び出しがなされれば、基本グラフィクスプレーン及び拡張グラフィクスプレーンにおけるそれぞれのグラフィクスの書き込み座標をずらしつつ、グラフィクスの書き込みを行うので、グラフィクスの立体視が可能になる。

本実施形態によれば、書き込み位置の調整をフレーム精度アニメーション実行部に行わせるので、BD-Jアプリケーションの処理負荷を軽減することができる。

(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

（解像度及び表示方式フラグの表現）
BD-JオブジェクトにおけるGUI管理テーブルは、解像度コード及び表示方式フラグを一体の解像度コードとして表現するのが望ましい。例えば、HD画質の1920×1080という規模のプレーンメモリを、立体視再生のために確保しようとする場合は、HD3D_1920×1080という解像度コードをGUI管理テーブルに記載する。HD画質の1280×1080という規模のプレーンメモリを、立体視再生のために確保しようとする場合は、HD3D_1280×1080という解像度コードをGUI管理テーブルに記載する。このような表記で、解像度及び表示方式フラグが記載されている場合、再生装置は、同じ解像度のプレーンメモリを、立体視再生のためにメモリデバイス上に確保するのが望ましい。

(記録装置としての実施)
再生装置１０２は、ビルドインメディアドライブ、リムーバブルメディアを含むローカルストレージを具備していて、これらへの書き込みを想定した構成になっているので、本願明細書に記載された再生装置は、記録装置としての機能を兼備しているといえる。再生装置１０２が記録装置として機能する場合、以下の2つの態様によって、管理オブジェクトの書き込みを実行する。

i)再生装置１０２が仮想パッケージを再生する機能をもつ場合、管理オブジェクトであるBD-Jオブジェクトの書き込みを以下のように行う。つまり、BD-ROMが装填された際、アプリケーションからの要求に従い、前記BD-ROMに対応する追加コンテンツを、ネットワークを介して、WWWサーバから取得する。取得された追加コンテンツはGUI管理テーブルが記述されてあるBD-Jオブジェクトを含む。再生装置１０２において、記録制御を行う制御部は、前記アプリケーションからの要求に従い、取得した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(TM)アプリケーション)
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(TM)プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-J Extensionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java(TM) 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は、コンテンツの所在に拘らず、シームレス再生を実現する。

(プレーンコントローラの制御内容)
メモリデバイスがSDRAMによって構成される場合、プレーンコントローラの処理としては、SDRAMをアクセスするための特有の制御が必要になる。

SDRAMは、時分割でアドレスピンに出力されたROWアドレスをメモリアレイに出力するROWアドレスデコーダ、時分割でアドレスピンに出力されるたCOLUMNアドレスをメモリアレイに出力するCOLUMNアドレスデコーダ、メモリアレイから読み出された一ページ長のデータを保持してデータピンに出力するページデータバッファ、バースト読み出しすべきワード長をページデータバッファに指示するワード長レジスタとを有する。SDRAMは、記憶素子に、コンデンサを採用しているので、自然放電が発生する。そのため、SDRAMでは、各記憶素子に対して、リフレッシュを行う必要があり、そのリフレッシュのための付加回路が必要になる。

SDRAMにピクチャが格納されでいる場合、プレーンコントローラは、RAS,CAS,WE,CS,CKEの状態の組合せにてコマンドを形成し、これとアドレスの組合せによって、読み出し／書き込みを実行する。例えば、バースト転送モードを利用する場合、活性化コマンドを発行すると共に、SDRAMのアドレスピンにROWアドレスを発行する。発行から一定時間のディレイを行った上でREADコマンドを発行すると共に、アドレスピンにCOLUMNアドレスを発行する。

(プログラミング言語の適用範囲)
上記実施形態では、仮想マシンのプログラミング言語としてJava（TM）を利用したが、Java（TM）ではなく、UNIX（TM） 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などの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。

また、記録媒体は光ディスク以外にも例えば、ＳＤメモリーカードなどのリムーバブルメディア（半導体メモリカード）であっても本発明の実施は可能である。

BD-ROMでは例えば、図３０に示すBD-ROMドライブ109を介してリードバッファ１、リードバッファ２へデータ、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３に転送されるように構成していたのに対し、BD-ROMの代わりに半導体メモリを用いた場合には、半導体メモリーカード内のデータを読み出すためのインターフェイス（メモリーカードＩ／Ｆ）を介してリードバッファ１、リードバッファ２へデータ、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３に転送されるように構成すればよい。

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

ＢＤ−ＲＯＭに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。

例えば、ＢＤ−ＲＯＭに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。

以後、ＢＤ−ＲＯＭに記録されたデータのうち、暗号化されているデータの解読について説明をする。

再生装置においては、ＢＤ−ＲＯＭ内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。

一方、ＢＤ−ＲＯＭには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するＭＫＢ（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びＭＫＢに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、ＭＫＢ、及び暗号化タイトルキーは対になっており、さらにＢＤ−ＲＯＭ上の通常コピーできない領域（ＢＣＡと呼ばれる領域）に書き込まれた識別子（例えばボリュームＩＤ）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、ＭＫＢ及びボリュームＩＤを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。

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

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

本実施の形態では記録媒体としてＢＤ−ＲＯＭを例に説明をしたが、ＢＤ−ＲＯＭに必ずしも限定されるのではなく、例えば、読込み／書込み可能な半導体メモリー（例えばＳＤカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。

例えば、ＢＤ−ＲＯＭに記録されるデータに相応するデータを例えば電子配信を利用して半導体メモリーカードに記録して、半導体メモリーカードから再生をするような構成としても良い。電子配信を利用して必要なデータを配信し、配信されたデータを記録する場合においても、配信されたデータのうちの一部または全てのデータに対して必要に応じて暗号化を行なって配信し、半導体メモリーに必要なデータについては暗号化がなされたままで記録するのが望ましい。

例えば電子配信を利用して、本実施の形態で説明をしたデータに相応するデータ（配信データ）を半導体メモリーに記録する動作について説明をする。

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

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

この、ＳＤメモリーカードを一意に識別するための識別情報は例えば上述のボリュームＩＤに相当する。

一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。

例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。

また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。

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

次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。

次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。

受信した公開鍵情報は例えば公開鍵本体（例えば上述のＭＫＢ及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。

署名情報には例えば、公開鍵情報のハッシュ値を含む。

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

半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。

まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。

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

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

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

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

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

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

従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。

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

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

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

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

また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。

（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。

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

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

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。

(システムLSIの単体実施)
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。

ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステム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の内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。

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

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

開発したチップと開発したチップに関連するミドルウェアとの間のインターフェイス部分について、共通にすると、汎用性が高くなる。

なお、システムＬＳＩにて構成をした部分に関しては、ＬＳＩでしか構成ができないというものではなく、システムＬＳＩに含まれるべき機能に対応する信号処理回路を用いて構成をしても良いことは言うまでもない。

本発明に係る、平面表示と立体表示を動的に切り換え可能にする記録媒体、その再生装置および再生方法は、殊に、AVコンテンツの制作に携わる映画産業、および、それを処理する機器の製造に携わる民生機器産業において利用される可能性が高い。例えば、BD-ROMディスク、および、BD-ROMプレーヤ等として利用可能である。

１ リードバッファ
２ リードバッファ
６ デマルチプレクサ
７a,b ビデオデコーダ
８a,b ビデオプレーン
９ オーディオデコーダ
１０ HDMIインターフェイス
１２ 再生状態／設定レジスタセット
１３ 静的シナリオメモリ
１４ 再生制御エンジン
１５ 基本グラフィクスプレーン
１６ 拡張グラフィクスプレーン
１７ プレーンコントローラ
１８a,b 色変換部
１９a,b 合成器
２１ MPU
２２ ROM
３０ 動的シナリオメモリ
３１ ヒープメモリ
１０１ BD-ROM
１０２ 再生装置
１０３ テレビ
１０４ ゴーグル
１０５ フロントエンド部
１０６ システムLSI
１０７ メモリデバイス
１０８ バックエンド部
１０９ BD-ROMドライブ
１１０ ローカルストレージ

本発明は、立体視再生の技術分野に属する発明である。

立体視再生とは、ライトビュー用とレフトビュー用の２つの視点の映像を準備することにより、立体視を実現する技術である。技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。継時分離方式とは、レフトビュー用映像及びライトビュー用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。この方式では、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。これらの左右の映像を、別々のメモリに格納して合成に供する必要があるので、一フレーム分の画素データを格納するためのメモリ(プレーンメモリ)は、2つ必要になる。

尚、平面表示と立体表示を動的に切り換える手法としては、特開２００４-１０９３３０号公報に記載されている切り替え方法がある。特開２００４-１０９３３０号公報に記載されている再生装置は、キー入力手段と、平面表示（２D）と立体表示（３D）の表示切り換え手段を備え、前記キー入力手段によるキー入力に応じて、前記表示切り換え手段による平面表示と立体表示を切り換える。

特開２００４−１０９３３０号公報

ところで立体視コンテンツの再生時に、アプリケーションを起動して、アプリケーションにGUIを描画させることで、立体視コンテンツの再生時におけるユーザ操作を容易に行わせたいという要望がある。これは、既存のBD-ROMコンテンツにおいて、コンテンツと、アプリケーションとを連動させて、アプリケーションにGUI処理を行わせるという高度な処理が実現されており、これを立体視コンテンツでも実現したいというコンテンツ制作者側からの要望による。しかしGUIを描画するためのプレーンメモリであるグラフィクスプレーンは、動画像の立体視を実現するためのプレーンメモリ(ビデオプレーン)とは別に確保にする必要があるので、再生装置では、平面視コンテンツの再生と比較して、倍のビデオプレーン、倍のグラフィクスプレーンの確保が必要になる。そして、GUIにHDTV向けの画質を解像度に求めようとすると、そのために必要となるメモリ規模も倍になり、これとビデオストリームの格納のためのビデオプレーンと併せて、再生装置に実装されるメモリデバイスのほとんどの領域が、プレーンメモリに占有されることになる。具体的には、HDTV向けの画質は1920×1080という解像度が必要であり、一画素当たりのインデックスのビット長を32ビットとすると、グラフィクスプレーンの総容量は8Mバイト(≒1920×1080×32)になる。立体視を行うにあたって、このグラフィクスプレーンを、ライトビュー用、レフトビュー用のそれぞれに割り当てたとすると、16Mバイトものメモリが費やされることになり、リソースを圧迫する。

一方、動作に必要なリソースが欠乏すると、アプリケーションの動作が不安定になり、ブラックアウトやハングアップの多発を招く恐れがある。特に、複数のコンテンツのうち、一部のものが立体視コンテンツであり、残りは平面視コンテンツであるような場合、立体視のためのプレーンメモリの追加が必要になるのは、一部のコンテンツの再生時に限られる。にもかかわらず、一旦立体視コンテンツが再生されれば、そのグラフィクスプレーンが確保されたままになって、上述したような動作の不安定化をむやみに引き起こすというのは、不合理である。

上述した先行技術文献に記載されている立体視の切り替えは、ユーザが積極的な意思をもって立体視を実現するか、平面視を実現するかを切り替えるものであり、かかる技術を適用したとしても、ユーザが積極的な意思をもって立体視再生を平面視再生に切り替えない限り、立体視のためのプレーンメモリは確保されたままになるので、かかる文献記載発明は、上述したような技術的課題の解決をもたらすものではない。

本発明の目的は、一部のものが立体視コンテンツであり、残りは平面視コンテンツであるような複数のコンテンツを再生する場合に、リソースの欠乏を避けることができる記録媒体を提供することである。

上記課題を解決するため、本発明にかかる再生装置は、映像データと、管理オブジェクトと、アプリケーションを含む複数のコンテンツが記録されている記録媒体であって、前記コンテンツに含まれる映像データには、平面視映像を構成するものと、立体視映像を構成するものとがあり、前記複数のコンテンツのそれぞれに含まれる管理オブジェクトは、アプリケーション管理テーブルと、コンフィグレーション情報とを含み、前記アプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションを再生装置に指示する情報を含み、前記コンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報およびフラグを含み、前記フラグは、グラフィクスの立体視を実現するために、複数のグラフィクスプレーンを前記メモリデバイス上に確保する必要があるか否かを示すことを特徴としている。

上述したようなコンフィグレーション情報におけるフラグは、グラフィクスの立体視を実現するために、複数のグラフィクスプレーンを確保する必要があるか否かを示すので、グラフィクスプレーンの追加が必要ではないコンテンツの再生時にあたっては、確保すべきグラフィクスプレーンの規模が一つに戻ることになる。立体視コンテンツのために、グラフィクスプレーンを追加したとしても、その追加のグラフィクスプレーンが確保されたままになって、メモリにおける空き容量が圧迫を受けることはない。そのため、アプリケーションの動作を安定させることができる。多くのコンテンツのうち、唯一つだけが立体視再生を実現し、その他は平面視再生しか実現しえないようなBD-ROMを再生対象にする場合、立体視コンテンツの再生後に、即座に、立体視のための複数のグラフィクスプレーンを解放することができる。

先行文献における特許文献１に記載された技術では、立体視の要否をユーザが切り替えるため、プレーンメモリを確保したり強制的に解放するような制御を実現することはできないが、本発明では、オーサリング側が意図するような確保を実現することができるので、アプリケーションの安定動作を実現することができる。

記録媒体、再生装置の、使用行為についての形態を示す図である。 BD-ROMの内部構成を示す。 BD-ROMのアプリケーションフォーマットを示す図である。 レフトビューストリーム、ライトビューストリームを構成する各ソースパケットがどのような過程を経てAVデータ領域に書き込まれるかを示す。 BD-ROMの物理単位と、1つのファイルエクステントを構成するソースパケットとの対応関係を示す図である。 TSパケットのパケットIDがとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。 インターリーブ配置の一例を示す図である。 立体視のためのベースビューストリーム、エンハンスドビューストリームの内部構成の一例を示す図である。 ゴーグルの透光／遮光を、図８のタイミングに従って切り替えることにより、どのような映像が再生に供されるかを示す図である。 目の残像反応により形成される立体映像を示す図である。 クリップ情報ファイルの一例を示す図である。 エントリーマップテーブルの内部構成を示す図である。 エントリーマップによるエントリーポイントの登録を示す。 レフトビュー、ライトビューのそれぞれに対応するエントリーマップが、どのように設定されているかを示す図である。 プレイリスト情報のデータ構造を示す図である。 サブパス情報テーブルの内部構成を示す図である。 レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。 プレイリスト情報におけるエクステンションデータの内部構成を示す図である。 ビデオストリーム番号テーブルの内部構成を示す図である。 JARアーカイブファイルの内部構成を示す図である。 BD-Jオブジェクトの内部構成を示す図である。 GUI管理テーブルの内部構成を示す図である。 ビデオプレーンの解像度と、グラフィクスプレーンとの対応関係を示す。 GUI管理テーブルの設定と、メモリの内容とを示す。 解像度コード＝"２"、"３"で確保されるグラフィクスプレーンを示す。 グラフィクスプレーンの確保、解放の時間的遷移を示す。 BD-Jアプリケーションによるグラフィクスの書き込みを示す。 ベースビューストリーム、エンハンスドビューストリームの再生と、BD-JアプリケーションによるGUI処理とが、連動する場合に再生される立体視映像の一例を示す。 再生装置の内部構成を示す図である。 フロントエンド部１０５〜バックエンド部１０８内の構成要素を示す図である。 再生装置におけるソフトウェアレイヤモデルを示す図である。 左側に、Index.bdmv、BD-Jオブジェクトを描き、右側に、ソフトウェアのレイヤモデルを描いた図である。 ソフトウェアレイヤモデル上に存在するBD-Jアプリケーションと、ビデオプレーン、グラフィクスプレーンとを1つにまとめて描いた図である。 モジュールマネージャ４２による処理手順を示すフローチャートである。 プレイリスト情報の再生手順を示すフローチャートである。 プレーンコントローラの処理手順を示すフローチャートである。 BD-JアプリケーションによるGUI処理の処理手順を示すフローチャートである。 フレーム精度アニメーション実行部８０を示す図である。

(第１実施形態)
図面を参照しながら、上記課題解決手段を具備した記録媒体、再生装置の実施形態について説明する。

図１は、記録媒体、再生装置の、使用行為についての形態を示す図である。本図に示すように、記録媒体の一例である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を含む。

ベースビューストリーム及びエンハンスドビューストリームを構成するソースパケットは、第3段目において、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段目に示すように、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のソースパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のソースパケットを"Aligned Unit"といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。

第３段目においてセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unitの単位でBD-ROMをアクセスする限り、32個の完結したソースパケットを得ることができる。以上がBD-ROMに対するAVクリップの書き込みのプロセスである。

図６は、TSパケットのパケットIDがとりうる複数の数値範囲と、各数値範囲のパケットIDをもつTSパケットのPESストリーム種別とを対応付けて示す図である。

0x0100のパケットIDをを有するTSパケットはプログラムマップ（Program＿map）を構成し、0x1001のパケットIDをを有するTSパケットはプログラムクロックレファレンス(PCR)を構成する。

0x1011のパケットIDを有するTSパケットはベースビューストリーム、Ox1012のTSパケットはエンハンスドビューストリームを構成する。

0x1100-11FのパケットIDを有するTSパケットはオーディオストリームを構成する。

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

第１段目は、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ピクチャを参照している。

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

図１０は、目の残像反応により形成される立体映像を示す図である。

以上で、ベースビューストリーム、エンハンスドビューストリームの内部構成についての説明を終える。続いて、クリップ情報ファイルについて説明する。

＜クリップ情報ファイル＞
図１１は、クリップ情報ファイルの一例を示す図である。クリップ情報ファイルは、本図に示すように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シーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、STCシーケンスを構成するソースパケット列を示す。

矢印te1,te2,te3,te4は、STC時間軸における再生時点t1,t11,t21,t31と、エントリーポイントとの対応関係を模式的に示しており、矢印sh1,sh2,sh3,sh4は、ATCsequeceにおける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を用いて一意にアクセスされることになる。

以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。

図１５は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、メインパス情報、サブパス情報テーブル、エクステンションデータを含む。

先ずメインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。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』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem＿random＿access＿flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still＿mode』と、『STN＿table』と、『BaseView＿indicator』と、『STN＿table』と、『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つ以上のSubPlayItem情報(・・・SubPlayItem情報＃１〜＃ｍ・・・)とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、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ピクチャは、時間軸において同じ時点になる。

レフトビューと、ライトビューとは、プレイアイテム情報、SubPlayItem情報とによって、対応付けられることになる。

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

図１９は、ビデオストリーム番号テーブルの内部構成を示す図である。

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

「Stream＿entry」は、プライマリビデオストリームを構成するPESパケットのPIDに対する参照値を示す『ref＿to＿stream＿PID＿of＿main＿Clip』『video＿format』『frame＿rate』を含む。

これらのテーブルにおけるstream＿entryの順位は、再生装置がストリームを選択するにあたって、ストリーム選択の優先順位を意味する。つまり、テーブルにおけるにおいてエントリーが高い順位にあるものを再生装置は、優先的に選択することになる。

enhanced＿view＿is＿availableフラグがオンであり、エンハンスドビューに設定されている場合、ref＿to＿stream＿of＿MainCLipには、0x1011のパケットIDと、0x1012のパケットIDとが記述される。

本願明細書におけるコンテンツとは、あるタイトル番号にて管理されるプレイリスト情報と、このプレイリスト情報から参照されるAVクリップに多重化されているビデオストリームおよび後述するBD-Jオブジェクトと、BD-Jオブジェクトによって示される起動が許されたアプリケーションとを包含する単位であり、"タイトル"と呼ばれる。

以上がプレイリスト情報についての説明である。

＜JARディレクトリ＞
続いて、JARディレクトリについて説明する。JARディレクトリは、JARアーカイブファイル(XXXXX.JAR)を格納している。

JARアーカイブファイルは、http：//java(TM).sun.com/j2se/1.4.2/docs/guide/jar/jar.htmlに記載された仕様に準じたファイルである。JARアーカイブファイルは複数のファイルをディレクトリ構造の形で格納している。図２０は、JARアーカイブファイルの内部構成を示す図である。

この内部構成は、ルートディレクトリ直下に「XXXXX.class」「XXXXX.PNG」が存在し、META-INFディレクトリにファイル「MANIFEST.MF」、ファイル「SIG-BD.SF」、ファイル「SIG-BD.RSA」、ファイル「bd.XXXXX.perm」が存在するというものである。

このXXXXX.class(クラスファイル)は、Java言語等のオブジェクト指向言語で記述されたクラス構造体をコンパイルすることで得られたバイトコードを格納している。かかるクラスファイルは、BD-Jアプリケーションを定義するものであり、Java(TM)仮想マシン上で実行可能となる。MANIFEST.MFは、デジタル証明書に対応するものであり、SIG-BD.SFは、MANIFEST.MFのハッシュ値が記載されているファイルである。SIG-BD.RSAは、デジタル証明書チェーン、署名情報が記載されているファイルである。bd.XXXXX.permは、パーミッションリクエストファイルであり、実行されるBD-Jアプリケーションにどのようなファイルへのアクセスを許可するのかを示すパーミッションに関する情報を格納する。

JARアーカイブファイルにおけるクラスファイルにて定義されるBD-Jアプリケーションは、Xletインターフェイスを通じて、アプリケーションマネージャにより、制御されるJava(TM) Xletである。Xletインターフェイスは、"loaded","paused"、"active","destoryed"といった4つの状態をもつ。

またJava(TM)アプリケーションは、JFIF(JPEG)やPNG,その他のグラフィクスデータを表示するためのスタンダードJavaライブラリを用いて、GEM1.0.2にて規定されたHAViフレームワークを実現する。HAViフレームワークは、GEM1.0.2におけるリモートコントロールナビゲーション機構を含むGUIフレームワークであり、Java(TM)アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。

図中のPNGファイルは、例えばBD-JアプリケーションがGUIに用いるアニメーションデータを格納している。

以上がJARファイルについて説明である。

続いて、BD-Jオブジェクトについて説明する。図２１は、BD-Jオブジェクトの内部構成を示す図である。本図に示すように、BD-Jオブジェクトは、「アプリケーション管理テーブル」、「GUI管理テーブル」、「プレイリスト管理テーブル」から構成される。

以下、これらの構成要素について説明する。

「アプリケーション管理テーブル」は、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。引き出し線bj1は、アプリケーション管理テーブルの内部構成をクローズアップして示している。この引き出し線に示すように、アプリケーション管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定する『アプリケーション識別子』と、『制御コード』とを含む。制御コードは、AutoRunに設定された場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、他のアプリケーションからのコールを待って、起動すべき旨を示す。

「GUI管理テーブル」は、動作中のアプリケーションがGUIを行う際の管理テーブルであり、GUI表示を実行するにあたってのコンフィグレーション情報や、GUIに用いるフォントデータ、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。このコンフィグレーション情報は、BD-Jオブジェクト内のアプリケーション管理テーブルによって起動されるべきアプリケーションがグラフィクスを描画するにあたって、再生されるビデオストリームの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報である。

引き出し線bj2は、プレイリスト管理テーブルの内部構成をクローズアップして示している。プレイリスト管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、自動的に再生されるべきプレイリストの指定を含む。また、プレイリスト管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させることができるアプリケーションが選択できるプレイリストの指定を含む。

続いて、GUI管理テーブルの内部構成について詳細に説明する。

図２２（ａ）は、GUI管理テーブルの内部構成を示す図である。引き出し線gh1は、GUI管理テーブルの構成をクローズアップしている。引出線gh1に示すように、GUI管理テーブルは「基本プレーンコンフィグレーション」、「表示方式フラグ」、「拡張プレーンコンフィグレーション」から構成される。「基本プレーンコンフィグレーション」は、ベースビューストリームに合成すべきグラフィクス(ベースビューグラフィクス)のために確保すべき、グラフィクスプレーンのコンフィグレーションを示す。「拡張プレーンコンフィグレーション」は、エンハンスドビューストリームに合成すべきグラフィクス(エンハンスドビューグラフィクス)のために確保すべき、グラフィクスプレーンのコンフィグレーションを示す。これら基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションを併せて、本願では、"コンフィグレーション情報"とよぶ。引き出し線gh2,gh3は、基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションの設定内容を示す。この引出線に示すように、基本プレーンコンフィグレーション、拡張プレーンコンフィグレーションには何も、解像度コードが設定される。

図２２（ｂ）は、表示方式フラグのビットアサインを示す図である。"０"である場合、GUIの平面視を行うから、確保すべきグラフィクス用のプレーンメモリ(グラフィクスプレーン、又は、イメージプレーンと呼ばれる。)は単一である旨を示す。"１"である場合、GUIの立体視を実行するから、確保すべきグラフィクスプレーンは複数である旨を示す。

図２２（ｃ）は、解像度コードの意味内容を示す。解像度コードが"1"に設定された場合、確保すべきグラフィクスプレーンの規模は、720×480画素であることを示す。解像度コードが"２"に設定された場合、確保すべきグラフィクスプレーンの規模は、960×540画素であることを示す。解像度コードが"３"に設定された場合、確保すべきグラフィクスプレーンの規模は、1920×1080画素であることを示す。解像度コードが"４"に設定された場合、確保すべきグラフィクスプレーンの規模は、1280×720画素であることを示す。

図２３は、ビデオプレーンの解像度と、グラフィクスプレーンとの対応関係を示す。左側はビデオプレーンの解像度を示し、右側は、グラフィクスプレーンの解像度を示す。真ん中の矢印は、許容されるビデオプレーンの解像度と、グラフィクスプレーンの解像度との組合せを示す。ビデオプレーンの解像度コードが720×480画素であれば、矢印kw1に示すように、グラフィクスプレーンの解像度コードとして、720×480画素の解像度コードの設定が許容される。

ビデオプレーンの解像度が、1920×1080画素であれば、矢印kw2,kw3に示すように、グラフィクスプレーンの解像度コードとして、960×540画素の解像度コード、又は、1920×1080画素の解像度コードの設定が許容される。

ビデオプレーンの解像度コードが、1280×720画素を意味するものであれば、矢印kw4に示すように、グラフィクスプレーンの解像度コードとして、1280×720画素の解像度コードの設定が許容される。

図２４（ａ）は、GUI管理テーブルの設定と、メモリの内容とを示す。

GUI管理テーブルにおいて、表示方式フラグが"０"に設定されている場合、基本プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリが、メモリに確保される。ここで、基本プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthB,縦画素数＝HeightBである場合、WidthB×HeightBという規模のプレーンメモリがメモリに確保されることになる。一方、表示方式フラグ"=0"であれば、拡張グラフィクスプレーンは確保されない。

図２４（ｂ）は、GUI管理テーブルの設定と、メモリの内容とを示す。GUI管理テーブルにおいて、表示方式フラグが"１"に設定されている場合、基本プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリと、拡張プレーンコンフィグレーションにおける解像度コードに応じたプレーンメモリとが、メモリに確保される。ここで、基本プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthB,縦画素数＝HeightBである場合、WidthB×HeightBという規模のプレーンメモリがメモリに確保されることになる。一方、表示方式フラグ"1"であるので、拡張グラフィクスプレーンが確保される。ここで、拡張プレーンコンフィグレーションにおける解像度コードが、横画素数＝WidthE,縦画素数＝HeightEである場合、WidthE×HeightEのプレーンメモリがメモリに確保されることになる。

図２５（ａ）は、解像度コードが"２"で確保されるグラフィクスプレーンを示す。解像度コードが"２"で確保されるグラフィクスプレーンとは、960×縦540の32ビット領域からなる。つまり解像度コードが"２"で復号されるグラフィクスプレーンとは、960×540の解像度で、1画素当たり32ビットのRGB値を格納できるメモリアロケーションである。32ビットのRGB値は、８ビットの赤画素の輝度(Ｒ値)、８ビットの緑画素の輝度(Ｇ値)、８ビットの青画素の輝度(Ｂ値)、透明度であるα値を含む。

図２５（ｂ）は、解像度コードが"３"で確保されるグラフィクスプレーンを示す。解像度コードが＝"３"で確保されるグラフィクスプレーンとは、横1920×縦1080の32 ビット領域からなる。これは1920×1080の解像度で、1画素当たり32 ビットのＲＧＢ値を格納できるメモリアロケーションをもつ領域ことをいう。

アプリケーションがGUI管理テーブルにおけるコンフィグレーション情報にて規定された解像度コードの座標系を基準にして、グラフィクスの書き込み位置を定める。具体的には、1920×1080 720×480といった解像度コードの画素のうち、左上画素を原点とした座標系にて、グラフィクスの書き込み座標は規定される。

図２６は、グラフィクスプレーンの確保、解放の時間的遷移を示す。第1段目は、映像内容を示し、第2段目は、時間軸を示す。第3段目は、BD-Jオブジェクトの内部構成を示し、第4段目は、メモリデバイスの内容を示す。 第2段目に示すように、タイトル＃1、＃3が平面視コンテンツであり、タイトル＃2が立体視コンテンツであり、タイトル＃1、＃3に対応するBD-Jオブジェクト内のGUI管理テーブルが表示方式フラグが"0"に設定されているものとする。またタイトル＃2に対応するBD-JオブジェクトのGUI管理テーブルが表示方式フラグが"1"に設定されているものとする。

以上の条件下におけるメモリデバイスのグラフィクスプレーン確保の時間的遷移は、第4段目に示す通りになる。第4段目では、カレントタイトルがタイトル＃1になったタイミングにおいて、メモリデバイスにおけるグラフィクスプレーンがクリアされて、その後、基本グラフィクスプレーンがメモリデバイスに確保される。カレントタイトルがタイトル＃2になると、メモリデバイスにおけるグラフィクスプレーンがクリアされて、その後、基本グラフィクスプレーン、及び、拡張グラフィクスプレーンがメモリデバイスに確保される。

カレントタイトルがタイトル＃3になると、基本グラフィクスプレーン、拡張グラフィクスプレーンがクリアされて、基本グラフィクスプレーンのみが確保される。

カレントタイトルがタイトル＃2になった期間だけ拡張グラフィクスプレーンがメモリデバイスに確保され、カレントタイトルがタイトル＃3になれば、拡張グラフィクスプレーンは解放されるので、メモリデバイスにおける容量が、グラフィクスプレーンによって長く占有されることはない。

以上が、GUI管理テーブルの説明である。続いて、BD-JアプリケーションによるGUI処理の詳細について説明する。

＜アニメーションの実現＞
GUI処理において、BD-Jアプリケーションによって描画されるグラフィクスの代表的なものは、メニュー、アニメーションである。メニューには、複数のボタン部材が存在し、個々のボタン部材は、ノーマル状態、フォーカス状態、アクティブ状態といった状態をもつ。リモコンにおける左右キーを押下することにより、フォーカス状態になるべきボタンを切り換えることができ、またBD-Jアプリケーションは、リモコンにおけるEnterキーの押下に応じて、現在フォーカス状態にあるボタンに対応する処理を実行する。

アニメーションは、グラフィクスに既に書き込まれたグラフィクスを、ある時間間隔において、順次上書きしてゆくことでなされる。以下、アニメーションを実現するためのグラフィクス書き込みについて説明する。

グラフィクスプレーンにおいて、アニメーションを構成するグラフィクスは、グラフィクス管理のための数値にて管理されており、この数値に対応するグラフィクスデータの画像は、画面上に一定時間だけ表されることになる。一方、その一定時間のあいだ、アプリケーションの側では、新たなグラフィクスの生成がなされている。一定時間が経過すれば、グラフィクスプレーンの格納内容は、新たに生成されたグラフィクスデータを用いて上書きされることになる。かかる上書きにおいて、グラフィクス管理のための数値は更新される。こういった動作、つまり、"アプリケーションによるグラフィクスの生成"、"生成されたグラフィクスの更新"、"グラフィクスの上書き"、"グラフィクス管理のための数値の更新"という一連の動作の繰り返しにより、グラフィクスのアニメーション表示は実現されることになる。

また単位時間（例えば一秒間など）における上述の一連の動作の繰り返しの回数（以後アプリケーションの実行速度と称す）を変えることにより、グラフィクスプレーンの格納内容が単位時間あたりに更新されるタイミングの数を増減させることが可能となる。これにより結果として、入力に対するアプリケーションによるグラフィクス描画によるGUI表示の応答性を高くしたり、低くしたりすることが可能となる。

このような処理に加え、立体視時には、グラフィクスを立体視を実現するため、当該座標系におけるグラフィクスの書き込み位置をずらす。こうすることで、グラフィクスの立体視を実現する。

図２７は、BD-Jアプリケーションによるグラフィクスの書き込みを示す。表示方式フラグが"１"である場合、拡張グラフィクスプレーンが追加される。BD-Jアプリケーションは、これらの基本グラフィクスプレーン、拡張グラフィクスプレーンのそれぞれにグラフィクスを書き込む。

このように、１つのグラフィクスデータを左右にずらして基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込むことにより、グラフィクスが、映像より前に浮き出て見える。

図２８は、ベースビューストリーム、エンハンスドビューストリームの再生と、BD-JアプリケーションによるGUI処理とが、連動する場合に再生される立体視映像の一例を示す。基本グラフィクスプレーン、拡張グラフィクスプレーンのそれぞれに、グラフィクスを書き込むので、立体視映像には、メニューやアニメーションが立体的に現れることになる。

以上でBD-Jオブジェクト及びGUI管理テーブルについての説明を終える。

図２９は、再生装置の内部構成を示す図である。本図において再生装置を構成する主だった部品は、フロントエンド部１０５、システムLSI１０６、メモリデバイス１０７、バックエンド部１０８である。

フロントエンド部１０５は、データ入力源である。

後述する図３０において、フロントエンド部１０５は例えば、BD-ROMドライブ１０９、ローカルストレージ１１０を含む。

システムLSI１０６は、論理素子から構成され、再生装置中核をなす。

後述する図３０において、システムＬＳＩ１０６は例えば、MPU２１、プレーンコントローラ１７、デマルチプレクサ６、ビデオデコーダ７ａ、ビデオデコーダ７ｂ、オーディオデコーダ９、色変換部１８ａ、色変換部１８ｂ、合成器１９ａ、合成器１９ｂを含む。システムＬＳＩは一チップで構成しても良いし、複数のチップで構成しても良い。

メモリデバイス１０７は、SDRAM等のメモリ素子のアレイによって構成される。

後述する図３０において、メモリデバイス１０７は例えば、リードバッファ１、リードバッファ２、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３、バイトコードインタプリタ、コマンドインタプリタ、組込みＲＯＭ２２、再生制御エンジン１４、ＰＳＲセット１２、基本グラフィクスプレーン１５、拡張グラフィクスプレーン１６、基本ビデオプレーン８ａ、拡張ビデオプレーン８ｂを含む。

例えば、メモリデバイス１０７にバンクメモリ方式を採用する場合、メモリデバイス上の領域は、統一したメモリ空間として認識されるので、BD-Jアプリケーションの動作時においては、かかるメモリデバイスの領域を、リソースとしてBD-Jアプリケーションによる利用に供する。そしてCPUにおけるメモリ空間の一部に、複数のプレーンメモリがマッピングされることになる。

バックエンド部１０８は、再生装置内部と、他の装置との接続インターフェイスである。

後述する図３０において、バックエンド部１０８は例えば、HDMI送受信部１０を含む。

上述したように、フロントエンド部１０５は例えば、BD-ROMドライブ１０９、ローカルストレージ１１０を含む。

BD-ROMドライブ１０９は、BD-ROMのローディング/イジェクトを行い、システムLSI１０６からの指示に応じて、ベースビューストリームを構成するエクステント、エンハンスドビューストリームを構成するエクステントをBD-ROMから読み出す。

BD-ROMドライブ109は例えば、半導体レーザ（図示せず）、コリメートレンズ（図示せず）、ビームスプリッタ（図示せず）、対物レンズ（図示せず）、集光レンズ（図示せず）、光検出器（図示せず）を有する光学ヘッド（図示せず）を備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。集光された光ビームは、光ディスク上で反射／回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、生成された信号がBD-ROMから読み出されたデータに対応する。

ローカルストレージ１１０は、ビルドインメディア、リムーバブルメディアを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。また、ダウンロードした追加コンテンツをどのようにBD-ROM上のデータとマージされるか、マージ規則が記載されたマージ管理情報もこのビルドインメディア、リムーバブルメディアに保存される。

ビルドインメディアとは例えば再生装置に内蔵されたハードディスクドライブ、メモリなどの書き込み可能な記録媒体である。

リムーバブルメディアとは、例えば可搬性を有する記録媒体であり、好適にはＳＤカードなどの可搬性を有する半導体メモリーカードである。

リムーバブルメディアを半導体メモリーカードとしたときを例に説明をすると、再生装置にはリムーバブルメディアを装着するためのスロット（図示せず）およびスロットに装着されたリムーバブルメディアを読み取るためのインターフェース（例えばメモリーカードＩ／Ｆ）が備えられており、スロットに半導体メモリを装着すると、リムーバブルメディアと再生装置とが電気的に接続され、インターフェース（例えばメモリーカードＩ／Ｆ）を利用して、半導体メモリに記録されたデータを電気信号に変換して読み出すことが可能となる。
＜再生装置における詳細構成＞
これらフロントエンド部１０５〜バックエンド部１０８内の構成要素を更に詳細に説明する。図３０は、フロントエンド部１０５〜バックエンド部１０８内の構成要素を示す図である。本図に示すように、フロントエンド部１０５〜バックエンド部１０８内には、リードバッファ１,２、デマルチプレクサ６、ビデオデコーダ７a,b、基本ビデオプレーン８a,b、オーディオデコーダ９、HDMIインターフェイス１０、再生状態／設定レジスタセット１２、静的シナリオメモリ１３、再生制御エンジン１４、基本グラフィクスプレーン１５、拡張グラフィクスプレーン１６、プレーンコントローラ１７、色変換部１８a,b、合成器１９a,b、MPU２１、ROM２２、動的シナリオメモリ３０、ヒープメモリ３１といった構成要素が存在する。

リードバッファ１は、BD-ROMドライブ１か読み出されたベースビューストリームを構成するエクステントを構成するソースパケットを一旦格納しておき、転送速度を調整した上、デマルチプレクサ６に転送するためのバッファであり、上述したような"RB1"という規模をもつ。

リードバッファ２は、BD-ROMドライブ１か読み出されたエンハンスドビューストリームを構成するエクステントを構成するソースパケットを一旦格納しておき、転送速度を調整した上、デマルチプレクサ６に転送するためのバッファであり、上述したような"RB2"という規模をもつ。

デマルチプレクサ６は、ソースパケットデパケッタイザー、PIDフイルタから構成され、ベースビューストリームを構成するエクステント、エンハンスドビューストリームを構成するエクステントが、リードバッファ１、２を介して転送されれば、ベースビュービデオストリームを構成するTSパケット、エンハンスドビュービデオストリームを構成するTSパケットを当該エクステントから分離して、ビデオデコーダ７a、ビデオデコーダ７ｂに転送する。

ビデオデコーダ７aは、デマルチプレクサ６から出力されたベースビューストリームを構成するTSパケットを復号して非圧縮形式のピクチャを基本ビデオプレーン８aに書き込む。

ビデオデコーダ７ｂは、デマルチプレクサ６から出力されたエンハンスドビューストリームを復号してTSパケットを復号して非圧縮形式のピクチャを拡張ビデオプレーン８ｂに書き込む。

基本ビデオプレーン８aは、ベースビューストリームを構成する非圧縮形式のピクチャを格納しておくためのメモリである。

拡張ビデオプレーン８bは、エンハンスドビューストリームを構成する非圧縮形式のピクチャを格納しておくためのメモリである。

オーディオデコーダ９は、デマルチプレクサ６から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。

HDMI送受信部１０は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）に準拠したインターフェイスを含み、再生装置とHDMI接続する装置（この例ではテレビ１０３）とHDMI規格に準拠するように送受信を行うものであり、基本ビデオプレーン８a、拡張ビデオプレーン８bに格納されたピクチャデータと、オーディオデコーダ１３によってデコードされた非圧縮のオーディオデータとを、HDMIインターフェイス１０を介してテレビ１０３に伝送する。テレビ１０３は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からＨＤＭＩインターフェイスを介して要求があると、テレビ１０３は要求された必要な情報（例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報）を再生装置へ返す。このように、HDMI送受信部１０を介することで、テレビ１０３が立体視表示に対応しているかどうかの情報を、テレビ１０３から取得することができる。

再生状態／設定レジスタ(Player Status/Setting Register)セット１２は、プレイリストの再生状態や、コンテンツが利用する任意の情報を格納できる領域である。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置（時刻）を再生しているか、などの状態を現すものである。プレイリストの再生状態が変化した際は、再生制御エンジン１４がPSRセット１２に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJavaプラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。以降、PSRのうち、代表的なものについて説明する。

PSR4は、1〜100の値に設定されることで、カレントのタイトル番号を示す。

PSR5は、1〜999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。

PSR6は、0〜999の値に設定されることで、カレントプレイリストの番号を示す。

PSR7は、0〜255の値に設定されることで、カレントプレイアイテムの番号を示す。

PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM)を示す。以上がPSRについての説明である。

静的シナリオメモリ１３は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。

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

基本グラフィクスプレーン１５は、BD-Jオブジェクトにおける基本プレーンコンフィグレーション情報に応じて確保されるプレーンメモリである。

拡張グラフィクスプレーン１６は、表示方式フラグが"１"、つまり立体表示する（オンにする）に設定された場合、BD-Jオブジェクトにおける拡張プレーンコンフィグレーション情報に応じて確保されるプレーンメモリである。

プレーンコントローラ１７は、表示プレーン切換指示に従って、基本グラフィクスプレーン内のグラフィクスデータと、基本ビデオプレーン内のピクチャデータとを合成した画像を出力して、平面表示を行わせるか、あるいは、基本グラフィクスプレーン内のグラフィクスデータと、基本ビデオプレーン内のピクチャデータとを合成した画像とをレフトビュー動画像として出力し、拡張グラフィクスプレーン内のグラフィクスデータと、拡張ビデオプレーン内のピクチャデータとをライトビュー動画像として出力することで、立体表示を行わせるかを制御する。立体表示を行なわせる場合、基本グラフィクスプレーンと基本ビデオプレーンとを合成した画像、及び、拡張グラフィクスプレーンと拡張ビデオプレーンを合成した画像をそれぞれ短い時間間隔の間に切り替えて表示する。

色変換部１８aは、カラールックアップテーブルを用いて、基本グラフィクスプレーン１５に格納されている画素コードを、Y,Cr,Cbといった画素値に変換する。

色変換部１８bは、カラールックアップテーブルを用いて、拡張グラフィクスプレーン１６に格納されている画素コードを、Y,Cr,Cbといった画素値に変換する。

合成器１９aは、基本ビデオプレーン８aに格納された非圧縮形式のピクチャデータの各画素と、基本グラフィクスプレーン１５に展開されたグラフィクスの各画素とを合成する。

合成器１９bは、拡張ビデオプレーン８ｂに格納された非圧縮形式のピクチャデータの各画素と、拡張グラフィクスプレーン１６に展開されたグラフィクスの各画素とを合成する。

MPU２１は、再生装置におけるコンピュータアーキテクチャの中核をなし、ROM２２に格納されているネィティブコードをフェッチして解読し、ネィティブコードに基づき、再生装置の処理を実行する。

ROM２２は、再生装置における組込みプログラムが予め格納されている。

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

ヒープメモリ３１は、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である。

以上が再生装置の内部構成についての説明である。続いて、再生装置のソフトウェアレイヤモデルの詳細について説明する。

図３１は、再生装置におけるソフトウェアレイヤモデルを示す図である。このソフトウェアレイヤモデルでは、HDMVモジュール、BD-Jモジュール、モード管理モジュールという3つの動作主体がMPU２１上に存在する。これらは、動的シナリオメモリ３０に存在するIndex.bdmv、BD-Jオブジェクト、ムービオブジェクトによって制御を行う。

以降、HDMVモジュール、BD-Jモジュール、モード管理モジュールについて説明する。

HDMVモジュールの一例であるコマンドインタプリタ４０は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。HDMVモードの動作主体であるコマンドインタプリタは、シナリオプログラムを構成するナビゲーションコマンドを解読して実行するものである。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

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とをフル実装している。

モード管理モジュールの一例であるモジュールマネージャ４２は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モジュールマネージャ４２によるモード管理とは、動的シナリオをどのコマンドインタプリタ４０、BD-Jモジュールに実行させるかという、モジュールの割り当てである。

以上がコマンドインタプリタ４０、BD-Jモジュール、モジュールマネージャ４２という3についての説明である。続いて、BD-Jプラットフォーム部４１の内部構成について説明する。

BD-Jモジュールは、ミドルウェア３５と、バイトコードインタプリタ３２と、ヒープメモリ３１上に存在するシステムアプリケーションとによって構成される。ヒープメモリ３１上のシステムアプリケーションには、クラスローダ３３、アプリケーションマネージャ３４、ミドルウェア３５に含まれるクラスライブラリの中で、ヒープメモリ３１上に配置されて実行されるものなどがある。以下、これらの構成要素について説明する。

バイトコードインタプリタ３２は、ヒープメモリ３１に格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPU２１に実行させる。

クラスローダ３３は、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、BD-Jアプリケーションのロードを行う。

アプリケーションマネージャ３４は、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。

ミドルウェア３５は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。

メモリデバイスの各領域は、このミドルウェア３５によって、例えばメモリプール管理機能、ヒープエリア管理機能にて管理されている。メモリプール管理機能とは、空きのメモリ領域を管理し、必要に応じて要求されたメモリサイズをアプリケーションに与え、使用が終了すると、メモリに蓄積された状態に戻す。ヒープエリア管理では、メモリの空き領域にメモリプールを設定し、タスクの要求に応じて、必要サイズのメモリを提供する。

以上がBD-Jプラットフォーム部４１についての説明である。続いて、GUI処理を描画するにあたってのBD-Jプラットフォーム部４１の改良について説明する。

あるタイトルがカレントタイトルになった際、BD-Jプラットフォーム４１は、そのカレントタイトルに対応付けられたGUI管理テーブルに記述されているコンフィグレーション情報にもとづいて、プレーンコントローラ１７に対する描画を指示する。

この際、平面表示する場合は、基本グラフィクスプレーンへの描画のみを指示する。立体表示する場合は、基本グラフィクスプレーンに、レフトビュー用のグラフィクス描画、および、拡張グラフィクスプレーンへライトビュー用のグラフィクス描画を指示する。レフトビュー用のグラフィクス描画とは、視点の位置を視聴者のレフトビューの位置でレンダリングした画像であり、ライトビュー用のグラフィクス描画とは、視点の位置を視聴者のライトビューの位置でレンダリングした画像である。

以上がBD-Jプラットフォーム部４１による描画の改良についての説明である。

図３２は、左側に、Index.bdmv、BD-Jオブジェクトを描き、右側に、ソフトウェアのレイヤモデルを描いた図である。矢印は、Index.bdmv、BD-Jオブジェクトの構成要素が、どのように引き渡されるかを示す。丸記号"１"の矢印は、モジュールマネージャ４２によるタイトル番号及び動作モードオブジェクトIDの読み込みを模式的に示している。丸記号"２"の矢印は、アプリケーションマネージャによるアプリケーション管理テーブルの読み込みを模式的に示している。丸記号"３"の矢印は、再生制御エンジン１４によるプレイリスト管理テーブルの読み込みを模式的に示し、丸記号"４"の矢印は、プレーンコントローラ１７によるGUI管理テーブルの読み込みを模式的に示している。

プレーンコントローラ１７は、平面表示する場合は、基本グラフィクスプレーン１５と基本ビデオプレーン８ａの合成出力を合成器１９ａに指示し、立体表示する場合は、基本グラフィクスプレーン１５と基本ビデオプレーン８ａへの合成出力を合成器１９ａに指示するとともに、拡張グラフィクスプレーン１６と拡張ビデオプレーン８ｂの合成出力を合成器１９ｂに指示する。

図３３は、ソフトウェアレイヤモデル上に存在するBD-Jアプリケーションと、ビデオプレーン、グラフィクスプレーンとを1つにまとめて描いた図である。メモリには、アニメーションを構成する複数のグラフィクスが展開されている。矢印は、BD-Jアプリケーションによる書き込みを模式的に示す。つまり、BD-Jアプリケーションは、アニメーションにおける一コマ、一コマにあたるグラフィクスを、ビデオストリームの再生進行に伴い、一枚ずつ基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込んでいることがわかる。

以降、ソフトウェアによるアプリケーションマネージャ３７の実装について説明する。図３４は、モジュールマネージャ４２による処理手順を示すフローチャートである。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、ユーザ操作に応じて、カレントタイトルが新たに選択されたか否かの判定であり、もし選択されれば、ステップＳ７において、メモリデバイスにおけるグラフィクスプレーンを全て解放してステップＳ８に移行する
ステップＳ８は、カレントタイトルに対応するBD-Jオブジェクトに、プレイリスト管理テーブルが存在するか否かの判定である。もし存在しないのであれば、前のタイトルでは、プレイリスト管理テーブルに記載されていたプレイリストの再生を停止させる(ステップＳ９)。

もし存在するのであれば、前のタイトルではプレイリスト管理テーブルに記載されていなかったが、カレントタイトルでは、プレイリスト管理テーブルに記載されており、当該プレイリスト管理テーブルに、AutoPlayプレイリストが存在すれば、AutoPlayプレイリストの再生を開始させる(ステップＳ１０)。

ステップＳ１１では、カレントタイトルに対応するBD-Jオブジェクトに、GUI管理テーブルが存在するか否かの判定を行う。ステップＳ１２は、GUI管理テーブルが存在する場合に実行される判定ステップであり、そのGUI管理テーブルにおけるコンフィグレーション情報をプレーンコントローラ１７に設定して、初期化を実行する(ステップＳ１２)。

ステップＳ１５は、カレントタイトルに対応するBD-Jオブジェクトにアプリケーション管理テーブルが存在するか否かの判定であり、もし存在するなら、前のタイトルを生存区間としていないが、カレントタイトルを生存区間としているJava（登録商標）アプリケーションであって、AutoRun属性を有するものを起動する(ステップＳ１６)。もし存在しないなら、前のタイトルを生存区間としているが、カレントタイトルを生存区間としていないアプリを停止する(ステップＳ１７)。

その後、Java（登録商標）アプリケーションの起動に成功したか否かの判定を行い(ステップＳ１８)、起動に成功すれば(ステップＳ１８でYes)、AutoPlayプレイリストの再生画像をクオータ(1/4)に変換する(ステップＳ１９)という手順を実現するものである。

一方このステップＳ１８がNoであればステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、本フローチャートの起動時にリセットされ、ステップＳ２３において、0か否かの判定がなされる。0でない場合、ステップＳ２４において再起動カウンタはデクリメントされる。以上のステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８〜ステップＳ１９からなるループ処理により、再起動カウンタが0でない限り、AutoRunアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。

ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ２１、ステップＳ２２の処理を実行する。正常終了していればステップＳ２１〜ステップＳ２２を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。

ステップＳ２１は、AutoPlayプレイリストの再生中であるか否かの判定であり、もし再生中なら、AutoPlayプレイリストの再生画像をフルスクリーン化するよう再生制御エンジンに指示する(ステップＳ２２)。その後、ステップＳ２３に移行する。ステップＳ２３への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これにより再起動カウンタの回数が0になるまで、アプリケーションの再起動は繰り返されることになる。

ステップＳ４は、BDドライブ１にBD-ROMが存在しているか否かの判定であり、もしBD-ROMが存在しなければ、全てのアプリケーションに対し、終了指示を発する(ステップＳ６)。

図３５は、プレイリスト情報の再生手順を示すフローチャートである。

ステップＳ３１において、カレント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]からエクステンションデータ[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップＳ３７)、パケットID[j]のTSパケット[j]をStart＿SPN[j]からEnd＿SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップＳ３８)。そしてステップＳ３９において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップＳ４０においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。

図３６は、プレーンコントローラの処理手順を示すフローチャートである。ステップＳ５１において、BD-JオブジェクトのGUI管理テーブルにおける基本プレーンコンフィグレーション情報における縦画素数×横画素数×１画素当たりのバイト数のプレーンメモリをRAM上に確保し、ステップＳ５２、ステップＳ５３に移行する。ステップＳ５２は、HDMIを介して再生装置に接続された相手側機器であるテレビ１０３に立体視の処理能力が存在するかどうかの判定ステップであり、ステップＳ５３は、BD-Jオブジェクトの表示方式フラグが"１" であるか否かの判定ステップである。どちらかの判定がNoであれば、平面視のためのプレーン制御を実行する。何れのステップもYesであれば、立体視による表示が可能と判断し、ステップＳ５４において、BD-JオブジェクトのGUI管理テーブルにおける拡張プレーンコンフィグレーション情報における縦画素数×横画素数×１画素当たりのバイト数のプレーンメモリをRAM上に確保し、ステップＳ５５に移行する。ステップＳ５５は、１／４８秒の表示期間が到来したかどうかの監視であり、もし到来すれば、ステップＳ５５がYesになって、ステップＳ５６〜ステップＳ６０の処理を実行する。具体的には、表示対象になるビデオプレーン、グラフィクスプレーンを決定して(ステップＳ５６)、グラフィクスプレーンに格納されている１ライン分の画素データを読み出して、Y,Cr,CBに変換し(ステップＳ５９)、ビデオプレーンから読み出された1ライン分のY,Cr,CBと画素毎に合成する(ステップＳ６０)という処理を、グラフィクスプレーン、ビデオプレーンにおける全てのラインについて繰り返す(ステップＳ５７、ステップＳ５８)。

なお、本実施の形態において、ステップ５２は、再生装置に接続された相手側機器であるテレビ１０３に立体視の処理能力が存在するかどうかを問い合わせたが、再生装置１０２にユーザインターフェースが存在し、事前に立体視の出力を行うかどうかをユーザに設定させてもよい。

図３７は、BD-JアプリケーションによるGUI処理の処理手順を示すフローチャートである。ステップＳ７１ではコンフィグレーション情報における解像度と、アニメーションデータを構成するグラフィクスの解像度とからグラフィクスのスケーリングファクターを決定し、ステップＳ７２においてベースビューグラフィクスの表示時期が到来するのを待つ。到来すれば、ステップＳ７３において、決定したスケーリングファクターで、ベースビューグラフィクスを表示するための座標((X,Y))を算出し(ステップＳ７３)、基本グラフィクスプレーンの座標(ＸB,ＹB)に、ベースビューグラフィクスを書き込む(ステップＳ７４)。

ステップＳ７５は、表示方式フラグがオンであるか否かの判定であり、表示方式フラグが"0"（つまりオフ）ならステップＳ７２に戻る。

表示方式フラグが"1" （つまりオン）であるなら、ステップＳ７６においてエンハンスドビューグラフィクスの表示時期が到来するのを待つ。到来すれば、ステップＳ７７において、決定したスケーリングファクターで、エンハンスドビューグラフィクスを表示するための座標((X,Y))を算出し(ステップＳ７７)、拡張グラフィクスプレーンの座標(ＸE,ＹE)に、エンハンスドビューグラフィクスを書き込む(ステップＳ７８)。その後、ステップＳ７２に戻る。

以上のように本実施形態によれば、GUI管理テーブルにおけるコンフィグレーション情報の表示方式フラグは、グラフィクスの立体視を実現するために、複数のプレーンメモリ（複数のグラフィクスプレーンおよび複数のビデオプレーン）を確保する必要があるか否かを示すので、プレーンメモリの追加が必要ではないコンテンツの再生時にあたっては、確保すべきグラフィクスプレーン、ビデオプレーンのそれぞれに対応するプレーンメモリの規模が一つに戻る（つまり、基本ビデオプレーン、基本グラフィクスプレーンをそれぞれ確保すればよい）ことになる。平面視のコンテンツを含んだタイトルをカレントタイトルとした再生から立体視のコンテンツを含んだタイトルをカレントタイトルに切り替えて再生したとき、立体視コンテンツのために、プレーンメモリを追加したとしても、その後、立体視のコンテンツを含んだタイトルをカレントタイトルとした再生から再度平面視のコンテンツを含んだタイトルをカレントタイトルに切り替えて再生したとき、その追加のプレーンメモリが確保されたままになって、メモリにおける空き容量が圧迫を受けることはない。そのため、アプリケーションの動作を安定させることができる。多くのコンテンツのうち、唯一つだけが立体視再生を実現し、その他は平面視再生しか実現しえないようなBD-ROMを再生対象にする場合、立体視コンテンツの再生後に、即座に、立体視のための複数のプレーンメモリを解放することができる。

(第２実施形態)
本実施形態は、アニメーションを実現するAPIを、ミドルウェアに設ける改良に関する。かかるAPIは、フレーム精度アニメーション実行部によってBD-Jアプリケーションに提供される。

図３８は、フレーム精度アニメーション実行部８０を示す図である。

フレーム精度アニメーション実行部８０は、カレントタイトルが切り替わった際、BD-Jオブジェクト内のGUI管理テーブルにおけるコンフィグレーション情報を取り込み、このコンフィグレーション情報に示される座標系をアニメーション描画の基準とする。そしてフレーム精度アニメーション実行部は、アニメーションデータを格納したファイルを指定するファイルパスと、アニメーションにおける表示レートとを表示比率とした機能呼び出しがなされれば、アニメーションデータに含まれる個々のグラフィクスを、指定された表示レートで再生して、動画像と合成する。この際、拡張グラフィクスプレーンへの書き込みにあたっては、視差を考慮して、グラフィクスの書き込み位置をずらしつつも、アニメーションデータを基本グラフィクスプレーン、拡張グラフィクスプレーンに書き込む。

APIの呼び出しがなされれば、基本グラフィクスプレーン及び拡張グラフィクスプレーンにおけるそれぞれのグラフィクスの書き込み座標をずらしつつ、グラフィクスの書き込みを行うので、グラフィクスの立体視が可能になる。

本実施形態によれば、書き込み位置の調整をフレーム精度アニメーション実行部に行わせるので、BD-Jアプリケーションの処理負荷を軽減することができる。

(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

（解像度及び表示方式フラグの表現）
BD-JオブジェクトにおけるGUI管理テーブルは、解像度コード及び表示方式フラグを一体の解像度コードとして表現するのが望ましい。例えば、HD画質の1920×1080という規模のプレーンメモリを、立体視再生のために確保しようとする場合は、HD3D_1920×1080という解像度コードをGUI管理テーブルに記載する。HD画質の1280×1080という規模のプレーンメモリを、立体視再生のために確保しようとする場合は、HD3D_1280×1080という解像度コードをGUI管理テーブルに記載する。このような表記で、解像度及び表示方式フラグが記載されている場合、再生装置は、同じ解像度のプレーンメモリを、立体視再生のためにメモリデバイス上に確保するのが望ましい。

(記録装置としての実施)
再生装置１０２は、ビルドインメディアドライブ、リムーバブルメディアを含むローカルストレージを具備していて、これらへの書き込みを想定した構成になっているので、本願明細書に記載された再生装置は、記録装置としての機能を兼備しているといえる。再生装置１０２が記録装置として機能する場合、以下の2つの態様によって、管理オブジェクトの書き込みを実行する。

i)再生装置１０２が仮想パッケージを再生する機能をもつ場合、管理オブジェクトであるBD-Jオブジェクトの書き込みを以下のように行う。つまり、BD-ROMが装填された際、アプリケーションからの要求に従い、前記BD-ROMに対応する追加コンテンツを、ネットワークを介して、WWWサーバから取得する。取得された追加コンテンツはGUI管理テーブルが記述されてあるBD-Jオブジェクトを含む。再生装置１０２において、記録制御を行う制御部は、前記アプリケーションからの要求に従い、取得した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(TM)アプリケーション)
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(TM)プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-J Extensionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java(TM) 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は、コンテンツの所在に拘らず、シームレス再生を実現する。

(プレーンコントローラの制御内容)
メモリデバイスがSDRAMによって構成される場合、プレーンコントローラの処理としては、SDRAMをアクセスするための特有の制御が必要になる。

SDRAMは、時分割でアドレスピンに出力されたROWアドレスをメモリアレイに出力するROWアドレスデコーダ、時分割でアドレスピンに出力されるたCOLUMNアドレスをメモリアレイに出力するCOLUMNアドレスデコーダ、メモリアレイから読み出された一ページ長のデータを保持してデータピンに出力するページデータバッファ、バースト読み出しすべきワード長をページデータバッファに指示するワード長レジスタとを有する。SDRAMは、記憶素子に、コンデンサを採用しているので、自然放電が発生する。そのため、SDRAMでは、各記憶素子に対して、リフレッシュを行う必要があり、そのリフレッシュのための付加回路が必要になる。

SDRAMにピクチャが格納されでいる場合、プレーンコントローラは、RAS,CAS,WE,CS,CKEの状態の組合せにてコマンドを形成し、これとアドレスの組合せによって、読み出し／書き込みを実行する。例えば、バースト転送モードを利用する場合、活性化コマンドを発行すると共に、SDRAMのアドレスピンにROWアドレスを発行する。発行から一定時間のディレイを行った上でREADコマンドを発行すると共に、アドレスピンにCOLUMNアドレスを発行する。

(プログラミング言語の適用範囲)
上記実施形態では、仮想マシンのプログラミング言語としてJava（TM）を利用したが、Java（TM）ではなく、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などの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。

また、記録媒体は光ディスク以外にも例えば、ＳＤメモリーカードなどのリムーバブルメディア（半導体メモリカード）であっても本発明の実施は可能である。

BD-ROMでは例えば、図３０に示すBD-ROMドライブ109を介してリードバッファ１、リードバッファ２へデータ、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３に転送されるように構成していたのに対し、BD-ROMの代わりに半導体メモリを用いた場合には、半導体メモリーカード内のデータを読み出すためのインターフェイス（メモリーカードＩ／Ｆ）を介してリードバッファ１、リードバッファ２へデータ、ヒープメモリ３１、動的シナリオメモリ３０、静的シナリオメモリ１３に転送されるように構成すればよい。

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

ＢＤ−ＲＯＭに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。

例えば、ＢＤ−ＲＯＭに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。

以後、ＢＤ−ＲＯＭに記録されたデータのうち、暗号化されているデータの解読について説明をする。

再生装置においては、ＢＤ−ＲＯＭ内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。

一方、ＢＤ−ＲＯＭには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するＭＫＢ（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びＭＫＢに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、ＭＫＢ、及び暗号化タイトルキーは対になっており、さらにＢＤ−ＲＯＭ上の通常コピーできない領域（ＢＣＡと呼ばれる領域）に書き込まれた識別子（例えばボリュームＩＤ）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、ＭＫＢ及びボリュームＩＤを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。

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

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

本実施の形態では記録媒体としてＢＤ−ＲＯＭを例に説明をしたが、ＢＤ−ＲＯＭに必ずしも限定されるのではなく、例えば、読込み／書込み可能な半導体メモリー（例えばＳＤカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。

例えば、ＢＤ−ＲＯＭに記録されるデータに相応するデータを例えば電子配信を利用して半導体メモリーカードに記録して、半導体メモリーカードから再生をするような構成としても良い。電子配信を利用して必要なデータを配信し、配信されたデータを記録する場合においても、配信されたデータのうちの一部または全てのデータに対して必要に応じて暗号化を行なって配信し、半導体メモリーに必要なデータについては暗号化がなされたままで記録するのが望ましい。

例えば電子配信を利用して、本実施の形態で説明をしたデータに相応するデータ（配信データ）を半導体メモリーに記録する動作について説明をする。

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

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

この、ＳＤメモリーカードを一意に識別するための識別情報は例えば上述のボリュームＩＤに相当する。

一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。

例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。

また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。

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

次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。

次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。

受信した公開鍵情報は例えば公開鍵本体（例えば上述のＭＫＢ及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。

署名情報には例えば、公開鍵情報のハッシュ値を含む。

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

半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。

まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。

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

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

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

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

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

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

従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。

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

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

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

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

また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。

（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。

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

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

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。

(システムLSIの単体実施)
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。

ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステム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の内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。

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

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

開発したチップと開発したチップに関連するミドルウェアとの間のインターフェイス部分について、共通にすると、汎用性が高くなる。

なお、システムＬＳＩにて構成をした部分に関しては、ＬＳＩでしか構成ができないというものではなく、システムＬＳＩに含まれるべき機能に対応する信号処理回路を用いて構成をしても良いことは言うまでもない。

本発明に係る、平面表示と立体表示を動的に切り換え可能にする記録媒体、その再生装置および再生方法は、殊に、AVコンテンツの制作に携わる映画産業、および、それを処理する機器の製造に携わる民生機器産業において利用される可能性が高い。例えば、BD-ROMディスク、および、BD-ROMプレーヤ等として利用可能である。

１ リードバッファ
２ リードバッファ
６ デマルチプレクサ
７a,b ビデオデコーダ
８a,b ビデオプレーン
９ オーディオデコーダ
１０ HDMIインターフェイス
１２ 再生状態／設定レジスタセット
１３ 静的シナリオメモリ
１４ 再生制御エンジン
１５ 基本グラフィクスプレーン
１６ 拡張グラフィクスプレーン
１７ プレーンコントローラ
１８a,b 色変換部
１９a,b 合成器
２１ MPU
２２ ROM
３０ 動的シナリオメモリ
３１ ヒープメモリ
１０１ BD-ROM
１０２ 再生装置
１０３ テレビ
１０４ ゴーグル
１０５ フロントエンド部
１０６ システムLSI
１０７ メモリデバイス
１０８ バックエンド部
１０９ BD-ROMドライブ
１１０ ローカルストレージ

Claims (12)

1. 映像データと、管理オブジェクトと、アプリケーションを含む複数のコンテンツが記録されている記録媒体であって、
   前記コンテンツに含まれる映像データには、平面視映像を構成するものと、立体視映像を構成するものとがあり、
   前記複数のコンテンツのそれぞれに含まれる管理オブジェクトは、アプリケーション管理テーブルと、コンフィグレーション情報とを含み、
   前記アプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションを再生装置に指示する情報を含み、
   前記コンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを前記再生装置が備えるメモリデバイス上に確保するよう前記再生装置に指示する情報およびフラグを含み、
   前記フラグは、グラフィクスの立体視を実現するために、複数のグラフィクスプレーンを前記メモリデバイス上に確保する必要があるか否かを示す
   ことを特徴とする記録媒体。
   
2. 前記コンテンツに含まれる映像データはビデオストリームであり、前記コンテンツは更にタイトル番号にて管理され、前記ビデオストリームの再生順序を規定するプレイリスト情報を含み、
   前記記録媒体には、コンテンツに対応するタイトル番号と、各タイトル番号に対応する管理オブジェクトとの対応付けを示すインデックステーブルが更に記録されており、
   前記アプリケーション管理テーブルによるアプリケーションの起動指示は、管理オブジェクトに対応付けてられているタイトル番号が、カレントタイトルのタイトル番号として前記再生装置により選択された際になされる
   ことを特徴とする請求項１記載の記録媒体。
   
3. 前記コンテンツのうち平面視映像を実現するものは、平面視映像を構成する映像データを含み、
   前記コンテンツのうち立体視映像を実現するものは、ライトビュー動画像、及び、レフトビュー動画像を構成する複数の映像データを含む
   ことを特徴とする請求項１記載の記録媒体。
   
4. 前記確保すべきグラフィクスプレーンの規模は、解像度コードによって表現され、解像度コードは、グラフィクスプレーンが格納すべきグラフィクスの縦画素数及び横画素数を示し、
   前記表示方式フラグが複数のグラフィクスプレーンの確保が必要である旨を示す場合、コンフィグレーション情報は、2つ目のグラフィクスプレーンのための解像度コードを含む
   ことを特徴とする請求項１記載の記録媒体。
   
5. 再生装置であって、
   メモリデバイスと、
   記録媒体に記録された複数のコンテンツの中からいずれかのコンテンツを読み出す読出手段と、
   前記読み出したコンテンツを再生する再生手段と、
   複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに含まれる管理オブジェクト内のアプリケーション管理テーブルに従ってアプリケーションを起動して実行する実行手段と、
   前記起動して実行されるアプリケーションがグラフィクスの描画を行うためのグラフィクスプレーンを管理オブジェクト内のコンフィグレーション情報に従って、前記メモリデバイス上に確保する制御手段とを備え、
   前記管理オブジェクト内のアプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションを再生装置に指示する情報を含み、
   前記管理オブジェクト内のコンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを確保するよう再生装置に指示する情報およびフラグを含み、
   前記制御手段は、前記フラグに従い、グラフィクスの立体視を実現するための複数のグラフィクスプレーンを前記メモリデバイス上に確保する
   ことを特徴とする再生装置。
   
6. 前記コンテンツに含まれる映像データはビデオストリームであり、前記コンテンツは更にタイトル番号にて管理、前記ビデオストリームの再生順序を規定するプレイリスト情報を含み、
   前記記録媒体には、コンテンツに対応するタイトル番号と、各タイトル番号に対応する管理オブジェクトとの対応付けを示すインデックステーブルが更に記録されており、
   前記実行手段は、管理オブジェクトに対応付けてられているタイトル番号が、カレントタイトルのタイトル番号として前記再生装置により選択された際、アプリケーション管理テーブルに記載されたアプリケーションをヒープメモリにロードするクラスローダを含む
   ことを特徴とする請求項５記載の再生装置。
   
7. 前記複数のグラフィクスプレーンは、ライトビュー用のグラフィクスプレーン、レフトビュー用のグラフィクスプレーンであり、
   前記アプリケーションは、
   ライトビュー用のグラフィクスプレーン、レフトビュー用のグラフィクスプレーンのそれぞれに、ライトビュー用のグラフィクス及びレフトビュー用のグラフィクスを書き込み、
   ライトビュー用のグラフィクスプレーンにおいてライトビュー用のグラフィクスが書き込まれる位置と、レフトビュー用のグラフィクスプレーンにおいてレフトビュー用のグラフィクスが書き込まれる位置とには、両目の視差に応じたオフセットが存在する
   ことを特徴とする請求項５記載の再生装置。
   
8. 前記立体視映像を実現するものは、ライトビュー動画像、及び、レフトビュー動画像を構成する複数の映像データを含み、
   前記読出手段は、複数の映像データのそれぞれを読み出し、
   前記再生装置は、
   読み出された複数の映像データをデコードして、ライトビュー動画像、レフトビュー動画像を得るビデオデコーダと、
   ライトビュー動画像を構成する個々のピクチャデータを格納するライトビュー用のビデオプレーンと、
   レフトビュー動画像を構成する個々のピクチャデータを格納するレフトビュー用のビデオプレーンとを備え、
   前記ライトビューグラフィクスプレーンに書き込まれたグラフィクスは、ライトビュービデオプレーンに格納されたピクチャデータと合成され、
   前記レフトビューグラフィクスプレーンに書き込まれたグラフィクスは、レフトビュービデオプレーンに格納されたピクチャデータと合成される
   ことを特徴とする請求項７記載の再生装置。
   
9. 前記確保すべきグラフィクスプレーンの規模は、解像度コードによって表現され、解像度コードは、縦画素数及び横画素数を示し、
   制御手段は、解像度コードに示される規模のグラフィクスプレーンを、メモリデバイス上に確保し、
   前記表示方式フラグが複数のグラフィクスプレーンの確保が必要である旨を示す場合、コンフィグレーション情報は、2つ目のグラフィクスプレーンのための解像度コードを含む
   ことを特徴とする請求項５記載の再生装置。
   
10. 記録媒体に記録された複数のコンテンツの何れかを再生する再生装置に組込むことができる集積回路であって、
    記録媒体から読み出された管理オブジェクトの入力を受け付ける受付手段と、
    複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記コンテンツに含まれる管理オブジェクト内のアプリケーション管理テーブルに従ってアプリケーションを起動して実行する実行手段と、
    前記アプリケーションがグラフィクスの描画を行うためのグラフィクスプレーンを管理オブジェクト内のコンフィグレーション情報に従って、前記再生装置が備えるメモリデバイス上に確保する制御手段とを備え、
    前記管理オブジェクト内のアプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションを前記再生装置に指示する情報を含み、
    前記管理オブジェクト内のコンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを確保するよう前記再生装置に指示する情報およびフラグを含み、
    前記制御手段は、前記フラグに従い、グラフィクスの立体視を実現するための複数のグラフィクスプレーンをメモリデバイス上に確保する
    ことを特徴とする集積回路。
    
11. メモリデバイスを備えたコンピュータ上でコンテンツの再生を行う再生方法であって、
    記録媒体に記録された複数のコンテンツの中からいずれかのコンテンツを読み出す読出ステップと、
    前記読み出したコンテンツを再生する再生ステップと、
    複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに含まれる管理オブジェクト内のアプリケーション管理テーブルに従ってアプリケーションを起動して実行する実行ステップと、
    前記起動して実行されるアプリケーションがグラフィクスの描画を行うためのグラフィクスプレーンを管理オブジェクト内のコンフィグレーション情報に従って、前記コンピュータのメモリデバイス上に確保する制御ステップとを有し、
    前記管理オブジェクト内のアプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションをコンピュータに指示する情報を含み、
    前記管理オブジェクト内のコンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを確保するよう前記コンピュータに指示する情報およびフラグを含み、
    前記制御ステップは、前記フラグに従い、グラフィクスの立体視を実現するための複数のグラフィクスプレーンを前記コンピュータにおけるメモリデバイス上に確保する
    ことを特徴とする再生方法。
    
12. メモリデバイスを備えたコンピュータにコンテンツの再生を行わせるプログラムであって、
    記録媒体に記録された複数のコンテンツの中からいずれかのコンテンツを読み出す読出ステップと、
    前記読み出したコンテンツを再生する再生ステップと、
    複数のコンテンツのうち、特定のコンテンツが再生対象になった際、前記再生対象のコンテンツに含まれる管理オブジェクト内のアプリケーション管理テーブルに従ってアプリケーションを起動して実行する実行ステップと、
    前記起動して実行されるアプリケーションがグラフィクスの描画を行うためのグラフィクスプレーンを管理オブジェクト内のコンフィグレーション情報に従って、前記コンピュータのメモリデバイス上に確保する制御ステップとをコンピュータに実行させ、
    前記管理オブジェクト内のアプリケーション管理テーブルは、前記アプリケーション管理テーブルを含むコンテンツが再生対象になった際、当該再生対象のコンテンツに含まれるアプリケーションのうち、前記再生対象のコンテンツに含まれる映像データの再生とともに、起動すべきアプリケーションをコンピュータに指示する情報を含み、
    前記管理オブジェクト内のコンフィグレーション情報は、前記起動すべきアプリケーションがグラフィクスを描画するにあたって、前記再生される映像データの解像度に対応付けられた規模のグラフィクスプレーンを確保するよう前記コンピュータに指示する情報およびフラグを含み、
    前記制御ステップは、前記フラグに従い、グラフィクスの立体視を実現するための複数のグラフィクスプレーンを前記コンピュータにおけるメモリデバイス上に確保する
    ことを特徴とするプログラム。

Images