JP4985886B2

JP4985886B2 - 再生装置、再生方法、および記録方法

Info

Publication number: JP4985886B2
Application number: JP2012013605A
Authority: JP
Inventors: しのぶ服部
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2009-04-08
Filing date: 2012-01-26
Publication date: 2012-07-25
Anticipated expiration: 2030-03-19
Also published as: JP2012130030A; JP2012124924A; JP2012130031A; JP4985884B2; JP4985883B2; JP2012130029A; JP4985882B2; JP2012124923A; JP4985885B2

Description

本技術は、再生装置、再生方法、および記録方法に関し、特に、例えばH.264 AVC/MVCプロファイル規格で符号化して得られたDependent view videoのストリームのGOP構造を定義してBD等の記録媒体に記録させ、またはGOP構造が定義された記録媒体を再生することができるようにした再生装置、再生方法、および記録方法に関する。

映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。

立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。

立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。

立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。

一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。

そのような大容量の記録媒体としては、BD(Blu-Ray（登録商標）)-ROM(Read Only Memory)等のBlu-Ray（登録商標） Disc（以下、BDともいう）がある。

特開２００５−３４８３１４号公報

ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。

例えば、ステレオ画像の画像データは、左画像のデータのストリームと右画像のデータのストリームの２本のデータストリームからなる。このため、この２本のデータストリームのGOP構造についても定義し、一致させなければ不都合が生じることがある。

本技術はこのような状況に鑑みてなされたものであり、例えばH.264 AVC/MVCプロファイル規格で符号化して得られたDependent view videoのストリームのGOP構造を定義してBD等の記録媒体に記録させ、またはGOP構造が定義された記録媒体を再生することができるようにするものである。

本技術の一側面の再生装置は、２つの視点から撮影された第１のビデオストリームと第２のビデオストリームのうちの第１のビデオストリームを、Ｉピクチャから、復号順で未来の、次のＩピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Ｉピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止してH.264 AVC/MVCによって符号化して得られた基本ストリームと、前記第２のビデオストリームを、Anchorピクチャから、復号順で未来の、次のAnchorピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Anchorピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止するとともに、該単位を構成するピクチャの数を、対応する前記基本ストリームの単位を構成するピクチャの数と一致させるようにH.264 AVC/MVCによって符号化して得られた拡張ストリームと、前記Ｉピクチャの表示時刻と前記基本ストリーム上の位置とを対応付けた第１のテーブル情報と、前記Anchorピクチャの表示時刻と前記拡張ストリーム上の位置とを対応付けた第２のテーブル情報とを記録媒体から読み出す読み出し部と、前記記録媒体から読み出された前記基本ストリームを、前記第１のテーブル情報に基づいて所定のＩピクチャから復号し、前記拡張ストリームを、前記第２のテーブル情報に基づいて、前記所定のＩピクチャと表示時刻が同じAnchorピクチャから復号する復号部とを備える。

固定値として割り当てられた第１のPIDに基づいて、前記記録媒体から読み出された第１のトランスポートストリームから前記基本ストリームを構成するパケットを分離する第１の分離部と、固定値として割り当てられた第２のPIDに基づいて、前記記録媒体から読み出された第２のトランスポートストリームから前記拡張ストリームを構成するパケットを分離する第２の分離部と、前記第１の分離部により分離された前記基本ストリームのパケットを記憶する第１のバッファと、前記第２の分離部により分離された前記拡張ストリームのパケットを記憶する第２のバッファとをさらに設けることができる。この場合、前記復号部には、前記第１のバッファにパケットが記憶された前記基本ストリームを復号し、前記第２のバッファにパケットが記憶された前記拡張ストリームを復号させることができる。

復号して得られた前記基本ストリームを構成する各ピクチャのデータと前記拡張ストリームを構成する各ピクチャのデータを記憶する第３のバッファと、前記第３のバッファに記憶された前記基本ストリームを構成する各ピクチャのデータを左目用と右目用のうちの一方のピクチャのデータとして出力し、前記第３のバッファに記憶された前記拡張ストリームを構成する各ピクチャのデータを左目用と右目用のうちの他方のピクチャのデータとして出力する出力部とをさらに設けることができる。

本技術によれば、例えばH.264 AVC/MVCプロファイル規格で符号化して得られたDependent view videoのストリームのGOP構造を定義してBD等の記録媒体に記録させ、またはGOP構造が定義された記録媒体を再生することができる。

本技術を適用した再生装置を含む再生システムの構成例を示す図である。撮影の例を示す図である。 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が指すソースパケットのデータ構造の例を示す図である。 EP_mapに含まれるサブテーブルを示す図である。エントリPTS_EP_coarseおよびエントリPTS_EP_fineのフォーマットの例を示す図である。エントリSPN_EP_coarseおよびエントリSPN_EP_fineのフォーマットの例を示す図である。 Access Unitの構成を示す図である。記録装置の構成例を示すブロック図である。図５２のMVCエンコーダの構成例を示すブロック図である。記録装置の記録処理について説明するフローチャートである。図５４のステップＳ２において行われる符号化処理について説明するフローチャートである。再生装置の構成例を示すブロック図である。図５６のMVCデコーダの構成例を示すブロック図である。再生装置の再生処理について説明するフローチャートである。図５８のステップＳ３２において行われるデコード処理について説明するフローチャートである。図５８のステップＳ３２において行われるデコード処理について説明する、図５９に続くフローチャートである。再生装置のランダムアクセス再生処理について説明するフローチャートである。 Base view videoストリームとDependent view videoストリームの状態を示す図である。 Base view videoストリームにおけるHRD parametersの符号化位置の例を示す図である。図６３に示す位置にHRD parametersを符号化した場合の記述形式を示す図である。 Base view videoストリームにおけるmax_dec_frame_bufferingの符号化位置の例を示す図である。図６５に示す位置にmax_dec_frame_bufferingを符号化した場合の記述形式を示す図である。 Dependent view videoストリームにおけるHRD parametersの符号化位置の例を示す図である。図６７に示す位置にHRD parametersを符号化した場合の記述形式を示す図である。図６７に示す位置にHRD parametersを符号化した場合の他の記述形式を示す図である。 Dependent view videoストリームにおけるmax_dec_frame_bufferingの符号化位置の例を示す図である。図７０に示す位置にmax_dec_frame_bufferingを符号化した場合の記述形式を示す図である。図７０に示す位置にmax_dec_frame_bufferingを符号化した場合の他の記述形式を示す図である。記録装置の記録処理について説明するフローチャートである。再生装置の再生処理について説明するフローチャートである。パラメータの設定の例を示す図である。パラメータの設定の他の例を示す図である。 MVCデコーダの他の構成例を示すブロック図である。パラメータの設定のさらに他の例を示す図である。パラメータの設定の例を示す図である。パラメータの設定の他の例を示す図である。パラメータの設定のさらに他の例を示す図である。検証装置を示す図である。 HRDの機能構成を示す図である。検証の例を示す図である。検証の他の例を示す図である。 view_typeの記述の例を示す図である。 view_typeの記述の他の例を示す図である。コンピュータのハードウェアの構成例を示すブロック図である。

＜第１の実施の形態＞
［再生システムの構成例］
図１は、本技術を適用した再生装置１を含む再生システムの構成例を示す図である。

図１に示すように、この再生システムは、再生装置１と表示装置３が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が記述される。view_typeは、例えば図１１のAppInfoPlayList()に記述される。

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の最後までのバイト数を表す。

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が含まれる。

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)₁、MB(Multiplexing Buffer)₁を介してVSB₁に記憶される。VSB₁には、Base view videoのエレメンタリストリームのデータが記憶される。

スイッチ１０７には、PIDフィルタ１０４から出力されたパケットだけでなく、図２１のPIDフィルタ１０５においてSub TSから抽出されたDependent view videoストリームを構成するパケットも供給される。

スイッチ１０７は、PIDフィルタ１０４からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。

また、スイッチ１０７は、PIDフィルタ１０５からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。

D videoバッファ１０８に出力されたパケットは、TB₂、MB₂を介してVSB₂に記憶される。VSB₂には、Dependent view videoのエレメンタリストリームのデータが記憶される。

スイッチ１０９は、B videoバッファ１０６のVSB₁に記憶されたBase view videoのパケットと、D videoバッファ１０８のVSB₂に記憶された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バッファ１０６のVSB₁から読み出されたパケットのDTS₁と、直後のタイミングでD videoバッファ１０８のVSB₂から読み出されたパケットのDTS₂は、図２２に示すように同じ時刻を表すものになる。

スイッチ１０９は、B videoバッファ１０６のVSB₁から読み出したBase view videoのパケット、または、D videoバッファ１０８のVSB₂から読み出した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のデータを含むユニットである。Dependent Unit＃２はDependent view videoのデータを含むユニットである。Access Unit（Dependent viewの場合、Dependent Unit）はピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。

H.264 AVC/MVCプロファイル規格でのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなユニットに格納される。H.264 AVC/MVCプロファイル規格でのエンコード時、Dependent Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。

図２５の例の場合、Dependent Unit＃２については、そのユニットに格納されるview componentがDependent view videoであることをview_idから識別することが可能になる。

一方、図２５に示すように、Access Unit＃１に格納されたview componentであるBase view videoにはMVCヘッダが付加されていない。

上述したようにBase view videoストリームは2D再生にも用いられるデータである。従って、それとの互換性を確保するために、Base view videoにはエンコード時にMVCヘッダが付加されない。あるいは、一度付加されたMVCヘッダが除去される。記録装置によるエンコードについては後述する。

再生装置１には、MVCヘッダが付加されていないview componentについては、そのview_idが0であり、view componentをBase view videoであるとして認識するように定義（設定）されている。Dependent view videoには、0以外の値がview_idとしてエンコード時に設定される。

これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。

図２４のスイッチ１１１においては、Base view videoのパケットをデコードして得られたデータとDependent view videoのパケットをデコードして得られたデータの識別が、このようなview_idに基づいて行われるようにしてもよい。

［第３の例］
図２６は、ビデオストリームの処理を行うさらに他の構成を示す図である。

図２６の例においては、図２４の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プレーン生成部１１７に出力する。

D IGデコーダ１２０は、スイッチ１８１から供給されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。Base IGストリームとDependent IGストリームが１つのデコーダによりデコードされるようにしてもよい。

スイッチ１８２は、Base PGストリームを構成するパケットをB PGデコーダ１２４に出力し、Dependent PGストリームを構成するパケットをD PGデコーダ１２８に出力する。スイッチ１８２は、図２１のスイッチ１２２とスイッチ１２６の機能を有する。

