記録方法
【課題】H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができるようにする。
【解決手段】Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。0がview_idとして設定されていると認識されたAccess Unit＃１がデコードされ、次に、Yがview_idとして設定されているAccess Unit＃２がデコードされる。本発明は、BD-ROM規格に対応した再生装置に適用することができる。
【解決手段】Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。0がview_idとして設定されていると認識されたAccess Unit＃１がデコードされ、次に、Yがview_idとして設定されているAccess Unit＃２がデコードされる。本発明は、BD-ROM規格に対応した再生装置に適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、記録媒体、および記録方法に関し、特に、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができるようにした記録媒体、および記録方法に関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray（登録商標）)-ROM(Read Only Memory)等のBlu-Ray（登録商標） Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−３４８３１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
ステレオ画像の画像データは、左画像のデータのストリームと右画像のデータのストリームの２本のデータストリームからなる。仮に、２本のデータストリームをそのままBDに記録しただけでは、既に普及しているBDプレーヤで再生できないおそれがある。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の記録媒体は、複数の映像データを対象としてH.264 AVC/MVCで符号化を行うことによって得られたviewのIDを含むMVCヘッダが付加されていないデータからなり、前記IDとして前記MVCヘッダに設定されている値が小さいviewのデータから順に処理を行う再生装置を、前記IDとして０の値が前記MVCヘッダに設定されているデータとして扱い、Dependent view videoのデータより先に復号を行うように機能させるBase view videoのストリームと、前記符号化を行うことによって得られた、Dependent viewのデータであることを表す１以上の値の前記IDを含む前記MVCヘッダが付加されたデータからなり、前記再生装置を、前記Base view videoのストリームの後に復号を行うように機能させる前記Dependent view videoのストリームとが記録された記録媒体である。
【００１３】
本技術の一側面の記録方法は、複数の映像データをH.264 AVC/MVCで符号化し、符号化を行うことによって得られた、viewのIDを含むMVCヘッダが付加されていないデータからなるBase view videoのストリームと、Dependent viewのデータであることを表す前記IDを含む前記MVCヘッダが付加されたデータからなるDependent view videoのストリームを記録媒体に記録するステップを含む。
【発明の効果】
【００１４】
本技術によれば、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができる。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】MVCエンコーダの構成例を示すブロック図である。
【図４】参照画像の例を示す図である。
【図５】TSの構成例を示す図である。
【図６】TSの他の構成例を示す図である。
【図７】TSのさらに他の構成例を示す図である。
【図８】AVストリームの管理の例を示す図である。
【図９】Main PathとSub Pathの構造を示す図である。
【図１０】光ディスクに記録されるファイルの管理構造の例を示す図である。
【図１１】PlayListファイルのシンタクスを示す図である。
【図１２】図１１にあるreserved_for_future_useの使い方の例を示す図である。
【図１３】3D_PL_typeの値の意味を示す図である。
【図１４】view_typeの値の意味を示す図である。
【図１５】図１１のPlayList()のシンタクスを示す図である。
【図１６】図１５のSubPath()のシンタクスを示す図である。
【図１７】図１６のSubPlayItem(i)のシンタクスを示す図である。
【図１８】図１５のPlayItem()のシンタクスを示す図である。
【図１９】図１８のSTN_table()のシンタクスを示す図である。
【図２０】再生装置の構成例を示すブロック図である。
【図２１】図２０のデコーダ部の構成例を示す図である。
【図２２】ビデオストリームの処理を行う構成を示す図である。
【図２３】ビデオストリームの処理を行う構成を示す図である。
【図２４】ビデオストリームの処理を行う他の構成を示す図である。
【図２５】Access Unitの例を示す図である。
【図２６】ビデオストリームの処理を行うさらに他の構成を示す図である。
【図２７】合成部と、その前段の構成を示す図である。
【図２８】合成部と、その前段の構成を示す他の図である。
【図２９】ソフト製作処理部の構成例を示すブロック図である。
【図３０】ソフト製作処理部を含む各構成の例を示す図である。
【図３１】記録装置に設けられる3D video TS生成部の構成例を示す図である。
【図３２】記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【図３３】記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【図３４】Access Unitをデコードする再生装置側の構成を示す図である。
【図３５】デコード処理を示す図である。
【図３６】Close GOP構造を示す図である。
【図３７】Open GOP構造を示す図である。
【図３８】GOP内の最大フレーム・フィールド数を示す図である。
【図３９】Close GOP構造を示す図である。
【図４０】Open GOP構造を示す図である。
【図４１】EP_mapに設定されたデコード開始位置の例を示す図である。
【図４２】Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【図４３】ピクチャサーチの概念を示す図である。
【図４４】光ディスク上に記録されたAVストリームの構造を示す図である。
【図４５】Clip AVストリームの例を示す図である。
【図４６】図４５のClip AVストリームに対応したEP_mapを概念的に示す図である。
【図４７】SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【図４８】コンピュータのハードウェアの構成例を示すブロック図である。
【発明を実施するための形態】
【００１６】
＜第１の実施の形態＞
［再生システムの構成例］
図１は、本技術を適用した再生装置１を含む再生システムの構成例を示す図である。
【００１７】
図１に示すように、この再生システムは、再生装置１と表示装置３が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と同様にして光ディスク２に記録され、再生される。
【００４８】
［TSの構成例］
図５は、TSの構成例を示す図である。
【００４９】
図５の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 viewとDependent viewのそれぞれのストリームが用意されている。
【００５２】
それぞれのストリームをデコードして得られた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画像のグラフィックスのストリームとなる。
【００５５】
図６は、TSの他の構成例を示す図である。
【００５６】
図６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
【００５７】
一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００５８】
このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
【００５９】
図７は、TSのさらに他の構成例を示す図である。
【００６０】
図７ＡのMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００６１】
一方、Sub TSにはDependent view videoストリームが含まれている。
【００６２】
このように、Dependent view videoストリームがBase view videoストリームとは別のTSに含まれていることもある。
【００６３】
図７ＢのMain TSにはBase view video、Primary audio、PG、IGのそれぞれのストリームが多重化されている。一方、Sub TSにはDependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００６４】
Main TSに含まれるPG、IGは2D再生用のストリームである。Sub TSに含まれているストリームは3D再生用のストリームである。
【００６５】
このように、PGのストリームとIGのストリームを2D再生と3D再生において共有しないようにすることも可能である。
【００６６】
以上のように、Base view videoストリームとDependent view videoストリームが別々のMPEG2 TSに含まれることがある。Base view videoストリームとDependent view videoストリームを別々のMPEG2 TSに含めて記録する場合のメリットについて説明する。
【００６７】
例えば１本のMPEG2 TSとして多重化できるビットレートが制限されている場合を考える。この場合において、Base view videoストリームとDependent view videoストリームの両方を１本のMPEG2 TSに含めたときには、その制約を満たすために各ストリームのビットレートを下げる必要がある。その結果、画質が落ちてしまうことになる。
【００６８】
それぞれ異なるMPEG2 TSに含めることによって、ビットレートを下げる必要がなくなり、画質を落とさずに済むことになる。
【００６９】
［アプリケーションフォーマット］
図８は、再生装置１による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ファイルは、図１０のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
【０１１２】
図１１の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の後には、１６０bitのreserved_for_future_useが含まれる。
【０１１８】
AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
【０１１９】
PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
【０１２０】
PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。
【０１２１】
ExtensionData()には、プライベートデータが挿入できるようになっている。
【０１２２】
図１２は、PlayListファイルの記述の具体例を示す図である。
【０１２３】
図１２に示すように、PlayListファイルには２bitの3D_PL_typeと１bitのview_typeが記述される。
【０１２４】
3D_PL_typeは、PlayListの種類を表す。
【０１２５】
view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。
【０１２６】
図１３は、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情報として、Base view videoストリームとDependent view videoストリームの光ディスク２からの読み出しに関する情報が登録される。
【０１３１】
図１４は、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の信号を区別して出力することが可能になる。
【０１３７】
図１５は、図１１の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の後には、１５ビットの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（）が参照される。
【０１５０】
図１７は、図１６の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はマルチClipの登録の有無を示すフラグである。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ストリームがこのvideo_stream_idにより特定される。
【０１７８】
Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
【０１７９】
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が与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化した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ストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
【０１８４】
Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
【０１８５】
［再生装置１の構成例］
図２０は、再生装置１の構成例を示すブロック図である。
【０１８６】
コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
【０１８７】
例えば、コントローラ５１は、ディスクドライブ５２を制御し、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表示が行われる。
【０２３０】
［T-STD(Transport stream-System. Target Decoder)の第１の例］
ここで、図２１に示す構成のうちの、デコーダと、その周辺の構成について説明する。
【０２３１】
図２２は、ビデオストリームの処理を行う構成を示す図である。
【０２３２】
図２２において、図２１に示す構成と同じ構成には同じ符号を付してある。図２２においては、PIDフィルタ１０４、B videoバッファ１０６、スイッチ１０７、D videoバッファ１０８、スイッチ１０９、ビデオデコーダ１１０、およびDPB(Decoded Picture Buffer)１５１が示されている。図２１には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB１５１が設けられる。
【０２３３】
PIDフィルタ１０４は、Main TSに含まれるBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２３４】
例えば、Base view videoストリームを構成するパケットには、PID=0がPIDの固定値として割り当てられている。また、Dependent view videoストリームを構成するパケットには、0以外の固定の値がPIDとして割り当てられている。
【０２３５】
PIDフィルタ１０４は、PID=0がヘッダに記述されているパケットをB videoバッファ１０６に出力し、0以外のPIDがヘッダに記述されているパケットをスイッチ１０７に出力する。
【０２３６】
B videoバッファ１０６に出力されたパケットは、TB(Transport Buffer)1、MB(Multiplexing Buffer)1を介してVSB1に記憶される。VSB1には、Base view videoのエレメンタリストリームのデータが記憶される。
【０２３７】
スイッチ１０７には、PIDフィルタ１０４から出力されたパケットだけでなく、図２１のPIDフィルタ１０５においてSub TSから抽出されたDependent view videoストリームを構成するパケットも供給される。
【０２３８】
スイッチ１０７は、PIDフィルタ１０４からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２３９】
また、スイッチ１０７は、PIDフィルタ１０５からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２４０】
D videoバッファ１０８に出力されたパケットは、TB2、MB2を介してVSB2に記憶される。VSB2には、Dependent view videoのエレメンタリストリームのデータが記憶される。
【０２４１】
スイッチ１０９は、B videoバッファ１０６のVSB1に記憶されたBase view videoのパケットと、D videoバッファ１０８のVSB2に記憶されたDependent view videoのパケットを順次読み出し、ビデオデコーダ１１０に出力する。
【０２４２】
例えば、スイッチ１０９は、ある時刻のBase view videoのパケットを出力した直後にそれと同じ時刻のDependent view videoのパケットを出力するといったように、同じ時刻のBase view videoのパケットとDependent view videoのパケットを続けてビデオデコーダ１１０に出力する。
【０２４３】
Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには、そのエンコード時に、PCR(Program Clock Reference)同期が確保された同じ時刻情報が設定されている。Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合であっても、対応するピクチャのデータを格納したパケットには同じ時刻情報が設定される。
【０２４４】
時刻情報はDTS(Decoding Time Stamp)、PTS(Presentation Time Stamp)であり、各PES(Packetized Elementary Stream)パケットに設定される。
【０２４５】
すなわち、それぞれのストリームのピクチャをエンコード順／デコード順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャが、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じDTSが設定されている。
【０２４６】
また、それぞれのストリームのピクチャを表示順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャも、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じPTSが設定されている。
【０２４７】
後述するようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造が同じ構造である場合、デコード順で対応するピクチャは、表示順でも対応するピクチャになる。
【０２４８】
パケットの転送がシリアルで行われる場合、あるタイミングでB videoバッファ１０６のVSB1から読み出されたパケットのDTS1と、直後のタイミングでD videoバッファ１０８のVSB2から読み出されたパケットのDTS2は、図２２に示すように同じ時刻を表すものになる。
【０２４９】
スイッチ１０９は、B videoバッファ１０６のVSB1から読み出したBase view videoのパケット、または、D videoバッファ１０８のVSB2から読み出したDependent view videoのパケットをビデオデコーダ１１０に出力する。
【０２５０】
ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットを順次デコードし、デコードして得られたBase view videoのピクチャのデータ、または、Dependent view videoのピクチャのデータをDPB１５１に記憶させる。
【０２５１】
DPB１５１に記憶されたデコード済みのピクチャのデータは、所定のタイミングでスイッチ１１１により読み出される。また、DPB１５１に記憶されたデコード済みのピクチャのデータは、他のピクチャの予測にビデオデコーダ１１０により用いられる。
【０２５２】
データの転送がシリアルで行われる場合、あるタイミングで出力されたBase view videoのピクチャのデータのPTSと、直後のタイミングで出力されたDependent view videoのピクチャのデータのPTSは、同じ時刻を表すものになる。
【０２５３】
Base view videoストリームとDependent view videoストリームは図５等を参照して説明したように１本のTSに多重化される場合があるし、図７を参照して説明したようにそれぞれ異なるTSに含まれることがある。
【０２５４】
図２２のデコーダモデルを実装することにより、再生装置１は、Base view videoストリームとDependent view videoストリームが１本のTSに多重化されている場合であっても、それぞれ異なるTSに含まれる場合であっても、対応することが可能になる。
【０２５５】
例えば図２３に示すように１本のTSが供給される状況しか想定されていない場合、Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれる場合などには対応することができない。
【０２５６】
また、図２２のデコーダモデルによれば、同じDTSを持つことから、Base view videoストリームとDependent view videoストリームが異なるTSに含まれる場合であっても、正しいタイミングでビデオデコーダ１１０にパケットを供給することができる。
【０２５７】
Base view video用のデコーダとDependent view video用のデコーダをそれぞれ並列に設けるようにしてもよい。この場合、Base view video用のデコーダとDependent view video用のデコーダには、それぞれ、同じ時刻のパケットが同じタイミングで供給される。
【０２５８】
［第２の例］
図２４は、ビデオストリームの処理を行う他の構成を示す図である。
【０２５９】
図２４においては、図２２の構成に加えて、スイッチ１１１、L videoプレーン生成部１６１、およびR videoプレーン生成部１６２が示されている。また、PIDフィルタ１０５もスイッチ１０７の前段に示されている。重複する説明については適宜省略する。
【０２６０】
L videoプレーン生成部１６１は、L view videoのプレーンを生成するものであり、図２１のB videoプレーン生成部１１２に替えて設けられる。
【０２６１】
R videoプレーン生成部１６２は、R view videoのプレーンを生成するものであり、図２１のD videoプレーン生成部１１３に替えて設けられる。
【０２６２】
この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。
【０２６３】
すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
【０２６４】
また、スイッチ１１１は、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のストリームであることを表す。
【０２６７】
この場合、スイッチ１１１は、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のプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２７１】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２７２】
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のデータを含むユニットである。Access Unit＃２はDependent view videoのデータを含むユニットである。Access Unitはピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。
【０２８１】
H.264 AVC/MVCでのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなAccess Unitに格納される。H.264 AVC/MVCでのエンコード時、Access Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。
【０２８２】
図２５の例の場合、Access Unit＃２については、そのAccess 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に基づいて行われるようにしてもよい。
【０２８８】
［第３の例］
図２６は、ビデオストリームの処理を行うさらに他の構成を示す図である。
【０２８９】
図２６の例においては、図２４のL videoプレーン生成部１６１に替えてB videoプレーン生成部１１２が設けられ、R videoプレーン生成部１６２に替えてD videoプレーン生成部１１３が設けられている。B videoプレーン生成部１１２とD videoプレーン生成部１１３の後段にはスイッチ１７１が設けられている。図２６に示す構成においても、view_typeに基づいてデータの出力先が切り替えられるようになされている。
【０２９０】
スイッチ１１１は、DPB１５１に記憶されたデータのうち、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力する。また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０２９１】
Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータは、上述したようにPID、またはview_idに基づいて識別される。
【０２９２】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０２９３】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０２９４】
スイッチ１７１に対しては、PlayListファイルに記述されているview_typeがコントローラ５１から供給されている。
【０２９５】
view_typeの値が0である場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
【０２９６】
また、この場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０２９７】
一方、view_typeの値が1である場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０２９８】
また、この場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０２９９】
図２６の構成によっても、再生装置１は、L viewとR viewを識別し、識別結果に応じて出力先を切り替えることができる。
【０３００】
［プレーン合成モデルの第１の例］
図２７は、図２１に示す構成のうちの、合成部１３０と、その前段の構成を示す図である。
【０３０１】
図２７においても、図２１に示す構成と同じ構成には同じ符号を付してある。
【０３０２】
スイッチ１８１には、Main TS、またはSub TSに含まれるIGストリームを構成するパケットが入力される。スイッチ１８１に入力されるIGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３０３】
スイッチ１８２には、Main TS、またはSub TSに含まれるPGストリームを構成するパケットが入力される。スイッチ１８２に入力されるPGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３０４】
図５等を参照して説明したように、IG、PGについても、3D表示を行うためのBase viewのストリームとDependent viewのストリームが用意されている。
【０３０５】
Base viewのIGがBase view videoと合成して表示され、Dependent viewのIGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、ボタンやアイコンなどを3Dで見ることになる。
【０３０６】
また、Base viewのPGがBase view videoと合成して表示され、Dependent viewのPGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、字幕のテキストなどを3Dで見ることになる。
【０３０７】
スイッチ１８１は、Base IGストリームを構成するパケットをB IGデコーダ１１６に出力し、Dependent IGストリームを構成するパケットをD IGデコーダ１２０に出力する。スイッチ１８１は、図２１のスイッチ１１４とスイッチ１１８の機能を有する。図２７においては、各バッファの図示を省略している。
【０３０８】
B IGデコーダ１１６は、スイッチ１８１から供給されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
【０３０９】
B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１０】
D IGデコーダ１２０は、スイッチ１８１から供給されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。Base IGストリームとDependent IGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３１１】
D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１２】
スイッチ１８２は、Base PGストリームを構成するパケットをB PGデコーダ１２４に出力し、Dependent PGストリームを構成するパケットをD PGデコーダ１２８に出力する。スイッチ１８２は、図２１のスイッチ１２２とスイッチ１２６の機能を有する。
【０３１３】
B PGデコーダ１２４は、スイッチ１８２から供給されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
【０３１４】
B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１５】
D PGデコーダ１２８は、スイッチ１８２から供給されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。Base PGストリームとDependent PGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３１６】
D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１７】
ビデオデコーダ１１０は、スイッチ１０９（図２２等）から供給されたパケットを順次デコードし、デコードして得られた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のプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３２１】
合成部１３０は、加算部１９１乃至１９４、およびスイッチ１９５から構成される。
【０３２２】
加算部１９１は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９３に出力する。D PGプレーン生成部１２９から加算部１９１に供給されるDependent PGのプレーンには、色情報の変換処理（CLUT(Color Look Up Table)処理）が施される。
【０３２３】
加算部１９２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンを、B videoプレーン生成部１１２から供給されたBase view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９４に出力する。B PGプレーン生成部１２５から加算部１９２に供給されるBase PGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３２４】
加算部１９３は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンを、加算部１９１による合成結果の上に重ねるようにして合成し、合成結果をDependent viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９３に供給されるDependent IGのプレーンには、色情報の変換処理が施される。
【０３２５】
加算部１９４は、B IGプレーン生成部１１７から供給されたBase IGのプレーンを、加算部１９２による合成結果の上に重ねるようにして合成し、合成結果をBase viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９４に供給されるBase IGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３２６】
このようにして生成されたBase viewのプレーンとDependent viewのプレーンに基づいて表示される画像は、ボタンやアイコンが前面に見え、その下（奥行き方向）に字幕のテキストが見え、その下にビデオが見えるような画像になる。
【０３２７】
スイッチ１９５は、view_typeの値が0である場合、Base viewのプレーンをL viewのプレーンとして出力し、Dependent viewのプレーンをR viewのプレーンとして出力する。スイッチ１９５にはコントローラ５１からview_typeが供給される。
【０３２８】
また、スイッチ１９５は、view_typeの値が1である場合、Base viewのプレーンをR viewのプレーンとして出力し、Dependent viewのプレーンをL viewのプレーンとして出力する。供給されたプレーンのうちのどのプレーンがBase viewのプレーンであるのかDependent viewのプレーンであるのかは、PIDやview_idに基づいて識別される。
【０３２９】
このように、再生装置１においては、Base viewのプレーン同士、Dependent viewのプレーン同士、video、IG、PGの各プレーンの合成が行われる。
【０３３０】
video、IG、PGの全てのプレーンの合成が終わった段階で、Base viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３３１】
また、video、IG、PGの全てのプレーンの合成が終わった段階で、Dependent viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３３２】
［第２の例］
図２８は、合成部１３０と、その前段の構成を示す図である。
【０３３３】
図２８に示す構成のうち、図２７に示す構成と同じ構成には同じ符号を付してある。図２８においては、合成部１３０の構成が図２７の構成と異なる。また、スイッチ１１１の動作が、図２７のスイッチ１１１の動作と異なる。B videoプレーン生成部１１２に替えてL videoプレーン生成部１６１が設けられ、D videoプレーン生成部１１３に替えてR videoプレーン生成部１６２が設けられている。重複する説明については省略する。
【０３３４】
スイッチ１１１と、合成部１３０のスイッチ２０１およびスイッチ２０２に対しては、同じview_typeの値がコントローラ５１から供給される。
【０３３５】
スイッチ１１１は、図２４のスイッチ１１１と同様に、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの出力先をview_typeに基づいて切り替える。
【０３３６】
例えば、view_typeの値が0である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
【０３３７】
一方、view_typeの値が1である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
【０３３８】
L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３３９】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３４０】
合成部１３０は、スイッチ２０１、スイッチ２０２、加算部２０３乃至２０６から構成される。
【０３４１】
スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンとD IGプレーン生成部１２１から供給されたDependent IGのプレーンの出力先をview_typeに基づいて切り替える。
【０３４２】
例えば、view_typeの値が0である場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをL viewのプレーンとして加算部２０６に出力する。
この場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３４３】
一方、view_typeの値が1である場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３４４】
スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンとD PGプレーン生成部１２９から供給されたDependent PGのプレーンの出力先をview_typeに基づいて切り替える。
【０３４５】
例えば、view_typeの値が0である場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをL viewのプレーンとして加算部２０４に出力する。
この場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３４６】
一方、view_typeの値が1である場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３４７】
加算部２０３は、スイッチ２０２から供給されたR viewのPGのプレーンを、R videoプレーン生成部１６２から供給されたR view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０５に出力する。
【０３４８】
加算部２０４は、スイッチ２０２から供給されたL viewのPGのプレーンを、L videoプレーン生成部１６１から供給されたL view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０６に出力する。
【０３４９】
加算部２０５は、スイッチ２０１から供給されたR viewのIGのプレーンを、加算部２０３による合成結果のプレーンの上に重ねるようにして合成し、合成結果をR viewのプレーンとして出力する。
【０３５０】
加算部２０６は、スイッチ２０１から供給されたL viewのIGのプレーンを、加算部２０４による合成結果のプレーンの上に重ねるようにして合成し、合成結果をL viewのプレーンとして出力する。
【０３５１】
このように、再生装置１においては、video、IG、PGのそれぞれのBase viewのプレーンとDependent viewのプレーンについて、他のプレーンとの合成の前に、いずれのプレーンがL viewであるのか、またはR viewであるのかが判断される。
【０３５２】
その判断が行われた後、L viewのプレーン同士、R viewのプレーン同士を合成するように、video、IG、PGの各プレーンの合成が行われる。
【０３５３】
［記録装置の構成例］
図２９は、ソフト製作処理部３０１の構成例を示すブロック図である。
【０３５４】
ビデオエンコーダ３１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ３１１は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ３１２に出力する。
【０３５５】
例えば、ビデオエンコーダ３１１は、エンコード時、同じPCRを基準としてDTS、PTSを設定する。すなわち、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じDTSを設定する。
【０３５６】
また、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じPTSを設定する。
【０３５７】
ビデオエンコーダ３１１は、後述するように、デコード順で対応するBase view videoのピクチャとBase view videoのピクチャに、復号に関する補助的な情報である付加情報としてそれぞれ同じ情報を設定する。
【０３５８】
さらに、ビデオエンコーダ３１１は、後述するように、表示順で対応するBase view videoのピクチャとBase view videoのピクチャに、ピクチャの出力順を表すPOCの値としてそれぞれ同じ値を設定する。
【０３５９】
また、ビデオエンコーダ３１１は、後述するように、Base view videoストリームのGOP構造とDependent view videoストリームのGOP構造とを一致させるようにしてエンコードを行う。
【０３６０】
オーディオエンコーダ３１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ３１４に出力する。オーディオエンコーダ３１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
【０３６１】
データエンコーダ３１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ３１６に出力する。
【０３６２】
データエンコーダ３１５は、ビデオエンコーダ３１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。Base view videoストリームの種類ではなく、Dependent view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表す情報が設定されるようにしてもよい。
【０３６３】
また、データエンコーダ３１５は、後述するEP_mapを、Base view videoストリームのClip Informationファイルと、Dependent view videoストリームのClip Informationファイルにそれぞれ設定する。デコード開始位置としてEP_mapに設定されたBase view videoストリームのピクチャと、Dependent view videoストリームのピクチャは対応するピクチャになる。
【０３６４】
多重化部３１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部３１８に出力する。
【０３６５】
誤り訂正符号化部３１８は、エラー訂正用のコードを多重化部３１７により多重化されたデータに付加する。
【０３６６】
変調部３１９は、誤り訂正符号化部３１８から供給されたデータに対して変調を施し、出力する。変調部３１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。
【０３６７】
このような構成を有するソフト製作処理部３０１が記録装置に設けられる。
【０３６８】
図３０は、ソフト製作処理部３０１を含む構成の例を示す図である。
【０３６９】
図３０に示す構成の一部が記録装置内に設けられることもある。
【０３７０】
ソフト製作処理部３０１により生成された記録信号はプリマスタリング処理部３３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部３３３に供給される。
【０３７１】
記録用原盤製作部３３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
【０３７２】
原盤記録部３３３において、プリマスタリング処理部３３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
【０３７３】
金属原盤製作部３３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
【０３７４】
成形処理部３３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。
あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
【０３７５】
成膜処理部３３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
【０３７６】
後加工処理部３３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。
【０３７７】
＜第２の実施の形態＞
［H.264 AVC/MVC Profileビデオストリームの運用１］
光ディスク２の規格であるBD-ROM規格においては、上述したように、H.264 AVC/MVC Profileを採用することで3D映像の符号化が実現される。
【０３７８】
また、BD-ROM規格においては、Base view videoストリームをL viewの映像のストリームとし、Dependent view videoストリームをR viewの映像のストリームとする。
【０３７９】
Base view videoをH.264 AVC/High Profileビデオストリームとして符号化することにより、過去のプレーヤや2D再生のみに対応したプレーヤにおいても、3D対応のディスクである光ディスク２を再生することが可能になる。すなわち、下位互換性を確保することが可能になる。
【０３８０】
具体的には、Base view videoのストリームのみをH.264 AVC/MVC非対応デコーダにおいてもデコード(再生)可能になる。つまり、Base view videoストリームは、既存の2DのBDプレーヤにおいても必ず再生可能なストリームになる。
【０３８１】
また、Base view videoストリームを、2D再生と3D再生において共通して使用することにより、オーサリング時の負荷の軽減を図ることが可能になる。オーサリング側は、AVストリームに関しては、従来行っていた作業に加えて、Dependent view videoストリームを用意すれば3D対応のディスクを製作することが可能になる。
【０３８２】
図３１は、記録装置に設けられる3D video TS生成部の構成例を示す図である。
【０３８３】
図３１の3D video TS生成部は、MVCエンコーダ４０１、MVCヘッダ除去部４０２、およびマルチプレクサ４０３から構成される。図２を参照して説明したようにして撮影されたL viewの映像＃１のデータと、R viewの映像＃２のデータがMVCエンコーダ４０１に入力される。
【０３８４】
MVCエンコーダ４０１は、図３のMVCエンコーダ１１と同様に、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオデータをBase view videoストリームとして出力する。また、MVCエンコーダ４０１は、L viewの映像＃１のデータとR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、出力する。
【０３８５】
MVCエンコーダ４０１から出力されたBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４０１から出力されたDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０３８６】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０３８７】
Dependent view videoのMVCヘッダに記述されるview_idの値としては、１以上の固定値が用いられる。図３２、図３３の例においても同様である。
【０３８８】
すなわち、MVCエンコーダ４０１は、図３のMVCエンコーダ１１とは異なり、MVCヘッダを付加した形でBase view videoとDependent view videoのそれぞれのストリームを生成し、出力するエンコーダである。図３のMVCエンコーダ１１においては、H.264 AVC/MVCで符号化されたDependent view videoのみにMVCヘッダが付加されている。
【０３８９】
MVCエンコーダ４０１から出力されたBase view videoストリームはMVCヘッダ除去部４０２に供給され、Dependent view videoストリームはマルチプレクサ４０３に供給される。
【０３９０】
MVCヘッダ除去部４０２は、Base view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４０２は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４０３に出力する。
【０３９１】
マルチプレクサ４０３は、MVCヘッダ除去部４０２から供給されたBase view videoストリームと、MVCエンコーダ４０１から供給されたDependent view videoストリームを含むTSを生成し、出力する。図３１の例においては、Base view videoストリームを含むTSとDependent view videoストリームを含むTSがそれぞれ出力されているが、上述したように同じTSに多重化されて出力されることもある。
【０３９２】
このように、実装の仕方によっては、L viewの映像とR viewの映像を入力とし、MVCヘッダ付のBase view videoとDependent view videoのそれぞれのストリームを出力するMVCエンコーダも考えられる。
【０３９３】
なお、図３１に示す構成全体を図３に示すようにMVCエンコーダの中に含めることも可能である。図３２、図３３に示す構成についても同様である。
【０３９４】
図３２は、記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【０３９５】
図３２の3D video TS生成部は、混合処理部４１１、MVCエンコーダ４１２、分離部４１３、MVCヘッダ除去部４１４、およびマルチプレクサ４１５から構成される。L viewの映像＃１のデータと、R viewの映像＃２のデータが混合処理部４１１に入力される。
【０３９６】
混合処理部４１１は、L viewの各ピクチャとR viewの各ピクチャを符号化順に並べる。
Dependent view videoの各ピクチャは対応するBase view videoのピクチャを参照して符号化が行われるから、符号化順に並べた結果は、L viewのピクチャとR viewのピクチャが交互に並ぶものになる。
【０３９７】
混合処理部４１１は、符号化順に並べたL viewのピクチャとR viewのピクチャをMVCエンコーダ４１２に出力する。
【０３９８】
MVCエンコーダ４１２は、混合処理部４１１から供給された各ピクチャをH.264 AVC/MVCで符号化し、符号化して得られたストリームを分離部４１３に出力する。MVCエンコーダ４１２から出力されたストリームには、Base view videoストリームとDependent view videoストリームが多重化されている。
【０３９９】
MVCエンコーダ４１２から出力されたストリームに含まれるBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４１２から出力されたストリームに含まれるDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０４００】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０４０１】
分離部４１３は、MVCエンコーダ４１２から供給されたストリームに多重化されているBase view videoストリームとDependent view videoストリームを分離し、出力する。分離部４１３から出力されたBase view videoストリームはMVCヘッダ除去部４１４に供給され、Dependent view videoストリームはマルチプレクサ４１５に供給される。
【０４０２】
MVCヘッダ除去部４１４は、分離部４１３から供給されたBase view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４１４は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４１５に出力する。
【０４０３】
マルチプレクサ４１５は、MVCヘッダ除去部４１４から供給されたBase view videoストリームと、分離部４１３から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４０４】
図３３は、記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【０４０５】
図３３の3D video TS生成部は、AVCエンコーダ４２１、MVCエンコーダ４２２、およびマルチプレクサ４２３から構成される。L viewの映像＃１のデータはAVCエンコーダ４２１に入力され、R viewの映像＃２のデータはMVCエンコーダ４２２に入力される。
【０４０６】
AVCエンコーダ４２１は、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオストリームをBase view videoストリームとしてMVCエンコーダ４２２とマルチプレクサ４２３に出力する。AVCエンコーダ４２１から出力されたBase view videoストリームを構成する各Access UnitにはMVCヘッダが含まれていない。
【０４０７】
MVCエンコーダ４２２は、AVCエンコーダ４２１から供給されたBase view videoストリーム（AVCビデオストリーム）をデコードし、L viewの映像＃１のデータを生成する。
【０４０８】
また、MVCエンコーダ４２２は、デコードして得られたL viewの映像＃１のデータと、外部から入力されたR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、マルチプレクサ４２３に出力する。MVCエンコーダ４２２から出力されたDependent view videoストリームを構成する各Access UnitにはMVCヘッダが含まれている。
【０４０９】
マルチプレクサ４２３は、AVCエンコーダ４２１から供給されたBase view videoストリームと、MVCエンコーダ４２２から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４１０】
図３３のAVCエンコーダ４２１が図３のH.264/AVCエンコーダ２１の機能を有し、MVCエンコーダ４２２が図３のH.264/AVCデコーダ２２とDependent view videoエンコーダ２４の機能を有することになる。また、マルチプレクサ４２３が図３のマルチプレクサ２５の機能を有することになる。
【０４１１】
このような構成を有する3D video TS生成部を記録装置内に設けることにより、Base view videoのデータを格納するAccess Unitに対するMVCヘッダの符号化を禁止することが可能になる。また、Dependent view videoのデータを格納するAccess Unitに、１以上のview_idが設定されたMVCヘッダが含まれるようにすることができる。
【０４１２】
図３４は、Access Unitをデコードする再生装置１側の構成を示す図である。
【０４１３】
図３４においては、図２２等を参照して説明したスイッチ１０９とビデオデコーダ１１０が示されている。Base view videoのデータを含むAccess Unit＃１と、Dependent view videoのデータを含むAccess Unit＃２がバッファから読み出され、スイッチ１０９に供給される。
【０４１４】
Base view videoを参照して符号化が行われているから、Dependent view videoを正しく復号するには、まず、対応するBase view videoを復号しておくことが必要になる。
【０４１５】
H.264/MVC規格においては、デコーダ側が、MVCヘッダに含まれるview_idを利用して各Access Unitの復号順序を算出するようになされている。また、Base view videoには、そのエンコード時に、常に最小の値をview_idの値として設定することが定められている。
デコーダは、最小のview_idが設定されているMVCヘッダを含むAccess Unitから復号を開始することで、Base view videoとDependent view videoを正しい順序で復号することができるようになされている。
【０４１６】
ところで、再生装置１のビデオデコーダ１１０に供給される、Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。
【０４１７】
そこで、再生装置１においては、MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。
【０４１８】
これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
【０４１９】
図３４のスイッチ１０９は、最小の値である0がview_idとして設定されていると認識したAccess Unit＃１をまずビデオデコーダ１１０に出力し、デコードを行わせる。
【０４２０】
また、スイッチ１０９は、Access Unit＃１のデコードが終了した後、0より大きい固定値であるYがview_idとして設定されているAccess Unit＃２をビデオデコーダ１１０に出力し、デコードを行わせる。Access Unit＃２に格納されているDependent view videoのピクチャは、Access Unit＃１に格納されているBase view videoのピクチャに対応するピクチャである。
【０４２１】
このように、Base view videoを格納したAccess Unitに対するMVCヘッダの符号化を禁止することにより、光ディスク２に記録されているBase view videoストリームを、従来のプレーヤにおいても再生可能なストリームとすることができる。
【０４２２】
BD-ROM規格を拡張したBD-ROM 3D規格のBase view videoストリームの条件として、従来のプレーヤにおいても再生可能なストリームとするような条件が決められた場合であっても、その条件を満たすようにすることができる。
【０４２３】
例えば、図３５に示すように、Base view videoとDependent view videoにそれぞれMVCヘッダを付加しておき、Base view videoから先にデコードが行われるようにした場合、そのBase view videoは従来のプレーヤにおいては再生できないものになる。従来のプレーヤが搭載するH.264/AVCデコーダにとっては、MVCヘッダは未定義のデータである。そのような未定義のデータが入力された場合、デコーダによってはそれを無視することができず、処理が破綻するおそれがある。
【０４２４】
なお、図３５においては、Base view videoのview_idはX、Dependent view videoのview_idは、Xより大きいYである。
【０４２５】
また、MVCヘッダの符号化を禁止した場合であっても、Base view videoのview_idを0としてみなすように定義することにより、再生装置１にBase view videoのデコードを先に行わせ、その後に、対応するDependent view videoのデコードを行わせることができる。
すなわち、正しい順序でデコードを行わせることが可能になる。
【０４２６】
［運用２］
GOP構造について
H.264/AVC規格には、MPEG-2ビデオ規格におけるGOP(Group Of Picture)構造が定義されていない。
【０４２７】
そこで、H.264/AVCビデオストリームを扱うBD-ROM規格においては、H.264/AVCビデオストリームのGOP構造を定義し、ランダムアクセスなどのGOP構造を利用した各種の機能を実現している。
【０４２８】
H.264 AVC/MVCで符号化して得られたビデオストリームであるBase view videoストリームとDependent view videoストリームにも、H.264/AVCビデオストリームと同様にGOP構造の定義が存在しない。
【０４２９】
Base view videoストリームはH.264/AVCビデオストリームである。従って、Base view videoストリームのGOP構造は、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造になる。
【０４３０】
Dependent view videoストリームのGOP構造についても、Base view videoストリームのGOP構造、すなわち、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造として定義する。
【０４３１】
BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造には次のような特徴がある。
【０４３２】
１．ストリーム構造についての特徴
（１）Open GOP/Closed GOP構造
図３６は、Closed GOP構造を示す図である。
【０４３３】
図３６の各ピクチャはH.264/AVCビデオストリームを構成するピクチャである。Closed GOPにはIDR(Instantaneous Decording Refresh)ピクチャが含まれる。
【０４３４】
IDRピクチャはＩピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファ（図２２のDPB１５１）の状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
【０４３５】
図３６に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。
【０４３６】
また、現在GOPのピクチャのうち、IDRピクチャより表示順で後（未来）のピクチャは、IDRピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。H.264/AVCにおいては、表示順でＩピクチャの後ろにあるＰピクチャから、そのＩピクチャより前のピクチャを参照することも許されている。
【０４３７】
図３７は、Open GOP構造を示す図である。
【０４３８】
図３７に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDR Ｉピクチャ（IDRピクチャではないＩピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４３９】
また、現在GOPのピクチャのうち、non-IDR Ｉピクチャより表示順で後のピクチャは、non-IDR Ｉピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４４０】
（２）GOPの先頭のAccess Unitには、SPS、PPSが必ず符号化される。
【０４４１】
SPS(Sequence Parameter Set)は、シーケンス全体の符号化に関する情報を含む、シーケンスのヘッダ情報である。あるシーケンスのデコード時、シーケンスの識別情報などが含まれるSPSが最初に必要になる。PPS(Picture Parameter Set)は、ピクチャ全体の符号化に関する情報を含む、ピクチャのヘッダ情報である。
【０４４２】
（３）GOPの先頭のAccess Unitには、最大30個までのPPSを符号化することができる。
複数のPPSを先頭のAccess Unitに符号化した場合には、各PPSのid(pic_parameter_set_id)は一緒であってはならない。
【０４４３】
（４）GOPの先頭以外のAccess Unitには、最大1個までのPPSを符号化することができる。
【０４４４】
２．参照構造についての特徴
（１）I・P・Bピクチャは、それぞれI・P・Bスライスのみから構成されるピクチャであることが求められる。
【０４４５】
（２）表示順で参照ピクチャ（I or Pピクチャ）の直前のBピクチャは、符号化順では、必ず、その参照ピクチャの直後に符号化されていることが求められる。
【０４４６】
（３）参照ピクチャ（I or Pピクチャ）の符号化順と表示順は維持されること（同じであること）が求められる。
【０４４７】
（４）PピクチャからBピクチャを参照することは禁止される。
【０４４８】
（５）符号化順で、非参照Bピクチャ（B1）が非参照ピクチャ（B2）の前である場合、表示順もB1が前になることが求められる。
【０４４９】
非参照Bピクチャは、符号化順で後ろにある他のピクチャによって参照されないBピクチャである。
【０４５０】
（６）参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）を参照することができる。
【０４５１】
（７）非参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）、又は参照Bピクチャを参照することができる。
【０４５２】
（８）連続するBピクチャの数を最大3枚とすることが求められる。
【０４５３】
３．GOP内の最大フレーム・フィールド数についての特徴
GOP内の最大フレーム・フィールド数は、図３８に示すようにビデオのフレームレートに応じて規定されている。
【０４５４】
図３８に示すように、例えば、フレームレートが29.97フレーム／秒でインタレース表示を行う場合、1GOPのピクチャで表示させることが可能な最大フィールド数は60である。
また、フレームレートが59.94フレーム／秒でプログレッシブ表示を行う場合、1GOPのピクチャで表示させることが可能な最大フレーム数は60である。
【０４５５】
以上のような特徴を有するGOP構造を、Dependent view videoストリームのGOP構造としても定義する。
【０４５６】
また、Base view videoストリームのあるGOPの構造と、対応するDependent view videoストリームのGOPの構造を一致させることを制約として規定する。
【０４５７】
以上のようにして定義したBase view videoストリーム、またはDependent view videoストリームのClosed GOP構造を図３９に示す。
【０４５８】
図３９に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。アンカーピクチャについては後述する。
【０４５９】
また、現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で後（未来）のピクチャは、IDRピクチャ、またはアンカーピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。
【０４６０】
図４０は、Base view videoストリーム、またはDependent view videoストリームのOpen GOP構造を示す図である。
【０４６１】
図４０に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDRアンカーピクチャ（IDRピクチャではないアンカーピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４６２】
また、現在GOPのピクチャのうち、non-IDRアンカーピクチャより表示順で後のピクチャは、non-IDRアンカーピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４６３】
以上のようにしてGOP構造を定義することにより、例えば、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、Open GOPであるのか、Closed GOPであるのかといったようなストリーム構造の特徴が一致することになる。
【０４６４】
また、Base view videoの非参照Bピクチャに対応するDependent view videoのピクチャは必ず非参照Bピクチャになるといったように、ピクチャの参照構造の特徴も一致することになる。
【０４６５】
さらに、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、フレーム数、フィールド数も一致することになる。
【０４６６】
このように、Dependent view videoストリームのGOP構造をBase view videoストリームのGOP構造と同じ構造として定義することにより、ストリーム間の対応するGOP同士に同じ特徴を持たせることが可能になる。
【０４６７】
また、ストリームの途中からデコードを行うような場合でも、問題なくそれを行うことが可能になる。ストリームの途中からのデコードは、例えば、トリックプレイやランダムアクセスのときに行われる。
【０４６８】
フレーム数が異なるといったように、ストリーム間の対応するGOP同士の構造が異なる場合、一方のストリームは正常に再生できるのに他方のストリームが再生できないといったことが生じるおそれがあるが、それを防ぐことができる。
【０４６９】
ストリーム間の対応するGOP同士の構造を異なるものとしてストリームの途中からデコードを開始した場合、Dependent view videoのデコードに必要となるBase view videoのピクチャがデコードされていないといったことが生じるおそれもある。この場合、結果として、Dependent view videoのピクチャをデコードすることができず、3D表示を行うことができなくなる。また、実装の方法によっては、Base view videoの画像も出力できない可能性があるが、それらの不都合も回避することができる。
【０４７０】
EP_mapについて
Base view videoストリームとDependent view videoストリームのGOP構造を利用することで、ランダムアクセスやトリックプレイ時のデコードの開始位置をEP_mapに設定することが可能になる。EP_mapはClip Informationファイルに含まれる。
【０４７１】
デコード開始位置としてEP_mapに設定可能なピクチャの制約として次の２つの制約を規定する。
【０４７２】
１．Dependent view videoストリームに設定可能な位置を、SubsetSPSに続けて配置されるアンカーピクチャの位置か、SubsetSPSに続けて配置されるIDRピクチャの位置とする。
【０４７３】
アンカーピクチャは、H.264 AVC/MVCで規定されるピクチャであり、時間方向に参照せずに、view間の参照を行って符号化されたDependent view videoストリームのピクチャである。
【０４７４】
２．Dependent view videoストリームのあるピクチャをデコード開始位置としてEP_mapに設定する場合、対応するBase view videoストリームのピクチャも、デコード開始位置としてEP_mapに設定する。
【０４７５】
図４１は、上記２つの制約を満たすEP_mapに設定されたデコード開始位置の例を示す図である。
【０４７６】
図４１においては、Base view videoストリームを構成するピクチャと、Dependent view videoストリームを構成するピクチャをデコード順に示している。
【０４７７】
Dependent view videoストリームのピクチャのうちの色を付けて示すピクチャＰ1は、アンカーピクチャ、またはIDRピクチャである。ピクチャＰ1のデータを含むAccess Unitの直前のAccess UnitにはSubsetSPSが含まれる。
【０４７８】
図４１の例においては、白抜き矢印＃１１で示すように、ピクチャＰ1が、Dependent view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４７９】
ピクチャＰ1に対応するBase view videoストリームのピクチャであるピクチャＰ11はIDRピクチャである。白抜き矢印＃１２で示すように、IDRピクチャであるピクチャＰ11も、Base view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４８０】
ランダムアクセスやトリックプレイが指示されたことから、ピクチャＰ1とピクチャＰ11からデコードを開始する場合、最初に、ピクチャＰ11のデコードが行われる。IDRピクチャであるから、他のピクチャを参照することなく、ピクチャＰ11をデコードすることが可能である。
【０４８１】
ピクチャＰ11のデコードが終了したとき、次に、ピクチャＰ1がデコードされる。ピクチャＰ1のデコードにはデコード済みのピクチャＰ11が参照される。アンカーピクチャ、またはIDRピクチャであるから、ピクチャＰ11のデコードが終了していればピクチャＰ1のデコードは可能である。
【０４８２】
その後、Base view videoのピクチャＰ1の次のピクチャ、Dependent view videoのピクチャＰ11の次のピクチャ、・・・といったようにしてデコードが行われる。
【０４８３】
対応するGOPの構造が同じであり、かつ、対応する位置からデコードが開始されるから、Base view videoについてもDependent view videoについても、EP_mapに設定されたピクチャ以降のピクチャを問題なくデコードすることができる。これによりランダムアクセスを実現することが可能になる。
【０４８４】
図４１の垂直方向に示す点線より左側に並ぶピクチャはデコードされないピクチャになる。
【０４８５】
図４２は、Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【０４８６】
図４２の例においては、色を付けて示すBase view videoのIDRピクチャであるピクチャＰ21がデコード開始位置としてEP_mapに設定されている。
【０４８７】
Base view videoのピクチャＰ21からデコードを開始する場合において、ピクチャＰ21に対応するDependent view videoのピクチャであるピクチャＰ31がアンカーピクチャではない場合を考える。GOP構造を定義していない場合、Base view videoのIDRピクチャに対応するDependent view videoのピクチャが、IDRピクチャまたはアンカーピクチャであるという保障はない。
【０４８８】
この場合、Base view videoのピクチャＰ21のデコードが終わったときであっても、ピクチャＰ31をデコードすることはできない。ピクチャＰ31のデコードには時間方向の参照も必要になるが、垂直方向に示す点線より左側（デコード順で前）のピクチャはデコードされていない。
【０４８９】
ピクチャＰ31をデコードすることができないことにより、ピクチャＰ31を参照するDependent view videoの他のピクチャもデコードすることができないことになる。
【０４９０】
Dependent view videoストリームのGOP構造を定義しておくことにより、このようなことを回避することができる。
【０４９１】
Base view videoだけでなく、Dependent view videoについてもEP_mapでデコード開始位置を設定しておくことにより、再生装置１はデコードの開始位置を容易に特定することが可能になる。
【０４９２】
Base view videoのあるピクチャだけをデコード開始位置としてEP_mapに設定しておいた場合、再生装置１は、デコード開始位置のピクチャに対応するDependent view videoのピクチャを計算により特定する必要があり、処理が複雑になってしまう。
【０４９３】
たとえ対応するBase view videoとDependent view videoのピクチャ同士が同じDTS/PTSを持っていたとしても、ビデオのビットレートが異なる場合にはTSにおけるバイト配列まで一致させることができないため、この場合に処理が複雑になる。
【０４９４】
図４３は、Base view videoストリームとDependent view videoストリームからなるMVCストリームを対象にしたランダムアクセスやトリックプレイを行う際に必要になるピクチャサーチの概念を示す図である。
【０４９５】
図４３に示すように、ランダムアクセスやトリックプレイを行う際、non-IDRアンカーピクチャかIDRピクチャがサーチされ、デコード開始位置が決定される。
【０４９６】
ここで、EP_mapについて説明する。Base view videoのデコード開始位置をEP_mapに設定する場合について説明するが、Dependent view videoのデコード開始位置についても、同様にしてDependent view video のEP_mapに設定される。
【０４９７】
図４４は、光ディスク２上に記録されたAVストリームの構造を示す図である。
【０４９８】
Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
【０４９９】
アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。１つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
【０５００】
Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
【０５０１】
PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
【０５０２】
なお、ソースパケットには、Clip AVストリームの先頭を例えば０として、ソースパケット毎に１ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第１バイト目から始まる。
【０５０３】
EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
【０５０４】
EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の１つのEPデータは、PTSと、PTSに対応するAccess Unitの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、１Access Unitには１ピクチャ分のデータが格納される。
【０５０５】
図４５は、Clip AVストリームの例を示す図である。
【０５０６】
図４５のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム（Base view videoストリーム）である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
【０５０７】
図４５においては、ビデオストリームのソースパケットのうちの、IDRピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
【０５０８】
例えば、PID=ｘで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
【０５０９】
同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
【０５１０】
図４６は、図４５のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
【０５１１】
図４６に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
【０５１２】
stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
【０５１３】
PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UnitのPTSを表す。
【０５１４】
SPN_EP_startは、PTS_EP_startの値により参照されるAccess Unitの第１バイト目を含むソースパケットのアドレスを表す。
【０５１５】
ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
【０５１６】
例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
【０５１７】
このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
【０５１８】
図４７は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【０５１９】
上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Unitの第１バイト目を含むソースパケットのソースパケット番号を表す。
【０５２０】
AVC/H.264においては、Access Unitすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
【０５２１】
トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が１であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Unitが開始されることになる。
【０５２２】
このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
【０５２３】
［運用３］
Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPOC(Picture Order Count)が符号化時に設定されている。POCは、ピクチャの表示順を表す値である。
【０５２４】
AVC/H.264においては、POCは「A variable having a value that is non-decreasing with increasing picture position in output order relative to the previous IDR picture in decoding order or relative to the previous picture containing the memory management control operation that marks all reference pictures as “unused for reference”.」として規定されている。
【０５２５】
符号化時、Base view videoストリームのピクチャに設定するPOCと、Dependent view videoストリームのピクチャに設定するPOCは統一して運用される。
【０５２６】
例えば、Base view videoストリームの表示順で１番目のピクチャにはPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５２７】
また、Dependent view videoストリームの表示順で１番目のピクチャには、Base view videoストリームの１番目のピクチャに設定されるものと同じPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５２８】
上述したようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造は同じであるから、Base view videoストリームとDependent view videoストリームの各ピクチャには、表示順で対応するピクチャ同士、同じPOCが設定される。
【０５２９】
これにより、再生装置１は、同じPOCが設定されているview componentを、表示順で対応するview componentとして処理することが可能になる。
【０５３０】
例えば、再生装置１は、Base view videoストリームのピクチャのうちのPOC=1が設定されているピクチャと、Dependent view videoストリームのピクチャのうちのPOC=1が設定されているピクチャを、対応するピクチャとして処理することができる。
【０５３１】
また、Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPicture Timing SEI(Supplemental Enhancement Information)が設定されている。SEIは、H.264/AVCで規定される、デコードに関する補助的な情報を含む付加情報である。
【０５３２】
SEIのうちの１つであるPicture Timing SEIには、符号化時のCPB(Coded Picture Buffer)からの読み出し時刻、デコード時のDPB（図２２のDPB１５１）からの読み出し時刻などの時刻情報が含まれる。また、表示時刻の情報、ピクチャ構造の情報などが含まれる。
【０５３３】
符号化時、Base view videoストリームのピクチャに設定するPicture Timing SEIと、Dependent view videoストリームのピクチャに設定するPicture Timing SEIは統一して運用される。
【０５３４】
例えば、Base view videoストリームの符号化順で１番目のピクチャにCPBからの読み出し時刻としてT1が設定された場合、Dependent view videoストリームの符号化順で１番目のピクチャにも、CPBからの読み出し時刻としてT1が設定される。
【０５３５】
すなわち、Base view videoストリームとDependent view videoストリームの各ピクチャには、符号化順、または復号順で対応するピクチャ同士、同じ内容のPicture Timing SEIが設定される。
【０５３６】
これにより、再生装置１は、同じPicture Timing SEIが設定されているview componentを、復号順で対応するview componentとして処理することが可能になる。
【０５３７】
POC、Picture Timing SEIは、Base view videoとDependent view videoのエレメンタリストリームに含まれるものであり、再生装置１においてはビデオデコーダ１１０により参照される。
【０５３８】
ビデオデコーダ１１０は、エレメンタリストリームに含まれる情報に基づいて、対応するview componentを識別することが可能になる。また、ビデオデコーダ１１０は、Picture Timing SEIに基づいて正しい復号順で、また、POCに基づいて正しい表示順になるようにデコード処理を行うことが可能になる。
【０５３９】
対応するview componentを識別するためにPlayListなどを参照する必要がないため、System Layerや、それ以上のLayerに問題が起きた場合の対処が可能になる。また、問題が起きたLayerに依存しないデコーダ実装も可能になる。
【０５４０】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【０５４１】
図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０５４２】
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で符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができるようにした記録媒体、および記録方法に関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray（登録商標）)-ROM(Read Only Memory)等のBlu-Ray（登録商標） Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−３４８３１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
ステレオ画像の画像データは、左画像のデータのストリームと右画像のデータのストリームの２本のデータストリームからなる。仮に、２本のデータストリームをそのままBDに記録しただけでは、既に普及しているBDプレーヤで再生できないおそれがある。
【００１１】
本技術はこのような状況に鑑みてなされたものであり、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができるようにするものである。
【課題を解決するための手段】
【００１２】
本技術の一側面の記録媒体は、複数の映像データを対象としてH.264 AVC/MVCで符号化を行うことによって得られたviewのIDを含むMVCヘッダが付加されていないデータからなり、前記IDとして前記MVCヘッダに設定されている値が小さいviewのデータから順に処理を行う再生装置を、前記IDとして０の値が前記MVCヘッダに設定されているデータとして扱い、Dependent view videoのデータより先に復号を行うように機能させるBase view videoのストリームと、前記符号化を行うことによって得られた、Dependent viewのデータであることを表す１以上の値の前記IDを含む前記MVCヘッダが付加されたデータからなり、前記再生装置を、前記Base view videoのストリームの後に復号を行うように機能させる前記Dependent view videoのストリームとが記録された記録媒体である。
【００１３】
本技術の一側面の記録方法は、複数の映像データをH.264 AVC/MVCで符号化し、符号化を行うことによって得られた、viewのIDを含むMVCヘッダが付加されていないデータからなるBase view videoのストリームと、Dependent viewのデータであることを表す前記IDを含む前記MVCヘッダが付加されたデータからなるDependent view videoのストリームを記録媒体に記録するステップを含む。
【発明の効果】
【００１４】
本技術によれば、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが記録されているBD等の記録媒体を、3D再生に対応していない装置においても再生させることができる。
【図面の簡単な説明】
【００１５】
【図１】本技術を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】MVCエンコーダの構成例を示すブロック図である。
【図４】参照画像の例を示す図である。
【図５】TSの構成例を示す図である。
【図６】TSの他の構成例を示す図である。
【図７】TSのさらに他の構成例を示す図である。
【図８】AVストリームの管理の例を示す図である。
【図９】Main PathとSub Pathの構造を示す図である。
【図１０】光ディスクに記録されるファイルの管理構造の例を示す図である。
【図１１】PlayListファイルのシンタクスを示す図である。
【図１２】図１１にあるreserved_for_future_useの使い方の例を示す図である。
【図１３】3D_PL_typeの値の意味を示す図である。
【図１４】view_typeの値の意味を示す図である。
【図１５】図１１のPlayList()のシンタクスを示す図である。
【図１６】図１５のSubPath()のシンタクスを示す図である。
【図１７】図１６のSubPlayItem(i)のシンタクスを示す図である。
【図１８】図１５のPlayItem()のシンタクスを示す図である。
【図１９】図１８のSTN_table()のシンタクスを示す図である。
【図２０】再生装置の構成例を示すブロック図である。
【図２１】図２０のデコーダ部の構成例を示す図である。
【図２２】ビデオストリームの処理を行う構成を示す図である。
【図２３】ビデオストリームの処理を行う構成を示す図である。
【図２４】ビデオストリームの処理を行う他の構成を示す図である。
【図２５】Access Unitの例を示す図である。
【図２６】ビデオストリームの処理を行うさらに他の構成を示す図である。
【図２７】合成部と、その前段の構成を示す図である。
【図２８】合成部と、その前段の構成を示す他の図である。
【図２９】ソフト製作処理部の構成例を示すブロック図である。
【図３０】ソフト製作処理部を含む各構成の例を示す図である。
【図３１】記録装置に設けられる3D video TS生成部の構成例を示す図である。
【図３２】記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【図３３】記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【図３４】Access Unitをデコードする再生装置側の構成を示す図である。
【図３５】デコード処理を示す図である。
【図３６】Close GOP構造を示す図である。
【図３７】Open GOP構造を示す図である。
【図３８】GOP内の最大フレーム・フィールド数を示す図である。
【図３９】Close GOP構造を示す図である。
【図４０】Open GOP構造を示す図である。
【図４１】EP_mapに設定されたデコード開始位置の例を示す図である。
【図４２】Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【図４３】ピクチャサーチの概念を示す図である。
【図４４】光ディスク上に記録されたAVストリームの構造を示す図である。
【図４５】Clip AVストリームの例を示す図である。
【図４６】図４５のClip AVストリームに対応したEP_mapを概念的に示す図である。
【図４７】SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【図４８】コンピュータのハードウェアの構成例を示すブロック図である。
【発明を実施するための形態】
【００１６】
＜第１の実施の形態＞
［再生システムの構成例］
図１は、本技術を適用した再生装置１を含む再生システムの構成例を示す図である。
【００１７】
図１に示すように、この再生システムは、再生装置１と表示装置３が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と同様にして光ディスク２に記録され、再生される。
【００４８】
［TSの構成例］
図５は、TSの構成例を示す図である。
【００４９】
図５の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 viewとDependent viewのそれぞれのストリームが用意されている。
【００５２】
それぞれのストリームをデコードして得られた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画像のグラフィックスのストリームとなる。
【００５５】
図６は、TSの他の構成例を示す図である。
【００５６】
図６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
【００５７】
一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００５８】
このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
【００５９】
図７は、TSのさらに他の構成例を示す図である。
【００６０】
図７ＡのMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００６１】
一方、Sub TSにはDependent view videoストリームが含まれている。
【００６２】
このように、Dependent view videoストリームがBase view videoストリームとは別のTSに含まれていることもある。
【００６３】
図７ＢのMain TSにはBase view video、Primary audio、PG、IGのそれぞれのストリームが多重化されている。一方、Sub TSにはDependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００６４】
Main TSに含まれるPG、IGは2D再生用のストリームである。Sub TSに含まれているストリームは3D再生用のストリームである。
【００６５】
このように、PGのストリームとIGのストリームを2D再生と3D再生において共有しないようにすることも可能である。
【００６６】
以上のように、Base view videoストリームとDependent view videoストリームが別々のMPEG2 TSに含まれることがある。Base view videoストリームとDependent view videoストリームを別々のMPEG2 TSに含めて記録する場合のメリットについて説明する。
【００６７】
例えば１本のMPEG2 TSとして多重化できるビットレートが制限されている場合を考える。この場合において、Base view videoストリームとDependent view videoストリームの両方を１本のMPEG2 TSに含めたときには、その制約を満たすために各ストリームのビットレートを下げる必要がある。その結果、画質が落ちてしまうことになる。
【００６８】
それぞれ異なるMPEG2 TSに含めることによって、ビットレートを下げる必要がなくなり、画質を落とさずに済むことになる。
【００６９】
［アプリケーションフォーマット］
図８は、再生装置１による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ファイルは、図１０のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
【０１１２】
図１１の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の後には、１６０bitのreserved_for_future_useが含まれる。
【０１１８】
AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
【０１１９】
PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
【０１２０】
PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。
【０１２１】
ExtensionData()には、プライベートデータが挿入できるようになっている。
【０１２２】
図１２は、PlayListファイルの記述の具体例を示す図である。
【０１２３】
図１２に示すように、PlayListファイルには２bitの3D_PL_typeと１bitのview_typeが記述される。
【０１２４】
3D_PL_typeは、PlayListの種類を表す。
【０１２５】
view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。
【０１２６】
図１３は、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情報として、Base view videoストリームとDependent view videoストリームの光ディスク２からの読み出しに関する情報が登録される。
【０１３１】
図１４は、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の信号を区別して出力することが可能になる。
【０１３７】
図１５は、図１１の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の後には、１５ビットの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（）が参照される。
【０１５０】
図１７は、図１６の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はマルチClipの登録の有無を示すフラグである。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ストリームがこのvideo_stream_idにより特定される。
【０１７８】
Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
【０１７９】
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が与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化した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ストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
【０１８４】
Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
【０１８５】
［再生装置１の構成例］
図２０は、再生装置１の構成例を示すブロック図である。
【０１８６】
コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
【０１８７】
例えば、コントローラ５１は、ディスクドライブ５２を制御し、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表示が行われる。
【０２３０】
［T-STD(Transport stream-System. Target Decoder)の第１の例］
ここで、図２１に示す構成のうちの、デコーダと、その周辺の構成について説明する。
【０２３１】
図２２は、ビデオストリームの処理を行う構成を示す図である。
【０２３２】
図２２において、図２１に示す構成と同じ構成には同じ符号を付してある。図２２においては、PIDフィルタ１０４、B videoバッファ１０６、スイッチ１０７、D videoバッファ１０８、スイッチ１０９、ビデオデコーダ１１０、およびDPB(Decoded Picture Buffer)１５１が示されている。図２１には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB１５１が設けられる。
【０２３３】
PIDフィルタ１０４は、Main TSに含まれるBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２３４】
例えば、Base view videoストリームを構成するパケットには、PID=0がPIDの固定値として割り当てられている。また、Dependent view videoストリームを構成するパケットには、0以外の固定の値がPIDとして割り当てられている。
【０２３５】
PIDフィルタ１０４は、PID=0がヘッダに記述されているパケットをB videoバッファ１０６に出力し、0以外のPIDがヘッダに記述されているパケットをスイッチ１０７に出力する。
【０２３６】
B videoバッファ１０６に出力されたパケットは、TB(Transport Buffer)1、MB(Multiplexing Buffer)1を介してVSB1に記憶される。VSB1には、Base view videoのエレメンタリストリームのデータが記憶される。
【０２３７】
スイッチ１０７には、PIDフィルタ１０４から出力されたパケットだけでなく、図２１のPIDフィルタ１０５においてSub TSから抽出されたDependent view videoストリームを構成するパケットも供給される。
【０２３８】
スイッチ１０７は、PIDフィルタ１０４からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２３９】
また、スイッチ１０７は、PIDフィルタ１０５からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２４０】
D videoバッファ１０８に出力されたパケットは、TB2、MB2を介してVSB2に記憶される。VSB2には、Dependent view videoのエレメンタリストリームのデータが記憶される。
【０２４１】
スイッチ１０９は、B videoバッファ１０６のVSB1に記憶されたBase view videoのパケットと、D videoバッファ１０８のVSB2に記憶されたDependent view videoのパケットを順次読み出し、ビデオデコーダ１１０に出力する。
【０２４２】
例えば、スイッチ１０９は、ある時刻のBase view videoのパケットを出力した直後にそれと同じ時刻のDependent view videoのパケットを出力するといったように、同じ時刻のBase view videoのパケットとDependent view videoのパケットを続けてビデオデコーダ１１０に出力する。
【０２４３】
Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには、そのエンコード時に、PCR(Program Clock Reference)同期が確保された同じ時刻情報が設定されている。Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合であっても、対応するピクチャのデータを格納したパケットには同じ時刻情報が設定される。
【０２４４】
時刻情報はDTS(Decoding Time Stamp)、PTS(Presentation Time Stamp)であり、各PES(Packetized Elementary Stream)パケットに設定される。
【０２４５】
すなわち、それぞれのストリームのピクチャをエンコード順／デコード順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャが、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じDTSが設定されている。
【０２４６】
また、それぞれのストリームのピクチャを表示順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャも、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じPTSが設定されている。
【０２４７】
後述するようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造が同じ構造である場合、デコード順で対応するピクチャは、表示順でも対応するピクチャになる。
【０２４８】
パケットの転送がシリアルで行われる場合、あるタイミングでB videoバッファ１０６のVSB1から読み出されたパケットのDTS1と、直後のタイミングでD videoバッファ１０８のVSB2から読み出されたパケットのDTS2は、図２２に示すように同じ時刻を表すものになる。
【０２４９】
スイッチ１０９は、B videoバッファ１０６のVSB1から読み出したBase view videoのパケット、または、D videoバッファ１０８のVSB2から読み出したDependent view videoのパケットをビデオデコーダ１１０に出力する。
【０２５０】
ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットを順次デコードし、デコードして得られたBase view videoのピクチャのデータ、または、Dependent view videoのピクチャのデータをDPB１５１に記憶させる。
【０２５１】
DPB１５１に記憶されたデコード済みのピクチャのデータは、所定のタイミングでスイッチ１１１により読み出される。また、DPB１５１に記憶されたデコード済みのピクチャのデータは、他のピクチャの予測にビデオデコーダ１１０により用いられる。
【０２５２】
データの転送がシリアルで行われる場合、あるタイミングで出力されたBase view videoのピクチャのデータのPTSと、直後のタイミングで出力されたDependent view videoのピクチャのデータのPTSは、同じ時刻を表すものになる。
【０２５３】
Base view videoストリームとDependent view videoストリームは図５等を参照して説明したように１本のTSに多重化される場合があるし、図７を参照して説明したようにそれぞれ異なるTSに含まれることがある。
【０２５４】
図２２のデコーダモデルを実装することにより、再生装置１は、Base view videoストリームとDependent view videoストリームが１本のTSに多重化されている場合であっても、それぞれ異なるTSに含まれる場合であっても、対応することが可能になる。
【０２５５】
例えば図２３に示すように１本のTSが供給される状況しか想定されていない場合、Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれる場合などには対応することができない。
【０２５６】
また、図２２のデコーダモデルによれば、同じDTSを持つことから、Base view videoストリームとDependent view videoストリームが異なるTSに含まれる場合であっても、正しいタイミングでビデオデコーダ１１０にパケットを供給することができる。
【０２５７】
Base view video用のデコーダとDependent view video用のデコーダをそれぞれ並列に設けるようにしてもよい。この場合、Base view video用のデコーダとDependent view video用のデコーダには、それぞれ、同じ時刻のパケットが同じタイミングで供給される。
【０２５８】
［第２の例］
図２４は、ビデオストリームの処理を行う他の構成を示す図である。
【０２５９】
図２４においては、図２２の構成に加えて、スイッチ１１１、L videoプレーン生成部１６１、およびR videoプレーン生成部１６２が示されている。また、PIDフィルタ１０５もスイッチ１０７の前段に示されている。重複する説明については適宜省略する。
【０２６０】
L videoプレーン生成部１６１は、L view videoのプレーンを生成するものであり、図２１のB videoプレーン生成部１１２に替えて設けられる。
【０２６１】
R videoプレーン生成部１６２は、R view videoのプレーンを生成するものであり、図２１のD videoプレーン生成部１１３に替えて設けられる。
【０２６２】
この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。
【０２６３】
すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
【０２６４】
また、スイッチ１１１は、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のストリームであることを表す。
【０２６７】
この場合、スイッチ１１１は、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のプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２７１】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２７２】
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のデータを含むユニットである。Access Unit＃２はDependent view videoのデータを含むユニットである。Access Unitはピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。
【０２８１】
H.264 AVC/MVCでのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなAccess Unitに格納される。H.264 AVC/MVCでのエンコード時、Access Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。
【０２８２】
図２５の例の場合、Access Unit＃２については、そのAccess 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に基づいて行われるようにしてもよい。
【０２８８】
［第３の例］
図２６は、ビデオストリームの処理を行うさらに他の構成を示す図である。
【０２８９】
図２６の例においては、図２４のL videoプレーン生成部１６１に替えてB videoプレーン生成部１１２が設けられ、R videoプレーン生成部１６２に替えてD videoプレーン生成部１１３が設けられている。B videoプレーン生成部１１２とD videoプレーン生成部１１３の後段にはスイッチ１７１が設けられている。図２６に示す構成においても、view_typeに基づいてデータの出力先が切り替えられるようになされている。
【０２９０】
スイッチ１１１は、DPB１５１に記憶されたデータのうち、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力する。また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０２９１】
Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータは、上述したようにPID、またはview_idに基づいて識別される。
【０２９２】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０２９３】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０２９４】
スイッチ１７１に対しては、PlayListファイルに記述されているview_typeがコントローラ５１から供給されている。
【０２９５】
view_typeの値が0である場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
【０２９６】
また、この場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０２９７】
一方、view_typeの値が1である場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０２９８】
また、この場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０２９９】
図２６の構成によっても、再生装置１は、L viewとR viewを識別し、識別結果に応じて出力先を切り替えることができる。
【０３００】
［プレーン合成モデルの第１の例］
図２７は、図２１に示す構成のうちの、合成部１３０と、その前段の構成を示す図である。
【０３０１】
図２７においても、図２１に示す構成と同じ構成には同じ符号を付してある。
【０３０２】
スイッチ１８１には、Main TS、またはSub TSに含まれるIGストリームを構成するパケットが入力される。スイッチ１８１に入力されるIGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３０３】
スイッチ１８２には、Main TS、またはSub TSに含まれるPGストリームを構成するパケットが入力される。スイッチ１８２に入力されるPGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３０４】
図５等を参照して説明したように、IG、PGについても、3D表示を行うためのBase viewのストリームとDependent viewのストリームが用意されている。
【０３０５】
Base viewのIGがBase view videoと合成して表示され、Dependent viewのIGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、ボタンやアイコンなどを3Dで見ることになる。
【０３０６】
また、Base viewのPGがBase view videoと合成して表示され、Dependent viewのPGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、字幕のテキストなどを3Dで見ることになる。
【０３０７】
スイッチ１８１は、Base IGストリームを構成するパケットをB IGデコーダ１１６に出力し、Dependent IGストリームを構成するパケットをD IGデコーダ１２０に出力する。スイッチ１８１は、図２１のスイッチ１１４とスイッチ１１８の機能を有する。図２７においては、各バッファの図示を省略している。
【０３０８】
B IGデコーダ１１６は、スイッチ１８１から供給されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
【０３０９】
B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１０】
D IGデコーダ１２０は、スイッチ１８１から供給されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。Base IGストリームとDependent IGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３１１】
D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１２】
スイッチ１８２は、Base PGストリームを構成するパケットをB PGデコーダ１２４に出力し、Dependent PGストリームを構成するパケットをD PGデコーダ１２８に出力する。スイッチ１８２は、図２１のスイッチ１２２とスイッチ１２６の機能を有する。
【０３１３】
B PGデコーダ１２４は、スイッチ１８２から供給されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
【０３１４】
B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１５】
D PGデコーダ１２８は、スイッチ１８２から供給されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。Base PGストリームとDependent PGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３１６】
D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３１７】
ビデオデコーダ１１０は、スイッチ１０９（図２２等）から供給されたパケットを順次デコードし、デコードして得られた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のプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３２１】
合成部１３０は、加算部１９１乃至１９４、およびスイッチ１９５から構成される。
【０３２２】
加算部１９１は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９３に出力する。D PGプレーン生成部１２９から加算部１９１に供給されるDependent PGのプレーンには、色情報の変換処理（CLUT(Color Look Up Table)処理）が施される。
【０３２３】
加算部１９２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンを、B videoプレーン生成部１１２から供給されたBase view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９４に出力する。B PGプレーン生成部１２５から加算部１９２に供給されるBase PGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３２４】
加算部１９３は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンを、加算部１９１による合成結果の上に重ねるようにして合成し、合成結果をDependent viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９３に供給されるDependent IGのプレーンには、色情報の変換処理が施される。
【０３２５】
加算部１９４は、B IGプレーン生成部１１７から供給されたBase IGのプレーンを、加算部１９２による合成結果の上に重ねるようにして合成し、合成結果をBase viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９４に供給されるBase IGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３２６】
このようにして生成されたBase viewのプレーンとDependent viewのプレーンに基づいて表示される画像は、ボタンやアイコンが前面に見え、その下（奥行き方向）に字幕のテキストが見え、その下にビデオが見えるような画像になる。
【０３２７】
スイッチ１９５は、view_typeの値が0である場合、Base viewのプレーンをL viewのプレーンとして出力し、Dependent viewのプレーンをR viewのプレーンとして出力する。スイッチ１９５にはコントローラ５１からview_typeが供給される。
【０３２８】
また、スイッチ１９５は、view_typeの値が1である場合、Base viewのプレーンをR viewのプレーンとして出力し、Dependent viewのプレーンをL viewのプレーンとして出力する。供給されたプレーンのうちのどのプレーンがBase viewのプレーンであるのかDependent viewのプレーンであるのかは、PIDやview_idに基づいて識別される。
【０３２９】
このように、再生装置１においては、Base viewのプレーン同士、Dependent viewのプレーン同士、video、IG、PGの各プレーンの合成が行われる。
【０３３０】
video、IG、PGの全てのプレーンの合成が終わった段階で、Base viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３３１】
また、video、IG、PGの全てのプレーンの合成が終わった段階で、Dependent viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３３２】
［第２の例］
図２８は、合成部１３０と、その前段の構成を示す図である。
【０３３３】
図２８に示す構成のうち、図２７に示す構成と同じ構成には同じ符号を付してある。図２８においては、合成部１３０の構成が図２７の構成と異なる。また、スイッチ１１１の動作が、図２７のスイッチ１１１の動作と異なる。B videoプレーン生成部１１２に替えてL videoプレーン生成部１６１が設けられ、D videoプレーン生成部１１３に替えてR videoプレーン生成部１６２が設けられている。重複する説明については省略する。
【０３３４】
スイッチ１１１と、合成部１３０のスイッチ２０１およびスイッチ２０２に対しては、同じview_typeの値がコントローラ５１から供給される。
【０３３５】
スイッチ１１１は、図２４のスイッチ１１１と同様に、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの出力先をview_typeに基づいて切り替える。
【０３３６】
例えば、view_typeの値が0である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
【０３３７】
一方、view_typeの値が1である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
【０３３８】
L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３３９】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３４０】
合成部１３０は、スイッチ２０１、スイッチ２０２、加算部２０３乃至２０６から構成される。
【０３４１】
スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンとD IGプレーン生成部１２１から供給されたDependent IGのプレーンの出力先をview_typeに基づいて切り替える。
【０３４２】
例えば、view_typeの値が0である場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをL viewのプレーンとして加算部２０６に出力する。
この場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３４３】
一方、view_typeの値が1である場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３４４】
スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンとD PGプレーン生成部１２９から供給されたDependent PGのプレーンの出力先をview_typeに基づいて切り替える。
【０３４５】
例えば、view_typeの値が0である場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをL viewのプレーンとして加算部２０４に出力する。
この場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３４６】
一方、view_typeの値が1である場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３４７】
加算部２０３は、スイッチ２０２から供給されたR viewのPGのプレーンを、R videoプレーン生成部１６２から供給されたR view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０５に出力する。
【０３４８】
加算部２０４は、スイッチ２０２から供給されたL viewのPGのプレーンを、L videoプレーン生成部１６１から供給されたL view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０６に出力する。
【０３４９】
加算部２０５は、スイッチ２０１から供給されたR viewのIGのプレーンを、加算部２０３による合成結果のプレーンの上に重ねるようにして合成し、合成結果をR viewのプレーンとして出力する。
【０３５０】
加算部２０６は、スイッチ２０１から供給されたL viewのIGのプレーンを、加算部２０４による合成結果のプレーンの上に重ねるようにして合成し、合成結果をL viewのプレーンとして出力する。
【０３５１】
このように、再生装置１においては、video、IG、PGのそれぞれのBase viewのプレーンとDependent viewのプレーンについて、他のプレーンとの合成の前に、いずれのプレーンがL viewであるのか、またはR viewであるのかが判断される。
【０３５２】
その判断が行われた後、L viewのプレーン同士、R viewのプレーン同士を合成するように、video、IG、PGの各プレーンの合成が行われる。
【０３５３】
［記録装置の構成例］
図２９は、ソフト製作処理部３０１の構成例を示すブロック図である。
【０３５４】
ビデオエンコーダ３１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ３１１は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ３１２に出力する。
【０３５５】
例えば、ビデオエンコーダ３１１は、エンコード時、同じPCRを基準としてDTS、PTSを設定する。すなわち、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じDTSを設定する。
【０３５６】
また、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じPTSを設定する。
【０３５７】
ビデオエンコーダ３１１は、後述するように、デコード順で対応するBase view videoのピクチャとBase view videoのピクチャに、復号に関する補助的な情報である付加情報としてそれぞれ同じ情報を設定する。
【０３５８】
さらに、ビデオエンコーダ３１１は、後述するように、表示順で対応するBase view videoのピクチャとBase view videoのピクチャに、ピクチャの出力順を表すPOCの値としてそれぞれ同じ値を設定する。
【０３５９】
また、ビデオエンコーダ３１１は、後述するように、Base view videoストリームのGOP構造とDependent view videoストリームのGOP構造とを一致させるようにしてエンコードを行う。
【０３６０】
オーディオエンコーダ３１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ３１４に出力する。オーディオエンコーダ３１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
【０３６１】
データエンコーダ３１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ３１６に出力する。
【０３６２】
データエンコーダ３１５は、ビデオエンコーダ３１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。Base view videoストリームの種類ではなく、Dependent view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表す情報が設定されるようにしてもよい。
【０３６３】
また、データエンコーダ３１５は、後述するEP_mapを、Base view videoストリームのClip Informationファイルと、Dependent view videoストリームのClip Informationファイルにそれぞれ設定する。デコード開始位置としてEP_mapに設定されたBase view videoストリームのピクチャと、Dependent view videoストリームのピクチャは対応するピクチャになる。
【０３６４】
多重化部３１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部３１８に出力する。
【０３６５】
誤り訂正符号化部３１８は、エラー訂正用のコードを多重化部３１７により多重化されたデータに付加する。
【０３６６】
変調部３１９は、誤り訂正符号化部３１８から供給されたデータに対して変調を施し、出力する。変調部３１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。
【０３６７】
このような構成を有するソフト製作処理部３０１が記録装置に設けられる。
【０３６８】
図３０は、ソフト製作処理部３０１を含む構成の例を示す図である。
【０３６９】
図３０に示す構成の一部が記録装置内に設けられることもある。
【０３７０】
ソフト製作処理部３０１により生成された記録信号はプリマスタリング処理部３３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部３３３に供給される。
【０３７１】
記録用原盤製作部３３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
【０３７２】
原盤記録部３３３において、プリマスタリング処理部３３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
【０３７３】
金属原盤製作部３３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
【０３７４】
成形処理部３３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。
あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
【０３７５】
成膜処理部３３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
【０３７６】
後加工処理部３３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。
【０３７７】
＜第２の実施の形態＞
［H.264 AVC/MVC Profileビデオストリームの運用１］
光ディスク２の規格であるBD-ROM規格においては、上述したように、H.264 AVC/MVC Profileを採用することで3D映像の符号化が実現される。
【０３７８】
また、BD-ROM規格においては、Base view videoストリームをL viewの映像のストリームとし、Dependent view videoストリームをR viewの映像のストリームとする。
【０３７９】
Base view videoをH.264 AVC/High Profileビデオストリームとして符号化することにより、過去のプレーヤや2D再生のみに対応したプレーヤにおいても、3D対応のディスクである光ディスク２を再生することが可能になる。すなわち、下位互換性を確保することが可能になる。
【０３８０】
具体的には、Base view videoのストリームのみをH.264 AVC/MVC非対応デコーダにおいてもデコード(再生)可能になる。つまり、Base view videoストリームは、既存の2DのBDプレーヤにおいても必ず再生可能なストリームになる。
【０３８１】
また、Base view videoストリームを、2D再生と3D再生において共通して使用することにより、オーサリング時の負荷の軽減を図ることが可能になる。オーサリング側は、AVストリームに関しては、従来行っていた作業に加えて、Dependent view videoストリームを用意すれば3D対応のディスクを製作することが可能になる。
【０３８２】
図３１は、記録装置に設けられる3D video TS生成部の構成例を示す図である。
【０３８３】
図３１の3D video TS生成部は、MVCエンコーダ４０１、MVCヘッダ除去部４０２、およびマルチプレクサ４０３から構成される。図２を参照して説明したようにして撮影されたL viewの映像＃１のデータと、R viewの映像＃２のデータがMVCエンコーダ４０１に入力される。
【０３８４】
MVCエンコーダ４０１は、図３のMVCエンコーダ１１と同様に、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオデータをBase view videoストリームとして出力する。また、MVCエンコーダ４０１は、L viewの映像＃１のデータとR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、出力する。
【０３８５】
MVCエンコーダ４０１から出力されたBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４０１から出力されたDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０３８６】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０３８７】
Dependent view videoのMVCヘッダに記述されるview_idの値としては、１以上の固定値が用いられる。図３２、図３３の例においても同様である。
【０３８８】
すなわち、MVCエンコーダ４０１は、図３のMVCエンコーダ１１とは異なり、MVCヘッダを付加した形でBase view videoとDependent view videoのそれぞれのストリームを生成し、出力するエンコーダである。図３のMVCエンコーダ１１においては、H.264 AVC/MVCで符号化されたDependent view videoのみにMVCヘッダが付加されている。
【０３８９】
MVCエンコーダ４０１から出力されたBase view videoストリームはMVCヘッダ除去部４０２に供給され、Dependent view videoストリームはマルチプレクサ４０３に供給される。
【０３９０】
MVCヘッダ除去部４０２は、Base view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４０２は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４０３に出力する。
【０３９１】
マルチプレクサ４０３は、MVCヘッダ除去部４０２から供給されたBase view videoストリームと、MVCエンコーダ４０１から供給されたDependent view videoストリームを含むTSを生成し、出力する。図３１の例においては、Base view videoストリームを含むTSとDependent view videoストリームを含むTSがそれぞれ出力されているが、上述したように同じTSに多重化されて出力されることもある。
【０３９２】
このように、実装の仕方によっては、L viewの映像とR viewの映像を入力とし、MVCヘッダ付のBase view videoとDependent view videoのそれぞれのストリームを出力するMVCエンコーダも考えられる。
【０３９３】
なお、図３１に示す構成全体を図３に示すようにMVCエンコーダの中に含めることも可能である。図３２、図３３に示す構成についても同様である。
【０３９４】
図３２は、記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【０３９５】
図３２の3D video TS生成部は、混合処理部４１１、MVCエンコーダ４１２、分離部４１３、MVCヘッダ除去部４１４、およびマルチプレクサ４１５から構成される。L viewの映像＃１のデータと、R viewの映像＃２のデータが混合処理部４１１に入力される。
【０３９６】
混合処理部４１１は、L viewの各ピクチャとR viewの各ピクチャを符号化順に並べる。
Dependent view videoの各ピクチャは対応するBase view videoのピクチャを参照して符号化が行われるから、符号化順に並べた結果は、L viewのピクチャとR viewのピクチャが交互に並ぶものになる。
【０３９７】
混合処理部４１１は、符号化順に並べたL viewのピクチャとR viewのピクチャをMVCエンコーダ４１２に出力する。
【０３９８】
MVCエンコーダ４１２は、混合処理部４１１から供給された各ピクチャをH.264 AVC/MVCで符号化し、符号化して得られたストリームを分離部４１３に出力する。MVCエンコーダ４１２から出力されたストリームには、Base view videoストリームとDependent view videoストリームが多重化されている。
【０３９９】
MVCエンコーダ４１２から出力されたストリームに含まれるBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４１２から出力されたストリームに含まれるDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０４００】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０４０１】
分離部４１３は、MVCエンコーダ４１２から供給されたストリームに多重化されているBase view videoストリームとDependent view videoストリームを分離し、出力する。分離部４１３から出力されたBase view videoストリームはMVCヘッダ除去部４１４に供給され、Dependent view videoストリームはマルチプレクサ４１５に供給される。
【０４０２】
MVCヘッダ除去部４１４は、分離部４１３から供給されたBase view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４１４は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４１５に出力する。
【０４０３】
マルチプレクサ４１５は、MVCヘッダ除去部４１４から供給されたBase view videoストリームと、分離部４１３から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４０４】
図３３は、記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【０４０５】
図３３の3D video TS生成部は、AVCエンコーダ４２１、MVCエンコーダ４２２、およびマルチプレクサ４２３から構成される。L viewの映像＃１のデータはAVCエンコーダ４２１に入力され、R viewの映像＃２のデータはMVCエンコーダ４２２に入力される。
【０４０６】
AVCエンコーダ４２１は、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオストリームをBase view videoストリームとしてMVCエンコーダ４２２とマルチプレクサ４２３に出力する。AVCエンコーダ４２１から出力されたBase view videoストリームを構成する各Access UnitにはMVCヘッダが含まれていない。
【０４０７】
MVCエンコーダ４２２は、AVCエンコーダ４２１から供給されたBase view videoストリーム（AVCビデオストリーム）をデコードし、L viewの映像＃１のデータを生成する。
【０４０８】
また、MVCエンコーダ４２２は、デコードして得られたL viewの映像＃１のデータと、外部から入力されたR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、マルチプレクサ４２３に出力する。MVCエンコーダ４２２から出力されたDependent view videoストリームを構成する各Access UnitにはMVCヘッダが含まれている。
【０４０９】
マルチプレクサ４２３は、AVCエンコーダ４２１から供給されたBase view videoストリームと、MVCエンコーダ４２２から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４１０】
図３３のAVCエンコーダ４２１が図３のH.264/AVCエンコーダ２１の機能を有し、MVCエンコーダ４２２が図３のH.264/AVCデコーダ２２とDependent view videoエンコーダ２４の機能を有することになる。また、マルチプレクサ４２３が図３のマルチプレクサ２５の機能を有することになる。
【０４１１】
このような構成を有する3D video TS生成部を記録装置内に設けることにより、Base view videoのデータを格納するAccess Unitに対するMVCヘッダの符号化を禁止することが可能になる。また、Dependent view videoのデータを格納するAccess Unitに、１以上のview_idが設定されたMVCヘッダが含まれるようにすることができる。
【０４１２】
図３４は、Access Unitをデコードする再生装置１側の構成を示す図である。
【０４１３】
図３４においては、図２２等を参照して説明したスイッチ１０９とビデオデコーダ１１０が示されている。Base view videoのデータを含むAccess Unit＃１と、Dependent view videoのデータを含むAccess Unit＃２がバッファから読み出され、スイッチ１０９に供給される。
【０４１４】
Base view videoを参照して符号化が行われているから、Dependent view videoを正しく復号するには、まず、対応するBase view videoを復号しておくことが必要になる。
【０４１５】
H.264/MVC規格においては、デコーダ側が、MVCヘッダに含まれるview_idを利用して各Access Unitの復号順序を算出するようになされている。また、Base view videoには、そのエンコード時に、常に最小の値をview_idの値として設定することが定められている。
デコーダは、最小のview_idが設定されているMVCヘッダを含むAccess Unitから復号を開始することで、Base view videoとDependent view videoを正しい順序で復号することができるようになされている。
【０４１６】
ところで、再生装置１のビデオデコーダ１１０に供給される、Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。
【０４１７】
そこで、再生装置１においては、MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。
【０４１８】
これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
【０４１９】
図３４のスイッチ１０９は、最小の値である0がview_idとして設定されていると認識したAccess Unit＃１をまずビデオデコーダ１１０に出力し、デコードを行わせる。
【０４２０】
また、スイッチ１０９は、Access Unit＃１のデコードが終了した後、0より大きい固定値であるYがview_idとして設定されているAccess Unit＃２をビデオデコーダ１１０に出力し、デコードを行わせる。Access Unit＃２に格納されているDependent view videoのピクチャは、Access Unit＃１に格納されているBase view videoのピクチャに対応するピクチャである。
【０４２１】
このように、Base view videoを格納したAccess Unitに対するMVCヘッダの符号化を禁止することにより、光ディスク２に記録されているBase view videoストリームを、従来のプレーヤにおいても再生可能なストリームとすることができる。
【０４２２】
BD-ROM規格を拡張したBD-ROM 3D規格のBase view videoストリームの条件として、従来のプレーヤにおいても再生可能なストリームとするような条件が決められた場合であっても、その条件を満たすようにすることができる。
【０４２３】
例えば、図３５に示すように、Base view videoとDependent view videoにそれぞれMVCヘッダを付加しておき、Base view videoから先にデコードが行われるようにした場合、そのBase view videoは従来のプレーヤにおいては再生できないものになる。従来のプレーヤが搭載するH.264/AVCデコーダにとっては、MVCヘッダは未定義のデータである。そのような未定義のデータが入力された場合、デコーダによってはそれを無視することができず、処理が破綻するおそれがある。
【０４２４】
なお、図３５においては、Base view videoのview_idはX、Dependent view videoのview_idは、Xより大きいYである。
【０４２５】
また、MVCヘッダの符号化を禁止した場合であっても、Base view videoのview_idを0としてみなすように定義することにより、再生装置１にBase view videoのデコードを先に行わせ、その後に、対応するDependent view videoのデコードを行わせることができる。
すなわち、正しい順序でデコードを行わせることが可能になる。
【０４２６】
［運用２］
GOP構造について
H.264/AVC規格には、MPEG-2ビデオ規格におけるGOP(Group Of Picture)構造が定義されていない。
【０４２７】
そこで、H.264/AVCビデオストリームを扱うBD-ROM規格においては、H.264/AVCビデオストリームのGOP構造を定義し、ランダムアクセスなどのGOP構造を利用した各種の機能を実現している。
【０４２８】
H.264 AVC/MVCで符号化して得られたビデオストリームであるBase view videoストリームとDependent view videoストリームにも、H.264/AVCビデオストリームと同様にGOP構造の定義が存在しない。
【０４２９】
Base view videoストリームはH.264/AVCビデオストリームである。従って、Base view videoストリームのGOP構造は、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造になる。
【０４３０】
Dependent view videoストリームのGOP構造についても、Base view videoストリームのGOP構造、すなわち、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造として定義する。
【０４３１】
BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造には次のような特徴がある。
【０４３２】
１．ストリーム構造についての特徴
（１）Open GOP/Closed GOP構造
図３６は、Closed GOP構造を示す図である。
【０４３３】
図３６の各ピクチャはH.264/AVCビデオストリームを構成するピクチャである。Closed GOPにはIDR(Instantaneous Decording Refresh)ピクチャが含まれる。
【０４３４】
IDRピクチャはＩピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファ（図２２のDPB１５１）の状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
【０４３５】
図３６に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。
【０４３６】
また、現在GOPのピクチャのうち、IDRピクチャより表示順で後（未来）のピクチャは、IDRピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。H.264/AVCにおいては、表示順でＩピクチャの後ろにあるＰピクチャから、そのＩピクチャより前のピクチャを参照することも許されている。
【０４３７】
図３７は、Open GOP構造を示す図である。
【０４３８】
図３７に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDR Ｉピクチャ（IDRピクチャではないＩピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４３９】
また、現在GOPのピクチャのうち、non-IDR Ｉピクチャより表示順で後のピクチャは、non-IDR Ｉピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４４０】
（２）GOPの先頭のAccess Unitには、SPS、PPSが必ず符号化される。
【０４４１】
SPS(Sequence Parameter Set)は、シーケンス全体の符号化に関する情報を含む、シーケンスのヘッダ情報である。あるシーケンスのデコード時、シーケンスの識別情報などが含まれるSPSが最初に必要になる。PPS(Picture Parameter Set)は、ピクチャ全体の符号化に関する情報を含む、ピクチャのヘッダ情報である。
【０４４２】
（３）GOPの先頭のAccess Unitには、最大30個までのPPSを符号化することができる。
複数のPPSを先頭のAccess Unitに符号化した場合には、各PPSのid(pic_parameter_set_id)は一緒であってはならない。
【０４４３】
（４）GOPの先頭以外のAccess Unitには、最大1個までのPPSを符号化することができる。
【０４４４】
２．参照構造についての特徴
（１）I・P・Bピクチャは、それぞれI・P・Bスライスのみから構成されるピクチャであることが求められる。
【０４４５】
（２）表示順で参照ピクチャ（I or Pピクチャ）の直前のBピクチャは、符号化順では、必ず、その参照ピクチャの直後に符号化されていることが求められる。
【０４４６】
（３）参照ピクチャ（I or Pピクチャ）の符号化順と表示順は維持されること（同じであること）が求められる。
【０４４７】
（４）PピクチャからBピクチャを参照することは禁止される。
【０４４８】
（５）符号化順で、非参照Bピクチャ（B1）が非参照ピクチャ（B2）の前である場合、表示順もB1が前になることが求められる。
【０４４９】
非参照Bピクチャは、符号化順で後ろにある他のピクチャによって参照されないBピクチャである。
【０４５０】
（６）参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）を参照することができる。
【０４５１】
（７）非参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）、又は参照Bピクチャを参照することができる。
【０４５２】
（８）連続するBピクチャの数を最大3枚とすることが求められる。
【０４５３】
３．GOP内の最大フレーム・フィールド数についての特徴
GOP内の最大フレーム・フィールド数は、図３８に示すようにビデオのフレームレートに応じて規定されている。
【０４５４】
図３８に示すように、例えば、フレームレートが29.97フレーム／秒でインタレース表示を行う場合、1GOPのピクチャで表示させることが可能な最大フィールド数は60である。
また、フレームレートが59.94フレーム／秒でプログレッシブ表示を行う場合、1GOPのピクチャで表示させることが可能な最大フレーム数は60である。
【０４５５】
以上のような特徴を有するGOP構造を、Dependent view videoストリームのGOP構造としても定義する。
【０４５６】
また、Base view videoストリームのあるGOPの構造と、対応するDependent view videoストリームのGOPの構造を一致させることを制約として規定する。
【０４５７】
以上のようにして定義したBase view videoストリーム、またはDependent view videoストリームのClosed GOP構造を図３９に示す。
【０４５８】
図３９に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。アンカーピクチャについては後述する。
【０４５９】
また、現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で後（未来）のピクチャは、IDRピクチャ、またはアンカーピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。
【０４６０】
図４０は、Base view videoストリーム、またはDependent view videoストリームのOpen GOP構造を示す図である。
【０４６１】
図４０に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDRアンカーピクチャ（IDRピクチャではないアンカーピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４６２】
また、現在GOPのピクチャのうち、non-IDRアンカーピクチャより表示順で後のピクチャは、non-IDRアンカーピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４６３】
以上のようにしてGOP構造を定義することにより、例えば、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、Open GOPであるのか、Closed GOPであるのかといったようなストリーム構造の特徴が一致することになる。
【０４６４】
また、Base view videoの非参照Bピクチャに対応するDependent view videoのピクチャは必ず非参照Bピクチャになるといったように、ピクチャの参照構造の特徴も一致することになる。
【０４６５】
さらに、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、フレーム数、フィールド数も一致することになる。
【０４６６】
このように、Dependent view videoストリームのGOP構造をBase view videoストリームのGOP構造と同じ構造として定義することにより、ストリーム間の対応するGOP同士に同じ特徴を持たせることが可能になる。
【０４６７】
また、ストリームの途中からデコードを行うような場合でも、問題なくそれを行うことが可能になる。ストリームの途中からのデコードは、例えば、トリックプレイやランダムアクセスのときに行われる。
【０４６８】
フレーム数が異なるといったように、ストリーム間の対応するGOP同士の構造が異なる場合、一方のストリームは正常に再生できるのに他方のストリームが再生できないといったことが生じるおそれがあるが、それを防ぐことができる。
【０４６９】
ストリーム間の対応するGOP同士の構造を異なるものとしてストリームの途中からデコードを開始した場合、Dependent view videoのデコードに必要となるBase view videoのピクチャがデコードされていないといったことが生じるおそれもある。この場合、結果として、Dependent view videoのピクチャをデコードすることができず、3D表示を行うことができなくなる。また、実装の方法によっては、Base view videoの画像も出力できない可能性があるが、それらの不都合も回避することができる。
【０４７０】
EP_mapについて
Base view videoストリームとDependent view videoストリームのGOP構造を利用することで、ランダムアクセスやトリックプレイ時のデコードの開始位置をEP_mapに設定することが可能になる。EP_mapはClip Informationファイルに含まれる。
【０４７１】
デコード開始位置としてEP_mapに設定可能なピクチャの制約として次の２つの制約を規定する。
【０４７２】
１．Dependent view videoストリームに設定可能な位置を、SubsetSPSに続けて配置されるアンカーピクチャの位置か、SubsetSPSに続けて配置されるIDRピクチャの位置とする。
【０４７３】
アンカーピクチャは、H.264 AVC/MVCで規定されるピクチャであり、時間方向に参照せずに、view間の参照を行って符号化されたDependent view videoストリームのピクチャである。
【０４７４】
２．Dependent view videoストリームのあるピクチャをデコード開始位置としてEP_mapに設定する場合、対応するBase view videoストリームのピクチャも、デコード開始位置としてEP_mapに設定する。
【０４７５】
図４１は、上記２つの制約を満たすEP_mapに設定されたデコード開始位置の例を示す図である。
【０４７６】
図４１においては、Base view videoストリームを構成するピクチャと、Dependent view videoストリームを構成するピクチャをデコード順に示している。
【０４７７】
Dependent view videoストリームのピクチャのうちの色を付けて示すピクチャＰ1は、アンカーピクチャ、またはIDRピクチャである。ピクチャＰ1のデータを含むAccess Unitの直前のAccess UnitにはSubsetSPSが含まれる。
【０４７８】
図４１の例においては、白抜き矢印＃１１で示すように、ピクチャＰ1が、Dependent view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４７９】
ピクチャＰ1に対応するBase view videoストリームのピクチャであるピクチャＰ11はIDRピクチャである。白抜き矢印＃１２で示すように、IDRピクチャであるピクチャＰ11も、Base view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４８０】
ランダムアクセスやトリックプレイが指示されたことから、ピクチャＰ1とピクチャＰ11からデコードを開始する場合、最初に、ピクチャＰ11のデコードが行われる。IDRピクチャであるから、他のピクチャを参照することなく、ピクチャＰ11をデコードすることが可能である。
【０４８１】
ピクチャＰ11のデコードが終了したとき、次に、ピクチャＰ1がデコードされる。ピクチャＰ1のデコードにはデコード済みのピクチャＰ11が参照される。アンカーピクチャ、またはIDRピクチャであるから、ピクチャＰ11のデコードが終了していればピクチャＰ1のデコードは可能である。
【０４８２】
その後、Base view videoのピクチャＰ1の次のピクチャ、Dependent view videoのピクチャＰ11の次のピクチャ、・・・といったようにしてデコードが行われる。
【０４８３】
対応するGOPの構造が同じであり、かつ、対応する位置からデコードが開始されるから、Base view videoについてもDependent view videoについても、EP_mapに設定されたピクチャ以降のピクチャを問題なくデコードすることができる。これによりランダムアクセスを実現することが可能になる。
【０４８４】
図４１の垂直方向に示す点線より左側に並ぶピクチャはデコードされないピクチャになる。
【０４８５】
図４２は、Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【０４８６】
図４２の例においては、色を付けて示すBase view videoのIDRピクチャであるピクチャＰ21がデコード開始位置としてEP_mapに設定されている。
【０４８７】
Base view videoのピクチャＰ21からデコードを開始する場合において、ピクチャＰ21に対応するDependent view videoのピクチャであるピクチャＰ31がアンカーピクチャではない場合を考える。GOP構造を定義していない場合、Base view videoのIDRピクチャに対応するDependent view videoのピクチャが、IDRピクチャまたはアンカーピクチャであるという保障はない。
【０４８８】
この場合、Base view videoのピクチャＰ21のデコードが終わったときであっても、ピクチャＰ31をデコードすることはできない。ピクチャＰ31のデコードには時間方向の参照も必要になるが、垂直方向に示す点線より左側（デコード順で前）のピクチャはデコードされていない。
【０４８９】
ピクチャＰ31をデコードすることができないことにより、ピクチャＰ31を参照するDependent view videoの他のピクチャもデコードすることができないことになる。
【０４９０】
Dependent view videoストリームのGOP構造を定義しておくことにより、このようなことを回避することができる。
【０４９１】
Base view videoだけでなく、Dependent view videoについてもEP_mapでデコード開始位置を設定しておくことにより、再生装置１はデコードの開始位置を容易に特定することが可能になる。
【０４９２】
Base view videoのあるピクチャだけをデコード開始位置としてEP_mapに設定しておいた場合、再生装置１は、デコード開始位置のピクチャに対応するDependent view videoのピクチャを計算により特定する必要があり、処理が複雑になってしまう。
【０４９３】
たとえ対応するBase view videoとDependent view videoのピクチャ同士が同じDTS/PTSを持っていたとしても、ビデオのビットレートが異なる場合にはTSにおけるバイト配列まで一致させることができないため、この場合に処理が複雑になる。
【０４９４】
図４３は、Base view videoストリームとDependent view videoストリームからなるMVCストリームを対象にしたランダムアクセスやトリックプレイを行う際に必要になるピクチャサーチの概念を示す図である。
【０４９５】
図４３に示すように、ランダムアクセスやトリックプレイを行う際、non-IDRアンカーピクチャかIDRピクチャがサーチされ、デコード開始位置が決定される。
【０４９６】
ここで、EP_mapについて説明する。Base view videoのデコード開始位置をEP_mapに設定する場合について説明するが、Dependent view videoのデコード開始位置についても、同様にしてDependent view video のEP_mapに設定される。
【０４９７】
図４４は、光ディスク２上に記録されたAVストリームの構造を示す図である。
【０４９８】
Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
【０４９９】
アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。１つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
【０５００】
Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
【０５０１】
PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
【０５０２】
なお、ソースパケットには、Clip AVストリームの先頭を例えば０として、ソースパケット毎に１ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第１バイト目から始まる。
【０５０３】
EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
【０５０４】
EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の１つのEPデータは、PTSと、PTSに対応するAccess Unitの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、１Access Unitには１ピクチャ分のデータが格納される。
【０５０５】
図４５は、Clip AVストリームの例を示す図である。
【０５０６】
図４５のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム（Base view videoストリーム）である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
【０５０７】
図４５においては、ビデオストリームのソースパケットのうちの、IDRピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
【０５０８】
例えば、PID=ｘで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
【０５０９】
同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
【０５１０】
図４６は、図４５のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
【０５１１】
図４６に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
【０５１２】
stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
【０５１３】
PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UnitのPTSを表す。
【０５１４】
SPN_EP_startは、PTS_EP_startの値により参照されるAccess Unitの第１バイト目を含むソースパケットのアドレスを表す。
【０５１５】
ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
【０５１６】
例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
【０５１７】
このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
【０５１８】
図４７は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【０５１９】
上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Unitの第１バイト目を含むソースパケットのソースパケット番号を表す。
【０５２０】
AVC/H.264においては、Access Unitすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
【０５２１】
トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が１であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Unitが開始されることになる。
【０５２２】
このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
【０５２３】
［運用３］
Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPOC(Picture Order Count)が符号化時に設定されている。POCは、ピクチャの表示順を表す値である。
【０５２４】
AVC/H.264においては、POCは「A variable having a value that is non-decreasing with increasing picture position in output order relative to the previous IDR picture in decoding order or relative to the previous picture containing the memory management control operation that marks all reference pictures as “unused for reference”.」として規定されている。
【０５２５】
符号化時、Base view videoストリームのピクチャに設定するPOCと、Dependent view videoストリームのピクチャに設定するPOCは統一して運用される。
【０５２６】
例えば、Base view videoストリームの表示順で１番目のピクチャにはPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５２７】
また、Dependent view videoストリームの表示順で１番目のピクチャには、Base view videoストリームの１番目のピクチャに設定されるものと同じPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５２８】
上述したようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造は同じであるから、Base view videoストリームとDependent view videoストリームの各ピクチャには、表示順で対応するピクチャ同士、同じPOCが設定される。
【０５２９】
これにより、再生装置１は、同じPOCが設定されているview componentを、表示順で対応するview componentとして処理することが可能になる。
【０５３０】
例えば、再生装置１は、Base view videoストリームのピクチャのうちのPOC=1が設定されているピクチャと、Dependent view videoストリームのピクチャのうちのPOC=1が設定されているピクチャを、対応するピクチャとして処理することができる。
【０５３１】
また、Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPicture Timing SEI(Supplemental Enhancement Information)が設定されている。SEIは、H.264/AVCで規定される、デコードに関する補助的な情報を含む付加情報である。
【０５３２】
SEIのうちの１つであるPicture Timing SEIには、符号化時のCPB(Coded Picture Buffer)からの読み出し時刻、デコード時のDPB（図２２のDPB１５１）からの読み出し時刻などの時刻情報が含まれる。また、表示時刻の情報、ピクチャ構造の情報などが含まれる。
【０５３３】
符号化時、Base view videoストリームのピクチャに設定するPicture Timing SEIと、Dependent view videoストリームのピクチャに設定するPicture Timing SEIは統一して運用される。
【０５３４】
例えば、Base view videoストリームの符号化順で１番目のピクチャにCPBからの読み出し時刻としてT1が設定された場合、Dependent view videoストリームの符号化順で１番目のピクチャにも、CPBからの読み出し時刻としてT1が設定される。
【０５３５】
すなわち、Base view videoストリームとDependent view videoストリームの各ピクチャには、符号化順、または復号順で対応するピクチャ同士、同じ内容のPicture Timing SEIが設定される。
【０５３６】
これにより、再生装置１は、同じPicture Timing SEIが設定されているview componentを、復号順で対応するview componentとして処理することが可能になる。
【０５３７】
POC、Picture Timing SEIは、Base view videoとDependent view videoのエレメンタリストリームに含まれるものであり、再生装置１においてはビデオデコーダ１１０により参照される。
【０５３８】
ビデオデコーダ１１０は、エレメンタリストリームに含まれる情報に基づいて、対応するview componentを識別することが可能になる。また、ビデオデコーダ１１０は、Picture Timing SEIに基づいて正しい復号順で、また、POCに基づいて正しい表示順になるようにデコード処理を行うことが可能になる。
【０５３９】
対応するview componentを識別するためにPlayListなどを参照する必要がないため、System Layerや、それ以上のLayerに問題が起きた場合の対処が可能になる。また、問題が起きたLayerに依存しないデコーダ実装も可能になる。
【０５４０】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【０５４１】
図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０５４２】
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で符号化を行うことによって得られたviewのIDを含むMVCヘッダが付加されていないデータからなり、前記IDとして前記MVCヘッダに設定されている値が小さいviewのデータから順に処理を行う再生装置を、前記IDとして０の値が前記MVCヘッダに設定されているデータとして扱い、Dependent view videoのデータより先に復号を行うように機能させるBase view videoのストリームと、
前記符号化を行うことによって得られた、Dependent viewのデータであることを表す１以上の値の前記IDを含む前記MVCヘッダが付加されたデータからなり、前記再生装置を、前記Base view videoのストリームの後に復号を行うように機能させる前記Dependent view videoのストリームと
が記録された記録媒体。
【請求項２】
複数の映像データをH.264 AVC/MVCで符号化し、
符号化を行うことによって得られた、viewのIDを含むMVCヘッダが付加されていないデータからなるBase view videoのストリームと、Dependent viewのデータであることを表す前記IDを含む前記MVCヘッダが付加されたデータからなるDependent view videoのストリームを記録媒体に記録する
ステップを含む記録方法。
【請求項１】
複数の映像データを対象としてH.264 AVC/MVCで符号化を行うことによって得られたviewのIDを含むMVCヘッダが付加されていないデータからなり、前記IDとして前記MVCヘッダに設定されている値が小さいviewのデータから順に処理を行う再生装置を、前記IDとして０の値が前記MVCヘッダに設定されているデータとして扱い、Dependent view videoのデータより先に復号を行うように機能させるBase view videoのストリームと、
前記符号化を行うことによって得られた、Dependent viewのデータであることを表す１以上の値の前記IDを含む前記MVCヘッダが付加されたデータからなり、前記再生装置を、前記Base view videoのストリームの後に復号を行うように機能させる前記Dependent view videoのストリームと
が記録された記録媒体。
【請求項２】
複数の映像データをH.264 AVC/MVCで符号化し、
符号化を行うことによって得られた、viewのIDを含むMVCヘッダが付加されていないデータからなるBase view videoのストリームと、Dependent viewのデータであることを表す前記IDを含む前記MVCヘッダが付加されたデータからなるDependent view videoのストリームを記録媒体に記録する
ステップを含む記録方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【公開番号】特開２０１２−１３５００１（Ｐ２０１２−１３５００１Ａ）
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願番号】特願２０１２−１９８２３（Ｐ２０１２−１９８２３）
【出願日】平成２４年２月１日（２０１２．２．１）
【分割の表示】特願２００９−９４２５４（Ｐ２００９−９４２５４）の分割
【原出願日】平成２１年４月８日（２００９．４．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願日】平成２４年２月１日（２０１２．２．１）
【分割の表示】特願２００９−９４２５４（Ｐ２００９−９４２５４）の分割
【原出願日】平成２１年４月８日（２００９．４．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]