JP4984194B2 - 記録方法 - Google Patents

Description

本技術は、記録方法に関し、特に、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにした記録方法に関する。

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

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

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

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

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

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

特開２００７−０９５２４９号公報

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

従来のBDの規格で用いられている、画像データの管理情報をそのまま用いた場合であっても、ステレオ画像のデータを再生することはできない。

本技術はこのような状況に鑑みてなされたものであり、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができるようにするものである。

本技術の記録方法は、左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報がAppInfoPlayList()に記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させるステップを含む。

本技術によれば、複数視点の映像データを所定の符号化方式で符号化して得られた基本ストリームと拡張ストリームのうちのいずれが、左画像のストリームであるのか、右画像のストリームであるのかを再生装置に判断させることができる。

本技術を適用した再生装置を含む再生システムの構成例を示す図である。 撮影の例を示す図である。 MVCエンコーダの構成例を示すブロック図である。 参照画像の例を示す図である。 AVストリームの管理の例を示す図である。 Main PathとSub Pathの構造を示す図である。 光ディスクに記録されるファイルの管理構造の例を示す図である。 PlayListファイルのシンタクスを示す図である。 図８のSubPath()のシンタクスを示す図である。 SubPath_typeの例を示す図である。 図９のSubPlayItem(i)のシンタクスを示す図である。 図８のPlayItem()のシンタクスを示す図である。 図１２のSTN_table()のシンタクスを示す図である。 application_typeの例を示す図である。 application_typeとSubPath_typeの設定の例を示す図である。 application_typeとSubPath_typeの設定の他の例を示す図である。 application_typeとSubPath_typeの設定のさらに他の例を示す図である。 Java（登録商標）アプリケーションによるstream_idの指定の例を示す図である。 PlayListファイルのシンタクスを示す図である。 図１９のreserved_for_future_useの使い方の例を示す図である。 3D_PL_typeの値の意味を示す図である。 view_typeの値の意味を示す図である。 再生装置の構成例を示すブロック図である。 図２３のデコーダ部の構成例を示す図である。 ビデオストリームの処理を行う構成を示す図である。 Access Unitの例を示す図である。 ソフト製作処理部の構成例を示すブロック図である。 ソフト製作処理部を含む構成の例を示す図である。 PMTにview_typeを記述する場合の例を示す図である。 エレメンタリストリーム中にview_typeを記述する場合の例を示す図である。 Access Unitの構成を示す図である。 コンピュータのハードウェアの構成例を示すブロック図である。

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

図１に示すように、この再生システムは、再生装置１と表示装置３がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置１には、BDなどの光ディスク２が装着される。

光ディスク２には、視点の数が２つのステレオ画像（いわゆる3D画像）を表示するために必要なストリームが記録されている。

再生装置１は、光ディスク２に記録されているストリームの3D再生に対応したプレーヤである。再生装置１は、光ディスク２に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置３に表示させる。音声についても同様に再生装置１により再生され、表示装置３に設けられるスピーカなどから出力される。

3D画像の表示の方式として様々な方式が提案されている。ここでは、3D画像の表示の方式として、以下のタイプ１の表示方式と、タイプ２の表示方式とを採用する。

タイプ１の表示方式は、3D画像のデータを左眼で観察される画像（L画像）のデータと、右眼で観察される画像（R画像）のデータとで構成し、L画像とR画像を交互に表示することで、3D画像を表示する方式である。

タイプ２の表示方式は、3D画像を生成する元になる画像である元画像のデータとDepthのデータとを用いて生成されるL画像とR画像を表示することで、3D画像を表示する方式である。タイプ２の表示方式で用いられる3D画像のデータは、元画像のデータと、元画像に与えることによってL画像とR画像を生成することができるDepthのデータとで構成される。

タイプ１の表示方式は、視聴するときにメガネが必要となる表示方式である。タイプ２の表示方式は、メガネなしで3D画像を視聴できる表示方式である。

光ディスク２には、タイプ１と２のいずれの表示方式によっても3D画像を表示することができるようなストリームが記録されている。

そのようなストリームを光ディスク２に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)プロファイル規格が採用される。

［H.264 AVC/MVC Profile］
H.264 AVC/MVCプロファイル規格では、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCプロファイル規格を単にMVCという。

図２は、撮影の例を示す図である。

図２に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。

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

図３に示すように、MVCエンコーダ１１は、H.264/AVCエンコーダ２１、H.264/AVCデコーダ２２、Depth算出部２３、Dependent view videoエンコーダ２４、およびマルチプレクサ２５から構成される。

L画像用のカメラにより撮影された映像＃１のストリームはH.264/AVCエンコーダ２１とDepth算出部２３に入力される。また、R画像用のカメラにより撮影された映像＃２のストリームはDepth算出部２３とDependent view videoエンコーダ２４に入力される。映像＃２のストリームがH.264/AVCエンコーダ２１とDepth算出部２３に入力され、映像＃１のストリームがDepth算出部２３とDependent view videoエンコーダ２４に入力されるようにしてもよい。

H.264/AVCエンコーダ２１は、映像＃１のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ２１は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ２２とマルチプレクサ２５に出力する。

