JP4574748B2 - 記録媒体、再生装置、記録方法、記録媒体再生システム - Google Patents

記録媒体、再生装置、記録方法、記録媒体再生システム Download PDF

Info

Publication number
JP4574748B2
JP4574748B2 JP2010523231A JP2010523231A JP4574748B2 JP 4574748 B2 JP4574748 B2 JP 4574748B2 JP 2010523231 A JP2010523231 A JP 2010523231A JP 2010523231 A JP2010523231 A JP 2010523231A JP 4574748 B2 JP4574748 B2 JP 4574748B2
Authority
JP
Japan
Prior art keywords
stream
file
information
playback
view
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010523231A
Other languages
English (en)
Other versions
JPWO2010095382A1 (ja
Inventor
航 池田
泰治 佐々木
智輝 小川
洋 矢羽田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Application granted granted Critical
Publication of JP4574748B2 publication Critical patent/JP4574748B2/ja
Publication of JPWO2010095382A1 publication Critical patent/JPWO2010095382A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00094—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised record carriers
    • G11B20/00115—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving measures which result in a restriction to authorised record carriers wherein the record carrier stores a unique medium identifier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00246—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is obtained from a local device, e.g. device key initially stored by the player or by the recorder
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00217—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source
    • G11B20/00253—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier
    • G11B20/00362—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier the cryptographic key used for encryption and/or decryption of contents recorded on or reproduced from the record carrier being read from a specific source wherein the key is stored on the record carrier the key being obtained from a media key block [MKB]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G11B20/1251—Formatting, e.g. arrangement of data block or words on the record carriers on discs for continuous data, e.g. digitised analog information signals, pulse code modulated [PCM] data
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/189—Recording image signals; Reproducing recorded image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H04N5/92—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/10537—Audio or video recording
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
    • G11B2020/1218—Formatting, e.g. arrangement of data block or words on the record carriers on discs wherein the formatting concerns a specific area of the disc
    • G11B2020/1224—Formatting, e.g. arrangement of data block or words on the record carriers on discs wherein the formatting concerns a specific area of the disc extent, i.e. a set of sectors which numbers form a continuous ascending sequence
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/23—Disc-shaped record carriers characterised in that the disc has a specific layer structure
    • G11B2220/235—Multilayer discs, i.e. multiple recording layers accessed from the same side
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2562—DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs

Description

本発明は、3D映像及び2D映像の再生技術の技術分野に属する発明である
2D映像とは、表示装置の表示画面をX-Y平面として捉えて、このX-Y平面上の画素にて表現される画像であり、平面視画像とも呼ばれる。
対照的に3D映像とは、表示装置の画面におけるX-Y平面上の画素に、Z軸方向の奥行きを加えた画像である。3D映像は、左目で視聴すべきレフトビュー映像と、右目で視聴すべきライトビュー映像とを共に再生して、これらレフトビュー映像、ライトビュー映像で立体視効果を発揮することにより、ユーザによる視聴に供される。3D映像における画素のうち、正のZ軸座標をもつものをユーザは、表示装置の画面より手前にあると感じ、負のZ軸座標をもつものを、画面より奥に存在すると感じる。
光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置（以下、「2D再生装置」と呼ぶ）との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3D映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの２種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置（以下、「2D/3D再生装置」）では、2D映像もしくは3D映像として再生できることが求められる。
3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献１に記載されたものがある。
特許第３９３５５０７号公報
ところで従来の2D再生装置と互換性を維持しつつ、再生装置に3D再生モードを導入しようとすると、再生モードが2D再生モードから3D再生モードに切り替わるという事象をストリーム選択プロシージャでどのように扱うかが問題になる。
ストリーム選択プロシージャとは、記録媒体に物理的に記録されている複数のエレメンタリストリームのうち、どれの再生が許可されているかを、記録媒体におけるテーブル(ストリーム選択テーブルという)に登録しておき、このストリーム選択テーブルに登録されているストリームの中から、多重分離の対象となるエレメンタリストリームのストリーム番号を決定する処理手順のことである。
ストリーム選択プロシージャによって決定されたストリーム番号は、再生装置におけるストリーム番号レジスタに格納される。またストリーム選択プロシージャは、再生装置の状態変化が生じた際、例えば、再生区間の切り替わりやディスクローディグ等がなされた際、実行される。ここで従来の2D再生装置の考えの延長線に立つと、再生モードの変化を装置状態の変化と捉えて、ストリーム選択プロシージャを実行し、ストリーム番号を設定しなおすという考えになる。
しかし、再生モードの変化に伴いストリーム選択プロシージャが実行され、新しいストリーム番号がストリーム番号レジスタに格納されれば、モード変化後のストリームの言語属性が同じになるとの保障はどこにもない。各ストリームがどのような言語属性であるかは、ストリーム選択テーブルにおいてストリーム番号で管理されているので、ストリーム番号が変われば、ストリーム属性も変わってしまうからからである。この場合、モード切り替え後に、改めてストリームを設定するという二度手間が必要になり、ユーザにとって使い勝手が悪いものになる。
本発明の目的は、再生モードの切り替え前後で、言語属性の同一性を維持することができる記録媒体を提供することである。
上記課題を解決するため、本発明にかかる記録媒体は、プレイリスト情報と、複数のエレメンタリストリームとが記録された記録媒体であって、
前記プレイリスト情報は、基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを含み、
前記基本ストリーム選択テーブルは、ストリーム番号に対応付けられた、平面視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
前記拡張ストリーム選択テーブルは、前記ストリーム番号と同一のストリーム番号に対応付けられた、立体視再生モードにおいて再生されるエレメンタリストリームのリストを示すことを特徴とする。
上述したような課題解決手段を具備した記録媒体によると、再生装置の再生モードが、平面視再生モードから立体視再生モードに変化した場合、ストリーム選択の基準は、基本ストリーム選択テーブルから、拡張ストリーム選択テーブルに切り替えわることになる。

この場合、平面視再生モードから立体視再生モードへの変化時において、ストリーム番号レジスタにおけるストリーム番号をそのままにし、ストリームの言語属性を変化前後で維持したまま、デコーダに供給すべきストリームを切り替えることができる。
こうすることで、言語属性を維持したまま、平面視再生モードから立体視再生モードに再生モードを変化させることが可能になるし、また立体視再生モードから平面視再生モードへと再生モードを変化させることが可能になる。
また平面視再生モードにおけるストリーム選択プロシージャの手順は、基本ストリーム選択テーブルのみに基づくので、平面視再生モードにおけるストリーム選択プロシージャの内容は、平面視専用の再生装置のストリーム選択プロシージャのものと同一のものにすることができる。ストリーム選択プロシージャの完全互換を保障することができるので、立体視再生に対応した記録媒体が、従来の平面視専用の再生装置に装填された場合の動作保障を容易にすることができる。立体視再生に対応した記録媒体が、従来の平面視専用の再生装置に装填された場合に、従来通りの動作がなされることが保障されるので、再生装置の製造主体は、立体視再生に対応した記録媒体が、従来の平面視専用の再生装置に装填されることによるユーザトラブルに巻き込まれず、安心して市場に、立体視再生に対応した記録媒体を送り出すことができる。
記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。 ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を左目から見た場合の例を示す。 立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。 1plane＋Offsetモードにおける立体視の実現の仕方を示す。 オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。 デプスビュー方式の一例を示す。 3D-Depthモードで生成される立体視画像を示す。 第１実施形態に係る記録媒体における内部構成を示す。 PESパケット列に、ビデオストリームがどのように格納されるかを示す。 メインTSがどのように多重化されるかを模式的に示す。 メインTS及びサブTSの内部構成を示す。 プレイリスト情報の内部構成を示す。 基本ストリーム選択テーブルの一例を示す。 拡張ストリーム選択テーブルの内部構成を示す。 拡張ストリーム選択テーブルにおけるストリーム登録列を示す。 メインTS、サブTSからどのようなエレメンタリストリームが多重分離されるかを示す。 基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。 モードにおけるストリーム番号の割り当て変化を示す。 オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。 再生装置の内部構成を示す。 結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。 結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。 再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。 再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す。 プレイリスト再生手順を示す。 ストリーム選択プロシージャの処理手順を示す。 ストリーム番号に対応するパケット識別子の出力処理の手順を示す。 エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。 インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。 立体視インターリーブドストリームファイル、ファイル2D、ファイルベースの相互関係を示す。 2Dプレイリスト、3Dプレイリストを示す。 3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。 3Dプレイリストに、ベースビューインディケータを書き加えた図である。 ストリームファイルからのソースパケットの読出手順を示す。 第４実施形態に係るプレイアイテム情報、サブプレイアイテムを示す。 プレイアイテム情報、サブプレイアイテム情報によるマルチアングル区間の指定を示す。 各アングル番号が設定された場合の立体視映像を示す。 ストリーム参照情報、Multi_clip_entrieに従ったストリームファイルの読み出し手順を示す。 クリップ情報ファイルの内部構成を示す。 クリップ情報ファイルにおけるエントリーマップテーブルと、エクステントスタートポイント情報とを示す。 プログラム情報におけるストリーム属性情報を示す。 エントリーマップによるエントリーポイントの登録を示す。 立体視インターリーブドストリームファイルを構成するデータブロックからATCシーケンスがどのように復元されるかを示す。 ATCシーケンス復元部を具備した読出部の内部構成を示す。 ATCシーケンス復元手順を示す。 ビデオストリームの内部構成を示す。 スライドショーに対し、設定されたエントリーマップの内部構成を示す。 スライドショープレイリストの再生手順を示す。 多重分離部及びビデオデコーダの内部構成を示す。 3D-LR方式、3D-Depth方式における１デコーダ＋２プレーンの装置構成を示す。 PGストリームのグラフィクスデコーダの内部構成を示す。 テキスト字幕デコーダの内部構成を示す。 IGデコーダのデコーダモデルを示す。 デコーダモデルの出力を、3D-LR方式で出力するための回路構成を示す。 デコーダモデルの出力を、1plane＋Offsetモード方式で出力するための回路構成を示す。 多層化された光ディスクの内部構成を示す。 ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。 記録方法の処理手順を示す。 AVファイル書込工程の処理手順を示す。 記録媒体の製造方法を示す。 記録装置の内部構成を示す。 2D/3D再生装置の構成を示す。 システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す。 レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図である。 出力モードの選択モデルの状態遷移を示す。 Initializationの処理手順を示す。 Procedure when playback condition is changedの処理手順を示す。 3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。 プレーン合成部の内部構成を示す。 2D用3D用のコンテンツが混在するデータ、また再生装置におけるその再生方法を示す。 2D/３Dの切り替えを示す。 ディペンデントビューのケーパビリティ、3D-Depthビューのケーパビリティを示す。 ３D再生能力をさらに細かく識別するために拡張したシステムパラメータを示す。 再生装置が３D用に拡張されたデータ構造に対応しているか否かを識別するデータベース識別情報を示す。 ユーザーの表示形式の好みを設定するシステムパラメータを示す。 現在再生中の表示形式を示すシステムパラメータである。 3Dオフセットの補正値を格納しておくためのビットアサインを示す。 2Dや３Dの表示形式を切り替えるユーザーオペレーションAPIを示す。 Change 3D Offsetモードコマンドのオペコード、オペランドを示す。 Change3DPresentationTypeコマンドを示す。 3モードのためのTSをどのようにファイルに格納するかを示す。 TSレベルでの多重化を表形式で示す。 TSパケットのPID割り当てを示す。 プライマリビデオストリーム、プライマリオーディオストリームを示す。 PGストリーム、IGストリーム、テキスト字幕ストリームを構成するTSパケットを示す。 セカンダリビデオストリーム、セカンダリオーディオストリームを構成するTSパケットを示す。 2つのプレイアイテムをシームレスに接続する形態を示す。 層境界で参照ファイルを切り替えるためのSubpathタイプを示す。 プライマリビデオストリーム、プライマリオーディオストリームのストリーム登録列の記述の仕方を示す。 PGストリームのストリーム登録列の記述の仕方を示す。 IGストリームのストリーム登録列の記述の仕方を示す。 セカンダリオーディオストリーム、セカンダリビデオストリームのストリーム登録列の記述の仕方を示す。 テキスト字幕ストリームのプレーンオフセットの時間的変化を表す。 背景画像をなすIピクチャを示す。 2D/3D再生装置を集積回路を用いて実現した構成例である。 ストリーム処理部の代表的な構成を示す機能ブロック図である。 切替部がDMACであった場合の切替部６５３周辺の概念図である。 AV出力部の代表的な構成を示す機能ブロック図である。 AV出力部もしくは再生装置のデータ出力部分を詳細に示した構成例である。 集積回路における制御バス及びデータバスの配置を示した図である。 集積回路における制御バス及びデータバスの配置を示した図である。 再生装置における動作手順を簡単に示したフローチャートである。 再生装置における動作手順を詳細に示したフローチャートである。
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目とでは、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、１つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
また、本願明細書における再生装置とは、2D再生モード、3D再生モードという2つの再生モードを具備しており、これらの相互切り替えを可能とする2D/3D再生装置(プレーヤ)である。
図１は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。同図（ａ）に示すように、記録媒体の一例である記録媒体１００、再生装置２００は、テレビ３００、3D眼鏡４００、リモコン５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、表示装置３００と接続され、記録媒体１００を再生する。
表示装置３００はテレビであり、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置３００は、3D眼鏡４００をユーザが着用することで立体視を実現するものだが、表示装置３００がレンチキュラー方式のものなら、3D眼鏡４００は不要となる。レンチキュラー方式の表示装置３００は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
3D眼鏡４００は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。 同図（ｂ）は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡４００は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図（ｃ）は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
リモコン５００は、AV再生のための操作項目を受け付けるための機器である。またリモコン５００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン５００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
図１のホームシアターシステムにおいて、3D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを"3D出力モード"という。2D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを"2D出力モード"という。
以上が、記録媒体及び再生装置の使用形態についての説明である。
本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。
視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図２は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。視点間の相関特性を利用したビデオ圧縮の方法としては、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によって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを"ベースビュービデオストリーム"という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、後述するベースビューインディケータによって定まる。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、"ディペンデントビュービデオストリーム"という。
視点間の相関性に基いて圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームであって、単体で復号化が可能になるものを"ベースビュービデオストリーム"という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、プレイアイテム情報内のベースビューインディケータによって定まる。
MVCビデオストリームの基礎となるMPEG4-AVC形式のビデオストリームについて説明する。
MVCビデオストリームは、GOP構造を有しており、クローズドGOP、オープンGOPから構成される。クローズドGOPは、IDRピクチャと、このIDRピクチャに続くBピクチャと、Pピクチャとから構成される。オープンGOPは、Non-IDR Iピクチャと、Non-IDR Iピクチャに続くBピクチャと、Pピクチャとから構成される。
Non-IDR Iピクチャ、Pピクチャ、Bピクチャは、他のピクチャとのフレーム相関性に基づき圧縮符号化されている。Bピクチャとは、Bidirectionally predictive(B)形式のスライスデータからなるピクチャをいい、Pピクチャとは、Predictive(P)形式のスライスデータからなるピクチャをいう。Bピクチャには、refrenceB(Br)ピクチャと、nonrefrenceB(B)ピクチャとがある。
クローズドGOPは、IDRピクチャが先頭に配置される。表示順序においてIDRピクチャは先頭にならないが、IDRピクチャ以外の他のピクチャ(Bピクチャ，Pピクチャ)は、クローズドGOPより前のGOPに存在するピクチャと依存関係をもつことはできない。このようにクローズドGOPは、依存関係を完結させる役割をもつ。
次にGOPの内部構成について説明する。オープンGOP、クローズドGOPにおける個々のピクチャデータは、H.264符号化方式におけるビデオアクセスユニット構造を有している。各ビデオアクセスユニットは、ビデオアクセスユニットデリミター、シーケンスパラメータセット、ピクチャパラメータセット、ビューコンポーネントを配列することにより構成される。
ビューコンポーネントとは、アクセスユニット構造を有しつつも、視点間の相関性に基づき圧縮符号化されているピクチャデータである。
ビデオアクセスユニットデリミターは、ネットワーク抽象化ユニットに変換されてソースパケットに格納される。このソースパケットからの読み出しを行うのであれば、ビデオストリーム内部におけるランダムアクセスが可能になる。
ビデオアクセスユニットと、ピクチャとの関係は、１ビデオアクセスユニット ＝ １ピクチャである。またBD-ROMでは、１PESパケット ＝ １フレームに制限されている。つまり、動画がフレーム構造であれば、１PESパケット ＝ １ピクチャであり、フィールド構造である場合、１PESパケット＝２ピクチャとなる。これらのことから、PESパケットは、ピクチャを、１対１の比率で格納している。
図３は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。
本図の第２段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータ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の順序で再生することで、左目画像が再生されることになる。
第４段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、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ピクチャを参照している。ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを１／４８秒の表示周期において、"Ｂ"ー"Ｄ"ー"Ｂ"ー"Ｄ"というように交互で出力するモードを、"B−Dプレゼンテーションモード"という。
ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを交互に出力するのではなく、再生モードを3Dモードに維持したまま、同じビデオフレームを2回以上繰り返し出力するという処理を行う再生タイプを、B−Bプレゼンテーションモードという。B−Bプレゼンテーションモードでは、単独再生可能なベースビュービデオストリームのビデオフレームのみが"Ｂ"−"Ｂ"−"Ｂ"−"Ｂ"というように繰り返し出力される。
以上のB−Dプレゼンテーションモード、B−Bプレゼンテーションモードが、再生装置の再生モードの基本となるが、これらのモード以外にも、再生装置には、1plane＋Offsetモードという再生モードが存在する。
1plane＋Offsetモード(3D-Offsetモードともいう)は、プレーンメモリの後段にシフト部を組込んで、シフト部を機能させることで立体視を実現する再生モードである。プレーンオフセット部は、レフトビュー期間及びライトビュー期間のそれぞれにおいて、プレーンメモリにおけるライン単位の画素の座標を、左方向又は右方向にシフトさせ、右目視線及び左目視線の結像点を手前方向、又は、奥行方向に変位させることで奥行き感を変化させる。具体的には、レフトビュー期間で左方向、ライトビュー期間で右方向に、画素座標を変化させれば、両目の視線の結像点は手前になり、レフトビュー期間で右方向、ライトビュー期間で左方向に、画素座標を変化させれば、両目の視線の結像点は手前になる。
かかるプレーンシフトでは、立体視のためのプレーンメモリが1プレーンで足りるので、簡易に立体視映像を作り出すのに最適である。このプレーンシフトでは、平面的な映像が手前に来たり、奥に引込んだりするという立体視映像を産み出すに過ぎないから、メニューや字幕の立体視効果には適しているものの、キャラクターや物体の立体視効果の実現にはやや物足りない。キャラクターの顔のくぼみや凹凸等が再現できないからである。
1plane＋Offsetモードをサポートする場合、再生装置の構成は以下の通りになる。グラフィクスの再生のため、再生装置にはプレーンメモリと、CLUT部、合成部が存在しており、このCLUT部、合成部の間にプレーンシフト部が組み入れられる。そして、シフト部は、ディペンデントビュービデオストリームのアクセスユニット構造に組込まれたオフセットシーケンスにおけるオフセットを用いて、上述したような画素の座標変化を実現する。こうすることで、1plane＋Offsetモードにおける画素の飛び出度合は、MVCビデオストリームと緻密に同期したものになる。この1plane＋Offsetモードの中には、1plane＋Zero Offsetモードがある。1plane＋Zero Offsetモードは、ポップアップメニューがオンである場合、オフセット値をゼロにして、ポップアップメニューだけに立体視効果を与える表示モードである。
図４は、1plane＋Offsetモードにおける立体視の実現の仕方を示す。
1plane＋Offsetモードにおいて、レフトビュービデオを出力する場合、PGプレーンと呼ばれるプレーンメモリに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後、他のプレーンとの合成に供する（図４上段参照）。
ライトビュービデオを出力する場合、プレーンメモリをオフセット値だけX軸の負の方向をずらし、レフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後にプレーンとの合成に供する（図４下段参照）。
図５は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクロッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。
更に、B−Dプレゼンテーションモードには、Ｌ画像、Ｒ画像を用いて立体視効果を実現する3D-LR方式の他、2D画像と、深度情報とを用いて立体視効果を実現する3D-Depth方式がある。
3D-Depth方式とは、ビデオデコーダの後段に、視差映像生成器を組み入れて、ビデオストリームにおける個々のピクチャデータと、このピクチャデータにおける個々の画素の深度情報とからレフトビューピクチャデータ、ライトビューピクチャデータを作り出させるモードである。
この深度情報は、画素の深度を濃淡で表すグレースケールのピクチャデータ(深度情報ピクチャデータと呼ばれる)として構成することができる。
図６は、デプスビュー方式の一例を示す。同図（ａ）は、2D画像であり、同図（ｂ）は、（ａ）に示した2Dに対して作成されたグレースケールを示す。グレースケールは、輝度成分のみの画素によって表現される。グレースケールの画素のうち、輝度が高いもの程(白いもの程)、奥行きが浅く、輝度が低いもの程(黒いもの程)、奥行きが深いことを示す。同図（ｃ）、（ｄ）は、グレースケールを用いることで生成される左目映像、右目映像を示す。図７は、3D-Depthモードで生成される立体視画像を示す。2Dの各フレーム毎に、左目映像、右目映像を生成すれば、ゴーグルを通じて左目映像、右目映像を見ることで、ユーザは立体視を楽しむことができる。
3D-Depth方式では、2D再生可能なビデオストリームがベースビュービデオストリームになる。グレースケールのピクチャデータから構成されるビデオストリームが、ディペンデントビュービデオストリームになる。
3D-Depthモードと、3D-LRモードとでは、ベースビュービデオストリームは共通化することができるため、ベースビュービデオストリームに組合せるべきビデオストリームを変化させれば、3D-LRモード、3D-Depthモードの映像を生成することができる。データ管理構造からこれらの組み合わせを扱い、プレーヤおよび接続されているテレビ側の特性に合わせて、表示方法を切り替える。3D-Depthモードは、再生装置に専用のハードウェアが必要であるので、特に断らない限り、本明細書で述べる記録媒体、再生装置は、3D-Depthモードに対応しないものとする。
(第１実施形態)
本願明細書の第１実施形態は、複数種別のエレメンタリストリームの選択をどのように行わせるかの改良に関する。
図８は、第１実施形態に係る記録媒体における内部構成を示す。本図（ａ）に示すように、第１実施形態に係る記録媒体には、「インデックステーブルファイル」、「動作モードオブジェクトのプログラムファイル」、「プレイリスト情報ファイル」、「ストリーム情報ファイル」、「ストリームファイル」が記録されている。
＜インデックステーブルファイル＞
インデックステーブルファイルは記録媒体全体に関する管理情報であり、再生装置への挿入後に、インデックステーブルファイルが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルファイルは、光ディスクのタイトル構造を構成する個々のタイトルと、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。タイトル構造とは、光ディスクの装填時に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を伴うタイトル(ファーストプレイタイトル)の再生を開始し、ファーストプレイタイトルの再生後、映画作品の本編を構成する一般タイトル("１"、"２"、"３"というようなシリアル番号で識別される一般的なタイトル)の再生を行い、本編タイトルの再生が終了すれば、タイトル選択を受け付けるタイトル(メニュータイトル)を再生してユーザによる一般タイトルの選択待ちを行うというものである。映画作品と、タイトルとの関係は、映画作品と、それの複数バージョンとの関係である。つまり1つのバージョンしかないような映画作品は、「映画作品＝タイトル」という関係になる。映画作品に、劇場公開版、ディレクターズカット版、TV放映版等、複数のバージョンがある場合、映画作品における個々のバージョンが1つのタイトルになる。再生装置には、カレントのタイトル番号を格納するタイトル番号レジスタを含み、複数のタイトルのうち、このタイトル番号レジスタに格納されているものが、現在の再生対象になる。光ディスクのタイトルは、上述したようなファーストプレイタイトル、一般タイトル、メニュータイトルのそれぞれに、動作モードを規定する動作モードオブジェクトを割り当てることで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。インデックステーブルでは、タイトルと、ビデオストリームとの関係を直接記述せず、タイトルと、動作モードオブジェクトとの関係を記述して、動作モードオブジェクトを通じてビデオストリームを再生させるようになっている。これば、AV再生を伴わず、動作モードオブジェクトを動作させるだけのタイトルを規定するためである。

＜動作モードオブジェクトのプログラムファイル＞
動作モードオブジェクトのプログラムファイルは、再生装置の動作モードを規定するプログラムである動作モードオブジェクトを格納している。動作モードオブジェクトには、コマンドによって記述されたものと、オブジェクト指向のコンパイラ言語によって記述されたものがある。前者の動作モードオブジェクトは、コマンドベースの動作モードにおいて、複数のナビゲーションコマンドをバッチジョブとして再生装置に供給し、これらナビゲーションコマンドに基づき再生装置を動作させる。このコマンドベースの動作モードを、"HDMVモード"と呼ぶ。
後者の動作モードオブジェクトは、オブジェクト指向型のコンパイラ言語ベースの動作モードにおいて、クラス構造体のインスタンスを再生装置に供給し、このインスタンスに基づき再生装置を動作させる。クラス構造体のインスタンスには、Java(TM)アプリケーションを用いることができる。オブジェクト指向型コンパイラ言語ベースの動作モードを、"BD-Jモード"と呼ぶ。
＜プレイリスト情報ファイル＞
プレイリスト情報ファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。"プレイリスト"とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの"型"を定義する。プレイリスト情報によって定義される再生経路は、いわゆる"マルチパス"である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。メインパスは1本であるのに対して、サブパスは、複数本定義することができ、これら複数のサブパスは、サブパスIDと呼ばれる識別子によって識別される。かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。BD-Jモードでは、再生制御のためのJava(TM)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(TM)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMF(JavaMedia Frame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。HDMVモードでは、プレイリストによる再生を命じるナビゲーションコマンドを再生装置に実行させることで、再生を開始することができる。再生装置には、カレントのプレイリスト情報の番号を格納するプレイリスト番号レジスタを含み、複数のプレイリスト情報のうち、このプレイリスト番号レジスタに格納されているものが、現在の再生対象になる。
＜ストリーム情報ファイル＞
ストリーム情報ファイルは、ストリームファイルのそれぞれと一対一の割合で存在するクリップ情報ファイルであり、ストリームファイル内に存在するソースパケット列がどのようなATCシーケンスを構成するか、それらのATCシーケンス内にどのようなSTCシーケンスが組込まれているのか、ATCシーケンスがどのようなTSであるのかを示す。
ストリーム情報ファイルは、ストリームファイルの中身を明らかにするものなので、ストリームファイル内のTSを再生しようとする場合、そのストリームファイルに対応するストリーム情報ファイルを予めメモリに読み出しておく必要がある。つまり、ストリームファイル再生にあたっては、予めストリーム情報ファイルをメモリに読み出すという前置主義が採用される。このような前置主義を採用しているのは以下の理由による。ストリームファイルに格納されるTSは、欧州デジタル放送規格と互換性があるデータ構造になっているが、放送番組として扱うためのPMT、PCR、PATといった情報はストリーム内に存在するため、これらを再生する度に取り出すのは賢明ではない。ストリームを再生する度に、低速な記録媒体をアクセスしてTSを構成するパケットを読み出し、そのTSパケットのペイロードを解析するという処理が必要になるからである。そこで、TSを構成するペイロードの中身を解析することなく、TSの諸元を把握できるよう、TSを格納したストリームファイルと一対一の比率でストリーム情報ファイルを設けておき、ストリーム再生に先立ち、ストリーム情報ファイルをメモリに読み出すことにしている。
＜ストリームファイル＞
ストリームファイルは、１又複数のソースパケット列を格納している。ソースパケットとは、２ビットのコピーパーミッションインディケータと、３０ビットのATS（到着時刻：Arrival Time Stamp）とから構成される４バイトのTP＿Extra＿Headerが付加されたTSパケットである。TP＿Extra＿HeaderにおけるATSは、実時間伝送が行われ、等時性が確保された状態での伝送における到達時刻をいう。
これらのソースパケット列のうち、アライバルタイムクロック(ATC)時間軸において、タイムスタンプが連続している複数のソースパケットから構成されているものを"ATCシーケンス"と呼ぶ。"ATCシーケンス"とは、ソースパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(no arrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、連続性が存在するソースパケット列を"ATCシーケンス"という。ATCシーケンスは、ATCのタイムスタンプが連続しているソースパケット列であるから、再生装置のアライバルタイムクロックを計時するクロックカウンタが計時を行っている間、ATCシーケンスを構成する各ソースパケットは、連続的なソースパケットデパケッタイジング処理、及び、連続的なパケットフィルタリング処理に供されることになる。
ATCシーケンスがソースパケットの配列であるのに対し、STC時間軸におけるタイムスタンプが連続しているTSパケットの配列をSTCシーケンスという。"STCシーケンス"とは、TSパケットの配列であって、TSのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)をもたないものをいう。STCの不連続点とは、デコーダがSTCを得るために参照するPCR(Program Clock Reference)を運ぶPCRパケットの不連続情報(discontinuity＿indicator)がONである点である。STCシーケンスは、STCのタイムスタンプが連続しているTSパケット列であるから、再生装置のシステムタイムクロックを計時するクロックカウンタが計時を行っている間、STCシーケンスを構成する各TSパケットは、再生装置内に存在するデコーダの連続的なデコード処理に供されることになる。

ストリームファイルにおけるメインTS、サブTSは、ストリームファイルに対応するストリーム情報ファイル内のクリップ情報によって、1つの"AVストリームの切れ端"つまり、"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に対応するストリームの属性情報を持ち、またTSに関する各種ディスクリプタを持つ。ディスクリプタにはストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。
PAT（Program Association Table）は、TS中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルTSを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルTSを扱うかの如く、TSをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、記録媒体再生装置との互換性を意図したものである。TSのうち、マルチパスの基軸となるものを"メインTS"という。またサブパスの基軸となるものを"サブTS"という。
図８（ｂ）は、メインTSの内部構成を示し、図８（ｃ）は、サブTSの内部構成を示す。同図（ｂ）に示すように、メインTSは、１本のベースビュービデオストリームと、３２本のベースビューPGストリーム、３２本のベースビューIGストリーム、３２本のオーディオストリームを含むものとする。同図（ｃ）に示すように、サブTSは、１本のディペンデントビュービデオストリームと、３２本のディペンデントビューPGストリーム、３２本のディペンデントビューIGストリームを含むものとする。
次に、TSの内部構成について説明する。
図９は、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パケット列＞
図９（ｂ）は、TSパケットの形式を示している。第１段目は、TSパケット列を示し、第２段目は、ソースパケット列を示す。
第１段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ４Byteの「TSヘッダ」とデータを格納する１８４Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第２段目によると、TSパケットには、４ByteのTP＿Extra＿Headerが付与されて、１９２Byteのソースパケットに変換された状態で、TSを構成する。TP＿Extra＿HeaderにはATS（Arrival＿Time＿Stamp）などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。TSには、第３段目に示すようにソースパケットが並ぶこととなり、TSの先頭からインクリメントする番号はSPN（ソースパケット番号）と呼ばれる。
＜TSにおける多重化＞
図１０は、メインTSがどのように多重化されるかを模式的に示す図である。まず、ベースビュービデオストリーム、及び、オーディオストリームを(第１段目)、それぞれPESパケット列に変換し(第２段目)、ソースパケット列に変換する(第３段目)。同じくレフトビューPGストリームおよびレフトビューインタラクティブグラフィクス(第７段目)を、それぞれPESパケット列に変換し(第６段目)、更にソースパケット列に変換する(第５段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、メインTSが得られることになる。
・TSに多重化されるエレメンタリストリーム
これらのTSに多重化されるエレメンタリストリーム(ES)は、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームがある。
・ビデオストリーム
ベースビューとなるビデオストリームは、ピクチャインピクチャアプリケーションにおけるプライマリビデオストリームを構成する。ピクチャインピクチャアプリケーションは、このプライマリビデオストリームの他、セカンダリビデオストリームから構成される。プライマリビデオストリームとは、ピクチャインピクチャアプリケーションにおいて親画面となるピクチャデータから構成されるビデオストリームでる。対照的に、セカンダリビデオストリームとは、ピクチャインピクチャにおいて子画面として、親画面の一部にはめ込まれるピクチャデータから構成されるビデオストリームである。
プライマリビデオストリームを構成するピクチャデータと、セカンダリビデオストリームを構成するピクチャデータとはデコード後、別々のプレーンメモリに格納される。セカンダリビデオストリームを構成するピクチャデータを格納するプレーンメモリの前段には、セカンダリビデオストリームを構成するピクチャデータのスケーリング変更及び表示座標の位置決めを行う構成要素(Scalling&Positioning)が存在する。
・オーディオストリーム
オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの２種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。セカンダリオーディオストリームは、このミキシングのためのダウンサンプリングのための情報、ゲイン制御のための情報が存在する。
・プレゼンテーショングラフィクスストリーム(PGストリーム)
PGストリームは、デコーダにパイプラインを採用することで、映像との緻密な同期を実現することができ、字幕表示に適したグラフィクスストリームであり、2DPGストリームと、立体視PGストリームという2つの種類がある。立体視PGストリームには、レフトビューPGストリーム及びライトビューPGストリームという二種類のものがある。レフトビューPGストリーム及びライトビューPGストリームのうち、ベースビューインディケータによって指定されているものがベースビューPGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューPGストリームになる。
2DPGストリームの他に、立体視PGストリームを設けるのは、PGストリームが字幕文字を表す場合、2Dで表示される真正面から見た字幕文字と、3D-LRモードで左目用に表示されるグラフィクスと、右目用に表示される字幕文字とは異なるものにする必要からである。そのため、2D再生の場合は正面から見たグラフィクスストリームを１本、3D-LRモード用にはレフトビューPGストリーム、ライトビューPGストリームの計２本を表示する。同様に、3D-Depthモードの場合は、正面から見た映像と深度情報を示すグレースケールストリームを再生する。2D+offset（2D互換ストリーム）と、3D-LRストリームとは、混在させてはならない。
2DPGストリームは最大３２本、ベースビューPGストリームの最大３２本、ディペンデントビューPGストリームも最大３２本定義することができる。これらのPGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのPGストリームのうち、所望のものが再生に供されることになる。
レフトビューPGストリーム、ライトビューPGストリームは、互いに言語属性は一致させておき、ユーザーが表示方式を切り替えても、同じ内容の字幕が表示されるようにする。前提として、2D字幕と3D字幕とは1対1に対応し、2Dでしかない字幕、及び、3Dでしかない字幕を設けてはならないない。切り替え時のユーザー混乱を防止するためである。こうすることにより、1つのストリーム番号で、2D/3Dそれぞれの表示モードに対応するストリームが選択されることになる。この場合、1つのストリーム番号で言語属性などは同じになり、2DとLRの字幕の内容は同じになる。
パイプラインによるデコード動作の実現により、動画像との緻密な同期を実現するので、PGストリームの用途は字幕のような文字再生に限定されない。映画作品のマスコットキャラクタを表示して、これを動画像と同期させつつ動作させるなど、緻密な同期が必要なグラフィクス再生であれば、どのようなものも、PGストリームによる再生対象として、採用することができる。
ストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。
PGストリーム、テキスト字幕ストリームは、これらの種類が区別されることなく、同じストリーム種別であるとして、これらPGストリーム及びテキスト字幕ストリームは、同じストリーム登録列に登録される。そして、ストリーム選択のプロシージャを実行するにあたって、ストリーム登録列におけるストリーム登録の順位に従い、再生されるべきPGストリーム又はテキスト字幕ストリームが定まる。PGストリーム、テキスト字幕ストリームは、ストリーム種が区別されることなく、ストリーム選択のプロシージャに供されるのでこれらPGストリーム及びテキスト字幕ストリームを1つのストリーム種別、つまり、"PG＿テキスト字幕ストリーム"という種別で扱う。
2D用のPG＿テキスト字幕ストリームは、1plane＋Offsetモードにおいて再生される。以降の説明では、2DPG＿テキスト字幕ストリームを、1plane＋OffsetPG＿テキスト字幕ストリームであるとして説明する。

・インタラクティブグラフィクス(IG)ストリーム
IGストリームは、対話操作の情報を具備することで、ビデオストリームの再生進行に伴ってメニューを表示したり、またユーザ操作に従いポップアップメニューを表示することができるグラフィクスストリームである。
IGストリームもPGストリームと同様、2DIGストリームと、立体視IGストリームという2つの種類がある。立体視IGストリームには、レフトビューIGストリーム及びライトビューIGストリームという二種類のものがある。レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームのうち、ベースビューインディケータによって指定されているものがベースビューIGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューIGストリームになる。2DIGストリームは最大３２本、ベースビューIGストリームは最大３２本、ディペンデントビューIGストリームも最大３２本定義することができる。これらのIGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのIGストリームのうち、所望のものが再生に供されることになる。
IGストリームの制御情報(対話制御セグメントという)は、ユーザインターフェイスモデルを規定する情報(User＿interface＿model)をもっており、オーサリング者は、このユーザインターフェイスモデル情報を設定することで、ビデオストリームの再生進行に伴ってメニューを表示するか(Alwaysオンという)、ユーザ操作に従いポップアップメニューを表示するか(ポップアップメニューオン)の何れかを指定することができる。
IGストリームが対話操作の情報をもつ意義は以下の通りである。Java仮想マシンがアプリケーションからの要求に応じてプレイリスト再生の開始を再生制御の主体である再生制御エンジンに指示する場合、Java仮想マシンは、再生制御エンジンに再生を命じた後、プレイリスト再生を開始した旨のレスポンスをアプリケーションに返す。つまり、再生制御エンジンによるプレイリスト再生が継続している間、Java仮想マシンは、実行終了待ちにはならない。何故なら、Java仮想マシンは、いわゆるイベントドリブン型の動作主体であり、再生制御エンジンがプレイリストの再生を行っている間も、動作を行うことができるからである。
一方、HDMVモードにおいて、コマンドインタプリタが、プレイリスト再生を再生制御エンジンに命じる場合、プレイリスト再生が終了するまで、そのプレイリスト再生の実行終了待ちとなる。再生制御エンジンによる再生が継続している間、コマンド実行部は、対話的な処理を実行することはできない。このコマンドインタプリタの代わりに、グラフィクスデコーダが対話的な動作を行う。グラフィクスデコーダに対話的な動作を行わせるため、IGストリームには、ボタン部材を用いた対話的な操作を規定する制御情報が組込まれている。
・各ストリーム種別において許容される表示モード
3D表示モードのどれが許容されるかは、ストリーム種別によって異なる。プライマリビデオストリームの3D表示モードには、B−Dプレゼンテーションモード、B−Bプレゼンテーションモードといった2つの再生モードが許容される。プライマリビデオストリームにおいて、B−Bプレゼンテーションモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、"立体視B−D再生タイプ"という。B−Bプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、立体視B−B再生タイプという。
PGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。PGストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるPGストリームの類型を、"立体視再生タイプ"という。1plane＋Offsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Offsetタイプという。1plane＋Zero Offsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Zero Offsetタイプという。
テキスト字幕ストリームの3D表示モードには、1plane＋Offsetモード、1plane＋Zero Offsetモードといった2つの再生モードが許容される。テキスト字幕ストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。
IGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。IGストリームにおいて、1plane＋Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。以降の説明では、特に断らない限り3D再生モード実行時には、ピクチャインピクチャは使用できないものとする。ピクチャインピクチャ及び3D再生モードは、何れも非圧縮のピクチャデータを格納するためのビデオプレーンを2つ必要とするからである。また特に断らない限り、3D再生モードでは、サウンドミキシングも使用できないものとする。
続いて、メインTS及びサブTSの内部構成について説明する。図１１は、メインTS及びサブTSの内部構成を示す。
同図（ａ）は、メインTSの内部構成を示す。メインTSは、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはProgram＿Map＿Tableを構成し、0x0101のパケットIDを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケット列は、プライマリビデオストリームを構成する。
0x1220のパケット識別子を有するソースパケット列から0x123FのパケットIDを有するソースパケット列までは、３２本のベースビューPGストリームを構成する。
0x1420のパケット識別子を有するソースパケット列から0x143FのパケットIDを有するソースパケット列までは ３２本のベースビューIGストリームを構成する。
0x1100のパケット識別子を有するソースパケット列から、0x111Fのパケット識別子を有するソースパケット列までは、プライマリオーディオストリームを構成する。
これらのソースパケットのパケット識別子を多重分離部に指示することにより、メインTSに多重化されている複数のESのうち、所望のものを分離してデコーダに供することができる。
図（ｂ）は、サブTSの内部構成を示す。サブTSは、以下のソースパケットによって構成されている。
Ox1012のパケット識別子を有するソースパケット列は、ディペンデントビュービデオストリームを構成し、Ox1240のパケット識別子を有するソースパケット列から0x125Fのパケット識別子を有するソースパケット列までは、３２本のディペンデントビューPGストリームを構成する。
Ox1440のパケット識別子を有するソースパケット列から0x145Fのパケット識別子を有するソースパケット列は、３２本のディペンデントビューIGストリームを構成する。
以上がストリームファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
上述したようなマルチパスを定義するため、図１２のような内部構成を有する。図１２（ａ）は、プレイリスト情報の内部構成を示す。同図（ａ）に示すようにプレイリスト情報は、「メインパス情報」、「サブパス情報」、「プレイリストマーク情報」、「エクステンションデータ」を含む。以下、これらの構成要素について説明する。
１）メインパス情報は、１つ以上の主たる再生区間情報から構成される。図１２（ｂ）は、メインパス情報、及び、サブパス情報の内部構成を示す図であり、本図に示すように、メインパス情報は、１つ以上の主たる再生区間情報から構成される。サブパス情報は、１つ以上の従たる再生区間情報から構成される。
主たる再生区間情報はプレイアイテム情報と呼ばれ、TSの再生時間軸のうち、In＿Timeとなる時点と、Out＿Timeとなる時点の組みを1つ以上定義することにより、論理的な再生区間を定義する情報である。再生装置には、カレントのプレイアイテムの番号を格納するプレイアイテム番号レジスタを含み、複数のプレイリスト情報のうち、このプレイアイテム番号レジスタに格納されているものが、現在の再生対象になる。

図１２（ｃ）は、プレイアイテム情報の内部構成を示す。本図に示すように、「ストリーム参照情報」、「インタイムアウトタイム情報」、「接続状態情報」、「基本ストリーム選択テーブル」を含む。
ストリーム参照情報は、プレイアイテムを構成するトランスポートストリームを"AVクリップ"として管理しているクリップ情報ファイルを示す「クリップ情報ファイルネーム情報(clip＿information＿file＿name)」、そのTSにおける符号化方式を示す「クリップ符号化方式識別子(Clip＿codec＿indentifier)」、当該TSのSTCシーケンスにおいて、インタイム及びアウトタイムが設定されているSTCシーケンスがどれであるかを示す「STC識別子レファレンス(STC＿ID＿referrence)」を含む。
以上がプレイアイテム情報についての説明である。
２）従たる再生区間情報は、サブパス情報と呼ばれ、複数のサブプレイアイテム情報から構成される。図１２（ｄ）は、サブプレイアイテム情報の内部構成を示す。本図に示すように、サブプレイアイテム情報は、STCシーケンスの時間軸にインタイムと、アウトタイムとの組みを規定することで、サブパスを構成する再生区間を定義する情報であり、「ストリーム参照情報」、「インタイムアウトタイム情報」、「シンクロプレイアイテムレファレンス」、「シンクロ開始時刻情報」を含む。 『ストリーム参照情報』は、プレイアイテム情報と同様、『クリップ情報ファイルネーム情報』『クリップ符号化方式識別子』、『STC識別子レファレンス』を含む。
『インタイムアウトタイム情報(SubPlayItem_In_Time,SubPlayItem_Out_Time)』は、STCシーケンス時間軸における、サブプレイアイテムの始点と、STCシーケンス時間軸上における、サブプレイアイテムの終点とを示す。
「シンクロプレイアイテムレファレンス(Sync_PlayItem_Id)」は、プレイアイテムのうち、本サブプレイアイテムが同期すべきものを一意に指定する情報である。サブプレイアイテムインタイムは、この同期プレイアイテム参照子で指定されたプレイアイテムの再生時間軸上に存在する。
「シンクロ開始時刻情報(Sync_Start_PTS_of_PlayItem)」は、同期プレイアイテム参照子で指定されたプレイアイテムのSTCシーケンスの時間軸のうち、サブプレイアイテムインタイムで指定されたサブプレイアイテムの始点が、どの時点に写像されるかを示す

３）プレイリストマーク情報は、再生区間固有のマークポイントを定義する情報であり、再生区間を示す参照子と、デジタルストリームの時間軸において、マークポイントが何処にあるかを示すタイムスタンプと、マークポイントの属性を示す属性情報とを含み、
前記属性情報は、プレイリストマーク情報により定義されたマークポイントが、リンクポイントであるか、エントリーマークであるかを示す。
リンクポイントは、リンクコマンドによるリンクが可能であるが、チャプタースキップ操作がユーザによりなされた場合の選択対象にはならないマークポイントである。
エントリーマークは、リンクコマンドによるリンクが可能であり、尚且つチャプタースキップ操作がユーザによりなされた場合の選択対象になるマークポイントである。
IGストリームのボタン情報内に組込まれたリンクコマンドは、プレイリストマーク情報を介した間接参照の形式で頭出し位置を指定している。
＜基本ストリーム選択テーブル(STreamNumber＿table)＞
前記基本ストリーム選択テーブルは、平面視再生モードにおいて再生すべきエレメンタリストリームのリストであり、プレイリストを構成する複数のプレイアイテムのうち、その基本ストリーム選択テーブルを包含しているのものがカレントプレイアイテムになった際、マルチパスのメインパスにて参照されているAVクリップに多重化されているES、及び、マルチパスのサブパスにて参照されているAVクリップに多重化されているESのうち、どれの再生を許可するかを、複数のストリーム種別毎に規定する。ここでのストリーム種別とは、ピクチャインピクチャにおけるプライマリビデオストリーム、ピクチャインピクチャにおけるセカンダリビデオストリーム、サウンドミキシングにおけるプライマリオーディオストリーム、サウンドミキシングにおけるセカンダリオーディオストリーム、PG＿テキスト字幕ストリーム、インタラクティブグラフィクストリームといった種別をいい、基本ストリーム選択テーブルは、これらのストリーム種別毎に、再生を許可すべきストリームを登録することができる。具体的には、基本ストリーム選択テーブルは、ストリーム登録の配列から構成される。ここでストリーム登録とは、基本ストリーム選択テーブルが帰属しているプレイアイテムがカレントプレイアイテムになった際、再生を許可すべきESがどのようなストリームであるかを、そのストリーム番号に対応付けて示すものであり、ストリーム登録は、論理的なストリーム番号に、ストリームエントリー及びストリーム属性の組合せを対応付けるというデータ構造になっている。 ストリーム登録におけるストリーム番号は、１、２、３というような整数値で表現され、ストリーム番号の最大数は、対応するストリーム種別のストリーム本数となる。
再生装置には、このストリーム種別毎に、ストリーム番号レジスタが存在しており、ここに格納されたストリーム番号で指示されるESが、現在再生対象になっているES、つまりカレントストリームになる。
このストリームエントリー内に、再生すべきESのパケット識別子が記述される。ストリームエントリー内に、再生すべきESのパケット識別子を記述することができるので、ストリーム登録におけるストリーム番号を再生装置のストリーム番号レジスタに格納し、ストリーム登録におけるストリームエントリー内のパケット識別子に基づいて再生装置のPIDフィルタにパケットフィルタリングを再生装置に実行させる。こうすることで、基本ストリーム選択テーブルにおいて再生が許可されたESのTSパケットがデコーダに出力され、ESの再生がなされることになる。
基本ストリーム選択テーブルにおけるこれらのストリーム登録は、ストリーム番号の順序に従って並べられており、ストリーム番号の順序に基づくストリーム登録の順位は、"再生装置が再生することができる""再生装置の言語設定と同じ言語属性をもつ"との条件を満たすストリームが複数存在する場合、ストリーム登録列におけるストリーム番号の順位によって、選択対象となるストリームが決定される。
こうすることで、基本ストリーム選択テーブルにおけるストリーム登録の中に、再生装置が再生できないものが存在する場合、かかるストリームは再生から除外されることになり、また、再生装置が再生することができる"との条件を満たすストリームが複数存在する場合は、それらのうちどれを優先的に選択すべきかという指針をオーサリング者は再生装置に伝えることができる。
"再生装置が再生することができる""再生装置の言語設定と同じ言語属性をもつ"との条件を満たすストリームが存在するかどうかという判定や、"再生することができる"との条件を満たすストリームのうちどれを選択するかという選択手順は、ストリーム選択プロシージャと呼ばれる。ストリーム選択プロシージャは、カレントプレイアイテムが新しいものに切り替った際、また、ユーザからストリーム切り替えが要求された際、実行される。

カレントプレイアイテムが新しいものに切り替わる等、再生装置の状態変化が生じた際、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を"状態変化時に実行すべきプロシージャ"という。ストリーム番号レジスタは、ストリーム種別毎に存在するから、上記プロシージャは、ストリーム種別ごとに実行されることになる。
ストリーム切り替え要求がユーザによってなされた場合、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を"ストリーム変化が要求された際のプロシージャ"という。
BD-ROMが装填された際、ストリーム番号レジスタをストリーム登録列における初期値に設定しておくとの手順を、"初期化"という。
基本ストリーム選択テーブルにおけるストリーム登録列は、サブプレイアイテム情報によって指定されているストリームと、プレイアイテム情報によって指定されているストリームとに一律に優先順序を付与しているので、ビデオストリームとは多重化されていないストリームであっても、サブプレイアイテム情報によって指定されていれば、ビデオストリームと同期再生すべきストリームの選択にあたっての選択の対象となる。
そして、サブプレイアイテム情報にて指定されたストリームを再生装置が再生することができ、尚且つ、サブプレイアイテム情報にて指定されたストリームの優先順序がビデオストリームと多重化されたグラフィクスストリームの優先順序よりも高い場合は、ビデオストリームと多重化されたストリームの代わりに、サブプレイアイテム情報にて指定されたストリームを再生に供することができる。
図１３は、基本ストリーム選択テーブルの一例を示す。同図（ａ）は、ストリーム種別に、プライマリビデオストリーム、プライマリオーディオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリームといった種別が存在する場合に、基本ストリーム選択テーブルに設けられる複数のストリーム登録列を示す。同図（ｂ）は、基本ストリーム選択テーブルにより、メインTS,サブTSから、どのようなESが分離されるかを示す。同図左側は、メインTS、サブTSを示し、真ん中は、基本ストリーム選択テーブルと、多重分離部とを示す。右側は、基本ストリーム選択テーブルに基づき分離されるプライマリビデオストリーム、プライマリオーディオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリームを示す。
続いて、エクステンションデータの詳細について説明する。
プレイリストがピクチャインピクチャアプリケーションを構成する場合、ピクチャインピクチャメタデータは、プレイリストファイルにおけるエクステンションデータのデータブロックに格納されねばならない。MVCビデオストリームをプレイリスト情報が参照する場合、拡張ストリーム選択テーブルは、プレイリスト情報ファイルのエクステンションデータにおけるデータブロックに格納されねばならない。
ディスク上のMVCビデオストリームや立体視IGストリーム再生メニューにおけるMVCビデオストリームをプレイリスト情報が参照する場合、サブパス情報の拡張情報（サブパスブロックエクステンション）は、プレイリスト情報ファイルにおけるエクステンションデータのデータブロックに格納されねねばならない。
プレイリスト情報におけるエクステンションデータのその他の目的は、保留されている。
2D再生装置は、プレイリストファイルにおけるエクステンションデータに遭遇した際、未知のエクステンションデータを無視せねばならない。
＜拡張ストリーム選択テーブル(STreamNumber_table＿StereoScopic(SS))＞
前記拡張ストリーム選択テーブルは、立体視再生モードにおいて、再生すべきエレメンタリストリームを示すリストであり、立体視再生モードにおいてのみ、基本ストリーム選択テーブルと共に使用され、プレイアイテムの再生や、これに関連するサブパスが再生されている際、選択することができるESを定義する。
前記拡張ストリーム選択テーブルは、立体視再生モードにおいてのみ再生を許可すべきESを示し、ストリーム登録列を含む。ストリーム登録列における個々のストリーム登録情報は、ストリーム番号と、そのストリーム番号に対応するストリームエントリーと、ストリーム属性とを含む。拡張ストリーム選択テーブルは、立体視再生モード固有の拡張を意味するので、各プレイアイテム情報に拡張ストリーム選択テーブル(STN_table_SS)が関連付けられているプレイリストを"3Dプレイリスト"という。
拡張ストリーム選択テーブルにおけるストリームエントリーは、再生装置が立体視再生モードに設定されている場合において、対応するストリーム番号が再生装置におけるストリーム番号レジスタに設定された際、再生装置が多重分離に用いるべきパケット識別子を示す。ここで、基本ストリーム選択テーブルとの違いは、拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象にならない点である。つまり、基本ストリーム選択テーブルにおけるストリーム登録列におけるストリーム登録情報は、個々のESの優先順序と解釈され、何れかのストリーム登録情報内のストリーム番号が、ストリーム番号レジスタに書き込まれる。しかし拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象とはならず、拡張ストリーム選択テーブルにおけるストリーム登録情報は、何れかのストリーム番号がストリーム番号レジスタに格納された際、そのストリーム番号に対応するストリームエントリー及びストリーム属性を取り出すという目的のみに用いられる。
2D再生モードから3D再生モードへと再生モードが切り替った際、対象となるストリーム選択テーブルが、基本ストリーム選択テーブルから拡張ストリーム選択テーブルに切り替ったために、ストリーム選択プロシージャを実行したとなると、ストリーム番号の同一性を維持することができず、強いては、言語属性の同一性も失われる可能性がある。
2D再生モードから3D再生モードへの切り替え時に、言語属性を始めとするストリーム属性の同一性を維持するため、拡張ストリーム選択テーブルの用途を、上記のものにも留めている。
前記拡張ストリーム選択テーブルは、ディペンデントビュービデオストリームのストリーム登録列、PGストリームのストリーム登録列、IGストリームのストリーム登録列から構成される。
拡張ストリーム選択テーブルにおけるストリーム登録列は、基本ストリーム選択テーブルにおける同じストリーム種別のストリーム登録列に結合される。この結合は、ストリーム選択テーブルにおけるプライマリビデオストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるディペンデントビュービデオストリームのストリーム登録列を結合し、ストリーム選択テーブルにおけるPGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録列を結合し、IGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録列を結合することでなされる。
上記の結合がなされれば、結合後のストリーム選択テーブルのうち、基本ストリーム選択テーブルにおけるストリーム登録列に対して上記プロシージャが実行される。
図１４は、拡張ストリーム選択テーブルの内部構成を示す。拡張ストリーム選択テーブルは、拡張ストリーム選択テーブルの全体長(length)、ポップアップ期間固定オフセット(Fixed＿offset＿during＿Popup)、各プレイアイテムにおけるそれぞれのストリーム種別に対応するストリーム登録列から構成される。
ここでプレイアイテム#1〜#NというN個のプレイアイテムが存在する場合、プレイアイテム#1〜#Nのそれぞれに対応するストリーム登録列が、拡張ストリーム選択テーブルに設けられる。各プレイアイテムに対応するストリーム登録列は、ディペンデントビューストリーム登録列、PGストリーム登録列、IGストリーム登録列である。
『Fixed＿offset＿during＿Popup』は、ポップアップ期間固定オフセットであり、IGストリームによるポップアップメニューがオンに設定されている場合、ビデオやPG＿テキスト字幕ストリームの再生タイプを制御する。この『Fixed＿offset＿during＿Popup』フィールドは、IGストリームにおけるuser＿interface＿modelフィールドがオン、つまり、ポップアップメニューのユーザインターフェイスがオンに設定されている場合、オンに設定される。IGストリームにおけるuser＿interface＿modelフィールドがオフ、つまり、AlwaysONのユーザインターフェイスに設定されている場合、オフに設定される。
ポップアップ期間固定オフセット"=0"、つまり、IGストリームのユーザインターフェイスにおいてポップアップメニューがオフに設定されている場合、ビデオストリームはB−Dプレゼンテーションモードとなる。立体視PGストリームは、立体視再生タイプになる。1plane＋Offsetモードの再生時において、PG＿テキスト字幕ストリームは、1plane＋Offsetモードになる。
ポップアップ期間固定オフセット"１"、つまり、IGストリームのポップアップメニューがオンである場合、ビデオストリームはB−Bプレゼンテーションモードとなる。立体視PGストリームは、1plane＋Offsetモードになり、1plane＋Offset用のPGストリームは、1plane＋Zero offset再生タイプとして再生される。
1plane＋OffsetモードにおいてPG＿テキスト字幕ストリームは、1plane＋Zero offsetになる。
『オフセットシーケンス本数情報(図中のnumber＿of＿offset＿sequence)』は、ディペンデントビューストリームにおけるオフセットシーケンスの個数を示す。
拡張ストリーム選択テーブルにおけるこの値は、ディペンデントビューストリームに含まれるオフセットシーケンスの個数と同じになる。
図１５は、拡張ストリーム選択テーブルにおけるストリーム登録列を示す。
図１５（ａ）は、ディペンデントビュービデオストリームのストリーム登録列の内部構成を示す。ディペンデントビューストリームのストリーム登録列は、v(x)個のSS＿dependet＿view＿blockから構成される。ここで、v(x)とは、プレイアイテム情報#xの基本ストリーム選択テーブルにおいて、再生が許可されているプライマリビデオストリームの本数である。図中の引き出し線は、ディペンデントビューストリームのストリーム登録列の内部構成をクローズアップして示している。引出線に示すように、SS＿dependet＿view＿blockは、ストリーム番号と、ストリームエントリーと、ストリーム属性と、number＿of＿offset＿sequenceとから構成される。
ストリームエントリーは、ディペンデントビュービデオストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビュービデオストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビュービデオストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
『ストリーム属性』は、ディペンデントビュービデオストリームの言語属性を含む。
『number＿of＿offset＿sequence』は、ディペンデントビュービデオストリーム内に存在するオフセットの本数を示す。
図１５（ａ）においてディペンデントビュービデオストリームのストリーム登録列は、データ構造上、複数のディペンデントビュービデオストリームについてのストリーム登録情報を設けるものになっている。通常、ベースビュービデオストリームの本数は1つであるから、ディペンデントビュービデオストリームにおけるストリーム登録情報の個数も唯一つになる。
図１５（ｂ）は、PGストリームのストリーム登録列の内部構成を示す。PGストリームのストリーム登録列は、P(x)個のストリーム登録情報から構成される。ここで、P(x)とは、プレイアイテム情報#xの基本ストリーム選択テーブルにおいて、再生が許可されているPGストリームの本数である。
図中の引き出し線は、PGストリーム登録列の共通の内部構成をクローズアップして示している。
『PGtextST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリームオフセットシーケンスレファレンス情報であり、1plane＋OffsetモードのPG＿テキスト字幕ストリームについてのオフセットシーケンスを指示する。
オフセットメタデータは、ディペンデントビュービデオストリームのアクセスユニットによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋Offsetモードタイプのプレゼンテーショングラフィクス(PG)プレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。
『is＿SS＿PG』は、PGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する立体視プレゼンテーショングラフィクス存否フラグである。立体視PGストリームにおける構造が存在しない場合、このフィールドは0に設定されねばならない。立体視PGストリームにおける構造が存在する場合、このフィールドは1に設定されねばならない。
『stream＿entry＿for＿base＿view』は、ベースビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるベースビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報におけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューPGストリームを格納しているストリームファイルを改めて読み出さねばならない。
『stream＿attribute』は、ベースビューPGストリーム及びディペンデントPGストリームの言語属性を含む。
『SS＿PG＿textST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリーム用のオフセットシーケンスを参照するためのレファレンス情報であり、PG＿テキスト字幕ストリームのためのオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットをPGプレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。

図１５（ｃ）は、IGストリームのストリーム登録列の内部構成を示す。IGストリームのストリーム登録列は、I(x)個のストリーム登録情報から構成される。ここで、I(x)とは、プレイアイテム情報#xの基本ストリーム選択テーブルにおいて、再生が許可されているIGストリームの本数である。図中の引き出し線は、ストリーム登録列の共通の内部構成をクローズアップして示している。
『IG＿offset＿sequence＿id＿ref』は、インタラクティブグラフィクスオフセットシーケンスレファレンスであり、1plane＋OffsetモードのIGストリームのシーケンスIDのレファレンスである。この値は、オフセットシーケンスに定義されているオフセットシーケンスIDを指示する。上述したように、オフセットメタデータは、ディペンデントビュービデオストリームによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋OffsetモードタイプのIGストリームに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はインタラクティブグラフィクススプレーンに、このオフセットを適用しない。
『IG＿Plane＿offset＿direction＿during＿BB＿video』は、B−Bプレゼンテーションモードにおいてポップアップメニューのユーザインターフェイスで、IGストリームが再生されている間、1plane＋Offsetモードにおけるインタラクティブグラフィクス(IG)プレーンにおけるオフセット方向を指示する。
値"０"でフロント設定、つまり、プレーンメモリは、TVと視聴者との間に存在し、レフトビュー期間においてプレーンは右方向に、ライトビュー期間においてプレーンは左方向にシフトされる。
値＝１でビハインド設定、つまり、プレーンメモリは、TV又はスクリーンの背後に存在し、レフトプレーンは左方向に、ライトプレーンは右方向にシフトされる。
『IG＿Plane＿offset＿value＿during＿BB＿video』は、B−BプレゼンテーションモードでポップアップメニューのユーザインターフェイスによってIGストリームが再生されている間、1plane＋OffsetモードにおけるIGプレーンのオフセット値を画素単位で指示する。
『is＿SS＿IG』は、立体視インタラクティブグラフィクス存否フラグであり、IGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する。立体視IGストリームのデータ構造が存在しない場合、このフィールドは値0に設定されねばならない。再生が許可されているIGストリームが立体視IGストリームである場合、このフィールドは、値1に設定されねばならない。
『stream＿entry＿for＿base＿view』は、ベースビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるベースビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報におけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューIGストリームを格納しているストリームファイルを改めて読み出さねばならない。
『stream＿attribute』は、ベースビューIGストリーム及びディペンデントIGストリームの言語属性を含む。
『SS＿IG＿offset＿sequence＿id＿ref』は、立体視タイプのIGストリームのためのオフセットシーケンスIDのレファレンスであり、ディペンデントビュービデオストリームのオフセットメタデータにおけるオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットを立体視タイプのIGプレーンに適用せねばならない。
このフィールドが不定値(FF)である場合、再生装置はIGプレーンに、このオフセットを適用しない。
拡張ストリーム選択テーブルにおける制限について説明する。
立体視ディペンデントビューブロックにおけるストリームエントリーは、プレイリストにおいて変化してはならない。
立体視ディペンデントビューブロックにおけるストリームエントリーのタイプがサブパスによって使用されるESタイプ（ストリームタイプ＝２）であれば、サブパスIDレファレンスと、サブクリップエントリーIDレファレンス(ref_to_subclip_entry_id)とはプレイリストにおいて変化しない。
ストリームエントリー、ベースビューのためのストリームエントリー、ディペンデントビューのためのストリームエントリーのタイプとして許されるESのタイプは、プレイアイテムによって使用されるAVクリップ内のES (ストリームタイプ＝１)、サブパスによって使用されるAVクリップ内のES(ストリームタイプ＝２)の2つのタイプのみである。
立体視ディペンデントビューブロックにおけるストリーム属性のストリーム符号化方式は、"0x20"に設定される。
図１６は、基本ストリーム選択テーブル、拡張ストリーム選択テーブルによりメインTS、サブTSからどのようなESが多重分離されるかを示す。
本図の真ん中には、多重分離部を示し、その上側には基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとの組みを示す。左側にはメインTS、サブTS、右側には、多重分離されるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリーム、プライマリオーディオストリームを示す。
図１７は、図１６のような多重分離がなされる場合、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。本図の真ん中に基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを示す。
基本ストリーム選択テーブルの左側は、再生装置においてカレントストリームのストリーム番号を格納するストリーム番号レジスタを示す。基本ストリーム選択テーブルの右側は、再生装置における言語設定を示す。拡張ストリーム選択テーブルの下側は、多重分離部を示す。矢印ｈ１は、PGストリームの言語設定と、基本ストリーム選択テーブルにおけるPGストリームのストリーム登録情報Ｘにおける言語属性との一致を模式的に示す。矢印ｈ２は、PGストリームのストリーム番号レジスタへの、ストリーム番号Ｘの設定を模式的に示す。
矢印ｈ３は、IGストリームの言語設定と、基本ストリーム選択テーブルにおけるIGストリームのストリーム登録情報Ｙにおける言語属性との一致を模式的に示す。矢印ｈ４は、IGストリームのストリーム番号レジスタへの、ストリーム番号Ｙの設定を模式的に示す。
本図のストリーム番号の設定は、基本ストリーム選択テーブルに対するストリーム選択プロシージャの結果に応じて、多重分離に供されるPGストリーム、IGストリームが定まること象徴的に示している。
矢印PD1は、拡張ストリーム選択テーブル内のSS＿dependent＿view＿blockにおけるストリームエントリーに記述されているパケット識別子の出力を模式的に示す。この出力によって多重分離部における多重分離がなされて、ディペンデントビュービデオストリームが出力される。
矢印PD2は、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録情報のストリームエントリーのうち、ストリーム番号Ｘに対応するもののパケット識別子の出力を模式的に示す。矢印Ｘ１は、矢印PD1のパケット識別子出力が、ストリーム番号レジスタに対するカレントストリーム番号Ｘの設定と連動していることを示す。
矢印PD3は、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録情報のストリームエントリーのうち、ストリーム番号Ｙに対応するもののパケット識別子の出力を模式的に示す。矢印Ｙ１は、矢印PD3のパケット識別子出力が、ストリーム番号レジスタに対するカレントストリーム番号Ｙの設定と連動していることを示す。
ここでの連動とは、基本ストリーム選択テーブルにおけるPG,IGストリームのストリーム登録列に記述されたストリーム番号のうち、ストリーム番号Ｘ,Ｙが、カレントのPG,IGストリーム番号としてストリーム番号レジスタに設定されたことに、拡張ストリーム選択テーブルに記載されたパケット識別子の出力が連動していることを意味する。
この出力によって多重分離部における多重分離がなされて、PG,IGストリームが出力される。
図１８は、モードにおけるストリーム番号の割り当て変化を示す。
縦欄は、ビデオストリーム#1というストリーム番号、オーディオストリーム#1、#2というストリーム番号、PGストリーム#1、#2というストリーム番号、IGストリーム#1、#2というストリーム番号を示している。
左側の破線枠にのみ囲まれるESは、2D再生モードにおいてのみ、多重分離の対象になるESである。
右側の破線枠にのみ囲まれるESは、3D再生モードにおいて多重分離の対象になるESを示す。
左側及び右側の破線枠の双方に囲まれるESは、2D再生モード及び3D再生モードにおいて多重分離の対象になるESを示す。
ビデオストリーム#1のストリーム番号だけに着目すると、プライマリビデオストリームは、左右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。この2Dビデオストリームは、レフトビュービデオストリームである。しかし、ライトビュービデオストリームは、右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。
オーディオストリーム#1、オーディオストリーム#2のストリーム番号に着目すると、オーディオストリームは、左右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。
PGストリーム#1、PGストリーム#2のストリーム番号に着目すると、2DPGストリームは、左側の破線枠のみに囲まれるので、2D再生モードのみで再生対象になっていることがわかる。ベースビューPGストリーム、ディペンデントビューPGストリームは右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。IGストリームも同様である。
以上より、3D再生モードにおいてビデオストリームというストリーム種別では、ディペンデントビュービデオストリームが再生対象として加わることがわかる。
また3D再生モードにおいてPGストリームというストリーム種別では、再生対象が、2DPGストリームから、ベースビューPGストリーム及びディペンデントビューPGストリームに置き換わっていることがわかる。
前記拡張ストリーム選択テーブルは、オブジェクト指向型コンパイラ言語を用いて、図１９のような記述を行い、コンパイルに供することで作成することができる。図１９は、オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。
PlayItem＿idを制御変数とするfor文は、Fixed＿offset＿during＿Popup、ディペンデントビューストリームのストリーム登録列、PG＿テキスト字幕ストリームのストリーム登録列、IGストリームのストリーム登録列の記述を、プレイアイテムの個数だけ繰り返すループを構成する。
primary＿video＿stream＿idを制御変数とするfor文は、ディペンデントビューストリームのストリーム登録列を定義するものであり、ディペンデントビューストリームのストリーム登録列は、number＿of＿primary＿video＿stream＿entriesだけ、stream＿entry,stream＿attribute,number＿of＿offset＿sequenceからなるSS＿dependent＿view＿blockを記述することで定義される。
PG＿textST＿stream＿idを制御変数とするfor文は、PG＿テキスト字幕ストリームのストリーム登録列を定義するものであり、number＿of＿PG＿textST＿stream＿number＿entriesだけ、PG＿text＿offset＿sequence＿id＿ref、is＿SS＿PGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿PGを制御変数としたif文は、is＿SS＿PGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿PGが1bdである場合のみ、ストリーム登録列に追加される。is＿SS＿PGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。

IG＿stream＿idを制御変数とするfor文は、IGストリームのストリーム登録列を定義するものであり、number＿of＿IG＿stream＿entriesだけ、IG＿offset＿sequence＿id＿ref、IG＿plane＿offset＿direction＿during＿BB＿video、IG＿plane＿offset＿value＿during＿BB＿video、is＿SS＿IGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿IGを制御変数としたif文は、is＿SS＿IGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿IGが1bである場合のみ、ストリーム登録列に追加される。is＿SS＿IGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。
以上が記録媒体についての説明である。続いて、再生装置の詳細について説明する。
図２０は、再生装置の内部構成を示す。本図に示すように再生装置は、読出設定部２０１、メモリ２０２、プレーヤ番号レジスタ２０３、デコーダ２０４、多重分離部２０５、プレーンメモリセット２０６、シフト部２０７、レイヤ合成部２０８、送受信部２０９、再生制御部２１０、出力モードレジスタ２１１、コンフィグレーションメモリ２１２から構成される。本図の内部構成は、課題解決手段を具備した再生装置を実施するための必要最低限の構成要素を記述したに過ぎない。より詳細な内部構成については、後段の実施形態に説明の場を譲る。
読出部２０１は、記録媒体からインデックステーブル、動作モードオブジェクトのプログラムファイル、プレイリスト情報ファイル、ストリーム情報ファイル、ストリームファイルを読み出す。
メモリ２０２は、プレイリスト情報に含まれる基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを結合することで得られた結合ストリーム登録列を格納する。
ストリーム種別毎のプレーヤ番号レジスタ２０３は、ビデオストリームのストリーム番号を格納するビデオストリーム番号レジスタ、PGストリームのストリーム番号を格納するPGストリーム番号レジスタ、IGストリームのストリーム番号を格納するIGストリーム番号レジスタ、オーディオストリーム番号を格納するオーディオストリーム番号レジスタを含む。
ストリーム種別毎のデコーダ２０４は、ビデオデコーダ、PGデコーダ、IGデコーダ、オーディオデコーダから構成される。
多重分離部２０５は、パケットフィルタリングを実行するPIDフィルタを備え、記録媒体から読み出された複数のソースパケット内のTSパケットのうち、結合ストリーム登録列に記載されたパケット識別子によって指示されているものを分離して、各デコーダに出力する。
プレーンメモリセット２０６は、複数のプレーンメモリから構成される。プレーンメモリとは、ESをデコードすることで得られた一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオデコーダ、PGデコーダ、IGデコーダのデコードによって得られた1画面分の画素データを格納する。
これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。このレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
シフト部２０７は、画素の座標のシフトを実行する。
レイヤ合成部２０８は、複数のプレーンメモリにおけるレイヤ合成を行う。
送受信部２０９は、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、相互認証フェーズと、ネゴシエーションフェーズを経て、データ伝送フェーズに移行し、データ伝送を行う。
このネゴシエーションフェーズは、相手側機器のケーパビリティ(デコード能力、再生能力、表示周波数を含む)を把握して、プレーヤ設定レジスタに設定しておき、以降の伝送のための伝送方式を定めるものである。これらの相互認証フェーズ、ネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮・平文形式の画素データを、表示装置における水平同期期間に従い表示装置に高い転送レートで転送する。一方、表示装置における水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置(表示装置のみならずアンプ、スピーカを含む)に、非圧縮・平文形式のオーディオデータを転送する。こうすることで、表示装置、アンプ、スピーカといった機器は、非圧縮・平文形式のピクチャデータ、非圧縮・平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮・暗号化形式のまま伝送することができる。
再生制御部２１０は、読出部２０１を制御して、記録媒体からのインデックステーブル、動作モードオブジェクト、プレイリスト情報、クリップ情報、ストリームファイルを記録媒体から読み出すとともに、記録媒体から読み出されたプレイリスト情報、クリップ情報に基づく再生制御を実行する。ストリームファイルの読み出しにあたっては、時間軸の任意の時点に相当するソースパケットを、ストリームファイルから読み出すというランダムアクセスを実現することができる。
出力モードレジスタ２１１は、再生モードを記憶している。
コンフィグレーションメモリ２１２は、各プレーンメモリのモードケーパビリティと、カレントモードとを記憶する不揮発性メモリであり、再生装置の製造主体によって、その記憶内容が設定される。モードケーパビリティとは、ビデオプレーン、PGプレーン、IGプレーンといった複数のプレーンメモリのそれぞれが、上述したような再生モードのそれぞれを処理することができるか否かを示す。再生モードを処理できるかどうかは、プレーンメモリに対応するストリーム種別が何であるか、また、その再生モードを処理するためのハードウェア構成が再生装置に存在するか否かによって決まる。
カレントモードは、複数のプレーンメモリのそれぞれが、複数の再生モードのうち、どれに設定されているかを示す。
以上が再生装置についての説明である。続いて、本実施形態に係る再生装置による多重分離処理の詳細について説明する。
図２１は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
同図（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ストリーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。基本ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号"１"、"２"、"３"のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、英語、日本語、中国語の言語属性を有している。
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号"１"、"２"、"３"のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、英語、日本語、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa1、a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号レジスタへのストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、基本ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
同図（ｃ）は、言語設定が中国語であり、出力モードがB−Dプレゼンテーションモードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号レジスタに対するストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。

図２２は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ストリーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。基本ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号"１"、"２"、"３"のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、何れも中国語の言語属性を有している。
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号"１"、"２"、"３"のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性も、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa1,a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝１のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝"１"がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、基本ストリーム選択テーブルにおけるストリーム番号"１"のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
（ｃ）は、言語設定が中国語であり、出力モードがB−Dプレゼンテーションモードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号"１"のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号"１"のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号"１"のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。

図２３は、再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のディペンデントビューストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、ディペンデントビュービデオストリームを構成するTSパケット、ベースビューPGストリームを構成するTSパケット、ディペンデントビューPGストリームを構成するTSパケット、ベースビューIGストリームを構成するTSパケット、ディペンデントビューIGストリームを構成するTSパケットがデコーダに出力されることがわかる。
図２４は、再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、シフト部との間の矢印は、拡張ストリーム選択テーブルにおけるPGストリームに対応するストリーム登録列におけるオフセットレファレンス、及び、拡張ストリーム選択テーブルにおけるIGストリームに対応するストリーム登録列におけるオフセットレファレンスが1plane＋Offsetモードにおいて参照されていることを示す。
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
ビデオデコーダと、シフト部との矢印は、上述したようなオフセットレファレンスに基づき、ディペンデントビュービデオストリームにおけるオフセットがPGストリームについてのシフト部、IGストリームについてのシフト部に供給されていることを示す。
図２５は、再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
図２６は、再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、基本ストリーム選択テーブルのストリーム登録列におけるストリームエントリーによって指示されているTSパケットが各デコーダに出力されているかを示す。
以上の再生制御は、図２７から図２９までのフローチャートに示される処理手順をオブジェクト指向型コンパイラ言語で記述してコンピュータに実行させることで実現することができる。
図２７は、プレイリスト再生手順を示す。本フローチャートは、ステップＳ１においてカレントプレイアイテム番号を１に設定した後、ステップＳ２〜ステップＳ６の処理を繰り返すループを構成する。このループでは、ストリーム選択プロシージャによりストリーム番号を決定して(ステップＳ２)、ストリーム番号に対応するESを格納したストリームファイルをオープンしてソースパケット列を読み出し(ステップＳ３)、読み出されたソースパケット列のうち、ストリーム番号に対応しているものの多重分離を指示し(ステップＳ４)、読み出されたソースパケットをプレイアイテムのインタイムからアウトタイムまで、サブプレイアイテムのインタイムからアウトタイムまで再生するようデコーダに命じる(ステップＳ５)という処理を、カレントプレイアイテム番号が最終番号になるまで繰り返すものである。ここで最終番号でなければ(ステップＳ６でNo)、カレントプレイアイテム番号がインクリメントされて、ステップＳ２に移行する。最終番号であれば、処理を終了する(ステップＳ６でYes)。
図２８は、ストリーム選択プロシージャの処理手順を示す。
本フローチャートでは、カレントプレイアイテム情報内の基本ストリーム選択テーブルをカレント基本ストリーム選択テーブルに設定する(ステップＳ７)。そして、ステップＳ８〜ステップＳ１７のループを実行する。ステップＳ８〜ステップＳ１７は、PGストリーム、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップＳ１０〜ステップＳ１７の処理を繰り返すものである。ステップＳ１０は、カレント基本ストリーム選択テーブルにおける、ストリームｘに対応する基本ストリーム選択テーブルエントリー数が0であるか否かの判定であり、ステップＳ１１は、カレントストリームにおけるストリームｘに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。
ステップＳ１０、ステップＳ１１の何れかがYesであれば、ステップＳ１７においてストリーム番号レジスタに格納されているストリーム番号を維持する。
ステップＳ１０、ステップＳ１１の何れもがNoであれば、カレント基本ストリーム選択テーブルに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して(ステップＳ１２)、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する(ステップＳ１３)。
条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する(ステップＳ１４)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレント基本ストリーム選択テーブルにおける優先順位が最も高いものを選択する(ステップＳ１５)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む(ステップＳ１６)。
以上の過程を経て、カレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedure when playback condition is changedによって確定した出力モードに応じたものとなる。
図２９は、ストリーム番号に対応するパケット識別子の出力処理の手順を示す。ステップＳ１７、ステップＳ１８の判定ステップを実行する構造になっている。ステップＳ１７は、カレントの出力モードが2D再生モードであるか否かの判定であり、もし2D再生モードであれば、ステップＳ３８において、基本ストリーム選択テーブルにおけるストリーム登録列のうち、カレントストリーム番号に対応するストリーム登録情報のストリームエントリーに基づく多重分離を多重分離部に指示する。
ステップＳ１８は、拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであるか否かの判定である。ステップＳ１７がNo、ステップＳ１８がNoであれば、ステップＳ１９〜ステップＳ３０を実行する。
ステップＳ１７〜ステップＳ３０は、ビデオストリームを立体視B−Dタイプに設定してビデオプレーンをB−Dプレゼンテーションモードに設定し(ステップＳ１９)、SS＿dependent＿View＿blockにおけるストリームエントリーのパケット識別子に基づく多重分離を指示して(ステップＳ２０)、ステップＳ２１〜ステップＳ２６の処理を実行する。
ステップＳ２１は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ２２において、PGストリームを立体視再生タイプに設定して、PGプレーンをB−Dプレゼンテーションモードにし(ステップＳ２３)、カレントPGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示する。
is＿ss＿PGがオフであれば、PGストリームを1plane＋Offset再生タイプに設定して、PGプレーンを、1plane＋Offsetモードに設定し(ステップＳ２４)、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ２５)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ２６)。
ステップＳ２７は、カレントIGストリームのストリーム登録情報におけるis＿ss＿IGがオンであるか否かの判定であり、オンであれば、ステップＳ２８において、カレントIGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示する。
is＿ss＿IGがオフであれば、カレントIGストリームのストリーム登録情報におけるSS＿IG＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ２９)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３０)。
拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであれば、ステップＳ１７がNo、ステップＳ１８がYesになって、ステップＳ３１〜ステップＳ３７を実行する。
ステップＳ３１〜ステップＳ３７は、ビデオストリームを立体視B−Bタイプに設定して、ビデオプレーンをB−Bプレゼンテーションモードに設定し(ステップＳ３１)、ステップＳ３２〜ステップＳ３７の処理を実行する。
ステップＳ３２は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ３３において、PGストリームを1plane＋Offsetモードタイプに設定して、PGプレーンを1plane＋Offsetモードに設定し、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ３４)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３５)。その後、ステップＳ３７に移行する。
is＿ss＿PGがオフであれば、ステップＳ３６においてPGストリームを1plane＋Zero Offsetモードタイプに設定して、PGプレーンを1plane＋Zero Offsetモードに設定する。その後、ステップＳ３７に移行する
ステップＳ３７では、カレントIGストリームのストリーム登録列におけるIG＿Plane＿offset＿direction＿during＿BB＿videoによって示される方向に対して、ストリーム登録列におけるIG＿Plane＿offset＿value＿during＿BB＿videoによって示される量だけ、プレーンシフトを実行する。以上の処理により、Fixed＿offset＿during＿Popupがオンの設定時には、平面的な動画像に、立体的な字幕やメニューが合成された立体視映像を再生に供することができる。
以上のように本実施形態によれば、2D再生モードから3D再生モードに変化した場合、拡張ストリーム選択テーブル内に存在するストリーム登録列であって、ストリーム番号レジスタに格納されているストリーム番号によって指示されるもののストリームエントリーによって多重分離の対象となるべきストリームを選ぶことができる。
3D再生モードに変化した場合、ストリーム番号レジスタにおけるストリーム番号をそのままにして、多重分離の対象となるストリームを切り替えることができるので、モードが切り替ったとしても、プロシージャを実行にする必要がなくなる。モード切り替えに伴うストリーム選択プロシージャの実行を回避することができるので、切り替えの前後で同じ言語属性のESを再生対象にすることができる。
(第２実施形態)
第１実施形態では、ディペンデントビューデータブロックを構成するサブTSをサブクリップエントリーIDレファレンスから参照していたため、サブTSがメインTSと分離して記録されている場合、2D再生モードから3D再生モードへの切替え時において、サブTSの読み出しが発生し、AV再生のシームレス性が損なわれる恐れがある。そこで本実施形態は、メインTSと、サブTSとが共に再生装置に読み込まれることを保障する改良を提案する。具体的には、メインTS、サブTSをインターリーブ化して、2TSを1ファイルとして記録することを提案する。
前提事項として、UDFファイルシステムにおけるファイルについて簡単に説明する。UDFにおけるファイルは、ファイルエントリーによって管理されている複数のエクステントから構成される。「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す"261"が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。