B PGデコーダ１２４は、スイッチ１８２から供給されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。

D PGデコーダ１２８は、スイッチ１８２から供給されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。Base PGストリームとDependent PGストリームが１つのデコーダによりデコードされるようにしてもよい。

ビデオデコーダ１１０は、スイッチ１０９（図２２等）から供給されたパケットを順次デコードし、デコードして得られたBase view 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プレーン生成部１６１に出力する。

合成部１３０は、スイッチ２０１、スイッチ２０２、加算部２０３乃至２０６から構成される。

スイッチ２０１は、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の各ピクチャのデータを格納したDependent Unitからなる。

Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Dependent 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の各ピクチャのデータを格納したDependent Unitからなる。

分離部４１３は、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ストリームを構成する各Dependent 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のデータを格納するDependent Unitに、１以上のview_idが設定されたMVCヘッダが含まれるようにすることができる。

図３４は、Access Unitをデコードする再生装置１側の構成を示す図である。

図３４においては、図２２等を参照して説明したスイッチ１０９とビデオデコーダ１１０が示されている。Base view videoのデータを含むAccess Unit＃１と、Dependent view videoのデータを含むDependent Unit＃２がバッファから読み出され、スイッチ１０９に供給される。

Base view videoを参照して符号化が行われているから、Dependent view videoを正しく復号するには、まず、対応するBase view videoを復号しておくことが必要になる。

H.264/MVCプロファイル規格においては、デコーダ側が、MVCヘッダに含まれるview_idを利用して各ユニットの復号順序を算出するようになされている。また、Base view videoには、そのエンコード時に、常に最小の値をview_idの値として設定することが定められている。デコーダは、最小のview_idが設定されているMVCヘッダを含むユニットから復号を開始することで、Base view videoとDependent view videoを正しい順序で復号することができるようになされている。

ところで、再生装置１のビデオデコーダ１１０に供給される、Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。

そこで、再生装置１においては、MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。

図３４のスイッチ１０９は、最小の値である0がview_idとして設定されていると認識したAccess Unit＃１をまずビデオデコーダ１１０に出力し、デコードを行わせる。

また、スイッチ１０９は、Access Unit＃１のデコードが終了した後、0より大きい固定値であるYがview_idとして設定されているユニットであるDependent Unit＃２をビデオデコーダ１１０に出力し、デコードを行わせる。Dependent 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 Pictures)構造が定義されていない。

そこで、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 Decoding 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ストリームのピクチャのうちの色を付けて示すピクチャＰ₁は、アンカーピクチャ、またはIDRピクチャである。ピクチャＰ₁のデータを含むAccess UnitにはSubsetSPSが含まれる。

図４１の例においては、白抜き矢印＃１１で示すように、ピクチャＰ₁が、Dependent view videoストリームのEP_mapにデコード開始位置として設定されている。

ピクチャＰ₁に対応するBase view videoストリームのピクチャであるピクチャＰ₁₁はIDRピクチャである。白抜き矢印＃１２で示すように、IDRピクチャであるピクチャＰ₁₁も、Base view videoストリームのEP_mapにデコード開始位置として設定されている。

ランダムアクセスやトリックプレイが指示されたことから、ピクチャＰ₁とピクチャＰ₁₁からデコードを開始する場合、最初に、ピクチャＰ₁₁のデコードが行われる。IDRピクチャであるから、他のピクチャを参照することなく、ピクチャＰ₁₁をデコードすることが可能である。

ピクチャＰ₁₁のデコードが終了したとき、次に、ピクチャＰ₁がデコードされる。ピクチャＰ₁のデコードにはデコード済みのピクチャＰ₁₁が参照される。アンカーピクチャ、またはIDRピクチャであるから、ピクチャＰ₁₁のデコードが終了していればピクチャＰ₁のデコードは可能である。

その後、Base view videoのピクチャＰ₁の次のピクチャ、Dependent view videoのピクチャＰ₁₁の次のピクチャ、・・・といったようにしてデコードが行われる。

対応するGOPの構造が同じであり、かつ、対応する位置からデコードが開始されるから、Base view videoについてもDependent view videoについても、EP_mapに設定されたピクチャ以降のピクチャを問題なくデコードすることができる。これによりランダムアクセスを実現することが可能になる。

図４１の垂直方向に示す点線より左側に並ぶピクチャはデコードされないピクチャになる。

図４２は、Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。

図４２の例においては、色を付けて示すBase view videoのIDRピクチャであるピクチャＰ₂₁がデコード開始位置としてEP_mapに設定されている。

Base view videoのピクチャＰ₂₁からデコードを開始する場合において、ピクチャＰ₂₁に対応するDependent view videoのピクチャであるピクチャＰ₃₁がアンカーピクチャではない場合を考える。GOP構造を定義していない場合、Base view videoのIDRピクチャに対応するDependent view videoのピクチャが、IDRピクチャまたはアンカーピクチャであるという保障はない。

この場合、Base view videoのピクチャＰ₂₁のデコードが終わったときであっても、ピクチャＰ₃₁をデコードすることはできない。ピクチャＰ₃₁のデコードには時間方向の参照も必要になるが、垂直方向に示す点線より左側（デコード順で前）のピクチャはデコードされていない。

ピクチャＰ₃₁をデコードすることができないことにより、ピクチャＰ₃₁を参照する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ストリームについてそれぞれ用意される。

図４８は、EP_mapに含まれるサブテーブルを示す図である。

図４８に示すように、EP_mapは、サブテーブルであるEP_coarseとEP_fineに分けられる。サブテーブルEP_coarseは、大まかな単位での検索を行うためのテーブルであり、サブテーブルEP_fineは、より精密な単位での検索を行うためのテーブルである。

図４８に示すように、サブテーブルEP_fineは、エントリPTS_EP_fineとエントリSPN_EP_fineとが対応付けられるテーブルである。サブテーブル内では、エントリのそれぞれに対して、例えば最上列を"０"として昇順にエントリ番号が与えられる。サブテーブルEP_fineにおいて、エントリPTS_EP_fineとエントリSPN_EP_fineとを合わせたデータ幅は４バイトとされる。

サブテーブルEP_coarseは、エントリref_to_EP_fine_id、エントリPTS_EP_coarseおよびエントリSPN_EP_coarseが対応付けられるテーブルである。エントリref_to_EP_fine_id、エントリPTS_EP_coarseおよびエントリSPN_EP_coarseを合わせたデータ幅は８バイトとされる。

サブテーブルEP_fineのエントリは、エントリPTS_EP_startおよびエントリSPN_EP_startのそれぞれのLSB(Least Significant Bit)側のビット情報からなる。また、サブテーブルEP_coarseのエントリは、エントリPTS_EP_startおよびエントリSPN_EP_startのそれぞれのMSB(Most Significant Bit)側のビット情報と、それに対応するサブテーブルEP_fineのテーブル中のエントリ番号からなる。このエントリ番号は、同じデータPTS_EP_startから取り出したLSB側のビット情報を持つサブテーブルEP_fineの中のエントリの番号である。

図４９は、エントリPTS_EP_coarseおよびエントリPTS_EP_fineのフォーマットの例を示す図である。

エントリPTS_EP_startはデータ長が３３ビットの値である。MSBのビットを第３２ビット、LSBのビットを第０ビットとすると、エントリPTS_EP_coarseには、エントリPTS_EP_startの第３２ビットから第１９ビットまでの１４ビットが用いられる。エントリPTS_EP_coarseにより、解像度が５．８秒で、２６．５時間までの範囲で検索が可能である。

また、エントリPTS_EP_fineには、エントリPTS_EP_startの第１９ビットから第９ビットまでの１１ビットが用いられる。エントリPTS_EP_fineにより、解像度が５．７ミリ秒で、１１．５秒までの範囲で検索が可能である。なお、第１９ビットは、エントリPTS_EP_coarseとエントリPTS_EP_fineとで共通して用いられる。また、LSB側の第０ビットから第８ビットまでの９ビットは、用いられない。

図５０は、エントリSPN_EP_coarseおよびエントリSPN_EP_fineのフォーマットの例を示す図である。

エントリSPN_EP_startはデータ長が３２ビットの値である。MSBのビットを第３１ビット、LSBのビットを第０ビットとすると、エントリSPN_EP_coarseには、エントリSPN_EP_startの第３１ビットから第０ビットまでの全てのビットが用いられる。

また、エントリSPN_EP_fineには、エントリSPN_EP_startの第１６ビットから第０ビットまでの１７ビットが用いられる。

EP_coarseとEP_fineを用いて行われる、ランダムアクセス時の読み出し開始アドレスの決定の仕方については後述する。EP_mapについては、例えば特開２００５−３４８３１４号公報にも記載されている。

［運用３］
デコード時、Dependent view videoストリームのピクチャのPOC(Picture Order Count)の値として、対応するBase view videoストリームのピクチャのPOCの値と同じ値が用いられる。POCは、AVC/H.264規格において規定されるピクチャの表示順を表す値であり、デコード時に計算により求められる。

例えば、Base view videoストリームのピクチャのPOCの値が計算により求められ、求められた値により示される順に、デコーダからBase view videoストリームのピクチャが出力される。また、Base view videoストリームのピクチャが出力されるのと同時に、対応するDependent view videoストリームのピクチャが出力される。これにより、実質的に、Base view videoストリームのピクチャのPOCの値と同じ値が、Dependent view videoストリームのピクチャのPOCの値として用いられることになる。

また、Base view videoストリームとDependent view videoストリームを構成する各ピクチャのデータにはSEI(Supplemental Enhancement Information)が付加される。SEIは、H.264/AVCで規定される、デコードに関する補助的な情報を含む付加情報である。

SEIのうちの１つであるPicture Timing SEIには、デコード時のCPB(Coded Picture Buffer)からの読み出し時刻、DPBからの読み出し時刻などの時刻情報が含まれる。また、表示時刻の情報、ピクチャ構造の情報などが含まれる。

図５１は、Access Unitの構成を示す図である。

図５１に示すように、Base view videoストリームの１ピクチャのデータを含むBase view videoのAccess Unitと、Dependent view videoストリームの１ピクチャのデータを含むDependent view videoのDependent Unitは同じ構成を有する。１つのユニットは、各ユニットの境界を示すデリミタ、SPS、PPS、SEI、ピクチャデータから構成される。

符号化時、Base view videoストリームのピクチャに付加するPicture Timing SEIと、Dependent view videoストリームのピクチャに付加するPicture Timing SEIは統一して運用される。

