(57)【要約】【課題】複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにする。【解決手段】3D_PL_typeはPlayListの種類を表す。3D_PL_typeの値の01は、3D再生のうちのB-D1再生用のPlayListであることを表し、10は、3D再生のうちのB-D2再生用のPlayListであることを表す。view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。本発明は、BD-ROM規格に対応した再生装置に適用することができる。【選択図】図２０
2010263613.tif 000002
【特許請求の範囲】
【請求項１】
複数視点の映像データを所定の符号化方式で符号化する符号化手段と、
前記符号化手段による符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成する生成手段と
を備える情報処理装置。
【請求項２】
前記生成手段は、前記視点情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する再生制御情報を生成し、
前記生成手段により生成された前記再生制御情報を、前記基本ストリームおよび前記拡張ストリームとともに記録媒体に記録する記録手段をさらに備える
請求項１に記載の情報処理装置。
【請求項３】
前記符号化手段は、前記基本ストリームと前記拡張ストリームのうちの少なくともいずれかのストリームに含まれる各ピクチャに、前記視点情報を付加する
請求項１に記載の情報処理装置。
【請求項４】
前記生成手段は、前記視点情報を含む、前記基本ストリームと前記拡張ストリームの伝送の制御に用いられる伝送制御情報を生成する
請求項１に記載の情報処理装置。
【請求項５】
前記生成手段は、二次元画像の再生を制御する情報であるのか、三次元画像の再生を制御する情報であるのかを表す種別情報を生成し、二次元画像の再生を制御する情報であることを表す前記種別情報を含む、前記基本ストリームの再生を制御する第１の再生制御情報を生成し、三次元画像の再生を制御する情報であることを表す前記種別情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する第２の再生制御情報を生成する
請求項１に記載の情報処理装置。
【請求項６】
前記生成手段は、前記第２の再生制御情報の拡張用のフィールドに、前記拡張ストリームの再生に関する情報を設定する
請求項５に記載の情報処理装置。
【請求項７】
複数視点の映像データを所定の符号化方式で符号化し、
符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成する
ステップを含む情報処理方法。
【請求項８】
複数視点の映像データを所定の符号化方式で符号化し、
符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成する
ステップを含む処理をコンピュータに実行させるプログラム。
【請求項９】
複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームおよび拡張ストリームと、
前記基本ストリームと前記拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する再生制御情報と
が記録された記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、プログラム、および記録媒体に関し、特に、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにした情報処理装置、情報処理方法、プログラム、および記録媒体に関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray(R))-ROM(Read Only Memory)等のBlu-Ray(R) Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−０９５２４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
従来のBDの規格で用いられている、画像データの管理情報をそのまま用いた場合であっても、ステレオ画像のデータを再生することはできない。
【００１１】
本発明はこのような状況に鑑みてなされたものであり、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにするものである。
【課題を解決するための手段】
【００１２】
本発明の一側面の情報処理装置は、複数視点の映像データを所定の符号化方式で符号化する符号化手段と、前記符号化手段による符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成する生成手段を備える。
【００１３】
前記生成手段には、前記視点情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する再生制御情報を生成させることができる。この場合、前記生成手段により生成された前記再生制御情報を、前記基本ストリームおよび前記拡張ストリームとともに記録媒体に記録する記録手段をさらに設けることができる。
【００１４】
前記符号化手段には、前記基本ストリームと前記拡張ストリームのうちの少なくともいずれかのストリームに含まれる各ピクチャに、前記視点情報を付加させることができる。
【００１５】
前記生成手段には、前記視点情報を含む、前記基本ストリームと前記拡張ストリームの伝送の制御に用いられる伝送制御情報を生成させることができる。
【００１６】
前記生成手段には、二次元画像の再生を制御する情報であるのか、三次元画像の再生を制御する情報であるのかを表す種別情報を生成させ、二次元画像の再生を制御する情報であることを表す前記種別情報を含む、前記基本ストリームの再生を制御する第１の再生制御情報を生成させ、三次元画像の再生を制御する情報であることを表す前記種別情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する第２の再生制御情報を生成させることができる。
【００１７】
前記生成手段には、前記第２の再生制御情報の拡張用のフィールドに、前記拡張ストリームの再生に関する情報を設定させることができる。
【００１８】
本発明の一側面の情報処理方法は、複数視点の映像データを所定の符号化方式で符号化し、符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成するステップを含む。
【００１９】
本発明の一側面のプログラムは、複数視点の映像データを所定の符号化方式で符号化し、符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を生成するステップを含む処理をコンピュータに実行させる。
【００２０】
本発明の一側面の記録媒体は、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームおよび拡張ストリームと、前記基本ストリームと前記拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報を含む、前記基本ストリームと前記拡張ストリームの再生を制御する再生制御情報とが記録されたものである。
【００２１】
本発明の一側面においては、複数視点の映像データが所定の符号化方式で符号化され、符号化によって得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを表す視点情報が生成される。
【発明の効果】
【００２２】
本発明によれば、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】MVCエンコーダの構成例を示すブロック図である。
【図４】参照画像の例を示す図である。
【図５】AVストリームの管理の例を示す図である。
【図６】Main PathとSub Pathの構造を示す図である。
【図７】光ディスクに記録されるファイルの管理構造の例を示す図である。
【図８】PlayListファイルのシンタクスを示す図である。
【図９】図８のSubPath()のシンタクスを示す図である。
【図１０】SubPath_typeの例を示す図である。
【図１１】図９のSubPlayItem(i)のシンタクスを示す図である。
【図１２】図８のPlayItem()のシンタクスを示す図である。
【図１３】図１２のSTN_table()のシンタクスを示す図である。
【図１４】application_typeの例を示す図である。
【図１５】application_typeとSubPath_typeの設定の例を示す図である。
【図１６】application_typeとSubPath_typeの設定の他の例を示す図である。
【図１７】application_typeとSubPath_typeの設定のさらに他の例を示す図である。
【図１８】Java（登録商標）アプリケーションによるstream_idの指定の例を示す図である。
【図１９】PlayListファイルのシンタクスを示す図である。
【図２０】図１９のreserved_for_future_useの使い方の例を示す図である。
【図２１】3D_PL_typeの値の意味を示す図である。
【図２２】view_typeの値の意味を示す図である。
【図２３】再生装置の構成例を示すブロック図である。
【図２４】図２３のデコーダ部の構成例を示す図である。
【図２５】ビデオストリームの処理を行う構成を示す図である。
【図２６】Access Unitの例を示す図である。
【図２７】ソフト製作処理部の構成例を示すブロック図である。
【図２８】ソフト製作処理部を含む構成の例を示す図である。
【図２９】PMTにview_typeを記述する場合の例を示す図である。
【図３０】エレメンタリストリーム中にview_typeを記述する場合の例を示す図である。
【図３１】Access Unitの構成を示す図である。
【図３２】コンピュータのハードウェアの構成例を示すブロック図である。
【発明を実施するための形態】
【００２４】
［再生システムの構成例］
図１は、本発明を適用した再生装置１を含む再生システムの構成例を示す図である。
【００２５】
図１に示すように、この再生システムは、再生装置１と表示装置３がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置１には、BDなどの光ディスク２が装着される。
【００２６】
光ディスク２には、視点の数が２つのステレオ画像（いわゆる3D画像）を表示するために必要なストリームが記録されている。
【００２７】
再生装置１は、光ディスク２に記録されているストリームの3D再生に対応したプレーヤである。再生装置１は、光ディスク２に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置３に表示させる。音声についても同様に再生装置１により再生され、表示装置３に設けられるスピーカなどから出力される。
【００２８】
3D画像の表示の方式として様々な方式が提案されている。ここでは、3D画像の表示の方式として、以下のタイプ１の表示方式と、タイプ２の表示方式とを採用する。
【００２９】
タイプ１の表示方式は、3D画像のデータを左眼で観察される画像（L画像）のデータと、右眼で観察される画像（R画像）のデータとで構成し、L画像とR画像を交互に表示することで、3D画像を表示する方式である。
【００３０】
タイプ２の表示方式は、3D画像を生成する元になる画像である元画像のデータとDepthのデータとを用いて生成されるL画像とR画像を表示することで、3D画像を表示する方式である。タイプ２の表示方式で用いられる3D画像のデータは、元画像のデータと、元画像に与えることによってL画像とR画像を生成することができるDepthのデータとで構成される。
【００３１】
タイプ１の表示方式は、視聴するときにメガネが必要となる表示方式である。タイプ２の表示方式は、メガネなしで3D画像を視聴できる表示方式である。
【００３２】
光ディスク２には、タイプ１と２のいずれの表示方式によっても3D画像を表示することができるようなストリームが記録されている。
【００３３】
そのようなストリームを光ディスク２に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)プロファイル規格が採用される。
【００３４】
［H.264 AVC/MVC Profile］
H.264 AVC/MVCプロファイル規格では、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCプロファイル規格を単にMVCという。
【００３５】
図２は、撮影の例を示す図である。
【００３６】
図２に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
【００３７】
図３は、MVCエンコーダの構成例を示すブロック図である。
【００３８】
図３に示すように、MVCエンコーダ１１は、H.264/AVCエンコーダ２１、H.264/AVCデコーダ２２、Depth算出部２３、Dependent view videoエンコーダ２４、およびマルチプレクサ２５から構成される。
【００３９】
L画像用のカメラにより撮影された映像＃１のストリームはH.264/AVCエンコーダ２１とDepth算出部２３に入力される。また、R画像用のカメラにより撮影された映像＃２のストリームはDepth算出部２３とDependent view videoエンコーダ２４に入力される。映像＃２のストリームがH.264/AVCエンコーダ２１とDepth算出部２３に入力され、映像＃１のストリームがDepth算出部２３とDependent view videoエンコーダ２４に入力されるようにしてもよい。
【００４０】
H.264/AVCエンコーダ２１は、映像＃１のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ２１は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ２２とマルチプレクサ２５に出力する。
【００４１】
H.264/AVCデコーダ２２は、H.264/AVCエンコーダ２１から供給されたAVCビデオストリームをデコードし、デコードして得られた映像＃１のストリームをDependent view videoエンコーダ２４に出力する。
【００４２】
Depth算出部２３は、映像＃１のストリームと映像＃２のストリームに基づいてDepthを算出し、算出したDepthのデータをマルチプレクサ２５に出力する。
【００４３】
Dependent view videoエンコーダ２４は、H.264/AVCデコーダ２２から供給された映像＃１のストリームと、外部から入力された映像＃２のストリームをエンコードし、Dependent view videoストリームを出力する。
【００４４】
Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図４に示すように、Dependent view videoには、Base view videoを参照画像とする予測符号化が許されている。例えばL画像をBase view videoとするとともにR画像をDependent view videoとして符号化を行った場合、その結果得られるDependent view videoストリームのデータ量は、Base view videoストリームのデータ量に比較して少なくなる。
【００４５】
なお、H.264/AVCでの符号化であるから、Base view videoについて時間方向の予測は行われている。また、Dependent view videoについても、view間の予測とともに、時間方向の予測が行われている。Dependent view videoをデコードするには、エンコード時に参照先とした、対応するBase view videoのデコードが先に終了している必要がある。
【００４６】
Dependent view videoエンコーダ２４は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ２５に出力する。
【００４７】
マルチプレクサ２５は、H.264/AVCエンコーダ２１から供給されたBase view videoストリームと、Depth算出部２３から供給されたDependent view videoストリーム（Depthのデータ）と、Dependent view videoエンコーダ２４から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは１本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
【００４８】
マルチプレクサ２５は、生成したTS（MPEG2 TS）を出力する。マルチプレクサ２５から出力されたTSは、他の管理データとともに記録装置において光ディスク２に記録され、光ディスク２に記録された形で再生装置１に提供される。
【００４９】
タイプ１の表示方式においてBase view videoとともに用いられるDependent view videoと、タイプ２の表示方式においてBase view videoとともに用いられるDependent view video（Depth）とを区別する必要がある場合、前者をD1 view videoといい、後者をD2 view videoという。
【００５０】
また、Base view videoとD1 view videoを用いて行われる、タイプ１の表示方式での3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる、タイプ２の表示方式での3D再生をB-D2再生という。
【００５１】
再生装置１は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク２から読み出して再生する。
【００５２】
また、再生装置１は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク２から読み出して再生する。
【００５３】
さらに、再生装置１は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク２から読み出して再生する。
【００５４】
Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
【００５５】
以下、Dependent view videoがD1 view videoである場合について主に説明する。単にDependent view videoというときは、D1 view videoを表すことになる。D2 view videoについても、D1 view videoと同様にして光ディスク２に記録され、再生される。
【００５６】
［アプリケーションフォーマット］
図５は、再生装置１によるAVストリームの管理の例を示す図である。
【００５７】
AVストリームの管理は、図５に示すようにPlayListとClipの２つのレイヤを用いて行われる。AVストリームは、光ディスク２だけでなく、再生装置１のローカルストレージに記録されていることもある。
【００５８】
ここでは、１つのAVストリームとそれに付随する情報であるClip Informationのペアを１つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。
【００５９】
AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationファイルは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。
【００６０】
PlayListはAVストリームの再生区間の集まりである。AVストリーム中の１つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。図５に示すように、PlayListは１つまたは複数のPlayItemにより構成される。
【００６１】
図５の左から１番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。
【００６２】
左から２番目のPlayListは１つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。
【００６３】
左から３番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。
【００６４】
例えば、左から１番目のPlayListに含まれる左側のPlayItemが再生位置としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を管理するための再生管理情報として用いられる。
【００６５】
PlayListの中で、１つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。
【００６６】
また、PlayListの中で、Main Pathに並行して、１つ以上のSubPlayItemの並びによって作られる再生パスをサブパス（Sub Path）という。
【００６７】
図６は、Main PathとSub Pathの構造を示す図である。
【００６８】
PlayListは、１つのMain Pathと１つ以上のSub Pathを持つことができる。
【００６９】
上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。
【００７０】
図６のPlayListは、３つのPlayItemの並びにより作られる１つのMain Pathと、３つのSub Pathを有している。
【００７１】
Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。
【００７２】
図６の例においては、Subpath_id=0のSub Pathには１つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには２つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには１つのSubPlayItemが含まれる。
【００７３】
１つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム（メイン画像データ）が含まれる。
【００７４】
また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで（同期して）再生されるオーディオストリームが１つ以上含まれてもよいし、含まれなくてもよい。
【００７５】
Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ（PG(Presentation Graphic)）のストリームが１つ以上含まれてもよいし、含まれなくてもよい。
【００７６】
Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが１つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。
【００７７】
１つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される０個以上のオーディオストリーム、０個以上のPGストリーム、および、０個以上のIGストリームが多重化されている。
【００７８】
また、１つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム（別ストリーム）の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。
【００７９】
このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開２００８−２５２７４０号公報、特開２００５−３４８３１４号公報に記載されている。
【００８０】
［ディレクトリ構造］
図７は、光ディスク２に記録されるファイルの管理構造の例を示す図である。
【００８１】
図７に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク２上には１つのrootディレクトリが作成される。rootディレクトリの下が、１つの記録再生システムで管理される範囲となる。
【００８２】
rootディレクトリの下にはBDMVディレクトリが置かれる。
【００８３】
BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
【００８４】
BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
【００８５】
PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、５桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。図７に示す１つのPlayListファイルには「00000.mpls」のファイル名が設定されている。
【００８６】
CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、５桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
【００８７】
図７の３つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
【００８８】
例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。
【００８９】
「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。
【００９０】
「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。
【００９１】
STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、５桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、５桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
【００９２】
「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。
【００９３】
「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。
【００９４】
「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。
【００９５】
「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。
【００９６】
図７に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
【００９７】
［各データのシンタクス］
図８は、PlayListファイルに記述されるPlayList()のシンタクスを示す図である。
【００９８】
lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
【００９９】
lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１００】
number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す１６ビットのフィールドである。図６の例の場合、PlayItemの数は３である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に０から割り振られる。例えば、図６のPlayItem_id＝０，１，２が割り振られる。
【０１０１】
number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す１６ビットのフィールドである。図６の例の場合、Sub Pathの数は３である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に０から割り振られる。例えば、図６のSubpath_id＝０，１，２が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。
【０１０２】
図９は、図８のSubPath()のシンタクスを示す図である。
【０１０３】
lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
【０１０４】
lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１０５】
SubPath_typeは、Sub Pathを用いて処理を行うアプリケーションの種類を示す８ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。SubPath_typeについては図１０を参照して後述する。
【０１０６】
SubPath_typeの後には、１５ビットのreserved_for_future_useが用意される。
【０１０７】
is_repeat_SubPathは、Sub Pathの再生方法を指定する１ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を１回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合（Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など）に利用される。
【０１０８】
Is_repeat_SubPathの後には、８ビットのreserved_for_future_useが用意される。
【０１０９】
number_of_SubPlayItemsは、１つのSub Pathの中にあるSubPlayItemの数（エントリー数）を示す８ビットのフィールドである。例えば、図６のSubPath_id＝０のSubPlayItemのnumber_of_SubPlayItemsは１であり、SubPath_id＝１のSubPlayItemのnumber_of_SubPlayItemsは２である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem（）が参照される。
【０１１０】
図１０は、SubPath_typeの例を示す図である。
【０１１１】
図１０において、「Out-of-mux」は、Sub Pathが参照するストリーム（Sub Pathを構成するSubPlayItemが参照するストリーム）と、Main Pathが参照するストリーム（Main Pathを構成するPlayItemが参照するストリーム）とが、それぞれ異なるTSに多重化されていることを表す。
【０１１２】
反対に、「In-of-mux」は、Sub Pathが参照するストリームと、Main Pathが参照するストリームとが、同じTSに多重化されていることを表す。
【０１１３】
SubPath_type＝０，１はreservedとされている。
【０１１４】
SubPath_type＝２は、Audio presentation path of the Browsable slideshow（プラウザブルスライドショーのオーディオプレゼンテーションパス）とされている。
【０１１５】
SubPath_type＝３は、Interactive graphics presentation menu（インタラクティブグラフィックスのプレゼンテーションメニュー）とされている。
【０１１６】
SubPath_type＝４は、Text subtitle presentation path（テキスト字幕のプレゼンテーションパス）とされている。
【０１１７】
SubPath_type＝５は、2nd Audio Presentation path（2ndオーディオストリームを参照するためのパス）とされている。SubPath_type＝５が設定されたSub Pathが参照する２番目のオーディオストリームは、例えば、映画に対する監督のコメント（音声）である。
【０１１８】
SubPath_type＝６は、2nd Video Presentation path（2ndビデオストリームを参照するためのパス）とされている。SubPath_type＝６が設定されたSub Pathが参照する２番目のビデオストリームは、例えば、映画に対する監督のコメント（動画像）である。
【０１１９】
SubPath_type＝７は、１本以上のES(Primary audio/PG/IG/Secondary audio)のパスや、ピクチャインピクチャプレゼンテーションパスとされている。
【０１２０】
SubPath_type＝８〜１１は、3D再生を行うアプリケーション用のSubPathを定義する。ここでは、SubPathが参照するDependent view videoストリームの多重化のパターンに応じて異なる値が設定される。
【０１２１】
SubPath_type＝８は、「Out-of-mux 3D SubPath from Disc」である。これは、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されていて、かつ、Main Pathが参照するBase view videoストリームとは異なるTSに多重化されていることを表す。
【０１２２】
SubPath_type＝９は、「In-mux 3D SubPath from Disc」である。これは、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されていて、かつ、Main Pathが参照するBase view videoストリームと同じTSに多重化されていることを表す。
【０１２３】
SubPath_type＝１０は、「Out-of-mux 3D SubPath from Local Storage」である。これは、Sub Pathが参照するDependent view videoストリームがローカルストレージに記録されていて、かつ、Main Pathが参照するBase view videoストリームとは異なるTSに多重化されていることを表す。
【０１２４】
後述するように、再生装置１においては、Dependent view videoストリームをサーバからダウンロードし、光ディスク２に記録されているBase view videoストリームと併せて用いることによって3D再生を行うことができるようになされている。
【０１２５】
SubPath_type＝１１は、「In-mux 3D SubPath from Local Storage」である。これは、Sub Pathが参照するDependent view videoストリームがローカルストレージに記録されていて、かつ、Main Pathが参照するBase view videoストリームと同じTSに多重化されていることを表す。この場合、Base view videoストリームもローカルストレージに記録されていることになる。
【０１２６】
SubPath_type＝１２乃至２５５は、reservedとされている。
【０１２７】
このように、Dependent view videoストリームを参照するSub Pathには、それが参照するDependent view videoストリームの記録場所とTSに対する多重化のパターンを表す値が設定される。
【０１２８】
これにより、再生装置１は、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されているのか、またはローカルストレージに記録されているのかを識別することができる。
【０１２９】
また、再生装置１は、Sub Pathが参照するDependent view videoストリームがBase view videoストリームと同じTSに多重化されているのか、または異なるTSに多重化されているのかを識別することができる。
【０１３０】
再生装置１は、識別結果に応じて、Base view videoストリームの読み出しの処理を切り替えることができる。
【０１３１】
図１１は、図９のSubPlayItem(i)のシンタクスを示す図である。
【０１３２】
lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
【０１３３】
図１１のSubPlayItem(i)は、SubPlayItemが１つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。
【０１３４】
SubPlayItemが１つのClipを参照する場合について説明する。
【０１３５】
Clip_Information_file_name[0]は参照するClipを表す。
【０１３６】
Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。
【０１３７】
is_multi_Clip_entriesはマルチクリップの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。
【０１３８】
ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
【０１３９】
SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。
【０１４０】
sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。
【０１４１】
SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。
【０１４２】
「if（is_multi_Clip_entries＝＝１ｂ」であり、SubPlayItemが複数のClipを参照する場合について説明する。
【０１４３】
num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。
【０１４４】
Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。
【０１４５】
ref_to_STC_id[SubClip_entry_id]はSTC不連続点（システムタイムベースの不連続点）に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。
【０１４６】
図１２は、図８のPlayItem()のシンタクスを示す図である。
【０１４７】
lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
【０１４８】
Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むmt2sファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ５桁の数字が含まれる。
【０１４９】
Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。
【０１５０】
ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
【０１５１】
IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。
【０１５２】
OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。
【０１５３】
STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。
【０１５４】
図１３は、図１２のSTN_table()のシンタクスを示す図である。
【０１５５】
STN_table()は、PlayItemの属性として設定されている。
【０１５６】
lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す１６ビットの符号なし整数である。lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１５７】
number_of_video_stream_entriesは、STN_table()の中でエントリーされる（登録される）、video_stream_idが与えられるストリームの数を表す。
【０１５８】
video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームのIDがこの記述により特定される。Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、後述するように計算により求められるようにしてもよい。
【０１５９】
video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。
【０１６０】
number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる１番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。
【０１６１】
number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる２番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。
【０１６２】
number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、DVDのサブピクチャのようなビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。
【０１６３】
number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、インタラクティブグラフィックスストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
【０１６４】
後述するMain TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームのIDではなくTSのIDであることは、stream_attribute()に記述される。
【０１６５】
図１４は、application_typeの例を示す図である。
【０１６６】
application_typeはClip Informationファイル（ClipInfo()）に記述される。Clip Informationファイルは各Clipに１つずつ用意される。
【０１６７】
application_type=0はreservedとされている。
【０１６８】
application_type=１は、その記述を含むClip Informationファイルに対応するTS（Clip）がMovieアプリケーション用のTSであることを表す。
【０１６９】
application_type=2は、その記述を含むClip Informationファイルに対応するTSがTime-based Slideshow用のTSであることを表す。
【０１７０】
application_type=3は、その記述を含むClip Informationファイルに対応するTSがBrowsable Slideshow用のTSであることを表す。
【０１７１】
application_type=4は、その記述を含むClip Informationファイルに対応するTSがSub Path用のBrowsable SlideshowのTSであることを表す。
【０１７２】
application_type=5は、その記述を含むClip Informationファイルに対応するTSがSub Pathのインタラクティブグラフィックス用のTSであることを表す。
【０１７３】
application_type=6は、その記述を含むClip Informationファイルに対応するTSがSub Pathのテキストサブタイトル（テキスト字幕データ）用のTSであることを表す。
【０１７４】
application_type=7は、その記述を含むClip Informationファイルに対応するTSが１つ以上のESを含むSub Path用のTSであることを表す。
【０１７５】
application_type=8は、その記述を含むClip Informationファイルに対応するTSが3D再生を行うアプリケーション用のTSであることを表す。
【０１７６】
application_type=9-255はreservedとされている。
【０１７７】
このように、application_typeの値として3D再生を行うアプリケーション用の値が定義されている。これにより、3D再生を行うアプリケーションは、自身が扱うTSをapplication_typeの値から識別することが可能になる。
【０１７８】
［application_typeとSubPath_typeの設定例］
図１５は、application_typeとSubPath_typeの設定の例を示す図である。
【０１７９】
図１５のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。このように、Dependent view videoストリームが、Base view videoストリームとともにMain TSに含まれていることもある。
【０１８０】
光ディスク２には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームが含まれているTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。
【０１８１】
ビデオと同様に3Dでの表示が可能になるように、PG、IGについてもBaseとDependentのそれぞれのストリームが用意されている。
【０１８２】
それぞれのストリームをデコードして得られたPG、IGのBase viewのプレーンは、適宜、Base view videoストリームをデコードして得られたBase view videoのプレーンと合成されて表示される。同様に、PG、IGのDependent viewのプレーンは、適宜、Dependent view videoストリームをデコードして得られたDependent view videoのプレーンと合成されて表示される。
【０１８３】
例えば、Base view videoストリームがL画像のストリームであり、Dependent view videoストリームがR画像のストリームである場合、PG、IGについても、そのBase viewのストリームはL画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはR画像のグラフィックスのストリームとなる。
【０１８４】
一方、Base view videoストリームがR画像のストリームであり、Dependent view videoストリームがL画像のストリームである場合、PG、IGについても、そのBase viewのストリームはR画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはL画像のグラフィックスのストリームとなる。
【０１８５】
Main TSのapplication_type（Main TSに対応するClip Informationファイルに記述されているapplication_type）の値は１である。
【０１８６】
Main TSに含まれるBase view videoストリームは、3D再生用のアプリケーションだけでなく、上述したように通常の2D再生用のアプリケーションであるMovieアプリケーションが扱うストリームでもある。Movieアプリケーションと3D再生用のアプリケーションの両方が扱うTSにはapplication_typeの値として１が設定される。
【０１８７】
また、Base view videoストリームと同じTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は９である。この例においては、Dependent view videoストリームは光ディスク２に記録されている。
【０１８８】
図１６は、application_typeとSubPath_typeの設定の他の例を示す図である。
【０１８９】
図１６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
【０１９０】
Main TSのapplication_typeの値は１である。
【０１９１】
また、Base view videoストリームと同じTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は９である。この例においても、Dependent view videoストリームは光ディスク２に記録されている。
【０１９２】
図１６のSub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが含まれている。
【０１９３】
3D再生を行うアプリケーションが扱うTSであるから、Sub TSのapplication_typeの値は８である。
【０１９４】
図１７は、application_typeとSubPath_typeの設定のさらに他の例を示す図である。
【０１９５】
図１７のMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【０１９６】
Main TSのapplication_typeの値は１である。
【０１９７】
図１７のSub TSにはDependent view videoストリームが含まれている。
【０１９８】
Base view videoストリームとは別のTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は８である。この例においても、Dependent view videoストリームは光ディスク２に記録されている。
【０１９９】
このように、3D再生を行うアプリケーションが扱うSub TSに対応するClip Informationファイルには、3D再生を行うアプリケーションが扱うTSであることを表す値がapplication_typeの値として設定される。
【０２００】
また、Dependent view videoストリームを参照するSub Pathには、そのDependent view videoストリームの記録場所と多重化のパターンに応じた値がSubPath_typeに設定される。
【０２０１】
なお、BD規格においては、光ディスク２から同時に読み出すことのできるTSの数が２本までという制約が存在する。
【０２０２】
また、Browsable Slideshowでは、上述したように、Main Pathが参照するビデオストリーム（静止画のスライドショーのストリーム）とは別に、BGMとして使用するオーディオストリームをSub Path（SubPath_type=2）によって参照することが想定されている。スライドショーの再生時には、Main Pathが参照するビデオストリームとSub Pathが参照するオーディオストリームを同時に読み出すことになる。
【０２０３】
ここで、静止画のスライドショーの3D表示を考える。ビデオストリームとしてBase view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合、その２本のTSを読み出すことはできるが、BGMとして使用するオーディオストリームを読み出すことはできなくなる。
【０２０４】
そこで、運用として、Browsable slideshow(Application_type=3)については、SubPath_type=9か11のみ設定可能とする。Browsable slideshowアプリケーションが扱うTSに含まれるDependent view videoストリームを参照するSub PathのSubPath_typeの値として、Base view videoストリームとは別のTSに含まれていることを表す8か10の値が設定されることはない。
【０２０５】
このようにしてSubPath_typeの値として設定可能な値をApplication_typeに応じて制限することにより、TSを読み出すことができなくなるといった不都合を回避することができる。
【０２０６】
［stream_idの定義］
図１３を参照して説明したように、STN_tableにおいて、PlayItemとSubPlayItemが参照するそれぞれのストリームのID（stream_id）が管理される。
【０２０７】
STN_tableにおいて管理されるvideo_stream_idはBase view videoストリームのIDを表し、PG_txtST_stream_idはBase PGストリームのIDを表す。また、IG_stream_idはBase IGストリームのIDを表す。
【０２０８】
ここで、Dependent viewのストリームについては、それぞれのstream_idをSTN_tableに登録するのではなく、Base viewのストリームのstream_idから計算により導き出すことができるようにする。
【０２０９】
例えば、Dependent view videoストリームのstream_idは下式（１）により定義される。
video_stream_id + x = dependent_view_video_stream_id    ・・・      （１）
【０２１０】
Dependent PGストリームのstream_idは下式（２）により定義される。
PG_textST_stream_id + x = Dependent_PG_textST_stream_id    ・・・      （２）
【０２１１】
Dependent IGストリームのstream_idは下式（３）により定義される。
IG_stream_id + x = Dependent_IG_stream_id    ・・・      （３）
【０２１２】
式（１）乃至（３）のxの値は任意である。式（１）乃至（３）においてそれぞれ異なる値がxとして代入されるようにしてもよい。
【０２１３】
xの値については、STN_tableから特定できるようにしてもよいし、再生装置１に予め設定されているようにしてもよい。
【０２１４】
これにより、光ディスク２にデータを記録する記録装置は、Dependent viewのストリームのstream_idを、Base viewのストリームのstream_idとは別にSTN_tableに設定しないで済む。
【０２１５】
また、再生装置１は、Base viewのストリームのstream_idをSTN_tableから特定すれば、それに対応するDependent viewのストリームのstream_idを計算により特定することが可能になる。
【０２１６】
BD規格においては、ストリームを使った各種の処理がJava（登録商標）アプリケーションによって実現される。
【０２１７】
例えば、あるストリームを使った処理を行う場合、図１８に示すように、Java（登録商標）アプリケーションは、そのストリームの読み出しを、stream_idを指定してAPI(Application Programming Interface)を介してドライバに指示する。
【０２１８】
ドライバは、APIを介してJava（登録商標）アプリケーションから指定されたstream_idをBase viewのストリームのstream_idとし、それに基づいてDependent viewのストリームのstream_idを計算により特定する。また、特定したstream_idに基づいて、Base viewのストリームとDependent viewのストリームを読み出す。
【０２１９】
これにより、3D表示を行う場合であっても、Java（登録商標）アプリケーションがAPIを介して指定するstream_idは１つで済む。また、Base viewとDependent viewの２つのstream_idを指定することができるようにAPIを拡張させる必要がない。
【０２２０】
また、Base viewのストリームのIDからDependent viewのストリームのIDを自動的に算出することができる利点として次のようなものもある。
【０２２１】
BDにおいては、再生するストリームをプレーヤが自動的に選択するためのアルゴリズムが準備されている。このアルゴリズムは、例えば、ある英語のビデオを再生すると、自動的に、どの字幕を一緒に再生するべきかが割り出せるようなアルゴリズムである。
【０２２２】
仮に、Dependent viewのストリームにもストリームIDを割り当てるようにした場合、従来のプレーヤが行っていたストリーム再生選択アルゴリズムの処理を、Dependent viewについても同様に行う必要があり、プレーヤの処理の負荷が高くなってしまう。すなわち、プレーヤは、Base viewのストリームに注目してストリーム再生選択アルゴリズムの処理を行った後に、Dependent viewのストリームに注目してストリーム再生選択アルゴリズムの処理を行う必要がある。
【０２２３】
上述したようにしてBase viewのストリームのIDからDependent viewのストリームのIDを自動的に算出することができるようにすることにより、Dependent viewのストリームに注目して行う処理を回避することが可能になる。
【０２２４】
［PlayListファイルの記述の例］
図１９は、PlayListファイルのシンタクスを示す図である。
【０２２５】
PlayListファイルは、図７のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
【０２２６】
PlayListファイルに、図８を参照して説明した各記述が含まれる。
【０２２７】
図１９のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。
【０２２８】
version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは４桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。
【０２２９】
PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。
【０２３０】
PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。
【０２３１】
ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。
【０２３２】
ExtensionData_start_addressの後には、160bitのreserved_for_future_useが含まれる。
【０２３３】
AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
【０２３４】
PlayList()には、図８を参照して説明したような、Main PathやSub Pathなどに関するパラメータが格納される。
【０２３５】
PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。
【０２３６】
ExtensionData()には、プライベートデータが挿入できるようになっている。
【０２３７】
図２０は、PlayListファイルの記述の例を示す図である。
【０２３８】
図２０に示すように、PlayListファイルには、２bitの3D_PL_typeと１bitのview_typeが記述される。view_typeは、例えば図１９のAppInfoPlayList()に記述される。
【０２３９】
3D_PL_typeは、PlayListの種類を表す。
【０２４０】
view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。Dependent view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが表されるようにしてもよい。
【０２４１】
図２１は、3D_PL_typeの値の意味を示す図である。
【０２４２】
3D_PL_typeの値の00は、2D再生用のPlayListであることを表す。
【０２４３】
3D_PL_typeの値の01は、3D再生のうちのB-D1再生用のPlayListであることを表す。
【０２４４】
3D_PL_typeの値の10は、3D再生のうちのB-D2再生用のPlayListであることを表す。
【０２４５】
例えば、3D_PL_typeの値が01が10の場合、PlayListファイルのExtenstionData()に3DPlayList情報が登録される。3DPlayList情報として、例えば、Dependent view videoストリームのClipに対応するclpiファイルのファイル名（図７の例の場合、「00002.clpi」）などが登録される。
【０２４６】
図２２は、view_typeの値の意味を示す図である。
【０２４７】
view_typeの値の0は、3D再生を行う場合には、Base view videoストリームがL viewのストリームであることを表す。2D再生を行う場合には、Base view videoストリームがAVCビデオストリームであることを表す。
【０２４８】
view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０２４９】
view_typeがPlayListファイルに記述されることにより、再生装置１は、Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することが可能になる。
【０２５０】
例えば、HDMIケーブルを介して表示装置３にビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが再生装置１に要求されるものと考えられる。
【０２５１】
Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することができるようにすることにより、再生装置１は、L viewの信号とR viewの信号を区別して出力することが可能になる。
【０２５２】
［再生装置１の構成例］
図２３は、再生装置１の構成例を示すブロック図である。
【０２５３】
コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
【０２５４】
例えば、コントローラ５１は、ディスクドライブ５２を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ５１は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部５６に供給させる。
【０２５５】
ディスクドライブ５２は、コントローラ５１による制御に従って光ディスク２からデータを読み出し、読み出したデータを、コントローラ５１、メモリ５３、またはデコーダ部５６に出力する。
【０２５６】
メモリ５３は、コントローラ５１が各種の処理を実行する上において必要なデータなどを適宜記憶する。
【０２５７】
ローカルストレージ５４は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ５４には、サーバ７２からダウンロードされたDependent view videoストリームなどが記録される。ローカルストレージ５４に記録されているストリームもデコーダ部５６に適宜供給される。
【０２５８】
インターネットインタフェース５５は、コントローラ５１からの制御に従ってネットワーク７１を介してサーバ７２と通信を行い、サーバ７２からダウンロードしたデータをローカルストレージ５４に供給する。
【０２５９】
サーバ７２からは、光ディスク２に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたDependent view videoストリームを光ディスク２に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク２の内容とは異なる内容の3D再生を実現することが可能になる。Dependent view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。
【０２６０】
デコーダ部５６は、ディスクドライブ５２、または、ローカルストレージ５４から供給されたストリームをデコードし、得られたビデオ信号を表示装置３に出力する。オーディオ信号も所定の経路を介して表示装置３に出力される。
【０２６１】
操作入力部５７は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部５７はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ５１に供給する。
【０２６２】
図２４は、デコーダ部５６の構成例を示す図である。
【０２６３】
図２４にはビデオ信号の処理を行う構成を示している。デコーダ部５６においては、オーディオ信号のデコード処理も行われる。オーディオ信号を対象として行われたデコード処理の結果は、図示せぬ経路を介して表示装置３に出力される。
【０２６４】
PIDフィルタ１０１は、ディスクドライブ５２、またはローカルストレージ５４から供給されたTSがMain TSであるかSub TSであるかを、TSを構成するパケットのPIDやストリームのIDなどに基づいて識別する。PIDフィルタ１０１は、Main TSをバッファ１０２に出力し、Sub TSをバッファ１０３に出力する。
【０２６５】
PIDフィルタ１０４は、バッファ１０２に記憶されたMain TSのパケットを順次読み出し、PIDに基づいて振り分ける。
【０２６６】
例えば、PIDフィルタ１０４は、Main TSに含まれているBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２６７】
また、PIDフィルタ１０４は、Main TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
【０２６８】
PIDフィルタ１０４は、Main TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
【０２６９】
図１５を参照して説明したように、Base view video、Dependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがMain TSに多重化されていることがある。
【０２７０】
PIDフィルタ１０５は、バッファ１０３に記憶されたSub TSのパケットを順次読み出し、PIDに基づいて振り分ける。
【０２７１】
例えば、PIDフィルタ１０５は、Sub TSに含まれているDependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２７２】
また、PIDフィルタ１０５は、Sub TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
【０２７３】
PIDフィルタ１０５は、Sub TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
【０２７４】
図１７を参照して説明したように、Dependent view videoストリームがSub TSに含まれていることがある。また、図１６を参照して説明したように、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがSub TSに多重化されていることがある。
【０２７５】
スイッチ１０７は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent view videoストリームを構成するパケットをD videoバッファ１０８に出力する。
【０２７６】
スイッチ１０９は、B videoバッファ１０６に記憶されたBase view videoのパケットと、D videoバッファ１０８に記憶されたDependent view videoのパケットを、デコードのタイミングを規定する時刻情報に従って順次読み出す。Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには例えば同じ時刻情報が設定されている。
【０２７７】
スイッチ１０９は、B videoバッファ１０６、またはD videoバッファ１０８から読み出したパケットをビデオデコーダ１１０に出力する。
【０２７８】
ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはDependent view videoのデータをスイッチ１１１に出力する。
【０２７９】
スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０２８０】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８１】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８２】
スイッチ１１４は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase IGストリームを構成するパケットをB IGバッファ１１５に出力する。
【０２８３】
B IGデコーダ１１６は、B IGバッファ１１５に記憶されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
【０２８４】
B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８５】
スイッチ１１８は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent IGストリームを構成するパケットをD IGバッファ１１９に出力する。
【０２８６】
D IGデコーダ１２０は、D IGバッファ１１９に記憶されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。
【０２８７】
D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８８】
スイッチ１２２は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase PGストリームを構成するパケットをB PGバッファ１２３に出力する。
【０２８９】
B PGデコーダ１２４は、B PGバッファ１２３に記憶されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
【０２９０】
B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２９１】
スイッチ１２６は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent PGストリームを構成するパケットをD PGバッファ１２７に出力する。
【０２９２】
D PGデコーダ１２８は、D PGバッファ１２７に記憶されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。
【０２９３】
D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２９４】
合成部１３０は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンと、B IGプレーン生成部１１７から供給されたBase IGのプレーンと、B PGプレーン生成部１２５から供給されたBase PGのプレーンを所定の順番で重ねることによって合成し、Base viewのプレーンを生成する。
【０２９５】
また、合成部１３０は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンと、D IGプレーン生成部１２１から供給されたDependent IGのプレーンと、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを所定の順番で重ねることによって合成し、Dependent viewのプレーンを生成する。
【０２９６】
合成部１３０は、Base viewのプレーンのデータとDependent viewのプレーンのデータを出力する。合成部１３０から出力されたビデオデータは表示装置３に出力され、Base viewのプレーンとDependent viewのプレーンが交互に表示されることによって3D表示が行われる。
【０２９７】
図２５は、ビデオストリームの処理を行う構成を示す図である。
【０２９８】
図２５において、図２４に示す構成と同じ構成には同じ符号を付してある。図２４には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB(Decoded Picture Buffer)１５１が設けられる。重複する説明については適宜省略する。
【０２９９】
また、図２５の例においては、L videoプレーン生成部１６１が図２４のB videoプレーン生成部１１２に替えて設けられ、R videoプレーン生成部１６２が図２４のD videoプレーン生成部１１３に替えて設けられている。
【０３００】
L videoプレーン生成部１６１は、L view videoのプレーンを生成する。また、R videoプレーン生成部１６２は、R view videoのプレーンを生成する。
【０３０１】
この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。
【０３０２】
すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータが、それぞれ、L viewとR viewのいずれのビデオデータであるのかを識別する。
【０３０３】
L viewとR viewの識別には、図２０と図２２を参照して説明したview_typeが用いられる。例えば、コントローラ５１は、PlayListファイルに記述されているview_typeをスイッチ１１１に出力する。
【０３０４】
view_typeの値が0である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。上述したように、view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。例えば、Base view videoのパケットにはPID=0が割り当てられ、Dependent view videoのパケットには0以外のPIDが割り当てられている。
【０３０５】
この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
【０３０６】
一方、view_typeの値が1である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０３０７】
この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
【０３０８】
L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。L videoプレーン生成部１６１から出力されたL view videoのプレーンは、他のL viewのデータが合成部１３０において適宜合成された後、Ｌ画像のデータとして表示装置３に出力される。
【０３０９】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。R videoプレーン生成部１６２から出力されたR view videoのプレーンは、他のR viewのデータが合成部１３０において適宜合成された後、Ｒ画像のデータとして表示装置３に出力される。
【０３１０】
H.264 AVC/MVCプロファイル規格でエンコードされたBase view video、Dependent view videoのエレメンタリストリーム内には、L viewであるのか、またはR viewであるのかを表す情報（フィールド）が存在しない。
【０３１１】
従って、view_typeをPlayListファイルに設定しておくことにより、記録装置は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを再生装置１に識別させることが可能になる。
【０３１２】
再生装置１は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを識別し、識別結果に応じて出力先を切り替えることができる。
【０３１３】
IG、PGのプレーンについてもそれぞれL viewとR viewが用意されている場合、ビデオストリームのL viewとR viewを区別できることにより、再生装置１はL view同士、R view同士のプレーンの合成を容易に行うことができる。
【０３１４】
HDMIケーブルを介してビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが要求される可能性がある。再生装置１はその要求に対応することが可能になる。
【０３１５】
DPB１５１に記憶されたBase view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの識別が、PIDではなく、view_idに基づいて行われるようにしてもよい。
【０３１６】
H.264 AVC/MVCプロファイル規格でのエンコード時、エンコード結果のストリームを構成するAccess Unitにはview_idが設定される。view_idにより、各Access Unitがどのview componentのユニットであるのかが識別可能になっている。
【０３１７】
図２６は、Access Unitの例を示す図である。
【０３１８】
図２６のAccess Unit＃１はBase view videoのデータを含むユニットである。Dependent Unit＃２はDependent view videoのデータを含むユニットである。Access Unit（Dependent viewの場合、Dependent Unit）はピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。
【０３１９】
H.264 AVC/MVCプロファイル規格でのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなユニットに格納される。H.264 AVC/MVCプロファイル規格でのエンコード時、Dependent Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。
【０３２０】
図２６の例の場合、Dependent Unit＃２については、そのユニットに格納されるview componentがDependent view videoであることをview_idから識別することが可能になる。
【０３２１】
一方、図２６に示すように、Access Unit＃１に格納されたview componentであるBase view videoにはMVCヘッダが付加されていない。
【０３２２】
上述したようにBase view videoストリームは2D再生にも用いられるデータである。従って、それとの互換性を確保するために、Base view videoにはエンコード時にMVCヘッダが付加されない。あるいは、一度付加されたMVCヘッダが除去される。
【０３２３】
再生装置１には、MVCヘッダが付加されていないview componentについては、そのview_idが0であり、view componentをBase view videoであるとして認識するように定義（設定）されている。Dependent view videoには、0以外の値がview_idとしてエンコード時に設定される。
【０３２４】
これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
【０３２５】
図２５のスイッチ１１１において、Base view videoのパケットをデコードして得られたデータとDependent view videoのパケットをデコードして得られたデータの識別が、このようなview_idに基づいて行われるようにしてもよい。
【０３２６】
［記録装置の構成例］
図２７は、ソフト製作処理部２０１の構成例を示すブロック図である。
【０３２７】
ビデオエンコーダ２１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ２１１は、複数の映像データをH.264 AVC/MVCプロファイル規格に従ってエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ２１２に出力する。
【０３２８】
オーディオエンコーダ２１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ２１４に出力する。オーディオエンコーダ２１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
【０３２９】
データエンコーダ２１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ２１６に出力する。
【０３３０】
例えば、データエンコーダ２１５は、Dependent view videoストリームを含むSub TSに対応するClip Informationファイルのapplication_typeの値として8を設定する。application_type=8は、Dependent view videoストリームを用いて処理を行うアプリケーションが3D再生を行うアプリケーションであることを表す。
【０３３１】
また、データエンコーダ２１５は、Dependent view videoストリームがBase view videoストリームと同じTSに多重化されているか否かと記録場所に応じたSubPath_typeをPlayListに設定する。Dependent view videoストリームの記録場所は、光ディスク２、またはローカルストレージ５４である。
【０３３２】
さらに、データエンコーダ２１５は、再生装置１側において、Base viewのストリームのIDに基づいてDependent viewのストリームを計算するようになされている場合、その計算に用いられる値xをSTN_table()などの所定の位置に設定する。
【０３３３】
データエンコーダ２１５は、ビデオエンコーダ２１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。
【０３３４】
多重化部２１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部２１８に出力する。
【０３３５】
誤り訂正符号化部２１８は、エラー訂正用のコードを多重化部２１７により多重化されたデータに付加する。
【０３３６】
変調部２１９は、誤り訂正符号化部２１８から供給されたデータに対して変調を施し、出力する。変調部２１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。
【０３３７】
このような構成を有するソフト製作処理部２０１が記録装置内に設けられる。
【０３３８】
図２８は、ソフト製作処理部２０１を含む各構成の例を示す図である。
【０３３９】
図２６に示す構成の一部が記録装置内に設けられることもある。
【０３４０】
ソフト製作処理部２０１により生成された記録信号はプリマスタリング処理部２３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部２３３に供給される。
【０３４１】
記録用原盤製作部２３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
【０３４２】
原盤記録部２３３において、プリマスタリング処理部２３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
【０３４３】
金属原盤製作部２３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
【０３４４】
成形処理部２３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
【０３４５】
成膜処理部２３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
【０３４６】
後加工処理部２３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。
【０３４７】
［view_typeの位置］
以上においては、図２０を参照して説明したように、Base view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかを表すview_typeがPlayListに記述されるものとしたが、他の位置に記述されるようにしてもよい。
【０３４８】
例えば、Base view videoストリームとDependent view videoストリームが、同じTS、またはそれぞれ異なるTSに多重化されて、放送波やネットワークを介して伝送されることも考えられる。この場合、view_typeは、例えば伝送制御情報であるPSI中や、Base view videoストリームまたはDependent view videoストリーム（エレメンタリストリーム）中に記述される。
【０３４９】
図２９は、PSI(Program Specific Information)に含まれるPMT(Program Map Table)にview_typeを記述する場合の例を示す図である。
【０３５０】
図２９に示すように、MVC用のdescriptorとしてMVC_video_stream_descriptor()を新たに定義し、MVC_video_stream_descriptor()の中にview_typeが記述されるようにしてもよい。なお、descriptor_tagの値として例えば65が割り当てられる。
【０３５１】
この場合、ソフト製作処理部２０１のデータエンコーダ２１５は、view_typeを記述したPMTを生成し、出力する。データエンコーダ２１５から出力されたPMTは、バッファ２１６を介して多重化部２１７に供給され、Base view video、Dependent view videoストリームとともに多重化される。多重化されることによって得られたTSは、放送波を介して、またはネットワークを介して送信される。
【０３５２】
TSを受信した再生装置１においては、PMTに記述されたview_typeの値に基づいて、TSに多重化されているBase view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが判断され、復号結果のデータの出力先を切り替えるなどの、図２５を参照して説明した処理が行われることになる。
【０３５３】
PMTの中ではなく、SIT(Selection Information Table)などの他の位置に記述されるようにしてもよい。
【０３５４】
図３０は、エレメンタリストリーム中にview_typeを記述する場合の例を示す図である。
【０３５５】
図３０に示すように、SEI中のMVC_video_stream_info()の中にview_typeが記述されるようにすることも可能である。SEIは、Base view videoストリームとDependent view videoストリームを構成する各ピクチャのデータに付加される付加情報である。view_typeを含むSEIは、Base view videoストリームとDependent view videoストリームのうちの少なくともいずれかのストリームの各ピクチャに付加される。
【０３５６】
図３１は、Access Unitの構成を示す図である。
【０３５７】
図３１に示すように、Base view videoストリームの１ピクチャのデータを含むBase view videoのAccess Unitと、Dependent view videoストリームの１ピクチャのデータを含むDependent view videoのDependent Unitは同じ構成を有する。１つのユニットは、各ユニットの境界を示すデリミタ、SPS、PPS、SEI、ピクチャデータから構成される。例えばDependent view videoのDependent Unitのピクチャデータには、図２６を参照して説明したMVCヘッダが付加される。
【０３５８】
この場合、ソフト製作処理部２０１のデータエンコーダ２１５は、view_typeを記述したSEIを生成し、図示せぬ経路を介してビデオエンコーダ２１１に出力する。データエンコーダ２１５から出力されたSEIは、ビデオエンコーダ２１１において、H.264 AVC/MVCプロファイル規格に従ってＬ画像データとＲ画像データを符号化することによって得られたBase view video、Dependent view videoの各ピクチャのデータに図３１に示すようにして付加される。
【０３５９】
view_typeを記述したSEIが付加されたピクチャのデータからなるBase view videoストリーム、Dependent view videoストリームは、多重化された後、放送波を介して、またはネットワークを介して送信されたり、記録媒体に記録されたりする。
【０３６０】
SEIを読み出した再生装置１においては、SEIに記述されたview_typeの値に基づいて、Base view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが判断され、復号結果のデータの出力先を切り替えるなどの、図２５を参照して説明した処理が行われることになる。
【０３６１】
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【０３６２】
図３２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０３６３】
CPU(Central Processing Unit)３０１、ROM(Read Only Memory)３０２、RAM(Random Access Memory)３０３は、バス３０４により相互に接続されている。
【０３６４】
バス３０４には、さらに、入出力インタフェース３０５が接続されている。入出力インタフェース３０５には、キーボード、マウスなどよりなる入力部３０６、ディスプレイ、スピーカなどよりなる出力部３０７が接続される。また、バス３０４には、ハードディスクや不揮発性のメモリなどよりなる記憶部３０８、ネットワークインタフェースなどよりなる通信部３０９、リムーバブルメディア３１１を駆動するドライブ３１０が接続される。
【０３６５】
以上のように構成されるコンピュータでは、CPU３０１が、例えば、記憶部３０８に記憶されているプログラムを入出力インタフェース３０５及びバス３０４を介してRAM３０３にロードして実行することにより、上述した一連の処理が行われる。
【０３６６】
CPU３０１が実行するプログラムは、例えばリムーバブルメディア３１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部３０８にインストールされる。
【０３６７】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０３６８】
本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０３６９】
１  再生装置，  ２  光ディスク，  ３  表示装置，  １１  MVCエンコーダ，  ２１  H.264/AVCエンコーダ，  ２２  H.264/AVCデコーダ，  ２３  Depth算出部，  ２４  Dependent view videoエンコーダ，  ２５  マルチプレクサ，  ５１  コントローラ，  ５２  ディスクドライブ，  ５３  メモリ，  ５４  ローカルストレージ，  ５５  インターネットインタフェース，  ５６  デコーダ部，  ５７  操作入力部
【図１】
2010263613.tif 000003
【図２】
2010263613.tif 000004
【図３】
2010263613.tif 000005
【図４】
2010263613.tif 000006
【図５】
2010263613.tif 000007
【図６】
2010263613.tif 000008
【図７】
2010263613.tif 000009
【図８】
2010263613.tif 000010
【図９】
2010263613.tif 000011
【図１０】
2010263613.tif 000012
【図１１】
2010263613.tif 000013
【図１２】
2010263613.tif 000014
【図１３】
2010263613.tif 000015
【図１４】
2010263613.tif 000016
【図１５】
2010263613.tif 000017
【図１６】
2010263613.tif 000018
【図１７】
2010263613.tif 000019
【図１８】
2010263613.tif 000020
【図１９】
2010263613.tif 000021
【図２０】
2010263613.tif 000022
【図２１】
2010263613.tif 000023
【図２２】
2010263613.tif 000024
【図２３】
2010263613.tif 000025
【図２４】
2010263613.tif 000026
【図２５】
2010263613.tif 000027
【図２６】
2010263613.tif 000028
【図２７】
2010263613.tif 000029
【図２８】
2010263613.tif 000030
【図２９】
2010263613.tif 000031
【図３０】
2010263613.tif 000032
【図３１】
2010263613.tif 000033
【図３２】
2010263613.tif 000034