JP2012044687A

JP2012044687A - 受信装置、受信方法

Info

Publication number: JP2012044687A
Application number: JP2011217650A
Authority: JP
Inventors: Ko Ikeda; 航池田; Tomoteru Ogawa; 智輝小川
Original assignee: Panasonic Corp
Current assignee: Panasonic Corp
Priority date: 2008-09-30
Filing date: 2011-09-30
Publication date: 2012-03-01
Anticipated expiration: 2029-09-14
Also published as: US20120275765A1; JP2010233211A; WO2010038365A1; EP2395772A3; JP2010213267A; EP2395770A2; CN102355590B; BRPI0904620A2; US20120062711A1; KR20110074823A; CA2691727A1; JPWO2010038365A1; US20100208042A1; EP2355533A1; EP2482564A2; EP2395772A2; MX2010002097A; CN101911713A; JP4733772B2; JP4923162B2

Abstract

【課題】様々な視点からのビデオストリームをベースビューとして選択することができる送信装置、受信装置を提供する。
【解決手段】放送またはネットワークを経由して送信されるデータは、ビデオストリームと、ベースビュー指定情報とを含む。送信されるビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがある。ベースビュー指定情報は、ベースビュービデオストリームがライトビュービデオストリームとレフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時にレフトビュービデオストリーム及びライトビュービデオストリームのうちどちらのビデオストリームが再生されるかを示す。
【選択図】図２３

Description

本発明は、3D映像及び2D映像の記録技術の技術分野に属する発明である

2D映像とは、表示装置の表示画面をX-Y平面として捉えて、このX-Y平面上の画素にて表現される画像であり、平面視画像とも呼ばれる。
対照的に3D映像とは、表示装置の画面におけるX-Y平面上の画素に、Z軸方向の奥行きを加えた画像である。3D映像は、左目で視聴すべきレフトビュー映像と、右目で視聴すべきライトビュー映像とを共に再生して、これらレフトビュー映像、ライトビュー映像で立体視効果を発揮することにより、ユーザによる視聴に供される。3D映像における画素のうち、正のZ軸座標をもつものをユーザは、表示装置の画面より手前にあると感じ、負のZ軸座標をもつものを、画面より奥に存在すると感じる。

光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置（以下、「2D再生装置」と呼ぶ）との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3Ｄ映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの２種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置（以下、「2D/3D再生装置」）では、2D映像もしくは3D映像として再生できることが求められる。

3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献１に記載されたものがある。

特許第３９３５５０７号公報

立体視再生では、レフトビューのビデオストリーム、ライトビューのビデオストリームを記録媒体に記録して、ユーザに視聴させる必要があるが、これらレフトビュービデオストリーム、ライトビュービデオストリームをどのような形式に変換しておくかが問題になる。一般的な記録形式は、レフトビュービデオストリーム、ライトビュービデオストリームをTSパケットレベルで多重化して、１つのトランスポートストリームとして記録するというものであるが、これでは、レフトビュービデオストリーム、ライトビュービデオストリームに割り当てることができるビットレートが低下してしまう。そのため画質の低下が発生しかねない。

本発明の目的は、3D再生装置と、2D再生装置との双方で再生されることを保障することができる送信装置を提供することである。

上記課題を解決するため、本発明にかかる送信装置は、放送またはネットワークを経由してデータを送信する送信装置であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、
を示すことを特徴とする。

本発明では、レフトビュービデオストリーム、ライトビュービデオストリームのうち、何れをベースビュービデオストリームにするかをベースビュー指定情報によって設定することができるので、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することができ、複数視点の独立した圧縮に比べて圧縮効率を向上させることができる。

記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を表す動画像を描いた図である。立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。多層化された光ディスクの内部構成を示す。ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。記録方法の処理手順を示すフローチャートである。 PESパケット列に、ビデオストリームがどのように格納され、TSパケット及びソースパケットに変換されるかを示す。 AVクリップがどのように多重化されるかを模式的に示す図である。記録方法により得られたエクステントの内部構成を示す。エクステントと、トランスポートストリームファイルとの対応付けを示す図である。インターリーブ形式のトランスポートストリームファイルと、レフトビューのトランスポートストリームファイルとをカップリングする方法について示している。 AVファイル書込工程の処理手順を示すフローチャートである。クリップ情報ファイルの内部構成を示す図である。クリップ情報ファイルにおけるストリーム属性情報を示す図である。クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。エントリーマップによるエントリーポイントの登録を示す。 2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。図１７の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。プレイリスト情報のデータ構造を示す図である。サブパス情報テーブルの内部構成を示す図である。レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。ストリーム選択テーブルを示す。図１７の3Dプレイリストに、レフトビュー／ライトビュー識別情報を書き加えた図である。レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。 2D/3D再生装置の構成を示している。システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す図である。プレーン合成部５bの内部構成を示す図である。 PGプレーンの合成の仕方を示す図である。オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。レジスタセット１０の内部構成及び再生制御エンジン７bの内部構成を示す図である。出力モードの選択モデルの状態遷移を示す図である。 Initializationの処理手順を示すフローチャートである。 Procedure when playback condition is changedの処理手順を示すフローチャートである。ストリーム選択プロシージャの処理手順を示すフローチャートである。プレイリストの再生手順を示すフローチャートである。再生制御エンジンの状態が停止中から3Dプレイリストに切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。表示装置３００、3D眼鏡４００の内部構成を示す図である。 3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。左右のシャッターを切り替えるのではなく、２つの眼鏡のシャッターを切り替える場合の、マルチチャネルモードにおける表示内容と、レフトビューの状態と、ライトビューの状態とを示す。再生装置と、表示装置との接続態様を示す図である。左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。ビデオストリームとPGストリームとを組み合わせる場合の、組合せ情報の記述例である。ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。複数の3D方式を網羅できるPSRのビットアサインを示す図である。表示装置が対応している3D再生方式をプレーヤセッティングレジスタに反映させる図である。インデックステーブルと、ムービーオブジェクトとの関係を示している。ストリーム選択の処理手順を示すフローチャートである。記録装置の内部構成を示す図である。

(第１実施形態)
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目は、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。

具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。

まず、１つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。

２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。

図１（ａ）は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す図である。本図に示すように、記録媒体の一例であるBD-ROM１００、再生装置２００は、テレビ３００、3D眼鏡４００、リモコン５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
BD-ROM１００は、上記ホームシアターシステムに、例えば映画作品を供給する。

再生装置２００は、テレビ３００と接続され、BD-ROM１００を再生する。
テレビ３００は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置３００は、3D眼鏡４００をユーザが着用することで立体視を実現するものだが、表示装置３００がレンチキュラー方式のものなら、3D眼鏡４００は不要となる。レンチキュラー方式の表示装置３００は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。

3D眼鏡４００は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。図１（ｂ）は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡４００は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図（ｃ）は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。

リモコン５００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン５００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。

以上が、記録媒体及び再生装置の使用形態についての説明である。
本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。
視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図２は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。

視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。

図３は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。
本図の第２段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。これらのピクチャデータは、Decode Time Stamp(DTS)に従いデコードされる。第１段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。本図において、参照ピクチャを持たずに符号化対象ピクチャのみを用いてピクチャ内予測符号化を行うピクチャをIピクチャと呼ぶ。ピクチャとは、フレームおよびフィールドの両者を包含する１つの符号化の単位である。また、既に処理済の１枚のピクチャを参照してピクチャ間予測符号化するピクチャをPピクチャとよび、既に処理済みの２枚のピクチャを同時に参照してピクチャ間予測符号化するピクチャをBピクチャと呼び、Bピクチャの中で他のピクチャから参照されるピクチャをBrピクチャと呼ぶ。また、フレーム構造の場合のフレーム、フィールド構造のフィールドを、ここではビデオアクセスユニットと呼ぶ。

第４段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第３段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。

第５段目は、3D眼鏡４００の状態をどのように変化させるかを示す。この第５段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。

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

そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、“ディペンデントビューストリーム”という。

次に、記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。

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

ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。この一方、記録層の境界のように、連続的な読み出しが不可能な部分については、論理アドレスが連続していないものとする。

ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROM１００の場合ではUDF（Universal Disc Format）によって記録される。日常使っているPC（パーソナルコンピュータ）の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。

ファイルシステム上でアクセス可能なファイルのうち、ビデオストリーム及びオーディオストリームを多重化することで得られたAVストリームを格納しているファイルを“AVファイル”という。一方、AVストリーム以外の一般的なデータを格納しているファイルを“非AVファイル”という。
ビデオストリーム、オーディオストリームを始めとするPacktized Elementaryストリーム(PESストリーム)が、TSパケットに変換された上で多重化されているため、AVストリームがトランスポートストリーム形式になっているAVファイルを、「トランスポートストリームファイル」という。

これとは異なり、ビデオストリーム、オーディオストリームを始めとするPESストリームが、パック列に変換された上で多重化されているため、AVストリームがシステムストリーム形式になっているAVファイルを、「システムストリームファイル」という。
BD-ROM、BD-RE、BD-Rに記録されるAVファイルは、前者のトランスポートストリームファイルである。DVD-Video、DVD-RW,DVD-R,DVD-RAMに記録されるAVファイルは、後者のシステムストリームファイルであり、Video Objectとも呼ばれる。

第４段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第５段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。

図５は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図である。

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

「index.bdmv(ファイル名固定)」は、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BD-Jオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納している。インデックステーブルはBD-ROM全体に関する管理情報であり、再生装置へのディスク挿入後に、index.bdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルはBD-ROMに格納されるすべてのタイトル、トップメニュー、FirstPlayといったタイトル構成を定義する最上位層のテーブルである。インデックテーブルには、一般のタイトル、トップメニュータイトル、FirstPlayタイトルから最初に実行されるプログラムファイルが指定されている。BD-ROMの再生装置は、タイトルあるいはメニューが呼び出されるたびにインデックステーブルを参照して、所定のプログラムファイルを実行する。ここで、FirstPlayタイトルとは、コンテンツプロバイダによって設定されるもので、ディスク投入時に自動実行されるプログラムファイルが設定されている。また、トップメニュータイトルは、リモコンでのユーザ操作で、「メニューに戻る」というようなコマンドが実行されるときに、呼び出されるムービーオブジェクト、BD-Jオブジェクトが指定されている。立体視に関する情報としてIndex.bdmvは、Initial＿output＿mode情報を有する。このInitial＿output＿mode情報は、Index.bdmvがロードされた場合に、再生装置の出力モードの初期状態がどうあるべきかを規定する情報であり、制作者サイドが希望する出力モードを、このInitial＿output＿mode情報に規定しておくことができる。

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

「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo[“xxxxx”は可変、拡張子”bdjo”は固定])が存在する。このプログラムファイルは、バイトコードインタプリタであるJava（登録商標）仮想マシンを制御主体とした動作モード(BD-Jモード)において、再生装置が行うべき制御手順を規定するBDーJオブジェクトを格納している。このBDーJオブジェクトは、「アプリケーション管理テーブル」を含む。BD-Jオブジェクト内の「アプリケーション管理テーブル」は、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。アプリケーション管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定する『アプリケーション識別子』と、『制御コード』とを含む。アプリケーション管理テーブルにより生存区間が規定されるBD-Jアプリケーションを、特に『BD-Jアプリケーション』という。制御コードは、AutoRunに設定された場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、他のアプリケーションからのコールを待って、起動すべき旨を示す。一方、BD-Jアプリケーションの中には、タイトルが終了したとしても、その動作が終了しないアプリケーションがある。かかるアプリケーションを、“タイトルアンバウンダリアプリケーション”という。

このJava（登録商標）アプリケーションの実体にあたるのが、BDMVディレクトリ配下のJARディレクトリに格納されたJava（登録商標）アーカイブファイル(YYYYY.jar)である。アプリケーションは例えばJava（登録商標）アプリケーションであり、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。

「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls[“xxxxx”は可変、拡張子”mpls”は固定])が存在する。
“プレイリスト”とは、AVストリームの時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、複数のAVストリームのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報ファイルは、かかるプレイリストの“型”を定義するプレイリスト情報を格納している。再生制御のためのJava(登録商標)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(登録商標)仮想マシンに命じることで、AV再生を開始させることができる。JMF(Java Media Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。

「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi [“xxxxx”は可変、拡張子”clpi”は固定])が存在する。
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、トランスポートストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts([“xxxxx”は可変、拡張子”m2ts”は固定])という形式でトランスポートストリームファイルが格納される。

STREAMディレクトリにおけるトランスポートストリームファイルは、AVクリップを格納している。“AVクリップ”とは、AVストリームの“切れ端”のことであり、ビデオストリーム、オーディオストリーム、グラフィクスストリーム等、複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を可能するものをいう。AVクリップは、1秒,5秒,1分等、長短に拘らず、時間軸上において、ある限られた時間の再生を保障するものであれば足りる。

またAVクリップは、複数種別のPESストリームを管理・制御するための情報として、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)を具備している。
PCR(Program＃Clock＃Reference)は、ATSの時間軸であるATC（Arrival Time Clock）とPTS・DTSの時間軸であるSTC（System Time Clock）の同期を取るために、そのPCRパケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。

PMT(Program＿map＿table)は、トランスポートストリームファイル中に含まれる映像・音声・グラフィクスなどの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、またAVクリップに関する各種ディスクリプタを持つ。ディスクリプタにはトランスポートストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。

PMTの先頭には、そのPMTに含まれるデータの長さなどを記したPMTヘッダが配置される。その後ろには、AVクリップに関するディスクリプタが複数配置される。前述したコピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、トランスポートストリームファイルに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのPID、ストリームの属性情報（フレームレート、アスペクト比など）が記載されたストリームディスクリプタから構成される。ストリームディスクリプタはAVクリップに存在するストリームの数だけ存在する。

PAT（Program Association Table）は、AVクリップ中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルトランスポートストリームを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルトランスポートストリームを扱うかの如く、AVクリップをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、BD-ROM再生装置との互換性を意図したものである。

またAVクリップのうち、レフトビュービデオストリームの分割部分を格納したパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したパケット等、レフトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間のシームレスなAV再生を保障するものを、“レフトビューAVクリップ”という。このレフトビューAVクリップが、ベースビュービデオストリームを含んでおり平面視再生を可能とするものなら、当該レフトビューAVクリップは、“2D／レフトビューAVクリップ”と称呼される。尚以降の説明では、特に断らない限り、レフトビュービデオストリームがベースビュービデオストリームであり、レフトビュービデオストリームを含むレフトビューAVクリップは、2D/レフトビューAVクリップであるものとする。

更にAVクリップのうち、ライトビュービデオストリームの分割部分を格納したソースパケット、ライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したパケットの集合体であって、タイムスタンプが連続しており、ある一定期間の連続再生を保障するものを、“ライトビューAVクリップ”という。

