(57)【要約】      （修正有）【課題】ソフトウェアの実装を困難化させることなく、Out-of-MUXフレームワークを再生装置に実現させることができる記録媒体を提供する。【解決手段】BD-ROMにはPlayList情報が記録されている。前記PlayList情報は、MainPath情報、SubPath情報を含む。MainPath情報及びSubPath情報はconnection_condition情報、sp_connection_condition情報を含み、connection_condition情報、sp_connection_condition情報は、MainPath情報にて参照される2つのMainClip間の接続状態が、シームレス接続(CC＝5)である場合、SubPath情報で参照される2つのSubClip間の接続状態もまた、シームレス接続(SP_CC=5)であるである旨を示す。【選択図】図２４
2011081897.tif 000002
【特許請求の範囲】
【請求項１】
セカンダリストリームと、他の記録媒体に記録されたプライマリストリーム及び当該セカンダリストリームの再生経路を示すプレイリスト情報と、が記録された記録媒体であって、
前記セカンダリストリームは、前記プライマリストリームに含まれる主映像に関連させて再生させる付属情報を含み、
前記プレイリスト情報は、主映像の１再生区間を定義する１つのプレイアイテム情報を複数持つことでプライマリストリームの再生経路を示し、主映像に関連した付属情報の１再生区間を定義する１つのサブプレイアイテム情報を複数持つことで前記セカンダリストリームの再生経路を示し、
前記複数のプレイアイテム情報のうち連続した２つのプレイアイテム情報を直前のプレイアイテム情報、現在のプレイアイテム情報とし、前記複数のサブプレイアイテム情報のうち２つの連続したサブプレイアイテム情報を直前のサブプレイアイテム情報、現在のサブプレイアイテム情報とすると、
現在のプレイアイテム情報は、
主映像の１再生区間の再生開始時刻情報を示すインタイムと、
主映像の１再生区間の再生終了時刻情報を示すアウトタイムと、
直前のプレイアイテム情報と現在のプレイアイテム情報との境界の接続状態を示す接続状態情報とを含み、
現在のサブプレイアイテム情報は、
付属情報の１再生区間の再生開始時刻情報を示すインタイムと、
付属情報の１再生区間の再生終了時刻情報を示すアウトタイムと、
関連づけて再生する前記プレイアイテム情報を特定するプレイアイテムIDと、
前記プレイアイテムIDによって特定される現在のプレイアイテム情報の再生時間上における前記サブプレイアイテム情報のインタイムの位置を決めるプレイアイテム同期PTS情報と、
直前のサブプレイアイテム情報と現在のサブプレイアイテム情報との境界の接続状態を示すサブ接続状態情報と、を含み、
前記現在のサブプレイアイテム情報の前記プレイアイテムIDで関連づけられるのが現在のプレイアイテム情報であって、前記現在のプレイアイテム情報の接続状態情報がシームレス再生であることを示す場合、
前記サブ接続状態情報もシームレス再生であることを示し、
前記サブプレイアイテム情報のプレイアイテム同期PTS情報は、現在のプレイアイテム情報のインタイムと等しく、現在のサブプレイアイテム情報のインタイムと現在のプレイアイテム情報のインタイムは等しく、
前記直前のプレイアイテム情報で再生区間が定義される主映像と、前記現在のプレイアイテム情報で再生区間が定義される主映像は、ビデオの解像度及びフレームレートが同じである、
ことを特徴とする記録媒体。
【請求項２】
前記プライマリストリームがMPEG-2のビデオ形式である場合、
前記直前のプレイアイテム情報で再生区間が定義される主映像を含むプライマリストリームは、シーケンスの終わりを示す情報で完了する、請求項１に記載の記録媒体。
【請求項３】
前記プライマリストリームがMPEG4-AVCのビデオ形式である場合、
前記直前のプレイアイテム情報で再生区間が定義される主映像を含むプライマリストリームは、シーケンスの終わりを示す情報で完了する、請求項１記載の記録媒体。
【請求項４】
プライマリストリームが記録された他の記録媒体と、前記請求項１に記載の記録媒体と、から情報を読み出して、ストリームを再生する再生装置であって、
前記第２の記録媒体に記録されている前記プレイリスト情報に従って、前記プライマリストリーム及び前記セカンダリストリームを読み出す読出部と、
前記読出部によって読み出されたプライマリストリームに含まれる主映像とセカンダリストリームに含まれる付属情報とを関連させて再生する再生部と、
を備える再生装置。
【請求項５】
プライマリストリームが記録された他の記録媒体と関連して用いられる記録媒体に情報を記録する記録方法であって、
アプリケーションデータを生成するステップと、
前記アプリケーションデータを記録媒体に記録するステップと、
を有し、
前記アプリケーションデータは、セカンダリストリームと、前記プライマリストリーム及び前記セカンダリストリームの再生経路を示すプレイリスト情報と、を含み、
を有し、
前記プレイリスト情報は、主映像の１再生区間を定義する１つのプレイアイテム情報を複数持つことでプライマリストリームの再生経路を示し、主映像に関連した付属情報の１再生区間を定義する１つのサブプレイアイテム情報を複数持つことで前記セカンダリストリームの再生経路を示し、
前記複数のプレイアイテム情報のうち連続した２つのプレイアイテム情報を直前のプレイアイテム情報、現在のプレイアイテム情報とし、前記複数のサブプレイアイテム情報のうち２つの連続したサブプレイアイテム情報を直前のサブプレイアイテム情報、現在のサブプレイアイテム情報とすると、
現在のプレイアイテム情報は、
主映像の１再生区間の再生開始時刻情報を示すインタイムと、
主映像の１再生区間の再生終了時刻情報を示すアウトタイムと、
直前のプレイアイテム情報と現在のプレイアイテム情報との境界の接続状態を示す接続状態情報とを含み、
現在のサブプレイアイテム情報は、
付属情報の１再生区間の再生開始時刻情報を示すインタイムと、
付属情報の１再生区間の再生終了時刻情報を示すアウトタイムと、
関連づけて再生する前記プレイアイテム情報を特定するプレイアイテムIDと、
前記プレイアイテムIDによって特定される現在のプレイアイテム情報の再生時間上における前記サブプレイアイテム情報のインタイムの位置を決めるプレイアイテム同期PTS情報と、
直前のサブプレイアイテム情報と現在のサブプレイアイテム情報との境界の接続状態を示すサブ接続状態情報と、を含み、
前記現在のサブプレイアイテム情報の前記プレイアイテムIDで関連づけられるのが現在のプレイアイテム情報であって、前記現在のプレイアイテム情報の接続状態情報がシームレス再生であることを示す場合、
前記サブ接続状態情報もシームレス再生であることを示し、
前記サブプレイアイテム情報のプレイアイテム同期PTS情報は、現在のプレイアイテム情報のインタイムと等しく、現在のサブプレイアイテム情報のインタイムと現在のプレイアイテム情報のインタイムは等しく、
前記直前のプレイアイテム情報で再生区間が定義される主映像と、前記現在のプレイアイテム情報で再生区間が定義される主映像は、ビデオの解像度及びフレームレートが同じである、ことを特徴とする記録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Out-of-MUXフレームワークの技術分野に属する発明である。
【背景技術】
【０００２】
Out-of-MUXフレームワークとは、BD-ROM等のリードオンリー型の記録媒体に記録されているデジタルストリームと、ハードディスク等のリライタブル型の記録媒体に記録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生させる技術である。
ここでBD-ROMに記録されているデジタルストリームが、映画作品の本編を構成するものであり、ローカルストレージに記録されているデジタルストリームが、映画監督のコメンタリを構成する場合、上述したOut-of-MUXフレームワークを実現することにより、BD-ROM上の本編と、コメンタリとを再生に供して、BD-ROMの内容拡充を図ることができる。
【０００３】
尚、リードオンリー型記録媒体の先行技術としては、以下の特許文献に記載されているものがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特願平８ー８３４７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、Out-of-MUXフレームワークを実行しようとすると、BD-ROMから読み出されたデジタルストリームに対して多重分離を行う多重分離部と、ローカルストレージから読み出されたデジタルストリームに対して多重分離を行う多重分離部とを装置内に設け、また各多重分離部にSTCを供給するクロックカウンタを２つ設けて、対応するSTCを参照した多重分離動作を、２つの多重分離部に行わせる必要がある。そうすると、個々の多重分離部による多重分離の処理は、互いに独立したものとなる。ここで多重分離の対象となるパケット列に時間軸の不連続点が存在する場合、一方のSTCを変更してこれに基づく多重分離動作を多重分離部に行わせた上、他方のSTCを変更して、これに基づく多重分離動作を他方の多重分離部に行わさねばならない。
【０００６】
ここで不連続点が個々の時間軸において、不規則に存在すれば、一方のSTCを変更しては、他方の変更もリセットするという、変更の繰り返しが多発する。この繰り返しの多発化は、再生装置における制御をいたずらに複雑化して、ソフトウェアによる実装を困難にさせる。かかる実装の困難化は、Out-of-MUXフレームワークを行い得る再生装置の普及を遅らせ、再生装置の低価格化を妨げる要因になる。
【０００７】
本発明の目的は、ソフトウェアの実装を困難化させることなく、Out-of-MUXフレームワークを再生装置に実現させることができる記録媒体を提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明にかかる記録媒体は、セカンダリストリームと、他の記録媒体に記録されたプライマリストリーム及び当該セカンダリストリームの再生経路を示すプレイリスト情報と、が記録された記録媒体であって、
前記セカンダリストリームは、前記プライマリストリームに含まれる主映像に関連させて再生させる付属情報を含み、
前記プレイリスト情報は、主映像の１再生区間を定義する１つのプレイアイテム情報を複数持つことでプライマリストリームの再生経路を示し、主映像に関連した付属情報の１再生区間を定義する１つのサブプレイアイテム情報を複数持つことで前記セカンダリストリームの再生経路を示し、
前記複数のプレイアイテム情報のうち連続した２つのプレイアイテム情報を直前のプレイアイテム情報、現在のプレイアイテム情報とし、前記複数のサブプレイアイテム情報のうち２つの連続したサブプレイアイテム情報を直前のサブプレイアイテム情報、現在のサブプレイアイテム情報とすると、
現在のプレイアイテム情報は、
主映像の１再生区間の再生開始時刻情報を示すインタイムと、
主映像の１再生区間の再生終了時刻情報を示すアウトタイムと、
直前のプレイアイテム情報と現在のプレイアイテム情報との境界の接続状態を示す接続状態情報とを含み、
現在のサブプレイアイテム情報は、
付属情報の１再生区間の再生開始時刻情報を示すインタイムと、
付属情報の１再生区間の再生終了時刻情報を示すアウトタイムと、
関連づけて再生する前記プレイアイテム情報を特定するプレイアイテムIDと、
前記プレイアイテムIDによって特定される現在のプレイアイテム情報の再生時間上における前記サブプレイアイテム情報のインタイムの位置を決めるプレイアイテム同期PTS情報と、
直前のサブプレイアイテム情報と現在のサブプレイアイテム情報との境界の接続状態を示すサブ接続状態情報と、を含み、
前記現在のサブプレイアイテム情報の前記プレイアイテムIDで関連づけられるのが現在のプレイアイテム情報であって、前記現在のプレイアイテム情報の接続状態情報がシームレス再生であることを示す場合、
前記サブ接続状態情報もシームレス再生であることを示し、
前記サブプレイアイテム情報のプレイアイテム同期PTS情報は、現在のプレイアイテム情報のインタイムと等しく、現在のサブプレイアイテム情報のインタイムと現在のプレイアイテム情報のインタイムは等しく、
前記直前のプレイアイテム情報で再生区間が定義される主映像と、前記現在のプレイアイテム情報で再生区間が定義される主映像は、ビデオの解像度及びフレームレートが同じである、ことを特徴にしている。
【発明の効果】
【０００９】
本発明によれば、サブプレイアイテム情報のプレイアイテム同期PTS情報は、現在のプレイアイテム情報のインタイムと等しく、現在のサブプレイアイテム情報のインタイムと現在のプレイアイテム情報のインタイムは等しいので、従たる再生区間の再生を伴いながら、主たる再生区間を再生させてゆく場合、プライマリストリーム側のSTCの不連続点は、プライマリストリーム側のSTCの不連続点と同じ時点に現れることになる。２つのSTC時間軸において、不連続点は、同じ時点に発生するので、かかる時点において多重分離部を再設定すれば、各多重分離部による多重分離動作を簡単に同期させてゆくことができる。かかる同期により、メーカーは、Out_of_MUXアプリケーションを実現するような再生装置を、多く市場に投入することができ、Out_of_MUXアプリケーションを実現するような再生装置を、広く普及させることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの内部構成を示す図である。
【図３】拡張子.m２tsが付与されたファイルがどのように構成されているかを模式的に示す図である。
【図４】PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示す図である。
【図５】ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示す図である。
【図６】トランスポートストリームの詳細を示す図である。
【図７】PAT、PMTパケットの内部構成を示す図である。
【図８】AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。
【図９】Aligned Unitの内部構成を示す図である。
【図１０】Clip情報の内部構成を示す図である。
【図１１】映画のビデオストリームに対するEP_map設定を示す図である。
【図１２】PlayList情報のデータ構造を示す図である。
【図１３】AVClipと、PlayList情報との関係を示す図である。
【図１４】ローカルストレージ２００の内部構成を示す図である。
【図１５】Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSがBD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。
【図１６】PlayList情報のデータ構造を示す図である。
【図１７】Subpath情報の内部構成をクローズアップして示す図である。
【図１８】ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。
【図１９】（a）STN_tableの内部構成を示す図である。
【００１１】
（b）ビデオストリームに対応したStream_attributeを示す図である。
（c）オーディオストリームに対応したStream_attributeを示す図である。
（d）ビデオストリームにおけるStream_entryを示す図である。
【図２０】BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。
【図２１】（a）〜（d）Windowのシフトを示す図である。
【図２２】BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。
【図２３】（a）（b）各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。
【図２４】Out_of_MUXアプリケーションを構成するPlayItem、SubPlayItemの接続状態を示す図である。
【図２５】図２４に示した、PlayItemのconnection_condition情報、SubPlayItemのsp_connection_condition情報が“=５”に設定されている場合の、PlayItemにけるIn_Time、Out_Timeと、SubPlayItemにおけるIn_Time、Out_Timeとの関係を示す図である。
【図２６】PlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値、SubPlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値を示す。
【図２７】previousPlayItemにて参照されているMainClip、カレントPlayItemにて参照されているSubClipにおいて、TS１、TS２がどのように特定されるかを示す図である。
【図２８】CC=５、及び、SP_CC=５の詳細を示す図である。
【図２９】previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudio Presentation Unitと、STC時間軸との関係を示す図である。
【図３０】本発明に係る再生装置の内部構成を示す図である。
【図３１】PlayList情報に基づく再生手順のフローチャートである。
【図３２】SubPlayItemにおけるシームレス接続を示すフローチャートである。
【図３３】第２実施形態にかかるオーサリングシステムの内部構成を示す図である。
【図３４】プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。
【図３５】同種のエレメンタリストリームが複数存在する場合の、プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。
【図３６】CC=６の詳細な説明を示す図である。
【図３７】PlayItemとSubPlayItemの相関を示した図である。
【図３８】ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的に示す図である。
【図３９】オーディオに加えて、字幕（PG）やメニュー（IG）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
【図４０】オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。
【図４１】第５実施形態に係る再生装置の内部構成を示す図である。
【図４２】オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。
【図４３】劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す図である。
【発明を実施するための形態】
【００１２】
（第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ローカルストレージ２００である。ローカルストレージ２００は、再生装置３００、テレビ４００、AVアンプ５００、スピーカ６００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。
【００１３】
以降、BD-ROM１００、ローカルストレージ２００、再生装置３００について説明を行う。
BD-ROM１００は、映画作品が記録された記録媒体である。
ローカルストレージ２００は、再生装置に組み込まれ、映画配給者のサーバから配信されたコンテンツの受け皿として利用されるハードディスクである。
【００１４】
再生装置３００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。また、映画配給者のサーバ７００から、ネットワークを通じてダウンロードしたコンテンツを、ローカルストレージ２００に格納し、こうしてローカルストレージ２００に記録されたコンテンツと、BD-ROM１００に記録されたコンテンツと組み合わせて、BD-ROM１００のコンテンツを拡張/更新を行うことができる。BD-ROM１００の記録内容に、ローカルストレージ２００の記録内容を組み合わせて、BD-ROM１００に記録されていないデータを、恰も、記録されているように扱う技術を“バーチャルパッケージ”という。
【００１５】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ファイルシステム上における改良で実現することができる。
図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。この第１段目においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
【００１６】
このBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリと呼ばれる３つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル（００００１.mpls）がある。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル（００００１.clpi，００００２.clpi）がある。
【００１７】
STREAMディレクトリには、拡張子m２tsが付与されたファイル（００００１.m２ts，００００２.m２ts）がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
先ず初めに、拡張子.m２tsが付与されたファイルについて説明する。図３は、拡張子.m２tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m２tsが付与されたファイル（００００１.m２ts，００００２.m２ts）は、AVClipを格納している。AVClipはMPEG２-Transport Stream形式のデジタルストリームである。このデジタルストリームは、デジタル化された映像、デジタル化された音声を（上１段目）、PESパケットからなるエレメンタリストリームに変換し（上２段目）、更にTSパケットに変換して（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（Presentatiion Graphics（PG）ストリーム）及び対話系のインタラクティブグラフィクスストリーム（Interactive Graphics（IG）ストリーム）を（下１段目、下２段目）、TSパケットに変換して（下３段目）、これらを多重化することで構成される。
【００１８】
以降、これらのビデオストリーム、オーディオストリーム、PGストリーム、IGストリームについて説明する。
ビデオストリームは、映画作品の動画像を構成するストリームであり、SD画像、HD画像であるピクチャデータから構成される。ビデオストリームには、VC-１のビデオストリーム、MPEG４-AVCのビデオストリーム、MPEG２-Videoのビデオストリームといった形式が存在する。MPEG４-AVCのビデオストリームでは、IDRピクチャ，Iピクチャ，Pピクチャ，Bピクチャに、PTS、DTSといったタイムスタンプが付され、このピクチャの単位で、再生制御がなされる。このように、PTS、DTSが付されて、再生制御の単位となる、ビデオストリームの一単位を“Video Presentation Unit”という。
オーディオストリームは、映画作品の音声を表すストリームであり、LPCMオーディオストリーム、DTS-HDオーディオストリーム、DD/DD+オーディオストリームやDD/MLPオーディオストリームといった形式が存在する。オーディオストリームにおけるオーディオフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディオストリームの一単位を“Audio Presentation Unit”という。
PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。PGストリームは、PCS（Presentation Control Segment）、PDS（Pallet Define Segment）、WDS（Window Define Segment）、ODS（Object Define Segment）という一連の機能セグメントからなる。ODS（Object Define Segment）は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。
【００１９】
WDS（Window Define Segment）は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS（Pallet Define Segment）は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS（Presentation Control Segment）は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
【００２０】
IGストリームは、対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS（Interactive Composition Segment）、PDS（Palette Difinition Segment）、ODS（Object Definition Segment）と呼ばれる機能グメントからなる。ODS（Object Definition Segment）は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS（Palette Difinition Segment）は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS（Interactive Composition Segment）は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。
【００２１】
ここでAVClipは、１つ以上の“STC_Sequence”から構される。“STC_Sequence”とは、AVストリームのシステム基準時刻であるSTC（System Time Clock）の不連続点（system time-base discontinuity）が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR（Program Clock Reference）を運ぶPCRパケットの不連続情報（discontinuity_indicator）がONである点である。
【００２２】
図４は、PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第１段目は、ビデオストリームを示し、第３段目はオーディオストリームを示す。第２段目は、PESパケット列を示す。本図の矢印yy１，yy２，yy３，yy４に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIDR、Bピクチャ、Pピクチャは、複数に分割され、個々の分割部分が、PESパケットのペイロード（図中のV＃1，V＃2，V＃3，V＃4）に格納されることがわかる。またオーディオストリームを構成するAudio Presentation Unitであるオーディオフレームは、矢印aa１，aa２に示すように、個々のPESパケットのペイロード（図中のA＃1，A＃2）に格納されていることがわかる。
【００２３】
図５は、ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示している。下段は、ビデオストリームと、オーディオストリームとを格納した複数のPESパケット（図中のV＃1，V＃2，V＃3，V＃4，A＃1，A＃2）を示す。ビデオストリーム及びオーディオストリームは、別個のPESパケットに格納されることが本図からわかる。上段は、下段のPESパケットを格納したプログラムストリーム及びトランスポートストリームを示す。プログラムストリームに多重化される場合、PESパケットは、１パックに収められる。トランスポートストリームに多重化される場合、PESパケットは分割され、個々の分割部分は、複数のTSパケットのペイロードに格納される。BD-ROMにおける格納方式は、前者のプログラムストリームではなく、後者のトランスポートストリームのものとなる。図５ではそのようになっていないが、トランスポートストリームに使われるビデオPESパケットは１つのフレーム、もしくはペアとなる２つのフィールドを格納するのが一般的である。
【００２４】
図６は、トランスポートストリームの詳細を示す図である。本図における第１段目は、MPEG２トランスポートストリームを構成する複数のTSパケット列であり、第２段目はTSパケットの内部構成を示す。この第２段目に示すように、１つのTSパケットは、“ヘッダ”と、“適用フィールド（adaptation field）”と、“ペイロード”とから構成される。引き出し線th１は、TSパケットヘッダの構成をクローズアップしている。このこの引き出し線に示すように、TSパケットヘッダには、PESパケットの先頭を格納していることを示す「ユニット開始表示（payload_unit_start_indicator）」、トランスポートストリームに多重化されるエレメンタリストリームの種別を示す「PID（Packet Identifier）」、TSパケットに適用フィールドが存在しているか否かを示す「適用フィールド制御」などが存在する。
【００２５】
引き出し線th２は、適用フィールドの内部構成をクローズアップしている。適用フィールドはTSパケットヘッダの適用フィールド制御が“１”に設定されている場合に、TSパケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、エントリーポイントであることを示す「ランダムアクセス表示（random_access_indicator）」、T-STD（Transport System Target Decoder）のSTC（System Time Clock）を与える「PCR（Program Clock Reference）」などが、この適用フィールドに格納される。
【００２６】
図７は、PAT、PMTパケットの内部構成を示す図である。これらのパケットは、トランスポートストリームのプログラム構成を記述するものである。
本図における引き出し線hm１は、トランスポートストリームに存在するPID=０のTSパケットの構成をクローズアップしている。かかるTSパケットは、PAT（Program Association Table）パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。PATパケットのPIDは常に“０”である。PATパケットには、PAS（Program Association Section）が格納される。引き出し線hm２は、PASの内部構成をクローズアップしている。この引き出し線に示すようにPASは、program_number（番組番号）と、program map table（PMTのPID）とを対応付けて示している。引き出し線hm３は、トランスポートストリームに存在するPID=０x１００のTSパケットの構成をクローズアップしている。かかるTSパケットは、PMTパケットと呼ばれる。引き出し線hm４に示すように、PMTパケットのPMSは、そのPMSに対応する番組に含まれるストリーム種別を示す「stream_type」と、そのストリームのPIDである「elementary_PID」とを含む。本図の例では、番組番号＃1の番組は、PID=０x１００のPMTを有しており、PID=０x２００と０x２０１とを有するMPEG２ビデオと、ADTSオーディオとが、この番組番号＃1の番組を構成していることがわかる。このようにして、常にPID=０であるPATからPMTのPIDを取得し、このPMTのPIDからPMTパケットを取得して、PMSを参照することで、トランスポートストリーム中の番組と、その構成ストリームのPIDやストリームタイプとを知得することができる。
【００２７】
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図８は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する１８８バイトのTSパケットは、第２段目に示すように４バイトのTS_extra_header（図中のハッチング部）、が付されて、１９２バイト長のSourceパケットになる。このTS_extra_headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival_Time_Stampを含む。ATSヘッダをTSパケットごとに付与してストリームを形成する理由は、TSパケットごとにデコーダ（STD）への入力時刻を与えるためである。デジタル放送ではトランスポートストリームは固定ビットレートとして扱われる。そのため、NULLパケットと呼ばれるダミーのTSパケットを多重化して固定ビットレートとしたトランスポートストリームを放送している。光ディスクのような限られた記録容量の記録媒体にストリームを記録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である。そのためBD-ROMではNULLパケットを記録することはしない。そして、可変ビットレートの記録方式に対応するため、個々のTSパケットにATSを付与した上でトランスポートストリームを記録する。このATSを用いることで、TSパケットごとにデコーダ入力時刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降、ATSヘッダとTSパケットの１組をソースパケット（Source Packet）と呼ぶ。
【００２８】
AVClipを構成するSourceパケットは、第３段目におけるAVClipにおいて、１つ以上の“ATC_Sequence”を構成する。“ATC_Sequence”とは、Sourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点（no arrival time-base discontinutiy）が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケットを“ATC_Sequence”という。
【００２９】
かかるATC_SequenceがAVClipになり、xxxxx.m２tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、１つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第４段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第４段目においてファイルを構成する各ファイルエクステントは、予め定められたSexetent以上のデータ長を有する。
【００３０】
AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Sexetentを検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Tjump=Taccess+Toverhead
で与えられる。
Taccessは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時間である。
BD-ROMから読み出されたTSパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Rudというビットレートで行われ、ECCブロックにおけるセクタ数をSeccとした場合、
Toverheadは、
Toverhead≦（２×Secc×８）/Rud=２０m秒
という計算で与えられる。
BD-ROMから読み出されたTSパケットは、Sourceパケットの状態でリードバッファに格納された上、TS_Recording_rateという転送レートで、デコーダに供給される。
【００３１】
TS_Recording_rateという転送レートでの、デコーダへのTSパケット供給が跡絶えさせないためには、Tjumpの間、リードバッファからデコーダへのTSパケット出力が継続している必要がある。ここでリードバッファからの出力は、TSパケットではなく、Sourceパケットの状態でなされるので、TSパケットのSourceパケットとのサイズ比を１９２/１８８とした場合、Tjumpの間、（１９２/１８８×TS_Recording_rate）という転送レートにより、リードバッファからのSourceパケット出力が継続している必要がある。
従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Boccupied≧（Tjump/１０００×８）×（（１９２/１８８）×TS_Recording_rate）
となる。
リードバッファへの入力レートはRud、リードバッファからの出力レートはTS_Recording_rate×（１９２/１８８）であるので、リードバッファへの蓄積レートは、入力レート-出力レートの計算で与えられ、（Rud-TS_Recording_rate×（１９２/１８８））になる。
【００３２】
このBoccupiedを、リードバッファに蓄積するのに要する時間Txは、
Tx=Boccupied/（Rud-TS_Recording_rate×（１９２/１８８））
になる。
BD-ROMからの読み出しには、この時間TxにおいてRudでのTSパケット入力を継続する必要があるので、AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Sexetentは、
Sexetent=Rud×Tx
=Rud×Boccupied/（Rud-TS_Recording_rate×（１９２/１８８））
≧Rud×（Tjump/１０００×８）×（（１９２/１８８）×TS_Recording_rate）
/（Rud-TS_Recording_rate×（１９２/１８８））
≧（Rud×Tjump/１０００×８）×
×TS_Recording_rate×１９２/（Rud×１８８-TS_Recording_rate×１９２）
になる。
よって
Sexetent≧
（Tjump×Rud/１０００×８）×
（TS_Recording_rate×１９２/（Rud×１８８-TS_Recording_rate×１９２））
になる。
AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさないように算出されたSextent以上のデータ長をもつことにより、AVClipを構成する各ファイルエクステントが、BD-ROM上において離散的に位置されたとしても、再生時においてデコーダへのTSパケット供給が途絶えさせることなく、連続的に読み出されることになる。
【００３３】
上述したファイルエクステントは、Sourceパケット３２個集めたアラインドユニット（Aligned Unit、６KByteのデータサイズ）を最小単位として構成されている。したがって、BDでのストリームファイル（XXXXX.AVClip）のファイルサイズは常に６KByteの倍数となる。
図９は、Aligned Unitの内部構成を示す図である。Aligned Unitは、３２個のSourceパケットから構成され、連続する３つのセクタに書き込まれる。３２個のSourceパケットからなるグループは、６１４４バイト（=３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（=２０４８×３）と一致する。BD-ROMにおけるセクタは、３２個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unitの単位でBD-ROMをアクセスする限り、３２個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。BD-ROMに記録され、高画質なビデオストリームが多重化されているAVClipを、以下“MainClip”と呼ぶ。これに対し、ローカルストレージに記録され、MainClipと同時に再生されるAVClipを、“SubClip”とよぶ。
【００３４】
BD-ROMに記録されているMainClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々のエレメンタリストリームに対応するものである。MainClipを多重分離することで得られるパーシャルトランスポートストリームであって、１つのエレメンタリストリームに対応するものを“プライマリTS”という。
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル（００００１.clpi，００００２.clpi）は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図１０は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、
i）AVClipについての情報を格納した『ClipInfo（）』、
ii）ATC Sequence，STC Sequenceに関する情報を格納した『Sequence Info（）』
iii）Program Sequenceに関する情報を格納した『Program Info（）』
iv）『Characteristic Point Info（CPI（））』からなる。
【００３５】
ClipInfoには、このClip情報が参照するAVClipのアプリケーションタイプ（application_type）がある。かかるClipInfoを参照することで、アプリケーションタイプによってMainClipかSubClipかや、動画を含んでいるのか静止画（スライドショー）を含んでいるのかなどが識別できる。またClipInfoには、上述したTS_recording_rateが記述されている。
Sequence Infoは、AVClipに含まれる、１つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS，ATSが出現する可能性があり、再生時に不都合が生じる。STC，ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、Sequence Infoは設けられている。
【００３６】
Program Infoとは、Program内容が一定である区間（Program Sequence）を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。Program Sequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSD画像からHD画像に変化している点等をいう。
続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu２はCPIの構成をクローズアップしている。引き出し線cu２に示すように、CPIは、Ne個のEP_map_for_one_stream_PID（EP_map_for_one_stream_PID［０］〜EP_map_for_one_stream_PID［Ne-１］）からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、１つのエレメンタリストリーム上において、Access Unitが存在するエントリー位置のパケット番号（SPN_EP_start）を、エントリー時刻（PTS_EP_start）と対応づけて示す情報である。図中の引き出し線cu３は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。
【００３７】
これによると、EP_map_for_one_stream_PIDは、Nc個のEP_High（EP_High（０）〜EP_High（Nc-１））と、Nf個のEP_Low（EP_Low（０）〜EP_Low（Nf-１））とからなることがわかる。ここでEP_Highは、Access Unit（Non-IDR Iピクチャ、IDRピクチャ）のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、Access Unit（Non-IDR Iピクチャ、IDRピクチャ）のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。
【００３８】
図中の引き出し線cu４は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High（i）は、EP_Lowに対する参照値である『ref_to_EP_Low_id［i］』と、Access Unit（Non-IDR Iピクチャ、IDRピクチャ）のPTSの上位ビットを示『PTS_EP_High［i］』と、Access Unit（Non-IDR Iピクチャ、IDRピクチャ）のSPNの上位ビットを示す『SPN_EP_High［i］』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。
【００３９】
図中の引き出し線cu５は、EP_Lowの構成をクローズアップしている。引き出し線cu５に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point（EP_Low_id）』と、対応するAccess Unitサイズを示す『I_end_position_offset（EP_Low_id）』と、対応するAccess Unit（Non-IDR Iピクチャ、IDRピクチャ）のPTSの下位ビットを示す『PTS_EP_Low（EP_Low_id）』と、対応するAccess Unit（Non-IDR Iピクチャ、IDRピクチャ）のSPNの下位ビットを示す『SPN_EP_Low（EP_Low_id）』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。
【００４０】
以下、具体例を通じて、EP_mapについて説明する。図１１は、映画のビデオストリームに対するEP_map設定を示す図である。第１段目は、表示順序に配置された複数のピクチャ（MPEG４-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ）を示し、第２段目は、そのピクチャにおける時間軸を示す。第４段目は、BD-ROM上のTSパケット列を示し、第３段目は、EP_mapの設定を示す。
【００４１】
第２段目の時間軸において、時点t１〜t７に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt１〜t７の時間間隔が、１秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t１〜t７をエントリー時刻（PTS_EP_start）として示し、これに対応づけてエントリー位置（SPN_EP_start）を示すよう、設定される。
続いて、PlayList情報について説明する。拡張子“mpls”が付与されたファイル（００００１.mpls）は、PlayList（PL）情報を格納したファイルである。
【００４２】
図１２は、PlayList情報のデータ構造を示す図であり、本図において、引き出し線mp１に示すようにPlayList情報は、MainPathを定義するMainPath情報（MainPath（））と、チャプターを定義するPlayListMark情報（PlayListMark（））を含む。
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
【００４３】
MainPathは、矢印mp１で示すように複数のPlayItem情報＃1・・・・＃mから定義される。PlayItem情報は、MainPathを構成する１つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs１によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVClipの符号化方式を示す『Clip_codec_identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItem（カレントPlayItem）と、その１つ前のPlayItem（previousPlayItem）との接続状態を示す『connection_condition』と、このPlayItemが対象としているSTC_Sequenceを一意に示す『re_to_STC_id［０］』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO_mask_table』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem_random_access_flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still_mode』と、『STN_table』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『In_time』、再生区間の終点を示す時間情報『Out_time』の組みであり、再生経路情報とは、この『In_time』及び『Out_time』の組みから構成される。
【００４４】
図１３は、AVClipと、PlayList情報との関係を示す図である。第１段目は、PlayList情報がもつ時間軸（PlayList時間軸）を示す。第２段目から第５段目は、EP_mapにて参照されているビデオストリームを示す。
PlayList情報は、PlayItem情報＃1，＃2という２つのPlayItem情報を含んでおり、これらPlayItem情報＃1，＃2のIn_time，Out_timeにより、２つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第１段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。
【００４５】
以上が、BD-ROM１００についての説明である。
続いて、本発明にかかる記録媒体である、ローカルストレージ２００について説明する。図１４は、ローカルストレージ２００の内部構成を示す図である。本図に示すように、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。
【００４６】
本図の第４段目にローカルストレージ２００を示し、第３段目にローカルストレージ２００上のトラックを示す。本図のトラックは、ローカルストレージ２００の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてローカルストレージ２００の応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。
【００４７】
本図のディレクトリ構造においてROOTディレクトリの配下には、「organization＃1」というサブディレクトリがあり、その配下に、「disc＃1」というサブディレクトリがある。ディレクトリ「organization＃1」とは、映画作品の特定のプロバイダに割り当てられたディレクトリである。「disc＃1」は、そのプロバイダが提供したBD-ROMのそれぞれに割り当てられたディレクトリである。
【００４８】
特定のプロバイダに対応するディレクトリに、各BD-ROMに対応するディレクトリを設けることにより、各BD-ROMについてのダウンロードデータが個別に格納される。このサブディレクトリの配下に、BD-ROMに格納されていたのと同様、PlayList情報（００００２.mpls）、Clip情報（００００３.clpi，００００４.clpi）、AVClip（００００３.m２ts，００００４.m２ts）が格納されている。
続いて、ローカルストレージ２００の構成要素となる、PlayList情報、Clip情報、AVClipについての説明する。
【００４９】
ローカルストレージ２００上のAVClip（００００３.m２ts，００００４.m２ts）は、SubClipを構成する。このSubClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。SubClipを多重分離することで得られるパーシャルトランスポートストリームを“セカンダリTS”という。かかるセカンダリTSは、Out_of_MUXアプリケーションを構成するものである。以降、Out_of_MUXアプリケーションについて説明する。
（Out-of-MUXアプリケーション）
Out-of-MUXアプリケーションとは、例えば、BD-ROM上のプライマリTSと、ネットワークなどを介して取得して、ローカルストレージに記録されたセカンダリTSの２つのTSを同時に再生選択することで、この２本のTS間で様々なエレメンタリストリームの組み合わせを可能とするアプリケーションである。
【００５０】
図１５は、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ装置、ローカルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPID Filterを示す。そして本図におけるプライマリTS（Video１，Audio１（English），Audio２（Spanish），PG１（English Subtitle），IG１（English Menu））、セカンダリTS（Audio２（Japanese），Audio３（Korean），PG２（Japanese Subtitle），PG３（Korean Subtitle），IG２（Japanese Menu），IG３（Korean Menu））は、それぞれD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio１）とスペイン語（Audio２）しか記録されていないため、日本語吹き替えなどをこのディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供する日本語吹き替え（Audio２）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、日本語吹き替え音声（Audio２）と、日本語字幕（PG２）と、日本語メニュー画面（IG２）とを、デコーダに送り込むことができる。こうすることでユーザーは、日本語吹き替え音声（Audio２）と、日本語字幕（PG２）とを、日本語メニュー画面（IG２）から選択して、映像（Video１）と共に再生することができる。
【００５１】
Out-of-MUXアプリケーションは、同時に再生される２つのTSの中に格納されたエレメンタリストリームの種別ごとに１つまで（言い換えれば、プライマリTSとセカンダリTSに格納されているビデオ１本、オーディオ１本、字幕１本、メニュー１本まで）という制限下で、ユーザーが自由に、音声及び字幕を選択することができる。
全てのBD-ROM再生装置はプライマリTS単体をデコードできる能力は持つが、２つのTSを同時にデコードする能力はない。したがって、Out-of-MUXアプリケーションを制限なく導入した場合には、ハードウェアの大規模化や、ソフトウェアを多く追加せざるを得なくなり、BD-ROM再生装置のコストアップに繋がる。そのため、Out-of-MUXアプリケーションの実現にあたっては、プライマリTSだけをデコードできるリソース上で、Out_of_MUXのアプリケーションを実現することができるかどうかどうかが鍵となる。
【００５２】
エレメンタリストリームの種別ごとに１つまで、再生を許可するという制限は、プライマリTSのエレメンタリストリームをセカンダリTSのエレメンタリストリームで「入れ換える」と考えればよい。そのようにすることで、１本のTSをデコードするリソース上で、Out_of_MUXアプリケーションを実現することができ、デコーダ側のコストアップを抑制することができる。本図の例では、プライマリTSのオーディオ、字幕（PG）、メニュー（IG）ストリームをセカンダリTSのそれらと入れ換えている。
【００５３】
セカンダリTSは、上述したようなローカルストレージである内蔵HDDの他、フラッシュメモリや一次記憶メモリ、ネットワーク越しのHDDや直接ネットワークを介したストリーミングなどから入力されることもある。説明の便宜上、セカンダリTSは、図１に示したような内蔵型のHDDから供給されるものとする。
ローカルストレージ上に存在するClip情報（００００３.clpi，００００４.clpi）は、基本的には、BD-ROMに記録されているものと同じデータ構造をもつ。ここでローカルストレージ上のClip情報のTS_Recording_Rateは、BD-ROMからのAVClip読み出しと同じビットレートに設定されている。つまりSubClipのClip情報に記述されたTS_Recording_Rateと、MainClipのClip情報に記述されたTS_Recording_Rateとは同一である。仮に、MainClipのTS_Recording_Rateの値と、SubClipのTS_Recording_Rateとが異なると、夫々のSource De-packetizerから、バッファに送り込むまでのデータレートがどちらのTSを送り込むかによって異なることになり、Out-of-MUXアプリケーションは１つの入力TSと仮定できるという仮定が成り立たなくなる。
【００５４】
また、２つのTS間で再生されるべきエレメンタリストリームは、自在に選択されるので、プライマリTSのオーディオが選択されればSource De-packetizerからデコーダ内のバッファまでが、プライマリTS用のビットレートに設定され、セカンダリTSのオーディオが選択されるとSource De-packetizerからデコーダ内のバッファまでが、セカンダリTSのためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑になってしまうからである。
続いて、ローカルストレージ２００上のPlayList情報について説明する。拡張子“mpls”が付与されたファイル（００００２.mpls）は、MainPath、Subpathと呼ばれる２種類の再生経路を束ねたものをPlaylist（PL）として定義する情報である。図１６は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報（MainPath（））と、チャプターを定義するPlayListMark情報（PlayListMark（））と、Subpathを定義するSubpath情報（Subpath（））とからなる。かかるPlayList情報の内部構成、及び、PlayItem情報の内部構成は、BD-ROMのものと同じであり、説明を省略する。以降、Subpath情報について説明する。
MainPathが、主映像たるMainClipに定義される再生経路であるのに対し、Subpathは、MainPathと同期すべきSubClipに対して定義される再生経路である。
【００５５】
図１７は、Subpath情報の内部構成をクローズアップして示す図である。本図における矢印hc０に示すようにSubpath情報は、SubClipの類型を示すSubPath_typeと、１つ以上のSubPlayItem情報（・・・SubPlayItem（）・・・）とを含む。
図中の引き出し線hc１は、SubPlayItem情報の構成をクローズアップしている。SubPlayItem情報は、図中の矢印hc１に示すように『Clip_information_file_name』、『Clip_codec_identifier』、『SP_connection_condition』、『ref_to_STC_id［０］』、『SubPlayItem_In_time』、『SubPlayItem_Out_time』、『sync_PlayItem_id』、『sync_start_PTS_of_PlayItem』からなる。
【００５６】
『Clip_information_file_name』は、Clip情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip_codec_identifier』は、AVClipの符号化方式を示す。
『SP_connection_condition』は、このSubPlayItem（カレントSubPlayItem）と、その１つ前のSubPlayItem（previousSubPlayItem）との接続状態を示す。
【００５７】
『ref_to_STC_id［０］』は、このPlayItemが対象としているSTC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。
『SubPlayItem_Out_time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
【００５８】
『sync_PlayItem_id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem_In_timeは、このsync_PlayItem_idで指定されたPlayItemの再生時間軸上に存在する。
『sync_start_PTS_of_PlayItem』は、sync_PlayItem_idで指定されたPlayItemの再生時間軸上において、SubPlayItem_In_timeで指定されたSubPlayItemの始点が、どこに存在するかを示す。
【００５９】
ここでの三者とは、ローカルストレージ２００上のSubClip、ローカルストレージ２００上のPlayList情報、BD-ROM上のMainClipの三者をいう。
図１８は、ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。本図において第１段目は、ローカルストレージ２００上に存在するSubClipを示す。この第１段目に示すように、ローカルストレージ２００上のSubClip内のセカンダリTSには、オーディオストリーム、PGストリーム、IGストリームといった種別がある。これらのうち何れかが、SubPathとして同期再生に供されることになる。
【００６０】
第２段目は、PlayList情報により定義される２つの時間軸を示す。第２段目のうち下側の時間軸は、PlayItem情報により定義されるPlayList時間軸を示し、上側の時間軸はSubPlayItemにより定義されるSubPlayItem時間軸を示す。
本図に示すように、SubPlayItem情報のSubPlayItem_Clip_information_file_nameは、SubClipを格納した.m２tsファイルのうち、どれを再生区間の対象として選ぶかという、SubClip選択の役割を果たしていることがわかる。
【００６１】
そしてSubPlayItem.IN_time、SubPlayItem.Out_timeは、SubClip上の、再生区間の始点及び終点を定義するという役割を果たしていることがわかる。
矢印Sync_PlayItem_Idは、どのPlayItemとの同期を意図しているかという同期指定の役割を果たし、sync_start_PTS_of_PlayItemは、PlayList時間軸上におけるSubPlayItem_In_timeの位置を決める役割を果たす。
【００６２】
以上が、SubPath情報についての説明である。
このローカルストレージ２００上のPlayList情報において特徴的であるのは、STN_Tableである。以降、ローカルストレージ２００上のPlayList情報について説明する。
STN_tableは、PlayItem情報のClip_Information_file_nameで指定されているMainClipに多重化された複数エレメンタリストリーム、及び、SubPlayItem情報のClip_Information_file_nameで指定されたSubClipに多重化されている複数エレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示すテーブルである。PlayList情報におけるSTN_Tableにおいて、同時に再生することが許可されている複数エレメンタリストリームは、いわゆる“システムストリーム”を構成することになる。
【００６３】
具体的にいうとSTN_tableは、MainClipに多重化されている複数エレメンタリストリーム、SubClipに多重化されているエレメンタリストリームのそれぞれについてのStream_entryを、Stream_attributeと対応付けることで構成される。
図１９（a）は、STN_tableの内部構成を示す図である。本図に示すようにSTN_tableは、STN_tableにおけるentryと、attributeとの組み（entry-attribute）を複数含み、これらentry-attributeの組みの個数（number_of_video_stream_entries，number_of_audio_stream_entries，number_of_PG_stream_entries，number_of_IG_stream_entries）を示すデータ構造になっている。
【００６４】
entry-attributeの組みは、図中の括弧記号”｛”に示すように、Play Itemにおいて再生可能なビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのそれぞれに対応している。
entry-attributeの詳細について説明する。
【００６５】
図１９（b）は、ビデオストリームに対応したStream_attributeを示す図である。
ビデオストリームにおけるStream_attributeは、ビデオストリームの表示方式を示す『Video_format』と、ビデオストリームの表示周波数を示す『frame_rate』等を含む。
図１９（c）は、オーディオストリームに対応したStream_attributeを示す図である。
オーディオストリームにおけるStream_attributeは、オーディオストリームの符号化方式を示す『stream_coding_type』と、対応するオーディオストリームのチャネル構成を示す『audio_presentation_type』と、対応するオーディオストリームのサンプリング周波数を示す対応する『Sampling_frequency』と、オーディオストリームの言語属性を示す『audio_language code』からなる。
【００６６】
図１９（d）は、ビデオストリームにおけるStream_entryを示す図である。本図に示すように、ビデオストリームのStream_entryは、ビデオストリームの多重分離に用いられるPIDを示す「ref_to_Stream_PID_of_Main_Clip」を含む。
MainClipにて多重化されているオーディオストリーム、IGストリーム、PGストリームのStream_attributeは、この図１９（d）の形式になっている。
【００６７】
STN_tableは、BD-ROMから読み出されるエレメンタリストリーム、ローカルストレージから読み出されるエレメンタリストリームのうち、再生が許可されているものを示すが、かかるSTN_tableが、無制限に、エレメンタリストリームの再生を許可しているとなると、デコーダシステムの破綻を招く恐れがある。
【００６８】
その理由は、以下の通りである。MPEG２のデコーダシステム標準によると、１つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせるための基本原則である。一方、BD-ROMにおけるストリームの再生が許可されると共に、ローカルストレージにおけるストリームの再生が許可されており、BD-ROMからのAVClip再生と、ローカルストレージからのAVClip再生とを同時に実行する場合、BD-ROMからのTSパケットと、ローカルストレージからのTSパケットとにオーバーラップが生じてしまう。
【００６９】
そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課している。
デコードエレメンタリストリームとは、STN_tableにおいて再生が許可されていて、一緒に再生するため、選択されたビデオストリーム、オーディオストリーム、PGストリーム、IGストリームである。デコードエレメンタリストリームには、ローカルストレージからの読み出されるものと、BD-ROMから読み出されるものの両者がある。
【００７０】
デコードエレメンタリストリームに課される制限とは、STN_tableにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないAVClip（MainClip，SubClip）を構成するTSパケット（Decoding TSパケット）の、１秒当たりのビット量は４８Mbit以下になるというものである。
この１秒という単位時間は、“Window”と呼ばれ、ATC Sequenceの時間軸上の任意の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのような１秒の期間においても、この４８Mbit以下という条件を満たす必要がある。
【００７１】
図２０は、BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。本図の第１段目は、BD-ROMから読み出された複数のTSパケット、第３段目は、ローカルストレージから読み出された複数のTSパケットを示す。これら第１段目、第３段目のTSパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構成するTSパケット（Decoding TSパケット）である。本図における第２段目は、第１段目に示したDecoding TSパケット、第３段目に示したDecoding TSパケットのうち、１秒という期間に属すものを示す。上述したように、MPEG２のデコーダシステム標準によると、１つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。しかし、本図によると、ATC時間軸において、TSパケット間のオーバーラップrp１，rp２，rp３が発生していることがわかる。このように、Windowという単位時間において、TSパケット動作のオーバーラップが許容されているのである。しかし、MPEG２のデコーダシステム標準にはない別の要件が課されている。それが上述した、１Window当たり４８Mbit以下という制限である。第４段目は、この第２段目に示す、Decoding TSパケットが満たすべき条件を数式で表している。この数式の意味は、上述したDecoding TSパケットの個数を、ビット数に換算した値（TSパケットのバイト数である１８８をかけ、ビット数８で表した値）が、４８Mbit以下になるというものである。
【００７２】
任意の１秒という期間において、Decoding TSパケットに以上のような条件を課すのが、本実施形態におけるビット量の制限である。Out_of_MUXアプリケーションのためのオーサリング時には、Sourceパケット列において、かかるWindowを、１パケットずつシフトさせつつ、１秒という期間内の、Decoding TSパケットのビット数が、４８Mbit以下という制限を満たすかどうかをチェックする。もし、制限を満たせば、次のTSパケットにWindowをシフトさせ、制限を満たさねば、BD-ROM規格に違反していると断定する。そして、かかるシフトを繰り返した結果、WindowのOut_Timeが、最後のSourceパケットに達すれば、当該Sourceパケットは、BD-ROM規格に整合しているとの判定を下す。
【００７３】
TSパケットのそれぞれには、２７MHzの時間精度をもつATSが付与されている。ATC時間軸上の座標は、１/２７，０００，０００秒という時間精度をもつが、このATC時間軸上の各座標に、ATSが存在するとは限らない。ATC時間軸には、ATSがまったく存在しない期間や、ATSが存在する期間が不規則に現れる。ATSの出現にバラツキがあるので、Windowをシフトするにあたって、In_Timeから１秒後にATSが存在しない場合、WindowのOut_Timeをどのように調整するかが問題になる。
【００７４】
WindowのOut_Timeは、原則としてIn_Timeの１秒として設定される。ここでATC時間軸において、In_Timeの１秒後にあたる座標にATSが存在すれば、In_Time+１秒の座標を、Out_Timeとする。もしIn_Timeの１秒後にあたる座標にATSが存在しなければ、In_Time+１秒以降であって、ATSが初めて現れるATC時間軸の座標を、Out_Timeとする。ATSの空白期間を考慮しながらOut_Timeを調整しつつ、Windowをシフトしてゆくので、Windowがシフトする度に、異なるビット値が算出される。In_Timeを１TSパケットずつシフトしてゆき、これに伴いOut_Timeを調整することで、ATC時間軸におけるビット値の遷移を緻密に計算してゆくことができる。
【００７５】
図２１は、Windowのシフトを示す図である。（a）〜（d）のそれぞれのうち、上段はベリファイの対象となるSourceパケット列を示し、下段は、WindowのIn_Time、Out_Timeを示す。同図（a）では、WindowのIn_Timeは、Sourceパケット＃iを指定している。このWindowのIn_Timeから１秒後に存在するTSパケット＃jが、WindowのOut_Timeに設定される。
同図（b）では、WindowのIn_Timeは、Sourceパケット＃i+１を指定している。一方、このWindowのIn_Timeから１秒後において、Sourceパケット＃j+１にあたる座標には、SourceパケットのATSが存在しない。この（b）におけるWindowのOut_Timeは、TSパケット＃jを越えたものになるが、TSパケット＃jの直後に、Sourceパケットが存在しないため、（b）のWindowにおけるビットレートは、（a）のWindowにおけるビットレートより少なくなってしまう。これでは、（b）のWindowは、チェックに値しなくなる。そこで、Out_Timeの調整により、WindowのIn_Timeから１秒以降に初めて現れるTSパケット＃j+２を、WindowのOut_Timeにする。Out_Timeをこのように設定すれば、（b）のWindowは、チェックに値するものとなる。
【００７６】
同図（c）では、WindowのIn_Timeは、Sourceパケット＃i+２を指定している。一方、このWindowのIn_Timeから１秒後には、Sourceパケット＃j+２が位置している。この（c）のWindowは、TSパケットの数が、（b）のWindowにおける数と変わらず、チェックに値しない。故に、この（c）では、チェックが行われず、更にWindowのIn_Timeを進める。
同図（d）では、WindowのIn_Timeは、Sourceパケット＃i+３を指定している。一方、このWindow_In_Timeから１秒後において、Sourceパケット＃j+３にあたる位置には、Sourceパケットが存在しない。そこで上述したようなOut_Timeの調整を行い、WindowのIn_Timeから１秒以降に初めて現れるTSパケット＃j+４を、WindowのOut_Timeとする。こうすることで、Window内のTSパケット数は、（b）と違うものとなり、チェックに値する。
【００７７】
以上のようなWindowシフトを伴う、ビット量チェックをオーサリング時に実行することで、ローカルストレージ及びBD-ROMからTSパケットが読み出され、デコーダに供給されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。
以上のWindowシフトによる保障を、図２２〜図２６の具体例を参照しながら説明する。
図２２の第１段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。横軸は時間軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、BD-ROM及びローカルストレージからの読み出し時のビット量は、破線の曲線のように推移する。
【００７８】
図２２の第２段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのうち、デコーダに供給されるものの合計のデータ量を示す。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量は、STN_tableで許可されたストリームに属するTSパケットの合計量となる。ワーストケースにおいては、合計の転送量が９６Mbit近くになり、このデータ量のTSパケットが供給されると考えられる。グラフの時間軸を、７つのWindowに分割して、個々のWindowにおける供給量と、Window毎の転送許容量とを対比する。
【００７９】
図２２の第３段目は、この図２２の第２段目におけるグラフを１秒という期間で区切ったものであり、図２３（a）（b）は、各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。Windowにおける転送許容量は、１秒当たり４８Mbitであり、０.５秒に換算すれば９６Mbitとなる。図中のパターンpn１のハッチングは、デコーダへのデータ供給量を示す。図中のパターンpn２のハッチングは、Window毎の転送許容量を示す。パターンpn１のハッチングが付された部分の面積が、何れのWindowにおいても、パターンpn２のハッチングが付された部分の面積以下になっている。これは、BD-ROM及びローカルストレージからのデータ供給量が、どのWindowにおいても、Windowにおける転送許容量以下に抑えられていることを意味する。
【００８０】
ATC時間軸上のどの時点においても、１秒当たりのデコーダへの転送許容量は、４８Mbit以下になるので、たとえ局所的に、デコーダへの転送許容量が９６Mbit近くになったとしても、４８Mbit=９６Mbit×０.５秒の計算により、かかる９６Mbitでの転送が０.５秒継続することはありえない。従ってデコーダが、このピークが到来する前に、BD-ROM、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダーフロー又はオーバーフローが生じることはない。
【００８１】
Windowにおける転送許容量、つまり、１秒当たり４８Mbitという数値は、MPEGに準拠したデコーダが、バッファに先読みできる数値を、目安にして定めたものである。バッファに先読みできるデータ量が、もっと大きい場合は、１秒当たりのデータ量を更に大きくしたり、またWindowの時間長を更に長くすることができる。このことから、本発明にかかる数値範囲は、１秒当たり４８Mbitというものに、限定されるべきでない。
【００８２】
以上が、STN_tableにおいて再生が許可されているセカンダリTSにおけるデータ量制限についての説明である。
次に、Out_of_MUXアプリケーションを実現する場合の、PlayItemにおけるconnection_condition情報、及び、SubPlayItemにおけるsp_connection_condition情報の設定について説明する。connection_condition情報のフィールドの値、sp_connection_condition情報のフィールドの値は“１”，“５”，“６”の値を取る事ができ、それぞれ以下のような意味を持つ。
【００８３】
connection_condition=１（CC=１）：このPlayItem（カレントPlayItem）と直前のPlayItem（previousPlayItem）とはシームレス接続される保証がない。つまり、フリーズして再生が途切れることが許容された接続形態（ノンシームレス接続）である。
connection_condition=５（CC=５）： カレントPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームと、previousPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームとがシームレス接続される保証がある。一方、MainClipに多重化されているオーディオストリームについてはこの限りではない。
【００８４】
connection_condition=６（CC=６）： カレントPlayItemとpreviousPlayItemに属するそれぞれのTSストリームは論理的に連続であり（時間軸が連続しており、符号化方式も連続している）、オーディオストリーム、ビデオストリームともにシームレス接続される保証がある。
SubPlayItem＃n内に記述されたsp_connection_condition情報は、次のように定義ができる。
【００８５】
sp_connection_condition情報（SP_CC=１）： このSubPlayItem（カレントSubPlayItem）と直前のSubPlayItem（previousSubPlayItem）とはシームレス接続される保証がない
sp_connection_condition情報（SP_CC=５）：カレントSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームと、previousSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームとがシームレス接続される保証がある。一方、SubClipに多重化されているオーディオストリームについてはこの限りではない。
【００８６】
sp_connection_condition情報（SP_CC=６）： カレントSubPlayItemと、previousSubPlayItemとに属するそれぞれのTSストリームは論理的に連続しており（時間軸が連続しており、符号化方式も連続している）、シームレス接続される保証がある。
Out_of_MUXアプリケーションを実現するPlayItemに対して設定されるべきSubPlayItemは、SubPlayItem内のビデオストリームやオーディオストリーム、またはPGストリームやIGストリームがPlayItem内にあったとしても不整合を起こさないようにすべきである。そのため、全く同一の接続条件となる。つまりPlayItem＃1、PlayItem＃2がCC=１で接続されるならば、それに対応するSubPlayItem＃1、SubPlayItem＃2もCC=１で接続される。同様に、PlayItem＃1、PlayItem＃2がCC=５で接続されるならば、それに対応するSubPlayItem＃1、SubPlayItem＃2もCC=５の条件を満たしながら接続される。
以下、図２４、図２５、図２６を参照しながら、Out_of_MUXアプリケーションを構成するPlayItem、SubPlayItemのIn_Time、Out_Time関係と、connection_condition情報の詳細について説明する。
【００８７】
図２４は、Out_of_MUXを構成するPlayItem、SubPlayItemの接続状態を示す図である。本図における第１段目は、SubClip時間軸であり、第２段目、第３段目は、SubPlayItem時間軸、PlayList時間軸である。第４段目は、MainClip時間軸である。本図において、PlayItem側のconnection_condition情報が“=５”である場合、SubPlayItem側のconnection_condition情報も、SP_CC=５になる。
【００８８】
図２５は、図２４に示した、PlayItemのconnection_condition情報、SubPlayItemのsp_connection_condition情報が“=５”に設定されている場合の、PlayItemにおけるIn_Time、Out_Timeと、SubPlayItemにおけるIn_Time、Out_Timeとの関係を示す図である。第１段目、第４段目は図２４と同じである。図２４に示した２つのPlayItem（PlayItem情報＃1、PlayItem情報＃2）のうち、PlayItem情報＃1のIn_Timeは、時刻t１を表し、Out_Timeは、時刻t２を表す。PlayItem情報＃2のIn_Timeは時刻t３、PlayItem情報＃2のOut_Timeは、時刻t４を表す。
【００８９】
PlayItem側の接続状態がCC=５に設定されていると、SubPlayItemにおけるSync_Start_Pts_of_PlayItemは、PlayItemのIn_Timeと同じ時点を示す。そしてSubPlayItemにおけるIn_Time、Out_Timeは、PlayItemのIn_Time、Out_Timeと同じ時刻を表す。このように、PlayItemのconnection_condition情報が“=５”である場合、SubPlayItemのsp_connection_condition情報も“=５”に設定され、尚且つ、PlayItemのIn_Time、Out_Timeは、SubPlayItemのIn_Time、Out_Timeと同一時点を表す。
【００９０】
PlayItemのIn_Time、Out_Time、SubPlayItemのIn_Time、Out_Timeは、それぞれVideo Presentation Unit、Audio Presentation UnitのPTSを参照している。PlayItemのIn_Time、Out_Timeと、SubPlayItemのIn_Time、Out_Timeとが一致しているということは、PlayItemのIn_Time、Out_Timeで参照されるVideo Presentation Unit、Audio Presentation UnitのPTS値が、SubPlayItemのIn_Time、Out_Timeで参照されるVideo Presentation Unit、Audio Presentation UnitのPTS値と同じであることを意味する。そうすると、プライマリTS、セカンダリTSは、時間長が同じで、オーサリング時においてVideo Presentation Unit、Audio Presentation UnitのPTSが、同じになるよう、エンコードされる必要がある。このようにプライマリTS、セカンダリTSを作成しておくことも、CC=５、SP_CC=５を実現するにあたっての条件になる。
【００９１】
これらの図で明らかになった、シームレス接続点と、カレントPlayItem、カレントSubPlayItemとの関係は以下の通りである。PlayItem情報におけるconnection_condition情報と、SubPlayItem情報におけるsp_connection_condition情報とが同じ接続点でのシームレス接続（CC=５、SP_CC=５）を意図している場合、カレントPlayItem、カレントSubPlayItemは、このシームレス接続点の直後に位置することになる。そのため、シームレス接続点の直後に位置するカレントPlayItemにおいて、その開始点を表すPlayItem.In_Timeは、当該シームレス接続点の直後に位置するカレントSubPlayItemにおいて、その開始点を表すSubPlayItem.In_Timeと一致することになる。
図２６は、PlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値、SubPlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値を示す。第２段目、第３段目は、前図に示したものと同じである。第１段目は、SubPlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第４段目も、PlayItemのIn_TimeからOut_Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第１段目における横軸は時間軸であり、縦軸は時間軸上の各時点におけるSTC値を表す。第１段目におけるSTC値は、SubPlayItem情報＃1のIn_TimeからOut_Timeまでの期間における単調増加zk１と、SubPlayItem情報＃2のIn_TimeからOut_Timeまでの期間における単調増加zk２とからなる。第４段目におけるSTC値は、PlayItem情報＃1のIn_TimeからOut_Timeまでの期間における単調増加zk３と、PlayItem情報＃2のIn_TimeからOut_Timeまでの期間における単調増加zk４とからなる。
【００９２】
PlayItemのIn_Timeは、SubPlayItemのIn_Timeと同じ時点を表すので、上述したグラフにおいて、STCの初期値は同じであり、途中の時点においても同じなる。つまり、PlayItemのIn_TimeからOut_Timeまでに存在する任意の時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC２（i）は、SubPlayItemのIn_TimeからOut_Timeまでに存在する同じ時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC１（i）と同じになる。STC値が同じであると、装置内のSTCカウンタは、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置における制御が簡略化される。
【００９３】
仮に、上述した図２５、図２６の制限に反し、１つのPlayItemに対して２つ以上のSubPlayItemを準備した場合、そのSubPlayItemの境界において、映像や音声が途切れてしまい、PlayItemの途中で再生が一時停止するなどの不便が生じる。また、Out-of-MUXアプリケーションにおいて、プライマリTSをセカンダリTSに入れ換えるという処理を実現する場合、この入れ替えの前後で、STC時間軸を切り替える必要があるので、再生装置における同期制御が複雑化する。一方、PlayItem、もしくはSubPlayItemのIn_Time、Out_Timeを共に、一連続なSTC時間軸に定義した場合、上述したような途切れやトランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、１つのPlayItemに対して同一の開始点、同一の終了点をSubPlayItemにもたせるのである。
【００９４】
ここでPlayItemにおけるIn_Time、Out_Timeと、SubPlayItemにおけるIn_Time、Out_Timeとの一致は、完全に一致していることを要求するのではなく、多少の誤差を許容する趣旨である。このIn_Time、Out_Time間の誤差について説明する。
PlayItemのIn_Time、Out_TimeとなるSTC時刻は、PlayItemがビデオフレームに対して設定される。これに対し、SubPlayItemではオーディオフレームに対して設定されることとなる。何故なら、SubPlayItemは、コメンタリが主用途でビデオストリームが多重化されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションユニットの再生時間長の違いから、開始/終了時刻が合わない。したがって、最低でも、１フレーム未満の誤差を認める必要がある。PlayItem＃nとSubPlayItem＃nの開始/終了時刻に関して、どちらも同一のSTC時間軸に対して、
｜（PlayItem＃n.Out-PlayItem＃n.In）-（SubPlayItem＃n.Out_time-SubPlayItem＃n.In_time｜≦PlayItem＃nの中で最小の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間≦１/６０秒
としても規定する。上記左辺の値は、PlayItem＃nの中で最大の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間（≦１/２５秒）としても良いし、１秒以下などとしても良い。
以上が、PlayItem、SubPlayItemにおけるIn_Time、Out_Timeの関係についての説明である。
【００９５】
次に、connection_condition情報、sp_connection_condition情報について詳しく説明する。CC=５、SP_CC=５の条件を満たすには、AVストリームのレベル、トランスポートストリームのレベル、Video Presentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要がある。
Current PlayItemのconnection_condition情報、及び、sp_connection_condition情報が“５”に設定されていることは、Previous PlayItemで再生されるAVストリームの終了点と、Current PlayItemで再生されるAVストリームの開始点との間に、“Clean Break”が存在することを意味する。
【００９６】
Clean Breakを実現するには、Previous PlayItemで再生されるAVClipと、Current PlayItemで再生されるAVストリームとが、以下の要件を満たさねばならない。
（１）Previous PlayItemで指定されているMainClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccess Unitが、Previous PlayItemのOut_Time以降から排除されていること。
【００９７】
同様に、Previous SubPlayItemで指定されているSubClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccess Unitが、Previous SubPlayItemのOut_Time以降から排除されていること。
（２）Current PlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、Current PlayItemのIn_Timeの前から取り除かれていること。そして、MainClipの最初のAudio Presentation Unitが、STC時間軸のIn_Timeで再生されるSampleを含んでいること。
【００９８】
同様に、Current SubPlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、Current SubPlayItemのIn_Timeの前から取り除かれていること。そして、SubClipの最初のAudio Presentation Unitが、STC時間軸のIn_Timeで再生されるSampleを含んでいること。
（３）Previous PlayItemにて指定されるMainClipを構成する全てのSourceパケットが、Current PlayItemにて指定されるMainClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
【００９９】
同様に、Previous SubPlayItemにて指定されるSubClipの全データが、Current SubPlayItemにて指定されるSubClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
以上が、AVストリームにおいて満たすべき条件についての説明である。続いて、トランスポートストリームのレベルにおいて満たすべき条件について説明する。
ここでCC=５においてシームレス接続の対象となる２つのプライマリTSを、プライマリTS１、プライマリTS２と呼ぶ。SP_CC=５においてシームレス接続の対象となる２つのプライマリTSを、セカンダリTS１、セカンダリTS２と呼ぶ。
【０１００】
図２７は、previousPlayItem、previousSubPlayItemにて参照されているAVClip、カレントPlayItem、カレントSubPlayItemにて参照されているAVClipにおいて、TS１、TS２がどのように特定されるかを示す図である。本図における第４段目は、プライマリTS１、プライマリTS２を示し、第３段目は、previousPlayItem側のMainClip１、カレントPlayItem側のMainClip２を示す。第１段目は、セカンダリTS１、セカンダリTS２を示し、第２段目は、previousSubPlayItem側のSubClip１、カレントSubPlayItem側のSubClip２を示す。
【０１０１】
プライマリTS１は、MainClip１において、ハッチングが付されたデータから構成される。MainClip１におけるハッチングが付されたデータは、Previous PlayItemにおけるIn_Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In_Timeが参照しているVideo Presentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、MainClip１の最後のパケットで終わる。
【０１０２】
プライマリTS２は、MainClip２においてハッチングが付されたデータから構成される。MainClip２においてハッチングが付されたデータは、MainClip２の最初のSourceパケットから始まる。そしてMainClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、Current PlayItemのOut_Timeで参照されるVideo Presentation Unit，Audio Presentation Unitの末尾に位置するSourceパケットである。
【０１０３】
セカンダリTS１は、SubClip１において、ハッチングが付されたデータから構成される。SubClip１におけるハッチングが付されたデータは、previousSubPlayItemにおけるIn_Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In_Timeが参照しているVideo Presentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、SubClip１の最後のパケットで終わる。
【０１０４】
セカンダリTS２は、SubClip２においてハッチングが付されたデータから構成される。SubClip２においてハッチングが付されたデータは、SubClip２の最初のSourceパケットから始まる。そしてSubClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、カレントSubPlayItemのOut_Timeで参照されるVideo Presentation Unit，Audio Presentation Unitの末尾に位置するSourceパケットである。
【０１０５】
以上の説明から、CC=５、SP_CC=５において、接続すべき２つのトランスポートストリームが、MainClip、SubClip内に、どのように配置されるかがわかる。previousPlayItem側のMainClipは、previousPlayItemのOut_Timeで参照されるVideo Presentation Unit、Audio Presentation Unitで終わっていなければならず、カレントPlayItem側のMainClipも、カレントPlayItemのIn_Timeで参照されるVideo Presentation Unit、Audio Presentation Unitで始まらなければならない。この関係は、previousSubPlayItemの同様であり、previousSubPlayItem側のSubClipは、previousSubPlayItemのOut_Timeで参照されるAudio Presentation Unitで終わっていなければならず、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのIn_Timeで参照されるAudio Presentation Unitで始まらなければならない。これは上述したように、previousSubPlayItemのOut_Timeから参照されるVideo Presentation Unit、Audio Presentation Unit以降に、余分なAudio Presentation Unitは存在してはならないからである。一方、previousSubPlayItem側のSubClipは、previousSubPlayItemのIn_Timeで参照されるAudio Presentation Unitで始まる必要はなく、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのOut_Timeで参照されるAudio Presentation Unitで終わる必要はない。
【０１０６】
以上の図２４、図２７から、プライマリTS、セカンダリTSは、同じ時間長に構成され、Video Presentation Unit、Audio Presentation UnitのPTS値が同一値になるように作成されねばならない。更にpreviousPlayItem側のMainClip、previousPlayItem側のSubClipは、Out_TimeにあたるVideo Presentation Unit、Audio Presentation Unitで終わるよう、多重化されねばならず、カレントPlayItem側のMainClip、カレントPlayItem側のSubClipは、In_TimeにあたるVideo Presentation Unit、Audio Presentation Unitで開始するよう、多重化されねばならない。
【０１０７】
そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
・TS１とTS２におけるプログラム数が１つであること
・ビデオストリームの数が１つであること
・オーディオストリーム数が同じであること
・Previous PlayItemにおけるSTN_tableと、Current PlayItemにおけるSTN_tableとは同じ内容になること
・個々のPlayItemにおけるトランスポートストリームの再生期間は３秒
以上が、CC=５、SP_CC=５で２つのストリームを接続するにあたってトランスポートストリームのレベルで満たすべき条件である。続いて、Video Presentation Unit、Audio Presentation Unitのレベルで満たすべき条件について説明する。
CC=５とは、本来、別々である筈のプライマリTS１たるビデオストリームの最後のVideo Presentation Unitの開始時刻と、プライマリTS２たるビデオストリームの最初のVideo Presentation Unitの終了時刻とを一致させることをいう。Video Presentation Unitの終了時刻・開始時刻を一致させようとすると、かかるVideo Presentation Unitと同期再生すべきAudio Presentation Unitの扱いが問題になる。何故なら、ビデオと、オーディオとではサンプリング周波数が異なり、Video Presentation Unit、Audio Presentation Unitの時間長は一致しないからである。
【０１０８】
図２８は、CC=５、及び、SP_CC=５の詳細を示す図である。第１段目〜第３段目は、SubPlayItemにおけるconnection_conditionを示し、第４段目〜第７段目は、PlayItemにおけるsp_connection_conditionを示す。第４段目は、TS１、TS２における複数のVideo Presentation Unitを示し、第５段目は、TS１におけるAudio Presentation Unit、TS２におけるAudio Presentation Unitを示す。第６段目は、MainClipにおけるSTCの値を示す。第７段目は、MainClipにおけSourceパケット列を示す。
【０１０９】
本図において、ハッチングが付されているのは、TS１側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットであり、ハッチングが付されていないのは、TS２側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットである。
本図においてCC=５とは、Video Presentation Unit境界を一致させるものの（第４段目）、MainClipのATCにおいてギャップがあり（第７段目）、MainClipのAudio Presentation Unitでオーバラップが存在する（第５段目）状態をいう。SP_CC=５とは、SubClipのATCにおいてギャップがあり（第１段目）、SubClipのAudio Presentation Unitでオーバラップが存在する（第２段目）状態をいう。
【０１１０】
上述したVideo Presentation Unitの境界とは、TS１側から見ればと、４段目における最後のVideo Presentation Unitの終了点PTS１（１stEnd）+Tppにあたり、TS２側から見れば、第４段目におけるVideo Presentation Unitの開始点PTS２（２ndSTART）にあたる。
TS１のうち、境界時点T４に一致するAudio Presentation Unitの終了点をT５a、TS２のうち、時点T４に一致するAudio Presentation Unitの開始点をT３aとした場合、MainClipにおけるオーバラップは、Audio Presentation UnitはT３aからT５aにまでとなる。
【０１１１】
また本図において、SubClipのAudio Presentation Unitは、MainClipのAudio Presentation Unitより長くなっている。これは、SubClipにおけるオーディオストリームはネットワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、そのためAudio Presentation Unit１つ当たりの時間長が長くなるからである。この第１段目におけるSourceパケット列においても、第７段目同様のギャップが存在し、第２段目におけるAudio Presentation Unitにおいても、第４段目と同様のオーバーラップが存在している。SubClipのTS１におけるAudio Presentation Unitのうち、境界時点T４に一致するAudio Presentation Unitの終了点をT５b、SubClipのTS２におけるAudio Presentation Unitのうち、時点T４に一致するAudio Presentation Unitの開始点をT３bとした場合、オーバラップはT３bからT５bまでとなる。
【０１１２】
この図から、CC=５、SP_CC=５を実現するには、Video Presentation Unit、Audio Presentation Unit、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。
（１）TS１におけるオーディオストリームの最後のAudio Presentation Unitは、previousPlayItem、previousSubPlayItemにて指定されるTS１における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。
【０１１３】
（２）TS２におけるオーディオストリームの、最初のAudio Presentation Unitは、カレントPlayItem、カレントSubPlayItemにて指定されるTS２の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。
（３）接続点のAudio Presentation Unit列において、ギャップが存在しない。これは接続点において、Audio Presentation Unit列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、２つのオーディオフレーム再生期間より短い大きさでなければならない。
【０１１４】
（４）TS２の最初のパケットは、PATを含み、１つ以上のPMTがその直後に後続してもよい。PMTがTSパケットのペイロードより大きければ、PMTは、２パケット以上になることもある。PMTを格納したTSパケットには、PCRやSITが存在してもよい。
図２９は、previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudio Presentation Unitと、STC時間軸との関係を示す図である。第１段目は、previousPlayItemが参照しているTS１に帰属する複数のVideo Presentation Unitと、カレントPlayItemが参照しているTS２に帰属する複数のVideo Presentation Unitとを示し、第２段目はpreviousSubPlayItemが参照しているタイムスタンプに帰属している複数のAudio Presentation Unitと、カレントSubPlayItemが参照しているTS２に帰属する複数のAudio Presentation Unitとを示す。第３段目は、previousSubPlayItemのTS１におけるSTC時間軸と、カレントSubPlayItemのTS２におけるSTC時間軸とを示す。第２段目に示すTS１におけるAudio Presentation Unit、TS２におけるAudio Presentation Unitのうち、TS２に属するAudio Presentation Unitの開始点T３bから、TS２に該当するAudio Presentation Unitの終了時刻T５bまでがオーバラップになるのは、図２８に示した通りである。そしてカレントSubPlayItemのIn_Time、previousSubPlayItemのOut_Timeは、それぞれ、Video Presentation Unitの境界である時点T４を指定している。カレントPlayItemのIn_Time、SubPlayItemのOut_Timeもまた、Video Presentation Unitの境界である時点T４を指定しているので、PlayItemのIn_Time、Out_Timeは、SubPlayItemのIn_Time、Out_Timeと一致していることになる。このようにpreviousSubPlayItemのIn_Time、カレントSubPlayItemのOut_Timeは、BD-ROMとは異なる記録媒体に記録されているにも拘らず、MainClipにおけるVideo Presentation Unitの境界と一致しており、更にまた、previousPlayItemのOut_Time、カレントPlayItemのIn_Timeと一致していることがわかる。
【０１１５】
以上がVideo Presentation Unit、Audio Presentation Unitレベルの条件についての詳細である。
次に、CC=５、SP_CC=５実現のための、エレメンタリストリームレベルでの符号化条件について説明する。
【０１１６】
個々のエレメンタリストリームのレベルでは、以下の符号化条件を満たす必要がある。
（１）ビデオストリーム
・シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、
・シームレス接続の直前のビデオストリームは、sequence_end_code（MPEG-２ Video時）、end_of_sequence_rbsp（MPEG-４ AVC時）で完了すること、
（２）オーディオストリーム
・同一のPIDをもつオーディオストリームの符号化方式が変わらないこと、
サンプリング周波数や量子化ビット数、チャンネル数などが変わらないこと、
（３）PGストリーム
a）TS１及びTS２におけるPGストリームの数が同一である。
【０１１７】
b）TS１におけるPGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c）TS１における最後のPCSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut_Timeにあたる再生時刻より早い時点を示す。
d）TS２のPGストリームは、Epoch Start，Epoch ContinueタイプのDisplay Setから始まらねばならない。
【０１１８】
e）TS２における最初のPCSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn_Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f）TS２からのSourceパケットが続く、TS１からのSourceパケットの取り出しは、同じシステム時間軸の、STC１、STC２として定義することができ、これらのDTS値/PTS値には重複が存在しない。
（４）IGストリーム
a）TS１及びTS２におけるIGストリームの数が同一である。
【０１１９】
b）TS１におけるIGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c）TS１における最後のICSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut_Timeにあたる再生時刻より早い時点を示す。
d）TS２のIGストリームは、Epoch Start，Epoch ContinueタイプのDisplay Setから始まらねばならない。
【０１２０】
e）TS２における最初のICSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn_Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f）TS２からのSourceパケットが続く、TS１からのSourceパケットの取り出しは、同じシステム時間軸の、STC１、STC２として定義することができ、これらのDTS値/PTS値には重複が存在しない。
previousPlayItemと、カレントPlayItemとをCC=５で接続し、previousSubPlayItemと、カレントSubPlayItemとをSP_CC=５で接続するには、以上のAVストリームのレベル、トランスポートストリームのレベル、Video Presentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならない。
【０１２１】
以上がローカルストレージ２００の構成たるPlayList情報についての説明である。
以上で本発明にかかる記録媒体についての説明を終える。続いて本発明に係る再生装置について説明する。
図３０は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１a、リードバッファ１b，c、ATCカウンタ２a，c，Source Depacketizer２b，d、ATCカウンタ２c，d、STCカウンタ３a，c、PID Filter３b，d、ビデオデコーダ４、Transport Buffer（TB）４a、Multiplexed Buffer（MB）４b、Coded Picture Buffer（CPB）４c、ビデオデコーダ４d、Re-order Buffer４e、スイッチ４f、ビデオプレーン５、オーディオデコーダ９、Transport Buffer６、Elementary Buffer７、デコーダ８、スイッチ１０a，b，c，d、Interactive Graphicsデコーダ１１、Transport Buffer（TB）１１a、Coded Data Buffer（CDB）１１b、Stream Graphics Processor（SGP）１１c、Object Buffer１１d、Composition Buffer１１e、Graphics Controller１１f、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、Transport Buffer（TB）１３a、Coded Data Buffer（CDB）１３b、Stream Graphics Processor（SGP）１３c、Object Buffer１３d、Composition Buffer１３e、Graphics Controller１３f、Presentation Graphicsプレーン１４、Transport Buffer１５a、Elementary Buffer１５b、デコーダ１５c、Transport Buffer１６a、Elementary Buffer１６b、デコーダ１６c、合成部１７、メモリ２１、コントローラ２２、PSRセット２３、PID変換部２４、ネットワーク部２５、操作受付部２６、ローカルストレージ２００から構成される。
【０１２２】
BD-ROMドライブ１aは、BD-ROMのローディング/イジェクトを行い、BD-ROMディスクに対するアクセスを実行する。
リードバッファ（RB）１bは、BD-ROMから読み出されたSourceパケット列を蓄積する。
リードバッファ（RB）１cは、LastPlayタイトルからから読み出されたSourceパケット列を蓄積する。
【０１２３】
ATC Counter２aは、プライマリTSを構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ２bにATCを出力してゆく。
ソースデパケッタイザ（Source De-packetizer）２bは、プライマリTSを構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、各TSパケットのATSに応じてデコーダへの入力時刻を調整する。具体的には、ATC Counter２aが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS_Recording_Rateで、そのTSパケットだけをPID Filter３bに転送する。
【０１２４】
ATC Counter２cは、セカンダリTSを構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ２dにATCを出力してゆく。
ソースデパケッタイザ（Source De-packetizer）２dは、セカンダリTSを構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、ATSに応じてデコーダへの入力時刻を調整する。具体的には、ATC Counter２cが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS_Recording_Rateで、そのTSパケットだけをPID Filter３dに転送する。
【０１２５】
STC Counter３aは、プライマリTSのPCRによってリセットされ、STCを出力する。
PID Filter３bは、MainClip用の多重分離部であり、ソースデパケッタイザ２bから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ９、Interactive Graphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。各デコーダは、PID Filter３bを経由したエレメンタリストリームを受け取って、プライマリTSのPCR（STC１時間軸）に従いデコードから再生の処理を行う。このようにPID Filter３bを通過して各デコーダに入力されるエレメンタリストリームは、プライマリTSのPCRに従って、デコード及び再生に供されることになる。
【０１２６】
STC Counter３cは、セカンダリTSのPCRによってリセットされ、STCを出力する。PIDフィルタ３dは、このSTCを参照して、多重分離を行う。
PID Filter３dは、SubClip用の多重分離部であり、ソースデパケッタイザ２dから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々オーディオデコーダ９、Interactive Graphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。このようにPID Filter３dを通過して各デコーダに入力されるエレメンタリストリームは、セカンダリTSのPCRに従って、デコード及び再生に供されることになる。
【０１２７】
記録媒体の説明で述べたように、PlayItemにおけるIn_Time、Out_Timeは、SubPlayItemにおけるIn_Time、Out_Timeと一致しているので、ATC Counter２aとATC Counter２cとが同一の値（時刻）を刻めば、プライマリTSとセカンダリTSの両方の時間軸が揃うことになり、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSを１本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表すATC時間軸と、デコーダ基準時間軸を表すSTC時間軸とを同期させることができる。
【０１２８】
ATC時間軸の同期により、上述した２つのSource De-packetizerは、それぞれ、BD-ROMからから読み出されたSourceパケット、ローカルストレージからから読み出されたSourceパケットを処理することができる。
STC時間軸の同期により、STC Counter３a，cは、同一の時刻を計時すれば、２つのTSを１つのTSとして処理することができる。再生装置におけるデコーダは、１つのSTC時間軸で動くため、通常のプライマリTSだけの再生時と変わることなく、STC時間の管理を共通化することができる。ビデオデコーダ４、IGデコーダ１１、PGデコーダ１３、システムデコーダ１５c，１６c、オーディオデコーダ９の全てが同一のSTC時間軸で動かせることは、再生装置開発の観点からすると、BD-ROMの再生のみを行う通常の再生装置と、制御が一切変わらないため望ましい制限となる。更にオーサリング時においては、１つのTSの入力タイミングを制御して、バッファ状態を観測すればよいので、オーサリング時の検証も容易になる。
【０１２９】
ビデオデコーダ４は、PID Filter３bから出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込むものであり、Transport Buffer４a、Multiplexed Buffer４b、Elementary Buffer４c、デコーダ４d、Re-order Buffer４e、スィッチ４fから構成される。
Transport Buffer（TB）４aは、ビデオストリームに帰属するTSパケットがPID Filter３bから出力された際、一旦蓄積されるバッファである。
【０１３０】
Multiplexed Buffer（MB）４bは、Transport Buffer４aからElementary Buffer４cにビデオストリームを出力するにあたって、一旦PESパケットを蓄積しておくためのバッファである。
Elementary Buffer（EB）４cは、符号化状態にあるピクチャ（Iピクチャ、Bピクチャ、Pピクチャ）が格納されるバッファである。
【０１３１】
デコーダ（DEC.）４dは、ビデオエレメンタリストリームの個々のフレーム画像を所定の復号時刻（DTS）ごとにデコードすることにより複数フレーム画像を得て、ビデオプレーン５に書き込む。
Re-order Buffer４eは、復号されたピクチャの順序を、符号化順序から表示順序に入れ替えるためのバッファである。
【０１３２】
スイッチ４fは、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのYUV値で表現された画素データにより構成される。
【０１３３】
オーディオデコーダ９は、Transport Buffer６、Elementary Buffer７、デコーダ８から構成され、オーディオストリームのデコードを行う。
Transport Buffer６は、PID Filter３bから出力されたTSパケットを、先入れ先だし式に格納して、オーディオデコーダ８に供する。
Elementary Buffer７は、PID Filter３bから出力されたTSパケットのうち再生されるべきオーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８に供する。
【０１３４】
デコーダ８は、Transport Buffer６に格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
スイッチ１０aは、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットのどちらかを、選択的にビデオデコーダ４に供給する。
【０１３５】
スイッチ１０bは、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットのどちらかを、選択的にInteractive Graphicsデコーダ１１に供給する。
スイッチ１０cは、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのどちらかを、選択的にPresentation Graphicsデコーダ１３に供給する。
【０１３６】
Interactive Graphics（IG）デコーダ１１は、BD-ROM１００又はローカルストレージ２００から読み出されたIGストリームをデコードして、非圧縮グラフィクスをIGプレーン１２に書き込むものであり、Transport Buffer（TB）１１a、Coded Data Buffer（CDB）１１b、Stream Graphics Processor（SGP）１１c、Object Buffer１１d、Composition Buffer１１e、Graphics Controller（Ctrl）１１fから構成される。
【０１３７】
Transport Buffer（TB）１１aは、IGストリームに帰属するTSパケットが一旦蓄積されるバッファである。
Coded Data Buffer（CDB）１１bは、IGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor（SGP）１１cは、グラフィクスデータを格納したPESパケットをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer１１dに書き込む。
【０１３８】
Object Buffer１１dは、Stream Graphics Processor１１cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer１１eは、グラフィクスデータ描画のための制御情報が配置されるメモリである。
Graphics Controller（Ctrl）１１fは、Composition Buffer１１eに配置された制御情報を解読して、解読結果に基づく制御をする。
【０１３９】
Interactive Graphics（IG）プレーン１２は、IGデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。
Presentation Graphics（PG）デコーダ１３は、BD-ROM又はローカルストレージ２００から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentation Graphicsプレーン１４に書き込む。PGデコーダ１３は、Transport Buffer（TB）１３a、Coded Data Buffer（CDB）１３b、Stream Graphics Processor（SGP）１３c、Object Buffer（OB）１３d、Composition Buffer（CB）１３e、Graphics Controller（Ctrl）１３fから構成される。
【０１４０】
Transport Buffer（TB）１３aは、PGストリームに帰属するTSパケットがPIDフィルタ４から出力された際、一旦蓄積されるバッファである。
Coded Data Buffer（CDB）１３bは、PGストリームを構成するPESパケットが格納されるバッファである。
Stream Graphics Processor（SGP）１３cは、グラフィクスデータを格納したPESパケット（ODS）をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてObjectBuffer１３dに書き込む。
【０１４１】
Object Buffer（OB）１３dは、Stream Graphics Processor１３cのデコードにより得られたグラフィクスオブジェクトが配置される。
Composition Buffer（CB）１３eは、グラフィクスデータ描画のための制御情報（PCS）が配置されるメモリである。
Graphics Controller（Ctrl）１３fは、Composition Buffer１３eに配置されたPCSを解読して、解読結果に基づく制御をする。
【０１４２】
Presentation Graphics（PG）プレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
システムデコーダ１５は、セカンダリTSにおけるシステム制御パケット（PATやPMT）を処理しデコーダ全体を制御する。
Transport Buffer１５aは、プライマリTSに存在するシステム制御パケット（PATやPMT）を格納する。
【０１４３】
Elementary Buffer１５bは、システム制御パケットをデコーダ１５cに供する。
デコーダ１５cは、Elementary Buffer１５bに格納されたシステム制御パケットを、デコードする。
Transport Buffer１６aは、セカンダリTSに存在するシステム制御パケットを格納する。
【０１４４】
Elementary Buffer１６bは、セカンダリTSにおけるシステム制御パケットをデコーダ１６cに供する。
デコーダ１６cは、Elementary Buffer１６bに格納されたシステム制御パケットを、デコードする。
メモリ２１は、カレントのPlayList情報やカレントのClip情報を格納しておくためのメモリである。カレントPlayList情報とは、BD-ROMに記録されている複数PlayList情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROM/ローカルストレージに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。
【０１４５】
コントローラ２２は、プレイリスト再生（カレントPlayList情報に従った再生制御のことである）を実行することで、BD-ROMの再生制御を実現する。また上述のようなATS、STCの制御も行なう。この制御にあたってコントローラ２２は、１秒という時間的範囲において、BD-ROM、ローカルストレージ内のSourceパケットを、デコーダ内のバッファに先読みしておく。このような先読みを行うのは、上述したウィンドゥの制限により、アンダーフロー又はオーバーフローが生じないとの保障があるからである。
【０１４６】
PSRセット２３は、再生装置に内蔵されるレジスタであり、６４個のPlayer Setting/Status Register（PSR）と、４０９６個のGeneral Purpose Register（GPR）とからなる。Player Setting/Status Registerの設定値（PSR）のうち、PSR４〜PSR８は、現在の再生時点を表現するのに用いられる。
PID変換部２４は、PSRセット２３に格納されているオーディオストリーム、オーディオストリームのストリーム番号を、STN_Tableに基づき、PID参照値に変換して、変換結果たるPID参照値をPID Filter３b、PID Filter３dに指示する。
【０１４７】
ネットワーク部２５は、本再生装置における通信機能を実現するものであり、URL指定が与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードを実行する。
操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作を示すUser Operation情報をコントローラ２２に通知する。
【０１４８】
以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ２２の実装について説明する。コントローラ２２は、図３１、図３２に示したフローチャートの処理手順をCPUに実行させるプログラムを作成して命令ROMに書き込み、CPUに供することで再生装置に実装することができる。
図３１は、PlayList情報に基づく再生手順のフローチャートである。本フローチャートは、PlayList情報を構成する.mplsファイルを読み込み（ステップS１１）、PlayList情報における先頭のPlayItemをカレントPlayItemにした上で（ステップS１２）、このカレントPlayItemに対して、ステップS１３〜ステップS２５の処理を繰り返すループ構造になっている。このループ構造は、ステップS２３を終了条件としたものであり、カレントPlayItemのIn_Timeに対応するAccess Unitから、カレントPlayItemのOut_Timeに対応するAccess Unitまでを読み出しをBD-ROMドライブに命じ（ステップS１３）、カレントPlayItemにpreviousPlayItemが存在するか否かを判定して（ステップS１４）、判定結果に応じて、ステップS１５の処理、ステップS１６〜ステップS２１の処理を選択的に実行する。具体的には、カレントPlayItemにpreviousPlayItemがなければ（ステップS１４でNo）、PlayItem_In_TimeからPlayItem_Out_Timeまでの再生をデコーダに命じる（ステップS１５）。
【０１４９】
カレントPlayItemにpreviousPlayItemがあれば（ステップS１４でYes）、カレントPlayItemがCC=５であるか否かを判定し（ステップS１６）、CC=５であるなら（ステップS１６でYes）、ステップS１７〜ステップS２０の処理を行う。
上述したpreviousPlayItemが存在する場合、プライマリTSにおけるATC_Sequenceが切り替わることになる。この切替において、ATC_delta１と呼ばれるプライマリTSのためのオフセット値を算出し（ステップS１７）、それまでのATC_SequenceにおけるATC値（ATC１）に、ATC_delta１を加算することにより、新しいATC_SequenceのATC値（ATC２）を得る（ステップS１８）。
【０１５０】
また、上述した、previousPlayItemが存在する場合、プライマリTSにおけるSTC_Sequenceが切り替わることになる。この切り替えにおいて、STC_delta１と呼ばれるオフセット値を求めて（ステップS１９）、それまでのSTC_SequenceにおけるSTC値（STC１）に、STC_delta１を加算することにより（ステップS２０）、新しいSTC_SequenceのSTC値（STC２）を求める。
そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem_In_TimeからPlayItem_Out_Timeまでの再生をデコーダに命じる（ステップS２１）。カレントPlayItemがCC=５でないなら、CC=１、CC=６の処理を行う。
【０１５１】
ステップS１５、ステップS１６〜ステップS２１のどちらかの処理を実行すればステップS２５の処理を実行する。ステップS２５は、カレントPlayItemと同期再生すべきSubPlayItemが存在するかどうかをサーチする処理である。ここでSubPath情報を構成する各SubPlayItemは、Sync_PlayItem_Idという情報を有しており、カレントPlayItemと同期再生すべきSubPlayItemは、このSync_PlayItem_Idが、カレントPlayItemに設定されている。そこでステップS２５では、カレントPlayItemをSync_PlayItem_Idに指定したSubPlayItemが、SubPath情報を構成する複数のSubPlayItemの中に存在するかどうかをサーチする。
【０１５２】
もし存在しない場合、ステップS２２に移行する。ステップS２２は、AVClip時間軸における現在の再生時点（カレントPTM（Presentation TiMe））がカレントPlayItemのOut_Timeに到達したかどうかを判定する（ステップS２２）。到達すれば、ステップS２３に移行する。ステップS２３は、カレントPlayItemがPlayList情報における最後のPlayItemになったか否かの判定であり、最後のPlayItemでなければ、PlayList情報における次のPlayItemを、カレントPlayItemにして（ステップS２４）、ステップS１３に移行する。以上の処理により、PlayList情報における全てのPlayItemに対して、ステップS１３〜ステップS２４の処理が施されることになる。
【０１５３】
図３２は、SubPlayItemにおけるシームレス接続を示すフローチャートである。
ステップS２５においてカレントPlayItemをSync_PlayItem_Idに指定したSubPlayItemが存在すると判定された場合、そのSubPlayItemをカレントSubPlayItemに設定して（ステップS３１）、SubPlayItemのIn_Timeに相当するAccess Unitから、Out_Timeに相当するAccess Unitまでの読み出しをローカルストレージ２００に命じる（ステップS３２）。そしてカレントPlayItemにPrevious SubPlayItemが存在するか否かを判定して（ステップS３３）、判定結果に応じて、ステップS３４、ステップS３５の処理、ステップS３６〜ステップS４１の処理を選択的に実行する。具体的には、カレントPlayItemにPrevious SubPlayItemがなければ（ステップS３３でNo）、カレントPTMが、Sync_Start_Pts_of_PlayItemに到達するのを待ち（ステップS３４）、到達すれば、SubPlayItem_In_TimeからSubPlayItem_Out_Timeまでの再生をデコーダに命じる（ステップS３５）。
【０１５４】
カレントPlayItemにPrevious SubPlayItemがあれば（ステップS３３でYes）、カレントPlayItemがSP_CC=５であるか否かを判定し（ステップS３６）、SP_CC=５であるなら（ステップS３６でYes）、ステップS３７〜ステップS４１の処理を行う。
上述した、previousPlayItemが存在する場合、ATC_Sequenceが切り替わることになる。この切替において、ATC_delta２と呼ばれるセカンダリTSのためのオフセット値を算出し（ステップS３７）、それまでのATC_SequenceにおけるATC値（ATC１）に、ATC_delta２を加算することにより、新しいATC_SequenceのATC値（ATC２）を得る（ステップS３８）。
【０１５５】
ATC_deltaとは、これまで読み出されているトランスポートストリーム（TS１）の最後のTSパケットの入力時点T１から、新たに読み出されたトランスポートストリーム（TS２）の最初のTSパケットの入力時点T２までのオフセット値をいい、“ATC_delta≧N１/TS_recording_rate”という計算式で与えられる。ここでN１は、TS１の最後のビデオPESパケットに後続する、TSパケットのパケット数である。
【０１５６】
また、上述した、previousPlayItemが存在する場合、STC_Sequenceも切り替わることになる。この切り替えにおいて、STC_delta２を求めて（ステップS３９）、それまでのSTC_SequenceにおけるSTC値（STC１）に、STC_delta２を加算することにより（ステップS４０）、新しいSTC_SequenceのSTC値（STC２）を求める。
先行STC_Sequenceにおいて最後に再生されるピクチャの表示開始時刻をPTS１（１stEND）、ピクチャの表示期間をTppとし、後続STC_Sequenceにおいて最初に表示されるピクチャの開始時刻をPTS２（２ndSTART）とした場合、CC=５では、PTS１（１stEND）+Tppの時刻と、PTS２（２ndSTART）の時刻とを一致させる必要があるから、STC_delta２は、
STC_delta２=PTS１（１stEND）+Tpp-PTS２（２ndSTART）
との計算式から算出される。
そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem_In_TimeからPlayItem_Out_Timeまでの再生をデコーダに命じる（ステップS４１）。
【０１５７】
コントローラ２２は、上述したように、STCの変更処理を行うが、再生装置の一般的な実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。フリーラン状態とは、デコーダがSTCとの同期制御を行っていない状態をいう。その後、STC時間軸が設定できる状態まで、STCが復帰すれば、デコーダは、フリーラン状態から、STCとの同期制御へと移行する。一方、ステップS３６においてカレントPlayItemがCC=５でないと判定されたなら（ステップS３６でNo）、CC=１、CC=６の処理を行う。
【０１５８】
以上のように本実施形態によれば、Windowと呼ばれる１秒当たりの転送許容量は、４８Mbit以下に制限されているので、この１秒という期間において、転送許容量が局所的に９６Mbitまであがったとしても、９６Mbit×０.５秒のサイズのTSパケットを、デコーダに先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローすることはない。デジタルストリームにおけるどの期間であっても、データ量は「９６Mbit×０.５秒」以下であり、アンダーフロー又はオーバーフローが生じることなく、TSパケットを供給することができるので、ビデオ又はオーディオの欠落を避けることができる。これによりOut-of-MUXフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。
【０１５９】
また、PlayItemにおけるIn_Time、Out_Timeと、SubPlayItemにおけるIn_Time、Out_Timeとが一致していて、PlayItem側の接続状態がCC=５であるなら、SubPlayItem側の接続状態もSP_CC=５になるので、PlayItemが切り替えられたとしても、多重分離部を再設定することなく、PlayItemからPlayItemへの切り替えと、SubPlayItemからSubPlayItemへの切り替えとを同時に実行することができる。多重分離部が参照するSTC時間軸を同期させつつ、PlayList情報に基づく再生処理を進行させてゆくことができる。
【０１６０】
（第２実施形態）
本実施形態では、先の実施形態で述べた、BD-ROMの製作について、詳しく説明する。先の実施形態に係るBD-ROMは、以下の工程を順次実行することにより、作ることができる。
先ず初めに、BD-ROMをどのような筋書きで再生させるかを決めるかを企画して（企画工程）、動画収録、音声収録等の素材作成を行い（素材作成工程）、企画工程において作成された筋書きから、ボリューム構成情報を作成する（シナリオ作成工程）。
【０１６１】
ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る（素材エンコード工程）。その後、複数のエレメンタリストリームの多重化を行う（多重化工程）。
【０１６２】
こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、BD-ROMの応用層フォーマットに適合させる作業を行い、BD-ROMのボリューム領域に記録すべきデータの全体像（一般にボリュームデータという）を得る（フォーマッティング工程）。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、BD-ROM規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、Clip情報，PlayList情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のfor文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、if文を用いて定義することができる。
【０１６３】
こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う（エミュレーション工程）。このエミュレーション工程では、BD-ROMプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、BD-ROMを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。
【０１６４】
以上の工程を経て、各実施形態に示した記録媒体（BD-ROM）を作ることができる。
映画作品を、BD-ROMコンテンツと、追加コンテンツとで構成する場合は、上述した企画工程からフォーマッティング工程までを実行する。そうして、１つのボリュームデータを構成するAVClip、Clip情報、PlayList情報が得られれば、これらのうち、既にBD-ROMにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバプログラム等で１つのファイルにまとめる。こうした処理を経て、追加コンテンツが得られれば、かかる追加コンテンツをWWWサーバーに供し、再生装置からの要求に応じて、再生装置に送出する。
【０１６５】
先の実施形態で述べたベリファイは、AVClip、Clip情報、PlayList情報が完成し、PlayList情報内のSTN_tableにより、再生すべきエレメンタリストリームが確定した段階、つまり、フォーマッティング工程で実行される。以降、かかるアプリケーションフォーマットを作成するオーサリングシステムについて説明する。
図３３は、第２実施形態にかかるオーサリングシステムの内部構成を示す図である。本図に示すようにオーサリングシステムは、入力装置５１、エンコード装置５２、サーバ装置５３、素材ストレージ５４、BD構成情報ストレージ５５、クライアント装置５６〜５８、マルチプレクサ６０、BDシナリオコンバータ６１、フォーマッタ６２、Verifier６３から構成される。
【０１６６】
入力装置５１は、HD画像、SD画像が収められたビデオカセットを装填し、このビデオカセットを再生して再生信号をエンコード装置５２に出力する。
エンコード装置５２は、入力装置５１から出力された再生信号をエンコードして、ビデオストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得られたエレメンタリストリームは、LANを通じてサーバ装置５３に出力され、サーバ装置５３内の素材ストレージ５４に書き込まれる。
【０１６７】
サーバ装置５３は、素材ストレージ５４、BD構成情報ストレージ５５という２つのドライブ装置からなる。
素材ストレージ５４は、サーバ装置５３の内蔵ディスク装置であり、エンコード装置５２のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ５４は、HDstreamディレクトリ、SDstreamディレクトリといった２つのディレクトリをもち、HD画像をエンコードすることにより得られたエレメンタリストリームはHDstreamディレクトリに書き込まれる。
【０１６８】
BD構成情報ストレージ５５は、BDボリューム構成情報が格納されるドライブ装置である。
マルチプレクサ６０は、素材ストレージ５４内のHDstreamディレクトリ、SDstreamディレクトリに格納されているエレメンタリストリームのうち、BDボリューム構成情報により指定されているものを読み出し、これをBDボリューム構成情報に従い多重化することで、多重化ストリームであるAVClipを得る。
【０１６９】
BDシナリオコンバータ６１は、BD構成情報ストレージ５５に格納されているBDボリューム構成情報をBD-ROMアプリケーションフォーマットに変換することによりBDシナリオを得る。
フォーマッタ６２は、マルチプレクサ６０によりえられたClip、BDシナリオコンバータ６１により得られたBDシナリオを、BD-ROMの応用層フォーマットに適応させる。こうして適応されらBDシナリオから、BD-ROMの原盤や、ローカルストレージに格納されるべきダウンロード用コンテンツが得られる。
【０１７０】
ベリファイ部６３は、シナリオコンバータ６１が生成したPlayList情報内のSTN_tableを参照して、マルチプレクサ６０が得たBD-ROM用のプライマリTS、ローカルストレージ用のセカンダリTSが、Out_of_MUXアプリケーションを実現するため制限を満たすかどうかを判定する。
以上が、オーサリングシステムの内部構成である。以降、オーサリングシステムおけるベリファイ部６３の実装について説明する。
【０１７１】
ベリファイ部６３は、図３４、図３５に示したフローチャートの処理手順をCPUに実行させるプログラムを作成して命令ROMに書き込み、CPUに供することでオーサリングシステム内に実装することができる。
図３４は、プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。本フローチャートは、ステップS１において、Sourceパケット列における最初のSourceパケットのATSを、カレントWindowのIn_Timeに設定した上で、ステップS２〜ステップS７の処理を繰り返すループ構造を有している。このループ構造は、カレントWindowのIn_Timeから１秒以降に存在するATSを、カレントWindowのOut_Timeに設定して（ステップS２）、カレントWindowのIn_TimeからOut_Timeまでに存在するTSパケット数をカウントし（ステップS３）、In_TimeからカレントWindowにおけるビット数を算出して（ステップS４）、そのビット値が４８Mbit以下であるかを判定する処理（ステップS５）を、ステップS６がYesと判定されるまで繰り返すものである。このステップS６は、カレントWindowのOut_Timeが、ATC時間軸における最後のSourceパケットに到達したかどうかの判定であり、もしステップS６がNoであるなら、Sourceパケット列における次のATSを、カレントWindowのIn_Timeにして（ステップS７）、ステップS２〜ステップS６の処理を繰り返す。どれかのWindowで、ステップS５がNoと判定されたなら、BD-ROM規格に違反していると判定される（ステップS９）。全てのWindowでステップS５がYesと判定され、ステップS６がYesと判定されたなら、BD-ROM規格に適合していると判定される（ステップS８）。
【０１７２】
プライマリTS、セカンダリTSは、以上のベリファイを経ているので、プライマリTS、セカンダリTSがそれぞれBD-ROM、ローカルストレージから供給される場合でも、上述したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのそれぞれに、同種のエレメンタリストリームが複数存在する場合、図３５の手順で、ベリファイを行うのが望ましい。図３５に示すベリファイ手順は、図３４におけるステップS３〜ステップS４を、ステップS８１〜ステップS８３に置き換えたものである。
【０１７３】
このステップS８１〜ステップS８３は、カレントWindowが１つ決定される度に、STN_tableにおいて、再生が許可されているエレメンタリストリームを構成するTSパケットのうち、カレントWindowに属するもののビットレートを、エレメンタリストリーム毎に算出して（ステップS８１）、複数のビデオストリーム、複数のオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び（ステップS８２）、ビデオストリームのビットレートの最大値、オーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して（ステップS８３）、その合計量が４８Mbit以下であるかを判定する（ステップS５）ものである。
【０１７４】
同種のエレメンタリストリームは、Out_of_MUXアプリケーションでは、必ず排他的に選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下の通りである。
【０１７５】
（１）WindowのIn_Timeが指し示すTSパケットの先頭
（２）WindowのIn_Timeが指し示すTSパケットの終了
（３）WindowのOut_Timeが指し示すTSパケットの先頭
（４）WindowのOut_Timeが指し示すTSパケットの終了
かかる箇所におけるビット量を重点的にチェックすることで、オーサリングでのベリファイ作業を、より簡略化することができる。
【０１７６】
以上のように本実施形態によれば、セカンダリTSの再生を許可したSTN_tableを作成した際、そのSTN_tableに基づく再生処理で、アンダーフロー又はオーバーフローが生じるかどうかを、オーサリングの段階で、あらかじめ検証しておくことができる。
（第３実施形態）
本実施形態は、PlayItem間、SubPlayItem間の接続に、CC=６という新たな類型を設ける実施形態である。
【０１７７】
CC=６とは、Progressive PlayList情報を構成する複数のPlayItem情報間の接続状態を規定する。Progressive PlayList情報とは、ストリーミングを前提にして再生されるべき複数のAVClipを、１つの再生経路として指定してゆくためのプレイリスト情報である。
Progressive PlayList情報は、ダウンロード/ストリーミングするセカンダリTSを細切れのファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウンロードを待たずに、再生を開始することができる利便がある。
【０１７８】
ストリーミングを前提にしたコンテンツは、短い長さの多くのAVClipにて規定されているので、Progressive PlayList情報は、これら複数AVClipのそれぞれに対応する、多くのPlayItem情報から構成される。一方、細かい単位に分割されたAVClipは、ストリーミングのために分割されたのであって、STC、ATCに不連続点が存在している訳ではない。そのため、CC=５ではない別の状態として、かかるAVClip間の接続状態を規定しておく必要がある。こうして規定された接続状態を、CC=６という。
CC=６である場合、２つのPlayItemから指定されるTS１、TS２と、２つのSubPlayItemから指定されるTS１、TS２とは、以下の条件を満たす必要がある。
【０１７９】
１）TS２におけるビデオストリームは、GOPから始まらなければならない。
２）TS２のオーディオストリームと同じPIDをもつTS１のオーディオストリームとにおいて、接続点におけるAudio Presentation Unit列に、ギャップが存在しない。
TS１のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そして、TS２における同じPIDをもつオーディオストリームは、不完全なAudio Presentation Unitから始まってもよい。複数のPlayItem、複数のSubPlayItemに基づき、これらのTS１、TS２を再生させてゆけば、２つのAudio Presentation Unitから、１つの完結したAudio Presentation Unitが得られる。
【０１８０】
CC=６では実際にはストリームが連続しているため、CC=５の時のようなビデオだけがシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするようなことはなく、全てのエレメンタリストリームがシームレスに接続される。
以上のようにCC=６は、論理的に連続しているストリームを、ストリーミングの都合から、複数の部分に分割した場合の分割境界を意味する。ただし、BD-ROMに記録されるべきストリームは３２個のSourceパケットから構成される必要があるので、１つのSubPlayItemを構成する１つのストリームファイルは、全て、６KByteの倍数になっている必要がある。
【０１８１】
図３６は、CC=６の詳細な説明を示す図である。第１段目は、１本の連続したATC/STC時間を有し、符号化方式も連続しているストリームを格納したファイル（２００００.m２ts）を示す。第２段目は、３つのストリームを格納した格納した３つのファイル（２０００１.m２ts，２０００２.m２t，２０００３.m２ts）を示す。これらの３つのファイルは、第１段目における１本のストリームを、アラインドユニット（６KByte）単位で区切ることで得られた、３つのプライマリTSを格納している。
【０１８２】
図３７は、PlayItemとSubPlayItemの相関を示した図である。第１段目は、PlayList情報における３つのPlayItem（PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3）を示す。これら３つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC=１に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC=５に設定されている。第２段目は、PlayList情報における３つのSubPlayItem（SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3）を示す。これら３つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC=１に設定され、SubPlayItem＃2、SubPlayItem＃3間は、CC=５に設定されている。第３段目は、Progressive PlayList情報における９つのSubPlayItem（SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9）を示す。これら９つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はCC=１に設定され、SubPlayItem＃6、SubPlayItem＃7間は、CC=５に設定され、それ以外は、CC=６に設定されている。Progressive PlayListのSubPlayItemは、CC=６で接続されるが、PlayItemがCC=１、CC=５で接続されるタイミングでは、PlayItemと同様にCC=１、CC=５の条件を満たしながら接続される。
【０１８３】
以上のように本実施形態によれば、PlayItem、SubPlayItemにおける接続状態に、CC=６という新たな類型を導入することで、Progressive PlayList情報を構成するAVClipを短く区切って、ストリームングで供給するという処理を実現することができる。
（第４実施形態）
第１実施形態では、各Windowにおけるビット量を、どのように制限するかについて説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えばよいかを提案する。
【０１８４】
図３８は、プライマリTSを構成するオーディオが、セカンダリTSを構成するオーディオに入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
図３８は、ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的示す図である。第１段目は、プライマリTSを示す。プライマリTSはV、A１、A２（ビデオ１本、オーディオ２本）を格納したTSパケットである。これらのTSパケットは、２種類３本のエレメンタリストリームを多重化して得たものである。
【０１８５】
第２段目は、セカンダリTSを示す。セカンダリTSは、１種類２本のオーディオA３、A４を格納したTSパケットからなる。これらセカンダリTSのTSパケットが多重化される時間帯p３は、デコーダへの入力時間軸を示すATC時間軸上で、プライマリTSのオーディオパケットが多重化された時間帯p１と、プライマリTSを構成するTSパケットが転送されてない時間帯p２とからなる。
【０１８６】
このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されてもデコードすべきエレメンタリストリームのビットレートの和がプライマリTSの許容最大ビットレート（４８Mbps）を超えない保証ができる。図３８の上述した一例は、一番簡単な例で、セカンダリTSにオーディオしかない場合である。
図３９は、オーディオに加えて、字幕（PGストリーム）やメニュー（IGストリーム）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
【０１８７】
本図において、セカンダリTSのパケットの転送が許可される時間帯k３は、
１）プライマリTSにおける同種のパケットの転送時間帯k１
２）プライマリTSの無転送時間帯k２
の和である。
セカンダリTSに格納されている他ストリーム種別（Video、IG、PG等）についても上記１）、２）のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類のストリームの転送時間帯でセカンダリTS内に多重化が可能か判断され、これで不足する場合には、２）のプライマリTSの無転送時間帯を利用して多重化されることが効率的である。
【０１８８】
本実施形態にかかるマルチプレクサ６０の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ６０は、デコーダモデルにおいて、プライマリTSを再生する際のバッファ状態をシミュレートし、プライマリTSにおける各パケットの転送時間帯や、プライマリTSの無転送時間帯を検出する。これらの時間帯を検出すれば、セカンダリTSを構成する各PESパケットが、同種のパケットの転送時間帯や、無転送時間帯に転送されるよう、セカンダリTSを構成する各PESパケットをTSパケットに変換して、各TSパケットに、かかるATSを付す。こうして付されたATSは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリTSを構成する各PESパケットは、図３９に示したように、プライマリTSにおける同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。
【０１８９】
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム形式ではなく、プログラムストリーム形式にする場合、マルチプレクサ６０は、エレメンタリストリームを構成するPESパケットを、パックに変換して、各パックのTSヘッダにSCR（System Clock Reference）を付す。こうして付されたSCRも、ATS同様、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリPS（ローカルストレージから供給されるプログラムストリーム）を構成する各PESパケットは、図３９に示したように、プライマリPS（BD-ROMから供給されるプログラムストリーム）における同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレージから供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種のパケットの転送時間帯や、無転送時間帯を、パック（PESパケット）という大きな時間単位で表現するので、オーサリング時における負担は格段に小さく、実現が容易となる。これは、DVD再生装置において、Out_of_MUXアプリケーションを実現するにあたっての、利点となる。
【０１９０】
以上のように本実施形態によれば、プライマリTSにおける同種のパケットの転送期間、プライマリTSにおける無転送期間を、セカンダリTSを構成するパケットの入力期間に選び多重化を行うので、第１実施形態に示したビット量制限を満たしやすくなる。かかる多重化を第２実施形態に示したオーサリングシステム上で実現することにより、Out_of_MUXアプリケーションを実現するような映画作品を製作しやすくなる。これにより、再生時のオーバフローが生じないような保障をオーサリングの段階で、容易に行うことができる。
（第５実施形態）
本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本アプリケーションは、１つの種別につき、１つのエレメンタリストリームというOut_of_MUXの規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシングアプリケーションはプライマリTSにあたるオーディオストリームと、セカンダリTSにあたるオーディオストリームとを同時に選択し、プライマリTSの音声とセカンダリTSの音声の２つの音声を同時にデコードする点が例外となる。
【０１９１】
図４０は、オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ１a、ローカルストレージ２００、ネットワーク部２５を左側に示し、各デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPID Filterを示す。そして本図におけるプライマリTS（Video１，Audio１（English），Audio２（Spanish），PG１（English Subtitle），IG１（English Menu））、セカンダリTS（Audio３（Commentary），PG２（Japanese Subtitle），PG３（Korean Subtitle），PG４（Chinese Subtitle），IG２（English Menu））は、それぞれBD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio１）とスペイン語（Audio２）しか記録されていないため、映画監督のコメンタリ音声は、このディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供するAudio３（Commnetary）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、英語音声（Audio１）と、Audio３（Commentry）とを、デコーダに送り込むことができる。これらの英語音声（Audio１）と、Audio３（Commentry）とを、デコーダがミキシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像（Video１）と共に再生させることができる。
【０１９２】
Out-of-MUXアプリケーションとの相違は２つのオーディオストリームを同時にデコードする点のみである。如何なるプライマリTSに対しても、ディスク発売後に監督のコメンタリ音声を付加するなどといったことが想定されるため、プライマリTSへのビットレート制限などは好ましくなく、Out-of-MUXと同様にセカンダリTSへの制限を導入する。オーディオミキシングでは、各エレメンタリストリーム（ビデオ、オーディオ、字幕、メニュー）に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソースを２つ必須とする。
【０１９３】
オーディオミキシングアプリケーションを実現するにあたって、プライマリTSにおける属することになるオーディオストリームを、プライマリオーディオストリームといい、セカンダリTSに属することになるオーディオストリームをセカンダリオーディオストリームという。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて説明する。
【０１９４】
プライマリオーディオストリームは、３２本存在し、それらは０x１１００から０x１１１FまでのPIDをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリーム同様、３２本存在し、０x１A００から０x１A１FまでのPIDをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカンダリオーディオストリームのオーディオフレームに、“ダウンミキシング情報”と、“ゲイン制御情報”とからなるメタデータを含む点である。
【０１９５】
“ダウンミキシング情報”は、ダウンミキシングのための情報である。ダウンミキシングとは、音声の再生チャネル数を符号化チャンネル数よりも少なくする変換であり、ダウンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、このダウンミキシングを再生装置に行わせる。５.１chの音声ストリームを２chで再生することなどがダウンミキシングの一例である。
【０１９６】
“ゲイン制御情報”とは、プライマリオーディオストリーム側の音声出力時のゲインを上げ下げする情報であるが、ここでは下げるだけでよい。このようにセカンダリオーディオストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出力をリアルタイムに下げることができる。PrimaryオーディオとSecondaryオーディオを重畳する場合には、あらかじめミキシングされるPrimaryオーディオとSecondaryオーディオの対が分かっているため、２本のオーディオのゲインをリアルタイムに制御する必要は無く、Primaryオーディオのゲインだけを下げてSecondaryオーディオのゲインはそのままにミキシング（重畳）することで十分である。かかるメタデータを配置することで、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避けることができる。以上が、本実施形態におけるオーディオストリームについての説明である。続いて、本実施形態におけるPlayList情報における改良について説明する。
【０１９７】
同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、本実施形態におけるPlayList情報には、再生が許可されている複数プライマリオーディオストリーム、複数セカンダリオーディオストリームの組合せが、各PlayItemのSTN_tableに示されている。
【０１９８】
以降、本実施形態におけるSTN_tableについて説明する。オーディオミキシングアプリケーションを実現するため、STN_tableには、セカンダリオーディオストリームにおけるStream_entryと、Stream_attributeとの組みが、プライマリオーディオストリームにおけるStream_entryと、Stream_attributeとの組みとは別に存在する。そして、セカンダリオーディオストリームにおけるStream_entryと、Stream_attributeとの組みが、Comb_info_Secondary_audio_Primary_audioと対応付けられている。
【０１９９】
（Comb_info_Secondary_audio_Primary_audio）
Comb_info_Secondary_audio_Primary_audioは、そのセカンダリオーディオストリームの再生出力をミキシングすることができる１つ以上のプライマリオーディオストリームを一意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ以外の属性を有しているようなプライマリオーディオストリームの再生時においてのみ、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミキシングの可否を、オーサリング時に設定しておくことができる。
【０２００】
（sp_connection_condition情報）
またPlayList情報において、SubPlayItemのsp_connection_condition情報は、PlayItem情報のconnection_condition情報と同じ値に設定される。よってPlayItem情報のconnection_condition情報が“=５”であるなら、SubPlayItem情報のsp_connection_condition情報もSP_CC=５に設定される。またSubPlayItem情報のIn_Time、Out_Timeは、PlayItem情報のIn_Time、Out_Timeと同じ時点を指し示す。
【０２０１】
以上が本実施形態における記録媒体の改良である。続いて本実施形態に係る再生装置の内部構成について説明する。
図４１は、第５実施形態に係る再生装置の内部構成を示す図である。本図に示すように、TB６、EB７、オーディオデコーダ８は、Audio Mixing Processor（点線で囲まれた部分）に置き換えられている。このAudio Mixing Processorは、プライマリTSとセカンダリTSから２本の音声ストリームを入力し、同時にデコードしてミキシングするものである。その他の構成はOut-of-MUXアプリケーションを実現するための内部構成と同様である。以降、Audio Mixing Processorについて説明する。Audio Mixing Processorは、Transport Buffer６a、６b、EB７a、７b、プリロードバッファ７c、オーディオデコーダ８a、８b、ミキサ９a、９bから構成される。
【０２０２】
Transport Buffer６aは、PID Filter３bから出力された、オーディオストリームのPIDを有するTSパケットを、先入れ先だし式に格納して、オーディオデコーダ８aに供する。
Transport Buffer６bは、PID Filter３dから出力された、オーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８bに供する。
【０２０３】
EB７aは、バッファ６aに格納されたTSパケットを変換することで得られる、PESパケットを格納するバッファである。
EB７bは、バッファ６aに格納されたTSパケットを変換することで得られる、PESパケットを格納するバッファである。
プリロードバッファ７cは、BD-ROM/ローカルストレージから読み出されたファイルsound.bdmvをプリロードしておくためのメモリである。ファイルsound.bdmvとは、メニューに対する操作に出力すべきオーディオデータを格納したファイルである。
【０２０４】
オーディオデコーダ８aは、プライマリTSを構成するPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
オーディオデコーダ８bは、セカンダリTSを構成するPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
【０２０５】
ミキサ９aは、オーディオデコーダ８aから出力されるLPCM状態のデジタルオーディオと、オーディオデコーダ８bから出力されるLPCM状態のデジタルオーディオとをミキシングする。
ミキサ９bは、ミキサ９aから出力されるLPCM状態のデジタルオーディオと、バッファ７cに格納されているサウンドデータとをミキシングする。このサウンドミキサ９bによるミキシングは、クリック音の発音を意図したようなナビゲーションコマンドを、コントローラ２２が解読することでなされる。
【０２０６】
以上が、本実施形態にかかる再生装置についての説明である。
上述したように、オーディオミキシングアプリケーションはプライマリオーディオストリーム、セカンダリオーディオストリームから構成されるので、第２実施形態に示したようなベリファイは、プライマリオーディオストリーム、セカンダリオーディオストリームが同時に読み出された場合を想定して実行される。具体的にいうと、MainClip、SubClipが基準としているATC時間軸において、１ずつWindowを、シフトさせてゆく。このシフトの手順は、図３５のフローチャートに示したものと同じである。そしてATSに示されるATC時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が４８Mbit以下であるかを判定する。４８Mbitを越えていれば、BD-ROM規格に違反していると判定結果を下す。
【０２０７】
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマリオーディオストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに供給する場合でも、１秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、オーディオミキシングアプリケーションを、効率的に作成することができる。そのため、オーディオミキシングアプリケーションを実現するような追加コンテンツを、ローカルストレージにダウンロードして、ローカルストレージからデコーダに供給するという供給態様が可能になるので、BD-ROMの出荷後に、コメンタリを追加するような供給法を容易に実現することができる。
【０２０８】
（第６実施形態）
第１実施形態では、PlayItemにおけるIn_Time、Out_Timeと、SubPlayItemにおけるIn_Time、Out_Timeとを一致させることで、PlayItem間の接続点、及び、SubPlayItemの接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この接続点の一致を要求せず、ある程度の時間差を認める。
【０２０９】
この時間差を認める場合、別の制限が必要になる。PlayItem、SubPlayItem間のシームレス接続において、上述したSTCの変更処理を行うが、この変更処理は、デコーダがフリーラン状態にある場合になされる。この場合、シームレス接続ではSTCが復帰するまで、デコーダは、同期制御に移ることができないので、STC変更を伴うシームレス接続は実装の都合上、頻繁には受け入れられない。したがって、PlayItemとSubPlayItemの両方において連続するCC=５の接続点は所定の時間間隔（例えば３秒程度）を置いて起こるように制限されるべきである。
【０２１０】
図４２は、オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。図４２の第１段目は、PlayList情報における３つのPlayItem（PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3）を示す。これら３つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC=１に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC=５に設定されている。図４２の第２段目は、PlayList情報における３つのSubPlayItem（SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3）を示す。これら３つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC=１に設定され、SubPlayItem＃2、SubPlayItem＃3間は、SP_CC=５に設定されている。図４２の第３段目は、Progressive PlayList情報における９つのSubPlayItem（SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9）を示す。これら９つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はSP_CC=１に設定され、SubPlayItem＃4、SubPlayItem＃5間は、SP_CC=５に設定され、それ以外は、SC=６に設定されている。
【０２１１】
本図において、第２段目のSubPlayItem＃3の開始は、第１段目におけるPlayItem＃3の開始点より３秒前である。同様に、第３段目のSubPlayItem＃5の開始点は、第１段目におけるPlayItem＃3の開始点より３秒前である。
PlayItemと、SubPlayItemとのSTC時間軸切り替えのための時間間隔は、３秒になっているので、STC時間軸の変更が頻繁になり過ぎることはない。
【０２１２】
またCC=１のタイミングはPlayItemに合わせてSP_CC=１で接続される。これはCC=１のノンシームレス接続時にSubPlayItemだけが再生を連続して継続した場合に、PlayItemとSubPlayItemの同期再生がずれていくことを防ぐためでもある。
PlayItemの途中でSubPlayItemをSP_CC=５で接続するという接続形態は、一枚のディスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。
【０２１３】
図４３の第１段目は、劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す。このPlayList情報のうち、PlayItem＃1、PlayItem＃2、PlayItem＃4から構成されるがディレクターズカットであり、PlayItem＃1、PlayItem＃3、PlayItem＃4から構成されるのが劇場公開版である。このように、PlayItem＃1とPlayItem＃4はどちらのバージョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えることができる。図４３の第２段目は、同図の第１段目におけるPlayItem＃1、PlayItem＃2、PlayItem＃4に対応するコメンタリを１つのSubPlayItemとして定義し、PlayItem＃1、PlayItem＃3、PlayItem＃4に対応するコメンタリとを、別のSubPlayItemとして定義する一例を示す。この場合、２つのSubPlayItemのそれぞれにおいて、PlayItem情報＃1、PlayItem情報＃4に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。
【０２１４】
図４３の第３段目は、PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3、PlayItem情報＃4のそれぞれに対応するSubPlayItem（SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3、SubPlayItem＃4）を定義する一例を示す。そしてSubPlayItem＃1と、SubPlayItem＃2及びSubPlayItem＃3との間、SubPlayItem＃2及びSubPlayItem＃3と、SubPlayItem＃4との間は、CC=５で接続するものとする。これらの接続点は、PlayItemにおける接続点と、３秒の時間間隔を設ける。つまりPlayItem＃1が終わる３秒前にコメンタリの方はSubPlayItem＃2とSubPlayItem＃3にCC=５（もしくはCC=６）を使って分岐させている。
【０２１５】
また、PlayItem＃2、PlayItem＃3が終わった３秒後にCC=５（もしくはCC=６）を使ってSubPlayItem＃4に分岐している。SubPlayItem＃2とSubPlayItem＃3の開始、及び、SubPlayItem＃4の開始は、PlayItem＃2とPlayItem＃3の開始、及び、PlayItem＃4の開始から、３秒の時間間隔を置いている。以上の時間間隔を置くことにより、STC時間軸の変更が頻繁になり過ぎることはない。
【０２１６】
厳密には、CC=５は、SubPlayItem＃3からSubPlayItem＃4への復帰の時だけ（ATC/STC時間軸がリセットされるシームレス接続）必要であり、その他はCC=６で代用が可能である。
以上のように本実施形態によれば、PlayItemのIn_Time、Out_Timeと、SubPlayItemのIn_Time、Out_Timeとが一致していないので、ATC Counter２aと２c、およびSTC Counter３aとSTC Counter３cの同期は不要となり、再生装置の設計の余地を広げることができる。
【０２１７】
（第７実施形態）
第６実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリームをBD-ROM、ローカルストレージから同時に読み出しデコーダに供給する場合、プライマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象としたが、本実施形態では、Picture in Picture（PiP）再生アプリケーションを実現する場合におけるビット量制限について説明する。
【０２１８】
PiP再生とは、PlayList情報のMainPath情報により、動画像を構成するMainClipが指定されており、PlayList情報のSubPlayItem情報により、別の動画像を構成するSubClipが指定されている場合、前者の動画像（Primary Video）と、後者の動画像（Secondary Video）とを、同じ画面内に表示するこという。ここでPrimary VideoはHD画像から構成され、Secondary VideoはSD画像から構成される。HD画像は、１９２０×１０８０という解像度を有し、フィルム素材同様、３７５０（もしくは３７５３か３７５４）クロックのフレーム間隔を有する。SD画像は、７２０×４８０という解像度を有し、NTSC素材同様、１５０１クロックの表示間隔、又は、PAL素材同様、１８００クロックのフレーム間隔を有する。
【０２１９】
SD画像の解像度は、HD画像の解像度の約１/４程度なので、HD画像たるPrimary Videoと、SD画像たるSecondary Videoとを同じ画面上に表示すると、Secondary Videoは、Primary Videoに対し、約１/４程度の大きさになる。
ここでSecondary Videoは、監督や出演者のみが登場している動画像であり、Primary Videoにおける映像内容を指さすような演技を行っているものとする。かかる動画像がSecondary Videoであるなら、かかるSecondary Videoの映像内容を、Primary Videoの映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や出演者が指さして、解説しているような、楽しい画面演出を実現することができる。
【０２２０】
Secondary Videoのためのビデオストリーム（セカンダリビデオストリーム）は、PlayList情報のSubPath情報における複数のSubPlayItem情報にて指定される。かかるSubPlayItem情報には、PiP_Position、PiP_Sizeという情報要素が新規に追加される。
“PiP_Position”は、Primary Video再生のための画面プレーン上のX座標、Y座標を用いて、Secondary Videoの再生映像が配置されるべき位置を示す。
【０２２１】
“PiP_Size”は、Secondary Video再生映像の縦サイズ、横サイズを示す。
また、本実施形態においてSubPlayItemのsp_connection_condition情報が“=５”に設定されているということは、カレントSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームと、previousSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームとがシームレス接続される保証があることを意味する。かかるSubPlayItemのsp_connection_condition情報は、PlayItem情報のconnection_condition情報と同じ値に設定されるので、PlayItem情報のconnection_condition情報が“=５”であるなら、SubPlayItem情報のsp_connection_condition情報も“=５”に設定されねばならない。つまりPlayItem側のプライマリビデオストリームがシームレス接続されるなら、SubPlayItem側のセカンダリビデオストリームもシームレス接続されねばならない。またSubPlayItem情報のIn_Time、Out_Timeは、PlayItem情報のIn_Time、Out_Timeと同じ時点を指し示さねばならない。
【０２２２】
以上が、本実施形態における記録媒体の改良である。
続いて、再生装置の改良について説明する。Secondary Videoストリームのデコードを行うべく、本実施形態に係る再生装置のハードウェア構成には、ビデオストリームをデコードするための構成要素がもう一組、追加されている。ここでビデオストリームをデコードするための構成要素とは、Transport Buffer、Multiplexed Buffer、Elementary Buffer、デコーダ、Videoプレーンであり、これらはセカンダリビデオストリームをデコードする。その他、本実施形態に係る再生装置には、以下のScaller、合成部が追加されている。
【０２２３】
Scallerは、SubPlayItem情報のPiP_Sizeに示される縦・横の大きさに基づき、Secondary Videoプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、Scallerによりされた拡大又は縮小された再生映像と、ビデオデコーダにより得られた再生映像とを合成することでPiP再生を実現する。合成部によるPrimary Videoの再生映像と、Secondary Videoの再生映像との合成は、SubPlayItem情報にて規定されている、PiP_Positionに従ってなされる。こうすることにより、Primary Videoの再生映像と、Secondary Videoの再生映像とが合成された合成映像が再生されることになる。この合成部による合成では、クロマキー合成、レイヤ合成等が可能であり、Secondary Videoにおける背景を取り除き、人物部分を抜き出した上で、Primary Videoの再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置についての説明である。
【０２２４】
PiP再生の実現にあたって、プライマリTSたるビデオストリーム（プライマリビデオストリーム）、セカンダリTSたるビデオストリーム（セカンダリビデオストリーム）を同時に読み出し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリームを、ビット量を制限するためのベリファイの対象とする。
【０２２５】
具体的にいうとATC時間軸においてWindowをシフトさせた際、ATSに示されるATC時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が４８Mbit以下であるかを判定する。
【０２２６】
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応するデコーダに供給する場合でも、１秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、PiPアプリケーションを、効率的に作成することができる。
【０２２７】
（備考）
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的
であり、実施する者の主観によることは留意されたい。
【０２２８】
（In_Time、Out_Time）
図２７では、TS１の最後のVideo Presentation UnitをpreviousPlayItemのOut_Timeとして選び、TS２の最初のVideo Presentation UnitをpreviousPlayItem、previousSubPlayItemのIn_Timeとして選んだが、TS１の途中のVideo Presentation UnitをpreviousPlayItemのOut_Timeとして選び、TS２の途中のVideo Presentation UnitをカレントPlayItem、カレントSubPlayItemのIn_Timeとして選んでもよい。この場合、PlayItem、カレントSubPlayItemは、シームレスに接続することができず、CC=１，SP_CC=１として接続せねばならない。
【０２２９】
（PlayList情報全体）
２つのPlayItem間をCC=５で接続しようとする場合、１つのPlayList情報に属する全てのPlayItem情報、全てのSubPlayItem情報は、CC=５として接続せねばならない。
（デコーダへのデータ供給量）
Out_of_MUXにおいて、デコーダへのデータ供給量は必ずしも大きくなる訳ではない。例えば、プライマリオーディオストリームがMainClipであり、CBRのDD（Dolby Digital）と、VBRのMLPとから構成されていて、このMLPが、ローカルストレージから供給されたCBRのDDに置き換えられるものとする。この場合、デコーダへのデータ供給量はかえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。
【０２３０】
（再生時間差）
CC=５、SP_CC=５を実現するにあたって、１つのPlayItemの中での各ビデオストリーム/オーディオストリームの再生時間差も小さいことが望ましい。この差もビデオ１フレーム分（１/６０〜１/２５秒）としても良いし、１秒以下などとしても良いし、全体の再生時間に対する割合（１％以下など）であっても良いし、これら２つを組み合わせたものであっても良い。１つのSubPlayItemの中での各ビデオ/オーディオエレメンタリストリームの再生時間差も同様である。
【０２３１】
１つのPIDに、２つのエレメンタリストリームを格納するケースにおいては、同一PIDで格納される２つのストリームの再生時間長の差は、どちらか再生時間が短いストリームの方の最小再生単位（１フレーム）の再生時間長未満であることが望ましい。かかるケースに該当するのは、Dolby Digital（AC-３）と、MLP（Meridian Lossless Packing）とが、１つのエレメンタリストリームに格納されて、BD-ROMに記録される場合である。
【０２３２】
（追加コンテンツに対する処理）
ローカルストレージ２００にダウンロードされた追加コンテンツは、何ヶ月、何年か経過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
（PIDの代用）
オーディオミキシングアプリケーションの実現時において、プライマリオーディオストリーム、セカンダリオーディオストリームの区別にPIDを用いたが、MPEG２-PSを使う場合には、PESパケットヘッダのstream_idをそれぞれ異なるものにするのが望ましい。
【０２３３】
またプライマリオーディオストリーム、セカンダリオーディオストリームは、２つの音声ストリームが１つのデマルチプレクサでも弁別可能なように、システムストリームレベルにおいて区別されていればよい。もしくは、２つのストリームを１つに束ねる前に、片方の
PIDを重複しないように付け替えておくだけでもよい。
【０２３４】
（プリロード）
クリック音のためのオーディオデータ（ファイルsound.bdmv）のプリロードは、BD-ROMのローディング時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、機器の応答性を高めAVClip再生が途切れにくくすることができる。
【０２３５】
（Java（登録商標）（TM）プラットフォーム）
各実施形態にかかる再生装置に、Java（登録商標）（TM）２Micro_Edition（J２ME）Personal Basis Profile（PBP １.０）と、Globally Executable MHP specification（GEM１.０.２）for package media targetsとをフル実装することでJava（登録商標）（TM）プラットフォームを構成し、BD-Jアプリケーションを再生装置に実行させてもよい。そしてこのアプリケーションの実行にあたって、Out_of_MUXフレームワークを再生装置に実行させてもよい。
【０２３６】
（タイトル）
BD-ROMの装填やユーザ操作、装置の状態に応じてタイトルを選択する“モジュールマネージャ”を再生装置に設けるのが望ましい。BD-ROM再生装置内のデコーダは、この“モジュールマネージャ”によるタイトル選択に応じて、プレイリスト情報に基づくAVClipの再生を行う。
【０２３７】
アプリケーションマネージャは、“モジュールマネージャ”がタイトルの選択を行った際、前のタイトルに対応するアプリケーション管理テーブル（AMT）と、カレントタイトルに対応するAMTとを用いてシグナリングを実行する。このシグナリングは、前のタイトルに対応するAMTには記載されているが、カレントタイトルに対応するAMTには記載されていないアプリケーションの動作を終了させ、前のタイトルに対応するAMTには記載されておらず、カレントタイトルに対応するAMTには記載されているアプリケーションの動作を開始させるという制御を行う。
【０２３８】
（ローカルストレージ内のディレクトリ構成）
各実施形態に示したローカルストレージ内の各領域は、BD-ROMにおけるディスクルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、このBD-ROMを作成した作成者が、ルート認証局から配布を受けたルート証明書を、BD-ROMに割り当てたものである。ディスクルート証明書はたとえばX.５０９の形式で符号されている。X.５０９の仕様は国際電信電話諮問委員会より発行されており、CCITT Recommendation X.５０９（１９８８），″The Directory-Authentication Framework″に記載されている。
【０２３９】
また、BD-ROM、ローカルストレージの記録内容は、Advancend Access Content System（AACS）にて暗号化され、署名情報が付されて、利用権限が、パーミッションファイルに規定されているのが望ましい。
（実装すべきパッケージ）
BD-ROM再生装置を、Java（登録商標）（TM）プラットフォームとして実施するにあたっては、以下のBD-J Extentionを再生装置に実装するのが望ましい。BD-J Extentionは、GEM［１.０.２］を越えた機能を、Java（登録商標）（TM）プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-J Extentionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java（登録商標）（TM）Media FrameWorkに追加すべき、特殊機能を提供する。アングル、音声、字幕の選択についての制御が、このパッケージに追加される。
・org.bluray.ti
このパッケージは、GEM［１.０.２］における“サービス”を“タイトル”にマップして動作するためのAPIや、BD-ROMからタイトル情報を問い合わせる機構や新たなタイトルを選択する機構を含む。
・org.bluray.application
このパッケージは、アプリケーションの生存区間を管理するためのAPIを含む。また、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問い合わせるAPIを含む。
・org.bluray.ui
このパッケージは、BD-ROMに特化されたキーイベントのための定数を定義し、映像再生との同期を実現するようなクラスを含む。
・org.bluray.vfs
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、BD-ROMに記録されたコンテンツ（on-discコンテンツ）と、BD-ROMに記録されていないLocal Storage上のコンテンツ（off-discコンテンツ）とをバインドする機構（Binding Scheme）を提供する。
【０２４０】
Binding Schemeとは、BD-ROM上のコンテンツ（AVClip、字幕、BD-Jアプリケーション）と、Local Storage上の関連コンテンツとを関連付けるものである。このBinding Schemeは、コンテンツの所在に拘らず、シームレス再生を実現する。
（Virtual Package）
Virtual Packageを生成させるような処理をBD-ROM再生装置に行わせてもよい。これは、再生装置がVirtual Package情報を生成することでなされる。Virtual Package情報とは、BD-ROMにおけるボリューム管理情報を拡張した情報である。ここでボリューム管理情報は、ある記録媒体上に存在するディレクトリ-ファイル構造を規定する情報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管理情報とからなる。Virtual Package情報とは、BD-ROMのディレクトリ-ファイル構造を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、BD-ROMにおけるディレクトリ-ファイル構造の拡張を図ったものである。
【０２４１】
（制御手順の実現）
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。
【０２４２】
・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム（オブジェクトプログラム）であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような１つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、１つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。
【０２４３】
本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２４４】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０２４５】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
【０２４６】
本発明に係るプログラムは、以下のようにして使用することができる。本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム（BIOS）や、様々なミドルウェア（オペレーションシステム）と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。
【０２４７】
再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム（BIOS）が命令ROMに組み込まれており、様々なミドルウェア（オペレーションシステム）が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、再生装置に設けられている。この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、１つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、１つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。
【０２４８】
ハードディスクモデルの再生装置では、本発明のプログラムを１つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
（コントローラ２２）
コントローラ２２は、一個のシステムLSIとして実現することができる。
【０２４９】
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも１つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる（このようなシステムLSIは、マルチチップモジュールと呼ばれる。）。
ここでパッケージの種別に着目するとシステムLSIには、QFP（クッド フラッド アレイ）、PGA（ピン グリッド アレイ）という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
【０２５０】
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
システムLSIにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。
【０２５１】
各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム（BIOS）、様々なミドルウェア（オペレーションシステム）が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。
【０２５２】
具体的な実装については、SoC実装やSiP実装を用いることが望ましい。SoC（System on chip）実装とは、１チップ上に複数の回路を焼き付ける技術である。SiP（System in Package）実装とは、複数チップを樹脂等で１パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
【０２５３】
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
さらに、各記録再生装置の構成要素の一部又は全てを１つのチップとして構成してもよい。集積回路化は、上述したSoC実装，SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（Field Programmable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。
【産業上の利用可能性】
【０２５４】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
【図１】
2011081897.tif 000003
【図２】
2011081897.tif 000004
【図３】
2011081897.tif 000005
【図４】
2011081897.tif 000006
【図５】
2011081897.tif 000007
【図６】
2011081897.tif 000008
【図７】
2011081897.tif 000009
【図８】
2011081897.tif 000010
【図９】
2011081897.tif 000011
【図１０】
2011081897.tif 000012
【図１１】
2011081897.tif 000013
【図１２】
2011081897.tif 000014
【図１３】
2011081897.tif 000015
【図１４】
2011081897.tif 000016
【図１５】
2011081897.tif 000017
【図１６】
2011081897.tif 000018
【図１７】
2011081897.tif 000019
【図１８】
2011081897.tif 000020
【図１９】
2011081897.tif 000021
【図２０】
2011081897.tif 000022
【図２１】
2011081897.tif 000023
【図２２】
2011081897.tif 000024
【図２３】
2011081897.tif 000025
【図２４】
2011081897.tif 000026
【図２５】
2011081897.tif 000027
【図２６】
2011081897.tif 000028
【図２７】
2011081897.tif 000029
【図２８】
2011081897.tif 000030
【図２９】
2011081897.tif 000031
【図３０】
2011081897.tif 000032
【図３１】
2011081897.tif 000033
【図３２】
2011081897.tif 000034
【図３３】
2011081897.tif 000035
【図３４】
2011081897.tif 000036
【図３５】
2011081897.tif 000037
【図３６】
2011081897.tif 000038
【図３７】
2011081897.tif 000039
【図３８】
2011081897.tif 000040
【図３９】
2011081897.tif 000041
【図４０】
2011081897.tif 000042
【図４１】
2011081897.tif 000043
【図４２】
2011081897.tif 000044
【図４３】
2011081897.tif 000045