(57)【要約】      （修正有）【課題】オーサリングの手間を増大させることなく、品位が高い立体視映像を再生することができる受信装置を提供する。【解決手段】受信装置が受信するデータには、グラフィクスが表示されている間、ピクチャデータを平面視映像として表示することを指示するピクチ平面視指示情報が存在する。受信装置における出力部は、グラフィクスが表示されている間、上平面視指示の情報に従い、メインビューを構成するピクチャデータを平面視映像として出力する。【選択図】図８９
2012157069.tif 000002
【特許請求の範囲】
【請求項１】
放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
前記データは、メインビュービデオストリームと、サブビュービデオストリームを含み、
前記メインビュービデオストリームは、立体視映像のメインビューを構成するピクチャデータを含み、
前記サブビュービデオストリームは、立体視映像のサブビューを構成するピクチャデータを含み、
前記データは、グラフィクスが表示されている間、前記ピクチャデータを平面視映像として表示することを示す情報をさらに含み
前記受信装置は、
前記メインビュービデオストリーム及び前記サブビュービデオストリームをデコードすることにより、メインビューを構成するピクチャデータ及びサブビューを構成するピクチャデータを得るビデオデコーダと、
前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータを立体視映像として出力する出力部と、
を備え、
前記情報を受信した場合、前記出力部は、グラフィクスが表示されている間、前記メインビューを構成するピクチャデータを平面視映像として出力する
ことを特徴とする受信装置。
【請求項２】
前記情報を受信した場合、前記出力部は、グラフィクスが表示されている間、前記メインビューを構成するピクチャデータのうち同じピクチャデータを２回以上繰り返し出力する
ことを特徴とする請求項１記載の受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、3D映像及び2D映像の再生技術の技術分野に属する発明である
【背景技術】
【０００２】
2D映像とは、表示装置の表示画面をX-Y平面として捉えて、このX-Y平面上の画素にて表現される画像であり、平面視画像とも呼ばれる。
対照的に3D映像とは、表示装置の画面におけるX-Y平面上の画素に、Z軸方向の奥行きを加えた画像である。3D映像は、左目で視聴すべきレフトビュー映像と、右目で視聴すべきライトビュー映像とを共に再生して、これらレフトビュー映像、ライトビュー映像で立体視効果を発揮することにより、ユーザによる視聴に供される。3D映像における画素のうち、正のZ軸座標をもつものをユーザは、表示装置の画面より手前にあると感じ、負のZ軸座標をもつものを、画面より奥に存在すると感じる。
【０００３】
光ディスクに3D映像を格納する場合には、2D映像が格納された光ディスクのみを再生できる再生装置（以下、「2D再生装置」と呼ぶ）との再生互換性が求められる。3D映像を格納した光ディスクを、2D再生装置が3D映像を2D映像として再生できない場合、同じコンテンツを3D用ディスクと、2D用ディスクとの２種類を製作する必要があり、コスト高になってしまう。よって、3D映像が格納された光ディスクは、2D再生装置では2D映像として再生し、2D映像と3D映像を再生できる再生装置（以下、「2D/3D再生装置」）では、2D映像もしくは3D映像として再生できることが求められる。
【０００４】
3D映像が格納された光ディスクでの再生互換性を確保する技術の先行技術としては、以下の特許文献１に記載されたものがある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第３９３５５０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
立体視のためのレフトビュー、ライトビューの映像は、3Dカメラで撮影することにより得たものである。この3Dカメラは、2つのレンズが、人間の両眼視差に応じた間隔だけ隔てられて存在する。かかるレンズを介して撮影されたレフトビュー映像及びライトビュー映像は、交互再生されることにより人間の両眼視差を作り出すことができる。
【０００７】
しかし字幕やメニューは、3Dカメラによる撮影行為で作成されるのではなく、撮影が終了した後のオーサリングの行程で作成されるものであり、これらは立体視映像を見ながら後付けで作される。この際、立体視再生時において、字幕やメニューがどのように見えるかを考えながら、レフトビュー、ライトビューそれぞれについて、字幕やメニューを作成することはオーサリングスタッフにとって多大な労力であり、字幕／メニュー付きの立体視コンテンツの制作にあたっては、その作成作業を効率化することが要望されている。また、動画像がどれだけ手前に見えるかは、各フレーム期間毎に、時々刻々と変化するので、字幕やメニューの奥行きを固定化すると、字幕やメニューが、映像中の人物像とが位置的に重なることが多いに有り得る。酷い時にはメニューの矩形枠等が人物に突刺さって見え、ユーザの失笑を買うことも考えられるで、このようなおかしな立体視映像が再生されることを避けるには、やはりオーサリングの手間を惜しむことはできない。
【０００８】
本発明の目的は、オーサリングの手間を増大させることなく、品位が高い立体視映像を再生することができる受信装置を提供することである。
【課題を解決するための手段】
【０００９】
上記課題を解決することができる受信装置は、放送またはネットワークを経由して送信されたデータを受信する受信装置であって、
前記データは、メインビュービデオストリームと、サブビュービデオストリームを含み、
前記メインビュービデオストリームは、立体視映像のメインビューを構成するピクチャデータを含み、
前記サブビュービデオストリームは、立体視映像のサブビューを構成するピクチャデータを含み、
前記データは、グラフィクスが表示されている間、前記ピクチャデータを平面視映像として表示することを示す情報をさらに含み
前記受信装置は、
前記メインビュービデオストリーム及び前記サブビュービデオストリームをデコードすることにより、メインビューを構成するピクチャデータ及びサブビューを構成するピクチャデータを得るビデオデコーダと、
前記メインビューを構成するピクチャデータ及び前記サブビューを構成するピクチャデータを立体視映像として出力する出力部と、
を備え、
前記情報を受信した場合、前記出力部は、グラフィクスが表示されている間、前記メインビューを構成するピクチャデータを平面視映像として出力する
ことを特徴とする。
【発明の効果】
【００１０】
グラフィクスストリームにおける情報は、グラフィクスが表示されている間、前記メインビューを構成するピクチャデータを平面視映像として出力する旨を規定するので、メインビデオストリーム、サブビデオストリームをデコードすることで得られた平面視ピクチャを背景とし、立体視グラフィクスを前景とした合成画面が表示されることになる。受信装置におけるプレーンメモリのためのメモリ規模が、ワンプレーンであっても、立体視再生を実現することができるので、オーサリングの効率化と、再生装置の低コスト化の両立を実現することができる。
【図面の簡単な説明】
【００１１】
【図１】記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。
【図２】ユーザーの顔を左側に描き、右側に対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。
【図３】立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。
【図４】1plane＋Offsetモードにおいて、プレーンメモリのレイヤモデルに対してどのようなオフセット制御がなされるかを示す。
【図５】図４におけるオフセット制御によって、どのような立体視映像が再生されるかを示す。
【図６】1plane＋Offsetモードにおける立体視の実現の仕方を示す。
【図７】1plane＋Offsetモードのための制御情報を具備したディペンデントビューストリームの内部構成を示す。
【図８】ユーザデータコンテナの内部構成を示す図である。
【図９】オフセットメタデータを記述するためのシンタックスを示す。
【図１０】正と負のプレーンオフセットの見え方の違いの一例を示す図である。
【図１１】横軸を時間軸とし、縦軸を、Plane＿offset＿value[j]としたグラフである。
【図１２】横軸を時間軸とし、縦軸をPlane＿offset＿value[j]としたグラフである。
【図１３】offset＿sequence＿id＝１、２、３、４のオフセットシーケンスによって、どのような奥行きが定義されるかの一例を示す。
【図１４】第１実施形態に係る記録媒体における内部構成を示す。
【図１５】PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示す。
【図１６】メインTSがどのように多重化されるかを模式的に示す図である。
【図１７】メインTS及びサブTSの内部構成を示す。
【図１８】プレイリスト情報の内部構成を示す。
【図１９】基本ストリーム選択テーブルの一例を示す。
【図２０】拡張ストリーム選択テーブルの内部構成を示す。
【図２１】拡張ストリーム選択テーブルにおけるストリーム登録列を示す。
【図２２】基本ストリーム選択テーブル、拡張ストリーム選択テーブルによりメインTS、サブTSからどのようなESが多重分離されるかを示す。
【図２３】図２２のような多重分離がなされる場合、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。
【図２４】モードにおけるストリーム番号の割り当て変化を示す。
【図２５】オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。
【図２６】再生装置の内部構成を示す。
【図２７】結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
【図２８】結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
【図２９】再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。
【図３０】再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。
【図３１】再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す。
【図３２】再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す。
【図３３】プレイリスト再生手順を示す。
【図３４】ストリーム選択プロシージャの処理手順を示す。
【図３５】ストリーム番号に対応するパケット識別子の出力処理の手順を示す。
【図３６】PGプレーンシフトの処理手順を示すフローチャートである。
【図３７】テキスト字幕ストリームが再生対象である場合のPGプレーンシフトの処理手順を示すフローチャートである。
【図３８】IGプレーンのプレーンシフトを示すフローチャートである。
【図３９】STN＿table＿SSのFixed＿offset＿during＿Popupがオンである場合のIGプレーンのプレーンシフトの処理手順を示すフローチャートである。
【図４０】エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。
【図４１】立体視インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。
【図４２】立体視インターリーブドストリームファイル、ファイル2D、ファイルベースの相互関係を示す。
【図４３】2Dプレイリスト、3Dプレイリストを示す。
【図４４】図４３の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。
【図４５】ベースビューインディケータを示す。
【図４６】プレイリスト情報によるストリームファイルの読み込み手順を示す。
【図４７】クリップ情報ファイルの内部構成を示す図である。
【図４８】エクステントスタートポイント情報のシンタックスを示す。
【図４９】クリップ情報ファイルにおけるエントリーマップテーブルを示す。
【図５０】プログラム情報におけるストリーム属性情報を示す。
【図５１】エントリーマップによるエントリーポイントの登録を示す。
【図５２】立体視インターリーブドストリームファイル構成するデータブロックからATCシーケンスがどのように復元されるかを示す。
【図５３】ATCシーケンスの復元を示す図である。
【図５４】ATCシーケンス復元手順を示す。
【図５５】多重分離部及びビデオデコーダの内部構成を示す。
【図５６】PGストリームのグラフィクスデコーダの内部構成を示す。
【図５７】テキスト字幕デコーダの内部構成を示す。
【図５８】IGデコーダのデコーダモデルを示す。
【図５９】デコーダモデルの出力を合成し、3D-LR方式で出力するための回路構成を示す。
【図６０】デコーダモデルの出力を合成し、1plane＋Offsetモード方式で出力するための回路構成を示している。
【図６１】多層化された光ディスクの内部構成を示す。
【図６２】ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。
【図６３】記録媒体の記録方法を示す。
【図６４】オーサリング行程の処理手順を示すフローチャートである。
【図６５】AVファイル書込工程の処理手順を示す。
【図６６】記録装置の内部構成を示す。
【図６７】2D/3D再生装置の構成を示している。
【図６８】システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す。
【図６９】レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図である。
【図７０】出力モードの選択モデルの状態遷移を示す。
【図７１】Initializationの処理手順を示す。
【図７２】Procedure when playback condition is changedの処理手順を示す。
【図７３】3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。
【図７４】マクロブロックの奥行きと、シフト制御のためのパラメータとの関係を示す。
【図７５】ビデオストリームのエンコードとパラレルに実行される、オフセットシーケンスの定義手順を示すフローチャートである。
【図７６】字幕ストリームにおけるウィンドゥ定義セグメント、制御情報を示す図である。
【図７７】DSにおけるPCSの記述例を示す図である。
【図７８】composition＿object内の3d＿graphics＿offsetを用いた補間を施す場合と、補間を施さない場合とで、オフセットが時間的にどのように変化するかを示す。
【図７９】画面の分割領域毎のオフセットから構成されるオフセットシーケンスを示す。
【図８０】画面内の物体の奥行きと、オフセットとの関係を示す。
【図８１】再生装置のうち、ビデオデコーダ、ベースビュービデオプレーン、ディペンデントビュービデオプレーンメモリ、PG/IGプレーンを示す。
【図８２】グラフィクスプレーンの内容と、オフセットとの関連性を示す。
【図８３】デプスビュー方式の一例を示す。
【図８４】3D-Depthモードで生成される立体視画像を示す。
【図８５】3D-Depthモードを実現するための記録媒体の構成例を示す。
【図８６】ディレクトリ名とファイル拡張子により、2Dと3Dの場合に再生するストリームファイルを区別する仕組み、また、LR形式とDepth形式で再生するストリームファイルを区別する仕組みを示す。
【図８７】エレメンタリバッファのサイズ情報を含むプレイアイテム情報を示す。
【図８８】奥行き情報が追加された3Dメタデータを示す。
【図８９】2D/3D再生装置を集積回路を用いて実現した構成例である。
【図９０】ストリーム処理部の代表的な構成を示す機能ブロック図である。
【図９１】切替部がDMACであった場合の切替部６５３周辺の概念図である。
【図９２】AV出力部の代表的な構成を示す機能ブロック図である。
【図９３】AV出力部もしくは再生装置のデータ出力部分を詳細に示した構成例である。
【図９４】画像重畳処理における、メモリと各プレーンとの関係を示した図である。
【図９５】画像重畳部における画像重畳処理の概念図である。
【図９６】画像重畳部における画像重畳処理の概念図である。
【図９７】画像重畳部における画像重畳処理の概念図である。
【図９８】画像重畳部における画像重畳処理の概念図である。
【図９９】集積回路における制御バス及びデータバスの配置を示した図である。
【図１００】集積回路における制御バス及びデータバスの配置を示した図である。
【図１０１】再生装置における動作手順を簡単に示したフローチャートである。
【図１０２】再生装置における動作手順を詳細に示したフローチャートである。
【図１０３】ベースビュービデオストリームのクリップ情報におけるエクステントスタートポイント情報の一例と、ディペンデントビューストリームのクリップ情報におけるエクステントスタートポイント情報の一例を示す。
【図１０４】ATCシーケンス１、２における任意のデータブロックのソースパケット番号を説明するための図である。
【発明を実施するための形態】
【００１２】
図面を参照しながら、上記課題解決手段を具備した記録媒体、及び、再生装置の実施形態について説明する。先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目とでは、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
【００１３】
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
【００１４】
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
【００１５】
まず、１つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
【００１６】
２つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の２つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
【００１７】
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
【００１８】
上記の何れの方式においても、立体視映像は、少なくとも2つの視点映像から構成される。視点映像とは、何等かの偏向性をもった映像のことであり、少なくとも2つの視点映像は、メインビュー映像と、サブビュー映像とから構成される。そしてメインビュー、サブビューがそれぞれ、ビデオストリームによって記録媒体から供給される場合、記録媒体には、メインビューを供給するビデオストリームであるメインビュービデオストリーム、サブビューを供給するビデオストリームであるサブビュービデオストリームが記録される。以降の説明で登場する記録媒体は、これらのメインビュービデオストリーム、サブビュービデオストリームを好適に記録するためのものである。
【００１９】
また本願明細書における再生装置は、上述したメインビュービデオストリーム、サブビュービデオストリームを再生するため、2D再生モード、3D再生モードという2つの再生モードを具備しており、これらの相互切り替えを可能とする2D/3D再生装置(プレーヤ)である。
【００２０】
図１は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。同図（ａ）に示すように、記録媒体の一例である記録媒体１００、再生装置２００は、テレビ３００、3D眼鏡４００、リモコン５００と共にホームシアターシステムを構成し、ユーザによる使用に供される。
【００２１】
記録媒体１００は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置２００は、表示装置３００と接続され、記録媒体１００を再生する。
表示装置３００はテレビであり、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置３００は、3D眼鏡４００をユーザが着用することで立体視を実現するものだが、表示装置３００がレンチキュラー方式のものなら、3D眼鏡４００は不要となる。レンチキュラー方式の表示装置３００は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾上のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
【００２２】
3D眼鏡４００は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。同図（ｂ）は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡４００は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図（ｃ）は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
【００２３】
リモコン５００は、AV再生のための操作項目を受け付けるための機器である。またリモコン５００は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン５００は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
【００２４】
図１のホームシアターシステムにおいて、3D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを“3D出力モード”という。2D再生モードでの画像表示を表示装置３００に行わせる再生装置の出力モードを“2D出力モード”という。
【００２５】
以上が、記録媒体及び再生装置の使用形態についての説明である。
（第１実施形態）
第１実施形態の特徴は、立体視再生を実現するためのメインビュービデオストリーム、サブビュービデオストリームの組みを記録媒体１００に記録して再生装置２００に供給するにあたって、サブビュービデオストリーム内のメタデータに、オフセット制御を規定する制御情報を組込む点である。
【００２６】
ここでのオフセット制御とは、グラフィクスプレーンにおける水平座標の右方向及び左方向にオフセットを与えて、メインビューを構成するピクチャデータが描画されるメインビュービデオプレーン及びサブビューを構成するピクチャデータが描画されるサブビュービデオプレーンと合成することをいう。
【００２７】
更に、上記シフト制御のための制御情報は、前記オフセット値を示す情報及び前記オフセット方向を規定する情報を、複数フレームにおける各フレームに対応付けて規定するパラメータシーケンスとして機能する。
【００２８】
以降の説明において、メインビュー及びサブビューは、視差画像方式を実現するものとする。視差画像方式(3D-LRモードという)は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図２は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
【００２９】
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
【００３０】
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。視点間の相関特性を利用したビデオ圧縮の方法としては、MultiviewVideo  Coding（MVC）と呼ばれるMPEG-４  AVC/H.２６４の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共同プロジェクトであるJointVideo  Team（JVT）は、２００８年7月にMultiview Video  Coding（MVC）と呼ばれるMPEG-４  AVC/H.２６４の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。
【００３１】
そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、後述するベースビューインディケータによって定まる。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、“ディペンデントビュービデオストリーム”という。
【００３２】
視点間の相関性に基いて圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームであって、単体で復号化が可能になるものを“ベースビュービデオストリーム”という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、プレイアイテム情報内のベースビューインディケータによって定まる。
【００３３】
現状における立体視映像の符号化は、このMVC方式によるものが最良であると考えられるので、以降の説明では、“メインビュービデオストリーム”が“ベースビュービデオストリーム”であり、“サブビュービデオストリーム”が“ディペンデントビュービデオストリーム”であるとして説明を行う。
【００３４】
MVCビデオストリームの基礎となるMPEG4-AVC形式のビデオストリームについて説明する。
MVCビデオストリームは、GOP構造を有しており、クローズドGOP、オープンGOPから構成される。クローズドGOPは、IDRピクチャと、このIDRピクチャに続くBピクチャと、Pピクチャとから構成される。オープンGOPは、Non-IDRIピクチャと、Non-IDR Iピクチャに続くBピクチャと、Pピクチャとから構成される。
【００３５】
Non-IDR Iピクチャ、Pピクチャ、Bピクチャは、他のピクチャとのフレーム相関性に基づき圧縮符号化されている。Bピクチャとは、Bidirectionallypredictive(B)形式のスライスデータからなるピクチャをいい、Pピクチャとは、Predictive(P)形式のスライスデータからなるピクチャをいう。Bピクチャには、refrenceB(Br)ピクチャと、nonrefrenceB(B)ピクチャとがある。
【００３６】
クローズドGOPは、IDRピクチャが先頭に配置される。表示順序においてIDRピクチャは先頭にならないが、IDRピクチャ以外の他のピクチャ(Bピクチャ，Pピクチャ)は、クローズドGOPより前のGOPに存在するピクチャと依存関係をもつことはできない。このようにクローズドGOPは、依存関係を完結させる役割をもつ。
次にGOPの内部構成について説明する。オープンGOP、クローズドGOPにおける個々のピクチャデータは、H.264符号化方式におけるビデオアクセスユニット構造を有している。
【００３７】
ビデオアクセスユニットと、ピクチャとの関係は、１ビデオアクセスユニット ＝ １ピクチャである。またBD-ROMでは、１PESパケット ＝ １フレームに制限されている。つまり、動画がフレーム構造であれば、１PESパケット＝ １ピクチャであり、フィールド構造である場合、１PESパケット＝２ピクチャとなる。これらのことから、PESパケットは、ピクチャを、１対１の比率で格納している。
【００３８】
図３は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。
本図の第２段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。これらのピクチャデータは、DecodeTime Stamp(DTS)に従いデコードされる。第１段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。
【００３９】
第４段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第３段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。
【００４０】
第５段目は、3D眼鏡４００の状態をどのように変化させるかを示す。この第５段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
【００４１】
本図において、例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを１／４８秒の表示周期において、“Ｂ”ー“Ｄ”ー“Ｂ”ー“Ｄ”というように交互で出力するモードを、“B−Dプレゼンテーションモード”という。
【００４２】
ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを交互に出力するのではなく、再生モードを3Dモードに維持したまま、同じビデオフレームを2回以上繰り返し出力するという処理を行う再生タイプを、B−Bプレゼンテーションモードという。B−Bプレゼンテーションモードでは、単独再生可能なベースビュービデオストリームのビデオフレームのみが“Ｂ”−“Ｂ”−“Ｂ”−“Ｂ”というように繰り返し出力される。
【００４３】
以上のB−Dプレゼンテーションモード、B−Bプレゼンテーションモードが、再生装置の再生モードの基本となるが、これらのモード以外にも、再生装置には、1plane＋Offsetモードという再生モードが存在する。
【００４４】
1plane＋Offsetモード(3D-Offsetモードともいう)は、プレーンメモリの後段にシフト部を組込んで、シフト部を機能させることで立体視を実現する再生モードである。プレーンオフセット部は、レフトビュー期間及びライトビュー期間のそれぞれにおいて、プレーンメモリにおけるライン単位の画素の座標を、左方向又は右方向にシフトさせ、右目視線及び左目視線の結像点を手前方向、又は、奥行方向に変位させることで奥行き感を変化させる。具体的には、レフトビュー期間で左方向、ライトビュー期間で右方向に、画素座標を変化させれば、両目の視線の結像点は手前になり、レフトビュー期間で右方向、ライトビュー期間で左方向に、画素座標を変化させれば、両目の視線の結像点は手前になる。
【００４５】
かかるプレーンシフトでは、立体視のためのプレーンメモリが1プレーンで足りるので、簡易に立体視映像を作り出すのに最適である。このプレーンシフトでは、平面的な映像が手前に来たり、奥に引込んだりするという立体視映像を産み出すに過ぎないから、メニューや字幕の立体視効果には適しているものの、キャラクターや物体の立体視効果の実現にはやや物足りない。キャラクターの顔のくぼみや凹凸等が再現できないからである。
【００４６】
1plane＋Offsetモードをサポートする場合、再生装置の構成は以下の通りになる。グラフィクスの再生のため、再生装置にはプレーンメモリと、CLUT部、合成部が存在しており、このCLUT部、合成部の間にプレーンシフト部が組み入れられる。そして、シフト部は、ディペンデントビュービデオストリームのアクセスユニット構造に組込まれたオフセットシーケンスにおけるオフセットを用いて、上述したような画素の座標変化を実現する。こうすることで、1plane＋Offsetモードにおける画素の飛び出度合は、MVCビデオストリームと緻密に同期したものになる。この1plane＋Offsetモードの中には、1plane＋ZeroOffsetモードがある。1plane＋Zero Offsetモードは、ポップアップメニューがオンである場合、オフセット値をゼロにして、ポップアップメニューだけに立体視効果を与える表示モードである。
【００４７】
オフセットシーケンスによるシフト制御の対象となるプレーンメモリは、所定のレイヤモデルを構成する複数のプレーンメモリである。プレーンメモリとは、ESをデコードすることで得られた一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオデコーダ、PGデコーダ、IGデコーダのデコードによって得られた1画面分の画素データを格納する。
【００４８】
所定のレイヤモデルは、ベースビュービデオプレーン及びディペンデントビュービデオプレーンの階層、PGプレーンの階層、IG/BD-Jプレーンの階層から構成され、各階層のプレーンメモリの格納内容を、ベースビュービデオプレーン→PGプレーン→IG/BD-Jプレーンの順にレイヤ合成することを意図したものである。
【００４９】
上記レイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。以下、各階層のプレーンメモリについて述べる。
【００５０】
ベースビュービデオプレーンは、ベースビュービデオストリームを構成するビューコンポーネントをデコードすることで得られる一画面分の画素データを格納することができるプレーンメモリである。ディペンデントビュービデオプレーンは、ディペンデントビュービデオストリームを構成するビューコンポーネントをデコードすることで得られる一画面分の画素データを格納することができるプレーンメモリである。
【００５１】
プレゼンテーショングラフィクス(PG)プレーンとは、パイプライン式で動作するグラフィクスデコーダが、デコード処理を行うことで得られたグラフィクスの格納に用いられるプレーンメモリである。IG/BD-Jプレーンとは、ある動作モードでは、IGプレーンとして機能し、別の動作モードでは、BD-Jプレーンとして機能するプレーンメモリである。インタラクティブグラフィクス(IG)プレーンとは、対話的な処理を前提にして動作するグラフィクスデコーダが、デコードを行うことで得られたグラフィクスの格納に用いられるプレーンメモリである。BD-Jプレーンは、オブジェクト指向プログラミング言語のアプリケーションが描画処理を行うことで得た描画イメージグラフィクスの格納に用いることができるプレーンメモリである。IGプレーンとBD-Jプレーンとは排他的なものであり、何れか一方が利用されている場合、他方は利用されないため、IGプレーンとBD-Jプレーンとでは1つのプレーンメモリを兼用している。
【００５２】
上記レイヤモデルにおいて、ビデオプレーンについては、ベースビュー用のビデオプレーンと、ディペンデントビュー用のビデオプレーンとが存在するものの、IG/BD-Jプレーン、PGプレーンについては、ベースビュー用、ディペンデントビュー用のそれぞれについて、プレーンメモリが存在する訳ではない。よってIG/BD-Jプレーン、PGプレーンがシフト制御の対象になる。
【００５３】
図４は、1plane＋Offsetモードにおいて、プレーンメモリのレイヤモデルに対してどのようなオフセット制御がなされるかを示す。本図におけるプレーンメモリのレイヤモデルは、IGプレーン、PGプレーン、ビデオプレーン、バックグラウンドプレーンから構成される。
【００５４】
本図（ａ）に示すように、ベースビュー期間においてPGプレーン及びIGプレーンは、左方向にシフトされる。この際、左方向シフト後のPGプレーンは、右側に透明領域が追加され、左側の端部が切り取られる。同じく左方向シフト後のIGプレーンは、右側に透明領域が追加され、左側の端部が切り取れる。
【００５５】
本図（ｂ）に示すように、ディペンデントビュー期間において、PGプレーン及びIGプレーンは、右方向にシフトされる。この際、右方向シフト後のPGプレーンは、左側に透明領域が追加され、右側の端部が切り取られる。同じく右方向シフト後のIGプレーンは、左側に透明領域が追加され、右側の端部が切り取られる。
図５は、図４におけるオフセット制御によって、どのような立体視映像が再生されるかを示す。IGプレーンの格納内容が、前チャプターへのスキップと、次チャプターへのスキップとを受け付けるGUI部品であり、PGプレーンの格納内容が『Dinos』という表題を示す字幕文字である場合、上述したような1plane＋Offsetモード時のオフセット制御によって、IGプレーン、PGプレーンの格納内容は、それぞれ（ａ）（ｂ）のものとなる。
【００５６】
（ａ）は、左シフト時のIGプレーンの格納内容と、右シフト時のIGプレーンの格納内容とを示す。（ｂ）は、左シフト時のPGプレーンの格納内容と、右シフト時のPGプレーンの格納内容とを示す。このようにオフセット制御がなされれば、（ｃ）のような立体視映像が再生されることになる。この（ｃ）の立体視映像では、図２に示した恐竜に、GUIと、字幕とが合成されるので、現状のBD-ROMコンテンツでなされているような字幕、GUIを伴う映画コンテンツが、立体視映像として再生されることになる。
【００５７】
図６は、1plane＋Offsetモードにおける立体視の実現の仕方を示す。
1plane＋Offsetモードにおいて、レフトビュービデオを出力する場合、PGプレーンと呼ばれるプレーンメモリに格納されている画像データの座標を+オフセット値だけX軸の正の方向へをずらす。そしてレフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後、他のプレーンとの合成に供する（図６（ａ）参照）。
【００５８】
ライトビュービデオを出力する場合、プレーンメモリをオフセット値だけX軸の負の方向をずらし、レフトビュービデオからはみ出ないようにプレーンメモリをクロッピングした後にプレーンとの合成に供する（図６（ｂ）参照）。
【００５９】
図６（ｃ）は、オフセット値を使ってクロッピングして重畳した後にユーザにどのように表示されるかを模式的に示した図である。オフセット値を使ってプレーンをずらしてクロッピングすると、左目と右目用に視差画像を作り出すことができるため、平面のイメージに対して深度をつけることが可能となる。かかる深度が存在すれば、ユーザは、平面イメージが表示装置の画面から浮かび上がったような表現が可能である(図６（ｄ）参照)。
【００６０】
図７は、1plane＋Offsetモードのための制御情報を具備したディペンデントビューストリームの内部構成を示す。第１段目は、複数のGOPであり、第２段目は、GOPを構成する複数のビデオアクセスユニットを示す。これらのビデオアクセスユニットは、ビューコンポーネントに該当するもので、GOPにおける個々の表示フレーム(図中のFrame(1)〜Frame(number＿of＿displayed＿frames＿in＿GOP))において表示される。
【００６１】
第３段目は、ビデオアクセスユニットの内部構成を示す。ビデオアクセスユニットは、ビデオアクセスユニットデリミター、シーケンスパラメータセット、ピクチャパラメータセット、MVCスケーラブルネスティングSEIメッセージ、ファーズトビューコンポーネント、シーケンス終端コード、ストリーム終端コードを配列することにより構成される。そしてこのMVCスケーラブルネスティングSEIメッセージの中に、ユーザデータコンテナが存在する。
【００６２】
図８は、ユーザデータコンテナの内部構成を示す図である。
同図（ａ）は、ユーザデータコンテナの内部構成を示す。ユーザデータコンテナは、アンレジスタードユーザデータ(未登録ユーザデータ)のことであり、クローズドキャプション情報、GOP構造マップ、オフセットメタデータという3つの種類がある。これらの種類は、コンテナ中のtype＿indeicatorに明示される。
【００６３】
同図（ｂ）は、オフセットメタデータを示す。オフセットメタデータは、PGプレーン、IGプレーン、BD-Jプレーンのためのシーケンスリストであり、立体視再生モードにおいてプレゼンテーショングラフィクス＿テキスト字幕、IG/BD-Jプレーンが1plane＋Offsetモードで再生されている間におけるオフセット設定に用いられる。具体的には、ピクチャデータと合成すべきグラフィクスを、1plane＋Offsetモードで再生する場合におけるPGプレーン、IGプレーン、BD-Jプレーンに対するオフセット制御を示す。
【００６４】
メタデータは、ディペンデントビューアクセスユニットの符号化順序における各GOPの先頭のビデオコンポーネントのMVCスケーラブルネスティングSEIメッセージに格納されねばならない。MVCスケーラブルネスティングSEIメッセージを含むNALユニットは、メタデータのユーザデータコンテナ以外の他のデータを含んでいてはならない。
【００６５】
同図（ｂ）は、オフセットメタデータ(Offset＿metadata)の内部構成を示す。
フレームレート(frame＿rate)は、オフセットメタデータを含むアクセスユニットのフレームレートを記述する。
【００６６】
プレゼンテーションタイムスタンプ(PTS)は、GOPにおける最初のフレームレートを90KHzで記述する。
オフセットシーケンスナンバー(number＿of＿offset＿sequence)は、０から３２までの範囲で、シーケンス数を記述する。
【００６７】
表示フレームナンバーインGOP(number＿of＿displayed＿frames＿in＿GOP)は、メタデータが含まれるGOPにおける表示フレーム数を示す。
number＿of＿sequence個のオフセットシーケンス(offset＿sequence[1]〜offset＿sequence[number＿of＿sequence]))は、ビデオストリームにおける個々のGOPに対応するオフセットシーケンスの集まりである。
【００６８】
同図（ｃ）は、オフセットシーケンスの内部構成を示す。オフセットシーケンスは、前記グラフィクスを、グループオブピクチャに属する各ピクチャデータと合成する場合における制御パラメータを、グループオブピクチャにおけるフレーム期間毎に示すパラメータシーケンスであり、number＿of＿displayed＿frames＿in＿GOPに示される個数の制御パラメータから構成される。この制御パラメータは、プレーンオフセット方向情報と、プレーンオフセット値とから構成される。
【００６９】
プレーンオフセット方向情報(Plane＿offset＿direction)は、プレーンにおけるオフセット方向を指示する。値“０”でフロント設定、つまり、プレーンメモリは、TVと視聴者との間に存在し、レフトビュー期間においてプレーンは右方向に、ライトビュー期間においてプレーンは左方向にシフトされる。
【００７０】
値＝１でビハインド設定、つまり、プレーンメモリは、TV又はスクリーンの背後に存在し、レフトビュー期間においてプレーンは左方向に、ライトビュー期間においてプレーンは右方向にシフトされる。プレーンオフセット方向情報がフロント設定を示す場合、3次元座標系における制御パラメータのZ軸座標は、正の座標になる。プレーンオフセット方向情報がビハインド設定を示す場合、3次元座標系における制御パラメータのZ軸座標は、負の座標になる。
【００７１】
プレーンオフセット値(Plane＿offset＿value)は、グラフィクスを構成する画素の水平方向の変位量の指定であり、プレーンのオフセット値を画素単位で指示する。
図９は、オフセットメタデータを記述するためのシンタックスを示す。offset＿sequence＿idを制御変数としたfor文は、number＿of＿offset＿sequence個のoffset＿sequenceを定義する。
【００７２】
iを制御変数としたfor文は、Plane＿offset＿directionと、Plane＿offset＿valueとの組みを、number＿of＿displayed＿frame＿in＿GOPだけ定義する。このようなfor文を用いることで、上述したようなオフセットシーケンスは定義されることになる。
【００７３】
図１０は、正と負のプレーンオフセットの見え方の違いの一例を示す図である。同図（ａ）（ｂ）において、手前の方は、ライトビュー出力時にシフトしたシフト後のグラフィクスプレーンを用いて出力されるライトビュー用のグラフィクスイメージを示す。奥の方は、レフトビュー出力時にシフトしたシフト後のグラフィクスプレーンを用いて出力されるレフトビュー用のグラフィクスイメージを示す。
【００７４】
本図（ａ）は、プレーンオフセットの符号が正（レフトビュー用のグラフィクスイメージを右方向へずらし、ライトビュー用のグラフィクスイメージを左方向へずらす）である場合を示す。プレーンオフセットが正の値であると、レフトビュー出力時の字幕がライトビュー出力時の字幕より右の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより手前にくるので、字幕も手前に見えるようになる。
【００７５】
本図（ｂ）は、プレーンオフセットの符号が負である場合を示す。負の値であると、図１４に示したように、レフトビュー出力時の字幕がライトビューの出力時の字幕より左の位置に見えるようになる。つまり、輻輳点（焦点位置）がスクリーンより奥にゆくので、字幕も奥に見えるようになる。
【００７６】
以上で、プレーンオフセットの正と負の切り替えによって、字幕が表示画面の位置よりも飛び出るか奥にゆくかを変化する方法についての説明を終える。
＜オフセットシーケンスの技術的意義＞
オフセットシーケンスは、上記データ構造を具備することにより、ビデオストリーム時間軸における各フレーム毎にグラフィクスの奥行きを定義することができるので、何れ1つのオフセットシーケンスを用いることで、任意のフレーム時間tから、そのフレーム時間に対応する奥行きzを導出する関数Ｚ(t)を定義することができる。この関数Ｚ(t)が、フレーム時刻tに対して奥行きを線形的に変化させるものなら、再生装置は、かかる関数Ｚ(t)に対応するオフセットシーケンスを、1plane＋Offsetモードに用いることで、再生進行に伴いグラフィクスの奥行きを線形的に変化させることができる。また関数Ｚ(t)が、フレーム時刻tに対して奥行きを、指数的に変化させるものなら、再生装置は、かかる関数Ｚ(t)に対応するオフセットシーケンスを、1plane＋Offsetモードに用いることで、再生進行に伴いグラフィクスの奥行きを指数的に変化させることができる。ビデオストリーム時間軸における再生時点の進行に伴い、リアルタイムに奥行きを変化させることができるので、リアリティに富んだグラフィクスの立体視再生を実現することができる。
【００７７】
図１１は、横軸を時間軸とし、縦軸を、Plane＿offset＿value[j]としたグラフである。横軸における時間軸は、ディペンデントビューアクセスユニットを構成する個々のGOPが一個の時間単位になっている。縦軸のうち正の方向は、Plane＿offset＿direction[j]が0である場合のPlane＿offset＿value[j]を示し、縦軸のうち負の方向は、Plane＿offset＿direction[j]が1である場合のPlane＿offset＿value[j]を示す。そしてグラフ中の曲線、直線は、offset＿sequence＿id＝１,２,３,４のオフセットシーケンスによるPlane＿offset＿direction[j]の時間的変位を示す。これらのうちoffset＿sequence＿id＝１,４のオフセットシーケンスは、時間軸に対して、線形的に変化する奥行きを定義する線形関数のオフセットシーケンスであり、offset＿sequence＿id＝２,３のオフセットシーケンスは、時間軸に対して、放物線状に変化する奥行きを定義する放物線関数のオフセットシーケンスである。
【００７８】
図１２は、横軸を時間軸とし、縦軸をPlane＿offset＿value[j]としたグラフである。横軸における時間軸は、ディペンデントビューアクセスユニットのGOPにおける個々のフレームが一個の時間単位になっている。よって、図１１に示したoffset＿sequence＿id＝１,２,３のオフセットシーケンスは、フレームの時間精度で表現すれば、フレーム期間毎に離散的な値になっていることがわかる。各オフセットシーケンスは、1秒当りに24個の離散的な奥行きを定義することができるので、１秒当りに24回の時間精度をもって、各オフセットシーケンスによる奥行きを変化させることができる。よって本編の動画像による立体視映像と比較して遜色がない、リアリティの高い奥行き変化で、３次元座標系におけるグラフィクスのZ座標を変化させることができる。
【００７９】
また、メタデータは複数のオフセットシーケンスを格納することができるので、複数のオフセットシーケンス1,2,3,4・・・・nを用いることにより、奥行きの時間的な変化が互いに異なる複数の奥行き関数Ｚ1(t),Ｚ2(t),Ｚ3(t),Ｚ4(t)・・・・・Ｚn(t)を定義できる。ここで、奥行き関数Ｚ1(t)が、変数tに応じて奥行きを変化させる１次関数であり、Ｚ2(t)が二次関数、Ｚ3(t)が三次関数、Ｚ4(t)が四次関数、Ｚn(t)がn次関数というように、複数のオフセットシーケンス1,2,3,4・・・・nを用いれば、奥行きと、フレーム時間との相関性が異なる複数の奥行き関数を定義することができる。
【００８０】
再生装置による動作にあたって、複数のオフセットシーケンス1,2,3,4・・・・nの何れかを選択するという動作を行えば、再生装置の状態変化や、ユーザからの要求に応じて、複数の奥行き関数Ｚ1(t),Ｚ2(t),Ｚ3(t),Ｚ4(t)・・・・・Ｚn(t)の中から最適なものを選び、1plane＋Offsetモードに用いることができる。こうすることで、1plane＋Offsetモードにおけるグラフィクスの奥行きの変化の仕方に、様々なバリエーションをもたせることができる。
【００８１】
本実施形態で定義される複数のオフセットシーケンスは、それぞれ奥行きの時間的変化が異なる表示位置を規定するので、再生装置において所定のストリーム選択プロシージャを実行して、複数のオフセットシーケンスのうち、最適なものを選択することにより、適切な位置にグラフィクスを配置させることができる。
【００８２】
以上が第１技術的意義についての説明である。続いて、第２の技術的意義の詳細について説明する。
第２の技術的意義としては、画面中の移動体におけるそれぞれの部位に応じた奥行きを定義できる点である。図２に示した恐竜の骨格において、頭、胴体、脚、尻尾のそれぞれの部位ではその奥行きが自ずと異なる。更に、動画像において、これら頭、胴体、脚、尻尾のそれぞれの部位の奥行きは、時間的に遷移するので、これらの頭、胴体、脚、尻尾のそれぞれの部位の丁度手前の位置の奥行きを示すような制御パラメータを、GOPの各フレーム毎に明示できるよう、メタデータにおいては、オフセットシーケンスを複数定義できるようなデータ構造を有している。
【００８３】
図１３は、offset＿sequence＿id＝１、２、３、４のオフセットシーケンスによって、どのような奥行きが定義されるかの一例を示す。
ここでoffset＿sequence＿id＝１、２のオフセットシーケンスは、ユーザと恐竜との間に字幕／メニューを配置するための適切な奥行きを指定するものであり、offset＿sequence＿id＝３、４のオフセットシーケンスが、恐竜の後ろに字幕／メニューを配置するための適切な奥行きを指定するものである。そしてこれらのうち、offset＿sequence＿id＝１のオフセットシーケンスは、ユーザの近くに奥行きを定義し、offset＿sequence＿id＝２のオフセットシーケンスは、恐竜の手前の奥行きを定義する。offset＿sequence＿id＝３のオフセットシーケンスは、恐竜の足元に沿った奥行きを定義するものであり、offset＿sequence＿id＝４のオフセットシーケンスは、恐竜よりもかなり後ろに字幕／メニューを配置するための適切な奥行きを指定するものである。
【００８４】
立体物の頭、胴体、脚、尻尾のそれぞれの部位の丁度手前の位置の奥行きを示すような制御パラメータを定義することができ、また、この制御パラメータの時間的変位をGOPの各フレーム毎に定義することができるので、図９のシンタックスで定義されるデータ構造を用いれば、緻密で高精度な1plane＋Offsetモードでのシフト制御を実現することができる。
【００８５】
図中の恐竜が画面内で動き回るものであり、字幕／メニューの適切な奥行きが、時々刻々と変化する場合でも、オフセットシーケンスの何れかを指定することにより、恐竜の適切な位置に、字幕／メニューの配置することができる。
【００８６】
以上が第２の技術的特徴についての説明である。
図１４は、第１実施形態に係る記録媒体における内部構成を示す。本図（ａ）に示すように、第１実施形態に係る記録媒体には、「インデックステーブルファイル」、「動作モードオブジェクトのプログラムファイル」、「プレイリスト情報ファイル」、「ストリーム情報ファイル」、「ストリームファイル」が記録されている。
【００８７】
＜インデックステーブルファイル＞
インデックステーブルファイルは記録媒体全体に関する管理情報であり、再生装置への記録媒体挿入後に、インデックステーブルファイルが最初に読み出されることで、再生装置において記録媒体が一意に認識される。
【００８８】
インデックステーブルファイルは、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。映画作品と、タイトルとの関係は、映画作品と、それの複数バージョンとの関係である。つまり1つのバージョンしかないような映画作品は、「映画作品＝タイトル」という関係になる。映画作品に、劇場公開版、ディレクターズカット版、TV放映版等、複数のバージョンがある場合、映画作品における個々のバージョンが1つのタイトルになる。
【００８９】
ここで、タイトル番号レジスタにおけるタイトル番号は、０、１〜９９９、不定値(0xFFFF)という番号がある。タイトル番号０は、トップメニュータイトルのタイトル番号である。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値(0xFFFF)のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。
【００９０】
インデックステーブルは、各タイトル番号のそれぞれに対応したエントリー(インデックステーブルエントリー)を有し、個々のインデックステーブルエントリーに、動作モードを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。インデックステーブルエントリーは、以下の共通のデータ構造で定義される。この共通のデータ構造は、『オブジェクトタイプ』と、『ムービーオブジェクトレファレンス』と、『オブジェクトファイル名情報』とを含む。『オブジェクトタイプ』は、該当するタイトルに関付けられている動作モードオブジェクトが、MovieオブジェクトであるかBD-Jオブジェクトであるかを示す。『オブジェクトファイル名情報』は、タイトルに関連付けられたBD-Jオブジェクトのファイル名を示す。『ムービーオブジェクトレファレンス』は、タイトルに関連付けられたムービーオブジェクトの識別子を示す。
【００９１】
再生装置においてタイトル番号レジスタの値は、記録媒体の装填後、不定値0xFFFF→１〜９９９→０というように変化する。このタイトル番号の変化は、記録媒体の装填時に、ファーストプレイタイトルの再生を開始し、ファーストプレイタイトルの再生後、１から999までのタイトル番号レジスタのタイトル番号で指示されるタイトルの再生を行い、タイトル番号で指示されるタイトルの再生が終了すれば、トップメニュータイトルを再生してユーザによる選択待ちを行うというものである。１〜９９９のタイトル番号をもつタイトルのうち、タイトル番号レジスタに格納されているタイトル番号と、同じタイトル番号をもつものが、現在の再生対象、つまりカレントタイトルになる。タイトル番号レジスタにどのような番号を設定するかは、トップメニュータイトルに対するユーザ操作や、プログラムによるタイトル番号レジスタの設定によって決定される。
【００９２】
＜動作モードオブジェクトのプログラムファイル＞
動作モードオブジェクトのプログラムファイルは、再生装置の動作モードを規定するプログラムである動作モードオブジェクトを格納している。動作モードオブジェクトには、コマンドによって記述されたものと、オブジェクト指向のコンパイラ言語によって記述されたものがある。前者の動作モードオブジェクトは、コマンドベースの動作モードにおいて、複数のナビゲーションコマンドをバッチジョブとして再生装置に供給し、これらナビゲーションコマンドに基づき再生装置を動作させる。このコマンドベースの動作モードを、“HDMVモード”と呼ぶ。
【００９３】
後者の動作モードオブジェクトは、オブジェクト指向型のコンパイラ言語ベースの動作モードにおいて、クラス構造体のインスタンスを再生装置に供給し、このインスタンスに基づき再生装置を動作させる。クラス構造体のインスタンスには、Java(登録商標)アプリケーションを用いることができる。オブジェクト指向型コンパイラ言語ベースの動作モードを、“BD-Jモード”と呼ぶ。
【００９４】
＜プレイリスト情報ファイル＞
プレイリスト情報ファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。“プレイリスト”とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの“型”を定義する。プレイリスト情報によって定義される再生経路は、いわゆる“マルチパス”である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。メインパスは1本であるのに対して、サブパスは、複数本定義することができ、これら複数のサブパスは、サブパスIDと呼ばれる識別子によって識別される。かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。BD-Jモードでは、再生制御のためのJava(登録商標)アプリケーションが、このプレイリスト情報を再生するJMFプレーヤインスタンスの生成をJava(登録商標)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMF(JavaMediaFrame work)プレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。HDMVモードでは、プレイリストによる再生を命じるナビゲーションコマンドを再生装置に実行させることで、再生を開始することができる。再生装置には、カレントのプレイリスト情報の番号を格納するプレイリスト番号レジスタを含み、複数のプレイリスト情報のうち、このプレイリスト番号レジスタに格納されているものが、現在の再生対象になる。
【００９５】
＜ストリーム情報ファイル＞
ストリーム情報ファイルは、ストリームファイルのそれぞれと一対一の割合で存在するクリップ情報ファイルであり、ストリームファイル内に存在するソースパケット列がどのようなATCシーケンスを構成するか、それらのATCシーケンス内にどのようなSTCシーケンスが組込まれているのか、ATCシーケンスがどのようなTSであるのかを示す。
【００９６】
ストリーム情報ファイルは、ストリームファイルの中身を明らかにするものなので、ストリームファイル内のTSを再生しようとする場合、そのストリームファイルに対応するストリーム情報ファイルを予めメモリに読み出しておく必要がある。つまり、ストリームファイル再生にあたっては、予めストリーム情報ファイルをメモリに読み出すという前置主義が採用される。このような前置主義を採用しているのは以下の理由による。ストリームファイルに格納されるTSは、欧州デジタル放送規格と互換性があるデータ構造になっているが、放送番組として扱うためのPMT、PCR、PATといった情報はストリーム内に存在するため、これらを再生する度に取り出すのは賢明ではない。ストリームを再生する度に、低速な記録媒体をアクセスしてTSを構成するパケットを読み出し、そのTSパケットのペイロードを解析するという処理が必要になるからである。そこで、TSを構成するペイロードの中身を解析することなく、TSの諸元を把握できるよう、TSを格納したストリームファイルと一対一の比率でストリーム情報ファイルを設けておき、ストリーム再生に先立ち、ストリーム情報ファイルをメモリに読み出すことにしている。
【００９７】
＜ストリームファイル＞
ストリームファイルは、１又複数のソースパケット列を格納している。ソースパケットとは、２ビットのコピーパーミッションインディケータと、３０ビットのATS（到着時刻：ArrivalTime  Stamp）とから構成される４バイトのTP＿Extra＿Headerが付加されたTSパケットである。TP＿Extra＿HeaderにおけるATSは、実時間伝送が行われ、等時性が確保された状態での伝送における到達時刻をいう。
【００９８】
これらのソースパケット列のうち、アライバルタイムクロック(ATC)時間軸において、タイムスタンプが連続している複数のソースパケットから構成されているものを“ATCシーケンス”と呼ぶ。“ATCシーケンス”とは、ソースパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、連続性が存在するソースパケット列を“ATCシーケンス”という。ATCシーケンスは、ATCのタイムスタンプが連続しているソースパケット列であるから、再生装置のアライバルタイムクロックを計時するクロックカウンタが計時を行っている間、ATCシーケンスを構成する各ソースパケットは、連続的なソースパケットデパケッタイジング処理、及び、連続的なパケットフィルタリング処理に供されることになる。
【００９９】
ATCシーケンスがソースパケットの配列であるのに対し、STC時間軸におけるタイムスタンプが連続しているTSパケットの配列をSTCシーケンスという。“STCシーケンス”とは、TSパケットの配列であって、TSのシステム基準時刻であるSTC(SystemTime Clock)の不連続点(system time-base discontinuity)をもたないものをいう。STCの不連続点とは、デコーダがSTCを得るために参照するPCR(ProgramClock Reference)を運ぶPCRパケットの不連続情報(discontinuity＿indicator)がONである点である。STCシーケンスは、STCのタイムスタンプが連続しているTSパケット列であるから、再生装置のシステムタイムクロックを計時するクロックカウンタが計時を行っている間、STCシーケンスを構成する各TSパケットは、再生装置内に存在するデコーダの連続的なデコード処理に供されることになる。
【０１００】
ストリームファイルにおけるメインTS、サブTSは、ストリームファイルに対応するストリーム情報ファイル内のクリップ情報によって、1つの“AVストリームの切れ端”つまり、“AVクリップ”として管理されている
またストリームファイルに格納されるパケット列は、複数種別のPESストリームを管理・制御するための情報として、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)を具備している。
【０１０１】
PCR(Program＿Clock＿Reference)は、ATSの時間軸であるATC（Arrival  Time  Clock）とPTS・DTSの時間軸であるSTC（System  Time  Clock）の同期を取るために、そのPCRパケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。
【０１０２】
PMT(Program＿map＿table)は、ストリームファイル中に含まれる映像・音声・グラフィクスなどの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、またTSに関する各種ディスクリプタを持つ。ディスクリプタにはストリームファイルのコピーを許可・不許可を指示するコピーコントロール情報などがある。
【０１０３】
PAT（Program  Association  Table）は、TS中に利用されるPMTのPIDが何であるかを示し、PAT自身のPID配列で登録される。
これらのPCR,PMT,PATは、欧州デジタル放送規格において、一個の放送番組(Program)を構成するパーシャルTSを規定する役割をもち、再生装置は、欧州デジタル放送規格において、一個の放送番組を構成するパーシャルTSを扱うかの如く、TSをデコーダによる処理に供することができる。これは、欧州デジタル放送規格の端末装置と、記録媒体再生装置との互換性を意図したものである。TSのうち、マルチパスの基軸となるものを“メインTS”という。またサブパスの基軸となるものを“サブTS”という。
【０１０４】
図１４（ｂ）は、メインTSの内部構成を示し、同図（ｃ）は、サブTSの内部構成を示す。同図（ｂ）に示すように、メインTSは、１本のベースビュービデオストリームと、３２本のベースビューPGストリーム、３２本のベースビューIGストリーム、３２本のオーディオストリームを含むものとする。同図（ｃ）に示すように、サブTSは、１本のディペンデントビュービデオストリームと、３２本のディペンデントビューPGストリーム、３２本のディペンデントビューIGストリームを含むものとする。
【０１０５】
次に、TSの内部構成について説明する。
図１５は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図（ａ）における第１段目はビデオストリームのビデオフレーム列を示す。第２段目は、PESパケット列を示す。第３段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy１,yy２,yy３, yy４に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS（Presentation  Time-Stamp）やピクチャの復号時刻であるDTS（Decoding  Time-Stamp）が格納される。
【０１０６】
＜TSパケット列＞
図１５（ｂ）は、TSを構成するTSパケットの形式を示している。第１段目は、TSパケット列を示し、第２段目は、ソースパケット列を示す。
【０１０７】
第１段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ４Byteの「TSヘッダ」とデータを格納する１８４Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
【０１０８】
第２段目によると、TSパケットには、４ByteのTP＿Extra＿Headerが付与されて、１９２Byteのソースパケットに変換された状態で、TSを構成する。TP＿Extra＿HeaderにはATS（Arrival＿Time＿Stamp）などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。TSには、第３段目に示すようにソースパケットが並ぶこととなり、TSの先頭からインクリメントする番号はSPN（ソースパケット番号）と呼ばれる。
【０１０９】
＜TSにおける多重化＞
図１６は、メインTSがどのように多重化されるかを模式的に示す図である。まず、レフトビュービデオストリーム、及び、オーディオストリームを(第１段目)、それぞれPESパケット列に変換し(第２段目)、ソースパケット列に変換する(第３段目)。同じくレフトビューPGストリームおよびレフトビューインタラクティブグラフィクス(第７段目)を、それぞれPESパケット列に変換し(第６段目)、更にソースパケット列に変換する(第５段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、メインTSが得られることになる。
【０１１０】
・TSに多重化されるエレメンタリストリーム
これらのTSに多重化されるエレメンタリストリーム(ES)は、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームがある。
【０１１１】
・ビデオストリーム
ベースビューとなるビデオストリームは、ピクチャインピクチャアプリケーションにおけるプライマリビデオストリームを構成する。ピクチャインピクチャアプリケーションは、このプライマリビデオストリームの他、セカンダリビデオストリームから構成される。プライマリビデオストリームとは、ピクチャインピクチャアプリケーションにおいて親画面となるピクチャデータから構成されるビデオストリームである。対照的に、セカンダリビデオストリームとは、ピクチャインピクチャにおいて子画面として、親画面の一部にはめ込まれるピクチャデータから構成されるビデオストリームである。
【０１１２】
プライマリビデオストリームを構成するピクチャデータと、セカンダリビデオストリームを構成するピクチャデータとはデコード後、別々のプレーンメモリに格納される。セカンダリビデオストリームを構成するピクチャデータを格納するプレーンメモリの前段には、セカンダリビデオストリームを構成するピクチャデータのスケーリング変更及び表示座標の位置決めを行う構成要素(Scalling&Positioning)が存在する。
【０１１３】
・オーディオストリーム
オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの２種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。セカンダリオーディオストリームは、このミキシングのためのダウンサンプリングのための情報、ゲイン制御のための情報が存在する。
【０１１４】
・プレゼンテーショングラフィクスストリーム(PGストリーム)
PGストリームは、デコーダにパイプラインを採用することで、映像との緻密な同期を実現することができ、字幕表示に適したグラフィクスストリームであり、2DPGストリームと、立体視PGストリームという2つの種類がある。立体視PGストリームには、レフトビューPGストリーム及びライトビューPGストリームという二種類のものがある。レフトビューPGストリーム及びライトビューPGストリームのうち、ベースビューインディケータによって指定されているものがベースビューPGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューPGストリームになる。
【０１１５】
2DPGストリームの他に、立体視PGストリームを設けるのは、PGストリームが字幕文字を表す場合、2Dで表示される真正面から見た字幕文字と、3D-LRモードで左目用に表示されるグラフィクスと、右目用に表示される字幕文字とは異なるものにする必要からである。そのため、2D再生の場合は正面から見たグラフィクスストリームを１本、3D-LRモード用にはレフトビューPGストリーム、ライトビューPGストリームの計２本を表示する。同様に、深度情報を用いる3D-Depthモードの場合は、正面から見た映像と深度情報を示すグレースケールストリームを再生する。2D+offset（2D互換ストリーム）と、3D-LRストリームとは、混在させてはならない。
【０１１６】
2DPGストリームは最大３２本、ベースビューPGストリームの最大３２本、ディペンデントビューPGストリームも最大３２本定義することができる。これらのPGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのPGストリームのうち、所望のものが再生に供されることになる。
【０１１７】
レフトビューPGストリーム、ライトビューPGストリームは、互いに言語属性は一致させておき、ユーザーが表示方式を切り替えても、同じ内容の字幕が表示されるようにする。前提として、2D字幕と3D字幕とは1対1に対応し、2Dでしかない字幕、及び、3Dでしかない字幕を設けてはならないない。切り替え時のユーザー混乱を防止するためである。こうすることにより、1つのストリーム番号で、2D/3Dそれぞれの表示モードに対応するストリームが選択されることになる。この場合、1つのストリーム番号で言語属性などは同じになり、2DとLRの字幕の内容は同じになる。
【０１１８】
パイプラインによるデコード動作の実現により、動画像との緻密な同期を実現するので、PGストリームの用途は字幕のような文字再生に限定されない。映画作品のマスコットキャラクタを表示して、これを動画像と同期させつつ動作させるなど、緻密な同期が必要なグラフィクス再生であれば、どのようなものも、PGストリームによる再生対象として、採用することができる。
【０１１９】
ストリームファイルに多重化されないが、字幕を現すストリームには、PGストリームの他に、テキスト字幕(textST)ストリームというものがある。textSTストリームは、字幕の内容をキャラクタコードで現したストリームである。
【０１２０】
PGストリーム、テキスト字幕ストリームは、これらの種類が区別されることなく、同じストリーム種別であるとして、これらPGストリーム及びテキスト字幕ストリームは、同じストリーム登録列に登録される。そして、ストリーム選択のプロシージャを実行するにあたって、ストリーム登録列におけるストリーム登録の順位に従い、再生されるべきPGストリーム又はテキスト字幕ストリームが定まる。PGストリーム、テキスト字幕ストリームは、ストリーム種が区別されることなく、ストリーム選択のプロシージャに供されるのでこれらPGストリーム及びテキスト字幕ストリームを1つのストリーム種別、つまり、“PG＿テキスト字幕ストリーム(略して、字幕ストリームと呼ぶ場合もある)”という種別で扱う。
【０１２１】
2D用のPG＿テキスト字幕ストリームは、1plane＋Offsetモードにおいて再生される。以降の説明では、2DPG＿テキスト字幕ストリームを、1plane＋OffsetPG＿テキスト字幕ストリームであるとして説明する。
【０１２２】
・インタラクティブグラフィクス(IG)ストリーム
IGストリームは、対話操作の情報を具備することで、ビデオストリームの再生進行に伴ってメニューを表示したり、またユーザ操作に従いポップアップメニューを表示することができるグラフィクスストリームである。
【０１２３】
IGストリームもPGストリームと同様、2DIGストリームと、立体視IGストリームという2つの種類がある。立体視IGストリームには、レフトビューIGストリーム及びライトビューIGストリームという二種類のものがある。レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームのうち、ベースビューインディケータによって指定されているものがベースビューIGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューIGストリームになる。  2DIGストリームは最大３２本、IGストリームは最大３２本、ディペンデントビューIGストリームも最大３２本定義することができる。これらのIGストリームには、それぞれ、別々のパケット識別子が付与されており、多重分離部に、再生すべきパケット識別子を指示することで、これらのIGストリームのうち、所望のものが再生に供されることになる。
【０１２４】
IGストリームの制御情報(対話制御セグメントという)は、ユーザインターフェイスモデルを規定する情報(User＿interface＿model)をもっており、オーサリング者は、このユーザインターフェイスモデル情報を設定することで、ビデオストリームの再生進行に伴ってメニューを表示するか(Alwaysオンという)、ユーザ操作に従いポップアップメニューを表示するか(ポップアップメニューオン)の何れかを指定することができる。
【０１２５】
IGストリームが対話操作の情報をもつ意義は以下の通りである。Java（登録商標）仮想マシンがアプリケーションからの要求に応じてプレイリスト再生の開始を再生制御の主体である再生制御エンジンに指示する場合、Java仮想マシンは、再生制御エンジンに再生を命じた後、プレイリスト再生を開始した旨のレスポンスをアプリケーションに返す。つまり、再生制御エンジンによるプレイリスト再生が継続している間、Java仮想マシンは、実行終了待ちにはならない。何故なら、Java仮想マシンは、いわゆるイベントドリブン型の動作主体であり、再生制御エンジンがプレイリストの再生を行っている間も、動作を行うことができるからである。
【０１２６】
一方、HDMVモードにおいて、コマンドインタプリタが、プレイリスト再生を再生制御エンジンに命じる場合、プレイリスト再生が終了するまで、そのプレイリスト再生の実行終了待ちとなる。再生制御エンジンによる再生が継続している間、コマンド実行部は、対話的な処理を実行することはできない。このコマンドインタプリタの代わりに、グラフィクスデコーダが対話的な動作を行う。グラフィクスデコーダに対話的な動作を行わせるため、IGストリームには、ボタン部材を用いた対話的な操作を規定する制御情報が組込まれている。  
【０１２７】
・各ストリーム種別において許容される表示モード
3D表示モードのどれが許容されるかは、ストリーム種別によって異なる。プライマリビデオストリームの3D表示モードには、B−Dプレゼンテーションモード、B−Bプレゼンテーションモードといった2つの再生モードが許容される。プライマリビデオストリームにおいて、B−Bプレゼンテーションモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、“立体視B−D再生タイプ”という。B−Bプレゼンテーションモードで再生される場合におけるプライマリビデオストリームの類型を、立体視B−B再生タイプという。
【０１２８】
PGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。PGストリームにおいて、1plane＋ZeroOffsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるPGストリームの類型を、“立体視再生タイプ”という。1plane＋Offsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Offsetタイプという。1plane＋ZeroOffsetモードで再生される場合におけるPGストリーム,PG＿テキスト字幕ストリームの類型を、1plane＋Zero Offsetタイプという。
【０１２９】
テキスト字幕ストリームの3D表示モードには、1plane＋Offsetモード、1plane＋Zero Offsetモードといった2つの再生モードが許容される。テキスト字幕ストリームにおいて、1plane＋ZeroOffsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。
【０１３０】
IGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane＋Offsetモード、1plane＋Zero Offsetモードといった3つの再生モードが許容される。IGストリームにおいて、1plane＋ZeroOffsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。以降の説明では、特に断らない限り3D再生モード実行時には、ピクチャインピクチャは使用できないものとする。ピクチャインピクチャ及び3D再生モードは、何れも非圧縮のピクチャデータを格納するためのビデオプレーンを2つ必要とするからである。また特に断らない限り、3D再生モードでは、サウンドミキシングも使用できないものとする。
【０１３１】
続いて、メインTS及びサブTSの内部構成について説明する。図１７は、メインTS及びサブTSの内部構成を示す。
同図（ａ）は、メインTSの内部構成を示す。メインTSは、以下のソースパケットによって構成されている。
【０１３２】
0x0100のパケットIDを有するソースパケットはProgram＿Map＿Tableを構成し、0x1001のパケットIDを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケット列は、プライマリビデオストリームを構成する。
【０１３３】
0x1200から0x121FのパケットIDを有するソースパケット列までは、３２本の2DPGストリームを構成する。
0x1400から0x141FのパケットIDを有するソースパケット列までは ３２本の2DIGストリームを構成する。
【０１３４】
0x1100のパケット識別子を有するソースパケット列から、0x111Fのパケット識別子を有するソースパケット列までは、プライマリオーディオストリームを構成する。
これらのソースパケットのパケット識別子を多重分離部に指示することにより、メインTSに多重化されている複数のESのうち、所望のものを分離してデコーダに供することができる。
【０１３５】
図（ｂ）は、サブTSの内部構成を示す。サブTSは、以下のソースパケットによって構成されている。
Ox1012のパケット識別子を有するソースパケット列は、ディペンデントビュービデオストリームを構成する。
【０１３６】
0x1220のパケット識別子を有するソースパケット列から0x123FのパケットIDを有するソースパケット列までは、３２本のベースビューPGストリームを構成する。
Ox1240のパケット識別子を有するソースパケット列から0x125Fのパケット識別子を有するソースパケット列までは、３２本のディペンデントビューPGストリームを構成する。
【０１３７】
0x1420のパケット識別子を有するソースパケット列から0x143FのパケットIDを有するソースパケット列までは ３２本のベースビューIGストリームを構成する。
Ox1440のパケット識別子を有するソースパケット列から0x145Fのパケット識別子を有するソースパケット列は、３２本のディペンデントビューIGストリームを構成する。
【０１３８】
以上がストリームファイルについての説明である。続いて、プレイリスト情報の詳細について説明する。
上述したようなマルチパスを定義するため、図１８のような内部構成を有する。本図は、プレイリスト情報の内部構成を示す。同図（ａ）に示すようにプレイリスト情報は、「メインパス情報」、「サブパス情報」、「プレイリストマーク情報」、「エクステンションデータ」を含む。以下、これらの構成要素について説明する。
【０１３９】
１）メインパス情報は、１つ以上の主たる再生区間情報から構成される。図１８（ｂ）は、メインパス情報、及び、サブパス情報の内部構成を示す図であり、本図に示すように、メインパス情報は、１つ以上の主たる再生区間情報から構成される。サブパス情報は、１つ以上の従たる再生区間情報から構成される。
【０１４０】
主たる再生区間情報はプレイアイテム情報と呼ばれ、TSの再生時間軸のうち、In＿Timeとなる時点と、Out＿Timeとなる時点の組みを1つ以上定義することにより、論理的な再生区間を定義する情報である。再生装置には、カレントのプレイアイテムの番号を格納するプレイアイテム番号レジスタを含み、複数のプレイリスト情報のうち、このプレイアイテム番号レジスタに格納されているものが、現在の再生対象になる。
【０１４１】
図１８（ｃ）は、プレイアイテム情報の内部構成を示す。本図に示すように、「ストリーム参照情報」、「インタイムアウトタイム情報」、「接続状態情報」、「基本ストリーム選択テーブル」を含む。
【０１４２】
ストリーム参照情報は、プレイアイテムを構成するトランスポートストリームを“AVクリップ”として管理しているクリップ情報ファイルを示す「クリップ情報ファイルネーム情報(clip＿information＿file＿name)」、そのTSにおける符号化方式を示す「クリップ符号化方式識別子(Clip＿codec＿indentifier)」、当該TSのSTCシーケンスにおいて、インタイム及びアウトタイムが設定されているSTCシーケンスがどれであるかを示す「STC識別子レファレンス(STC＿ID＿referrence)」を含む。
【０１４３】
再生区間であるプレイアイテムは、プレイアイテム情報−クリップ情報−AVクリップという階層構造を有しており、AVクリップ及びクリップ情報の組みと、プレイアイテム情報との比率については、１対多の関係にして、1つのAVクリップを複数のプレイアイテム情報から多重参照することができる。よって、あるタイトルのために作成されたAVクリップをバンクフィルムとして採用し、これを複数のプレイアイテム情報から参照することで、映画作品のバリエーションを効率良く作成することができる(尚、バンクフィルムとは、映画業界の用語であり、複数のシーンで使いまわしされる映像内容のことである)。
【０１４４】
バンクフィルムとなるAVクリップが多くのプレイアイテム情報から参照されるとなると、参照されるプレイアイテム情報毎に、バンクフィルムのうち、再生させるべき区間を変化させたいという要望がでてくる。参照されるプレイアイテム情報毎に、バンクフィルムの再生させるべき区間を、変化させるという目的のため、プレイアイテム情報には、上述したIn＿Time、Out＿Timeが存在し、ストリーム再生時間軸の任意の時点を再生区間の開始点、終了点として使用できるようになっている。
【０１４５】
またバンクフィルムとなるAVクリップが多くのプレイアイテム情報から参照されるとなると、参照されるプレイアイテム情報毎に、使用する音声や字幕、メニューを変化させたいという要望がでてくる。このように、参照されるプレイアイテム情報毎に、使用する音声や字幕、メニューを変化させるという目的のため、プレイアイテム情報には、上述したストリーム選択テーブルが存在する。このストリーム選択テーブルを用いれば、メインパスとなるプレイアイテム情報から参照されるAVクリップに多重化されているエレメンタリストリーム、サブパスとなるサブプレイアイテム情報から参照されるAVクリップに多重化されているエレメンタリストリームのうち、バンクシーンの引用先にとって最適なもののみの再生を許可することができる。
【０１４６】
以上がプレイアイテム情報についての説明である。
２）従たる再生区間情報は、サブパス情報と呼ばれ、複数のサブプレイアイテム情報から構成される。図１８（ｄ）は、サブプレイアイテムの内部構成を示す。本図に示すように、サブプレイアイテム情報は、STCシーケンスの時間軸にインタイムと、アウトタイムとの組みを規定することで、サブパスを構成する再生区間を定義する情報であり、「ストリーム参照情報」、「インタイムアウトタイム情報」、「シンクロプレイアイテムレファレンス」、「シンクロ開始時刻情報」を含む。『ストリーム参照情報』は、プレイアイテム情報と同様、『クリップ情報ファイルネーム情報』『クリップ符号化方式識別子』、『STC識別子レファレンス』を含む。
【０１４７】
『インタイムアウトタイム情報(SubPlayItem＿In＿Time,SubPlayItem＿Out＿Time)』は、STCシーケンス時間軸における、サブプレイアイテムの始点と、STCシーケンス時間軸上における、サブプレイアイテムの終点とを示す。
【０１４８】
「シンクロプレイアイテムレファレンス(Sync＿PlayItem＿Id)」は、プレイアイテムのうち、本サブプレイアイテムが同期すべきものを一意に指定する情報である。サブプレイアイテムインタイムは、この同期プレイアイテム参照子で指定されたプレイアイテムの再生時間軸上に存在する。
【０１４９】
「シンクロ開始時刻情報(Sync＿Start＿PTS＿of＿PlayItem)」は、同期プレイアイテム参照子で指定されたプレイアイテムのSTCシーケンスの時間軸のうち、サブプレイアイテムインタイムで指定されたサブプレイアイテムの始点が、どの時点に写像されるかを示す
３）プレイリストマーク情報は、再生区間固有のマークポイントを定義する情報であり、再生区間を示す参照子と、デジタルストリームの時間軸において、マークポイントが何処にあるかを示すタイムスタンプと、マークポイントの属性を示す属性情報とを含み、
前記属性情報は、プレイリストマーク情報により定義されたマークポイントが、リンクポイントであるか、エントリーマークであるかを示す。
【０１５０】
リンクポイントは、リンクコマンドによるリンクが可能であるが、チャプタースキップ操作がユーザによりなされた場合の選択対象にはならないマークポイントである。
エントリーマークは、リンクコマンドによるリンクが可能であり、尚且つチャプタースキップ操作がユーザによりなされた場合の選択対象になるマークポイントである。
【０１５１】
IGストリームのボタン情報内に組込まれたリンクコマンドは、プレイリストマーク情報を介した間接参照の形式で頭出し位置を指定している。
＜基本ストリーム選択テーブル(STreamNumber＿table)＞
前記基本ストリーム選択テーブルは、プレイリストを構成する複数のプレイアイテムのうち、その基本ストリーム選択テーブルを包含しているのものがカレントプレイアイテムになった際、マルチパスのメインパスにて参照されているAVクリップに多重化されているES、及び、マルチパスのサブパスにて参照されているAVクリップに多重化されているESのうち、どれの再生を許可するかを、複数のストリーム種別毎に規定するテーブルである。ここでのストリーム種別とは、ピクチャインピクチャにおけるプライマリビデオストリーム、ピクチャインピクチャにおけるセカンダリビデオストリーム、サウンドミキシングにおけるプライマリオーディオストリーム、サウンドミキシングにおけるセカンダリオーディオストリーム、PG＿テキスト字幕ストリーム、インタラクティブグラフィクストリームといった種別をいい、基本ストリーム選択テーブルは、これらのストリーム種別毎に、再生を許可すべきストリームを登録することができる。具体的には、基本ストリーム選択テーブルは、ストリーム登録の配列から構成される。ここでストリーム登録とは、基本ストリーム選択テーブルが帰属しているプレイアイテムがカレントプレイアイテムになった際、再生を許可すべきESがどのようなストリームであるかを、そのストリーム番号に対応付けて示すものであり、ストリーム登録は、論理的なストリーム番号に、ストリームエントリー及びストリーム属性の組合せを対応付けるというデータ構造になっている。ストリーム登録におけるストリーム番号は、１、２、３というような整数値で表現され、ストリーム番号の最大数は、対応するストリーム種別のストリーム本数となる。
【０１５２】
再生装置には、このストリーム種別毎に、ストリーム番号レジスタが存在しており、ここに格納されたストリーム番号で指示されるESが、現在再生対象になっているES、つまりカレントストリームになる。
【０１５３】
このストリームエントリー内に、再生すべきESのパケット識別子が記述される。ストリームエントリー内に、再生すべきESのパケット識別子を記述することができるので、ストリーム登録におけるストリーム番号を再生装置のストリーム番号レジスタに格納し、ストリーム登録におけるストリームエントリー内のパケット識別子に基づいて再生装置のPIDフィルタにパケットフィルタリングを再生装置に実行させる。こうすることで、基本ストリーム選択テーブルにおいて再生が許可されたESのTSパケットがデコーダに出力され、ESの再生がなされることになる。
【０１５４】
基本ストリーム選択テーブルにおけるこれらのストリーム登録は、ストリーム番号の順序に従って並べられており、ストリーム番号の順序に基づくストリーム登録の順位は、“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”の条件を満たすストリームが複数存在する場合、ストリーム登録列におけるストリーム番号の順位によって、選択対象となるストリームが決定される。
【０１５５】
こうすることで、基本ストリーム選択テーブルにおけるストリーム登録の中に、再生装置が再生できないものが存在する場合、かかるストリームは再生から除外されることになり、また、“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”との条件を満たすストリームが複数存在する場合は、それらのうちどれを優先的に選択すべきかという指針をオーサリング者は再生装置に伝えることができる。
【０１５６】
“再生装置が再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”の条件を満たすストリームが存在するかどうかという判定や、“再生することができる”、“ストリームの言語属性が再生装置の言語設定と一致する”との条件を満たすストリームのうちどれを選択するかという選択手順は、ストリーム選択プロシージャと呼ばれる。ストリーム選択プロシージャは、カレントプレイアイテムが新しいものに切り替った際、また、ユーザからストリーム切り替えが要求された際、実行される。
【０１５７】
カレントプレイアイテムが新しいものに切り替わる等、再生装置の状態変化が生じた際、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を“状態変化時に実行すべきプロシージャ”という。ストリーム番号レジスタは、ストリーム種別毎に存在するから、上記プロシージャは、ストリーム種別ごとに実行されることになる。
【０１５８】
ストリーム切り替え要求がユーザによってなされた場合、上述したような判定や選択を行い、再生装置のストリーム番号レジスタにストリーム番号を設定する一連の手順を“ストリーム変化が要求された際のプロシージャ”という。
【０１５９】
BD-ROMが装填された際、ストリーム番号レジスタをストリーム登録列における初期値に設定しておくとの手順を、“初期化”という。
基本ストリーム選択テーブルにおけるストリーム登録列は、サブプレイアイテム情報によって指定されているストリームと、プレイアイテム情報によって指定されているストリームとに一律に優先順序を付与しているので、ビデオストリームとは多重化されていないストリームであっても、サブプレイアイテム情報によって指定されていれば、ビデオストリームと同期再生すべきストリームの選択にあたっての選択の対象となる。
【０１６０】
そして、サブプレイアイテム情報にて指定されたストリームを再生装置が再生することができ、尚且つ、サブプレイアイテム情報にて指定されたストリームの優先順序がビデオストリームと多重化されたグラフィクスストリームの優先順序よりも高い場合は、ビデオストリームと多重化されたストリームの代わりに、サブプレイアイテム情報にて指定されたストリームを再生に供することができる。
図１９は、基本ストリーム選択テーブルの一例を示す。同図（ａ）は、ストリーム種別に、プライマリビデオストリーム、セカンダリビデオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリームといった種別が存在する場合に、基本ストリーム選択テーブルに設けられる複数のストリーム登録列を示す。同図（ｂ）は、基本ストリーム選択テーブルにより、メインTS,サブTSから、どのようなESが分離されるかを示す。同図左側は、メインTS、サブTSを示し、真ん中は、基本ストリーム選択テーブルと、多重分離部とを示す。右側は、基本ストリーム選択テーブルに基づき分離されるプライマリビデオストリーム、プライマリオーディオストリーム、PGストリーム、IGストリーム、セカンダリビデオストリーム、セカンダリオーディオストリームを示す。
【０１６１】
続いて、エクステンションデータの詳細について説明する。
プレイリストがピクチャインピクチャアプリケーションを構成する場合、ピクチャインピクチャメタデータは、プレイリストファイルにおけるエクステンションデータのデータブロックに格納されねばならない。MVCビデオストリームをプレイリスト情報が参照する場合、拡張ストリーム選択テーブルは、プレイリスト情報ファイルのエクステンションデータにおけるデータブロックに格納されねばならない。
【０１６２】
ディスク上のMVCビデオストリームや立体視IGストリーム再生メニューにおけるMVCビデオストリームをプレイリスト情報が参照する場合、サブパス情報の拡張情報（サブパスブロックエクステンション）は、プレイリスト情報ファイルにおけるエクステンションデータのデータブロックに格納されねねばならない。
【０１６３】
プレイリスト情報におけるエクステンションデータのその他の目的は、保留されている。
2D再生装置は、プレイリストファイルにおけるエクステンションデータに遭遇した際、未知のエクステンションデータを無視せねばならない。
【０１６４】
＜拡張ストリーム選択テーブル(STreamNumber＿table＿StereoScopic(SS))＞
前記拡張ストリーム選択テーブルは、立体視再生モードにおいてのみ、ストリーム選択テーブルと共に使用されるストリーム選択テーブルであり、プレイアイテムの再生や、これに関連するサブパスが再生されている際、選択することができるESを定義する。
【０１６５】
前記拡張ストリーム選択テーブルは、立体視再生モードにおいてのみ再生を許可すべきESを示し、ストリーム登録列を含む。ストリーム登録列における個々のストリーム登録情報は、ストリーム番号と、そのストリーム番号に対応するストリームエントリーと、ストリーム属性とを含む。拡張ストリーム選択テーブルは、立体視再生モード固有の拡張を意味するので、各プレイアイテム情報に拡張ストリーム選択テーブル(STN＿table＿SS)が関連付けられているプレイリストを“3Dプレイリスト”という。
【０１６６】
拡張ストリーム選択テーブルにおけるストリームエントリーは、再生装置が立体視再生モードに設定されている場合において、対応するストリーム番号が再生装置におけるストリーム番号レジスタに設定された際、再生装置が多重分離に用いるべきパケット識別子を示す。ここで、基本ストリーム選択テーブルとの違いは、拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象にならない点である。つまり、基本ストリーム選択テーブルにおけるストリーム登録列におけるストリーム登録情報は、個々のESの優先順序と解釈され、何れかのストリーム登録情報内のストリーム番号が、ストリーム番号レジスタに書き込まれる。しかし拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択プロシージャの対象とはならず、拡張ストリーム選択テーブルにおけるストリーム登録情報は、何れかのストリーム番号がストリーム番号レジスタに格納された際、そのストリーム番号に対応するストリームエントリー及びストリーム属性を取り出すという目的のみに用いられる。
【０１６７】
2D再生モードから3D再生モードへと再生モードが切り替った際、対象となるストリーム選択テーブルが、基本ストリーム選択テーブルから拡張ストリーム選択テーブルに切り替ったために、ストリーム選択プロシージャを実行したとなると、ストリーム番号の同一性を維持することができず、強いては、言語属性の同一性も失われる可能性がある。
【０１６８】
2D再生モードから3D再生モードへの切り替え時に、言語属性を始めとするストリーム属性の同一性を維持するため、拡張ストリーム選択テーブルの用途を、上記のものにも留めている。
【０１６９】
前記拡張ストリーム選択テーブルは、ディペンデントビュービデオストリームのストリーム登録列、PGストリームのストリーム登録列、IGストリームのストリーム登録列から構成される。
【０１７０】
拡張ストリーム選択テーブルにおけるストリーム登録列は、ストリーム選択テーブルにおける同じストリーム種別のストリーム登録列に結合される。この結合は、ストリーム選択テーブルにおけるプライマリビデオストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるディペンデントビュービデオストリームのストリーム登録列を結合し、ストリーム選択テーブルにおけるPGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録列を結合し、IGストリームのストリーム登録列に、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録列を結合することでなされる。
【０１７１】
上記の結合がなされれば、結合後のストリーム選択テーブルのうち、基本ストリーム選択テーブルにおけるストリーム登録列に対して上記プロシージャが実行される。
図２０は、拡張ストリーム選択テーブルの内部構成を示す。拡張ストリーム選択テーブルは、拡張ストリーム選択テーブルの全体長(length)、ポップアップ期間固定オフセット(Fixed＿offset＿during＿Popup)、各プレイアイテムにおけるそれぞれのストリーム種別に対応するストリーム登録列から構成される。
【０１７２】
ここでプレイアイテム＃1〜＃NというN個のプレイアイテムが存在する場合、プレイアイテム＃1〜＃Nのそれぞれに対応するストリーム登録列が、拡張ストリーム選択テーブルに設けられる。各プレイアイテムに対応するストリーム登録列は、ディペンデントビューストリーム登録列、PGストリーム登録列、IGストリーム登録列である。
【０１７３】
『Fixed＿offset＿during＿Popup』は、ポップアップ期間固定オフセットであり、IGストリームによるポップアップメニューがオンに設定されている場合、ビデオやPG＿テキスト字幕ストリームの再生タイプを制御する。この『Fixed＿offset＿during＿Popup』フィールドは、IGストリームにおけるuser＿interface＿modelフィールドがオン、つまり、ポップアップメニューのユーザインターフェイスがオンに設定されている場合、オンに設定される。IGストリームにおけるuser＿interface＿modelフィールドがオフ、つまり、AlwaysONのユーザインターフェイスに設定されている場合、オフに設定される。
【０１７４】
ポップアップ期間固定オフセット”=0”、つまり、IGストリームのユーザインターフェイスにおいてポップアップメニューがオフに設定されている場合、ビデオストリームはB−Dプレゼンテーションモードとなる。立体視PGストリームは、立体視再生タイプになる。1plane＋Offsetモードの再生時において、PG＿テキスト字幕ストリームは、1plane＋Offsetモードになる。
【０１７５】
ポップアップ期間固定オフセット“１”、つまり、IGストリームのポップアップメニューがオンである場合、ビデオストリームはB−Bプレゼンテーションモードとなる。立体視PGストリームは、1plane＋Offsetモードになり、1plane＋Offset用のPGストリームは、1plane＋Zerooffset再生タイプとして再生される。
【０１７６】
1plane＋OffsetモードにおいてPG＿テキスト字幕ストリームは、1plane＋Zero offsetになる。
『オフセットシーケンス本数情報(図中のnumber＿of＿offset＿sequence)』は、ディペンデントビューストリームにおけるオフセットシーケンスの個数を示す。
【０１７７】
拡張ストリーム選択テーブルにおけるこの値は、ディペンデントビューストリームに含まれるオフセットシーケンスの個数と同じになる。
図２１は、拡張ストリーム選択テーブルにおけるストリーム登録列を示す。
【０１７８】
図２１（ａ）は、ディペンデントビュービデオストリームのストリーム登録列の内部構成を示す。ディペンデントビューストリームのストリーム登録列は、v(x)個のSS＿dependet＿view＿blockから構成される。ここで、v(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているプライマリビデオストリームの本数である。図中の引き出し線は、ディペンデントビューストリームのストリーム登録列の内部構成をクローズアップして示している。引出線に示すように、SS＿dependet＿view＿blockは、ストリーム番号と、ストリームエントリーと、ストリーム属性と、number＿of＿offset＿sequenceとから構成される。
【０１７９】
ストリームエントリーは、ディペンデントビュービデオストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビュービデオストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビュービデオストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
【０１８０】
『ストリーム属性』は、ディペンデントビュービデオストリームの言語属性を含む。
『number＿of＿offset＿sequence』は、ディペンデントビュービデオストリーム内に存在するオフセットの本数を示す。
【０１８１】
図２１（ａ）においてディペンデントビュービデオストリームのストリーム登録列は、データ構造上、複数のディペンデントビュービデオストリームについてのストリーム登録情報を設けるものになっている。通常、ベースビュービデオストリームの本数は1つであるから、ディペンデントビュービデオストリームにおけるストリーム登録情報の個数も唯一つになる。
【０１８２】
図２１（ｂ）は、PGストリームのストリーム登録列の内部構成を示す。PGストリームのストリーム登録列は、P(x)個のストリーム登録情報から構成される。ここで、P(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているPGストリームの本数である。
【０１８３】
図中の引き出し線は、ストリーム登録列の共通の内部構成をクローズアップして示している。
『PGtextST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリームオフセットシーケンスレファレンス情報であり、1plane＋OffsetモードのPG＿テキスト字幕ストリームについてのオフセットシーケンスを指示する。
【０１８４】
オフセットメタデータは、ディペンデントビュービデオストリームのアクセスユニットによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋Offsetモードタイプのプレゼンテーショングラフィクス(PG)プレーンに適用せねばならない。
【０１８５】
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。
『is＿SS＿PG』は、PGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する立体視プレゼンテーショングラフィクス存否フラグである。立体視PGストリームにおける構造が存在しない場合、このフィールドは0に設定されねばならない。立体視PGストリームにおける構造が存在する場合、このフィールドは1に設定されねばならない。
【０１８６】
『stream＿entry＿for＿base＿view』は、ベースビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるベースビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
【０１８７】
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューPGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューPGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビューPGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報におけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューPGストリームを格納しているストリームファイルを改めて読み出さねばならない。
【０１８８】
『stream＿attribute』は、ベースビューPGストリーム及びディペンデントPGストリームの言語属性を含む。
『SS＿PG＿textST＿offset＿sequence＿id＿ref』は、PG＿テキスト字幕ストリーム用のオフセットシーケンスを参照するためのレファレンス情報であり、PG＿テキスト字幕ストリームのためのオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットをPGプレーンに適用せねばならない。
【０１８９】
このフィールドが不定値(FF)である場合、再生装置はPGストリームプレーンメモリに、このオフセットを適用しない。
図２１（ｃ）は、IGストリームのストリーム登録列の内部構成を示す。IGストリームのストリーム登録列は、I(x)個のストリーム登録情報から構成される。ここで、I(x)とは、プレイアイテム情報＃xの基本ストリーム選択テーブルにおいて、再生が許可されているIGストリームの本数である。図中の引き出し線は、ストリーム登録列の共通の内部構成をクローズアップして示している。
【０１９０】
『IG＿offset＿sequence＿id＿ref』は、インタラクティブグラフィクスオフセットシーケンスレファレンスであり、1plane＋OffsetモードのIGストリームのシーケンスIDのレファレンスである。この値は、オフセットシーケンスに定義されているオフセットシーケンスIDを指示する。上述したように、オフセットメタデータは、ディペンデントビュービデオストリームによって供給される。再生装置は、このフィールドによって提供されたオフセットを1plane＋OffsetモードタイプのIGストリームに適用せねばならない。
【０１９１】
このフィールドが不定値(FF)である場合、再生装置はインタラクティブグラフィクススプレーンに、このオフセットを適用しない。
『IG＿Plane＿offset＿direction＿during＿BB＿video』は、B−Bプレゼンテーションモードにおいてポップアップメニューのユーザインターフェイスで、IGストリームが再生されている間、1plane＋Offsetモードにおけるインタラクティブグラフィクス(IG)プレーンにおけるオフセット方向を指示する。
【０１９２】
値“０”でフロント設定、つまり、プレーンメモリは、TVと視聴者との間に存在し、レフトビュー期間においてプレーンは右方向に、ライトビュー期間においてプレーンは左方向にシフトされる。
【０１９３】
値＝１でビハインド設定、つまり、プレーンメモリは、TV又はスクリーンの背後に存在し、レフトプレーンは左方向に、ライトプレーンは右方向にシフトされる。
『IG＿Plane＿offset＿value＿during＿BB＿video』は、B−BプレゼンテーションモードでポップアップメニューのユーザインターフェイスによってIGストリームが再生されている間、1plane＋OffsetモードにおけるIGプレーンのオフセット値を画素単位で指示する。
【０１９４】
『is＿SS＿IG』は、立体視インタラクティブグラフィクス存否フラグであり、IGストリームにおけるベースビューIGのストリームエントリー、ディペンデントビューIGのストリームエントリー、ストリーム属性の有効性と、存在とを指示する。立体視IGストリームのデータ構造が存在しない場合、このフィールドは値0に設定されねばならない。再生が許可されているIGストリームが立体視IGストリームである場合、このフィールドは、値1に設定されねばならない。
【０１９５】
『stream＿entry＿for＿base＿view』は、ベースビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ベースビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるベースビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。
【０１９６】
『stream＿entry＿for＿depentdent＿view』は、ディペンデントビューIGストリームの再生パスが帰属しているサブパスを指定するサブパス識別子レファレンス(ref＿to＿Subpath＿id)と、ディペンデントビューIGストリームが格納されているストリームファイルを指定するストリームファイルレファレンス(ref＿to＿subClip＿entry＿id)と、当該ストリームファイルにおけるディペンデントビューIGストリームのパケット識別子(ref＿to＿stream＿PID＿subclip)とを含む。拡張ストリーム選択テーブルのストリーム登録情報におけるstream＿entry＿for＿depentdent＿viewによって参照されているストリームファイルが、基本ストリーム選択テーブルのストリームエントリーによって参照されているストリームファイルとは異なる場合、ディペンデントビューIGストリームを格納しているストリームファイルを改めて読み出さねばならない。
【０１９７】
『stream＿attribute』は、ベースビューIGストリーム及びディペンデントIGストリームの言語属性を含む。
『SS＿IG＿offset＿sequence＿id＿ref』は、立体視タイプのIGストリームのためのオフセットシーケンスIDのレファレンスであり、ディペンデントビュービデオストリームのオフセットメタデータにおけるオフセットシーケンスを指示する。再生装置は、このフィールドによって提供されたオフセットを立体視タイプのIGプレーンに適用せねばならない。
【０１９８】
このフィールドが不定値(FF)である場合、再生装置はIGプレーンに、このオフセットを適用しない。
PG＿テキスト字幕ストリーム用のオフセットシーケンスのレファレンス情報及びIGストリーム用のオフセットシーケンスのレファレンス情報は、ストリーム番号に対応付けて、ストリーム登録情報に記載されているため、装置状態の変化時やストリーム変更要求の発生時にストリーム選択プロシージャが実行され、装置側の言語設定に応じたストリーム番号がストリーム番号レジスタに設定された場合、その新たなストリーム番号に対応したレファレンスによって指示されるオフセットシーケンスが、ビデオデコーダからシフト部に供給されることになる。こうすることで、再生装置における言語設定に応じた、最適なオフセットシーケンスがシフト部に供給されるので、1plane＋Offsetモードにおけるグラフィクスの奥行きを、再生装置の言語設定に応じた最適なものにすることができる。
【０１９９】
拡張ストリーム選択テーブルにおける制限について説明する。
立体視ディペンデントビューブロックにおけるストリームエントリーは、プレイリストにおいて変化してはならない。
【０２００】
立体視ディペンデントビューブロックにおけるストリームエントリーのタイプがサブパスによって使用されるESタイプ（ストリームタイプ＝２）であれば、サブパスIDレファレンスと、サブクリップエントリーIDレファレンス(ref＿to＿subclip＿entry＿id)とはプレイリストにおいて変化しない。
【０２０１】
ストリームエントリー、ベースビューのためのストリームエントリー、ディペンデントビューのためのストリームエントリーのタイプとして許されるESのタイプは、プレイアイテムによって使用されるAVクリップ内のES  (ストリームタイプ＝１)、サブパスによって使用されるAVクリップ内のES(ストリームタイプ＝２)の2つタイプのみである。
【０２０２】
立体視ディペンデントビューブロックにおけるストリーム属性のストリーム符号化方式は、“0x20”に設定される。
図２２は、基本ストリーム選択テーブル、拡張ストリーム選択テーブルによりメインTS、サブTSからどのようなESが多重分離されるかを示す。
【０２０３】
本図の真ん中には、多重分離部を示し、その上側には基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとの組みを示す。左側にはメインTS、サブTS、右側には、多重分離されるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリーム、プライマリオーディオストリームを示す。
【０２０４】
図２３は、図２２のような多重分離がなされる場合、基本ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録列がどのように参照されるかを示す。本図の真ん中に基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを示す。
【０２０５】
基本ストリーム選択テーブルの左側は、再生装置においてカレントストリームのストリーム番号を格納するストリーム番号レジスタを示す。基本ストリーム選択テーブルの右側は、再生装置における言語設定を示す。拡張ストリーム選択テーブルの下側は、多重分離部を示す。矢印ｈ１は、PGストリームの言語設定と、基本ストリーム選択テーブルにおけるPGストリームのストリーム登録情報Ｘにおける言語属性との一致を模式的に示す。矢印ｈ２は、PGストリームのストリーム番号レジスタへの、ストリーム番号Ｘの設定を模式的に示す。
【０２０６】
矢印ｈ３は、IGストリームの言語設定と、基本ストリーム選択テーブルにおけるIGストリームのストリーム登録情報Ｙにおける言語属性との一致を模式的に示す。矢印ｈ４は、IGストリームのストリーム番号レジスタへの、ストリーム番号Ｙの設定を模式的に示す。
【０２０７】
本図のストリーム番号の設定は、基本ストリーム選択テーブルに対するストリーム選択プロシージャの結果に応じて、多重分離に供されるPGストリーム、IGストリームが定まること象徴的に示している。
【０２０８】
矢印PD1は、拡張ストリーム選択テーブル内のSS＿dependent＿view＿blockにおけるストリームエントリーに記述されているパケット識別子の出力を模式的に示す。この出力によって多重分離部における多重分離がなされて、ディペンデントビュービデオストリームが出力される。
【０２０９】
矢印PD2は、拡張ストリーム選択テーブルにおけるPGストリームのストリーム登録情報のストリームエントリーのうち、ストリーム番号Ｘに対応するもののパケット識別子の出力を模式的に示す。矢印Ｘ１は、矢印PD1のパケット識別子出力が、ストリーム番号レジスタに対するカレントストリーム番号Ｘの設定と連動していることを示す。
【０２１０】
矢印PD3は、拡張ストリーム選択テーブルにおけるIGストリームのストリーム登録情報のストリームエントリーのうち、ストリーム番号Ｙに対応するもののパケット識別子の出力を模式的に示す。矢印Ｙ１は、矢印PD3のパケット識別子出力が、ストリーム番号レジスタに対するカレントストリーム番号Ｙの設定と連動していることを示す。
【０２１１】
ここでの連動とは、基本ストリーム選択テーブルにおけるPG,IGストリームのストリーム登録列に記述されたストリーム番号のうち、ストリーム番号Ｘ,Ｙが、カレントのPG,IGストリーム番号としてストリーム番号レジスタに設定されたことに、拡張ストリーム選択テーブルに記載されたパケット識別子の出力が連動していることを意味する。
【０２１２】
この出力によって多重分離部における多重分離がなされて、PG,IGストリームが出力される。
図２４は、モードにおけるストリーム番号の割り当て変化を示す。
【０２１３】
縦欄は、ビデオストリーム＃1というストリーム番号、オーディオストリーム＃1、＃2というストリーム番号、PGストリーム＃1、＃2というストリーム番号を示している。
左側の破線枠にのみ囲まれるESは、2D再生モードにおいてのみ、多重分離の対象になるESである。
【０２１４】
右側の破線枠にのみ囲まれるESは、3D再生モードにおいて多重分離の対象になるESを示す。
左側及び右側の破線枠の双方に囲まれるESは、3D再生モードにおいて多重分離の対象になるESを示す。
【０２１５】
ビデオストリーム＃1のストリーム番号だけに着目すると、2Dビデオストリームは、左右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。この2Dビデオストリームは、レフトビュービデオストリームである。しかし、ライトビュービデオストリームは、右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。
【０２１６】
オーディオストリーム＃1、オーディオストリーム＃2のストリーム番号に着目すると、オーディオストリームは、左右両方の破線枠に囲まれるので、2D再生モード及び3D再生モードの双方で再生対象になっていることがわかる。
【０２１７】
PGストリーム＃1、PGストリーム＃2のストリーム番号に着目すると、2DPGストリームは、左側の破線枠のみに囲まれるので、2D再生モードのみで再生対象になっていることがわかる。ベースビューPGストリーム、ディペンデントビューPGストリームは右側の破線枠のみに囲まれているので、3D再生モードでのみ再生されることがわかる。IGストリームも同様である。
【０２１８】
以上より、3D再生モードにおいてビデオストリームというストリーム種別では、ディペンデントビュービデオストリームが再生対象として加わることがわかる。
また3D再生モードにおいてPGストリームというストリーム種別では、再生対象が、2DPGストリームから、ベースビューPGストリーム及びディペンデントビューPGストリームに置き換わっていることがわかる。
【０２１９】
前記拡張ストリーム選択テーブルは、オブジェクト指向型コンパイラ言語を用いて、図１９のような記述を行い、コンパイルに供することで作成することができる。図２５は、オブジェクト指向型コンパイラ言語を用いて拡張ストリーム選択テーブルを記述するためのシンタックスを示す。
【０２２０】
PlayItem＿idを制御変数とするfor文は、Fixed＿offset＿during＿Popup、ディペンデントビューストリームのストリーム登録列、PG＿テキスト字幕ストリームのストリーム登録列、IGストリームのストリーム登録列の記述を、プレイアイテムの個数だけ繰り返すループを構成する。
【０２２１】
primary＿video＿stream＿idを制御変数とするfor文は、ディペンデントビューストリームのストリーム登録列を定義するものであり、ディペンデントビューストリームのストリーム登録列は、number＿of＿primary＿video＿stream＿entriesだけ、stream＿entry,stream＿attribute,number＿of＿offset＿sequenceからなるSS＿dependent＿view＿blockを記述することで定義される。
【０２２２】
PG＿textST＿stream＿idを制御変数とするfor文は、PG＿テキスト字幕ストリームのストリーム登録列を定義するものであり、number＿of＿PG＿textST＿stream＿number＿entriesだけ、PG＿text＿offset＿sequence＿id＿ref、is＿SS＿PGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿PGを制御変数としたif文は、is＿SS＿PGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿PGが1bdである場合のみ、ストリーム登録列に追加される。is＿SS＿PGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。
【０２２３】
IG＿stream＿idを制御変数とするfor文は、IGストリームのストリーム登録列を定義するものであり、number＿of＿IG＿stream＿entriesだけ、IG＿offset＿sequence＿id＿ref、IG＿plane＿offset＿direction＿during＿BB＿video、IG＿plane＿offset＿value＿during＿BB＿video、is＿SS＿IGの記述を繰り返すループになっている。ループ中に存在する、is＿SS＿IGを制御変数としたif文は、is＿SS＿IGが1bであれば、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeを定義するものであり、かかるif文によって、stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは、is＿SS＿IGが1bdである場合のみ、ストリーム登録列に追加される。is＿SS＿IGが0bであれば,stream＿entry＿for＿base＿biew(),stream＿entry＿for＿dependent＿biew(),stream＿attributeは追加されない。
【０２２４】
以上が記録媒体についての説明である。続いて、再生装置の詳細について説明する。
図２６は、再生装置の内部構成を示す。本図に示すように再生装置は、読出部２０１、メモリ２０２、プレーヤ番号レジスタ２０３、デコーダ２０４、多重分離部２０５、プレーンメモリセット２０６、シフト部２０７、レイヤ合成部２０８、送受信部２０９、再生制御部２１０、出力モードレジスタ２１１、コンフィグレーションメモリ２１２から構成される。本図の内部構成は、課題解決手段を具備した再生装置を実施するための必要最低限の構成要素を記述したに過ぎない。より詳細な内部構成については、後段の実施形態に説明の場を譲る。
【０２２５】
読出部２０１は、記録媒体からインデックステーブル、動作モードオブジェクトのプログラムファイル、プレイリスト情報ファイル、ストリーム情報ファイル、ストリームファイルを読み出す。
【０２２６】
メモリ２０２は、プレイリスト情報に含まれる基本ストリーム選択テーブルと、拡張ストリーム選択テーブルとを結合することで得られた結合ストリーム登録列を格納する。
ストリーム種別毎のプレーヤ番号レジスタ２０３は、ビデオストリームのストリーム番号を格納するビデオストリーム番号レジスタ、PGストリームのストリーム番号を格納するPGストリーム番号レジスタ、IGストリームのストリーム番号を格納するIGストリーム番号レジスタ、オーディオストリーム番号を格納するオーディオストリーム番号レジスタを含む。
【０２２７】
ストリーム種別毎のデコーダ２０４は、ビデオデコーダ、PGデコーダ、IGデコーダ、オーディオデコーダから構成される。
多重分離部２０５は、パケットフィルタリングを実行するPIDフィルタを備え、記録媒体から読み出された複数のソースパケット内のTSパケットのうち、結合ストリーム登録列に記載されたパケット識別子によって指示されているものを分離して、各デコーダに出力する。
【０２２８】
プレーンメモリセット２０６は、複数のプレーンメモリから構成される。
これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。
【０２２９】
シフト部２０７は、画素の座標のシフトを実行する。
レイヤ合成部２０８は、複数のプレーンメモリにおけるレイヤ合成を行う。
送受信部２０９は、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、相互認証フェーズと、ネゴシエーションフェーズを経て、データ伝送フェーズに移行し、データ伝送を行う。
【０２３０】
このネゴシエーションフェーズは、相手側機器のケーパビリティ(デコード能力、再生能力、表示周波数を含む)を把握して、プレーヤ設定レジスタに設定しておき、以降の伝送のための伝送方式を定めるものである。これらの相互認証フェーズ、ネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮・平文形式の画素データを、表示装置における水平同期期間に従い表示装置に高い転送レートで転送する。一方、表示装置における水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置(表示装置のみならずアンプ、スピーカを含む)に、非圧縮・平文形式のオーディオデータを転送する。こうすることで、表示装置、アンプ、スピーカといった機器は、非圧縮・平文形式のピクチャデータ、非圧縮・平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮・暗号化形式のまま伝送することができる。
【０２３１】
再生制御部２１０は、読出部２０１を制御して、記録媒体からのインデックステーブル、動作モードオブジェクト、プレイリスト情報、クリップ情報、ストリームファイルを記録媒体から読み出すとともに、記録媒体から読み出されたプレイリスト情報、クリップ情報に基づく再生制御を実行する。ストリームファイルの読み出しにあたっては、時間軸の任意の時点に相当するソースパケットを、ストリームファイルから読み出すというランダムアクセスを実現することができる。
【０２３２】
出力モードレジスタ２１１は、再生モードを記憶している。
コンフィグレーションメモリ２１２は、各プレーンメモリのモードケーパビリティと、カレントモードとを記憶する不揮発性メモリであり、再生装置の製造主体によって、その記憶内容が設定される。モードケーパビリティとは、ビデオプレーン、PGプレーン、IGプレーンといった複数のプレーンメモリのそれぞれが、上述したような再生モードのそれぞれを処理することができるか否かを示す。再生モードを処理できるかどうかは、プレーンメモリに対応するストリーム種別が何であるか、また、その再生モードを処理するためのハードウェア構成が再生装置に存在するか否かによって決まる。
【０２３３】
カレントモードは、複数のプレーンメモリのそれぞれが、複数の再生モードのうち、どれに設定されているかを示す。
以上が再生装置についての説明である。続いて、本実施形態に係る再生装置による多重分離処理の詳細について説明する。
【０２３４】
図２７は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
同図（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ストリーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。基本ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、英語、日本語、中国語の言語属性を有している。
【０２３５】
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、英語、日本語、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
【０２３６】
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
【０２３７】
図中のa1、a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号レジスタへのストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
【０２３８】
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、基本ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
【０２３９】
同図（ｃ）は、言語設定が中国語であり、出力モードがB−Dプレゼンテーションモードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
【０２４０】
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号レジスタに対するストリーム番号の設定、多重分離部へのパケット識別子の出力を模式的に示したものである。
【０２４１】
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝３のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号＝３のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。
【０２４２】
図２８は、結合ストリーム登録列によってどのようなパケット識別子が多重分離部に出力されるかを示す。
（ａ）は、動作例の題材として用いる結合ストリーム登録列を示す。結合ストリーム登録列は、基本ストリーム選択テーブルにおける3つのストリーム登録情報と、拡張ストリーム選択テーブルにおける3つのストリーム登録情報とから構成されるものである。基本ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性は、何れかも中国語の言語属性を有している。
【０２４３】
拡張ストリーム選択テーブルにおける3つのストリーム登録情報はそれぞれ、ストリーム番号“１”、“２”、“３”のストリーム番号を有し、3つのストリーム登録情報におけるストリーム属性も、中国語の言語属性を有している。基本ストリーム選択テーブルにおけるストリーム登録情報と、拡張ストリーム選択テーブルにおけるストリーム登録情報とではストリームエントリーにおけるパケット識別子が異なり、拡張ストリーム選択テーブルにおけるストリーム登録情報は、B−DプレゼンテーションモードのためのベースビューPGストリームのためのパケット識別子、ディペンデントビューPGストリームのためのパケット識別子を含む。
【０２４４】
同図（ｂ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
【０２４５】
図中のa1,a2,a3を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号＝３のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号＝“１”がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、基本ストリーム選択テーブルにおけるストリーム番号“１”のストリーム登録情報におけるストリームエントリーのパケット識別子によって特定されるTSパケットが、デコーダに出力されることになる。
【０２４６】
同図（ｃ）は、言語設定が中国語であり、出力モードが2D再生モードに設定された再生装置に、かかる結合ストリーム登録列が供給された場合における、ストリーム番号の設定と、パケット識別子の出力とを示す。
【０２４７】
図中のa4,a5,a6を付した矢印は、言語設定の一致判定、ストリーム番号の設定、パケット識別子の出力を模式的に示したものである。
プロシージャにおいて、ストリーム番号“１”のストリーム登録情報において、再生装置側の言語設定と、ストリーム属性との一致が判定され、このストリーム番号“１”のストリーム登録情報に含まれるストリーム番号がストリーム番号レジスタに書き込まれる。この際、基本ストリーム選択テーブルにおけるストリームエントリーにおけるパケット識別子が多重分離部に出力される。こうすることで、拡張ストリーム選択テーブルにおけるストリーム番号“１”のストリーム登録情報におけるストリームエントリーに格納されたパケット識別子の組みによって特定される２系統のTSパケットが、デコーダに出力されることになる。
【０２４８】
図２９は、再生装置がB−Dプレゼンテーションモードに設定されており、B−Dケーパビリティが存在する場合におけるパケット識別子の参照及びパケット出力を示す。
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のディペンデントビューストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、拡張ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
【０２４９】
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、ディペンデントビュービデオストリームを構成するTSパケット、ベースビューPGストリームを構成するTSパケット、ディペンデントビューPGストリームを構成するTSパケット、ベースビューIGストリームを構成するTSパケット、ディペンデントビューIGストリームを構成するTSパケットがデコーダに出力されることがわかる。
【０２５０】
図３０は、再生装置が1plane＋Offsetモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、シフト部との間の矢印は、拡張ストリーム選択テーブルにおけるPGストリームに対応するストリーム登録列におけるオフセットレファレンス、及び、拡張ストリーム選択テーブルにおけるIGストリームに対応するストリーム登録列におけるオフセットレファレンスが1plane＋Offsetモードにおいて参照されていることを示す。
【０２５１】
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
【０２５２】
ビデオデコーダと、シフト部との矢印は、上述したようなオフセットレファレンスに基づき、ディペンデントビュービデオストリームにおけるオフセットがPGストリームについてのシフト部、IGストリームについてのシフト部に供給されていることを示す。
【０２５３】
図３１は、再生装置が2Dプレゼンテーションモードに設定されている場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
【０２５４】
多重分離部と、複数のデコーダとの間の矢印は、ストリームファイルに存在する複数のソースパケットのうち、どのTSパケットが各デコーダに出力されているかを示す。この矢印のように、多重分離部からデコーダへと、ベースビュービデオストリームを構成するTSパケット、PGストリームを構成するTSパケット、IGストリームを構成するTSパケット、オーディオストリームを構成するTSパケットがデコーダに出力されることがわかる。
【０２５５】
図３２は、再生装置にB−Dプレゼンテーションモードのケーパビリティが存在しない場合におけるパケット識別子の参照及びパケット出力を示す
結合ストリーム登録列と、多重分離部との間の矢印は、結合ストリーム登録列における複数のストリーム登録列のうち、どれのストリームエントリー内のパケット識別子が参照されているかを示す。本図では、基本ストリーム選択テーブル内のベースビュービデオストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のPG＿テキスト字幕ストリーム登録列におけるストリームエントリー内のパケット識別子、基本ストリーム選択テーブル内のIGストリーム登録列におけるストリームエントリー内のパケット識別子が多重分離部によって参照されていることがわかる。
【０２５６】
多重分離部と、複数のデコーダとの間の矢印は、インターリーブドストリームファイルに存在する複数のソースパケットのうち、基本ストリーム選択テーブルのストリーム登録列におけるストリームエントリーによって指示されているTSパケットが各デコーダに出力されているかを示す。
【０２５７】
以上の再生制御は、図３３から図３５までのフローチャートに示される処理手順をオブジェクト指向型コンパイラ言語で記述してコンピュータに実行させることで実現することができる。
【０２５８】
図３３は、プレイリスト再生手順を示す。本フローチャートは、ステップＳ１においてカレントプレイアイテム番号を１に設定した後、ステップＳ２〜ステップＳ６の処理を繰り返すループを構成する。このループでは、ストリーム選択プロシージャによりストリーム番号を決定して(ステップＳ２)、ストリーム番号に対応するESを格納したストリームファイルをオープンしてソースパケット列を読み出し(ステップＳ３)、読み出されたソースパケット列のうち、ストリーム番号に対応しているものの多重分離を指示し(ステップＳ４)、読み出されたソースパケットをプレイアイテムのインタイムからアウトタイムまで、サブプレイアイテムのインタイムからアウトタイムまで再生するようデコーダに命じる(ステップＳ５)という処理を、カレントプレイアイテム番号が最終番号になるまで繰り返すものである。ここで最終番号でなければ(ステップＳ６でNo)、カレントプレイアイテム番号がインクリメントされて、ステップＳ２に移行する。最終番号であれば、処理を終了する(ステップＳ６でYes)。
【０２５９】
図３４は、ストリーム選択プロシージャの処理手順を示す。
本フローチャートでは、カレントプレイアイテム情報内の基本ストリーム選択テーブルをカレント基本ストリーム選択テーブルに設定する(ステップＳ７)。そして、ステップＳ８〜ステップＳ１７のループを実行する。ステップＳ８〜ステップＳ１７は、IGストリーム、セカンダリビデオストリーム、プライマリオーディオストリーム、セカンダリオーディオストリームのそれぞれについて、ステップＳ１０〜ステップＳ１７の処理を繰り返すものである。ステップＳ１０は、カレント基本ストリーム選択テーブルにおける、ストリームｘに対応する基本ストリーム選択テーブルエントリー数が0であるか否かの判定であり、ステップＳ１１は、カレントストリームにおけるストリームｘに対応するストリームエントリー数が、ストリーム番号レジスタに格納されているストリーム番号以上であるかを判定する判定ステップである。
【０２６０】
ステップＳ１０、ステップＳ１１の何れかがYesであれば、ステップＳ１７においてストリーム番号レジスタに格納されているストリーム番号を維持する。
ステップＳ１０、ステップＳ１１の何れもがNoであれば、カレント基本ストリーム選択テーブルに登録されているPESストリームが、複数の条件のうち、どれを満たすかを判定して(ステップＳ１２)、満たすと判定された条件の組合せが同一となるPESストリームが複数存在するか否かを判定する(ステップＳ１３)。
【０２６１】
条件を満たすPESストリームが唯一つである場合、条件を満たす1つのPESストリームを選択する(ステップＳ１４)。
条件を満たすPESストリームが複数存在する場合、同じ条件を満たすと判定されたPESストリームのうち、カレント基本ストリーム選択テーブルにおける優先順位が最も高いものを選択する(ステップＳ１５)。こうしてPESストリームを選択すれば、選択したPESストリームのストリームエントリーに対応するストリーム番号を、PSRにおけるストリーム番号レジスタに書き込む(ステップＳ１６)。
【０２６２】
以上の過程を経て、カレントプレイアイテムにおいて再生すべきPESストリームが確定すれば、カレントプレイアイテムの再生を開始する必要があるが、カレントプレイアイテム再生の処理手順は、Procedurewhen playback condition is changedによって確定した出力モードに応じたものとなる。
【０２６３】
図３５は、ストリーム番号に対応するパケット識別子の出力処理の手順を示す。ステップＳ１７、ステップＳ１８の判定ステップを実行する構造になっている。ステップＳ１７は、カレントの出力モードが2D再生モードであるか否かの判定であり、もし2D再生モードであれば、ステップＳ３８において、基本ストリーム選択テーブルにおけるストリーム登録列のうち、カレントストリーム番号に対応するストリーム登録情報のストリームエントリーに基づく多重分離を多重分離部に指示する。
【０２６４】
ステップＳ１８は、拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであるか否かの判定である。ステップＳ１７がNo、ステップＳ１８がNoであれば、ステップＳ１９〜ステップＳ３０を実行する。
【０２６５】
ステップＳ１７〜ステップＳ３０は、ビデオストリームを立体視B−Dタイプに設定してビデオプレーンをB−Dプレゼンテーションモードに設定し(ステップＳ１９)、SS＿dependent＿View＿blockにおけるストリームエントリーのパケット識別子に基づく多重分離を指示して(ステップＳ２０)、ステップＳ２１〜ステップＳ２６の処理を実行する。
【０２６６】
ステップＳ２１は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ２２において、PGストリームを立体視再生タイプに設定して、PGプレーンをB−Dプレゼンテーションモードにし(ステップＳ２３)、カレントPGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示する。
【０２６７】
is＿ss＿PGがオフであれば、PGストリームを1plane＋Offset再生タイプに設定して、PGプレーンを、1plane＋Offsetモードに設定し(ステップＳ２４)、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ２５)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ２６)。
【０２６８】
ステップＳ２７は、カレントIGストリームのストリーム登録情報におけるis＿ss＿IGがオンであるか否かの判定であり、オンであれば、ステップＳ２８において、カレントIGストリームに対応するストリーム登録情報のStream＿entry＿bese＿view,Stream＿entry＿dependent＿viewのパケット識別子に基づく多重分離を指示する。
【０２６９】
is＿ss＿IGがオフであれば、カレントIGストリームのストリーム登録情報におけるSS＿IG＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ２９)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３０)。
【０２７０】
拡張ストリーム選択テーブルのFixed＿offset＿during＿Popupがオンであれば、ステップＳ１７がNo、ステップＳ１８がYesになって、ステップＳ３１〜ステップＳ３７を実行する。
【０２７１】
ステップＳ３１〜ステップＳ３７は、ビデオストリームを立体視B−Bタイプに設定して、ビデオプレーンをB−Bプレゼンテーションモードに設定し(ステップＳ３１)、ステップＳ３２〜ステップＳ３７の処理を実行する。
【０２７２】
ステップＳ３２は、カレントPGストリームのストリーム登録情報におけるis＿ss＿PGがオンであるか否かの判定であり、オンであれば、ステップＳ３３において、PGストリームを1plane＋Offsetモードタイプに設定して、PGプレーンを1plane＋Offsetモードに設定し、カレントPGストリームのストリーム登録情報におけるSS＿PG＿textST＿offset＿sequence＿id＿refで指示されるオフセットシーケンスをディペンデントビュービデオストリームから取得し(ステップＳ３４)、取得したオフセットシーケンスに基づきプレーンシフトを実行する(ステップＳ３５)。その後、ステップＳ３７に移行する。
【０２７３】
is＿ss＿PGがオフであれば、ステップＳ３６においてPGストリームを1plane＋Zero Offsetモードタイプに設定して、PGプレーンを1plane＋ZeroOffsetモードに設定する。その後、ステップＳ３７に移行する
ステップＳ３７では、カレントIGストリームのストリーム登録列におけるIG＿Plane＿offset＿direction＿during＿BB＿videoによって示される方向に対して、ストリーム登録列におけるIG＿Plane＿offset＿value＿during＿BB＿videoによって示される量だけ、プレーンシフトを実行する。以上の処理により、Fixed＿offset＿during＿Popupがオンの設定時には、平面的な動画像に、立体的な字幕やメニューが合成された立体視映像を再生に供することができる。
【０２７４】
図３６は、PGプレーンシフトの処理手順を示すフローチャートである。
ステップS６０は、PGであるか、テキスト字幕であるかの判定である。PGストリームであれば、ステップS６１〜ステップS７４のループに移行する。この二重ループは、変数i、jを0で初期化して(ステップS６１)、カレントストリームのPG＿textST＿offset＿sequence＿id＿refで指示されるoffset＿sequence＿idを有するオフセットシーケンスのうち、GOP(i)のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]をビデオデコーダから取得し(ステップS６２)、GOP(i)のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]を用いてプレーンシフトを実行するという処理を繰り返すものである。この変数iを用いたループの終了条件は、ステップS６９において変数iがnumber＿of＿offset＿sequenceになったと判定されることであり、この条件が満たされるまで、ステップS７０変数iがインクリメントされて、ステップS６２に戻るとの処理が繰り返される。
【０２７５】
ステップS６３〜ステップS６８のループは、GOPのフレームにおけるベースビューの水平表示期間が開始されるのを待ち(ステップS６３)、開始されれば、ステップS６４においてフレーム(ｊ)のピクチャデータにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]の画素数だけシフトして、その後、GOPのフレームにおけるディペンデントビューの水平表示期間が開始されるのを待ち(ステップS６５)、開始されれば、フレーム(ｊ)のピクチャデータにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは反対の方向に、Plane＿offset＿value[j]の画素数だけシフトするという処理を繰り返すものである。この変数ｊを用いたループの終了条件は、ステップS６７において変数ｊがnumber＿of＿displayed＿frame＿in＿GOPになったと判定されることであり、この条件が満たされるまで、ステップS７８において変数ｊがインクリメントされて、ステップS６３に戻るとの処理が繰り返される。
【０２７６】
図３７は、テキスト字幕ストリームが再生対象である場合のPGプレーンシフトの処理手順を示すフローチャートである。本図の処理構造は、図のものと基本的に同一だが、ステップS６４がステップS７１、ステップS７２に、ステップS６５がステップS７３に置き換えられている。
【０２７７】
ステップS７１は、フレームに用いるべきオフセットのPGプレーンにおける描画領域毎の補間値を取得する。ステップS７２は、PGプレーンにおける各描画領域の画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]＋補間値の画素数だけシフトさせる。
【０２７８】
ステップS７３は、PGプレーンにおける各描画領域の画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは逆の方向に、Plane＿offset＿value[j]＋補間値の画素数だけシフトさせる。
【０２７９】
図３８は、IGプレーンのプレーンシフトを示すフローチャートである。本図の処理構造は、図３６のものと基本的に同一だが、ステップS６０がステップS７４に置き換えられ、ステップS６２がステップS７５に置き換えられ、ステップS６４がステップS７６に置き換えられ、ステップS６６がステップS７７に置き換えられている点が異なる。
【０２８０】
ステップS７４は、STN＿table＿SSのFixed＿offset＿during＿Popupがオンかどうかの判定であり、NoであればステップS６１に、YesであればステップS７８に移行する。
ステップS７５は、カレントストリームのSS＿IG＿offset＿sequence＿id＿refで指示されるoffset＿sequence＿idを有するオフセットシーケンスのうち、GOP(i)のPlane＿offset＿direction[j]及びPlane＿offset＿value[j]をビデオデコーダから取得する。
【０２８１】
ステップS７６は、IGプレーンにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向に、Plane＿offset＿value[j]の画素数だけシフトする。
ステップS７７は、IGプレーンにおける各ラインの画素を、Ｘ軸のPlane＿offset＿direction[j]に示される方向とは反対の方向に、Plane＿offset＿value[j]の画素数だけシフトする
図３９は、STN＿table＿SSのFixed＿offset＿during＿Popupがオンである場合のIGプレーンのプレーンシフトの処理手順を示すフローチャートである。本図に示される処理構造は、図のものと基本的に同一だが、ステップS６２がステップS７８に置き換えられ、ステップS６４がステップS７９に、ステップS６６がステップS８０に置き換えられている点が異なる。
【０２８２】
ステップS７８は、STN＿table＿SSのカレントストリームにおけるIG＿plane＿offset＿direction＿during＿BB＿video、IG＿plane＿offset＿value＿during＿BB＿videoを取得する。
ステップS７９は、IGプレーンにおける各ラインの画素を、Ｘ軸のIG＿plane＿offset＿direction＿during＿BB＿videoに示される方向に、IG＿plane＿offset＿value＿during＿BB＿videoの画素数だけシフトする。
【０２８３】
ステップS８０は、IGプレーンにおける各ラインの画素を、Ｘ軸のIG＿plane＿offset＿direction＿during＿BB＿videoに示される方向とは逆の方向に、IG＿plane＿offset＿value＿during＿BB＿videoの画素数だけシフトする。
【０２８４】
以上のように本実施形態によれば、1plane＋Offsetモードの制御のための制御情報の置き場所が、ディペンデントビューストリーム内に規定されているので、3Dカメラが撮影の際に得た奥行きの情報や、ビデオストリームを生成するためのエンコーダがエンコードの過程で得た視差の情報に基づき制御情報を生成して、ディペンデントビュービデオストリーム内にメタデータとして組み入れることで、1plane＋Offsetモードにおけるオフセット制御のための制御情報は簡易に生成されることになる。そうすればオーサリング行程での作業は、大きく省略されることになる。制御情報は、1plane＋Offsetモードにおけるオフセット制御を規定するので、左右の字幕やメニューが存在しなくても、字幕やメニューが1つさえあれば、立体視の再生が可能になる。レフトビュー、ライトビューのそれぞれについて字幕やメニューを作成するという手間が軽減されるばかりか、再生装置におけるプレーンメモリのためのメモリ規模が、ワンプレーンであっても、立体視再生を実現することができるので、オーサリングの効率化と、再生装置の低コスト化の両立を実現することができる。
【０２８５】
(第２実施形態)
第１実施形態では、ディペンデントビューデータブロックを構成するサブTSをサブクリップエントリーIDレファレンスから参照していたため、サブTSがメインTSと分離して記録されている場合、2D再生モードから3D再生モードへの切替え時において、サブTSの読み出しが発生し、AV再生のシームレス性が損なわれる恐れがある。そこで本実施形態は、メインTSと、サブTSとが共に再生装置に読み込まれることを保障する改良を提案する。具体的には、メインTS、サブTSをインターリーブ化して、2TSを1ファイルとして記録することを提案する。
【０２８６】
前提事項として、UDFファイルシステムにおけるファイルについて簡単に説明する。UDFにおけるファイルは、ファイルエントリーによって管理されている複数のエクステントから構成される。「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
【０２８７】
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す“261”が記述される。
【０２８８】
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号（LBN）を含む。アロケーション記述子は、エクステント長を示すデータと、エクステントの記録位置を示す論理ブロック番号とを含む。ただしエクステント長を示すデータの上位２ビットは、“０”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“１”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“０”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
【０２８９】
上述したようなファイルエントリーのアロケーション識別子を参照することで、ストリームファイルを構成するエクステントのアドレスを知得することができる。
次に、本実施形態で想定されているファイルの種別について説明する。
【０２９０】
＜立体視インターリーブドストリームファイル(FileSS)＞
立体視インターリーブドストリームファイル(FileSS)は、2TSをインターリーブ形式にしたストリームファイル(2TSインターリーブファイル)であり、５桁の整数値と、立体視再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。立体視インターリーブドストリームファイルは、エクステントSS[n]から構成され、エクステントSS[n](EXTSS[n])は、インデックス番号nによって特定される。インデックス番号nは、立体視インターリーブドストリームファイルの先頭から1つずつインクリメントされる番号である。
【０２９１】
エクステントSS[n]は、ディペンデントビューデータブロックと、ベースビューデータブロックとの組みとして構成される。
エクステントSS[n]を構成するベースビューデータブロック、ディペンデントビューデータブロックは、ファイル2D、ファイルベース、ファイルディペンデントからのクロスレファレンスの対象となる。クロスレファレンスとは、記録媒体に記録された1つのデータ客体を、複数のファイルのエクステントとして、ファイルエントリーに登録しておくことをいう。本実施形態では、ファイル2Dのファイルエントリー、ファイルベースのファイルエントリー、ファイルディペンデントのファイルエントリーに、ベースビューデータブロック、ディペンデントビューデータブロックの先頭アドレス及び連続長が登録されることになる。
【０２９２】
＜ファイルベース(FileBase)＞
ファイルベース(FileBase)は、ファイル2Dに対応するクリップ情報におけるエクステントスタートポイント情報によって指示されるメインTSを“格納している”とされる仮想的なストリームファイルであり、少なくとも1つのエクステント1[i](EXT1[i]と呼ぶ)によって構成される。エクステント1[i]は、ファイルベースにおけるi番目のエクステントであり、iは、エクステントのインデックス番号であり、ファイルベースの先頭を0としてインクリメントされる。ファイルベースは、2TSファイルである立体視インターリーブドストリームファイルを、1TSファイルとして扱うための仮想的なストリームファイルであり、そのファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
【０２９３】
実際の読み出しにあたって、ファイルベースは、この立体視インターリーブドストリームファイルのファイル名を用いてファイルオープンを行うことで特定される。具体的にいうと再生装置のミドルウェアは、立体視インターリーブドストリームファイルのファイル名を用いたファイルオープンがコールされた場合、ファイルベースのエクステントを特定するファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする。立体視インターリーブドストリームファイルは、“1TSのみを包含している”とみなすことができ、2TSの立体視インターリーブドストリームファイルを1TSのファイルベースとして記録媒体から読み出すことができる。
【０２９４】
B−Bプレゼンテーションモードにおいて、ベースビューデータブロックのみを読み出したい場合は、このファイルベースを構成するエクステントのみが読み出しの対象になる。B−BプレゼンテーションモードからB−Dプレゼンテーションモードへのモード変更があったとしても、読出範囲を、ファイルベースを構成するエクステントの記録範囲から、立体視インターリーブドストリームファイルを構成するエクステントの記録領域に拡大すれば、ベースビューデータブロック、ディペンデントビューデータブロックの双方を読み出すことができるから、ファイル読み出しの効率性を低下させることはない。
【０２９５】
＜ファイルディペンデント(FileDependent)＞
ファイルディペンデント(FileDependent)は、サブTSを“格納している”とされるストリームファイルであり、エクステント2[i](EXT2[i])によって構成される。EXT2[i]は、ファイルディペンデントにおけるi番目のエクステントであり、iは、エクステントのインデックス番号であり、ファイルディペンデントの先頭を0としてインクリメントされる。ファイルベースは、2TSファイルである立体視インターリーブドストリームファイルを、サブTSを格納した1TSファイルとして扱うための仮想的なストリームファイルであり、そのファイルエントリーを、再生装置のメモリ上で構築することで仮想的に生成される。
【０２９６】
ディペンデントビュービデオストリームは、立体視インターリーブドストリームファイルのファイル名である5桁番号に、1を加算した番号がファイル名として付与される。このファイル名を用いてアクセスされる。記録媒体には、ダミーファイルが記録されていて、ディペンデントビュービデオストリームの識別番号である、「１を加算した番号」がこのダミーファイルに付与される。ダミーファイルとは、ファイル名のみが存在していて、実体であるエクステントが存在しないファイルであり、ディペンデントビュービデオストリームは、このダミーファイルに格納されるとして扱われる。
【０２９７】
＜ファイル2D(File2D)＞
ファイル2Dは、2D再生モードにおいて再生されるメインTSを格納している1TSのストリームファイルであり、エクステント2Dから構成される。ファイル2Dは、５桁の整数値と、立体視再生用のインターリーブド形式ファイルである旨を示す拡張子(ssif)とによって識別される。
【０２９８】
以下、ファイル２Ｄ／ファイルベース、ファイルディペンデントの相互関係について説明する。図４０は、エクステントと、ファイル2D／ファイルベース、ファイルディペンデントとの対応付けを示す。
【０２９９】
第１段目は、ファイル2D／ファイルベース、ファイルディペンデントである00001.m2ts,00002.m2tsを示し、第２段目は、ベースビューデータブロックを格納したエクステント、ディペンデントビューデータブロックを格納したエクステントを示す。第３段目は、立体視インターリーブドストリームファイルである00001.ssifを示す。
【０３００】
破線の矢印h1,h2,h3,h4は、エクステントEXT1[i],EXT2[i]が、どのファイルに帰属しているかというアロケーション識別子による帰属関係を示す。矢印h1,h2に示される帰属関係によると、エクステントEXT1[i],EXT1[i+1]は、ファイルベースである00001.m2tsのエクステントとして登録されていることがわかる。
【０３０１】
矢印h3,h4に示される帰属関係によると、エクステントEXT2[i],EXT2[i+1]は、ファイルディペンデントである00002.m2tsのエクステントとして登録されていることがわかる。
矢印h5,h6,h7,h8に示される帰属関係によると、エクステントEXT1[i],EXT2[i],EXT1[i+1],EXT2[i+1]は、00001.ssifのエクステントとして登録されていることがわかる。以上のように、エクステントEXT1[i],EXT1[i+1]は、00001.ssifに帰属すると同時に、00001.m2tsに帰属するという二重性を有していることがわかる。この“ssif”という拡張子は、StereoScopicInterleave Fileの頭文字をとったものであり、立体視再生のため、インターリーブ形式になっていることを示す。
【０３０２】
図４１は、立体視インターリーブドストリームファイルと、ファイル2D／ファイルベースとの関係を示す。
同図（ａ）の第３段目は、インターリーブドストリームファイルの内部構成を示す。ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のそれぞれと、ディペンデントビューデータブロックを格納したエクステントEXT2[1],EXT2[2]のそれぞれとが交互配置されることで構成される。
【０３０３】
第１段目は、ファイル2D及びファイルベースの内部構成を示す。ファイル2D／ファイルベースは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ベースビューデータブロックを格納したエクステントEXT1[1],EXT1[2]のみから構成されている。ファイル2Dのファイル名は、インターリーブドストリームファイルのファイル名が同一だが、拡張子が異なる。
【０３０４】
第２段目は、ファイディペンデントの内部構成を示す。ファイディペンデントは、第３段目におけるインターリーブドストリームファイルを構成するエクステントのうち、ディペンデントビューデータブロックを格納するエクステントEXT2[1],EXT2[2],EXT2[2]のみから構成されている。ファイルディペンデントのファイル名は、インターリーブドストリームファイルのファイル名に1を加算したものになっており、また拡張子が異なる。
【０３０５】
3D映像を含む光ディスクであったとしても、全ての再生装置が3D再生方式に対応しているとは限らないため、2Dでの再生がサポートされることが望ましい。ただし、2D再生のみに対応した再生装置は、3Dで拡張されたデータ構造などは判別できない。2D再生装置は旧来の2D再生方式のままの判別方法で、2Dプレイリストおよび2Dストリームにのみアクセスできる必要があるので、レフトビュービデオストリームについては、2D方式の再生装置が認識できるようなファイル形式で格納されている。
【０３０６】
１つ目の方法は、上述したようなプレイリスト情報の参照、つまり、メインTSは2D再生でも利用できるように2D再生方式と同じファイル名を使い、インターリーブ形式のストリームファイルは拡張子を変える方法である。同図（ｂ）における00001.m2ts、及び、00001.ssifは、一方は2D方式、他方は3D方式でありながら同じファイル名“00001”によってカップリングされている。
【０３０７】
プレイリストは、メインTSのAVクリップしか参照しないため、既存の2D再生装置ではファイル２Ｄしか再生しない。3D対応の再生装置は、プレイリストはメインTSの入ったファイル２Ｄしか参照していないが、同じ識別番号を持ち、拡張子のみ異なるファイルが存在する場合は、そのファイルを見つけ出し、3D映像のためのインターリーブ形式のストリームファイルであると判断して、メインTSと、サブTSとを出力する。
【０３０８】
２つ目の方法は、フォルダを分ける方法である。メインTSは既存のフォルダ名（例：STREAM）を持つフォルダ内に格納しておくが、サブTSは、3D特有の名前を持つフォルダ（例：SSIF）に同じファイル名『00001』で格納しておく。プレイリストがファイルを参照する際、2D再生装置では「STREAM」フォルダ内のファイルのみを参照するが、3D再生装置の場合は「STREAM」と「SSIF」フォルダの中から、同じ名前のファイルを同時に参照することにより、メインTSと、サブTSとを関連づけることが可能となる。
【０３０９】
３つ目の方法は、識別番号によるものである。ファイル２Ｄ／ファイルベースの識別番号が“００００１”である場合、ファイルディペンデントの識別番号は、同図（ｃ）に示すようにこのレフトビューの識別番号に“１”を加算した番号、つまり、“０００２”という識別番号を付与する等、一定のルールに従って関連づけを行う方法である。しかし記録媒体のファイルシステムにおいて、上述のルールで命名されたファイルディペンデントは、あくまでも実体のないダミーファイルとして扱われる。これは、ファイルディペンデントの実体は、立体視インターリーブドストリームファイルに過ぎないとの理由による。
【０３１０】
こうして関連付けられたファイル名を、基本ストリーム選択テーブルにおけるストリーム登録情報、及び、拡張ストリーム選択テーブルにおけるストリーム登録情報におけるストリームエントリーのサブクリップエントリーIDレファレンス(ref＿to＿subclip＿entry＿id)に記述しておく。一方、再生装置については、サブクリップエントリーIDレファレンスに記述された識別番号に“1”を加算した識別番号のファイル名は、ダミーファイルのファイル名であると認証して、ファイルディペンデントを仮想的にオープンする処理を実行する。こうすれば、ストリーム選択プロシージャにおいて、上述したような関連付けがなされたファイルディペンデントが確実に記録媒体から読み出されることになる。
【０３１１】
以上が、ファイル２Ｄ、ファイルベース、ファイルディペンデントについての説明である。
以下、データブロックの詳細について説明する。
【０３１２】
＜ベースビューデータブロック＞
ベースビューデータブロック(B[i])は、メインTSのi番目のデータブロックである。ここで、メインTSとは、カレントプレイアイテム情報のクリップ情報ファイル名情報(クリップ情報ファイルネーム情報)を通じて、メインパスの基軸として指定されているTSである。B[i]の“i”は、ファイルベースの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
【０３１３】
ベースビューデータブロックには、ファイルベースと、ファイル2Dとで共通化されるものと、ファイルベースと、ファイル2Dとで共通化されていないものとがある。
ファイル2D及びファイルベースで共通化されるベースビューデータブロック、及び、ファイル2D固有のベースビューデータブロックは、ファイル2Dのエクステントになるものであり、再生装置におけるバッファアンダーフローを生じさせない長さに設定されている。そしてその先頭のセクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されている。
【０３１４】
ファイル2Dと共通化されていないファイルベース固有のベースビューデータブロックは、ファイル2Dのエクステントにはならないから、再生装置におけるシングルバッファをアンダーフローを生じさせない長さに設定されている訳ではない。より小さいサイズ、つまり、再生装置におけるダブルバッファをアンダーフローさせない長さに設定されている。
【０３１５】
またファイルベース固有のベースビューデータブロックは、その先頭セクタアドレスがファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ベースビューデータブロックにおける先頭ソースパケットのソースパケットが、メインTSに対応するクリップ情報ファイルのクリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ファイルベース固有のベースビューデータブロックの先頭セクタアドレスは、立体視インターリーブドストリームファイルのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
【０３１６】
レフトビューがベースビューである場合、ベースビューデータブロックは、レフトビュービデオストリームの分割部分を格納したソースパケット、レフトビュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット、欧州デジタル放送規格に規定されたパケット管理情報(PCR,PMT,PAT)等、2D再生及びレフトビュー再生のための複数種別のPESストリームの分割部分を格納したソースパケットの集合体である。このベースビューデータブロックを構成するパケットは、ATC,STC,SPNが連続しており、ある一定期間のシームレスなAV再生を保障する。
【０３１７】
＜ディペンデントビューデータブロック＞
ディペンデントビューデータブロック(D[i])は、サブTSのi番目のデータブロックである。サブTSとは、カレントプレイアイテム情報に対応する拡張ストリーム選択テーブルのストリーム登録列におけるストリームエントリーにおいて、サブパスの基軸として指定されているTSである。D[i]の“i”は、ファイルディペンデントの先頭のデータブロックを0としてインクリメントされるインデックス番号である。
【０３１８】
ディペンデントビューデータブロックは、ファイルディペンデントのエクステントになるものであり、再生装置におけるダブルバッファのアンダーフローを生じさせない長さに設定されている。
【０３１９】
また、記録媒体の連続領域上で、ディペンデントビューデータブロックは、同じ再生時間で再生されるべきベースビューデータブロックより手前に配置される。そのため、立体視インターリーブドストリームファイルの読み出し時にあたって、ディペンデントビューデータブロックは、必ずベースビューデータブロックより先に読み出されることになる。
【０３２０】
ディペンデントビューデータブロックは、ファイル2Dと共通化されていないので、その先頭セクタアドレスが、ファイル2Dのファイルエントリーにおけるアロケーション記述子に記述されていない。代わりに、ディペンデントビューデータブロックにおける先頭ソースパケットのソースパケットが、クリップ情報内のエクステントスタートポイント情報によって、ポインティングされている。そのため、ディペンデントビューデータブロックの先頭セクタアドレスは、ファイル2Dのファイルエントリーにおけるアロケーション記述子と、クリップ情報内のエクステントスタートポイント情報とを用いて導きだす必要がある。
【０３２１】
ディペンデントビューがライトビューである場合、ディペンデントビューデータブロックは、ライトビュービデオストリームの分割部分を格納したソースパケット、レフトビュー及びライトビュービュー用のグラフィクスストリームの分割部分を格納したソースパケット、これらと共に再生されるべきオーディオストリームの分割部分を格納したソースパケット等、ライトビュー再生のための複数種別のPESストリームの分割部分を格納したソースパケットの集合体である。これらのパケットはATC,STC,SPNが連続しており、ある一定期間の連続再生を保障する。連続するベースビューデータブロックとディペンデントビューデータブロックとでは、ベースビューデータブロックを構成する複数のソースパケットのATS・SPN、及び、ディペンデントビューデータブロックを構成する複数のソースパケットのATS・SPNは、何れも同じ値になっている。従って、ベースビューデータブロックを構成する複数のソースパケット、及び、ディペンデントビューデータブロックを構成する複数のソースパケットは、同じATC時刻に、PIDフィルタに到達することになる。
【０３２２】
＜エクステントの類型＞
上述したように、ファイル2Dのエクステントには、ファイルベースのエクステントと共通のものと、ファイルベースと共通ではないものとがある。
【０３２３】
ファイル2Dのエクステントが、B[0]、B[1]、B[2]、B[3]2D、B[4]2Dから構成され、ファイルベースのエクステントがB[0]、B[1]、B[2]、B[3]ss、B[4]ssから構成されるものとする。B[0]、B[1]、B[2]は、ファイルベースと共通化されているベースビューデータブロックである。B[3]2D、B[4]2Dは、ファイルベースと共通化されていない、ファイル2D固有のベースビューデータブロックである。
【０３２４】
またB[3]ss、B[4]ssは、ファイル2Dと共通化されていない、ファイルベース固有のベースビューデータブロックである。
B[3]2Dにおけるデータと、B[3]ssのデータとは、bit-for-bitの同一性を有する。B[4]2Dにおけるデータと、B[4]ssのデータとは、bit-for-bitの同一性を有する。
【０３２５】
これらのファイル2DにおけるデータブロックB[2]、B[3]2D、B[4]2Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステント（ビッグエクステント）を構成する。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、立体視インターリーブドストリームファイルを2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。
【０３２６】
ファイル2D及びファイルベースは、エクステントが一部異なっているものの、同一性を有しているので、これらファイル2D及びファイルベースを併せて、“ファイル2D／ファイルベース”という。
【０３２７】
＜ロングジャンプ＞
一般論だが、記録媒体に光ディスクを採用する場合、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。
【０３２８】
ジャンプには、光ディスクの回転速度を上下させる操作の他に、トラックジャンプ及びフォーカスジャンプがある。トラックジャンプは、光ピックアップをディスクの半径方向に移動させる操作をいう。フォーカスジャンプは、光ディスクが多層ディスクであるとき、光ピックアップの焦点を一つの記録層から別の記録層へ移動させる操作をいう。これらのジャンプは一般にシーク時間が長く、かつ、ジャンプによって読み出しがスキップされるセクタ数が大きいので、特に「ロングジャンプ」という。ジャンプ期間中、光ピックアップによる読み出し操作は停止する。
【０３２９】
ジャンプ期間中、読み出し操作がスキップされる部分の長さを「ジャンプ距離」という。ジャンプ距離は通常、その部分のセクタ数で表される。上記のロングジャンプは具体的には、ジャンプ距離が所定の閾値を超えるジャンプとして定義される。その閾値は、例えばBD-ROMの規格では、ディスクの種類及びドライブの読み出し処理に関する性能により、４００００セクタに規定されている。
【０３３０】
ロングジャンプを生じさせる場所の代表的なものとしては、記録層の境界の他、プレイアイテム間の１対ｎの多重接続が存在する場所がある。
ここで、1対nのプレイアイテムの多重接続を行う場合、ｎ個のプレイアイテムを構成するn個のTSのうち1つ目のものは、その直前のプレイアイテムを構成するTSの直後に配置することができる。しかし2つ目以降のものは、その直前のプレイアイテムを構成するTSの直後に配置することができない。１対nの多重接続が存在する場合において、直前のプレイアイテムから、ｎ個のプレイアイテムの２個目以降のプレイアイテムへとジャンプする場合、そのジャンプは、1つ以上のTSの記録領域を読み飛ばす必要があるので、１対ｎのプレイアイテムの多重接続が存在する場所では、ロングジャンプが生じることになる。
【０３３１】
＜各モードの再生経路＞
2D再生モードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイル2Dのエクステントから構成される。
【０３３２】
B−Dプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照される立体視インターリーブドストリームファイルのエクステントから構成される。
【０３３３】
B−Bプレゼンテーションモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報によって参照されるファイルベースのエクステントから構成される。
【０３３４】
これらの3つのモードの再生経路は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報に記述されているファイル名を、ファイル2Dのファイル名として用いてファイルオープンを行うか、ファイルベースのファイル名として用いてファイルオープンを行うか、立体視インターリーブドストリームファイルのファイル名として用いてファイルオープンを行うかで切り替えられる。このような再生経路の切り替えは、カレントプレイリストやカレントプレイアイテムの変動を招かないので、再生モードの変更時のシームレス性を維持することができる。
【０３３５】
よって再生装置は、カレントプレイアイテム情報のクリップ情報ファイルネーム情報に基づき立体視インターリーブドストリームファイル、ファイルベース、ファイル2Dの何れかをオープンすることにより、それぞれの再生モードに適合したデータブロックを記録媒体から読み出すことができる。
【０３３６】
＜EXT2D、EXT1[n]、EXT2[n]、の具体的な値＞
EXT2Dの下限値は、2D再生モードの再生時、各ベースビューデータブロックから次のベースビューデータブロックまでのジャンプ期間中において、再生装置におけるリードバッファのバッファアンダーフローを生じないように決定される。
【０３３７】
ｎ番目のベースビューデータブロックから(n+1)番目のベースビューデータブロックまでのジャンプが時間Tjump2D(n)を要し、各ベースビューデータブロックが,リードバッファに速度Rud2Dで読み出され、かつ、リードバッファからビデオデコーダへ前記ベースビューデータブロックが平均速度Rbext2Dで転送されるとき、EXT2Dの下限値は以下の条件１の式で表される。
【０３３８】
＜条件１＞EXT2Dの下限値 ≧（Rud2D×Rbext2D）/(Rud2D−Rbext2D)×Tjump2D（n）
ベースビューデータブロックB[n]ssに対応するエクステントをEXT1[n]であるものとする。この場合、EXT1[n]の下限値は、B−Dプレゼンテーションモードの再生時、各ベースビューデータブロックから次のディペンデントビューデータブロックまでのジャンプ期間と、当該ディペンデントビューデータブロックから次のベースビューデータブロックまでのジャンプ期間とを通して、ダブルバッファのアンダーフローを生じさせないように決定される。
【０３３９】
ここでのダブルバッファは、リードバッファ１、リードバッファ２から構成されるものとする。リードバッファ１は、2D再生装置のリードバッファと同一物である。
B−Dプレゼンテーションモードの再生において、n番目のベースビューデータブロックからp番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n)を要し、ｐ番目のディペンデントビューデータブロックから（n+1）番目のベースビューデータブロックまでのジャンプが時間TBjump3D(n)を要するものとする。
【０３４０】
そして各ベースビューデータブロックがリードバッファ１へ速度Rud3Dで読み出され、各ディペンデントビューデータブロックがリードバッファ２へ速度Rud3Dで読み出され、かつ、リードバッファ１からビデオデコーダへ前記ベースビューデータブロックが平均速度Rbext3Dで転送されるとき、EXT1[n]の下限値は、以下の条件２の式で表される。ビックエクステントの連続長は、この下限値、又は、この下限値を上回る値に設定される。
【０３４１】
＜条件２＞EXT1[n]の下限値 ≧（Rud3D×Rbext3D）/(Rud3D−Rbext3D)×(TFjump3D（n）＋EXT2[n]/(Rud3D＋TBjump3D(n)))
EXT2の下限値は、B−Dプレゼンテーションモードの再生時、各ディペンデントビューエクステントから次のベースビューエクステントまでのジャンプ期間と、当該ベースビューエクステントから次のディペンデントビューエクステントまでのジャンプ期間とを通して再生装置におけるダブルバッファにアンダーフローを生じさせないように決定されている。
【０３４２】
（n+1）番目のベースビューデータブロックから（p+1）番目のディペンデントビューデータブロックまでのジャンプが時間TFjump3D(n+1)を要し、かつ、リードバッファ２からデコーダへ前記ディペンデントビューストリームファイルが平均速度Rdext3Dで転送されるとき、EXT2[n]の下限値は以下の条件３の式で表される。
【０３４３】
＜条件３＞
EXT2[n]の下限値  ≧（Rud3D×Rbext3D）/(Rud3D−Rdext3D)×(TBjump3D（n）＋EXT1[n+1]/(Rud3D＋TFjump3D(n+1)))
＜EXTSSの具体的な値＞
あるエクステントの読み出しから、次のエクステントへのジャンプにあたって、そのジャンプの直前のバッファ占有量は、充分なものでなければならない。そうすると、立体視インターリーブドストリームファイルの読み出し時にあたってリードバッファは、1つのエクステントによって充填される必要があり、バッファアンダーフローの発生を避けねばならない。
【０３４４】
しかしEXTSSは、エクステントからエクステントへのジャンプ期間Tjumpだけではなく、Ｔdiffに基づき定める必要がある。ここでTdiffは、EXTssにおけるディペンデントビューデータブロックのプリロードと、EXTssnextにおけるディペンデントビューデータブロックのプリロードとに伴う遅延時間を意味する。以下にTdiffの意味合いについて解説すると、立体視インターリーブドストリームファイルの読み出しにあたって、先頭のディペンデントビューデータブロックをプリロードしている間は再生を開始することはできない。
【０３４５】
EXTssでは、このディペンデントビューデータブロックのプリロードに要する期間だけ再生が遅れるから、EXTssにおいて先頭のディペンデントビューのデータブロックのプリロードに要する時間は、再生がその分遅れてしまうという“遅延期間”となる。
【０３４６】
逆にEXTssnextにおいては、EXTssからEXTssnextへのジャンプの直後に、先頭のディペンデントビューデータブロックのプリロードが行われるから、その間だけビデオデコーダの再生開始が遅れてもよいことになる。つまりEXTssnextの再生にあたって、先頭のディペンデントビューデータブロックのプリロードが行われる期間は、ビデオデコーダ再生開始が猶予される“猶予期間”となる。
【０３４７】
以上を踏まえるとTdiffは、ディペンデントビューデータブロックの猶予期間から遅延期間を引いた値として導かれることになる。具体的には、以下の式を満たすように算出される。
【０３４８】
Tdiff=ceil[((Ｓ1stEXT1[i]EXTSSnext]−Ｓ1stEXT1[i]EXTSS)x1000x8)/Rud72]
ここでＴdiffは、Ｓ1stEXT2[i]EXTssの読出期間と、Ｓ1stEXT2[i]EXTssnextの読出期間との差分を意味し、Ｓ1stEXT2[i]EXTssは、EXTssの最初に位置するEXT2[i]のサイズであり、Ｓ1stEXT2[i]EXTssNEXTは、EXTssNEXTの最初に位置するEXT2[i]のサイズである。EXTssnextは、立体視インターリーブドストリームファイルにおけるエクステントであって、EXTssの直後に位置し、EXTssとシームレスに再生されるものである。
【０３４９】
このTdiffと、EXTssnextへのジャンプ時間(Ｔjump)とを用いれば、各エクステントにおける平均ビットレートに基づく最小エクステントサイズであるSextssは、以下の条件４を満たす値として算出される。
【０３５０】
＜条件４＞
SextSS[Byte]≧ceil[(Tjump＋Tdiff×Rud72)/(1000×8))×(Rextss×192)/(Rud72×188−Rextss×192)]
ここで、Rud72は、立体視再生モードにおけるBD-ROMドライブからのデータレートである。
【０３５１】
Rextssは、EXTssの平均ビットレートであり、以下の式から導かれる。
Ｒextss＝ceil[Ｎsp×188×8/(ATCDextss/27000000)]
ATCDextss＝ATCstart＿extssnext −ATCstart＿extss
ATCDextss＝ATClast＿extss − ATCstart＿extss + ceil(27000000x188x8/min(Rts1,Rts2))
ATCDextssは、EXTssのATC期間である。
【０３５２】
ATCstart＿EXTSSは、EXTssにおけるソースパケット列のATCフィールドによって指示される最小のATC値である。
ATCstart＿EXTssnextは、EXTssnextにおけるソースパケット列のATCフィールドによって指示される最小のATC値である。
【０３５３】
ATClast＿EXTSSは、EXTssにおけるソースパケット列のATCフィールドによって指示される最大のATC値である。
Ｎspは、メインTS、サブTSにおけるソースパケットであって、ATCDexssの範囲内にあるATCに対応するATC値をもつものの個数である。
【０３５４】
Ｒts1は、メインTSにおけるTSレコーディングレートの値であり、その最大値は、48Ｍbpsである。
Ｒts2は、サブTSにおけるTSレコーディングレートの値であり、その最大値は、48Ｍbpsである。
【０３５５】
2つのプレイアイテムを連続的に再生存在する場合、EXTssは、Previousプレイアイテム(プレイアイテム１)によって使用されるATCシーケンスの最初のデータバイトを含む。
・EXTssは、条件４において定義された最小エクステントサイズ以上のサイズをもつ。
【０３５６】
・EXTssがPreviousプレイアイテムにて使用されるATCシーケンスの最初のデータバイトである場合、Previousプレイアイテムのコネクションコンディション情報は、＝５(プレイアイテムの境界でクリーンブレークを伴う接続処理)、＝６(プレイアイテムの境界がGOPのバウンダリと一致する接続処理)に設定されない。この場合、EXTssのサイズを満たさなくてもよい。
【０３５７】
EXTssは、カレントプレイアイテム（プレイアイテム２）によって使用されるATCシーケンスのデータバイトを含む。
【０３５８】
・EXTssは、条件４において定義された最小エクステントサイズ以上のサイズをもつ。
・EXTssがプレイアイテム２にて使用されるATCシーケンスの最後のデータバイトである場合、プレイアイテム２のコネクションコンディション情報は、＝５、＝６に設定されない。この場合、EXTssのサイズを満たさなくてもよい。
【０３５９】
図４２は、立体視インターリーブドストリームファイル、ファイル2D、ファイルベースの相互関係を示す。第１段目はファイル2Dを示し、第２段目は記録媒体上のデータブロック、第３段目は立体視インターリーブドストリームファイル、第４段目はファイルベース、第５段目はファイルディペンデントを示す。
【０３６０】
第２段目におけるデータブロックは、上述したD[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ss,B[3]2D,B[4]2Dである。そして矢印ex1,ex2,ex3,ex4は、データブロックのうち、B[1],B[2],B[3]2D,B[4]2Dがファイル2Dのエクステントを構成しているという帰属関係を示す。
【０３６１】
矢印ex5,ex6は、データブロックのうち、D[1],B[1],D[2],B[2],D[3],B[3]ss,D[4],B[4]ssが立体視インターリーブドストリームファイルのエクステントを構成しているという帰属関係を示す。
【０３６２】
第４段目は、この立体視インターリーブドストリームファイルを構成するデータブロックのうち、B[1],B[2],B[3]ss,B[4]ssがファイルベースのエクステントとなり、第５段目は、立体視インターリーブドストリームファイルを構成するデータブロックのうち、D[1],D[2],D[3],D[4]がファイルディペンデントのエクステントになることを示す。
【０３６３】
図４３は、2Dプレイリスト、3Dプレイリストを示す。第１段目は、2Dプレイリスト情報であり、第２段目は、ベーズデータブロック、第３段目は、3Dプレイリスト、第４段目は、ディペンデントビューデータブロックを示す。
【０３６４】
矢印rf1,rf2,rf3は、2Dプレイリスト情報のプレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名00001と、拡張子m2tsとを組合せることによる再生経路を示す。この場合、データブロックB[1],B[2],B[3]2Dによってベースビュー側の再生経路が構成される。
【０３６５】
矢印rf4,rf5,rf6,rf7は、3Dプレイリスト情報のプレイアイテム情報により指定される再生経路を示す。この場合、B[1],B[2],B[3]ss,B[4]ssを用いてベースビュー側の再生経路が構成される。
【０３６６】
矢印rf8,rf9,rf10,rf11は、3Dプレイリスト情報のサブプレイアイテム情報により指定される再生経路を示す。この場合、D[1],D[2],D[3],D[4]を用いてディペンデントビュー側の再生経路が構成される。これらのプレイアイテム情報、サブプレイアイテム情報により指定される再生経路を構成するデータブロックは、プレイアイテム情報におけるclip＿information＿file＿nameに記述されているファイル名と、拡張子ssifとを組合せてファイルオープンを行うことで読み出すことができる。
【０３６７】
本図の3Dプレイリストにおけるクリップ情報ファイルネーム情報、2Dプレイリスにおけるクリップ情報ファイルネーム情報は、共通のファイル名を記述しているので、これら3Dプレイリスト、2Dプレイリストを定義するようなプレイリスト情報を記述するにあたっては共通する記述で足りる(符号df1,df2参照)。よって、この3Dプレイリストを実現するようなプレイリスト情報を記述しておけは、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。本図の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておくことで、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されるので、オーサリングを行う者の手間を軽減することができる。
【０３６８】
立体視インターリーブドストリームファイルにメインTS、サブTSを格納する場合、２Ｄプレイリストのプレイアイテム情報におけるclip＿information＿file＿nameは、ファイル２Ｄのファイル名を記述する。３Ｄプレイリストのプレイアイテム情報におけるclip＿information＿file＿nameは、ファイルベースのファイル名を記述する。ファイルベースは、仮想的なファイルであり、そのファイル名は、立体視インターリーブドストリームファイルと同じものなので、立体視インターリーブドストリームファイルのファイル名をプレイアイテム情報におけるclip＿information＿file＿nameに記述しておけばよい。拡張ストリーム選択テーブルのストリーム登録情報におけるref＿to＿subclip＿entry＿idは、ファイルディペンデントのファイル名を記述する。ファイルディペンデントのファイル名は、立体視インターリーブドストリームファイルの識別番号に、１を加算したものである。
【０３６９】
図４４は、図４３の3Dプレイリストに、もう1つサブパスを加えたプレイリストを示す。図４３のプレイリストは、サブパスID＝“１”のサブパスのみを具備していたのに対して、図４４のプレイリストにおける2つ目のサブパスは、サブパスID＝“２”によって識別されるものであり、別のデータブロックを参照している。2以上のサブパス情報を設けることで定義される複数のライトビューは、右目から被写体を見る角度が異なる複数のライトビューであり、ライトビューを構成するデータブロックがその角度の数だけ用意されていて、角度ごとにサブパスを設けている。
【０３７０】
ベースビューデータブロックから構成されるメインTSによって規定されるメインパスと同期して再生するサブパスを切り替えることで、ユーザにとって快適な視差画像を用いて立体映像を表示することが可能となる。
【０３７１】
この3Dプレイリストを実現するようなプレイリスト情報についても、再生装置の出力モードが立体視出力モードのときは3Dプレイリストとして機能し、再生装置の出力モードが2D出力モードのときは2Dプレイリストとして機能することになる。図４３の2Dプレイリスト、3Dプレイリストは、1つのプレイリスト情報を記述しておけば、これを解釈する再生装置の出力モードに応じて、2Dプレイリスト、3Dプレイリストとして解釈されて、適宜最適な出力モードがなされるので、オーサリングを行う者の手間を軽減することができる。
【０３７２】
以降、ベースビュービデオストリームの指定の仕方について説明する。
一般にスタジオでは、レフトビュービデオを2D映像として作成すると考えられるが、中には、ライトビューを2D映像として作成する方がよいと考えるかもしれない。そのような可能性が存在するので、レフトビュー及びライトビューのうち、どちらをベースビューに設定するかを示すベースビューインディケータをプレイアイテム情報毎に設定できるようにしている。レフトビュービデオストリーム及びライトビュービデオストリームのうちどちらをベースビュービデオストリームとするか、レフトビューPGストリーム及びライトビューPGストリームのうちどちらをベースビューPGストリームとするか、レフトビューIGストリーム及びライトビューIGストリームのうちどちらをベースビューIGストリームとするかは、このプレイアイテム情報毎のベースビューインディケータによって指示される。
【０３７３】
上述したように、ディペンデントビューデータブロックは、必ずベースビューデータブロックに先行して配置されるとの規則性をもつので、このベースビューインディケータを参照すれば、ライトビューを再生するためのソースパケット、レフトビューを再生するためのソースパケットのどちらが、先に再生装置に供給されるかを知得することができる。
【０３７４】
この情報によって、ライトビュービデオストリームが、ベースビュービデオストリームとして指定されている場合は、たとえライトビューがサブパス情報によって指定されていたとしても、かかるライトビュービデオストリームをビデオデコーダに先に投入して、非圧縮のピクチャデータを得る。そして、このライトビュービデオストリームをデコードすることで得られた非圧縮のピクチャデータに基づき動き補償を行う。こうして、どちらをベースビューとすることができるかという選択に柔軟性をもたせている。
【０３７５】
図４５（ａ）は、図４３の3Dプレイリストに、ベースビューインディケータを書き加えた図である。
図４５（ｂ）は、オブジェクト指向プログラミング言語によるベースビューインディケータの記述を示す。本図は、PlayItemを定義する構造体において、ベースビューインディケータをどのように記述するかという記述例である。本図に示すように、“0”の即値を指定することで、レフトビュービデオストリームをベースビュービデオストリームとして指定することができ、“1”の即値を指定することで、レフトビュービデオストリームをベースビュービデオストリームとして指定することができる。
【０３７６】
表示装置への出力に使うことができ、表示装置側は、それぞれ2つのストリームを区別するために利用する。シャッター方式の眼鏡を使う場合などでは、プレイアイテムが参照するメイン映像がレフトビューなのかライトビューなのか分からなければ、眼鏡と表示装置の表示を同期することができないため、レフトビューを表示しているときにはシャッター方式眼鏡の左目側の光を透過し、ライトビューを表示しているときにはシャッター方式眼鏡の右目側の光を透過するよう、眼鏡に切り替え信号を送っている。
【０３７７】
また、レンチキュラーのように表示装置の画面にプリズムを組み込んだ裸眼立体視方式でも、レフトビューとライトビューの区別は必要なため、この情報を用いて区別を行う。以上がベースビューインディケータについての説明である。このベースビューインディケータは、視差画像のうち、レフトビュー又はライトビューのどちらかが平面視映像として再生できることを前提にしている。
【０３７８】
図４６は、プレイアイテムの再生手順を示す。
ステップＳ４１は、カレント出力モードが3D出力モードであるか否かの判定であり、カレント出力モードが2D出力モードであれば、ステップＳ４３〜ステップＳ４６を実行する。
【０３７９】
ステップＳ４３において、カレントプレイアイテムのClip＿Information＿file＿nameに記述されている「XXXXX」と、拡張子「m2ts」とで指定されているストリームファイルをオープンし、ステップＳ４４において、ビデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿TimeをStart＿SPN[i]及びEnd＿SPN[i]に変換する。
【０３８０】
ステップＳ４５では、パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し、ステップＳ４６において、読出範囲[i]に属するエクステントを連続的に読み出すよう、記録媒体のドライブに指示する。
【０３８１】
カレント出力モードが立体視出力モードであれば、ステップＳ５０〜ステップＳ６０のループに移行する。
ステップＳ５０において、カレントプレイアイテムのClip＿Information＿file＿nameに記述されている「XXXXX」と、拡張子「ssif」とで指定されているストリームファイルをオープンし、ステップＳ５１において、レフトビュービデオストリーム、ライトビュービデオストリームのうち、カレントプレイアイテム情報のベースビューインディケータによって指定されているものをベースビュービデオストリームとする。それ以外のものをディペンデントビューストリームとする。
【０３８２】
ステップＳ５２において、ベースビュービデオストリームのパケットIDに対応するエントリーポイントを用いて、カレントPlayItem.In＿Time及びカレントPlayItem.Out＿TimeをStart＿SPN[i]及びEnd＿SPN[i]に変換する。
【０３８３】
ステップＳ５３では、ディペンデントビューストリームに対応するSubPlayItemを特定し、ディペンデントビューストリームのパケットID[j]に対応するエントリーポイント[j]を用いて特定されたSubPlayItemIn＿Time、SubPlayItemOut＿TimeをStart＿SPN[j]、End＿SPN[j]に変換する(ステップＳ５４)。
【０３８４】
パケットID[i]のTSパケット[i]をStart＿SPN[i]からEnd＿SPN[i]まで読み出すための読出範囲[i]に属するエクステントを特定し(ステップＳ５５)、パケットID[j]のTSパケット[j]をStart＿SPN[j]からEnd＿SPN[j]まで読み出すための読出範囲に属するエクステントを特定する(ステップＳ５６)。そしてステップＳ５７において読出範囲[i],[j]に属するエクステントをアドレスの昇順にソートして、ステップＳ５８においてソートされたアドレスを用いて、読出範囲[i],[j]に属するエクステントを連続的に読み出すよう、ドライブに指示する。その後、ソースパケット列が読み出されれば、ステップＳ５９においてベースビューのATCシーケンス、ディペンデントビューのATCシーケンスをそれぞれ復元して、ベースビュー用のPIDフィルタ、ディペンデントビュー用のPIDフィルタに送り込む。
【０３８５】
以上のように本実施形態によれば、ベースビューデータブロックと、ディペンデントビューデータブロックとを1つの立体視インターリーブドストリームファイルに格納しつつも、これらをデコーダに供給する際、ベースビュー用のATCシーケンスと、ディペンデントビュー用のATCシーケンスとを復元するので、デコーダ側では、立体視インターリーブドストリームファイルを通常のストリームファイルと同様に取り扱うことができる。よって、ベースビュービデオストリーム、ディペンデントビュービデオストリームの格納方式に、積極的に立体視インターリーブドストリームファイルを取り入れることができる。
【０３８６】
(第３実施形態)
本実施形態では、クリップ情報ファイルの詳細について説明する。
図４７は、クリップ情報ファイルの内部構成を示す。
【０３８７】
同図（ａ）は、2Dのクリップ情報ファイル、同図（ｂ）は、3D用のクリップ情報ファイルを示す。これらのクリップ情報ファイルは、『クリップ情報』、『シーケンス情報』、『プログラム情報』、『特徴点情報』を含む。
【０３８８】
『クリップ情報』は、ストリームファイルに格納されているソースパケット列のそれぞれが、どのようなAVクリップであるかをATCシーケンス毎に示す情報であり、対応するAVクリップによって構成されるアプリケーションが、ムービー、スライドショー等、どのような類型に属するか(アプリケーションタイプ)、対応するAVクリップがどのようなストリームの類型に属するか(ストリームタイプ)、AVクリップにおけるTSパケットの転送レート(TSレコーディングレート)、前のAVクリップを構成するATCシーケンスとのATCの差分(ATCデルタ)、符号化に用いた符号化方式の識別子を含む。
【０３８９】
『シーケンス情報』は、ストリームファイルに格納されている1又は複数のソースパケット列がどのようなATCシーケンスであるかを示す情報(ATCシーケンス情報)をATCシーケンス毎に示す構成になっている。ATCシーケンス情報は、ATCの開始点たるソースパケットがどこに存在するかをソースパケット番号で示す情報、STCシーケンス識別子ーATCシーケンス識別子間のオフセットと、複数のSTCシーケンスのそれぞれについてのSTCシーケンス情報とを含む。STCシーケンス情報は、そのSTCシーケンスにおけるPCRを格納しているソースパケットのパケット番号、そのATCシーケンスのうち、どこにSTCシーケンスの開始点たるソースパケットが存在するかを示す情報、STCシーケンスにおける再生開始時刻、再生終了時刻を含む。
【０３９０】
『プログラム情報』は、クリップ情報ファイルによって“AVクリップ”であるとして管理されているメインTS、サブTSのプログラム構成を示す情報であり、AVクリップがどのようなESを多重化したものであるかを示す。具体的には、AVクリップに多重化されているESがどのようなパケット識別子を有しているか、どのような符号化方式であるかを示す。ビデオストリームが、MPEG2-video,MPEG4-AVC等のうち、どの符号化方式を用いて圧縮符号化されているかは、このプログラム情報内に明示される。
【０３９１】
『特徴点情報』は、AVクリップに多重化されている複数のESの特徴点がどこに存在するかを、ES毎に示す情報である。ES毎の特徴点を示す情報は、エントリーマップと呼ばれる。
【０３９２】
何が特徴点になるかは、ストリームの種別毎に異なる。ベースビュービデオストリーム、ディペンデントビュービデオストリームの場合は、オープンGOP、クローズドGOPの先頭に位置するIピクチャのアクセスユニットデリッミターが特徴点となる。オーディオストリームの場合は、１秒置き等、一定期間置きに存在するオーディオフレームの先頭位置を示すアクセスユニットデリッミターが特徴点となり、PGストリーム、IGストリームの場合は、グラフィクスストリームのディスプレイセットのうち、表示に必要な全ての機能セグメントを具備したもの(エポックスタートのディスプレイセット、アクジッションポイントのディスプレイセット)の先頭位置を示すアクセスユニットデリッミターが特徴点となる。
【０３９３】
また特徴点をどのように表すかは、ATCシーケンス、STCシーケンスのそれぞれで異なる。ATCシーケンスにおいて特徴点は、ソースパケット番号で表現される。STCシーケンスにおいては、同じ特徴点が、STC時間軸における時点を示すPTSを用いて表現される。
【０３９４】
上記違いに鑑みES毎のエントリーマップは、複数のエントリーポイントから構成されている。具体的にいうと、エントリーマップを構成する個々のエントリーポイントは、ATCシーケンスにおける特徴点の所在を示すソースパケット番号が、STCシーケンスにおける特徴点の所在を示すPTSと対応付けられており、その特徴点へのアングル切り替えが可能であるか否かを示すフラグ(is＿angle＿changeフラグ)を具備している。マルチアングル区間を構成するインターリーブユニットの先頭に位置するソースパケットは、アングル切り替えが可能になっているため、インターリーブユニットの先頭ソースパケットを差すエントリーポイントのis＿angle＿changeフラグは、必ずオンに設定される。また、インターリーブユニットの先頭ソースパケットを差すエントリーポイントは、エントリーポイントによって、プレイアイテム情報におけるIn＿Timeと対応付けられている。
【０３９５】
ES毎のエントリーマップは、これらストリーム種別毎の特徴点のソースパケット番号を、PTSに対応付けて示しているので、このエントリーマップを参照することで、STCシーケンスにおける任意の時点から、その時点に最も近いES毎の特徴点の所在を示すソースパケット番号を導くことができる。
【０３９６】
以上が2D用のクリップ情報ファイルについての説明である。続いて、3D用のクリップ情報ファイルの詳細について説明する。3D用のクリップ情報ファイルは、図４７（ｂ）の内部構成になっていて、通常のクリップ情報(管理情報)である「ファイル２Ｄ用のクリップ情報」の他に、ファイルディペンデント用のクリップ情報である「クリップディペンデント情報(ベースビュー管理情報)」、ファイルベース用のクリップ情報である「クリップベース情報(ベースビュー管理情報)」が存在する。これは以下の理由による。第２実施形態で述べたように、立体視インターリーブドストリームファイルと、通常のストリームファイルとの混同を避けるため、立体視インターリーブドストリームファイルは、ストリームファイルとは異なるディレクトリに格納される。そのため立体視インターリーブドストリームファイルには、クリップ情報ファイルを対応付けることができない。そこで、クリップディペンデント情報、及び、クリップベース情報は、ファイル２Ｄに対応するクリップ情報ファイルに格納されることになる。
【０３９７】
2D用のクリップ情報と、クリップベース情報及びクリップディペンデント情報との違いは、クリップベース情報及びクリップディペンデント情報の内部に、エクステントスタートポイント列を含むメタデータが存在する点である。
【０３９８】
図４７（ｂ）において、クリップディペンデント情報は、エクステントスタートポイント列を含み、クリップベース情報も、エクステントスタートポイント列を含む。クリップディペンデント情報内に存在するエクステントスタートポイント列は、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルディペンデントを構成する複数のエクステントの先頭のソースパケット番号を示す。
【０３９９】
クリップベース情報内に存在するエクステントスタートポイント列も、複数のエクステントスタートポイント情報から構成され、各エクステントスタートポイント情報はファイルベースを構成する複数のエクステントの先頭のソースパケット番号を示す。
【０４００】
これらのエクステントスタートポイント情報が存在することの技術的意義について述べる。
ストリームファイルに格納されているTSは、本来は、1つのTSであり、ATCシーケンスも1つのみである。よって、クリップ情報ファイルのシーケンス情報を参照しただけでは、分割部分の先頭がどこであるかを判別することはできない。一方、分割部分の先頭はエクステントの先頭でもあるので、ファイルエントリやエクステント記述子といったファイルシステムの情報を参照すれば、分割部分の先頭がどこであるかを知ることができるが、ファイルシステムの情報はミドルウェアで管理されている情報であるため、アプリケーションからこのエクステントの情報を参照するのは困難を極める。そこで、本実施形態では、エクステントスタートポイント情報を用いて、エクステントが何パケット目であるかをクリップ情報内に示させるようにしている。
【０４０１】
図１０３は、ベースビュークリップ情報におけるエクステントスタートポイント情報の一例と、ディペンデントビュークリップ情報におけるエクステントスタートポイント情報の一例を示す。（ａ）は、ベースビュークリップ情報のエクステントスタートポイント情報と、ディペンデントビュークリップ情報のエクステントスタートポイント情報とを示す。
【０４０２】
（ｂ)は、ATCシーケンス1を構成するベースビューデータブロックB[0],B[1],B[2]・・・・B[n]、ATCシーケンス2を構成するディペンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]を示す。（ｃ）は、ディペンデントビューデータブロックのソースパケット数、ベースビューデータブロックのソースパケット数を示す。
【０４０３】
（ｄ）は、立体視インターリーブドストリームファイルに包含される複数のデータブロックを示す。
同図（ｂ）に示すように、ATCシーケンス2が、ディペンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]から構成されるとすると、ATCシーケンス２における、ディペンデントビューデータブロックD[0],D[1],D[2]・・・・D[n]の相対ソースパケット数である0,b1,b2,b3,b4・・・bnがファイルディペンデントのエクステントスタートポイント情報のSPN＿extent＿startに記載される。
【０４０４】
ATCシーケンス1が、ベースビューデータブロックB[0],B[1],B[2]・・・・B[n]によって構成されるとすると、ベースビューデータブロックの相対ソースパケット数である0,a1,a2,a3,a4・・・anが、ファイルベースのエクステントスタートポイント情報のSPN＿extent＿startに記載される。
【０４０５】
同図（ｃ）は、立体視インターリーブドストリームファイルにおける任意のディペンデントビューデータブロックD[x]、任意のベースビューデータブロックb[x]のソースパケット数である。ディペンデントビューデータブロックD[x]の先頭ソースパケット番号がbxであり、ディペンデントビューデータブロックD[x+1]の先頭ソースパケット番号がbx+1である場合、D[x]を構成するソースパケット数は、ｂx+1−ｂxになる。
【０４０６】
同じく、ベースビューデータブロックB[x]の先頭ソースパケット番号がａxであり、ベースビューデータブロックB[x+1]の先頭ソースパケット番号がａx+1である場合、B[n]を構成するソースパケット数は、ａx+1−ａxになる。
【０４０７】
立体視インターリーブドストリームファイルにおける最後のベースビューデータブロックB[n]の先頭ソースパケット番号がanであり、ATCシーケンス１におけるソースパケットの個数がnumber＿of＿source＿packet1である場合、B[n]を構成するソースパケット数は、number＿of＿source＿packet1-anになる。
【０４０８】
立体視インターリーブドストリームファイルにおける最後のディペンデントビューデータブロックD[n]の先頭ソースパケット番号がbnであり、ATCシーケンス２におけるソースパケットの個数がnumber＿of＿source＿packet2である場合、D[n]を構成するソースパケット数は、number＿of＿source＿packet2-bnになる。
【０４０９】
そうすると、ディペンデントビューデータブロックの先頭ソースパケット番号、ベースビューデータブロックの先頭ソースパケット番号は、（ｄ）に示す通りになる。
立体視インターリーブドストリームファイルにおいて、D[0]の先頭SPNは“0”、B[0]の先頭SPNは“b1”になる。
【０４１０】
D[1]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケット数a1との和になるから“b1+a1”になる。
B[1]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケット数a1と、先行するD[1]のソースパケット数b2-b1との和になるから“b2+a1(=b1+a1+b2-b1)”になる。
【０４１１】
D[2]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケット数a1と、先行するD[1]のソースパケット数b2-b1と、B[1]のソースパケット数a2-a1との和になるから“b2+a2(=b1+a1+b2-b1+a2-a1)”になる。
【０４１２】
B[2]の先頭SPNについては、先行するD[0]のソースパケット数b1と、B[0]のソースパケット数a1と、先行するD[1]のソースパケット数b2-b1と、B[1]のソースパケット数a2-a1と、D[2]のソースパケット数b3-b2との和になるから“b3+a2(=b1+a1+b2-b1+a2-a1+b3-b2)”になる。図１０４は、ATCシーケンス１、２における任意のデータブロックのソースパケット番号を説明するための図である。同図（ａ）のATCシーケンス２において、bxのソースパケット番号に存在するD[x]の立体視インターリーブドストリームファイルにおけるソースパケット番号を求める場合を考える。この場合、D[x]の先頭ソースパケット番号は、D[0],B[0],D[1],B[1],D[2],B[2]・・・・D[x-1],B[x-1]の相対ソースパケット数のソースパケット数の総和になるから、同図（ｂ）に示すように“bx+ax”になる。
【０４１３】
同図（ａ）のATCシーケンス１において、axのソースパケット番号に存在するB[x]の立体視インターリーブドストリームファイルにおけるソースパケット番号を求める場合を考える。この場合、同図（ｂ）に示すように、B[x]の先頭ソースパケット番号は、D[0],B[0],D[1],B[1],D[2],B[2]・・・・D[x-1],B[x-1],D[x]の相対ソースパケット数のソースパケット数の総和になるから、“ｂx+1＋ａx”になる。
【０４１４】
同図（ｃ）は、上記ベースビューデータブロックをエクステントとするファイルベースと、上記ディペンデントビューデータブロックをエクステントとするファイルディペンデントとを示す。
【０４１５】
B[x]にあたるファイルベースのエクステントであるEXT1[x]の先頭LBN及び連続長、及び、D[x]にあたるファイルディペンデントのエクステントであるEXT2[x]の先頭LBN及び連続長は以下のように求められる。
【０４１６】
D[x]の先頭ソースパケット番号からLBNを求めるには、（(ｂx+ａx)*192/2048)という計算でソースパケットをLBNに変換する。同じく、Ｂ[x]の先頭ソースパケット番号からLBNを求めるには、（(ｂx+1＋ａx)*192/2048)という計算でソースパケットをLBNに変換する。ここで“192”は、ソースパケットサイズをバイト数で表したものであり、“2048”は、セクタサイズ(論理ブロックサイズ)をバイト数で表したものである。これらのLBNに最も近い、立体視インターリーブドストリームファイルのエクステントのLBNは、上記変換によって得られたLBNを、関数SSIF＿LBN(file＿offset)の引数であるfile＿offsetに用いることで算出される。関数SSIF＿LBNは、file＿offsetから、SSIFのアロケーション既述子をたどって、file＿offsetに該当するLBNを返す関数である。
【０４１７】
こうすることで、EXT2[x]の先頭LBNは、SSIF＿LBN((ｂx＋ａx)*192/2048)になり、EXT1[x]の先頭LBNは、SSIF＿LBN((ｂx+1＋ａx)*192/2048)になる。
一方、EXT2[x]の連続長は、(SSIF＿LBN((ｂx+1＋ａx)*192/2048)−SSIF＿LBN((ｂx＋ａx)*192/2048))になる。EXT1[x]の連続長は、(SSIF＿LBN((ｂx+1＋ａx+1)*192/2048)−SSIF＿LBN((ｂx+1＋ａx)*192/2048))になる。これらの先頭LBN及び連続長を示すファイルエントリーをメモリ上で生成すれば、ファイルベース、ファイルディペンデントを仮想的に得ることができる。
【０４１８】
図４８は、エクステントスタートポイント情報のシンタックスを示す。number＿of＿extent＿unitsは、ATS区間が同一のExtent Blockの数を示す。
extent＿idを制御変数としたfor文は、base/dependent＿view＿extent＿start＿address、interleaved＿base/dependent＿view＿extent＿start＿address[extent＿id]を、number＿of＿extents＿unitだけ定義するものである。
【０４１９】
base/dependent＿view＿extent＿start＿address [extent＿id] は、LR別ファイル形式の各Extentのスタートアドレスを示す。interleaved＿base/dependent＿view＿extent＿start＿address[extent＿id] は、LR 1ファイル形式の各Extentのスタートアドレスを示す。これらのうち、base＿biew＿extent＿start＿address[extent＿id]は、ファイル先頭からの相対アドレスを示す。この相対アドレスは192byte(SPN)単位であり、32bitで768GBまで対応可能である。これは、EP＿mapを使った再生開始アドレス探索のため、SPN単位の方が判定が容易になるからである。Extentは6KBアラインしているため、6KB単位でもよい。6KB=192byte*32のため、5bitシフトで対応可能になる。そして、エクステントスタートポイント情報の構成要素であって、ソースパケット番号によってエクステントの先頭アドレスを表現するものを“SPN＿extent＿start”という。
【０４２０】
図４９は、クリップ情報ファイルにおけるエントリーマップテーブルを示す。  本図（ａ）は、エントリーマップテーブルの概略構成を示す。引出線eh1は、エントリーマップテーブルの内部構成をクローズアップして示している。この引出線に示すように、エントリーマップテーブルは、『エントリマップヘッダ情報』、『エクステント開始タイプ』、『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』を含む。
【０４２１】
『エントリマップヘッダ情報』は、エントリマップが指すビデオストリームのPIDやエントリポイント数などの情報が格納される。
『エクステント開始タイプ』は、レフトビュービデオストリーム及びライトビュービデオストリームのうち、どちらのエクステントから先にエクステントが配置されているか示す。  
【０４２２】
『PID＝0x1011についてのエントリーマップ』、『PID＝0x1012についてのエントリーマップ』、『PID＝0x1220についてのエントリーマップ』、『PID＝0x1221についてのエントリーマップ』は、複数種別のソースパケットによって構成されるPESストリームのそれぞれについてのエントリーマップである。エントリーマップにおいて、一対となるPTSとSPNとの情報を"エントリポイント"と呼ぶ。また先頭を"０"として各エントリポイント毎にインクリメントした値をエントリポイントID（以下EP＿ID）と呼ぶ。このエントリマップを利用することにより、再生機はビデオストリームの時間軸上の任意の地点に対応するソースパケット位置を特定することが出来るようになる。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。また、エントリマップはAVクリップ内に多重化される各ビデオストリーム毎に作られ、PIDで管理される。
【０４２３】
引き出し線eh2は、PID＝1011のエントリーマップの内部構成をクローズアップして示している。EP＿ID=0に対応するエントリーポイント、EP＿ID=1に対応するエントリーポイント、EP＿ID=2に対応するエントリーポイント、EP＿ID=3に対応するエントリーポイントから構成される。EP＿ID=0に対応するエントリーポイントは、オンに設定されたis＿angle＿changeフラグと、SPN=3と、PTS=80000との対応付けを示す。EP＿ID=1に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=1500と、PTS=270000との対応付けを示す。
【０４２４】
EP＿ID=2に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=3200と、PTS=360000との対応付けを示す。EP＿ID=3に対応するエントリーポイントは、オフに設定されたis＿angle＿changeフラグと、SPN=4800と、PTS=450000との対応付けを示す。is＿angle＿changeフラグは、そのエントリーポイントから独立して復号することができるか否かを示すフラグである。ビデオストリームがMVC又はMPEG4-AVCで符号化されており、エントリーポイントにIDRピクチャが存在する場合、このフラグはオンに設定される。エントリーポイントにNon-IDRピクチャが存在する場合、このフラグはオフに設定される。
【０４２５】
同図（ｂ）は、（ａ）に示したPID=1011のTSパケットに対応するエントリーマップ内の複数のエントリーマップによって、どのソースパケットを指示されるかを示す。EP＿ID=0に対応するエントリーマップは、SPN=3を指し示しており、このソースパケット番号をPTS=80000と対応付けている。EP＿ID=1に対応するエントリーマップは、SPN=1500を指し示しており、このソースパケット番号をPTS=270000に対応付けている。
【０４２６】
EP＿ID=2に対応するエントリーマップは、SPN=3200のソースパケットを指し示しており、このソースパケット番号をPTS=360000に対応付けている。EP＿ID=3に対応するエントリーマップは、SPN=4800のソースパケットを指し示しおり、このソースパケット番号をPTS=450000と対応付けている。
【０４２７】
図５０は、プログラム情報におけるストリーム属性情報を示す。
図中の引き出し線ah1は、ストリーム属性の内部構成をクローズアップして示している。
【０４２８】
この引出線に示すように、PID＝0x1011のTSパケットによって構成されるレフトビュービデオストリームのストリーム属性、PID＝0x1012のTSパケットによって構成されるライトビュービデオストリームのストリーム属性、PID＝0x1100、PID＝0x1101のTSパケットによって構成されるオーディオストリームのストリーム属性、PID=0x1220,0x1221のTSパケットによって構成されるPGストリームのストリーム属性というように、複数種別のソースパケットによって構成されるPESストリームがどのような属性をもっているかがこのストリーム属性に示されている。この引出線ah1に示すように、AVクリップに含まれる各ストリームについての属性情報が、PID毎に登録される。
【０４２９】
図５１は、エントリーマップによるエントリーポイントの登録を示す。第１段目は、SCシーケンスにて規定される時間軸を示す。第２段目は、クリップ情報におけるエントリーマップを示す。第３段目は、クリップディペンデント情報におけるエクステントスタートポイント情報、及び、クリップベース情報におけるエクステントスタートポイント情報を示す。第４段目は、ATCシーケンスを構成するソースパケット列を示す。エントリーマップが、ATCシーケンスのうち＝n1のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t1に設定しておく。そうすると、PTS=t1という時点を用いて、ATCシーケンスにおける＝n1からのランダムアクセスを再生装置に実行させることができる。またエントリーマップが、ATCシーケンスのうち＝n21のソースパケットを指定している場合、このエントリーマップのPTSには、STCシーケンスにおけるPTS=t21に設定しておく。そうすると、PTS=t21という時点を用いて、ATCシーケンスにおける＝n21からのランダムアクセスを再生装置に実行させることができる
このエントリマップを利用することにより、再生装置はビデオストリームの時間軸上の任意の地点に対応するソースパケットを特定することが出来る。例えば、早送り・巻戻しの特殊再生の際には、エントリマップに登録されるIピクチャを特定し選択して再生することによりAVクリップを解析することなく効率的に処理を行うことが出来る。
【０４３０】
また第３段目における、クリップディペンデント情報におけるエクステントスタートポイント[i]、クリップベース情報におけるエクステントスタートポイント[j]は、第４段目において、ディペンデントビュービデオストリームを構成するエクステント、ベースビュービデオストリームを構成するエクステントの先頭ソースパケット番号がどれであるかを示す。
【０４３１】
これにより、クリップディペンデント情報におけるエクステントスタートポイント[i]で示されるソースパケットから、クリップベース情報のエクステント[j]によって示されるソースパケットの直前のソースパケットまでを読み出せば、ディペンデントビュービデオストリームを構成するソースパケット列のみを抽出することができる。
【０４３２】
クリップベース情報におけるエクステントスタートポイント[j]で示されるソースパケットから、クリップディペンデント情報におけるエクステント[i+1]によって示されるソースパケットの直前のソースパケットまでを読み出せば、ベースビュービデオストリームを構成するソースパケット列のみを抽出することができる。
【０４３３】
そして、ベースビュービデオストリームを構成するソースパケット同士、ディペンデントビュービデオストリームを構成するソースパケット同士を統合すれば、ベースビュービデオストリーを構成するATCシーケンス、ディペンデントビュービデオストリームを構成するATCシーケンスを復元することができる。
【０４３４】
図５２は、立体視インターリーブドストリームファイル構成するデータブロックからATCシーケンスがどのように復元されるかを示す。
第４段目は、立体視インターリーブドストリームファイルを構成する複数のデータブロックを示し、第３段目は、メインTS、サブTSに多重化されるソースパケット列を示す。
【０４３５】
第２段目は、ディペンデントビューを構成するSTCシーケンス２、エントリーマップ、ディペンデントビューを構成するATCシーケンス２の組みを示し、第１段目は、ベースビューを構成するSTCシーケンス１、エントリーマップ、ベースビューを構成するATCシーケンス１の組みを示す。第３段目から第２段目、第１段目への矢印は、立体視インターリーブドストリームファイルにインターリーブ化されている2つのTS(メインTS、サブTS)のデータブロックからATCシーケンス１、ATCシーケンス２が復元されることを模式的に示す。これらのATCシーケンスは、クリップ情報におけるエントリーマップによって、STCシーケンスとの対応がとられる。
【０４３６】
以上が本実施形態に係る記録媒体についての説明である。続いて、再生装置の詳細について説明する。
本実施形態における再生装置の読出部は、2つの記録媒体からのソースパケット入力を受け付ける構成になっており、2つの記録媒体のそれぞれをアクセスするための2つのドライブ、これら2つのドライブから入力されたソースパケットを一旦格納してデコーダに出力するための2つのリードバッファを含む。そして、2つのドライブと、2つのリードバッファとの間に、ATCシーケンス復元部が存在する。このATCシーケンス復元部は、1つの記録媒体から読み出されたインターリーブドストリームファイル内のソースパケットから、ベースビューを構成するATCシーケンスと、ディペンデントビューストリームを構成するATCシーケンスとを分離し、2つのリードバッファのそれぞれに書き込むものである。こうすることで再生装置は、ベースビュービデオストリームを構成するATCシーケンス、ディペンデントビューストリームを構成するATCシーケンスがそれぞれ別々の記録媒体から読み出されたかのように処理することができる。図５３（ａ）は、ATCシーケンス復元部を具備した読出部の内部構成を示す。上述したように、2つのドライブと、2つのリードバッファとの間にATCシーケンス復元部が介在している。図中の矢印B0は、1つのドライブからのソースパケット入力を象徴的に示したものであり、矢印B1は、ベースビュービデオストリームを構成するATCシーケンス１の書き込み、矢印D1は、ディペンデントビューストリームを構成するATCシーケンス２の書き込みを模式的に示す。
【０４３７】
図５３（ｂ）は、ATCシーケンス復元部によって得られた2つのATCシーケンスが、どのように取り扱われるかを示す。図中の真ん中に多重分離部内に存在するPIDフィルタを示す。左側は、ATCシーケンス復元部によって得られた2つのATCシーケンスを示す。右側は、これらの2つのATCシーケンスを多重分離することで得られるベースビュービデオストリーム、ディペンデントビュービデオストリーム、ベースビューPGストリーム、ディペンデントビューPGストリーム、ベースビューIGストリーム、ディペンデントビューIGストリームを示す。これらの2つのPIDフィルタによる多重分離は、第１実施形態に示した基本ストリーム選択テーブル、拡張ストリーム選択テーブルによる。このATCシーケンス復元部は、図５４の処理をハードウェア資源に実行させるプログラムを作成することで実現される。図５４は、ATCシーケンス復元手順を示す。
【０４３８】
ステップＳ９１は、ベースビュー用のATCシーケンスをATCシーケンス１とし、ディペンデントビュー用のATCシーケンスをATCシーケンス２とする。ステップＳ９２では、変数xを1に初期化する。この変数xは、ディペンデントビューデータブロック、ベースビューデータブロックを指示する。以降、ステップＳ９４〜ステップＳ９６のループを繰り返す。
【０４３９】
変数xによって指示されるソースパケット番号bxが、ベースビューデータブロックの最後の数値nによって指示されるソースパケット番号bnであるか否かを判定し(ステップＳ９３)、もしそうでなければ、ソースパケット番号ｂx＋ａxによって指示されるソースパケット(ｂx＋ａx)から、ｂx+1＋ａxによって指示されるソースパケット(ｂx+1＋ａx)の直前のパケットまでをATCシーケンス２に追加し(ステップＳ９４)、ソースパケット(ｂx+1＋ａx)からソースパケット(ｂx+1＋ａx+1)の直前のパケットまでをATCシーケンス１に追加して(ステップＳ９５)、変数xをインクリメントする(ステップＳ９６)という処理を、ステップＳ９３がYesと判定されるまで繰り返す。
【０４４０】
ステップＳ９３がYesと判定されれば、ソースパケット番号ｂnから(number＿of＿source＿packet2-ｂn)個のソースパケットをATCシーケンス２に追加し(ステップＳ９７)、ソースパケット番号ａnから(number＿of＿source＿packet1-ａn)個のソースパケットをATCシーケンス１に追加する(ステップＳ９８)。
【０４４１】
以上のように、ATCシーケンス１、２が復元されれば、ベースビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする(ステップＳ９９)。同様に、ディペンデントビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルディペンデントを仮想的にオープンする(ステップＳ１００)。
【０４４２】
＜ファイルベースをオープンすることの技術的意義＞
ここで任意の時点からのランダムアクセスを行う際、ストリームファイル内のセクタサーチを行う必要がある。セクタサーチとは、任意の時点からのランダムアクセスを行う際、その時点に対応するソースパケットのソースパケット番号を特定して、そのソースパケット番号のソースパケットを含むセクタから、ファイルリードを行うという処理である。
【０４４３】
立体視インターリーブドストリームファイルは、一個のエクステントが大きいため、セクタサーチの探索範囲が広く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定に、かなりの処理時間を要することがある。
【０４４４】
これは、インターリーブストリームファイルは、ベースビュービデオストリームを構成するデータブロック、ディペンデントビューストリームを構成するデータブロックがインターリーブ配置されて一本の長いエクステントを構成しており、インターリーブストリームファイルのファイルエントリーのアロケーション記述子は、その長いエクステントの先頭アドレスを示しているに過ぎないとの理由による。
【０４４５】
これに対してファイルベースは、長さが短い複数のエクステントから構成されており、個々のエクステントの先頭アドレスがアロケーション記述子に示されているため、セクタサーチにあたっての探索範囲が狭く、任意の時点からのランダムアクセスが命じられた際、読み出し先となるセクタの特定が、短時間で完了する。
【０４４６】
つまり、ベースビュービデオストリームを構成するデータブロックが、ファイルベースのエクステントとして管理されており、データブロックの先頭アドレスが、ファイルベースに対応するファイルエントリーにおけるアロケーション記述子に明記されているので、ランダムアクセス位置を包含しているエクステントの先頭アドレスから、セクタサーチを開始すれば、早期にランダムアクセス位置となるソースパケットを含むセクタにまで到達することができる。
【０４４７】
このようにベースビュービデオストリームを構成するデータブロックを、ファイルベースのエクステントとして管理し、各エクステントの先頭アドレス及び連続長を、ファイルベースについてのファイルエントリーのアロケーション記述子に示しておくことにより、ベースビュービデオストリームにおける任意の時点からのランダムアクセスが高速になる。
【０４４８】
具体的なセクタサーチの手順は以下のものになる。ベースビュービデオストリームに対応するエントリーマップを用いることにより、任意の時点に対応するランダムアクセス位置であるソースパケット番号を導き出す。
【０４４９】
次に、ベースビュービデオストリームに対応するクリップ情報内のエクステントスタートポインティング情報を用いることにより、ランダムアクセス位置となるソースパケット番号を包含しているエクステントがどれであるかを特定する。
【０４５０】
更に、ファイルベースに対応するファイルエントリーのアロケーション記述子を参照すれば、ランダムアクセス位置となるソースパケット番号を包含しているエクステントの先頭セクタアドレスを特定することができる。その先頭セクタアドレスにファイルポインタを設定して、ファイルリードを行い、読み出されたソースパケットに対するパケット解析を実行することで、ランダムアクセス位置となるソースパケット番号のソースパケットを特定する。そして特定されたソースパケット番号のソースパケットを読み出す。これにより、メインTSに対するランダムアクセスが効率的に実行されることになる。サブTSも同様である。
【０４５１】
以上のように本実施形態によれば、エクステントスタートポイント情報に基づき、インターリーブドストリームファイルにおけるベースビュービデオストリームのエクステント、ディペンデントビュービデオストリームのエクステントをエクステントスタートポイント情報に基づき整列した上で多重分離部、デコーダに供するので、デコーダやプログラムは、ベースビュービデオストリームを格納したファイルベースディペンデントビュービデオストリームを格納したファイルディペンデントという2つのファイルが記録媒体に仮想的に存在するものとして扱うことができる。
【０４５２】
立体視のためのベースビュービデオストリーム、ディペンデントビュービデオストリームをインターリーブストリームファイルとして記録媒体しつつも、ベースビュービデオストリーム及びディペンデントビュービデオストリームの単体アクセスを可能にせしめるので、再生装置の処理の効率性を向上させることができる。
【０４５３】
尚、エクステントスタートポイント情報は、１バイト単位で、エクステントの先頭を示しても良いが、エクステントがECCブロックのような固定長の読み取りブロックサイズにアラインする場合は、固定長単位で指定することが望ましい。こうすることでアドレスを識別するために必要な情報量を抑えることも可能である。
【０４５４】
(第４実施形態)
本実施形態では、多重分離部、デコーダ、プレーンメモリのハードウェアスケールについて説明する。
【０４５５】
本実施形態における多重分離部は、ソースパケットデパケッタイザー、PIDフイルタとの組みを1つ以上含む。このソースパケットデパケッタイザー、PIDフイルタの組みは、ストリーム入力の系統数に応じた数だけ存在する。
【０４５６】
図５５は、多重分離部及びビデオデコーダの内部構成を示す。
同図（ａ）は、多重分離部のデコーダモデルを示す。多重分離部 (Source De-packetizer and PID filter)の組みは2つになる。これは、多重分離部が本来、2つの記録媒体からの2系統のストリーム入力を処理する構成になっているからである。2D再生モードでは、2つの記録媒体からのストリーム入力を処理することができるが、3D再生モードでは、LとR、2DとDepthという2系統のストリーム入力を処理することになる。
【０４５７】
同図（ａ）に示すように、多重分離部は、ソースデパケッタイザ２２、PIDフィルタ２３、ソースデパケッタイザ２７、PIDフィルタ２８から構成される。
ソースデパケッタイザ２２は、リードバッファ２aにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップの記録レートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
【０４５８】
PIDフィルタ２３は、ソースデパケッタイザ２２から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デコーダに出力する。
【０４５９】
ソースデパケッタイザ２６は、リードバッファ２bにソースパケットが蓄えられた場合、ATCカウンタが生成するATCの値と、ソースパケットのATS値とが同一になった瞬間に、AVクリップのシステムレートにしたがって、そのTSパケットだけをPIDフィルタに転送する。この転送にあたって、各ソースパケットのATSに応じてデコーダへの入力時刻を調整する。
【０４６０】
PIDフィルタ２７は、ソースデパケッタイザ２６から出力されたTSパケットのうち、TSパケットのPIDが、再生に必要とされるPIDに一致するものを、PIDにしたがって、各種デコーダに出力する。
【０４６１】
次にプライマリビデオデコーダ３１の内部構成について説明する。
図５５（ｂ）は、プライマリビデオデコーダの内部構成を示す。プライマリビデオデコーダ３１は、TB５１、MB５２、EB５３、TB５４、MB５５、EB５６、デコーダコア５７、バッファスイッチ５８、DPB５９、ピクチャスイッチ６０から構成される。
【０４６２】
Transport Buffer(TB)５１は、レフトビュービデオストリームを含むTSパケットがPIDフィルタ２３から出力された際、TSパケットのまま一旦蓄積されるバッファである。
Multiplexed Buffer(MB)５２は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
【０４６３】
Elementaly Buffer(EB)５３は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
Transport Buffer(TB)５４は、ライトビュービデオストリームを含むTSパケットがPIDフィルタから出力された際、TSパケットのまま一旦蓄積されるバッファである。
【０４６４】
Multiplexed Buffer(MB)５５は、TBからEBにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。TBからMBにデータが転送される際に、TSパケットのTSヘッダは取り除かれる。
【０４６５】
Elementaly Buffer(EB)５６は、符号化状態にあるビデオアクセスユニットが格納されるバッファである。MBからEBにデータが転送される際にPESヘッダが取り除かれる。
デコーダコア５７は、ビデオストリームの個々のビデオアクセスユニットを所定の復号時刻（DTS）でデコードすることによりフレーム/フィールド画像を作成する。AVクリップに多重化されるビデオストリームの圧縮符号化形式にはMPEG２、MPEG４AVC、VC１などがあるため、ストリームの属性に応じて、ビデオデコーダ５７のデコード方法は切り替えられる。ベースビュービデオストリームを構成するピクチャデータをデコードするにあたってビデオデコーダ５７は、未来方向又は過去方向に存在するピクチャデータを参照ピクチャとして利用して、動き補償を行う。そしてディペンデントビュービデオストリームを構成する個々のピクチャデータのデコードにあたってビデオデコーダ５７は、ベースビュービデオストリームを構成するピクチャデータを参照ピクチャとして利用して、動き補償を行う。こうしてピクチャデータがデコードされれば、ビデオデコーダ５７は、デコードされたフレーム/フィールド画像をDPB５９に転送し、表示時刻（PTS）のタイミングで対応するフレーム/フィールド画像をピクチャスイッチに転送する。
【０４６６】
バッファスイッチ５８は、ビデオデコーダ５７がビデオアクセスユニットをデコードする際に取得したデコードスイッチ情報を使って、次のアクセスユニットをEB５３、EB５６のどちらから引き抜くかを決定し、EB５３と、EB５６とに蓄えられたピクチャをビデオアクセスユニットに割り当てられた復号時刻（DTS）のタイミングでビデオデコーダ５７に転送する。レフトビュービデオストリームとライトビュービデオストリームのDTSは時間軸上でピクチャ単位で交互に来るように設定されているため、例えばDTSを無視して前倒しでデコードする場合、ピクチャ単位でビデオアクセスユニットをビデオデコーダ５７に転送するのが望ましい。
【０４６７】
Decoded PIcture Buffer(DPB)５９は、復号されたフレーム/フィールド画像を一時的に保持しておくバッファである。ビデオデコーダ５７が、ピクチャ間予測符号化されたPピクチャやBピクチャなどのビデオアクセスユニットをデコードする際に、既にデコードされたピクチャを参照するために利用する。
【０４６８】
ピクチャスイッチ６０は、ビデオデコーダ５７から転送されたデコード済みのフレーム/フィールド画像を、ビデオプレーンに書き込む場合、その書込先をレフトビュービデオプレーン、ライトビュービデオプレーンに切り替える。レフトビューのストリームの場合は、非圧縮のピクチャデータがレフトビュービデオプレーンに、ライトビューのストリームの場合は、非圧縮のピクチャデータがライトビュービデオプレーンに瞬時に書き出されることになる。
【０４６９】
モード切り替え時におけるビデオスデコーダの動作について述べる。LR方式の場合はL側の出力だけに切り替えれ2D表示になり、Depth方式の場合は、深度情報の処理をやめ、深度情報を付加しなけれ2D映像に切り替えることができる。ただし、LR方式とDepth方式は必要とするデータが異なるため、相互の切り替えを行う際には、デコードするストリームの再選択が必要となる。
【０４７０】
次に、再生装置におけるデコーダ及びプレーンメモリの規模について説明する。
装置構成が、１デコーダになるか、２デコーダになるか、１プレーンになるか、２プレーンになるかは、ストリーム種別と、立体視方式との組合せによって変わる。
【０４７１】
3D-LR方式を採用する場合、MVCビデオストリームが再生対象であれば、１デコーダ＋２プレーン構成になる。
3D-Depth方式を採用する場合も、１デコーダ＋２プレーン構成になり、視差画像生成器が必要になる。これはプライマリビデオストリーム、セカンダリビデオストリームでも同様である。
【０４７２】
MVCビデオストリームにおいて装置構成が1デコーダになるのは、個々の圧縮ピクチャデータのマクロブロックの動き補償を実現するにあたって、非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータを参照画像として利用するからである。デコーデッドピクチャバッファに、参照画像となる非圧縮のレフトビューピクチャデータ、及び、非圧縮のライトビューピクチャデータが格納される。
【０４７３】
以上がビデオデコーダ、ビデオプレーンについての説明である。
PGストリームにおける再生装置の構成は、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。3D-LR方式、3D-Depth方式を採用する場合、２デコーダ＋２プレーン構成になる。
【０４７４】
同じく、IGストリームにおける再生装置構成は、3D-LR方式を採用する場合、２デコーダ＋２プレーン構成になる。一方、1plane＋Offset方式を採用する場合、１デコーダ＋１プレーン構成になる。
【０４７５】
テキスト字幕ストリームにおける再生装置構成では3D-LR方式が存在せず、1plane＋Offsetモードである場合、１デコーダ＋１プレーン構成になる。3D-Depth方式である場合、１デコーダ＋２プレーン構成になる。
【０４７６】
次に、PGストリームの内部構成と、PGストリームをデコードするPGデコーダの内部構成とについて説明する。
レフトビューPGストリーム、ライトビューPGストリームは、何れも複数のディスプレイセットを含む。ディスプレイセットとは、一個の画面表示を構成する機能セグメントの集まりのことである。機能セグメントは、約2KバイトのPESパケットのペイロードに格納されてデコーダに供給され、DTS、PTSを用いて、再生制御がなされる処理単位のことである。
【０４７７】
ディスプレイセットには、以下の類型がある。
Ａ.エポックスタートのディスプレイセット
エポックスタートのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンをリセットして、メモリ管理を開始させる機能セグメントの集まりであり、画面構成に必要な機能セグメントを全て含んでいる。
【０４７８】
Ｂ.ノーマルケースのディスプレイセット
ノーマルケースのディスプレイセットとは、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理を継続したまま画面構成を行うディスプレイセットであり、先行するディスプレイセットからの差分となる機能セグメントを含んでいる。
【０４７９】
Ｃ.アクジッションポイントのディスプレイセット
アクジッションポイントのディスプレイセットとは、画面構成に必要な機能セグメントを全て含むディスプレイセットであるが、グラフィクスデコーダにおけるコンポジションバッファ、コードデータバッファ、グラフィクスプレーンのメモリ管理をリセットさせないディスプレイセットである。このアクジッションポイントのディスプレイセットには、前のディスプレイセットとは異なる内容の機能セグメントが存在してもよい。
【０４８０】
Ｄ.エポックコンティニューのディスプレイセット
エポックコンティニューのディスプレイセットとは、PGストリームの再生を許可しているプレイアイテムと、その直前のプレイアイテムとの接続形態が、クリーンブレークを伴うシームレス接続(CC=5)である場合、再生装置におけるコンポジションバッファ、コードデータバッファ、オブジェクトバッファ、グラフィクスプレーンにおけるメモリ管理を、そのまま継続させる旨を示す。この際、オブジェクトバッファ、グラフィクスプレーン上に得られたグラフィクスオブジェクトは、廃棄されることなく、オブジェクトバッファ、グラフィクスプレーン上で存続する。
【０４８１】
レフトビューと、ライトビューとでは、STCシーケンスにおける再生時間軸の同一時点に、これらのディスプレイセットの始点・終点が割り当てられている。そして、レフトビューPGストリームと、ライトビューPGストリームとでは、時間軸上の同じ時点に存在するディスプレイセットの類型は、同一になっている。つまりレフトビュー側のディスプレイセットがエポックスタートのディスプレイセットであるなら、STCシーケンスの時間軸において同じ時点のライトビュー側のディスプレイセットは、エポックスタートのディスプレイセットになる。
【０４８２】
また、レフトビュー側のディスプレイセットがアクジッションポイントのディスプレイセットであるなら、STCシーケンスの時間軸において同じ時点のライトビュー側のアクジッションポイントのディスプレイセットも、エポックスタートのディスプレイセットになる。
【０４８３】
各ディスプレイセットは、複数の機能セグメントを含む。この複数の機能セグメントには以下のものがある。
(1)オブジェクト定義セグメント
オブジェクト定義セグメントは、グラフィクスオブジェクトを定義する機能セグメントである。グラフィクス定義セグメントは、コード値と、そのコード値のランレングスとを用いることで、グラフィクスオブジェクトを定義している。
【０４８４】
(2)パレット定義セグメント
パレット定義セグメントは、各コード値と、輝度、赤色差・青色差との対応関係を示したパレットデータを含む。レフトビューグラフィクスストリームのパレット定義セグメントと、ライトビューグラフィクスストリームのパレット定義セグメントとでは、コード値と、輝度及び色差との対応関係が同一の内容に設定されている。
【０４８５】
(3)ウィンドゥ定義セグメント
ウィンドゥ定義セグメントは、非圧縮のグラフィクスオブジェクトを画面上に展開するためのプレーンメモリにおいて、ウィンドゥと呼ばれる矩形枠を定義する機能セグメントである。グラフィクスオブジェクトの描画は、このプレーンメモリの内部で制限されており、このウィンドゥの外部では、グラフィクスオブジェクトの描画は行えない。
【０４８６】
プレーンメモリの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。
【０４８７】
(4)画面構成セグメント
画面構成セグメントは、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントであり、グラフィクスデコーダにおけるコンポジションコントローラに対する複数の制御項目を含む。画面構成セグメントは、グラフィクスストリームにおけるディスプレイセットの詳細を規定すると共に、グラフィクスオブジェクトを用いた画面構成を規定する機能セグメントである。かかる画面構成には、Cut-In/Out、Fade-In/Out、Color  Change、Scroll、Wipe-In/Outといったものがあり、画面構成セグメントによる画面構成を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
【０４８８】
(5)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグメントである。再生装置は、画面構成セグメントからこのエンドセグメントまでが、1つのディスプレイセットを構成する機能セグメントであるとして解釈する。
【０４８９】
PGストリームにおいてディスプレイセットの開始時点は、画面構成セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、画面構成セグメントを格納したPESパケットのPTSによって特定される。
【０４９０】
レフトビューグラフィクスストリーム及びライトビューグラフィクスストリームは、パケッタイズドエレメンタリストリーム(PES)であり、画面構成セグメントは、PESパケットに格納され、画面構成セグメントを格納したPESパケットのPTSは、画面構成セグメントが属するディスプレイセットによる表示を何時実行するかを示す。
【０４９１】
画面構成セグメントを格納したPESパケットのPTSの値は、レフトビュービデオストリームと、ライトビュービデオストリームとで同一の内容になっている。
・PGデコーダのデコーダモデル
PGデコーダは、PGストリームから読み出されう機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
【０４９２】
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するためのトランスポートバッファが存在する。
グラフィクスデコーダの後段には、グラフィクスプレーンと、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換するCLUT部と、プレーンシフトのためのシフト部とが存在する。
【０４９３】
PGストリームにおけるパイプラインは、グラフィクスデコーダあるディスプレイセットに属するオブジェクト定義セグメントをデコードしてグラフィクスオブジェクトをオブジェクトバッファに書き込む処理と、先行するディスプレイセットに属するオブジェクト定義セグメントをデコードすることにより得られたグラフィクスオブジェクトをオブジェクトバッファからプレーンメモリに書き込む処理とを同時に実行することでなされる。
【０４９４】
図５６は、PGストリームのグラフィクスデコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモード方式で表示するためのデコーダモデルである。同図（ｂ）は、LR方式のデータを表示する場合のデコーダモデルである。
【０４９５】
本図において、グラフィクスデコーダの本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲っている。
同図（ａ）では、グラフィクスデコーダは１デコーダ構成になっており、グラフィクスプレーンも1プレーン構成になっている。しかしグラフィクスプレーンの出力が、レフトビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
【０４９６】
同図（ｂ）では、トランスポートバッファ−グラフィクスデコーダ−グラフィクスプレーン−CLUT部が2組み存在していて、レフトビューストリーム、ライトビューストリームをそれぞれ独立に処理することができる。
【０４９７】
オフセットシーケンスはディペンデントビュービデオストリームに含まれているので、プレーンオフセット形式では、グラフィクスデコーダは１デコーダ構成になり、この1つのグラフィクスデコーダの出力が、レフトビューとライトビューとに切り替えられる。
【０４９８】
PGデコーダの2D/3D切り替え時の動作は以下の通りである。
１.1plane＋Offsetモードと2Dモードとの相互切り替え時は、シームレスに切り替えられる。これは、Offsetを無効化することでなされる。
【０４９９】
２.3D-LRモードと、2Dモードとでは、PID切り替えが伴うため、一端字幕が消える。これはストリーム切り替えと同じである。
３.3D-LRモードとLモードとでは、L（BaseView側）のみの表示に切り替える。シームレスに切り替え可能だが、表示位置が偏る可能性がある。
【０５００】
3D-Depthモードと、2Dモードとでは、2D表示中もバックグラウンドで、グレースケールに示される深度情報をデコードして、レフトビューのグラフィクスオブジェクト、ライトビューのグラフィクスオブジェクトを生成しておけば、グラフィクスオブジェクトの切り替えをシームレスに行うことができる。
【０５０１】
PGデコーダでモード切り替えを実行する場合、Depthモード、1plane＋Offsetモードから2Dモードへの切り替えが容易である。しかし3D-LR方式の場合、立体視のグラフィクスオブジェクトと、2Dのグラフィクスオブジェクトとは異なるため、切り替え時に処理するPGストリームの変更が必要となり、次のPGストリームが供給されるまでグラフィクスオブジェクトが表示されない可能性が生じる。
【０５０２】
グラフィクスオブジェクトが表示されない期間を設けたくない場合には、正面から見る2Dグラフィクスオブジェクトではなく、ベースビューのグラフィクスオブジェクトのみに切り替えることも可能である。この場合すこし左に偏った映像に見える可能性が残る。立体視PGを2DPGに切り替える場合、どちらの方法を用いるか、管理データに設定しておくことも可能である。
【０５０３】
・テキスト字幕デコーダのデコーダモデル
テキスト字幕ストリームは、複数の字幕記述データから構成される。
【０５０４】
テキスト字幕デコーダは、字幕記述データから、テキストコードと、制御情報とを分離する「字幕プロセッサ」と、字幕記述データから分離されたテキストコードを格納する「管理情報バッファ」と、フォントデータを用いて、管理情報バッファ内のテキストコードをビットマップに展開する「テキストレンダー」と、展開により得られたビットマップを格納する「オブジェクトバッファ」と、字幕記述データから分離された制御情報を用いて、時間軸に沿ったテキスト字幕再生の制御を実行する「描画制御部」とを含む。
【０５０５】
テキスト字幕デコーダの前段には、フォントデータのプリロードを行う「フォントプリロードバッファ」、テキスト字幕ストリームを構成するTSパケットの入力速度を調整する「TSバッファ」、プレイアイテムの再生に先立ち、テキスト字幕ストリームをプリロードしておくための「字幕プリロードバッファ」が存在する。
【０５０６】
グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのためのシフト部が存在する。
【０５０７】
図５７は、テキスト字幕デコーダの内部構成を示す。同図（ａ）は、1plane＋Offsetモードにおけるテキスト字幕デコーダのデコーダモデルを示し、同図（ｂ）は、3D-LR方式におけるテキスト字幕デコーダのデコーダモデルを示す。本図において、テキスト字幕デコーダ本体にあたる部分は黒枠で囲こみ、テキスト字幕デコーダ後段にあたる部分は一点鎖線で囲んでいる。テキスト字幕デコーダ前段にあたる部分は、破線枠で囲んでいる。
【０５０８】
同図（ａ）では、グラフィクスプレーンの出力が、レフトビュー、ライトビューのそれぞれに別れていて、個々のレフトビュー出力、ライトビュー出力に対して、シフト部が付加される。
【０５０９】
同図（ｂ）では、レフトビュー用のグラフィクスプレーンと、ライトビュー用のグラフィクスプレーンとが存在していて、テキスト字幕デコーダによって展開されたビットマップを、これらのそれぞれのグラフィクスプレーンに書き込む。3D-LR方式のテキスト字幕デコーダでは、カラーパレット情報が拡張されており、字幕用の文字/背景/縁取り3色に加え、Depth用に3色追加されている。そして、レンダリングエンジンが字幕を描画することができる。
【０５１０】
テキスト字幕ストリームは、PGストリームと異なり、グラフィクスデータをビットマップとして送るのではなく、フォントデータと文字コードを送ることにより、レンダリングエンジンで字幕を生成するから、字幕の立体視は、1plane＋Offsetモードによって実現する。テキスト字幕を1plane＋Offsetモードで表示する場合、モードの切り替えは、フォントセットの切り替えか、レンダリング方式の切り替えによってなされる。L/RフォントセットやOpenGLフォントセットを定義することでモード切り替えを行う方法もある。レンダリングエンジンが3D表示を行う事も可能である。
【０５１１】
3D-LRモードでは、ベースビューと、ディペンデントビューとで独立したフォントセットやOpenGLフォントセットを定義することで立体視再生を実現する。また、レンダリングエンジンが3Dフォントを描画することで立体視再生を実現してもよい。
【０５１２】
3D-Depthモードの場合は、深度映像をレンダリングエンジンで生成する。
以上がテキスト字幕ストリーム及びテキスト字幕デコーダについての説明である。続いて、IGストリームの内部構成と、IGデコーダの構成とについて説明する。
【０５１３】
・IGストリーム
レフトビューIGストリーム、ライトビューIGストリームは何れも複数のディスプレイセットを含み、各ディスプレイセットは、複数の機能セグメントを含む。ディスプレイセットには、PGストリームと同様、エポックスタートのディスプレイセット、ノーマルケースのディスプレイセット、アクジッションポイントのディスプレイセット、エポックコンティニューのディスプレイセットが存在する
これらのディスプレイセットに属する複数の機能セグメントには以下の種類がある。
【０５１４】
(1)オブジェクト定義セグメント
このオブジェクト定義セグメントは、PGストリームのものと同じである但しIGストリームのグラフィクスオブジェクトは、ページのインエフェクト、アウトエフェクト、ボタン部材のノーマル状態、セレクテッド状態、アクティブ状態を定義するものである。オブジェクト定義セグメントは、ボタン部材の同じ状態を定義するもの同士、同じエフェクト映像を構成するもの同士、グループ化されている。同じ状態を定義するオブジェクト定義セグメントを寄せ集めたグループをグラフィクスデータ集合という。
【０５１５】
(2)パレット定義セグメント
パレット定義セグメントは、PGストリームのものと同じである。
(3)対話制御セグメント
対話制御セグメントは、複数のページ情報を含み、複数のページ情報は、マルチページメニューの画面構成を規定する情報であり、各ページ情報は、エフェクトシーケンスと、複数のボタン情報と、パレット識別子の参照値とを含む。
【０５１６】
ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。
【０５１７】
エフェクトシーケンスは、グラフィクスオブジェクトを用いて、ページ情報に対応するページの表示に先立ち再生されるインエフェクト、又は、当該ページの表示後に再生されるアウトエフェクトを構成するものであり、エフェクト情報を含む。
【０５１８】
エフェクト情報は、インエフェクト又はアウトエフェクトを再生するにあたっての個々の画面構成を規定する情報であり、グラフィクスプレーン上のウィンドゥ定義セグメントで定義されたウィンドゥ（部分領域）においてどのような画面構成を実行すべきかを規定する画面構成オブジェクトと、同領域における次の画面構成との時間間隔を示すエフェクト期間情報とを含む。
【０５１９】
エフェクトシーケンスにおける画面構成オブジェクトは、PGストリームの画面構成セグメントと同じような制御内容を規定する。オブジェクト定義セグメントのうち、前記インエフェクトに用いられるグラフィクスオブジェクトを定義するものは、グラフィクスデータ列において、ボタン部材に用いられるグラフィクスオブジェクトを定義するオブジェクト定義セグメントより前に配置されている。
【０５２０】
ページ情報における各ボタン情報は、グラフィクスオブジェクトをボタン部材の一状態として表示させることにより、マルチページメニューを構成する各ページ上で対話的な画面構成を実現する情報である。前記ボタン情報はセットボタンページコマンドを含み、セットボタンページコマンドは、対応するボタン部材がアクティブ状態になった際、ファーストページ以外の他のページを、カレントページとして設定する処理を再生装置に行わせるコマンドである。
【０５２１】
IGストリームの再生時において、プレーンシフトにおけるオフセットをページ毎に変更させたい場合は、ボタン情報にオフセットを変更するナビゲーションコマンド組込んでおき、該当するボタン情報において、ナビゲーションコマンドのオートアクティベートを規定しておく。これにより、IGストリームのストリーム登録情報に規定されているオフセットの値や方向を自動的に変更できるようにする。
【０５２２】
(4)エンドセグメント
1つのディスプレイセットに属する複数の機能セグメントの最後尾に位置する機能セグメントである。対話制御セグメントからこのエンドセグメントまでが、1つのディスプレイセットを構成する機能セグメントであるとして解釈される。
【０５２３】
レフトビューグラフィクスストリームと、ライトビューグラフィクスストリームとにおいて、同一となる対話制御セグメントの制御項目には、ボタン近接情報、セレクションタイムアウトタイムスタンプ、ユーザタイムアウトディレーション、コンポジションタイムアウト情報がある。
【０５２４】
１.ボタン近接情報
ボタン近接情報は、あるボタンがセレクテッド状態になっていて、上下左右方向の何れかを指示するキー操作があった場合、どのボタンをセレクテッド状態にすべきかを指定する情報である。
【０５２５】
２.セレクションタイムアウトタイムスタンプ
セレクションタイムアウトタイムスタンプは、カレントページにおけるボタン部材を自動的にアクティベートして、セットボタンページコマンドを再生装置に実行させるためのタイムアウト時間を示す。
【０５２６】
３.ユーザタイムアウトディレーション
ユーザタイムアウトディレーションは、カレントページをファーストページに戻して、ファーストページのみが表示されている状態にするためのタイムアウト時間を示す。
【０５２７】
４.コンポジションタイムアウト情報
コンポジションタイムアウト情報は、対話制御セグメントによる対話的な画面表示を終了させる時間を示す。IGストリームにおいてディスプレイセットの開始時点は、対話制御セグメントを格納したPESパケットのDTSによって特定され、ディスプレイセットの終了時点は、対話制御セグメントのコンポジションタイムアウト時刻によって特定される。レフトビュー、ライトビューでは、これらのDTSと、コンポジションタイムアウト時刻とは同一時点に設定される。
【０５２８】
・IGデコーダのデコーダモデル
IGデコーダは、IGストリームから読み出されう機能セグメントを格納する「コーデッドデータバッファ」と、画面構成セグメントをデコードしてグラフィクスオブジェクトを得る「ストリームグラフィクスプロセッサ」と、デコードにより得られたグラフィクスオブジェクトを格納する「オブジェクトバッファ」と、画面構成セグメントを格納する「コンポジションバッファ」と、コンポジションバッファに格納された画面構成セグメントを解読して、これらの画面構成セグメントにおける制御項目に基づき、オブジェクトバッファに得られたグラフィクスオブジェクトを用いてグラフィクスプレーン上で画面構成を行う「コンポジションコントローラ」とを含む。
【０５２９】
このグラフィクスプレーンの前段には、機能セグメントを構成するTSパケットの入力速度を調整するための「トランスポートバッファ」が存在する。
グラフィクスデコーダの後段には、「グラフィクスプレーン」と、パレット定義セグメントに基づいて、グラフィクスプレーンに格納されたグラフィクスオブジェクトを構成する画素コードを、輝度・色差に変換する「CLUT部」と、プレーンシフトのための「シフト部」とが存在する。
【０５３０】
図５８は、IGデコーダのデコーダモデルを示す。本図では、IGデコーダ本体にあたる部分は黒枠で囲こみ、グラフィクスデコーダ後段にあたる部分は一点鎖線で囲んでいる。IGデコーダ前段にあたる部分は、破線枠で囲んでいる。
【０５３１】
図５８（ａ）は、2D形式のIGストリームを1plane＋Offsetモード方式によってLR形式で表示するためのデコーダモデルである。同図（ｂ）は、IGストリームのデコーダモデルであるが、LR方式のデータを表示する場合のデコーダモデルである。  
【０５３２】
これらのデコーダでは、メニューグラフィクスの深度情報をプログラムから制御するために、システムパラメータの値をオフセットに反映するための回路を含んでいる。
同図（ｂ）は、2デコーダモデルであり、コマンドによりoffset値の変更が可能になる。よってメニューの深度情報をコマンドで変えることができる。Offset値は左右異なる値も与えられる。一方、Depth方式の場合、Offsetは無効になる。
【０５３３】
グラフィクスデコーダにおけるコンポジションコントローラは、対話画面に存在するボタン部材のうち、カレントボタンになるものを、セレクテッド状態に対応するグラフィクスデータ集合のグラフィクスデータを用いて表示し、それ以外のボタン部材を、ノーマル状態に対応するグラフィクスデータ集合を用いて表示することで、対話画面の初期表示を実現する。
【０５３４】
上下左右の４方向の何れかを指定する旨のユーザ操作があった場合、カレントボタンの周辺に位置するノーマル状態のボタン部材のうち、ユーザ操作により指定された方向に存在するものの番号をボタン番号レジスタに書き込み、当該書き込みによって、新たにカレントボタンになったボタン部材をノーマル状態からセレクテッド状態に変化させる。
【０５３５】
対話画面においてセレクテッド状態になっているボタン部材をアクティブ状態に変化させる旨のユーザ操作があった場合、当該アクティブ状態を構成するグラフィクスデータをグラフィクスデータ集合から取り出して表示に供することで対話画面の更新を実現する。
【０５３６】
これらの対話画面の更新は、レフトビュー、ライトビューで共通に実行にする必要があるので、２デコーダモデルにおいて、コンポジションコントローラを、レフトビュー用のグラフィクスデコーダと、ライトビュー用のグラフィクスデコーダとで共通化することが望ましい。
【０５３７】
この場合、立体視IGストリームにおけるレフトビュー・ライトビューのナビゲーションコマンドは同一化し、3D用と2D用のグラフィクスオブジェクトのボタン構成を同一にすることで、相互切り替えを実現する。
【０５３８】
2DIGストリームと、立体視IGストリームとでは、ナビゲーションコマンドおよびボタン情報の属性・数などが同じであれば、グラフィクスオブジェクトの表示のみの切り替えが可能となる。3D-LRモードからL画像のみへの切り替えでは、再ロードなしに切り替え可能だが、表示位置が偏る可能性がある。どちらを採用するかのタイトル制作者の意図をフラグに示させておき、このフラグに基づき再生装置が切り替えを行うことが望ましい。
【０５３９】
以下に、モード切り替え時における留意事項をまとめた。
・1plane＋Offsetモードと、2Dモードとの切り替えにおいては再ロードは発生しない。これはIGストリームのロードは必要ではなく、Offsetの無効化のみとなるからである。
【０５４０】
・3D-LRモードと、2Dモードとの切り替えにおいて、ストリームが異なるため、再ロードが発生する。
・  3D-Depthと2Dとの間では、プリロード時に深度情報のデコードが完了していれば再ロードは発生しない。
【０５４１】
・AV再生開始前にメモリに読み込むというプリロードモデルが採用されていたとしても、2Dモード/3Dモードの切り替えに伴い、IGストリームの再ロードが発生すれば、シームレス再生は保証されないケースが生じる。
【０５４２】
以上がIGストリーム及びIGデコーダについての説明である。続いて、プレーンメモリの詳細について説明する。
1plane＋Offsetモード方式におけるプレーンメモリ構成について説明する。
【０５４３】
プレーンメモリのレイヤ合成は、プレーンメモリのレイヤモデルにおいて、階層間のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける階層間の全ての組合せに対して実行することでなされる。合成部２０８によるレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。
【０５４４】
階層間の重畳は、ある階層に位置するプレーンメモリのライン単位の画素値に透過率αを重みとして乗じるとともに、その下位階層に位置するプレーンメモリのライン単位の画素値に（１−透過率α）という重みを乗じて  これら輝度の重み付けがなされた画素値同士を加算し、加算結果を、その階層におけるライン単位の画素の画素値とする処理である。この階層間の重畳を、レイヤモデルの隣接する2つ階層に位置するライン単位の画素同士で繰り返し実行することにより、上記レイヤ合成は実現される。
【０５４５】
プレーンメモリ後段は、上述したようなCLUT部、シフト部の他、レイヤ合成を実現するため、個々の画素値に等価率を乗算するための乗算部、画素同士の加算を行うための加算部、セカンダリビデオの位置決め・スケーリング変更を行うためのScalling&Positioning部を含む
図５９は、デコーダモデルの出力を合成し、3D-LR方式で出力するための回路構成を示す。プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、２組み存在していることがわかる。また、プレーンメモリ後段にあたる部位も、２組み存在していることがわかる。
【０５４６】
レイヤモデル、プレーンメモリ後段が2組み存在することにより、3D-LR方式におけるプレーンメモリ構成は、プライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのそれぞれが、レフトビュー用と、ライトビュー用とに別れていて、これらのプレーンメモリの出力をレイヤ合成を、レフトビュー、ライトビューのそれぞれについて実行するようになっている。
【０５４７】
セカンダリビデオプレーンでは、プライマリビデオストリームと同様に、セカンダリビデオストリームを3D-LRモードや3D-Depthモードで表示することが可能である。また、PGストリームのように2D映像にオフセットを与えて、平面の映像を手前に浮き出させて表示することも可能である。
【０５４８】
図６０は、これらのデコーダモデルの出力を合成し、1plane＋Offsetモード方式で出力するための回路構成を示している。  
レフトビュー用のプライマリビデオプレーン、ライトビュー用のプライマリビデオプレーン、PGプレーン、IGプレーン、セカンダリビデオプレーンのレイヤモデルは黒枠で囲こみ、プレーンメモリ後段にあたる部分は一点鎖線で囲んでいる。本図からも明らかなように、上述したようなレイヤモデルは、１組みだけが存在していることがわかる。また、プレーンメモリ後段にあたる部位は、２組み存在している。
【０５４９】
1plane＋Offsetモード方式では、プライマリビデオプレーンは、レフトビューのものと、ライトビューのものとが準備されている。セカンダリビデオプレーン、PGプレーン、IGプレーンについては、レフトビュー、ライトビューのそれぞれに別れておらず、レフトビュー、ライトビューで共通の１枚のプレーンメモリのみが存在する。そして、これらのレフトビュー出力、ライトビュー出力のそれぞれに対して上述したようなレイヤ合成がなされるようになっている。
【０５５０】
再生装置は、B−Dプレゼンテーションモード、1plane＋Offsetモードの双方をサポートにする必要があるので、再生装置のハードウェア構成としては、基本的に2デコーダ＋2プレーンの構成になっていて、1plane＋Offsetモード、2D再生モードに再生装置が切り替った際、１デコーダ＋１プレーンの組みのうち一方を無効化して、１デコーダ＋１プレーン構成になる。
【０５５１】
3D再生モードから2D再生モードへの切り替えが生じ再生装置の構成が、2デコーダ＋2プレーン構成から1デコーダ＋1プレーン構成に変化した場合、多重分離の対象は、Ｌ画像を構成するTSパケットのみとなる。そうすると、3D眼鏡を通じてＬ画像、Ｒ画像を視聴していたユーザは、3D再生モードから2D再生モードに切り替った途端、Ｌ画像しか見えなくなる。
【０５５２】
この場合、両目によるTVの視聴が、片目によるTVの視聴に切り替わることになり、目の負担が大きくなって、悪寒を覚えるユーザも出てくる。そこで本実施形態では、切り替った場合、PIDフィルタの対象を、Ｌ画像を構成するTSパケット、Ｒ画像を構成するTSパケットから、Ｌ画像を構成するTSパケットに切り替えると共に、グラフィクスデコーダにおけるメモリ管理をリセットする。そして、切り替えにおいて、上述したような悪寒を請じさせることがないよう、字幕を一旦消去することにする。
【０５５３】
以上のように本実施形態によれば、デコーダ構成を2デコーダ構成から1デコーダ構成に切り替える際、プレーンメモリにおける字幕を一旦リセットするので、両目によるTVの視聴が、片目によるTVの視聴に切り替わることによる目の負担をやわらげることができる。
【０５５４】
(第５実施形態)
本実施形態では、これまでの実施形態で説明した記録媒体を造るための形態、つまり、記録媒体の生産行為の形態について説明する。
【０５５５】
これまでの実施形態で説明した記録媒体は、多層化された光ディスクであるBD-ROMディスク、BD-ROMディスクと再生互換性があるようなBD-REディスク、BD-Rディスク、AVC-HDメディアとして作成することができる。
【０５５６】
図６１は、多層化された光ディスクの内部構成を示す。
第１段目は、多層化された光ディスクの一例であるBD-ROMを示し、第２段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域から構成される。これらの第１記録層の記録領域、第２記録層の記録領域、第３記録層の記録領域は、1つの連続した論理アドレス空間を構成する。
【０５５７】
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで、BD-ROMのような読み込み専用ディスクの場合には、基本的に論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。ただし、記録層の境界においては、論理アドレスが連続していたとしても連続的な読み出しはできない。そのため、層境界の論理アドレスは、予め記録装置に登録されているものとする。
【０５５８】
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROMの場合ではUDF（UniversalDisc Format）によって記録される。日常使っているPC（パーソナルコンピュータ）の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出すことが可能になっている。  
【０５５９】
第４段目は、ファイルシステムで管理されるファイルシステム領域における領域割り当てを示す。ファイルシステム領域のうち、内周側には、非AVデータ記録領域が存在する。非AVデータ記録領域の直後には、AVデータ記録領域が存在する。第５段目は、これら非AVデータ記録領域及びAVデータ記録領域の記録内容を示す。AVデータ記録領域には、AVファイルを構成する構成するエクステントが存在する。非AVデータ記録領域には、AVファイル以外の非AVファイルを構成するエクステントが存在する。
【０５６０】
図６２は、ファイルシステムを前提にした光ディスクのアプリケーションフォーマットを示す。
BDMVディレクトリはBD-ROMで扱うTSや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」，「MovieObject.bdmv」の２種類のファイルが配置されている。
【０５６１】
「index.bdmv(ファイル名固定)」は、インデックステーブルを格納している。
「MovieObject.bdmv（ファイル名固定）」は、1つ以上のムービーオブジェクトを格納している。ムービーオブジェクトは、コマンドインタプリタを制御主体とした動作モード(HDMVモード)において、再生装置が行うべき制御手順を規定するプログラムファイルであり、1つ以上のコマンドと、GUIに対するメニューコール、タイトルコールがユーザによってなされた場合、これらのコールをマスクするかどうかを規定するマスクフラグを含む。
【０５６２】
「BDJOディレクトリ」には、拡張子bdjoが付与されたプログラムファイル(xxxxx.bdjo[“xxxxx”は可変、拡張子”bdjo”は固定])が存在する。このプログラムファイルは、BD-Jモードにおいて、再生装置が行うべき制御手順を規定するBDーJオブジェクトを格納している。このBDーJオブジェクトは、「アプリケーション管理テーブル」を含む。BD-Jオブジェクト内の「アプリケーション管理テーブル」は、タイトルを生存区間としたアプリケーションシグナリングを、再生装置に行わせるためのテーブルである。アプリケーション管理テーブルは、BD-Jオブジェクトに対応するタイトルがカレントタイトルになった際、動作させるべきアプリケーションを特定する『アプリケーション識別子』と、『制御コード』とを含む。アプリケーション管理テーブルにより生存区間が規定されるBD-Jアプリケーションを、特に『BD-Jアプリケーション』という。制御コードは、AutoRunに設定された場合、このアプリケーションをヒープメモリにロードした上、自動的に起動する旨を示し、Presentに設定された場合、このアプリケーションをヒープメモリにロードした上、他のアプリケーションからのコールを待って、起動すべき旨を示す。一方、BD-Jアプリケーションの中には、タイトルが終了したとしても、その動作が終了しないアプリケーションがある。かかるアプリケーションを、“タイトルアンバウンダリアプリケーション”という。
【０５６３】
このJava（登録商標）アプリケーションの実体にあたるのが、BDMVディレクトリ配下のJARディレクトリに格納されたJava（登録商標）アーカイブファイル(YYYYY.jar)である。
アプリケーションは例えばJava（登録商標）アプリケーションであり、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。
【０５６４】
「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls[“xxxxx”は可変、拡張子”mpls”は固定])が存在する。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi [“xxxxx”は可変、拡張子”clpi”は固定])が存在する。
【０５６５】
以上のディレクトリに存在するファイルを構成するエクステントは、非AVデータ領域に記録される。
「STREAMディレクトリ」は、ストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts([“xxxxx”は可変、拡張子”m2ts”は固定])という形式でストリームファイルが格納される。
【０５６６】
上述したようなファイルは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成され、ファイルシステムによってアクセスされる領域のことである。以降、これらの領域について説明する。
【０５６７】
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号（LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
【０５６８】
次に、ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
【０５６９】
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
【０５７０】
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号（LBN）を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
【０５７１】
「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
【０５７２】
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
【０５７３】
これらのディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。
【０５７４】
「下位ファイルのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、1つ以上の「エクステント」とが記録されている。
【０５７５】
本願の主眼となるストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
【０５７６】
以上が記録媒体の内部構成についての説明である。続いて、図６１及び図６２に示した記録媒体の作り方、つまり、記録方法の形態について説明する。
本実施形態に係る記録方法は、上述したようなAVファイル、非AVファイルをリアルタイムに作成して、AVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。
【０５７７】
リアルタイムレコーディング技術により記録方法を実現する場合、当該記録方法を実行する記録装置は、リアルタイムにAVクリップを作成して、BD-RE又はBD-R、ハードディスク、半導体メモリカードに記録する。
【０５７８】
この場合AVクリップは、アナログ入力信号を記録装置がリアルタイムエンコードすることにより得られたTSであってもよいし、記録装置がデジタル入力したTSをパーシャル化することで得られるTSであってもよい。リアルタイムレコーディングを実行する記録装置は、ビデオ信号をエンコードしてビデオストリームを得るビデオエンコーダと、オーディオ信号をエンコードしてオーディオストリームを得るオーディオエンコーダと、ビデオストリーム、オーディオストリーム等を多重化して、MPEG2-TSを得るマルチプレクサと、MPEG2-TS形式のデジタルストリームを構成するTSパケットをソースパケットに変換するソースパケッタイザとを備え、ソースパケット形式に変換されたMPEG2デジタルストリームをAVクリップファイルに格納してBD-RE,BD-R等に書き込む。デジタルストリームの書き込むと共に、記録装置の制御部は、メモリ上でクリップ情報やプレイリスト情報を生成する処理を行う。具体的には、ユーザによって録画処理が要求された際、制御部は、AVクリップのストリームファイル及びクリップ情報ファイルをBD-RE,BD-R上にクリエイトする。
【０５７９】
そして、装置外部から入力されるTSからビデオストリームにおけるGOPの先頭位置が検出されるか、エンコーダによってビデオストリームのGOPが生成されれば、記録装置の制御部は、このGOPにおいて、先頭に位置するイントラピクチャのPTSと、このGOPの先頭部分を格納したソースパケットのパケット番号とを取得して、このPTS及びパケット番号の組みを、EP＿PTSエントリー及びEP＿SPNエントリーの組みとして、クリップ情報ファイルのエントリーマップに追記する。以降、GOPが生成される度に、EP＿PTSエントリー及びEP＿SPNエントリーの組みを、クリップ情報ファイルのエントリーマップに追記してゆく。この際、GOPの先頭がIDRピクチャである場合は、“オン”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。GOPの先頭がIDRピクチャでなければ場合は、“オフ”に設定されたis＿angle＿changeフラグをEP＿PTSエントリー及びEP＿SPNエントリーの組みに追加する。
【０５８０】
また、クリップ情報ファイルにおけるストリームの属性情報については、記録されるべきストリームの属性に従い設定する。以上のようにしてAVクリップ、クリップ情報が生成されてBD-RE,BD-Rに書き込まれれば、このクリップ情報内のエントリーマップを介して、再生経路を定義するプレイリスト情報を生成し、BD-RE,BD-Rに書き込む。このような処理を、リアルタイムレコーディング技術において実行することで、AVクリップ−クリップ情報−プレイリスト情報という階層構造をBD-RE,BD-R上に得ることができる。
【０５８１】
以上がリアルタイムレコーディングによる記録方法を実行する記録装置である。続いて、プレフォーマットレコーディングによる記録方法について説明する。
プレフォーマットレコーディングによる記録方法は、オーサリング行程を含むような光ディスクの製造方法となる。
【０５８２】
図６３は、光ディスクの記録方法を示す。同図（ａ）は、プレフォーマットレコーディングによる記録方法を示すフローチャートであり光ディスクの製造方法の処理手順を示す。光ディスクの製造方法は、オーサリングステップ、署名ステップ、メディア鍵取得ステップ、メディア鍵暗号ステップ、物理フォーマットステップ、識別子埋め込みステップ、マスタリングステップ、レプリケーションステップを含む。
【０５８３】
オーサリングステップS２０１は、光ディスクのボリューム領域の全体像を表すビットストリームを作成する。
署名ステップS２０２は、光ディスクの製造にあたってAACS LAに対して署名要求を行う。具体的には、ビットストリームの一ステップを抜き出し、AACS LAに送付する。ここでAACSLAは、次世代のデジタル家電機器における著作物保護技術に関するライセンスを管理する団体である。オーサリング装置を用いて光ディスクのオーサリングを行うオーサリングサイト、及び、マスタリング装置を用いてマスタリングを実行するマスタリングサイトは、AACSLAよりライセンスの提供を受ける。また、メディア鍵、無効化情報を管理する。そして、AACS LAより署名されたビットストリームの一部分を取得する。
【０５８４】
メディア鍵取得ステップS２０３は、AACS LAからメディア鍵を取得する。メディア鍵は、常に固有のものが使用されるわけではなく、これまで製造された光ディスクの枚数が一定枚数まで達すると新しいものに更新される。メディア鍵を更新することにより、特定のメーカーや機器を排除することができ、万が一暗号鍵が破られたとしても、無効化情報を用いることでそれ自体を無効化することができる。
【０５８５】
メディア鍵暗号化ステップS２０４は、メディア鍵取得ステップにより取得したメディア鍵を用いて、ビットストリームの暗号化に用いた鍵を暗号化する。
物理フォーマットステップS２０５は、ビットストリームに対して物理フォーマットを実行する。
【０５８６】
識別子埋込みステップS２０６は、光ディスクに収録されるビットストリームに、一般の機器では検出することができない一意の識別子を電子透かしとして埋め込む。これにより、不正なマスタリングによる海賊版の量産を防ぐことができる。
【０５８７】
マスタリングステップS２０７は、光ディスクの原盤を作製する。まず、ガラス基板上にフォトレジスト層を形成し、当該フォトレジスト層に対して、所望するグルーブやピットに対応するようにレーザ光を照射して露光し、現像処理を施す。このグルーブやピットは、8ー16変調されたビットストリームの各ビット値を表すものである。その後、このようなレーザカッティングによってグルーブやピットに対応した凹凸が形成されたフォトレジストを元にして、光ディスクの原盤を作製する。
【０５８８】
レプリケーションステップS２０８は、光ディスクの原盤を用いて、その複製である光ディスクを大量生産する。
図６５（ｂ）は、光ディスクを大量生産するのではなく、一般ユーザがPCを使って、BD-R,BD-RE等に、これまでの実施形態で述べた各種ファイルを記録する場合のプリフォーマットレコーディングによる記録方法の処理手順を示す。同図（ａ）と比較すると、同図（ｂ）による記録方法では、物理フォーマット(ステップ２０５)、マスタリング(ステップS２０７)、レプリケーション(ステップS２０８)が存在せず、代わりに、各ファイルの書き込み行程(ステップS２０９)が存在する。
【０５８９】
次にオーサリング行程について説明する。
図６４は、オーサリング行程の処理手順を示すフローチャートである。
ステップS１０１において、メインTS及びサブTSについてのリールセットを定義する。“リール”とは、エレメンタリストリームの素材となるデータを格納したファイルであり、オーサリングシステムでは、ローカルネットワーク上のドライブ上に存在する。3Dカメラによって撮影されたL画像やR画像、撮影時に録音された音声や、その後のアフレコで収録された音声、言語毎の字幕、メニューをデータ化したものが、これらリールに該当する。“リールセット”とは、1つのTSに多重化されるべきエレメンタリストリームの集合を表した、素材ファイルへのリンク群である。ここでは、メインTS、サブTSのそれぞれについてリールセットが定義される。
【０５９０】
ステップS１０２において、プレイアイテム、サブプレイアイテムの原型を定義し、プレイアイテム、サブプレイアイテムの再生順序を定義することでメインパス、サブパスの原型を定義する。プレイアイテムの原型の定義は、平面視再生モードにおいて、そのプレイアイテムで再生を許可すべきリールの指定と、In＿Time／Out＿Timeとの指定を、GUIを通じて受け付けることでなされる。サブプレイアイテムの原型の定義は、立体視再生モードにおいて、そのサブプレイアイテムに対応するプレイアイテムで再生を許可すべきリールの指定と、In＿Time／Out＿Timeとの指定を、GUIを通じて受け付けることでなされる。
【０５９１】
再生を許可すべきリールの指定は、リールセットにおける素材ファイルのリンクのうち、再生を許可すべきものをチェックボックスでチェックするというGUIで構成される。この際、各リールに対応付けて数値入力欄を表示する。そして、この数値入力欄によって、各リールについての優先順位を受け付け、これをリールに対応する優先順位とする。以上の再生を許可すべきリールの設定と、優先順位の設定とからストリーム選択テーブル、拡張ストリーム選択テーブルが生成されることになる。
【０５９２】
In＿Time及びOut＿Timeの指定は、GUI上で、ベースビュービデオストリーム又はディペンデントビュービデオストリームの時間軸を図形化して表示し、図形化された時間軸において、スライドバーを移動させて、そのスライドバーの位置設定をユーザから受け付けるという処理を記録装置が実行することでなされる。
【０５９３】
プレイアイテム、サブプレイアイテムの再生順序の定義は、GUI上でプレイアイテムのIn＿Timeにおけるピクチャをサムネール化して表示し、このサムネールに対して、再生順序を設定するという操作を記録装置がユーザから受け付けることでなされる。
【０５９４】
ステップS１０３では、リールセットにて指定された素材ファイルをエンコードすることにより、複数のエレメンタリストリームを得る。これらの複数のエレメンタリストリームは、ベースビュービデオストリーム、ディペンデントビュービデオストリームと、これらベースビュービデオストリーム、ディペンデントビュービデオストリームと多重化されるべきオーディオストリーム、PGストリーム、IGストリームがある。
【０５９５】
ステップS１０４では、エンコードで得られたエレメンタリストリームのうち、ベースビュービデオストリームと同じリールセットに属する同じするものを、当該ベースビュービデオストリームと多重化することで、1つのメインTSを得る。
【０５９６】
ステップS１０５では、エンコードで得られたエレメンタリストリームのうち、ディペンデントビュービデオストリームと同じリールセットに属するものを、当該ディペンデントビュービデオストリームと多重化することで、1つのサブTSを得る。
【０５９７】
ステップS１０６では、エンコード及び多重化時に設定されたパラメータを元に、クリップ情報ファイルの原型を生成する。
ステップS１０７では、プレイアイテムの原型を元にプレイアイテム情報、サブプレイアイテム情報を生成し、これらのプレイアイテム情報、サブプレイアイテム情報に再生順序を定義することで、メインパス情報、サブパス情報を生成して、プレイリスト情報を定義する。
【０５９８】
プレイアイテム情報の作成においては、メインTSに多重化されたエレメンタリストリームのうち、プレイアイテムの基本構造において平面視再生モードで再生すべきと規定されたものを再生可能に設定すべく、プレイアイテム情報内にストリーム選択テーブルを生成する。また、ベースビュービデオストリームにおける再生区間を規定するため、上述の編集作業で規定されたIn＿Time、Out＿Timeをプレイアイテム情報に記載する。
【０５９９】
サブプレイアイテム情報の作成においては、サブTSに多重化されたエレメンタリストリームのうち、プレイアイテムの基本構造において立体視再生モードで再生すべきと規定されたものを再生可能に設定すべく、プレイリスト情報のエクステンションデータ内に拡張ストリーム選択テーブルを生成する。プレイアイテム情報、サブプレイアイテム情報は、クリップ情報ファイル内の情報を元に定義されるからクリップ情報ファイルの原型を元にして設定される。
【０６００】
ステップS１０８では、メインTS、サブTS、クリップ情報ファイルの原型、プレイリスト情報の原型を、所定のアプリケーションフォーマットに従ったディレクトリーファイル群に変換する。
【０６０１】
以上の過程を得て、メインTS、サブTS、クリップ情報、プレイアイテム情報、サブプレイアイテム情報が生成されれば、メインTS、サブTSをそれぞれ独立したストリームファイルに変換し、クリップ情報をクリップ情報ファイルに変換し、プレイアイテム情報及びサブプレイアイテム情報をプレイリスト情報ファイルに変換することで、記録媒体に記録されるべき一連のファイルセットを得る。
【０６０２】
線形関数、放物線関数の関数式から、各フレーム毎の奥行きを算出する場合、ビデオストリームのフレーム時刻から、フレーム時刻毎の奥行きを導く関数を、記録装置のアプリケーションプログラムインターフェイスに定義しておき、この関数に、ベースビュービデオストリームのフレーム時刻を与えて、各フレーム時刻毎の奥行きを算出する。そして、算出されたそれぞれの奥行きを、プレーンオフセット値、オフセット方向情報に変換する。
【０６０３】
その後、ビデオストリームのエンコード行程の実行にあたって、上記変換で得たプレーンオフセット値、オフセット方向情報を、各GOPのメタデータに記載すれば、オフセットシーケンスは、エンコードの過程で作成しておくことができる。
【０６０４】
図６５は、AVファイル書込工程の処理手順を示す。リアルタイムレコーディングによる記録方法や、マスタリング、レプリケーションを伴い記録方法の実施では、AVファイルの書き込みを、本図のフローチャートによって実現する。
【０６０５】
ステップＳ４０１において、xxxxx.ssifをクリエイトして、記録装置のメモリ上にファイルエントリーを作成する。ステップＳ４０２は、空きの連続セクタ領域を確保し得たかどうかの判定であり、確保し得たなら、ステップＳ４０３において、空きの連続セクタ領域にディペンデントビューデータブロックを構成するソースパケット列をEXT2[i]だけ書き込み、その後、ステップＳ４０４〜ステップＳ４０８を実行する。確保し得ない場合は、ステップＳ４０９で例外処理をした後、記録方法を終了する。
【０６０６】
ステップＳ４０４〜ステップＳ４０８は、ステップＳ４０７がNoと判定されるまで、ステップＳ４０４〜ステップＳ４０６、ステップＳ４０８の処理を繰り返すループを構成している。
【０６０７】
ステップＳ４０５は、空きの連続セクタ領域に、ベースビューデータブロックを構成するソースパケット列をEXT1[i]だけ書き込む。ステップＳ４０６は、ソースパケット列が書き込まれた先頭アドレス及び連続長を示すアロケーション識別子をファイルエントリーに追記して、エクステントとして登録する。これに伴い、書き込まれたソースパケット列の先頭ソースパケット番号を指し示すエクステントスタートポイント情報を、クリップベース情報、クリップディペンデント情報内のメタデータに追記する。
【０６０８】
ステップＳ４０７は、ループの終了条件を規定するものであり、ベースビューデータブロック、ディペンデントビューデータブロックに未書込のソースパケットが存在するかどうかの判定を行う。存在すれば、ステップＳ４０８に移行して、ループを継続する。存在しなければ、ステップＳ４１０に移行する。
【０６０９】
ステップＳ４０８は、連続セクタ領域が存在するかどうかの判定であり、存在すれば、ステップＳ４０３に移行し、存在しなければ、ステップＳ４０２まで戻る。
ステップＳ４１０では、xxxxx.ssifをクローズして、ファイルエントリーを記録媒体に書き込む。ステップＳ４１１では、xxxxx.m2tsをクリエイトして、メモリにxxxxx.m2tsのファイルエントリーを生成する。ステップＳ４１２では、ファイル2Dで固有となるベースビューデータブロックの先頭アドレス及び連続長を示すアロケーション記述子をxxxxx.m2tsのファイルエントリーに追記する。ステップＳ４１３では、xxxxx.m2tsをクローズして、ファイルエントリーを書き込む。
【０６１０】
ステップＳ４０４は、EXTSS＋EXT2Dの範囲内に、ロングジャンプの発生地点が存在するかどうかの判定である。ここでのロングジャンプの発生地点は、層境界であるものとする。EXTSS＋EXT2Dの範囲内に層境界が存在する場合、ステップＳ４２０において、ベースビューデータブロックを複製して、ベースビューデータブロックB[i]ssと、ベースビューデータブロックB[i]2Dとをロングジャンプ発生地点の直前までに書き込み、その後、ステップＳ４０６に移行する。これらが、ファイル2Dのエクステント、ファイルベースのエクステントになる。
【０６１１】
次に、オーサリングステップの作業に用いられる記録装置について説明する。ここで説明する記録装置は、映画コンテンツの頒布のために制作スタジオに設置され、オーサリングスタッフの使用に供される。オーサリングスタッフからの操作に従い、MPEG規格に従い圧縮符号化されたデジタルストリーム及びどのように映画タイトルを再生するかを記したシナリオを生成し、これらのデータを含むBD-ROM向けのボリュームビットストリームを生成して、マスタリングサイトに引き渡すための記録媒体に記録するというのが、本発明にかかる記録装置の使用形態である。
【０６１２】
図６６は、記録装置の内部構成を示す。本図に示すように、記録装置は、ビデオエンコーダ５０１、素材制作部５０２、シナリオ生成部５０３、BDプログラム制作部５０４、多重化処理部５０５、フォーマット処理部５０６により構成される。
【０６１３】
ビデオエンコーダ５０１は、レフトビューの非圧縮のビットマップなどの画像イメージと、ライトビューの非圧縮のビットマップなどの画像イメージからMPEG４-AVCやMPEG２などの圧縮方式に従い符号化し、レフトビュービデオストリームとライトビュービデオストリームを作成する。この時、ライトビュービデオストリームは、レフトビュービデオストリームの表示時刻で対応するフレームとピクチャ間予測符号化により符号化する。このピクチャ間予測符号化の処理の過程で、レフトビューのイメージとライトビューのイメージの動きベクトルから、3D映像時の奥行き情報を抽出し、フレーム奥行き情報格納部５０１aに書き込む。ビデオエンコーダ５０１は、ピクチャ間の相関特性を利用した画像圧縮をするために、８x８や１６x１６のマクロブロック単位で動きベクトルを抽出して画像圧縮を行う。
【０６１４】
マクロブロックでの動きベクトルを抽出する処理において、背景に家が存在し、前景に人が存在する動画像を、動きベクトル抽出の対象とする。この場合、左目画像と右目画像とでピクチャ間予測を行う。そうすると、「家」のイメージの箇所には動きベクトルが検出されないが、「人」の箇所では動きベクトルが検出される。
【０６１５】
検出された動きベクトルを抽出して、3D映像を表示した際のフレーム単位の奥行き情報を作成する。奥行き情報は、例えば、８ビットの深度を持つフレームの解像度と同じイメージを採用することが考えられる。
【０６１６】
素材制作部５０２は、オーディオストリーム、PGストリーム、IGストリームなどの各ストリームを作成して、オーディオストリーム格納部５０２a、IGストリーム格納部５０２b、PGストリーム格納部５０２cに書き込む。
【０６１７】
オーディオストリーム作成にあたって素材制作部５０２は、非圧縮のLinearPCM音声などをAC３などの圧縮方式に従い符号化することでオーディオストリームを作成する。その他にも素材制作部５０２は、字幕イメージと表示タイミング、およびフェードイン/フェードアウトなどの字幕の効果を含む字幕情報ファイルを元にして、BD-ROM規格に準拠したPGストリームのフォーマットであるPGストリームを作成する。素材制作部５０２は、メニューに使うビットマップイメージと、メニューに配置されるボタンの遷移や表示効果を記載したメニューファイルを元にして、BD-ROM規格に準拠したメニュー画面のフォーマットであるIGストリームを作成する。
【０６１８】
シナリオ生成部５０３は、素材制作部５０２で作成した各ストリームの情報や、オーサリングスタッフからのGUIを経由した操作にしたがって、BD-ROMフォーマットでシナリオを作成する。ここで言うシナリオは、インデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルがそれにあたる。また、シナリオ生成部５０３は、多重化処理を実現するための各AVクリップがどのストリームから構成されるかを記述したパラメータファイルを作成する。ここで作成されるインデックスファイル、ムービーオブジェクトファイル、プレイリストファイルなどのファイルは第１実施形態１および第２実施形態で説明したデータ構造となる。
【０６１９】
BDプログラム制作部５０４は、GUI等のユーザインターフェースを通じて、ユーザからの要求に従って、BDプログラムファイルのソースコードを作成し、BDプログラムを作成する。この時、BDプログラムファイルのプログラムがGFXプレーンの奥行きを設定するために、ビデオエンコーダ５０１が出力した奥行き情報を利用することができる。
【０６２０】
多重化処理部５０５は、BD-ROMシナリオデータに記述されているレフトビュービデオストリーム、ライトビュービデオストリーム、ビデオ、オーディオ、字幕、ボタンなどの複数のストリームを多重化して、MPEG２-TS形式のAVクリップを作成する。このとき、AVクリップと対になるクリップ情報ファイルも同時に作成する。
【０６２１】
多重化処理部５０５は、自ら生成したエントリマップと、AVクリップに含まれるストリーム毎の音声属性、映像属性などを示す属性情報をペアにしてクリップ情報ファイルを作成する。クリップ情報ファイルの構成はこれまでの各実施の形態で説明したデータ構造となる。
【０６２２】
フォーマット処理部５０６は、シナリオ生成部５０３で生成したBD-ROMシナリオデータと、BDプログラム制作部５０４で制作したBDプログラムファイル、多重化処理部５０５で生成したAVクリップやクリップ情報ファイルや、BD-ROM規格に準拠したフォーマットでファイルやディレクトリを配置し、BD-ROM規格に準拠したファイルシステムであるUDFのフォーマットでディスクイメージを作成して、ディスクイメージを表すビットストリームをBD-ROMビットストリーム格納部５０７に書き込む。
【０６２３】
また、この時ビデオエンコーダ５０１が出力した奥行き情報を利用し、PG、IG、セカンダリビデオストリームの3Dメタデータを作成する。3D映像の物体と重ならないようにイメージの画面上の配置を自動で設定したり、奥行きが重ならないようにオフセット値を調整する。こうして作成されたディスクイメージのファイルレイアウトはこれまでに説明したファイルレイアウトのデータ構造で設定する。生成したディスクイメージをBD-ROMプレス用データに変換し、このデータに対してプレス工程を行うことで、BD-ROMの製造が可能となる。
【０６２４】
(第６実施形態)
本実施形態では、これまでの実施形態で説明した再生装置の機能を統合した、2D/3D再生装置の内部構成について説明する。
【０６２５】
図６７は、2D/3D再生装置の構成を示している。2D/3D再生装置は、BD-ROMドライブ１、リードバッファ２a、リードバッファ２b、スイッチ３、システムターゲットデコーダ４、プレーンメモリセット５a、プレーン合成部５b、HDMI送受信部６、再生制御部７、管理情報メモリ９、レジスタセット１０、プログラム実行部１１、プログラムメモリ１２、HDMVモジュール１３、BD-Jプラットフォーム１４、ミドルウェア１５、モード管理モジュール１６、ユーザイベント処理部１７、ローカルストレージ１８、不揮発メモリ１９から構成されている。
【０６２６】
BD-ROMドライブ１は、2D再生装置と同様に再生制御部７からの要求を元にBD-ROMディスクからデータを読み出すが、BD-ROMディスクから読み出されたAVクリップはリードバッファ２aかリードバッファ２bに転送される。
【０６２７】
3D映像を再生する際には、再生制御部７からはベースビューデータブロックとディペンデントビューデータブロックとをエクステント単位で交互に読み出す旨を指示する読出要求が送られる。BD-ROMドライブ１は、ベースビューデータブロックを構成するエクステントをリードバッファ２aに読み出し、ディペンデントビューデータブロックを構成するエクステントをリードバッファ２bに読み出す。3D映像を再生する際には、ベースビューデータブロックとディペンデントビューデータブロックの両方を同時に読み込む必要があるため、2D再生装置のBD-ROMドライブ以上のスピード性能が求められる。
【０６２８】
リードバッファ２aは、BD-ROMドライブ１が読み込んだベースビューデータブロックのデータを格納するデュアルポートメモリ等で構成されたバッファである。
リードバッファ２bは、BD-ROMドライブ１が読み込んだディペンデントビューデータブロックのデータを格納するデュアルポートメモリ等で構成されたバッファである。
【０６２９】
スイッチ３は、リードバッファに対するデータ入力源を、BD-ROMドライブ１又はローカルストレージ１８の何れかに切り替えるためのスイッチである。
システムターゲットデコーダ４は、リードバッファ２aに読み出されたソースパケットとリードバッファ２bに読み出されたソースパケットに対して多重分離処理を行いストリームのデコード処理を行う。
【０６３０】
プレーンメモリセット５aは、複数のプレーンメモリから構成される。プレーンメモリには、レフトビュービデオプレーン、ライトビュービデオプレーン、セカンダリビデオプレーン、IGプレーン、PGプレーンといったものがある。
【０６３１】
プレーン合成部５bは、これまでの実施形態で説明したプレーン合成を行う。テレビなどへの出力する場合には3Dの方式に合わせた出力を行う。シャッタメガネを利用して交互に左目イメージ・右目イメージを再生することが必要な場合はそのまま出力し、例えばレンチキュラーのテレビに出力する場合は、テンポラリのバッファを用意して、先に転送される左目イメージをテンポラリバッファに格納して、右目イメージが転送された後に同時に出力する。
【０６３２】
HDMI送受信部６は、例えばHDMI規格（HDMI:High Definition Multimedia Interface）において、第１実施形態に述べた認証フェーズ、ネゴシエーションフェーズを実行する。ネゴシエーションフェーズでは、立体視表示に対応しているかに関する情報、平面表示可能な解像度に関する情報、立体表示可能な解像度に関する情報をテレビから受け取ることができる。
【０６３３】
再生制御部７は、再生エンジン７a、再生制御エンジン７bを含み、3Dプレイリストの再生がプログラム実行部１１などから命じられると、3Dプレイリストの中で再生対象となるプレイアイテムのベースビューデータブロックを特定し、そのプレイアイテムと同期して再生される3D用のサブパスのサブプレイアイテムのディペンデントビューデータブロックを特定する。その後、対応するクリップ情報ファイルのエントリマップを解釈し、どちらのエクステントから先にエクステントが配置されているか示すエクステント開始タイプに基づき、再生開始地点からベースビューデータブロックのエクステントと、ディペンデントビューデータブロックのエクステントとを交互に読み出すようにBD-ROMドライブ１に要求する。再生開始するときには、最初のエクステントをリードバッファ２aか、リードバッファ２bに読みきった後に、リードバッファ２aとリードバッファ２bからシステムターゲットデコーダ４に転送を開始する。
【０６３４】
再生エンジン７aは、AV再生機能を実行する。AV再生機能とは、DVD再生装置、CD再生装置から踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、セカンダリビデオ用のピクチャデータ切り替え、アングル切り替えといった処理である。
【０６３５】
再生制御エンジン７bは、HDMVモードの動作主体であるコマンドインタプリタ、BD-Jモードの動作主体であるJavaプラットフォームからの関数呼び出しに応じて、プレイリストの再生機能を実行する。プレイリスト再生機能とは、上述したAV再生機能のうち、再生開始や再生停止をカレントプレイリストを構成するカレントプレイリスト情報、カレントクリップ情報に従って行うことをいう。
【０６３６】
管理情報メモリ９は、カレントプレイリスト情報やカレントクリップ情報を格納しておくためのメモリである。カレントプレイリスト情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントクリップ情報とは、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブからアクセスできる複数クリップ情報のうち、現在処理対象になっているものをいう。
【０６３７】
再生状態／設定レジスタ(Player Status/Setting Register)セット１０は、これまでの実施形態で述べた再生状態レジスタ、再生設定レジスタの他、プログラムファイルが利用する任意の情報を格納できる汎用レジスタを含む。
【０６３８】
プログラム実行部１１は、BDプログラムファイルに格納されたプログラムを実行するプロセッサである。格納されたプログラムに従って動作を行い、次のような制御を行う。（１）再生制御部７に対してプレイリスト再生を命令する。（２）システムターゲットデコーダに対してメニューやゲームのグラフィクスのためのPNG・JPEGを転送して画面に表示する。これらはプログラムの作りに応じて自由に行うことができ、どのように制御するかは、オーサリング工程によるBD-Jアプリケーションのプログラミング工程によって決まる。
【０６３９】
プログラムメモリ１２は、カレント動的シナリオを格納しておき、HDMVモードの動作主体であるHDMVモジュール、BD-Jモードの動作主体であるJavaプラットフォームによる処理に供されるメモリである。カレント動的シナリオとは、BD-ROMに記録されているIndex.bdmv、BD-Jオブジェクト、ムービーブジェクトのうち、現在実行対象になっているものをいう。またプログラムメモリ１２は、ヒープメモリを含む。
【０６４０】
ヒープメモリは、システムアプリケーションのバイトコード、BD-Jアプリケーションのバイトコード、システムアプリケーションが利用するシステムパラメータ、BD-Jアプリケーションが利用するアプリケーションパラメータが配置されるスタック領域である
HDMVモジュール１３は、HDMVモードの動作主体となるDVD仮想プレーヤであり、HDMVモードの実行主体となる。本モジュールは、コマンドインタプリタを具備し、ムービーオブジェクトを構成するナビゲーションコマンドを解読して実行することでHDMVモードの制御を実行する。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、DVD-Videoライクな再生制御を実現することができる。
【０６４１】
BD-Jプラットフォーム１４は、BD-Jモードの動作主体であるJavaプラットフォームであり、Java2Micro＿Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM1.0.2)for package media targetsとをフル実装しており、クラスローダ、バイトコードインタプリタ、アプリケーションマネージャから構成される。
【０６４２】
クラスローダは、システムアプリケーションの1つであり、JARアーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、BD-Jアプリケーションのロードを行う。
【０６４３】
バイトコードインタプリタは、いわゆるJava仮想マシンであり、ヒープメモリに格納されているBD-Jアプリケーションを構成するバイトコード、システムアプリケーションを構成するバイトコードをネィティブコードに変換して、MPUに実行させる。
【０６４４】
アプリケーションマネージャは、システムアプリケーションの1つであり、BD-Jオブジェクト内のアプリケーション管理テーブルに基づき、BD-Jアプリケーションを起動したりBD-Jアプリケーションを終了したりする等、BD-Jアプリケーションのアプリケーションシグナリングを行う。以上で、BD-Jプラットフォーム部の内部構成についての説明を終える。
【０６４５】
ミドルウェア１５は、組込みソフトウェアのためのオペレーティングシステムであり、カーネル、デバイスドライバから構成される。カーネルは、BD-Jアプリケーションからのアプリケーションプログラミングインターフェイス(API)のコールに応じて、再生装置特有の機能をBD-Jアプリケーションに提供する。また、割込信号により割込ハンドラ部を起動する等のハードウェア制御を実現する。
【０６４６】
モード管理モジュール１６は、BD-ROMまたはビルドインメディアドライブ、リムーバブルメディアドライブから読み出されたIndex.bdmvを保持して、モード管理及び分岐制御を行う。モード管理モジュールによるモード管理とは、動的シナリオを、BD-Jプラットフォーム２２、HDMVモジュールのどちらに実行させるかという、モジュールの割り当てである。
【０６４７】
ユーザイベント処理部１７は、リモコンを通じたユーザ操作に応答して、プログラム実行部１６や再生制御部７に処理の実行を依頼する。例えば、リモコンでボタンを押した場合は、そのボタンに含まれるコマンドを実行するようプログラム実行部１６に依頼する。例えば、リモコンで早送り・巻戻しボタンが押された場合には、再生制御部７に、現在再生しているプレイリストのAVクリップに対する早送り・巻戻し処理の実行を命令する。
【０６４８】
ローカルストレージ１８は、ハードディスクをアクセスするためのビルドインメディアドライブ、半導体メモリカードをアクセスするためのリムーバブルメディアドライブを備え、ダウンロードしてきた追加コンテンツやアプリケーションが使うデータなどの保存に用いられる。追加コンテンツの保存領域はBD-ROM毎に分かれており、またアプリケーションがデータの保持に使用できる領域はアプリケーション毎に分かれている。
【０６４９】
不揮発メモリ１９は、読み書き可能なメモリなどの記録媒体であり、電源が供給されなくても、記録内容を保持できる媒体、例えばフラッシュメモリ、FeRAMなどである。これは、レジスタセット１０における記憶内容のバックアップに用いられる。
【０６５０】
次に、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成について説明する。図６８は、システムターゲットデコーダ４及びプレーンメモリセット５aの内部構成を示す。本図に示すように、システムターゲットデコーダ４及びプレーンメモリセット５aは、ATCカウンタ２１、ソースデパケッタイザ２２、PIDフィルタ２３、STCカウンタ２４、ATCカウンタ２５、ソースデパケッタイザ２６、PIDフィルタ２７、プライマリビデオデコーダ３１、レフトビュービデオプレーン３２、ライトビュービデオプレーン３３、セカンダリビデオデコーダ３４、セカンダリビデオプレーン３５、PGデコーダ３６、PGプレーン３７、IGデコーダ３８、IGプレーン３９、プライマリオーディオデコーダ４０、セカンダリオーディオデコーダ４１、ミキサー４２、レンダリングエンジン４３、GFXプレーン４４から構成される。
【０６５１】
プライマリビデオデコーダ３１は、レフトビュービデオストリームをデコードして、デコード結果である非圧縮のビデオフレームをレフトビュービデオプレーン３２に書き込む。
【０６５２】
レフトビュービデオプレーン３２は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
ライトビュービデオプレーン３３は、例えば、1920×2160(1280×1440)といった解像度によってピクチャデータを格納することができるプレーンメモリである。
【０６５３】
セカンダリビデオデコーダ３４は、プライマリビデオデコーダと同様の構成を持ち、入力されるセカンダリビデオストリームのデコードを行い、表示時刻（PTS）のタイミングでピクチャをセカンダリビデオプレーンに書き出す。
【０６５４】
セカンダリビデオプレーン３５は、システムターゲットデコーダ４からセカンダリビデオストリームがデコードされたセカンダリビデオ用のピクチャデータ用データが出力される。
【０６５５】
PGデコーダ３６は、ソースデパケタイザから入力される複数のTSパケットからPGストリームを抽出してデコードし、非圧縮のグラフィクスデータを表示時刻（PTS）のタイミングでPGプレーンに書き出す。
【０６５６】
PGプレーン３７には、PGストリームをデコードすることで得られた非圧縮のグラフィクスオブジェクトが格納される。
IGデコーダ３８は、ソースパケタイザから入力される複数のTSパケットからIGストリームを抽出してデコードし、非圧縮のグラフィクスオブジェクトを表示時刻（PTS）のタイミングでIGプレーンに書き出す。
【０６５７】
IGプレーン３９には、IGストリームをデコードすることで得られたグラフィクスデータが格納される。
プライマリオーディオデコーダ４０は、プライマリオーディオストリームをデコードする。
【０６５８】
セカンダリオーディオデコーダ４１は、セカンダリオーディオストリームをデコードする。
ミキサー４２は、プライマリオーディオデコーダ４０のデコード結果と、セカンダリオーディオデコーダ４１のデコード結果とを合成する。
【０６５９】
レンダリングエンジン４３は、Java2D，OPEN-GLといった基盤ソフトウェアを備え、BD-Jアプリケーションから要求に従ってJPEGデータ／PNGデータのデコードを行い、イメージやウィジェットを得て、IGプレーン及びバックグラウンドグラフィクスプレーンに書き込む。JPEGデータをデコードすることにより得られる画像データは、GUIの壁紙になるものであり、バックグラウンドグラフィクスプレーンに着込まれる。PNGデータをデコードすることにより得られる画素データは、IGプレーンに書き込まれて、アニメーションを伴うボタン表示を実現することができる。これらJPEGデータ／PNGデータをデコードすることで得られたイメージやウィジェットは、BD-Jアプリケーションが、タイトル選択や字幕選択、音声選択を受け付けるためのメニューを表示したり、ストリーム再生連動型のゲームを動作させるにあたって、GUI部品を構成するために使われる。その他、BD-JアプリケーションがWWWサイトをアクセスする際、そのWWWサイトのブラウザ画面を構成するために用いられる。
【０６６０】
GFXプレーン４４は、JPEG，PNGなどのグラフィクスデータがデコードされた後、書き込まれるプレーンメモリである。
レンダリングメモリ４５は、レンダリングエンジンによってデコードされるべきPNGデータ、JPEGデータが読み込まれるメモリである。このイメージメモリには、BD-Jアプリケーションが、ライブ再生モードを実行する際、キャッシュ領域が確保される。ライブ再生モードとは、ネットワーク上に存在するWWWサイトのブラウザ画面と、BD-ROMによるストリーム再生とを組み合わせるものであり、キャッシュ領域は、ライブ再生モード時における現在のブラウザ画面、及び、直前のブラウザ画面をキャッシュしておくためのキャッシュメモリであり、非圧縮のPNGデータ又は非圧縮のJPEGデータであって、前記ブラウザ画面を構成するものがここに格納されることになる。
【０６６１】
以上のように本実施形態によれば、これまでの実施形態で述べた特徴を包含した記録媒体をBD-ROMとして実現することができ、また、これまでの実施形態で述べた特徴を包含した再生装置をBD-ROM再生装置として実現することができる。
【０６６２】
(第７実施形態)
本実施形態では、レジスタセットの詳細について説明する。
レジスタセットは、複数のプレーヤ状態レジスタ、複数のプレーヤ設定レジスタから構成される。個々のプレーヤ状態レジスタ、プレーヤ設定レジスタは何れも語長が３２ビットのレジスタであり、３２ビット長のレジスタのそれぞれにはレジスタ番号が与えられ、このレジスタ番号を用いてアクセスすべきレジスタが特定される。
【０６６３】
各レジスタの一語(３２ビット)を構成する各ビットデータのビット位置は、b0〜b31と呼ばれる。最上位ビットはb31、最下位ビットはb0と呼ぶ。そして、32ビットのうち、bxビット目のビット位置からbyビット目のビット位置までのビット範囲は、[bx:by]という表記で表現される。
【０６６４】
所定のレジスタ番号のプレーヤ設定レジスタ／プレーヤ状態レジスタに格納されている32ビット長のビット列であって、任意のビット範囲[bx:by]のものの値は、プログラムが動作を行うにあたっての動作システムの環境変数(システムパラメータ又はプレーヤ変数という)として扱われる。再生制御を行うプログラムは、システムプロパティやアプリケーションプログラミングインターフェイス(API)を通じて、システムパラメータを取得することができる。また、特に禁止されていない限り、これらのプレーヤ状態レジスタ、プレーヤ設定レジスタの値をプログラムは書き換えることができる。BD-Jアプリケーションについては、システムパラメータの取得や書き換えについて正当権限が、JARアーカイブファイルにおけるパーミッション管理テーブルによって与えられていることが要件になる。
【０６６５】
プレーヤ状態レジスタは、再生装置のMPUが算術演算やビット演算を行う際、その被演算子となる数値を格納しておくためのハードウェア資源であり、光ディスクが装填された際に初期値が設定され、またカレントプレイアイテムの変更等、再生装置の状態が変化した際に、その格納値の有効性が判定されるレジスタである。この格納値としては、カレントのタイトル番号、カレントのプレイリスト番号、カレントのプレイアイテム番号、カレントのストリーム番号、カレントのチャプター番号等がある。光ディスクの装填時に初期値が格納されるので、この格納値は一時的なものであり、光ディスクがイジェクトされたり、また再生装置の電源が断たれれば、この格納値は有効性を失う。
【０６６６】
プレーヤ設定レジスタは、電源対策が施されている点がプレーヤ状態レジスタとは異なる。電源対策が施されているので、再生装置の電源遮断時において、その格納値が不揮発性のメモリに退避され、再生装置の電源投入時において、その格納値が復帰される。再生装置の製造主体(マニフャクチャ)が再生装置の出荷時に定めた再生装置の各種コンフィグレーションや、ユーザがセットアップ手順に従い設定した各種コンフィグレーション、そして、再生装置がTVシステムやステレオ、アンプ等のホームシアターシステムの機器と接続された際、接続相手となる機器とのネゴシエーションにより判明した相手側機器のケーパビリティがプレーヤ設定レジスタに設定される。
【０６６７】
図６９は、レジスタセット１０の内部構成と、再生制御エンジン７bとを描いた図である。
本図の左側にはレジスタセット１０の内部構成を示している。右側には再生制御エンジン７bの内部構成を示している。
【０６６８】
それぞれのレジスタ番号が割り当てられたプレーヤ状態レジスタ、プレーヤ設定レジスタは、どのようなものであるかを示す。
PSR1は、オーディオストリームのためのストリーム番号レジスタであり、カレントのオーディオストリーム番号を格納する。
【０６６９】
PSR2は、PGストリームのためのストリーム番号レジスタであり、カレントのPGストリーム番号を格納する。
PSR4は、1〜100の値に設定されることで、カレントのタイトル番号を示す。
【０６７０】
PSR5は、1〜999の値に設定されることで、カレントのチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、カレントプレイリストの番号を示す。
【０６７１】
PSR7は、0〜255の値に設定されることで、カレントプレイアイテムの番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM)を示す。以上がPSRについての説明である。
【０６７２】
PSR10は、IGストリームのためのストリーム番号レジスタであり、カレントのIGストリーム番号を格納する。PSR21は、ユーザが、立体視再生を実行することを意図しているかどうかを示す。
【０６７３】
PSR22は、出力モード値を示す。
PSR23は、“Display Capability for video”の設定である。これは、再生装置の接続相手である表示装置に立体視再生を実行する能力が存在するかどうかを示す。
【０６７４】
PSR24は、“Player Capability for 3D”の設定である。これは、再生装置に立体視再生を実行する能力が存在するかどうかを示す。
一方、再生制御エンジン７bの内部には、レジスタセット１０におけるPSR4,PSR6,PSR21,PSR23と、管理情報メモリ９におけるカレントプレイリスト情報のストリーム選択テーブルとを参照して、カレントプレイリストにおける出力モードを一意に定めるプロシージャ実行部８を備えている。PSR24におけるPlayerCapability for 3Dは、再生装置の3D再生に関する能力全般を意味するものなので、“3D-Capability”と簡単に表記する場合がある。
【０６７５】
PSR23は、出力モードを規定するものであり、その状態遷移の選択モデルは、図７０に示すように規定されている。
図７０は、出力モードの選択モデルの状態遷移を示す。この選択モデルには、2つの一般的な状態が存在する。楕円は、この一般的な状態、つまり、出力モード値がとりうる値である“Invalid”,“valid”を模式的に描いたものである。Invalidは出力モードが無効であり、Validは出力モードが有効である旨を示す。
【０６７６】
一般的な状態は、状態遷移が起こらない限り、維持される。状態遷移は、プレイリスト再生の開始、ナビゲーションコマンドやBD-Jアプリケーションにより要求された出力モード変化、BD-Jタイトルへのジャンプがある。状態遷移が発生した際、出力モードプリレファレンスを獲得するためのプロシージャが実行される。
【０６７７】
図中の矢印jm1,jm2,jm3・・・・jm12は、状態遷移のトリガとなる事象を模式的に示す。本図における状態遷移には、以下のものがある。
『Load a disc』とは、BD-ROMが装填されたという状態を意味する。
【０６７８】
『Start Presentation』とは、HDMVモードにおいて、プレイリストの再生開始(start Playlist playback)を意味する。BD-Jモードにおいては、BD-Jタイトルへの分岐を意味する。何故なら、BD-Jモードにおいては、BD-Jタイトルに分岐した場合、必ずしも、プレイリストの再生が開始されるとは限らないからである。『Jumpto BD-J title』は、BD-Jタイトルへの分岐を意味する。具体的には、インデックステーブルにおいて、BD-Jアプリケーションに対応付けられたタイトル(BD-Jタイトル)がカレントタイトルになることをいう。
【０６７９】
『Start Playlist Playback』は、何等かのプレイリストを意味するプレイリスト番号が、PSRに設定されて、プレイリスト情報が、カレントプレイリスト情報としてメモリに読み出されることをいう。
【０６８０】
『Change Output Mode』とは、BD-JアプリケーションがAPIをコールすることで、出力モードを変化することをいう。『Terminatepresentation』とは、HDMVモードの場合は、プレイリストの再生が終了することをいい、BD-Jモードの場合は、BD-Jタイトルからインデックステーブルにおいてムービーオブジェクトに対応付けられたタイトル(HDMVタイトル)へとジャンプすることをいう。
【０６８１】
ディスクがロードされた際、出力モードの状態は、一時的な状態“Initialization”に遷移る。出力モードセレクションの状態は、一時的に“Initializationstate”に遷移した後、invalid stateに遷移する。
【０６８２】
Output Mode Selectionの状態は、再生開始(Start Presentation)がアクティブになるまで、Invalidに維持される。HDMVモードにおいて“StartPresentation”は、プレイリストの再生が開始されたことを意味する。BD-JモードにおいてStart Presentation”は、BD-Jタイトルの再生が開始され、BD-Jアプリケーションが何等かの動作を開始したことを意味する。必ずしも、プレイリストの再生が開始されたことを意味するとは限らない。
【０６８３】
Start Presentationがアクティブになった際、出力モードは、一時的な状態である“Procedure when playbackcondition is changed”に遷移する。
出力モードは、Procedure when playback condition is changedの結果に従ってValidに遷移する。出力モードが有効であって、StartPresentationが終了すれば、状態はInvalidに遷移する。
【０６８４】
ムービーオブジェクトにおけるナビゲーションコマンドは、コンテンツプロバイダが出力モードプリレファレンスに設定するために、プレイリスト再生の開始に先立ち、実行されねばならない。ムービーオブジェクトにおけるナビゲーションコマンドが実行された際、このモデルでは、Invalidになる。
【０６８５】
図７１は、Initializationの処理手順を示す。
ステップＳ５０１は、ディスクアンバウンドのBD-Jアプリケーションが動作中かどうかの判定であり、ステップＳ５０２は、PSR23におけるStereoscopicDisplay Capabilityが“Capability有”を示し、Index.bdmvにおけるInitial＿output＿mode情報が“立体視出力モード”を示すかどうかの判定である。
【０６８６】
ステップＳ５０１がYesであれば、ステップＳ５０３においてカレントの出力モードを維持する。ステップＳ５０１がNo、ステップＳ５０２がYesであれば、ステップＳ４においてPSR22を立体視出力モードに設定する。ステップＳ５０１がNo、ステップＳ５０２がNoであればステップＳ５においてPSR22における出力モードを、2D出力モードに設定する。
【０６８７】
図７２は、Procedure when playback condition is changedの処理手順を示す。ステップＳ５１１は、PSR22における出力モードは、2D出力モードであるか否かの判定であり、ステップＳ５１３は、PSR23におけるStereoscopicDisplay Capabilityが“Capability有”を示し、尚且つ、プレイリストに拡張ストリーム選択テーブルが存在するかどうかの判定である。
【０６８８】
ステップＳ５１１がYesであればステップＳ５１２において、カレント出力モードを変化させない。ステップＳ５１１がNo、ステップＳ５１３がYesであってもカレント出力モードを変化させない(ステップＳ５１２)。ステップＳ５１１がNo、ステップＳ５１３がNoであればカレント出力モードを2D出力モードに変化させる(ステップＳ５１４)。
【０６８９】
プレイリストの再生を開始するにあたって留意すべきは、それぞれのプレイアイテムで再生可能なPESストリームが、個々のプレイアイテムにおけるストリーム選択テーブルで規定されている点である。よってカレントプレイアイテムの再生を開始するにあたって、先ず始めに、カレントプレイアイテムのストリーム選択テーブルで再生が許可されているPESストリームの中から、プレイアイテムの再生に最適なものを選ぶ必要がある。この選択の手順は、“ストリーム選択プロシージャ”と呼ばれる。
【０６９０】
以下、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインについて説明する。3D再生モードの実現のために用いられているレジスタは、２１番、２２番、２３番、２４番のレジスタであり、これらのレジスタにおけるビットアサインを示したのが図７３である。図７３は、3D再生モード実現のためのプレーヤ設定レジスタのビットアサインを示す。
【０６９１】
同図（ａ）は、PSR21のビットアサインを示す。本図において、最下位ビットb0が、出力モードプリレファレンスであり、0bに設定されることで、2D出力モードである旨を示し、1bに設定されることで、立体視出力モードである旨を示す。ナビゲーションコマンドやBD-JアプリケーションはこのPSR21の値を書き換えることはできない。
【０６９２】
同図（ｂ）は、PSR22のビットアサインを示す。
PSR22におけるb0は、カレントの出力モードを表す。出力モードが変化すれば、再生装置におけるビデオ出力は、対応して変化しなければならない。出力モードの値は、選択モデルによって制御されねばならない。
【０６９３】
同図（ｃ）は、PSR23のビットアサインを示す。本図に示すようにPSR23におけるb0は、接続されたTVシステムにおける立体視表示ケーパビリティを示す。具体的には、“０”に設定されることで、接続されたTVシステムが、立体視再生インケーパブルである旨を示し、“１”に設定されることで、立体視再生ケーパブルであるかを示す。
【０６９４】
表示装置とネゴシエーションを行う何等かのインターフェイスが再生装置においてサポートされている場合、再生が開始する前に、これらの値は自動的に設定される。これらの値が自動的に設定されない場合、ユーザによって設定される。
【０６９５】
同図（ｄ）は、PSR24のビットアサインを示す。本図に示すようにPSR24におけるb0は、再生装置おける立体視表示ケーパビリティを示す。立体視表示ケーパビリティは、０に設定されることで、立体視再生タイプがインケーパブルである旨を示し、１に設定されることで、ケーパブルであるかを示す。
【０６９６】
以上のように本実施形態によれば、再生装置の状態変化やユーザからのストリーム切り替え要求があったとしても、出力モードの有効性を保つことができる。
(第８実施形態)
第１実施形態では、サブビュービデオストリームのメタデータに、オフセット制御を規定する情報を組み込んだが、本実施形態では、グラフィクスストリーム内のメタデータに、オフセット制御を規定する制御情報を組み込む。オフセット制御のための制御情報は、グラフィクスプレーンにおける水平座標の右方向及び左方向にオフセットを与えて、メインビューを構成するピクチャデータが描画されるメインビュービデオプレーン及びサブビューを構成するピクチャデータが描画されるサブビュービデオプレーンと合成する。
【０６９７】
以降、シフト制御のためのパラメータと、このパラメータを補間するためのデータとについて説明する。
図７４は、マクロブロックの奥行きと、シフト制御のためのパラメータとの関係を示す。
【０６９８】
図２のL画像、R画像を表すピクチャデータは、同図（ａ）のマクロブロック、同図（ｂ）のマクロブロックから構成されているものとする。これらの本図における四角枠が、一個のマクロブロックを表す。そして、ハッチングが付されたマクロブロックは、Ｌ画像、Ｒ画像を構成するマクロブロックのうち、立体物が占有しているものを示す。
【０６９９】
同図（ｃ）は、上記、Ｌ画像、Ｒ画像から得られる立体物であり、図２に示したものと同じである。図（ｄ）は、図（ａ）（ｂ）のマクロブロックによって現された立体物である。図（ａ）（ｂ）のマクロブロックは、Ｌ画像と、Ｒ画像との間の相関性に基づく奥行きをもつので、この奥行きに従い、マクロブロックをZ軸方向に配置すれば、図（ｄ）のようになる。これらのマクロブロックは、立体物である恐竜の頭、胴体、手足、尻尾の奥行きをもつので、図（ｅ）のように、シフト制御に用いるべき奥行きを規定する。つまり、立体視に対応するマクロブロックがもつ奥行きに対して、Z軸方向においてαだけ偏位した位置を、シフト制御で用いるべき奥行きとする。こうすることで、恐竜の頭部の手前でグラフィクスを表示するための奥行き、胴体の手前でグラフィクスを表示するための奥行き、手足の手前でグラフィクスを表示するための奥行き、尻尾の手前でグラフィクスを表示するための奥行きを規定することができる。
【０７００】
これら4つの奥行きを4つのオフセットシーケンスとして定義すれば、1plane＋Offsetモードにおいて、グラフィクスを表示させるための奥行きとして、恐竜の頭、胴体、手足、尻尾の何れかを適切に選択することができる。
【０７０１】
MPEG4-MVCの符号化では、Ｌ画像、Ｒ画像の相関性を用いて符号化がなされるので、Ｌ画像を構成するマクロブロックと、Ｒ画像を構成するマクロブロックとの動きベクトルが生成される。この動きベクトルを用いれば、マクロブロック毎の奥行きを検出することができ、このマクロブロック毎の奥行きから、マクロブロックのそれぞれに対応したシフト制御パラメータを得ることができる。
【０７０２】
かかるオフセットシーケンスの生成は、ビデオストリームのエンコードと並行して、オフセットシーケンスの定義手順を実行することでなされる。図７５は、ビデオストリームのエンコードとパラレルに実行される、オフセットシーケンスの定義手順を示すフローチャートである。
【０７０３】
ステップS１１０はGOPのエンコードが開始されたかどうかの判定であり、開始されれば、ステップS１１１において、GOPにおける先頭ビデオアクセスユニットの先頭のMVCスケーラブルネスティングSEIメッセージに、先頭ビデオアクセスユニットのピクチャ中の移動体の個々のマクロブロックに対応するオフセットシーケンスを生成する。これは、X軸方向のシフト幅、Z軸方向のシフト方向といった1plane＋Offsetモードのための制御パラメータを、先頭ビデオアクセスユニットのピクチャデータを構成する個々のマクロブロックに対応して生成するためである。
【０７０４】
ステップS１１２は、GOPに属するＬ画像、Ｒ画像のエンコードがなされる度に、画面中の移動体の動きベクトルがマクロブロック単位で算出されたかどうかの判定である。動きベクトルが算出されれば、奥行き情報を算出する。本実施形態では、奥行き情報を、ステップS１１３において、マクロブロック毎の動きベクトルの水平方向のスカラ値をシフト幅に変換し、マクロブロック毎の動きベクトルの移動方向の水平成分をシフト方向に変換するという簡易な処理で算出する。こうすることで、フレーム期間毎のシフト幅、シフト方向のおおよその値を求める。
【０７０５】
ステップS１１４において、フレーム期間のマクロブロック毎に得られたシフト幅に、Z軸方向の偏位量を加算する。これは、上記変換の元となる水平方向のスカラ値は、マクロブロックに対応する立体物の奥行きのそのものの奥行きを示しているので、かかる偏位量を加算しておくことで、立体物のやや手前の奥行きを1plane＋Offsetモードにおけるシフト幅として明示するするためである。
【０７０６】
ステップS１１５において、偏位量が加算された各フレームのマクロブロック毎のシフト幅と、シフト方向とを新たなPlane＿offset＿direction、Plane＿offset＿valueとして、各オフセットシーケンスに追記する。
【０７０７】
ステップS１１６は、ビデオストリームにおけるGOPのエンコードが継続しているかどうかの判定であり、継続していればステップＳ１１２に戻る。エンコードが継続している限り、上記オフセットシーケンスへのPlane＿offset＿direction、Plane＿offset＿valueの追加が継続することになる。
【０７０８】
GOPのエンコードが終了すれば、そのGOPに対するビデオアクセスユニットにおけるオフセットメタデータの生成を終え、ステップS１１０に戻る。
尚、3Dカメラの撮影の際、また、ベースビュービデオストリーム及びディペンデントビュービデオストリームのエンコードの際、これらマクロブロック毎のシフト幅、シフト方向をGOP毎にデータベース化しておき、このシフト幅、シフト方向に適切な変換を施して、GOP先頭にあたるアクセスユニット内のMVCスケーラブルネスティングSEIメッセージに格納すれば、複数の奥行きを定義するような複数のオフセットシーケンスを定義することができる。尚、MPEG4-MVCのコーディックを3Dカメラが具備している場合、3Dカメラにおいて、上記オフセットシーケンスの定義を実行すべきである。
【０７０９】
以上が、1plane＋Offsetモードにおけるシフト制御のパラメータの作り方である。次に、こうした過程で生成された制御パラメータを補間する補間パラメータについて説明する。このような補間パラメータは、字幕ストリームの内部のメタデータに存在する。
図７６は、字幕ストリームにおけるウィンドゥ定義セグメント、制御情報を示す図である。
【０７１０】
『ウィンドゥ定義セグメント』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は"window"と呼ばれ、このWDSで定義される。図７６（ａ）は、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『window＿id』と、グラフィックスプレーンにおける左上画素の水平位置を示す『window＿horizontal＿position』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『window＿vertical＿position』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『window＿width』と、グラフィックスプレーンにおける縦幅を示す『window＿height』とを用いて表現される。
【０７１１】
window＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンの内部領域においてウィンドゥは、縦:video＿height、横:video＿widthという二次元状の大きさをもつ。
【０７１２】
window＿horizontal＿positionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0〜video＿width-1の値をとり、window＿vertical＿positionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0〜video＿height-1の値をとる。
【０７１３】
window＿widthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0〜video＿width-window＿horizontal＿position-1の値をとり、window＿heightは、グラフィックスプレーンにおける縦幅であるので0〜video＿height-window＿vertical＿position-1の値をとる。
【０７１４】
WDSのwindow＿horizontal＿position、window＿vertical＿position、window＿width、window＿heightにより、グラフィックプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャーが表示されている期間において、ピクチャー内の絵柄の邪魔にならないように、ピクチャー上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャーの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【０７１５】
図７６（ｂ）は1Plane+offset用にフィールドを追加したPCS(Presentation Composition Segment)の構造を示している。
本図に示すようにPCSは、『segment＿type』と、『segment＿length』と、『composition＿number』と、『composition＿state』と、『pallet＿update＿flag』と、『pallet＿id＿ref』と、『number＿of＿composition＿object』to,『composition＿object(1)〜(m)』とから構成される。
【０７１６】
『composition＿number』は、0から65535までの数値を用いてDisplay Setにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcomposition＿numberは設定される。
【０７１７】
『composition＿state』は、本PCSから始まるDisplay Setが、Normal Caseであるか、Acquisition Pointであるか、EpochStartであるかを示す。
『pallet＿update＿flag』は、本PCSにおいてPalletOnly Displey Updateがなされているかどうかを示す。PalletOnlyDispley Updateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは"1"に設定される。
【０７１８】
以降の『3d＿graphics＿offset＿direction』、『3d＿graphics＿offset』は、グラフィクスストリームにおけるメタデータである。
『3d＿graphics＿offset＿direction』は左右のどちらにOffset分ずらすかの方向を決めるためのフィールドである。
【０７１９】
『3d＿graphics＿offset』は、左右の方向に具体的にどれだけ動かすかを決めるためにフィールドである。
『pallet＿id＿ref』は、PalletOnly Displey Updateに用いられるべきパレットを示す。
【０７２０】
『composition＿object(1)・・・(n)』は、このPCSが属するDisplay Set内で表示すべきObjcetをどのように制御するかを示す情報である。同図の破線co1は、任意のcomposition＿object(i)の内部構成をクローズアップしている。この破線co1に示すように、composition＿object(i)は、『object＿id＿ref』、『window＿id＿ref』、『object＿cropped＿flag』、『forced＿on＿flag』、『object＿horizontal＿position』、『object＿vertical＿position』、『cropping＿rectangle情報(1)(2)・・・・・(n)』からなる。
【０７２１】
『object＿id＿ref』は、composition＿object (i)に対応する参照すべきODSの識別子を示す。
『window＿id＿ref』は、本PCSにおいて、グラフィクスオブジェクトに割り当てられるべきウィンドゥを示す。1つのウィンドゥには最大2つのグラフィクスオブジェクトが割り当てられる。
【０７２２】
『object＿cropped＿flag』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、クロップしないグラフィクスオブジェクト表示するかを切り換えるフラグである。"1"と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、"0"と設定された場合、グラフィクスオブジェクトはクロップされることなく表示される。『forced＿on＿flag』は、プレーヤーの設定で字幕がOFFになっている際でも強制的に表示されるべき字幕を示すグラフィクスオブジェクトの場合に1になる。
【０７２３】
『object＿horizontal＿position』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『object＿vertical＿position』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
【０７２４】
『cropping＿rectangle情報(1)(2)・・・・・(n)』は、『object＿cropped＿flag』が1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcropping＿rectangle情報(i)の内部構成をクローズアップしている。この破線に示すようにcropping＿rectangle情報(i)は、『object＿cropping＿horizontal＿position』、『object＿cropping＿vertical＿address』、『object＿cropping＿width』、『object＿cropping＿height』からなる。
【０７２５】
『object＿cropping＿horizontal＿position』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSIEN 300 743標準規格における"Region"に相当する。
【０７２６】
『object＿cropping＿vertical＿address』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
『object＿cropping＿width』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
【０７２７】
『object＿cropping＿height』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がPCSのデータ構造である。
【０７２８】
3d＿graphics＿offsetで示される単位は、画面上の1画素(ピクセル)単位で左右にずらす量として定義してもよいし、3d＿graphics＿offsetを定義するビット数を節約するために、例えば2画素(ピクセル)単位で動かす量としても良い。
【０７２９】
例えば、3d＿graphics＿offset＿directionが1ビットのフィールドとして構成され、0の時に字幕がディスプレイから手前に飛び出る方向（つまりGraphicsPlaneを左目用Video Planeに重ねる場合には、右方向にOffset分ずらしてGraphics Planeを重畳）にOffsetを与え、1の場合には画面から奥行き方向にへこむ方向にOffsetを与えるようにする。また、3d＿graphics＿offsetが6ビットあるとすると、左右のVideoPlaneに対して重畳するOffsetは、左右方向に各64ピクセル(Offsetが1画素単位での移動量を示す場合) 動かすことができる。
【０７３０】
この時、左右方向に64ピクセルで十分な３Ｄ字幕（飛び出し）が得られないので、このフィールドの値は、ディペンデントビューストリームにおけるオフセットシーケンスとの補間値として用いる。具体的にいうと、composition＿object内のオフセットは、ディペンデントビューストリーム内のオフセットシーケンスと組合せて用いられる補間値であり、描画領域における字幕を表示するにあたって、ディペンデントビューストリームのオフセットシーケンスに示されるオフセットをどの程度補間すればよいかという補間値を示す。
【０７３１】
次に個々のPCSをどのように記述するかについて説明する。Display Setに属するWDS、PCSの記述例を図７７（ａ）〜（ｃ）に示す。図７７は、DS1におけるPCSの記述例を示す図である。
【０７３２】
図７７（ａ）において、WDSのwindow＿horizontal＿position、window＿vertical＿positionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、window＿width,window＿heightは、ウィンドゥの表示枠の横幅、縦幅を示す。
【０７３３】
図７７（ａ）におけるクロップ情報のobject＿cropping＿horizontal＿position,object＿cropping＿vertical＿positionは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして基準点からobject＿cropping＿width、object＿cropping＿heightに示される範囲(図中の太枠部分)がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてobject＿horizontal＿position、object＿vertical＿positionを基準点(左上)とした破線の範囲cp1に配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
【０７３４】
図７７（ｂ）は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は、（ａ）と同じなので説明を省略する。クロップ情報の記述は、（ａ）と異なる。図７７（ｂ）におけるクロップ情報のobject＿cropping＿horizontal＿position、object＿cropping＿vertical＿positionは、オブジェクトバッファ上の字幕『本当はウソだった。あなたが』のうち、『ウソだった』の左上座標を示し、object＿cropping＿height、object＿cropping＿widthは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
【０７３５】
図７７（ｃ）は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図７７（ａ）と同じなので説明を省略する。クロップ情報の記述は、図７７（ａ）と異なる。図７７（ｃ）におけるクロップ情報のobject＿cropping＿horizontal＿position、object＿cropping＿vertical＿position,は、オブジェクトバッファ上の字幕『本当はウソだった。あなたが』のうち、『あなたが』の左上座標を示し、object＿cropping＿height、object＿cropping＿widthは、『あなたが』の横幅、縦幅を示す。こうすることにより、『あなたが』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『あなたが』は動画像と合成され表示される。
【０７３６】
DS1,2,3のPCSを以上のように記述することで、字幕の表示効果を実現することができる。
図７８は、composition＿object内の3d＿graphics＿offsetを用いた補間を施す場合と、補間を施さない場合とで、オフセットが時間的にどのように変化するかを示す。実線は、composition＿object内の3d＿graphics＿offsetを用いて補間を施した場合におけるオフセットの時間的変化を示し、破線は、composition＿object内の3d＿graphics＿offsetを用いた補間を施さない場合におけるオフセットの時間的変化を示す。
【０７３７】
グラフィクスプレーンにおいて描画領域が2つあり、これらのうち、1つ目の領域に台詞を表示し、2つ目の領域に、監督のコメンタリを表示させたい場合がある。そして、コメンタリについては、台詞よりも奥手に配置して、字幕の立体感を出したいような場合、2つ目の領域について、補間値を設定すれば、コメンタリの奥行きを深くすることができる。
【０７３８】
プレーンシフトはライン単位になされるので、1つのラインに複数の描画領域を定義できないようなルールを設けるか、または、1つのラインに複数の描画ラインを設ける場合、オフセットの値を同じ値に設定するというルールを設けるべきである。
【０７３９】
（第９実施形態）
本実施形態は、ビデオオフセット情報が、画面を分割することで得られたそれぞれの領域のオフセット値を持つという改良に関する。
【０７４０】
図７９は、画面の分割領域毎のオフセットから構成されるオフセットシーケンスを示す。同図左は、９個のオフセットから構成されるオフセットシーケンスである。同図右は、オフセットシーケンスにおける個々のオフセットが、９分割された画面のうち、どの部分に該当するかを示す。Offset＿１は左上、Offset＿２は左、Offset＿３は左下、Offset＿４は上、Offset＿５は中心、Offset＿６は下、Offset＿７は右上、Offset＿８は右、Offset＿９は右下の領域のオフセット値を表す。これらのOffset値はビデオストリームの各フレームのビデオの奥行き情報から決定される。
【０７４１】
図８０は、画面内の物体の奥行きと、オフセットとの関係を示す。同図の左側は、ピクチャデータの一例を示し、右側は、９分割のオフセットシーケンスを示す。左側において、円形の物体は奥に引っ込んでおり、三角の物体は前に飛び出ているものとする。
【０７４２】
この場合、円形の物体が含まれる領域に対応するオフセット１は、その値は小さい。
三角の物体が含まれる領域に対応するオフセット５、６、８、９は、その値が大きく設定されている。このようにオフセット情報は、各フレームごとのシーンに含まれる物体の奥行きを元に作成される。
【０７４３】
次に、３D再生装置について説明する。３D再生装置の構成の基本部分は、これまでの実施の形態で説明した３D映像を再生する３D再生装置と同じであるため、拡張または異なる部分を中心に説明する。
【０７４４】
図８１は、再生装置のうち、ビデオデコーダ、ベースビュービデオプレーン、ディペンデントビュービデオプレーン、PG/IGプレーンを示す。
まず、３D映像ビデオデコーダは、２D/左目映像プレーンにPTSのタイミングでフレームの復号画像を書き出すと同じタイミングで、そのフレームに含まれるビデオオフセット情報をプレーン合成部に通知する。
【０７４５】
また、ビデオオフセット情報の９分割の領域のオフセットの中で、どのオフセットの最大値をプレーンずらしに使うかを示すための情報が、プレーヤ変数のうち、SPRM（２５）に格納される。SPRM（２５）は、Offset＿１，  Offset＿２，  Offset＿３，  Offset＿４，
Offset＿５，  Offset＿６，  Offset＿７，  Offset＿８，  Offset＿９のうち、どの値が最大値であるかを示す。
【０７４６】
SPRM（２５）は、BDプログラムファイルのプログラムを実行時にコマンドやAPIなどでセットされる。SPRM（２５）は例えば９ビットの情報があり、それぞれの１ビットが各オフセット値が有効/無効を示す。
【０７４７】
プレーン合成部は、３D映像ビデオデコーダから転送されるビデオオフセット情報とSPRM（２５）の値から利用するオフセット値の最大値をとることでプレーンをずらす値を決め、プレーンずらし&クロッピング処理を行ってプレーンメモリとの重畳を行う。
【０７４８】
同図の例では各オフセットの値が、Offset＿１=-３，  Offset＿２=-３，  Offset＿３=-１，  Offset＿４=-２，  Offset＿５=３，  Offset＿６=５，  Offset＿７=１，  Offset＿８=４，  Offset＿９=５となっている。SPRM（２５）には、Offset＿１とOffst＿４とOffset＿７が有効で、これらの最大値をプレーンずらしに使うように設定されている。
【０７４９】
シフト部は、ビデオオフセット情報の中から、SPRM（２５）で有効とされるOffset＿１とOffset＿４とOffset＿７の中から最大値を計算して（この場合はMAX（-３，-２，１）=１）、プレーンずらし&クロッピング処理を実行し、映像プレーンとの重畳を行う。
【０７５０】
このような構成にすることによりビデオストリームの中にビデオオフセット情報を入れることにより、３D再生装置が持つメモリサイズを削減できる。
＜オフセットの適用＞
SPRM（２５）には、有効な９分割のオフセット値を指し示す情報だけでなく、ベースのオフセット値を格納しても良い。そして、プレーン合成部は、９分割内の有効なオフセット値の最大値を出した後に、そのベースのオフセット値を加算しても良い。例えば、９分割内の有効なオフセット値が３で、ベースのオフセット値が２であれば、プレーンをずらすオフセット値を３+２の５としても良い。
【０７５１】
＜ウィンドゥの適用＞
本実施の形態では、SPRM（２５）を使って、９分割の内の有効なオフセット値を決めるとしたが、グラフィックスプレーンに含まれるグラフィックスの矩形領域を元に有効なオフセット値を決めるてもよい。
【０７５２】
図８２は、グラフィクスプレーンの内容と、オフセットとの関連性を示す。
例えば、表示すべきグラフィックスのグラフィックスイメージが、同図下段の円形であれば、有効なオフセット値は、Offset＿５＆Offset＿６＆Offset＿８＆Offset＿９となる。これはIG/PGなどのグラフィクスだけでなく、クローズドキャプションなどの情報を３D再生する場合も同じである。
【０７５３】
＜オフセット情報の位置＞
ビデオオフセット情報は、フレームごとに格納されるのではなく、GOP先頭のみに格納されるとしても良い。また、GOP先頭のアクセスユニットにGOPに含まれるフレーム分のビデオオフセット情報が格納されていても良い。
【０７５４】
なお、ビデオオフセット情報は、ビデオエンコード時に左目画像と右目画像の動きベクトルの違いから算出しても良い。
＜変更＞
ビデオオフセット情報は、各フレームごとのシーンに含まれる物体の奥行きから算出する場合には、奥行き情報が奥行きが激しく変化する場合に、グラフィックスの奥行き間も激しく変化してしまうため、フレーム間でローパスフィルタを通すようにして値を設定しても良い。
【０７５５】
＜プレーンメモリ毎の適用＞
本実施の形態では、ビデオオフセット情報を、ビデオの画面を９分割した値でセットしたが、プレーンごとのオフセット値を持つとしても良い。この場合、プレーン合成部はプレーンに応じて、オフセット値を変えて、プレーンずらし&クロッピングを行う。
【０７５６】
＜格納位置＞
本実施の形態では２D/左目映像ビデオストリームにオフセット値を格納するとして説明したが、右目映像ビデオストリームの方に格納していてもよいのはいうまでもない。
(第１０実施形態)
本実施形態では、Ｌ画像、Ｒ画像を用いて立体視効果を実現する3D-LR方式の他、2D画像と、深度情報とを用いて立体視効果を実現する3D-Depth方式を導入する。
【０７５７】
3D-Depth方式とは、ビデオデコーダの後段に、視差映像生成器を組み入れて、ビデオストリームにおける個々のピクチャデータと、このピクチャデータにおける個々の画素の深度情報とからレフトビューピクチャデータ、ライトビューピクチャデータを作り出させるモードである。
【０７５８】
この深度情報は、画素の深度を濃淡で表すグレースケールのピクチャデータ(深度情報ピクチャデータと呼ばれる)として構成することができる。
図８３は、デプスビュー方式の一例を示す。同図（ａ）は、2D画像であり、同図（ｂ）は、（ａ）に示した2Dに対して作成されたグレースケールを示す。グレースケールは、輝度成分のみの画素によって表現される。グレースケールの画素のうち、輝度が高いもの程(白いもの程)、奥行きが浅く、輝度が低いもの程(黒いもの程)、奥行きが深いことを示す。同図（ｃ）、（ｄ）は、グレースケールを用いることで生成される左目映像、右目映像を示す。図８４は、3D-Depthモードで生成される立体視画像を示す。2Dの各フレーム毎に、左目映像、右目映像を生成すれば、ゴーグルを通じて左目映像、右目映像を見ることで、ユーザは立体視を楽しむことができる。
【０７５９】
3D-Depth方式では、2D再生可能なビデオストリームがベースビュービデオストリームになる。グレースケールのピクチャデータから構成されるビデオストリームが、ディペンデントビュービデオストリームになる。
【０７６０】
3D-Depthモードと、3D-LRモードとでは、ベースビュービデオストリームは共通化することができるため、ベースビュービデオストリームに組合せるべきビデオストリームを変化させれば、3D-LRモード、3D-Depthモードの映像を生成することができる。データ管理構造からこれらの組み合わせを扱い、プレーヤおよび接続されているテレビ側の特性に合わせて、表示方法を切り替える。3D-Depthモードは、再生装置に専用のハードウェアが必要であるので、特に断らない限り、本明細書で述べる記録媒体、再生装置は、3D-Depthモードに対応しないものとする。
【０７６１】
図８５は、3D-Depthモードを実現するための記録媒体の構成例を示す。同図（ａ）は、3D-Depthモードに対応したディレクトリとファイルを示す。
3D再生用のベースビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、BASEサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
【０７６２】
3D再生用LR形式のディペンデントビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、LRサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
【０７６３】
3D再生用Depth形式のベースビュービデオストリームを含むストリームファイルは、STREAMディレクトリ以下に、DEPTHサブディレクトリを作成して格納し、2D再生用のストリームファイルと区別する。
【０７６４】
同様に、LR形式で再生する際に必要なストリームファイルのストリーム管理情報は、CLIPINFディレクトリ以下に、LRサブディレクトリを作成して格納し、2D再生用の管理と区別する。
【０７６５】
Depth形式で再生する際に必要なストリームファイルのストリーム管理情報は、CLIPINFディレクトリ以下に、DEPTHサブディレクトリを作成して格納し、2D再生用の管理と区別する。ファイルの形式により、拡張子も変化させる。
【０７６６】
１つのストリームファイルだけで再生できるファイルは、2D再生用のストリームファイルと同じ拡張子を利用する。
ベースビュービデオストリームを含まず、単体では再生できず（ビデオをデコードできず）、ベースビュービデオストリームを含むストリームファイルとともに再生しなければデコードできないファイルは“.３dts”などと拡張子を分けて区別する。
【０７６７】
ベースビュービデオストリームとディペンデントビュービデオストリームがインタリーブ配置されており、単純にファイル先頭から連続に読み込んでも再生できない形式のファイルは、.ilts（interleaved  TS）などと拡張子を分けて区別する。
【０７６８】
同図（ｂ）は、3D-Depthモードに対応するための拡張ストリーム選択テーブルのシンタックスを示している。同図（ｂ）のシンタックスでは、stream＿entry()に、type=4という類型が追加されている。type=4の場合は、3D用のファイルを指定するref＿to＿stream＿PID＿of＿3DClipを含む。
【０７６９】
LR＿dependent＿view＿ES＿availability、LR＿interleaved＿file＿availability、Depth＿dependent＿view＿ES＿availability、Depth＿interleaved＿file＿availabilityは、Out-of-MUXを利用したディペンデントビュービデオストリームを供給する場合、インターリーブ形式のファイルは不要となることを示すフラグである。
【０７７０】
3D＿base＿view＿block()は、必ず存在するブロックであり、2D用と3D用とで参照するエクステントが異なる場合は、type=4のストリームエントリーにより、STREAM/BASE/xxxxx.m2tsを参照する。
【０７７１】
2D用と、3D用とで参照するエクステントが同一である場合、或は1TSの場合は、type=1のストリームエントリーにより、STREAM/xxxxx.m2tsを参照する。
LR＿dependent＿view＿ES＿availabilityがオンに設定されている場合、type=4のストリームエントリーを用いてSTREAM/LR/xxxxx.3dtsを指定する。LRインタリーブファイルを利用する場合は、STREAM/LR/xxxxx.iltsを指定する。
【０７７２】
Depth＿dependent＿view＿ES＿availabilityがオンに設定されており、2D用と3D用とで参照するエクステントが異なる場合、type=4のストリームエントリーを用いてSTREAM/DEPTH/xxxxx.3dtsを指定する。Depthインタリーブファイルを利用する場合は、STREAM/DEPTH/xxxxx.iltsを指定する。
【０７７３】
図８６は、プレイアイテムと、ストリームとの対応関係を示す。同図の左側の第１列は、図８５（ｂ）によって記述された拡張ストリーム選択テーブルを含むプレイアイテムであり、その隣の第２列は、図８５（ａ）のストリームファイル内のTSである。第３列は、様々なタイプの再生装置を示し、第４列は、その再生装置によって参照されるクリップ情報ファイルを示す。
【０７７４】
図中の左側のプレイアイテムの中には、クリップ情報ファイルネーム(clip＿file＿name)、ストリーム選択テーブル(STN＿table)、3D-Depth方式に対応することができる拡張ストリーム選択テーブル(STN＿table＿extention)が存在する。ストリーム選択テーブル、拡張ストリーム選択テーブルの中の小枠は、ストリーム選択テーブル、拡張ストリーム選択テーブルにおけるストリーム登録情報のストリームエントリーが、どのような類型であるかを示す。ストリーム選択テーブルにおけるストリームエントリーの類型はType＝１になっている。
【０７７５】
対照的に、拡張ストリーム選択テーブルにおけるベースビュービデオストリームのストリームエントリー(Base view stream)、3D-LR形式のディペンデントビュービデオストリームのストリームエントリー(LRdependent view stream)、3D-LR形式の立体視インターリーブドストリームのストリームエントリー(LR interleavedstream)、3D-Depth形式のディペンデントビュービデオストリームのストリームエントリー(Depth dependent view stream)、3D-Depth形式の立体視インターリーブドストリームのストリームエントリー(Depthinterleaved stream)は、何れもType=4になっている。
【０７７６】
第２列における一番上の段は、立体視インターリーブドストリームファイル(00001.ssif)の内部構成を示す。枠内の“Ｄ”,“Ｒ”,“Ｌ”,“Ｌ2D”のうち、“Ｄ”は、Depth形式ベースビュービデオストリームのエクステント、“Ｒ”は、ライトビュービデオストリームのエクステント、“Ｌ”は、レフトビュービデオストリームのエクステント、“Ｌ2D”は、レフトビュービデオストリームのエクステントのうち、2D再生用のものを示す。
【０７７７】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/00001.m2tsのファイルパスでストリームファイルが、2Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｌ”,“Ｌ2D”が2Dプレーヤによって参照される。
【０７７８】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/BASE/00001.m2tsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｌ”,“Ｌ3D”が3Dプレーヤによって参照される。
【０７７９】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/LR/00001.3dtsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｒ”,“Ｒ”,“Ｒ”が3Dプレーヤによって参照される。
【０７８０】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/LR/00001.iltsのファイルパスでストリームファイルが、3D-LRモードで再生を行う3Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｒ”,“Ｌ”,“Ｒ”,“Ｌ3D”が3Dプレーヤによって参照される。
【０７８１】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/DEPTH/00001.3dtsのファイルパスでストリームファイルが、3D-Depthモードで再生を行う3Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｄ”,“Ｄ”,“Ｄ”が3Dプレーヤによって参照される。
【０７８２】
プレイアイテム情報におけるクリップ情報ファイルネームから、STREAM/DEPTH/00001.iltsのファイルパスでストリームファイルが、3D-Depthモードで再生を行う3Dプレーヤによって参照される場合、上述した立体視インターリーブドストリームファイルのエクステントのうち、“Ｄ”,“Ｌ”,“Ｄ”,“Ｌ3D”“Ｌ”が3Dプレーヤによって参照される。
【０７８３】
第４列によると、CLIPINF/00001.clpiは、2Dプレーヤ、3D-LR再生を行う3Dプレーヤ、Depth再生を行う3Dプレーヤによって参照されていることがわかる。CLIPINF/LR/00001.clpiは、3D-LR再生を行う3Dプレーヤによって参照されていることがわかる。CLIPINF/DEPTH/00001.clpiは、Depth再生を行う3Dプレーヤによって参照されていることがわかる。以上のように、ストリームエントリーがtype=4である場合、再生する3Dタイプ（LR形式、Depth形式）と、プレーヤの対応ファイル形式（base/dependent別ファイル形式、1ファイル形式）より、読み込むべきストリームファイルを判定する。
【０７８４】
2D用ストリームファイルと、3D用ストリームファイルとで同一エクステントのクロスリンクを実現している場合、ベースビューストリームのtype=1のストリームエントリーに設定することにより、2D用ストリームファイルと同一のストリームファイルを参照することができる。1TSに多重化する場合、ベースビュービデオストリーム、ディペンデントビューストリームのストリームタイプをいずれもtype=1のストリームエントリーとして、2D用ストリームファイルとおなじファイルを参照することができる。
【０７８５】
(第１１実施形態）                                                            
本実施の形態では、本発明にかかる３D再生装置に必要なビデオの復号化に必要なバッファサイズを削減するためのデータ構造および３D再生装置について説明する。
【０７８６】
先の実施形態に示したように、３D映像ビデオデコーダは、２D/レフトビュービデオストリームの符号化状態によるビデオアクセスユニットが格納されるバッファとしてEB(1)、ライトビュービデオストリームの符号化状態によるビデオアクセスユニットが格納されるバッファとしてEB(2）を持つ。
【０７８７】
このバッファサイズは、MPEG-４  AVC規格においてはCPBにあたり、所定の規格に応じて設定されるが、一般的にはビットレートの大きさに応じて設定される値である。ビットレートが大きくなれば必要なバッファサイズも多く必要であり、ビットレートが小さくなれば必要なバッファサイズも少なくてよい。ここでいうビットレートはMBからEBへの転送レートであり、MPEG-４  AVC規格でいえば、HRDパラメタータに格納されるBitRateを意味する。
【０７８８】
例えば、２D/レフトビュービデオストリームのビットレートが４０Mbpsの場合に必要なバッファサイズが４MBであるとすれば、同じ符号化方式で符号化されたビットストリームにおいては、３０Mbpsに必要なバッファサイズは４MB×３０Mbps/４０Mbps=３MBになる。
【０７８９】
ここで、２D/レフトビュービデオストリームとライトビュービデオストリームの合計のビットレートは、ドライブからの転送レートなどから固定値として規定される。ここではビデオストリームの合計のビットレートは６０Mbpsであるとする。
【０７９０】
この場合、合計のビットレートが６０Mbpsとすると、２D/レフトビュービデオストリームのビットレートが４０Mbpsであれば、ライトビュービデオストリームのビットレートは２０Mbpsとなる。また、２D/レフトビュービデオストリームのビットレートが３０Mbpsであれば、ライトビュービデオストリームのビットレートは３０Mbpsとなる。
【０７９１】
この場合、ビットレートの最大値を考えてみると、２D/レフトビュービデオストリームの最大ビットレートは４０Mbps、ライトビュービデオストリームの最大ビットレートは３０Mbpsとなる。各ビットレートの最大値からEBのサイズを定義すると、２D/レフトビュービデオストリーム用のEB(1)は４MB×４０Mbps/４０Mbps=４MB、ライトビュービデオストリーム用のEB(2）は４MB×３０Mbps/４０Mbps=３MBとなる。このように定義すれば、３D再生装置が、４MB+３MB=７MBのバッファを格納し、各ビデオストリームがここで定義されるバッファサイズでアンダーフローやオーバーフローしないように作成されていれば、３D映像の再生を保証できることになる。
【０７９２】
しかし、２D/レフトビュービデオストリームとライトビュービデオストリームのビットレートの合計は６０Mbpsであるため、２D/レフトビュービデオストリームの最大ビットレート=４０Mbpsとライトビュービデオストリームの最大ビットレート=３０Mbpsの組み合わせは存在しない。そのため、３D再生装置のためにそれぞれのビットレートの最大値からバッファサイズを決定した場合（４MB+３MB）には、必要以上に大きなバッファサイズをつむことになってしまう。
【０７９３】
そこで、３D再生装置が、必要最低限のEB(1)、EB(2）のバッファサイズを積むためのデータ構造および３D再生装置について説明する。
まず、データ構造について説明する。
【０７９４】
データ構造の基本部分は、これまでの実施の形態で説明した３D映像を格納するためのデータ構造と同じであるため、拡張または異なる部分を中心に説明する。
本実施の形態におけるデータ構造は、プレイアイテムの構造が図８７に示す構造になっていおり、EB(1)サイズとEB(2）サイズのフィールドが追加されている点が異なる。  図８７は、エレメンタリバッファのサイズ情報を含むプレイアイテム情報を示す。
【０７９５】
EB(1)サイズは、プレイアイテムから参照される２D/レフトビュービデオストリームをデコードするために必要なEB(1)のサイズ情報が格納される。
EB(2）サイズは、上記プレイアイテムと同時に再生されるライトビュービデオストリームをデコードするために必要なEB(2）のサイズ情報が格納される。
【０７９６】
ここでEB(1)サイズとEB(2）サイズの合計サイズは、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートから決定される。例えば、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートが６０Mbpsの場合には、４MB×６０Mbps/４０Mbps=６MBとなる。
【０７９７】
また、プレイアイテムから参照される２D/レフトビュービデオストリームは、EB(1)サイズで定義されるバッファでアンダーフロー、オーバフローしないでデコードできるように作成されており、プレイアイテムと同時に再生されるライトビュービデオストリームは、EB(2)サイズで定義されるバッファでアンダーフロー、オーバフローしないでデコードできるように作成されている。
【０７９８】
次に、３D再生装置について説明する。
３D再生装置の構成の基本部分は、これまでの実施の形態で説明した３D映像を再生する３D再生装置と同じであるため、拡張または異なる部分を中心に説明する。
【０７９９】
本実施の形態における３D再生装置は、再生するプレイアイテムに応じて、３D映像ビデオデコーダ内のベースビュー用のEB、ディペンデントビュー用のEBのサイズ（メモリの割り当てサイズ）を変更する点が異なる。
【０８００】
再生制御部は、プレイアイテムの再生を行う前に、プレイアイテムに含まれるEB(1)サイズとEB(2）サイズの情報を取得し、システムターゲットデコーダに通知し、システムターゲットデコーダは、３D映像ビデオデコーダのEB(1)とEB(2）のサイズを変更する。再生制御部は、EB(1)と、EB(2）のサイズの変更が完了した後に、該当プレイアイテムの再生を開始する。
【０８０１】
３D再生装置がプレイアイテム＃1を３D映像として再生する場合には、プレイアイテム＃1から参照される２D/レフトビュービデオストリームと、プレイアイテム＃1と同時に再生されるライトビュービデオストリームを特定して再生処理を行うが、３D再生装置はプレイアイテム＃1に含まれるEB(1)サイズとEB(2）サイズより、システムターゲットデコーダ内の映像ビデオデコーダのEB(1)と、EB(2）とのサイズを変更する。この例では、EB(1)サイズを４MB、EB(2）サイズを２MBと設定し、ビデオストリームの再生を行う。プレイアイテム＃2を再生する場合も同様に、３D再生装置はプレイアイテム＃2に含まれるEB(1)サイズとEB(2）サイズより、システムターゲットデコーダ内の映像ビデオデコーダのEB(1)と、EB(2）のサイズを変更する。この例では、EB(1)サイズを３MB、EB(2）サイズを３MBと設定し、ビデオストリームの再生を行う。
【０８０２】
このような構成にすることにより、３D再生装置に必要なEB(1)とEB(2）のサイズをビデオストリームのビットレートに応じて適宜制御できるため、必要なバッファサイズを、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートから定義することが可能となる。これにより、それぞれのビットレートの最大値で定義したバッファサイズを持つ場合に比べて、必要なEB(1)とEB(2）の合計バッファサイズを削減することができる。
【０８０３】
尚、プレイアイテム間でシームレス接続が行われる場合にバッファサイズが変更されると、プレイアイテム間の遷移で、どちらかのEBのサイズが小さくなると、シームレス接続の保証ができなくなる可能性があるため、これを禁止しても良い。つまり、コネクションコンディションが５、６のプレイアイテムにおいては、EB(1)サイズとEB(2）サイズの値は設定できない、もしくは無視されるとしてもよい。また、コネクションコンディションが５、６のプレイアイテムにおいては、EB(1)サイズとEB(2）サイズの値は、前のプレイアイテムのEB(1)サイズ、EB(2）サイズと同じ値になっていなければならないとしても良い。
【０８０４】
また、２D/レフトビュービデオストリームとライトビュービデオストリームの合計ビットレートは固定的に決まるため、EB(1)サイズのフィールドだけが存在し、EB(2）サイズは、EBの合計バッファサイズ-EB(1)サイズとして算出できるとしてもよい。
【０８０５】
更に、EB(1)サイズとEB(2）サイズのフィールドは、バッファサイズを算出できればよい。例えばビデオストリームのビットレートが書いてあり、これから算出しても良いし、EB(1)サイズとEB(2）サイズの組み合わせがテーブルとして定義されていて、そのIDを設定しても良い。
【０８０６】
(第１２実施形態)
本実施形態は、クリップ情報における3Dメタデータに、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームの２Ｄイメージに奥行き情報を追加する改良に関する。
【０８０７】
図８８は、奥行き情報が追加された3Dメタデータを示す。3Dメタデータは、同図上段に示すように、AVストリーム内に含まれるプレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム、副映像ビデオストリームのPID毎に、3D映像の表示時刻を示すPTSと、ライトビューレフトビューのピクセルのずれを示すオフセット値が記載されたテーブル情報である。オフセット値はＸ軸方向へのピクセル数であり、マイナス値も許される。ここではテーブルの１つの行で示される対となるPTSとオフセット値の情報をオフセットエントリと呼ぶことにする。オフセットエントリの有効区間は、該当オフセットエントリのPTSから次のオフセットエントリのPTSまでである。例えば、オフセットエントリ＃１のPTSが１８００００で、オフセットエントリ＃２のPTSが２７００００である場合は、オフセットエントリ＃１のオフセット値は１８００００から２７００００まで有効となる。再生装置のプレーン合成部は、この情報値に基づき、PGプレーン、IGプレーン、副映像プレーンを左右にオフセット値をずらしながらプレーン合成をする。これによって、視差画像をつくり出すことができ、２次元映像に対して立体的な奥行きを付加することができる。
【０８０８】
なお、ここでは3DメタデータはPID毎に設定されるとしたが、例えば各プレーンごとに設定できても良い。これにより2D/3D再生装置の3Dメタデータの解析処理を簡素化できる。なお、2D/3D再生装置の合成処理の性能を踏まえて、オフセットエントリの間隔に例えば１秒以上とするなどのように制約をつけても良い。
【０８０９】
ビデオストリーム属性情報について説明する。3D-LRモードにおいては、2D/ベースビュービデオストリームのPIDが0x1011のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度と、対応するライトビューAVストリームのPIDが0x1012のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度は一致しなければならない。また、3D-Depthモードにおいては、2D/ベースビュービデオストリームのPIDが0x1011のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度と、対応するデプスマップAVストリームのPIDが0x1013のビデオストリーム属性情報のコーデック、フレームレート、アスペクト比、解像度は一致しなければならない。コーデックが同じでない場合にはビデオストリーム間での参照関係が成り立たず、また、ディスプレイに同期して3D映像として再生するためにはフレームレート、アスペクト比、解像度を一致しなければユーザに違和感を与えてしまうためである。
【０８１０】
また、ライトビューAVストリームのビデオストリーム属性情報に、ビデオストリームが2D/ベースビュービデオストリームを参照するビデオストリームであることを示すフラグを入れても良い。また、参照先のAVストリームの情報を含めておいても良い。このような構成にすることにより、作成されたデータが規定のフォーマットどおりに作られているかを検証するツールが、ビデオストリームの対応関係を判断することができる。
【０８１１】
2D/ベースビュービデオストリームのクリップ情報ファイルには、2D/レフトビュービデオストリームのエントリマップが格納される。2D/レフトビュービデオストリームの各エントリポイントには、2D/レフトビュービデオストリームのGOP先頭のＩピクチャのPTSとSPNが登録される。同様に、ライトビュービデオストリームのクリップ情報ファイルには、ライトビュービデオストリームのエントリマップが格納される。ライトビュービデオストリームの各エントリポイントには、ライトビュービデオストリームのライトビューGOP先頭のピクチャのPTSとSPNが登録される。（第１３実施形態）
本実施形態では、前述の実施形態において説明された構造のデータを再生する再生装置に関して、集積回路６０３を用いて実現した構成例について説明する。
【０８１２】
媒体IF部６０１は、媒体からデータを受信して（読み出して）、集積回路６０３に転送する。なお媒体IF部６０１は、前述の実施形態において説明した構造のデータを媒体から受信する。媒体IF部６０１は、例えば、媒体が光ディスクやハードディスクの場合はディスクドライブ、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波の場合はCANチューナーやSiチューナー、媒体がイーサネット（登録商標）、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。
【０８１３】
メモリ６０２は、媒体から受信した（読み出した）データを一旦格納したり、集積回路６０３における処理途中のデータを一時的に格納するメモリで、例えばSDRAM(SynchronousDynamic Random Access Memory)、Rx SDRAM(Double-Date-Ratex Synchronous DynamicRandom Access Memory;x=1,2,3・・・)等が用いられる。なおメモリ６０２は、任意の個数備えていればよく、必要に応じて単数でも複数でも構わない。
【０８１４】
集積回路６０３は、媒体IF部６０１から転送されたデータに対して映像・音声処理を施すシステムLSIで、主制御部６０６、ストリーム処理部６０５、信号処理部６０７、メモリ制御部６０９、AV出力部６０８等から構成される。
【０８１５】
主制御部６０６は、タイマ機能や割り込み機能を有するプロセッサコアを有し、プロセッサコアはプログラムメモリ等に格納されたプログラムに従って、集積回路６０３全体の制御を行う。なお、プログラムメモリ等には、予めOS等の基本ソフトが格納されている。
【０８１６】
ストリーム処理部６０５は、主制御部６０６の制御の下、媒体から媒体IF部６０１経由で転送されたデータを受信し、集積回路６０３内のデータバスを経由してメモリ６０２に格納したり、受信したデータを映像系データ（ビデオ／グラフィクス（PG,IG））、音声系データに分離する。前述したとおり媒体上ではレフトビュービデオストリームを含む2D/L用のAVクリップとライトビュービデオストリームを含むR用のAVクリップが、幾つかのエクステントに分割された状態で交互に配置されている。従って、主制御部６０６は、集積回路６０３がレフトビューストリームを含む左目用データを受信した場合は、メモリ６０２の第１の領域にデータが格納されるように、ライトビュービデオストリームを含む右目用データを受信した場合は、メモリ６０２の第２の領域にデータが格納されるように制御する。ここで、左目用データは左目用エクステントに属しており、右目用データは右目用エクステントに属している。なお、メモリ６０２における第１、第２の領域は単一のメモリが論理的に領域分割されたものでもよいし、物理的に異なるメモリでもよい。また、本実施形態においては、レフトビュービデオストリームを含む左目用データをメインビューデータ、ライトビュービデオストリームを含む右目用データをサブビューデータとして説明を続けるが、右目用データがメインビューデータ、左目用データがサブビューデータであっても構わない。
【０８１７】
信号処理部６０７は、主制御部６０６の制御の下、ストリーム処理部６０５が分離した映像系データ、音声系データに対し、適切な方式でデコードする。映像系データは、MPEG-2、MPEG-4AVC、MPEG4-MVC、SMPTE VC-1などの方式を使って符号化記録されており、また音声系データは、ドルビーAC-3、Dolby DigitalPlus、MLP、DTS、DTS-HD、リニアPCMなどの方式で圧縮・符号化記録されているので、信号処理部６０７はこれらに対応した方式でデコードする。なお、信号処理部６０７のモデルは、例えば第９実施形態の図６５における各種デコーダがそれに当たる。
【０８１８】
メモリ制御部６０９は、集積回路６０３内の各機能ブロックからメモリ６０２へのアクセスを調停する。
AV出力部６０８は、主制御部６０６の制御の下、信号処理部６０７においてデコードされた映像系データを重畳したり、映像系データのフォーマット変換等をして集積回路６０３外へ出力する。
【０８１９】
図９０は、ストリーム処理部６０５の代表的な構成を示す機能ブロック図である。ストリーム処理部６０５は、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３等を備える。
【０８２０】
デバイス・ストリームIF部６５１は、媒体IF部６０１と集積回路６０３間のデータ転送用インターフェースであり、例えば、媒体が光ディスクやハードディスクの場合はSATA(SerialAdvanced Technology Attachment)、ATAPI(Advanced Technology Attachment PacketInterface)、PATA(Parallel Advanced Technology Attachment)、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波などの場合はチューナーIF、媒体がイーサネット(登録商標)、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。なお、媒体の種類によっては、デバイス・ストリームIF部６５１が媒体IF部６０１の機能の一部を肩代わりしても構わないし、媒体IF部６０１が集積回路６０３に内蔵されていても構わない。
【０８２１】
多重分離部６５２は、媒体から転送された映像・音声を含む再生データを映像系データと音声系データに分離する。前述の各エクステントは、映像・音声・PG（字幕）・IG（メニュー）等の各ソースパケットから構成されており（但し、サブビューデータは音声を含まない場合もある）、各ソースパケットに含まれているPID（識別子）に従って、映像系・音声系の各TSパケットに分離され、信号処理部６０７に転送される。処理済のデータは、直接もしくは一旦メモリ６０２に格納された後、信号処理部６０７に転送される。なお、多重分離部６５２のモデルは、例えば第９実施形態の図６５におけるソースデパケタイザ、PIDフィルタがそれに当たる。
【０８２２】
切替部６５３は、デバイス・ストリームIF部６５１が左目用データを受信した時はメモリ６０２の第１の領域に格納されるように、右目用データを受信した時はメモリ６０２の第２の領域に格納されるように、出力先（格納先）を切り替える。ここで、切替部６５３は例えばDMAC(DirectMemory A１０１ess Controller)である。図９１は切替部６５３がDMACであった場合の切替部６５３周辺の概念図である。DMACは、主制御部６０６の制御の下、デバイス・ストリームIF部が受信したデータとそのデータ格納先アドレスをメモリ制御部６０９に対して送信する。具体的には、デバイス・ストリームIF部が左目用データを受信した時はアドレス１（第１の格納領域）を、右目用データを受信した時はアドレス２（第２の格納領域）をメモリ制御部６０９に送信することで、受信データによってその出力先（格納先）を切り替えている。メモリ制御部６０９は、DMACから送られてきた格納先アドレスに従ってメモリ６０２にデータを格納する。なお、主制御部６０６の代わりに切替部６５３を制御する専用の回路を設けても構わない。
【０８２３】
ここでは、ストリーム処理部６０５の代表的な構成として、デバイス・ストリームIF部６５１、多重分離部６５２、切替部６５３について説明したが、受信した暗号化データや鍵データ等を復号する暗号エンジン部、媒体〜再生装置間の機器認証プロトコル等の実行制御や秘密鍵を保持するセキュア管理部、ダイレクトメモリアクセス用のコントローラ等を更に備えていてもよい。これまでは媒体から受信したデータをメモリ６０２に格納する際に、切替部６５３が左目用データ・右目用データかによって格納先を切り替える場合について説明してきたが、媒体から受信したデータを一旦メモリ６０２に格納した後に、多重分離部６５２へデータを転送する際に、左目用データ・右目用データを振り分けてもよい。
【０８２４】
図９２は、AV出力部６０８の代表的な構成を示す機能ブロック図である。AV出力部６０８は、画像重畳部６８１と、ビデオ出力フォーマット変換部６８２、オーディオ・ビデオ出力IF部６８３等を備える。
【０８２５】
画像重畳部６８１は、デコードされた映像系のデータを重畳する。具体的には、レフトビュービデオデータもしくはライトビュービデオデータと、PG（字幕）、IG（メニュー）をピクチャ単位で重畳する。画像重畳部６８１のモデルは、例えば第１１実施形態、図９２などである。
【０８２６】
画像重畳部６８１は、レフトビュープレーンとグラフィクスプレーン、ライトビュープレーンとグラフィクスプレーンとを重畳する。図９４は画像重畳処理におけるメモリ６０２と各プレーンとの関係を示した図である。メモリ６０２には、デコード済みのデータで、各プレーンに描画されるデータを格納する領域（レフトビューに対応するプレーンデータ格納領域、ライトビューに対応するプレーンデータ格納領域、グラフィクスに対応するプレーンデータ格納領域）を備える。ここで、プレーンはメモリ６０２中の領域であることもあれば、仮想的な空間であることもある。メモリ６０２は、更に画像重畳後のデータを格納する画像重畳後データ格納領域を備える。
【０８２７】
図９５、図９６は画像重畳の概念図である。ここでは簡単のために、グラフィクスプレーンは一枚であり、レフトビュープレーンと重畳する際は、グラフィクスプレーンに+Xのオフセットを与えて、ライトビュープレーンと重畳する際は、-Xのオフセットを与えて重畳処理を行う、ワンプレーンオフセットモードを前提として説明する。なお、グラフィックスプレーンをレフトビュー重畳用、ライトビュー重畳用の二枚用意し、それぞれにオフセット値を与えて、重畳処理を行っても構わない。図９５においては、グラフィクスプレーンを紙面上右へoffset値だけ平行移動させたものをレフトビュープレーンと、図９６においては、グラフィクスプレーンを紙面上左へoffset値だけ平行移動させたものをライトビュープレーンと重畳する。この時、図示しているように紙面上左右方向の座標が同じで対応する画素同士を重畳し、重畳後のデータをメモリ６０２の画像重畳後データ格納領域に格納する。なお、グラフィクスプレーンのoffset値は、前述のとおりライトビュービデオストリーム（サブビュービデオストリーム）もしくは、PLAYLISTに含まれている。図９７は、画像重畳の別の方法を示した概念図で、メモリ６０２は更に、オフセット済みグラフィクスに対応するプレーンデータ格納領域（レフトビュー重畳用、ライトビュー重畳用）を備え、予めレフトビュープレーン、ライトビュープレーンと重畳されるデータをメモリ６０２に用意しておき、画像重畳部６８１がメモリ６０２から必要なデータを読み込んで重畳し、重畳後のデータをメモリ６０２の画像重畳後データ格納領域に格納するというものである。また図９８は、テキスト字幕（PG/IGとは別）の重畳に関する概念図である。テキスト字幕は、前述のとおりテキスト字幕ストリームに多重化されており、グラフィクスプレーンに描画されて重畳されるが、レフトビュープレーン重畳時とライトビュー重畳時とはそれぞれオフセット値分だけずらして描画したものを、レフトビュープレーン、ライトビュープレーンと重畳する。なお、図９８に示しているとおりメモリ６０２は更にテキスト字幕に対応するプレーンデータ格納領域を備えている。
【０８２８】
ビデオ出力フォーマット変換部６８２は、デコードされた映像系データに対して、拡大または縮小するリサイズ処理、走査方式をプログレッシブ方式及びインターレース方式の一方から他方に変換するＩＰ変換処理、ノイズを除去するノイズリダクション処理、フレームレートを変換するフレームレート変換処理などを必要に応じて行う。
【０８２９】
オーディオ・ビデオ出力IF部６８３は、画像重畳やフォーマット変換された映像系データとデコードされた音声系データとに対して、データ送信形式に合わせてエンコード等を行う。なお、後述するようにオーディオ・ビデオ出力IF部６８３は、一部集積回路６０３外に備えられても構わない。
【０８３０】
図９３は、AV出力部６０８もしくは再生装置のデータ出力部分を、より詳細に示した構成例である。本実施の形態における集積回路６０３及び再生装置は、複数の映像系データ、音声系データのデータ送信形式に対応している。図９２におけるオーディオ・ビデオ出力IF部６８３は、アナログビデオ出力IF部６８３a、アナログオーディオ出力IF部６８３c、デジタルオーディオ・出力IF部６８３bに対応する。
【０８３１】
アナログビデオ出力IF部６８３aは、画像重畳処理や出力フォーマット変換処理された映像系データを、アナログ映像信号形式に変換・エンコードし、出力する。例えば、NTSC、PAL、SECAMの３方式のいずれかに対応したコンポジットビデオエンコーダー、Ｓ映像信号（Y/C分離）用エンコーダー、コンポーネント映像信号用エンコーダーや、DAC（D/Aコンバータ）等がそれに当たる。
【０８３２】
デジタルオーディオ・ビデオ出力IF部６８３bは、デコードされた音声系データと画像重畳処理や出力フォーマット変換された映像系データを一体化、更に暗号化した後、データ送信規格に合わせてエンコードし、出力する。例えば、HDMI(High−DefinitionMultimedia InterFace)等がそれに当たる。
【０８３３】
アナログオーディオ出力IF部６８３cは、デコードされた音声系データをD/A変換しアナログ音声データを出力するオーディオDAC等がそれに当たる。
これら映像系データ及び音声系データの送信形式は、表示装置・スピーカー６０４側がサポートしているデータ受信装置（データ入力端子）に依存して切り替えたり、またユーザーの選択によって送信形式を切り替えることが可能である。更に、単一の送信形式だけではなく、並行して複数の送信形式にて同一のコンテンツに対応したデータを送信することも可能である。
【０８３４】
ここでは、AV出力部６０８の代表的な構成として、画像重畳部６８１、ビデオ出力フォーマット変換部６８２、オーディオ・ビデオ出力IF部６８３について説明したが、フィルタ処理、画面合成、曲線描画、３Ｄ表示等のグラフィックス処理を行うグラフッィクスエンジン部等を更に備えていてもよい。
【０８３５】
以上が、本実施の形態における再生装置の構成についての説明である。なお、前述の集積回路６０３に含まれる各機能ブロックは全てが内蔵されていなくても良いし、逆に図８９のメモリ６０２が集積回路６０３に内蔵されていてもよい。また、本実施形態においては、主制御部６０６と信号処理部６０７は異なる機能ブロックとして説明してきたが、主制御部６０６が信号処理部６０７の処理の一部を行っても構わない。
【０８３６】
また、集積回路６０３における制御バスやデータバスの経路は、各処理ブロックの処理手順や処理内容によって任意に配置されるが、例えば図９９のように、各処理ブロックどうしを直接結ぶようにデータバスを配置してもよいし、図１００のように各処理ブロックどうしをメモリ６０２（メモリ制御部６０９）を介して結ぶようにデータバスを配置してもよい。
【０８３７】
また、集積回路６０３は、複数のチップを一つのパッケージに封止し、見かけ上一つのLSIにしたマルチチップ・モジュールであっても構わない。また、LSI製造後に、プログラムすることが可能なFPGA(FieldProgrammable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０８３８】
次に、以上のように構成された再生装置の動作について説明する。
図１０１は、媒体からデータを受信し（読み出し）、デコードした後に、映像信号及び音声信号として出力する再生動作手順を簡単に示すフローチャートである。
【０８３９】
Ｓ６０１：媒体からデータを受信する（読み出す）（媒体IF部６０１、ストリーム処理部６０５）。
Ｓ６０２：Ｓ６０１において受信された（読み出された）データを各種データ（映像系データ・音声系データ）に分離する（ストリーム処理部６０５）。
【０８４０】
Ｓ６０３：Ｓ６０２において分離された各種データを適切な形式でデコードする（信号処理部６０７）。
Ｓ６０４：Ｓ６０３においてデコード処理された各種データのうち、映像系のものについて重畳処理を行う（AV出力部６０８）。
【０８４１】
Ｓ６０５：Ｓ６０２〜Ｓ６０４において処理された映像系データ及び音声系データを出力する（AV出力部６０８）。
図１０２は、より詳細に再生動作手順を示したフローチャートである。各動作・処理は、主制御部６０６の制御の下、行われる。
【０８４２】
Ｓ７０１：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている再生されるデータ以外の、データを再生するために必要なデータ（PLAYLIST、CLIPINF等）を受信し（読み出し）、メモリ６０２に格納する（媒体IF部６０１、デバイスIF部６５１、メモリ制御部６０９、メモリ６０２）。
【０８４３】
Ｓ７０２：主制御部６０６は、受信されたCLIPINFに含まれるストリーム属性情報から、媒体に格納されている映像データ及び音声データの圧縮形式を認識し、対応するデコード処理ができるように信号処理部６０７の初期化を行う（主制御部６０６）。
【０８４４】
Ｓ７０３：ストリーム処理部６０５のデバイス・ストリームIF部６５１は、媒体IF部６０１を通して媒体に格納されている映像・音声など再生されるデータを受信し（読み出し）、切替部６５３、メモリ制御部６０９を経由してメモリ６０２に格納する。なお、データはエクステント単位で受信し（読み出され）、左目用データを受信した（読み出した）時は第１の領域へ、右目用データを受信した（読み出した）時は第２の領域へ格納されるよう、主制御部６０６が切替部６５３を制御し、切替部６５３がデータの出力先（格納先）を切り替える（媒体IF部６０１、デバイスIF部５１、主制御部６０６、切替部６５３、メモリ制御部６０９、メモリ６０２）。
【０８４５】
Ｓ７０４：メモリ６０２に格納されたデータは、ストリーム処理部６０５の多重分離部６５２に転送され、多重分離部６５２はストリームデータを構成するソースパケットに含まれるPIDに従って映像系（主映像、副映像、PG（字幕）、IG（メニュー））、音声系（音声、副音声）のいずれであるか認識し、TSパケット単位で信号処理部６０７の対応する各デコーダへ転送する。（多重分離部６５２）。
【０８４６】
Ｓ７０５：信号処理部６０７の各デコーダは、転送されてきたTSパケットに対して、適切な方式でデコード処理を行う（信号処理部６０７）。
Ｓ７０６：信号処理部６０７においてデコードされた映像系データのうち、レフトビュービデオストリーム及びライトビュービデオストリームに対応するデータを、表示装置４に合わせてリサイズする（ビデオ出力フォーマット変換部６８２）。
【０８４７】
Ｓ７０７：Ｓ７０６においてリサイズされたビデオストリームと、PG（字幕）・IG（メニュー）とが重畳される（画像重畳部６８１）。
Ｓ７０８：Ｓ７０７において重畳された映像データに対して、走査方式の変換であるＩＰ変換を行う（ビデオ出力フォーマット変換部６８２）。
【０８４８】
Ｓ７０９：これまでの処理を行った映像系データ及び音声系データに対して、表示装置・スピーカー６０４のデータ出力方式、もしくは表示装置・スピーカー６０４へのデータ送信方式に従って、エンコードやD/A変換等を行う。例えば、映像系データ・音声系データをそれぞれ、アナログまたはデジタル出力に対応するために処理を行う。映像系データのアナログ出力としては、コンポジット映像信号やＳ映像信号やコンポーネント映像信号等をサポートしている。また映像系・音声系データのデジタル出力は、HDMIをサポートしている（オーディオ・ビデオ出力IF部６８３）。
【０８４９】
Ｓ１１０：Ｓ７０９において処理された映像系データ及び音声系データを、表示装置・スピーカー６０４に送信、出力する（オーディオ・ビデオ出力IF部６８３、表示装置・スピーカー６０４）。
【０８５０】
以上が、本実施の形態における再生装置の動作手順の説明である。なお、処理ごとに処理結果をメモリ６０２に一旦格納しても構わない。また、本動作手順では、ビデオ出力フォーマット変換部６８２においてリサイズ処理及びIP変換処理を行う場合について説明したが、必要に応じて処理を省略しても構わないし、また他の処理（ノイズリダクション処理、フレームレート変換処理等）を行っても構わない。更に、可能なものについては処理手順を変更しても構わない。
【０８５１】
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。（複数のオフセットシーケンスの割り当て）
複数のオフセットシーケンスのそれぞれに、画像のマクロブロック毎の奥行きを格納するというのは一例に過ぎない。
【０８５２】
また、それぞれが＋１０又は−１０ずつ異なる奥行きを示す奥行き情報を、各オフセットシーケンスのプレーンオフセット方向情報、及び、プレーンオフセットシフト値として設定してもよい。
【０８５３】
(ファイル同士の対応付け)
第３実施形態において、識別情報を用いた対応付けの具体例ではレフトビューの識別番号に"１"を加算したものをライトビューの識別番号とした。しかし、レフトビューの識別番号に、"１００００"を加算したものをライトビューの識別番号として採用してもよい。
【０８５４】
ファイル名によるカップリング方式でファイルの対応付けてを実現する場合、再生装置側がカップリングされているファイルを見つけ出すための仕組みが必要となり、上述のようなルール付けされたファイルを見つけ出し、プレイリストから参照されていないファイルも再生する仕組みが必要である。これらの方法を用いる場合は、3D対応再生装置に上記の仕組みが必要となるが、2D映像と3D映像でプレイリストを分ける必要がなく、旧来より普及している2D再生装置で安全に動作させることも可能となる。
【０８５５】
Depth方式のためのグレースケールのように、１本では立体視映像を再生できないストリームに関しては、誤って機器がそのファイルを単体で再生しないように拡張子を変えて区別する。単体では再生できないファイルを識別するため3D対応ファイルを既存機器からDLNA(DigitalLiving Network Alliance)を介して参照する場合などのユーザー混乱を防止する。ファイル番号を同一にし、拡張子を区別することで、ファイル名だけでペアリング情報を表現することも可能になる。
【０８５６】
(立体視方式)
第１実施形態で説明の前提とした視差画像方式は、左右の映像を時間軸方向で交互に表示させるために、例えば、通常の2次元の映画であれば1秒に２４枚の映像を表示させるのに対して、左右の映像合わせて１秒に４８枚の映像を表示させる必要がある。従って、この方式では、一画面の書き換えが比較的早い表示装置において好適である。この視差画像を用いた立体視は、既に遊園地の遊具などで一般的に使用されており、技術的にも確立されているため、家庭における実用化に最も近いものと言える。視差画像を用いた立体視のための方法はこれらの他にも、2色分離方式などさまざまな技術が提案されている。本実施形態においては、継時分離方式あるいは偏光メガネ方式を例として用いて説明したが、視差画像を用いる限りこれら２方式に限定するものではない。
【０８５７】
TV３００についても、レンチキュラーレンズだけでなく、同様の機能を持たせたデバイス、例えば液晶素子を用いてもよい。また左目用の画素には縦偏光のフィルター、右目用の画素には横偏光のフィルターを設置し、視聴者は、左目用には縦偏光、右目用には横偏光のフィルターを設置した偏光メガネを用いて表示装置の画面を見ることによって立体視を実現させてもよい。
【０８５８】
(レフトビュー、ライトビューの適用対象)
レフトビューとライトビューを用意するのは、本編に関わるビデオストリームだけではなく、サムネイル画像に適用することも可能である。ビデオストリームの場合と同様に、2D再生装置では従来の2D用サムネイルを表示するが、3D再生装置では3D用に用意された左目サムネイルと右目サムネイルを、3D表示方式に合わせて出力する。
【０８５９】
同様に、メニュー画像や、チャプターサーチ用のシーン別サムネイル画像、シーン別縮小画面にも応用することが可能である。
（プログラムの実施形態）
各実施形態に示したアプリケーションプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０８６０】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０８６１】
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
【０８６２】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムをコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。
【０８６３】
（光ディスクの再生）
BD-ROMドライブは、半導体レーザ、コリメートレンズ、ビームスプリッタ、対物レンズ、集光レンズ、光検出器を有する光学ヘッドを備える。半導体レーザから出射された光ビームは、コリメートレンズ、ビームスプリッタ、対物レンズを通って、光ディスクの情報面に集光される。
【０８６４】
集光された光ビームは、光ディスク上で反射/回折され、対物レンズ、ビームスプリッタ、集光レンズを通って、光検出器に集光される。光検出器にて集光された光の光量に応じて、再生信号を生成する。
【０８６５】
(記録媒体のバリエーション)
各実施の形態における記録媒体は、光ディスク、半導体メモリーカード等、パッケージメディア全般を含んでいる。本実施の形態の記録媒体は予め必要なデータが記録された光ディスク（例えばBD-ROM、DVD-ROMなどの既存の読み取り可能な光ディスク）を例に説明をするが、これに限定される必要はなく、例えば、放送またはネットワークを経由して配信された本発明の実施に必要なデータを含んだ3Dコンテンツを光ディスクへ書き込む機能を有する端末装置（例えば左記の機能は再生装置に組み込まれていても良いし、再生装置とは別の装置であってもよい）を利用して書き込み可能な光ディスク（例えばBD-RE、DVD-RAMなどの既存の書き込み可能な光ディスク）に記録し、この記録した光ディスクを本発明の再生装置に適用しても本発明の実施は可能である。
【０８６６】
（半導体メモリカード記録装置及び再生装置の実施形態）
各実施の形態で説明をしたデータ構造を半導体メモリーに記録する記録装置、及び、再生する再生装置の実施形態について説明する。
【０８６７】
まず、前提となる技術として、BD-ROMに記録されているデータの著作権保護の仕組みについて説明する。
BD-ROMに記録されたデータのうち、例えば著作権の保護、データの秘匿性の向上の観点からデータの一部が、必要に応じて暗号化されている場合がある。
【０８６８】
例えば、BD-ROMに記録されたデータのうち、暗号化されているデータは、例えばビデオストリームに対応するデータ、オーディオストリームに対応するデータ、またはこれらを含むストリームに対応するデータであったりする。
【０８６９】
以後、BD-ROMに記録されたデータのうち、暗号化されているデータの解読について説明をする。
半導体メモリカード再生装置においては、BD-ROM内の暗号化されたデータを解読するために必要な鍵に対応するデータ（例えばデバイスキー）が予め再生装置に記憶されている。
【０８７０】
一方、BD-ROMには暗号化されたデータを解読するために必要な鍵に対応するデータ（例えば上述のデバイスキーに対応するMKB（メディアキーブロック））と、暗号化されたデータを解読するための鍵自体を暗号化したデータ（例えば上述のデバイスキー及びMKBに対応する暗号化タイトルキー）が記録されている。ここで、デバイスキー、MKB、及び暗号化タイトルキーは対になっており、さらにBD-ROM上の通常コピーできない領域（BCAと呼ばれる領域）に書き込まれた識別子（例えばボリュームID）とも対応付けがされている。この組み合わせが正しくなければ、暗号の解読ができないものとする。組み合わせが正しい場合のみ、暗号解読に必要な鍵（例えば上述のデバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を導き出すことができ、この暗号解読に必要な鍵を用いて、暗号化されたデータの解読が可能となる。
【０８７１】
装填されたBD-ROMを再生装置において再生する場合、例えばBD-ROM内の暗号化タイトルキー、MKBと対になっている（または対応する）デバイスキーが再生装置内になければ、暗号化されたデータは再生がなされない。何故ならば、暗号化されたデータの解読に必要な鍵（タイトルキー）は、鍵自体が暗号化されて（暗号化タイトルキー）BD-ROM上に記録されており、MKBとデバイスキーの組み合わせが正しくなければ、暗号の解読に必要な鍵を導き出すことができないからである。
【０８７２】
逆に暗号化タイトルキー、MKB、デバイスキー及びボリュームIDの組み合わせが正しければ、例えば上述の暗号解読に必要な鍵（デバイスキー、MKB及びボリュームIDを元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いてビデオストリームがデコーダにてデコードされ、オーディオストリームがオーディオデコーダにてデコードされるように再生装置は構成されている。
【０８７３】
以上が、BD-ROMに記録されているデータの著作権保護の仕組みであるが、この仕組みは、BD-ROMに必ずしも限定されるのではなく、例えば、読込み/書込み可能な半導体メモリー（例えばSDカードなどの可搬性を有する半導体メモリーカード）に適用した場合においても、実施が可能である。
【０８７４】
半導体メモリーカード再生装置の再生手順について説明する。光ディスクでは例えば、光ディスクドライブを介してデータを読み出すように構成していたのに対し、半導体メモリーカードを用いた場合には、半導体メモリーカード内のデータを読み出すためのI/Fを介してデータを読み出すように構成すればよい。
【０８７５】
より詳細には、再生装置のスロットに半導体メモリーカードが挿入されると、半導体メモリーカードI/Fを経由して再生装置と半導体メモリーカードが電気的に接続される。半導体メモリーカードに記録されたデータは半導体メモリーカードI/Fを介して読み出すように構成すれば良い。
【０８７６】
(受信装置としての実施形態)
各実施形態で説明した再生装置は、本実施の形態で説明をしたデータに相応するデータ（配信データ）を電子配信サービスの配信サーバから受信し、半導体メモリカードに記録する端末装置としても実現することができる。
【０８７７】
かかる端末装置は、各実施形態で説明した再生装置がそのような動作を行なえるように構成をされていても良いし、本実施の形態の再生装置とは別に半導体メモリーに配信データを記憶することを行う専用の端末装置にて行なうような形態であっても良い。ここでは再生装置が行なう例について説明をする。また記録先の半導体メモリーとしてSDカードを例に説明をする。
【０８７８】
再生装置が備えるスロットに挿入されたSDメモリーカードに配信データを記録する場合、まず配信データを蓄積する配信サーバへ配信データの送信を要求する。このとき再生装置は挿入したSDメモリーカードを一意に識別するための識別情報（例えば個々のSDメモリーカード固有の識別番号、より具体的には、例えばSDメモリーカードのシリアル番号等）をSDメモリーカードから読み出して、読み出した識別情報を配信要求とともに、配信サーバへ送信する。
【０８７９】
この、SDメモリーカードを一意に識別するための識別情報は例えば上述のボリュームIDに相当する。
一方、配信サーバでは、配信するデータのうち必要なデータ（例えばビデオストリーム、オーディオストリーム等）が暗号解読に必要な鍵（例えばタイトルキー）を用いて暗号の解除ができるように暗号化がなされてサーバ上に格納されている。
【０８８０】
例えば配信サーバは、秘密鍵を保持しており、半導体メモリーカードの固有の識別番号のそれぞれに対して異なる公開鍵情報が動的に生成できるように構成されている。
また、配信サーバは、暗号化されたデータの解読に必要な鍵（タイトルキー）自身に対して暗号化ができるように構成されている（つまり暗号化タイトルキーを生成できるように構成されている）。
【０８８１】
生成される公開鍵情報は例えば上述のMKB、ボリュームID及び暗号化タイトルキーに相当する情報を含む。暗号化されたデータは例えば半導体メモリー固有の識別番号、後述する公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しければ、暗号解読に必要な鍵（例えばデバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）が得られ、この得られた暗号解読に必要な鍵（タイトルキー）を用いて、暗号化されたデータの解読ができるものである。
【０８８２】
次に、再生装置は、受信した公開鍵情報と配信データをスロットに挿入した半導体メモリーカードの記録領域に記録する。
次に、半導体メモリーカードの記録領域に記録した公開鍵情報と配信データに含まれるデータのうち暗号化したデータを復号して再生する方法の一例について説明をする。
【０８８３】
受信した公開鍵情報は例えば公開鍵本体（例えば上述のMKB及び暗号化タイトルキー）、署名情報、半導体メモリーカードの固有の識別番号、および無効にすべきデバイスに関する情報を示すデバイスリストが記録されている。
【０８８４】
署名情報には例えば、公開鍵情報のハッシュ値を含む。
デバイスリストには例えば、不正に再生がなされる可能性があるデバイスに関する情報が記載されている。これは例えば再生装置に予め記録されたデバイスキー、再生装置の識別番号、または再生装置が備えるデコーダの識別番号といったように、不正に再生される可能性がある装置、装置に含まれる部品、または機能（プログラム）といったものを一意に特定するための情報である。
【０８８５】
半導体メモリーカードの記録領域に記録した配信データのうち、暗号化されたデータの再生に関し、説明をする。
まず、公開鍵本体を利用して暗号化したデータを復号する前に復号鍵本体を機能させてよいかどうかに関するチェックを行う。
【０８８６】
具体的には、（１） 公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致するかどうかのチェック（２）再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致するかのチェック（３） 公開鍵情報に含まれるデバイスリストに示される情報に基づいて、再生を行う再生装置が不正な再生が可能かどうかのチェック（例えば公開鍵情報に含まれるデバイスリストに示されるデバイスキーと、再生装置に予め記憶されたデバイスキーが一致するかどうかのチェック）
を行なう。これらのチェックを行なう順番は、どのような順序で行なってもよい。
【０８８７】
上述の（１）〜（３）のチェックにおいて、公開鍵情報に含まれる半導体メモリー固有の識別情報と半導体メモリーに予め記憶されている固有の識別番号とが一致しない、再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致しない、または、再生を行う再生装置が不正に再生される可能性があると判断した、のいずれかを満足すれば、再生装置は、暗号化されたデータの解読がなされないように制御する。
【０８８８】
また、公開鍵情報に含まれる半導体メモリーカードの固有の識別情報と半導体メモリーカードに予め記憶されている固有の識別番号とが一致し、かつ再生装置内で算出した公開鍵情報のハッシュ値と署名情報に含まれるハッシュ値が一致し、かつ再生を行う再生装置が不正に再生される可能性がないと判断したのであれば、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが正しいと判断し、暗号解読に必要な鍵（デバイスキー、MKB及び半導体メモリー固有の識別番号を元に、暗号化タイトルキーを復号して得られるタイトルキー）を用いて、暗号化されたデータの解読を行なう。
【０８８９】
例えば暗号化されたデータがビデオストリーム、オーディオストリームである場合、ビデオデコーダは上述の暗号解読に必要な鍵（暗号化タイトルキーを復号して得られるタイトルキー）を利用してビデオストリームを復号し（デコードし）、オーディオデコーダは、上述の暗号解読に必要な鍵を利用してオーディオストリームを復号する（デコードする）。
【０８９０】
このように構成をすることにより、電子配信時において不正利用される可能性がある再生装置、部品、機能（プログラム）などが分っている場合、これらを識別するための情報をデバイスリストに示して、配信するようにすれば、再生装置側がデバイスリストに示されているものを含むような場合には公開鍵情報（公開鍵本体）を用いた復号を抑止できるようにできるため、半導体メモリー固有の識別番号、公開鍵情報に含まれる公開鍵本体、および再生装置に予め記録されたデバイスキーの組み合わせが、たとえ正しくても、暗号化されたデータの解読がなされないように制御できるため、不正な装置上での配信データの利用を抑止することが可能となる。
【０８９１】
また半導体メモリーカードに予め記録されている半導体メモリーカードの固有の識別子は秘匿性の高い記録領域に格納するような構成を採用するのが望ましい。何故ならば、半導体メモリーカードに予め記録されている固有の識別番号（例えばSDメモリーカードを例にすればSDメモリーカードのシリアル番号等）は改竄がなされると、違法コピーが容易になされてしまう。何故ならば複数の半導体メモリーカードには、それぞれ異なる固有の識別番号が割り当てられているが、この固有の識別番号が同一となるように改竄がなされてしまえば、上述の（１）の判定が意味を成さなくなり、改竄がなされた数に相当する違法コピーがなされてしまう可能性があるからである。
【０８９２】
従って、半導体メモリーカードの固有の識別番号といった情報は秘匿性が高い記録領域に記録するような構成を採用するのが望ましい。
このような構成を実現するために、例えば半導体メモリーカードは、半導体メモリーカードの固有の識別子と言った秘匿性の高いデータを記録するための記録領域を通常のデータを格納する記録領域（第１の記録領域と称す）とは別の記録領域（第２の記録領域と称す）に設けること、およびこの第２の記録領域へのアクセスをするための制御回路を設けるとともに、第２の記録領域へのアクセスには制御回路を介してのみアクセスできるような構成とする。
【０８９３】
例えば、第２の記録領域に記録されているデータは暗号化がなされて、記録されており、制御回路は、例えば暗号化されたデータを復号するための回路が組み込まれている。制御回路へ第２の記録領域へのデータのアクセスが合った場合には、暗号を復号し、復号したデータを返すように構成すれば良い。または、制御回路は第２の記録領域に記録されているデータの格納場所の情報を保持しており、データのアクセスの要求があれば、対応するデータの格納場所を特定し、特定した格納場所から読み取ったデータを返すような構成としても良い。
【０８９４】
再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録する要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行すると、要求を受けた制御回路は第２の記録領域に記録されたデータを読み出して再生装置上で動作するアプリケーションへ返す。この半導体メモリーカードの固有の識別番号とともに必要なデータの配信要求を配信サーバに要求し、配信サーバから送られる公開鍵情報、および対応する配信データを第１の記録領域に記録するように構成すればよい。
【０８９５】
また、再生装置上で動作するアプリケーションで、電子配信を利用して半導体メモリーカードに記録を要求するアプリケーションは、メモリーカードI/Fを介して制御回路へ第２の記録領域に記録されたデータ（例えば半導体メモリ固有の識別番号）へのアクセス要求を発行する前に、アプリケーションの改竄がされていないかを事前にチェックすることが望ましい。改竄のチェックには例えば既存のX.５０９仕様に準拠したデジタル証明書を利用したチェックなどを利用しても良い。
【０８９６】
また、半導体メモリーカードの第１の記録領域に記録された配信データへのアクセスは半導体メモリーカードが有する制御回路を介してアクセスする必要は必ずしもない。
【産業上の利用可能性】
【０８９７】
本発明に係る情報記録媒体は3D映像を格納しているが、2D映像を再生する装置と3D映像を再生する装置のどちらでも再生できるため、互換性を意識することなく3D映像を格納した映画タイトルなどの動画コンテンツを市場に供給することができ、映画市場や民生機器市場を活性化させることができる。故に本発明に係る記録媒体、再生装置は、映画産業や民生機器産業において高い利用可能性をもつ
【符号の説明】
【０８９８】
１００  記録媒体
２００  再生装置
３００  表示装置
４００  3D眼鏡
５００  リモコン
【図１】
2012157069.tif 000003
【図２】
2012157069.tif 000004
【図３】
2012157069.tif 000005
【図４】
2012157069.tif 000006
【図５】
2012157069.tif 000007
【図６】
2012157069.tif 000008
【図７】
2012157069.tif 000009
【図８】
2012157069.tif 000010
【図９】
2012157069.tif 000011
【図１０】
2012157069.tif 000012
【図１１】
2012157069.tif 000013
【図１２】
2012157069.tif 000014
【図１３】
2012157069.tif 000015
【図１４】
2012157069.tif 000016
【図１５】
2012157069.tif 000017
【図１６】
2012157069.tif 000018
【図１７】
2012157069.tif 000019
【図１８】
2012157069.tif 000020
【図１９】
2012157069.tif 000021
【図２０】
2012157069.tif 000022
【図２１】
2012157069.tif 000023
【図２２】
2012157069.tif 000024
【図２３】
2012157069.tif 000025
【図２４】
2012157069.tif 000026
【図２５】
2012157069.tif 000027
【図２６】
2012157069.tif 000028
【図２７】
2012157069.tif 000029
【図２８】
2012157069.tif 000030
【図２９】
2012157069.tif 000031
【図３０】
2012157069.tif 000032
【図３１】
2012157069.tif 000033
【図３２】
2012157069.tif 000034
【図３３】
2012157069.tif 000035
【図３４】
2012157069.tif 000036
【図３５】
2012157069.tif 000037
【図３６】
2012157069.tif 000038
【図３７】
2012157069.tif 000039
【図３８】
2012157069.tif 000040
【図３９】
2012157069.tif 000041
【図４０】
2012157069.tif 000042
【図４１】
2012157069.tif 000043
【図４２】
2012157069.tif 000044
【図４３】
2012157069.tif 000045
【図４４】
2012157069.tif 000046
【図４５】
2012157069.tif 000047
【図４６】
2012157069.tif 000048
【図４７】
2012157069.tif 000049
【図４８】
2012157069.tif 000050
【図４９】
2012157069.tif 000051
【図５０】
2012157069.tif 000052
【図５１】
2012157069.tif 000053
【図５２】
2012157069.tif 000054
【図５３】
2012157069.tif 000055
【図５４】
2012157069.tif 000056
【図５５】
2012157069.tif 000057
【図５６】
2012157069.tif 000058
【図５７】
2012157069.tif 000059
【図５８】
2012157069.tif 000060
【図５９】
2012157069.tif 000061
【図６０】
2012157069.tif 000062
【図６１】
2012157069.tif 000063
【図６２】
2012157069.tif 000064
【図６３】
2012157069.tif 000065
【図６４】
2012157069.tif 000066
【図６５】
2012157069.tif 000067
【図６６】
2012157069.tif 000068
【図６７】
2012157069.tif 000069
【図６８】
2012157069.tif 000070
【図６９】
2012157069.tif 000071
【図７０】
2012157069.tif 000072
【図７１】
2012157069.tif 000073
【図７２】
2012157069.tif 000074
【図７３】
2012157069.tif 000075
【図７４】
2012157069.tif 000076
【図７５】
2012157069.tif 000077
【図７６】
2012157069.tif 000078
【図７７】
2012157069.tif 000079
【図７８】
2012157069.tif 000080
【図７９】
2012157069.tif 000081
【図８０】
2012157069.tif 000082
【図８１】
2012157069.tif 000083
【図８２】
2012157069.tif 000084
【図８３】
2012157069.tif 000085
【図８４】
2012157069.tif 000086
【図８５】
2012157069.tif 000087
【図８６】
2012157069.tif 000088
【図８７】
2012157069.tif 000089
【図８８】
2012157069.tif 000090
【図８９】
2012157069.tif 000091
【図９０】
2012157069.tif 000092
【図９１】
2012157069.tif 000093
【図９２】
2012157069.tif 000094
【図９３】
2012157069.tif 000095
【図９４】
2012157069.tif 000096
【図９５】
2012157069.tif 000097
【図９６】
2012157069.tif 000098
【図９７】
2012157069.tif 000099
【図９８】
2012157069.tif 000100
【図９９】
2012157069.tif 000101
【図１００】
2012157069.tif 000102
【図１０１】
2012157069.tif 000103
【図１０２】
2012157069.tif 000104
【図１０３】
2012157069.tif 000105
【図１０４】
2012157069.tif 000106