例えば、Base view videoストリームの符号化順で１番目のピクチャに、CPBからの読み出し時刻がT1であることを表すPicture Timing SEIが付加された場合、Dependent view videoストリームの符号化順で１番目のピクチャにも、CPBからの読み出し時刻がT1であることを表すPicture Timing SEIが付加される。

すなわち、Base view videoストリームとDependent view videoストリームの各ピクチャには、符号化順、または復号順で対応するピクチャ同士、同じ内容のPicture Timing SEIが付加される。

これにより、再生装置１は、同じPicture Timing SEIが付加されているview componentを、復号順で対応するview componentとして処理することが可能になる。

Picture Timing SEIは、Base view videoとDependent view videoのエレメンタリストリームに含まれるものであり、再生装置１においてはビデオデコーダ１１０により参照される。

ビデオデコーダ１１０は、エレメンタリストリームに含まれる情報に基づいて、対応するview componentを識別することが可能になる。また、ビデオデコーダ１１０は、Picture Timing SEIに基づいて正しい復号順で、デコード処理を行うことが可能になる。

対応するview componentを識別するためにPlayListなどを参照する必要がないため、System Layerや、それ以上のLayerに問題が起きた場合の対処が可能になる。また、問題が起きたLayerに依存しないデコーダ実装も可能になる。

［記録装置の構成］
図５２は、以上のような運用に従って符号化を行い、Base view videoストリームとDependent view videoストリームを記録媒体に記録する記録装置の構成例を示すブロック図である。

図５２の記録装置５０１においては、Base view videoストリームが生成されるとともに、Dependent view videoストリームとしてD1 view videoのストリームが生成される。
すなわち、記録装置５０１においては、図３を参照して説明したようなDepthの情報は生成されない。

図５２に示すように、記録装置５０１は、情報生成部５１１、MVCエンコーダ５１２、および記録部５１３から構成される。情報生成部５１１は、上述した図２９のデータエンコーダ３１５に対応し、MVCエンコーダ５１２は、図２９のビデオエンコーダ３１１に対応する。L画像データとR画像データはMVCエンコーダ５１２に入力される。

情報生成部５１１は、プレイリストファイル、Base view video用のEP_mapを含むClip Informationファイル、Dependent view video用のEP_mapを含むClip Informationファイルからなるデータベース情報を生成する。情報生成部５１１によるデータベース情報の生成は、記録装置５０１のユーザ（コンテンツ制作者）による入力に従って行われる。情報生成部５１１は、生成したデータベース情報を記録部５１３に出力する。

また、情報生成部５１１は、Base view videoの各ピクチャに付加する図５１のSPS、PPS、SEI等のBase view video用の付加情報と、Dependent view videoの各ピクチャに付加するSPS、PPS、SEI等のDependent view video用の付加情報を生成する。情報生成部５１１により生成されるBase view video用の付加情報とDependent view video用の付加情報には、それぞれPicture Timing SEIが含まれる。情報生成部５１１は、生成した付加情報をMVCエンコーダ５１２に出力する。

MVCエンコーダ５１２は、L画像データとR画像データをH.264 AVC/MVCプロファイル規格に従って符号化し、L画像データを符号化して得られたBase view videoの各ピクチャのデータと、R画像データを符号化して得られたDependent view videoの各ピクチャのデータを生成する。

また、MVCエンコーダ５１２は、Base view videoの各ピクチャのデータに情報生成部５１１により生成されたBase view video用の付加情報を付加することによってBase view videoストリームを生成する。同様に、MVCエンコーダ５１２は、Dependent view videoの各ピクチャのデータに情報生成部５１１により生成されたDependent view video用の付加情報を付加することによってDependent view videoストリームを生成する。

MVCエンコーダ５１２は、生成したBase view videoストリームとDependent view videoストリームを記録部５１３に出力する。

記録部５１３は、情報生成部５１１から供給されたデータベース情報と、MVCエンコーダ５１２から供給されたBase view videoストリームとDependent view videoストリームをBD等の記録媒体に記録する。記録部５１３によりデータが記録された記録媒体は、例えば上述した光ディスク２として再生側の装置に提供される。

なお、記録部５１３においては、Base view videoストリームとDependent view videoストリームを記録する前に各種の処理が行われる。例えば、Base view videoストリームとDependent view videoストリームを同じTSに、またはそれぞれ他のデータとともに異なるTSに多重化する処理、Base view videoのAccess UnitからMVCヘッダを除去する処理、Base view videoストリームとDependent view videoストリームをソースパケットに分割するパケット化処理などが行われる。

図５３は、図５２のMVCエンコーダ５１２の構成例を示すブロック図である。

図５３に示すように、MVCエンコーダ５１２は、Base view videoエンコーダ５２１とDependent view videoエンコーダ５２２から構成される。L画像データはBase view videoエンコーダ５２１とDependent view videoエンコーダ５２２に入力され、R画像データはDependent view videoエンコーダ５２２に入力される。R画像データがBase view videoエンコーダ５２１に入力され、Base view videoとしてエンコードされるようにしてもよい。

Base view videoエンコーダ５２１は、L画像データを例えばH.264 AVCの規格に従って符号化する。また、Base view videoエンコーダ５２１は、符号化して得られた各ピクチャにBase view video用の付加情報を付加し、Base view videoストリームとして出力する。

Dependent view videoエンコーダ５２２は、L画像データを適宜参照し、R画像データをH.264 AVC/MVCプロファイル規格に従って符号化する。また、Dependent view videoエンコーダ５２２は、符号化して得られた各ピクチャにDependent view video用の付加情報を付加し、Dependent view videoストリームとして出力する。

［記録装置の動作］
ここで、図５４のフローチャートを参照して、記録装置５０１の記録処理について説明する。

ステップＳ１において、情報生成部５１１は、プレイリストファイルとClip Informationファイルからなるデータベース情報と、L画像データとR画像のそれぞれのピクチャに付加する付加情報とを生成する。

ステップＳ２において、MVCエンコーダ５１２により符号化処理が行われる。符号化処理によって生成されたBase view videoストリームとDependent view videoストリームは記録部５１３に供給される。

ステップＳ３において、記録部５１３は、情報生成部５１１により生成されたデータベース情報と、MVCエンコーダ５１２により生成されたBase view videoストリームとDependent view videoストリームを記録媒体に記録させる。その後、処理は終了される。

次に、図５５のフローチャートを参照して、図５４のステップＳ２において行われる符号化処理について説明する。

ステップＳ１１において、Base view videoエンコーダ５２１は、入力されたL画像のうちの１つのピクチャ（１フレーム）を符号化対象のピクチャとして選択する。

ステップＳ１２において、Base view videoエンコーダ５２１は、符号化対象のL画像をＩピクチャまたはIDRピクチャとして符号化するか否かを判定する。１GOPを構成するピクチャの数、１GOPに含まれるＩピクチャまたはIDRピクチャの数などの符号化条件が設定されている場合、符号化対象のL画像のピクチャタイプは、例えば符号化順に並べたときのピクチャの位置に応じて定まる。

ＩピクチャまたはIDRピクチャとして符号化するとステップＳ１２において判定した場合、ステップＳ１３において、Base view videoエンコーダ５２１は、符号化対象のL画像のピクチャタイプをＩピクチャまたはIDRピクチャとして決定する。

ステップＳ１４において、Dependent view videoエンコーダ５２２は、入力されたR画像のうち、ピクチャタイプがＩピクチャまたはIDRピクチャとしてステップＳ１３において決定されたL画像に対応する１つのピクチャを検出する。上述したように、表示順、符号化順で各ピクチャを並べたときに同じ時刻、同じ位置にあるL画像とR画像が対応するピクチャになる。

ステップＳ１５において、Dependent view videoエンコーダ５２２は、検出したR画像のピクチャタイプをAchorピクチャとして決定する。

一方、符号化対象のL画像をＩピクチャまたはIDRピクチャとして符号化しないとステップＳ１２において判定した場合、ステップＳ１６において、Base view videoエンコーダ５２１は、符号化対象のL画像の位置に応じてピクチャタイプを決定する。

ステップＳ１７において、Dependent view videoエンコーダ５２２は、入力されたR画像のうち、ピクチャタイプがステップＳ１６において決定されたL画像に対応する１つのピクチャを検出する。

ステップＳ１８において、Dependent view videoエンコーダ５２２は、検出したR画像のピクチャタイプとして、いま符号化対象として選択されているL画像の次に出力が可能になるようなタイプを決定する。

ステップＳ１９において、Base view videoエンコーダ５２１は、決定したピクチャタイプに従って符号化対象のL画像を符号化する。また、Dependent view videoエンコーダ５２２は、決定したピクチャタイプに従って、ステップＳ１４またはＳ１７において検出したR画像を符号化する。

ステップＳ２０において、Base view videoエンコーダ５２１は、符号化して得られたBase view videoのピクチャに付加情報を付加する。また、Dependent view videoエンコーダ５２２は、符号化して得られたDependent view videoのピクチャに付加情報を付加する。

ステップＳ２１において、Base view videoエンコーダ５２１は、符号化対象としていま選択しているL画像が最後のピクチャであるか否かを判定する。

符号化対象としていま選択しているL画像が最後のピクチャではないとステップＳ２１において判定された場合、ステップＳ１１に戻り、符号化対象のピクチャを切り替えて以上の処理が繰り返される。いま選択しているL画像が最後のピクチャであるとステップＳ２１において判定された場合、図５４のステップＳ２に戻り、それ以降の処理が行われる。

以上の処理により、L画像のデータとR画像のデータを、符号化後のBase view videoストリーム、Dependent view videoストリームにおいてGOP構造が同じになるように符号化することが可能になる。

また、Base view videoのピクチャと、対応するDependent view videoのピクチャに、それぞれ同じ内容の付加情報を付加することが可能になる。

［再生装置の構成］
図５６は、記録装置５０１によりデータが記録された記録媒体を再生する再生装置の構成例を示すブロック図である。

図５６に示すように、再生装置５０２は、取得部５３１、制御部５３２、MVCデコーダ５３３、および出力部５３４から構成される。取得部５３１は例えば図２０のディスクドライブ５２に対応し、制御部５３２は図２０のコントローラ５１に対応する。MVCデコーダ５３３は図２０のデコーダ部５６の一部の構成に対応する。

取得部５３１は、制御部５３２による制御に従って、記録装置５０１によりデータが記録され、再生装置５０２に装着された記録媒体からデータを読み出す。取得部５３１は、記録媒体から読み出したデータベース情報を制御部５３２に出力し、Base view videoストリームとDependent view videoストリームをMVCデコーダ５３３に出力する。

