JP4654327B2 - 記録媒体、及び再生装置 - Google Patents

記録媒体、及び再生装置 Download PDF

Info

Publication number
JP4654327B2
JP4654327B2 JP2010525153A JP2010525153A JP4654327B2 JP 4654327 B2 JP4654327 B2 JP 4654327B2 JP 2010525153 A JP2010525153 A JP 2010525153A JP 2010525153 A JP2010525153 A JP 2010525153A JP 4654327 B2 JP4654327 B2 JP 4654327B2
Authority
JP
Japan
Prior art keywords
data block
playback
file
stream
extent
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
JP2010525153A
Other languages
English (en)
Other versions
JPWO2010095443A1 (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 JP4654327B2 publication Critical patent/JP4654327B2/ja
Publication of JPWO2010095443A1 publication Critical patent/JPWO2010095443A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • H04N9/8233—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a character code signal
    • H04N9/8244—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal the additional signal being a character code signal involving the use of subcodes
    • 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/005—Reproducing at a different information rate from the information rate of recording
    • 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/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • 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/161—Encoding, multiplexing or demultiplexing different image signal components
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/907—Television signal recording using static stores, e.g. storage tubes or semiconductor memories
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/80—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205—Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal
    • 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

Description

本発明は、3D映像及び2D映像の再生技術の技術分野に属する発明である。
本発明は、立体視映像の再生技術に関し、特に、記録媒体上での映像データのアロケーションに関する。
近年では3D映像の映画作品が増加していることに伴い、このような映画作品を家庭用に供給するため、3D映像を高画質のまま光ディスクに格納することが求められてきている。
光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置（以下、「2D再生装置」と呼ぶ）との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3Ｄ映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの２種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置（以下、「2D/3D再生装置」）では、2D映像もしくは3D映像として再生できることが求められる。また、再生互換性を有する光ディスクを用いることで、2D/3D再生装置では、１つの光ディスクで3D映像及び2D映像の再生を楽しむことができる。
図１０４は、３Ｄ映像コンテンツが記録された光ディスクについて、２Ｄ再生装置に対する互換性を確保するための技術を示す模式図である（例えば特許文献１参照）。光ディスク6701には二種類のビデオストリームが格納されている。一方は２Ｄ／レフトビュービデオストリームであり、他方はライトビュービデオストリームである。「２Ｄ／レフトビュービデオストリーム」は、３Ｄ映像の再生では視聴者の左目に見せる２Ｄ映像、すなわち「レフトビュー」を表し、２Ｄ映像の再生ではその２Ｄ映像そのものを表す。「ライトビュービデオストリーム」は、３Ｄ映像の再生において視聴者の右目に見せる２Ｄ映像、すなわち「ライトビュー」を表す。左右のビデオストリーム間では、フレームレートは等しいが、フレームの表示時期はフレーム周期の半分だけずれている。例えば、各ビデオストリームのフレームレートが１秒間に２４フレームであるとき、２Ｄ／レフトビュービデオストリームとライトビュービデオストリームとの各フレームが１／４８秒ごとに交互に表示される。
各ビデオストリームは、図１０４に示されているように、光ディスク6701上では複数のエクステント6702A−C、6703A−Cに分割されている。各エクステントはＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）を１以上含み、光ディスクドライブによって一括して読み出される。以下、２Ｄ／レフトビュービデオストリームに属するエクステントを「２Ｄ／レフトビューエクステント」といい、ライトビュービデオストリームに属するエクステントを「ライトビューエクステント」という。２Ｄ／レフトビューエクステント6702A−Cとライトビューエクステント6703A−Cとは交互に光ディスク6701のトラック6701A上に配置されている。隣接する２つのエクステント6702A−6703A、6702B−6703B、6702C−6703Cの間では再生時間が等しい。このようなエクステントの配置を「インターリーブ配置」という。インターリーブ配置で記録されたエクステント群は、以下に述べるように、３Ｄ映像の再生と２Ｄ映像の再生との両方で利用される。
２Ｄ再生装置6704では、光ディスクドライブ6704Aが光ディスク6701上のエクステントのうち、２Ｄ／レフトビューエクステント6702A−Cのみを先頭から順番に読み出す一方、ライトビューエクステント6703A−Cの読み出しをスキップする。更に、映像デコーダ6704Bが、光ディスクドライブ6704Aによって読み出されたエクステントを順次、映像フレーム6706Lに復号する。それにより、表示装置6707にはレフトビューのみが表示されるので、視聴者には通常の２Ｄ映像が見える。
３Ｄ再生装置6705では、光ディスクドライブ6705Aが光ディスク6701から２Ｄ／レフトビューエクステントとライトビューエクステントとを交互に、符号で表せば、6702A、6703A、6702B、6703B、6702C、6703Cの順に読み出す。更に、読み出された各エクステントから、２Ｄ／レフトビュービデオストリームは左映像デコーダ6705Lへ送られ、ライトビュービデオストリームは右映像デコーダ6705Rへ送られる。各映像デコーダ6705L、6705Rは交互に各ビデオストリームを映像フレーム6706L、6706Rに復号する。それにより、表示装置6708にはレフトビューとライトビューとが交互に表示される。一方、シャッター眼鏡6709は左右のレンズを、表示装置6708による画面の切り換えに同期して交互に不透明にする。従って、シャッター眼鏡6709をかけた視聴者には、表示装置6708に表示された映像が３Ｄ映像に見える。
光ディスクに限らず、記録媒体に３Ｄ映像コンテンツを格納するときは、上記のようにエクステントのインターリーブ配置を利用する。それにより、その記録媒体を２Ｄ映像の再生と３Ｄ映像の再生との両方で利用することができる。
特許第３９３５５０７号公報
光ディスクには、いわゆる二層ディスクのような、記録層を複数含むものがある。そのような光ディスクでは、一連のストリームデータが二層にわたって記録される場合が生じ得る。一方、単層ディスクでも、一連のストリームデータが別のデータを間に挟んで記録される場合がある。それらの場合、光ディスクドライブのピックアップは光ディスクからのデータの読み出し中に、層の切り換えに伴うフォーカスジャンプ、又は、ディスクの半径方向の移動を伴うトラックジャンプを行わねばならない。それらのジャンプは一般にシーク時間が長いので、「ロングジャンプ」と呼ばれる。ロングジャンプの発生にかかわらず映像をシームレスに再生するには、ロングジャンプの直前に読み出されるエクステントのサイズを十分に大きくして、ロングジャンプ中に映像デコーダ内のバッファがアンダーフローを起こさないための条件を満たすようにしなければならない。
図１０４に示されているエクステントのインターリーブ配置において上記の条件を２Ｄ映像と３Ｄ映像との両方の再生について満たすには、ロングジャンプの直前にアクセスされる２Ｄ／レフトビューエクステントを十分に拡大すればよい。しかし、その場合、そのエクステントと再生時間が等しいライトビューエクステントも併せて拡大しなければならない。その結果、右映像デコーダ6705R内に確保されるべきバッファ容量は、上記の条件を満たすのには十分な容量よりも更に大きなものとなる。それは、３Ｄ再生装置6705内のバッファ容量の更なる削減、及びメモリの利用効率の更なる向上を阻むので好ましくない。
そこで、右映像デコーダ6705R内に確保されるべきバッファ容量を必要最小限に抑えるには、例えばロングジャンプの直前又は直後で２Ｄ映像の再生経路と３Ｄ映像の再生経路とを分離することが考えられる。ここで、「映像の再生経路」とは、その映像を表すビデオストリームの各部とその再生順との間の対応関係を意味する。更に、「再生経路の分離」とは、ビデオストリームの再生対象の部分とその複製データとを記録媒体上に記録して、それぞれを異なる再生経路に割り当てることを意味する。２Ｄ映像の再生経路と３Ｄ映像の再生経路とを上記のように分離したとき、２Ｄ映像の再生時と３Ｄ映像の再生時とで、ロングジャンプの直前に読み出されるべき２Ｄ／レフトビューエクステントのサイズを別々に設計できる。従って、右映像デコーダ6705R内に確保されるべきバッファ容量を必要最小限に抑えたまま、２Ｄ映像の再生時と３Ｄ映像の再生時とのいずれでもロングジャンプ中での各映像デコーダ6705L、6705R内のバッファアンダーフローを防止できる。
しかしその反面、記録媒体には、２Ｄ／レフトビュービデオストリームの同じ部分が異なるエクステントに重複して格納される。記録媒体の記録領域を効率的に利用するという観点からは、このような重複の増大を抑えることが望まれる。
本発明の目的は、再生装置内に確保されるべきバッファ容量を削減でき、かつ、異なるエクステントに重複して格納されるデータ量の増大を抑えることができる配置にストリームファイルが記録された記録媒体を提供することである。
上記目的を達成するために、本発明に係る記録媒体は、複数のデータブロックからなるデータストリームと管理情報とが記録された記録媒体であって、前記データストリームは、平面視再生に利用されるメインビュー・ストリームと、前記メインビュー・ストリームと組み合わされて立体視映像の再生に利用されるサブビュー・ストリームとを含み、前記複数のデータブロックは、前記メインビュー・ストリームから構成される複数のメインビュー・データブロックと、前記サブビュー・ストリームから構成される複数のサブビュー・データブロックとを含み、前記管理情報は、平面視再生時に、前記メインビュー・データブロックを参照する２Ｄ管理情報と、立体視再生時に、前記メインビュー・データブロックを参照する３Ｄ管理情報とを含み、前記複数のデータブロックの種類には、共通データブロックと、２Ｄデータブロックと、３Ｄデータブロックとがあり、前記共通データブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記共通データブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報及び３Ｄ管理情報の双方から参照され、前記２Ｄデータブロックは、前記メインビュー・データブロックを含み、前記２Ｄデータブロックに含まれるメインビュー・データブロックは、３Ｄ管理情報からは参照されずに、２Ｄ管理情報から参照され、前記３Ｄデータブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記３Ｄデータブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報からは参照されずに、３Ｄ管理情報から参照され、２Ｄデータブロックは、共通データブロックが記録されている領域に論理アドレスが後続する領域であって、平面視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、３Ｄデータブロックは、２Ｄデータブロックが記録されている領域に論理アドレスが後続する領域であって、立体視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、２Ｄデータブロックに含まれるメインビュー・データブロックと３Ｄデータブロックに含まれるメインビュー・データブロックとは同一の内容であることを特徴とする。
本発明に係る記録媒体は、平面視再生用ファイルと立体視再生用ファイルとで、ロングジャンプの直前に参照するデータブロックが、異なる領域に格納されるため、ロングジャンプの直前で２Ｄ映像の再生経路と３Ｄ映像の再生経路とが分離されている。そのため、ロングジャンプの直前に参照するエクステントのサイズを、平面視再生用と立体視再生用とで独立に設計することができ、立体視映像の再生時に確保されるべきバッファ容量を削減することができる。
更に、２Ｄ映像の再生経路では、ロングジャンプの直前に参照される２Ｄデータブロックが、二種類のファイルに共有されている共通データブロックに連続することで、ロングジャンプの直前に参照される平面視再生用ファイルのエクステントの一部として、この共通データブロックを利用するこができる。その一方で、平面視再生用ファイルにおいてロングジャンプの直前に参照されるエクステントのうち、上述の共通データブロックが立体視再生用ファイルのエクステントしても利用されるため、異なるエクステントに重複して格納されるデータ量の増大を抑えることができる。
また、ロングジャンプ位置の前に、平面視再生用ファイルと立体視再生用ファイルとで同一の内容がひとまとまりで配置されるため、ロングジャンプの後ろで再生経路を分岐するような１対ｎの多重接続のデータ作成が可能となる。
記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。 ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を左目から見た場合の例を示す。 立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。 デプスビュー方式の一例を示す。 デプスモードで生成される立体視画像を示す。 多層化された光ディスクの内部構成を示す。 ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。 第１実施形態に係る記録媒体における内部構成を示す。 PESパケット列に、ビデオストリームがどのように格納されるかを示す。 メインTSがどのように多重化されるかを模式的に示す。 メインTS及びサブTSの内部構成を示す。 ビデオストリームのデータ構造を示す模式図である。 ビデオアクセスユニット内の補足データ領域に格納されるデコードスイッチ情報のデータ構造を示す図である。 デコードカウンタを説明する図である。 メインＴＳ、第１サブＴＳ、及び第２サブＴＳのそれぞれに属するデータ・ブロック群の記録媒体１００上での物理的な配置を示す模式図である。 （ａ）は、あるＢＤ−ＲＯＭディスク上に個別に連続して記録されたメインＴＳ1701とサブＴＳ1702との配置を示す模式図である。（ｂ）は、本発明の実施形態１による記録媒体１００上に交互に記録されたベースビュー・データ・ブロックB[0]、B[1]、B[2]、…とディペンデントビュー・データ・ブロックD[0]、D[1]、D[2]、…との配置を示す模式図である。 （ａ）は、あるＢＤ−ＲＯＭディスク上において隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でビデオ・ストリームの再生時間が異なるときの再生経路を示す模式図である。（ｂ）は、本発明の実施形態１による記録媒体１００上において隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でビデオ・ストリームの再生時間が等しいときの再生経路を示す模式図である。（ｃ）は、本発明の実施形態１による記録媒体１００上において全てのベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でビデオ・ストリームの再生時間が等しいときの再生経路を示す模式図である。 （ａ）、（ｂ）、（ｃ）、（ｄ）、（ｅ）はそれぞれ、ファイル２Ｄ（01000.m2ts）、第１ファイルＤＥＰ（02000.m2ts）、第２ファイルＤＥＰ（03000.m2ts）、第１ファイルＳＳ（01000.ssif）、第２ファイルＳＳ（02000.ssif）の各データ構造を示す模式図である。 図１５に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路2001、Ｌ／Ｒモードでの再生経路2002、及びデプス・モードでの再生経路2003を示す模式図である。 記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第１例を示す模式図である。 図２０に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路を示す模式図である。 あるＢＤ−ＲＯＭディスクの層境界の前後にインターリーブ配置で記録されているデータ・ブロック群と、それに対する各再生モードでの再生経路とを示す模式図である。 配置１を用いて前方プレイアイテムから複数の後方プレイアイテムに分岐してシームレス接続する例を説明する図である。 記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第２例を示す模式図である。 図２４に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路を示す模式図である。 本発明の実施形態１による記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第３例を示す模式図である。 図２６に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路を示す模式図である。 記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第４例を示す模式図である。 図２８に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路を示す模式図である。 記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第５例を示す模式図である。 図３０に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とを示す模式図である。 記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第６例を示す模式図である。 図３２に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とを示す模式図である。 （ａ）は、図２８に示されている配置の第１例からデプスマップ・データ・ブロックを除去したものを示す模式図である。（ｂ）は、（ａ）に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とを示す模式図である。 図２０に示されている配置の第１例からデプスマップ・データ・ブロックを除去したものを示す模式図である。 ＰＭＴのデータ構造を示す模式図である。 ２Ｄクリップ情報ファイルのデータ構造を示す模式図である。 （ａ）は、図３７に示されているエントリ・マップ3030のデータ構造を示す模式図であり、（ｂ）（ｃ）は、ファイル２Ｄに属するソースパケット群3110のうち、エントリ・マップ3030によって各ＥＰ＿ＩＤ3105に対応付けられているものを示す模式図である。 （ａ）は、オフセット・テーブル3041のデータ構造を示す模式図である。（ｂ）は、オフセット・エントリの有効区間を表す模式図である。 （ａ）は、図３０に示されているエクステント起点3042のデータ構造を示す模式図であり、（ｂ）は、ライトビュー・クリップ情報ファイルに含まれるエクステント起点3320のデータ構造を示す模式図であり、（ｃ）は、Ｌ／Ｒモードの再生装置２００によって第１ファイルＳＳ（01000.ssif）から抽出されたベースビュー・データ・ブロックL1、L2、…を表す模式図である。（ｄ）は、第１ファイルＤＥＰ（02000.m2ts）に属するライトビュー・エクステントEXT2[0]、EXT2[1]、…と、エクステント起点3320の示すＳＰＮ3322との間の対応関係を表す模式図である。（ｅ）は、第１ファイルＳＳ544Aに属する３ＤエクステントEXTSS[0]、EXTSS[1]、…と記録媒体１００上のデータ・ブロック群3350との間の対応関係の一例を示す模式図である。 本発明の実施形態１による記録媒体１００上に記録された、３Ｄ映像コンテンツを含むデータ・ブロック群の配置の一例を示す模式図である。 本発明の実施形態１による記録媒体１００における、ベースビュー・ビデオ・ストリーム3510とディペンデントビュー・ビデオ・ストリーム3520とに設定されたエントリ・ポイントの例を示す模式図である。 ATCシーケンス復元手順を示す。 ２Ｄプレイリスト・ファイル（00001.mpls）521のデータ構造を示す模式図である。 図４４に示されているＰＩ＃Ｎのデータ構造を示す模式図である。 （ａ）、（ｂ）はそれぞれ、図４５に示されているコネクション・コンディション3704が「５」、「６」であるときに接続対象の二つの再生区間3801、3802の間の関係を示す模式図である。 図４４に示されている２Ｄプレイリスト・ファイル（00001.mpls）521の示すＰＴＳと、ファイル２Ｄ（01000.m2ts）541から再生される部分との間の対応関係を示す模式図である。 ３Ｄプレイリスト・ファイル（00002.mpls）のデータ構造を示す模式図である。 図４８に示されているＳＴＮテーブルＳＳ4030のデータ構造を示す模式図である。 （ａ）、（ｂ）、（ｃ）はそれぞれ、図４９に示されているディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112、ＰＧストリームのストリーム登録情報列4113、及びＩＧストリームのストリーム登録情報列4114のデータ構造を示す模式図である。 図４８に示されている３Ｄプレイリスト・ファイル（00002.mpls）522の示すＰＴＳと、第１ファイルＳＳ（01000.ssif）から再生される部分との間の対応関係を示す模式図である。 インデックス・ファイル（index.bdmv）内のインデックス・テーブル4410を示す模式図である。 図１に示されている再生装置２００によって３Ｄ映像のタイトルが選択されたときに行われる、再生対象のプレイリスト・ファイルの選択処理のフローチャートである。 図１に示されている再生装置２００の２Ｄ再生モードでの機能ブロック図である。 図５４に示されているプレーヤ変数記憶部4608内のシステム・パラメータの一覧表である。 図５４に示されているシステム・ターゲット・デコーダ4603の機能ブロック図である。 図１に示されている再生装置２００の３Ｄ再生モードでの機能ブロック図である。 図５７に示されているシステム・ターゲット・デコーダ4903の機能ブロック図である。 図５７に示されているプレーン加算部4910の機能ブロック図である。 （ａ）、（ｂ）は、図５９に示されている第２クロッピング処理部5132によるクロッピング処理を示す模式図である。 （ａ）、（ｂ）、（ｃ）はそれぞれ、図６０に示されているクロッピング処理によって生成されたレフトビューとライトビューとのＰＧプレーン、及びそれらから視聴者に知覚される３Ｄ映像を示す模式図である。 図５４に示されている２Ｄ再生モードの再生装置２００内の再生処理系統を示す模式図である。 （ａ）は、図６２に示されている再生処理系統による２Ｄエクステントの再生処理中、リード・バッファ4602に蓄積されるデータ量DAの変化を示すグラフであり、（ｂ）は、それらの２Ｄエクステントを含む３Ｄエクステント・ブロック5510と２Ｄ再生モードでの再生経路5520との間の対応関係を示す模式図である。 本発明の実施形態１によるＢＤ−ＲＯＭディスクに関するジャンプ距離Sjumpと最大ジャンプ時間Tjumpとの間の対応表の一例である。 図５７に示されている３Ｄ再生モードの再生装置２００内の再生処理系統を示す模式図である。 （ａ）、（ｂ）は、図６５に示されている再生処理系統によるＬ／Ｒモードでの３Ｄエクステント・ブロックの再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフであり、（ｃ）は、その３Ｄエクステント・ブロック5810とＬ／Ｒモードでの再生経路5820との間の対応関係を示す模式図である。 （ａ）、（ｂ）は、図６５に示されている再生処理系統によるデプス・モードでの３Ｄエクステント・ブロックの再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフであり、（ｃ）は、その３Ｄエクステント・ブロック5910とデプス・モードでの再生経路5920との間の対応関係を示す模式図である。 図６５に示されている再生処理系統によるＬ／Ｒモードでの再生処理中に生じるロングジャンプJLY、JBDJ1、JBDJ2を示す模式図である。 （ａ）、（ｂ）は、図６５に示されている再生処理系統によって、拡大された最小エクステント・サイズ以上のサイズを持つデータ・ブロック群から成る３Ｄエクステント・ブロックが読み出されるときにおける、各リード・バッファ4921、4922の蓄積データ量DA1、DA2の変化を示すグラフであり、（ｃ）は、その３Ｄエクステント・ブロック6110とＬ／Ｒモードでの再生経路6120との間の対応関係を示す模式図である。 ３つ以上の複数３Ｄエクステントブロックがシームレスに接続するデータ構造を示す図である。 バッファ余裕量の蓄積方法を説明する図である。 Ｌ／Ｒモードでの３Ｄ映像再生におけるリードバッファへのデータ蓄積量の変化を説明する図である。 （ａ）は、配置１のデータをＬ／Ｒモードで再生中に生じるロングジャンプを示す図であり、（ｂ）は、Ｌ／Ｒモードで配置１のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す図である。 （ａ）は、配置１のデータをデプスモードで再生中に生じるロングジャンプを示す図であり、（ｂ）は、デプスモードで配置１のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す図である。 （ａ）は、配置２のデータをＬ／Ｒモードで再生中に生じるロングジャンプを示す図であり、（ｂ）は、Ｌ／Ｒモードで配置２のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す図である。 プレイアイテム同士がシームレス接続する場合のデータ配置方法の条件を説明する図である。 （ａ）は、配置３のデータをデプスモードで再生中に生じるロングジャンプを示す図であり、（ｂ）は、デプスモードで配置３のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す図である。 ２Ｄ／３Ｄ再生装置の３Ｄ映像再生に必要なリードバッファのサイズを削減するためのデータ配置方法を説明する図である。 終端のエクステント群が、式（２）−（５）の最小エクステントサイズを満たすための制約を説明する図である。 Ｌ／Ｒモードでのバッファ余裕量ＵＬ１とＵＬ２のサイズの計算方法を説明する図である。 ３Ｄ映像のマルチアングルの実現方法を説明する図である。 ３Ｄ映像のマルチアングルの実現方法の変形例を説明する図である。 （ａ）は、マルチアングル区間において３Ｄプレイリストのプレイアイテム及びサブプレイアイテムが参照するストリームファイルを示す図であり、（ｂ）は、各アングル映像のストリームファイルが記録された記録領域のデータアロケーションを説明する図である。 アングル１からアングル３に切り替えた場合の再生経路を説明する図である。 （ａ）は、本発明の実施形態１によるＢＤ−ＲＯＭディスク上で、多重化ストリーム・データのみを含むインターリーブ配置のデータ・ブロック群を示す模式図であり、（ｂ）は、そのＢＤ−ＲＯＭディスク上で、他のファイルに属するエクステントを含むインターリーブ配置のデータ・ブロック群を示す模式図である。 エクステント間にＡＶストリームとは別のファイルを格納するために好適なエクステントの配置方法を説明する図である。 インターリーブされたＡＶストリームのエクステント間に別ファイルを格納するためのサイズの条件を説明する図である。 リードバッファを１つで構成する場合の２Ｄ／３Ｄ再生装置の構成を説明する図である。 リードバッファを１つで構成する場合のシステムターゲットデコーダの構成を説明する図である。 第１リード・バッファ4921と第２リード・バッファ4922とのデータ蓄積量の推移と、１つのリードバッファの構成にした場合のリードバッファのデータ蓄積量の推移を示す図である。 リードバッファを１つの構成にした場合のリードバッファ（１）の内部に蓄積されるデータの推移を模式的に示す図である。 リードバッファを１つに構成する場合のＡＶストリーム内のソースパケットのＡＴＳの構成を示す図である。 本発明の実施形態３による記録装置の内部構成を示すブロック図である。 （ａ）、（ｂ）は、本発明の実施形態３による記録装置において、３Ｄ映像の一シーンの表示に利用される左映像ピクチャと右映像ピクチャとを表す模式図であり、（ｃ）は、ビデオエンコーダ6301によってそれらのピクチャから算出された奥行き情報を示す模式図である。 2D/3D再生装置を集積回路を用いて実現した構成例である。 ストリーム処理部の代表的な構成を示す機能ブロック図である。 切替部がDMACであった場合の切替部５３周辺の概念図である。 AV出力部の代表的な構成を示す機能ブロック図である。 AV出力部もしくは再生装置のデータ出力部分を詳細に示した構成例である。 集積回路における制御バス及びデータバスの配置を示した図である。 集積回路における制御バス及びデータバスの配置を示した図である。 再生装置における動作手順を簡単に示したフローチャートである。 再生装置における動作手順を詳細に示したフローチャートである。 ３Ｄ映像コンテンツが記録された光ディスクについて、２Ｄ再生装置に対する互換性を確保するための技術を示す模式図である。
以下、本発明の好適な実施形態に係る記録媒体及び再生装置について、図面を参照しながら説明する。
＜実施形態１＞
先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目とでは、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、１つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
上記の何れの方式においても、立体視映像は、少なくとも2つの視点映像から構成される。視点映像とは、何等かの偏向性をもった映像のことであり、少なくとも2つの視点映像のうち1つを“メインビュー映像”といい、メインビューに準ずる偏向性をもつ視点映像を“サブビュー”という。そしてメインビュー、サブビューがそれぞれ、ビデオストリームによって記録媒体から供給される場合、メインビューを供給するビデオストリームを“メインビュービデオストリーム”という。サブビューを供給するビデオストリームを“サブビュービデオストリーム”という。以降の説明で登場する記録媒体は、これらのメインビュービデオストリーム、サブビュービデオストリームを好適に記録するためのものである。
また本願明細書における再生装置は、上述したメインビュービデオストリーム、サブビュービデオストリームを再生するため、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方式によるものが最良であると考えられるので、以降の説明では、“メインビュービデオストリーム”が“ベースビュービデオストリーム”であり、“サブビュービデオストリーム”が“ディペンデントビュービデオストリーム”であるとして説明を行う。
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プレゼンテーションモードには、Ｌ画像、Ｒ画像を用いて立体視効果を実現する3D-LR方式の他、2D画像と、深度情報とを用いて立体視効果を実現する3D-Depth方式がある。
3D-Depth方式とは、ビデオデコーダの後段に、視差映像生成器を組み入れて、ビデオストリームにおける個々のピクチャデータと、このピクチャデータにおける個々の画素の深度情報とからレフトビューピクチャデータ、ライトビューピクチャデータを作り出させるモードである。
この深度情報は、画素の深度を濃淡で表すグレースケールのピクチャデータ(深度情報ピクチャデータと呼ばれる)として構成することができる。
図４は、デプスビュー方式の一例を示す。同図（ａ）は、2D画像であり、同図（ｂ）は、（ａ）に示した2Dに対して作成されたグレースケールを示す。グレースケールは、輝度成分のみの画素によって表現される。グレースケールの画素のうち、輝度が高いもの程(白いもの程)、奥行きが浅く、輝度が低いもの程(黒いもの程)、奥行きが深いことを示す。同図（ｃ）、（ｄ）は、グレースケールを用いることで生成される左目映像、右目映像を示す。図５は、3D-Depthモードで生成される立体視画像を示す。2Dの各フレーム毎に、左目映像、右目映像を生成すれば、ゴーグルを通じて左目映像、右目映像を見ることで、ユーザは立体視を楽しむことができる。
3D-Depth方式では、2D再生可能なビデオストリームがベースビュービデオストリームになる。グレースケールのピクチャデータから構成されるビデオストリームが、ディペンデントビュービデオストリームになる。
この3D-Depth方式において利用するグレースケールのピクチャデータをデジタル化し、圧縮符号化することにより得られるビデオストリームを、デプスマップストリームという。デプスマップストリームは、時間方向の相関特性を利用したピクチャ間予測符号化によって圧縮され、視点間の相関を持たないビデオストリームであるが、ビデオストリームのフォーマットは、3D-LR方式で用いるディペンデントビュービデオストリームと同じにしておく。例えば、レフトビュービデオストリーム及びライトビュービデオストリームがＭＶＣフォーマットで符号化されている場合は、デプスマップストリームも同様にＭＶＣフォーマットでエンコードする。このような構成にすることで、3D-LR方式と3D-Depth方式との再生の切り替えを、再生装置の構成を変えることなくスムーズに行うことができる。
以下、3D-LR方式を用いたB−DプレゼンテーションモードをＬ／Ｒモードとし、3D-Depth方式を用いたB−Dプレゼンテーションモードをデプスモードとする。デプスモードと、Ｌ／Ｒモードとでは、ベースビュービデオストリームは共通化することができるため、ベースビュービデオストリームに組合せるべきビデオストリームを変化させれば、Ｌ／Ｒモード、デプスモードの映像を生成することができる。データ管理構造からこれらの組み合わせを扱い、プレーヤおよび接続されているテレビ側の特性に合わせて、表示方法を切り替える。

＜記録媒体１００＞
本発明に係る記録媒体は、多層化された光ディスクである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と同じように記録されている論理データをディレクトリ／ファイル構造を使って読み出すことが可能になっている。
第４段目は、ファイルシステムで管理されるパーティション領域の記録内容を示す。パーティション領域には、ファイルを構成するエクステントが存在する。エクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。
パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成される。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、各ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
各ディレクトリ領域に含まれる「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
このように各ディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。以上がディレクトリファイルについての説明である。続いて、下位ファイルについてのファイル記録領域の詳細について説明する。
各ディレクトリ領域に含まれる「下位ファイルについてのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、ファイルエントリにより管理される1つ以上の「エクステント」とが記録されている。また、あるディレクトリの配下に複数の下位ファイルが含まれる場合には、ディレクトリ領域には複数の「下位ファイルについてのファイル記録領域」が存在することになる。
下位ファイルの「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す"261"が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
下位ファイルにおける「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号（LBN）と、エクステント長を示すデータを含む。ただしエクステント長を示すデータの上位２ビットは、“00”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“01”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“11”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
UDFにおけるファイルは、ファイルエントリーによって管理されている複数のエクステントから構成され、上述したようなファイルエントリーのアロケーション識別子を参照することで、ファイルを構成するエクステントの論理アドレスを知得することができる。
例えば、本願の主眼となるストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。

図７は、ファイルシステムを前提にした記録媒体１００のアプリケーションフォーマットを示す。
BDMVディレクトリはBD-ROMで扱うTSや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」，「MovieObject.bdmv」の２種類のファイルが配置されている。
以下に、BDMVディレクトリ配下に置かれる各ファイルについて説明する。
「index.bdmv(ファイル名固定)」は、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BD-Jオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納しているインデックステーブルファイルである。
インデックステーブルファイルは記録媒体全体に関する管理情報であり、再生装置への挿入後に、インデックステーブルファイルが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルファイルは、光ディスクのタイトル構造を構成する個々のタイトルと、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。タイトル構造とは、光ディスクの装填時に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を伴うタイトル(ファーストプレイタイトル)の再生を開始し、ファーストプレイタイトルの再生後、映画作品の本編を構成する一般タイトル("１"、"２"、"３"というようなシリアル番号で識別される一般的なタイトル)の再生を行い、本編タイトルの再生が終了すれば、タイトル選択を受け付けるタイトル(メニュータイトル)を再生してユーザによる一般タイトルの選択待ちを行うというものである。映画作品と、タイトルとの関係は、映画作品と、それの複数バージョンとの関係である。つまり1つのバージョンしかないような映画作品は、「映画作品＝タイトル」という関係になる。映画作品に、劇場公開版、ディレクターズカット版、TV放映版等、複数のバージョンがある場合、映画作品における個々のバージョンが1つのタイトルになる。再生装置には、カレントのタイトル番号を格納するタイトル番号レジスタを含み、複数のタイトルのうち、このタイトル番号レジスタに格納されているものが、現在の再生対象になる。光ディスクのタイトルは、上述したようなファーストプレイタイトル、一般タイトル、メニュータイトルのそれぞれに、動作モードを規定する動作モードオブジェクトを割り当てることで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。インデックステーブルでは、タイトルと、ビデオストリームとの関係を直接記述せず、タイトルと、動作モードオブジェクトとの関係を記述して、動作モードオブジェクトを通じてビデオストリームを再生させるようになっている。これば、AV再生を伴わず、動作モードオブジェクトを動作させるだけのタイトルを規定するためである。
「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プログラム、及び、データから、アプリケーションは構成されることになる。

「STREAMディレクトリ」は、ストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts(["xxxxx"は可変、拡張子"m2ts"は固定])、及びxxxxx.ssif(["xxxxx"は可変、拡張子"ssif"は固定])という形式でストリームファイルが格納される。本実施形態におけるストリームファイルは、記録媒体１００上に記録された映像コンテンツの実体のうち、ファイルシステムの定めるファイル形式に整えられたものをいう。ここで、映像コンテンツの実体は一般に、映像・音声・字幕等を表す各種のストリームデータが多重化されたストリームデータを意味する。この多重化ストリーム・データは内蔵のプライマリ・ビデオ・ストリームの種類に依って、メイン・トランスポート・ストリーム（ＴＳ）とサブＴＳとに大別される。「メインＴＳ」はプライマリ・ビデオ・ストリームとしてベースビュー・ビデオ・ストリームを含む。「ベースビュー・ビデオ・ストリーム」は単独で再生可能であり、２Ｄ映像を表す。「サブＴＳ」はプライマリ・ビデオ・ストリームとしてディペンデントビュー・ビデオ・ストリームを含む。「ディペンデントビュー・ビデオ・ストリーム」は、その再生にベースビュー・ビデオ・ストリームを必要とし、そのベースビュー・ビデオ・ストリームとの組み合わせで３Ｄ映像を表す。ディペンデントビュー・ビデオ・ストリームの種類には、ライトビュー・ビデオ・ストリーム、レフトビュー・ビデオ・ストリーム、及びデプスマップ・ストリームがある。「ライトビュー・ビデオ・ストリーム」は、ベースビュー・ビデオ・ストリームの表す２Ｄ映像がＬ／Ｒモードの再生装置によって３Ｄ映像のレフトビューとして利用されるとき、その３Ｄ映像のライトビューを表すビデオ・ストリームとして利用される。「レフトビュー・ビデオ・ストリーム」はその逆である。「デプスマップ・ストリーム」は、ベースビュー・ビデオ・ストリームの表す２Ｄ映像がデプス・モードの再生装置によって仮想的な２Ｄ画面への３Ｄ映像の射影として利用されるとき、その３Ｄ映像のデプスマップを表すストリーム・データとして利用される。
ＡＶストリーム・ファイルは内蔵の多重化ストリーム・データの種類に依って、ファイル２Ｄ、ファイル・ディペンデント（以下、ファイルＤＥＰと略す。）、及びインターリーブ・ファイル（以下、ファイルＳＳと略す。）の三種類に分けられる。「ファイル２Ｄ」は２Ｄ再生モードでの２Ｄ映像の再生に利用される平面視再生用ストリームファイルであり、メインＴＳを含む。「ファイルＤＥＰ」はサブＴＳを含む。「ファイルＳＳ」は、３Ｄ再生モードでの３Ｄ映像の再生に利用される立体視再生用ストリームファイルであり、同じ３Ｄ映像を表すメインＴＳとサブＴＳとの対を含む。ファイルＳＳは特に、そのメインＴＳをいずれかのファイル２Ｄと共有し、そのサブＴＳをいずれかのファイルＤＥＰと共有する。すなわち、記録媒体１００のファイルシステムでは、メインＴＳはファイルＳＳとファイル２Ｄとのいずれとしてもアクセス可能であり、サブＴＳはファイルＳＳとファイルＤＥＰとのいずれとしてもアクセス可能である。このように、記録媒体１００上に記録された一連のデータを異なるファイルに共有させ、いずれのファイルとしてもアクセス可能にする仕組みを「ファイルのクロスリンク」という。このようなファイル２ＤとファイルＤＥＰとは、m2tsという拡張子を付して、ＳＴＲＥＡＭディレクトリの直下に置かれ、ファイルＳＳは、ssifという拡張子を付して、ＳＴＲＥＡＭディレクトリの下位ディレクトリであるＳＳＩＦディレクトリの直下に置かれる。

「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls["xxxxx"は可変、拡張子"mpls"は固定])が存在する。プレイリスト情報ファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。"プレイリスト"とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの"型"を定義する。プレイリスト情報によって定義される再生経路は、いわゆる"マルチパス"である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。メインパスに含まれる再生区間を、プレイアイテムと呼び、サブンパスに含まれる再生区間は、サブプレイアイテムと呼ぶ。メインパスは1本であるのに対して、サブパスは、複数本定義することができ、これら複数のサブパスは、サブパスIDと呼ばれる識別子によって識別される。かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。BD-Jモードでは、再生制御のためのJava(登録商標)アプリケーションが、このプレイリスト情報を再生するJMF(Java(登録商標)Media Frame work)プレーヤインスタンスの生成をJava(登録商標)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMFプレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。HDMVモードでは、プレイリストによる再生を命じるナビゲーションコマンドを再生装置に実行させることで、再生を開始することができる。再生装置には、カレントのプレイリスト情報の番号を格納するプレイリスト番号レジスタを含み、複数のプレイリスト情報のうち、このプレイリスト番号レジスタに格納されているものが、現在の再生対象になる。プレイリスト情報ファイルの種類には２Ｄプレイリスト情報ファイルと３Ｄプレイリスト情報ファイルとがある。「２Ｄプレイリスト情報ファイル」はファイル２Ｄの再生経路を規定する。「３Ｄプレイリスト情報ファイル」は、２Ｄ再生モードの再生装置に対してはファイル２Ｄの再生経路を規定し、３Ｄ再生モードの再生装置に対してファイルＳＳの再生経路を規定する。

「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi ["xxxxx"は可変、拡張子"clpi"は固定])が存在する。クリップ情報ファイルは、ファイル２Ｄ及びファイルＤＥＰのそれぞれと一対一の割合で存在するクリップ情報ファイルであり、ストリームファイル内に存在するソースパケット列がどのような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パケットは、再生装置内に存在するデコーダの連続的なデコード処理に供されることになる。
またストリームファイルに格納されるパケット列は、複数種別の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ストリームを構成する。

＜ビデオストリーム＞
図１２は、ビデオストリームのデータ構造を示す模式図である。
ビデオストリームは、複数のＧＯＰから構成されており、これを符合化処理の基本単位とすることで動画像の編集やランダムアクセスが可能となっている。ＧＯＰは、１つ以上のビデオアクセスユニットにより構成されている。ビデオアクセスユニットは、符合化されたピクチャデータを格納する単位であり、フレーム構造の場合は１フレーム、フィールド構造の場合の１フィールドのデータが格納される。ＧＯＰ先頭のビデオアクセスユニットはＩピクチャのデータが格納され、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータが格納される。シーケンスヘッダは、当該ＧＯＰで共通の情報を格納したヘッダであり、解像度、フレームレート、アスペクト比、ビットレートなどの情報が格納される。ピクチャヘッダはピクチャ全体の符合化方式等、ピクチャの復号に必要な情報を格納したヘッダである。補足データは圧縮データの復号に必須ではない付加情報であり、例えば、映像と同期してＴＶに表示するクローズドキャプションの文字情報やタイムコード情報などがある。圧縮ピクチャデータは圧縮符合化されたピクチャデータである。ＧＯＰ先頭以外のビデオアクセスユニットは、シーケンスヘッダを含まない点を除いて、ＧＯＰ先頭のビデオアクセスユニットと同様にピクチャヘッダ、補足データ、圧縮ピクチャデータが格納される。また、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータの中身の構成は、ビデオの符合化方式によって異なる。例えば、ＭＰＥＧ−４ ＡＶＣの場合であれば、シーケンスヘッダはＳＰＳ（シーケンスパラメータセット）に、ピクチャヘッダはＰＰＳ（ピクチャパラメータセット）に、補足データはＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）に相当する。
ベースビュービデオストリーム、ディペンデントビュービデオストリームの何れも、ここで説明したＧＯＰ構造を持つ。ベースビュービデオストリームの先頭ピクチャは、IDRピクチャもしくはNon-IDR Iピクチャであり、ディペンデントビュービデオストリームの先頭ピクチャは、ディペンデントビュービデオストリームがライトビュービデオストリームであれば、ベースビュービデオストリームの対応するＧＯＰ先頭ピクチャと供に３Ｄ映像の同じフレーム又はフィールドを表すライトビューピクチャであって、ベースビュービデオストリームのＧＯＰ先頭ピクチャと同じＰＴＳが付与されたライトビュービデオストリームのピクチャである。また、ディペンデントビュービデオストリームがデプスマップストリームであれば、ディペンデントビュービデオストリームの先頭ピクチャは、ベースビュービデオストリームの対応するＧＯＰ先頭ピクチャに対するデプスマップを格納したピクチャであり、ベースビュービデオストリームのＧＯＰ先頭ピクチャと同じＰＴＳが付与されたデプスマップストリームのピクチャである。ベースビュービデオストリームとディペンデントビュービデオストリームとの間で、ＰＴＳが等しく、かつＤＴＳが等しいピクチャを含むＶＡＵの対を「３Ｄ・ＶＡＵ」という。同じ３Ｄ・ＶＡＵに属するベースビュービデオストリームとディペンデントビュービデオストリームとの対応するＧＯＰでは、シーケンスヘッダのフレームレート、解像度、アスペクト比に同じ値が設定される。
図１３は、ビデオアクセスユニット内の補足データ領域に格納されるデコードスイッチ情報のデータ構造を示す図である。デコードスイッチ情報は、再生装置内のデコーダに、次に復号すべきビデオアクセスユニットを容易に特定させるための情報であり、ベースビュービデオストリームとディペンデントビュービデオストリームとの両方で各ビデオアクセスユニットに含まれる。ここで、そのデコーダは後述のように、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとをビデオアクセスユニット単位で交互に復号する。そのとき、そのデコーダは一般に、各ビデオアクセスユニットに付与されたＤＴＳの示す時刻に合わせて、次に復号すべきＶＡＵを特定する。しかし、デコーダの種類には、ＤＴＳを無視してビデオアクセスユニットを順次、復号し続けるものも多い。そのようなデコーダにとって、各ビデオアクセスユニットがＤＴＳに加えてデコードスイッチ情報を含むことは好ましい。
図１３の上段は、デコードスイッチ情報の構造を示しており、図１３の下段は１つのビデオアクセスユニットのデータ構造を示している。デコードスイッチ情報は、ビデオアクセスユニット毎に、ビデオアクセスユニット内の補足データ領域（ＭＰＥＧ−４ ＡＶＣの場合はＳＥＩ）に格納される。
デコードスイッチ情報は、次アクセスユニットタイプと次アクセスユニットサイズ、及びデコードカウンタから構成されている。
次アクセスユニットタイプは、次にデコードするビデオアクセスユニットがベースビュービデオストリームとディペンデントビュービデオストリームとのどちらなのかを示す情報である。値が「１」の場合はベースビュービデオストリームのビデオアクセスユニットを示し、値が「２」の場合はディペンデントビュービデオストリームのビデオアクセスユニットを示し、「０」の場合は現在のビデオアクセスユニットがストリーム終端に位置し、次に復号されるべきビデオアクセスユニットが存在しないことを示す。
次アクセスユニットサイズは、次にデコードするビデオアクセスユニットのサイズ情報である。もし、次にデコードするビデオアクセスユニットのサイズが不明であるならば、デコード前のビデオアクセスユニットが格納されたバッファからビデオアクエスユニットを引き抜く際に、アクセスユニットの構造を解析してサイズを特定する必要が生じる。しかし、次アクセスユニットサイズがあることで、ビデオデコーダは次のビデオアクセスユニットの構造を解析することなくサイズを特定できる。そのため、デコーダは、デコード前のピクチャを含むビデオアクセスユニットを、バッファから容易に抽出できる。
デコードカウンタは、図１４（ａ）に示すようにベースビュービデオストリームのＧＯＰ先頭のＩピクチャを０としたときに、ベースビュービデオストリームとディペンデントビュービデオストリームとのビデオアクセスユニットをデコード順にインクリメントしたカウンタの値である。
この情報を使えば、何かの原因でビデオアクセスユニットが読めなかったときのエラー処理を適切に行うことができる。例えば、図１４（ａ）のようにベースビュービデオストリームの３番目のビデオアクセスユニット（Ｂｒピクチャ）が、読み込みエラーで読めなかったとすると、何も情報がない場合、ディペンデントビュービデオストリームの３番目のビデオアクセスユニット（Ｂピクチャ）は、ベースビュービデオストリームの３番目のビデオアクセスユニットを参照するため、誤ったデコードを行いノイズののった画像をデコードしてしまう可能性がある。このときに、ディペンデントビュービデオストリームの２番目のビデオアクセスユニット（Ｐピクチャ）のデコードカウンタの値を保持しておけば、次に来るべきアクセスユニットのデコードカウンタの値を予測できるため、デコーダは適切なエラー処理を行うことができる。図１４（ａ）の例では、ディペンデントビュービデオストリームの２番目のビデオアクセスユニット（Ｐピクチャ）のデコードカウンタ４は「４」であるため、次に来るべきデコードカウンタは「５」であるはずだが、実際には読み込めるビデオアクセスユニットはベースビュービデオストリームの４番目のビデオアクセスユニット（Ｐピクチャ）でデコードカウンタは「７」になっている。このため、ビデオデコーダでは、ビデオアクセスユニットをひとつスキップしたことが判断できる。これにより、例えば、ディペンデントビュービデオストリームの３番目のビデオアクセスユニット（Ｂピクチャ）は参照先のピクチャが無いと判断してデコードをスキップする、といった処理を行うことができる。
なお、図１４（ｂ）のようにデコードカウンタを映像ビデオストリーム毎に完結する値にしても良い。この場合も、直前にデコードしたのがベースビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタと同じであると予測できる。直前にデコードしたのがディペンデントビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタに１足したものと同じであると予測できるため、同様に適切なエラー処理を行うことができる。

＜多重化ストリーム・データのインターリーブ配置＞
３Ｄ映像のシームレス再生には、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの記録媒体１００上での物理的な配置が重要である。ここで、「シームレス再生」とは、多重化ストリーム・データから映像と音声とを途切れさせることなく滑らかに再生することをいう。
図１５は、メインＴＳ、第１サブＴＳ、及び第２サブＴＳのそれぞれに属するデータ・ブロック群の記録媒体１００上での物理的な配置を示す模式図である。「データ・ブロック」とは、記録媒体１００上の連続領域、すなわち物理的に連続する複数のセクタに記録された一連のデータをいう。記録媒体１００では物理アドレスが論理アドレスと実質的に等しいので、各データ・ブロック内ではＬＢＮも連続している。従って、再生装置２００のＢＤ−ＲＯＭドライブは一つのデータ・ブロックを、光ピックアップにシークを行わせることなく連続して読み出すことができる。以下、メインＴＳに属するデータ・ブロックL1、L2、L3、…を「ベースビュー・データ・ブロック」といい、サブＴＳに属するデータ・ブロックR1、R2、R3、…、D1、D2、D3、…を「ディペンデントビュー・データ・ブロック」という。特に、第１サブＴＳに属するデータ・ブロックR1、R2、R3、…を「ライトビュー・データ・ブロック」といい、第２サブＴＳに属するデータ・ブロックD1、D2、D3、…を「デプスマップ・データ・ブロック」という。図１５を参照するに、データ・ブロック群は記録媒体１００上のトラック1601に沿って連続的に記録されている。更に、ベースビュー・データ・ブロックL1、L2、L3、…、ライトビュー・データ・ブロックR1、R2、R3、…、及びデプスマップ・データ・ブロックD1、D2、D3、…が一つずつ交互に配置されている。このようなデータ・ブロック群の配置を「インターリーブ配置」という。
本発明の実施形態１によるインターリーブ配置では、隣接する三種類のデータ・ブロックの間でエクステントＡＴＣ時間が等しい。例えば図１５では、先頭のデプスマップ・データ・ブロックD1、先頭のライトビュー・データ・ブロックR1、及び、先頭のベースビュー・データ・ブロックL1が連続している。それらのデータ・ブロックD1、R1、L1間ではエクステントＡＴＣ時間が等しい。ここで、「ＡＴＣ（Arrival Time Clock）」は、ＡＴＳの基準とされるべきクロックを意味する。また、「エクステントＡＴＣ時間」はＡＴＣの値で定義され、一つのエクステント内のソースパケットに付与されたＡＴＳの範囲、すなわち、そのエクステントの先頭のソースパケットのＡＴＳから次のエクステントの先頭のソースパケットのＡＴＳまでの時間間隔を表す。すなわち、エクステントＡＴＣ時間は、そのエクステント内のソースパケットを全て、再生装置２００内でリード・バッファからシステム・ターゲット・デコーダへ転送するのに要する時間に等しい。尚、「リードバッファ」は再生装置２００内のバッファメモリであり、記録媒体１００から読み出されたデータ・ブロックをシステム・ターゲット・デコーダに送るまでの間、一時的に格納する。
エクステントＡＴＣ時間の等しい三種類のデータ・ブロック間では更に、再生期間が一致し、かつビデオ・ストリームの再生時間が等しくてもよい。例えば図１５では、先頭の三つのデータ・ブロックD1、R1、L1間で、再生期間が一致し、かつビデオ・ストリームの再生時間が等しい。後続のデータ・ブロック群でも同様に、エクステントＡＴＣ時間の等しい三種類のデータ・ブロックD2、R2、L2間では、再生期間が一致し、かつビデオ・ストリームの再生時間が等しくてもよい。
本発明の実施形態１によるインターリーブ配置では更に、エクステントＡＴＣ時間の等しい三つの連続するデータ・ブロックは、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックの順に、すなわちデータ量の小さい順に配置されている。例えば図１５では、先頭のライトビュー・データ・ブロックR1に含まれるピクチャは、先頭のベースビュー・データ・ブロックL1に含まれるピクチャを参照ピクチャとして圧縮されている。従って、先頭のライトビュー・データ・ブロックR1のサイズSext2[1]は先頭のベースビュー・データ・ブロックL1のサイズSext1[1]以下である：Sext2[1]≦Sext1[1]。一方、デプスマップの画素当たりのデータ量、すなわち奥行き値のビット数は一般に、ベースビュー・ビデオ・ストリームに含まれるピクチャの画素当たりのデータ量、すなわち色座標値とα値とのビット数の和よりも小さい。更に、メインＴＳは第２サブＴＳとは異なり、プライマリ・ビデオ・ストリームの他にもプライマリ・オーディオ・ストリーム等のエレメンタリ・ストリームを含む。従って、図１５では先頭のデプスマップ・データ・ブロックD1のサイズSext3[1]は先頭のベースビュー・データ・ブロックL1のサイズSext1[1]以下である：Sext3[1]≦Sext1[1]。それ故、図１５では、先頭のデプスマップ・データ・ブロックD1、先頭のライトビュー・データ・ブロックR1、及び先頭のベースビュー・データ・ブロックL1がその順で配置されている。次に連続する三つのエクステントD2、R2、L2の順序も同様である。
エクステントＡＴＣ時間の等しいデータ・ブロックの各先頭に位置するＶＡＵは同じ３Ｄ・ＶＡＵに属し、特に、同じ３Ｄ映像を表すＧＯＰの先頭のピクチャを含む。例えば図１５では、エクステントＡＴＣ時間の等しい三つの連続するデータ・ブロックDn、Rn、Ln（n＝1、2、3、…）のうち、デプスマップ・データ・ブロックDnの先端はデプスマップ・ストリームのＩピクチャを含み、ライトビュー・データ・ブロックRnの先端はライトビュー・ビデオ・ストリームのＰピクチャを含み、ベースビュー・データ・ブロックLnの先端はベースビュー・ビデオ・ストリームのＩピクチャを含む。そのデプスマップ・ストリームのＩピクチャは、そのベースビュー・ビデオ・ストリームのＩピクチャの表す２Ｄ映像に対するデプスマップを表す。そのライトビュー・ビデオ・ストリームのＰピクチャは、そのベースビュー・ビデオ・ストリームのＩピクチャの表す２Ｄ映像をレフトビューとするときのライトビューを表す。特にそのＰピクチャは、そのベースビュー・ビデオ・ストリームのＩピクチャを参照ピクチャとして圧縮されている。従って、３Ｄ再生モードの再生装置２００は、いずれのデータ・ブロックの組Dn、Rn、Lnからも３Ｄ映像の再生を開始できる。
＜多重化ストリーム・データをデータ・ブロックに分割する意義＞
再生装置２００は、記録媒体１００から３Ｄ映像をシームレスに再生するには、メインＴＳとサブＴＳとをパラレルに処理しなければならない。しかし、その処理に利用可能なリード・バッファの容量は一般に限られている。特に、記録媒体１００からリード・バッファへ連続して読み込むことのできるデータ量には限界がある。従って、再生装置２００はメインＴＳとサブＴＳとを、エクステントＡＴＣ時間の等しい部分の対に分割して読み出さねばならない。
図１６の（ａ）は、あるＢＤ−ＲＯＭディスク上に個別に連続して記録されたメインＴＳ1701とサブＴＳ1702との配置を示す模式図である。再生装置２００がそれらのメインＴＳ1701とサブＴＳ1702とをパラレルに処理するとき、図１６の（ａ）に実線の矢印（１）−（４）で示されているように、ＢＤ−ＲＯＭドライブはメインＴＳ1701とサブＴＳ1702とを交互に、エクステントＡＴＣ時間の等しい部分ずつ読み出す。そのとき、ＢＤ−ＲＯＭドライブ121は、図１６の（ａ）に破線の矢印で示されているように、読み出し処理の途中でＢＤ−ＲＯＭディスク上の読み出し対象領域を大きく変化させなければならない。例えば矢印（１）の示すメインＴＳ1701の先端部分が読み出された時、ＢＤ−ＲＯＭドライブ121は光ピックアップによる読み出し動作を一旦停止し、ＢＤ−ＲＯＭディスクの回転速度を上げる。それにより、矢印（２）の示すサブＴＳ1702の先端部分が記録されたＢＤ−ＲＯＭディスク上のセクタを速やかに光ピックアップの位置まで移動させる。このように、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。図１６の（ａ）に示されている破線の矢印は、読み出し処理の途中で必要な各ジャンプの範囲を示す。各ジャンプの期間中光ピックアップによる読み出し処理は停止し、デコーダによる復号処理のみが進行する。その結果、読み出し処理を復号処理に間に合わせることが難しいので、シームレス再生を確実に持続することが難しい。
図１６の（ｂ）は、本発明の実施形態１による記録媒体１００上に交互に記録されたベースビュー・データ・ブロックB[0]、B[1]、B[2]、…とディペンデントビュー・データ・ブロックD[0]、D[1]、D[2]、…との配置を示す模式図である。図１６の（ｂ）を参照するに、メインＴＳとサブＴＳとはそれぞれ、複数のデータ・ブロックに分割されて交互に配置されている。その場合、再生装置２００は３Ｄ映像の再生時、図１６の（ｂ）に矢印（１）−（４）で示されているように、データ・ブロックB[0]、D[0]、B[1]、D[1]、…を先頭から順番に読み出す。それだけで、再生装置２００はメインＴＳとサブＴＳとを交互に読み出すことをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、３Ｄ映像のシームレス再生が確実に持続可能である。
＜隣接するデータ・ブロック間でエクステントＡＴＣ時間を揃える意義＞
図１５に示されているインターリーブ配置では、隣接する三種類のデータ・ブロックDn、Rn、Lnがいずれも同じエクステントＡＴＣ時間を持つ。すなわち、それらのエクステント間では各エクステントの先頭のソースパケットから次のエクステントの先頭のソースパケットまでのＡＴＳの差が等しい（但し、その差の計算では、ＡＴＳにラップ・アラウンドが発生することが考慮されている）。その場合、再生装置２００内のシステム・ターゲット・デコーダはリード・バッファから、ＡＴＣで計られる同じ時間内に、ベースビュー・データ・ブロックLnとディペンデントビュー・データ・ブロックDn又はRnとの両方に含まれる全てのＴＳパケットを取り出す。従って、特に飛び込み再生時において、システム・ターゲット・デコーダはベースビュー・ストリームとディペンデントビュー・ストリームとの間でＴＳパケットの復号処理を容易に同期させることができる。
＜再生時間の等しいデータ・ブロックを隣接させる意義＞
図１７の（ａ）は、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でエクステントＡＴＣ時間が異なり、かつビデオ・ストリームの再生時間が異なるときの再生経路を示す模式図である。図１７の（ａ）に示されている例では、先頭のベースビュー・データ・ブロックB[0]の再生時間は４秒間であり、先頭のディペンデントビュー・データ・ブロックD[0]の再生時間は１秒間である。ここで、ディペンデントビュー・データ・ブロックD[0]の復号に必要なベースビュー・ビデオ・ストリームの部分は、そのディペンデントビュー・データ・ブロックD[0]と同じ再生時間を持つ。従って、再生装置２００内のリード・バッファの容量を節約するには、図１７の（ａ）に矢印1810で示されているように、再生装置２００にベースビュー・データ・ブロックB[0]とディペンデントビュー・データ・ブロックD[0]とを交互に同じ再生時間ずつ、例えば１秒間ずつ読み込ませることが好ましい。しかし、その場合、図１７の（ａ）に破線で示されているように、読み出し処理の途中でジャンプが生じる。その結果、読み出し処理を復号処理に間に合わせることが難しいので、シームレス再生を確実に持続することが難しい。
図１７の（ｂ）は、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でビデオ・ストリームの再生時間が等しいときの再生経路を示す模式図である。本発明の実施形態１による記録媒体１００上では、図１７の（ｂ）に示されているように、隣接する一対のデータ・ブロックの間でビデオ・ストリームの再生時間が等しい。例えば、先頭のベースビュー・データ・ブロックB[0]とディペンデントビュー・データ・ブロックD[0]との対ではビデオ・ストリームの再生時間が共に１秒に等しく、二番目のデータ・ブロックの対B[1]、D[1]ではビデオ・ストリームの再生時間が共に０．７秒に等しい。その場合、再生装置２００は３Ｄ映像の再生時、図１７の（ｂ）に矢印1820で示されているように、データ・ブロックB[0]、D[0]、B[1]、D[1]、…を先頭から順番に読み出す。それだけで、再生装置２００はメインＴＳとサブＴＳとを交互に同じ再生時間ずつ読み出すことをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、３Ｄ映像のシームレス再生が確実に持続可能である。
尚、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でエクステントＡＴＣ時間が等しければ、それらのデータ・ブロック間で再生期間が一致していなくても、更にビデオ・ストリームの再生時間が等しくなくてもよい。その場合でも、図１７の（ｂ）に示されているものと同様に、再生装置２００はデータ・ブロック群を先頭から順番に読み出すだけで、メインＴＳとサブＴＳとの交互の読み出しをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、３Ｄ映像のシームレス再生が確実に持続可能である。
また、図１７（ｃ）のように、ベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとのすべてエクステントのエクステントＡＴＣ時間を同じにするとしても良い。このように構成することで、多重化ストリームのエクステントサイズの決定方法が図１７（ｂ）に示すものに比べて容易になるためデータ作成が容易になる。また、その固定するエクステントＡＴＣ時間を、後述する最小エクステントサイズのエクステントＡＴＣ時間とすれば、２Ｄ／３Ｄ再生装置に必要なリードバッファのサイズを小さくすることもできる。
＜データ・ブロックに対するＡＶストリーム・ファイルのクロスリンク＞
多重化ストリーム・データに属する各データ・ブロックは、記録媒体１００のファイルシステムでは、ファイル２Ｄ又はファイルＤＥＰ内の一つのエクステントとしてアクセス可能である。すなわち、各データ・ブロックの論理アドレスは、ファイル２Ｄ又はファイルＤＥＰのファイル・エントリに記録されたアロケーション記述子から知ることができる。図１５に示されている例では、ファイル２Ｄ（01000.m2ts）のファイル・エントリ1610に含まれるアロケーション記述子＃１、＃２、＃３、…は、ベースビュー・データ・ブロックL1、L2、L3、…の各サイズとその先端のＬＢＮとを示す。第１ファイルＤＥＰ（02000.m2ts）のファイル・エントリ1620に含まれるアロケーション記述子＃１、＃２、＃３、…は、ライトビュー・データ・ブロックR1、R2、R3、…の各サイズとその先端のＬＢＮとを示す。第２ファイルＤＥＰ（03000.m2ts）のファイル・エントリ1630に含まれるアロケーション記述子＃１、＃２、＃３、…は、デプスマップ・データ・ブロックD1、D2、D3、…の各サイズとその先端のＬＢＮとを示す。
図１８の（ａ）は、ファイル２Ｄ（01000.m2ts）のデータ構造を示す模式図である。図１５に示されているように、ファイル・エントリ1610内のアロケーション記述子＃１、＃２、＃３、…はベースビュー・データ・ブロックL1、L2、L3、…を参照する。従って、各ベースビュー・データ・ブロックL1、L2、L3、…は、図１８の（ａ）に示されているように、ファイル２ＤのエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…としてアクセス可能である。以下、ファイル２Ｄに属するエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…を「２Ｄエクステント」という。
図１８の（ｂ）は、第１ファイルＤＥＰ（02000.m2ts）のデータ構造を示す模式図である。図１５に示されているように、ファイル・エントリ1620内のアロケーション記述子＃１、＃２、＃３、…はライトビュー・データ・ブロックR1、R2、R3、…を参照する。従って、各ライトビュー・データ・ブロックR1、R2、R3、…は、図１８の（ｂ）に示されているように、第１ファイルＤＥＰのエクステントEXT2[0]、EXT2[1]、EXT2[2]、…としてアクセス可能である。以下、ライトビューストリームファイルであるファイルＤＥＰに属するエクステントEXT2[0]、EXT2[1]、EXT2[2]、…を「ライトビュー・エクステント」という。
図１８の（ｃ）は、第２ファイルＤＥＰ（03000.m2ts）のデータ構造を示す模式図である。図１５に示されているように、ファイル・エントリ1630内のアロケーション記述子＃１、＃２、＃３、…はデプスマップ・データ・ブロックD1、D2、D3、…を参照する。従って、各デプスマップ・データ・ブロックD1、D2、D3、…は、図１８の（ｃ）に示されているように、第２ファイルＤＥＰのエクステントEXT3[0]、EXT3[1]、EXT3[2]、…としてアクセス可能である。以下、デプスマップストリームファイルであるファイルＤＥＰに属するエクステントEXT3[0]、EXT3[1]、EXT3[2]、…を「デプスマップ・エクステント」という。更に、ライトビュー・エクステントとデプスマップ・エクステントとのように、いずれかのファイルＤＥＰに属するエクステントを「ディペンデントビュー・エクステント」と総称する。
図１５に示されているデータ・ブロック群に対して、ＡＶストリーム・ファイルのクロスリンクは次のように実現される。第１ファイルＳＳ（01000.ssif）のファイル・エントリ1640に含まれるアロケーション記述子＃１、＃２、＃３、…は、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3、…をそれぞれ一つのエクステントと見なして各サイズとその先端のＬＢＮとを示す。第２ファイルＳＳ（02000.ssif）のファイル・エントリ1650に含まれるアロケーション記述子＃１、＃２、＃３、…は、デプスマップ・データ・ブロックD1、D2、D3、…とベースビュー・データ・ブロックL1、L2、L3、…との各サイズとその先端のＬＢＮとを交互に示す。
図１８の（ｄ）は、第１ファイルＳＳ（01000.ssif）のデータ構造を示す模式図である。図１５に示されているように、ファイル・エントリ1640内のアロケーション記述子＃１、＃２、＃３、…は、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3、…を参照する。従って、隣接するデータ・ブロックの各対R1＋L1、R2＋L2、R3＋L3、…は、図１８の（ｄ）に示されているように、第１ファイルＳＳのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、…としてアクセス可能である。以下、ファイルＳＳに属するエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、…を「３Ｄエクステント」という。各３ＤエクステントEXTSS[n]（n＝0、1、2、…）は、ファイル２Ｄとはベースビュー・データ・ブロックLnを共有し、第１ファイルＤＥＰとはライトビュー・データ・ブロックRnを共有する。
図１８の（ｅ）は、第２ファイルＳＳ（02000.ssif）のデータ構造を示す模式図である。図１５に示されているように、ファイル・エントリ1650内のアロケーション記述子＃１、＃２、＃３、…は、デプスマップ・データ・ブロックD1、D2、D3、…とベースビュー・データ・ブロックL1、L2、L3、…とを交互に参照する。従って、各データ・ブロックD1、L1、D2、L2、は、図１８の（ｅ）に示されているように、第２ファイルＳＳのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]、…としてアクセス可能である。第２ファイルＳＳの各エクステントは、ファイル２Ｄとはベースビュー・データ・ブロックLnを共有し、第２ファイルＤＥＰとはデプスマップ・データ・ブロックDnを共有する。
＜インターリーブ配置のデータ・ブロック群に対する再生経路＞
図１９は、図１５に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路1901、Ｌ／Ｒモードでの再生経路1902、及びデプス・モードでの再生経路1903を示す模式図である。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路1901が示すとおり、ベースビュー・データ・ブロックL1、L2、L3が順番に２ＤエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]として読み出される。すなわち、まず先頭のベースビュー・データ・ブロックL1が読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、二番目のベースビュー・データ・ブロックL2が読み出され、その直後のデプスマップ・データ・ブロックD3とライトビュー・データ・ブロックR3との読み出しが二回目のジャンプJ2D2によってスキップされる。続いて、三番目のベースビュー・データ・ブロックL3が読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路1902が示すとおり、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3が順番に３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]として読み出される。すなわち、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1とが連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが連続して読み出され、その直後のデプスマップ・データ・ブロックD3の読み出しが二回目のジャンプJLR2によってスキップされる。続いて、三番目のライトビュー・データ・ブロックR3とその直後のベースビュー・データ・ブロックL3とが連続して読み出される。
再生装置２００はデプス・モードでは第２ファイルＳＳを再生する。従って、デプス・モードでの再生経路1903が示すとおり、デプスマップ・データ・ブロックD1、D2、D3とベースビュー・データ・ブロックL1、L2とが交互に、第２ファイルＳＳのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]として読み出される。すなわち、まず先頭のデプスマップ・データ・ブロックD1が読み出され、その直後のライトビュー・データ・ブロックR1の読み出しが最初のジャンプJLD1によってスキップされる。次に、先頭のベースビュー・データ・ブロックL1が読み出され、続けてその直後のデプスマップ・エクステントD2が読み出される。更に、その直後のライトビュー・エクステントR2の読み出しが二回目のジャンプJLD2によってスキップされ、二番目のベースビュー・データ・ブロックL2が読み出される。
図１９の各再生経路1901−1903が示すとおり、データ・ブロック群がインターリーブ配置で記録された領域では、再生装置２００はそのデータ・ブロック群を実質上、先頭から順に読み出せばよい。ここで、その読み出し処理の途中ではジャンプが生じる。しかし、各ジャンプの距離は、図１６の（ａ）に示されているものとは異なり、メインＴＳとサブＴＳとのいずれの全長よりも十分に短い。また、いずれのジャンプも、図１７の（ａ）に示されているものとは異なり、一つのデータ・ブロックの読み出しの途中では生じていない。更に、エクステントＡＴＣ時間の等しいベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの各対では、サイズの比較的小さいディペンデントビュー・データ・ブロックが先に読み出される。従って、その逆の場合よりも、再生装置２００はリード・バッファの容量を削減できる。
再生装置２００はＬ／Ｒモードではデータ・ブロック群を第１ファイルＳＳのエクステント群として読み込む。すなわち、再生装置２００は第１ファイルＳＳのファイル・エントリ1640内のアロケーション記述子＃１、＃２、…から各３ＤエクステントEXTSS[0]、EXTSS[1]、…の先端のＬＢＮとそのサイズとを読み出してＢＤ−ＲＯＭドライブ121に渡す。ＢＤ−ＲＯＭドライブ121はそのＬＢＮからそのサイズのデータを連続して読み出す。これらの処理は、データ・ブロック群を第１ファイルＤＥＰとファイル２Ｄとの各エクステントとして読み込む処理よりも、ＢＤ−ＲＯＭドライブ121の制御が次の二点（Ａ）、（Ｂ）で簡単である：（Ａ）再生装置２００は一箇所のファイル・エントリを利用して、エクステントを順番に参照すればよい；（Ｂ）読み込み対象のエクステントの総数が実質上半減するので、ＢＤ−ＲＯＭドライブに渡されるべきＬＢＮとサイズとの対の総数が少ない。利点（Ａ）はデプス・モードでデータ・ブロック群を第２ファイルＳＳのエクステントとして読み込む処理にも当てはまる。但し、再生装置２００は３ＤエクステントEXTSS[0]、EXTSS[1]、…を読み込んだ後、それぞれをライトビュー・データ・ブロックとベースビュー・データ・ブロックとに分離してデコーダに渡さなければならない。その分離処理にはクリップ情報ファイルが利用される。その詳細については後述する。

＜ロングジャンプ＞
一般論だが、記録媒体に光ディスクを採用する場合、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。
ジャンプには、光ディスクの回転速度を上下させる操作の他に、トラックジャンプ及びフォーカスジャンプがある。トラックジャンプは、光ピックアップをディスクの半径方向に移動させる操作をいう。フォーカスジャンプは、光ディスクが多層ディスクであるとき、光ピックアップの焦点を一つの記録層から別の記録層へ移動させる操作をいう。これらのジャンプは一般にシーク時間が長く、かつ、ジャンプによって読み出しがスキップされるセクタ数が大きいので、特に「ロングジャンプ」という。ジャンプ期間中、光ピックアップによる読み出し操作は停止する。
ジャンプ期間中、読み出し操作がスキップされる記録媒体１００上の領域の長さを「ジャンプ距離」という。ジャンプ距離は通常、その部分のセクタ数で表される。上記のロングジャンプは具体的には、ジャンプ距離が所定の閾値を超えるジャンプとして定義される。その閾値は、例えばBD-ROMの規格では、ディスクの種類及びドライブの読み出し処理に関する性能により、４００００セクタに規定されている。
ロングジャンプを生じさせる場所の代表的なものとしては、メインＴＳとサブＴＳとが記録層の境界を越えて記録されている場合や、メインＴＳとサブＴＳとが別のデータを間に挟んで記録されている場合の他、プレイアイテム間の１対ｎの多重接続が存在する場所がある。
＜ロングジャンプの前後での多重化ストリーム・データの配置＞
記録媒体１００では、一連のメインＴＳとサブＴＳとが、ロングジャンプの必要な位置の前後に分離されているととき、それらのデータ・ブロック群が、以下に述べる５種類の配置１−５のいずれかで記録されている。更に、それらのデータ・ブロック群へのアクセスにはＡＶストリーム・ファイルのクロスリンクが利用される。それにより、再生装置２００は後述のとおり、リード・バッファの容量を必要最小限に維持したまま、ロングジャンプ中での映像のシームレス再生を容易に実現できる。
以下に、ロングジャンプの必要な位置として記録層の境界を例にして、データ・ブロック群がロングジャンプの必要な位置の前後に分離して配置する場合のデータ配置方法について、そのデータ構造を説明する。
［配置１］
図２０は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第１例を示す模式図である。本図に示すデータ配置は、ロングジャンプの必要な位置の前後に分離されているメインＴＳとサブＴＳとのプレイアイテム同士が、シームレス接続する場合に利点のあるデータ配置方法である。本図においてデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含むサブＴＳ、及びデプスマップストリームを含むサブＴＳに属する。図２０に示すように、層境界LBの前に位置する第１記録層には、デプスマップ・データ・ブロック群…、D0、D1、ライトビュー・データ・ブロック群…、R0、R1、及びベースビュー・データ・ブロック群…、L0、L1がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第１の３Ｄエクステント・ブロック」2001という。また、第１の３Ｄエクステント・ブロック2001の後端L1に連続してベースビュー・データ・ブロックL22D、L32Dが配置されている。更に、ベースビュー・データ・ブロックL32Dと層境界LBとの間には、デプスマップ・データ・ブロック群D2、D3、ライトビュー・データ・ブロック群R2、R3、及びベースビュー・データ・ブロック群…、L2SS、L3SSがインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第２の３Ｄエクステント・ブロック」2002という。
一方、層境界LBの後に位置する第２記録層には、デプスマップ・データ・ブロック群D4、…、ライトビュー・データ・ブロック群R4、…、及びベースビュー・データ・ブロック群L4、…がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第３の３Ｄエクステント・ブロック」2003という。
各３Ｄエクステント・ブロック2001、2002、2003のインターリーブ配置は、図１５に示されているものと同様である。すなわち、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックがその順で交互に並ぶ。更に、三つの連続するデータ・ブロックDn、Rn、Ln（n＝…、1、2、3、4、…）間ではエクステントＡＴＣ時間が等しい。第１の３Ｄエクステント・ブロック2001の後端に位置する三つのデータ・ブロックD1、R1、L1と、第２の３Ｄエクステント・ブロック2002の先端に位置する三つのデータ・ブロックD2、R2、L2SSとの間では、各ストリーム・データの内容が連続している。
第１の３Ｄエクステント・ブロック2001と第２の３Ｄエクステント・ブロック2002との間に位置するベースビュー・データ・ブロックL22Dは、第２の３Ｄエクステント・ブロック2002のベースビュー・データ・ブロックL2SSとビット単位（bit−for−bit）で一致する。同様にベースビュー・データ・ブロックL32Dは、第２の３Ｄエクステント・ブロック2002のベースビュー・データ・ブロックL3SSとビット単位で一致する。すなわち、データ・ブロック群L22D、L32Dとデータ・ブロック群L2SS、L3SSとの一方は他方の複製データである。以下、前者L22D、L32Dを「２Ｄ再生専用ブロック」といい、後者L2SS、L3SSを「３Ｄ再生専用ブロック」という。
図２０に示されている各データ・ブロックは、３Ｄ再生専用ブロックL2SS、L3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば第１ファイル２Ｄ（01000.m2ts）のファイル・エントリ2010では、アロケーション記述子＃１が、第１の３Ｄエクステント・ブロック2001内の最後から二番目のベースビュー・データ・ブロックL0のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL0は第１ファイル２Ｄの一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は、第１の３Ｄエクステント・ブロック2001内の最後のベースビュー・データ・ブロックL1とその直後に連続する２Ｄ再生専用ブロック群L22D、L32Dとからなるベースビュー・データ・ブロックの一群L1+ L22D+L32Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックの一群L1+ L22D+L32Dは、第１ファイル２Ｄの単一の２ＤエクステントEXT2D[1]としてアクセス可能である。これらのファイル２Ｄにおけるベースビュー・データ・ブロックL1、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステント（ビッグエクステント）を構成している。ファイル２Ｄは、ロングジャンプの直前で、ビックエクステントを形成することができるので、２Ｄ再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。ファイル２Ｄの再生において層境界LBをまたぐロングジャンプの直前にアクセスされるエクステントである２ＤエクステントEXT2D[1]を、以下では「ジャンプ直前２Ｄエクステント」とよぶ。
第２ファイル２Ｄ（01001.m2ts）のファイル・エントリ2011では、アロケーション記述子＃１が、第３の３Ｄエクステント・ブロック2003内のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は第２ファイル２Ｄの一つの２ＤエクステントEXT2D[2]としてアクセス可能である。
図２０に示されているデータ・ブロック群に対しても、ＡＶストリーム・ファイルのクロスリンクは図１５のものと同様に実現される。特に、第１ファイルＳＳ（01000.ssif）のファイル・エントリ2020では、アロケーション記述子＃１、＃２、＃３、＃４が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R0＋L0、R1＋L1、R2＋L2SS、R3＋L3SSをそれぞれ一つのエクステントと見なして、各サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの各対R0＋L0、R1＋L1、R2＋L2SS、R3＋L3SSは第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。このうちEXTSS[2]、EXTSS[3]は、ファイルＳＳの再生において、層境界LBをまたぐロングジャンプの直前にアクセスされる第２の３Ｄエクステント・ブロック2002を構成するエクステント群であり、以下では「ジャンプ直前３Ｄエクステント群」とよぶ。また、第２ファイルＳＳ（01001.ssif）のファイル・エントリ2021では、アロケーション記述子＃１が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4＋L4を一つのエクステントと見なして、サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの対R4＋L4は第２ファイルＳＳの３ＤエクステントEXTSS[4]としてアクセス可能である。
ここで、２Ｄ再生専用ブロックL32Dと層境界LBとの間に位置する３ＤエクステントEXTSS[2]、EXTSS[3] を除き、３ＤエクステントEXTSS[0]、EXTSS[1]、及びEXTSS[4]はそれぞれ、ベースビュー・データ・ブロック…、L0、L1、L4をファイル２Ｄと共有する。一方、２Ｄ再生専用ブロックL22D、L32Dは、ファイル２Ｄにおける層境界LB直前の２ＤエクステントEXT2D[1]の一部としてのみアクセス可能な、ファイル２Ｄ固有のベースビューデータブロックである。更に、３Ｄ再生専用ブロックL2SS、L3SSは、ファイルＳＳにおける層境界LB直前の３ＤエクステントEXTSS[2]の一部としてのみアクセス可能な、ファイルＳＳ固有のベースビューデータブロックである。
図２０において、２Ｄプレイリスト及び３Ｄプレイリストは、何れもシームレスに接続する２つのプレイアイテム＃１、＃２を含む。ここでは、シームレスに接続するプレイアイテムの接続元プレイアイテムを「前方プレイアイテム」、接続先プレイアイテムを「後方プレイアイテム」と呼ぶことにする。まず、２Ｄプレイリストと３Ｄプレイリストとの各前方プレイアイテムが参照するデータを説明する。２Ｄプレイリストの前方プレイアイテムは、第１ファイル２Ｄを参照する。３Ｄプレイリストの前方プレイアイテムは第１ファイルＳＳを参照し、３Ｄプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。上述のように、第１ファイル２Ｄの２ＤエクステントEXT2D[0]、EXT2D[1]と、第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]とで参照するベースビューデータブロックの中身は同じである。これにより、２Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL1、L22D、L32Dを再生することになり、３Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1、L2SS、L3SSを再生することになる。従って、２Ｄプレイリストに基づく２Ｄ再生と３Ｄプレイリストに基づく３Ｄ再生とでは、再生経路（再生する論理アドレス）は異なるが同じレフトビュー・ビデオ・フレームを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。２Ｄプレイリストの後方プレイアイテムは、第２ファイル２Ｄを参照する。３Ｄプレイリストの後方プレイアイテムは第２ファイルＳＳを参照し、３Ｄプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。第２ファイル２Ｄと第２ファイルＳＳとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、２Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前２ＤエクステントEXT2D[1]の終端から、後方プレイアイテムにより参照される２ＤエクステントEXT2D[2]先頭までの距離は、２Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、３Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前３Ｄエクステントブロック2002と後方プレイアイテムにより参照される３Ｄエクステントブロック2003間のジャンプ距離は、２Ｄ／３Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
図２１は、図２０に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路、Ｌ／Ｒモードでの再生経路、及びデプス・モードでの再生経路を示す模式図である。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、ベースビュー・データ・ブロックL0が最初の２ＤエクステントEXT2D[0] として読み出され、ベースビュー・データ・ブロックL1とその直後の２Ｄ再生専用ブロックL22D、L32Dとが連続して二番目の２ＤエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路が示すとおり、ライトビュー・データ・ブロックR0とその直後のベースビュー・データ・ブロックL0との対R0＋L0が最初の３ＤエクステントEXTSS[0]として読み出され、ライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1とが二番目の３ＤエクステントEXTSS[1]として読み出され、ライトビュー・データ・ブロックR2とその直後の３Ｄ再生専用ブロックL2SSとが三番目の３ＤエクステントEXTSS[2]として読み出され、ライトビュー・データ・ブロックR3とその直後の３Ｄ再生専用ブロックL3SSとが四番目の３ＤエクステントEXTSS[3]として読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後のベースビューデータブロックL4とが五番目の３ＤエクステントEXTSS[4]として読み出される。
図２１に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロックL22D、L32Dは読み出されるが、３Ｄ再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆に、Ｌ／Ｒモードでは、２Ｄ再生専用ブロックL22D、L32Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL2SS、L3SSは読み出される。しかし、データ・ブロックL22D、L2SSはビット単位で一致しており、データ・ブロックL32D、L3SSもビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置１ではロングジャンプJLYの前で２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とが分離されている。デプス・モードについても同様である。
［配置１の利点］
図２２は、あるＢＤ−ＲＯＭディスクの層境界の前後にインターリーブ配置で記録されているデータ・ブロック群と、それに対する各再生モードでの再生経路とを示す模式図である。図２２を参照するに、図２０に示されている配置１と同様、第１記録層には、デプスマップ・データ・ブロック群…、D1、D2、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されて第１の３Ｄエクステント・ブロック2301を構成している。一方、第２記録層には、デプスマップ・データ・ブロック群D3、…、ライトビュー・データ・ブロック群R3、…、及びベースビュー・データ・ブロック群L3、…がインターリーブ配置で記録されて第２の３Ｄエクステント・ブロック2302を構成している。各３Ｄエクステント・ブロック2301、2302のインターリーブ配置は、図２０に示されているもの2001、2002と同様である。更に、第１の３Ｄエクステント・ブロック2301の後端に位置する三つのデータ・ブロックD2、R2、L2と、第２の３Ｄエクステント・ブロック2302の先端に位置する三つのデータ・ブロックD3、R3、L3との間では、各ストリーム・データの内容が連続している。
図２２に示されているデータ・ブロック群は、図２０に示されているものとは異なり、層境界LBの直前に２Ｄ再生専用ブロックLn2Dと３Ｄ再生専用ブロックLnSSとを含んでいない。従って、以下に示すように、２Ｄ再生モードでの再生経路2310とＬ／Ｒモードでの再生経路2311とがロングジャンプJLYの直前に分離されることなく、いずれも同じベースビュー・データ・ブロックL2を通る。
図２２に示されているベースビュー・データ・ブロックL1−L3はいずれもファイル２Ｄの一つのエクステントEXT2D[0]−EXT2D[2]としてアクセス可能である。一方、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの各対R1＋L1、R2＋L2、R3＋L3はファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]としてアクセス可能である。いずれの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]もそれぞれベースビュー・データ・ブロックL1、L2、L3をファイル２Ｄと共有する。
２Ｄ再生モードの再生装置２００はファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路2310が示すとおり、まず第１の３Ｄエクステント・ブロック2301内の最後から二番目のベースビュー・データ・ブロックL1が最初の２ＤエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第１の３Ｄエクステント・ブロック2301内の最後のベースビュー・データ・ブロックL2が二番目の２ＤエクステントEXT2D[1]として読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2302の先端に位置する２個のデータ・ブロックD3、R3の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2302内の先頭のベースビュー・データ・ブロックL3が三番目の２ＤエクステントEXT2D[2]として読み出される。
Ｌ／Ｒモードの再生装置２００はファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路2311が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1＋L1が最初の３ＤエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の３ＤエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2302内の先頭のデプスマップ・データ・ブロックD3の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2302内の先頭のライトビュー・データ・ブロックR3とその直後のベースビュー・データ・ブロックL3とが三番目の３ＤエクステントEXTSS[2]として連続して読み出される。
上記のとおり、図２２に示されているデータ・ブロック群では、図２０に示されているものとは異なり、２Ｄ再生モードでの再生経路2310とＬ／Ｒモードでの再生経路2311とがいずれも、ロングジャンプJLYの直前に同じベースビュー・データ・ブロックL2を通る。ここで、ロングジャンプJLYの期間中、ＢＤ−ＲＯＭドライブ121は読み出し処理を停止するが、システム・ターゲット・デコーダは、リード・バッファに蓄積されたストリーム・データの復号処理を続行する。従って、再生装置２００にロングジャンプJLYの前後で映像をシームレスに再生させるには、ロングジャンプJLYの期間中でのバッファ・アンダーフローを防止しなければならない。
Ｌ／Ｒモードでは、第１の３Ｄエクステント・ブロック2301が復号される間に、リード・バッファに一定量のデータが蓄積される。この一定量のデータを「バッファ余裕量」という（その詳細は後述する）。ロングジャンプJLYの期間中では、その直前に読み込まれた３ＤエクステントEXTSS[1]、すなわちライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2とに加えてそのバッファ余裕量のデータが復号される。従って、Ｌ／Ｒモードでバッファ・アンダーフローを防止するにはバッファ余裕量が十分に大きければよい。一方、各データ・ブロックR2、L2のサイズは、ロングジャンプJLYの直前までバッファ余裕量が維持できる値Smin2、Smin1であればよい。
しかし、２Ｄ再生モードでバッファ・アンダーフローを防止するには、２ＤエクステントEXT2D[1]、すなわちベースビュー・データ・ブロックL2のサイズSext2D[1]が次の条件を満たさねばならない：２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間に、リード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上である。その条件を満たすサイズSext2D[1]は、図２２に示されているように、Ｌ／Ｒモードでのシームレス再生に必要最小限のサイズSmin1よりも一般に大きい。従って、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量はＬ／Ｒモードでのシームレス再生に必要最小限の値よりも大きくなければならない。更に、ライトビュー・データ・ブロックR2はベースビュー・データ・ブロックL2とエクステントＡＴＣ時間が等しくなければならない。従って、ライトビュー・データ・ブロックR2のサイズSext2[1]はＬ／Ｒモードでのシームレス再生に必要最小限の値Smin2よりも一般に大きい。それ故、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量はＬ／Ｒモードでのシームレス再生に必要最小限の値よりも更に大きくなければならない。以上の結果、図２２に示されている配置では、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量の更なる削減が困難である。
それに対し、図２１に示されている配置１では上記のとおり、ロングジャンプJLYの前で２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とが分離されている。従って、図２２に示されている配置とは異なり、層境界LBの前に位置するジャンプ直前２ＤエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR1のサイズSext2[1]とが、以下のように別々に決定可能である。
まず、ジャンプ直前２ＤエクステントEXT2D[1]のサイズSext2D[1]は、ベースビュー・データ・ブロックL1のサイズSext1[1]と２Ｄ再生専用ブロックL2 2DのサイズS2D[2]、２Ｄ再生専用ブロックL3 2DのサイズS2D[3]の和Sext1[1]＋S2D[2]+S2D[3]に等しい。従って、２Ｄ再生モードでのシームレス再生の実現には、その和Sext1[1]＋S2D[2]+S2D[3]が、ジャンプ直前２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。ここで、ジャンプ直前２ＤエクステントEXT2D[1]のうち、３ＤエクステントEXTSS[1]と共有されるのは、エクステント先頭に位置するベースビュー・データ・ブロックL1だけである。従って、２Ｄ再生専用ブロックL2 2DのサイズS2D[2]と２Ｄ再生専用ブロックL3 2DのサイズS2D[3]とを適切に拡大することにより、ジャンプ直前２ＤエクステントEXT2D[1]のサイズSext2D[1]＝Sext1[1]＋S2D[2]+S2D[3]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext1[1]を更に小さく制限することができる。それに伴い、ベースビュー・データ・ブロックL1とエクステントＡＴＣ時間を等しくするライトビュー・データ・ブロックR1のサイズSext2[1]も更に小さく制限することができる。
一方、層境界LBの直前に位置するジャンプ直前３Ｄエクステントブロック2002に属するライトビュー・データ・ブロックR2、R3とベースビュー・データ・ブロックL2SS、L3SSとの各サイズSext2[2]、Sext2[3]、Sext1[2]、Sext1[3]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、３Ｄ再生専用ブロックL2SSは２Ｄ再生専用ブロックL22Dの複製データであり、３Ｄ再生専用ブロックL3SSは２Ｄ再生専用ブロックL32Dの複製データであるので、２Ｄ再生専用ブロックL32DのサイズS2Dの拡大は、３Ｄ再生専用ブロックL3SSの直前に位置するライトビュー・データ・ブロックR3のサイズを拡大させる。しかし、そのサイズは、図２２に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量を、Ｌ／Ｒモードでのシームレス再生に必要最小限の値に更に接近させることができる。
このように、配置１では、再生装置２００内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが可能である。
以上、配置１ではロングジャンプが発生する地点において、２Ｄ再生モードでの再生経路と、Ｌ／Ｒモードでの再生経路とを分離できるため、ジャンプ直前３Ｄエクステントブロックの終端EXT1[3]のサイズは、２Ｄ再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
また、図２０の説明では、ロングジャンプの必要な位置として層境界を例としたが、ロングジャンプは、1対nのプレイアイテムの多重接続を行う場合にも生じ得る。1対nのプレイアイテムの多重接続を行う場合、ｎ個のプレイアイテムを構成するn個のTSのうち1つ目のものは、その直前のプレイアイテムを構成するTSの直後に配置することができる。しかし2つ目以降のものは、その直前のプレイアイテムを構成するTSの直後に配置することができない。１対nの多重接続が存在する場合において、直前のプレイアイテムから、ｎ個のプレイアイテムの２個目以降のプレイアイテムへとジャンプする場合、そのジャンプは、1つ以上のTSの記録領域を読み飛ばす必要があるので、１対ｎのプレイアイテムの多重接続が存在する場所では、ロングジャンプが生じることになる。このような1対nのプレイアイテム多重接続に伴うロングジャンプにも、配置１を適用することができる。具体的には、図２３に示すように、２Ｄプレイリスト及び３Ｄプレイリストの何れに関しても、前方プレイアイテムであるプレイアイテム＃１により参照されるデータをひとまとまりで全て配置し、その後にｎ個の後方プレイアイテムが参照するデータを配置する。このとき図２０に示す配置と同様に、前方プレイアイテムについて２Ｄプレイリストと３Ｄプレイリストとで再生経路を分離してデータを配置しており、ジャンプ直前３Ｄエクステントブロックの終端EXT1[3]のサイズは、２Ｄ再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
以上、配置１を用いることで、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能となる。
［配置２］
図２４は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第２例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含むサブＴＳ、及びデプスマップストリームを含むサブＴＳに属する。以下、この配置を「配置２」という。図２４を図２０と比較するに、配置１とは、第１の３Ｄエクステントブロック2001に連続して第２の３Ｄエクステントブロック2002が配置されている点、及び３Ｄエクステントブロック2002の後端L3SSに連続して２Ｄ再生専用ブロック群L12D、L22D、L32Dが配置され連続して一つの２ＤエクステントEXT2D[1]としてアクセス可能である点で異なる。その他の特徴については配置２は配置１と同様であるので、その詳細についての説明は配置２についての説明を援用する。
層境界LBの直前に位置する２Ｄ再生専用ブロック群L12D、L22D、L32Dは第２の３Ｄエクステント・ブロック2002内の３Ｄ再生専用ブロック群L1SS、L2SS、L3SSとビット単位で一致する。すなわち、２Ｄ再生専用ブロック群L12D、L22D、L32Dと３Ｄ再生専用ブロック群L1SS、L2SS、L3SSとの一方は他方の複製データである。
図２４に示されている各データ・ブロックは、３Ｄ再生専用ブロックL1SS、L2SS、L3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば、第１ファイル２Ｄのファイル・エントリ2010では、アロケーション記述子＃１は、第１の３Ｄエクステント・ブロック2001内の最後のベースビュー・データ・ブロックL0のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL1は一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は２Ｄ再生専用ブロックL12D、L22D、L32Dからなるベースビュー・データ・ブロックの一群L12D+ L22D+L32Dを単一のエクステントと見なしてその合計サイズとその先端のＬＢＮとを示す。従って、２Ｄ再生専用ブロック群L12D、L22D、L32Dは次の２ＤエクステントEXT2D[1]としてアクセス可能である。このファイル２Ｄにおけるベースビュー・データ・ブロックL12D、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステントを構成している。ファイル２Ｄは、ロングジャンプの直前で、ビックエクステントを形成することができるので、２Ｄ再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。また、第２ファイル２Ｄのファイル・エントリ2011では、アロケーション記述子＃１が、第３の３Ｄエクステント・ブロック2003内の最初のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は第２ファイル２Ｄの一つの２ＤエクステントEXT2D[2]としてアクセス可能である。
第１ファイルＳＳのファイル・エントリ2020では、アロケーション記述子＃１、＃２、＃３、＃４が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R0＋L0、R1＋L1SS、R2＋L2SS、R3＋L3SSをそれぞれ一つのエクステントと見なして、各サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの各対R0＋L0、…、R3＋L3 SSは第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。また、第２ファイルＳＳのファイル・エントリ2021では、アロケーション記述子＃１が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4＋L4を一つのエクステントと見なして、サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの対R4＋L4は第２ファイルＳＳの３ＤエクステントEXTSS[4]としてアクセス可能である。
ここで、２Ｄ再生専用ブロックL12D、L22D、L32Dは、ファイル２Ｄにおける層境界LB直前の２ＤエクステントEXT2D[1]としてのみアクセス可能なファイル２Ｄ固有のベースビューデータブロックであり、各３Ｄ再生専用ブロックL1SS、L2SS、L3SSは３ＤエクステントEXTSS[1]、EXTSS[2] 、EXTSS[3]の一部としてのみアクセス可能な、ファイルＳＳ固有のベースビューデータブロックである。
図２４において、２Ｄプレイリスト及び３Ｄプレイリストは、何れもシームレスに接続する２つのプレイアイテム＃１、＃２を含む。まず、２Ｄプレイリストと３Ｄプレイリストとの各前方プレイアイテムが参照するデータを説明する。２Ｄプレイリストの前方プレイアイテムは、第１ファイル２Ｄを参照する。３Ｄプレイリストの前方プレイアイテムは第１ファイルＳＳを参照し、３Ｄプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。上述のように、第１ファイル２Ｄの２ＤエクステントEXT2D[0]、EXT2D[1]と、第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]との中身は同じである。これにより、２Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL12D、L22D、L32Dを再生することになり、３Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1 SS、L2SS、L3SSを再生することになる。従って、２Ｄプレイリストに基づく２Ｄ再生と３Ｄプレイリストに基づく３Ｄ再生とでは、再生経路は異なるが同じデータを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。２Ｄプレイリストの後方プレイアイテムは、第２ファイル２Ｄを参照する。３Ｄプレイリストの後方プレイアイテムは第２ファイルＳＳを参照し、３Ｄプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。第２ファイル２Ｄと第２ファイルＳＳとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、２Ｄプレイリストの前方プレイアイテムにより参照される２ＤエクステントEXT2D[0]の終端からジャンプ直前２ＤエクステントEXT2D[1]先頭までの距離と、２Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前２ＤエクステントEXT2D[1]の終端から後方プレイアイテムにより参照される２ＤエクステントEXT2D[2]先頭までの距離とは、２Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、３Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前３Ｄエクステントブロック2002と後方プレイアイテムにより参照される３Ｄエクステントブロック2003間のジャンプ距離は、２Ｄ／３Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
図２５は、図２４に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路、Ｌ／Ｒモードでの再生経路、及びデプス・モードでの再生経路を示す模式図である。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、ベースビュー・データ・ブロックL0が最初の２ＤエクステントEXT2D[0] として読み出され、２Ｄ再生専用ブロックL12D、L22D、L32Dが連続して二番目の２ＤエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路が示すとおり、ライトビュー・データ・ブロックR0とその直後のベースビュー・データ・ブロックL0との対R0＋L0が最初の３ＤエクステントEXTSS[0]として読み出され、ライトビュー・データ・ブロックR1とその直後の３Ｄ再生専用ブロックL1SSとが二番目の３ＤエクステントEXTSS[1]として読み出され、ライトビュー・データ・ブロックR2とその直後の３Ｄ再生専用ブロックL2SSとが三番目の３ＤエクステントEXTSS[2]として読み出され、ライトビュー・データ・ブロックR3とその直後の３Ｄ再生専用ブロックL3SSとが四番目の３ＤエクステントEXTSS[3]として読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後の３Ｄ再生専用ブロックL4とが五番目の３ＤエクステントEXTSS[4]として読み出される。
図２４に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロックL12D、L22D、L32Dは読み出されるが、３Ｄ再生専用ブロックL1SS、L2SS、L3SSの読み出しはスキップされる。逆に、Ｌ／Ｒモードでは、２Ｄ再生専用ブロックL12D、L22D、L32Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL1SS、L2SS、L3SSは読み出される。しかし、データ・ブロックL12D、L22D、L32DとL1SS、L2SS、L3SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置２ではロングジャンプJLYの前で２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とが分離されている。デプス・モードについても同様である。
ジャンプ直前２ＤエクステントEXT2D[1]のサイズSext2D[1]が、２Ｄ再生専用ブロックL1 2DのサイズS2D[2]、２Ｄ再生専用ブロックL2 2DのサイズS2D[2]、２Ｄ再生専用ブロックL3 2DのサイズS2D[3]の和S2D[1]＋S2D[2]+S2D[3]に等しい。従って、２Ｄ再生モードでのシームレス再生の実現には、その和S2D[1]＋S2D[2]+S2D[3]が、ジャンプ直前２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。また、２Ｄ再生専用ブロックL1 2Dの直前に位置するジャンプ直前３Ｄエクステントブロック2002に属するライトビュー・データ・ブロックR1、R2、R3とベースビュー・データ・ブロックL1SS、L2SS、L3SSとの各サイズSext2[1]、Sext2[2]、Sext2[3]、Sext1[1]、Sext1[2]、Sext1[3]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。
ここで、３Ｄ再生専用ブロックL1SSは２Ｄ再生専用ブロックL12Dの複製データであり、３Ｄ再生専用ブロックL2SSは２Ｄ再生専用ブロックL22Dの複製データであり、３Ｄ再生専用ブロックL3SSは２Ｄ再生専用ブロックL32Dの複製データであるので、２Ｄ再生専用ブロックL12D、L22D、L32Dの合計サイズS2D[1]＋S2D[2]+S2D[3]の拡大は、各３Ｄ再生専用ブロックL1SS、L2SS、L3SSの直前に位置するライトビュー・データ・ブロックR1、R2、R3のサイズを拡大させる。しかし、３Ｄ再生専用ブロックは三つL1SS、L2SS、L3SSに分割されてライトビュー・データ・ブロックと対になっているので、ライトビュー・データ・ブロックR1、R2、R3の各サイズは、図２２に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR2のサイズよりは十分に小さくできる。こうして、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量は、Ｌ／Ｒモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置２では、再生装置２００内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが可能である。
以上、配置２ではロングジャンプが発生する地点において、２Ｄ再生モードでの再生経路と、Ｌ／Ｒモードでの再生経路とを分離できるため、ジャンプ直前３Ｄエクステントブロックの終端EXT1[3]のサイズは、２Ｄ再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
また、図２４の説明では、ロングジャンプの必要な位置として層境界を例としたが、配置２は、1対nのプレイアイテム多重接続に伴うロングジャンプにも適用することができる。具体的には、前方プレイアイテムについては、図２４に示す配置と同様に、２Ｄプレイリストと３Ｄプレイリストとで再生経路を分離してデータを配置し、その後にｎ個の後方プレイアイテムが参照するデータを順に配置することで、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能となる。
［配置３］
図２６は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第３例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含むサブＴＳ、及びデプスマップストリームを含むサブＴＳに属する。以下、この配置を「配置３」という。図２６を図２０と比較するに、配置１は配置２とは、ジャンプ直前３Ｄエクステントブロック2002が、ジャンプ直前３Ｄエクステントブロック2004に置換されている点のみで異なる。その他の特徴については配置２は配置１と同様であるので、その詳細についての説明は配置２についての説明を援用する。
ジャンプ直前３Ｄエクステントブロック2004におけるインターリーブ配置は、他の３Ｄエクステントブロックのインターリーブ配置と比べて、デプスマップデータブロックとライトビューデータブロックとの配置順が逆になっており、ライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックがその順で交互に並ぶ。ジャンプ直前３Ｄエクステントブロック2004に含まれる、３Ｄ再生専用ブロックL2SS、L3SSが、２Ｄ再生専用ブロック群L22D、L32Dとビット単位で一致することは配置１と同様である。
配置３では図２７に示すようにＬ／Ｒモードの再生経路において、ライトビューデータブロックR0とレフトビューデータブロックL0との対からなる３ＤエクステントEXTSS[0]、ライトビューデータブロックR1とレフトビューデータブロックL1との対からなる３ＤエクステントEXTSS[1]、ライトビューデータブロックR2のみからなる３ＤエクステントEXTSS[2]、レフトビューデータブロックL2SSとライトビューデータブロックR3との対からなる３ＤエクステントEXTSS[3]、レフトビューデータブロックL3SSのみからなる３ＤエクステントEXTSS[4]の順で、データブロックがアクセスされる。
このような配置にすることによって、配置３では、配置１と同様にロングジャンプが発生する地点において２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とを分離できるため、ジャンプ直前３Ｄエクステントブロックの終端EXT1[3]のサイズは２Ｄ再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。また、配置３は、配置１と同様に1対nのプレイアイテム多重接続に伴うロングジャンプにも適用することができ、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能である。
これらに加えて配置３では、デプスモードとＬ／Ｒモードとの両方で３Ｄ映像を再生する場合のシームレス接続に必要なバッファ余裕量を少なく抑えられる。その結果、２Ｄ／３Ｄ再生装置がデプスモードとＬ／Ｒモードの両方で３Ｄ映像を再生するために必要なリードバッファのサイズを、配置１のデータを再生する場合よりも小さくすることができる。バッファ余裕量の具体的な削減量についての詳細は後述する。
尚、図２６では、ジャンプ直前３Ｄエクステントブロック2004において、ライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックがその順で交互に並び、他の３Ｄエクステントブロックにおいてデプスマップデータブロック、ライトビューデータブロック、レフトビューデータブロックがその順で交互に並ぶとした。しかし、配置３は、ジャンプ直前３Ｄエクステントブロックのインターリーブ配置が他の３Ｄエクステントブロックのインターリーブ配置に対して、デプスマップデータブロックとライトビューデータブロックとの順が逆になっていることを特徴としており、例えば、他の３Ｄエクステントブロックにおいてライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックの順で交互にインターリブ配置している場合には、ジャンプ直前３Ｄエクステントブロックでは、デプスマップデータブロック、ライトビューデータブロック、レフトビューデータブロックの順で交互にデータブロックをインタリーブ配置するとよい。
［配置４］
図２８は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第４例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含む第１サブＴＳ、及びデプスマップストリームを含む第２サブＴＳに属する。以下、この配置を「配置４」という。図２８を参照するに、層境界LBの前に位置する第１記録層には、デプスマップ・データ・ブロック群…、D1、D2、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第１の３Ｄエクステント・ブロック」2101という。更に、第１の３Ｄエクステント・ブロック2101の後端L2と層境界LBとの間に一つのベースビュー・データ・ブロックL32Dが配置されている。一方、層境界LBの後に位置する第２記録層には、デプスマップ・データ・ブロック群D3、D4、…、ライトビュー・データ・ブロック群R3、R4、…、及びベースビュー・データ・ブロック群L3SS、L4、…がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第２の３Ｄエクステント・ブロック」2102という。
各３Ｄエクステント・ブロック2101、2102のインターリーブ配置は、図１５に示されているものと同様である。すなわち、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックがその順で交互に並ぶ。更に、三つの連続するデータ・ブロックDn、Rn、Ln（n＝…、1、2、3、4、…）間ではエクステントＡＴＣ時間が等しい。第１の３Ｄエクステント・ブロック2101の後端に位置する三つのデータ・ブロックD2、R2、L2と、第２の３Ｄエクステント・ブロック2102の先端に位置する三つのデータ・ブロックD3、R3、L3SSとの間では、各ストリーム・データの内容が連続している。
層境界LBの直前に位置するベースビュー・データ・ブロックL32Dは、第２の３Ｄエクステント・ブロック2102内の先端のベースビュー・データ・ブロックL3SSとビット単位（bit−for−bit）で一致する。すなわち、それらのデータ・ブロックL32D、L3SSの一方は他方の複製データである。以下、前者L32Dを「２Ｄ再生専用ブロック」といい、後者L3SSを「３Ｄ再生専用ブロック」という。
図２８に示されている各データ・ブロックは、３Ｄ再生専用ブロックL3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えばファイル２Ｄ（01000.m2ts）のファイル・エントリ2110では、アロケーション記述子＃１が、第１の３Ｄエクステント・ブロック2101内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL1はファイル２Ｄの一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は、第１の３Ｄエクステント・ブロック2101内の最後のベースビュー・データ・ブロックL2とその直後の２Ｄ再生専用ブロックL32Dとの対L2＋L32Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックの対L2＋L32Dはファイル２Ｄの単一の２ＤエクステントEXT2D[1]としてアクセス可能である。更に、アロケーション記述子＃３が、第２の３Ｄエクステント・ブロック2102内の二番目のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は別の一つの２ＤエクステントEXT2D[2]としてアクセス可能である。
図２８に示されているデータ・ブロック群に対しても、ＡＶストリーム・ファイルのクロスリンクは図１５のものと同様に実現される。特に、第１ファイルＳＳのファイル・エントリ2120では、アロケーション記述子＃１、＃２、＃３、＃４が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3SS、R4＋L4をそれぞれ一つのエクステントと見なして、各サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの各対R1＋L1、R2＋L2、R3＋L3SS、R4＋L4は第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。ここで、層境界LBの直後の３ＤエクステントEXTSS[3]を除き、３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[3]はそれぞれ、ベースビュー・データ・ブロックL1、L2、L4をファイル２Ｄと共有する。一方、２Ｄ再生専用ブロックL32Dは、層境界LBの直前に位置するファイル２ＤのエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、３Ｄ再生専用ブロックL3SSは、層境界LBの直後の３ＤエクステントEXTSS[2]の一部としてのみアクセス可能である。
図２９は、図２８に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路2201とＬ／Ｒモードでの再生経路2202を示す模式図である。尚、デプス・モードでの再生経路は、図１５に示されているものから、当業者には容易に類推可能であろう。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路2201が示すとおり、まず第１の３Ｄエクステント・ブロック2101内の最後から二番目のベースビュー・データ・ブロックL1が最初の２ＤエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第１の３Ｄエクステント・ブロック2101内の最後のベースビュー・データ・ブロックL2とその直後の２Ｄ再生専用ブロックL32Dとの対L2＋L32Dが二番目の２ＤエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2102の先端に位置する５個のデータ・ブロックD3、R3、L3SS、D4、R4の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2102内の二番目のベースビュー・データ・ブロックL4が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路2202が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1＋L1が最初の３ＤエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の３ＤエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、２Ｄ再生専用ブロックL32Dと第２の３Ｄエクステント・ブロック2102内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2102内の先頭のライトビュー・データ・ブロックR3とその直後の３Ｄ再生専用ブロックL3SSとが三番目の３ＤエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。更に、次のライトビュー・データ・ブロックR4とその直後のベースビュー・データ・ブロックL4とが四番目の３ＤエクステントEXTSS[3]として連続して読み出される。
図２９に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロックL32Dは読み出されるが、３Ｄ再生専用ブロックL3SSの読み出しはスキップされる。逆に、Ｌ／Ｒモードでは、２Ｄ再生専用ブロックL32Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL3SSは読み出される。しかし、両方のデータ・ブロックL32D、L3SSはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置４ではロングジャンプJLYの前後で２Ｄ再生モードでの再生経路2201とＬ／Ｒモードでの再生経路2202とが分離されている。デプス・モードについても同様である。
図２９に示されている配置４では上記のとおり、ロングジャンプJLYの前後で２Ｄ再生モードでの再生経路2201とＬ／Ｒモードでの再生経路2202とが分離されている。従って、図２２に示されている配置とは異なり、層境界LBの直前に位置する２ＤエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。
まず、２ＤエクステントEXT2D[1]のサイズSext2D[1]はベースビュー・データ・ブロックL2のサイズSext1[1]と２Ｄ再生専用ブロックL32DのサイズS2Dとの和Sext1[1]＋S2Dに等しい。従って、２Ｄ再生モードでのシームレス再生の実現には、その和Sext1[1]＋S2Dが、２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する３ＤエクステントEXTSS[1]に属するライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2との各サイズSext2[1]、Sext1[1]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、２ＤエクステントEXT2D[1]のうち、３ＤエクステントEXTSS[1]と共有されるのは、前側に位置するベースビュー・データ・ブロックL2だけである。従って、２Ｄ再生専用ブロックL32DのサイズS2Dを適切に拡大することにより、２ＤエクステントEXT2D[1]のサイズSext2D[1]＝Sext1[1]＋S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。
ここで、３Ｄ再生専用ブロックL3SSは２Ｄ再生専用ブロックL32Dの複製データであるので、２Ｄ再生専用ブロックL32DのサイズS2Dの拡大は、３Ｄ再生専用ブロックL3SSの直前に位置するライトビュー・データ・ブロックR3のサイズを拡大させる。しかし、そのサイズは、図２２に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量を、Ｌ／Ｒモードでのシームレス再生に必要最小限の値に更に接近させることができる。
このように、配置４では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが、再生装置２００内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。更に、２Ｄ再生モードとＬ／Ｒモードとで読み込み対象のデータ・ブロックを変更すること、特に２Ｄ再生専用ブロックL32Dと３Ｄ再生専用ブロックL3SSとの間の切り換えが、再生対象のＡＶストリーム・ファイルをファイル２ＤとファイルＳＳとの間で切り換えるだけで容易に実現可能である。
［配置５］
図３０は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第５例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含む第１サブＴＳ、及びデプスマップストリームを含む第２サブＴＳに属する。以下、この配置を「配置５」という。図３０を図２８と比較するに、配置５は配置４とは、第２の３Ｄエクステント・ブロック2402の先端に二個の３Ｄ再生専用ブロックL3SS、L4SSが設けられている点で異なる。その他の特徴については配置５は配置４と同様であるので、その詳細についての説明は配置４についての説明を援用する。
層境界LBの直前に位置する２Ｄ再生専用ブロック（L3＋L4)2Dは第２の３Ｄエクステント・ブロック2402内の３Ｄ再生専用ブロックの対L3SS、L4SSとビット単位で一致する。すなわち、２Ｄ再生専用ブロック（L3＋L4)2Dと３Ｄ再生専用ブロックの対L3SS、L4SSとの一方は他方の複製データである。
図３０に示されている各データ・ブロックは、３Ｄ再生専用ブロックL3SS、L4SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば、ファイル２Ｄのファイル・エントリ2410では、アロケーション記述子＃１が、第１の３Ｄエクステント・ブロック2401内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL1はファイル２Ｄの一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２が、第１の３Ｄエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL2とその直後の２Ｄ再生専用ブロック（L3＋L4)2Dとの対L2＋(L3＋L4)2Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックの対L2＋(L3＋L4)2Dはファイル２Ｄの一つの２ＤエクステントEXT2D[1]としてアクセス可能である。更に、アロケーション記述子＃３が、第２の３Ｄエクステント・ブロック2402内の三番目のベースビュー・データ・ブロックL5のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL5は別の一つの２ＤエクステントEXT2D[2]としてアクセス可能である。
第１ファイルＳＳのファイル・エントリ2420では、アロケーション記述子＃１、＃２、＃３、＃４、＃５が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3SS、R4＋L4SS、R5＋L5をそれぞれ一つのエクステントと見なして、各サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの各対R1＋L1、…、R5＋L5は第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]、EXTSS[4]としてアクセス可能である。２Ｄ再生専用ブロック（L3＋L4)2Dはファイル２ＤのエクステントEXT2D[1]の一部としてのみアクセス可能であり、各３Ｄ再生専用ブロックL3SS、L4SSは３ＤエクステントEXTSS[2]、EXTSS[3]の一部としてのみアクセス可能である。
図３１は、図３０に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路2501とＬ／Ｒモードでの再生経路2502とを示す模式図である。尚、デプス・モードでの再生経路は、図１５に示されているものから、当業者には容易に類推可能であろう。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路2501が示すとおり、まず第１の３Ｄエクステント・ブロック2401内の最後から二番目のベースビュー・データ・ブロックL1が最初の２ＤエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第１の３Ｄエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL2とその直後の２Ｄ再生専用ブロック（L3＋L4)2Dとの対L2＋(L3＋L4)2Dが二番目の２ＤエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2402の先端に位置する８個のデータ・ブロックD3、R3、L3SS、D4、R4、L4SS、D5、R5の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2402内の三番目のベースビュー・データ・ブロックL5が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路2502が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1＋L1が最初の３ＤエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の３ＤエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、２Ｄ再生専用ブロック（L3＋L4)2Dと第２の３Ｄエクステント・ブロック2402内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2402内の先頭のライトビュー・データ・ブロックR3とその直後の３Ｄ再生専用ブロックL3SSとが三番目の３ＤエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。同様に、次のライトビュー・データ・ブロックR4とその直後の３Ｄ再生専用ブロックL4SSとが四番目の３ＤエクステントEXTSS[3]として連続して読み出され、その直後のデプスマップ・データ・ブロックD5の読み出しが三番目のジャンプJLR3によってスキップされる。更に次のライトビュー・データ・ブロックR5とその直後のベースビュー・データ・ブロックL5とが五番目の３ＤエクステントEXTSS[4]として連続して読み出される。
図３１に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロック（L3＋L4)2Dは読み出されるが、３Ｄ再生専用ブロックL3SS、L4SSの読み出しはスキップされる。逆にＬ／Ｒモードでは、２Ｄ再生専用ブロック（L3＋L4)2Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL3SS、L4SSは読み出される。しかし、２Ｄ再生専用ブロック（L3＋L4)2Dと３Ｄ再生専用ブロックの対L3SS、L4SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置５ではロングジャンプJLYの前後で２Ｄ再生モードでの再生経路2501とＬ／Ｒモードでの再生経路2502とが分離されている。従って、層境界LBの直前に位置する２ＤエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。尚、デプス・モードについても同様である。
まず、２ＤエクステントEXT2D[1]のサイズSext2D[1]はベースビュー・データ・ブロックL2のサイズSext1[1]と２Ｄ再生専用ブロック（L3＋L4)2DのサイズS2Dとの和Sext1[1]＋S2Dに等しい。従って、２Ｄ再生モードでのシームレス再生の実現には、その和Sext1[1]＋S2Dが、２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する３ＤエクステントEXTSS[1]に属するライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2との各サイズSext2[1]、Sext1[1]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、２Ｄ再生専用ブロック（L3＋L4)2DのサイズS2Dの適切な拡大により、２ＤエクステントEXT2D[1]のサイズSext2D[1]＝Sext1[1]＋S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。
ここで、３Ｄ再生専用ブロックの対L3SS、L4SSは２Ｄ再生専用ブロック（L3＋L4)2Dの複製データであるので、２Ｄ再生専用ブロック（L3＋L4)2DのサイズS2Dの拡大は、各３Ｄ再生専用ブロックL3SS、L4SSの直前に位置するライトビュー・データ・ブロックR3、R4のサイズを拡大させる。しかし、一つの２Ｄ再生専用ブロック（L3＋L4)2Dに対して３Ｄ再生専用ブロックは二つL3SS、L4SSに分割されているので、各サイズは、図２２に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量は、Ｌ／Ｒモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置５では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが、再生装置２００のデコーダ内に確保されるべきバッファ容量を必要最小限に抑えたままで可能である。更に、２Ｄ再生モードとＬ／Ｒモードとで読み込み対象のデータ・ブロックを変更すること、特に２Ｄ再生専用ブロック（L3＋L4)2Dと３Ｄ再生専用ブロックの対L3SS、L4SSとの間の切り換えが、再生対象のＡＶストリーム・ファイルをファイル２ＤとファイルＳＳとの間で切り換えるだけで容易に実現可能である。尚、デプス・モードでも同様である。
配置５では、２Ｄ再生専用ブロック（L3＋L4)2Dの複製データが二個の３Ｄ再生専用ブロックL3SS、L4SSとして設けられている。その他に、複製データが三個以上の３Ｄ再生専用ブロックとして設けられていてもよい。
［配置６］
図３２は、記録媒体１００の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第６例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインＴＳ、ライトビュービデオストリームを含む第１サブＴＳ、及びデプスマップストリームを含む第２サブＴＳに属する。以下、この配置を「配置６」という。図３２を図３０と比較するに、配置６は配置５とは、２Ｄ再生専用ブロック（L2＋L3)2Dが単独で一つの２ＤエクステントEXT2D[1]としてアクセス可能である点で異なる。その他の特徴については配置６は配置５と同様であるので、その詳細についての説明は配置５についての説明を援用する。
層境界LBの直前に位置する２Ｄ再生専用ブロック（L2＋L3)2Dは第２の３Ｄエクステント・ブロック2602内の３Ｄ再生専用ブロックの対L2SS、L3SSとビット単位で一致する。すなわち、２Ｄ再生専用ブロック（L2＋L3)2Dと３Ｄ再生専用ブロックの対L2SS、L3SSとの一方は他方の複製データである。
図３２に示されている各データ・ブロックは、３Ｄ再生専用ブロックL2SS、L3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば、ファイル２Ｄのファイル・エントリ2610では、アロケーション記述子＃１は、第１の３Ｄエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL1のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL1は一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は２Ｄ再生専用ブロック（L2＋L3)2Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、２Ｄ再生専用ブロック（L2＋L3)2Dは次の２ＤエクステントEXT2D[1]としてアクセス可能である。アロケーション記述子＃３は、第２の３Ｄエクステント・ブロック2602内の三番目のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は三番目の２ＤエクステントEXT2D[2]としてアクセス可能である。
第１ファイルＳＳのファイル・エントリ2620では、アロケーション記述子＃１、＃２、＃３、＃４が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2SS、R3＋L3SS、R4＋L4をそれぞれ一つのエクステントと見なして、各サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの各対R1＋L1、…、R4＋L4は第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。２Ｄ再生専用ブロック（L2＋L3)2Dはファイル２Ｄの一つのエクステントEXT2D[1]としてのみアクセス可能であり、各３Ｄ再生専用ブロックL2SS、L3SSは３ＤエクステントEXTSS[1]、EXTSS[2]の一部としてのみアクセス可能である。
図３３は、図３２に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路2701とＬ／Ｒモードでの再生経路2702とを示す模式図である。尚、デプス・モードでの再生経路は、図１５に示されているものから、当業者には容易に類推可能であろう。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路2701が示すとおり、まず第１の３Ｄエクステント・ブロック2601内の最後のベースビュー・データ・ブロックL1が最初の２ＤエクステントEXT2D[0]として読み出される。次に、その直後の２Ｄ再生専用ブロック（L2＋L3)2Dが二番目の２ＤエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2602の先端に位置する８個のデータ・ブロックD2、R2、L2SS、D3、R3、L3SS、D4、R4の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2602内の三番目のベースビュー・データ・ブロックL4が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路2702が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1＋L1が最初の３ＤエクステントEXTSS[0]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、２Ｄ再生専用ブロック（L2＋L3)2Dと第２の３Ｄエクステント・ブロック2602内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。次に、第２の３Ｄエクステント・ブロック2602内の先頭のライトビュー・データ・ブロックR2とその直後の３Ｄ再生専用ブロックL2SSとが二番目の３ＤエクステントEXTSS[1]として連続して読み出され、その直後のデプスマップ・データ・ブロックD3の読み出しが最初のジャンプJLR1によってスキップされる。同様に、次のライトビュー・データ・ブロックR3とその直後の３Ｄ再生専用ブロックL3SSとが三番目の３ＤエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。更に次のライトビュー・データ・ブロックR4とその直後のベースビュー・データ・ブロックL4とが四番目の３ＤエクステントEXTSS[3]として連続して読み出される。
図３３に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロック（L2＋L3)2Dは読み出されるが、３Ｄ再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆にＬ／Ｒモードでは、２Ｄ再生専用ブロック（L2＋L3)2Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL2SS、L3SSは読み出される。しかし、２Ｄ再生専用ブロック（L2＋L3)2Dと３Ｄ再生専用ブロックの対L2SS、L3SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置６ではロングジャンプJLYの前後で２Ｄ再生モードでの再生経路2701とＬ／Ｒモードでの再生経路2702とが分離されている。従って、層境界LBの直前に位置する２ＤエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。尚、デプス・モードについても同様である。
まず、層境界LBの直前で連続する二つの２ＤエクステントEXT2D[0]、EXT2D[1]のサイズの和Sext2D[0]＋Sext2D[1]はベースビュー・データ・ブロックL1のサイズSext2D[0]と２Ｄ再生専用ブロック（L2＋L3)2DのサイズS2Dとの和Sext1[1]＋S2Dに等しい。従って、２Ｄ再生モードでのシームレス再生の実現には、その和Sext1[1]＋S2Dが、２ＤエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する３ＤエクステントEXTSS[0]に属するライトビュー・データ・ブロックR1のサイズSext2[0]とベースビュー・データ・ブロックL1との各サイズSext2[0]、Sext2D[0]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、２Ｄ再生専用ブロック（L2＋L3)2DのサイズS2Dの適切な拡大により、２Ｄエクステントの対EXT2D[0]、EXT2D[1]のサイズの和Sext2D[0]＋Sext2D[1]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext2D[0]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR1のサイズSext2[0]も更に小さく制限することができる。
ここで、３Ｄ再生専用ブロックの対L2SS、L3SSは２Ｄ再生専用ブロック（L2＋L3)2Dの複製データであるので、２Ｄ再生専用ブロック（L2＋L3)2DのサイズS2Dの拡大は、各３Ｄ再生専用ブロックL2SS、L3SSの直前に位置するライトビュー・データ・ブロックR2、R3のサイズを拡大させる。しかし、一つの２Ｄ再生専用ブロック（L2＋L3)2Dに対して３Ｄ再生専用ブロックは二つL2SS、L3SSに分割されているので、各サイズは、図２２に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量は、Ｌ／Ｒモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置６では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが、再生装置２００内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。更に、２Ｄ再生モードとＬ／Ｒモードとで読み込み対象のデータ・ブロックを変更すること、特に２Ｄ再生専用ブロック（L2＋L3)2Dと３Ｄ再生専用ブロックの対L2SS、L3SSとの間の切り換えが、再生対象のＡＶストリーム・ファイルをファイル２ＤとファイルＳＳとの間で切り換えるだけで容易に実現可能である。尚、デプス・モードでも同様である。
配置６では、２Ｄ再生専用ブロック（L2＋L3)2Dの複製データが二個の３Ｄ再生専用ブロックL2SS、L3SSとして設けられている。その他に、複製データが図２８のように一個の３Ｄ再生専用ブロックとして設けられてもよく、又は三個以上の３Ｄ再生専用ブロックとして設けられていてもよい。
尚、配置１−５とは異なり、２Ｄ再生専用ブロックはファイル２Ｄの二個以上のエクステントとしてアクセス可能であってもよい。更に、各データ・ブロックは二種類以上のファイル２Ｄ又はファイルＳＳのエクステントとしてアクセス可能であってもよい。
＜Ｌ／Ｒモードのみに対応する多重化ストリーム・データの配置＞
３Ｄ映像の再生にＬ／Ｒモードのみが利用されるとき、上記の配置１−６からデプスマップ・データ・ブロックが除去されてもよい。図３４の（ａ）は、図２８に示されている配置４からデプスマップ・データ・ブロックを除去したものを示す模式図である。これらのデータ・ブロック群は、レフトビューストリームを含むメインＴＳとライトビュービデオストリームを含むサブＴＳとに属する。図３４の（ａ）を参照するに、層境界LBの前に位置する第１の３Ｄエクステント・ブロック2801では、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されている。一方、層境界LBの後に位置する第２の３Ｄエクステント・ブロック2802では、ライトビュー・データ・ブロック群R3、R4、…、及びベースビュー・データ・ブロック群L3SS、L4、…がインターリーブ配置で記録されている。更に、第１の３Ｄエクステント・ブロック2801の後端L2と層境界LBとの間に２Ｄ再生専用ブロックL32Dが配置され、第２の３Ｄエクステント・ブロック2802の先端には３Ｄ再生専用ブロックL3SSが配置されている。それらのデータ・ブロックL32D、L3SSの一方は他方の複製データであり、ビット単位で一致する。
各３Ｄエクステント・ブロック2801、2802のインターリーブ配置では、ライトビュー・データ・ブロックとベースビュー・データ・ブロックとがその順で交互に並ぶ。更に、二つの連続するデータ・ブロックRn、Ln（n＝…、1、2、3、4、…）間ではエクステントＡＴＣ時間が等しい。第１の３Ｄエクステント・ブロック2801の後端に位置する二つのデータ・ブロックR2、L2と、第２の３Ｄエクステント・ブロック2802の先端に位置する二つのデータ・ブロックR3、L3SSとの間では、各ストリーム・データの内容が連続している。
図３４の（ａ）に示されている各データ・ブロックは、３Ｄ再生専用ブロックL3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば、ファイル２Ｄのファイル・エントリ2810では、アロケーション記述子＃１は、第１の３Ｄエクステント・ブロック2801内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL1は一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は、そのベースビュー・データ・ブロックの対L2＋L32Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックの対L2＋L32Dは二番目の２ＤエクステントEXT2D[1]としてアクセス可能である。アロケーション記述子＃３は、第２の３Ｄエクステント・ブロック2802内の二番目のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は三番目の２ＤエクステントEXT2D[2]としてアクセス可能である。
図３４の（ａ）に示されているデータ・ブロック群に対しても、ＡＶストリーム・ファイルのクロスリンクは図１５のものと同様に実現される。特に、各３Ｄエクステント・ブロック2801、2802からはデプスマップ・データ・ブロックが除去されているので、エクステントＡＴＣ時間の等しいライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上、連続して配置されてもよい。その場合、それら二つ以上の対が一つの３Ｄエクステントとしてアクセスされてもよい。図３４の（ａ）を参照するに、ファイルＳＳのファイル・エントリ2820では、アロケーション記述子＃１は、第１の３Ｄエクステント・ブロック2801のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR1、L1、R2、L2を一つのエクステントと見なして、それらの全体のサイズと先端のＬＢＮとを示す。従って、それらのデータ・ブロックR1、L1、R2、L2、は一つの３ＤエクステントEXTSS[0]としてアクセス可能である。アロケーション記述子＃２は、第２の３Ｄエクステント・ブロック2802のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR3、L3SS、R4、L4を一つのエクステントと見なして、それらの全体のサイズと先端のＬＢＮとを示す。従って、それらのデータ・ブロックR3、L3SS、R4、L4は次の３ＤエクステントEXTSS[1]としてアクセス可能である。ここで、３ＤエクステントEXTSS[0]、EXTSS[1]はそれぞれ、ベースビュー・データ・ブロックL1、L2、L4を２ＤエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]と共有する。一方、２Ｄ再生専用ブロックL32Dは、層境界LBの直前に位置する２ＤエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、３Ｄ再生専用ブロックL3SSは、層境界LBの直後の３ＤエクステントEXTSS[1]の一部としてのみアクセス可能である。
図３４の（ｂ）は、図３４の（ａ）に示されているデータ・ブロック群に対する２Ｄ再生モードでの再生経路2803とＬ／Ｒモードでの再生経路2804とを示す模式図である。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、２Ｄ再生モードでの再生経路2803が示すとおり、まず第１の３Ｄエクステント・ブロック2801内の最後から二番目のベースビュー・データ・ブロックL1が最初の２ＤエクステントEXT2D[0]として読み出され、その直後のライトビュー・データ・ブロックR2の読み出しが最初のジャンプJ2D1によってスキップされる。次に、第１の３Ｄエクステント・ブロック2801内の最後のベースビュー・データ・ブロックL2とその直後の２Ｄ再生専用ブロックL32Dとの対L2＋L32Dが二番目の２ＤエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第２の３Ｄエクステント・ブロック2802の先端に位置する３個のデータ・ブロックR3、L3SS、R4の読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2802内の二番目のベースビュー・データ・ブロックL4が三番目の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／ＲモードではファイルＳＳを再生する。従って、Ｌ／Ｒモードでの再生経路2804が示すとおり、まず第１の３Ｄエクステント・ブロック2801内のデータ・ブロック群R1、L1、R2、L2が最初の３ＤエクステントEXTSS[0]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、２Ｄ再生専用ブロックL32Dの読み出しがスキップされる。続いて、第２の３Ｄエクステント・ブロック2802内のデータ・ブロック群R3、L3SS、R4、L4とが次の３ＤエクステントEXTSS[1]として連続して読み出される。
図３４の（ｂ）に示されているとおり、２Ｄ再生モードでは、２Ｄ再生専用ブロックL32Dは読み出されるが、３Ｄ再生専用ブロックL3SSの読み出しはスキップされる。逆に、Ｌ／Ｒモードでは、２Ｄ再生専用ブロックL32Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL3SSは読み出される。しかし、両方のデータ・ブロックL32D、L3SSはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置４では、Ｌ／Ｒモードのみに対応可能な場合でも、ロングジャンプJLYの前後で２Ｄ再生モードでの再生経路2801とＬ／Ｒモードでの再生経路2802とが分離されている。従って、２Ｄ再生専用ブロックL32DのサイズS2Dを適切に拡大することにより、２ＤエクステントEXT2D[1]のサイズSext2D[1]＝Sext1[1]＋S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。その結果、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量をＬ／Ｒモードでのシームレス再生に必要最小限の値に更に接近させることができる。
続いて、配置１からデプスマップ・データ・ブロックを除去した例について説明する。
図３５は、図２０に示されている配置１からデプスマップ・データ・ブロックを除去したものを示す模式図である。これらのデータ・ブロック群は、レフトビューストリームを含むメインＴＳとライトビュービデオストリームを含むサブＴＳとに属する。図３５に示すように、層境界LBの前に位置する第１記録層には、ライトビュー・データ・ブロック群…、R0、R1、及びベースビュー・データ・ブロック群…、L0、L1がインターリーブ配置された第１の３Ｄエクステント・ブロック2005が記録されている。また、第１の３Ｄエクステント・ブロック2005の後端L1に連続して２Ｄ再生専用ブロックL22D、L32Dが配置されている。更に、２Ｄ再生専用ブロックL32Dと層境界LBとの間には、ライトビュー・データ・ブロックR2、R3、及び３Ｄ再生専用ブロックL2SS、L3SSがインターリーブ配置された第２の３Ｄエクステント・ブロック2006が記録されている。
２Ｄ再生専用ブロックL22D、L32Dと３Ｄ再生専用ブロックL2SS、L3SSとの一方は他方の複製データであり、ビット単位で一致する。一方、層境界LBの後に位置する第２記録層には、ライトビュー・データ・ブロック群R4、…、及びベースビュー・データ・ブロック群L4、…がインターリーブ配置された第３の３Ｄエクステント・ブロック2007が記録されている。
各３Ｄエクステント・ブロック2005、2006、2007のインターリーブ配置では、ライトビュー・データ・ブロックとベースビュー・データ・ブロックとがその順で交互に並ぶ。更に、二つの連続するデータ・ブロックRn、Ln（n＝…、1、2、3、4、…）間ではエクステントＡＴＣ時間が等しい。第１の３Ｄエクステント・ブロック2005の後端に位置する二つのデータ・ブロックR1、L1と、第２の３Ｄエクステント・ブロック2006の先端に位置する二つのデータ・ブロックR2、L2SSとの間では、各ストリーム・データの内容が連続し、第２の３Ｄエクステント・ブロック2006の後端に位置する二つのデータ・ブロックR3、L3SSと、第３の３Ｄエクステント・ブロック2007の先端に位置する二つのデータ・ブロックR4、L4との間では、各ストリーム・データの内容が連続している。
図３５に示されている各データ・ブロックは、３Ｄ再生専用ブロックL2SS、L3SSを除いて、ファイル２Ｄ又はファイルＤＥＰのいずれかのエクステントとしてアクセス可能である。例えば第１ファイル２Ｄのファイル・エントリ2010では、アロケーション記述子＃１が、第１の３Ｄエクステント・ブロック2005内の最後から二番目のベースビュー・データ・ブロックL0のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL0は第１ファイル２Ｄの一つの２ＤエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子＃２は、第１の３Ｄエクステント・ブロック2001内の最後のベースビュー・データ・ブロックL1とその直後に連続する２Ｄ再生専用ブロック群L22D、L32Dとからなるベースビュー・データ・ブロックの一群L1+ L22D+L32Dを単一のエクステントと見なしてそのサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックの一群L1+ L22D+L32Dは、第１ファイル２Ｄの単一の２ＤエクステントEXT2D[1]としてアクセス可能である。これらのファイル２Ｄにおけるベースビュー・データ・ブロックL1、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステントを構成している。ファイル２Ｄは、ロングジャンプの直前で、ビックエクステントを形成することができるので、２Ｄ再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。また、第２ファイル２Ｄのファイル・エントリ2011では、アロケーション記述子＃１が、第３の３Ｄエクステント・ブロック2007内のベースビュー・データ・ブロックL4のサイズとその先端のＬＢＮとを示す。従って、そのベースビュー・データ・ブロックL4は第２ファイル２Ｄの一つの２ＤエクステントEXT2D[2]としてアクセス可能である。
図３５に示されているデータ・ブロック群に対しても、ＡＶストリーム・ファイルのクロスリンクは図１５のものと同様に実現される。特に、各３Ｄエクステント・ブロック2005、2006、2007からはデプスマップ・データ・ブロックが除去されているので、エクステントＡＴＣ時間の等しいライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上、連続して配置されてもよい。その場合、それら二つ以上の対が一つの３Ｄエクステントとしてアクセスされてもよい。図３５を参照するに、第１ファイルＳＳのファイル・エントリ2020では、アロケーション記述子＃１は、第１の３Ｄエクステント・ブロック2005のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR0、L0、R1、L1を一つのエクステントと見なして、それらの全体のサイズと先端のＬＢＮとを示す。従って、それらのデータ・ブロックR0、L0、R1、L1、は一つの３ＤエクステントEXTSS[0]としてアクセス可能である。アロケーション記述子＃２は、第２の３Ｄエクステント・ブロック2006のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR2、L2SS、R3、L3SSを一つのエクステントと見なして、それらの全体のサイズと先端のＬＢＮとを示す。従って、それらのデータ・ブロックR2、L2SS、R3、L3SSは次の３ＤエクステントEXTSS[1]としてアクセス可能である。また、第２ファイルＳＳのファイル・エントリ2021では、アロケーション記述子＃１が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4＋L4を一つのエクステントと見なして、サイズとその先端のＬＢＮとを示す。従って、隣接するデータ・ブロックの対R4＋L4は第２ファイルＳＳの３ＤエクステントEXTSS[4]としてアクセス可能である。
ここで、３ＤエクステントEXTSS[0]、EXTSS[1]はそれぞれ、ベースビュー・データ・ブロックL0、L1、L4を２ＤエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]と共有する。一方、２Ｄ再生専用ブロックL22D、L32Dは、層境界LBの前に位置する２ＤエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、３Ｄ再生専用ブロックL2SS、L3SSは、層境界LBの直後の３ＤエクステントEXTSS[1]の一部としてのみアクセス可能である。
図３５において、２Ｄプレイリスト及び３Ｄプレイリストは、何れもシームレスに接続する２つのプレイアイテム＃１、＃２を含む。２Ｄプレイリストの前方プレイアイテムは、第１ファイル２Ｄを参照する。３Ｄプレイリストの前方プレイアイテムは第１ファイルＳＳを参照し、３Ｄプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。上述のように、第１ファイル２Ｄの２ＤエクステントEXT2D[0]、EXT2D[1]と、第１ファイルＳＳの３ＤエクステントEXTSS[0]、EXTSS[1]とで参照するベースビューデータブロックの中身は同じである。これにより、２Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL1、L22D、L32Dを再生することになり、３Ｄプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1、L2SS、L3SSを再生することになる。従って、２Ｄプレイリストに基づく２Ｄ再生と３Ｄプレイリストに基づく３Ｄ再生とでは、再生経路は異なるが同じレフトビュー・ビデオ・フレームを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。２Ｄプレイリストの後方プレイアイテムは、第２ファイル２Ｄを参照する。３Ｄプレイリストの後方プレイアイテムは第２ファイルＳＳを参照し、３Ｄプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルＤＥＰを参照する。第２ファイル２Ｄと第２ファイルＳＳとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、２Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前２ＤエクステントEXT2D[1]の終端から、後方プレイアイテムにより参照される２ＤエクステントEXT2D[2]先頭までの距離は、２Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、３Ｄプレイリストの前方プレイアイテムにより参照されるジャンプ直前３Ｄエクステントブロック2006と後方プレイアイテムにより参照される３Ｄエクステントブロック2007間のジャンプ距離は、２Ｄ／３Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
再生装置２００は２Ｄ再生モードではファイル２Ｄを再生する。従って、ベースビュー・データ・ブロックL0が最初の２ＤエクステントEXT2D[0] として読み出され、ベースビュー・データ・ブロックL1とその直後の２Ｄ再生専用ブロックL22D、L32Dとが連続して二番目の２ＤエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が第２ファイル２Ｄの最初の２ＤエクステントEXT2D[2]として読み出される。
再生装置２００はＬ／Ｒモードでは第１ファイルＳＳを再生する。従って、まず第１の３Ｄエクステント・ブロック2005内のデータ・ブロック群R0、L0、R1、L1が最初の３ＤエクステントEXTSS[0]として連続して読み出され、第２の３Ｄエクステント・ブロック2006内のデータ・ブロック群R2、L2SS、R3、L3SSが二番目の３ＤエクステントEXTSS[1]として連続して読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後のベースビューデータブロックL4とが第２ファイルＳＳの最初の３ＤエクステントEXTSS[4]として読み出される。
このように、２Ｄ再生モードでは、２Ｄ再生専用ブロックL22D、L32Dは読み出されるが、３Ｄ再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆に、Ｌ／Ｒモードでは、２Ｄ再生専用ブロックL22D、L32Dの読み出しはスキップされるが、３Ｄ再生専用ブロックL2SS、L3SSは読み出される。しかし、データ・ブロックL22D、L2SSはビット単位で一致しており、データ・ブロックL32D、L3SSもビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置１では、３Ｄ再生としてＬ／Ｒモードのみに対応可能な場合でも、ロングジャンプの前で２Ｄ再生モードでの再生経路とＬ／Ｒモードでの再生経路とが分離されている。従って、２Ｄ再生専用ブロックL22D、L32DのサイズS2D[2]、S2D[3]を適切に拡大することにより、２ＤエクステントEXT2D[1]のサイズSext2D[1]＝Sext1[1]＋S2D[2]＋S2D[3]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。その結果、Ｌ／Ｒモードの再生装置２００内に確保されるべきリード・バッファの容量をＬ／Ｒモードでのシームレス再生に必要最小限の値に更に接近させることができる。他の配置２、３、５、及び６についても同様である。
このように、配置１−６がＬ／Ｒモードのみ対応可能なものであっても、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が２Ｄ再生モードとＬ／Ｒモードとの両方で実現可能であるようなサイズに設計することが、再生装置２００内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。

＜ＡＶストリーム・ファイルに含まれるその他のＴＳパケット＞
ＡＶストリーム・ファイルに含まれるＴＳパケットの種類には、図１０、１１に示されているエレメンタリ・ストリームから変換されたもの以外にも、ＰＡＴ（Program Association Table）、ＰＭＴ（Program Map Table）、及びＰＣＲ（Program Clock Reference）がある。ＰＣＲ、ＰＭＴ、及びＰＡＴは欧州デジタル放送規格で定められたものであり、本来は、一つの番組を構成するパーシャル・トランスポート・ストリームを規定する役割を持つ。ＰＣＲ、ＰＭＴ、及びＰＡＴを利用することで、ＡＶストリーム・ファイルも、そのパーシャル・トランスポート・ストリームと同様に規定される。具体的には、ＰＡＴは、同じＡＶストリーム・ファイルに含まれるＰＭＴのＰＩＤを示す。ＰＡＴ自身のＰＩＤは０である。ＰＭＴは、同じＡＶストリーム・ファイルに含まれる、映像・音声・字幕等を表す各エレメンタリ・ストリームのＰＩＤとその属性情報とを含む。ＰＭＴは更に、そのＡＶストリーム・ファイルに関する各種のディスクリプタ（記述子ともいう。）を含む。ディスクリプタには特に、そのＡＶストリーム・ファイルのコピーの許可／禁止を示すコピー・コントロール情報が含まれる。ＰＣＲは、自身に割り当てられたＡＴＳに対応させるべきＳＴＣ（System Time Clock）の値を示す情報を含む。ここで、ＳＴＣは、デコーダ内でＰＴＳ及びＤＴＳの基準として利用されるクロックである。デコーダはＰＣＲを利用して、ＡＴＣにＳＴＣを同期させる。
図３６は、ＰＭＴ2910のデータ構造を示す模式図である。ＰＭＴ2910は、ＰＭＴヘッダ2901、ディスクリプタ2902、及びストリーム情報2903を含む。ＰＭＴヘッダ2901は、ＰＭＴ2910に含まれるデータの長さ等を示す。各ディスクリプタ2902は、ＰＭＴ2910を含むＡＶストリーム・ファイルの全体に関するディスクリプタである。前述のコピー・コントロール情報はディスクリプタ2902の一つに含まれる。ストリーム情報2903は、ＡＶストリーム・ファイルに含まれる各エレメンタリ・ストリームに関する情報であり、一つずつ異なるエレメンタリ・ストリームに割り当てられている。各ストリーム情報2903は、ストリーム・タイプ2931、ＰＩＤ2932、及びストリーム・ディスクリプタ2933を含む。ストリーム・タイプ2931は、そのエレメンタリ・ストリームの圧縮に利用されたコーデックの識別情報等を含む。ＰＩＤ2932は、そのエレメンタリ・ストリームのＰＩＤを示す。ストリーム・ディスクリプタ2933は、そのエレメンタリ・ストリームの属性情報、例えばフレームレート及びアスペクト比を含む。
ＰＣＲ、ＰＭＴ、及びＰＡＴを利用することで、再生装置内のデコーダにＡＶストリーム・ファイルを、欧州デジタル放送規格に準拠のパーシャル・トランスポート・ストリームと同様に処理させることができる。それにより、記録媒体１００用の再生装置と欧州デジタル放送規格に準拠の端末装置との間の互換性を確保することができる。
以上がストリームファイルの詳細についての説明である。

＜クリップ情報ファイル＞
以下、クリップ情報ファイルの詳細について説明する。
図３７は、２Ｄクリップ情報ファイル531のデータ構造を示す模式図である。ディペンデントビュー・クリップ情報ファイルも同様なデータ構造を持つ。以下では、まず、クリップ情報ファイル全般に共通するデータ構造を２Ｄクリップ情報ファイル531のデータ構造を例に説明する。その後、２Ｄクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとのデータ構造上の相違点について説明する。
図３７を参照するに、２Ｄクリップ情報ファイル531は、クリップ情報3010、ストリーム属性情報3020、エントリ・マップ3030、及び３Ｄメタデータ3040を含む。３Ｄメタデータ3040はオフセット・テーブル3041とエクステント起点3042とを含む。
クリップ情報3010は、図３７に示されているように、システムレート3011、再生開始時刻3012、及び再生終了時刻3013を含む。システムレート3011は、対応するファイル２Ｄに属する“ＴＳパケット”が再生装置２００内でリード・バッファからシステム・ターゲット・デコーダへ転送される速度の最高値を示す。ファイル２Ｄでは、ＴＳパケットの転送速度がシステムレート以下に抑えられるように、ソースパケットのＡＴＳの間隔が設定されている。再生開始時刻3012は、ファイル２Ｄの先頭のＶＡＵのＰＴＳ、例えば先頭の映像フレームのＰＴＳを示す。再生終了時刻3012は、ファイル２Ｄの後端のＶＡＵのＰＴＳから所定量遅れたＳＴＣの値、例えば最後の映像フレームのＰＴＳに１フレーム当たりの再生時間を加えた値を示す。
ストリーム属性情報3020は、図３７に示されているように、ファイル２Ｄに含まれる各エレメンタリ・ストリームのＰＩＤ3021とその属性情報3022との間の対応表である。属性情報3022は、ビデオ・ストリーム、オーディオ・ストリーム、ＰＧストリーム、及びＩＧストリームのそれぞれで異なる。例えばプライマリ・ビデオ・ストリームのＰＩＤ０ｘ１０１１に対応付けられた属性情報は、そのビデオ・ストリームの圧縮に利用されたコーデックの種類、そのビデオ・ストリームを構成する各ピクチャの解像度、アスペクト比、及びフレームレートを含む。一方、プライマリ・オーディオ・ストリームのＰＩＤ０ｘ１１０１に対応付けられた属性情報は、そのオーディオ・ストリームの圧縮に利用されたコーデックの種類、そのオーディオ・ストリームに含まれるチャンネル数、言語、及びサンプリング周波数を含む。属性情報3022は再生装置２００により、デコーダの初期化に利用される。
［エントリ・マップ］
図３８の（ａ）は、エントリ・マップ3030のデータ構造を示す模式図である。図３８の（ａ）を参照するに、エントリ・マップ3030はテーブル3100を含む。テーブル3100は、メインＴＳに多重化されたビデオ・ストリームと同数であり、各ビデオ・ストリームに一つずつ割り当てられている。図３８の（ａ）では各テーブル3100が割り当て先のビデオ・ストリームのＰＩＤで区別されている。各テーブル3100はエントリ・マップ・ヘッダ3101とエントリ・ポイント3102とを含む。エントリ・マップ・ヘッダ3101は、そのテーブル3100に対応付けられたＰＩＤと、そのテーブル3100に含まれるエントリ・ポイント3102の総数とを含む。エントリ・ポイント3102は、ＰＴＳ3103とソースパケット番号（ＳＰＮ）3104との対を個別に異なるエントリ・ポイントＩＤ（ＥＰ＿ＩＤ）3105に対応付ける。さらに、エントリ・ポイント3102は、この特徴点へのアングル切り替えが可能であるか否かを示すフラグ(is＿angle＿changeフラグ)を具備している。マルチアングル区間を構成するインターリーブユニットの先頭に位置するソースパケットは、アングル切り替えが可能になっているため、インターリーブユニットの先頭ソースパケットを差すエントリーポイントのis＿angle＿changeフラグは、必ずオンに設定される。また、インターリーブユニットの先頭ソースパケットを差すエントリーポイントは、エントリーポイントによって、プレイアイテム情報におけるIn_Timeと対応付けられている。ＰＴＳ3103は、エントリ・マップ・ヘッダ3101の示すＰＩＤのビデオ・ストリームに含まれるいずれかのＩピクチャのＰＴＳに等しい。ＳＰＮ3104は、そのＩピクチャが格納されたソースパケット群の先頭のＳＰＮに等しい。「ＳＰＮ」とは、一つのＡＶストリーム・ファイルに属するソースパケット群に、先頭から順に割り当てられた通し番号をいう。ＳＰＮはそのＡＶストリーム・ファイル内での各ソースパケットのアドレスとして利用される。２Ｄクリップ情報ファイル531内のエントリ・マップ3030では、ＳＰＮは、ファイル２Ｄ541に属するソースパケット群、すなわちメインＴＳを構成するソースパケット群に割り当てられた番号を意味する。従って、エントリ・ポイント3102は、ファイル２Ｄ541に含まれるＩピクチャのＰＴＳとアドレス、すなわちＳＰＮとの間の対応関係を表す。
エントリ・ポイント3102は、ファイル２Ｄ541内の全てのＩピクチャに対して設定されていなくてもよい。但し、ＩピクチャがＧＯＰの先頭に位置し、かつ、そのＩピクチャの先頭を含むＴＳパケットが２Ｄエクステントの先頭に位置するときは、そのＩピクチャにはエントリ・ポイント3102を設定しなければならない。
図３８の（ｂ）は、ファイル２Ｄ541に属するソースパケット群3110のうち、エントリ・マップ3030によって各ＥＰ＿ＩＤ3105に対応付けられているものを示す模式図である。図３８の（ｃ）は、そのソースパケット群3110と記録媒体１００上のデータ・ブロック群3120との間の対応関係を示す模式図である。再生装置２００はファイル２Ｄ541から２Ｄ映像を再生するとき、エントリ・マップ3030を利用して、任意のシーンを表すフレームのＰＴＳから、そのフレームを含むソースパケットのＳＰＮを特定する。具体的には、再生装置２００は、再生開始位置として特定のエントリ・ポイントのＰＴＳ、例えばＰＴＳ＝３６００００が指定されたとき、まずエントリ・マップ3030から、そのＰＴＳに対応付けられたＳＰＮ＝３２００を検索する。再生装置２００は次に、そのＳＰＮとソースパケット一つ当たりのデータ量１９２バイトとの積をセクタ一つ当たりのデータ量２０４８バイトで割ったときの商ＳＰＮ／１９２×２０４８を求める。その値は、メインＴＳのうち、そのＳＰＮが割り当てられたソースパケットを含むアラインド・ユニットよりも前の部分が記録されたセクタの総数に等しい。図３８の（ｂ）に示されている例では、その値３２００×１９２／２０４８＝３００は、ＳＰＮが０から３１９９までのソースパケット群3111が記録されたセクタの総数に等しい。再生装置２００は続いてファイル２Ｄ541のファイル・エントリ内のアロケーション記述子を参照し、２Ｄエクステント群が記録されたセクタ群の先頭から数えて（上記の総数＋１）番目のセクタのＬＢＮを特定する。図３８の（ｃ）に示されている例では、２ＤエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…としてアクセス可能なベースビュー・データ・ブロックL1、L2＋L32D、L4、…が記録されたセクタ群のうち、先頭から数えて３０１番目のセクタのＬＢＮが特定される。再生装置２００はそのＬＢＮをＢＤ−ＲＯＭドライブに指定する。それにより、そのＬＢＮのセクタから順にベースビュー・データ・ブロック群がアラインド・ユニット単位で読み出される。再生装置２００は更に、最初に読み出されたアラインド・ユニットから、再生開始位置のエントリ・ポイントの示すソースパケットを選択してＩピクチャに復号する。それ以降、後続のピクチャは、先に復号されたピクチャを利用して順次復号される。こうして、再生装置２００はファイル２Ｄ541から特定のＰＴＳ以降の２Ｄ映像を再生できる。
エントリ・マップ3030は更に、早送り再生及び巻戻し再生等の特殊再生の効率的な処理に有利である。例えば２Ｄ再生モードの再生装置２００は、まずエントリ・マップ3030を参照して、再生開始位置、例えばＰＴＳ＝３６００００以降のＰＴＳを含むエントリ・ポイント、ＥＰ＿ＩＤ＝２、３、…からＳＰＮ＝３２００、４８００、…を順番に読み出す。再生装置２００は次にファイル２Ｄ541のファイル・エントリを利用して、各ＳＰＮに対応するセクタのＬＢＮを特定する。再生装置２００は続いて、各ＬＢＮをＢＤ−ＲＯＭドライブに指定する。それにより、各ＬＢＮのセクタからアラインド・ユニットが読み出される。再生装置２００は更に各アラインド・ユニットから、各エントリ・ポイントの示すソースパケットを選択してＩピクチャに復号する。こうして、再生装置２００は２Ｄエクステント群EXT2D[n]自体を解析することなく、ファイル２Ｄ541からＩピクチャを選択的に再生できる。
［オフセット・テーブル］
図３９の（ａ）はオフセット・テーブル3041のデータ構造を示す模式図である。オフセット・テーブル3041は、３Ｄ再生モードの再生装置２００によるクロッピング処理に利用される情報である。「クロッピング処理」とは、２Ｄ映像を表すデータから、レフトビューとライトビューとを表すプレーン・データの対を生成する処理をいう。「プレーン・データ」とは画素データの二次元配列を意味し、その配列のサイズは映像フレームの解像度に等しい。一組の画素データは色座標値とα値（不透明度）との組み合わせから成る。色座標値はＲＧＢ値又はＹＣｒＣｂ値で表される。クロッピング処理の対象には、メインＴＳ内のＰＧストリーム、ＩＧストリーム、及びセカンダリ・ビデオ・ストリームのそれぞれから生成されるプレーン・データ、並びに、ＢＤ−Ｊオブジェクトに従って生成されるイメージ・プレーン・データが含まれる。クロッピング処理はプレーン・データ内での各画素データの位置を水平方向に変化させる。従って、クロッピング処理によって得られるプレーン・データの対ではレフトビューとライトビューとの各表示位置が元の２Ｄ映像の表示位置から左右にずれている。それらの変位が視聴者に両眼視差として知覚されることにより、レフトビューとライトビューとの対がその視聴者には一つの３Ｄ映像として見える。
図３９の（ａ）を参照するに、オフセット・テーブル3041は、ＰＧストリーム、ＩＧストリーム、及びセカンダリ・ビデオ・ストリームのＰＩＤ別にテーブル3210を含む。各テーブル3210はＰＴＳ3201とオフセット値3202との対応表である。ＰＴＳ3201は、ＰＧストリーム、ＩＧストリーム、及びセカンダリ・ビデオ・ストリームから生成される各プレーン・データの表示時刻を表す。オフセット値3202は、クロッピング処理による各画素データの水平方向の変位量を符号付きの画素数で表したものである。例えばプラス符号は右向きの変位を表し、マイナス符号はその逆である。オフセット値3202の符号は、３Ｄ映像の奥行きが画面よりも手前か奥かに依って決められている。以下、ＰＴＳ3201とオフセット値3202との対3203を「オフセット・エントリ」という。
図３９の（ｂ）は、オフセット・エントリの有効区間を表す模式図である。各オフセット・エントリの有効区間は、ＳＴＣで計られる時間において、そのオフセット・エントリのＰＴＳの示す時刻から、次のオフセット・エントリのＰＴＳの示す時刻までの期間である。プレーン・データのＰＴＳがあるオフセット・エントリの有効区間に属するとき、クロッピング処理では、そのプレーン・データ内の画素データの表示位置が、そのオフセット・エントリのオフセット値だけ変化する。図３９の（ａ）に示されている例では、オフセット・エントリ＃１のＰＴＳが１８００００であり、オフセット・エントリ＃２のＰＴＳが２７００００であり、オフセット・エントリ＃３のＰＴＳが３６００００である。その場合、図３９の（ｂ）に示されているように、オフセット・エントリ＃１のオフセット値“＋５”は、１８００００から２７００００までのＳＴＣの範囲3204で有効であり、オフセット・エントリ＃２のオフセット値“＋３”は、２７００００から３６００００までのＳＴＣの範囲3205で有効である。
［エクステント起点］
図４０の（ａ）は、２Ｄクリップ情報ファイルに含まれるエクステント起点3042のデータ構造を示す模式図である。図４０の（ａ）を参照するに、「エクステント起点（Extent＿Start＿Point）」3042は、ベースビュー・エクステントＩＤ（ＥＸＴ１＿ＩＤ）3311とＳＰＮ3312とを含む。ＥＸＴ１＿ＩＤ3311は、第１ファイルＳＳ（01000.ssif）544Aに属する各ベースビュー・データ・ブロックに、先頭から順に割り当てられた通し番号である。ＳＰＮ3312は各ＥＸＴ１＿ＩＤ3311に一つずつ割り当てられ、そのＥＸＴ１＿ＩＤ3311で識別されるベースビュー・データ・ブロックの先端に位置するソースパケットのＳＰＮに等しい。ここで、そのＳＰＮは、第１ファイルＳＳ544Aに属するベースビュー・データ・ブロック群に含まれる各ソースパケットに、先頭から順に割り当てられた通し番号である。
図１５に示されているインターリーブ配置のデータ・ブロック群ではベースビュー・データ・ブロックはファイル２Ｄと、これに対応するファイルＳＳとに共有される。しかし、図２０、２４、２６、２８、３０、３２に示されてる配置１−５では、２Ｄ再生専用ブロックはファイル２Ｄにのみ属し、３Ｄ再生専用ブロックはファイルＳＳにのみ属する。従って、エクステント起点3042の示すＳＰＮ3312は、ファイル２Ｄに属する２Ｄエクステントの先端に位置するソースパケットのＳＰＮとは一般に異なる。
図４０の（ｂ）は、ライトビュー・クリップ情報ファイルに含まれるエクステント起点3320のデータ構造を示す模式図である。図４０の（ｂ）を参照するに、エクステント起点3320は、ライトビュー・エクステントＩＤ（ＥＸＴ２＿ＩＤ）3321とＳＰＮ3322とを含む。ＥＸＴ２＿ＩＤ3321は、第１ファイルＳＳ544Aに属する各ライトビュー・データ・ブロックに、先頭から順に割り当てられた通し番号である。ＳＰＮ3322は各ＥＸＴ２＿ＩＤ3321に一つずつ割り当てられ、そのＥＸＴ２＿ＩＤ3321で識別されるライトビュー・データ・ブロックの先端に位置するソースパケットのＳＰＮに等しい。ここで、そのＳＰＮは、第１ファイルＳＳ544Aに属するライトビュー・データ・ブロック群に含まれる各ソースパケットに、先頭から順に割り当てられた通し番号である。
図４０の（ｄ）は、第１ファイルＤＥＰ（02000.m2ts）に属するライトビュー・エクステントEXT2[0]、EXT2[1]、…と、エクステント起点3320の示すＳＰＮ3322との間の対応関係を表す模式図である。図１５、２０、２４、２６、２８、３０、３２のいずれに示されているデータ構造でも、ライトビュー・データ・ブロックは第１ファイルＤＥＰと第１ファイルＳＳとに共有される。従って、図４０の（ｄ）に示されているように、エクステント起点3320の示す各ＳＰＮ3322は、各ライトビュー・エクステントEXT2[0]、EXT2[1]、…の先端に位置するソースパケットのＳＰＮに等しい。
２Ｄクリップ情報ファイルのエクステント起点3042とライトビュー・クリップ情報ファイルのエクステント起点3320とは、以下に説明するように、第１ファイルＳＳ544Aから３Ｄ映像が再生されるとき、各３Ｄエクステントに含まれるデータ・ブロックの境界の検出に利用される。
図４０の（ｅ）は、第１ファイルＳＳ544Aに属する３ＤエクステントEXTSS[0]、EXTSS[1]、…と記録媒体１００上のデータ・ブロック群3350との間の対応関係の一例を示す模式図である。図４０の（ｅ）を参照するに、データ・ブロック群3350は、図２６に示されている配置３と同様である。尚、以下の説明は、インターリーブ配置、及び配置１−５の何れのデータ構造でも同様に成立する。データ・ブロック群3350では、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3SS、R4＋L4がそれぞれ、３ＤエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。更に、ｎ番目の３ＤエクステントEXTSS[n]（n＝0、1、2、…）では、ベースビュー・データ・ブロックL(n＋1)に含まれるソースパケットの数は、エクステント起点3042において、ＥＸＴ１＿ＩＤ＝ｎ＋１、ｎのそれぞれに対応するＳＰＮ間の差Ａ(ｎ＋１)−Ａｎに等しい（ここで、Ａ０＝０）。一方、ライトビュー・データ・ブロックR(n＋1)に含まれるソースパケットの数は、エクステント起点3320において、ＥＸＴ２＿ＩＤ＝ｎ＋１、ｎのそれぞれに対応するＳＰＮ間の差Ｂ(ｎ＋１)−Ｂｎに等しい（ここで、Ｂ０＝０）。
Ｌ／Ｒモードの再生装置２００は第１ファイルＳＳ544Aから３Ｄ映像を再生するとき、各クリップ情報ファイルのエントリ・マップに加え、エクステント起点3042、3320を利用して、任意のシーンのライトビューを表すフレームのＰＴＳから、そのフレームを含むライトビュー・データ・ブロックが記録されたセクタのＬＢＮを特定する。具体的には、再生装置２００はまず、例えばライトビュー・クリップ情報ファイル532のエントリ・マップから、そのＰＴＳに対応付けられたＳＰＮを検索する。仮に、そのＳＰＮの示すソースパケットが第１ファイルＤＥＰの３番目のライトビュー・エクステントEXT2[2]、すなわちライトビュー・データ・ブロックR3に含まれる場合を想定する。再生装置２００は次に、ライトビュー・クリップ情報ファイルのエクステント起点3320の示すＳＰＮ3322の中から、目標のＳＰＮ以下で最大のもの“Ｂ２”と、それに対応するＥＸＴ２＿ＩＤ“２”とを検索する。再生装置２００は続いて、２Ｄクリップ情報ファイルのエクステント起点3042から、そのＥＸＴ２＿ＩＤ“２”と等しいＥＸＴ１＿ＩＤに対応するＳＰＮ3312の値“Ａ２”を検索する。再生装置２００は更に、検索されたＳＰＮ3024、3320の値の和Ｂ２＋Ａ２を求める。図４０の（ｅ）から理解されるように、その和Ｂ２＋Ａ２は、３Ｄエクステント群EXTSS[0]、EXTSS[1]、…に含まれるデータ・ブロックのうち、３番目のライトビュー・データ・ブロックR3よりも前に配置されたものに含まれるソースパケットの総数に等しい。従って、その和Ｂ２＋Ａ２とソースパケット一つ当たりのデータ量１９２バイトとの積をセクタ一つ当たりのデータ量２０４８バイトで割ったときの商（Ｂ２＋Ａ２）×１９２／２０４８は、３Ｄエクステント群の先頭から３番目のライトビュー・データ・ブロックR3の直前までのセクタ数に等しい。この商を利用して第１ファイルＳＳ544Aのファイル・エントリ内のアロケーション記述子を辿れば、そのライトビュー・データ・ブロックR3の先端が記録されたセクタのＬＢＮを特定することができる。
再生装置２００は、上記のようにＬＢＮを特定した後、そのＬＢＮをＢＤ−ＲＯＭドライブに指定する。それにより、そのＬＢＮのセクタ以降に記録された３Ｄエクステント群、すなわち３番目のライトビュー・データ・ブロックR3以降の３Ｄエクステント群がアラインド・ユニット単位で読み出される。
再生装置２００は更にエクステント起点3042、3320を利用して、読み出された各３Ｄエクステントから、ディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとを交互に抽出する。例えば、図４０の（ｅ）に示されているデータ・ブロック群3350から３Ｄエクステント群EXTSS[n]（n＝0、1、2、…）が順番に読み出されるときを想定する。再生装置２００はまず、最初の３ＤエクステントEXTSS[0]の先頭からＢ１個のソースパケットを最初のディペンデントビュー・データ・ブロックR1として抽出する。再生装置２００は次に、Ｂ１番目のソースパケットと、それに続く（Ａ１−１）個のソースパケットとの計Ａ１個のソースパケットを最初のベースビュー・データ・ブロックL1として抽出する。再生装置２００は続いて、（Ｂ１＋Ａ１）番目のソースパケットと、それに続く（Ｂ２−Ｂ１−１）個のソースパケットとの計（Ｂ２−Ｂ１）個のソースパケットを二番目のディペンデントビュー・データ・ブロックR2として抽出する。再生装置２００は更に、（Ａ１＋Ｂ２）番目のソースパケットと、それに続く（Ａ２−Ａ１−１）個のソースパケットとの計（Ａ２−Ａ１）個のソースパケットを二番目のベースビュー・データ・ブロックL2として抽出する。それ以降も再生装置２００は同様に、読み出されるソースパケットの数から各３Ｄエクステント内のデータ・ブロック間の境界を検出して、ディペンデントビューとベースビューとの各データ・ブロックを交互に抽出する。抽出されたベースビュー・データ・ブロックとライトビュー・データ・ブロックとはパラレルにシステム・ターゲット・デコーダに渡されて復号される。
こうして、Ｌ／Ｒモードの再生装置２００は第１ファイルＳＳ544Aから特定のＰＴＳ以降の３Ｄ映像を再生できる。その結果、再生装置２００は、ＢＤ−ＲＯＭドライブの制御に関する上記の利点（Ａ）、（Ｂ）を実際に享受できる。
≪ファイル・ベース≫
図４０の（ｃ）は、Ｌ／Ｒモードの再生装置２００によって第１ファイルＳＳ544Aから抽出されたベースビュー・データ・ブロックL1、L2、…を表す模式図である。図４０の（ｅ）に示されているデータ・ブロック群3350は２Ｄ再生専用ブロックL32Dと３Ｄ再生専用ブロックL3SSとの両方を含む。しかし、図４０の（ｃ）に示されているベースビュー・データ・ブロック群は、ファイル２Ｄの２Ｄエクステント群とは異なり、２Ｄ再生専用ブロックL32Dに代えて３Ｄ再生専用ブロックL3SSを含む。従って、エクステント起点3042の示すＳＰＮ3312は、各ベースビュー・データ・ブロックの先端に位置するソースパケットのＳＰＮに等しい。図４０の（ｃ）に示されているベースビュー・データ・ブロック群のように、エクステント起点を利用して一つのファイルＳＳから抽出されるベースビュー・データ・ブロック群を「ファイル・ベース」という。更に、ファイル・ベースに含まれるベースビュー・データ・ブロックを「ベースビュー・エクステント」という。各ベースビュー・エクステントは、図４０の（ｃ）に示されているように、２Ｄクリップ情報ファイル内のエクステント起点によって参照される。
ベースビュー・エクステントは、２Ｄ再生専用ブロックと３Ｄ再生専用ブロックとを除き、２Ｄエクステントと実体、すなわちベースビュー・データ・ブロックを共有する。更に、互いに対応する２Ｄ再生専用ブロックと３Ｄ再生専用ブロックとはビット単位で一致する。従って、ファイル・ベースはファイル２Ｄと同じメインＴＳを含む。しかし、ベースビュー・エクステントは２Ｄエクステントとは異なり、いずれのファイルのファイル・エントリ内のアロケーション記述子によっても参照されない。上記のとおり、ベースビュー・エクステントは、クリップ情報ファイル内のエクステント起点を利用して、ファイルＳＳ内の３Ｄエクステントから抽出される。このように、ファイル・ベースは、図７に示されている本来のファイルとは異なり、ファイル・エントリを含まず、かつ、ベースビュー・エクステントの参照にエクステント起点を必要とする。それらの意味で、ファイル・ベースは「仮想的なファイル」である。特にファイル・ベースはファイルシステムでは認識されず、図７に示されているディレクトリ／ファイル構造には現れない。
記録媒体１００上に記録された３Ｄ映像コンテンツは、メインＴＳに対するサブＴＳを一種類だけ含むものでもよい。図４１は、そのコンテンツを含むデータ・ブロック群の配置の一例を示す模式図である。図４１を参照するに、データ・ブロック群3400は、ディペンデントビュー・データ・ブロックD[n]（n＝…、0、1、2、3、…）とベースビュー・データ・ブロックB[n]とを一種類ずつ含む。層境界LBの前にはディペンデントビュー・データ・ブロック群…、D[0]、D[1]とベースビュー・データ・ブロック群…、B[0]、B[1]とがインターリーブ配置で記録され、第１の３Ｄエクステント・ブロック3401を構成している。第１の３Ｄエクステント・ブロック3401の後端B[1]と層境界LBとの間には２Ｄ再生専用ブロックB[2]2Dが配置されている。一方、層境界LBの後にはディペンデントビュー・データ・ブロック群D[2]、D[3]、…とベースビュー・データ・ブロック群B[2]SS、B[3]、…とがインターリーブ配置で記録され、第２の３Ｄエクステント・ブロック3402を構成している。第２の３Ｄエクステント・ブロック3402内の先頭のベースビュー・データ・ブロックB[2]SSは３Ｄ再生専用ブロックであり、２Ｄ再生専用ブロックB[2]2Dとビット単位で一致する。
図４１には、データ・ブロック群3400とファイル２Ｄ3410のエクステント群との間の対応関係も示されている。第１の３Ｄエクステント・ブロック3401内のベースビュー・データ・ブロック…、B[0]、B[1]は、最後のものB[1]を除き、単独で一つの２Ｄエクステント…、EXT2D[0]としてファイル２Ｄ3410に属する。第１の３Ｄエクステント・ブロック3401内の最後のベースビュー・データ・ブロックB[1]は、その直後の２Ｄ再生専用ブロックB[2]2Dとの対で一つの２ＤエクステントEXT2D[1]としてファイル２Ｄ3410に属する。第２の３Ｄエクステント・ブロック3402内のベースビュー・データ・ブロックB[3]、…は、３Ｄ再生専用ブロックB[2]SSを除き、２ＤエクステントEXT2D[2]、…としてファイル２Ｄ3410に属する。各２Ｄエクステントはファイル２Ｄ3410のファイル・エントリ内のアロケーション記述子を参照データとして利用することによってアクセス可能である。
図４１には、データ・ブロック群3400とファイルＤＥＰ3412のエクステント群との間の対応関係も示されている。第１の３Ｄエクステント・ブロック3401内の各ディペンデントビュー・データ・ブロック…、D[0]、D[1]、及び第２の３Ｄエクステント・ブロック3402内の各ディペンデントビュー・データ・ブロックD[2]、D[3]、…はディペンデントビュー・エクステント…、EXT2[0]、EXT2[1]、EXT2[2]、…としてファイルＤＥＰ3412に属する。各ディペンデントビュー・エクステントはファイルＤＥＰ3412のファイル・エントリ内のアロケーション記述子を参照データとして利用することによってアクセス可能である。
図４１には、データ・ブロック群3400とファイルＳＳ3420のエクステント群との間の対応関係も示されている。データ・ブロック群3400は、図１５に示されているものとは異なり、デプスマップ・データ・ブロックを含まない。従って、いずれの３Ｄエクステント・ブロック3401、3402内のインターリーブ配置でも、ディペンデントビュー・データ・ブロック…、D[0]、D[1]、D[2]、D[3]、…とベースビュー・データ・ブロック…、B[0]、B[1]、B[2]SS、B[3]、…とは交互に連続している。その場合、ファイルＳＳ3420は、エクステントＡＴＣ時間の等しいディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上連続する部分を一つの３Ｄエクステントとして含んでもよい。図４１では、第１の３Ｄエクステント・ブロック3401内の二つの連続するディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対D[0]＋B[0]、D[1]＋B[1]が、一つの３ＤエクステントEXTSS[0]としてファイルＳＳ3420に属する。更に、第２の３Ｄエクステント・ブロック3402内の二つの連続するディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対D[2]＋B[2]SS、D[3]＋B[3]が、一つの３ＤエクステントEXTSS[1]としてファイルＳＳ3420に属する。３ＤエクステントEXTSS[0]、EXTSS[1]は、２ＤエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、EXT2D[3]とはベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]を共有し、ディペンデントビュー・エクステントEXT2[0]、EXT2[1]、EXT2[2]、EXT2[3]とはディペンデントビュー・データ・ブロックD[0]、D[1]、D[2]、D[3]を共有する。各３ＤエクステントはファイルＳＳ3420のファイル・エントリ内のアロケーション記述子を参照データとして利用してアクセス可能である。
再生装置２００は３ＤエクステントEXTSS[0]、EXTSS[1]を読み込んだ後、ファイル２Ｄ3410とファイルＤＥＰ3412とのそれぞれに対応するクリップ情報ファイル内のエクステント起点を利用して、各３ＤエクステントEXTSS[0]、EXTSS[1]からベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]を抽出する。それらのベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]はベースビュー・エクステントEXT1[0]、EXT1[1]、EXT1[2]、EXT1[3]としてファイル・ベース3411に属する。各ベースビュー・エクステントEXT1[0]、EXT1[1]、EXT1[2]、EXT1[3]は、ファイル２Ｄ3410に対応する２Ｄクリップ情報ファイル内のエクステント起点によって参照される。
以下、特に区別する必要がない限り、ベースビュー・データ・ブロックは（２Ｄ再生専用ブロックを除いて）ベースビュー・エクステントと同一視し、ディペンデントビュー・データ・ブロックはディペンデントビュー・エクステントと同一視する。
≪ディペンデントビュー・クリップ情報ファイル≫
ディペンデントビュー・クリップ情報ファイルは、図３７−図４０に示されている２Ｄクリップ情報ファイルとデータ構造が同様である。従って、以下の説明では、ディペンデントビュー・クリップ情報ファイルと２Ｄクリップ情報ファイルとの間の相違点に触れ、同様な点については上記の説明を援用する。
ディペンデントビュー・クリップ情報ファイルは２Ｄクリップ情報ファイルとは次の三点（ｉ）、（ｉｉ）、（ｉｉｉ）で異なる：（ｉ）ストリーム属性情報に条件が課せられている；（ｉｉ）エントリ・ポイントに条件が課せられている；（ｉｉｉ）３Ｄメタデータがオフセット・テーブルを含まない。
（ｉ）ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとがＬ／Ｒモードの再生装置２００によって３Ｄ映像の再生に利用されるべきものであるとき、ライトビュービデオストリームであるディペンデントビュー・ビデオ・ストリームはベースビュー・ビデオ・ストリームを利用して圧縮されている。そのとき、ディペンデントビュー・ビデオ・ストリームはベースビュー・ビデオ・ストリームとビデオ・ストリーム属性が等しく揃えられる。ここで、ベースビュー・ビデオ・ストリームに関するビデオ・ストリーム属性情報は、２Ｄクリップ情報ファイルのストリーム属性情報3020内でＰＩＤ＝０ｘ１０１１に対応付けられている。ディペンデントビュー・ビデオ・ストリームに関するビデオ・ストリーム属性情報は、ディペンデントビュー・クリップ情報ファイルのストリーム属性情報内でＰＩＤ＝０ｘ１０１２又は０ｘ１０１３に対応付けられている。従って、それらのビデオ・ストリーム属性情報間では、図３７に示されている各項目、すなわち、コーデック、解像度、アスペクト比、及びフレームレートが一致しなければならない。コーデックの種類が一致していれば、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとのピクチャ間に符号化での参照関係が成立するので、各ピクチャを復号することができる。解像度、アスペクト比、及びフレームレートがいずれも一致していれば、左右の映像の画面表示を同期させることができる。それ故、それらの映像を３Ｄ映像として視聴者に違和感を与えることなく見せることができる。
（ｉｉ）ディペンデントビュー・クリップ情報ファイルのエントリ・マップは、ディペンデントビュー・ビデオ・ストリームに割り当てられたテーブルを含む。そのテーブルは、図３８の（ａ）に示されているもの3100と同様に、エントリ・マップ・ヘッダとエントリ・ポイントとを含む。エントリ・マップ・ヘッダは、対応するディペンデントビュー・ビデオ・ストリームのＰＩＤ、すなわち０ｘ１０１２又は０ｘ１０１３を示す。各エントリ・ポイントは一対のＰＴＳとＳＰＮとを一つのＥＰ＿ＩＤに対応付けている。各エントリ・ポイントのＰＴＳは、ディペンデントビュー・ビデオ・ストリームに含まれるいずれかのＧＯＰの先頭のピクチャのＰＴＳと等しい。各エントリ・ポイントのＳＰＮは、同じエントリ・ポイントに属するＰＴＳの示すピクチャが格納されたソースパケット群の先頭のＳＰＮに等しい。ここで、ＳＰＮは、ファイルＤＥＰに属するソースパケット群、すなわちサブＴＳを構成するソースパケット群に先頭から順に割り当てられた通し番号を意味する。各エントリ・ポイントのＰＴＳは、２Ｄクリップ情報ファイルのエントリ・マップのうち、ベースビュー・ビデオ・ストリームに割り当てられたテーブル内のエントリ・ポイントのＰＴＳと一致しなければならない。すなわち、同じ３Ｄ・ＶＡＵに含まれる一対のピクチャの一方を含むソースパケット群の先頭にエントリ・ポイントが設定されているときは、常に、他方を含むソースパケット群の先頭にもエントリ・ポイントが設定されていなければならない。
図４２は、ベースビュー・ビデオ・ストリーム3510とディペンデントビュー・ビデオ・ストリーム3520とに設定されたエントリ・ポイントの例を示す模式図である。各ビデオ・ストリーム3510、3520では、先頭から数えて同じ順番のＧＯＰが同じ再生期間の映像を表す。図４２を参照するに、ベースビュー・ビデオ・ストリーム3510では、先頭から数えて奇数番目に位置するＧＯＰ＃１、ＧＯＰ＃３、ＧＯＰ＃５の各先頭にエントリ・ポイント3501B、3503B、3505Bが設定されている。それに併せて、ディペンデントビュー・ビデオ・ストリーム3520でも、先頭から数えて奇数番目に位置するＧＯＰ＃１、ＧＯＰ＃３、ＧＯＰ＃５の各先頭にエントリ・ポイント3501D、3503D、3505Dが設定されている。その場合、再生装置２００は、例えばＧＯＰ＃３から３Ｄ映像の再生を開始するとき、対応するエントリ・ポイント3503B、3503DのＳＰＮからファイルＳＳ内の再生開始位置のアドレスを直ちに算定できる。特にエントリ・ポイント3503B、3503Dがいずれもデータ・ブロックの先端に設定されているとき、図４０の（ｅ）から理解されるとおり、エントリ・ポイント3503B、3503DのＳＰＮの和が、ファイルＳＳの先頭から再生開始位置までの部分に含まれるソースパケットの数に等しい。図４０の（ｅ）の説明で述べたとおり、そのソースパケットの数からは、ファイルＳＳ内の再生開始位置の部分が記録されたセクタのＬＢＮを算定することができる。こうして、３Ｄ映像の再生においても、飛び込み再生等、ビデオ・ストリームのランダムアクセスを要する処理の応答速度を向上させることができる。
ＢＤ−ＲＯＭドライブが読み出したストリームファイルのソースパケットから、ベースビューを構成するATCシーケンスとディペンデントビューストリームを構成するATCシーケンスとをエクステント起点を利用して分離する手順について説明する。図４３は、ATCシーケンス復元手順を示す。
ステップＳ９１は、ベースビュー用のATCシーケンスをATCシーケンス１とし、ディペンデントビュー用のATCシーケンスをATCシーケンス２とする。ステップＳ９２では、変数xを1に初期化する。この変数xは、
エクステント起点により示されるベースビュー・エクステントＩＤ（ＥＸＴ１＿ＩＤ）ライトビュー・エクステントＩＤ（ＥＸＴ２＿ＩＤ）のインデックス番号を指示する。以降、ステップＳ９４〜ステップＳ９６のループを繰り返す。
変数xによって指示されるソースパケット番号bxが、ベースビューデータブロックの最後の数値nによって指示されるソースパケット番号bnであるか否かを判定し(ステップＳ９３)、もしそうでなければ、ソースパケット番号ｂx＋ａxによって指示されるソースパケット(ｂx＋ａx)から、ｂx+1＋ａxによって指示されるソースパケット(ｂx+1＋ａx)の直前のパケットまでをATCシーケンス２に追加し(ステップＳ９４)、ソースパケット(ｂx+1＋ａx)からソースパケット(ｂx+1＋ａx+1)の直前のパケットまでをATCシーケンス１に追加して(ステップＳ９５)、変数xをインクリメントする(ステップＳ９６)という処理を、ステップＳ９３がYesと判定されるまで繰り返す。
ステップＳ９３がYesと判定されれば、ソースパケット番号ｂnから(number_of_source_packet2-ｂn)個のソースパケットをATCシーケンス２に追加し(ステップＳ９７)、ソースパケット番号ａnから(number_of_source_packet1-ａn)個のソースパケットをATCシーケンス１に追加する(ステップＳ９８)。
以上のように、ATCシーケンス１、２が復元されれば、ベースビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする(ステップＳ９９)。同様に、ディペンデントビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルディペンデントを仮想的にオープンする(ステップＳ１００)。

＜プレイリスト情報ファイル＞
以下、プレイリスト情報ファイルの詳細について説明する。
≪２Ｄプレイリスト・ファイル≫
図４４は、２Ｄプレイリスト・ファイルのデータ構造を示す模式図である。図４４を参照するに、２Ｄプレイリスト・ファイル521はメインパス3601と二つのサブパス3602、3603とを含む。
メインパス3601はプレイアイテム情報（ＰＩ）の配列であり、ファイル２Ｄの主要な再生経路、すなわち再生対象の部分とその再生順とを規定する。各ＰＩは固有のプレイアイテムＩＤ＝＃Ｎ（Ｎ＝１、２、３、…）で識別される。各ＰＩ＃Ｎは主要な再生経路の異なる再生区間を一対のＰＴＳで規定する。その対の一方はその再生区間の開始時刻（In−Time）を表し、他方は終了時刻（Out−Time）を表す。更に、メインパス3601内でのＰＩの順序は、対応する再生区間の再生経路内での順序を表す。
各サブパス3602、3603はサブプレイアイテム情報（ＳＵＢ＿ＰＩ）の配列であり、ファイル２Ｄの主要な再生経路に並列に付随可能な再生経路を規定する。その再生経路は、メインパス3601の表すファイル２Ｄの部分とは別の部分、又は別のファイル２Ｄに多重化されたストリーム・データの部分とその再生順とを意味する。そのストリーム・データは、メインパス3601に従ってファイル２Ｄから再生される２Ｄ映像と同時に再生されるべき別の２Ｄ映像を表す。その別の２Ｄ映像は例えば、ピクチャ・イン・ピクチャ方式における副映像、ブラウザ画面、ポップアップ・メニュー、又は字幕を含む。サブパス3602、3603には２Ｄプレイリスト・ファイル521への登録順に通し番号「０」、「１」が振られている。その通し番号はサブパスＩＤとして各サブパス3602、3603の識別に利用される。各サブパス3602、3603では、各ＳＵＢ＿ＰＩが固有のサブプレイアイテムＩＤ＝＃Ｍ（Ｍ＝１、２、３、…）で識別される。各ＳＵＢ＿ＰＩ＃Ｍは、再生経路の異なる再生区間を一対のＰＴＳで規定する。その対の一方はその再生区間の再生開始時刻を表し、他方は再生終了時刻を表す。更に、各サブパス3602、3603内でのＳＵＢ＿ＰＩの順序は、対応する再生区間の再生経路内での順序を表す。
図４５は、ＰＩ＃Ｎのデータ構造を示す模式図である。図４５を参照するに、ＰＩ＃Ｎは、参照クリップ情報3701、再生開始時刻（In＿Time）3702、再生終了時刻（Out＿Time）3703、コネクション・コンディション3704、及びストリーム選択テーブル（以下、ＳＴＮ（Stream Number）テーブルと略す。）3705を含む。参照クリップ情報3701は、２Ｄクリップ情報ファイルを識別するための情報である。再生開始時刻3702と再生終了時刻3703とは、ファイル２Ｄ541の再生対象部分の先端と後端との各ＰＴＳを示す。コネクション・コンディション3704は、再生開始時刻3702と再生終了時刻3703とによって規定された再生区間での映像を、一つ前のＰＩ＃（Ｎ−１）によって規定された再生区間での映像に接続するときの条件を規定する。ＳＴＮテーブル3705は、再生開始時刻3702から再生終了時刻3703までの間に再生装置２００内のデコーダによってファイル２Ｄ541から選択可能なエレメンタリ・ストリームのリストを表す。
ＳＵＢ＿ＰＩのデータ構造は、図４５に示されているＰＩのデータ構造と、参照クリップ情報、再生開始時刻、及び再生終了時刻を含む点で共通する。特にＳＵＢ＿ＰＩの再生開始時刻と再生終了時刻とは、ＰＩのそれらと同じ時間軸上の値で表される。ＳＵＢ＿ＰＩは更に「ＳＰコネクション・コンディション」というフィールドを含む。ＳＰコネクション・コンディションはＰＩのコネクション・コンディションと同じ意味を持つ。
［コネクション・コンディション］
コネクション・コンディション3704の値には「１」、「５」、「６」の三種類がある。コネクション・コンディション3704が「１」であるとき、ＰＩ＃Ｎによって規定されるファイル２Ｄの部分から再生される映像は、直前のＰＩ＃（Ｎ−１）によって規定されるファイル２Ｄの部分から再生される映像とは必ずしもシームレスに接続されなくてもよい。一方、コネクション・コンディション3704が「５」又は「６」であるとき、それら両方の映像が必ずシームレスに接続されなければならない。
図４６の（ａ）、（ｂ）はそれぞれ、コネクション・コンディション3704が「５」、「６」であるときに接続対象の二つの再生区間3801、3802の間の関係を示す模式図である。ここで、ＰＩ＃（Ｎ−１）はファイル２Ｄの第１部分3801を規定し、ＰＩ＃Ｎはファイル２Ｄの第２部分3802を規定する。図４６の（ａ）を参照するに、コネクション・コンディション3704が「５」であるとき、２つのＰＩ＃（Ｎ−１）、ＰＩ＃Ｎの間でＳＴＣが途切れていても良い。すなわち、第１部分3801の後端のＰＴＳ＃１と第２部分3802の先端のＰＴＳ＃２とは不連続であってもよい。但し、いくつかの制約条件が満たされねばならない。例えば、第１部分3801に続けて第２部分3802をデコーダに供給したときでも、そのデコーダが復号処理をスムーズに持続できるように、各部分3801、3802が作成されていなければならない。更に、第１部分3801に含まれるオーディオ・ストリームの最後のフレームを、第２部分3802に含まれるオーディオ・ストリームの先頭フレームと重複させなければならない。一方、図４６の（ｂ）を参照するに、コネクション・コンディション3704が「６」であるとき、第１部分3801と第２部分3802とは、デコーダの復号処理上、一連の部分として扱えるものでなければならない。すなわち、第１部分3801と第２部分3802との間ではＳＴＣとＡＴＣとがいずれも連続でなければならない。同様に、ＳＰコネクション・コンディションが「５」又は「６」であるとき、隣接する２つのＳＵＢ＿ＰＩによって規定されるファイル２Ｄの部分間では、ＳＴＣとＡＴＣとがいずれも連続でなければならない。
［ＳＴＮテーブル］
図４５を再び参照するに、ＳＴＮテーブル3705はストリーム登録情報の配列である。「ストリーム登録情報」とは、再生開始時刻3702から再生終了時刻3703までの間にメインＴＳから再生対象として選択可能なエレメンタリ・ストリームを個別に示す情報である。ストリーム番号（ＳＴＮ）3706はストリーム登録情報に個別に割り当てられた通し番号であり、再生装置２００によって各エレメンタリ・ストリームの識別に利用される。ＳＴＮ3706は更に、同じ種類のエレメンタリ・ストリームの間では選択の優先順位を表す。ストリーム登録情報はストリーム・エントリ3709とストリーム属性情報3710と含む。ストリーム・エントリ3709はストリーム・パス情報3707とストリーム識別情報3708とを含む。ストリーム・パス情報3707は、選択対象のエレメンタリ・ストリームが属するファイル２Ｄを示す情報である。例えばストリーム・パス情報3707が“メインパス”を示すとき、そのファイル２Ｄは、参照クリップ情報3701の示す２Ｄクリップ情報ファイルに対応するものである。一方、ストリーム・パス情報3707が“サブパスＩＤ＝１”を示すとき、選択対象のエレメンタリ・ストリームが属するファイル２Ｄは、サブパスＩＤ＝１のサブパスに含まれるＳＵＢ＿ＰＩの参照クリップ情報が示す２Ｄクリップ情報ファイルに対応するものである。そのＳＵＢ＿ＰＩの規定する再生開始時刻又は再生終了時刻のいずれかは、ＳＴＮテーブル3705を含むＰＩの規定する再生開始時刻3702から再生終了時刻3703までの期間に含まれる。ストリーム識別情報3708は、ストリーム・パス情報3707によって特定されるファイル２Ｄに多重化されているエレメンタリ・ストリームのＰＩＤを示す。このＰＩＤの示すエレメンタリ・ストリームが再生開始時刻3702から再生終了時刻3703までの間に選択可能である。ストリーム属性情報3710は各エレメンタリ・ストリームの属性情報を表す。例えば、オーディオ・ストリーム、ＰＧストリーム、及びＩＧストリームの各属性情報は言語の種類を示す。
［２Ｄプレイリスト・ファイルに従った２Ｄ映像の再生］
図４７は、２Ｄプレイリスト・ファイル（00001.mpls）521の示すＰＴＳと、ファイル２Ｄ（01000.m2ts）541から再生される部分との間の対応関係を示す模式図である。図４７を参照するに、２Ｄプレイリスト・ファイル521のメインパス3601では、ＰＩ＃１は、再生開始時刻IN1を示すＰＴＳ＃１と、再生終了時刻OUT1を示すＰＴＳ＃２とを規定する。ＰＩ＃１の参照クリップ情報3701は２Ｄクリップ情報ファイル（01000.clpi）531を示す。再生装置２００は２Ｄプレイリスト・ファイル521に従って２Ｄ映像を再生するとき、まずＰＩ＃１からＰＴＳ＃１、＃２を読み出す。再生装置２００は次に、２Ｄクリップ情報ファイル531のエントリ・マップを参照して、ＰＴＳ＃１、＃２に対応するファイル２Ｄ541内のＳＰＮ＃１、＃２を検索する。再生装置２００は続いて、ＳＰＮ＃１、＃２から、それぞれに対応するセクタ数を算定する。再生装置２００は更にそれらのセクタ数とファイル２Ｄ541のファイル・エントリ内のアロケーション記述子とを利用して、再生対象の２Ｄエクステント群EXT2D[0]、…、EXT2D[n]が記録されたセクタ群P1の先端のＬＢＮ＃１と後端のＬＢＮ＃２とを特定する。セクタ数の算定とＬＢＮの特定とは、図３８の（ｂ）、（ｃ）を用いて説明したとおりである。再生装置２００は最後に、ＬＢＮ＃１からＬＢＮ＃２までの範囲をＢＤ−ＲＯＭドライブに指定する。それにより、その範囲のセクタ群P1から、２Ｄエクステント群EXT2D[0]、…、EXT2D[n]に属するソースパケット群が読み出される。同様に、ＰＩ＃２の示すＰＴＳ＃３、＃４の対は、まず２Ｄクリップ情報ファイル531のエントリ・マップを利用してＳＰＮ＃３、＃４の対に変換される。次にファイル２Ｄ541のファイル・エントリ内のアロケーション記述子を利用して、ＳＰＮ＃３、＃４の対がＬＢＮ＃３、＃４の対に変換される。更に、ＬＢＮ＃３からＬＢＮ＃４までの範囲のセクタ群P2から、２Ｄエクステント群に属するソースパケット群が読み出される。ＰＩ＃３の示すＰＴＳ＃５、＃６の対からＳＰＮ＃５、＃６の対への変換、ＳＰＮ＃５、＃６の対からＬＢＮ＃５、＃６の対への変換、及びＬＢＮ＃５からＬＢＮ＃６までの範囲のセクタ群P3からのソースパケット群の読み出しも同様である。こうして、再生装置２００は２Ｄプレイリスト・ファイル521のメインパス3601に従ってファイル２Ｄ541から２Ｄ映像を再生できる。
２Ｄプレイリスト・ファイル521はエントリ・マーク3901を含んでもよい。エントリ・マーク3901は、メインパス3601のうち、実際に再生が開始されるべき時点を示す。例えば図４７に示されているように、ＰＩ＃１に対して複数のエントリ・マーク3901が設定されてもよい。エントリ・マーク3901は特に頭出し再生において、再生開始位置の検索に利用される。例えば２Ｄプレイリスト・ファイル521が映画タイトルの再生経路を規定するとき、エントリ・マーク3901は各チャプタの先頭に付与される。それにより、再生装置２００はその映画タイトルをチャプタごとに再生できる。
≪３Ｄプレイリスト・ファイル≫
図４８は、３Ｄプレイリスト・ファイル4000のデータ構造を示す模式図である。図４８を参照するに、３Ｄプレイリスト・ファイル4000は、メインパス4001、サブパス4002、及び拡張データ4003を含む。
メインパス4001は、メインＴＳの再生経路を規定する。従って、メインパス4001は、図４４に示されている２Ｄプレイリスト・ファイルのメインパス3601に等しい。２Ｄ再生モードの再生装置２００は３Ｄプレイリスト・ファイル4000のメインパス4001に従ってファイル２Ｄから２Ｄ映像を再生できる。
サブパス4002は、サブＴＳの再生経路、すなわちレフトビュービデオストリームを含むファイルＤＥＰ又はデプスマップストリームを含むファイルＤＥＰのいずれかの再生経路を規定する。サブパス4002のデータ構造は、図４４に示されている２Ｄプレイリスト・ファイルのサブパス3602、3603のデータ構造と同様である。従って、その同様なデータ構造の詳細、特にＳＵＢ＿ＰＩのデータ構造の詳細についての説明は、図４４を用いた説明を援用する。
サブパス4002のＳＵＢ＿ＰＩ＃Ｎ（Ｎ＝１、２、３、…）はメインパス4001のＰＩ＃Ｎと一対一に対応する。更に、各ＳＵＢ＿ＰＩ＃Ｎの規定する再生開始時刻と再生終了時刻とはそれぞれ、対応するＰＩ＃Ｎの規定する再生開始時刻と再生終了時刻とに等しい。サブパス4002はその上、サブパス・タイプ4021を含む。「サブパス・タイプ」は一般に、メインパスとサブパスとの間で再生処理が同期すべきか否かを示す。３Ｄプレイリスト・ファイル4000では特にサブパス・タイプ4021が３Ｄ再生モードの種類、すなわちサブパス4002に従って再生されるべきディペンデントビュー・ビデオ・ストリームの種類を示す。図４８では、サブパス・タイプ4021は、その値が「３Ｄ・Ｌ／Ｒ」であるので、３Ｄ再生モードがＬ／Ｒモードであること、すなわちライトビュー・ビデオ・ストリームが再生対象であることを示す。一方、サブパス・タイプ4021は、その値が「３Ｄデプス」であるときは、３Ｄ再生モードがデプス・モードであること、すなわちデプスマップ・ストリームが再生対象であることを示す。３Ｄ再生モードの再生装置２００は、サブパス・タイプ4021の値が「３Ｄ・Ｌ／Ｒ」又は「３Ｄデプス」であることを検出したとき、メインパス4001に従った再生処理とサブパス4002に従った再生処理とを同期させる。
拡張データ4003は、３Ｄ再生モードの再生装置２００によってのみ解釈される部分であり、２Ｄ再生モードの再生装置２００には無視される。拡張データ4003は特に、拡張ストリーム選択テーブル4030を含む。「拡張ストリーム選択テーブル（STN＿table＿SS）」（以下、ＳＴＮテーブルＳＳと略す。）は、３Ｄ再生モードにおいて、メインパス4001内の各ＰＩの示すＳＴＮテーブルに追加されるべきストリーム登録情報の配列である。このストリーム登録情報は、サブＴＳから再生対象として選択可能なエレメンタリ・ストリームを示す。
図４９は、ＳＴＮテーブルＳＳ4030のデータ構造を示す模式図である。図４９を参照するに、ＳＴＮテーブルＳＳ4030はストリーム登録情報列4101、4102、4103、…を含む。ストリーム登録情報列4101、4102、4103、…はメインパス4001内のＰＩ＃１、＃２、＃３、…に個別に対応し、３Ｄ再生モードの再生装置２００により、対応するＰＩ内のＳＴＮテーブルに含まれるストリーム登録情報列と組み合わされて利用される。各ＰＩに対するストリーム登録情報列4101は、ポップアップ期間のオフセット（Fixed＿offset＿during＿Popup）4111、ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112、ＰＧストリームのストリーム登録情報列4113、及びＩＧストリームのストリーム登録情報列4114を含む。
ポップアップ期間のオフセット4111は、ＩＧストリームからポップアップ・メニューが再生されるか否かを示す。３Ｄ再生モードの再生装置２００はそのオフセット4111の値に依ってビデオ・プレーンとＰＧプレーンとの表示モード（presentation mode）を変える。ここで、ビデオ・プレーンの表示モードにはベースビュー（Ｂ）−ディペンデントビュー（Ｄ）表示モードとＢ−Ｂ表示モードとの二種類があり、ＰＧプレーンとＩＧプレーンとの各表示モードには、２プレーン・モード、１プレーン＋オフセット・モード、及び１プレーン＋ゼロ・オフセット・モードとの三種類がある。例えばポップアップ期間のオフセット4111の値が“０”であるとき、ＩＧストリームからはポップアップ・メニューが再生されない。そのとき、ビデオ・プレーンの表示モードとしてＢ−Ｄ表示モードが選択され、ＰＧプレーンの表示モードとして２プレーン・モード又は１プレーン＋オフセット・モードが選択される。一方、ポップアップ期間のオフセット4111の値が“１”であるとき、ＩＧストリームからポップアップ・メニューが再生される。そのとき、ビデオ・プレーンの表示モードとしてＢ−Ｂ表示モードが選択され、ＰＧプレーンの表示モードとして１プレーン＋ゼロ・オフセット・モードが選択される。
「Ｂ−Ｄ表示モード」では再生装置２００が、レフトビューとライトビューとのビデオ・ストリームから復号されたプレーン・データを交互に出力する。従って、テレビ３００の画面には、ビデオ・プレーンの表すレフトビューとライトビューとのフレームが交互に表示されるので、視聴者にはそれらが３Ｄ映像として見える。「Ｂ−Ｂ表示モード」では再生装置２００が、動作モードを３Ｄ再生モードに維持したまま（特にフレームレートを３Ｄ再生時の値、例えば４８フレーム／秒に維持したまま）、ベースビュー・ビデオ・ストリームから復号されたプレーン・データのみをフレーム当たり二回ずつ出力する。従って、テレビ３００の画面には、ビデオ・プレーンについてはレフトビューとライトビューとのいずれかのフレームしか表示されないので、視聴者にはそれらが２Ｄ映像としてしか見えない。
「２プレーン・モード」では、サブＴＳがレフトビューとライトビューとのグラフィックス・ストリームを両方含むとき、再生装置２００が各グラフィックス・ストリームからレフトビューとライトビューとのグラフィックス・プレーン・データを復号して交互に出力する。「１プレーン＋オフセット・モード」では、再生装置２００がクロッピング処理により、メインＴＳ内のグラフィックス・ストリームからレフトビューとライトビューとのプレーン・データの対を生成して交互に出力する。いずれのモードでも、テレビ３００の画面にはレフトビューとライトビューとのＰＧプレーンが交互に表示されるので、視聴者にはそれらが３Ｄ映像として見える。「１プレーン＋ゼロ・オフセット・モード」では、再生装置２００が、動作モードを３Ｄ再生モードに維持したまま、クロッピング処理を一時的に停止させ、メインＴＳ内のグラフィックス・ストリームから復号されたプレーン・データをフレーム当たり二回ずつ出力する。従って、テレビ３００の画面には、レフトビューとライトビューとのいずれかのＰＧプレーンしか表示されないので、視聴者にはそれらが２Ｄ映像としてしか見えない。
３Ｄ再生モードの再生装置２００は、ＰＩごとにポップアップ期間のオフセット4111を参照して、ＩＧストリームからポップアップ・メニューが再生されるときはＢ−Ｂ表示モードと１プレーン＋ゼロ・オフセット・モードとを選択する。それにより、ポップアップ・メニューが表示される間、他の３Ｄ映像が一時的に２Ｄ映像に変更されるので、ポップアップ・メニューの視認性・操作性が向上する。
ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112、ＰＧストリームのストリーム登録情報列4113、及びＩＧストリームのストリーム登録情報列4114はそれぞれ、サブＴＳから再生対象として選択可能なディペンデントビュー・ビデオ・ストリーム、ＰＧストリーム、及びＩＧストリームを示すストリーム登録情報を含む。これらのストリーム登録情報列4112、4113、4114はそれぞれ、対応するＰＩ内のＳＴＮテーブルに含まれるストリーム登録情報列のうち、ベースビュー・ビデオ・ストリーム、ＰＧストリーム、及びＩＧストリームを示すものと組み合わされて利用される。３Ｄ再生モードの再生装置２００は、ＳＴＮテーブル内のいずれかのストリーム登録情報を読み出すとき、そのストリーム登録情報に組み合わされたＳＴＮテーブルＳＳ内のストリーム登録情報列も自動的に読み出す。それにより、再生装置２００は、２Ｄ再生モードを単に３Ｄ再生モードへ切り換えるとき、設定済みのＳＴＮ、及び言語等のストリーム属性を同一に維持できる。
図５０の（ａ）は、ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112のデータ構造を示す模式図である。図５０の（ａ）を参照するに、このストリーム登録情報列4112は一般に複数のストリーム登録情報（SS＿dependet＿view＿block）4201を含む。それらは、対応するＰＩ内のストリーム登録情報のうち、ベースビュー・ビデオ・ストリームを示すものと同数である。各ストリーム登録情報4201は、ＳＴＮ4211、ストリーム・エントリ4212、及びストリーム属性情報4213を含む。ＳＴＮ4211はストリーム登録情報4201に個別に割り当てられた通し番号であり、対応するＰＩ内の組み合わせ対象のストリーム登録情報のＳＴＮと等しい。ストリーム・エントリ4212は、サブパスＩＤ参照情報（ref＿to＿Subpath＿id）4221、ストリーム・ファイル参照情報（ref＿to＿subClip＿entry＿id）4222、及びＰＩＤ（ref＿to＿stream＿PID＿subclip）4223を含む。サブパスＩＤ参照情報4221は、ディペンデントビュー・ビデオ・ストリームの再生経路を規定するサブパスのサブパスＩＤを示す。ストリーム・ファイル参照情報4222は、そのディペンデントビュー・ビデオ・ストリームが格納されたファイルＤＥＰを識別するための情報である。ＰＩＤ4223は、そのディペンデントビュー・ビデオ・ストリームのＰＩＤである。ストリーム属性情報4213はそのディペンデントビュー・ビデオ・ストリームの属性、例えばフレームレート、解像度、及びビデオフォーマットを含む。特にそれらは、対応するＰＩ内の組み合わせ対象のストリーム登録情報の示すベースビュー・ビデオ・ストリームのものと共通である。
図５０の（ｂ）は、ＰＧストリームのストリーム登録情報列4113のデータ構造を示す模式図である。図５０の（ｂ）を参照するに、このストリーム登録情報列4113は一般に複数のストリーム登録情報4231を含む。それらは、対応するＰＩ内のストリーム登録情報のうち、ＰＧストリームを示すものと同数である。各ストリーム登録情報4231は、ＳＴＮ4241、立体視フラグ（is＿SS＿PG）4242、ベースビュー・ストリーム・エントリ（stream＿entry＿for＿base＿view）4243、ディペンデントビュー・ストリーム・エントリ（stream＿entry＿for＿depentdent＿view）4244、及びストリーム属性情報4245を含む。ＳＴＮ4241はストリーム登録情報4231に個別に割り当てられた通し番号であり、対応するＰＩ内の組み合わせ対象のストリーム登録情報のＳＴＮと等しい。立体視フラグ4242は、記録媒体１００にベースビューとディペンデントビュー、例えばレフトビューとライトビューとのＰＧストリームが両方含まれているか否かを示す。立体視フラグ4242がオンであるとき、サブＴＳに両方のＰＧストリームが含まれている。従って、ベースビュー・ストリーム・エントリ4243、ディペンデントビュー・ストリーム・エントリ4244、及びストリーム属性情報4245のいずれのフィールドも再生装置によって読み出される。立体視フラグ4242がオフであるとき、それらのフィールド4243−4245はいずれも再生装置に無視される。ベースビュー・ストリーム・エントリ4243とディペンデントビュー・ストリーム・エントリ4244とはいずれも、サブパスＩＤ参照情報、ストリーム・ファイル参照情報、及びＰＩＤを含む。サブパスＩＤ参照情報は、ベースビューとディペンデントビューとの各ＰＧストリームの再生経路を規定するサブパスのサブパスＩＤを示す。ストリーム・ファイル参照情報は、各ＰＧストリームが格納されたファイルＤＥＰを識別するための情報である。ＰＩＤは各ＰＧストリームのＰＩＤである。ストリーム属性情報4245は各ＰＧストリームの属性、例えば言語の種類を含む。
図５０の（ｃ）は、ＩＧストリームのストリーム登録情報列4114のデータ構造を示す模式図である。図５０の（ｃ）を参照するに、このストリーム登録情報列4114は一般に複数のストリーム登録情報4251を含む。それらは、対応するＰＩ内のストリーム登録情報のうち、ＩＧストリームを示すものと同数である。各ストリーム登録情報4251は、ＳＴＮ4261、立体視フラグ（is＿SS＿IG）4262、ベースビュー・ストリーム・エントリ4263、ディペンデントビュー・ストリーム・エントリ4264、及びストリーム属性情報4265を含む。ＳＴＮ4261はストリーム登録情報4251に個別に割り当てられた通し番号であり、対応するＰＩ内の組み合わせ対象のストリーム登録情報のＳＴＮと等しい。立体視フラグ4262は、記録媒体１００にベースビューとディペンデントビュー、例えばレフトビューとライトビューとのＩＧストリームが両方含まれているか否かを示す。立体視フラグ4262がオンであるとき、サブＴＳに両方のＩＧストリームが含まれている。従って、ベースビュー・ストリーム・エントリ4263、ディペンデントビュー・ストリーム・エントリ4264、及びストリーム属性情報4265のいずれのフィールドも再生装置によって読み出される。立体視フラグ4262がオフであるとき、それらのフィールド4263−4265はいずれも再生装置に無視される。ベースビュー・ストリーム・エントリ4263とディペンデントビュー・ストリーム・エントリ4264とはいずれも、サブパスＩＤ参照情報、ストリーム・ファイル参照情報、及びＰＩＤを含む。サブパスＩＤ参照情報は、ベースビューとディペンデントビューとの各ＩＧストリームの再生経路を規定するサブパスのサブパスＩＤを示す。ストリーム・ファイル参照情報は、各ＩＧストリームが格納されたファイルＤＥＰを識別するための情報である。ＰＩＤは各ＩＧストリームのＰＩＤである。ストリーム属性情報4265は各ＩＧストリームの属性、例えば言語の種類を含む。
［３Ｄプレイリスト・ファイルに従った３Ｄ映像の再生］
図５１は、３Ｄプレイリスト・ファイル（00002.mpls）522の示すＰＴＳと、ファイルＳＳ（01000.ssif）544Aから再生される部分との間の対応関係を示す模式図である。図５１を参照するに、３Ｄプレイリスト・ファイル522のメインパス4301では、ＰＩ＃１は、再生開始時刻IN1を示すＰＴＳ＃１と、再生終了時刻OUT1を示すＰＴＳ＃２とを規定する。ＰＩ＃１の参照クリップ情報は２Ｄクリップ情報ファイル（01000.clpi）531を示す。一方、サブパス・タイプが「３Ｄ・Ｌ／Ｒ」を示すサブパス4302では、ＳＵＢ＿ＰＩ＃１が、ＰＩ＃１と同じＰＴＳ＃１、＃２を規定する。ＳＵＢ＿ＰＩ＃１の参照クリップ情報はライトビュー・クリップ情報ファイル（02000.clpi）532を示す。
再生装置２００は３Ｄプレイリスト・ファイル522に従って３Ｄ映像を再生するとき、まずＰＩ＃１とＳＵＢ＿ＰＩ＃１とからＰＴＳ＃１、＃２を読み出す。再生装置２００は次に２Ｄクリップ情報ファイル531のエントリ・マップを参照し、ＰＴＳ＃１、＃２に対応するファイル２Ｄ内のＳＰＮ＃１、＃２を検索する。それと並行して、再生装置２００はライトビュー・クリップ情報ファイル532のエントリ・マップを参照し、ＰＴＳ＃１、＃２に対応するファイルＤＥＰ内のＳＰＮ＃１１、＃１２を検索する。再生装置２００は続いて、図４０の（ｅ）の説明で述べたように各クリップ情報ファイル531、532のエクステント起点3042、3320を利用して、ＳＰＮ＃１、＃１１から、ファイルＳＳ544Aの先頭から再生開始位置までのソースパケット数ＳＰＮ＃２１を算定する。再生装置２００は同様に、ＳＰＮ＃２、＃１２から、ファイルＳＳ544Aの先頭から再生終了位置までのソースパケット数ＳＰＮ＃２２を算定する。再生装置２００は更にＳＰＮ＃２１、＃２２のそれぞれに対応するセクタ数を算定する。再生装置２００は続いて、それらのセクタ数とファイルＳＳ544Aのファイル・エントリ内のアロケーション記述子とを利用して、再生対象の３Ｄエクステント群EXTSS[0]、…、EXTSS[n]が記録されたセクタ群P11の先端のＬＢＮ＃１と後端のＬＢＮ＃２とを特定する。セクタ数の算定とＬＢＮの特定とは、図４０の（ｅ）の説明で述べたものと同様である。再生装置２００は最後に、ＬＢＮ＃１からＬＢＮ＃２までの範囲をＢＤ−ＲＯＭドライブに指定する。それにより、その範囲のセクタ群P11から、３Ｄエクステント群EXTSS[0]、…、EXTSS[n]に属するソースパケット群が読み出される。同様に、ＰＩ＃２とＳＵＢ＿ＰＩ＃２との示すＰＴＳ＃３、＃４の対は、まずクリップ情報ファイル531、532の各エントリ・マップを利用してＳＰＮ＃３、＃４の対とＳＰＮ＃１３、＃１４の対とに変換される。次に、ＳＰＮ＃３、＃１３からはファイルＳＳ544Aの先頭から再生開始位置までのソースパケット数ＳＰＮ＃２３が算定され、ＳＰＮ＃４、＃１４からはファイルＳＳ544Aの先頭から再生終了位置までのソースパケット数ＳＰＮ＃２４が算定される。続いて、ファイルＳＳ544Aのファイル・エントリ内のアロケーション記述子を利用して、ＳＰＮ＃２３、＃２４の対がＬＢＮ＃３、＃４の対に変換される。更に、ＬＢＮ＃３からＬＢＮ＃４までの範囲のセクタ群P12から、３Ｄエクステント群に属するソースパケット群が読み出される。
上記の読み出し処理と並行して、再生装置２００は、図４０の（ｅ）の説明で述べたように各クリップ情報ファイル531、532のエクステント起点3042、3320を利用して、各３Ｄエクステントからベースビュー・エクステントを抽出し、残りのライトビュー・エクステントとパラレルに復号する。こうして、再生装置２００は、３Ｄプレイリスト・ファイル522に従って第１ファイルＳＳ544Aから３Ｄ映像を再生できる。
以上がプレイリスト情報ファイルの詳細についての説明である。

≪インデックス・テーブル≫
図５２は、インデックス・ファイル（index.bdmv）内のインデックス・テーブル4410を示す模式図である。図５２を参照するに、インデックス・テーブル4410は、「ファーストプレイ」4401、「トップメニュー」4402、及び「タイトルｋ」44303（ｋ＝１、２、…、ｎ：ｎは１以上の整数）という項目を含む。各項目にはムービーオブジェクトMVO−2D、MVO−3D、…、又はＢＤ−ＪオブジェクトBDJO−2D、BDJO−3D、…のいずれかが対応付けられている。ユーザの操作又はアプリケーション・プログラムによってタイトル又はメニューが呼び出される度に、再生装置２００の制御部はインデックス・テーブル4410の対応する項目を参照する。制御部は更に、その項目に対応付けられているオブジェクトを記録媒体１００から呼び出し、それに従って様々な処理を実行する。具体的には、項目「ファーストプレイ」4401には、記録媒体１００がＢＤ−ＲＯＭドライブへ挿入された時に呼び出されるべきオブジェクトが指定されている。項目「トップメニュー」4402には、例えばユーザの操作で「メニューに戻れ」というコマンドが入力された時にテレビ３００にメニューを表示させるためのオブジェクトが指定されている。項目「タイトルｋ」4403には、記録媒体１００上のコンテンツを構成するタイトルが個別に割り当てられている。例えばユーザの操作によって再生対象のタイトルが指定されたとき、そのタイトルが割り当てられている項目「タイトルｋ」には、そのタイトルに対応するＡＶストリーム・ファイルから映像を再生するためのオブジェクトが指定されている。
図５２に示されている例では、項目「タイトル１」と項目「タイトル２」とが２Ｄ映像のタイトルに割り当てられている。項目「タイトル１」に対応付けられているムービーオブジェクトMVO−2Dは、２Ｄプレイリスト・ファイル（00001.mpls）521を用いた２Ｄ映像の再生処理に関する命令群を含む。再生装置２００によって項目「タイトル１」が参照されたとき、そのムービーオブジェクトMVO−2Dに従い、２Ｄプレイリスト・ファイル521が記録媒体１００から読み出され、それに規定された再生経路に沿って２Ｄ映像の再生処理が実行される。項目「タイトル２」に対応付けられているＢＤ−ＪオブジェクトBDJO−2Dは、２Ｄプレイリスト・ファイル521を用いた２Ｄ映像の再生処理に関するアプリケーション管理テーブルを含む。再生装置２００によって項目「タイトル２」が参照されたとき、そのＢＤ−ＪオブジェクトBDJO−2D内のアプリケーション管理テーブルに従ってＪＡＲファイルからＪａｖａ(登録商標)アプリケーション・プログラムが呼び出されて実行される。それにより、２Ｄプレイリスト・ファイル521が記録媒体１００から読み出され、それに規定された再生経路に沿って２Ｄ映像の再生処理が実行される。
図５２に示されている例では更に、項目「タイトル３」と項目「タイトル４」とが３Ｄ映像のタイトルに割り当てられている。項目「タイトル３」に対応付けられているムービーオブジェクトMVO−3Dは、２Ｄプレイリスト・ファイル521を用いた２Ｄ映像の再生処理に関する命令群に加え、３Ｄプレイリスト・ファイル（00002.mpls）522、（00003.mpls）523のいずれかを用いた３Ｄ映像の再生処理に関する命令群を含む。項目「タイトル４」に対応付けられているＢＤ−ＪオブジェクトBDJO−3Dでは、アプリケーション管理テーブルが、２Ｄプレイリスト・ファイル521を用いた２Ｄ映像の再生処理に関するＪａｖａ(登録商標)アプリケーション・プログラムに加え、３Ｄプレイリスト・ファイル522、523のいずれかを用いた３Ｄ映像の再生処理に関するＪａｖａ(登録商標)アプリケーション・プログラムを規定する。
再生装置２００によって項目「タイトル３」が参照されたとき、ムービーオブジェクトMVO−3Dに従い、まず次の四種類の判別処理が行われる：（１）再生装置２００自身が３Ｄ映像の再生に対応しているか否か、（２）ユーザが３Ｄ映像の再生を選択しているか否か、（３）テレビ３００が３Ｄ映像の再生に対応しているか否か、及び（４）再生装置２００の３Ｄ映像再生モードがＬ／Ｒモードとデプス・モードとのいずれであるか。次にそれらの判別結果に応じていずれかのプレイリスト・ファイル521−523が再生対象として選択される。再生装置２００によって項目「タイトル４」が参照されたとき、ＢＤ−ＪオブジェクトBDJO−3D内のアプリケーション管理テーブルに従ってＪＡＲファイルからＪａｖａ(登録商標)アプリケーション・プログラムが呼び出されて実行される。それにより、まず上記の判別処理が行われ、次にその判別結果に応じたプレイリスト・ファイルの選択が行われる。

［３Ｄ映像タイトルの選択時でのプレイリスト・ファイルの選択］
図５３は、３Ｄ映像のタイトルが選択されたときに行われる、再生対象のプレイリスト・ファイルの選択処理のフローチャートである。図５２に示されているインデックス・テーブル4410では、項目「タイトル３」が参照されたときはムービーオブジェクトMVO−3Dに従ってその選択処理が実行され、項目「タイトル４」が参照されたときは、ＢＤ−ＪオブジェクトBDJO−3Dに規定されたＪａｖａ(登録商標)アプリケーション・プログラムに従ってその選択処理が実行される。
ここで、その選択処理の前提として、再生装置２００が第１フラグと第２フラグとを含むときを想定する。第１フラグが“０”であるとき、再生装置２００は２Ｄ映像の再生のみに対応可能であり、“１”であるとき、３Ｄ映像の再生にも対応可能である。第２フラグが“０”であるとき、再生装置２００はＬ／Ｒモードであり、“１”であるとき、デプス・モードである。
ステップＳ４５０１では、再生装置２００は第１フラグの値をチェックする。その値が０であるとき、処理はステップＳ４５０５へ進む。その値が１であるとき、処理はステップＳ４５０２へ進む。
ステップＳ４５０２では、再生装置２００はテレビ３００にメニューを表示させて、ユーザに２Ｄ映像と３Ｄ映像とのいずれかの再生を選択させる。ユーザがリモコン105等を操作して、２Ｄ映像の再生を選択したとき、処理はステップＳ４５０５へ進み、３Ｄ映像の再生を選択したとき、処理はステップＳ４５０３へ進む。
ステップＳ４５０３では、再生装置２００は、テレビ３００が３Ｄ映像の再生に対応しているかチェックする。具体的には、再生装置２００はＨＤＭＩケーブルを通してテレビ３００との間でＣＥＣメッセージを交換し、テレビ３００が３Ｄ映像の再生に対応しているか否かをテレビ３００に問い合わせる。テレビ３００が３Ｄ映像の再生に対応しているとき、処理はステップＳ４５０４へ進む。テレビ３００が３Ｄ映像の再生に対応していないとき、処理はステップＳ４５０５へ進む。
ステップＳ４５０４では、再生装置２００は第２フラグの値をチェックする。その値が０であるとき、処理はステップＳ４５０６へ進む。その値が１であるとき、処理はステップＳ４５０７へ進む。
ステップＳ４５０５では、再生装置２００は２Ｄプレイリスト・ファイル521を再生対象として選択する。尚、そのとき、再生装置２００はテレビ３００に、３Ｄ映像の再生が選択されなかった理由を表示させてもよい。
ステップＳ４５０６では、再生装置２００はＬ／Ｒモード用の３Ｄプレイリスト・ファイル522を再生対象として選択する。
ステップＳ４５０７では、再生装置２００はデプス・モード用の３Ｄプレイリスト・ファイル523を再生対象として選択する。
以上が本発明の実施形態１に係る記録媒体１００についての説明である。

＜２Ｄ再生装置の構成＞
２Ｄ再生モードの再生装置２００は記録媒体１００から２Ｄ映像コンテンツを再生するとき、２Ｄ再生装置として動作する。図５４は、２Ｄ再生装置4600の機能ブロック図である。図５４を参照するに、２Ｄ再生装置4600は、ＢＤ−ＲＯＭドライブ4601、再生部4600A、及び制御部4600Bを含む。再生部4600Aは、リード・バッファ4602、システム・ターゲット・デコーダ4603、及びプレーン加算部4610を含む。制御部4600Bは、動的シナリオ・メモリ4604、静的シナリオ・メモリ4605、プログラム実行部4606、再生制御部4607、プレーヤ変数記憶部4608、及びユーザイベント処理部4609を含む。再生部4600Aと制御部4600Bとは互いに異なる集積回路に実装されている。その他に、両者が単一の集積回路に統合されていてもよい。
ＢＤ−ＲＯＭドライブ4601は、内部に記録媒体１００が挿入されたとき、その記録媒体１００にレーザ光を照射してその反射光の変化を検出する。更に、その反射光の光量の変化から、記録媒体１００に記録されたデータを読み取る。具体的には、ＢＤ−ＲＯＭドライブ4601は光ピックアップ、すなわち光学ヘッドを備えている。その光学ヘッドは、半導体レーザ、コリメータ・レンズ、ビーム・スプリッタ、対物レンズ、集光レンズ、及び光検出器を含む。半導体レーザから出射された光ビームは、コリメータ・レンズ、ビーム・スプリッタ、及び対物レンズを順に通って記録媒体１００の記録層に集められる。集められた光ビームはその記録層で反射／回折される。その反射／回折光は、対物レンズ、ビーム・スプリッタ、及び集光レンズを通って光検出器に集められる。光検出器は、その集光量に応じたレベルの再生信号を生成する。更に、その再生信号からデータが復調される。
ＢＤ−ＲＯＭドライブ4601は、再生制御部4607からの要求に従って記録媒体１００からデータを読み出す。そのデータのうち、ファイル２Ｄのエクステント、すなわち２Ｄエクステントはリード・バッファ4602へ転送され、動的シナリオ情報は動的シナリオ・メモリ4604へ転送され、静的シナリオ情報は静的シナリオ・メモリ4605へ転送される。「動的シナリオ情報」は、インデックス・ファイル、ムービーオブジェクト・ファイル、及びＢＤ−Ｊオブジェクト・ファイルを含む。「静的シナリオ情報」は２Ｄプレイリスト・ファイルと２Ｄクリップ情報ファイルとを含む。
リード・バッファ4602、動的シナリオ・メモリ4604、及び静的シナリオ・メモリ4605はいずれもバッファ・メモリである。リード・バッファ4602としては再生部4600A内のメモリ素子が利用され、動的シナリオ・メモリ4604及び静的シナリオ・メモリ4605としては制御部4600B内のメモリ素子が利用される。その他に、それらのバッファ・メモリ4602、4604、4605として、単一のメモリ素子の異なる領域が利用されてもよい。リード・バッファ4602は２Ｄエクステントを格納し、動的シナリオ・メモリ4604は動的シナリオ情報を格納し、静的シナリオ・メモリ4605は静的シナリオ情報を格納する。
システム・ターゲット・デコーダ4603は、リード・バッファ4602から２Ｄエクステントをソースパケット単位で読み出して多重分離処理を行い、更に分離された各エレメンタリ・ストリームに対して復号処理を行う。ここで、各エレメンタリ・ストリームの復号に必要な情報、例えばコーデックの種類及びストリームの属性は予め、再生制御部4607からシステム・ターゲット・デコーダ4603へ転送されている。システム・ターゲット・デコーダ4603は更に、復号後のプライマリ・ビデオ・ストリーム、セカンダリ・ビデオ・ストリーム、ＩＧストリーム、及びＰＧストリームをそれぞれ、ＶＡＵごとに、主映像プレーン・データ、副映像プレーン・データ、ＩＧプレーン・データ、及びＰＧプレーン・データとして送出する。一方、システム・ターゲット・デコーダ4603は、復号後のプライマリ・オーディオ・ストリームとセカンダリ・オーディオ・ストリームとをミキシングしてテレビ３００の内蔵スピーカ103A等の音声出力装置へ送出する。その他に、システム・ターゲット・デコーダ4603はプログラム実行部4606からグラフィックス・データを受信する。そのグラフィックス・データは、ＧＵＩ用のメニュー等のグラフィックスを画面に表示するためのものであり、ＪＰＥＧ又はＰＮＧ等のラスタデータで表現されている。システム・ターゲット・デコーダ4603はそのグラフィックス・データを処理してイメージ・プレーン・データとして送出する。尚、システム・ターゲット・デコーダ4603の詳細については後述する。
ユーザイベント処理部4609は、リモコン105又は再生装置２００のフロントパネルを通してユーザの操作を検出し、その操作の種類に応じて、プログラム実行部4606又は再生制御部4607に処理を依頼する。例えばユーザがリモコン105のボタンを押下してポップアップ・メニューの表示を指示したとき、ユーザイベント処理部4609はその押下を検出してそのボタンを識別する。ユーザイベント処理部4609は更にプログラム実行部4606に、そのボタンに対応するコマンドの実行、すなわちポップアップ・メニューの表示処理を依頼する。一方、例えばユーザがリモコン105の早送り又は巻戻しボタンを押下したとき、ユーザイベント処理部4609はその押下を検出してそのボタンを識別する。ユーザイベント処理部4609は更に再生制御部4607に、現在再生中のプレイリストの早送り又は巻戻し処理を依頼する。
再生制御部4607は、２Ｄエクステント及びインデックス・ファイル等、各種のデータを記録媒体１００から、リード・バッファ4602、動的シナリオ・メモリ4604、及び静的シナリオ・メモリ4605へ転送する処理を制御する。その制御には、図７に示されているディレクトリ／ファイル構造を管理するファイルシステムが利用される。すなわち、再生制御部4607はファイル・オープン用のシステムコールを利用して、ＢＤ−ＲＯＭドライブ4601に各種のファイルを各バッファ・メモリ4602、4604、4605へ転送させる。ここで、ファイル・オープンとは次の一連の処理をいう。まず、システムコールによってファイルシステムに検索対象のファイル名が与えられ、そのファイル名がディレクトリ／ファイル構造から検索される。その検索に成功したとき、再生制御部4607内のメモリには、まず、転送対象のファイルのファイル・エントリが転送され、そのメモリ内にＦＣＢ（File Control Block）が生成される。その後、転送対象のファイルのファイル・ハンドルがファイルシステムから再生制御部4607に返される。以後、再生制御部4607はそのファイル・ハンドルをＢＤ−ＲＯＭドライブ4601に提示することにより、ＢＤ−ＲＯＭドライブ4601にその転送対象のファイルを記録媒体１００から各バッファ・メモリ4602、4604、4605へ転送させることができる。
再生制御部4607は、ＢＤ−ＲＯＭドライブ4601とシステム・ターゲット・デコーダ4603とを制御してファイル２Ｄから映像データと音声データとを復号させる。具体的には、再生制御部4607はまず、プログラム実行部4606からの命令、又はユーザイベント処理部4609からの依頼に応じて、静的シナリオ・メモリ4605から２Ｄプレイリスト・ファイルを読み出してその内容を解釈する。再生制御部4607は次に、その解釈された内容、特に再生経路に従って、ＢＤ−ＲＯＭドライブ4601とシステム・ターゲット・デコーダ4603とに再生対象のファイル２Ｄを指定して、その読み出し処理及び復号処理を指示する。このようなプレイリスト・ファイルに基づく再生処理を「プレイリスト再生」という。その他に、再生制御部4607は、静的シナリオ情報を利用してプレーヤ変数記憶部4608に各種のプレーヤ変数を設定する。再生制御部4607は更に、それらのプレーヤ変数を参照して、システム・ターゲット・デコーダ4603に復号対象のエレメンタリ・ストリームを指定し、かつ、各エレメンタリ・ストリームの復号に必要な情報を提供する。
プレーヤ変数記憶部4608は、プレーヤ変数を記憶するためのレジスタ群である。プレーヤ変数の種類にはシステム・パラメータ（ＳＰＲＭ）と汎用のパラメータ（ＧＰＲＭ）とがある。ＳＰＲＭは再生装置２００の状態を示す。図５５はＳＰＲＭの一覧表である。各ＳＰＲＭには通し番号4701が振られ、各通し番号4701に変数値4702が個別に対応付けられている。主なＳＰＲＭの内容は以下のとおりである。ここで、括弧内の数字は通し番号4701を示す。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： プライマリ・オーディオ・ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーション・タイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタル・レベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： オーディオ・ストリーム用言語コード
ＳＰＲＭ（１７） ： オーディオ・ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤ・リージョン・コード
ＳＰＲＭ（２１） ： セカンダリ・ビデオ・ストリーム番号
ＳＰＲＭ（２２） ： セカンダリ・オーディオ・ストリーム番号
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
ＳＰＲＭ（１０）は、復号処理中のピクチャのＰＴＳを示し、そのピクチャが復号されて主映像プレーン・メモリに書き込まれる度に更新される。従って、ＳＰＲＭ（１０）を参照すれば、現在の再生時点を知ることができる。
ＳＰＲＭ（１６）のオーディオ・ストリーム用言語コード、及びＳＰＲＭ（１８）の字幕ストリーム用言語コードは、再生装置２００のデフォルトの言語コードを示す。それらは再生装置２００のＯＳＤ等を利用してユーザに変更させることもでき、プログラム実行部4606を通じてアプリケーション・プログラムに変更させることもできる。例えばＳＰＲＭ（１６）が「英語」を示しているとき、再生制御部4607はプレイリスト再生処理において、まずＰＩ内のＳＴＮテーブルから、「英語」の言語コードを含むストリーム・エントリを検索する。再生制御部4607は次に、そのストリーム・エントリのストリーム識別情報からＰＩＤを抽出してシステム・ターゲット・デコーダ4603に渡す。それにより、そのＰＩＤのオーディオ・ストリームがシステム・ターゲット・デコーダ4603によって選択され、復号される。これらの処理は、ムービーオブジェクト・ファイル又はＢＤ−Ｊオブジェクト・ファイルを利用して再生制御部4607に実行させることができる。
再生制御部4607は再生処理中、再生状態の変化に応じてプレーヤ変数を更新する。再生制御部4607は特に、ＳＰＲＭ（１）、ＳＰＲＭ（２）、ＳＰＲＭ（２１）、及びＳＰＲＭ（２２）を更新する。それらは順に、処理中のオーディオ・ストリーム、字幕ストリーム、セカンダリ・ビデオ・ストリーム、及びセカンダリ・オーディオ・ストリームの各ＳＴＮを示す。例えばプログラム実行部4606によってＳＰＲＭ（１）が変更されたときを想定する。再生制御部4607はそのとき、まず現時点で再生処理中のＰＩ内のＳＴＮテーブルから、変更後のＳＰＲＭ（１）の示すＳＴＮを含むストリーム・エントリを検索する。再生制御部4607は次に、そのストリーム・エントリ内のストリーム識別情報からＰＩＤを抽出してシステム・ターゲット・デコーダ4603に渡す。それにより、そのＰＩＤのオーディオ・ストリームがシステム・ターゲット・デコーダ4603によって選択され、復号される。こうして、再生対象のオーディオ・ストリームが切り換えられる。同様に、再生対象の字幕及びセカンダリ・ビデオ・ストリームを切り換えることもできる。
プログラム実行部4606はプロセッサであり、ムービーオブジェクト・ファイル及びＢＤ−Ｊオブジェクト・ファイルに格納されたプログラムを実行する。プログラム実行部4606は各プログラムに従って、特に次のような制御を行う：（１）再生制御部4607に対してプレイリスト再生処理を命令する；（２）メニュー用又はゲーム用のグラフィックス・データをＰＮＧ又はＪＰＥＧのラスタデータとして生成し、それをシステム・ターゲット・デコーダ4603へ転送して他の映像データに合成させる。これらの制御の具体的な内容はプログラムの設計を通じて比較的自由に設計することができる。すなわち、それらの制御内容は、記録媒体１００のオーサリング工程のうち、ムービーオブジェクト・ファイル及びＢＤ−Ｊオブジェクト・ファイルのプログラミング工程によって決まる。
プレーン加算部4610は、システム・ターゲット・デコーダ4603から、主映像プレーン・データ、副映像プレーン・データ、ＩＧプレーン・データ、ＰＧプレーン・データ、及びイメージ・プレーン・データを受信し、それらを互いに重畳して一つの映像フレーム又はフィールドに合成する。合成後の映像データはテレビ３００へ送出され、その画面に表示される。
≪システム・ターゲット・デコーダ≫
図５６は、システム・ターゲット・デコーダ4603の機能ブロック図である。図５６を参照するに、システム・ターゲット・デコーダ4603は、ソース・デパケタイザ4810、ＡＴＣカウンタ4820、第１の２７ＭＨｚクロック4830、ＰＩＤフィルタ4840、ＳＴＣカウンタ（ＳＴＣ１）4850、第２の２７ＭＨｚクロック4860、主映像デコーダ4870、副映像デコーダ4871、ＰＧデコーダ4872、ＩＧデコーダ4873、主音声デコーダ4874、副音声デコーダ4875、イメージ・プロセッサ4880、主映像プレーン・メモリ4890、副映像プレーン・メモリ4891、ＰＧプレーン・メモリ4892、ＩＧプレーン・メモリ4893、イメージ・プレーン・メモリ4894、及び音声ミキサ4895を含む。
ソース・デパケタイザ4810はリード・バッファ4602からソースパケットを読み出し、その中からＴＳパケットを取り出してＰＩＤフィルタ4840へ送出する。ソース・デパケタイザ4810は更に、その送出の時刻を各ソースパケットのＡＴＳに応じて調整する。具体的には、ソース・デパケタイザ4810はまず、ＡＴＣカウンタ4820が生成するＡＴＣの値を監視する。ここで、ＡＴＣの値はＡＴＣカウンタ4820により、第１の２７ＭＨｚクロック4830のクロック信号のパルスに応じてインクリメントされる。ソース・デパケタイザ4810は次に、ＡＴＣの値がソースパケットのＡＴＳと一致した瞬間、そのソースパケットから取り出されたＴＳパケットをＰＩＤフィルタ4840へ転送する。そのような送出時刻の調整により、ソース・デパケタイザ4810からＰＩＤフィルタ4840へのＴＳパケットの平均転送速度RTSは、図３８に示されている２Ｄクリップ情報ファイルの示すシステムレート3111を超えない。
ＰＩＤフィルタ4840はまず、ソース・デパケタイザ4810から送出されたＴＳパケットの含むＰＩＤを監視する。そのＰＩＤが、再生制御部4807から予め指定されたＰＩＤに一致したとき、ＰＩＤフィルタ4840はそのＴＳパケットを選択し、そのＰＩＤの示すエレメンタリ・ストリームの復号に適したデコーダ4870−4875へ転送する。例えばＰＩＤが０ｘ１０１１であるとき、そのＴＳパケットは主映像デコーダ4870へ転送される。一方、ＰＩＤが、０ｘ１Ｂ００−０ｘ１Ｂ１Ｆ、０ｘ１１００−０ｘ１１１Ｆ、０ｘ１Ａ００−０ｘ１Ａ１Ｆ、０ｘ１２００−０ｘ１２１Ｆ、及び０ｘ１４００−０ｘ１４１Ｆの各範囲に属するとき、ＴＳパケットはそれぞれ、副映像デコーダ4871、主音声デコーダ4874、副音声デコーダ4875、ＰＧデコーダ4872、及びＩＧデコーダ4873へ転送される。
ＰＩＤフィルタ4840は更に、各ＴＳパケットのＰＩＤを利用してそのＴＳパケットの中からＰＣＲを検出する。ＰＩＤフィルタ4840はそのとき、ＳＴＣカウンタ4850の値を所定値に設定する。ここで、ＳＴＣカウンタ4850の値は第２の２７ＭＨｚクロック4860のクロック信号のパルスに応じてインクリメントされる。また、ＳＴＣカウンタ4850に設定されるべき値は予め、再生制御部4807からＰＩＤフィルタ4840に指示されている。各デコーダ4870−4875はＳＴＣカウンタ4850の値をＳＴＣとして利用する。すなわち、ＰＩＤフィルタ4840から送出されたＴＳパケットに対する復号処理の時期を、そのＴＳパケットに含まれるＰＴＳ又はＤＴＳの示す時刻に従って調節する。
主映像デコーダ4870は、図５６に示されているように、トランスポート・ストリーム・バッファ（ＴＢ：Transport Stream Buffer）4801、多重化バッファ（ＭＢ：Multiplexing Buffer）4802、エレメンタリ・ストリーム・バッファ（ＥＢ：Elementary Stream Buffer）4803、圧縮映像デコーダ（ＤＥＣ）4804、及び復号ピクチャ・バッファ（ＤＰＢ：Decoded Picture Buffer）4805を含む。ＴＢ4801、ＭＢ4802、ＥＢ4803、及びＤＰＢ4805はいずれもバッファ・メモリであり、それぞれ主映像デコーダ4870に内蔵のメモリ素子の一領域を利用する。その他に、それらのいずれか又は全てが異なるメモリ素子に分離されていてもよい。ＴＢ4801は、ＰＩＤフィルタ4840から受信されたＴＳパケットをそのまま蓄積する。ＭＢ4802は、ＴＢ4801に蓄積されたＴＳパケットから復元されたＰＥＳパケットを蓄積する。尚、ＴＢ4801からＭＢ4802へＴＳパケットが転送されるとき、そのＴＳパケットからＴＳヘッダが除去される。ＥＢ4803は、ＰＥＳパケットから、符号化されたＶＡＵを抽出して格納する。そのＶＡＵには、圧縮ピクチャ、すなわち、Ｉピクチャ、Ｂピクチャ、及びＰピクチャが格納されている。尚、ＭＢ4802からＥＢ4803へデータが転送されるとき、そのＰＥＳパケットからＰＥＳヘッダが除去される。ＤＥＣ4804は、ＥＢ4803内の各ＶＡＵからピクチャを、元のＴＳパケットに含まれるＤＴＳの示す時刻に復号する。ＤＥＣ4804はその他に、図１３に示されているデコードスイッチ情報を利用して、各ＶＡＵからピクチャをそのＤＴＳに関わらず、順次復号してもよい。ＤＥＣ4804は、各ＶＡＵ内に格納された圧縮ピクチャの圧縮符号化方式、例えば、ＭＰＥＧ−２、ＭＰＥＧ−４ ＡＶＣ、及びＶＣ１、並びにストリーム属性に応じて復号方法を切り換える。ＤＥＣ4804は更に、復号後のピクチャ、すなわちフレーム又はフィールドをＤＰＢ4805へ転送する。ＤＰＢ4805は復号後のピクチャを一時的に保持する。ＤＥＣ4804は、Ｐピクチャ及びＢピクチャを復号するとき、ＤＰＢ4805に保持されている復号後のピクチャを参照する。ＤＰＢ4805は更に、保持している各ピクチャを、元のＴＳパケットに含まれるＰＴＳの示す時刻に主映像プレーン・メモリ4890へ書き込む。
副映像デコーダ4871は主映像デコーダ4870と同様の構成を含む。副映像デコーダ4871はまず、ＰＩＤフィルタ4840から受信されたセカンダリ・ビデオ・ストリームのＴＳパケットを非圧縮のピクチャに復号する。副映像デコーダ4871は次に、そのＴＳパケットに含まれるＰＴＳの示す時刻に非圧縮のピクチャを副映像プレーン・メモリ4891へ書き込む。
ＰＧデコーダ4872は、ＰＩＤフィルタ4840から受信されたＴＳパケットを非圧縮のグラフィックス・データに復号し、そのＴＳパケットに含まれるＰＴＳの示す時刻にＰＧプレーン・メモリ4892へ書き込む。
ＩＧデコーダ4873は、ＰＩＤフィルタ4840から受信されたＴＳパケットを非圧縮のグラフィックス・データに復号し、そのＴＳパケットに含まれるＰＴＳの示す時刻にＩＧプレーン・メモリ4893へ書き込む。
主音声デコーダ4874はまず、ＰＩＤフィルタ4840から受信されたＴＳパケットを内蔵のバッファに蓄える。主音声デコーダ4874は次に、そのバッファ内の各ＴＳパケットからＴＳヘッダとＰＥＳヘッダとを除去し、残りのデータを非圧縮のＬＰＣＭ音声データに復号する。主音声デコーダ4874は更にその音声データを、元のＴＳパケットに含まれるＰＴＳの示す時刻に音声ミキサ4895へ送出する。主音声デコーダ4874は、ＴＳパケットに含まれるプライマリ・オーディオ・ストリームの圧縮符号化方式、例えばＡＣ−３又はＤＴＳ、及びストリーム属性に応じて、圧縮音声データの復号方法を切り換える。
副音声デコーダ4875は主音声デコーダ4874と同様の構成を含む。副音声デコーダ4875はまず、ＰＩＤフィルタ4840から受信されたセカンダリ・オーディオ・ストリームのＴＳパケットを非圧縮のＬＰＣＭ音声データに復号する。副音声デコーダ4875は次に、そのＴＳパケットに含まれるＰＴＳの示す時刻に非圧縮のＬＰＣＭ音声データを音声ミキサ4895へ送出する。副音声デコーダ4875は、ＴＳパケットに含まれるセカンダリ・オーディオ・ストリームの圧縮符号化方式、例えば、ドルビー・デジタル・プラス、ＤＴＳ−ＨＤ ＬＢＲ、及びストリーム属性に応じて圧縮音声データの復号方法を切り換える。
音声ミキサ4895は、主音声デコーダ4874と副音声デコーダ4875とのそれぞれから非圧縮の音声データを受信し、それらを用いてミキシング（音の重ね合わせ）を行う。音声ミキサ4895は更に、そのミキシングで得られた合成音をテレビ３００の内蔵スピーカ103A等へ送出する。
イメージ・プロセッサ4880は、プログラム実行部4806からグラフィックス・データ、すなわちＰＮＧ又はＪＰＥＧのラスタデータを受信する。イメージ・プロセッサ4880はそのとき、そのグラフィックス・データに対するレンダリング処理を行ってイメージ・プレーン・メモリ4894へ書き込む。

＜３Ｄ再生装置の構成＞
３Ｄ再生モードの再生装置２００は記録媒体１００から３Ｄ映像コンテンツを再生するとき、３Ｄ再生装置として動作する。その構成の基本部分は、図５４−５６に示されている２Ｄ再生装置の構成と同様である。従って、以下では２Ｄ再生装置の構成からの拡張部分及び変更部分について説明し、基本部分の詳細についての説明は上記の２Ｄ再生装置についての説明を援用する。また、２Ｄプレイリスト・ファイルに従った２Ｄ映像の再生処理、すなわち２Ｄプレイリスト再生処理に利用される構成は２Ｄ再生装置の構成と同様である。従って、その詳細についての説明も上記の２Ｄ再生装置についての説明を援用する。以下の説明では、３Ｄプレイリスト・ファイルに従った３Ｄ映像の再生処理、すなわち３Ｄプレイリスト再生処理を想定する。
図５７は、３Ｄ再生装置4900の機能ブロック図である。３Ｄ再生装置4900は、ＢＤ−ＲＯＭドライブ4901、再生部4900A、及び制御部4900Bを含む。再生部4900Aは、スイッチ4911、第１リード・バッファ4921、第２リード・バッファ4922、システム・ターゲット・デコーダ4903、及びプレーン加算部4910を含む。制御部4900Bは、動的シナリオ・メモリ4904、静的シナリオ・メモリ4905、プログラム実行部4906、再生制御部4907、プレーヤ変数記憶部4908、及びユーザイベント処理部4909を含む。再生部4900Aと制御部4900Bとは互いに異なる集積回路に実装されている。その他に、両者が単一の集積回路に統合されていてもよい。特に、動的シナリオ・メモリ4904、静的シナリオ・メモリ4905、プログラム実行部4906、及びユーザイベント処理部4909は、図５４に示されている２Ｄ再生装置内のものと同様である。従って、それらの詳細についての説明は上記の２Ｄ再生装置についての説明を援用する。
ＢＤ−ＲＯＭドライブ4901は、図５４に示されている２Ｄ再生装置内のもの4601と同様な構成要素を含む。ＢＤ−ＲＯＭドライブ4901は、再生制御部4907からＬＢＮの範囲が指示されたとき、その範囲の示す記録媒体１００上のセクタ群からデータを読み出す。特にファイルＳＳのエクステント、すなわち３Ｄエクステントに属するソースパケット群は、ＢＤ−ＲＯＭドライブ4901からスイッチ4911へ転送される。ここで、各３Ｄエクステントは、図１８の（ｄ）及び図４１に示されているとおり、ベースビューとディペンデントビューとのデータ・ブロックの対を一つ以上含む。それらのデータ・ブロックは異なるリード・バッファ4921、4922へパラレルに転送されなければならない。従って、ＢＤ−ＲＯＭドライブ4901には２Ｄ再生装置内のＢＤ−ＲＯＭドライブ4601以上のアクセス・スピードが求められる。
スイッチ4911はＢＤ−ＲＯＭドライブ4901からは３Ｄエクステントを受信する。一方、スイッチ4911は再生制御部4907からは、その３Ｄエクステントに含まれる各データ・ブロックの境界を示す情報、例えばその３Ｄエクステントの先頭から各境界までのソースパケット数を受信する。ここで、再生制御部4907はその情報を、クリップ情報ファイル内のエクステント起点を利用して生成する。スイッチ4911は更に、その情報を利用して各３Ｄエクステントからベースビュー・データ・ブロックを抽出して、第１リード・バッファ4921へ送出する。一方、スイッチ4911は残りのディペンデントビュー・データ・ブロックを第２リード・バッファ4922へ送出する。
第１リード・バッファ4921と第２リード・バッファ4922とはいずれも、再生部4900A内のメモリ素子を利用したバッファ・メモリである。特に単一のメモリ素子内の異なる領域が各リード・バッファ4921、4922として利用される。その他に、異なるメモリ素子が個別に各リード・バッファ4921、4922として利用されてもよい。第１リード・バッファ4921は、スイッチ4911からベースビュー・データ・ブロックを受信して格納する。第２リード・バッファ4922は、スイッチ4911からディペンデントビュー・データ・ブロックを受信して格納する。
システム・ターゲット・デコーダ4903はまず、第１リード・バッファ4921に格納されたベースビュー・データ・ブロックと、第２リード・バッファ4922に格納されたディペンデントビュー・データ・ブロックとから交互にソースパケットを読み出す。システム・ターゲット・デコーダ4903は次に、多重分離処理によって各ソースパケットからエレメンタリ・ストリームを分離し、更に分離されたものの中から、再生制御部4907から指示されたＰＩＤの示すものを復号する。システム・ターゲット・デコーダ4903は続いて、復号後のエレメンタリ・ストリームをその種類別に内蔵のプレーン・メモリに書き込む。ベースビュー・ビデオ・ストリームは左映像プレーン・メモリに書き込まれ、ディペンデントビュー・ビデオ・ストリームは右映像プレーン・メモリに書き込まれる。一方、セカンダリ・ビデオ・ストリームは副映像プレーン・メモリに書き込まれ、ＩＧストリームはＩＧプレーン・メモリに書き込まれ、ＰＧストリームはＰＧプレーン・メモリに書き込まれる。ここで、ビデオ・ストリーム以外のストリーム・データがベースビューとディペンデントビューとのストリーム・データの対から成るとき、対応するプレーン・メモリはレフトビューとライトビューとの両方のプレーン・データに対して個別に用意される。システム・ターゲット・デコーダ4903はその他に、プログラム実行部4906からのグラフィックス・データ、例えばＪＰＥＧ又はＰＮＧ等のラスタデータを処理してイメージ・プレーン・メモリに書き込む。
システム・ターゲット・デコーダ4903は、左映像と右映像との各プレーン・メモリからのプレーン・データの出力をＢ−Ｄ表示モードとＢ−Ｂ表示モードとに対応させる。再生制御部4907からＢ−Ｄ表示モードが指示されたとき、システム・ターゲット・デコーダ4903は左映像と右映像との各プレーン・メモリから交互にプレーン・データを出力する。一方、再生制御部4907からＢ−Ｂ表示モードが指示されたとき、システム・ターゲット・デコーダ4903は動作モードを３Ｄ再生モードに維持したまま、左映像と右映像とのいずれかのプレーン・メモリからのみプレーン・データをフレーム当たり二回ずつ出力する。
システム・ターゲット・デコーダ4903は更に、グラフィックス・プレーン・メモリ、すなわち、ＰＧプレーン・メモリ、ＩＧプレーン・メモリ、及びイメージ・プレーン・メモリからの各グラフィックス・プレーン・データの出力を、２プレーン・モード、１プレーン＋オフセット・モード、及び１プレーン＋ゼロ・オフセット・モードに対応させる。再生制御部4907から２プレーン・モードが指示されたとき、システム・ターゲット・デコーダ4903は各グラフィックス・プレーン・メモリからレフトビューとライトビューとのグラフィックス・プレーン・データを交互に出力する。再生制御部4907から１プレーン＋オフセット・モード又は１プレーン＋ゼロ・オフセット・モードが指示されたとき、システム・ターゲット・デコーダ4903は動作モードを３Ｄ再生モードに維持したまま、各グラフィックス・プレーン・メモリからグラフィックス・プレーン・データを出力する。再生制御部4907から１プレーン＋オフセット・モードが指示されたときは更に、システム・ターゲット・デコーダ4903は、再生制御部4907によって指定されたオフセット値をプレーン加算部4910に渡す。ここで、再生制御部4907は、そのオフセット値をクリップ情報ファイル内のオフセット・テーブルに基づいて設定する。一方、再生制御部4907から１プレーン＋ゼロ・オフセット・モードが指示されたときは、システム・ターゲット・デコーダ4903はオフセット値として“０”をプレーン加算部4910に渡す。
再生制御部4907は、３Ｄプレイリスト再生処理をプログラム実行部4906等から命じられたとき、まず、静的シナリオ・メモリ4905に格納された３Ｄプレイリスト・ファイルを参照する。再生制御部4907は次に、３Ｄプレイリスト・ファイルに従い、図５１に示されている手順で、読み出し対象の３Ｄエクステントが記録されたセクタ群のＬＢＮの範囲をＢＤ−ＲＯＭドライブ4901に指示する。一方、再生制御部4907は、静的シナリオ・メモリ4905に格納されたクリップ情報ファイル内の３Ｄメタデータを参照して、読み出し対象の各３Ｄエクステントに関するエクステント起点を検索する。再生制御部4907は更に、そのエクステント起点から、各３Ｄエクステントに含まれるデータ・ブロックの境界を示す情報を生成する。その情報が再生制御部4907からスイッチ4911へ送出される。
再生制御部4907はその他に、３Ｄプレイリスト・ファイル内のＳＴＮテーブルとＳＴＮテーブルＳＳとを利用して、システム・ターゲット・デコーダ4903とプレーン加算部4910との動作条件を制御する。例えば、再生対象のエレメンタリ・ストリームのＰＩＤが選択されて、システム・ターゲット・デコーダ4903に渡される。また、ＳＴＮテーブルＳＳのうち、ポップアップ期間のオフセット4111に応じて各プレーンの表示モードが選択されてシステム・ターゲット・デコーダ4903とプレーン加算部4910とに指示される。
プレーヤ変数記憶部4908は、２Ｄ再生装置内のものと同様に、図５５に示されているＳＰＲＭを含む。しかし、図５５では予備であったＳＰＲＭ（２４）−（３２）のいずれか二つは、図５３に示されている第１フラグと第２フラグとを個別に含む。例えば、ＳＰＲＭ（２４）が第１フラグを含み、ＳＰＲＭ（２５）が第２フラグを含む。その場合、ＳＰＲＭ（２４）が“０”であるときは再生装置２００が２Ｄ映像の再生のみに対応可能であり、“１”であるときは３Ｄ映像の再生にも対応可能である。ＳＰＲＭ（２５）が“０”であるときは再生装置２００がＬ／Ｒモードであり、“１”であるときはデプス・モードである。
プレーン加算部4910はシステム・ターゲット・デコーダ4903から各種のプレーン・データを受信し、それらを互いに重畳して一つのフレーム又はフィールドに合成する。特にＬ／Ｒモードでは、左映像プレーン・データはレフトビュー・ビデオ・プレーンを表し、右映像プレーン・データはライトビュー・ビデオ・プレーンを表す。従って、プレーン加算部4910は、左映像プレーン・データには、他のプレーン・データのうち、レフトビューを表すものを重畳し、右映像プレーン・データには、ライトビューを表すものを重畳する。一方、デプス・モードでは、右映像プレーン・データは、左映像プレーン・データの表すビデオ・プレーンに対するデプスマップを表す。従って、プレーン加算部4910はまず、両方の映像プレーン・データからレフトビューとライトビューとのビデオ・プレーン・データの対を生成する。その後、プレーン加算部4910はＬ／Ｒモードでの合成処理と同様に合成処理を行う。
再生制御部4907から、副映像プレーン、ＰＧプレーン、ＩＧプレーン、又はイメージ・プレーンの表示モードとして１プレーン＋オフセット・モード又は１プレーン＋ゼロ・オフセット・モードが指示されているとき、プレーン加算部4910は、システム・ターゲット・デコーダ4903から受信されたプレーン・データに対してクロッピング処理を行う。それにより、レフトビューとライトビューとのプレーン・データの対が生成される。特に１プレーン＋オフセット・モードが指示されているとき、そのクロッピング処理では、システム・ターゲット・デコーダ4903又はプログラム実行部4906から指示されたオフセット値が利用される。一方、１プレーン＋ゼロ・オフセット・モードが指示されているとき、そのクロッピング処理ではオフセット値が“０”に設定されている。従って、同じプレーン・データが、レフトビューとライトビューとを表すものとして繰り返し出力される。その後、プレーン加算部4910はＬ／Ｒモードでの合成処理と同様に合成処理を行う。合成後のフレーム又はフィールドはテレビ３００へ送出され、その画面に表示される。
≪システム・ターゲット・デコーダ≫
図５８は、システム・ターゲット・デコーダ4903の機能ブロック図である。図５８に示されている構成要素は、図５４に示されている２Ｄ再生装置のもの4603とは次の二点で異なる：（１）リード・バッファから各デコーダへの入力系統が二重化されている点、並びに、（２）主映像デコーダは３Ｄ再生モードに対応可能であり、副映像デコーダ、ＰＧデコーダ、及びＩＧデコーダは２プレーン・モードに対応可能である点。すなわち、それらの映像デコーダはいずれもベースビューとディペンデントビューとのそれぞれのストリームを交互に復号できる点。一方、主音声デコーダ、副音声デコーダ、音声ミキサ、イメージ・プロセッサ、及び各プレーン・メモリは、図５４に示されている２Ｄ再生装置のものと同様である。従って、以下では、図５８に示されている構成要素のうち、図５４に示されているものとは異なるものについて説明し、同様なものの詳細についての説明は、図５４についての説明を援用する。更に、各映像デコーダはいずれも同様な構造を持つので、以下では主映像デコーダ5015の構造について説明し、他の映像デコーダの構造についてはその説明を援用する。
第１ソース・デパケタイザ5011は、第１リード・バッファ4921からソースパケットを読み出して、その中からＴＳパケットを取り出して第１ＰＩＤフィルタ5013へ送出する。第２ソース・デパケタイザ5012は、第２リード・バッファ4922からソースパケットを読み出して、その中からＴＳパケットを取り出して第２ＰＩＤフィルタ5014へ送出する。各ソース・デパケタイザ5011、5012は更に、各ＴＳパケットの送出時刻を各ソースパケットのＡＴＳに応じて調整する。その調整方法は、図５４に示されているソース・デパケタイザ4610による方法と同様であるので、その詳細についての説明は、図５４についての説明を援用する。そのような調節により、第１ソース・デパケタイザ5011から第１ＰＩＤフィルタ5013へのＴＳパケットの平均転送速度RTS1は、図３７に示されている２Ｄクリップ情報ファイルの示すシステムレート3011を超えない。同様に、第２ソース・デパケタイザ5012から第２ＰＩＤフィルタ5014へのＴＳパケットの平均転送速度RTS2は、ディペンデントビュー・クリップ情報ファイルの示すシステムレートを超えない。
第１ＰＩＤフィルタ5013は、第１ソース・デパケタイザ5011からＴＳパケットを受信する度に、そのＰＩＤを選択対象のＰＩＤと比較する。その選択対象のＰＩＤは再生制御部4907によって予め、３Ｄプレイリスト・ファイル内のＳＴＮテーブルに従って指定されている。両方のＰＩＤが一致したとき、第１ＰＩＤフィルタ5013はそのＴＳパケットを、そのＰＩＤに割り当てられたデコーダへ転送する。例えば、ＰＩＤが０ｘ１０１１であるとき、そのＴＳパケットは主映像デコーダ5015内のＴＢ（１）5001へ転送される。その他に、ＰＩＤが、０ｘ１Ｂ００−０ｘ１Ｂ１Ｆ、０ｘ１１００−０ｘ１１１Ｆ、０ｘ１Ａ００−０ｘ１Ａ１Ｆ、０ｘ１２００−０ｘ１２１Ｆ、及び０ｘ１４００−０ｘ１４１Ｆの各範囲に属するとき、対応するＴＳパケットはそれぞれ、副映像デコーダ、主音声デコーダ、副音声デコーダ、ＰＧデコーダ、及びＩＧデコーダへ転送される。
第２ＰＩＤフィルタ5014は、第２ソース・デパケタイザ5012からＴＳパケットを受信する度に、そのＰＩＤを選択対象のＰＩＤと比較する。その選択対象のＰＩＤは再生制御部4907によって予め、３Ｄプレイリスト・ファイル内のＳＴＮテーブルＳＳに従って指定されている。具体的には、両方のＰＩＤが一致したとき、第２ＰＩＤフィルタ5014はそのＴＳパケットを、そのＰＩＤに割り当てられたデコーダへ転送する。例えば、ＰＩＤが０ｘ１０１２又は０ｘ１０１３であるとき、そのＴＳパケットは主映像デコーダ5015内のＴＢ（２）5008へ転送される。その他に、ＰＩＤが、０ｘ１Ｂ２０−０ｘ１Ｂ３Ｆ、０ｘ１２２０−０ｘ１２７Ｆ、及び０ｘ１４２０−０ｘ１４７Ｆの各範囲に属するとき、対応するＴＳパケットはそれぞれ、副映像デコーダ、ＰＧデコーダ、及びＩＧデコーダへ転送される。
主映像デコーダ5015は、ＴＢ（１）5001、ＭＢ（１）5002、ＥＢ（１）5003、ＴＢ（２）5008、ＭＢ（２）5009、ＥＢ（２）5010、バッファ・スイッチ5006、ＤＥＣ5004、ＤＰＢ5005、及びピクチャ・スイッチ5007を含む。ＴＢ（１）5001、ＭＢ（１）5002、ＥＢ（１）5003、ＴＢ（２）5008、ＭＢ（２）5009、ＥＢ（２）5010、及びＤＰＢ5005はいずれもバッファ・メモリである。各バッファ・メモリは、主映像デコーダ5015に内蔵されたメモリ素子の一領域を利用する。その他に、それらのバッファ・メモリのいずれか又は全てが、異なるメモリ素子に分離されていてもよい。
ＴＢ（１）5001は、ベースビュー・ビデオ・ストリームを含むＴＳパケットを第１ＰＩＤフィルタ5013から受信してそのまま蓄積する。ＭＢ（１）5002は、ＴＢ（１）5001に蓄積されたＴＳパケットからＰＥＳパケットを復元して蓄積する。そのとき、各ＴＳパケットからＴＳヘッダが除去される。ＥＢ（１）5003は、ＭＢ（１）5002に蓄積されたＰＥＳパケットから、符号化されたＶＡＵを抽出して蓄積する。そのとき、各ＰＥＳパケットからＰＥＳヘッダが除去される。
ＴＢ（２）5008は、ディペンデントビュー・ビデオ・ストリームを含むＴＳパケットを第２ＰＩＤフィルタ5014から受信してそのまま蓄積する。ＭＢ（２）5009は、ＴＢ（２）5008に蓄積されたＴＳパケットからＰＥＳパケットを復元して蓄積する。そのとき、各ＴＳパケットからＴＳヘッダが除去される。ＥＢ（２）5010は、ＭＢ（２）5009に蓄積されたＰＥＳパケットから、符号化されたＶＡＵを抽出して蓄積する。そのとき、各ＰＥＳパケットからＰＥＳヘッダが除去される。
バッファ・スイッチ5006は、ＥＢ（１）5003とＥＢ（２）5010とのそれぞれに蓄積されたＶＡＵを、元のＴＳパケットに含まれるＤＴＳの示す時刻にＤＥＣ5004へ転送する。ここで、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間では、同じ３Ｄ・ＶＡＵに属する一対のピクチャのＤＴＳが等しい。従って、バッファ・スイッチ5006は、ＥＢ（１）5003とＥＢ（２）5010とに蓄積された、ＤＴＳの等しい一対のＶＡＵのうち、ＥＢ（１）5003に蓄積された方を先にＤＥＣ5004へ転送する。その他に、バッファ・スイッチ5006は、図１３に示されているそのＶＡＵ内のデコードスイッチ情報をＤＥＣ5004から返信されてもよい。その場合、バッファ・スイッチ5006はその復号スイッチ情報1401を使って、次に転送すべきＶＡＵをＥＢ（１）5003とＥＢ（２）5010とのいずれから転送すべきか、決定できる。
ＤＥＣ5004は、バッファ・スイッチ5006から転送されたＶＡＵを復号する。ここで、そのＶＡＵ内に格納された圧縮ピクチャの符号化方式、例えば、ＭＰＥＧ−２、ＭＰＥＧ−４ ＡＶＣ、及びＶＣ１、並びにストリーム属性に応じて、ＤＥＣ5004は復号方法を切り換える。ＤＥＣ5004は更に、復号された非圧縮のピクチャ、すなわち映像フレーム又はフィールドをＤＰＢ5005へ転送する。
ＤＰＢ5005は、復号された非圧縮のピクチャを一時的に保持する。ＤＥＣ5004がＰピクチャ及びＢピクチャを復号するとき、ＤＰＢ5005はＤＥＣ5004からの要求に応じて、保持されている非圧縮のピクチャの中から参照ピクチャをＤＥＣ5004に提供する。
ピクチャ・スイッチ5007は、ＤＰＢ5005から非圧縮の各ピクチャを、元のＴＳパケットに含まれるＰＴＳの示す時刻に、左映像プレーン・メモリ5020と右映像プレーン・メモリ5021とのいずれかに書き込む。ここで、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間では、同じ３Ｄ・ＶＡＵに属する一対のピクチャのＰＴＳが等しい。従って、ピクチャ・スイッチ5007は、ＤＰＢ5005に保持された、ＰＴＳの等しい一対のピクチャのうち、ベースビュー・ビデオ・ストリームに属する方を先に左映像プレーン・メモリ5020に書き込み、続いて、ディペンデントビュー・ビデオ・ストリームに属するものを右映像プレーン・メモリ5021に書き込む。
≪プレーン加算部≫
図５９はプレーン加算部4910の機能ブロック図である。図５９を参照するに、プレーン加算部4910は、視差映像生成部5110、スイッチ5120、四つのクロッピング処理部5131−5134、及び四つの加算部5141−5144を含む。
視差映像生成部5110は、システム・ターゲット・デコーダ4903から左映像プレーン・データ5101と右映像プレーン・データ5102とを受信する。再生装置２００がＬ／Ｒモードであるとき、左映像プレーン・データ5101はレフトビュー・ビデオ・プレーンを表し、右映像プレーン・データ5102はライトビュー・ビデオ・プレーンを表す。そのとき、視差映像生成部5110は各ビデオ・プレーン・データ5101、5102をそのままスイッチ5120へ送出する。一方、再生装置２００がデプス・モードであるとき、左映像プレーン・データ5101は２Ｄ映像のビデオ・プレーンを表し、右映像プレーン・データ5102はその２Ｄ映像に対するデプスマップを表す。そのとき、視差映像生成部5110は、まずそのデプスマップからその２Ｄ映像の各部の両眼視差を計算する。視差映像生成部5110は次に、左映像プレーン・データ5101を加工して、ビデオ・プレーンにおけるその２Ｄ映像の各部の表示位置を、計算された両眼視差に応じて左右に移動させる。それにより、レフトビューとライトビューとを表すビデオ・プレーンの対が生成される。視差映像生成部5110は更に、そのビデオ・プレーンの対を左映像と右映像とのプレーン・データの対としてスイッチ5120へ送出する。
スイッチ5120は、再生制御部4907からＢ−Ｄ表示モードが指示されているとき、ＰＴＳの等しい左映像プレーン・データ5101と右映像プレーン・データ5102とをその順で第１加算部5141へ送出する。スイッチ5120は、再生制御部4907からＢ−Ｂ表示モードが指示されているとき、ＰＴＳの等しい左映像プレーン・データ5101と右映像プレーン・データ5102との一方をフレーム当たり二回ずつ、第１加算部5141へ送出し、他方を破棄する。
各クロッピング処理部5131−5134は、視差映像生成部5110とスイッチ5120との対と同様な構成を含む。２プレーン・モードではそれらの構成が利用される。特に再生装置２００がデプス・モードであるとき、システム・ターゲット・デコーダ4903からのプレーン・データはレフトビューとライトビューとのプレーン・データの対に変換される。再生制御部4907からＢ−Ｄ表示モードが指示されているとき、レフトビューとライトビューとのプレーン・データが交互に各加算部5141−5144へ送出される。一方、再生制御部4907からＢ−Ｂ表示モードが指示されているとき、レフトビューとライトビューとのプレーン・データの一方がフレーム当たり二回ずつ各加算部5141−5144へ送出され、他方は破棄される。
１プレーン＋オフセット・モードでは、第１クロッピング処理部5131は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用して副映像プレーン・データ5103に対してクロッピング処理を行う。それにより、その副映像プレーン・データ5103は、レフトビューとライトビューとを表す一対の副映像プレーン・データに変換されて交互に送出される。一方、１プレーン＋ゼロ・オフセット・モードではその副映像プレーン・データ5103が二回繰り返して送出される。
１プレーン＋オフセット・モードでは、第２クロッピング処理部5132は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用してＰＧプレーン・データ5104に対してクロッピング処理を行う。それにより、そのＰＧプレーン・データ5104は、レフトビューとライトビューとを表す一対のＰＧプレーン・データに変換されて交互に送出される。一方、１プレーン＋ゼロ・オフセット・モードではそのＰＧプレーン・データ5104が二回繰り返して送出される。
１プレーン＋オフセット・モードでは、第３クロッピング処理部5133は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用してＩＧプレーン・データ5105に対してクロッピング処理を行う。それにより、そのＩＧプレーン・データ5105は、レフトビューとライトビューとを表す一対のＩＧプレーン・データに変換されて交互に送出される。一方、１プレーン＋ゼロ・オフセット・モードではそのＩＧプレーン・データ5105が二回繰り返して送出される。
図６０の（ａ）、（ｂ）は、第２クロッピング処理部5132によるクロッピング処理を示す模式図である。図６０の（ａ）、（ｂ）ではそれぞれ、ＰＧプレーン・データ5104からレフトビューＰＧプレーン・データ5204LとライトビューＰＧプレーン・データ5204Rとの対が次のように生成される。第２クロッピング処理部5132はまず、オフセット値5151の中から、ＰＧプレーンに割り当てられたものを検索する。第２クロッピング処理部5132は次に、そのオフセット値に従って、ＰＧプレーン・データ5104の示すグラフィックス映像の表示位置に対するレフトビューとライトビューとの各表示位置を左又は右に変化させる。その結果、レフトビューとライトビューとのＰＧプレーン・データの対が得られる。尚、１プレーン＋ゼロ・オフセット・モードではオフセット値が“０”であるので、元のＰＧプレーン・データがそのまま維持される。第１クロッピング処理部5131は副映像プレーン・データ5103に対して同様にクロッピング処理を行い、第３クロッピング処理部5133はＩＧプレーン・データ5105に対して同様にクロッピング処理を行う。
図６０の（ａ）を参照するに、３Ｄ映像の奥行きが画面よりも手前であることをオフセット値の符号が示すとき、第２クロッピング処理部5132はまず、ＰＧプレーン・データ5104内の各画素データの位置を元の位置から、オフセット値に等しい画素数5201Lだけ右に変化させる。３Ｄ映像の奥行きが画面よりも奥であることをオフセット値の符号が示すときは、左に変化させる。第２クロッピング処理部5132は次に、ＰＧプレーン・データ5104の範囲から右（又は左）にはみ出ている画素データ群5202Lを除去する。こうして、残りの画素データ群5204LがレフトビューＰＧプレーン・データとして出力される。
図６０の（ｂ）を参照するに、３Ｄ映像の奥行きが画面よりも手前であることをオフセット値の符号が示すとき、第２クロッピング処理部5132はまず、ＰＧプレーン・データ5104内の各画素データの位置を元の位置から、オフセット値に等しい画素数5201Rだけ左に変化させる。３Ｄ映像の奥行きが画面よりも奥であることをオフセット方向が示すときは、右に変化させる。第２クロッピング処理部5132は次に、ＰＧプレーン・データ5104の範囲から左（又は右）にはみ出ている画素データ群5202Rを除去する。こうして、残りの画素データ群5204RがライトビューＰＧプレーン・データとして出力される。
図６１の（ａ）、（ｂ）、（ｃ）はそれぞれ、図６０に示されているクロッピング処理によって生成されたレフトビューとライトビューとのＰＧプレーン、及びそれらから視聴者に知覚される３Ｄ映像を示す模式図である。図６１の（ａ）を参照するに、レフトビューＰＧプレーン5301Lは画面5302の範囲からオフセット値5201Lだけ右に変位している。その結果、レフトビューＰＧプレーン5301L内の字幕の２Ｄ映像5303は、元の位置よりもオフセット値5201Lだけ右に変位して見える。図６１の（ｂ）を参照するに、ライトビューＰＧプレーン5301Rは逆に、画面5302の範囲からオフセット値5201Rだけ左に変位している。その結果、ライトビューＰＧプレーン5301R内の字幕の２Ｄ映像5303は、元の位置よりもオフセット値5201Rだけ左に変位して見える。それらのＰＧプレーン5301L、5301Rを画面5302に交互に表示するとき、図６１の（ｃ）に示されているように、視聴者5304には字幕の３Ｄ映像5305が画面5302よりも手前に見える。そのときの３Ｄ映像5305と画面5302との間の距離はオフセット値5201L、5201Rによって調節可能である。ＰＧプレーン・データ5104内の各画素データの位置を、図６０の（ａ）、（ｂ）に示されている方向とは逆に変化させたときは、視聴者5304には字幕の３Ｄ映像5305が画面5302よりも奥に見える。
このように、１プレーン＋オフセット・モードではクリッピング処理を利用して、一つのプレーン・データから、レフトビューとライトビューとのプレーン・データの対が生成される。それにより、一つのプレーン・データからでも、視差映像を表示することができる。すなわち、平面的なイメージに対して奥行き感を与えることができる。特に視聴者にその平面的なイメージを画面から浮かび上がるようにも、画面の奥に沈み込むようにも見せることができる。尚、１プレーン＋ゼロ・オフセット・モードではオフセット値が“０”であるので、平面的なイメージがそのまま維持される。
図５９を再び参照するに、イメージ・プレーン・データ5106は、プログラム実行部4906からシステム・ターゲット・デコーダ4903へ転送されたグラフィックス・データが、システム・ターゲット・デコーダ4903によって復号されたものである。そのグラフィックス・データはＪＰＥＧ又はＰＮＧ等のラスタデータであり、メニュー等のＧＵＩ用グラフィックス部品を表す。第４クロッピング処理部5134はイメージ・プレーン・データ5106に対するクロッピング処理を他のクロッピング処理部5131−5133と同様に行う。但し、第４クロッピング処理部5134は他のクロッピング処理部5131−5133とは異なり、オフセット値をシステム・ターゲット・デコーダ4903ではなく、プログラムＡＰＩ5152から受け取る。ここで、プログラムＡＰＩ5152はプログラム実行部4906によって実行される。それにより、グラフィックス・データの表すイメージの奥行きに相当するオフセット値が算出されて、第４クロッピング処理部5134に渡される。
第１加算部5141はまず、スイッチ5120からはビデオ・プレーン・データを受信し、第１クロッピング処理部5131からは副映像プレーン・データを受信する。第１加算部5141は次に、ビデオ・プレーン・データと副映像プレーン・データとを一組ずつ重畳して第２加算部5142に渡す。第２加算部5142は、第２クロッピング処理部5132からＰＧプレーン・データを受信し、第１加算部5141からのプレーン・データに重畳して第３加算部5143に渡す。第３加算部5143は、第３クロッピング処理部5133からＩＧプレーン・データを受信し、第２加算部5142からのプレーン・データに重畳して第４加算部5144に渡す。第４加算部5144は、第４クロッピング処理部5134からイメージ・プレーン・データを受信し、第３加算部5143からのプレーン・データに重畳してテレビ３００へ送出する。その結果、図５９に矢印5100で示されている順序で、左映像プレーン・データ5101又は右映像プレーン・データ5102、副映像プレーン・データ5103、ＰＧプレーン・データ5104、ＩＧプレーン・データ5105、及びイメージ・プレーン・データ5106は重畳される。それらの合成処理により、各プレーン・データの示す映像はテレビ３００の画面上に、左映像プレーン又は右映像プレーン、副映像プレーン、ＩＧプレーン、ＰＧプレーン、及びイメージ・プレーンの順に重ねられたように表示される。
プレーン加算部4910は上記の処理の他に、四つの加算部5141−5144によって合成されたプレーン・データの出力形式を、テレビ３００等、そのデータの出力先の装置による３Ｄ映像の表示方式に合わせて変換する。例えば出力先の装置が経時分離方式を利用するとき、プレーン加算部4910は合成後のプレーン・データを一つの映像フレーム又はフィールドとして送出する。一方、出力先の装置がレンチキュラーレンズを利用するとき、プレーン加算部4910は内蔵のバッファ・メモリを利用して、レフトビューとライトビューとのプレーン・データの対を一つの映像フレーム又はフィールドに合成して送出する。具体的には、プレーン加算部4910は、先に合成されたレフトビュー・プレーン・データを一旦、そのバッファ・メモリに格納して保持する。プレーン加算部4910は続いて、ライトビュー・プレーン・データを合成して、バッファ・メモリに保持されたレフトビュー・プレーン・データと更に合成する。その合成では、レフトビューとライトビューとの各プレーン・データが縦方向に細長い短冊形の小領域に分割され、各小領域が一つのフレーム又はフィールドの中に横方向に交互に並べられて一つのフレーム又はフィールドに再構成される。こうして、レフトビューとライトビューとのプレーン・データの対が一つの映像フレーム又はフィールドに合成される。プレーン加算部4910はその合成後の映像フレーム又はフィールドを出力先の装置へ送出する。
以上が再生装置についての説明である。

＜映像のシームレス再生のためにデータ・ブロックのサイズが満たすべき条件＞
本発明の実施形態による記録媒体１００では、図１５、４１に示されているとおり、ベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとが一つずつ交互に配置され、インターリーブ配置を形成している。更に、層境界等、ロングジャンプが必要な箇所では、図２０、２４、２６、２８、３０、３２に示されているとおり、ベースビュー・データ・ブロックとその複製データとが２Ｄ再生専用ブロックと３Ｄ再生専用ブロックとして配置されている。これらのデータ・ブロックの配置は上記の説明どおり、２Ｄ映像と３Ｄ映像とのいずれのシームレス再生にも有利である。それらのシームレス再生を更に確実に実現するには、各データ・ブロックのサイズは、再生装置２００の性能に基づく条件を満たせばよい。以下、それらの条件について説明する。
≪２Ｄ再生モードの性能に基づく条件≫
図６２は、２Ｄ再生モードの再生装置２００内の再生処理系統を示す模式図である。図６２を参照するに、その再生処理系統は、図５４に示されている要素のうち、ＢＤ−ＲＯＭドライブ4601、リード・バッファ4602、及びシステム・ターゲット・デコーダ4603を含む。ＢＤ−ＲＯＭドライブ4601は記録媒体１００から２Ｄエクステントを読み出し、読み出し速度Rud−2Dでリード・バッファ4602へ転送する。システム・ターゲット・デコーダ4603は、リード・バッファ4602内に蓄積された各２Ｄエクステントからソースパケットを平均転送速度Rext2Dで読み出し、映像データVDと音声データADとに復号する。
平均転送速度Rext2Dは、図４５に示されているソース・デパケタイザ3711からＰＩＤフィルタ3713へのＴＳパケットの平均転送速度RTSの１９２／１８８倍に等しく、一般に２Ｄエクステントごとに異なる。平均転送速度Rext2Dの最大値Rmax2Dは、ファイル２Ｄに対するシステムレートの１９２／１８８倍に等しい。ここで、そのシステムレートは、図３７に示されているように、２Ｄクリップ情報ファイルに規定されている。また、上記の係数１９２／１８８はソースパケットとＴＳパケットとの間のバイト数の比に等しい。平均転送速度Rext2Dは通常ビット／秒で表され、具体的には、ビット単位で表された２ＤエクステントのサイズをエクステントＡＴＣ時間で割ったときの値に等しい。「ビット単位で表されたエクステントのサイズ」は、そのエクステント内のソースパケット数とソースパケット一つ当たりのバイト数（＝１９２バイト）との積の８倍に等しい。
読み出し速度Rud−2Dは通常ビット／秒で表され、平均転送速度Rext2Dの最高値Rmax2Dよりも高い値、例えば５４Ｍｂｐｓに設定される：Rud−2D＞Rmax2D。それにより、ＢＤ−ＲＯＭドライブ4601が記録媒体１００から一つの２Ｄエクステントを読み出している間、システム・ターゲット・デコーダ4603の復号処理に伴うリード・バッファ4602のアンダーフローが防止される。
図６３の（ａ）は、２Ｄエクステントの再生処理中、リード・バッファ4602に蓄積されるデータ量DAの変化を示すグラフである。図６３の（ｂ）は、それらの２Ｄエクステントを含む３Ｄエクステント・ブロック5510と２Ｄ再生モードでの再生経路5520との間の対応関係を示す模式図である。図６３の（ｂ）を参照するに、３Ｄエクステント・ブロック5510は、インターリーブ配置のベースビュー・データ・ブロック群とディペンデントビュー・データ・ブロック群とで構成されている。再生経路5520に従い、各ベースビュー・データ・ブロックL0、L1、…が一つの２ＤエクステントEXT2D[0]、EXT2D[1]、…として、記録媒体１００からリード・バッファ4602へ読み出される。まず、先頭のベースビュー・データ・ブロックL0、すなわち２ＤエクステントEXT2D[0]の読み出し期間PR2D[0]では、図６３の（ａ）に示されているように、蓄積データ量DAは、読み出し速度Rud−2Dと平均転送速度Rext2D[0]との間の差Rud−2D−Rext2D[0]に等しい速度で増加する。
先頭の２ＤエクステントEXT2D[0]の後端が読み出された時に最初のジャンプJ2D[0]が生じる。そのジャンプ期間PJ2D[0]では、後続の二つのデータ・ブロックD1、R1の読み出しがスキップされるので、記録媒体１００からのデータの読み出しが停止する。従って、最初のジャンプ期間PJ2D[0]では、図６３の（ａ）に示されているように、蓄積データ量DAは平均転送速度Rext2D[0]で減少する。
ここで、次の場合を想定する：最初の読み出し期間PR2D[0]にリード・バッファ4602に蓄積されたデータ量、すなわち先頭の２ＤエクステントEXT2D[0]のサイズSext2D[0]が、その読み出し期間PR2D[0]から最初のジャンプ期間PJ2D[0]にわたってリード・バッファ4602からシステム・ターゲット・デコーダ4603へ転送されるデータ量に等しい。その場合、図６３の（ａ）に示されているように、蓄積データ量DAは最初のジャンプ期間PJ2D[0]の終了時、最初の読み出し期間PR2D[0]の開始時での値を下回らない。
最初のジャンプJ2D[0]に続いて次のベースビュー・データ・ブロックL1、すなわち２ＤエクステントEXT2D[1]の読み出しが開始される。その読み出し期間PR2D[1]では、図６３の（ａ）に示されているように、蓄積データ量DAは、データ転送速度の差Rud−2D−Rext2D[1]に等しい速度で再び増加する。
実際には、ＢＤ−ＲＯＭドライブ4601は読み出し／転送動作を、図６３の（ａ）に示されているように連続的にではなく断続的に行う。それにより、各２Ｄエクステントの読み出し期間PR2D[0]、PR2D[1]、…に蓄積データ量DAがリード・バッファ4602の容量を超えないように、すなわちリード・バッファ4602がオーバーフローを生じないようにする。従って、図６３の（ａ）のグラフは、実際には階段状である増減を直線的な増減として近似的に表したものである。
以上のように、２Ｄ再生モードでは再生経路5520に従い、２ＤエクステントLn＝EXT2D[n]（n＝0、1、2、…）の読み出しと、一対のディペンデントビュー・データ・ブロックDn、Rnの記録領域を越えるジャンプJ2D[n]とが交互に繰り返される。それに伴い、リード・バッファ4602の蓄積データ量DAは、読み出し期間PR2D[n]では速度Rud−2D−Rext2D[n]で増加し、ジャンプ期間PJ2D[n]では速度Rext2D[n]で減少する。従って、それらの２ＤエクステントEXT2D[n]から２Ｄ映像をシームレスに再生するには、以下の条件［１］、［２］が満たされればよい。
［１］各ジャンプ期間PJ2D[n]でリード・バッファ4602からシステム・ターゲット・デコーダ4603へのデータ供給を維持して、そのデコーダ4603の連続的な出力を確保する必要がある。図６３の（ａ）から明らかなとおり、各読み出し期間PR2D[n]にリード・バッファ4602に蓄積されるデータ量、すなわち各２ＤエクステントEXT2D[n]のサイズSext2D[n]が、その読み出し期間PR2D[n]から次のジャンプ期間PJ2D[n]にわたってリード・バッファ4602からシステム・ターゲット・デコーダ4603へ転送されるデータ量に等しければ、そのジャンプ期間PJ2D[n]の途中で蓄積データ量DAがその読み出し期間PR2D[n]の直前の値まで戻ることはない。特にリード・バッファ4602はアンダーフローを生じない。ここで、読み出し期間PR2D[n]の長さは、２ＤエクステントEXT2D[n]のサイズSext2D[n]を読み出し速度Rud−2Dで割った値Sext2D[n]／Rud−2Dに等しい。従って、各２ＤエクステントEXT2D[n]のサイズSext2D[n]は次式（１）を満たせばよい：
Figure 0004654327
 式（１）では、ジャンプ時間Tjump−2D[n]はジャンプ期間PJ2D[n]の長さであり、秒単位で表される。一方、読み出し速度Rud−2Dと平均転送速度Rext2Dとはいずれもビット／秒で表される。従って、式（１）では平均転送速度Rext2Dを数「８」で割り、２ＤエクステントのサイズSext2D[n]の単位をビットからバイトへ変換している。すなわち、２ＤエクステントのサイズSext2D[n]はバイト単位で表される。関数ＣＥＩＬ（）は、括弧内の数値の小数点以下の端数を切り上げる操作を意味する。
［２］リード・バッファ4602の容量は有限であることから、ジャンプ時間Tjump−2D[n]の最大値は制限される。すなわち、ジャンプ期間PJ2D[n]の直前に蓄積データ量DAがリード・バッファ4602の容量一杯であっても、ジャンプ時間Tjump−2D[n]が長すぎれば、ジャンプ期間PJ2D[n]中に蓄積データ量DAが０に達し、リード・バッファ4602のアンダーフローが生じる危険性がある。以下、記録媒体１００からリード・バッファ4602へのデータ供給が途絶えている状態で蓄積データ量DAがリード・バッファ4602の最大容量から０に到達するまでの時間、すなわち、シームレス再生を保証できるジャンプ時間Tjump−2Dの最大値を「最大ジャンプ時間」という。
光ディスクの規格では通常、ジャンプ距離と最大ジャンプ時間との間の関係が光ディスクドライブのアクセス・スピード等から決められている。図６４は、ＢＤ−ＲＯＭディスクに関するジャンプ距離Sjumpと最大ジャンプ時間Tjumpとの間の対応表の一例である。図６４では、ジャンプ距離Sjumpはセクタ単位で表され、最大ジャンプ時間Tjumpはｍ秒単位で表されている。ここで、１セクタ＝２０４８バイトとする。図６４を参照するに、ジャンプ距離Sjumpが、０セクタ、１−１００００セクタ、１０００１−２００００セクタ、２０００１−４００００セクタ、４０００１セクタ−１／１０ストローク、及び１／１０ストローク以上の各範囲に属するとき、最大ジャンプ時間Tjumpはそれぞれ、５０ｍ秒、２５０ｍ秒、３００ｍ秒、３５０ｍ秒、７００ｍ秒、及び１４００ｍ秒である。
ジャンプ距離Sjumpが０セクタに等しいときの最大ジャンプ時間を特に「ゼロ・セクタ遷移時間Tjump−0」という。「ゼロ・セクタ遷移」とは、二つの連続するデータ・ブロック間での光ピックアップの移動をいう。ゼロ・セクタ遷移期間では光ピックアップは読み出し動作を一旦停止して待機する。ゼロ・セクタ遷移時間は、記録媒体１００の回転による光ピックアップの位置の移動時間の他に、誤り訂正処理に伴うオーバーヘッドを含んでもよい。「誤り訂正処理に伴うオーバーヘッド」とは、二つの連続するデータ・ブロック間の境界がＥＣＣブロック間の境界と一致していないときに、そのＥＣＣブロックを用いた誤り訂正処理が二回行われることに起因する余分な時間をいう。誤り訂正処理には一つのＥＣＣブロックの全体が必要である。従って、一つのＥＣＣブロックが二つの連続するデータ・ブロックに共有されているとき、いずれのデータ・ブロックの読み出し処理でもそのＥＣＣブロックの全体が読み出されて誤り訂正処理に利用される。その結果、それらのデータ・ブロックを一つ読み出すごとに、そのデータ・ブロックの他に最大３２セクタの余分なデータが読み出される。誤り訂正処理に伴うオーバーヘッドは、その余分なデータの読み出し時間の合計、すなわち３２［セクタ］×２０４８［バイト］×８［ビット／バイト］×２［回］／読み出し速度Rud−2Dで評価される。尚、各データ・ブロックをＥＣＣブロック単位で構成することにより、誤り訂正処理に伴うオーバーヘッドをゼロ・セクタ遷移時間から除外してもよい。
記録媒体１００が多層ディスクであるとき、層切り換えを伴うロングジャンプでは、図６４に規定された最大ジャンプ時間Tjumpに加えて、フォーカス・ジャンプ等、その記録層の切り換え操作に特定の時間、例えば３５０ｍ秒が更に必要である。以下、この時間を「層切換時間」という。
以上のことから、式（１）に代入されるべきジャンプ時間Tjump−2D[n]は二つのパラメータTJ[n]、TL[n]の和で決まる：Tjump−2D[n]＝TJ[n]＋TL[n]。第１パラメータTJ[n]は、ＢＤ−ＲＯＭディスクの規格によってジャンプ距離別に規定された最大ジャンプ時間を表す。第１パラメータTJ[n]は例えば図６４の表において、ｎ番目の２ＤエクステントEXT2D[n]の後端から（ｎ＋１）番目の２ＤエクステントEXT2D[n＋1]の先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。第２パラメータTL[n]は、ｎ番目の２ＤエクステントEXT2D[n]と（ｎ＋１）番目の２ＤエクステントEXT2D[n＋1]との間に層境界LBがあるときは層切換時間、例えば３５０ｍ秒を表し、層境界LBがないときは０を表す。例えばジャンプ時間Tjump−2D[n]の最大値が７００ｍ秒に制限されるとき、二つの２ＤエクステントEXT2D[n]、EXT2D[n＋1]間のジャンプ距離は、それらの２Ｄエクステント間に層境界がないときは１／１０ストローク（＝約１．２ＧＢ）まで許され、層境界があるときは４００００セクタ（＝約７８．１ＭＢ）まで許される。
≪３Ｄ再生モードに基づく条件≫
図６５は、３Ｄ再生モードの再生装置２００内の再生処理系統を示す模式図である。図６５を参照するに、その再生処理系統は、図５７に示されている要素のうち、ＢＤ−ＲＯＭドライブ4901、スイッチ4911、第１リード・バッファ4921、第２リード・バッファ4922、及びシステム・ターゲット・デコーダ4903を含む。ＢＤ−ＲＯＭドライブ4901は記録媒体１００から３Ｄエクステントを読み出し、読み出し速度Rud−3Dでスイッチ4911へ転送する。スイッチ4911は各３Ｄエクステントからベースビュー・エクステントを抽出して、ディペンデントビュー・エクステントと分離する。ベースビュー・エクステントは第１リード・バッファ4921へ格納され、ディペンデントビュー・エクステントは第２リード・バッファ4922へ格納される。第２リード・バッファ4922内の蓄積データは、Ｌ／Ｒモードではライトビュー・エクステントであり、デプス・モードではデプスマップ・エクステントである。システム・ターゲット・デコーダ4903は、第１リード・バッファ4921内に蓄積された各ベースビュー・エクステントからソースパケットを第１平均転送速度Rext1で読み出す。Ｌ／Ｒモードのシステム・ターゲット・デコーダ4903は、第２リード・バッファ4922内に蓄積された各ライトビュー・エクステントからソースパケットを第２平均転送速度Rext2で読み出す。デプス・モードのシステム・ターゲット・デコーダ4903は、第２リード・バッファ4922内に蓄積された各デプスマップ・エクステントからソースパケットを第３平均転送速度Rext3で読み出す。システム・ターゲット・デコーダ4903は更に、読み出されたベースビュー・エクステントとディペンデントビュー・エクステントとの対を映像データVDと音声データADとに復号する。
第１平均転送速度Rext1を「ベースビュー転送速度」という。ベースビュー転送速度Rext1は、図５８に示されている第１ソース・デパケタイザ5011から第１ＰＩＤフィルタ5013へのＴＳパケットの平均転送速度RTS1の１９２／１８８倍に等しく、一般にベースビュー・エクステントごとに異なる。ベースビュー転送速度Rext1の最高値Rmax1はファイル２Ｄに対するシステムレートの１９２／１８８倍に等しい。そのシステムレートは２Ｄクリップ情報ファイルに規定されている。ベースビュー転送速度Rext1は通常ビット／秒で表され、具体的には、ビット単位で表されたベースビュー・エクステントのサイズをエクステントＡＴＣ時間で割ったときの値に等しい。エクステントＡＴＣ時間は、そのベースビュー・エクステント内のソースパケットに付与されたＡＴＳの範囲を表す。従って、エクステントＡＴＣ時間は、そのベースビュー・エクステント内のソースパケットを全て、第１リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送するのに要する時間に等しい。
第２平均転送速度Rext2を「ライトビュー転送速度」といい、第３平均転送速度Rext3を「デプスマップ転送速度」という。いずれの転送速度Rext2、Rext3も、第２ソース・デパケタイザ5012から第２ＰＩＤフィルタ5014へのＴＳパケットの平均転送速度RTS2の１９２／１８８倍に等しく、一般にディペンデントビュー・エクステントごとに異なる。ライトビュー転送速度Rext2の最高値Rmax2はライトビュービデオストリームを含むファイルＤＥＰに対するシステムレートの１９２／１８８倍と等しく、デプスマップ転送速度Rext3の最高値Rmax3はデプスマップストリームを含むファイルＤＥＰに対するシステムレートの１９２／１８８倍に等しい。各システムレートはライトビュー・クリップ情報ファイルとデプスマップ・クリップ情報ファイルとに規定されている。各転送速度Rext2、Rext3は通常ビット／秒で表され、具体的には、ビット単位で表されたディペンデントビュー・エクステントのサイズをエクステントＡＴＣ時間で割ったときの値に等しい。エクステントＡＴＣ時間は、各ディペンデントビュー・エクステント内のソースパケットに付与されたＡＴＳの範囲を表す。従って、エクステントＡＴＣ時間は、そのディペンデントビュー・エクステント内のソースパケットを全て、第２リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送するのに要する時間に等しい。
読み出し速度Rud−3Dは通常ビット／秒で表され、第１−３平均転送速度Rext1−Rext3のいずれの最高値Rmax1−Rmax3よりも高い値、例えば７２Ｍｂｐｓに設定される：Rud−3D＞Rmax1、Rud−3D＞Rmax2、Rud−3D＞Rmax3。それにより、ＢＤ−ＲＯＭドライブ4901によって記録媒体１００から一つの３Ｄエクステントを読み出している間、システム・ターゲット・デコーダ4903の復号処理に伴う各リード・バッファ4921、4922のアンダーフローが防止される。
［Ｌ／Ｒモード］
図６６の（ａ）、（ｂ）は、Ｌ／Ｒモードでの３Ｄエクステント・ブロックの再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフである。図６６の（ｃ）は、その３Ｄエクステント・ブロック5810とＬ／Ｒモードでの再生経路5820との間の対応関係を示す模式図である。図６６の（ｃ）を参照するに、３Ｄエクステント・ブロック5810は、インターリーブ配置のベースビュー・データ・ブロック群とディペンデントビュー・データ・ブロック群とで構成されている。再生経路5820に従い、隣接するライトビュー・データ・ブロックRkとベースビュー・データ・ブロックLkとの各対（k＝0、1、2、…）が一つの３ＤエクステントEXTSS[k]として読み出される。ここでは説明の便宜上、（ｎ−１）個の３Ｄエクステントが既に読み出され、かつ整数ｎが１より十分に大きい場合を想定する。その場合、両リード・バッファ4921、4922の蓄積データ量DA1、DA2は既にそれぞれの下限値UL1、UL2以上に維持されている。それらの下限値UL1、UL2を「バッファ余裕量」という。バッファ余裕量UL1、UL2を確保するための方法については後述する。
図６６の（ｃ）を参照するに、第（２ｎ−１）読み出し期間PRR[n]にｎ番目のライトビュー・エクステントRnが記録媒体１００から第２リード・バッファ4922へ読み出される。第（２ｎ−１）読み出し期間PRR[n]では、図６６の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとライトビュー転送速度Rext2[n]との間の差Rud−3D−Rext2[n]に等しい速度で増加する。一方、図６６の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少する。
ｎ番目のライトビュー・エクステントRnの後端が読み出された時、ｎ回目のゼロ・セクタ遷移J0[n]が生じる。第ｎゼロ・セクタ遷移期間PJ0[n]では、記録媒体１００からのデータの読み出しが停止する。従って、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少し続け、第２リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少する。
第ｎゼロ・セクタ遷移期間PJ0[n]の終了時点から、第２ｎ読み出し期間PRL[n]が開始される。第２ｎ読み出し期間PRL[n]ではｎ番目のベースビュー・エクステントLnが記録媒体１００から第１リード・バッファ4921へ読み出される。従って、図６６の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1は、読み出し速度Rud−3Dとベースビュー転送速度Rext1[n]との間の差Rud−3D−Rext1[n]に等しい速度で増加する。一方、図６６の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少し続ける。
ｎ番目のベースビュー・エクステントLnの後端が読み出された時、ｎ番目のジャンプJLR[n]が生じる。第ｎジャンプ期間PJLR[n]では（ｎ＋１）番目のデプスマップ・エクステントD(n＋1)の読み出しがスキップされるので、記録媒体１００からのデータの読み出しが停止する。従って、第ｎジャンプ期間PJLR[n]では、図６６の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少する。一方、図６６の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少し続ける。
ここで、次の場合を想定する：第（２ｎ−１）読み出し期間PRR[n]に第２リード・バッファ4922に蓄積されるデータ量、すなわちｎ番目のライトビュー・エクステントRnのサイズSext2[n]は少なくとも、第（２ｎ−１）読み出し期間PRR[n]から第ｎジャンプ期間PJLR[n]にわたって第２リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、ジャンプ期間PJLR[n]の終了時、図６６の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2が第２バッファ余裕量UL2を下回らない。
第ｎジャンプ期間PJLR[n]の終了時点から第（２ｎ＋１）読み出し期間PRR[n＋1]が開始される。第（２ｎ＋１）読み出し期間PRR[n＋1]では、（ｎ＋１）番目のライトビュー・エクステントR(n＋1)が記録媒体１００から第２リード・バッファ4922へ読み出される。従って、図６６の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとライトビュー転送速度Rext2[n＋1]との間の差Rud−3D−Rext2[n＋1]に等しい速度で増加する。一方、図６６の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続ける。
（ｎ＋１）番目のライトビュー・エクステントR(n＋1)の後端が読み出された時、（ｎ＋１）回目のゼロ・セクタ遷移J0[n＋1]が生じる。第（ｎ＋１）ゼロ・セクタ遷移期間PJ0[n＋1]では記録媒体１００からのデータの読み出しが停止する。従って、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続け、第２リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n＋1]で減少する。
ここで、次の場合を想定する：第２ｎ読み出し期間PRL[n]に第１リード・バッファ4921に蓄積されるデータ量、すなわちｎ番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第２ｎ読み出し期間PRL[n]から第（ｎ＋１）ゼロ・セクタ遷移期間PJ0[n＋1]にわたって第１リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第（ｎ＋１）ゼロ・セクタ遷移期間PJ0[n＋1]の終了時、図６６の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1が第１バッファ余裕量UL1を下回らない。
３ＤエクステントEXTSS[n]＝Rn＋Ln、EXTSS[n＋1]＝R(n＋1)＋L(n＋1)、…から、それらの間のジャンプにかかわらず、３Ｄ映像をシームレスに再生するには、上記と同様な蓄積データ量DA1、DA2の変化が繰り返されればよい。それには、以下の条件［３］、［４］、［５］が満たされればよい。
［３］ｎ番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第２ｎ読み出し期間PRL[n]から第（ｎ＋１）ゼロ・セクタ遷移期間PJ0[n＋1]にわたって第１リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第２ｎ読み出し期間PRL[n]の長さは、ｎ番目のベースビュー・エクステントLnのサイズSext1[n]を読み出し速度Rud−3Dで割った値Sext1[n]／Rud−3Dに等しい。第（２ｎ＋１）読み出し期間PRR[n＋1]の長さは、（ｎ＋１）番目のライトビュー・エクステントR(n＋1)のサイズSext2[n＋1]を読み出し速度Rud−3Dで割った値Sext2[n＋1]／Rud−3Dに等しい。従って、ｎ番目のベースビュー・エクステントLnのサイズSext1[n]は次式（２）を満たせばよい：
Figure 0004654327
 ［４］ｎ番目のライトビュー・エクステントRnのサイズSext2[n]は少なくとも、第（２ｎ−１）読み出し期間PRR[n]から第ｎジャンプ期間PJLR[n]にわたって第２リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第（２ｎ−１）読み出し期間PRR[n]の長さは、ｎ番目のライトビュー・エクステントRnのサイズSext2[n]を読み出し速度Rud−3Dで割った値Sext2[n]／Rud−3Dに等しい。従って、ｎ番目のライトビュー・エクステントRnのサイズSext2[n]は次式（３）を満たせばよい：
Figure 0004654327
 ［５］式（２）、（３）に代入されるべきジャンプ時間Tjump−3D[n]は、式（１）に代入されるべきジャンプ時間Tjump−2D[n]とは異なり、第１パラメータTJ[n]だけで決まる：Tjump−3D[n]＝TJ[n]。第１パラメータTJ[n]は例えば図６４の表において、ｎ番目のベースビュー・エクステントLnの後端から（ｎ＋１）番目のライトビュー・エクステントR(n＋1)の先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。
［デプス・モード］
図６７の（ａ）、（ｂ）は、デプス・モードでの３Ｄエクステント・ブロック再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフである。図６７の（ｃ）は、その３Ｄエクステント・ブロック5910とデプス・モードでの再生経路5920との間の対応関係を示す模式図である。図６７の（ｃ）を参照するに、３Ｄエクステント・ブロック5910は、図６６の（ｃ）に示されている３Ｄエクステント・ブロック5810と同様なインターリーブ配置のデータ・ブロック群で構成されている。再生経路5920に従い、デプスマップ・データ・ブロックDkとベースビュー・データ・ブロックDkとがそれぞれ、一つのエクステントとして読み出される（k＝0、1、2、…）。図６６の場合と同様、（ｎ−１）個の３Ｄエクステントが既に読み込まれ、かつ整数ｎが１より十分に大きい場合を想定する。その場合、両リード・バッファ4921、4922の蓄積データ量DA1、DA2は既にそれぞれのバッファ余裕量UL1、UL2以上に維持されている。
図６７の（ｃ）を参照するに、第（２ｎ−１）読み出し期間PRD[n]にｎ番目のデプスマップ・エクステントDnが記録媒体１００から第２リード・バッファ4922へ読み出される。第（２ｎ−１）読み出し期間PRD[n]では、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとデプスマップ転送速度Rext3[n]との間の差Rud−3D−Rext3[n]に等しい速度で増加する。一方、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少する。
ｎ番目のデプスマップ・エクステントDnの後端が読み出された時、ｎ回目のジャンプJLD[n]が生じる。第ｎジャンプ期間PJLD[n]では、ｎ番目のライトビュー・エクステントRnの読み出しがスキップされるので、記録媒体１００からのデータの読み出しが停止する。従って、第ｎジャンプ期間PJLD[n]では、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少し続ける。一方、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少する。
第ｎジャンプ期間PJLD[n]の終了時点から第２ｎ読み出し期間PRL[n]が開始される。第２ｎ読み出し期間PRL[n]では、ｎ番目のベースビュー・エクステントLnが記録媒体１００から第１リード・バッファ4921へ読み出される。従って、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1は、読み出し速度Rud−3Dとベースビュー転送速度Rext1[n]との間の差Rud−3D−Rext1[n]に等しい速度で増加する。一方、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少し続ける。
ｎ番目のベースビュー・エクステントLnの後端が読み出された時、ｎ回目のゼロ・セクタ遷移J0[n]が生じる。第ｎゼロ・セクタ遷移期間PJ0[n]では、記録媒体１００からのデータの読み出しが停止する。従って、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し、第２リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少し続ける。
ここで、次の場合を想定する：第（２ｎ−１）読み出し期間PRD[n]に第２リード・バッファ4922に蓄積されるデータ量、すなわちｎ番目のデプスマップ・エクステントDnのサイズSext3[n]は少なくとも、第（２ｎ−１）読み出し期間PRD[n]から第ｎゼロ・セクタ遷移期間PJ0[n]にわたって第２リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第ｎゼロ・セクタ遷移期間PJ0[n]の終了時、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2が第２バッファ余裕量UL2を下回らない。
第ｎゼロ・セクタ遷移期間PJ0[n]の終了時点から第（２ｎ＋１）読み出し期間PRD[n＋1]が開始される。第（２ｎ＋１）読み出し期間PRD[n＋1]では（ｎ＋１）番目のデプスマップ・エクステントD(n＋1)が記録媒体１００から第２リード・バッファ4922へ読み出される。従って、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続ける。一方、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2は速度Rud−3D−Rext3[n＋1]で増加する。
（ｎ＋１）番目のデプスマップ・エクステントD(n＋1)の後端が読み出された時、（ｎ＋１）回目のジャンプJLD[n＋1]が生じる。第（ｎ＋１）ジャンプ期間PJLD[n＋1]では、（ｎ＋１）番目のライトビュー・エクステントR(n＋1)の読み出しがスキップされるので、記録媒体１００からのデータの読み出しが停止する。従って、第（ｎ＋１）ジャンプ期間PJLD[n＋1]では、第１リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続け、第２リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n＋1]で減少する。
第（ｎ＋１）ジャンプ期間PJLD[n＋1]の終了時点から第（２ｎ＋２）読み出し期間PRL[n＋1]が開始される。第（２ｎ＋２）読み出し期間PRL[n＋1]では、（ｎ＋１）番目のベースビュー・エクステントL(n＋1)が記録媒体１００から第１リード・バッファ4921へ読み出される。従って、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1は速度Rud−3D−Rext1[n＋1]で増加する。一方、図６７の（ｂ）に示されているように、第２リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n＋1]で減少し続ける。
ここで、次の場合を想定する：第２ｎ読み出し期間PRL[n]に第１リード・バッファ4921に蓄積されるデータ量、すなわちｎ番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第２ｎ読み出し期間PRL[n]から第（ｎ＋１）ジャンプ期間PJLD[n＋1]にわたって第１リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第（ｎ＋１）ジャンプ期間PJLD[n＋1]の終了時、図６７の（ａ）に示されているように、第１リード・バッファ4921の蓄積データ量DA1が第１バッファ余裕量UL1を下回らない。
デプスマップ・エクステントDn、D(n＋1)、…とベースビュー・エクステントLn、L(n＋1)、…とから、それらの間のジャンプにかかわらず、３Ｄ映像をシームレスに再生するには、上記と同様な蓄積データ量DA1、DA2の変化が繰り返されればよい。それには、以下の条件［６］、［７］、［８］が満たされればよい。
［６］ｎ番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第２ｎ読み出し期間PRL[n]から第（ｎ＋１）ジャンプ期間PJLD[n＋1]にわたって第１リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第２ｎ読み出し期間PRL[n]の長さは、ｎ番目のベースビュー・エクステントLnのサイズSext1[n]を読み出し速度Rud−3Dで割った値Sext1[n]／Rud−3Dに等しい。第（２ｎ＋１）読み出し期間PRD[n＋1]の長さは、（ｎ＋１）番目のデプスマップ・エクステントD(n＋1)のサイズSext3[n＋1]を読み出し速度Rud−3Dで割った値Sext3[n＋1]／Rud−3Dに等しい。従って、ｎ番目のベースビュー・エクステントLnのサイズSext1[n]は次式（４）を満たせばよい：
Figure 0004654327
 ［７］ｎ番目のデプスマップ・エクステントDnのサイズSext3[n]は少なくとも、第（２ｎ−１）読み出し期間PRD[n]から第ｎゼロ・セクタ遷移期間PJ0[n]にわたって第２リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第（２ｎ−１）読み出し期間PRD[n]の長さは、ｎ番目のデプスマップ・エクステントDnのサイズSext3[n]を読み出し速度Rud−3Dで割った値Sext3[n]／Rud−3Dに等しい。従って、ｎ番目のデプスマップ・エクステントDnのサイズSext3[n]は次式（５）を満たせばよい：
Figure 0004654327
 ［８］式（４）、（５）に代入されるべきジャンプ時間Tjump−3D[n]は、例えば図６４の表において、ｎ番目のデプスマップ・エクステントDnの後端からｎ番目のベースビュー・エクステントLnの先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。尚、本発明の実施形態によるデータ・ブロック群の配置では、エクステントＡＴＣ時間の等しいデプスマップ・エクステントDnとベースビュー・エクステントLnとの対が間に層境界を挟んで配置されることはない。
ゼロ・セクタ遷移時間Tjump−0[n]は、ｎ番目のベースビュー・エクステントLnと（ｎ＋１）番目のデプスマップ・エクステントD(n＋1)との間における層境界LBの有無に関わらず、実際のゼロ・セクタ遷移に要する時間のみで評価された規定値に等しい。
以上の結果、インターリーブ配置のデータ・ブロック群から、２Ｄ映像のシームレス再生、３Ｄ映像のＬ／Ｒモードでのシームレス再生、及び３Ｄ映像のデプス・モードでのシームレス再生のいずれも実現可能にするには、各データ・ブロックのサイズは上記の式（１）−（５）を全て満たすように設計されればよい。特にベースビュー・データ・ブロックのサイズは、式（１）、（２）、及び（４）の各右辺の中で最大のもの以上であればよい。以下、式（１）−（５）を全て満たすデータ・ブロックのサイズの下限値を「最小エクステント・サイズ」という。

＜リード・バッファの余裕量＞
図６６、６７の各（ａ）、（ｂ）に示されている各リード・バッファ4921、4922の蓄積データ量DA1、DA2の下限値UL1、UL2はそれぞれのバッファ余裕量を表す。「バッファ余裕量」とは、一つの３Ｄエクステント・ブロック、すなわちインターリーブ配置の一連のデータ・ブロック群の読み出し期間中、各リード・バッファに維持されるべき蓄積データ量の下限値をいう。ストリーム・データの読み出し中に、読み出し対象の記録層が切り換えられるとき、又は他のファイルの読み出し処理が割り込まれたとき、異なる３Ｄエクステント・ブロック間でロングジャンプが生じる。ここで、上記の他のファイルは、ＡＶストリーム・ファイル以外のファイル、例えば、ムービーオブジェクト・ファイル、ＢＤ−Ｊオブジェクト・ファイル、及びＪＡＲファイルを含む。ロングジャンプは、式（２）−（５）の導出で考慮された一つの３Ｄエクステント・ブロック内で生じるジャンプよりも長い。更に、他のファイルの読み出し処理の割り込みに起因するロングジャンプでは、その発生時期が不定であり、特に一つのデータ・ブロックの読み出し途中でも生じ得る。従って、式（２）−（５）にロングジャンプの最大ジャンプ時間を代入して最小エクステント・サイズを設定するよりも、バッファ余裕量を、ロングジャンプ中での各リード・バッファのアンダーフローを防ぐことのできる量に維持しておく方が有利である。
図６８は、Ｌ／Ｒモードでの再生処理中に生じるロングジャンプJLY、JBDJ1、JBDJ2を示す模式図である。図６８を参照するに、層境界LBの前に位置する第１記録層には、第１の３Ｄエクステント・ブロック6001が配置され、その後端L3と層境界LBとの間には２Ｄ再生専用ブロックL42Dが配置されている。一方、層境界LBの後に位置する第２記録層には第２の３Ｄエクステント・ブロック6002が配置されている。更に、いずれの３Ｄエクステント・ブロック6001、6002からも離れた領域にＢＤ−Ｊオブジェクト・ファイル6003が記録されている。第１の３Ｄエクステント・ブロック6001から第２の３Ｄエクステント・ブロック6002への再生処理では、層切り換えに伴うロングジャンプJLYが生じる。一方、第１の３Ｄエクステント・ブロック6001の読み出し中にＢＤ−Ｊオブジェクト・ファイル6003の読み出し処理が割り込まれたとき、一対のロングジャンプJBDJ1、JBDJ2が生じる。各ロングジャンプJLY、JBDJに対して必要なバッファ余裕量UL1、UL2は以下のように計算される。
層切り換えに伴うロングジャンプJLYの最大ジャンプ時間Tjump−LYは、図６４の表において第１ロングジャンプJLYのジャンプ距離に対応する最大ジャンプ時間と層切換時間との和に等しい。そのジャンプ距離は、第１の３Ｄエクステント・ブロック6001内の最後のベースビュー・データ・ブロックL3の後端と、第２の３Ｄエクステント・ブロック6002内の先頭のライトビュー・データ・ブロックR4の先端との間のセクタ数に等しい。一方、ベースビュー転送速度Rext1は最高値Rmax1を超えない。従って、そのロングジャンプJLYの期間に第１リード・バッファ4921から消費されるデータ量は、ベースビュー転送速度の最高値Rmax1と最大ジャンプ時間Tjump−LYとの積を超えない。その積の値が第１バッファ余裕量UL1として決定される。すなわち、第１バッファ余裕量UL1は次式（６）で計算される：
Figure 0004654327
 例えばジャンプ距離が４００００セクタであるとき、図６４の表によれば、最大ジャンプ時間Tjump−LYは、層切換時間３５０ｍ秒を含めて７００ｍ秒である。従って、ファイル２Ｄに対するシステムレートが４８Ｍｂｐｓであるとき、第１バッファ余裕量UL1は（４８Ｍｂｐｓ×１９２／１８８）×０．７秒＝約４．０９ＭＢに等しい。
同様に、ロングジャンプJLYの期間に第２リード・バッファ4922から消費されるデータ量の最大値、すなわちライトビュー転送速度の最大値Rmax2と最大ジャンプ時間Tjump−LYとの積が第２バッファ余裕量UL2として決定される。すなわち、第２バッファ余裕量UL2は次式（７）で計算される：
Figure 0004654327
 例えばジャンプ距離が４００００セクタであり、すなわち最大ジャンプ時間Tjump−LYが７００ｍ秒であり、第１ファイルＤＥＰに対するシステムレートが１６Ｍｂｐｓであるとき、第２バッファ余裕量UL2は（１６Ｍｂｐｓ×１９２／１８８）×０．７秒＝約１．３６ＭＢに等しい。
図６８を再び参照するに、第１の３Ｄエクステント・ブロック6001の読み出し期間にＢＤ−Ｊオブジェクト・ファイル6003の読み出し処理の割り込みが生じたとき、最初のロングジャンプJBDJ1が生じる。それにより、読み出し対象の位置が第２ベースビュー・データ・ブロックL2の記録領域からＢＤ−Ｊオブジェクト・ファイル6003の記録領域へ移動する。そのジャンプ時間TBDJは一定値、例えば９００ｍ秒に予め規定されている。次に、ＢＤ−Ｊオブジェクト・ファイル6003が読み出される。その読み出しに要する時間は、そのファイル6003に属するエクステントのサイズSBDJの８倍を読み出し速度Rud−3Dで割った値８×SBDJ[n]／Rud−3Dに等しい（通常、エクステントのサイズSBDJはバイト単位で表され、読み出し速度Rud−3Dはビット／秒で表されるので、８倍が必要である）。続いて、２回目のロングジャンプJBDJ2が生じる。それにより、読み出し対象の位置がＢＤ−Ｊオブジェクト・ファイル6003の記録領域から第２ベースビュー・データ・ブロックL2の記録領域へ戻る。そのジャンプ時間TBDJは最初のジャンプ時間、例えば９００ｍ秒に等しい。計２回のロングジャンプJBDJ1、JBDJ2とＢＤ−Ｊオブジェクト・ファイル6003の読み出しとが行われる間、第１リード・バッファ4921にはデータが読み込まれない。従って、その期間に第１リード・バッファ4921から消費されるデータ量の最大値が第１バッファ余裕量UL1として決定される。すなわち、第１バッファ余裕量UL1は次式（８）で計算される：
Figure 0004654327
 同様に、２回のロングジャンプJBDJ1、JBDJ2とＢＤ−Ｊオブジェクト・ファイル6003の読み出しとが行われる間に第２リード・バッファ4922から消費されるデータ量の最大値が第２バッファ余裕量UL2として決定される。すなわち、第２バッファ余裕量UL2は次式（９）で計算される：
Figure 0004654327
 第１バッファ余裕量UL1は、式（６）、（８）の右辺で表される値のいずれか大きい方に設定される。第２バッファ余裕量UL2は、式（７）、（９）の右辺で表される値のいずれか大きい方に設定される。
＜リード・バッファの最小容量＞
図６６、６７の各（ｃ）に示されている一連の３Ｄエクステント・ブロックからの再生処理については、各リード・バッファ4921、4922に必要な容量の最小値は以下のように計算される。
３Ｄ再生モードでｎ番目のベースビュー・データ・ブロックLn（n＝0、1、2、…）を読み出すとき、第１リード・バッファ4921に必要な容量RB1[n]は、図６６、６７の各（ａ）に示されているグラフのピークのうち、最も高い値以上であればよい。ここで、読み出し対象のベースビュー・データ・ブロックのサイズSext1が一定であれば、ベースビュー転送速度Rext1が最高値Rmax1に等しいときにピーク値は最も高い。従って、その容量RB1[n]は、Ｌ／Ｒモードとデプス・モードとのいずれでも、次式（１０）を満たせばよい：
Figure 0004654327
 Ｌ／Ｒモードでｎ番目のライトビュー・データ・ブロックRnを読み出すとき、第２リード・バッファ4922に必要な容量RB2LR[n]は、図６６の（ｂ）に示されているグラフのピークのうち、最も高い値以上であればよい。ここで、読み出し対象のライトビュー・データ・ブロックのサイズSext2が一定であれば、ライトビュー転送速度Rext2が最高値Rmax2に等しいときにピーク値は最も高い。従って、その容量RB2LR[n]は次式（１１）を満たせばよい：
Figure 0004654327
 ここで、ライトビュー・データ・ブロックはいずれも、飛び込み再生によって最初に読み出される可能性を持つ。その場合、最初に読み出されるライトビュー・データ・ブロックの全体が第２リード・バッファ4922に格納されるまでシステム・ターゲット・デコーダ4903は第２リード・バッファ4922からデータを読み出さない。従って、第２リード・バッファ4922の容量RB2LR[n]は第１リード・バッファ4921の容量RB1[n]とは異なり、「少なくともｎ番目のライトビュー・データ・ブロックRnのサイズSext2[n]よりも大きい」という条件を更に満たす。
同様に、デプス・モードでｎ番目のデプスマップ・データ・ブロックDnを読み出すときに必要な第２リード・バッファ4922の容量RB2LD[n]は次式（１２）を満たせばよい：
Figure 0004654327
 ＜層境界前後での再生経路の分離の効果＞
本発明の実施形態による記録媒体１００では、層境界の前後のデータ・ブロック群が、図２０、２４、２６、２８、３０、３２のそれぞれに示されている配置１−６のいずれかで記録されている。それにより、層切り換えの前後ではベースビュー・ビデオ・ストリームの特定部分が、２Ｄ再生モードでは２Ｄ再生専用ブロックLn2Dから再生され、３Ｄ再生モードでは３Ｄ再生専用ブロックLnSSから再生される。その場合、図２２に示されている配置とは異なり、その特定部分を格納した２ＤエクステントのサイズSext2Dは、ベースビュー・エクステントのサイズSext1と２Ｄ再生専用ブロックLn2Dのサイズとの和に等しい。式（１）はその和Sext2Dによって満たされればよい一方、式（２）−（５）は２Ｄ再生専用ブロックLn2D以外のデータ・ブロックのサイズによって満たされればよい。従って、２Ｄ再生専用ブロックLn2Dのサイズの調節によって、２Ｄエクステントの全体のサイズSext2Dが式（１）を満たすこととは実質上独立に、式（２）−（５）を満たすディペンデントビュー・エクステントのサイズSext2、Sext3の下限値、すなわち最小エクステント・サイズが更に縮小可能である。それ故、式（１１）、（１２）から明らかなとおり、第２リード・バッファ4922の最小容量RB2LR、RB2LDが、式（１）とは実質上独立に、更に削減可能である。
＜３Ｄエクステント・ブロック内のエクステントＡＴＣ時間＞
３Ｄエクステント・ブロック、すなわち、インターリーブ配置のデータ・ブロック群では、隣接するデータ・ブロックDn、Rn、Ln（n＝0、1、2、…）がいずれも同じエクステントＡＴＣ時間を持つ。言い換えれば、各データ・ブロックの先頭のソースパケットから次のデータ・ブロックの先頭のソースパケットまでのＡＴＳの差が等しい。但し、その差の計算では、ＡＴＳにラップ・アラウンドが発生することが考慮されている。その場合、ＡＴＣで計られる同じ時間内に、第１ソース・デパケタイザ5011はベースビュー・データ・ブロックLn内の全てのソースパケットからＴＳパケットを取り出して第１ＰＩＤフィルタ5013へ送出し、第２ソース・デパケタイザ5012はディペンデントビュー・データ・ブロックDn又はRn内の全てのソースパケットからＴＳパケットを取り出して第２ＰＩＤフィルタ5014へ送出する。従って、特に飛び込み再生時、主映像デコーダ5015はベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間でＴＳパケットの復号処理を容易に同期させることができる。

＜エクステントＡＴＣ時間を用いたエクステント・サイズの条件式＞
式（２）−（５）では、ベースビュー・エクステントとディペンデントビュー・エクステントとの各サイズが、それよりも後方に位置するエクステントのサイズで制限される。しかし、オーサリング工程での利用という観点からは、各エクステントのサイズに対する条件が、他のエクステントのサイズには依存しない形で表現されていることが望ましい。従って、式（２）−（５）は、以下のように、エクステントＡＴＣ時間を利用した条件式に表現し直される。
上記のとおり、隣接する三つのエクステントDn、Rn、Ln（n＝0、1、2、…）はいずれも同じエクステントＡＴＣ時間Text[n]を持つ。それらのエクステントＡＴＣ時間の最小値を最小エクステントＡＴＣ時間minTextとし、最大値を最大エクステントＡＴＣ時間maxTextとする：minText≦Text[n]≦maxText。その場合、ｎ番目の各エクステントEXT1[n]、EXT2[n]、EXT3[n]のサイズSext1[n]、Sext2[n]、Sext3[n]は次式（１３）、（１４）、（１５）の範囲に制限される：
CEIL(Rext1[n]×minText／8)≦Sext1[n]≦CEIL(Rext1[n]×maxText／8)、 （１３）
CEIL(Rext2[n]×minText／8)≦Sext2[n]≦CEIL(Rext2[n]×maxText／8)、 （１４）
CEIL(Rext3[n]×minText／8)≦Sext3[n]≦CEIL(Rext3[n]×maxText／8)。 （１５）
続いて、最大エクステントＡＴＣ時間maxTextと最小エクステントＡＴＣ時間minTextとの間の差を一定値Tmとする：maxText＝minText＋Tm。その場合、最小エクステントＡＴＣ時間minTextは最小エクステント・サイズ、すなわち式（２）−（５）の各右辺を利用して、以下のように算定される。
ｎ番目のベースビュー・エクステントのサイズが最小エクステント・サイズに等しいとき、式（２）、（１３）から最小エクステントＡＴＣ時間minTextは次式（１６）を満たす：
Figure 0004654327
 （ｎ＋１）番目のライトビュー・エクステントのサイズSext2[n＋1]は、ライトビュー転送速度Rext2の最高値Rmax2と最大エクステントＡＴＣ時間maxTextとの積まで許される：Sext2[n＋1]≦Rmax2×maxText＝Rmax2×(minText＋Tm)。更に、ベースビュー転送速度Rext1[n]は最高値Rmax1を超えない：Rext1[n]≦Rmax1。最小エクステントＡＴＣ時間minTextは式（１６）の右辺の上限であるべきなので、次式（１７）を満たすべきである：
Figure 0004654327
 式（２）に代えて式（４）を同様に変形すれば、最小エクステントＡＴＣ時間minTextは次式（１８）を更に満たすべきである：
Figure 0004654327
 一方、ｎ番目のベースビュー・エクステントのサイズが最小エクステント・サイズに等しいとき、そのエクステントＡＴＣ時間Text[n]が最小エクステントＡＴＣ時間minTextに等しい。ｎ番目のライトビュー・エクステントはｎ番目のベースビュー・エクステントとエクステントＡＴＣ時間が共通であるので、式（３）、（１４）から、最小エクステントＡＴＣ時間minTextは次式（１９）を満たす：
Figure 0004654327
 ライトビュー転送速度Rext2[n]は最高値Rmax2を超えず、ベースビュー転送速度Rext1[n]は最高値Rmax1を超えない：Rext2[n]≦Rmax2、Rext1[n]≦Rmax1。最小エクステントＡＴＣ時間minTextは式（１９）の右辺の上限であるべきなので、次式（２０）を満たすべきである：
Figure 0004654327
 式（３）に代えて式（５）を利用すれば同様にして、最小エクステントＡＴＣ時間minTextが次式（２１）を満たすべきである：
Figure 0004654327
 以上の結果、最小エクステントＡＴＣ時間minTextは、式（１７）、（１８）、（２０）、（２１）の各右辺の中での最大値として定義される。ここで、ゼロ・セクタ遷移時間Tjump−0、ジャンプ時間Tjump−3D、及びエクステントＡＴＣ時間の変動幅Tmは予め一定に制限できる。特に、後述の変形例（F）と同様、最大ジャンプ距離MAX＿EXTJUMP3Dを利用してジャンプ時間Tjump−3Dを評価してもよい。それにより、最小エクステントＡＴＣ時間minTextは実質上、平均転送時間の最大値Rmax等の定数だけで決定可能である。従って、式（１３）−（１５）で表されたエクステント・サイズに対する条件はオーサリング工程での利用に有利である。

＜バッファ余裕量の確保＞
各バッファ余裕量UL1、UL2は、以下に述べるように確保される。まず、各データ・ブロックの設計では「エクステントＡＴＣ時間Textが最小エクステントＡＴＣ時間minText以上である」という条件が課される。ここで、最小エクステントＡＴＣ時間minTextは、式（１７）、（１８）、（２０）、（２１）に示されているとおり、平均転送速度Rext1、Rext2、Rext3がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での値である。しかし、実際の平均転送速度Rext1、Rext2、Rext3はそれぞれの最高値Rmax1、Rmax2、Rmax3よりも一般に低い。従って、実際のデータ・ブロックのサイズRext1×Text、Rext2×Text、Rext3×Textは、上記の条件下で想定される値Rmax1×Text、Rmax2×Text、Rmax3×Textよりも一般に小さい。それ故、各データ・ブロックの読み出し開始からエクステントＡＴＣ時間Textが経過する前に、次のデータ・ブロックの読み出しが開始される。すなわち、各リード・バッファ4921、4922の蓄積データ量DA1、DA2は実際には、図６６、６７の（ａ）、（ｂ）に示されているものとは一般に異なり、読み出し開始時の値まで戻る前に再び増加する。こうして、各蓄積データ量DA1、DA2は、ベースビューとディペンデントビューとのデータ・ブロックの対が一つ読み出されるごとに所定量ずつ増える。その結果、ある程度の数のデータ・ブロックが各リード・バッファ4921、4922に連続して読み込まれることにより、各バッファ余裕量UL1、UL2が確保される。
図６９の（ａ）は、３Ｄエクステント・ブロック6110とＬ／Ｒモードでの再生経路6120との間の対応関係を示す模式図である。図６９の（ａ）を参照するに、３Ｄエクステント・ブロック6110はインターリーブ配置のベースビュー・データ・ブロック群Lkとディペンデントビュー・データ・ブロック群Dk、Rk（k＝0、1、2、…）とで構成されている。再生経路6120に従い、隣接するライトビュー・データ・ブロックRkとベースビュー・データ・ブロックLkとの各対が一つの３Ｄエクステント、すなわちディペンデントビュー・エクステントとベースビュー・エクステントとの対として読み出される。ベースビュー・エクステントLkのエクステント・サイズSext1[k]はベースビュー転送速度Rext1[k]とエクステントＡＴＣ時間Text[k]との積に等しい：Sext1[k]＝Rext1[k]×Text[k]。このエクステント・サイズSext1[k]は、ベースビュー転送速度の最高値Rmax1とエクステントＡＴＣ時間Text[k]との積よりも一般に小さい：Sext1[k]＜Rmax1×Text[k]。ディペンデントビュー・エクステントDk、Rkのエクステント・サイズSext3[k]、Sext2[k]についても同様である。
図６９の（ｂ）は、３Ｄエクステント・ブロック6110がＬ／Ｒモードでの再生経路6120に従って読み出されるときにおける第１リード・バッファ4921の蓄積データ量DA1の変化を示すグラフである。細い実線のグラフは、平均転送速度Rext1[k]、Rext2[k]、Rext3[k]がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での変化を示す。一方、太い実線のグラフは、先頭のベースビュー・エクステントL0の転送速度Rext1[0]が最高値Rmax1よりも低い場合での変化を示す。尚、説明の便宜上、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合を想定する。その場合、ディペンデントビュー・エクステントのサイズRext2[k]×Text[k]、Rext3[k]×Text[k]は想定可能な最大値Rmax2×Text[k]、Rmax3×Text[k]に等しい。
図６９の（ｂ）を参照するに、細い実線のグラフでは、先頭のベースビュー・エクステントL0の読み出し開始からエクステントＡＴＣ時間Text[0]が経過したとき、次のベースビュー・エクステントL1の読み出しが開始される。従って、そのときの蓄積データ量DA1は読み出し開始時の値DM10と実質的に等しい。一方、太い実線のグラフでは、先頭のベースビュー・エクステントL0の全体が記録媒体１００から第１リード・バッファ4921へ読み出されるのに時間Sext1[0]／Rud−3Dが必要である。その時間は細い実線のグラフでの時間Rmax1×Text[0]／Rud−3Dよりも時間ΔTbだけ短い：ΔTb＝Sext1[0]／Rud−3D−Rmax1×Text[0]／Rud−3D＝(Rext1[0]−Rmax1)×Text[0]／Rud−3D。従って、太い実線のグラフでは細い実線のグラフよりも蓄積データ量DA1が時間ΔTbだけ早くピークに達する。一方、各ディペンデントビュー・エクステントD1、R1のサイズSext2[1]、Sext3[1]は両方のグラフで共通の値Rmax2×Text[1]、Rmax3×Text[1]である。従って、蓄積データ量DA1のピークから次のベースビュー・エクステントL1の読み出し開始までの時間ΔTは両方のグラフで共通である。その結果、太い実線のグラフでは細い実線のグラフとは異なり、先頭のベースビュー・エクステントL0の読み出し開始からエクステントＡＴＣ時間Textが経過するよりも時間ΔTbだけ早く、次のベースビュー・エクステントL1の読み出しが開始される。それ故、その時点での蓄積データ量DA1の値DM11は先頭のベースビュー・エクステントL0の読み出し開始時の値DM10よりも増分DM1[0]だけ増加する。図６９の（ｂ）から明らかなとおり、この増分DM1[0]は蓄積データ量DA1の実際の減少速度Rext1[0]と時間ΔTbとの積に等しい：DM1[0]＝Rext1[0]×ΔTb＝Rext1[0]×(Rext1[0]−Rmax1)×Text[0]／Rud−3D。
図６９の（ｃ）は、図６９の（ｂ）に示されている変化を第１リード・バッファ4921の蓄積データ量DA1が示すときにおける第２リード・バッファ4922の蓄積データ量DA2の変化を示すグラフである。細い実線のグラフは、平均転送速度Rext1[k]、Rext2[k]、Rext3[k]がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での変化を示す。一方、太い実線のグラフは、先頭のベースビュー・エクステントL0の転送速度Rext1[0]が最高値Rmax1よりも低い場合での変化を示す。尚、説明の便宜上、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合を想定する。
図６９の（ｃ）を参照するに、細い実線のグラフでは、先頭のライトビュー・エクステントR0の読み出し開始からエクステントＡＴＣ時間Text[0]が経過したとき、次のライトビュー・エクステントR1の読み出しが開始される。従って、そのときの蓄積データ量DA2は読み出し開始時の値DM20と実質的に等しい。一方、太い実線のグラフでは細い実線のグラフよりも時間ΔTbだけ早く、先頭のベースビュー・エクステントL0の全体が記録媒体１００から第１リード・バッファ4921へ読み出される。従って、太い実線のグラフでは細い実線のグラフよりも時間ΔTbだけ早く、すなわち先頭のライトビュー・エクステントR0の読み出し開始からエクステントＡＴＣ時間Textが経過するよりも時間ΔTbだけ前に、次のライトビュー・エクステントR1の読み出しが開始される。それ故、その時点での蓄積データ量DA2の値DM21は、先頭のライトビュー・エクステントR0の読み出し開始時の値DM20よりも増分DM2[0]だけ増加する。図６９の（ｃ）から明らかなとおり、この増分DM2[0]は蓄積データ量DA2の実際の減少速度Rext2[0]と時間ΔTbとの積に等しい：DM2[0]＝Rext2[0]×ΔTb＝Rext2[0]×(Rext1[0]−Rmax1)×Text[0]／Rud−3D。
図６９では、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合が想定されている。しかし、実際には、ディペンデントビュー転送速度Rext2[k]、Rext3[k]も一般に、それぞれの最高値Rmax2、Rmax3よりも低い。その場合、図６９の（ｃ）のグラフでは図６９の（ｂ）のグラフと同様に、蓄積データ量DA2が時間ΔTdだけピークに早く到達する：ΔTd＝Sext2[0]／Rud−3D−Rmax2×Text[0]／Rud−3D＝(Rext2[0]−Rmax2)×Text[0]／Rud−3D。一方、図６９の（ｂ）のグラフでは、蓄積データ量DA1のピークから次のベースビュー・エクステントL1の読み出し開始までの時間ΔTが同じ時間ΔTdだけ短縮される。それらを考慮した場合、ベースビュー・エクステントLkとライトビュー・エクステントRkとの対が一つ処理されるごとに、各リード・バッファの蓄積データ量DA1、DA2は、次式（２２）、（２３）で表される増分DM1[k]、DM2[k]だけ増加する：
DM1[k]＝Rext1[k]×(ΔTb＋ΔTd)
＝Rext1[k]×{(Rext1[k]−Rmax1)＋(Rext2[k]−Rmax2)}×Text[k]／Rud−3D、 （２２）
DM2[k]＝Rext2[k]×(ΔTb＋ΔTd)
＝Rext2[k]×{(Rext1[k]−Rmax1)＋(Rext2[k]−Rmax2)}×Text[k]／Rud−3D。
（２３）
Ｌ／Ｒモードでは、各３ＤエクステントEXTSS[k]からベースビュー・エクステントLkとライトビュー・エクステントRkとが各リード・バッファ4921、4922に読み込まれるごとに各蓄積データ量DA1、DA2は増分DM1[k]、DM2[k]ずつ増える。デプス・モードでも同様に、ベースビュー・エクステントLkとデプスマップ・エクステントDkとが各リード・バッファ4921、4922に読み込まれるごとに各蓄積データ量DA1、DA2は増分DM3[k]、DM4[k]ずつ増える。ここで、増分DM3[k]、DM4[k]は次式（２４）、（２５)で表される：
DM3[k]＝Rext1[k]×{(Rext1[k]−Rmax1)＋(Rext3[k]−Rmax3)}×Text[k]／Rud−3D、 （２４）
DM4[k]＝Rext3[k]×{(Rext1[k]−Rmax1)＋(Rext3[k]−Rmax3)}×Text[k]／Rud−3D。
（２５）
従って、３Ｄエクステント・ブロック6110全体でのエクステントＡＴＣ時間の合計Tsum＝Text[0]＋Text[1]＋Text[2]＋…が次式（２６）を満たすとき、その３Ｄエクステント・ブロック6110の全体の読み出しによって各リード・バッファ4921、4922にバッファ余裕量UL1、UL2を確保することができる：
Figure 0004654327
 ここで、次の近似が用いられている：３Ｄエクステント・ブロック6110の全体で、ベースビュー転送速度Rext1[k]が平均値Rext1−avに等しく、ディペンデントビュー転送速度Rext2[k]、Rext3[k]が平均値Rext2−av、Rext3−avに等しい。
尚、一連の３Ｄエクステント・ブロックの読み出し期間では、ロングジャンプが生じない限り、各リード・バッファの蓄積データ量DA1、DA2は増え続ける。従って、各蓄積データ量DA1、DA2が所定の閾値を超えた場合、再生装置２００はＢＤ−ＲＯＭドライブ4901に読み出し／転送動作を断続させる。それにより、読み出し速度Rud−3Dが低下するので、各蓄積データ量DA1、DA2の増加が抑えられる。こうして、各リード・バッファ4921、4922のオーバーフローを回避することができる。
（バッファ余裕量の蓄積方法１）
次に、リードバッファに確保される層切り替えジャンプなどのためのバッファ余裕量のＡＶ再生中の蓄積方法について説明する。
３Ｄエクステントブロック間のシームレス接続のための配置方法の説明において、３Ｄエクステントブロック間のシームレス接続のために、３Ｄエクステントブロック間のジャンプの場合には、第１リード・バッファ4921にジャンプ前に蓄積されたバッファ余裕量ＵＬ１と、第２リード・バッファ4922にジャンプ前に確保されるバッファ余裕量ＵＬ２を消費して、３Ｄ映像の再生を継続すると説明した。
この第１リード・バッファ4921のバッファ余裕量ＵＬ１と第２リード・バッファ4922のバッファ余裕量ＵＬ２は、３Ｄ映像の再生開始時にバッファリングして蓄えると説明したが、例えば図７０のように３Ｄエクステントブロックが３つ以上シームレスに接続する場合には、１回目の３Ｄエクステントブロック間のジャンプ時にバッファ余裕量ＵＬ１，ＵＬ２を消費してしまうため、２回目の３Ｄエクステントブロック間のジャンプ時にバッファ余裕量がなくなってしまうため、リードバッファのバッファアンダーフローが発生して、シームレス再生できないことになってしまう。
そのため、３Ｄエクステントブロックが、ある３Ｄエクステントブロックからシームレスに接続され、かつ、ある３Ｄエクステントブロックにシームレスに接続する場合には、３Ｄ映像を再生中しながら、第１リード・バッファ4921と第２リード・バッファ4922にバッファ余裕量ＵＬ１、ＵＬ２を、３Ｄエクステントブロック間のジャンプ前までに蓄積する必要がある。この、ある３Ｄエクステントブロックからシームレスに接続され、かつ、ある３Ｄエクステントブロックにシームレスに接続する３Ｄエクステントブロックをシームレス３Ｄエクステントブロック６９０２とここでは呼ぶことにする。
そこで、シームレス３Ｄエクステントブロック６９０２区間での「平均ビットレート」と「シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間」に対して次のような制約を設けることで、シームレス３Ｄエクステントブロック６９０２区間の再生を行った際に、バッファ余裕量ＵＬ１、ＵＬ２のデータ蓄積量を確保できるようにする。

シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間 ＞＝
ＭＡＸ（ＵＬ１×Ｒｕｄ３Ｄ／（ＲＥＸＴ１×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝），
ＵＬ１×Ｒｕｄ３Ｄ／（ＲＥＸＴ１×｛（ＲＭＡＸ１＋ＲＭＡＸ３）−（ＲＥＸＴ１＋ＲＥＸＴ３）｝），
ＵＬ２×Ｒｕｄ３Ｄ／（ＲＥＸＴ２×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝），
ＵＬ２×Ｒｕｄ３Ｄ／（ＲＥＸＴ３×｛（ＲＭＡＸ１＋ＲＭＡＸ３）−（ＲＥＸＴ１＋ＲＥＸＴ３）｝））…式（２７）

ＵＬ１とＵＬ２はシームレス３Ｄエクステントブロックの後方の３Ｄエクステントブロックまでのジャンプ時間を元に計算されたリードバッファのバッファ余裕量（単位：ビット）である。ＭＡＸ（）は項目の大きい値を返す関数である。ＲＥＸＴ１は３Ｄエクステントブロック区間の２Ｄ／左目ＡＶストリームの平均ビットレートであり、ＲＥＸＴ２は３Ｄエクステントブロック区間のファイルＤＥＰのストリームの平均ビットレートであり、ＲＥＸＴ３は３Ｄエクステントブロック区間のデプスマップＡＶストリームの平均ビットレートである。
以降で上記式の根拠を、図７１を用いて説明する。ここでは、Ｌ／Ｒモードで３Ｄ映像の再生を行う場合のケースを用いて説明するが、同様の方法でＤＥＰＴＨモードの計算を行えば式を導くことができる。
図７１はＬ／Ｒモードで３Ｄ映像の再生を行う場合の第１リード・バッファ4921と第２リード・バッファ4922のデータ蓄積量の推移を示す。ここではシームレス３Ｄエクステントブロックにジャンプした直後の様子を示しており、ＵＬ１、ＵＬ２のバッファ余裕量を消費しきった状態で再生を開始しているとする。また、各エクステントは、前述した最小エクステントサイズと最大エクステントサイズの定義方法によって、インターリーブして配置されているとする。
前述の最小エクステントサイズと最大エクステントサイズは、エクステントの平均ビットレートをＲＭＡＸ１もしくはＲＭＡＸ２として算出したサイズとなっている。図７１のデータ蓄積量の推移を示す通常の線は、エクステントの平均ビットレートがＲＭＡＸ１、ＲＭＡＸ２の場合のデータ蓄積量の推移を示す。対してデータ蓄積量の推移を示す太線は、２Ｄ／左目ＡＶストリームのエクステント（ＲＥＸＴ１［ｎ］）の平均ビットレートがＲＭＡＸ１よりも小さいＲＥＸＴ１の場合のデータ蓄積量の推移を示している。
２Ｄ／左目ＡＶストリームのエクステントのビットレートがＲＭＡＸ１よりも小さい場合には、エクステントの読み込みは、ビットレートがＲＭＡＸ１の場合よりも早く終わることになり、以降のデータ蓄積量の推移は矢印７００１で示す分だけ前倒しされることになる。この前倒しによって、エクステントを読み終えると、前倒しの分だけ、矢印７００２で示されるサイズ（前倒し時間×ＲＥＸＴ１）がバッファ余裕量として蓄積されることになる。前倒し時間は、エクステントの再生時間をＴＥＸＴとすると、ＴＥＸＴ×（ＲＭＡＸ１−ＲＥＸＴ１）／ＲＵＤ３Ｄと表せる。また、第２リード・バッファ4922のデータ蓄積量も同様に前倒しされることとなるため、エクステントを読み終えると、前倒しの分だけ、矢印７００３で示されるサイズ（前倒し時間×ＲＥＸＴ２）がバッファ余裕量として蓄積されることになる。
同様にファイルＤＥＰのストリームのエクステントのビットレートがＲＭＡＸ２よりも小さいＲＥＸＴ２の場合には前倒しが発生するためその分、第１リード・バッファ4921と第２リード・バッファ4922にはバッファ余裕量が蓄積されることとなる。
２Ｄ／左目ＡＶストリームのエクステント群と、対応するファイルＤＥＰのストリームのエクステント群の再生時間をＴＥＸＴとし、各エクステントの平均ビットレートがＲＥＸＴ１、ＲＥＸＴ２とすると、これらのエクステントを読むことによって、第１リード・バッファ4921に蓄積されるバッファ余裕量と、第２リード・バッファ4922に蓄積されるバッファ余裕量は次のようになる。

第１リード・バッファ4921に蓄積されるバッファ余裕量（単位：ビット）＝ＴＥＸＴ×（ＲＥＸＴ１×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝／ＲＵＤ３Ｄ…式（２８）

第２リード・バッファ4922に蓄積されるバッファ余裕量（単位：ビット）＝ＴＥＸＴ×（ＲＥＸＴ２×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝／ＲＵＤ３Ｄ…式（２９）

よって式（２８）と（２９）から、シームレス接続のジャンプに必要なＵＬ１、ＵＬ２のサイズを蓄積するまでの時間にすることで、式（２７）を導くことができる。

（バッファ余裕量の蓄積方法２）
次に、リードバッファに確保される層切り替えジャンプなどのためのバッファ余裕量のＡＶ再生中の蓄積方法の別案を説明する。
シームレス３Ｄエクステントブロック６９０２内のエクステントのサイズは、式（１）−（５）で求められる最小エクステントサイズ以上に設定するとしたが、この計算式に、バッファ余裕量を蓄積するためのマージンを追加した以下に示す形に変形する。

ＳＥＸＴ１［ｎ］＞＝ＣＥＩＬ（（Ｒｕｄ３Ｄ×ＲＥＸＴ１［ｎ］）／（Ｒｕｄ３Ｄ−ＲＥＸＴ１［ｎ］）×（ＴＪＵＭＰ０＋ＳＥＸＴ２［ｎ＋１］／Ｒｕｄ３Ｄ＋ＴＪＵＭＰ＋ＴＭＥＲＧＩＮ）／８）…（３０）

ＳＥＸＴ２［ｎ］＞＝ＣＥＩＬ（（Ｒｕｄ３Ｄ×ＲＥＸＴ２［ｎ］）／（Ｒｕｄ３Ｄ−ＲＥＸＴ２［ｎ］）×（ＴＪＵＭＰ０＋ＳＥＸＴ１［ｎ］／Ｒｕｄ３Ｄ＋ＴＪＵＭＰ＋ＴＭＥＲＧＩＮ）／８）…（３１）

ＳＥＸＴ１［ｎ］＞＝ＣＥＩＬ（（Ｒｕｄ３Ｄ×ＲＥＸＴ１［ｎ］）／（Ｒｕｄ３Ｄ−ＲＥＸＴ１［ｎ］）×（ＴＪＵＭＰ＋ＳＥＸＴ３［ｎ＋１］／Ｒｕｄ３Ｄ＋ＴＪＵＭＰ０＋ＴＭＥＲＧＩＮ）／８）…（３２）

ＳＥＸＴ３［ｎ］＝ＣＥＩＬ（（Ｒｕｄ３Ｄ×ＲＥＸＴ３［ｎ］）／（Ｒｕｄ３Ｄ−ＲＥＸＴ３［ｎ］）×（ＴＪＵＭＰ＋ＳＥＸＴ１［ｎ］／Ｒｕｄ３Ｄ＋ＴＪＵＭＰ０＋ＴＭＥＲＧＩＮ）／８）…（３３）

ＴＭＥＲＧＩＮがバッファ余裕量を蓄積するためのマージン時間（単位：秒）である。
図７２を用いてＬ／Ｒモードでの３Ｄ映像再生におけるリードバッファへのデータ蓄積量の変化を説明する。
このように計算された最小エクステントサイズを持つエクステントでシームレス３Ｄエクステントブロック６９０２を構成することにより、図７２のデータ蓄積量の推移に示すように、２Ｄ／左目ＡＶストリームの１エクステントの読み込むに従って、ＴＭＥＲＧＩＮ×ＲＥＸＴ１［ｎ］の値だけ第１リード・バッファ4921にデータが余分に蓄積される。ファイルＤＥＰのストリームの１エクステントの読み込むに従って、ＴＭＥＲＧＩＮ×ＲＥＸＴ２［ｎ］の値だけ第２リード・バッファ4922にデータが余分に蓄積される。
また、ファイルＤＥＰのストリームの１エクステントの読み込むに従って、ＴＭＥＲＧＩＮの値だけ、第１リード・バッファ4921への２Ｄ／左目ＡＶストリームのエクステントデータの入力を前倒しできるため、ファイルＤＥＰのストリームの１エクステントの読み込む度に、ＴＭＥＲＧＩＮ×ＲＥＸＴ１［ｎ］の値だけ第１リード・バッファ4921にデータが余分に蓄積される。同様に２Ｄ／左目ＡＶストリームの１エクステントの読み込むに従って、ＴＭＥＲＧＩＮの値だけ、第２リード・バッファ4922へのファイルＤＥＰのストリームのエクステントデータの入力を前倒しできるため、ファイルＤＥＰのストリームの１エクステントの読み込む度に、ＴＭＥＲＧＩＮ×ＲＥＸＴ１［ｎ］の値だけ第１リード・バッファ4921にデータが余分に蓄積される。
そこで、シームレス３Ｄエクステントブロック６９０２区間での「３Ｄエクステントブロックの合計エクステントＡＴＣ時間」に対して次のような制約を設けることで、シームレス３Ｄエクステントブロック６９０２区間の再生を行った際に、バッファ余裕量ＵＬ１、ＵＬ２のデータ蓄積量を確保できることになる。

シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間 ＞＝
ＭＡＸ（ＵＬ１／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ１／ＴＥＸＴ），
ＵＬ２／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ２／ＴＥＸＴ），
ＵＬ２／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ３／ＴＥＸＴ））…式（３４）
ＵＬ１とＵＬ２はシームレス３Ｄエクステントブロックの後方の３Ｄエクステントブロックまでのジャンプ時間を元に計算されたリードバッファのバッファ余裕量（単位：ビット）である。ＭＡＸ（）は項目の大きい値を返す関数である。ＲＥＸＴ１は３Ｄエクステントブロック区間の２Ｄ／左目ＡＶストリームの平均ビットレートであり、ＲＥＸＴ２は３Ｄエクステントブロック区間のファイルＤＥＰのストリームの平均ビットレートであり、ＲＥＸＴ３は３Ｄエクステントブロック区間のデプスマップＡＶストリームの平均ビットレートである。ＴＥＸＴは、１エクステントの平均エクステントＡＴＣ時間である。
なお、上記のように規定することと、「平均ビットレート」と「シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間」で規定する方法を両立させるようにしても良い。つまり、以下のように「シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間」を規定しても良い。

シームレス３Ｄエクステントブロックの合計エクステントＡＴＣ時間 ＞＝
ＭＡＸ（ＵＬ１／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ１／ＴＥＸＴ＋（（ＲＥＸＴ１×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝）／Ｒｕｄ３Ｄ），
ＵＬ１／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ１／ＴＥＸＴ＋（（ＲＥＸＴ１×｛（ＲＭＡＸ１＋ＲＭＡＸ３）−（ＲＥＸＴ１＋ＲＥＸＴ３）｝）／Ｒｕｄ３Ｄ），
ＵＬ２／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ２／ＴＥＸＴ＋（（ＲＥＸＴ２×｛（ＲＭＡＸ１＋ＲＭＡＸ２）−（ＲＥＸＴ１＋ＲＥＸＴ２）｝）／Ｒｕｄ３Ｄ），
ＵＬ２／（２×ＴＭＥＲＧＩＮ× ＲＥＸＴ３／ＴＥＸＴ＋（（ＲＥＸＴ３×｛（ＲＭＡＸ１＋ＲＭＡＸ３）−（ＲＥＸＴ１＋ＲＥＸＴ３）｝）／Ｒｕｄ３Ｄ））…式（３５）

＜配置１のデータを３Ｄ再生するために必要なバッファ余裕量＞
次に、図２０に示した配置１のデータを３Ｄ再生するために必要なバッファ余裕量について説明する。
まず、Ｌ／Ｒモードで再生する上で必要なバッファ余裕量について説明する。
図７３の（ａ）は、配置１のデータをＬ／Ｒモードで再生中に生じるロングジャンプを示す図である。図７３の（ｂ）は、Ｌ／Ｒモードで配置１のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、図７３の（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前３Ｄエクステントブロック2002の後端に配列するエクステントＡＴＣ時間が一致する三つのデータブロックD3、R3、L3SSのサイズが０である場合を想定する。
まず、第１リード・バッファ4921のバッファ余裕量UL1について説明する。図７３の（ａ）に示す経路で再生した場合に第１リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前（地点Ｂ）までにアンダーフローしなければ良い。つまり地点Ｂのリードバッファサイズが≧０であればよい。そのためには、図７３の地点Ａ（３Ｄエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前）までにバッファ余裕量ＵＬ１のデータ量を蓄積する必要がある。
地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファの減少量＝（ＴＪＵＭＰＥＸ ＋ ３×ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ ＋ ２×ＳＥＸＴ２／ＲＵＤ３Ｄ ) × ＲＭＡＸ１
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ２／ＲＵＤ３Ｄ)× ＲＭＡＸ１ ＋（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ) × ＲＭＡＸ１ …（３６）

ＳＥＸＴ２は、地点Ａから地点Ｂまでに存在するライトビューデータブロックのサイズを示す。地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量＝２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（３７）

ＳＥＸＴ１は、地点Ａから地点Ｂまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Ａに必要なバッファ余裕量は、式（３６）、（３７）から次のように計算できる。
ＵＬ１＝地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量−地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ２／ＲＵＤ３Ｄ)× ＲＭＡＸ１ ＋（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ) × ＲＭＡＸ１ −２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（３８）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ２／ＲＵＤ３Ｄ)× ＲＭＡＸ１とＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）は０以上になるように最小エクステントサイズは決定される。つまり、式（２）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（３８）からＬ／Ｒモードで再生する上で必要なバッファ余裕量UL1は、次式（３９）となる。
ＵＬ１＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ＋ＴＪＵＭＰ０−ＴＪＵＭＰ）×ＲＭＡＸ１ …（３９）
次に、第２リード・バッファ4922のバッファ余裕量について説明する。第２リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前（地点Ｄ）までにアンダーフローしなければ良い。つまり地点Ｄのリードバッファサイズが≧０であればよい。そのためには、図７３の地点Ｃ（３Ｄエクステントブロック2001の終端のライトビューデータブロックR1を読み込む直前）までにバッファ余裕量（ＵＬ２）のデータ量を蓄積する必要がある。
地点Ｃから地点Ｄまでの第２リード・バッファ4922の減少量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの減少量＝（ＴＪＵＭＰＥＸ ＋ ３×ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ ＋ ２×ＳＥＸＴ１／ＲＵＤ３Ｄ ) × ＲＭＡＸ２
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ２ ＋（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ) × ＲＭＡＸ２ …（４０）

ＳＥＸＴ１は、地点Ｃから地点Ｄまでに存在するレフトビューデータブロックのサイズを示す。地点Ａから地点Ｂまでの第２リード・バッファ4921の増加量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの増加量＝２×ＳＥＸＴ２／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ２）…（４１）

ＳＥＸＴ２は、地点Ｃから地点Ｄまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Ｃに必要なバッファ余裕量は、式（４０）、（４１）から次のように計算できる。
ＵＬ２＝地点Ｃから地点Ｄまでの第２リード・バッファの減少量−地点Ｃから地点Ｄまでの第２リード・バッファの増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ２ ＋（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ) × ＲＭＡＸ２ −２×ＳＥＸＴ２／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ２）…（４２）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ２とＳＥＸＴ２／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ２）は０以上になるように最小エクステントサイズは決定される。つまり、式（３）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（４２）からＬ／Ｒモードで再生する上で必要なバッファ余裕量UL1は、次式（４３）となる。
ＵＬ２＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ＋ＴＪＵＭＰ０−ＴＪＵＭＰ）×ＲＭＡＸ２ …（４３）
以上がＬ／Ｒモードで配置１のデータを再生する上で必要なバッファ余裕量である。

次に、ＤＥＰＴＨモードで配置１のデータを再生する上で必要なバッファ余裕量について説明する。
図７４の（ａ）は、配置１のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図７４の（ｂ）は、デプスモードで配置１のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、図７４の（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前３Ｄエクステントブロック2002の後端に配列するエクステントＡＴＣ時間が一致する三つのデータブロックD3、R3、L3SSのサイズが０である場合を想定する。
まず、第１リード・バッファ4921のバッファ余裕量UL1について説明する。図７４の（ａ）に示す経路で再生した場合に第１リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前（地点Ｂ）までにアンダーフローしなければ良い。つまり地点Ｂのリードバッファサイズが≧０であればよい。そのためには、図７４の地点Ａ（３Ｄエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前）までにバッファ余裕量ＵＬ１のデータ量を蓄積する必要がある。
地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファの減少量＝（ＴＪＵＭＰＥＸ ＋ ３×ＴＪＵＭＰ＋ ＴＪＵＭＰ０ ＋ ＴＬＡＹＥＲ ＋ ２×ＳＥＸＴ３／ＲＵＤ３Ｄ ) × ＲＭＡＸ１
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ)× ＲＭＡＸ１ ＋（ＴＪＵＭＰ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ０) × ＲＭＡＸ１ …（４４）

ＳＥＸＴ３は、地点Ａから地点Ｂまでに存在するデブスマップデータブロックのサイズを示す。地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量＝２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（４５）

ＳＥＸＴ１は、地点Ａから地点Ｂまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Ａに必要なバッファ余裕量は、式（４４）、（４５）から次のように計算できる。
ＵＬ１＝地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量−地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ)× ＲＭＡＸ１ ＋（ＴＪＵＭＰ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ０) × ＲＭＡＸ１ −２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（４６）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ)× ＲＭＡＸ１とＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）は０以上になるように最小エクステントサイズは決定される。つまり、式（４）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（４６）からＬ／Ｒモードで再生する上で必要なバッファ余裕量UL1は、次式（４７）となる。
ＵＬ１＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ−ＴＪＵＭＰ０＋ＴＪＵＭＰ）×ＲＭＡＸ１ …（４７）
次に、第２リード・バッファ4922のバッファ余裕量について説明する。第２リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のデプスマップデータブロックD4を読む直前（地点Ｄ）までにアンダーフローしなければ良い。つまり地点Ｄのリードバッファサイズが≧０であればよい。そのためには、図７４の地点Ｃ（３Ｄエクステントブロック2001の終端のデプスマップデータブロックD1を読み込む直前）までにバッファ余裕量（ＵＬ２）のデータ量を蓄積する必要がある。
地点Ｃから地点Ｄまでの第２リード・バッファ4922の減少量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの減少量＝（ＴＪＵＭＰＥＸ ＋ ３×ＴＪＵＭＰ＋ ＴＪＵＭＰ０ ＋ ＴＬＡＹＥＲ ＋ ２×ＳＥＸＴ１／ＲＵＤ３Ｄ ) × ＲＭＡＸ３
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ３ ＋（ＴＪＵＭＰ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ０) × ＲＭＡＸ３ …（４８）

ＳＥＸＴ１は、地点Ｃから地点Ｄまでに存在するレフトビューデータブロックのサイズを示す。地点Ａから地点Ｂまでの第２リード・バッファ4921の増加量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの増加量＝２×ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（４９）

ＳＥＸＴ３は、地点Ｃから地点Ｄまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Ｃに必要なバッファ余裕量は、式（４８）、（４９）から次のように計算できる。
ＵＬ２＝地点Ｃから地点Ｄまでの第２リード・バッファの減少量−地点Ｃから地点Ｄまでの第２リード・バッファの増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ３ ＋（ＴＪＵＭＰ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ − ＴＪＵＭＰ０) × ＲＭＡＸ３ −２×ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（５０）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ３とＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）は０以上になるように最小エクステントサイズは決定される。つまり、式（５）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（５０）からＬ／Ｒモードで再生する上で必要なバッファ余裕量UL1は、次式（５１）となる。
ＵＬ２＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ−ＴＪＵＭＰ０＋ＴＪＵＭＰ）×ＲＭＡＸ３ …（５１）
以上がデプスモードで配置１のデータを再生する上で必要なバッファ余裕量である。
２Ｄ／３Ｄ再生装置は、このように計算されるＵＬ１とＵＬ２をバッファ余裕量として確保することで、図２０で説明した配置１のデータを、シームレスに再生を行うことが可能となる。

＜配置２のデータを３Ｄ再生するために必要なバッファ余裕量＞
次に、図２４に示した配置２のデータを３Ｄ再生するために必要なバッファ余裕量について説明する。 まず、デプスモードで再生する上で必要なバッファ余裕量について説明する。
図７５の（ａ）は、配置２のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図７５の（ｂ）は、デプスモードで配置２のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、図７５の（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前３Ｄエクステントブロック2002の後端に配列するエクステントＡＴＣ時間が一致する三つのデータブロックD3、R3、L3SSのサイズが０である場合を想定する。
まず、第１リード・バッファ4921のバッファ余裕量UL1について説明する。図７５の（ａ）に示す経路で再生した場合に第１リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前（地点Ｂ）までにアンダーフローしなければ良い。つまり地点Ｂのリードバッファサイズが≧０であればよい。そのためには、図７５の地点Ａ（３Ｄエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前）までにバッファ余裕量ＵＬ１のデータ量を蓄積する必要がある。
地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量＝( ２×ＴＪＵＭＰ ＋ ＴＪＵＭＰ０ ＋ ＴＬＡＹＥＲ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ ) × ＲＭＡＸ１
＝（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１ ＋（ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ１ …（５２）

ＳＥＸＴ３は、地点Ａから地点Ｂまでに存在するデプスマップデータブロックのサイズを示す。地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量＝ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（５３）

ＳＥＸＴ１は、地点Ａから地点Ｂまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Ａに必要なバッファ余裕量は、式（５２）、（５３）から次のように計算できる。
ＵＬ１＝地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量−地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量
ＵＬ１＝地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量−地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量
＝（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１ ＋（ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ１ −ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（５４）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１とＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）は０以上になるように最小エクステントサイズは決定される。つまり、式（３）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（５４）からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式（５５）となる。
ＵＬ１＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰ）×ＲＭＡＸ１ …（５５）
次に、第２リード・バッファ4922のバッファ余裕量について説明する。第２リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前（地点Ｄ）までにアンダーフローしなければ良い。つまり地点Ｄのリードバッファサイズが≧０であればよい。そのためには、図７５の地点Ｃ（３Ｄエクステントブロック2001の終端のライトビューデータブロックR1を読み込む直前）までにバッファ余裕量（ＵＬ２）のデータ量を蓄積する必要がある。
地点Ｃから地点Ｄまでの第２リード・バッファ4922の減少量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの減少量＝( ２×ＴＪＵＭＰ ＋ ＴＪＵＭＰ０ ＋ ＴＬＡＹＥＲ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ ) × ＲＭＡＸ３
＝（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ )× ＲＭＡＸ３ ＋（ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ３ …（５６）

ＳＥＸＴ１は、地点Ｃから地点Ｄまでに存在するレフトビューデータブロックのサイズを示す。地点Ａから地点Ｂまでの第２リード・バッファ4921の増加量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの増加量＝ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（５７）

ＳＥＸＴ２は、地点Ｃから地点Ｄまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Ｃに必要なバッファ余裕量は、式（５６）、（５７）から次のように計算できる。
ＵＬ２＝地点Ｃから地点Ｄまでの第２リード・バッファの減少量−地点Ｃから地点Ｄまでの第２リード・バッファの増加量
＝（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ )× ＲＭＡＸ３ ＋（ＴＪＵＭＰ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ３−ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（５８）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ３とＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）は０以上になるように最小エクステントサイズは決定される。つまり、式（３）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（５８）からＬ／Ｒモードで再生する上で必要なバッファ余裕量UL1は、次式（５９）となる。
ＵＬ２＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰ）×ＲＭＡＸ３ …（５９）
以上がデプスモードで配置２のデータを再生する上で必要なバッファ余裕量である。
次に、Ｌ／Ｒモードで再生する上で必要なバッファ余裕量（ＵＬ１，ＵＬ２）について説明する。
Ｌ／Ｒモードで再生する上で必要なバッファ余裕量は、次で表す式で求められる。
ＵＬ１＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰ０）×ＲＭＡＸ１ …（６０）
ＵＬ２＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰ０）×ＲＭＡＸ２ …（６１）

これらはＤＥＰＴＨモードのバッファ余裕量ＵＬ１、ＵＬ２と同様の考え方で計算できるため計算方法は省略する。
２Ｄ／３Ｄ再生装置は、このように計算されるＵＬ１とＵＬ２をバッファ余裕量として確保することで、図２４で説明した配置２のデータを、シームレスに再生を行うことが可能となる。
ここで、式（６０）、（６１）によって求められる配置２のデータをＬ／Ｒモードで再生する上で必要なバッファ余裕量は、式（３９）、（４３）によって求められる配置１のデータをＬ／Ｒモードで再生する上で必要なバッファ余裕量に比べて値が小さい。また、式（５５）、（５９）によって求められる配置２のデータをデプスモードで再生する上で必要なバッファ余裕量は、式（４７）、（５１）によって求められる配置１のデータをデプスモードで再生する上で必要なバッファ余裕量に比べて値が小さい。
よって、図２４を用いて説明した配置２のデータ構造の方が、シームレス接続に必要なバッファ余裕量（ＵＬ１、ＵＬ２）を小さく抑えられるため、３Ｄ映像を再生する際に必要な第１リード・バッファ4921、第２リード・バッファ4922のサイズを小さくすることができる。
ただし、図２４を用いて説明したデータ構造でデータを配置するためには、図２０にはない前述した次の条件が必要である。
「３Ｄエクステントブロック６４０１の最後の２Ｄ／左目ＡＶストリームのエクステントは、自身のエクステントの終端から、２Ｄジャンプ直前エクステント６５０１までのジャンプ時間をＴＪＵＭＰとして式（２）によって求められる２Ｄ再生装置のための最小エクステントサイズ以上のサイズになる必要がある。３Ｄエクステントブロック６４０１の最後の２Ｄ／左目ＡＶストリームのエクステントから、２Ｄジャンプ直前エクステント６５０１までの距離は、２Ｄ再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。」
図７６に示すように、３Ｄエクステントブロックのエクステントサイズの条件から決められたサイズを持つ３Ｄエクステントブロック2001の最後のレフトビューデータブロックL1を読み込むことで２Ｄ再生装置がシームレスに再生可能なジャンプ距離が、ジャンプ直前３Ｄエクステントブロック2002のサイズよりも大きい場合は、図２４を用いて説明したデータ構造でデータを配置できる。しかし、３Ｄエクステントブロックのエクステントサイズの条件から決められたサイズを持つ３Ｄエクステントブロック2001の最後のレフトビューデータブロックL1を読み込むことで２Ｄ再生装置がシームレスに再生可能なジャンプ距離が、ジャンプ直前３Ｄエクステントブロック2002のサイズよりも小さい場合は、図２４を用いて説明したデータ構造でデータを配置できない。
よって、上記の条件を満たす場合は、図２４に示す配置２のデータ構造でデータを配置し、満たさない場合は、図２０に示す配置１のデータ構造でデータを配置するというように使い分けを行うと好ましい。
また、式（１）で示したように、２Ｄ再生モードでシームレス接続をするためのエクステントサイズはシステムレートに依存するため、上記条件をクリアするためのレフトビュービデオストリームのシステムレートを特定し、そのシステムレートよりも高ければ、図２０に示す配置１のデータ構造で配置し、そのシステムレートよりも低ければ、図２４に示す配置２のデータ構造で配置するとしても良い。
なお、図２４に示す配置２では、ジャンプ直前２ＤエクステントEXT2D[n]が２Ｄ専用ブロックのみから構成されており、ジャンプ直前２ＤエクステントEXT2D[n]と同じサイズのデータを３Ｄ専用ブロックとして複製し、記録媒体に記録しておく必要がある。 その一方で図２０に示す配置１では、ジャンプ直前２ＤエクステントEXT2D[n]の一部として利用しているベースビュー・データ・ブロックLnが、３ＤエクステントEXTSS[n]の一部としても利用されるため、異なるエクステントに重複して格納されるデータ量の増大を抑えることができるという点で好ましい。

＜配置３のデータを３Ｄ再生するために必要なバッファ余裕量＞
次に、図２６に示した配置３のデータを３Ｄ再生するために必要なバッファ余裕量について説明する。 まず、デプスモードで再生する上で必要なバッファ余裕量について説明する。
図７７の（ａ）は、配置３のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図７７の（ｂ）は、デプスモードで配置３のデータを再生する場合の第１リード・バッファ4921のデータ蓄積量の推移を示し、図７７の（ｃ）は第２リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前３Ｄエクステントブロック2002の後端に配列するエクステントＡＴＣ時間が一致する三つのデータブロックD3、R3、L3SSのサイズが０である場合を想定する。
まず、第１リード・バッファ4921のバッファ余裕量UL1について説明する。図７７の（ａ）に示す経路で再生した場合に第１リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前（地点Ｂ）までにアンダーフローしなければ良い。つまり地点Ｂのリードバッファサイズが≧０であればよい。そのためには、図７７の地点Ａ（３Ｄエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前）までにバッファ余裕量ＵＬ１のデータ量を蓄積する必要がある。

地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量＝( ２×ＴＪＵＭＰ ＋ ２×ＴＪＵＭＰ０ ＋ ＴＬＡＹＥＲ ＋ ＴＪＵＭＰＥＸ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ ) × ＲＭＡＸ１
＝（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１ ＋（ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ１ …（６２）
ＳＥＸＴ３は、地点Ａから地点Ｂまでに存在するデプスマップデータブロックのサイズを示す。地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量は次のとおりに計算される。
地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量＝２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（６３）
ＳＥＸＴ１は、地点Ａから地点Ｂまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Ａに必要なバッファ余裕量は、式（６２）、（６３）から次のように計算できる。
ＵＬ１＝地点Ａから地点Ｂまでの第１リード・バッファ4921の減少量−地点Ａから地点Ｂまでの第１リード・バッファ4921の増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１ ＋（ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ１ −２×ＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）…（６４）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ３／ＲＵＤ３Ｄ )× ＲＭＡＸ１とＳＥＸＴ１／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ１）は０以上になるように最小エクステントサイズは決定される。つまり、式（３）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。

よって、ワースト値を考慮するとこの値は０となるため、式（５４）からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式（６５）となる。
ＵＬ１＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰＥＸ）×ＲＭＡＸ１ …（６５）
次に、第２リード・バッファ4922のバッファ余裕量について説明する。第２リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前（地点Ｄ）までにアンダーフローしなければ良い。つまり地点Ｄのリードバッファサイズが≧０であればよい。そのためには、図７７の地点Ｃ（３Ｄエクステントブロック2001の終端のデプスマップデータブロックD1を読み込む直前）までにバッファ余裕量（ＵＬ２）のデータ量を蓄積する必要がある。
地点Ｃから地点Ｄまでの第２リード・バッファ4922の減少量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの減少量＝( ２×ＴＪＵＭＰ ＋ ２×ＴＪＵＭＰ０ ＋ ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ ＋ ２×ＳＥＸＴ１／ＲＵＤ３Ｄ ) × ＲＭＡＸ３
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ )× ＲＭＡＸ３ ＋（ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ３ …（６６）
ＳＥＸＴ１は、地点Ｃから地点Ｄまでに存在するレフトビューデータブロックのサイズを示す。地点Ｃから地点Ｄまでの第２リード・バッファ4921の増加量は次のとおりに計算される。
地点Ｃから地点Ｄまでの第２リード・バッファの増加量＝２×ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（６７）
ＳＥＸＴ３は、地点Ｃから地点Ｄまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Ｃに必要なバッファ余裕量は、式（６６）、（６７）から次のように計算できる。
ＵＬ２＝地点Ｃから地点Ｄまでの第２リード・バッファの減少量−地点Ｃから地点Ｄまでの第２リード・バッファの増加量
＝２×（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ )× ＲＭＡＸ３ ＋（ＴＪＵＭＰＥＸ ＋ ＴＬＡＹＥＲ) × ＲＭＡＸ３−２×ＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）…（６８）

ここで、（ＴＪＵＭＰ０ ＋ ＴＪＵＭＰ ＋ ＳＥＸＴ１／ＲＵＤ３Ｄ)× ＲＭＡＸ３とＳＥＸＴ３／ＲＵＤ３Ｄ×（ＲＵＤ３Ｄ−ＲＭＡＸ３）は０以上になるように最小エクステントサイズは決定される。つまり、式（３）を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず０以上になる。
よって、ワースト値を考慮するとこの値は０となるため、式（６８）からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式（６９）となる。
ＵＬ２＝ＣＥＩＬ（ＴＬＡＹＥＲ＋ＴＪＵＭＰＥＸ）×ＲＭＡＸ３ …（６９）
以上がデプスモードで配置３のデータを再生する上で必要なバッファ余裕量である。

次に、Ｌ／Ｒモードで再生する上で必要なバッファ余裕量について説明する。
Ｌ／Ｒモードで再生する上で必要なバッファ余裕量は、次で表す式で求められる。
ＵＬ１＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ）×ＲＭＡＸ１ …（７０）
ＵＬ２＝ＣＥＩＬ（ＴＪＵＭＰＥＸ＋ＴＬＡＹＥＲ）×ＲＭＡＸ２ …（７１）

これはデプスモードのバッファ余裕量ＵＬ１、ＵＬ２と同様の考え方で説明できるため、計算方法は省略する。
２Ｄ／３Ｄ再生装置は、このように計算されるＵＬ１とＵＬ２をバッファ余裕量として確保することで、図２６で説明した配置３のデータを、シームレスに再生を行うことが可能となる。
ここで、２Ｄ／３Ｄ再生装置が、Ｌ／Ｒモードとデプスモードの両方３Ｄ映像を再生可能である場合には、必要なバッファ余裕量はワースト値になる。図２０を用いて説明した配置１のデータ構造を再生する場合のバッファ余裕量のワースト値（最大値）は、デプスモードで３Ｄ映像を再生するために必要なバッファ余裕量である、式（４７）、（５１）で求められるサイズになる。図２６を用いて説明した配置３のデータ構造を再生する場合のバッファ余裕量のワースト値（最大値）は、Ｌ／Ｒモードで３Ｄ映像を再生するために必要なバッファ余裕量である式（７０）、（７１）で求められるサイズか、デプスモードで３Ｄ映像を再生するために必要なバッファ余裕量である式（６５）、（６９）で求められるサイズかの何れかになる。ここで、式（７０）、（７１）で求められる配置３をＬ／Ｒモードで再生するために必要なバッファ余裕量と、式（６５）、（６９）で求められる配置３をデブスモードで再生するために必要なバッファ余裕量とは、どちらも式（４７）、（５１）で求められる配置１をデブスモードで再生するために必要なバッファ余裕量に比べて小さい。即ち、配置３は配置１に比べて、デプスモードとＬ／Ｒモードとの両方で、シームレス接続に必要なバッファ余裕量（ＵＬ１、ＵＬ２）を小さく抑えられる。よって、Ｌ／Ｒモードとデプスモードとの両方３Ｄ映像を再生可能である場合には、リードバッファに必要なサイズの観点から図２６を用いて説明した配置１のデータ構造で記録媒体にストリームデータを配置することが好ましいことが言える。

（シームレス接続時のリードバッファサイズを削減するためのデータ構造）
図２０、図２４、図２６で説明したシームレス接続でのデータ配置方法に加えて、２Ｄ／３Ｄ再生装置での３Ｄ映像再生に必要なリードバッファのサイズを削減するためのデータ配置方法を、図７８を用いて説明する。
３Ｄ映像再生に必要なリードバッファのサイズを削減するためのデータ配置方法について説明する。
図７８上段は、図２６で説明した配置３でのＬ／Ｒモードの再生経路、デプスモードの再生経路を示している。
図７８上段のデータ構造において、ジャンプ直前３Ｄエクステントブロック７５０１の終端のレフトビューデータブロック、ライトビューデータブロック、デプスマップデータブロックの各データブロックのサイズは、式（２）−（５）で求められる最小エクステントサイズを満たさないでよい。これは、例えば前述した定義方法によって最小エクステントサイズを「エクステントの平均転送レート×最小エクステントＡＴＣ時間」（例：ＲＥＸＴ１［ｎ］×ＭＩＮ＿ＴＥＸＴ）とし、最大エクステントサイズを「エクステントの平均転送レート×最小エクステントＡＴＣ時間」（例：ＲＥＸＴ１［ｎ］×ＭＩＮ＿ＴＥＸＴ）とした場合に、コンテンツの再生時間によっては、最小エクステント時間を満たさない端数が出てきてしまうためである。例えば、最小エクステントＡＴＣ時間を2秒、最大エクステントＡＴＣ時間＝最小エクステントＡＴＣ時間とし、ＡＶストリームのＡＴＣ時間が１１秒であるとする。この場合、ＡＶストリームの先頭から最小エクステントＡＴＣ時間である２秒単位でエクステントを区切っていく場合に、終端に1秒のエクステントＡＴＣ時間のエクステントがあまってしまう。
仮に図７８下段のように終端のエクステント群が、式（２）−（５）の最小エクステントサイズを満たすようにすると、２Ｄ／３Ｄ再生装置に必要なバッファ余裕量であるＵＬ１とＵＬ２は削減できるため好ましい。
そこで、終端のエクステント群が、式（２）−（５）の最小エクステントサイズを満たせるように図７９に示すように次の制約を設ける。
シームレス接続するためのＡＶストリームの最小ＡＴＣ時間をＴＤＵＲＡＴＩＯＮとすると、最大エクステントＡＴＣ時間を次のように定義する。
ＴＭＡＸ＿ＴＥＸＴ≧（ＴＭＩＮ＿ＴＥＸＴ×ＴＤＵＲＡＴＩＯＮ）／（ＴＤＵＲＡＴＩＯＮ−ＭＩＮ＿ＴＥＸＴ）…（７２）
図７９下段にその根拠を書いている。ＡＶストリームを先頭から最小エクステントＡＴＣ時間でエクステント分割した場合に発生する最小エクステント時間を満たさない、終端エクステントの最大値はＭＩＮ＿ＴＥＸＴとなる。終端のＭＩＮ＿ＴＥＸＴの時間分を、最小エクステントＡＴＣ時間で分割できているエクステントに分配して、それが最大エクステントＡＴＣ時間以下になれば、端数は発生させないことができる。
図７９の例では、ＭＩＮ＿ＴＥＸＴが2秒でＴＤＵＲＡＴＩＯＮが20秒のケースでは、最大エクステントＡＴＣ時間が２．２２２秒となり、ＭＩＮ＿ＴＥＸＴが2秒でＴＤＵＲＡＴＩＯＮが30秒の場合は２．１４２秒となっている。最大エクステントＡＴＣ時間が大きくなると、エクステントサイズが大きくなるため、２Ｄ／３Ｄ再生装置に必要なバッファサイズが増えることになる。よって、ＭＡＸ＿ＴＥＸＴとＴＤＵＲＡＴＩＯＮの関係は、ジャンプパフォーマンス等のパラメータを踏まえて適度に設定する。制約の仕方としては、シームレス接続する場合のＡＶストリームのＡＴＣ時間（ＴＤＵＲＡＴＩＯＮ）を30秒以上で、ＭＡＸ＿ＴＥＸＴを２．１５秒とするなどとして、所定の規格で決めるとよい。
上記の制約を守れば、終端のエクステント群は、常にエクステントＡＴＣ最小時間を守れるため２Ｄ／３Ｄ再生装置に必要なバッファ余裕量であるＵＬ１とＵＬ２は削減できる。
バッファ余裕量ＵＬ１とＵＬ２が削減できる理由は、図７５で説明した計算方法から計算産できる。図８０はＬ／Ｒモードでのバッファ余裕量ＵＬ１とＵＬ２のサイズの計算方法をまとめている。

＜マルチアングル＞
図８１（ａ）に示すように、２Ｄ映像においてマルチアングルを実現するデータ配置として、各アングル映像を示す複数の多重化ストリーム群を、アングル毎にインターリーブ配置する方法がある。
３Ｄ映像でマルチアングルを実現する場合には、図８１（ｂ）に示すように、１つのアングルのレフトビュービデオストリームと、ライトビュービデオストリームと、デプスマップストリームとのデータブロックをインターリーブ配置したブロックを１単位として、このブロックをアングル毎にインターリーブして構成してもよい。
＜３Ｄ映像でマルチアングルを実現する他のデータ構造＞
なお、３Ｄ映像でマルチアングルを行う場合に、図８２（ｂ）に示すように、マルチアングル区間ではレフトビュービデオストリーム、ディペンデントビュービデオストリーム、及びデプスマップストリームのエクステントを別ファイルに分離させず1本の多重化ストリーム内に収めるようにしてもよい。この場合、２Ｄ再生装置で再生するためには、レフトビュービデオストリーム、ディペンデントビュービデオストリーム、及びデプスマップストリームを合わせて、ＡＶストリームのシステムレートの範囲内に収める必要がある。
このような変形例では、プレイアイテム間で、システムターゲットデコーダに転送するＡＶストリームの数が途中で切り替わるようなケースに対応するために、図８２（ａ）に示すように、各プレイアイテムに、再生するＴＳの本数を指し示すためのフラグを設ける。具体的には、３Ｄ映像を再生するために２つのＡＶストリーム（Ｌ／Ｒモードであればレフトビュービデオストリームとライトビュービデオストリーム、デプスモードであればレフトビュービデオストリームとデプスマップストリーム）を再生する非マルチアングル区間のプレイアイテム＃１、＃３には、このＴＳモードを示すフラグを２ＴＳのモードに設定し、３Ｄ映像を再生するために１つのＡＶストリームを再生するマルチアングル区間のプレイアイテム＃２には、ＴＳモードを示すフラグを１ＴＳのモードに設定する。これにより、２Ｄ／３Ｄ再生装置は、システムターゲットデコーダへの転送をフラグを使って切り替えることができる。なお、このフラグはコネクションコンディションとして追加しても良い。例えば、２ＴＳから１ＴＳへ移行するモードをコネクションコンディション「７」として設定し、１ＴＳから２ＴＳへ移行するモードをコネクションコンディション「８」として設定する。
以下、３Ｄ映像のマルチアングル再生に対応するための詳細について説明する。
＜立体視インターリーブドストリームファイル＞
マルチアングルを構成する立体視インターリーブドファイルが記録された記録領域のデータアロケーションについて説明する。
図８３の（ａ）は、マルチアングル区間において３Ｄプレイリストのプレイアイテム及びサブプレイアイテムが参照するストリームファイルを示す図である。３Ｄプレイリストのプレイアイテム及びサブプレイアイテムは、マルチアングル区間を構成することを示すマルチアングルフラグを含む。マルチアングル区間を構成するプレイアイテム及びサブプレイアイテムでは、このフラグがオンに設定されている。本図には、アングル番号１の３Ｄ映像（以下、Ａ１映像）、アングル番号２の３Ｄ映像（以下、Ａ２映像）、及びアングル番号３の３Ｄ映像（以下、Ａ３映像）の３つのアングル映像を切り替えて再生することができるマルチアングル区間のプレイアイテム及びサブプレイアイテムを含む３Ｄプレイリストを示している。
マルチアングル区間のプレイアイテムは、各アングル映像のベースビュービデオストリームを格納したストリームファイルに対応する参照クリップ情報8301、参照クリップ情報8302、及び参照クリップ情報8303を有する。サブパス・タイプが３Ｄを示すマルチアングル区間のサブプレイアイテムは、各アングル映像のディペンデントビュービデオストリームを格納したストリームファイルに対応する参照クリップ情報8304、参照クリップ情報8305、及び参照クリップ情報8306を有する。本図において各参照クリップ情報の枠内の記載は、それぞれの参照クリップ情報に対応するストリームファイルのファイル名を示している。
参照クリップ情報8301と参照クリップ情報8304とは、Ａ１映像のベースビューストリーム及びディペンデントビューストリームを指定しており、図４０（ｅ）及び図５１の説明でのべたように、再生装置は、参照クリップ情報8301及び参照クリップ情報8304で示すクリップ情報のエクステント起点を利用してＡ１映像を格納している第１ファイルＳＳ（00001.ssif）8307を再生することができる。また、参照クリップ情報8302と参照クリップ情報8305とは、Ａ２映像のベースビューストリーム及びディペンデントビューストリームを指定しており、再生装置は、参照クリップ情報8302及び参照クリップ情報8305で示すクリップ情報のエクステント起点を利用してＡ２映像を格納している第２ファイルＳＳ（00002.ssif）8308を再生することができる。さらに、参照クリップ情報8303と参照クリップ情報8306とは、Ａ３映像のベースビューストリーム及びディペンデントビューストリームを指定しており、再生装置は、参照クリップ情報8303及び参照クリップ情報8306で示されるクリップ情報のエクステント起点を利用してＡ３映像を格納している第３ファイルＳＳ（00002.ssif）8309を再生することができる。
図８３の（ｂ）は、第１ファイルＳＳ8307、第２ファイルＳＳ8308、及び第３ファイルＳＳ8309の記録媒体１００上での物理的な配置を示している。
第１ファイルＳＳ8307のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8301及び参照クリップ情報8304が示すクリップ情報のエントリマップにおいてis＿angle＿changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A1、D[1]A1、…、ベースビューデータブロックB[0]A1、B[1]A1…に分割されており、D[n]A1とB[n]A1とが第１ファイルＳＳ8307の「インターリーブユニット」A1[n] （n＝0、1、…）をなしている。インターリーブユニットA1[n]は、第１ファイルＳＳ8307のｎ番目のエクステントとしてアクセス可能である。
第２ファイルＳＳ8308のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8302及び参照クリップ情報8305が示すクリップ情報のエントリマップにおいてis＿angle＿changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A2、D[1]A2、…、ベースビューデータブロックB[0]A2、B[1]A2…に分割されており、D[n]A2とB[n]A2とが第２ファイルＳＳ8308のインターリーブユニットA2[n]をなしている。インターリーブユニットA2[n]は、第２ファイルＳＳ8308のｎ番目のエクステントとしてアクセス可能である。
第３ファイルＳＳ8309のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8303及び参照クリップ情報8306が示すクリップ情報のエントリマップにおいてis＿angle＿changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A3、D[1]A3、…、ベースビューデータブロックB[0]A3、B[1]A3…に分割されており、D[n]A3とB[n]A3とが第３ファイルＳＳ8309のインターリーブユニットA3[n]をなしている。インターリーブユニットA3[n]は、第３ファイルＳＳ8309のｎ番目のエクステントとしてアクセス可能である。
本図の最下段に示すように、これらのインターリーブユニット群は、記録媒体１００上のトラックに沿って連続的に記録されている。更に、Ａ１のインターリーブユニットA1[0]、A1[1]、…、Ａ２のインターリーブユニットA2[0]、A2[1]、…、及びＡ３のインターリーブユニットA3[0]、A3[1]、…が、Ａ１映像、Ａ２映像、Ａ３映像の順で、一つずつ交互に配置されている。
図８４は、図８３に示すように第１ファイルＳＳ8307、第２ファイルＳＳ8308、及び第３ファイルＳＳ8309が配置された記憶領域における再生経路を説明する図である。
以下、マルチアングル区間の途中でアングル番号１からアングル番号３に再生するアングル映像が切り替えられる場合を例に説明する。
２Ｄ再生モードでは、先ずアングル番号１の映像として、第１ファイルＳＳ8307の最初のインターリーブユニットA1[0]を構成するベースビューデータブロックB[0]A1が読み出されるが、その再生中にアングル番号が３に切り替えられることで、B[0]A1の終端から第３ファイルＳＳ8309においてアングル切り替えが可能なインターリーブユニットA3[1]のベースビューデータブロックB[1]A3先頭までジャンプが発生し、このB[1]A3が読み出されることになる。
３Ｄ再生モードでは、先ずアングル番号１の映像として、第１ファイルＳＳ8307の最初のインターリーブユニットA1[0]を構成するディペンデントビューデータブロックD[0]A1及びベースビューデータブロックB[0]A1が連続して読み出されるが、その再生中にアングル番号が３に切り替えられることで、B[0]A1の終端から第３ファイルＳＳ8309においてアングル切り替えが可能なインターリーブユニットA3[1]のディペンデントビューデータブロックD[1]A3先頭までジャンプが発生し、このディペンデントビューデータブロックD[1]A3と続くベースビューデータブロックB[1]A3とが読み出されることになる。
以上のように、アングル番号の設定に応じて、異なるアングル映像のベースビュービデオストリーム及びディペンデントビュービデオストリームが再生装置に読み出されることになる。

＜変形例＞
（A）本発明の実施形態１は、記録媒体に３Ｄ映像を格納するときのエクステントの配置に関する。しかし、本発明は、記録媒体に高フレームレートの映像を格納するときに利用されても良い。具体的には、例えば高フレームレートの映像を奇数番目のフレーム群と偶数番目のフレーム群とに分け、それぞれをベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとみなして、上記の実施形態１によるエクステントの配置で記録媒体に記録すればよい。通常のフレームレートでの映像再生のみが可能な再生装置は、その記録媒体からは奇数番目のフレーム群の映像を再生すればよい。一方、高フレームレートでの映像再生が可能な再生装置は、奇数番目のフレーム群のみの映像と両方のフレーム群の映像とを選択的に再生できる。こうして、高フレームレートの映像が格納された記録媒体に、通常のフレームレートでの映像再生のみが可能な再生装置に対する互換性を確保させることができる。

（B）本発明の実施形態１では、ベースビュー・ビデオ・ストリームがレフトビューを表し、ディペンデントビュー・ビデオ・ストリームがライトビューを表す。逆に、ベースビュー・ビデオ・ストリームがライトビューを表し、ディペンデントビュー・ビデオ・ストリームがレフトビューを表してもよい。

（C）図３９の（ａ）に示されているオフセット・テーブル3141は、ＰＩＤ別にオフセット・エントリ3304のテーブル3310を含む。オフセット・テーブルはその他に、プレーン別にオフセット・エントリのテーブルを含んでもよい。その場合、３Ｄ再生装置によるオフセット・テーブルの解析処理を簡素化することができる。更に、プレーンの合成処理に関する３Ｄ再生装置の性能に合わせて、オフセット・エントリの有効区間の長さに、例えば１秒間という下限が設けられてもよい。

（D）図４８に示されている３Ｄプレイリスト・ファイルは、サブＴＳの再生経路を示すサブパスを一つ含む。その他に、３Ｄプレイリスト・ファイルが、異なるサブＴＳの再生経路を示すサブパスを複数含んでもよい。例えば、一方のサブパスのサブパス・タイプが「３Ｄ・Ｌ／Ｒ」であり、他方のサブパスのサブパス・タイプが「３Ｄ・デプス」であってもよい。その３Ｄプレイリスト・ファイルに従って３Ｄ映像が再生されるとき、再生対象のサブパスがそれら二種類のサブパスの間で切り換えられることにより、再生装置２００をＬ／Ｒモードとデプス・モードとの間で容易に切り換えさせることができる。特にその切り換え処理は、３Ｄプレイリスト・ファイルそのものを切り換える処理よりも速やかに実現可能である。
３Ｄプレイリスト・ファイルは、サブパス・タイプの等しいサブパスを複数含んでいてもよい。例えば、同じシーンに対する両眼視差の異なる３Ｄ映像が共通のレフトビューに対するライトビューの違いで表現されるとき、異なるライトビュー・ビデオ・ストリームごとに異なるファイルＤＥＰが記録媒体１００に記録される。一方、３Ｄプレイリスト・ファイルは、サブパス・タイプが「３Ｄ・Ｌ／Ｒ」であるサブパスを複数含む。それらのサブパスは、異なるファイルＤＥＰの再生経路を個別に規定する。その他に、一つのファイル２Ｄに対してデプスマップ・ストリームが二種類以上含まれていてもよい。その場合、３Ｄプレイリスト・ファイルは、サブパス・タイプが「３Ｄ・デプス」であるサブパスを複数含む。それらのサブパスは、各デプスマップ・ストリームを含むファイルＤＥＰの再生経路を個別に規定する。そのような３Ｄプレイリスト・ファイルに従って３Ｄ映像が再生されるとき、再生対象のサブパスが例えばユーザの操作に応じて速やかに切り換えられるので、３Ｄ映像を実質的に途切れさせることなく、その両眼視差を変化させることができる。それにより、ユーザに所望の両眼視差の３Ｄ映像を容易に選択させることができる。

（E）リード・バッファからシステム・ターゲット・レコーダへのデータの平均転送速度Rextの評価においてエクステントＡＴＣ時間が正確に計算されることを目的として、各エクステントのサイズがソースパケット長のある一定の倍数に揃えられてもよい。更に、いずれかのエクステントがその倍数よりも多くのソースパケットを含むとき、その倍数を超えたソースパケット数とソースパケット一つ当たりの転送時間（＝１８８×８／システムレート）との積を、その倍数に相当するエクステントＡＴＣ時間に加えた値が、そのエクステントのエクステントＡＴＣ時間とみなされても良い。その他に、エクステントＡＴＣ時間は、一つのエクステントの先頭のソースパケットのＡＴＳから同じエクステントの最後のソースパケットのＡＴＳまでの時間間隔にソースパケット一つ当たりの転送時間を加えた値で定義されてもよい。その場合、エクステントＡＴＣ時間の計算には次のエクステントの参照が不要であるので、その計算を簡単化することができる。尚、上記のエクステントＡＴＣ時間の計算では、ＡＴＳにラップ・アラウンドが発生することを考慮しなければならない。

（F）インターリーブ配置のデータ・ブロック群の中には、例えばＢＤ−Ｊオブジェクト・ファイル等、別のファイルに属するエクステントが配置されてもよい。図８６の（ａ）は、多重化ストリーム・データのみを含むインターリーブ配置のデータ・ブロック群を示す模式図である。図８６の（ｂ）は、他のファイルに属するエクステントを含むインターリーブ配置のデータ・ブロック群を示す模式図である。
図８６の（ａ）を参照するに、データ・ブロック群6201は、デプスマップ・データ・ブロックD1、D2、D3、ライトビュー・データ・ブロックR1、R2、R3、ベースビュー・データ・ブロックL1、L2、L3を交互に含む。Ｌ／Ｒモードでの再生経路6202では、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1＋L1、R2＋L2、R3＋L3が順番に読み出される。各対ではライトビュー・データ・ブロックとベースビュー・データ・ブロックとの間にゼロ・セクタ遷移J0が生じる。更に各デプスマップ・データ・ブロックD1、D2、D3の読み出しがジャンプJLRによってスキップされる。デプス・モードでの再生経路6203では、デプスマップ・データ・ブロックD1、D2、D3とベースビュー・データ・ブロックL1、L2、L3とが交互に読み出される。隣接するベースビュー・データ・ブロックとデプスマップ・データ・ブロックとの間にはゼロ・セクタ遷移J0が生じる。更に各ライトビュー・データ・ブロックR1、R2、R3の読み出しがジャンプJLDによってスキップされる。
一方、図８６の（ｂ）を参照するに、図８６の（ａ）と同様なデータ・ブロック群6204の中に、別のファイルに属するエクステントA1、A2が挿入されている。その別のファイルは、例えばムービーオブジェクト・ファイル、ＢＤ−Ｊオブジェクト・ファイル、及びＪＡＲファイルのいずれでもよい。そのエクステントA1、A2はいずれも、図８６の（ａ）では隣接していたデプスマップ・データ・ブロックとライトビュー・データ・ブロックとの間に挿入されている。その場合、Ｌ／Ｒモードでの再生経路6205では、図８６の（ａ）に示されている再生経路6202よりもジャンプJLRの距離が長い。しかし、そのエクステントA1、A2をいずれかのベースビュー・データ・ブロックの隣に挿入する場合とは異なり、ゼロ・セクタ遷移J0を通常のジャンプに変更しなくてもよい。デプス・モードでの再生経路6206でも同様である。ここで、図６４の表から明らかなとおり、最大ジャンプ時間は一般に、ジャンプ距離を変更するときよりも、ゼロ・セクタ遷移を通常のジャンプに変更するときの方が大きく増加する。従って、式（２）−（５）から明らかなとおり、最小エクステント・サイズは一般に、ジャンプ距離を変更するときよりも、ゼロ・セクタ遷移を通常のジャンプに変更するときの方が大きく増加する。それ故、インターリーブ配置のデータ・ブロック群6201の中にエクステントA1、A2を挿入するときは、図８６の（ｂ）に示されているように、デプスマップ・データ・ブロックとライトビュー・データ・ブロックとの間に挿入する。それにより、その挿入に伴う最小エクステント・サイズの増大を抑えることができるので、リード・バッファの最小容量の増大を回避することができる。
図８６の（ｂ）に示されている配置では更に、各エクステントA1、A2のセクタ単位でのサイズG1、G2が最大ジャンプ距離MAX＿EXTJUMP3D以下に制限されてもよい：G1≦MAX＿EXTJUMP3D、G2≦MAX＿EXTJUMP3D。その最大ジャンプ距離MAX＿EXTJUMP3Dは、データ・ブロック群6204内で生じるジャンプJLR、JLDの中で最大のジャンプ距離をセクタ単位で表す。その制限の下では、式（２）−（５）の右辺に代入されるべき最大ジャンプ時間が増大しにくいので、最小エクステント・サイズが増大しにくい。従って、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を回避することができる。
その他に、各エクステントA1、A2のサイズG1、G2とそれに隣接するディペンデントビュー・データ・ブロックD2、R2、D3、R3のサイズSext3[2]、Sext2[2]、Sext3[3]、Sext2[3]との和が最大ジャンプ距離MAX＿EXTJUMP3D以下に制限されてもよい：
CEIL(Sext3[2]／2048)＋G1≦MAX＿EXTJUMP3D、
CEIL(Sext2[2]／2048)＋G1≦MAX＿EXTJUMP3D、
CEIL(Sext3[3]／2048)＋G2≦MAX＿EXTJUMP3D、
CEIL(Sext2[3]／2048)＋G2≦MAX＿EXTJUMP3D。
これらの式では、ディペンデントビュー・データ・ブロックのバイト単位でのサイズを１セクタ当たりのバイト数２０４８で割ることにより、各サイズの単位をバイトからセクタ数に変換している。これらの条件式が満たされている限り、式（２）−（５）の右辺に代入されるべき最大ジャンプ時間は一定値を超えない。例えば最大ジャンプ距離MAX＿EXTJUMP3Dを４００００セクタに固定した場合、図６４の表から最大ジャンプ時間は３５０ｍ秒を超えない。従って、最小エクステント・サイズは一定値を超えない。こうして、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を確実に回避することができる。
上記の制限とは更に別に、各エクステントA1、A2のサイズG1、G2とそれに隣接するディペンデントビュー・データ・ブロックD2、R2、D3、R3のサイズSext3[2]、Sext2[2]、Sext3[3]、Sext2[3]との和が、そのディペンデントビュー・データ・ブロックのサイズに対する最大ジャンプ距離MAX＿JUMP(・)以下に制限されてもよい：
CEIL(Sext3[2]／2048)＋G1≦MAX＿JUMP(Sext3[2])、
CEIL(Sext2[2]／2048)＋G1≦MAX＿JUMP(Sext2[2])、
CEIL(Sext3[3]／2048)＋G2≦MAX＿JUMP(Sext3[3])、
CEIL(Sext2[3]／2048)＋G2≦MAX＿JUMP(Sext2[3])。
ディペンデントビュー・データ・ブロックのサイズに対する最大ジャンプ距離MAX＿JUMP(・)とは、そのサイズをセクタ数で表したとき、図６４の表において、そのセクタ数と同じ最大ジャンプ時間に対応するセクタ数の中での最大値をいう。例えばディペンデントビュー・データ・ブロックのサイズが５０００セクタであるとき、図６４の表において５０００セクタは、最大ジャンプ時間２５０ｍ秒に対応する範囲１−１００００セクタに属する。従って、最大ジャンプ距離MAX＿JUMP(５０００×２０４８バイト)はその範囲の最大値１００００セクタである。上記の条件式が満たされている限り、式（２）−（５）の右辺に代入されるべき最大ジャンプ時間は変更されないので、最小エクステント・サイズは不変である。従って、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を更に確実に回避することができる。
（インターリーブされたエクステント間にＡＶストリーム以外のファイルの配置）
次に、インターリーブされたエクステント間にＡＶストリームとは別のファイル（例えばＢＤプログラムファイルなど）を格納するために好適なエクステントの配置方法の詳細について説明する。
図８７上段は、ＡＶストリームのエクステントが連続して配置されるケースを示している。この場合には、２Ｄ／３Ｄ再生装置のＬ／Ｒモードの再生経路の場合には、ＥＸＴ２［ｎ］とＥＸＴ１［ｎ］が連続しているため、この間のエクステントの遷移時間は０セクタのジャンプ（ＴＪＵＭＰ０）となる。２Ｄ／３Ｄ再生装置のデプスモードの再生経路の場合には、ＥＸＴ１［ｎ］とＥＸＴ３［ｎ＋１］が連続しているため、この間のエクステントの遷移時間は０セクタのジャンプ（ＴＪＵＭＰ０）となる。前述したように、ＴＪＵＭＰ０の区間は、ドライブは連続的にエクステントを読み込みことによって高速に読み込めるため、ＴＪＵＭＰ０の時間は図６４のように他のジャンプ時間に比べて小さい値になる。
しかし、ＡＶストリームのエクステントが配置される区間においても、ＡＶストリーム以外の別ファイル（例えば、ＢＤプログラムファイルなど）を配置するケースがあるため、図８７上段のようにすべてのエクステントを連続して配置することができないケースがある。この場合には、エクステントの合間にＡＶストリーム以外の別ファイルを配置する必要がある。
図８７中段のように、ＥＸＴ１［ｎ］とＥＸＴ３［ｎ］の間にＡＶストリーム以外の別ファイルを配置した場合には、ＥＸＴ２［ｎ］とＥＸＴ１［ｎ］の間は連続するが、ＥＸＴ１［ｎ］とＥＸＴ３［ｎ＋１］の間は連続しなくなる。この場合、２Ｄ／３Ｄ再生装置のＬ／Ｒモードの再生経路ではＥＸＴ２［ｎ］とＥＸＴ１［ｎ］が連続することでＴＪＵＭＰ０でエクステントの遷移を行えるが、２Ｄ／３Ｄ再生装置のデプスモードの再生経路ではエクステントが連続する区間（ＴＪＵＭＰ０）がなくなるため、Ｌ／Ｒプレーヤの再生経路よりも多くのジャンプ時間が必要となる。
ここで、２Ｄ／３Ｄ再生装置がシームレスに再生するための最小エクステントサイズは、ＳＥＸＴ１［ｎ］については式（２）と式（４）、ＳＥＸＴ２［ｎ］については式（３）、ＳＥＸＴ３［ｎ］については式（５）を満たすサイズにする必要がある。図８７中段のようなエクステントの配置では、式（４）と式（５）のＴＪＵＭＰ０の値が増加するため、ＳＥＸＴ１［ｎ］、ＳＥＸＴ３［ｎ］の最小エクステントサイズが大きくなってしまう。エクステントサイズが大きくなると、式（１０）から式（１２）までの式に示すように２Ｄ／３Ｄ再生装置に必要なバッファサイズが増えることとなってしまう。
そこで、ＡＶストリームのエクステント群の間にＡＶストリーム以外の別ファイルを配置する場合には、図８７下段のようにＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置する（ＥＸＴ２［ｎ］とＥＸＴ１［ｎ］とＥＸＴ３［ｎ＋１］は連続して配置する）。このような配置を行うことによって、２Ｄ／３Ｄ再生装置のＬ／Ｒモードの再生経路ではＥＸＴ２［ｎ］とＥＸＴ１［ｎ］が連続することでドライブはＴＪＵＭＰ０でエクステントの遷移を行うことができ、２Ｄ／３Ｄ再生装置のデプスモードの再生経路においても、ＥＸＴ１［ｎ］とＥＸＴ３［ｎ＋１］が連続することでドライブはＴＪＵＭＰ０でエクステントの遷移を行うことができる。これによって、式（２）、式（３）、式（４）、式（５）に出てくるＴＪＵＭＰ０の値を小さくすることができるため、図８７中段のような配置に比べて最小エクステントサイズを小さくすることが可能であり、つまりは２Ｄ／３Ｄ再生装置に必要なバッファサイズを図８７中段のような配置に比べて抑制することができる。
なお、インターリーブされたＡＶストリームのエクステント群の間に、ＡＶストリーム以外の別ファイルを配置する場合には、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置するとした場合の、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置できるファイルのサイズを次の式のように制約してもよい。
ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（７３）
ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（７４）

図８８に示すように、ＥＸＴ３［ｎ］の終端とＥＸＴ２［ｎ］の先頭までの間隔をＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）（単位：ブロック数）とし、ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ（単位：ブロック数）はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することで、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間隔が大きくなりすぎることによって、式（２）、（３）、（４）、（５）に代入されるＴＪＵＭＰの値が増加し、エクステントサイズが大きくなりすぎることを防ぐことができる。
なお、インターリーブされたＡＶストリームのエクステント群の間に、ＡＶストリーム以外の別ファイルを配置する場合には、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置するとした場合の、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置できるファイルのサイズを次の式のように制約してもよい。
ＣＥＩＬ（ＳＥＸＴ３［ｎ］／２０４８）＋ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（７５）

ＣＥＩＬ（ＳＥＸＴ２［ｎ］／２０４８）＋ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（７６）

図８８に示すように、ＥＸＴ３［ｎ］の終端とＥＸＴ２［ｎ］の先頭までの間隔をＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）（単位：ブロック数）とし、ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ（単位：ブロック数）はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することによって、式（７３）、（７４）に比べて最小エクステントのサイズを効果的に制約できる。例えば、ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄを１００００ブロックとした場合、式（７３）、（７４）の場合は、ＳＥＸＴ３［ｎ］、ＳＥＸＴ２［ｎ］の値によって、エクステント間のジャンプ距離は、１００００を超えるケースが発生するため、ＴＪＵＭＰの値が増加してしまい、図６４の例で言えば２５０ｍｓとなってしまう。ところが、式（７５）、（７６）のように定義することで、エクステント間の最大ジャンプ距離を、固定化することができ、例えばＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄを１００００ブロックとした場合には、ＴＪＵＭＰに入る値は常に一定の固定値を超えない。（図６４でいえば２５０ｍｓを超えない）
なお、インターリーブされたＡＶストリームのエクステント群の間に、ＡＶストリーム以外の別ファイルを配置する場合には、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置するとした場合の、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］の間に配置できるファイルのサイズを次の式のように制約してもよい。
ＣＥＩＬ（ＳＥＸＴ３［ｎ］／２０４８）＋ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ ＭＡＸ＿ＪＵＭＰ（ＳＥＸＴ３［ｎ］） …（７７）
ＣＥＩＬ（ＳＥＸＴ２［ｎ］／２０４８）＋ＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）＜＝ ＭＡＸ＿ＪＵＭＰ（ＳＥＸＴ２［ｎ］） …（７８）

図８８に示すように、ＥＸＴ３［ｎ］の終端とＥＸＴ２［ｎ］の先頭までの間隔をＧＡＰ（ＥＸＴ３［ｎ］，ＥＸＴ２［ｎ］）（単位：ブロック数）とし、ＭＡＸ＿ＪＵＭＰ（ＳＥＸＴ３［ｎ］）はＳＥＸＴ３［ｎ］の距離をジャンプする時間でジャンプできる最大ジャンプ距離（単位：ブロック数）とし、ＭＡＸ＿ＪＵＭＰ（ＳＥＸＴ２［ｎ］）はＳＥＸＴ２［ｎ］の距離をジャンプする時間でジャンプできる最大ジャンプ距離とする（単位：ブロック数）。例えば、ＳＥＸＴ３［ｎ］が５０００×２０４８（Ｂｙｔｅ）の場合に、このエクステントをジャンプする時間は図６４の例では２５０ｍｓである。この場合、ＭＡＸ＿ＪＵＭＰ（ＳＥＸＴ３［ｎ］）は、図６４の表により、２５０ｍｓで飛べる最大ジャンプ距離である１００００ブロックとなる。式（７７）、（７８）のように規定することにより、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］間の間隔によって式（２）、（３）、（４）、（５）におけるＴＪＵＭＰの値は変動しないため最小エクステントサイズの大きさを、式（７５）、（７６）に比べて効率的に小さく抑制することが可能である。
なお、インターリーブされたＡＶストリームのエクステントについてのサイズ制限として、ＥＸＴ３［ｎ］とＥＸＴ２［ｎ］のサイズに次の式のような制約を加え、インターリーブ区間でのギャップは認めないとしても良い。
ＣＥＩＬ（ＳＥＸＴ３［ｎ］／２０４８）＜＝ ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（７９）
ＣＥＩＬ（ＳＥＸＴ２［ｎ］／２０４８）＜＝ ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ …（８０）
図８８に示すように、ＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄ（単位：ブロック数）はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することによって、エクステント間の最大ジャンプ距離を、固定化することができ、例えばＭＡＸ＿ＥＸＴＪＵＭＰ３Ｄを１００００ブロックとした場合には、ＴＪＵＭＰに入る値は常に一定の固定値を超えない。（図６４でいえば２５０ｍｓを超えない）

＜実施形態２＞
実施形態１では、図５４に示すように第１リード・バッファ4921と第２リード・バッファ4922の二つのバッファを利用して、ストリームデータをシステムターゲットデコーダに入力するとしたが、本実施形態２では、１つのリードバッファのみ利用して３Ｄ映像再生を実現する構成について説明する。
具体的には、図８９のようにリードバッファ（１）3707の１つのバッファにして、システムターゲットデコーダ３７０３に入力し、図９０に示すようにリードバッファ（１）3707からソースデパケタイザ（１）４１１１とソースデパケタイザ（２）４１１２に入力するように構成する。
このような構成にすることによって、２Ｄ／３Ｄ再生装置が３Ｄ映像の再生に必要なリードバッファのサイズを小さくすることが可能となる。
図９１上段は、第１リード・バッファ4921と第２リード・バッファ4922の二つのバッファを利用する場合の、第１リード・バッファ4921の３Ｄ映像再生時のデータ蓄積量の推移を示している。図９１中段は、第１リード・バッファ4921と第２リード・バッファ4922の二つのバッファを利用する場合の、第２リード・バッファ4922の３Ｄ映像再生時のデータ蓄積量の推移を示している。図９１上段の第１リード・バッファ4921の頂点と、図９１上段の第２リード・バッファ4922の頂点はかさならないため、第１リード・バッファ4921にＥＸＴ１［ｎ］とＥＸＴ２［ｎ］（もしくはＥＸＴ３［ｎ］）を入れると、図９１下段の線９６０１のように、二つのリードバッファを設けるよりもバッファサイズを小さくすることが可能である。
この場合、第１リード・バッファ4921からの転送レートは、第１リード・バッファ4921に入力されるＡＶストリームの合計システムレート×１９２／１８８のレートが必要となる。図９２上段は、リードバッファを１つの構成にした場合のリードバッファ（１）3707の内部に蓄積されるデータの推移を模式的に示した図である。図９２上段は、Ｌ／Ｒモードで再生する場合のデータの推移を示している。また、各箱はリードバッファ（１）3707を示す。９７０１は、図９２下段の３Ｄエクステントブロックの先頭エクステントであるＥＸＴ２［０］を読み込みした時点（Ａ地点）でのリードバッファ（１）3707内部に蓄積されるデータを示す。先頭ＥＸＴ２［０］を読み込む時点では、システムターゲットデコーダ３７０３への転送は開始されないため、ＥＸＴ２［０］のデータがそのままバッファに蓄積される。９７０２は、ＥＸＴ１［０］を読み込み中（Ｂ地点）のリードバッファ（１）3707内部に蓄積されるデータを示す。システムターゲットデコーダ３７０３への転送を開始する場合には、リードバッファ（１）3707内のＥＸＴ２［０］のデータはシステムターゲットデコーダ３７０３への転送とともに減少し、また、ＥＸＴ１［０］のデータはリードバッファ（１）3707に蓄えられると同時に、システムターゲットデコーダ３７０３への転送とともに減少していく。９７０３は、ＥＸＴ１［０］を読み込み完了地点（Ｃ地点）のリードバッファ（１）3707内部に蓄積されるデータを示す。９７０４は、ＥＸＴ２［１］を読み込み中（Ｄ地点）のリードバッファ（１）3707内部に蓄積されるデータを示す。リードバッファ（１）3707内のＥＸＴ１［０］のデータはシステムターゲットデコーダ３７０３への転送とともに減少し、また、ＥＸＴ２［１］のデータはリードバッファ（１）3707に蓄えられると同時に、システムターゲットデコーダ３７０３への転送とともに減少していく。このようにリードバッファ（１）3707を制御することで、リードバッファ（１）3707の１つのバッファで実現できる。
ここで、システムターゲットデコーダ３７０３への転送は、前述したようにソースパケットに付与されたＡＴＳのタイミングで行われる。よって、リードバッファ（１）3707に二つのＡＶストリームを入力した場合に、同じＡＴＳが付与されたソースパケットが入力された場合には、リードバッファ（１）3707からシステムターゲットデコーダ３７０３への二つのソースパケットの転送を同時刻に行うことはできないため、ＡＴＳのタイミングでシステムターゲットデコーダ３７０３への転送ができなくなってしまう。例えば、ＡＴＳ＝１００が付与された２Ｄ／左目ＡＶストリームのソースパケットと、例えば、ＡＴＳ＝１００が付与されたファイルＤＥＰのストリームのソースパケットが存在した場合に、ＡＴＳ＝１００の２Ｄ／左目ＡＶストリームのソースパケットを先に転送してしまうと、ＡＴＳ＝１００のファイルＤＥＰのストリームのソースパケットは、ＡＴＳ＋１ソースパケットの転送時間分ずれて、システムターゲットデコーダのソースデパケタイザ（２）４１１２に転送されることとなり、システムターゲットデコーダ３７０３のデコード処理にバッファアンダーフローなどの問題が発生する可能性がある。
そこで、図９３上段に示すようにＡＶストリーム内のソースパケットのＡＴＳを設定する。図９３上段は、２Ｄ／左目ＡＶストリームとファイルＤＥＰのストリームのソースパケット列を示しており、ソースパケットをＡＴＣ時間で並べている。ＳＰ＃Ｎは、各ソースパケットを示し、添え字のＮはＡＶストリームの先頭ソースパケットを０としてインクリメントされる番号である。また各ソースパケットの先頭に付与される矢印はＡＴＳのタイミングを示す。また、各ソースパケットの箱の大きさは、２Ｄ／３Ｄ再生装置が、各ソースパケットをシステムターゲットデコーダへの転送時間（以降、「３Ｄソースパケット転送時間９８０１」とする）を示す。また、矢印９８０１は、２Ｄ／３Ｄ再生装置の１ソースパケットのリードバッファ（１）3707からシステムターゲットデコーダへの転送時間を示し、矢印９８０２は、２Ｄ再生装置の１ソースパケットのリードバッファからシステムターゲットデコーダへの転送時間（以降、「２Ｄソースパケット転送時間９８０２」とする）を示す。
図９３上段に示すように、２Ｄ／左目ＡＶストリームの隣接するソースパケットのＡＴＳの間隔は、２Ｄソースパケット転送時間９８０２以上あけなければならない。この制約を守らなければ、２Ｄ再生装置のシステムターゲットデコーダへの転送が間に合わなくなってしまうからである。図９３下段の例では、２Ｄ／左目ＡＶストリームのＳＰ＃０とＳＰ＃１のＡＴＳの間隔は、２Ｄ再生装置の１ソースパケットのリードバッファからシステムターゲットデコーダへの転送時間よりも小さいためＮＧである。また、ファイルＤＥＰのストリームのソースパケットのＡＴＳからそのＡＴＳに３Ｄソースパケット転送時間９８０１を加えたＡＴＣ時間までの間隔は、２Ｄ／左目ＡＶストリームのソースパケットのＡＴＳからそのＡＴＳに３Ｄソースパケット転送時間９８０１を加えたＡＴＣ時間までの間隔は、オーバラップしてはいけない。図９３下段のファイルＤＥＰのストリームのＳＰ＃２と２Ｄ／左目ＡＶストリームのＳＰ＃３はＮＧのケースとなる。
このような制約を守ってＡＶストリームを構成することにより、同じＡＴＳが付与された二つのソースパケットが１つのリードバッファ（１）3707に入力されることを防ぐことが可能となる。

《実施形態３》
以下、本発明の実施形態３として、本発明の実施形態１による記録媒体の記録装置及び記録方法について説明する。
その記録装置はいわゆるオーサリング装置と呼ばれるものである。オーサリング装置は通常、頒布用の映画コンテンツの制作スタジオに設置され、オーサリングスタッフによって使用される。記録装置はオーサリングスタッフの操作に従い、まず映画コンテンツを、ＭＰＥＧ規格に則った圧縮符号化方式のデジタル・ストリーム、すなわちＡＶストリーム・ファイルに変換する。記録装置は次にシナリオを生成する。シナリオは、映画コンテンツに含まれる各タイトルの再生方法を規定した情報であり、具体的には上記の動的シナリオ情報及び静的シナリオ情報を含む。記録装置は続いて、上記のデジタル・ストリーム及びシナリオから、ＢＤ−ＲＯＭディスク用のボリュームイメージ又はアップデートキットを生成する。記録装置は最後に、実施形態１によるエクステントの配置を利用して、ボリュームイメージを記録媒体に記録する。
図９３は、その記録装置の内部構成を示すブロック図である。図９３を参照するに、その記録装置は、ビデオエンコーダ6301、素材制作部6302、シナリオ生成部6303、ＢＤプログラム制作部6304、多重化処理部6305、フォーマット処理部6306、及びデータベース部6307を含む。
データベース部6307は記録装置に内蔵の不揮発性記憶装置であり、特にハードディスクドライブ（ＨＤＤ）である。データベース部6307はその他に、記録装置に外付けされたＨＤＤであってもよく、記録装置に内蔵の、又は外付けされた不揮発性半導体メモリ装置であってもよい。
ビデオエンコーダ6301は、非圧縮のビットマップ・データ等の映像データをオーサリングスタッフから受け付けて、それをＭＰＥＧ−４ ＡＶＣ又はＭＰＥＧ−２等の圧縮符号化方式で圧縮する。それにより、主映像のデータはプライマリ・ビデオ・ストリームに変換され、副映像のデータはセカンダリ・ビデオ・ストリームに変換される。特に３Ｄ映像のデータはベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとに変換される。ビデオエンコーダ6301は、レフトビュー・ビデオ・ストリームをそれ自身のピクチャ間での予測符号化によってベースビュー・ビデオ・ストリームに変換し、ライトビュー・ビデオ・ストリームを、それ自身のピクチャだけでなく、ベースビュー・ビデオ・ストリームのピクチャとの間の予測符号化によってディペンデントビュー・ビデオ・ストリームに変換する。尚、ライトビュー・ビデオ・ストリームがベースビュー・ビデオ・ストリームに変換されてもよい。更に、レフトビュー・ビデオ・ストリームがディペンデントビュー・ビデオ・ストリームに変換されてもよい。変換後の各ビデオ・ストリーム6311はデータベース部6307に保存される。
ビデオエンコーダ6301は更に、このピクチャ間予測符号化の処理過程で、左映像と右映像との間での各イメージの動きベクトルを検出し、それらから３Ｄ映像内の各イメージの奥行き情報を算出する。算出された各イメージの奥行き情報はフレーム奥行き情報6310に整理されてデータベース部6307に保存される。
図９４の（ａ）、（ｂ）は、３Ｄ映像の一シーンの表示に利用される左映像ピクチャと右映像ピクチャとを表す模式図であり、（ｃ）は、ビデオエンコーダ6301によってそれらのピクチャから算出された奥行き情報を示す模式図である。
ビデオエンコーダ6301はまず、左右のピクチャ間の冗長性を利用して各ピクチャを圧縮する。そのとき、ビデオエンコーダ6301は圧縮前の左右のピクチャを８×８又は１６×１６の画素マトリクスごとに、すなわちマクロブロックごとに比較して、両ピクチャ間での各イメージの動きベクトルを検出する。具体的には、図９４の（ａ）、（ｂ）に示されているように、まず、左映像ピクチャ6401と右映像ピクチャ6402とはそれぞれ、マクロブロック6403のマトリクスに分割される。次に、両ピクチャ6401、6402間でイメージ・データがマクロブロック6403ごとに比較され、その結果から各イメージの動きベクトルが検出される。例えば「家」のイメージ6404を表す領域は両ピクチャ6401、6402間で実質的に等しい。従って、それらの領域からは動きベクトルが検出されない。一方、「球」のイメージ6405を表す領域は両ピクチャ6401、6402間で実質的に異なる。従って、それらの領域からは、「球」のイメージ6405の変位を表す動きベクトルが検出される。
ビデオエンコーダ6301は次に、検出された動きベクトルを各ピクチャ6401、6402の圧縮に利用する一方、各イメージ・データ6404、6405の表す映像の両眼視差の計算にも利用する。こうして得られた両眼視差から、ビデオエンコーダ6301は更に、「家」及び「球」のイメージ6404、6405等、各イメージの「奥行き」を算出する。各イメージの奥行きを表す情報は、例えば図９４の（ｃ）に示されているように、各ピクチャ6401、6402のマクロブロックのマトリクスと同じサイズのマトリクス6406に整理される。図９３に示されているフレーム奥行き情報6310はこのマトリクス6406を含む。このマトリクス6406内のブロック6407は、各ピクチャ6401、6402内のマクロブロック6403と一対一に対応する。各ブロック6407は、対応するマクロブロック6403の表すイメージの奥行きを、例えば８ビットの深度で表す。図９４に示されている例では、「球」のイメージ6405の奥行きが、マトリクス6406の領域6408内の各ブロックに記録される。その領域6408は、そのイメージ6405を表す各ピクチャ6401、6402内の領域の全体に対応する。
図９３を再び参照するに、素材制作部6302は、ビデオ・ストリーム以外のエレメンタリ・ストリーム、例えば、オーディオ・ストリーム6312、ＰＧストリーム6313、及びＩＧストリーム6314を作成してデータベース部6307に保存する。例えば、素材制作部6302はオーサリングスタッフから非圧縮のＬＰＣＭ音声データを受け付けて、それをＡＣ−３等の圧縮符号化方式で符号化してオーディオ・ストリーム6312に変換する。素材制作部6302はその他に、オーサリングスタッフから字幕情報ファイルを受け付けて、それに従ってＰＧストリーム6313を作成する。字幕情報ファイルは、字幕を表すイメージ・データ、その字幕の表示時期、及び、その字幕に加えられるべきフェードイン／フェードアウト等の視覚効果を規定する。素材制作部6302は更に、オーサリングスタッフからビットマップ・データとメニューファイルとを受け付けて、それらに従ってＩＧストリーム6314を作成する。ビットマップ・データはメニューのイメージを表す。メニューファイルは、そのメニューに配置される各ボタンの状態の遷移、及び各ボタンに加えられるべき視覚効果を規定する。
シナリオ生成部6303は、オーサリングスタッフからＧＵＩ経由で受け付けられた指示に従ってＢＤ−ＲＯＭシナリオ・データ6315を作成し、データベース部6307に保存する。ＢＤ−ＲＯＭシナリオ・データ6315は、データベース部6307に保存された各エレメンタリ・ストリーム6311−6314の再生方法を規定する。ＢＤ−ＲＯＭシナリオ・データ6315は、図７に示されているファイル群のうち、インデックス・ファイル511、ムービーオブジェクト・ファイル512、及びプレイリスト・ファイル521−523を含む。シナリオ生成部6303は更にパラメータ・ファイル6316を作成して多重化処理部6305へ送出する。パラメータ・ファイル6316は、データベース部6307に保存されたエレメンタリ・ストリーム6311−6314の中から、メインＴＳとサブＴＳとのそれぞれに多重化されるべきストリーム・データを規定する。
ＢＤプログラム制作部6304はオーサリングスタッフに対して、ＢＤ−Ｊオブジェクト及びＪａｖａ(登録商標)アプリケーション・プログラムのプログラミング環境を提供する。ＢＤプログラム制作部6304はＧＵＩを通じてユーザからの要求を受け付け、その要求に従って各プログラムのソースコードを作成する。ＢＤプログラム制作部6304は更に、ＢＤ−ＪオブジェクトからＢＤ−Ｊオブジェクト・ファイル551を作成し、Ｊａｖａ(登録商標)アプリケーション・プログラムをＪＡＲファイル561に圧縮する。それらのファイル551、561はフォーマット処理部6306へ送出される。
ここで、ＢＤ−Ｊオブジェクトが次のようにプログラミングされる場合を想定する：ＢＤ−Ｊオブジェクトは、図５４、５９に示されているプログラム実行部4606、4906にＧＵＩ用のグラフィックス・データをシステム・ターゲット・デコーダ4603、4903へ送出させる。ＢＤ−Ｊオブジェクトは更に、システム・ターゲット・デコーダ4603、4903にそのグラフィックス・データをイメージ・プレーン・データとして処理させる。その場合、ＢＤプログラム制作部6304は、データベース部6307に保存されたフレーム奥行き情報6310を利用して、ＢＤ−Ｊオブジェクトにイメージ・プレーン・データに対するオフセット情報を設定してもよい。
多重化処理部6305はパラメータ・ファイル6316に従い、データベース部6307に保存されている各エレメンタリ・ストリーム6311−6314をＭＰＥＧ２−ＴＳ形式のストリーム・ファイルに多重化する。具体的には図１０に示されているように、各エレメンタリ・ストリームがソースパケット列に変換され、各列のソースパケットが一列にまとめられて一本の多重化ストリーム・データを構成する。こうして、メインＴＳとサブＴＳとが作成される。
その処理と並行して、多重化処理部6305は、２Ｄクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとを以下の手順で作成する。まず、ファイル２ＤとファイルＤＥＰとのそれぞれについて、図３９に示されているエントリ・マップ3130が生成される。次に、各ファイルのエントリ・マップを利用して、図４０に示されているエクステント起点の一覧表3310が作成される。続いて、メインＴＳとサブＴＳとのそれぞれに多重化されるべき各エレメンタリ・ストリームから、図３８に示されているストリーム属性情報が抽出される。更に、図３８に示されているように、エントリ・マップ、３Ｄメタデータ、及びストリーム属性情報の組み合わせがクリップ情報に対応付けられる。
フォーマット処理部6306は、データベース部6307に保存されたＢＤ−ＲＯＭシナリオ・データ6315、ＢＤプログラム制作部6304によって制作されたＢＤ−Ｊオブジェクト・ファイル等のプログラム・ファイル群、及び、多重化処理部6305によって生成された多重化ストリーム・データとクリップ情報ファイルとから、図７に示されているディレクトリ構造のＢＤ−ＲＯＭディスクイメージ6320を作成する。そのディレクトリ構造では、ファイルシステムとしてＵＤＦが利用される。
フォーマット処理部6306は、ファイル２Ｄ、ファイルＤＥＰ、及びファイルＳＳの各ファイル・エントリを作成するとき、２Ｄクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとのそれぞれに含まれるエントリ・マップと３Ｄメタデータとを参照する。それにより、各エントリ・ポイントと各エクステント起点とのＳＰＮが各アロケーション記述子の作成に利用される。特に図１５に示されているようなインターリーブ配置が表現されるようにアロケーション記述子が作成される。それにより、各ベースビュー・データ・ブロックはファイルＳＳとファイル２Ｄとに共有され、各ディペンデントビュー・データ・ブロックはファイルＳＳとファイルＤＥＰとに共有される。一方、ロングジャンプの必要な箇所では、図２０、２４、２６、２８、３０、３２のそれぞれに示されている配置１−６のいずれかが表現されるようにアロケーション記述子が作成される。特に、ベースビュー・データ・ブロックの一部は２Ｄ再生専用ブロックとしてファイル２Ｄ内のアロケーション記述子によってのみ参照され、その一部の複製データが３Ｄ再生専用ブロックとしてファイルＳＳのアロケーション記述子によってのみ参照される。更に、ベースビューとディペンデントビューとのエクステントの各サイズが式（１）−（５）を満たすように設計され、それに基づいて、各アロケーション記述子の表すべき論理アドレスの値が決定される。
フォーマット処理部6306はその他に、データベース部6307に保存されたフレーム奥行き情報6310を利用して、図３９の（ａ）に示されているオフセット・テーブルを、セカンダリ・ビデオ・ストリーム6311、ＰＧストリーム6313、及びＩＧストリーム6314のそれぞれについて作成する。フォーマット処理部6306は更にオフセット・テーブルを２Ｄクリップ情報ファイルの３Ｄメタデータ内に格納する。ここで、各ストリームの表す３Ｄ映像が、他のストリームの表す３Ｄ映像と同じ視方向に重なって表示されないように、左右の各映像フレーム内でのイメージ・データの配置が自動的に調整される。更に、各ストリームの表す３Ｄ映像の奥行きが互いに重ならないように、各映像フレームに対するオフセット値が自動的に調整される。
フォーマット処理部6306によって生成されたＢＤ−ＲＯＭディスクイメージ6320はその後、ＢＤ−ＲＯＭプレス用データに変換される。更に、このデータはＢＤ−ＲＯＭディスクの原盤に記録される。この原盤がプレス工程に利用されることにより、本発明の実施形態１による記録媒体１００の大量生産が実現可能になる。

《実施形態４》
本実施形態では、前述の実施形態において説明された構造のデータを再生する再生装置に関して、集積回路３を用いて実現した構成例（図９５）について説明する。
媒体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から送られてきた格納先アドレスに従ってメモリ２にデータを格納する。なお、主制御部６は、再生データに先立って受信されメモリ２に格納されている前述のCLIPINFに含まれるエクステント起点（立体視再生の場合は、前述のファイルベースもしくはファイルディペンデント）を利用して切替部５３を制御する。つまり、主制御部６は、ファイルベースを利用してデバイス・ストリームIF部５１が受信したデータが左目用データであることを認識し、切替部５３を制御し、デバイス・ストリームIF部51が受信したデータが右目用データであることを認識し、切替部５３を制御してメモリ２への出力先（格納先）を切り替える。また、主制御部６の代わりに切替部５３を制御する専用の回路を設けても構わない。
ここでは、ストリーム処理部５の代表的な構成として、デバイス・ストリーム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部１を通して媒体に格納されている再生されるデータ以外の、データを再生するために必要なデータ（PLAYLIST、CLIPINF等）を受信し（読み出し）、メモリ２に格納する（媒体IF部１、デバイスIF部５１、メモリ制御部９、メモリ２）。
Ｓ１０２：主制御部６は、受信されたCLIPINFに含まれるストリーム属性情報から、媒体に格納されている映像データ及び音声データの圧縮形式を認識し、対応するデコード処理ができるように信号処理部７の初期化を行う（主制御部６）。
Ｓ１０３：ストリーム処理部５のデバイス・ストリームIF部５１は、媒体IF部１を通して媒体に格納されている映像・音声など再生されるデータを受信し（読み出し）、切替部５３、メモリ制御部９を経由してメモリ２に格納する。なお、データはエクステント単位で受信し（読み出され）、左目用データを受信した（読み出した）時は第１の領域へ、右目用データを受信した（読み出した）時は第２の領域へ格納されるよう、主制御部６が切替部５３を制御し、切替部５３がデータの出力先（格納先）を切り替える（媒体IF部１、デバイスIF部５１、主制御部６、切替部５３、メモリ制御部９、メモリ２）。
Ｓ１０４：メモリ２に格納されたデータは、ストリーム処理部５の多重分離部５２に転送され、多重分離部５２はストリームデータを構成するソースパケットに含まれるPIDに従って映像系（主映像、副映像、PG（字幕）、IG（メニュー））、音声系（音声、副音声）のいずれであるか認識し、TSパケット単位で信号処理部７の対応する各デコーダへ転送する。（多重分離部５２）。
Ｓ１０５：信号処理部７の各デコーダは、転送されてきたTSパケットに対して、適切な方式でデコード処理を行う（信号処理部７）。
Ｓ１０６：信号処理部７においてデコードされた映像系データのうち、レフトビュービデオストリーム及びライトビュービデオストリームに対応するデータを、表示装置４に合わせてリサイズする（ビデオ出力フォーマット変換部８２）。
Ｓ１０７：Ｓ１０６においてリサイズされたビデオストリームと、PG（字幕）・IG（メニュー）とが重畳される（画像重畳部８１）。
Ｓ１０８：Ｓ１０７において重畳された映像データに対して、走査方式の変換であるＩＰ変換を行う（ビデオ出力フォーマット変換部８２）。
Ｓ１０９：これまでの処理を行った映像系データ及び音声系データに対して、表示装置・スピーカー４のデータ出力方式、もしくは表示装置・スピーカー４へのデータ送信方式に従って、エンコードやD/A変換等を行う。例えば、映像系データ・音声系データをそれぞれ、アナログまたはデジタル出力に対応するために処理を行う。映像系データのアナログ出力としては、コンポジット映像信号やＳ映像信号やコンポーネント映像信号等をサポートしている。また映像系・音声系データのデジタル出力は、HDMIをサポートしている（オーディオ・ビデオ出力IF部８３）。
Ｓ１１０：Ｓ１０９において処理された映像系データ及び音声系データを、表示装置・スピーカー４に送信、出力する（オーディオ・ビデオ出力IF部８３、表示装置・スピーカー４）。
以上が、本実施の形態における再生装置の動作手順の説明である。なお、処理ごとに処理結果をメモリ２に一旦格納しても構わない。また、本動作手順では、ビデオ出力フォーマット変換部８２においてリサイズ処理及びIP変換処理を行う場合について説明したが、必要に応じて処理を省略しても構わないし、また他の処理（ノイズリダクション処理、フレームレート変換処理等）を行っても構わない。更に、可能なものについては処理手順を変更しても構わない。

＜補足＞
≪放送、通信回路を経由したデータ配信≫
本発明の実施形態１による記録媒体は、光ディスクの他、例えばＳＤメモリカードを含む可搬性半導体メモリ装置等、パッケージメディアとして利用可能なリムーバブルメディア全般を含む。また、実施形態１の説明では、予めデータが記録された光ディスク、すなわち、ＢＤ−ＲＯＭ又はＤＶＤ−ＲＯＭ等の既存の読み出し専用の光ディスクが例に挙げられている。しかし、本発明の実施形態はそれらに限定されない。例えば放送で、又はネットワーク経由で配信された３Ｄ映像のコンテンツを端末装置によって、ＢＤ−ＲＥ又はＤＶＤ−ＲＡＭ等の既存の書き込み可能な光ディスクへ書き込むときに、実施形態１によるエクステントの配置が利用されてもよい。ここで、その端末装置は、再生装置に組み込まれていても、再生装置とは別の装置であってもよい。
≪半導体メモリカードの再生≫
本発明の実施形態１による記録媒体として、光ディスクに代えて半導体メモリカードを用いたときにおける、再生装置のデータ読み出し部について説明する。
再生装置のうち、光ディスクからデータを読み出す部分は、例えば光ディスクドライブによって構成される。それに対し、半導体メモリカードからデータを読み出す部分は、専用のインタフェース（Ｉ／Ｆ）で構成される。より詳細には、再生装置にカードスロットが設けられ、その内部に上記のＩ／Ｆが実装される。そのカードスロットに半導体メモリカードが挿入されるとき、そのＩ／Ｆを通してその半導体メモリカードが再生装置と電気的に接続される。更に、半導体メモリカードからデータがそのＩ／Ｆを通して再生装置に読み出される。
≪ＢＤ−ＲＯＭディスク上のデータに対する著作権保護技術≫
ここで、以降の補足事項の前提として、ＢＤ−ＲＯＭディスクに記録されているデータの著作権を保護するための仕組みについて説明する。
ＢＤ−ＲＯＭディスクに記録されたデータの一部が、例えば著作権の保護又はデータの秘匿性の向上の観点から暗号化されている場合がある。その暗号化データは例えば、ビデオ・ストリーム、オーディオ・ストリーム、又はその他のストリームを含む。その場合、暗号化データは以下のように解読される。
再生装置には予め、ＢＤ−ＲＯＭディスク上の暗号化データを解読するための「鍵」の生成に必要なデータの一部、すなわちデバイスキーが記憶されている。一方、ＢＤ−ＲＯＭディスクには、そのその「鍵」の生成に必要なデータの別の一部、すなわちＭＫＢ（メディアキーブロック）と、その「鍵」自体の暗号化データ、すなわち暗号化タイトルキーとが記録されている。デバイスキー、ＭＫＢ、及び暗号化タイトルキーは互いに対応付けられ、更に、図６に示されている記録媒体１００上のＢＣＡ201に書き込まれた特定のＩＤ、すなわちボリュームＩＤにも対応付けられている。デバイスキー、ＭＫＢ、暗号化タイトルキー、及びボリュームＩＤの組み合わせが正しくなければ、暗号化データの解読はできない。すなわち、これらの組み合わせが正しい場合にのみ、上記の「鍵」、すなわちタイトルキーが生成される。具体的には、まず、デバイスキー、ＭＫＢ、及びボリュームＩＤを利用して暗号化タイトルキーが復号される。それによってタイトルキーを導き出すことができたときのみ、そのタイトルキーを上記の「鍵」として用いて暗号化データを解読することができる。
ＢＤ−ＲＯＭディスク上の暗号化データを再生装置によって再生しようとしても、例えばそのＢＤ−ＲＯＭディスク上の暗号化タイトルキー、ＭＫＢ、及びボリュームＩＤに予め対応付けられたデバイスキーがその再生装置内に記憶されていなければ、その暗号化データを再生することができない。何故なら、その暗号化データの解読に必要な鍵、すなわちタイトルキーは、ＭＫＢ、デバイスキー、及びボリュームＩＤの正しい組み合わせで暗号化タイトルキーを復号しなければ導き出せないからである。
ＢＤ−ＲＯＭディスクに記録されるべきビデオ・ストリームとオーディオ・ストリームとの少なくともいずれかの著作権を保護するには、まず、保護対象のストリームをタイトルキーで暗号化して、ＢＤ−ＲＯＭディスクに記録する。次に、ＭＫＢ、デバイスキー、及びボリュームＩＤの組み合わせから鍵を生成し、その鍵で上記のタイトルキーを暗号化して暗号化タイトルキーに変換する。更に、ＭＫＢ、ボリュームＩＤ、及び暗号化タイトルキーをＢＤ−ＲＯＭディスクに記録する。そのＢＤ−ＲＯＭディスクからは、上述の鍵の生成に利用されたデバイスキーを備えた再生装置でしか、暗号化されたビデオ・ストリーム及び／又はオーディオ・ストリームをデコーダで復号することはできない。こうして、ＢＤ−ＲＯＭディスクに記録されたデータの著作権を保護することができる。
以上に述べた、ＢＤ−ＲＯＭディスクにおけるデータの著作権保護の仕組みは、ＢＤ−ＲＯＭディスク以外にも適用可能である。例えば読み書き可能な半導体メモリ装置、特にＳＤカード等の可搬性半導体メモリカードにも適用可能である。
≪電子配信を利用した記録媒体へのデータ記録≫
電子配信を利用して本発明の実施形態１による再生装置へ３Ｄ映像のＡＶストリーム・ファイル等のデータ（以下、配信データという。）を伝達し、更にその再生装置にその配信データを半導体メモリカードに記録させる処理について、以下説明する。尚、以下の動作は、上記の再生装置に代えて、その処理に特化した端末装置によって行われてもよい。また、記録先の半導体メモリカードがＳＤメモリカードである場合を想定する。
再生装置は上記のとおり、カードスロットを備えている。そのカードスロットにはＳＤメモリカードが挿入されている。この状態で、再生装置はまず、ネットワーク上の配信サーバへ配信データの送信要求を送出する。このとき、再生装置はＳＤメモリカードからその識別情報を読み出して、その識別情報を送信要求と共に配信サーバへ送出する。ＳＤメモリカードの識別情報は、例えばそのＳＤメモリカード固有の識別番号、より具体的にはそのＳＤメモリカードのシリアル番号である。この識別情報は上述のボリュームＩＤとして利用される。
配信サーバには配信データが格納されている。その配信データのうち、ビデオ・ストリーム及び／又はオーディオ・ストリーム等、暗号化による保護の必要なデータは、所定のタイトルキーを用いて暗号化されている。その暗号化データは同じタイトルキーで復号が可能である。
配信サーバは、再生装置と共通の秘密鍵としてデバイスキーを保持している。配信サーバは更に、ＳＤメモリカードと共通のＭＫＢを保持している。配信サーバは、再生装置から配信データの送信要求とＳＤメモリカードの識別情報とを受け付けたとき、まず、デバイスキー、ＭＫＢ、及びその識別情報から鍵を生成し、その鍵でタイトルキーを暗号化して暗号化タイトルキーを生成する。
配信サーバは次に公開鍵情報を生成する。その公開鍵情報は、例えば、上述のＭＫＢ、暗号化タイトルキー、署名情報、ＳＤメモリカードの識別番号、及びデバイスリストを含む。署名情報は、例えば公開鍵情報のハッシュ値を含む。デバイスリストは、無効にすべきデバイス、すなわち、配信データ中の暗号化データを不正に再生する危険性のあるデバイスのリストである。そのリストには、例えば、再生装置のデバイスキー、再生装置の識別番号、再生装置に内蔵のデコーダ等、各種部品の識別番号、又は機能（プログラム）が特定されている。
配信サーバは更に、配信データと公開鍵情報とを再生装置へ送出する。再生装置は、それらを受信して、カードスロット内の専用Ｉ／Ｆを通してＳＤメモリカードに記録する。
ＳＤメモリカードに記録された配信データのうち、暗号化データは、例えば公開鍵情報を以下のように利用して復号される。まず、公開鍵情報の認証として次の三種類のチェック（１）−（３）が行われる。尚、それらはどのような順序で行われてもよい。
（１）公開鍵情報に含まれるＳＤメモリカードの識別情報が、カードスロットに挿入されているＳＤメモリカードに記憶されている識別番号と一致するか否か。
（２）公開鍵情報から算出されるハッシュ値が、署名情報に含まれるハッシュ値と一致するか否か。
（３）公開鍵情報の示すデバイスリストから当該再生装置が除外されているか否か。具体的には、デバイスリストから当該再生装置のデバイスキーが除外されているか否か。
上述のチェック（１）−（３）のいずれかの結果が否定的であるとき、再生装置は暗号化データの復号処理を中止する。逆に、上述のチェック（１）−（３）の全ての結果が肯定的であるとき、再生装置は公開鍵情報の正当性を認め、デバイスキー、ＭＫＢ、及びＳＤメモリカードの識別情報を利用して、公開鍵情報内の暗号化タイトルキーをタイトルキーに復号する。再生装置は更に、そのタイトルキーを用いて暗号化データを、例えばビデオ・ストリーム及び／又はオーディオ・ストリームに復号する。
以上の仕組みには次の利点がある。電子配信時に既に、不正使用の危険性がある再生装置、部品、及び機能（プログラム）等が知られている場合、これらの識別情報がデバイスリストに列挙され、公開鍵情報の一部として配信される。一方、配信データを要求した再生装置は必ず、そのデバイスリスト内の識別情報を、その再生装置及びその部品等の識別情報と照合しなければならない。それにより、その再生装置又はその部品等がデバイスリストに示されていれば、たとえ、ＳＤメモリカードの識別番号、ＭＫＢ、暗号化タイトルキー、及びデバイスキーの組み合わせが正しくても、その再生装置は公開鍵情報を配信データ内の暗号化データの復号には利用できない。こうして、配信データの不正使用を効果的に抑制することができる。
半導体メモリカードの識別情報は、半導体メモリカード内の記録領域のうち、特に秘匿性の高い記録領域に格納することが望ましい。何故なら、万一、その識別情報、例えばＳＤメモリカードではそのシリアル番号が不正に改竄された場合、ＳＤメモリカードの違法コピーが容易に実行可能になってしまうからである。すなわち、その改竄の結果、同一の識別情報を持つ半導体メモリカードが複数存在するようになれば、上述のチェック（１）では正規品と違法な複製品との識別ができなくなるからである。従って、半導体メモリカードの識別情報は秘匿性の高い記録領域に記録して、不正な改竄から保護されねばならない。
半導体メモリカード内にこのような秘匿性の高い記録領域を構成する手段は、例えば次のとおりである。まず、通常のデータ用の記録領域（以下、第１の記録領域と称す。）から電気的に分離された別の記録領域（以下、第２の記録領域と称す。）が設置される。次に、第２の記録領域へのアクセス専用の制御回路が半導体メモリカード内に設けられる。それにより、第２の記録領域へはその制御回路を介してのみアクセスが可能であるようにする。例えば、第２の記録領域には、暗号化されたデータのみが記録され、その暗号化されたデータを復号するための回路が制御回路内にのみ組み込まれる。それにより、第２の記録領域内のデータへのアクセスは、そのデータを制御回路に復号させなければ不可能である。その他に、第２の記録領域内の各データのアドレスを制御回路にのみ保持させてもよい。その場合、第２の記録領域内のデータのアドレスは制御回路にしか特定できない。
半導体メモリカードの識別情報が第２の記録領域に記録された場合、再生装置上で動作するアプリケーション・プログラムは、電子配信を利用して配信サーバからデータを取得して半導体メモリカードに記録する場合、次のような処理を行う。まず、そのアプリケーション・プログラムは、メモリカードＩ／Ｆを介して上記の制御回路に対し、第２の記録領域に記録された半導体メモリカードの識別情報へのアクセス要求を発行する。制御回路はその要求に応じて、まず、第２の記録領域からその識別情報を読み出す。制御回路は次に、メモリカードＩ／Ｆを介して上記のアプリケーション・プログラムへその識別情報を送る。そのアプリケーション・プログラムはその後、その識別情報と共に配信データの送信要求を配信サーバに送出する。アプリケーション・プログラムは更に、その要求に応じて配信サーバから受信される公開鍵情報と配信データとを、メモリカードＩ／Ｆを介して半導体メモリカード内の第１の記録領域に記録する。
尚、上記のアプリケーション・プログラムは、半導体メモリカード内の制御回路に対して上記のアクセス要求を発行する前に、そのアプリケーション・プログラム自体の改竄の有無をチェックすることが望ましい。そのチェックには、例えばＸ．５０９に準拠のデジタル証明書が利用されてもよい。また、配信データは上記のとおり、半導体メモリカード内の第１の記録領域に記録されればよく、その配信データへのアクセスは半導体メモリカード内の制御回路によって制御されなくてもよい。
≪リアルタイム・レコーディングへの適用≫
本発明の実施形態３では、ＡＶストリーム・ファイル及びプレイリスト・ファイルは、オーサリングシステムにおけるプリレコーディング技術によってＢＤ−ＲＯＭディスクに記録されてユーザに供給されることを前提とした。しかし、ＡＶストリーム・ファイル及びプレイリスト・ファイルは、リアルタイム・レコーディングによって、ＢＤ−ＲＥディスク、ＢＤ−Ｒディスク、ハードディスク、又は半導体メモリカード等の書き込み可能な記録媒体（以下、ＢＤ−ＲＥディスク等と略す。）に記録されてユーザに供給されるものであってもよい。その場合、ＡＶストリーム・ファイルは、アナログ入力信号を記録装置がリアルタイムで復号することによって得られたトランスポート・ストリームであってもよい。その他に、記録装置がデジタル入力したトランスポート・ストリームをパーシャル化することで得られるトランスポート・ストリームであってもよい。
リアルタイム・レコーディングを実行する記録装置は、ビデオエンコーダ、オーディオエンコーダ、マルチプレクサ、及びソースパケタイザを含む。ビデオエンコーダはビデオ信号を符号化してビデオ・ストリームに変換する。オーディオエンコーダはオーディオ信号を符号化してオーディオ・ストリームに変換する。マルチプレクサは、ビデオ・ストリームとオーディオ・ストリームとを多重化して、ＭＰＥＧ２−ＴＳ形式のデジタル・ストリームに変換する。ソースパケタイザは、ＭＰＥＧ２−ＴＳ形式のデジタル・ストリーム内のＴＳパケットをソースパケットに変換する。記録装置は各ソースパケットをＡＶストリーム・ファイルに格納して、ＢＤ−ＲＥディスク等に書き込む。
ＡＶストリーム・ファイルの書き込み処理と並行して、記録装置の制御部はクリップ情報ファイルとプレイリスト・ファイルとをメモリ上で生成してＢＤ−ＲＥディスク等に書き込む。具体的には、ユーザによって録画処理が要求されたとき、制御部はまず、ＡＶストリーム・ファイルに合わせてクリップ情報ファイルを生成してＢＤ−ＲＥディスク等に書き込む。その場合、外部から受信されるトランスポート・ストリームからビデオ・ストリーム内の一つのＧＯＰの先頭が検出される度に、又は、ビデオエンコーダによってビデオ・ストリーム内の一つのＧＯＰが生成される度に、制御部は、そのＧＯＰの先頭に位置するＩピクチャのＰＴＳと、そのＧＯＰの先頭が格納されたソースパケットのＳＰＮとを取得する。制御部は更に、そのＰＴＳとＳＰＮとの対を一つのエントリ・ポイントとしてクリップ情報ファイルのエントリ・マップに追記する。ここで、そのエントリ・ポイントには「is＿angle＿changeフラグ」が追加される。is＿angle＿changeフラグは、そのＧＯＰの先頭がＩＤＲピクチャであるときは“オン”に設定され、そのＧＯＰの先頭がＩＤＲピクチャではないときは“オフ”に設定される。クリップ情報ファイル内には更に、ストリーム属性情報が記録対象のストリームの属性に従って設定される。こうして、ＡＶストリーム・ファイルとクリップ情報ファイルとがＢＤ−ＲＥディスク等に書き込まれた後、制御部はそのクリップ情報ファイル内のエントリ・マップを利用してプレイリスト・ファイルを生成し、ＢＤ−ＲＥディスク等に書き込む。
≪マネージド・コピー≫
本発明の実施形態１による再生装置は更に、マネージド・コピーによって記録媒体１００上のデジタル・ストリームを他の記録媒体へ書き込んでもよい。「マネージド・コピー」とは、ＢＤ−ＲＯＭディスク等の読み出し専用記録媒体から書き込み可能な記録媒体へ、デジタル・ストリーム、プレイリスト・ファイル、クリップ情報ファイル、及びアプリケーション・プログラムをコピーすることを、サーバとの通信による認証が成功した場合にのみ許可するための技術をいう。その書き込み可能な記録媒体は、ＢＤ−Ｒ、ＢＤ−ＲＥ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、及びＤＶＤ−ＲＡＭ等の書き込み可能な光ディスク、ハードディスク、並びに、ＳＤメモリカード、メモリースティック（登録商標）、コンパクトフラッシュ（登録商標）、スマートメディア（登録商標）、及びマルチメディアカード（登録商標）等の可搬性半導体メモリ装置を含む。マネージド・コピーは、読み出し専用記録媒体に記録されたデータのバックアップ回数の制限、及びバックアップ処理に対する課金を可能にする。
ＢＤ−ＲＯＭディスクからＢＤ−Ｒディスク又はＢＤ−ＲＥディスクへのマネージド・コピーが行われる場合、両ディスクの記録容量が等しいときは、コピー元のディスクに記録されたビット・ストリームがそのまま、順番にコピーされればよい。
マネージド・コピーが異種の記録媒体間で行われるときはトランス・コードが必要である。「トランス・コード」とは、コピー元のディスクに記録されているデジタル・ストリームをコピー先の記録媒体のアプリケーション・フォーマットに適合させるための処理をいう。トランス・コードは、例えば、ＭＰＥＧ２−ＴＳ形式からＭＰＥＧ２プログラム・ストリーム形式へ変換する処理、及び、ビデオ・ストリームとオーディオ・ストリームとのそれぞれに割り当てられているビットレートを低くして符号化し直す処理を含む。トランス・コードでは、上述のリアルタイム・レコーディングによって、ＡＶストリーム・ファイル、クリップ情報ファイル、及びプレイリスト・ファイルが生成されねばならない。
≪データ構造の記述方法≫
本発明の実施形態１によるデータ構造のうち、「所定型の情報が複数存在する」という繰り返し構造は、ｆｏｒ文に制御変数の初期値と繰り返し条件とを記述することによって定義される。また、「所定の条件が成立するときに所定の情報が定義される」というデータ構造は、ｉｆ文にその条件と、その条件の成立時に設定されるべき変数とを記述することによって定義される。このように、実施形態１によるデータ構造は高級プログラミング言語によって記述される。従って、そのデータ構造は、「構文解析」、「最適化」、「資源割付」、及び「コード生成」といったコンパイラによる翻訳過程を経て、コンピュータによって読み取り可能なコードに変換され、記録媒体に記録される。高級プログラミング言語での記述により、そのデータ構造は、オブジェクト指向言語におけるクラス構造体のメソッド以外の部分、具体的には、そのクラス構造体における配列型のメンバー変数として扱われ、プログラムの一部を成す。すなわち、そのデータ構造は、プログラムと実質的に同等である。従って、そのデータ構造はコンピュータ関連の発明として保護を受けるべきである。
≪再生プログラムによるプレイリスト・ファイル、クリップ情報ファイルの管理≫
プレイリスト・ファイルとＡＶストリーム・ファイルとが記録媒体に記録されるとき、その記録媒体には再生プログラムが実行形式のファイルとして記録される。再生プログラムはコンピュータに、プレイリスト・ファイルに従ってＡＶストリーム・ファイルを再生させる。再生プログラムは記録媒体からコンピュータ内のメモリ装置にロードされた後、そのコンピュータによって実行される。そのロード処理はコンパイル処理又はリンク処理を含む。それらの処理により、再生プログラムはメモリ装置内では複数のセクションに分割される。それらのセクションは、ｔｅｘｔセクション、ｄａｔａセクション、ｂｓｓセクション、及びｓｔａｃｋセクションを含む。ｔｅｘｔセクションは、再生プログラムのコード列、変数の初期値、及び書き換え不可のデータを含む。ｄａｔａセクションは、初期値を持つ変数、及び書き換え可能なデータを含む。ｄａｔａセクションは特に、記録媒体上に記録された、随時アクセスされるファイルを含む。ｂｓｓセクションは、初期値を持たない変数を含む。ｂｓｓセクション内のデータは、ｔｅｘｔセクション内のコードの示す命令に応じて参照される。コンパイル処理又はリンク処理では、コンピュータ内のＲＡＭにｂｓｓセクション用の領域が確保される。ｓｔａｃｋセクションは、必要に応じて一時的に確保されるメモリ領域である。再生プログラムによる各処理ではローカル変数が一時的に使用される。ｓｔａｃｋセクションはそれらのローカル変数を含む。プログラムの実行が開始されるとき、ｂｓｓセクション内の変数はゼロで初期化され、ｓｔａｃｋセクションには必要なメモリ領域が確保される。
プレイリスト・ファイル及びクリップ情報ファイルは上述のとおり、記録媒体上では既に、コンピュータによって読み取り可能なコードに変換されている。従って、それらのファイルは再生プログラムの実行時、ｔｅｘｔセクション内の「書き換え不可のデータ」、又はｄａｔａセクション内の「随時アクセスされるファイル」として管理される。すなわち、プレイリスト・ファイル及びクリップ情報ファイルは、再生プログラムの実行時にその構成要素の中に組み込まれる。それ故、プレイリスト・ファイル及びクリップ情報ファイルは再生プログラムにおいて、単なるデータの提示を超えた役割を果たす。
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなく3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ。
１００ 記録媒体
２００ 再生装置
３００ 表示装置
４００ 3D眼鏡
５００ リモコン
２００１ 第１の３Ｄエクステント・ブロック
２００２ 第２の３Ｄエクステント・ブロック
２００３ 第３の３Ｄエクステント・ブロック
２０１０ 第１ファイル２Ｄのファイル・エントリ
２０１１ 第２ファイル２Ｄのファイル・エントリ
２０２０ 第１ファイルＳＳのファイル・エントリ
２０２１ 第２ファイルＳＳのファイル・エントリ
LB 層境界
D0、D1、D2、D3、D4 デプスマップ・データ・ブロック
R0、R1、R2、R3、R4 ライトビュー・データ・ブロック
L0、L1、L4 ベースビュー・データ・ブロック
L22D、L32D ２Ｄ再生専用ブロック
L2SS、L3SS ３Ｄ再生専用ブロック
EXT2D[0]、EXT2D[1]、EXT2D[2] ２Ｄエクステント
EXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]、EXTSS[4] ３Ｄエクステント

Claims (6)

  1. 複数のデータブロックからなるデータストリームと管理情報とが記録された記録媒体であって、
    前記データストリームは、平面視再生に利用されるメインビュー・ストリームと、前記メインビュー・ストリームと組み合わされて立体視映像の再生に利用されるサブビュー・ストリームとを含み、
    前記複数のデータブロックは、前記メインビュー・ストリームから構成される複数のメインビュー・データブロックと、前記サブビュー・ストリームから構成される複数のサブビュー・データブロックとを含み、
    前記管理情報は、平面視再生時に、前記メインビュー・データブロックを参照する２Ｄ管理情報と、立体視再生時に、前記メインビュー・データブロックを参照する３Ｄ管理情報とを含み、
    前記複数のデータブロックの種類には、共通データブロックと、２Ｄデータブロックと、３Ｄデータブロックとがあり、
    前記共通データブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記共通データブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報及び３Ｄ管理情報の双方から参照され、
    前記２Ｄデータブロックは、前記メインビュー・データブロックを含み、前記２Ｄデータブロックに含まれるメインビュー・データブロックは、３Ｄ管理情報からは参照されずに、２Ｄ管理情報から参照され、
    前記３Ｄデータブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記３Ｄデータブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報からは参照されずに、３Ｄ管理情報から参照され、
    ２Ｄデータブロックは、共通データブロックが記録されている領域に論理アドレスが後続する領域であって、平面視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、
    ３Ｄデータブロックは、２Ｄデータブロックが記録されている領域に論理アドレスが後続する領域であって、立体視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、
    ２Ｄデータブロックに含まれるメインビュー・データブロックと３Ｄデータブロックに含まれるメインビュー・データブロックとは同一の内容であること
    を特徴とする記録媒体。
  2. ２Ｄデータブロックに含まれる最後のピクチャの表示時刻と、３Ｄデータブロックに含まれる最後のピクチャの表示時刻とが一致することを特徴とする
    請求項１に記載の記録媒体。
  3. 前記記録媒体には更に、複数の再生区間により再生経路を示す再生経路情報が記録されており、
    ２Ｄデータブロック及び３Ｄデータブロックに定義された再生区間は、後続する再生区間とのシームレスな再生が保証された再生区間であることを特徴とする
    請求項２に記載の記録媒体。
  4. ３Ｄデータブロックは、前記立体視映像の再生中に生じるロングジャンプ中に、再生装置にバッファアンダーフローを生じさせないデータサイズを有し、
    ２Ｄデータブロックは、共通データブロックと連続して読み出されることで、前記平面視映像の再生中に生じるロングジャンプ中に、再生装置にバッファアンダーフローを生じさせないデータサイズを有する
    ことを特徴とする請求項３に記載の記録媒体。
  5. 前記記録媒体は複数の記録層を含み、前記ロングジャンプは前記複数の記録層間のジャンプである
    請求項１に記載の記録媒体。
  6. 複数のデータブロックからなるデータストリームと管理情報とが記録された記録媒体から映像を再生するための再生装置であって、
    前記データストリームは、平面視再生に利用されるメインビュー・ストリームと、前記メインビュー・ストリームと組み合わされて立体視映像の再生に利用されるサブビュー・ストリームとを含み、
    前記複数のデータブロックは、前記メインビュー・ストリームから構成される複数のメインビュー・データブロックと、前記サブビュー・ストリームから構成される複数のサブビュー・データブロックとを含み、
    前記管理情報は、平面視再生時に、前記メインビュー・データブロックを参照する２Ｄ管理情報と、立体視再生時に、前記メインビュー・データブロックを参照する３Ｄ管理情報とを含み、
    前記複数のデータブロックの種類には、共通データブロックと、２Ｄデータブロックと、３Ｄデータブロックとがあり、
    前記共通データブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記共通データブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報及び３Ｄ管理情報の双方から参照され、
    前記２Ｄデータブロックは、前記メインビュー・データブロックを含み、前記２Ｄデータブロックに含まれるメインビュー・データブロックは、３Ｄ管理情報からは参照されずに、２Ｄ管理情報から参照され、
    前記３Ｄデータブロックは、前記メインビュー・データブロックと前記サブビュー・データブロックとを含み、前記３Ｄデータブロックに含まれるメインビュー・データブロックは、２Ｄ管理情報からは参照されずに、３Ｄ管理情報から参照され、
    ２Ｄデータブロックは、共通データブロックが記録されている領域に論理アドレスが後続する領域であって、平面視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、
    ３Ｄデータブロックは、２Ｄデータブロックが記録されている領域に論理アドレスが後続する領域であって、立体視映像の再生中に生じるロングジャンプの直前にアクセスされる領域に記録され、
    ２Ｄデータブロックに含まれるメインビュー・データブロックと３Ｄデータブロックに含まれるメインビュー・データブロックとは同一の内容であり、
    前記再生装置は、
    前記記録媒体から、前記データストリームを読み出す読出手段と、
    前記データストリームから前記メインビュー・データブロックと前記サブビュー・データブロックを分離し、前記メインビュー・ストリームと前記サブビュー・ストリームを抽出する分離手段と、
    抽出された前記メインビュー・ストリームと前記サブビュー・ストリームを格納するリードバッファと、
    リードバッファから、前記メインビュー・ストリームと前記サブビュー・ストリームに含まれる圧縮ピクチャの供給を受けて、前記圧縮ピクチャを復号するデコーダと、
    を備え、
    前記読出手段は、平面視映像の再生時に、前記２Ｄ管理情報を利用して、共通データブロック、及び２Ｄデータブロックに含まれるメインビュー・データブロックを読み出し、
    前記分離手段は、立体視映像の再生時に、前記３Ｄ管理情報を利用してデータストリームから、共通データブロック、及び３Ｄデータブロックに含まれるメインビュー・データブロックを分離して、メインビュー・ストリームを抽出することを特徴とする
    再生装置。
JP2010525153A 2009-02-19 2010-02-18 記録媒体、及び再生装置 Active JP4654327B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2009037224 2009-02-19
JP2009037224 2009-02-19
PCT/JP2010/001055 WO2010095443A1 (ja) 2009-02-19 2010-02-18 記録媒体、再生装置、及び集積回路

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2010171598A Division JP2011004410A (ja) 2009-02-19 2010-07-30 記録媒体、及び再生装置
JP2010171599A Division JP5390485B2 (ja) 2009-02-19 2010-07-30 半導体集積回路

Publications (2)

Publication Number Publication Date
JP4654327B2 true JP4654327B2 (ja) 2011-03-16
JPWO2010095443A1 JPWO2010095443A1 (ja) 2012-08-23

Family

ID=42633730

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2010525153A Active JP4654327B2 (ja) 2009-02-19 2010-02-18 記録媒体、及び再生装置
JP2010171599A Expired - Fee Related JP5390485B2 (ja) 2009-02-19 2010-07-30 半導体集積回路
JP2010171598A Pending JP2011004410A (ja) 2009-02-19 2010-07-30 記録媒体、及び再生装置

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2010171599A Expired - Fee Related JP5390485B2 (ja) 2009-02-19 2010-07-30 半導体集積回路
JP2010171598A Pending JP2011004410A (ja) 2009-02-19 2010-07-30 記録媒体、及び再生装置

Country Status (11)

Country Link
US (1) US20110013884A1 (ja)
EP (1) EP2400774B1 (ja)
JP (3) JP4654327B2 (ja)
KR (1) KR20110126516A (ja)
CN (2) CN102740038A (ja)
DK (1) DK2400774T3 (ja)
ES (1) ES2549164T3 (ja)
MX (1) MX2010010757A (ja)
RU (1) RU2523178C2 (ja)
TW (1) TW201127017A (ja)
WO (1) WO2010095443A1 (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9549228B2 (en) 2010-09-01 2017-01-17 Lg Electronics Inc. Broadcast signal processing method and device for 3-dimensional (3D) broadcasting service
JP5594045B2 (ja) 2010-10-14 2014-09-24 ソニー株式会社 再生装置、再生方法、プログラム、および記録媒体
JP2012089931A (ja) 2010-10-15 2012-05-10 Sony Corp 情報処理装置、情報処理方法およびプログラム
GB2485532A (en) * 2010-11-12 2012-05-23 Sony Corp Three dimensional (3D) image duration-related metadata encoding of apparent minimum observer distances (disparity)
US8705946B2 (en) * 2010-11-19 2014-04-22 Sony Corporation 3D authoring tool ensuring no buffer underrun upon jumps
CN102098339A (zh) * 2011-01-26 2011-06-15 广州酷狗计算机科技有限公司 一种音频文件传输方法及其系统
MX2013008311A (es) * 2011-02-16 2013-09-06 Panasonic Corp Codificador de video, metodo de codificacion de video, programa de codificacion de video, metodo de reproduccion de video y programa de reproduccion de video.
CA2825117A1 (en) * 2011-02-17 2012-08-23 Panasonic Corporation Video encoding device, video encoding method, video encoding program, video playback device, video playback method, and video playback program
EP2506263A1 (en) 2011-03-31 2012-10-03 Thomson Licensing Stereoscopic scene graph for defining 3D- and 2D-compatible graphical objects
WO2012147365A1 (ja) * 2011-04-28 2012-11-01 パナソニック株式会社 記録媒体、再生装置、及び記録装置
EP2750389A4 (en) 2011-08-24 2014-09-24 Panasonic Corp RECORDING MEDIUM, READING DEVICE, RECORDING DEVICE, AND RECORDING METHOD
JP2013090016A (ja) * 2011-10-13 2013-05-13 Sony Corp 送信装置、送信方法、受信装置および受信方法
JPWO2013099289A1 (ja) * 2011-12-28 2015-04-30 パナソニック株式会社 再生装置、送信装置、再生方法及び送信方法
CN102404610B (zh) * 2011-12-30 2014-06-18 百视通网络电视技术发展有限责任公司 视频点播服务的实现方法及系统
EP2685456A1 (en) * 2012-07-12 2014-01-15 Universiteit Gent Index with offset to closest I-picture entry for random access in a bitstream.
CN102984483B (zh) * 2012-12-18 2016-08-03 上海晨思电子科技有限公司 一种三维用户界面显示系统及方法
US9681116B2 (en) * 2013-03-15 2017-06-13 Arris Enterprises, Inc. System and method for delivering 3DTV content to variety of receivers
TW201528775A (zh) 2014-01-02 2015-07-16 Ind Tech Res Inst 景深圖校正方法及系統
RU2582852C1 (ru) * 2015-01-21 2016-04-27 Общество с ограниченной ответственностью "Вокорд СофтЛаб" (ООО "Вокорд СофтЛаб") Автоматическое построение 3d модели лица по серии 2d изображений или по видеофильму
WO2017002541A1 (ja) * 2015-06-30 2017-01-05 ソニー株式会社 情報処理装置、情報処理システム、情報記録媒体、および情報処理方法、並びにプログラム
US11006069B2 (en) 2015-09-10 2021-05-11 Sony Corporation Transmission device, transmission method, reception device, and reception method
US10607654B2 (en) * 2017-02-09 2020-03-31 Verizon Patent And Licensing Inc. Using sharding to generate virtual reality content
DE102017215106B4 (de) * 2017-08-30 2022-07-28 Volkswagen Aktiengesellschaft Fortbewegungsmittel, Anordnung und Vorrichtung zur Evaluierung eines Signals eines Airbagsteuergerätes
US10834391B2 (en) * 2018-04-23 2020-11-10 8i Limited Hologram streaming machine
KR102569032B1 (ko) 2019-01-22 2023-08-23 삼성전자주식회사 전자 장치 및 그의 컨텐트 제공 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11191895A (ja) * 1996-12-04 1999-07-13 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2000270347A (ja) * 1999-03-17 2000-09-29 Sharp Corp 記録装置、及び該記録装置を用いた監視システム
JP4512172B2 (ja) * 2008-09-17 2010-07-28 パナソニック株式会社 記録媒体、再生装置、及び集積回路

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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
WO1997032437A1 (en) * 1996-02-28 1997-09-04 Matsushita Electric Industrial Co., Ltd. High-resolution optical disk for recording stereoscopic video, optical disk reproducing device, and optical disk recording device
JP3272271B2 (ja) * 1997-06-27 2002-04-08 三洋電機株式会社 映像再生装置及び映像記録媒体
DE69841532D1 (de) * 1997-08-29 2010-04-15 Panasonic Corp Optische Platte mit hierarchisch codiertem digitalen Videosignal, Wiedergabevorrichtung und Aufnahmevorrichtung für die optische Platte
JP2000134642A (ja) * 1998-10-21 2000-05-12 Toshiba Corp 立体モードと平面モードを持つ立体映像再生装置とその方法
CN100518282C (zh) * 2004-04-07 2009-07-22 松下电器产业株式会社 记录可以高速转换的流的信息记录装置和记录方法
JP4638784B2 (ja) * 2005-07-19 2011-02-23 オリンパスイメージング株式会社 画像出力装置及びプログラム
JP2006230001A (ja) * 2006-03-20 2006-08-31 Sony Corp 再生装置、再生方法、再生プログラムおよび記録媒体
RU2315439C1 (ru) * 2006-07-03 2008-01-20 Борис Иванович Волков Система объемной видеозаписи и воспроизведения
CA2662322A1 (en) * 2006-09-06 2008-03-13 Abbott Respiratory Llc Variable dose aerosol drug canister
JP4999931B2 (ja) * 2007-11-09 2012-08-15 三菱電機株式会社 ディスク状記録媒体、並びに映像情報再生装置及び方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11191895A (ja) * 1996-12-04 1999-07-13 Matsushita Electric Ind Co Ltd 高解像度および立体映像記録用光ディスク、光ディスク再生装置、および光ディスク記録装置
JP2000270347A (ja) * 1999-03-17 2000-09-29 Sharp Corp 記録装置、及び該記録装置を用いた監視システム
JP4512172B2 (ja) * 2008-09-17 2010-07-28 パナソニック株式会社 記録媒体、再生装置、及び集積回路

Also Published As

Publication number Publication date
CN102740038A (zh) 2012-10-17
JP2011004411A (ja) 2011-01-06
RU2523178C2 (ru) 2014-07-20
EP2400774A1 (en) 2011-12-28
JP2011004410A (ja) 2011-01-06
JPWO2010095443A1 (ja) 2012-08-23
ES2549164T3 (es) 2015-10-23
CN102027751A (zh) 2011-04-20
US20110013884A1 (en) 2011-01-20
RU2010140053A (ru) 2013-03-27
KR20110126516A (ko) 2011-11-23
EP2400774B1 (en) 2015-07-15
MX2010010757A (es) 2010-11-04
JP5390485B2 (ja) 2014-01-15
WO2010095443A1 (ja) 2010-08-26
TW201127017A (en) 2011-08-01
DK2400774T3 (en) 2015-10-19
EP2400774A4 (en) 2013-08-21
CN102027751B (zh) 2012-07-18

Similar Documents

Publication Publication Date Title
JP4654327B2 (ja) 記録媒体、及び再生装置
WO2010095440A1 (ja) 記録媒体、再生装置、及び集積回路
JP5351353B1 (ja) 記録媒体、再生装置、及び集積回路
JP5457299B2 (ja) 記録媒体、再生装置、及び集積回路
JP5491414B2 (ja) 記録媒体、再生装置、及び集積回路
WO2010089995A1 (ja) 記録媒体、再生装置、及び集積回路
WO2010113454A1 (ja) 記録媒体、再生装置、及び集積回路
JP4569935B2 (ja) 記録媒体、再生装置、及び集積回路
WO2010100875A1 (ja) 記録媒体、再生装置、及び集積回路
WO2010076846A1 (ja) 記録媒体、再生装置、及び集積回路
WO2010098134A1 (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: 20101124

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4654327

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: 20131224

Year of fee payment: 3