H.264/AVCデコーダ２２は、H.264/AVCエンコーダ２１から供給されたAVCビデオストリームをデコードし、デコードして得られた映像＃１のストリームをDependent view videoエンコーダ２４に出力する。

Depth算出部２３は、映像＃１のストリームと映像＃２のストリームに基づいてDepthを算出し、算出したDepthのデータをマルチプレクサ２５に出力する。

Dependent view videoエンコーダ２４は、H.264/AVCデコーダ２２から供給された映像＃１のストリームと、外部から入力された映像＃２のストリームをエンコードし、Dependent view videoストリームを出力する。

Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図４に示すように、Dependent view videoには、Base view videoを参照画像とする予測符号化が許されている。例えばL画像をBase view videoとするとともにR画像をDependent view videoとして符号化を行った場合、その結果得られるDependent view videoストリームのデータ量は、Base view videoストリームのデータ量に比較して少なくなる。

なお、H.264/AVCでの符号化であるから、Base view videoについて時間方向の予測は行われている。また、Dependent view videoについても、view間の予測とともに、時間方向の予測が行われている。Dependent view videoをデコードするには、エンコード時に参照先とした、対応するBase view videoのデコードが先に終了している必要がある。

Dependent view videoエンコーダ２４は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ２５に出力する。

マルチプレクサ２５は、H.264/AVCエンコーダ２１から供給されたBase view videoストリームと、Depth算出部２３から供給されたDependent view videoストリーム（Depthのデータ）と、Dependent view videoエンコーダ２４から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは１本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。

マルチプレクサ２５は、生成したTS（MPEG2 TS）を出力する。マルチプレクサ２５から出力されたTSは、他の管理データとともに記録装置において光ディスク２に記録され、光ディスク２に記録された形で再生装置１に提供される。

タイプ１の表示方式においてBase view videoとともに用いられるDependent view videoと、タイプ２の表示方式においてBase view videoとともに用いられるDependent view video（Depth）とを区別する必要がある場合、前者をD1 view videoといい、後者をD2 view videoという。

また、Base view videoとD1 view videoを用いて行われる、タイプ１の表示方式での3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる、タイプ２の表示方式での3D再生をB-D2再生という。

再生装置１は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク２から読み出して再生する。

また、再生装置１は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク２から読み出して再生する。

さらに、再生装置１は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク２から読み出して再生する。

Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。

以下、Dependent view videoがD1 view videoである場合について主に説明する。単にDependent view videoというときは、D1 view videoを表すことになる。D2 view videoについても、D1 view videoと同様にして光ディスク２に記録され、再生される。

［アプリケーションフォーマット］
図５は、再生装置１によるAVストリームの管理の例を示す図である。

AVストリームの管理は、図５に示すようにPlayListとClipの２つのレイヤを用いて行われる。AVストリームは、光ディスク２だけでなく、再生装置１のローカルストレージに記録されていることもある。

ここでは、１つのAVストリームとそれに付随する情報であるClip Informationのペアを１つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。

AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationファイルは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。

PlayListはAVストリームの再生区間の集まりである。AVストリーム中の１つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。図５に示すように、PlayListは１つまたは複数のPlayItemにより構成される。

図５の左から１番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。

左から２番目のPlayListは１つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。

左から３番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。

例えば、左から１番目のPlayListに含まれる左側のPlayItemが再生位置としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を管理するための再生管理情報として用いられる。

PlayListの中で、１つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。

また、PlayListの中で、Main Pathに並行して、１つ以上のSubPlayItemの並びによって作られる再生パスをサブパス（Sub Path）という。

図６は、Main PathとSub Pathの構造を示す図である。

PlayListは、１つのMain Pathと１つ以上のSub Pathを持つことができる。

上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。

図６のPlayListは、３つのPlayItemの並びにより作られる１つのMain Pathと、３つのSub Pathを有している。

Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。

図６の例においては、Subpath_id=0のSub Pathには１つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには２つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには１つのSubPlayItemが含まれる。

１つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム（メイン画像データ）が含まれる。

また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで（同期して）再生されるオーディオストリームが１つ以上含まれてもよいし、含まれなくてもよい。

Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ（PG(Presentation Graphic)）のストリームが１つ以上含まれてもよいし、含まれなくてもよい。

Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが１つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。

１つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される０個以上のオーディオストリーム、０個以上のPGストリーム、および、０個以上のIGストリームが多重化されている。

また、１つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム（別ストリーム）の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。

このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開２００８−２５２７４０号公報、特開２００５−３４８３１４号公報に記載されている。

［ディレクトリ構造］
図７は、光ディスク２に記録されるファイルの管理構造の例を示す図である。

図７に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク２上には１つのrootディレクトリが作成される。rootディレクトリの下が、１つの記録再生システムで管理される範囲となる。

rootディレクトリの下にはBDMVディレクトリが置かれる。

BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。

BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。

PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、５桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。
図７に示す１つのPlayListファイルには「00000.mpls」のファイル名が設定されている。

CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、５桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。

図７の３つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。

例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。

「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。

「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。

STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、５桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、５桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。

「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。

「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。