「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号（LBN）を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位２ビットは、"00"に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、"01"に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。"11"に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
上述したようなファイルエントリーのアロケーション識別子を参照することで、ストリームファイルを構成するエクステントのアドレスを知得することができる。
次に、本実施形態で想定されているファイルの種別について説明する。

＜立体視インターリーブドストリームファイル(FileSS)＞
立体視インターリーブドストリームファイル(FileSS)は、2TSをインターリーブ形式にしたストリームファイル(2TSインターリーブファイル)であり、５桁の整数値と、立体視再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。立体視インターリーブドストリームファイルは、エクステントSS[n]から構成され、エクステントSS[n](EXTSS[n])は、インデックス番号nによって特定される。インデックス番号nは、立体視インターリーブドストリームファイルの先頭から1つずつインクリメントされる番号である。
エクステントSS[n]は、ディペンデントビューデータブロックと、ベースビューデータブロックとの組みとして構成される。
エクステントSS[n]を構成するベースビューデータブロック、ディペンデントビューデータブロックは、ファイル2D、ファイルベース、ファイルディペンデントからのクロスレファレンスの対象となる。クロスレファレンスとは、記録媒体に記録された1つのデータ客体を、複数のファイルのエクステントとして、ファイルエントリーに登録しておくことをいう。本実施形態では、ファイル2Dのファイルエントリー、ファイルベースのファイルエントリー、ファイルディペンデントのファイルエントリーに、ベースビューデータブロックの先頭アドレス及び連続長と、ディペンデントビューデータブロックの先頭アドレス及び連続長とが登録されることになる。