CLIPINFディレクトリに格納されるクリップ情報ファイルとは、レフトビューAVクリップ又はライトビューAVクリップが、どのようなパケットの集合体であるか等、AVクリップの詳細を、個々のAVクリップ毎に示した情報であり、対応するAVクリップの再生に先立ちメモリに読み出され、そのAVクリップの再生が継続している間、再生装置内で参照に供される情報である。

以上が記録媒体の内部構成についての説明である。続いて、図４及び図５に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。

図６は、記録方法の処理手順を示すフローチャートである。
ステップS３０１は、BD-ROMのタイトル構造を決定する工程である。これによりタイトル構造情報が作成される。タイトル構造情報とは、木構造を用いて、BD-ROMにおける再生単位の関係、例えば、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する情報である。具体的にいうと、タイトル構造情報は、制作しようとするBD-ROMの「ディスク名」に対応するノード、そのBD-ROMにおいて、Index.bdmvから再生可能となる「タイトル」に対応するノード、そのタイトルを構成する「ムービーオブジェクト及びBD-Jオブジェクト」に対応するノード、当該ムービーオブジェクト及びBD-Jオブジェクトから再生される「プレイリスト」のノードを規定して、これらノードを、エッジ(辺)で結び付けることで、タイトル、ムービーオブジェクト、BD-Jオブジェクト、プレイリスト間の関係を規定する。

ステップS３０２は、タイトルに利用する動画、音声、静止画、字幕情報のインポートを行う工程である。
ステップＳ３０３は、GUIを経由したユーザ操作に従った編集処理をタイトル構造情報に施すことにより、BD-ROMシナリオデータを作成する工程である。ここでBD-ROMシナリオデータとは、AVストリームの再生にあたって、タイトル単位での再生を再生装置に行わせる情報であり、BD-ROMではインデックステーブル、ムービーオブジェクト、プレイリストとして定義されている情報がシナリオにあたる。BD-ROMシナリオデータには、ストリームを構成する素材情報、再生区間、再生経路を示す情報、メニュー画面配置、メニューからの遷移情報などを含む。

ステップS３０４は、エンコード工程であり、BD-ROMシナリオデータに基づきエンコードを行って、PESストリームを得る。
ステップS３０５は、BD-ROMシナリオデータに従った多重化工程であり、この工程によってPESストリームを多重化してAVクリップを得る。
ステップＳ３０６では、BD-ROMへの記録のためのデータベースを得る。ここでのデータベースとは、前述のBD-ROMで定義されるインデックステーブル、ムービーオブジェクト、プレイリスト、BD-Jオブジェクトなどの総称である。

ステップS３０７では、Java(登録商標)プログラム、多重化工程で得られたAVクリップ、BD-ROMデータベースを入力とし、BD-ROMに準拠したファイルシステムフォーマットでAVファイル,非AVファイルを作成する。
ステップＳ３０８は、BD-ROMに記録されるべきデータのうち、非AVファイルの書込工程であり、ステップＳ３０９は、AVファイルの書込工程である。

ステップＳ３０５の多重化工程は、ビデオストリーム、オーディオストリーム、グラフィクスストリームをPESストリームに変換した上、トランスポートストリームに変換する第１変換工程、トランスポートストリームを構成する個々のTSパケットを、ソースパケットに変換する第２変換工程を含み、動画像、音声、グラフィクスを構成するソースパケット列を、多重化するものである。

ステップＳ３０９のAVファイル書き込み工程は、ソースパケット列をAVファイルのエクステントとして、記録媒体の連続領域に書き込むものである。
書き込みの対象となるストリームは、以下の通りである。
・ビデオストリーム
ビデオストリームは映画のプライマリビデオおよびセカンダリビデオを示す。ここでプライマリビデオとはピクチャインピクチャにおいて親画像として表示される通常の映像を示し、セカンダリビデオとは、ピクチャインピクチャにおいて小画面で表示される映像のことである。プライマリビデオには、レフトビュービデオ、ライトビュービデオの２種類があり、セカンダリビデオにも、レフトビュービデオ、ライトビュービデオの２種類がある。

ビデオストリームは、上述したMVCの他、MPEG-２、MPEG-4AVC、または、SMPTE VC-１などの方式を使って符号化記録されている。
・オーディオストリーム
オーディオストリームは、映画の主音声部分を示す。オーディオストリームは、ドルビーAC-３、Dolby Digital Plus、MLP、DTS、DTS-HD、または、リニアPCMのなどの方式で圧縮・符号化記録されている。オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの２種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。