「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。

「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。

図７に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。

［各データのシンタクス］
図８は、PlayListファイルに記述されるPlayList()のシンタクスを示す図である。

lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。

lengthの後には、１６ビットのreserved_for_future_useが用意される。

number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す１６ビットのフィールドである。図６の例の場合、PlayItemの数は３である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に０から割り振られる。例えば、図６のPlayItem_id＝０，１，２が割り振られる。

number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す１６ビットのフィールドである。図６の例の場合、Sub Pathの数は３である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に０から割り振られる。例えば、図６のSubpath_id＝０，１，２が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。

図９は、図８のSubPath()のシンタクスを示す図である。

lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。

lengthの後には、１６ビットのreserved_for_future_useが用意される。

SubPath_typeは、Sub Pathを用いて処理を行うアプリケーションの種類を示す８ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。SubPath_typeについては図１０を参照して後述する。

SubPath_typeの後には、１５ビットのreserved_for_future_useが用意される。

is_repeat_SubPathは、Sub Pathの再生方法を指定する１ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を１回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合（Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など）に利用される。

Is_repeat_SubPathの後には、８ビットのreserved_for_future_useが用意される。

number_of_SubPlayItemsは、１つのSub Pathの中にあるSubPlayItemの数（エントリー数）を示す８ビットのフィールドである。例えば、図６のSubPath_id＝０のSubPlayItemのnumber_of_SubPlayItemsは１であり、SubPath_id＝１のSubPlayItemのnumber_of_SubPlayItemsは２である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem（）が参照される。

図１０は、SubPath_typeの例を示す図である。

図１０において、「Out-of-mux」は、Sub Pathが参照するストリーム（Sub Pathを構成するSubPlayItemが参照するストリーム）と、Main Pathが参照するストリーム（Main Pathを構成するPlayItemが参照するストリーム）とが、それぞれ異なるTSに多重化されていることを表す。

反対に、「In-of-mux」は、Sub Pathが参照するストリームと、Main Pathが参照するストリームとが、同じTSに多重化されていることを表す。

SubPath_type＝０，１はreservedとされている。

SubPath_type＝２は、Audio presentation path of the Browsable slideshow（プラウザブルスライドショーのオーディオプレゼンテーションパス）とされている。

SubPath_type＝３は、Interactive graphics presentation menu（インタラクティブグラフィックスのプレゼンテーションメニュー）とされている。

SubPath_type＝４は、Text subtitle presentation path（テキスト字幕のプレゼンテーションパス）とされている。

SubPath_type＝５は、2nd Audio Presentation path（2ndオーディオストリームを参照するためのパス）とされている。SubPath_type＝５が設定されたSub Pathが参照する２番目のオーディオストリームは、例えば、映画に対する監督のコメント（音声）である。

SubPath_type＝６は、2nd Video Presentation path（2ndビデオストリームを参照するためのパス）とされている。SubPath_type＝６が設定されたSub Pathが参照する２番目のビデオストリームは、例えば、映画に対する監督のコメント（動画像）である。

SubPath_type＝７は、１本以上のES(Primary audio/PG/IG/Secondary audio)のパスや、ピクチャインピクチャプレゼンテーションパスとされている。

SubPath_type＝８〜１１は、3D再生を行うアプリケーション用のSubPathを定義する。
ここでは、SubPathが参照するDependent view videoストリームの多重化のパターンに応じて異なる値が設定される。

SubPath_type＝８は、「Out-of-mux 3D SubPath from Disc」である。これは、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されていて、かつ、Main Pathが参照するBase view videoストリームとは異なるTSに多重化されていることを表す。

SubPath_type＝９は、「In-mux 3D SubPath from Disc」である。これは、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されていて、かつ、Main Pathが参照するBase view videoストリームと同じTSに多重化されていることを表す。

SubPath_type＝１０は、「Out-of-mux 3D SubPath from Local Storage」である。これは、Sub Pathが参照するDependent view videoストリームがローカルストレージに記録されていて、かつ、Main Pathが参照するBase view videoストリームとは異なるTSに多重化されていることを表す。

後述するように、再生装置１においては、Dependent view videoストリームをサーバからダウンロードし、光ディスク２に記録されているBase view videoストリームと併せて用いることによって3D再生を行うことができるようになされている。

SubPath_type＝１１は、「In-mux 3D SubPath from Local Storage」である。これは、Sub Pathが参照するDependent view videoストリームがローカルストレージに記録されていて、かつ、Main Pathが参照するBase view videoストリームと同じTSに多重化されていることを表す。この場合、Base view videoストリームもローカルストレージに記録されていることになる。

SubPath_type＝１２乃至２５５は、reservedとされている。

このように、Dependent view videoストリームを参照するSub Pathには、それが参照するDependent view videoストリームの記録場所とTSに対する多重化のパターンを表す値が設定される。

これにより、再生装置１は、Sub Pathが参照するDependent view videoストリームが光ディスク２に記録されているのか、またはローカルストレージに記録されているのかを識別することができる。

また、再生装置１は、Sub Pathが参照するDependent view videoストリームがBase view videoストリームと同じTSに多重化されているのか、または異なるTSに多重化されているのかを識別することができる。