＜ファイルベース(FileBase)＞
ファイルベース(FileBase)は、ファイル2Dに対応するクリップ情報におけるエクステントスタートポイント情報によって指示されるメインTSを"格納している"とされる仮想的なストリームファイルであり、少なくとも1つのエクステント1[i](EXT1[i]と呼ぶ)によって構成される。エクステント1[i]は、ファイルベースにおけるi番目のエクステントであり、iは、エクステントのインデックス番号であり、ファイルベースの先頭を0としてインクリメントされる。ファイルベースは、2TSファイルである立体視インターリーブドストリームファイルを、1TSファイルとして扱うための仮想的なストリームファイルであり、そのファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
実際の読み出しにあたって、ファイルベースは、この立体視インターリーブドストリームファイルのファイル名を用いてファイルオープンを行うことで特定される。具体的にいうと再生装置のミドルウェアは、立体視インターリーブドストリームファイルのファイル名を用いたファイルオープンがコールされた場合、ファイルベースのエクステントを特定するファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする。立体視インターリーブドストリームファイルは、"1TSのみを包含している"とみなすことができ、2TSの立体視インターリーブドストリームファイルを1TSのファイルベースとして記録媒体から読み出すことができる。
B−Bプレゼンテーションモードにおいて、ベースビューデータブロックのみを読み出したい場合は、このファイルベースを構成するエクステントのみが読み出しの対象になる。B−BプレゼンテーションモードからB−Dプレゼンテーションモードへのモード変更があったとしても、読出範囲を、ファイルベースを構成するエクステントの記録範囲から、立体視インターリーブドストリームファイルを構成するエクステントの記録領域に拡大すれば、ベースビューデータブロック、ディペンデントビューデータブロックの双方を読み出すことができるから、ファイル読み出しの効率性を低下させることはない。
＜ファイルディペンデント(FileDependent)＞
ファイルディペンデント(FileDependent)は、サブTSを"格納している"とされるストリームファイルであり、エクステント2[i](EXT2[i])によって構成される。EXT2[i]は、ファイルディペンデントにおけるi番目のエクステントであり、iは、エクステントのインデックス番号であり、ファイルディペンデントの先頭を0としてインクリメントされる。ファイルディペンデントは、2TSファイルである立体視インターリーブドストリームファイルを、サブTSを格納した1TSファイルとして扱うための仮想的なストリームファイルであり、そのファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
ディペンデントビュービデオストリームは、立体視インターリーブドストリームファイルのファイル名である5桁番号に、1を加算した番号がファイル名として付与される。このファイル名を用いてアクセスされる。記録媒体には、ダミーファイルが記録されていて、ディペンデントビュービデオストリームの識別番号である、「１を加算した番号」がこのダミーファイルに付与される。ダミーファイルとは、ファイル名のみが存在していて、実体であるエクステントが存在しないファイルであり、ディペンデントビュービデオストリームは、このダミーファイルに格納されるとして扱われる。

＜ファイル2D(File2D)＞
ファイル2Dは、2D再生モードにおいて再生されるメインTSを格納している1TSのストリームファイルであり、エクステント2Dから構成される。ファイル2Dは、５桁の整数値と、立体視再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。
以下、ファイル２Ｄ／ファイルベース、ファイルディペンデントの相互関係について説明する。図３０は、エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。
第１段目は、ファイル2D／ファイルベース、ファイルディペンデントである00001.m2ts,00002.m2tsを示し、第２段目は、ベースビューデータブロックを格納したエクステント、ディペンデントビューデータブロックを格納したエクステントを示す。第３段目は、立体視インターリーブドストリームファイルである00001.ssifを示す。
破線の矢印h1,h2,h3,h4は、エクステントEXT1[i],EXT2[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT1[i],EXT1[i+1]は、ファイルベースである00001.m2tsのエクステントとして登録されていることがわかる。
矢印h3,h4に示される帰属関係によると、エクステントEXT2[i],EXT2[i+1]は、ファイルディペンデントである00002.m2tsのエクステントとして登録されていることがわかる。
矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT1[i],EXT2[i],EXT1[i+1],EXT2[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT1[i],EXT1[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この"ssif"という拡張子は、StereoScopic Interleave Fileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。
図３１は、インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。
同図（ａ）の第３段目は、インターリーブドストリームファイルの内部構成を示す。ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のそれぞれと、ディペンデントビューデータブロックを格納したエクステントEXT2[1],EXT2[2]のそれぞれとが交互配置されることで構成される。
第１段目は、ファイル2D及びファイルベースの内部構成を示す。ファイル2D／ファイルベースは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のみから構成されている。ファイル2Dのファイル名は、インターリーブドストリームファイルのファイル名が同一だが、拡張子が異なる。
第２段目は、ファイディペンデントの内部構成を示す。ファイディペンデントは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ディペンデントビューデータブロックを格納するエクステントEXT2[1],EXT2[2],EXT2[2]のみから構成されている。ファイルディペンデントのファイル名は、インターリーブドストリームファイルのファイル名に1を加算したものになっており、また拡張子が異なる。
3D映像を含む光ディスクであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2Dストリームにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。
１つ目の方法は、上述したようなプレイリスト情報の参照、つまり、メインTSは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のストリームファイルは拡張子を変える方法である。同図（ｂ）における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名"00001"によってカップリングされている。
プレイリストは、メインTSのAVクリップしか参照しないため、既存の2D再生装置ではファイル２Ｄしか再生しない。3D対応の再生装置は、プレイリストはメインTSの入ったファイル２Ｄしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のストリームファイルであると判断して、メインTSと、サブTSとを出力する。
２つ目の方法は、フォルダを分ける方法である。メインTSは既存のフォルダ名（例：STREAM）を持つフォルダ内に格納しておくが、サブTSは、3D特有の名前を持つフォルダ（例：SSIF）に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照する際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、メインTSと、サブTSとを関連づけることが可能となる。
３つ目の方法は、識別番号によるものである。ファイル２Ｄ／ファイルベースの識別番号が"００００１"である場合、ファイルディペンデントの識別番号は、同図（ｃ）に示すようにこのファイル２Ｄ／ファイルベースの識別番号に"１"を加算した番号、つまり、"０００２"という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。しかし記録媒体のファイルシステムにおいて、上述のルールで命名されたファイルディペンデントは、あくまでも実体のないダミーファイルとして扱われる。これは、ファイルディペンデントの実体は、立体視インターリーブドストリームファイルに過ぎないとの理由による。 こうして関連付けられたファイル名を、基本ストリーム選択テーブルにおけるストリーム登録情報、及び、拡張ストリーム選択テーブルにおけるストリーム登録情報におけるストリームエントリーのサブクリップエントリーIDレファレンス(ref_to_subclip_entry_id)に記述しておく。一方、再生装置については、サブクリップエントリーIDレファレンスに記述された識別番号に"1"を加算した識別番号のファイル名は、ダミーファイルのファイル名であると認証して、ファイルディペンデントを仮想的にオープンする処理を実行する。こうすれば、ストリーム選択プロシージャにおいて、上述したような関連付けがなされたファイルディペンデントが確実に記録媒体から読み出されることになる。
以上が、ファイル２Ｄ、ファイルベース、ファイルディペンデントについての説明である。
以下、データブロックの詳細について説明する。
＜ベースビューデータブロック＞
ベースビューデータブロック(B[i])は、メインTSのi番目のデータブロックである。ここで、メインTSとは、カレントプレイアイテム情報のクリップ情報ファイル名情報(クリップ情報ファイルネーム情報)を通じて、メインパスの基軸として指定されているTSである。B[i]の"i"は、ファイルベースの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
ベースビューデータブロックには、ファイルベースと、ファイル2Dとで共通化されるものと、ファイルベースと、ファイル2Dとで共通化されていないものとがある。
ファイル2D及びファイルベースで共通化されるベースビューデータブロック、及び、ファイル2D固有のベースビューデータブロックは、ファイル2Dのエクステントになるものであり、再生装置におけるバッファアンダーフローを生じさせない長さに設定されている。そしてその先頭のセクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されている。
ファイル2Dと共通化されていないファイルベース固有のベースビューデータブロックは、ファイル2Dのエクステントにはならないから、再生装置におけるシングルバッファをアンダーフローを生じさせない長さに設定されている訳ではない。より小さいサイズ、つまり、再生装置におけるダブルバッファをアンダーフローさせない長さに設定されている。
またファイルベース固有のベースビューデータブロックは、その先頭セクタアドレスがファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ベースビューデータブロックにおける先頭ソースパケットのソースパケットが、メインTSに対応するクリップ情報ファイルのクリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ファイルベース固有のベースビューデータブロックの先頭セクタアドレスは、立体視インターリーブドストリームファイルのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
レフトビューがベースビューである場合、ベースビューデータブロックは、レフトビュービデオストリームの分割部分を格納したソースパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)等、2D再生及びレフトビュー再生のための複数種別のPESストリームの分割部分を格納したソースパケットの集合体である。このベースビューデータブロックを構成するパケットは、ATC,STC,SPNが連続しており、ある一定期間のシームレスなAV再生を保障する。

＜ディペンデントビューデータブロック＞
ディペンデントビューデータブロック(D[i])は、サブTSのi番目のデータブロックである。サブTSとは、カレントプレイアイテム情報に対応する拡張ストリーム選択テーブルのストリーム登録列におけるストリームエントリーにおいて、サブパスの基軸として指定されているTSである。D[i]の"i"は、ファイルディペンデントの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
ディペンデントビューデータブロックは、ファイルディペンデントのエクステントになるものであり、再生装置におけるダブルバッファのアンダーフローを生じさせない長さに設定されている。
また、記録媒体の連続領域上で、ディペンデントビューデータブロックは、同じ再生時間で再生されるべきベースビューデータブロックより手前に配置される。そのため、立体視インターリーブドストリームファイルの読み出し時にあたって、ディペンデントビューデータブロックは、必ずベースビューデータブロックより先に読み出されることになる。
ディペンデントビューデータブロックは、ファイル2Dと共通化されていないので、その先頭セクタアドレスが、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ディペンデントビューデータブロックにおける先頭ソースパケットのソースパケットが、クリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ディペンデントビューデータブロックの先頭セクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
ディペンデントビューがライトビューである場合、ディペンデントビューデータブロックは、ライトビュービデオストリームの分割部分を格納したソースパケット、ライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したソースパケットの集合体である。これらのパケットはATC,STC,SPNが連続しており、ある一定期間の連続再生を保障する。連続するベースビューデータブロックとディペンデントビューデータブロックとでは、ベースビューデータブロックを構成するソースパケット、及び、ディペンデントビューデータブロックを構成するソースパケットは、ソースパケット番号が連続しているものの、ベースビューデータブロックを構成する複数のソースパケットのATS、及び、ディペンデントビューデータブロックを構成する複数のソースパケットのATSは、何れも同じ値になっている。従って、ベースビューデータブロックを構成する複数のソースパケット、及び、ディペンデントビューデータブロックを構成する複数のソースパケットは、同じATC時刻に、PIDフィルタに到達することになる。

＜エクステントの類型＞
上述したように、ファイル2Dのエクステントには、ファイルベースのエクステントと共通のものと、ファイルベースと共通ではないものとがある。
ファイル2Dのエクステントが、B[0]、B[1]、B[2]、B[3]2D、B[4]2Dから構成され、ファイルベースのエクステントがB[0]、B[1]、B[2]、B[3]ss、B[4]ssから構成されるものとする。B[0]、B[1]、B[2]は、ファイルベースと共通化されているベースビューデータブロックである。B[3]2D、B[4]2Dは、ファイルベースと共通化されていない、ファイル2D固有のベースビューデータブロックである。
またB[3]ss、B[4]ssは、ファイル2Dと共通化されていない、ファイルベース固有のベースビューデータブロックである。
B[3]2Dにおけるデータと、B[3]ssのデータとは、bit-for-bitの同一性を有する。B[4]2Dにおけるデータと、B[4]ssのデータとは、bit-for-bitの同一性を有する。
これらのファイル2DにおけるデータブロックB[2]、B[3]2D、B[4]2Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステント（ビッグエクステント）を構成する。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、立体視インターリーブドストリームファイルを2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。
ファイル2D及びファイルベースは、エクステントが一部異なっているものの、同一性を有しているので、これらファイル2D及びファイルベースを併せて、"ファイル2D／ファイルベース"という。

＜ロングジャンプ＞
一般論だが、記録媒体に光ディスクを採用する場合、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。
ジャンプには、光ディスクの回転速度を上下させる操作の他に、トラックジャンプ及びフォーカスジャンプがある。トラックジャンプは、光ピックアップをディスクの半径方向に移動させる操作をいう。フォーカスジャンプは、光ディスクが多層ディスクであるとき、光ピックアップの焦点を一つの記録層から別の記録層へ移動させる操作をいう。これらのジャンプは一般にシーク時間が長く、かつ、ジャンプによって読み出しがスキップされるセクタ数が大きいので、特に「ロングジャンプ」という。ジャンプ期間中、光ピックアップによる読み出し操作は停止する。
ジャンプ期間中、読み出し操作がスキップされる部分の長さを「ジャンプ距離」という。ジャンプ距離は通常、その部分のセクタ数で表される。上記のロングジャンプは具体的には、ジャンプ距離が所定の閾値を超えるジャンプとして定義される。その閾値は、例えばBD-ROMの規格では、ディスクの種類及びドライブの読み出し処理に関する性能により、４００００セクタに規定されている。
ロングジャンプを生じさせる場所の代表的なものとしては、記録層の境界の他、プレイアイテム間の１対ｎの多重接続が存在する場所がある。
ここで、1対nのプレイアイテムの多重接続を行う場合、ｎ個のプレイアイテムを構成するn個のTSのうち1つ目のものは、その直前のプレイアイテムを構成するTSの直後に配置することができる。しかし2つ目以降のものは、その直前のプレイアイテムを構成するTSの直後に配置することができない。１対nの多重接続が存在する場合において、直前のプレイアイテムから、ｎ個のプレイアイテムの２個目以降のプレイアイテムへとジャンプする場合、そのジャンプは、1つ以上のTSの記録領域を読み飛ばす必要があるので、１対ｎのプレイアイテムの多重接続が存在する場所では、ロングジャンプが生じることになる。

＜各モードの再生経路＞
2D再生モードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイル2Dのエクステントから構成される。
B−Dプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照される立体視インターリーブドストリームファイルのエクステントから構成される。
B−Bプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイルベースのエクステントから構成される。
これらの3つのモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報に記述されているファイル名を、ファイル2Dのファイル名として用いてファイルオープンを行うか、ファイルベースのファイル名として用いてファイルオープンを行うか、立体視インターリーブドストリームファイルのファイル名として用いてファイルオープンを行うかで切り替えられる。このような再生経路の切り替えは、カレントプレイリストやカレントプレイアイテムの変動を招かないので、再生モードの変更時のシームレス性を維持することができる。
よって再生装置は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報に基づき立体視インターリーブドストリームファイル、ファイルベース、ファイル2Dの何れかをオープンすることにより、それぞれの再生モードに適合したデータブロックを記録媒体から読み出すことができる。
＜EXT2D、EXT1[n]、EXT2[n]、の具体的な値＞
EXT2Dの下限値は、2D再生モードの再生時、各ベースビューデータブロックから次のベースビューデータブロックまでのジャンプ期間中において、再生装置におけるリードバッファのバッファアンダーフローを生じないように決定される。
ｎ番目のベースビューデータブロックから(n+1)番目のベースビューデータブロックまでのジャンプが時間Tjump2D(n)を要し、各ベースビューデータブロックが,リードバッファに速度Rud2Dで読み出され、かつ、リードバッファからビデオデコーダへ前記ベースビューデータブロックが平均速度Rbext2Dで転送されるとき、EXT2Dの下限値は以下の式で表される。
EXT2Dの下限値 ≧（Rud2D×Rbext2D）/(Rud2D−Rbext2D)×Tjump2D（n）

ベースビューデータブロックB[n]ssに対応するエクステントをEXT1[n]であるものとする。この場合、EXT1[n]の下限値は、B−Dプレゼンテーションモードの再生時、各ベースビューデータブロックから次のディペンデントビューデータブロックまでのジャンプ期間と、当該ディペンデントビューデータブロックから次のベースビューデータブロックまでのジャンプ期間とを通して、ダブルバッファのアンダーフローを生じさせないように決定される。
ここでのダブルバッファは、リードバッファ１、リードバッファ２から構成されるものとする。リードバッファ１は、2D再生装置のリードバッファと同一物である。
B−Dプレゼンテーションモードの再生において、n番目のベースビューデータブロックからp番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n)を要し、ｐ番目のディペンデントビューデータブロックから（n+1）番目のベースビューデータブロックまでのジャンプが時間TBjump3D(n)を要するものとする。
そして各ベースビューデータブロックがリードバッファ１へ速度Rud3Dで読み出され、各ディペンデントビューデータブロックがリードバッファ２へ速度Rud3Dで読み出され、かつ、リードバッファ１からビデオデコーダへ前記ベースビューデータブロックが平均速度Rbext3Dで転送されるとき、EXT1[n]の下限値は、以下で表される。ビックエクステントの連続長は、この下限値、又は、この下限値を上回る値に設定される。
EXT1[n]の下限値 ≧（Rud3D×Rbext3D）/(Rud3D−Rbext3D) ×(TFjump3D（n）＋EXT2[n]/(Rud3D＋TBjump3D(n)))

EXT2の下限値は、B−Dプレゼンテーションモードの再生時、各ディペンデントビューエクステントから次のベースビューエクステントまでのジャンプ期間と、当該ベースビューエクステントから次のディペンデントビューエクステントまでのジャンプ期間とを通して再生装置におけるダブルバッファにアンダーフローを生じさせないように決定されている。
（n+1）番目のベースビューデータブロックから（p+1）番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n+1)を要し、かつ、リードバッファ２からデコーダへ前記ディペンデントビューストリームファイルが平均速度Rdext3Dで転送されるとき、EXT2[n]の下限値は以下の式で表される。

EXT2[n]の下限値 ≧（Rud3D×Rbext3D）/(Rud3D−Rdext3D) ×(TBjump3D（n）＋EXT1[n+1]/(Rud3D＋TFjump3D(n+1)))


EXTSSは、ベースビュービデオストリームのエクステントと、ディペンデントビュービデオストリームのエクステントから構成されるから、その下限値は、以下の式のように表される。
EXTSSの下限値 ≧ EXT1[n] ＋ EXT2[n]

