WO2010038409A1

WO2010038409A1 - 再生装置、記録媒体、及び集積回路

Info

Publication number: WO2010038409A1
Application number: PCT/JP2009/004950
Authority: WO
Inventors: 佐々木泰治; 矢羽田洋; 上坂靖; 持永和寛
Original assignee: パナソニック株式会社
Priority date: 2008-09-30
Filing date: 2009-09-28
Publication date: 2010-04-08
Also published as: JPWO2010038409A1; CN102232295A; RU2011135363A; US20100086285A1; SG172182A1; CA2746156A1; EP2360935A1; AU2009299356A1; TW201029466A; EP2360935A4; MX2011006360A

Abstract

　３Ｄ映像と２Ｄ映像とをシームレスに再生することができる再生装置を提供する。ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置であって、３Ｄビデオストリームを用いて立体視再生を行う場合、ベースビュービデオストリームとディペンデントビュービデオストリームとをデコードして得られたピクチャデータを表示装置へ出力し、３Ｄビデオストリームを用いて平面視再生を行う場合、ベースビュービデオストリームをデコードして得られた各ピクチャデータを、２回ずつ繰り返して表示装置へ出力することで、平面視再生における出力フレームレートを、立体視再生における出力フレームレートと同じフレームレートに変換する。

Description

再生装置、記録媒体、及び集積回路

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

　近年では３Ｄ映像の立体視を楽しめる映画館が増加していることに伴い、３Ｄ映像を高画質のまま光ディスクに格納することが求められてきている。

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

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

　また、再生互換性を有する光ディスクを用いることで、2D/3D再生装置では、１つの光ディスクで3D映像及び2D映像の再生を楽しむことができる。

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

　ところで、3D映像を機器間で伝送するには、広帯域が必要である。そこで、2D/3D再生装置と表示装置との接続には、広帯域のデータ伝送が可能なHDMI規格（HDMI:High Definition Multimedia Interface）に準拠した接続が用いられることが多い。HDMI規格の接続では装置間で同期してデータを受け渡すため、映像信号のフレームレートを切り替えるためには、装置間で再同期が必要となるため、その間、映像出力が停止することになる。

　ここで、3D映像は、２４Ｈｚのレフトビュー映像と２４Ｈｚのライトビュー映像とが表示装置へ出力されるため、3D映像全体で４８Ｈｚのフレームレートで出力される。これに対して、2D映像は、２４Ｈｚのレフトビュー映像のみが表示装置へ出力される。そのため、2D/3D再生装置で3D映像の再生中に2D映像に切り替えを行うと、表示装置との間でＨＤＭI接続の再同期が生じ、再生に遅延が生じるという問題がある。

　本発明はかかる問題に鑑み、３Ｄ映像と２Ｄ映像とをシームレスに再生することができる再生装置、及び記録媒体を提供することを目的とする。

　上記目的を達成するために、本発明に係る再生装置は、ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置であって、前記３Ｄビデオストリームを用いて立体視再生を行う場合、前記ベースビュービデオストリームをデコードして得られたピクチャデータと前記ディペンデントビュービデオストリームをデコードして得られたピクチャデータとを表示装置へ出力し、前記３Ｄビデオストリームを用いて平面視再生を行う場合、前記ベースビュービデオストリームをデコードして得られた各ピクチャデータを、少なくとも２回ずつ繰り返して表示装置へ出力することを特徴とする。

　本発明に係る再生装置は、上記の構成により、３Ｄビデオストリームを用いて平面視再生を行う場合に、ベースビュービデオストリームをデコードして得られた各ピクチャデータを繰り返して表示装置へ出力することで、平面視再生における出力フレームレートを、立体視再生における出力フレームレートと一致させることができる。

　そのため、３Ｄビデオストリームの再生中に立体視再生と平面視再生とを切り替えても、再生装置と表示装置との間でＨＤＭI接続の再同期の必要がなく、シームレスに再生することができる。

記録媒体、再生装置の使用行為についての形態を示す図ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を表す動画像を描いた図立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図多層化された光ディスクの内部構成を示す図ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す図記録方法の処理手順を示すフローチャートビデオストリームの構造を説明する図デコードスイッチ情報の構造を示す図デコードカウンタを説明する図 PESパケット列に、ビデオストリームがどのように格納され、TSパケット及びソースパケットに変換されるかを示す図ＡＶストリームがどのように多重化されるかを模式的に示す図記録方法により得られたエクステントの内部構成を示す図エクステントと、ＡＶストリームファイルとの対応付けを示す図クリップ情報ファイルの内部構成を示す図クリップ情報ファイルにおけるストリーム属性情報を示す図クリップ情報ファイルにおけるエントリーマップテーブルを示す図エントリーマップによるエントリーポイントの登録を示すエントリマップとＧＯＰとの関係を示す図３Ｄメタデータの構造を説明する図 2Dプレイアイテムと、3Dプレイアイテムとの混在が発生していないプレイリストを示す図図２０の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す図２Ｄ映像と３Ｄ映像とが混在する例を示す図２Ｄ映像と３Ｄ映像とが混在する例でのシームレス接続を実現する構成を説明する図２Ｄプレイアイテムと３Ｄプレイアイテムとのシームレス接続を実現するプレイリストの構成を示す図プレイリスト情報のデータ構造を示す図サブパス情報テーブルの内部構成を示す図レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す図ストリーム選択テーブルを示す図図２０の3Dプレイリストに、レフトビュー／ライトビュー識別情報を書き加えた図レフトビュー画像、ライトビュー画像と、センター画像とが、別々に構成されている2つのプレイリスト情報を示す図 2D/3D再生装置の構成を示している図システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す図プレーン加算部の内部構成を示す図 PGプレーンの合成の仕方を示す図オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図レジスタセット１０の内部構成及び再生制御エンジン７bの内部構成を示す図ＰＳＲ２２の表示タイプ値を設定するフローチャート２Ｄプレイリストと３Ｄプレイリストの再生を切り替えるデータ構造を示す図２Ｄプレイリストと３Ｄプレイリストの再生を切り替えるフローチャート３Ｄ映像のＬ・Ｒ表示タイプとＬ・Ｌ表示タイプとのシームレスな切り替えを説明する図プレーン合成部におけるスイッチ６２の切り替え制御を示すフローチャート３Ｄ映像の再生と２Ｄ映像の再生のシームレスな切り替えを実現するプライマリビデオデコーダ３１の構成を示す図３Ｄ映像の再生と２Ｄ映像の再生のシームレスな切り替えを実現するための再生ステータスの役割を説明する二つ目の図再生ステータスを、２Ｄ映像を再生する再生区間に適用することを説明する図エントリマップの変形例を示す図変形例に係るエントリポイントとＡＶストリームの関係を模式的に示す図第２実施形態に係る再生装置のプライマリビデオデコーダの構成を示す図右目映像のピクチャが欠損した場合に、２Ｄ／左目映像のピクチャを右目映像のピクチャとして再生することを説明する図右目映像のピクチャが欠損した場合に、一つ前の右目映像のピクチャを再生することを説明する図右目映像のピクチャが欠損した場合に、一つ前の左目映像と右目映像のピクチャを再生することを説明する図右目映像のピクチャが欠損した場合に、右目映像のピクチャを黒などのピクチャで補完することを説明する図右目映像のピクチャが欠損した場合に、２Ｄ／左目映像のピクチャと右目映像のピクチャを黒などのピクチャで補完することを説明する図右目映像のピクチャが欠損した場合に、左目映像のピクチャと一つ前の右目映像のピクチャで補完することを説明する図２Ｄ映像の再生での一時停止処理を説明する図３Ｄ映像の再生での一時停止処理を説明する図３Ｄ映像の再生での一時停止処理を実現するためのプレーン加算部を説明する図静止画のＧＯＰ構成を説明する図３Ｄ映像の特殊再生を説明する図３Ｄ映像の特殊再生を簡易にするためのデータ構造を説明する図記録装置の内部構成を示す図ビデオエンコーダの奥行き情報作成を説明する図

　(第１実施形態)
　図面を参照しながら、上記課題解決手段を具備した再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。

　一般に右目と、左目は、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。

　具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。

　この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。

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

　２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。

　継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。

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

　BD-ROM１００は、上記ホームシアターシステムに、例えば映画作品を供給する。

　再生装置２００は、テレビ３００と接続され、BD-ROM１００を再生する2D/3D再生装置である。
。この再生装置２００とテレビ３００との接続には、ＨＤＭＩ接続が用いられる。

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

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

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

　以上が、記録媒体及び再生装置の使用形態についての説明である。

　本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。

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

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

　図３は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す図である。

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

　第４段目は、レフトビュービデオストリームの内部構成を示す。このレフトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第３段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。ただし、継時分離方式の立体視再生では、同じPTSが付された左目画像と右目画像とのペアうち一方の表示を、PTSの間隔の半分の時間（以下、「３Ｄ表示ディレイ」という）分だけ遅延して表示する。

　第５段目は、3D眼鏡４００の状態をどのように変化させるかを示す。この第５段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。

　これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。

　例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。

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

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

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

　図４は、多層化された光ディスクの内部構成を示す。

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

　ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで、BD-ROM１００のような読み込み専用ディスクの場合には、基本的に論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。ただし、記録層の境界においては、論理アドレスが連続していたとしても連続的な読み出しはできない。

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

　ファイルシステム上でアクセス可能なファイルのうち、ビデオストリーム及びオーディオストリームを多重化することで得られたAVストリームを格納しているファイルを"ＡＶストリームファイル"という。一方、AVストリーム以外の一般的なデータを格納しているファイルを"非AVファイル"という。

　ビデオストリーム、オーディオストリームを始めとするElementaryストリームは、PESヘッダが付与されたPacketized Elementaryストリーム(PESストリーム)に変換され、TSパケットに変換された上で多重化されている。このTSパケットの単位で多重化されたファイルを、「トランスポートストリームファイル」という。

　これとは異なり、ビデオストリーム、オーディオストリームを始めとするElementaryストリームのPESストリームが、パック列に変換された上で多重化されているファイルを、「プログラムストリームファイル」という。

　BD-ROM、BD-RE、BD-Rに記録されるＡＶストリームファイルは、前者のトランスポートストリームファイルである。DVD-Video、DVD-RW,DVD-R,DVD-RAMに記録されるＡＶストリームファイルは、後者のシステムストリームファイルであり、Video Objectとも呼ばれる。

　第４段目は、ファイルシステムで管理されるパーティション領域の記録内容を示す。パーティション領域には、ＡＶストリームファイルを構成するエクステントと、ＡＶストリームファイル以外の非AVファイルを構成するエクステントが存在する。

　エクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。

　「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。

　次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。

　「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。

　「記述子タグ」は、自身がファイルエントリである旨を示すタグである。

　「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。

　「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。

　「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。

　「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。

　「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。

　これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。

　「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。

　「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261"が記述される。

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

　上述したようなファイルエントリーのアロケーション識別子を参照することで、ＡＶストリームファイルや、非ＡＶファイルを構成するエクステントのアドレスを知得することができる。

　例えば、ＡＶストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。

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

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

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

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

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

　このJava（登録商標）アプリケーションの実体にあたるのが、BDMVディレクトリ配下のJARディレクトリに格納されたJava（登録商標）アーカイブファイル(YYYYY.jar)である。　　　

　アプリケーションは例えばJava（登録商標）アプリケーションであり、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。

　「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls["xxxxx"は可変、拡張子"mpls"は固定])が存在する。

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

　「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi ["xxxxx"は可変、拡張子"clpi"は固定])が存在する。

　「STREAMディレクトリ」は、ＡＶストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts(["xxxxx"は可変、拡張子"m2ts"は固定])という形式でＡＶストリームファイルが格納される。

　STREAMディレクトリにおけるＡＶストリームファイルは、ＭＰＥＧ－２トランスポート・ストリーム（ＴＳ）形式のデジタルストリームであり、ビデオストリーム、オーディオストリーム、グラフィクスストリーム等の複数のエレメンタリ・ストリームが多重化されたものである。

　またＡＶストリームファイルにおいて、レフトビュービデオストリームを格納したパケット、レフトビュー用のグラフィクスストリームを格納したパケット、これらと共に再生されるべきオーディオストリームを格納したパケット等、レフトビュー再生のための複数種別のPESストリームを格納したパケットの集合体を、"レフトビューＡＶストリーム"という。このレフトビューＡＶストリームが、ベースビュービデオストリームを含んでおり平面視再生を可能とするものなら、当該レフトビューＡＶストリームは、"2D／レフトビューＡＶストリーム"と称呼される。尚以降の説明では、特に断らない限り、レフトビュービデオストリームがベースビュービデオストリームであり、レフトビュービデオストリームを含むレフトビューＡＶストリームは、2D/レフトビューＡＶストリームであるものとする。

　更にＡＶストリームファイルにおいて、ライトビュービデオストリームを格納したソースパケット、ライトビュービュー用のグラフィクスストリームを格納したソースパケット、これらと共に再生されるべきオーディオストリームを格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームを格納したパケットの集合体を、"ライトビューＡＶストリーム"という。

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

　以上が記録媒体の内部構成についての説明である。続いて、図４及び図５に示した記録媒体の作り方、つまり、記録方法の形態について説明する。

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

　図６は、記録方法の処理手順を示すフローチャートである。

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

　ステップS３０２は、タイトルに利用する動画、音声、静止画、字幕情報のインポートを行う行程である。

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

　ステップS３０４は、エンコード行程であり、BD-ROMシナリオデータに基づきエンコードを行って、PESストリームを得る。

　ステップS３０５は、BD-ROMシナリオデータに従った多重化行程であり、この行程によってPESストリームを多重化してＡＶストリームを得る。