再生装置１は、識別結果に応じて、Base view videoストリームの読み出しの処理を切り替えることができる。

図１１は、図９のSubPlayItem(i)のシンタクスを示す図である。

lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す１６ビットの符号なし整数である。

図１１のSubPlayItem(i)は、SubPlayItemが１つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。

SubPlayItemが１つのClipを参照する場合について説明する。

Clip_Information_file_name[0]は参照するClipを表す。

Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。

is_multi_Clip_entriesはマルチクリップの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。

ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。

SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。

sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。

SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。

「if（is_multi_Clip_entries＝＝１ｂ」であり、SubPlayItemが複数のClipを参照する場合について説明する。

num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。

Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。

ref_to_STC_id[SubClip_entry_id]はSTC不連続点（システムタイムベースの不連続点）に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。

図１２は、図８のPlayItem()のシンタクスを示す図である。

lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す１６ビットの符号なし整数である。

Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むmt2sファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ５桁の数字が含まれる。

Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。

ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。

IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。

OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。

STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。

図１３は、図１２のSTN_table()のシンタクスを示す図である。

STN_table()は、PlayItemの属性として設定されている。

lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す１６ビットの符号なし整数である。lengthの後には、１６ビットのreserved_for_future_useが用意される。

number_of_video_stream_entriesは、STN_table()の中でエントリーされる（登録される）、video_stream_idが与えられるストリームの数を表す。

video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームのIDがこの記述により特定される。Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、後述するように計算により求められるようにしてもよい。

video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。

number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる１番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。

number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる２番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。

number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、DVDのサブピクチャのようなビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。

number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、インタラクティブグラフィックスストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。

後述するMain TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームのIDではなくTSのIDであることは、stream_attribute()に記述される。

図１４は、application_typeの例を示す図である。

application_typeはClip Informationファイル（ClipInfo()）に記述される。Clip Informationファイルは各Clipに１つずつ用意される。

application_type=0はreservedとされている。

application_type=１は、その記述を含むClip Informationファイルに対応するTS（Clip）がMovieアプリケーション用のTSであることを表す。

application_type=2は、その記述を含むClip Informationファイルに対応するTSがTime-based Slideshow用のTSであることを表す。

application_type=3は、その記述を含むClip Informationファイルに対応するTSがBrowsable Slideshow用のTSであることを表す。

application_type=4は、その記述を含むClip Informationファイルに対応するTSがSub Path用のBrowsable SlideshowのTSであることを表す。

application_type=5は、その記述を含むClip Informationファイルに対応するTSがSub Pathのインタラクティブグラフィックス用のTSであることを表す。

application_type=6は、その記述を含むClip Informationファイルに対応するTSがSub Pathのテキストサブタイトル（テキスト字幕データ）用のTSであることを表す。

application_type=7は、その記述を含むClip Informationファイルに対応するTSが１つ以上のESを含むSub Path用のTSであることを表す。

application_type=8は、その記述を含むClip Informationファイルに対応するTSが3D再生を行うアプリケーション用のTSであることを表す。

application_type=9-255はreservedとされている。

このように、application_typeの値として3D再生を行うアプリケーション用の値が定義されている。これにより、3D再生を行うアプリケーションは、自身が扱うTSをapplication_typeの値から識別することが可能になる。

［application_typeとSubPath_typeの設定例］
図１５は、application_typeとSubPath_typeの設定の例を示す図である。

図１５のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。このように、Dependent view videoストリームが、Base view videoストリームとともにMain TSに含まれていることもある。

光ディスク２には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームが含まれているTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。

ビデオと同様に3Dでの表示が可能になるように、PG、IGについてもBaseとDependentのそれぞれのストリームが用意されている。

それぞれのストリームをデコードして得られたPG、IGのBase viewのプレーンは、適宜、Base view videoストリームをデコードして得られたBase view videoのプレーンと合成されて表示される。同様に、PG、IGのDependent viewのプレーンは、適宜、Dependent view videoストリームをデコードして得られたDependent view videoのプレーンと合成されて表示される。

例えば、Base view videoストリームがL画像のストリームであり、Dependent view videoストリームがR画像のストリームである場合、PG、IGについても、そのBase viewのストリームはL画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはR画像のグラフィックスのストリームとなる。

一方、Base view videoストリームがR画像のストリームであり、Dependent view videoストリームがL画像のストリームである場合、PG、IGについても、そのBase viewのストリームはR画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはL画像のグラフィックスのストリームとなる。

Main TSのapplication_type（Main TSに対応するClip Informationファイルに記述されているapplication_type）の値は１である。

Main TSに含まれるBase view videoストリームは、3D再生用のアプリケーションだけでなく、上述したように通常の2D再生用のアプリケーションであるMovieアプリケーションが扱うストリームでもある。Movieアプリケーションと3D再生用のアプリケーションの両方が扱うTSにはapplication_typeの値として１が設定される。

また、Base view videoストリームと同じTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は９である。この例においては、Dependent view videoストリームは光ディスク２に記録されている。

図１６は、application_typeとSubPath_typeの設定の他の例を示す図である。

図１６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。

