以下、本発明の好適な実施形態に係る記録媒体及び再生装置について、図面を参照しながら説明する。
<実施形態1>
先ず始めに、立体視の原理について簡単に述べる。
一般に右目と、左目とでは、その位置の差に起因して、右目から見える像と左目から見える像には見え方に若干の差がある。この差を利用して人間は目に見える像を立体として認識できるのである。立体表示をする場合には人間の視差を利用し平面の画像があたかも立体に見えるようにしている。
具体的には、平面表示の画像において、右目用の画像と左目用の画像には人間の視差に相当する見え方の差に相当する程度の差があり、これらの画像を短い時間間隔で切り替えて表示することにより、あたかも立体的な表示がなされているように見えるのである。
この短い時間間隔というのは、上述の切り替え表示により人間が立体的に見えると錯覚する程度の時間であればよい。立体視の実現法としては、ホログラフィ技術を用いる方法と、視差画像を用いる方式とがある。
まず、1つ目のホログラフィ技術の特徴としては、人間が通常物体を認識するのと全く同じように物体を立体として再現することができるが、動画生成に関しては、技術的な理論は確立しているが、ホログラフィ用の動画をリアルタイムで生成する膨大な演算量を伴うコンピューター、及び1mmの間に数千本の線を引けるだけの解像度を持った表示装置が必要であるが、現在の技術での実現は非常に難しく、商用として実用化されている例はほとんどない。
2つ目の視差画像を用いた方式である。この方式のメリットは、高々右目用と左目用の2つの視点の映像を準備するだけで立体視を実現できることにあり、技術的には、左右のそれぞれの目に対応した絵を、いかにして対応した目にだけ見せることができるかの観点から、継時分離方式を始めとするいくつかの技術が実用化されている。
継時分離方式とは、左目用映像及び右目用映像を時間軸方向で交互に表示させ、目の残像反応により左右のシーンを脳内で重ね合わさせて、立体映像として認識させる方法である。
上記の何れの方式においても、立体視映像は、少なくとも2つの視点映像から構成される。視点映像とは、何等かの偏向性をもった映像のことであり、少なくとも2つの視点映像のうち1つを“メインビュー映像”といい、メインビューに準ずる偏向性をもつ視点映像を“サブビュー”という。そしてメインビュー、サブビューがそれぞれ、ビデオストリームによって記録媒体から供給される場合、メインビューを供給するビデオストリームを“メインビュービデオストリーム”という。サブビューを供給するビデオストリームを“サブビュービデオストリーム”という。以降の説明で登場する記録媒体は、これらのメインビュービデオストリーム、サブビュービデオストリームを好適に記録するためのものである。
また本願明細書における再生装置は、上述したメインビュービデオストリーム、サブビュービデオストリームを再生するため、2D再生モード、3D再生モードという2つの再生モードを具備しており、これらの相互切り替えを可能とする2D/3D再生装置(プレーヤ)である。
図1は、記録媒体、再生装置、表示装置、眼鏡の使用行為についての形態を示す。同図(a)に示すように、記録媒体の一例である記録媒体100、再生装置200は、テレビ300、3D眼鏡400、リモコン500と共にホームシアターシステムを構成し、ユーザによる使用に供される。
記録媒体100は、上記ホームシアターシステムに、例えば映画作品を供給する。
再生装置200は、表示装置300と接続され、記録媒体100を再生する。
表示装置300はテレビであり、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。本実施形態の表示装置300は、3D眼鏡400をユーザが着用することで立体視を実現するものだが、表示装置300がレンチキュラー方式のものなら、3D眼鏡400は不要となる。レンチキュラー方式の表示装置300は、画面中の縦方向に左目用のピクチャーと右目用のピクチャーを同時に交互に並べ、表示装置の画面表面にレンチキュラーレンズと呼ばれる蒲鉾状のレンズを通して、左目用のピクチャーを構成する画素は左目だけに結像し、右目用のピクチャーを構成する画素は右目だけに結像するようにすることで、左右の目に視差のあるピクチャーを見せ、立体視を実現させる。
3D眼鏡400は、液晶シャッターを備え、継時分離方式あるいは偏光メガネ方式による視差画像をユーザに視聴させる。視差画像とは、右目に入る映像と、左目に入る映像とから構成される一組の映像であり、それぞれの目に対応したピクチャーだけがユーザの目に入るようにして立体視を行わせる。 同図(b)は、左目用映像の表示時を示す。画面上に左目用の映像が表示されている瞬間において、前述の3D眼鏡400は、左目に対応する液晶シャッターを透過にし、右目に対応する液晶シャッターは遮光する。同図(c)は、右目用映像の表示時を示す。画面上に右目用の映像が表示されている瞬間において、先ほどと逆に右目に対応する液晶シャッターを透光にし、左目に対応する液晶シャッターを遮光する。
リモコン500は、AV再生のための操作項目を受け付けるための機器である。またリモコン500は、階層化されたGUIに対する操作をユーザから受け付ける機器であり、かかる操作受け付けのため、リモコン500は、GUIを構成するメニューを呼び出すメニューキー、メニューを構成するGUI部品のフォーカスを移動させる矢印キー、メニューを構成するGUI部品に対して確定操作を行う決定キー、階層化されたメニューをより上位のものにもどってゆくための戻りキー、数値キーを備える。
図1のホームシアターシステムにおいて、3D再生モードでの画像表示を表示装置300に行わせる再生装置の出力モードを"3D出力モード"という。2D再生モードでの画像表示を表示装置300に行わせる再生装置の出力モードを"2D出力モード"という。
以上が、記録媒体及び再生装置の使用形態についての説明である。
本実施形態では、立体視に使う視差画像を情報記録媒体に格納する方法を説明する。
視差画像方式は、右目に入る映像と、左目に入る映像とを各々用意し、それぞれの目に対応したピクチャーだけが入るようにして立体視を行う方法である。図2は、ユーザーの顔を左側に描き、右側には、対象物たる恐竜の骨格を左目から見た場合の例と、対象物たる恐竜の骨格を、右目から見た場合の例とを示している。右目及び左目の透光、遮光から繰り返されば、ユーザの脳内では、目の残像反応により左右のシーンの重合せがなされ、顔の中央の延長線上に立体映像が存在すると認識することができる。
視差画像のうち、左目に入る画像を左目画像(L画像)といい、右目に入る画像を右目画像(R画像)という。そして、各々のピクチャが、L画像になっている動画像をレフトビュービデオといい、各々のピクチャがR画像になっている動画像をライトビュービデオという。そして、レフトビュービデオ、ライトビュービデオをデジタル化し、圧縮符号化することにより得られるビデオストリームを、レフトビュービデオストリーム、ライトビュービデオストリームという。
これらのレフトビュービデオストリーム、ライトビュービデオストリームは、時間方向の相関特性を利用したピクチャ間予測符号化に加えて、視点間の相関特性を利用したピクチャ間予測符号化によって圧縮されている。ライトビュービデオストリームのピクチャは、レフトビュービデオストリームの同じ表示時刻のピクチャを参照して圧縮されている。視点間の相関特性を利用したビデオ圧縮の方法としては、Multiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格がある。ISO/IEC MPEGとITU-T VCEGの共同プロジェクトであるJoint Video Team(JVT)は、2008年7月にMultiview Video Coding(MVC)と呼ばれるMPEG-4 AVC/H.264の修正規格の策定を完了した。MVCは、複数視点の映像をまとめて符号化する規格であり、映像の時間方向の類似性だけでなく視点間の類似性も予測符号化に利用することで、複数視点の独立した圧縮に比べて圧縮効率を向上している。
そして、MVCによって圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームのうち、単体で復号化が可能になるものを"ベースビュービデオストリーム"という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、後述するベースビューインディケータによって定まる。また、レフトビュービデオストリーム及びライトビュービデオストリームのうち、ベースビュービデオストリームを構成する個々のピクチャデータとのフレーム間相関特性に基づき圧縮符号化されており、ベースビュービデオストリームが復号された上で復号可能になるビデオストリームを、"ディペンデントビュービデオストリーム"という。
視点間の相関性に基いて圧縮符号化されたレフトビュービデオストリーム及びライトビュービデオストリームであって、単体で復号化が可能になるものを"ベースビュービデオストリーム"という。レフトビュービデオストリーム及びライトビュービデオストリームの何れを、ベースビュービデオストリームに指定するかは、プレイアイテム情報内のベースビューインディケータによって定まる。
現状における立体視映像の符号化は、このMVC方式によるものが最良であると考えられるので、以降の説明では、“メインビュービデオストリーム”が“ベースビュービデオストリーム”であり、“サブビュービデオストリーム”が“ディペンデントビュービデオストリーム”であるとして説明を行う。
MVCビデオストリームの基礎となるMPEG4-AVC形式のビデオストリームについて説明する。
MVCビデオストリームは、GOP構造を有しており、クローズドGOP、オープンGOPから構成される。クローズドGOPは、IDRピクチャと、このIDRピクチャに続くBピクチャと、Pピクチャとから構成される。オープンGOPは、Non-IDR Iピクチャと、Non-IDR Iピクチャに続くBピクチャと、Pピクチャとから構成される。
Non-IDR Iピクチャ、Pピクチャ、Bピクチャは、他のピクチャとのフレーム相関性に基づき圧縮符号化されている。Bピクチャとは、Bidirectionally predictive(B)形式のスライスデータからなるピクチャをいい、Pピクチャとは、Predictive(P)形式のスライスデータからなるピクチャをいう。Bピクチャには、refrenceB(Br)ピクチャと、nonrefrenceB(B)ピクチャとがある。
クローズドGOPは、IDRピクチャが先頭に配置される。表示順序においてIDRピクチャは先頭にならないが、IDRピクチャ以外の他のピクチャ(Bピクチャ,Pピクチャ)は、クローズドGOPより前のGOPに存在するピクチャと依存関係をもつことはできない。このようにクローズドGOPは、依存関係を完結させる役割をもつ。
次にGOPの内部構成について説明する。オープンGOP、クローズドGOPにおける個々のピクチャデータは、H.264符号化方式におけるビデオアクセスユニット構造を有している。各ビデオアクセスユニットは、ビデオアクセスユニットデリミター、シーケンスパラメータセット、ピクチャパラメータセット、ビューコンポーネントを配列することにより構成される。
ビューコンポーネントとは、アクセスユニット構造を有しつつも、視点間の相関性に基づき圧縮符号化されているピクチャデータである。
ビデオアクセスユニットデリミターは、ネットワーク抽象化ユニットに変換されてソースパケットに格納される。このソースパケットからの読み出しを行うのであれば、ビデオストリーム内部におけるランダムアクセスが可能になる。
ビデオアクセスユニットと、ピクチャとの関係は、1ビデオアクセスユニット = 1ピクチャである。またBD-ROMでは、1PESパケット = 1フレームに制限されている。つまり、動画がフレーム構造であれば、1PESパケット = 1ピクチャであり、フィールド構造である場合、1PESパケット=2ピクチャとなる。これらのことから、PESパケットは、ピクチャを、1対1の比率で格納している。
図3は、立体視のためのレフトビュービデオストリーム、ライトビュービデオストリームの内部構成の一例を示す。
本図の第2段目は、レフトビュービデオストリームの内部構成を示す。このストリームには、ピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9というピクチャデータが含まれている。これらのピクチャデータは、Decode Time Stamp(DTS)に従いデコードされる。第1段目は、左目画像を示す。そうしてデコードされたピクチャデータI1,P2,Br3,Br4,P5,Br6,Br7,P9をPTSに従い、I1,Br3,Br4,P2,Br6,Br7,P5の順序で再生することで、左目画像が再生されることになる。
第4段目は、ライトビュービデオストリームの内部構成を示す。このライトビュービデオストリームは、P1,P2,B3,B4,P5,B6,B7,P8というピクチャデータが含まれている。これらのピクチャデータは、DTSに従いデコードされる。第3段目は、右目画像を示す。そうしてデコードされたピクチャデータP1,P2,B3,B4,P5,B6,B7,P8をPTSに従い、P1,B3,B4,P2,B6,B7,P5の順序で再生することで、右目画像が再生されることになる。 ここで両ビデオストリームの間では、3D映像の同じフレーム又はフィールドを表す一対のピクチャに対して同じPTS及び同じDTSが割り当てられている。
第5段目は、3D眼鏡400の状態をどのように変化させるかを示す。この第5段目に示すように、左目画像の視聴時は、右目のシャッターを閉じ、右目画像の視聴時は、左目のシャッターを閉じていることがわかる。
本図において、例えば、ライトビュービデオストリームの先頭Pピクチャは、レフトビュービデオストリームのIピクチャを参照し、ライトビュービデオストリームのBピクチャは、レフトビュービデオストリームのBrピクチャを参照し、ライトビュービデオストリームの二つ目のPピクチャは、レフトビュービデオストリームのPピクチャを参照している。ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを1/48秒の表示周期において、"B"ー"D"ー"B"ー"D"というように交互で出力するモードを、"B−Dプレゼンテーションモード"という。
ベースビュービデオストリームのビデオフレームと、ディペンデントビューストリームのビデオフレームとを交互に出力するのではなく、再生モードを3Dモードに維持したまま、同じビデオフレームを2回以上繰り返し出力するという処理を行う再生タイプを、B−Bプレゼンテーションモードという。B−Bプレゼンテーションモードでは、単独再生可能なベースビュービデオストリームのビデオフレームのみが"B"−"B"−"B"−"B"というように繰り返し出力される。
更に、B−Dプレゼンテーションモードには、L画像、R画像を用いて立体視効果を実現する3D-LR方式の他、2D画像と、深度情報とを用いて立体視効果を実現する3D-Depth方式がある。
3D-Depth方式とは、ビデオデコーダの後段に、視差映像生成器を組み入れて、ビデオストリームにおける個々のピクチャデータと、このピクチャデータにおける個々の画素の深度情報とからレフトビューピクチャデータ、ライトビューピクチャデータを作り出させるモードである。
この深度情報は、画素の深度を濃淡で表すグレースケールのピクチャデータ(深度情報ピクチャデータと呼ばれる)として構成することができる。
図4は、デプスビュー方式の一例を示す。同図(a)は、2D画像であり、同図(b)は、(a)に示した2Dに対して作成されたグレースケールを示す。グレースケールは、輝度成分のみの画素によって表現される。グレースケールの画素のうち、輝度が高いもの程(白いもの程)、奥行きが浅く、輝度が低いもの程(黒いもの程)、奥行きが深いことを示す。同図(c)、(d)は、グレースケールを用いることで生成される左目映像、右目映像を示す。図5は、3D-Depthモードで生成される立体視画像を示す。2Dの各フレーム毎に、左目映像、右目映像を生成すれば、ゴーグルを通じて左目映像、右目映像を見ることで、ユーザは立体視を楽しむことができる。
3D-Depth方式では、2D再生可能なビデオストリームがベースビュービデオストリームになる。グレースケールのピクチャデータから構成されるビデオストリームが、ディペンデントビュービデオストリームになる。
この3D-Depth方式において利用するグレースケールのピクチャデータをデジタル化し、圧縮符号化することにより得られるビデオストリームを、デプスマップストリームという。デプスマップストリームは、時間方向の相関特性を利用したピクチャ間予測符号化によって圧縮され、視点間の相関を持たないビデオストリームであるが、ビデオストリームのフォーマットは、3D-LR方式で用いるディペンデントビュービデオストリームと同じにしておく。例えば、レフトビュービデオストリーム及びライトビュービデオストリームがMVCフォーマットで符号化されている場合は、デプスマップストリームも同様にMVCフォーマットでエンコードする。このような構成にすることで、3D-LR方式と3D-Depth方式との再生の切り替えを、再生装置の構成を変えることなくスムーズに行うことができる。
以下、3D-LR方式を用いたB−DプレゼンテーションモードをL/Rモードとし、3D-Depth方式を用いたB−Dプレゼンテーションモードをデプスモードとする。デプスモードと、L/Rモードとでは、ベースビュービデオストリームは共通化することができるため、ベースビュービデオストリームに組合せるべきビデオストリームを変化させれば、L/Rモード、デプスモードの映像を生成することができる。データ管理構造からこれらの組み合わせを扱い、プレーヤおよび接続されているテレビ側の特性に合わせて、表示方法を切り替える。
<記録媒体100>
本発明に係る記録媒体は、多層化された光ディスクであるBD-ROMディスク、BD-ROMディスクと再生互換性があるようなBD-REディスク、BD-Rディスク、AVC-HDメディアとして作成することができる。
図6は、多層化された光ディスクの内部構成を示す。
第1段目は、多層化された光ディスクの一例であるBD-ROMを示し、第2段目は、各記録層上に存在する螺旋トラックを水平方向に引き伸ばして描いた図である。これらの記録層における螺旋トラックは、1つの連続したボリューム領域として扱われる。ボリューム領域は、最内周に位置するリードイン、最外周に位置するリードアウト、この間に存在する第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域から構成される。これらの第1記録層の記録領域、第2記録層の記録領域、第3記録層の記録領域は、1つの連続した論理アドレス空間を構成する。
ボリューム領域は、先頭から光ディスクをアクセスする単位で通し番号が振られており、この番号のことを論理アドレスと呼ぶ。光ディスクからのデータの読み出しは論理アドレスを指定することで行う。ここで、BD-ROMのような読み込み専用ディスクの場合には、基本的に論理アドレスが連続しているセクタは、光ディスク上の物理的な配置においても連続している。すなわち、論理アドレスが連続しているセクタのデータはシークを行わずに読み出すことが可能である。ただし、記録層の境界においては、論理アドレスが連続していたとしても連続的な読み出しはできない。そのため、層境界の論理アドレスは、予め記録装置に登録されているものとする。
ボリューム領域は、リードイン領域の直後にファイルシステム管理情報が記録されていて、これに続いて、ファイルシステム管理情報にて管理されるパーティション領域が存在する。ファイルシステムとはディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みであり、BD-ROMの場合ではUDF(Universal Disc Format)によって記録される。日常使っているPC(パーソナルコンピュータ)の場合でも、FATまたはNTFSと呼ばれるファイルシステムを通すことにより、ディレクトリやファイルという構造でハードディスクに記録されたデータがコンピュータ上で表現され、ユーザビリティを高めている。このファイルシステムにより、通常のPCと同じように記録されている論理データをディレクトリ/ファイル構造を使って読み出すことが可能になっている。
第4段目は、ファイルシステムで管理されるパーティション領域の記録内容を示す。パーティション領域には、ファイルを構成するエクステントが存在する。エクステントは、パーティション領域において、物理的に連続する複数のセクタ上に形成される。
パーティション領域は、「ファイルセット記述子が記録された領域」、「終端記述子が記録された領域」、「ROOTディレクトリ領域」、「BDMVディレクトリ領域」、「JARディレクトリ領域」、「BDJOディレクトリ領域」、「PLAYLISTディレクトリ領域」、「CLIPINFディレクトリ領域」、「STREAMディレクトリ領域」から構成される。以降、これらの領域について説明する。
「ファイルセット記述子」は、ディレクトリ領域のうち、ROOTディレクトリのファイルエントリが記録されているセクタを指し示す論理ブロック番号(LBN)を含む。「終端記述子」は、ファイルセット記述子の終端を示す。
次に、各ディレクトリ領域の詳細について説明する。上述したような複数のディレクトリ領域は、何れも共通の内部構成を有している。つまり、「ディレクトリ領域」は、「ファイルエントリ」と、「ディレクトリファイル」と、「下位ファイルについてのファイル記録領域」とから構成される。
「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
「アロケーション記述子」は、ディレクトリファイルの記録位置を示す論理ブロック番号(LBN)を含む。以上がファイルエントリーについての説明である。続いて、ディレクトリファイルの詳細について説明する。
各ディレクトリ領域に含まれる「ディレクトリファイル」は、「下位ディレクトリについてのファイル識別記述子」と、「下位ファイルのファイル識別記述子」とを含む。
「下位ディレクトリのファイル識別記述子」は、自身の配下にある下位ディレクトリをアクセスするための参照情報であり、その下位ディレクトリを示す識別情報と、その下位ディレクトリのディレクトリ名の長さと、下位ディレクトリのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、その下位ディレクトリのディレクトリ名とから構成される。
「下位ファイルのファイル識別記述子」は、自身の配下にあるファイルをアクセスするための参照情報であり、その下位ファイルを示す識別情報と、その下位ファイル名の長さと、下位ファイルについてのファイルエントリがどの論理ブロック番号に記録されているかを示すファイルエントリアドレスと、下位ファイルのファイル名とから構成される。
このように各ディレクトリのディレクトリファイルにおけるファイル識別記述子には、下位ディレクトリ及び下位ファイルのファイルエントリーが、どの論理ブロックに記録されているかが示されているので、このファイル識別記述子を辿ってゆけば、ROOTディレクトリのファイルエントリーからBDMVディレクトリのファイルエントリーに到達することができ、また、BDMVディレクトリのファイルエントリーからPLAYLISTディレクトリのファイルエントリーに到達することができる。同様に、JARディレクトリ、BDJOディレクトリ、CLIPINFディレクトリ、STREAMディレクトリのファイルエントリーにも到達することができる。以上がディレクトリファイルについての説明である。続いて、下位ファイルについてのファイル記録領域の詳細について説明する。
各ディレクトリ領域に含まれる「下位ファイルについてのファイル記録領域」とは、あるディレクトリの配下にある下位ファイルの実体が記録されている領域であり、当該下位ファイルについての「ファイルエントリ」と、ファイルエントリにより管理される1つ以上の「エクステント」とが記録されている。また、あるディレクトリの配下に複数の下位ファイルが含まれる場合には、ディレクトリ領域には複数の「下位ファイルについてのファイル記録領域」が存在することになる。
下位ファイルの「ファイルエントリ」は、「記述子タグ」と、「ICBタグ」と、「アロケーション記述子」とを含む。
「記述子タグ」は、自身がファイルエントリである旨を示すタグである。タグには、ファイルエントリ記述子、スペースビットマップ記述子などの種別があるが、ファイルエントリの場合には、記述子タグとしてファイルエントリを示す"261"が記述される。
「ICBタグ」は、ファイルエントリ自身に関する属性情報を示す。
下位ファイルにおける「アロケーション記述子」は、あるディレクトリの配下にある下位ファイルを構成するエクステントの記録位置を示す論理ブロック番号(LBN)と、エクステント長を示すデータを含む。ただしエクステント長を示すデータの上位2ビットは、“00”に設定されることで、割り付け済みかつ記録済みエクステントである旨を示し、“01”に設定されることで、割り付け済みかつ未記録エクステントである旨を示す。“11”に設定されることで、アロケーション識別子の続きのエクステントであることを示す。あるディレクトリの配下にある下位ファイルが複数のエクステントに分割されている場合には、ファイルエントリはエストテント毎に複数のアロケーション記述子を有することになる。
UDFにおけるファイルは、ファイルエントリーによって管理されている複数のエクステントから構成され、上述したようなファイルエントリーのアロケーション識別子を参照することで、ファイルを構成するエクステントの論理アドレスを知得することができる。
例えば、本願の主眼となるストリームファイルは、そのファイルが帰属するディレクトリのディレクトリ領域内に存在するファイル記録領域のことであり、ディレクトリファイルにおけるファイル識別記述子、及び、ファイルエントリーにおけるアローケーション識別子を辿ってゆくことで、アクセスすることができる。
図7は、ファイルシステムを前提にした記録媒体100のアプリケーションフォーマットを示す。
BDMVディレクトリはBD-ROMで扱うTSや管理情報などのデータが記録されているディレクトリである。BDMVディレクトリの配下には、「PLAYLISTディレクトリ」、「CLIPINFディレクトリ」、「STREAMディレクトリ」、「BDJOディレクトリ」、「JARディレクトリ」と呼ばれる5つのサブディレクトリが存在し、BDMVディレクトリには、「index.bdmv」,「MovieObject.bdmv」の2種類のファイルが配置されている。
以下に、BDMVディレクトリ配下に置かれる各ファイルについて説明する。
「index.bdmv(ファイル名固定)」は、BD-ROMにおいて再生可能となる複数タイトルのタイトル番号と、個々のタイトルを規定するプログラムファイル、つまり、BD-Jオブジェクト又はムービーブジェクトとの対応付けを示すインデックステーブルを格納しているインデックステーブルファイルである。
インデックステーブルファイルは記録媒体全体に関する管理情報であり、再生装置への挿入後に、インデックステーブルファイルが最初に読み出されることで、再生装置においてディスクが一意に認識される。インデックステーブルファイルは、光ディスクのタイトル構造を構成する個々のタイトルと、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。タイトル構造とは、光ディスクの装填時に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を伴うタイトル(ファーストプレイタイトル)の再生を開始し、ファーストプレイタイトルの再生後、映画作品の本編を構成する一般タイトル("1"、"2"、"3"というようなシリアル番号で識別される一般的なタイトル)の再生を行い、本編タイトルの再生が終了すれば、タイトル選択を受け付けるタイトル(メニュータイトル)を再生してユーザによる一般タイトルの選択待ちを行うというものである。映画作品と、タイトルとの関係は、映画作品と、それの複数バージョンとの関係である。つまり1つのバージョンしかないような映画作品は、「映画作品=タイトル」という関係になる。映画作品に、劇場公開版、ディレクターズカット版、TV放映版等、複数のバージョンがある場合、映画作品における個々のバージョンが1つのタイトルになる。再生装置には、カレントのタイトル番号を格納するタイトル番号レジスタを含み、複数のタイトルのうち、このタイトル番号レジスタに格納されているものが、現在の再生対象になる。光ディスクのタイトルは、上述したようなファーストプレイタイトル、一般タイトル、メニュータイトルのそれぞれに、動作モードを規定する動作モードオブジェクトを割り当てることで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。インデックステーブルでは、タイトルと、ビデオストリームとの関係を直接記述せず、タイトルと、動作モードオブジェクトとの関係を記述して、動作モードオブジェクトを通じてビデオストリームを再生させるようになっている。これば、AV再生を伴わず、動作モードオブジェクトを動作させるだけのタイトルを規定するためである。
「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プログラム、及び、データから、アプリケーションは構成されることになる。
「STREAMディレクトリ」は、ストリームファイルを格納しているディレクトリであり、本ディレクトリには、xxxxx.m2ts(["xxxxx"は可変、拡張子"m2ts"は固定])、及びxxxxx.ssif(["xxxxx"は可変、拡張子"ssif"は固定])という形式でストリームファイルが格納される。本実施形態におけるストリームファイルは、記録媒体100上に記録された映像コンテンツの実体のうち、ファイルシステムの定めるファイル形式に整えられたものをいう。ここで、映像コンテンツの実体は一般に、映像・音声・字幕等を表す各種のストリームデータが多重化されたストリームデータを意味する。この多重化ストリーム・データは内蔵のプライマリ・ビデオ・ストリームの種類に依って、メイン・トランスポート・ストリーム(TS)とサブTSとに大別される。「メインTS」はプライマリ・ビデオ・ストリームとしてベースビュー・ビデオ・ストリームを含む。「ベースビュー・ビデオ・ストリーム」は単独で再生可能であり、2D映像を表す。「サブTS」はプライマリ・ビデオ・ストリームとしてディペンデントビュー・ビデオ・ストリームを含む。「ディペンデントビュー・ビデオ・ストリーム」は、その再生にベースビュー・ビデオ・ストリームを必要とし、そのベースビュー・ビデオ・ストリームとの組み合わせで3D映像を表す。ディペンデントビュー・ビデオ・ストリームの種類には、ライトビュー・ビデオ・ストリーム、レフトビュー・ビデオ・ストリーム、及びデプスマップ・ストリームがある。「ライトビュー・ビデオ・ストリーム」は、ベースビュー・ビデオ・ストリームの表す2D映像がL/Rモードの再生装置によって3D映像のレフトビューとして利用されるとき、その3D映像のライトビューを表すビデオ・ストリームとして利用される。「レフトビュー・ビデオ・ストリーム」はその逆である。「デプスマップ・ストリーム」は、ベースビュー・ビデオ・ストリームの表す2D映像がデプス・モードの再生装置によって仮想的な2D画面への3D映像の射影として利用されるとき、その3D映像のデプスマップを表すストリーム・データとして利用される。
AVストリーム・ファイルは内蔵の多重化ストリーム・データの種類に依って、ファイル2D、ファイル・ディペンデント(以下、ファイルDEPと略す。)、及びインターリーブ・ファイル(以下、ファイルSSと略す。)の三種類に分けられる。「ファイル2D」は2D再生モードでの2D映像の再生に利用される平面視再生用ストリームファイルであり、メインTSを含む。「ファイルDEP」はサブTSを含む。「ファイルSS」は、3D再生モードでの3D映像の再生に利用される立体視再生用ストリームファイルであり、同じ3D映像を表すメインTSとサブTSとの対を含む。ファイルSSは特に、そのメインTSをいずれかのファイル2Dと共有し、そのサブTSをいずれかのファイルDEPと共有する。すなわち、記録媒体100のファイルシステムでは、メインTSはファイルSSとファイル2Dとのいずれとしてもアクセス可能であり、サブTSはファイルSSとファイルDEPとのいずれとしてもアクセス可能である。このように、記録媒体100上に記録された一連のデータを異なるファイルに共有させ、いずれのファイルとしてもアクセス可能にする仕組みを「ファイルのクロスリンク」という。このようなファイル2DとファイルDEPとは、m2tsという拡張子を付して、STREAMディレクトリの直下に置かれ、ファイルSSは、ssifという拡張子を付して、STREAMディレクトリの下位ディレクトリであるSSIFディレクトリの直下に置かれる。
「PLAYLISTディレクトリ」には、拡張子mplsが付与されたプレイリスト情報ファイル(xxxxx.mpls["xxxxx"は可変、拡張子"mpls"は固定])が存在する。プレイリスト情報ファイルは、再生装置にプレイリストを再生させるための情報を格納したファイルである。"プレイリスト"とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもち、プレイリスト情報は、かかるプレイリストの"型"を定義する。プレイリスト情報によって定義される再生経路は、いわゆる"マルチパス"である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるストリームに対して定義された再生経路(サブパス)とを束ねたものである。メインパスに含まれる再生区間を、プレイアイテムと呼び、サブンパスに含まれる再生区間は、サブプレイアイテムと呼ぶ。メインパスは1本であるのに対して、サブパスは、複数本定義することができ、これら複数のサブパスは、サブパスIDと呼ばれる識別子によって識別される。かかるマルチパスの再生時間軸には、チャプター位置が定義される。このチャプター位置を再生装置に参照させることにより、マルチパスの時間軸に対する任意の時点に対するランダムアクセスを再生装置に実現させる。BD-Jモードでは、再生制御のためのJava(登録商標)アプリケーションが、このプレイリスト情報を再生するJMF(Java(登録商標)Media Frame work)プレーヤインスタンスの生成をJava(登録商標)仮想マシンに命じることで、マルチパスによるAV再生を開始させることができる。JMFプレーヤインスタンスとは、JMFプレーヤクラスを基にして仮想マシンのヒープメモリ上に生成される実際のデータのことである。HDMVモードでは、プレイリストによる再生を命じるナビゲーションコマンドを再生装置に実行させることで、再生を開始することができる。再生装置には、カレントのプレイリスト情報の番号を格納するプレイリスト番号レジスタを含み、複数のプレイリスト情報のうち、このプレイリスト番号レジスタに格納されているものが、現在の再生対象になる。プレイリスト情報ファイルの種類には2Dプレイリスト情報ファイルと3Dプレイリスト情報ファイルとがある。「2Dプレイリスト情報ファイル」はファイル2Dの再生経路を規定する。「3Dプレイリスト情報ファイル」は、2D再生モードの再生装置に対してはファイル2Dの再生経路を規定し、3D再生モードの再生装置に対してファイルSSの再生経路を規定する。
「CLIPINFディレクトリ」には、拡張子clpiが付与されたクリップ情報ファイル(xxxxx.clpi ["xxxxx"は可変、拡張子"clpi"は固定])が存在する。クリップ情報ファイルは、ファイル2D及びファイルDEPのそれぞれと一対一の割合で存在するクリップ情報ファイルであり、ストリームファイル内に存在するソースパケット列がどのようなATCシーケンスを構成するか、それらのATCシーケンス内にどのようなSTCシーケンスが組込まれているのか、ATCシーケンスがどのようなTSであるのかを示す。
クリップ情報ファイルは、ストリームファイルの中身を明らかにするものなので、ストリームファイル内のTSを再生しようとする場合、そのストリームファイルに対応するクリップ情報ファイルを予めメモリに読み出しておく必要がある。つまり、ストリームファイル再生にあたっては、予めクリップ情報ファイルをメモリに読み出すという前置主義が採用される。このような前置主義を採用しているのは以下の理由による。ストリームファイルに格納されるTSは、欧州デジタル放送規格と互換性があるデータ構造になっているが、放送番組として扱うためのPMT、PCR、PATといった情報はストリーム内に存在するため、これらを再生する度に取り出すのは賢明ではない。ストリームを再生する度に、低速な記録媒体をアクセスしてTSを構成するパケットを読み出し、そのTSパケットのペイロードを解析するという処理が必要になるからである。そこで、TSを構成するペイロードの中身を解析することなく、TSの諸元を把握できるよう、TSを格納したストリームファイルと一対一の比率でクリップ情報ファイルを設けておき、ストリーム再生に先立ち、クリップ情報ファイルをメモリに読み出すことにしている。本実施形態において、クリップ情報ファイルのうち、ファイル2Dに対応付けられているものを「2Dクリップ情報ファイル」といい、ファイルDEPに対応付けられているものを「ディペンデントビュー・クリップ情報ファイル」という。更に、ファイルDEPがライトビュー・ビデオ・ストリームを含むとき、対応するディペンデントビュー・クリップ情報ファイルを「ライトビュー・クリップ情報ファイル」という。ファイルDEPがデプスマップ・ストリームを含むとき、対応するディペンデントビュー・クリップ情報ファイルを「デプスマップ・クリップ情報ファイル」という。
<ストリームファイル>
以下、ストリームファイルの詳細について説明する。
ストリームファイルは、1又複数のソースパケット列を格納している。ソースパケットとは、2ビットのコピーパーミッションインディケータと、30ビットのATS(到着時刻:Arrival Time Stamp)とから構成される4バイトのTP_Extra_Headerが付加されたTSパケットである。TP_Extra_HeaderにおけるATSは、実時間伝送が行われ、等時性が確保された状態での伝送における到達時刻をいう。
これらのソースパケット列のうち、アライバルタイムクロック(ATC)時間軸において、タイムスタンプが連続している複数のソースパケットから構成されているものを"ATCシーケンス"と呼ぶ。"ATCシーケンス"とは、ソースパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(no arrival time-base discontinuity)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するソースパケット列を"ATCシーケンス"という。ATCシーケンスは、ATCのタイムスタンプが連続しているソースパケット列であるから、再生装置のアライバルタイムクロックを計時するクロックカウンタが計時を行っている間、ATCシーケンスを構成する各ソースパケットは、連続的なソースパケットデパケッタイジング処理、及び、連続的なパケットフィルタリング処理に供されることになる。
ATCシーケンスがソースパケットの配列であるのに対し、STC時間軸におけるタイムスタンプが連続しているTSパケットの配列をSTCシーケンスという。"STCシーケンス"とは、TSパケットの配列であって、TSのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)をもたないものをいう。STCの不連続点とは、デコーダがSTCを得るために参照するPCR(Program Clock Reference)を運ぶPCRパケットの不連続情報(discontinuity_indicator)がONである点である。STCシーケンスは、STCのタイムスタンプが連続しているTSパケット列であるから、再生装置のシステムタイムクロックを計時するクロックカウンタが計時を行っている間、STCシーケンスを構成する各TSパケットは、再生装置内に存在するデコーダの連続的なデコード処理に供されることになる。
またストリームファイルに格納されるパケット列は、複数種別の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"という。
図8(a)は、メインTSの内部構成を示し、図8(b)は、サブTSの内部構成を示す。同図(a)に示すように、メインTSは、1本のベースビュービデオストリームと、32本のベースビューPGストリーム、32本のベースビューIGストリーム、32本のオーディオストリームを含むものとする。同図(b)に示すように、サブTSは、1本のディペンデントビュービデオストリームと、32本のディペンデントビューPGストリーム、32本のディペンデントビューIGストリームを含むものとする。
次に、TSの内部構成について説明する。
図9は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示している。本図(a)における第1段目はビデオストリームのビデオフレーム列を示す。第2段目は、PESパケット列を示す。第3段目は、これらのPESパケット列を変換することで得られるTSパケット列を示す。本図の矢印yy1,yy2, yy3, yy4に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS(Presentation Time-Stamp)やピクチャの復号時刻であるDTS(Decoding Time-Stamp)が格納される。
<TSパケット列>
図9(b)は、TSパケットの形式を示している。第1段目は、TSパケット列を示し、第2段目は、ソースパケット列を示す。
第1段目に示すようにTSパケットは、ストリームを識別するPIDなどの情報を持つ4Byteの「TSヘッダ」とデータを格納する184Byteの「TSペイロード」に分かれる固定長のパケットであり、前述で説明したPESパケットは分割されTSペイロードに格納される。
第2段目によると、TSパケットには、4ByteのTP_Extra_Headerが付与されて、192Byteのソースパケットに変換された状態で、TSを構成する。TP_Extra_HeaderにはATS(Arrival_Time_Stamp)などの情報が記載される。ATSは当該TSパケットのPIDフィルタへの転送開始時刻を示す。TSには、第3段目に示すようにソースパケットが並ぶこととなり、TSの先頭からインクリメントする番号はSPN(ソースパケット番号)と呼ばれる。
<TSにおける多重化>
図10は、メインTSがどのように多重化されるかを模式的に示す図である。まず、ベースビュービデオストリーム、及び、オーディオストリームを(第1段目)、それぞれPESパケット列に変換し(第2段目)、ソースパケット列に変換する(第3段目)。同じくレフトビューPGストリームおよびレフトビューインタラクティブグラフィクス(第7段目)を、それぞれPESパケット列に変換し(第6段目)、更にソースパケット列に変換する(第5段目)。こうして得られた、ビデオ、オーディオ、グラフィクスを構成するソースパケットをそのATSの順に配列してゆく。これはソースパケットは、そのATSに従い、リードバッファに読み込まれるべきだからである。こうして、ATSに従ってソースパケットが配列されれば、メインTSが得られることになる。
・TSに多重化されるエレメンタリストリーム
これらのTSに多重化されるエレメンタリストリーム(ES)は、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームがある。
・ビデオストリーム
ベースビューとなるビデオストリームは、ピクチャインピクチャアプリケーションにおけるプライマリビデオストリームを構成する。ピクチャインピクチャアプリケーションは、このプライマリビデオストリームの他、セカンダリビデオストリームから構成される。プライマリビデオストリームとは、ピクチャインピクチャアプリケーションにおいて親画面となるピクチャデータから構成されるビデオストリームでる。対照的に、セカンダリビデオストリームとは、ピクチャインピクチャにおいて子画面として、親画面の一部にはめ込まれるピクチャデータから構成されるビデオストリームである。
プライマリビデオストリームを構成するピクチャデータと、セカンダリビデオストリームを構成するピクチャデータとはデコード後、別々のプレーンメモリに格納される。セカンダリビデオストリームを構成するピクチャデータを格納するプレーンメモリの前段には、セカンダリビデオストリームを構成するピクチャデータのスケーリング変更及び表示座標の位置決めを行う構成要素(Scalling&Positioning)が存在する。
・オーディオストリーム
オーディオストリームには、プライマリオーディオストリーム、セカンダリオーディオストリームの2種類がある。プライマリオーディオストリームは、ミキシング再生を行う場合、主音声となるべきオーディオストリームであり、セカンダリオーディオストリームは、ミキシング再生を行う場合、副音声をとなるべきオーディオストリームである。セカンダリオーディオストリームは、このミキシングのためのダウンサンプリングのための情報、ゲイン制御のための情報が存在する。オーディオストリームは、ドルビーAC−3、Dolby Digital Plus、MLP、DTS、DTS−HD、または、リニアPCMのなどの方式で圧縮・符号化記録されている。
・プレゼンテーショングラフィクスストリーム(PGストリーム)
PGストリームは、デコーダにパイプラインを採用することで、映像との緻密な同期を実現することができ、字幕表示に適したグラフィクスストリームであり、2DPGストリームと、立体視PGストリームという2つの種類がある。立体視PGストリームには、レフトビューPGストリーム及びライトビューPGストリームという二種類のものがある。レフトビューPGストリーム及びライトビューPGストリームのうち、ベースビューインディケータによって指定されているものがベースビューPGストリームになり、ベースビューインディケータによって指定されていないものがディペンデントビューPGストリームになる。
2DPGストリームの他に、立体視PGストリームを設けるのは、PGストリームが字幕文字を表す場合、2Dで表示される真正面から見た字幕文字と、3D-LRモードで左目用に表示されるグラフィクスと、右目用に表示される字幕文字とは異なるものにする必要からである。そのため、2D再生の場合は正面から見たグラフィクスストリームを1本、3D-LRモード用にはレフトビューPGストリーム、ライトビューPGストリームの計2本を表示する。同様に、3D-Depthモードの場合は、正面から見た映像と深度情報を示すグレースケールストリームを再生する。2D+offset(2D互換ストリーム)と、3D-LRストリームとは、混在させてはならない。
2DPGストリームは最大32本、ベースビューPGストリームの最大32本、ディペンデントビューPGストリームも最大32本定義することができる。これらの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ストリームは最大32本、ベースビューIGストリームは最大32本、ディペンデントビューIGストリームも最大32本定義することができる。これらの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+Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。B−Dプレゼンテーションモードで再生される場合におけるPGストリームの類型を、"立体視再生タイプ"という。1plane+Offsetモードで再生される場合におけるPGストリーム,PG_テキスト字幕ストリームの類型を、1plane+Offsetタイプという。1plane+Zero Offsetモードで再生される場合におけるPGストリーム,PG_テキスト字幕ストリームの類型を、1plane+Zero Offsetタイプという。
テキスト字幕ストリームの3D表示モードには、1plane+Offsetモード、1plane+Zero Offsetモードといった2つの再生モードが許容される。テキスト字幕ストリームにおいて、1plane+Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。
IGストリームの3D表示モードには、B−Dプレゼンテーションモード、1plane+Offsetモード、1plane+Zero Offsetモードといった3つの再生モードが許容される。IGストリームにおいて、1plane+Zero Offsetモードが許容されるのは、ポップアップメニューがオンになっている場合のみである。以降の説明では、特に断らない限り3D再生モード実行時には、ピクチャインピクチャは使用できないものとする。ピクチャインピクチャ及び3D再生モードは、何れも非圧縮のピクチャデータを格納するためのビデオプレーンを2つ必要とするからである。また特に断らない限り、3D再生モードでは、サウンドミキシングも使用できないものとする。
続いて、メインTS及びサブTSの内部構成について説明する。図11は、メインTS及びサブTSの内部構成を示す。
同図(a)は、メインTSの内部構成を示す。メインTSは、以下のソースパケットによって構成されている。
0x0100のパケットIDを有するソースパケットはProgram_Map_Tableを構成し、0x0101のパケットIDを有するTSパケットはPCRを構成する。
0x1011のパケットIDを有するソースパケット列は、プライマリビデオストリームを構成する。
0x1220のパケット識別子を有するソースパケット列から0x123FのパケットIDを有するソースパケット列までは、32本のベースビューPGストリームを構成する。
0x1420のパケット識別子を有するソースパケット列から0x143FのパケットIDを有するソースパケット列までは 32本のベースビューIGストリームを構成する。
0x1100のパケット識別子を有するソースパケット列から、0x111Fのパケット識別子を有するソースパケット列までは、プライマリオーディオストリームを構成する。
これらのソースパケットのパケット識別子を多重分離部に指示することにより、メインTSに多重化されている複数のESのうち、所望のものを分離してデコーダに供することができる。
図(b)は、サブTSの内部構成を示す。サブTSは、以下のソースパケットによって構成されている。
Ox1012のパケット識別子を有するソースパケット列は、ディペンデントビュービデオストリームを構成し、Ox1240のパケット識別子を有するソースパケット列から0x125Fのパケット識別子を有するソースパケット列までは、32本のディペンデントビューPGストリームを構成する。
Ox1440のパケット識別子を有するソースパケット列から0x145Fのパケット識別子を有するソースパケット列は、32本のディペンデントビューIGストリームを構成する。
<ビデオストリーム>
図12は、ビデオストリームのデータ構造を示す模式図である。
ビデオストリームは、複数のGOPから構成されており、これを符合化処理の基本単位とすることで動画像の編集やランダムアクセスが可能となっている。GOPは、1つ以上のビデオアクセスユニットにより構成されている。ビデオアクセスユニットは、符合化されたピクチャデータを格納する単位であり、フレーム構造の場合は1フレーム、フィールド構造の場合の1フィールドのデータが格納される。GOP先頭のビデオアクセスユニットはIピクチャのデータが格納され、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータが格納される。シーケンスヘッダは、当該GOPで共通の情報を格納したヘッダであり、解像度、フレームレート、アスペクト比、ビットレートなどの情報が格納される。ピクチャヘッダはピクチャ全体の符合化方式等、ピクチャの復号に必要な情報を格納したヘッダである。補足データは圧縮データの復号に必須ではない付加情報であり、例えば、映像と同期してTVに表示するクローズドキャプションの文字情報やタイムコード情報などがある。圧縮ピクチャデータは圧縮符合化されたピクチャデータである。GOP先頭以外のビデオアクセスユニットは、シーケンスヘッダを含まない点を除いて、GOP先頭のビデオアクセスユニットと同様にピクチャヘッダ、補足データ、圧縮ピクチャデータが格納される。また、シーケンスヘッダ、ピクチャヘッダ、補足データ、圧縮ピクチャデータの中身の構成は、ビデオの符合化方式によって異なる。例えば、MPEG−4 AVCの場合であれば、シーケンスヘッダはSPS(シーケンスパラメータセット)に、ピクチャヘッダはPPS(ピクチャパラメータセット)に、補足データはSEI(Supplemental Enhancement Information)に相当する。
ベースビュービデオストリーム、ディペンデントビュービデオストリームの何れも、ここで説明したGOP構造を持つ。ベースビュービデオストリームの先頭ピクチャは、IDRピクチャもしくはNon-IDR Iピクチャであり、ディペンデントビュービデオストリームの先頭ピクチャは、ディペンデントビュービデオストリームがライトビュービデオストリームであれば、ベースビュービデオストリームの対応するGOP先頭ピクチャと供に3D映像の同じフレーム又はフィールドを表すライトビューピクチャであって、ベースビュービデオストリームのGOP先頭ピクチャと同じPTSが付与されたライトビュービデオストリームのピクチャである。また、ディペンデントビュービデオストリームがデプスマップストリームであれば、ディペンデントビュービデオストリームの先頭ピクチャは、ベースビュービデオストリームの対応するGOP先頭ピクチャに対するデプスマップを格納したピクチャであり、ベースビュービデオストリームのGOP先頭ピクチャと同じPTSが付与されたデプスマップストリームのピクチャである。ベースビュービデオストリームとディペンデントビュービデオストリームとの間で、PTSが等しく、かつDTSが等しいピクチャを含むVAUの対を「3D・VAU」という。同じ3D・VAUに属するベースビュービデオストリームとディペンデントビュービデオストリームとの対応するGOPでは、シーケンスヘッダのフレームレート、解像度、アスペクト比に同じ値が設定される。
図13は、ビデオアクセスユニット内の補足データ領域に格納されるデコードスイッチ情報のデータ構造を示す図である。デコードスイッチ情報は、再生装置内のデコーダに、次に復号すべきビデオアクセスユニットを容易に特定させるための情報であり、ベースビュービデオストリームとディペンデントビュービデオストリームとの両方で各ビデオアクセスユニットに含まれる。ここで、そのデコーダは後述のように、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとをビデオアクセスユニット単位で交互に復号する。そのとき、そのデコーダは一般に、各ビデオアクセスユニットに付与されたDTSの示す時刻に合わせて、次に復号すべきVAUを特定する。しかし、デコーダの種類には、DTSを無視してビデオアクセスユニットを順次、復号し続けるものも多い。そのようなデコーダにとって、各ビデオアクセスユニットがDTSに加えてデコードスイッチ情報を含むことは好ましい。
図13の上段は、デコードスイッチ情報の構造を示しており、図13の下段は1つのビデオアクセスユニットのデータ構造を示している。デコードスイッチ情報は、ビデオアクセスユニット毎に、ビデオアクセスユニット内の補足データ領域(MPEG−4 AVCの場合はSEI)に格納される。
デコードスイッチ情報は、次アクセスユニットタイプと次アクセスユニットサイズ、及びデコードカウンタから構成されている。
次アクセスユニットタイプは、次にデコードするビデオアクセスユニットがベースビュービデオストリームとディペンデントビュービデオストリームとのどちらなのかを示す情報である。値が「1」の場合はベースビュービデオストリームのビデオアクセスユニットを示し、値が「2」の場合はディペンデントビュービデオストリームのビデオアクセスユニットを示し、「0」の場合は現在のビデオアクセスユニットがストリーム終端に位置し、次に復号されるべきビデオアクセスユニットが存在しないことを示す。
次アクセスユニットサイズは、次にデコードするビデオアクセスユニットのサイズ情報である。もし、次にデコードするビデオアクセスユニットのサイズが不明であるならば、デコード前のビデオアクセスユニットが格納されたバッファからビデオアクエスユニットを引き抜く際に、アクセスユニットの構造を解析してサイズを特定する必要が生じる。しかし、次アクセスユニットサイズがあることで、ビデオデコーダは次のビデオアクセスユニットの構造を解析することなくサイズを特定できる。そのため、デコーダは、デコード前のピクチャを含むビデオアクセスユニットを、バッファから容易に抽出できる。
デコードカウンタは、図14(a)に示すようにベースビュービデオストリームのGOP先頭のIピクチャを0としたときに、ベースビュービデオストリームとディペンデントビュービデオストリームとのビデオアクセスユニットをデコード順にインクリメントしたカウンタの値である。
この情報を使えば、何かの原因でビデオアクセスユニットが読めなかったときのエラー処理を適切に行うことができる。例えば、図14(a)のようにベースビュービデオストリームの3番目のビデオアクセスユニット(Brピクチャ)が、読み込みエラーで読めなかったとすると、何も情報がない場合、ディペンデントビュービデオストリームの3番目のビデオアクセスユニット(Bピクチャ)は、ベースビュービデオストリームの3番目のビデオアクセスユニットを参照するため、誤ったデコードを行いノイズののった画像をデコードしてしまう可能性がある。このときに、ディペンデントビュービデオストリームの2番目のビデオアクセスユニット(Pピクチャ)のデコードカウンタの値を保持しておけば、次に来るべきアクセスユニットのデコードカウンタの値を予測できるため、デコーダは適切なエラー処理を行うことができる。図14(a)の例では、ディペンデントビュービデオストリームの2番目のビデオアクセスユニット(Pピクチャ)のデコードカウンタ4は「4」であるため、次に来るべきデコードカウンタは「5」であるはずだが、実際には読み込めるビデオアクセスユニットはベースビュービデオストリームの4番目のビデオアクセスユニット(Pピクチャ)でデコードカウンタは「7」になっている。このため、ビデオデコーダでは、ビデオアクセスユニットをひとつスキップしたことが判断できる。これにより、例えば、ディペンデントビュービデオストリームの3番目のビデオアクセスユニット(Bピクチャ)は参照先のピクチャが無いと判断してデコードをスキップする、といった処理を行うことができる。
なお、図14(b)のようにデコードカウンタを映像ビデオストリーム毎に完結する値にしても良い。この場合も、直前にデコードしたのがベースビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタと同じであると予測できる。直前にデコードしたのがディペンデントビュービデオストリームのビデオアクセスユニットであった場合は、次に来るべきビデオアクセスユニットのデコードカウンタは、直前のデコードカウンタに1足したものと同じであると予測できるため、同様に適切なエラー処理を行うことができる。
<多重化ストリーム・データのインターリーブ配置>
3D映像のシームレス再生には、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの記録媒体100上での物理的な配置が重要である。ここで、「シームレス再生」とは、多重化ストリーム・データから映像と音声とを途切れさせることなく滑らかに再生することをいう。
図15は、メインTS、第1サブTS、及び第2サブTSのそれぞれに属するデータ・ブロック群の記録媒体100上での物理的な配置を示す模式図である。「データ・ブロック」とは、記録媒体100上の連続領域、すなわち物理的に連続する複数のセクタに記録された一連のデータをいう。記録媒体100では物理アドレスが論理アドレスと実質的に等しいので、各データ・ブロック内ではLBNも連続している。従って、再生装置200のBD−ROMドライブは一つのデータ・ブロックを、光ピックアップにシークを行わせることなく連続して読み出すことができる。以下、メインTSに属するデータ・ブロックL1、L2、L3、…を「ベースビュー・データ・ブロック」といい、サブTSに属するデータ・ブロックR1、R2、R3、…、D1、D2、D3、…を「ディペンデントビュー・データ・ブロック」という。特に、第1サブTSに属するデータ・ブロックR1、R2、R3、…を「ライトビュー・データ・ブロック」といい、第2サブTSに属するデータ・ブロックD1、D2、D3、…を「デプスマップ・データ・ブロック」という。図15を参照するに、データ・ブロック群は記録媒体100上のトラック1601に沿って連続的に記録されている。更に、ベースビュー・データ・ブロックL1、L2、L3、…、ライトビュー・データ・ブロックR1、R2、R3、…、及びデプスマップ・データ・ブロックD1、D2、D3、…が一つずつ交互に配置されている。このようなデータ・ブロック群の配置を「インターリーブ配置」という。
本発明の実施形態1によるインターリーブ配置では、隣接する三種類のデータ・ブロックの間でエクステントATC時間が等しい。例えば図15では、先頭のデプスマップ・データ・ブロックD1、先頭のライトビュー・データ・ブロックR1、及び、先頭のベースビュー・データ・ブロックL1が連続している。それらのデータ・ブロックD1、R1、L1間ではエクステントATC時間が等しい。ここで、「ATC(Arrival Time Clock)」は、ATSの基準とされるべきクロックを意味する。また、「エクステントATC時間」はATCの値で定義され、一つのエクステント内のソースパケットに付与されたATSの範囲、すなわち、そのエクステントの先頭のソースパケットのATSから次のエクステントの先頭のソースパケットのATSまでの時間間隔を表す。すなわち、エクステントATC時間は、そのエクステント内のソースパケットを全て、再生装置200内でリード・バッファからシステム・ターゲット・デコーダへ転送するのに要する時間に等しい。尚、「リードバッファ」は再生装置200内のバッファメモリであり、記録媒体100から読み出されたデータ・ブロックをシステム・ターゲット・デコーダに送るまでの間、一時的に格納する。
エクステントATC時間の等しい三種類のデータ・ブロック間では更に、再生期間が一致し、かつビデオ・ストリームの再生時間が等しくてもよい。例えば図15では、先頭の三つのデータ・ブロックD1、R1、L1間で、再生期間が一致し、かつビデオ・ストリームの再生時間が等しい。後続のデータ・ブロック群でも同様に、エクステントATC時間の等しい三種類のデータ・ブロックD2、R2、L2間では、再生期間が一致し、かつビデオ・ストリームの再生時間が等しくてもよい。
本発明の実施形態1によるインターリーブ配置では更に、エクステントATC時間の等しい三つの連続するデータ・ブロックは、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックの順に、すなわちデータ量の小さい順に配置されている。例えば図15では、先頭のライトビュー・データ・ブロックR1に含まれるピクチャは、先頭のベースビュー・データ・ブロックL1に含まれるピクチャを参照ピクチャとして圧縮されている。従って、先頭のライトビュー・データ・ブロックR1のサイズSext2[1]は先頭のベースビュー・データ・ブロックL1のサイズSext1[1]以下である:Sext2[1]≦Sext1[1]。一方、デプスマップの画素当たりのデータ量、すなわち奥行き値のビット数は一般に、ベースビュー・ビデオ・ストリームに含まれるピクチャの画素当たりのデータ量、すなわち色座標値とα値とのビット数の和よりも小さい。更に、メインTSは第2サブTSとは異なり、プライマリ・ビデオ・ストリームの他にもプライマリ・オーディオ・ストリーム等のエレメンタリ・ストリームを含む。従って、図15では先頭のデプスマップ・データ・ブロックD1のサイズSext3[1]は先頭のベースビュー・データ・ブロックL1のサイズSext1[1]以下である:Sext3[1]≦Sext1[1]。それ故、図15では、先頭のデプスマップ・データ・ブロックD1、先頭のライトビュー・データ・ブロックR1、及び先頭のベースビュー・データ・ブロックL1がその順で配置されている。次に連続する三つのエクステントD2、R2、L2の順序も同様である。
エクステントATC時間の等しいデータ・ブロックの各先頭に位置するVAUは同じ3D・VAUに属し、特に、同じ3D映像を表すGOPの先頭のピクチャを含む。例えば図15では、エクステントATC時間の等しい三つの連続するデータ・ブロックDn、Rn、Ln(n=1、2、3、…)のうち、デプスマップ・データ・ブロックDnの先端はデプスマップ・ストリームのIピクチャを含み、ライトビュー・データ・ブロックRnの先端はライトビュー・ビデオ・ストリームのPピクチャを含み、ベースビュー・データ・ブロックLnの先端はベースビュー・ビデオ・ストリームのIピクチャを含む。そのデプスマップ・ストリームのIピクチャは、そのベースビュー・ビデオ・ストリームのIピクチャの表す2D映像に対するデプスマップを表す。そのライトビュー・ビデオ・ストリームのPピクチャは、そのベースビュー・ビデオ・ストリームのIピクチャの表す2D映像をレフトビューとするときのライトビューを表す。特にそのPピクチャは、そのベースビュー・ビデオ・ストリームのIピクチャを参照ピクチャとして圧縮されている。従って、3D再生モードの再生装置200は、いずれのデータ・ブロックの組Dn、Rn、Lnからも3D映像の再生を開始できる。
<多重化ストリーム・データをデータ・ブロックに分割する意義>
再生装置200は、記録媒体100から3D映像をシームレスに再生するには、メインTSとサブTSとをパラレルに処理しなければならない。しかし、その処理に利用可能なリード・バッファの容量は一般に限られている。特に、記録媒体100からリード・バッファへ連続して読み込むことのできるデータ量には限界がある。従って、再生装置200はメインTSとサブTSとを、エクステントATC時間の等しい部分の対に分割して読み出さねばならない。
図16の(a)は、あるBD−ROMディスク上に個別に連続して記録されたメインTS1701とサブTS1702との配置を示す模式図である。再生装置200がそれらのメインTS1701とサブTS1702とをパラレルに処理するとき、図16の(a)に実線の矢印(1)−(4)で示されているように、BD−ROMドライブはメインTS1701とサブTS1702とを交互に、エクステントATC時間の等しい部分ずつ読み出す。そのとき、BD−ROMドライブ121は、図16の(a)に破線の矢印で示されているように、読み出し処理の途中でBD−ROMディスク上の読み出し対象領域を大きく変化させなければならない。例えば矢印(1)の示すメインTS1701の先端部分が読み出された時、BD−ROMドライブ121は光ピックアップによる読み出し動作を一旦停止し、BD−ROMディスクの回転速度を上げる。それにより、矢印(2)の示すサブTS1702の先端部分が記録されたBD−ROMディスク上のセクタを速やかに光ピックアップの位置まで移動させる。このように、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。図16の(a)に示されている破線の矢印は、読み出し処理の途中で必要な各ジャンプの範囲を示す。各ジャンプの期間中光ピックアップによる読み出し処理は停止し、デコーダによる復号処理のみが進行する。その結果、読み出し処理を復号処理に間に合わせることが難しいので、シームレス再生を確実に持続することが難しい。
図16の(b)は、本発明の実施形態1による記録媒体100上に交互に記録されたベースビュー・データ・ブロックB[0]、B[1]、B[2]、…とディペンデントビュー・データ・ブロックD[0]、D[1]、D[2]、…との配置を示す模式図である。図16の(b)を参照するに、メインTSとサブTSとはそれぞれ、複数のデータ・ブロックに分割されて交互に配置されている。その場合、再生装置200は3D映像の再生時、図16の(b)に矢印(1)−(4)で示されているように、データ・ブロックB[0]、D[0]、B[1]、D[1]、…を先頭から順番に読み出す。それだけで、再生装置200はメインTSとサブTSとを交互に読み出すことをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、3D映像のシームレス再生が確実に持続可能である。
<隣接するデータ・ブロック間でエクステントATC時間を揃える意義>
図15に示されているインターリーブ配置では、隣接する三種類のデータ・ブロックDn、Rn、Lnがいずれも同じエクステントATC時間を持つ。すなわち、それらのエクステント間では各エクステントの先頭のソースパケットから次のエクステントの先頭のソースパケットまでのATSの差が等しい(但し、その差の計算では、ATSにラップ・アラウンドが発生することが考慮されている)。その場合、再生装置200内のシステム・ターゲット・デコーダはリード・バッファから、ATCで計られる同じ時間内に、ベースビュー・データ・ブロックLnとディペンデントビュー・データ・ブロックDn又はRnとの両方に含まれる全てのTSパケットを取り出す。従って、特に飛び込み再生時において、システム・ターゲット・デコーダはベースビュー・ストリームとディペンデントビュー・ストリームとの間でTSパケットの復号処理を容易に同期させることができる。
<再生時間の等しいデータ・ブロックを隣接させる意義>
図17の(a)は、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でエクステントATC時間が異なり、かつビデオ・ストリームの再生時間が異なるときの再生経路を示す模式図である。図17の(a)に示されている例では、先頭のベースビュー・データ・ブロックB[0]の再生時間は4秒間であり、先頭のディペンデントビュー・データ・ブロックD[0]の再生時間は1秒間である。ここで、ディペンデントビュー・データ・ブロックD[0]の復号に必要なベースビュー・ビデオ・ストリームの部分は、そのディペンデントビュー・データ・ブロックD[0]と同じ再生時間を持つ。従って、再生装置200内のリード・バッファの容量を節約するには、図17の(a)に矢印1810で示されているように、再生装置200にベースビュー・データ・ブロックB[0]とディペンデントビュー・データ・ブロックD[0]とを交互に同じ再生時間ずつ、例えば1秒間ずつ読み込ませることが好ましい。しかし、その場合、図17の(a)に破線で示されているように、読み出し処理の途中でジャンプが生じる。その結果、読み出し処理を復号処理に間に合わせることが難しいので、シームレス再生を確実に持続することが難しい。
図17の(b)は、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でビデオ・ストリームの再生時間が等しいときの再生経路を示す模式図である。本発明の実施形態1による記録媒体100上では、図17の(b)に示されているように、隣接する一対のデータ・ブロックの間でビデオ・ストリームの再生時間が等しい。例えば、先頭のベースビュー・データ・ブロックB[0]とディペンデントビュー・データ・ブロックD[0]との対ではビデオ・ストリームの再生時間が共に1秒に等しく、二番目のデータ・ブロックの対B[1]、D[1]ではビデオ・ストリームの再生時間が共に0.7秒に等しい。その場合、再生装置200は3D映像の再生時、図17の(b)に矢印1820で示されているように、データ・ブロックB[0]、D[0]、B[1]、D[1]、…を先頭から順番に読み出す。それだけで、再生装置200はメインTSとサブTSとを交互に同じ再生時間ずつ読み出すことをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、3D映像のシームレス再生が確実に持続可能である。
尚、隣接するベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの間でエクステントATC時間が等しければ、それらのデータ・ブロック間で再生期間が一致していなくても、更にビデオ・ストリームの再生時間が等しくなくてもよい。その場合でも、図17の(b)に示されているものと同様に、再生装置200はデータ・ブロック群を先頭から順番に読み出すだけで、メインTSとサブTSとの交互の読み出しをスムーズに実現できる。特にその読み出し処理ではジャンプが生じないので、3D映像のシームレス再生が確実に持続可能である。
また、図17(c)のように、ベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとのすべてエクステントのエクステントATC時間を同じにするとしても良い。このように構成することで、多重化ストリームのエクステントサイズの決定方法が図17(b)に示すものに比べて容易になるためデータ作成が容易になる。また、その固定するエクステントATC時間を、後述する最小エクステントサイズのエクステントATC時間とすれば、2D/3D再生装置に必要なリードバッファのサイズを小さくすることもできる。
<データ・ブロックに対するAVストリーム・ファイルのクロスリンク>
多重化ストリーム・データに属する各データ・ブロックは、記録媒体100のファイルシステムでは、ファイル2D又はファイルDEP内の一つのエクステントとしてアクセス可能である。すなわち、各データ・ブロックの論理アドレスは、ファイル2D又はファイルDEPのファイル・エントリに記録されたアロケーション記述子から知ることができる。図15に示されている例では、ファイル2D(01000.m2ts)のファイル・エントリ1610に含まれるアロケーション記述子#1、#2、#3、…は、ベースビュー・データ・ブロックL1、L2、L3、…の各サイズとその先端のLBNとを示す。第1ファイルDEP(02000.m2ts)のファイル・エントリ1620に含まれるアロケーション記述子#1、#2、#3、…は、ライトビュー・データ・ブロックR1、R2、R3、…の各サイズとその先端のLBNとを示す。第2ファイルDEP(03000.m2ts)のファイル・エントリ1630に含まれるアロケーション記述子#1、#2、#3、…は、デプスマップ・データ・ブロックD1、D2、D3、…の各サイズとその先端のLBNとを示す。
図18の(a)は、ファイル2D(01000.m2ts)のデータ構造を示す模式図である。図15に示されているように、ファイル・エントリ1610内のアロケーション記述子#1、#2、#3、…はベースビュー・データ・ブロックL1、L2、L3、…を参照する。従って、各ベースビュー・データ・ブロックL1、L2、L3、…は、図18の(a)に示されているように、ファイル2DのエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…としてアクセス可能である。以下、ファイル2Dに属するエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…を「2Dエクステント」という。
図18の(b)は、第1ファイルDEP(02000.m2ts)のデータ構造を示す模式図である。図15に示されているように、ファイル・エントリ1620内のアロケーション記述子#1、#2、#3、…はライトビュー・データ・ブロックR1、R2、R3、…を参照する。従って、各ライトビュー・データ・ブロックR1、R2、R3、…は、図18の(b)に示されているように、第1ファイルDEPのエクステントEXT2[0]、EXT2[1]、EXT2[2]、…としてアクセス可能である。以下、ライトビューストリームファイルであるファイルDEPに属するエクステントEXT2[0]、EXT2[1]、EXT2[2]、…を「ライトビュー・エクステント」という。
図18の(c)は、第2ファイルDEP(03000.m2ts)のデータ構造を示す模式図である。図15に示されているように、ファイル・エントリ1630内のアロケーション記述子#1、#2、#3、…はデプスマップ・データ・ブロックD1、D2、D3、…を参照する。従って、各デプスマップ・データ・ブロックD1、D2、D3、…は、図18の(c)に示されているように、第2ファイルDEPのエクステントEXT3[0]、EXT3[1]、EXT3[2]、…としてアクセス可能である。以下、デプスマップストリームファイルであるファイルDEPに属するエクステントEXT3[0]、EXT3[1]、EXT3[2]、…を「デプスマップ・エクステント」という。更に、ライトビュー・エクステントとデプスマップ・エクステントとのように、いずれかのファイルDEPに属するエクステントを「ディペンデントビュー・エクステント」と総称する。
図15に示されているデータ・ブロック群に対して、AVストリーム・ファイルのクロスリンクは次のように実現される。第1ファイルSS(01000.ssif)のファイル・エントリ1640に含まれるアロケーション記述子#1、#2、#3、…は、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3、…をそれぞれ一つのエクステントと見なして各サイズとその先端のLBNとを示す。第2ファイルSS(02000.ssif)のファイル・エントリ1650に含まれるアロケーション記述子#1、#2、#3、…は、デプスマップ・データ・ブロックD1、D2、D3、…とベースビュー・データ・ブロックL1、L2、L3、…との各サイズとその先端のLBNとを交互に示す。
図18の(d)は、第1ファイルSS(01000.ssif)のデータ構造を示す模式図である。図15に示されているように、ファイル・エントリ1640内のアロケーション記述子#1、#2、#3、…は、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3、…を参照する。従って、隣接するデータ・ブロックの各対R1+L1、R2+L2、R3+L3、…は、図18の(d)に示されているように、第1ファイルSSのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、…としてアクセス可能である。以下、ファイルSSに属するエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、…を「3Dエクステント」という。各3DエクステントEXTSS[n](n=0、1、2、…)は、ファイル2Dとはベースビュー・データ・ブロックLnを共有し、第1ファイルDEPとはライトビュー・データ・ブロックRnを共有する。
図18の(e)は、第2ファイルSS(02000.ssif)のデータ構造を示す模式図である。図15に示されているように、ファイル・エントリ1650内のアロケーション記述子#1、#2、#3、…は、デプスマップ・データ・ブロックD1、D2、D3、…とベースビュー・データ・ブロックL1、L2、L3、…とを交互に参照する。従って、各データ・ブロックD1、L1、D2、L2、は、図18の(e)に示されているように、第2ファイルSSのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]、…としてアクセス可能である。第2ファイルSSの各エクステントは、ファイル2Dとはベースビュー・データ・ブロックLnを共有し、第2ファイルDEPとはデプスマップ・データ・ブロックDnを共有する。
<インターリーブ配置のデータ・ブロック群に対する再生経路>
図19は、図15に示されているデータ・ブロック群に対する2D再生モードでの再生経路1901、L/Rモードでの再生経路1902、及びデプス・モードでの再生経路1903を示す模式図である。
再生装置200は2D再生モードではファイル2Dを再生する。従って、2D再生モードでの再生経路1901が示すとおり、ベースビュー・データ・ブロックL1、L2、L3が順番に2DエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]として読み出される。すなわち、まず先頭のベースビュー・データ・ブロックL1が読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、二番目のベースビュー・データ・ブロックL2が読み出され、その直後のデプスマップ・データ・ブロックD3とライトビュー・データ・ブロックR3との読み出しが二回目のジャンプJ2D2によってスキップされる。続いて、三番目のベースビュー・データ・ブロックL3が読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路1902が示すとおり、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3が順番に3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]として読み出される。すなわち、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1とが連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが連続して読み出され、その直後のデプスマップ・データ・ブロックD3の読み出しが二回目のジャンプJLR2によってスキップされる。続いて、三番目のライトビュー・データ・ブロックR3とその直後のベースビュー・データ・ブロックL3とが連続して読み出される。
再生装置200はデプス・モードでは第2ファイルSSを再生する。従って、デプス・モードでの再生経路1903が示すとおり、デプスマップ・データ・ブロックD1、D2、D3とベースビュー・データ・ブロックL1、L2とが交互に、第2ファイルSSのエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]として読み出される。すなわち、まず先頭のデプスマップ・データ・ブロックD1が読み出され、その直後のライトビュー・データ・ブロックR1の読み出しが最初のジャンプJLD1によってスキップされる。次に、先頭のベースビュー・データ・ブロックL1が読み出され、続けてその直後のデプスマップ・エクステントD2が読み出される。更に、その直後のライトビュー・エクステントR2の読み出しが二回目のジャンプJLD2によってスキップされ、二番目のベースビュー・データ・ブロックL2が読み出される。
図19の各再生経路1901−1903が示すとおり、データ・ブロック群がインターリーブ配置で記録された領域では、再生装置200はそのデータ・ブロック群を実質上、先頭から順に読み出せばよい。ここで、その読み出し処理の途中ではジャンプが生じる。しかし、各ジャンプの距離は、図16の(a)に示されているものとは異なり、メインTSとサブTSとのいずれの全長よりも十分に短い。また、いずれのジャンプも、図17の(a)に示されているものとは異なり、一つのデータ・ブロックの読み出しの途中では生じていない。更に、エクステントATC時間の等しいベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとの各対では、サイズの比較的小さいディペンデントビュー・データ・ブロックが先に読み出される。従って、その逆の場合よりも、再生装置200はリード・バッファの容量を削減できる。
再生装置200はL/Rモードではデータ・ブロック群を第1ファイルSSのエクステント群として読み込む。すなわち、再生装置200は第1ファイルSSのファイル・エントリ1640内のアロケーション記述子#1、#2、…から各3DエクステントEXTSS[0]、EXTSS[1]、…の先端のLBNとそのサイズとを読み出してBD−ROMドライブ121に渡す。BD−ROMドライブ121はそのLBNからそのサイズのデータを連続して読み出す。これらの処理は、データ・ブロック群を第1ファイルDEPとファイル2Dとの各エクステントとして読み込む処理よりも、BD−ROMドライブ121の制御が次の二点(A)、(B)で簡単である:(A)再生装置200は一箇所のファイル・エントリを利用して、エクステントを順番に参照すればよい;(B)読み込み対象のエクステントの総数が実質上半減するので、BD−ROMドライブに渡されるべきLBNとサイズとの対の総数が少ない。利点(A)はデプス・モードでデータ・ブロック群を第2ファイルSSのエクステントとして読み込む処理にも当てはまる。但し、再生装置200は3DエクステントEXTSS[0]、EXTSS[1]、…を読み込んだ後、それぞれをライトビュー・データ・ブロックとベースビュー・データ・ブロックとに分離してデコーダに渡さなければならない。その分離処理にはクリップ情報ファイルが利用される。その詳細については後述する。
<ロングジャンプ>
一般論だが、記録媒体に光ディスクを採用する場合、光ピックアップに読み出し動作を一旦停止させて、その間に次の読み出し対象領域上へ光ピックアップを位置づけるための操作を「ジャンプ」という。
ジャンプには、光ディスクの回転速度を上下させる操作の他に、トラックジャンプ及びフォーカスジャンプがある。トラックジャンプは、光ピックアップをディスクの半径方向に移動させる操作をいう。フォーカスジャンプは、光ディスクが多層ディスクであるとき、光ピックアップの焦点を一つの記録層から別の記録層へ移動させる操作をいう。これらのジャンプは一般にシーク時間が長く、かつ、ジャンプによって読み出しがスキップされるセクタ数が大きいので、特に「ロングジャンプ」という。ジャンプ期間中、光ピックアップによる読み出し操作は停止する。
ジャンプ期間中、読み出し操作がスキップされる記録媒体100上の領域の長さを「ジャンプ距離」という。ジャンプ距離は通常、その部分のセクタ数で表される。上記のロングジャンプは具体的には、ジャンプ距離が所定の閾値を超えるジャンプとして定義される。その閾値は、例えばBD-ROMの規格では、ディスクの種類及びドライブの読み出し処理に関する性能により、40000セクタに規定されている。
ロングジャンプを生じさせる場所の代表的なものとしては、メインTSとサブTSとが記録層の境界を越えて記録されている場合や、メインTSとサブTSとが別のデータを間に挟んで記録されている場合の他、プレイアイテム間の1対nの多重接続が存在する場所がある。
<ロングジャンプの前後での多重化ストリーム・データの配置>
記録媒体100では、一連のメインTSとサブTSとが、ロングジャンプの必要な位置の前後に分離されているととき、それらのデータ・ブロック群が、以下に述べる5種類の配置1−5のいずれかで記録されている。更に、それらのデータ・ブロック群へのアクセスにはAVストリーム・ファイルのクロスリンクが利用される。それにより、再生装置200は後述のとおり、リード・バッファの容量を必要最小限に維持したまま、ロングジャンプ中での映像のシームレス再生を容易に実現できる。
以下に、ロングジャンプの必要な位置として記録層の境界を例にして、データ・ブロック群がロングジャンプの必要な位置の前後に分離して配置する場合のデータ配置方法について、そのデータ構造を説明する。
[配置1]
図20は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第1例を示す模式図である。本図に示すデータ配置は、ロングジャンプの必要な位置の前後に分離されているメインTSとサブTSとのプレイアイテム同士が、シームレス接続する場合に利点のあるデータ配置方法である。本図においてデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含むサブTS、及びデプスマップストリームを含むサブTSに属する。図20に示すように、層境界LBの前に位置する第1記録層には、デプスマップ・データ・ブロック群…、D0、D1、ライトビュー・データ・ブロック群…、R0、R1、及びベースビュー・データ・ブロック群…、L0、L1がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第1の3Dエクステント・ブロック」2001という。また、第1の3Dエクステント・ブロック2001の後端L1に連続してベースビュー・データ・ブロックL22D、L32Dが配置されている。更に、ベースビュー・データ・ブロックL32Dと層境界LBとの間には、デプスマップ・データ・ブロック群D2、D3、ライトビュー・データ・ブロック群R2、R3、及びベースビュー・データ・ブロック群…、L2SS、L3SSがインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第2の3Dエクステント・ブロック」2002という。
一方、層境界LBの後に位置する第2記録層には、デプスマップ・データ・ブロック群D4、…、ライトビュー・データ・ブロック群R4、…、及びベースビュー・データ・ブロック群L4、…がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第3の3Dエクステント・ブロック」2003という。
各3Dエクステント・ブロック2001、2002、2003のインターリーブ配置は、図15に示されているものと同様である。すなわち、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックがその順で交互に並ぶ。更に、三つの連続するデータ・ブロックDn、Rn、Ln(n=…、1、2、3、4、…)間ではエクステントATC時間が等しい。第1の3Dエクステント・ブロック2001の後端に位置する三つのデータ・ブロックD1、R1、L1と、第2の3Dエクステント・ブロック2002の先端に位置する三つのデータ・ブロックD2、R2、L2SSとの間では、各ストリーム・データの内容が連続している。
第1の3Dエクステント・ブロック2001と第2の3Dエクステント・ブロック2002との間に位置するベースビュー・データ・ブロックL22Dは、第2の3Dエクステント・ブロック2002のベースビュー・データ・ブロックL2SSとビット単位(bit−for−bit)で一致する。同様にベースビュー・データ・ブロックL32Dは、第2の3Dエクステント・ブロック2002のベースビュー・データ・ブロックL3SSとビット単位で一致する。すなわち、データ・ブロック群L22D、L32Dとデータ・ブロック群L2SS、L3SSとの一方は他方の複製データである。以下、前者L22D、L32Dを「2D再生専用ブロック」といい、後者L2SS、L3SSを「3D再生専用ブロック」という。
図20に示されている各データ・ブロックは、3D再生専用ブロックL2SS、L3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば第1ファイル2D(01000.m2ts)のファイル・エントリ2010では、アロケーション記述子#1が、第1の3Dエクステント・ブロック2001内の最後から二番目のベースビュー・データ・ブロックL0のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL0は第1ファイル2Dの一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は、第1の3Dエクステント・ブロック2001内の最後のベースビュー・データ・ブロックL1とその直後に連続する2D再生専用ブロック群L22D、L32Dとからなるベースビュー・データ・ブロックの一群L1+ L22D+L32Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックの一群L1+ L22D+L32Dは、第1ファイル2Dの単一の2DエクステントEXT2D[1]としてアクセス可能である。これらのファイル2Dにおけるベースビュー・データ・ブロックL1、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステント(ビッグエクステント)を構成している。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。ファイル2Dの再生において層境界LBをまたぐロングジャンプの直前にアクセスされるエクステントである2DエクステントEXT2D[1]を、以下では「ジャンプ直前2Dエクステント」とよぶ。
第2ファイル2D(01001.m2ts)のファイル・エントリ2011では、アロケーション記述子#1が、第3の3Dエクステント・ブロック2003内のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は第2ファイル2Dの一つの2DエクステントEXT2D[2]としてアクセス可能である。
図20に示されているデータ・ブロック群に対しても、AVストリーム・ファイルのクロスリンクは図15のものと同様に実現される。特に、第1ファイルSS(01000.ssif)のファイル・エントリ2020では、アロケーション記述子#1、#2、#3、#4が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R0+L0、R1+L1、R2+L2SS、R3+L3SSをそれぞれ一つのエクステントと見なして、各サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの各対R0+L0、R1+L1、R2+L2SS、R3+L3SSは第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。このうちEXTSS[2]、EXTSS[3]は、ファイルSSの再生において、層境界LBをまたぐロングジャンプの直前にアクセスされる第2の3Dエクステント・ブロック2002を構成するエクステント群であり、以下では「ジャンプ直前3Dエクステント群」とよぶ。また、第2ファイルSS(01001.ssif)のファイル・エントリ2021では、アロケーション記述子#1が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4+L4を一つのエクステントと見なして、サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの対R4+L4は第2ファイルSSの3DエクステントEXTSS[4]としてアクセス可能である。
ここで、2D再生専用ブロックL32Dと層境界LBとの間に位置する3DエクステントEXTSS[2]、EXTSS[3] を除き、3DエクステントEXTSS[0]、EXTSS[1]、及びEXTSS[4]はそれぞれ、ベースビュー・データ・ブロック…、L0、L1、L4をファイル2Dと共有する。一方、2D再生専用ブロックL22D、L32Dは、ファイル2Dにおける層境界LB直前の2DエクステントEXT2D[1]の一部としてのみアクセス可能な、ファイル2D固有のベースビューデータブロックである。更に、3D再生専用ブロックL2SS、L3SSは、ファイルSSにおける層境界LB直前の3DエクステントEXTSS[2]の一部としてのみアクセス可能な、ファイルSS固有のベースビューデータブロックである。
図20において、2Dプレイリスト及び3Dプレイリストは、何れもシームレスに接続する2つのプレイアイテム#1、#2を含む。ここでは、シームレスに接続するプレイアイテムの接続元プレイアイテムを「前方プレイアイテム」、接続先プレイアイテムを「後方プレイアイテム」と呼ぶことにする。まず、2Dプレイリストと3Dプレイリストとの各前方プレイアイテムが参照するデータを説明する。2Dプレイリストの前方プレイアイテムは、第1ファイル2Dを参照する。3Dプレイリストの前方プレイアイテムは第1ファイルSSを参照し、3Dプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。上述のように、第1ファイル2Dの2DエクステントEXT2D[0]、EXT2D[1]と、第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]とで参照するベースビューデータブロックの中身は同じである。これにより、2Dプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL1、L22D、L32Dを再生することになり、3Dプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1、L2SS、L3SSを再生することになる。従って、2Dプレイリストに基づく2D再生と3Dプレイリストに基づく3D再生とでは、再生経路(再生する論理アドレス)は異なるが同じレフトビュー・ビデオ・フレームを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。2Dプレイリストの後方プレイアイテムは、第2ファイル2Dを参照する。3Dプレイリストの後方プレイアイテムは第2ファイルSSを参照し、3Dプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。第2ファイル2Dと第2ファイルSSとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、2Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前2DエクステントEXT2D[1]の終端から、後方プレイアイテムにより参照される2DエクステントEXT2D[2]先頭までの距離は、2D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、3Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前3Dエクステントブロック2002と後方プレイアイテムにより参照される3Dエクステントブロック2003間のジャンプ距離は、2D/3D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
図21は、図20に示されているデータ・ブロック群に対する2D再生モードでの再生経路、L/Rモードでの再生経路、及びデプス・モードでの再生経路を示す模式図である。
再生装置200は2D再生モードではファイル2Dを再生する。従って、ベースビュー・データ・ブロックL0が最初の2DエクステントEXT2D[0] として読み出され、ベースビュー・データ・ブロックL1とその直後の2D再生専用ブロックL22D、L32Dとが連続して二番目の2DエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路が示すとおり、ライトビュー・データ・ブロックR0とその直後のベースビュー・データ・ブロックL0との対R0+L0が最初の3DエクステントEXTSS[0]として読み出され、ライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1とが二番目の3DエクステントEXTSS[1]として読み出され、ライトビュー・データ・ブロックR2とその直後の3D再生専用ブロックL2SSとが三番目の3DエクステントEXTSS[2]として読み出され、ライトビュー・データ・ブロックR3とその直後の3D再生専用ブロックL3SSとが四番目の3DエクステントEXTSS[3]として読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後のベースビューデータブロックL4とが五番目の3DエクステントEXTSS[4]として読み出される。
図21に示されているとおり、2D再生モードでは、2D再生専用ブロックL22D、L32Dは読み出されるが、3D再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆に、L/Rモードでは、2D再生専用ブロックL22D、L32Dの読み出しはスキップされるが、3D再生専用ブロックL2SS、L3SSは読み出される。しかし、データ・ブロックL22D、L2SSはビット単位で一致しており、データ・ブロックL32D、L3SSもビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置1ではロングジャンプJLYの前で2D再生モードでの再生経路とL/Rモードでの再生経路とが分離されている。デプス・モードについても同様である。
[配置1の利点]
図22は、あるBD−ROMディスクの層境界の前後にインターリーブ配置で記録されているデータ・ブロック群と、それに対する各再生モードでの再生経路とを示す模式図である。図22を参照するに、図20に示されている配置1と同様、第1記録層には、デプスマップ・データ・ブロック群…、D1、D2、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されて第1の3Dエクステント・ブロック2301を構成している。一方、第2記録層には、デプスマップ・データ・ブロック群D3、…、ライトビュー・データ・ブロック群R3、…、及びベースビュー・データ・ブロック群L3、…がインターリーブ配置で記録されて第2の3Dエクステント・ブロック2302を構成している。各3Dエクステント・ブロック2301、2302のインターリーブ配置は、図20に示されているもの2001、2002と同様である。更に、第1の3Dエクステント・ブロック2301の後端に位置する三つのデータ・ブロックD2、R2、L2と、第2の3Dエクステント・ブロック2302の先端に位置する三つのデータ・ブロックD3、R3、L3との間では、各ストリーム・データの内容が連続している。
図22に示されているデータ・ブロック群は、図20に示されているものとは異なり、層境界LBの直前に2D再生専用ブロックLn2Dと3D再生専用ブロックLnSSとを含んでいない。従って、以下に示すように、2D再生モードでの再生経路2310とL/Rモードでの再生経路2311とがロングジャンプJLYの直前に分離されることなく、いずれも同じベースビュー・データ・ブロックL2を通る。
図22に示されているベースビュー・データ・ブロックL1−L3はいずれもファイル2Dの一つのエクステントEXT2D[0]−EXT2D[2]としてアクセス可能である。一方、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの各対R1+L1、R2+L2、R3+L3はファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]としてアクセス可能である。いずれの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]もそれぞれベースビュー・データ・ブロックL1、L2、L3をファイル2Dと共有する。
2D再生モードの再生装置200はファイル2Dを再生する。従って、2D再生モードでの再生経路2310が示すとおり、まず第1の3Dエクステント・ブロック2301内の最後から二番目のベースビュー・データ・ブロックL1が最初の2DエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第1の3Dエクステント・ブロック2301内の最後のベースビュー・データ・ブロックL2が二番目の2DエクステントEXT2D[1]として読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2302の先端に位置する2個のデータ・ブロックD3、R3の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2302内の先頭のベースビュー・データ・ブロックL3が三番目の2DエクステントEXT2D[2]として読み出される。
L/Rモードの再生装置200はファイルSSを再生する。従って、L/Rモードでの再生経路2311が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1+L1が最初の3DエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の3DエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2302内の先頭のデプスマップ・データ・ブロックD3の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2302内の先頭のライトビュー・データ・ブロックR3とその直後のベースビュー・データ・ブロックL3とが三番目の3DエクステントEXTSS[2]として連続して読み出される。
上記のとおり、図22に示されているデータ・ブロック群では、図20に示されているものとは異なり、2D再生モードでの再生経路2310とL/Rモードでの再生経路2311とがいずれも、ロングジャンプJLYの直前に同じベースビュー・データ・ブロックL2を通る。ここで、ロングジャンプJLYの期間中、BD−ROMドライブ121は読み出し処理を停止するが、システム・ターゲット・デコーダは、リード・バッファに蓄積されたストリーム・データの復号処理を続行する。従って、再生装置200にロングジャンプJLYの前後で映像をシームレスに再生させるには、ロングジャンプJLYの期間中でのバッファ・アンダーフローを防止しなければならない。
L/Rモードでは、第1の3Dエクステント・ブロック2301が復号される間に、リード・バッファに一定量のデータが蓄積される。この一定量のデータを「バッファ余裕量」という(その詳細は後述する)。ロングジャンプJLYの期間中では、その直前に読み込まれた3DエクステントEXTSS[1]、すなわちライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2とに加えてそのバッファ余裕量のデータが復号される。従って、L/Rモードでバッファ・アンダーフローを防止するにはバッファ余裕量が十分に大きければよい。一方、各データ・ブロックR2、L2のサイズは、ロングジャンプJLYの直前までバッファ余裕量が維持できる値Smin2、Smin1であればよい。
しかし、2D再生モードでバッファ・アンダーフローを防止するには、2DエクステントEXT2D[1]、すなわちベースビュー・データ・ブロックL2のサイズSext2D[1]が次の条件を満たさねばならない:2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間に、リード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上である。その条件を満たすサイズSext2D[1]は、図22に示されているように、L/Rモードでのシームレス再生に必要最小限のサイズSmin1よりも一般に大きい。従って、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量はL/Rモードでのシームレス再生に必要最小限の値よりも大きくなければならない。更に、ライトビュー・データ・ブロックR2はベースビュー・データ・ブロックL2とエクステントATC時間が等しくなければならない。従って、ライトビュー・データ・ブロックR2のサイズSext2[1]はL/Rモードでのシームレス再生に必要最小限の値Smin2よりも一般に大きい。それ故、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量はL/Rモードでのシームレス再生に必要最小限の値よりも更に大きくなければならない。以上の結果、図22に示されている配置では、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量の更なる削減が困難である。
それに対し、図21に示されている配置1では上記のとおり、ロングジャンプJLYの前で2D再生モードでの再生経路とL/Rモードでの再生経路とが分離されている。従って、図22に示されている配置とは異なり、層境界LBの前に位置するジャンプ直前2DエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR1のサイズSext2[1]とが、以下のように別々に決定可能である。
まず、ジャンプ直前2DエクステントEXT2D[1]のサイズSext2D[1]は、ベースビュー・データ・ブロックL1のサイズSext1[1]と2D再生専用ブロックL2 2DのサイズS2D[2]、2D再生専用ブロックL3 2DのサイズS2D[3]の和Sext1[1]+S2D[2]+S2D[3]に等しい。従って、2D再生モードでのシームレス再生の実現には、その和Sext1[1]+S2D[2]+S2D[3]が、ジャンプ直前2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。ここで、ジャンプ直前2DエクステントEXT2D[1]のうち、3DエクステントEXTSS[1]と共有されるのは、エクステント先頭に位置するベースビュー・データ・ブロックL1だけである。従って、2D再生専用ブロックL2 2DのサイズS2D[2]と2D再生専用ブロックL3 2DのサイズS2D[3]とを適切に拡大することにより、ジャンプ直前2DエクステントEXT2D[1]のサイズSext2D[1]=Sext1[1]+S2D[2]+S2D[3]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext1[1]を更に小さく制限することができる。それに伴い、ベースビュー・データ・ブロックL1とエクステントATC時間を等しくするライトビュー・データ・ブロックR1のサイズSext2[1]も更に小さく制限することができる。
一方、層境界LBの直前に位置するジャンプ直前3Dエクステントブロック2002に属するライトビュー・データ・ブロックR2、R3とベースビュー・データ・ブロックL2SS、L3SSとの各サイズSext2[2]、Sext2[3]、Sext1[2]、Sext1[3]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、3D再生専用ブロックL2SSは2D再生専用ブロックL22Dの複製データであり、3D再生専用ブロックL3SSは2D再生専用ブロックL32Dの複製データであるので、2D再生専用ブロックL32DのサイズS2Dの拡大は、3D再生専用ブロックL3SSの直前に位置するライトビュー・データ・ブロックR3のサイズを拡大させる。しかし、そのサイズは、図22に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量を、L/Rモードでのシームレス再生に必要最小限の値に更に接近させることができる。
このように、配置1では、再生装置200内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが可能である。
以上、配置1ではロングジャンプが発生する地点において、2D再生モードでの再生経路と、L/Rモードでの再生経路とを分離できるため、ジャンプ直前3Dエクステントブロックの終端EXT1[3]のサイズは、2D再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
また、図20の説明では、ロングジャンプの必要な位置として層境界を例としたが、ロングジャンプは、1対nのプレイアイテムの多重接続を行う場合にも生じ得る。1対nのプレイアイテムの多重接続を行う場合、n個のプレイアイテムを構成するn個のTSのうち1つ目のものは、その直前のプレイアイテムを構成するTSの直後に配置することができる。しかし2つ目以降のものは、その直前のプレイアイテムを構成するTSの直後に配置することができない。1対nの多重接続が存在する場合において、直前のプレイアイテムから、n個のプレイアイテムの2個目以降のプレイアイテムへとジャンプする場合、そのジャンプは、1つ以上のTSの記録領域を読み飛ばす必要があるので、1対nのプレイアイテムの多重接続が存在する場所では、ロングジャンプが生じることになる。このような1対nのプレイアイテム多重接続に伴うロングジャンプにも、配置1を適用することができる。具体的には、図23に示すように、2Dプレイリスト及び3Dプレイリストの何れに関しても、前方プレイアイテムであるプレイアイテム#1により参照されるデータをひとまとまりで全て配置し、その後にn個の後方プレイアイテムが参照するデータを配置する。このとき図20に示す配置と同様に、前方プレイアイテムについて2Dプレイリストと3Dプレイリストとで再生経路を分離してデータを配置しており、ジャンプ直前3Dエクステントブロックの終端EXT1[3]のサイズは、2D再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
以上、配置1を用いることで、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能となる。
[配置2]
図24は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第2例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含むサブTS、及びデプスマップストリームを含むサブTSに属する。以下、この配置を「配置2」という。図24を図20と比較するに、配置1とは、第1の3Dエクステントブロック2001に連続して第2の3Dエクステントブロック2002が配置されている点、及び3Dエクステントブロック2002の後端L3SSに連続して2D再生専用ブロック群L12D、L22D、L32Dが配置され連続して一つの2DエクステントEXT2D[1]としてアクセス可能である点で異なる。その他の特徴については配置2は配置1と同様であるので、その詳細についての説明は配置1についての説明を援用する。
層境界LBの直前に位置する2D再生専用ブロック群L12D、L22D、L32Dは第2の3Dエクステント・ブロック2002内の3D再生専用ブロック群L1SS、L2SS、L3SSとビット単位で一致する。すなわち、2D再生専用ブロック群L12D、L22D、L32Dと3D再生専用ブロック群L1SS、L2SS、L3SSとの一方は他方の複製データである。
図24に示されている各データ・ブロックは、3D再生専用ブロックL1SS、L2SS、L3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば、第1ファイル2Dのファイル・エントリ2010では、アロケーション記述子#1は、第1の3Dエクステント・ブロック2001内の最後のベースビュー・データ・ブロックL0のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL1は一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は2D再生専用ブロックL12D、L22D、L32Dからなるベースビュー・データ・ブロックの一群L12D+ L22D+L32Dを単一のエクステントと見なしてその合計サイズとその先端のLBNとを示す。従って、2D再生専用ブロック群L12D、L22D、L32Dは次の2DエクステントEXT2D[1]としてアクセス可能である。このファイル2Dにおけるベースビュー・データ・ブロックL12D、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステントを構成している。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。また、第2ファイル2Dのファイル・エントリ2011では、アロケーション記述子#1が、第3の3Dエクステント・ブロック2003内の最初のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は第2ファイル2Dの一つの2DエクステントEXT2D[2]としてアクセス可能である。
第1ファイルSSのファイル・エントリ2020では、アロケーション記述子#1、#2、#3、#4が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R0+L0、R1+L1SS、R2+L2SS、R3+L3SSをそれぞれ一つのエクステントと見なして、各サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの各対R0+L0、…、R3+L3 SSは第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。また、第2ファイルSSのファイル・エントリ2021では、アロケーション記述子#1が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4+L4を一つのエクステントと見なして、サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの対R4+L4は第2ファイルSSの3DエクステントEXTSS[4]としてアクセス可能である。
ここで、2D再生専用ブロックL12D、L22D、L32Dは、ファイル2Dにおける層境界LB直前の2DエクステントEXT2D[1]としてのみアクセス可能なファイル2D固有のベースビューデータブロックであり、各3D再生専用ブロックL1SS、L2SS、L3SSは3DエクステントEXTSS[1]、EXTSS[2] 、EXTSS[3]の一部としてのみアクセス可能な、ファイルSS固有のベースビューデータブロックである。
図24において、2Dプレイリスト及び3Dプレイリストは、何れもシームレスに接続する2つのプレイアイテム#1、#2を含む。まず、2Dプレイリストと3Dプレイリストとの各前方プレイアイテムが参照するデータを説明する。2Dプレイリストの前方プレイアイテムは、第1ファイル2Dを参照する。3Dプレイリストの前方プレイアイテムは第1ファイルSSを参照し、3Dプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。上述のように、第1ファイル2Dの2DエクステントEXT2D[0]、EXT2D[1]と、第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]との中身は同じである。これにより、2Dプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL12D、L22D、L32Dを再生することになり、3Dプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1 SS、L2SS、L3SSを再生することになる。従って、2Dプレイリストに基づく2D再生と3Dプレイリストに基づく3D再生とでは、再生経路は異なるが同じデータを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。2Dプレイリストの後方プレイアイテムは、第2ファイル2Dを参照する。3Dプレイリストの後方プレイアイテムは第2ファイルSSを参照し、3Dプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。第2ファイル2Dと第2ファイルSSとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、2Dプレイリストの前方プレイアイテムにより参照される2DエクステントEXT2D[0]の終端からジャンプ直前2DエクステントEXT2D[1]先頭までの距離と、2Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前2DエクステントEXT2D[1]の終端から後方プレイアイテムにより参照される2DエクステントEXT2D[2]先頭までの距離とは、2D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、3Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前3Dエクステントブロック2002と後方プレイアイテムにより参照される3Dエクステントブロック2003間のジャンプ距離は、2D/3D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
図25は、図24に示されているデータ・ブロック群に対する2D再生モードでの再生経路、L/Rモードでの再生経路、及びデプス・モードでの再生経路を示す模式図である。
再生装置200は2D再生モードではファイル2Dを再生する。従って、ベースビュー・データ・ブロックL0が最初の2DエクステントEXT2D[0] として読み出され、2D再生専用ブロックL12D、L22D、L32Dが連続して二番目の2DエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路が示すとおり、ライトビュー・データ・ブロックR0とその直後のベースビュー・データ・ブロックL0との対R0+L0が最初の3DエクステントEXTSS[0]として読み出され、ライトビュー・データ・ブロックR1とその直後の3D再生専用ブロックL1SSとが二番目の3DエクステントEXTSS[1]として読み出され、ライトビュー・データ・ブロックR2とその直後の3D再生専用ブロックL2SSとが三番目の3DエクステントEXTSS[2]として読み出され、ライトビュー・データ・ブロックR3とその直後の3D再生専用ブロックL3SSとが四番目の3DエクステントEXTSS[3]として読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後の3D再生専用ブロックL4とが五番目の3DエクステントEXTSS[4]として読み出される。
図24に示されているとおり、2D再生モードでは、2D再生専用ブロックL12D、L22D、L32Dは読み出されるが、3D再生専用ブロックL1SS、L2SS、L3SSの読み出しはスキップされる。逆に、L/Rモードでは、2D再生専用ブロックL12D、L22D、L32Dの読み出しはスキップされるが、3D再生専用ブロックL1SS、L2SS、L3SSは読み出される。しかし、データ・ブロックL12D、L22D、L32DとL1SS、L2SS、L3SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置2ではロングジャンプJLYの前で2D再生モードでの再生経路とL/Rモードでの再生経路とが分離されている。デプス・モードについても同様である。
ジャンプ直前2DエクステントEXT2D[1]のサイズSext2D[1]が、2D再生専用ブロックL1 2DのサイズS2D [1]、2D再生専用ブロックL2 2DのサイズS2D[2]、2D再生専用ブロックL3 2DのサイズS2D[3]の和S2D[1]+S2D[2]+S2D[3]に等しい。従って、2D再生モードでのシームレス再生の実現には、その和S2D[1]+S2D[2]+S2D[3]が、ジャンプ直前2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。また、2D再生専用ブロックL1 2Dの直前に位置するジャンプ直前3Dエクステントブロック2002に属するライトビュー・データ・ブロックR1、R2、R3とベースビュー・データ・ブロックL1SS、L2SS、L3SSとの各サイズSext2[1]、Sext2[2]、Sext2[3]、Sext1[1]、Sext1[2]、Sext1[3]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。
ここで、3D再生専用ブロックL1SSは2D再生専用ブロックL12Dの複製データであり、3D再生専用ブロックL2SSは2D再生専用ブロックL22Dの複製データであり、3D再生専用ブロックL3SSは2D再生専用ブロックL32Dの複製データであるので、2D再生専用ブロックL12D、L22D、L32Dの合計サイズS2D[1]+S2D[2]+S2D[3]の拡大は、各3D再生専用ブロックL1SS、L2SS、L3SSの直前に位置するライトビュー・データ・ブロックR1、R2、R3のサイズを拡大させる。しかし、3D再生専用ブロックは三つL1SS、L2SS、L3SSに分割されてライトビュー・データ・ブロックと対になっているので、ライトビュー・データ・ブロックR1、R2、R3の各サイズは、図22に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR2のサイズよりは十分に小さくできる。こうして、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量は、L/Rモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置2では、再生装置200内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが可能である。
以上、配置2ではロングジャンプが発生する地点において、2D再生モードでの再生経路と、L/Rモードでの再生経路とを分離できるため、ジャンプ直前3Dエクステントブロックの終端EXT1[3]のサイズは、2D再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。
また、図24の説明では、ロングジャンプの必要な位置として層境界を例としたが、配置2は、1対nのプレイアイテム多重接続に伴うロングジャンプにも適用することができる。具体的には、前方プレイアイテムについては、図24に示す配置と同様に、2Dプレイリストと3Dプレイリストとで再生経路を分離してデータを配置し、その後にn個の後方プレイアイテムが参照するデータを順に配置することで、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能となる。
[配置3]
図26は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第3例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含むサブTS、及びデプスマップストリームを含むサブTSに属する。以下、この配置を「配置3」という。図26を図20と比較するに、配置3は配置1とは、ジャンプ直前3Dエクステントブロック2002が、ジャンプ直前3Dエクステントブロック2004に置換されている点のみで異なる。その他の特徴については配置3は配置1と同様であるので、その詳細についての説明は配置1についての説明を援用する。
ジャンプ直前3Dエクステントブロック2004におけるインターリーブ配置は、他の3Dエクステントブロックのインターリーブ配置と比べて、デプスマップデータブロックとライトビューデータブロックとの配置順が逆になっており、ライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックがその順で交互に並ぶ。ジャンプ直前3Dエクステントブロック2004に含まれる、3D再生専用ブロックL2SS、L3SSが、2D再生専用ブロック群L22D、L32Dとビット単位で一致することは配置1と同様である。
配置3では図27に示すようにL/Rモードの再生経路において、ライトビューデータブロックR0とレフトビューデータブロックL0との対からなる3DエクステントEXTSS[0]、ライトビューデータブロックR1とレフトビューデータブロックL1との対からなる3DエクステントEXTSS[1]、ライトビューデータブロックR2のみからなる3DエクステントEXTSS[2]、レフトビューデータブロックL2SSとライトビューデータブロックR3との対からなる3DエクステントEXTSS[3]、レフトビューデータブロックL3SSのみからなる3DエクステントEXTSS[4]の順で、データブロックがアクセスされる。
このような配置にすることによって、配置3では、配置1と同様にロングジャンプが発生する地点において2D再生モードでの再生経路とL/Rモードでの再生経路とを分離できるため、ジャンプ直前3Dエクステントブロックの終端EXT1[3]のサイズは2D再生モードでバッファ・アンダーフローを防止するための条件の影響を回避できる。また、配置3は、配置1と同様に1対nのプレイアイテム多重接続に伴うロングジャンプにも適用することができ、前方プレイアイテムから複数のプレイアイテムに分岐してシームレス接続するような多重接続のデータ作成が可能である。
これらに加えて配置3では、デプスモードとL/Rモードとの両方で3D映像を再生する場合のシームレス接続に必要なバッファ余裕量を少なく抑えられる。その結果、2D/3D再生装置がデプスモードとL/Rモードの両方で3D映像を再生するために必要なリードバッファのサイズを、配置1のデータを再生する場合よりも小さくすることができる。バッファ余裕量の具体的な削減量についての詳細は後述する。
尚、図26では、ジャンプ直前3Dエクステントブロック2004において、ライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックがその順で交互に並び、他の3Dエクステントブロックにおいてデプスマップデータブロック、ライトビューデータブロック、レフトビューデータブロックがその順で交互に並ぶとした。しかし、配置3は、ジャンプ直前3Dエクステントブロックのインターリーブ配置が他の3Dエクステントブロックのインターリーブ配置に対して、デプスマップデータブロックとライトビューデータブロックとの順が逆になっていることを特徴としており、例えば、他の3Dエクステントブロックにおいてライトビューデータブロック、デプスマップデータブロック、レフトビューデータブロックの順で交互にインターリブ配置している場合には、ジャンプ直前3Dエクステントブロックでは、デプスマップデータブロック、ライトビューデータブロック、レフトビューデータブロックの順で交互にデータブロックをインタリーブ配置するとよい。
[配置4]
図28は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第4例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含む第1サブTS、及びデプスマップストリームを含む第2サブTSに属する。以下、この配置を「配置4」という。図28を参照するに、層境界LBの前に位置する第1記録層には、デプスマップ・データ・ブロック群…、D1、D2、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第1の3Dエクステント・ブロック」2101という。更に、第1の3Dエクステント・ブロック2101の後端L2と層境界LBとの間に一つのベースビュー・データ・ブロックL32Dが配置されている。一方、層境界LBの後に位置する第2記録層には、デプスマップ・データ・ブロック群D3、D4、…、ライトビュー・データ・ブロック群R3、R4、…、及びベースビュー・データ・ブロック群L3SS、L4、…がインターリーブ配置で記録されている。以下、これらのデータ・ブロック群を「第2の3Dエクステント・ブロック」2102という。
各3Dエクステント・ブロック2101、2102のインターリーブ配置は、図15に示されているものと同様である。すなわち、デプスマップ・データ・ブロック、ライトビュー・データ・ブロック、及びベースビュー・データ・ブロックがその順で交互に並ぶ。更に、三つの連続するデータ・ブロックDn、Rn、Ln(n=…、1、2、3、4、…)間ではエクステントATC時間が等しい。第1の3Dエクステント・ブロック2101の後端に位置する三つのデータ・ブロックD2、R2、L2と、第2の3Dエクステント・ブロック2102の先端に位置する三つのデータ・ブロックD3、R3、L3SSとの間では、各ストリーム・データの内容が連続している。
層境界LBの直前に位置するベースビュー・データ・ブロックL32Dは、第2の3Dエクステント・ブロック2102内の先端のベースビュー・データ・ブロックL3SSとビット単位(bit−for−bit)で一致する。すなわち、それらのデータ・ブロックL32D、L3SSの一方は他方の複製データである。以下、前者L32Dを「2D再生専用ブロック」といい、後者L3SSを「3D再生専用ブロック」という。
図28に示されている各データ・ブロックは、3D再生専用ブロックL3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えばファイル2D(01000.m2ts)のファイル・エントリ2110では、アロケーション記述子#1が、第1の3Dエクステント・ブロック2101内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL1はファイル2Dの一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は、第1の3Dエクステント・ブロック2101内の最後のベースビュー・データ・ブロックL2とその直後の2D再生専用ブロックL32Dとの対L2+L32Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックの対L2+L32Dはファイル2Dの単一の2DエクステントEXT2D[1]としてアクセス可能である。更に、アロケーション記述子#3が、第2の3Dエクステント・ブロック2102内の二番目のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は別の一つの2DエクステントEXT2D[2]としてアクセス可能である。
図28に示されているデータ・ブロック群に対しても、AVストリーム・ファイルのクロスリンクは図15のものと同様に実現される。特に、第1ファイルSSのファイル・エントリ2120では、アロケーション記述子#1、#2、#3、#4が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3SS、R4+L4をそれぞれ一つのエクステントと見なして、各サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの各対R1+L1、R2+L2、R3+L3SS、R4+L4は第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。ここで、層境界LBの直後の3DエクステントEXTSS[3]を除き、3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[3]はそれぞれ、ベースビュー・データ・ブロックL1、L2、L4をファイル2Dと共有する。一方、2D再生専用ブロックL32Dは、層境界LBの直前に位置するファイル2DのエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、3D再生専用ブロックL3SSは、層境界LBの直後の3DエクステントEXTSS[2]の一部としてのみアクセス可能である。
図29は、図28に示されているデータ・ブロック群に対する2D再生モードでの再生経路2201とL/Rモードでの再生経路2202を示す模式図である。尚、デプス・モードでの再生経路は、図15に示されているものから、当業者には容易に類推可能であろう。
再生装置200は2D再生モードではファイル2Dを再生する。従って、2D再生モードでの再生経路2201が示すとおり、まず第1の3Dエクステント・ブロック2101内の最後から二番目のベースビュー・データ・ブロックL1が最初の2DエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第1の3Dエクステント・ブロック2101内の最後のベースビュー・データ・ブロックL2とその直後の2D再生専用ブロックL32Dとの対L2+L32Dが二番目の2DエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2102の先端に位置する5個のデータ・ブロックD3、R3、L3SS、D4、R4の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2102内の二番目のベースビュー・データ・ブロックL4が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路2202が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1+L1が最初の3DエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の3DエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、2D再生専用ブロックL32Dと第2の3Dエクステント・ブロック2102内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2102内の先頭のライトビュー・データ・ブロックR3とその直後の3D再生専用ブロックL3SSとが三番目の3DエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。更に、次のライトビュー・データ・ブロックR4とその直後のベースビュー・データ・ブロックL4とが四番目の3DエクステントEXTSS[3]として連続して読み出される。
図29に示されているとおり、2D再生モードでは、2D再生専用ブロックL32Dは読み出されるが、3D再生専用ブロックL3SSの読み出しはスキップされる。逆に、L/Rモードでは、2D再生専用ブロックL32Dの読み出しはスキップされるが、3D再生専用ブロックL3SSは読み出される。しかし、両方のデータ・ブロックL32D、L3SSはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置4ではロングジャンプJLYの前後で2D再生モードでの再生経路2201とL/Rモードでの再生経路2202とが分離されている。デプス・モードについても同様である。
図29に示されている配置4では上記のとおり、ロングジャンプJLYの前後で2D再生モードでの再生経路2201とL/Rモードでの再生経路2202とが分離されている。従って、図22に示されている配置とは異なり、層境界LBの直前に位置する2DエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。
まず、2DエクステントEXT2D[1]のサイズSext2D[1]はベースビュー・データ・ブロックL2のサイズSext1[1]と2D再生専用ブロックL32DのサイズS2Dとの和Sext1[1]+S2Dに等しい。従って、2D再生モードでのシームレス再生の実現には、その和Sext1[1]+S2Dが、2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する3DエクステントEXTSS[1]に属するライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2との各サイズSext2[1]、Sext1[1]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、2DエクステントEXT2D[1]のうち、3DエクステントEXTSS[1]と共有されるのは、前側に位置するベースビュー・データ・ブロックL2だけである。従って、2D再生専用ブロックL32DのサイズS2Dを適切に拡大することにより、2DエクステントEXT2D[1]のサイズSext2D[1]=Sext1[1]+S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。
ここで、3D再生専用ブロックL3SSは2D再生専用ブロックL32Dの複製データであるので、2D再生専用ブロックL32DのサイズS2Dの拡大は、3D再生専用ブロックL3SSの直前に位置するライトビュー・データ・ブロックR3のサイズを拡大させる。しかし、そのサイズは、図22に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量を、L/Rモードでのシームレス再生に必要最小限の値に更に接近させることができる。
このように、配置4では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが、再生装置200内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。更に、2D再生モードとL/Rモードとで読み込み対象のデータ・ブロックを変更すること、特に2D再生専用ブロックL32Dと3D再生専用ブロックL3SSとの間の切り換えが、再生対象のAVストリーム・ファイルをファイル2DとファイルSSとの間で切り換えるだけで容易に実現可能である。
[配置5]
図30は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第5例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含む第1サブTS、及びデプスマップストリームを含む第2サブTSに属する。以下、この配置を「配置5」という。図30を図28と比較するに、配置5は配置4とは、第2の3Dエクステント・ブロック2402の先端に二個の3D再生専用ブロックL3SS、L4SSが設けられている点で異なる。その他の特徴については配置5は配置4と同様であるので、その詳細についての説明は配置4についての説明を援用する。
層境界LBの直前に位置する2D再生専用ブロック(L3+L4)2Dは第2の3Dエクステント・ブロック2402内の3D再生専用ブロックの対L3SS、L4SSとビット単位で一致する。すなわち、2D再生専用ブロック(L3+L4)2Dと3D再生専用ブロックの対L3SS、L4SSとの一方は他方の複製データである。
図30に示されている各データ・ブロックは、3D再生専用ブロックL3SS、L4SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば、ファイル2Dのファイル・エントリ2410では、アロケーション記述子#1が、第1の3Dエクステント・ブロック2401内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL1はファイル2Dの一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2が、第1の3Dエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL2とその直後の2D再生専用ブロック(L3+L4)2Dとの対L2+(L3+L4)2Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックの対L2+(L3+L4)2Dはファイル2Dの一つの2DエクステントEXT2D[1]としてアクセス可能である。更に、アロケーション記述子#3が、第2の3Dエクステント・ブロック2402内の三番目のベースビュー・データ・ブロックL5のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL5は別の一つの2DエクステントEXT2D[2]としてアクセス可能である。
第1ファイルSSのファイル・エントリ2420では、アロケーション記述子#1、#2、#3、#4、#5が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3SS、R4+L4SS、R5+L5をそれぞれ一つのエクステントと見なして、各サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの各対R1+L1、…、R5+L5は第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]、EXTSS[4]としてアクセス可能である。2D再生専用ブロック(L3+L4)2Dはファイル2DのエクステントEXT2D[1]の一部としてのみアクセス可能であり、各3D再生専用ブロックL3SS、L4SSは3DエクステントEXTSS[2]、EXTSS[3]の一部としてのみアクセス可能である。
図31は、図30に示されているデータ・ブロック群に対する2D再生モードでの再生経路2501とL/Rモードでの再生経路2502とを示す模式図である。尚、デプス・モードでの再生経路は、図15に示されているものから、当業者には容易に類推可能であろう。
再生装置200は2D再生モードではファイル2Dを再生する。従って、2D再生モードでの再生経路2501が示すとおり、まず第1の3Dエクステント・ブロック2401内の最後から二番目のベースビュー・データ・ブロックL1が最初の2DエクステントEXT2D[0]として読み出され、その直後のデプスマップ・データ・ブロックD2とライトビュー・データ・ブロックR2との読み出しが最初のジャンプJ2D1によってスキップされる。次に、第1の3Dエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL2とその直後の2D再生専用ブロック(L3+L4)2Dとの対L2+(L3+L4)2Dが二番目の2DエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2402の先端に位置する8個のデータ・ブロックD3、R3、L3SS、D4、R4、L4SS、D5、R5の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2402内の三番目のベースビュー・データ・ブロックL5が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路2502が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1+L1が最初の3DエクステントEXTSS[0]として連続して読み出され、その直後のデプスマップ・データ・ブロックD2の読み出しが最初のジャンプJLR1によってスキップされる。次に、二番目のライトビュー・データ・ブロックR2とその直後のベースビュー・データ・ブロックL2とが二番目の3DエクステントEXTSS[1]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、2D再生専用ブロック(L3+L4)2Dと第2の3Dエクステント・ブロック2402内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2402内の先頭のライトビュー・データ・ブロックR3とその直後の3D再生専用ブロックL3SSとが三番目の3DエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。同様に、次のライトビュー・データ・ブロックR4とその直後の3D再生専用ブロックL4SSとが四番目の3DエクステントEXTSS[3]として連続して読み出され、その直後のデプスマップ・データ・ブロックD5の読み出しが三番目のジャンプJLR3によってスキップされる。更に次のライトビュー・データ・ブロックR5とその直後のベースビュー・データ・ブロックL5とが五番目の3DエクステントEXTSS[4]として連続して読み出される。
図31に示されているとおり、2D再生モードでは、2D再生専用ブロック(L3+L4)2Dは読み出されるが、3D再生専用ブロックL3SS、L4SSの読み出しはスキップされる。逆にL/Rモードでは、2D再生専用ブロック(L3+L4)2Dの読み出しはスキップされるが、3D再生専用ブロックL3SS、L4SSは読み出される。しかし、2D再生専用ブロック(L3+L4)2Dと3D再生専用ブロックの対L3SS、L4SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置5ではロングジャンプJLYの前後で2D再生モードでの再生経路2501とL/Rモードでの再生経路2502とが分離されている。従って、層境界LBの直前に位置する2DエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。尚、デプス・モードについても同様である。
まず、2DエクステントEXT2D[1]のサイズSext2D[1]はベースビュー・データ・ブロックL2のサイズSext1[1]と2D再生専用ブロック(L3+L4)2DのサイズS2Dとの和Sext1[1]+S2Dに等しい。従って、2D再生モードでのシームレス再生の実現には、その和Sext1[1]+S2Dが、2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する3DエクステントEXTSS[1]に属するライトビュー・データ・ブロックR2とベースビュー・データ・ブロックL2との各サイズSext2[1]、Sext1[1]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、2D再生専用ブロック(L3+L4)2DのサイズS2Dの適切な拡大により、2DエクステントEXT2D[1]のサイズSext2D[1]=Sext1[1]+S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。
ここで、3D再生専用ブロックの対L3SS、L4SSは2D再生専用ブロック(L3+L4)2Dの複製データであるので、2D再生専用ブロック(L3+L4)2DのサイズS2Dの拡大は、各3D再生専用ブロックL3SS、L4SSの直前に位置するライトビュー・データ・ブロックR3、R4のサイズを拡大させる。しかし、一つの2D再生専用ブロック(L3+L4)2Dに対して3D再生専用ブロックは二つL3SS、L4SSに分割されているので、各サイズは、図22に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量は、L/Rモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置5では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが、再生装置200のデコーダ内に確保されるべきバッファ容量を必要最小限に抑えたままで可能である。更に、2D再生モードとL/Rモードとで読み込み対象のデータ・ブロックを変更すること、特に2D再生専用ブロック(L3+L4)2Dと3D再生専用ブロックの対L3SS、L4SSとの間の切り換えが、再生対象のAVストリーム・ファイルをファイル2DとファイルSSとの間で切り換えるだけで容易に実現可能である。尚、デプス・モードでも同様である。
配置5では、2D再生専用ブロック(L3+L4)2Dの複製データが二個の3D再生専用ブロックL3SS、L4SSとして設けられている。その他に、複製データが三個以上の3D再生専用ブロックとして設けられていてもよい。
[配置6]
図32は、記録媒体100の層境界の前後に記録されたデータ・ブロック群の物理的な配置の第6例を示す模式図である。これらのデータ・ブロック群は、レフトビュービデオストリームを含むメインTS、ライトビュービデオストリームを含む第1サブTS、及びデプスマップストリームを含む第2サブTSに属する。以下、この配置を「配置6」という。図32を図30と比較するに、配置6は配置5とは、2D再生専用ブロック(L2+L3)2Dが単独で一つの2DエクステントEXT2D[1]としてアクセス可能である点で異なる。その他の特徴については配置6は配置5と同様であるので、その詳細についての説明は配置5についての説明を援用する。
層境界LBの直前に位置する2D再生専用ブロック(L2+L3)2Dは第2の3Dエクステント・ブロック2602内の3D再生専用ブロックの対L2SS、L3SSとビット単位で一致する。すなわち、2D再生専用ブロック(L2+L3)2Dと3D再生専用ブロックの対L2SS、L3SSとの一方は他方の複製データである。
図32に示されている各データ・ブロックは、3D再生専用ブロックL2SS、L3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば、ファイル2Dのファイル・エントリ2610では、アロケーション記述子#1は、第1の3Dエクステント・ブロック2401内の最後のベースビュー・データ・ブロックL1のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL1は一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は2D再生専用ブロック(L2+L3)2Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、2D再生専用ブロック(L2+L3)2Dは次の2DエクステントEXT2D[1]としてアクセス可能である。アロケーション記述子#3は、第2の3Dエクステント・ブロック2602内の三番目のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は三番目の2DエクステントEXT2D[2]としてアクセス可能である。
第1ファイルSSのファイル・エントリ2620では、アロケーション記述子#1、#2、#3、#4が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2SS、R3+L3SS、R4+L4をそれぞれ一つのエクステントと見なして、各サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの各対R1+L1、…、R4+L4は第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。2D再生専用ブロック(L2+L3)2Dはファイル2Dの一つのエクステントEXT2D[1]としてのみアクセス可能であり、各3D再生専用ブロックL2SS、L3SSは3DエクステントEXTSS[1]、EXTSS[2]の一部としてのみアクセス可能である。
図33は、図32に示されているデータ・ブロック群に対する2D再生モードでの再生経路2701とL/Rモードでの再生経路2702とを示す模式図である。尚、デプス・モードでの再生経路は、図15に示されているものから、当業者には容易に類推可能であろう。
再生装置200は2D再生モードではファイル2Dを再生する。従って、2D再生モードでの再生経路2701が示すとおり、まず第1の3Dエクステント・ブロック2601内の最後のベースビュー・データ・ブロックL1が最初の2DエクステントEXT2D[0]として読み出される。次に、その直後の2D再生専用ブロック(L2+L3)2Dが二番目の2DエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2602の先端に位置する8個のデータ・ブロックD2、R2、L2SS、D3、R3、L3SS、D4、R4の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2602内の三番目のベースビュー・データ・ブロックL4が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、L/Rモードでの再生経路2702が示すとおり、まず先頭のライトビュー・データ・ブロックR1とその直後のベースビュー・データ・ブロックL1との対R1+L1が最初の3DエクステントEXTSS[0]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、2D再生専用ブロック(L2+L3)2Dと第2の3Dエクステント・ブロック2602内の先頭のデプスマップ・データ・ブロックD3との読み出しがスキップされる。次に、第2の3Dエクステント・ブロック2602内の先頭のライトビュー・データ・ブロックR2とその直後の3D再生専用ブロックL2SSとが二番目の3DエクステントEXTSS[1]として連続して読み出され、その直後のデプスマップ・データ・ブロックD3の読み出しが最初のジャンプJLR1によってスキップされる。同様に、次のライトビュー・データ・ブロックR3とその直後の3D再生専用ブロックL3SSとが三番目の3DエクステントEXTSS[2]として連続して読み出され、その直後のデプスマップ・データ・ブロックD4の読み出しが二番目のジャンプJLR2によってスキップされる。更に次のライトビュー・データ・ブロックR4とその直後のベースビュー・データ・ブロックL4とが四番目の3DエクステントEXTSS[3]として連続して読み出される。
図33に示されているとおり、2D再生モードでは、2D再生専用ブロック(L2+L3)2Dは読み出されるが、3D再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆にL/Rモードでは、2D再生専用ブロック(L2+L3)2Dの読み出しはスキップされるが、3D再生専用ブロックL2SS、L3SSは読み出される。しかし、2D再生専用ブロック(L2+L3)2Dと3D再生専用ブロックの対L2SS、L3SSとはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置6ではロングジャンプJLYの前後で2D再生モードでの再生経路2701とL/Rモードでの再生経路2702とが分離されている。従って、層境界LBの直前に位置する2DエクステントEXT2D[1]のサイズSext2D[1]とその直前のライトビュー・データ・ブロックR2のサイズSext2[1]とが、以下のように別々に決定可能である。尚、デプス・モードについても同様である。
まず、層境界LBの直前で連続する二つの2DエクステントEXT2D[0]、EXT2D[1]のサイズの和Sext2D[0]+Sext2D[1]はベースビュー・データ・ブロックL1のサイズSext2D[0]と2D再生専用ブロック(L2+L3)2DのサイズS2Dとの和Sext1[1]+S2Dに等しい。従って、2D再生モードでのシームレス再生の実現には、その和Sext1[1]+S2Dが、2DエクステントEXT2D[1]の読み出し開始からロングジャンプJLYの完了までの間にリード・バッファからシステム・ターゲット・デコーダに送られるデータ量以上であればよい。一方、層境界LBの直前に位置する3DエクステントEXTSS[0]に属するライトビュー・データ・ブロックR1のサイズSext2[0]とベースビュー・データ・ブロックL1との各サイズSext2[0]、Sext2D[0]は、ロングジャンプJLYの直前までバッファ余裕量が維持できる程度の値であればよい。ここで、2D再生専用ブロック(L2+L3)2DのサイズS2Dの適切な拡大により、2Dエクステントの対EXT2D[0]、EXT2D[1]のサイズの和Sext2D[0]+Sext2D[1]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext2D[0]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR1のサイズSext2[0]も更に小さく制限することができる。
ここで、3D再生専用ブロックの対L2SS、L3SSは2D再生専用ブロック(L2+L3)2Dの複製データであるので、2D再生専用ブロック(L2+L3)2DのサイズS2Dの拡大は、各3D再生専用ブロックL2SS、L3SSの直前に位置するライトビュー・データ・ブロックR2、R3のサイズを拡大させる。しかし、一つの2D再生専用ブロック(L2+L3)2Dに対して3D再生専用ブロックは二つL2SS、L3SSに分割されているので、各サイズは、図22に示されている層境界LBの直前に位置するライトビュー・データ・ブロックR3のサイズよりは十分に小さくできる。こうして、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量は、L/Rモードでのシームレス再生に必要最小限の値まで更に削減可能である。
このように、配置6では各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが、再生装置200内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。更に、2D再生モードとL/Rモードとで読み込み対象のデータ・ブロックを変更すること、特に2D再生専用ブロック(L2+L3)2Dと3D再生専用ブロックの対L2SS、L3SSとの間の切り換えが、再生対象のAVストリーム・ファイルをファイル2DとファイルSSとの間で切り換えるだけで容易に実現可能である。尚、デプス・モードでも同様である。
配置6では、2D再生専用ブロック(L2+L3)2Dの複製データが二個の3D再生専用ブロックL2SS、L3SSとして設けられている。その他に、複製データが図28のように一個の3D再生専用ブロックとして設けられてもよく、又は三個以上の3D再生専用ブロックとして設けられていてもよい。
尚、配置1−5とは異なり、2D再生専用ブロックはファイル2Dの二個以上のエクステントとしてアクセス可能であってもよい。更に、各データ・ブロックは二種類以上のファイル2D又はファイルSSのエクステントとしてアクセス可能であってもよい。
<L/Rモードのみに対応する多重化ストリーム・データの配置>
3D映像の再生にL/Rモードのみが利用されるとき、上記の配置1−6からデプスマップ・データ・ブロックが除去されてもよい。図34の(a)は、図28に示されている配置4からデプスマップ・データ・ブロックを除去したものを示す模式図である。これらのデータ・ブロック群は、レフトビューストリームを含むメインTSとライトビュービデオストリームを含むサブTSとに属する。図34の(a)を参照するに、層境界LBの前に位置する第1の3Dエクステント・ブロック2801では、ライトビュー・データ・ブロック群…、R1、R2、及びベースビュー・データ・ブロック群…、L1、L2がインターリーブ配置で記録されている。一方、層境界LBの後に位置する第2の3Dエクステント・ブロック2802では、ライトビュー・データ・ブロック群R3、R4、…、及びベースビュー・データ・ブロック群L3SS、L4、…がインターリーブ配置で記録されている。更に、第1の3Dエクステント・ブロック2801の後端L2と層境界LBとの間に2D再生専用ブロックL32Dが配置され、第2の3Dエクステント・ブロック2802の先端には3D再生専用ブロックL3SSが配置されている。それらのデータ・ブロックL32D、L3SSの一方は他方の複製データであり、ビット単位で一致する。
各3Dエクステント・ブロック2801、2802のインターリーブ配置では、ライトビュー・データ・ブロックとベースビュー・データ・ブロックとがその順で交互に並ぶ。更に、二つの連続するデータ・ブロックRn、Ln(n=…、1、2、3、4、…)間ではエクステントATC時間が等しい。第1の3Dエクステント・ブロック2801の後端に位置する二つのデータ・ブロックR2、L2と、第2の3Dエクステント・ブロック2802の先端に位置する二つのデータ・ブロックR3、L3SSとの間では、各ストリーム・データの内容が連続している。
図34の(a)に示されている各データ・ブロックは、3D再生専用ブロックL3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば、ファイル2Dのファイル・エントリ2810では、アロケーション記述子#1は、第1の3Dエクステント・ブロック2801内の最後から二番目のベースビュー・データ・ブロックL1のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL1は一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は、そのベースビュー・データ・ブロックの対L2+L32Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックの対L2+L32Dは二番目の2DエクステントEXT2D[1]としてアクセス可能である。アロケーション記述子#3は、第2の3Dエクステント・ブロック2802内の二番目のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は三番目の2DエクステントEXT2D[2]としてアクセス可能である。
図34の(a)に示されているデータ・ブロック群に対しても、AVストリーム・ファイルのクロスリンクは図15のものと同様に実現される。特に、各3Dエクステント・ブロック2801、2802からはデプスマップ・データ・ブロックが除去されているので、エクステントATC時間の等しいライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上、連続して配置されてもよい。その場合、それら二つ以上の対が一つの3Dエクステントとしてアクセスされてもよい。図34の(a)を参照するに、ファイルSSのファイル・エントリ2820では、アロケーション記述子#1は、第1の3Dエクステント・ブロック2801のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR1、L1、R2、L2を一つのエクステントと見なして、それらの全体のサイズと先端のLBNとを示す。従って、それらのデータ・ブロックR1、L1、R2、L2、は一つの3DエクステントEXTSS[0]としてアクセス可能である。アロケーション記述子#2は、第2の3Dエクステント・ブロック2802のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR3、L3SS、R4、L4を一つのエクステントと見なして、それらの全体のサイズと先端のLBNとを示す。従って、それらのデータ・ブロックR3、L3SS、R4、L4は次の3DエクステントEXTSS[1]としてアクセス可能である。ここで、3DエクステントEXTSS[0]、EXTSS[1]はそれぞれ、ベースビュー・データ・ブロックL1、L2、L4を2DエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]と共有する。一方、2D再生専用ブロックL32Dは、層境界LBの直前に位置する2DエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、3D再生専用ブロックL3SSは、層境界LBの直後の3DエクステントEXTSS[1]の一部としてのみアクセス可能である。
図34の(b)は、図34の(a)に示されているデータ・ブロック群に対する2D再生モードでの再生経路2803とL/Rモードでの再生経路2804とを示す模式図である。
再生装置200は2D再生モードではファイル2Dを再生する。従って、2D再生モードでの再生経路2803が示すとおり、まず第1の3Dエクステント・ブロック2801内の最後から二番目のベースビュー・データ・ブロックL1が最初の2DエクステントEXT2D[0]として読み出され、その直後のライトビュー・データ・ブロックR2の読み出しが最初のジャンプJ2D1によってスキップされる。次に、第1の3Dエクステント・ブロック2801内の最後のベースビュー・データ・ブロックL2とその直後の2D再生専用ブロックL32Dとの対L2+L32Dが二番目の2DエクステントEXT2D[1]として連続して読み出される。その直後の層境界LBではロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、第2の3Dエクステント・ブロック2802の先端に位置する3個のデータ・ブロックR3、L3SS、R4の読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2802内の二番目のベースビュー・データ・ブロックL4が三番目の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/RモードではファイルSSを再生する。従って、L/Rモードでの再生経路2804が示すとおり、まず第1の3Dエクステント・ブロック2801内のデータ・ブロック群R1、L1、R2、L2が最初の3DエクステントEXTSS[0]として連続して読み出される。その直後にロングジャンプJLYが生じ、フォーカス・ジャンプの実行と共に、2D再生専用ブロックL32Dの読み出しがスキップされる。続いて、第2の3Dエクステント・ブロック2802内のデータ・ブロック群R3、L3SS、R4、L4とが次の3DエクステントEXTSS[1]として連続して読み出される。
図34の(b)に示されているとおり、2D再生モードでは、2D再生専用ブロックL32Dは読み出されるが、3D再生専用ブロックL3SSの読み出しはスキップされる。逆に、L/Rモードでは、2D再生専用ブロックL32Dの読み出しはスキップされるが、3D再生専用ブロックL3SSは読み出される。しかし、両方のデータ・ブロックL32D、L3SSはビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置4では、L/Rモードのみに対応可能な場合でも、ロングジャンプJLYの前後で2D再生モードでの再生経路2801とL/Rモードでの再生経路2802とが分離されている。従って、2D再生専用ブロックL32DのサイズS2Dを適切に拡大することにより、2DエクステントEXT2D[1]のサイズSext2D[1]=Sext1[1]+S2Dを一定に維持したまま、ベースビュー・データ・ブロックL2のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。その結果、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量をL/Rモードでのシームレス再生に必要最小限の値に更に接近させることができる。
続いて、配置1からデプスマップ・データ・ブロックを除去した例について説明する。
図35は、図20に示されている配置1からデプスマップ・データ・ブロックを除去したものを示す模式図である。これらのデータ・ブロック群は、レフトビューストリームを含むメインTSとライトビュービデオストリームを含むサブTSとに属する。図35に示すように、層境界LBの前に位置する第1記録層には、ライトビュー・データ・ブロック群…、R0、R1、及びベースビュー・データ・ブロック群…、L0、L1がインターリーブ配置された第1の3Dエクステント・ブロック2005が記録されている。また、第1の3Dエクステント・ブロック2005の後端L1に連続して2D再生専用ブロックL22D、L32Dが配置されている。更に、2D再生専用ブロックL32Dと層境界LBとの間には、ライトビュー・データ・ブロックR2、R3、及び3D再生専用ブロックL2SS、L3SSがインターリーブ配置された第2の3Dエクステント・ブロック2006が記録されている。
2D再生専用ブロックL22D、L32Dと3D再生専用ブロックL2SS、L3SSとの一方は他方の複製データであり、ビット単位で一致する。一方、層境界LBの後に位置する第2記録層には、ライトビュー・データ・ブロック群R4、…、及びベースビュー・データ・ブロック群L4、…がインターリーブ配置された第3の3Dエクステント・ブロック2007が記録されている。
各3Dエクステント・ブロック2005、2006、2007のインターリーブ配置では、ライトビュー・データ・ブロックとベースビュー・データ・ブロックとがその順で交互に並ぶ。更に、二つの連続するデータ・ブロックRn、Ln(n=…、1、2、3、4、…)間ではエクステントATC時間が等しい。第1の3Dエクステント・ブロック2005の後端に位置する二つのデータ・ブロックR1、L1と、第2の3Dエクステント・ブロック2006の先端に位置する二つのデータ・ブロックR2、L2SSとの間では、各ストリーム・データの内容が連続し、第2の3Dエクステント・ブロック2006の後端に位置する二つのデータ・ブロックR3、L3SSと、第3の3Dエクステント・ブロック2007の先端に位置する二つのデータ・ブロックR4、L4との間では、各ストリーム・データの内容が連続している。
図35に示されている各データ・ブロックは、3D再生専用ブロックL2SS、L3SSを除いて、ファイル2D又はファイルDEPのいずれかのエクステントとしてアクセス可能である。例えば第1ファイル2Dのファイル・エントリ2010では、アロケーション記述子#1が、第1の3Dエクステント・ブロック2005内の最後から二番目のベースビュー・データ・ブロックL0のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL0は第1ファイル2Dの一つの2DエクステントEXT2D[0]としてアクセス可能である。アロケーション記述子#2は、第1の3Dエクステント・ブロック2005内の最後のベースビュー・データ・ブロックL1とその直後に連続する2D再生専用ブロック群L22D、L32Dとからなるベースビュー・データ・ブロックの一群L1+ L22D+L32Dを単一のエクステントと見なしてそのサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックの一群L1+ L22D+L32Dは、第1ファイル2Dの単一の2DエクステントEXT2D[1]としてアクセス可能である。これらのファイル2Dにおけるベースビュー・データ・ブロックL1、L22D、L32Dは、ロングジャンプを生じさせる場所の直前において、連続長が大きいエクステントを構成している。ファイル2Dは、ロングジャンプの直前で、ビックエクステントを形成することができるので、2D再生モードで再生する場合であっても、リードバッファのアンダーフローを危惧する必要はない。また、第2ファイル2Dのファイル・エントリ2011では、アロケーション記述子#1が、第3の3Dエクステント・ブロック2007内のベースビュー・データ・ブロックL4のサイズとその先端のLBNとを示す。従って、そのベースビュー・データ・ブロックL4は第2ファイル2Dの一つの2DエクステントEXT2D[2]としてアクセス可能である。
図35に示されているデータ・ブロック群に対しても、AVストリーム・ファイルのクロスリンクは図15のものと同様に実現される。特に、各3Dエクステント・ブロック2005、2006、2007からはデプスマップ・データ・ブロックが除去されているので、エクステントATC時間の等しいライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上、連続して配置されてもよい。その場合、それら二つ以上の対が一つの3Dエクステントとしてアクセスされてもよい。図35を参照するに、第1ファイルSSのファイル・エントリ2020では、アロケーション記述子#1は、第1の3Dエクステント・ブロック2005のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR0、L0、R1、L1を一つのエクステントと見なして、それらの全体のサイズと先端のLBNとを示す。従って、それらのデータ・ブロックR0、L0、R1、L1、は一つの3DエクステントEXTSS[0]としてアクセス可能である。アロケーション記述子#2は、第2の3Dエクステント・ブロック2006のうち、四つの連続するライトビュー・データ・ブロックとベースビュー・データ・ブロックR2、L2SS、R3、L3SSを一つのエクステントと見なして、それらの全体のサイズと先端のLBNとを示す。従って、それらのデータ・ブロックR2、L2SS、R3、L3SSは次の3DエクステントEXTSS[1]としてアクセス可能である。また、第2ファイルSSのファイル・エントリ2021では、アロケーション記述子#1が、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R4+L4を一つのエクステントと見なして、サイズとその先端のLBNとを示す。従って、隣接するデータ・ブロックの対R4+L4は第2ファイルSSの3DエクステントEXTSS[4]としてアクセス可能である。
ここで、3DエクステントEXTSS[0]、EXTSS[1]はそれぞれ、ベースビュー・データ・ブロックL0、L1、L4を2DエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]と共有する。一方、2D再生専用ブロックL22D、L32Dは、層境界LBの前に位置する2DエクステントEXT2D[1]の一部としてのみアクセス可能である。更に、3D再生専用ブロックL2SS、L3SSは、層境界LBの直後の3DエクステントEXTSS[1]の一部としてのみアクセス可能である。
図35において、2Dプレイリスト及び3Dプレイリストは、何れもシームレスに接続する2つのプレイアイテム#1、#2を含む。2Dプレイリストの前方プレイアイテムは、第1ファイル2Dを参照する。3Dプレイリストの前方プレイアイテムは第1ファイルSSを参照し、3Dプレイリストの前方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。上述のように、第1ファイル2Dの2DエクステントEXT2D[0]、EXT2D[1]と、第1ファイルSSの3DエクステントEXTSS[0]、EXTSS[1]とで参照するベースビューデータブロックの中身は同じである。これにより、2Dプレイリストの再生では、プレイアイテムのシームレス接続地点においてベースビューデータブロックL1、L22D、L32Dを再生することになり、3Dプレイリストの再生では、プレイアイテムのシームレス接続地点において同内容のL1、L2SS、L3SSを再生することになる。従って、2Dプレイリストに基づく2D再生と3Dプレイリストに基づく3D再生とでは、再生経路は異なるが同じレフトビュー・ビデオ・フレームを再生することができる。
次に、各後方プレイアイテムが参照するデータを説明する。2Dプレイリストの後方プレイアイテムは、第2ファイル2Dを参照する。3Dプレイリストの後方プレイアイテムは第2ファイルSSを参照し、3Dプレイアイテムの後方プレイアイテムに同期して再生するサブプレイアイテムからはファイルDEPを参照する。第2ファイル2Dと第2ファイルSSとは、本図に示すように同じベースビューデータブロックL4を実体として用いている。
ここで、2Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前2DエクステントEXT2D[1]の終端から、後方プレイアイテムにより参照される2DエクステントEXT2D[2]先頭までの距離は、2D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。また、3Dプレイリストの前方プレイアイテムにより参照されるジャンプ直前3Dエクステントブロック2006と後方プレイアイテムにより参照される3Dエクステントブロック2007間のジャンプ距離は、2D/3D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。
再生装置200は2D再生モードではファイル2Dを再生する。従って、ベースビュー・データ・ブロックL0が最初の2DエクステントEXT2D[0] として読み出され、ベースビュー・データ・ブロックL1とその直後の2D再生専用ブロックL22D、L32Dとが連続して二番目の2DエクステントEXT2D[1]として読み出され、ロングジャンプの後に、ベースビュー・データ・ブロックL4が第2ファイル2Dの最初の2DエクステントEXT2D[2]として読み出される。
再生装置200はL/Rモードでは第1ファイルSSを再生する。従って、まず第1の3Dエクステント・ブロック2005内のデータ・ブロック群R0、L0、R1、L1が最初の3DエクステントEXTSS[0]として連続して読み出され、第2の3Dエクステント・ブロック2006内のデータ・ブロック群R2、L2SS、R3、L3SSが二番目の3DエクステントEXTSS[1]として連続して読み出され、ロングジャンプの後に、ライトビュー・データ・ブロックR4とその直後のベースビューデータブロックL4とが第2ファイルSSの最初の3DエクステントEXTSS[4]として読み出される。
このように、2D再生モードでは、2D再生専用ブロックL22D、L32Dは読み出されるが、3D再生専用ブロックL2SS、L3SSの読み出しはスキップされる。逆に、L/Rモードでは、2D再生専用ブロックL22D、L32Dの読み出しはスキップされるが、3D再生専用ブロックL2SS、L3SSは読み出される。しかし、データ・ブロックL22D、L2SSはビット単位で一致しており、データ・ブロックL32D、L3SSもビット単位で一致しているので、いずれの再生モードでも、再生されるレフトビュー・ビデオ・フレームは等しい。このように、配置1では、3D再生としてL/Rモードのみに対応可能な場合でも、ロングジャンプの前で2D再生モードでの再生経路とL/Rモードでの再生経路とが分離されている。従って、2D再生専用ブロックL22D、L32DのサイズS2D[2]、S2D[3]を適切に拡大することにより、2DエクステントEXT2D[1]のサイズSext2D[1]=Sext1[1]+S2D[2]+S2D[3]を一定に維持したまま、ベースビュー・データ・ブロックL1のサイズSext1[1]を更に小さく制限することができる。それに伴い、ライトビュー・データ・ブロックR2のサイズSext2[1]も更に小さく制限することができる。その結果、L/Rモードの再生装置200内に確保されるべきリード・バッファの容量をL/Rモードでのシームレス再生に必要最小限の値に更に接近させることができる。他の配置2、3、5、及び6についても同様である。
このように、配置1−6がL/Rモードのみ対応可能なものであっても、各データ・ブロックを、ロングジャンプ中での映像のシームレス再生が2D再生モードとL/Rモードとの両方で実現可能であるようなサイズに設計することが、再生装置200内に確保されるべきリード・バッファの容量を必要最小限に抑えたままで可能である。
<AVストリーム・ファイルに含まれるその他のTSパケット>
AVストリーム・ファイルに含まれるTSパケットの種類には、図10、11に示されているエレメンタリ・ストリームから変換されたもの以外にも、PAT(Program Association Table)、PMT(Program Map Table)、及びPCR(Program Clock Reference)がある。PCR、PMT、及びPATは欧州デジタル放送規格で定められたものであり、本来は、一つの番組を構成するパーシャル・トランスポート・ストリームを規定する役割を持つ。PCR、PMT、及びPATを利用することで、AVストリーム・ファイルも、そのパーシャル・トランスポート・ストリームと同様に規定される。具体的には、PATは、同じAVストリーム・ファイルに含まれるPMTのPIDを示す。PAT自身のPIDは0である。PMTは、同じAVストリーム・ファイルに含まれる、映像・音声・字幕等を表す各エレメンタリ・ストリームのPIDとその属性情報とを含む。PMTは更に、そのAVストリーム・ファイルに関する各種のディスクリプタ(記述子ともいう。)を含む。ディスクリプタには特に、そのAVストリーム・ファイルのコピーの許可/禁止を示すコピー・コントロール情報が含まれる。PCRは、自身に割り当てられたATSに対応させるべきSTC(System Time Clock)の値を示す情報を含む。ここで、STCは、デコーダ内でPTS及びDTSの基準として利用されるクロックである。デコーダはPCRを利用して、ATCにSTCを同期させる。
図36は、PMT2910のデータ構造を示す模式図である。PMT2910は、PMTヘッダ2901、ディスクリプタ2902、及びストリーム情報2903を含む。PMTヘッダ2901は、PMT2910に含まれるデータの長さ等を示す。各ディスクリプタ2902は、PMT2910を含むAVストリーム・ファイルの全体に関するディスクリプタである。前述のコピー・コントロール情報はディスクリプタ2902の一つに含まれる。ストリーム情報2903は、AVストリーム・ファイルに含まれる各エレメンタリ・ストリームに関する情報であり、一つずつ異なるエレメンタリ・ストリームに割り当てられている。各ストリーム情報2903は、ストリーム・タイプ2931、PID2932、及びストリーム・ディスクリプタ2933を含む。ストリーム・タイプ2931は、そのエレメンタリ・ストリームの圧縮に利用されたコーデックの識別情報等を含む。PID2932は、そのエレメンタリ・ストリームのPIDを示す。ストリーム・ディスクリプタ2933は、そのエレメンタリ・ストリームの属性情報、例えばフレームレート及びアスペクト比を含む。
PCR、PMT、及びPATを利用することで、再生装置内のデコーダにAVストリーム・ファイルを、欧州デジタル放送規格に準拠のパーシャル・トランスポート・ストリームと同様に処理させることができる。それにより、記録媒体100用の再生装置と欧州デジタル放送規格に準拠の端末装置との間の互換性を確保することができる。
以上がストリームファイルの詳細についての説明である。
<クリップ情報ファイル>
以下、クリップ情報ファイルの詳細について説明する。
図37は、2Dクリップ情報ファイル531のデータ構造を示す模式図である。ディペンデントビュー・クリップ情報ファイルも同様なデータ構造を持つ。以下では、まず、クリップ情報ファイル全般に共通するデータ構造を2Dクリップ情報ファイル531のデータ構造を例に説明する。その後、2Dクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとのデータ構造上の相違点について説明する。
図37を参照するに、2Dクリップ情報ファイル531は、クリップ情報3010、ストリーム属性情報3020、エントリ・マップ3030、及び3Dメタデータ3040を含む。3Dメタデータ3040はオフセット・テーブル3041とエクステント起点3042とを含む。
クリップ情報3010は、図37に示されているように、システムレート3011、再生開始時刻3012、及び再生終了時刻3013を含む。システムレート3011は、対応するファイル2Dに属する“TSパケット”が再生装置200内でリード・バッファからシステム・ターゲット・デコーダへ転送される速度の最高値を示す。ファイル2Dでは、TSパケットの転送速度がシステムレート以下に抑えられるように、ソースパケットのATSの間隔が設定されている。再生開始時刻3012は、ファイル2Dの先頭のVAUのPTS、例えば先頭の映像フレームのPTSを示す。再生終了時刻3012は、ファイル2Dの後端のVAUのPTSから所定量遅れたSTCの値、例えば最後の映像フレームのPTSに1フレーム当たりの再生時間を加えた値を示す。
ストリーム属性情報3020は、図37に示されているように、ファイル2Dに含まれる各エレメンタリ・ストリームのPID3021とその属性情報3022との間の対応表である。属性情報3022は、ビデオ・ストリーム、オーディオ・ストリーム、PGストリーム、及びIGストリームのそれぞれで異なる。例えばプライマリ・ビデオ・ストリームのPID0x1011に対応付けられた属性情報は、そのビデオ・ストリームの圧縮に利用されたコーデックの種類、そのビデオ・ストリームを構成する各ピクチャの解像度、アスペクト比、及びフレームレートを含む。一方、プライマリ・オーディオ・ストリームのPID0x1101に対応付けられた属性情報は、そのオーディオ・ストリームの圧縮に利用されたコーデックの種類、そのオーディオ・ストリームに含まれるチャンネル数、言語、及びサンプリング周波数を含む。属性情報3022は再生装置200により、デコーダの初期化に利用される。
[エントリ・マップ]
図38の(a)は、エントリ・マップ3030のデータ構造を示す模式図である。図38の(a)を参照するに、エントリ・マップ3030はテーブル3100を含む。テーブル3100は、メインTSに多重化されたビデオ・ストリームと同数であり、各ビデオ・ストリームに一つずつ割り当てられている。図38の(a)では各テーブル3100が割り当て先のビデオ・ストリームのPIDで区別されている。各テーブル3100はエントリ・マップ・ヘッダ3101とエントリ・ポイント3102とを含む。エントリ・マップ・ヘッダ3101は、そのテーブル3100に対応付けられたPIDと、そのテーブル3100に含まれるエントリ・ポイント3102の総数とを含む。エントリ・ポイント3102は、PTS3103とソースパケット番号(SPN)3104との対を個別に異なるエントリ・ポイントID(EP_ID)3105に対応付ける。さらに、エントリ・ポイント3102は、この特徴点へのアングル切り替えが可能であるか否かを示すフラグ(is_angle_changeフラグ)を具備している。マルチアングル区間を構成するインターリーブユニットの先頭に位置するソースパケットは、アングル切り替えが可能になっているため、インターリーブユニットの先頭ソースパケットを差すエントリーポイントのis_angle_changeフラグは、必ずオンに設定される。また、インターリーブユニットの先頭ソースパケットを差すエントリーポイントは、エントリーポイントによって、プレイアイテム情報におけるIn_Timeと対応付けられている。PTS3103は、エントリ・マップ・ヘッダ3101の示すPIDのビデオ・ストリームに含まれるいずれかのIピクチャのPTSに等しい。SPN3104は、そのIピクチャが格納されたソースパケット群の先頭のSPNに等しい。「SPN」とは、一つのAVストリーム・ファイルに属するソースパケット群に、先頭から順に割り当てられた通し番号をいう。SPNはそのAVストリーム・ファイル内での各ソースパケットのアドレスとして利用される。2Dクリップ情報ファイル531内のエントリ・マップ3030では、SPNは、ファイル2D541に属するソースパケット群、すなわちメインTSを構成するソースパケット群に割り当てられた番号を意味する。従って、エントリ・ポイント3102は、ファイル2D541に含まれるIピクチャのPTSとアドレス、すなわちSPNとの間の対応関係を表す。
エントリ・ポイント3102は、ファイル2D541内の全てのIピクチャに対して設定されていなくてもよい。但し、IピクチャがGOPの先頭に位置し、かつ、そのIピクチャの先頭を含むTSパケットが2Dエクステントの先頭に位置するときは、そのIピクチャにはエントリ・ポイント3102を設定しなければならない。
図38の(b)は、ファイル2D541に属するソースパケット群3110のうち、エントリ・マップ3030によって各EP_ID3105に対応付けられているものを示す模式図である。図38の(c)は、そのソースパケット群3110と記録媒体100上のデータ・ブロック群3120との間の対応関係を示す模式図である。再生装置200はファイル2D541から2D映像を再生するとき、エントリ・マップ3030を利用して、任意のシーンを表すフレームのPTSから、そのフレームを含むソースパケットのSPNを特定する。具体的には、再生装置200は、再生開始位置として特定のエントリ・ポイントのPTS、例えばPTS=360000が指定されたとき、まずエントリ・マップ3030から、そのPTSに対応付けられたSPN=3200を検索する。再生装置200は次に、そのSPNとソースパケット一つ当たりのデータ量192バイトとの積をセクタ一つ当たりのデータ量2048バイトで割ったときの商SPN/192×2048を求める。その値は、メインTSのうち、そのSPNが割り当てられたソースパケットを含むアラインド・ユニットよりも前の部分が記録されたセクタの総数に等しい。図38の(b)に示されている例では、その値3200×192/2048=300は、SPNが0から3199までのソースパケット群3111が記録されたセクタの総数に等しい。再生装置200は続いてファイル2D541のファイル・エントリ内のアロケーション記述子を参照し、2Dエクステント群が記録されたセクタ群の先頭から数えて(上記の総数+1)番目のセクタのLBNを特定する。図38の(c)に示されている例では、2DエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、…としてアクセス可能なベースビュー・データ・ブロックL1、L2+L32D、L4、…が記録されたセクタ群のうち、先頭から数えて301番目のセクタのLBNが特定される。再生装置200はそのLBNをBD−ROMドライブに指定する。それにより、そのLBNのセクタから順にベースビュー・データ・ブロック群がアラインド・ユニット単位で読み出される。再生装置200は更に、最初に読み出されたアラインド・ユニットから、再生開始位置のエントリ・ポイントの示すソースパケットを選択してIピクチャに復号する。それ以降、後続のピクチャは、先に復号されたピクチャを利用して順次復号される。こうして、再生装置200はファイル2D541から特定のPTS以降の2D映像を再生できる。
エントリ・マップ3030は更に、早送り再生及び巻戻し再生等の特殊再生の効率的な処理に有利である。例えば2D再生モードの再生装置200は、まずエントリ・マップ3030を参照して、再生開始位置、例えばPTS=360000以降のPTSを含むエントリ・ポイント、EP_ID=2、3、…からSPN=3200、4800、…を順番に読み出す。再生装置200は次にファイル2D541のファイル・エントリを利用して、各SPNに対応するセクタのLBNを特定する。再生装置200は続いて、各LBNをBD−ROMドライブに指定する。それにより、各LBNのセクタからアラインド・ユニットが読み出される。再生装置200は更に各アラインド・ユニットから、各エントリ・ポイントの示すソースパケットを選択してIピクチャに復号する。こうして、再生装置200は2Dエクステント群EXT2D[n]自体を解析することなく、ファイル2D541からIピクチャを選択的に再生できる。
[オフセット・テーブル]
図39の(a)はオフセット・テーブル3041のデータ構造を示す模式図である。オフセット・テーブル3041は、3D再生モードの再生装置200によるクロッピング処理に利用される情報である。「クロッピング処理」とは、2D映像を表すデータから、レフトビューとライトビューとを表すプレーン・データの対を生成する処理をいう。「プレーン・データ」とは画素データの二次元配列を意味し、その配列のサイズは映像フレームの解像度に等しい。一組の画素データは色座標値とα値(不透明度)との組み合わせから成る。色座標値はRGB値又はYCrCb値で表される。クロッピング処理の対象には、メインTS内のPGストリーム、IGストリーム、及びセカンダリ・ビデオ・ストリームのそれぞれから生成されるプレーン・データ、並びに、BD−Jオブジェクトに従って生成されるイメージ・プレーン・データが含まれる。クロッピング処理はプレーン・データ内での各画素データの位置を水平方向に変化させる。従って、クロッピング処理によって得られるプレーン・データの対ではレフトビューとライトビューとの各表示位置が元の2D映像の表示位置から左右にずれている。それらの変位が視聴者に両眼視差として知覚されることにより、レフトビューとライトビューとの対がその視聴者には一つの3D映像として見える。
図39の(a)を参照するに、オフセット・テーブル3041は、PGストリーム、IGストリーム、及びセカンダリ・ビデオ・ストリームのPID別にテーブル3210を含む。各テーブル3210はPTS3201とオフセット値3202との対応表である。PTS3201は、PGストリーム、IGストリーム、及びセカンダリ・ビデオ・ストリームから生成される各プレーン・データの表示時刻を表す。オフセット値3202は、クロッピング処理による各画素データの水平方向の変位量を符号付きの画素数で表したものである。例えばプラス符号は右向きの変位を表し、マイナス符号はその逆である。オフセット値3202の符号は、3D映像の奥行きが画面よりも手前か奥かに依って決められている。以下、PTS3201とオフセット値3202との対3203を「オフセット・エントリ」という。
図39の(b)は、オフセット・エントリの有効区間を表す模式図である。各オフセット・エントリの有効区間は、STCで計られる時間において、そのオフセット・エントリのPTSの示す時刻から、次のオフセット・エントリのPTSの示す時刻までの期間である。プレーン・データのPTSがあるオフセット・エントリの有効区間に属するとき、クロッピング処理では、そのプレーン・データ内の画素データの表示位置が、そのオフセット・エントリのオフセット値だけ変化する。図39の(a)に示されている例では、オフセット・エントリ#1のPTSが180000であり、オフセット・エントリ#2のPTSが270000であり、オフセット・エントリ#3のPTSが360000である。その場合、図39の(b)に示されているように、オフセット・エントリ#1のオフセット値“+5”は、180000から270000までのSTCの範囲3204で有効であり、オフセット・エントリ#2のオフセット値“+3”は、270000から360000までのSTCの範囲3205で有効である。
[エクステント起点]
図40の(a)は、2Dクリップ情報ファイルに含まれるエクステント起点3042のデータ構造を示す模式図である。図40の(a)を参照するに、「エクステント起点(Extent_Start_Point)」3042は、ベースビュー・エクステントID(EXT1_ID)3311とSPN3312とを含む。EXT1_ID3311は、第1ファイルSS(01000.ssif)544Aに属する各ベースビュー・データ・ブロックに、先頭から順に割り当てられた通し番号である。SPN3312は各EXT1_ID3311に一つずつ割り当てられ、そのEXT1_ID3311で識別されるベースビュー・データ・ブロックの先端に位置するソースパケットのSPNに等しい。ここで、そのSPNは、第1ファイルSS544Aに属するベースビュー・データ・ブロック群に含まれる各ソースパケットに、先頭から順に割り当てられた通し番号である。
図15に示されているインターリーブ配置のデータ・ブロック群ではベースビュー・データ・ブロックはファイル2Dと、これに対応するファイルSSとに共有される。しかし、図20、24、26、28、30、32に示されてる配置1−5では、2D再生専用ブロックはファイル2Dにのみ属し、3D再生専用ブロックはファイルSSにのみ属する。従って、エクステント起点3042の示すSPN3312は、ファイル2Dに属する2Dエクステントの先端に位置するソースパケットのSPNとは一般に異なる。
図40の(b)は、ライトビュー・クリップ情報ファイルに含まれるエクステント起点3320のデータ構造を示す模式図である。図40の(b)を参照するに、エクステント起点3320は、ライトビュー・エクステントID(EXT2_ID)3321とSPN3322とを含む。EXT2_ID3321は、第1ファイルSS544Aに属する各ライトビュー・データ・ブロックに、先頭から順に割り当てられた通し番号である。SPN3322は各EXT2_ID3321に一つずつ割り当てられ、そのEXT2_ID3321で識別されるライトビュー・データ・ブロックの先端に位置するソースパケットのSPNに等しい。ここで、そのSPNは、第1ファイルSS544Aに属するライトビュー・データ・ブロック群に含まれる各ソースパケットに、先頭から順に割り当てられた通し番号である。
図40の(d)は、第1ファイルDEP(02000.m2ts)に属するライトビュー・エクステントEXT2[0]、EXT2[1]、…と、エクステント起点3320の示すSPN3322との間の対応関係を表す模式図である。図15、20、24、26、28、30、32のいずれに示されているデータ構造でも、ライトビュー・データ・ブロックは第1ファイルDEPと第1ファイルSSとに共有される。従って、図40の(d)に示されているように、エクステント起点3320の示す各SPN3322は、各ライトビュー・エクステントEXT2[0]、EXT2[1]、…の先端に位置するソースパケットのSPNに等しい。
2Dクリップ情報ファイルのエクステント起点3042とライトビュー・クリップ情報ファイルのエクステント起点3320とは、以下に説明するように、第1ファイルSS544Aから3D映像が再生されるとき、各3Dエクステントに含まれるデータ・ブロックの境界の検出に利用される。
図40の(e)は、第1ファイルSS544Aに属する3DエクステントEXTSS[0]、EXTSS[1]、…と記録媒体100上のデータ・ブロック群3350との間の対応関係の一例を示す模式図である。図40の(e)を参照するに、データ・ブロック群3350は、図26に示されている配置3と同様である。尚、以下の説明は、インターリーブ配置、及び配置1−5の何れのデータ構造でも同様に成立する。データ・ブロック群3350では、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3SS、R4+L4がそれぞれ、3DエクステントEXTSS[0]、EXTSS[1]、EXTSS[2]、EXTSS[3]としてアクセス可能である。更に、n番目の3DエクステントEXTSS[n](n=0、1、2、…)では、ベースビュー・データ・ブロックL(n+1)に含まれるソースパケットの数は、エクステント起点3042において、EXT1_ID=n+1、nのそれぞれに対応するSPN間の差A(n+1)−Anに等しい(ここで、A0=0)。一方、ライトビュー・データ・ブロックR(n+1)に含まれるソースパケットの数は、エクステント起点3320において、EXT2_ID=n+1、nのそれぞれに対応するSPN間の差B(n+1)−Bnに等しい(ここで、B0=0)。
L/Rモードの再生装置200は第1ファイルSS544Aから3D映像を再生するとき、各クリップ情報ファイルのエントリ・マップに加え、エクステント起点3042、3320を利用して、任意のシーンのライトビューを表すフレームのPTSから、そのフレームを含むライトビュー・データ・ブロックが記録されたセクタのLBNを特定する。具体的には、再生装置200はまず、例えばライトビュー・クリップ情報ファイル532のエントリ・マップから、そのPTSに対応付けられたSPNを検索する。仮に、そのSPNの示すソースパケットが第1ファイルDEPの3番目のライトビュー・エクステントEXT2[2]、すなわちライトビュー・データ・ブロックR3に含まれる場合を想定する。再生装置200は次に、ライトビュー・クリップ情報ファイルのエクステント起点3320の示すSPN3322の中から、目標のSPN以下で最大のもの“B2”と、それに対応するEXT2_ID“2”とを検索する。再生装置200は続いて、2Dクリップ情報ファイルのエクステント起点3042から、そのEXT2_ID“2”と等しいEXT1_IDに対応するSPN3312の値“A2”を検索する。再生装置200は更に、検索されたSPN3024、3320の値の和B2+A2を求める。図40の(e)から理解されるように、その和B2+A2は、3Dエクステント群EXTSS[0]、EXTSS[1]、…に含まれるデータ・ブロックのうち、3番目のライトビュー・データ・ブロックR3よりも前に配置されたものに含まれるソースパケットの総数に等しい。従って、その和B2+A2とソースパケット一つ当たりのデータ量192バイトとの積をセクタ一つ当たりのデータ量2048バイトで割ったときの商(B2+A2)×192/2048は、3Dエクステント群の先頭から3番目のライトビュー・データ・ブロックR3の直前までのセクタ数に等しい。この商を利用して第1ファイルSS544Aのファイル・エントリ内のアロケーション記述子を辿れば、そのライトビュー・データ・ブロックR3の先端が記録されたセクタのLBNを特定することができる。
再生装置200は、上記のようにLBNを特定した後、そのLBNをBD−ROMドライブに指定する。それにより、そのLBNのセクタ以降に記録された3Dエクステント群、すなわち3番目のライトビュー・データ・ブロックR3以降の3Dエクステント群がアラインド・ユニット単位で読み出される。
再生装置200は更にエクステント起点3042、3320を利用して、読み出された各3Dエクステントから、ディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとを交互に抽出する。例えば、図40の(e)に示されているデータ・ブロック群3350から3Dエクステント群EXTSS[n](n=0、1、2、…)が順番に読み出されるときを想定する。再生装置200はまず、最初の3DエクステントEXTSS[0]の先頭からB1個のソースパケットを最初のディペンデントビュー・データ・ブロックR1として抽出する。再生装置200は次に、B1番目のソースパケットと、それに続く(A1−1)個のソースパケットとの計A1個のソースパケットを最初のベースビュー・データ・ブロックL1として抽出する。再生装置200は続いて、(B1+A1)番目のソースパケットと、それに続く(B2−B1−1)個のソースパケットとの計(B2−B1)個のソースパケットを二番目のディペンデントビュー・データ・ブロックR2として抽出する。再生装置200は更に、(A1+B2)番目のソースパケットと、それに続く(A2−A1−1)個のソースパケットとの計(A2−A1)個のソースパケットを二番目のベースビュー・データ・ブロックL2として抽出する。それ以降も再生装置200は同様に、読み出されるソースパケットの数から各3Dエクステント内のデータ・ブロック間の境界を検出して、ディペンデントビューとベースビューとの各データ・ブロックを交互に抽出する。抽出されたベースビュー・データ・ブロックとライトビュー・データ・ブロックとはパラレルにシステム・ターゲット・デコーダに渡されて復号される。
こうして、L/Rモードの再生装置200は第1ファイルSS544Aから特定のPTS以降の3D映像を再生できる。その結果、再生装置200は、BD−ROMドライブの制御に関する上記の利点(A)、(B)を実際に享受できる。
≪ファイル・ベース≫
図40の(c)は、L/Rモードの再生装置200によって第1ファイルSS544Aから抽出されたベースビュー・データ・ブロックL1、L2、…を表す模式図である。図40の(e)に示されているデータ・ブロック群3350は2D再生専用ブロックL32Dと3D再生専用ブロックL3SSとの両方を含む。しかし、図40の(c)に示されているベースビュー・データ・ブロック群は、ファイル2Dの2Dエクステント群とは異なり、2D再生専用ブロックL32Dに代えて3D再生専用ブロックL3SSを含む。従って、エクステント起点3042の示すSPN3312は、各ベースビュー・データ・ブロックの先端に位置するソースパケットのSPNに等しい。図40の(c)に示されているベースビュー・データ・ブロック群のように、エクステント起点を利用して一つのファイルSSから抽出されるベースビュー・データ・ブロック群を「ファイル・ベース」という。更に、ファイル・ベースに含まれるベースビュー・データ・ブロックを「ベースビュー・エクステント」という。各ベースビュー・エクステントは、図40の(c)に示されているように、2Dクリップ情報ファイル内のエクステント起点によって参照される。
ベースビュー・エクステントは、2D再生専用ブロックと3D再生専用ブロックとを除き、2Dエクステントと実体、すなわちベースビュー・データ・ブロックを共有する。更に、互いに対応する2D再生専用ブロックと3D再生専用ブロックとはビット単位で一致する。従って、ファイル・ベースはファイル2Dと同じメインTSを含む。しかし、ベースビュー・エクステントは2Dエクステントとは異なり、いずれのファイルのファイル・エントリ内のアロケーション記述子によっても参照されない。上記のとおり、ベースビュー・エクステントは、クリップ情報ファイル内のエクステント起点を利用して、ファイルSS内の3Dエクステントから抽出される。このように、ファイル・ベースは、図7に示されている本来のファイルとは異なり、ファイル・エントリを含まず、かつ、ベースビュー・エクステントの参照にエクステント起点を必要とする。それらの意味で、ファイル・ベースは「仮想的なファイル」である。特にファイル・ベースはファイルシステムでは認識されず、図7に示されているディレクトリ/ファイル構造には現れない。
記録媒体100上に記録された3D映像コンテンツは、メインTSに対するサブTSを一種類だけ含むものでもよい。図41は、そのコンテンツを含むデータ・ブロック群の配置の一例を示す模式図である。図41を参照するに、データ・ブロック群3400は、ディペンデントビュー・データ・ブロックD[n](n=…、0、1、2、3、…)とベースビュー・データ・ブロックB[n]とを一種類ずつ含む。層境界LBの前にはディペンデントビュー・データ・ブロック群…、D[0]、D[1]とベースビュー・データ・ブロック群…、B[0]、B[1]とがインターリーブ配置で記録され、第1の3Dエクステント・ブロック3401を構成している。第1の3Dエクステント・ブロック3401の後端B[1]と層境界LBとの間には2D再生専用ブロックB[2]2Dが配置されている。一方、層境界LBの後にはディペンデントビュー・データ・ブロック群D[2]、D[3]、…とベースビュー・データ・ブロック群B[2]SS、B[3]、…とがインターリーブ配置で記録され、第2の3Dエクステント・ブロック3402を構成している。第2の3Dエクステント・ブロック3402内の先頭のベースビュー・データ・ブロックB[2]SSは3D再生専用ブロックであり、2D再生専用ブロックB[2]2Dとビット単位で一致する。
図41には、データ・ブロック群3400とファイル2D3410のエクステント群との間の対応関係も示されている。第1の3Dエクステント・ブロック3401内のベースビュー・データ・ブロック…、B[0]、B[1]は、最後のものB[1]を除き、単独で一つの2Dエクステント…、EXT2D[0]としてファイル2D3410に属する。第1の3Dエクステント・ブロック3401内の最後のベースビュー・データ・ブロックB[1]は、その直後の2D再生専用ブロックB[2]2Dとの対で一つの2DエクステントEXT2D[1]としてファイル2D3410に属する。第2の3Dエクステント・ブロック3402内のベースビュー・データ・ブロックB[3]、…は、3D再生専用ブロックB[2]SSを除き、2DエクステントEXT2D[2]、…としてファイル2D3410に属する。各2Dエクステントはファイル2D3410のファイル・エントリ内のアロケーション記述子を参照データとして利用することによってアクセス可能である。
図41には、データ・ブロック群3400とファイルDEP3412のエクステント群との間の対応関係も示されている。第1の3Dエクステント・ブロック3401内の各ディペンデントビュー・データ・ブロック…、D[0]、D[1]、及び第2の3Dエクステント・ブロック3402内の各ディペンデントビュー・データ・ブロックD[2]、D[3]、…はディペンデントビュー・エクステント…、EXT2[0]、EXT2[1]、EXT2[2]、…としてファイルDEP3412に属する。各ディペンデントビュー・エクステントはファイルDEP3412のファイル・エントリ内のアロケーション記述子を参照データとして利用することによってアクセス可能である。
図41には、データ・ブロック群3400とファイルSS3420のエクステント群との間の対応関係も示されている。データ・ブロック群3400は、図15に示されているものとは異なり、デプスマップ・データ・ブロックを含まない。従って、いずれの3Dエクステント・ブロック3401、3402内のインターリーブ配置でも、ディペンデントビュー・データ・ブロック…、D[0]、D[1]、D[2]、D[3]、…とベースビュー・データ・ブロック…、B[0]、B[1]、B[2]SS、B[3]、…とは交互に連続している。その場合、ファイルSS3420は、エクステントATC時間の等しいディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対が二つ以上連続する部分を一つの3Dエクステントとして含んでもよい。図41では、第1の3Dエクステント・ブロック3401内の二つの連続するディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対D[0]+B[0]、D[1]+B[1]が、一つの3DエクステントEXTSS[0]としてファイルSS3420に属する。更に、第2の3Dエクステント・ブロック3402内の二つの連続するディペンデントビュー・データ・ブロックとベースビュー・データ・ブロックとの対D[2]+B[2]SS、D[3]+B[3]が、一つの3DエクステントEXTSS[1]としてファイルSS3420に属する。3DエクステントEXTSS[0]、EXTSS[1]は、2DエクステントEXT2D[0]、EXT2D[1]、EXT2D[2]、EXT2D[3]とはベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]を共有し、ディペンデントビュー・エクステントEXT2[0]、EXT2[1]、EXT2[2]、EXT2[3]とはディペンデントビュー・データ・ブロックD[0]、D[1]、D[2]、D[3]を共有する。各3DエクステントはファイルSS3420のファイル・エントリ内のアロケーション記述子を参照データとして利用してアクセス可能である。
再生装置200は3DエクステントEXTSS[0]、EXTSS[1]を読み込んだ後、ファイル2D3410とファイルDEP3412とのそれぞれに対応するクリップ情報ファイル内のエクステント起点を利用して、各3DエクステントEXTSS[0]、EXTSS[1]からベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]を抽出する。それらのベースビュー・データ・ブロックB[0]、B[1]、B[2]SS、B[3]はベースビュー・エクステントEXT1[0]、EXT1[1]、EXT1[2]、EXT1[3]としてファイル・ベース3411に属する。各ベースビュー・エクステントEXT1[0]、EXT1[1]、EXT1[2]、EXT1[3]は、ファイル2D3410に対応する2Dクリップ情報ファイル内のエクステント起点によって参照される。
以下、特に区別する必要がない限り、ベースビュー・データ・ブロックは(2D再生専用ブロックを除いて)ベースビュー・エクステントと同一視し、ディペンデントビュー・データ・ブロックはディペンデントビュー・エクステントと同一視する。
≪ディペンデントビュー・クリップ情報ファイル≫
ディペンデントビュー・クリップ情報ファイルは、図37−図40に示されている2Dクリップ情報ファイルとデータ構造が同様である。従って、以下の説明では、ディペンデントビュー・クリップ情報ファイルと2Dクリップ情報ファイルとの間の相違点に触れ、同様な点については上記の説明を援用する。
ディペンデントビュー・クリップ情報ファイルは2Dクリップ情報ファイルとは次の三点(i)、(ii)、(iii)で異なる:(i)ストリーム属性情報に条件が課せられている;(ii)エントリ・ポイントに条件が課せられている;(iii)3Dメタデータがオフセット・テーブルを含まない。
(i)ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとがL/Rモードの再生装置200によって3D映像の再生に利用されるべきものであるとき、ライトビュービデオストリームであるディペンデントビュー・ビデオ・ストリームはベースビュー・ビデオ・ストリームを利用して圧縮されている。そのとき、ディペンデントビュー・ビデオ・ストリームはベースビュー・ビデオ・ストリームとビデオ・ストリーム属性が等しく揃えられる。ここで、ベースビュー・ビデオ・ストリームに関するビデオ・ストリーム属性情報は、2Dクリップ情報ファイルのストリーム属性情報3020内でPID=0x1011に対応付けられている。ディペンデントビュー・ビデオ・ストリームに関するビデオ・ストリーム属性情報は、ディペンデントビュー・クリップ情報ファイルのストリーム属性情報内でPID=0x1012又は0x1013に対応付けられている。従って、それらのビデオ・ストリーム属性情報間では、図37に示されている各項目、すなわち、コーデック、解像度、アスペクト比、及びフレームレートが一致しなければならない。コーデックの種類が一致していれば、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとのピクチャ間に符号化での参照関係が成立するので、各ピクチャを復号することができる。解像度、アスペクト比、及びフレームレートがいずれも一致していれば、左右の映像の画面表示を同期させることができる。それ故、それらの映像を3D映像として視聴者に違和感を与えることなく見せることができる。
(ii)ディペンデントビュー・クリップ情報ファイルのエントリ・マップは、ディペンデントビュー・ビデオ・ストリームに割り当てられたテーブルを含む。そのテーブルは、図38の(a)に示されているもの3100と同様に、エントリ・マップ・ヘッダとエントリ・ポイントとを含む。エントリ・マップ・ヘッダは、対応するディペンデントビュー・ビデオ・ストリームのPID、すなわち0x1012又は0x1013を示す。各エントリ・ポイントは一対のPTSとSPNとを一つのEP_IDに対応付けている。各エントリ・ポイントのPTSは、ディペンデントビュー・ビデオ・ストリームに含まれるいずれかのGOPの先頭のピクチャのPTSと等しい。各エントリ・ポイントのSPNは、同じエントリ・ポイントに属するPTSの示すピクチャが格納されたソースパケット群の先頭のSPNに等しい。ここで、SPNは、ファイルDEPに属するソースパケット群、すなわちサブTSを構成するソースパケット群に先頭から順に割り当てられた通し番号を意味する。各エントリ・ポイントのPTSは、2Dクリップ情報ファイルのエントリ・マップのうち、ベースビュー・ビデオ・ストリームに割り当てられたテーブル内のエントリ・ポイントのPTSと一致しなければならない。すなわち、同じ3D・VAUに含まれる一対のピクチャの一方を含むソースパケット群の先頭にエントリ・ポイントが設定されているときは、常に、他方を含むソースパケット群の先頭にもエントリ・ポイントが設定されていなければならない。
図42は、ベースビュー・ビデオ・ストリーム3510とディペンデントビュー・ビデオ・ストリーム3520とに設定されたエントリ・ポイントの例を示す模式図である。各ビデオ・ストリーム3510、3520では、先頭から数えて同じ順番のGOPが同じ再生期間の映像を表す。図42を参照するに、ベースビュー・ビデオ・ストリーム3510では、先頭から数えて奇数番目に位置するGOP#1、GOP#3、GOP#5の各先頭にエントリ・ポイント3501B、3503B、3505Bが設定されている。それに併せて、ディペンデントビュー・ビデオ・ストリーム3520でも、先頭から数えて奇数番目に位置するGOP#1、GOP#3、GOP#5の各先頭にエントリ・ポイント3501D、3503D、3505Dが設定されている。その場合、再生装置200は、例えばGOP#3から3D映像の再生を開始するとき、対応するエントリ・ポイント3503B、3503DのSPNからファイルSS内の再生開始位置のアドレスを直ちに算定できる。特にエントリ・ポイント3503B、3503Dがいずれもデータ・ブロックの先端に設定されているとき、図40の(e)から理解されるとおり、エントリ・ポイント3503B、3503DのSPNの和が、ファイルSSの先頭から再生開始位置までの部分に含まれるソースパケットの数に等しい。図40の(e)の説明で述べたとおり、そのソースパケットの数からは、ファイルSS内の再生開始位置の部分が記録されたセクタのLBNを算定することができる。こうして、3D映像の再生においても、飛び込み再生等、ビデオ・ストリームのランダムアクセスを要する処理の応答速度を向上させることができる。
BD−ROMドライブが読み出したストリームファイルのソースパケットから、ベースビューを構成するATCシーケンスとディペンデントビューストリームを構成するATCシーケンスとをエクステント起点を利用して分離する手順について説明する。図43は、ATCシーケンス復元手順を示す。
ステップS91は、ベースビュー用のATCシーケンスをATCシーケンス1とし、ディペンデントビュー用のATCシーケンスをATCシーケンス2とする。ステップS92では、変数xを1に初期化する。この変数xは、
エクステント起点により示されるベースビュー・エクステントID(EXT1_ID)ライトビュー・エクステントID(EXT2_ID)のインデックス番号を指示する。以降、ステップS94〜ステップS96のループを繰り返す。
変数xによって指示されるソースパケット番号bxが、ベースビューデータブロックの最後の数値nによって指示されるソースパケット番号bnであるか否かを判定し(ステップS93)、もしそうでなければ、ソースパケット番号bx+axによって指示されるソースパケット(bx+ax)から、bx+1+axによって指示されるソースパケット(bx+1+ax)の直前のパケットまでをATCシーケンス2に追加し(ステップS94)、ソースパケット(bx+1+ax)からソースパケット(bx+1+ax+1)の直前のパケットまでをATCシーケンス1に追加して(ステップS95)、変数xをインクリメントする(ステップS96)という処理を、ステップS93がYesと判定されるまで繰り返す。
ステップS93がYesと判定されれば、ソースパケット番号bnから(number_of_source_packet2-bn)個のソースパケットをATCシーケンス2に追加し(ステップS97)、ソースパケット番号anから(number_of_source_packet1-an)個のソースパケットをATCシーケンス1に追加する(ステップS98)。
以上のように、ATCシーケンス1、2が復元されれば、ベースビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルベースを仮想的にオープンする(ステップS99)。同様に、ディペンデントビューデータブロックの先頭LBN及び連続長をセクタ数で示すファイルエントリーをメモリ上で生成して、ファイルディペンデントを仮想的にオープンする(ステップS100)。
<プレイリスト情報ファイル>
以下、プレイリスト情報ファイルの詳細について説明する。
≪2Dプレイリスト・ファイル≫
図44は、2Dプレイリスト・ファイルのデータ構造を示す模式図である。図44を参照するに、2Dプレイリスト・ファイル521はメインパス3601と二つのサブパス3602、3603とを含む。
メインパス3601はプレイアイテム情報(PI)の配列であり、ファイル2Dの主要な再生経路、すなわち再生対象の部分とその再生順とを規定する。各PIは固有のプレイアイテムID=#N(N=1、2、3、…)で識別される。各PI#Nは主要な再生経路の異なる再生区間を一対のPTSで規定する。その対の一方はその再生区間の開始時刻(In−Time)を表し、他方は終了時刻(Out−Time)を表す。更に、メインパス3601内でのPIの順序は、対応する再生区間の再生経路内での順序を表す。
各サブパス3602、3603はサブプレイアイテム情報(SUB_PI)の配列であり、ファイル2Dの主要な再生経路に並列に付随可能な再生経路を規定する。その再生経路は、メインパス3601の表すファイル2Dの部分とは別の部分、又は別のファイル2Dに多重化されたストリーム・データの部分とその再生順とを意味する。そのストリーム・データは、メインパス3601に従ってファイル2Dから再生される2D映像と同時に再生されるべき別の2D映像を表す。その別の2D映像は例えば、ピクチャ・イン・ピクチャ方式における副映像、ブラウザ画面、ポップアップ・メニュー、又は字幕を含む。サブパス3602、3603には2Dプレイリスト・ファイル521への登録順に通し番号「0」、「1」が振られている。その通し番号はサブパスIDとして各サブパス3602、3603の識別に利用される。各サブパス3602、3603では、各SUB_PIが固有のサブプレイアイテムID=#M(M=1、2、3、…)で識別される。各SUB_PI#Mは、再生経路の異なる再生区間を一対のPTSで規定する。その対の一方はその再生区間の再生開始時刻を表し、他方は再生終了時刻を表す。更に、各サブパス3602、3603内でのSUB_PIの順序は、対応する再生区間の再生経路内での順序を表す。
図45は、PI#Nのデータ構造を示す模式図である。図45を参照するに、PI#Nは、参照クリップ情報3701、再生開始時刻(In_Time)3702、再生終了時刻(Out_Time)3703、コネクション・コンディション3704、及びストリーム選択テーブル(以下、STN(Stream Number)テーブルと略す。)3705を含む。参照クリップ情報3701は、2Dクリップ情報ファイルを識別するための情報である。再生開始時刻3702と再生終了時刻3703とは、ファイル2D541の再生対象部分の先端と後端との各PTSを示す。コネクション・コンディション3704は、再生開始時刻3702と再生終了時刻3703とによって規定された再生区間での映像を、一つ前のPI#(N−1)によって規定された再生区間での映像に接続するときの条件を規定する。STNテーブル3705は、再生開始時刻3702から再生終了時刻3703までの間に再生装置200内のデコーダによってファイル2D541から選択可能なエレメンタリ・ストリームのリストを表す。
SUB_PIのデータ構造は、図45に示されているPIのデータ構造と、参照クリップ情報、再生開始時刻、及び再生終了時刻を含む点で共通する。特にSUB_PIの再生開始時刻と再生終了時刻とは、PIのそれらと同じ時間軸上の値で表される。SUB_PIは更に「SPコネクション・コンディション」というフィールドを含む。SPコネクション・コンディションはPIのコネクション・コンディションと同じ意味を持つ。
[コネクション・コンディション]
コネクション・コンディション3704の値には「1」、「5」、「6」の三種類がある。コネクション・コンディション3704が「1」であるとき、PI#Nによって規定されるファイル2Dの部分から再生される映像は、直前のPI#(N−1)によって規定されるファイル2Dの部分から再生される映像とは必ずしもシームレスに接続されなくてもよい。一方、コネクション・コンディション3704が「5」又は「6」であるとき、それら両方の映像が必ずシームレスに接続されなければならない。
図46の(a)、(b)はそれぞれ、コネクション・コンディション3704が「5」、「6」であるときに接続対象の二つの再生区間3801、3802の間の関係を示す模式図である。ここで、PI#(N−1)はファイル2Dの第1部分3801を規定し、PI#Nはファイル2Dの第2部分3802を規定する。図46の(a)を参照するに、コネクション・コンディション3704が「5」であるとき、2つのPI#(N−1)、PI#Nの間でSTCが途切れていても良い。すなわち、第1部分3801の後端のPTS#1と第2部分3802の先端のPTS#2とは不連続であってもよい。但し、いくつかの制約条件が満たされねばならない。例えば、第1部分3801に続けて第2部分3802をデコーダに供給したときでも、そのデコーダが復号処理をスムーズに持続できるように、各部分3801、3802が作成されていなければならない。更に、第1部分3801に含まれるオーディオ・ストリームの最後のフレームを、第2部分3802に含まれるオーディオ・ストリームの先頭フレームと重複させなければならない。一方、図46の(b)を参照するに、コネクション・コンディション3704が「6」であるとき、第1部分3801と第2部分3802とは、デコーダの復号処理上、一連の部分として扱えるものでなければならない。すなわち、第1部分3801と第2部分3802との間ではSTCとATCとがいずれも連続でなければならない。同様に、SPコネクション・コンディションが「5」又は「6」であるとき、隣接する2つのSUB_PIによって規定されるファイル2Dの部分間では、STCとATCとがいずれも連続でなければならない。
[STNテーブル]
図45を再び参照するに、STNテーブル3705はストリーム登録情報の配列である。「ストリーム登録情報」とは、再生開始時刻3702から再生終了時刻3703までの間にメインTSから再生対象として選択可能なエレメンタリ・ストリームを個別に示す情報である。ストリーム番号(STN)3706はストリーム登録情報に個別に割り当てられた通し番号であり、再生装置200によって各エレメンタリ・ストリームの識別に利用される。STN3706は更に、同じ種類のエレメンタリ・ストリームの間では選択の優先順位を表す。ストリーム登録情報はストリーム・エントリ3709とストリーム属性情報3710と含む。ストリーム・エントリ3709はストリーム・パス情報3707とストリーム識別情報3708とを含む。ストリーム・パス情報3707は、選択対象のエレメンタリ・ストリームが属するファイル2Dを示す情報である。例えばストリーム・パス情報3707が“メインパス”を示すとき、そのファイル2Dは、参照クリップ情報3701の示す2Dクリップ情報ファイルに対応するものである。一方、ストリーム・パス情報3707が“サブパスID=1”を示すとき、選択対象のエレメンタリ・ストリームが属するファイル2Dは、サブパスID=1のサブパスに含まれるSUB_PIの参照クリップ情報が示す2Dクリップ情報ファイルに対応するものである。そのSUB_PIの規定する再生開始時刻又は再生終了時刻のいずれかは、STNテーブル3705を含むPIの規定する再生開始時刻3702から再生終了時刻3703までの期間に含まれる。ストリーム識別情報3708は、ストリーム・パス情報3707によって特定されるファイル2Dに多重化されているエレメンタリ・ストリームのPIDを示す。このPIDの示すエレメンタリ・ストリームが再生開始時刻3702から再生終了時刻3703までの間に選択可能である。ストリーム属性情報3710は各エレメンタリ・ストリームの属性情報を表す。例えば、オーディオ・ストリーム、PGストリーム、及びIGストリームの各属性情報は言語の種類を示す。
[2Dプレイリスト・ファイルに従った2D映像の再生]
図47は、2Dプレイリスト・ファイル(00001.mpls)521の示すPTSと、ファイル2D(01000.m2ts)541から再生される部分との間の対応関係を示す模式図である。図47を参照するに、2Dプレイリスト・ファイル521のメインパス3601では、PI#1は、再生開始時刻IN1を示すPTS#1と、再生終了時刻OUT1を示すPTS#2とを規定する。PI#1の参照クリップ情報3701は2Dクリップ情報ファイル(01000.clpi)531を示す。再生装置200は2Dプレイリスト・ファイル521に従って2D映像を再生するとき、まずPI#1からPTS#1、#2を読み出す。再生装置200は次に、2Dクリップ情報ファイル531のエントリ・マップを参照して、PTS#1、#2に対応するファイル2D541内のSPN#1、#2を検索する。再生装置200は続いて、SPN#1、#2から、それぞれに対応するセクタ数を算定する。再生装置200は更にそれらのセクタ数とファイル2D541のファイル・エントリ内のアロケーション記述子とを利用して、再生対象の2Dエクステント群EXT2D[0]、…、EXT2D[n]が記録されたセクタ群P1の先端のLBN#1と後端のLBN#2とを特定する。セクタ数の算定とLBNの特定とは、図38の(b)、(c)を用いて説明したとおりである。再生装置200は最後に、LBN#1からLBN#2までの範囲をBD−ROMドライブに指定する。それにより、その範囲のセクタ群P1から、2Dエクステント群EXT2D[0]、…、EXT2D[n]に属するソースパケット群が読み出される。同様に、PI#2の示すPTS#3、#4の対は、まず2Dクリップ情報ファイル531のエントリ・マップを利用してSPN#3、#4の対に変換される。次にファイル2D541のファイル・エントリ内のアロケーション記述子を利用して、SPN#3、#4の対がLBN#3、#4の対に変換される。更に、LBN#3からLBN#4までの範囲のセクタ群P2から、2Dエクステント群に属するソースパケット群が読み出される。PI#3の示すPTS#5、#6の対からSPN#5、#6の対への変換、SPN#5、#6の対からLBN#5、#6の対への変換、及びLBN#5からLBN#6までの範囲のセクタ群P3からのソースパケット群の読み出しも同様である。こうして、再生装置200は2Dプレイリスト・ファイル521のメインパス3601に従ってファイル2D541から2D映像を再生できる。
2Dプレイリスト・ファイル521はエントリ・マーク3901を含んでもよい。エントリ・マーク3901は、メインパス3601のうち、実際に再生が開始されるべき時点を示す。例えば図47に示されているように、PI#1に対して複数のエントリ・マーク3901が設定されてもよい。エントリ・マーク3901は特に頭出し再生において、再生開始位置の検索に利用される。例えば2Dプレイリスト・ファイル521が映画タイトルの再生経路を規定するとき、エントリ・マーク3901は各チャプタの先頭に付与される。それにより、再生装置200はその映画タイトルをチャプタごとに再生できる。
≪3Dプレイリスト・ファイル≫
図48は、3Dプレイリスト・ファイル4000のデータ構造を示す模式図である。図48を参照するに、3Dプレイリスト・ファイル4000は、メインパス4001、サブパス4002、及び拡張データ4003を含む。
メインパス4001は、メインTSの再生経路を規定する。従って、メインパス4001は、図44に示されている2Dプレイリスト・ファイルのメインパス3601に等しい。2D再生モードの再生装置200は3Dプレイリスト・ファイル4000のメインパス4001に従ってファイル2Dから2D映像を再生できる。
サブパス4002は、サブTSの再生経路、すなわちレフトビュービデオストリームを含むファイルDEP又はデプスマップストリームを含むファイルDEPのいずれかの再生経路を規定する。サブパス4002のデータ構造は、図44に示されている2Dプレイリスト・ファイルのサブパス3602、3603のデータ構造と同様である。従って、その同様なデータ構造の詳細、特にSUB_PIのデータ構造の詳細についての説明は、図44を用いた説明を援用する。
サブパス4002のSUB_PI#N(N=1、2、3、…)はメインパス4001のPI#Nと一対一に対応する。更に、各SUB_PI#Nの規定する再生開始時刻と再生終了時刻とはそれぞれ、対応するPI#Nの規定する再生開始時刻と再生終了時刻とに等しい。サブパス4002はその上、サブパス・タイプ4021を含む。「サブパス・タイプ」は一般に、メインパスとサブパスとの間で再生処理が同期すべきか否かを示す。3Dプレイリスト・ファイル4000では特にサブパス・タイプ4021が3D再生モードの種類、すなわちサブパス4002に従って再生されるべきディペンデントビュー・ビデオ・ストリームの種類を示す。図48では、サブパス・タイプ4021は、その値が「3D・L/R」であるので、3D再生モードがL/Rモードであること、すなわちライトビュー・ビデオ・ストリームが再生対象であることを示す。一方、サブパス・タイプ4021は、その値が「3Dデプス」であるときは、3D再生モードがデプス・モードであること、すなわちデプスマップ・ストリームが再生対象であることを示す。3D再生モードの再生装置200は、サブパス・タイプ4021の値が「3D・L/R」又は「3Dデプス」であることを検出したとき、メインパス4001に従った再生処理とサブパス4002に従った再生処理とを同期させる。
拡張データ4003は、3D再生モードの再生装置200によってのみ解釈される部分であり、2D再生モードの再生装置200には無視される。拡張データ4003は特に、拡張ストリーム選択テーブル4030を含む。「拡張ストリーム選択テーブル(STN_table_SS)」(以下、STNテーブルSSと略す。)は、3D再生モードにおいて、メインパス4001内の各PIの示すSTNテーブルに追加されるべきストリーム登録情報の配列である。このストリーム登録情報は、サブTSから再生対象として選択可能なエレメンタリ・ストリームを示す。
図49は、STNテーブルSS4030のデータ構造を示す模式図である。図49を参照するに、STNテーブルSS4030はストリーム登録情報列4101、4102、4103、…を含む。ストリーム登録情報列4101、4102、4103、…はメインパス4001内のPI#1、#2、#3、…に個別に対応し、3D再生モードの再生装置200により、対応するPI内のSTNテーブルに含まれるストリーム登録情報列と組み合わされて利用される。各PIに対するストリーム登録情報列4101は、ポップアップ期間のオフセット(Fixed_offset_during_Popup)4111、ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112、PGストリームのストリーム登録情報列4113、及びIGストリームのストリーム登録情報列4114を含む。
ポップアップ期間のオフセット4111は、IGストリームからポップアップ・メニューが再生されるか否かを示す。3D再生モードの再生装置200はそのオフセット4111の値に依ってビデオ・プレーンとPGプレーンとの表示モード(presentation mode)を変える。ここで、ビデオ・プレーンの表示モードにはベースビュー(B)−ディペンデントビュー(D)表示モードとB−B表示モードとの二種類があり、PGプレーンとIGプレーンとの各表示モードには、2プレーン・モード、1プレーン+オフセット・モード、及び1プレーン+ゼロ・オフセット・モードとの三種類がある。例えばポップアップ期間のオフセット4111の値が“0”であるとき、IGストリームからはポップアップ・メニューが再生されない。そのとき、ビデオ・プレーンの表示モードとしてB−D表示モードが選択され、PGプレーンの表示モードとして2プレーン・モード又は1プレーン+オフセット・モードが選択される。一方、ポップアップ期間のオフセット4111の値が“1”であるとき、IGストリームからポップアップ・メニューが再生される。そのとき、ビデオ・プレーンの表示モードとしてB−B表示モードが選択され、PGプレーンの表示モードとして1プレーン+ゼロ・オフセット・モードが選択される。
「B−D表示モード」では再生装置200が、レフトビューとライトビューとのビデオ・ストリームから復号されたプレーン・データを交互に出力する。従って、テレビ300の画面には、ビデオ・プレーンの表すレフトビューとライトビューとのフレームが交互に表示されるので、視聴者にはそれらが3D映像として見える。「B−B表示モード」では再生装置200が、動作モードを3D再生モードに維持したまま(特にフレームレートを3D再生時の値、例えば48フレーム/秒に維持したまま)、ベースビュー・ビデオ・ストリームから復号されたプレーン・データのみをフレーム当たり二回ずつ出力する。従って、テレビ300の画面には、ビデオ・プレーンについてはレフトビューとライトビューとのいずれかのフレームしか表示されないので、視聴者にはそれらが2D映像としてしか見えない。
「2プレーン・モード」では、サブTSがレフトビューとライトビューとのグラフィックス・ストリームを両方含むとき、再生装置200が各グラフィックス・ストリームからレフトビューとライトビューとのグラフィックス・プレーン・データを復号して交互に出力する。「1プレーン+オフセット・モード」では、再生装置200がクロッピング処理により、メインTS内のグラフィックス・ストリームからレフトビューとライトビューとのプレーン・データの対を生成して交互に出力する。いずれのモードでも、テレビ300の画面にはレフトビューとライトビューとのPGプレーンが交互に表示されるので、視聴者にはそれらが3D映像として見える。「1プレーン+ゼロ・オフセット・モード」では、再生装置200が、動作モードを3D再生モードに維持したまま、クロッピング処理を一時的に停止させ、メインTS内のグラフィックス・ストリームから復号されたプレーン・データをフレーム当たり二回ずつ出力する。従って、テレビ300の画面には、レフトビューとライトビューとのいずれかのPGプレーンしか表示されないので、視聴者にはそれらが2D映像としてしか見えない。
3D再生モードの再生装置200は、PIごとにポップアップ期間のオフセット4111を参照して、IGストリームからポップアップ・メニューが再生されるときはB−B表示モードと1プレーン+ゼロ・オフセット・モードとを選択する。それにより、ポップアップ・メニューが表示される間、他の3D映像が一時的に2D映像に変更されるので、ポップアップ・メニューの視認性・操作性が向上する。
ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112、PGストリームのストリーム登録情報列4113、及びIGストリームのストリーム登録情報列4114はそれぞれ、サブTSから再生対象として選択可能なディペンデントビュー・ビデオ・ストリーム、PGストリーム、及びIGストリームを示すストリーム登録情報を含む。これらのストリーム登録情報列4112、4113、4114はそれぞれ、対応するPI内のSTNテーブルに含まれるストリーム登録情報列のうち、ベースビュー・ビデオ・ストリーム、PGストリーム、及びIGストリームを示すものと組み合わされて利用される。3D再生モードの再生装置200は、STNテーブル内のいずれかのストリーム登録情報を読み出すとき、そのストリーム登録情報に組み合わされたSTNテーブルSS内のストリーム登録情報列も自動的に読み出す。それにより、再生装置200は、2D再生モードを単に3D再生モードへ切り換えるとき、設定済みのSTN、及び言語等のストリーム属性を同一に維持できる。
図50の(a)は、ディペンデントビュー・ビデオ・ストリームのストリーム登録情報列4112のデータ構造を示す模式図である。図50の(a)を参照するに、このストリーム登録情報列4112は一般に複数のストリーム登録情報(SS_dependet_view_block)4201を含む。それらは、対応するPI内のストリーム登録情報のうち、ベースビュー・ビデオ・ストリームを示すものと同数である。各ストリーム登録情報4201は、STN4211、ストリーム・エントリ4212、及びストリーム属性情報4213を含む。STN4211はストリーム登録情報4201に個別に割り当てられた通し番号であり、対応するPI内の組み合わせ対象のストリーム登録情報のSTNと等しい。ストリーム・エントリ4212は、サブパスID参照情報(ref_to_Subpath_id)4221、ストリーム・ファイル参照情報(ref_to_subClip_entry_id)4222、及びPID(ref_to_stream_PID_subclip)4223を含む。サブパスID参照情報4221は、ディペンデントビュー・ビデオ・ストリームの再生経路を規定するサブパスのサブパスIDを示す。ストリーム・ファイル参照情報4222は、そのディペンデントビュー・ビデオ・ストリームが格納されたファイルDEPを識別するための情報である。PID4223は、そのディペンデントビュー・ビデオ・ストリームのPIDである。ストリーム属性情報4213はそのディペンデントビュー・ビデオ・ストリームの属性、例えばフレームレート、解像度、及びビデオフォーマットを含む。特にそれらは、対応するPI内の組み合わせ対象のストリーム登録情報の示すベースビュー・ビデオ・ストリームのものと共通である。
図50の(b)は、PGストリームのストリーム登録情報列4113のデータ構造を示す模式図である。図50の(b)を参照するに、このストリーム登録情報列4113は一般に複数のストリーム登録情報4231を含む。それらは、対応するPI内のストリーム登録情報のうち、PGストリームを示すものと同数である。各ストリーム登録情報4231は、STN4241、立体視フラグ(is_SS_PG)4242、ベースビュー・ストリーム・エントリ(stream_entry_for_base_view)4243、ディペンデントビュー・ストリーム・エントリ(stream_entry_for_depentdent_view)4244、及びストリーム属性情報4245を含む。STN4241はストリーム登録情報4231に個別に割り当てられた通し番号であり、対応するPI内の組み合わせ対象のストリーム登録情報のSTNと等しい。立体視フラグ4242は、記録媒体100にベースビューとディペンデントビュー、例えばレフトビューとライトビューとのPGストリームが両方含まれているか否かを示す。立体視フラグ4242がオンであるとき、サブTSに両方のPGストリームが含まれている。従って、ベースビュー・ストリーム・エントリ4243、ディペンデントビュー・ストリーム・エントリ4244、及びストリーム属性情報4245のいずれのフィールドも再生装置によって読み出される。立体視フラグ4242がオフであるとき、それらのフィールド4243−4245はいずれも再生装置に無視される。ベースビュー・ストリーム・エントリ4243とディペンデントビュー・ストリーム・エントリ4244とはいずれも、サブパスID参照情報、ストリーム・ファイル参照情報、及びPIDを含む。サブパスID参照情報は、ベースビューとディペンデントビューとの各PGストリームの再生経路を規定するサブパスのサブパスIDを示す。ストリーム・ファイル参照情報は、各PGストリームが格納されたファイルDEPを識別するための情報である。PIDは各PGストリームのPIDである。ストリーム属性情報4245は各PGストリームの属性、例えば言語の種類を含む。
図50の(c)は、IGストリームのストリーム登録情報列4114のデータ構造を示す模式図である。図50の(c)を参照するに、このストリーム登録情報列4114は一般に複数のストリーム登録情報4251を含む。それらは、対応するPI内のストリーム登録情報のうち、IGストリームを示すものと同数である。各ストリーム登録情報4251は、STN4261、立体視フラグ(is_SS_IG)4262、ベースビュー・ストリーム・エントリ4263、ディペンデントビュー・ストリーム・エントリ4264、及びストリーム属性情報4265を含む。STN4261はストリーム登録情報4251に個別に割り当てられた通し番号であり、対応するPI内の組み合わせ対象のストリーム登録情報のSTNと等しい。立体視フラグ4262は、記録媒体100にベースビューとディペンデントビュー、例えばレフトビューとライトビューとのIGストリームが両方含まれているか否かを示す。立体視フラグ4262がオンであるとき、サブTSに両方のIGストリームが含まれている。従って、ベースビュー・ストリーム・エントリ4263、ディペンデントビュー・ストリーム・エントリ4264、及びストリーム属性情報4265のいずれのフィールドも再生装置によって読み出される。立体視フラグ4262がオフであるとき、それらのフィールド4263−4265はいずれも再生装置に無視される。ベースビュー・ストリーム・エントリ4263とディペンデントビュー・ストリーム・エントリ4264とはいずれも、サブパスID参照情報、ストリーム・ファイル参照情報、及びPIDを含む。サブパスID参照情報は、ベースビューとディペンデントビューとの各IGストリームの再生経路を規定するサブパスのサブパスIDを示す。ストリーム・ファイル参照情報は、各IGストリームが格納されたファイルDEPを識別するための情報である。PIDは各IGストリームのPIDである。ストリーム属性情報4265は各IGストリームの属性、例えば言語の種類を含む。
[3Dプレイリスト・ファイルに従った3D映像の再生]
図51は、3Dプレイリスト・ファイル(00002.mpls)522の示すPTSと、ファイルSS(01000.ssif)544Aから再生される部分との間の対応関係を示す模式図である。図51を参照するに、3Dプレイリスト・ファイル522のメインパス4301では、PI#1は、再生開始時刻IN1を示すPTS#1と、再生終了時刻OUT1を示すPTS#2とを規定する。PI#1の参照クリップ情報は2Dクリップ情報ファイル(01000.clpi)531を示す。一方、サブパス・タイプが「3D・L/R」を示すサブパス4302では、SUB_PI#1が、PI#1と同じPTS#1、#2を規定する。SUB_PI#1の参照クリップ情報はライトビュー・クリップ情報ファイル(02000.clpi)532を示す。
再生装置200は3Dプレイリスト・ファイル522に従って3D映像を再生するとき、まずPI#1とSUB_PI#1とからPTS#1、#2を読み出す。再生装置200は次に2Dクリップ情報ファイル531のエントリ・マップを参照し、PTS#1、#2に対応するファイル2D内のSPN#1、#2を検索する。それと並行して、再生装置200はライトビュー・クリップ情報ファイル532のエントリ・マップを参照し、PTS#1、#2に対応するファイルDEP内のSPN#11、#12を検索する。再生装置200は続いて、図40の(e)の説明で述べたように各クリップ情報ファイル531、532のエクステント起点3042、3320を利用して、SPN#1、#11から、ファイルSS544Aの先頭から再生開始位置までのソースパケット数SPN#21を算定する。再生装置200は同様に、SPN#2、#12から、ファイルSS544Aの先頭から再生終了位置までのソースパケット数SPN#22を算定する。再生装置200は更にSPN#21、#22のそれぞれに対応するセクタ数を算定する。再生装置200は続いて、それらのセクタ数とファイルSS544Aのファイル・エントリ内のアロケーション記述子とを利用して、再生対象の3Dエクステント群EXTSS[0]、…、EXTSS[n]が記録されたセクタ群P11の先端のLBN#1と後端のLBN#2とを特定する。セクタ数の算定とLBNの特定とは、図40の(e)の説明で述べたものと同様である。再生装置200は最後に、LBN#1からLBN#2までの範囲をBD−ROMドライブに指定する。それにより、その範囲のセクタ群P11から、3Dエクステント群EXTSS[0]、…、EXTSS[n]に属するソースパケット群が読み出される。同様に、PI#2とSUB_PI#2との示すPTS#3、#4の対は、まずクリップ情報ファイル531、532の各エントリ・マップを利用してSPN#3、#4の対とSPN#13、#14の対とに変換される。次に、SPN#3、#13からはファイルSS544Aの先頭から再生開始位置までのソースパケット数SPN#23が算定され、SPN#4、#14からはファイルSS544Aの先頭から再生終了位置までのソースパケット数SPN#24が算定される。続いて、ファイルSS544Aのファイル・エントリ内のアロケーション記述子を利用して、SPN#23、#24の対がLBN#3、#4の対に変換される。更に、LBN#3からLBN#4までの範囲のセクタ群P12から、3Dエクステント群に属するソースパケット群が読み出される。
上記の読み出し処理と並行して、再生装置200は、図40の(e)の説明で述べたように各クリップ情報ファイル531、532のエクステント起点3042、3320を利用して、各3Dエクステントからベースビュー・エクステントを抽出し、残りのライトビュー・エクステントとパラレルに復号する。こうして、再生装置200は、3Dプレイリスト・ファイル522に従って第1ファイルSS544Aから3D映像を再生できる。
以上がプレイリスト情報ファイルの詳細についての説明である。
≪インデックス・テーブル≫
図52は、インデックス・ファイル(index.bdmv)内のインデックス・テーブル4410を示す模式図である。図52を参照するに、インデックス・テーブル4410は、「ファーストプレイ」4401、「トップメニュー」4402、及び「タイトルk」44303(k=1、2、…、n:nは1以上の整数)という項目を含む。各項目にはムービーオブジェクトMVO−2D、MVO−3D、…、又はBD−JオブジェクトBDJO−2D、BDJO−3D、…のいずれかが対応付けられている。ユーザの操作又はアプリケーション・プログラムによってタイトル又はメニューが呼び出される度に、再生装置200の制御部はインデックス・テーブル4410の対応する項目を参照する。制御部は更に、その項目に対応付けられているオブジェクトを記録媒体100から呼び出し、それに従って様々な処理を実行する。具体的には、項目「ファーストプレイ」4401には、記録媒体100がBD−ROMドライブへ挿入された時に呼び出されるべきオブジェクトが指定されている。項目「トップメニュー」4402には、例えばユーザの操作で「メニューに戻れ」というコマンドが入力された時にテレビ300にメニューを表示させるためのオブジェクトが指定されている。項目「タイトルk」4403には、記録媒体100上のコンテンツを構成するタイトルが個別に割り当てられている。例えばユーザの操作によって再生対象のタイトルが指定されたとき、そのタイトルが割り当てられている項目「タイトルk」には、そのタイトルに対応するAVストリーム・ファイルから映像を再生するためのオブジェクトが指定されている。
図52に示されている例では、項目「タイトル1」と項目「タイトル2」とが2D映像のタイトルに割り当てられている。項目「タイトル1」に対応付けられているムービーオブジェクトMVO−2Dは、2Dプレイリスト・ファイル(00001.mpls)521を用いた2D映像の再生処理に関する命令群を含む。再生装置200によって項目「タイトル1」が参照されたとき、そのムービーオブジェクトMVO−2Dに従い、2Dプレイリスト・ファイル521が記録媒体100から読み出され、それに規定された再生経路に沿って2D映像の再生処理が実行される。項目「タイトル2」に対応付けられているBD−JオブジェクトBDJO−2Dは、2Dプレイリスト・ファイル521を用いた2D映像の再生処理に関するアプリケーション管理テーブルを含む。再生装置200によって項目「タイトル2」が参照されたとき、そのBD−JオブジェクトBDJO−2D内のアプリケーション管理テーブルに従ってJARファイルからJava(登録商標)アプリケーション・プログラムが呼び出されて実行される。それにより、2Dプレイリスト・ファイル521が記録媒体100から読み出され、それに規定された再生経路に沿って2D映像の再生処理が実行される。
図52に示されている例では更に、項目「タイトル3」と項目「タイトル4」とが3D映像のタイトルに割り当てられている。項目「タイトル3」に対応付けられているムービーオブジェクトMVO−3Dは、2Dプレイリスト・ファイル521を用いた2D映像の再生処理に関する命令群に加え、3Dプレイリスト・ファイル(00002.mpls)522、(00003.mpls)523のいずれかを用いた3D映像の再生処理に関する命令群を含む。項目「タイトル4」に対応付けられているBD−JオブジェクトBDJO−3Dでは、アプリケーション管理テーブルが、2Dプレイリスト・ファイル521を用いた2D映像の再生処理に関するJava(登録商標)アプリケーション・プログラムに加え、3Dプレイリスト・ファイル522、523のいずれかを用いた3D映像の再生処理に関するJava(登録商標)アプリケーション・プログラムを規定する。
再生装置200によって項目「タイトル3」が参照されたとき、ムービーオブジェクトMVO−3Dに従い、まず次の四種類の判別処理が行われる:(1)再生装置200自身が3D映像の再生に対応しているか否か、(2)ユーザが3D映像の再生を選択しているか否か、(3)テレビ300が3D映像の再生に対応しているか否か、及び(4)再生装置200の3D映像再生モードがL/Rモードとデプス・モードとのいずれであるか。次にそれらの判別結果に応じていずれかのプレイリスト・ファイル521−523が再生対象として選択される。再生装置200によって項目「タイトル4」が参照されたとき、BD−JオブジェクトBDJO−3D内のアプリケーション管理テーブルに従ってJARファイルからJava(登録商標)アプリケーション・プログラムが呼び出されて実行される。それにより、まず上記の判別処理が行われ、次にその判別結果に応じたプレイリスト・ファイルの選択が行われる。
[3D映像タイトルの選択時でのプレイリスト・ファイルの選択]
図53は、3D映像のタイトルが選択されたときに行われる、再生対象のプレイリスト・ファイルの選択処理のフローチャートである。図52に示されているインデックス・テーブル4410では、項目「タイトル3」が参照されたときはムービーオブジェクトMVO−3Dに従ってその選択処理が実行され、項目「タイトル4」が参照されたときは、BD−JオブジェクトBDJO−3Dに規定されたJava(登録商標)アプリケーション・プログラムに従ってその選択処理が実行される。
ここで、その選択処理の前提として、再生装置200が第1フラグと第2フラグとを含むときを想定する。第1フラグが“0”であるとき、再生装置200は2D映像の再生のみに対応可能であり、“1”であるとき、3D映像の再生にも対応可能である。第2フラグが“0”であるとき、再生装置200はL/Rモードであり、“1”であるとき、デプス・モードである。
ステップS4501では、再生装置200は第1フラグの値をチェックする。その値が0であるとき、処理はステップS4505へ進む。その値が1であるとき、処理はステップS4502へ進む。
ステップS4502では、再生装置200はテレビ300にメニューを表示させて、ユーザに2D映像と3D映像とのいずれかの再生を選択させる。ユーザがリモコン105等を操作して、2D映像の再生を選択したとき、処理はステップS4505へ進み、3D映像の再生を選択したとき、処理はステップS4503へ進む。
ステップS4503では、再生装置200は、テレビ300が3D映像の再生に対応しているかチェックする。具体的には、再生装置200はHDMIケーブルを通してテレビ300との間でCECメッセージを交換し、テレビ300が3D映像の再生に対応しているか否かをテレビ300に問い合わせる。テレビ300が3D映像の再生に対応しているとき、処理はステップS4504へ進む。テレビ300が3D映像の再生に対応していないとき、処理はステップS4505へ進む。
ステップS4504では、再生装置200は第2フラグの値をチェックする。その値が0であるとき、処理はステップS4506へ進む。その値が1であるとき、処理はステップS4507へ進む。
ステップS4505では、再生装置200は2Dプレイリスト・ファイル521を再生対象として選択する。尚、そのとき、再生装置200はテレビ300に、3D映像の再生が選択されなかった理由を表示させてもよい。
ステップS4506では、再生装置200はL/Rモード用の3Dプレイリスト・ファイル522を再生対象として選択する。
ステップS4507では、再生装置200はデプス・モード用の3Dプレイリスト・ファイル523を再生対象として選択する。
以上が本発明の実施形態1に係る記録媒体100についての説明である。
<2D再生装置の構成>
2D再生モードの再生装置200は記録媒体100から2D映像コンテンツを再生するとき、2D再生装置として動作する。図54は、2D再生装置4600の機能ブロック図である。図54を参照するに、2D再生装置4600は、BD−ROMドライブ4601、再生部4600A、及び制御部4600Bを含む。再生部4600Aは、リード・バッファ4602、システム・ターゲット・デコーダ4603、及びプレーン加算部4610を含む。制御部4600Bは、動的シナリオ・メモリ4604、静的シナリオ・メモリ4605、プログラム実行部4606、再生制御部4607、プレーヤ変数記憶部4608、及びユーザイベント処理部4609を含む。再生部4600Aと制御部4600Bとは互いに異なる集積回路に実装されている。その他に、両者が単一の集積回路に統合されていてもよい。
BD−ROMドライブ4601は、内部に記録媒体100が挿入されたとき、その記録媒体100にレーザ光を照射してその反射光の変化を検出する。更に、その反射光の光量の変化から、記録媒体100に記録されたデータを読み取る。具体的には、BD−ROMドライブ4601は光ピックアップ、すなわち光学ヘッドを備えている。その光学ヘッドは、半導体レーザ、コリメータ・レンズ、ビーム・スプリッタ、対物レンズ、集光レンズ、及び光検出器を含む。半導体レーザから出射された光ビームは、コリメータ・レンズ、ビーム・スプリッタ、及び対物レンズを順に通って記録媒体100の記録層に集められる。集められた光ビームはその記録層で反射/回折される。その反射/回折光は、対物レンズ、ビーム・スプリッタ、及び集光レンズを通って光検出器に集められる。光検出器は、その集光量に応じたレベルの再生信号を生成する。更に、その再生信号からデータが復調される。
BD−ROMドライブ4601は、再生制御部4607からの要求に従って記録媒体100からデータを読み出す。そのデータのうち、ファイル2Dのエクステント、すなわち2Dエクステントはリード・バッファ4602へ転送され、動的シナリオ情報は動的シナリオ・メモリ4604へ転送され、静的シナリオ情報は静的シナリオ・メモリ4605へ転送される。「動的シナリオ情報」は、インデックス・ファイル、ムービーオブジェクト・ファイル、及びBD−Jオブジェクト・ファイルを含む。「静的シナリオ情報」は2Dプレイリスト・ファイルと2Dクリップ情報ファイルとを含む。
リード・バッファ4602、動的シナリオ・メモリ4604、及び静的シナリオ・メモリ4605はいずれもバッファ・メモリである。リード・バッファ4602としては再生部4600A内のメモリ素子が利用され、動的シナリオ・メモリ4604及び静的シナリオ・メモリ4605としては制御部4600B内のメモリ素子が利用される。その他に、それらのバッファ・メモリ4602、4604、4605として、単一のメモリ素子の異なる領域が利用されてもよい。リード・バッファ4602は2Dエクステントを格納し、動的シナリオ・メモリ4604は動的シナリオ情報を格納し、静的シナリオ・メモリ4605は静的シナリオ情報を格納する。
システム・ターゲット・デコーダ4603は、リード・バッファ4602から2Dエクステントをソースパケット単位で読み出して多重分離処理を行い、更に分離された各エレメンタリ・ストリームに対して復号処理を行う。ここで、各エレメンタリ・ストリームの復号に必要な情報、例えばコーデックの種類及びストリームの属性は予め、再生制御部4607からシステム・ターゲット・デコーダ4603へ転送されている。システム・ターゲット・デコーダ4603は更に、復号後のプライマリ・ビデオ・ストリーム、セカンダリ・ビデオ・ストリーム、IGストリーム、及びPGストリームをそれぞれ、VAUごとに、主映像プレーン・データ、副映像プレーン・データ、IGプレーン・データ、及びPGプレーン・データとして送出する。一方、システム・ターゲット・デコーダ4603は、復号後のプライマリ・オーディオ・ストリームとセカンダリ・オーディオ・ストリームとをミキシングしてテレビ300の内蔵スピーカ103A等の音声出力装置へ送出する。その他に、システム・ターゲット・デコーダ4603はプログラム実行部4606からグラフィックス・データを受信する。そのグラフィックス・データは、GUI用のメニュー等のグラフィックスを画面に表示するためのものであり、JPEG又はPNG等のラスタデータで表現されている。システム・ターゲット・デコーダ4603はそのグラフィックス・データを処理してイメージ・プレーン・データとして送出する。尚、システム・ターゲット・デコーダ4603の詳細については後述する。
ユーザイベント処理部4609は、リモコン105又は再生装置200のフロントパネルを通してユーザの操作を検出し、その操作の種類に応じて、プログラム実行部4606又は再生制御部4607に処理を依頼する。例えばユーザがリモコン105のボタンを押下してポップアップ・メニューの表示を指示したとき、ユーザイベント処理部4609はその押下を検出してそのボタンを識別する。ユーザイベント処理部4609は更にプログラム実行部4606に、そのボタンに対応するコマンドの実行、すなわちポップアップ・メニューの表示処理を依頼する。一方、例えばユーザがリモコン105の早送り又は巻戻しボタンを押下したとき、ユーザイベント処理部4609はその押下を検出してそのボタンを識別する。ユーザイベント処理部4609は更に再生制御部4607に、現在再生中のプレイリストの早送り又は巻戻し処理を依頼する。
再生制御部4607は、2Dエクステント及びインデックス・ファイル等、各種のデータを記録媒体100から、リード・バッファ4602、動的シナリオ・メモリ4604、及び静的シナリオ・メモリ4605へ転送する処理を制御する。その制御には、図7に示されているディレクトリ/ファイル構造を管理するファイルシステムが利用される。すなわち、再生制御部4607はファイル・オープン用のシステムコールを利用して、BD−ROMドライブ4601に各種のファイルを各バッファ・メモリ4602、4604、4605へ転送させる。ここで、ファイル・オープンとは次の一連の処理をいう。まず、システムコールによってファイルシステムに検索対象のファイル名が与えられ、そのファイル名がディレクトリ/ファイル構造から検索される。その検索に成功したとき、再生制御部4607内のメモリには、まず、転送対象のファイルのファイル・エントリが転送され、そのメモリ内にFCB(File Control Block)が生成される。その後、転送対象のファイルのファイル・ハンドルがファイルシステムから再生制御部4607に返される。以後、再生制御部4607はそのファイル・ハンドルをBD−ROMドライブ4601に提示することにより、BD−ROMドライブ4601にその転送対象のファイルを記録媒体100から各バッファ・メモリ4602、4604、4605へ転送させることができる。
再生制御部4607は、BD−ROMドライブ4601とシステム・ターゲット・デコーダ4603とを制御してファイル2Dから映像データと音声データとを復号させる。具体的には、再生制御部4607はまず、プログラム実行部4606からの命令、又はユーザイベント処理部4609からの依頼に応じて、静的シナリオ・メモリ4605から2Dプレイリスト・ファイルを読み出してその内容を解釈する。再生制御部4607は次に、その解釈された内容、特に再生経路に従って、BD−ROMドライブ4601とシステム・ターゲット・デコーダ4603とに再生対象のファイル2Dを指定して、その読み出し処理及び復号処理を指示する。このようなプレイリスト・ファイルに基づく再生処理を「プレイリスト再生」という。その他に、再生制御部4607は、静的シナリオ情報を利用してプレーヤ変数記憶部4608に各種のプレーヤ変数を設定する。再生制御部4607は更に、それらのプレーヤ変数を参照して、システム・ターゲット・デコーダ4603に復号対象のエレメンタリ・ストリームを指定し、かつ、各エレメンタリ・ストリームの復号に必要な情報を提供する。
プレーヤ変数記憶部4608は、プレーヤ変数を記憶するためのレジスタ群である。プレーヤ変数の種類にはシステム・パラメータ(SPRM)と汎用のパラメータ(GPRM)とがある。SPRMは再生装置200の状態を示す。図55はSPRMの一覧表である。各SPRMには通し番号4701が振られ、各通し番号4701に変数値4702が個別に対応付けられている。主なSPRMの内容は以下のとおりである。ここで、括弧内の数字は通し番号4701を示す。
SPRM(0) : 言語コード
SPRM(1) : プライマリ・オーディオ・ストリーム番号
SPRM(2) : 字幕ストリーム番号
SPRM(3) : アングル番号
SPRM(4) : タイトル番号
SPRM(5) : チャプタ番号
SPRM(6) : プログラム番号
SPRM(7) : セル番号
SPRM(8) : 選択キー情報
SPRM(9) : ナビゲーション・タイマー
SPRM(10) : 再生時刻情報
SPRM(11) : カラオケ用ミキシングモード
SPRM(12) : パレンタル用国情報
SPRM(13) : パレンタル・レベル
SPRM(14) : プレーヤ設定値(ビデオ)
SPRM(15) : プレーヤ設定値(オーディオ)
SPRM(16) : オーディオ・ストリーム用言語コード
SPRM(17) : オーディオ・ストリーム用言語コード(拡張)
SPRM(18) : 字幕ストリーム用言語コード
SPRM(19) : 字幕ストリーム用言語コード(拡張)
SPRM(20) : プレーヤ・リージョン・コード
SPRM(21) : セカンダリ・ビデオ・ストリーム番号
SPRM(22) : セカンダリ・オーディオ・ストリーム番号
SPRM(23) : 再生状態
SPRM(24) : 予備
SPRM(25) : 予備
SPRM(26) : 予備
SPRM(27) : 予備
SPRM(28) : 予備
SPRM(29) : 予備
SPRM(30) : 予備
SPRM(31) : 予備
SPRM(10)は、復号処理中のピクチャのPTSを示し、そのピクチャが復号されて主映像プレーン・メモリに書き込まれる度に更新される。従って、SPRM(10)を参照すれば、現在の再生時点を知ることができる。
SPRM(16)のオーディオ・ストリーム用言語コード、及びSPRM(18)の字幕ストリーム用言語コードは、再生装置200のデフォルトの言語コードを示す。それらは再生装置200のOSD等を利用してユーザに変更させることもでき、プログラム実行部4606を通じてアプリケーション・プログラムに変更させることもできる。例えばSPRM(16)が「英語」を示しているとき、再生制御部4607はプレイリスト再生処理において、まずPI内のSTNテーブルから、「英語」の言語コードを含むストリーム・エントリを検索する。再生制御部4607は次に、そのストリーム・エントリのストリーム識別情報からPIDを抽出してシステム・ターゲット・デコーダ4603に渡す。それにより、そのPIDのオーディオ・ストリームがシステム・ターゲット・デコーダ4603によって選択され、復号される。これらの処理は、ムービーオブジェクト・ファイル又はBD−Jオブジェクト・ファイルを利用して再生制御部4607に実行させることができる。
再生制御部4607は再生処理中、再生状態の変化に応じてプレーヤ変数を更新する。再生制御部4607は特に、SPRM(1)、SPRM(2)、SPRM(21)、及びSPRM(22)を更新する。それらは順に、処理中のオーディオ・ストリーム、字幕ストリーム、セカンダリ・ビデオ・ストリーム、及びセカンダリ・オーディオ・ストリームの各STNを示す。例えばプログラム実行部4606によってSPRM(1)が変更されたときを想定する。再生制御部4607はそのとき、まず現時点で再生処理中のPI内のSTNテーブルから、変更後のSPRM(1)の示すSTNを含むストリーム・エントリを検索する。再生制御部4607は次に、そのストリーム・エントリ内のストリーム識別情報からPIDを抽出してシステム・ターゲット・デコーダ4603に渡す。それにより、そのPIDのオーディオ・ストリームがシステム・ターゲット・デコーダ4603によって選択され、復号される。こうして、再生対象のオーディオ・ストリームが切り換えられる。同様に、再生対象の字幕及びセカンダリ・ビデオ・ストリームを切り換えることもできる。
プログラム実行部4606はプロセッサであり、ムービーオブジェクト・ファイル及びBD−Jオブジェクト・ファイルに格納されたプログラムを実行する。プログラム実行部4606は各プログラムに従って、特に次のような制御を行う:(1)再生制御部4607に対してプレイリスト再生処理を命令する;(2)メニュー用又はゲーム用のグラフィックス・データをPNG又はJPEGのラスタデータとして生成し、それをシステム・ターゲット・デコーダ4603へ転送して他の映像データに合成させる。これらの制御の具体的な内容はプログラムの設計を通じて比較的自由に設計することができる。すなわち、それらの制御内容は、記録媒体100のオーサリング工程のうち、ムービーオブジェクト・ファイル及びBD−Jオブジェクト・ファイルのプログラミング工程によって決まる。
プレーン加算部4610は、システム・ターゲット・デコーダ4603から、主映像プレーン・データ、副映像プレーン・データ、IGプレーン・データ、PGプレーン・データ、及びイメージ・プレーン・データを受信し、それらを互いに重畳して一つの映像フレーム又はフィールドに合成する。合成後の映像データはテレビ300へ送出され、その画面に表示される。
≪システム・ターゲット・デコーダ≫
図56は、システム・ターゲット・デコーダ4603の機能ブロック図である。図56を参照するに、システム・ターゲット・デコーダ4603は、ソース・デパケタイザ4810、ATCカウンタ4820、第1の27MHzクロック4830、PIDフィルタ4840、STCカウンタ(STC1)4850、第2の27MHzクロック4860、主映像デコーダ4870、副映像デコーダ4871、PGデコーダ4872、IGデコーダ4873、主音声デコーダ4874、副音声デコーダ4875、イメージ・プロセッサ4880、主映像プレーン・メモリ4890、副映像プレーン・メモリ4891、PGプレーン・メモリ4892、IGプレーン・メモリ4893、イメージ・プレーン・メモリ4894、及び音声ミキサ4895を含む。
ソース・デパケタイザ4810はリード・バッファ4602からソースパケットを読み出し、その中からTSパケットを取り出してPIDフィルタ4840へ送出する。ソース・デパケタイザ4810は更に、その送出の時刻を各ソースパケットのATSに応じて調整する。具体的には、ソース・デパケタイザ4810はまず、ATCカウンタ4820が生成するATCの値を監視する。ここで、ATCの値はATCカウンタ4820により、第1の27MHzクロック4830のクロック信号のパルスに応じてインクリメントされる。ソース・デパケタイザ4810は次に、ATCの値がソースパケットのATSと一致した瞬間、そのソースパケットから取り出されたTSパケットをPIDフィルタ4840へ転送する。そのような送出時刻の調整により、ソース・デパケタイザ4810からPIDフィルタ4840へのTSパケットの平均転送速度RTSは、図38に示されている2Dクリップ情報ファイルの示すシステムレート3111を超えない。
PIDフィルタ4840はまず、ソース・デパケタイザ4810から送出されたTSパケットの含むPIDを監視する。そのPIDが、再生制御部4807から予め指定されたPIDに一致したとき、PIDフィルタ4840はそのTSパケットを選択し、そのPIDの示すエレメンタリ・ストリームの復号に適したデコーダ4870−4875へ転送する。例えばPIDが0x1011であるとき、そのTSパケットは主映像デコーダ4870へ転送される。一方、PIDが、0x1B00−0x1B1F、0x1100−0x111F、0x1A00−0x1A1F、0x1200−0x121F、及び0x1400−0x141Fの各範囲に属するとき、TSパケットはそれぞれ、副映像デコーダ4871、主音声デコーダ4874、副音声デコーダ4875、PGデコーダ4872、及びIGデコーダ4873へ転送される。
PIDフィルタ4840は更に、各TSパケットのPIDを利用してそのTSパケットの中からPCRを検出する。PIDフィルタ4840はそのとき、STCカウンタ4850の値を所定値に設定する。ここで、STCカウンタ4850の値は第2の27MHzクロック4860のクロック信号のパルスに応じてインクリメントされる。また、STCカウンタ4850に設定されるべき値は予め、再生制御部4807からPIDフィルタ4840に指示されている。各デコーダ4870−4875はSTCカウンタ4850の値をSTCとして利用する。すなわち、PIDフィルタ4840から送出されたTSパケットに対する復号処理の時期を、そのTSパケットに含まれるPTS又はDTSの示す時刻に従って調節する。
主映像デコーダ4870は、図56に示されているように、トランスポート・ストリーム・バッファ(TB:Transport Stream Buffer)4801、多重化バッファ(MB:Multiplexing Buffer)4802、エレメンタリ・ストリーム・バッファ(EB:Elementary Stream Buffer)4803、圧縮映像デコーダ(DEC)4804、及び復号ピクチャ・バッファ(DPB:Decoded Picture Buffer)4805を含む。TB4801、MB4802、EB4803、及びDPB4805はいずれもバッファ・メモリであり、それぞれ主映像デコーダ4870に内蔵のメモリ素子の一領域を利用する。その他に、それらのいずれか又は全てが異なるメモリ素子に分離されていてもよい。TB4801は、PIDフィルタ4840から受信されたTSパケットをそのまま蓄積する。MB4802は、TB4801に蓄積されたTSパケットから復元されたPESパケットを蓄積する。尚、TB4801からMB4802へTSパケットが転送されるとき、そのTSパケットからTSヘッダが除去される。EB4803は、PESパケットから、符号化されたVAUを抽出して格納する。そのVAUには、圧縮ピクチャ、すなわち、Iピクチャ、Bピクチャ、及びPピクチャが格納されている。尚、MB4802からEB4803へデータが転送されるとき、そのPESパケットからPESヘッダが除去される。DEC4804は、EB4803内の各VAUからピクチャを、元のTSパケットに含まれるDTSの示す時刻に復号する。DEC4804はその他に、図13に示されているデコードスイッチ情報を利用して、各VAUからピクチャをそのDTSに関わらず、順次復号してもよい。DEC4804は、各VAU内に格納された圧縮ピクチャの圧縮符号化方式、例えば、MPEG−2、MPEG−4 AVC、及びVC1、並びにストリーム属性に応じて復号方法を切り換える。DEC4804は更に、復号後のピクチャ、すなわちフレーム又はフィールドをDPB4805へ転送する。DPB4805は復号後のピクチャを一時的に保持する。DEC4804は、Pピクチャ及びBピクチャを復号するとき、DPB4805に保持されている復号後のピクチャを参照する。DPB4805は更に、保持している各ピクチャを、元のTSパケットに含まれるPTSの示す時刻に主映像プレーン・メモリ4890へ書き込む。
副映像デコーダ4871は主映像デコーダ4870と同様の構成を含む。副映像デコーダ4871はまず、PIDフィルタ4840から受信されたセカンダリ・ビデオ・ストリームのTSパケットを非圧縮のピクチャに復号する。副映像デコーダ4871は次に、そのTSパケットに含まれるPTSの示す時刻に非圧縮のピクチャを副映像プレーン・メモリ4891へ書き込む。
PGデコーダ4872は、PIDフィルタ4840から受信されたTSパケットを非圧縮のグラフィックス・データに復号し、そのTSパケットに含まれるPTSの示す時刻にPGプレーン・メモリ4892へ書き込む。
IGデコーダ4873は、PIDフィルタ4840から受信されたTSパケットを非圧縮のグラフィックス・データに復号し、そのTSパケットに含まれるPTSの示す時刻にIGプレーン・メモリ4893へ書き込む。
主音声デコーダ4874はまず、PIDフィルタ4840から受信されたTSパケットを内蔵のバッファに蓄える。主音声デコーダ4874は次に、そのバッファ内の各TSパケットからTSヘッダとPESヘッダとを除去し、残りのデータを非圧縮のLPCM音声データに復号する。主音声デコーダ4874は更にその音声データを、元のTSパケットに含まれるPTSの示す時刻に音声ミキサ4895へ送出する。主音声デコーダ4874は、TSパケットに含まれるプライマリ・オーディオ・ストリームの圧縮符号化方式、例えばAC−3又はDTS、及びストリーム属性に応じて、圧縮音声データの復号方法を切り換える。
副音声デコーダ4875は主音声デコーダ4874と同様の構成を含む。副音声デコーダ4875はまず、PIDフィルタ4840から受信されたセカンダリ・オーディオ・ストリームのTSパケットを非圧縮のLPCM音声データに復号する。副音声デコーダ4875は次に、そのTSパケットに含まれるPTSの示す時刻に非圧縮のLPCM音声データを音声ミキサ4895へ送出する。副音声デコーダ4875は、TSパケットに含まれるセカンダリ・オーディオ・ストリームの圧縮符号化方式、例えば、ドルビー・デジタル・プラス、DTS−HD LBR、及びストリーム属性に応じて圧縮音声データの復号方法を切り換える。
音声ミキサ4895は、主音声デコーダ4874と副音声デコーダ4875とのそれぞれから非圧縮の音声データを受信し、それらを用いてミキシング(音の重ね合わせ)を行う。音声ミキサ4895は更に、そのミキシングで得られた合成音をテレビ300の内蔵スピーカ103A等へ送出する。
イメージ・プロセッサ4880は、プログラム実行部4806からグラフィックス・データ、すなわちPNG又はJPEGのラスタデータを受信する。イメージ・プロセッサ4880はそのとき、そのグラフィックス・データに対するレンダリング処理を行ってイメージ・プレーン・メモリ4894へ書き込む。
<3D再生装置の構成>
3D再生モードの再生装置200は記録媒体100から3D映像コンテンツを再生するとき、3D再生装置として動作する。その構成の基本部分は、図54−56に示されている2D再生装置の構成と同様である。従って、以下では2D再生装置の構成からの拡張部分及び変更部分について説明し、基本部分の詳細についての説明は上記の2D再生装置についての説明を援用する。また、2Dプレイリスト・ファイルに従った2D映像の再生処理、すなわち2Dプレイリスト再生処理に利用される構成は2D再生装置の構成と同様である。従って、その詳細についての説明も上記の2D再生装置についての説明を援用する。以下の説明では、3Dプレイリスト・ファイルに従った3D映像の再生処理、すなわち3Dプレイリスト再生処理を想定する。
図57は、3D再生装置4900の機能ブロック図である。3D再生装置4900は、BD−ROMドライブ4901、再生部4900A、及び制御部4900Bを含む。再生部4900Aは、スイッチ4911、第1リード・バッファ4921、第2リード・バッファ4922、システム・ターゲット・デコーダ4903、及びプレーン加算部4910を含む。制御部4900Bは、動的シナリオ・メモリ4904、静的シナリオ・メモリ4905、プログラム実行部4906、再生制御部4907、プレーヤ変数記憶部4908、及びユーザイベント処理部4909を含む。再生部4900Aと制御部4900Bとは互いに異なる集積回路に実装されている。その他に、両者が単一の集積回路に統合されていてもよい。特に、動的シナリオ・メモリ4904、静的シナリオ・メモリ4905、プログラム実行部4906、及びユーザイベント処理部4909は、図54に示されている2D再生装置内のものと同様である。従って、それらの詳細についての説明は上記の2D再生装置についての説明を援用する。
BD−ROMドライブ4901は、図54に示されている2D再生装置内のもの4601と同様な構成要素を含む。BD−ROMドライブ4901は、再生制御部4907からLBNの範囲が指示されたとき、その範囲の示す記録媒体100上のセクタ群からデータを読み出す。特にファイルSSのエクステント、すなわち3Dエクステントに属するソースパケット群は、BD−ROMドライブ4901からスイッチ4911へ転送される。ここで、各3Dエクステントは、図18の(d)及び図41に示されているとおり、ベースビューとディペンデントビューとのデータ・ブロックの対を一つ以上含む。それらのデータ・ブロックは異なるリード・バッファ4921、4922へパラレルに転送されなければならない。従って、BD−ROMドライブ4901には2D再生装置内のBD−ROMドライブ4601以上のアクセス・スピードが求められる。
スイッチ4911はBD−ROMドライブ4901からは3Dエクステントを受信する。一方、スイッチ4911は再生制御部4907からは、その3Dエクステントに含まれる各データ・ブロックの境界を示す情報、例えばその3Dエクステントの先頭から各境界までのソースパケット数を受信する。ここで、再生制御部4907はその情報を、クリップ情報ファイル内のエクステント起点を利用して生成する。スイッチ4911は更に、その情報を利用して各3Dエクステントからベースビュー・データ・ブロックを抽出して、第1リード・バッファ4921へ送出する。一方、スイッチ4911は残りのディペンデントビュー・データ・ブロックを第2リード・バッファ4922へ送出する。
第1リード・バッファ4921と第2リード・バッファ4922とはいずれも、再生部4900A内のメモリ素子を利用したバッファ・メモリである。特に単一のメモリ素子内の異なる領域が各リード・バッファ4921、4922として利用される。その他に、異なるメモリ素子が個別に各リード・バッファ4921、4922として利用されてもよい。第1リード・バッファ4921は、スイッチ4911からベースビュー・データ・ブロックを受信して格納する。第2リード・バッファ4922は、スイッチ4911からディペンデントビュー・データ・ブロックを受信して格納する。
システム・ターゲット・デコーダ4903はまず、第1リード・バッファ4921に格納されたベースビュー・データ・ブロックと、第2リード・バッファ4922に格納されたディペンデントビュー・データ・ブロックとから交互にソースパケットを読み出す。システム・ターゲット・デコーダ4903は次に、多重分離処理によって各ソースパケットからエレメンタリ・ストリームを分離し、更に分離されたものの中から、再生制御部4907から指示されたPIDの示すものを復号する。システム・ターゲット・デコーダ4903は続いて、復号後のエレメンタリ・ストリームをその種類別に内蔵のプレーン・メモリに書き込む。ベースビュー・ビデオ・ストリームは左映像プレーン・メモリに書き込まれ、ディペンデントビュー・ビデオ・ストリームは右映像プレーン・メモリに書き込まれる。一方、セカンダリ・ビデオ・ストリームは副映像プレーン・メモリに書き込まれ、IGストリームはIGプレーン・メモリに書き込まれ、PGストリームはPGプレーン・メモリに書き込まれる。ここで、ビデオ・ストリーム以外のストリーム・データがベースビューとディペンデントビューとのストリーム・データの対から成るとき、対応するプレーン・メモリはレフトビューとライトビューとの両方のプレーン・データに対して個別に用意される。システム・ターゲット・デコーダ4903はその他に、プログラム実行部4906からのグラフィックス・データ、例えばJPEG又はPNG等のラスタデータを処理してイメージ・プレーン・メモリに書き込む。
システム・ターゲット・デコーダ4903は、左映像と右映像との各プレーン・メモリからのプレーン・データの出力をB−D表示モードとB−B表示モードとに対応させる。再生制御部4907からB−D表示モードが指示されたとき、システム・ターゲット・デコーダ4903は左映像と右映像との各プレーン・メモリから交互にプレーン・データを出力する。一方、再生制御部4907からB−B表示モードが指示されたとき、システム・ターゲット・デコーダ4903は動作モードを3D再生モードに維持したまま、左映像と右映像とのいずれかのプレーン・メモリからのみプレーン・データをフレーム当たり二回ずつ出力する。
システム・ターゲット・デコーダ4903は更に、グラフィックス・プレーン・メモリ、すなわち、PGプレーン・メモリ、IGプレーン・メモリ、及びイメージ・プレーン・メモリからの各グラフィックス・プレーン・データの出力を、2プレーン・モード、1プレーン+オフセット・モード、及び1プレーン+ゼロ・オフセット・モードに対応させる。再生制御部4907から2プレーン・モードが指示されたとき、システム・ターゲット・デコーダ4903は各グラフィックス・プレーン・メモリからレフトビューとライトビューとのグラフィックス・プレーン・データを交互に出力する。再生制御部4907から1プレーン+オフセット・モード又は1プレーン+ゼロ・オフセット・モードが指示されたとき、システム・ターゲット・デコーダ4903は動作モードを3D再生モードに維持したまま、各グラフィックス・プレーン・メモリからグラフィックス・プレーン・データを出力する。再生制御部4907から1プレーン+オフセット・モードが指示されたときは更に、システム・ターゲット・デコーダ4903は、再生制御部4907によって指定されたオフセット値をプレーン加算部4910に渡す。ここで、再生制御部4907は、そのオフセット値をクリップ情報ファイル内のオフセット・テーブルに基づいて設定する。一方、再生制御部4907から1プレーン+ゼロ・オフセット・モードが指示されたときは、システム・ターゲット・デコーダ4903はオフセット値として“0”をプレーン加算部4910に渡す。
再生制御部4907は、3Dプレイリスト再生処理をプログラム実行部4906等から命じられたとき、まず、静的シナリオ・メモリ4905に格納された3Dプレイリスト・ファイルを参照する。再生制御部4907は次に、3Dプレイリスト・ファイルに従い、図51に示されている手順で、読み出し対象の3Dエクステントが記録されたセクタ群のLBNの範囲をBD−ROMドライブ4901に指示する。一方、再生制御部4907は、静的シナリオ・メモリ4905に格納されたクリップ情報ファイル内の3Dメタデータを参照して、読み出し対象の各3Dエクステントに関するエクステント起点を検索する。再生制御部4907は更に、そのエクステント起点から、各3Dエクステントに含まれるデータ・ブロックの境界を示す情報を生成する。その情報が再生制御部4907からスイッチ4911へ送出される。
再生制御部4907はその他に、3Dプレイリスト・ファイル内のSTNテーブルとSTNテーブルSSとを利用して、システム・ターゲット・デコーダ4903とプレーン加算部4910との動作条件を制御する。例えば、再生対象のエレメンタリ・ストリームのPIDが選択されて、システム・ターゲット・デコーダ4903に渡される。また、STNテーブルSSのうち、ポップアップ期間のオフセット4111に応じて各プレーンの表示モードが選択されてシステム・ターゲット・デコーダ4903とプレーン加算部4910とに指示される。
プレーヤ変数記憶部4908は、2D再生装置内のものと同様に、図55に示されているSPRMを含む。しかし、図55では予備であったSPRM(24)−(32)のいずれか二つは、図53に示されている第1フラグと第2フラグとを個別に含む。例えば、SPRM(24)が第1フラグを含み、SPRM(25)が第2フラグを含む。その場合、SPRM(24)が“0”であるときは再生装置200が2D映像の再生のみに対応可能であり、“1”であるときは3D映像の再生にも対応可能である。SPRM(25)が“0”であるときは再生装置200がL/Rモードであり、“1”であるときはデプス・モードである。
プレーン加算部4910はシステム・ターゲット・デコーダ4903から各種のプレーン・データを受信し、それらを互いに重畳して一つのフレーム又はフィールドに合成する。特にL/Rモードでは、左映像プレーン・データはレフトビュー・ビデオ・プレーンを表し、右映像プレーン・データはライトビュー・ビデオ・プレーンを表す。従って、プレーン加算部4910は、左映像プレーン・データには、他のプレーン・データのうち、レフトビューを表すものを重畳し、右映像プレーン・データには、ライトビューを表すものを重畳する。一方、デプス・モードでは、右映像プレーン・データは、左映像プレーン・データの表すビデオ・プレーンに対するデプスマップを表す。従って、プレーン加算部4910はまず、両方の映像プレーン・データからレフトビューとライトビューとのビデオ・プレーン・データの対を生成する。その後、プレーン加算部4910はL/Rモードでの合成処理と同様に合成処理を行う。
再生制御部4907から、副映像プレーン、PGプレーン、IGプレーン、又はイメージ・プレーンの表示モードとして1プレーン+オフセット・モード又は1プレーン+ゼロ・オフセット・モードが指示されているとき、プレーン加算部4910は、システム・ターゲット・デコーダ4903から受信されたプレーン・データに対してクロッピング処理を行う。それにより、レフトビューとライトビューとのプレーン・データの対が生成される。特に1プレーン+オフセット・モードが指示されているとき、そのクロッピング処理では、システム・ターゲット・デコーダ4903又はプログラム実行部4906から指示されたオフセット値が利用される。一方、1プレーン+ゼロ・オフセット・モードが指示されているとき、そのクロッピング処理ではオフセット値が“0”に設定されている。従って、同じプレーン・データが、レフトビューとライトビューとを表すものとして繰り返し出力される。その後、プレーン加算部4910はL/Rモードでの合成処理と同様に合成処理を行う。合成後のフレーム又はフィールドはテレビ300へ送出され、その画面に表示される。
≪システム・ターゲット・デコーダ≫
図58は、システム・ターゲット・デコーダ4903の機能ブロック図である。図58に示されている構成要素は、図54に示されている2D再生装置のもの4603とは次の二点で異なる:(1)リード・バッファから各デコーダへの入力系統が二重化されている点、並びに、(2)主映像デコーダは3D再生モードに対応可能であり、副映像デコーダ、PGデコーダ、及びIGデコーダは2プレーン・モードに対応可能である点。すなわち、それらの映像デコーダはいずれもベースビューとディペンデントビューとのそれぞれのストリームを交互に復号できる点。一方、主音声デコーダ、副音声デコーダ、音声ミキサ、イメージ・プロセッサ、及び各プレーン・メモリは、図54に示されている2D再生装置のものと同様である。従って、以下では、図58に示されている構成要素のうち、図54に示されているものとは異なるものについて説明し、同様なものの詳細についての説明は、図54についての説明を援用する。更に、各映像デコーダはいずれも同様な構造を持つので、以下では主映像デコーダ5015の構造について説明し、他の映像デコーダの構造についてはその説明を援用する。
第1ソース・デパケタイザ5011は、第1リード・バッファ4921からソースパケットを読み出して、その中からTSパケットを取り出して第1PIDフィルタ5013へ送出する。第2ソース・デパケタイザ5012は、第2リード・バッファ4922からソースパケットを読み出して、その中からTSパケットを取り出して第2PIDフィルタ5014へ送出する。各ソース・デパケタイザ5011、5012は更に、各TSパケットの送出時刻を各ソースパケットのATSに応じて調整する。その調整方法は、図54に示されているソース・デパケタイザ4610による方法と同様であるので、その詳細についての説明は、図54についての説明を援用する。そのような調節により、第1ソース・デパケタイザ5011から第1PIDフィルタ5013へのTSパケットの平均転送速度RTS1は、図37に示されている2Dクリップ情報ファイルの示すシステムレート3011を超えない。同様に、第2ソース・デパケタイザ5012から第2PIDフィルタ5014へのTSパケットの平均転送速度RTS2は、ディペンデントビュー・クリップ情報ファイルの示すシステムレートを超えない。
第1PIDフィルタ5013は、第1ソース・デパケタイザ5011からTSパケットを受信する度に、そのPIDを選択対象のPIDと比較する。その選択対象のPIDは再生制御部4907によって予め、3Dプレイリスト・ファイル内のSTNテーブルに従って指定されている。両方のPIDが一致したとき、第1PIDフィルタ5013はそのTSパケットを、そのPIDに割り当てられたデコーダへ転送する。例えば、PIDが0x1011であるとき、そのTSパケットは主映像デコーダ5015内のTB(1)5001へ転送される。その他に、PIDが、0x1B00−0x1B1F、0x1100−0x111F、0x1A00−0x1A1F、0x1200−0x121F、及び0x1400−0x141Fの各範囲に属するとき、対応するTSパケットはそれぞれ、副映像デコーダ、主音声デコーダ、副音声デコーダ、PGデコーダ、及びIGデコーダへ転送される。
第2PIDフィルタ5014は、第2ソース・デパケタイザ5012からTSパケットを受信する度に、そのPIDを選択対象のPIDと比較する。その選択対象のPIDは再生制御部4907によって予め、3Dプレイリスト・ファイル内のSTNテーブルSSに従って指定されている。具体的には、両方のPIDが一致したとき、第2PIDフィルタ5014はそのTSパケットを、そのPIDに割り当てられたデコーダへ転送する。例えば、PIDが0x1012又は0x1013であるとき、そのTSパケットは主映像デコーダ5015内のTB(2)5008へ転送される。その他に、PIDが、0x1B20−0x1B3F、0x1220−0x127F、及び0x1420−0x147Fの各範囲に属するとき、対応するTSパケットはそれぞれ、副映像デコーダ、PGデコーダ、及びIGデコーダへ転送される。
主映像デコーダ5015は、TB(1)5001、MB(1)5002、EB(1)5003、TB(2)5008、MB(2)5009、EB(2)5010、バッファ・スイッチ5006、DEC5004、DPB5005、及びピクチャ・スイッチ5007を含む。TB(1)5001、MB(1)5002、EB(1)5003、TB(2)5008、MB(2)5009、EB(2)5010、及びDPB5005はいずれもバッファ・メモリである。各バッファ・メモリは、主映像デコーダ5015に内蔵されたメモリ素子の一領域を利用する。その他に、それらのバッファ・メモリのいずれか又は全てが、異なるメモリ素子に分離されていてもよい。
TB(1)5001は、ベースビュー・ビデオ・ストリームを含むTSパケットを第1PIDフィルタ5013から受信してそのまま蓄積する。MB(1)5002は、TB(1)5001に蓄積されたTSパケットからPESパケットを復元して蓄積する。そのとき、各TSパケットからTSヘッダが除去される。EB(1)5003は、MB(1)5002に蓄積されたPESパケットから、符号化されたVAUを抽出して蓄積する。そのとき、各PESパケットからPESヘッダが除去される。
TB(2)5008は、ディペンデントビュー・ビデオ・ストリームを含むTSパケットを第2PIDフィルタ5014から受信してそのまま蓄積する。MB(2)5009は、TB(2)5008に蓄積されたTSパケットからPESパケットを復元して蓄積する。そのとき、各TSパケットからTSヘッダが除去される。EB(2)5010は、MB(2)5009に蓄積されたPESパケットから、符号化されたVAUを抽出して蓄積する。そのとき、各PESパケットからPESヘッダが除去される。
バッファ・スイッチ5006は、EB(1)5003とEB(2)5010とのそれぞれに蓄積されたVAUを、元のTSパケットに含まれるDTSの示す時刻にDEC5004へ転送する。ここで、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間では、同じ3D・VAUに属する一対のピクチャのDTSが等しい。従って、バッファ・スイッチ5006は、EB(1)5003とEB(2)5010とに蓄積された、DTSの等しい一対のVAUのうち、EB(1)5003に蓄積された方を先にDEC5004へ転送する。その他に、バッファ・スイッチ5006は、図13に示されているそのVAU内のデコードスイッチ情報をDEC5004から返信されてもよい。その場合、バッファ・スイッチ5006はその復号スイッチ情報1401を使って、次に転送すべきVAUをEB(1)5003とEB(2)5010とのいずれから転送すべきか、決定できる。
DEC5004は、バッファ・スイッチ5006から転送されたVAUを復号する。ここで、そのVAU内に格納された圧縮ピクチャの符号化方式、例えば、MPEG−2、MPEG−4 AVC、及びVC1、並びにストリーム属性に応じて、DEC5004は復号方法を切り換える。DEC5004は更に、復号された非圧縮のピクチャ、すなわち映像フレーム又はフィールドをDPB5005へ転送する。
DPB5005は、復号された非圧縮のピクチャを一時的に保持する。DEC5004がPピクチャ及びBピクチャを復号するとき、DPB5005はDEC5004からの要求に応じて、保持されている非圧縮のピクチャの中から参照ピクチャをDEC5004に提供する。
ピクチャ・スイッチ5007は、DPB5005から非圧縮の各ピクチャを、元のTSパケットに含まれるPTSの示す時刻に、左映像プレーン・メモリ5020と右映像プレーン・メモリ5021とのいずれかに書き込む。ここで、ベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間では、同じ3D・VAUに属する一対のピクチャのPTSが等しい。従って、ピクチャ・スイッチ5007は、DPB5005に保持された、PTSの等しい一対のピクチャのうち、ベースビュー・ビデオ・ストリームに属する方を先に左映像プレーン・メモリ5020に書き込み、続いて、ディペンデントビュー・ビデオ・ストリームに属するものを右映像プレーン・メモリ5021に書き込む。
≪プレーン加算部≫
図59はプレーン加算部4910の機能ブロック図である。図59を参照するに、プレーン加算部4910は、視差映像生成部5110、スイッチ5120、四つのクロッピング処理部5131−5134、及び四つの加算部5141−5144を含む。
視差映像生成部5110は、システム・ターゲット・デコーダ4903から左映像プレーン・データ5101と右映像プレーン・データ5102とを受信する。再生装置200がL/Rモードであるとき、左映像プレーン・データ5101はレフトビュー・ビデオ・プレーンを表し、右映像プレーン・データ5102はライトビュー・ビデオ・プレーンを表す。そのとき、視差映像生成部5110は各ビデオ・プレーン・データ5101、5102をそのままスイッチ5120へ送出する。一方、再生装置200がデプス・モードであるとき、左映像プレーン・データ5101は2D映像のビデオ・プレーンを表し、右映像プレーン・データ5102はその2D映像に対するデプスマップを表す。そのとき、視差映像生成部5110は、まずそのデプスマップからその2D映像の各部の両眼視差を計算する。視差映像生成部5110は次に、左映像プレーン・データ5101を加工して、ビデオ・プレーンにおけるその2D映像の各部の表示位置を、計算された両眼視差に応じて左右に移動させる。それにより、レフトビューとライトビューとを表すビデオ・プレーンの対が生成される。視差映像生成部5110は更に、そのビデオ・プレーンの対を左映像と右映像とのプレーン・データの対としてスイッチ5120へ送出する。
スイッチ5120は、再生制御部4907からB−D表示モードが指示されているとき、PTSの等しい左映像プレーン・データ5101と右映像プレーン・データ5102とをその順で第1加算部5141へ送出する。スイッチ5120は、再生制御部4907からB−B表示モードが指示されているとき、PTSの等しい左映像プレーン・データ5101と右映像プレーン・データ5102との一方をフレーム当たり二回ずつ、第1加算部5141へ送出し、他方を破棄する。
各クロッピング処理部5131−5134は、視差映像生成部5110とスイッチ5120との対と同様な構成を含む。2プレーン・モードではそれらの構成が利用される。特に再生装置200がデプス・モードであるとき、システム・ターゲット・デコーダ4903からのプレーン・データはレフトビューとライトビューとのプレーン・データの対に変換される。再生制御部4907からB−D表示モードが指示されているとき、レフトビューとライトビューとのプレーン・データが交互に各加算部5141−5144へ送出される。一方、再生制御部4907からB−B表示モードが指示されているとき、レフトビューとライトビューとのプレーン・データの一方がフレーム当たり二回ずつ各加算部5141−5144へ送出され、他方は破棄される。
1プレーン+オフセット・モードでは、第1クロッピング処理部5131は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用して副映像プレーン・データ5103に対してクロッピング処理を行う。それにより、その副映像プレーン・データ5103は、レフトビューとライトビューとを表す一対の副映像プレーン・データに変換されて交互に送出される。一方、1プレーン+ゼロ・オフセット・モードではその副映像プレーン・データ5103が二回繰り返して送出される。
1プレーン+オフセット・モードでは、第2クロッピング処理部5132は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用してPGプレーン・データ5104に対してクロッピング処理を行う。それにより、そのPGプレーン・データ5104は、レフトビューとライトビューとを表す一対のPGプレーン・データに変換されて交互に送出される。一方、1プレーン+ゼロ・オフセット・モードではそのPGプレーン・データ5104が二回繰り返して送出される。
1プレーン+オフセット・モードでは、第3クロッピング処理部5133は、システム・ターゲット・デコーダ4903からオフセット値5151を受信し、それを利用してIGプレーン・データ5105に対してクロッピング処理を行う。それにより、そのIGプレーン・データ5105は、レフトビューとライトビューとを表す一対のIGプレーン・データに変換されて交互に送出される。一方、1プレーン+ゼロ・オフセット・モードではそのIGプレーン・データ5105が二回繰り返して送出される。
図60の(a)、(b)は、第2クロッピング処理部5132によるクロッピング処理を示す模式図である。図60の(a)、(b)ではそれぞれ、PGプレーン・データ5104からレフトビューPGプレーン・データ5204LとライトビューPGプレーン・データ5204Rとの対が次のように生成される。第2クロッピング処理部5132はまず、オフセット値5151の中から、PGプレーンに割り当てられたものを検索する。第2クロッピング処理部5132は次に、そのオフセット値に従って、PGプレーン・データ5104の示すグラフィックス映像の表示位置に対するレフトビューとライトビューとの各表示位置を左又は右に変化させる。その結果、レフトビューとライトビューとのPGプレーン・データの対が得られる。尚、1プレーン+ゼロ・オフセット・モードではオフセット値が“0”であるので、元のPGプレーン・データがそのまま維持される。第1クロッピング処理部5131は副映像プレーン・データ5103に対して同様にクロッピング処理を行い、第3クロッピング処理部5133はIGプレーン・データ5105に対して同様にクロッピング処理を行う。
図60の(a)を参照するに、3D映像の奥行きが画面よりも手前であることをオフセット値の符号が示すとき、第2クロッピング処理部5132はまず、PGプレーン・データ5104内の各画素データの位置を元の位置から、オフセット値に等しい画素数5201Lだけ右に変化させる。3D映像の奥行きが画面よりも奥であることをオフセット値の符号が示すときは、左に変化させる。第2クロッピング処理部5132は次に、PGプレーン・データ5104の範囲から右(又は左)にはみ出ている画素データ群5202Lを除去する。こうして、残りの画素データ群5204LがレフトビューPGプレーン・データとして出力される。
図60の(b)を参照するに、3D映像の奥行きが画面よりも手前であることをオフセット値の符号が示すとき、第2クロッピング処理部5132はまず、PGプレーン・データ5104内の各画素データの位置を元の位置から、オフセット値に等しい画素数5201Rだけ左に変化させる。3D映像の奥行きが画面よりも奥であることをオフセット方向が示すときは、右に変化させる。第2クロッピング処理部5132は次に、PGプレーン・データ5104の範囲から左(又は右)にはみ出ている画素データ群5202Rを除去する。こうして、残りの画素データ群5204RがライトビューPGプレーン・データとして出力される。
図61の(a)、(b)、(c)はそれぞれ、図60に示されているクロッピング処理によって生成されたレフトビューとライトビューとのPGプレーン、及びそれらから視聴者に知覚される3D映像を示す模式図である。図61の(a)を参照するに、レフトビューPGプレーン5301Lは画面5302の範囲からオフセット値5201Lだけ右に変位している。その結果、レフトビューPGプレーン5301L内の字幕の2D映像5303は、元の位置よりもオフセット値5201Lだけ右に変位して見える。図61の(b)を参照するに、ライトビューPGプレーン5301Rは逆に、画面5302の範囲からオフセット値5201Rだけ左に変位している。その結果、ライトビューPGプレーン5301R内の字幕の2D映像5303は、元の位置よりもオフセット値5201Rだけ左に変位して見える。それらのPGプレーン5301L、5301Rを画面5302に交互に表示するとき、図61の(c)に示されているように、視聴者5304には字幕の3D映像5305が画面5302よりも手前に見える。そのときの3D映像5305と画面5302との間の距離はオフセット値5201L、5201Rによって調節可能である。PGプレーン・データ5104内の各画素データの位置を、図60の(a)、(b)に示されている方向とは逆に変化させたときは、視聴者5304には字幕の3D映像5305が画面5302よりも奥に見える。
このように、1プレーン+オフセット・モードではクリッピング処理を利用して、一つのプレーン・データから、レフトビューとライトビューとのプレーン・データの対が生成される。それにより、一つのプレーン・データからでも、視差映像を表示することができる。すなわち、平面的なイメージに対して奥行き感を与えることができる。特に視聴者にその平面的なイメージを画面から浮かび上がるようにも、画面の奥に沈み込むようにも見せることができる。尚、1プレーン+ゼロ・オフセット・モードではオフセット値が“0”であるので、平面的なイメージがそのまま維持される。
図59を再び参照するに、イメージ・プレーン・データ5106は、プログラム実行部4906からシステム・ターゲット・デコーダ4903へ転送されたグラフィックス・データが、システム・ターゲット・デコーダ4903によって復号されたものである。そのグラフィックス・データはJPEG又はPNG等のラスタデータであり、メニュー等のGUI用グラフィックス部品を表す。第4クロッピング処理部5134はイメージ・プレーン・データ5106に対するクロッピング処理を他のクロッピング処理部5131−5133と同様に行う。但し、第4クロッピング処理部5134は他のクロッピング処理部5131−5133とは異なり、オフセット値をシステム・ターゲット・デコーダ4903ではなく、プログラムAPI5152から受け取る。ここで、プログラムAPI5152はプログラム実行部4906によって実行される。それにより、グラフィックス・データの表すイメージの奥行きに相当するオフセット値が算出されて、第4クロッピング処理部5134に渡される。
第1加算部5141はまず、スイッチ5120からはビデオ・プレーン・データを受信し、第1クロッピング処理部5131からは副映像プレーン・データを受信する。第1加算部5141は次に、ビデオ・プレーン・データと副映像プレーン・データとを一組ずつ重畳して第2加算部5142に渡す。第2加算部5142は、第2クロッピング処理部5132からPGプレーン・データを受信し、第1加算部5141からのプレーン・データに重畳して第3加算部5143に渡す。第3加算部5143は、第3クロッピング処理部5133からIGプレーン・データを受信し、第2加算部5142からのプレーン・データに重畳して第4加算部5144に渡す。第4加算部5144は、第4クロッピング処理部5134からイメージ・プレーン・データを受信し、第3加算部5143からのプレーン・データに重畳してテレビ300へ送出する。その結果、図59に矢印5100で示されている順序で、左映像プレーン・データ5101又は右映像プレーン・データ5102、副映像プレーン・データ5103、PGプレーン・データ5104、IGプレーン・データ5105、及びイメージ・プレーン・データ5106は重畳される。それらの合成処理により、各プレーン・データの示す映像はテレビ300の画面上に、左映像プレーン又は右映像プレーン、副映像プレーン、IGプレーン、PGプレーン、及びイメージ・プレーンの順に重ねられたように表示される。
プレーン加算部4910は上記の処理の他に、四つの加算部5141−5144によって合成されたプレーン・データの出力形式を、テレビ300等、そのデータの出力先の装置による3D映像の表示方式に合わせて変換する。例えば出力先の装置が経時分離方式を利用するとき、プレーン加算部4910は合成後のプレーン・データを一つの映像フレーム又はフィールドとして送出する。一方、出力先の装置がレンチキュラーレンズを利用するとき、プレーン加算部4910は内蔵のバッファ・メモリを利用して、レフトビューとライトビューとのプレーン・データの対を一つの映像フレーム又はフィールドに合成して送出する。具体的には、プレーン加算部4910は、先に合成されたレフトビュー・プレーン・データを一旦、そのバッファ・メモリに格納して保持する。プレーン加算部4910は続いて、ライトビュー・プレーン・データを合成して、バッファ・メモリに保持されたレフトビュー・プレーン・データと更に合成する。その合成では、レフトビューとライトビューとの各プレーン・データが縦方向に細長い短冊形の小領域に分割され、各小領域が一つのフレーム又はフィールドの中に横方向に交互に並べられて一つのフレーム又はフィールドに再構成される。こうして、レフトビューとライトビューとのプレーン・データの対が一つの映像フレーム又はフィールドに合成される。プレーン加算部4910はその合成後の映像フレーム又はフィールドを出力先の装置へ送出する。
以上が再生装置についての説明である。
<映像のシームレス再生のためにデータ・ブロックのサイズが満たすべき条件>
本発明の実施形態による記録媒体100では、図15、41に示されているとおり、ベースビュー・データ・ブロックとディペンデントビュー・データ・ブロックとが一つずつ交互に配置され、インターリーブ配置を形成している。更に、層境界等、ロングジャンプが必要な箇所では、図20、24、26、28、30、32に示されているとおり、ベースビュー・データ・ブロックとその複製データとが2D再生専用ブロックと3D再生専用ブロックとして配置されている。これらのデータ・ブロックの配置は上記の説明どおり、2D映像と3D映像とのいずれのシームレス再生にも有利である。それらのシームレス再生を更に確実に実現するには、各データ・ブロックのサイズは、再生装置200の性能に基づく条件を満たせばよい。以下、それらの条件について説明する。
≪2D再生モードの性能に基づく条件≫
図62は、2D再生モードの再生装置200内の再生処理系統を示す模式図である。図62を参照するに、その再生処理系統は、図54に示されている要素のうち、BD−ROMドライブ4601、リード・バッファ4602、及びシステム・ターゲット・デコーダ4603を含む。BD−ROMドライブ4601は記録媒体100から2Dエクステントを読み出し、読み出し速度Rud−2Dでリード・バッファ4602へ転送する。システム・ターゲット・デコーダ4603は、リード・バッファ4602内に蓄積された各2Dエクステントからソースパケットを平均転送速度Rext2Dで読み出し、映像データVDと音声データADとに復号する。
平均転送速度Rext2Dは、図45に示されているソース・デパケタイザ3711からPIDフィルタ3713へのTSパケットの平均転送速度RTSの192/188倍に等しく、一般に2Dエクステントごとに異なる。平均転送速度Rext2Dの最大値Rmax2Dは、ファイル2Dに対するシステムレートの192/188倍に等しい。ここで、そのシステムレートは、図37に示されているように、2Dクリップ情報ファイルに規定されている。また、上記の係数192/188はソースパケットとTSパケットとの間のバイト数の比に等しい。平均転送速度Rext2Dは通常ビット/秒で表され、具体的には、ビット単位で表された2DエクステントのサイズをエクステントATC時間で割ったときの値に等しい。「ビット単位で表されたエクステントのサイズ」は、そのエクステント内のソースパケット数とソースパケット一つ当たりのバイト数(=192バイト)との積の8倍に等しい。
読み出し速度Rud−2Dは通常ビット/秒で表され、平均転送速度Rext2Dの最高値Rmax2Dよりも高い値、例えば54Mbpsに設定される:Rud−2D>Rmax2D。それにより、BD−ROMドライブ4601が記録媒体100から一つの2Dエクステントを読み出している間、システム・ターゲット・デコーダ4603の復号処理に伴うリード・バッファ4602のアンダーフローが防止される。
図63の(a)は、2Dエクステントの再生処理中、リード・バッファ4602に蓄積されるデータ量DAの変化を示すグラフである。図63の(b)は、それらの2Dエクステントを含む3Dエクステント・ブロック5510と2D再生モードでの再生経路5520との間の対応関係を示す模式図である。図63の(b)を参照するに、3Dエクステント・ブロック5510は、インターリーブ配置のベースビュー・データ・ブロック群とディペンデントビュー・データ・ブロック群とで構成されている。再生経路5520に従い、各ベースビュー・データ・ブロックL0、L1、…が一つの2DエクステントEXT2D[0]、EXT2D[1]、…として、記録媒体100からリード・バッファ4602へ読み出される。まず、先頭のベースビュー・データ・ブロックL0、すなわち2DエクステントEXT2D[0]の読み出し期間PR2D[0]では、図63の(a)に示されているように、蓄積データ量DAは、読み出し速度Rud−2Dと平均転送速度Rext2D[0]との間の差Rud−2D−Rext2D[0]に等しい速度で増加する。
先頭の2DエクステントEXT2D[0]の後端が読み出された時に最初のジャンプJ2D[0]が生じる。そのジャンプ期間PJ2D[0]では、後続の二つのデータ・ブロックD1、R1の読み出しがスキップされるので、記録媒体100からのデータの読み出しが停止する。従って、最初のジャンプ期間PJ2D[0]では、図63の(a)に示されているように、蓄積データ量DAは平均転送速度Rext2D[0]で減少する。
ここで、次の場合を想定する:最初の読み出し期間PR2D[0]にリード・バッファ4602に蓄積されたデータ量、すなわち先頭の2DエクステントEXT2D[0]のサイズSext2D[0]が、その読み出し期間PR2D[0]から最初のジャンプ期間PJ2D[0]にわたってリード・バッファ4602からシステム・ターゲット・デコーダ4603へ転送されるデータ量に等しい。その場合、図63の(a)に示されているように、蓄積データ量DAは最初のジャンプ期間PJ2D[0]の終了時、最初の読み出し期間PR2D[0]の開始時での値を下回らない。
最初のジャンプJ2D[0]に続いて次のベースビュー・データ・ブロックL1、すなわち2DエクステントEXT2D[1]の読み出しが開始される。その読み出し期間PR2D[1]では、図63の(a)に示されているように、蓄積データ量DAは、データ転送速度の差Rud−2D−Rext2D[1]に等しい速度で再び増加する。
実際には、BD−ROMドライブ4601は読み出し/転送動作を、図63の(a)に示されているように連続的にではなく断続的に行う。それにより、各2Dエクステントの読み出し期間PR2D[0]、PR2D[1]、…に蓄積データ量DAがリード・バッファ4602の容量を超えないように、すなわちリード・バッファ4602がオーバーフローを生じないようにする。従って、図63の(a)のグラフは、実際には階段状である増減を直線的な増減として近似的に表したものである。
以上のように、2D再生モードでは再生経路5520に従い、2DエクステントLn=EXT2D[n](n=0、1、2、…)の読み出しと、一対のディペンデントビュー・データ・ブロックDn、Rnの記録領域を越えるジャンプJ2D[n]とが交互に繰り返される。それに伴い、リード・バッファ4602の蓄積データ量DAは、読み出し期間PR2D[n]では速度Rud−2D−Rext2D[n]で増加し、ジャンプ期間PJ2D[n]では速度Rext2D[n]で減少する。従って、それらの2DエクステントEXT2D[n]から2D映像をシームレスに再生するには、以下の条件[1]、[2]が満たされればよい。
[1]各ジャンプ期間PJ2D[n]でリード・バッファ4602からシステム・ターゲット・デコーダ4603へのデータ供給を維持して、そのデコーダ4603の連続的な出力を確保する必要がある。図63の(a)から明らかなとおり、各読み出し期間PR2D[n]にリード・バッファ4602に蓄積されるデータ量、すなわち各2DエクステントEXT2D[n]のサイズSext2D[n]が、その読み出し期間PR2D[n]から次のジャンプ期間PJ2D[n]にわたってリード・バッファ4602からシステム・ターゲット・デコーダ4603へ転送されるデータ量に等しければ、そのジャンプ期間PJ2D[n]の途中で蓄積データ量DAがその読み出し期間PR2D[n]の直前の値まで戻ることはない。特にリード・バッファ4602はアンダーフローを生じない。ここで、読み出し期間PR2D[n]の長さは、2DエクステントEXT2D[n]のサイズSext2D[n]を読み出し速度Rud−2Dで割った値Sext2D[n]/Rud−2Dに等しい。従って、各2DエクステントEXT2D[n]のサイズSext2D[n]は次式(1)を満たせばよい:
式(1)では、ジャンプ時間T
jump−2D[n]はジャンプ期間PJ
2D[n]の長さであり、秒単位で表される。一方、読み出し速度R
ud−2Dと平均転送速度R
ext2Dとはいずれもビット/秒で表される。従って、式(1)では平均転送速度R
ext2Dを数「8」で割り、2DエクステントのサイズS
ext2D[n]の単位をビットからバイトへ変換している。すなわち、2DエクステントのサイズS
ext2D[n]はバイト単位で表される。関数CEIL()は、括弧内の数値の小数点以下の端数を切り上げる操作を意味する。
[2]リード・バッファ4602の容量は有限であることから、ジャンプ時間Tjump−2D[n]の最大値は制限される。すなわち、ジャンプ期間PJ2D[n]の直前に蓄積データ量DAがリード・バッファ4602の容量一杯であっても、ジャンプ時間Tjump−2D[n]が長すぎれば、ジャンプ期間PJ2D[n]中に蓄積データ量DAが0に達し、リード・バッファ4602のアンダーフローが生じる危険性がある。以下、記録媒体100からリード・バッファ4602へのデータ供給が途絶えている状態で蓄積データ量DAがリード・バッファ4602の最大容量から0に到達するまでの時間、すなわち、シームレス再生を保証できるジャンプ時間Tjump−2Dの最大値を「最大ジャンプ時間」という。
光ディスクの規格では通常、ジャンプ距離と最大ジャンプ時間との間の関係が光ディスクドライブのアクセス・スピード等から決められている。図64は、BD−ROMディスクに関するジャンプ距離Sjumpと最大ジャンプ時間Tjumpとの間の対応表の一例である。図64では、ジャンプ距離Sjumpはセクタ単位で表され、最大ジャンプ時間Tjumpはm秒単位で表されている。ここで、1セクタ=2048バイトとする。図64を参照するに、ジャンプ距離Sjumpが、0セクタ、1−10000セクタ、10001−20000セクタ、20001−40000セクタ、40001セクタ−1/10ストローク、及び1/10ストローク以上の各範囲に属するとき、最大ジャンプ時間Tjumpはそれぞれ、50m秒、250m秒、300m秒、350m秒、700m秒、及び1400m秒である。
ジャンプ距離Sjumpが0セクタに等しいときの最大ジャンプ時間を特に「ゼロ・セクタ遷移時間Tjump−0」という。「ゼロ・セクタ遷移」とは、二つの連続するデータ・ブロック間での光ピックアップの移動をいう。ゼロ・セクタ遷移期間では光ピックアップは読み出し動作を一旦停止して待機する。ゼロ・セクタ遷移時間は、記録媒体100の回転による光ピックアップの位置の移動時間の他に、誤り訂正処理に伴うオーバーヘッドを含んでもよい。「誤り訂正処理に伴うオーバーヘッド」とは、二つの連続するデータ・ブロック間の境界がECCブロック間の境界と一致していないときに、そのECCブロックを用いた誤り訂正処理が二回行われることに起因する余分な時間をいう。誤り訂正処理には一つのECCブロックの全体が必要である。従って、一つのECCブロックが二つの連続するデータ・ブロックに共有されているとき、いずれのデータ・ブロックの読み出し処理でもそのECCブロックの全体が読み出されて誤り訂正処理に利用される。その結果、それらのデータ・ブロックを一つ読み出すごとに、そのデータ・ブロックの他に最大32セクタの余分なデータが読み出される。誤り訂正処理に伴うオーバーヘッドは、その余分なデータの読み出し時間の合計、すなわち32[セクタ]×2048[バイト]×8[ビット/バイト]×2[回]/読み出し速度Rud−2Dで評価される。尚、各データ・ブロックをECCブロック単位で構成することにより、誤り訂正処理に伴うオーバーヘッドをゼロ・セクタ遷移時間から除外してもよい。
記録媒体100が多層ディスクであるとき、層切り換えを伴うロングジャンプでは、図64に規定された最大ジャンプ時間Tjumpに加えて、フォーカス・ジャンプ等、その記録層の切り換え操作に特定の時間、例えば350m秒が更に必要である。以下、この時間を「層切換時間」という。
以上のことから、式(1)に代入されるべきジャンプ時間Tjump−2D[n]は二つのパラメータTJ[n]、TL[n]の和で決まる:Tjump−2D[n]=TJ[n]+TL[n]。第1パラメータTJ[n]は、BD−ROMディスクの規格によってジャンプ距離別に規定された最大ジャンプ時間を表す。第1パラメータTJ[n]は例えば図64の表において、n番目の2DエクステントEXT2D[n]の後端から(n+1)番目の2DエクステントEXT2D[n+1]の先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。第2パラメータTL[n]は、n番目の2DエクステントEXT2D[n]と(n+1)番目の2DエクステントEXT2D[n+1]との間に層境界LBがあるときは層切換時間、例えば350m秒を表し、層境界LBがないときは0を表す。例えばジャンプ時間Tjump−2D[n]の最大値が700m秒に制限されるとき、二つの2DエクステントEXT2D[n]、EXT2D[n+1]間のジャンプ距離は、それらの2Dエクステント間に層境界がないときは1/10ストローク(=約1.2GB)まで許され、層境界があるときは40000セクタ(=約78.1MB)まで許される。
≪3D再生モードに基づく条件≫
図65は、3D再生モードの再生装置200内の再生処理系統を示す模式図である。図65を参照するに、その再生処理系統は、図57に示されている要素のうち、BD−ROMドライブ4901、スイッチ4911、第1リード・バッファ4921、第2リード・バッファ4922、及びシステム・ターゲット・デコーダ4903を含む。BD−ROMドライブ4901は記録媒体100から3Dエクステントを読み出し、読み出し速度Rud−3Dでスイッチ4911へ転送する。スイッチ4911は各3Dエクステントからベースビュー・エクステントを抽出して、ディペンデントビュー・エクステントと分離する。ベースビュー・エクステントは第1リード・バッファ4921へ格納され、ディペンデントビュー・エクステントは第2リード・バッファ4922へ格納される。第2リード・バッファ4922内の蓄積データは、L/Rモードではライトビュー・エクステントであり、デプス・モードではデプスマップ・エクステントである。システム・ターゲット・デコーダ4903は、第1リード・バッファ4921内に蓄積された各ベースビュー・エクステントからソースパケットを第1平均転送速度Rext1で読み出す。L/Rモードのシステム・ターゲット・デコーダ4903は、第2リード・バッファ4922内に蓄積された各ライトビュー・エクステントからソースパケットを第2平均転送速度Rext2で読み出す。デプス・モードのシステム・ターゲット・デコーダ4903は、第2リード・バッファ4922内に蓄積された各デプスマップ・エクステントからソースパケットを第3平均転送速度Rext3で読み出す。システム・ターゲット・デコーダ4903は更に、読み出されたベースビュー・エクステントとディペンデントビュー・エクステントとの対を映像データVDと音声データADとに復号する。
第1平均転送速度Rext1を「ベースビュー転送速度」という。ベースビュー転送速度Rext1は、図58に示されている第1ソース・デパケタイザ5011から第1PIDフィルタ5013へのTSパケットの平均転送速度RTS1の192/188倍に等しく、一般にベースビュー・エクステントごとに異なる。ベースビュー転送速度Rext1の最高値Rmax1はファイル2Dに対するシステムレートの192/188倍に等しい。そのシステムレートは2Dクリップ情報ファイルに規定されている。ベースビュー転送速度Rext1は通常ビット/秒で表され、具体的には、ビット単位で表されたベースビュー・エクステントのサイズをエクステントATC時間で割ったときの値に等しい。エクステントATC時間は、そのベースビュー・エクステント内のソースパケットに付与されたATSの範囲を表す。従って、エクステントATC時間は、そのベースビュー・エクステント内のソースパケットを全て、第1リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送するのに要する時間に等しい。
第2平均転送速度Rext2を「ライトビュー転送速度」といい、第3平均転送速度Rext3を「デプスマップ転送速度」という。いずれの転送速度Rext2、Rext3も、第2ソース・デパケタイザ5012から第2PIDフィルタ5014へのTSパケットの平均転送速度RTS2の192/188倍に等しく、一般にディペンデントビュー・エクステントごとに異なる。ライトビュー転送速度Rext2の最高値Rmax2はライトビュービデオストリームを含むファイルDEPに対するシステムレートの192/188倍と等しく、デプスマップ転送速度Rext3の最高値Rmax3はデプスマップストリームを含むファイルDEPに対するシステムレートの192/188倍に等しい。各システムレートはライトビュー・クリップ情報ファイルとデプスマップ・クリップ情報ファイルとに規定されている。各転送速度Rext2、Rext3は通常ビット/秒で表され、具体的には、ビット単位で表されたディペンデントビュー・エクステントのサイズをエクステントATC時間で割ったときの値に等しい。エクステントATC時間は、各ディペンデントビュー・エクステント内のソースパケットに付与されたATSの範囲を表す。従って、エクステントATC時間は、そのディペンデントビュー・エクステント内のソースパケットを全て、第2リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送するのに要する時間に等しい。
読み出し速度Rud−3Dは通常ビット/秒で表され、第1−3平均転送速度Rext1−Rext3のいずれの最高値Rmax1−Rmax3よりも高い値、例えば72Mbpsに設定される:Rud−3D>Rmax1、Rud−3D>Rmax2、Rud−3D>Rmax3。それにより、BD−ROMドライブ4901によって記録媒体100から一つの3Dエクステントを読み出している間、システム・ターゲット・デコーダ4903の復号処理に伴う各リード・バッファ4921、4922のアンダーフローが防止される。
[L/Rモード]
図66の(a)、(b)は、L/Rモードでの3Dエクステント・ブロックの再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフである。図66の(c)は、その3Dエクステント・ブロック5810とL/Rモードでの再生経路5820との間の対応関係を示す模式図である。図66の(c)を参照するに、3Dエクステント・ブロック5810は、インターリーブ配置のベースビュー・データ・ブロック群とディペンデントビュー・データ・ブロック群とで構成されている。再生経路5820に従い、隣接するライトビュー・データ・ブロックRkとベースビュー・データ・ブロックLkとの各対(k=0、1、2、…)が一つの3DエクステントEXTSS[k]として読み出される。ここでは説明の便宜上、(n−1)個の3Dエクステントが既に読み出され、かつ整数nが1より十分に大きい場合を想定する。その場合、両リード・バッファ4921、4922の蓄積データ量DA1、DA2は既にそれぞれの下限値UL1、UL2以上に維持されている。それらの下限値UL1、UL2を「バッファ余裕量」という。バッファ余裕量UL1、UL2を確保するための方法については後述する。
図66の(c)を参照するに、第(2n−1)読み出し期間PRR[n]にn番目のライトビュー・エクステントRnが記録媒体100から第2リード・バッファ4922へ読み出される。第(2n−1)読み出し期間PRR[n]では、図66の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとライトビュー転送速度Rext2[n]との間の差Rud−3D−Rext2[n]に等しい速度で増加する。一方、図66の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少する。
n番目のライトビュー・エクステントRnの後端が読み出された時、n回目のゼロ・セクタ遷移J0[n]が生じる。第nゼロ・セクタ遷移期間PJ0[n]では、記録媒体100からのデータの読み出しが停止する。従って、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少し続け、第2リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少する。
第nゼロ・セクタ遷移期間PJ0[n]の終了時点から、第2n読み出し期間PRL[n]が開始される。第2n読み出し期間PRL[n]ではn番目のベースビュー・エクステントLnが記録媒体100から第1リード・バッファ4921へ読み出される。従って、図66の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1は、読み出し速度Rud−3Dとベースビュー転送速度Rext1[n]との間の差Rud−3D−Rext1[n]に等しい速度で増加する。一方、図66の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少し続ける。
n番目のベースビュー・エクステントLnの後端が読み出された時、n番目のジャンプJLR[n]が生じる。第nジャンプ期間PJLR[n]では(n+1)番目のデプスマップ・エクステントD(n+1)の読み出しがスキップされるので、記録媒体100からのデータの読み出しが停止する。従って、第nジャンプ期間PJLR[n]では、図66の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少する。一方、図66の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n]で減少し続ける。
ここで、次の場合を想定する:第(2n−1)読み出し期間PRR[n]に第2リード・バッファ4922に蓄積されるデータ量、すなわちn番目のライトビュー・エクステントRnのサイズSext2[n]は少なくとも、第(2n−1)読み出し期間PRR[n]から第nジャンプ期間PJLR[n]にわたって第2リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、ジャンプ期間PJLR[n]の終了時、図66の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2が第2バッファ余裕量UL2を下回らない。
第nジャンプ期間PJLR[n]の終了時点から第(2n+1)読み出し期間PRR[n+1]が開始される。第(2n+1)読み出し期間PRR[n+1]では、(n+1)番目のライトビュー・エクステントR(n+1)が記録媒体100から第2リード・バッファ4922へ読み出される。従って、図66の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとライトビュー転送速度Rext2[n+1]との間の差Rud−3D−Rext2[n+1]に等しい速度で増加する。一方、図66の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続ける。
(n+1)番目のライトビュー・エクステントR(n+1)の後端が読み出された時、(n+1)回目のゼロ・セクタ遷移J0[n+1]が生じる。第(n+1)ゼロ・セクタ遷移期間PJ0[n+1]では記録媒体100からのデータの読み出しが停止する。従って、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続け、第2リード・バッファ4922の蓄積データ量DA2はライトビュー転送速度Rext2[n+1]で減少する。
ここで、次の場合を想定する:第2n読み出し期間PRL[n]に第1リード・バッファ4921に蓄積されるデータ量、すなわちn番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第2n読み出し期間PRL[n]から第(n+1)ゼロ・セクタ遷移期間PJ0[n+1]にわたって第1リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第(n+1)ゼロ・セクタ遷移期間PJ0[n+1]の終了時、図66の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1が第1バッファ余裕量UL1を下回らない。
3DエクステントEXTSS[n]=Rn+Ln、EXTSS[n+1]=R(n+1)+L(n+1)、…から、それらの間のジャンプにかかわらず、3D映像をシームレスに再生するには、上記と同様な蓄積データ量DA1、DA2の変化が繰り返されればよい。それには、以下の条件[3]、[4]、[5]が満たされればよい。
[3]n番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第2n読み出し期間PRL[n]から第(n+1)ゼロ・セクタ遷移期間PJ0[n+1]にわたって第1リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第2n読み出し期間PRL[n]の長さは、n番目のベースビュー・エクステントLnのサイズSext1[n]を読み出し速度Rud−3Dで割った値Sext1[n]/Rud−3Dに等しい。第(2n+1)読み出し期間PRR[n+1]の長さは、(n+1)番目のライトビュー・エクステントR(n+1)のサイズSext2[n+1]を読み出し速度Rud−3Dで割った値Sext2[n+1]/Rud−3Dに等しい。従って、n番目のベースビュー・エクステントLnのサイズSext1[n]は次式(2)を満たせばよい:
[4]n番目のライトビュー・エクステントRnのサイズS
ext2[n]は少なくとも、第(2n−1)読み出し期間PR
R[n]から第nジャンプ期間PJ
LR[n]にわたって第2リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第(2n−1)読み出し期間PR
R[n]の長さは、n番目のライトビュー・エクステントRnのサイズS
ext2[n]を読み出し速度R
ud−3Dで割った値S
ext2[n]/R
ud−3Dに等しい。従って、n番目のライトビュー・エクステントRnのサイズS
ext2[n]は次式(3)を満たせばよい:
[5]式(2)、(3)に代入されるべきジャンプ時間T
jump−3D[n]は、式(1)に代入されるべきジャンプ時間T
jump−2D[n]とは異なり、第1パラメータTJ[n]だけで決まる:T
jump−3D[n]=TJ[n]。第1パラメータTJ[n]は例えば図64の表において、n番目のベースビュー・エクステントLnの後端から(n+1)番目のライトビュー・エクステントR(n+1)の先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。
[デプス・モード]
図67の(a)、(b)は、デプス・モードでの3Dエクステント・ブロック再生処理中、各リード・バッファ4921、4922に蓄積されるデータ量DA1、DA2の変化を示すグラフである。図67の(c)は、その3Dエクステント・ブロック5910とデプス・モードでの再生経路5920との間の対応関係を示す模式図である。図67の(c)を参照するに、3Dエクステント・ブロック5910は、図66の(c)に示されている3Dエクステント・ブロック5810と同様なインターリーブ配置のデータ・ブロック群で構成されている。再生経路5920に従い、デプスマップ・データ・ブロックDkとベースビュー・データ・ブロックDkとがそれぞれ、一つのエクステントとして読み出される(k=0、1、2、…)。図66の場合と同様、(n−1)個の3Dエクステントが既に読み込まれ、かつ整数nが1より十分に大きい場合を想定する。その場合、両リード・バッファ4921、4922の蓄積データ量DA1、DA2は既にそれぞれのバッファ余裕量UL1、UL2以上に維持されている。
図67の(c)を参照するに、第(2n−1)読み出し期間PRD[n]にn番目のデプスマップ・エクステントDnが記録媒体100から第2リード・バッファ4922へ読み出される。第(2n−1)読み出し期間PRD[n]では、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2は、読み出し速度Rud−3Dとデプスマップ転送速度Rext3[n]との間の差Rud−3D−Rext3[n]に等しい速度で増加する。一方、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少する。
n番目のデプスマップ・エクステントDnの後端が読み出された時、n回目のジャンプJLD[n]が生じる。第nジャンプ期間PJLD[n]では、n番目のライトビュー・エクステントRnの読み出しがスキップされるので、記録媒体100からのデータの読み出しが停止する。従って、第nジャンプ期間PJLD[n]では、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n−1]で減少し続ける。一方、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少する。
第nジャンプ期間PJLD[n]の終了時点から第2n読み出し期間PRL[n]が開始される。第2n読み出し期間PRL[n]では、n番目のベースビュー・エクステントLnが記録媒体100から第1リード・バッファ4921へ読み出される。従って、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1は、読み出し速度Rud−3Dとベースビュー転送速度Rext1[n]との間の差Rud−3D−Rext1[n]に等しい速度で増加する。一方、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少し続ける。
n番目のベースビュー・エクステントLnの後端が読み出された時、n回目のゼロ・セクタ遷移J0[n]が生じる。第nゼロ・セクタ遷移期間PJ0[n]では、記録媒体100からのデータの読み出しが停止する。従って、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し、第2リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n]で減少し続ける。
ここで、次の場合を想定する:第(2n−1)読み出し期間PRD[n]に第2リード・バッファ4922に蓄積されるデータ量、すなわちn番目のデプスマップ・エクステントDnのサイズSext3[n]は少なくとも、第(2n−1)読み出し期間PRD[n]から第nゼロ・セクタ遷移期間PJ0[n]にわたって第2リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第nゼロ・セクタ遷移期間PJ0[n]の終了時、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2が第2バッファ余裕量UL2を下回らない。
第nゼロ・セクタ遷移期間PJ0[n]の終了時点から第(2n+1)読み出し期間PRD[n+1]が開始される。第(2n+1)読み出し期間PRD[n+1]では(n+1)番目のデプスマップ・エクステントD(n+1)が記録媒体100から第2リード・バッファ4922へ読み出される。従って、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続ける。一方、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2は速度Rud−3D−Rext3[n+1]で増加する。
(n+1)番目のデプスマップ・エクステントD(n+1)の後端が読み出された時、(n+1)回目のジャンプJLD[n+1]が生じる。第(n+1)ジャンプ期間PJLD[n+1]では、(n+1)番目のライトビュー・エクステントR(n+1)の読み出しがスキップされるので、記録媒体100からのデータの読み出しが停止する。従って、第(n+1)ジャンプ期間PJLD[n+1]では、第1リード・バッファ4921の蓄積データ量DA1はベースビュー転送速度Rext1[n]で減少し続け、第2リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n+1]で減少する。
第(n+1)ジャンプ期間PJLD[n+1]の終了時点から第(2n+2)読み出し期間PRL[n+1]が開始される。第(2n+2)読み出し期間PRL[n+1]では、(n+1)番目のベースビュー・エクステントL(n+1)が記録媒体100から第1リード・バッファ4921へ読み出される。従って、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1は速度Rud−3D−Rext1[n+1]で増加する。一方、図67の(b)に示されているように、第2リード・バッファ4922の蓄積データ量DA2はデプスマップ転送速度Rext3[n+1]で減少し続ける。
ここで、次の場合を想定する:第2n読み出し期間PRL[n]に第1リード・バッファ4921に蓄積されるデータ量、すなわちn番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第2n読み出し期間PRL[n]から第(n+1)ジャンプ期間PJLD[n+1]にわたって第1リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。その場合、第(n+1)ジャンプ期間PJLD[n+1]の終了時、図67の(a)に示されているように、第1リード・バッファ4921の蓄積データ量DA1が第1バッファ余裕量UL1を下回らない。
デプスマップ・エクステントDn、D(n+1)、…とベースビュー・エクステントLn、L(n+1)、…とから、それらの間のジャンプにかかわらず、3D映像をシームレスに再生するには、上記と同様な蓄積データ量DA1、DA2の変化が繰り返されればよい。それには、以下の条件[6]、[7]、[8]が満たされればよい。
[6]n番目のベースビュー・エクステントLnのサイズSext1[n]は少なくとも、第2n読み出し期間PRL[n]から第(n+1)ジャンプ期間PJLD[n+1]にわたって第1リード・バッファ4921からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第2n読み出し期間PRL[n]の長さは、n番目のベースビュー・エクステントLnのサイズSext1[n]を読み出し速度Rud−3Dで割った値Sext1[n]/Rud−3Dに等しい。第(2n+1)読み出し期間PRD[n+1]の長さは、(n+1)番目のデプスマップ・エクステントD(n+1)のサイズSext3[n+1]を読み出し速度Rud−3Dで割った値Sext3[n+1]/Rud−3Dに等しい。従って、n番目のベースビュー・エクステントLnのサイズSext1[n]は次式(4)を満たせばよい:
[7]n番目のデプスマップ・エクステントDnのサイズS
ext3[n]は少なくとも、第(2n−1)読み出し期間PR
D[n]から第nゼロ・セクタ遷移期間PJ
0[n]にわたって第2リード・バッファ4922からシステム・ターゲット・デコーダ4903へ転送されるデータ量に等しい。ここで、第(2n−1)読み出し期間PR
D[n]の長さは、n番目のデプスマップ・エクステントDnのサイズS
ext3[n]を読み出し速度R
ud−3Dで割った値S
ext3[n]/R
ud−3Dに等しい。従って、n番目のデプスマップ・エクステントDnのサイズS
ext3[n]は次式(5)を満たせばよい:
[8]式(4)、(5)に代入されるべきジャンプ時間T
jump−3D[n]は、例えば図64の表において、n番目のデプスマップ・エクステントDnの後端からn番目のベースビュー・エクステントLnの先端までのセクタ数、すなわちジャンプ距離に対応する最大ジャンプ時間に等しい。尚、本発明の実施形態によるデータ・ブロック群の配置では、エクステントATC時間の等しいデプスマップ・エクステントDnとベースビュー・エクステントLnとの対が間に層境界を挟んで配置されることはない。
ゼロ・セクタ遷移時間Tjump−0[n]は、n番目のベースビュー・エクステントLnと(n+1)番目のデプスマップ・エクステントD(n+1)との間における層境界LBの有無に関わらず、実際のゼロ・セクタ遷移に要する時間のみで評価された規定値に等しい。
以上の結果、インターリーブ配置のデータ・ブロック群から、2D映像のシームレス再生、3D映像のL/Rモードでのシームレス再生、及び3D映像のデプス・モードでのシームレス再生のいずれも実現可能にするには、各データ・ブロックのサイズは上記の式(1)−(5)を全て満たすように設計されればよい。特にベースビュー・データ・ブロックのサイズは、式(1)、(2)、及び(4)の各右辺の中で最大のもの以上であればよい。以下、式(1)−(5)を全て満たすデータ・ブロックのサイズの下限値を「最小エクステント・サイズ」という。
<リード・バッファの余裕量>
図66、67の各(a)、(b)に示されている各リード・バッファ4921、4922の蓄積データ量DA1、DA2の下限値UL1、UL2はそれぞれのバッファ余裕量を表す。「バッファ余裕量」とは、一つの3Dエクステント・ブロック、すなわちインターリーブ配置の一連のデータ・ブロック群の読み出し期間中、各リード・バッファに維持されるべき蓄積データ量の下限値をいう。ストリーム・データの読み出し中に、読み出し対象の記録層が切り換えられるとき、又は他のファイルの読み出し処理が割り込まれたとき、異なる3Dエクステント・ブロック間でロングジャンプが生じる。ここで、上記の他のファイルは、AVストリーム・ファイル以外のファイル、例えば、ムービーオブジェクト・ファイル、BD−Jオブジェクト・ファイル、及びJARファイルを含む。ロングジャンプは、式(2)−(5)の導出で考慮された一つの3Dエクステント・ブロック内で生じるジャンプよりも長い。更に、他のファイルの読み出し処理の割り込みに起因するロングジャンプでは、その発生時期が不定であり、特に一つのデータ・ブロックの読み出し途中でも生じ得る。従って、式(2)−(5)にロングジャンプの最大ジャンプ時間を代入して最小エクステント・サイズを設定するよりも、バッファ余裕量を、ロングジャンプ中での各リード・バッファのアンダーフローを防ぐことのできる量に維持しておく方が有利である。
図68は、L/Rモードでの再生処理中に生じるロングジャンプJLY、JBDJ1、JBDJ2を示す模式図である。図68を参照するに、層境界LBの前に位置する第1記録層には、第1の3Dエクステント・ブロック6001が配置され、その後端L3と層境界LBとの間には2D再生専用ブロックL42Dが配置されている。一方、層境界LBの後に位置する第2記録層には第2の3Dエクステント・ブロック6002が配置されている。更に、いずれの3Dエクステント・ブロック6001、6002からも離れた領域にBD−Jオブジェクト・ファイル6003が記録されている。第1の3Dエクステント・ブロック6001から第2の3Dエクステント・ブロック6002への再生処理では、層切り換えに伴うロングジャンプJLYが生じる。一方、第1の3Dエクステント・ブロック6001の読み出し中にBD−Jオブジェクト・ファイル6003の読み出し処理が割り込まれたとき、一対のロングジャンプJBDJ1、JBDJ2が生じる。各ロングジャンプJLY、JBDJに対して必要なバッファ余裕量UL1、UL2は以下のように計算される。
層切り換えに伴うロングジャンプJLYの最大ジャンプ時間Tjump−LYは、図64の表において第1ロングジャンプJLYのジャンプ距離に対応する最大ジャンプ時間と層切換時間との和に等しい。そのジャンプ距離は、第1の3Dエクステント・ブロック6001内の最後のベースビュー・データ・ブロックL3の後端と、第2の3Dエクステント・ブロック6002内の先頭のライトビュー・データ・ブロックR4の先端との間のセクタ数に等しい。一方、ベースビュー転送速度Rext1は最高値Rmax1を超えない。従って、そのロングジャンプJLYの期間に第1リード・バッファ4921から消費されるデータ量は、ベースビュー転送速度の最高値Rmax1と最大ジャンプ時間Tjump−LYとの積を超えない。その積の値が第1バッファ余裕量UL1として決定される。すなわち、第1バッファ余裕量UL1は次式(6)で計算される:
例えばジャンプ距離が40000セクタであるとき、図64の表によれば、最大ジャンプ時間T
jump−LYは、層切換時間350m秒を含めて700m秒である。従って、ファイル2Dに対するシステムレートが48Mbpsであるとき、第1バッファ余裕量UL1は(48Mbps×192/188)×0.7秒=約4.09MBに等しい。
同様に、ロングジャンプJLYの期間に第2リード・バッファ4922から消費されるデータ量の最大値、すなわちライトビュー転送速度の最大値Rmax2と最大ジャンプ時間Tjump−LYとの積が第2バッファ余裕量UL2として決定される。すなわち、第2バッファ余裕量UL2は次式(7)で計算される:
例えばジャンプ距離が40000セクタであり、すなわち最大ジャンプ時間T
jump−LYが700m秒であり、第1ファイルDEPに対するシステムレートが16Mbpsであるとき、第2バッファ余裕量UL2は(16Mbps×192/188)×0.7秒=約1.36MBに等しい。
図68を再び参照するに、第1の3Dエクステント・ブロック6001の読み出し期間にBD−Jオブジェクト・ファイル6003の読み出し処理の割り込みが生じたとき、最初のロングジャンプJBDJ1が生じる。それにより、読み出し対象の位置が第2ベースビュー・データ・ブロックL2の記録領域からBD−Jオブジェクト・ファイル6003の記録領域へ移動する。そのジャンプ時間TBDJは一定値、例えば900m秒に予め規定されている。次に、BD−Jオブジェクト・ファイル6003が読み出される。その読み出しに要する時間は、そのファイル6003に属するエクステントのサイズSBDJの8倍を読み出し速度Rud−3Dで割った値8×SBDJ[n]/Rud−3Dに等しい(通常、エクステントのサイズSBDJはバイト単位で表され、読み出し速度Rud−3Dはビット/秒で表されるので、8倍が必要である)。続いて、2回目のロングジャンプJBDJ2が生じる。それにより、読み出し対象の位置がBD−Jオブジェクト・ファイル6003の記録領域から第2ベースビュー・データ・ブロックL2の記録領域へ戻る。そのジャンプ時間TBDJは最初のジャンプ時間、例えば900m秒に等しい。計2回のロングジャンプJBDJ1、JBDJ2とBD−Jオブジェクト・ファイル6003の読み出しとが行われる間、第1リード・バッファ4921にはデータが読み込まれない。従って、その期間に第1リード・バッファ4921から消費されるデータ量の最大値が第1バッファ余裕量UL1として決定される。すなわち、第1バッファ余裕量UL1は次式(8)で計算される:
同様に、2回のロングジャンプJ
BDJ1、J
BDJ2とBD−Jオブジェクト・ファイル6003の読み出しとが行われる間に第2リード・バッファ4922から消費されるデータ量の最大値が第2バッファ余裕量UL2として決定される。すなわち、第2バッファ余裕量UL2は次式(9)で計算される:
第1バッファ余裕量UL1は、式(6)、(8)の右辺で表される値のいずれか大きい方に設定される。第2バッファ余裕量UL2は、式(7)、(9)の右辺で表される値のいずれか大きい方に設定される。
<リード・バッファの最小容量>
図66、67の各(c)に示されている一連の3Dエクステント・ブロックからの再生処理については、各リード・バッファ4921、4922に必要な容量の最小値は以下のように計算される。
3D再生モードでn番目のベースビュー・データ・ブロックLn(n=0、1、2、…)を読み出すとき、第1リード・バッファ4921に必要な容量RB1[n]は、図66、67の各(a)に示されているグラフのピークのうち、最も高い値以上であればよい。ここで、読み出し対象のベースビュー・データ・ブロックのサイズSext1が一定であれば、ベースビュー転送速度Rext1が最高値Rmax1に等しいときにピーク値は最も高い。従って、その容量RB1[n]は、L/Rモードとデプス・モードとのいずれでも、次式(10)を満たせばよい:
L/Rモードでn番目のライトビュー・データ・ブロックRnを読み出すとき、第2リード・バッファ4922に必要な容量RB2
LR[n]は、図66の(b)に示されているグラフのピークのうち、最も高い値以上であればよい。ここで、読み出し対象のライトビュー・データ・ブロックのサイズS
ext2が一定であれば、ライトビュー転送速度R
ext2が最高値R
max2に等しいときにピーク値は最も高い。従って、その容量RB2
LR[n]は次式(11)を満たせばよい:
ここで、ライトビュー・データ・ブロックはいずれも、飛び込み再生によって最初に読み出される可能性を持つ。その場合、最初に読み出されるライトビュー・データ・ブロックの全体が第2リード・バッファ4922に格納されるまでシステム・ターゲット・デコーダ4903は第2リード・バッファ4922からデータを読み出さない。従って、第2リード・バッファ4922の容量RB2
LR[n]は第1リード・バッファ4921の容量RB1[n]とは異なり、「少なくともn番目のライトビュー・データ・ブロックRnのサイズS
ext2[n]よりも大きい」という条件を更に満たす。
同様に、デプス・モードでn番目のデプスマップ・データ・ブロックDnを読み出すときに必要な第2リード・バッファ4922の容量RB2LD[n]は次式(12)を満たせばよい:
<層境界前後での再生経路の分離の効果>
本発明の実施形態による記録媒体100では、層境界の前後のデータ・ブロック群が、図20、24、26、28、30、32のそれぞれに示されている配置1−6のいずれかで記録されている。それにより、層切り換えの前後ではベースビュー・ビデオ・ストリームの特定部分が、2D再生モードでは2D再生専用ブロックLn
2Dから再生され、3D再生モードでは3D再生専用ブロックLn
SSから再生される。その場合、図22に示されている配置とは異なり、その特定部分を格納した2DエクステントのサイズS
ext2Dは、ベースビュー・エクステントのサイズS
ext1と2D再生専用ブロックLn
2Dのサイズとの和に等しい。式(1)はその和S
ext2Dによって満たされればよい一方、式(2)−(5)は2D再生専用ブロックLn
2D以外のデータ・ブロックのサイズによって満たされればよい。従って、2D再生専用ブロックLn
2Dのサイズの調節によって、2Dエクステントの全体のサイズS
ext2Dが式(1)を満たすこととは実質上独立に、式(2)−(5)を満たすディペンデントビュー・エクステントのサイズS
ext2、S
ext3の下限値、すなわち最小エクステント・サイズが更に縮小可能である。それ故、式(11)、(12)から明らかなとおり、第2リード・バッファ4922の最小容量RB2
LR、RB2
LDが、式(1)とは実質上独立に、更に削減可能である。
<3Dエクステント・ブロック内のエクステントATC時間>
3Dエクステント・ブロック、すなわち、インターリーブ配置のデータ・ブロック群では、隣接するデータ・ブロックDn、Rn、Ln(n=0、1、2、…)がいずれも同じエクステントATC時間を持つ。言い換えれば、各データ・ブロックの先頭のソースパケットから次のデータ・ブロックの先頭のソースパケットまでのATSの差が等しい。但し、その差の計算では、ATSにラップ・アラウンドが発生することが考慮されている。その場合、ATCで計られる同じ時間内に、第1ソース・デパケタイザ5011はベースビュー・データ・ブロックLn内の全てのソースパケットからTSパケットを取り出して第1PIDフィルタ5013へ送出し、第2ソース・デパケタイザ5012はディペンデントビュー・データ・ブロックDn又はRn内の全てのソースパケットからTSパケットを取り出して第2PIDフィルタ5014へ送出する。従って、特に飛び込み再生時、主映像デコーダ5015はベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとの間でTSパケットの復号処理を容易に同期させることができる。
<エクステントATC時間を用いたエクステント・サイズの条件式>
式(2)−(5)では、ベースビュー・エクステントとディペンデントビュー・エクステントとの各サイズが、それよりも後方に位置するエクステントのサイズで制限される。しかし、オーサリング工程での利用という観点からは、各エクステントのサイズに対する条件が、他のエクステントのサイズには依存しない形で表現されていることが望ましい。従って、式(2)−(5)は、以下のように、エクステントATC時間を利用した条件式に表現し直される。
上記のとおり、隣接する三つのエクステントDn、Rn、Ln(n=0、1、2、…)はいずれも同じエクステントATC時間Text[n]を持つ。それらのエクステントATC時間の最小値を最小エクステントATC時間minTextとし、最大値を最大エクステントATC時間maxTextとする:minText≦Text[n]≦maxText。その場合、n番目の各エクステントEXT1[n]、EXT2[n]、EXT3[n]のサイズSext1[n]、Sext2[n]、Sext3[n]は次式(13)、(14)、(15)の範囲に制限される:
CEIL(Rext1[n]×minText/8)≦Sext1[n]≦CEIL(Rext1[n]×maxText/8)、 (13)
CEIL(Rext2[n]×minText/8)≦Sext2[n]≦CEIL(Rext2[n]×maxText/8)、 (14)
CEIL(Rext3[n]×minText/8)≦Sext3[n]≦CEIL(Rext3[n]×maxText/8)。 (15)
続いて、最大エクステントATC時間maxTextと最小エクステントATC時間minTextとの間の差を一定値Tmとする:maxText=minText+Tm。その場合、最小エクステントATC時間minTextは最小エクステント・サイズ、すなわち式(2)−(5)の各右辺を利用して、以下のように算定される。
n番目のベースビュー・エクステントのサイズが最小エクステント・サイズに等しいとき、式(2)、(13)から最小エクステントATC時間minTextは次式(16)を満たす:
(n+1)番目のライトビュー・エクステントのサイズS
ext2[n+1]は、ライトビュー転送速度R
ext2の最高値R
max2と最大エクステントATC時間maxT
extとの積まで許される:S
ext2[n+1]≦R
max2×maxT
ext=R
max2×(minT
ext+Tm)。更に、ベースビュー転送速度R
ext1[n]は最高値R
max1を超えない:R
ext1[n]≦R
max1。最小エクステントATC時間minT
extは式(16)の右辺の上限であるべきなので、次式(17)を満たすべきである:
式(2)に代えて式(4)を同様に変形すれば、最小エクステントATC時間minT
extは次式(18)を更に満たすべきである:
一方、n番目のベースビュー・エクステントのサイズが最小エクステント・サイズに等しいとき、そのエクステントATC時間T
ext[n]が最小エクステントATC時間minT
extに等しい。n番目のライトビュー・エクステントはn番目のベースビュー・エクステントとエクステントATC時間が共通であるので、式(3)、(14)から、最小エクステントATC時間minT
extは次式(19)を満たす:
ライトビュー転送速度R
ext2[n]は最高値R
max2を超えず、ベースビュー転送速度R
ext1[n]は最高値R
max1を超えない:R
ext2[n]≦R
max2、R
ext1[n]≦R
max1。最小エクステントATC時間minT
extは式(19)の右辺の上限であるべきなので、次式(20)を満たすべきである:
式(3)に代えて式(5)を利用すれば同様にして、最小エクステントATC時間minT
extが次式(21)を満たすべきである:
以上の結果、最小エクステントATC時間minT
extは、式(17)、(18)、(20)、(21)の各右辺の中での最大値として定義される。ここで、ゼロ・セクタ遷移時間T
jump−0、ジャンプ時間T
jump−3D、及びエクステントATC時間の変動幅Tmは予め一定に制限できる。特に、後述の変形例(F)と同様、最大ジャンプ距離MAX_EXTJUMP3Dを利用してジャンプ時間T
jump−3Dを評価してもよい。それにより、最小エクステントATC時間minT
extは実質上、平均転送時間の最大値R
max等の定数だけで決定可能である。従って、式(13)−(15)で表されたエクステント・サイズに対する条件はオーサリング工程での利用に有利である。
<バッファ余裕量の確保>
各バッファ余裕量UL1、UL2は、以下に述べるように確保される。まず、各データ・ブロックの設計では「エクステントATC時間Textが最小エクステントATC時間minText以上である」という条件が課される。ここで、最小エクステントATC時間minTextは、式(17)、(18)、(20)、(21)に示されているとおり、平均転送速度Rext1、Rext2、Rext3がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での値である。しかし、実際の平均転送速度Rext1、Rext2、Rext3はそれぞれの最高値Rmax1、Rmax2、Rmax3よりも一般に低い。従って、実際のデータ・ブロックのサイズRext1×Text、Rext2×Text、Rext3×Textは、上記の条件下で想定される値Rmax1×Text、Rmax2×Text、Rmax3×Textよりも一般に小さい。それ故、各データ・ブロックの読み出し開始からエクステントATC時間Textが経過する前に、次のデータ・ブロックの読み出しが開始される。すなわち、各リード・バッファ4921、4922の蓄積データ量DA1、DA2は実際には、図66、67の(a)、(b)に示されているものとは一般に異なり、読み出し開始時の値まで戻る前に再び増加する。こうして、各蓄積データ量DA1、DA2は、ベースビューとディペンデントビューとのデータ・ブロックの対が一つ読み出されるごとに所定量ずつ増える。その結果、ある程度の数のデータ・ブロックが各リード・バッファ4921、4922に連続して読み込まれることにより、各バッファ余裕量UL1、UL2が確保される。
図69の(a)は、3Dエクステント・ブロック6110とL/Rモードでの再生経路6120との間の対応関係を示す模式図である。図69の(a)を参照するに、3Dエクステント・ブロック6110はインターリーブ配置のベースビュー・データ・ブロック群Lkとディペンデントビュー・データ・ブロック群Dk、Rk(k=0、1、2、…)とで構成されている。再生経路6120に従い、隣接するライトビュー・データ・ブロックRkとベースビュー・データ・ブロックLkとの各対が一つの3Dエクステント、すなわちディペンデントビュー・エクステントとベースビュー・エクステントとの対として読み出される。ベースビュー・エクステントLkのエクステント・サイズSext1[k]はベースビュー転送速度Rext1[k]とエクステントATC時間Text[k]との積に等しい:Sext1[k]=Rext1[k]×Text[k]。このエクステント・サイズSext1[k]は、ベースビュー転送速度の最高値Rmax1とエクステントATC時間Text[k]との積よりも一般に小さい:Sext1[k]<Rmax1×Text[k]。ディペンデントビュー・エクステントDk、Rkのエクステント・サイズSext3[k]、Sext2[k]についても同様である。
図69の(b)は、3Dエクステント・ブロック6110がL/Rモードでの再生経路6120に従って読み出されるときにおける第1リード・バッファ4921の蓄積データ量DA1の変化を示すグラフである。細い実線のグラフは、平均転送速度Rext1[k]、Rext2[k]、Rext3[k]がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での変化を示す。一方、太い実線のグラフは、先頭のベースビュー・エクステントL0の転送速度Rext1[0]が最高値Rmax1よりも低い場合での変化を示す。尚、説明の便宜上、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合を想定する。その場合、ディペンデントビュー・エクステントのサイズRext2[k]×Text[k]、Rext3[k]×Text[k]は想定可能な最大値Rmax2×Text[k]、Rmax3×Text[k]に等しい。
図69の(b)を参照するに、細い実線のグラフでは、先頭のベースビュー・エクステントL0の読み出し開始からエクステントATC時間Text[0]が経過したとき、次のベースビュー・エクステントL1の読み出しが開始される。従って、そのときの蓄積データ量DA1は読み出し開始時の値DM10と実質的に等しい。一方、太い実線のグラフでは、先頭のベースビュー・エクステントL0の全体が記録媒体100から第1リード・バッファ4921へ読み出されるのに時間Sext1[0]/Rud−3Dが必要である。その時間は細い実線のグラフでの時間Rmax1×Text[0]/Rud−3Dよりも時間ΔTbだけ短い:ΔTb=Sext1[0]/Rud−3D−Rmax1×Text[0]/Rud−3D=(Rext1[0]−Rmax1)×Text[0]/Rud−3D。従って、太い実線のグラフでは細い実線のグラフよりも蓄積データ量DA1が時間ΔTbだけ早くピークに達する。一方、各ディペンデントビュー・エクステントD1、R1のサイズSext2[1]、Sext3[1]は両方のグラフで共通の値Rmax2×Text[1]、Rmax3×Text[1]である。従って、蓄積データ量DA1のピークから次のベースビュー・エクステントL1の読み出し開始までの時間ΔTは両方のグラフで共通である。その結果、太い実線のグラフでは細い実線のグラフとは異なり、先頭のベースビュー・エクステントL0の読み出し開始からエクステントATC時間Textが経過するよりも時間ΔTbだけ早く、次のベースビュー・エクステントL1の読み出しが開始される。それ故、その時点での蓄積データ量DA1の値DM11は先頭のベースビュー・エクステントL0の読み出し開始時の値DM10よりも増分DM1[0]だけ増加する。図69の(b)から明らかなとおり、この増分DM1[0]は蓄積データ量DA1の実際の減少速度Rext1[0]と時間ΔTbとの積に等しい:DM1[0]=Rext1[0]×ΔTb=Rext1[0]×(Rext1[0]−Rmax1)×Text[0]/Rud−3D。
図69の(c)は、図69の(b)に示されている変化を第1リード・バッファ4921の蓄積データ量DA1が示すときにおける第2リード・バッファ4922の蓄積データ量DA2の変化を示すグラフである。細い実線のグラフは、平均転送速度Rext1[k]、Rext2[k]、Rext3[k]がそれぞれの最高値Rmax1、Rmax2、Rmax3に等しい場合での変化を示す。一方、太い実線のグラフは、先頭のベースビュー・エクステントL0の転送速度Rext1[0]が最高値Rmax1よりも低い場合での変化を示す。尚、説明の便宜上、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合を想定する。
図69の(c)を参照するに、細い実線のグラフでは、先頭のライトビュー・エクステントR0の読み出し開始からエクステントATC時間Text[0]が経過したとき、次のライトビュー・エクステントR1の読み出しが開始される。従って、そのときの蓄積データ量DA2は読み出し開始時の値DM20と実質的に等しい。一方、太い実線のグラフでは細い実線のグラフよりも時間ΔTbだけ早く、先頭のベースビュー・エクステントL0の全体が記録媒体100から第1リード・バッファ4921へ読み出される。従って、太い実線のグラフでは細い実線のグラフよりも時間ΔTbだけ早く、すなわち先頭のライトビュー・エクステントR0の読み出し開始からエクステントATC時間Textが経過するよりも時間ΔTbだけ前に、次のライトビュー・エクステントR1の読み出しが開始される。それ故、その時点での蓄積データ量DA2の値DM21は、先頭のライトビュー・エクステントR0の読み出し開始時の値DM20よりも増分DM2[0]だけ増加する。図69の(c)から明らかなとおり、この増分DM2[0]は蓄積データ量DA2の実際の減少速度Rext2[0]と時間ΔTbとの積に等しい:DM2[0]=Rext2[0]×ΔTb=Rext2[0]×(Rext1[0]−Rmax1)×Text[0]/Rud−3D。
図69では、ディペンデントビュー転送速度Rext2[k]、Rext3[k]はそれぞれの最高値Rmax2、Rmax3に等しい場合が想定されている。しかし、実際には、ディペンデントビュー転送速度Rext2[k]、Rext3[k]も一般に、それぞれの最高値Rmax2、Rmax3よりも低い。その場合、図69の(c)のグラフでは図69の(b)のグラフと同様に、蓄積データ量DA2が時間ΔTdだけピークに早く到達する:ΔTd=Sext2[0]/Rud−3D−Rmax2×Text[0]/Rud−3D=(Rext2[0]−Rmax2)×Text[0]/Rud−3D。一方、図69の(b)のグラフでは、蓄積データ量DA1のピークから次のベースビュー・エクステントL1の読み出し開始までの時間ΔTが同じ時間ΔTdだけ短縮される。それらを考慮した場合、ベースビュー・エクステントLkとライトビュー・エクステントRkとの対が一つ処理されるごとに、各リード・バッファの蓄積データ量DA1、DA2は、次式(22)、(23)で表される増分DM1[k]、DM2[k]だけ増加する:
DM1[k]=Rext1[k]×(ΔTb+ΔTd)
=Rext1[k]×{(Rext1[k]−Rmax1)+(Rext2[k]−Rmax2)}×Text[k]/Rud−3D、 (22)
DM2[k]=Rext2[k]×(ΔTb+ΔTd)
=Rext2[k]×{(Rext1[k]−Rmax1)+(Rext2[k]−Rmax2)}×Text[k]/Rud−3D。
(23)
L/Rモードでは、各3DエクステントEXTSS[k]からベースビュー・エクステントLkとライトビュー・エクステントRkとが各リード・バッファ4921、4922に読み込まれるごとに各蓄積データ量DA1、DA2は増分DM1[k]、DM2[k]ずつ増える。デプス・モードでも同様に、ベースビュー・エクステントLkとデプスマップ・エクステントDkとが各リード・バッファ4921、4922に読み込まれるごとに各蓄積データ量DA1、DA2は増分DM3[k]、DM4[k]ずつ増える。ここで、増分DM3[k]、DM4[k]は次式(24)、(25)で表される:
DM3[k]=Rext1[k]×{(Rext1[k]−Rmax1)+(Rext3[k]−Rmax3)}×Text[k]/Rud−3D、 (24)
DM4[k]=Rext3[k]×{(Rext1[k]−Rmax1)+(Rext3[k]−Rmax3)}×Text[k]/Rud−3D。
(25)
従って、3Dエクステント・ブロック6110全体でのエクステントATC時間の合計Tsum=Text[0]+Text[1]+Text[2]+…が次式(26)を満たすとき、その3Dエクステント・ブロック6110の全体の読み出しによって各リード・バッファ4921、4922にバッファ余裕量UL1、UL2を確保することができる:
ここで、次の近似が用いられている:3Dエクステント・ブロック6110の全体で、ベースビュー転送速度R
ext1[k]が平均値R
ext1−avに等しく、ディペンデントビュー転送速度R
ext2[k]、R
ext3[k]が平均値R
ext2−av、R
ext3−avに等しい。
尚、一連の3Dエクステント・ブロックの読み出し期間では、ロングジャンプが生じない限り、各リード・バッファの蓄積データ量DA1、DA2は増え続ける。従って、各蓄積データ量DA1、DA2が所定の閾値を超えた場合、再生装置200はBD−ROMドライブ4901に読み出し/転送動作を断続させる。それにより、読み出し速度Rud−3Dが低下するので、各蓄積データ量DA1、DA2の増加が抑えられる。こうして、各リード・バッファ4921、4922のオーバーフローを回避することができる。
(バッファ余裕量の蓄積方法1)
次に、リードバッファに確保される層切り替えジャンプなどのためのバッファ余裕量のAV再生中の蓄積方法について説明する。
3Dエクステントブロック間のシームレス接続のための配置方法の説明において、3Dエクステントブロック間のシームレス接続のために、3Dエクステントブロック間のジャンプの場合には、第1リード・バッファ4921にジャンプ前に蓄積されたバッファ余裕量UL1と、第2リード・バッファ4922にジャンプ前に確保されるバッファ余裕量UL2を消費して、3D映像の再生を継続すると説明した。
この第1リード・バッファ4921のバッファ余裕量UL1と第2リード・バッファ4922のバッファ余裕量UL2は、3D映像の再生開始時にバッファリングして蓄えると説明したが、例えば図70のように3Dエクステントブロックが3つ以上シームレスに接続する場合には、1回目の3Dエクステントブロック間のジャンプ時にバッファ余裕量UL1,UL2を消費してしまうため、2回目の3Dエクステントブロック間のジャンプ時にバッファ余裕量がなくなってしまうため、リードバッファのバッファアンダーフローが発生して、シームレス再生できないことになってしまう。
そのため、3Dエクステントブロックが、ある3Dエクステントブロックからシームレスに接続され、かつ、ある3Dエクステントブロックにシームレスに接続する場合には、3D映像を再生中しながら、第1リード・バッファ4921と第2リード・バッファ4922にバッファ余裕量UL1、UL2を、3Dエクステントブロック間のジャンプ前までに蓄積する必要がある。この、ある3Dエクステントブロックからシームレスに接続され、かつ、ある3Dエクステントブロックにシームレスに接続する3Dエクステントブロックをシームレス3Dエクステントブロック6902とここでは呼ぶことにする。
そこで、シームレス3Dエクステントブロック6902区間での「平均ビットレート」と「シームレス3Dエクステントブロックの合計エクステントATC時間」に対して次のような制約を設けることで、シームレス3Dエクステントブロック6902区間の再生を行った際に、バッファ余裕量UL1、UL2のデータ蓄積量を確保できるようにする。
シームレス3Dエクステントブロックの合計エクステントATC時間 >=
MAX(UL1×Rud3D/(REXT1×{(RMAX1+RMAX2)−(REXT1+REXT2)}),
UL1×Rud3D/(REXT1×{(RMAX1+RMAX3)−(REXT1+REXT3)}),
UL2×Rud3D/(REXT2×{(RMAX1+RMAX2)−(REXT1+REXT2)}),
UL2×Rud3D/(REXT3×{(RMAX1+RMAX3)−(REXT1+REXT3)}))…式(27)
UL1とUL2はシームレス3Dエクステントブロックの後方の3Dエクステントブロックまでのジャンプ時間を元に計算されたリードバッファのバッファ余裕量(単位:ビット)である。MAX()は項目の大きい値を返す関数である。REXT1は3Dエクステントブロック区間の2D/左目AVストリームの平均ビットレートであり、REXT2は3Dエクステントブロック区間のファイルDEPのストリームの平均ビットレートであり、REXT3は3Dエクステントブロック区間のデプスマップAVストリームの平均ビットレートである。
以降で上記式の根拠を、図71を用いて説明する。ここでは、L/Rモードで3D映像の再生を行う場合のケースを用いて説明するが、同様の方法でDEPTHモードの計算を行えば式を導くことができる。
図71はL/Rモードで3D映像の再生を行う場合の第1リード・バッファ4921と第2リード・バッファ4922のデータ蓄積量の推移を示す。ここではシームレス3Dエクステントブロックにジャンプした直後の様子を示しており、UL1、UL2のバッファ余裕量を消費しきった状態で再生を開始しているとする。また、各エクステントは、前述した最小エクステントサイズと最大エクステントサイズの定義方法によって、インターリーブして配置されているとする。
前述の最小エクステントサイズと最大エクステントサイズは、エクステントの平均ビットレートをRMAX1もしくはRMAX2として算出したサイズとなっている。図71のデータ蓄積量の推移を示す通常の線は、エクステントの平均ビットレートがRMAX1、RMAX2の場合のデータ蓄積量の推移を示す。対してデータ蓄積量の推移を示す太線は、2D/左目AVストリームのエクステント(REXT1[n])の平均ビットレートがRMAX1よりも小さいREXT1の場合のデータ蓄積量の推移を示している。
2D/左目AVストリームのエクステントのビットレートがRMAX1よりも小さい場合には、エクステントの読み込みは、ビットレートがRMAX1の場合よりも早く終わることになり、以降のデータ蓄積量の推移は矢印7001で示す分だけ前倒しされることになる。この前倒しによって、エクステントを読み終えると、前倒しの分だけ、矢印7002で示されるサイズ(前倒し時間×REXT1)がバッファ余裕量として蓄積されることになる。前倒し時間は、エクステントの再生時間をTEXTとすると、TEXT×(RMAX1−REXT1)/RUD3Dと表せる。また、第2リード・バッファ4922のデータ蓄積量も同様に前倒しされることとなるため、エクステントを読み終えると、前倒しの分だけ、矢印7003で示されるサイズ(前倒し時間×REXT2)がバッファ余裕量として蓄積されることになる。
同様にファイルDEPのストリームのエクステントのビットレートがRMAX2よりも小さいREXT2の場合には前倒しが発生するためその分、第1リード・バッファ4921と第2リード・バッファ4922にはバッファ余裕量が蓄積されることとなる。
2D/左目AVストリームのエクステント群と、対応するファイルDEPのストリームのエクステント群の再生時間をTEXTとし、各エクステントの平均ビットレートがREXT1、REXT2とすると、これらのエクステントを読むことによって、第1リード・バッファ4921に蓄積されるバッファ余裕量と、第2リード・バッファ4922に蓄積されるバッファ余裕量は次のようになる。
第1リード・バッファ4921に蓄積されるバッファ余裕量(単位:ビット)=TEXT×(REXT1×{(RMAX1+RMAX2)−(REXT1+REXT2)}/RUD3D…式(28)
第2リード・バッファ4922に蓄積されるバッファ余裕量(単位:ビット)=TEXT×(REXT2×{(RMAX1+RMAX2)−(REXT1+REXT2)}/RUD3D…式(29)
よって式(28)と(29)から、シームレス接続のジャンプに必要なUL1、UL2のサイズを蓄積するまでの時間にすることで、式(27)を導くことができる。
(バッファ余裕量の蓄積方法2)
次に、リードバッファに確保される層切り替えジャンプなどのためのバッファ余裕量のAV再生中の蓄積方法の別案を説明する。
シームレス3Dエクステントブロック6902内のエクステントのサイズは、式(1)−(5)で求められる最小エクステントサイズ以上に設定するとしたが、この計算式に、バッファ余裕量を蓄積するためのマージンを追加した以下に示す形に変形する。
SEXT1[n]>=CEIL((Rud3D×REXT1[n])/(Rud3D−REXT1[n])×(TJUMP0+SEXT2[n+1]/Rud3D+TJUMP+TMERGIN)/8)…(30)
SEXT2[n]>=CEIL((Rud3D×REXT2[n])/(Rud3D−REXT2[n])×(TJUMP0+SEXT1[n]/Rud3D+TJUMP+TMERGIN)/8)…(31)
SEXT1[n]>=CEIL((Rud3D×REXT1[n])/(Rud3D−REXT1[n])×(TJUMP+SEXT3[n+1]/Rud3D+TJUMP0+TMERGIN)/8)…(32)
SEXT3[n]=CEIL((Rud3D×REXT3[n])/(Rud3D−REXT3[n])×(TJUMP+SEXT1[n]/Rud3D+TJUMP0+TMERGIN)/8)…(33)
TMERGINがバッファ余裕量を蓄積するためのマージン時間(単位:秒)である。
図72を用いてL/Rモードでの3D映像再生におけるリードバッファへのデータ蓄積量の変化を説明する。
このように計算された最小エクステントサイズを持つエクステントでシームレス3Dエクステントブロック6902を構成することにより、図72のデータ蓄積量の推移に示すように、2D/左目AVストリームの1エクステントの読み込むに従って、TMERGIN×REXT1[n]の値だけ第1リード・バッファ4921にデータが余分に蓄積される。ファイルDEPのストリームの1エクステントの読み込むに従って、TMERGIN×REXT2[n]の値だけ第2リード・バッファ4922にデータが余分に蓄積される。
また、ファイルDEPのストリームの1エクステントの読み込むに従って、TMERGINの値だけ、第1リード・バッファ4921への2D/左目AVストリームのエクステントデータの入力を前倒しできるため、ファイルDEPのストリームの1エクステントの読み込む度に、TMERGIN×REXT1[n]の値だけ第1リード・バッファ4921にデータが余分に蓄積される。同様に2D/左目AVストリームの1エクステントの読み込むに従って、TMERGINの値だけ、第2リード・バッファ4922へのファイルDEPのストリームのエクステントデータの入力を前倒しできるため、ファイルDEPのストリームの1エクステントの読み込む度に、TMERGIN×REXT1[n]の値だけ第1リード・バッファ4921にデータが余分に蓄積される。
そこで、シームレス3Dエクステントブロック6902区間での「3Dエクステントブロックの合計エクステントATC時間」に対して次のような制約を設けることで、シームレス3Dエクステントブロック6902区間の再生を行った際に、バッファ余裕量UL1、UL2のデータ蓄積量を確保できることになる。
シームレス3Dエクステントブロックの合計エクステントATC時間 >=
MAX(UL1/(2×TMERGIN× REXT1/TEXT),
UL2/(2×TMERGIN× REXT2/TEXT),
UL2/(2×TMERGIN× REXT3/TEXT))…式(34)
UL1とUL2はシームレス3Dエクステントブロックの後方の3Dエクステントブロックまでのジャンプ時間を元に計算されたリードバッファのバッファ余裕量(単位:ビット)である。MAX()は項目の大きい値を返す関数である。REXT1は3Dエクステントブロック区間の2D/左目AVストリームの平均ビットレートであり、REXT2は3Dエクステントブロック区間のファイルDEPのストリームの平均ビットレートであり、REXT3は3Dエクステントブロック区間のデプスマップAVストリームの平均ビットレートである。TEXTは、1エクステントの平均エクステントATC時間である。
なお、上記のように規定することと、「平均ビットレート」と「シームレス3Dエクステントブロックの合計エクステントATC時間」で規定する方法を両立させるようにしても良い。つまり、以下のように「シームレス3Dエクステントブロックの合計エクステントATC時間」を規定しても良い。
シームレス3Dエクステントブロックの合計エクステントATC時間 >=
MAX(UL1/(2×TMERGIN× REXT1/TEXT+((REXT1×{(RMAX1+RMAX2)−(REXT1+REXT2)})/Rud3D),
UL1/(2×TMERGIN× REXT1/TEXT+((REXT1×{(RMAX1+RMAX3)−(REXT1+REXT3)})/Rud3D),
UL2/(2×TMERGIN× REXT2/TEXT+((REXT2×{(RMAX1+RMAX2)−(REXT1+REXT2)})/Rud3D),
UL2/(2×TMERGIN× REXT3/TEXT+((REXT3×{(RMAX1+RMAX3)−(REXT1+REXT3)})/Rud3D))…式(35)
<配置1のデータを3D再生するために必要なバッファ余裕量>
次に、図20に示した配置1のデータを3D再生するために必要なバッファ余裕量について説明する。
まず、L/Rモードで再生する上で必要なバッファ余裕量について説明する。
図73の(a)は、配置1のデータをL/Rモードで再生中に生じるロングジャンプを示す図である。図73の(b)は、L/Rモードで配置1のデータを再生する場合の第1リード・バッファ4921のデータ蓄積量の推移を示し、図73の(c)は第2リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前3Dエクステントブロック2002の後端に配列するエクステントATC時間が一致する三つのデータブロックD3、R3、L3 SS のサイズが0である場合を想定する。
まず、第1リード・バッファ4921のバッファ余裕量UL1について説明する。図73の(a)に示す経路で再生した場合に第1リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前(地点B)までにアンダーフローしなければ良い。つまり地点Bのリードバッファサイズが≧0であればよい。そのためには、図73の地点A(3Dエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前)までにバッファ余裕量UL1のデータ量を蓄積する必要がある。
地点Aから地点Bまでの第1リード・バッファ4921の減少量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファの減少量=(TJUMPEX + 3×TJUMP0 + TJUMP + TLAYER + 2×SEXT2/RUD3D ) × RMAX1
=2×(TJUMP0 + TJUMP + SEXT2/RUD3D)× RMAX1 +(TJUMP0 + TJUMPEX + TLAYER − TJUMP) × RMAX1 …(36)
SEXT2は、地点Aから地点Bまでに存在するライトビューデータブロックのサイズを示す。地点Aから地点Bまでの第1リード・バッファ4921の増加量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファ4921の増加量=2×SEXT1/RUD3D×(RUD3D−RMAX1)…(37)
SEXT1は、地点Aから地点Bまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Aに必要なバッファ余裕量は、式(36)、(37)から次のように計算できる。
UL1=地点Aから地点Bまでの第1リード・バッファ4921の減少量−地点Aから地点Bまでの第1リード・バッファ4921の増加量
=2×(TJUMP0 + TJUMP + SEXT2/RUD3D)× RMAX1 +(TJUMP0 + TJUMPEX + TLAYER − TJUMP) × RMAX1 −2×SEXT1/RUD3D×(RUD3D−RMAX1)…(38)
ここで、(TJUMP0 + TJUMP + SEXT2/RUD3D)× RMAX1とSEXT1/RUD3D×(RUD3D−RMAX1)は0以上になるように最小エクステントサイズは決定される。つまり、式(2)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(38)からL/Rモードで再生する上で必要なバッファ余裕量UL1は、次式(39)となる。
UL1=CEIL(TJUMPEX+TLAYER+TJUMP0−TJUMP)×RMAX1 …(39)
次に、第2リード・バッファ4922のバッファ余裕量について説明する。第2リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前(地点D)までにアンダーフローしなければ良い。つまり地点Dのリードバッファサイズが≧0であればよい。そのためには、図73の地点C(3Dエクステントブロック2001の終端のライトビューデータブロックR1を読み込む直前)までにバッファ余裕量(UL2)のデータ量を蓄積する必要がある。
地点Cから地点Dまでの第2リード・バッファ4922の減少量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの減少量=(TJUMPEX + 3×TJUMP0 + TJUMP + TLAYER + 2×SEXT1/RUD3D ) × RMAX2
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX2 +(TJUMP0 + TJUMPEX + TLAYER − TJUMP) × RMAX2 …(40)
SEXT1は、地点Cから地点Dまでに存在するレフトビューデータブロックのサイズを示す。地点Cから地点Dまでの第2リード・バッファ4922の増加量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの増加量=2×SEXT2/RUD3D×(RUD3D−RMAX2)…(41)
SEXT2は、地点Cから地点Dまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Cに必要なバッファ余裕量は、式(40)、(41)から次のように計算できる。
UL2=地点Cから地点Dまでの第2リード・バッファの減少量−地点Cから地点Dまでの第2リード・バッファの増加量
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX2 +(TJUMP0 + TJUMPEX + TLAYER − TJUMP) × RMAX2 −2×SEXT2/RUD3D×(RUD3D−RMAX2)…(42)
ここで、(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX2とSEXT2/RUD3D×(RUD3D−RMAX2)は0以上になるように最小エクステントサイズは決定される。つまり、式(3)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(42)からL/Rモードで再生する上で必要なバッファ余裕量UL2は、次式(43)となる。
UL2=CEIL(TJUMPEX+TLAYER+TJUMP0−TJUMP)×RMAX2 …(43)
以上がL/Rモードで配置1のデータを再生する上で必要なバッファ余裕量である。
次に、DEPTHモードで配置1のデータを再生する上で必要なバッファ余裕量について説明する。
図74の(a)は、配置1のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図74の(b)は、デプスモードで配置1のデータを再生する場合の第1リード・バッファ4921のデータ蓄積量の推移を示し、図74の(c)は第2リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前3Dエクステントブロック2002の後端に配列するエクステントATC時間が一致する三つのデータブロックD3、R3、L3SSのサイズが0である場合を想定する。
まず、第1リード・バッファ4921のバッファ余裕量UL1について説明する。図74の(a)に示す経路で再生した場合に第1リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前(地点B)までにアンダーフローしなければ良い。つまり地点Bのリードバッファサイズが≧0であればよい。そのためには、図74の地点A(3Dエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前)までにバッファ余裕量UL1のデータ量を蓄積する必要がある。
地点Aから地点Bまでの第1リード・バッファ4921の減少量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファの減少量=(TJUMPEX + 3×TJUMP+ TJUMP0 + TLAYER + 2×SEXT3/RUD3D ) × RMAX1
=2×(TJUMP0 + TJUMP + SEXT3/RUD3D)× RMAX1 +(TJUMP + TJUMPEX + TLAYER − TJUMP0) × RMAX1 …(44)
SEXT3は、地点Aから地点Bまでに存在するデブスマップデータブロックのサイズを示す。地点Aから地点Bまでの第1リード・バッファ4921の増加量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファ4921の増加量=2×SEXT1/RUD3D×(RUD3D−RMAX1)…(45)
SEXT1は、地点Aから地点Bまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Aに必要なバッファ余裕量は、式(44)、(45)から次のように計算できる。
UL1=地点Aから地点Bまでの第1リード・バッファ4921の減少量−地点Aから地点Bまでの第1リード・バッファ4921の増加量
=2×(TJUMP0 + TJUMP + SEXT3/RUD3D)× RMAX1 +(TJUMP + TJUMPEX + TLAYER − TJUMP0) × RMAX1 −2×SEXT1/RUD3D×(RUD3D−RMAX1)…(46)
ここで、(TJUMP0 + TJUMP + SEXT3/RUD3D)× RMAX1とSEXT1/RUD3D×(RUD3D−RMAX1)は0以上になるように最小エクステントサイズは決定される。つまり、式(4)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(46)からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式(47)となる。
UL1=CEIL(TJUMPEX+TLAYER−TJUMP0+TJUMP)×RMAX1 …(47)
次に、第2リード・バッファ4922のバッファ余裕量について説明する。第2リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のデプスマップデータブロックD4を読む直前(地点D)までにアンダーフローしなければ良い。つまり地点Dのリードバッファサイズが≧0であればよい。そのためには、図74の地点C(3Dエクステントブロック2001の終端のデプスマップデータブロックD1を読み込む直前)までにバッファ余裕量(UL2)のデータ量を蓄積する必要がある。
地点Cから地点Dまでの第2リード・バッファ4922の減少量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの減少量=(TJUMPEX + 3×TJUMP+ TJUMP0 + TLAYER + 2×SEXT1/RUD3D ) × RMAX3
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX3 +(TJUMP + TJUMPEX + TLAYER − TJUMP0) × RMAX3 …(48)
SEXT1は、地点Cから地点Dまでに存在するレフトビューデータブロックのサイズを示す。地点Cから地点Dまでの第2リード・バッファ4922の増加量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの増加量=2×SEXT3/RUD3D×(RUD3D−RMAX3)…(49)
SEXT3は、地点Cから地点Dまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Cに必要なバッファ余裕量は、式(48)、(49)から次のように計算できる。
UL2=地点Cから地点Dまでの第2リード・バッファの減少量−地点Cから地点Dまでの第2リード・バッファの増加量
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX3 +(TJUMP + TJUMPEX + TLAYER − TJUMP0) × RMAX3 −2×SEXT3/RUD3D×(RUD3D−RMAX3)…(50)
ここで、(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX3とSEXT3/RUD3D×(RUD3D−RMAX3)は0以上になるように最小エクステントサイズは決定される。つまり、式(5)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(50)からデプスモードで再生する上で必要なバッファ余裕量UL2は、次式(51)となる。
UL2=CEIL(TJUMPEX+TLAYER−TJUMP0+TJUMP)×RMAX3 …(51)
以上がデプスモードで配置1のデータを再生する上で必要なバッファ余裕量である。
2D/3D再生装置は、このように計算されるUL1とUL2をバッファ余裕量として確保することで、図20で説明した配置1のデータを、シームレスに再生を行うことが可能となる。
<配置2のデータを3D再生するために必要なバッファ余裕量>
次に、図24に示した配置2のデータを3D再生するために必要なバッファ余裕量について説明する。 まず、デプスモードで再生する上で必要なバッファ余裕量について説明する。
図75の(a)は、配置2のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図75の(b)は、デプスモードで配置2のデータを再生する場合の第1リード・バッファ4921のデータ蓄積量の推移を示し、図75の(c)は第2リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前3Dエクステントブロック2002の後端に配列するエクステントATC時間が一致する三つのデータブロックD3、R3、L3 SS のサイズが0である場合を想定する。
まず、第1リード・バッファ4921のバッファ余裕量UL1について説明する。図75の(a)に示す経路で再生した場合に第1リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前(地点B)までにアンダーフローしなければ良い。つまり地点Bのリードバッファサイズが≧0であればよい。そのためには、図75の地点A(3Dエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前)までにバッファ余裕量UL1のデータ量を蓄積する必要がある。
地点Aから地点Bまでの第1リード・バッファ4921の減少量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファ4921の減少量=( 2×TJUMP + TJUMP0 + TLAYER + SEXT3/RUD3D ) × RMAX1
=(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1 +(TJUMP + TLAYER) × RMAX1 …(52)
SEXT3は、地点Aから地点Bまでに存在するデプスマップデータブロックのサイズを示す。地点Aから地点Bまでの第1リード・バッファ4921の増加量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファ4921の増加量=SEXT1/RUD3D×(RUD3D−RMAX1)…(53)
SEXT1は、地点Aから地点Bまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Aに必要なバッファ余裕量は、式(52)、(53)から次のように計算できる。
UL1=地点Aから地点Bまでの第1リード・バッファ4921の減少量−地点Aから地点Bまでの第1リード・バッファ4921の増加量
=(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1 +(TJUMP + TLAYER) × RMAX1 −SEXT1/RUD3D×(RUD3D−RMAX1)…(54)
ここで、(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1とSEXT1/RUD3D×(RUD3D−RMAX1)は0以上になるように最小エクステントサイズは決定される。つまり、式(3)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(54)からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式(55)となる。
UL1=CEIL(TLAYER+TJUMP)×RMAX1 …(55)
次に、第2リード・バッファ4922のバッファ余裕量について説明する。第2リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前(地点D)までにアンダーフローしなければ良い。つまり地点Dのリードバッファサイズが≧0であればよい。そのためには、図75の地点C(3Dエクステントブロック2001の終端のライトビューデータブロックR1を読み込む直前)までにバッファ余裕量(UL2)のデータ量を蓄積する必要がある。
地点Cから地点Dまでの第2リード・バッファ4922の減少量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの減少量=( 2×TJUMP + TJUMP0 + TLAYER + SEXT1/RUD3D ) × RMAX3
=(TJUMP0 + TJUMP + SEXT1/RUD3D )× RMAX3 +(TJUMP + TLAYER) × RMAX3 …(56)
SEXT1は、地点Cから地点Dまでに存在するレフトビューデータブロックのサイズを示す。地点Cから地点Dまでの第2リード・バッファ4922の増加量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの増加量=SEXT3/RUD3D×(RUD3D−RMAX3)…(57)
SEXT2は、地点Cから地点Dまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Cに必要なバッファ余裕量は、式(56)、(57)から次のように計算できる。
UL2=地点Cから地点Dまでの第2リード・バッファの減少量−地点Cから地点Dまでの第2リード・バッファの増加量
=(TJUMP0 + TJUMP + SEXT1/RUD3D )× RMAX3 +(TJUMP + TLAYER) × RMAX3−SEXT3/RUD3D×(RUD3D−RMAX3)…(58)
ここで、(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX3とSEXT3/RUD3D×(RUD3D−RMAX3)は0以上になるように最小エクステントサイズは決定される。つまり、式(3)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(58)からデプスモードで再生する上で必要なバッファ余裕量UL2は、次式(59)となる。
UL2=CEIL(TLAYER+TJUMP)×RMAX3 …(59)
以上がデプスモードで配置2のデータを再生する上で必要なバッファ余裕量である。
次に、L/Rモードで再生する上で必要なバッファ余裕量(UL1,UL2)について説明する。
L/Rモードで再生する上で必要なバッファ余裕量は、次で表す式で求められる。
UL1=CEIL(TLAYER+TJUMP0)×RMAX1 …(60)
UL2=CEIL(TLAYER+TJUMP0)×RMAX2 …(61)
これらはDEPTHモードのバッファ余裕量UL1、UL2と同様の考え方で計算できるため計算方法は省略する。
2D/3D再生装置は、このように計算されるUL1とUL2をバッファ余裕量として確保することで、図24で説明した配置2のデータを、シームレスに再生を行うことが可能となる。
ここで、式(60)、(61)によって求められる配置2のデータをL/Rモードで再生する上で必要なバッファ余裕量は、式(39)、(43)によって求められる配置1のデータをL/Rモードで再生する上で必要なバッファ余裕量に比べて値が小さい。また、式(55)、(59)によって求められる配置2のデータをデプスモードで再生する上で必要なバッファ余裕量は、式(47)、(51)によって求められる配置1のデータをデプスモードで再生する上で必要なバッファ余裕量に比べて値が小さい。
よって、図24を用いて説明した配置2のデータ構造の方が、シームレス接続に必要なバッファ余裕量(UL1、UL2)を小さく抑えられるため、3D映像を再生する際に必要な第1リード・バッファ4921、第2リード・バッファ4922のサイズを小さくすることができる。
ただし、図24を用いて説明したデータ構造でデータを配置するためには、図20にはない前述した次の条件が必要である。
「3Dエクステントブロック6401の最後の2D/左目AVストリームのエクステントは、自身のエクステントの終端から、2Dジャンプ直前エクステント6501までのジャンプ時間をTJUMPとして式(2)によって求められる2D再生装置のための最小エクステントサイズ以上のサイズになる必要がある。3Dエクステントブロック6401の最後の2D/左目AVストリームのエクステントから、2Dジャンプ直前エクステント6501までの距離は、2D再生装置のジャンプパフォーマンスを元に所定の規格で決められる最大ジャンプ距離以下になるように設定される。」
図76に示すように、3Dエクステントブロックのエクステントサイズの条件から決められたサイズを持つ3Dエクステントブロック2001の最後のレフトビューデータブロックL1を読み込むことで2D再生装置がシームレスに再生可能なジャンプ距離が、ジャンプ直前3Dエクステントブロック2002のサイズよりも大きい場合は、図24を用いて説明したデータ構造でデータを配置できる。しかし、3Dエクステントブロックのエクステントサイズの条件から決められたサイズを持つ3Dエクステントブロック2001の最後のレフトビューデータブロックL1を読み込むことで2D再生装置がシームレスに再生可能なジャンプ距離が、ジャンプ直前3Dエクステントブロック2002のサイズよりも小さい場合は、図24を用いて説明したデータ構造でデータを配置できない。
よって、上記の条件を満たす場合は、図24に示す配置2のデータ構造でデータを配置し、満たさない場合は、図20に示す配置1のデータ構造でデータを配置するというように使い分けを行うと好ましい。
また、式(1)で示したように、2D再生モードでシームレス接続をするためのエクステントサイズはシステムレートに依存するため、上記条件をクリアするためのレフトビュービデオストリームのシステムレートを特定し、そのシステムレートよりも高ければ、図20に示す配置1のデータ構造で配置し、そのシステムレートよりも低ければ、図24に示す配置2のデータ構造で配置するとしても良い。
なお、図24に示す配置2では、ジャンプ直前2DエクステントEXT2D[n]が2D専用ブロックのみから構成されており、ジャンプ直前2DエクステントEXT2D[n]と同じサイズのデータを3D専用ブロックとして複製し、記録媒体に記録しておく必要がある。 その一方で図20に示す配置1では、ジャンプ直前2DエクステントEXT2D[n]の一部として利用しているベースビュー・データ・ブロックLnが、3DエクステントEXTSS[n]の一部としても利用されるため、異なるエクステントに重複して格納されるデータ量の増大を抑えることができるという点で好ましい。
<配置3のデータを3D再生するために必要なバッファ余裕量>
次に、図26に示した配置3のデータを3D再生するために必要なバッファ余裕量について説明する。 まず、デプスモードで再生する上で必要なバッファ余裕量について説明する。
図77の(a)は、配置3のデータをデプスモードで再生中に生じるロングジャンプを示す図である。図77の(b)は、デプスモードで配置3のデータを再生する場合の第1リード・バッファ4921のデータ蓄積量の推移を示し、図77の(c)は第2リード・バッファ4922のデータ蓄積量の推移を示す。
ここでは、必要なバッファ余裕量のワースト値を考慮し、ジャンプ直前3Dエクステントブロック2002の後端に配列するエクステントATC時間が一致する三つのデータブロックD3、R3、L3 SS のサイズが0である場合を想定する。
まず、第1リード・バッファ4921のバッファ余裕量UL1について説明する。図77の(a)に示す経路で再生した場合に第1リード・バッファ4921がアンダーフローしないためには、後方プレイアイテムの先頭のレフトビューデータブロックL4を読む直前(地点B)までにアンダーフローしなければ良い。つまり地点Bのリードバッファサイズが≧0であればよい。そのためには、図77の地点A(3Dエクステントブロック2001の終端のレフトビューデータブロックL1を読み込む直前)までにバッファ余裕量UL1のデータ量を蓄積する必要がある。
地点Aから地点Bまでの第1リード・バッファ4921の減少量=( 2×TJUMP + 2×TJUMP0 + TLAYER + TJUMPEX + SEXT3/RUD3D ) × RMAX1
=(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1 +(TJUMPEX + TLAYER) × RMAX1 …(62)
SEXT3は、地点Aから地点Bまでに存在するデプスマップデータブロックのサイズを示す。地点Aから地点Bまでの第1リード・バッファ4921の増加量は次のとおりに計算される。
地点Aから地点Bまでの第1リード・バッファ4921の増加量=2×SEXT1/RUD3D×(RUD3D−RMAX1)…(63)
SEXT1は、地点Aから地点Bまでに存在するレフトビューデータブロックのサイズを示す。よって、地点Aに必要なバッファ余裕量は、式(62)、(63)から次のように計算できる。
UL1=地点Aから地点Bまでの第1リード・バッファ4921の減少量−地点Aから地点Bまでの第1リード・バッファ4921の増加量
=2×(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1 +(TJUMPEX + TLAYER) × RMAX1 −2×SEXT1/RUD3D×(RUD3D−RMAX1)…(64)
ここで、(TJUMP0 + TJUMP + SEXT3/RUD3D )× RMAX1とSEXT1/RUD3D×(RUD3D−RMAX1)は0以上になるように最小エクステントサイズは決定される。つまり、式(3)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(64)からデプスモードで再生する上で必要なバッファ余裕量UL1は、次式(65)となる。
UL1=CEIL(TLAYER+TJUMPEX)×RMAX1 …(65)
次に、第2リード・バッファ4922のバッファ余裕量について説明する。第2リード・バッファ4922がシームレス接続してもバッファがアンダーフローしないためには、後方プレイアイテムの先頭のライトビューデータブロックR4を読む直前(地点D)までにアンダーフローしなければ良い。つまり地点Dのリードバッファサイズが≧0であればよい。そのためには、図77の地点C(3Dエクステントブロック2001の終端のデプスマップデータブロックD1を読み込む直前)までにバッファ余裕量(UL2)のデータ量を蓄積する必要がある。
地点Cから地点Dまでの第2リード・バッファ4922の減少量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの減少量=( 2×TJUMP + 2×TJUMP0 + TJUMPEX + TLAYER + 2×SEXT1/RUD3D ) × RMAX3
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D )× RMAX3 +(TJUMPEX + TLAYER) × RMAX3 …(66)
SEXT1は、地点Cから地点Dまでに存在するレフトビューデータブロックのサイズを示す。地点Cから地点Dまでの第2リード・バッファ4922の増加量は次のとおりに計算される。
地点Cから地点Dまでの第2リード・バッファの増加量=2×SEXT3/RUD3D×(RUD3D−RMAX3)…(67)
SEXT3は、地点Cから地点Dまでに存在するデプスマップデータブロックのサイズを示す。よって、地点Cに必要なバッファ余裕量は、式(66)、(67)から次のように計算できる。
UL2=地点Cから地点Dまでの第2リード・バッファの減少量−地点Cから地点Dまでの第2リード・バッファの増加量
=2×(TJUMP0 + TJUMP + SEXT1/RUD3D )× RMAX3 +(TJUMPEX + TLAYER) × RMAX3−2×SEXT3/RUD3D×(RUD3D−RMAX3)…(68)
ここで、(TJUMP0 + TJUMP + SEXT1/RUD3D)× RMAX3とSEXT3/RUD3D×(RUD3D−RMAX3)は0以上になるように最小エクステントサイズは決定される。つまり、式(3)を満たす最小エクステントサイズ以上のエクステントサイズであれば、この値は必ず0以上になる。
よって、ワースト値を考慮するとこの値は0となるため、式(68)からデプスモードで再生する上で必要なバッファ余裕量UL2は、次式(69)となる。
UL2=CEIL(TLAYER+TJUMPEX)×RMAX3 …(69)
以上がデプスモードで配置3のデータを再生する上で必要なバッファ余裕量である。
次に、L/Rモードで再生する上で必要なバッファ余裕量について説明する。
L/Rモードで再生する上で必要なバッファ余裕量は、次で表す式で求められる。
UL1=CEIL(TJUMPEX+TLAYER)×RMAX1 …(70)
UL2=CEIL(TJUMPEX+TLAYER)×RMAX2 …(71)
これはデプスモードのバッファ余裕量UL1、UL2と同様の考え方で説明できるため、計算方法は省略する。
2D/3D再生装置は、このように計算されるUL1とUL2をバッファ余裕量として確保することで、図26で説明した配置3のデータを、シームレスに再生を行うことが可能となる。
ここで、2D/3D再生装置が、L/Rモードとデプスモードの両方3D映像を再生可能である場合には、必要なバッファ余裕量はワースト値になる。図20を用いて説明した配置1のデータ構造を再生する場合のバッファ余裕量のワースト値(最大値)は、デプスモードで3D映像を再生するために必要なバッファ余裕量である、式(47)、(51)で求められるサイズになる。図26を用いて説明した配置3のデータ構造を再生する場合のバッファ余裕量のワースト値(最大値)は、L/Rモードで3D映像を再生するために必要なバッファ余裕量である式(70)、(71)で求められるサイズか、デプスモードで3D映像を再生するために必要なバッファ余裕量である式(65)、(69)で求められるサイズかの何れかになる。ここで、式(70)、(71)で求められる配置3をL/Rモードで再生するために必要なバッファ余裕量と、式(65)、(69)で求められる配置3をデブスモードで再生するために必要なバッファ余裕量とは、どちらも式(47)、(51)で求められる配置1をデブスモードで再生するために必要なバッファ余裕量に比べて小さい。即ち、配置3は配置1に比べて、デプスモードとL/Rモードとの両方で、シームレス接続に必要なバッファ余裕量(UL1、UL2)を小さく抑えられる。よって、L/Rモードとデプスモードとの両方3D映像を再生可能である場合には、リードバッファに必要なサイズの観点から図26を用いて説明した配置1のデータ構造で記録媒体にストリームデータを配置することが好ましいことが言える。
(シームレス接続時のリードバッファサイズを削減するためのデータ構造)
図20、図24、図26で説明したシームレス接続でのデータ配置方法に加えて、2D/3D再生装置での3D映像再生に必要なリードバッファのサイズを削減するためのデータ配置方法を、図78を用いて説明する。
3D映像再生に必要なリードバッファのサイズを削減するためのデータ配置方法について説明する。
図78上段は、図26で説明した配置3でのL/Rモードの再生経路、デプスモードの再生経路を示している。
図78上段のデータ構造において、ジャンプ直前3Dエクステントブロック7501の終端のレフトビューデータブロック、ライトビューデータブロック、デプスマップデータブロックの各データブロックのサイズは、式(2)−(5)で求められる最小エクステントサイズを満たさないでよい。これは、例えば前述した定義方法によって最小エクステントサイズを「エクステントの平均転送レート×最小エクステントATC時間」(例:REXT1[n]×MIN_TEXT)とし、最大エクステントサイズを「エクステントの平均転送レート×最小エクステントATC時間」(例:REXT1[n]×MIN_TEXT)とした場合に、コンテンツの再生時間によっては、最小エクステント時間を満たさない端数が出てきてしまうためである。例えば、最小エクステントATC時間を2秒、最大エクステントATC時間=最小エクステントATC時間とし、AVストリームのATC時間が11秒であるとする。この場合、AVストリームの先頭から最小エクステントATC時間である2秒単位でエクステントを区切っていく場合に、終端に1秒のエクステントATC時間のエクステントがあまってしまう。
仮に図78下段のように終端のエクステント群が、式(2)−(5)の最小エクステントサイズを満たすようにすると、2D/3D再生装置に必要なバッファ余裕量であるUL1とUL2は削減できるため好ましい。
そこで、終端のエクステント群が、式(2)−(5)の最小エクステントサイズを満たせるように図79に示すように次の制約を設ける。
シームレス接続するためのAVストリームの最小ATC時間をTDURATIONとすると、最大エクステントATC時間を次のように定義する。
TMAX_TEXT≧(TMIN_TEXT×TDURATION)/(TDURATION−MIN_TEXT)…(72)
図79下段にその根拠を書いている。AVストリームを先頭から最小エクステントATC時間でエクステント分割した場合に発生する最小エクステント時間を満たさない、終端エクステントの最大値はMIN_TEXTとなる。終端のMIN_TEXTの時間分を、最小エクステントATC時間で分割できているエクステントに分配して、それが最大エクステントATC時間以下になれば、端数は発生させないことができる。
図79の例では、MIN_TEXTが2秒でTDURATIONが20秒のケースでは、最大エクステントATC時間が2.222秒となり、MIN_TEXTが2秒でTDURATIONが30秒の場合は2.142秒となっている。最大エクステントATC時間が大きくなると、エクステントサイズが大きくなるため、2D/3D再生装置に必要なバッファサイズが増えることになる。よって、MAX_TEXTとTDURATIONの関係は、ジャンプパフォーマンス等のパラメータを踏まえて適度に設定する。制約の仕方としては、シームレス接続する場合のAVストリームのATC時間(TDURATION)を30秒以上で、MAX_TEXTを2.15秒とするなどとして、所定の規格で決めるとよい。
上記の制約を守れば、終端のエクステント群は、常にエクステントATC最小時間を守れるため2D/3D再生装置に必要なバッファ余裕量であるUL1とUL2は削減できる。
バッファ余裕量UL1とUL2が削減できる理由は、図75で説明した計算方法から計算できる。図80はL/Rモードでのバッファ余裕量UL1とUL2のサイズの計算方法をまとめている。
<マルチアングル>
図81(a)に示すように、2D映像においてマルチアングルを実現するデータ配置として、各アングル映像を示す複数の多重化ストリーム群を、アングル毎にインターリーブ配置する方法がある。
3D映像でマルチアングルを実現する場合には、図81(b)に示すように、1つのアングルのレフトビュービデオストリームと、ライトビュービデオストリームと、デプスマップストリームとのデータブロックをインターリーブ配置したブロックを1単位として、このブロックをアングル毎にインターリーブして構成してもよい。
<3D映像でマルチアングルを実現する他のデータ構造>
なお、3D映像でマルチアングルを行う場合に、図82(b)に示すように、マルチアングル区間ではレフトビュービデオストリーム、ディペンデントビュービデオストリーム、及びデプスマップストリームのエクステントを別ファイルに分離させず1本の多重化ストリーム内に収めるようにしてもよい。この場合、2D再生装置で再生するためには、レフトビュービデオストリーム、ディペンデントビュービデオストリーム、及びデプスマップストリームを合わせて、AVストリームのシステムレートの範囲内に収める必要がある。
このような変形例では、プレイアイテム間で、システムターゲットデコーダに転送するAVストリームの数が途中で切り替わるようなケースに対応するために、図82(a)に示すように、各プレイアイテムに、再生するTSの本数を指し示すためのフラグを設ける。具体的には、3D映像を再生するために2つのAVストリーム(L/Rモードであればレフトビュービデオストリームとライトビュービデオストリーム、デプスモードであればレフトビュービデオストリームとデプスマップストリーム)を再生する非マルチアングル区間のプレイアイテム#1、#3には、このTSモードを示すフラグを2TSのモードに設定し、3D映像を再生するために1つのAVストリームを再生するマルチアングル区間のプレイアイテム#2には、TSモードを示すフラグを1TSのモードに設定する。これにより、2D/3D再生装置は、システムターゲットデコーダへの転送をフラグを使って切り替えることができる。なお、このフラグはコネクションコンディションとして追加しても良い。例えば、2TSから1TSへ移行するモードをコネクションコンディション「7」として設定し、1TSから2TSへ移行するモードをコネクションコンディション「8」として設定する。
以下、3D映像のマルチアングル再生に対応するための詳細について説明する。
<立体視インターリーブドストリームファイル>
マルチアングルを構成する立体視インターリーブドファイルが記録された記録領域のデータアロケーションについて説明する。
図83の(a)は、マルチアングル区間において3Dプレイリストのプレイアイテム及びサブプレイアイテムが参照するストリームファイルを示す図である。3Dプレイリストのプレイアイテム及びサブプレイアイテムは、マルチアングル区間を構成することを示すマルチアングルフラグを含む。マルチアングル区間を構成するプレイアイテム及びサブプレイアイテムでは、このフラグがオンに設定されている。本図には、アングル番号1の3D映像(以下、A1映像)、アングル番号2の3D映像(以下、A2映像)、及びアングル番号3の3D映像(以下、A3映像)の3つのアングル映像を切り替えて再生することができるマルチアングル区間のプレイアイテム及びサブプレイアイテムを含む3Dプレイリストを示している。
マルチアングル区間のプレイアイテムは、各アングル映像のベースビュービデオストリームを格納したストリームファイルに対応する参照クリップ情報8301、参照クリップ情報8302、及び参照クリップ情報8303を有する。サブパス・タイプが3Dを示すマルチアングル区間のサブプレイアイテムは、各アングル映像のディペンデントビュービデオストリームを格納したストリームファイルに対応する参照クリップ情報8304、参照クリップ情報8305、及び参照クリップ情報8306を有する。本図において各参照クリップ情報の枠内の記載は、それぞれの参照クリップ情報に対応するストリームファイルのファイル名を示している。
参照クリップ情報8301と参照クリップ情報8304とは、A1映像のベースビューストリーム及びディペンデントビューストリームを指定しており、図40(e)及び図51の説明でのべたように、再生装置は、参照クリップ情報8301及び参照クリップ情報8304で示すクリップ情報のエクステント起点を利用してA1映像を格納している第1ファイルSS(00001.ssif)8307を再生することができる。また、参照クリップ情報8302と参照クリップ情報8305とは、A2映像のベースビューストリーム及びディペンデントビューストリームを指定しており、再生装置は、参照クリップ情報8302及び参照クリップ情報8305で示すクリップ情報のエクステント起点を利用してA2映像を格納している第2ファイルSS(00002.ssif)8308を再生することができる。さらに、参照クリップ情報8303と参照クリップ情報8306とは、A3映像のベースビューストリーム及びディペンデントビューストリームを指定しており、再生装置は、参照クリップ情報8303及び参照クリップ情報8306で示されるクリップ情報のエクステント起点を利用してA3映像を格納している第3ファイルSS(00002.ssif)8309を再生することができる。
図83の(b)は、第1ファイルSS8307、第2ファイルSS8308、及び第3ファイルSS8309の記録媒体100上での物理的な配置を示している。
第1ファイルSS8307のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8301及び参照クリップ情報8304が示すクリップ情報のエントリマップにおいてis_angle_changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A1、D[1]A1、…、ベースビューデータブロックB[0]A1、B[1]A1…に分割されており、D[n]A1とB[n]A1とが第1ファイルSS8307の「インターリーブユニット」A1[n] (n=0、1、…)をなしている。インターリーブユニットA1[n]は、第1ファイルSS8307のn番目のエクステントとしてアクセス可能である。
第2ファイルSS8308のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8302及び参照クリップ情報8305が示すクリップ情報のエントリマップにおいてis_angle_changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A2、D[1]A2、…、ベースビューデータブロックB[0]A2、B[1]A2…に分割されており、D[n]A2とB[n]A2とが第2ファイルSS8308のインターリーブユニットA2[n]をなしている。インターリーブユニットA2[n]は、第2ファイルSS8308のn番目のエクステントとしてアクセス可能である。
第3ファイルSS8309のディペンデントビュービデオストリーム及びベースビュービデオストリームは、参照クリップ情報8303及び参照クリップ情報8306が示すクリップ情報のエントリマップにおいてis_angle_changeがオンに設定された区間、即ち、アングル切り替えが可能な区間毎に、ディペンデントビューデータブロックD[0]A3、D[1]A3、…、ベースビューデータブロックB[0]A3、B[1]A3…に分割されており、D[n]A3とB[n]A3とが第3ファイルSS8309のインターリーブユニットA3[n]をなしている。インターリーブユニットA3[n]は、第3ファイルSS8309のn番目のエクステントとしてアクセス可能である。
本図の最下段に示すように、これらのインターリーブユニット群は、記録媒体100上のトラックに沿って連続的に記録されている。更に、A1のインターリーブユニットA1[0]、A1[1]、…、A2のインターリーブユニットA2[0]、A2[1]、…、及びA3のインターリーブユニットA3[0]、A3[1]、…が、A1映像、A2映像、A3映像の順で、一つずつ交互に配置されている。
図84は、図83に示すように第1ファイルSS8307、第2ファイルSS8308、及び第3ファイルSS8309が配置された記憶領域における再生経路を説明する図である。
以下、マルチアングル区間の途中でアングル番号1からアングル番号3に再生するアングル映像が切り替えられる場合を例に説明する。
2D再生モードでは、先ずアングル番号1の映像として、第1ファイルSS8307の最初のインターリーブユニットA1[0]を構成するベースビューデータブロックB[0]A1が読み出されるが、その再生中にアングル番号が3に切り替えられることで、B[0]A1の終端から第3ファイルSS8309においてアングル切り替えが可能なインターリーブユニットA3[1]のベースビューデータブロックB[1]A3先頭までジャンプが発生し、このB[1]A3が読み出されることになる。
3D再生モードでは、先ずアングル番号1の映像として、第1ファイルSS8307の最初のインターリーブユニットA1[0]を構成するディペンデントビューデータブロックD[0]A1及びベースビューデータブロックB[0]A1が連続して読み出されるが、その再生中にアングル番号が3に切り替えられることで、B[0]A1の終端から第3ファイルSS8309においてアングル切り替えが可能なインターリーブユニットA3[1]のディペンデントビューデータブロックD[1]A3先頭までジャンプが発生し、このディペンデントビューデータブロックD[1]A3と続くベースビューデータブロックB[1]A3とが読み出されることになる。
以上のように、アングル番号の設定に応じて、異なるアングル映像のベースビュービデオストリーム及びディペンデントビュービデオストリームが再生装置に読み出されることになる。
<変形例>
(A)本発明の実施形態1は、記録媒体に3D映像を格納するときのエクステントの配置に関する。しかし、本発明は、記録媒体に高フレームレートの映像を格納するときに利用されても良い。具体的には、例えば高フレームレートの映像を奇数番目のフレーム群と偶数番目のフレーム群とに分け、それぞれをベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとみなして、上記の実施形態1によるエクステントの配置で記録媒体に記録すればよい。通常のフレームレートでの映像再生のみが可能な再生装置は、その記録媒体からは奇数番目のフレーム群の映像を再生すればよい。一方、高フレームレートでの映像再生が可能な再生装置は、奇数番目のフレーム群のみの映像と両方のフレーム群の映像とを選択的に再生できる。こうして、高フレームレートの映像が格納された記録媒体に、通常のフレームレートでの映像再生のみが可能な再生装置に対する互換性を確保させることができる。
(B)本発明の実施形態1では、ベースビュー・ビデオ・ストリームがレフトビューを表し、ディペンデントビュー・ビデオ・ストリームがライトビューを表す。逆に、ベースビュー・ビデオ・ストリームがライトビューを表し、ディペンデントビュー・ビデオ・ストリームがレフトビューを表してもよい。
(C)図39の(a)に示されているオフセット・テーブル3141は、PID別にオフセット・エントリ3304のテーブル3310を含む。オフセット・テーブルはその他に、プレーン別にオフセット・エントリのテーブルを含んでもよい。その場合、3D再生装置によるオフセット・テーブルの解析処理を簡素化することができる。更に、プレーンの合成処理に関する3D再生装置の性能に合わせて、オフセット・エントリの有効区間の長さに、例えば1秒間という下限が設けられてもよい。
(D)図48に示されている3Dプレイリスト・ファイルは、サブTSの再生経路を示すサブパスを一つ含む。その他に、3Dプレイリスト・ファイルが、異なるサブTSの再生経路を示すサブパスを複数含んでもよい。例えば、一方のサブパスのサブパス・タイプが「3D・L/R」であり、他方のサブパスのサブパス・タイプが「3D・デプス」であってもよい。その3Dプレイリスト・ファイルに従って3D映像が再生されるとき、再生対象のサブパスがそれら二種類のサブパスの間で切り換えられることにより、再生装置200をL/Rモードとデプス・モードとの間で容易に切り換えさせることができる。特にその切り換え処理は、3Dプレイリスト・ファイルそのものを切り換える処理よりも速やかに実現可能である。
3Dプレイリスト・ファイルは、サブパス・タイプの等しいサブパスを複数含んでいてもよい。例えば、同じシーンに対する両眼視差の異なる3D映像が共通のレフトビューに対するライトビューの違いで表現されるとき、異なるライトビュー・ビデオ・ストリームごとに異なるファイルDEPが記録媒体100に記録される。一方、3Dプレイリスト・ファイルは、サブパス・タイプが「3D・L/R」であるサブパスを複数含む。それらのサブパスは、異なるファイルDEPの再生経路を個別に規定する。その他に、一つのファイル2Dに対してデプスマップ・ストリームが二種類以上含まれていてもよい。その場合、3Dプレイリスト・ファイルは、サブパス・タイプが「3D・デプス」であるサブパスを複数含む。それらのサブパスは、各デプスマップ・ストリームを含むファイルDEPの再生経路を個別に規定する。そのような3Dプレイリスト・ファイルに従って3D映像が再生されるとき、再生対象のサブパスが例えばユーザの操作に応じて速やかに切り換えられるので、3D映像を実質的に途切れさせることなく、その両眼視差を変化させることができる。それにより、ユーザに所望の両眼視差の3D映像を容易に選択させることができる。
(E)リード・バッファからシステム・ターゲット・レコーダへのデータの平均転送速度Rextの評価においてエクステントATC時間が正確に計算されることを目的として、各エクステントのサイズがソースパケット長のある一定の倍数に揃えられてもよい。更に、いずれかのエクステントがその倍数よりも多くのソースパケットを含むとき、その倍数を超えたソースパケット数とソースパケット一つ当たりの転送時間(=188×8/システムレート)との積を、その倍数に相当するエクステントATC時間に加えた値が、そのエクステントのエクステントATC時間とみなされても良い。その他に、エクステントATC時間は、一つのエクステントの先頭のソースパケットのATSから同じエクステントの最後のソースパケットのATSまでの時間間隔にソースパケット一つ当たりの転送時間を加えた値で定義されてもよい。その場合、エクステントATC時間の計算には次のエクステントの参照が不要であるので、その計算を簡単化することができる。尚、上記のエクステントATC時間の計算では、ATSにラップ・アラウンドが発生することを考慮しなければならない。
(F)インターリーブ配置のデータ・ブロック群の中には、例えばBD−Jオブジェクト・ファイル等、別のファイルに属するエクステントが配置されてもよい。図86の(a)は、多重化ストリーム・データのみを含むインターリーブ配置のデータ・ブロック群を示す模式図である。図86の(b)は、他のファイルに属するエクステントを含むインターリーブ配置のデータ・ブロック群を示す模式図である。
図86の(a)を参照するに、データ・ブロック群6201は、デプスマップ・データ・ブロックD1、D2、D3、ライトビュー・データ・ブロックR1、R2、R3、ベースビュー・データ・ブロックL1、L2、L3を交互に含む。L/Rモードでの再生経路6202では、隣接するライトビュー・データ・ブロックとベースビュー・データ・ブロックとの対R1+L1、R2+L2、R3+L3が順番に読み出される。各対ではライトビュー・データ・ブロックとベースビュー・データ・ブロックとの間にゼロ・セクタ遷移J0が生じる。更に各デプスマップ・データ・ブロックD1、D2、D3の読み出しがジャンプJLRによってスキップされる。デプス・モードでの再生経路6203では、デプスマップ・データ・ブロックD1、D2、D3とベースビュー・データ・ブロックL1、L2、L3とが交互に読み出される。隣接するベースビュー・データ・ブロックとデプスマップ・データ・ブロックとの間にはゼロ・セクタ遷移J0が生じる。更に各ライトビュー・データ・ブロックR1、R2、R3の読み出しがジャンプJLDによってスキップされる。
一方、図86の(b)を参照するに、図86の(a)と同様なデータ・ブロック群6204の中に、別のファイルに属するエクステントA1、A2が挿入されている。その別のファイルは、例えばムービーオブジェクト・ファイル、BD−Jオブジェクト・ファイル、及びJARファイルのいずれでもよい。そのエクステントA1、A2はいずれも、図86の(a)では隣接していたデプスマップ・データ・ブロックとライトビュー・データ・ブロックとの間に挿入されている。その場合、L/Rモードでの再生経路6205では、図86の(a)に示されている再生経路6202よりもジャンプJLRの距離が長い。しかし、そのエクステントA1、A2をいずれかのベースビュー・データ・ブロックの隣に挿入する場合とは異なり、ゼロ・セクタ遷移J0を通常のジャンプに変更しなくてもよい。デプス・モードでの再生経路6206でも同様である。ここで、図64の表から明らかなとおり、最大ジャンプ時間は一般に、ジャンプ距離を変更するときよりも、ゼロ・セクタ遷移を通常のジャンプに変更するときの方が大きく増加する。従って、式(2)−(5)から明らかなとおり、最小エクステント・サイズは一般に、ジャンプ距離を変更するときよりも、ゼロ・セクタ遷移を通常のジャンプに変更するときの方が大きく増加する。それ故、インターリーブ配置のデータ・ブロック群6201の中にエクステントA1、A2を挿入するときは、図86の(b)に示されているように、デプスマップ・データ・ブロックとライトビュー・データ・ブロックとの間に挿入する。それにより、その挿入に伴う最小エクステント・サイズの増大を抑えることができるので、リード・バッファの最小容量の増大を回避することができる。
図86の(b)に示されている配置では更に、各エクステントA1、A2のセクタ単位でのサイズG1、G2が最大ジャンプ距離MAX_EXTJUMP3D以下に制限されてもよい:G1≦MAX_EXTJUMP3D、G2≦MAX_EXTJUMP3D。その最大ジャンプ距離MAX_EXTJUMP3Dは、データ・ブロック群6204内で生じるジャンプJLR、JLDの中で最大のジャンプ距離をセクタ単位で表す。その制限の下では、式(2)−(5)の右辺に代入されるべき最大ジャンプ時間が増大しにくいので、最小エクステント・サイズが増大しにくい。従って、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を回避することができる。
その他に、各エクステントA1、A2のサイズG1、G2とそれに隣接するディペンデントビュー・データ・ブロックD2、R2、D3、R3のサイズSext3[2]、Sext2[2]、Sext3[3]、Sext2[3]との和が最大ジャンプ距離MAX_EXTJUMP3D以下に制限されてもよい:
CEIL(Sext3[2]/2048)+G1≦MAX_EXTJUMP3D、
CEIL(Sext2[2]/2048)+G1≦MAX_EXTJUMP3D、
CEIL(Sext3[3]/2048)+G2≦MAX_EXTJUMP3D、
CEIL(Sext2[3]/2048)+G2≦MAX_EXTJUMP3D。
これらの式では、ディペンデントビュー・データ・ブロックのバイト単位でのサイズを1セクタ当たりのバイト数2048で割ることにより、各サイズの単位をバイトからセクタ数に変換している。これらの条件式が満たされている限り、式(2)−(5)の右辺に代入されるべき最大ジャンプ時間は一定値を超えない。例えば最大ジャンプ距離MAX_EXTJUMP3Dを40000セクタに固定した場合、図64の表から最大ジャンプ時間は350m秒を超えない。従って、最小エクステント・サイズは一定値を超えない。こうして、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を確実に回避することができる。
上記の制限とは更に別に、各エクステントA1、A2のサイズG1、G2とそれに隣接するディペンデントビュー・データ・ブロックD2、R2、D3、R3のサイズSext3[2]、Sext2[2]、Sext3[3]、Sext2[3]との和が、そのディペンデントビュー・データ・ブロックのサイズに対する最大ジャンプ距離MAX_JUMP(・)以下に制限されてもよい:
CEIL(Sext3[2]/2048)+G1≦MAX_JUMP(Sext3[2])、
CEIL(Sext2[2]/2048)+G1≦MAX_JUMP(Sext2[2])、
CEIL(Sext3[3]/2048)+G2≦MAX_JUMP(Sext3[3])、
CEIL(Sext2[3]/2048)+G2≦MAX_JUMP(Sext2[3])。
ディペンデントビュー・データ・ブロックのサイズに対する最大ジャンプ距離MAX_JUMP(・)とは、そのサイズをセクタ数で表したとき、図64の表において、そのセクタ数と同じ最大ジャンプ時間に対応するセクタ数の中での最大値をいう。例えばディペンデントビュー・データ・ブロックのサイズが5000セクタであるとき、図64の表において5000セクタは、最大ジャンプ時間250m秒に対応する範囲1−10000セクタに属する。従って、最大ジャンプ距離MAX_JUMP(5000×2048バイト)はその範囲の最大値10000セクタである。上記の条件式が満たされている限り、式(2)−(5)の右辺に代入されるべき最大ジャンプ時間は変更されないので、最小エクステント・サイズは不変である。従って、エクステントA1、A2の挿入に伴うリード・バッファの最小容量の増大を更に確実に回避することができる。
(インターリーブされたエクステント間にAVストリーム以外のファイルの配置)
次に、インターリーブされたエクステント間にAVストリームとは別のファイル(例えばBDプログラムファイルなど)を格納するために好適なエクステントの配置方法の詳細について説明する。
図87上段は、AVストリームのエクステントが連続して配置されるケースを示している。この場合には、2D/3D再生装置のL/Rモードの再生経路の場合には、EXT2[n]とEXT1[n]が連続しているため、この間のエクステントの遷移時間は0セクタのジャンプ(TJUMP0)となる。2D/3D再生装置のデプスモードの再生経路の場合には、EXT1[n]とEXT3[n+1]が連続しているため、この間のエクステントの遷移時間は0セクタのジャンプ(TJUMP0)となる。前述したように、TJUMP0の区間は、ドライブは連続的にエクステントを読み込みことによって高速に読み込めるため、TJUMP0の時間は図64のように他のジャンプ時間に比べて小さい値になる。
しかし、AVストリームのエクステントが配置される区間においても、AVストリーム以外の別ファイル(例えば、BDプログラムファイルなど)を配置するケースがあるため、図87上段のようにすべてのエクステントを連続して配置することができないケースがある。この場合には、エクステントの合間にAVストリーム以外の別ファイルを配置する必要がある。
図87中段のように、EXT1[n]とEXT3[n]の間にAVストリーム以外の別ファイルを配置した場合には、EXT2[n]とEXT1[n]の間は連続するが、EXT1[n]とEXT3[n+1]の間は連続しなくなる。この場合、2D/3D再生装置のL/Rモードの再生経路ではEXT2[n]とEXT1[n]が連続することでTJUMP0でエクステントの遷移を行えるが、2D/3D再生装置のデプスモードの再生経路ではエクステントが連続する区間(TJUMP0)がなくなるため、L/Rプレーヤの再生経路よりも多くのジャンプ時間が必要となる。
ここで、2D/3D再生装置がシームレスに再生するための最小エクステントサイズは、SEXT1[n]については式(2)と式(4)、SEXT2[n]については式(3)、SEXT3[n]については式(5)を満たすサイズにする必要がある。図87中段のようなエクステントの配置では、式(4)と式(5)のTJUMP0の値が増加するため、SEXT1[n]、SEXT3[n]の最小エクステントサイズが大きくなってしまう。エクステントサイズが大きくなると、式(10)から式(12)までの式に示すように2D/3D再生装置に必要なバッファサイズが増えることとなってしまう。
そこで、AVストリームのエクステント群の間にAVストリーム以外の別ファイルを配置する場合には、図87下段のようにEXT3[n]とEXT2[n]の間に配置する(EXT2[n]とEXT1[n]とEXT3[n+1]は連続して配置する)。このような配置を行うことによって、2D/3D再生装置のL/Rモードの再生経路ではEXT2[n]とEXT1[n]が連続することでドライブはTJUMP0でエクステントの遷移を行うことができ、2D/3D再生装置のデプスモードの再生経路においても、EXT1[n]とEXT3[n+1]が連続することでドライブはTJUMP0でエクステントの遷移を行うことができる。これによって、式(2)、式(3)、式(4)、式(5)に出てくるTJUMP0の値を小さくすることができるため、図87中段のような配置に比べて最小エクステントサイズを小さくすることが可能であり、つまりは2D/3D再生装置に必要なバッファサイズを図87中段のような配置に比べて抑制することができる。
なお、インターリーブされたAVストリームのエクステント群の間に、AVストリーム以外の別ファイルを配置する場合には、EXT3[n]とEXT2[n]の間に配置するとした場合の、EXT3[n]とEXT2[n]の間に配置できるファイルのサイズを次の式のように制約してもよい。
GAP(EXT3[n],EXT2[n])<=MAX_EXTJUMP3D …(73)
GAP(EXT3[n],EXT2[n])<=MAX_EXTJUMP3D …(74)
図88に示すように、EXT3[n]の終端とEXT2[n]の先頭までの間隔をGAP(EXT3[n],EXT2[n])(単位:ブロック数)とし、MAX_EXTJUMP3D(単位:ブロック数)はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することで、EXT3[n]とEXT2[n]の間隔が大きくなりすぎることによって、式(2)、(3)、(4)、(5)に代入されるTJUMPの値が増加し、エクステントサイズが大きくなりすぎることを防ぐことができる。
なお、インターリーブされたAVストリームのエクステント群の間に、AVストリーム以外の別ファイルを配置する場合には、EXT3[n]とEXT2[n]の間に配置するとした場合の、EXT3[n]とEXT2[n]の間に配置できるファイルのサイズを次の式のように制約してもよい。
CEIL(SEXT3[n]/2048)+GAP(EXT3[n],EXT2[n])<= MAX_EXTJUMP3D …(75)
CEIL(SEXT2[n]/2048)+GAP(EXT3[n],EXT2[n])<= MAX_EXTJUMP3D …(76)
図88に示すように、EXT3[n]の終端とEXT2[n]の先頭までの間隔をGAP(EXT3[n],EXT2[n])(単位:ブロック数)とし、MAX_EXTJUMP3D(単位:ブロック数)はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することによって、式(73)、(74)に比べて最小エクステントのサイズを効果的に制約できる。例えば、MAX_EXTJUMP3Dを10000ブロックとした場合、式(73)、(74)の場合は、SEXT3[n]、SEXT2[n]の値によって、エクステント間のジャンプ距離は、10000を超えるケースが発生するため、TJUMPの値が増加してしまい、図64の例で言えば250msとなってしまう。ところが、式(75)、(76)のように定義することで、エクステント間の最大ジャンプ距離を、固定化することができ、例えばMAX_EXTJUMP3Dを10000ブロックとした場合には、TJUMPに入る値は常に一定の固定値を超えない。(図64でいえば250msを超えない)
なお、インターリーブされたAVストリームのエクステント群の間に、AVストリーム以外の別ファイルを配置する場合には、EXT3[n]とEXT2[n]の間に配置するとした場合の、EXT3[n]とEXT2[n]の間に配置できるファイルのサイズを次の式のように制約してもよい。
CEIL(SEXT3[n]/2048)+GAP(EXT3[n],EXT2[n])<= MAX_JUMP(SEXT3[n]) …(77)
CEIL(SEXT2[n]/2048)+GAP(EXT3[n],EXT2[n])<= MAX_JUMP(SEXT2[n]) …(78)
図88に示すように、EXT3[n]の終端とEXT2[n]の先頭までの間隔をGAP(EXT3[n],EXT2[n])(単位:ブロック数)とし、MAX_JUMP(SEXT3[n])はSEXT3[n]の距離をジャンプする時間でジャンプできる最大ジャンプ距離(単位:ブロック数)とし、MAX_JUMP(SEXT2[n])はSEXT2[n]の距離をジャンプする時間でジャンプできる最大ジャンプ距離とする(単位:ブロック数)。例えば、SEXT3[n]が5000×2048(Byte)の場合に、このエクステントをジャンプする時間は図64の例では250msである。この場合、MAX_JUMP(SEXT3[n])は、図64の表により、250msで飛べる最大ジャンプ距離である10000ブロックとなる。式(77)、(78)のように規定することにより、EXT3[n]とEXT2[n]間の間隔によって式(2)、(3)、(4)、(5)におけるTJUMPの値は変動しないため最小エクステントサイズの大きさを、式(75)、(76)に比べて効率的に小さく抑制することが可能である。
なお、インターリーブされたAVストリームのエクステントについてのサイズ制限として、EXT3[n]とEXT2[n]のサイズに次の式のような制約を加え、インターリーブ区間でのギャップは認めないとしても良い。
CEIL(SEXT3[n]/2048)<= MAX_EXTJUMP3D …(79)
CEIL(SEXT2[n]/2048)<= MAX_EXTJUMP3D …(80)
図88に示すように、MAX_EXTJUMP3D(単位:ブロック数)はインターリーブするエクステント区間での最大ジャンプ距離とする。このように規定することによって、エクステント間の最大ジャンプ距離を、固定化することができ、例えばMAX_EXTJUMP3Dを10000ブロックとした場合には、TJUMPに入る値は常に一定の固定値を超えない。(図64でいえば250msを超えない)
<実施形態2>
実施形態1では、図54に示すように第1リード・バッファ4921と第2リード・バッファ4922の二つのバッファを利用して、ストリームデータをシステムターゲットデコーダに入力するとしたが、本実施形態2では、1つのリードバッファのみ利用して3D映像再生を実現する構成について説明する。
具体的には、図89のようにリードバッファ(1)3707の1つのバッファにして、システムターゲットデコーダ3703に入力し、図90に示すようにリードバッファ(1)3707からソースデパケタイザ(1)4111とソースデパケタイザ(2)4112に入力するように構成する。
このような構成にすることによって、2D/3D再生装置が3D映像の再生に必要なリードバッファのサイズを小さくすることが可能となる。
図91上段は、第1リード・バッファ4921と第2リード・バッファ4922の二つのバッファを利用する場合の、第1リード・バッファ4921の3D映像再生時のデータ蓄積量の推移を示している。図91中段は、第1リード・バッファ4921と第2リード・バッファ4922の二つのバッファを利用する場合の、第2リード・バッファ4922の3D映像再生時のデータ蓄積量の推移を示している。図91上段の第1リード・バッファ4921の頂点と、図91上段の第2リード・バッファ4922の頂点はかさならないため、第1リード・バッファ4921にEXT1[n]とEXT2[n](もしくはEXT3[n])を入れると、図91下段の線9601のように、二つのリードバッファを設けるよりもバッファサイズを小さくすることが可能である。
この場合、第1リード・バッファ4921からの転送レートは、第1リード・バッファ4921に入力されるAVストリームの合計システムレート×192/188のレートが必要となる。図92上段は、リードバッファを1つの構成にした場合のリードバッファ(1)3707の内部に蓄積されるデータの推移を模式的に示した図である。図92上段は、L/Rモードで再生する場合のデータの推移を示している。また、各箱はリードバッファ(1)3707を示す。9701は、図92下段の3Dエクステントブロックの先頭エクステントであるEXT2[0]を読み込みした時点(A地点)でのリードバッファ(1)3707内部に蓄積されるデータを示す。先頭EXT2[0]を読み込む時点では、システムターゲットデコーダ3703への転送は開始されないため、EXT2[0]のデータがそのままバッファに蓄積される。9702は、EXT1[0]を読み込み中(B地点)のリードバッファ(1)3707内部に蓄積されるデータを示す。システムターゲットデコーダ3703への転送を開始する場合には、リードバッファ(1)3707内のEXT2[0]のデータはシステムターゲットデコーダ3703への転送とともに減少し、また、EXT1[0]のデータはリードバッファ(1)3707に蓄えられると同時に、システムターゲットデコーダ3703への転送とともに減少していく。9703は、EXT1[0]を読み込み完了地点(C地点)のリードバッファ(1)3707内部に蓄積されるデータを示す。9704は、EXT2[1]を読み込み中(D地点)のリードバッファ(1)3707内部に蓄積されるデータを示す。リードバッファ(1)3707内のEXT1[0]のデータはシステムターゲットデコーダ3703への転送とともに減少し、また、EXT2[1]のデータはリードバッファ(1)3707に蓄えられると同時に、システムターゲットデコーダ3703への転送とともに減少していく。このようにリードバッファ(1)3707を制御することで、リードバッファ(1)3707の1つのバッファで実現できる。
ここで、システムターゲットデコーダ3703への転送は、前述したようにソースパケットに付与されたATSのタイミングで行われる。よって、リードバッファ(1)3707に二つのAVストリームを入力した場合に、同じATSが付与されたソースパケットが入力された場合には、リードバッファ(1)3707からシステムターゲットデコーダ3703への二つのソースパケットの転送を同時刻に行うことはできないため、ATSのタイミングでシステムターゲットデコーダ3703への転送ができなくなってしまう。例えば、ATS=100が付与された2D/左目AVストリームのソースパケットと、例えば、ATS=100が付与されたファイルDEPのストリームのソースパケットが存在した場合に、ATS=100の2D/左目AVストリームのソースパケットを先に転送してしまうと、ATS=100のファイルDEPのストリームのソースパケットは、ATS+1ソースパケットの転送時間分ずれて、システムターゲットデコーダのソースデパケタイザ(2)4112に転送されることとなり、システムターゲットデコーダ3703のデコード処理にバッファアンダーフローなどの問題が発生する可能性がある。
そこで、図93上段に示すようにAVストリーム内のソースパケットのATSを設定する。図93上段は、2D/左目AVストリームとファイルDEPのストリームのソースパケット列を示しており、ソースパケットをATC時間で並べている。SP#Nは、各ソースパケットを示し、添え字のNはAVストリームの先頭ソースパケットを0としてインクリメントされる番号である。また各ソースパケットの先頭に付与される矢印はATSのタイミングを示す。また、各ソースパケットの箱の大きさは、2D/3D再生装置が、各ソースパケットをシステムターゲットデコーダへの転送時間(以降、「3Dソースパケット転送時間9801」とする)を示す。また、矢印9801は、2D/3D再生装置の1ソースパケットのリードバッファ(1)3707からシステムターゲットデコーダへの転送時間を示し、矢印9802は、2D再生装置の1ソースパケットのリードバッファからシステムターゲットデコーダへの転送時間(以降、「2Dソースパケット転送時間9802」とする)を示す。
図93上段に示すように、2D/左目AVストリームの隣接するソースパケットのATSの間隔は、2Dソースパケット転送時間9802以上あけなければならない。この制約を守らなければ、2D再生装置のシステムターゲットデコーダへの転送が間に合わなくなってしまうからである。図93下段の例では、2D/左目AVストリームのSP#0とSP#1のATSの間隔は、2D再生装置の1ソースパケットのリードバッファからシステムターゲットデコーダへの転送時間よりも小さいためNGである。また、ファイルDEPのストリームのソースパケットのATSからそのATSに3Dソースパケット転送時間9801を加えたATC時間までの間隔は、2D/左目AVストリームのソースパケットのATSからそのATSに3Dソースパケット転送時間9801を加えたATC時間までの間隔は、オーバラップしてはいけない。図93下段のファイルDEPのストリームのSP#2と2D/左目AVストリームのSP#3はNGのケースとなる。
このような制約を守ってAVストリームを構成することにより、同じATSが付与された二つのソースパケットが1つのリードバッファ(1)3707に入力されることを防ぐことが可能となる。
《実施形態3》
以下、本発明の実施形態3として、本発明の実施形態1による記録媒体の記録装置及び記録方法について説明する。
その記録装置はいわゆるオーサリング装置と呼ばれるものである。オーサリング装置は通常、頒布用の映画コンテンツの制作スタジオに設置され、オーサリングスタッフによって使用される。記録装置はオーサリングスタッフの操作に従い、まず映画コンテンツを、MPEG規格に則った圧縮符号化方式のデジタル・ストリーム、すなわちAVストリーム・ファイルに変換する。記録装置は次にシナリオを生成する。シナリオは、映画コンテンツに含まれる各タイトルの再生方法を規定した情報であり、具体的には上記の動的シナリオ情報及び静的シナリオ情報を含む。記録装置は続いて、上記のデジタル・ストリーム及びシナリオから、BD−ROMディスク用のボリュームイメージ又はアップデートキットを生成する。記録装置は最後に、実施形態1によるエクステントの配置を利用して、ボリュームイメージを記録媒体に記録する。
図93は、その記録装置の内部構成を示すブロック図である。図93を参照するに、その記録装置は、ビデオエンコーダ6301、素材制作部6302、シナリオ生成部6303、BDプログラム制作部6304、多重化処理部6305、フォーマット処理部6306、及びデータベース部6307を含む。
データベース部6307は記録装置に内蔵の不揮発性記憶装置であり、特にハードディスクドライブ(HDD)である。データベース部6307はその他に、記録装置に外付けされたHDDであってもよく、記録装置に内蔵の、又は外付けされた不揮発性半導体メモリ装置であってもよい。
ビデオエンコーダ6301は、非圧縮のビットマップ・データ等の映像データをオーサリングスタッフから受け付けて、それをMPEG−4 AVC又はMPEG−2等の圧縮符号化方式で圧縮する。それにより、主映像のデータはプライマリ・ビデオ・ストリームに変換され、副映像のデータはセカンダリ・ビデオ・ストリームに変換される。特に3D映像のデータはベースビュー・ビデオ・ストリームとディペンデントビュー・ビデオ・ストリームとに変換される。ビデオエンコーダ6301は、レフトビュー・ビデオ・ストリームをそれ自身のピクチャ間での予測符号化によってベースビュー・ビデオ・ストリームに変換し、ライトビュー・ビデオ・ストリームを、それ自身のピクチャだけでなく、ベースビュー・ビデオ・ストリームのピクチャとの間の予測符号化によってディペンデントビュー・ビデオ・ストリームに変換する。尚、ライトビュー・ビデオ・ストリームがベースビュー・ビデオ・ストリームに変換されてもよい。更に、レフトビュー・ビデオ・ストリームがディペンデントビュー・ビデオ・ストリームに変換されてもよい。変換後の各ビデオ・ストリーム6311はデータベース部6307に保存される。
ビデオエンコーダ6301は更に、このピクチャ間予測符号化の処理過程で、左映像と右映像との間での各イメージの動きベクトルを検出し、それらから3D映像内の各イメージの奥行き情報を算出する。算出された各イメージの奥行き情報はフレーム奥行き情報6310に整理されてデータベース部6307に保存される。
図94の(a)、(b)は、3D映像の一シーンの表示に利用される左映像ピクチャと右映像ピクチャとを表す模式図であり、(c)は、ビデオエンコーダ6301によってそれらのピクチャから算出された奥行き情報を示す模式図である。
ビデオエンコーダ6301はまず、左右のピクチャ間の冗長性を利用して各ピクチャを圧縮する。そのとき、ビデオエンコーダ6301は圧縮前の左右のピクチャを8×8又は16×16の画素マトリクスごとに、すなわちマクロブロックごとに比較して、両ピクチャ間での各イメージの動きベクトルを検出する。具体的には、図94の(a)、(b)に示されているように、まず、左映像ピクチャ6401と右映像ピクチャ6402とはそれぞれ、マクロブロック6403のマトリクスに分割される。次に、両ピクチャ6401、6402間でイメージ・データがマクロブロック6403ごとに比較され、その結果から各イメージの動きベクトルが検出される。例えば「家」のイメージ6404を表す領域は両ピクチャ6401、6402間で実質的に等しい。従って、それらの領域からは動きベクトルが検出されない。一方、「球」のイメージ6405を表す領域は両ピクチャ6401、6402間で実質的に異なる。従って、それらの領域からは、「球」のイメージ6405の変位を表す動きベクトルが検出される。
ビデオエンコーダ6301は次に、検出された動きベクトルを各ピクチャ6401、6402の圧縮に利用する一方、各イメージ・データ6404、6405の表す映像の両眼視差の計算にも利用する。こうして得られた両眼視差から、ビデオエンコーダ6301は更に、「家」及び「球」のイメージ6404、6405等、各イメージの「奥行き」を算出する。各イメージの奥行きを表す情報は、例えば図94の(c)に示されているように、各ピクチャ6401、6402のマクロブロックのマトリクスと同じサイズのマトリクス6406に整理される。図93に示されているフレーム奥行き情報6310はこのマトリクス6406を含む。このマトリクス6406内のブロック6407は、各ピクチャ6401、6402内のマクロブロック6403と一対一に対応する。各ブロック6407は、対応するマクロブロック6403の表すイメージの奥行きを、例えば8ビットの深度で表す。図94に示されている例では、「球」のイメージ6405の奥行きが、マトリクス6406の領域6408内の各ブロックに記録される。その領域6408は、そのイメージ6405を表す各ピクチャ6401、6402内の領域の全体に対応する。
図93を再び参照するに、素材制作部6302は、ビデオ・ストリーム以外のエレメンタリ・ストリーム、例えば、オーディオ・ストリーム6312、PGストリーム6313、及びIGストリーム6314を作成してデータベース部6307に保存する。例えば、素材制作部6302はオーサリングスタッフから非圧縮のLPCM音声データを受け付けて、それをAC−3等の圧縮符号化方式で符号化してオーディオ・ストリーム6312に変換する。素材制作部6302はその他に、オーサリングスタッフから字幕情報ファイルを受け付けて、それに従ってPGストリーム6313を作成する。字幕情報ファイルは、字幕を表すイメージ・データ、その字幕の表示時期、及び、その字幕に加えられるべきフェードイン/フェードアウト等の視覚効果を規定する。素材制作部6302は更に、オーサリングスタッフからビットマップ・データとメニューファイルとを受け付けて、それらに従ってIGストリーム6314を作成する。ビットマップ・データはメニューのイメージを表す。メニューファイルは、そのメニューに配置される各ボタンの状態の遷移、及び各ボタンに加えられるべき視覚効果を規定する。
シナリオ生成部6303は、オーサリングスタッフからGUI経由で受け付けられた指示に従ってBD−ROMシナリオ・データ6315を作成し、データベース部6307に保存する。BD−ROMシナリオ・データ6315は、データベース部6307に保存された各エレメンタリ・ストリーム6311−6314の再生方法を規定する。BD−ROMシナリオ・データ6315は、図7に示されているファイル群のうち、インデックス・ファイル511、ムービーオブジェクト・ファイル512、及びプレイリスト・ファイル521−523を含む。シナリオ生成部6303は更にパラメータ・ファイル6316を作成して多重化処理部6305へ送出する。パラメータ・ファイル6316は、データベース部6307に保存されたエレメンタリ・ストリーム6311−6314の中から、メインTSとサブTSとのそれぞれに多重化されるべきストリーム・データを規定する。
BDプログラム制作部6304はオーサリングスタッフに対して、BD−Jオブジェクト及びJava(登録商標)アプリケーション・プログラムのプログラミング環境を提供する。BDプログラム制作部6304はGUIを通じてユーザからの要求を受け付け、その要求に従って各プログラムのソースコードを作成する。BDプログラム制作部6304は更に、BD−JオブジェクトからBD−Jオブジェクト・ファイル551を作成し、Java(登録商標)アプリケーション・プログラムをJARファイル561に圧縮する。それらのファイル551、561はフォーマット処理部6306へ送出される。
ここで、BD−Jオブジェクトが次のようにプログラミングされる場合を想定する:BD−Jオブジェクトは、図54、59に示されているプログラム実行部4606、4906にGUI用のグラフィックス・データをシステム・ターゲット・デコーダ4603、4903へ送出させる。BD−Jオブジェクトは更に、システム・ターゲット・デコーダ4603、4903にそのグラフィックス・データをイメージ・プレーン・データとして処理させる。その場合、BDプログラム制作部6304は、データベース部6307に保存されたフレーム奥行き情報6310を利用して、BD−Jオブジェクトにイメージ・プレーン・データに対するオフセット情報を設定してもよい。
多重化処理部6305はパラメータ・ファイル6316に従い、データベース部6307に保存されている各エレメンタリ・ストリーム6311−6314をMPEG2−TS形式のストリーム・ファイルに多重化する。具体的には図10に示されているように、各エレメンタリ・ストリームがソースパケット列に変換され、各列のソースパケットが一列にまとめられて一本の多重化ストリーム・データを構成する。こうして、メインTSとサブTSとが作成される。
その処理と並行して、多重化処理部6305は、2Dクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとを以下の手順で作成する。まず、ファイル2DとファイルDEPとのそれぞれについて、図39に示されているエントリ・マップ3130が生成される。次に、各ファイルのエントリ・マップを利用して、図40に示されているエクステント起点の一覧表3310が作成される。続いて、メインTSとサブTSとのそれぞれに多重化されるべき各エレメンタリ・ストリームから、図38に示されているストリーム属性情報が抽出される。更に、図38に示されているように、エントリ・マップ、3Dメタデータ、及びストリーム属性情報の組み合わせがクリップ情報に対応付けられる。
フォーマット処理部6306は、データベース部6307に保存されたBD−ROMシナリオ・データ6315、BDプログラム制作部6304によって制作されたBD−Jオブジェクト・ファイル等のプログラム・ファイル群、及び、多重化処理部6305によって生成された多重化ストリーム・データとクリップ情報ファイルとから、図7に示されているディレクトリ構造のBD−ROMディスクイメージ6320を作成する。そのディレクトリ構造では、ファイルシステムとしてUDFが利用される。
フォーマット処理部6306は、ファイル2D、ファイルDEP、及びファイルSSの各ファイル・エントリを作成するとき、2Dクリップ情報ファイルとディペンデントビュー・クリップ情報ファイルとのそれぞれに含まれるエントリ・マップと3Dメタデータとを参照する。それにより、各エントリ・ポイントと各エクステント起点とのSPNが各アロケーション記述子の作成に利用される。特に図15に示されているようなインターリーブ配置が表現されるようにアロケーション記述子が作成される。それにより、各ベースビュー・データ・ブロックはファイルSSとファイル2Dとに共有され、各ディペンデントビュー・データ・ブロックはファイルSSとファイルDEPとに共有される。一方、ロングジャンプの必要な箇所では、図20、24、26、28、30、32のそれぞれに示されている配置1−6のいずれかが表現されるようにアロケーション記述子が作成される。特に、ベースビュー・データ・ブロックの一部は2D再生専用ブロックとしてファイル2D内のアロケーション記述子によってのみ参照され、その一部の複製データが3D再生専用ブロックとしてファイルSSのアロケーション記述子によってのみ参照される。更に、ベースビューとディペンデントビューとのエクステントの各サイズが式(1)−(5)を満たすように設計され、それに基づいて、各アロケーション記述子の表すべき論理アドレスの値が決定される。
フォーマット処理部6306はその他に、データベース部6307に保存されたフレーム奥行き情報6310を利用して、図39の(a)に示されているオフセット・テーブルを、セカンダリ・ビデオ・ストリーム6311、PGストリーム6313、及びIGストリーム6314のそれぞれについて作成する。フォーマット処理部6306は更にオフセット・テーブルを2Dクリップ情報ファイルの3Dメタデータ内に格納する。ここで、各ストリームの表す3D映像が、他のストリームの表す3D映像と同じ視方向に重なって表示されないように、左右の各映像フレーム内でのイメージ・データの配置が自動的に調整される。更に、各ストリームの表す3D映像の奥行きが互いに重ならないように、各映像フレームに対するオフセット値が自動的に調整される。
フォーマット処理部6306によって生成されたBD−ROMディスクイメージ6320はその後、BD−ROMプレス用データに変換される。更に、このデータはBD−ROMディスクの原盤に記録される。この原盤がプレス工程に利用されることにより、本発明の実施形態1による記録媒体100の大量生産が実現可能になる。
《実施形態4》
本実施形態では、前述の実施形態において説明された構造のデータを再生する再生装置に関して、集積回路3を用いて実現した構成例(図95)について説明する。
媒体IF部1は、媒体からデータを受信して(読み出して)、集積回路3に転送する。なお媒体IF部1は、前述の実施形態において説明した構造のデータを媒体から受信する。媒体IF部1は、例えば、媒体が光ディスクやハードディスクの場合はディスクドライブ、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波の場合はCANチューナーやSiチューナー、媒体がイーサネット(登録商標)、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。
メモリ2は、媒体から受信した(読み出した)データを一旦格納したり、集積回路3における処理途中のデータを一時的に格納するメモリで、例えばSDRAM(Synchronous Dynamic Random Access Memory)、DDRx SDRAM(Double-Date-Ratex Synchronous Dynamic Random Access Memory;x=1,2,3・・・)等が用いられる。なおメモリ2は、任意の個数備えていればよく、必要に応じて単数でも複数でも構わない。
集積回路3は、媒体IF部1から転送されたデータに対して映像・音声処理を施すシステムLSIで、主制御部6、ストリーム処理部5、信号処理部7、メモリ制御部9、AV出力部8等から構成される。
主制御部6は、タイマ機能や割り込み機能を有するプロセッサコアを有し、プロセッサコアはプログラムメモリ等に格納されたプログラムに従って、集積回路3全体の制御を行う。なお、プログラムメモリ等には、予めOS等の基本ソフトが格納されている。
ストリーム処理部5は、主制御部6の制御の下、媒体から媒体IF部1経由で転送されたデータを受信し、集積回路3内のデータバスを経由してメモリ2に格納したり、受信したデータを映像系データ、音声系データに分離する。前述したとおり、レフトビュービデオストリームを含む2D/L用のAVクリップとライトビュービデオストリームを含むR用のAVクリップが、それぞれ幾つかのエクステントに分割された状態で媒体上に配置されている(例えば、図41、もしくは図81、82参照(マルチアングル))。従って、主制御部6は、集積回路3がレフトビューストリームを含む左目用データを受信した場合は、メモリ2の第1の領域にデータが格納されるように、ライトビュービデオストリームを含む右目用データを受信した場合は、メモリ2の第2の領域にデータが格納されるように制御する。ここで、左目用データは左目用エクステントに属しており、右目用データは右目用エクステントに属している。なお、メモリ2における第1、第2の領域は単一のメモリが論理的に領域分割されたものでもよいし、物理的に異なるメモリでもよい。また、本実施形態においては、レフトビュービデオストリームを含む左目用データをメインビューデータ、ライトビュービデオストリームを含む右目用データをサブビューデータとして説明を続けるが、右目用データがメインビューデータ、左目用データがサブビューデータであっても構わない。
信号処理部7は、主制御部6の制御の下、ストリーム処理部5が分離した映像系データ、音声系データに対し、適切な方式でデコードする。映像系データは、MPEG-2、MPEG-4 AVC、MPEG4-MVC、SMPTE VC-1などの方式を使って符号化記録されており、また音声系データは、ドルビーAC-3、Dolby Digital Plus、MLP、DTS、DTS-HD、リニアPCMなどの方式で圧縮・符号化記録されているので、信号処理部7はこれらに対応した方式でデコードする。なお、信号処理部7のモデルは、例えば第9実施形態の図65における各種デコーダがそれに当たる。
メモリ制御部9は、集積回路3内の各機能ブロックからメモリ2へのアクセスを調停する。
AV出力部8は、主制御部6の制御の下、信号処理部7においてデコードされた映像系データを重畳したり、映像系及データのフォーマット変換等をして集積回路3外へ出力する。
図96は、ストリーム処理部5の代表的な構成を示す機能ブロック図である。ストリーム処理部5は、デバイス・ストリームIF部51、多重分離部52、切替部53等を備える。
デバイス・ストリームIF部51は、媒体IF部1と集積回路3間のデータ転送用インターフェースであり、例えば、媒体が光ディスクやハードディスクの場合はSATA(Serial Advanced Technology Attachment)、ATAPI(Advanced Technology Attachment Packet Interface)、PATA(Parallel Advanced Technology Attachment)、媒体がSDカードやUSBメモリ等の半導体メモリの場合はカードIF、媒体がCATV等を含む放送波などの場合はチューナーIF、媒体がイーサネット(登録商標)、無線LAN、無線公衆回線等のネットワークの場合は、ネットワークIF、等である。なお、媒体の種類によっては、デバイス・ストリームIF部51が媒体IF部1の機能の一部を肩代わりしても構わないし、媒体IF部1が集積回路3に内蔵されていても構わない。
多重分離部52は、媒体から転送された映像・音声を含む再生データを映像系データと音声系データに分離する。前述の各エクステントは、映像・音声・PG(字幕)・IG(メニュー)等の各ソースパケットから構成されており(但し、サブビューデータは音声を含まない場合もある)、各ソースパケットに含まれているPID(識別子)に従って、映像系・音声系の各TSパケットに分離し、信号処理部7に転送する。処理済のデータは、直接もしくは一旦メモリ2に格納された後、信号処理部7に転送される。なお、多重分離部52のモデルは、例えば第9実施形態の図65におけるソースデパケタイザ、PIDフィルタがそれに当たる。
切替部53は、デバイス・ストリームIF部51が左目用データを受信した時はメモリ2の第1の領域に格納されるように、右目用データを受信した時はメモリ2の第2の領域に格納されるように、出力先(格納先)を切り替える。ここで、切替部53は例えばDMAC(Direct Memory Access Controller)である。図97は切替部53がDMACであった場合の切替部53周辺の概念図である。DMACは、主制御部6の制御の下、デバイス・ストリームIF部が受信したデータとそのデータ格納先アドレスをメモリ制御部9に対して送信する。具体的には、デバイス・ストリームIF部が左目用データを受信した時はアドレス1(第1の格納領域)を、右目用データを受信した時はアドレス2(第2の格納領域)をメモリ制御部9に送信することで、受信データによってその出力先(格納先)を切り替えている。メモリ制御部9は、DMACから送られてきた格納先アドレスに従ってメモリ2にデータを格納する。なお、主制御部6は、再生データに先立って受信されメモリ2に格納されている前述のCLIPINFに含まれるエクステント起点(立体視再生の場合は、前述のファイルベースもしくはファイルディペンデント)を利用して切替部53を制御する。つまり、主制御部6は、ファイルベースを利用してデバイス・ストリームIF部51が受信したデータが左目用データであることを認識し、切替部53を制御し、デバイス・ストリームIF部51が受信したデータが右目用データであることを認識し、切替部53を制御してメモリ2への出力先(格納先)を切り替える。また、主制御部6の代わりに切替部53を制御する専用の回路を設けても構わない。
ここでは、ストリーム処理部5の代表的な構成として、デバイス・ストリームIF部51、多重分離部52、切替部53について説明したが、受信した暗号化データや鍵データ等を復号する暗号エンジン部、媒体〜再生装置間の機器認証プロトコル等の実行制御や秘密鍵を保持するセキュア管理部、ダイレクトメモリアクセス用のコントローラ等を更に備えていてもよい。これまでは媒体から受信したデータをメモリ2に格納する際に、切替部53が左目用データ・右目用データかによって格納先を切り替える場合について説明してきたが、媒体から受信したデータを一旦メモリ2に格納した後に、多重分離部52へデータを転送する際に、左目用データ・右目用データを振り分けてもよい。
図98は、AV出力部8の代表的な構成を示す機能ブロック図である。AV出力部8は、画像重畳部81と、ビデオ出力フォーマット変換部82、オーディオ・ビデオ出力IF部83等を備える。
画像重畳部81は、デコードされた映像系のデータを重畳する。具体的には、レフトビュービデオデータもしくはライトビュービデオデータと、PG(字幕)、IG(メニュー)をピクチャ単位で重畳する。画像重畳部81のモデルは、例えば第11実施形態、図98などである。
ビデオ出力フォーマット変換部82は、デコードされた映像系データに対して、拡大または縮小するリサイズ処理、走査方式をプログレッシブ方式及びインターレース方式の一方から他方に変換するIP変換処理、ノイズを除去するノイズリダクション処理、フレームレートを変換するフレームレート変換処理などを必要に応じて行う。
オーディオ・ビデオ出力IF部83は、画像重畳やフォーマット変換された映像系データとデコードされた音声系データとに対して、データ送信形式に合わせてエンコード等を行う。なお、後述するようにオーディオ・ビデオ出力IF部83は、一部集積回路3外に備えられても構わない。
図99は、AV出力部8もしくは再生装置のデータ出力部分を、より詳細に示した構成例である。本実施の形態における集積回路3及び再生装置は、複数の映像系データ、音声系データのデータ送信形式に対応している。図98におけるオーディオ・ビデオ出力IF部83は、アナログビデオ出力IF部83a、アナログオーディオ出力IF部83c、デジタルビデオ・オーディオ出力IF部83bに対応する。
アナログビデオ出力IF部83aは、画像重畳処理や出力フォーマット変換処理された映像系データを、アナログ映像信号形式に変換・エンコードし、出力する。例えば、NTSC、PAL、SECAMの3方式のいずれかに対応したコンポジットビデオエンコーダー、S映像信号(Y/C分離)用エンコーダー、コンポーネント映像信号用エンコーダーや、DAC(D/Aコンバータ)等がそれに当たる。
デジタルオーディオ・ビデオ出力IF部83bは、デコードされた音声系データと画像重畳処理や出力フォーマット変換された映像系データを一体化、更に暗号化した後、データ送信規格に合わせてエンコードし、出力する。例えば、HDMI(High−Definition Multimedia InterFace)等がそれに当たる。
アナログオーディオ出力IF部83cは、デコードされた音声系データをD/A変換しアナログ音声データを出力するオーディオDAC等がそれに当たる。
これら映像系データ及び音声系データの送信形式は、表示装置・スピーカー4側がサポートしているデータ受信装置(データ入力端子)に依存して切り替えたり、またユーザーの選択によって送信形式を切り替えることが可能である。更に、単一の送信形式だけではなく、並行して複数の送信形式にて同一のコンテンツに対応したデータを送信することも可能である。
ここでは、AV出力部8の代表的な構成として、画像重畳部81、ビデオ出力フォーマット変換部82、オーディオ・ビデオ出力IF部83について説明したが、フィルタ処理、画面合成、曲線描画、3D表示等のグラフィックス処理を行うグラフッィクスエンジン部等を更に備えていてもよい。
以上が、本実施の形態における再生装置の構成についての説明である。なお、前述の集積回路3に含まれる各機能ブロックは全てが内蔵されていなくても良いし、逆に図95のメモリ2が集積回路3に内蔵されていてもよい。また、本実施形態においては、主制御部6と信号処理部7は異なる機能ブロックとして説明してきたが、主制御部6が信号処理部7の処理の一部を行っても構わない。
また、集積回路3における制御バスやデータバスの経路は、各処理ブロックの処理手順や処理内容によって任意に配置されるが、例えば図100のように、各処理ブロックどうしを直接結ぶようにデータバスを配置してもよいし、図101のように各処理ブロックどうしをメモリ2(メモリ制御部9)を介して結ぶようにデータバスを配置してもよい。
また、集積回路3は、複数のチップを一つのパッケージに封止し、見かけ上一つのLSIにしたマルチチップ・モジュールであっても構わない。
また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
次に、以上のように構成された再生装置の動作について説明する。
図102は、媒体からデータを受信し(読み出し)、デコードした後に、映像信号及び音声信号として出力する再生動作手順を簡単に示すフローチャートである。
S1:媒体からデータを受信する(読み出す)(媒体IF部1、ストリーム処理部5)。
S2:S1において受信された(読み出された)データを各種データ(映像系データ・音声系データ)に分離する(ストリーム処理部5)。
S3:S2において分離された各種データを適切な形式でデコードする(信号処理部7)。
S4:S3においてデコード処理された各種データのうち、映像系のものについて重畳処理を行う(AV出力部8)。
S6:S2〜S5において処理された映像系データ及び音声系データを出力する(AV出力部8)。
図103は、より詳細に再生動作手順を示したフローチャートである。各動作・処理は、主制御部6の制御の下、行われる。
S101:ストリーム処理部5のデバイス・ストリームIF部51は、媒体IF部1を通して媒体に格納されている再生されるデータ以外の、データを再生するために必要なデータ(PLAYLIST、CLIPINF等)を受信し(読み出し)、メモリ2に格納する(媒体IF部1、デバイスIF部51、メモリ制御部9、メモリ2)。
S102:主制御部6は、受信されたCLIPINFに含まれるストリーム属性情報から、媒体に格納されている映像データ及び音声データの圧縮形式を認識し、対応するデコード処理ができるように信号処理部7の初期化を行う(主制御部6)。
S103:ストリーム処理部5のデバイス・ストリームIF部51は、媒体IF部1を通して媒体に格納されている映像・音声など再生されるデータを受信し(読み出し)、切替部53、メモリ制御部9を経由してメモリ2に格納する。なお、データはエクステント単位で受信し(読み出され)、左目用データを受信した(読み出した)時は第1の領域へ、右目用データを受信した(読み出した)時は第2の領域へ格納されるよう、主制御部6が切替部53を制御し、切替部53がデータの出力先(格納先)を切り替える(媒体IF部1、デバイスIF部51、主制御部6、切替部53、メモリ制御部9、メモリ2)。
S104:メモリ2に格納されたデータは、ストリーム処理部5の多重分離部52に転送され、多重分離部52はストリームデータを構成するソースパケットに含まれるPIDに従って映像系(主映像、副映像、PG(字幕)、IG(メニュー))、音声系(音声、副音声)のいずれであるか認識し、TSパケット単位で信号処理部7の対応する各デコーダへ転送する。(多重分離部52)。
S105:信号処理部7の各デコーダは、転送されてきたTSパケットに対して、適切な方式でデコード処理を行う(信号処理部7)。
S106:信号処理部7においてデコードされた映像系データのうち、レフトビュービデオストリーム及びライトビュービデオストリームに対応するデータを、表示装置4に合わせてリサイズする(ビデオ出力フォーマット変換部82)。
S107:S106においてリサイズされたビデオストリームと、PG(字幕)・IG(メニュー)とが重畳される(画像重畳部81)。
S108:S107において重畳された映像データに対して、走査方式の変換であるIP変換を行う(ビデオ出力フォーマット変換部82)。
S109:これまでの処理を行った映像系データ及び音声系データに対して、表示装置・スピーカー4のデータ出力方式、もしくは表示装置・スピーカー4へのデータ送信方式に従って、エンコードやD/A変換等を行う。例えば、映像系データ・音声系データをそれぞれ、アナログまたはデジタル出力に対応するために処理を行う。映像系データのアナログ出力としては、コンポジット映像信号やS映像信号やコンポーネント映像信号等をサポートしている。また映像系・音声系データのデジタル出力は、HDMIをサポートしている(オーディオ・ビデオ出力IF部83)。
S110:S109において処理された映像系データ及び音声系データを、表示装置・スピーカー4に送信、出力する(オーディオ・ビデオ出力IF部83、表示装置・スピーカー4)。
以上が、本実施の形態における再生装置の動作手順の説明である。なお、処理ごとに処理結果をメモリ2に一旦格納しても構わない。また、本動作手順では、ビデオ出力フォーマット変換部82においてリサイズ処理及びIP変換処理を行う場合について説明したが、必要に応じて処理を省略しても構わないし、また他の処理(ノイズリダクション処理、フレームレート変換処理等)を行っても構わない。更に、可能なものについては処理手順を変更しても構わない。
<補足>
≪放送、通信回路を経由したデータ配信≫
本発明の実施形態1による記録媒体は、光ディスクの他、例えばSDメモリカードを含む可搬性半導体メモリ装置等、パッケージメディアとして利用可能なリムーバブルメディア全般を含む。また、実施形態1の説明では、予めデータが記録された光ディスク、すなわち、BD−ROM又はDVD−ROM等の既存の読み出し専用の光ディスクが例に挙げられている。しかし、本発明の実施形態はそれらに限定されない。例えば放送で、又はネットワーク経由で配信された3D映像のコンテンツを端末装置によって、BD−RE又はDVD−RAM等の既存の書き込み可能な光ディスクへ書き込むときに、実施形態1によるエクステントの配置が利用されてもよい。ここで、その端末装置は、再生装置に組み込まれていても、再生装置とは別の装置であってもよい。
≪半導体メモリカードの再生≫
本発明の実施形態1による記録媒体として、光ディスクに代えて半導体メモリカードを用いたときにおける、再生装置のデータ読み出し部について説明する。
再生装置のうち、光ディスクからデータを読み出す部分は、例えば光ディスクドライブによって構成される。それに対し、半導体メモリカードからデータを読み出す部分は、専用のインタフェース(I/F)で構成される。より詳細には、再生装置にカードスロットが設けられ、その内部に上記のI/Fが実装される。そのカードスロットに半導体メモリカードが挿入されるとき、そのI/Fを通してその半導体メモリカードが再生装置と電気的に接続される。更に、半導体メモリカードからデータがそのI/Fを通して再生装置に読み出される。
≪BD−ROMディスク上のデータに対する著作権保護技術≫
ここで、以降の補足事項の前提として、BD−ROMディスクに記録されているデータの著作権を保護するための仕組みについて説明する。
BD−ROMディスクに記録されたデータの一部が、例えば著作権の保護又はデータの秘匿性の向上の観点から暗号化されている場合がある。その暗号化データは例えば、ビデオ・ストリーム、オーディオ・ストリーム、又はその他のストリームを含む。その場合、暗号化データは以下のように解読される。
再生装置には予め、BD−ROMディスク上の暗号化データを解読するための「鍵」の生成に必要なデータの一部、すなわちデバイスキーが記憶されている。一方、BD−ROMディスクには、そのその「鍵」の生成に必要なデータの別の一部、すなわちMKB(メディアキーブロック)と、その「鍵」自体の暗号化データ、すなわち暗号化タイトルキーとが記録されている。デバイスキー、MKB、及び暗号化タイトルキーは互いに対応付けられ、更に、図6に示されている記録媒体100上のBCA201に書き込まれた特定のID、すなわちボリュームIDにも対応付けられている。デバイスキー、MKB、暗号化タイトルキー、及びボリュームIDの組み合わせが正しくなければ、暗号化データの解読はできない。すなわち、これらの組み合わせが正しい場合にのみ、上記の「鍵」、すなわちタイトルキーが生成される。具体的には、まず、デバイスキー、MKB、及びボリュームIDを利用して暗号化タイトルキーが復号される。それによってタイトルキーを導き出すことができたときのみ、そのタイトルキーを上記の「鍵」として用いて暗号化データを解読することができる。
BD−ROMディスク上の暗号化データを再生装置によって再生しようとしても、例えばそのBD−ROMディスク上の暗号化タイトルキー、MKB、及びボリュームIDに予め対応付けられたデバイスキーがその再生装置内に記憶されていなければ、その暗号化データを再生することができない。何故なら、その暗号化データの解読に必要な鍵、すなわちタイトルキーは、MKB、デバイスキー、及びボリュームIDの正しい組み合わせで暗号化タイトルキーを復号しなければ導き出せないからである。
BD−ROMディスクに記録されるべきビデオ・ストリームとオーディオ・ストリームとの少なくともいずれかの著作権を保護するには、まず、保護対象のストリームをタイトルキーで暗号化して、BD−ROMディスクに記録する。次に、MKB、デバイスキー、及びボリュームIDの組み合わせから鍵を生成し、その鍵で上記のタイトルキーを暗号化して暗号化タイトルキーに変換する。更に、MKB、ボリュームID、及び暗号化タイトルキーをBD−ROMディスクに記録する。そのBD−ROMディスクからは、上述の鍵の生成に利用されたデバイスキーを備えた再生装置でしか、暗号化されたビデオ・ストリーム及び/又はオーディオ・ストリームをデコーダで復号することはできない。こうして、BD−ROMディスクに記録されたデータの著作権を保護することができる。
以上に述べた、BD−ROMディスクにおけるデータの著作権保護の仕組みは、BD−ROMディスク以外にも適用可能である。例えば読み書き可能な半導体メモリ装置、特にSDカード等の可搬性半導体メモリカードにも適用可能である。
≪電子配信を利用した記録媒体へのデータ記録≫
電子配信を利用して本発明の実施形態1による再生装置へ3D映像のAVストリーム・ファイル等のデータ(以下、配信データという。)を伝達し、更にその再生装置にその配信データを半導体メモリカードに記録させる処理について、以下説明する。尚、以下の動作は、上記の再生装置に代えて、その処理に特化した端末装置によって行われてもよい。また、記録先の半導体メモリカードがSDメモリカードである場合を想定する。
再生装置は上記のとおり、カードスロットを備えている。そのカードスロットにはSDメモリカードが挿入されている。この状態で、再生装置はまず、ネットワーク上の配信サーバへ配信データの送信要求を送出する。このとき、再生装置はSDメモリカードからその識別情報を読み出して、その識別情報を送信要求と共に配信サーバへ送出する。SDメモリカードの識別情報は、例えばそのSDメモリカード固有の識別番号、より具体的にはそのSDメモリカードのシリアル番号である。この識別情報は上述のボリュームIDとして利用される。
配信サーバには配信データが格納されている。その配信データのうち、ビデオ・ストリーム及び/又はオーディオ・ストリーム等、暗号化による保護の必要なデータは、所定のタイトルキーを用いて暗号化されている。その暗号化データは同じタイトルキーで復号が可能である。
配信サーバは、再生装置と共通の秘密鍵としてデバイスキーを保持している。配信サーバは更に、SDメモリカードと共通のMKBを保持している。配信サーバは、再生装置から配信データの送信要求とSDメモリカードの識別情報とを受け付けたとき、まず、デバイスキー、MKB、及びその識別情報から鍵を生成し、その鍵でタイトルキーを暗号化して暗号化タイトルキーを生成する。
配信サーバは次に公開鍵情報を生成する。その公開鍵情報は、例えば、上述のMKB、暗号化タイトルキー、署名情報、SDメモリカードの識別番号、及びデバイスリストを含む。署名情報は、例えば公開鍵情報のハッシュ値を含む。デバイスリストは、無効にすべきデバイス、すなわち、配信データ中の暗号化データを不正に再生する危険性のあるデバイスのリストである。そのリストには、例えば、再生装置のデバイスキー、再生装置の識別番号、再生装置に内蔵のデコーダ等、各種部品の識別番号、又は機能(プログラム)が特定されている。
配信サーバは更に、配信データと公開鍵情報とを再生装置へ送出する。再生装置は、それらを受信して、カードスロット内の専用I/Fを通してSDメモリカードに記録する。
SDメモリカードに記録された配信データのうち、暗号化データは、例えば公開鍵情報を以下のように利用して復号される。まず、公開鍵情報の認証として次の三種類のチェック(1)−(3)が行われる。尚、それらはどのような順序で行われてもよい。
(1)公開鍵情報に含まれるSDメモリカードの識別情報が、カードスロットに挿入されているSDメモリカードに記憶されている識別番号と一致するか否か。
(2)公開鍵情報から算出されるハッシュ値が、署名情報に含まれるハッシュ値と一致するか否か。
(3)公開鍵情報の示すデバイスリストから当該再生装置が除外されているか否か。具体的には、デバイスリストから当該再生装置のデバイスキーが除外されているか否か。
上述のチェック(1)−(3)のいずれかの結果が否定的であるとき、再生装置は暗号化データの復号処理を中止する。逆に、上述のチェック(1)−(3)の全ての結果が肯定的であるとき、再生装置は公開鍵情報の正当性を認め、デバイスキー、MKB、及びSDメモリカードの識別情報を利用して、公開鍵情報内の暗号化タイトルキーをタイトルキーに復号する。再生装置は更に、そのタイトルキーを用いて暗号化データを、例えばビデオ・ストリーム及び/又はオーディオ・ストリームに復号する。
以上の仕組みには次の利点がある。電子配信時に既に、不正使用の危険性がある再生装置、部品、及び機能(プログラム)等が知られている場合、これらの識別情報がデバイスリストに列挙され、公開鍵情報の一部として配信される。一方、配信データを要求した再生装置は必ず、そのデバイスリスト内の識別情報を、その再生装置及びその部品等の識別情報と照合しなければならない。それにより、その再生装置又はその部品等がデバイスリストに示されていれば、たとえ、SDメモリカードの識別番号、MKB、暗号化タイトルキー、及びデバイスキーの組み合わせが正しくても、その再生装置は公開鍵情報を配信データ内の暗号化データの復号には利用できない。こうして、配信データの不正使用を効果的に抑制することができる。
半導体メモリカードの識別情報は、半導体メモリカード内の記録領域のうち、特に秘匿性の高い記録領域に格納することが望ましい。何故なら、万一、その識別情報、例えばSDメモリカードではそのシリアル番号が不正に改竄された場合、SDメモリカードの違法コピーが容易に実行可能になってしまうからである。すなわち、その改竄の結果、同一の識別情報を持つ半導体メモリカードが複数存在するようになれば、上述のチェック(1)では正規品と違法な複製品との識別ができなくなるからである。従って、半導体メモリカードの識別情報は秘匿性の高い記録領域に記録して、不正な改竄から保護されねばならない。
半導体メモリカード内にこのような秘匿性の高い記録領域を構成する手段は、例えば次のとおりである。まず、通常のデータ用の記録領域(以下、第1の記録領域と称す。)から電気的に分離された別の記録領域(以下、第2の記録領域と称す。)が設置される。次に、第2の記録領域へのアクセス専用の制御回路が半導体メモリカード内に設けられる。それにより、第2の記録領域へはその制御回路を介してのみアクセスが可能であるようにする。例えば、第2の記録領域には、暗号化されたデータのみが記録され、その暗号化されたデータを復号するための回路が制御回路内にのみ組み込まれる。それにより、第2の記録領域内のデータへのアクセスは、そのデータを制御回路に復号させなければ不可能である。その他に、第2の記録領域内の各データのアドレスを制御回路にのみ保持させてもよい。その場合、第2の記録領域内のデータのアドレスは制御回路にしか特定できない。
半導体メモリカードの識別情報が第2の記録領域に記録された場合、再生装置上で動作するアプリケーション・プログラムは、電子配信を利用して配信サーバからデータを取得して半導体メモリカードに記録する場合、次のような処理を行う。まず、そのアプリケーション・プログラムは、メモリカードI/Fを介して上記の制御回路に対し、第2の記録領域に記録された半導体メモリカードの識別情報へのアクセス要求を発行する。制御回路はその要求に応じて、まず、第2の記録領域からその識別情報を読み出す。制御回路は次に、メモリカードI/Fを介して上記のアプリケーション・プログラムへその識別情報を送る。そのアプリケーション・プログラムはその後、その識別情報と共に配信データの送信要求を配信サーバに送出する。アプリケーション・プログラムは更に、その要求に応じて配信サーバから受信される公開鍵情報と配信データとを、メモリカードI/Fを介して半導体メモリカード内の第1の記録領域に記録する。
尚、上記のアプリケーション・プログラムは、半導体メモリカード内の制御回路に対して上記のアクセス要求を発行する前に、そのアプリケーション・プログラム自体の改竄の有無をチェックすることが望ましい。そのチェックには、例えばX.509に準拠のデジタル証明書が利用されてもよい。また、配信データは上記のとおり、半導体メモリカード内の第1の記録領域に記録されればよく、その配信データへのアクセスは半導体メモリカード内の制御回路によって制御されなくてもよい。
≪リアルタイム・レコーディングへの適用≫
本発明の実施形態3では、AVストリーム・ファイル及びプレイリスト・ファイルは、オーサリングシステムにおけるプリレコーディング技術によってBD−ROMディスクに記録されてユーザに供給されることを前提とした。しかし、AVストリーム・ファイル及びプレイリスト・ファイルは、リアルタイム・レコーディングによって、BD−REディスク、BD−Rディスク、ハードディスク、又は半導体メモリカード等の書き込み可能な記録媒体(以下、BD−REディスク等と略す。)に記録されてユーザに供給されるものであってもよい。その場合、AVストリーム・ファイルは、アナログ入力信号を記録装置がリアルタイムで復号することによって得られたトランスポート・ストリームであってもよい。その他に、記録装置がデジタル入力したトランスポート・ストリームをパーシャル化することで得られるトランスポート・ストリームであってもよい。
リアルタイム・レコーディングを実行する記録装置は、ビデオエンコーダ、オーディオエンコーダ、マルチプレクサ、及びソースパケタイザを含む。ビデオエンコーダはビデオ信号を符号化してビデオ・ストリームに変換する。オーディオエンコーダはオーディオ信号を符号化してオーディオ・ストリームに変換する。マルチプレクサは、ビデオ・ストリームとオーディオ・ストリームとを多重化して、MPEG2−TS形式のデジタル・ストリームに変換する。ソースパケタイザは、MPEG2−TS形式のデジタル・ストリーム内のTSパケットをソースパケットに変換する。記録装置は各ソースパケットをAVストリーム・ファイルに格納して、BD−REディスク等に書き込む。
AVストリーム・ファイルの書き込み処理と並行して、記録装置の制御部はクリップ情報ファイルとプレイリスト・ファイルとをメモリ上で生成してBD−REディスク等に書き込む。具体的には、ユーザによって録画処理が要求されたとき、制御部はまず、AVストリーム・ファイルに合わせてクリップ情報ファイルを生成してBD−REディスク等に書き込む。その場合、外部から受信されるトランスポート・ストリームからビデオ・ストリーム内の一つのGOPの先頭が検出される度に、又は、ビデオエンコーダによってビデオ・ストリーム内の一つのGOPが生成される度に、制御部は、そのGOPの先頭に位置するIピクチャのPTSと、そのGOPの先頭が格納されたソースパケットのSPNとを取得する。制御部は更に、そのPTSとSPNとの対を一つのエントリ・ポイントとしてクリップ情報ファイルのエントリ・マップに追記する。ここで、そのエントリ・ポイントには「is_angle_changeフラグ」が追加される。is_angle_changeフラグは、そのGOPの先頭がIDRピクチャであるときは“オン”に設定され、そのGOPの先頭がIDRピクチャではないときは“オフ”に設定される。クリップ情報ファイル内には更に、ストリーム属性情報が記録対象のストリームの属性に従って設定される。こうして、AVストリーム・ファイルとクリップ情報ファイルとがBD−REディスク等に書き込まれた後、制御部はそのクリップ情報ファイル内のエントリ・マップを利用してプレイリスト・ファイルを生成し、BD−REディスク等に書き込む。
≪マネージド・コピー≫
本発明の実施形態1による再生装置は更に、マネージド・コピーによって記録媒体100上のデジタル・ストリームを他の記録媒体へ書き込んでもよい。「マネージド・コピー」とは、BD−ROMディスク等の読み出し専用記録媒体から書き込み可能な記録媒体へ、デジタル・ストリーム、プレイリスト・ファイル、クリップ情報ファイル、及びアプリケーション・プログラムをコピーすることを、サーバとの通信による認証が成功した場合にのみ許可するための技術をいう。その書き込み可能な記録媒体は、BD−R、BD−RE、DVD−R、DVD−RW、及びDVD−RAM等の書き込み可能な光ディスク、ハードディスク、並びに、SDメモリカード、メモリースティック(登録商標)、コンパクトフラッシュ(登録商標)、スマートメディア(登録商標)、及びマルチメディアカード(登録商標)等の可搬性半導体メモリ装置を含む。マネージド・コピーは、読み出し専用記録媒体に記録されたデータのバックアップ回数の制限、及びバックアップ処理に対する課金を可能にする。
BD−ROMディスクからBD−Rディスク又はBD−REディスクへのマネージド・コピーが行われる場合、両ディスクの記録容量が等しいときは、コピー元のディスクに記録されたビット・ストリームがそのまま、順番にコピーされればよい。
マネージド・コピーが異種の記録媒体間で行われるときはトランス・コードが必要である。「トランス・コード」とは、コピー元のディスクに記録されているデジタル・ストリームをコピー先の記録媒体のアプリケーション・フォーマットに適合させるための処理をいう。トランス・コードは、例えば、MPEG2−TS形式からMPEG2プログラム・ストリーム形式へ変換する処理、及び、ビデオ・ストリームとオーディオ・ストリームとのそれぞれに割り当てられているビットレートを低くして符号化し直す処理を含む。トランス・コードでは、上述のリアルタイム・レコーディングによって、AVストリーム・ファイル、クリップ情報ファイル、及びプレイリスト・ファイルが生成されねばならない。
≪データ構造の記述方法≫
本発明の実施形態1によるデータ構造のうち、「所定型の情報が複数存在する」という繰り返し構造は、for文に制御変数の初期値と繰り返し条件とを記述することによって定義される。また、「所定の条件が成立するときに所定の情報が定義される」というデータ構造は、if文にその条件と、その条件の成立時に設定されるべき変数とを記述することによって定義される。このように、実施形態1によるデータ構造は高級プログラミング言語によって記述される。従って、そのデータ構造は、「構文解析」、「最適化」、「資源割付」、及び「コード生成」といったコンパイラによる翻訳過程を経て、コンピュータによって読み取り可能なコードに変換され、記録媒体に記録される。高級プログラミング言語での記述により、そのデータ構造は、オブジェクト指向言語におけるクラス構造体のメソッド以外の部分、具体的には、そのクラス構造体における配列型のメンバー変数として扱われ、プログラムの一部を成す。すなわち、そのデータ構造は、プログラムと実質的に同等である。従って、そのデータ構造はコンピュータ関連の発明として保護を受けるべきである。
≪再生プログラムによるプレイリスト・ファイル、クリップ情報ファイルの管理≫
プレイリスト・ファイルとAVストリーム・ファイルとが記録媒体に記録されるとき、その記録媒体には再生プログラムが実行形式のファイルとして記録される。再生プログラムはコンピュータに、プレイリスト・ファイルに従ってAVストリーム・ファイルを再生させる。再生プログラムは記録媒体からコンピュータ内のメモリ装置にロードされた後、そのコンピュータによって実行される。そのロード処理はコンパイル処理又はリンク処理を含む。それらの処理により、再生プログラムはメモリ装置内では複数のセクションに分割される。それらのセクションは、textセクション、dataセクション、bssセクション、及びstackセクションを含む。textセクションは、再生プログラムのコード列、変数の初期値、及び書き換え不可のデータを含む。dataセクションは、初期値を持つ変数、及び書き換え可能なデータを含む。dataセクションは特に、記録媒体上に記録された、随時アクセスされるファイルを含む。bssセクションは、初期値を持たない変数を含む。bssセクション内のデータは、textセクション内のコードの示す命令に応じて参照される。コンパイル処理又はリンク処理では、コンピュータ内のRAMにbssセクション用の領域が確保される。stackセクションは、必要に応じて一時的に確保されるメモリ領域である。再生プログラムによる各処理ではローカル変数が一時的に使用される。stackセクションはそれらのローカル変数を含む。プログラムの実行が開始されるとき、bssセクション内の変数はゼロで初期化され、stackセクションには必要なメモリ領域が確保される。
プレイリスト・ファイル及びクリップ情報ファイルは上述のとおり、記録媒体上では既に、コンピュータによって読み取り可能なコードに変換されている。従って、それらのファイルは再生プログラムの実行時、textセクション内の「書き換え不可のデータ」、又はdataセクション内の「随時アクセスされるファイル」として管理される。すなわち、プレイリスト・ファイル及びクリップ情報ファイルは、再生プログラムの実行時にその構成要素の中に組み込まれる。それ故、プレイリスト・ファイル及びクリップ情報ファイルは再生プログラムにおいて、単なるデータの提示を超えた役割を果たす。