　ステップＳ３０６では、BD-ROMへの記録のためのデータベースを得る。ここでのデータベースとは、前述のBD-ROMで定義されるインデックステーブル、ムービーオブジェクト、プレイリスト、BD-Jオブジェクトなどの総称である。

　ステップS３０７では、Java(TM)プログラム、多重化行程で得られたＡＶストリーム、BD-ROMデータベースを入力とし、BD-ROMに準拠したファイルシステムフォーマットでＡＶストリームファイル,非AVファイルを作成する。

　ステップＳ３０８は、BD-ROMに記録されるべきデータのうち、非AVファイルの書込行程であり、ステップＳ３０９は、ＡＶストリームファイルの書込行程である。

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

　ステップＳ３０９のＡＶストリームファイル書き込み行程は、ソースパケット列をＡＶストリームファイルのエクステントとして、記録媒体の連続領域に書き込むものである。

　書き込みの対象となるストリームは、以下の通りである。

　・ビデオストリーム
　ビデオストリームは映画のプライマリビデオおよびセカンダリビデオを示す。ここでプライマリビデオとはピクチャインピクチャにおいて親画像として表示される通常の映像を示し、セカンダリビデオとは、ピクチャインピクチャにおいて小画面で表示される映像のことである。プライマリビデオには、レフトビュービデオ、ライトビュービデオの２種類があり、セカンダリビデオにも、レフトビュービデオ、ライトビュービデオの２種類がある。

　ビデオストリームは、上述したMVCの他、MPEG-２、MPEG-4AVC、または、SMPTE VC-１などの方式を使って符号化記録されている。

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

　・Presentation Graphicsストリーム
　Presentation Graphicsストリーム(PGストリーム)は、映画の字幕や、キャラクタ等、ピクチャと緻密に同期すべきグラフィクスを示すグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。