制御部５３２は、記録媒体からのデータの読み出しなどの、再生装置５０２の全体の動作を制御する。

例えば、制御部５３２は、取得部５３１を制御して記録媒体から読み出させることによって、データベース情報を取得する。また、制御部５３２は、取得したデータベース情報に含まれる３Ｄ再生用のプレイリスト（図１３の3D_PL_typeの値が01のプレイリスト）の再生が指示された場合、プレイリストに記述されているストリームIDなどの情報を取得部５３１に供給し、Base view videoストリームとDependent view videoストリームを記録媒体から読み出させる。制御部５３２は、MVCデコーダ５３３を制御し、Base view videoストリームとDependent view videoストリームをデコードさせる。

MVCデコーダ５３３は、制御部５３２による制御に従って、Base view videoストリームとDependent view videoストリームをデコードする。MVCデコーダ５３３は、Base view videoストリームとDependent view videoストリームをデコードして得られたデータを出力部５３４に出力する。例えば、MVCデコーダ５３３は、view_type（図１４）に従って、Base view videoストリームをデコードして得られたデータをL画像データ、Dependent view videoストリームをデコードして得られたデータをR画像データとして、それぞれ出力する。

出力部５３４は、MVCデコーダ５３３から供給されたL画像データとR画像データをディスプレイに出力し、L画像とR画像を表示させる。

図５７は、MVCデコーダ５３３の構成例を示すブロック図である。

図５７に示すように、MVCデコーダ５３３は、CPB５４１、デコーダ５４２、およびDPB５４３から構成される。CPB５４１は、図２２のB videoバッファ１０６とD videoバッファ１０８を含む。デコーダ５４２は図２２のビデオデコーダ１１０に対応し、DPB５４３は図２２のDPB１５１に対応する。図示は省略しているが、CPB５４１とデコーダ５４２の間には、図２２のスイッチ１０９に対応する回路も設けられる。

CPB５４１は、取得部５３１から供給されたBase view videoストリームのデータとDependent view videoストリームのデータを記憶する。CPB５４１に記憶されたBase view videoストリームのデータは、１つのAccess Unitを構成するデータの単位でデコーダ５４２により読み出される。CPB５４１に記憶されたDependent view videoストリームのデータも同様に、１つのDependent Unitを構成するデータの単位でデコーダ５４２により読み出される。

デコーダ５４２は、CPB５４１から読み出したデータをデコードし、デコードして得られたBase view video、Dependent view videoの各ピクチャのデータをDPB５４３に出力する。

DPB５４３は、デコーダ５４２から供給されたデータを記憶する。DPB５４３に記憶されたBase view video、Dependent view videoの各ピクチャのデータは、デコード順で後のピクチャをデコードするときにデコーダ５４２により適宜参照される。DPB５４３に記憶された各ピクチャのデータは、Picture Timing SEIにより表される各ピクチャの表示時刻などに従って出力される。

［再生装置の動作］
ここで、図５８のフローチャートを参照して、再生装置５０２の再生処理について説明する。

なお、図５８においては、Base view videoストリームの処理を行った後にDependent view videoストリームの処理を行うように各ステップを示しているが、Base view videoストリームの処理とDependent view videoストリームの処理は適宜並行して行われる。Base view videoストリームとDependent view videoストリームの処理に関する他のフローチャートについても同様である。

ステップＳ３１において、取得部５３１は、再生装置５０２に装着された記録媒体からデータを読み出す。取得部５３１は、読み出したデータベース情報を制御部５３２に出力し、Base view videoストリームのデータとDependent view videoストリームのデータをMVCデコーダ５３３に出力する。

ステップＳ３２において、MVCデコーダ５３３はデコード処理を行う。

ステップＳ３３において、出力部５３４は、MVCデコーダ５３３から供給されたL画像データとR画像データをディスプレイに出力し、L画像とR画像を表示させる。その後、処理は終了される。

次に、図５９および図６０のフローチャートを参照して、図５８のステップＳ３２において行われるデコード処理について説明する。

ステップＳ４１において、CPB５４１は、Base view videoストリームのデータとDependent view videoストリームのデータを記憶する。CPB５４１に記憶されたデータは、適宜、制御部５３２により読み出される。

ステップＳ４２において、制御部５３２は、CPB５４１に記憶されたデータを参照し、Base view videoストリームのAccess Unitの境界を検出する。Access Unitの境界の検出は、例えばAccess Unitデリミタを検出することによって行われる。ある位置の境界から次の境界までのデータが１つのAccess Unitのデータとなる。１つのAccess Unitのデータには、Base view videoの１ピクチャのデータと、それに付加された付加情報が含まれる。

ステップＳ４３において、制御部５３２は、境界を検出したBase view videoの１つのAccess UnitにPicture Timing SEIが符号化されている（含まれている）か否かを判定する。

Picture Timing SEIが符号化されているとステップＳ４３において判定した場合、ステップＳ４４において、制御部５３２はPicture Timing SEIを読み出す。

ステップＳ４５において、制御部５３２は、読み出したPicture Timing SEIに記述されている引き出し時刻（読み出し時刻）に合わせて、境界を検出した１つのAccess Unitのデータのうちの、Base view videoのピクチャのデータをCPB５４１からデコーダ５４２に供給させる。

一方、Picture Timing SEIが符号化されていないとステップＳ４３において判定した場合、ステップＳ４６において、制御部５３２は、システム情報（DTS）に合わせて、境界を検出した１つのAccess Unitのデータのうちの、Base view videoのピクチャのデータをCPB５４１からデコーダ５４２に供給させる。

ステップＳ４７において、デコーダ５４２は、CPB５４１から供給されたデータをデコードする。Base view videoのピクチャのデコードには、適宜、DPB５４３に記憶されているデコード済みのピクチャが参照される。

ステップＳ４８において、DPB５４３は、デコードによって得られたBase view videoのピクチャのデータを記憶する。

ステップＳ４９において、制御部５３２は、デコードしたBase view videoのピクチャのPOCを計算し、記憶する。

ステップＳ５０において、制御部５３２は、Dependent view videoストリームのDependent Unitの境界を検出し、ステップＳ４２で境界を検出したBase view videoストリームのAccess Unitに対応するDependent view videoストリームのDependent Unitを検出する。

ステップＳ５１において、制御部５３２は、境界を検出したDependent view videoの１つのDependent UnitにPicture Timing SEIが符号化されているか否かを判定する。

Picture Timing SEIが符号化されているとステップＳ５１において判定した場合、ステップＳ５２において、制御部５３２はPicture Timing SEIを読み出す。

ステップＳ５３において、制御部５３２は、読み出したPicture Timing SEIに記述されている引き出し時刻に合わせて、境界を検出した１つのDependent Unitのデータのうちの、Dependent view videoのピクチャのデータをCPB５４１からデコーダ５４２に供給させる。

一方、Picture Timing SEIが符号化されていないとステップＳ５１において判定した場合、ステップＳ５４において、制御部５３２は、システム情報に合わせて、境界を検出した１つのDependent Unitのデータのうちの、Dependent view videoのピクチャのデータをCPB５４１からデコーダ５４２に供給させる。

なお、Base view video用のデコーダとDependent view video用のデコーダがそれぞれMVCデコーダ５３３に設けられている場合、CPB５４１に記憶されているDependent view videoのピクチャのデータは、Base view videoのピクチャのデータがCPB５４１からBase view video用のデコーダに供給されるタイミングと同じタイミングでDependent view video用のデコーダに供給される。

ステップＳ５５において、デコーダ５４２は、CPB５４１から供給されたデータをデコードする。Dependent view videoのピクチャのデコードには、適宜、DPB５４３に記憶されているデコード済みのBase view videoのピクチャ、Dependent view videoのピクチャが参照される。

ステップＳ５６において、DPB５４３は、デコードによって得られたDependent view videoのピクチャのデータを記憶する。以上の処理が繰り返されることによって、DPB５４３には、POCの値が計算された複数のBase view videoのピクチャと、対応するDependent view videoのピクチャが記憶される。Dependent view videoのピクチャについては、POCの値の計算は行われない。

ステップＳ５７において、制御部５３２は、DPB５４３に記憶されているBase view videoのピクチャの中でPOCの値が最も小さいピクチャをDPB５４３から出力させるとともに、同じタイミングで、対応するDependent view videoのピクチャをDPB５４３から出力させる。DPB５４３から出力されたピクチャは出力部５３４に供給される。

Base view videoのピクチャの出力は、そのピクチャにPicture Timing SEIが付加されている場合、Picture Timing SEIに記述されている表示時刻に合わせて行われる。一方、Picture Timing SEIが付加されていない場合、システム情報（PTS）により表される表示時刻に合わせて行われる。

ステップＳ５８において、制御部５３２は、Base view videoとDependent view videoの全てのピクチャの出力が終了したか否かを判定する。制御部５３２は、全てのピクチャの出力が終了していないとステップＳ５８において判定した場合、ステップＳ４１に戻り、以上の処理を繰り返し行う。全てのピクチャの出力が終了したとステップＳ５８において判定した場合、図５８のステップＳ３２に戻り、それ以降の処理が行われる。

以上の処理により、GOP構造が同じになるようにして符号化されるとともに、各ピクチャに同じ付加情報が付加されたBase view videoストリームとDependent view videoストリームをデコードすることが可能になる。

次に、図６１のフローチャートを参照して、EP_mapを用いて行われる再生装置５０２のランダムアクセス再生の処理について説明する。

ステップＳ７１において、制御部５３２は、取得部５３１を制御し、Base view videoストリームのClipとDependent view videoストリームのClipのそれぞれのClip Informationファイルを読み出す。また、制御部５３２は、Base view video用のEP_mapとDependent view video用のEP_mapを取得する。上述したように、EP_mapは、Base view video用のものとDependent view video用のものがそれぞれ用意される。

ステップＳ７２において、制御部５３２は、ユーザによる操作などに基づいてランダムアクセス再生の開始時刻を表すPTSを取得する。例えば、ビデオストリームに設定されたチャプタがメニュー画面から選択された場合、選択されたチャプタのPTSが取得される。

ステップＳ７３において、制御部５３２は、Base view video用のEP_mapより、取得した再生開始時刻のPTSに対応するSPN_EP_startが示すソースパケット番号を特定する。また、制御部５３２は、特定したソースパケット番号により識別されるソースパケットが記録されている記録媒体上のアドレスを読み出し開始アドレスとして設定する。