図３２は、立体視インターリーブドストリームファイル、ファイル2D、ファイルディペンデントの相互関係を示す。第１段目はファイル2Dを示し、第２段目は記録媒体上のデータブロック、第３段目は立体視インターリーブドストリームファイル、第４段目はファイルベース、第５段目はファイルディペンデントを示す。
第２段目におけるデータブロックは、上述したD[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ss,B[3]2D,B[4]2Dである。そして矢印ex1,ex2,ex3,ex4は、データブロックのうち、B[1],B[2],B[3]2D,B[4]2Dがファイル2Dのエクステントを構成しているという帰属関係を示す。
矢印ex5,ex6は、データブロックのうち、D[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ssが立体視インターリーブドストリームファイルのエクステントを構成しているという帰属関係を示す。
第４段目は、この立体視インターリーブドストリームファイルを構成するデータブロックのうち、B[1],B[2],B[3]ss,B[4]ssがファイルベースのエクステントとなり、第５段目は、立体視インターリーブドストリームファイルを構成するデータブロックのうち、D[1],D[2],D[3],D[4]がファイルディペンデントのエクステントになることを示す。
図３３は、2Dプレイリスト、3Dプレイリストを示す。第１段目は、2Dプレイリスト情報であり、第２段目は、ベースビューデータブロック、第３段目は、3Dプレイリスト、第４段目は、ディペンデントビューデータブロックを示す。
矢印rf1,rf2,rf3は、2Dプレイリスト情報のプレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名00001と、拡張子m2tsとを組合せることによる再生経路を示す。この場合、データブロックB[1],B[2],B[3]2Dによってベースビュー側の再生経路が構成される。
矢印rf4,rf5,rf6,rf7は、3Dプレイリスト情報のプレイアイテム情報により指定される再生経路を示す。この場合、B[1],B[2],B[3]ss,B[4]ssを用いてベースビュー側の再生経路が構成される。
矢印rf8,rf9,rf10,rf11は、3Dプレイリスト情報のサブプレイアイテム情報により指定される再生経路を示す。この場合、D[1],D[2],D[3],D[4]を用いてディペンデントビュー側の再生経路が構成される。これらのプレイアイテム情報、サブプレイアイテム情報により指定される再生経路を構成するデータブロックは、プレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名と、拡張子ssifとを組合せてファイルオープンを行うことで読み出すことができる。
本図の3Dプレイリストにおけるクリップ情報ファイルネーム情報、2Dプレイリスにおけるクリップ情報ファイルネーム情報は、共通のファイル名を記述しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。
立体視インターリーブドストリームファイルにメインTS、サブTSを格納する場合、２Ｄプレイリストのプレイアイテム情報におけるclip_information_file_nameは、ファイル２Ｄのファイル名を記述する。３Ｄプレイリストのプレイアイテム情報におけるclip_information_file_nameは、ファイルベースのファイル名を記述する。ファイルベースは、仮想的なファイルであり、そのファイル名は、立体視インターリーブドストリームファイルと同じものなので、立体視インターリーブドストリームファイルのファイル名をプレイアイテム情報におけるclip_information_file_nameに記述しておけばよい。拡張ストリーム選択テーブルのストリーム登録情報におけるref_to_subclip_entry_idは、ファイルディペンデントのファイル名を記述する。ファイルディペンデントのファイル名は、立体視インターリーブドストリームファイルの識別番号に、１を加算したものである。
図３４は、図３３の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図３３のプレイリストは、サブパスID＝"１"のサブパスのみを具備していたのに対して、図３４のプレイリストにおける2つ目のサブパスは、サブパスID＝"２"によって識別されるものであり、別のデータブロックを参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、ライトビューを構成するデータブロックがその角度の数だけ用意されていて、角度ごとにサブパスを設けている。
ベースビューデータブロックから構成されるメインTSによって規定されるメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。
この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図３４の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。
以降、ベースビュービデオストリームの指定の仕方について説明する。
一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すベースビューインディケータをプレイアイテム情報毎に設定できるようにしている。レフトビュービデオストリーム及びライトビュービデオストリームのうちどちらをベースビュービデオストリームとするか、レフトビューPGストリーム及びライトビューPGストリームのうちどちらをベースビューPGストリームとするか、レフトビューIGストリーム及びライトビューIGストリームのうちどちらをベースビューIGストリームとするかは、このプレイアイテム情報毎のベースビューインディケータによって指示される。
上述したように、ディペンデントビューデータブロックは、必ずベースビューデータブロックに先行して配置されるとの規則性をもつので、このベースビューインディケータを参照すれば、ライトビューを再生するためのソースパケット、レフトビューを再生するためのソースパケットのどちらが、先に再生装置に供給されるかを知得することができる。
この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。
図３５（ａ）は、図３３の3Dプレイリストに、ベースビューインディケータを書き加えた図である。
図３５（ｂ）は、オブジェクト指向プログラミング言語によるベースビューインディケータの記述を示す。本図は、PlayItemを定義する構造体において、ベースビューインディケータをどのように記述するかという記述例である。本図に示すように、"0"の即値を指定することで、レフトビュービデオストリームをベースビュービデオストリームとして指定することができ、"1"の即値を指定することで、ライトビュービデオストリームをベースビュービデオストリームとして指定することができる。
表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。
また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。以上がベースビューインディケータについての説明である。このベースビューインディケータは、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。
図３６は、ストリームファイルからのソースパケットの読出手順を示す。
ステップＳ４１は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップＳ４３〜ステップＳ４６を実行する。
ステップＳ４３において、カレントプレイアイテムの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]に属するエクステントを連続的に読み出すよう、記録媒体のドライブに指示する。
カレント出力モードが立体視出力モードであれば、ステップＳ５０〜ステップＳ６０のループに移行する。
ステップＳ５０において、カレントプレイアイテムの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]に属するエクステントを連続的に読み出すよう、ドライブに指示する。その後、ソースパケット列が読み出されれば、ステップＳ５９においてベースビューのATCシーケンス、ディペンデントビューのATCシーケンスをそれぞれ復元して、ベースビュー用のPIDフィルタ、ディペンデントビュー用のPIDフィルタに送り込む。
以上のように本実施形態によれば、ベースビューデータブロックと、ディペンデントビューデータブロックとを1つの立体視インターリーブドストリームファイルに格納しつつも、これらをデコーダに供給する際、ベースビュー用のATCシーケンスと、ディペンデントビュー用のATCシーケンスとを復元するので、デコーダ側では、立体視インターリーブドストリームファイルを通常のストリームファイルと同様に取り扱うことができる。よって、ベースビュービデオストリーム、ディペンデントビュービデオストリームの格納方式に、積極的に立体視インターリーブドストリームファイルを取り入れることができる。
(第３実施形態)
本実施形態では、マルチアングル再生に対応するためのデータ構造について説明する。
＜立体視インターリーブドストリームファイル＞
マルチアングルを構成する立体視インターリーブドファイルが記録された記録領域のデータアロケーションについて説明する。
マルチアングルを構成するインターリーブドファイルの記録領域には、複数のインターリーブユニットが記録されている。各インターリーブユニットは、ベースビューデータブロック及びディペンデントビューデータブロックの組みのそれぞれに対応している。
マルチアングル区間において、アングル番号"＝１"の設定時に再生されるべきベースビューデータブロック及びディペンデントビューデータブロックの組み、アングル番号＝２の設定時に再生されるべきベースビューデータブロック及びディペンデントビューデータブロックの組み、アングル番号＝３の設定時に再生されるべきベースビューデータブロック及びディペンデントビューデータブロックの組み、アングル番号＝４の設定時に再生されるべきベースビューデータブロック及びディペンデントビューデータブロックの組みが存在する場合、立体視インターリーブドストリームファイルは、アングル番号＝１に対応するインターリーブユニット、アングル番号＝２に対応するインターリーブユニット、アングル番号に＝３に対応するインターリーブユニット、アングル番号＝４に対応するインターリーブユニットから構成されることになる。
各インターリーブユニットは、インターリーブドストリームファイルにおけるエクステントSS(EXTSS)のエクステントであり、アングル番号xがアングル番号レジスタに設定されている際、読み出されるべきベースビューデータブロック(B[i]Ax)と、アングル番号xがアングル番号レジスタに設定されている際、読み出されるべきディペンデントビューデータブロック(D[i]Ax)とから構成される。よって、マルチアングル区間を構成する立体視インターリーブドストリームファイルでは、一個のインターリーブユニットが、上述したようなEXTSS[i]の要件を満たすことになる。
プレイリスト情報における基本ストリーム選択テーブルは、プレイアイテム情報によって定義される再生区間において、再生が許可されるベースビュービデオストリームのパケット識別子を示し、拡張ストリーム選択テーブルは、再生が許可されるディペンデントビューストリームのパケット識別子とを対応付けて示す。この点は、第１実施形態と同様である。図３７は、第４実施形態に係るプレイアイテム情報、サブプレイアイテムを示す。同図（ａ）は、プレイアイテム情報、同図（ｂ）は、サブプレイアイテム情報の内部構成を示す。
プレイアイテム情報及びサブプレイアイテム情報は、プレイアイテムがマルチアングル区間を構成するかどうかを示すマルチアングルフラグ(multi＿angleフラグ)を含む。
このフラグがオンに設定されている場合、プレイアイテム情報及びサブプレイアイテム情報には、ストリーム参照情報の拡張構造(multi＿clip＿entries)が設けられる。ストリーム参照情報の拡張構造は、プレイアイテム情報における２つ目以降のAVクリップの指定を含む。このAVクリップの指定は、クリップ情報ファイルネームと、STC識別子レファレンスとの組みである。
プレイアイテム情報におけるストリーム参照情報(clip_information_file_name)、及び、サブプレイアイテム情報におけるストリーム参照情報(clip_information_file_name)は、ベースビュービデオストリームを格納したストリームファイル、及び、ディペンデントビューストリームを格納したストリームファイルであって、再生装置のアングル番号レジスタにおいて１番のアングル番号で識別されるものを指定している。
プレイアイテム情報におけるストリーム参照情報の拡張構造、サブプレイアイテム情報におけるファイル参照情報の拡張構造は、ベースビュービデオストリームを格納したストリームファイル、及び、ディペンデントビューストリームを格納したストリームファイルであって、再生装置のアングル番号レジスタにおいて２番以降のアングル番号で識別されるものを指定する。
プレイアイテム情報は、ベースビュービデオストリームの再生時間軸におけるインタイム、及び、アウトタイムを示す時刻情報を含み、前記サブプレイアイテム情報は、ディペンデントビューストリームの再生時間軸におけるインタイム、及び、アウトタイムを示す時刻情報を含む。
プレイアイテム情報のインタイム及びアウトタイムは、サブプレイアイテム情報のインタイム及びアウトタイムと等価である。
プレイアイテム情報におけるファイル参照情報の拡張情報によって指定されるストリームファイルの本数と、サブプレイアイテム情報におけるファイル参照情報の拡張情報によって指定されるストリームファイルの本数とは同じである。
図３７（ｃ）は、プレイアイテム情報におけるIn＿Time、Out＿Timeと、インターリーブユニットにおけるベースビューデータブロックとの関係を示す。
本図の上半分は、４つのベースビューデータブロックB[1]A1,B[1]A2,B[1]A3,B[1]A4に対応する４つのSTCシーケンスを示す。これらの４つのベースビューデータブロックB[1]A1,B[1]A2,B[1]A3,B[1]A4は、アングル番号が＝１、＝２、＝３、＝４に設定された際、読み出されるべきベースビューデータブロックである。
プレイアイテム情報におけるIn＿Timeは、共通して４つのベースビューデータブロックに対応する４つのSTCシーケンスの再生開始時刻を指定している。
プレイアイテム情報におけるOut＿Timeは、共通して４つのベースビューデータブロックB[1]A1,B[1]A2,B[1]A3,B[1]A4に対応する４つのSTCシーケンスの先頭の再生終了時刻を指定している。
本図の下半分は、４つのディペンデントビューデータブロックD[1]A1,D[1]A2,D[1]A3,D[1]A4に対応する４つのSTCシーケンスを示す。これらの４つのディペンデントビューデータブロックD[1]A1,D[1]A2,D[1]A3,D[1]A4は、アングル番号が＝１、＝２、＝３、＝４に設定された際、読み出されるべきディペンデントビューデータブロックである。プレイアイテム情報におけるIn＿Timeは、共通して４つのディペンデントビューデータブロックに対応する４つのSTCシーケンスの再生開始時刻を指定している。
プレイアイテム情報におけるOut＿Timeは、共通して４つのディペンデントビューデータブロックD[1]A1,D[1]A2,D[1]A3,D[1]A4に対応する４つのSTCシーケンスの先頭の再生終了時刻を指定している。
図３８は、プレイアイテム情報、サブプレイアイテム情報によるマルチアングル区間の指定を示す。第１段目は、Multi＿clip＿entriesを含むプレイアイテム情報を示し、第２段目は、プレイアイテム情報のclip＿information＿file＿nameによって参照される立体視インターリーブドストリームファイルを示す。第３段目は、インターリーブユニットを構成するベースビューデータブロック、ディペンデントビューデータブロックの組みを示し、第４段目は、サブプレイアイテム情報のclip＿information＿file＿nameによって参照される立体視インターリーブドストリームファイルを示す。第５段目は、サブプレイアイテム情報を示す。
プレイアイテム情報におけるclip＿information＿file＿nameは、アングル番号"１"に対応付けられており、プレイアイテム情報のMulti＿clip＿entrieにおけるclip＿information＿file＿nameは、アングル番号＝２、３、４に対応付けられている。そして、アングル番号"１"に対応するclip＿information＿file＿nameは、00001.ssifのストリームファイルを、ベースビュービデオストリームの供給元として指定している。
アングル番号＝２、３、４に対応するclip＿information＿file＿nameは、00002.ssif,00003.ssif,00004.ssifを、ベースビュービデオストリームの供給元として指定している。
サブプレイアイテム情報におけるclip＿information＿file＿nameは、アングル番号"１"に対応付けられており、サブプレイアイテム情報のMulti＿clip＿entrieにおけるclip＿information＿file＿nameは、アングル番号＝２、３、４に対応付けられている。そして、サブプレイアイテム情報において、アングル番号"１"に対応するclip＿information＿file＿nameは、00001.ssifのストリームファイルを、ディペンデントビデオストリームの供給元として指定している。サブプレイアイテムにおけるMulti＿clip＿entrieのアングル番号＝２、３、４に対応するclip＿information＿file＿nameは、00002.ssif、00003.sssif、00004.ssifのストリームファイルを、ディペンデントビデオストリームの供給元として指定している。
00001.ssifはデータブロックB[1]A1,D[1]A1の組みからなるインターリーブユニットを含み、00002.ssifはデータブロックB[1]A2,D[1]A2の組みからなるインターリーブユニット、00003.ssifはデータブロックB[1]A3,D[1]A3の組みからなるインターリーブユニット、00004.ssifはデータブロックB[1]A4,D[1]A4の組みからなるインターリーブユニットを含む。これらの対応付けにより、再生装置におけるアングル番号の設定に応じて、異なるインターリーブユニットが再生装置に読み出されるこになる。
ここで、プレイアイテム情報、サブプレイアイテム情報におけるストリーム参照情報によって参照されている00001.ssifのストリームファイルが図２に示し恐竜のレフトビュービデオストリームを格納しているものとする。
この他、プレイアイテム情報におけるMulti_clip_entrie、及び、サブプレイアイテム情報におけるMulti_clip_entrieによって参照されている00002.ssifが、図２に示した恐竜の後方アングルからの映像を表すベースビュービデオストリーム、及び、ライトビュービデオストリームを格納しているものとする。
また、プレイアイテム情報におけるMulti_clip_entrie、及び、サブプレイアイテム情報におけるMulti_clip_entrieによって参照されている00003.ssifが、図２に示した恐竜の左上アングルからの映像を表すベースビュービデオストリーム、及び、ライトビュービデオストリームを格納しているものとする。
この場合、再生装置におけるアングル番号レジスタの格納値の切り替えによって、上述したような00001.ssif,00002.ssif,00003.ssifのストリームファイルが選択的に再生装置に読み出されることになる。
図３９は、各アングル番号が設定された場合の立体視映像を示す。同図（ａ）は、アングル番号＝１の設定時において、プレイアイテム情報のストリーム参照情報によって参照されるストリームファイル、及び、サブプレイアイテム情報におけるストリーム参照情報によって参照されるストリームファイルが読み出されることで再生されることになる立体視映像を示す。
図３９（ｂ）は、アングル番号＝２の設定時において、プレイアイテム情報のMulti_clip_entrieによって参照されるストリームファイル、及び、サブプレイアイテム情報におけるMulti_clip_entrieによって参照されるストリームファイルが読み出されることで再生されることになる立体視映像を示す。
図３９（ｃ）は、アングル番号＝３の設定時において、プレイアイテム情報のMulti_clip_entrieによって参照されるストリームファイル、及び、サブプレイアイテム情報におけるMulti_clip_entrieによって参照されるストリームファイルが読み出されることで再生されることになる立体視映像を示す。
アングル番号の変化に応じて、ストリーム供給元となるストリームファイルが切り替わるので、基本ストリーム選択テーブル、拡張ストリーム選択テーブルの登録内容が同じであっても、視聴することができる立体視映像を変化させることができる。

以上が本実施形態に係る記録媒体についての説明である。続いて、再生装置の詳細について説明する。
再生装置は、その特有の構成要素として、アングル番号を格納するアングル番号レジスタを具備している。
本実施形態の再生装置における読出部は、アングル番号レジスタにおけるアングル番号が、１番であればプレイアイテム情報におけるファイル参照情報、及び、サブプレイアイテム情報におけるファイル参照情報によって参照されているストリームファイルを読み出す。
アングル番号レジスタにおけるアングル番号が、２番以降であればプレイアイテム情報におけるファイル参照情報の拡張情報、及び、サブプレイアイテム情報におけるファイル参照情報の拡張情報によって参照されているストリームファイルを読み出す。
ベースビュービデオストリームについては、ベースビュービデオストリームの時間軸のうち、プレイアイテム情報の時刻情報によって示されるインタイムからアウトタイムまでを再生し、ディペンデントビューストリームについては、ディペンデントビューストリームの時間軸のうち、従たる再生区間の時刻情報によって示されるインタイムからアウトタイムまでを再生する。
図４０は、Multi_clip_entrieに従ったストリームファイルの読出手順を示す。
ステップＳ６１は、アングル番号レジスタに格納されているアングル番号は"1"であるか否かの判定であり、もしアングル番号が"1"であれば、ステップＳ６２においてプレイアイテム情報におけるclip＿information＿file＿nameで指定されているファイル名、及び、サブプレイアイテム情報におけるclip＿information＿file＿nameで指定されているファイル名のストリームファイルをオープンする。
もしアングル番号が"２以上"であれば、ステップＳ６３においてプレイアイテム情報のmulti＿Clip＿entriesにおけるclip＿information＿file＿nameで指定されているファイル名、及び、サブプレイアイテム情報のmulti＿Clip＿entriesにおけるclip＿information＿file＿nameで指定されているファイル名のストリームファイルをオープンする。
ステップＳ６４では、オープンされたストリームファイルのベースビュービデオストリーム、ディペンデントビュービデオストリームを読み出す。
以上のように本実施形態によれば、あるストリーム選択テーブルのストリーム登録列において、あるパケット識別子で識別されるベースビュービデオストリーム及びディペンデントビューストリームの供給源を、再生装置におけるアングル番号レジスタにおけるアングル番号に応じて、切り替えることができる。例えば、アングル番号"１"であれば、ベースビュービデオストリーム及びディペンデントビューストリームの供給源をインターリーブストリームファイルであると規定し、アングル番号＝２であれば、ベースビュービデオストリーム及びディペンデントビューストリームの供給源を、別のストリームファイルに規定することができる。
また、ユーザ操作によるアングル番号の変化に応じて、様々なストリームファイルからベースビュービデオストリーム及びディペンデントビューストリームをデコーダに供給することができるので、立体視処理のアングル切り替えを容易に実現することができる。
(第４実施形態)
本実施形態では、これまでの実施形態で述べた立体視再生の実現のために、どのような類型のサブパスを設けるべきか、つまり、サブパスの類型について説明する。
これまでの実施形態の立体視再生の実現のため、ディペンデントビュービデオストリームに対して定義される再生区間には、オフディスクタイプのOut-of-MUXディペンデントビュービデオストリーム再生パス(サブパスタイプ＝５)と、オンディスクタイプのOut-of-MUXディペンデントビュービデオストリーム再生パス(サブパスタイプ＝８)がある。
先ず始めに、Out-of-MUXディペンデントビュービデオストリーム再生パス(サブパスタイプ＝５)について説明する。Out-of-MUXフレームワークとは、BD-ROM等のリードオンリー型の記録媒体に記録されているデジタルストリームと、リライタブル型の記録媒体である、ローカルストレージに記録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生させる技術である。
そのためOut-of-MUXディペンデントビュービデオストリーム再生パスに使用されるサブプレイアイテムは、メインパスから分離されている。プレイリストにおけるプレイアイテムが、ディペンデントビュービデオストリームを参照するサブパスタイプ＝５のサブパスに関連付けられているなら、以下の条件を満たす必要がある。
１）プレイアイテムと、関連付けられたサブプレイアイテムとは互いに対応付けてアラインされねばならない。サブプレイアイテムの再生期間は、関連付けられたプレイアイテムと同じになる。具体的にいうと、
１−ａ）サブプレイアイテムの本数はプレイアイテムの本数と同じである。
１−ｂ）プレイアイテム情報とサブプレイアイテムとは１対１対応でなければならない。i番目のサブプレイアイテムにおけるシンクロプレイアイテムレファレンスは、iでなければならない。
１−ｃ）サブプレイアイテムにおけるシンクロスタートタイムプレイアイテムはサブプレイアイテムインタイムと等価でなければならない。
１−ｄ）サブプレイアイテムインタイムは、サブプレイアイテムにおけるシンクロプレイアイテムレファレンスによって参照されているプレイアイテムにおけるインタイムと等価になる。
１−ｅ）サブプレイアイテムアウトタイムは、サブプレイアイテムにおけるシンクロプレイアイテムレファレンスによって参照されているプレイアイテムにおけるアウトタイムと等価になる。
２）連続するサブプレイアイテムが接続されている場合、サブプレイアイテムの接続形態情報によって指示されるサブプレイアイテム間の接続は、クリーンブレークを伴う接続形態(connection＿condition＝５)、又は、ATCシーケンス及びSTCシーケンスが連続している接続形態(connection＿condition＝６)になる。
３）関連するプレイリスト再生タイプが、"プレイアイテムのシーケンシャル再生"を示す場合、サブプレイアイテムのエントリーは、再生される順序に並べられる必要がある。
４）サブパスにおけるサブプレイアイテムのエントリーは、シンクロプレイアイテムレファレンス値に関連した順序で並べられている必要がある。関連するプレイリストのプレイリスト再生タイプがランダムシャッフルであれば、同じシンクロプレイアイテムレファレンスをもつサブプレイアイテム間の再生順序の順に、サブプレイアイテムの順序を並べ替えておく必要がある。
以上が、サブパスタイプ＝５のサブパスが満たすべき条件である。
サブパスタイプ＝５のサブパスは、同期型Out-of-MUXタイプのESパス、及び、Out-of-MUXディペンデントビュービデオ再生パスという2つの機能をもつ。サブパスタイプ＝５のサブパスによって使用されるAVクリップは、多重化されたプライマリオーディオストリーム、PGストリーム、IGストリーム、セカンダリオーディオストリーム、ディペンデントビュービデオストリームから構成することができる。
次に、オンディスクにおけるOut-of-MUXディペンデントビュービデオストリームパス（サブパスタイプ＝８）について説明する。メインパスから分離したディペンデントビュービデオ再生パスを再生するのに、本タイプのサブプレイアイテムは使用される。サブパスタイプ＝８のサブパスに関連付けられたサブプレイアイテムは、以下の条件を満たす必要がある。
１）プレイアイテムと、関連付けられたサブプレイアイテムとは互いに対応付けてアラインされねばならない。サブプレイアイテムの再生期間は、関連付けられたプレイアイテムと同じになる。具体的にいうと、
１−ａ）サブプレイアイテムの本数はプレイアイテムの本数と同じである。
１−ｂ）i番目のサブプレイアイテムにおけるシンクロプレイアイテムレファレンスは、iでなければならない。
１−ｃ）サブプレイアイテムにおけるシンクロスタートタイムプレイアイテムはサブプレイアイテムインタイムと等価でなければならない。
１−ｄ）サブプレイアイテムインタイムは、サブプレイアイテムにおけるシンクロプレイアイテムレファレンスによって参照されているプレイアイテムにおけるインタイムと等価になる。
１−ｅ）サブプレイアイテムアウトタイムは、サブプレイアイテムにおけるシンクロプレイアイテムレファレンスによって参照されているプレイアイテムにおけるアウトタイムと等価になる。
１−ｆ）サブプレイアイテムにおけるMulti_clip_entrieの個数は、シンクロプレイアイテムレファレンスによって参照されているプレイアイテムにおけるMulti_clip_entrieと同数である。
２）接続状態について述べると、連続するサブプレイアイテムが接続されている場合、サブプレイアイテムの接続形態情報によって指示されるサブプレイアイテム間の接続は、クリーンブレークを伴う接続形態(connection＿condition＝５)、又は、ATCシーケンス及びSTCシーケンスが連続している接続形態(connection＿condition＝６)になる。
３）関連するプレイリスト再生タイプが、"プレイアイテムのシーケンシャル再生"を示す場合、サブプレイアイテムのエントリーは、再生される順序に並べられる必要がある。
４）サブパスにおけるサブプレイアイテムのエントリーは、シンクロプレイアイテムレファレンス値に関連した順序で並べられている必要がある。関連するプレイリストのプレイリスト再生タイプがランダムシャッフルであれば、同じシンクロプレイアイテムレファレンスをもつサブプレイアイテム間の再生順序の順に、サブプレイアイテムの順序を並べ替えておく必要がある。
５）プレイアイテム情報におけるイズマルチアングルフラグがオン（マルチアングルを構成する）と設定されており、サブパスタイプ＝８のサブプレイアイテム情報に関連付けられている場合、当該プレイアイテム情報は、ストリーム参照情報の拡張構造（Multi_clip_entrie）を有する。
拡張ストリーム選択テーブルにおける立体視ディペンデントビューブロック(SS＿dependent＿view＿block)のためのストリームエントリーにおけるサブクリップエントリーIDレファレンスは、ストリームエントリーのサブパスIDレファレンスによって参照されるサブパスのサブプレイアイテム情報において、１番目のアングル番号に対応するものとして、ストリーム参照情報から参照されているクリップ情報ファイルにおけるサブクリップエントリーIDを参照せねばならない。
マルチアングル区間を構成するプレイアイテム、及び、サブパスの類型について説明する。マルチアングル区間を構成するプレイアイテムには、ノンシームレスマルチアングルタイプのプレイアイテムを定義することができる。
拡張ストリーム選択テーブルが付加された３Ｄプレイリストにおけるプレイアイテム情報は、イズシームレスアングルチェンジフラグをもつ。このイズシームレスアングルチェンジフラグは、アングル切り替えがノンシームレスであるかシームレスであるかを示す。イズシームレスアングルチェンジフラグが0(ノンシームレス)である場合、３Ｄプレイリストは、インタラクティブグラフィクス再生メニューのサブパス（サブパスタイプ＝３）、立体視インタラクティブグラフィクス再生メニューのサブパス（サブパスタイプ＝９）をもつことができる。
イズシームレスアングルチェンジフラグが0(ノンシームレス)に設定されている場合、拡張ストリーム選択テーブルが付加された３Ｄプレイリストは、立体視再生モードのためのディペンデントビュービデオストリームのためのサブパスとして、上述したようなサブパスタイプ＝３、８、９のサブパスのみを定義することができる。これを除くどのようなサブパスも対応付けることはできない。
以上のように本実施形態によれば、オンディスクで立体視再生を実現するためのサブパスの類型、オフディスクで立体視再生を実現するためのサブパスの類型を設けるので、一枚のディスクで立体視を実現したり、ディスクと他の記録媒体との組合せで立体視を実現することができる。
(第５実施形態)
本実施形態では、クリップ情報ファイルの詳細について説明する。
図４１は、クリップ情報ファイルの内部構成を示す。
同図（ａ）は、2Dのクリップ情報ファイル、同図（ｂ）は、3D用のクリップ情報ファイルを示す。これらのクリップ情報ファイルは、『クリップ情報』、『シーケンス情報』、『プログラム情報』、『特徴点情報』を含む。
『クリップ情報』は、ストリームファイルに格納されているソースパケット列のそれぞれが、どのようなAVクリップであるかをATCシーケンス毎に示す情報であり、対応するAVクリップによって構成されるアプリケーションが、ムービー、スライドショー等、どのような類型に属するか(アプリケーションタイプ)、対応するAVクリップがどのようなストリームの類型に属するか(ストリームタイプ)、AVクリップにおけるTSパケットの転送レート(TSレコーディングレート)、前のAVクリップを構成するATCシーケンスとのATCの差分(ATCデルタ)、符号化に用いた符号化方式の識別子を含む。
『シーケンス情報』は、ストリームファイルに格納されている1又は複数のソースパケット列がどのようなATCシーケンスであるかを示す情報(ATCシーケンス情報)をATCシーケンス毎に示す構成になっている。ATCシーケンス情報は、ATCの開始点たるソースパケットがどこに存在するかをソースパケット番号で示す情報、STCシーケンス識別子ーATCシーケンス識別子間のオフセットと、複数のSTCシーケンスのそれぞれについてのSTCシーケンス情報とを含む。STCシーケンス情報は、そのSTCシーケンスにおけるPCRを格納しているソースパケットのパケット番号、そのATCシーケンスのうち、どこにSTCシーケンスの開始点たるソースパケットが存在するかを示す情報、STCシーケンスにおける再生開始時刻、再生終了時刻を含む。
『プログラム情報』は、クリップ情報ファイルによって"AVクリップ"であるとして管理されているメインTS、サブTSのプログラム構成を示す情報であり、AVクリップがどのようなESを多重化したものであるかを示す。具体的には、AVクリップに多重化されているESがどのようなパケット識別子を有しているか、どのような符号化方式であるかを示す。ビデオストリームが、MPEG2-video,MPEG4-AVC等のうち、どの符号化方式を用いて圧縮符号化されているかは、このプログラム情報内に明示される。
『特徴点情報』は、AVクリップに多重化されている複数のESの特徴点がどこに存在するかを、ES毎に示す情報である。ES毎の特徴点を示す情報は、エントリーマップと呼ばれる。
何が特徴点になるかは、ストリームの種別毎に異なる。ベースビュービデオストリーム、ディペンデントビュービデオストリームの場合は、オープンGOP、クローズドGOPの先頭に位置するIピクチャのアクセスユニットデリッミターが特徴点となる。オーディオストリームの場合は、１秒置き等、一定期間置きに存在するオーディオフレームの先頭位置を示すアクセスユニットデリッミターが特徴点となり、PGストリーム、IGストリームの場合は、グラフィクスストリームのディスプレイセットのうち、表示に必要な全ての機能セグメントを具備したもの(エポックスタートのディスプレイセット、アクジッションポイントのディスプレイセット)の先頭位置を示すアクセスユニットデリッミターが特徴点となる。
また特徴点をどのように表すかは、ATCシーケンス、STCシーケンスのそれぞれで異なる。ATCシーケンスにおいて特徴点は、ソースパケット番号で表現される。STCシーケンスにおいては、同じ特徴点が、STC時間軸における時点を示すPTSを用いて表現される。
上記違いに鑑みES毎のエントリーマップは、複数のエントリーポイントから構成されている。具体的にいうと、エントリーマップを構成する個々のエントリーポイントは、ATCシーケンスにおける特徴点の所在を示すソースパケット番号が、STCシーケンスにおける特徴点の所在を示すPTSと対応付けられており、その特徴点へのアングル切り替えが可能であるか否かを示すフラグ(is＿angle＿changeフラグ)を具備している。マルチアングル区間を構成するインターリーブユニットの先頭に位置するソースパケットは、アングル切り替えが可能になっているため、インターリーブユニットの先頭ソースパケットを差すエントリーポイントのis＿angle＿changeフラグは、必ずオンに設定される。また、インターリーブユニットの先頭ソースパケットを差すエントリーポイントは、エントリーポイントによって、プレイアイテム情報におけるIn_Timeと対応付けられている。
ES毎のエントリーマップは、これらストリーム種別毎の特徴点のソースパケット番号を、PTSに対応付けて示しているので、このエントリーマップを参照することで、STCシーケンスにおける任意の時点から、その時点に最も近いES毎の特徴点の所在を示すソースパケット番号を導くことができる。
以上が2D用のクリップ情報ファイルについての説明である。続いて、3D用のクリップ情報ファイルの詳細について説明する。3D用のクリップ情報ファイルは、図４１（ｂ）の内部構成になっていて、通常のクリップ情報(管理情報)である「ファイル２Ｄ用のクリップ情報」の他に、ファイルディペンデント用のクリップ情報である「クリップディペンデント情報(ベースビュー管理情報)」、ファイルベース用のクリップ情報である「クリップベース情報(ベースビュー管理情報)」が存在する。これは以下の理由による。第２実施形態で述べたように、立体視インターリーブドストリームファイルと、通常のストリームファイルとの混同を避けるため、立体視インターリーブドストリームファイルは、ストリームファイルとは異なるディレクトリに格納される。そのため立体視インターリーブドストリームファイルには、クリップ情報ファイルを対応付けることができない。そこで、クリップディペンデント情報、及び、クリップベース情報は、ファイル２Ｄに対応するクリップ情報ファイルに格納されることになる。
2D用のクリップ情報と、クリップベース情報及びクリップディペンデント情報との違いは、クリップベース情報及びクリップディペンデント情報の内部に、エクステントスタートポイント列を含むメタデータが存在する点である。
図４１（ｂ）において、クリップディペンデント情報は、エクステントスタートポイント列を含み、クリップベース情報も、エクステントスタートポイント列を含む。クリップディペンデント情報内に存在するエクステントスタートポイント列は、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルディペンデントを構成する複数のエクステントの先頭のソースパケット番号を示す。
クリップベース情報内に存在するエクステントスタートポイント列も、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルベースを構成する複数のエクステントの先頭のソースパケット番号を示す。
これらのエクステントスタートポイント情報が存在することの技術的意義について述べる。
ストリームファイルに格納されているTSは、本来は、1つのTSであり、ATCシーケンスも1つのみである。よって、クリップ情報ファイルのシーケンス情報を参照しただけでは、分割部分の先頭がどこであるかを判別することはできない。一方、分割部分の先頭はエクステントの先頭でもあるので、ファイルエントリやエクステント記述子といったファイルシステムの情報を参照すれば、分割部分の先頭がどこであるかを知ることができるが、ファイルシステムの情報はミドルウェアで管理されている情報であるため、アプリケーションからこのエクステントの情報を参照するのは困難を極める。そこで、本実施形態では、エクステントスタートポイント情報を用いて、エクステントが何パケット目であるかをクリップ情報内に示させるようにしている。
図４１（ｃ）は、エクステントスタートポイント情報を記述するための、プログラム言語によるシンタックスを示す。
本図において、extention＿idを制御変数とするfor文は、extention＿idを引数とするエクステントスタートポイントを、number＿of＿extention＿start＿pointsだけ繰り返すループである。インターリーブストリームファイルにおけるエクステントの本数ｔを、このnumber＿of＿extention＿start＿pointsに記述して上記for文を作成すれば、インターリーブストリームファイルに対応するようなエクステントスタートポイント情報が作成されることになる。
図４２は、クリップ情報ファイルにおけるエントリーマップテーブルと、エクステントスタートポイント情報とを示す。 本図（ａ）は、エントリーマップテーブルの概略構成を示す。引出線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と対応付けている。
図４３は、プログラム情報におけるストリーム属性情報を示す。
図中の引き出し線ah1は、ストリーム属性の内部構成をクローズアップして示している。
この引出線に示すように、PID＝0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性、PID＝0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性、PID＝0x1100、PID＝0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。
図４４は、エントリーマップによるエントリーポイントの登録を示す。第１段目は、SCシーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、クリップディペンデント情報におけるエクステントスタートポイント情報、及び、クリップベース情報におけるエクステントスタートポイント情報を示す。第４段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうち＝n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける＝n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち＝n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおける＝n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生装置はビデオストリームの時間軸上の任意の地点に対応するソースパケットを特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。
また第３段目における、クリップディペンデント情報におけるエクステントスタートポイント[i]、クリップベース情報におけるエクステントスタートポイント[j]は、第４段目において、ディペンデントビュービデオストリームを構成するエクステント、ベースビュービデオストリームを構成するエクステントの先頭ソースパケット番号がどれであるかを示す。
これにより、クリップディペンデント情報におけるエクステントスタートポイント[i]で示されるソースパケットから、クリップベース情報のエクステント[j]によって示されるソースパケットの直前のソースパケットまでを読み出せば、ディペンデントビュービデオストリームを構成するソースパケット列のみを抽出することができる。
クリップベース情報におけるエクステントスタートポイント[j]で示されるソースパケットから、クリップディペンデント情報におけるエクステント[i+1]によって示されるソースパケットの直前のソースパケットまでを読み出せば、ベースビュービデオストリームを構成するソースパケット列のみを抽出することができる。
そして、ベースビュービデオストリームを構成するソースパケット同士、ディペンデントビュービデオストリームを構成するソースパケット同士を統合すれば、ベースビュービデオストリーを構成するATCシーケンス、ディペンデントビュービデオストリームを構成するATCシーケンスを復元することができる。
図４５は、立体視インターリーブドストリームファイルを構成するデータブロックからATCシーケンスがどのように復元されるかを示す。
第４段目は、立体視インターリーブドストリームファイルを構成する複数のデータブロックを示し、第３段目は、メインTS、サブTSに多重化されるソースパケット列を示す。
第２段目は、ディペンデントビューを構成するSTCシーケンス２、エントリーマップ、ディペンデントビューを構成するATCシーケンス２の組みを示し、第１段目は、ベースビューを構成するSTCシーケンス１、エントリーマップ、ベースビューを構成するATCシーケンス１の組みを示す。第３段目から第２段目、第１段目への矢印は、立体視インターリーブドストリームファイルにインターリーブ化されている2つのTS(メインTS、サブTS)のデータブロックからATCシーケンス１、ATCシーケンス２が復元されることを模式的に示す。これらのATCシーケンスは、クリップ情報におけるエントリーマップによって、STCシーケンスとの対応がとられる。
以上が本実施形態に係る記録媒体についての説明である。続いて、再生装置の詳細について説明する。
本実施形態における再生装置の読出部は、2つの記録媒体からのソースパケット入力を受け付ける構成になっており、2つの記録媒体のそれぞれをアクセスするための2つのドライブ、これら2つのドライブから入力されたソースパケットを一旦格納してデコーダに出力するための2つのリードバッファを含む。そして、2つのドライブと、2つのリードバッファとの間に、ATCシーケンス復元部が存在する。このATCシーケンス復元部は、1つの記録媒体から読み出されたインターリーブドストリームファイル内のソースパケットから、ベースビューを構成するATCシーケンスと、ディペンデントビューストリームを構成するATCシーケンスとを分離し、2つのリードバッファのそれぞれに書き込むものである。こうすることで再生装置は、ベースビュービデオストリームを構成するATCシーケンス、ディペンデントビューストリームを構成するATCシーケンスがそれぞれ別々の記録媒体から読み出されたかのように処理することができる。図４６（ａ）は、ATCシーケンス復元部を具備した読出部の内部構成を示す。上述したように、2つのドライブと、2つのリードバッファとの間にATCシーケンス復元部が介在している。図中の矢印B0は、1つのドライブからのソースパケット入力を象徴的に示したものであり、矢印B1は、ベースビュービデオストリームを構成するATCシーケンス１の書き込み、矢印D1は、ディペンデントビューストリームを構成するATCシーケンス２の書き込みを模式的に示す。
図４６（ｂ）は、ATCシーケンス復元部によって得られた2つのATCシーケンスが、どのように取り扱われるかを示す。図中の真ん中に多重分離部内に存在するPIDフィルタを示す。左側は、ATCシーケンス復元部によって得られた2つのATCシーケンスを示す。右側は、これらの2つのATCシーケンスを多重分離することで得られるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリームを示す。これらの2つのPIDフィルタによる多重分離は、第１実施形態に示した基本ストリーム選択テーブル、拡張ストリーム選択テーブルによる。
このATCシーケンス復元部は、図４７の処理をハードウェア資源に実行させるプログラムを作成することで実現される。図４７は、ATCシーケンス復元手順を示す。
ステップＳ７１は、ベースビュー用のATCシーケンスをATCシーケンス１とし、ディペンデントビュー用のATCシーケンスをATCシーケンス２とする。ステップＳ７２では、ファイル2Dに対応するクリップ情報ファイルのうち、クリップディペンデント情報、及び、クリップベース情報からエクステントスタートポイント情報を取り出す。そして、ステップＳ７３〜ステップＳ７７のループに移行する。このループは、変数i、変数jを1に初期化して(ステップＳ７３)、ステップＳ７４〜ステップＳ７６を実行し、その後、変数i,変数jをインクリメントする(ステップＳ７７)という処理を繰り返すものである。
ステップＳ７４は、クリップディペンデント情報において、エクステントスタートポイント情報[i]で指示されるソースパケット番号のソースパケットから、クリップベース情報において、エクステントスタートポイント情報[j]で指示されるソースパケット番号の直前のソースパケットまでをATCシーケンス２に追加する。
ステップＳ７５は、クリップベース情報において、エクステントスタートポイント情報[j]で指示されるソースパケット番号のソースパケットから、クリップディペンデント情報において、エクステントスタートポイント情報[i+1]で指示されるソースパケット番号の直前のソースパケットまでをATCシーケンス１に追加する。
ステップＳ７６は、エクステントスタートポイント情報[i+1]が存在するかどうかの判定である。もし、エクステントスタートポイント情報[i+1]が存在しないと判定された場合、ステップＳ７８において、クリップベース情報内のエクステントスタートポイント情報[j]で指示されるソースパケット番号のソースパケットから、立体視インターリーブドストリームファイルの最後のソースパケットまでをATCシーケンス１に追加する。
以上の処理を繰り返すことで、ベースビューデータブロックはATCシーケンス１に統合されることになり、ディペンデントビューデータブロックはATCシーケンス2に統合されることになる。以上のように、ATCシーケンス１、２が復元されれば、ベースビューデータブロックの先頭アドレス及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする(ステップＳ７９)。同様に、ディペンデントビューデータブロックの先頭アドレス及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルディペンデントを仮想的にオープンする(ステップＳ８０)。
エクステントスタートポイント情報は、データブロックの先頭アドレスをソースパケット番号で示しているので、ソースパケット番号で表現されているデータブロックの先頭アドレス及びソースパケット数で表現されているデータブロックの連続長を、セクタ数に変換にする必要がある。この変換手順の詳細を述べる。
ソースパケットは、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のソースパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のソースパケットを"Aligned Unit"といい、記録媒体への書き込みにあたっては、Aligned Unit単位で暗号化がなされる。
データブロックを構成するソースパケットは32個毎に1つのAligned Unitに変換され、3つのセクタに記録されるので、ソースパケット番号を32で割ることにより商を得て、その商を、Aligned Unitのアドレスとして解釈する。こうして得られたAligned Unitアドレスに3を乗ずることにより、データブロックの先頭ソースパケットに最も近いセクタアドレスを求めることができる。
またデータブロックの連続長を示すソースパケット数を32で割ることにより、商を得て、その商を連続Aligned Unit数として解釈する。こうして得られたAligned Unit数に3を乗ずることにより、データブロックの連続長をセクタ数で表現することができる。以上の変換により得られたデータブロックのアドレス、及び、連続長を表すセクタ数をアロケーション記述子として、ファイルベースのファイルエントリー、及び、ファイルディペンデントのファイルエントリーに組込めば、ファイルベース、ファイルディペンデントのファイルエントリーを仮想的に生成することができる。
＜ファイルベースをオープンすることの技術的意義＞
ここで任意の時点からのランダムアクセスを行う際、ストリームファイル内のセクタサーチを行う必要がある。セクタサーチとは、任意の時点からのランダムアクセスを行う際、その時点に対応するソースパケットのソースパケット番号を特定して、そのソースパケット番号のソースパケットを含むセクタから、ファイルリードを行うという処理である。
立体視インターリーブドストリームファイルは、一個のエクステントが大きいため、セクタサーチの探索範囲が広く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定に、かなりの処理時間を要することがある。
これは、インターリーブストリームファイルは、ベースビュービデオストリームを構成するデータブロック、ディペンデントビューストリームを構成するデータブロックがインターリーブ配置されて一本の長いエクステントを構成しており、インターリーブストリームファイルのファイルエントリーのアロケーション記述子は、その長いエクステントの先頭アドレスを示しているに過ぎないとの理由による。
これに対してファイルベースは、長さが短い複数のエクステントから構成されており、個々のエクステントの先頭アドレスがアロケーション記述子に示されているため、セクタサーチにあたっての探索範囲が狭く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定が、短時間で完了する。