・Presentation Graphicsストリーム
Presentation Graphicsストリーム(PGストリーム)は、映画の字幕や、キャラクタ等、ピクチャと緻密に同期すべきグラフィクスを示すグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。
PGストリームは、PCS(Presentation Control Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(Object Define Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。

WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS(Pallet Define Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。

グラフィクスストリームの再生において、グラフィクスデコーダは、ある表示単位に属するODSをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行表示単位に属するODSをデコードすることにより得られたグラフィクスオブジェクトをプレーンメモリに書き込む処理とをパイプラインで実行し、ハードウェアをフル駆動することで、上述したような緻密な同期を実現する。

トランスポートストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。このPGストリームと、textSTストリームとの組みは、BD-ROM規格において、“PGTextSTストリーム”と呼ばれる。

・Interactive Graphicsストリーム
Interactive Graphicsストリーム(IGストリーム)は、リモコンを通じた対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(Interactive Composition Segment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)と呼ばれる機能セグメントからなる。ODS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(Interactive Composition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。インタラクティブグラフィックスストリームは、画面上にGUI部品を配置することにより作成される対話画面を示している。

図７（ａ）は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図における第１段目はビデオストリームのビデオフレーム列を示す。第２段目は、PESパケット列を示す。第３段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy１,yy２, yy３, yy４に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS（Presentation Time-Stamp）やピクチャの復号時刻であるDTS（Decoding Time-Stamp）が格納される。

＜TSパケット列＞
図７（ｂ）は、AVクリップに最終的に書き込まれるTSパケットの形式を示している。第１段目は、TSパケット列を示し、第２段目は、ソースパケット列を示す。

第１段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ４Byteの「TSヘッダ」とデータを格納する１８４Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第２段目によると、TSパケットには、４ByteのTP＿Extra＿Headerが付与されて、１９２Byteのソースパケットに変換された状態で、AVクリップに書き込まれる。TP＿Extra＿HeaderにはATS（Arrival＿Time＿Stamp）などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。AVクリップには、第３段目に示すようにソースパケットが並ぶこととなり、AVクリップの先頭からインクリメントする番号はSPN（ソースパケットナンバー）と呼ばれる。

＜AVクリップにおける多重化＞
図８は、レフトビューAVクリップがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを(第１段目)、それぞれPESパケット列に変換し(第２段目)、ソースパケット列に変換する(第３段目)。同じくレフトビュープレゼンテーショングラフィックスストリームおよびレフトビューインタラクティブグラフィックス(第７段目)を、それぞれPESパケット列に変換し(第６段目)、更にソースパケット列に変換する(第５段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、レフトビューAVクリップが得られることになる。このレフトビューAVクリップは、リードバッファがアンダーフローしないサイズに定められており、記録媒体への記録の対象になる。

Arrival Time Clock(ATC)時間軸において、ATSが連続しているソースパケットの集まりをATCシーケンスといい、System Time Clock(STC)時間軸においてデコードタイムスタンプ(DTS),プレゼンテーションタイムスタンプ(PTS)が連続しているソースパケットの集まりを、STCシーケンスという。
図９は、記録方法により得られたエクステントを示す。第１段目は、AVファイルを構成するエクステントEXT＿L[i],EXT＿L[i+1],EXT＿R[i],EXT＿R[i+1]を示す。

第２段目は、各エクステント内に属するソースパケット列を示す。
この第１段目におけるエクステントは、ライトビューAVクリップを構成するソースパケットのグループと、レフトビューAVクリップを構成するソースパケットのグループとを、インターリーブ配置したものである。本図におけるインターリーブ配置とは、ライトビューAVクリップを構成するソースパケット集合と、レフトビューAVクリップを構成するソースパケット集合とが、一個のエクステントとして、"ライトビュー"、"レフトビュー"、"ライトビュー"、"レフトビュー"・・・・・という規則性をもって記録されていることである。

ここで、括弧書きにおける変数i,i+1は、何番目のエクステントとして再生されるかを示す。この記法からすると、変数iによって指示される2つのエクステント、つまり、EXT＿L[i],EXT＿R[i]は同時に再生され、変数i+1によって指示される2つのエクステント、つまり、EXT＿L[i+1],EXT＿R[i+1]は同時に再生されることがわかる。
エクステントEXT＿L[i]のサイズをSEXT＿L[i]と呼び、エクステントEXT＿R[i]のサイズをSEXT＿R[i]と呼ぶ。

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

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

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

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

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

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

RB1≧Rmax1×[2×Tjump+RB2/(Rud-Rmax2)]

になる。

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

RB2≧Rmax2×[2×Tjump+RB1/(Rud-Rmax1)]

になる。

ライトビュー用リードバッファ,レフトビュー用リードバッファのメモリサイズの具体的な値としては、1.5Mbyte以下であり、本実施形態においてエクステントサイズSEXT＿R、SEXT＿Lは、このライトビュー用リードバッファ,レフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。以上がレフトビューAVクリップ、ライトビューAVクリップの記録のされ方についての説明である。続いて、レフトビューAVクリップ及びライトビューAVクリップの内部構成について説明する。図９の第１段目を参照しながら、エクステントEXT＿R[i]、エクステントEXT＿L[i]の内部構成について説明する。

エクステントEXT＿L[i]は、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはProgram_Mapを構成し、0x1001のパケットIDをを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケットはレフトビュービデオストリーム、
0x1220〜123FのパケットIDを有するソースパケットはレフトビューPGストリーム、
0x1420〜143FのパケットIDを有するソースパケットはレフトビューIGストリーム
0x1100から0x111FまでのPIDを有するソースパケットはオーディオストリームを構成する。

エクステントEXT＿R[i]は、以下のソースパケットによって構成されている。
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）を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位２ビットは、“０”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“１”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“０”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。

上述したようなファイルエントリーのアロケーション識別子を参照することで、プレイリスト情報ファイル、クリップ情報ファイル、トランスポートストリームファイル、BD-Jオブジェクトファイル、JARアーカイブファイルを構成するエクステントのアドレスを知得することができる。
本願の主眼となるトランスポートストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。

上述したようなAVストリーム、Index.bdmv、JARファイル、BD-Jオブジェクトは、ファイル構造、ディレクトリ構造に従ってBD-ROMに記録されているので、再生装置は、ファイルオープンのためのシステムコールを行うことで、これらをメモリに読み出すことができる。
ファイルオープンとは、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCB(File Control Block)を確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。そして、このファイルオープンにあたって、拡張子がm2tsのトランスポートストリームファイルは、STREAMディレクトリを用いたファイルパスによって特定される。拡張子がssifのトランスポートストリームファイルは、STEAMディレクトリと、SSIFディレクトリとを用いたファイルパスによって特定されることになる。これらは、STEAMディレクトリ、SSIFディレクトリに配置されているからである。

上述したようなファイル構造において、図９に示したエクステントがどのように取り扱われているかについて説明する。
図１０は、エクステントと、トランスポートストリームファイルとの対応付けを示す図である。
第１段目は、通常のトランスポートストリーム形式のトランスポートストリームファイルである00001.m2ts,00002.m2tsを示し、第２段目は、ライトビューのエクステント、レフトビューのエクステントを示す。第３段目は、インターリーブ形式のトランスポートストリームファイルである00001.ssifを示す。

破線の矢印h1,h2,h3,h4は、エクステントEXT＿R[i],EXT＿L[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT＿L[i],EXT＿L[i+1]は、00001.m2tsのエクステントとして登録されていることがわかる。
矢印h3,h4に示される帰属関係によると、エクステントEXT＿R[i],EXT＿R[i+1]は、00002.m2tsのエクステントとして登録されていることがわかる。

矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT＿R[i],EXT＿L[i],EXT＿R[i+1],EXT＿L[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT＿L[i],EXT＿L[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この“ssif”という拡張子は、StereoScopic Interleave Fileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。

図１１は、対応するレフトビューAVクリップと、ライトビューAVクリップとをカップリングする方法について示している。
同図は、トランスポートストリームファイルが、どのようなエクステントによって構成されているかを示す。
これらのうち、エクステントEXT＿L[i],EXT＿L[i+1]は、2D映像として再生されるものである。

3D映像を含むBD-ROMであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2DのAVクリップにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。

１つ目の方法は、レフトビューは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のトランスポートストリームファイルは拡張子を変える方法である。同図左下における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名“00001”によってカップリングされている。
プレイリストはレフトビューのAVクリップしか参照しないため、既存の2D再生装置では2D用のAVクリップしか再生しない。3D対応の再生装置は、プレイリストはレフトビューの入ったAVクリップしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のトランスポートストリームファイルであると判断して、レフトビューとライトビューとを出力する。

２つ目の方法は、フォルダを分ける方法である。レフトビューは既存のフォルダ名（例：STREAM）を持つフォルダ内に格納しておくが、拡張であるライトビューは、3D特有の名前を持つフォルダ（例：SSIF）に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照する際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、レフトビューとライトビューを関連づけることが可能となる。

３つ目の方法は、識別番号によるものである。レフトビューの識別番号が“００００１”である場合、ライトビューの識別番号は、このレフトビューの識別番号に“１”を加算した番号、つまり、“０００２”という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。この例ではレフトビューの識別番号に“１”を加算したものをライトビューの識別番号としたが、レフトビューの識別番号に、“１００００”を加算したものをライトビューの識別番号として採用してもよい。

この例では、既存の2D再生装置が再生する映像はレフトビューであるとして記載しているが、実際はどちらでもよく、また、プレイリスト内にどちらの映像が規定映像として再生されているか識別するための情報があってもよい。
カップリング方式を実現する場合には、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。

以上がAVクリップを格納したトランスポートストリームファイルについての説明である。続いて、上述したようなトランスポートストリームファイルをどのようにして記録媒体に記録するか、つまり、AVファイルをAVデータ領域に書き込むための工程（AVファイル書込工程）の詳細について説明する。
図１２は、AVファイル書込工程の処理手順を示すフローチャートである。

ステップＳ４０１において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップＳ４０２は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップＳ４０３〜ステップＳ４０８を実行する。確保し得ない場合は、ステップＳ４０９で例外処理をした後、記録方法を終了する。
ステップＳ４０３〜ステップＳ４０８は、ステップＳ４０７がNoと判定されるまで、ステップＳ４０３〜ステップＳ４０６、ステップＳ４０８の処理を繰り返すループを構成している。

ステップＳ４０３において、空きの連続セクタ領域にレフトビューAVクリップを構成するソースパケット列をSEXT＿L[i]だけ書き込み、ステップＳ４０４において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。
ステップＳ４０５において、空きの連続セクタ領域にライトビューAVクリップを構成するソースパケット列をSEXT＿R[i]だけ書き込み、ステップＳ４０６において、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。

ステップＳ４０７は、ループの終了条件を規定するものであり、ライトビューAVクリップ、レフトビューAVクリップに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップＳ４０８に移行して、ループを継続する。存在しなければ、ステップＳ４１０に移行する。
ステップＳ４０８は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップＳ４０３に移行し、存在しなければ、ステップＳ４０２まで戻る。

ステップＳ４１０では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップＳ４１１では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップＳ４１２では、レフトビューAVクリップ、ライトビューAVクリップのうち、ベースビュービデオストリームを含むもののエクステントの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップＳ４１２では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。

以上がAVファイル書込工程についての説明である。続いてクリップ情報ファイルについて説明する。
＜クリップ情報ファイル＞
図１３は、クリップ情報ファイルの内部構成を示す図である。クリップ情報ファイルは、本図に示すようにAVクリップの管理情報であり、AVクリップと１対１に対応している。引き出し線ch1は、クリップ情報ファイルの内部構成をクローズアップして示している。この引出線に示すように、クリップ情報ファイルは、「クリップ情報」と、「ストリーム属性情報」と、「エントリマップテーブル」と、「3Dメタデータ」とから構成される。

クリップ情報は、引出線ch2に示すように「システムレート」、「再生開始時間」、「再生終了時刻」から構成されている。システムレートはAVクリップを構成するTSパケットを、後述するシステムターゲットデコーダのPIDフィルタに転送するための最大転送レートを示す。AVクリップ中に含まれるATSの間隔はシステムレート以下になるように設定されている。再生開始時間はAVクリップの先頭のビデオフレームのPTSであり、再生終了時間はAVクリップの終端のビデオフレームのPTSに１フレーム分の再生間隔を足したものが設定される。

図１４は、クリップ情報ファイルにおけるストリーム属性情報を示す図である。
図中の引き出し線ah1は、ストリーム属性情報の内部構成をクローズアップして示している。
この引出線に示すように、PID＝0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性情報、PID＝0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性情報、PID＝0x1100、PID＝0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性情報、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性情報というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性情報に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。

図１５は、クリップ情報ファイルにおけるエントリーマップテーブルを示す図である。本図（ａ）は、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、『エントリマップヘッダ情報』、『エクステント開始タイプ』、『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』を含む。

『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。
『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。

『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』は、複数種別のソースパケットによって構成されるPESストリームのそれぞれについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報を“エントリポイント”と呼ぶ。また先頭を“０”として各エントリポイント毎にインクリメントした値をエントリポイントID（以下EP＿ID）と呼ぶ。このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するソースパケット位置を特定することが出来るようになる。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。また、エントリマップはAVクリップ内に多重化される各ビデオストリーム毎に作られ、PIDで管理される。

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

EP＿ID=2に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=3200と、PTS=360000との対応付けを示す。EP＿ID=3に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=4800と、PTS=450000との対応付けを示す。is＿angle＿changeフラグは、そのエントリーポイントから独立して復号することができるか否かを示すフラグである。ビデオストリームがMVC又はMPEG4-AVCで符号化されており、エントリーポイントにIDRピクチャが存在する場合、このフラグはオンに設定される。エントリーポイントにNon-IDRピクチャが存在する場合、このフラグはオフに設定される。

同図（ｂ）は、（ａ）に示したPID=1011のTSパケットに対応するエントリーポイント内の複数のエントリーポイントによって、どのソースパケットを指示されるかを示す。EP＿ID=0に対応するエントリーポイントは、SPN=3を指し示しており、このソースパケット番号をPTS=80000と対応付けている。EP＿ID=1に対応するエントリーポイントは、SPN=1500を指し示しており、このソースパケット番号をPTS=270000に対応付けている。

EP＿ID=2に対応するエントリーポイントは、SPN=3200のソースパケットを指し示しており、このソースパケット番号をPTS=360000に対応付けている。EP＿ID=3に対応するエントリーポイントは、SPN=4800のソースパケットを指し示しおり、このソースパケット番号をPTS=450000と対応付けている。
図１６は、エントリーマップによるエントリーポイントの登録を示す。第１段目は、STCシーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうちSPN＝n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける＝n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち＝n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおける＝n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するAVクリップのファイル位置を特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。

以上がエントリーマップテーブルについての説明である。続いて、3Dメタデータの詳細について説明する。
3Dメタデータとは、立体視再生に必要となる様々な情報を規定したメタデータ群であり、複数のオフセットエントリーを含む。個々のオフセットエントリーは、複数のPID、複数の表示時刻に対応付けられている。そしてあるPIDのPESストリームを再生する際、そのPESストリームの複数の表示時刻において、どれだけのオフセットを用いて、立体視を実現すべきかをPID毎及び表示時刻毎に規定できるようになっている。

以上がクリップ情報ファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
デコーダや表示プレーンの構成が異なるため、2D再生、3D再生の切り替えをシームレスに行うことは困難である。そのため、シームレスな切り替えが発生する可能性があるプレイアイテム同士において、2Dと3Dの切り替えを行うことは難しい。

図１７は、2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す。混在をなくすことにより、再生装置の再生環境の切り替えを発生させないようにしている。本図のプレイリストは、「メインパス」、1つ以上の「サブパス」から構成される。
「メインパス」は、1つ以上のプレイアイテムから構成される。図中の例では、プレイアイテム＃1、＃2、＃3から構成されていることがわかる。

「サブパス」は、メインパスと一緒に再生される一連の再生経路を示し、プレイリストに登録される順にID(サブパスID)が振られる。サブパスIDは、サブパスを識別するために使われる。サブパスには、メインパスの再生に同期して再生される同期型、メインパスの再生に非同期で再生可能な非同期型があり、そのタイプはサブパスタイプに記される。サブプレイアイテムは、1つ以上のサブプレイアイテム情報から構成される。

また「プレイアイテム」は、ストリーム選択テーブルを含む。ストリーム選択テーブルは、プレイアイテム及びサブプレイアイテムにおいて再生が許可されているエレメンタリストリームのストリーム番号を示す情報である。プレイリスト情報、プレイアイテム情報、サブプレイアイテム情報、ストリーム選択テーブルの詳細については、後の実施形態に説明の場を譲る。

「AVクリップ＃1,＃2,＃3」は、2D映像として再生されるAVクリップであるとともに、3D映像として再生する時にはレフトビューとして再生されるAVクリップである。
「AVクリップ＃4,＃5,＃6」は3D映像として再生する時にはライトビューとして再生されるAVクリップである。
2Dプレイリストのメインパスは、レフトビューAVクリップを格納するAVクリップ＃1,＃2,＃3を符号rf1,2,3に示すように参照している。

3Dプレイリストは、レフトビューAVクリップを符号rf4,rf5,rf6に示すように参照しているプレイアイテムを含むメインパスとともに、ライトビューを参照するためのサブパスが用意されていて、このサブパスが、ライトビューを格納するAVクリップ＃4,＃5,＃6を、符号rf7,8,9に示すように参照している。このサブパスは、メインパスと時間軸上で同期するように設定される。この構造により、2Dプレイリストと3Dプレイリストで、レフトビューが格納されたAVクリップを共有することができ、3Dプレイリストではレフトビューとライトビューを時間軸上で同期させて関連付けることができる。

本図の3Dプレイリスト、2Dプレイリストは何れもプレイアイテム情報＃1〜＃3が、共通のAVクリップであるAVクリップ＃1〜＃3を参照しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。

図１８は、図１７の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図１７のプレイリストは、サブパスID=0のサブパスのみを具備していたのに対して、図１８のプレイリストにおける2つ目のサブパスは、サブパスID”=1”によって識別されるものであり、AVクリップ＃7、＃8、＃９を参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、AVクリップ群がその角度の数だけ用意されていて、角度ごとにサブパスを設けている。

図１８の例では、AVクリップ＃1,＃2,＃3とAVクリップ＃4,＃5,＃6は共にライトビューを格納しているが、右目から被写体を見る角度が異なる。サブパスIDが「０」のサブパスはAVクリップ＃4,＃5,＃6を符号rf7,8,9に示すように参照し、サブパスIDが「１」のサブパスはAVクリップ＃7,＃8,＃9を符号rf10,rf11,rf12に示すように参照する。表示装置の画面の大きさやユーザからの嗜好に基づいて、レフトビューを格納するメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。

この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図１８の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。

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

以降、『STN＿table』、『レフトビュー／ライトビュー識別情報』、『multi＿clip＿entry』について説明する。
『STN＿table(STream Number＿table)』は、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN＿tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。このSTN＿tableは、2D再生のためのものであり、3D再生のためのSTN＿tableは別に存在する。

『レフトビュー／ライトビュー識別情報』は、レフトビュービデオストリーム、ライトビュービデオストリームのうち、どちらかベースビュービデオストリームであるかを指定するベースビュービデオストリーム指定情報であり、0ならばレフトビュービデオストリームが、ベースビュービデオストリームであることを示し、1ならばベースビュービデオストリームがライトビュービデオストリームであることを示す。

『connection＿condition』は、前方プレイアイテムと接続タイプを示している。プレイアイテムのconnection＿conditionが「１」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレス接続が保証されないことを示す。プレイアイテムのconnection＿conditionが「５」か「６」の場合は、プレイアイテムが指し示すAVクリップは、そのプレイアイテムの前のプレイアイテムが指し示すAVクリップとシームレスに接続されることが保証される。

connection＿conditionが「５」の場合は、プレイアイテム間でSTCの連続性が途切れていても良く、つまり、接続前プレイアイテムのAVクリップ終端のビデオ表示時刻よりも、接続後プレイアイテムのAVクリップ先頭のビデオ表示時刻開始時刻は不連続でよい。ただし、接続前プレイアイテムのAVクリップを後述するシステムターゲットデコーダのPIDフィルタに入力した後に続けて、接続後プレイアイテムのAVクリップをシステムターゲットデコーダのPIDフィルタに入力して再生したときに、システムターゲットデコーダのデコードが破綻しないようにAVクリップを作成する必要がある。また接続前プレイアイテムのAVクリップのオーディオの終端フレームと、接続後プレイアイテムのオーディオの先頭フレームは再生時間軸で重ならなければならないなどの制約条件がある。

また、connection＿conditionが「６」の場合は、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップを結合したときに１本のAVクリップとして再生できなければならない。つまり、接続前プレイアイテムのAVクリップと接続後プレイアイテムのAVクリップ間でSTCは連続し、またATCも連続する。
『Multi＿clip＿entries』は、プレイアイテムでマルチアングル区間を形成する場合、個々のアングル映像を表すAVクリップがどれであるかを特定するための情報である。

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

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

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

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

以上がサブパス情報についての説明である。続いて、エントリーマーク情報の詳細について説明する。
エントリマーク情報はプレイアイテムで定義される再生区間内に対して付与することでき、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマークをチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。

以上がエントリーマーク情報についての説明である。続いて、エクステンションデータの詳細について説明する。
エクステンションデータは、2Dプレイリストとは互換がない、3Dプレイリスト特有の拡張部分であり、ここにSTN＿table＿SS＃1〜＃Nが格納される。STN＿table＿SSは、それぞれが複数のプレイアイテム情報のそれぞれに対応していて、3D再生用のストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN＿table＿SSにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。プレイアイテム情報内のSTN＿tableと、エクステンションデータ内のSTN＿table＿SSとを組合せることで、ストリーム選択テーブルが構成されることになる。

続いて、上述したPlayItem情報の内部構成のうち、ストリーム選択テーブルの詳細について説明する。
図２２（ａ）は、ストリーム選択テーブルを示す。ストリーム選択テーブルは、複数のストリームエントリから構成される。このストリームエントリーは、図中の括弧記号“｝”に示すように、STN＿table内で定義されるものと、STN＿table＿SS内で定義されるものとがある。

STN＿tableのストリームエントリーには、2D出力モードの設定時において、再生可能となる2D用の音声/PG/IGが登録される。そのため、STN＿tableの中には、2Dビデオストリームエントリー群、2Dオーディオストリームエントリー群、2DPGストリームエントリー群、2DIGストリームエントリー群が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。

STN＿table＿SSのストリームエントリーには、立体視再生モードの設定時において、再生可能となる3D用の音声/PG/IGが登録される。そのため、STN＿table＿SSの中には、3Dビデオストリームエントリー群、3Dオーディオストリームエントリー群、3DPGストリームエントリー群、3DIGストリームエントリー群、ストリーム組合せ情報が存在しており、これらのストリームエントリー群の中に、ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのパケット識別子を記述することができる。

同図（ｂ）は、ストリームエントリーの共通構成を示す図である。本図に示すように、ストリーム選択テーブルにおけるストリームエントリは、『ストリーム選択番号』、『ストリームパス情報』、『ストリーム識別情報』から構成される。
『ストリーム選択番号』は、ストリーム選択テーブルに含まれるストリームエントリ１の先頭から順にインクリメントされる番号であり、再生装置でのストリーム識別のために利用される。

『ストリームパス情報』は、ストリーム識別情報によって示されるストリームが、どのAVクリップに多重化されているかを示す情報であり、例えば”メインパス”であれば、該当するプレイアイテムのAVクリップを示し、”サブパスID=１”であれば、そのサブパスIDが示すサブパスにおいて、該当するプレイアイテムの再生区間に対応するサブプレイアイテムのAVクリップを示す。

『ストリーム識別情報』は、PIDなどの情報であり、参照するAVクリップに多重化されているストリームを示す。また、ストリームエントリには、各ストリームの属性情報も同時に記録されている。ここで属性情報とは、各ストリームの性質を示す情報で、例えばオーディオ、プレゼンテーショングラフィックス、インタラクティブグラフィックスの場合には、言語属性などが含まれる。

STN＿table＿SSにおいて、レフトビュービデオストリームのストリームエントリとライトビュービデオストリームのストリームエントリとでは、例えばフレームレートや解像度、ビデオフォーマットなどは同じ値になる。ストリームエントリには、レフトビュービデオストリームなのか、ライトビュービデオストリームなのかが分かるフラグが用意されることがある。

以上がストリーム選択テーブルについての説明である。続いて、レフトビュー／ライトビュー識別情報の詳細について説明する。
ここまでの記載は、レフトビュー用をメインとし、2D表示の場合はレフトビューが表示されることを前提に説明しているが、ライトビューがメインでもよい。プレイリストに左目/ライトビューのどちらがメインであるか、2Dの場合に表示されるかを判別する情報に従い、ベースビュービデオストリームであるものとする。その判別の情報が、レフトビュー／ライトビュー識別情報である。

一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すレフトビュー／ライトビュー識別情報をプレイアイテム情報毎に設定できるようにしている。

図２３は、図１７の3Dプレイリストに、レフトビュー／ライトビュー識別情報を書き加えた図である。この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。

各ストリームとレフトビュー/ライトビューの識別情報は、表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。

また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。
以上がレフトビュー／ライトビュー識別情報についての説明である。このレフトビュー／ライトビュー識別情報は、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。しかし視差画像の内容によっては、このように平面視画像として利用することに向いていないことがある。

以下、平面視画像として利用することに不向きなレフトビュー画像、ライトビュー画像について説明する。
図２４は、レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す。図中の右下は、映像中の恐竜が、ユーザの目の前にまで迫ってくるような画面効果を狙っている立体視画像を示す。この立体視画像は、その上に記載されているような、Ｌ画像、Ｒ画像によって構成される。飛び出し効果が大きい立体視画像を構成するＬ画像、Ｒ画像は、飛び出して現れる画像中の対象(本図では恐竜)を、側面から表示するようになっている。これらのうち、レフトビュービデオストリームを、平面視用のビデオストリームとして使用する場合、横長の物体が横たわっているように見えてしまい、おかしなものになる。そこで、2Dモードに設定されている場合、センター画像を表すビデオストリームを指定する、プレイリスト情報をカレントプレイリストとして選ぶようにする。

本図において、00005.mplsは、飛び出し度合が大きいレフトビュービデオストリーム、及び、ライトビュービデオストリームを、メインパス情報及びサブパス情報として指定している。
00003.mplsは、センター画像のビデオストリームをメインパスによって指定している。そして本図左上のムービーオブジェクトは、再生装置における3D再生のケーパビリティ(3D-Capability)に応じて、00005.mpls、00003.mplsのうち、どちらかを選択して再生するよう記述されている(図中のif文)。

以上が記録媒体の実施行為及び記録方法の実施行為についての説明である。続いて、再生装置の詳細について説明する。
図２５は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BD-ROMドライブ１、リードバッファ２a、リードバッファ２b、スイッチ３、システムターゲットデコーダ４、プレーンメモリセット５a、プレーン合成部５b、HDMI送受信部６、再生制御部７、管理情報メモリ９、レジスタセット１０、プログラム実行部１１、プログラムメモリ１２、HDMVモジュール１３、BD-Jプラットフォーム１４、ミドルウェア１５、モード管理モジュール１６、ユーザイベント処理部１７、ローカルストレージ１８、不揮発メモリ１９から構成されている。

BD-ROMドライブ１は、2D再生装置と同様に再生制御部７からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ２aかリードバッファ２bに転送される。
3D映像を再生する際には、再生制御部７からは2D/レフトビューAVクリップとライトビューAVクリップとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BD-ROMドライブ１は、2D/レフトビューAVクリップを構成するエクステントをリードバッファ２aに読み出し、ライトビューAVクリップを構成するエクステントをリードバッファ２bに読み出す。3D映像を再生する際には、2D/レフトビューAVクリップとライトビューAVクリップの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。

リードバッファ２aは、BD-ROMドライブ１が読み込んだ2D/レフトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ２bは、BD-ROMドライブ１が読み込んだライトビューAVクリップのデータを格納するデュアルポートメモリ等で構成されたバッファである。
スイッチ３は、リードバッファに対するデータ入力源を、BD-ROMドライブ１又はローカルストレージ１８の何れかに切り替えるためのスイッチである。

システムターゲットデコーダ４は、リードバッファ２aに読み出されたソースパケットとリードバッファ２bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。
プレーンメモリセット５aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、インタラクティブグラフィックスプレーン（IGプレーン）、プレゼンテーショングラフィックスプレーン（PGプレーン）といったものがある。

プレーン合成部５bは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンを瞬時に重畳し、TVなどの画面に表示する。この表示にあたってプレーン合成部５bは、セカンダリビデオプレーン、PGプレーン、IGプレーンを3Dメタデータを使って左目用と右目用とに交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンと合成する。合成後の映像は、GFXプレーンの重畳処理に転送される。

プレーン合成部５bは、IGプレーンにおけるグラフィクスをAPIから指定されたオフセット情報を使って左目と右目用に交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンとセカンダリビデオプレーンとPGプレーンとIGプレーンとが重畳されたイメージを、テレビに出力する。
テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。

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

再生制御部７は、再生エンジン７a、再生制御エンジン７bを含み、3Dプレイリストの再生がプログラム実行部１１などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムの2D/レフトビューAVクリップを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのライトビューAVクリップを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点から2D/レフトビューAVクリップのエクステントと、ライトビューAVクリップのエクステントとを交互に読み出すようにBD-ROMドライブ１に要求する。再生開始するときには、最初のエクステントをリードバッファ２aか、リードバッファ２bに読みきった後に、リードバッファ２aとリードバッファ２bからシステムターゲットデコーダ４に転送を開始する。また、再生制御部７は、3Dプレイリストを再生する場合は、2D/レフトビューAVクリップに対応するクリップ情報ファイルに含まれる3Dメタデータをプレーン合成部５に通知する。

再生エンジン７aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。

再生制御エンジン７bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJava（登録商標）プラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。

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

再生状態／設定レジスタ(Player Status/Setting Register)セット１０は、プレイリストの再生状態を格納する再生状態レジスタ、再生装置におけるコンフィグレーションを示すコンフィグレーション情報を格納する再生設定レジスタ、コンテンツが利用する任意の情報を格納できる汎用レジスタを含む、レジスタの集まりである。プレイリストの再生状態とは、プレイリストに記載されている各種AVデータ情報の中のどのAVデータを利用しているか、プレイリストのどの位置（時刻）を再生しているかなどの状態を現す。

プレイリストの再生状態が変化した際は、再生制御エンジン７bがレジスタセット１０に対し、その内容を格納する。また、HDMVモードの動作主体であるコマンドインタプリタもしくはBD-Jモードの動作主体であるJava（登録商標）プラットフォームが実行しているアプリケーションからの指示により、アプリケーションが指定した値を格納したり、格納された値をアプリケーションに渡したりすることが可能である。

プログラム実行部１１は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。（１）再生制御部７に対してプレイリスト再生を命令する。（２）システムターゲットデコーダに対してメニューやゲームのグラフィックスのためのPNG・JPEGを転送して画面に表示する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBD-Jアプリケーションのプログラミング工程によって決まる。

プログラムメモリ１２は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BD-Jモードの動作主体であるJava（登録商標）プラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。またプログラムメモリ１２は、ヒープメモリを含む。

ヒープメモリは、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である
HDMVモジュール１３は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。

BD-Jプラットフォーム１４は、BD-Jモードの動作主体であるJava（登録商標）プラットフォームであり、Java2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsとをフル実装しており、クラスローダ、バイトコードインタプリタ、アプリケーションマネージャから構成される。

クラスローダは、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、BD-Jアプリケーションのロードを行う。
バイトコードインタプリタは、いわゆるJava（登録商標）仮想マシンであり、ヒープメモリに格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。

アプリケーションマネージャは、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。以上で、BD-Jプラットフォーム部の内部構成についての説明を終える。

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

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

ユーザイベント処理部１７は、リモコンを通じたユーザ操作に応答して、プログラム実行部１６や再生制御部７に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部１６に依頼する。例えば、リモコンで早送り・巻戻しボタンが押された場合には、再生制御部７に、現在再生しているプレイリストのAVクリップに対する早送り・巻戻し処理の実行を命令する。

ローカルストレージ１８は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。

不揮発メモリ１９は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット１０における記憶内容のバックアップに用いられる。
次に、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成について説明する。図２６は、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す図である。本図に示すように、システムターゲットデコーダ４及びプレーンメモリセット５aは、ATCカウンタ２１、ソースデパケッタイザ２２、PIDフィルタ２３、STCカウンタ２４、ATCカウンタ２５、ソースデパケッタイザ２６、PIDフィルタ２７、プライマリビデオデコーダ３１、レフトビュービデオプレーン３２、ライトビュービデオプレーン３３、セカンダリビデオデコーダ３４、セカンダリビデオプレーン３５、PGデコーダ３６、PGプレーン３７、IGデコーダ３８、IGプレーン３９、プライマリオーディオデコーダ４０、セカンダリオーディオデコーダ４１、ミキサー４２、レンダリングエンジン４３、GFXプレーン４４から構成される。

ATCカウンタ２１は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケッタイザ２２は、リードバッファ２aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。

PIDフィルタ２３は、ソースデパケッタイザ２２から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダ３１、セカンダリビデオデコーダ３４、IGデコーダ３８、PGデコーダ３６、プライマリオーディオデコーダ４０、セカンダリオーディオデコーダ４１に転送する。

STCカウンタ２４は、System Time Clock(STC)を生成し各デコーダの動作タイミングを調整する。
ATCカウンタ２５は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。
ソースデパケッタイザ２６は、リードバッファ２abにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。

PIDフィルタ２７は、ソースデパケッタイザ２６から出力されたTSパケットのうち、TSパケットのPIDが、カレントプレイアイテムのストリーム選択テーブルに記載されたPIDに一致するものを、PIDにしたがって、プライマリビデオデコーダに転送する。
プライマリビデオデコーダ３１は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン３２に書き込む。

レフトビュービデオプレーン３２は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
ライトビュービデオプレーン３３は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
セカンダリビデオデコーダ３４は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻（PTS）のタイミングでピクチャをセカンダリビデオプレーンに書き出す。

セカンダリビデオプレーン３５は、システムターゲットデコーダ４からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
PGデコーダ３６は、ソースデパケタイザから入力される複数のTSパケットからプレゼンテーショングラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスデータを表示時刻（PTS）のタイミングでPGプレーンに書き出す。

PGプレーン３７には、プレゼンテーショングラフィックスストリームをデコードすることで得られた非圧縮のグラフィックスオブジェクトが格納される。
IGデコーダ３８は、ソースパケタイザから入力される複数のTSパケットからインタラクティブグラフィックスストリームを抽出してデコードし、非圧縮のグラフィックスオブジェクトを表示時刻（PTS）のタイミングでIGプレーンに書き出す。

IGプレーン３９には、インタラクティブグラフィックスストリームをデコードすることで得られたグラフィックスデータが格納される。
プライマリオーディオデコーダ４０は、プライマリオーディオストリームをデコードする。
セカンダリオーディオデコーダ４１は、セカンダリオーディオストリームをデコードする。

ミキサー４２は、プライマリオーディオデコーダ４０のデコード結果と、セカンダリオーディオデコーダ４１のデコード結果とを合成する。
レンダリングエンジン４３は、JPEG，PNGなど、BD-Jアプリケーションがメニュー描画に利用するグラフィックスデータをデコードする。
GFXプレーン４４は、JPEG，PNGなどのグラフィックスデータがデコードされた後、書き込まれるプレーンメモリである。

次にプライマリビデオデコーダ３１の内部構成について説明する。プライマリビデオデコーダ３１は、TB５１、MB５２、EB５３、TB５４、MB５５、EB５６、ビデオデコーダ５７、バッファスイッチ５８、DPB５９、ピクチャスイッチ６０から構成される。
Transport Buffer(TB)５１は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ２３から出力された際、TSパケットのまま一旦蓄積されるバッファである。

Multiplexed Buffer(MB)５２は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
Elementaly Buffer(EB)５３は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。

Transport Buffer(TB)５４は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)５５は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。

Elementaly Buffer(EB)５６は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
ビデオデコーダ５７は、ビデオエレメンタリストリームの個々のビデオアクセスユニットを所定の復号時刻（DTS）でデコードすることによりフレーム/フィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG２、MPEG４AVC、VC１などがあるため、ストリームの属性に応じて、ビデオデコーダ５７のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ５７は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ５７は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ５７は、デコードされたフレーム/フィールド画像をDPB５９に転送し、表示時刻（PTS）のタイミングで対応するフレーム/フィールド画像をピクチャスイッチに転送する。

バッファスイッチ５８は、ビデオデコーダ５７がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB５３、EB５６のどちらから引き抜くかを決定し、EB５３と、EB５６とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻（DTS）のタイミングでビデオデコーダ５７に転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ５７に転送するのが望ましい。

Decoded PIcture Buffer(DPB)５９は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ５７が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。
ピクチャスイッチ６０は、ビデオデコーダ５７から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。

図２７は、プレーン合成部の内部構成を示す図である。3Dメタデータに基づき、プレーンに格納されている非圧縮ピクチャデータ、グラフィクスデータをクロッピングするクロッピング部６１a,b,cと、プログラムAPIに基づきプレーンに格納されている非圧縮グラフィクスデータをクロッピングするクロッピング部６１dと、出力内容をレフトビュービデオプレーンと、ライトビュービデオプレーンとで切り替えるスイッチ６２と、プレーン同士の合成を行う加算部６３、６４、６５、６６とから構成される。

プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ４よりPTSのタイミングで映像データが書き出される。プレーン合成部５bは、レフトビュービデオプレーンとライトビュービデオプレーンのうち、PTSのタイミングで映像データが書き出されたほうのプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送される。

これらのプレーンメモリのそれぞれは、レフトビューと、ライトビューとでそれぞれ異なる内容が格納されることで立体視の実現が可能になる。しかし、レフトビューにおける格納内容と、ライトビューにおける格納内容とが同じであっても、プレーンメモリにおける画素の座標を、レフトビューと、ライトビューとでそれぞれ変化させれば擬似的な立体視を実現することができる。上述したようなプレーンメモリのうちPGプレーンは、プレーンメモリにおける画素の座標を変化させることで、立体視を実現している。以下、PGプレーンにおける立体視の実現の仕方について説明する。

図２８は、PGプレーンの合成の仕方を示す図である。
プレーン合成の仕方を図２８のPGプレーンの例を用いて説明する。プレーン合成部５は、3Dメタデータ内に存在するオフセットエントリーのうち、現在再生されているプレゼンテーショングラフィックスのPIDに対応するものの中から、現在の表示時刻に対応するオフセット値を取得する。そして、プレーン合成部５は、重畳する映像プレーンがレフトビュービデオプレーンの場合はPGプレーンに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後、他のプレーンとの合成に供する（図２８上段参照）。

プレーン合成部５bは、重畳する映像プレーンがライトビュービデオプレーンの場合は、PGプレーンをオフセット値だけX軸の負の方向をずらし、レフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後に重畳する（図２８下段参照）。IGプレーン、セカンダリビデオプレーンも同様に処理を行う。
図２９は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクロッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。

以上がプレーン合成についての説明である。続いて、レジスタセット１０の内部構成及び再生制御エンジン７bの詳細について説明する。
図３０は、レジスタセット１０の内部構成及び再生制御エンジン７bの内部構成を示す図である。
本図の左側にはレジスタセット１０の内部構成を示している。右側には再生制御エンジン７bの内部構成を示している。

PSRに格納されているこれらの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって適宜参照され、またムービーオブジェクト及びBD-Jアプリケーションによる更新を受ける。このようにPSRの格納値は、ムービーオブジェクト及びBD-Jアプリケーションによって参照されるパラメータであるから、システムパラメータとも呼ばれる。
始めに、PSRのうち、代表的なものについて説明する。

PSR1は、オーディオストリームのためのストリーム番号レジスタであり、カレントのオーディオストリーム番号を格納する。
PSR2は、PGストリームのためのストリーム番号レジスタであり、カレントのPGストリーム番号を格納する。
PSR4は、1〜100の値に設定されることで、カレントのタイトル番号を示す。

PSR5は、1〜999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、カレントプレイリストの番号を示す。
PSR7は、0〜255の値に設定されることで、カレントプレイアイテムの番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM)を示す。以上がPSRについての説明である。

PSR10は、IGストリームのためのストリーム番号レジスタであり、カレントのIGストリーム番号を格納する。
PSR21は、ユーザが、立体視再生を実行することを意図しているかどうかを示す。
PSR22は、出力モード値を示す。
PSR23は、“Display Capability for video”の設定である。これは、再生装置の接続相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。

PSR24は、“Player Capability for 3D”の設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。
一方、再生制御エンジン７bの内部には、レジスタセット１０におけるPSR4,PSR6,PSR21,PSR23,PSR24と、管理情報メモリ９におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部８を備えている。PSR24におけるPlayer Capability for 3Dは、再生装置の3D再生に関する能力全般を意味するものなので、“3D-Capability”と簡単に表記する場合がある。

PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図３１に示すように規定されている。
図３１は、出力モードの選択モデルの状態遷移を示す図である。この選択モデルには、2つの一般的な状態が存在する。楕円は、この一般的な状態、つまり、出力モード値がとりうる値である“Invalid”,“valid”を模式的に描いたものである。Invalidは出力モードが無効であり、Validは出力モードが有効である旨を示す。

一般的な状態は、状態遷移が起こらない限り、維持される。状態遷移は、プレイリスト再生の開始、ナビゲーションコマンドやBD-Jアプリケーションにより要求された出力モード変化、BD-Jタイトルへのジャンプがある。状態遷移が発生した際、好ましい出力モードを獲得するためのプロシージャが実行される。
図中の矢印jm1,jm2,jm3・・・・jm12は、状態遷移のトリガとなる事象を模式的に示す。本図における状態遷移には、以下のものがある。

『Load a disc』とは、BD-ROMが装填されたという状態を意味する。
『Start Presentation』とは、HDMVモードにおいて、プレイリストの再生開始(start Playlist playback)を意味する。BD-Jモードにおいては、BD-Jタイトルへの分岐を意味する。何故なら、BD-Jモードにおいては、BD-Jタイトルに分岐した場合、必ずしも、プレイリストの再生が開始されるとは限らないからである。
『Jump to BD-J title』は、BD-Jタイトルへの分岐を意味する。具体的には、インデックステーブルにおいて、BD-Jアプリケーションに対応付けられたタイトル(BD-Jタイトル)がカレントタイトルになることをいう。

『Start Playlist Playback』は、何等かのプレイリストを意味するプレイリスト番号が、PSRに設定されて、プレイリスト情報が、カレントプレイリスト情報としてメモリに読み出されることをいう。
『Change Output Mode』とは、BD-JアプリケーションがAPIをコールすることで、出力モードを変化することをいう。
『Terminate presentation』とは、HDMVモードの場合は、プレイリストの再生が終了することをいい、BD-Jモードの場合は、BD-Jタイトルからインデックステーブルにおいてムービーオブジェクトに対応付けられたタイトル(HDMVタイトル)へとジャンプすることをいう。

ディスクがロードされた際、出力モードの状態は、一時的な状態“Initialization”に遷移る。出力モードセレクションの状態は、一時的に“Initialization state”に遷移した後、invalid stateに遷移する。
Output Mode Selectionの状態は、再生開始(Start Presentation)がアクティブになるまで、Invalidに維持される。HDMVモードにおいて“Start Presentation”は、プレイリストの再生が開始されたことを意味する。BD-JモードにおいてStart Presentation”は、BD-Jタイトルの再生が開始され、BD-Jアプリケーションが何等かの動作を開始したことを意味する。必ずしも、プレイリストの再生が開始されたことを意味するとは限らない。

Start Presentationがアクティブになった際、出力モードは、一時的な状態である“Procedure when playback condition is changed”に遷移する。
出力モードは、Procedure when playback condition is changedの結果に従ってValidに遷移する。出力モードが有効であって、Start Presentationが終了すれば、状態はInvalidに遷移する。

ムービーオブジェクトにおけるナビゲーションコマンドは、コンテンツプロバイダが好ましい出力モードに設定するために、プレイリスト再生の開始に先立ち、実行されねばならない。ムービーオブジェクトにおけるナビゲーションコマンドが実行された際、このモデルでは、Invalidになる。
図３２は、Initializationの処理手順を示すフローチャートである。

ステップＳ１は、ディスクアンバウンドのBD-Jアプリケーションが動作中かどうかの判定であり、ステップＳ２は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、Index.bdmvにおけるInitial＿output＿mode情報が“立体視出力モード”を示すかどうかの判定である。
ステップＳ１がYesであれば、ステップＳ３においてカレントの出力モードを維持する。ステップＳ１がNo、ステップＳ２がYesであれば、ステップＳ４においてPSR22を立体視出力モードに設定する。ステップＳ１がNo、ステップＳ２がNoであればステップＳ５においてPSR22における出力モードを、2D出力モードに設定する。

図３３は、Procedure when playback condition is changedの処理手順を示すフローチャートである。ステップＳ１１は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、ステップＳ１３は、PSR23におけるStereoscopic Display Capabilityが“Capability有”を示し、尚且つ、プレイリストにSTN＿table＿SSが存在するかどうかの判定である。

ステップＳ１１がYesであればステップＳ１２において、カレント出力モードを変化させない。ステップＳ１１がNo、ステップＳ１３がYesであってもカレント出力モードを変化させない(ステップＳ１２)。ステップＳ１１がNo、ステップＳ１３がNoであればカレント出力モードを2D出力モードに変化させる(ステップＳ１４)。
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、“ストリーム選択プロシージャ”と呼ばれる。

図３４は、ストリーム選択プロシージャの処理手順を示すフローチャートである。ステップＳ２１は、再生装置の表示方式が2Dであるか否かを判定する判定ステップであり、判定結果がYesであるなら、カレントプレイアイテム情報内の2D用STN＿tableをカレントSTN＿tableに設定する(ステップＳ２２)。判定結果がNoであるなら、プレイリスト情報のエクステンションデータに存在するSTN＿table＿SSのうち、カレントプレイアイテム情報に対応するものを、カレントSTN＿tableに設定する。以降、ステップＳ２４〜ステップＳ３３の処理を実行する。ステップＳ２４〜ステップＳ３３は、プライマリビデオストリーム、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップＳ２６〜ステップＳ３３の処理を繰り返すものである。ステップＳ２６は、カレントSTN＿tableにおける、ストリームｘに対応するSTN＿tableエントリー数が0であるか否かの判定であり、ステップＳ２７は、カレントSTN_tableにおけるストリームｘに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。

ステップＳ２６、ステップＳ２７の何れかがYesであれば、ステップＳ３３においてストリーム番号レジスタに格納されているストリーム番号を維持する。
ステップＳ２６、ステップＳ２７の何れもがNoであれば、カレントSTN＿tableに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して(ステップＳ２８)、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する(ステップＳ２９)。

条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する(ステップＳ３０)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレントSTN＿tableにおける優先順位が最も高いものを選択する(ステップＳ３１)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む(ステップＳ３２)。

以上の過程を経て出力モードが確定し、またカレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedure when playback condition is changedによって確定した出力モードに応じたものとなる。出力モードに応じた、プレイアイテムの再生手順を図３５を参照しながら説明する。

図３５は、プレイアイテムの再生手順を示すフローチャートである。
ステップＳ４１は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップＳ４２において、カレントプレイアイテム番号を“１”に初期化した上で、ステップＳ４３〜ステップＳ４８のループに移行する。

このループは、カレントプレイアイテムに対してステップＳ４３〜ステップＳ４６の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップＳ４８)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップＳ４７でYes)。ステップＳ４３〜ステップＳ４６の内容は、以下のものである。
ステップＳ４３において、カレントプレイアイテムのClip＿Information＿file＿nameに記述されている「XXXXX」と、拡張子「m2ts」とで指定されているトランスポートストリームファイルをオープンし、ステップＳ４４において、ビデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿TimeをStart＿SPN[i]及びEnd＿SPN[i]に変換する。

ステップＳ４５では、パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し、ステップＳ４６において、読出範囲[i]に属するエクステントを連続的に読み出すよう、BD-ROMドライブに指示する。
カレント出力モードが立体視出力モードであれば、ステップＳ４９において、カレントプレイアイテム番号を“１”に初期化した上で、ステップＳ５０〜ステップＳ６０のループに移行する。

このループは、カレントプレイアイテムに対してステップＳ５０〜ステップＳ５８の処理を実行して、カレントプレイアイテム番号をインクリメントするという処理を(ステップＳ６０)、カレントプレイアイテム番号が最終になるまで繰り返すものである(ステップＳ５９でYes)。ステップＳ５０〜ステップＳ５８の内容は、以下のものである。
ステップＳ５０において、カレントプレイアイテムのClip＿Information＿file＿nameに記述されている「XXXXX」と、拡張子「ssif」とで指定されているトランスポートストリームファイルをオープンし、ステップＳ５１において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のレフトビュー／ライトビュー識別情報によって指定されているものををベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。

ステップＳ５２において、ベースビュービデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿TimeをStart＿SPN[i]及びEnd＿SPN[i]に変換する。
ステップＳ５３では、ディペンデントビューストリームに対応するSubPlayItemを特定し、ディペンデントビューストリームのパケットID[j]に対応するエントリーポイント[j]を用いて特定されたSubPlayItemIn＿Time、SubPlayItemOut＿TimeをStart＿SPN[j]、End＿SPN[j]に変換する(ステップＳ５４)。

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

HDMVモードにおいては、プレイリストの再生が停止していれば、画面には何も現れないが、BD-Jモードでは、プレイリスト再生が停止していても、BD-Jアプリケーションが画面描画を行うことができるので、何等かの画面が表示されている可能性がある。ここでもし、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こる。何故なら、再生制御エンジン側で立体視が実現されているのに、BD-Jアプリケーションによる画面描画が平面視のままでは不整合が起こるからである。

プレイリストの再生が開始されれば、そのプレイリストが2Dであるか、3D映像であるかに応じて、メニューやグラフィクスを3Dに変換したり、2Dに変換する必要があるので、そこで本実施形態では、ミドルウェアがBD-Jアプリケーションにイベントを出力して、立体視のための画面描画を促すことにしている。
2D映像と3D映像とが切り替わるタイミングを、ディスク上に記録され、再生装置で動作しているプログラムに知らせるための仕組みについて説明する。

図３１の状態遷移では、BD-Jタイトルにおいてプレイリストの再生が開始した際、Procedure when playback condition is changedが実行されたが、このBD-Jタイトルの再生中に、プレイリストの再生が開始された場合、何等かの術により、プレイリスト再生の開始をBD-Jアプリケーションに通知せねばならない。この通知をどのようにして行うかを記述したのが図３６である。

図３６は、再生制御エンジンの状態が“停止中”から“3Dプレイリスト再生中”に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。
第１段目は、BD-Jアプリケーションによって描画されたGUIを示す。第３段目は、再生制御エンジンの状態を示す。第２段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。

第３段目によると、再生制御エンジンの状態は、『停止中→3Dプレイリスト再生→停止中』というように遷移していることがわかる。このうち、停止中から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から停止中に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。

第１段目において、再生制御エンジンの停止中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これは、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。
次に、再生制御エンジン７bが再生を停止しているのではなく、2Dプレイリストの再生を既に開始しており、その再生の途上で、再生対象となるプレイリストが切り替わるというケースを想定する。図３７は、再生制御エンジンの状態が2Dプレイリスト再生から3Dプレイリスト再生に切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。

第１段目は、BD-Jアプリケーションによって描画されたGUIを示す。第３段目は、再生制御エンジンの状態を示す。第２段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第３段目によると、再生制御エンジンの状態は、2Dプレイリスト再生→3Dプレイリスト再生→2Dプレイリスト再生というように遷移していることがわかる。このうち、2Dプレイリスト再生から3Dプレイリスト再生に遷移したタイミングに、3D開始を示すHScreenConfigurationイベントが出力され、3Dプレイリスト再生から2Dプレイリスト再生に遷移したタイミングにも、3D終了を示すHScreenConfigurationイベントが出力されていることがわかる。

第１段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。これも、上記イベント出力に応じて、BD-JアプリケーションがGUIの描画切り替えを行ったためである。

次に、再生制御エンジンによる3Dプレイリストの再生中に、ユーザが字幕切り替え、音声切り替えの操作を再生装置に行ったというケースを想定して、以下を行う。再生対象となるストリームが切り替わることになる。以下、このストリーム切り替えの事例について図３８を参照しながら説明する。
図３８は、再生制御エンジンによる3Dプレイリストの再生中に、対象となるストリームが切り替わった場合に、BD-Jアプリケーションにどのようなイベントが出力されるかを示す図である。

第１段目は、BD-Jアプリケーションによって描画されたGUIを示す。第３段目は、再生制御エンジンの状態を示す。第２段目は、ミドルウェアからBD-Jアプリケーションに出力されるHScreenConfigurationイベントを示す。
第３段目によると、再生制御エンジンの状態は、3Dプレイリスト再生であるか、その途中に、ストリーム切替えがなされていることがわかる。このうち、ストリームが別のものに変化したタイミング、及び、ストリームが元のものに戻ったタイミングに、HScreenConfigurationイベントが出力されていることがわかる。

第１段目において、再生制御エンジンによる2Dプレイリストの再生中に、BD-Jアプリケーションによって描画されるGUIは、2D用のGUIであることがわかる。一方、3Dプレイリスト再生中に、BD-Jアプリケーションによって描画されるGUIは、3D用のGUIであることがわかる。
プレイアイテムやプレイリスト、あるいは、ユーザーがストリーム切り替えを行ったタイミングであって、3D映像の再生が開始された場合、あるいは、終了した場合に、イベントを上げることにより、2D/3Dが切り替わるタイミングを検出して、適切なメニュー・グラフィクスに切り替えさせる。

以上のように本実施形態によれば、再生装置の出力モードが立体視再生モードになっている場合、プレイリスト情報内のClip＿Information＿file＿nameと、インターリーブ形式のトランスポートストリームファイルである旨を示す拡張子「ssif」とから識別されるインターリーブ形式のトランスポートストリームファイルのエクステントを読み出して再生に供することで、出力モードが立体視再生モードに設定されている場合に限って、インターリーブ形式のトランスポートストリームファイルのエクステントを読み出すことができる。これにより、2D再生装置によってインターリーブ形式のトランスポートストリームファイルのエクステントが読み出されることはないので、インターリーブ形式のトランスポートストリームの独特のATSの変化、つまり、ATSが増えては減り、ATSが増えては減るという不規則な変化の繰り返しが、2D再生装置の誤動作や不安定化を招くことはない。

そして、ある決まったファイル参照情報が記述されたプレイリスト情報を作成しておけば、3D再生時において、そのファイル参照情報のファイル名と、インターリーブ形式のトランスポートストリームである旨を示す拡張子とをもつインターリーブ形式のストリームファイルが読み出されて再生されることになり、2D再生時において、そのファイル参照情報のファイル名と、通常形式のトランスポートストリームファイルである旨を示す拡張子とをもつトランスポートストリームファイルが読み出されて再生されることになる。こうすることで、3D用プレイリスト情報、2D用プレイリスト情報を作り分ける必要がないので、オーサリングの手間が減る。こうしたオーサリングの手間の低減によって、3D再生可能な映画作品の充実化を図ることができる。

（第２実施形態）
本実施形態では、表示装置３００、3D眼鏡４００がどのような機能をもち、その内部構成がどのようなものかを図３９を参照しながら説明する。
図３９（ａ）は、表示装置３００の内部構成を示す図である。本図に示すように、表示装置３００は、チューナ７１、HDMI送受信部７２、メッセージ記憶部７３、表示制御部７４、表示素子７５、無線送信部７６から構成される。

チューナ７１は、地上波デジタル放送、衛星デジタル放送で送信されたマルチチャネルトランスポートストリームを受信して復調する。この際チューナ７１は、複数のチャネルを同時に選局して非圧縮のピクチャを出力することもできる。
HDMI送受信部７２は、HDMIを通じて再生装置から送信されてくる非圧縮で合成済みピクチャデータを受信する。

メッセージ記憶部７３は、ピクチャに代えて表示すべき警告メッセージを記憶している。
表示制御部７４は、チューナ７１による復調で得られた非圧縮のピクチャ、HDMIを通じて再生装置から伝送された非圧縮で合成がなされたピクチャを表示に供する。表示にあたって表示制御部７４は、1/120秒、1/140秒という時間精度で、表示期間を切り替えることができ、この精度で、例えば1/24秒という表示期間を、1/48秒、1/72秒、1/92秒というように、更に小さい表示期間に細分化することができる。

表示パネル７５は、液晶表示素子、プラズマ発光素子、有機EL素子を駆動することで、画素の発光を行うデバイスであり、表示制御部７４による制御の下で、非圧縮のピクチャデータの表示を行う。
無線送信部７６は、赤外線通信方式、無線LAN方式によって、3D眼鏡４００を制御する。具体的には、3Dモード及びマルチチャネルモードのそれぞれにおいて、表示期間の先頭にあたって、3D眼鏡４００の状態遷移を促す同期信号を送信する。かかる信号送信によって、レフトビューの期間では透光状態に遷移し、ライトビューの期間では遮光状態に遷移し、レフトビューの期間では改めて透光状態に遷移させるという制御を繰り返す。これにより、図１(ｂ)(ｃ)のような変化を行うことになる。

本実施形態では3Dモードでの処理として、表示制御部７４は、1/24秒という表示期間を、1/72秒の時間長をもつ3つの表示期間(表示期間1/3,2/3,3/3)に分割して、この３つの表示期間1/3,2/3,3/3のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/3の表示内容はレフトビュー、2つ目の表示期間2/3の表示内容はライトビュー、そして3つ目の表示期間3/3の内容には警告画面というようにである。これらの期間の先頭において、眼鏡に対して同期信号を送信し、レフトビュー及びライトビューの状態遷移を行わせる。

マルチチャネルモードの処理として、表示装置３００は複数のチャネルを、時分割で復調する。そして表示制御部７４は、1/24秒という表示期間を、1/48秒の時間長をもつ2つの表示期間(表示期間1/2,2/2)に分割して、この2つの表示期間1/2,2/2のそれぞれに、別々の表示内容を表示する。1つ目の表示期間1/2の表示内容はチャネル１、2つ目の表示期間1/2の表示内容はチャネル２というようにである。そして、個々のチャネルの表示期間が到来すれば、そのチャネルの視聴を希望しているユーザの状態を透光状態に遷移させ、他のチャネルの視聴を希望しているユーザの眼鏡の状態を遮光状態に遷移させる。

図３９（ｂ）は、3D眼鏡４００の内部構成を示す図である。
状態遷移のトリガとなる同期信号を表示装置３００から受信する無線受信部８１と、液晶シャッタの状態を、透光状態、遮光状態に遷移させる状態制御部８２と、液晶シャッタ８３、８４とを具備する。
眼鏡の動作モードにも、3Dモード、マルチチャネルモードが存在する。

3Dモードにおいて眼鏡は、透光状態、遮光状態のほか、遮断−遮光状態を具備する。遮断−遮光状態は、レフトビュー及びライトビューの双方が閉じている状態である。
マルチチャネルモードにおいて眼鏡は、レフトビュー及びライトビューの双方が開いている透光−透光状態と、レフトビュー及びライトビューの双方が閉じている遮断−遮光状態とに遷移する。

立体視表示を実現する場合、本実施形態では、眼鏡のライトビュー、レフトビューを、単に切り替えるのではなく、3D眼鏡４００の装着を促す警告画面を、3D眼鏡を既に装着しているユーザに見せないような配慮が必要になる。警告画面を装着済みユーザに見せないように、3D眼鏡４００をどのように制御すべきかを、図４０を参照しながら説明する。
図４０は、3Dモードにおける表示内容と、眼鏡のレフトビューの状態及びライトビューの状態とを示す。第１段目は、再生時間軸における表示期間を示し、第２段目は、表示装置の表示内容を示す。第３段目は、眼鏡のライトビュー、レフトビューの状態を示す。1/24秒のうち、最初の1/72秒の表示期間1/3では、レフトビュー画像が表示装置に表示されていて、眼鏡のレフトビューが透光状態、ライトビューが遮光状態になっている。続く表示期間2/3では、ライトビュー画像が表示装置に表示されていて眼鏡のレフトビューが遮光状態、ライトビューが透光状態になっている。最後の表示期間3/3では、表示装置が眼鏡の装着を促す警告画面になっていて、眼鏡のレフトビュー及びライトビューが遮光状態になっていることがわかる。

1/24秒の表示期間を分割することで得られた3つの1/72秒の表示期間のうち、最後の表示期間3/3において、眼鏡を装着したユーザは、画面に表示されている警告映像を見ることができない。「3D眼鏡をかけてください」と表示すると、3D眼鏡をかけていない人には、3D眼鏡をかけることを促すメッセージが見えるが、すでに3D眼鏡をかけている人には見えないといった、状況に応じたメッセージが表示されることになる。

マルチチャネル表示を実行する場合、表示装置は、左右のシャッターを切り替えるのではなく、２つの眼鏡のシャッターを切り替えるという独特の制御を実現する。この独特な制御を図４１を参照しながら説明する。
図４１は、左右のシャッターを切り替えるのではなく、２つの眼鏡のシャッターを切り替える場合の、3Dモードにおける表示内容と、ユーザ１の状態と、ユーザ２の状態とを示す。第１段目は、再生時間軸における表示期間を示し、第２段目は、表示装置の表示内容を示す。第３段目は、眼鏡のＲ、Ｌの状態を示す。

1/24秒の表示期間のうち、表示期間1/2において、ユーザー１が装着している眼鏡は、透光−透光状態になりユーザ１はチャンネル１（Ch１）を視聴することができる。
ユーザー２が装着している眼鏡は、遮光−遮光状態になりユーザ２はチャンネル１（Ch１）を視聴することができない。
表示期間2/2において、ユーザー１が装着している眼鏡は、遮光−遮光状態になりユーザ２はチャンネル２（Ch２）を視聴することができない。ユーザー２が装着している眼鏡は、透光−透光状態になりユーザ２はチャンネル２（Ch２）を視聴することができる。このような使い方をすると、１つの画面で、二人がそれぞれ異なるチャンネルを同時に見ることができる
3D眼鏡をすでに装着しているため、眼鏡に内蔵されたイヤフォンを用いれば、映像と音声を完全に独立させることも可能であり、リビングでのチャンネル権争いの回避、１つの画面で対戦ゲームをするなど、応用範囲は広がる。また、ステップを増やすことにより、３チャンネルやさらに多くのチャンネルを１つの画面で見ることが可能となる。

以上のように本実施形態によれば、表示装置を視聴しているユーザが複数人である場合、各ユーザが3D眼鏡４００を着用することで、各ユーザは、自分が好きなチャネルを視聴することが可能になる。ユーザの人数分、表示装置を用意しなくてもユーザは好きな番組を見ることができるので、ユーザ宅のリビングを有効に利用することができる。
(第３実施形態)
本実施形態は、再生装置と、表示装置とのネゴシエーションに関する実施形態である。ユーザ宅内におけるホームシアターシステムの構築事情には、それぞれの家庭独特のものがあり、再生装置は、表示装置と接続された際、接続相手となる表示装置とネゴシエーションを行って、どのプレイリストを再生に供するかを切り替える必要がある。

本実施の形態では、3Dに対応したデジタル出力と、旧来の表示装置にも出力できることを考慮したアナログ出力を同時に出力する場合の改良を説明する。
3D映像を格納したBD-ROMであったとしても、旧来から存在して普及台数が多い2D再生装置でも正常に再生されることを考える必要がある。第１実施形態で述べたように、BD-ROM上のプログラムで制御する方法もあるが、プログラムのバグなどにより選択を誤った場合、不適切な映像が再生され視聴者の健康を害したり、過剰な負荷がかかることにより再生装置が壊れてしまう可能性もあるため、不適切な再生が行われない仕組みが必要となる。

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用の出力が困難な場合は、リモコンに副表示部を設け、そちらに表示することが望ましい。

これらのことを図４２を参照しながら具体的に説明する。図４２は、再生装置と、表示装置との接続態様を示す図である。上側は、アナログ接続される表示装置を示す。左下側に、デジタル接続される3Ｄ対応の表示装置３００を示し、右下側に、デジタル接続される2D表示装置３０２を示す。
再生装置が、3D表示装置と、2D表示装置とに同時接続された場合は、これらの表示装置とネゴシエーションを試みる。そして、相手側表示装置との接続がアナログ接続によるものであるため、ネゴシエーションをすることができないことが判明すれば、レフトビュービデオストリーム、レフトビュービデオストリームのうち、2D出力優先映像情報に示されるものを再生する。こうすることで、接続相手たる表示装置とアナログ接続された場合、オーサリング担当者が意図したプレイリストを再生に供することができる。

一方、双方の表示装置との接続がデジタル接続によるものであり、ネゴシエーションが成功した場合は、相手側が3D表示装置であるか、2D表示装置であるかを判定する。ネゴシエーションの結果、相手側が2D表示装置であることが判明すれば、図中の矢印mg1に示すように画面内容の遷移を2D表示装置に行わせる。
矢印mg1は、2D表示装置の画面内容の遷移を示す。デジタル接続の場合、3D映像の再生中です。「3D表示装置で御覧ください」とのメッセージを表示した後、2D映像を表示する。

またネゴシエーションにあたっては、複数のライトビューを切り替える必要がある。複数のライトビューを切り替える理由として、表示装置の画面の大きさの違いがある。左目と右目の間隔は個人の個体差があってもだいたい同じであるが、表示装置は２０インチのものもあれば、１５０インチのものもある。５０インチの表示装置を想定して、目と目の間隔６.５センチで作られた映像も、１５０インチの表示装置では３倍の１９.５センチの目の間隔になってしまい、3D映像として認識が難しくなる。そのため、様々なサイズの表示装置でレフトビューとライトビューの差が、６.５センチになるレフトビュー、ライトビューの組みを納めておけば、表示装置に合わせてビデオストリームを選ぶことにより、最適なレフトビュービデオストリーム/ライトビュービデオストリームの組み合わせを選ぶことができる。

表示装置には、１５０インチ、５０インチという様々なサイズがあり、例え左右の画素数が同じでも、これらの表示装置における画面上の距離は違ってくることを図４３を参照しながら説明する。
図４３は、左右の差を示す画素数と、表示装置の画面上の距離との関係を示す。
左側は、左右のオフセットが異なる、ライトビューピクチャ−と、レフトビューピクチャとの組を示す。

中段は、５０インチ表示装置における距離を示し、右側は、150インチ表示装置における距離を示す。左右の差が５０画素である場合、５０インチ表示装置上での距離は２.０cmとなり、１５０インチ表示装置上での距離は６.０cmとなる。
左右の差が100画素である場合、５０インチ表示装置上での距離は、４.０cmとなり、１５０インチ表示装置上での距離は１２.０cmとなる。

左右の差が150画素である場合、５０インチ表示装置上での距離は、６.０cmとなり、１５０インチ表示装置上での距離は１８.０cmとなる。
５０インチ表示装置では、６.０cmが最適となり、１５０インチ表示装置でも、６.０cmが最適となので、3DStream Depth ChangeUO、3DStreamDepthChangeコマンドにより、画面上において表示される距離を調整する。

図４３で説明した表示装置の画面サイズを取得する方法を用いて、プログラムが自動的に最適な左目/ライトビューの組み合わせを選択できれば、ユーザーは画面サイズを気にすることなく、最適なストリームが自動選択されることになる。
複数の画面サイズに対応した奥行き感/深度の異なるストリームが複数記録されている場合、ローカルストレージの画素差が異なるストリームを記録媒体に記録しておき、これらのストリームを切り替えるためのUOやコマンドを用いることで、ユーザー自身が奥行き感/深度を選択することも可能である。

以上のように本実施形態によれば、再生装置が表示装置と接続された際、表示装置との関係においてより適切な再生出力が行われることが保障される。

(第４実施形態)
本実施形態は、立体視を行うにあたって、ビデオストリームと共に、どのようなPGストリーム、IGストリームを選択すべきかという改良を実現する。

2D再生装置で再生される映像は2D映像であり、対応する字幕やメニュー画像が2Dである。対して、3D再生装置で再生されるのは3D映像であり、対応する字幕やメニュー画像も3Dであることが望ましい。3D映像に対して、2DのPGやIGが表示された場合、前後関係が意図しないものとなり、ユーザーが正常に空間認識ができず、最悪健康を害してしまうためである。

また、3D再生装置であったとしても、ユーザーが2D映像を選ぶことは自由であるが、その場合、対応する字幕やメニュー画像も自動的に2Dに切り替わるべきである。
2D映像と関連する字幕などの組み合わせ、3D映像と関連する字幕などの組み合わせは、プログラムで選択してもよいが、データとして関連づけておくことにより再生装置が自動的に不適切な組み合わせを排除することが可能となる。その仕組みについて述べる。

3D対応のプレイリストは、第１実施形態で示したように、ストリーム選択テーブルをさらに2D用のSTN＿tableと、3D再生用のSTN＿table＿SSとに分けて管理する。そして2D再生でしか利用しない映像/音声/PG/IGのストリーム登録と、3Dで利用する映像/音声/PG/IGのストリーム登録は異なるエントリー群に登録する。2D映像を選択している場合は、3D用に用意された音声/PG/IGは選択できない。また、同様に3D映像を選択している場合は、2D用に用意された音声/PG/IGは選択できない。

管理テーブルをさらに分割して、レフトビューとライトビュー、それらに関連づけられる字幕/メニュー画像のストリーム登録を別々に管理することもできる。

2D用に作成されたPGストリームと、3D用に作成されたPGストリームとでは、奥行きの有無、位置や角度に違いがあるので、立体視のためのビデオストリームの再生時に、2DPGストリームが選択されて、3Dビデオストリームと共に再生されることは、オーサリング者にとっては何とか避けたいところである。

これを避けるために導入されたのが、STN＿table＿SSにおけるストリーム組合せ情報である。図４４は、ビデオストリームとPGストリームとを組み合わせる場合の、ストリーム組合せ情報の記述例である。
本図（ａ）に示すように、ストリーム選択テーブルにおけるストリーム組み合わせ情報には、ビデオストリームのストリーム番号＝1と、PGストリームのストリーム番号”=1”、２との組み合わせが許容されていることがわかる。

ビデオストリームのストリーム番号＝２には、PGストリームのストリーム番号”=1”、２との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号＝３には、PGストリームのストリーム番号＝３、４との組み合わせが許容されていることがわかる。ビデオストリームのストリーム番号＝４には、PGストリームのストリーム番号＝３との組み合わせが許容されていることがわかる。

図４４（ｂ）は、その組合せ情報にて規定されるビデオストリーム、PGストリーム間で、許容される組合せを模式的に示す。
本図左側のビデオストリームは、ストリーム１、２、３、４のストリーム番号によって特定されるビデオストリームを示す。これらのうち、ストリーム１、２のストリーム番号によって特定されるビデオストリームは2D用であり、ストリーム３、４のストリーム番号によって特定されるビデオストリームは3D用であることがわかる。

本図右側のPGストリームは、ストリーム１、２、３、４のストリーム番号によって特定されるPGストリームを示す。これらのうち、ストリーム１、２のストリーム番号によって特定されるPGストリームは2D用であり、ストリーム３、４のストリーム番号によって特定されるPGストリームは3D用であることがわかる。
ビデオストリーム及びPGストリームの間の実線kw1,2,3・・・は、ストリーム組合せ情報によって許容される組合せを模式的に示す。この実線で模式的に示されるように、2Dと3Dの映像/字幕を組み合わせることはできない。また、組み合わせ可能なストリーム通しの場合も意図的に省くことができる。

PGストリームと、ビデオストリームとの組合せはストリーム組合せ情報に予め規定されているので、このストリーム組合せ情報に則して、PGストリームを選択すれば、あるビデオストリームが選択された際、このビデオストリームにとって最適なPGストリームが選択されることが保障されることになる。
図４５は、ストリーム組み合わせ情報に従った、再生装置のストリーム選択の処理手順を示すフローチャートである。ユーザーがストリームを切り替える時、あるいは、プレイアイテム境界のように、ストリームの構成が変化する可能性がある時に、本図で示すストリーム選択処理が実行され、ビデオストリームとPGストリームは、ストリーム組み合わせ情報に登録された組み合わせに合致させる。

ステップＳ７１において、ビデオストリーム番号を取得し、ステップＳ７２においてPGストリームを取得する。ステップＳ７３は、ビデオストリームと、PGストリームとの組合せが、ストリーム組合せ情報に登録されているかどうかの判定であり、もし登録されていれば、ステップＳ７４においてそのストリーム組合せ情報の通り再生する。登録されていなければ、ステップＳ７５においてストリーム組合せ情報においてビデオストリームとの組合せが登録されている、他のPGストリームを選択し再生する。

(第５実施形態)
第１実施形態の冒頭で述べたように、立体視には様々な原理があり、市場で流通しつつある製品は、様々な3D方式に対応していると考えられる。3Dの再生方式にはいろいろな方式が存在し、また、方式により表示装置側の対応・非対応も異なるため、再生装置のシステムパラメータは複数の方式を表現できる形式が望ましい。ここでは、3Dの再生方式として、２画面のビデオを独立して送る２画面ステレオ再生方式、サイド・バイ・サイド方式、横方向２倍方式、2D+奥行き情報方式などを例に挙げるが、その他、表示装置が対応可能な方式がある場合は、対応する方式の実行の可否を識別できるように、PSRのビットアサインを定める。

図４６は、複数の3D方式を網羅できるPSRのビットアサインを示す図である。
本図におけるPSR24は、４ビット(b3,b2,b1,b0)からなり、最上位ビットb3から最下位ビットb0までのそれぞれのビットには、それぞれ対応する3D再生方式が関連づけられている。再生装置がその3D再生方式に対応している場合には、対応するビットが「１」に設定され、対応していない場合には対応するビットが「０」に設定される。PSR24の全ビットが「０」のときは、再生装置は2D再生装置であり、いずれかあるいはいくつかのビットが「１」のときは、対応した方式の2D/3D再生装置であることを示す。

PSR24における最上位ビットb3から最下位ビットb0までのビットは、２画面ステレオ再生、サイド・バイ・サイド方式、横方向２倍方式、2D−奥行き情報方式のそれぞれの3D表示方式をサポートできるかどうかを示す。
２画面ステレオ再生方式は、これまでの実施形態で説明した方式である。
サイド・バイ・サイド方式は、1920×1080という解像度を、960×1080と、960×1080とに分けて、これらのそれぞれに、レフトビュー，ライトビューを表示させる方式をいう。

横方向２倍方式は、1920×1080という解像度を、3840×1080という解像度にして、このうち、1920×1080の解像度の部分にレフトビューを割り当て、1920×1080の解像度の部分にライトビューを割り当てる方式である。
2D−奥行き情報方式は、2D映像と、グレースケール画像とで立体視を実現する方式である。グレースケール画像は、２値化画素からなる。2値化画素の輝度は、2D映像における各画素の奥行きを示す。この２値化画素の輝度に従い、2D映像における各画素の奥行きを作成して、立体視画像を構築する。

プレーヤセッティングレジスタの値をBD-ROM上のBD-Jアプリケーションからアクセスする場合は、再生装置のシステムプロパティとしてアクセスすることも可能である。
表示装置と再生装置が、HDMIのように表示装置の性能・対応方式を再生装置に送信できる伝送方式により接続されている場合、再生装置の性能だけではなく、表示装置の対応方式も鑑みて、PSR24に自動的に設定する。この場合、同じ再生装置でも接続される表示装置によってPSR24の値は変化する。

表示装置の性能を伝送できない場合は、ユーザーが手動で設定することが望ましい。
表示装置から対応方式を取得できる場合は、単純な対応方式の他、表示装置のサイズ、解像度、表示装置の画面から視聴する人までの距離等、3D再生に影響する情報を取得し、PSR24に格納しておくことで、後で説明するプログラムによる最適な再生方式の選択に活用することも可能である。

3Dの対応状況が1ビットで表せないことがででくる。この場合、複数ビットを使うべきである。映像サイズが1920×1080までは対応可能だが、それ以上の解像度の場合はデコーダの性能不足などにより再生できないことが想定される場合、２ビットを利用して非対応を「00b」、1920×1080まで対応を「01b」、それ以上のサイズに対応したものを「10b」などと表現すれば、より細かく対応状況をシステムパラメータを用いて表現することが可能である。

複数の3D方式を網羅できるようにPSR24のビットアサインを規定しておけば、再生装置に接続される表示装置がどのような3D方式のものであっても、表示装置に立体視再生を行わせることができる。図４７は、表示装置が対応している3D再生方式を再生装置セッティングレジスタに反映させる図である。これまでに説明した3D再生能力を示す3D-Capabilityのシステムパラメータを利用すると、2D再生装置が,3Dビデオストリームを選択することを禁止する処理も可能である。ユーザー、プログラムあるいは、プレイアイテム先頭において、ビデオストリームを選択する時、選択しようとしているストリームが3Dビデオストリームである場合、プレーヤセッティングレジスタに格納された再生装置の対応3D方式を確認し、ストリーム選択テーブルから選択しようとしているストリームの情報を取得することにより、選択するストリームが再生装置で再生可能か否かが判別できる。

2D再生装置では3D映像を再生できないため、この処理により選択自体が発生せず、不適切な映像が画面に表示されることを防ぐことができる。
前の実施形態で説明した、表示装置が対応している3D方式を自動的に取得する仕組みと組み合わせると、接続されている表示装置が対応した3D方式のストリームか2Dストリームしか選択できないようになり、不適切な映像が画面に表示されることを防ぐことができる。

かかる処理を実現する場合のプログラムの処理内容について説明する。
ユーザからタイトルが選択され、実行されたBDプログラムファイルは、プログラムの中で、再生装置が3D映像再生に対応しているか、対応している場合にユーザが3D映像再生を選択しているかを調べて、再生するプレイリストを切り替える。
3D再生方式を複数想定する場合は、それぞれ対応した方式のプレイリストを準備しておき、再生装置がBD-ROMに格納されたプレイリストに対応している場合は、対応した3Dプレイリストを選択、対応していない場合は、2Dプレイリストを選択する。

FirstPlayタイトルをどのように構成すべきかについて説明する。
FirstPlayタイトルを構成するプレイリスト、つまり、ディスク挿入時にまず最初に再生されるプレイリストは、安全のため必ずどの再生装置でも再生される2D映像で構成すべきである。
BD-ROMに格納されているプログラムはオーサリング側が作成するものであり、複数の3D形式に再生装置が対応している場合、どの3D再生方式を優先的に選択するかは、オーサリング側の意志に依存する。

3Dプレイリストの選択について説明する。
たとえば、3D方式１が２画面ステレオ再生方式、3D方式２がサイド・バイ・サイド方式であり、再生装置がサイド・バイ・サイド方式にのみ対応している場合、プログラムはその再生装置で再生可能であるサイド・バイ・サイド方式の3Dプレイリスト００５.MPLSを選択して再生する。

Index.bdmv、プログラムの関係について説明する。
図４７に示すように、3D再生方式を再生装置セッティングレジスタに反映させれば、BD-ROMにおけるプログラムを動作させることでオーサリング担当者は、再生装置及び表示装置にとって最適な3D方式を再生装置セッティングレジスタに設定することができる。このような3D再生方式の選択を実現する場合、インデックステーブルと、BDプログラムファイルとは、以下に示すように設定しておく必要がある。

図４８はインデックスファイル（Index.bdmv）とプログラムファイルとの関係を示している。
本図左側は、インデックステーブルと、当該インデックステーブルの解読主体であるモード管理モジュール１６とを示す。上述したように、インデックステーブルには、FirstPlayタイトル、トップメニュー、タイトル１、２、３のそれぞれに対応するエントリーが存在する。

本図の右側は、再生装置における出力モードの設定に応じて選択的に再生されるべき4つのプレイリストファイルを示す。
４つのプレイリストファイルには、2D映像を再生する経路が記載された00001.mpls、00003.mplsと、3D方式１による再生経路が記載された00004.mplsと、3D方式２による再生経路が記載された00005.mplsとが存在する。

本図の真ん中には、ムービーオブジェクト１,２という2つのムービーオブジェクトが記載されている。
ムービーオブジェクト１は、00001.mplsの再生を命じる。この00001.mplsは、2Dプレイリストを定義するものである。何故なら、FirstPlayタイトルで再生されるべきプレイリストは、何れの出力モードでも必ず再生される必要があるからである。

ムービーオブジェクト２は、PSR24に示される3D-Capabilityが3D方式1であれば、00004.mplsの再生を命じ、3D-Capabilityが3D方式2であれば00005.mplsの再生を命じ、3D-Capabilityが、何れの3D方式にも合致しなければ、00003.mplsの再生を命じる。図中の矢印pp1,pp2,pp3は、ムービーオブジェクトによるプレイリストの再生指示を模式的に示す。
図中の矢印my1,my2は、これらのムービーオブジェクトが、HDMVモジュール１３による解読に供されることを示す。HDMVモジュール１３が、これらのムービーオブジェクトを実行することで、再生装置におけるCapabilityに応じて、上述したような3つのプレイリストファイルが選択的に再生に供されることがわかる。

ストリーム組合せ情報に、ビデオストリームと組合せることができるPGストリームが予め規定されていれば、ストリーム選択の処理手順は、図４９のフローチャートに則したものとなる。
図４９は、ストリーム選択の処理手順を示すフローチャートである。ステップＳ８１において、再生装置の対応3D方式を取得し、ステップＳ８２において、ストリーム選択テーブルを取得する。ステップＳ８３では、再生装置が対応する3D方式と、選択しようとするストリームとが合致しているかどうかを判定し、ステップＳ８３の判定結果がYesであるなら、ステップＳ８４において選択を許す。ステップＳ８３の判定結果がNoであるなら、ステップＳ８５において、選択を許可しない。

（第６実施形態）
本実施形態では、第１実施形態で述べた記録方法を実施するための記録装置について説明する。
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。

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

そして、装置外部から入力されるトランスポートストリームからビデオストリームにおけるGOPの先頭位置が検出されるか、エンコーダによってビデオストリームのGOPが生成されれば、記録装置の制御部は、このGOPにおいて、先頭に位置するイントラピクチャのPTSと、このGOPの先頭部分を格納したソースパケットのパケット番号とを取得して、このPTS及びパケット番号の組みを、EP＿PTSエントリー及びEP＿SPNエントリーの組みとして、クリップ情報ファイルのエントリーマップに追記する。以降、GOPが生成される度に、EP＿PTSエントリー及びEP＿SPNエントリーの組みを、クリップ情報ファイルのエントリーマップに追記してゆく。この際、GOPの先頭がIDRピクチャである場合は、“オン”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。GOPの先頭がIDRピクチャでなければ場合は、“オフ”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。

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

以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法を実行する記録装置について説明する。

ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成するというのが、本発明にかかる記録装置の使用形態である。

図５０は、記録装置の内部構成を示す図である。本図に示すように本発明にかかる記録装置は、ビデオエンコーダ５０１、素材制作部５０２、シナリオ生成部５０３、BDプログラム制作部５０４、多重化処理部５０５、フォーマット処理部５０６により構成される。

ビデオエンコーダ５０１は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG４-AVCやMPEG２などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部５０１aに書き込む。ビデオエンコーダ５０１は、ピクチャ間の相関特性を利用した画像圧縮をするために、８x８や１６x１６のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。

マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、８ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。

素材制作部５０２は、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックストリームなどの各ストリームを作成して、オーディオストリーム格納部５０２a、インタラクティブグラフィクスストリーム格納部５０２b、プレゼンテーショングラフィックストリーム格納部５０２cに書き込む。
オーディオストリーム作成にあたって素材制作部５０２は、非圧縮のLinearPCM音声などをAC３などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部５０２は、字幕イメージと表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるプレゼンテーショングラフィックスストリームを作成する。素材制作部５０２は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるインタラクティブグラフィックスストリームを作成する。

シナリオ生成部５０３は、素材制作部５０２で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BD-ROMフォーマットでシナリオを作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部５０３は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第１実施形態１および第２実施形態で説明したデータ構造となる。

BDプログラム制作部５０４は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ５０１が出力した奥行き情報を利用することができる。
多重化処理部５０５は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG２-TS形式のAVクリップを作成する。このとき、AVクリップと対になるクリップ情報ファイルも同時に作成する。

多重化処理部５０５は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。
フォーマット処理部５０６は、シナリオ生成部５０３で生成したBD-ROMシナリオデータと、BDプログラム制作部５０４で制作したBDプログラムファイル、多重化処理部５０５で生成したAVクリップやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成する。

また、この時ビデオエンコーダ５０１が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトは実施の形態１、２で説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。

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

BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。
マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで“トランスコード”とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、AVクリップ、Clip情報、プレイリスト情報を得る必要がある。

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

(立体視方式)
第１実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。

表示装置３００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。

（3D映像を格納するためのIndex.bdmvのデータ構造）
プレイリストではなくインデックスファイルを、2D再生装置と3D対応再生装置で区別し、2D再生装置では再生開始時に「Index.bdmv」を参照するが、3D再生装置では「Index.３dmv」を選択させるといった方法もとることができる。

（複数ストリームを扱うためのデータ構造）
複数のストリームがある場合、上記のようにサブパス情報を使ってもよいし、マルチアングルのためのmulti＿clip＿entriesを使ってもよい。multi＿clip＿entriesを使う場合、表示装置の画面のサイズに合わせてストリームを選択した後は、誤って他の画面サイズ用のストリームに切り替わらないよう、アングル変更のUOを禁止することが望ましい。

(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。

同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
(記録層の構成)
BD-ROMの各記録層には、立体視／平面視共用領域と、立体視専用領域と、平面視専用領域とを設けることが望ましい。

立体視／平面視共用領域は、立体視映像の再生時と平面視映像の再生時との両方でアクセスされる領域であって、ベースビュービデオストリームファイルに属する複数のエクステントと、ディペンデントビューストリームを格納したファイルに属する複数のエクステントとが交互に配置されて記録された連続領域である。
立体視専用領域及び平面視専用領域は、立体視／平面視共用領域に後続しており、記録層の境界直前に存在する。

立体視専用領域は、立体視出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視／平面視共用領域に記録されたベースビュービデオストリームファイルに属するエクステントに後続するエクステントと、立体視／平面視共用領域に記録されたディペンデントビュービデオストリームファイルに属するエクステントに後続するエクステントとが交互に配置されて記録された領域である。

平面視専用領域は、2D出力モードの再生中に生じるロングジャンプの直前にアクセスされる領域であって、立体視専用領域に記録されたベースビュービデオストリームファイルに属するエクステントの複製物が記録された領域である、
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

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

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

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

（データ構造の記述の仕方）
上述したようなデータ構造のうち、ある決まった型の情報が複数存在するという繰り返し構造は、for文に、制御変数の初期値と、繰り返し条件とを設定することで定義することができる。Do While文を用いてもよい。
また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。この記述には、switch文、case文を用いてもよい。

このように、各実施形態に示したデータ構造は、高級プログラミング言語の文法によって記述することができるので、各実施形態に示したデータ構造は、構文解析、最適化、資源割付、コード生成といった、コンパイラによる翻訳過程を経て、上記プログラムと同様、コンピュータが読み取り可能なコンピュータコードに変換された状態で記録媒体に記録される。こうして、高級プログラミング言語によって記述されたデータ構造は、オブジェクト指向言語においては、クラス構造体のメソッド以外の部分、つまり、クラス構造体における配列型のメンバー変数として扱われ、プログラムの一部をなす。つまり、各実施形態のデータ構造は、コンピュータコードに変換されてコンピュータ読取可能な記録媒体記に記録され、プログラムのメンバー変数となる。こうした扱いがなされるので、これまでに述べたデータ構造は、実質的にはプログラムと同じものである。

（光ディスクの再生）
BD-ROMドライブは、半導体レーザ、コリメートレンズ、ビームスプリッタ、対物レンズ、集光レンズ、光検出器を有する光学ヘッドを備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。

集光された光ビームは、光ディスク上で反射/回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、再生信号を生成する。
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。

（半導体メモリカード記録装置及び再生装置の実施形態）
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。

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

以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
半導体メモリカード再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。

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

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

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

以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。
半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを介してデータを読み出すように構成すればよい。

より詳細には、再生装置のスロット（図示せず）に半導体メモリーカードが挿入されると、半導体メモリーカードI/Fを経由して再生装置と半導体メモリーカードが電気的に接続される。半導体メモリーカードに記録されたデータは半導体メモリーカードI/Fを介して読み出すように構成すれば良い。

(受信装置としての実施形態)
各実施形態で説明した再生装置は、本実施の形態で説明をしたデータに相応するデータ（配信データ）を電子配信サービスの配信サーバから受信し、半導体メモリカードに記録する端末装置としても実現することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（システムLSI）
再生装置の内部構成のうち、システムターゲットデコーダや、再生制御部７、プログラム実行部１１等、ロジック素子を中心とした部分は、システムLSIで構成することがことが望ましい。

システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッドフラッドアレイ)、PGA(ピングリッドアレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置２００の中核としての役割を果たす。
かかるシステムLSIは、再生装置２００は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。

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

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

・MPUブロック
これは、ARMコア、外部バスインターフェイス(Bus Control Unit:BCU)、DMAコントローラ、タイマー、ベクタ割込コントローラといった周辺回路、UART、GPIO(General Purpose Input Output)、同期シリアルインターフェイスなどの周辺インターフェイスで構成される。

・ストリームI/Oブロック
これは、USBインターフェイスやATA Packetインターフェイスを介して、外部バス上に接続されたドライブ装置、ハードリディスクドライブ装置、SDメモリカードドライブ装置とのデータ入出力を行う。
・AVI/Oブロック
これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。

・メモリ制御ブロック
これは、外部バスを介して接続されたSD-RAMの読み書きを実現するブロックであり、各ブロック間の内部接続を制御する内部バス接続部、システムLSI外部に接続されたSD-RAMとのデータ転送を行うアクセス制御部、各ブロックからのSD-RAMのアクセス要求を調整するアクセススケジュール部からなる。

具体的な生産手順の詳細は以下のものになる。まず各実施形態に示した構成図を基に、システムLSIとすべき部分の回路図を作成し、回路素子やIC,LSIを用いて、構成図における構成要素を具現化する。

そうして、各構成要素を具現化してゆけば、回路素子やIC,LSI間を接続するバスやその周辺回路、外部とのインターフェイス等を規定する。更には、接続線、電源ライン、グランドライン、クロック信号線等も規定してゆく。この規定にあたって、LSIのスペックを考慮して各構成要素の動作タイミングを調整したり、各構成要素に必要なバンド幅を保証する等の調整を加えながら、回路図を完成させてゆく。

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

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

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

ミドルウェアに対するインターフェイス、および、ミドルウェアとシステムLSIのインターフェイスを適切に定義することにより、再生装置のユーザインターフェース部分、ミドルウェア部分、システムLSI部分をそれぞれ独立して並行開発することができ、より効率よく開発することが可能となる。なお、それぞれのインターフェイスのきり方には、様々な切り方がある。

本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなく3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ

１００ BD-ROM
２００再生装置
３００テレビ
４００ 3D眼鏡
５００リモコン
１ BDドライブ
２a,b リードバッファ
４システムターゲットデコーダ
５a プレーンメモリセット
５b プレーン合成部
６ HDMI送受信部
７再生制御部
９管理情報メモリ
１０レジスタセット
１１プログラム実行部
１２プログラムメモリ
１３ HDMVモジュール
１４ BD-Jプラットフォーム
１５ミドルウェア
１６モード管理モジュール
１７ユーザイベント処理部
１８ローカルストレージ
１９不揮発メモリ
２３ PIDフィルタ
２７ PIDフィルタ
３１プライマリビデオデコーダ
３２レフトビュービデオプレーン
３３ライトビュービデオプレーン
３４セカンダリビデオデコーダ
３５セカンダリビデオプレーン
３６ PGデコーダ
３７ PGプレーン
３８ IGデコーダ
３９ IGプレーン
４０プライマリオーディオデコーダ
４１セカンダリオーディオデコーダ
４２ミキサー

上記課題を解決するため、本発明にかかる受信装置は、放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ベースビュー指定情報は、前記ビデオストリームの再生区間毎に定義されており、
前記ビデオストリームのデコードを行い、非圧縮のピクチャデータを得るデコーダと、
前記デコーダによって得られた非圧縮のピクチャデータを出力する出力手段とを備え、
前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、ライトビュービデオストリームがあり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるかを示し、
前記デコーダは、
平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、
立体視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、且つ前記ディペンデントビュービデオストリームを構成する圧縮ピクチャデータを、前記ベースビュー指定情報により示されるベースビュービデオストリームの非圧縮ピクチャデータを参照してデコードし、
前記出力手段は、
前記ベースビュー指定情報に従って、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームのいずれかを左目用映像として出力し、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームの他方を右目用映像として出力する
ことを特徴としている。

Claims

放送またはネットワークを経由してデータを送信する送信装置であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、
を示すことを特徴とする送信装置。
前記データは、テーブル情報を含み、
前記テーブル情報は、
時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、
前記ベースビュー指定情報は、前記テーブル情報に対応付けられている
ことを特徴とする、請求項１記載の送信装置。
前記データは、データ管理情報を含み、
前記データ管理情報は、
プログラムクロックリファレンス（ＰＣＲ）、プログラムマップテーブル（ＰＭＴ）、プログラムアソシエーションテーブル（ＰＡＴ）の何れかである
ことを特徴とする、請求項１記載の送信装置。
放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ビデオストリームのデコードを行い、非圧縮のピクチャデータを得るデコーダと、
前記デコーダによって得られた非圧縮のピクチャデータを出力する出力手段とを備え、
前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、
ライトビュービデオストリームがあり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるかを示し、
前記デコーダは、
平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、
立体視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、且つ前記ディペンデントビュービデオストリームを構成する圧縮ピクチャデータを、前記ベースビュー指定情報により示されるベースビュービデオストリームの非圧縮ピクチャデータを参照してデコードし、
前記出力手段は、
前記ベースビュー指定情報に従って、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームのいずれかを左目用映像として出力し、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームの他方を右目用映像として出力する
ことを特徴とする受信装置。
前記データは、テーブル情報を含み、
前記テーブル情報は、
時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、
前記ベースビュー指定情報は、前記テーブル情報に対応付けられている
ことを特徴とする、請求項４記載の受信装置。
前記データは、データ管理情報を含み、
前記データ管理情報は、
プログラムクロックリファレンス（ＰＣＲ）、プログラムマップテーブル（ＰＭＴ）、プログラムアソシエーションテーブル（ＰＡＴ）の何れかである
ことを特徴とする、請求項４記載の受信装置。
放送またはネットワークを経由してデータを送信する送信方法であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ビデオストリームは、立体視再生を可能とするレフトビュービデオストリームと、ライトビュービデオストリームであり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるか、また平面再生時に前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうちどちらのビデオストリームが再生されるか、
を示すことを特徴とする送信方法。
前記データは、テーブル情報を含み、
前記テーブル情報は、
時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、
前記ベースビュー指定情報は、前記テーブル情報に対応付けられている
ことを特徴とする、請求項７記載の送信方法。
前記データは、データ管理情報を含み、
前記データ管理情報は、
プログラムクロックリファレンス（ＰＣＲ）、プログラムマップテーブル（ＰＭＴ）、プログラムアソシエーションテーブル（ＰＡＴ）の何れかである
ことを特徴とする、請求項７記載の送信方法。
放送またはネットワークを経由して送信されたデータを受信する受信方法であって、
前記データは、ビデオストリームと、ベースビュー指定情報とを含み、
前記ビデオストリームのデコードを行い、非圧縮のピクチャデータを得るデコードステップと、
前記デコードステップによって得られた非圧縮のピクチャデータを出力する出力ステップとを備え、
前記ビデオストリームには、立体視再生を可能とするレフトビュービデオストリーム、
ライトビュービデオストリームがあり、
前記レフトビュービデオストリーム及び前記ライトビュービデオストリームのうち、いずれか一方がベースビュービデオストリームであり、他方がディペンデントビュービデオストリームであり、
前記ディペンデントビュービデオストリームは、前記ベースビュービデオストリームに基づいて圧縮符号化されたものであり、
前記ベースビュー指定情報は、前記ベースビュービデオストリームが前記ライトビュービデオストリームと前記レフトビュービデオストリームのうちどちらのビデオストリームであるかを示し、
前記デコードステップは、
平面視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、
立体視再生を行う場合、前記ベースビュー指定情報により示されるベースビュービデオストリームを構成する圧縮ピクチャデータのデコードを行い、且つ前記ディペンデントビュービデオストリームを構成する圧縮ピクチャデータを、前記ベースビュー指定情報により示されるベースビュービデオストリームの非圧縮ピクチャデータを参照してデコードし、
前記出力ステップは、
前記ベースビュー指定情報に従って、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームのいずれかを左目用映像として出力し、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームの他方を右目用映像として出力する
ことを特徴とする受信方法。
前記データは、テーブル情報を含み、
前記テーブル情報は、
時間軸上のある再生区間において再生されるエレメンタリストリームを示すテーブルであり、
前記ベースビュー指定情報は、前記テーブル情報に対応付けられている
ことを特徴とする、請求項１０記載の受信方法。
前記データは、データ管理情報を含み、
前記データ管理情報は、
プログラムクロックリファレンス（ＰＣＲ）、プログラムマップテーブル（ＰＭＴ）、プログラムアソシエーションテーブル（ＰＡＴ）の何れかである
ことを特徴とする、請求項１０記載の受信方法。