例えば、PTSを構成する３２ビットのうちのMSB側の１４ビットに基づいて、Base view video用のEP_mapのサブテーブルであるEP_coarseを対象として検索が行われ、PTS_EP_coarseと、対応するref_to_EP_fine_id、SPN_EP_coarseが特定される。また、特定されたref_to_EP_fine_idに基づいて、EP_fineを対象として検索が行われ、LSB側の第１０ビットからの１１ビットの値に対応するエントリPTS_EP_fineが特定される。

PTS_EP_fineに対応するSPN_EP_coarseが示すソースパケット番号が特定され、ソースパケット番号により識別されるソースパケットが記録されているアドレスが読み出し開始アドレスとして決定される。それぞれのソースパケットの記録媒体上のアドレスは、記録媒体に記録されているデータを管理するファイルシステムにより特定される。

ステップＳ７４において、制御部５３２は、Dependent view video用のEP_mapより、取得した再生開始時刻のPTSに対応するSPN_EP_startが示すソースパケット番号を特定する。PTSに対応するSPN_EP_startが示すソースパケット番号の特定も、Dependent view video用のEP_mapを構成するサブテーブルを用いて行われる。また、制御部５３２は、特定したソースパケット番号により識別されるソースパケットが記録されている記録媒体上のアドレスを読み出し開始アドレスとして設定する。

ステップＳ７５において、取得部５３１は、ステップＳ７３で設定された読み出し開始アドレスから、Base view videoストリームを構成する各ソースパケットのデータの読み出しを開始する。また、取得部５３１は、ステップＳ７４で設定された読み出し開始アドレスから、Dependent view videoストリームを構成する各ソースパケットのデータの読み出しを開始する。

読み出されたBase view videoストリームのデータとDependent view videoストリームのデータは、MVCデコーダ５３３に供給される。図５９、図６０を参照して説明した処理が行われることによって、ユーザにより指定された再生開始位置からのデコードが行われる。

ステップＳ７６において、制御部５３２は、次にサーチするか否か、すなわち、他の位置からランダムアクセス再生を開始することが指示されたか否かを判定し、指示されたと判定した場合、ステップＳ７１以降の処理を繰り返し行う。

他の位置からランダム再生を開始することが指示されていないとステップＳ７６において判定された場合、処理は終了される。

［バッファコントロール情報］
以上のように、H.264 AVC/MVCプロファイル規格では、基本となるビデオストリームであるBase view videoストリームと、Base view videoストリームを基本として符号化、復号を行うビデオストリームであるDependent view videoストリームが定義されている。

H.264 AVC/MVCプロファイル規格では、Base view videoストリームとDependent view videoストリームが１本のビデオストリームとして存在することも、それぞれ単独のビデオストリームとして存在することも許容されている。

図６２Ａは、Base view videoストリームとDependent view videoストリームが１本のビデオストリームとして存在する状態を示す図である。

図６２Ａの例においては、Base view videoストリーム全体とDependent view videoストリーム全体がそれぞれ所定の区間毎に分割され、各区間が混在するように１本のエレメンタリストリームが構成されている。図６２Ａにおいて「Ｂ」の文字を付して示す区間はBase view videoストリームの区間を表し、「Ｄ」の文字を付して示す区間はDependent view videoストリームの区間を表す。

図６２Ｂは、Base view videoストリームとDependent view videoストリームがそれぞれ単独のビデオストリームとして存在する状態を示す図である。

BD-ROM 3D規格においては、図６２Ｂに示すように、Base view videoストリームとDependent view videoストリームが、それぞれ単独のエレメンタリストリームとしてディスク上に記録されていることが求められる。また、Base view videoストリームが、H.264/AVC規格で符号化されたストリームであることが求められる。これらの制限は、3D再生に対応していないBDプレーヤによる、Base view videoストリームのみの再生（2D再生）を可能にするためである。

従って、BD-ROM 3D規格においては、H.264/AVC規格で符号化されたBase view videoストリームだけを再生した場合であっても、Base view videoストリームとDependent view videoストリームを合わせて再生した場合であっても正しく再生できるように記録装置側でストリームを符号化しておく必要がある。具体的には、バッファアンダーフローやオーバーフローが生じることがないように符号化しておく必要がある。

H.264/AVC規格においては、バッファアンダーフローなどが生じないようにするために２種類のバッファコントロール情報をストリーム中に符号化することが可能になっている。BD-ROM 3D規格においても、Base view videoストリームだけのデコードと、Base view videoストリームとDependent view videoストリームを合わせてのデコードとを想定して、バッファコントロール情報をストリーム中に符号化しておく必要がある。

ところで、BD-ROM 3D規格に対応した再生装置には、Base view videoストリームとDependent view videoストリームを１つのデコーダでデコードするものと、Base view video用とDependent view video用の２つのデコーダでデコードするものがある。BD-ROM 3D規格においてはデコーダの数までは規定されていない。

従って、BD-ROM 3D規格においては、１つのデコーダでデコードした場合であっても、２つのデコーダでデコードした場合であっても正しく再生できるように、記録装置側でバッファコントロール情報をストリーム中に符号化しておく必要がある。

以上より、記録装置においては、次のようにしてバッファコントロール情報が符号化される。

１．Base view videoストリーム中に、Base view videoストリームのみを再生した場合にそれを正しく行うことができるようにするための値が符号化される。
２．Dependent view videoストリーム中に、Dependent view videoストリームを単独デコーダ（Dependent view video用のデコーダ）で再生した場合にそれを正しく行うことができるようにするための値が符号化される。
３．Dependent view videoストリーム中に、Base view videoストリームとDependent view videoストリームを合わせて１つのデコーダで再生した場合にそれを正しく行うことができるようにするための値が符号化される。

［符号化位置の具体例］
Base view videoストリームとDependent view videoストリームには、バッファコントロール情報として、HRD parametersとmax_dec_frame_bufferingが符号化される。

HRD parametersは、CPBからデコーダに対する入力の最大ビットレートを表す情報が含まれる。CPBに対する入力の最大ビットレートを表す情報、CPBのバッファサイズを表す情報、HRDがCBR(Constant Bit Rate)であるか否かを示すフラグが含まれるようにしてもよい。

max_dec_frame_bufferingは、DPBに記憶可能なピクチャ（参照ピクチャ）の最大枚数を表す情報である。

図６３は、Base view videoストリームにおけるHRD parametersの符号化位置の例を示す図である。

図６３に示すように、HRD parametersは、Base view videoストリームを構成するそれぞれのAccess Unitに含まれるSPSの１つの情報として符号化される。図６３の例においては、SPSに含まれるVUI(Video Usability Information)の１つの情報として符号化されている。

図６３のHRD parametersは、Base view videoストリームのみを再生した場合の、デコーダに対する入力の最大ビットレートを表す。CPBとデコーダの間のバスをBase view videoストリームのデータのみの伝送に用いた場合、その伝送レートはHRD parametersにより表されるビットレート以下に制限される。

なお、図６３のAUDは図５１を参照して説明したAUデリミタに対応し、Slicesは、図６３のAccess Unitに含まれる１ピクチャのデータに対応する。

図６４は、図６３に示す位置にHRD parametersを符号化した場合のseq_parameter_set_data()（SPS）の記述形式を示す図である。

図６４に示すように、hrd_parameters()（HRD parameters）は、seq_parameter_set_data()中のvui_parameters()（VUI）の中に記述される。

図６５は、Base view videoストリームにおけるmax_dec_frame_bufferingの符号化位置の例を示す図である。

図６５に示すように、max_dec_frame_bufferingも、Base view videoストリームを構成するそれぞれのAccess Unitに含まれるSPSの１つの情報として符号化される。図６５の例においては、SPSに含まれるVUIの１つの情報として符号化されている。

図６５のmax_dec_frame_bufferingは、Base view videoストリームのみを再生した場合の、DPBに記憶可能なピクチャの最大枚数を表す。１つのDPBをBase view videoストリームのデコード済みのピクチャのみの記憶に用いた場合、DPBに記憶されるピクチャの枚数はmax_dec_frame_bufferingにより表される枚数以下に制限される。

図６６は、図６５に示す位置にmax_dec_frame_bufferingを符号化した場合のseq_parameter_set_data()の記述形式を示す図である。

図６６に示すように、max_dec_frame_bufferingは、seq_parameter_set_data()中のvui_parameters()の中に記述される。

以下、適宜、図６３に示すようにしてBase view videoストリームに符号化されているHRD parametersを第１のHRD parametersという。また、図６５に示すようにしてBase view videoストリームに符号化されているmax_dec_frame_bufferingを第１のmax_dec_frame_bufferingという。

図６７は、Dependent view videoストリームにおけるHRD parametersの符号化位置の例を示す図である。

図６７に示すように、HRD parametersは、Dependent view videoストリームを構成するそれぞれのDependent Unitに含まれるSubsetSPSの１つの情報として符号化される。図６７の例においては、SubsetSPSに含まれるSPSの１つの情報として符号化されている。

SPSの１つの情報として符号化されているHRD parametersは、Dependent view videoストリームを単独デコーダで再生した場合の、Dependent view video用のデコーダに対する入力の最大ビットレートを表す。CPBと単独デコーダの間のバスをDependent view videoストリームのデータのみの伝送に用いた場合、その伝送レートはHRD parametersにより表されるビットレート以下に制限される。

図６８は、SPSの１つの情報としてHRD parametersを符号化した場合のsubset_seq_parameter_set_data()（SubsetSPS）の記述形式を示す図である。SubsetSPSは、H.264/AVCのSPSを拡張したパラメータの記述であり、ビュー間の依存関係を表す情報などが含まれる。

図６８に示すように、hrd_parameters()は、subset_seq_parameter_set_data()中の、seq_parameter_set_data()中の、vui_parameters()の中に記述される。

図６７の例においては、SubsetSPSに含まれるMVC VUI Extの１つの情報としてもHRD parametersが符号化されている。

MVC VUI Extの１つの情報として符号化されているHRD parametersは、Base view videoストリームとDependent view videoストリームを合わせて１つのデコーダで再生した場合の、デコーダに対する入力の最大ビットレートを表す。CPBと１つのデコーダの間のバスをBase view videoストリームのデータとDependent view videoストリームのデータの伝送に用いた場合、その伝送レートはHRD parametersにより表されるビットレート以下に制限される。

図６９は、MVC VUI Extの１つの情報としてHRD parametersを符号化した場合のsubset_seq_parameter_set_data()の記述形式を示す図である。

