明 細 書
記録媒体、再生装置、記録方法、再生方法
技術分野
[0001] 本発明は、 Out-of-MUXフレームワークの技術分野に属する発明である。
背景技術
[0002] Out- of- MUXフレームワークとは、 BD- ROM等のリードオンリー型の記録媒体に記 録されて!/ヽるデジタルストリームと、ハードディスク等のリライタブル型の記録媒体に記 録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生 させる技術である。
ここで BD-ROMに記録されて!、るデジタルストリーム力 映画作品の本編を構成す るものであり、ローカルストレージに記録されているデジタルストリーム力 映画監督の コメンタリを構成する場合、上述した Out-of-MUXフレームワークを実現することにより 、 BD-ROM上の本編と、コメンタリとを再生に供して、 BD-ROMの内容拡充を図ること ができる。
[0003] 尚、リードオンリー型記録媒体の先行技術としては、以下の特許文献に記載されて いるものがある。
特許文献 1:特願平 8— 83478号公報
発明の開示
発明が解決しょうとする課題
[0004] ところで、 Out-of-MUXフレームワークの実現にあたっては、装置内に存在する複 数のデコーダのうち、あるものは、 BD-ROM力も読み出されたストリームの処理し、ま た別のものは、ローカルストレージ側のストリームを処理するという混在状態が発生す ることになる。そして、 BD-ROM力ものストリーム読み出し力 あるストリームから、別の ストリームに切り替つた場合において、複数デコーダのそれぞれは、シームレス接続 のための処理を行う必要があるが、どれかのデコーダ力 シームレス接続の処理を怠 れば、 BD-ROM側のデータを処理するデコーダ、及び、ローカルストレージ側のストリ ームを処理するデコーダのうち、ローカルストレージ力 供給されるものの再生が途
切れること〖こなる。
[0005] たとえ、 BD-ROMから供給されるストリームに対して、シームレス接続の処理が行え たとしても、ローカルストレージ力 供給されるストリームに対するシームレス接続に抜 けがあれば、再生に途切れが生じることになる。これでは、ストリームが BD-ROMから 供給されるか、ローカルストレージカも供給されるかによって、ストリームの再生品質 に明らかなバラツキが生じることになり、メーカーにとって、容認できない事態が生じる
[0006] 本発明の目的は、ストリームが光ディスク力 供給される力、ローカルストレージから 供給されるかによって、再生品質にバラツキが生じることをなくすことができる記録媒 体を提供することである。
課題を解決するための手段
[0007] 上記目的を達成するため、本発明にかかる記録媒体は、プレイリスト情報が記録さ れており、前記プレイリスト情報は、メインパス情報、サブパス情報を含み、前記メイン パス情報は、複数デジタルストリームのうち 2つのものを、メインストリームとして指定し て、それのメインストリームに対し、主たる再生区間を定義する情報であり、前記サブ パス情報は、複数デジタルストリームのうち他の 2つのものを、サブストリームとして指 定して、それのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生 区間を定義する情報であり、
プレイリスト情報は接続情報を含み、接続情報は、メインパス情報にて参照される 2 つのメインストリーム間の接続状態が、所定タイプの接続である場合、サブパス情報 で参照される前記 2つのサブストリーム間の接続であって、 2つのメインストリーム間の 接続と同じタイミングになされるものの接続状態も、同じタイプの接続である旨を示す ことを特徴としている。
発明の効果
[0008] 上述した接続情報は、メインパス情報にて参照される 2つのメインストリーム間の接 続状態が、所定タイプの接続である場合、サブパス情報で参照される前記 2つのサブ ストリーム間の接続であって、 2つのメインストリーム間の接続と同じタイミングになされ るものの接続状態も、同じタイプの接続である旨を示しているので、光ディスク力ゝら供
給されるストリームにおけるタイムスタンプの不連続点と、ローカルストレージカも供給 されるストリームにおけるタイムスタンプの不連続点とが時間軸上の同じ時点に出現 する場合、再生装置がプレイリスト情報に従って再生動作を進めてゆけば、装置内に 複数のデコーダは、上述した不連続点において、一律に接続処理を行うことになる。 これにより接続処理の抜けを防止することができる。結果として、光ディスクから供給さ れるストリームと、ローカルストレージ力 供給されるストリームとで、再生品質にバラッ キが生じることがなくなる。
[0009] 力かるバラツキをなくすことで、メーカーは Out_of_MUXアプリケーションを実現する ような再生装置を、広く普及させることができる。
図面の簡単な説明
[0010] [図 1]本発明に係る記録媒体の、使用行為についての形態を示す図である。
[図 2]BD- ROMの内部構成を示す図である。
[図 3]拡張子. m2tsが付与されたファイルがどのように構成されているかを模式的に示 す図である。
[図 4]PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納さ れるかを更に詳しく示す図である。
[図 5]ビデ才ゃ才一ディォが、プログラムストリーム、トランスポートストリームにどのよう に多重化されるかを示す図である。
[図 6]トランスポートストリームの詳細を示す図である。
[図 7]PAT、 PMTパケットの内部構成を示す図である。
[図 8]AVClipを構成する TSパケットがどのような過程を経て BD-ROMに書き込まれる かを示す。
[図 9]Aligned Unitの内部構成を示す図である。
[図 10]Clip情報の内部構成を示す図である。
[図 11]映画のビデオストリームに対する EPjnap設定を示す図である。
[図 12]PlayList情報のデータ構造を示す図である。
[図 13]AVClipと、 PlayList情報との関係を示す図である。
[図 14]ローカルストレージ 200の内部構成を示す図である。
[図 15]Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSが BD- RO M再生装置の内部構成において、デコーダにどのように供給されるかを示す図である
[図 16]PlayList情報のデータ構造を示す図である。
[図 17]Subpath情報の内部構成をクローズアップして示す図である。
[図 18]ローカルストレージ 200上の SubClipと、ローカルストレージ 200上の PlayList情 報と、 BD- ROM上の MainClipとの対応を示す図である。
[図 19] (a) STN_tableの内部構成を示す図である。
(b)ビデオストリームに対応した Stream_attributeを示す図である。
(c)オーディオストリームに対応した Stream_attributeを示す図である。
(d)ビデオストリームにおける Stream_entryを示す図である。
[図 20]BD-ROM力も読み出された TSパケットと、ローカルストレージカも読み出された TSパケットとを示し、これらの TSパケットのうち、デコーダに供給されるものを示す。
[図 21] (a)〜(d) Windowのシフトを示す図である。
[図 22]BD-ROM力も読み出された TSパケット、ローカルストレージカも読み出された T Sパケットのデータ量の時間的推移を示すグラフである。
[図 23] (a) (b)各 Windowの転送許容量と、 Windowにおけるデコーダへの供給量とを 対比して示す図である。
[図 24]Out_of_MUXアプリケーションを構成する Playltem、 SubPlayltemの接続状態を 示す図である。
[図 25]図 24に示した、 Playltemの connection— condition情報、 SubPlayltemの sp—conne ction— condition情報が" =5"に設定されて!、る場合の、 Playltemにおける In— Time、 Ou t_Timeと、 SubPlayltemにおける In_Time、 Out_Timeとの関係を示す図である。
[図 26]PlayItemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、参照 されるべき STC値、 SubPlayltemの In_Timeから Out_Timeまでに存在する部分を再生 する場合に、参照されるべき STC値を示す。
[図 27]previousPlayItemにて参照されて!、る MainClip、カレント Playltemにて参照され ている SubClipにおいて、 TS1、 TS2がどのように特定されるかを示す図である。
[図 28]CC = 5、及び、 SP_CC = 5の詳細を示す図である。
[図 29]previousPlayItem及びカレント Playltemにて指定される複数の Video Presentati on Unitと、複数の Audio Presentation Unitと、 STC時間軸との関係を示す図である。 圆 30]本発明に係る再生装置の内部構成を示す図である。
[図 31]PlayList情報に基づく再生手順のフローチャートである。
[図 32]SubPlayItemにおけるシームレス接続を示すフローチャートである。
[図 33]第 2実施形態に力かるォーサリングシステムの内部構成を示す図である。
[図 34]プライマリ TS、セカンダリ TSに対するべリファイ手順を示すフローチャートである
[図 35]同種のエレメンタリストリームが複数存在する場合の、プライマリ TS、セカンダリ
TSに対するべリファイ手順を示すフローチャートである。
[図 36]CC=6の詳細な説明を示す図である。
[図 37]PlayItemと SubPlayltemの相関を示した図である。
[図 38]ATC時間軸に存在する複数の TSパケットが、どのように多重化されるかを模式 的に示す図である。
[図 39]オーディオに加えて、字幕 (PG)やメニュー(IG)も入れ替えられる場合、プライ マリ TSを構成する複数の TSパケットと、セカンダリ TSを構成する複数の TSパケットとが 、どのように多重化されるかを模式的に示す図である。
[図 40]オーディオミキシングアプリケーションを構成するプライマリ TS、セカンダリ TSが 、 BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示 す図である。
圆 41]第 5実施形態に係る再生装置の内部構成を示す図である。
[図 42]オーディオミキシングを示すプレイリストにて指定される Playltemと SubPlayltem の相関を示した図である。
[図 43]劇場公開版とディレクターズカットの両方を構成する PlayList情報の一例を示 す図である。
符号の説明
la BD— ROMドライブ
lb,c リードバッファ
lb,a,c ATCカウンタ
2a, d Source Depacketizer
2c,d ATCカウンタ
3a,c STCカウンタ
3b,d PID Filter
4 ビデオデコーダ
5 ビデオプレーン
6 Transport Buffer
7 Elementary Buffer
8 オーディオデコーダa,b,c,d スィッチ
11 Interactive Graphicsデコ ~~ダ
12 Interactive Graphicsプレ ~~ン
13 Presentation Graphicsデコ ~~グ
14 Presentation Graphicsプレ ~~ン 17 合成部
21 メモリ
22 コントローラ
23 PSRセット
24 PID変換部
25 ネットワーク部
26 操作受付部
100 BD-ROM
200 ローカノレストレージ
300 再生装置
400 テレビ
500 AVアンプ
発明を実施するための最良の形態
[0013] (第 1実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明 に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図 1は、 本発明に係る記録媒体の、使用行為についての形態を示す図である。図 1において 、本発明に係る記録媒体は、ローカルストレージ 200である。ローカルストレージ 200 は、再生装置 300、テレビ 400、 AVアンプ 500、スピーカ 600から構成されるホーム シアターシステムに、映画作品を供給するという用途で使用される。
[0014] 以降、 BD- ROM100、ローカルストレージ 200、再生装置 300について説明を行う。
BD-ROM100は、映画作品が記録された記録媒体である。
ローカルストレージ 200は、再生装置に組み込まれ、映画配給者のサーバから配信 されたコンテンツの受け皿として利用されるハードディスクである。
[0015] 再生装置 300は、ネット対応型のデジタル家電機器であり、 BD-ROM100を再生す る機能をもつ。また、映画配給者のサーバ 700から、ネットワークを通じてダウンロー ドしたコンテンツを、ローカルストレージ 200に格納し、こうしてローカルストレージ 200 に記録されたコンテンツと、 BD-ROM100に記録されたコンテンツと組み合わせて、 B D- ROM100のコンテンツを拡張/更新を行うことができる。 BD- ROM100の記録内容 に、ローカルストレージ 200の記録内容を組み合わせて、 BD- ROM100に記録され ていないデータを、恰も、記録されているように扱う技術を"バーチャルパッケージ"と いう。
[0016] 以上が本発明に係る記録媒体の使用形態についての説明である。
続、て本発明に係る記録媒体の生産行為につ 、て説明する。本発明に係る記録 媒体は、ファイルシステム上における改良で実現することができる。
く BD- ROMの概要 >
図 2は、 BD- ROMの内部構成を示す図である。本図の第 4段目に BD- ROMを示し、 第 3段目に BD- ROM上のトラックを示す。本図のトラックは、 BD- ROMの内周から外周 にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。こ のトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図の
ボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。 ディレクトリ構造を用いて BD- ROMの応用層フォーマット (アプリケーションフォーマット )を表現すると、図中の第 1段目のようになる。この第 1段目において BD- ROMには、 R ootディレクトリの下に、 BDMVディレクトリがある。
[0017] この BDMVディレクトリの配下には、更に PLAYLISTディレクトリ、 CLIPINFディレクトリ 、 STREAMディレクトリと呼ばれる 3つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子 mplsが付与されたファイル (OOOOl.mpls)がある。 CLIPINFディレクトリには、拡張子 clpiが付与されたファイル (00001.clpi,00002.clpi) がある。
[0018] STREAMディレクトリには、拡張子 m2tsが付与されたファイル (00001.m2ts,00002.m2 ts)がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイル力 BD-ROM上に 配置されて ヽることがゎカゝる。
< BD- ROMの構成その 1.AVClip >
先ず初めに、拡張子. m2tsが付与されたファイルについて説明する。図 3は、拡張子 .m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。 拡張子. m2tsが付与されたファイル (00001.m2ts,00002.m2ts)は、 AVClipを格納してい る。 AVClipは MPEG2-Transport Stream形式のデジタルストリームである。このデジタ ルストリームは、デジタル化された映像、デジタル化された音声を (上 1段目)、 PESパ ケットからなるエレメンタリストリームに変換し (上 2段目)、更に TSパケットに変換して( 上 3段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム (Presentatiion Gr aphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム (Interactive GraphicsdG)ストリーム)を (下 1段目、下 2段目)、 TSパケットに変換して (下 3段目)、こ れらを多重化することで構成される。
[0019] 以降、これらのビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームに ついて説明する。
<ビデ才ストリーム >
ビデオストリームは、映画作品の動画像を構成するストリームであり、 SD画像、 HD画
像であるピクチャデータカゝら構成される。ビデオストリームには、 VC-1のビデオストリ ーム、 MPEG4- AVCのビデオストリーム、 MPEG2- Videoのビデオストリームといった形 式が存在する。 MPEG4-AVCのビデオストリームでは、 IDRピクチャ, Iピクチャ ,Ρピクチ ャ ,Βピクチャに、 PTS、 DTSといったタイムスタンプが付され、このピクチヤの単位で、 再生制御がなされる。このように、 PTS、 DTSが付されて、再生制御の単位となる、ビ デォストリームの一単位を" Video Presentation Unit"という。
<オーディオストリーム >
オーディオストリームは、映画作品の音声を表すストリームであり、 LPCMオーディオ ストリーム、 DTS—HDオーディオストリーム、 DD/DD+オーディオストリームや DD/MLP オーディオストリームといった形式が存在する。オーディオストリームにおけるオーディ オフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御 がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディ ォストリームの一単位を" Audio Presentation Unit"という。
< PGストリーム >
PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、 日本 語、フランス語というように複数言語についてのストリームが存在する。 PGストリームは 、 PCS(Presentation control Segment) ^ PDS(Pallet Define Segment) ^ WDS(Window D efine Segment), ODS(Object Define Segment)という一連の機能セグメントからなる。 0 DS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグ メントである。
[0020] WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量 を定義する機能セグメントであり、 PDS(Pallet Define Segment)は、グラフィクスォブジ ェタトの描画にあたっての、発色を規定する機能セグメントである。 PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである 。かかるページ制御には、 Cut-In/Out, Fade-In/Out, Color Change, Scroll, Wipe- 1 n/Outといったものがあり、 PCSによるページ制御を伴うことにより、ある字幕を徐々に 消去しつつ、次の字幕を表示させると!、う表示効果が実現可能になる。
[0021] < IGストリーム >
IGストリームは、対話制御を実現するグラフィクスストリームである。 IGストリームにて 定義される対話制御は、 DVD再生装置上の対話制御と互換性がある対話制御であ る。力力る I ストリ ~~ム【ま、 ICSQnteractive Composition segment)ゝ PDS(Palette Difinit ion Segment), ODS(Object Definition Segment)と呼ばれる機能セグメントからなる。 0 DS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメント である。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画さ れる。 PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたって の、発色を規定する機能セグメントである。 ICSOnteractive Composition Segment)は、 ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメ ントである。 ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンド を含む。
[0022] ここで AVClipは、 1つ以上の" STC_Sequence"から構成される。 "STC_Sequence"とは 、 AVストリームのシステム基準時刻である STC(System Time Clock)の不連続点 (syste m time-base discontinuity)が存在しない区間をいう。 STCの不連続点はデコーダが S TCを得るために参照する PCR(Program Clock Reference)を運ぶ PCRパケットの不連 続情報 (discontinuityjndicator)が ONである点である。
[0023] 図 4は、 PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格 納されるかを更に詳しく示している。本図における第 1段目は、ビデオストリームを示し 、第 3段目はオーディオストリームを示す。第 2段目は、 PESパケット列を示す。本図の 矢印 yyl,yy2,yy3,yy4に示すように、ビデオストリームにおける複数の Video Presentati on Unitである IDR、 Bピクチャ、 Pピクチャは、複数に分割され、個々の分割部分が、 P ESパケットのペイロード (図中の V#1,V#2,V#3,V#4)に格納されることがわかる。またォ 一ディォストリームを構成する Audio Presentation Unitであるオーディオフレームは、 矢印 aal ,aa2に示すように、個々の PESパケットのペイロード (図中の A#l ,A#2)に格納 されていることがわ力る。
[0024] 図 5は、ビデ才ゃ才一ディォが、プログラムストリーム、トランスポートストリームにどの ように多重化されるかを示している。下段は、ビデオストリームと、オーディオストリーム とを格納した複数の PESパケット (図中の V#1,V#2,V#3,V#4,A#1,A#2)を示す。ビデオ
ストリーム及びオーディオストリームは、別個の PESパケットに格納されることが本図か らゎ力る。上段は、下段の PESパケットを格納したプログラムストリーム及びトランスポ 一トストリームを示す。プログラムストリームに多重化される場合、 PESパケットは、 1パ ックに収められる。トランスポートストリームに多重化される場合、 PESパケットは分割さ れ、個々の分割部分は、複数の TSパケットのペイロードに格納される。 BD- ROMにお ける格納方式は、前者のプログラムストリームではなぐ後者のトランスポートストリーム のものとなる。図 5ではそのようになっていないが、トランスポートストリームに使われる ビデオ PESパケットは 1つのフレーム、もしくはペアとなる 2つのフィールドを格納する のが一般的である。
[0025] 図 6は、トランスポートストリームの詳細を示す図である。本図における第 1段目は、 MPEG2トランスポートストリームを構成する複数の TSパケット列であり、第 2段目は TS パケットの内部構成を示す。この第 2段目に示すように、 1つの TSパケットは、 "ヘッダ "と、 "適用フィールド(adaptation field) "と、 "ペイロード"と力も構成される。引き出し 線 thlは、 TSパケットヘッダの構成をクローズアップしている。このこの引き出し線に示 すように、 TSパケットヘッダには、 PESパケットの先頭を格納していることを示す「ュ- ット開始表示 (payload_unit_start_indicator)」、トランスポートストリームに多重ィ匕される エレメンタリストリームの種別を示す「PID (Packet Identifier)」、 TSパケットに適用フィ 一ルドが存在している力否かを示す「適用フィールド制御」などが存在する。
[0026] 引き出し線 th2は、適用フィールドの内部構成をクローズアップしている。適用フィー ルドは TSパケットヘッダの適用フィールド制御が" Γに設定されている場合に、 TSパ ケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、 エントリーポイントであることを示す「ランダムアクセス表示(random_access_indicator)」 、 T-STD (Transport System Target Decoder)の ¾ i C (System Time Clock)を与 る「 PCR (Program Clock Reference)」などが、この適用フィールドに格納される。
[0027] 図 7は、 PAT、 PMTパケットの内部構成を示す図である。これらのパケットは、トラン スポートストリームのプログラム構成を記述するものである。
本図における引き出し線 hmlは、トランスポートストリームに存在する PID=0の TSパケ ットの構成をクローズアップしている。かかる TSパケットは、 PAT (Program Association
Table)パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。 PATパケ ットの PIDは常に" 0"である。 PATパケットには、 PAS (Program Association Section)が 格納される。引き出し線 hm2は、 PASの内部構成をクローズアップしている。この引き 出し線に示すように PASは、 program_number (番糸且番号)と、 program map table(PMT の PID)とを対応付けて示している。引き出し線 hm3は、トランスポートストリームに存在 する PID=0xl00の TSパケットの構成をクローズアップしている。力かる TSパケットは、 P MTパケットと呼ばれる。引き出し線 hm4に示すように、 PMTパケットの PMSは、その PM Sに対応する番組に含まれるストリーム種別を示す「stream_type」と、そのストリームの PIDである「elementary_PID」とを含む。本図の例では、番糸且番号 #1の番糸且は、 PID=0x 100の PMTを有しており、 PID=0x200と 0x201とを有する MPEG2ビデオと、 ADTSォー ディォとが、この番組番号 #1の番組を構成していることがわかる。このようにして、常に PID=0である PATから PMTの PIDを取得し、この PMTの PIDから PMTパケットを取得し て、 PMSを参照することで、トランスポートストリーム中の番組と、その構成ストリームの PIDやストリームタイプとを知得することができる。
続いて、以上のように構成された AVClip力 BD- ROMにどのように書き込まれる力 を説明する。図 8は、 AVClipを構成する TSパケットがどのような過程を経て BD-ROM に書き込まれるかを示す。本図の第 1段目に AVClipを構成する TSパケットを示す。
AVClipを構成する 188バイトの TSパケットは、第 2段目に示すように 4バイトの TS_extr ajieader (図中のハッチング部)、が付されて、 192バイト長の Sourceパケットになる。こ の TS_extra_headerは、当該 TSパケットのデコーダ入力時刻情報を示す Arrival_Time_ Stampを含む。 ATSヘッダを TSパケットごとに付与してストリームを形成する理由は、 T Sパケットごとにデコーダ(STD)への入力時刻を与えるためである。デジタル放送では トランスポートストリームは固定ビットレートとして扱われる。そのため、 NULLパケットと 呼ばれるダミーの TSパケットを多重化して固定ビットレートとしたトランスポートストリー ムを放送して 、る。光ディスクのような限られた記録容量の記録媒体にストリームを記 録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である 。そのため BD- ROMでは NULLパケットを記録することはしない。そして、可変ビットレ ートの記録方式に対応するため、個々の TSパケットに ATSを付与した上でトランスポ
一トストリームを記録する。この ATSを用いることで、 TSパケットごとにデコーダ入力時 刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降 、 ATSヘッダと TSパケットの 1組をソースパケット(Source Packet)と呼ぶ。
[0029] AVClipを構成する Sourceパケットは、第 3段目における AVClipにおいて、 1つ以上 の" ATC_Sequence"を構成する。 "ATC_Sequence"とは、 Sourceパケットの配列であつ て、その Arrival— Time— Stamp ^参照し飞 ヽる Arrival— Time— Clockに、 , 連腕 \no arnv al time-base discontinutiy)が存在しないものをいう。いい力えれば、その ArrivaLTime _Stampが参照している Arrival_Time_Clockに、連続性が存在する Sourceパケット列を" ATC— Sequence"と!、う。
[0030] かかる ATC_Sequenceが AVClipになり、 xxxxx.m2tsというファイル名で BD- ROMに記 録される。
かかる AVClipは、通常のコンピュータファイル同様、 1つ以上のファイルエクステント に分割され、 BD-ROM上の領域に記録される。第 4段目は AVClipがどのように BD-R OMに記録されるかを模式的に示す。この第 4段目においてファイルを構成する各フ アイルエクステントは、予め定められた Sexetent以上のデータ長を有する。
[0031] AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの 最小データ長 Sexetentを検討する。
ここで BD- ROMにおいて光ピックアップのジャンプに要する時間は、
Ί jump =Ί access+Toverheaa
で与えられる。
Taccessは、ジャンプ距離(ジャンプする物理アドレスの距離)に応じて与えられる時 間である。
BD- ROM力も読み出された TSパケットは、リードバッファと呼ばれるバッファに格納 された上、デコーダに出力される力 リードバッファへの入力力 Rudというビットレート で行われ、 ECCブロックにおけるセクタ数を Seccとした場合、
丄、 overneadi 、
Toverhead≤ (2 X Secc X 8)/Rud = 20m秒
という計算で与えられる。
BD- ROM力も読み出された TSパケットは、 Sourceパケットの状態でリードバッファに 格納された上、 TS_Recording_rateという転送レートで、デコーダに供給される。
[0032] TS_Recording_rateという転送レートでの、デコーダへの TSパケット供給が跡絶えさ せないためには、 Tjumpの間、リードバッファからデコーダへの TSパケット出力が継続 している必要がある。ここでリードバッファからの出力は、 TSパケットではなぐ Source パケットの状態でなされるので、 TSパケットの Sourceパケットとのサイズ比を 192/188と した場合、 Tjumpの間、(192/188 X TS_Recording_rate)という転送レートにより、リード バッファからの Sourceパケット出力が継続している必要がある。
従って、リードバッファ力 アンダーフローしないためのバッファ蓄積量は、 Boccupied≥ (Tjump/ 1000 X 8) X ((192/188) X TS— Recording— rate)
となる。
リードバッファへの入力レートは Rud、リードバッファからの出力レートは TS_Recordin g_rate X (192/ 188)であるので、リードバッファへの蓄積レートは、入力レート一出カレ ートの計算で与えられ、 (Rud - TS_Recording_rate X (192/188》になる。
[0033] この Boccupiedを、リードバッファに蓄積するのに要する時間 Txは、
Tx = Boccupied/(Rud— TS— Recording— rate X (192/188))
になる。
BD-ROMからの読み出しには、この時間 Txにおいて Rudでの TSパケット入力を継続 する必要があるので、 AVClipを複数のエクステントに分割して記録する場合の、エタ ステント一個当たりの最小データ長 Sexetentは、
¾exetent = Rud X Tx
= Rud X Boccupied/(Rud— TS— Recording— rate X (192/188))
≥ Rud X (Tjump/ 1000 X 8) X ((192/188) X TS— Recording— rate)
/(Rud—TS— Recording— rate X (192/188))
≥ (Rud X Tjump/ 1000 X 8) X
X TS— Recording— rate X 192/(Rud X 188— TS— Recording— rate X 192)
になる。
よって
Sexetent≥
(Tjump X Rud/1000 X 8) X
(TS— Recording— rate X 192/(Rud X 188— TS— Recording— rate X 192》
になる。
AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさな いように算出された Sextent以上のデータ長をもつことにより、 AVClipを構成する各フ アイルエクステントが、 BD-ROM上において離散的に位置されたとしても、再生時に おいてデコーダへの TSパケット供給が途絶えさせることなぐ連続的に読み出される ことになる。
[0034] 上述したファイルエクステントは、 Sourceパケット 32個集めたァラインドユニット(Align ed Unit, 6KByteのデータサイズ)を最小単位として構成されている。したがって、 BD でのストリームファイル(XXXXX.AVClip)のファイルサイズは常に 6KByteの倍数とな る。
図 9は、 Aligned Unitの内部構成を示す図である。 Aligned Unitは、 32個の Sourceパ ケットから構成され、連続する 3つのセクタに書き込まれる。 32個の Sourceパケットから なるグループは、 6144バイト (=32 X 192)であり、これは 3個のセクタサイズ 6144バイト (= 2048 X 3)と一致する。 BD-ROMにおけるセクタは、 32個単位で誤り訂正符号が付され 、 ECCブロックを構成する。再生装置は Aligned Unitの単位で BD- ROMをアクセスす る限り、 32個の完結した Sourceパケットを得ることができる。以上が BD-ROMに対する AVClipの書き込みのプロセスである。 BD- ROMに記録され、高画質なビデオストリー ムが多重化されている AVClipを、以下" MainClip"と呼ぶ。これに対し、ローカルストレ ージに記録され、 MainClipと同時に再生される AVClipを、 "SubClip"とよぶ。
[0035] BD- ROMに記録されている MainClipに対して、多重分離を行うことで、パーシャルト ランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々の エレメンタリストリームに対応するものである。 MainClipを多重分離することで得られる パーシャルトランスポートストリームであって、 1つのエレメンタリストリームに対応するも のを"プライマリ TS"という。
< BD- ROMの構成その 2.Clip情報 >
続、て拡張子 .clpiが付与されたファイルにつ 、て説明する。拡張子 .clpiが付与され たファイル (00001.clpi,00002.clpi)は、 Clip情報を格納している。 Clip情報は、個々の A VClipについての管理情報である。図 10は、 Clip情報の内部構成を示す図である。 本図の左側に示すように Clip情報は、
OAVClipについての情報を格納した『ClipInfoO』、
ii) ATC Sequence'STC Sequenceに関する情報を格納した『Sequence InfoO』 iii) Program Sequenceに関する情報を格納した『Program InfoO』
iv)『Characteristic Point Info(CPlO)』からなる。
[0036] Cliplnfoには、この Clip情報が参照する AVClipのアプリケーションタイプ(application _type)がある。力かる Cliplnfoを参照することで、アプリケーションタイプによって MainC lipか SubClipかや、動画を含んで!/、るのか静止画 (スライドショー)を含んで!/、るのかな どが識別できる。また Cliplnfoには、上述した TS_recording_rateが記述されて!、る。
Sequence Infoi 、 AVClip【こ れ 、 1つ W上の ¾ i,C— ¾equence、 ATし— Sequencedこ ついての情報である。これらの情報を設けておくことの意義は、 STC、 ATCの不連続 点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、 AV Clip内において同じ値の PTS,ATSが出現する可能性があり、再生時に不都合が生じ る。 STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでで あるかを示すため、 Sequence Infoは設けられている。
[0037] Program Infoとは、 Program内容が一定である区間 (Program Sequence)を示す情報 である。 Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム 同士の集まりである。 Program Sequence情報を設けておくことの意義は、 Program内 容の変化点を、予め再生装置に通知するためである。ここでの Program内容の変化 点とは、ビデオストリームの PIDが変化したり、ビデオストリームの種類が SD画像から H D画像に変化して 、る点等を!、う。
続いて Characteristic Point Infoについて説明する。図中の引き出し線 cu2は、 CPI の構成をクローズアップしている。引き出し線 cu2に示すように、 CPIは、 Ne個の EP_ma p— for— one— stream— PID(EP— map— for— one— stream— PID[0]〜EP— map— for— one— stream— PID[N e-1])からなる。これら EP_map_for_one_stream_PIDは、 AVClipに属する個々のエレメン
タリストリームについての EP_mapである。 EP_mapは、 1つのエレメンタリストリーム上に おいて、 Access Unitが存在するエントリー位置のパケット番号 (SPN_EP_start)を、ェン トリー時刻 (PTS_EP_start)と対応づけて示す情報である。図中の引き出し線 cu3は、 EP _map_for_one_stream_PIDの内部構成をクローズアップして 、る。
[0038] これによると、 EP— map— for— one— stream— PIDは、 Nc個の EP— High(EP— High(0)〜EP— High (Nc-1))と、 Nf個の EP丄 ow(EP丄 ow(0)〜EP丄 ow(Nf-l》とからなることがわかる。ここで E P— Highは、 Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の SPN— EP— start及び PTS— EP —startの上位ビットを表す役割をもち、 EP丄 owは、 Access Unit(Non- IDR Iピクチャ、 ID Rピクチャ)の SPN_EP_start及び PTS_EP_startの下位ビットを示す役割をもつ。
[0039] 図中の引き出し線 cu4は、 EP_Highの内部構成をクローズアップしている。この引き 出し線に示すように、 EP_High(i)は、 EP丄 owに対する参照値である『ref_to_EP丄 ow_id[i ]』と、 Access Unit(Non-IDR Iピクチャ、 IDRピクチャ)の PTSの上位ビットを示す『PTS_E P_High[i]』と、 Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の SPNの上位ビットを示 す『SPN_EP_High[i]』と力もなる。ここで iとは、任意の EP_Highを識別するための識別子 である。
[0040] 図中の引き出し線 cu5は、 EP丄 owの構成をクローズアップしている。引き出し線 cu5 に示すように、 EP丄 owは、対応する Access Unitが IDRピクチャか否かを示す『is_angle — change_point(EP丄 ow_id)』と、対応する Access Unitのサイズを示す『し end_position_off set(EP丄 ow_id)』と、対応する Access Unit(Non- IDR Iピクチャ、 IDRピクチャ)の PTSの 下位ビットを示す『PTS_EP丄 ow(EP丄 owjd)』と、対応する Access Unit(Non- IDR Iピク チヤ、 IDRピクチャ)の SPNの下位ビットを示す『SPN_EP丄 ow(EP丄 ow_id)』とからなる。こ こで EP丄 owjdとは、任意の EP丄 owを識別するための識別子である。
[0041]
< Clip情報の説明その 2.EP_map>
以下、具体例を通じて、 EPjnapについて説明する。図 11は、映画のビデオストリー ムに対する EPjnap設定を示す図である。第 1段目は、表示順序に配置された複数の ピクチャ (MPEG4-AVCに規定された IDRピクチャ、 Iピクチャ、 Bピクチャ、 Pピクチャ)を 示し、第 2段目は、そのピクチヤにおける時間軸を示す。第 4段目は、 BD-ROM上の T
Sパケット列を示し、第 3段目は、 EP_mapの設定を示す。
[0042] 第 2段目の時間軸にお!、て、時点 tl〜t7に、 Access Unitとなる IDRピクチャ及び Iピ クチャが存在するものとする。そしてこれらの tl〜t7の時間間隔が、 1秒程度であると すると、映画に用いられるビデオストリームにおける EP_mapは、 tl〜t7をエントリ一時 刻 (PTS_EP_start)として示し、これに対応づけてエントリー位置 (SPN_EP_start)を示す よう、設定される。
< PlayList情報 >
続いて、 PlayList情報について説明する。拡張子" mpls"が付与されたファイル (0000 1.mpls)は、 PlayList(PL)情報を格納したファイルである。
[0043] 図 12は、 PlayList情報のデータ構造を示す図であり、本図において、引き出し線 mp 1に示すように PlayList情報は、 MainPathを定義する MainPath情報 (MainPathO)と、チ ャプターを定義する PlayListMark情報 (PlayListMarkO)を含む。
< PlayList情報の説明その 1.MainPath情報 >
先ず MainPathについて説明する。 MainPathは、主映像たるビデオストリームゃォー ディォストリームに対して定義される再生経路である。
[0044] MainPathは、矢印 mplで示すように複数の Playltem情報 #1 · · · '#mから定義される。
Playltem情報は、 MainPathを構成する 1つの論理的な再生区間を定義する。 Playltem 情報の構成は、引き出し線 hslによりクローズアップされている。この引き出し線に示 すように Playltem情報は、再生区間の IN点及び Out点が属する AVClipの再生区間情 報のファイル名を示す『ClipJnformation_file_name』と、 AVClipの符号化方式を示す『 Clip_codec_identifier』と、 Playltemがマルチアングルを構成するか否かを示す『is_mult i— angle』と、この Playltem (カレント Playltemリと、その 1っ刖の PlayItem(previousPlayItem )との接続状態を示す『connection_condition』と、この Playltemが対象として!/、る STC_S equenceを一意に示す『reむ o_STC_id[0]』と、再生区間の始点を示す時間情報『In_tim e』と、再生区間の終点を示す時間情報『Out_time』と、この Playltemにおいてマスクす べきユーザオペレーションがどれであるかを示す『UO_mask_table』と、この Playltemの 途中へのランダムアクセスを許可するか否かを示す『PlayItem_random_access_flag』と 、この Playltemの再生終了後、最後のピクチャの静止表示を継続する力否かを示す『
Still_mode』と、『STN_table』とカゝら構成される。このうち、再生経路を構成するのは、再 生区間の始点を示す時間情報『In_time』、再生区間の終点を示す時間情報『Out_tim e』の組みであり、再生経路情報とは、この『In_time』及び『Out_time』の組み力 構成 される。
[0045] 図 13は、 AVClipと、 PlayList情報との関係を示す図である。第 1段目は、 PlayList情 報がもつ時間軸 (PlayList時間柳を示す。第 2段目から第 5段目は、 EPjnapにて参照 されて!/ヽるビデ才ストリームを示す。
PlayList情報は、 Playltem情報 #1,#2と!、う 2つの Playltem情報を含んでおり、これら P layltem情報 #1,#2の In_time,Out_timeにより、 2つの再生区間が定義されることになる。 これらの再生区間を配列させると、 AVClip時間軸とは異なる時間軸が定義されること になる。これが第 1段目に示す PlayList時間軸である。このように、 Playltem情報の定 義により、 AVClipとは異なる再生経路の定義が可能になる。
[0046] 以上が、 BD-ROM100についての説明である。
<ローカルストレージ 200 >
続いて、本発明に力かる記録媒体である、ローカルストレージ 200について説明す る。図 14は、ローカルストレージ 200の内部構成を示す図である。本図に示すように 、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。
[0047] 本図の第 4段目にローカルストレージ 200を示し、第 3段目にローカルストレージ 20 0上のトラックを示す。本図のトラックは、ローカルストレージ 200の内周から外周にか けて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このト ラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリ ユーム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレ クトリ構造を用いてローカルストレージ 200の応用層フォーマット (アプリケーションフォ 一マット)を表現すると、図中の第 1段目のようになる。
[0048] 本図のディレクトリ構造において ROOTディレクトリの配下には、「organization#l」と いうサブディレクトリがあり、その配下に、「disc#l」というサブディレクトリがある。ディレ クトリ「organization#l」とは、映画作品の特定のプロバイダに割り当てられたディレクト リである。「disc#l」は、そのプロバイダが提供した BD-ROMのそれぞれに割り当てら
れたディレクトリである。
[0049] 特定のプロバイダに対応するディレクトリに、各 BD-ROMに対応するディレクトリを設 けることにより、各 BD- ROMについてのダウンロードデータが個別に格納される。この サブディレクトリの配下に、 BD- ROMに格納されていたのと同様、 PlayList情報 (00002 .mpls)、 Clip情報 (00003. clpi,00004.clpi)、 AVClip(00003.m2ts,00004.m2ts)が格納さ れている。
続いて、ローカルストレージ 200の構成要素となる、 PlayList情報、 Clip情報、 AVCli pについての説明する。
[0050] <ローカルストレージ 200の構成その 1. AVClip >
ローカルストレージ 200上の AVClip(00003.m2ts,00004.m2ts)は、 SubClipを構成す る。この SubClipに対して、多重分離を行うことで、パーシャルトランスポートストリーム が得られる。 SubClipを多重分離することで得られるパーシャルトランスポートストリー ムを"セカンダリ TS"という。力かるセカンダリ TSは、 Out_of_MUXアプリケーションを構 成するものである。以降、 Out_of_MUXアプリケーションについて説明する。
( Out- of- MUXアプリケーション)
Out- of- MUXアプリケーションとは、例えば、 BD- ROM上のプライマリ TSと、ネットヮ ークなどを介して取得して、ローカルストレージに記録されたセカンダリ TSの 2つの TS を同時に再生選択することで、この 2本の TS間で様々なエレメンタリストリームの組み 合わせを可能とするアプリケーションである。
[0051] 図 15は、 Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSが、 B D-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図 である。本図では、 BD-ROM再生装置の内部構成のうち、 BD-ROMドライブ装置、口 一力ルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、 ストリームの多重分離を行う PID Filterを示す。そして本図におけるプライマリ TS(Vide 01.Audio 1 (English) ,Audio2(Spanish) , PG 1 (English Subtitle), IG1 (English Menu))ゝセカ ンダリ TS(Audio2(Japanese),Audio3(Korean),PG2(Japanese Subtitle) , PG3(Korean Sub title),IG20apanese Menu),IG3(Korean Menu))は、それぞれ BD- ROM、ローカルストレ ージカゝら供給されるトランスポートストリームを示す。ディスク単体には英語 (Audio 1)
とスペイン語 (Audio 2)しか記録されていないため、 日本語吹き替えなどをこのデイス タカも選択することはできない。し力しながら、コンテンツプロバイダが提供する日本 語吹き替え(Audio 2)の入ったセカンダリ TSを、ローカルストレージにダウンロードす れば、 日本語吹き替え音声 (Audio 2)と、 日本語字幕 (PG 2)と、 日本語メニュー画面 (IG 2)とを、デコーダに送り込むことができる。こうすることでユーザーは、 日本語吹き 替え音声 (Audio 2)と、 日本語字幕 (PG 2)とを、 日本語メニュー画面 (IG 2)から選択 して、映像 (Videol)と共に再生することができる。
[0052] Out-of-MUXアプリケーションは、同時に再生される 2つの TSの中に格納されたェ レメンタリストリームの種別ごとに 1つまで (言い換えれば、プライマリ TSとセカンダリ TS に格納されているビデオ 1本、オーディオ 1本、字幕 1本、メニュー 1本まで)という制 限下で、ユーザーが自由に、音声及び字幕を選択することができる。
全ての BD-ROM再生装置はプライマリ TS単体をデコードできる能力は持つ力 2つ の TSを同時にデコードする能力はない。したがって、 Out-of-MUXアプリケーションを 制限なく導入した場合には、ハードウェアの大規模ィ匕や、ソフトウェアを多く追加せざ るを得なくなり、 BD- ROM再生装置のコストアップに繋がる。そのため、 Out-of-MUX アプリケーションの実現にあたっては、プライマリ TSだけをデコードできるリソース上で 、 Out_of_MUXのアプリケーションを実現することができるかどうかどうかが鍵となる。
[0053] エレメンタリストリームの種別ごとに 1つまで、再生を許可するという制限は、プライマ リ TSのエレメンタリストリームをセカンダリ TSのエレメンタリストリームで「入れ換える」と 考えればよい。そのようにすることで、 1本の TSをデコードするリソース上で、 Out_of_M UXアプリケーションを実現することができ、デコーダ側のコストアップを抑制することが できる。本図の例では、プライマリ TSのオーディオ、字幕 (PG)、メニュー(IG)ストリー ムをセカンダリ TSのそれらと入れ換えて!/、る。
[0054] セカンダリ TSは、上述したようなローカルストレージである内蔵 HDDの他、フラッシュ メモリや一次記憶メモリ、ネットワーク越しの HDDや直接ネットワークを介したストリーミ ングなど力も入力されることもある。説明の便宜上、セカンダリ TSは、図 1に示したよう な内蔵型の HDDから供給されるものとする。
<ローカルストレージ 200の構成その 2.Clip情報 >
ローカルストレージ上に存在する Clip情報 (00003.clpi,00004.clpi)は、基本的には、 BD- ROMに記録されているものと同じデータ構造をもつ。ここでローカルストレージ上 の Clip情報の TS_Recording_Rateは、 BD- ROMからの AVClip読み出しと同じビットレー トに設定されている。つまり SubClipの Clip情報に記述された TS_Recording _Rateと、 M ainClipの Clip情報に記述された TS_Recording _Rateとは同一である。仮に、 MainClip の TS_Recording _Rateの値と、 SubClipの TS_Recording_Rateとが異なると、夫々の Sour ce De-packetizerから、バッファに送り込むまでのデータレートがどちらの TSを送り込 むかによって異なることになり、 Out-of-MUXアプリケーションは 1つの入力 TSと仮定 できるという仮定が成り立たなくなる。
[0055] また、 2つの TS間で再生されるべきエレメンタリストリームは、自在に選択されるので 、プライマリ TSのオーディオが選択されれば Source De- packetizerからデコーダ内の バッファまで力 プライマリ TS用のビットレートに設定され、セカンダリ TSのオーディオ が選択されると Source De-packetizerからデコーダ内のバッファまでが、セカンダリ TS のためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑 になってしまうからである。
くローカルストレージ 200の構成その 2.PlayList情報 >
続いて、ローカルストレージ 200上の PlayList情報について説明する。拡張子" mpls "が付与されたファイル (00002.mpls)は、 MainPath, Subpathと呼ばれる 2種類の再生 経路を束ねたものを Playlist(PL)として定義する情報である。図 16は、 PlayList情報の データ構造を示す図であり、本図に示すように PlayList情報は、 MainPathを定義する MainPath情報 (MainPathO)と、チャプターを定義する PlayListMark情報 (PlayListMark( ;))と、 Subpathを定義する Subpath情報 (SubpathO)とからなる。力かる PlayList情報の内 部構成、及び、 Playltem情報の内部構成は、 BD-ROMのものと同じであり、説明を省 略する。以降、 Subpath情報について説明する。
< PlayList情報の説明その 1.Subpath情報 >
MainPathが、主映像たる MainClipに定義される再生経路であるのに対し、 Subpath は、 MainPathと同期すべき SubClipに対して定義される再生経路である。
[0056] 図 17は、 Subpath情報の内部構成をクローズアップして示す図である。本図におけ
る矢印 hcOに示すように Subpath情報は、 SubClipの類型を示す SubPath_typeと、 1っ以 上の SubPlayltem情報 (· · · SubPlayltemO · · とを含む。
図中の引き出し線 hclは、 SubPlayltem情報の構成をクローズアップしている。 SubPl ayltem情報は、図中の矢印 hclに示すように『Clip jnformation_file_name』、『Clip_code c— identifier』、『SP— connection— condition』、『ref— to— ¾ f C— id[0]』、 [[SubPlayltem— In— time』 、『SubPlayItem— Out— time』、『sync— Playltem— id』、『sync— start— PTS— of— Playltem』からな る。
[0057] 『Clip_information_file_name』は、 Clip情報のファイル名を記述することにより、 SubPla yltemに対応する SubClipを一意に指定する情報である。
『Clip_codec_identifier』は、 AVClipの符号化方式を示す。
『SP— connection— condition』は、この SubPlayltem (カレント SubPlayltem)と、その 1つ前 の SubPlayltem(previousSubPlayltem)との接続状態を示す。
[0058] 『reむ o_STC_id[0]』は、この Playltemが対象として!/、る STC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、 SubClipの再生時間軸上における、 SubPlayltemの始点を 示す情報である。
『SubPlayItem_Out_time』は、 SubClipの再生時間軸上における、 SubPlayltemの終点 を示す情報である。
[0059] 『sync_PlayItem_id』は、 MainPathを構成する Playltemのうち、本 SubPlayltemが同期 すべきものを一意に指定する情報である。 SubPlayltem— In— timeは、この sync— Playltem— idで指定された Play Itemの再生時間軸上に存在する。
『sync_start_PTS_of_PlayItem』は、 sync_PlayItem_idで指定された Play Itemの再生時 間軸上にぉ 、て、 SubPlayItem_In_timeで指定された SubPlayltemの始点力 どこに存 在するかを示す。
[0060] < SubPath情報につ!、ての詳細その 2.三者の関係 >
ここでの三者とは、ローカルストレージ 200上の SubClip、ローカルストレージ 200上 の PlayList情報、 BD- ROM上の MainClipの三者を!、う。
図 18は、ローカルストレージ 200上の SubClipと、ローカルストレージ 200上の PlayLi st情報と、 BD- ROM上の MainClipとの対応を示す図である。本図において第 1段目は
、ローカルストレージ 200上に存在する SubClipを示す。この第 1段目に示すように、口 一力ルストレージ 200上の SubClip内のセカンダリ TSには、オーディオストリーム、 PG ストリーム、 IGストリームといった種別がある。これらのうち何れ力が、 SubPathとして同 期再生に供されることになる。
[0061] 第 2段目は、 PlayList情報により定義される 2つの時間軸を示す。第 2段目のうち下側 の時間軸は、 Playltem情報により定義される PlayList時間軸を示し、上側の時間軸は
SubPlayltemにより定義される SubPlayltem時間軸を示す。
本図に示すように、 SubPlayltem情報の SubPlayltem— Clip— information— file— nameは、 S ubClipを格納した. m2tsファイルのうち、どれを再生区間の対象として選ぶかという、 Su bClip選択の役割を果たして 、ることがわかる。
[0062] そして SubPlayItem.IN_time、 SubPlayltem.OuUimeは、 SubClip上の、再生区間の始 点及び終点を定義するという役割を果たしていることがわかる。
矢印 Sync_PlayItem_Idは、どの Playltemとの同期を意図して!/、る力と 、う同期指定の 役割を果たし、 sync_start_PTS_of_PlayItemは、 PlayList時間軸上における SubPlayltem
Jn_timeの位置を決める役割を果たす。
[0063] 以上が、 SubPath情報についての説明である。
< STN— table >
このローカルストレージ 200上の PlayList情報にお!、て特徴的であるのは、 STN_Ta bleである。以降、ローカルストレージ 200上の PlayList情報について説明する。
STN_tableは、 Playltem情報の Clip_Information_file_nameで指定されている MainClip に多重化された複数エレメンタリストリーム、及び、 SubPlayltem情報の Clipjnformatio n_file_nameで指定された SubClipに多重化されている複数エレメンタリストリームのうち 、同時に再生することが許可されている組み合わせを 1つ以上示すテーブルである。 PlayList情報における STN_Tableにおいて、同時に再生することが許可されている複 数エレメンタリストリームは、いわゆる"システムストリーム,,を構成することになる。
[0064] 具体的にいうと STN_tableは、 MainClipに多重化されている複数エレメンタリストリー ム、 SubClipに多重化されて!/、るエレメンタリストリームのそれぞれにつ!/、ての Stream_e ntryを、 Stream_attributeと対応付けることで構成される。
図 19 (a)は、 STN_tableの内部構成を示す図である。本図に示すように STN_tableは 、 STN_tableにおける entryと、 attributeとの組み (entry- attribute)を複数含み、これら e ntry—attriDuteの糸且みの個数 (number— of— video— stream— entries, number— of— audio— strea m—entnes,number— of— Ptj— stream— entries, number— of— IG— stream— entries)を すァ ~~タ概 造になっている。
[0065] entry-attributeの組みは、図中の括弧記号" { "に示すように、 Play Itemにおいて再 生可能なビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームのそれぞ れに対応している。
entry— attributeの詳細につ!、て説明する。
[0066] 図 19 (b)は、ビデオストリームに対応した Stream_attributeを示す図である。
ビデオストリームにおける Stream_attributeは、ビデオストリームの表示方式を示す『 Video_format』と、ビデオストリームの表示周波数を示す『frame_rate』等を含む。
図 19 (c)は、オーディオストリームに対応した Stream_attributeを示す図である。 オーディオストリームにおける Stream_attributeは、オーディオストリームの符号化方 式を示す『stream— coding— type』と、対応するオーディオストリームのチャネル構成を示 す『audio_presentation_type』と、対応するオーディオストリームのサンプリング周波数 を示す対応する『Sampling_frequency』と、オーディオストリームの言語属性を示す『au dio— language code』;gらな oQ
[0067] 図 19 (d)は、ビデオストリームにおける Stream_entryを示す図である。本図に示すよ うに、ビデオストリームの Stream_entryは、ビデオストリームの多重分離に用いられる PI Dを示す「ref_to_Stream_PID_of_Main_Clip」を含む。
MainClipにて多重化されているオーディオストリーム、 IGストリーム、 PGストリームの S tream_attributeは、この図 19 (d)の开式になっている。
[0068] <再生が許可されて!、るエレメンタリストリームのデータ量制限 >
STN_tableは、 BD- ROMから読み出されるエレメンタリストリーム、ローカルストレージ 力 読み出されるエレメンタリストリームのうち、再生が許可されて 、るものを示すが、 かかる STN_tableが、無制限に、エレメンタリストリームの再生を許可しているとなると、 デコーダシステムの破綻を招く恐れがある。
[0069] その理由は、以下の通りである。 MPEG2のデコーダシステム標準によると、 1つのト ランスポートストリームにおける ATC時間軸の TSパケット間には、オーバーラップが存 在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせる ための基本原則である。一方、 BD-ROMにおけるストリームの再生が許可されると共 に、ローカルストレージにおけるストリームの再生が許可されており、 BD- ROMからの AVClip再生と、ローカルストレージからの AVClip再生とを同時に実行する場合、 BD- ROMからの TSパケットと、ローカノレストレージからの TSパケットとにオーバーラップが 生じてしまう。
[0070] そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課し ている。
デコードエレメンタリストリームとは、 STN_tableにおいて再生が許可されていて、一 緒に再生するため、選択されたビデオストリーム、オーディオストリーム、 PGストリーム 、 IGストリームである。デコードエレメンタリストリームには、ローカルストレージからの読 み出されるものと、 BD-ROM力も読み出されるものの両者がある。
[0071] デコードエレメンタリストリームに課される制限とは、 STN_tableにおいて同時に再生 することが許可されて 、るエレメンタリストリームを含み、再生が許可されて ヽな 、エレ メンタリストリームを含まない AVClip(MainClip,SubClip)を構成する TSパケット (Decodin g TSパケット)の、 1秒当たりのビット量は 48Mbit以下になるというものである。
この 1秒という単位時間は、 "Window"と呼ばれ、 ATC Sequenceの時間軸上の任意 の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのよ うな 1秒の期間においても、この 48Mbit以下という条件を満たす必要がある。
[0072] 図 20は、 BD- ROMから読み出された TSパケットと、ローカルストレージから読み出さ れた TSパケットとを示し、これらの TSパケットのうち、デコーダに供給されるものを示す 。本図の第 1段目は、 BD- ROM力も読み出された複数の TSパケット、第 3段目は、ロー カルストレージカも読み出された複数の TSパケットを示す。これら第 1段目、第 3段目 の TSパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構 成する TSパケット (Decoding TSパケット)である。本図における第 2段目は、第 1段目に 示した Decoding TSパケット、第 3段目に示した Decoding TSパケットのうち、 1秒という
期間に属すものを示す。上述したように、 MPEG2のデコーダシステム標準によると、 1 つのトランスポートストリームにおける ATC時間軸の TSパケット間には、オーバーラッ プが存在してはならない。し力し、本図によると、 ATC時間軸において、 TSパケット間 のオーバーラップ rpl,rp2,rp3が発生していることがわかる。このように、 Windowという 単位時間において、 TSパケット動作のオーバーラップが許容されているのである。し かし、 MPEG2のデコーダシステム標準にはない別の要件が課されている。それが上 述した、 lWindow当たり 48Mbit以下という制限である。第 4段目は、この第 2段目に示 す、 Decoding TSパケットが満たすべき条件を数式で表している。この数式の意味は、 上述した Decoding TSパケットの個数を、ビット数に換算した値 (TSパケットのバイト数 である 188をかけ、ビット数 8で表した値)力 48Mbit以下になるというものである。
[0073] 任意の 1秒という期間において、 Decoding TSパケットに以上のような条件を課すの 力 本実施形態におけるビット量の制限である。 Out_of_MUXアプリケーションのため のォーサリング時には、 Sourceパケット列において、かかる Windowを、 1パケットずつ シフトさせつつ、 1秒という期間内の、 Decoding TSパケットのビット数力 48Mbit以下と いう制限を満たす力どうかをチェックする。もし、制限を満たせば、次の TSパケットに W indowをシフトさせ、制限を満たさねば、 BD-ROM規格に違反していると断定する。そ して、力かるシフトを繰り返した結果、 Windowの Out_Timeが、最後の Sourceパケットに 達すれば、当該 Sourceパケットは、 BD-ROM規格に整合しているとの判定を下す。
[0074] < Windowのシフト >
TSパケットのそれぞれには、 27MHzの時間精度をもつ ATSが付与されている。 ATC 時間軸上の座標は、 1/27,000,000秒という時間精度をもつ力 この ATC時間軸上の 各座標に、 ATSが存在するとは限らない。 ATC時間軸には、 ATSがまったく存在しな い期間や、 ATSが存在する期間が不規則に現れる。 ATSの出現にバラツキがあるの で、 Windowをシフトするにあたって、 In_Timeから 1秒後に ATSが存在しない場合、 Win dowの Out_Timeをどのように調整するかが問題になる。
[0075] Windowの Out_Timeは、原則として In_Timeの 1秒として設定される。ここで ATC時間 軸において、 In_Timeの 1秒後にあたる座標に ATSが存在すれば、 In_Time + l秒の座 標を、 Out_Timeとする。もし In_Timeの 1秒後にあたる座標に ATSが存在しなければ、 I
n_Time + l秒以降であって、 ATSが初めて現れる ATC時間軸の座標を、 Out_Timeと する。 ATSの空白期間を考慮しながら Out_Timeを調整しつつ、 Windowをシフトしてゆ くので、 Windowがシフトする度に、異なるビット値が算出される。 In_Timeを ITSパケット ずつシフトしてゆき、これに伴い Out_Timeを調整することで、 ATC時間軸におけるビッ ト値の遷移を緻密に計算してゆくことができる。
[0076] 図 21は、 Windowのシフトを示す図である。(a)〜(d)のそれぞれのうち、上段はベリ フアイの対象となる Sourceパケット列を示し、下段は、 Windowの In_Time、 Out_Timeを 示す。同図(a)では、 Windowの In_Timeは、 Sourceパケット ffiを指定している。この Win dowの In_Timeから 1秒後に存在する TSパケット 'が、 Windowの Out_Timeに設定される 同図(b)では、 Windowの In_Timeは、 Sourceパケット ffi+1を指定している。一方、この Windowの In_Timeから 1秒後にお 、て、 Sourceパケット ·+1にあたる座標には、 Source パケットの ATSが存在しない。この(b)における Windowの Out_Timeは、 TSパケット 'を 越えたものになるが、 TSパケット ·の直後に、 Sourceパケットが存在しないため、(b) の Windowにおけるビットレートは、(a)の Windowにおけるビットレートより少なくなつて しまう。これでは、(b)の Windowは、チェックに値しなくなる。そこで、 Out_Timeの調整 により、 Windowの In_Timeから 1秒以降に初めて現れる TSパケット ·+2を、 Windowの 0 ut_Timeにする。 Out_Timeをこのように設定すれば、(b)の Windowは、チェックに値す るちのとなる。
[0077] 同図(c)では、 Windowの In_Timeは、 Sourceパケット ffi+2を指定して!/、る。一方、この Windowの In_Timeから 1秒後には、 Sourceパケット ·+2が位置している。この(c)の Win dowは、 TSパケットの数が、(b)の Windowにおける数と変わらず、チェックに値しない 。故に、この(c)では、チェックが行われず、更に Windowの In_Timeを進める。
同図(d)では、 Windowの In_Timeは、 Sourceパケット ffi+3を指定している。一方、この Window_In_Timeから 1秒後において、 Sourceパケット '+3にあたる位置には、 Sourceパ ケットが存在しない。そこで上述したような Out_Timeの調整を行い、 Windowの In_Time 力 1秒以降に初めて現れる TSパケット ·+4を、 Windowの Out_Timeとする。こうするこ とで、 Window内の TSパケット数は、(b)と違うものとなり、チェックに値する。
[0078] 以上のような Windowシフトを伴う、ビット量チェックをォーサリング時に実行すること で、ローカルストレージ及び BD- ROMから TSパケットが読み出され、デコーダに供給 されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。 以上の Windowシフトによる保障を、図 22〜図 26の具体例を参照しながら説明する 図 22の第 1段目は、 BD- ROMから読み出された TSパケット、ローカルストレージから 読み出された TSパケットのデータ量の時間的推移を示すグラフである。横軸は時間 軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、 B D- ROM及びローカルストレージからの読み出し時のビット量は、破線の曲線のように 推移する。
[0079] 図 22の第 2段目は、 BD- ROMから読み出された TSパケット、ローカルストレージから 読み出された TSパケットのうち、デコーダに供給されるものの合計のデータ量を示す 。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量 は、 STN_tableで許可されたストリームに属する TSパケットの合計量となる。ワーストケ ースにおいては、合計の転送量が 96Mbit近くになり、このデータ量の TSパケットが供 給されると考えられる。グラフの時間軸を、 7つの Windowに分割して、個々の Window における供給量と、 Window毎の転送許容量とを対比する。
[0080] 図 22の第 3段目は、この図 22の第 2段目におけるグラフを 1秒という期間で区切った ものであり、図 23 (a) (b)は、各 Windowの転送許容量と、 Windowにおけるデコーダへ の供給量とを対比して示す図である。 Windowにおける転送許容量は、 1秒当たり 48M bitであり、 0.5秒に換算すれば 96Mbitとなる。図中のパターン pnlのハッチングは、デ コーダへのデータ供給量を示す。図中のパターン pn2のハッチングは、 Window毎の 転送許容量を示す。パターン pnlのハッチングが付された部分の面積力 何れの Win dowにおいても、パターン pn2のハッチングが付された部分の面積以下になっている。 これは、 BD- ROM及びローカルストレージからのデータ供給量が、どの Windowにお いても、 Windowにおける転送許容量以下に抑えられていることを意味する。
[0081] ATC時間軸上のどの時点においても、 1秒当たりのデコーダへの転送許容量は、 48 Mbit以下になるので、たとえ局所的に、デコーダへの転送許容量が 96Mbit近くにな
つたとしても、 48Mbit = 96Mbit X 0.5秒の計算により、力かる 96Mbitでの転送が 0.5秒 継続することはありえない。従ってデコーダが、このピークが到来する前に、 BD-ROM 、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダ 一フロー又はオーバーフローが生じることはな 、。
[0082] Windowにおける転送許容量、つまり、 1秒当たり 48Mbitという数値は、 MPEGに準拠 したデコーダ力 ノ ッファに先読みできる数値を、目安にして定めたものである。バッ ファに先読みできるデータ量力 もっと大きい場合は、 1秒当たりのデータ量を更に大 きくしたり、また Windowの時間長を更に長くすることができる。このことから、本発明に 力かる数値範囲は、 1秒当たり 48Mbitというものに、限定されるべきでない。
[0083] 以上が、 STN_tableにおいて再生が許可されているセカンダリ TSにおけるデータ量 制限についての説明である。
、 connection— condition†青報、 sp— connection— condition†青報の設定
次に、 Out_of_MUXアプリケーションを実現する場合の、 Playltemにおける connectio n— conmtion†青報、及び、 SubPlayltemにおける sp— connection— condition†青報の設定に 、て説明する。 connection— condition†*報のフィ ~~ノレドの値、 sp— connection— conditi on情報のフィールドの値は" Γ, "5", "6"の値を取る事ができ、それぞれ以下のような 意味を持つ。
[0084] connection— condition=l(CC=l): この Playltem (カレント Playltem)と直前の Playltem( previousPlayltem)とはシームレス接続される保証がない。つまり、フリーズして再生が 途切れることが許容された接続形態 (ノンシームレス接続)である。
connection_condition=5(CC=5): カレント Playltem側の MainClipに多重化されて!/ヽ るビデオストリーム、 PGストリーム、 IGストリームと、 previousPlayltem側の MainClipに多 重化されているビデオストリーム、 PGストリーム、 IGストリームとがシームレス接続され る保証がある。一方、 MainClipに多重化されているオーディオストリームについてはこ の限りではない。
[008¾」 connection— condition=6(CC=6): カレント Playltemと previousPlayltemに属するそれ ぞれの TSストリームは論理的に連続であり(時間軸が連続しており、符号化方式も連 続している)、オーディオストリーム、ビデオストリームともにシームレス接続される保証
がある。
SubPlayltemfti内に記述された sp_connection_condition情報は、次のように定義がで きる。
[0086] sp— connection— condition情報 (SP—CC=1): この SubPlayltem (カレント SubPlayltem)と 直前の SubPlayltem(previousSubPlayltem)とはシームレス接続される保証がない sp_connection_condition情報 (SP_CC=5) :カレント SubPlayltem側の SubClipに多重ィ匕 されている PGストリーム、 IGストリームと、 previousSubPlayltem側の SubClipに多重化さ れている PGストリーム、 IGストリームとがシームレス接続される保証がある。一方、 Sub Clipに多重化されて!/、るオーディオストリームにつ 、てはこの限りではな!/、。
[0087] sp— connection— condition情報 (SP—CC=6) : カレント SubPlayltemと、 previousSubPlaylt emとに属するそれぞれの TSストリームは論理的に連続しており(時間軸が連続してお り、符号ィ匕方式も連続している)、シームレス接続される保証がある。
Out_of_MUXアプリケーションを実現する Playltemに対して設定されるべき SubPlaylt emは、 SubPlayltem内のビデオストリームやオーディオストリーム、または PGストリーム や IGストリームが Playltem内にあつたとしても不整合を起こさないようにすべきである。 そのため、全く同一の接続条件となる。つまり Playltem#l、 Playltem#2力CC=1で接続 されるならば、それに対応する SubPlayItem#l、 SubPlayItem#2も CC=1で接続される。 同様に、 Playltem#l、 Playltem#2が CC=5で接続されるならば、それに対応する SubPl ayltem#l、 SubPlayItem#2も CC=5の条件を満たしながら接続される。
以下、図 24、図 25、図 26を参照しながら、 Out_of_MUXアプリケーションを構成する Playltem ^ SubPlayltemの In— Time、 Out— Timeの関係と、 connection— condition†青報の羊 細について説明する。
[0088] < In— Time、 Out— Timeの関係 >
図 24は、 Out_of_MUXを構成する Playltem、 SubPlayltemの接続状態を示す図であ る。本図における第 1段目は、 SubClip時間軸であり、第 2段目、第 3段目は、 SubPlaylt em時間軸、 PlayList時間軸である。第 4段目は、 MainClip時間軸である。本図におい て、 Playltem側の connection— condition情報力 ' = 5"である場合、 SubPlayltem側の con nection— condition情報 、 SP—し C = 5にな 。
[0089] 図 25は、図 24に示した、 Playltemの connection_condition情報、 SubPlayltemの sp_c onnection_condition情報が" =5"に設定されている場合の、 Playltemにおける In_Time 、 Out_Timeと、 SubPlayltemにおける In_Time、 Out_Timeとの関係を示す図である。第 1 段目、第 4段目は図 24と同じである。図 24に示した 2つの PlayItem(PlayItem情報 #1、 Playltem情報 #2)のうち、 Playltem情報 #1の In_Timeは、時刻 tlを表し、 Out_Timeは、 時刻 t2を表す。 Playltem情報 #2の In_Timeは時刻 t3、 Playltem情報 #2の Out_Timeは、 時刻 t4を表す。
[0090] Playltem側の接続状態力 CC = 5に設定されていると、 SubPlayltemにおける Sync_St art_Pts_of_PlayItemは、 Playltemの In_Timeと同じ時点を示す。そして SubPlayltemにお ける In_Time、 Out_Timeは、 Playltemの In_Time、 Out_Timeと同じ時刻を表す。このよう に、 Playltemの connection— condition†青報力 21 =o 場合、 ¾ub Playltemの sp— conn ection_condition情報も" =5"に設定され、尚且つ、 Playltemの In_Time、 Out_Timeは、 SubPlayltemの In_Time、 Out_Timeと同一時点を表す。
[0091] Playltemの In_Time、 Out_Time、 SubPlayltemの In_Time、 Out_Timeは、それぞれ Vide o Presentation Unit, Audio Presentation Unitの PTSを参照している。 Playltemの In_Ti me、 Out_Timeと、 SubPlayltemの In_Time、 Out_Timeとが一致しているということは、 Pla yltemの In— Time、 Out— Timeで参照 れ video Presentation Unit、 Audio Presentatio n Unitの PTS値が、 SubPlayltemの In_Time、 Out_Timeで参照される Video Presentation Unit, Audio Presentation Unitの PTS値と同じであることを意味する。そうすると、プラ ィマリ TS、セカンダリ TSは、時間長が同じで、ォーサリング時において Video Presenta tion Unit, Audio Presentation Unitの PTSが、同じになるよう、エンコードされる必要が ある。このようにプライマリ TS、セカンダリ TSを作成しておくことも、 CC = 5、 SP_CC=5を 実現するにあたっての条件になる。
[0092] くシームレス接続点との関係のまとめ〉
これらの図で明らかになった、シームレス接続点と、カレント Playltem、カレント SubPl ayltemとの関係は以下の通りである。 Playltem情報における connection_condition情 報と、 SubPlayltem情報における sp_connection_condition情報とが同じ接続点でのシ ームレス接続 (CC=5、 SP_CC=5)を意図している場合、カレント Plavltem、カレント SubPl
ayltemは、このシームレス接続点の直後に位置することになる。そのため、シームレス 接続点の直後に位置するカレント Playltemにおいて、その開始点を表す Playltem.ln_ Timeは、当該シームレス接続点の直後に位置するカレント SubPlayltemにおいて、そ の開始点を表す SubPlayItem.In_Timeと一致することになる。
<同期再生するにあたって、参照すべき STC値 >
図 26は、 Playltemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、 参照されるべき STC値、 SubPlayltemの In_Timeから Out_Timeまでに存在する部分を 再生する場合に、参照されるべき STC値を示す。第 2段目、第 3段目は、前図に示し たものと同じである。第 1段目は、 SubPlayltemの In_Timeから Out_Timeまでに存在する 部分を再生する場合に、参照されるべき STC値をグラフ形式で示している。第 4段目 も、 Playltemの In_Timeから Out_Timeまでに存在する部分を再生する場合に、参照さ れるべき STC値をグラフ形式で示している。第 1段目における横軸は時間軸であり、 縦軸は時間軸上の各時点における STC値を表す。第 1段目における STC値は、 SubPl ayltem情報 #1の In_Timeから Out_Timeまでの期間における単調増力 Uzklと、 SubPlaylt em情報 #2の In_Timeから Out_Timeまでの期間における単調増カロ zk2とからなる。第 4 段目における STC値は、 Playltem情報 #1の In_Timeから Out_Timeまでの期間における 単調増加 zk3と、 Playltem情報 #2の In_Timeから Out_Timeまでの期間における単調増 カロ zk4とからなる。
[0093] Playltemの In_Timeは、 SubPlayltemの In_Timeと同じ時点を表すので、上述したグラ フにおいて、 STCの初期値は同じであり、途中の時点においても同じなる。つまり、 P1 ayltemの In_Timeから Out_Timeまでに存在する任意の時点 iの Sourceパケットをデコー ダに供給する際、参照すべき STC値である STC2G)は、 SubPlayltemの In_Timeから Out _Timeまでに存在する同じ時点 iの Sourceパケットをデコーダに供給する際、参照すベ き STC値である STCl(i)と同じになる。 STC値が同じであると、装置内の STCカウンタは 、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置におけ る制御が簡略化される。
[0094] 仮に、上述した図 25、図 26の制限に反し、 1つの Playltemに対して 2つ以上の SubPl ayltemを準備した場合、その SubPlayltemの境界において、映像や音声が途切れてし
まい、 Playltemの途中で再生が一時停止するなどの不便が生じる。また、 Out-of-MU Xアプリケーションにおいて、プライマリ TSをセカンダリ TSに入れ換えるという処理を実 現する場合、この入れ替えの前後で、 STC時間軸を切り替える必要があるので、再生 装置における同期制御が複雑化する。一方、 Playltem、もしくは SubPlayltemの In_Tim e、 Out_Timeを共に、一連続な STC時間軸に定義した場合、上述したような途切れや トランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、 1 つの Playltemに対して同一の開始点、同一の終了点を SubPlayltemにもたせるのであ る。
[0095] < In— Time、 Out— Timeの誤差 >
ここで Playltemにおけ。 In— l ime、 Out— Timeと、 SubPlayltemにおける In— Time、 Out— Ti meとの一致は、完全に一致していることを要求するのではなぐ多少の誤差を許容す る趣旨である。この In_Time、 Out_Time間の誤差について説明する。
Playltemの In_Time、 Out_Timeとなる STC時刻は、 Playltemがビデオフレームに対し て設定される。これに対し、 SubPlayltemではオーディオフレームに対して設定される こととなる。何故なら、 SubPlayltemは、コメンタリが主用途でビデオストリームが多重化 されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションュ ニットの再生時間長の違いから、開始/終了時刻が合わない。したがって、最低でも、 1フレーム未満の誤差を認める必要がある。 Playltemftiと SubPlayltemftiの開始/終了 時刻に関して、どちらも同一の STC時間軸に対して、
I (Piayltem#n.uut- Playltenwn.In) - (¾ubPiayItem#n.uut— time- ¾ubPiayItem#n.In— ti me) I≤ Playltemftiの中で最小の再生時間を持つビデオの 1プログレッシブフレーム もしくは 2インターレースフィールドの再生時間≤ 1/60秒
としても規定する。上記左辺の値は、 Playltemftiの中で最大の再生時間を持つビデ ォの 1プログレッシブフレームもしくは 2インターレースフィールドの再生時間(≤ 1/25 秒)としても良いし、 1秒以下などとしても良い。
以上が、 Playltem, SubPlayltemにおける In_Time、 Out_Timeの関係についての説明 である。
[0096] 次に、 connection— condition†青報、 sp— connection— condition†青報につ ヽて羊し 説
する。 CC = 5、 SP_CC=5の条件を満たすには、 AVストリームのレベル、トランスポート ストリームのレべノレ、 Video Presentation Unit及び Audio Presentation Unitのレべノレ、 エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要が ある。
<AVストリームのレベル >
Current Playltemの connection— condition情報、及ひ、 sp— connection— condition情報 力 S "5"に設定されていることは、 Previous Playltemで再生される AVストリームの終了点 と、 Current Playltemで再生される AVストリームの開始点との間に、 "Clean Break"が 存在することを意味する。
[0097] Clean Breakを実現するには、 Previous Playltemで再生される AVClipと、 Current PI ayltemで再生される AVストリームと力 以下の要件を満たさねばならな!/、。
(1) Previous Playltemで指定されている MainClipの終了点に、不必要な Access Unit が存在せず、 PTSを有する不要な Access Unitが、 Previous Playltemの Out_Time以降 力 排除されていること。
[0098] 同様に、 Previous SubPlayltemで指定されている SubClipの終了点に、不必要な Acc ess Unitが存在せず、 PTSを有する不要な Access Unit力 Previous SubPlayltemの Ou t_Time以降力 排除されて 、ること。
(2) Current Playltemにて指定される AVストリームの開始点において、 PTSをもつ不 要な Access Unitが、 Current Playltemの In_Timeの前から取り除かれていること。そし て、 MainClipの最初の Audio Presentation Unitが、 STC時間軸の In_Timeで再生され る Sampleを含んで 、ること。
[0099] 同様に、 Current SubPlayltemにて指定される AVストリームの開始点において、 PTS をもつ不要な Access Unit力 Current SubPlayltemの In_Timeの前から取り除かれてい ること。そして、 SubClipの最初の Audio Presentation Unitが、 STC時間軸の In_Timeで 再生される Sampleを含んで!/、ること。
(3) Previous Playltemにて指定される MainClipを構成する全ての Sourceパケットが、 Current Playltemにて指定される MainClipの先頭パケットが送り込まれる前に、デコー ダシステムに取り込まれるように、多重化されること。
[0100] 同様に、 Previous SubPlayltemにて指定される SubClipの全データが、 Current SubPl ayltemにて指定される SubClipの先頭パケットが送り込まれる前に、デコーダシステム に取り込まれるように、多重化されること。
以上が、 AVストリームにおいて満たすべき条件についての説明である。続いて、トラ ンスポートストリームのレベルにおいて満たすべき条件について説明する。
<トランスポートストリームのレベル >
ここで CC = 5にお!/、てシームレス接続の対象となる 2つのプライマリ TSを、プライマリ TS1、プライマリ TS2と呼ぶ。 SP_CC=5においてシームレス接続の対象となる 2つのプラ ィマリ TSを、セカンダリ TS1、セカンダリ TS2と呼ぶ。
[0101] 図 27は、 previousPlayItem、 previousSubPlayltemにて参照されて 、る AVClip、カレ ント Playltem、カレント SubPlayltemにて参照されている AVClipにおいて、 TS1、 TS2が どのように特定されるかを示す図である。本図における第 4段目は、プライマリ TS1、プ ライマリ TS2を示し、第 3段目は、 previousPlayltem側の MainClipl、カレント Playltem側 の MainClip2を示す。第 1段目は、セカンダリ TS1、セカンダリ TS2を示し、第 2段目は、 previousSubPlayltem側の SubClipl、カレント SubPlayltem側の SubClip2を示す。
[0102] プライマリ TS1は、 MainCliplにおいて、ハッチングが付されたデータから構成される 。 MainCliplにおけるハッチングが付されたデータは、 Previous Playltemにおける In_Ti meに対するデコードを開始することができる Sourceパケットから始まる。かかる Source ノヽケットは、 In— Time ^参照して ヽる Video Presentation Unit及ぴ Audio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、 MainCliplの 最後のパケットで終わる。
[0103] プライマリ TS2は、 MainClip2においてハッチングが付されたデータから構成される。
MainClip2においてハッチングが付されたデータは、 MainClip2の最初の Sourceバケツ ト力 始まる。そして MainClipにおいてハッチングが付されたデータは、カレント Playlt emに対するデコードを終了する Sourceパケットで終わる。力かる Sourceパケットは、 Cu rrent Playltemの Out— Timeで参照される Video Presentation Unit, Audio Presentation Unitの末尾に位置する Sourceパケットである。
[0104] セカンダリ TS1は、 SubCliplにおいて、ハッチングが付されたデータから構成される
。 SubCliplにおけるハッチングが付されたデータは、 previousSubPlayltemにおける In_ Timeに対するデコードを開始することができる Sourceパケットから始まる。力かる Sourc eノヽケットは、 In— Time力参照して ヽる Video Presentation Unit及ぴ Audio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、 SubCliplの 最後のパケットで終わる。
[0105] セカンダリ TS2は、 SubClip2においてハッチングが付されたデータ力も構成される。 S ubClip2においてハッチングが付されたデータは、 SubClip2の最初の Sourceパケットか ら始まる。そして SubClipにおいてハッチングが付されたデータは、カレント Playltemに 対するデコードを終了する Sourceパケットで終わる。力かる Sourceパケットは、カレント ubPlayltemの Out— Timeで参照 れる Video Presentation Unit, Audio Presentation U nitの末尾に位置する Sourceパケットである。
[0106] 以上の説明から、 CC = 5、 SP_CC=5において、接続すべき 2つのトランスポートストリ ームが、 MainClip、 SubClip内に、どのように配置されるかがわかる。 previousPlayltem 側の MainClipは、 previousPlayltemの Out_Timeで参照される Video Presentation Unit 、 Audio Presentation Unitで終わっていなければならず、カレント Playltem側の MainC lipも、カレント Playltemの In_Timeで参照される Video Presentation Unit, Audio Presen tation Unitで始まらなければならない。この関係は、 previousSubPlayltemの同様であ り、 previousSubPlayltem側の SubClipは、 previousSubPlayltemの Out_Timeで参照され る Audio Presentation Unitで終わっていなければならず、カレント SubPlayltem側の Su bClipも、カレント SubPlayltemの In_Timeで参照される Audio Presentation Unitで始まら なければならな 、。これは上述したように、 previousSubPlayltemの Out_Timeから参照 される Video Presentation Unit、 Audio Presentation Unit以降に、余分な Audio Prese ntation Unitは存在してはならないからである。一方、 previousSubPlayltem側の SubCli pは、 previousSubPlayltemの In— Timeで参照 れる Audio Presentation Unitで始ま 必 要はなぐカレント SubPlayltem側の SubClipも、カレント SubPlayltemの Out_Timeで参 照される Audio Presentation Unitで終わる必要はない。
[0107] 以上の図 24、図 27から、プライマリ TS、セカンダリ TSは、同じ時間長に構成され、 Vi deo Presentation Unit, Audio Presentation Unitの PTS値が同一値になるように作成
されねばならな ヽ。更に previousPlayltem側の MainClip、 previousPlayltem側の SubCli pは、 Out— Timeにあたる Video Presentation Unit、 Audio Presentation Unitで終わるよ う、多重化されねばならず、カレント Playltem側の MainClip、カレント Playltem側の Sub し lipi 、 In— Time【こあ 7こる Video Presentation Unit、 Audio Presentation Unitで開始す るよう、多重化されねばならない。
[0108] そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
• TS1と TS2におけるプログラム数が 1つであること
'ビデオストリームの数力 S1つであること
'オーディオストリーム数が同じであること
•Previous Playltemにおける STN— tableと、 Current Playltemにおける STN— tableとは 同じ内容になること
.個々の Playltemにおけるトランスポートストリームの再生期間は 3秒
以上が、 CC = 5、 SP_CC=5で 2つのストリームを接続するにあたってトランスポートス トリームのレベルで満たすべき条件である。続いて、 Video Presentation Unit, Audio Presentation Unitのレベルで満たすべき条件につ!、て説明する。
Video Presentation Unit、 Audio Presentation Unitのレヘル〉
CC = 5とは、本来、別々である答のプライマリ TS1たるビデオストリームの最後の Vide 0 Presentation Unitの開始時刻と、プライマリ TS2たるビデオストリームの最初の Video Presentation Unitの終了時刻とを一致させることをいう。 Video Presentation Unitの 終了時刻 ·開始時刻を一致させようとすると、かかる Video Presentation Unitと同期再 生すべき Audio Presentation Unitの扱いが問題になる。何故なら、ビデオと、オーデ ィォとではサンプリング周波数が異なり、 Video Presentation Unit, Audio Presentatio n Unitの時間長は一致しないからである。
[0109] 図 28は、 CC = 5、及び、 SP_CC = 5の詳細を示す図である。第 1段目〜第 3段目は、 ubPlayltemにおける connection— condition 不し、束 4段目〜弟 7段目は、 Playltemに おける sp_connection_conditionを示す。第 4段目は、 TS1、 TS2における複数の Video P resentation Unit 不し、第 5段目は、 TS1における Audio Presentation Unit、 TS2にお ける Audio Presentation Unitを示す。第 6段目は、 MainClipにおける STCの値を示す
。第 7段目は、 MainClipにおけ Sourceパケット列を示す。
[0110] 本図において、ハッチングが付されているのは、 TS1側の Video Presentation Unit, Audio Presentation Unit, Sourceパケットであり、ハッチングが付されていないのは、 T S21則の Video Presentation Unit、 Audio Presentation Unit、 Sourceノヽケットで te 。 本図において CC = 5とは、 Video Presentation Unit境界を一致させるものの (第 4段 目)、 MainClipの ATCにおいてギャップがあり (第 7段目)、 MainClipの Audio Presentati on Unitでオーバラップが存在する (第 5段目)状態をいう。 SP_CC=5とは、 SubClipの AT Cにおいてギャップがあり (第 1段目)、 SubClipの Audio Presentation Unitでオーバラッ プが存在する (第 2段目 )状態を ヽぅ。
[0111] 上述した Video Presentation Unitの境界とは、 TS1側から見ればと、第 4段目におけ る最後の Video Presentation Unitの終了点 PTSl(lstEnd)+Tppにあたり、 TS2側から見 れば、第 4段目における Video Presentation Unitの開始点 PTS2(2ndSTART)にあたる
TS1のうち、境界時点 T4に一致する Audio Presentation Unitの終了点を T5a、 TS2の うち、時点 T4に一致する Audio Presentation Unitの開始点を T3aとした場合、 MainCli pにおけるオーバラップは、 Audio Presentation Unitは T3aから T5aにまでとなる。
[0112] また本図にお 、て、 SubClipの Audio Presentation Unitは、 MainClipの Audio Presen tation Unitより長くなつている。これは、 SubClipにおけるオーディオストリームはネット ワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、その ため Audio Presentation Unitlつ当たりの時間長が長くなる力もである。この第 1段目 における Sourceパケット列においても、第 7段目同様のギャップが存在し、第 2段目に おける Audio Presentation Unitにおいても、第 4段目と同様のオーバーラップが存在 している。 SubClipの TS1における Audio Presentation Unitのうち、境界時点 T4に一致 する Audio Presentation Unitの終了点を T5b、 SubClipの TS2における Audio Presentat ion Unitのうち、時点 T4に一致する Audio Presentation Unitの開始点を T3bとした場 合、オーバラップは T3bから T5bまでとなる。
[0113] この図から、 CC = 5、 SP_CC=5を実現するには、 Video Presentation Unit, Audio Pr esentation Unit,パケットのレベルにおいて、以下の 4つの条件を満たさねばならな
いことがわ力る。
(1)TS1におけるオーディオストリームの最後の Audio Presentation Unitは、 previous Playltem, previousSubPlayltemにて指定される TSlにおける最後のビデオのピクチャ の表示期間の終期に等しい再生時刻をもつサンプルを含む。
[0114] (2)TS2におけるオーディオストリームの、最初の Audio Presentation Unitは、カレント Playltem,カレント SubPlayltemにて指定される TS2の最初のピクチャの表示期間の先 頭と等 Uヽ再生時刻をもつサンプルを含む。
(3)接続点の Audio Presentation Unit列において、ギャップが存在しない。これは接 続点において、 Audio Presentation Unit列のオーバーラップが発生してもよいことを 意味する。しかしかかるオーバーラップは、 2つのオーディオフレーム再生期間より短 Vヽ大きさでなければならな!/、。
[0115] (4)TS2の最初のパケットは、 PATを含み、 1つ以上の PMTがその直後に後続してもよ い。 PMTが TSパケットのペイロードより大きければ、 PMTは、 2パケット以上になること もある。 PMTを格納した TSパケットには、 PCRや SITが存在してもよい。
< In— Time、 Out— Timeと Video Presentation Unitとの関係 >
図 29は、 previousPlayltem及びカレント Playltemにて指定される複数の Video Prese ntation Unitと、複数の Audio Presentation Unitと、 STC時間軸との関係を示す図であ る。第 1段目は、 previousPlayltemが参照している TS1に帰属する複数の Video Presen tation Unitと、カレント Playltemが参照している TS2に帰属する複数の Video Presentat ion Unitとを示し、第 2段目は previousSubPlayltemが参照しているタイムスタンプに帰 属している複数の Audio Presentation Unitと、カレント SubPlayltemが参照している TS2 に帰属する複数の Audio Presentation Unitとを示す。第 3段目は、 previousSubPlaylte mの TSlにおける STC時間軸と、カレント SubPlayltemの TS2における STC時間軸とを示 す。第 2段目に示す TS1における Audio Presentation Unit, TS2における Audio Presen tation Unitのうち、 TS2に属する Audio Presentation Unitの開始点 T3bから、 TS2に該 当する Audio Presentation Unitの終了時刻 T5bまでがオーバラップになるのは、図 28 に示した通りである。そしてカレント SubPlayltemの In_Time、 previousSubPlayltemの Ou t_Timeは、それぞれ、 Video Presentation Unitの境界である時点 T4を指定している。
カレント Playltemの In_Time、 SubPlayltemの Out_Timeもまた、 Video Presentation Unit の境界である時点 T4を指定しているので、 Playltemの In_Time、 Out_Timeは、 SubPlayl temの In_Time、 Out_Timeと一致して 、ることになる。このように previousSubPlayltemの I n_Time、カレント SubPlayltemの Out_Timeは、 BD- ROMとは異なる記録媒体に記録さ れているにも拘らず、 MainClipにおける Video Presentation Unitの境界と一致してお り、更にまた、 previousPlayltemの Out_Time、カレント Playltemの In_Timeと一致してい ることがゎカゝる。
[0116] 以上が Video Presentation Unit, Audio Presentation Unitレベルの条件にっ 、ての 詳細である。
くエレメンタリストリームのレベル >
次に、 CC = 5、 SP_CC=5実現のための、エレメンタリストリームレベルでの符号化条 件について説明する。
[0117] 個々のエレメンタリストリームのレベルでは、以下の符号ィ匕条件を満たす必要がある
(1)ビデオストリーム
'シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、 •シームレス接続の直前のビデオストリームは、 sequence_end_code(MPEG- 2 Video 時)、 end_of_ sequence_rbsp(MPEG-4 AVC時)で完了すること、
(2)オーディオストリーム
•同一の PIDをもつオーディオストリームの符号化方式が変わらな!/、こと、 サンプリング周波数や量子化ビット数、チャンネル数などが変わらな 、こと、
(3) PGストリーム
a)TSl及び TS2における PGストリームの数が同一である。
[0118] b)TSlにおける PGストリームは、 End of Display Setと呼ばれる機能セグメントで終了 して ヽること
c) TSlにおける最後の PCSを運ぶ PESパケットの PTSは、 previous Playltem、 previous SubPlayltemの Out_Timeにあたる再生時刻より早 、時点を示す。
d) TS2の PGストリームは、 Epoch Start, Epoch Continueタイプの Display Setから始ま
らねばならない。
[0119] e)TS2における最初の PCSを運ぶ PESパケットの PTSは、カレント Playltem、カレント Su bPlayltemの In_Timeにあたる再生時刻と等し!/、か、より遅!、時点を示す。
DTS2からの Sourceパケットが続ぐ TS1力もの Sourceパケットの取り出しは、同じシス テム時間軸の、 STC1、 STC2として定義することができ、これらの DTS値/ PTS値には 重複が存在しない。
(4)IGストリーム
a)TSl及び TS2における IGストリームの数が同一である。
[0120] b)TSlにおける IGストリームは、 End of Display Setと呼ばれる機能セグメントで終了 して ヽること
c) TSlにおける最後の ICSを運ぶ PESパケットの PTSは、 previousPlayItem、 previousS ubPlayltemの Out_Timeにあたる再生時刻より早い時点を示す。
d) TS2の IGストリームは、 Epoch Start.Epoch Continueタイプの Display Setから始まら ねばならない。
[0121] e)TS2における最初の ICSを運ぶ PESパケットの PTSは、カレント Playltem、カレント Su bPlayltemの In_Timeにあたる再生時刻と等し!/、か、より遅!、時点を示す。
DTS2からの Sourceパケットが続ぐ TS1力もの Sourceパケットの取り出しは、同じシス テム時間軸の、 STC1、 STC2として定義することができ、これらの DTS値/ PTS値には 重複が存在しない。
previousPlayltemと、カレント Playltemとを CC = 5で接続し、 previousSubPlayltemと、 カレント SubPlayltemとを SP_CC=5で接続するには、以上の AVストリームのレベル、トラ ンスポートストリームのレべノレ、 Video Presentation Unit及び Audio Presentation Unit のレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならな い。
[0122] 以上がローカルストレージ 200の構成たる PlayList情報についての説明である。
以上で本発明に力かる記録媒体にっ 、ての説明を終える。続、て本発明に係る再 生装置について説明する。
図 30は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生
装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は 、主としてシステム LSIと、ドライブ装置という 2つのパーツからなり、これらのパーツを 装置のキャビネット及び基板に実装することで工業的に生産することができる。システ ム LSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうし て生産される再生装置は、 BD- ROMドライブ la、リードバッファ lb,c、 ATCカウンタ 2a, c.Source Depacketizer2b,d、 ATCカウンタ 2c,d、 STCカウンタ 3a,c、 PID Filter3b,d、 ビデオデコーダ 4、 Transport Buffer(TB)4a、 Multiplexed Buffer(MB)4b、 Coded Pictu re Buffer(CPB)4c、ビデオデコーダ 4d、 Re-order Buffer4e、スィッチ 4f、ビデオプレー ン 5、オーディオデコーダ 9、 Transport Buffer6、 Elementary Buffer7、デコーダ 8、ス イッチ lOa,b,c,d、 Interactive Graphicsアコ ~~ダ 11、 Transport Buffer(TB)l la、 Coded Data Buffer(CDB)l lb、 Stream Graphics Processor(SGP)l lc、 Object Bufferl ld、 C omposition Bufferl le、 Grapnics Controller 1 Ifゝ Interactive Graphicsプレ ~~ン 12、 Pr esentation Graphicsアコ ~~タ 13、 Transport Buffer(TB)13a、 Coded Data Buffer(CDB )13b、 Stream Graphics Processor(SGP)13c、 Object Buffer 13d、 Composition Buffer 13e、 Graphics Controller 13f、 Presentation Graphicsプレ ~~ン 14、 Transport Buffer 15a、 Elementary Buffer 15b、アコ ~~タ l5c、 Transport Buffer 16a、 Elementary Buffer 16b、デコーダ 16c、合成部 17、メモリ 21、コントローラ 22、 PSRセット 23、 PID変換部 24、ネットワーク部 25、操作受付部 26、ローカルストレージ 200から構成される。
[0123] BD— ROMドライブ laは、 BD— ROMのローデイング/イジェクトを行い、 BD— ROMディ スクに対するアクセスを実行する。
リードバッファ (RB)lbは、 BD- ROMから読み出された Sourceパケット列を蓄積する。 リードバッファ (RB)lcは、 LastPlayタイトルからから読み出された Sourceパケット列を 蓄積する。
[0124] ATC Counter2aは、プライマリ TSを構成する Sourceパケットのうち、再生区間の最初 に位置するものの ATSを用いてリセットされ、以降ソースデバケツタイザ 2bに ATCを出 力してゆく。
ソースデバケツタイザ (Source De- packetizer)2bは、プライマリ TSを構成する Source パケットから TSパケットを取り出して、送出する。この送出にあたって、各 TSパケットの
ATSに応じてデコーダへの入力時刻を調整する。具体的には、 ATC Counter2aが生 成する ATCの値と、 Sourceパケットの ATS値とが同一になった瞬間に TS_Recording_Ra teで、その TSパケットだけを PID Filter3bに転送する。
[0125] ATC Counter2cは、セカンダリ TSを構成する Sourceパケットのうち、再生区間の最 初に位置するものの ATSを用いてリセットされ、以降ソースデバケツタイザ 2dに ATCを 出力してゆく。
ソースデバケツタイザ (Source De- packetizer)2dは、セカンダリ TSを構成する Source パケットから TSパケットを取り出して、送出する。この送出にあたって、 ATSに応じてデ コーダへの入力時刻を調整する。具体的には、 ATC Counter2cが生成する ATCの 値と、 Sourceパケットの ATS値とが同一になった瞬間に TS_Recording_Rateで、その TS パケットだけを PID Filter 3dに転送する。
[0126] STC Counter3aは、プライマリ TSの PCRによってリセットされ、 STCを出力する。
PID Filter3bは、 MainClip用の多重分離部であり、ソースデバケツタイザ 2bから出力 された Sourceパケットのうち、 PID変換部 24から通知された PID参照値をもつものを、 夫々ビテォデコーダ 4、ォーアイォテコーダ 9、 Interactive Graphicsテコーダ 11、 Pre sentation Graphicsデコーダ 13に出力する。各デコーダは、 PID Filter3bを経由した エレメンタリストリームを受け取って、プライマリ TSの PCR(STC1時間軸)に従いデコー ドから再生の処理を行う。このように PID Filter3bを通過して各デコーダに入力される エレメンタリストリームは、プライマリ TSの PCRに従って、デコード及び再生に供される ことになる。
[0127] STC Counter3cは、セカンダリ TSの PCRによってリセットされ、 STCを出力する。 PID フィルタ 3dは、この STCを参照して、多重分離を行う。
PID Filter3dは、 SubClip用の多重分離部であり、ソースデバケツタイザ 2dから出力 された Sourceパケットのうち、 PID変換部 24から通知された PID参照値をもつものを、 夫々ォーティオアコーダ 9、 Interactive Graphicsテコーダ丄 1、 Presentation Graphics デコーダ 13に出力する。このように PID Filter3dを通過して各デコーダに入力される エレメンタリストリームは、セカンダリ TSの PCRに従って、デコード及び再生に供される ことになる。
[0128] 記録媒体の説明で述べたように、 Playltemにおける In_Time、 Out_Timeは、 SubPlaylt emにおける In_Time、 Out_Timeと一致しているので、 ATC Counter2aと ATC Counter 2cとが同一の値(時刻)を刻めば、プライマリ TSとセカンダリ TSの両方の時間軸が揃う ことになり、 Out- of- MUXアプリケーションを構成するプライマリ TS、セカンダリ TSを 1 本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表す ATC時間 軸と、デコーダ基準時間軸を表す STC時間軸とを同期させることができる。
[0129] ATC時間軸の同期により、上述した 2つの Source De- packetizerは、それぞれ、 BD -ROM力 から読み出された Sourceパケット、ローカルストレージからから読み出され た Sourceパケットを処理することができる。
STC時間軸の同期により、 STC Counter3a,cは、同一の時刻を計時すれば、 2つの TSを 1つの TSとして処理することができる。再生装置におけるデコーダは、 1つの STC 時間軸で動くため、通常のプライマリ TSだけの再生時と変わることなぐ STC時間の管 理を共通化することができる。ビデオデコーダ 4、 IGデコーダ 11、 PGデコーダ 13、シ ステムデコーダ 15c,16c、オーディオデコーダ 9の全てが同一の STC時間軸で動か せることは、再生装置開発の観点力もすると、 BD-ROMの再生のみを行う通常の再 生装置と、制御が一切変わらないため望ましい制限となる。更にォーサリング時にお いては、 1つの TSの入力タイミングを制御して、ノ ッファ状態を観測すればよいので、 ォーサリング時の検証も容易になる。
[0130] ビデオデコーダ 4は、 PID Filter3bから出力された複数 PESパケットを復号して非圧 縮形式のピクチャを得てビデオプレーン 5に書き込むものであり、 Transport Buffer4a 、 Multiplexed Buffer4b、 Elementary Buffer4c、テコータ 4d、 Re-order Buffer4e、スィ ツチ 4 ゝら構成される。
Transport Buffer(TB)4aは、ビデオストリームに帰属する TSパケットが PID Filter3bか ら出力された際、一旦蓄積されるノ ッファである。
[0131] Multiplexed Buffer(MB)4bは、 Transport Buffer4aから Elementary Buffer4cにビデオ ストリームを出力するにあたって、ー且 PESパケットを蓄積しておくためのバッファであ る。
Elementary Buffer(EB)4cは、符号化状態にあるピクチャ (Iピクチャ、 Bピクチャ、 Pピク
チヤ)が格納されるバッファである。
[0132] デコーダ (DEC.)4dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の 復号時刻(DTS)ごとにデコードすることにより複数フレーム画像を得て、ビデオプレ ーン 5に書き込む。
Re-order Buffer4eは、復号されたピクチャの順序を、符号ィ匕順序力 表示順序に 入れ替えるためのバッファである。
[0133] スィッチ 4fは、符号ィ匕順序力 表示順序へと、ピクチャの順序を入れ替えを実現す るスィッチである。
ビデオプレーン 5は、非圧縮形式のピクチャを格納しておくためのプレーンである。 プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ 領域である。ビデオプレーン 5における解像度は 1920 X 1080であり、このビデオプレ ーン 5に格納されたピクチャデータは、 16ビットの YUV値で表現された画素データに より構成される。
[0134] オーディオデコーダ 9は、 Transport Buffer 6, Elementary Buffer 7,デコーダ 8から 構成され、オーディオストリームのデコードを行う。
Transport Buffer6は、 PID Filter3bから出力された TSパケットを、先入れ先だし式に 格納して、オーディオデコーダ 8に供する。
Elementary Buffer7は、 PID Filter3bから出力された TSパケットのうち再生されるべ きオーディオストリームの PIDを有する TSパケットのみを、先入れ先だし式に格納して
、オーディオデコーダ 8に供する。
[0135] デコーダ 8は、 Transport Buffer6に格納された TSパケットを PESパケットに変換して
、この PESパケットに対しデコード処理を行い、非圧縮状態の LPCM状態のオーディ ォデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がな される。
スィッチ 10aは、 BD- ROMから読み出された TSパケット、ローカルストレージ 200から 読み出された TSパケットのどちらかを、選択的にビデオデコーダ 4に供給する。
[0136] スィッチ 10bは、 BD- ROMから読み出された TSパケット、ローカルストレージ 200力 ら読み出された TSパケットのどちらかを、選択的に Interactive Graphicsデコーダ 11に
供給する。
スィッチ 10cは、 BD- ROMから読み出された TSパケット、ローカルストレージから読 み出された TSパケットのどちらかを、選択的に Presentation Graphicsデコーダ 13に供 給する。
[0137] Interactive Graphics(IG)デコーダ 11は、 BD- ROM100又はローカルストレージ 200 力も読み出された IGストリームをデコードして、非圧縮グラフィクスを IGプレーン 12に 書き込むものであり、 Transport Buffer(TB)l la、 Coded Data Buffer(CDB)l lb、 Strea m Graphics Processor(SGP)丄 lc、 Object Bufferl ld、 Composition Buffer丄 le、 Graphi cs Controller(Ctrl)l ll¾ら構成される。
[0138] Transport Buffer(TB)l laは、 IGストリームに帰属する TSパケットがー且蓄積される バッファである。
Coded Data Buffer(CDB)l lbは、 IGストリームを構成する PESパケットが格納される バッファである。
Stream Graphics Processor(SGP)l lcは、グラフィクスデータを格納した PESパケット をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビッ トマップをグラフィクスオブジェクトとして ObjectBufferl ldに書き込む。
[0139] Object Bufferl Idは、 Stream Graphics Processor 1 lcのデコードにより得られたグラ フィクスオブジェクトが配置される。
Composition Bufferl leは、グラフィクスデータ描画のための制御情報が配置される メモリである。
Graphics Controller(Ctrl)l lfは、 Composition Bufferl leに配置された制御情報を 解読して、解読結果に基づく制御をする。
[0140] Interactive Graphics(IG)プレーン 12は、 IGデコーダ 10によるデコードで得られた非 圧縮グラフィクスが書き込まれる。
Presentation Graphics(PG)デコーダ 13は、 BD- ROM又はローカルストレージ 200か ら読み出された PGストリームをデコードして、非圧縮グラフィクスを Presentation Graph icsプレーン 14に書き込む。 PGデコーダ 13は、 Transport Buffer(TB)13a、 Coded Dat a Buffer(CDB)13b、 Stream Graphics Processor(SGP)13cゝ Object Buffer(OB)13d、 C
omposition Buffer(CB)13e、 Graphics Controller(Ctrl)131¾ら構成される。
[0141] Transport Buffer(TB)13aは、 PGストリームに帰属する TSパケットが PIDフィルタ 4か ら出力された際、一旦蓄積されるノ ッファである。
Coded Data Buffer(CDB)13bは、 PGストリームを構成する PESパケットが格納される バッファである。
Stream Graphics Processor(SGP)13cは、グラフィクスデータを格納した PESパケット( ODS)をデコードして、デコードにより得られたインデックスカラー力もなる非圧縮状態 のビットマップをグラフィクスオブジェクトとして ObjectBufferl3dに書き込む。
[0142] Object Buffer(OB)13dは、 Stream Graphics Processorl3cのデコードにより得られた グラフィクスオブジェクトが配置される。
Composition Buffer(CB)13eは、グラフィクスデータ描画のための制御情報 (PCS)が 配置されるメモリである。
Graphics Controller(Ctrl)13fは、 Composition Buffer 13eに配置された PCSを解読し て、解読結果に基づく制御をする。
[0143] Presentation Graphics(PG)プレーン 14は、一画面分の領域をもったメモリであり、一 画面分の非圧縮グラフィクスを格納することができる。
システムデコーダ 15は、セカンダリ TSにおけるシステム制御パケット (PATや PMT)を 処理しデコーダ全体を制御する。
Transport Bufferl5aは、プライマリ TSに存在するシステム制御パケット (PATや PMT) を格納する。
[0144] Elementary Bufferl5bは、システム制御パケットをデコーダ 15cに供する。
デコーダ 15cは、 Elementary Bufferl5bに格納されたシステム制御パケットを、デコ ードする。
Transport Bufferl6aは、セカンダリ TSに存在するシステム制御パケットを格納する。
[0145] Elementary Bufferl6bは、セカンダリ TSにおけるシステム制御パケットをデコーダ 16 cに供する。
デコーダ 16cは、 Elementary Bufferl6bに格納されたシステム制御パケットを、デコ ードする。
メモリ 21は、カレントの PlayList情報やカレントの Clip情報を格納しておくためのメモ リである。カレント PlayList情報とは、 BD- ROMに記録されている複数 PlayList情報のう ち、現在処理対象になっているものをいう。カレント Clip情報とは、 BD- ROM/ロー力 ルストレージに記録されている複数 Clip情報のうち、現在処理対象になっているもの をいう。
[0146] コントローラ 22は、プレイリスト再生 (カレント PlayList情報に従った再生制御のことで ある)を実行することで、 BD-ROMの再生制御を実現する。また上述のような ATS、 ST Cの制御も行なう。この制御にあたってコントローラ 22は、 1秒という時間的範囲にお いて、 BD- ROM、ローカルストレージ内の Sourceパケットを、デコーダ内のバッファに 先読みしておく。このような先読みを行うのは、上述したウィンドウの制限により、アン ダーフロー又はオーバーフローが生じないとの保障があるからである。
[0147] PSRセット 23は、再生装置に内蔵されるレジスタであり、 64個の Player Setting/Statu s Register(PSR)と、 4096個の General Purpose Register (GPR)とからなる。 Player Setti ng/Status Registerの設定値 (PSR)のうち、 PSR4〜PSR8は、現在の再生時点を表現す るのに用いられる。
PID変換部 24は、 PSRセット 23に格納されているオーディオストリーム、オーディオ ストリームのストリーム番号を、 STN_Tableに基づき、 PID参照値に変換して、変換結果 たる PID参照値を PID Filter3b、 PID Filter 3dに指示する。
[0148] ネットワーク部 25は、本再生装置における通信機能を実現するものであり、 URL指 定が与えられれば、その URLにあたる webサイトとの TCPコネクション、 FTPコネクショ ン等を確立する。力かるコネクション確立により webサイトからのダウンロードを実行す る。
操作受付部 26は、リモコンに対してなされた操作をユーザカゝら受け付け、そうした 操作を示す User Operation情報をコントローラ 22に通知する。
[0149] 以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ 22の実 装について説明する。コントローラ 22は、図 31、図 32に示したフローチャートの処理 手順を CPUに実行させるプログラムを作成して命令 ROMに書き込み、 CPUに供する ことで再生装置に実装することができる。
図 31は、 PlayList情報に基づく再生手順のフローチャートである。本フローチャート は、 PlayList情報を構成する. mplsファイルを読み込み (ステップ Sl l)、 PlayList情報に ぉける先頭のPlayItemをカレントPlayItemにした上で(ステップS 12)、このカレント Playl temに対して、ステップ S13〜ステップ S25の処理を繰り返すループ構造になってい る。このループ構造は、ステップ S23を終了条件としたものであり、カレント Playltemの In_Timeに対応する Access Unitから、カレント Playltemの Out_Timeに対応する Access Unitまでを読み出しを BD- ROMドライブに命じ (ステップ SI 3)、カレント Playltemに pre viousPlayltemが存在するか否かを判定して (ステップ S 14)、判定結果に応じて、ステ ップ S 15の処理、ステップ S 16〜ステップ S 21の処理を選択的に実行する。具体的 には、カレント Playltemに previousPlayltemがなければ (ステップ S14で No)、 PlayltemJ n_Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S 15)。
[0150] カレント Playltemに previousPlayltemがあれば (ステップ S 14で Yes)、カレント Playltem 力 SCC = 5であるか否かを判定し (ステップ S I 6)、 CC = 5であるなら (ステップ SI 6で Yes )、ステップ SI 7〜ステップ S20の処理を行う。
上述した previousPlayltemが存在する場合、プライマリ TSにおける ATC_Sequenceが 切り替わることになる。この切替において、 ATC_deltalと呼ばれるプライマリ TSのため のオフセット値を算出し (ステップ S 17)、それまでの ATC_Sequenceにおける ATC値 (A TC1)に、 ATC_deltalをカ卩算することにより、新しい ATC_Sequenceの ATC値 (ATC2)を 得る (ステップ S 18)。
[0151] また、上述した、 previousPlayltemが存在する場合、プライマリ TSにおける STC_Sequ enceが切り替わることになる。この切り替えにおいて、 STC_deltalと呼ばれるオフセット 値を求めて (ステップ S 19)、それまでの STC_Sequenceにおける STC値 (STC1)に、 STC _deltalを加算することにより (ステップ S20)、新し!/ヽ STC_Sequenceの STC値 (STC2)を 求める。
そして Audio Overrapのミュートをオーディオデコーダ 9に指示した上で、 Playltem Jn _Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S21)。カレント Playltem力 SCC = 5でないなら、 CC=1、 CC=6の処理を行う。
[0152] ステップ S15、ステップ S16〜ステップ S21のどちらかの処理を実行すればステップ
S25の処理を実行する。ステップ S25は、カレント Playltemと同期再生すべき SubPlayl temが存在するかどうかをサーチする処理である。ここで SubPath情報を構成する各 Su bPlayltemは、 Sync_PlayItem_Idという情報を有しており、カレント Playltemと同期再生 すべき SubPlayltemは、この Sync_PlayItem_Idが、カレント Playltemに設定されている。 そこでステップ S25では、カレント Playltemを Sync_PlayItem_Idに指定した SubPlayltem 力 SubPath情報を構成する複数の SubPlayltemの中に存在するかどうかをサーチす る。
[0153] もし存在しない場合、ステップ S22に移行する。ステップ S22は、 AVClip時間軸に おける現在の再生時点 (カレント PTM(Presentation TiMe》がカレント Playltemの Out_T imeに到達した力どうかを判定する (ステップ S22)。到達すれば、ステップ S23に移行 する。ステップ S23は、カレント Playltemが PlayList情報における最後の Playltemにな つたか否かの判定であり、最後の Playltemでなければ、 PlayList情報における次の Pla yltemを、カレント Playltemにして (ステップ S24)、ステップ S I 3に移行する。以上の処 理により、 PlayList情報における全ての Playltemに対して、ステップ S 13〜ステップ S2 4の処理が施されることになる。
[0154] 図 32は、 SubPlayltemにおけるシームレス接続を示すフローチャートである。
ステップ S25においてカレント Playltemを Sync_PlayItem_Idに指定した SubPlayltemが 存在すると判定された場合、その SubPlayltemをカレント SubPlayltemに設定して (ステ ップ S31)、 SubPlayltemの In_Timeに相当する Access Unitから、 Out_Timeに相当する Access Unitまでの読み出しをローカルストレージ 200に命じる (ステップ S32)。そして カレント Playltemに Previous SubPlayltemが存在するか否かを判定して (ステップ S33) 、判定結果に応じて、ステップ S34、ステップ S35の処理、ステップ S36〜ステップ S4 1の処理を選択的に実行する。具体的には、カレント Playltemに Previous SubPlayltem がなければ (ステップ S33で No)、カレント PTMが、 Sync_Start_Pts_of_PlayItemに到達 するのを待ち (ステップ S34)、到達すれば、 SubPlayItem_In_Timeから SubPlayItem_Out _Timeまでの再生をデコーダに命じる (ステップ S35)。
[0155] カレント Playltemに Previous SubPlayltemがあれば (ステップ S33で Yes)、カレント Pla yltem力 P_CC=5であるか否かを判定し (ステップ S36)、 SP_CC=5であるなら (ステップ
S36で Yes)、ステップ S37〜ステップ S41の処理を行う。
上述した、 previousPlayltemが存在する場合、 ATC_Sequenceが切り替わることにな る。この切替において、 ATC_delta2と呼ばれるセカンダリ TSのためのオフセット値を算 出し (ステップ S37)、それまでの ATC_Sequenceにおける ATC値 (ATC1)に、 ATC_delta 2をカ卩算することにより、新し!/、ATC_Sequenceの ATC値 (ATC2)を得る (ステップ S38)。
[0156] ATC_deltaとは、これまで読み出されているトランスポートストリーム (TS1)の最後の TS パケットの入力時点 T1から、新たに読み出されたトランスポートストリーム (TS2)の最初 の TSパケットの入力時点 T2までのオフセット値を 、、 "ATC.delta≥ Nl/TS_recordin g_rate"という計算式で与えられる。ここで N1は、 TS1の最後のビデオ PESパケットに後 続する、 TSパケットのパケット数である。
[0157] また、上述した、 previousPlayltemが存在する場合、 STC_Sequenceも切り替わること になる。この切り替えにおいて、 STC_delta2を求めて (ステップ S39)、それまでの STC_ Sequenceにおける STC値 (STC1)に、 STC_delta2をカ卩算することにより (ステップ S40)、 新しい STC_Sequenceの STC値 (STC2)を求める。
先行 STC_Sequenceにおいて最後に再生されるピクチャの表示開始時刻を PTSKlst END),ピクチャの表示期間を Tppとし、後続 STC_Sequenceにおいて最初に表示され るピクチャの開始時刻を PTS2(2ndSTART)とした場合、 CC = 5では、 PTSl(lstEND) + Tppの時刻と、 PTS2(2ndSTART)の時刻とを一致させる必要があるから、 STC_delta2は
STC_delta2 = PTS l(lstEND) + Tpp - PTS2(2ndSTART)
との計算式力 算出される。
そして Audio Overrapのミュートをオーディオデコーダ 9に指示した上で、 Playltemjn _Timeから PlayItem_Out_Timeまでの再生をデコーダに命じる (ステップ S41)。
[0158] コントローラ 22は、上述したように、 STCの変更処理を行うが、再生装置の一般的な 実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。 フリーラン状態とは、デコーダが STCとの同期制御を行っていない状態をいう。その後 、 STC時間軸が設定できる状態まで、 STCが復帰すれば、デコーダは、フリーラン状 態から、 STCとの同期制御へと移行する。一方、ステップ S36においてカレント Playlte
m力 SCC = 5でないと判定されたなら (ステップ S36で No)、 CC=1、 CC=6の処理を行う。
[0159] 以上のように本実施形態によれば、 Windowと呼ばれる 1秒当たりの転送許容量は、 48Mbit以下に制限されているので、この 1秒という期間において、転送許容量が局所 的に 96Mbitまであがったとしても、 96Mbit X 0.5秒のサイズの TSパケットを、デコーダ に先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローす ることはない。デジタルストリームにおけるどの期間であっても、データ量は「96Mbit X 0.5秒」以下であり、アンダーフロー又はオーバーフローが生じることなぐ TSパケット を供給することができるので、ビデオ又はオーディオの欠落を避けることができる。こ れにより Out-of-MUXフレームワーク実現のための同時読み出し力 品質上の問題 に波及する恐れはなくなる。
[0160] また、 Playltemにおける In_Time、 Out_Timeと、 SubPlayltemにおける In_Time、 Out_Ti meとが一致していて、 Playltem側の接続状態が CC = 5であるなら、 SubPlayltem側の 接続状態も SP_CC=5になるので、 Playltemが切り替えられたとしても、多重分離部を 再設定することなぐ Playltemから Playltemへの切り替えと、 SubPlayltemから SubPlaylt emへの切り替えとを同時に実行することができる。多重分離部が参照する STC時間 軸を同期させつつ、 PlayList情報に基づく再生処理を進行させてゆくことができる。
[0161] (第 2実施形態)
本実施形態では、先の実施形態で述べた、 BD-ROMの製作について、詳しく説明 する。先の実施形態に係る BD-ROMは、以下の工程を順次実行することにより、作る ことができる。 く BD- ROMの記録工程 >
先ず初めに、 BD-ROMをどのような筋書きで再生させるかを決めるかを企画して (企 画工程)、動画収録、音声収録等の素材作成を行い (素材作成工程)、企画工程にお V、て作成された筋書きから、ボリューム構成情報を作成する (シナリオ作成工程)。
[0162] ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを 示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをェン コードすることにより、エレメンタリストリームを得る (素材エンコード工程)。その後、複 数のエレメンタリストリームの多重化を行う (多重化工程)。
[0163] こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、 B D- ROMの応用層フォーマットに適合させる作業を行 、、 BD- ROMのボリューム領域 に記録すべきデータの全体像 (一般にボリュームデータという)を得る (フォーマッティ ング工程)。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述さ れたクラス構造体のインスタンスであり、 BD- ROM規格に規定された構文に基づ!/、て 、クラス構造体のインスタンスを記述することで、 Clip情報, PlayList情報等を作成する ことができる。この場合、テーブル形式のデータは、プログラミング言語の for文を用い て定義することができ、その他、特定の条件下のみ、必要になるようなデータは、 ifX を用いて定義することができる。
[0164] こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生し てみてシナリオ作成工程の結果が正しいか否かの確認を行う (エミユレーシヨン工程) 。このエミユレーシヨン工程では、 BD- ROMプレーヤモデルのバッファ状態のシミュレ ートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列 に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作 成する。さらにプレス装置によって作成された原盤から、 BD-ROMを製造する。この 製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの 印刷と 、つた諸工程力 なる。
[0165] 以上の工程を経て、各実施形態に示した記録媒体 (BD-ROM)を作ることができる。
<追加コンテンツの作成工程〉
映画作品を、 BD-ROMコンテンツと、追加コンテンツとで構成する場合は、上述した 企画工程力もフォーマッティング工程までを実行する。そうして、 1つのボリュームデー タを構成する AVClip、 Clip情報、 PlayList情報が得られれば、これらのうち、既に BD- ROMにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバ プログラム等で 1つのファイルにまとめる。こうした処理を経て、追加コンテンツが得ら れれば、力かる追加コンテンツを WWWサーバーに供し、再生装置からの要求に応じ て、再生装置に送出する。
[0166] 先の実施形態で述べたベリファイは、 AVClip、 Clip情報、 PlayList情報が完成し、 P1 ayList情報内の STN_tableにより、再生すべきエレメンタリストリームが確定した段階、 つまり、フォーマッティング工程で実行される。以降、力かるアプリケーションフォーマ ットを作成するォーサリングシステムについて説明する。
<ォーサリングシステム >
図 33は、第 2実施形態に力かるォーサリングシステムの内部構成を示す図である。 本図に示すようにォーサリングシステムは、入力装置 51、エンコード装置 52、サーバ 装置 53、素材ストレージ 54、 BD構成情報ストレージ 55、クライアント装置 56〜58、 マルチプレクサ 60、 BDシナリオコンバータ 61、フォーマッタ 62、 Verifier63から構成 される。
[0167] 入力装置 51は、 HD画像、 SD画像が収められたビデオカセットを装填し、このビデ ォカセットを再生して再生信号をエンコード装置 52に出力する。
エンコード装置 52は、入力装置 51から出力された再生信号をエンコードして、ビデ ォストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得ら れたエレメンタリストリームは、 LANを通じてサーバ装置 53に出力され、サーバ装置 5 3内の素材ストレージ 54に書き込まれる。
[0168] サーバ装置 53は、素材ストレージ 54、 BD構成情報ストレージ 55という 2つのドライ ブ装置からなる。
素材ストレージ 54は、サーバ装置 53の内蔵ディスク装置であり、エンコード装置 52 のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ 54 は、 HDstreamディレクトリ、 SDstreamディレクトリといった 2つのディレクトリをもち、 HD 画像をエンコードすることにより得られたエレメンタリストリームは HDstreamディレクトリ に書き込まれる。
[0169] BD構成情報ストレージ 55は、 BDボリューム構成情報が格納されるドライブ装置で ある。
マルチプレクサ 60は、素材ストレージ 54内の HDstreamディレクトリ、 SDstreamディレ クトリに格納されているエレメンタリストリームのうち、 BDボリューム構成情報により指定 されて 、るものを読み出し、これを BDボリューム構成情報に従 、多重化することで、
多重化ストリームである AVClipを得る。
[0170] BDシナリオコンバータ 61は、 BD構成情報ストレージ 55に格納されている BDボリュ ーム構成情報を BD-ROMアプリケーションフォーマットに変換することにより BDシナリ ォを得る。
フォーマッタ 62は、マルチプレクサ 60によりえられた Clip、 BDシナリオコンバータ 61 により得られた BDシナリオを、 BD- ROMの応用層フォーマットに適応させる。こうして 適応されら BDシナリオから、 BD- ROMの原盤や、ローカルストレージに格納されるべ きダウンロード用コンテンツが得られる。
[0171] ベリファイ部 63は、シナリオコンバータ 61が生成した PlayList情報内の STN_tableを 参照して、マルチプレクサ 60が得た BD- ROM用のプライマリ TS、ローカルストレージ 用のセカンダリ TSが、 Out_of_MUXアプリケーションを実現するため制限を満たすかど うかを判定する。
以上が、ォーサリングシステムの内部構成である。以降、ォーサリングシステムおけ るべリファイ部 63の実装について説明する。
[0172] くべリファイ部 63実装のための処理手順 >
ベリファイ部 63は、図 34、図 35に示したフローチャートの処理手順を CPUに実行さ せるプログラムを作成して命令 ROMに書き込み、 CPUに供することでォーサリングシ ステム内に実装することができる。
図 34は、プライマリ TS、セカンダリ TSに対するべリファイ手順を示すフローチャート である。本フローチャートは、ステップ S1において、 Sourceパケット列における最初の Sourceパケットの ATSを、カレント Windowの In_Timeに設定した上で、ステップ S2〜ス テツプ S7の処理を繰り返すループ構造を有している。このループ構造は、カレント Wi ndowの In_Timeから 1秒以降に存在する ATSを、カレント Windowの Out_Timeに設定し て (ステップ S2)、カレント Windowの In_Timeから Out_Timeまでに存在する TSパケット数 をカウントし (ステップ S3)、 In_Timeからカレント Windowにおけるビット数を算出して (ス テツプ S4)、そのビット値が 48Mbit以下であるかを判定する処理 (ステップ S5)を、ステ ップ S6力 Wesと判定されるまで繰り返すものである。このステップ S6は、カレント Windo wの Out_Timeが、 ATC時間軸における最後の Sourceパケットに到達したかどうかの判
定であり、もしステップ S6が Noであるなら、 Sourceパケット列における次の ATSを、力 レント Windowの In_Timeにして (ステップ S7)、ステップ S2〜ステップ S6の処理を繰り 返す。どれかの Windowで、ステップ S5が Noと判定されたなら、 BD- ROM規格に違反 していると判定される (ステップ S9)。全ての Windowでステップ S5が Yesと判定され、ス テツプ S6が Yesと判定されたなら、 BD-ROM規格に適合して 、ると判定される (ステツ プ S8)。
[0173] プライマリ TS、セカンダリ TSは、以上のベリファイを経ているので、プライマリ TS、セ カンダリ TSがそれぞれ BD-ROM、ローカルストレージカも供給される場合でも、上述 したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、 PGストリーム、 IGストリームのそれぞれに、 同種のエレメンタリストリームが複数存在する場合、図 35の手順で、ベリファイを行う のが望ましい。図 35に示すベリファイ手順は、図 34におけるステップ S3〜ステップ S 4を、ステップ S81〜ステップ S83に置き換えたものである。
[0174] このステップ S81〜ステップ S83は、カレント Windowが 1つ決定される度に、 STN_ta bleにお!/、て、再生が許可されて!、るエレメンタリストリームを構成する TSパケットのう ち、カレント Windowに属するもののビットレートを、エレメンタリストリーム毎に算出して (ステップ S81)、複数のビデオストリーム、複数のオーディオストリーム、複数の PGスト リーム、複数の IGストリームのうち、算出されたビットレートが最も高いものを選び (ステ ップ S82)、ビデオストリームのビットレートの最大値、オーディオストリームのビットレー トの最大値、 PGストリームのビットレートの最大値、 IGストリームのビットレートの最大値 を合計して (ステップ S83)、その合計量が 48Mbit以下であるかを判定する (ステップ S 5)ものである。
[0175] 同種のエレメンタリストリームは、 Out_of_MUXアプリケーションでは、必ず排他的に 選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所 におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下 の通りである。
[0176] (l)Windowの In_Timeが指し示す TSパケットの先頭
(2) Windowの In_Timeが指し示す TSパケットの終了
(3) Windowの Out_Timeが指し示す TSパケットの先頭
(4) Windowの Out_Timeが指し示す TSパケットの終了 力かる箇所におけるビット量を重点的にチェックすることで、ォーサリングでのベリフ アイ作業を、より簡略化することができる。
[0177] 以上のように本実施形態によれば、セカンダリ TSの再生を許可した STN_tableを作 成した際、その STN_tableに基づく再生処理で、アンダーフロー又はオーバーフロー が生じるかどうかを、ォーサリングの段階で、あら力じめ検証しておくことができる。
(第 3実施形態)
本実施形態は、 Playltem間、 SubPlayltem間の接続に、 CC=6という新たな類型を設 ける実施形態である。
[0178] CC=6とは、 Progressive PlayList情報を構成する複数の Playltem情報間の接続状態 を規定する。 Progressive PlayList情報とは、ストリーミングを前提にして再生されるべ き複数の AVClipを、 1つの再生経路として指定してゆくためのプレイリスト情報である
、 Progressive PlayList情報
Progressive PlayList情報は、ダウンロード/ストリーミングするセカンダリ TSを細切れ のファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウン ロードを待たずに、再生を開始することができる利便がある。
[0179] ストリーミングを前提にしたコンテンツは、短い長さの多くの AVClipにて規定されて いるので、 Progressive PlayList情報は、これら複数 AVClipのそれぞれに対応する、 多くの Playltem情報力も構成される。一方、細かい単位に分割された AVClipは、ストリ 一ミングのために分割されたのであって、 STC、 ATCに不連続点が存在している訳で はない。そのため、 CC = 5ではない別の状態として、力かる AVClip間の接続状態を 規定しておく必要がある。こうして規定された接続状態を、 CC=6という。
< CC=6にお!/、て満たすべき条件 >
CC=6である場合、 2つの Playltemから指定される TS1、 TS2と、 2つの SubPlayltemか
ら指定される TS1、 TS2とは、以下の条件を満たす必要がある。
[0180] 1)TS2におけるビデオストリームは、 GOPから始まらなければならない。
2)TS2のオーディオストリームと同じ PIDをもつ TS1のオーディオストリームとにおいて 、接続点における Audio Presentation Unit列に、ギャップが存在しない。
TS1のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そ して、 TS2における同じ PIDをもつオーディオストリームは、不完全な Audio Presentatio n Unitから始まってもよい。複数の Playltem、複数の SubPlayltemに基づき、これらの T Sl、 TS2を再生させてゆけば、 2つの Audio Presentation Unit力ら、 1つの完結した Aud 10 Presentation Unit力 Sネ守られる。
[0181] CC=6では実際にはストリームが連続しているため、 CC=5の時のようなビデオだけ がシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするような ことはなぐ全てのエレメンタリストリームがシームレスに接続される。 以上のように CC=6は、論理的に連続しているストリームを、ストリーミングの都合から 、複数の部分に分割した場合の分割境界を意味する。ただし、 BD-ROMに記録され るべきストリームは 32個の Sourceパケットから構成される必要があるので、 1つの SubPl ayltemを構成する 1つのストリームファイルは、全て、 6KByteの倍数になっている必要 がある。
[0182] < CC=6の詳細 >
図 36は、 CC=6の詳細な説明を示す図である。第 1段目は、 1本の連続した ATC/ST C時間を有し、符号化方式も連続して!/、るストリームを格納したファイル (20000.m2ts) を示す。第 2段目は、 3つのストリームを格納した格納した 3つのファイル (20001.m2ts,2 0002.m2t,20003.m2ts)を示す。これらの 3つのファイルは、第 1段目における 1本のスト リームを、ァラインドユニット(6KByte)単位で区切ることで得られた、 3つのプライマリ T Sを格納している。
[0183] 図 37は、 Playltemと SubPlayltemの相関を示した図である。第 1段目は、 PlayList情 報における 3つの PlayItem(PlayItem情報 #1、 Playltem情報 #2、 Playltem情報 #3)を示 す。これら 3つの Playltemはプライマリ TSを指定しており、 Playltem情報 #1、 Playltem情
報 #2間は CC = 1に設定され、 Playltem情報 #2、 Playltem情報 #3間は、 CC = 5に設定 されている。第 2段目は、 PlayList情報における 3つの SubPlayItem(SubPlayItem#l、 Su bPlayItem#2、 SubPlayItem#3)を示す。これら 3つの SubPlayltemはセカンダリ TSを指定 しており、 SubPlayItem#l、 SubPlayItem#2間は CC = 1に設定され、 SubPlayItem#2、 Su bPlayItem#3間は、 CC = 5に設定されている。第 3段目は、 Progressive PlayList情報 における 9つの SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubPlayItem#3〜SubPla yltem#9)を示す。これら 9つの SubPlayltemはセカンダリ TSを指定しており、 SubPlaylte m#3、 SubPlayItem#4間は CC=1に設定され、 SubPlayItem#6、 SubPlayItem#7間は、 CC =5に設定され、それ以外は、 CC=6に設定されている。 Progressive PlayListの SubPl ayltemは、 CC=6で接続される力 Playltemが CC=1、 CC=5で接続されるタイミングで は、 Playltemと同様に CC=1、 CC=5の条件を満たしながら接続される。
[0184] 以上のように本実施形態によれば、 Playltem, SubPlayltemにおける接続状態に、 C C=6という新たな類型を導入することで、 Progressive PlayList情報を構成する AVClip を短く区切って、ストリームングで供給するという処理を実現することができる。
(第 4実施形態)
第 1実施形態では、各 Windowにおけるビット量を、どのように制限するかについて 説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えば よいかを提案する。
[0185] <ビデオ +オーディオの多重化 >
図 38は、プライマリ TSを構成するオーディオ力 セカンダリ TSを構成するオーディ ォに入れ替えられる場合、プライマリ TSを構成する複数の TSパケットと、セカンダリ TS を構成する複数の TSパケットとが、どのように多重化されるかを模式的に示す図であ る。
図 38は、 ATC時間軸に存在する複数の TSパケットが、どのように多重化されるかを 模式的に示す図である。第 1段目は、プライマリ TSを示す。プライマリ TSは V、 Al、 A2 (ビデオ 1本、オーディオ 2本)を格納した TSパケットである。これらの TSパケットは、 2 種類 3本のエレメンタリストリームを多重化して得たものである。
[0186] 第 2段目は、セカンダリ TSを示す。セカンダリ TSは、 1種類 2本のオーディオ A3、 A4
を格納した TSパケットからなる。これらセカンダリ TSの TSパケットが多重化される時間 帯 p3は、デコーダへの入力時間軸を示す ATC時間軸上で、プライマリ TSのオーディ ォパケットが多重化された時間帯 piと、プライマリ TSを構成する TSパケットが転送され てない時間帯 p2とからなる。
[0187] このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されても デコードすべきエレメンタリストリームのビットレートの和がプライマリ TSの許容最大ビ ットレート(48Mbps)を超えない保証ができる。図 38の上述した一例は、一番簡単な 例で、セカンダリ TSにオーディオしかな 、場合である。
<ビデオ +オーディオ + PGストリーム + IGストリームの多重化 >
図 39は、オーディオにカ卩えて、字幕 (PGストリーム)やメニュー(IGストリーム)も入れ 替えられる場合、プライマリ TSを構成する複数の TSパケットと、セカンダリ TSを構成す る複数の TSパケットとが、どのように多重化されるかを模式的に示す図である。
[0188] 本図において、セカンダリ TSのパケットの転送が許可される時間帯 k3は、
1)プライマリ TSにおける同種のパケットの転送時間帯 kl
2)プライマリ TSの無転送時間帯 k2
の和である。
セカンダリ TSに格納されている他ストリーム種別(Video、 IG、 PG等)についても上記 1)、 2)のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類の ストリームの転送時間帯でセカンダリ TS内に多重化が可能力判断され、これで不足 する場合には、 2)のプライマリ TSの無転送時間帯を利用して多重化されることが効 率的である。
[0189] <マルチプレクサ 60の処理 >
本実施形態に力かるマルチプレクサ 60の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ 60は、デコーダモデル において、プライマリ TSを再生する際のノッファ状態をシミュレートし、プライマリ TSに おける各パケットの転送時間帯や、プライマリ TSの無転送時間帯を検出する。これら の時間帯を検出すれば、セカンダリ TSを構成する各 PESパケットが、同種のパケットの 転送時間帯や、無転送時間帯に転送されるよう、セカンダリ TSを構成する各 PESパケ
ットを TSパケットに変換して、各 TSパケットに、力かる ATSを付す。こうして付された AT Sは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリ TSを構 成する各 PESパケットは、図 39に示したように、プライマリ TSにおける同種のパケット の転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。
[0190] く DVDによる供給 >
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム 形式ではなぐプログラムストリーム形式にする場合、マルチプレクサ 60は、エレメン タリストリームを構成する PESパケットを、パックに変換して、各パックの TSヘッダに SC R(System Clock Reference)を付す。こうして付された SCRも、 ATS同様、同種のバケツ トの転送時間帯や、無転送時間帯を示すので、セカンダリ PS (ローカルストレージから 供給されるプログラムストリーム)を構成する各 PESパケットは、図 39に示したように、プ ライマリ PS(BD- ROMから供給されるプログラムストリーム)における同種のパケットの転 送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレー ジ力 供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種 のパケットの転送時間帯や、無転送時間帯を、パック(PESパケット)という大きな時間 単位で表現するので、ォーサリング時における負担は格段に小さぐ実現が容易とな る。これは、 DVD再生装置において、 Out_of_MUXアプリケーションを実現するにあた つての、禾 IJ点となる。
[0191] 以上のように本実施形態によれば、プライマリ TSにおける同種のパケットの転送期 間、プライマリ TSにおける無転送期間を、セカンダリ TSを構成するパケットの入力期 間に選び多重化を行うので、第 1実施形態に示したビット量制限を満たしやすくなる。 力かる多重化を第 2実施形態に示したォーサリングシステム上で実現することにより、 Out_of_MUXアプリケーションを実現するような映画作品を製作しやすくなる。これによ り、再生時のオーバフローが生じないような保障をォーサリングの段階で、容易に行う ことができる。
(第 5実施形態)
本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本ァ プリケーシヨンは、 1つの種別につき、 1つのエレメンタリストリームという Out_of_MUXの
規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシ ングアプリケーションはプライマリ TSにあたるオーディオストリームと、セカンダリ TSに あたるオーディオストリームとを同時に選択し、プライマリ TSの音声とセカンダリ TSの 音声の 2つの音声を同時にデコードする点が例外となる。
[0192] 図 40は、オーディオミキシングアプリケーションを構成するプライマリ TS、セカンダリ TSが、 BD-ROM再生装置の内部構成において、デコーダにどのように供給されるか を示す図である。本図では、 BD-ROM再生装置の内部構成のうち、 BD-ROMドライブ la、ローカルストレージ 200、ネットワーク部 25を左側に示し、各デコーダを右側に示 す。真ん中に、ストリームの多重分離を行う PID Filterを示す。そして本図におけるプ ライマリ TS(Video 1 'Audio 1 (English) ,Audio2(Spanish) , PG 1 (English Subtitle) ,IG1 (Englis h Menu))ゝセカンダリ TS(Audio3(Commentary),PG2(Japanese Subtitle),PG3(Korean S ubtitle),PG4(Chinese Subtitle),IG2(English Menu))は、それぞれ BD- ROM、ローカル ストレージカゝら供給されるトランスポートストリームを示す。ディスク単体には英語 (Audi 0 1)とスペイン語 (Audio 2)しか記録されていないため、映画監督のコメンタリ音声は 、このディスク力も選択することはできない。し力しながら、コンテンツプロバイダが提 供する Audio 3(Commnetary)の入ったセカンダリ TSを、ローカノレストレージにダウン口 ードすれば、英語音声(Audio 1)と、 Audio 3(Commentry)とを、デコーダに送り込む ことができる。これらの英語音声(Audio 1)と、 Audio 3(Commentry)とを、デコーダがミ キシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像 (Videol) と共に再生させることができる。
[0193] Out-of-MUXアプリケーションとの相違は 2つのオーディオストリームを同時にデコ ードする点のみである。如何なるプライマリ TSに対しても、ディスク発売後に監督のコ メンタリ音声を付加するなどといったことが想定されるため、プライマリ TSへのビットレ ート制限などは好ましくなぐ Out-of-MUXと同様にセカンダリ TSへの制限を導入する 。オーディオミキシングでは、各エレメンタリストリーム(ビデオ、オーディオ、字幕、メ- ユー)に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソ ースを 2つ必須とする。
[0194] くプライマリ、セカンダリオーディオストリームの構成〉
オーディオミキシングアプリケーションを実現するにあたって、プライマリ TSにおける 属することになるオーディオストリームを、プライマリオーディオストリームといい、セカ ンダリ TSに属することになるオーディオストリームをセカンダリオーディオストリームとい う。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて 説明する。
[0195] プライマリオーディオストリームは、 32本存在し、それらは 0x1100から 0x111Fまでの P IDをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリー ム同様、 32本存在し、 OxlAOOから OxlAlFまでの PIDをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカ ンダリオーディオストリームのオーディオフレームに、 "ダウンミキシング情報,,と、 "ゲイ ン制御情報"と力もなるメタデータを含む点である。
[0196] "ダウンミキシング情報,,は、ダウンミキシングのための情報である。ダウンミキシング とは、音声の再生チャネル数を符号ィ匕チャンネル数よりも少なくする変換であり、ダウ ンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、 このダウンミキシングを再生装置に行わせる。 5.1chの音声ストリームを 2chで再生する ことなどがダウンミキシングの一例である。
[0197] "ゲイン制御情報"とは、プライマリオーディオストリーム側の音声出力時のゲインを 上げ下げする情報である力 ここでは下げるだけでよい。このようにセカンダリオーデ ィォストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出 力をリアルタイムに下げることができる。 Primaryオーディオと Secondaryオーディオを 重畳する場合には、あらかじめミキシングされる Primaryオーディオと Secondaryォー ディォの対が分かっているため、 2本のオーディオのゲインをリアルタイムに制御する 必要は無く、 Primaryオーディオのゲインだけを下げて Secondaryオーディオのゲイン はそのままにミキシング (重畳)することで十分である。力かるメタデータを配置すること で、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリ ームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避ける ことができる。以上が、本実施形態におけるオーディオストリームについての説明であ る。続いて、本実施形態における PlayList情報における改良について説明する。
[0198] くオーディオミキシングアプリケーションを実現するための STN_table> 同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、 本実施形態における PlayList情報には、再生が許可されて!、る複数プライマリオーデ ィォストリーム、複数セカンダリオーディオストリームの組合せが、各 Playltemの STN_ta bleに示されている。
[0199] 以降、本実施形態における STN_tableにつ 、て説明する。オーディオミキシングアブ リケーシヨンを実現するため、 STN_tableには、セカンダリオーディオストリームにおけ る Stream_entryと、 Stream_attributeとの組み力 プライマリオーディオストリームにおけ る Stream_entryと、 Stream_attributeとの組みとは別に存在する。そして、セカンダリオ 一ディォストリームにおける Stream_entryと、 Stream_attributeとの糸且みが、 Comb_info_S econdary— audio— Primary— audioと対 J心 1、丄けりれて V、る。
[0200] (Comb— info— secondary— audio— Primary— audio)
Comb_info_Secondary_audio_Primary_audioは、そのセカンダリオ一ディォストリームの 再生出力をミキシングすることができる 1つ以上のプライマリオーディオストリームを一 意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリ ームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ 以外の属性を有して 、るようなプライマリオーディオストリームの再生時にぉ 、てのみ 、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミ キシングの可否を、ォーサリング時に設定しておくことができる。
[0201] (sp— connection— condition†青 R j
ま 7こ PlayList†青報【こお 、て、 Sub Playltemの sp— connection— condition†青報 ί¾、 Playlte m情報の connection_condition情報と同じ値に設定される。よって Playltem情報の conn ection— condition†青報力 21 =o C、&)るなら、 SubPlayltem†青報の sp— connection— condition 情報も SP_CC=5に設定される。また SubPlayltem情報の In_Time、 Out_Timeは、 Playlte m情報の In_Time、 Out_Timeと同じ時点を指し示す。
[0202] 以上が本実施形態における記録媒体の改良である。続いて本実施形態に係る再 生装置の内部構成にっ 、て説明する。
<再生装置の内部構成 >
図 41は、第 5実施形態に係る再生装置の内部構成を示す図である。本図に示すよ うに、 TB6、 EB7、オーディオデコーダ 8は、 Audio Mixing Processor (点線で囲まれ た部分)に置き換えられている。この Audio Mixing Processorは、プライマリ TSとセカ ンダリ TSから 2本の音声ストリームを入力し、同時にデコードしてミキシングするもので ある。その他の構成は Out- of-MUXアプリケーションを実現するための内部構成と同 様である。以降、 Audio Mixing Processorについて詈兄明する。 Audio Mixing Proces sorは、 Transport Buffer6a、 6b、 EB7a、 7b、プリロードバッファ 7c、オーディオデコー ダ 8a、 8b、ミキサ 9a、 9bから構成される。
[0203] Transport Buffer6aは、 PID Filter3bから出力された、オーディオストリームの PIDを 有する TSパケットを、先入れ先だし式に格納して、オーディオデコーダ 8aに供する。
Transport Buffer6bは、 PID Filter3dから出力された、オーディオストリームの PIDを 有する TSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ 8bに供す る。
[0204] EB7aは、バッファ 6aに格納された TSパケットを変換することで得られる、 PESパケット を格納するバッファである。
EB7bは、バッファ 6aに格納された TSパケットを変換することで得られる、 PESバケツ トを格納するバッファである。
プリロードバッファ 7cは、 BD- ROM/ローカルストレージから読み出されたファイル so und.bdmvをプリロードしておくためのメモリである。ファイル sound.bdmvとは、メニュー に対する操作に出力すべきオーディオデータを格納したファイルである。
[0205] オーディオデコーダ 8aは、プライマリ TSを構成する PESパケットに対しデコード処理 を行い、非圧縮状態の LPCM状態のオーディオデータを得て出力する。これによりォ 一ディォストリームにおけるデジタル出力がなされる。
オーディオデコーダ 8bは、セカンダリ TSを構成する PESパケットに対しデコード処理 を行い、非圧縮状態の LPCM状態のオーディオデータを得て出力する。これによりォ 一ディォストリームにおけるデジタル出力がなされる。
[0206] ミキサ 9aは、オーディオデコーダ 8aから出力される LPCM状態のデジタルオーディ ォと、オーディオデコーダ 8bから出力される LPCM状態のデジタルオーディオとをミキ
シングする。
ミキサ 9bは、ミキサ 9aから出力される LPCM状態のデジタルオーディオと、ノ ッファ 7 cに格納されて 、るサウンドデータとをミキシングする。このサウンドミキサ 9bによるミキ シングは、クリック音の発音を意図したようなナビゲーシヨンコマンドを、コントローラ 22 が解読することでなされる。
[0207] 以上が、本実施形態に力かる再生装置についての説明である。
<オーディオミキシングアプリケーションに対するべリファイ >
上述したように、オーディオミキシングアプリケーションはプライマリオーディオストリ ーム、セカンダリオーディオストリーム力も構成されるので、第 2実施形態に示したよう なべリファイは、プライマリオーディオストリーム、セカンダリオーディオストリームが同 時に読み出された場合を想定して実行される。具体的にいうと、 MainClip, SubClipが 基準としている ATC時間軸において、 1ずつ Windowを、シフトさせてゆく。このシフト の手順は、図 35のフローチャートに示したものと同じである。そして ATSに示される A TC時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリー ム、複数のセカンダリオーディオストリーム、複数の PGストリーム、複数の IGストリーム のうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレート の最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーデ ィォストリームのビットレートの最大値、 PGストリームのビットレートの最大値、 IGストリ ームのビットレートの最大値を合計して、その合計量が 48Mbit以下であるかを判定す る。 48Mbitを越えていれば、 BD-ROM規格に違反していると判定結果を下す。
[0208] 以上のように本実施形態によれば、 BD- ROM、ローカルストレージの双方からプライ マリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマ リオ一ディォストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに 供給する場合でも、 1秒当たりのビット量が、所定の上限を越えないという保障を施す ことができる。力かる保障を与えるので、オーディオミキシングアプリケーションを、効 率的に作成することができる。そのため、オーディオミキシングアプリケーションを実 現するような追力 tlコンテンツを、ローカルストレージにダウンロードして、ローカルストレ 一ジカもデコーダに供給するという供給態様が可能になるので、 BD-ROMの出荷後
に、コメンタリを追加するような供給法を容易に実現することができる。
[0209] (第 6実施形態)
第 1実施开態では、 Playltemにおける In_Time、 Out_Timeと、 SubPlayltemにおける In _Time、 Out_Timeとを一致させることで、 Playltem間の接続点、及び、 SubPlayltemの 接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この 接続点の一致を要求せず、ある程度の時間差を認める。
[0210] この時間差を認める場合、別の制限が必要になる。 Playltem, SubPlayltem間のシー ムレス接続において、上述した STCの変更処理を行うが、この変更処理は、デコーダ 力 Sフリーラン状態にある場合になされる。この場合、シームレス接続では STCが復帰 するまで、デコーダは、同期制御に移ることができないので、 STC変更を伴うシームレ ス接続は実装の都合上、頻繁には受け入れられない。したがって、 Playltemと SubPla yltemの両方にぉ 、て連続する CC=5の接続点は所定の時間間隔 (例えば 3秒程度) を置いて起こるように制限されるべきである。
[0211] 図 42は、オーディオミキシングを示すプレイリストにて指定される Playltemと SubPlayl temの相関を示した図である。図 42の第 1段目は、 PlayList情報における 3つの Playlte m(PlayItem情報 #1、 Playltem情報 #2、 Playltem情報 #3)を示す。これら 3つの Playltem はプライマリ TSを指定しており、 Playltem情報 #1、 Playltem情報 #2間は CC=1に設定さ れ、 Playltem情報 #2、 Playltem情報 #3間は、 CC = 5に設定されている。図 42の第 2段 目は、 PlayList情報における 3つの SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubP layltem#3)を示す。これら 3つの SubPlayltemはセカンダリ TSを指定しており、 SubPlaylt em#l、 SubPlayItem#2間は CC=1に設定され、 SubPlayItem#2、 SubPlayItem#3間は、 S P_CC = 5に設定されている。図 42の第 3段目は、 Progressive PlayList情報における 9 っの3 ?1& ½6111(3 ?1& ½6]11#1、 SubPlayItem#2、 SubPlayItem#3〜SubPlayItem#9) を示す。これら 9つの SubPlayltemはセカンダリ TSを指定しており、 SubPlayItem#3、 Sub Playltem#4間は SP_CC=1に設定され、 SubPlayItem#4、 SubPlayItem#5間は、 SP_CC=5 に設定され、それ以外は、 SC=6に設定されている。
[0212] 本図において、第 2段目の SubPlayItem#3の開始は、第 1段目における Playltem#3の 開始点より 3秒前である。同様に、第 3段目の SubPlayItem#5の開始点は、第 1段目に
おける Playltem#3の開始点より 3秒前である。
Playltemと、 SubPlayltemとの STC時間軸切り替えのための時間間隔は、 3秒になつ ているので、 STC時間軸の変更が頻繁になり過ぎることはない。
[0213] また CC=1のタイミングは Playltemに合わせて SP_CC=1で接続される。これは CC=1 のノンシームレス接続時に SubPlayltemだけが再生を連続して継続した場合に、 Playlt emと SubPlayltemの同期再生がずれていくことを防ぐためでもある。
Playltemの途中で SubPlayltemを SP_CC=5で接続すると!/、う接続形態は、一枚のデ イスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。
[0214] 図 43の第 1段目は、劇場公開版とディレクターズカットの両方を構成する PlayList情 報の一例を示す。この PlayList情報のうち、 Playltem#l、 Playltem#2、 Playltem#4から 構成されるがディレクターズカットであり、 Playltem#l、 Playltem#3、 Playltem#4から構 成されるのが劇場公開版である。このように、 Playltem#lと Playltem#4はどちらのバー ジョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異 なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えること 力 Sできる。図 43の第 2段目は、同図の第 1段目における Playltem#l、 Playltem#2、 Pla yltem#4に対応するコメンタリを 1つの SubPlayltemとして定義し、 Playltem#l、 Playltem #3、 Playltem#4に対応するコメンタリとを、別の SubPlayltemとして定義する一例を示 す。この場合、 2つの SubPlayltemのそれぞれにおいて、 Playltem情報 #1、 Playltem情 報 #4に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。
[0215] 図 43の第 3段目は、 Playltem情報 #1、 Playltem情報 #2、 Playltem情報 #3、 Playltem 情報 #4のそれぞれに対応する SubPlayItem(SubPlayItem#l、 SubPlayItem#2、 SubPlayl tem#3、 SubPlayItem#4)を定義する一例を示す。そして SubPlayItem#lと、 SubPlayltem #2及び SubPlayItem#3との間、 SubPlayItem#2及び SubPlayItem#3と、 SubPlayItem#4と の間は、 CC = 5で接続するものとする。これらの接続点は、 Playltemにおける接続点 と、 3秒の時間間隔を設ける。つまり Playltem#lが終わる 3秒前にコメンタリの方は Sub Playltem#2と SubPlayItem#3に CC=5 (もしくは CC=6)を使って分岐させている。
[0216] また、 Playltem#2、 Playltem#3が終わった 3秒後に CC=5 (もしくは CC=6)を使って Su bPlayItem#4に分岐している。 SubPlayItem#2と SubPlayItem#3の開始、及び、 SubPlav
Item#4の開始は、 Playltem#2と Playltem#3の開始、及び、 Playltem#4の開始から、 3 の時間間隔を置いている。以上の時間間隔を置くことにより、 STC時間軸の変更が 頻繁になり過ぎることはない。
[0217] 厳密には、 CC=5は、 SubPlayItem#3から SubPlayItem#4への復帰の時だけ(ATC/S TC時間軸がリセットされるシームレス接続)必要であり、その他は CC=6で代用が可能 である。
以上のように本実施形態によれば、 Playltemの In_Time、 Out_Timeと、 SubPlayltem の In_Time、 Out_Timeとが一致していないので、 ATC Counter2aと 2c、および STC Co unter3aと STC Counter3cの同期は不要となり、再生装置の設計の余地を広げること ができる。
[0218] (第 7実施形態)
第 6実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリーム を BD-ROM、ローカルストレージから同時に読み出しデコーダに供給する場合、ブラ ィマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象と したが、本実施形態では、 Picture in Picture(PiP)再生アプリケーションを実現する場 合におけるビット量制限について説明する。
[0219] PiP再生とは、 PlayList情報の MainPath情報により、動画像を構成する MainClipが指 定されており、 PlayList情報の SubPlayltem情報により、別の動画像を構成する SubCli Pが指定されている場合、前者の動画像 (Primary Video)と、後者の動画像 (Secondary Video)とを、同じ画面内に表示するこという。ここで Primary Videoは HD画像から構成 され、 Secondary Videoは SD画像から構成される。 HD画像は、 1920 X 1080という解像 度を有し、フィルム素材同様、 3750 (もしくは 3753か 3754)クロックのフレーム間隔を有 する。 SD画像は、 720 X 480という解像度を有し、 NTSC素材同様、 1501クロックの表 示間隔、又は、 PAL素材同様、 1800クロックのフレーム間隔を有する。
[0220] SD画像の解像度は、 HD画像の解像度の約 1/4程度なので、 HD画像たる Primary V ideoと、 SD画像たる Secondary Videoとを同じ画面上に表示すると、 Secondary Video は、 Primary Videoに対し、約 1/4程度の大きさになる。
ここで Secondary Videoは、監督や出演者のみが登場している動画像であり、 Primar
y Videoにおける映像内容を指さすような演技を行っているものとする。かかる動画像 力 ^Secondary Videoであるなら、力力る Secondary Videoの映像内谷を、 Primary Video の映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や 出演者が指さして、解説しているような、楽しい画面演出を実現することができる。
[0221] <本実施形態における PlayList情報 >
Secondary Videoのためのビデオストリーム (セカンダリビデオストリーム)は、 PlayList 情報の SubPath情報における複数の SubPlayltem情報にて指定される。力かる SubPlay Item情報には、 PiP_Position、 PiP_Sizeという情報要素が新規に追加される。
"PiP_Position"は、 Primary Video再生のための画面プレーン上の X座標、 Y座標を 用いて、 Secondary Videoの再生映像が配置されるべき位置を示す。
[0222] "PiP_Size"は、 Secondary Video再生映像の縦サイズ、横サイズを示す。
また、本実施形態にぉ 、て SubPlayltemの sp_connection_condition情報が" =5"に設 定されて!/、ると!/、うことは、カレント SubPlayltem側の SubClipに多重化されて!/、るセ力 ンダリビデオストリームと、 previousSubPlayltem側の SubClipに多重化されているセカ ンダリビデオストリームとがシームレス接続される保証があることを意味する。かかる Su bPiayltemの sp— connection— condition†青報 ίま、 Playltem†青報の connection— condition†青 報と同じ値に設定されるので、 Playltem情報の connection_condition情報が" =5"であ るなら、 SubPlayltem情報の sp_connection_condition情報も" =5"に設定されねばなら ない。つまり Playltem側のプライマリビデオストリームがシームレス接続されるなら、 Sub Playltem側のセカンダリビデオストリームもシームレス接続されねばならな!/、。また Sub Playltem情報の In— Time、 Out— Timeは、 Playltem情報の In— Time、 Out— Timeと同じ時点 を指し示さねばならない。
[0223] 以上が、本実施形態における記録媒体の改良である。
<本実施形態における再生装置の改良 >
続いて、再生装置の改良について説明する。 Secondary Videoストリームのデコード を行うベぐ本実施形態に係る再生装置のハードウェア構成には、ビデオストリームを デコードするための構成要素力 Sもう一組、追加されている。ここでビデオストリームを デコードするための構成要素とは、 Transport Buffer, Multiplexed Buffer, Elementary
Buffer、デコーダ、 Videoプレーンであり、これらはセカンダリビデオストリームをデコー ドする。その他、本実施形態に係る再生装置には、以下の Scaller、合成部が追加さ れている。
[0224] Scalierは、 SubPlayltem情報の PiP_Sizeに示される縦.横の大きさに基づき、 Seconda ry Videoプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、 Scalierによりされた拡大又は縮小された再生映像と、ビデオデコーダに より得られた再生映像とを合成することで PiP再生を実現する。合成部による Primary Videoの再生映像と、 Secondary Videoの再生映像との合成は、 SubPlayltem情報にて 規定されている、 PiP_Positionに従ってなされる。こうすることにより、 Primary Videoの 再生映像と、 Secondary Videoの再生映像とが合成された合成映像が再生されること になる。この合成部による合成では、クロマキ一合成、レイヤ合成等が可能であり、 Se condary Videoにおける背景を取り除き、人物部分を抜き出した上で、 Primary Video の再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置に ついての説明である。
[0225] < PiPアプリケーションに対するべリファイ >
PiP再生の実現にあたって、プライマリ TSたるビデオストリーム (プライマリビデオストリ 一ム)、セカンダリ TSたるビデオストリーム (セカンダリビデオストリーム)を同時に読み出 し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリーム を、ビット量を制限するためのベリファイの対象とする。
[0226] 具体的にいうと ATC時間軸において Windowをシフトさせた際、 ATSに示される ATC 時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、 複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数 の PGストリーム、複数の IGストリームのうち、算出されたビットレートが最も高いものを 選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリーム のビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカ ンダリオ一ディォストリームのビットレートの最大値、 PGストリームのビットレートの最大 値、 IGストリームのビットレートの最大値を合計して、その合計量が 48Mbit以下である かを判定する。
[0227] 以上のように本実施形態によれば、 BD- ROM、ローカルストレージの双方からプライ マリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応 するデコーダに供給する場合でも、 1秒当たりのビット量が、所定の上限を越えないと いう保障を施すことができる。力かる保障を与えるので、 PiPアプリケーションを、効率 的に作成することができる。
[0228] (備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明 したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えること ができる。各実施形態に示した通り実施する力、これらの改良'変更を施すか否かは 、何れも任意的
であり、実施する者の主観によることは留意されたい。
[0229] (In— Time、 Out— Time)
図 27では、 TSlの最後の Video Presentation Unitを previousPlayltemの Out— Timeと して選び、 TS2の最初の Video Presentation Unitを previousPlayltem, previousSubPla yltemの In_Timeとして選んだ力 TSlの途中の Video Presentation Unitを previousPlay Itemの Out_Timeとして選び、 TS2の途中の Video Presentation Unitをカレント Playltem 、カレント SubPlayltemの In_Timeとして選んでもよい。この場合、 Playltem、カレント Sub Playltemは、シームレスに接続することができず、 CC=1,SP_CC=1として接続せねばな らない。
[0230] (PlayList情報全体)
2つの Playltem間を CC = 5で接続しょうとする場合、 1つの PlayList情報に属する全 ての Playltem情報、全ての SubPlayltem情報は、 CC = 5として接続せねばならない。
(デコーダへのデータ供給量)
Out_of_MUXにお 、て、デコーダへのデータ供給量は必ずしも大きくなる訳ではな い。例えば、プライマリオーディオストリームが MainClipであり、 CBRの DD(Dolby Digit al)と、 VBRの MLPとから構成されていて、この MLPが、ローカルストレージから供給さ れた CBRの DDに置き換えられるものとする。この場合、デコーダへのデータ供給量は かえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。
[0231] (再生時間差)
CC = 5、 SP_CC=5を実現するにあたって、 1つの Playltemの中での各ビデオストリー ム /オーディオストリームの再生時間差も小さ 、ことが望ま U、。この差もビデオ 1フレ ーム分(1/60〜1/25秒)としても良いし、 1秒以下などとしても良いし、全体の再生時 間に対する割合(1%以下など)であっても良いし、これら 2つを組み合わせたもので あっても良 、。 1つの SubPlayltemの中での各ビデオ/オーディオエレメンタリストリーム の再生時間差も同様である。
[0232] 1つの PIDに、 2つのエレメンタリストリームを格納するケースにおいては、同一 PIDで 格納される 2つのストリームの再生時間長の差は、どちらか再生時間が短いストリーム の方の最小再生単位(1フレーム)の再生時間長未満であることが望ましい。かかるケ ースに該当するのは、 Dolby Digital (AC- 3)と、 MLP(Meridian Lossless Packing)と 力 1つのエレメンタリストリームに格納されて、 BD-ROMに記録される場合である。
[0233] (追加コンテンツに対する処理)
ローカルストレージ 200にダウンロードされた追加コンテンツは、何ヶ月、何年か経 過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
(PIDの代用)
オーディオミキシングアプリケーションの実現時にぉ 、て、プライマリオーディオスト リーム、セカンダリオーディオストリームの区別に PIDを用いたが、 MPEG2-PSを使う場 合には、 PESパケットヘッダの streamjdをそれぞれ異なるものにするのが望ましい。
[0234] またプライマリオーディオストリーム、セカンダリオーディオストリームは、 2つの音声 ストリームが 1つのデマルチプレクサでも弁別可能なように、システムストリームレベル において区別されていればよい。もしくは、 2つのストリームを 1つに束ねる前に、片方 の
PIDを重複しな 、ように付け替えておくだけでもよ!/、。
[0235] (プリロード)
クリック音のためのオーディオデータ(ファイル sound.bdmv)のプリロードは、 BD-RO Mのローデイング時やタイトル切替時に行うことが望ましい。何故なら、 AVClipの再生 中にファイル sound.bdmvを読み出そうとすると、 AVClipとは別のファイルを読み出す
ための光ピックアップのシークが発生する力もである。一方、 BD-R0Mの装填時ゃタ ィトル切替時には、 AVClipの再生が継続していることは希なので、かかるタイミングに ファイル sound.bdmvを読み出すことにより、機器の応答性を高め AVClip再生が途切 れにくくすることができる。
[0236] (Java (登録商標) (TM)プラットフォーム)
各実施形態に力かる再生装置に、 Java (登録商標) (TM)2Micro_Edition(J2ME) Pers onal Basis Profile(PBP 1.0)と、 Globally Executable MHP specification(GEM 1.0.2)for package media targetsとをフル実装することで Java (登録商標)(TM)プラットフォームを 構成し、 BD-Jアプリケーションを再生装置に実行させてもよい。そしてこのアプリケー シヨンの実行にあたって、 Out_of_MUXフレームワークを再生装置に実行させてもよい
[0237] (タイトル)
BD-ROMの装填やユーザ操作、装置の状態に応じてタイトルを選択する"モジユー ルマネージャ"を再生装置に設けるのが望ましい。 BD-ROM再生装置内のデコーダ は、この"モジュールマネージャ"によるタイトル選択に応じて、プレイリスト情報に基づ く AVClipの再生を行う。
[0238] アプリケーションマネージャは、 "モジュールマネージャ"がタイトルの選択を行った 際、前のタイトルに対応するアプリケーション管理テーブル (AMT)と、カレントタイトル に対応する AMTとを用いてシグナリングを実行する。このシグナリングは、前のタイト ルに対応する AMTには記載されている力 カレントタイトルに対応する AMTには記載 されていないアプリケーションの動作を終了させ、前のタイトルに対応する AMTには 記載されておらず、カレントタイトルに対応する AMTには記載されているアプリケーシ ヨンの動作を開始させるという制御を行う。
[0239] (ローカルストレージ内のディレクトリ構成)
各実施形態に示したローカルストレージ内の各領域は、 BD-ROMにおけるディスク ルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、この BD-ROMを作成した作成者力 ルート認証局力も配 布を受けたルート証明書を、 BD-ROMに割り当てたものである。ディスクルート証明書
はたとえば X.509の形式で符号されて 、る。 X.509の仕様は国際電信電話諮問委員 会より発行されており、 CCITT Recommendation X.509 (1988), "The Directory - Au thentication Framework こ れて 、 。
また、 BD- ROM、ローカルストレージの記録内容は、 Advancend Access Content Sy stem(AACS)にて暗号ィ匕され、署名情報が付されて、利用権限が、パーミッションファ ィルに規定されて 、るのが望まし 、。
(実装すべきパッケージ)
BD-ROM再生装置を、 Java (登録商標) (TM)プラットフォームとして実施するにあた つては、以下の BD-J Extentionを再生装置に実装するのが望ましい。 BD-J Extentio nは、 GEM[1.0.2]を越えた機能を、 Java (登録商標) (TM)プラットフォームに与えるた めに特化された、様々なパッケージを含んでいる。 BD-J Extentionにて供給されるパ ッケージには、以下のものがある。
• org.bluray.media
このパッケージは、 Java (登録商標) (TM) Media FrameWorkに追加すべき、特殊機 能を提供する。アングル、音声、字幕の選択についての制御力 このパッケージに追 加される。
•org.bluray.ti
このパッケージは、 GEM[1.0.2]における"サービス"を"タイトル"にマップして動作す るための APIや、 BD-ROM力もタイトル情報を問 、合わせる機構や新たなタイトルを選 択する機構を含む。
• org. bluray. application
このパッケージは、アプリケーションの生存区間を管理するための APIを含む。また 、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問 、合わせ る APIを含む。
•org.biuray.ui
このパッケージは、 BD-ROMに特化されたキーイベントのための定数を定義し、映 像再生との同期を実現するようなクラスを含む。
•org. bluray. vfs
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、 B D- ROMに記録されたコンテンツ (on-discコンテンツ)と、 BD- ROMに記録されて!、な!/ヽ Local Storage上のコンテンツ (off-discコンテンツ)とをバインドする機構 (Binding Schem e)を提供する。
[0241] Binding Schemeとは、 BD- ROM上のコンテンツ (AVClip、字幕、 BD- Jアプリケーショ ン)と、 Local Storage上の関連コンテンツとを関連付けるものである。この Binding Sche meは、コンテンツの所在に拘らず、シームレス再生を実現する。
(Virtual Package)
Virtual Packageを生成させるような処理を BD- ROM再生装置に行わせてもよい。こ れは、再生装置が Virtual Package情報を生成することでなされる。 Virtual Package情 報とは、 BD-ROMにおけるボリューム管理情報を拡張した情報である。ここでボリユー ム管理情報は、ある記録媒体上に存在するディレクトリ ファイル構造を規定する情 報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管 理情報とからなる。 Virtual Package情報とは、 BD- ROMのディレクトリ—ファイル構造 を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、 BD-R OMにおけるディレクトリ一ファイル構造の拡張を図ったものである。
[0242] (制御手順の実現)
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構 成要素による制御手順は、ハードウェア資源を用 、て具体的に実現されて 、ることか ら、自然法則を利用した技術的思想の創作といえ、 "プログラムの発明"としての成立 要件を満たす。
[0243] ·本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログ ラム (オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや 、機能的構成要素の個々の手順を、コンピュータに実行させるような 1つ以上のプロ グラムコードから構成される。ここでプログラムコードは、プロセッサのネイティブコード 、 JAVA (登録商標)バイトコードというように、様々な種類がある。またプログラムコード による各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップ
を実現することができる場合、この外部関数をコールするコール文力 プログラムコー ドになる。また、 1つのステップを実現するようなプログラムコード力 別々のオブジェク トプログラムに帰属することもある。命令種が制限されている RISCプロセッサでは、算 術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ス テツプが実現されることちある。
[0244] 本発明に力かるプログラムは、以下のようにして作ることができる。先ず初めに、ソフ トウエア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成 要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア 開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部 関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプ ログラムを記述する。
[0245] 記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは 、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程か らなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行 い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対 して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割 付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム 中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリ に割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコード に変換し、オブジェクトプログラムを得る。
[0246] オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する 。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空 間に割り当て、これらを 1つに結合して、ロードモジュールを生成する。こうして生成さ れるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フロ 一チャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実 行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる
[0247] 本発明に係るプログラムは、以下のようにして使用することができる。本発明に係る プログラムを糸且込プログラムとして使用する場合、プログラムにあたるロードモジユー ルを、基本入出力プログラム (BIOS)や、様々なミドルウェア (オペレーションシステム)と 共に、命令 ROMに書き込む。こうした命令 ROMを、制御部に組み込み、 CPUに実行 させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用 することができる。
[0248] 再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム (BIO S)が命令 ROMに組み込まれており、様々なミドルウェア (オペレーションシステム)が、 ハードディスクにプレインストールされている。また、ハードディスクから、システムを起 動するためのブート ROM力 再生装置に設けられている。この場合、ロードモジユー ルのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、 1つのァ プリケーシヨンとしてハードディスクにインストールする。そうすると、再生装置は、ブー ト ROMによるブートストラップを行い、オペレーションシステムを起動した上で、 1つの アプリケーションとして、当該アプリケーションを CPUに実行させ、本発明に係るプログ ラムを使用する。
[0249] ハードディスクモデルの再生装置では、本発明のプログラムを 1つのアプリケーショ ンとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネ ットワークを通じて供給することができる。
(コントローラ 22)
コントローラ 22は、一個のシステム LSIとして実現することができる。
[0250] システム LSIとは、高密度基板上にベアチップを実装し、パッケージングしたものを いう。複数個のベアチップを高密度基板上に実装し、ノ ッケージングすることにより、 あたカゝも 1つの LSIのような外形構造を複数個のベアチップに持たせたものも、システ ム LSIに含まれる (このようなシステム LSIは、マルチチップモジュールと呼ばれる。;)。 ここでパッケージの種別に着目するとシステム LSIには、 QFP (タッドフラッドアレイ) 、 PGA (ピングリッドアレイ)という種別がある。 QFPは、パッケージの四側面にピンが 取り付けられたシステム LSIである。 PGAは、底面全体に、多くのピンが取り付けられ たシステム LSIである。
[0251] これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システム LSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システム LSI におけるこれらのピンに、他の回路を接続することにより、システム LSIは、再生装置の 中核としての役割を果たす。
システム LSIにパッケージングされるベアチップは、 "フロントエンド部"、 "バックェン ド部"、 "デジタル処理部"からなる。 "フロントエンド部"は、アナログ信号を、デジタル 化する部分であり、 "バックエンド部"はデジタル処理の結果、得られたデータを、アナ 口グイ匕して出力する部分である。
[0252] 各実施形態において内部構成図として示した各構成要素は、このデジタル処理部 内に実装される。
先に"組込プログラムとしての使用"で述べたように、命令 ROMには、プログラムにあ たるロードモジュールや、基本入出力プログラム (BIOS)、様々なミドルウェア (オペレー シヨンシステム)が書き込まれる。本実施形態において、特に創作したのは、このプロ グラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュール を格納した命令 ROMを、ベアチップとしてパッケージングすることにより、本発明に係 るシステム LSIは生産することができる。
[0253] 具体的な実装につ!、ては、 SoC実装や SiP実装を用いることが望まし 、。 SoC(Syste m on chip)実装とは、 1チップ上に複数の回路を焼き付ける技術である。 SiP(System in Package)実装とは、複数チップを榭脂等で 1パッケージにする技術である。以上の過 程を経て、本発明に係るシステム LSIは、各実施形態に示した再生装置の内部構成 図を基に作ることができる。
[0254] 尚、上述のようにして生成される集積回路は、集積度の違いにより、 IC、 LSI,スーパ -LSI,ウノレ卜ラ LSIと呼称されることちある。
さらに、各記録再生装置の構成要素の一部又は全てを 1つのチップとして構成して もよい。集積回路化は、上述した SoC実装, SiP実装に限るものではなぐ専用回路又 は汎用プロセスで実現してもよい。 LSI製造後に、プログラムすることが可能な FPGA ( Field Programmable Gate Array)や、 LSI内部の回路セルの接続や設定を再構成可 能なシリコンフィギユラブル'プロセッサを利用することが考えられる。更には、半導体
技術の進歩又は派生する技術により LSIに置き換わる集積回路化の技術が登場すれ ば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バ ィォ技術の適応などが可能性としてありうる。
産業上の利用可能性
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されて おり、この内部構成に基づき量産することが明らかなので、資質において工業上利用 することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有 する。