つまり、ベースビュービデオストリームを構成するデータブロックが、ファイルベースのエクステントとして管理されており、データブロックの先頭アドレスが、ファイルベースに対応するファイルエントリーにおけるアロケーション記述子に明記されているので、ランダムアクセス位置を包含しているエクステントの先頭アドレスから、セクタサーチを開始すれば、早期にランダムアクセス位置となるソースパケットを含むセクタにまで到達することができる。
このようにベースビュービデオストリームを構成するデータブロックを、ファイルベースのエクステントとして管理し、各エクステントの先頭アドレス及び連続長を、ファイルベースについてのファイルエントリーのアロケーション記述子に示しておくことにより、ベースビュービデオストリームにおける任意の時点からのランダムアクセスが高速になる。
具体的なセクタサーチの手順は以下のものになる。ベースビュービデオストリームに対応するエントリーマップを用いることにより、任意の時点に対応するランダムアクセス位置であるソースパケット番号を導き出す。
次に、ベースビュービデオストリームに対応するクリップ情報内のエクステントスタートポインティング情報を用いることにより、ランダムアクセス位置となるソースパケット番号を包含しているエクステントがどれであるかを特定する。
更に、ファイルベースに対応するファイルエントリーのアロケーション記述子を参照すれば、ランダムアクセス位置となるソースパケット番号を包含しているエクステントの先頭セクタアドレスを特定することができる。その先頭セクタアドレスにファイルポインタを設定して、ファイルリードを行い、読み出されたソースパケットに対するパケット解析を実行することで、ランダムアクセス位置となるソースパケット番号のソースパケットを特定する。そして特定されたソースパケット番号のソースパケットを読み出す。これにより、メインTSに対するランダムアクセスが効率的に実行されることになる。サブTSも同様である。
以上のように本実施形態によれば、インターリーブドストリームファイルにおけるベースビュービデオストリームのエクステント、ディペンデントビュービデオストリームのエクステントをエクステントスタートポイント情報に基づき整列した上で多重分離部、デコーダに供するので、デコーダやプログラムは、ベースビュービデオストリームを格納したファイルベース、及び、ディペンデントビュービデオストリームを格納したファイルディペンデントという2つのファイルが記録媒体に仮想的に存在するものとして扱うことができる。
立体視のためのベースビュービデオストリーム、ディペンデントビュービデオストリームをインターリーブストリームファイルとして記録媒体に記録しつつも、ベースビュービデオストリーム及びディペンデントビュービデオストリームの単体アクセスを可能にせしめるので、再生装置の処理の効率性を向上させることができる。
尚、エクステントスタートポイント情報は、１バイト単位で、エクステントの先頭を示しても良いが、エクステントがECCブロックのような固定長の読み取りブロックサイズにアラインする場合は、固定長単位で指定することが望ましい。こうすることでアドレスを識別するために必要な情報量を抑えることも可能である。
(第６実施形態)
本実施形態は、立体視スライドショーのアプリケーションを実現する改良に関する。
スライドショーは、静止画から構成されていることから、映画よりも、高精度なランダムアクセスが要求される。高精度なランダムアクセスとは、1枚先、10枚先というように、"一枚のピクチャ"をアクセス単位にしたランダムアクセスである。ビデオストリームのエントリーマップは、1秒間隔というように、1秒程度の時間精度をもち、この1秒という時間間隔には、20〜30枚のピクチャが包含され得る。そのため、上述したエントリーマップを用いてピクチャ精度でのランダムアクセスを実現しようとすると、エントリーマップの参照だけでは足りず、ストリームに対する解析が必要になる。
ここでの"ストリームの解析"とは、エントリーマップに記載されているエントリー位置から、ピクチャのヘッダを取り出し、このヘッダからピクチャのサイズを読み出して、そのサイズに基づき、次のピクチャの記録位置を特定するという処理を、何回も繰り返し、所望のピクチャの記録位置まで辿りつくというものである。かかる解析は、ストリームに対する高頻度のアクセスを伴うものなので、エントリー位置から3枚先、5枚先のピクチャを読み出すだけでも、相当の時間がかかる。ピクチャ精度のランダムアクセスに相当の時間がかかるため、ユーザ操作に即応して、前後のピクチャを表示させたり、10枚前後のピクチャを表示させうる機能をスライドショーに追加しようとしても、制作者サイドが期待するような、使い勝手にならない。
スライドショーに対するエントリーポイントは、ビデオストリームにおけるピクチャ毎のエントリーアドレスを再生時刻に対応づけて示している。そして、プレイリストマーク情報は、個々のピクチャデータを指定するようにしている。
このように個々のピクチャデータがエントリーポイントと、プレイリストマーク情報とによって指示されれば、1枚先、3枚先というように、ピクチャ精度のランダムアクセスが要求されたとしても、ビデオストリームの解析を伴うことなく、ピクチャ精度のランダムアクセスを実現することができる。
時間軸上の任意の時点からビデオストリーム上の記録位置を導くことができ、また、1枚先、3枚先というピクチャ精度でのランダムアクセスを実現することができるので、ユーザ操作に即応して、前後のピクチャを表示させたり、数枚前後のピクチャを表示させうるアプリケーションを制作することができる。
これまでの実施形態において、立体視再生可能なビデオストリームは、インターリーブ形式にしていたが、このようにインターリーブ形式にすると、スライドショーを構成するピクチャデータは、Ｌ−ＬーＬ、Ｒ−ＲーＲというような順序で配列されることになる。このような順序の全てのピクチャデータが、スライドショーを構成しており、個々のピクチャデータがエントリーポイントによって指示されれば、エントリーポイントは、００：００→００：０１→００：０２、００：００→００：０１→００：０２というような順序で、配列されることになる。
エントリーマップにおけるエントリーポイントは、その再生時刻が昇順になるように並ばなければならず、エントリーマップに対する制約に違反する。そこで、AVクリップのアプリケーションタイプがスライドショーである場合の特有の制限として、レフトビューストリームを構成するピクチャデータ、及び、ライトビューストリームを構成するピクチャデータを１TS化することにする。このように、１TS化すれば、レフトビューストリームを構成するピクチャデータ、及び、ライトビューストリームを構成するピクチャデータをＬ−Ｒ−Ｌ−Ｒ−Ｌ−Ｒという順序で配列することができ、そして、これらのピクチャデータのエントリーポイントについては、そのエントリーポイントにおける再生時刻が、００：００→００：００→００：０１→００：０１→００：０２→００：０２→００：０３、００：０３になるように配列することができる。
1枚のスライドをなすピクチャデータを時間順序に配列し、その上で多重化を行うことで、多重化されたピクチャデータのかたまりが、記録媒体の連続領域に記録されることになる。
図４８は、ビデオストリームの内部構成を示す。本図では、同図（ａ）は、ムービーアプリケーションを構成するビデオストリームを示す。（ａ）の第２段目は、ベースビュービデオストリームと、ディペンデントビューストリームとをインターリーブ形式にした立体視インターリーブドストリームファイルを示す。図中のR1,R2,R3,R4は、ディペンデントビュービデオストリームを構成するピクチャデータであり、L1,L2,L3,L4は、ベースビュービデオストリームを構成するピクチャデータである。R5,R6,R7,R8は、ディペンデントビュービデオストリームを構成するピクチャデータである。
第１段目は、このインターリーブストリームファイルと実体を同一にするディペンデントビューストリームのストリームファイルを示す。ファイル名と、m2tsの拡張子とによって構成される。このディペンデントビューストリームのストリームファイルは、R1、R2、R3、R4、R5、R6、R7、R8によって構成される。以上のようにムービーアプリケーションでは、ディペンデントビューストリームが使用されることで構成されることがわかる。
同図（ｂ）の第２段目は、静止画スライドショーにおけるIピクチャを示す。図中のレフトビューピクチャ「Ｌ」、ライトビューピクチャ「Ｒ」は、「Ｌ」「Ｒ」「Ｌ」「Ｒ」「Ｌ」「Ｒ」の順序で多重化されて、記録されていることがわかる。
ベースビュー静止画であるピクチャデータの先頭であるアクセスユニットデリミターは、ディペンデントビュー静止画であるピクチャデータの先頭より先行しており、且つ、ディペンデントビュー静止画であるピクチャデータの後尾は、前記ベースビュー静止画の次に再生されるべきベースビュー静止画のピクチャデータにおける先頭を表すアクセスユニットデリミターより先行している。そして、これらベースビュー静止画のピクチャデータの先頭であるアクセスユニットデリミターを格納したソースパケット、ディペンデントビュー静止画のピクチャデータの先頭であるアクセスユニットデリミターを格納したソースパケットは、自身以外のピクチャデータを含んでいない。つまり、ベースビュー静止画を表すピクチャデータ、ディペンデントビュー静止画を表すピクチャデータは、完結した状態で、ベースビュー−ディペンデントビュー−ベースビューーディペンデントビューの順に、記録領域に並んでいる。
しかし、第１段目に示すように、ディペンデントビューストリームは使用されておらず、スライドショーアプリケーションでは、ライトビューの映像をディペンデントビューストリームとしてアクセスすることができない。
レフトビューのピクチャデータ、ライトビューのピクチャデータを多重化しているのは以下の理由による。ピクチャデータを一個のエクステントとして記録媒体に記録しようとすると、最小エクステント長を満たせない。最小エクステント長を満たすため、複数のピクチャデータを上述したように時間順序に配置した上多重化して、多重化されたTSを記録する。こうすることで、最小エクステント長を満たすように、TSを分割して記録することが可能になる。
対照的に、サイズが比較的小さいため、１枚の静止画を表示するためのデータを固めて配置した方が、読み取り効率が上がることになる。
続いて、AVクリップにおけるアプリケーションの種別を示す情報(application＿type)がスライドショー(application＿type=2or3)である場合の、エントリーマップ設定について説明する。時間軸上の複数の時点(t1〜t7)において、再生がなされるよう、PTSが設定されたIDRピクチャが、スライドショー内に存在するものとする。この場合、このスライドショーに対するエントリーマップ設定は、図４９のようになる。図４９は、スライドショーに対し、設定されたエントリーマップの内部構成を示す。
スライドショーでは、全てのピクチャを指示するようエントリーマップを設定するので、エントリーマップにおける個々のEntry＿Point#1〜#7は、スライドショーにおける個々のIDRピクチャの再生時点t1,t2,t3,t4,t5,t6,t7を、エントリー時刻(PTS＿EP＿start)として特定し、エントリー位置(SPN＿EP＿start)と対応づけられていることがわかる。
こうして、各IDRピクチャの再生時点が、エントリー時刻として、エントリーマップにより指定されるので、t1〜t7のうち、どれかをランダムアクセスのアクセス先に選ぶ場合でも、先行するIDRピクチャを経由するという迂回のオーバーヘッドが発生することはない。
本図の第１段目は、PlayListMark情報の設定を示し、第２段目はプレイアイテム情報におけるインタイムの指定を示す。第３段目は、Ｌ画像、Ｒ画像を示し、第４段目はエントリーマップ、第５段目は、ソースパケット列を示す。
スライドショーでは、全てのレフトビューピクチャ、ライトビューピクチャを指示するようエントリーマップを設定するので、エントリーマップにおける個々のEntry＿Point#1〜#7は、スライドショーにおける個々のIDRピクチャの再生時点t1,t2,t3,t4,t5,t6,t7を、エントリー時刻(PTS＿EP＿start)として特定し、エントリー位置(SPN＿EP＿start)と対応づけていることがわかる。
第３段目における時点t2,t4,t6のうち、t6をアクセス先にしてランダムアクセスを実行しようとすると、時点t6そのものが、PTS＿EP＿startに指示されているので、先のレフトビューピクチャを経由することなく、時点t6にあたる、記録位置(SPN=N6)をアクセスすることができる。
全てのレフトビューピクチャの再生時点も、PTS＿EP＿startにより指示されているので、スライドショーにおける、時間情報を用いたランダムアクセスを高速に実行することができる。
上述したようなエントリーマップ設定に伴い、クリップ情報におけるApplication＿Typeを2又は3に示しておけば、スライドショーを構成するすべてのピクチャに対してエントリーマップ上にエントリーが存在することが識別できるので、エントリーマップのエントリーを参照することにより、読み出すデータの範囲が判明し、前後のストリームを余分に解析する必要がなくなる。
以上が記録媒体についての説明である。続いて、再生装置の詳細について説明する。再生装置がスライドショー再生を行うには、再生制御エンジンが図５０に示すような処理手順で再生を行えばよい。
図５０は、スライドショープレイリストの再生手順を示す。ステップＳ８１は、カレントプレイアイテム番号を"1"に初期化し、ステップＳ８２において、カレントプレイアイテムにおけるclip＿information＿file＿nameのアプリケーションタイプがスライドショーであるかどうかを判定する。もしムービアプリケーションであれば、ステップＳ８３においてムービーアプリケーションの処理を行う。
スライドショーであれば、ステップＳ８４〜ステップＳ９０の処理を繰り返すループに移行する。このループは、ステップＳ８５、ステップＳ８６の判定を経て、カレントPlayItem.In＿Timeに合致するか、最も近いエントリーポイント[i]をエントリーマップから特定し(ステップＳ８７)、エントリーポイント[i]で指示されているソースパケット番号のソースパケットからエントリーポイント[i+1]で指示されているソースパケット番号の直前のソースパケットまでを読み出し、ベースビュー側のPIDフィルタに送り込む処理(ステップＳ８８)、エントリーポイント[i+1]で指示されているソースパケット番号のソースパケットからエントリーポイント[i+2]で指示されているソースパケット番号の直前のソースパケットまでを読み出し、ディペンデントビュー側のPIDフィルタに送り込む処理(ステップＳ８９)を、カレントPlayItem番号が最終のPlayItem番号になるまで繰り返すというものである(ステップＳ９４)。このステップＳ９４の判定がYesにならない限り、カレントPlayItem番号はインクリメントされた上で、ステップＳ８５に移行する。
ステップＳ８５は、スキップバック操作がなされたかどうかの判定であり、ステップＳ８６は、スキップネクスト操作がなされたかどうかの判定である。スキップネクスト操作がなされれば、カレントチャプター番号がインクリメントされ(ステップＳ９０)、スキップバック操作がなされれば、カレントチャプター番号が"1"かどうかが判定されて(ステップＳ９１)、"1"でなければデクリメントされる(ステップＳ９２)。
そして、ステップＳ９３では、カレントチャプター番号に対応するPlayListMarkのPlayItem＿ref＿idで参照されているPlayItem番号を、カレントPlayItem番号として、ステップＳ５５に移行する。
以上のように本実施形態によれば、ストリーム解析を行うことなく、任意のL画像のピクチャデータ、R画像のピクチャデータの組みを読み出して、再生に供することができるので、ユーザのスキップ操作に従い、任意のピクチャデータをランダムアクセスすることができるスライドショーアプリケーションを容易に実現することができる。
(第７実施形態)
本実施形態では、多重分離部、デコーダ、プレーンメモリのハードウェアスケールについて説明する。
本実施形態における多重分離部は、ソースパケットデパケッタイザー、PIDフイルタとの組みを1つ以上含む。このソースパケットデパケッタイザー、PIDフイルタの組みは、ストリーム入力の系統数に応じた数だけ存在する。
図５１は、多重分離部及びビデオデコーダの内部構成を示す。
同図（ａ）は、多重分離部のデコーダモデルを示す。多重分離部 (Source De-packetizer and PID filter)の組みは2つになる。これは、多重分離部が本来、2つの記録媒体からの2系統のストリーム入力を処理する構成になっているからである。2D再生モードでは、2つの記録媒体からのストリーム入力を処理することができるが、3D再生モードでは、LとR、2DとDepthという2系統のストリーム入力を処理することになる。
同図（ａ）に示すように、多重分離部は、ソースデパケッタイザ２２、PIDフィルタ２３、ソースデパケッタイザ２７、PIDフィルタ２８から構成される。
ソースデパケッタイザ２２は、リードバッファ２aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ２３は、ソースデパケッタイザ２２から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デコーダに出力する。
ソースデパケッタイザ２６は、リードバッファ２bにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
PIDフィルタ２７は、ソースデパケッタイザ２６から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デコーダに出力する。
次にプライマリビデオデコーダ３１の内部構成について説明する。
図５１（ｂ）は、プライマリビデオデコーダの内部構成を示す。プライマリビデオデコーダ３１は、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ピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。
ピクチャスイッチ６０は、デコーダコア５７から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。
モード切り替え時におけるビデオスデコーダの動作について述べる。LR方式の場合はL側の出力だけに切り替えれば2D表示になり、Depth方式の場合は、深度情報の処理をやめ、深度情報を付加しなけれ2D映像に切り替えることができる。ただし、LR方式とDepth方式は必要とするデータが異なるため、相互の切り替えを行う際には、デコードするストリームの再選択が必要となる。
次に、再生装置におけるデコーダ及びプレーンメモリの規模について説明する。
装置構成が、１デコーダになるか、２デコーダになるか、１プレーンになるか、２プレーンになるかは、ストリーム種別と、立体視方式との組合せによって変わる。
3D-LR方式を採用する場合、MVCビデオストリームが再生対象であれば、１デコーダ＋２プレーン構成になる。
3D-Depth方式を採用する場合も、１デコーダ＋２プレーン構成になり、視差画像生成器が必要になる。これはプライマリビデオストリーム、セカンダリビデオストリームでも同様である。図５２は、3D-LR方式、3D-Depth方式における１デコーダ＋２プレーンの装置構成を示す。図５２（ａ）は、3D-LR方式を採用する場合における１デコーダ＋２プレーン構成を示す。図５２（ｂ）は、3D-Depth方式を採用する場合における１デコーダ＋２プレーン構成を示す。
MVCビデオストリームにおいて装置構成が1デコーダになるのは、個々の圧縮ピクチャデータのマクロブロックの動き補償を実現するにあたって、非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータを参照画像として利用するからである。デコーデッドピクチャバッファに、参照画像となる非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータが格納される。
以上がビデオデコーダ、ビデオプレーンについての説明である。
PGストリームにおける再生装置の構成は、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。3D-LR方式、3D-Depth方式を採用する場合、２デコーダ＋２プレーン構成になる。
同じく、IGストリームにおける再生装置構成は、3D-LR方式を採用する場合、２デコーダ＋２プレーン構成になる。一方、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。
テキスト字幕ストリームにおける再生装置構成では3D-LR方式が存在せず、1plane＋Offsetモードである場合、１デコーダ＋１プレーン構成になる。3D-Depth方式である場合、１デコーダ＋２プレーン構成になる。
次に、PGストリームの内部構成と、PGストリームをデコードするPGデコーダの内部構成とについて説明する。
レフトビューPGストリーム、ライトビューPGストリームは、何れも複数のディスプレイセットを含む。ディスプレイセットとは、一個の画面表示を構成する機能セグメントの集まりのことである。機能セグメントは、約2KバイトのPESパケットのペイロードに格納されてデコーダに供給され、DTS、PTSを用いて、再生制御がなされる処理単位のことである。
ディスプレイセットには、以下の類型がある。
Ａ.エポックスタートのディスプレイセット
エポックスタートのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンをリセットして、メモリ管理を開始させる機能セグメントの集まりであり、画面構成に必要な機能セグメントを全て含んでいる。
Ｂ.ノーマルケースのディスプレイセット
ノーマルケースのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理を継続したまま画面構成を行うディスプレイセットであり、先行するディスプレイセットからの差分となる機能セグメントを含んでいる。
Ｃ.アクジッションポイントのディスプレイセット
アクジッションポイントのディスプレイセットとは、画面構成に必要な機能セグメントを全て含むディスプレイセットであるが、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理をリセットさせないディスプレイセットである。このアクジッションポイントのディスプレイセットには、前のディスプレイセットとは異なる内容の機能セグメントが存在してもよい。
Ｄ.エポックコンティニューのディスプレイセット
エポックコンティニューのディスプレイセットとは、PGストリームの再生を許可しているプレイアイテムと、その直前のプレイアイテムとの接続形態が、クリーンブレークを伴うシームレス接続(CC=5)である場合、再生装置におけるコンポジションバッファ、コードデータバッファ、オブジェクトバッファ、グラフィクスプレーンにおけるメモリ管理を、そのまま継続させる旨を示す。この際、オブジェクトバッファ、グラフィクスプレーン上に得られたグラフィクスオブジェクトは、廃棄されることなく、オブジェクトバッファ、グラフィクスプレーン上で存続する。
レフトビューと、ライトビューとでは、STCシーケンスにおける再生時間軸の同一時点に、これらのディスプレイセットの始点・終点が割り当てられている。そして、レフトビューPGストリームと、ライトビューPGストリームとでは、時間軸上の同じ時点に存在するディスプレイセットの類型は、同一になっている。つまりレフトビュー側のディスプレイセットがエポックスタートのディスプレイセットであるなら、STCシーケンスの時間軸において同じ時点のライトビュー側のディスプレイセットは、エポックスタートのディスプレイセットになる。
また、レフトビュー側のディスプレイセットがアクジッションポイントのディスプレイセットであるなら、STCシーケンスの時間軸において同じ時点のライトビュー側のアクジッションポイントのディスプレイセットも、アクジッションポイントのディスプレイセットになる。
各ディスプレイセットは、複数の機能セグメントを含む。この複数の機能セグメントには以下のものがある。
(1)オブジェクト定義セグメント
オブジェクト定義セグメントは、グラフィクスオブジェクトを定義する機能セグメントである。グラフィクス定義セグメントは、コード値と、そのコード値のランレングスとを用いることで、グラフィクスオブジェクトを定義している。
(2)パレット定義セグメント
パレット定義セグメントは、各コード値と、輝度、赤色差・青色差との対応関係を示したパレットデータを含む。レフトビューグラフィクスストリームのパレット定義セグメントと、ライトビューグラフィクスストリームのパレット定義セグメントとでは、コード値と、輝度及び色差との対応関係が同一の内容に設定されている。
(3)ウィンドゥ定義セグメント
ウィンドゥ定義セグメントは、非圧縮のグラフィクスオブジェクトを画面上に展開するためのプレーンメモリにおいて、ウィンドゥと呼ばれる矩形枠を定義する機能セグメントである。グラフィクスオブジェクトの描画は、このプレーンメモリの内部で制限されており、このウィンドゥの外部では、グラフィクスオブジェクトの描画は行えない。
プレーンメモリの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
(4)画面構成セグメント
画面構成セグメントは、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントであり、グラフィクスデコーダにおけるコンポジションコントローラに対する複数の制御項目を含む。画面構成セグメントは、グラフィクスストリームにおけるディスプレイセットの詳細を規定すると共に、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントである。かかる画面構成には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、画面構成セグメントによる画面構成を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
(5)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグメントである。再生装置は、画面構成セグメントからこのエンドセグメントまでが、1つのディスプレイセットを構成する機能セグメントであるとして解釈する。

PGストリームにおいてディスプレイセットの開始時点は、画面構成セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、画面構成セグメントを格納したPESパケットのPTSによって特定される。
レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームは、パケッタイズドエレメンタリストリーム(PES)であり、画面構成セグメントは、PESパケットに格納され、画面構成セグメントを格納したPESパケットのPTSは、画面構成セグメントが属するディスプレイセットによる表示を何時実行するかを示す。
画面構成セグメントを格納したPESパケットのPTSの値は、レフトビュービデオストリームと、ライトビュービデオストリームとで同一の内容になっている。
・PGデコーダのデコーダモデル
PGデコーダは、PGストリームから読み出されう機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するためのトランスポートバッファが存在する。
グラフィクスデコーダの後段には、グラフィクスプレーンと、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換するCLUT部と、プレーンシフトのためのシフト部とが存在する。
PGストリームにおけるパイプラインは、グラフィクスデコーダが、あるディスプレイセットに属するオブジェクト定義セグメントをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行するディスプレイセットに属するオブジェクト定義セグメントをデコードすることにより得られたグラフィクスオブジェクトをオブジェクトバッファからプレーンメモリに書き込む処理とを同時に実行することでなされる。
図５３は、PGストリームのグラフィクスデコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモード方式で表示するためのデコーダモデルである。図５３（ｂ）は、LR方式のデータを表示する場合のデコーダモデルである。
本図において、グラフィクスデコーダの本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲っている。
同図（ａ）では、グラフィクスデコーダは１デコーダ構成になっており、グラフィクスプレーンも1プレーン構成になっている。しかしグラフィクスプレーンの出力が、レフトビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
同図（ｂ）では、トランスポートバッファ−グラフィクスデコーダ−グラフィクスプレーン−CLUT部が2組み存在していて、レフトビューストリーム、ライトビューストリームをそれぞれ独立に処理することができる。
オフセットシーケンスはディペンデントビュービデオストリームに含まれているので、プレーンオフセット形式では、グラフィクスデコーダは１デコーダ構成になり、この1つのグラフィクスデコーダの出力が、レフトビューとライトビューとに切り替えられる。
PGデコーダの2D/3D切り替え時の動作は以下の通りである。
１.1plane＋Offsetモードと2Dモードとの相互切り替え時は、シームレスに切り替えられる。これは、Offsetを無効化することでなされる。
２.3D-LRモードと、2Dモードとでは、PID切り替えが伴うため、一旦字幕が消える。これはストリーム切り替えと同じである。
３.3D-LRモードとLモードとでは、L（BaseView側）のみの表示に切り替える。シームレスに切り替え可能だが、表示位置が偏る可能性がある。
3D-Depthモードと、2Dモードとでは、2D表示中もバックグラウンドで、グレースケールに示される深度情報をデコードして、レフトビューのグラフィクスオブジェクト、ライトビューのグラフィクスオブジェクトを生成しておけば、グラフィクスオブジェクトの切り替えをシームレスに行うことができる。
PGデコーダでモード切り替えを実行する場合、Depthモード、1plane＋Offsetモードから2Dモードへの切り替えが容易である。しかし3D-LR方式の場合、立体視のグラフィクスオブジェクトと、2Dのグラフィクスオブジェクトとは異なるため、切り替え時に処理するPGストリームの変更が必要となり、次のPGストリームが供給されるまでグラフィクスオブジェクトが表示されない可能性が生じる。
グラフィクスオブジェクトが表示されない期間を設けたくない場合には、正面から見る2Dグラフィクスオブジェクトではなく、ベースビューのグラフィクスオブジェクトのみに切り替えることも可能である。この場合すこし左に偏った映像に見える可能性が残る。立体視PGを2DPGに切り替える場合、どちらの方法を用いるか、管理データに設定しておくことも可能である。
・テキスト字幕デコーダのデコーダモデル
テキスト字幕ストリームは、複数の字幕記述データから構成される。
テキスト字幕デコーダは、字幕記述データから、テキストコードと、制御情報とを分離する「字幕プロセッサ」と、字幕記述データから分離されたテキストコードを格納する「管理情報バッファ」と、フォントデータを用いて、管理情報バッファ内のテキストコードをビットマップに展開する「テキストレンダー」と、展開により得られたビットマップを格納する「オブジェクトバッファ」と、字幕記述データから分離された制御情報を用いて、時間軸に沿ったテキスト字幕再生の制御を実行する「描画制御部」とを含む。
テキスト字幕デコーダの前段には、フォントデータのプリロードを行う「フォントプリロードバッファ」、テキスト字幕ストリームを構成するTSパケットの入力速度を調整する「TSバッファ」、プレイアイテムの再生に先立ち、テキスト字幕ストリームをプリロードしておくための「字幕プリロードバッファ」が存在する。

グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのためのシフト部が存在する。
図５４は、テキスト字幕デコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモードにおけるテキスト字幕デコーダのデコーダモデルを示し、図５４（ｂ）は、3D-LR方式におけるテキスト字幕デコーダのデコーダモデルを示す。本図において、テキスト字幕デコーダ本体にあたる部分は黒枠で囲こみ、テキスト字幕デコーダ後段にあたる部分は一点鎖線で囲んでいる。テキスト字幕デコーダ前段にあたる部分は、破線枠で囲んでいる。
同図（ａ）では、グラフィクスプレーンの出力が、レフトビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
同図（ｂ）では、レフトビュー用のグラフィクスプレーンと、ライトビュー用のグラフィクスプレーンとが存在していて、テキスト字幕デコーダによって展開されたビットマップを、これらのそれぞれのグラフィクスプレーンに書き込む。3D-LR方式のテキスト字幕デコーダでは、カラーパレット情報が拡張されており、字幕用の文字/背景/縁取り3色に加え、Depth用に3色追加されている。そして、レンダリングエンジンが字幕を描画することができる。
テキスト字幕ストリームは、PGストリームと異なり、グラフィクスデータをビットマップとして送るのではなく、フォントデータと文字コードを送ることにより、レンダリングエンジンで字幕を生成するから、字幕の立体視は、1plane＋Offsetモードによって実現する。テキスト字幕を1plane＋Offsetモードで表示する場合、モードの切り替えは、フォントセットの切り替えか、レンダリング方式の切り替えによってなされる。L/RフォントセットやOpenGLフォントセットを定義することでモード切り替えを行う方法もある。レンダリングエンジンが3D表示を行う事も可能である。
3D-LRモードでは、ベースビューと、ディペンデントビューとで独立したフォントセットやOpenGLフォントセットを定義することで立体視再生を実現する。また、レンダリングエンジンが3Dフォントを描画することで立体視再生を実現してもよい。
3D-Depthモードの場合は、深度映像をレンダリングエンジンで生成する。
以上がテキスト字幕ストリーム及びテキスト字幕デコーダについての説明である。続いて、IGストリームの内部構成と、IGデコーダの構成とについて説明する。
・IGストリーム
レフトビューIGストリーム、ライトビューIGストリームは何れも複数のディスプレイセットを含み、各ディスプレイセットは、複数の機能セグメントを含む。ディスプレイセットには、PGストリームと同様、エポックスタートのディスプレイセット、ノーマルケースのディスプレイセット、アクジッションポイントのディスプレイセット、エポックコンティニューのディスプレイセットが存在する
これらのディスプレイセットに属する複数の機能セグメントには以下の種類がある。
(1)オブジェクト定義セグメント
このオブジェクト定義セグメントは、PGストリームのものと同じである但しIGストリームのグラフィクスオブジェクトは、ページのインエフェクト、アウトエフェクト、ボタン部材のノーマル状態、セレクテッド状態、アクティブ状態を定義するものである。オブジェクト定義セグメントは、ボタン部材の同じ状態を定義するもの同士、同じエフェクト映像を構成するもの同士、グループ化されている。同じ状態を定義するオブジェクト定義セグメントを寄せ集めたグループをグラフィクスデータ集合という。
(2)パレット定義セグメント
パレット定義セグメントは、PGストリームのものと同じである。
(3)対話制御セグメント
対話制御セグメントは、複数のページ情報を含み、複数のページ情報は、マルチページメニューの画面構成を規定する情報であり、各ページ情報は、エフェクトシーケンスと、複数のボタン情報と、パレット識別子の参照値とを含む。
ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。
エフェクトシーケンスは、グラフィクスオブジェクトを用いて、ページ情報に対応するページの表示に先立ち再生されるインエフェクト、又は、当該ページの表示後に再生されるアウトエフェクトを構成するものであり、エフェクト情報を含む。
エフェクト情報は、インエフェクト又はアウトエフェクトを再生するにあたっての個々の画面構成を規定する情報であり、グラフィクスプレーン上のウィンドゥ定義セグメントで定義されたウィンドゥ（部分領域）においてどのような画面構成を実行すべきかを規定する画面構成オブジェクトと、同領域における次の画面構成との時間間隔を示すエフェクト期間情報とを含む。
エフェクトシーケンスにおける画面構成オブジェクトは、PGストリームの画面構成セグメントと同じような制御内容を規定する。オブジェクト定義セグメントのうち、前記インエフェクトに用いられるグラフィクスオブジェクトを定義するものは、グラフィクスデータ列において、ボタン部材に用いられるグラフィクスオブジェクトを定義するオブジェクト定義セグメントより前に配置されている。
ページ情報における各ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。前記ボタン情報はセットボタンページコマンドを含み、セットボタンページコマンドは、対応するボタン部材がアクティブ状態になった際、ファーストページ以外の他のページを、カレントページとして設定する処理を再生装置に行わせるコマンドである。
IGストリームの再生時において、プレーンシフトにおけるオフセットをページ毎に変更させたい場合は、ボタン情報にオフセットを変更するナビゲーションコマンド組込んでおき、該当するボタン情報において、ナビゲーションコマンドのオートアクティベートを規定しておく。これにより、IGストリームのストリーム登録情報に規定されているオフセットの値や方向を自動的に変更できるようにする。

(4)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグメントである。対話制御セグメントからこのエンドセグメントまでが、1つのディスプレイセットを構成する機能セグメントであるとして解釈される。