図６９に示すように、hrd_parameters()は、subset_seq_parameter_set_data()中の、mvc_vui_parameters_extension()（MVC VUI Ext）中に記述される。

以下、適宜、図６７に示すようにしてSPSの１つの情報としてDependent view videoストリームに符号化されているHRD parameters（図６７の左側）を第２のHRD parametersという。また、MVC VUI Extの１つの情報としてDependent view videoストリームに符号化されているHRD parameters（図６７の右側）を第３のHRD parametersという。

図７０は、Dependent view videoストリームにおけるmax_dec_frame_bufferingの符号化位置の例を示す図である。

図７０に示すように、max_dec_frame_bufferingは、Dependent view videoストリームを構成するそれぞれのDependent Unitに含まれるSubsetSPSの１つの情報として符号化される。図７０の例においては、SubsetSPSに含まれるSPSの１つの情報として符号化されている。

SPSの１つの情報として符号化されているmax_dec_frame_bufferingは、Dependent view videoストリームを単独デコーダで再生した場合の、DPBに記憶可能なピクチャの最大枚数を表す。１つのDPBをDependent view videoストリームのデコード済みのピクチャのみの記憶に用いた場合、DPBに記憶されるピクチャの枚数はmax_dec_frame_bufferingにより表される枚数以下に制限される。

図７１は、SPSの１つの情報としてmax_dec_frame_bufferingを符号化した場合のsubset_seq_parameter_set_data()の記述形式を示す図である。

図７１に示すように、max_dec_frame_bufferingは、subset_seq_parameter_set_data()中の、seq_parameter_set_data()中の、vui_parameters()の中に記述される。

図７０の例においては、SEIの１つの情報としてもmax_dec_frame_bufferingが符号化されている。

SEIの１つの情報として符号化されているmax_dec_frame_bufferingは、Base view videoストリームとDependent view videoストリームを合わせて１つのデコーダで再生した場合の、DPBに記憶可能なピクチャの最大枚数を表す。１つのDPBをBase view videoストリームのデコード済みのピクチャとDependent view videoストリームのデコード済みのピクチャの記憶に用いた場合、DPBに記憶されるピクチャの枚数はmax_dec_frame_bufferingにより表される枚数以下に制限される。

図７２は、SEIの１つの情報としてmax_dec_frame_bufferingを符号化した場合のsei_message()（SEI）の記述形式を示す図である。

図７２に示すように、max_dec_frame_bufferingは、sei_message()中の、view_scalability_info()（View scalability information SEI）中に記述される。

以下、適宜、図７０に示すようにしてSPSの１つの情報としてDependent view videoストリームに符号化されているmax_dec_frame_buffering（図７０の左側）を第２のmax_dec_frame_bufferingという。また、SEIの１つの情報としてDependent view videoストリームに符号化されているmax_dec_frame_buffering（図７０の右側）を第３のmax_dec_frame_bufferingという。

このように、Base view videoストリームとDependent view videoストリームには、HRD parametersとmax_dec_frame_bufferingが３種類ずつ符号化される。

［装置の構成］
バッファコントロール情報を含むデータをBDに記録する記録装置は図５２に示す記録装置５０１と同じ構成を有する。また、BDに記録されたデータを再生する再生装置は図５６に示す再生装置５０２と同じ構成を有する。

以下、バッファコントロール情報を用いた処理を行う記録装置と再生装置の構成として図５２、図５６の構成を引用して説明する。上述した説明と重複する説明については適宜省略する。

記録装置５０１の情報生成部５１１は、プレイリストファイルとClip Informationファイルからなるデータベース情報とともに、Base view video用の付加情報と、Dependent view video用の付加情報を生成する。Base view video用の付加情報には、第１のHRD parametersと、第１のmax_dec_frame_bufferingが含まれる。また、Dependent view video用の付加情報には、第２、第３のHRD parametersと、第２、第３のmax_dec_frame_bufferingが含まれる。

情報生成部５１１は、生成したデータベース情報を記録部５１３に出力し、付加情報をMVCエンコーダ５１２に出力する。

また、MVCエンコーダ５１２は、Base view videoの各ピクチャのデータに情報生成部５１１により生成されたBase view video用の付加情報を付加することによってBase view videoストリームを生成する。Base view videoストリームにおいては、図６３に示す位置に第１のHRD parametersが符号化され、図６５に示す位置に第１のmax_dec_frame_bufferingが符号化されている。

同様に、MVCエンコーダ５１２は、Dependent view videoの各ピクチャのデータに情報生成部５１１により生成されたDependent view video用の付加情報を付加することによってDependent view videoストリームを生成する。Dependent view videoストリームにおいては、図６７に示す位置に第２、第３のHRD parametersが符号化され、図７０に示す位置に第２、第３のmax_dec_frame_bufferingが符号化されている。

記録部５１３は、情報生成部５１１から供給されたデータベース情報と、MVCエンコーダ５１２から供給されたBase view videoストリームとDependent view videoストリームをBDに記録する。記録部５１３によりデータが記録されたBDは再生装置５０２に提供される。

再生装置５０２の取得部５３１は、記録装置５０１によりデータが記録され、再生装置５０２に装着されたBDからデータを読み出す。取得部５３１は、BDから読み出したデータベース情報を制御部５３２に出力し、Base view videoストリームとDependent view videoストリームをMVCデコーダ５３３に出力する。

例えば、制御部５３２は、Base view videoストリームのみを再生する場合、Base view videoストリームから第１のHRD parametersと第１のmax_dec_frame_bufferingを読み出す。制御部５３２は、読み出した情報に基づいて、MVCデコーダ５３３によるBase view videoストリームのデコードを制御する。

また、制御部５３２は、Base view videoストリームとDependent view videoストリームを再生（3D再生）する場合、MVCデコーダ５３３が１つのデコーダを有しているときには、Dependent view videoストリームから第３のHRD parametersと第３のmax_dec_frame_bufferingを読み出す。制御部５３２は、読み出した情報に基づいて、MVCデコーダ５３３によるBase view videoストリームとDependent view videoストリームのデコードを制御する。

MVCデコーダ５３３は、制御部５３２による制御に従って、Base view videoストリームのみ、またはBase view videoストリームとDependent view videoストリームをデコードする。MVCデコーダ５３３は、デコードして得られたデータを出力部５３４に出力する。

出力部５３４は、MVCデコーダ５３３から供給された画像をディスプレイに出力し、２Ｄ画像または３Ｄ画像を表示させる。

［装置の動作］
ここで、図７３のフローチャートを参照して、記録装置５０１の記録処理について説明する。

ステップＳ１０１において、情報生成部５１１は、データベース情報と、Base view videoとDependent view videoのそれぞれのピクチャに付加するバッファコントロール情報を含む付加情報とを生成する。

ステップＳ１０２において、MVCエンコーダ５１２により符号化処理が行われる。ここでは、図５５を参照して説明した処理と同じ処理が行われる。ステップＳ１０１により生成されたバッファコントロール情報は、Base view videoとDependent view videoの各ピクチャに付加される。符号化処理によって生成されたBase view videoストリームとDependent view videoストリームは記録部５１３に供給される。

ステップＳ１０３において、記録部５１３は、情報生成部５１１により生成されたデータベース情報と、MVCエンコーダ５１２により生成されたBase view videoストリームとDependent view videoストリームをBDに記録させる。その後、処理は終了される。

次に、図７４のフローチャートを参照して、再生装置５０２の再生処理について説明する。

ステップＳ１１１において、取得部５３１は、再生装置５０２に装着されたBDからデータを読み出す。取得部５３１は、読み出したデータベース情報を制御部５３２に出力し、例えば3D再生を行う場合、Base view videoストリームのデータとDependent view videoストリームのデータをMVCデコーダ５３３に出力する。

ステップＳ１１２において、制御部５３２は、BDから読み出され、供給されたストリームのデータからバッファコントロール情報を読み出し、パラメータをMVCデコーダ５３３に設定する。後述するように、バッファコントロール情報の読み出し元になるストリームは、BDから読み出されたストリームに応じて、またはMVCデコーダ５３３の構成に応じて変わることになる。

ステップＳ１１３において、MVCデコーダ５３３は、制御部５３２により設定されたパラメータに従って、図５９、図６０を参照して説明したデコード処理を行う。

ステップＳ１１４において、出力部５３４は、MVCデコーダ５３３によりデコード処理が行われることによって得られた画像データをディスプレイに出力する。その後、処理は終了される。

［パラメータの設定の具体例］
バッファコントロール情報を用いて行われるパラメータの設定の具体例について説明する。

ここでは、Base view videoストリームのみを再生した場合のデコーダに対する入力の最大ビットレートは40Mbpsであるものとする。また、Dependent view videoストリームを単独デコーダで再生した場合のDependent view video用のデコーダに対する入力の最大ビットレートは40Mbpsであるものとする。Base view videoストリームとDependent view videoストリームを合わせて１つのデコーダで再生した場合のデコーダに対する入力の最大ビットレートは60Mbpsであるものとする。

この場合、記録装置５０１においては、第１のHRD parametersの値、第２のHRD parametersの値としていずれも40Mbpsを表す値が符号化される。第３のHRD parametersの値として60Mbpsを表す値が符号化される。

また、Base view videoストリームのみを再生した場合のDPBに記憶可能なピクチャの最大枚数は4枚であるものとする。Dependent view videoストリームを単独デコーダで再生した場合のDPBに記憶可能なピクチャの最大枚数は4枚であるものとする。Base view videoストリームとDependent view videoストリームを合わせて１つのデコーダで再生した場合のDPBに記憶可能なピクチャの最大枚数は6枚であるものとする。

この場合、記録装置５０１においては、第１のmax_dec_frame_bufferingの値、第２のmax_dec_frame_bufferingの値としていずれも4枚を表す値が符号化される。第３のmax_dec_frame_bufferingの値として6枚を表す値が符号化される。

図７５は、１つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームのみをデコードする場合の例を示す図である。

この場合、図７５に示すように、Base view videoストリームに符号化されている第１のHRD parametersと第１のmax_dec_frame_bufferingが制御部５３２により読み出される。Base view videoストリーム上に斜線を付して示すバッファコントロール情報D1は第１のHRD parametersと第１のmax_dec_frame_bufferingを表す。

また、制御部５３２により、CPB５４１からデコーダ５４２に対する入力の最大ビットレートが40Mbpsとして第１のHRD parametersに基づいて設定される。例えば、CPB５４１とデコーダ５４２の間のバスの帯域幅が40Mbps分だけ確保されることによって最大ビットレートが設定される。

