"放送またはネットワークを経由してデータを送信する送信装置であって、前記データは、ビデオストリームと、ベースビュー指定情報とを含み、前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、を示すことを特徴とする送信装置。前記データは、テーブル情報を含み、前記テーブル情報は、時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、前記ベースビュー指定情報は、前記テーブル情報に対応付けられていることを特徴とする、請求項1記載の送信装置。前記データは、データ管理情報を含み、前記データ管理情報は、プログラムクロックリファレンスPCR、プログラムマップテーブルPMT、プログラムアソシエーションテーブルPATの何れかであることを特徴とする、請求項1記載の送信装置。放送またはネットワークを経由して送信されたデータを受信する受信装置であって、前記データは、ビデオストリームと、ベースビュー指定情報とを含み、前記ビデオストリームのデコードを行い、非圧縮のピクチャデータを得るデコーダと、前記デコーダによって得られた非圧縮のピクチャデータを出力する出力手段とを備え、前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるかを示し、前記デコーダは、平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、立体視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、且つ前記ディペンデントビュービデオストリームを構成する圧縮ピクチャデータを、前記ベースビュー指定情報により示されるベースビュービデオストリームの非圧縮ピクチャデータを参照してデコードし、前記出力手段は、前記ベースビュー指定情報に従って、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームのいずれかを左目用映像として出力し、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームの他方を右目用映像として出力することを特徴とする受信装置。前記データは、テーブル情報を含み、前記テーブル情報は、時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、前記ベースビュー指定情報は、前記テーブル情報に対応付けられていることを特徴とする、請求項4記載の受信装置。前記データは、データ管理情報を含み、前記データ管理情報は、プログラムクロックリファレンスPCR、プログラムマップテーブルPMT、プログラムアソシエーションテーブルPATの何れかであることを特徴とする、請求項4記載の受信装置。放送またはネットワークを経由してデータを送信する送信方法であって、前記データは、ビデオストリームと、ベースビュー指定情報とを含み、前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、を示すことを特徴とする送信方法。前記データは、テーブル情報を含み、前記テーブル情報は、時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、前記ベースビュー指定情報は、前記テーブル情報に対応付けられていることを特徴とする、請求項7記載の送信方法。前記データは、データ管理情報を含み、前記データ管理情報は、プログラムクロックリファレンスPCR、プログラムマップテーブルPMT、プログラムアソシエーションテーブルPATの何れかであることを特徴とする、請求項7記載の送信方法。放送またはネットワークを経由して送信されたデータを受信する受信方法であって、前記データは、ビデオストリームと、ベースビュー指定情報とを含み、前記ビデオストリームのデコードを行い、非圧縮のピクチャデータを得るデコードステップと、前記デコードステップによって得られた非圧縮のピクチャデータを出力する出力ステップとを備え、前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるかを示し、前記デコードステップは、平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、立体視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、且つ前記ディペンデントビュービデオストリームを構成する圧縮ピクチャデータを、前記ベースビュー指定情報により示されるベースビュービデオストリームの非圧縮ピクチャデータを参照してデコードし、前記出力ステップは、前記ベースビュー指定情報に従って、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームのいずれかを左目用映像として出力し、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームの他方を右目用映像として出力することを特徴とする受信方法。前記データは、テーブル情報を含み、前記テーブル情報は、時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、前記ベースビュー指定情報は、前記テーブル情報に対応付けられていることを特徴とする、請求項10記載の受信方法。前記データは、データ管理情報を含み、前記データ管理情報は、プログラムクロックリファレンスPCR、プログラムマップテーブルPMT、プログラムアソシエーションテーブルPATの何れかであることを特徴とする、請求項10記載の受信方法。立体視再生では、レフトビューのビデオストリーム、ライトビューのビデオストリームを記録媒体に記録して、ユーザに視聴させる必要があるが、これらレフトビュービデオストリーム、ライトビュービデオストリームをどのような形式に変換しておくかが問題になる。一般的な記録形式は、レフトビュービデオストリーム、ライトビュービデオストリームをTSパケットレベルで多重化して、1つのトランスポートストリームとして記録するというものであるが、これでは、レフトビュービデオストリーム、ライトビュービデオストリームに割り当てることができるビットレートが低下してしまう。そのため画質の低下が発生しかねない。本発明の目的は、3D再生装置と、2D再生装置との双方で再生されることを保障することができる送信装置を提供することである。上記課題を解決するため、本発明にかかる送信装置は、放送またはネットワークを経由してデータを送信する送信装置であって、前記データは、ビデオストリームと、ベースビュー指定情報とを含み、前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、を示すことを特徴とする。本発明では、レフトビュービデオストリーム、ライトビュービデオストリームのうち、何れをベースビュービデオストリームにするかをベースビュー指定情報によって設定することができるので、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することができ、複数視点の独立した圧縮に比べて圧縮効率を向上させることができる。図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。一般に右目と、左目は、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。まず、1つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。2つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の2つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。図1aは、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。本図に示すように、記録媒体の一例であるBDROM100、再生装置200は、テレビ300、3D眼鏡400、リモコン500と共にホームシアターシステムを構成し、ユーザによる使用に供される。BDROM100は、上記ホームシアターシステムに、例えば映画作品を供給する。再生装置200は、テレビ300と接続され、BDROM100を再生する。テレビ300は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置300は、3D眼鏡400をユーザが着用することで立体視を実現するものだが、表示装置300がレンチキュラー方式のものなら、3D眼鏡400は不要となる。レンチキュラー方式の表示装置300は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。3D眼鏡400は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。図1bは、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡400は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図cは、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。リモコン500は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン500は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。以上が、記録媒体及び再生装置の使用形態についての説明である。本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図2は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。視差画像のうち、左目に入る画像を左目画像といい、右目に入る画像を右目画像という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。図3は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。本図の第2段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1P2Br3Br4P5Br6Br7P9というピクチャデータが含まれている。これらのピクチャデータは、DecodeTimeStampに従いデコードされる。第1段目は、左目画像を示す。そうしてデコードされたピクチャデータI1P2Br3Br4P5Br6Br7P9をPTSに従い、I1Br3Br4P2Br6Br7P5の順序で再生することで、左目画像が再生されることになる。本図において、参照ピクチャを持たずに符号化対象ピクチャのみを用いてピクチャ内予測符号化を行うピクチャをIピクチャと呼ぶ。ピクチャとは、フレームおよびフィールドの両者を包含する1つの符号化の単位である。また、既に処理済の1枚のピクチャを参照してピクチャ間予測符号化するピクチャをPピクチャとよび、既に処理済みの2枚のピクチャを同時に参照してピクチャ間予測符号化するピクチャをBピクチャと呼び、Bピクチャの中で他のピクチャから参照されるピクチャをBrピクチャと呼ぶ。また、フレーム構造の場合のフレーム、フィールド構造のフィールドを、ここではビデオアクセスユニットと呼ぶ。第4段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1P2B3B4P5B6B7P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第3段目は、右目画像を示す。そうしてデコードされたピクチャデータP1P2B3B4P5B6B7P8をPTSに従い、P1B3B4P2B6B7P5の順序で再生することで、右目画像が再生されることになる。第5段目は、3D眼鏡400の状態をどのように変化させるかを示す。この第5段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。このような視点間の相関特性を利用したビデオ圧縮の方法としては、MultiviewVideoCodingMVCと呼ばれるMPEG4AVCH264の修正規格がある。ISOIECMPEGとITUTVCEGの共同プロジェクトであるJointVideoTeamJVTは、2008年7月にMultiviewVideoCodingMVCと呼ばれるMPEG4AVCH264の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものをベースビュービデオストリームという。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、ディペンデントビューストリームという。次に、記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。図4は、多層化された光ディスクの内部構成を示す。第1段目は、多層化された光ディスクであるBDROMを示し、第2段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域から構成される。これらの第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域は、1つの連続した論理アドレス空間を構成する。ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。この一方、記録層の境界のように、連続的な読み出しが不可能な部分については、論理アドレスが連続していないものとする。ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BDROM100の場合ではUDFUniversalDiscFormatによって記録される。日常使っているPCパーソナルコンピュータの場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。ファイルシステム上でアクセス可能なファイルのうち、ビデオストリーム及びオーディオストリームを多重化することで得られたAVストリームを格納しているファイルをAVファイルという。一方、AVストリーム以外の一般的なデータを格納しているファイルを非AVファイルという。ビデオストリーム、オーディオストリームを始めとするPacktizedElementaryストリームが、TSパケットに変換された上で多重化されているため、AVストリームがトランスポートストリーム形式になっているAVファイルを、トランスポートストリームファイルという。これとは異なり、ビデオストリーム、オーディオストリームを始めとするPESストリームが、パック列に変換された上で多重化されているため、AVストリームがシステムストリーム形式になっているAVファイルを、システムストリームファイルという。BDROM、BDRE、BDRに記録されるAVファイルは、前者のトランスポートストリームファイルである。DVDVideo、DVDRWDVDRDVDRAMに記録されるAVファイルは、後者のシステムストリームファイルであり、VideoObjectとも呼ばれる。第4段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第5段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。図5は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。BDMVディレクトリはBDROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリと呼ばれる5つのサブディレクトリが存在し、BDMVディレクトリには、indexbdmv,MovieObjectbdmvの2種類のファイルが配置されている。indexbdmvは、BDROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BDJオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納している。インデックステーブルはBDROM全体に関する管理情報であり、再生装置へのディスク挿入後に、indexbdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルはBDROMに格納されるすべてのタイトル、トップメニュー、FirstPlayといったタイトル構成を定義する最上位層のテーブルである。インデックテーブルには、一般のタイトル、トップメニュータイトル、FirstPlayタイトルから最初に実行されるプログラムファイルが指定されている。BDROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにインデックステーブルを参照して、所定のプログラムファイルを実行する。ここで、FirstPlayタイトルとは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるプログラムファイルが設定されている。また、トップメニュータイトルは、リモコンでのユーザ操作で、メニューに戻るというようなコマンドが実行されるときに、呼び出されるムービーオブジェクト、BDJオブジェクトが指定されている。立体視に関する情報としてIndexbdmvは、Initial_output_mode情報を有する。このInitial_output_mode情報は、Indexbdmvがロードされた場合に、再生装置の出力モードの初期状態がどうあるべきかを規定する情報であり、制作者サイドが希望する出力モードを、このInitial_output_mode情報に規定しておくことができる。MovieObjectbdmvファイル名固定は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モードにおいて、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。BDJOディレクトリには、拡張子bdjoが付与されたプログラムファイルが存在する。このプログラムファイルは、バイトコードインタプリタであるJava登録商標仮想マシンを制御主体とした動作モードにおいて、再生装置が行うべき制御手順を規定するBDーJオブジェクトを格納している。このBDーJオブジェクトは、アプリケーション管理テーブルを含む。BDJオブジェクト内のアプリケーション管理テーブルは、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。アプリケーション管理テーブルは、BDJオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定するアプリケーション識別子と、制御コードとを含む。アプリケーション管理テーブルにより生存区間が規定されるBDJアプリケーションを、特にBDJアプリケーションという。制御コードは、AutoRunに設定された場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、他のアプリケーションからのコールを待って、起動すべき旨を示す。一方、BDJアプリケーションの中には、タイトルが終了したとしても、その動作が終了しないアプリケーションがある。かかるアプリケーションを、タイトルアンバウンダリアプリケーションという。このJava登録商標アプリケーションの実体にあたるのが、BDMVディレクトリ配下のJARディレクトリに格納されたJava登録商標アーカイブファイルである。アプリケーションは例えばJava登録商標アプリケーションであり、仮想マシンのヒープ領域にロードされた1つ以上のxletプログラムからなる。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。PLAYLISTディレクトリには、拡張子mplsが付与されたプレイリスト情報ファイルが存在する。プレイリストとは、AVストリームの時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、複数のAVストリームのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報ファイルは、かかるプレイリストの型を定義するプレイリスト情報を格納している。再生制御のためのJavaアプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava仮想マシンに命じることで、AV再生を開始させることができる。JMFプレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。CLIPINFディレクトリには、拡張子clpiが付与されたクリップ情報ファイルが存在する。以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。STREAMディレクトリは、トランスポートストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxxm2tsという形式でトランスポートストリームファイルが格納される。STREAMディレクトリにおけるトランスポートストリームファイルは、AVクリップを格納している。AVクリップとは、AVストリームの切れ端のことであり、ビデオストリーム、オーディオストリーム、グラフィクスストリーム等、複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を可能するものをいう。AVクリップは、1秒5秒1分等、長短に拘らず、時間軸上において、ある限られた時間の再生を保障するものであれば足りる。またAVクリップは、複数種別のPESストリームを管理制御するための情報として、欧州デジタル放送規格に規定されたパケット管理情報を具備している。PCRは、ATSの時間軸であるATCArrivalTimeClockとPTSDTSの時間軸であるSTCSystemTimeClockの同期を取るために、そのPCRパケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。PMTは、トランスポートストリームファイル中に含まれる映像音声グラフィクスなどの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、またAVクリップに関する各種ディスクリプタを持つ。ディスクリプタにはトランスポートストリームファイルのコピーを許可不許可を指示するコピーコントロール情報などがある。PMTの先頭には、そのPMTに含まれるデータの長さなどを記したPMTヘッダが配置される。その後ろには、AVクリップに関するディスクリプタが複数配置される。前述したコピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、トランスポートストリームファイルに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのPID、ストリームの属性情報フレームレート、アスペクト比などが記載されたストリームディスクリプタから構成される。ストリームディスクリプタはAVクリップに存在するストリームの数だけ存在する。PATProgramAssociationTableは、AVクリップ中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。これらのPCRPMTPATは、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルトランスポートストリームを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルトランスポートストリームを扱うかの如く、AVクリップをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、BDROM再生装置との互換性を意図したものである。またAVクリップのうち、レフトビュービデオストリームの分割部分を格納したパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したパケット等、レフトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を保障するものを、レフトビューAVクリップという。このレフトビューAVクリップが、ベースビュービデオストリームを含んでおり平面視再生を可能とするものなら、当該レフトビューAVクリップは、2D/レフトビューAVクリップと称呼される。尚以降の説明では、特に断らない限り、レフトビュービデオストリームがベースビュービデオストリームであり、レフトビュービデオストリームを含むレフトビューAVクリップは、2DレフトビューAVクリップであるものとする。更にAVクリップのうち、ライトビュービデオストリームの分割部分を格納したソースパケット、ライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間の連続再生を保障するものを、ライトビューAVクリップという。CLIPINFディレクトリに格納されるクリップ情報ファイルとは、レフトビューAVクリップ又はライトビューAVクリップが、どのようなパケットの集合体であるか等、AVクリップの詳細を、個々のAVクリップ毎に示した情報であり、対応するAVクリップの再生に先立ちメモリに読み出され、そのAVクリップの再生が継続している間、再生装置内で参照に供される情報である。以上が記録媒体の内部構成についての説明である。続いて、図4及び図5に示した記録媒体の作り方、つまり、記録方法の形態について説明する。本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。図6は、記録方法の処理手順を示すフローチャートである。ステップS301は、BDROMのタイトル構造を決定する工程である。これによりタイトル構造情報が作成される。タイトル構造情報とは、木構造を用いて、BDROMにおける再生単位の関係、例えば、タイトル、ムービーオブジェクト、BDJオブジェクト、プレイリスト間の関係を規定する情報である。具体的にいうと、タイトル構造情報は、制作しようとするBDROMのディスク名に対応するノード、そのBDROMにおいて、Indexbdmvから再生可能となるタイトルに対応するノード、そのタイトルを構成するムービーオブジェクト及びBDJオブジェクトに対応するノード、当該ムービーオブジェクト及びBDJオブジェクトから再生されるプレイリストのノードを規定して、これらノードを、エッジで結び付けることで、タイトル、ムービーオブジェクト、BDJオブジェクト、プレイリスト間の関係を規定する。ステップS302は、タイトルに利用する動画、音声、静止画、字幕情報のインポートを行う工程である。ステップS303は、GUIを経由したユーザ操作に従った編集処理をタイトル構造情報に施すことにより、BDROMシナリオデータを作成する工程である。ここでBDROMシナリオデータとは、AVストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、BDROMではインデックステーブル、ムービーオブジェクト、プレイリストとして定義されている情報がシナリオにあたる。BDROMシナリオデータには、ストリームを構成する素材情報、再生区間、再生経路を示す情報、メニュー画面配置、メニューからの遷移情報などを含む。ステップS304は、エンコード工程であり、BDROMシナリオデータに基づきエンコードを行って、PESストリームを得る。ステップS305は、BDROMシナリオデータに従った多重化工程であり、この工程によってPESストリームを多重化してAVクリップを得る。ステップS306では、BDROMへの記録のためのデータベースを得る。ここでのデータベースとは、前述のBDROMで定義されるインデックステーブル、ムービーオブジェクト、プレイリスト、BDJオブジェクトなどの総称である。ステップS307では、Javaプログラム、多重化工程で得られたAVクリップ、BDROMデータベースを入力とし、BDROMに準拠したファイルシステムフォーマットでAVファイル非AVファイルを作成する。ステップS308は、BDROMに記録されるべきデータのうち、非AVファイルの書込工程であり、ステップS309は、AVファイルの書込工程である。ステップS305の多重化工程は、ビデオストリーム、オーディオストリーム、グラフィクスストリームをPESストリームに変換した上、トランスポートストリームに変換する第1変換工程、トランスポートストリームを構成する個々のTSパケットを、ソースパケットに変換する第2変換工程を含み、動画像、音声、グラフィクスを構成するソースパケット列を、多重化するものである。ステップS309のAVファイル書き込み工程は、ソースパケット列をAVファイルのエクステントとして、記録媒体の連続領域に書き込むものである。書き込みの対象となるストリームは、以下の通りである。ビデオストリームビデオストリームは映画のプライマリビデオおよびセカンダリビデオを示す。ここでプライマリビデオとはピクチャインピクチャにおいて親画像として表示される通常の映像を示し、セカンダリビデオとは、ピクチャインピクチャにおいて小画面で表示される映像のことである。プライマリビデオには、レフトビュービデオ、ライトビュービデオの2種類があり、セカンダリビデオにも、レフトビュービデオ、ライトビュービデオの2種類がある。ビデオストリームは、上述したMVCの他、MPEG2、MPEG4AVC、または、SMPTEVC1などの方式を使って符号化記録されている。オーディオストリームオーディオストリームは、映画の主音声部分を示す。オーディオストリームは、ドルビーAC3、DolbyDigitalPlus、MLP、DTS、DTSHD、または、リニアPCMのなどの方式で圧縮符号化記録されている。オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの2種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。PresentationGraphicsストリームPresentationGraphicsストリームは、映画の字幕や、キャラクタ等、ピクチャと緻密に同期すべきグラフィクスを示すグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。PGストリームは、PCS、PDS、WDS、ODSという一連の機能セグメントからなる。ODSは、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。WDSは、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDSは、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCSは、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、CutInOut、FadeInOut、ColorChange、Scroll、WipeInOutといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。グラフィクスストリームの再生において、グラフィクスデコーダは、ある表示単位に属するODSをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行表示単位に属するODSをデコードすることにより得られたグラフィクスオブジェクトをプレーンメモリに書き込む処理とをパイプラインで実行し、ハードウェアをフル駆動することで、上述したような緻密な同期を実現する。トランスポートストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。このPGストリームと、textSTストリームとの組みは、BDROM規格において、PGTextSTストリームと呼ばれる。InteractiveGraphicsストリームInteractiveGraphicsストリームは、リモコンを通じた対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS、PDS、ODSと呼ばれる機能セグメントからなる。ODSは、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDSは、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICSは、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。インタラクティブグラフィックスストリームは、画面上にGUI部品を配置することにより作成される対話画面を示している。図7aは、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目はビデオストリームのビデオフレーム列を示す。第2段目は、PESパケット列を示す。第3段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy1yy2yy3yy4に示すように、ビデオストリームにおける複数のVideoPresentationUnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTSPresentationTimeStampやピクチャの復号時刻であるDTSDecodingTimeStampが格納される。<TSパケット列>図7bは、AVクリップに最終的に書き込まれるTSパケットの形式を示している。第1段目は、TSパケット列を示し、第2段目は、ソースパケット列を示す。第1段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ4ByteのTSヘッダとデータを格納する184ByteのTSペイロードに分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。第2段目によると、TSパケットには、4ByteのTP_Extra_Headerが付与されて、192Byteのソースパケットに変換された状態で、AVクリップに書き込まれる。TP_Extra_HeaderにはATSArrival_Time_Stampなどの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。AVクリップには、第3段目に示すようにソースパケットが並ぶこととなり、AVクリップの先頭からインクリメントする番号はSPNソースパケットナンバーと呼ばれる。<AVクリップにおける多重化>図8は、レフトビューAVクリップがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを、それぞれPESパケット列に変換し、ソースパケット列に変換する。同じくレフトビュープレゼンテーショングラフィックスストリームおよびレフトビューインタラクティブグラフィックスを、それぞれPESパケット列に変換し、更にソースパケット列に変換する。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、レフトビューAVクリップが得られることになる。このレフトビューAVクリップは、リードバッファがアンダーフローしないサイズに定められており、記録媒体への記録の対象になる。ArrivalTimeClock時間軸において、ATSが連続しているソースパケットの集まりをATCシーケンスといい、SystemTimeClock時間軸においてデコードタイムスタンププレゼンテーションタイムスタンプが連続しているソースパケットの集まりを、STCシーケンスという。図9は、記録方法により得られたエクステントを示す。第1段目は、AVファイルを構成するエクステントEXT_LiEXT_Li1EXT_RiEXT_Ri1を示す。第2段目は、各エクステント内に属するソースパケット列を示す。この第1段目におけるエクステントは、ライトビューAVクリップを構成するソースパケットのグループと、レフトビューAVクリップを構成するソースパケットのグループとを、インターリーブ配置したものである。本図におけるインターリーブ配置とは、ライトビューAVクリップを構成するソースパケット集合と、レフトビューAVクリップを構成するソースパケット集合とが、一個のエクステントとして、ライトビュー、レフトビュー、ライトビュー、レフトビューという規則性をもって記録されていることである。ここで、括弧書きにおける変数ii1は、何番目のエクステントとして再生されるかを示す。この記法からすると、変数iによって指示される2つのエクステント、つまり、EXT_LiEXT_Riは同時に再生され、変数i1によって指示される2つのエクステント、つまり、EXT_Li1EXT_Ri1は同時に再生されることがわかる。エクステントEXT_LiのサイズをSEXT_Liと呼び、エクステントEXT_RiのサイズをSEXT_Riと呼ぶ。これらSEXT_L、SEXT_Rのサイズをどのように定めるかについて説明する。ここでのエクステントは、再生装置においてライトビュー用リードバッファ、レフトビュー用リードバッファという2つのバッファに交互に読み出されてビデオデコーダに供される。そうすると、SEXT_L、SEXT_Rのサイズは、ライトビュー用リードバッファ及びレフトビュー用リードバッファをバッファフルにする時間を考慮して定める必要がある。つまり、ライトビュー用リードバッファへの転送レートを、Rmax1とすると、ライトビュー用リードバッファ=Rmax1×ジャンプを伴いながらレフトビュー用リードバッファをフルにする時間という関係を満たすよう、ライトビュー用リードバッファの容量を定めねばならない。ここでジャンプとは、ディスクシークと同義である。何故なら、BDROMにおいて記録に確保できる連続領域は有限であり、レフトビュービデオストリーム及びライトビュービデオストリームは、必ずしも、隣合わせで記録されるとは限らず、飛び飛びの領域に記録されることも有り得るからである。続いてジャンプを伴いながらレフトビュー用リードバッファをフルにする時間について考える。レフトビュー用リードバッファにおけるTSパケット蓄積は、RudRmax2という転送レートでなされる。これは、レフトビュー用リードバッファからの出力レートRmax2と、レフトビュー用リードバッファへの入力レートRudとの差分を意味する。そうすると、レフトビュー用リードバッファをフルにする時間は、RB2となる。レフトビュー用リードバッファにデータを読み出すにあたっては、ライトビューAVクリップからレフトビューAVクリップへのジャンプ時間と、レフトビューAVクリップからライトビューAVクリップへのジャンプ時間とを考慮する必要があるので、レフトビュー用リードバッファの蓄積には2×TjumpRB2という時間が必要になる。ライトビュー用リードバッファの転送レートをRmax1とすると、上述したレフトビュー用リードバッファの蓄積時間において、Rmax1という転送レートで、ライトビュー用リードバッファ内の全てのソースパケットは出力されねばならないから、ライトビュー用リードバッファのサイズRB1は、RB1≧Rmax1×2×TjumpRB2になる。同様の手順で、レフトビュー用リードバッファの容量RB2を求めると、RB2≧Rmax2×2×TjumpRB1になる。ライトビュー用リードバッファレフトビュー用リードバッファのメモリサイズの具体的な値としては、15Mbyte以下であり、本実施形態においてエクステントサイズSEXT_R、SEXT_Lは、このライトビュー用リードバッファレフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。以上がレフトビューAVクリップ、ライトビューAVクリップの記録のされ方についての説明である。続いて、レフトビューAVクリップ及びライトビューAVクリップの内部構成について説明する。図9の第1段目を参照しながら、エクステントEXT_Ri、エクステントEXT_Liの内部構成について説明する。エクステントEXT_Liは、以下のソースパケットによって構成されている。0x0100のパケットIDを有するソースパケットはProgramMapを構成し、0x1001のパケットIDをを有するTSパケットはPCRを構成する。0x1011のパケットIDを有するソースパケットはレフトビュービデオストリーム、0x1220~123FのパケットIDを有するソースパケットはレフトビューPGストリーム、0x1420~143FのパケットIDを有するソースパケットはレフトビューIGストリーム0x1100から0x111FまでのPIDを有するソースパケットはオーディオストリームを構成する。エクステントEXT_Riは、以下のソースパケットによって構成されている。Ox1012のTSパケットはライトビュービデオストリームを構成し、Ox1240~125FのソースパケットはライトビューPGストリームを構成し、Ox1440~145FのソースパケットはライトビューIGストリームを構成する。ボリューム領域におけるエクステントの位置付けエクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、ファイルセット記述子が記録された領域、終端記述子が記録された領域、ROOTディレクトリ領域、BDMVディレクトリ領域、JARディレクトリ領域、BDJOディレクトリ領域、PLAYLISTディレクトリ領域、CLIPINFディレクトリ領域、STREAMディレクトリ領域から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。ファイルセット記述子は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号LBNを含む。終端記述子は、ファイルセット記述子の終端を示す。次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、ディレクトリ領域は、ファイルエントリと、ディレクトリファイルと、下位ファイルについてのファイル記録領域とから構成される。ファイルエントリは、記述子タグと、ICBタグと、アロケーション記述子とを含む。記述子タグは、自身がファイルエントリである旨を示すタグである。ICBタグは、ファイルエントリ自身に関する属性情報を示す。アロケーション記述子は、ディレクトリファイルの記録位置を示す論理ブロック番号LBNを含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。ディレクトリファイルは、下位ディレクトリについてのファイル識別記述子と、下位ファイルのファイル識別記述子とを含む。下位ディレクトリのファイル識別記述子は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。下位ファイルのファイル識別記述子は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。下位ファイルのファイル記録領域とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについてのファイルエントリと、1つ以上のエクステントとが記録されている。ファイルエントリは、記述子タグと、ICBタグと、アロケーション記述子とを含む。記述子タグは、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す261が記述される。ICBタグは、ファイルエントリ自身に関する属性情報を示す。アロケーション記述子は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号LBNを含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位2ビットは、0に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、1に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。0に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。上述したようなファイルエントリーのアロケーション識別子を参照することで、プレイリスト情報ファイル、クリップ情報ファイル、トランスポートストリームファイル、BDJオブジェクトファイル、JARアーカイブファイルを構成するエクステントのアドレスを知得することができる。本願の主眼となるトランスポートストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。上述したようなAVストリーム、Indexbdmv、JARファイル、BDJオブジェクトは、ファイル構造、ディレクトリ構造に従ってBDROMに記録されているので、再生装置は、ファイルオープンのためのシステムコールを行うことで、これらをメモリに読み出すことができる。ファイルオープンとは、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCBを確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。そして、このファイルオープンにあたって、拡張子がm2tsのトランスポートストリームファイルは、STREAMディレクトリを用いたファイルパスによって特定される。拡張子がssifのトランスポートストリームファイルは、STEAMディレクトリと、SSIFディレクトリとを用いたファイルパスによって特定されることになる。これらは、STEAMディレクトリ、SSIFディレクトリに配置されているからである。上述したようなファイル構造において、図9に示したエクステントがどのように取り扱われているかについて説明する。図10は、エクステントと、トランスポートストリームファイルとの対応付けを示す図である。第1段目は、通常のトランスポートストリーム形式のトランスポートストリームファイルである00001m2ts00002m2tsを示し、第2段目は、ライトビューのエクステント、レフトビューのエクステントを示す。第3段目は、インターリーブ形式のトランスポートストリームファイルである00001ssifを示す。破線の矢印h1h2h3h4は、エクステントEXT_RiEXT_Liが、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1h2に示される帰属関係によると、エクステントEXT_LiEXT_Li1は、00001m2tsのエクステントとして登録されていることがわかる。矢印h3h4に示される帰属関係によると、エクステントEXT_RiEXT_Ri1は、00002m2tsのエクステントとして登録されていることがわかる。矢印h5h6h7h8に示される帰属関係によると、エクステントEXT_RiEXT_LiEXT_Ri1EXT_Li1は、00001ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT_LiEXT_Li1は、00001ssifに帰属すると同時に、00001m2tsに帰属するという二重性を有していることがわかる。このssifという拡張子は、StereoScopicInterleaveFileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。図11は、対応するレフトビューAVクリップと、ライトビューAVクリップとをカップリングする方法について示している。同図は、トランスポートストリームファイルが、どのようなエクステントによって構成されているかを示す。これらのうち、エクステントEXT_LiEXT_Li1は、2D映像として再生されるものである。3D映像を含むBDROMであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2DのAVクリップにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。1つ目の方法は、レフトビューは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のトランスポートストリームファイルは拡張子を変える方法である。同図左下における00001m2ts、及び、00001ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名00001によってカップリングされている。プレイリストはレフトビューのAVクリップしか参照しないため、既存の2D再生装置では2D用のAVクリップしか再生しない。3D対応の再生装置は、プレイリストはレフトビューの入ったAVクリップしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のトランスポートストリームファイルであると判断して、レフトビューとライトビューとを出力する。2つ目の方法は、フォルダを分ける方法である。レフトビューは既存のフォルダ名例:STREAMを持つフォルダ内に格納しておくが、拡張であるライトビューは、3D特有の名前を持つフォルダ例:SSIFに同じファイル名00001で格納しておく。プレイリストがファイルを参照する際、2D再生装置ではSTREAMフォルダ内のファイルのみを参照するが、3D再生装置の場合はSTREAMとSSIFフォルダの中から、同じ名前のファイルを同時に参照することにより、レフトビューとライトビューを関連づけることが可能となる。3つ目の方法は、識別番号によるものである。レフトビューの識別番号が00001である場合、ライトビューの識別番号は、このレフトビューの識別番号に1を加算した番号、つまり、0002という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。この例ではレフトビューの識別番号に1を加算したものをライトビューの識別番号としたが、レフトビューの識別番号に、10000を加算したものをライトビューの識別番号として採用してもよい。この例では、既存の2D再生装置が再生する映像はレフトビューであるとして記載しているが、実際はどちらでもよく、また、プレイリスト内にどちらの映像が規定映像として再生されているか識別するための情報があってもよい。カップリング方式を実現する場合には、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。以上がAVクリップを格納したトランスポートストリームファイルについての説明である。続いて、上述したようなトランスポートストリームファイルをどのようにして記録媒体に記録するか、つまり、AVファイルをAVデータ領域に書き込むための工程AVファイル書込工程の詳細について説明する。図12は、AVファイル書込工程の処理手順を示すフローチャートである。ステップS401において、xxxxxssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップS402は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップS403~ステップS408を実行する。確保し得ない場合は、ステップS409で例外処理をした後、記録方法を終了する。ステップS403~ステップS408は、ステップS407がNoと判定されるまで、ステップS403~ステップS406、ステップS408の処理を繰り返すループを構成している。ステップS403において、空きの連続セクタ領域にレフトビューAVクリップを構成するソースパケット列をSEXT_Liだけ書き込み、ステップS404において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。ステップS405において、空きの連続セクタ領域にライトビューAVクリップを構成するソースパケット列をSEXT_Riだけ書き込み、ステップS406において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。ステップS407は、ループの終了条件を規定するものであり、ライトビューAVクリップ、レフトビューAVクリップに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップS408に移行して、ループを継続する。存在しなければ、ステップS410に移行する。ステップS408は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップS403に移行し、存在しなければ、ステップS402まで戻る。ステップS410では、xxxxxssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップS411では、xxxxxm2tsをクリエイトして、メモリにxxxxxm2tsのファイルエントリーを生成する。ステップS412では、レフトビューAVクリップ、ライトビューAVクリップのうち、ベースビュービデオストリームを含むもののエクステントの先頭アドレス及び連続長を示すアロケーション記述子をxxxxxm2tsのファイルエントリーに追記する。ステップS412では、xxxxxm2tsをクローズして、ファイルエントリーを書き込む。以上がAVファイル書込工程についての説明である。続いてクリップ情報ファイルについて説明する。<クリップ情報ファイル>図13は、クリップ情報ファイルの内部構成を示す図である。クリップ情報ファイルは、本図に示すようにAVクリップの管理情報であり、AVクリップと1対1に対応している。引き出し線ch1は、クリップ情報ファイルの内部構成をクローズアップして示している。この引出線に示すように、クリップ情報ファイルは、クリップ情報と、ストリーム属性情報と、エントリマップテーブルと、3Dメタデータとから構成される。クリップ情報は、引出線ch2に示すようにシステムレート、再生開始時間、再生終了時刻から構成されている。システムレートはAVクリップを構成するTSパケットを、後述するシステムターゲットデコーダのPIDフィルタに転送するための最大転送レートを示す。AVクリップ中に含まれるATSの間隔はシステムレート以下になるように設定されている。再生開始時間はAVクリップの先頭のビデオフレームのPTSであり、再生終了時間はAVクリップの終端のビデオフレームのPTSに1フレーム分の再生間隔を足したものが設定される。図14は、クリップ情報ファイルにおけるストリーム属性情報を示す図である。図中の引き出し線ah1は、ストリーム属性情報の内部構成をクローズアップして示している。この引出線に示すように、PID=0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性情報、PID=0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性情報、PID=0x1100、PID=0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性情報、PID0x12200x1221のTSパケットによって構成されるPGストリームのストリーム属性情報というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性情報に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。図15は、クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。本図aは、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、エントリマップヘッダ情報、エクステント開始タイプ、PID=0x1011についてのエントリーマップ、PID=0x1012についてのエントリーマップ、PID=0x1220についてのエントリーマップ、PID=0x1221についてのエントリーマップを含む。エントリマップヘッダ情報は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。エクステント開始タイプは、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。PID=0x1011についてのエントリーマップ、PID=0x1012についてのエントリーマップ、PID=0x1220についてのエントリーマップ、PID=0x1221についてのエントリーマップは、複数種別のソースパケットによって構成されるPESストリームのそれぞれについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報をエントリポイントと呼ぶ。また先頭を0として各エントリポイント毎にインクリメントした値をエントリポイントID以下EP_IDと呼ぶ。このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するソースパケット位置を特定することが出来るようになる。例えば、早送り巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。また、エントリマップはAVクリップ内に多重化される各ビデオストリーム毎に作られ、PIDで管理される。引き出し線eh2は、PID=1011のエントリーマップの内部構成をクローズアップして示している。EP_ID0に対応するエントリーポイント、EP_ID1に対応するエントリーポイント、EP_ID2に対応するエントリーポイント、EP_ID3に対応するエントリーポイントから構成される。EP_ID0に対応するエントリーポイントは、オンに設定されたis_angle_changeフラグと、SPN3と、PTS80000との対応付けを示す。EP_ID1に対応するエントリーポイントは、オフに設定されたis_angle_changeフラグと、SPN1500と、PTS270000との対応付けを示す。EP_ID2に対応するエントリーポイントは、オフに設定されたis_angle_changeフラグと、SPN3200と、PTS360000との対応付けを示す。EP_ID3に対応するエントリーポイントは、オフに設定されたis_angle_changeフラグと、SPN4800と、PTS450000との対応付けを示す。is_angle_changeフラグは、そのエントリーポイントから独立して復号することができるか否かを示すフラグである。ビデオストリームがMVC又はMPEG4AVCで符号化されており、エントリーポイントにIDRピクチャが存在する場合、このフラグはオンに設定される。エントリーポイントにNonIDRピクチャが存在する場合、このフラグはオフに設定される。同図bは、aに示したPID1011のTSパケットに対応するエントリーポイント内の複数のエントリーポイントによって、どのソースパケットを指示されるかを示す。EP_ID0に対応するエントリーポイントは、SPN3を指し示しており、このソースパケット番号をPTS80000と対応付けている。EP_ID1に対応するエントリーポイントは、SPN1500を指し示しており、このソースパケット番号をPTS270000に対応付けている。EP_ID2に対応するエントリーポイントは、SPN3200のソースパケットを指し示しており、このソースパケット番号をPTS360000に対応付けている。EP_ID3に対応するエントリーポイントは、SPN4800のソースパケットを指し示しおり、このソースパケット番号をPTS450000と対応付けている。図16は、エントリーマップによるエントリーポイントの登録を示す。第1段目は、STCシーケンスにて規定される時間軸を示す。第2段目は、クリップ情報におけるエントリーマップを示す。第3段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうちSPN=n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTSt1に設定しておく。そうすると、PTSt1という時点を用いて、ATCシーケンスにおける=n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち=n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTSt21に設定しておく。そうすると、PTSt21という時点を用いて、ATCシーケンスにおける=n21からのランダムアクセスを再生装置に実行させることができるこのエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するAVクリップのファイル位置を特定することが出来る。例えば、早送り巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。以上がエントリーマップテーブルについての説明である。続いて、3Dメタデータの詳細について説明する。3Dメタデータとは、立体視再生に必要となる様々な情報を規定したメタデータ群であり、複数のオフセットエントリーを含む。個々のオフセットエントリーは、複数のPID、複数の表示時刻に対応付けられている。そしてあるPIDのPESストリームを再生する際、そのPESストリームの複数の表示時刻において、どれだけのオフセットを用いて、立体視を実現すべきかをPID毎及び表示時刻毎に規定できるようになっている。以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。デコーダや表示プレーンの構成が異なるため、2D再生、3D再生の切り替えをシームレスに行うことは困難である。そのため、シームレスな切り替えが発生する可能性があるプレイアイテム同士において、2Dと3Dの切り替えを行うことは難しい。図17は、2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。混在をなくすことにより、再生装置の再生環境の切り替えを発生させないようにしている。本図のプレイリストは、メインパス、1つ以上のサブパスから構成される。メインパスは、1つ以上のプレイアイテムから構成される。図中の例では、プレイアイテム1、2、3から構成されていることがわかる。サブパスは、メインパスと一緒に再生される一連の再生経路を示し、プレイリストに登録される順にIDが振られる。サブパスIDは、サブパスを識別するために使われる。サブパスには、メインパスの再生に同期して再生される同期型、メインパスの再生に非同期で再生可能な非同期型があり、そのタイプはサブパスタイプに記される。サブプレイアイテムは、1つ以上のサブプレイアイテム情報から構成される。またプレイアイテムは、ストリーム選択テーブルを含む。ストリーム選択テーブルは、プレイアイテム及びサブプレイアイテムにおいて再生が許可されているエレメンタリストリームのストリーム番号を示す情報である。プレイリスト情報、プレイアイテム情報、サブプレイアイテム情報、ストリーム選択テーブルの詳細については、後の実施形態に説明の場を譲る。AVクリップ123は、2D映像として再生されるAVクリップであるとともに、3D映像として再生する時にはレフトビューとして再生されるAVクリップである。AVクリップ456は3D映像として再生する時にはライトビューとして再生されるAVクリップである。2Dプレイリストのメインパスは、レフトビューAVクリップを格納するAVクリップ123を符号rf123に示すように参照している。3Dプレイリストは、レフトビューAVクリップを符号rf4rf5rf6に示すように参照しているプレイアイテムを含むメインパスとともに、ライトビューを参照するためのサブパスが用意されていて、このサブパスが、ライトビューを格納するAVクリップ456を、符号rf789に示すように参照している。このサブパスは、メインパスと時間軸上で同期するように設定される。この構造により、2Dプレイリストと3Dプレイリストで、レフトビューが格納されたAVクリップを共有することができ、3Dプレイリストではレフトビューとライトビューを時間軸上で同期させて関連付けることができる。本図の3Dプレイリスト、2Dプレイリストは何れもプレイアイテム情報1~3が、共通のAVクリップであるAVクリップ1~3を参照しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。図18は、図17の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図17のプレイリストは、サブパスID0のサブパスのみを具備していたのに対して、図18のプレイリストにおける2つ目のサブパスは、サブパスID1によって識別されるものであり、AVクリップ7、8、9を参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、AVクリップ群がその角度の数だけ用意されていて、角度ごとにサブパスを設けている。図18の例では、AVクリップ123とAVクリップ456は共にライトビューを格納しているが、右目から被写体を見る角度が異なる。サブパスIDが0のサブパスはAVクリップ456を符号rf789に示すように参照し、サブパスIDが1のサブパスはAVクリップ789を符号rf10rf11rf12に示すように参照する。表示装置の画面の大きさやユーザからの嗜好に基づいて、レフトビューを格納するメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図18の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。図19は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、メインパス情報、サブパス情報テーブル、エクステンションデータ、マーク情報を含む。先ず始めに、メインパス情報について説明する。引き出し線mp1は、メインパス情報の内部構成をクローズアップして示している。MainPathは、矢印mp1で示すように複数のPlayItem情報1Nから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線mp2によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVクリップの再生区間情報のファイル名を示すClip_Information_file_nameと、AVクリップの符号化方式を示すClip_codec_identifierと、PlayItemがマルチアングルを構成するか否かを示すis_multi_angleと、このPlayItemと、その1つ前のPlayItemとの接続状態を示すconnection_conditionと、このPlayItemが対象としているSTC_Sequenceを一意に示すref_to_STC_id0と、再生区間の始点を示す時間情報In_timeと、再生区間の終点を示す時間情報Out_timeと、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示すUO_mask_tableと、STN_tableと、レフトビュー/ライトビュー識別情報と、multi_clip_entryとから構成される。以降、STN_table、レフトビュー/ライトビュー識別情報、multi_clip_entryについて説明する。STN_tableは、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。このSTN_tableは、2D再生のためのものであり、3D再生のためのSTN_tableは別に存在する。レフトビュー/ライトビュー識別情報は、レフトビュービデオストリーム、ライトビュービデオストリームのうち、どちらかベースビュービデオストリームであるかを指定するベースビュービデオストリーム指定情報であり、0ならばレフトビュービデオストリームが、ベースビュービデオストリームであることを示し、1ならばベースビュービデオストリームがライトビュービデオストリームであることを示す。connection_conditionは、前方プレイアイテムと接続タイプを示している。プレイアイテムのconnection_conditionが1の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレス接続が保証されないことを示す。プレイアイテムのconnection_conditionが5か6の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレスに接続されることが保証される。connection_conditionが5の場合は、プレイアイテム間でSTCの連続性が途切れていても良く、つまり、接続前プレイアイテムのAVクリップ終端のビデオ表示時刻よりも、接続後プレイアイテムのAVクリップ先頭のビデオ表示時刻開始時刻は不連続でよい。ただし、接続前プレイアイテムのAVクリップを後述するシステムターゲットデコーダのPIDフィルタに入力した後に続けて、接続後プレイアイテムのAVクリップをシステムターゲットデコーダのPIDフィルタに入力して再生したときに、システムターゲットデコーダのデコードが破綻しないようにAVクリップを作成する必要がある。また接続前プレイアイテムのAVクリップのオーディオの終端フレームと、接続後プレイアイテムのオーディオの先頭フレームは再生時間軸で重ならなければならないなどの制約条件がある。また、connection_conditionが6の場合は、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップを結合したときに1本のAVクリップとして再生できなければならない。つまり、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップ間でSTCは連続し、またATCも連続する。Multi_clip_entriesは、プレイアイテムでマルチアングル区間を形成する場合、個々のアングル映像を表すAVクリップがどれであるかを特定するための情報である。以上がメインパス情報についての説明である。続いて、サブパス情報テーブルの詳細について説明する。図20は、サブパス情報テーブルの内部構成を示す図である。引き出し線su1は、サブパス情報の内部構成をクローズアップして示している。引出線su1に示すように、サブパス情報テーブルは複数のサブパス情報123mを含む。これらのサブパス情報は、1つのクラス構造体から派生した複数のインスタンスであり、その内部構成は共通のものなる。引き出し線su2は、Subpath情報の共通の内部構成をクローズアップして示している。この引き出し線に示すように、各Subpath情報は、サブパスの類型を示すSubPath_typeと、1つ以上のサブプレイアイテム情報とを含む。引き出し線su3は、SubPlayItemの内部構成をクローズアップして示している。この引出線に示すように、サブプレイアイテム情報は、Clip_information_file_name、Clip_codec_identifier、ref_to_STC_id0、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_id0は、この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で指定されたPlayItemの再生時間軸上に存在する。sync_start_PTS_of_PlayItemは、sync_PlayItem_idで指定されたPlayItemの再生時間軸上において、SubPlayItem_In_timeで指定されたSubPlayItemの始点が、どこに存在するかを45KHzの時間精度で示す。図21は、レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。本図は、図16をベースとして作図されており、このベースとなる図の第2段目の時間軸に、PlayItemのIn_Time及びOut_Timeを描いている。第1段目の時間軸に、SubPlayItemのIn_Time及びOut_Timeを描いている。第3段目から第5段目は、図16の第3段目から第5段目と同一である。レフトビュー、ライトビューのIピクチャは、時間軸において同じ時点になる。以上がプレイリスト情報のデータ構造についての説明である。以上がサブパス情報についての説明である。続いて、エントリーマーク情報の詳細について説明する。エントリマーク情報はプレイアイテムで定義される再生区間内に対して付与することでき、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマークをチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。以上がエントリーマーク情報についての説明である。続いて、エクステンションデータの詳細について説明する。エクステンションデータは、2Dプレイリストとは互換がない、3Dプレイリスト特有の拡張部分であり、ここにSTN_table_SS1~Nが格納される。STN_table_SSは、それぞれが複数のプレイアイテム情報のそれぞれに対応していて、3D再生用のストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN_table_SSにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。プレイアイテム情報内のSTN_tableと、エクステンションデータ内のSTN_table_SSとを組合せることで、ストリーム選択テーブルが構成されることになる。続いて、上述したPlayItem情報の内部構成のうち、ストリーム選択テーブルの詳細について説明する。図22aは、ストリーム選択テーブルを示す。ストリーム選択テーブルは、複数のストリームエントリから構成される。このストリームエントリーは、図中の括弧記号}に示すように、STN_table内で定義されるものと、STN_table_SS内で定義されるものとがある。STN_tableのストリームエントリーには、2D出力モードの設定時において、再生可能となる2D用の音声PGIGが登録される。そのため、STN_tableの中には、2Dビデオストリームエントリー群、2Dオーディオストリームエントリー群、2DPGストリームエントリー群、2DIGストリームエントリー群が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。STN_table_SSのストリームエントリーには、立体視再生モードの設定時において、再生可能となる3D用の音声PGIGが登録される。そのため、STN_table_SSの中には、3Dビデオストリームエントリー群、3Dオーディオストリームエントリー群、3DPGストリームエントリー群、3DIGストリームエントリー群、ストリーム組合せ情報が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。同図bは、ストリームエントリーの共通構成を示す図である。本図に示すように、ストリーム選択テーブルにおけるストリームエントリは、ストリーム選択番号、ストリームパス情報、ストリーム識別情報から構成される。ストリーム選択番号は、ストリーム選択テーブルに含まれるストリームエントリ1の先頭から順にインクリメントされる番号であり、再生装置でのストリーム識別のために利用される。ストリームパス情報は、ストリーム識別情報によって示されるストリームが、どのAVクリップに多重化されているかを示す情報であり、例えばメインパスであれば、該当するプレイアイテムのAVクリップを示し、サブパスID1であれば、そのサブパスIDが示すサブパスにおいて、該当するプレイアイテムの再生区間に対応するサブプレイアイテムのAVクリップを示す。ストリーム識別情報は、PIDなどの情報であり、参照するAVクリップに多重化されているストリームを示す。また、ストリームエントリには、各ストリームの属性情報も同時に記録されている。ここで属性情報とは、各ストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。STN_table_SSにおいて、レフトビュービデオストリームのストリームエントリとライトビュービデオストリームのストリームエントリとでは、例えばフレームレートや解像度、ビデオフォーマットなどは同じ値になる。ストリームエントリには、レフトビュービデオストリームなのか、ライトビュービデオストリームなのかが分かるフラグが用意されることがある。以上がストリーム選択テーブルについての説明である。続いて、レフトビュー/ライトビュー識別情報の詳細について説明する。ここまでの記載は、レフトビュー用をメインとし、2D表示の場合はレフトビューが表示されることを前提に説明しているが、ライトビューがメインでもよい。プレイリストに左目ライトビューのどちらがメインであるか、2Dの場合に表示されるかを判別する情報に従い、ベースビュービデオストリームであるものとする。その判別の情報が、レフトビュー/ライトビュー識別情報である。一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すレフトビュー/ライトビュー識別情報をプレイアイテム情報毎に設定できるようにしている。図23は、図17の3Dプレイリストに、レフトビュー/ライトビュー識別情報を書き加えた図である。この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。各ストリームとレフトビューライトビューの識別情報は、表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。以上がレフトビュー/ライトビュー識別情報についての説明である。このレフトビュー/ライトビュー識別情報は、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。しかし視差画像の内容によっては、このように平面視画像として利用することに向いていないことがある。以下、平面視画像として利用することに不向きなレフトビュー画像、ライトビュー画像について説明する。図24は、レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。図中の右下は、映像中の恐竜が、ユーザの目の前にまで迫ってくるような画面効果を狙っている立体視画像を示す。この立体視画像は、その上に記載されているような、L画像、R画像によって構成される。飛び出し効果が大きい立体視画像を構成するL画像、R画像は、飛び出して現れる画像中の対象を、側面から表示するようになっている。これらのうち、レフトビュービデオストリームを、平面視用のビデオストリームとして使用する場合、横長の物体が横たわっているように見えてしまい、おかしなものになる。そこで、2Dモードに設定されている場合、センター画像を表すビデオストリームを指定する、プレイリスト情報をカレントプレイリストとして選ぶようにする。本図において、00005mplsは、飛び出し度合が大きいレフトビュービデオストリーム、及び、ライトビュービデオストリームを、メインパス情報及びサブパス情報として指定している。00003mplsは、センター画像のビデオストリームをメインパスによって指定している。そして本図左上のムービーオブジェクトは、再生装置における3D再生のケーパビリティに応じて、00005mpls、00003mplsのうち、どちらかを選択して再生するよう記述されている。以上が記録媒体の実施行為及び記録方法の実施行為についての説明である。続いて、再生装置の詳細について説明する。図25は、2D3D再生装置の構成を示している。2D3D再生装置は、BDROMドライブ1、リードバッファ2a、リードバッファ2b、スイッチ3、システムターゲットデコーダ4、プレーンメモリセット5a、プレーン合成部5b、HDMI送受信部6、再生制御部7、管理情報メモリ9、レジスタセット10、プログラム実行部11、プログラムメモリ12、HDMVモジュール13、BDJプラットフォーム14、ミドルウェア15、モード管理モジュール16、ユーザイベント処理部17、ローカルストレージ18、不揮発メモリ19から構成されている。BDROMドライブ1は、2D再生装置と同様に再生制御部7からの要求を元にBDROMディスクからデータを読み出すが、BDROMディスクから読み出されたAVクリップはリードバッファ2aかリードバッファ2bに転送される。3D映像を再生する際には、再生制御部7からは2DレフトビューAVクリップとライトビューAVクリップとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BDROMドライブ1は、2DレフトビューAVクリップを構成するエクステントをリードバッファ2aに読み出し、ライトビューAVクリップを構成するエクステントをリードバッファ2bに読み出す。3D映像を再生する際には、2DレフトビューAVクリップとライトビューAVクリップの両方を同時に読み込む必要があるため、2D再生装置のBDROMドライブ以上のスピード性能が求められる。リードバッファ2aは、BDROMドライブ1が読み込んだ2DレフトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。リードバッファ2bは、BDROMドライブ1が読み込んだライトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。スイッチ3は、リードバッファに対するデータ入力源を、BDROMドライブ1又はローカルストレージ18の何れかに切り替えるためのスイッチである。システムターゲットデコーダ4は、リードバッファ2aに読み出されたソースパケットとリードバッファ2bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。プレーンメモリセット5aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、インタラクティブグラフィックスプレーンIGプレーン、プレゼンテーショングラフィックスプレーンPGプレーンといったものがある。プレーン合成部5bは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンを瞬時に重畳し、TVなどの画面に表示する。この表示にあたってプレーン合成部5bは、セカンダリビデオプレーン、PGプレーン、IGプレーンを3Dメタデータを使って左目用と右目用とに交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンと合成する。合成後の映像は、GFXプレーンの重畳処理に転送される。プレーン合成部5bは、IGプレーンにおけるグラフィクスをAPIから指定されたオフセット情報を使って左目と右目用に交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンとセカンダリビデオプレーンとPGプレーンとIGプレーンとが重畳されたイメージを、テレビに出力する。テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。HDMI送受信部6は、例えばHDMI規格HDMIHighDefinitionMultimediaInterfaceに準拠したインターフェイスを含み、再生装置とHDMI接続する装置この例ではテレビ300とHDMI規格に準拠するように送受信を行うものであり、ビデオに格納されたピクチャデータと、オーディオデコーダ9によってデコードされた非圧縮のオーディオデータとを、HDMI送受信部6を介してテレビ300に伝送する。テレビ300は、例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を保持しており、再生装置からHDMI送受信部6を介して要求があると、テレビ300は要求された必要な情報例えば立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報を再生装置へ返す。このように、HDMI送受信部6を介することで、テレビ300が立体視表示に対応しているかどうかの情報を、テレビ300から取得することができる。再生制御部7は、再生エンジン7a、再生制御エンジン7bを含み、3Dプレイリストの再生がプログラム実行部11などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムの2DレフトビューAVクリップを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのライトビューAVクリップを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点から2DレフトビューAVクリップのエクステントと、ライトビューAVクリップのエクステントとを交互に読み出すようにBDROMドライブ1に要求する。再生開始するときには、最初のエクステントをリードバッファ2aか、リードバッファ2bに読みきった後に、リードバッファ2aとリードバッファ2bからシステムターゲットデコーダ4に転送を開始する。また、再生制御部7は、3Dプレイリストを再生する場合は、2DレフトビューAVクリップに対応するクリップ情報ファイルに含まれる3Dメタデータをプレーン合成部5に通知する。再生エンジン7aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。再生制御エンジン7bは、HDMVモードの動作主体であるコマンドインタプリタ、BDJモードの動作主体であるJava登録商標プラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。管理情報メモリ9は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BDROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BDROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。再生状態/設定レジスタセット10は、プレイリストの再生状態を格納する再生状態レジスタ、再生装置におけるコンフィグレーションを示すコンフィグレーション情報を格納する再生設定レジスタ、コンテンツが利用する任意の情報を格納できる汎用レジスタを含む、レジスタの集まりである。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置時刻を再生しているかなどの状態を現す。プレイリストの再生状態が変化した際は、再生制御エンジン7bがレジスタセット10に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBDJモードの動作主体であるJava登録商標プラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。プログラム実行部11は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。1再生制御部7に対してプレイリスト再生を命令する。2システムターゲットデコーダに対してメニューやゲームのグラフィックスのためのPNGJPEGを転送して画面に表示する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBDJアプリケーションのプログラミング工程によって決まる。プログラムメモリ12は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BDJモードの動作主体であるJava登録商標プラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BDROMに記録されているIndexbdmv、BDJオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。またプログラムメモリ12は、ヒープメモリを含む。ヒープメモリは、システムアプリケーションのバイトコード、BDJアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BDJアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域であるHDMVモジュール13は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVDVideoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVDVideoライクな再生制御を実現することができる。BDJプラットフォーム14は、BDJモードの動作主体であるJava登録商標プラットフォームであり、Java2Micro_EditionPersonalBasisProfileと、GloballyExecutableMHPspecificationforpackagemediatargetsとをフル実装しており、クラスローダ、バイトコードインタプリタ、アプリケーションマネージャから構成される。クラスローダは、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ31に格納することにより、BDJアプリケーションのロードを行う。バイトコードインタプリタは、いわゆるJava登録商標仮想マシンであり、ヒープメモリに格納されているBDJアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。アプリケーションマネージャは、システムアプリケーションの1つであり、BDJオブジェクト内のアプリケーション管理テーブルに基づき、BDJアプリケーションを起動したりBDJアプリケーションを終了したりする等、BDJアプリケーションのアプリケーションシグナリングを行う。以上で、BDJプラットフォーム部の内部構成についての説明を終える。ミドルウェア15は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BDJアプリケーションからのアプリケーションプログラミングインターフェイスのコールに応じて、再生装置特有の機能をBDJアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。モード管理モジュール16は、BDROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndexbdmvを保持して、モード管理及び分岐制御を行う。モード管理モジュールによるモード管理とは、動的シナリオを、BDJプラットフォーム22、HDMVモジュールのどちらに実行させるかという、モジュールの割り当てである。ユーザイベント処理部17は、リモコンを通じたユーザ操作に応答して、プログラム実行部16や再生制御部7に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部16に依頼する。例えば、リモコンで早送り巻戻しボタンが押された場合には、再生制御部7に、現在再生しているプレイリストのAVクリップに対する早送り巻戻し処理の実行を命令する。ローカルストレージ18は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBDROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。不揮発メモリ19は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット10における記憶内容のバックアップに用いられる。次に、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成について説明する。図26は、システムターゲットデコーダ4及びプレーンメモリセット5aの内部構成を示す図である。本図に示すように、システムターゲットデコーダ4及びプレーンメモリセット5aは、ATCカウンタ21、ソースデパケッタイザ22、PIDフィルタ23、STCカウンタ24、ATCカウンタ25、ソースデパケッタイザ26、PIDフィルタ27、プライマリビデオデコーダ31、レフトビュービデオプレーン32、ライトビュービデオプレーン33、セカンダリビデオデコーダ34、セカンダリビデオプレーン35、PGデコーダ36、PGプレーン37、IGデコーダ38、IGプレーン39、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41、ミキサー42、レンダリングエンジン43、GFXプレーン44から構成される。ATCカウンタ21は、ArrivalTimeClockを生成して、再生装置内の動作タイミングを調整する。ソースデパケッタイザ22は、リードバッファ2aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。PIDフィルタ23は、ソースデパケッタイザ22から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダ31、セカンダリビデオデコーダ34、IGデコーダ38、PGデコーダ36、プライマリオーディオデコーダ40、セカンダリオーディオデコーダ41に転送する。STCカウンタ24は、SystemTimeClockを生成し各デコーダの動作タイミングを調整する。ATCカウンタ25は、ArrivalTimeClockを生成して、再生装置内の動作タイミングを調整する。ソースデパケッタイザ26は、リードバッファ2abにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。PIDフィルタ27は、ソースデパケッタイザ26から出力されたTSパケットのうち、TSパケットのPIDが、カレントプレイアイテムのストリーム選択テーブルに記載されたPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダに転送する。プライマリビデオデコーダ31は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン32に書き込む。レフトビュービデオプレーン32は、例えば、1920×2160といった解像度によってピクチャデータを格納することができるプレーンメモリである。ライトビュービデオプレーン33は、例えば、1920×2160といった解像度によってピクチャデータを格納することができるプレーンメモリである。セカンダリビデオデコーダ34は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻PTSのタイミングでピクチャをセカンダリビデオプレーンに書き出す。セカンダリビデオプレーン35は、システムターゲットデコーダ4からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。PGデコーダ36は、ソースデパケタイザから入力される複数のTSパケットからプレゼンテーショングラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスデータを表示時刻PTSのタイミングでPGプレーンに書き出す。PGプレーン37には、プレゼンテーショングラフィックスストリームをデコードすることで得られた非圧縮のグラフィックスオブジェクトが格納される。IGデコーダ38は、ソースパケタイザから入力される複数のTSパケットからインタラクティブグラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスオブジェクトを表示時刻PTSのタイミングでIGプレーンに書き出す。IGプレーン39には、インタラクティブグラフィックスストリームをデコードすることで得られたグラフィックスデータが格納される。プライマリオーディオデコーダ40は、プライマリオーディオストリームをデコードする。セカンダリオーディオデコーダ41は、セカンダリオーディオストリームをデコードする。ミキサー42は、プライマリオーディオデコーダ40のデコード結果と、セカンダリオーディオデコーダ41のデコード結果とを合成する。レンダリングエンジン43は、JPEG,PNGなど、BDJアプリケーションがメニュー描画に利用するグラフィックスデータをデコードする。GFXプレーン44は、JPEG,PNGなどのグラフィックスデータがデコードされた後、書き込まれるプレーンメモリである。次にプライマリビデオデコーダ31の内部構成について説明する。プライマリビデオデコーダ31は、TB51、MB52、EB53、TB54、MB55、EB56、ビデオデコーダ57、バッファスイッチ58、DPB59、ピクチャスイッチ60から構成される。TransportBuffer51は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ23から出力された際、TSパケットのまま一旦蓄積されるバッファである。MultiplexedBuffer52は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。ElementalyBuffer53は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。TransportBuffer54は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。MultiplexedBuffer55は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。ElementalyBuffer56は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。ビデオデコーダ57は、ビデオエレメンタリストリームの個々のビデオアクセスユニットを所定の復号時刻DTSでデコードすることによりフレームフィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG2、MPEG4AVC、VC1などがあるため、ストリームの属性に応じて、ビデオデコーダ57のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ57は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ57は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ57は、デコードされたフレームフィールド画像をDPB59に転送し、表示時刻PTSのタイミングで対応するフレームフィールド画像をピクチャスイッチに転送する。バッファスイッチ58は、ビデオデコーダ57がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB53、EB56のどちらから引き抜くかを決定し、EB53と、EB56とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻DTSのタイミングでビデオデコーダ57に転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ57に転送するのが望ましい。DecodedPIctureBuffer59は、復号されたフレームフィールド画像を一時的に保持しておくバッファである。ビデオデコーダ57が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。ピクチャスイッチ60は、ビデオデコーダ57から転送されたデコード済みのフレームフィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。図27は、プレーン合成部の内部構成を示す図である。3Dメタデータに基づき、プレーンに格納されている非圧縮ピクチャデータ、グラフィクスデータをクロッピングするクロッピング部61abcと、プログラムAPIに基づきプレーンに格納されている非圧縮グラフィクスデータをクロッピングするクロッピング部61dと、出力内容をレフトビュービデオプレーンと、ライトビュービデオプレーンとで切り替えるスイッチ62と、プレーン同士の合成を行う加算部63、64、65、66とから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ4よりPTSのタイミングで映像データが書き出される。プレーン合成部5bは、レフトビュービデオプレーンとライトビュービデオプレーンのうち、PTSのタイミングで映像データが書き出されたほうのプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送される。これらのプレーンメモリのそれぞれは、レフトビューと、ライトビューとでそれぞれ異なる内容が格納されることで立体視の実現が可能になる。しかし、レフトビューにおける格納内容と、ライトビューにおける格納内容とが同じであっても、プレーンメモリにおける画素の座標を、レフトビューと、ライトビューとでそれぞれ変化させれば擬似的な立体視を実現することができる。上述したようなプレーンメモリのうちPGプレーンは、プレーンメモリにおける画素の座標を変化させることで、立体視を実現している。以下、PGプレーンにおける立体視の実現の仕方について説明する。図28は、PGプレーンの合成の仕方を示す図である。プレーン合成の仕方を図28のPGプレーンの例を用いて説明する。プレーン合成部5は、3Dメタデータ内に存在するオフセットエントリーのうち、現在再生されているプレゼンテーショングラフィックスのPIDに対応するものの中から、現在の表示時刻に対応するオフセット値を取得する。そして、プレーン合成部5は、重畳する映像プレーンがレフトビュービデオプレーンの場合はPGプレーンに格納されている画像データの座標をオフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後、他のプレーンとの合成に供する図28上段参照。プレーン合成部5bは、重畳する映像プレーンがライトビュービデオプレーンの場合は、PGプレーンをオフセット値だけX軸の負の方向をずらし、レフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後に重畳する図28下段参照。IGプレーン、セカンダリビデオプレーンも同様に処理を行う。図29は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクロッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。以上がプレーン合成についての説明である。続いて、レジスタセット10の内部構成及び再生制御エンジン7bの詳細について説明する。図30は、レジスタセット10の内部構成及び再生制御エンジン7bの内部構成を示す図である。本図の左側にはレジスタセット10の内部構成を示している。右側には再生制御エンジン7bの内部構成を示している。PSRに格納されているこれらの格納値は、ムービーオブジェクト及びBDJアプリケーションによって適宜参照され、またムービーオブジェクト及びBDJアプリケーションによる更新を受ける。このようにPSRの格納値は、ムービーオブジェクト及びBDJアプリケーションによって参照されるパラメータであるから、システムパラメータとも呼ばれる。始めに、PSRのうち、代表的なものについて説明する。PSR1は、オーディオストリームのためのストリーム番号レジスタであり、カレントのオーディオストリーム番号を格納する。PSR2は、PGストリームのためのストリーム番号レジスタであり、カレントのPGストリーム番号を格納する。PSR4は、1~100の値に設定されることで、カレントのタイトル番号を示す。PSR5は、1~999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。PSR6は、0~999の値に設定されることで、カレントプレイリストの番号を示す。PSR7は、0~255の値に設定されることで、カレントプレイアイテムの番号を示す。PSR8は、0~OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点を示す。以上がPSRについての説明である。PSR10は、IGストリームのためのストリーム番号レジスタであり、カレントのIGストリーム番号を格納する。PSR21は、ユーザが、立体視再生を実行することを意図しているかどうかを示す。PSR22は、出力モード値を示す。PSR23は、DisplayCapabilityforvideoの設定である。これは、再生装置の接続相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。PSR24は、PlayerCapabilityfor3Dの設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。一方、再生制御エンジン7bの内部には、レジスタセット10におけるPSR4PSR6PSR21PSR23PSR24と、管理情報メモリ9におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部8を備えている。PSR24におけるPlayerCapabilityfor3Dは、再生装置の3D再生に関する能力全般を意味するものなので、3DCapabilityと簡単に表記する場合がある。PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図31に示すように規定されている。図31は、出力モードの選択モデルの状態遷移を示す図である。この選択モデルには、2つの一般的な状態が存在する。楕円は、この一般的な状態、つまり、出力モード値がとりうる値であるInvalidvalidを模式的に描いたものである。Invalidは出力モードが無効であり、Validは出力モードが有効である旨を示す。一般的な状態は、状態遷移が起こらない限り、維持される。状態遷移は、プレイリスト再生の開始、ナビゲーションコマンドやBDJアプリケーションにより要求された出力モード変化、BDJタイトルへのジャンプがある。状態遷移が発生した際、好ましい出力モードを獲得するためのプロシージャが実行される。図中の矢印jm1jm2jm3jm12は、状態遷移のトリガとなる事象を模式的に示す。本図における状態遷移には、以下のものがある。Loadadiscとは、BDROMが装填されたという状態を意味する。StartPresentationとは、HDMVモードにおいて、プレイリストの再生開始を意味する。BDJモードにおいては、BDJタイトルへの分岐を意味する。何故なら、BDJモードにおいては、BDJタイトルに分岐した場合、必ずしも、プレイリストの再生が開始されるとは限らないからである。JumptoBDJtitleは、BDJタイトルへの分岐を意味する。具体的には、インデックステーブルにおいて、BDJアプリケーションに対応付けられたタイトルがカレントタイトルになることをいう。StartPlaylistPlaybackは、何等かのプレイリストを意味するプレイリスト番号が、PSRに設定されて、プレイリスト情報が、カレントプレイリスト情報としてメモリに読み出されることをいう。ChangeOutputModeとは、BDJアプリケーションがAPIをコールすることで、出力モードを変化することをいう。Terminatepresentationとは、HDMVモードの場合は、プレイリストの再生が終了することをいい、BDJモードの場合は、BDJタイトルからインデックステーブルにおいてムービーオブジェクトに対応付けられたタイトルへとジャンプすることをいう。ディスクがロードされた際、出力モードの状態は、一時的な状態Initializationに遷移る。出力モードセレクションの状態は、一時的にInitializationstateに遷移した後、invalidstateに遷移する。OutputModeSelectionの状態は、再生開始がアクティブになるまで、Invalidに維持される。HDMVモードにおいてStartPresentationは、プレイリストの再生が開始されたことを意味する。BDJモードにおいてStartPresentationは、BDJタイトルの再生が開始され、BDJアプリケーションが何等かの動作を開始したことを意味する。必ずしも、プレイリストの再生が開始されたことを意味するとは限らない。StartPresentationがアクティブになった際、出力モードは、一時的な状態であるProcedurewhenplaybackconditionischangedに遷移する。出力モードは、Procedurewhenplaybackconditionischangedの結果に従ってValidに遷移する。出力モードが有効であって、StartPresentationが終了すれば、状態はInvalidに遷移する。ムービーオブジェクトにおけるナビゲーションコマンドは、コンテンツプロバイダが好ましい出力モードに設定するために、プレイリスト再生の開始に先立ち、実行されねばならない。ムービーオブジェクトにおけるナビゲーションコマンドが実行された際、このモデルでは、Invalidになる。図32は、Initializationの処理手順を示すフローチャートである。ステップS1は、ディスクアンバウンドのBDJアプリケーションが動作中かどうかの判定であり、ステップS2は、PSR23におけるStereoscopicDisplayCapabilityがCapability有を示し、IndexbdmvにおけるInitial_output_mode情報が立体視出力モードを示すかどうかの判定である。ステップS1がYesであれば、ステップS3においてカレントの出力モードを維持する。ステップS1がNo、ステップS2がYesであれば、ステップS4においてPSR22を立体視出力モードに設定する。ステップS1がNo、ステップS2がNoであればステップS5においてPSR22における出力モードを、2D出力モードに設定する。図33は、Procedurewhenplaybackconditionischangedの処理手順を示すフローチャートである。ステップS11は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、ステップS13は、PSR23におけるStereoscopicDisplayCapabilityがCapability有を示し、尚且つ、プレイリストにSTN_table_SSが存在するかどうかの判定である。ステップS11がYesであればステップS12において、カレント出力モードを変化させない。ステップS11がNo、ステップS13がYesであってもカレント出力モードを変化させない。ステップS11がNo、ステップS13がNoであればカレント出力モードを2D出力モードに変化させる。プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、ストリーム選択プロシージャと呼ばれる。図34は、ストリーム選択プロシージャの処理手順を示すフローチャートである。ステップS21は、再生装置の表示方式が2Dであるか否かを判定する判定ステップであり、判定結果がYesであるなら、カレントプレイアイテム情報内の2D用STN_tableをカレントSTN_tableに設定する。判定結果がNoであるなら、プレイリスト情報のエクステンションデータに存在するSTN_table_SSのうち、カレントプレイアイテム情報に対応するものを、カレントSTN_tableに設定する。以降、ステップS24~ステップS33の処理を実行する。ステップS24~ステップS33は、プライマリビデオストリーム、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップS26~ステップS33の処理を繰り返すものである。ステップS26は、カレントSTN_tableにおける、ストリームxに対応するSTN_tableエントリー数が0であるか否かの判定であり、ステップS27は、カレントSTNtableにおけるストリームxに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。ステップS26、ステップS27の何れかがYesであれば、ステップS33においてストリーム番号レジスタに格納されているストリーム番号を維持する。ステップS26、ステップS27の何れもがNoであれば、カレントSTN_tableに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する。条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する。条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレントSTN_tableにおける優先順位が最も高いものを選択する。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む。以上の過程を経て出力モードが確定し、またカレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedurewhenplaybackconditionischangedによって確定した出力モードに応じたものとなる。出力モードに応じた、プレイアイテムの再生手順を図35を参照しながら説明する。図35は、プレイアイテムの再生手順を示すフローチャートである。ステップS41は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップS42において、カレントプレイアイテム番号を1に初期化した上で、ステップS43~ステップS48のループに移行する。このループは、カレントプレイアイテムに対してステップS43~ステップS46の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を、カレントプレイアイテム番号が最終になるまで繰り返すものである。ステップS43~ステップS46の内容は、以下のものである。ステップS43において、カレントプレイアイテムのClip_Information_file_nameに記述されているXXXXXと、拡張子m2tsとで指定されているトランスポートストリームファイルをオープンし、ステップS44において、ビデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItemIn_Time及びカレントPlayItemOut_TimeをStart_SPNi及びEnd_SPNiに変換する。ステップS45では、パケットIDiのTSパケットiをStart_SPNiからEnd_SPNiまで読み出すための読出範囲iに属するエクステントを特定し、ステップS46において、読出範囲iに属するエクステントを連続的に読み出すよう、BDROMドライブに指示する。カレント出力モードが立体視出力モードであれば、ステップS49において、カレントプレイアイテム番号を1に初期化した上で、ステップS50~ステップS60のループに移行する。このループは、カレントプレイアイテムに対してステップS50~ステップS58の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を、カレントプレイアイテム番号が最終になるまで繰り返すものである。ステップS50~ステップS58の内容は、以下のものである。ステップS50において、カレントプレイアイテムのClip_Information_file_nameに記述されているXXXXXと、拡張子ssifとで指定されているトランスポートストリームファイルをオープンし、ステップS51において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のレフトビュー/ライトビュー識別情報によって指定されているものををベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。ステップS52において、ベースビュービデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItemIn_Time及びカレントPlayItemOut_TimeをStart_SPNi及びEnd_SPNiに変換する。ステップS53では、ディペンデントビューストリームに対応するSubPlayItemを特定し、ディペンデントビューストリームのパケットIDjに対応するエントリーポイントjを用いて特定されたSubPlayItemIn_Time、SubPlayItemOut_TimeをStart_SPNj、End_SPNjに変換する。パケットIDiのTSパケットiをStart_SPNiからEnd_SPNiまで読み出すための読出範囲iに属するエクステントを特定し、パケットIDjのTSパケットjをStart_SPNjからEnd_SPNjまで読み出すための読出範囲に属するエクステントを特定する。そしてステップS57において読出範囲ijに属するエクステントをアドレスの昇順にソートして、ステップS58においてソートされたアドレスを用いて、読出範囲ijに属するエクステントを連続的に読み出すよう、ドライブに指示する。HDMVモードにおいては、プレイリストの再生が停止していれば、画面には何も現れないが、BDJモードでは、プレイリスト再生が停止していても、BDJアプリケーションが画面描画を行うことができるので、何等かの画面が表示されている可能性がある。ここでもし、再生制御エンジン側で立体視が実現されているのに、BDJアプリケーションによる画面描画が平面視のままでは不整合が起こる。何故なら、再生制御エンジン側で立体視が実現されているのに、BDJアプリケーションによる画面描画が平面視のままでは不整合が起こるからである。プレイリストの再生が開始されれば、そのプレイリストが2Dであるか、3D映像であるかに応じて、メニューやグラフィクスを3Dに変換したり、2Dに変換する必要があるので、そこで本実施形態では、ミドルウェアがBDJアプリケーションにイベントを出力して、立体視のための画面描画を促すことにしている。2D映像と3D映像とが切り替わるタイミングを、ディスク上に記録され、再生装置で動作しているプログラムに知らせるための仕組みについて説明する。図31の状態遷移では、BDJタイトルにおいてプレイリストの再生が開始した際、Procedurewhenplaybackconditionischangedが実行されたが、このBDJタイトルの再生中に、プレイリストの再生が開始された場合、何等かの術により、プレイリスト再生の開始をBDJアプリケーションに通知せねばならない。この通知をどのようにして行うかを記述したのが図36である。図36は、再生制御エンジンの状態が停止中から3Dプレイリスト再生中に切り替わった場合に、BDJアプリケーションにどのようなイベントが出力されるかを示す図である。第1段目は、BDJアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBDJアプリケーションに出力されるHScreenConfigurationイベントを示す。第3段目によると、再生制御エンジンの状態は、停止中→3Dプレイリスト再生→停止中というように遷移していることがわかる。このうち、停止中から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から停止中に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。第1段目において、再生制御エンジンの停止中に、BDJアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BDJアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これは、上記イベント出力に応じて、BDJアプリケーションがGUIの描画切り替えを行ったためである。次に、再生制御エンジン7bが再生を停止しているのではなく、2Dプレイリストの再生を既に開始しており、その再生の途上で、再生対象となるプレイリストが切り替わるというケースを想定する。図37は、再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BDJアプリケーションにどのようなイベントが出力されるかを示す図である。第1段目は、BDJアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBDJアプリケーションに出力されるHScreenConfigurationイベントを示す。第3段目によると、再生制御エンジンの状態は、2Dプレイリスト再生→3Dプレイリスト再生→2Dプレイリスト再生というように遷移していることがわかる。このうち、2Dプレイリスト再生から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から2Dプレイリスト再生に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BDJアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BDJアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これも、上記イベント出力に応じて、BDJアプリケーションがGUIの描画切り替えを行ったためである。次に、再生制御エンジンによる3Dプレイリストの再生中に、ユーザが字幕切り替え、音声切り替えの操作を再生装置に行ったというケースを想定して、以下を行う。再生対象となるストリームが切り替わることになる。以下、このストリーム切り替えの事例について図38を参照しながら説明する。図38は、再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BDJアプリケーションにどのようなイベントが出力されるかを示す図である。第1段目は、BDJアプリケーションによって描画されたGUIを示す。第3段目は、再生制御エンジンの状態を示す。第2段目は、ミドルウェアからBDJアプリケーションに出力されるHScreenConfigurationイベントを示す。第3段目によると、再生制御エンジンの状態は、3Dプレイリスト再生であるか、その途中に、ストリーム切替えがなされていることがわかる。このうち、ストリームが別のものに変化したタイミング、及び、ストリームが元のものに戻ったタイミングに、HScreenConfigurationイベントが出力されていることがわかる。第1段目において、再生制御エンジンによる2Dプレイリストの再生中に、BDJアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BDJアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。プレイアイテムやプレイリスト、あるいは、ユーザーがストリーム切り替えを行ったタイミングであって、3D映像の再生が開始された場合、あるいは、終了した場合に、イベントを上げることにより、2D3Dが切り替わるタイミングを検出して、適切なメニューグラフィクスに切り替えさせる。以上のように本実施形態によれば、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のClip_Information_file_nameと、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子ssifとから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供することで、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。こうしたオーサリングの手間の低減によって、3D再生可能な映画作品の充実化を図ることができる。第2実施形態本実施形態では、表示装置300、3D眼鏡400がどのような機能をもち、その内部構成がどのようなものかを図39を参照しながら説明する。図39aは、表示装置300の内部構成を示す図である。本図に示すように、表示装置300は、チューナ71、HDMI送受信部72、メッセージ記憶部73、表示制御部74、表示素子75、無線送信部76から構成される。チューナ71は、地上波デジタル放送、衛星デジタル放送で送信されたマルチチャネルトランスポートストリームを受信して復調する。この際チューナ71は、複数のチャネルを同時に選局して非圧縮のピクチャを出力することもできる。HDMI送受信部72は、HDMIを通じて再生装置から送信されてくる非圧縮で合成済みピクチャデータを受信する。メッセージ記憶部73は、ピクチャに代えて表示すべき警告メッセージを記憶している。表示制御部74は、チューナ71による復調で得られた非圧縮のピクチャ、HDMIを通じて再生装置から伝送された非圧縮で合成がなされたピクチャを表示に供する。表示にあたって表示制御部74は、1120秒、1140秒という時間精度で、表示期間を切り替えることができ、この精度で、例えば124秒という表示期間を、148秒、172秒、192秒というように、更に小さい表示期間に細分化することができる。表示パネル75は、液晶表示素子、プラズマ発光素子、有機EL素子を駆動することで、画素の発光を行うデバイスであり、表示制御部74による制御の下で、非圧縮のピクチャデータの表示を行う。無線送信部76は、赤外線通信方式、無線LAN方式によって、3D眼鏡400を制御する。具体的には、3Dモード及びマルチチャネルモードのそれぞれにおいて、表示期間の先頭にあたって、3D眼鏡400の状態遷移を促す同期信号を送信する。かかる信号送信によって、レフトビューの期間では透光状態に遷移し、ライトビューの期間では遮光状態に遷移し、レフトビューの期間では改めて透光状態に遷移させるという制御を繰り返す。これにより、図1のような変化を行うことになる。本実施形態では3Dモードでの処理として、表示制御部74は、124秒という表示期間を、172秒の時間長をもつ3つの表示期間に分割して、この3つの表示期間132333のそれぞれに、別々の表示内容を表示する。1つ目の表示期間13の表示内容はレフトビュー、2つ目の表示期間23の表示内容はライトビュー、そして3つ目の表示期間33の内容には警告画面というようにである。これらの期間の先頭において、眼鏡に対して同期信号を送信し、レフトビュー及びライトビューの状態遷移を行わせる。マルチチャネルモードの処理として、表示装置300は複数のチャネルを、時分割で復調する。そして表示制御部74は、124秒という表示期間を、148秒の時間長をもつ2つの表示期間に分割して、この2つの表示期間1222のそれぞれに、別々の表示内容を表示する。1つ目の表示期間12の表示内容はチャネル1、2つ目の表示期間12の表示内容はチャネル2というようにである。そして、個々のチャネルの表示期間が到来すれば、そのチャネルの視聴を希望しているユーザの状態を透光状態に遷移させ、他のチャネルの視聴を希望しているユーザの眼鏡の状態を遮光状態に遷移させる。図39bは、3D眼鏡400の内部構成を示す図である。状態遷移のトリガとなる同期信号を表示装置300から受信する無線受信部81と、液晶シャッタの状態を、透光状態、遮光状態に遷移させる状態制御部82と、液晶シャッタ83、84とを具備する。眼鏡の動作モードにも、3Dモード、マルチチャネルモードが存在する。3Dモードにおいて眼鏡は、透光状態、遮光状態のほか、遮断-遮光状態を具備する。遮断-遮光状態は、レフトビュー及びライトビューの双方が閉じている状態である。マルチチャネルモードにおいて眼鏡は、レフトビュー及びライトビューの双方が開いている透光-透光状態と、レフトビュー及びライトビューの双方が閉じている遮断-遮光状態とに遷移する。立体視表示を実現する場合、本実施形態では、眼鏡のライトビュー、レフトビューを、単に切り替えるのではなく、3D眼鏡400の装着を促す警告画面を、3D眼鏡を既に装着しているユーザに見せないような配慮が必要になる。警告画面を装着済みユーザに見せないように、3D眼鏡400をどのように制御すべきかを、図40を参照しながら説明する。図40は、3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のライトビュー、レフトビューの状態を示す。124秒のうち、最初の172秒の表示期間13では、レフトビュー画像が表示装置に表示されていて、眼鏡のレフトビューが透光状態、ライトビューが遮光状態になっている。続く表示期間23では、ライトビュー画像が表示装置に表示されていて眼鏡のレフトビューが遮光状態、ライトビューが透光状態になっている。最後の表示期間33では、表示装置が眼鏡の装着を促す警告画面になっていて、眼鏡のレフトビュー及びライトビューが遮光状態になっていることがわかる。124秒の表示期間を分割することで得られた3つの172秒の表示期間のうち、最後の表示期間33において、眼鏡を装着したユーザは、画面に表示されている警告映像を見ることができない。3D眼鏡をかけてくださいと表示すると、3D眼鏡をかけていない人には、3D眼鏡をかけることを促すメッセージが見えるが、すでに3D眼鏡をかけている人には見えないといった、状況に応じたメッセージが表示されることになる。マルチチャネル表示を実行する場合、表示装置は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替えるという独特の制御を実現する。この独特な制御を図41を参照しながら説明する。図41は、左右のシャッターを切り替えるのではなく、2つの眼鏡のシャッターを切り替える場合の、3Dモードにおける表示内容と、ユーザ1の状態と、ユーザ2の状態とを示す。第1段目は、再生時間軸における表示期間を示し、第2段目は、表示装置の表示内容を示す。第3段目は、眼鏡のR、Lの状態を示す。124秒の表示期間のうち、表示期間12において、ユーザー1が装着している眼鏡は、透光-透光状態になりユーザ1はチャンネル1Ch1を視聴することができる。ユーザー2が装着している眼鏡は、遮光-遮光状態になりユーザ2はチャンネル1Ch1を視聴することができない。表示期間22において、ユーザー1が装着している眼鏡は、遮光-遮光状態になりユーザ2はチャンネル2Ch2を視聴することができない。ユーザー2が装着している眼鏡は、透光-透光状態になりユーザ2はチャンネル2Ch2を視聴することができる。このような使い方をすると、1つの画面で、二人がそれぞれ異なるチャンネルを同時に見ることができる3D眼鏡をすでに装着しているため、眼鏡に内蔵されたイヤフォンを用いれば、映像と音声を完全に独立させることも可能であり、リビングでのチャンネル権争いの回避、1つの画面で対戦ゲームをするなど、応用範囲は広がる。また、ステップを増やすことにより、3チャンネルやさらに多くのチャンネルを1つの画面で見ることが可能となる。以上のように本実施形態によれば、表示装置を視聴しているユーザが複数人である場合、各ユーザが3D眼鏡400を着用することで、各ユーザは、自分が好きなチャネルを視聴することが可能になる。ユーザの人数分、表示装置を用意しなくてもユーザは好きな番組を見ることができるので、ユーザ宅のリビングを有効に利用することができる。本実施形態は、再生装置と、表示装置とのネゴシエーションに関する実施形態である。ユーザ宅内におけるホームシアターシステムの構築事情には、それぞれの家庭独特のものがあり、再生装置は、表示装置と接続された際、接続相手となる表示装置とネゴシエーションを行って、どのプレイリストを再生に供するかを切り替える必要がある。本実施の形態では、3Dに対応したデジタル出力と、旧来の表示装置にも出力できることを考慮したアナログ出力を同時に出力する場合の改良を説明する。3D映像を格納したBDROMであったとしても、旧来から存在して普及台数が多い2D再生装置でも正常に再生されることを考える必要がある。第1実施形態で述べたように、BDROM上のプログラムで制御する方法もあるが、プログラムのバグなどにより選択を誤った場合、不適切な映像が再生され視聴者の健康を害したり、過剰な負荷がかかることにより再生装置が壊れてしまう可能性もあるため、不適切な再生が行われない仕組みが必要となる。2DTVとの接続時について述べる。そもそも旧来のアナログ方式では3D映像に対応していないため、3D映像は出力できない。再生装置が3D映像再生中は、アナログ出力に3D映像再生中です。3D対応のディスプレイでご覧ください。などのメッセージを表示して、ユーザーが誤った端子に接続したり、対応していない表示装置に接続していることを知らせるためのメッセージを表示する。その後、接続されている表示装置が2D表示装置である場合は、自動的に2Dプレイリストに再生を切り替えることが望ましい。次に、2D表示装置と、3D表示装置とが再生装置に同時に接続されていて、これらの表示装置に映像信号を同時出力するケースについて説明する。再生装置に2D表示装置と3D表示装置が接続されており、同時に出力している場合は、2D表示装置側に3D映像のレフトビューかライトビューのいずれかのみを出力する。複数の表示装置に、プレイリストの再生結果である映像信号を同時出力する際、レフトビュービデオストリーム、ライトビュービデオストリームのうちどちらを、アナログ用に出力するかを規定する情報を、2D出力優先映像情報という。この情報をプレイリストに予め設けておき、カレントプレイリストにおける2D出力優先映像情報に従い、2D表示装置、3D表示装置に同時に映像信号を出力する。こうすることで、2Dと3D用の映像を同時にデコードしたり、2Dと3D用のプレイリストを独立して扱えなくても、同時に2つの表示装置に出力することが可能となる。同様にOSDシステム組み込みメニュー表示を行う際、3D表示装置には3D対応のOSD表示を行うが、アナログ出力のように2Dしか対応しない出力には専用の2D映像、あるいは、レフトビューのみライトビューのみを出力する。3D用の出力と2D用の出力が困難な場合は、リモコンに副表示部を設け、そちらに表示することが望ましい。これらのことを図42を参照しながら具体的に説明する。図42は、再生装置と、表示装置との接続態様を示す図である。上側は、アナログ接続される表示装置を示す。左下側に、デジタル接続される3D対応の表示装置300を示し、右下側に、デジタル接続される2D表示装置302を示す。再生装置が、3D表示装置と、2D表示装置とに同時接続された場合は、これらの表示装置とネゴシエーションを試みる。そして、相手側表示装置との接続がアナログ接続によるものであるため、ネゴシエーションをすることができないことが判明すれば、レフトビュービデオストリーム、レフトビュービデオストリームのうち、2D出力優先映像情報に示されるものを再生する。こうすることで、接続相手たる表示装置とアナログ接続された場合、オーサリング担当者が意図したプレイリストを再生に供することができる。一方、双方の表示装置との接続がデジタル接続によるものであり、ネゴシエーションが成功した場合は、相手側が3D表示装置であるか、2D表示装置であるかを判定する。ネゴシエーションの結果、相手側が2D表示装置であることが判明すれば、図中の矢印mg1に示すように画面内容の遷移を2D表示装置に行わせる。矢印mg1は、2D表示装置の画面内容の遷移を示す。デジタル接続の場合、3D映像の再生中です。3D表示装置で御覧くださいとのメッセージを表示した後、2D映像を表示する。またネゴシエーションにあたっては、複数のライトビューを切り替える必要がある。複数のライトビューを切り替える理由として、表示装置の画面の大きさの違いがある。左目と右目の間隔は個人の個体差があってもだいたい同じであるが、表示装置は20インチのものもあれば、150インチのものもある。50インチの表示装置を想定して、目と目の間隔65センチで作られた映像も、150インチの表示装置では3倍の195センチの目の間隔になってしまい、3D映像として認識が難しくなる。そのため、様々なサイズの表示装置でレフトビューとライトビューの差が、65センチになるレフトビュー、ライトビューの組みを納めておけば、表示装置に合わせてビデオストリームを選ぶことにより、最適なレフトビュービデオストリームライトビュービデオストリームの組み合わせを選ぶことができる。表示装置には、150インチ、50インチという様々なサイズがあり、例え左右の画素数が同じでも、これらの表示装置における画面上の距離は違ってくることを図43を参照しながら説明する。図43は、左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。左側は、左右のオフセットが異なる、ライトビューピクチャ-と、レフトビューピクチャとの組を示す。中段は、50インチ表示装置における距離を示し、右側は、150インチ表示装置における距離を示す。左右の差が50画素である場合、50インチ表示装置上での距離は20cmとなり、150インチ表示装置上での距離は60cmとなる。左右の差が100画素である場合、50インチ表示装置上での距離は、40cmとなり、150インチ表示装置上での距離は120cmとなる。左右の差が150画素である場合、50インチ表示装置上での距離は、60cmとなり、150インチ表示装置上での距離は180cmとなる。50インチ表示装置では、60cmが最適となり、150インチ表示装置でも、60cmが最適となので、3DStreamDepthChangeUO、3DStreamDepthChangeコマンドにより、画面上において表示される距離を調整する。図43で説明した表示装置の画面サイズを取得する方法を用いて、プログラムが自動的に最適な左目ライトビューの組み合わせを選択できれば、ユーザーは画面サイズを気にすることなく、最適なストリームが自動選択されることになる。複数の画面サイズに対応した奥行き感深度の異なるストリームが複数記録されている場合、ローカルストレージの画素差が異なるストリームを記録媒体に記録しておき、これらのストリームを切り替えるためのUOやコマンドを用いることで、ユーザー自身が奥行き感深度を選択することも可能である。以上のように本実施形態によれば、再生装置が表示装置と接続された際、表示装置との関係においてより適切な再生出力が行われることが保障される。本実施形態は、立体視を行うにあたって、ビデオストリームと共に、どのようなPGストリーム、IGストリームを選択すべきかという改良を実現する。2D再生装置で再生される映像は2D映像であり、対応する字幕やメニュー画像が2Dである。対して、3D再生装置で再生されるのは3D映像であり、対応する字幕やメニュー画像も3Dであることが望ましい。3D映像に対して、2DのPGやIGが表示された場合、前後関係が意図しないものとなり、ユーザーが正常に空間認識ができず、最悪健康を害してしまうためである。また、3D再生装置であったとしても、ユーザーが2D映像を選ぶことは自由であるが、その場合、対応する字幕やメニュー画像も自動的に2Dに切り替わるべきである。2D映像と関連する字幕などの組み合わせ、3D映像と関連する字幕などの組み合わせは、プログラムで選択してもよいが、データとして関連づけておくことにより再生装置が自動的に不適切な組み合わせを排除することが可能となる。その仕組みについて述べる。3D対応のプレイリストは、第1実施形態で示したように、ストリーム選択テーブルをさらに2D用のSTN_tableと、3D再生用のSTN_table_SSとに分けて管理する。そして2D再生でしか利用しない映像音声PGIGのストリーム登録と、3Dで利用する映像音声PGIGのストリーム登録は異なるエントリー群に登録する。2D映像を選択している場合は、3D用に用意された音声PGIGは選択できない。また、同様に3D映像を選択している場合は、2D用に用意された音声PGIGは選択できない。管理テーブルをさらに分割して、レフトビューとライトビュー、それらに関連づけられる字幕メニュー画像のストリーム登録を別々に管理することもできる。2D用に作成されたPGストリームと、3D用に作成されたPGストリームとでは、奥行きの有無、位置や角度に違いがあるので、立体視のためのビデオストリームの再生時に、2DPGストリームが選択されて、3Dビデオストリームと共に再生されることは、オーサリング者にとっては何とか避けたいところである。これを避けるために導入されたのが、STN_table_SSにおけるストリーム組合せ情報である。図44は、ビデオストリームとPGストリームとを組み合わせる場合の、ストリーム組合せ情報の記述例である。本図aに示すように、ストリーム選択テーブルにおけるストリーム組み合わせ情報には、ビデオストリームのストリーム番号=1と、PGストリームのストリーム番号1、2との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=2には、PGストリームのストリーム番号1、2との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=3には、PGストリームのストリーム番号=3、4との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号=4には、PGストリームのストリーム番号=3との組み合わせが許容されていることがわかる。図44bは、その組合せ情報にて規定されるビデオストリーム、PGストリーム間で、許容される組合せを模式的に示す。本図左側のビデオストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるビデオストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるビデオストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるビデオストリームは3D用であることがわかる。本図右側のPGストリームは、ストリーム1、2、3、4のストリーム番号によって特定されるPGストリームを示す。これらのうち、ストリーム1、2のストリーム番号によって特定されるPGストリームは2D用であり、ストリーム3、4のストリーム番号によって特定されるPGストリームは3D用であることがわかる。ビデオストリーム及びPGストリームの間の実線kw123は、ストリーム組合せ情報によって許容される組合せを模式的に示す。この実線で模式的に示されるように、2Dと3Dの映像字幕を組み合わせることはできない。また、組み合わせ可能なストリーム通しの場合も意図的に省くことができる。PGストリームと、ビデオストリームとの組合せはストリーム組合せ情報に予め規定されているので、このストリーム組合せ情報に則して、PGストリームを選択すれば、あるビデオストリームが選択された際、このビデオストリームにとって最適なPGストリームが選択されることが保障されることになる。図45は、ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。ユーザーがストリームを切り替える時、あるいは、プレイアイテム境界のように、ストリームの構成が変化する可能性がある時に、本図で示すストリーム選択処理が実行され、ビデオストリームとPGストリームは、ストリーム組み合わせ情報に登録された組み合わせに合致させる。ステップS71において、ビデオストリーム番号を取得し、ステップS72においてPGストリームを取得する。ステップS73は、ビデオストリームと、PGストリームとの組合せが、ストリーム組合せ情報に登録されているかどうかの判定であり、もし登録されていれば、ステップS74においてそのストリーム組合せ情報の通り再生する。登録されていなければ、ステップS75においてストリーム組合せ情報においてビデオストリームとの組合せが登録されている、他のPGストリームを選択し再生する。第1実施形態の冒頭で述べたように、立体視には様々な原理があり、市場で流通しつつある製品は、様々な3D方式に対応していると考えられる。3Dの再生方式にはいろいろな方式が存在し、また、方式により表示装置側の対応非対応も異なるため、再生装置のシステムパラメータは複数の方式を表現できる形式が望ましい。ここでは、3Dの再生方式として、2画面のビデオを独立して送る2画面ステレオ再生方式、サイドバイサイド方式、横方向2倍方式、2D奥行き情報方式などを例に挙げるが、その他、表示装置が対応可能な方式がある場合は、対応する方式の実行の可否を識別できるように、PSRのビットアサインを定める。図46は、複数の3D方式を網羅できるPSRのビットアサインを示す図である。本図におけるPSR24は、4ビットからなり、最上位ビットb3から最下位ビットb0までのそれぞれのビットには、それぞれ対応する3D再生方式が関連づけられている。再生装置がその3D再生方式に対応している場合には、対応するビットが1に設定され、対応していない場合には対応するビットが0に設定される。PSR24の全ビットが0のときは、再生装置は2D再生装置であり、いずれかあるいはいくつかのビットが1のときは、対応した方式の2D3D再生装置であることを示す。PSR24における最上位ビットb3から最下位ビットb0までのビットは、2画面ステレオ再生、サイドバイサイド方式、横方向2倍方式、2D-奥行き情報方式のそれぞれの3D表示方式をサポートできるかどうかを示す。2画面ステレオ再生方式は、これまでの実施形態で説明した方式である。サイドバイサイド方式は、1920×1080という解像度を、960×1080と、960×1080とに分けて、これらのそれぞれに、レフトビュー,ライトビューを表示させる方式をいう。横方向2倍方式は、1920×1080という解像度を、3840×1080という解像度にして、このうち、1920×1080の解像度の部分にレフトビューを割り当て、1920×1080の解像度の部分にライトビューを割り当てる方式である。2D-奥行き情報方式は、2D映像と、グレースケール画像とで立体視を実現する方式である。グレースケール画像は、2値化画素からなる。2値化画素の輝度は、2D映像における各画素の奥行きを示す。この2値化画素の輝度に従い、2D映像における各画素の奥行きを作成して、立体視画像を構築する。プレーヤセッティングレジスタの値をBDROM上のBDJアプリケーションからアクセスする場合は、再生装置のシステムプロパティとしてアクセスすることも可能である。表示装置と再生装置が、HDMIのように表示装置の性能対応方式を再生装置に送信できる伝送方式により接続されている場合、再生装置の性能だけではなく、表示装置の対応方式も鑑みて、PSR24に自動的に設定する。この場合、同じ再生装置でも接続される表示装置によってPSR24の値は変化する。表示装置の性能を伝送できない場合は、ユーザーが手動で設定することが望ましい。表示装置から対応方式を取得できる場合は、単純な対応方式の他、表示装置のサイズ、解像度、表示装置の画面から視聴する人までの距離等、3D再生に影響する情報を取得し、PSR24に格納しておくことで、後で説明するプログラムによる最適な再生方式の選択に活用することも可能である。3Dの対応状況が1ビットで表せないことがででくる。この場合、複数ビットを使うべきである。映像サイズが1920×1080までは対応可能だが、それ以上の解像度の場合はデコーダの性能不足などにより再生できないことが想定される場合、2ビットを利用して非対応を00b、1920×1080まで対応を01b、それ以上のサイズに対応したものを10bなどと表現すれば、より細かく対応状況をシステムパラメータを用いて表現することが可能である。複数の3D方式を網羅できるようにPSR24のビットアサインを規定しておけば、再生装置に接続される表示装置がどのような3D方式のものであっても、表示装置に立体視再生を行わせることができる。図47は、表示装置が対応している3D再生方式を再生装置セッティングレジスタに反映させる図である。これまでに説明した3D再生能力を示す3DCapabilityのシステムパラメータを利用すると、2D再生装置が3Dビデオストリームを選択することを禁止する処理も可能である。ユーザー、プログラムあるいは、プレイアイテム先頭において、ビデオストリームを選択する時、選択しようとしているストリームが3Dビデオストリームである場合、プレーヤセッティングレジスタに格納された再生装置の対応3D方式を確認し、ストリーム選択テーブルから選択しようとしているストリームの情報を取得することにより、選択するストリームが再生装置で再生可能か否かが判別できる。2D再生装置では3D映像を再生できないため、この処理により選択自体が発生せず、不適切な映像が画面に表示されることを防ぐことができる。前の実施形態で説明した、表示装置が対応している3D方式を自動的に取得する仕組みと組み合わせると、接続されている表示装置が対応した3D方式のストリームか2Dストリームしか選択できないようになり、不適切な映像が画面に表示されることを防ぐことができる。かかる処理を実現する場合のプログラムの処理内容について説明する。ユーザからタイトルが選択され、実行されたBDプログラムファイルは、プログラムの中で、再生装置が3D映像再生に対応しているか、対応している場合にユーザが3D映像再生を選択しているかを調べて、再生するプレイリストを切り替える。3D再生方式を複数想定する場合は、それぞれ対応した方式のプレイリストを準備しておき、再生装置がBDROMに格納されたプレイリストに対応している場合は、対応した3Dプレイリストを選択、対応していない場合は、2Dプレイリストを選択する。FirstPlayタイトルをどのように構成すべきかについて説明する。FirstPlayタイトルを構成するプレイリスト、つまり、ディスク挿入時にまず最初に再生されるプレイリストは、安全のため必ずどの再生装置でも再生される2D映像で構成すべきである。BDROMに格納されているプログラムはオーサリング側が作成するものであり、複数の3D形式に再生装置が対応している場合、どの3D再生方式を優先的に選択するかは、オーサリング側の意志に依存する。3Dプレイリストの選択について説明する。たとえば、3D方式1が2画面ステレオ再生方式、3D方式2がサイドバイサイド方式であり、再生装置がサイドバイサイド方式にのみ対応している場合、プログラムはその再生装置で再生可能であるサイドバイサイド方式の3Dプレイリスト005MPLSを選択して再生する。Indexbdmv、プログラムの関係について説明する。図47に示すように、3D再生方式を再生装置セッティングレジスタに反映させれば、BDROMにおけるプログラムを動作させることでオーサリング担当者は、再生装置及び表示装置にとって最適な3D方式を再生装置セッティングレジスタに設定することができる。このような3D再生方式の選択を実現する場合、インデックステーブルと、BDプログラムファイルとは、以下に示すように設定しておく必要がある。図48はインデックスファイルIndexbdmvとプログラムファイルとの関係を示している。本図左側は、インデックステーブルと、当該インデックステーブルの解読主体であるモード管理モジュール16とを示す。上述したように、インデックステーブルには、FirstPlayタイトル、トップメニュー、タイトル1、2、3のそれぞれに対応するエントリーが存在する。本図の右側は、再生装置における出力モードの設定に応じて選択的に再生されるべき4つのプレイリストファイルを示す。4つのプレイリストファイルには、2D映像を再生する経路が記載された00001mpls、00003mplsと、3D方式1による再生経路が記載された00004mplsと、3D方式2による再生経路が記載された00005mplsとが存在する。本図の真ん中には、ムービーオブジェクト12という2つのムービーオブジェクトが記載されている。ムービーオブジェクト1は、00001mplsの再生を命じる。この00001mplsは、2Dプレイリストを定義するものである。何故なら、FirstPlayタイトルで再生されるべきプレイリストは、何れの出力モードでも必ず再生される必要があるからである。ムービーオブジェクト2は、PSR24に示される3DCapabilityが3D方式1であれば、00004mplsの再生を命じ、3DCapabilityが3D方式2であれば00005mplsの再生を命じ、3DCapabilityが、何れの3D方式にも合致しなければ、00003mplsの再生を命じる。図中の矢印pp1pp2pp3は、ムービーオブジェクトによるプレイリストの再生指示を模式的に示す。図中の矢印my1my2は、これらのムービーオブジェクトが、HDMVモジュール13による解読に供されることを示す。HDMVモジュール13が、これらのムービーオブジェクトを実行することで、再生装置におけるCapabilityに応じて、上述したような3つのプレイリストファイルが選択的に再生に供されることがわかる。ストリーム組合せ情報に、ビデオストリームと組合せることができるPGストリームが予め規定されていれば、ストリーム選択の処理手順は、図49のフローチャートに則したものとなる。図49は、ストリーム選択の処理手順を示すフローチャートである。ステップS81において、再生装置の対応3D方式を取得し、ステップS82において、ストリーム選択テーブルを取得する。ステップS83では、再生装置が対応する3D方式と、選択しようとするストリームとが合致しているかどうかを判定し、ステップS83の判定結果がYesであるなら、ステップS84において選択を許す。ステップS83の判定結果がNoであるなら、ステップS85において、選択を許可しない。第6実施形態本実施形態では、第1実施形態で述べた記録方法を実施するための記録装置について説明する。リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BDRE又はBDR、ハードディスク、半導体メモリカードに記録する。この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2TS形式のデジタルストリームを得るマルチプレクサと、MPEG2TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBDREBDR等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップファイル及びクリップ情報ファイルをBDREBDR上にクリエイトする。そして、装置外部から入力されるトランスポートストリームからビデオストリームにおけるGOPの先頭位置が検出されるか、エンコーダによってビデオストリームのGOPが生成されれば、記録装置の制御部は、このGOPにおいて、先頭に位置するイントラピクチャのPTSと、このGOPの先頭部分を格納したソースパケットのパケット番号とを取得して、このPTS及びパケット番号の組みを、EP_PTSエントリー及びEP_SPNエントリーの組みとして、クリップ情報ファイルのエントリーマップに追記する。以降、GOPが生成される度に、EP_PTSエントリー及びEP_SPNエントリーの組みを、クリップ情報ファイルのエントリーマップに追記してゆく。この際、GOPの先頭がIDRピクチャである場合は、オンに設定されたis_angle_changeフラグをEP_PTSエントリー及びEP_SPNエントリーの組みに追加する。GOPの先頭がIDRピクチャでなければ場合は、オフに設定されたis_angle_changeフラグをEP_PTSエントリー及びEP_SPNエントリーの組みに追加する。また、クリップ情報ファイルにおけるストリームの属性情報については、記録されるべきストリームの属性に従い設定する。以上のようにしてAVクリップ、クリップ情報が生成されてBDREBDRに書き込まれれば、このクリップ情報内のエントリーマップを介して、再生経路を定義するプレイリスト情報を生成し、BDREBDRに書き込む。このような処理を、リアルタイムレコーディング技術において実行することで、AVクリップ-クリップ情報-プレイリスト情報という階層構造をBDREBDR上に得ることができる。以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法を実行する記録装置について説明する。ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBDROM向けのボリュームビットストリームを生成するというのが、本発明にかかる記録装置の使用形態である。図50は、記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、ビデオエンコーダ501、素材制作部502、シナリオ生成部503、BDプログラム制作部504、多重化処理部505、フォーマット処理部506により構成される。ビデオエンコーダ501は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG4AVCやMPEG2などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部501aに書き込む。ビデオエンコーダ501は、ピクチャ間の相関特性を利用した画像圧縮をするために、8x8や16x16のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、家のイメージの箇所には動きベクトルが検出されないが、人の箇所では動きベクトルが検出される。検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、8ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。素材制作部502は、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックストリームなどの各ストリームを作成して、オーディオストリーム格納部502a、インタラクティブグラフィクスストリーム格納部502b、プレゼンテーショングラフィックストリーム格納部502cに書き込む。オーディオストリーム作成にあたって素材制作部502は、非圧縮のLinearPCM音声などをAC3などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部502は、字幕イメージと表示タイミング、およびフェードインフェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BDROM規格に準拠したPGストリームのフォーマットであるプレゼンテーショングラフィックスストリームを作成する。素材制作部502は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BDROM規格に準拠したメニュー画面のフォーマットであるインタラクティブグラフィックスストリームを作成する。シナリオ生成部503は、素材制作部502で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BDROMフォーマットでシナリオを作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部503は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第1実施形態1および第2実施形態で説明したデータ構造となる。BDプログラム制作部504は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ501が出力した奥行き情報を利用することができる。多重化処理部505は、BDROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG2TS形式のAVクリップを作成する。このとき、AVクリップと対になるクリップ情報ファイルも同時に作成する。多重化処理部505は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。フォーマット処理部506は、シナリオ生成部503で生成したBDROMシナリオデータと、BDプログラム制作部504で制作したBDプログラムファイル、多重化処理部505で生成したAVクリップやクリップ情報ファイルや、BDROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BDROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成する。また、この時ビデオエンコーダ501が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトは実施の形態1、2で説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBDROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BDROMの製造が可能となる。記録装置は、マネージドコピーによってデジタルストリームの書き込むものでもよい。マネージドコピーとは、BDROM等の読み出し専用記録媒体に記録されているデジタルストリームやプレイリスト情報、クリップ情報、アプリケーションプログラムを、別の光ディスクBDR,BDRE,DVDR,DVDRW,DVDRAM等やハードディスク、リムーバブルメディアSDメモリーカード、メモリースティック、コンパクトフラッシュ登録商標、スマートメディア、マルチメディアカード等などの読み書き可能な記録媒体へコピーする際、サーバと通信を行い、認証が行われ許可された状態においてのみコピー実行可能にする技術である。この技術により、バックアップ回数を制限したり、課金された状態でのみバックアップを許す等の制御を行うことができる。BDROMからBDRBDREへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBDROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここでトランスコードとは、BDROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、AVクリップ、Clip情報、プレイリスト情報を得る必要がある。以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。第1実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に24枚の映像を表示させるのに対して、左右の映像合わせて1秒に48枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら2方式に限定するものではない。表示装置300についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。3D映像を格納するためのIndexbdmvのデータ構造プレイリストではなくインデックスファイルを、2D再生装置と3D対応再生装置で区別し、2D再生装置では再生開始時にIndexbdmvを参照するが、3D再生装置ではIndex3dmvを選択させるといった方法もとることができる。複数ストリームを扱うためのデータ構造複数のストリームがある場合、上記のようにサブパス情報を使ってもよいし、マルチアングルのためのmulti_clip_entriesを使ってもよい。multi_clip_entriesを使う場合、表示装置の画面のサイズに合わせてストリームを選択した後は、誤って他の画面サイズ用のストリームに切り替わらないよう、アングル変更のUOを禁止することが望ましい。レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。BDROMの各記録層には、立体視/平面視共用領域と、立体視専用領域と、平面視専用領域とを設けることが望ましい。立体視/平面視共用領域は、立体視映像の再生時と平面視映像の再生時との両方でアクセスされる領域であって、ベースビュービデオストリームファイルに属する複数のエクステントと、ディペンデントビューストリームを格納したファイルに属する複数のエクステントとが交互に配置されて記録された連続領域である。立体視専用領域及び平面視専用領域は、立体視/平面視共用領域に後続しており、記録層の境界直前に存在する。立体視専用領域は、立体視出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視/平面視共用領域に記録されたベースビュービデオストリームファイルに属するエクステントに後続するエクステントと、立体視/平面視共用領域に記録されたディペンデントビュービデオストリームファイルに属するエクステントに後続するエクステントとが交互に配置されて記録された領域である。平面視専用領域は、2D出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視専用領域に記録されたベースビュービデオストリームファイルに属するエクステントの複製物が記録された領域である、プログラムの実施形態各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA登録商標バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを1つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。データ構造の記述の仕方上述したようなデータ構造のうち、ある決まった型の情報が複数存在するという繰り返し構造は、for文に、制御変数の初期値と、繰り返し条件とを設定することで定義することができる。DoWhile文を用いてもよい。また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。この記述には、switch文、case文を用いてもよい。このように、各実施形態に示したデータ構造は、高級プログラミング言語の文法によって記述することができるので、各実施形態に示したデータ構造は、構文解析、最適化、資源割付、コード生成といった、コンパイラによる翻訳過程を経て、上記プログラムと同様、コンピュータが読み取り可能なコンピュータコードに変換された状態で記録媒体に記録される。こうして、高級プログラミング言語によって記述されたデータ構造は、オブジェクト指向言語においては、クラス構造体のメソッド以外の部分、つまり、クラス構造体における配列型のメンバー変数として扱われ、プログラムの一部をなす。つまり、各実施形態のデータ構造は、コンピュータコードに変換されてコンピュータ読取可能な記録媒体記に記録され、プログラムのメンバー変数となる。こうした扱いがなされるので、これまでに述べたデータ構造は、実質的にはプログラムと同じものである。光ディスクの再生BDROMドライブは、半導体レーザ、コリメートレンズ、ビームスプリッタ、対物レンズ、集光レンズ、光検出器を有する光学ヘッドを備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。集光された光ビームは、光ディスク上で反射回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、再生信号を生成する。各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク例えばBDROM、DVDROMなどの既存の読み取り可能な光ディスクを例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよいを利用して書き込み可能な光ディスク例えばBDRE、DVDRAMなどの既存の書き込み可能な光ディスクに記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。半導体メモリカード記録装置及び再生装置の実施形態各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。まず、前提となる技術として、BDROMに記録されているデータの著作権保護の仕組みについて説明する。BDROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。例えば、BDROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。以後、BDROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。半導体メモリカード再生装置においては、BDROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ例えばデバイスキーが予め再生装置に記憶されている。一方、BDROMには暗号化されたデータを解読するために必要な鍵に対応するデータ例えば上述のデバイスキーに対応するMKBメディアキーブロックと、暗号化されたデータを解読するための鍵自体を暗号化したデータ例えば上述のデバイスキー及びMKBに対応する暗号化タイトルキーが記録されている。ここで、デバイスキー、MKB、及び暗号化タイトルキーは対になっており、さらにBDROM上の通常コピーできない領域BCAと呼ばれる領域に書き込まれた識別子例えばボリュームIDとも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵例えば上述のデバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキーを導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。装填されたBDROMを再生装置において再生する場合、例えばBDROM内の暗号化タイトルキー、MKBと対になっているまたは対応するデバイスキーが再生装置内になければ、暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵タイトルキーは、鍵自体が暗号化されて暗号化タイトルキーBDROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵を導き出すことができないからである。逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しければ、例えば上述の暗号解読に必要な鍵デバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキーを用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。以上が、BDROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BDROMに必ずしも限定されるのではなく、例えば、読込み書込み可能な半導体メモリー例えばSDカードなどの可搬性を有する半導体メモリーカードに適用した場合においても、実施が可能である。半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのIFを介してデータを読み出すように構成すればよい。より詳細には、再生装置のスロット図示せずに半導体メモリーカードが挿入されると、半導体メモリーカードIFを経由して再生装置と半導体メモリーカードが電気的に接続される。半導体メモリーカードに記録されたデータは半導体メモリーカードIFを介して読み出すように構成すれば良い。各実施形態で説明した再生装置は、本実施の形態で説明をしたデータに相応するデータ配信データを電子配信サービスの配信サーバから受信し、半導体メモリカードに記録する端末装置としても実現することができる。かかる端末装置は、各実施形態で説明した再生装置がそのような動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDカードを例に説明をする。再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバ図示せずへ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。一方、配信サーバでは、配信するデータのうち必要なデータ例えばビデオストリーム、オーディオストリーム等が暗号解読に必要な鍵例えばタイトルキーを用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。また、配信サーバは、暗号化されたデータの解読に必要な鍵タイトルキー自身に対して暗号化ができるように構成されているつまり暗号化タイトルキーを生成できるように構成されている。生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵例えばデバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキーが得られ、この得られた暗号解読に必要な鍵タイトルキーを用いて、暗号化されたデータの解読ができるものである。次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。受信した公開鍵情報は例えば公開鍵本体例えば上述のMKB及び暗号化タイトルキー、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。署名情報には例えば、公開鍵情報のハッシュ値を含む。デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能プログラムといったものを一意に特定するための情報である。半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。具体的には、1公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック2再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック3公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェックを行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。上述の1~3のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキーを用いて、暗号化されたデータの解読を行なう。例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵暗号化タイトルキーを復号して得られるタイトルキーを利用してビデオストリームを復号しデコードし、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号するデコードする。このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能プログラムなどが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報公開鍵本体を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の1の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域第1の記録領域と称すとは別の記録領域第2の記録領域と称すに設けること、およびこの第2の記録領域へのアクセスをするための制御回路を設けるとともに、第2の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。例えば、第2の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第2の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第2の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードIFを介して制御回路へ第2の記録領域に記録されたデータ例えば半導体メモリ固有の識別番号へのアクセス要求を発行すると、要求を受けた制御回路は第2の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第1の記録領域に記録するように構成すればよい。また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードIFを介して制御回路へ第2の記録領域に記録されたデータ例えば半導体メモリ固有の識別番号へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のX509仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。また、半導体メモリーカードの第1の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。システムLSI再生装置の内部構成のうち、システムターゲットデコーダや、再生制御部7、プログラム実行部11等、ロジック素子を中心とした部分は、システムLSIで構成することがことが望ましい。システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる。ここでパッケージの種別に着目するとシステムLSIには、QFP、PGAという種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置200の中核としての役割を果たす。かかるシステムLSIは、再生装置200は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。システムLSIのアーキテクチャは、Uniphierアーキテクチャに準拠させるのが望ましい。Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。データ並列プロセッサDPPこれは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。命令並列プロセッサIPPこれは、命令RAM、命令キャッシュ、データRAM、データキャッシュからなるLocalMemoryController、命令フェッチ部、デコーダ、実行ユニット、レジスタファイルからなるProcessingUnit部、複数アプリケーションの並列実行をProcessingUnit部に行わせるVirtualMultiProcessorUnit部で構成される。MPUブロックこれは、ARMコア、外部バスインターフェイス、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。ストリームIOブロックこれは、USBインターフェイスやATAPacketインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードリディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。AVIOブロックこれは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。メモリ制御ブロックこれは、外部バスを介して接続されたSDRAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSDRAMとのデータ転送を行うアクセス制御部、各ブロックからのSDRAMのアクセス要求を調整するアクセススケジュール部からなる。具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やICLSIを用いて、構成図における構成要素を具現化する。そうして、各構成要素を具現化してゆけば、回路素子やICLSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。こうして実装設計が行われ、基板上のレイアウトが確定すれば、実装設計結果をCAMデータに変換して、NC工作機械等の設備に出力する。NC工作機械は、このCAMデータを基に、SoC実装やSiP実装を行う。SoC実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置200の内部構成図を基に作ることができる。尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。FPGAを用いてシステムLSIを実現した場合は、多数のロジックエレメントが格子状に配置されており、LUTに記載されている入出力の組合せに基づき、縦横の配線をつなぐことにより、各実施形態に示したハードウェア構成を実現することができる。LUTは、SRAMに記憶されており、かかるSRAMの内容は、電源断により消滅するので、かかるFPGAの利用時には、コンフィグ情報の定義により、各実施形態に示したハードウェア構成を実現するLUTを、SRAMに書き込ませる必要がある。本実施の形態は、ミドルウェアとシステムLSIに対応するハードウェア、システムLSI以外のハードウェア、ミドルウェアに対するインターフェイスの部分、ミドルウェアとシステムLSIのインターフェイスの部分、ミドルウェアとシステムLSI以外の必要なハードウェアへのインターフェイスの部分、ユーザインターフェースの部分で実現し、これらを組み込んで再生装置を構成したとき、それぞれが連携して動作することにより特有の機能が提供されることになる。ミドルウェアに対するインターフェイス、および、ミドルウェアとシステムLSIのインターフェイスを適切に定義することにより、再生装置のユーザインターフェース部分、ミドルウェア部分、システムLSI部分をそれぞれ独立して並行開発することができ、より効率よく開発することが可能となる。なお、それぞれのインターフェイスのきり方には、様々な切り方がある。"