　PGストリームは、PCS(Presentation Control Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(Object Define Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。

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

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

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

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

　ビデオストリームは、複数のＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）から構成されており、これを符合化処理の基本単位とすることで動画像の編集やランダムアクセスが可能となっている。

　図７（ａ）は、ピクチャがどのようにＧＯＰに格納されるかの対応関係を示している。本図における第１段目は、レフトビュービデオストリームのピクチャ列とＧＯＰの対応関係を示し、第２段目は、ライトビュービデオストリームのピクチャ列とＧＯＰの対応関係を示す。本図では、レフトビュービデオストリーム及びライトビュービデオストリームで、表示時刻が同じピクチャを揃えて描いている。レフトビュービデオストリーム、ライトビュービデオストリームのＧＯＰ先頭は、いずれもＩピクチャである。また、ライトビュービデオストリームのＧＯＰ先頭のピクチャは、立体視映像を再生する際にレフトビュービデオストリームのＧＯＰ先頭のＩピクチャとペアで表示されるピクチャであり、レフトビュービデオストリームのＧＯＰ先頭のＩピクチャと表示時刻が同じピクチャである。

　図７（ｂ）は、ＧＯＰの構造を示している。ＧＯＰは１つ以上のビデオアクセスユニットにより構成されている。ビデオアクセスユニットは、ピクチャの符合化データを格納する単位であり、フレーム構造の場合は１フレーム、フィールド構造の場合の１フィールドのデータが格納される。

　ＧＯＰ先頭のビデオアクセスユニットは、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータからなり、Ｉピクチャのデータが格納される。シーケンスヘッダは、当該ＧＯＰで共通の情報を格納したヘッダであり、解像度、フレームレート、アスペクト比、ビットレートなどの情報が格納される。ここで、ライトビュービデオストリームのＧＯＰのシーケンスヘッダのフレームレート、解像度、アスペクト比の値は、対応するレフトビュービデオストリームのＧＯＰのシーケンスヘッダのフレームレート、解像度、アスペクト比と同じである。ピクチャヘッダはピクチャ全体の符合化の方式などの情報を格納したヘッダである。補足データは圧縮ピクチャデータの復号に必須ではない付加情報であり、例えば、映像と同期してＴＶに表示するクローズドキャプションの文字情報やタイムコード情報などがある。圧縮ピクチャデータは圧縮符合化されたピクチャデータである。ＧＯＰ先頭以外のビデオアクセスユニットは、ピクチャヘッダ、補足データ、圧縮ピクチャデータからなる。

　ここで、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータの中身の構成は、ビデオの符合化方式によって異なる。例えば、ＭＰＥＧ－４　ＡＶＣの場合であれば、シーケンスヘッダはＳＰＳ（シーケンスパラメータセット）に、ピクチャヘッダはＰＰＳ（ピクチャパラメータセット）に、補足データはＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ　Ｅｎｈａｎｃｅｍｅｎｔ　Ｉｎｆｏｒｍａｔｉｏｎ）に対応する。

　図８はレフトビュービデオストリームとライトビュービデオストリームの各ビデオアクセスユニットに付与されたデコードスイッチ情報を示している。ビデオデコーダでは、レフトビュービデオストリームのビデオアクセスユニットとライトビュービデオストリームのビデオアクセスユニットとをスイッチしながらデコード処理を行う。通常のビデオデコーダは、ビデオアクセスユニットに付与されたＤＴＳの時刻によって次にデコードするビデオアクセスユニットを特定することができる。しかし、ＤＴＳを無視して前倒ししてデコードをするビデオデコーダも多く存在する。その場合に、ビデオストリームの各ビデオアクセスユニットの中に、次にデコードするビデオアクセスユニットを特定する情報があることが好ましい。図８に示すデコードスイッチ情報は、ビデオアクセスユニットのスイッチ処理を支援するための情報である。

　図８の上段は、デコードスイッチ情報の構造を示しており、図８の下段は１つのビデオアクセスユニットのデータ構造を示している。デコードスイッチ情報は、ビデオアクセスユニット毎に、ビデオアクセスユニット内の補足データ領域（ＭＰＥＧ－４　ＡＶＣの場合はＳＥＩ）に格納される。

　デコードスイッチ情報は、次アクセスユニットタイプと次アクセスユニットサイズ、及びデコードカウンタから構成されている。

　次アクセスユニットタイプは、次にデコードするビデオアクセスユニットがレフトビュービデオストリームとライトビュービデオストリームとのどちらなのかを示す情報である。値が「１」の場合はレフトビュービデオストリームのビデオアクセスユニットを示し、値が「２」の場合はライトビュービデオストリームのビデオアクセスユニットを示し、「０」の場合は現在のビデオアクセスユニットがストリーム終端のビデオアクセスユニットであることを示す。

　次アクセスユニットサイズは、次にデコードするビデオアクセスユニットのサイズ情報である。もし、次にデコードするビデオアクセスユニットのサイズが不明であるならば、デコード前のビデオアクセスユニットが格納されたバッファからビデオアクエスユニットを引き抜く際に、アクセスユニットの構造を解析してサイズを特定する必要が生じる。しかし、次アクセスユニットサイズがあることで、ビデオデコーダは次のビデオアクセスユニットの構造を解析することなくサイズを特定できる。そのため、デコード前のピクチャが格納されたバッファから引き抜く処理を簡易に行うことができる。

　デコードカウンタは、図９（ａ）に示すようにレフトビュービデオストリームのＧＯＰ先頭のＩピクチャを０としたときに、レフトビュービデオストリームとライトビュービデオストリームとのビデオアクセスユニットをデコード順にインクリメントしたカウンタである。
この情報を使えば、何かの原因でビデオアクセスユニットが読めなかったときのエラー処理を適切に行うことができる。例えば、図９（ａ）のようにレフトビュービデオストリームの３番目のビデオアクセスユニット（Ｂｒピクチャ）が、読み込みエラーで読めなかったとすると、何も情報がない場合、ライトビュービデオストリームの３番目のビデオアクセスユニット（Ｂピクチャ）は、レフトビュービデオストリームの３番目のビデオアクセスユニットを参照するため、誤ったデコードを行いノイズののった画像をデコードしてしまう可能性がある。このときに、ライトビュービデオストリームの２番目のビデオアクセスユニット（Ｐピクチャ）のデコードカウンタの値を保持しておけば、次に来るべきアクセスユニットのデコードカウンタの値を予測できるため、デコーダは適切なエラー処理を行うことができる。図９（ａ）の例では、ライトビュービデオストリームの２番目のビデオアクセスユニット（Ｐピクチャ）のデコードカウンタ４は「４」であるため、次に来るべきデコードカウンタは「５」であるはずだが、実際には読み込めるビデオアクセスユニットはレフトビュービデオストリームの４番目のビデオアクセスユニット（Ｐピクチャ）でデコードカウンタは「７」になっている。このため、ビデオデコーダでは、ビデオアクセスユニットをひとつスキップしたことが判断できる。これにより、例えば、ライトビュービデオストリームの３番目のビデオアクセスユニット（Ｂピクチャ）は参照先のピクチャが無いと判断してデコードをスキップする、といった処理を行うことができる。

　なお、図９（ｂ）のようにデコードカウンタを映像ビデオストリーム毎に完結する値にしても良い。この場合も、直前にデコードしたのがレフトビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタと同じであると予測できる。直前にデコードしたのがライトビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタに１足したものと同じであると予測できるため、同様に適切なエラー処理を行うことができる。

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

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

　第１段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ４Byteの「TSヘッダ」とデータを格納する１８４Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。

　第２段目によると、TSパケットには、４ByteのTP＿Extra＿Headerが付与されて、１９２Byteのソースパケットに変換された状態で、ＡＶストリームに書き込まれる。TP＿Extra＿HeaderにはATS（Arrival＿Time＿Stamp）などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。ＡＶストリームには、第３段目に示すようにソースパケットが並ぶこととなり、ＡＶストリームの先頭からインクリメントする番号はSPN（ソースパケットナンバー）と呼ばれる。

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

　Arrival Time Clock(ATC)時間軸において、ATSが連続しているソースパケットの集まりをATCシーケンスといい、System Time Clock(STC)時間軸においてデコードタイムスタンプ(DTS),プレゼンテーションタイムスタンプ(PTS)が連続しているソースパケットの集まりを、STCシーケンスという。

　図１２は、記録方法により得られたエクステントを示す。第１段目は、ＡＶストリームファイルを構成するエクステントEXT＿L[i],EXT＿L[i+1],EXT＿R[i],EXT＿R[i+1]を示す。

　第２段目は、各エクステント内に属するソースパケット列を示す。

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

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

　エクステントEXT＿L[i]のサイズをSEXT＿L[i]と呼び、エクステントEXT＿R[i]のサイズをSEXT＿R[i]と呼ぶ。

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

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

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

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

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　になる。

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

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

　　　　　　　　　　　　　　　　　　　　　　　になる。

　ライトビュー用リードバッファ,レフトビュー用リードバッファのメモリサイズの具体的な値としては、1.5Mbyte以下であり、本実施形態においてエクステントサイズSEXT＿R、SEXT＿Lは、このライトビュー用リードバッファ,レフトビュー用リードバッファのサイズと同じサイズか、またはこれにほぼ等しいサイズに設定されている。このようなエクステントの物理的なファイル配置によって、ＡＶストリームは映像や音声を途中でとぎれさせることなくシームレスに再生されることが可能となる。以上がレフトビューＡＶストリーム、ライトビューＡＶストリームの記録のされ方についての説明である。続いて、レフトビューＡＶストリーム及びライトビューＡＶストリームの内部構成について説明する。図１２の第１段目を参照しながら、エクステントEXT＿R[i]、エクステントEXT＿L[i]の内部構成について説明する。

　エクステントEXT＿L[i]は、以下のソースパケットによって構成されている。

　0x0100のパケットIDを有するソースパケットはProgram＿mapを構成し、0x1001のパケットIDをを有するTSパケットはPCRを構成する。

　0x1011のパケットIDを有するソースパケットはレフトビュービデオストリーム、
　0x1220～123FのパケットIDを有するソースパケットはレフトビューPGストリーム、
　0x1420～143FのパケットIDを有するソースパケットはレフトビューIGストリーム
　0x1100から0x111FまでのPIDを有するソースパケットはオーディオストリームを構成する。

　エクステントEXT＿R[i]は、以下のソースパケットによって構成されている。

　Ox1012のTSパケットはライトビュービデオストリームを構成し、Ox1240～125FのソースパケットはライトビューPGストリームを構成し、Ox1440～145FのソースパケットはライトビューIGストリームを構成する。

　ＡＶストリームに含まれるソースパケットには、映像・音声・グラフィクスなどの各ストリーム以外にもPAT（Program Association　Table）、PMT（Program Map　Table）、PCR（Program Clock　Reference）などがある。PATはＡＶストリーム中に利用されるPMTのPIDが何であるかを示し、PAT自身のPIDは0x0000で登録される。PMTは、ＡＶストリームファイル中に含まれる映像・音声・グラフィクスなどの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、またＡＶストリームに関する各種ディスクリプタを持つ。ディスクリプタにはＡＶストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。PCRは、ATSの時間軸であるATC（Arrival Time Clock）とPTS・DTSの時間軸であるSTC（System　Time　Clock）の同期を取るために、そのPCRパケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。

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

　ファイルシステムにおいて、図１２に示したエクステントがどのように取り扱われているかについて説明する。

　図１３は、エクステントと、ＡＶストリームファイルとの対応付けを示す図である。

　第１段目は、ライトビューのエクステント、レフトビューのエクステントを示す。第２段目は、インターリーブ形式のＡＶストリームファイルであるXXXXX.m2tsを示す。

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

　以上がＡＶストリームを格納したＡＶストリームファイルについての説明である。続いてクリップ情報ファイルについて説明する。

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

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

　図１５は、クリップ情報ファイルにおけるストリーム属性情報を示す図である。

　図中の引き出し線ah1は、ストリーム属性情報の内部構成をクローズアップして示している。

　この引出線に示すように、PID＝0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性情報、PID＝0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性情報、PID＝0x1100、PID＝0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性情報、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性情報というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性情報に示されている。この引出線ah1に示すように、ＡＶストリームファイルに含まれる各ストリームについての属性情報が、PID毎に登録される。各ストリームの属性情報はストリームの種別毎に異なる情報を持つ。ビデオストリーム属性情報は、そのビデオストリームがどのような圧縮コーデックで圧縮されたか、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか、アスペクト比はどれだけであるか、フレームレートはどれだけであるかなどの情報を持つ。オーディオストリーム属性情報は、そのオーディオストリームがどのような圧縮コーデックで圧縮されたか、そのオーディオストリームに含まれるチャンネル数は何であるか、何の言語に対応するか、サンプリング周波数がどれだけであるかなどの情報を持つ。これらの情報は、プレーヤが再生する前のデコーダの初期化などに利用される。

　ビデオストリーム属性情報について説明する。レフトビュービデオストリームのPID=0ｘ1011のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度と、対応するライトビュービデオストリームのPID=0ｘ1012のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度とは一致しなければならない。コーデックが同じでない場合にはビデオストリーム間での参照関係が成り立たず、また、ディスプレイに同期して３Ｄ映像として再生するためにはフレームレート、アスペクト比、解像度を一致しなければユーザに違和感を与えてしまうためである。

　また、ライトビュービデオストリームのビデオストリーム属性情報に、デコードにレフトビューストリームを参照するビデオストリームであることを示すフラグを入れても良い。また、参照先のビデオストリームの情報を含めておいても良い。このような構成にすることにより、作成されたデータが規定のフォーマットどおりに作られているかを検証するツールが、ビデオストリームの対応関係を判断することができる。

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

　『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。

　『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。この情報を参照することにより２Ｄ／３Ｄ再生装置は、レフトビューＡＶストリームのエクステントとライトビューＡＶストリームのエクステントとのうち、どちらのエクステントからＢＤ－ＲＯＭドライブに再生要求を出すべきかを簡易に判断することができる。

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

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

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

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

　EP＿ID=2に対応するエントリーマップは、SPN=3200のソースパケットを指し示しており、このソースパケット番号をPTS=360000に対応付けている。EP＿ID=3に対応するエントリーマップは、SPN=4800のソースパケットを指し示しおり、このソースパケット番号をPTS=450000と対応付けている。

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

　ここで、レフトビュービデオストリームのＧＯＰ先頭のＩピクチャと、そのＧＯＰに対応するライトビュービデオストリームのＧＯＰ先頭のIピクチャとのうち、片方しかエントリマップに登録されていない場合、飛び込み再生などのランダムアクセス時に、立体視映像として再生することが困難になってしまう。例えば、図１８（ｂ）のＢＬ１、ＢＬ３、ＢＬ５は、それぞれレフトビュービデオストリームのＧＯＰ＃Ｌ１、ＧＯＰ＃Ｌ３、ＧＯＰ＃Ｌ５の先頭のＩピクチャを指すエントリポイントである。ここでＢＬ３に飛び込み再生をする場合に、ＧＯＰ＃Ｌ３に対応するライトビューストリームのＧＯＰ、つまりＧＯＰ＃Ｒ３のピクチャを指すエントリポイントが存在しないため、クリップ情報ファイルからＧＯＰ＃Ｒ３の先頭ピクチャのＳＰＮ情報が取得できない。そのため、3D映像の再生時にＧＯＰ＃Ｌ３の先頭から飛び込み再生する場合には、ライトビューストリームのＧＯＰ＃Ｒ３より前に位置するエントリポイントＢＲ２が指すＧＯＰ＃Ｒ２のピクチャのＳＰＮからデータを解析して、ＧＯＰ＃Ｒ３の先頭ピクチャの開始ＳＰＮを取得する必要があり、飛び込み再生時のレスポンスが悪くなってしまう。

　そこで、図１８（ａ）に示すように、レフトビュービデオストリームのＧＯＰ先頭のＩピクチャと、そのＧＯＰに対応するライトビュービデオストリームのＧＯＰ先頭のピクチャは、常にどちらもエントリマップに登録されるようにする。このように構成することで、レフトビュービデオストリームのＧＯＰ先頭のＳＰＮとそのＧＯＰに対応するライトビュービデオストリームのＧＯＰ先頭のＳＰＮとを、両方エントリーマップから取得できるため、飛び込み再生時のレスポンスの悪化を防ぐことができる。

　以上がエントリーマップテーブルについての説明である。続いて、3Dメタデータの詳細について説明する。

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

　３Ｄメタデータはプレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームの２Ｄイメージに奥行き情報を追加するための情報である。３Ｄメタデータは、図１９の上段に示すように、ＡＶストリームファイル内に含まれるプレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームのＰＩＤ毎に、３Ｄ映像の表示時刻を示すＰＴＳと、右目左目のピクセルのずれを示すオフセット値が記載されたテーブル情報である。オフセット値はＸ軸方向へのピクセル数であり、マイナス値も許される。ここではテーブルの１つの行で示される対となるＰＴＳとオフセット値の情報をオフセットエントリと呼ぶことにする。図１９の下段に示すように、オフセットエントリの有効区間は、該当オフセットエントリのＰＴＳから次のオフセットエントリのＰＴＳまでである。例えば、オフセットエントリ＃１のＰＴＳが１８００００で、オフセットエントリ＃２のＰＴＳが２７００００である場合は、オフセットエントリ＃１のオフセット値は１８００００から２７００００まで有効となる。後述する２Ｄ／３Ｄ映像装置のプレーン加算部５ｂは、この情報値に基づき、ＰＧプレーン、ＩＧプレーン、副映像プレーンを左右にオフセット値をずらしながらプレーン合成をする。これによって、視差画像をつくり出すことができ、２次元映像に対して立体的な奥行きを付加することができる。プレーン合成の方法の詳細については、プレーン加算部５ｂで説明する。なお、ここでは３ＤメタデータはＰＩＤ毎に設定されるとしたが、例えば各プレーンごとに設定できても良い。これにより２Ｄ／３Ｄ再生装置の３Ｄメタデータの解析処理を簡素化できる。なお、２Ｄ／３Ｄ再生装置の合成処理の性能を踏まえて、オフセットエントリの間隔に例えば１秒以上とするなどのように制約をつけても良い。

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

　　＜プレイリスト情報ファイル＞
　プレイリストは、ＡＶストリームファイルの再生経路を示すものである。プレイリストは１つ以上のプレイアイテムから構成され、各プレイアイテムはＡＶストリームに対する再生区間を示す。各プレイアイテムは、それぞれプレイアイテムＩＤで識別され、プレイリスト内で再生されるべき順序で記述されている。また、プレイリストは再生開始点を示すエントリマークを含んでいる。エントリマークはプレイアイテムで定義される再生区間内に対して付与することでき、プレイアイテムに対して再生開始点となりうる位置に付けられ、頭出し再生に利用される。例えば、映画タイトルにおいて、エントリマークをチャプタの先頭となる位置に付与することで、チャプタ再生することが可能である。

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

　「メインパス」は、1つ以上のプレイアイテムから構成される。図中の例では、プレイアイテム#1、#2、#3から構成されていることがわかる。

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

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

　「AVクリップ#1,#2,#3」は、2D映像として再生されるＡＶストリームであるとともに、3D映像として再生する時にはレフトビューとして再生されるＡＶストリームである。

　「AVクリップ#4,#5,#6」は3D映像として再生する時にはライトビューとして再生されるＡＶストリームである。

　2Dプレイリストのメインパスは、レフトビューＡＶストリームを格納するAVクリップ#1,#2,#3を符号rf1,2,3に示すように参照している。

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

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

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

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

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

　次に、２Ｄプレイアイテムと３Ｄプレイアイテムとが混在するプレイリストについて説明する。このようなプレイリストでは、２Ｄプレイアイテムと３Ｄプレイアイテムとをシームレスに接続する必要がある。

　３Ｄ映像を格納するコンテンツは、全編すべてが３Ｄ映像という構成とは限らず、２Ｄ映像と３Ｄ映像が混在するケースがある。そのため、２Ｄ映像と３Ｄ映像をシームレスに再生することが求められる。図２２（ａ）は、２Ｄ映像と３Ｄ映像が混在する例を示している。再生区間＃１は３Ｄ映像を再生する区間で、レフトビュービデオストリームとライトビュービデオストリームとの両方が再生され、左目画像と右目画像とが交互に表示される。レフトビュービデオストリームのフレームレートを１秒間にＮフレームのフレームレートとすると、ライトビュービデオストリームのフレームレートも１秒間にＮフレームのフレームレートとなり、レフトビュービデオストリームのフレームとライトビュービデオストリームのフレームは交互に表示されるため、３Ｄ映像全体のフレームレートは１秒間にＮ×２フレームのフレームレート（Ｎ×２Ｈｚ）となる。一方、再生区間＃２は２Ｄ映像を再生する区間で、レフトビュービデオストリームのみが再生されるため、フレームレートは１秒間にＮフレームのフレームレート（Ｎ　Ｈｚ）となる。図２１（ａ）の例では、再生区間＃２は１秒間に２４フレームのフレームレート（２４Ｈｚ）としている。また、再生区間＃１と再生区間＃３とは同じ構成であり、フレームレートは２４×２Ｈｚとなり、４８Ｈｚとしている。

　ここで、再生区間＃１、再生区間＃２、再生区間＃３を順に再生する場合、再生区間でフレームレートが異なることになる。フレームレートが異なると、再生装置とテレビとのＨＤＭＩ接続を再設定する必要があるため、再設定のための遅延が発生しシームレス再生が保証されない。そこで、図２１（ｂ）の再生区間＃５のように、２Ｄ映像を再生する区間であっても、他の３Ｄ映像再生区間（再生区間＃４と再生区間＃６）のフレームレートに合わせるために、レフトビュービデオストリームと同じ映像を、ライトビュービデオストリームとして格納する方法が考えられる。この場合には、再生区間＃５は、３Ｄ映像の再生と同じフレームレートで再生されるため、再生区間＃４、再生区間＃５、再生区間＃６を順に再生しても、フレームレートの切り替えによるＨＤＭＩ接続の再設定の遅延は発生しなくなる。しかし、このような構成では、再生区間＃５は、２Ｄ映像でありながら、レフトビュービデオストリームとライトビュービデオストリームの２つを用意する必要が生じ、データ量が増えてしまうとともに、データ作成が煩わしくなる。

　そこで、図２３のように、各再生区間には再生方法を識別するフィールドである重複フラグを用意し、３Ｄ映像を再生する区間には３Ｄ映像を再生するためのレフトビュービデオストリームとライトビュービデオストリームを用意し、２Ｄ映像を再生する区間には２Ｄ映像を再生するためのレフトビュービデオストリームのみを用意する。再生方法には２種類有り、「ピクチャを１度ずつ再生する（以降、通常再生と呼ぶ）」と「１枚のピクチャを２度ずつ再生する（以降、重複再生と呼ぶ）」とである。再生装置はこのフィールドに従って各再生区間の再生処理を行う。このような構成にすることにより、３Ｄ映像を再生する区間では重複フラグが「通常再生」を指示し、２Ｄ映像を再生する区間では重複フラグが「重複再生」を指示していれば、３Ｄ映像を再生する区間と２Ｄ映像を再生する区間のフレームレートが同じになるため、再生区間の切り替え時にＨＤＭＩ接続の再同期による遅延を発生させることなく、シームレスに再生することが可能である。また、３Ｄ映像を再生する区間で重複フラグが「通常再生」を指示しており、２Ｄ映像を再生する区間で重複フラグが「通常再生」を指示していれば、３Ｄ映像を再生する区間と２Ｄ映像を再生する区間のフレームレートが同じにならないため、再生区間の切り替え時に遅延が発生しシームレスに再生できなくなるが、高フレームレートで再生するとテレビ側の処理に負荷がかかる場合（例えば、電力量など）には、２Ｄ映像の再生時の処理の負荷を軽減できる。

　例えば図２３の例では、３Ｄ映像を再生する再生区間＃１と再生区間＃３の重複フラグは「通常再生」を指示し、２Ｄ映像を再生する再生区間＃２の重複フラグは「重複再生」を指示している。再生区間＃１と再生区間＃３には、３Ｄ映像を再生するためのレフトビュービデオストリームとライトビュービデオストリームが用意されているが、再生区間＃２には、２Ｄ映像を再生するためのレフトビュービデオストリームのみが用意される。再生装置は、再生区間＃１と再生区間＃３では通常通りにレフトビュービデオストリームの画像とライトビュービデオストリームの画像とを交互に再生表示するが、再生区間＃２ではレフトビュービデオストリームの各ピクチャを２度ずつ再生表示する。

　具体的な３Ｄプレイリストのデータ構造について図２４を用いて説明する。３Ｄプレイリストの３Ｄ映像の再生区間であるプレイアイテム＃１とプレイアイテム＃３とは、レフトビュービデオストリームを格納するレフトビューＡＶストリームを参照するとともに、そのプレイアイテムと同期して再生するサブプレイアイテム＃１とサブプレイアイテム＃２はライトビュービデオストリームを格納するライトビューＡＶストリームを参照する。また、２Ｄ映像の再生区間であるプレイアイテム＃２は、レフトビュービデオストリームを格納するレフトビューＡＶストリームのみを参照する。また、これらのプレイリスト内の各プレイアイテムはコネクションコンディションでシームレスに接続されるように設定されている。ここで、各プレイアイテムには、このプレイアイテムの再生区間の重複フラグが用意されている。重複フラグが「０」の場合は「通常再生」を示し、重複フラグが「１」の場合は「重複再生」を示し、再生装置は、各プレイアイテムの重複フラグを参照して再生処理を行う。

　なお、図２４では、プレイアイテムに重複フラグというフィールドを設けたが、このように明示的なフィールドを設けずに、「再生区間が２Ｄ映像を格納するか、否か」を再生方法の識別情報とする構成にしてもよい。例えば、２Ｄ映像を再生するプレイアイテムと同期して再生するサブプレイアイテムから参照するＡＶストリームがない場合に「重複再生」を示すとしても良いし、あるいは、２Ｄ映像を再生するプレイアイテムと同期して再生するサブプレイアイテムから参照するＡＶストリームがレフトビューＡＶストリームである場合に「重複再生」を示すとしても良いし、またあるいは、２Ｄ映像を再生するプレイアイテムと同期して再生するサブプレイアイテムがない場合に「重複再生」を示すとしても良い。

　なお、プレイリスト内に２Ｄプレイアイテムと３Ｄプレイアイテムとが混在することを禁止しても良い。このようにすることで２Ｄ映像と３Ｄ映像との切り替え時のフレームレート変更による遅延の問題を容易に回避できる。

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

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

　以降、『STN＿table』、『レフトビュー／ライトビュー識別情報』、『multi＿clip＿entry』について説明する。

　『STN＿table(STream Number＿table)』は、パケットIDを含むストリームエントリー及びストリーム属性の組みに、論理的なストリーム番号を割り当てるテーブルである。STN＿tableにおけるストリームエントリー及びストリーム属性の組みの順序は、対応するストリームの優先順位を示す。このSTN＿tableは、2D再生のためのものであり、3D再生のためのSTN＿tableは別に存在する。

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

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

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

　また、connection＿conditionが「６」の場合は、接続前プレイアイテムのＡＶストリームと接続後プレイアイテムのＡＶストリームを結合したときに１本のAVクリップとして再生できなければならない。つまり、接続前プレイアイテムのＡＶストリームと接続後プレイアイテムのＡＶストリーム間でSTCは連続し、またATCも連続する。

　『Multi＿clip＿entries』は、プレイアイテムでマルチアングル区間を形成する場合、個々のアングル映像を表すＡＶストリームがどれであるかを特定するための情報である。

　以上がメインパス情報についての説明である。続いて、サブパス情報テーブルの詳細について説明する。

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

　『Clip＿information＿file＿name』は、クリップ情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。

　『Clip＿codec＿identifier』は、ＡＶストリームファイルの符号化方式を示す。

　『ref＿to＿STC＿id[0]』は、このSubPlayItemが対象としているSTC＿Sequenceを一意に示す。

　『SubPlayItem＿In＿time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。

　『SubPlayItem＿Out＿time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。

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

　『sync＿start＿PTS＿of＿PlayItem』は、sync＿PlayItem＿idで指定されたPlay Itemの再生時間軸上において、SubPlayItem＿In＿timeで指定されたSubPlayItemの始点が、どこに存在するかを45KHzの時間精度で示す。

　図２７は、レフトビュー、ライトビューに対して、どのような再生区間が定義されているかを示す。本図は、図１７をベースとして作図されており、このベースとなる図の第２段目の時間軸に、PlayItemのIn＿Time及びOut＿Timeを描いている。第１段目の時間軸に、SubPlayItemのIn＿Time及びOut＿Timeを描いている。第３段目から第４段目は、図１７の第２段目から第３段目と同一である。レフトビュー、ライトビューのIピクチャは、時間軸において同じ時点になる。以上がプレイリスト情報のデータ構造についての説明である。

　以上がサブパス情報についての説明である。続いて、エントリーマーク情報の詳細について説明する。

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

　以上がエントリーマーク情報についての説明である。続いて、エクステンションデータの詳細について説明する。

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

　続いて、上述したPlayItem情報の内部構成のうち、ストリーム選択テーブルの詳細について説明する。

　図２８（ａ）は、ストリーム選択テーブルを示す。ストリーム選択テーブルは、複数のストリームエントリから構成される。このストリームエントリーは、図中の括弧記号“｝”に示すように、STN＿table内で定義されるものと、STN＿table＿SS内で定義されるものとがある。

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

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

　同図（ｂ）は、ストリームエントリーの共通構成を示す図である。本図に示すように、ストリーム選択テーブルにおけるストリームエントリは、『ストリーム選択番号』、『ストリームパス情報』、『ストリーム識別情報』から構成される。

　『ストリーム選択番号』は、ストリーム選択テーブルに含まれるストリームエントリ１の先頭から順にインクリメントされる番号であり、再生装置でのストリーム識別のために利用される。

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

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

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

　以上がストリーム選択テーブルについての説明である。続いて、レフトビュー／ライトビュー識別情報の詳細について説明する。

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

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

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

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

　また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。

　以上がレフトビュー／ライトビュー識別情報についての説明である。このレフトビュー／ライトビュー識別情報は、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。しかし視差画像の内容によっては、このように平面視画像として利用することに向いていないことがある。

　以下、平面視画像として利用することに不向きなレフトビュー画像、ライトビュー画像について説明する。

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

　本図において、00005.mplsは、飛び出し度合が大きいレフトビュービデオストリーム、及び、ライトビュービデオストリームを、メインパス情報及びサブパス情報として指定している。

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

　以上が記録媒体の実施行為及び記録方法の実施行為についての説明である。続いて、再生装置の詳細について説明する。

　図３１は、2D/3D再生装置の構成を示している。2D/3D再生装置２００は、BDドライブ１、リードバッファ２a、リードバッファ２b、スイッチ３、システムターゲットデコーダ４、プレーンメモリセット５ａ、プレーン加算部５ｂ、HDMI送受信部６、再生制御部７、管理情報メモリ９、レジスタセット１０、プログラム実行部１１、プログラムメモリ１２、HDMVモジュール１３、BD-Jプラットフォーム１４、ミドルウェア１５、モード管理モジュール１６、ユーザイベント処理部１７、ローカルストレージ１８、不揮発メモリ１９から構成されている。

　BD-ROMドライブ１は、2D再生装置と同様に再生制御部７からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたＡＶストリームファイルはリードバッファ２aかリードバッファ２bに転送される。

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

　リードバッファ２aは、BD-ROMドライブ１が読み込んだ2D/レフトビューＡＶストリームのデータを格納するデュアルポートメモリ等で構成されたバッファである。

　リードバッファ２bは、BD-ROMドライブ１が読み込んだライトビューＡＶストリームのデータを格納するデュアルポートメモリ等で構成されたバッファである。

　スイッチ３は、リードバッファに対するデータ入力源を、BD-ROMドライブ１又はローカルストレージ１８の何れかに切り替えるためのスイッチである。

　システムターゲットデコーダ４は、リードバッファ２aに読み出されたソースパケットとリードバッファ２bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。

　プレーンメモリセット５aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、インタラクティブグラフィックスプレーン（IGプレーン）、プレゼンテーショングラフィックスプレーン（PGプレーン）といったものがある。

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

　プレーン加算部５ｂは、IGプレーンにおけるグラフィクスをAPIから指定されたオフセット情報を使って左目と右目用に交互にクロッピングし、レフトビュービデオプレーンもしくはライトビュービデオプレーンとセカンダリビデオプレーンとPGプレーンとIGプレーンとが重畳されたイメージを、テレビに出力する。

　テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。

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

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

　上述したような制御において再生制御部７は、ファイルオープンのためのシステムコールを行うことで、これらのファイルをメモリに読み出すことができる。

　ファイルオープンとは、ファイルシステムが、システムコール時に与えられたファイル名によってディレクトリを検索し、ファイルが存在すればFCB(File Control Block)を確保して、ファイルハンドルの番号を返す処理をいう。FCBは、目的のファイルのディレクトリエントリーの内容がメモリ上にコピーされることにより生成される。以後、再生制御部７はそのファイルハンドルをＢＤ－ＲＯＭドライブ１に提示することにより、目的のファイルをＢＤ－ＲＯＭから、メモリへ転送させることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　不揮発メモリ１９は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット１０における記憶内容のバックアップに用いられる。

　次に、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成について説明する。図３２は、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す図である。本図に示すように、システムターゲットデコーダ４及びプレーンメモリセット５aは、ATCカウンタ２１、ソースデパケタイザ２２、PIDフィルタ２３、STCカウンタ２４、ATCカウンタ２５、ソースデパケタイザ２６、PIDフィルタ２７、プライマリビデオデコーダ３１、レフトビュービデオプレーン３２、ライトビュービデオプレーン３３、セカンダリビデオデコーダ３４、セカンダリビデオプレーン３５、PGデコーダ３６、PGプレーン３７、IGデコーダ３８、IGプレーン３９、プライマリオーディオデコーダ４０、セカンダリオーディオデコーダ４１、ミキサー４２、レンダリングエンジン４３、GFXプレーン４４から構成される。

　ATCカウンタ２１は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。

　ソースデパケタイザ２２は、リードバッファ２aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、ＡＶストリームファイルの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。

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

　STCカウンタ２４は、System Time Clock(STC)を生成し各デコーダの動作タイミングを調整する。

　ATCカウンタ２５は、Arrival Time Clock(ATC)を生成して、再生装置内の動作タイミングを調整する。

　ソースデパケタイザ２６は、リードバッファ２abにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、ＡＶストリームファイルのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。

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

　プライマリビデオデコーダ３１は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをバイトコードインタプリタ３２に書き込む。

　レフトビュービデオプレーン３２は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。

　ライトビュービデオプレーン３３は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。

　セカンダリビデオデコーダ３４は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻（PTS）のタイミングでピクチャをセカンダリビデオプレーンに書き出す。

　セカンダリビデオプレーン３５は、システムターゲットデコーダ４からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。

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

　PGプレーン３７には、プレゼンテーショングラフィックスストリームをデコードすることで得られた非圧縮のグラフィックスオブジェクトが格納される。

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

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

　プライマリオーディオデコーダ４０は、プライマリオーディオストリームをデコードする。

　セカンダリオーディオデコーダ４１は、セカンダリオーディオストリームをデコードする。

　ミキサー４２は、プライマリオーディオデコーダ４０のデコード結果と、セカンダリオーディオデコーダ４１のデコード結果とを合成する。

　レンダリングエンジン４３は、JPEG，PNGなど、BD-Jアプリケーションがメニュー描画に利用するグラフィックスデータをデコードする。

　GFXプレーン４４は、JPEG，PNGなどのグラフィックスデータがデコードされた後、書き込まれるプレーンメモリである。

　次にプライマリビデオデコーダ３１の内部構成について説明する。プライマリビデオデコーダ３１は、TB５１、MB５２、EB５３、TB５４、MB５５、EB５６、ビデオデコーダ５７、バッファスイッチ５８、DPB５９、ピクチャスイッチ６０から構成される。

　Transport Buffer(TB)５１は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ２３から出力された際、TSパケットのまま一旦蓄積されるバッファである。

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

　Elementaly Buffer(EB)５３は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。

　Transport Buffer(TB)５４は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。

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

　Elementaly Buffer(EB)５６は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。

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

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

　Decoded PIcture Buffer(DPB)５９は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ５７が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。

　ピクチャスイッチ６０は、ビデオデコーダ５７から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。

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

　プレーンメモリセット５ａには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンがあり、これらは、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーン、GFXプレーンの順に並んでいる。レフトビュービデオプレーンとライトビュービデオプレーンには、システムターゲットデコーダ４よりPTSのタイミングで映像データが書き出される。

　スイッチ６２は、ＰＳＲ２２に設定されている値、及び再生中のプレイアイテムの重複フラグに基づいてレフトビュービデオプレーン、ライトビュービデオプレーンの何れかに経路を切り替え、経路を切り替えた側のプレーンを選択して、セカンダリビデオプレーン、PGプレーン、IGプレーンとの重畳処理に転送する。

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

　図３４は、PGプレーンの合成の仕方を示す図である。

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

　プレーン加算部５ｂは、重畳する映像プレーンがライトビュービデオプレーンの場合は、PGプレーンをオフセット値だけX軸の負の方向をずらし、レフトビュービデオプレーンにはみ出ないようにPGプレーンをクロッピングした後に重畳する（図３４下段参照）。IGプレーン、セカンダリビデオプレーンも同様に処理を行う。

　図３５は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクリッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である。

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

　図３６は、レジスタセット１０の内部構成及び再生制御エンジン７bの内部構成を示す図である。

　本図の左側にはレジスタセット１０の内部構成を示している。右側には再生制御エンジン７bの内部構成を示している。

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

　始めに、PSRのうち、代表的なものについて説明する。

　PSR1は、オーディオストリームのためのストリーム番号レジスタであり、カレントのオーディオストリーム番号を格納する。

　PSR2は、PGストリームのためのストリーム番号レジスタであり、カレントのPGストリーム番号を格納する。

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

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

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

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

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

　PSR10は、IGストリームのためのストリーム番号レジスタであり、カレントのIGストリーム番号を格納する。

PSR21は、ユーザが、立体視再生を実行することを意図しているかどうかを示す。PSR21への値の設定は、ＢＤプログラムファイルのナビゲーションコマンドやＡＰＩを通じて、またはプレーヤのＯＳＤを通じて行われる。また、リモコン５００には、「３Ｄ／２Ｄ切り替えボタン」が設けられており、３Ｄプレイリストの再生中などの任意のタイミングで、ユーザイベント処理部１７からこのボタンの押下が通知された場合、PSR21の値は、立体視再生を示す値と２Ｄ再生を示す値とに交互に再設定される。このような構成にすることによりユーザの嗜好を取り入れることが可能になる。

　PSR22は、表示タイプ値を示す。

　PSR23は、"Display Capability for 3D"の設定である。これは、再生装置の接続相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。

　PSR24は、"Player Capability for 3D"の設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。PSR24におけるPlayer Capability for 3Dは、再生装置の3D再生に関する能力全般を意味するものなので、"3D-Capability"と簡単に表記する場合がある。

　一方、再生制御エンジン７bの内部には、レジスタセット１０におけるPSR4,PSR6,PSR21,PSR23,PSR24と、管理情報メモリ９におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける表示タイプを一意に定めるプロシージャ実行部８を備えている。

　また、プロシージャ実行部は、３Ｄプレイリストの再生中に、PSR21の値が変更された場合、図３７に示す処理手順により、ＰＳＲ２２の表示タイプ値を再設定する。具体的には、PSR24の"Player Capability for 3D"の値が１、即ち再生装置が立体視再生能力を有し（ステップＳ１１１：Ｙｅｓ）、PSR21の表示タイプユーザ設定が「立体視再生」を示す値であり（ステップＳ１１２：Ｙｅｓ）、さらに、PSR23の"Display Capability for 3D"の値が１、即ち再生装置の接続相手である表示装置に立体視再生を実行する能力が存在する（１１１３：Ｙｅｓ）場合、PSR22を「Ｌ・Ｒ表示タイプ」に設定する（ステップＳ１１４）。一方、PSR21,PSR23,PSR24が上記以外の値に設定されている場合は、PSR22を「Ｌ・Ｌ表示タイプ」に設定する（ステップＳ１１５）。

　以上がレジスタセット１０についての説明である。

　尚、本実施形態に係る再生装置２００は３Ｄ/２Ｄ再生装置であるため３Ｄ映像を再生できるが、2D再生装置においては、２Ｄ映像を再生する経路が記載された２Ｄプレイリストのみを参照して２Ｄ映像を再生する。

　以下に、２Ｄ再生装置において２Ｄプレイリストを再生する仕組みについて説明する。

　図３８はインデックスファイル（Ｉｎｄｅｘ．ｂｄｍｖ）とＢＤプログラムファイル（ＡＡＡ．ＰＲＧ）の関係を示している。３Ｄ映像を格納したＢＤ－ＲＯＭには、２Ｄ映像を再生する経路が記載された２Ｄプレイリストと、３Ｄ映像を再生する経路が記載された３Ｄプレイリストが記録されている。ユーザからタイトルが選択され、実行されたＢＤプログラムファイルは、プログラムの中で、再生装置が映像再生に対応しているか、対応している場合にユーザが３Ｄ映像再生を選択しているかを調べて、再生するプレイリストを切り替える。

　図３９はＢＤプログラムファイルのプログラムでの２Ｄプレイリストと３Ｄプレイリストとの選択フローを示している。

　Ｓ１にて、ＰＳＲ２４の値をチェックし、値が０の場合は該当再生装置は２Ｄ再生装置であるため、２Ｄプレイリストを再生し、値が１の場合はＳ２に進む。

　Ｓ２にて、ユーザに２Ｄ映像の再生を希望するか、３Ｄ映像の再生を希望するかを、メニュー画面を表示して問い合わせる。ユーザのリモコンなどでの選択の結果、２Ｄ映像の再生を希望する場合は２Ｄプレイリストを再生し、３Ｄ映像の再生を希望する場合はＳ３に進む。

　Ｓ３にて、ディスプレイが３Ｄ映像の再生に対応しているかをチェックする。例えば、ＨＤＭＩにて結線を行い、再生装置がディスプレイに対して、３Ｄ映像再生に対応しているかどうかを問い合わせる。３Ｄ映像の再生に対応していない場合は、２Ｄプレイリストを再生するが、ユーザに対してテレビ側の準備が整っていない旨をメニュー画面などで提示しても良い。３Ｄ映像の再生に対応している場合は、３Ｄプレイリストを再生する。

　なお、２Ｄプレイリストと３Ｄプレイリストのファイル名のプリフィックスの番号（ＸＸＸ．ｍｐｌｓであればＸＸＸ）は連番になっていても良い。こうすることで、２Ｄプレイリストに対応する３Ｄプレイリストの特定が容易になる。以上が、２Ｄプレイリストと３Ｄプレイリストとの選択についての説明である。

　　＜立体視再生と２Ｄ再生のシームレスな切り替え＞
　３Ｄ映像を立体視再生中にユーザの選択によって、任意のタイミングで２Ｄ再生に切り替えられることや、２Ｄ再生から立体視再生再生へスムーズに切り替えられることが求められる。例えば目の疲労感によって立体視再生を２Ｄ再生に切り替えるなどの使い方が想定できる。

　３Ｄ映像の再生と２Ｄ映像の再生とを切り替える第１の方法としては、３Ｄ映像の再生経路が格納されている３Ｄプレイリストの再生から、２Ｄ映像の再生経路が格納されている２Ｄプレイリストの再生へ切り替える方法が考えられる。この方法では、例えば、３Ｄプレイリストで３Ｄ映像を再生中に、ＢＤプログラムファイルによって表示されたメニューなどを介して、ユーザが３Ｄ映像の再生から２Ｄ映像の再生へ切り替え命令を行うことになる。それに応じて、ＢＤプログラムファイルは、まず、３Ｄプレイリストの再生を中断させ、当該３Ｄプレイリストに対応する２Ｄプレイリストを特定して選択し、次に、３Ｄプレイリスト中断時刻に対応する２Ｄプレイリスト再生開始地点を特定して、飛び込み再生を行い、３Ｄ映像の再生から２Ｄ映像の再生遷移を行うことになる。この場合、プレイリストの再生の中断処理が行われ、またＢＤプログラムファイルの実行処理が必要となるため、上記の方法ではシームレスな切り替えが実行できないという問題がある。

　さらに、３Ｄ映像を再生中に２Ｄ映像の再生へ切り替える場合には、レフトビュービデオストリームとライトビュービデオストリームとのピクチャを交互に出力する処理から、レフトビュービデオストリームのピクチャのみを出力する処理に遷移することになるため、再生装置から出力するフレームレートが４８Ｈｚから２４Ｈｚに変化する。その結果、再生装置とテレビとの間でＨＤＭI接続の再同期が必要となり、切り替え時に遅延が発生してしまう。フレームレートの切り替えを発生させない仕組みが必要となる。

　以下、３Ｄ映像の立体視再生と２Ｄ再生とをシームレスに切り替える方法について説明する。

　そこで、図４０に示すように、３Ｄプレイリストにより３Ｄ映像を再生するためのレフトビュービデオストリームとライトビュービデオストリームとが参照されている場合にも、ＰＳＲ２２の設定に従って、テレビへ出力する映像を変更する。この時、「Ｌ・Ｒ表示タイプ」では、２４Ｈｚのレフトビュービデオストリームと２４Ｈｚライトビュービデオストリームとの両方のピクチャを交互に４８Ｈｚで出力する。「Ｌ・Ｌ表示タイプ」では、ベースビューストリームであるレフトビュービデオストリームだけを重複再生、即ち、１枚のピクチャを２度ずつ４８Ｈｚで出力することで、表示タイプ切り替えの前後のフレームレートを一致させている。

　ＰＳＲ２２の値は、ＰＳＲ２１の表示タイプユーザ設定がＢＤプログラムファイルのナビゲーションコマンドやＡＰＩを通じて、またはプレーヤのＯＳＤ、もしくはリモコン５００のボタン操作を通じて変更されるのに伴って変更されるため、再生中のステータス変更が可能である。図４０に示す例では、３Ｄプレイリストによる再生中に出力ステータスが変更されているため、表示タイプが「Ｌ・Ｒ表示タイプ」であるｔ１までの期間は、テレビには３Ｄ映像が表示されるが、ｔ１からｔ２までの期間は、表示タイプが「Ｌ・Ｌ表示タイプ」に変更され、それに従ってテレビには２Ｄ映像が表示される。さらにｔ２以後は表示タイプが再び「Ｌ・Ｒ表示タイプ」に変更され、テレビには３Ｄ映像が表示される。しかし、全ての期間を通じてテレビへの出力レートは４８Ｈｚであるため、再生装置とテレビとの間でＨＤＭI接続の再同期が発生せず、３Ｄ映像の立体視再生と２Ｄ再生とがシームレスに切り替わる。

　このように構成することで、３Ｄ映像から２Ｄ映像への再生切り替えを行うときに、プレイリストの切り替えを行うことなく、３Ｄプレイリスト再生中に動的にユーザが３Ｄ映像から２Ｄ映像への再生切り替えを行うことができる。また、２Ｄ映像の再生を重複再生の処理で行うことにより、３Ｄ映像の再生とフレームレートの切り替えが発生しないため遅延なくシームレスな切り替えが可能となる。

　図４０で示すような、３Ｄ映像の立体視再生と２Ｄ再生とのシームレな切り替えは、プレーン加算部５ｂの動作によって実現することができる。このときビデオデコーダでは、通常の通り３Ｄプレイリストにより参照されるレフトビュービデオストリームのビクチャとライトビュービデオストリームのビクチャとがＤＴＳのタイミングで交互にデコードされ、それぞれＰＴＳのタイミングで対応するプレーンメモリへ格納される。

　その一方で、プレーン加算部５ｂでは、スイッチ６２が図４１に示す手順で、ピクチャデータを取得するプレーンメモリを切り替える。図４１は、スイッチ６２の切り替え制御を示すフローチャートである。スイッチ６２は、ＰＳＲ２２における表示タイプの値がＬ・Ｒ表示タイプを示す場合（ステップＳ１０１：Ｙｅｓ）、接続経路をカレントビューのプレーンメモリ側へ切り替える（ステップＳ１０２）。ステップＳ１０１においてＰＳＲ２２における表示タイプの値がＬ・Ｌ表示タイプを示す場合（ステップＳ１０１：Ｎｏ）、スイッチ６２は接続経路をレフトビュープレーン３２の側へ切り替える（ステップＳ１０３）。

　スイッチ６２の切り替え後、プレーンメモリセット５aの各プレーンメモリから格納データが読み出され、重畳処理に転送させる。その後、カレントビューが変更され（ステップＳ１０４）、ステップＳ１０１から処理が繰り返される。プレーン加算部５ｂでは、このステップＳ１０１～ステップＳ１０５の一連の処理が４８Ｈｚで繰り返し実行される。尚、カレントビューは、ビデオストリームの再生開始時にレフトビューであり、ステップＳ１０５を実行するたびにレフトビューとライトビューと交互に変更される。

　このようにスイッチ６２が切り替えられることで、「Ｌ・Ｒ表示タイプ」では、３Ｄ映像が４８Ｈｚのフレームレートが出力され、「Ｌ・Ｌ表示タイプ」では、２Ｄ映像が４８Ｈｚのフレームレートで出力される。

　なお、図４０で示すような、３Ｄ映像の立体視再生と２Ｄ再生とのシームレな切り替えは、プレーン加算部５ｂでの処理を変えずにプライマリビデオデコーダ３１の処理を変えることで実現することもできる。図４２は、３Ｄ映像の再生と２Ｄ映像の再生のシームレスな切り替えを実現するプライマリビデオデコーダ３１の構成を示す図である。

　プライマリビデオデコーダ３１は、再生制御部７からＰＳＲ２２に設定された表示タイプの通知を受ける。表示タイプがＬ・Ｒ表示タイプである場合には、ピクチャスイッチ６０は、デコーダ５７から転送されたデコード済みのレフトビュービデオストリームのピクチャ、及びライトビュービデオストリームのピクチャを、それぞれＰＴＳのタイミングで、対応するビデオプレーンに出力する。表示タイプがＬ・Ｌ表示タイプである場合には、ピクチャスイッチ６０は、デコーダ５７から転送されたデコード済みのレフトビュービデオストリームのピクチャを、ＰＴＳのタイミングで、レフトビュービデオプレーンに出力すると共に、そのＰＴＳ＋３Ｄ表示ディレイのタイミングで同じデコード済みのレフトビュービデオストリームのピクチャをライトビュービデオプレーンに出力する。

　以上の構成により、３Ｄ映像の立体視再生と２Ｄ再生とのシームレな切り替えが実現される。

　以上のように本実施形態によれば、再生装置の表示タイプがＬ・Ｒ表示タイプになっている場合、レフトビュービデオストリームから得られるピクチャデータと、ライトビュービデオストリームから得られるピクチャデータとが、交互に出力されるが、再生装置の表示タイプがＬ・Ｌ表示タイプになっている場合、レフトビュービデオストリームから得られるピクチャデータが、１枚のピクチャにつき２回ずつ繰り返して出力される。これによって、Ｌ・Ｒ表示タイプにおける３Ｄ映像と、Ｌ・Ｌ表示タイプにおける２Ｄ映像とのフレームレートとが一致する。そのため、３Ｄ映像と２Ｄ映像との切り替え時にＨＤＭI接続の再同期が生じず、シームレスな再生が可能となる。

　なお、本実施の形態では、２Ｄ再生装置では左目映像を２Ｄ映像として再生する構成で説明したが、２Ｄ再生装置が右目映像を２Ｄ映像として再生する構成にしても同じ効果が得られることは言うまでもない。

　なお、本発明は３Ｄ映像を格納するための方法として説明したが、高フレームレートの映像を格納するために利用しても良い。高フレームレート映像の中で、奇数フレームを抜き出し格納した奇数フレーム映像と、偶数フレームを抜き出し格納した偶数フレーム映像を用意し、奇数フレーム映像を２Ｄ／左目映像として、偶数フレーム映像を右目映像として、本実施の形態で説明したデータ構造で記録すれば３Ｄ映像を格納するときと同じ効果が得られる。つまり、高フレームレート映像を本実施の形態で格納したＢＤ－ＲＯＭは、２Ｄ再生装置では奇数フレーム映像を再生でき、２Ｄ／３Ｄ再生装置では奇数フレーム映像もしくは高フレームレート映像を再生できるため、互換再生を確保できる。

　　＜第１実施形態の変形例１＞
　なお、図４３に示すように、ＰＳＲ２２が示す表示タイプの種類を、「Ｌ・Ｒ表示タイプ」、「Ｌ・Ｌ表示タイプ」、及び「２Ｄ通常表示タイプ」の三種類とする構成にしても良い。ここで「Ｌ・Ｒ表示タイプ」、「Ｌ・Ｌ表示タイプ」は、図４０において示した「Ｌ・Ｒ表示タイプ」、「Ｌ・Ｌ表示タイプ」と同様の表示タイプであり、「２Ｄ通常表示タイプ」は、レフトビュービデオストリームだけをピクチャデータを１枚ずつ再生する表示タイプである。

　このように構成すると、フレームレートが４８Ｈｚであった「Ｌ・Ｒ表示タイプ」や「Ｌ・Ｌ表示タイプ」の区間に比べて、表示タイプを「２Ｄ通常表示タイプ」にした区間では、フレームレートが２４Ｈｚと低くなる。そのため、その境界でＨＤＭＩ接続のフレームレートの切り替えが必要であり、遅延が発生しシームレスな切り替えができなくなる。しかしこのような構成は、高フレームレートで再生する際にテレビ側の処理に負荷がかかる場合（例えば、電力量など）には、２Ｄ映像の再生時の処理の負荷を軽減できるというメリットがある。

　なお、図４４に示すように、ＰＳＲ２２に設定された表示タイプは、レフトビュービデオストリームとライトビュービデオストリームとが格納された３Ｄ映像を再生する再生区間だけでなく、レフトビュービデオストリームだけが格納された２Ｄ映像を再生する再生区間にも適用できるようにしてよい。表示タイプには、前述の「Ｌ・Ｒ表示タイプ」、「Ｌ・Ｌ表示タイプ」、及び「２Ｄ通常表示タイプ」が存在するが、レフトビュービデオストリームだけが格納された２Ｄ映像を再生する再生区間５８０２においては「Ｌ・Ｒ表示タイプ」のステータスは適用されない。２Ｄ／３Ｄ再生装置は、表示タイプに従って再生処理を行う。各再生区間はプレイアイテムなどで区切られており、それぞれのプレイアイテムはコネクションコンディションによってシームレスに接続されるように設定されている。このような構成にすることで、３Ｄプレイリストに３Ｄ映像を再生する再生区間と２Ｄ映像を再生する再生区間とが混在していてもユーザは自由に３Ｄ映像と２Ｄ映像の再生を切り替えることが可能となる。

　なお、表示タイプが「Ｌ・Ｒ表示タイプ」に設定されている状態で、レフトビュービデオストリームだけが格納される２Ｄ映像を再生する再生区間に遷移した場合には、ＰＳＲ２２の設定は「Ｌ・Ｌ表示タイプ」に変更される。このように構成することにより、３Ｄ映像を再生したときのフレームレートのまま、２Ｄ映像を再生できるため、フレームレートの切り替えなく再生できる。

　また、表示タイプが「Ｌ・Ｒ表示タイプ」のまま、レフトビュービデオストリームだけが格納される２Ｄ映像を再生する再生区間に遷移した場合には、その２Ｄ映像を再生する再生区間に付与された重複フラグを優先するように構成してもよい。例えば、前述した重複フラグのように再生区間に割り当てられた情報を優先して、表示タイプを変更してもよい。重複フラグが「重複再生」であれば、ＰＳＲ２２の設定は「Ｌ・Ｌ表示タイプ」に変更され、重複フラグが「通常再生」であれば、ＰＳＲ２２の設定は「２Ｄ通常表示タイプ」に変更される。

　　＜第１実施形態の変形例２＞
　エントリマップは、図４５に示すようにそれぞれのエントリポイントの情報にエクステント開始フラグ（ＥＸＴＳＴＡＲＴ）が追加した構成としてもよい。エクステント開始フラグは、エントリポイントが指すＳＰＮがＡＶストリームファイルのエクステント先頭の場合に「１」が設定され、エントリポイントが指すＳＰＮがＡＶストリームファイルのエクステント先頭でない場合に「０」が設定される。これによりエントリマップの情報から各エクステントのサイズを取得することができるため、２Ｄ／３Ｄ再生装置がＡＶストリームの再生をエクステント単位で交互に行う処理を簡易に行うことができる。図４６にエントリポイントとＡＶストリームの関係を模式的に示している。例えば、図４６のＡＶストリームファイルを先頭から３Ｄ映像として再生を行うには次のように行う。まず、左目ＡＶストリームのエクステント開始フラグが「１」のエントリポイント＃１のＳＰＮと、その次のエクステント開始フラグが「１」のエントリポイント＃２のＳＰＮまでの差分から読み込みサイズを計算して、該当エクステントの読み込み処理をＢＤ－ＲＯＭドライブに要求する。次にライトビューＡＶストリームのエクステント開始フラグが「１」のエントリポイント＃３のＳＰＮと、その次のエクステント開始フラグが「１」のエントリポイント＃４のＳＰＮまでの差分から読み込みサイズを計算して、該当エクステントの読み込み処理をＢＤ－ＲＯＭドライブに要求する。このように読み込み処理をレフトビューＡＶストリームとライトビューＡＶストリームとで交互に行うことで、ファイルシステムのエクステントの情報を知らなくても、交互にエクステント単位で読み込みができるため、ＢＤ－ＲＯＭドライブはジャンプを発生させずに連続的に再生を行うことができる。

　また、レフトビューＡＶストリームのレフトビュービデオストリームのＧＯＰ先頭のＩピクチャの中で、そのＩピクチャの先頭を含むＴＳパケットがエクステント先頭の場合には、必ずエントリポイントも作成しなければならならない。同様に、ライトビューＡＶストリームのライトビュービデオストリームの右目ＧＯＰ先頭のピクチャの中で、そのピクチャの先頭を含むＴＳパケットがエクステント先頭の場合には、必ずエントリポイントを作成しなければならならない。

　なお、エントリマップの各エントリポイントにエクステント開始フラグを追加するとしたが、エントリマップにはアングル切り替えフラグと呼ばれるマルチアングルでのアングル切り替えのタイミングを示す１ビットのフラグが用意されている。よって、ビット量を削減するために、エクステント開始フラグはこのフラグと共用化しても良い。エントリマップヘッダ情報に、該当１ビットのフィールドが「エクステント開始フラグ」なのか、「アングル切り替えフラグ」なのかを示すフラグを用意して、このフラグをチェックすることで、２Ｄ／３Ｄ再生装置はエントリマップ上の該当１ビットのフィールドの意味を解釈して処理をスイッチしても良い。

　なお、エントリマップの各エントリポイントにエクステント開始フラグを追加するとしたが、各ＡＶストリームのエクステントサイズを特定する情報であれば、この構成に限らない。例えば、ＡＶストリームのエクステントのサイズをリスト化してメタデータとしてクリップ情報ファイルに格納しても良いし、エントリマップのエントリポイントに１：１で対応するビット列を別途用意し、ビット列が「１」であればエクステント先頭を意味し「０」であればエクステント先頭ではないとしてもよい。

　(第２実施形態)
　第２実施形態では、ＢＤ－ＲＯＭに格納された３Ｄ映像を再生する上で、ピクチャが欠損してデコードできない場合の再生方法および再生装置について説明する。

　図４８上段は、３Ｄ映像として再生する際のレフトビュービデオストリームとライトビュービデオストリームのピクチャの例を表示順で示しており、再生中にＳｙｎｔａｘ異常など何らかの異常が発生してしまいデコードできないピクチャが存在していることを示している。このＳｙｎｔａｘ異常など何らかの異常が発生してしまいデコードできないピクチャを欠損ピクチャ６５０１と呼ぶ。ライトビュービデオストリームのピクチャ内に欠損ピクチャ６５０１が存在する場合に、欠損されたままピクチャを表示してしまうと、ユーザに対して大きな不快感が発生してしまう。

　そこで、図４８下段のように第２実施形態に係る再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、その欠損ピクチャ６５０１とペアとして表示されるレフトビュービデオストリームのピクチャ（以降、欠損ペアピクチャ６７０１と呼ぶ）を、欠損ピクチャ６５０１の代わりに表示する。

　この方法での再生装置の改良部分を説明する。本実施形態に係る再生装置は、第１実施形態にて説明した再生装置２００のプライマリビデオデコーダを改良したものである。図４７は、第２実施形態に係る再生装置のプライマリビデオデコーダの構成を示す図である。欠損ピクチャ６５０１とペアとして表示されるレフトビュービデオストリームの欠損ペアピクチャ６５０２のＰＴＳは、欠損ピクチャのＰＴＳから３Ｄ表示ディレイを引いた値となる。そのため、システムターゲットデコーダ４では、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１であるとの通知が、ビデオデコーダ５７からピクチャスイッチ６０へ通知された場合には、欠損ピクチャ６５０１のＰＴＳから３Ｄ表示ディレイを引いたレフトビュービデオストリームのピクチャをライトビュープレーンに出力する。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能となる。

　なお、本実施形態の変形例として、図４９下段のように再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、その欠損ピクチャ６５０１の直前のライトビュービデオストリームのピクチャを、欠損ピクチャ６５０１の代わりに表示してもよい。この方法での再生装置の拡張部分を説明する。システムターゲットデコーダ４では、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１であるとの通知が、ビデオデコーダ５７からピクチャスイッチ６０へ通知された場合には、欠損ピクチャ６５０１をライトビュービデオプレーンに出力せずに破棄する。ライトビュービデオプレーンには直前のライトビュービデオストリームのピクチャが残り、このピクチャが欠損ピクチャ６５０１の代わりとしてプレーン加算部３０で重畳処理に使われる。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能である。

　また、他の変形例として、図５０下段のように２Ｄ／３Ｄ再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、その欠損ピクチャ６５０１の直前のライトビュービデオストリームのピクチャを、欠損ピクチャ６５０１の代わりに表示し、また、その欠損ピクチャ６５０１とペアとして表示されるレフトビュービデオストリームの欠損ペアピクチャ６５０２の直前のレフトビュービデオストリームのピクチャを、その欠損ペアピクチャ６５０２の代わりに表示しても良い。この方法での２Ｄ／３Ｄ再生装置の拡張部分を説明する。システムターゲットデコーダ４では、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１であるとの通知が、ビデオデコーダ５７からピクチャスイッチ６０へ通知された場合には、欠損ピクチャ６５０１をライトビュービデオプレーンに出力せずに破棄する。ライトビュービデオプレーンには直前のライトビュービデオストリームのピクチャが残り、このピクチャが欠損ピクチャ６５０１の代わりとしてプレーン加算部３０で重畳処理に使われる。また、システムターゲットデコーダ４では、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１であるとの通知が、ビデオデコーダ５７からピクチャスイッチ６０へ通知された場合には、さらに、欠損ピクチャ６５０１とPTSが同じであり、欠損ピクチャ６５０１とペアで表示される欠損ペアピクチャ６５０２を特定し、このピクチャをレフトビュービデオプレーンには出力せずに破棄する。レフトビュービデオプレーンには直前のレフトビュービデオストリームのピクチャが残り、このピクチャが欠損ペアピクチャ６５０２の代わりとしてプレーン加算部３０で重畳処理に使われる。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能である。

　さらに他の変形例として、図５１下段のように２Ｄ／３Ｄ再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、単色の黒などで構成されあらかじめ用意した補完ピクチャ６８０１を欠損ピクチャ６５０１の代わりに表示してもよい。この方法での、２Ｄ／３Ｄ再生装置の拡張部分を説明する。システムターゲットデコーダ４では、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１であるとの通知が、ビデオデコーダ５７からピクチャスイッチ６０へ通知された場合には、欠損ピクチャ６５０１のＰＴＳのタイミングで補完ピクチャ６８０１をライトビュービデオプレーンに出力する。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能である。

　さらに他の変形例として、図５２下段のように２Ｄ／３Ｄ再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、補完ピクチャ６８０１を欠損ピクチャ６５０１の代わりに表示し、補完ピクチャ６８０１を欠損ペアピクチャ６７０１の代わりに表示してもよい。この方法での、２Ｄ／３Ｄ再生装置の拡張部分を説明する。システムターゲットデコーダ２３は、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１の場合には、欠損ピクチャ６５０１のＰＴＳのタイミングで補完ピクチャ６８０１をライトビュービデオプレーンに出力する。また、システムターゲットデコーダ２３は、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１の場合には、欠損ピクチャ６５０１とペアで表示される欠損ペアピクチャ６７０１を特定し、このピクチャのＰＴＳのタイミングで補完ピクチャ６８０１をレフトビュービデオプレーンに出力する。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能である。

　さらに他の変形例として、図５３下段のように２Ｄ／３Ｄ再生装置は、３Ｄ映像再生中にライトビュービデオストリームに欠損ピクチャ６５０１が存在する場合には、補完ピクチャ６８０１を、直前のライトビュービデオストリームのピクチャと欠損ペアピクチャ６７０１から作成して、その補完ピクチャ６８０１を欠損ピクチャ６５０１の代わりに表示してもよい。この方法での、２Ｄ／３Ｄ再生装置の拡張部分を説明する。システムターゲットデコーダ２３は、ライトビュービデオストリームのピクチャが欠損ピクチャ６５０１の場合には、直前のライトビュービデオストリームのピクチャと欠損ペアピクチャ６７０１から補完ピクチャ６８０１を作成し、欠損ピクチャ６５０１のＰＴＳのタイミングで補完ピクチャ６８０１をライトビュービデオプレーンに出力する。このように構成することにより、ユーザに欠損されたピクチャを表示することを避けることができ、視聴者の不快感を軽減することが可能である。

　なお、ピクチャが欠損してデコードできない場合の再生方法および再生装置についての説明で、欠損ピクチャ６５０１をライトビュービデオストリーム中にある場合を説明したが、これがレフトビュービデオストリームにある場合も同様の構成（レフトビュービデオストリームとライトビュービデオストリームを入れ替える）で対応できるのは言うまでもない。但し、本実施の形態で説明したように、ライトビュービデオストリームの各ピクチャは、左目映像ビデオストリームのピクチャを参照する構成になっている場合には、左目映像ビデオストリームのピクチャが欠損ピクチャの場合に、対応するライトビュービデオストリームのピクチャも欠損ピクチャとなるため、レフトビュービデオストリーム内に欠損ピクチャがある場合には、欠損ピクチャと欠損ペアピクチャの両方別のピクチャで置き換える方法が有効である。つまり、図５０と図５２を用いて説明した方法が有効である。

　(第３実施形態)
　第３実施形態では、ＢＤ－ＲＯＭに格納された３Ｄ映像の一時停止処理の再生方法および再生装置について説明する。

　２Ｄ映像の再生において、ユーザからの命令によって再生の一時停止命令が行われた場合には、図５４に示すように再生装置は一時停止時点の２Ｄ映像のピクチャをデコードし、そのピクチャを一時停止解除命令が行われるまでビデオストリームのフレームレートで出力することになる。３Ｄ映像の再生において、ユーザからの命令によって再生の一時停止命令が行われた場合には、図５５（ａ）で示したように一時停止時点にあるレフトビュービデオかライトビュービデオのどちらかのピクチャをデコードして、そのピクチャを一時停止解除命令が行われるまで出力する方法と、図５５（ｂ）で示したように一時停止時点のレフトビュービデオのピクチャとペアになるライトビュービデオのピクチャをデコードして、その二つのピクチャを一時停止解除命令が行われるまで出力する方法がある。なお、この二つの方法は、ＢＤプログラムファイルなどから区別できるように、一時停止を命令するコマンドやＡＰＩを分けても良い。

　３Ｄ映像における一時停止処理の方法における２Ｄ／３Ｄ再生装置の拡張部分について説明する。

　まず、一時停止時点での２Ｄ／左目映像か右目映像のどちらかのピクチャを表示する場合の再生装置の拡張部分を説明する。２Ｄ／３Ｄ再生装置２００の再生制御部７は、ユーザイベント処理部１７やプログラム実行部１１から一時停止命令を受け取ると、ＢＤ－ＲＯＭドライブ１とシステムターゲットデコーダ４とに対するデコード停止命令を実行する。ＢＤ－ＲＯＭドライブ１はデコード停止命令を受け取るとＢＤ－ＲＯＭディスクからの読み出しを停止する。システムターゲットデコーダ４はデコード停止命令を受け取ると、デコードを停止し、スピーカへの音声の出力を停止する。このとき、システムターゲットデコーダ４はレフトビュービデオプレーンかライトビュービデオプレーンへのピクチャの書き込みが途中であれば終了するまで待ち、プレーン加算部５ｂに一時停止ステータスを通知する。プレーン加算部５ｂは図５６に示すように、システムターゲットデコーダから一時停止ステータスを受け取る。一時停止ステータスには、最後にシステムターゲットデコーダが出力したピクチャがレフトビュービデオプレーンか、ライトビュービデオプレーンのどちらに書き込まれたのかを示すフラグを格納している。プレーン加算部５ｂのスイッチ６２は、最後にシステムターゲットデコーダがデコードして出力したピクチャがレフトビュービデオプレーンである場合は、重畳処理に行うビデオプレーンをレフトビュービデオプレーンに選択する。プレーン加算部５ｂのスイッチ６２は、最後にシステムターゲットデコーダがデコードして出力したピクチャがライトビュービデオプレーンである場合は、重畳処理に行う映像プレーンをライトビュービデオプレーンに選択する。プレーン加算部５ｂは選択した映像プレーンと他のプレーンとの重畳処理を３Ｄ映像のフレームレート（２Ｄ映像の倍のフレームレート）の間隔で行う。

　次に、一時停止時点での２Ｄ／左目映像と右目映像の２つのピクチャも表示する場合の再生装置の拡張部分を説明する。２Ｄ／３Ｄ再生装置２００の再生制御部２７は、ユーザイベント処理部１７やプログラム実行部１１から一時停止命令を受け取ると、ＢＤ－ＲＯＭドライブ１とシステムターゲットデコーダ４に対するデコード停止命令を実行する。ＢＤ－ＲＯＭドライブ２１はデコード停止命令を受け取るとＢＤ－ＲＯＭディスクからの読み出しを停止する。システムターゲットデコーダ２３はデコード停止命令を受け取ると、デコードを停止し、スピーカへの音声の出力を停止する。このとき、システムターゲットデコーダ４はレフトビュービデオプレーンかライトビュービデオプレーンへのピクチャの書き込みが途中であれば終了するまで待つが、最後に映像プレーンに出力したピクチャがレフトビュービデオストリームである場合は、そのピクチャとペアとして表示するライトビュービデオストリームのピクチャをデコードしてライトビュービデオプレーンに出力するまで待ち、プレーン加算部５ｂに一時停止ステータスを通知する。プレーン加算部５ｂはシステムターゲットデコーダから一時停止ステータスを受け取ると、レフトビュービデオプレーンとライトビュービデオプレーンとを交互に切り替えて、他のプレーンとの重畳処理を３Ｄ映像のフレームレートの間隔で行う。

　以上が、３Ｄ映像の一時停止処理の説明である。

　(第４実施形態)
　第４実施形態では、３Ｄ映像の静止画のデータ構造、再生方法および再生装置について説明する。

　まず、３Ｄ映像の静止画を実現するためのデータ構造と再生方法について説明する。

　図５７は静止画でのＧＯＰ構成を示している。レフトビュービデオストリームのＧＯＰには、Ｉピクチャのビデオアクセスユニットが格納され、そのＩピクチャのビデオアクセスユニットの終端にはプライマリビデオデコーダ３１に、ビデオシーケンスの終端を知らせるためのシーケンス終端コード６４０１（ＭＰＥＧ－２の場合は、Ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ、ＭＰＥＧ－４　ＡＶＣの場合はＥｎｄＯｆＳｅｑｕｅｎｃｅ）が格納される。また、ライトビュービデオストリームの右目ＧＯＰには、レフトビュービデオストリームのＧＯＰ先頭のＩピクチャとペアで表示されるピクチャのビデオアクセスユニットが格納され、レフトビュービデオストリームのＧＯＰ先頭のＩピクチャのＰＴＳと同じ時刻を示すＰＴＳが付与される。右目ＧＯＰの先頭ピクチャの終端にも同様にビデオデコーダ３１に、ビデオシーケンスの終端を知らせるためのシーケンス終端コード６４０２が格納される。

　次に、３Ｄ映像の静止画を実現するための２Ｄ／３Ｄ再生装置の拡張部を説明する。２Ｄ映像として図５７に示した静止画のレフトビュービデオストリームを再生する場合には、２Ｄ／３Ｄ再生装置のプライマリビデオデコーダ３１は、シーケンス終端コード６４０１が存在した場合は、そのビデオアクセスユニットをデコードした後、デコード処理を停止する。このようにすることで次のビデオアクセスユニットがプライマリビデオデコーダ３１に入力された場合でも、デコードしないため静止画を実現できる。次の静止画の再生に移行する場合には、再生制御部などからデコード開始命令が行われてデコードが再開される。

　しかし、３Ｄ映像として図５７に示した静止画のレフトビュービデオストリームとライトビュービデオストリームとを再生する場合には、プライマリビデオデコーダ３１は、レフトビュービデオストリームのビデオアクセスユニットに付加されているシーケンス終端コード６４０１は無視して、ライトビュービデオストリームのビデオアクセスユニットに付加されているシーケンス終端コード６４０２のみを参照する。つまり、ライトビュービデオストリームのビデオアクセスユニットにシーケンス終端コード６４０２がある場合に、プライマリビデオデコーダ３１はそのビデオアクセスユニットをデコードした後、デコード処理を停止する。このような構成にすることで、２Ｄ映像と３Ｄ映像の静止画を両立できる。

　なお、ライトビュービデオストリームの右目ＧＯＰの先頭ピクチャの終端には、レフトビュービデオストリームと同じシーケンス終端コード６４０２を格納するとしたが、このシーケンス終端コード６４０２はライトビュービデオストリーム独自のフォーマットになっていてもよい。例えば、新しいシーケンス終端コード６４０２を定義しても良いし、補足データでライトビュービデオストリーム用のシーケンス終端コード６４０２を定義しても良い。また、シーケンス終端コード６４０２として、図８で説明したデコードスイッチ情報にＧＯＰ終端のビデオアクセスユニットかどうかを示すフラグを追加しても良い。このように構成することによって、レフトビュービデオストリームのシーケンス終端コード６４０１とライトビュービデオストリームのシーケンス終端コード６４０２の区別が明確になり、プライマリビデオデコーダ３１が３Ｄ映像として静止画を再生する場合の処理が容易になる。

　(第５実施形態)
　第３実施形態では、ＢＤ－ＲＯＭに格納された３Ｄ映像の特殊再生の再生方法および再生装置について説明する。

　図５８（ａ）のブロックはレフトビューＡＶストリームとライトビューＡＶストリームがインターリーブされたエクステントを示している。白のブロックはレフトビューＡＶストリーム、斜線のブロックはライトビューＡＶストリームのエクステントを示しており、三角形の印はエントリポイントの位置を示している。７１０９Ａ、７１０９Ｃ、７１１０ＥはレフトビューＡＶストリームに含まれるレフトビュービデオストリームのエントリポイント、７１０９Ｂ、７１０９ＤはライトビューＡＶストリームに含まれるライトビュービデオストリームのエントリポイントを示している。矢印７１０１、７１０２、７１０３０４、７１０５は、エントリポイントが指すピクチャが格納されたＴＳパケットの範囲を示している。この範囲のＴＳパケットを読みきれば、エントリポイントが指すピクチャをデコードすることができる。この範囲をエントリピクチャＴＳサイズと呼ぶことにする。エントリピクチャＴＳサイズは、エントリポイントの情報としてＳＰＮ、ＰＴＳと共に格納される。

　３Ｄ映像のまま早送りで再生を行う場合には、レフトビュービデオストリームのエントリポイントが指すＩピクチャと、そのＩピクチャとペアとして表示するライトビュービデオストリームのエントリポイントが指すピクチャを再生する必要がある。この場合、図５８（ａ）の３Ｄ映像の再生経路が示すとおり、各エントリーポイントが指すピクチャを再生するたびにジャンプが発生するためパフォーマンスが悪くなってしまう。

　そこで、図５８（ｂ）のように、ライトビュービデオストリームのエントリポイントのピクチャを、３Ｄ映像としてペアで表示されるレフトビュービデオストリームのエントリポイントのＩピクチャの配置箇所に近接する箇所にも配置する。そして、レフトビュービデオストリームのエントリポイントに格納されるエントリピクチャＴＳサイズは、ライトビュービデオストリームのエントリポイントが指すピクチャと同じものと、レフトビュービデオストリームのエントリポイントが指すＩピクチャとがレフトビューＡＶストリームのエクステントに格納されたＴＳパケットの範囲を示している。

　図５８（ｂ）の先頭のＩピクチャの例では、ライトビュービデオストリームのエントリポイントのピクチャ（エントリピクチャＴＳサイズ７１０２に格納されたピクチャ）と同じものが、３Ｄ映像としてペアで表示されるレフトビュービデオストリームのエントリポイントのＩピクチャと連続する箇所に配置されている。レフトビュービデオストリームのエントリポイントに格納されるエントリピクチャＴＳサイズは、ライトビュービデオストリームのエントリポイントが指すピクチャと同じものと、レフトビュービデオストリームのエントリポイントが指すピクチャとがレフトビューＡＶストリームに格納されたＴＳパケットの範囲（７１０６の矢印）となる。このように構成することによって、３Ｄ映像のまま早送りで再生を行う場合には、レフトビュービデオストリームのＩピクチャとライトビュービデオストリームのＩピクチャを同時に読み出すことができるため、再生する上でのジャンプを削減することができる。

　この構成を実現するためには、図５９（ａ）で示すように、レフトビューＡＶストリーム中に特殊再生用のために、ＰＩＤを割りふり、ライトビュービデオストリームのＩピクチャだけを格納するようにしても良い。２Ｄ／３Ｄ再生装置は、早送り、巻き戻しなどのエントリポイントが指すピクチャを再生することが実行されるときには、レフトビューＡＶストリームだけの読み出しを行い、２Ｄ／３Ｄ再生装置のシステムターゲットデコーダ２３は、レフトビューＡＶストリームから読まれたライトビュービデオストリームのピクチャがＰＩＤフィルタ２３に到着した場合には、そのデータをＴＢ５４に転送してライトビュービデオストリームのデコード処理を行う。

　また、この構成を実現するためには、図５９（ｂ）で示すように、レフトビューＡＶストリーム中に特殊再生用のために、ライトビュービデオストリームのエントリポイントが指すピクチャを、ペアとして表示するレフトビュービデオストリームのＧＯＰ先頭のＩピクチャの右目用ビデオアクセスユニット７２０１に格納しても良い。この右目用ビデオアクセスユニット７２０１は２Ｄ再生装置で再生できないように、ビデオアクセスユニットのリザーブとして定義できる領域に格納する。２Ｄ／３Ｄ再生装置は、早送り、巻き戻しなどのエントリポイントが指すピクチャを再生することが実行されるときには、レフトビューＡＶストリームだけの読み出しを行い、２Ｄ／３Ｄ再生装置のシステムターゲットデコーダ２３は、ライトビュービデオストリームの右目用ビデオアクセスユニット７２０１がＰＩＤフィルタ２３に到着した場合には、そのデータをＴＢ５４に転送してライトビュービデオストリームのデコード処理を行う。

　(第６実施形態)
　本実施形態では、第１実施形態で述べた記録方法を実施するための記録装置について説明する。

　リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにＡＶストリームファイルを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。

　この場合ＡＶストリームファイルは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたトランスポートストリームであってもよいし、記録装置がデジタル入力したトランスポートストリームをパーシャル化することで得られるトランスポートストリームであってもよい。

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

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

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

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

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

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

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

　図６１に示すようにマクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「円」の箇所では動きベクトルが検出される。

　検出された動きベクトルを抽出して、図６１下段のように、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、８ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。

　素材制作部５０２は、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックストリームなどの各ストリームを作成して、オーディオストリーム格納部５０２a、プレゼンテーショングラフィックスストリーム格納部５０２b、インタラクティブグラフィックストリーム格納部５０２cに書き込む。

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

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

　BDプログラム制作部５０４は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ５０１が出力した奥行き情報を利用することができる。

　多重化処理部５０５は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG２-TS形式のＡＶストリームファイルを作成する。このとき、ＡＶストリームファイルと対になるクリップ情報ファイルも同時に作成する。

　多重化処理部５０５は、自ら生成したエントリマップと、ＡＶストリームファイルに含まれるストリーム毎の音声属性、映像属性などを示す属性情報とをペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。

　フォーマット処理部５０６は、シナリオ生成部５０３で生成したBD-ROMシナリオデータと、BDプログラム制作部５０４で制作したBDプログラムファイル、多重化処理部５０５で生成したＡＶストリームファイルやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成する。

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

　(マネージドコピーを実現する記録装置としての実施)
　記録装置は、マネージドコピーによってデジタルストリームの書き込むものでもよい。

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

　BD-ROMからBD-R,BD-REへのコピーを実現する場合、コピー元と、コピー先とで記録容量が同じであるなら、マネージドコピーにおいては、コピー元となるBD-ROMにおけるビットストリームを最内周から最外周まで、順次コピーしてゆくという動作で足りる。

　マネージドコピーが、異種媒体間のコピーを想定したものであるなら、トランスコードが必要になる。ここで“トランスコード”とは、BD-ROMに記録されているデジタルストリームの形式をMPEG2トランスポートストリーム形式からMPEG2プログラムストリーム形式等に変換したり、ビデオストリーム及びオーディオストリームに割り当てられているビットレートを低くして再エンコードすることにより、デジタルストリームを、コピー先メディアのアプリケーションフォーマットに適合させる処理をいう。かかるトランスコードにあたっては、上述したリアルタイムレコーディングの処理を行うことで、ＡＶストリームファイル、Clip情報、プレイリスト情報を得る必要がある。

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

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

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

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

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

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

　同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。

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

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

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

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

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

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

　また、所定の条件が成立する際、ある決まった情報を定義するという任意的なデータ構造は、if文に、その成立すべき条件と、条件成立時に設定すべき変数とを、if文を用いて記述することができる。この記述には、switch文、case文を用いてもよい。

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

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

　集光された光ビームは、光ディスク上で反射/回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、再生信号を生成する。

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

　（半導体メモリカード記録装置及び再生装置の実施形態）
　各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。

　まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。

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

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

　以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。

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

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

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

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

　以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。

　半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを介してデータを読み出すように構成すればよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　ここでパッケージの種別に着目するとシステムLSIには、QFP(クッドフラッドアレイ)、PGA(ピングリッドアレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

　これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置２００の中核としての役割を果たす。

　かかるシステムLSIは、再生装置２００は勿論のこと、TVやゲーム、パソコン、ワンセグ携帯等、映像再生を扱う様々な機器に組込みが可能であり、本発明の用途を多いに広げることができる。

　システムLSIのアーキテクチャは、Uniphierアーキテクチャに準拠させるのが望ましい。

　Uniphierアーキテクチャに準拠したシステムLSIは、以下の回路ブロックから構成される。

　・データ並列プロセッサDPP
　これは、複数の要素プロセッサが同一動作するSIMD型プロセッサであり、各要素プロセッサに内蔵されている演算器を、1つの命令で同時動作させることで、ピクチャを構成する複数画素に対するデコード処理の並列化を図る。

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

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

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

　・AVI/Oブロック
　これは、オーディオ入出力、ビデオ入出力、OSDコントローラで構成され、テレビ、AVアンプとのデータ入出力を行う。

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

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

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

　回路図が完成すれば、実装設計を行う。実装設計とは、回路設計によって作成された回路図上の部品(回路素子やIC,LSI)を基板上のどこへ配置するか、あるいは、回路図上の接続線を、基板上にどのように配線するかを決定する基板レイアウトの作成作業である。

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

　尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。

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

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

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

　本発明に係る再生装置は、３Ｄ映像再生と２Ｄ映像再生との切り替えにおいて、出力フレームレートの変化がないため、出力フレームレートの同期が必要なＨＤＭＩ接続によりモニタと接続する用途において有用である。

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

Claims

ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置であって、
　前記３Ｄビデオストリームを用いて立体視再生を行う場合、前記ベースビュービデオストリームをデコードして得られたピクチャデータと前記ディペンデントビュービデオストリームをデコードして得られたピクチャデータとを表示装置へ出力し、
　前記３Ｄビデオストリームを用いて平面視再生を行う場合、前記ベースビュービデオストリームをデコードして得られた各ピクチャデータを、少なくとも２回ずつ繰り返して表示装置へ出力する
ことを特徴とする再生装置。
前記３Ｄビデオストリームを用いて平面視再生を行う場合に各ピクチャデータを繰り返して出力する回数は、１ピクチャデータにつき２回であり、
　前記繰り返しにより、平面視再生における出力フレームレートを、立体視再生における出力フレームレートと同じフレームレートに変換する
ことを特徴とする請求項１に記載の再生装置。
前記再生装置は、
　３Ｄビデオストリームの再生時に、立体視再生及び平面視再生の何れか一方から他方への変更指示を受け付ける受付手段を有する
ことを特徴とする請求項１に記載の再生装置。
前記再生装置は、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームとをデコードするデコーダと、
　前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替えるスイッチとを含み、
　前記３Ｄビデオストリームを用いて立体視再生を行う場合、前記ベースビュービデオプレーンメモリに格納されたピクチャデータと、前記ディペンデントビュービデオプレーンメモリに格納されたピクチャデータを出力し、
　前記３Ｄビデオストリームを用いて平面視再生を行う場合、前記ベースビュービデオプレーンメモリに格納されたピクチャデータを、少なくとも２回ずつ繰り返して出力する
ことを特徴とする請求項１に記載の再生装置。
前記再生装置は、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームとをデコードするデコーダと、
　前記３Ｄビデオストリームを用いて立体視再生を行う場合、前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替え、
　前記３Ｄビデオストリームを用いて平面視再生を行う場合、前記ベースビュービデオストリームのデコードにより得られたピクチャデータを、前記ベースビュービデオプレーンメモリと前記ディペンデントビュービデオプレーンメモリとの両方へ導くように、経路を切り替えるスイッチとを含み、
　前記ベースビュービデオプレーンメモリに格納されたピクチャデータと、前記ディペンデントビュービデオプレーンメモリに格納されたピクチャデータとを出力する
ことを特徴とする請求項１に記載の再生装置。
ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置の集積回路であって、
　前記３Ｄビデオストリームを用いて立体視再生を行う場合、前記ベースビュービデオストリームをデコードして得られたピクチャデータと前記ディペンデントビュービデオストリームをデコードして得られたピクチャデータとを出力し、
　前記３Ｄビデオストリームを用いて平面視再生を行う場合、前記ベースビュービデオストリームをデコードして得られた各ピクチャデータを、少なくとも２回ずつ繰り返して出力する
ことを特徴とする集積回路。
記録媒体に記録されたビデオストリームを再生区間情報に基づいて再生する再生装置であって、
　前記再生区間情報には、立体視再生を実現する３Ｄ再生区間を規定するものと、平面視再生を実現する２Ｄ再生区間を規定するものとがあり、
　前記再生装置は、
　３Ｄ再生区間と２Ｄ再生区間とをシームレスに接続する場合、２Ｄ再生区間に属する圧縮ピクチャデータのデコードにより得られた各ピクチャデータを、少なくとも２回ずつ繰り返して表示装置に出力する
ことを特徴とする再生装置。
２Ｄ再生区間において各ピクチャデータを繰り返し出力する回数は、１ピクチャデータにつき２回であり、
　前記繰り返しにより、平面視再生における出力フレームレートを、立体視再生における出力フレームレートと同じフレームレートに変換する
ことを特徴とする請求項７に記載の再生装置。
前記再生装置は、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　ベースビュービデオストリームとディペンデントビュービデオストリームとをデコードするデコーダと、
　前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替えるスイッチとを含み、
　３Ｄ再生区間の再生中に、前記ベースビュービデオプレーンメモリに格納されたピクチャデータと、前記ディペンデントビュービデオプレーンメモリに格納されたピクチャデータとを出力し、
　２Ｄ再生区間の再生中に、前記ベースビュービデオプレーンメモリに格納されたピクチャデータを、少なくとも２回ずつ繰り返して出力する
ことを特徴とする請求項７に記載の再生装置。
前記再生装置は、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　ベースビュービデオストリームとディペンデントビュービデオストリームとをデコードするデコーダと、
　３Ｄ再生区間の再生中に、前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替え、
　２Ｄ再生区間の再生中に、前記ベースビュービデオストリームのデコードにより得られたピクチャデータを、前記ベースビュービデオプレーンメモリと前記ディペンデントビュービデオプレーンメモリとの両方へ導くように、経路を切り替えるスイッチとを含み、
　前記ベースビュービデオプレーンメモリに格納されたピクチャデータと、前記ディペンデントビュービデオプレーンメモリに格納されたピクチャデータとを出力する
ことを特徴とする請求項７に記載の再生装置。
記録媒体に記録されたビデオストリームを再生区間情報に基づいて再生する再生装置の集積回路であって、
　前記再生区間情報には、立体視再生を実現する３Ｄ再生区間を規定するものと、平面視再生を実現する２Ｄ再生区間を規定するものとがあり、
　前記集積回路は、
　３Ｄ再生区間と２Ｄ再生区間とをシームレスに接続する場合、２Ｄ再生区間に属する圧縮ピクチャデータのデコードにより得られた各ピクチャデータを、少なくとも２回ずつ繰り返して出力する
ことを特徴とする再生装置。
ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームと、プレイリスト情報とを格納する記録媒体であって、
　前記プレイリスト情報は、前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームとの再生時間軸における再生開始時刻及び再生終了時刻とにより再生区間を規定する再生区間情報を含み、
　前記再生区間情報には、立体視再生を実現する３Ｄ再生区間を規定するものと、平面視再生を実現する２Ｄ再生区間を規定するものとがあり、
　２Ｄ再生区間を規定する再生区間情報はさらに、当該再生区間情報により規定される再生区間に属する圧縮ピクチャデータのデコードにより得られた各ピクチャデータを、少なくとも２回ずつ繰り返して表示装置に出力することを指示するフラグを含む
ことを特徴とする記録媒体。
ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置であって、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームとをデコードするデコーダと、
　前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替えるスイッチとを含み、
　前記スイッチは、前記ベースビュービデオストリーム及び前記ディペンデントビュービデオストリームのうち、何れか一方のビデオストリームのデコード時にエラーが生じ、一方のピクチャデータが欠損した場合、他方のビデオストリームのデコードにより得られたピクチャデータを、両方のビデオプレーンメモリへ導くように、経路を切り替える
ことを特徴とする再生装置。
ベースビュービデオストリームとディペンデントビュービデオストリームとを含む３Ｄビデオストリームを再生する再生装置であって、
　ベースビュービデオプレーンメモリと、
　ディペンデントビュービデオプレーンメモリと、
　前記ベースビュービデオストリームと前記ディペンデントビュービデオストリームとをデコードするデコーダと、
　前記ベースビュービデオストリームのデコードにより得られたピクチャデータを前記ベースビュービデオプレーンメモリへ導き、前記ディペンデントビュービデオストリームのデコードにより得られたピクチャデータを前記ディペンデントビュービデオプレーンメモリへ導くように、経路を切り替えるスイッチとを含み、
　前記ベースビュービデオストリーム及び前記ディペンデントビュービデオストリームのうち、何れか一方のビデオストリームのデコード時にエラーが生じ、一方のピクチャデータが欠損した場合、他方のビデオプレーンメモリに格納されているピクチャデータと、前記一方のビデオストリームに対応するビデオプレーンメモリに前記エラーの直前に格納されたピクチャデータとを出力する
ことを特徴とする再生装置。
ベースビュービデオストリームと、ディペンデントビュービデオストリームとを含む３Ｄビデオストリームと、ストリーム情報とが記録された記録媒体であって、
　前記ベースビュービデオストリームと、前記ディペンデントビュービデオストリームとは、同じ再生時間軸を有し、
　前記ストリーム情報は、
　ベースビュービデオストリーム上のエントリーポイントを、前記再生時間軸における再生時刻に対応付けて示す第１エントリーマップと、
　ディペンデントビュービデオストリーム上のエントリーポイントを、前記再生時間軸における再生時刻に対応付けて示す第２エントリーマップとを含み、
　前記第１エントリーマップに登録されているエントリーポイントに対応付けられている再生時刻と、同じ再生時刻に対応付けられているエントリーポイントが、前記第２エントリーマップに登録されている
ことを特徴とする記録媒体。