レフトビューグラフィクスストリームと、ライトビューグラフィクスストリームとにおいて、同一となる対話制御セグメントの制御項目には、ボタン近接情報、セレクションタイムアウトタイムスタンプ、ユーザタイムアウトディレーション、コンポジションタイムアウト情報がある。
１.ボタン近接情報
ボタン近接情報は、あるボタンがセレクテッド状態になっていて、上下左右方向の何れかを指示するキー操作があった場合、どのボタンをセレクテッド状態にすべきかを指定する情報である。
２.セレクションタイムアウトタイムスタンプ
セレクションタイムアウトタイムスタンプは、カレントページにおけるボタン部材を自動的にアクティベートして、セットボタンページコマンドを再生装置に実行させるためのタイムアウト時間を示す。
３.ユーザタイムアウトディレーション
ユーザタイムアウトディレーションは、カレントページをファーストページに戻して、ファーストページのみが表示されている状態にするためのタイムアウト時間を示す。
４.コンポジションタイムアウト情報
コンポジションタイムアウト情報は、対話制御セグメントによる対話的な画面表示を終了させる時間を示す。IGストリームにおいてディスプレイセットの開始時点は、対話制御セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、対話制御セグメントのコンポジションタイムアウト時刻によって特定される。レフトビュー、ライトビューでは、これらのDTSと、コンポジションタイムアウト時刻とは同一時点に設定される。
・IGデコーダのデコーダモデル
IGデコーダは、IGストリームから読み出される機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するための「トランスポートバッファ」が存在する。
グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのための「シフト部」とが存在する。
図５５は、IGデコーダのデコーダモデルを示す。本図では、IGデコーダ本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲んでいる。IGデコーダ前段にあたる部分は、破線枠で囲んでいる。
図５５（ａ）は、2D形式のIGストリームを1plane＋Offsetモード方式によってLR形式で表示するためのデコーダモデルである。同図（ｂ）は、IGストリームのデコーダモデルであるが、LR方式のデータを表示する場合のデコーダモデルである。
これらのデコーダでは、メニューグラフィクスの深度情報をプログラムから制御するために、システムパラメータの値をオフセットに反映するための回路を含んでいる。
同図（ｂ）は、2デコーダモデルであり、コマンドによりoffset値の変更が可能になる。よってメニューの深度情報をコマンドで変えることができる。Offset値は左右異なる値も与えられる。一方、Depth方式の場合、Offsetは無効になる。
グラフィクスデコーダにおけるコンポジションコントローラは、対話画面に存在するボタン部材のうち、カレントボタンになるものを、セレクテッド状態に対応するグラフィクスデータ集合のグラフィクスデータを用いて表示し、それ以外のボタン部材を、ノーマル状態に対応するグラフィクスデータ集合を用いて表示することで、対話画面の初期表示を実現する。
上下左右の４方向の何れかを指定する旨のユーザ操作があった場合、カレントボタンの周辺に位置するノーマル状態のボタン部材のうち、ユーザ操作により指定された方向に存在するものの番号をボタン番号レジスタに書き込み、当該書き込みによって、新たにカレントボタンになったボタン部材をノーマル状態からセレクテッド状態に変化させる。
対話画面においてセレクテッド状態になっているボタン部材をアクティブ状態に変化させる旨のユーザ操作があった場合、当該アクティブ状態を構成するグラフィクスデータをグラフィクスデータ集合から取り出して表示に供することで対話画面の更新を実現する。
これらの対話画面の更新は、レフトビュー、ライトビューで共通に実行にする必要があるので、２デコーダモデルにおいて、コンポジションコントローラを、レフトビュー用のグラフィクスデコーダと、ライトビュー用のグラフィクスデコーダとで共通化することが望ましい。
この場合、立体視IGストリームにおけるレフトビュー・ライトビューのナビゲーションコマンドは同一化し、3D用と2D用のグラフィクスオブジェクトのボタン構成を同一にすることで、相互切り替えを実現する。
2DIGストリームと、立体視IGストリームとでは、ナビゲーションコマンドおよびボタン情報の属性・数などが同じであれば、グラフィクスオブジェクトの表示のみの切り替えが可能となる。3D-LRモードからL画像のみへの切り替えでは、再ロードなしに切り替え可能だが、表示位置が偏る可能性がある。どちらを採用するかのタイトル制作者の意図をフラグに示させておき、このフラグに基づき再生装置が切り替えを行うことが望ましい。
以下に、モード切り替え時における留意事項をまとめた。
・1plane＋Offsetモードと、2Dモードとの切り替えにおいては再ロードは発生しない。これはIGストリームのロードは必要ではなく、Offsetの無効化のみとなるからである。
・3D-LRモードと、2Dモードとの切り替えにおいて、ストリームが異なるため、再ロードが発生する。
・ 3D-Depthと2Dとの間では、プリロード時に深度情報のデコードが完了していれば再ロードは発生しない。
・AV再生開始前にメモリに読み込むというプリロードモデルが採用されていたとしても、2Dモード/3Dモードの切り替えに伴い、IGストリームの再ロードが発生すれば、シームレス再生は保証されないケースが生じる。
以上がIGストリーム及びIGデコーダについての説明である。続いて、プレーンメモリの詳細について説明する。
1plane＋Offsetモード方式におけるプレーンメモリ構成について説明する。
プレーンメモリのレイヤ合成は、プレーンメモリのレイヤモデルにおいて、階層間のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける階層間の全ての組合せに対して実行することでなされる。合成部２０８によるレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
階層間の重畳は、ある階層に位置するプレーンメモリのライン単位の画素値に透過率αを重みとして乗じるとともに、その下位階層に位置するプレーンメモリのライン単位の画素値に（１−透過率α）という重みを乗じて これら輝度の重み付けがなされた画素値同士を加算し、加算結果を、その階層におけるライン単位の画素の画素値とする処理である。この階層間の重畳を、レイヤモデルの隣接する2つの階層に位置するライン単位の画素同士で繰り返し実行することにより、上記レイヤ合成は実現される。
プレーンメモリ後段は、上述したようなCLUT部、シフト部の他、レイヤ合成を実現するため、個々の画素値に透過率を乗算するための乗算部、画素同士の加算を行うための加算部、セカンダリビデオの位置決め・スケーリング変更を行うためのScalling&Positioning部を含む
図５６は、これらのデコーダモデルの出力を合成し、3D-LR方式で出力するための回路構成を示す。プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、２組み存在していることがわかる。また、プレーンメモリ後段にあたる部位も、２組み存在していることがわかる。
レイヤモデル、プレーンメモリ後段が2組み存在することにより、3D-LR方式におけるプレーンメモリ構成は、プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのそれぞれが、レフトビュー用と、ライトビュー用とに別れていて、これらのプレーンメモリの出力をレイヤ合成を、レフトビュー、ライトビューのそれぞれについて実行するようになっている。
セカンダリビデオプレーンでは、プライマリビデオストリームと同様に、セカンダリビデオストリームを3D-LRモードや3D-Depthモードで表示することが可能である。また、PGストリームのように2D映像にオフセットを与えて、平面の映像を手前に浮き出させて表示することも可能である。
図５７は、これらのデコーダモデルの出力を合成し、1plane＋Offsetモード方式で出力するための回路構成を示している。
レフトビュー用のプライマリビデオプレーン、ライトビュー用のプライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、１組みだけが存在していることがわかる。また、プレーンメモリ後段にあたる部位は、２組み存在している。
1plane＋Offsetモード方式では、プライマリビデオプレーンは、レフトビューのものと、ライトビューのものとが準備されている。セカンダリビデオプレーン、PGプレーン、IGプレーンについては、レフトビュー、ライトビューのそれぞれに別れておらず、レフトビュー、ライトビューで共通の１枚のプレーンメモリのみが存在する。そして、これらのレフトビュー出力、ライトビュー出力のそれぞれに対して上述したようなレイヤ合成がなされるようになっている。
再生装置は、B−Dプレゼンテーションモード、1plane＋Offsetモードの双方をサポートにする必要があるので、再生装置のハードウェア構成としては、基本的に2デコーダ＋2プレーンの構成になっていて、1plane＋Offsetモード、2D再生モードに再生装置が切り替った際、１デコーダ＋１プレーンの組みのうち一方を無効化して、１デコーダ＋１プレーン構成になる。
3D再生モードから2D再生モードへの切り替えが生じ再生装置の構成が、2デコーダ＋2プレーン構成から1デコーダ＋1プレーン構成に変化した場合、多重分離の対象は、Ｌ画像を構成するTSパケットのみとなる。そうすると、3D眼鏡を通じてＬ画像、Ｒ画像を視聴していたユーザは、3D再生モードから2D再生モードに切り替った途端、Ｌ画像しか見えなくなる。
この場合、両目によるTVの視聴が、片目によるTVの視聴に切り替わることになり、目の負担が大きくなって、悪寒を覚えるユーザも出てくる。そこで本実施形態では、切り替った場合、PIDフィルタの対象を、Ｌ画像を構成するTSパケット、Ｒ画像を構成するTSパケットから、Ｌ画像を構成するTSパケットに切り替えると共に、グラフィクスデコーダにおけるメモリ管理をリセットする。そして、切り替えにおいて、上述したような悪寒を請じさせることがないよう、字幕を一旦消去することにする。
以上のように本実施形態によれば、デコーダ構成を2デコーダ構成から1デコーダ構成に切り替える際、プレーンメモリにおける字幕を一旦リセットするので、両目によるTVの視聴が、片目によるTVの視聴に切り替わることによる目の負担をやわらげることができる。
(第８実施形態)
本実施形態では、これまでの実施形態で説明した記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。
これまでの実施形態で説明した記録媒体は、多層化された光ディスクであるBD-ROMディスク、BD-ROMディスクと再生互換性があるようなBD-REディスク、BD-Rディスク、AVC-HDメディアとして作成することができる。
図５８は、多層化された光ディスクの内部構成を示す。
第１段目は、多層化された光ディスクの一例であるBD-ROMを示し、第２段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域から構成される。これらの第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域は、1つの連続した論理アドレス空間を構成する。
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで、BD-ROMのような読み込み専用ディスクの場合には、基本的に論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。ただし、記録層の境界においては、論理アドレスが連続していたとしても連続的な読み出しはできない。そのため、層境界の論理アドレスは、予め記録装置に登録されているものとする。
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROMの場合ではUDF（Universal Disc Format）によって記録される。日常使っているPC（パーソナルコンピュータ）の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。
第４段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第５段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。
図５９は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。
BDMVディレクトリはBD-ROMで扱うTSや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」，「MovieObject.bdmv」の２種類のファイルが配置されている。

「index.bdmv(ファイル名固定)」は、インデックステーブルを格納している。
「MovieObject.bdmv（ファイル名固定）」は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。
「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo["xxxxx"は可変、拡張子"bdjo"は固定])が存在する。このプログラムファイルは、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"は固定])が存在する。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi ["xxxxx"は可変、拡張子"clpi"は固定])が存在する。
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、ストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts(["xxxxx"は可変、拡張子"m2ts"は固定])という形式でストリームファイルが格納される。
上述したようなファイルは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。
「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
本願の主眼となるストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
以上が記録媒体の内部構成についての説明である。続いて、図５８及び図５９に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。
図６０は、記録方法の処理手順を示す。ステップＳ１０１は、記録装置が動画、音声、字幕、メニューといったデータ素材のインポートを行い、ステップＳ１０２では、データ素材をデジタル化して圧縮符号化し、MPEG規格に従ったエンコードを行うことで、PESを得る。ステップＳ１０３では、PESを多重化して対応するクリップ情報を生成し、ステップＳ１０４では、AVクリップと、クリップ情報とをそれぞれ別々のファイルに格納する。
ステップＳ１０５では、AVクリップの再生経路を規定するプレイリスト、プレイリストを用いた制御手順を規定するプログラム、これらについての管理情報を作成し、ステップＳ１０６では、AVクリップ、クリップ情報、プレイリスト、プログラムファイル、その他の管理情報を記録媒体に書き込む。
図６１は、AVファイル書込工程の処理手順を示す。
ステップＳ４０１において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップＳ４０２は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップＳ４０３において、空きの連続セクタ領域にディペンデントビューデータブロックを構成するソースパケット列をEXT2[i]だけ書き込み、その後、ステップＳ４０４〜ステップＳ４０８を実行する。確保し得ない場合は、ステップＳ４０９で例外処理をした後、記録方法を終了する。
ステップＳ４０４〜ステップＳ４０８は、ステップＳ４０７がNoと判定されるまで、ステップＳ４０４〜ステップＳ４０６、ステップＳ４０８の処理を繰り返すループを構成している。
ステップＳ４０５は、空きの連続セクタ領域に、ベースビューデータブロックを構成するソースパケット列をEXT1[i]だけ書き込む。ステップＳ４０６は、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。これに伴い、書き込まれたソースパケット列の先頭ソースパケット番号を指し示すエクステントスタートポイント情報を、クリップベース情報、クリップディペンデント情報内のメタデータに追記する。
ステップＳ４０７は、ループの終了条件を規定するものであり、ベースビューデータブロック、ディペンデントビューデータブロックに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップＳ４０８に移行して、ループを継続する。存在しなければ、ステップＳ４１０に移行する。
ステップＳ４０８は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップＳ４０３に移行し、存在しなければ、ステップＳ４０２まで戻る。
ステップＳ４１０では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップＳ４１１では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップＳ４１２では、ファイル2Dで固有となるベースビューデータブロックの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップＳ４１３では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。
ステップＳ４０４は、EXTSS＋EXT2Dの範囲内に、ロングジャンプの発生地点が存在するかどうかの判定である。ここでのロングジャンプの発生地点は、層境界であるものとする。EXTSS＋EXT2Dの範囲内に層境界が存在する場合、ステップＳ４２０において、ベースビューデータブロックを複製して、ベースビューデータブロックB[i]ssと、ベースビューデータブロックB[i]2Dとをロングジャンプ発生地点の直前までに書き込み、その後、ステップＳ４０６に移行する。これらが、ファイル2Dのエクステント、ファイルベースのエクステントになる。
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。
この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたTSであってもよいし、記録装置がデジタル入力したTSをパーシャル化することで得られるTSであってもよい。リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TSを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBD-RE,BD-R等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップのストリームファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
そして、装置外部から入力されるTSからビデオストリームにおける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上に得ることができる。
以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法について説明する。
プレフォーマットレコーディングによる記録方法は、オーサリング行程を含むような光ディスクの製造方法となる。
光ディスクの製造方法は、オーサリングステップ、署名ステップ、メディア鍵取得ステップ、メディア鍵暗号ステップ、物理フォーマットステップ、識別子埋こみステップ、マスタリングステップ、レプリケーションステップを含む。図６２は、記録媒体の製造方法を示す。同図（ａ）のオーサリングステップS２０１は、光ディスクのボリューム領域の全体像を表すビットストリームを作成する。
署名ステップS２０２は、光ディスクの製造にあたってAACS LAに対して署名要求を行う。具体的には、ビットストリームの一部分を抜き出し、AACS LAに送付する。ここでAACS LAは、次世代のデジタル家電機器における著作物保護技術に関するライセンスを管理する団体である。オーサリング装置を用いて光ディスクのオーサリングを行うオーサリングサイト、及び、マスタリング装置を用いてマスタリングを実行するマスタリングサイトは、AACS LAよりライセンスの提供を受ける。また、メディア鍵、無効化情報を管理する。そして、AACS LAより署名されたビットストリームの一部分を取得する。
メディア鍵取得ステップS２０３は、AACS LAからメディア鍵を取得する。メディア鍵は、常に固有のものが使用されるわけではなく、これまで製造された光ディスクの枚数が一定枚数まで達すると新しいものに更新される。メディア鍵を更新することにより、特定のメーカーや機器を排除することができ、万が一暗号鍵が破られたとしても、無効化情報を用いることでそれ自体を無効化することができる。
メディア鍵暗号化ステップS２０４は、メディア鍵取得ステップにより取得したメディア鍵を用いて、ビットストリームの暗号化に用いた鍵を暗号化する。
物理フォーマットステップS２０５は、ビットストリームに対して物理フォーマットを実行する。
識別子埋込みステップS２０６は、光ディスクに収録されるビットストリームに、一般の機器では検出することができない一意の識別子を電子透かしとして埋め込む。これにより、不正なマスタリングによる海賊版の量産を防ぐことができる。
マスタリングステップS２０７は、光ディスクの原盤を作製する。まず、ガラス基板上にフォトレジスト層を形成し、当該フォトレジスト層に対して、所望するグルーブやピットに対応するようにレーザ光を照射して露光し、現像処理を施す。このグルーブやピットは、8ー16変調されたビットストリームの各ビット値を表すものである。その後、このようなレーザカッティングによってグルーブやピットに対応した凹凸が形成されたフォトレジストを元にして、光ディスクの原盤を作製する。
レプリケーションステップS２０８は、光ディスクの原盤を用いて、その複製である光ディスクを大量生産する。
図６２（ｂ）は、オーサリングステップの処理手順を示す。
ステップ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(TM)プログラム、多重化工程で得られたAVクリップ、BD-ROMデータベースを入力とし、BD-ROMに準拠したファイルシステムフォーマットでAVファイル,非AVファイルを作成する。
次に、オーサリングステップの作業に用いられる記録装置について説明する。ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成して、マスタリングサイトに引き渡すための記録媒体に記録するというのが、本発明にかかる記録装置の使用形態である。
図６３は、記録装置の内部構成を示す。本図に示すように、記録装置は、ビデオエンコーダ５０１、素材制作部５０２、シナリオ生成部５０３、BDプログラム制作部５０４、多重化処理部５０５、フォーマット処理部５０６により構成される。
ビデオエンコーダ５０１は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG４-AVCやMPEG２などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部５０１aに書き込む。ビデオエンコーダ５０１は、ピクチャ間の相関特性を利用した画像圧縮をするために、８x８や１６x１６のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。
マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、８ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。
素材制作部５０２は、オーディオストリーム、PGストリーム、IGストリームなどの各ストリームを作成して、オーディオストリーム格納部５０２a、IGストリーム格納部５０２b、PGストリーム格納部５０２cに書き込む。
オーディオストリーム作成にあたって素材制作部５０２は、非圧縮のLinearPCM音声などをAC３などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部５０２は、字幕イメージと表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるPGストリームを作成する。素材制作部５０２は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるIGストリームを作成する。
シナリオ生成部５０３は、素材制作部５０２で作成した各ストリームの情報や、オーサリングスタッフからの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のフォーマットでディスクイメージを作成して、ディスクイメージを表すビットストリームをBD-ROMビットストリーム格納部５０７に書き込む。
また、この時ビデオエンコーダ５０１が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトはこれまでに説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。
(第９実施形態)
本実施形態では、これまでの実施形態で説明した再生装置の機能を統合した、2D/3D再生装置の内部構成について説明する。
図６４は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BD-ROMドライブ１、リードバッファ２a、リードバッファ２b,２c、ATCシーケンス復元部２c、システムターゲットデコーダ４、プレーンメモリセット５a、プレーン合成部５b、HDMI送受信部６、再生制御部７、管理情報メモリ９、レジスタセット１０、プログラム実行部１１、プログラムメモリ１２、HDMVモジュール１３、BD-Jプラットフォーム１４、ミドルウェア１５、モード管理モジュール１６、ユーザイベント処理部１７、ローカルストレージ１８、不揮発メモリ１９から構成されている。
BD-ROMドライブ１は、2D再生装置と同様に再生制御部７からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ２aかリードバッファ２bに転送される。
3D映像を再生する際には、再生制御部７からはベースビューデータブロックとディペンデントビューデータブロックとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BD-ROMドライブ１は、ベースビューデータブロックを構成するエクステントをリードバッファ２aに読み出し、ディペンデントビューデータブロックを構成するエクステントをリードバッファ２bに読み出す。3D映像を再生する際には、ベースビューデータブロックとディペンデントビューデータブロックの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。
リードバッファ２aは、BD-ROMドライブ１が読み込んだベースビューデータブロックのデータを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ２bは、BD-ROMドライブ１が読み込んだディペンデントビューデータブロックのデータを格納するデュアルポートメモリ等で構成されたバッファである。
ATCシーケンス復元部２cは、リードバッファに対するデータ入力源を、BD-ROMドライブ１又はローカルストレージ１８の何れかに切り替えるためのスイッチである。
システムターゲットデコーダ４は、リードバッファ２aに読み出されたソースパケットとリードバッファ２bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。
プレーンメモリセット５aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーンといったものがある。
プレーン合成部５bは、これまでの実施形態で説明したプレーン合成を行う。テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。
HDMI送受信部６は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）に従って、第１実施形態に述べた認証フェーズ、ネゴシエーションフェーズを実行する。ネゴシエーションフェーズでは、立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報をテレビから受け取ることができる。
再生制御部７は、再生エンジン７a、再生制御エンジン７bを含み、3Dプレイリストの再生がプログラム実行部１１などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムのベースビューデータブロックを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのディペンデントビューデータブロックを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点からベースビューデータブロックのエクステントと、ディペンデントビューデータブロックのエクステントとを交互に読み出すようにBD-ROMドライブ１に要求する。再生開始するときには、最初のエクステントをリードバッファ２aか、リードバッファ２bに読みきった後に、リードバッファ２aとリードバッファ２bからシステムターゲットデコーダ４に転送を開始する。
再生エンジン７aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。
再生制御エンジン７bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。
管理情報メモリ９は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。
再生状態／設定レジスタ(Player Status/Setting Register)セット１０は、これまでの実施形態で述べた再生状態レジスタ、再生設定レジスタの他、プログラムファイルが利用する任意の情報を格納できる汎用レジスタを含む。
プログラム実行部１１は、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プレーン４４、レンダリングメモリ４５から構成される。
プライマリビデオデコーダ３１は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン３２に書き込む。
レフトビュービデオプレーン３２は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。

ライトビュービデオプレーン３３は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
セカンダリビデオデコーダ３４は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻（PTS）のタイミングでピクチャをセカンダリビデオプレーンに書き出す。
セカンダリビデオプレーン３５は、システムターゲットデコーダ４からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
PGデコーダ３６は、ソースデパケタイザから入力される複数のTSパケットからPGストリームを抽出してデコードし、非圧縮のグラフィクスデータを表示時刻（PTS）のタイミングでPGプレーンに書き出す。
PGプレーン３７には、PGストリームをデコードすることで得られた非圧縮のグラフィクスオブジェクトが格納される。
IGデコーダ３８は、ソースパケタイザから入力される複数のTSパケットからIGストリームを抽出してデコードし、非圧縮のグラフィクスオブジェクトを表示時刻（PTS）のタイミングでIGプレーンに書き出す。
IGプレーン３９には、IGストリームをデコードすることで得られたグラフィクスデータが格納される。
プライマリオーディオデコーダ４０は、プライマリオーディオストリームをデコードする。
セカンダリオーディオデコーダ４１は、セカンダリオーディオストリームをデコードする。
ミキサー４２は、プライマリオーディオデコーダ４０のデコード結果と、セカンダリオーディオデコーダ４１のデコード結果とを合成する。
レンダリングエンジン４３は、Java2D，OPEN-GLといった基盤ソフトウェアを備え、BD-Jアプリケーションから要求に従ってJPEGデータ／PNGデータのデコードを行い、イメージやウィジェットを得て、IGプレーン及びバックグラウンドグラフィクスプレーンに書き込む。JPEGデータをデコードすることにより得られる画像データは、GUIの壁紙になるものであり、バックグラウンドグラフィクスプレーンに着込まれる。PNGデータをデコードすることにより得られる画素データは、IGプレーンに書き込まれて、アニメーションを伴うボタン表示を実現することができる。これらJPEGデータ／PNGデータをデコードすることで得られたイメージやウィジェットは、BD-Jアプリケーションが、タイトル選択や字幕選択、音声選択を受け付けるためのメニューを表示したり、ストリーム再生連動型のゲームを動作させるにあたって、GUI部品を構成するために使われる。その他、BD-JアプリケーションがWWWサイトをアクセスする際、そのWWWサイトのブラウザ画面を構成するために用いられる。
GFXプレーン４４は、JPEG，PNGなどのグラフィクスデータがデコードされた後、書き込まれるプレーンメモリである。
レンダリングメモリ４５は、レンダリングエンジンによってデコードされるべきPNGデータ、JPEGデータが読み込まれるメモリである。このイメージメモリには、BD-Jアプリケーションが、ライブ再生モードを実行する際、キャッシュ領域が確保される。ライブ再生モードとは、ネットワーク上に存在するWWWサイトのブラウザ画面と、BD-ROMによるストリーム再生とを組み合わせるものであり、キャッシュ領域は、ライブ再生モード時における現在のブラウザ画面、及び、直前のブラウザ画面をキャッシュしておくためのキャッシュメモリであり、非圧縮のPNGデータ又は非圧縮のJPEGデータであって、前記ブラウザ画面を構成するものがここに格納されることになる。
以上のように本実施形態によれば、これまでの実施形態で述べた特徴を包含した記録媒体をBD-ROMとして実現することができ、また、これまでの実施形態で述べた特徴を包含した再生装置をBD-ROM再生装置として実現することができる。
(第１０実施形態)
本実施形態では、レジスタセットの詳細について説明する。
レジスタセットは、複数のプレーヤ状態レジスタ、複数のプレーヤ設定レジスタから構成される。個々のプレーヤ状態レジスタ、プレーヤ設定レジスタは何れも語長が３２ビットのレジスタであり、３２ビット長のレジスタのそれぞれにはレジスタ番号が与えられ、このレジスタ番号を用いてアクセスすべきレジスタが特定される。
各レジスタの一語(３２ビット)を構成する各ビットデータのビット位置は、b0〜b31と呼ばれる。最上位ビットはb31、最下位ビットはb0と呼ぶ。そして、32ビットのうち、bxビット目のビット位置からbyビット目のビット位置までのビット範囲は、[bx:by]という表記で表現される。
所定のレジスタ番号のプレーヤ設定レジスタ／プレーヤ状態レジスタに格納されている32ビット長のビット列であって、任意のビット範囲[bx:by]のものの値は、プログラムが動作を行うにあたっての動作システムの環境変数(システムパラメータ又はプレーヤ変数という)として扱われる。再生制御を行うプログラムは、システムプロパティやアプリケーションプログラミングインターフェイス(API)を通じて、システムパラメータを取得することができる。また、特に禁止されていない限り、これらのプレーヤ状態レジスタ、プレーヤ設定レジスタの値をプログラムは書き換えることができる。BD-Jアプリケーションについては、システムパラメータの取得や書き換えについて正当権限が、JARアーカイブファイルにおけるパーミッション管理テーブルによって与えられていることが要件になる。
プレーヤ状態レジスタは、再生装置のMPUが算術演算やビット演算を行う際、その被演算子となる数値を格納しておくためのハードウェア資源であり、光ディスクが装填された際に初期値が設定され、またカレントプレイアイテムの変更等、再生装置の状態が変化した際に、その格納値の有効性が判定されるレジスタである。この格納値としては、カレントのタイトル番号、カレントのプレイリスト番号、カレントのプレイアイテム番号、カレントのストリーム番号、カレントのチャプター番号等がある。光ディスクの装填時に初期値が格納されるので、この格納値は一時的なものであり、光ディスクがイジェクトされたり、また再生装置の電源が断たれれば、この格納値は有効性を失う。

プレーヤ設定レジスタは、電源対策が施されている点がプレーヤ状態レジスタとは異なる。電源対策が施されているので、再生装置の電源遮断時において、その格納値が不揮発性のメモリに退避され、再生装置の電源投入時において、その格納値が復帰される。再生装置の製造主体(マニフャクチャ)が再生装置の出荷時に定めた再生装置の各種コンフィグレーションや、ユーザがセットアップ手順に従い設定した各種コンフィグレーション、そして、再生装置がTVシステムやステレオ、アンプ等のホームシアターシステムの機器と接続された際、接続相手となる機器とのネゴシエーションにより判明した相手側機器のケーパビリティがプレーヤ設定レジスタに設定される。
図６６は、レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図である。
本図の左側にはレジスタセット１０の内部構成を示している。右側には再生制御エンジン７bの内部構成を示している。
それぞれのレジスタ番号が割り当てられたプレーヤ状態レジスタ、プレーヤ設定レジスタは、どのようなものであるかを示す。
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と、管理情報メモリ９におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部８を備えている。における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有"を示し、尚且つ、プレイリストに拡張ストリーム選択テーブルが存在するかどうかの判定である。
ステップＳ５１１がYesであればステップＳ５１２において、カレント出力モードを変化させない。ステップＳ５１１がNo、ステップＳ５１３がYesであってもカレント出力モードを変化させない(ステップＳ５１２)。ステップＳ５１１がNo、ステップＳ５１３がNoであればカレント出力モードを2D出力モードに変化させる(ステップＳ５１４)。
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、"ストリーム選択プロシージャ"と呼ばれる。

以下、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインについて説明する。3D再生モードの実現のために用いられているレジスタは、２１番号、２２番、２３番、２４番のレジスタであり、これらのレジスタにおけるビットアサインを示したのが図７０である。図７０は、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。
同図（ａ）は、PSR21のビットアサインを示す。本図において、最下位ビットb0が、出力モードプリレファレンスであり、0bに設定されることで、2D出力モードである旨を示し、1bに設定されることで、立体視出力モードである旨を示す。ナビゲーションコマンドやBD-JアプリケーションはこのPSR21の値を書き換えることはできない。
同図（ｂ）は、PSR22のビットアサインを示す。
PSR22におけるb0は、カレントの出力モードを表す。出力モードが変化すれば、再生装置におけるビデオ出力は、対応して変化しなければならない。出力モードの値は、選択モデルによって制御されねばならない。
同図（ｃ）は、PSR23のビットアサインを示す。本図に示すようにPSR23におけるb0は、接続されたTVシステムにおける立体視表示ケーパビリティを示す。具体的には、"０"に設定されることで、接続されたTVシステムが、立体視再生インケーパブルである旨を示し、"１"に設定されることで、立体視再生ケーパブルであるかを示す。
表示装置とネゴシエーションを行う何等かのインターフェイスが再生装置においてサポートされている場合、再生が開始する前に、これらの値は自動的に設定される。これらの値が自動的に設定されない場合、ユーザによって設定される。
同図（ｄ）は、PSR24のビットアサインを示す。本図に示すようにPSR24におけるb0は、再生装置おける立体視表示ケーパビリティを示す。立体視表示ケーパビリティは、０に設定されることで、立体視再生タイプがインケーパブルである旨を示し、１に設定されることで、ケーパブルであるかを示す。
以上のように本実施形態によれば、再生装置の状態変化やユーザからのストリーム切り替え要求があったとしても、出力モードの有効性を保つことができる。
(第１１実施形態)
本実施形態は、メモリやミドルウェアに組み込まれた3Dメタデータに基づきプレーンシフトを実行する改良に関する。
図７１は、プレーン合成部の内部構成を示す。メモリ内に組込まれた3Dメタデータに基づき、プレーンに格納されている非圧縮ピクチャデータ、グラフィクスデータをクロッピングするクロッピング部６１a,b,cと、プログラムAPIに基づきプレーンに格納されている非圧縮グラフィクスデータをクロッピングするクロッピング部６１dと、出力内容をレフトビュービデオプレーンと、ライトビュービデオプレーンとで切り替えるスイッチ６２と、プレーン同士の合成を行う加算部６３、６４、６５、６６とから構成される。
プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ４よりPTSのタイミングで映像データが書き出される。プレーン合成部５bは、レフトビュービデオプレーンとライトビュービデオプレーンのうち、PTSのタイミングで映像データが書き出されたほうのプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送される。
以上のように本実施形態によれば、メモリやミドルウェアに組み込まれたオフセットに基づきプレーンシフトを実行することができる。
（第１２実施形態)
本実施の形態では、B−Dプレゼンテーションモードとして3D-Depth方式が許容されている場合において、2D用,3D用のコンテンツが混在するデータ、また再生装置をどのように構成するかを説明する。
前提として3Dディスク（2D互換）は、2D再生装置で再生可能であるものとする。
3Dディスク（2D互換）において、2D再生に関連するナビゲーションデータ構造・ストリームおよびファイル配置条件は、2Dディスクでの規定を満たす。よって、2D再生装置で2D部分のみを再生可能とする。
そして3D再生装置でも、2D再生に切り替えた場合は、2D再生用のコンテンツが表示される。
3Dディスク（3D専用）は、ファイル配置条件は3Dに最適化されており、2D再生装置では再生できない。これは、3D-LRストリームを1TSに多重化して、2D再生装置での対応上限以上に、3D用にTSレートを上げるためである。2D再生装置で再生した場合、プログラムで警告画面に遷移し、3D専用の再生には遷移することはない。しかし、この場合でも、ファーストプレイタイトルや特定タイトルのみ、2D再生装置に対応する必要がある。
2D表示に切り替えた場合、ベースビュー映像のみ表示することとし、2D用のストリームはない。
図７２は、2D用、3D用のコンテンツが混在するデータ、また再生装置におけるその再生方法を示す。
図７２（ａ）は、各種ディスクに記録されたコンテンツの構成と、各種再生装置で再生される再生方法との関係を、表形式で示している。同図（ａ）の横の欄は、2Dディスク、2D互換の3Dディスク、3D専用の3Dディスクを表す。横の欄は、2D再生装置、3D再生装置を示す。３D対応再生装置とは、2D再生3D再生のどちらも行える再生装置である。2Dコンテンツしか記録されていないディスクは、３D対応の再生装置で再生しても、2Dコンテンツしか表示されない。
同図の表に示される対応関係によると、ディスクに３D専用のコンテンツしか含まれない場合、３Dコンテンツに対応していない2D再生装置では再生できない。このようなディスクがあったとしても、ディスクの形状は2D,3Dのものが区別できないため、ユーザーが誤って３Dディスクを2D再生装置で再生を試み、何も映像・音声が再生されず、何が起こっているのかさえ分からない場合が起こりえる。
そのようなケースを防ぐため、３Dコンテンツが記録されたディスクであったとしても、2D再生装置でも再生できるように、2Dコンテンツ、3Dコンテンツを含む、ハイブリッドディスクを考える。ハイブリッドディスクは、3D再生装置では３Dコンテンツが再生され、３Dに対応しない2D再生装置では、2Dコンテンツが再生される。
ただし、2D用のAVストリームと、３D用のAVストリームをそれぞれディスクに記録すると、重複する内容のデータが冗長に記録されることになり、データ容量が余分に必要になる。そこで、2D用AVストリーム3D用AVストリームのうち共通部分を共有化し、データサイズを必要十分に抑えつつ、2D再生装置でも3D再生装置でも適切なデータが再生される方法が必要となる。
以降は、これらのデータを管理する管理情報について説明する
図７２（ｂ）は、インデックステーブルの内部構成を示す。本図において、ファーストプレイタイトルに対応するエントリーには、2D再生装置／3D再生装置で共通に動作するプログラムを記述しておく。こうすることで、2D再生装置に装填された場合の動作を保障することができる。
図７３は、2D/３Dの切り替えを示す状態遷移図である。
同図左側は、ビデオにおける状態遷移を示す。本図は、状態L、状態L+R、状態L+Depthといった3つの状態から構成される。
丸記号１の遷移は、出力段のスイッチ切り替えが発生することによる状態遷移を示す。丸記号２の遷移では、出力段のスイッチ切り替えが発生することによる状態遷移を示す。
丸記号３の遷移は、デコードするストリームが切り替わるため、デコーダ切り替えが発生することによる状態遷移を示す。シームレス切り替えは保証されない。
同図（b）は、Graphics: 字幕グラフィクス、レンダリング字幕グラフィクス、メニューグラフィクスにおける状態遷移を示す。
丸記号４の遷移は、プレーンのオフセット切り替えによる状態遷移を示す。
丸記号５の遷移は、出力段のスイッチ切り替えによる状態遷移を示す。
丸記号６ の遷移は、デコードするストリームの切り替えによる状態遷移を示す。シームレス接続は保証されない。プリロードストリームの切り替えはAVが途切れる。
丸記号７ の遷移では、デコードするストリームの切り替えによる状態遷移を示す。シームレス接続は保証されない。
丸記号８の遷移は、LからLRの切り替え、LRからLへの切り替えによる状態遷移を示す。デコードするストリームの切り替えは伴わない。
(第１３実施形態)
本実施形態は、3D再生に必要なシステムパラメータについて述べる。
図７４から図７９は、3D再生に必要なシステムパラメータに関する説明である。
図７４は、ディペンデントビューのケーパビリティ、3D-Depthビューのケーパビリティを示す。
図７５は、３D再生能力をさらに細かく識別するためのシステムパラメータの拡張を示す。具体的にいうと、本図のビットアサインは、[b22:b16]が1plane＋Offset方式、[b14:b8]が3D-Depth方式、[b6:b0]が3D-LR方式のそれぞれに割り当てられており、これらのビット列における各ビットが、背景画像プレーン、プライマリビデオプレーン、セカンダリビデオプレーン、テキスト字幕のプレーン、PGプレーン、IGプレーン、Javaグラフィクスのプレーンのそれぞれについて、ケーパビリティの有無を示すことができる。
図７６は、再生装置が３D用に拡張されたデータ構造に対応しているか否かを識別するデータベース識別情報を示す。このデータベース情報は、再生装置が対応することができるアプリケーションフォーマットのバージョン数を含み、プレーヤープロファイル情報となる。プログラムにより再生するストリームを選ぶ際、３D用に拡張された管理データを扱えるか否かを判定するために利用することも可能である。
図７７は、ユーザーの表示形式の好みを設定するシステムパラメータであり、１つのディスクに、LR方式やDepth方式などのデータが含まれる際、ディスク上のプログラムは、このシステムパラメータの値を参考にして、ユーザーにあったデータを含むPlayListを選択して再生を開始することが可能である。本図において、3D Presentation Preferneceは、00b に設定されることで、2D presentation modeを意味する。01b に設定されることで、3D-LR presentation modeを意味し、10bに設定されることで、3D-Depth presentation modeを意味する。
図７８は、現在再生中の表示形式を示すシステムパラメータであり、このシステムパラメータを参照することにより、プログラムはメニューグラフィクスなどを2Dで表示すればよいのか、LR方式で表示すればよいのか、などを判断することが可能になる。
本図において、3D Presentation Typeは、00b に設定されることで、2D presentation modeを意味する。01b に設定されることで、3D-LR presentation modeを意味し、10bに設定されることで、3D-Depth presentation modeを意味する。
またb31からb16までの各ビットは、背景画像のプレーンメモリ、プライマリビデオのプレーンメモリ、セカンダリビデオのプレーンメモリ、テキスト字幕のプレーンメモリ、Java Graphicsのプレーンメモリのそれぞれに割り当てられており、３D方式の可否を各方式毎に示すこともできる。
オフセット値の補正に関して説明する。ディスプレイの大きさにより適切なオフセット値は異なる場合がある。そのため、再生装置はディスプレイに応じて適切なオフセット値を設定しておくことにより、字幕グラフィクスやメニューグラフィクスをオフセット方式で表示する際、このシステムパラメータの値を加減して、より適切な表示にすることが可能となる。図７９は、3Dオフセットの補正値を格納しておくためのビットアサインを示す。[b15]は、Offset Typeを示し、[b14]はDirectionを示す。[b13,b8]は、3D offset for Right,3D offset for Leftを示す。Offset Typeは、値0に設定されることで即値指定を示し、グラフィクスストリームで規定されているオフセット値は無効であることを示す。値1に設定されることで、グラフィクスストリームに対して設定されているオフセット値への補正値である旨を示す。Directionは、値0でマイナス、値1でプラス方向であることを示す。3D offset for Rightは、ライトビュー時のオフセット、3D offset for Leftは、レフトビュー時のオフセットを示す。
このシステムパラメータの値は、ディスク上のプログラムから与えることも可能であり、その場合は、シーンに応じてグラフィクスの深度を変化させるためなどに利用することが可能である。
（2D/3D切り替えユーザーオペレーション）
2D/3D切り替えユーザーオペレーションAPIについて説明する。図８０は、2Dや３Dの表示形式を切り替えるユーザーオペレーションAPIを示す。同図（ａ）のAPIはいずれの方式に切り替えるか識別する引数を持っている。このAPIは、ユーザイベント処理部と、ミドルウェアとの間のAPIである。このAPIにおける書式は、Change3DPresentationType ( 3D Presentation Type )である。引数3D Presentation Typeとしては、00: 2D、01: 3D-LR、10: 3D-Depthの何れかを指定することができる。
Change3DPresentationTypeAPIの利用を許可するか否かは、ユーザオペレーションマスクテーブルに組み込むことができる。図８０（ｂ）は、ユーザオペレーションマスクテーブル(UO＿mask＿table)に、Change3DPresentationType を記述する場合のソースコードの記述例を示す。
(3Dオフセットの変更)
3Dオフセットの変更コマンドについて説明する。
図８１は、Change 3D Offsetモードコマンドのオペコード、オペランドを示す。同図上段は、これらオペランド、オペコードのビットアサインを示す。当該コマンドには、2つのオペランドがあり、これらのオペランドには、ライトビューのためのオフセット、レフトビューのためのオフセットを指定することができる。
(2D/3D切り替えコマンド)
同図下段は、2D/3D切り替えコマンドを示す。このコマンドのオペランドには、2D、1plane＋Offset、3D-LR、3D-Depthの何れかを指定することができる。
（3Dにおける再生モードの切替え）
3Dにおける再生モードの切り替えを行うためのコマンドについて説明する。このコマンドにより上記システムパラメータの値を変更し、表示形式を切り替えることが可能である。
図８２は、Change3DPresentationTypeコマンドを示す。同図上段は、ビットアサインを示す。このコマンドは、b63〜b32における3D Display Typeの再生モードに、再生モードを変更させる旨を示す
図８２の下段は、Graphics Offset値設定コマンドのフォーマットを示す。このコマンドは、何れかのPSRに3D再生タイプを設定するというものであり(Set 3D Presentation Type to PSRxx)、オペランドには、切り替え後のモードとして、2D, 1plane＋Offsetモード, 3D-LR, 3D-Depthの何れかを指定することができる。
(第１４実施形態)
本実施形態では、2D用AVストリーム3D用AVストリームのうち共通部分を共有化し、データサイズを必要十分に抑える方法について説明する。
図８３は、3モードのためのTSをどのようにファイルに格納するかを示す。LR方式に必要なデータブロックと、Depth方式に必要なデータブロックとを効率よくディスクから読み取るために、レフトビュー用のデータブロック(L)と、ライトビュー用のデータブロック(R)と、Depth用のデータブロック(D)とを交互にディスク上に記録し、それぞれごとにファイルシステムから参照することにより、インタリーブ配置されたAVクリップの3つのストリームファイルを記録媒体上で定義する。
2D再生用のプレイリスト(2DPlayList)はレフトビュー用のデータブロック(L)が含まれるファイルを参照し、LR方式用のプレイリスト(3D-LRPlayList)はレフトビュー用のデータブロック(L)が含まれるAVクリップと、ライトビュー用のデータブロック(R)が含まれるAVクリップとを参照する。
ディスク上には、ライトビュー用のデータブロック(R)、レフトビュー用のデータブロック(L)、Depthのデータブロック(D)をインターリーブで記録する場合の記録方式について説明する。
これらのデータブロックがインターリーブ配置されることで、立体視インターリーブドストリームファイルを構成している。そしてこの立体視インターリーブドストリームファイルは、3つのファイルからのクロスレファレンスの対象となる。1つ目のファイルは、レフトビュー用のデータブロック(L)のみを収録内容とするクリップ1(2D/L)のストリームファイルである。2つ目は、ライトビュー用のデータブロック(R)のみを収録内容とするクリップ2(R)のストリームファイルである。３つ目は、Depth用のデータブロック(D)のみを収録内容とするクリップ3(D)のストリームファイルである。こうしたクロスレファレンスを実現すれば、再生装置が3つの再生モードのそれぞれに設定された際、自身の再生モードに応じたストリームファイルのみを読み出せばよい。
図８３（ａ）の右側の最上段は、Ｒ、Ｌ、Ｄ、Ｒ、Ｌ、Ｄという並びで、レフトビュー用のデータブロック(L)、ライトビュー用のデータブロック(R)、Depth用のデータブロック(D)のデータブロックがインターリーブ配置された立体視インターリーブドストリームファイルが存在する。
この下に、クリップ1(2D/L),クリップ2(R),クリップ3(D)を格納した3つのストリームファイルを示す。クロスレファレンスによって、クリップ1(2D/L)はレフトビュー用のデータブロック(L)のみ、クリップ2(R)はライトビュー用のデータブロック(R)のみ、クリップ3(D)はDepth用のデータブロック(D)のみを格納していることがわかる。 左側は、2D、3D-LRモード、3D-Depthモードという3つのモードを示す。その間の線は、各モードにおいて、どのAVクリップを使用するという使用関係を示す。
この使用関係によると、AVクリップ1は、2D、3D-LRモード、3D-Depthモードの何れにおいても参照可能であり、AVクリップ2は、3D-LRモードのみ参照可能、AVクリップ3は、3D-Depthモードにおいてのみ参照可能であることがわかる。
クロスレファレンスの別の方法としては、3D-LRモードで必要なレフトビュー用のデータブロック(L)、ライトビュー用のデータブロック(R)を1つのAVクリップのストリームファイルにパッケージし、3D-Depthモードで必要なレフトビュー用のデータブロック(L)、Depth用のデータブロック(D)を1つのAVクリップのストリームファイルにパッケージすることが考えられる。
図８３（ｂ）の右側は、クリップ1(2D/L),クリップ2(LR),クリップ3(LD)を格納した3つのストリームファイルを示す。クロスレファレンスによって、クリップ1(2D/L)はレフトビュー用のデータブロック(L)のみ、クリップ2(LR)は、レフトビュー用のデータブロック(L)、ライトビュー用のデータブロック(R)の組み、クリップ3(LD)は、レフトビュー用のデータブロック(L)、Depth用のデータブロック(D)の組みを格納していることがわかる。
図８３（ｂ）の左側は、2D、3D-LR方式、3D-Depth方式という3つのモードを示す。その間の線は、各モードにおいて、どのストリームファイルのAVクリップを使用するという使用関係を示す。
この使用関係によると、AVクリップ1は、2Dモードにおいてのみのみ参照可能であり、AVクリップ2は、3D-LRモードのみ参照可能、AVクリップ3は、3D-Depthモードにおいてのみ参照可能であることがわかる。
レフトビュー用のデータブロック(L)、ライトビュー用のデータブロック(R)、Depth用のデータブロック(D)を1TSに多重化して、3つの再生モードに対応したプレイリストから参照するというクロスレファレンスの方法も考えられる。
図８３（ｃ）の右側に、レフトビュー用のデータブロック(L)、ライトビュー用のデータブロック(R)、Depth用のデータブロック(D)が多重化されたTSを示す。左側に、2Dプレイリスト、3D(LR)プレイリスト、3D(Depth)プレイリストという3つのプレイリストを示す。その間の線は、各モードにおいて、どのAVクリップを使用するという使用関係を示す。
いずれの方法でデータを記録した場合も、ストリーム識別子を、予め割り振っておくことにより、それぞれのデータを取り出す効率を簡単化することが可能である。
図８４は、TSレベルでの多重化を表形式で示す。横の欄は、2D/L用のAVクリップ(Clip1(2D/L))、R用のAVクリップ(Clip2(R))、Depth用のAVクリップ(Clip3(D))、1Clipのそれぞれを示す。縦の欄は、プライマリビデオストリーム、プライマリオーディオストリーム、PG、IG、セカンダリビデオストリーム、セカンダリオーディオストリームのそれぞれを示す。本図において、クリップ1,2,3はインターリーブ配置される。これらのうち2D再生装置は、AVクリップ1のみを再生し、3D-LR再生装置は、AVクリップ1,2を再生する。3D-Depth再生装置は、AVクリップ1,3を再生する。
（第１５実施形態)
第１実施形態で説明した、3D-LRモード、3D-Depthモード、1plane＋Offsetモードの何れかに設定された場合、再生装置におけるストリーム番号によって、どのパケット識別子のESが再生に供されるかについて説明する。
前提として、2Dグラフィクスストリーム、LRのグラフィクスストリーム、Depth用のグラフィクスストリームのパケット識別子は+20/40/60の範囲に分けて区分するものとする。ただし、いずれのPID値であってもストリーム選択テーブルからPIDを直接指定可能とする。
PGストリームを一例にとると、2DPGストリームと、立体視PGストリームとの対応を取るため、多重化されたストリームのPIDの関連づけは、2DPGストリームのパケット識別子に0x20/0x40/0x60を加算することで、立体視PGストリームのパケット識別子を導くなどのルール付けを行う。
図８５は、TSパケットのPID割り当てを示す。AVクリップには、これらのパケット識別子が割り当てられたTSパケットが存在する。