さらに、制御部５３２により、DPB５４３に記憶可能なピクチャの最大枚数が4枚として第１のmax_dec_frame_bufferingに基づいて設定される。例えば、DPB５４３の記憶領域のうち、デコード済みのピクチャを4枚分だけ記憶可能な領域が確保されることによって、記憶可能なピクチャの最大枚数が設定される。

これにより、記録側で想定した通りにBase view videoストリームのデコードが１つのデコーダを用いて行われることになる。制約の範囲内でデコードできるようにBase view videoストリームが記録側で符号化されていれば、再生側のバッファが破綻するのを防ぐことが可能になる。

図７６は、１つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームとDependent view videoストリームをデコードする場合の例を示す図である。

この場合、図７６に示すように、Dependent view videoストリームに符号化されている第３のHRD parametersと第３のmax_dec_frame_bufferingが制御部５３２により読み出される。Dependent view videoストリーム上に斜線を付して示すバッファコントロール情報D2は第２のHRD parametersと第２のmax_dec_frame_bufferingを表す。また、バッファコントロール情報D3は第３のHRD parametersと第３のmax_dec_frame_bufferingを表す。

また、制御部５３２により、CPB５４１からデコーダ５４２に対する入力の最大ビットレートが60Mbpsとして第３のHRD parametersに基づいて設定される。

さらに、制御部５３２により、DPB５４３に記憶可能なピクチャの最大枚数が6枚として第３のmax_dec_frame_bufferingに基づいて設定される。

これにより、記録側で想定した通りにBase view videoストリームとDependent view videoストリームのデコードが行われることになる。制約の範囲内でデコードできるようにBase view videoストリームとDependent view videoストリームが記録側で符号化されていれば、再生側のバッファが破綻するのを防ぐことが可能になる。

図７７は、MVCデコーダ５３３の他の構成例を示すブロック図である。

図７７に示す構成のうち、図５７に示す構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。

図７７の例においては、デコーダ５４２−１とデコーダ５４２−２の２つのデコーダが設けられている。デコーダ５４２−１はBase view video用のデコーダであり、デコーダ５４２−２はDependent view video用のデコーダである。

CPB５４１に記憶されたBase view videoストリームのデータは、１つのAccess Unitを構成するデータの単位でデコーダ５４２−１により読み出される。また、CPB５４１に記憶されたDependent view videoストリームは、１つのDependent Unitを構成するデータの単位でデコーダ５４２−２により読み出される。

デコーダ５４２−１は、CPB５４１から読み出したデータをデコードし、デコードして得られたBase view videoの各ピクチャのデータをDPB５４３に出力する。

デコーダ５４２−２は、CPB５４１から読み出したデータをデコードし、デコードして得られたDependent view videoの各ピクチャのデータをDPB５４３に出力する。

このように、MVCデコーダ５３３が２つのデコーダを有している場合について説明する。

図７８は、２つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームのみをデコードする場合の例を示す図である。

この場合、図７８に示すように、Base view videoストリームに符号化されている第１のHRD parametersと第１のmax_dec_frame_bufferingが制御部５３２により読み出される。

また、制御部５３２により、CPB５４１からデコーダ５４２に対する入力の最大ビットレートが40Mbpsとして第１のHRD parametersに基づいて設定される。

さらに、制御部５３２により、DPB５４３に記憶可能なピクチャの最大枚数が4枚として第１のmax_dec_frame_bufferingに基づいて設定される。

図７８において、デコーダ５４２−２を破線で示していることは、デコーダ５４２−２において処理が行われないことを示す。

図７９は、２つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームとDependent view videoストリームをデコードする場合の例を示す図である。

この場合、図７９に示すように、Base view videoストリームに符号化されている第１のHRD parametersと、Dependent view videoストリームに符号化されている第２のHRD parametersと第３のmax_dec_frame_bufferingが制御部５３２により読み出される。

また、制御部５３２により、CPB５４１からデコーダ５４２−１に対する入力の最大ビットレートが40Mbpsとして第１のHRD parametersに基づいて設定され、CPB５４１からデコーダ５４２−２に対する入力の最大ビットレートが40Mbpsとして第２のHRD parametersに基づいて設定される。

さらに、制御部５３２により、DPB５４３に記憶可能なピクチャの最大枚数が6枚として第３のmax_dec_frame_bufferingに基づいて設定される。DPB５４３はBase view videoとDependent view videoとで共通に用いられるから、DPB５４３に記憶可能なピクチャの最大枚数を設定するためのパラメータとして第３のmax_dec_frame_bufferingが用いられる。

図８０は、２つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームとDependent view videoストリームをデコードする場合の他の例を示す図である。

図８０のMVCデコーダ５３３には、CPB５４１とDPB５４３についても、それぞれ、Base view video用のものとDependent view video用のものが設けられている。

この場合、図８０に示すように、Base view videoストリームに符号化されている第１のHRD parametersと第１のmax_dec_frame_bufferingが制御部５３２により読み出される。また、Dependent view videoストリームに符号化されている第２のHRD parametersと第２のmax_dec_frame_bufferingが制御部５３２により読み出される。

制御部５３２により、Base view video用のCPBであるCPB５４１−１からデコーダ５４２−１に対する入力の最大ビットレートが40Mbpsとして第１のHRD parametersに基づいて設定される。また、Dependent view video用のCPBであるCPB５４１−２からデコーダ５４２−２に対する入力の最大ビットレートが40Mbpsとして第２のHRD parametersに基づいて設定される。

さらに、制御部５３２により、Base view video用のDPBであるDPB５４３−１に記憶可能なピクチャの最大枚数が４枚として第１のmax_dec_frame_bufferingに基づいて設定される。また、Dependent view video用のDPBであるDPB５４３−２に記憶可能なピクチャの最大枚数が４枚として第２のmax_dec_frame_bufferingに基づいて設定される。

図８１は、２つのデコーダを有するMVCデコーダ５３３において、Base view videoストリームとDependent view videoストリームをデコードする場合のさらに他の例を示す図である。

図８１のMVCデコーダ５３３には、CPBについては、Base view video用のものとDependent view video用のものが設けられているが、DPBは、Base view videoとDependent view videoとで共通して用いられる。また、Base view video用のCPBであるCPB５４１−１とデコーダ５４２−１の間のデータの伝送、Dependent view video用のCPBであるCPB５４１−２とデコーダ５４２−２の間のデータの伝送は、同じバスを介して行われる。

この場合、図８１に示すように、Dependent view videoストリームに符号化されている第３のHRD parametersと第３のmax_dec_frame_bufferingが制御部５３２により読み出される。

また、制御部５３２により、CPB５４１−１とデコーダ５４２−１の間のデータ伝送と、CPB５４１−２とデコーダ５４２−２の間のデータ伝送に用いられるバスの最大ビットレートが60Mbpsとして第３のHRD parametersに基づいて設定される。

［検証装置］
図８２は、記録装置５０１によりBDに記録されたビデオストリームが、再生装置５０２において正しく再生できるものであるか否かを検証する検証装置を示す図である。

図８２の検証装置５５１はコンピュータにより構成される。検証装置５５１に対しては、BDから読み出されたビデオストリームが入力される。

検証装置５５１にビデオストリームとして入力されるBase view videoストリームには、第１のHRD parametersと第１のmax_dec_frame_bufferingが符号化されている。また、Dependent view videoストリームには、第２、第３のHRD parametersと、第２、第３のmax_dec_frame_bufferingが符号化されている。

検証装置５５１においては、CPUにより所定のプログラムが実行されることによって制御部５５１Ａが実現される。制御部５５１Ａは、入力されたビデオストリームが、再生装置５０２において正しく再生できるものであるか否かを検証し、検証結果を表す情報を出力する。検証結果は例えばディスプレイに表示され、検証装置５５１を用いて検証を行うユーザにより確認される。

また、検証装置５５１においては、CPUにより所定のプログラムが実行されることによってHRD(Hypothetical Reference Decoder)が実現される。HRDは、再生装置５０２のMVCデコーダ５３３を仮想的に再現したものである。HRDの機能構成を図８３に示す。

図８３に示すように、HRD５６１は、CPB５７１、デコーダ５７２、およびDPB５７３から構成される。

CPB５７１は、入力されたBase view videoストリームのデータとDependent view videoストリームのデータを記憶する。CPB５７１に記憶されたBase view videoストリームのデータは、１つのAccess Unitを構成するデータの単位でデコーダ５７２により読み出される。CPB５７１に記憶されたDependent view videoストリームのデータも同様に、１つのDependent Unitを構成するデータの単位でデコーダ５７２により読み出される。

デコーダ５７２は、CPB５７１から読み出したデータをデコードし、デコードして得られたBase view video、Dependent view videoの各ピクチャのデータをDPB５７３に出力する。

DPB５７３は、デコーダ５７３から供給されたデータを記憶する。DPB５７３に記憶されたBase view video、Dependent view videoの各ピクチャのデータは、Picture Timing SEIにより表される各ピクチャの表示時刻などに従って出力される。

検証の具体例について説明する。

上述した例と同様に、第１、第２、第３のHRD parametersの値として、それぞれ、40Mbps、40Mbps、60Mbpsを表す値が符号化されているものとする。また、第１、第２、第３のmax_dec_frame_bufferingの値として、それぞれ、4枚、4枚、6枚を表す値が符号化されているものとする。

図８３は、Base view videoストリームのみをデコードする場合の例を示す図である。

この場合、図８３に示すように、Base view videoストリームに符号化されている第１のHRD parametersと第１のmax_dec_frame_bufferingが制御部５５１Ａにより読み出される。

また、制御部５５１Ａにより、CPB５７１からデコーダ５７２に対する入力の最大ビットレートが40Mbpsとして第１のHRD parametersに基づいて設定される。さらに、制御部５５１Ａにより、DPB５７３に記憶可能なピクチャの最大枚数が4枚として第１のmax_dec_frame_bufferingに基づいて設定される。

この状態で、Base view videoストリームのデコードを正しく行うことができるか否かが制御部５５１Ａにより検証され、検証結果を表す情報が出力される。デコードを正しく行うことができると判断された場合、入力されたBase view videoストリームは、それに符号化されている第１のHRD parametersと第１のmax_dec_frame_bufferingに基づいて、図７５、図７８、図８０を参照して説明したようにして正しく再生できるストリームであることになる。

図８４は、Dependent view videoストリームのみをDependent view video用のデコーダでデコードする場合の例を示す図である。

この場合、図８４に示すように、Dependent view videoストリームに符号化されている第２のHRD parametersと第２のmax_dec_frame_bufferingが制御部５５１Ａにより読み出される。

