記録方法
【課題】複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにする。
【解決手段】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規格に対応した再生装置に適用することができる。
【解決手段】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規格に対応した再生装置に適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、記録媒体、および記録方法に関し、特に、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにした記録媒体、および記録方法に関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray(R))-ROM(Read Only Memory)等のBlu-Ray(R) Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−０９５２４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
従来のBDの規格で用いられている、画像データの管理情報をそのまま用いた場合であっても、ステレオ画像のデータを再生することはできない。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の記録媒体は、左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化して得られた基本ストリームおよび拡張ストリームと、前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルとが記録された記録媒体である。
【００１３】
本技術の他の側面の記録方法は、左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させるステップを含む。
【発明の効果】
【００１４】
本技術によれば、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができる。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】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エンコーダ， ２５ マルチプレクサ， ５１ コントローラ， ５２ ディスクドライブ， ５３ メモリ， ５４ ローカルストレージ， ５５ インターネットインタフェース， ５６ デコーダ部， ５７ 操作入力部
【技術分野】
【０００１】
本技術は、記録媒体、および記録方法に関し、特に、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにした記録媒体、および記録方法に関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray(R))-ROM(Read Only Memory)等のBlu-Ray(R) Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−０９５２４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
従来のBDの規格で用いられている、画像データの管理情報をそのまま用いた場合であっても、ステレオ画像のデータを再生することはできない。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の記録媒体は、左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化して得られた基本ストリームおよび拡張ストリームと、前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルとが記録された記録媒体である。
【００１３】
本技術の他の側面の記録方法は、左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させるステップを含む。
【発明の効果】
【００１４】
本技術によれば、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができる。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】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エンコーダ， ２５ マルチプレクサ， ５１ コントローラ， ５２ ディスクドライブ， ５３ メモリ， ５４ ローカルストレージ， ５５ インターネットインタフェース， ５６ デコーダ部， ５７ 操作入力部
【特許請求の範囲】
【請求項１】
左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化して得られた基本ストリームおよび拡張ストリームと、
前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルと
が記録された記録媒体。
【請求項２】
左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、
前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、
生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させる
ステップを含む記録方法。
【請求項１】
左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化して得られた基本ストリームおよび拡張ストリームと、
前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルと
が記録された記録媒体。
【請求項２】
左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、
前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報が、前記基本ストリームを参照するメイン再生パスを構成するPlayItemの情報を含むフィールドとは異なるフィールドに記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、
生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させる
ステップを含む記録方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【公開番号】特開２０１２−１３００４５（Ｐ２０１２−１３００４５Ａ）
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１２−１９８２５（Ｐ２０１２−１９８２５）
【出願日】平成２４年２月１日（２０１２．２．１）
【分割の表示】特願２０１０−６５１１０（Ｐ２０１０−６５１１０）の分割
【原出願日】平成２２年３月１９日（２０１０．３．１９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２４年２月１日（２０１２．２．１）
【分割の表示】特願２０１０−６５１１０（Ｐ２０１０−６５１１０）の分割
【原出願日】平成２２年３月１９日（２０１０．３．１９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]