図８６は、プライマリビデオストリーム、プライマリオーディオストリームを示す。
同図（ａ）の破線枠は、各出力モードにおいて、どのパケット識別子のTSパケットが、多重分離の対象になるかを示す。2Dモードでは、Base Viewを構成するTSパケットが多重分離の対象になり、3D-LRモードでは、Base View + Dependent Viewを構成するTSパケットが多重分離の対象になり、3D-Depthモードでは、Base View + 深度情報を構成するTSパケットが多重分離の対象になっていることがわかる。 具体的にいうと、再生装置が2Dモードである場合、パケット識別子=0x1101のTSパケットが多重分離の対象になる。
3D-LRモードである場合、パケット識別子=0x1101のTSパケットと、パケット識別子=0x1012のTSパケットとが多重分離の対象になる。
3D-Depthモードである場合、パケット識別子=0x1101のTSパケットと、深度情報を構成するパケット識別子=0x1013のTSパケットとが多重分離の対象になる。
同図（ｂ）の表は、セカンダリビデオストリームとの組合せの可否を示す。本表によると、ベースビュービデオストリームがMPEG4-AVC Base Viewであり、ディペンデントビュービデオストリームが、MPEG4-AVC Dependent Viewである場合、セカンダリビデオストリームとの共存が不可になる。ベースビュービデオストリームがMPEG4-AVCであり、ディペンデントビュービデオストリームが、MPEG4-AVCである場合も、セカンダリビデオストリームとの共存が不可になる。VC-1も同様である。
ベースビュービデオストリーム、ディペンデントビュービデオストリームの符号化方式がMPEG2 Videoである場合、セカンダリビデオストリームとの共存は不可になる。
図８６（ｃ）は、ストリーム番号=１、２、３が割り当てられるプライマリオーディオストリームの内部構成を示す。基本的は、2Dモード、3Dモードを通じてオーディオストリームは共通となる。 破線枠は、3つのモードのそれぞれにおいて、どのTSパケットが多重分離の対象になるかを示す。本図において、パケット識別子=0x1101のオーディオストリームは、チャネル拡張されたストリームであるものとする。
2D/3D再生時において、オーディオストリームのストリーム番号が値＝１に設定されれば、パケット識別子=0x1100のTSパケットが多重分離の対象になる。
2D/3D再生時において、オーディオストリームのストリーム番号が値＝２に設定されれば、パケット識別子=0x1101のTSパケットが多重分離の対象になる。
2D再生時において、オーディオストリームのストリーム番号が値＝３に設定されれば、パケット識別子=0x1102のTSパケットが多重分離の対象になる。
図８７は、PGストリーム、IGストリーム、テキスト字幕ストリームを構成するTSパケットを示す。
図８７（ａ）は、ストリーム番号=１、ストリーム番号=２のPGストリームを示す。2D字幕と3D字幕は1対1に対応する。
図中の破線枠は、2D再生モード、3D-3D-LRモード、3D-3D-Depthモードという3つのモードのそれぞれにおいて、どのTSパケットが多重分離の対象になるかを示す。
3D-Depthモードにおいて、PGストリームのストリーム番号が値＝１に設定されれば、パケット識別子=0x1260のTSパケットによって構成されるPGストリームが再生されることになる。
2Dモード,1plane＋Offsetモード,3D-LRモードにおいて、PGストリームのストリーム番号が値＝１に設定されれは、パケット識別子=0x1200のTSパケットが多重分離の対象になる。
3D-Depthモードにおいて、PGストリームのストリーム番号が値＝２に設定されれば、パケット識別子=0x1261のTSパケットによって構成されるPGストリームが多重分離の対象になる。
2D,1plane＋Offsetモードにおいて、PGストリームのストリーム番号が値＝２に設定されれば、パケット識別子=0x1201のTSパケットによって構成されるPGストリームが多重分離の対象になる。
3D-LRモードにおいて、PGストリームのストリーム番号が値＝２に設定されれば、パケット識別子=0x1221,0x1241のTSパケットによって構成されるPGストリームが多重分離の対象になる。
図８７（ｂ）は、テキスト字幕ストリームを示す。
2Dモードにおいて、テキスト字幕ストリームのストリーム番号が値＝１に設定された場合、0x1800のTSパケットが多重分離の対象になる。2Dモードにおいて、テキスト字幕ストリームのストリーム番号が値＝２に設定された場合も、0x1800のTSパケットが多重分離の対象になる。
1plane＋Offset(3D-LR)モード、3D-Depthモードにおいて、テキスト字幕ストリームのストリーム番号が値＝１に設定された場合、0x1801のTSパケットが多重分離の対象になる。テキスト字幕ストリームのストリーム番号が値＝２に設定された場合も、0x1801のTSパケットが多重分離の対象になる。
図８７（ｃ）は、IGストリームを示す。
3D-DepthモードにおいてIGストリームのストリーム番号がストリーム番号=１に設定された場合、0x1460のTSパケットが多重分離の対象になる。IGストリームのストリーム番号がストリーム番号=２に設定された場合、0x1461のTSパケットが多重分離の対象になる。
2D,1plane＋OffsetモードにおいてIGストリームのストリーム番号がストリーム番号=１に設定された場合、0x1400のTSパケットが多重分離の対象になる。IGストリームのストリーム番号がストリーム番号=２に設定された場合、0x1401のTSパケットが多重分離の対象になる。
3D-LR(2Dec)モードにおいてIGストリームのストリーム番号がストリーム番号=１に設定された場合、0x1400のTSパケットが多重分離の対象になる。IGストリームのストリーム番号がストリーム番号=２に設定された場合、0x1421のTSパケット,0x1441のTSパケットが多重分離の対象になる。
図８８は、セカンダリビデオストリーム、セカンダリオーディオストリームを構成するTSパケットを示す。
図８８（ａ）は、セカンダリビデオストリームを示す。
3D-LRモードで、ストリーム番号が値＝１に設定された場合、ライトビュー用の0x1B20のTSパケット、レフトビュー用の0x1B00のTSパケットが多重分離の対象になる。
2Dモードで、ストリーム番号が値＝１に設定された場合、レフトビュー用の0x1B00のTSパケットが多重分離の対象になる。
1plane＋Offsetモードで、ストリーム番号が値＝１に設定された場合、レフトビュー用の0x1B00、Offset情報が多重分離の対象になる。
3D-Depthモードでストリーム番号が値＝１に設定された場合、レフトビュー用の0x1B00、Depth情報の0x1B40のTSパケットが多重分離の対象になる。
ストリーム番号が値＝２に設定された場合、モードの如何を問わず、レフトビュー用の0x1B00が多重分離の対象になる。
プライマリビデオストリームが3D表示形式の時、セカンダリビデオストリームは再生装置のデコード性能とプライマリビデオストリームの表示形式に合わせて、2D再生モード、1plane＋Offsetモード、3D-LRモード、3D-Depthモードを選択することができる。
プライマリオーディオストリームと、ミキシングして出力するケースについて説明する。
セカンダリオーディオストリームもプライマリオーディオストリーム同様に、2D/3Dで同じものを使うことも可能であるし、分けることも可能である。分ける場合は、拡張ストリームを設定する、あるいは、ストリームを分ければよい。
図８８（ｂ）は、セカンダリオーディオストリームを示す。
2D再生モードにおいてストリーム番号=１に設定された場合、0x1100のTSパケットが多重分離の対象になる。3D再生モードにおいても、0x1100のTSパケットが多重分離の対象になる。
2D再生モード、3D再生モードにおいてストリーム番号=２に設定された場合、0x1101のTSパケットが多重分離の対象になる。
2D再生モードにおいてストリーム番号=３に設定された場合、0x1102のTSパケットが多重分離の対象になる。3D再生モードにおいてストリーム番号=３に設定された場合、0x1103のTSパケットが多重分離の対象になる。
以上が、個別のストリームに関する2D/3D表示方式に応じた管理方法の説明である。
(第１６実施形態)
本実施形態では、接続状態情報による接続状態についての改良に関する。
接続状態情報は、対応するプレイアイテムがカレントプレイアイテムのプレイアイテム情報になった際、その直前のプレイアイテムと、カレントプレイアイテムとの接続が、どのような接続タイプであるかを示す。ここでプレイアイテムは、In＿Time、Out＿Timeが設定されているSTCシーケンスと、そのSTCシーケンスの母体となるATCシーケンスによって構成される。ATCシーケンスの接続が連続しているか不連続であるのか、STCシーケンスの接続が連続しているのか不連続であるかによって、このプレイアイテムと、直前のプレイアイテムとの接続態様は、以下の3つの態様に分類される。
1つ目は、ATCシーケンス及びSTCシーケンスが連続しておらず、シームレス再生を保障しえない接続形態であり、Connection＿Condition＝１と呼ばれる。
2つ目は、ATCシーケンスが連続しておらず、STCシーケンスにクリーンブレークが存在する接続形態であり、Connection＿Condition＝５と呼ばれる。クリーンブレークを伴う接続形態では、連続再生される2つのビデオストリームのうち、接続点直後に位置するビデオストリームにおける最初のビデオプレゼンテーションユニットの開始時刻と、接続点直前に位置するビデオストリームにおける最後のビデオプレゼンテーションユニットの終了時刻とは、システムタイムクロック時間軸において連続している。これによりシームレス接続が可能になる。
その一方、ATCシーケンスの接続点を経由して連続再生される2つのオーディオストリームのうち、接続点直後に位置するオーディオストリームの最初のオーディオプレゼンテーションユニットと、接続点直前に位置するオーディオストリームにおける最後のオーディオプレゼンテーションユニットとの間とではオーバラップが存在する。このオーバーラップについては、オーディオ出力のミュートがなされる。
3つ目は、ATCシーケンス及びSTCシーケンスが連続している接続形態であり、Connection＿Condition＝６と呼ばれる。この接続形態において、前記接続を経由した2つのビデオストリームの接続点は、GOPのバウンダリと一致する。
Connection＿Condition＝５におけるシームレス接続は、以下の過程を経ることでなされる。
カレントのATCシーケンスと、その直前のATCシーケンスとのATCの差分値(ATC＿delta)は、クリップ情報に格納されているので、直前のプレイアイテムを構成するATC＿Sequenceを処理するためのクロックカウンタの計時値(ATC1)に、ATC＿deltaを加算することにより、カレントプレイアイテムを構成するATC＿Sequenceを処理するためのクロックカウンタの計時値(ATC2)を得る。
また上述した、プレイアイテムが切り替わる場合、STC＿deltaと呼ばれるオフセット値を求める。
こうして得られたSTC＿deltaを、直前のプレイアイテムを構成するSTCシーケンスを処理するために用いられていたクロックカウンタの計時値(STC1)に加算することにより、新しいカレントプレイアイテムを構成するSTCシーケンスを処理するためのクロックカウンタの計時値(STC2)を算出することができる。
先行STCシーケンスにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STCシーケンスにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、CC＝5では、PTS1(1stEND)＋Tppの時刻と、PTS2(2ndSTART)の時刻とを一致させる必要があるから、STC＿deltaは、

STC＿delta＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)

との計算式から算出される。

基本ストリーム選択テーブル、拡張ストリーム選択テーブルについて検討すると、上述したようなシームレス接続を実現する場合、前後のプレイアイテム情報間で同じであることが必要になる。しかし、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるファイルの指定方法は異なってもよい。
２つストリームファイルの場合と、１つのClipに多重化された場合のESを、シームレスに接続するためには、ストリームの属性が同じであることなどの条件の他、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおいて許可されているESが同じであれば足りる。
つまり、2TSインタリーブのプレイアイテム情報と、1TS多重化のプレイアイテム情報をシームレスに接続するには、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおいて許可されているESが同じであれば足りる。

上記接続は、以下のようなケースで発生する。
a.マルチアングル区間におけるプレイアイテム情報接続
b.ディスクコンテンツとダウンロードコンテンツプレイアイテム情報接続
c.動画と静止画とのプレイアイテム情報接続
図８９は、2つのプレイアイテムをシームレスに接続する形態を示す。同図（ａ）は、２つのClipファイルの場合と、１つのClipに多重化された場合のストリームを、シームレスに接続する場合の構成を示す。
図８９（ｂ）は、サブプレイアイテムにおけるIn＿Time、Out＿Timeの設定を示す。SubPathタイプ=8,9,10に含まれるサブプレイアイテムは、対応するプレイアイテム情報と開始時刻および終了時刻が同じになる。
(第１７実施形態)
本実施形態では、多層化された光ディスクの各記録層には、3D／2D共用のデータブロックB[i]ssと、2D専用のデータブロックB[i]2Dとを設ける場合に、これらを経由して再生する再生パスを設けることを提案する。
先の実施形態によるストリームファイルの書き込みにおいて、層境界の直前には、3D専用のデータブロックB[i]ss、2D専用のデータブロックB[i]2Dを書き込むので、層境界で2D再生装置と3D再生装置が参照するファイルを切り替えるための3D迂回路として、新たなサブパスを定義する。
図９０は、層境界で参照ファイルを切り替えるためのSubpathタイプを示す。同図（ａ）において、サブパス情報タイプ=8である場合、ディペンデントビュー for LRであることを示し、サブパス情報タイプ=9である場合、ディペンデントビュー for Depthであることを示す。SubPathタイプ=10は、層境界で2D再生装置と3D再生装置が参照するファイルを切り替えるための3D迂回路であることを示す。1つのPlayListで2D/3Dを切り替える必要がなければ、PlayListを分けてもよい。
3D専用ディスク（2D再生装置用アロケーションなし）では、サブパスタイプ=10の迂回ではなく、プレイアイテム情報が参照するClipを再生する。
図９０（ｂ）は、サブパスタイプ＝８、＝９のサブパスを構成するAVクリップを示し、図９０（ｃ）は、サブパスタイプ"＝１０のサブパスを構成するAVクリップを示す。これまでの実施形態で述べたように、層境界のようにロングジャンプが発生する場所では2D再生のためのAVクリップと、3D再生のためのAVクリップとを分離にする必要があるので、サブパスタイプ"＝１０のサブプレイアイテムについては、AVクリップ2、AVクリップ3によって構成している。
(第１８実施形態)
これまでの実施形態における拡張ストリーム選択テーブルは、3D-LR方式、1plane＋Offsetモードに対応するものだったが、本実施形態は、3D-Depth方式にも対応できるような拡張ストリーム選択テーブルの記述を実現する。
プライマリビデオストリームの再生を許可するストリーム登録列と、プライマリオーディオストリームの再生を許可するストリーム登録列との記述の仕方を説明する。
図９１は、ソースコードを用いたプライマリビデオストリームの再生を許可するストリーム登録列と、プライマリオーディオストリームの再生を許可するストリーム登録列との記述の仕方の一例である。
1つ目のfor文は、プライマリビデオストリームのストリーム登録列を定義するものであり、dependent＿view＿is＿availableと、depth＿is＿availableと、2つのif文とを、主ビデオストリームの本数分定義するというループ文である。
dependent＿view＿is＿availableは、ライトビューのデータブロックが存在するかどうかを示す。depth＿is＿availableは、depthのデータブロックが存在するか否かを示す。ループ中のStream＿entryは、これらのデータが存在する場合、対応するClipファイルがどのファイルであるか、そのファイルの中でどのデータが対象となるデータか識別するためのPIDを含む。
for文中のdependent＿view＿is＿availableを条件式としたif文は、dependent＿view＿is＿availableが有効である場合、ストリームエントリーと、ストリーム属性とを追加する旨を示す。
for文中のdepth＿is＿availableを条件式としたif文は、depth＿is＿availableが有効である場合、ストリームエントリーと、ストリーム属性とを追加するものである。
2つ目のfor文は、プライマリオーディオストリームのストリーム登録列を定義するものであり、replace＿3D＿audio＿streamと、ストリームエントリーと、ストリーム属性とを、プライマリオーディオストリームの本数分定義するというループ文である。
replace＿3D＿audio＿streamは、3D再生モードの実行時において、オーディオストリームの置き換えを実行すべきかどうかを指示する。

（PG＿テキスト字幕ストリーム）
PG＿テキスト字幕ストリームの再生を許可するストリーム登録列の記述の仕方を説明する。この記述は、１つのストリーム番号に対して、LR方式のデータが存在するか、深度情報が存在するかを識別し、必要となるファイルがいずれであるか指定するものである。
図９２は、PG＿テキスト字幕ストリームのストリーム登録列を記述するためのソースコードの記述例を示す。
図中のfor 文は、オフセットが有効であるか否かを示すoffset＿is＿availableと、LR方式が有効であるか否かを示すLR＿streams＿are＿availableと、3D-Depth方式が有効であるか否かを示すDepth＿stream＿is＿availableと、3つのif文とを字幕グラフィクスストリームの本数分並べるという繰り返し構造を定義する。
offset＿is＿availableを条件式としたif文は、offset＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性を設けるものである。
LR＿streams＿are＿availableを条件式としたif文は、LR＿streams＿are＿availableが有効である場合、ストリームエントリー 左用と、ストリームエントリー 右用と、ストリーム属性とを追加するものである。
Depth＿stream＿is＿availableを条件式としたif文は、Depth＿stream＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性を追加するものである。
（IGストリーム）
IGストリームの再生を許可するストリーム登録列のの記述の仕方を説明する。
図９３は、IGストリームのストリーム登録列の記述を示す。
図中のfor においてoffset＿is＿availableと、LR＿streams＿are＿availableと、Depth＿stream＿is＿availableと、3つのif文とがメニューグラフィクスストリームの本数分存在する。
offset＿is＿availableを条件式としたif文は、offset＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性を追加させるものである。
LR＿streams＿are＿availableを条件式としたif文は、LR＿streams＿are＿availableが有効である場合、ストリームエントリー 左用、ストリームエントリー 右用、ストリーム属性を追加するものである。
Depth＿stream＿is＿availableを条件式としたif文は、Depth＿stream＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性が追加される。
図９４は、セカンダリオーディオストリーム、セカンダリビデオストリームのストリーム登録列の記述を示す。
（セカンダリオーディオストリーム）
セカンダリオーディオストリームの再生を許可するストリーム登録列の記述について説明する。
図中の1つ目のfor文は、replace＿3D＿audio＿stream、ストリームエントリー、ストリーム属性の組みを、セカンダリオーディオストリームの本数分だけ定義するループを形成している。replace＿3D＿audio＿streamは、3D再生モードにおいて、セカンダリオーディオストリームの置き換えを実行するか否かを示す。
2つ目のfor文は、dependent＿view＿is＿available、Depth＿is＿availableの組みと、2つのif文とを含む。
dependent＿view＿is＿availableを条件式としたif文は、dependent＿view＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性を追加するものである。
Depth＿is＿availableを条件式としたif文は、Depth＿is＿availableが有効である場合、ストリームエントリー、ストリーム属性を追加するものである。
（セカンダリビデオストリームのストリーム登録列）
セカンダリビデオストリームの再生を許可するストリーム登録列の記述について説明する。
2つ目のfor文は、セカンダリビデオストリームのストリーム登録列を定義するものであり、dependent＿view＿is＿availableと、depth＿is＿availableと、2つのif文とを、セカンダリビデオストリームの本数分定義するというループ文である。
for文中のdependent＿view＿is＿availableを条件式としたif文は、dependent＿view＿is＿availableが有効である場合、ストリームエントリーと、ストリーム属性とを追加する旨を示す。
for文中のdepth＿is＿availableを条件式としたif文は、depth＿is＿availableが有効である場合、ストリームエントリーと、ストリーム属性とを追加するものである。
以上のように本実施形態によれば、3D-LR方式、1plane＋Offsetモードだけでなく、3D-Depth方式に対応することができる、拡張ストリーム選択テーブルを作成することができる。
(第１９実施形態)
本実施形態では、テキスト字幕ストリームのプレーンオフセットについて説明する。
テキスト字幕(textST)ストリームはAVストリームに多重化されないので、その再生にあたっては、テキスト字幕ストリーム本体と、テキストの展開に用いられるフォントとを再生に先立ち、メモリにプリロードしておく必要がある。またテキスト字幕ストリームのうち、どの言語を正常に表示できるかどうかは、BD-ROM再生装置において、言語コード毎に設定されたケーパビリティフラグに設定される。一方、PGストリームによる字幕再生には、ケーパビリティフラグの参照は不要となる。PGストリームにおける字幕は、ランレングス圧縮された字幕を展開すれば足りるからである。
以上は、テキスト字幕ストリームの一般的な構成である。以下、3D再生モード特有となるテキスト字幕ストリームの改良について説明する。1plane＋Offset(3D-LR)モード、3D-Depthモードにおいて再生の対象になるテキスト字幕ストリーム(0x1801のTSパケットから構成されるもの)は、フレームにおいてプレーンオフセットを更新できる構造になっており、プレーン用のパレット構造を追加できる。これは、滑らかな深度変更のため、オフセットの情報のみをフレーム毎に、テキスト字幕デコーダに送り込みたいとの要望による。
2つのオフセット情報の差分は、深度を時間で線形で変化させることも可能である。2点間を、非線形に補完して、滑らかに加減速しながらオフセットを変更することも可能である。
図９５は、テキスト字幕ストリームのプレーンオフセットの時間的変化を表すグラフである。本図において破線は非線形補間を、実線は線形補間を示す。
以上のように本実施形態によれば、プレーンオフセットの設定に、線形補間、非線形補間を利用することができ、字幕の飛出し度合を滑らかに変化させることが可能になる。
(第２０実施形態)
本実施形態では、プレーンのレイヤモデルにおいて、最下層に存在するプレーンメモリの改良である。このプレーンメモリは、バッググラウンドプレーンメモリと呼ばれ、背景壁紙画像を格納する。インタラクティブグラフィクスのポップアップメニューを再生する場合、BD-Jアプリケーションがポップアップメニューを表示する場合、このバッググラウンドプレーンメモリの格納内容が、背景壁紙画像として用いられる。そして本実施形態では、バックグラウンドプレーンの格納内容を、プライマリビデオストリームの2D/３D切り替えに追従して表示形式を切り替える。図９６は、背景画像をなすIピクチャを示す。背景画像（壁紙）を設定するために、JPEGあるいはIフレームをL/R個別に指定する。2D/3D切り替え時は、MainView属性(=L or R)で指定される左右いずれかの画像を表示する。
(第２１実施形態)
第８実施形態の再生装置２００は、ビルドインメディアドライブ、リムーバブルメディアを含むローカルストレージを具備していて、これらへの書き込みを想定した構成になっているので、本願明細書に記載された再生装置は、記録装置としての機能を兼備しているといえる。再生装置２００が記録装置として機能する場合、以下の態様によって、拡張ストリーム選択テーブルを含むプレイリスト情報の書き込みを実行する。