また、制御部５５１Ａにより、CPB５７１からデコーダ５７２に対する入力の最大ビットレートが40Mbpsとして第２のHRD parametersに基づいて設定される。さらに、制御部５５１Ａにより、DPB５７３に記憶可能なピクチャの最大枚数が4枚として第２のmax_dec_frame_bufferingに基づいて設定される。

この状態で、Dependent view videoストリームのデコードを正しく行うことができるか否かが制御部５５１Ａにより検証され、検証結果を表す情報が出力される。デコードを正しく行うことができると判断された場合、入力されたDependent view videoストリームは、それに符号化されている第２のHRD parametersと第２のmax_dec_frame_bufferingに基づいて、図８０を参照して説明したようにしてDependent view video用のデコーダで正しく再生できるストリームであることになる。

なお、Dependent view videoストリームをデコードするにはBase view videoストリームが必要である。図８４のデコーダ５７２に対しては、Base view videoストリームのデコード済みのピクチャのデータも適宜入力され、Dependent view videoストリームのデコードに用いられる。

図８５は、Base view videoストリームとDependent view videoストリームを１つのデコーダでデコードする場合の例を示す図である。

この場合、図８５に示すように、Dependent view videoストリームに符号化されている第３のHRD parametersと第３のmax_dec_frame_bufferingが制御部５５１Ａにより読み出される。

また、制御部５５１Ａにより、CPB５７１からデコーダ５７２に対する入力の最大ビットレートが60Mbpsとして第３のHRD parametersに基づいて設定される。

さらに、制御部５５１Ａにより、DPB５７３に記憶可能なピクチャの最大枚数が6枚として第３のmax_dec_frame_bufferingに基づいて設定される。

この状態で、Base view videoストリームとDependent view videoストリームのデコードを正しく行うことができるか否かが制御部５５１Ａにより検証され、検証結果を表す情報が出力される。デコードを正しく行うことができると判断された場合、入力されたBase view videoストリームとDependent view videoストリームは、第３のHRD parametersと第３のmax_dec_frame_bufferingに基づいて、図７６を参照して説明したようにして正しく再生できるストリームであることになる。

［view_typeの位置］
以上においては、図１２を参照して説明したように、Base view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかを表すview_typeがPlayListに記述されるものとしたが、他の位置に記述されるようにしてもよい。

例えば、Base view videoストリームとDependent view videoストリームが、同じTS、またはそれぞれ異なるTSに多重化されて、放送波やネットワークを介して伝送されることも考えられる。この場合、view_typeは、例えば伝送制御情報であるPSI中や、Base view videoストリームまたはDependent view videoストリーム（エレメンタリストリーム）中に記述される。

図８６は、PSI(Program Specific Information)に含まれるPMT(Program Map Table)にview_typeを記述する場合の例を示す図である。

図８６に示すように、MVC用のdescriptorとしてMVC_video_stream_descriptor()を新たに定義し、MVC_video_stream_descriptor()の中にview_typeが記述されるようにしてもよい。なお、descriptor_tagの値として例えば65が割り当てられる。

TSを受信した再生装置１においては、PMTに記述されたview_typeの値に基づいて、TSに多重化されているBase view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが判断され、復号結果のデータの出力先を切り替えるなどの、図２４、図２６を参照して説明した処理が行われることになる。

PMTの中ではなく、SIT(Selection Information Table)などの他の位置に記述されるようにしてもよい。

図８７は、エレメンタリストリーム中にview_typeを記述する場合の例を示す図である。

図８７に示すように、SEI中のMVC_video_stream_info()の中にview_typeが記述されるようにすることも可能である。上述したように、SEIは、Base view videoストリームとDependent view videoストリームを構成する各ピクチャのデータに付加される付加情報である。view_typeを含むSEIは、Base view videoストリームとDependent view videoストリームのうちの少なくともいずれかのストリームの各ピクチャに付加される。

SEIを読み出した再生装置１においては、SEIに記述されたview_typeの値に基づいて、Base view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが判断され、復号結果のデータの出力先を切り替えるなどの、図２４、図２６を参照して説明した処理が行われることになる。

上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。

図８８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。

CPU(Central Processing Unit)７０１、ROM(Read Only Memory)７０２、RAM(Random Access Memory)７０３は、バス７０４により相互に接続されている。

バス７０４には、さらに、入出力インタフェース７０５が接続されている。入出力インタフェース７０５には、キーボード、マウスなどよりなる入力部７０６、ディスプレイ、スピーカなどよりなる出力部７０７が接続される。また、バス７０４には、ハードディスクや不揮発性のメモリなどよりなる記憶部７０８、ネットワークインタフェースなどよりなる通信部７０９、リムーバブルメディア７１１を駆動するドライブ７１０が接続される。

以上のように構成されるコンピュータでは、CPU７０１が、例えば、記憶部７０８に記憶されているプログラムを入出力インタフェース７０５及びバス７０４を介してRAM７０３にロードして実行することにより、上述した一連の処理が行われる。

CPU７０１が実行するプログラムは、例えばリムーバブルメディア７１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部７０８にインストールされる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

１再生装置，２光ディスク，３表示装置，１１ MVCエンコーダ，２１ H.264/AVCエンコーダ，２２ H.264/AVCデコーダ，２３ Depth算出部，２４ Dependent view videoエンコーダ，２５マルチプレクサ，５１コントローラ，５２ディスクドライブ，５３メモリ，５４ローカルストレージ，５５インターネットインタフェース，５６デコーダ部，５７操作入力部

Claims

２つの視点から撮影された第１のビデオストリームと第２のビデオストリームのうちの第１のビデオストリームを、Ｉピクチャから、復号順で未来の、次のＩピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Ｉピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止してH.264 AVC/MVCによって符号化して得られた基本ストリームと、
前記第２のビデオストリームを、Anchorピクチャから、復号順で未来の、次のAnchorピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Anchorピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止するとともに、該単位を構成するピクチャの数を、対応する前記基本ストリームの単位を構成するピクチャの数と一致させるようにH.264 AVC/MVCによって符号化して得られた拡張ストリームと、
前記Ｉピクチャの表示時刻と前記基本ストリーム上の位置とを対応付けた第１のテーブル情報と、
前記Anchorピクチャの表示時刻と前記拡張ストリーム上の位置とを対応付けた第２のテーブル情報と
を記録媒体から読み出す読み出し部と、
前記記録媒体から読み出された前記基本ストリームを、前記第１のテーブル情報に基づいて所定のＩピクチャから復号し、前記拡張ストリームを、前記第２のテーブル情報に基づいて、前記所定のＩピクチャと表示時刻が同じAnchorピクチャから復号する復号部と
を備える再生装置。
固定値として割り当てられた第１のPIDに基づいて、前記記録媒体から読み出された第１のトランスポートストリームから前記基本ストリームを構成するパケットを分離する第１の分離部と、
固定値として割り当てられた第２のPIDに基づいて、前記記録媒体から読み出された第２のトランスポートストリームから前記拡張ストリームを構成するパケットを分離する第２の分離部と、
前記第１の分離部により分離された前記基本ストリームのパケットを記憶する第１のバッファと、
前記第２の分離部により分離された前記拡張ストリームのパケットを記憶する第２のバッファと
をさらに備え、
前記復号部は、前記第１のバッファにパケットが記憶された前記基本ストリームを復号し、前記第２のバッファにパケットが記憶された前記拡張ストリームを復号する
請求項１に記載の再生装置。
復号して得られた前記基本ストリームを構成する各ピクチャのデータと前記拡張ストリームを構成する各ピクチャのデータを記憶する第３のバッファと、
前記第３のバッファに記憶された前記基本ストリームを構成する各ピクチャのデータを左目用と右目用のうちの一方のピクチャのデータとして出力し、前記第３のバッファに記憶された前記拡張ストリームを構成する各ピクチャのデータを左目用と右目用のうちの他方のピクチャのデータとして出力する出力部と
をさらに備える請求項２に記載の再生装置。
２つの視点から撮影された第１のビデオストリームと第２のビデオストリームのうちの第１のビデオストリームを、Ｉピクチャから、復号順で未来の、次のＩピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Ｉピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止してH.264 AVC/MVCによって符号化して得られた基本ストリームと、
前記第２のビデオストリームを、Anchorピクチャから、復号順で未来の、次のAnchorピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Anchorピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止するとともに、該単位を構成するピクチャの数を、対応する前記基本ストリームの単位を構成するピクチャの数と一致させるようにH.264 AVC/MVCによって符号化して得られた拡張ストリームと、
前記Ｉピクチャの表示時刻と前記基本ストリーム上の位置とを対応付けた第１のテーブル情報と、
前記Anchorピクチャの表示時刻と前記拡張ストリーム上の位置とを対応付けた第２のテーブル情報と
を記録媒体から読み出し、
前記記録媒体から読み出した前記基本ストリームを、前記第１のテーブル情報に基づいて所定のＩピクチャから復号し、
前記拡張ストリームを、前記第２のテーブル情報に基づいて、前記所定のＩピクチャと表示時刻が同じAnchorピクチャから復号する
ステップを含む再生方法。
２つの視点から撮影された第１のビデオストリームと第２のビデオストリームのうちの第１のビデオストリームを、Ｉピクチャから、復号順で未来の、次のＩピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Ｉピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止してH.264 AVC/MVCによって符号化して得られた基本ストリームと、
前記第２のビデオストリームを、Anchorピクチャから、復号順で未来の、次のAnchorピクチャの直前のピクチャまでの集合を単位とし、該単位内の、前記Anchorピクチャよりも表示順で未来のピクチャを、該単位より過去の単位内のピクチャから予測することを禁止するとともに、該単位を構成するピクチャの数を、対応する前記基本ストリームの単位を構成するピクチャの数と一致させるようにH.264 AVC/MVCによって符号化して得られた拡張ストリームと、
前記基本ストリームとともに読み出され、再生装置により前記基本ストリームの復号に用いられる、前記Ｉピクチャの表示時刻とストリーム上の位置とを対応付けた第１のテーブル情報と、
前記拡張ストリームとともに読み出され、前記再生装置により前記拡張ストリームの復号に用いられる、前記Anchorピクチャの表示時刻とストリーム上の位置とを対応付けた第２のテーブル情報と
を生成し、
生成した前記基本ストリーム、前記拡張ストリーム、前記第１のテーブル情報、および前記第２のテーブル情報を記録媒体に記録させる
ステップを含む記録方法。