Main TSのapplication_typeの値は１である。

また、Base view videoストリームと同じTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は９である。この例においても、Dependent view videoストリームは光ディスク２に記録されている。

図１６のSub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが含まれている。

3D再生を行うアプリケーションが扱うTSであるから、Sub TSのapplication_typeの値は８である。

図１７は、application_typeとSubPath_typeの設定のさらに他の例を示す図である。

図１７のMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。

Main TSのapplication_typeの値は１である。

図１７のSub TSにはDependent view videoストリームが含まれている。

Base view videoストリームとは別のTSに含まれているから、Dependent view videoストリームを参照するSub PathのSubPath_typeの値は８である。この例においても、Dependent view videoストリームは光ディスク２に記録されている。

このように、3D再生を行うアプリケーションが扱うSub TSに対応するClip Informationファイルには、3D再生を行うアプリケーションが扱うTSであることを表す値がapplication_typeの値として設定される。

また、Dependent view videoストリームを参照するSub Pathには、そのDependent view videoストリームの記録場所と多重化のパターンに応じた値がSubPath_typeに設定される。

なお、BD規格においては、光ディスク２から同時に読み出すことのできるTSの数が２本までという制約が存在する。

また、Browsable Slideshowでは、上述したように、Main Pathが参照するビデオストリーム（静止画のスライドショーのストリーム）とは別に、BGMとして使用するオーディオストリームをSub Path（SubPath_type=2）によって参照することが想定されている。スライドショーの再生時には、Main Pathが参照するビデオストリームとSub Pathが参照するオーディオストリームを同時に読み出すことになる。

ここで、静止画のスライドショーの3D表示を考える。ビデオストリームとしてBase view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合、その２本のTSを読み出すことはできるが、BGMとして使用するオーディオストリームを読み出すことはできなくなる。

そこで、運用として、Browsable slideshow(Application_type=3)については、SubPath_type=9か11のみ設定可能とする。Browsable slideshowアプリケーションが扱うTSに含まれるDependent view videoストリームを参照するSub PathのSubPath_typeの値として、Base view videoストリームとは別のTSに含まれていることを表す8か10の値が設定されることはない。

このようにしてSubPath_typeの値として設定可能な値をApplication_typeに応じて制限することにより、TSを読み出すことができなくなるといった不都合を回避することができる。

［stream_idの定義］
図１３を参照して説明したように、STN_tableにおいて、PlayItemとSubPlayItemが参照するそれぞれのストリームのID（stream_id）が管理される。

STN_tableにおいて管理されるvideo_stream_idはBase view videoストリームのIDを表し、PG_txtST_stream_idはBase PGストリームのIDを表す。また、IG_stream_idはBase IGストリームのIDを表す。

ここで、Dependent viewのストリームについては、それぞれのstream_idをSTN_tableに登録するのではなく、Base viewのストリームのstream_idから計算により導き出すことができるようにする。

例えば、Dependent view videoストリームのstream_idは下式（１）により定義される。
video_stream_id + x = dependent_view_video_stream_id ・・・ （１）

Dependent PGストリームのstream_idは下式（２）により定義される。
PG_textST_stream_id + x = Dependent_PG_textST_stream_id ・・・ （２）

Dependent IGストリームのstream_idは下式（３）により定義される。
IG_stream_id + x = Dependent_IG_stream_id ・・・ （３）

式（１）乃至（３）のxの値は任意である。式（１）乃至（３）においてそれぞれ異なる値がxとして代入されるようにしてもよい。

xの値については、STN_tableから特定できるようにしてもよいし、再生装置１に予め設定されているようにしてもよい。

これにより、光ディスク２にデータを記録する記録装置は、Dependent viewのストリームのstream_idを、Base viewのストリームのstream_idとは別にSTN_tableに設定しないで済む。

また、再生装置１は、Base viewのストリームのstream_idをSTN_tableから特定すれば、それに対応するDependent viewのストリームのstream_idを計算により特定することが可能になる。

BD規格においては、ストリームを使った各種の処理がJava（登録商標）アプリケーションによって実現される。

例えば、あるストリームを使った処理を行う場合、図１８に示すように、Java（登録商標）アプリケーションは、そのストリームの読み出しを、stream_idを指定してAPI(Application Programming Interface)を介してドライバに指示する。

ドライバは、APIを介してJava（登録商標）アプリケーションから指定されたstream_idをBase viewのストリームのstream_idとし、それに基づいてDependent viewのストリームのstream_idを計算により特定する。また、特定したstream_idに基づいて、Base viewのストリームとDependent viewのストリームを読み出す。

これにより、3D表示を行う場合であっても、Java（登録商標）アプリケーションがAPIを介して指定するstream_idは１つで済む。また、Base viewとDependent viewの２つのstream_idを指定することができるようにAPIを拡張させる必要がない。

また、Base viewのストリームのIDからDependent viewのストリームのIDを自動的に算出することができる利点として次のようなものもある。

BDにおいては、再生するストリームをプレーヤが自動的に選択するためのアルゴリズムが準備されている。このアルゴリズムは、例えば、ある英語のビデオを再生すると、自動的に、どの字幕を一緒に再生するべきかが割り出せるようなアルゴリズムである。

