(57)【要約】【課題】BD等の記録媒体に記録されている、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームからなる3Dコンテンツを、グラフィックスストリームとともに適切に再生することができるようにする。【解決手段】Base viewのプレーン同士、Dependent viewのプレーン同士、video、IG、PGの各プレーンの合成が行われる。また、Base viewのプレーン同士を合成した結果と、Dependent viewのプレーン同士を合成した結果について、L viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。本発明は、BD-ROM規格に対応した再生装置に適用することができる。【選択図】図２７
2010245970.tif 000002
【特許請求の範囲】
【請求項１】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号する第１の復号手段と、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号する第２の復号手段と、
前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成する合成手段と
を備える再生装置。
【請求項２】
前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記第１の合成プレーンと前記第２の合成プレーンのうちの一方の合成プレーンを左画像のプレーンとして出力し、他方の合成プレーンを右画像のプレーンとして出力する切り替え手段をさらに備える
請求項１に記載の再生装置。
【請求項３】
前記切り替え手段は、前記第１の合成プレーンがBase viewのプレーン同士を合成して得られたプレーンであるのか、前記第２の合成プレーンがDependent viewのプレーン同士を合成して得られたプレーンであるのかを、PIDに基づいて識別する
請求項２に記載の再生装置。
【請求項４】
前記切り替え手段は、前記第１の合成プレーンがBase viewのプレーン同士を合成して得られたプレーンであるのか、前記第２の合成プレーンがDependent viewのプレーン同士を合成して得られたプレーンであるのかを、符号化時に前記Dependent view videoのストリームに設定されたview IDに基づいて識別する
請求項２に記載の再生装置。
【請求項５】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、
前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成する
ステップを含む再生方法。
【請求項６】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、
前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成する
ステップを含む処理をコンピュータに実行させるプログラム。
【請求項７】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号する第１の復号手段と、
前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力する第１の切り替え手段と、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号する第２の復号手段と、
前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力する第２の切り替え手段と、
前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成する合成手段と
を備える再生装置。
【請求項８】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、
前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力し、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、
前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力し、
前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成する
ステップを含む再生方法。
【請求項９】
複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、
前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力し、
Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、
前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力し、
前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、
前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成する
ステップを含む処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、再生装置、再生方法、およびプログラムに関し、特に、BD等の記録媒体に記録されている、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームからなる3Dコンテンツを、グラフィックスストリームとともに適切に再生することができるようにした再生装置、再生方法、およびプログラムに関する。
【背景技術】
【０００２】
映画等のコンテンツとしては２次元画像のコンテンツが主流であるが、最近では、立体視が可能な立体視画像のコンテンツが注目を集めている。
【０００３】
立体視画像の表示には、専用のデバイスが必要であり、そのような立体視用デバイスとしては、例えば、NHK（日本放送協会）が開発したIP(Integral Photography)立体画像システムがある。
【０００４】
立体視画像の画像データは、複数の視点の画像データ（複数の視点から撮影された画像の画像データ）からなり、視点の数が多く、かつ、視点が広範囲にわたるほど、様々な方向から被写体を見ることができる、いわば「のぞけるテレビ」を実現することができる。
【０００５】
立体視画像のうちの、視点の数が最も少ないのは視点の数が２視点のステレオ画像（いわゆる3D画像）である。ステレオ画像の画像データは、左眼で観察される画像である左画像のデータと、右眼で観察される画像である右画像のデータとからなる。
【０００６】
一方、映画等の、高解像度の画像のコンテンツはそのデータ量が多いことから、そのようなデータ量の多いコンテンツを記録するには大容量の記録媒体が必要になる。
【０００７】
そのような大容量の記録媒体としては、BD(Blu-Ray（登録商標）)-ROM(Read Only Memory)等のBlu-Ray（登録商標） Disc（以下、BDともいう）がある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−３４８３１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、BDの規格では、ステレオ画像を含む立体視画像の画像データを、BDにどのように記録し、また、再生するかは規定されていない。
【００１０】
ステレオ画像の画像データは、左画像のデータのストリームと右画像のデータのストリームの２本のデータストリームからなる。また、映画の字幕や、ユーザが操作するボタンなどもステレオ表示しようとする場合、それらのグラフィックスのストリームも、左目用のものと右目用のものとで２本用意されることになる。
【００１１】
このため、画像データのストリームとグラフィックスストリームを併せて再生し、ステレオ画像を表示させることができるようなデコーダモデルを定義し、そのモデルに従ったデコーダを再生装置に実装する必要がある。
【００１２】
本発明はこのような状況に鑑みてなされたものであり、BD等の記録媒体に記録されている、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームからなる3Dコンテンツを、グラフィックスストリームとともに適切に再生することができるようにするものである。
【課題を解決するための手段】
【００１３】
本発明の一側面の再生装置は、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号する第１の復号手段と、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号する第２の復号手段と、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成する合成手段とを備える。
【００１４】
前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記第１の合成プレーンと前記第２の合成プレーンのうちの一方の合成プレーンを左画像のプレーンとして出力し、他方の合成プレーンを右画像のプレーンとして出力する切り替え手段をさらに設けることができる。
【００１５】
前記切り替え手段には、前記第１の合成プレーンがBase viewのプレーン同士を合成して得られたプレーンであるのか、前記第２の合成プレーンがDependent viewのプレーン同士を合成して得られたプレーンであるのかを、PIDに基づいて識別させることができる。
【００１６】
前記切り替え手段には、前記第１の合成プレーンがBase viewのプレーン同士を合成して得られたプレーンであるのか、前記第２の合成プレーンがDependent viewのプレーン同士を合成して得られたプレーンであるのかを、符号化時に前記Dependent view videoのストリームに設定されたview IDに基づいて識別させることができる。
【００１７】
本発明の一側面の再生方法は、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成するステップを含む。
【００１８】
本発明の一側面のプログラムは、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンを生成し、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンを生成するステップを含む処理をコンピュータに実行させる。
【００１９】
本発明の他の側面の再生装置は、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号する第１の復号手段と、前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力する第１の切り替え手段と、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号する第２の復号手段と、前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力する第２の切り替え手段と、前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成する合成手段とを備える。
【００２０】
本発明の他の側面の再生方法は、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力し、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力し、前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成するステップを含む。
【００２１】
本発明の他の側面のプログラムは、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームを復号し、前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンを第１の左画像のプレーンとして出力し、他方のプレーンを第１の右画像のプレーンとして出力し、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームを復号し、前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンを第２の左画像のプレーンとして出力し、他方のプレーンを第２の右画像のプレーンとして出力し、前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンを生成するステップを含む処理をコンピュータに実行させる。
【００２２】
本発明の一側面においては、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが復号され、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームが復号され、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンを合成して第１の合成プレーンが生成され、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンを合成して第２の合成プレーンが生成される。
【００２３】
本発明の他の側面においては、複数の映像データをH.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームが復号され、前記Base view videoのストリームと前記Dependent view videoのストリームのうちの一方のストリームが左画像のストリームであるのか、右画像のストリームであるのかを表すフラグに基づいて、前記Base view videoのストリームの復号結果に基づいて得られたBase view videoのプレーンと、前記Dependent view videoのストリームの復号結果に基づいて得られたDependent view videoのプレーンのうちの一方のプレーンが第１の左画像のプレーンとして出力され、他方のプレーンを第１の右画像のプレーンとして出力される。また、Base viewのグラフィックスストリームとDependent viewのグラフィックスストリームが復号され、前記フラグに基づいて、前記Base viewのグラフィックスストリームの復号結果に基づいて得られたBase viewグラフィックスのプレーンと、前記Dependent viewのグラフィックスストリームの復号結果に基づいて得られたDependent viewグラフィックスのプレーンのうちの一方のプレーンが第２の左画像のプレーンとして出力され、他方のプレーンが第２の右画像のプレーンとして出力され、前記第１の左画像のプレーンと前記第２の左画像のプレーンを合成して第１の合成プレーンを生成し、前記第１の右画像のプレーンと前記第２の右画像のプレーンを合成して第２の合成プレーンが生成される。
【発明の効果】
【００２４】
本発明によれば、BD等の記録媒体に記録されている、H.264 AVC/MVCで符号化して得られたBase view videoのストリームとDependent view videoのストリームからなる3Dコンテンツを、グラフィックスストリームとともに適切に再生することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明を適用した再生装置を含む再生システムの構成例を示す図である。
【図２】撮影の例を示す図である。
【図３】MVCエンコーダの構成例を示すブロック図である。
【図４】参照画像の例を示す図である。
【図５】TSの構成例を示す図である。
【図６】TSの他の構成例を示す図である。
【図７】TSのさらに他の構成例を示す図である。
【図８】AVストリームの管理の例を示す図である。
【図９】Main PathとSub Pathの構造を示す図である。
【図１０】光ディスクに記録されるファイルの管理構造の例を示す図である。
【図１１】PlayListファイルのシンタクスを示す図である。
【図１２】図１１にあるreserved_for_future_useの使い方の例を示す図である。
【図１３】3D_PL_typeの値の意味を示す図である。
【図１４】view_typeの値の意味を示す図である。
【図１５】図１１のPlayList()のシンタクスを示す図である。
【図１６】図１５のSubPath()のシンタクスを示す図である。
【図１７】図１６のSubPlayItem(i)のシンタクスを示す図である。
【図１８】図１５のPlayItem()のシンタクスを示す図である。
【図１９】図１８のSTN_table()のシンタクスを示す図である。
【図２０】再生装置の構成例を示すブロック図である。
【図２１】図２０のデコーダ部の構成例を示す図である。
【図２２】ビデオストリームの処理を行う構成を示す図である。
【図２３】ビデオストリームの処理を行う構成を示す図である。
【図２４】ビデオストリームの処理を行う他の構成を示す図である。
【図２５】Access Unitの例を示す図である。
【図２６】ビデオストリームの処理を行うさらに他の構成を示す図である。
【図２７】合成部と、その前段の構成を示す図である。
【図２８】合成部と、その前段の構成を示す他の図である。
【図２９】ソフト製作処理部の構成例を示すブロック図である。
【図３０】ソフト製作処理部を含む各構成の例を示す図である。
【図３１】記録装置に設けられる3D video TS生成部の構成例を示す図である。
【図３２】記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【図３３】記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【図３４】Access Unitをデコードする再生装置側の構成を示す図である。
【図３５】デコード処理を示す図である。
【図３６】Close GOP構造を示す図である。
【図３７】Open GOP構造を示す図である。
【図３８】GOP内の最大フレーム・フィールド数を示す図である。
【図３９】Close GOP構造を示す図である。
【図４０】Open GOP構造を示す図である。
【図４１】EP_mapに設定されたデコード開始位置の例を示す図である。
【図４２】Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【図４３】ピクチャサーチの概念を示す図である。
【図４４】光ディスク上に記録されたAVストリームの構造を示す図である。
【図４５】Clip AVストリームの例を示す図である。
【図４６】図４５のClip AVストリームに対応したEP_mapを概念的に示す図である。
【図４７】SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【図４８】コンピュータのハードウェアの構成例を示すブロック図である。
【発明を実施するための形態】
【００２６】
＜第１の実施の形態＞
［再生システムの構成例］
図１は、本発明を適用した再生装置１を含む再生システムの構成例を示す図である。
【００２７】
図１に示すように、この再生システムは、再生装置１と表示装置３がHDMI(High Definition Multimedia Interface)ケーブルなどで接続されることによって構成される。再生装置１には、BDなどの光ディスク２が装着される。
【００２８】
光ディスク２には、視点の数が２つのステレオ画像（いわゆる3D画像）を表示するために必要なストリームが記録されている。
【００２９】
再生装置１は、光ディスク２に記録されているストリームの3D再生に対応したプレーヤである。再生装置１は、光ディスク２に記録されているストリームを再生し、再生して得られた3D画像をテレビジョン受像機などよりなる表示装置３に表示させる。音声についても同様に再生装置１により再生され、表示装置３に設けられるスピーカなどから出力される。
【００３０】
3D画像の表示の方式として様々な方式が提案されている。ここでは、3D画像の表示の方式として、以下のタイプ１の表示方式と、タイプ２の表示方式とを採用する。
【００３１】
タイプ１の表示方式は、3D画像のデータを左眼で観察される画像（L画像）のデータと、右眼で観察される画像（R画像）のデータとで構成し、L画像とR画像を交互に表示することで、3D画像を表示する方式である。
【００３２】
タイプ２の表示方式は、3D画像を生成する元になる画像である元画像のデータとDepthのデータとを用いて生成されるL画像とR画像を表示することで、3D画像を表示する方式である。タイプ２の表示方式で用いられる3D画像のデータは、元画像のデータと、元画像に与えることによってL画像とR画像を生成することができるDepthのデータとで構成される。
【００３３】
タイプ１の表示方式は、視聴するときにメガネが必要となる表示方式である。タイプ２の表示方式は、メガネなしで3D画像を視聴できる表示方式である。
【００３４】
光ディスク２には、タイプ１と２のいずれの表示方式によっても3D画像を表示することができるようなストリームが記録されている。
【００３５】
そのようなストリームを光ディスク２に記録するための符号化の方式として、例えば、H.264 AVC(Advanced Video Coding)/MVC(Multi-view Video coding)が採用される。
【００３６】
［H.264 AVC/MVC Profile］
H.264 AVC/MVCでは、Base view videoと呼ばれる画像ストリームと、Dependent view videoと呼ばれる画像ストリームとが定義されている。以下、適宜、H.264 AVC/MVCを単にMVCという。
【００３７】
図２は、撮影の例を示す図である。
【００３８】
図２に示すように、同じ被写体を対象として、L画像用のカメラとR画像用のカメラによって撮影が行われる。L画像用のカメラとR画像用のカメラによって撮影された映像のエレメンタリストリームがMVCエンコーダに入力される。
【００３９】
図３は、MVCエンコーダの構成例を示すブロック図である。
【００４０】
図３に示すように、MVCエンコーダ１１は、H.264/AVCエンコーダ２１、H.264/AVCデコーダ２２、Depth算出部２３、Dependent view videoエンコーダ２４、およびマルチプレクサ２５から構成される。
【００４１】
L画像用のカメラにより撮影された映像＃１のストリームはH.264/AVCエンコーダ２１とDepth算出部２３に入力される。また、R画像用のカメラにより撮影された映像＃２のストリームはDepth算出部２３とDependent view videoエンコーダ２４に入力される。映像＃２のストリームがH.264/AVCエンコーダ２１とDepth算出部２３に入力され、映像＃１のストリームがDepth算出部２３とDependent view videoエンコーダ２４に入力されるようにしてもよい。
【００４２】
H.264/AVCエンコーダ２１は、映像＃１のストリームを、例えばH.264 AVC/High Profileビデオストリームとして符号化する。H.264/AVCエンコーダ２１は、符号化して得られたAVCビデオストリームを、Base view videoストリームとしてH.264/AVCデコーダ２２とマルチプレクサ２５に出力する。
【００４３】
H.264/AVCデコーダ２２は、H.264/AVCエンコーダ２１から供給されたAVCビデオストリームをデコードし、デコードして得られた映像＃１のストリームをDependent view videoエンコーダ２４に出力する。
【００４４】
Depth算出部２３は、映像＃１のストリームと映像＃２のストリームに基づいてDepthを算出し、算出したDepthのデータをマルチプレクサ２５に出力する。
【００４５】
Dependent view videoエンコーダ２４は、H.264/AVCデコーダ２２から供給された映像＃１のストリームと、外部から入力された映像＃２のストリームをエンコードし、Dependent view videoストリームを出力する。
【００４６】
Base view videoには、他のストリームを参照画像とする予測符号化が許されていないが、図４に示すように、Dependent view videoには、Base view videoを参照画像とする予測符号化が許されている。例えばL画像をBase view videoとするとともにR画像をDependent view videoとして符号化を行った場合、その結果得られるDependent view videoストリームのデータ量は、Base view videoストリームのデータ量に比較して少なくなる。
【００４７】
なお、H.264/AVCでの符号化であるから、Base view videoについて時間方向の予測は行われている。また、Dependent view videoについても、view間の予測とともに、時間方向の予測が行われている。Dependent view videoをデコードするには、エンコード時に参照先とした、対応するBase view videoのデコードが先に終了している必要がある。
【００４８】
Dependent view videoエンコーダ２４は、このようなview間の予測も用いて符号化して得られたDependent view videoストリームをマルチプレクサ２５に出力する。
【００４９】
マルチプレクサ２５は、H.264/AVCエンコーダ２１から供給されたBase view videoストリームと、Depth算出部２３から供給されたDependent view videoストリーム（Depthのデータ）と、Dependent view videoエンコーダ２４から供給されたDependent view videoストリームとを、例えばMPEG2 TSとして多重化する。Base view videoストリームとDependent view videoストリームは１本のMPEG2 TSに多重化されることもあるし、別々のMPEG2 TSに含まれることもある。
【００５０】
マルチプレクサ２５は、生成したTS（MPEG2 TS）を出力する。マルチプレクサ２５から出力されたTSは、他の管理データとともに記録装置において光ディスク２に記録され、光ディスク２に記録された形で再生装置１に提供される。
【００５１】
タイプ１の表示方式においてBase view videoとともに用いられるDependent view videoと、タイプ２の表示方式においてBase view videoとともに用いられるDependent view video（Depth）とを区別する必要がある場合、前者をD1 view videoといい、後者をD2 view videoという。
【００５２】
また、Base view videoとD1 view videoを用いて行われる、タイプ１の表示方式での3D再生をB-D1再生という。Base view videoとD2 view videoを用いて行われる、タイプ２の表示方式での3D再生をB-D2再生という。
【００５３】
再生装置１は、ユーザによる指示などに応じてB-D1再生を行う場合、Base view videoストリームとD1 view videoストリームを光ディスク２から読み出して再生する。
【００５４】
また、再生装置１は、B-D2再生を行う場合、Base view videoストリームとD2 view videoストリームを光ディスク２から読み出して再生する。
【００５５】
さらに、再生装置１は、通常の2D画像の再生を行う場合、Base view videoストリームだけを光ディスク２から読み出して再生する。
【００５６】
Base view videoストリームはH.264/AVCで符号化されているAVCビデオストリームであるから、BDのフォーマットに対応したプレーヤであれば、そのBase view videoストリームを再生し、2D画像を表示させることが可能になる。
【００５７】
以下、Dependent view videoがD1 view videoである場合について主に説明する。単にDependent view videoというときは、D1 view videoを表すことになる。D2 view videoについても、D1 view videoと同様にして光ディスク２に記録され、再生される。
【００５８】
［TSの構成例］
図５は、TSの構成例を示す図である。
【００５９】
図５のMain TSにはBase view video、Dependent view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。このように、Dependent view videoストリームが、Base view videoストリームとともにMain TSに含まれていることもある。
【００６０】
光ディスク２には、Main TSとSub TSが記録されている。Main TSは、少なくともBase view videoストリームを含むTSである。Sub TSは、Base view videoストリーム以外のストリームを含み、Main TSとともに用いられるTSである。
【００６１】
ビデオと同様に3Dでの表示が可能になるように、後述するPG、IGについてもBase viewとDependent viewのそれぞれのストリームが用意されている。
【００６２】
それぞれのストリームをデコードして得られたPG、IGのBase viewのプレーンは、Base view videoストリームをデコードして得られたBase view videoのプレーンと合成されて表示される。同様に、PG、IGのDependent viewのプレーンは、Dependent view videoストリームをデコードして得られたDependent view videoのプレーンと合成されて表示される。
【００６３】
例えば、Base view videoストリームがL画像のストリームであり、Dependent view videoストリームがR画像のストリームである場合、PG、IGについても、そのBase viewのストリームはL画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはR画像のグラフィックスのストリームとなる。
【００６４】
一方、Base view videoストリームがR画像のストリームであり、Dependent view videoストリームがL画像のストリームである場合、PG、IGについても、そのBase viewのストリームはR画像のグラフィックスのストリームとなる。また、Dependent viewのPGストリーム、IGストリームはL画像のグラフィックスのストリームとなる。
【００６５】
図６は、TSの他の構成例を示す図である。
【００６６】
図６のMain TSにはBase view video、Dependent view videoのそれぞれのストリームが多重化されている。
【００６７】
一方、Sub TSにはPrimary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００６８】
このように、ビデオストリームがMain TSに多重化され、PG、IGのストリーム等がSub TSに多重化されていることもある。
【００６９】
図７は、TSのさらに他の構成例を示す図である。
【００７０】
図７ＡのMain TSにはBase view video、Primary audio、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００７１】
一方、Sub TSにはDependent view videoストリームが含まれている。
【００７２】
このように、Dependent view videoストリームがBase view videoストリームとは別のTSに含まれていることもある。
【００７３】
図７ＢのMain TSにはBase view video、Primary audio、PG、IGのそれぞれのストリームが多重化されている。一方、Sub TSにはDependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームが多重化されている。
【００７４】
Main TSに含まれるPG、IGは2D再生用のストリームである。Sub TSに含まれているストリームは3D再生用のストリームである。
【００７５】
このように、PGのストリームとIGのストリームを2D再生と3D再生において共有しないようにすることも可能である。
【００７６】
以上のように、Base view videoストリームとDependent view videoストリームが別々のMPEG2 TSに含まれることがある。Base view videoストリームとDependent view videoストリームを別々のMPEG2 TSに含めて記録する場合のメリットについて説明する。
【００７７】
例えば１本のMPEG2 TSとして多重化できるビットレートが制限されている場合を考える。この場合において、Base view videoストリームとDependent view videoストリームの両方を１本のMPEG2 TSに含めたときには、その制約を満たすために各ストリームのビットレートを下げる必要がある。その結果、画質が落ちてしまうことになる。
【００７８】
それぞれ異なるMPEG2 TSに含めることによって、ビットレートを下げる必要がなくなり、画質を落とさずに済むことになる。
【００７９】
［アプリケーションフォーマット］
図８は、再生装置１によるAVストリームの管理の例を示す図である。
【００８０】
AVストリームの管理は、図８に示すようにPlayListとClipの２つのレイヤを用いて行われる。AVストリームは、光ディスク２だけでなく、再生装置１のローカルストレージに記録されていることもある。
【００８１】
ここでは、１つのAVストリームとそれに付随する情報であるClip Informationのペアを１つのオブジェクトと考え、それらをまとめてClipという。以下、AVストリームを格納したファイルをAVストリームファイルという。また、Clip Informationを格納したファイルをClip Informationファイルともいう。
【００８２】
AVストリームは時間軸上に展開され、各Clipのアクセスポイントは、主に、タイムスタンプでPlayListにおいて指定される。Clip Informationファイルは、AVストリーム中のデコードを開始すべきアドレスを見つけるためなどに使用される。
【００８３】
PlayListはAVストリームの再生区間の集まりである。AVストリーム中の１つの再生区間はPlayItemと呼ばれる。PlayItemは、時間軸上の再生区間のIN点とOUT点のペアで表される。図８に示すように、PlayListは１つまたは複数のPlayItemにより構成される。
【００８４】
図８の左から１番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームの前半部分と後半部分がそれぞれ参照されている。
【００８５】
左から２番目のPlayListは１つのPlayItemから構成され、それにより、右側のClipに含まれるAVストリーム全体が参照されている。
【００８６】
左から３番目のPlayListは２つのPlayItemから構成され、その２つのPlayItemにより、左側のClipに含まれるAVストリームのある部分と、右側のClipに含まれるAVストリームのある部分がそれぞれ参照されている。
【００８７】
例えば、左から１番目のPlayListに含まれる左側のPlayItemが再生対象としてディスクナビゲーションプログラムにより指定された場合、そのPlayItemが参照する、左側のClipに含まれるAVストリームの前半部分の再生が行われる。このように、PlayListは、AVストリームの再生を管理するための再生管理情報として用いられる。
【００８８】
PlayListの中で、１つ以上のPlayItemの並びによって作られる再生パスをメインパス(Main Path)という。
【００８９】
また、PlayListの中で、Main Pathに並行して、１つ以上のSubPlayItemの並びによって作られる再生パスをサブパス（Sub Path）という。
【００９０】
図９は、Main PathとSub Pathの構造を示す図である。
【００９１】
PlayListは、１つのMain Pathと１つ以上のSub Pathを持つことができる。
【００９２】
上述したBase view videoストリームは、Main Pathを構成するPlayItemが参照するストリームとして管理される。また、Dependent view videoストリームは、Sub Pathを構成するSubPlayItemが参照するストリームとして管理される。
【００９３】
図９のPlayListは、３つのPlayItemの並びにより作られる１つのMain Pathと、３つのSub Pathを有している。
【００９４】
Main Pathを構成するPlayItemには、先頭から順番にそれぞれIDが設定される。Sub Pathにも、先頭から順番にSubpath_id=0、Subpath_id=1、およびSubpath_id=2のIDが設定される。
【００９５】
図９の例においては、Subpath_id=0のSub Pathには１つのSubPlayItemが含まれ、Subpath_id=1のSub Pathには２つのSubPlayItemが含まれる。また、Subpath_id=2のSub Pathには１つのSubPlayItemが含まれる。
【００９６】
１つのPlayItemが参照するClip AVストリームには、少なくともビデオストリーム（メイン画像データ）が含まれる。
【００９７】
また、Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同じタイミングで（同期して）再生されるオーディオストリームが１つ以上含まれてもよいし、含まれなくてもよい。
【００９８】
Clip AVストリームには、Clip AVストリームに含まれるビデオストリームと同期して再生されるビットマップの字幕データ（PG(Presentation Graphic)）のストリームが１つ以上含まれてもよいし、含まれなくてもよい。
【００９９】
Clip AVストリームには、Clip AVストリームファイルに含まれるビデオストリームと同期して再生されるIG(Interactive Graphic)のストリームが１つ以上含まれてもよいし、含まれなくてもよい。IGのストリームは、ユーザにより操作されるボタンなどのグラフィックを表示させるために用いられる。
【０１００】
１つのPlayItemが参照するClip AVストリームには、ビデオストリームと、それと同期して再生される０個以上のオーディオストリーム、０個以上のPGストリーム、および、０個以上のIGストリームが多重化されている。
【０１０１】
また、１つのSubPlayItemは、PlayItemが参照するClip AVストリームとは異なるストリーム（別ストリーム）の、ビデオストリーム、オーディオストリーム、または、PGストリームなどを参照する。
【０１０２】
このようなPlayList、PlayItem、SubPlayItemを使ったAVストリームの管理については、例えば、特開２００８−２５２７４０号公報、特開２００５−３４８３１４号公報に記載されている。
【０１０３】
［ディレクトリ構造］
図１０は、光ディスク２に記録されるファイルの管理構造の例を示す図である。
【０１０４】
図１０に示すように、ファイルはディレクトリ構造により階層的に管理される。光ディスク２上には１つのrootディレクトリが作成される。rootディレクトリの下が、１つの記録再生システムで管理される範囲となる。
【０１０５】
rootディレクトリの下にはBDMVディレクトリが置かれる。
【０１０６】
BDMVディレクトリの直下に、「Index.bdmv」の名前が設定されたファイルであるIndexファイルと、「MovieObject.bdmv」の名前が設定されたファイルであるMovieObjectファイルが格納される。
【０１０７】
BDMVディレクトリの下には、BACKUPディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ等が設けられる。
【０１０８】
PLAYLISTディレクトリには、PlayListを記述したPlayListファイルが格納される。各PlayListファイルには、５桁の数字と拡張子「.mpls」を組み合わせた名前が設定される。図１０に示す１つのPlayListファイルには「00000.mpls」のファイル名が設定されている。
【０１０９】
CLIPINFディレクトリにはClip Informationファイルが格納される。各Clip Informationファイルには、５桁の数字と拡張子「.clpi」を組み合わせた名前が設定される。
【０１１０】
図１０の３つのClip Informationファイルには、それぞれ、「00001.clpi」、「00002.clpi」、「00003.clpi」のファイル名が設定されている。以下、適宜、Clip Informationファイルをclpiファイルという。
【０１１１】
例えば、「00001.clpi」のclpiファイルは、Base view videoのClipに関する情報が記述されたファイルである。
【０１１２】
「00002.clpi」のclpiファイルは、D2 view videoのClipに関する情報が記述されたファイルである。
【０１１３】
「00003.clpi」のclpiファイルは、D1 view videoのClipに関する情報が記述されたファイルである。
【０１１４】
STREAMディレクトリにはストリームファイルが格納される。各ストリームファイルには、５桁の数字と拡張子「.m2ts」を組み合わせた名前、もしくは、５桁の数字と拡張子「.ilvt」を組み合わせた名前が設定される。以下、適宜、拡張子「.m2ts」が設定されたファイルをm2tsファイルという。また、拡張子「.ilvt」が設定されたファイルをilvtファイルという。
【０１１５】
「00001.m2ts」のm2tsファイルは2D再生用のファイルであり、このファイルを指定することによってBase view videoストリームの読み出しが行われる。
【０１１６】
「00002.m2ts」のm2tsファイルはD2 view videoストリームのファイルであり、「00003.m2ts」のm2tsファイルはD1 view videoストリームのファイルである。
【０１１７】
「10000.ilvt」のilvtファイルはB-D1再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD1 view videoストリームの読み出しが行われる。
【０１１８】
「20000.ilvt」のilvtファイルはB-D2再生用のファイルであり、このファイルを指定することによってBase view videoストリームとD2 view videoストリームの読み出しが行われる。
【０１１９】
図１０に示すものの他に、BDMVディレクトリの下には、オーディオストリームのファイルを格納するディレクトリなども設けられる。
【０１２０】
［各データのシンタクス］
図１１は、PlayListファイルのシンタクスを示す図である。
【０１２１】
PlayListファイルは、図１０のPLAYLISTディレクトリに格納される、拡張子「.mpls」が設定されるファイルである。
【０１２２】
図１１のtype_indicatorは、「xxxxx.mpls」のファイルの種類を表す。
【０１２３】
version_numberは、「xxxx.mpls」のバージョンナンバーを表す。version_numberは４桁の数字からなる。例えば、3D再生用のPlayListファイルには、「3D Spec version」であることを表す“0240”が設定される。
【０１２４】
PlayList_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayList()の先頭アドレスを表す。
【０１２５】
PlayListMark_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMark()の先頭アドレスを表す。
【０１２６】
ExtensionData_start_addressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、ExtensionData()の先頭アドレスを表す。
【０１２７】
ExtensionData_start_addressの後には、１６０bitのreserved_for_future_useが含まれる。
【０１２８】
AppInfoPlayList()には、再生制限などの、PlayListの再生コントロールに関するパラメータが格納される。
【０１２９】
PlayList()には、Main PathやSub Pathなどに関するパラメータが格納される。PlayList()の内容については後述する。
【０１３０】
PlayListMark()には、PlayListのマーク情報、すなわち、チャプタジャンプなどを指令するユーザオペレーションまたはコマンドなどにおけるジャンプ先（ジャンプポイント）であるマークに関する情報が格納される。
【０１３１】
ExtensionData()には、プライベートデータが挿入できるようになっている。
【０１３２】
図１２は、PlayListファイルの記述の具体例を示す図である。
【０１３３】
図１２に示すように、PlayListファイルには２bitの3D_PL_typeと１bitのview_typeが記述される。
【０１３４】
3D_PL_typeは、PlayListの種類を表す。
【０１３５】
view_typeは、PlayListによって再生が管理されるBase view videoストリームが、L画像（L view）のストリームであるのか、R画像（R view）のストリームであるのかを表す。
【０１３６】
図１３は、3D_PL_typeの値の意味を示す図である。
【０１３７】
3D_PL_typeの値の00は、2D再生用のPlayListであることを表す。
【０１３８】
3D_PL_typeの値の01は、3D再生のうちのB-D1再生用のPlayListであることを表す。
【０１３９】
3D_PL_typeの値の10は、3D再生のうちのB-D2再生用のPlayListであることを表す。
【０１４０】
例えば、3D_PL_typeの値が01か10の場合には、PlayListファイルのExtenstionData()に3DPlayList情報が登録される。例えば、3DPlayList情報として、Base view videoストリームとDependent view videoストリームの光ディスク２からの読み出しに関する情報が登録される。
【０１４１】
図１４は、view_typeの値の意味を示す図である。
【０１４２】
view_typeの値の0は、3D再生を行う場合には、Base view videoストリームがL viewのストリームであることを表す。2D再生を行う場合には、Base view videoストリームがAVCビデオストリームであることを表す。
【０１４３】
view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０１４４】
view_typeがPlayListファイルに記述されることにより、再生装置１は、Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することが可能になる。
【０１４５】
例えば、HDMIケーブルを介して表示装置３にビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが再生装置１に要求されるものと考えられる。
【０１４６】
Base view videoストリームがL viewのストリームであるのかR viewのストリームであるのかを識別することができるようにすることにより、再生装置１は、L viewの信号とR viewの信号を区別して出力することが可能になる。
【０１４７】
図１５は、図１１のPlayList()のシンタクスを示す図である。
【０１４８】
lengthは、このlengthフィールドの直後からPlayList()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
【０１４９】
lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１５０】
number_of_PlayItemsは、PlayListの中にあるPlayItemの数を示す１６ビットのフィールドである。図９の例の場合、PlayItemの数は３である。PlayItem_idの値は、PlayListの中でPlayItem()が現れる順番に０から割り振られる。例えば、図９のPlayItem_id＝０，１，２が割り振られる。
【０１５１】
number_of_SubPathsは、PlayListの中にあるSub Pathの数を示す１６ビットのフィールドである。図９の例の場合、Sub Pathの数は３である。SubPath_idの値は、PlayListの中でSubPath()が現れる順番に０から割り振られる。例えば、図９のSubpath_id＝０，１，２が割り振られる。その後のfor文では、PlayItemの数だけPlayItem()が参照され、Sub Pathの数だけSubPath()が参照される。
【０１５２】
図１６は、図１５のSubPath()のシンタクスを示す図である。
【０１５３】
lengthは、このlengthフィールドの直後からSub Path()の最後までのバイト数を示す３２ビットの符号なし整数である。すなわち、lengthは、reserved_for_future_useからPlayListの最後までのバイト数を表す。
【０１５４】
lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１５５】
SubPath_typeは、Sub Pathのアプリケーションの種類を示す８ビットのフィールドである。SubPath_typeは、例えば、Sub Pathがオーディオであるか、ビットマップ字幕であるか、テキスト字幕であるかなどの種類を示す場合に利用される。
【０１５６】
SubPath_typeの後には、１５ビットのreserved_for_future_useが用意される。
【０１５７】
is_repeat_SubPathは、Sub Pathの再生方法を指定する１ビットのフィールドであり、Main Pathの再生の間にSub Pathの再生を繰り返し行うか、またはSub Pathの再生を１回だけ行うかを示す。例えば、Main Pathが参照するClipとSub Pathが参照するClipの再生タイミングが異なる場合（Main Pathを静止画のスライドショーのパスとし、Sub PathをBGMとするオーディオのパスとして使う場合など）に利用される。
【０１５８】
Is_repeat_SubPathの後には、８ビットのreserved_for_future_useが用意される。
【０１５９】
number_of_SubPlayItemsは、１つのSub Pathの中にあるSubPlayItemの数（エントリー数）を示す８ビットのフィールドである。例えば、図９のSubPath_id＝０のSubPlayItemのnumber_of_SubPlayItemsは１であり、SubPath_id＝１のSubPlayItemのnumber_of_SubPlayItemsは２である。その後のfor文では、SubPlayItemの数だけ、SubPlayItem（）が参照される。
【０１６０】
図１７は、図１６のSubPlayItem(i)のシンタクスを示す図である。
【０１６１】
lengthは、このlengthフィールドの直後からSub playItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
【０１６２】
図１７のSubPlayItem(i)は、SubPlayItemが１つのClipを参照する場合と、複数のClipを参照する場合に分けて記述されている。
【０１６３】
SubPlayItemが１つのClipを参照する場合について説明する。
【０１６４】
Clip_Information_file_name[0]は参照するClipを表す。
【０１６５】
Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。
【０１６６】
is_multi_Clip_entriesはマルチClipの登録の有無を示すフラグである。is_multi_Clip_entriesのフラグが立っている場合、SubPlayItemが複数のClipを参照する場合のシンタクスが参照される。
【０１６７】
ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
【０１６８】
SubPlayItem_IN_timeはSub Pathの再生区間の開始位置を表し、SubPlayItem_OUT_timeは終了位置を表す。
【０１６９】
sync_PlayItem_idとsync_start_PTS_of_PlayItemは、Main Pathの時間軸上でSub Pathが再生を開始する時刻を表す。
【０１７０】
SubPlayItem_IN_time、SubPlayItem_OUT_time、sync_PlayItem_id、sync_start_PTS_of_PlayItemは、SubPlayItemが参照するClipにおいて共通に使用される。
【０１７１】
「if（is_multi_Clip_entries＝＝１ｂ」であり、SubPlayItemが複数のClipを参照する場合について説明する。
【０１７２】
num_of_Clip_entriesは参照するClipの数を表す。Clip_Information_file_name[SubClip_entry_id]の数が、Clip_Information_file_name[0]を除くClipの数を指定する。
【０１７３】
Clip_codec_identifier[SubClip_entry_id]はClipのコーデック方式を表す。
【０１７４】
ref_to_STC_id[SubClip_entry_id]はSTC不連続点（システムタイムベースの不連続点）に関する情報である。ref_to_STC_id[SubClip_entry_id]の後にはreserved_for_future_useが含まれる。
【０１７５】
図１８は、図１５のPlayItem()のシンタクスを示す図である。
【０１７６】
lengthは、このlengthフィールドの直後からPlayItem()の最後までのバイト数を示す１６ビットの符号なし整数である。
【０１７７】
Clip_Information_file_name[0]は、PlayItemが参照するClipのClip Informationファイルの名前を表す。なお、Clipを含むmt2sファイルのファイル名と、それに対応するClip Informationファイルのファイル名には同じ５桁の数字が含まれる。
【０１７８】
Clip_codec_identifier［0］はClipのコーデック方式を表す。Clip_codec_identifier［0］の後にはreserved_for_future_useが含まれる。reserved_for_future_useの後にはis_multi_angle、connection_conditionが含まれる。
【０１７９】
ref_to_STC_id［0］はSTC不連続点（システムタイムベースの不連続点）に関する情報である。
【０１８０】
IN_timeはPlayItemの再生区間の開始位置を表し、OUT_timeは終了位置を表す。
【０１８１】
OUT_timeの後にはUO_mask_table()、PlayItem_random_access_mode、still_modeが含まれる。
【０１８２】
STN_table()には、対象のPlayItemが参照するAVストリームの情報が含まれる。また、対象のPlayItemと関連付けて再生されるSub Pathがある場合、そのSub Pathを構成するSubPlayItemが参照するAVストリームの情報も含まれる。
【０１８３】
図１９は、図１８のSTN_table()のシンタクスを示す図である。
【０１８４】
STN_table()は、PlayItemの属性として設定されている。
【０１８５】
lengthは、このlengthフィールドの直後からSTN_table()の最後までのバイト数を示す１６ビットの符号なし整数である。lengthの後には、１６ビットのreserved_for_future_useが用意される。
【０１８６】
number_of_video_stream_entriesは、STN_table()の中でエントリーされる（登録される）、video_stream_idが与えられるストリームの数を表す。
【０１８７】
video_stream_idは、ビデオストリームを識別するための情報である。例えば、Base view videoストリームがこのvideo_stream_idにより特定される。
【０１８８】
Dependent view videoストリームのIDについては、STN_table()内で定義されるようにしてもよいし、Base view videoストリームのIDに所定の値を加算するなどして計算により求められるようにしてもよい。
【０１８９】
video_stream_numberは、ビデオ切り替えに使われる、ユーザから見えるビデオストリーム番号である。
【０１９０】
number_of_audio_stream_entriesは、STN_table()の中でエントリーされる、audio_stream_idが与えられる１番目のオーディオストリームのストリームの数を表す。audio_stream_idは、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。
【０１９１】
number_of_audio_stream2_entriesは、STN_table()の中でエントリーされる、audio_stream_id2が与えられる２番目のオーディオストリームのストリームの数を表す。audio_stream_id2は、オーディオストリームを識別するための情報であり、audio_stream_numberは、音声切り替えに使われるユーザから見えるオーディオストリーム番号である。この例においては、再生する音声を切り替えることができるようになされている。
【０１９２】
number_of_PG_txtST_stream_entriesは、STN_table()の中でエントリーされる、PG_txtST_stream_idが与えられるストリームの数を表す。この中では、ビットマップ字幕をランレングス符号化したPGストリームとテキスト字幕ファイル(txtST)がエントリーされる。PG_txtST_stream_idは、字幕ストリームを識別するための情報であり、PG_txtST_stream_numberは、字幕切り替えに使われるユーザから見える字幕ストリーム番号である。
【０１９３】
number_of_IG_stream_entriesは、STN_table()の中でエントリーされる、IG_stream_idが与えられるストリームの数を表す。この中ではIGストリームがエントリーされる。IG_stream_idは、IGストリームを識別するための情報であり、IG_stream_numberは、グラフィックス切り替えに使われるユーザから見えるグラフィックスストリーム番号である。
【０１９４】
Main TS、Sub TSのIDもSTN_table()に登録される。そのIDがエレメンタリストリームではなくTSのIDであることは、stream_attribute()に記述される。
【０１９５】
［再生装置１の構成例］
図２０は、再生装置１の構成例を示すブロック図である。
【０１９６】
コントローラ５１は、予め用意されている制御プログラムを実行し、再生装置１の全体の動作を制御する。
【０１９７】
例えば、コントローラ５１は、ディスクドライブ５２を制御し、3D再生用のPlayListファイルを読み出す。また、コントローラ５１は、STN_tableに登録されているIDに基づいて、Main TSとSubTSを読み出させ、デコーダ部５６に供給させる。
【０１９８】
ディスクドライブ５２は、コントローラ５１による制御に従って光ディスク２からデータを読み出し、読み出したデータを、コントローラ５１、メモリ５３、またはデコーダ部５６に出力する。
【０１９９】
メモリ５３は、コントローラ５１が各種の処理を実行する上において必要なデータなどを適宜記憶する。
【０２００】
ローカルストレージ５４は例えばHDD(Hard Disk Drive)により構成される。ローカルストレージ５４には、サーバ７２からダウンロードされたDependent view videoストリームなどが記録される。ローカルストレージ５４に記録されているストリームもデコーダ部５６に適宜供給される。
【０２０１】
インターネットインタフェース５５は、コントローラ５１からの制御に従ってネットワーク７１を介してサーバ７２と通信を行い、サーバ７２からダウンロードしたデータをローカルストレージ５４に供給する。
【０２０２】
サーバ７２からは、光ディスク２に記録されているデータをアップデートさせるデータがダウンロードされる。ダウンロードしたDependent view videoストリームを光ディスク２に記録されているBase view videoストリームと併せて用いることができるようにすることにより、光ディスク２の内容とは異なる内容の3D再生を実現することが可能になる。Dependent view videoストリームがダウンロードされたとき、PlayListの内容も適宜更新される。
【０２０３】
デコーダ部５６は、ディスクドライブ５２、またはローカルストレージ５４から供給されたストリームをデコードし、得られたビデオ信号を表示装置３に出力する。オーディオ信号も所定の経路を介して表示装置３に出力される。
【０２０４】
操作入力部５７は、ボタン、キー、タッチパネル、ジョグダイヤル、マウスなどの入力デバイスや、所定のリモートコマンダから送信される赤外線などの信号を受信する受信部により構成される。操作入力部５７はユーザの操作を検出し、検出した操作の内容を表す信号をコントローラ５１に供給する。
【０２０５】
図２１は、デコーダ部５６の構成例を示す図である。
【０２０６】
図２１においてはビデオ信号の処理を行う構成が示されている。デコーダ部５６においては、オーディオ信号のデコード処理も行われる。オーディオ信号を対象として行われたデコード処理の結果は、図示せぬ経路を介して表示装置３に出力される。
【０２０７】
PIDフィルタ１０１は、ディスクドライブ５２、またはローカルストレージ５４から供給されたTSがMain TSであるかSub TSであるかを、TSを構成するパケットのPIDやストリームのIDなどに基づいて識別する。PIDフィルタ１０１は、Main TSをバッファ１０２に出力し、Sub TSをバッファ１０３に出力する。
【０２０８】
PIDフィルタ１０４は、バッファ１０２に記憶されたMain TSのパケットを順次読み出し、PIDに基づいて振り分ける。
【０２０９】
例えば、PIDフィルタ１０４は、Main TSに含まれているBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２１０】
また、PIDフィルタ１０４は、Main TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
【０２１１】
PIDフィルタ１０４は、Main TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
【０２１２】
図５を参照して説明したように、Base view video、Dependent view video、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがMain TSに多重化されていることがある。
【０２１３】
PIDフィルタ１０５は、バッファ１０３に記憶されたSub TSのパケットを順次読み出し、PIDに基づいて振り分ける。
【０２１４】
例えば、PIDフィルタ１０５は、Sub TSに含まれているDependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２１５】
また、PIDフィルタ１０５は、Sub TSに含まれているBase IGストリームを構成するパケットをスイッチ１１４に出力し、Dependent IGストリームを構成するパケットをスイッチ１１８に出力する。
【０２１６】
PIDフィルタ１０５は、Sub TSに含まれているBase PGストリームを構成するパケットをスイッチ１２２に出力し、Dependent PGストリームを構成するパケットをスイッチ１２６に出力する。
【０２１７】
図７を参照して説明したように、Dependent view videoストリームがSub TSに含まれていることがある。また、図６を参照して説明したように、Base PG、Dependent PG、Base IG、Dependent IGのそれぞれのストリームがSub TSに多重化されていることがある。
【０２１８】
スイッチ１０７は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent view videoストリームを構成するパケットをD videoバッファ１０８に出力する。
【０２１９】
スイッチ１０９は、B videoバッファ１０６に記憶されたBase view videoのパケットと、D videoバッファ１０８に記憶されたDependent view videoのパケットを、デコードのタイミングを規定する時刻情報に従って順次読み出す。Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには例えば同じ時刻情報が設定されている。
【０２２０】
スイッチ１０９は、B videoバッファ１０６、またはD videoバッファ１０８から読み出したパケットをビデオデコーダ１１０に出力する。
【０２２１】
ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットをデコードし、デコードすることによって得られたBase view video、またはDependent view videoのデータをスイッチ１１１に出力する。
【０２２２】
スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０２２３】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２２４】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２２５】
スイッチ１１４は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase IGストリームを構成するパケットをB IGバッファ１１５に出力する。
【０２２６】
B IGデコーダ１１６は、B IGバッファ１１５に記憶されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
【０２２７】
B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２２８】
スイッチ１１８は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent IGストリームを構成するパケットをD IGバッファ１１９に出力する。
【０２２９】
D IGデコーダ１２０は、D IGバッファ１１９に記憶されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。
【０２３０】
D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２３１】
スイッチ１２２は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたBase PGストリームを構成するパケットをB PGバッファ１２３に出力する。
【０２３２】
B PGデコーダ１２４は、B PGバッファ１２３に記憶されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
【０２３３】
B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２３４】
スイッチ１２６は、PIDフィルタ１０４、またはPIDフィルタ１０５から供給されたDependent PGストリームを構成するパケットをD PGバッファ１２７に出力する。
【０２３５】
D PGデコーダ１２８は、D PGバッファ１２７に記憶されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。
【０２３６】
D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２３７】
合成部１３０は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンと、B IGプレーン生成部１１７から供給されたBase IGのプレーンと、B PGプレーン生成部１２５から供給されたBase PGのプレーンを所定の順番で重ねることによって合成し、Base viewのプレーンを生成する。
【０２３８】
また、合成部１３０は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンと、D IGプレーン生成部１２１から供給されたDependent IGのプレーンと、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを所定の順番で重ねることによって合成し、Dependent viewのプレーンを生成する。
【０２３９】
合成部１３０は、Base viewのプレーンとDependent viewのプレーンのデータを出力する。合成部１３０から出力されたビデオデータは表示装置３に出力され、Base viewのプレーンとDependent viewのプレーンが交互に表示されることによって3D表示が行われる。
【０２４０】
［T-STD(Transport stream-System. Target Decoder)の第１の例］
ここで、図２１に示す構成のうちの、デコーダと、その周辺の構成について説明する。
【０２４１】
図２２は、ビデオストリームの処理を行う構成を示す図である。
【０２４２】
図２２において、図２１に示す構成と同じ構成には同じ符号を付してある。図２２においては、PIDフィルタ１０４、B videoバッファ１０６、スイッチ１０７、D videoバッファ１０８、スイッチ１０９、ビデオデコーダ１１０、およびDPB(Decoded Picture Buffer)１５１が示されている。図２１には示していないが、ビデオデコーダ１１０の後段には、デコード済みのピクチャのデータが記憶されるDPB１５１が設けられる。
【０２４３】
PIDフィルタ１０４は、Main TSに含まれるBase view videoストリームを構成するパケットをB videoバッファ１０６に出力し、Dependent view videoストリームを構成するパケットをスイッチ１０７に出力する。
【０２４４】
例えば、Base view videoストリームを構成するパケットには、PID=0がPIDの固定値として割り当てられている。また、Dependent view videoストリームを構成するパケットには、0以外の固定の値がPIDとして割り当てられている。
【０２４５】
PIDフィルタ１０４は、PID=0がヘッダに記述されているパケットをB videoバッファ１０６に出力し、0以外のPIDがヘッダに記述されているパケットをスイッチ１０７に出力する。
【０２４６】
B videoバッファ１０６に出力されたパケットは、TB(Transport Buffer)1、MB(Multiplexing Buffer)1を介してVSB1に記憶される。VSB1には、Base view videoのエレメンタリストリームのデータが記憶される。
【０２４７】
スイッチ１０７には、PIDフィルタ１０４から出力されたパケットだけでなく、図２１のPIDフィルタ１０５においてSub TSから抽出されたDependent view videoストリームを構成するパケットも供給される。
【０２４８】
スイッチ１０７は、PIDフィルタ１０４からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２４９】
また、スイッチ１０７は、PIDフィルタ１０５からDependent view videoストリームを構成するパケットが供給された場合、それをD videoバッファ１０８に出力する。
【０２５０】
D videoバッファ１０８に出力されたパケットは、TB2、MB2を介してVSB2に記憶される。VSB2には、Dependent view videoのエレメンタリストリームのデータが記憶される。
【０２５１】
スイッチ１０９は、B videoバッファ１０６のVSB1に記憶されたBase view videoのパケットと、D videoバッファ１０８のVSB2に記憶されたDependent view videoのパケットを順次読み出し、ビデオデコーダ１１０に出力する。
【０２５２】
例えば、スイッチ１０９は、ある時刻のBase view videoのパケットを出力した直後にそれと同じ時刻のDependent view videoのパケットを出力するといったように、同じ時刻のBase view videoのパケットとDependent view videoのパケットを続けてビデオデコーダ１１０に出力する。
【０２５３】
Base view videoのあるピクチャのデータを格納したパケットと、それに対応するDependent view videoのピクチャのデータを格納したパケットには、そのエンコード時に、PCR(Program Clock Reference)同期が確保された同じ時刻情報が設定されている。Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれている場合であっても、対応するピクチャのデータを格納したパケットには同じ時刻情報が設定される。
【０２５４】
時刻情報はDTS(Decoding Time Stamp)、PTS(Presentation Time Stamp)であり、各PES(Packetized Elementary Stream)パケットに設定される。
【０２５５】
すなわち、それぞれのストリームのピクチャをエンコード順／デコード順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャが、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じDTSが設定されている。
【０２５６】
また、それぞれのストリームのピクチャを表示順に並べたときに同じ時刻に位置するBase view videoのピクチャとDependent view videoのピクチャも、対応するピクチャとなる。あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットには、同じPTSが設定されている。
【０２５７】
後述するようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造が同じ構造である場合、デコード順で対応するピクチャは、表示順でも対応するピクチャになる。
【０２５８】
パケットの転送がシリアルで行われる場合、あるタイミングでB videoバッファ１０６のVSB1から読み出されたパケットのDTS1と、直後のタイミングでD videoバッファ１０８のVSB2から読み出されたパケットのDTS2は、図２２に示すように同じ時刻を表すものになる。
【０２５９】
スイッチ１０９は、B videoバッファ１０６のVSB1から読み出したBase view videoのパケット、または、D videoバッファ１０８のVSB2から読み出したDependent view videoのパケットをビデオデコーダ１１０に出力する。
【０２６０】
ビデオデコーダ１１０は、スイッチ１０９から供給されたパケットを順次デコードし、デコードして得られたBase view videoのピクチャのデータ、または、Dependent view videoのピクチャのデータをDPB１５１に記憶させる。
【０２６１】
DPB１５１に記憶されたデコード済みのピクチャのデータは、所定のタイミングでスイッチ１１１により読み出される。また、DPB１５１に記憶されたデコード済みのピクチャのデータは、他のピクチャの予測にビデオデコーダ１１０により用いられる。
【０２６２】
データの転送がシリアルで行われる場合、あるタイミングで出力されたBase view videoのピクチャのデータのPTSと、直後のタイミングで出力されたDependent view videoのピクチャのデータのPTSは、同じ時刻を表すものになる。
【０２６３】
Base view videoストリームとDependent view videoストリームは図５等を参照して説明したように１本のTSに多重化される場合があるし、図７を参照して説明したようにそれぞれ異なるTSに含まれることがある。
【０２６４】
図２２のデコーダモデルを実装することにより、再生装置１は、Base view videoストリームとDependent view videoストリームが１本のTSに多重化されている場合であっても、それぞれ異なるTSに含まれる場合であっても、対応することが可能になる。
【０２６５】
例えば図２３に示すように１本のTSが供給される状況しか想定されていない場合、Base view videoストリームとDependent view videoストリームがそれぞれ異なるTSに含まれる場合などには対応することができない。
【０２６６】
また、図２２のデコーダモデルによれば、同じDTSを持つことから、Base view videoストリームとDependent view videoストリームが異なるTSに含まれる場合であっても、正しいタイミングでビデオデコーダ１１０にパケットを供給することができる。
【０２６７】
Base view video用のデコーダとDependent view video用のデコーダをそれぞれ並列に設けるようにしてもよい。この場合、Base view video用のデコーダとDependent view video用のデコーダには、それぞれ、同じ時刻のパケットが同じタイミングで供給される。
【０２６８】
［第２の例］
図２４は、ビデオストリームの処理を行う他の構成を示す図である。
【０２６９】
図２４においては、図２２の構成に加えて、スイッチ１１１、L videoプレーン生成部１６１、およびR videoプレーン生成部１６２が示されている。また、PIDフィルタ１０５もスイッチ１０７の前段に示されている。重複する説明については適宜省略する。
【０２７０】
L videoプレーン生成部１６１は、L view videoのプレーンを生成するものであり、図２１のB videoプレーン生成部１１２に替えて設けられる。
【０２７１】
R videoプレーン生成部１６２は、R view videoのプレーンを生成するものであり、図２１のD videoプレーン生成部１１３に替えて設けられる。
【０２７２】
この例においては、スイッチ１１１は、L viewのビデオデータとR viewのビデオデータを識別して出力する必要があることになる。
【０２７３】
すなわち、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
【０２７４】
また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータがL viewとR viewのいずれのビデオデータであるのかを識別する必要がある。
【０２７５】
L viewとR viewの識別には、図１２と図１４を参照して説明したview_typeが用いられる。例えば、コントローラ５１は、PlayListファイルに記述されているview_typeをスイッチ１１１に出力する。
【０２７６】
view_typeの値が0である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。上述したように、view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
【０２７７】
この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
【０２７８】
一方、view_typeの値が1である場合、スイッチ１１１は、DPB１５１に記憶されたデータのうち、PID=0で識別されるBase view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０２７９】
この場合、スイッチ１１１は、0以外のPIDで識別されるDependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
【０２８０】
L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８１】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０２８２】
H.264 AVC/MVCでエンコードされたBase view video、Dependent view videoのエレメンタリストリーム内には、L viewであるのか、またはR viewであるのかを表す情報（フィールド）が存在しない。
【０２８３】
従って、view_typeをPlayListファイルに設定しておくことにより、記録装置は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを再生装置１に識別させることが可能になる。
【０２８４】
再生装置１は、Base view videoストリームとDependent view videoストリームがそれぞれL viewとR viewのいずれのストリームであるのかを識別し、識別結果に応じて出力先を切り替えることができる。
【０２８５】
IG、PGのプレーンについてもそれぞれL viewとR viewが用意されている場合、ビデオストリームのL viewとR viewを区別できることにより、再生装置１はL view同士、R view同士のプレーンの合成を容易に行うことができる。
【０２８６】
上述したように、HDMIケーブルを介してビデオ信号を出力する場合、L viewの信号とR viewの信号とをそれぞれ区別した上で出力することが要求されるが、再生装置１はその要求に対応することが可能になる。
【０２８７】
DPB１５１に記憶されたBase view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの識別が、PIDではなく、view_idに基づいて行われるようにしてもよい。
【０２８８】
H.264 AVC/MVCでのエンコード時、エンコード結果のストリームを構成するAccess Unitにはview_idが設定される。view_idにより、各Access Unitがどのview componentのユニットであるのかが識別可能になっている。
【０２８９】
図２５は、Access Unitの例を示す図である。
【０２９０】
図２５のAccess Unit＃１はBase view videoのデータを含むユニットである。Access Unit＃２はDependent view videoのデータを含むユニットである。Access Unitはピクチャ単位でのアクセスが可能になるように、例えば１枚のピクチャのデータをまとめたユニットである。
【０２９１】
H.264 AVC/MVCでのエンコードが行われることによって、Base view videoとDependent view videoの各ピクチャのデータは、このようなAccess Unitに格納される。H.264 AVC/MVCでのエンコード時、Access Unit＃２内に示すように、それぞれのview componentにはMVCヘッダが付加される。MVCヘッダにはview_idが含まれる。
【０２９２】
図２５の例の場合、Access Unit＃２については、そのAccess Unitに格納されるview componentがDependent view videoであることをview_idから識別することが可能になる。
【０２９３】
一方、図２５に示すように、Access Unit＃１に格納されたview componentであるBase view videoにはMVCヘッダが付加されていない。
【０２９４】
上述したようにBase view videoストリームは2D再生にも用いられるデータである。従って、それとの互換性を確保するために、Base view videoにはエンコード時にMVCヘッダが付加されない。あるいは、一度付加されたMVCヘッダが除去される。記録装置によるエンコードについては後述する。
【０２９５】
再生装置１には、MVCヘッダが付加されていないview componentについては、そのview_idが0であり、view componentをBase view videoであるとして認識するように定義（設定）されている。Dependent view videoには、0以外の値がview_idとしてエンコード時に設定される。
【０２９６】
これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
【０２９７】
図２４のスイッチ１１１においては、Base view videoのパケットをデコードして得られたデータとDependent view videoのパケットをデコードして得られたデータの識別が、このようなview_idに基づいて行われるようにしてもよい。
【０２９８】
［第３の例］
図２６は、ビデオストリームの処理を行うさらに他の構成を示す図である。
【０２９９】
図２６の例においては、図２４のL videoプレーン生成部１６１に替えてB videoプレーン生成部１１２が設けられ、R videoプレーン生成部１６２に替えてD videoプレーン生成部１１３が設けられている。B videoプレーン生成部１１２とD videoプレーン生成部１１３の後段にはスイッチ１７１が設けられている。図２６に示す構成においても、view_typeに基づいてデータの出力先が切り替えられるようになされている。
【０３００】
スイッチ１１１は、DPB１５１に記憶されたデータのうち、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力する。また、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０３０１】
Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータは、上述したようにPID、またはview_idに基づいて識別される。
【０３０２】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３０３】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３０４】
スイッチ１７１に対しては、PlayListファイルに記述されているview_typeがコントローラ５１から供給されている。
【０３０５】
view_typeの値が0である場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の0は、Base view videoストリームがL viewのストリームであることを表す。
【０３０６】
また、この場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０３０７】
一方、view_typeの値が1である場合、スイッチ１７１は、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンをL view videoのプレーンとして合成部１３０に出力する。view_typeの値の1は、Base view videoストリームがR viewのストリームであることを表す。
【０３０８】
また、この場合、スイッチ１７１は、B videoプレーン生成部１１２から供給されたBase view videoのプレーンをR view videoのプレーンとして合成部１３０に出力する。
【０３０９】
図２６の構成によっても、再生装置１は、L viewとR viewを識別し、識別結果に応じて出力先を切り替えることができる。
【０３１０】
［プレーン合成モデルの第１の例］
図２７は、図２１に示す構成のうちの、合成部１３０と、その前段の構成を示す図である。
【０３１１】
図２７においても、図２１に示す構成と同じ構成には同じ符号を付してある。
【０３１２】
スイッチ１８１には、Main TS、またはSub TSに含まれるIGストリームを構成するパケットが入力される。スイッチ１８１に入力されるIGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３１３】
スイッチ１８２には、Main TS、またはSub TSに含まれるPGストリームを構成するパケットが入力される。スイッチ１８２に入力されるPGストリームを構成するパケットには、Base viewのパケットとDependent viewのパケットが含まれる。
【０３１４】
図５等を参照して説明したように、IG、PGについても、3D表示を行うためのBase viewのストリームとDependent viewのストリームが用意されている。
【０３１５】
Base viewのIGがBase view videoと合成して表示され、Dependent viewのIGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、ボタンやアイコンなどを3Dで見ることになる。
【０３１６】
また、Base viewのPGがBase view videoと合成して表示され、Dependent viewのPGがDependent view videoと合成して表示されることにより、ユーザは、ビデオだけでなく、字幕のテキストなどを3Dで見ることになる。
【０３１７】
スイッチ１８１は、Base IGストリームを構成するパケットをB IGデコーダ１１６に出力し、Dependent IGストリームを構成するパケットをD IGデコーダ１２０に出力する。スイッチ１８１は、図２１のスイッチ１１４とスイッチ１１８の機能を有する。図２７においては、各バッファの図示を省略している。
【０３１８】
B IGデコーダ１１６は、スイッチ１８１から供給されたBase IGストリームを構成するパケットをデコードし、デコードして得られたデータをB IGプレーン生成部１１７に出力する。
【０３１９】
B IGプレーン生成部１１７は、Base IGのプレーンをB IGデコーダ１１６から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３２０】
D IGデコーダ１２０は、スイッチ１８１から供給されたDependent IGストリームを構成するパケットをデコードし、デコードして得られたデータをD IGプレーン生成部１２１に出力する。Base IGストリームとDependent IGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３２１】
D IGプレーン生成部１２１は、Dependent IGのプレーンをD IGデコーダ１２０から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３２２】
スイッチ１８２は、Base PGストリームを構成するパケットをB PGデコーダ１２４に出力し、Dependent PGストリームを構成するパケットをD PGデコーダ１２８に出力する。スイッチ１８２は、図２１のスイッチ１２２とスイッチ１２６の機能を有する。
【０３２３】
B PGデコーダ１２４は、スイッチ１８２から供給されたBase PGストリームを構成するパケットをデコードし、デコードして得られたデータをB PGプレーン生成部１２５に出力する。
【０３２４】
B PGプレーン生成部１２５は、Base PGのプレーンをB PGデコーダ１２４から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３２５】
D PGデコーダ１２８は、スイッチ１８２から供給されたDependent PGストリームを構成するパケットをデコードし、デコードして得られたデータをD PGプレーン生成部１２９に出力する。Base PGストリームとDependent PGストリームが１つのデコーダによりデコードされるようにしてもよい。
【０３２６】
D PGプレーン生成部１２９は、Dependent PGのプレーンをD PGデコーダ１２８から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３２７】
ビデオデコーダ１１０は、スイッチ１０９（図２２等）から供給されたパケットを順次デコードし、デコードして得られたBase view videoのデータ、または、Dependent view videoのデータをスイッチ１１１に出力する。
【０３２８】
スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをB videoプレーン生成部１１２に出力し、Dependent view videoのパケットをデコードして得られたデータをD videoプレーン生成部１１３に出力する。
【０３２９】
B videoプレーン生成部１１２は、Base view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３３０】
D videoプレーン生成部１１３は、Dependent view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、出力する。
【０３３１】
合成部１３０は、加算部１９１乃至１９４、およびスイッチ１９５から構成される。
【０３３２】
加算部１９１は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンを、D videoプレーン生成部１１３から供給されたDependent view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９３に出力する。D PGプレーン生成部１２９から加算部１９１に供給されるDependent PGのプレーンには、色情報の変換処理（CLUT(Color Look Up Table)処理）が施される。
【０３３３】
加算部１９２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンを、B videoプレーン生成部１１２から供給されたBase view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部１９４に出力する。B PGプレーン生成部１２５から加算部１９２に供給されるBase PGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３３４】
加算部１９３は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンを、加算部１９１による合成結果の上に重ねるようにして合成し、合成結果をDependent viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９３に供給されるDependent IGのプレーンには、色情報の変換処理が施される。
【０３３５】
加算部１９４は、B IGプレーン生成部１１７から供給されたBase IGのプレーンを、加算部１９２による合成結果の上に重ねるようにして合成し、合成結果をBase viewのプレーンとして出力する。D IGプレーン生成部１２１から加算部１９４に供給されるBase IGのプレーンには、色情報の変換処理やオフセット値を用いた補正処理が施される。
【０３３６】
このようにして生成されたBase viewのプレーンとDependent viewのプレーンに基づいて表示される画像は、ボタンやアイコンが前面に見え、その下（奥行き方向）に字幕のテキストが見え、その下にビデオが見えるような画像になる。
【０３３７】
スイッチ１９５は、view_typeの値が0である場合、Base viewのプレーンをL viewのプレーンとして出力し、Dependent viewのプレーンをR viewのプレーンとして出力する。スイッチ１９５にはコントローラ５１からview_typeが供給される。
【０３３８】
また、スイッチ１９５は、view_typeの値が1である場合、Base viewのプレーンをR viewのプレーンとして出力し、Dependent viewのプレーンをL viewのプレーンとして出力する。供給されたプレーンのうちのどのプレーンがBase viewのプレーンであるのかDependent viewのプレーンであるのかは、PIDやview_idに基づいて識別される。
【０３３９】
このように、再生装置１においては、Base viewのプレーン同士、Dependent viewのプレーン同士、video、IG、PGの各プレーンの合成が行われる。
【０３４０】
video、IG、PGの全てのプレーンの合成が終わった段階で、Base viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３４１】
また、video、IG、PGの全てのプレーンの合成が終わった段階で、Dependent viewのプレーン同士を合成した結果がL viewであるのか、またはR viewであるのかがview_typeに基づいて判断され、R viewのプレーンとL viewのプレーンがそれぞれ出力される。
【０３４２】
［第２の例］
図２８は、合成部１３０と、その前段の構成を示す図である。
【０３４３】
図２８に示す構成のうち、図２７に示す構成と同じ構成には同じ符号を付してある。図２８においては、合成部１３０の構成が図２７の構成と異なる。また、スイッチ１１１の動作が、図２７のスイッチ１１１の動作と異なる。B videoプレーン生成部１１２に替えてL videoプレーン生成部１６１が設けられ、D videoプレーン生成部１１３に替えてR videoプレーン生成部１６２が設けられている。重複する説明については省略する。
【０３４４】
スイッチ１１１と、合成部１３０のスイッチ２０１およびスイッチ２０２に対しては、同じview_typeの値がコントローラ５１から供給される。
【０３４５】
スイッチ１１１は、図２４のスイッチ１１１と同様に、Base view videoのパケットをデコードして得られたデータと、Dependent view videoのパケットをデコードして得られたデータの出力先をview_typeに基づいて切り替える。
【０３４６】
例えば、view_typeの値が0である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。
【０３４７】
一方、view_typeの値が1である場合、スイッチ１１１は、Base view videoのパケットをデコードして得られたデータをR videoプレーン生成部１６２に出力する。この場合、スイッチ１１１は、Dependent view videoのパケットをデコードして得られたデータをL videoプレーン生成部１６１に出力する。
【０３４８】
L videoプレーン生成部１６１は、L view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３４９】
R videoプレーン生成部１６２は、R view videoのプレーンをスイッチ１１１から供給されたデータに基づいて生成し、合成部１３０に出力する。
【０３５０】
合成部１３０は、スイッチ２０１、スイッチ２０２、加算部２０３乃至２０６から構成される。
【０３５１】
スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンとD IGプレーン生成部１２１から供給されたDependent IGのプレーンの出力先をview_typeに基づいて切り替える。
【０３５２】
例えば、view_typeの値が0である場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３５３】
一方、view_typeの値が1である場合、スイッチ２０１は、D IGプレーン生成部１２１から供給されたDependent IGのプレーンをL viewのプレーンとして加算部２０６に出力する。この場合、スイッチ２０１は、B IGプレーン生成部１１７から供給されたBase IGのプレーンをR viewのプレーンとして加算部２０５に出力する。
【０３５４】
スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンとD PGプレーン生成部１２９から供給されたDependent PGのプレーンの出力先をview_typeに基づいて切り替える。
【０３５５】
例えば、view_typeの値が0である場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３５６】
一方、view_typeの値が1である場合、スイッチ２０２は、D PGプレーン生成部１２９から供給されたDependent PGのプレーンをL viewのプレーンとして加算部２０４に出力する。この場合、スイッチ２０２は、B PGプレーン生成部１２５から供給されたBase PGのプレーンをR viewのプレーンとして加算部２０３に出力する。
【０３５７】
加算部２０３は、スイッチ２０２から供給されたR viewのPGのプレーンを、R videoプレーン生成部１６２から供給されたR view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０５に出力する。
【０３５８】
加算部２０４は、スイッチ２０２から供給されたL viewのPGのプレーンを、L videoプレーン生成部１６１から供給されたL view videoのプレーンの上に重ねるようにして合成し、合成結果を加算部２０６に出力する。
【０３５９】
加算部２０５は、スイッチ２０１から供給されたR viewのIGのプレーンを、加算部２０３による合成結果のプレーンの上に重ねるようにして合成し、合成結果をR viewのプレーンとして出力する。
【０３６０】
加算部２０６は、スイッチ２０１から供給されたL viewのIGのプレーンを、加算部２０４による合成結果のプレーンの上に重ねるようにして合成し、合成結果をL viewのプレーンとして出力する。
【０３６１】
このように、再生装置１においては、video、IG、PGのそれぞれのBase viewのプレーンとDependent viewのプレーンについて、他のプレーンとの合成の前に、いずれのプレーンがL viewであるのか、またはR viewであるのかが判断される。
【０３６２】
その判断が行われた後、L viewのプレーン同士、R viewのプレーン同士を合成するように、video、IG、PGの各プレーンの合成が行われる。
【０３６３】
［記録装置の構成例］
図２９は、ソフト製作処理部３０１の構成例を示すブロック図である。
【０３６４】
ビデオエンコーダ３１１は、図３のMVCエンコーダ１１と同様の構成を有している。ビデオエンコーダ３１１は、複数の映像データをH.264 AVC/MVCでエンコードすることによってBase view videoストリームとDependent view videoストリームを生成し、バッファ３１２に出力する。
【０３６５】
例えば、ビデオエンコーダ３１１は、エンコード時、同じPCRを基準としてDTS、PTSを設定する。すなわち、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、デコード順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じDTSを設定する。
【０３６６】
また、ビデオエンコーダ３１１は、あるBase view videoのピクチャのデータを格納するPESパケットと、表示順でそのピクチャと対応するDependent view videoのピクチャのデータを格納するPESパケットに同じPTSを設定する。
【０３６７】
ビデオエンコーダ３１１は、後述するように、デコード順で対応するBase view videoのピクチャとBase view videoのピクチャに、復号に関する補助的な情報である付加情報としてそれぞれ同じ情報を設定する。
【０３６８】
さらに、ビデオエンコーダ３１１は、後述するように、表示順で対応するBase view videoのピクチャとBase view videoのピクチャに、ピクチャの出力順を表すPOCの値としてそれぞれ同じ値を設定する。
【０３６９】
また、ビデオエンコーダ３１１は、後述するように、Base view videoストリームのGOP構造とDependent view videoストリームのGOP構造とを一致させるようにしてエンコードを行う。
【０３７０】
オーディオエンコーダ３１３は、入力されたオーディオストリームをエンコードし、得られたデータをバッファ３１４に出力する。オーディオエンコーダ３１３には、Base view video、Dependent view videoストリームとともにディスクに記録させるオーディオストリームが入力される。
【０３７１】
データエンコーダ３１５は、PlayListファイルなどの、ビデオ、オーディオ以外の上述した各種のデータをエンコードし、エンコードして得られたデータをバッファ３１６に出力する。
【０３７２】
データエンコーダ３１５は、ビデオエンコーダ３１１によるエンコードに応じて、Base view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表すview_typeをPlayListファイルに設定する。Base view videoストリームの種類ではなく、Dependent view videoストリームがL viewのストリームであるのか、R viewのストリームであるのかを表す情報が設定されるようにしてもよい。
【０３７３】
また、データエンコーダ３１５は、後述するEP_mapを、Base view videoストリームのClip Informationファイルと、Dependent view videoストリームのClip Informationファイルにそれぞれ設定する。デコード開始位置としてEP_mapに設定されたBase view videoストリームのピクチャと、Dependent view videoストリームのピクチャは対応するピクチャになる。
【０３７４】
多重化部３１７は、それぞれのバッファに記憶されたビデオデータ、オーディオデータ、および、ストリーム以外のデータを同期信号と共に多重化し、誤り訂正符号化部３１８に出力する。
【０３７５】
誤り訂正符号化部３１８は、エラー訂正用のコードを多重化部３１７により多重化されたデータに付加する。
【０３７６】
変調部３１９は、誤り訂正符号化部３１８から供給されたデータに対して変調を施し、出力する。変調部３１９の出力は、再生装置１において再生可能な光ディスク２に記録されるソフトウェアとなる。
【０３７７】
このような構成を有するソフト製作処理部３０１が記録装置に設けられる。
【０３７８】
図３０は、ソフト製作処理部３０１を含む構成の例を示す図である。
【０３７９】
図３０に示す構成の一部が記録装置内に設けられることもある。
【０３８０】
ソフト製作処理部３０１により生成された記録信号はプリマスタリング処理部３３１においてマスタリング処理が施され、光ディスク２に記録すべきフォーマットの信号が生成される。生成された信号は原盤記録部３３３に供給される。
【０３８１】
記録用原盤製作部３３２においては、ガラスなどよりなる原盤が用意され、その上に、フォトレジストなどよりなる記録材料が塗布される。これにより、記録用原盤が製作される。
【０３８２】
原盤記録部３３３において、プリマスタリング処理部３３１から供給された記録信号に対応してレーザビームが変調され、原盤上のフォトレジストに照射される。これにより、原盤上のフォトレジストが記録信号に対応して露光される。その後、この原盤を現像し、原盤上にピットを出現させることが行われる。
【０３８３】
金属原盤製作部３３４において、原盤に電鋳等の処理が施され、ガラス原盤上のピットを転写した金属原盤が製作される。この金属原盤から、さらに金属スタンパが製作され、これが成形用金型とされる。
【０３８４】
成形処理部３３５において、成形用金型に、インジェクションなどによりPMMA（アクリル）またはPC（ポリカーボネート）などの材料を注入し、固定化させることが行われる。あるいは、金属スタンパ上に２Ｐ（紫外線硬化樹脂）などを塗布した後、紫外線を照射して硬化させることが行われる。これにより、金属スタンパ上のピットを、樹脂よりなるレプリカ上に転写することができる。
【０３８５】
成膜処理部３３６において、レプリカ上に、反射膜が蒸着あるいはスパッタリングなどにより形成される。あるいはまた、レプリカ上に、反射膜がスピンコートにより形成される。
【０３８６】
後加工処理部３３７において、このディスクに対して内外径の加工が施され、２枚のディスクを張り合わせるなどの必要な処置が施される。さらに、ラベルを貼り付けたり、ハブを取り付けたりした後、カートリッジに挿入される。このようにして再生装置１によって再生可能なデータが記録された光ディスク２が完成する。
【０３８７】
＜第２の実施の形態＞
［H.264 AVC/MVC Profileビデオストリームの運用１］
光ディスク２の規格であるBD-ROM規格においては、上述したように、H.264 AVC/MVC Profileを採用することで3D映像の符号化が実現される。
【０３８８】
また、BD-ROM規格においては、Base view videoストリームをL viewの映像のストリームとし、Dependent view videoストリームをR viewの映像のストリームとする。
【０３８９】
Base view videoをH.264 AVC/High Profileビデオストリームとして符号化することにより、過去のプレーヤや2D再生のみに対応したプレーヤにおいても、3D対応のディスクである光ディスク２を再生することが可能になる。すなわち、下位互換性を確保することが可能になる。
【０３９０】
具体的には、Base view videoのストリームのみをH.264 AVC/MVC非対応デコーダにおいてもデコード(再生)可能になる。つまり、Base view videoストリームは、既存の2DのBDプレーヤにおいても必ず再生可能なストリームになる。
【０３９１】
また、Base view videoストリームを、2D再生と3D再生において共通して使用することにより、オーサリング時の負荷の軽減を図ることが可能になる。オーサリング側は、AVストリームに関しては、従来行っていた作業に加えて、Dependent view videoストリームを用意すれば3D対応のディスクを製作することが可能になる。
【０３９２】
図３１は、記録装置に設けられる3D video TS生成部の構成例を示す図である。
【０３９３】
図３１の3D video TS生成部は、MVCエンコーダ４０１、MVCヘッダ除去部４０２、およびマルチプレクサ４０３から構成される。図２を参照して説明したようにして撮影されたL viewの映像＃１のデータと、R viewの映像＃２のデータがMVCエンコーダ４０１に入力される。
【０３９４】
MVCエンコーダ４０１は、図３のMVCエンコーダ１１と同様に、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオデータをBase view videoストリームとして出力する。また、MVCエンコーダ４０１は、L viewの映像＃１のデータとR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、出力する。
【０３９５】
MVCエンコーダ４０１から出力されたBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４０１から出力されたDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０３９６】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０３９７】
Dependent view videoのMVCヘッダに記述されるview_idの値としては、１以上の固定値が用いられる。図３２、図３３の例においても同様である。
【０３９８】
すなわち、MVCエンコーダ４０１は、図３のMVCエンコーダ１１とは異なり、MVCヘッダを付加した形でBase view videoとDependent view videoのそれぞれのストリームを生成し、出力するエンコーダである。図３のMVCエンコーダ１１においては、H.264 AVC/MVCで符号化されたDependent view videoのみにMVCヘッダが付加されている。
【０３９９】
MVCエンコーダ４０１から出力されたBase view videoストリームはMVCヘッダ除去部４０２に供給され、Dependent view videoストリームはマルチプレクサ４０３に供給される。
【０４００】
MVCヘッダ除去部４０２は、Base view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４０２は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４０３に出力する。
【０４０１】
マルチプレクサ４０３は、MVCヘッダ除去部４０２から供給されたBase view videoストリームと、MVCエンコーダ４０１から供給されたDependent view videoストリームを含むTSを生成し、出力する。図３１の例においては、Base view videoストリームを含むTSとDependent view videoストリームを含むTSがそれぞれ出力されているが、上述したように同じTSに多重化されて出力されることもある。
【０４０２】
このように、実装の仕方によっては、L viewの映像とR viewの映像を入力とし、MVCヘッダ付のBase view videoとDependent view videoのそれぞれのストリームを出力するMVCエンコーダも考えられる。
【０４０３】
なお、図３１に示す構成全体を図３に示すようにMVCエンコーダの中に含めることも可能である。図３２、図３３に示す構成についても同様である。
【０４０４】
図３２は、記録装置に設けられる3D video TS生成部の他の構成例を示す図である。
【０４０５】
図３２の3D video TS生成部は、混合処理部４１１、MVCエンコーダ４１２、分離部４１３、MVCヘッダ除去部４１４、およびマルチプレクサ４１５から構成される。L viewの映像＃１のデータと、R viewの映像＃２のデータが混合処理部４１１に入力される。
【０４０６】
混合処理部４１１は、L viewの各ピクチャとR viewの各ピクチャを符号化順に並べる。Dependent view videoの各ピクチャは対応するBase view videoのピクチャを参照して符号化が行われるから、符号化順に並べた結果は、L viewのピクチャとR viewのピクチャが交互に並ぶものになる。
【０４０７】
混合処理部４１１は、符号化順に並べたL viewのピクチャとR viewのピクチャをMVCエンコーダ４１２に出力する。
【０４０８】
MVCエンコーダ４１２は、混合処理部４１１から供給された各ピクチャをH.264 AVC/MVCで符号化し、符号化して得られたストリームを分離部４１３に出力する。MVCエンコーダ４１２から出力されたストリームには、Base view videoストリームとDependent view videoストリームが多重化されている。
【０４０９】
MVCエンコーダ４１２から出力されたストリームに含まれるBase view videoストリームは、Base view videoの各ピクチャのデータを格納したAccess Unitからなる。また、MVCエンコーダ４１２から出力されたストリームに含まれるDependent view videoストリームは、Dependent view videoの各ピクチャのデータを格納したAccess Unitからなる。
【０４１０】
Base view videoストリームを構成する各Access UnitとDependent view videoストリームを構成する各Access Unitには、格納しているview componentを識別するためのview_idを記述したMVCヘッダが含まれている。
【０４１１】
分離部４１３は、MVCエンコーダ４１２から供給されたストリームに多重化されているBase view videoストリームとDependent view videoストリームを分離し、出力する。分離部４１３から出力されたBase view videoストリームはMVCヘッダ除去部４１４に供給され、Dependent view videoストリームはマルチプレクサ４１５に供給される。
【０４１２】
MVCヘッダ除去部４１４は、分離部４１３から供給されたBase view videoストリームを構成する各Access Unitに含まれるMVCヘッダを除去する。MVCヘッダ除去部４１４は、MVCヘッダを除去したAccess Unitから構成されるBase view videoストリームをマルチプレクサ４１５に出力する。
【０４１３】
マルチプレクサ４１５は、MVCヘッダ除去部４１４から供給されたBase view videoストリームと、分離部４１３から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４１４】
図３３は、記録装置に設けられる3D video TS生成部のさらに他の構成例を示す図である。
【０４１５】
図３３の3D video TS生成部は、AVCエンコーダ４２１、MVCエンコーダ４２２、およびマルチプレクサ４２３から構成される。L viewの映像＃１のデータはAVCエンコーダ４２１に入力され、R viewの映像＃２のデータはMVCエンコーダ４２２に入力される。
【０４１６】
AVCエンコーダ４２１は、L viewの映像＃１のデータをH.264/AVCで符号化し、符号化して得られたAVCビデオストリームをBase view videoストリームとしてMVCエンコーダ４２２とマルチプレクサ４２３に出力する。AVCエンコーダ４２１から出力されたBase view videoストリームを構成する各Access UnitにはMVCヘッダが含まれていない。
【０４１７】
MVCエンコーダ４２２は、AVCエンコーダ４２１から供給されたBase view videoストリーム（AVCビデオストリーム）をデコードし、L viewの映像＃１のデータを生成する。
【０４１８】
また、MVCエンコーダ４２２は、デコードして得られたL viewの映像＃１のデータと、外部から入力されたR viewの映像＃２のデータに基づいてDependent view videoストリームを生成し、マルチプレクサ４２３に出力する。MVCエンコーダ４２２から出力されたDependent view videoストリームを構成する各Access UnitにはMVCヘッダが含まれている。
【０４１９】
マルチプレクサ４２３は、AVCエンコーダ４２１から供給されたBase view videoストリームと、MVCエンコーダ４２２から供給されたDependent view videoストリームを含むTSを生成し、出力する。
【０４２０】
図３３のAVCエンコーダ４２１が図３のH.264/AVCエンコーダ２１の機能を有し、MVCエンコーダ４２２が図３のH.264/AVCデコーダ２２とDependent view videoエンコーダ２４の機能を有することになる。また、マルチプレクサ４２３が図３のマルチプレクサ２５の機能を有することになる。
【０４２１】
このような構成を有する3D video TS生成部を記録装置内に設けることにより、Base view videoのデータを格納するAccess Unitに対するMVCヘッダの符号化を禁止することが可能になる。また、Dependent view videoのデータを格納するAccess Unitに、１以上のview_idが設定されたMVCヘッダが含まれるようにすることができる。
【０４２２】
図３４は、Access Unitをデコードする再生装置１側の構成を示す図である。
【０４２３】
図３４においては、図２２等を参照して説明したスイッチ１０９とビデオデコーダ１１０が示されている。Base view videoのデータを含むAccess Unit＃１と、Dependent view videoのデータを含むAccess Unit＃２がバッファから読み出され、スイッチ１０９に供給される。
【０４２４】
Base view videoを参照して符号化が行われているから、Dependent view videoを正しく復号するには、まず、対応するBase view videoを復号しておくことが必要になる。
【０４２５】
H.264/MVC規格においては、デコーダ側が、MVCヘッダに含まれるview_idを利用して各Access Unitの復号順序を算出するようになされている。また、Base view videoには、そのエンコード時に、常に最小の値をview_idの値として設定することが定められている。デコーダは、最小のview_idが設定されているMVCヘッダを含むAccess Unitから復号を開始することで、Base view videoとDependent view videoを正しい順序で復号することができるようになされている。
【０４２６】
ところで、再生装置１のビデオデコーダ１１０に供給される、Base view videoを格納したAccess UnitにはMVCヘッダの符号化が禁止されている。
【０４２７】
そこで、再生装置１においては、MVCヘッダがないAccess Unitに格納されているview componentについては、そのview_idが0であるとして認識するように定義されている。
【０４２８】
これにより、再生装置１は、0であるとして認識したview_idに基づいてBase view videoを識別することができ、実際に設定されている0以外のview_idに基づいてDependent view videoを識別することができる。
【０４２９】
図３４のスイッチ１０９は、最小の値である0がview_idとして設定されていると認識したAccess Unit＃１をまずビデオデコーダ１１０に出力し、デコードを行わせる。
【０４３０】
また、スイッチ１０９は、Access Unit＃１のデコードが終了した後、0より大きい固定値であるYがview_idとして設定されているAccess Unit＃２をビデオデコーダ１１０に出力し、デコードを行わせる。Access Unit＃２に格納されているDependent view videoのピクチャは、Access Unit＃１に格納されているBase view videoのピクチャに対応するピクチャである。
【０４３１】
このように、Base view videoを格納したAccess Unitに対するMVCヘッダの符号化を禁止することにより、光ディスク２に記録されているBase view videoストリームを、従来のプレーヤにおいても再生可能なストリームとすることができる。
【０４３２】
BD-ROM規格を拡張したBD-ROM 3D規格のBase view videoストリームの条件として、従来のプレーヤにおいても再生可能なストリームとするような条件が決められた場合であっても、その条件を満たすようにすることができる。
【０４３３】
例えば、図３５に示すように、Base view videoとDependent view videoにそれぞれMVCヘッダを付加しておき、Base view videoから先にデコードが行われるようにした場合、そのBase view videoは従来のプレーヤにおいては再生できないものになる。従来のプレーヤが搭載するH.264/AVCデコーダにとっては、MVCヘッダは未定義のデータである。そのような未定義のデータが入力された場合、デコーダによってはそれを無視することができず、処理が破綻するおそれがある。
【０４３４】
なお、図３５においては、Base view videoのview_idはX、Dependent view videoのview_idは、Xより大きいYである。
【０４３５】
また、MVCヘッダの符号化を禁止した場合であっても、Base view videoのview_idを0としてみなすように定義することにより、再生装置１にBase view videoのデコードを先に行わせ、その後に、対応するDependent view videoのデコードを行わせることができる。すなわち、正しい順序でデコードを行わせることが可能になる。
【０４３６】
［運用２］
GOP構造について
H.264/AVC規格には、MPEG-2ビデオ規格におけるGOP(Group Of Picture)構造が定義されていない。
【０４３７】
そこで、H.264/AVCビデオストリームを扱うBD-ROM規格においては、H.264/AVCビデオストリームのGOP構造を定義し、ランダムアクセスなどのGOP構造を利用した各種の機能を実現している。
【０４３８】
H.264 AVC/MVCで符号化して得られたビデオストリームであるBase view videoストリームとDependent view videoストリームにも、H.264/AVCビデオストリームと同様にGOP構造の定義が存在しない。
【０４３９】
Base view videoストリームはH.264/AVCビデオストリームである。従って、Base view videoストリームのGOP構造は、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造になる。
【０４４０】
Dependent view videoストリームのGOP構造についても、Base view videoストリームのGOP構造、すなわち、BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造と同じ構造として定義する。
【０４４１】
BD-ROM規格において定義されたH.264/AVCビデオストリームのGOP構造には次のような特徴がある。
【０４４２】
１．ストリーム構造についての特徴
（１）Open GOP/Closed GOP構造
図３６は、Closed GOP構造を示す図である。
【０４４３】
図３６の各ピクチャはH.264/AVCビデオストリームを構成するピクチャである。Closed GOPにはIDR(Instantaneous Decording Refresh)ピクチャが含まれる。
【０４４４】
IDRピクチャはＩピクチャであり、IDRピクチャを含むGOP内の中で最初にデコードされる。IDRピクチャのデコード時、参照ピクチャバッファ（図２２のDPB１５１）の状態や、それまで管理されていたフレーム番号やPOC(Picture Order Count)などのデコードに関する全ての情報はリセットされる。
【０４４５】
図３６に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。
【０４４６】
また、現在GOPのピクチャのうち、IDRピクチャより表示順で後（未来）のピクチャは、IDRピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。H.264/AVCにおいては、表示順でＩピクチャの後ろにあるＰピクチャから、そのＩピクチャより前のピクチャを参照することも許されている。
【０４４７】
図３７は、Open GOP構造を示す図である。
【０４４８】
図３７に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDR Ｉピクチャ（IDRピクチャではないＩピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４４９】
また、現在GOPのピクチャのうち、non-IDR Ｉピクチャより表示順で後のピクチャは、non-IDR Ｉピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４５０】
（２）GOPの先頭のAccess Unitには、SPS、PPSが必ず符号化される。
【０４５１】
SPS(Sequence Parameter Set)は、シーケンス全体の符号化に関する情報を含む、シーケンスのヘッダ情報である。あるシーケンスのデコード時、シーケンスの識別情報などが含まれるSPSが最初に必要になる。PPS(Picture Parameter Set)は、ピクチャ全体の符号化に関する情報を含む、ピクチャのヘッダ情報である。
【０４５２】
（３）GOPの先頭のAccess Unitには、最大30個までのPPSを符号化することができる。複数のPPSを先頭のAccess Unitに符号化した場合には、各PPSのid(pic_parameter_set_id)は一緒であってはならない。
【０４５３】
（４）GOPの先頭以外のAccess Unitには、最大1個までのPPSを符号化することができる。
【０４５４】
２．参照構造についての特徴
（１）I・P・Bピクチャは、それぞれI・P・Bスライスのみから構成されるピクチャであることが求められる。
【０４５５】
（２）表示順で参照ピクチャ（I or Pピクチャ）の直前のBピクチャは、符号化順では、必ず、その参照ピクチャの直後に符号化されていることが求められる。
【０４５６】
（３）参照ピクチャ（I or Pピクチャ）の符号化順と表示順は維持されること（同じであること）が求められる。
【０４５７】
（４）PピクチャからBピクチャを参照することは禁止される。
【０４５８】
（５）符号化順で、非参照Bピクチャ（B1）が非参照ピクチャ（B2）の前である場合、表示順もB1が前になることが求められる。
【０４５９】
非参照Bピクチャは、符号化順で後ろにある他のピクチャによって参照されないBピクチャである。
【０４６０】
（６）参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）を参照することができる。
【０４６１】
（７）非参照Bピクチャは、表示順で直前、又は直後の参照ピクチャ（I or Pピクチャ）、又は参照Bピクチャを参照することができる。
【０４６２】
（８）連続するBピクチャの数を最大3枚とすることが求められる。
【０４６３】
３．GOP内の最大フレーム・フィールド数についての特徴
GOP内の最大フレーム・フィールド数は、図３８に示すようにビデオのフレームレートに応じて規定されている。
【０４６４】
図３８に示すように、例えば、フレームレートが29.97フレーム／秒でインタレース表示を行う場合、1GOPのピクチャで表示させることが可能な最大フィールド数は60である。また、フレームレートが59.94フレーム／秒でプログレッシブ表示を行う場合、1GOPのピクチャで表示させることが可能な最大フレーム数は60である。
【０４６５】
以上のような特徴を有するGOP構造を、Dependent view videoストリームのGOP構造としても定義する。
【０４６６】
また、Base view videoストリームのあるGOPの構造と、対応するDependent view videoストリームのGOPの構造を一致させることを制約として規定する。
【０４６７】
以上のようにして定義したBase view videoストリーム、またはDependent view videoストリームのClosed GOP構造を図３９に示す。
【０４６８】
図３９に示すように、Closed GOPである現在GOPにおいては、その現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で前（過去）のピクチャは、直前のGOPのピクチャを参照することが禁止される。アンカーピクチャについては後述する。
【０４６９】
また、現在GOPのピクチャのうち、IDRピクチャ、またはアンカーピクチャより表示順で後（未来）のピクチャは、IDRピクチャ、またはアンカーピクチャを超えて、直前のGOPのピクチャを参照することが禁止される。
【０４７０】
図４０は、Base view videoストリーム、またはDependent view videoストリームのOpen GOP構造を示す図である。
【０４７１】
図４０に示すように、Open GOPである現在GOPにおいては、その現在GOPのピクチャのうち、non-IDRアンカーピクチャ（IDRピクチャではないアンカーピクチャ）より表示順で前のピクチャは、直前のGOPのピクチャを参照することが許される。
【０４７２】
また、現在GOPのピクチャのうち、non-IDRアンカーピクチャより表示順で後のピクチャは、non-IDRアンカーピクチャを超えて直前のGOPのピクチャを参照することが禁止される。
【０４７３】
以上のようにしてGOP構造を定義することにより、例えば、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、Open GOPであるのか、Closed GOPであるのかといったようなストリーム構造の特徴が一致することになる。
【０４７４】
また、Base view videoの非参照Bピクチャに対応するDependent view videoのピクチャは必ず非参照Bピクチャになるといったように、ピクチャの参照構造の特徴も一致することになる。
【０４７５】
さらに、Base view videoストリームのあるGOPと、対応するDependent view videoストリームのGOPの間では、フレーム数、フィールド数も一致することになる。
【０４７６】
このように、Dependent view videoストリームのGOP構造をBase view videoストリームのGOP構造と同じ構造として定義することにより、ストリーム間の対応するGOP同士に同じ特徴を持たせることが可能になる。
【０４７７】
また、ストリームの途中からデコードを行うような場合でも、問題なくそれを行うことが可能になる。ストリームの途中からのデコードは、例えば、トリックプレイやランダムアクセスのときに行われる。
【０４７８】
フレーム数が異なるといったように、ストリーム間の対応するGOP同士の構造が異なる場合、一方のストリームは正常に再生できるのに他方のストリームが再生できないといったことが生じるおそれがあるが、それを防ぐことができる。
【０４７９】
ストリーム間の対応するGOP同士の構造を異なるものとしてストリームの途中からデコードを開始した場合、Dependent view videoのデコードに必要となるBase view videoのピクチャがデコードされていないといったことが生じるおそれもある。この場合、結果として、Dependent view videoのピクチャをデコードすることができず、3D表示を行うことができなくなる。また、実装の方法によっては、Base view videoの画像も出力できない可能性があるが、それらの不都合も回避することができる。
【０４８０】
EP_mapについて
Base view videoストリームとDependent view videoストリームのGOP構造を利用することで、ランダムアクセスやトリックプレイ時のデコードの開始位置をEP_mapに設定することが可能になる。EP_mapはClip Informationファイルに含まれる。
【０４８１】
デコード開始位置としてEP_mapに設定可能なピクチャの制約として次の２つの制約を規定する。
【０４８２】
１．Dependent view videoストリームに設定可能な位置を、SubsetSPSに続けて配置されるアンカーピクチャの位置か、SubsetSPSに続けて配置されるIDRピクチャの位置とする。
【０４８３】
アンカーピクチャは、H.264 AVC/MVCで規定されるピクチャであり、時間方向に参照せずに、view間の参照を行って符号化されたDependent view videoストリームのピクチャである。
【０４８４】
２．Dependent view videoストリームのあるピクチャをデコード開始位置としてEP_mapに設定する場合、対応するBase view videoストリームのピクチャも、デコード開始位置としてEP_mapに設定する。
【０４８５】
図４１は、上記２つの制約を満たすEP_mapに設定されたデコード開始位置の例を示す図である。
【０４８６】
図４１においては、Base view videoストリームを構成するピクチャと、Dependent view videoストリームを構成するピクチャをデコード順に示している。
【０４８７】
Dependent view videoストリームのピクチャのうちの色を付けて示すピクチャＰ1は、アンカーピクチャ、またはIDRピクチャである。ピクチャＰ1のデータを含むAccess Unitの直前のAccess UnitにはSubsetSPSが含まれる。
【０４８８】
図４１の例においては、白抜き矢印＃１１で示すように、ピクチャＰ1が、Dependent view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４８９】
ピクチャＰ1に対応するBase view videoストリームのピクチャであるピクチャＰ11はIDRピクチャである。白抜き矢印＃１２で示すように、IDRピクチャであるピクチャＰ11も、Base view videoストリームのEP_mapにデコード開始位置として設定されている。
【０４９０】
ランダムアクセスやトリックプレイが指示されたことから、ピクチャＰ1とピクチャＰ11からデコードを開始する場合、最初に、ピクチャＰ11のデコードが行われる。IDRピクチャであるから、他のピクチャを参照することなく、ピクチャＰ11をデコードすることが可能である。
【０４９１】
ピクチャＰ11のデコードが終了したとき、次に、ピクチャＰ1がデコードされる。ピクチャＰ1のデコードにはデコード済みのピクチャＰ11が参照される。アンカーピクチャ、またはIDRピクチャであるから、ピクチャＰ11のデコードが終了していればピクチャＰ1のデコードは可能である。
【０４９２】
その後、Base view videoのピクチャＰ1の次のピクチャ、Dependent view videoのピクチャＰ11の次のピクチャ、・・・といったようにしてデコードが行われる。
【０４９３】
対応するGOPの構造が同じであり、かつ、対応する位置からデコードが開始されるから、Base view videoについてもDependent view videoについても、EP_mapに設定されたピクチャ以降のピクチャを問題なくデコードすることができる。これによりランダムアクセスを実現することが可能になる。
【０４９４】
図４１の垂直方向に示す点線より左側に並ぶピクチャはデコードされないピクチャになる。
【０４９５】
図４２は、Dependent view videoのGOP構造を定義しない場合に生じる問題について示す図である。
【０４９６】
図４２の例においては、色を付けて示すBase view videoのIDRピクチャであるピクチャＰ21がデコード開始位置としてEP_mapに設定されている。
【０４９７】
Base view videoのピクチャＰ21からデコードを開始する場合において、ピクチャＰ21に対応するDependent view videoのピクチャであるピクチャＰ31がアンカーピクチャではない場合を考える。GOP構造を定義していない場合、Base view videoのIDRピクチャに対応するDependent view videoのピクチャが、IDRピクチャまたはアンカーピクチャであるという保障はない。
【０４９８】
この場合、Base view videoのピクチャＰ21のデコードが終わったときであっても、ピクチャＰ31をデコードすることはできない。ピクチャＰ31のデコードには時間方向の参照も必要になるが、垂直方向に示す点線より左側（デコード順で前）のピクチャはデコードされていない。
【０４９９】
ピクチャＰ31をデコードすることができないことにより、ピクチャＰ31を参照するDependent view videoの他のピクチャもデコードすることができないことになる。
【０５００】
Dependent view videoストリームのGOP構造を定義しておくことにより、このようなことを回避することができる。
【０５０１】
Base view videoだけでなく、Dependent view videoについてもEP_mapでデコード開始位置を設定しておくことにより、再生装置１はデコードの開始位置を容易に特定することが可能になる。
【０５０２】
Base view videoのあるピクチャだけをデコード開始位置としてEP_mapに設定しておいた場合、再生装置１は、デコード開始位置のピクチャに対応するDependent view videoのピクチャを計算により特定する必要があり、処理が複雑になってしまう。
【０５０３】
たとえ対応するBase view videoとDependent view videoのピクチャ同士が同じDTS/PTSを持っていたとしても、ビデオのビットレートが異なる場合にはTSにおけるバイト配列まで一致させることができないため、この場合に処理が複雑になる。
【０５０４】
図４３は、Base view videoストリームとDependent view videoストリームからなるMVCストリームを対象にしたランダムアクセスやトリックプレイを行う際に必要になるピクチャサーチの概念を示す図である。
【０５０５】
図４３に示すように、ランダムアクセスやトリックプレイを行う際、non-IDRアンカーピクチャかIDRピクチャがサーチされ、デコード開始位置が決定される。
【０５０６】
ここで、EP_mapについて説明する。Base view videoのデコード開始位置をEP_mapに設定する場合について説明するが、Dependent view videoのデコード開始位置についても、同様にしてDependent view video のEP_mapに設定される。
【０５０７】
図４４は、光ディスク２上に記録されたAVストリームの構造を示す図である。
【０５０８】
Base view videoストリームを含むTSは、6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
【０５０９】
アライドユニットは、32個のソースパケット(Source Packet)からなる。ソースパケットは192バイトを有する。１つのソースパケットは、4バイトのトランスポートパケットエクストラヘッダ(TP_extra header)と、188バイトのトランスポートパケット(Transport Packet)とからなる。
【０５１０】
Base view videoのデータは、MPEG2 PESパケットにパケット化されている。PESパケットのデータ部にPESパケットヘッダが付加されてPESパケットが形成される。PESパケットヘッダには、PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDが含まれる。
【０５１１】
PESパケットは、さらにトランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードにトランスポートパケットヘッダが付加されてトランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPIDを含む。
【０５１２】
なお、ソースパケットには、Clip AVストリームの先頭を例えば０として、ソースパケット毎に１ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第１バイト目から始まる。
【０５１３】
EP_mapは、Clipのアクセスポイントのタイムスタンプが与えられたときに、Clip AVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイントのリストである。
【０５１４】
EP_mapは、AVストリームの中で、デコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の１つのEPデータは、PTSと、PTSに対応するAccess Unitの、AVストリーム中のアドレスとの対で構成される。AVC/H.264においては、１Access Unitには１ピクチャ分のデータが格納される。
【０５１５】
図４５は、Clip AVストリームの例を示す図である。
【０５１６】
図４５のClip AVストリームは、PID=xで識別されるソースパケットからなるビデオストリーム（Base view videoストリーム）である。ビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPIDにより区別される。
【０５１７】
図４５においては、ビデオストリームのソースパケットのうちの、IDRピクチャの先頭バイトを含むソースパケットに色が付されている。色が付いていない四角は、ランダムアクセスポイントとならないデータが含まれるソースパケットや、他のストリームのデータが含まれているソースパケットを示す。
【０５１８】
例えば、PID=ｘで区別されるビデオストリームのランダムアクセス可能なIDRピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、Clip AVストリームの時間軸上でPTS=pts(x1)の位置に配置される。
【０５１９】
同様に、次にランダムアクセス可能なIDRピクチャの先頭バイトを含むソースパケットはソースパケット番号X2のソースパケットとされ、PTS=pts(x2)の位置に配置される。
【０５２０】
図４６は、図４５のClip AVストリームに対応したEP_mapの例を概念的に示す図である。
【０５２１】
図４６に示すように、EP_mapは、stream_PID、PTS_EP_start、およびSPN_EP_startから構成される。
【０５２２】
stream_PIDは、ビデオストリームを伝送するトランスポートパケットのPIDを表す。
【０５２３】
PTS_EP_startは、ランダムアクセス可能なIDRピクチャから始まるAccess UnitのPTSを表す。
【０５２４】
SPN_EP_startは、PTS_EP_startの値により参照されるAccess Unitの第１バイト目を含むソースパケットのアドレスを表す。
【０５２５】
ビデオストリームのPIDがstream_PIDに格納され、PTS_EP_startとSPN_EP_startの対応関係を表すテーブル情報であるEP_map_for_one_stream_PID()が生成される。
【０５２６】
例えば、PID=xのビデオストリームのEP_map_for_one_stream_PID[0]には、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応して記述される。
【０５２７】
このようなテーブルが、同じClip AVストリームに多重化されたそれぞれのビデオストリームについても生成される。生成されたテーブルを含むEP_mapが、当該Clip AVストリームに対応するClip Informationファイルに格納される。
【０５２８】
図４７は、SPN_EP_startが指すソースパケットのデータ構造の例を示す図である。
【０５２９】
上述したように、ソースパケットは、188バイトのトランスポートパケットに4バイトのヘッダを付加した形で構成される。トランスポートパケット部分は、ヘッダ部(TP header)とペイロード部とからなる。SPN_EP_startは、IDRピクチャから始まるAccess Unitの第１バイト目を含むソースパケットのソースパケット番号を表す。
【０５３０】
AVC/H.264においては、Access Unitすなわちピクチャは、AUデリミタ(Access Unit Delimiter)から開始される。AUデリミタの後に、SRSとPPSが続く。その後に、IDRピクチャのスライスのデータの、先頭部分または全体が格納される。
【０５３１】
トランスポートパケットのTPヘッダにあるpayload_unit_start_indicatorの値が１であることは、新たなPESパケットがこのトランスポートパケットのペイロードから始まることを表す。このソースパケットから、Access Unitが開始されることになる。
【０５３２】
このようなEP_mapが、Base view videoストリームとDependent view videoストリームについてそれぞれ用意される。
【０５３３】
［運用３］
Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPOC(Picture Order Count)が符号化時に設定されている。POCは、ピクチャの表示順を表す値である。
【０５３４】
AVC/H.264においては、POCは「A variable having a value that is non-decreasing with increasing picture position in output order relative to the previous IDR picture in decoding order or relative to the previous picture containing the memory management control operation that marks all reference pictures as “unused for reference”.」として規定されている。
【０５３５】
符号化時、Base view videoストリームのピクチャに設定するPOCと、Dependent view videoストリームのピクチャに設定するPOCは統一して運用される。
【０５３６】
例えば、Base view videoストリームの表示順で１番目のピクチャにはPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５３７】
また、Dependent view videoストリームの表示順で１番目のピクチャには、Base view videoストリームの１番目のピクチャに設定されるものと同じPOC=1が設定され、それ以降、１ずつ値を増やして、POCが各ピクチャに設定される。
【０５３８】
上述したようにBase view videoストリームのGOP構造とDependent view videoストリームのGOP構造は同じであるから、Base view videoストリームとDependent view videoストリームの各ピクチャには、表示順で対応するピクチャ同士、同じPOCが設定される。
【０５３９】
これにより、再生装置１は、同じPOCが設定されているview componentを、表示順で対応するview componentとして処理することが可能になる。
【０５４０】
例えば、再生装置１は、Base view videoストリームのピクチャのうちのPOC=1が設定されているピクチャと、Dependent view videoストリームのピクチャのうちのPOC=1が設定されているピクチャを、対応するピクチャとして処理することができる。
【０５４１】
また、Base view videoストリームとDependent view videoストリームを構成する各ピクチャにはPicture Timing SEI(Supplemental Enhancement Information)が設定されている。SEIは、H.264/AVCで規定される、デコードに関する補助的な情報を含む付加情報である。
【０５４２】
SEIのうちの１つであるPicture Timing SEIには、符号化時のCPB(Coded Picture Buffer)からの読み出し時刻、デコード時のDPB（図２２のDPB１５１）からの読み出し時刻などの時刻情報が含まれる。また、表示時刻の情報、ピクチャ構造の情報などが含まれる。
【０５４３】
符号化時、Base view videoストリームのピクチャに設定するPicture Timing SEIと、Dependent view videoストリームのピクチャに設定するPicture Timing SEIは統一して運用される。
【０５４４】
例えば、Base view videoストリームの符号化順で１番目のピクチャにCPBからの読み出し時刻としてT1が設定された場合、Dependent view videoストリームの符号化順で１番目のピクチャにも、CPBからの読み出し時刻としてT1が設定される。
【０５４５】
すなわち、Base view videoストリームとDependent view videoストリームの各ピクチャには、符号化順、または復号順で対応するピクチャ同士、同じ内容のPicture Timing SEIが設定される。
【０５４６】
これにより、再生装置１は、同じPicture Timing SEIが設定されているview componentを、復号順で対応するview componentとして処理することが可能になる。
【０５４７】
POC、Picture Timing SEIは、Base view videoとDependent view videoのエレメンタリストリームに含まれるものであり、再生装置１においてはビデオデコーダ１１０により参照される。
【０５４８】
ビデオデコーダ１１０は、エレメンタリストリームに含まれる情報に基づいて、対応するview componentを識別することが可能になる。また、ビデオデコーダ１１０は、Picture Timing SEIに基づいて正しい復号順で、また、POCに基づいて正しい表示順になるようにデコード処理を行うことが可能になる。
【０５４９】
対応するview componentを識別するためにPlayListなどを参照する必要がないため、System Layerや、それ以上のLayerに問題が起きた場合の対処が可能になる。また、問題が起きたLayerに依存しないデコーダ実装も可能になる。
【０５５０】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【０５５１】
図４８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
【０５５２】
CPU(Central Processing Unit)５０１、ROM(Read Only Memory)５０２、RAM(Random Access Memory)５０３は、バス５０４により相互に接続されている。
【０５５３】
バス５０４には、さらに、入出力インタフェース５０５が接続されている。入出力インタフェース５０５には、キーボード、マウスなどよりなる入力部５０６、ディスプレイ、スピーカなどよりなる出力部５０７が接続される。また、バス５０４には、ハードディスクや不揮発性のメモリなどよりなる記憶部５０８、ネットワークインタフェースなどよりなる通信部５０９、リムーバブルメディア５１１を駆動するドライブ５１０が接続される。
【０５５４】
以上のように構成されるコンピュータでは、CPU５０１が、例えば、記憶部５０８に記憶されているプログラムを入出力インタフェース５０５及びバス５０４を介してRAM５０３にロードして実行することにより、上述した一連の処理が行われる。
【０５５５】
CPU５０１が実行するプログラムは、例えばリムーバブルメディア５１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部５０８にインストールされる。
【０５５６】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０５５７】
本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０５５８】
１  再生装置，  ２  光ディスク，  ３  表示装置，  １１  MVCエンコーダ，  ２１  H.264/AVCエンコーダ，  ２２  H.264/AVCデコーダ，  ２３  Depth算出部，  ２４  Dependent view videoエンコーダ，  ２５  マルチプレクサ，  ５１  コントローラ，  ５２  ディスクドライブ，  ５３  メモリ，  ５４  ローカルストレージ，  ５５  インターネットインタフェース，  ５６  デコーダ部，  ５７  操作入力部
【図１】
2010245970.tif 000003
【図２】
2010245970.tif 000004
【図３】
2010245970.tif 000005
【図４】
2010245970.tif 000006
【図５】
2010245970.tif 000007
【図６】
2010245970.tif 000008
【図７】
2010245970.tif 000009
【図８】
2010245970.tif 000010
【図９】
2010245970.tif 000011
【図１０】
2010245970.tif 000012
【図１１】
2010245970.tif 000013
【図１２】
2010245970.tif 000014
【図１３】
2010245970.tif 000015
【図１４】
2010245970.tif 000016
【図１５】
2010245970.tif 000017
【図１６】
2010245970.tif 000018
【図１７】
2010245970.tif 000019
【図１８】
2010245970.tif 000020
【図１９】
2010245970.tif 000021
【図２０】
2010245970.tif 000022
【図２１】
2010245970.tif 000023
【図２２】
2010245970.tif 000024
【図２３】
2010245970.tif 000025
【図２４】
2010245970.tif 000026
【図２５】
2010245970.tif 000027
【図２６】
2010245970.tif 000028
【図２７】
2010245970.tif 000029
【図２８】
2010245970.tif 000030
【図２９】
2010245970.tif 000031
【図３０】
2010245970.tif 000032
【図３１】
2010245970.tif 000033
【図３２】
2010245970.tif 000034
【図３３】
2010245970.tif 000035
【図３４】
2010245970.tif 000036
【図３５】
2010245970.tif 000037
【図３６】
2010245970.tif 000038
【図３７】
2010245970.tif 000039
【図３８】
2010245970.tif 000040
【図３９】
2010245970.tif 000041
【図４０】
2010245970.tif 000042
【図４１】
2010245970.tif 000043
【図４２】
2010245970.tif 000044
【図４３】
2010245970.tif 000045
【図４４】
2010245970.tif 000046
【図４５】
2010245970.tif 000047
【図４６】
2010245970.tif 000048
【図４７】
2010245970.tif 000049
【図４８】
2010245970.tif 000050