i)再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービス(MODEST)の供給を受ける機能をもつ場合、BD-Jオブジェクトの書き込みを以下のように行う。
つまり再生装置２００がオンデマンドマニュファクチャサービス又は電子的セルスルーサービスによってBD-Jオブジェクトの供給を受ける際、リムーバブルメディアにおけるルートディレクトリの配下に、デフォルトのディレクトリと、MODESTディレクトリとをクリエイトして、MODESTディレクトリの配下に、BDMVディレクトリをクリエイトする。MODESTディレクトリは、ファーストMODESTディレクトリであり、ファーストMODESTディレクトリは、前記サービスを初めて受けた際、クリエイトされるMODESTディレクトリである。ユーザが２回目以降にサービスを受ける際、再生装置２００における制御部は、２回目以降のサービスに対応するMODESTディレクトリをクリエイトする。
そして、上述したように、プレイリスト情報を取得すると、制御部は、デフォルトディレクトリにスタートアッププログラムを書き込み、MODESTディレクトリ配下のBDMVディレクトリにBD-Jオブジェクトを書き込む。このスタートアッププログラムは、記録媒体が再生装置２００に装填された際、最初に実行されるべきプログラムであり、BDMVディレクトリを選択する操作をユーザから受け付けるためのメニューを再生装置２００に表示させて、ルート変更機能を再生装置２００に実行させる。このルート変更機能は、メニューに対する選択操作がユーザによってなされた場合、選択されたBDMVディレクトリが属するMODESTディレクトリをルートディレクトリとして認識させる機能である。かかるルート変更機能によって、BD-ROMを再生するのと同じ制御手順によって取得したプレイリスト情報に基づく再生制御を実行することができる。
ii)マネージドコピーを実現する記録装置としての実施
記録装置は、マネージドコピーによってデジタルストリームの書き込むものでもよい。
マネージドコピーとは、BD-ROM等の読み出し専用記録媒体に記録されているデジタルストリームやプレイリスト情報、クリップ情報、アプリケーションプログラムを、別の光ディスク（BD-R，BD-RE，DVD-R，DVD-RW，DVD-RAM等）やハードディスク、リムーバブルメディア（SDメモリーカード、メモリースティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等）などの読み書き可能な記録媒体へコピーする際、サーバと通信を行い、認証が行われ許可された状態においてのみコピー実行可能にする技術である。この技術により、バックアップ回数を制限したり、課金された状態でのみバックアップを許す等の制御を行うことができる。
BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。
マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで"トランスコード"とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2TS形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、AVクリップ、Clip情報、プレイリスト情報を得る必要がある。
以上のように本実施形態によれば、これまでの実施形態で述べた再生装置を、記録装置/再生装置兼用タイプとして実施することができる。
（第２２実施形態)
本実施形態は、オーディオストリームについての改良に関する。
オーディオストリームの符号化方式には、LPCMの他、DD/DD+、DTS-HD、DD/MLPがある。DD/DD+、DTS-HD、DD/MLPといった符号化方式のオーディオストリームのオーディオフレームは、基本データと、拡張データとから構成される。DD/DD+の基本データは、インデペンドサブストリームであり、DD/DD+の拡張データは、デペンドサブストリームであり、DTS-HDの基本データは、コアサブストリームであり、DTS-HDの拡張データは、エクステンションサブストリームであり、DD/MLPの基本データは、DDデータであり、DD/MLPの拡張データは、MLPオーディオである。
これらの符号化方式に対応するため、再生装置には、ステレオ再生の能力が存在するか、サラウンド再生の能力が存在するかを、各符号化方式毎に示すコンフィグレーションレジスタ、再生装置における言語設定を示す言語設定レジスタ、再生対象となるオーディオストリームの番号を格納するストリーム番号レジスタが存在する。そして、複数のオーディオストリームの何れかを再生対象として選択するため、再生装置は、記録媒体に記録されている複数オーディオストリームのそれぞれが、複数の条件のうち、いずれの条件を満たすかを判定して、満たすと判定された条件の組合せに応じてオーディオストリームを選択するとのプロシージャを実行する。
この複数の条件には、第１条件、第２条件、第３条件があり、第１条件は、オーディオストリームの符号化方式と、コンフィグレーションレジスタの設定値とを比較することで、再生できると判定されることであり、第２条件は、オーディオストリームの言語コードと、言語設定レジスタの設定値とを比較することによる、言語属性の一致であり、第３条件は、オーディオストリームのチャンネル数と、コンフィグレーションレジスタの設定値とを比較することで、サラウンド出力を行えると判定されることである。
第１条件、第２条件、第３条件の全てを満たすオーディオストリームが存在しない場合、第１条件及び第２条件を満たすオーディオストリームのうち、STN_tableにおけるストリーム登録が先頭に位置しているオーディオストリームを選択して、そのオーディオストリームのストリーム番号を、再生装置におけるストリーム番号レジスタ(PSR1)に設定する。こうすることで、最も最適なオーディオストリームが選択されることになる。 再生装置における前記セッティングレジスタは、複数の符号化方式の基本データに対応した第１のフラグ群と、複数の符号化方式の拡張データに対応した第２のフラグ群とを含み、第１のフラグ群は、基本データのサラウンド出力を処理できるか否かを符号化方式毎に示す複数のフラグによって構成されており、第２のフラグ群は、拡張データのサラウンド出力を処理できるか否かを符号化方式毎に示す複数のフラグによって構成されている。
オーディオストリームは、テレビの再生方式の影響を受けないので、５.１chなどで音響効果・定位のあるオーディオストリームを記録しておけば、2Dモード、3Dモードで共有することが可能である。
2Dモード/3Dモードの表示形式は視覚的な表示の違いであり、オーディオストリームに採用されている上述した符号化方式は、５.１chなどのマルチチャンネルを用いて、ディスプレイより前面に音を定位させることができる。
この場合、マルチチャネル拡張方式に対応する再生装置においてのみ、拡張データされたマルチチャネル再生が可能となる。上記オーディオストリームの符号化方式は既にそれらに対応した形式であるため、2Dモードと3Dモードとで音声を切り替える必要はない。
しかし、2Dモードと3Dモードとで音の定位具合を変えたい場合は、3D再生装置でのみ再生される拡張部分をオーディオストリームに設定するか、あるいは、2Dモードと3Dモードとで再生されるオーディオを切り替えればよい。
2D再生モードと、3D再生モードとでオーディオの定位などを変化させたい場合、オーディオストリームを構成するオーディオアクセスユニット内に、3D再生モードのための拡張データを設定しておき、2D再生モードと、3D再生モードとで、異なるTSパケットの多重分離を行わせるよう、拡張ストリーム選択テーブル内にオーディオストリームのストリーム登録列を設けておく。そして3D再生モードにおいて、この3D再生モード用のオーディオストリームを再生させれば、音声の定位位置を3D再生モード時に変化させることができる。
しかし、同じストリーム番号を持つストリームは、2D再生モードと、3D再生モードとで再生すべきオーディオストリームが異なる場合でも、言語属性は同じにせねばならない。あるストリーム番号で、2Dモードでしか再生されないオーディオ、3Dモードでしか再生されないオーディオはない。これは、2D再生モードと、3D再生モードとの切り替え時のユーザーの混乱を防止するためである。
2Dモードと3Dモードとでオーディオストリーム自体が異なる場合でも、管理構造上は１本として扱うため、2Dモード用のオーディオストリームの言語属性と、3Dモード用のオーディオストリームの言語属性とは一致させておく。
（第２３実施形態）
本実施形態では、前述の実施形態において説明された構造のデータを再生する再生装置に関して、集積回路６０３を用いて実現した構成例について説明する。
図９７は、2D/3D再生装置を集積回路を用いて実現した構成例である。
媒体IF部６０１は、媒体からデータを受信して（読み出して）、集積回路６０３に転送する。なお媒体IF部６０１は、前述の実施形態において説明した構造のデータを媒体から受信する。媒体IF部６０１は、例えば、媒体が光ディスクやハードディスクの場合はディスクドライブ、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波の場合はCANチューナーやSiチューナー、媒体がイーサネット（登録商標）、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。
メモリ６０２は、媒体から受信した（読み出した）データを一旦格納したり、集積回路６０３における処理途中のデータを一時的に格納するメモリで、例えばSDRAM(Synchronous Dynamic Random Access Memory)、DDRx SDRAM(Double-Date-Ratex Synchronous Dynamic Random Access Memory;x=1,2,3・・・)等が用いられる。なおメモリ６０２は、任意の個数備えていればよく、必要に応じて単数でも複数でも構わない。
集積回路６０３は、媒体IF部６０１から転送されたデータに対して映像・音声処理を施すシステムLSIで、主制御部６０６、ストリーム処理部６０５、信号処理部６０７、メモリ制御部６０９、AV出力部６０８等から構成される。
主制御部６０６は、タイマ機能や割り込み機能を有するプロセッサコアを有し、プロセッサコアはプログラムメモリ等に格納されたプログラムに従って、集積回路６０３全体の制御を行う。なお、プログラムメモリ等には、予めOS等の基本ソフトが格納されている。
ストリーム処理部６０５は、主制御部６０６の制御の下、媒体から媒体IF部６０１経由で転送されたデータを受信し、集積回路６０３内のデータバスを経由してメモリ６０２に格納したり、受信したデータを映像系データ、音声系データに分離する。前述したとおり媒体上ではレフトビュービデオストリームを含む2D/L用のAVクリップとライトビュービデオストリームを含むR用のAVクリップが、幾つかのエクステントに分割された状態で交互に配置されている。従って、主制御部６０６は、集積回路６０３がレフトビューストリームを含む左目用データを受信した場合は、メモリ６０２の第１の領域にデータが格納されるように、ライトビュービデオストリームを含む右目用データを受信した場合は、メモリ６０２の第２の領域にデータが格納されるように制御する。ここで、左目用データは左目用エクステントに属しており、右目用データは右目用エクステントに属している。なお、メモリ６０２における第１、第２の領域は単一のメモリが論理的に領域分割されたものでもよいし、物理的に異なるメモリでもよい。
信号処理部６０７は、主制御部６０６の制御の下、ストリーム処理部６０５が分離した映像系データ、音声系データに対し、適切な方式でデコードする。映像系データは、MPEG-2、MPEG-4 AVC、MPEG4-MVC、SMPTE VC-1などの方式を使って符号化記録されており、また音声系データは 、ドルビーAC-3、Dolby Digital Plus、MLP、DTS、DTS-HD、リニアPCMなどの方式で圧縮・符号化記録されているので、信号処理部６０７はこれらに対応した方式でデコードする。なお、信号処理部６０７のモデルは、例えば第９実施形態の図６５における各種デコーダがそれに当たる。
メモリ制御部６０９は、集積回路内の各機能ブロックからメモリ６０２へのアクセスを調停する。
AV出力部６０８は、主制御部６０６の制御の下、信号処理部６０７においてデコードされた映像系データを重畳したり、映像系及データのフォーマット変換等をして集積回路６０３外へ出力する。
図９８は、ストリーム処理部６５の代表的な構成を示す機能ブロック図である。ストリーム処理部６５は、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３等を備える。
デバイス・ストリームIF部６５１は、媒体IF部６０１と集積回路６０３間のデータ転送用インターフェースであり、例えば、媒体が光ディスクやハードディスクの場合はSATA(Serial Advanced Technology Attachment)、ATAPI(Advanced Technology Attachment Packet Interface)、PATA(Parallel Advanced Technology Attachment)、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送はなどの場合はチューナーIF、媒体がイーサネット、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。なお、媒体の種類によっては、デバイス・ストリームIF部６５１が媒体IF部６０１の機能の一部を肩代わりしても構わないし、媒体IF部６０１が集積回路６０３に内蔵されていても構わない。
多重分離部６５２は、媒体から転送された映像・音声を含む再生データを映像系データと音声系データに分離する。前述の各エクステントは、映像・音声・PG（字幕）・IG（メニュー）等の各ソースパケットから構成されており（但し、ディペンデントは音声を含まない場合もある）、各ソースパケットに含まれているPID（識別子）に従って、映像系・音声系の各TSパケットに分離し、信号処理部６０７に転送する。処理済のデータは、直接もしくは一旦メモリ６０２に格納された後、信号処理部６０７に転送される。なお、多重分離部６５２のモデルは、例えば第９実施形態の図６５におけるソースデパケタイザ、PIDフィルタがそれに当たる。
切替部６５３は、デバイス・ストリームIF部６５１が左目用データを受信した時はメモリ６０２の第１の領域に格納されるように、右目用データを受信した時はメモリ６０２の第２の領域に格納されるように、出力先（格納先）を切り替える。ここで、切替部６５３は例えばDMAC(Direct Memory Access Controller)である。図９９は切替部６５３がDMACであった場合の切替部６５３周辺の概念図である。DMACは、主制御部６０６の制御の下、デバイス・ストリームIF部が受信したデータとそのデータ格納先アドレスをメモリ制御部６０９に対して送信する。具体的には、デバイス・ストリームIF部が左目用データを受信した時はアドレス１（第１の格納領域）を、右目用データを受信した時はアドレス２（第２の格納領域）をメモリ制御部６０９に送信することで、受信データによってその出力先（格納先）を切り替えている。メモリ制御部６０９は、DMACから送られてきた格納先アドレスに従ってメモリ６０２にデータを格納する。なお、主制御部６０６の代わりに切替部６５３を制御する専用の回路を設けても構わない。
ここでは、ストリーム処理部６５の代表的な構成として、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３について説明したが、受信した暗号化データや鍵データ等を復号する暗号エンジン部、媒体〜再生装置間の機器認証プロトコル等の実行制御や秘密鍵を保持するセキュア管理部、ダイレクトメモリアクセス用のコントローラ等を更に備えていてもよい。これまでは媒体から受信したデータをメモリ６０２に格納する際に、切替部６５３が左目用データ・右目用データかによって格納先を切り替える場合について説明してきたが、媒体から受信したデータを一旦メモリ６０２に格納した後に、多重分離部６５２へデータを転送する際に、左目用データ・右目用データを振り分けてもよい。
図１００は、AV出力部６０８の代表的な構成を示す機能ブロック図である。AV出力部６０８は、画像重畳部６８１と、ビデオ出力フォーマット変換部６８２、オーディオ・ビデオ出力IF部６８３等を備える。
画像重畳部６８１は、デコードされた映像系のデータを重畳する。具体的には、レフトビュービデオデータもしくはライトビュービデオデータと、PG（字幕）、IG（メニュー）をピクチャ単位で重畳する。画像重畳部６８１のモデルは、例えば第１１実施形態、図７１などである。
ビデオ出力フォーマット変換部６８２は、デコードされた映像系データに対して、拡大または縮小するリサイズ処理、走査方式をプログレッシブ方式及びインターレース方式の一方から他方に変換するＩＰ変換処理、ノイズを除去するノイズリダクション処理、フレームレートを変換するフレームレート変換処理などを必要に応じて行う。
オーディオ・ビデオ出力IF部６８３は、画像重畳やフォーマット変換された映像系データとデコードされた音声系データとに対して、データ送信形式に合わせてエンコード等を行う。なお、後述するようにオーディオ・ビデオ出力IF部６８３は、一部集積回路６０３外に備えられても構わない。
図１０１は、AV出力部６０８もしくは再生装置のデータ出力部分を、より詳細に示した構成例である。本実施の形態における集積回路６０３及び再生装置は、複数の映像系データ、音声系データのデータ送信形式に対応している。図１００におけるオーディオ・ビデオ出力IF部６８３は、アナログビデオ出力IF部６８３a、アナログオーディオ出力IF部６８３c、デジタルオーディオ・出力IF部６８３bに対応する。
アナログビデオ出力IF部６８３aは、画像重畳処理や出力フォーマット変換処理された映像系データを、アナログ映像信号形式に変換・エンコードし、出力する。例えば、NTSC、PAL、SECAMの３方式のいずれかに対応したコンポジットビデオエンコーダー、Ｓ映像信号（Y/C分離）用エンコーダー、コンポーネント映像信号用エンコーダーや、DAC（D/Aコンバータ）等がそれに当たる。
デジタルオーディオ・ビデオ出力IF部６８３bは、デコードされた音声系データと画像重畳処理や出力フォーマット変換された映像系データを一体化、更に暗号化した後、データ送信規格に合わせてエンコードし、出力する。例えば、HDMI(High−Definition Multimedia InterFace)等がそれに当たる。
アナログオーディオ出力IF部６８３cは、デコードされた音声系データをD/A変換しアナログ音声データを出力するオーディオDAC等がそれに当たる。
これら映像系データ及び音声系データの送信形式は、表示装置・スピーカー側がサポートしているデータ受信装置（データ入力端子）に依存して切り替えたり、またユーザーの選択によって送信形式を切り替えることが可能である。更に、単一の送信形式だけではなく、並行して複数の送信形式にて同一のコンテンツに対応したデータを送信することも可能である。
ここでは、AV出力部６０８の代表的な構成として、画像重畳部６８１、ビデオ出力フォーマット変換部６８２、オーディオ・ビデオ出力IF部６８３について説明したが、フィルタ処理、画面合成、曲線描画、３Ｄ表示等のグラフィックス処理を行うグラフッィクスエンジン部等を更に備えていてもよい。
以上が、本実施の形態における再生装置の構成についての説明である。なお、前述の集積回路６０３に含まれる各機能ブロックは全てが内蔵されていなくても良いし、逆に図９７のメモリ６０２が集積回路６０３に内蔵されていてもよい。また、本実施形態においては、主制御部６０６と信号処理部６０７は異なる機能ブロックとして説明してきたが、主制御部６０６が信号処理部６０７の処理の一部を行っても構わない。
また、集積回路６０３における制御バスやデータバスの経路は、各処理ブロックの処理手順や処理内容によって任意に配置されるが、例えば図１０２のように、各処理ブロックどうしを直接結ぶようにデータバスを配置してもよいし、図１０３のように各処理ブロックどうしをメモリ６０２（メモリ制御部６０９）を介して結ぶようにデータバスを配置してもよい。
また、集積回路６０３は、複数のチップを一つのパッケージに封止し、見かけ上一つのLSIにしたマルチチップ・モジュールであっても構わない。 また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
次に、以上のように構成された再生装置の動作について説明する。
図１０４は、媒体からデータを受信し（読み出し）、デコードした後に、映像信号及び音声信号として出力する再生動作手順を簡単に示すフローチャートである。
Ｓ６０１：媒体からデータを受信する（読み出す）（媒体IF部６０１→ストリーム処理部６５）。
Ｓ６０２：Ｓ６０１において受信された（読み出された）データを各種データ（映像系データ・音声系データ）に分離する（ストリーム処理部６５）。
Ｓ６０３：Ｓ６０２において分離された各種データを適切な形式でデコードする（信号処理部６０７）。
Ｓ６０４：Ｓ６０３においてデコード処理された各種データのうち、映像系のものについて重畳処理を行う（AV出力部６０８）。
Ｓ６０６：Ｓ６０２〜Ｓ６５において処理された映像系データ及び音声系データを出力する（AV出力部６０８）。
図１０５は、より詳細に再生動作手順を示したフローチャートである。各動作・処理は、主制御部６０６の制御の下、行われる。
Ｓ７０１：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている再生されるデータ以外の、データを再生するために必要なデータ（プレイリスト、クリップ情報等）を受信し（読み出し）、メモリ６０２に格納する（媒体IF部６０１、デバイスIF部６５１、メモリ制御部６０９、メモリ６０２）。
Ｓ７０２：主制御部６０６は、受信されたクリップ情報に含まれるストリーム属性情報から、媒体に格納されている映像データ及び音声データの圧縮形式を認識し、対応するデコード処理ができるように信号処理部６０７の初期化を行う（主制御部６０６）。
Ｓ７０３：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている映像・音声など再生されるデータを受信し（読み出し）、切替部６５３、メモリ制御部６０９を経由してメモリ６０２に格納する。なお、データはエクステント単位で受信し（読み出され）、左目用データを受信した（読み出した）時は第１の領域へ、右目用データを受信した（読み出した）時は第２の領域へ格納されるよう、主制御部６０６が切替部６５３を制御し、切替部６５３がデータの出力先（格納先）を切り替える（媒体IF部６０１、デバイスIF部６５１、主制御部６０６、切替部６５３、メモリ制御部６０９、メモリ６０２）。
Ｓ７０４：メモリ６０２に格納されたデータは、ストリーム処理部６０５の多重分離部６５２に転送され、多重分離部６５２はストリームデータを構成するソースパケットに含まれるPIDに従って映像系（主映像、副映像、PG（字幕）、IG（メニュー））、音声系（音声、副音声）のいずれであるか認識し、TSパケット単位で信号処理部６０７の対応する各デコーダへ転送する。（多重分離部６５２）。
Ｓ７０５：信号処理部６０７の各デコーダは、転送されてきたTSパケットに対して、適切な方式でデコード処理を行う（信号処理部６０７）。
Ｓ７０６：信号処理部６０７においてデコードされた映像系データのうち、レフトビュービデオストリーム及びライトビュービデオストリームに対応するデータを、表示装置に合わせてリサイズする（ビデオ出力フォーマット変換部６８２）。
Ｓ７０７：Ｓ７０６においてリサイズされたビデオストリームと、PG（字幕）・IG（メニュー）とが重畳される（画像重畳部６８１）。
Ｓ７０８：Ｓ７０７において重畳された映像データに対して、走査方式の変換であるＩＰ変換を行う（ビデオ出力フォーマット変換部６８２）。
Ｓ７０９：これまでの処理を行った映像系データ及び音声系データに対して、表示装置・スピーカー４のデータ出力方式、もしくは表示装置・スピーカー４へのデータ送信方式に従って、エンコードやD/A変換等を行う。例えば、映像系データ・音声系データをそれぞれ、アナログまたはデジタル出力に対応するために処理を行う。映像系データのアナログ出力としては、コンポジット映像信号やＳ映像信号やコンポーネント映像信号等をサポートしている。また映像系・音声系データのデジタル出力は、HDMIをサポートしている（オーディオ・ビデオ出力IF部６８３）。
Ｓ７１０：Ｓ７０９において処理された映像系データ及び音声系データを、表示装置・スピーカーに送信、出力する（オーディオ・ビデオ出力IF部６８３、表示装置・スピーカー４）。
以上が、本実施の形態における再生装置の動作手順の説明である。なお、処理ごとに処理結果をメモリ６０２に一旦格納しても構わない。また、本動作手順では、ビデオ出力フォーマット変換部６８２においてリサイズ処理及びIP変換処理を行う場合について説明したが、必要に応じて処理を省略しても構わないし、また他の処理（ノイズリダクション処理、フレームレート変換処理等）を行っても構わない。更に、可能なものについては処理手順を変更しても構わない。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

(ファイル同士の対応付け)
第３実施形態において、識別情報を用いた対応付けの具体例ではレフトビューの識別番号に"１"を加算したものをライトビューの識別番号とした。しかし、レフトビューの識別番号に、"１００００"を加算したものをライトビューの識別番号として採用してもよい。
ファイル名によるカップリング方式でファイルの対応付けてを実現する場合、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。
Depth方式のためのグレースケールのように、１本では立体視映像を再生できないストリームに関しては、誤って機器がそのファイルを単体で再生しないように拡張子を変えて区別する。単体では再生できないファイルを識別するため3D対応ファイルを既存機器からDLNA(Digital Living Network Alliance)を介して参照する場合などのユーザー混乱を防止する。ファイル番号を同一にし、拡張子を区別することで、ファイル名だけでペアリング情報を表現することも可能になる。
(立体視方式)
第１実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。
TV３００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。
同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。

（光ディスクの再生）
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.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなく3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ
１００ 記録媒体
２００ 再生装置
３００ 表示装置
４００ 3D眼鏡
５００ リモコン

Claims (10)

  1. プレイリスト情報と、複数のエレメンタリストリームとが記録された記録媒体であって、
    前記プレイリスト情報は、基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを含み、
    前記基本ストリーム選択テーブルは、ストリーム番号に対応付けられた、平面視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記拡張ストリーム選択テーブルは、前記ストリーム番号と同一のストリーム番号に対応付けられた、立体視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記プレイリスト情報は、前記記録媒体における第１の領域に記録されており、
    前記複数のエレメンタリストリームは、前記記録媒体における第２の領域に記録されており、
    前記第１の領域は、前記第２の領域より内周側に配置されている
    ことを特徴とする記録媒体。
  2. 前記エレメンタリストリームのリストは、エレメンタリストリームのストリームエントリーを、ストリーム番号に対応付けており、
    前記ストリームエントリーは、前記エレメンタリストリームに対応するパケット識別子を含む
    ことを特徴とする請求項１記載の記録媒体。
  3. 前記平面視再生モードにおいて再生されるエレメンタリストリームとは、ベースビュービデオストリームであり、
    前記立体視再生モードにおいて再生されるエレメンタリストリームとは、ベースビュービデオストリームと共に再生されるディペンデントビュービデオストリームであり、
    前記基本ストリーム選択テーブルに示されるリストに含まれるベースビュービデオストリームの数は、前記拡張ストリーム選択テーブルに示されるリストに含まれるディペンデントビュービデオストリームの数と等しい
    ことを特徴とする請求項１記載の記録媒体。
  4. 前記エレメンタリストリームは、グラフィクスストリームであり、
    前記拡張ストリーム選択テーブルは識別フラグを含み、
    前記識別フラグは、
    立体視再生モードにおいて再生されるグラフィクスストリームに、左目用グラフィクスストリームと右目用グラフィクスストリームのペアが存在するか否かを示す
    ことを特徴とする請求項１記載の記録媒体。
  5. グラフィクスストリームには、プレゼンテーショングラフィクスストリームと、インタラクティブグラフィクスストリームとがある
    ことを特徴とする請求項４記載の記録媒体。
  6. プレイリスト情報と、ストリームファイルとが記録された記録媒体の再生を行う再生装置であって、
    前記プレイリスト情報は、基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを含み、
    前記基本ストリーム選択テーブルは、ストリーム番号に対応付けられた、平面視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記拡張ストリーム選択テーブルは、前記ストリーム番号と同一のストリーム番号に対応付けられた、立体視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記ストリームファイルに格納されている複数のパケットを順次読み出す読出手段と、
    読み出された複数のパケットのうち、所定のパケット識別子を有するものを分離する多重分離手段と、
    多重分離されたパケットをデコードするデコーダとを備え、
    立体視再生モードにおいて、前記多重分離手段は、
    前記拡張ストリーム選択テーブルが示すエレメンタリストリームのリストのうち、前記ストリーム番号に対応するストリームエントリーによって示されるパケット識別子を多重分離に用いる
    ことを特徴とする再生装置。
  7. 前記エレメンタリストリームは、グラフィクスストリームであり、
    前記拡張ストリーム選択テーブルは識別フラグを含み、
    前記識別フラグは、
    立体視再生モードにおいて再生されるグラフィクスストリームに、左目用グラフィクスストリームと右目用グラフィクスストリームのペアが存在するか否かを示し、
    前記多重分離手段は、識別フラグが、左目用グラフィクスストリームと右目用グラフィクスストリームのペアが存在する旨を示す場合、左目用グラフィクスストリームと右目用グラフィクスストリームのペアをデコーダに供給する
    ことを特徴とする請求項６記載の再生装置。
  8. グラフィクスストリームには、プレゼンテーショングラフィクスストリームと、インタラクティブグラフィクスストリームとがある
    ことを特徴とする請求項７記載の再生装置。
  9. プレイリスト情報と、複数のエレメンタリストリームとを記録媒体に記録する記録方法であって、
    複数のエクステントを含んだベースビュービデオストリームと複数のエクステントを含んだディペンデントビュービデオストリームを生成するステップと、
    前記ベースビュービデオストリームに属するエクステントと前記ディペンデントビュービデオストリームに属するエクステントとが交互に配置されたデータを記録するステップと、
    プレイリスト情報を記録するステップとを備え、
    前記プレイリスト情報は、基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを含み、
    前記基本ストリーム選択テーブルは、ストリーム番号に対応付けられた、平面視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記拡張ストリーム選択テーブルは、前記ストリーム番号と同一のストリーム番号に対応付けられた、立体視再生モードにおいて再生されるエレメンタリストリームのリストを示す
    ことを特徴とする記録方法。
  10. プレイリスト情報と、ストリームファイルとが記録された記録媒体と前記記録媒体を再生する再生装置とを備えた記録媒体再生システムであって、
    前記プレイリスト情報は、基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを含み、
    前記基本ストリーム選択テーブルは、ストリーム番号に対応付けられた、平面視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記拡張ストリーム選択テーブルは、前記ストリーム番号と同一のストリーム番号に対応付けられた、立体視再生モードにおいて再生されるエレメンタリストリームのリストを示し、
    前記再生装置は、
    前記ストリームファイルに格納されている複数のパケットを順次読み出す読出手段と、
    読み出された複数のパケットのうち、所定のパケット識別子を有するものを分離する多重分離手段と、
    多重分離されたパケットをデコードするデコーダとを備え、
    立体視再生モードにおいて、前記多重分離手段は、
    前記拡張ストリーム選択テーブルが示すエレメンタリストリームのリストのうち、前記ストリーム番号に対応するストリームエントリーによって示されるパケット識別子を多重分離に用いる
    ことを特徴とする記録媒体再生システム。
JP2010523231A 2009-02-19 2010-02-04 記録媒体、再生装置、記録方法、記録媒体再生システム Active JP4574748B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2009037226 2009-02-19
JP2009037226 2009-02-19
PCT/JP2010/000668 WO2010095382A1 (ja) 2009-02-19 2010-02-04 記録媒体、再生装置、集積回路

Related Child Applications (5)

Application Number Title Priority Date Filing Date
JP2010157852A Division JP2011019228A (ja) 2009-02-19 2010-07-12 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158537A Division JP4588118B1 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置
JP2010158536A Division JP4701312B2 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158539A Division JP5336436B2 (ja) 2009-02-19 2010-07-13 集積回路
JP2010158538A Division JP4588119B1 (ja) 2009-02-19 2010-07-13 再生装置、集積回路

Publications (2)

Publication Number Publication Date
JP4574748B2 true JP4574748B2 (ja) 2010-11-04
JPWO2010095382A1 JPWO2010095382A1 (ja) 2012-08-23

Family

ID=42633672

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2010523231A Active JP4574748B2 (ja) 2009-02-19 2010-02-04 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010157852A Pending JP2011019228A (ja) 2009-02-19 2010-07-12 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158539A Expired - Fee Related JP5336436B2 (ja) 2009-02-19 2010-07-13 集積回路
JP2010158536A Active JP4701312B2 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158538A Expired - Fee Related JP4588119B1 (ja) 2009-02-19 2010-07-13 再生装置、集積回路
JP2010158537A Expired - Fee Related JP4588118B1 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置

Family Applications After (5)

Application Number Title Priority Date Filing Date
JP2010157852A Pending JP2011019228A (ja) 2009-02-19 2010-07-12 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158539A Expired - Fee Related JP5336436B2 (ja) 2009-02-19 2010-07-13 集積回路
JP2010158536A Active JP4701312B2 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置、記録方法、記録媒体再生システム
JP2010158538A Expired - Fee Related JP4588119B1 (ja) 2009-02-19 2010-07-13 再生装置、集積回路
JP2010158537A Expired - Fee Related JP4588118B1 (ja) 2009-02-19 2010-07-13 記録媒体、再生装置

Country Status (17)

Country Link
US (1) US20110090305A1 (ja)
EP (1) EP2400771B1 (ja)
JP (6) JP4574748B2 (ja)
KR (1) KR20110126514A (ja)
CN (5) CN102881304A (ja)
AR (1) AR075527A1 (ja)
AU (1) AU2010203000B8 (ja)
BR (1) BRPI1001232A2 (ja)
CA (1) CA2708189C (ja)
DK (1) DK2400771T3 (ja)
ES (1) ES2526441T3 (ja)
MX (1) MX2010008147A (ja)
MY (1) MY152341A (ja)
RU (1) RU2525750C2 (ja)
TW (1) TW201127016A (ja)
WO (1) WO2010095382A1 (ja)
ZA (1) ZA201005044B (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011041249A (ja) * 2009-05-12 2011-02-24 Sony Corp データ構造および記録媒体、並びに、再生装置、再生方法、プログラム、およびプログラム格納媒体
JP2012130036A (ja) * 2009-05-12 2012-07-05 Sony Corp 記録方法

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010244630A (ja) * 2009-04-07 2010-10-28 Sony Corp 情報処理装置、情報処理方法、プログラム、及び、データ構造
JP2012089931A (ja) * 2010-10-15 2012-05-10 Sony Corp 情報処理装置、情報処理方法およびプログラム
CN102625092A (zh) * 2011-01-27 2012-08-01 天脉聚源(北京)传媒科技有限公司 一种移动设备播放视频的方法和装置
JP2012169730A (ja) * 2011-02-10 2012-09-06 Nec Personal Computers Ltd 画像処理方法及び画像処理装置
BR112013020867A2 (pt) * 2011-02-16 2016-09-27 Panasonic Corp codificador de vídeo, método de codificação de vídeo, programa de codificação de vídeo, dispositivo de reprodução de vídeo, método de reprodução de vídeo, e programa de reprodução de vídeo
WO2012111325A1 (ja) * 2011-02-17 2012-08-23 パナソニック株式会社 映像符号化装置、映像符号化方法、映像符号化プログラム、映像再生装置、映像再生方法及び映像再生プログラム
JPWO2012123982A1 (ja) * 2011-03-11 2014-07-17 日立コンシューマエレクトロニクス株式会社 記録装置／方法／媒体、再生装置／方法
US8887206B2 (en) 2011-06-09 2014-11-11 Cstereo3D, Llc Device and method for rendering and delivering 3-D content
JP2013026696A (ja) * 2011-07-15 2013-02-04 Sony Corp 送信装置、送信方法および受信装置
JP2013066075A (ja) * 2011-09-01 2013-04-11 Sony Corp 送信装置、送信方法および受信装置
US9041819B2 (en) 2011-11-17 2015-05-26 Apple Inc. Method for stabilizing a digital video
US8611642B2 (en) * 2011-11-17 2013-12-17 Apple Inc. Forming a steroscopic image using range map
JPWO2013099289A1 (ja) * 2011-12-28 2015-04-30 パナソニック株式会社 再生装置、送信装置、再生方法及び送信方法
KR102093408B1 (ko) * 2012-07-19 2020-04-14 한국전자통신연구원 동일 포트에 멀티플렉싱 된 다중 패킷 스트림의 패킷오류 구분을 선택적으로 수행하는 방법 및 그 장치
US10547713B2 (en) 2012-11-20 2020-01-28 Nvidia Corporation Method and system of transmitting state based input over a network
US20140195594A1 (en) * 2013-01-04 2014-07-10 Nvidia Corporation Method and system for distributed processing, rendering, and displaying of content
JP6303829B2 (ja) * 2014-06-03 2018-04-04 富士通株式会社 多重化プログラム、多重化装置、及び多重化方法
CN104702919B (zh) 2015-03-31 2019-08-06 小米科技有限责任公司 播放控制方法及装置、电子设备
JP6809471B2 (ja) * 2015-09-10 2021-01-06 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10630773B2 (en) 2015-11-12 2020-04-21 Nvidia Corporation System and method for network coupled cloud gaming
US11027199B2 (en) 2015-11-12 2021-06-08 Nvidia Corporation System and method for network coupled gaming
DE102017109021B4 (de) * 2016-05-11 2022-10-27 Carl Zeiss Meditec Ag System für das stereoskopische Visualisieren eines Objektbereichs sowie Objektbereich-Visualisierungsverfahren
TWI606724B (zh) * 2016-10-03 2017-11-21 和碩聯合科技股份有限公司 多媒體播放裝置及其播放方法
CN108122558B (zh) * 2017-12-22 2020-12-29 深圳国微技术有限公司 一种latm aac音频流的实时转容实现方法及装置
WO2019215984A1 (ja) * 2018-05-09 2019-11-14 オリンパス株式会社 画像処理装置及び画像生成方法
CN109561263A (zh) * 2018-11-23 2019-04-02 重庆爱奇艺智能科技有限公司 在vr设备的3d视频中实现3d字幕效果
CN112711817B (zh) * 2019-10-24 2023-04-28 深圳市建筑设计研究总院有限公司 一种受弯构件的支座连接方法
CN112040264B (zh) * 2020-09-06 2023-04-21 北京字节跳动网络技术有限公司 互动系统、方法、装置、计算机设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007166651A (ja) * 1996-02-28 2007-06-28 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、光ディスク記録装置
WO2008114595A1 (ja) * 2007-03-22 2008-09-25 Mitsubishi Electric Corporation 映像再生装置および映像再生方法
WO2009157159A1 (ja) * 2008-06-24 2009-12-30 パナソニック株式会社 記録媒体、再生装置、集積回路、再生方法、プログラム

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4739418A (en) * 1985-03-20 1988-04-19 Victor Company Of Japan, Ltd. Information signal recording disc recorded with stereoscopic television signal
JPS63151293A (ja) * 1986-12-16 1988-06-23 Mitsubishi Electric Corp 映像再生装置
JPH01109990A (ja) * 1987-10-23 1989-04-26 Sanyo Electric Co Ltd 立体ビデオディスクレコーダ
US6502199B2 (en) * 1995-09-29 2002-12-31 Matsushita Electric Industrial Co., Ltd. Method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
TW436777B (en) * 1995-09-29 2001-05-28 Matsushita Electric Ind Co Ltd A method and an apparatus for reproducing bitstream having non-sequential system clock data seamlessly therebetween
KR100354418B1 (ko) * 1996-12-04 2002-09-28 마쯔시다덴기산교 가부시키가이샤 고해상도 및 입체 영상 기록용 광디스크, 광디스크 재생 장치,및 광디스크 기록 장치
EP1708487B1 (en) * 1997-08-29 2013-05-08 Panasonic Corporation Method and apparatus for reading a high-resolution optical video disc
US7184648B1 (en) * 1999-06-25 2007-02-27 Koninklijke Philips Electronics N.V. Incomplete streams
JP2003526269A (ja) * 2000-03-03 2003-09-02 テノー ネットワークス， インコーポレイテッド 内部プロセッサメモリ領域を用いる高速データ処理
KR100354840B1 (ko) * 2000-05-09 2002-10-05 최부진 입체영상 취득을 위한 촬영기 및 촬영방법
JP4251864B2 (ja) * 2002-12-13 2009-04-08 シャープ株式会社 画像データ作成装置およびそのデータを再生する画像データ再生装置
WO2004066621A1 (ja) * 2003-01-20 2004-08-05 Pioneer Corporation 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造
JP4331488B2 (ja) * 2003-02-20 2009-09-16 パナソニック株式会社 集積回路及びそれを用いた電子機器
JP4251907B2 (ja) * 2003-04-17 2009-04-08 シャープ株式会社 画像データ作成装置
JP4228767B2 (ja) * 2003-04-25 2009-02-25 ソニー株式会社 再生装置、再生方法、再生プログラムおよび記録媒体
JP4121888B2 (ja) * 2003-04-28 2008-07-23 シャープ株式会社 コンテンツ表示装置およびコンテンツ表示プログラム
JP2004357156A (ja) * 2003-05-30 2004-12-16 Sharp Corp 映像受信装置および映像再生装置
EP1858014B1 (en) * 2004-06-02 2009-11-18 Panasonic Corporation Recording medium, reproduction device, program, and reproduction method
WO2006019039A1 (ja) * 2004-08-18 2006-02-23 Sharp Kabushiki Kaisha 画像データ表示装置
CA2602713C (en) * 2005-04-07 2014-05-13 Matsushita Electric Industrial Co., Ltd. Recording medium, reproducing device, recording method, and reproducing method
JP2007004896A (ja) * 2005-06-23 2007-01-11 Toshiba Corp 情報記憶媒体、情報転送方法、情報再生方法、及び情報記録方法
KR100657322B1 (ko) * 2005-07-02 2006-12-14 삼성전자주식회사 로컬 3차원 비디오를 구현하기 위한 인코딩/디코딩 방법 및장치
JP2007129368A (ja) * 2005-11-01 2007-05-24 Matsushita Electric Ind Co Ltd 情報記録装置およびその方法
JP2006230001A (ja) * 2006-03-20 2006-08-31 Sony Corp 再生装置、再生方法、再生プログラムおよび記録媒体
JP5011842B2 (ja) * 2006-06-22 2012-08-29 株式会社ニコン 画像再生装置
JP2009033348A (ja) * 2007-07-25 2009-02-12 Toshiba Corp ビデオ会議アプリケーションサーバ、ビデオ会議方法およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007166651A (ja) * 1996-02-28 2007-06-28 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、光ディスク記録装置
WO2008114595A1 (ja) * 2007-03-22 2008-09-25 Mitsubishi Electric Corporation 映像再生装置および映像再生方法
WO2009157159A1 (ja) * 2008-06-24 2009-12-30 パナソニック株式会社 記録媒体、再生装置、集積回路、再生方法、プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011041249A (ja) * 2009-05-12 2011-02-24 Sony Corp データ構造および記録媒体、並びに、再生装置、再生方法、プログラム、およびプログラム格納媒体
JP2012130036A (ja) * 2009-05-12 2012-07-05 Sony Corp 記録方法
US8730304B2 (en) 2009-05-12 2014-05-20 Sony Corporation Information processing apparatus, method, program and recording medium

Also Published As

Publication number Publication date
JP2011019230A (ja) 2011-01-27
ZA201005044B (en) 2012-01-25
WO2010095382A1 (ja) 2010-08-26
KR20110126514A (ko) 2011-11-23
JP4588119B1 (ja) 2010-11-24
AU2010203000B2 (en) 2014-09-25
CN102547359B (zh) 2014-12-10
CN102547359A (zh) 2012-07-04
BRPI1001232A2 (pt) 2016-02-10
EP2400771A1 (en) 2011-12-28
AR075527A1 (es) 2011-04-06
RU2010132152A (ru) 2013-03-27
MY152341A (en) 2014-09-15
CN102547346A (zh) 2012-07-04
JP2011019228A (ja) 2011-01-27
AU2010203000A1 (en) 2010-09-02
CN102685435B (zh) 2013-07-17
EP2400771A4 (en) 2013-11-27
MX2010008147A (es) 2010-11-25
JPWO2010095382A1 (ja) 2012-08-23
CN101933337B (zh) 2012-10-31
JP2011010312A (ja) 2011-01-13
AU2010203000A8 (en) 2014-10-09
ES2526441T3 (es) 2015-01-12
AU2010203000B8 (en) 2014-10-09
US20110090305A1 (en) 2011-04-21
CN102685435A (zh) 2012-09-19
RU2525750C2 (ru) 2014-08-20
JP4701312B2 (ja) 2011-06-15
JP5336436B2 (ja) 2013-11-06
JP4588118B1 (ja) 2010-11-24
CA2708189C (en) 2016-03-29
DK2400771T3 (en) 2015-02-23
CN101933337A (zh) 2010-12-29
TW201127016A (en) 2011-08-01
JP2011030221A (ja) 2011-02-10
EP2400771B1 (en) 2014-11-19
JP2011015408A (ja) 2011-01-20
CA2708189A1 (en) 2010-08-19
CN102881304A (zh) 2013-01-16

Similar Documents

Publication Publication Date Title
JP4574748B2 (ja) 記録媒体、再生装置、記録方法、記録媒体再生システム
JP5038543B2 (ja) 受信装置
JP4564107B2 (ja) 記録媒体、再生装置、システムｌｓｉ、再生方法、記録方法、記録媒体再生システム
WO2010095381A1 (ja) 記録媒体、再生装置、集積回路
JP5497679B2 (ja) 半導体集積回路
WO2010095410A1 (ja) 記録媒体、再生装置、集積回路
WO2010143439A1 (ja) 再生装置、集積回路、記録媒体

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100727

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100818

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4574748

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130827

Year of fee payment: 3