仮に、Dependent viewのストリームにもストリームIDを割り当てるようにした場合、従来のプレーヤが行っていたストリーム再生選択アルゴリズムの処理を、Dependent viewについても同様に行う必要があり、プレーヤの処理の負荷が高くなってしまう。すなわち、プレーヤは、Base viewのストリームに注目してストリーム再生選択アルゴリズムの処理を行った後に、Dependent viewのストリームに注目してストリーム再生選択アルゴリズムの処理を行う必要がある。

上述したようにしてBase viewのストリームのIDからDependent viewのストリームのIDを自動的に算出することができるようにすることにより、Dependent viewのストリームに注目して行う処理を回避することが可能になる。

［PlayListファイルの記述の例］
図１９は、PlayListファイルのシンタクスを示す図である。

PlayListファイルは、図７のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。

PlayListファイルに、図８を参照して説明した各記述が含まれる。

図１９のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。

version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは４桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。

PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。

PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。

ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。

ExtensionData_start_addressの後には、160bitのreserved_for_future_useが含まれる。

AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。

PlayList()には、図８を参照して説明したような、Main PathやSub Pathなどに関するパラメータが格納される。

PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。

ExtensionData()には、プライベートデータが挿入できるようになっている。

図２０は、PlayListファイルの記述の例を示す図である。

図２０に示すように、PlayListファイルには、２bitの3D_PL_typeと１bitのview_typeが記述される。view_typeは、例えば図１９のAppInfoPlayList()に記述される。

3D_PL_typeは、PlayListの種類を表す。

view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。Dependent view videoストリームがL画像のストリームであるのか、R画像のストリームであるのかが表されるようにしてもよい。

図２１は、3D_PL_typeの値の意味を示す図である。

3D_PL_typeの値の00は、2D再生用のPlayListであることを表す。

3D_PL_typeの値の01は、3D再生のうちのB-D1再生用のPlayListであることを表す。

3D_PL_typeの値の10は、3D再生のうちのB-D2再生用のPlayListであることを表す。

例えば、3D_PL_typeの値が01が10の場合、PlayListファイルのExtenstionData()に3DPlayList情報が登録される。3DPlayList情報として、例えば、Dependent view videoストリームのClipに対応するclpiファイルのファイル名（図７の例の場合、「00002.clpi」）などが登録される。

図２２は、view_typeの値の意味を示す図である。

view_typeの値の0は、3D再生を行う場合には、Base view videoストリームがL viewのストリームであることを表す。2D再生を行う場合には、Base view videoストリームがAVCビデオストリームであることを表す。

view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。

view_typeがPlayListファイルに記述されることにより、再生装置１は、Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することが可能になる。

例えば、HDMIケーブルを介して表示装置３にビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが再生装置１に要求されるものと考えられる。

Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することができるようにすることにより、再生装置１は、L viewの信号とR viewの信号を区別して出力することが可能になる。

［再生装置１の構成例］
図２３は、再生装置１の構成例を示すブロック図である。

コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。

例えば、コントローラ５１は、ディスクドライブ５２を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ５１は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部５６に供給させる。

ディスクドライブ５２は、コントローラ５１による制御に従って光ディスク２からデータを読み出し、読み出したデータを、コントローラ５１、メモリ５３、またはデコーダ部５６に出力する。

メモリ５３は、コントローラ５１が各種の処理を実行する上において必要なデータなどを適宜記憶する。

ローカルストレージ５４は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ５４には、サーバ７２からダウンロードされたDependent view videoストリームなどが記録される。ローカルストレージ５４に記録されているストリームもデコーダ部５６に適宜供給される。

インターネットインタフェース５５は、コントローラ５１からの制御に従ってネットワーク７１を介してサーバ７２と通信を行い、サーバ７２からダウンロードしたデータをローカルストレージ５４に供給する。

サーバ７２からは、光ディスク２に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたDependent view videoストリームを光ディスク２に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク２の内容とは異なる内容の3D再生を実現することが可能になる。
Dependent view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。

デコーダ部５６は、ディスクドライブ５２、または、ローカルストレージ５４から供給されたストリームをデコードし、得られたビデオ信号を表示装置３に出力する。オーディオ信号も所定の経路を介して表示装置３に出力される。

操作入力部５７は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部５７はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ５１に供給する。

図２４は、デコーダ部５６の構成例を示す図である。

図２４にはビデオ信号の処理を行う構成を示している。デコーダ部５６においては、オーディオ信号のデコード処理も行われる。オーディオ信号を対象として行われたデコード処理の結果は、図示せぬ経路を介して表示装置３に出力される。

PIDフィルタ１０１は、ディスクドライブ５２、またはローカルストレージ５４から供給されたTSがMain TSであるかSub TSであるかを、TSを構成するパケットのPIDやストリームのIDなどに基づいて識別する。PIDフィルタ１０１は、Main TSをバッファ１０２に出力し、Sub TSをバッファ１０３に出力する。

PIDフィルタ１０４は、バッファ１０２に記憶されたMain TSのパケットを順次読み出し、PIDに基づいて振り分ける。

例えば、PIDフィルタ１０４は、Main TSに含まれているBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。

また、PIDフィルタ１０４は、Main TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。

PIDフィルタ１０４は、Main TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。

図１５を参照して説明したように、Base view video、Dependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがMain TSに多重化されていることがある。

PIDフィルタ１０５は、バッファ１０３に記憶されたSub TSのパケットを順次読み出し、PIDに基づいて振り分ける。

例えば、PIDフィルタ１０５は、Sub TSに含まれているDependent view videoストリームを構成するパケットをスイッチ１０７に出力する。

また、PIDフィルタ１０５は、Sub TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。

PIDフィルタ１０５は、Sub TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。

図１７を参照して説明したように、Dependent view videoストリームがSub TSに含まれていることがある。また、図１６を参照して説明したように、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがSub TSに多重化されていることがある。

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

スイッチ１０９は、B videoバッファ１０６に記憶されたBase view videoのパケットと、D videoバッファ１０８に記憶されたDependent view videoのパケットを、デコードのタイミングを規定する時刻情報に従って順次読み出す。Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには例えば同じ時刻情報が設定されている。

スイッチ１０９は、B videoバッファ１０６、またはD videoバッファ１０８から読み出したパケットをビデオデコーダ１１０に出力する。

ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはDependent view videoのデータをスイッチ１１１に出力する。

スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。

B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。

D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。

スイッチ１１４は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase IGストリームを構成するパケットをB IGバッファ１１５に出力する。

B IGデコーダ１１６は、B IGバッファ１１５に記憶されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。

B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。

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

D IGデコーダ１２０は、D IGバッファ１１９に記憶されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。

D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。

スイッチ１２２は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase PGストリームを構成するパケットをB PGバッファ１２３に出力する。

B PGデコーダ１２４は、B PGバッファ１２３に記憶されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。

B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。

スイッチ１２６は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent PGストリームを構成するパケットをD PGバッファ１２７に出力する。

D PGデコーダ１２８は、D PGバッファ１２７に記憶されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。

D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。

合成部１３０は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンと、B IGプレーン生成部１１７から供給されたBase IGのプレーンと、B PGプレーン生成部１２５から供給されたBase PGのプレーンを所定の順番で重ねることによって合成し、Base viewのプレーンを生成する。

また、合成部１３０は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンと、D IGプレーン生成部１２１から供給されたDependent IGのプレーンと、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを所定の順番で重ねることによって合成し、Dependent viewのプレーンを生成する。

合成部１３０は、Base viewのプレーンのデータとDependent viewのプレーンのデータを出力する。合成部１３０から出力されたビデオデータは表示装置３に出力され、Base viewのプレーンとDependent viewのプレーンが交互に表示されることによって3D表示が行われる。

図２５は、ビデオストリームの処理を行う構成を示す図である。

図２５において、図２４に示す構成と同じ構成には同じ符号を付してある。図２４には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB(Decoded Picture Buffer)１５１が設けられる。重複する説明については適宜省略する。

また、図２５の例においては、L videoプレーン生成部１６１が図２４のB videoプレーン生成部１１２に替えて設けられ、R videoプレーン生成部１６２が図２４のD videoプレーン生成部１１３に替えて設けられている。

L videoプレーン生成部１６１は、L view videoのプレーンを生成する。また、R videoプレーン生成部１６２は、R view videoのプレーンを生成する。

この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。

すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータが、それぞれ、L viewとR viewのいずれのビデオデータであるのかを識別する。

L viewとR viewの識別には、図２０と図２２を参照して説明したview_typeが用いられる。例えば、コントローラ５１は、PlayListファイルに記述されているview_typeをスイッチ１１１に出力する。

view_typeの値が0である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。上述したように、view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。例えば、Base view videoのパケットにはPID=0が割り当てられ、Dependent view videoのパケットには0以外のPIDが割り当てられている。

この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。

一方、view_typeの値が1である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。

この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。

L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。L videoプレーン生成部１６１から出力されたL view videoのプレーンは、他のL viewのデータが合成部１３０において適宜合成された後、Ｌ画像のデータとして表示装置３に出力される。

R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。R videoプレーン生成部１６２から出力されたR view videoのプレーンは、他のR viewのデータが合成部１３０において適宜合成された後、Ｒ画像のデータとして表示装置３に出力される。

H.264 AVC/MVCプロファイル規格でエンコードされたBase view video、Dependent view videoのエレメンタリストリーム内には、L viewであるのか、またはR viewであるのかを表す情報（フィールド）が存在しない。

従って、view_typeをPlayListファイルに設定しておくことにより、記録装置は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを再生装置１に識別させることが可能になる。

再生装置１は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを識別し、識別結果に応じて出力先を切り替えることができる。

IG、PGのプレーンについてもそれぞれL viewとR viewが用意されている場合、ビデオストリームのL viewとR viewを区別できることにより、再生装置１はL view同士、R view同士のプレーンの合成を容易に行うことができる。

HDMIケーブルを介してビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが要求される可能性がある。再生装置１はその要求に対応することが可能になる。

DPB１５１に記憶されたBase view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの識別が、PIDではなく、view_idに基づいて行われるようにしてもよい。

H.264 AVC/MVCプロファイル規格でのエンコード時、エンコード結果のストリームを構成するAccess Unitにはview_idが設定される。view_idにより、各Access Unitがどのview componentのユニットであるのかが識別可能になっている。

図２６は、Access Unitの例を示す図である。

図２６のAccess Unit＃１はBase view videoのデータを含むユニットである。Dependent Unit＃２はDependent view videoのデータを含むユニットである。Access Unit（Dependent viewの場合、Dependent Unit）はピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。

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

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

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

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

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

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

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

［記録装置の構成例］
図２７は、ソフト製作処理部２０１の構成例を示すブロック図である。

ビデオエンコーダ２１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ２１１は、複数の映像データをH.264 AVC/MVCプロファイル規格に従ってエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ２１２に出力する。

オーディオエンコーダ２１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ２１４に出力する。オーディオエンコーダ２１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。

データエンコーダ２１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ２１６に出力する。

例えば、データエンコーダ２１５は、Dependent view videoストリームを含むSub TSに対応するClip Informationファイルのapplication_typeの値として8を設定する。application_type=8は、Dependent view videoストリームを用いて処理を行うアプリケーションが3D再生を行うアプリケーションであることを表す。

また、データエンコーダ２１５は、Dependent view videoストリームがBase view videoストリームと同じTSに多重化されているか否かと記録場所に応じたSubPath_typeをPlayListに設定する。Dependent view videoストリームの記録場所は、光ディスク２、またはローカルストレージ５４である。

さらに、データエンコーダ２１５は、再生装置１側において、Base viewのストリームのIDに基づいてDependent viewのストリームを計算するようになされている場合、その計算に用いられる値xをSTN_table()などの所定の位置に設定する。

データエンコーダ２１５は、ビデオエンコーダ２１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。

多重化部２１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部２１８に出力する。

誤り訂正符号化部２１８は、エラー訂正用のコードを多重化部２１７により多重化されたデータに付加する。

変調部２１９は、誤り訂正符号化部２１８から供給されたデータに対して変調を施し、出力する。変調部２１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。

このような構成を有するソフト製作処理部２０１が記録装置内に設けられる。

図２８は、ソフト製作処理部２０１を含む各構成の例を示す図である。

図２６に示す構成の一部が記録装置内に設けられることもある。

ソフト製作処理部２０１により生成された記録信号はプリマスタリング処理部２３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部２３３に供給される。

記録用原盤製作部２３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。

原盤記録部２３３において、プリマスタリング処理部２３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。

金属原盤製作部２３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。

成形処理部２３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。
あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。

成膜処理部２３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。

後加工処理部２３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。

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

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

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

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

この場合、ソフト製作処理部２０１のデータエンコーダ２１５は、view_typeを記述したPMTを生成し、出力する。データエンコーダ２１５から出力されたPMTは、バッファ２１６を介して多重化部２１７に供給され、Base view video、Dependent view videoストリームとともに多重化される。多重化されることによって得られたTSは、放送波を介して、またはネットワークを介して送信される。

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

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

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

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

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

図３１に示すように、Base view videoストリームの１ピクチャのデータを含むBase view videoのAccess Unitと、Dependent view videoストリームの１ピクチャのデータを含むDependent view videoのDependent Unitは同じ構成を有する。１つのユニットは、各ユニットの境界を示すデリミタ、SPS、PPS、SEI、ピクチャデータから構成される。例えばDependent view videoのDependent Unitのピクチャデータには、図２６を参照して説明したMVCヘッダが付加される。

この場合、ソフト製作処理部２０１のデータエンコーダ２１５は、view_typeを記述したSEIを生成し、図示せぬ経路を介してビデオエンコーダ２１１に出力する。データエンコーダ２１５から出力されたSEIは、ビデオエンコーダ２１１において、H.264 AVC/MVCプロファイル規格に従ってＬ画像データとＲ画像データを符号化することによって得られたBase view video、Dependent view videoの各ピクチャのデータに図３１に示すようにして付加される。

view_typeを記述したSEIが付加されたピクチャのデータからなるBase view videoストリーム、Dependent view videoストリームは、多重化された後、放送波を介して、またはネットワークを介して送信されたり、記録媒体に記録されたりする。

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

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

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

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

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

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

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

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

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

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

Claims (1)

1. 左目用の映像データと右目用の映像データをH.264 AVC/MVCで符号化を行うことによって基本ストリームおよび拡張ストリームを生成し、
   前記基本ストリームが左目用の映像データのストリームであるのか右目用の映像データのストリームであるのかを表す、前記基本ストリームを復号して得られた映像データを左目用の映像データと右目用の映像データのうちの一方の映像データとして出力し、前記拡張ストリームを復号して得られた映像データを他方の映像データとして出力するように再生装置を機能させる１ビットの視点情報がAppInfoPlayList()に記述された、前記基本ストリームと前記拡張ストリームの再生を管理するPlayListファイルを生成し、
   生成した前記基本ストリーム、前記拡張ストリーム、および前記PlayListファイルを記録媒体に記録させる
   ステップを含む記録方法。

Images