(57)【要約】ＢＤ−ＲＯＭにはＰｌａｙＬｉｓｔ情報が記録されている。ＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈ情報、ＳｕｂＰａｔｈ情報を含み、前記ＭａｉｎＰａｔｈ情報は、複数ＡＶＣｌｉｐの１つを、ＭａｉｎＣｌｉｐとして指定して、そのＭａｉｎＣｌｉｐに対し、主たる再生区間を定義している。前記ＳｕｂＰａｔｈ情報は、複数ＡＶＣｌｉｐのうち他のものを、ＳｕｂＣｌｉｐとして指定して、そのＳｕｂＣｌｉｐに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義している。  ＰｌａｙＬｉｓｔ情報はＳＴＮ＿ｔａｂｌｅを含み、ＳＴＮ＿ｔａｂｌｅは、ＳｕｂＣｌｉｐ及びＳｕｂＣｌｉｐに多重化された複数のエレメンタリストリームのうち、再生が許可されているものを示している。そしてＳＴＮ＿ｔａｂｌｅにおいて再生が許可されている複数エレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないＡＶＣｌｉｐの単位時間（１秒）当たりの総サイズは、例えば、４８Ｍｂｉｔ以下に抑制されている。【特許請求の範囲】
【請求項１】
プレイリスト情報が記録された記録媒体であって、
前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの１つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
前記プレイリスト情報はストリームテーブルを含み、
前記ストリームテーブルは、
メインストリーム及びサブストリームに多重化された複数のエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないデジタルストリームの単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする記録媒体。
【請求項２】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリオーディオストリームとがあり、
プライマリオーディオストリーム及びセカンダリオーディオストリームは、オーディオミキシングアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそれぞれから選ばれる
ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデオストリームとがあり、
プライマリビデオストリーム及びセカンダリビデオストリームは、ピクチャインピクチャアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれる
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生装置であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するパケットを、メインパス情報に従って読み出す第１読出部と、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケットを、サブパス情報に従って読み出す第２読出部と、
デコーダと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パケットを得て、デコーダに供給する多重分離部とを備え、
多重分離部からデコーダに供給されるパケットの、単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする再生装置。
【請求項６】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項５記載の再生装置。
【請求項７】
前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリオーディオストリームとがあり、
前記デコーダは、
プライマリオーディオストリームをデコードする第１デコーダと、及び、セカンダリオーディオストリームをデコードする第２デコーダと、第１、第２デコーダによるデコード結果を合成する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそれぞれから選ばれている
ことを特徴とする請求項６記載の再生装置。
【請求項８】
前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデオストリームとがあり、
前記デコーダは、
プライマリビデオストリームをデコードする第１デコーダと、及び、セカンダリビデオストリームをデコードする第２デコーダと、第１、第２デコーダによるデコード結果を合成する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれている
ことを特徴とする請求項６記載の再生装置。
【請求項９】
アプリケーションデータを記録媒体に記録する記録方法であって、
アプリケーションデータを生成するステップ、
アプリケーションデータに対するベリファイを行うステップ
ベリファイ結果が正当であるアプリケーションデータが書き込まれた記録媒体を得るステップを備え、
アプリケーションデータは、プレイリスト情報と、デジタルストリームとを含み、
前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの１つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
前記プレイリスト情報はストリームテーブルを含み、
前記ストリームテーブルは、
メインストリーム及びサブストリームに多重化された複数のエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
前記ベリファイのステップは、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないデジタルストリームの単位時間当たりの総データサイズが、所定値以下であることを確認する
ことを特徴とする記録方法。
【請求項１０】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項９記載の記録方法。
【請求項１１】
前記エレメンタリストリームの種別には、プライマリオーディオストリームと、セカンダリオーディオストリームとがあり、
プライマリオーディオストリーム及びセカンダリオーディオストリームは、オーディオミキシングアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリームのそれぞれから選ばれる
ことを特徴とする請求項１０記載の記録方法。
【請求項１２】
前記エレメンタリストリームの種別には、プライマリビデオストリームと、セカンダリビデオストリームとがあり、
プライマリビデオストリーム及びセカンダリビデオストリームは、ピクチャインピクチャアプリケーションを構成するものであり、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリーム、セカンダリビデオストリームのそれぞれから選ばれる
ことを特徴とする請求項１０記載の記録方法。
【請求項１３】
ストリームは、複数のパケットから構成され、各パケットには、アライバルタイムスタンプが付与されており、
前記記録方法は、
複数アライバルタイムスタンプの基準となる時間軸上に、前記単位時間の長さをもつウィンドゥを定義し、アライバルタイムスタンプに示される座標に従い、当該ウィンドゥを、この時間軸上でシフトさせてゆくステップを含み、
前記ベリファイステップにおける総データサイズの確認は、
ウィンドゥが１回するシフトする毎に、行われる
ことを特徴とする請求項９記載の記録方法。
【請求項１４】
プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生方法であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するパケットを、メインパス情報に従って読み出す第１読出ステップと、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケットを、サブパス情報に従って読み出す第２読出ステップと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パケットを得て、デコーダに供給する多重分離ステップとを備え、
多重分離部からデコーダに供給されるパケットの、単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする再生方法。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、Ｏｕｔ−ｏｆ−ＭＵＸフレームワークの技術分野に属する発明である。
【背景技術】
【０００２】  Ｏｕｔ−ｏｆ−ＭＵＸフレームワークとは、ＢＤ−ＲＯＭ等のリードオンリー型の記録媒体に記録されているデジタルストリームと、リライタブル型の記録媒体である、ローカルストレージに記録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生させる技術である。
ここでＢＤ−ＲＯＭに記録されているデジタルストリームが、映画作品の本編を構成するものであり、ローカルストレージに記録されているデジタルストリームが、映画監督のコメンタリを構成する場合、上述したＯｕｔ−ｏｆ−ＭＵＸフレームワークを実現することにより、ＢＤ−ＲＯＭ上の本編と、ローカルストレージ上のコメンタリとを再生に供して、ＢＤ−ＲＯＭの内容拡充を図ることができる。尚、リードオンリー型記録媒体の先行技術としては、以下の特許文献に記載されているものがある。
【特許文献１】特願平８ー８３４７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】  ところで上述したＯｕｔ−ｏｆ−ＭＵＸフレームワークでは、ＢＤ−ＲＯＭに記録されたストリームと、ローカルストレージに記録されたストリームとを同時に読み出して、それらのストリームを構成するＴＳパケットを、デコーダに供給せねばならない。このデコーダへの供給にどれだけの帯域が必要であるかを検討すると、これらＢＤ−ＲＯＭからの供給ビットレートが４８Ｍｂｐｓ、ローカルストレージからの供給ビットレートが４８Ｍｂｐｓである場合、ワーストケースにおいて、９６Ｍｂｉｔ（４８Ｍｂｉｔ＋４８Ｍｂｉｔ）ものデータ供給が、上述した同時読み出しの期間内において発生する可能性がある。かかるワーストケースの発生が考えられるなら、９６ＭｂｐｓというビットレートでＴＳパケットを供給できるよう装置内の帯域を上げねばならない。またそれが不可能であるならば、デコーダ内に大きなバッファを設けておき、当該供給が一時点に集中しないように、ＴＳパケットの先読みをデコーダに行わせる必要がある。しかし上述した同時読み出しの期間が、短ければいざしらず、２時間という映画再生のオーダであれば、バッファの容量が不足し、充分な先読みが行えない。【０００４】  充分な先読みが行えないため、先読みのためのバッファにアンダーフローが生じると、ビデオ又はオーディオの欠落が発生するため再生品質が著しく低下する。かといって、高いビットレートでのデータ供給が必要になるなら、再生装置の低価格化を大きく妨げる結果となる。
本発明の目的は、高い帯域を必要とせずとも、別々の記録媒体から供給されたデジタルストリームを、デコーダに供給することができる、記録媒体を提供することである。
【課題を解決するための手段】
【０００５】  上記目的を達成するため、本発明にかかる記録媒体は、プレイリスト情報が記録され、前記プレイリスト情報は、メインパス情報、サブパス情報を含み、前記メインパス情報は、複数デジタルストリームの１つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、前記プレイリスト情報はストリームテーブルを含み、前記ストリームテーブルは、メインストリーム及びサブストリームに多重化された複数のエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないデジタルストリームの単位時間当たりの総データサイズは、所定値以下であることを特徴としている。
【発明の効果】
【０００６】  ストリームテーブルにおいて再生が許可されている複数エレメンタリストリームの単位時間当たりの総データサイズは、所定値以下であり、ワーストケースにおいても、単位時間当たりに転送すべきＴＳパケットの量は、所定の上限値を上回ることはない。
例えば単位時間が１秒であり、所定の上限値が４８Ｍｂｉｔである場合、ストリームの同時読み出しのため、ＴＳパケットの供給量が局所的に９６Ｍｂｉｔにまであがったとしても、“１秒当たりのビット量が４８Ｍｂｉｔ以下”に制限されるため、ワーストケースにあたる９６Ｍｂｉｔのデータ供給量は、０．５秒以上継続することはない。【０００７】  ストリームの再生時間軸上のどの時点においても「ワーストケースが０．５秒以上継続しない」との保障があるので、９６Ｍｂｉｔ×０．５秒のサイズのＴＳパケットを、常に先読みしてデコーダに供給するように、再生装置を構成しておけば、デコーダ内のバッファのアンダーフローを回避することができる。
「９６Ｍｂｉｔ×０．５秒」を上限値とした先読みにより、アンダーフローを生じさせることなく、ＴＳパケットを安定的にデコーダに供給することができるので、Ｏｕｔ−ｏｆ−ＭＵＸフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。バンド幅を高めるなくことなく、ＢＤ−ＲＯＭのみを対象としたような再生装置において、Ｏｕｔ−ｏｆ−ＭＵＸフレームワークを実現することができるので、Ｏｕｔ−ｏｆ−ＭＵＸフレームワークを実現するような再生装置を、低価格で、市場に供給することができる。【０００８】  また「１秒当たり４８Ｍｂｐｓ以下」との制限があるので、再生装置は、上述したような“常に先読みを行う”という単純な制御を実行していれば、ワーストケースとなるデータ供給が発生したとしてもアンダーフローの発生を避けることができる。ワーストケースとなるデータ供給がいつ発生するかを予測する予測処理等の実装を省略することができるので、再生装置を、容易に開発することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】ＢＤ−ＲＯＭの内部構成を示す図である。
【図３】拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示す図である。
【図４】ＰＥＳパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示す図である。
【図５】ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示す図である。
【図６】トランスポートストリームの詳細を示す図である。
【図７】ＰＡＴ、ＰＭＴパケットの内部構成を示す図である。
【図８】ＡＶＣｌｉｐを構成するＴＳパケットがどのような過程を経てＢＤ−ＲＯＭに書き込まれるかを示す。
【図９】Ａｌｉｇｎｅｄ  Ｕｎｉｔの内部構成を示す図である。
【図１０】Ｃｌｉｐ情報の内部構成を示す図である。
【図１１】映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。
【図１２】ＰｌａｙＬｉｓｔ情報のデータ構造を示す図である。
【図１３】ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。
【図１４】ローカルストレージ２００の内部構成を示す図である。
【図１５】Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションを構成するプライマリＴＳ、セカンダリＴＳがＢＤ−ＲＯＭ再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。
【図１６】ＰｌａｙＬｉｓｔ情報のデータ構造を示す図である。
【図１７】Ｓｕｂｐａｔｈ情報の内部構成をクローズアップして示す図である。
【図１８】ローカルストレージ２００上のＳｕｂＣｌｉｐと、ローカルストレージ２００上のＰｌａｙＬｉｓｔ情報と、ＢＤ−ＲＯＭ上のＭａｉｎＣｌｉｐとの対応を示す図である。
【図１９】（ａ）ＳＴＮ＿ｔａｂｌｅの内部構成を示す図である。
【００１０】  （ｂ）ビデオストリームに対応したＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅを示す図である。
（ｃ）オーディオストリームに対応したＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅを示す図である。
（ｄ）ビデオストリームにおけるＳｔｒｅａｍ＿ｅｎｔｒｙを示す図である。【図２０】ＢＤ−ＲＯＭから読み出されたＴＳパケットと、ローカルストレージから読み出されたＴＳパケットとを示し、これらのＴＳパケットのうち、デコーダに供給されるものを示す。
【図２１】（ａ）〜（ｄ）Ｗｉｎｄｏｗのシフトを示す図である。
【図２２】ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージから読み出されたＴＳパケットのデータ量の時間的推移を示すグラフである。
【図２３】（ａ）（ｂ）各Ｗｉｎｄｏｗの転送許容量と、Ｗｉｎｄｏｗにおけるデコーダへの供給量とを対比して示す図である。
【図２４】Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを構成するＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍの接続状態を示す図である。
【図２５】図２４に示した、ＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、ＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”に設定されている場合の、ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとの関係を示す図である。
【図２６】ＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値を示す。
【図２７】ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍにて参照されているＭａｉｎＣｌｉｐ、カレントＰｌａｙＩｔｅｍにて参照されているＳｕｂＣｌｉｐにおいて、ＴＳ１、ＴＳ２がどのように特定されるかを示す図である。
【図２８】ＣＣ＝５、及び、ＳＰ＿ＣＣ＝５の詳細を示す図である。
【図２９】ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ及びカレントＰｌａｙＩｔｅｍにて指定される複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、複数のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、ＳＴＣ時間軸との関係を示す図である。
【図３０】本発明に係る再生装置の内部構成を示す図である。
【図３１】ＰｌａｙＬｉｓｔ情報に基づく再生手順のフローチャートである。
【図３２】ＳｕｂＰｌａｙＩｔｅｍにおけるシームレス接続を示すフローチャートである。
【図３３】第２実施形態にかかるオーサリングシステムの内部構成を示す図である。
【図３４】プライマリＴＳ、セカンダリＴＳに対するベリファイ手順を示すフローチャートである。
【図３５】同種のエレメンタリストリームが複数存在する場合の、プライマリＴＳ、セカンダリＴＳに対するベリファイ手順を示すフローチャートである。
【図３６】ＣＣ＝６の詳細な説明を示す図である。
【図３７】ＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの相関を示した図である。
【図３８】ＡＴＣ時間軸に存在する複数のＴＳパケットが、どのように多重化されるかを模式的に示す図である。
【図３９】オーディオに加えて、字幕（ＰＧ）やメニュー（ＩＧ）も入れ替えられる場合、プライマリＴＳを構成する複数のＴＳパケットと、セカンダリＴＳを構成する複数のＴＳパケットとが、どのように多重化されるかを模式的に示す図である。
【図４０】オーディオミキシングアプリケーションを構成するプライマリＴＳ、セカンダリＴＳが、ＢＤ−ＲＯＭ再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。
【図４１】第５実施形態に係る再生装置の内部構成を示す図である。
【図４２】オーディオミキシングを示すプレイリストにて指定されるＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの相関を示した図である。
【図４３】劇場公開版とディレクターズカットの両方を構成するＰｌａｙＬｉｓｔ情報の一例を示す図である。
【符号の説明】
【００１１】            １ａ    ＢＤ−ＲＯＭドライブ
１ｂ，ｃ  リードバッファ
１ｂ，ａ，ｃ  ＡＴＣカウンタ
２ａ，ｄ  Ｓｏｕｒｃｅ  Ｄｅｐａｃｋｅｔｉｚｅｒ
２ｃ，ｄ  ＡＴＣカウンタ
３ａ，ｃ  ＳＴＣカウンタ
３ｂ，ｄ  ＰＩＤ  Ｆｉｌｔｅｒ
４  ビデオデコーダ
５  ビデオプレーン
６  Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ
７  Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ
８  オーディオデコーダ
１０ａ，ｂ，ｃ，ｄ  スイッチ
１１  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ
１２  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン
１３  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ
１４  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン
１７  合成部
２１  メモリ
２２  コントローラ
２３  ＰＳＲセット
２４  ＰＩＤ変換部
２５  ネットワーク部
２６  操作受付部
１００  ＢＤ−ＲＯＭ
２００  ローカルストレージ
３００  再生装置
４００  テレビ
５００  ＡＶアンプ
【発明を実施するための最良の形態】
【００１２】  （第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ローカルストレージ２００である。ローカルストレージ２００は、再生装置３００、テレビ４００、ＡＶアンプ５００、スピーカ６００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。【００１３】  以降、ＢＤ−ＲＯＭ１００、ローカルストレージ２００、再生装置３００について説明を行う。
ＢＤ−ＲＯＭ１００は、映画作品が記録された記録媒体である。
ローカルストレージ２００は、再生装置に組み込まれ、映画配給者のサーバから配信されたコンテンツの受け皿として利用されるハードディスクである。【００１４】  再生装置３００は、ネット対応型のデジタル家電機器であり、ＢＤ−ＲＯＭ１００を再生する機能をもつ。また、映画配給者のサーバ７００から、ネットワークを通じてダウンロードしたコンテンツを、ローカルストレージ２００に格納し、こうしてローカルストレージ２００に記録されたコンテンツと、ＢＤ−ＲＯＭ１００に記録されたコンテンツと組み合わせて、ＢＤ−ＲＯＭ１００のコンテンツを拡張／更新を行うことができる。ＢＤ−ＲＯＭ１００の記録内容に、ローカルストレージ２００の記録内容を組み合わせて、ＢＤ−ＲＯＭ１００に記録されていないデータを、恰も、記録されているように扱う技術を“バーチャルパッケージ”という。【００１５】  以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ファイルシステム上における改良で実現することができる。
＜ＢＤ−ＲＯＭの概要＞
図２は、ＢＤ−ＲＯＭの内部構成を示す図である。本図の第４段目にＢＤ−ＲＯＭを示し、第３段目にＢＤ−ＲＯＭ上のトラックを示す。本図のトラックは、ＢＤ−ＲＯＭの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。この第１段目においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。【００１６】  このＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリと呼ばれる３つのサブディレクトリが存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ）がある。
ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ）がある。【００１７】  ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ）がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。
＜ＢＤ−ＲＯＭの構成その１．ＡＶＣｌｉｐ＞
先ず初めに、拡張子．ｍ２ｔｓが付与されたファイルについて説明する。図３は、拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐはＭＰＥＧ２−Ｔｒａｎｓｐｏｒ  Ｓｔｒｅａｍ形式のデジタルストリームである。このデジタルストリームは、デジタル化された映像、デジタル化された音声を（上１段目）、ＰＥＳパケットからなるエレメンタリストリームに変換し（上２段目）、更にＴＳパケットに変換して（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（Ｐｒｅｓｅｎｔａｔｉｉｏｎ  Ｇｒａｐｈｉｃｓ（ＰＧ）ストリーム）及び対話系のインタラクティブグラフィクスストリーム（Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓ（ＩＧ）ストリーム）を（下１段目、下２段目）、ＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。【００１８】  以降、これらのビデオストリーム、オーディオストリーム、ＰＧストリーム、ＩＧストリームについて説明する。
＜ビデオストリーム＞
ビデオストリームは、映画作品の動画像を構成するストリームであり、ＳＤ画像、ＨＤ画像であるピクチャデータから構成される。ビデオストリームには、ＶＣ−１のビデオストリーム、ＭＰＥＧ４−ＡＶＣのビデオストリーム、ＭＰＥＧ２−Ｖｉｄｅｏのビデオストリームといった形式が存在する。ＭＰＥＧ４−ＡＶＣのビデオストリームでは、ＩＤＲピクチャ，Ｉピクチャ，Ｐピクチャ，Ｂピクチャに、ＰＴＳ、ＤＴＳといったタイムスタンプが付され、このピクチャの単位で、再生制御がなされる。このように、ＰＴＳ、ＤＴＳが付されて、再生制御の単位となる、ビデオストリームの一単位を“Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ”という。
＜オーディオストリーム＞
オーディオストリームは、映画作品の音声を表すストリームであり、ＬＰＣＭオーディオストリーム、ＤＴＳ−ＨＤオーディオストリーム、ＤＤ／ＤＤ＋オーディオストリームやＤＤ／ＭＬＰオーディオストリームといった形式が存在する。オーディオストリームにおけるオーディオフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディオストリームの一単位を“Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ”という。
＜ＰＧストリーム＞
ＰＧストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。ＰＧストリームは、ＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｌｅｔ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）、ＷＤＳ（Ｗｉｎｄｏｗ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）という一連の機能セグメントからなる。ＯＤＳ（Ｏｂｊｅｃｔ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。【００１９】  ＷＤＳ（Ｗｉｎｄｏｗ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、ＰＤＳ（Ｐａｌｌｅｔ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｅｇｍｅｎｔ）は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Ｃｕｔ−Ｉｎ／Ｏｕｔ、Ｆａｄｅ−Ｉｎ／Ｏｕｔ、Ｃｏｌｏｒ  Ｃｈａｎｇｅ、Ｓｃｒｏｌｌ、Ｗｉｐｅ−Ｉｎ／Ｏｕｔといったものがあり、ＰＣＳによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。【００２０】  ＜ＩＧストリーム＞
ＩＧストリームは、対話制御を実現するグラフィクスストリームである。ＩＧストリームにて定義される対話制御は、ＤＶＤ再生装置上の対話制御と互換性がある対話制御である。かかるＩＧストリームは、ＩＣＳ（Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｍｐｏｓｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ  Ｄｉｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ  Ｄｅｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。ＯＤＳ（Ｏｂｊｅｃｔ  Ｄｅｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。ＰＤＳ（Ｐａｌｅｔｔｅ  Ｄｉｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ＩＣＳ（Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｍｐｏｓｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ＩＣＳは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。【００２１】  ここでＡＶＣｌｉｐは、１つ以上の“ＳＴＣ＿Ｓｅｑｕｅｎｃｅ”から構成される。“ＳＴＣ＿Ｓｅｑｕｅｎｃｅ”とは、ＡＶストリームのシステム基準時刻であるＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）の不連続点（ｓｙｓｔｅｍ  ｔｉｍｅ−ｂａｓｅ  ｄｉｓｃｏｎｔｉｎｕｉｔｙ）が存在しない区間をいう。ＳＴＣの不連続点はデコーダがＳＴＣを得るために参照するＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）を運ぶＰＣＲパケットの不連続情報（ｄｉｓｃｏｎｔｉｎｕｉｔｙ＿ｉｎｄｉｃａｔｏｒ）がＯＮである点である。【００２２】  図４は、ＰＥＳパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第１段目は、ビデオストリームを示し、第３段目はオーディオストリームを示す。第２段目は、ＰＥＳパケット列を示す。本図の矢印ｙｙ１，ｙｙ２，ｙｙ３，ｙｙ４に示すように、ビデオストリームにおける複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔであるＩＤＲ、Ｂピクチャ、Ｐピクチャは、複数に分割され、個々の分割部分が、ＰＥＳパケットのペイロード（図中のＶ＃１，Ｖ＃２，Ｖ＃３，Ｖ＃４）に格納されることがわかる。またオーディオストリームを構成するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔであるオーディオフレームは、矢印ａａ１，ａａ２に示すように、個々のＰＥＳパケットのペイロード（図中のＡ＃１，Ａ＃２）に格納されていることがわかる。【００２３】  図５は、ビデオやオーディオが、プログラムストリーム、トランスポートストリームにどのように多重化されるかを示している。下段は、ビデオストリームと、オーディオストリームとを格納した複数のＰＥＳパケット（図中のＶ＃１，Ｖ＃２，Ｖ＃３，Ｖ＃４，Ａ＃１，Ａ＃２）を示す。ビデオストリーム及びオーディオストリームは、別個のＰＥＳパケットに格納されることが本図からわかる。上段は、下段のＰＥＳパケットを格納したプログラムストリーム及びトランスポートスト���ームを示す。プログラムストリームに多重化される場合、ＰＥＳパケットは、１パックに収められる。トランスポートストリームに多重化される場合、ＰＥＳパケットは分割され、個々の分割部分は、複数のＴＳパケットのペイロードに格納される。ＢＤ−ＲＯＭにおける格納方式は、前者のプログラムストリームではなく、後者のトランスポートストリームのものとなる。図５ではそのようになっていないが、トランスポートストリームに使われるビデオＰＥＳパケットは１つのフレーム、もしくはペアとなる２つのフィールドを格納するのが一般的である。【００２４】  図６は、トランスポートストリームの詳細を示す図である。本図における第１段目は、ＭＰＥＧ２トランスポートストリームを構成する複数のＴＳパケット列であり、第２段目はＴＳパケットの内部構成を示す。この第２段目に示すように、１つのＴＳパケットは、“ヘッダ”と、“適用フィールド（ａｄａｐｔａｔｉｏｎ  ｆｉｅｌｄ）”と、“ペイロード”とから構成される。引き出し線ｔｈ１は、ＴＳパケットヘッダの構成をクローズアップしている。このこの引き出し線に示すように、ＴＳパケットヘッダには、ＰＥＳパケットの先頭を格納していることを示す「ユニット開始表示（ｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｉｎｄｉｃａｔｏｒ）」、トランスポートストリームに多重化されるエレメンタリストリームの種別を示す「ＰＩＤ（Ｐａｃｋｅｔ  Ｉｄｅｎｔｉｆｉｅｒ）」、ＴＳパケットに適用フィールドが存在しているか否かを示す「適用フィールド制御」などが存在する。【００２５】  引き出し線ｔｈ２は、適用フィールドの内部構成をクローズアップしている。適用フィールドはＴＳパケットヘッダの適用フィールド制御が“１”に設定されている場合に、ＴＳパケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、エントリーポイントであることを示す「ランダムアクセス表示（ｒａｎｄｏｍ＿ａｃｃｅｓｓ＿ｉｎｄｉｃａｔｏｒ）」、Ｔ−ＳＴＤ（Ｔｒａｎｓｐｏｒｔ  Ｓｙｓｔｅｍ  Ｔａｒｇｅｔ  Ｄｅｃｏｄｅｒ）のＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）を与える「ＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）」などが、この適用フィールドに格納される。【００２６】  図７は、ＰＡＴ、ＰＭＴパケットの内部構成を示す図である。これらのパケットは、トランスポートストリームのプログラム構成を記述するものである。
本図における引き出し線ｈｍ１は、トランスポートストリームに存在するＰＩＤ＝０のＴＳパケットの構成をクローズアップしている。かかるＴＳパケットは、ＰＡＴ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｔａｂｌｅ）パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。ＰＡＴパケットのＰＩＤは常に“０”である。ＰＡＴパケットには、ＰＡＳ（Ｐｒｏｇｒａｍ  Ａｓｓｏｃｉａｔｉｏｎ  Ｓｅｃｔｉｏｎ）が格納される。引き出し線ｈｍ２は、ＰＡＳの内部構成をクローズアップしている。この引き出し線に示すようにＰＡＳは、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒ（番組番号）と、ｐｒｏｇｒａｍ  ｍａｐ  ｔａｂｌｅ（ＰＭＴのＰＩＤ）とを対応付けて示している。引き出し線ｈｍ３は、トランスポートストリームに存在するＰＩＤ＝０ｘ１００のＴＳパケットの構成をクローズアップしている。かかるＴＳパケットは、ＰＭＴパケットと呼ばれる。引き出し線ｈｍ４に示すように、ＰＭＴパケットのＰＭＳは、そのＰＭＳに対応する番組に含まれるストリーム種別を示す「ｓｔｒｅａｍ＿ｔｙｐｅ」と、そのストリームのＰＩＤである「ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤ」とを含む。本図の例では、番組番号＃１の番組は、ＰＩＤ＝０ｘ１００のＰＭＴを有しており、ＰＩＤ＝０ｘ２００と０ｘ２０１とを有するＭＰＥＧ２ビデオと、ＡＤＴＳオーディオとが、この番組番号＃１の番組を構成していることがわかる。このようにして、常にＰＩＤ＝０であるＰＡＴからＰＭＴのＰＩＤを取得し、このＰＭＴのＰＩＤからＰＭＴパケットを取得して、ＰＭＳを参照することで、トランスポートストリーム中の番組と、その構成ストリームのＰＩＤやストリームタイプとを知得することができる。【００２７】  続いて、以上のように構成されたＡＶＣｌｉｐが、ＢＤ−ＲＯＭにどのように書き込まれるかを説明する。図８は、ＡＶＣｌｉｐを構成するＴＳパケットがどのような過程を経てＢＤ−ＲＯＭに書き込まれるかを示す。本図の第１段目にＡＶＣｌｉｐを構成するＴＳパケットを示す。
ＡＶＣｌｉｐを構成する１８８バイトのＴＳパケットは、第２段目に示すように４バイトのＴＳ＿ｅｘｔｒａ＿ｈｅａｄｅｒ（図中のハッチング部）、が付されて、１９２バイト長のＳｏｕｒｃｅパケットになる。このＴＳ＿ｅｘｔｒａ＿ｈｅａｄｅｒは、当該ＴＳパケットのデコーダ入力時刻情報を示すＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐを含む。ＡＴＳヘッダをＴＳパケットごとに付与してストリームを形成する理由は、ＴＳパケットごとにデコーダ（ＳＴＤ）への入力時刻を与えるためである。デジタル放送ではトランスポートストリームは固定ビットレートとして扱われる。そのため、ＮＵＬＬパケットと呼ばれるダミーのＴＳパケットを多重化して固定ビットレートとしたトランスポートストリームを放送している。光ディスクのような限られた記録容量の記録媒体にストリームを記録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である。そのためＢＤ−ＲＯＭではＮＵＬＬパケットを記録することはしない。そして、可変ビットレートの記録方式に対応するため、個々のＴＳパケットにＡＴＳを付与した上でトランスポートストリームを記録する。このＡＴＳを用いることで、ＴＳパケットごとにデコーダ入力時刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降、ＡＴＳヘッダとＴＳパケットの１組をソースパケット（Ｓｏｕｒｃｅ  Ｐａｃｋｅｔ）と呼ぶ。【００２８】  ＡＶＣｌｉｐを構成するＳｏｕｒｃｅパケットは、第３段目におけるＡＶＣｌｉｐにおいて、１つ以上の“ＡＴＣ＿Ｓｅｑｕｅｎｃｅ”を構成する。“ＡＴＣ＿Ｓｅｑｕｅｎｃｅ”とは、Ｓｏｕｒｃｅパケットの配列であって、そのＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐが参照しているＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｃｌｏｃｋに、不連続点（ｎｏ  ａｒｒｉｖａｌ  ｔｉｍｅ−ｂａｓｅ  ｄｉｓｃｏｎｔｉｎｕｔｉｙ）が存在しないものをいう。いいかえれば、そのＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐが参照しているＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｃｌｏｃｋに、連続性が存在するＳｏｕｒｃｅパケット列を“ＡＴＣ＿Ｓｅｑｕｅｎｃｅ”という。【００２９】  かかるＡＴＣ＿ＳｅｑｕｅｎｃｅがＡＶＣｌｉｐになり、ｘｘｘｘｘ．ｍ２ｔｓというファイル名でＢＤ−ＲＯＭに記録される。
かかるＡＶＣｌｉｐは、通常のコンピュータファイル同様、１つ以上のファイルエクステントに分割され、ＢＤ−ＲＯＭ上の領域に記録される。第４段目はＡＶＣｌｉｐがどのようにＢＤ−ＲＯＭに記録されるかを模式的に示す。この第４段目においてファイルを構成する各ファイルエクステントは、予め定められたＳｅｘｅｔｅｎｔ以上のデータ長を有する。【００３０】  ＡＶＣｌｉｐを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓｅｘｅｔｅｎｔを検討する。
ここでＢＤ−ＲＯＭにおいて光ピックアップのジャンプに要する時間は、
Ｔｊｕｍｐ＝Ｔａｃｃｅｓｓ＋Ｔｏｖｅｒｈｅａｄ
で与えられる。
Ｔａｃｃｅｓｓは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時間である。
ＢＤ−ＲＯＭから読み出されたＴＳパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Ｒｕｄというビットレートで行われ、ＥＣＣブロックにおけるセクタ数をＳｅｃｃとした場合、
Ｔｏｖｅｒｈｅａｄは、
Ｔｏｖｅｒｈｅａｄ≦（２×Ｓｅｃｃ×８）／Ｒｕｄ＝２０ｍ秒
という計算で与えられる。
ＢＤ−ＲＯＭから読み出されたＴＳパケットは、Ｓｏｕｒｃｅパケットの状態でリードバッファに格納された上、ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅという転送レートで、デコーダに供給される。【００３１】  ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅという転送レートでの、デコーダへのＴＳパケット供給が跡絶えさせないためには、Ｔｊｕｍｐの間、リードバッファからデコーダへのＴＳパケット出力が継続している必要がある。ここでリードバッファからの出力は、ＴＳパケットではなく、Ｓｏｕｒｃｅパケットの状態でなされるので、ＴＳパケットのＳｏｕｒｃｅパケットとのサイズ比を１９２／１８８とした場合、Ｔｊｕｍｐの間、（１９２／１８８×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）という転送レートにより、リードバッファからのＳｏｕｒｃｅパケット出力が継続している必要がある。
従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、  Ｂｏｃｃｕｐｉｅｄ≧（Ｔｊｕｍｐ／１０００×８）×（（１９２／１８８）×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）
となる。
リードバッファへの入力レートはＲｕｄ、リードバッファからの出力レートはＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８）であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））になる。【００３２】  このＢｏｃｃｕｐｉｅｄを、リードバッファに蓄積するのに要する時間Ｔｘは、
Ｔｘ＝Ｂｏｃｃｕｐｉｅｄ／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
になる。
ＢＤ−ＲＯＭからの読み出しには、この時間ＴｘにおいてＲｕｄでのＴＳパケット入力を継続する必要があるので、ＡＶＣｌｉｐを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓｅｘｅｔｅｎｔは、
Ｓｅｘｅｔｅｎｔ＝Ｒｕｄ×Ｔｘ
＝Ｒｕｄ×Ｂｏｃｃｕｐｉｅｄ／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
≧Ｒｕｄ×（Ｔｊｕｍｐ／１０００×８）×（（１９２／１８８）×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）
／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
≧（Ｒｕｄ×Ｔｊｕｍｐ／１０００×８）×
×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２／（Ｒｕｄ×１８８−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２）
になる。
よって
Ｓｅｘｅｔｅｎｔ≧
（Ｔｊｕｍｐ×Ｒｕｄ／１０００×８）×
（ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２／（Ｒｕｄ×１８８−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２））
になる。
ＡＶＣｌｉｐを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさないように算出されたＳｅｘｔｅｎｔ以上のデータ長をもつことにより、ＡＶＣｌｉｐを構成する各ファイルエクステントが、ＢＤ−ＲＯＭ上において離散的に位置されたとしても、再生時においてデコーダへのＴＳパケット供給が途絶えさせることなく、連続的に読み出されることになる。【００３３】  上述したファイルエクステントは、Ｓｏｕｒｃｅパケット３２個集めたアラインドユニット（Ａｌｉｇｎｅｄ  Ｕｎｉｔ、６ＫＢｙｔｅのデータサイズ）を最小単位として構成されている。したがって、ＢＤでのストリームファイル（ＸＸＸＸＸ．ＡＶＣｌｉｐ）のファイルサイズは常に６ＫＢｙｔｅの倍数となる。
図９は、Ａｌｉｇｎｅｄ  Ｕｎｉｔの内部構成を示す図である。Ａｌｉｇｎｅｄ  Ｕｎｉｔは、３２個のＳｏｕｒｃｅパケットから構成され、連続する３つのセクタに書き込まれる。３２個のＳｏｕｒｃｅパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。ＢＤ−ＲＯＭにおけるセクタは、３２個単位で誤り訂正符号が付され、ＥＣＣブロックを構成する。再生装置はＡｌｉｇｎｅｄ  Ｕｎｉｔの単位でＢＤ−ＲＯＭをアクセスする限り、３２個の完結したＳｏｕｒｃｅパケットを得ることができる。以上がＢＤ−ＲＯＭに対するＡＶＣｌｉｐの書き込みのプロセスである。ＢＤ−ＲＯＭに記録され、高画質なビデオストリームが多重化されているＡＶＣｌｉｐを、以下“ＭａｉｎＣｌｉｐ”と呼ぶ。これに対し、ローカルストレージに記録され、ＭａｉｎＣｌｉｐと同時に再生されるＡＶＣｌｉｐを、“ＳｕｂＣｌｉｐ”とよぶ。【００３４】  ＢＤ−ＲＯＭに記録されているＭａｉｎＣｌｉｐに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々のエレメンタリストリームに対応するものである。ＭａｉｎＣｌｉｐを多重分離することで得られるパーシャルトランスポートストリームであって、１つのエレメンタリストリームに対応するものを“プライマリＴＳ”という。
＜ＢＤ−ＲＯＭの構成その２．Ｃｌｉｐ情報＞
続いて拡張子．ｃｌｐｉが付与されたファイルについて説明する。拡張子．ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ）は、Ｃｌｉｐ情報を格納している。Ｃｌｉｐ情報は、個々のＡＶＣｌｉｐについての管理情報である。図１０は、Ｃｌｉｐ情報の内部構成を示す図である。本図の左側に示すようにＣｌｉｐ情報は、
ｉ）ＡＶＣｌｉｐについての情報を格納した『ＣｌｉｐＩｎｆｏ（）』、
ｉｉ）ＡＴＣ  Ｓｅｑｕｅｎｃｅ，ＳＴＣ  Ｓｅｑｕｅｎｃｅに関する情報を格納した『Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏ（）』
ｉｉｉ）Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅに関する情報を格納した『Ｐｒｏｇｒａｍ  Ｉｎｆｏ（）』
ｉｖ）『Ｃｈａｒａｃｔｅｒｉｓｔｉｃ  Ｐｏｉｎｔ  Ｉｎｆｏ（ＣＰＩ（））』からなる。【００３５】  ＣｌｉｐＩｎｆｏには、このＣｌｉｐ情報が参照するＡＶＣｌｉｐのアプリケーションタイプ（ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ）がある。かかるＣｌｉｐＩｎｆｏを参照することで、アプリケーションタイプによってＭａｉｎＣｌｉｐかＳｕｂＣｌｉｐかや、動画を含んでいるのか静止画（スライドショー）を含んでいるのかなどが識別できる。またＣｌｉｐＩｎｆｏには、上述したＴＳ＿ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅが記述されている。
Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏは、ＡＶＣｌｉｐに含まれる、１つ以上のＳＴＣ−Ｓｅｑｕｅｎｃｅ、ＡＴＣ−Ｓｅｑｕｅｎｃｅについての情報である。これらの情報を設けておくことの意義は、ＳＴＣ、ＡＴＣの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、ＡＶＣｌｉｐ内において同じ値のＰＴＳ，ＡＴＳが出現する可能性があり、再生時に不都合が生じる。ＳＴＣ，ＡＴＣが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏは設けられている。【００３６】  Ｐｒｏｇｒａｍ  Ｉｎｆｏとは、Ｐｒｏｇｒａｍ内容が一定である区間（Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅ）を示す情報である。Ｐｒｏｇｒａｍとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅ情報を設けておくことの意義は、Ｐｒｏｇｒａｍ内容の変化点を、予め再生装置に通知するためである。ここでのＰｒｏｇｒａｍ内容の変化点とは、ビデオストリームのＰＩＤが変化したり、ビデオストリームの種類がＳＤ画像からＨＤ画像に変化している点等をいう。
続いてＣｈａｒａｃｔｅｒｉｓｔｉｃ  Ｐｏｉｎｔ  Ｉｎｆｏについて説明する。図中の引き出し線ｃｕ２は、ＣＰＩの構成をクローズアップしている。引き出し線ｃｕ２に示すように、ＣＰＩは、Ｎｅ個のＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ［０］〜ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ［Ｎｅ−１］）からなる。これらＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、ＡＶＣｌｉｐに属する個々のエレメンタリストリームについてのＥＰ＿ｍａｐである。ＥＰ＿ｍａｐは、１つのエレメンタリストリーム上において、Ａｃｃｅｓｓ  Ｕｎｉｔが存在するエントリー位置のパケット番号（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を、エントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）と対応づけて示す情報である。図中の引き出し線ｃｕ３は、ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤの内部構成をクローズアップしている。【００３７】  これによると、ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、Ｎｃ個のＥＰ＿Ｈｉｇｈ（ＥＰ＿Ｈｉｇｈ（０）〜ＥＰ＿Ｈｉｇｈ（Ｎｃ−１））と、Ｎｆ個のＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ（０）〜ＥＰ＿Ｌｏｗ（Ｎｆ−１））とからなることがわかる。ここでＥＰ＿Ｈｉｇｈは、Ａｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの上位ビットを表す役割をもち、ＥＰ＿Ｌｏｗは、Ａｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの下位ビットを示す役割をもつ。【００３８】  図中の引き出し線ｃｕ４は、ＥＰ＿Ｈｉｇｈの内部構成をクローズアップしている。この引き出し線に示すように、ＥＰ＿Ｈｉｇｈ（ｉ）は、ＥＰ＿Ｌｏｗに対する参照値である『ｒｅｆ＿ｔｏ＿ＥＰ＿Ｌｏｗ＿ｉｄ［ｉ］』と、Ａｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＰＴＳの上位ビットを示す『ＰＴＳ＿ＥＰ＿Ｈｉｇｈ［ｉ］』と、Ａｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＳＰＮの上位ビットを示す『ＳＰＮ＿ＥＰ＿Ｈｉｇｈ［ｉ］』とからなる。ここでｉとは、任意のＥＰ＿Ｈｉｇｈを識別するための識別子である。【００３９】  図中の引き出し線ｃｕ５は、ＥＰ＿Ｌｏｗの構成をクローズアップしている。引き出し線ｃｕ５に示すように、ＥＰ＿Ｌｏｗは、対応するＡｃｃｅｓｓ  ＵｎｉｔがＩＤＲピクチャか否かを示す『ｉｓ＿ａｎｇｌｅ＿ｃｈａｎｇｅ＿ｐｏｉｎｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔのサイズを示す『Ｉ＿ｅｎｄ＿ｐｏｓｉｔｉｏｎ＿ｏｆｆｓｅｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＰＴＳの下位ビットを示す『ＰＴＳ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＳＰＮの下位ビットを示す『ＳＰＮ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』とからなる。ここでＥＰ＿Ｌｏｗ＿ｉｄとは、任意のＥＰ＿Ｌｏｗを識別するための識別��である。【００４０】  ＜Ｃｌｉｐ情報の説明その２．ＥＰ＿ｍａｐ＞
以下、具体例を通じて、ＥＰ＿ｍａｐについて説明する。図１１は、映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。第１段目は、表示順序に配置された複数のピクチャ（ＭＰＥＧ４−ＡＶＣに規定されたＩＤＲピクチャ、Ｉピクチャ、Ｂピクチャ、Ｐピクチャ）を示し、第２段目は、そのピクチャにおける時間軸を示す。第４段目は、ＢＤ−ＲＯＭ上のＴＳパケット列を示し、第３段目は、ＥＰ＿ｍａｐの設定を示す。【００４１】  第２段目の時間軸において、時点ｔ１〜ｔ７に、Ａｃｃｅｓｓ  ＵｎｉｔとなるＩＤＲピクチャ及びＩピクチャが存在するものとする。そしてこれらのｔ１〜ｔ７の時間間隔が、１秒程度であるとすると、映画に用いられるビデオストリームにおけるＥＰ＿ｍａｐは、ｔ１〜ｔ７をエントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）として示し、これに対応づけてエントリー位置（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を示すよう、設定される。
＜ＰｌａｙＬｉｓｔ情報＞
続いて、ＰｌａｙＬｉｓｔ情報について説明する。拡張子“ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ）は、ＰｌａｙＬｉｓｔ（ＰＬ）情報を格納したファイルである。【００４２】  図１２は、ＰｌａｙＬｉｓｔ情報のデータ構造を示す図であり、本図において、引き出し線ｍｐ１に示すようにＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈを定義するＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））と、チャプターを定義するＰｌａｙＬｉｓｔＭａｒｋ情報（ＰｌａｙＬｉｓｔＭａｒｋ（））を含む。
＜ＰｌａｙＬｉｓｔ情報の説明その１．ＭａｉｎＰａｔｈ情報＞
先ずＭａｉｎＰａｔｈについて説明する。ＭａｉｎＰａｔｈは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。【００４３】  ＭａｉｎＰａｔｈは、矢印ｍｐ１で示すように複数のＰｌａｙＩｔｅｍ情報＃１・・・・＃ｍから定義される。ＰｌａｙＩｔｅｍ情報は、ＭａｉｎＰａｔｈを構成する１つの論理的な再生区間を定義する。ＰｌａｙＩｔｅｍ情報の構成は、引き出し線ｈｓ１によりクローズアップされている。この引き出し線に示すようにＰｌａｙＩｔｅｍ情報は、再生区間のＩＮ点及びＯｕｔ点が属するＡＶＣｌｉｐの再生区間情報のファイル名を示す『Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、ＡＶＣｌｉｐの符号化方式を示す『Ｃｌｉｐ＿ｃｏｄｅｃ＿ｉｄｅｎｔｉｆｉｅｒ』と、ＰｌａｙＩｔｅｍがマルチアングルを構成するか否かを示す『ｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅ』と、このＰｌａｙＩｔｅｍ（カレントＰｌａｙＩｔｅｍ）と、その１つ前のＰｌａｙＩｔｅｍ（ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ）との接続状態を示す『ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』と、このＰｌａｙＩｔｅｍが対象としているＳＴＣ＿Ｓｅｑｕｅｎｃｅを一意に示す『ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ［０］』と、再生区間の始点を示す時間情報『Ｉｎ＿ｔｉｍｅ』と、再生区間の終点を示す時間情報『Ｏｕｔ＿ｔｉｍｅ』と、このＰｌａｙＩｔｅｍにおいてマスクすべきユーザオペレーションがどれであるかを示す『ＵＯ＿ｍａｓｋ＿ｔａｂｌｅ』と、このＰｌａｙＩｔｅｍの途中へのランダムアクセスを許可するか否かを示す『ＰｌａｙＩｔｅｍ＿ｒａｎｄｏｍ＿ａｃｃｅｓｓ＿ｆｌａｇ』と、このＰｌａｙＩｔｅｍの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Ｓｔｉｌｌ＿ｍｏｄｅ』と、『ＳＴＮ＿ｔａｂｌｅ』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『Ｉｎ＿ｔｉｍｅ』、再生区間の終点を示す時間情報『Ｏｕｔ＿ｔｉｍｅ』の組みであり、再生経路情報とは、この『Ｉｎ＿ｔｉｍｅ』及び『Ｏｕｔ＿ｔｉｍｅ』の組みから構成される。【００４４】  図１３は、ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。第１段目は、ＰｌａｙＬｉｓｔ情報がもつ時間軸（ＰｌａｙＬｉｓｔ時間軸）を示す。第２段目から第５段目は、ＥＰ＿ｍａｐにて参照されているビデオストリームを示す。
ＰｌａｙＬｉｓｔ情報は、ＰｌａｙＩｔｅｍ情報＃１，＃２という２つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ情報＃１，＃２のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、２つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第１段目に示すＰｌａｙＬｉｓｔ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる再生経路の定義が可能になる。【００４５】  以上が、ＢＤ−ＲＯＭ１００についての説明である。
＜ローカルストレージ２００＞
続いて、本発明にかかる記録媒体である、ローカルストレージ２００について説明する。図１４は、ローカルストレージ２００の内部構成を示す図である。本図に示すように、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。【００４６】  本図の第４段目にローカルストレージ２００を示し、第３段目にローカルストレージ２００上のトラックを示す。本図のトラックは、ローカルストレージ２００の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてローカルストレージ２００の応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。【００４７】  本図のディレクトリ構造においてＲＯＯＴディレクトリの配下には、「ｏｒｇａｎｉｚａｔｉｏｎ＃１」というサブディレクトリがあり、その配下に、「ｄｉｓｃ＃１」というサブディレクトリがある。ディレクトリ「ｏｒｇａｎｉｚａｔｉｏｎ＃１」とは、映画作品の特定のプロバイダに割り当てられたディレクトリである。「ｄｉｓｃ＃１」は、そのプロバイダが提供したＢＤ−ＲＯＭのそれぞれに割り当てられたディレクトリである。【００４８】  特定のプロバイダに対応するディレクトリに、各ＢＤ−ＲＯＭに対応するディレクトリを設けることにより、各ＢＤ−ＲＯＭについてのダウンロードデータが個別に格納される。このサブディレクトリの配下に、ＢＤ−ＲＯＭに格納されていたのと同様、ＰｌａｙＬｉｓｔ情報（００００２．ｍｐｌｓ）、Ｃｌｉｐ情報（００００３．ｃｌｐｉ，００００４．ｃｌｐｉ）、ＡＶＣｌｉｐ（００００３．ｍ２ｔｓ，００００４．ｍ２ｔｓ）が格納されている。
続いて、ローカルストレージ２００の構成要素となる、ＰｌａｙＬｉｓｔ情報、Ｃｌｉｐ情報、ＡＶＣｌｉｐについての説明する。【００４９】  ＜ローカルストレージ２００の構成その１．ＡＶＣｌｉｐ＞
ローカルストレージ２００上のＡＶＣｌｉｐ（００００３．ｍ２ｔｓ，００００４．ｍ２ｔｓ）は、ＳｕｂＣｌｉｐを構成する。このＳｕｂＣｌｉｐに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。ＳｕｂＣｌｉｐを多重分離することで得られるパーシャルトランスポートストリームを“セカンダリＴＳ”という。かかるセカンダリＴＳは、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを構成するものである。以降、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションについて説明する。
（Ｏｕｔ−ｏｆ−ＭＵＸアプリケーション）
Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションとは、例えば、ＢＤ−ＲＯＭ上のプライマリＴＳと、ネットワークなどを介して取得して、ローカルストレージに記録されたセカンダリＴＳの２つのＴＳを同時に再生選択することで、この２本のＴＳ間で様々なエレメンタリストリームの組み合わせを可能とするアプリケーションである。【００５０】  図１５は、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションを構成するプライマリＴＳ、セカンダリＴＳが、ＢＤ−ＲＯＭ再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、ＢＤ−ＲＯＭ再生装置の内部構成のうち、ＢＤ−ＲＯＭドライブ装置、ローカルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、ストリームの多重分離を行うＰＩＤ  Ｆｉｌｔｅｒを示す。そして本図におけるプライマリＴＳ（Ｖｉｄｅｏ１，Ａｕｄｉｏ１（Ｅｎｇｌｉｓｈ），Ａｕｄｉｏ２（Ｓｐａｎｉｓｈ），ＰＧ１（Ｅｎｇｌｉｓｈ  Ｓｕｂｔｉｔｌｅ），ＩＧ１（Ｅｎｇｌｉｓｈ  Ｍｅｎｕ））、セカンダリＴＳ（Ａｕｄｉｏ２（Ｊａｐａｎｅｓｅ），Ａｕｄｉｏ３（Ｋｏｒｅａｎ），ＰＧ２（Ｊａｐａｎｅｓｅ  Ｓｕｂｔｉｔｌｅ），ＰＧ３（Ｋｏｒｅａｎ  Ｓｕｂｔｉｔｌｅ），ＩＧ２（Ｊａｐａｎｅｓｅ  Ｍｅｎｕ），ＩＧ３（Ｋｏｒｅａｎ  Ｍｅｎｕ））は、それぞれＢＤ−ＲＯＭ、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Ａｕｄｉｏ  １）とスペイン語（Ａｕｄｉｏ  ２）しか記録されていないため、日本語吹き替えなどをこのディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供する日本語吹き替え（Ａｕｄｉｏ  ２）の入ったセカンダリＴＳを、ローカルストレージにダウンロードすれば、日本語吹き替え音声（Ａｕｄｉｏ  ２）と、日本語字幕（ＰＧ  ２）と、日本語メニュー画面（ＩＧ  ２）とを、デコーダに送り込むことができる。こうすることでユーザーは、日本語吹き替え音声（Ａｕｄｉｏ  ２）と、日本語字幕（ＰＧ  ２）とを、日本語メニュー画面（ＩＧ  ２）から選択して、映像（Ｖｉｄｅｏ１）と共に再生することができる。【００５１】  Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションは、同時に再生される２つのＴＳの中に格納されたエレメンタリストリームの種別ごとに１つまで（言い換えれば、プライマリＴＳとセカンダリＴＳに格納されているビデオ１本、オーディオ１本、字幕１本、メニュー１本まで）という制限下で、ユーザーが自由に、音声及び字幕を選択することができる。
全てのＢＤ−ＲＯＭ再生装置はプライマリＴＳ単体をデコードできる能力は持つが、２つのＴＳを同時にデコードする能力はない。したがって、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションを制限なく導入した場合には、ハードウェアの大規模化や、ソフトウェアを多く追加せざるを得なくなり、ＢＤ−ＲＯＭ再生装置のコストアップに繋がる。そのため、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションの実現にあたっては、プライマリＴＳだけをデコードできるリソース上で、Ｏｕｔ＿ｏｆ＿ＭＵＸのアプリケーションを実現することができるかどうかどうかが鍵となる。【００５２】  エレメンタリストリームの種別ごとに１つまで、再生を許可するという制限は、プライマリＴＳのエレメンタリストリームをセカンダリＴＳのエレメンタリストリームで「入れ換える」と考えればよい。そのようにすることで、１本のＴＳをデコードするリソース上で、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現することができ、デコーダ側のコストアップを抑制することができる。本図の例では、プライマリＴＳのオーディオ、字幕（ＰＧ）、メニュー（ＩＧ）ストリームをセカンダリＴＳのそれらと入れ換えている。【００５３】  セカンダリＴＳは、上述したようなローカルストレージである内蔵ＨＤＤの他、フラッシュメモリや一次記憶メモリ、ネットワーク越しのＨＤＤや直接ネットワークを介したストリーミングなどから入力されることもある。説明の便宜上、セカンダリＴＳは、図１に示したような内蔵型のＨＤＤから供給されるものとする。
＜ローカルストレージ２００の構成その２．Ｃｌｉｐ情報＞
ローカルストレージ上に存在するＣｌｉｐ情報（００００３．ｃｌｐｉ，００００４．ｃｌｐｉ）は、基本的には、ＢＤ−ＲＯＭに記録されているものと同じデータ構造をもつ。ここでローカルストレージ上のＣｌｉｐ情報のＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅは、ＢＤ−ＲＯＭからのＡＶＣｌｉｐ読み出しと同じビットレートに設定されている。つまりＳｕｂＣｌｉｐのＣｌｉｐ情報に記述されたＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅと、ＭａｉｎＣｌｉｐのＣｌｉｐ情報に記述されたＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅとは同一である。仮に、ＭａｉｎＣｌｉｐのＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅの値と、ＳｕｂＣｌｉｐのＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅとが異なると、夫々のＳｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒから、バッファに送り込むまでのデータレートがどちらのＴＳを送り込むかによって異なることになり、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションは１つの入力ＴＳと仮定できるという仮定が成り立たなくなる。【００５４】  また、２つのＴＳ間で再生されるべきエレメンタリストリームは、自在に選択されるので、プライマリＴＳのオーディオが選択されればＳｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒからデコーダ内のバッファまでが、プライマリＴＳ用のビットレートに設定され、セカンダリＴＳのオーディオが選択されるとＳｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒからデコーダ内のバッファまでが、セカンダリＴＳのためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑になってしまうからである。
＜ローカルストレージ２００の構成その２．ＰｌａｙＬｉｓｔ情報＞
続いて、ローカルストレージ２００上のＰｌａｙＬｉｓｔ情報について説明する。拡張子“ｍｐｌｓ”が付与されたファイル（００００２．ｍｐｌｓ）は、ＭａｉｎＰａｔｈ、Ｓｕｂｐａｔｈと呼ばれる２種類の再生経路を束ねたものをＰｌａｙｌｉｓｔ（ＰＬ）として定義する情報である。図１６は、ＰｌａｙＬｉｓｔ情報のデータ構造を示す図であり、本図に示すようにＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈを定義するＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））と、チャプターを定義するＰｌａｙＬｉｓｔＭａｒｋ情報（ＰｌａｙＬｉｓｔＭａｒｋ（））と、Ｓｕｂｐａｔｈを定義するＳｕｂｐａｔｈ情報（Ｓｕｂｐａｔｈ（））とからなる。かかるＰｌａｙＬｉｓｔ情報の内部構成、及び、ＰｌａｙＩｔｅｍ情報の内部構成は、ＢＤ−ＲＯＭのものと同じであり、説明を省略する。以降、Ｓｕｂｐａｔｈ情報について説明する。
＜ＰｌａｙＬｉｓｔ情報の説明その１．Ｓｕｂｐａｔｈ情報＞
ＭａｉｎＰａｔｈが、主映像たるＭａｉｎＣｌｉｐに定義される再生経路であるのに対し、Ｓｕｂｐａｔｈは、ＭａｉｎＰａｔｈと同期すべきＳｕｂＣｌｉｐに対して定義される再生経路である。【００５５】  図１７は、Ｓｕｂｐａｔｈ情報の内部構成をクローズアップして示す図である。本図における矢印ｈｃ０に示すようにＳｕｂｐａｔｈ情報は、ＳｕｂＣｌｉｐの類型を示すＳｕｂＰａｔｈ＿ｔｙｐｅと、１つ以上のＳｕｂＰｌａｙＩｔｅｍ情報（・・・ＳｕｂＰｌａｙＩｔｅｍ（）・・・）とを含む。
図中の引き出し線ｈｃ１は、ＳｕｂＰｌａｙＩｔｅｍ情報の構成をクローズアップしている。ＳｕｂＰｌａｙＩｔｅｍ情報は、図中の矢印ｈｃ１に示すように『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』、『Ｃｌｉｐ＿ｃｏｄｅｃ＿ｉｄｅｎｔｉｆｉｅｒ』、『ＳＰ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』、『ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ［０］』、『ＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ｔｉｍｅ』、『ＳｕｂＰｌａｙＩｔｅｍ＿Ｏｕｔ＿ｔｉｍｅ』、『ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄ』、『ｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍ』からなる。【００５６】  『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』は、Ｃｌｉｐ情報のファイル名を記述することにより、ＳｕｂＰｌａｙＩｔｅｍに対応するＳｕｂＣｌｉｐを一意に指定する情報である。
『Ｃｌｉｐ＿ｃｏｄｅｃ＿ｉｄｅｎｔｉｆｉｅｒ』は、ＡＶＣｌｉｐの符号化方式を示す。
『ＳＰ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』は、このＳｕｂＰｌａｙＩｔｅｍ（カレントＳｕｂＰｌａｙＩｔｅｍ）と、その１つ前のＳｕｂＰｌａｙＩｔｅｍ（ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ）との接続状態を示す。【００５７】  『ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ［０］』は、このＰｌａｙＩｔｅｍが対象としているＳＴＣ＿Ｓｅｑｕｅｎｃｅを一意に示す。
『ＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ｔｉｍｅ』は、ＳｕｂＣｌｉｐの再生時間軸上における、ＳｕｂＰｌａｙＩｔｅｍの始点を示す情報である。
『ＳｕｂＰｌａｙＩｔｅｍ＿Ｏｕｔ＿ｔｉｍｅ』は、ＳｕｂＣｌｉｐの再生時間軸上における、ＳｕｂＰｌａｙＩｔｅｍの終点を示す情報である。【００５８】  『ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄ』は、ＭａｉｎＰａｔｈを構成するＰｌａｙＩｔｅｍのうち、本ＳｕｂＰｌａｙＩｔｅｍが同期すべきものを一意に指定する情報である。ＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ｔｉｍｅは、このｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄで指定されたＰｌａｙ  Ｉｔｅｍの再生時間軸上に存在する。
『ｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍ』は、ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄで指定されたＰｌａｙ  Ｉｔｅｍの再生時間軸上において、ＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ｔｉｍｅで指定されたＳｕｂＰｌａｙＩｔｅｍの始点が、どこに存在するかを示す。【００５９】  ＜ＳｕｂＰａｔｈ情報についての詳細その２．三者の関係＞
ここでの三者とは、ローカルストレージ２００上のＳｕｂＣｌｉｐ、ローカルストレージ２００上のＰｌａｙＬｉｓｔ情報、ＢＤ−ＲＯＭ上のＭａｉｎＣｌｉｐの三者をいう。
図１８は、ローカルストレージ２００上のＳｕｂＣｌｉｐと、ローカルストレージ２００上のＰｌａｙＬｉｓｔ情報と、ＢＤ−ＲＯＭ上のＭａｉｎＣｌｉｐとの対応を示す図である。本図において第１段目は、ローカルストレージ２００上に存在するＳｕｂＣｌｉｐを示す。この第１段目に示すように、ローカルストレージ２００上のＳｕｂＣｌｉｐ内のセカンダリＴＳには、オーディオストリーム、ＰＧストリーム、ＩＧストリームといった種別がある。これらのうち何れかが、ＳｕｂＰａｔｈとして同期再生に供されることになる。【００６０】  第２段目は、ＰｌａｙＬｉｓｔ情報により定義される２つの時間軸を示す。第２段目のうち下側の時間軸は、ＰｌａｙＩｔｅｍ情報により定義されるＰｌａｙＬｉｓｔ時間軸を示し、上側の時間軸はＳｕｂＰｌａｙＩｔｅｍにより定義されるＳｕｂＰｌａｙＩｔｅｍ時間軸を示す。
本図に示すように、ＳｕｂＰｌａｙＩｔｅｍ情報のＳｕｂＰｌａｙＩｔｅｍ＿Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、ＳｕｂＣｌｉｐを格納した．ｍ２ｔｓファイルのうち、どれを再生区間の対象として選ぶかという、ＳｕｂＣｌｉｐ選択の役割を果たしていることがわかる。【００６１】  そしてＳｕｂＰｌａｙＩｔｅｍ．ＩＮ＿ｔｉｍｅ、ＳｕｂＰｌａｙＩｔｅｍ．Ｏｕｔ＿ｔｉｍｅは、ＳｕｂＣｌｉｐ上の、再生区間の始点及び終点を定義するという役割を果たしていることがわかる。
矢印Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、どのＰｌａｙＩｔｅｍとの同期を意図しているかという同期指定の役割を果たし、ｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍは、ＰｌａｙＬｉｓｔ時間軸上におけるＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ｔｉｍｅの位置を決める役割を果たす。【００６２】  以上が、ＳｕｂＰａｔｈ情報についての説明である。
＜ＳＴＮ＿ｔａｂｌｅ＞
このローカルストレージ２００上のＰｌａｙＬｉｓｔ情報において特徴的であるのは、ＳＴＮ＿Ｔａｂｌｅである。以降、ローカルストレージ２００上のＰｌａｙＬｉｓｔ情報について説明する。
ＳＴＮ＿ｔａｂｌｅは、ＰｌａｙＩｔｅｍ情報のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＭａｉｎＣｌｉｐに多重化された複数エレメンタリストリーム、及び、ＳｕｂＰｌａｙＩｔｅｍ情報のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されたＳｕｂＣｌｉｐに多重化されている複数エレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示すテーブルである。ＰｌａｙＬｉｓｔ情報におけるＳＴＮ＿Ｔａｂｌｅにおいて、同時に再生することが許可されている複数エレメンタリストリームは、いわゆる“システムストリーム”を構成することになる。【００６３】  具体的にいうとＳＴＮ＿ｔａｂｌｅは、ＭａｉｎＣｌｉｐに多重化されている複数エレメンタリストリーム、ＳｕｂＣｌｉｐに多重化されているエレメンタリストリームのそれぞれについてのＳｔｒｅａｍ＿ｅｎｔｒｙを、Ｓｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅと対応付けることで構成される。
図１９（ａ）は、ＳＴＮ＿ｔａｂｌｅの内部構成を示す図である。本図に示すようにＳＴＮ＿ｔａｂｌｅは、ＳＴＮ＿ｔａｂｌｅにおけるｅｎｔｒｙと、ａｔｔｒｉｂｕｔｅとの組み（ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅ）を複数含み、これらｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みの個数（ｎｕｍｂｅｒ＿ｏｆ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＰＧ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＩＧ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ）を示すデータ構造になっている。【００６４】  ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みは、図中の括弧記号”｛”に示すように、ＰｌａｙＩｔｅｍにおいて再生可能なビデオストリーム、オーディオストリーム、ＰＧストリーム、ＩＧストリームのそれぞれに対応している。
ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細について説明する。【００６５】  図１９（ｂ）は、ビデオストリームに対応したＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅを示す図である。
ビデオストリームにおけるＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅは、ビデオストリームの表示方式を示す『Ｖｉｄｅｏ＿ｆｏｒｍａｔ』と、ビデオストリームの表示周波数を示す『ｆｒａｍｅ＿ｒａｔｅ』等を含む。
図１９（ｃ）は、オーディオストリームに対応したＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅを示す図である。
オーディオストリームにおけるＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅは、オーディオストリームの符号化方式を示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するオーディオストリームのチャネル構成を示す『ａｕｄｉｏ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｙｐｅ』と、対応するオーディオストリームのサンプリング周波数を示す対応する『Ｓａｍｐｌｉｎｇ＿ｆｒｅｑｕｅｎｃｙ』と、オーディオストリームの言語属性を示す『ａｕｄｉｏ＿ｌａｎｇｕａｇｅ  ｃｏｄｅ』からなる。【００６６】  図１９（ｄ）は、ビデオストリームにおけるＳｔｒｅａｍ＿ｅｎｔｒｙを示す図である。本図に示すように、ビデオストリームのＳｔｒｅａｍ＿ｅｎｔｒｙは、ビデオストリームの多重分離に用いられるＰＩＤを示す「ｒｅｆ＿ｔｏ＿Ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿Ｍａｉｎ＿Ｃｌｉｐ」を含む。
ＭａｉｎＣｌｉｐにて多重化されているオーディオストリーム、ＩＧストリーム、ＰＧストリームのＳｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅは、この図１９（ｄ）の形式になっている。【００６７】  ＜再生が許可されているエレメンタリストリームのデータ量制限＞
ＳＴＮ＿ｔａｂｌｅは、ＢＤ−ＲＯＭから読み出されるエレメンタリストリーム、ローカルストレージから読み出されるエレメンタリストリームのうち、再生が許可されているものを示すが、かかるＳＴＮ＿ｔａｂｌｅが、無制限に、エレメンタリストリームの再生を許可しているとなると、デコーダシステムの破綻を招く恐れがある。【００６８】  その理由は、以下の通りである。ＭＰＥＧ２のデコーダシステム標準によると、１つのトランスポートストリームにおけるＡＴＣ時間軸のＴＳパケット間には、オーバーラップが存在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせるための基本原則である。一方、ＢＤ−ＲＯＭにおけるストリームの再生が許可されると共に、ローカルストレージにおけるストリームの再生が許可されており、ＢＤ−ＲＯＭからのＡＶＣｌｉｐ再生と、ローカルストレージからのＡＶＣｌｉｐ再生とを同時に実行する場合、ＢＤ−ＲＯＭからのＴＳパケットと、ローカルストレージからのＴＳパケットとにオーバーラップが生じてしまう。【００６９】  そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課している。
デコードエレメンタリストリームとは、ＳＴＮ＿ｔａｂｌｅにおいて再生が許可されていて、一緒に再生するため、選択されたビデオストリーム、オーディオストリーム、ＰＧストリーム、ＩＧストリームである。デコードエレメンタリストリームには、ローカルストレージからの読み出されるものと、ＢＤ−ＲＯＭから読み出されるものの両者がある。【００７０】  デコードエレメンタリストリームに課される制限とは、ＳＴＮ＿ｔａｂｌｅにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないＡＶＣｌｉｐ（ＭａｉｎＣｌｉｐ，ＳｕｂＣｌｉｐ）を構成するＴＳパケット（Ｄｅｃｏｄｉｎｇ  ＴＳパケット）の、１秒当たりのビット量は４８Ｍｂｉｔ以下になるというものである。
この１秒という単位時間は、“Ｗｉｎｄｏｗ”と呼ばれ、ＡＴＣ  Ｓｅｑｕｅｎｃｅの時間軸上の任意の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのような１秒の期間においても、この４８Ｍｂｉｔ以下という条件を満たす必要がある。【００７１】  図２０は、ＢＤ−ＲＯＭから読み出されたＴＳパケットと、ローカルストレージから読み出されたＴＳパケットとを示し、これらのＴＳパケットのうち、デコーダに供給されるものを示す。本図の第１段目は、ＢＤ−ＲＯＭから読み出された複数のＴＳパケット、第３段目は、ローカルストレージから読み出された複数のＴＳパケットを示す。これら第１段目、第３段目のＴＳパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構成するＴＳパケット（Ｄｅｃｏｄｉｎｇ  ＴＳパケット）である。本図における第２段目は、第１段目に示したＤｅｃｏｄｉｎｇ  ＴＳパケット、第３段目に示したＤｅｃｏｄｉｎｇ  ＴＳパケットのうち、１秒という期間に属すものを示す。上述したように、ＭＰＥＧ２のデコーダシステム標準によると、１つのトランスポートストリームにおけるＡＴＣ時間軸のＴＳパケット間には、オーバーラップが存在してはならない。しかし、本図によると、ＡＴＣ時間軸において、ＴＳパケット間のオーバーラップｒｐ１，ｒｐ２，ｒｐ３が発生していることがわかる。このように、Ｗｉｎｄｏｗという単位時間において、ＴＳパケット動作のオーバーラップが許容されているのである。しかし、ＭＰＥＧ２のデコーダシステム標準にはない別の要件が課されている。それが上述した、１Ｗｉｎｄｏｗ当たり４８Ｍｂｉｔ以下という制限である。第４段目は、この第２段目に示す、Ｄｅｃｏｄｉｎｇ  ＴＳパケットが満たすべき条件を数式で表している。この数式の意味は、上述したＤｅｃｏｄｉｎｇ  ＴＳパケットの個数を、ビット数に換算した値（ＴＳパケットのバイト数である１８８をかけ、ビット数８で表した値）が、４８Ｍｂｉｔ以下になるというものである。【００７２】  任意の１秒という期間において、Ｄｅｃｏｄｉｎｇ  ＴＳパケットに以上のような条件を課すのが、本実施形態におけるビット量の制限である。Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションのためのオーサリング時には、Ｓｏｕｒｃｅパケット列において、かかるＷｉｎｄｏｗを、１パケットずつシフトさせつつ、１秒という期間内の、Ｄｅｃｏｄｉｎｇ  ＴＳパケットのビット数が、４８Ｍｂｉｔ以下という制限を満たすかどうかをチェックする。もし、制限を満たせば、次のＴＳパケットにＷｉｎｄｏｗをシフトさせ、制限を満たさねば、ＢＤ−ＲＯＭ規格に違反していると断定する。そして、かかるシフトを繰り返した結果、ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅが、最後のＳｏｕｒｃｅパケットに達すれば、当該Ｓｏｕｒｃｅパケットは、ＢＤ−ＲＯＭ規格に整合しているとの判定を下す。【００７３】  ＜Ｗｉｎｄｏｗのシフト＞
ＴＳパケットのそれぞれには、２７ＭＨｚの時間精度をもつＡＴＳが付与されている。ＡＴＣ時間軸上の座標は、１／２７，０００，０００秒という時間精度をもつが、このＡＴＣ時間軸上の各座標に、ＡＴＳが存在するとは限らない。ＡＴＣ時間軸には、ＡＴＳがまったく存在しない期間や、ＡＴＳが存在する期間が不規則に現れる。ＡＴＳの出現にバラツキがあるので、Ｗｉｎｄｏｗをシフトするにあたって、Ｉｎ＿Ｔｉｍｅから１秒後にＡＴＳが存在しない場合、ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅをどのように調整するかが問題になる。【００７４】  ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅは、原則としてＩｎ＿Ｔｉｍｅの１秒として設定される。ここでＡＴＣ時間軸において、Ｉｎ＿Ｔｉｍｅの１秒後にあたる座標にＡＴＳが存在すれば、Ｉｎ＿Ｔｉｍｅ＋１秒の座標を、Ｏｕｔ＿Ｔｉｍｅとする。もしＩｎ＿Ｔｉｍｅの１秒後にあたる座標にＡＴＳが存在しなければ、Ｉｎ＿Ｔｉｍｅ＋１秒以降であって、ＡＴＳが初めて現れるＡＴＣ時間軸の座標を、Ｏｕｔ＿Ｔｉｍｅとする。ＡＴＳの空白期間を考慮しながらＯｕｔ＿Ｔｉｍｅを調整しつつ、Ｗｉｎｄｏｗをシフトしてゆくので、Ｗｉｎｄｏｗがシフトする度に、異なるビット値が算出される。Ｉｎ＿ＴｉｍｅをＩＴＳパケットずつシフトしてゆき、これに伴いＯｕｔ＿Ｔｉｍｅを調整することで、ＡＴＣ時間軸におけるビット値の遷移を緻密に計算してゆくことができる。【００７５】  図２１は、Ｗｉｎｄｏｗのシフトを示す図である。（ａ）〜（ｄ）のそれぞれのうち、上段はベリファイの対象となるＳｏｕｒｃｅパケット列を示し、下段は、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅを示す。同図（ａ）では、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅは、Ｓｏｕｒｃｅパケット＃ｉを指定している。このＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒後に存在するＴＳパケット＃ｊが、ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅに設定される。
同図（ｂ）では、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅは、Ｓｏｕｒｃｅパケット＃ｉ＋１を指定している。一方、このＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒後において、Ｓｏｕｒｃｅパケット＃ｊ＋１にあたる座標には、ＳｏｕｒｃｅパケットのＡＴＳが存在しない。この（ｂ）におけるＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅは、ＴＳパケット＃ｊを越えたものになるが、ＴＳパケット＃ｊの直後に、Ｓｏｕｒｃｅパケットが存在しないため、（ｂ）のＷｉｎｄｏｗにおけるビットレートは、（ａ）のＷｉｎｄｏｗにおけるビットレートより少なくなってしまう。これでは、（ｂ）のＷｉｎｄｏｗは、チェックに値しなくなる。そこで、Ｏｕｔ＿Ｔｉｍｅの調整により、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒以降に初めて現れるＴＳパケット＃ｊ＋２を、ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅにする。Ｏｕｔ＿Ｔｉｍｅをこのように設定すれば、（ｂ）のＷｉｎｄｏｗは、チェックに値するものとなる。【００７６】  同図（ｃ）では、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅは、Ｓｏｕｒｃｅパケット＃ｉ＋２を指定している。一方、このＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒後には、Ｓｏｕｒｃｅパケット＃ｊ＋２が位置している。この（ｃ）のＷｉｎｄｏｗは、ＴＳパケットの数が、（ｂ）のＷｉｎｄｏｗにおける数と変わらず、チェックに値しない。故に、この（ｃ）では、チェックが行われず、更にＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅを進める。
同図（ｄ）では、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅは、Ｓｏｕｒｃｅパケット＃ｉ＋３を指定している。一方、このＷｉｎｄｏｗ＿Ｉｎ＿Ｔｉｍｅから１秒後において、Ｓｏｕｒｃｅパケット＃ｊ＋３にあたる位置には、Ｓｏｕｒｃｅパケットが存在しない。そこで上述したようなＯｕｔ＿Ｔｉｍｅの調整を行い、ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒以降に初めて現れるＴＳパケット＃ｊ＋４を、ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅとする。こうすることで、Ｗｉｎｄｏｗ内のＴＳパケット数は、（ｂ）と違うものとなり、チェックに値する。【００７７】  以上のようなＷｉｎｄｏｗシフトを伴う、ビット量チェックをオーサリング時に実行することで、ローカルストレージ及びＢＤ−ＲＯＭからＴＳパケットが読み出され、デコーダに供給されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。
以上のＷｉｎｄｏｗシフトによる保障を、図２２〜図２６の具体例を参照しながら説明する。
図２２の第１段目は、ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージから読み出されたＴＳパケットのデータ量の時間的推移を示すグラフである。横軸は時間軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、ＢＤ−ＲＯＭ及びローカルストレージからの読み出し時のビット量は、破線の曲線のように推移する。【００７８】  図２２の第２段目は、ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージから読み出されたＴＳパケットのうち、デコーダに供給されるものの合計のデータ量を示す。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量は、ＳＴＮ＿ｔａｂｌｅで許可されたストリームに属するＴＳパケットの合計量となる。ワーストケースにおいては、合計の転送量が９６Ｍｂｉｔ近くになり、このデータ量のＴＳパケットが供給されると考えられる。グラフの時間軸を、７つのＷｉｎｄｏｗに分割して、個々のＷｉｎｄｏｗにおける供給量と、Ｗｉｎｄｏｗ毎の転送許容量とを対比する。【００７９】  図２２の第３段目は、この図２２の第２段目におけるグラフを１秒という期間で区切ったものであり、図２３（ａ）（ｂ）は、各Ｗｉｎｄｏｗの転送許容量と、Ｗｉｎｄｏｗにおけるデコーダへの供給量とを対比して示す図である。Ｗｉｎｄｏｗにおける転送許容量は、１秒当たり４８Ｍｂｉｔであり、０．５秒に換算すれば９６Ｍｂｉｔとなる。図中のパターンｐｎ１のハッチングは、デコーダへのデータ供給量を示す。図中のパターンｐｎ２のハッチングは、Ｗｉｎｄｏｗ毎の転送許容量を示す。パターンｐｎ１のハッチングが付された部分の面積が、何れのＷｉｎｄｏｗにおいても、パターンｐｎ２のハッチングが付された部分の面積以下になっている。これは、ＢＤ−ＲＯＭ及びローカルストレージからのデータ供給量が、どのＷｉｎｄｏｗにおいても、Ｗｉｎｄｏｗにおける転送許容量以下に抑えられていることを意味する。【００８０】  ＡＴＣ時間軸上のどの時点においても、１秒当たりのデコーダへの転送許容量は、４８Ｍｂｉｔ以下になるので、たとえ局所的に、デコーダへの転送許容量が９６Ｍｂｉｔ近くになったとしても、４８Ｍｂｉｔ＝９６Ｍｂｉｔ×０．５秒の計算により、かかる９６Ｍｂｉｔでの転送が０．５秒継続することはありえない。従ってデコーダが、このピークが到来する前に、ＢＤ−ＲＯＭ、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダーフロー又はオーバーフローが生じることはない。【００８１】  Ｗｉｎｄｏｗにおける転送許容量、つまり、１秒当たり４８Ｍｂｉｔという数値は、ＭＰＥＧに準拠したデコーダが、バッファに先読みできる数値を、目安にして定めたものである。バッファに先読みできるデータ量が、もっと大きい場合は、１秒当たりのデータ量を更に大きくしたり、またＷｉｎｄｏｗの時間長を更に長くすることができる。このことから、本発明にかかる数値範囲は、１秒当たり４８Ｍｂｉｔというものに、限定されるべきでない。【００８２】  以上が、ＳＴＮ＿ｔａｂｌｅにおいて再生が許可されているセカンダリＴＳにおけるデータ量制限についての説明である。
＜ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報の設定＞
次に、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現する場合の、ＰｌａｙＩｔｅｍにおけるｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、及び、ＳｕｂＰｌａｙＩｔｅｍにおけるｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報の設定について説明する。ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報のフィールドの値、ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報のフィールドの値は“１”，“５”，“６”の値を取る事ができ、それぞれ以下のような意味を持つ。【００８３】  ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ＝１（ＣＣ＝１）：このＰｌａｙＩｔｅｍ（カレントＰｌａｙＩｔｅｍ）と直前のＰｌａｙＩｔｅｍ（ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ）とはシームレス接続される保証がない。つまり、フリーズして再生が途切れることが許容された接続形態（ノンシームレス接続）である。
ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ＝５（ＣＣ＝５）：カレントＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐに多重化されているビデオストリーム、ＰＧストリーム、ＩＧストリームと、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐに多重化されているビデオストリーム、ＰＧストリーム、ＩＧストリームとがシームレス接続される保証がある。一方、ＭａｉｎＣｌｉｐに多重化されているオーディオストリームについてはこの限りではない。【００８４】  ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ＝６（ＣＣ＝６）：カレントＰｌａｙＩｔｅｍとｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍに属するそれぞれのＴＳストリームは論理的に連続であり（時間軸が連続しており、符号化方式も連続している）、オーディオストリーム、ビデオストリームともにシームレス接続される保証がある。
ＳｕｂＰｌａｙＩｔｅｍ＃ｎ内に記述されたｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報は、次のように定義ができる。【００８５】  ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報（ＳＰ＿ＣＣ＝１）：このＳｕｂＰｌａｙＩｔｅｍ（カレントＳｕｂＰｌａｙＩｔｅｍ）と直前のＳｕｂＰｌａｙＩｔｅｍ（ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ）とはシームレス接続される保証がない
ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報（ＳＰ＿ＣＣ＝５）：カレントＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐに多重化されているＰＧストリーム、ＩＧストリームと、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐに多重化されているＰＧストリーム、ＩＧストリームとがシームレス接続される保証がある。一方、ＳｕｂＣｌｉｐに多重化されているオーディオストリームについてはこの限りではない。【００８６】  ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報（ＳＰ＿ＣＣ＝６）：カレントＳｕｂＰｌａｙＩｔｅｍと、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍとに属するそれぞれのＴＳストリームは論理的に連続しており（時間軸が連続しており、符号化方式も連続している）、シームレス接続される保証がある。
Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現するＰｌａｙＩｔｅｍに対して設定されるべきＳｕｂＰｌａｙＩｔｅｍは、ＳｕｂＰｌａｙＩｔｅｍ内のビデオストリームやオーディオストリーム、またはＰＧストリームやＩＧストリームがＰｌａｙＩｔｅｍ内にあったとしても不整合を起こさないようにすべきである。そのため、全く同一の接続条件となる。つまりＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２がＣＣ＝１で接続されるならば、それに対応するＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２もＣＣ＝１で接続される。同様に、ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２がＣＣ＝５で接続されるならば、それに対応するＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２もＣＣ＝５の条件を満たしながら接続される。
以下、図２４、図２５、図２６を参照しながら、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを構成するＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅの関係と、ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報の詳細について説明する。【００８７】  ＜Ｉｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅの関係＞
図２４は、Ｏｕｔ＿ｏｆ＿ＭＵＸを構成するＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍの接続状態を示す図である。本図における第１段目は、ＳｕｂＣｌｉｐ時間軸であり、第２段目、第３段目は、ＳｕｂＰｌａｙＩｔｅｍ時間軸、ＰｌａｙＬｉｓｔ時間軸である。第４段目は、ＭａｉｎＣｌｉｐ時間軸である。本図において、ＰｌａｙＩｔｅｍ側のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”である場合、ＳｕｂＰｌａｙＩｔｅｍ側のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報も、ＳＰ＿ＣＣ＝５になる。【００８８】  図２５は、図２４に示した、ＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、ＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”に設定されている場合の、ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとの関係を示す図である。第１段目、第４段目は図２４と同じである。図２４に示した２つのＰｌａｙＩｔｅｍ（ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２）のうち、ＰｌａｙＩｔｅｍ情報＃１のＩｎ＿Ｔｉｍｅは、時刻ｔ１を表し、Ｏｕｔ＿Ｔｉｍｅは、時刻ｔ２を表す。ＰｌａｙＩｔｅｍ情報＃２のＩｎ＿Ｔｉｍｅは時刻ｔ３、ＰｌａｙＩｔｅｍ情報＃２のＯｕｔ＿Ｔｉｍｅは、時刻ｔ４を表す。【００８９】  ＰｌａｙＩｔｅｍ側の接続状態がＣＣ＝５に設定されていると、ＳｕｂＰｌａｙＩｔｅｍにおけるＳｙｎｃ＿Ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍは、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅと同じ時点を示す。そしてＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと同じ時刻を表す。このように、ＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”である場合、ＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報も“＝５”に設定され、尚且つ、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと同一時点を表す。【００９０】  ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅ、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、それぞれＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔのＰＴＳを参照している。ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとが一致しているということは、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅで参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔのＰＴＳ値が、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅで参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔのＰＴＳ値と同じであることを意味する。そうすると、プライマリＴＳ、セカンダリＴＳは、時間長が同じで、オーサリング時においてＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏ���  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔのＰＴＳが、同じになるよう、エンコードされる必要がある。このようにプライマリＴＳ、セカンダリＴＳを作成しておくことも、ＣＣ＝５、ＳＰ＿ＣＣ＝５を実現するにあたっての条件になる。【００９１】  ＜同期再生するにあたって、参照すべきＳＴＣ値＞
図２６は、ＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値を示す。第２段目、第３段目は、前図に示したものと同じである。第１段目は、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値をグラフ形式で示している。第４段目も、ＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する部分を再生する場合に、参照されるべきＳＴＣ値をグラフ形式で示している。第１段目における横軸は時間軸であり、縦軸は時間軸上の各時点におけるＳＴＣ値を表す。第１段目におけるＳＴＣ値は、ＳｕｂＰｌａｙＩｔｅｍ情報＃１のＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでの期間における単調増加ｚｋ１と、ＳｕｂＰｌａｙＩｔｅｍ情報＃２のＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでの期間における単調増加ｚｋ２とからなる。第４段目におけるＳＴＣ値は、ＰｌａｙＩｔｅｍ情報＃１のＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでの期間における単調増加ｚｋ３と、ＰｌａｙＩｔｅｍ情報＃２のＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでの期間における単調増加ｚｋ４とからなる。【００９２】  ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅは、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅと同じ時点を表すので、上述したグラフにおいて、ＳＴＣの初期値は同じであり、途中の時点においても同じなる。つまり、ＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する任意の時点ｉのＳｏｕｒｃｅパケットをデコーダに供給する際、参照すべきＳＴＣ値であるＳＴＣ２（ｉ）は、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在する同じ時点ｉのＳｏｕｒｃｅパケットをデコーダに供給する際、参照すべきＳＴＣ値であるＳＴＣ１（ｉ）と同じになる。ＳＴＣ値が同じであると、装置内のＳＴＣカウンタは、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置における制御が簡略化される。【００９３】  仮に、上述した図２５、図２６の制限に反し、１つのＰｌａｙＩｔｅｍに対して２つ以上のＳｕｂＰｌａｙＩｔｅｍを準備した場合、そのＳｕｂＰｌａｙＩｔｅｍの境界において、映像や音声が途切れてしまい、ＰｌａｙＩｔｅｍの途中で再生が一時停止するなどの不便が生じる。また、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションにおいて、プライマリＴＳをセカンダリＴＳに入れ換えるという処理を実現する場合、この入れ替えの前後で、ＳＴＣ時間軸を切り替える必要があるので、再生装置における同期制御が複雑化する。一方、ＰｌａｙＩｔｅｍ、もしくはＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅを共に、一連続なＳＴＣ時間軸に定義した場合、上述したような途切れやトランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、１つのＰｌａｙＩｔｅｍに対して同一の開始点、同一の終了点をＳｕｂＰｌａｙＩｔｅｍにもたせるのである。【００９４】  ＜Ｉｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅの誤差＞
ここでＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとの一致は、完全に一致していることを要求するのではなく、多少の誤差を許容する趣旨である。このＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅ間の誤差について説明する。
ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿ＴｉｍｅとなるＳＴＣ時刻は、ＰｌａｙＩｔｅｍがビデオフレームに対して設定される。これに対し、ＳｕｂＰｌａｙＩｔｅｍではオーディオフレームに対して設定されることとなる。何故なら、ＳｕｂＰｌａｙＩｔｅｍは、コメンタリが主用途でビデオストリームが多重化されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションユニットの再生時間長の違いから、開始／終了時刻が合わない。したがって、最低でも、１フレーム未満の誤差を認める必要がある。ＰｌａｙＩｔｅｍ＃ｎとＳｕｂＰｌａｙＩｔｅｍ＃ｎの開始／終了時刻に関して、どちらも同一のＳＴＣ時間軸に対して、
｜（ＰｌａｙＩｔｅｍ＃ｎ．Ｏｕｔ−ＰｌａｙＩｔｅｍ＃ｎ．Ｉｎ）−（ＳｕｂＰｌａｙＩｔｅｍ＃ｎ．Ｏｕｔ＿ｔｉｍｅ−ＳｕｂＰｌａｙＩｔｅｍ＃ｎ．Ｉｎ＿ｔｉｍｅ）｜≦ＰｌａｙＩｔｅｍ＃ｎの中で最小の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間≦１／６０秒
としても規定する。上記左辺の値は、ＰｌａｙＩｔｅｍ＃ｎの中で最大の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間（≦１／２５秒）としても良いし、１秒以下などとしても良い。
以上が、ＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅの関係についての説明である。【００９５】  次に、ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報について詳しく説明する。ＣＣ＝５、ＳＰ＿ＣＣ＝５の条件を満たすには、ＡＶストリームのレベル、トランスポートストリームのレベル、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ及びＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのレベル、エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要がある。
＜ＡＶストリームのレベル＞
Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報、及び、ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“５”に設定されていることは、Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍで再生されるＡＶストリームの終了点と、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍで再生されるＡＶストリームの開始点との間に、“Ｃｌｅａｎ  Ｂｒｅａｋ”が存在することを意味する。【００９６】  ＣｌｅａｎＢｒｅａｋを実現するには、Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍで再生されるＡＶＣｌｉｐと、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍで再生されるＡＶストリームとが、以下の要件を満たさねばならない。
（１）Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍで指定されているＭａｉｎＣｌｉｐの終了点に、不必要なＡｃｃｅｓｓ  Ｕｎｉｔが存在せず、ＰＴＳを有する不要なＡｃｃｅｓｓ  Ｕｎｉｔが、Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅ以降から排除されていること。【００９７】  同様に、Ｐｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍで指定されているＳｕｂＣｌｉｐの終了点に、不必要なＡｃｃｅｓｓ  Ｕｎｉｔが存在せず、ＰＴＳを有する不要なＡｃｃｅｓｓ  Ｕｎｉｔが、Ｐｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅ以降から排除されていること。
（２）Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍにて指定されるＡＶストリームの開始点において、ＰＴＳをもつ不要なＡｃｃｅｓｓ  Ｕｎｉｔが、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅの前から取り除かれていること。そして、ＭａｉｎＣｌｉｐの最初のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔが、ＳＴＣ時間軸のＩｎ＿Ｔｉｍｅで再生されるＳａｍｐｌｅを含んでいること。【００９８】  同様に、Ｃｕｒｒｅｎｔ  ＳｕｂＰｌａｙＩｔｅｍにて指定されるＡＶストリームの開始点において、ＰＴＳをもつ不要なＡｃｃｅｓｓ  Ｕｎｉｔが、Ｃｕｒｒｅｎｔ  ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅの前から取り除かれていること。そして、ＳｕｂＣｌｉｐの最初のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔが、ＳＴＣ時間軸のＩｎ＿Ｔｉｍｅで再生されるＳａｍｐｌｅを含んでいること。
（３）Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍにて指定されるＭａｉｎＣｌｉｐを構成する全てのＳｏｕｒｃｅパケットが、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍにて指定されるＭａｉｎＣｌｉｐの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。【００９９】  同様に、Ｐｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍにて指定されるＳｕｂＣｌｉｐの全データが、Ｃｕｒｒｅｎｔ  ＳｕｂＰｌａｙＩｔｅｍにて指定されるＳｕｂＣｌｉｐの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
以上が、ＡＶストリームにおいて満たすべき条件についての説明である。続いて、トランスポートストリームのレベルにおいて満たすべき条件について説明する。
＜トランスポートストリームのレベル＞
ここでＣＣ＝５においてシームレス接続の対象となる２つのプライマリＴＳを、プライマリＴＳ１、プライマリＴＳ２と呼ぶ。ＳＰ＿ＣＣ＝５においてシームレス接続の対象となる２つのプライマリＴＳを、セカンダリＴＳ１、セカンダリＴＳ２と呼ぶ。【０１００】  図２７は、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍにて参照されているＡＶＣｌｉｐ、カレントＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍにて参照されているＡＶＣｌｉｐにおいて、ＴＳ１、ＴＳ２がどのように特定されるかを示す図である。本図における第４段目は、プライマリＴＳ１、プライマリＴＳ２を示し、第３段目は、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐ１、カレントＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐ２を示す。第１段目は、セカンダリＴＳ１、セカンダリＴＳ２を示し、第２段目は、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐ１、カレントＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐ２を示す。【０１０１】  プライマリＴＳ１は、ＭａｉｎＣｌｉｐ１において、ハッチングが付されたデータから構成される。ＭａｉｎＣｌｉｐ１におけるハッチングが付されたデータは、Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅに対するデコードを開始することができるＳｏｕｒｃｅパケットから始まる。かかるＳｏｕｒｃｅパケットは、Ｉｎ＿Ｔｉｍｅが参照しているＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ及びＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ先頭に位置するものである。そしてハッチングが付されたデータは、ＭａｉｎＣｌｉｐ１の最後のパケットで終わる。【０１０２】  プライマリＴＳ２は、ＭａｉｎＣｌｉｐ２においてハッチングが付されたデータから構成される。ＭａｉｎＣｌｉｐ２においてハッチングが付されたデータは、ＭａｉｎＣｌｉｐ２の最初のＳｏｕｒｃｅパケットから始まる。そしてＭａｉｎＣｌｉｐにおいてハッチングが付されたデータは、カレントＰｌａｙＩｔｅｍに対するデコードを終了するＳｏｕｒｃｅパケットで終わる。かかるＳｏｕｒｃｅパケットは、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅで参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ，Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの末尾に位置するＳｏｕｒｃｅパケットである。【０１０３】  セカンダリＴＳ１は、ＳｕｂＣｌｉｐ１において、ハッチングが付されたデータから構成される。ＳｕｂＣｌｉｐ１におけるハッチングが付されたデータは、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅに対するデコードを開始することができるＳｏｕｒｃｅパケットから始まる。かかるＳｏｕｒｃｅパケットは、Ｉｎ＿Ｔｉｍｅが参照しているＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ及びＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ先頭に位置するものである。そしてハッチングが付されたデータは、ＳｕｂＣｌｉｐ１の最後のパケットで終わる。【０１０４】  セカンダリＴＳ２は、ＳｕｂＣｌｉｐ２においてハッチングが付されたデータから構成される。Ｓｕｂｃｌｉｐ２においてハッチングが付されたデータは、ＳｕｂＣｌｉｐ２の最初のＳｏｕｒｃ���パケットから始まる。そしてＳｕｂＣｌｉｐにおいてハッチングが付されたデータは、カレントＰｌａｙＩｔｅｍに対するデコードを終了するＳｏｕｒｃｅパケットで終わる。かかるＳｏｕｒｃｅパケットは、カレントＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅで参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ，Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの末尾に位置するＳｏｕｒｃｅパケットである。【０１０５】  以上の説明から、ＣＣ＝５、ＳＰ＿ＣＣ＝５において、接続すべき２つのトランスポートストリームが、ＭａｉｎＣｌｉｐ、ＳｕｂＣｌｉｐ内に、どのように配置されるかがわかる。ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐは、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅで参照されるＶｉｄｅｏＰｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで終わっていなければならず、カレントＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐも、カレントＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅで参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで始まらなければならない。この関係は、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍの同様であり、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐは、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅで参照されるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで終わっていなければならず、カレントＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐも、カレントＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅで参照されるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで始まらなければならない。これは上述したように、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅから参照されるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ以降に、余分なＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔは存在してはならないからである。一方、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐは、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅで参照されるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで始まる必要はなく、カレントＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐも、カレントＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅで参照されるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで終わる必要はない。【０１０６】  以上の図２４、図２７から、プライマリＴＳ、セカンダリＴＳは、同じ時間長に構成され、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔのＰＴＳ値が同一値になるように作成されねばならない。更にｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐ、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐは、Ｏｕｔ＿ＴｉｍｅにあたるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで終わるよう、多重化されねばならず、カレントＰｌａｙＩｔｅｍ側のＭａｉｎＣｌｉｐ、カレントＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐは、Ｉｎ＿ＴｉｍｅにあたるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔで開始するよう、多重化されねばならない。【０１０７】  そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
・ＴＳ１とＴＳ２におけるプログラム数が１つであること
・ビデオストリームの数が１つであること
・オーディオストリーム数が同じであること
・Ｐｒｅｖｉｏｕｓ  ＰｌａｙＩｔｅｍにおけるＳＴＮ＿ｔａｂｌｅと、Ｃｕｒｒｅｎｔ  ＰｌａｙＩｔｅｍにおけるＳＴＮ＿ｔａｂｌｅとは同じ内容になること
・個々のＰｌａｙＩｔｅｍにおけるトランスポートストリームの再生期間は３秒
以上が、ＣＣ＝５、ＳＰ＿ＣＣ＝５で２つのストリームを接続するにあたってトランスポートストリームのレベルで満たすべき条件である。続いて、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのレベルで満たすべき条件について説明する。
＜Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのレベル＞
ＣＣ＝５とは、本来、別々である筈のプライマリＴＳ１たるビデオストリームの最後のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの開始時刻と、プライマリＴＳ２たるビデオストリームの最初のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了時刻とを一致させることをいう。Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了時刻・開始時刻を一致させようとすると、かかるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと同期再生すべきＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの扱いが問題になる。何故なら、ビデオと、オーディオとではサンプリング周波数が異なり、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの時間長は一致しないからである。【０１０８】  図２８は、ＣＣ＝５、及び、ＳＰ＿ＣＣ＝５の詳細を示す図である。第１段目〜第３段目は、ＳｕｂＰｌａｙＩｔｅｍにおけるｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎを示し、第４段目〜第７段目は、ＰｌａｙＩｔｅｍにおけるｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎを示す。第４段目は、ＴＳ１、ＴＳ２における複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔを示し、第５段目は、ＴＳ１におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、ＴＳ２におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔを示す。第６段目は、ＭａｉｎＣｌｉｐにおけるＳＴＣの値を示す。第７段目は、ＭａｉｎＣｌｉｐにおけＳｏｕｒｃｅパケット列を示す。【０１０９】  本図において、ハッチングが付されているのは、ＴＳ１側のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ｓｏｕｒｃｅパケットであり、ハッチングが付されていないのは、ＴＳ２側のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ｓｏｕｒｃｅパケットである。
本図においてＣＣ＝５とは、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ境界を一致させるものの（第４段目）、ＭａｉｎＣｌｉｐのＡＴＣにおいてギャップがあり（第７段目）、ＭａｉｎＣｌｉｐのＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔでオーバラップが存在する（第５段目）状態をいう。ＳＰ＿ＣＣ＝５とは、ＳｕｂＣｌｉｐのＡＴＣにおいてギャップがあり（第１段目）、ＳｕｂＣｌｉｐのＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔでオーバラップが存在する（第２段目）状態をいう。【０１１０】  上述したＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの境界とは、ＴＳ１側から見ればと、第４段目における最後のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了点ＰＴＳ１（１ｓｔＥｎｄ）＋Ｔｐｐにあたり、ＴＳ２側から見れば、第４段目におけるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの開始点ＰＴＳ２（２ｎｄＳＴＡＲＴ）にあたる。
ＴＳ１のうち、境界時点Ｔ４に一致するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了点をＴ５ａ、ＴＳ２のうち、時点Ｔ４に一致するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの開始点をＴ３ａとした場合、ＭａｉｎＣｌｉｐにおけるオーバラップは、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔはＴ３ａからＴ５ａにまでとなる。【０１１１】  また本図において、ＳｕｂＣｌｉｐのＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔは、ＭａｉｎＣｌｉｐのＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔより長くなっている。これは、ＳｕｂＣｌｉｐにおけるオーディオストリームはネットワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、そのためＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ１つ当たりの時間長が長くなるからである。この第１段目におけるＳｏｕｒｃｅパケット列においても、第７段目同様のギャップが存在し、第２段目におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔにおいても、第４段目と同様のオーバーラップが存在している。ＳｕｂＣｌｉｐのＴＳ１におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのうち、境界時点Ｔ４に一致するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了点をＴ５ｂ、ＳｕｂＣｌｉｐのＴＳ２におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのうち、時点Ｔ４に一致するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの開始点をＴ３ｂとした場合、オーバラップはＴ３ｂからＴ５ｂまでとなる。【０１１２】  この図から、ＣＣ＝５、ＳＰ＿ＣＣ＝５を実現するには、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。
（１）ＴＳ１におけるオーディオストリームの最後のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔは、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍにて指定されるＴＳ１における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。【０１１３】  （２）ＴＳ２におけるオーディオストリームの、最初のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔは、カレントＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍにて指定されるＴＳ２の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。
（３）接続点のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ列において、ギャップが存在しない。これは接続点において、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、２つのオーディオフレーム再生期間より短い大きさでなければならない。【０１１４】  （４）ＴＳ２の最初のパケットは、ＰＡＴを含み、１つ以上のＰＭＴがその直後に後続してもよい。ＰＭＴがＴＳパケットのペイロードより大きければ、ＰＭＴは、２パケット以上になることもある。ＰＭＴを格納したＴＳパケットには、ＰＣＲやＳＩＴが存在してもよい。
＜Ｉｎ＿Ｔｉｍｅ、Ｏｕｔ＿ＴｉｍｅとＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔとの関係＞
図２９は、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ及びカレントＰｌａｙＩｔｅｍにて指定される複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、複数のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、ＳＴＣ時間軸との関係を示す図である。第１段目は、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが参照しているＴＳ１に帰属する複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、カレントＰｌａｙＩｔｅｍが参照しているＴＳ２に帰属する複数のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔとを示し、第２段目はｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍが参照しているタイムスタンプに帰属している複数のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔと、カレントＳｕｂＰｌａｙＩｔｅｍが参照しているＴＳ２に帰属する複数のＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔとを示す。第３段目は、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＴＳ１におけるＳＴＣ時間軸と、カレントＳｕｂＰｌａｙＩｔｅｍのＴＳ２におけるＳＴＣ時間軸とを示す。第２段目に示すＴＳ１におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、ＴＳ２におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのうち、ＴＳ２に属するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの開始点Ｔ３ｂから、ＴＳ２に該当するＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの終了時刻Ｔ５ｂまでがオーバラップになるのは、図２８に示した通りである。そしてカレントＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅは、それぞれ、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの境界である時点Ｔ４を指定している。カレントＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、ＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅもまた、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの境界である時点Ｔ４を指定しているので、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと一致していることになる。このようにｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、カレントＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅは、ＢＤ−ＲＯＭとは異なる記録媒体に記録されているにも拘らず、ＭａｉｎＣｌｉｐにおけるＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔの境界と一致しており、更にまた、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅ、カレントＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅと一致していることがわかる。【０１１５】  以上がＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ、Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔレベルの条件についての詳細である。
＜エレメンタリストリームのレベル＞
次に、ＣＣ＝５、ＳＰ＿ＣＣ＝５実現のための、エレメンタリストリームレベルでの符号化条件について説明する。【０１１６】  個々のエレメンタリストリームのレベルでは、以下の符号化条件を満たす必要がある。
（１）ビデオストリーム
・シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、
・シームレス接続の直前のビデオストリームは、ｓｅｑｕｅｎｃｅ＿ｅｎｄ＿ｃｏｄｅ（ＭＰＥＧ−２  Ｖｉｄｅｏ時）、ｅｎｄ＿ｏｆ＿ｓｅｑｕｅｎｃｅ＿ｒｂｓｐ（ＭＰＥＧ−４  ＡＶＣ時）で完了すること、
（２）オーディオストリーム
・同一のＰＩＤをもつオーディオストリームの符号化方式が変わらないこと、
サンプリング周波数や量子化ビット数、チャンネル数などが変わらないこと、
（３）ＰＧストリーム
ａ）ＴＳ１及びＴＳ２におけるＰＧストリームの数が同一である。【０１１７】  ｂ）ＴＳ１におけるＰＧストリームは、Ｅｎｄ  ｏｆ  Ｄｉｓｐｌａｙ  Ｓｅｔと呼ばれる機能セグメントで終了していること
ｃ）ＴＳ１における最後のＰＣＳを運ぶＰＥＳパケットのＰＴＳは、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅにあたる再生時刻より早い時点を示す。
ｄ）ＴＳ２のＰＧストリームは、Ｅｐｏｃｈ  Ｓｔａｒｔ，Ｅｐｏｃｈ  ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ  Ｓｅｔから始まらねばならない。【０１１８】  ｅ）ＴＳ２における最初のＰＣＳを運ぶＰＥＳパケットのＰＴＳは、カレントＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅにあたる再生時刻と等しいか、より遅い時点を示す。
ｆ）ＴＳ２からのＳｏｕｒｃｅパケットが続く、ＴＳ１からのＳｏｕｒｃｅパケットの取り出しは、同じシステム時間軸の、ＳＴＣ１、ＳＴＣ２として定義することができ、これらのＤＴＳ値／ＰＴＳ値には重複が存在しない。
（４）ＩＧストリーム
ａ）ＴＳ１及びＴＳ２におけるＩＧストリームの数が同一である。【０１１９】  ｂ）ＴＳ１におけるＩＧストリームは、Ｅｎｄ  ｏｆ  Ｄｉｓｐｌａｙ  Ｓｅｔと呼ばれる機能セグメントで終了していること
ｃ）ＴＳ１における最後のＩＣＳを運ぶＰＥＳパケットのＰＴＳは、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅにあたる再生時刻より早い時点を示す。
ｄ）ＴＳ２のＩＧストリームは、Ｅｐｏｃｈ  Ｓｔａｒｔ，Ｅｐｏｃｈ  ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ  Ｓｅｔから始まらねばならない。【０１２０】  ｅ）ＴＳ２における最初のＩＣＳを運ぶＰＥＳパケットのＰＴＳは、カレントＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅにあたる再生時刻と等しいか、より遅い時点を示す。
ｆ）ＴＳ２からのＳｏｕｒｃｅパケットが続く、ＴＳ１からのＳｏｕｒｃｅパケットの取り出しは、同じシステム時間軸の、ＳＴＣ１、ＳＴＣ２として定義することができ、これらのＤＴＳ値／ＰＴＳ値には重複が存在しない。
ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍと、カレントＰｌａｙＩｔｅｍとをＣＣ＝５で接続し、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍと、カレントＳｕｂＰｌａｙＩｔｅｍとをＳＰ＿ＣＣ＝５で接続するには、以上のＡＶストリームのレベル、トランスポートストリームのレベル、Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ及びＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔのレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならない。【０１２１】  以上がローカルストレージ２００の構成たるＰｌａｙＬｉｓｔ情報についての説明である。
以上で本発明にかかる記録媒体についての説明を終える。続いて本発明に係る再生装置について説明する。
図３０は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤ−ＲＯＭドライブ１ａ、リードバッファ１ｂ，ｃ、ＡＴＣカウンタ２ａ，ｃ，Ｓｏｕｒｃｅ  Ｄｅｐａｃｋｅｔｉｚｅｒ２ｂ，ｄ、ＡＴＣカウンタ２ｃ，ｄ、ＳＴＣカウンタ３ａ，ｃ、ＰＩＤ  Ｆｉｌｔｅｒ３ｂ，ｄ、ビデオデコーダ４、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）４ａ、Ｍｕｌｔｉｐｌｅｘｅｄ  Ｂｕｆｆｅｒ（ＭＢ）４ｂ、Ｃｏｄｅｄ  Ｐｉｃｔｕｒｅ  Ｂｕｆｆｅｒ（ＣＰＢ）４ｃ、ビデオデコーダ４ｄ、Ｒｅ−ｏｒｄｅｒ  Ｂｕｆｆｅｒ４ｅ、スイッチ４ｆ、ビデオプレーン５、オーディオデコーダ９、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ７、デコーダ８、スイッチ１０ａ，ｂ，ｃ，ｄ、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１１ａ、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１１ｂ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１１ｃ、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１１ｄ、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１１ｅ、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ１１ｆ、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１３ａ、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１３ｂ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１３ｃ、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１３ｄ、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１３ｅ、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ１３ｆ、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１４、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ１５ａ、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１５ｂ、デコーダ１５ｃ、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ１６ａ、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１６ｂ、デコーダ１６ｃ、合成部１７、メモリ２１、コントローラ２２、ＰＳＲセット２３、ＰＩＤ変換部２４、ネットワーク部２５、操作受付部２６、ローカルストレージ２００から構成される。【０１２２】  ＢＤ−ＲＯＭドライブ１ａは、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭディスクに対するアクセスを実行する。
リードバッファ（ＲＢ）１ｂは、ＢＤ−ＲＯＭから読み出されたＳｏｕｒｃｅパケット列を蓄積する。
リードバッファ（ＲＢ）１ｃは、ＬａｓｔＰｌａｙタイトルからから読み出されたＳｏｕｒｃｅパケット列を蓄積する。【０１２３】  ＡＴＣ  Ｃｏｕｎｔｅｒ２ａは、プライマリＴＳを構成するＳｏｕｒｃｅパケットのうち、再生区間の最初に位置するもののＡＴＳを用いてリセットされ、以降ソースデパケッタイザ２ｂにＡＴＣを出力してゆく。
ソースデパケッタイザ（Ｓｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒ）２ｂは、プライマリＴＳを構成するＳｏｕｒｃｅパケットからＴＳパケットを取り出して、送出する。この送出にあたって、各ＴＳパケットのＡＴＳに応じてデコーダへの入力時刻を調整する。具体的には、ＡＴＣ  Ｃｏｕｎｔｅｒ２ａが生成するＡＴＣの値と、ＳｏｕｒｃｅパケットのＡＴＳ値とが同一になった瞬間にＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅで、そのＴＳパケットだけをＰＩＤ  Ｆｉｌｔｅｒ３ｂに転送する。【０１２４】  ＡＴＣ  Ｃｏｕｎｔｅｒ２ｃは、セカンダリＴＳを構成するＳｏｕｒｃｅパケットのうち、再生区間の最初に位置するもののＡＴＳを用いてリセットされ、以降ソースデパケッタイザ２ｄにＡＴＣを出力してゆく。
ソースデパケッタイザ（Ｓｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒ）２ｄは、セカンダリＴＳを構成するＳｏｕｒｃｅパケットからＴＳパケットを取り出して、送出する。この送出にあたって、ＡＴＳに応じてデコーダへの入力時刻を調整する。具体的には、ＡＴＣ  Ｃｏｕｎｔｅｒ２ｃが生成するＡＴＣの値と、ＳｏｕｒｃｅパケットのＡＴＳ値とが同一になった瞬間にＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿Ｒａｔｅで、そのＴＳパケットだけをＰＩＤ  Ｆｉｌｔｅｒ３ｄに転送する。【０１２５】  ＳＴＣ  Ｃｏｕｎｔｅｒ３ａは、プライマリＴＳのＰＣＲによってリセットされ、ＳＴＣを出力する。
ＰＩＤ  Ｆｉｌｔｅｒ３ｂは、ＭａｉｎＣｌｉｐ用の多重分離部であり、ソースデパケッタイザ２ｂから出力されたＳｏｕｒｃｅパケットのうち、ＰＩＤ変換部２４から通知されたＰＩＤ参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ９、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３に出力する。各デコーダは、ＰＩＤ  Ｆｉｌｔｅｒ３ｂを経由したエレメンタリストリームを受け取って、プライマリＴＳのＰＣＲ（ＳＴＣ１時間軸）に従いデコードから再生の処理を行う。このようにＰＩＤ  Ｆｉｌｔｅｒ３ｂを通過して各デコーダに入力されるエレメンタリストリームは、プライマリＴＳのＰＣＲに従って、デコード及び再生に供されることになる。【０１２６】  ＳＴＣ  Ｃｏｕｎｔｅｒ３ｃは、セカンダリＴＳのＰＣＲによってリセットされ、ＳＴＣを出力する。ＰＩＤフィルタ３ｄは、このＳＴＣを参照して、多重分離を行う。
ＰＩＤ  Ｆｉｌｔｅｒ３ｄは、ＳｕｂＣｌｉｐ用の多重分離部であり、ソースデパケッタイザ２ｄから出力されたＳｏｕｒｃｅパケットのうち、ＰＩＤ変換部２４から通知されたＰＩＤ参照値をもつものを、夫々オーディオデコーダ９、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３に出力する。このようにＰＩＤ  Ｆｉｌｔｅｒ３ｄを通過して各デコーダに入力されるエレメンタリストリームは、セカンダリＴＳのＰＣＲに従って、デコード及び再生に供されることになる。【０１２７】  記録媒体の説明で述べたように、ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと一致しているので、ＡＴＣ  Ｃｏｕｎｔｅｒ２ａとＡＴＣ  Ｃｏｕｎｔｅｒ２ｃとが同一の値（時刻）を刻めば、プライマリＴＳとセカンダリＴＳの両方の時間軸が揃うことになり、Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションを構成するプライマリＴＳ、セカンダリＴＳを１本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表すＡＴＣ時間軸と、デコーダ基準時間軸を表すＳＴＣ時間軸とを同期させることができる。【０１２８】  ＡＴＣ時間軸の同期により、上述した２つのＳｏｕｒｃｅ  Ｄｅ−ｐａｃｋｅｔｉｚｅｒは、それぞれ、ＢＤ−ＲＯＭからから読み出されたＳｏｕｒｃｅパケット、ローカルストレージからから読み出されたＳｏｕｒｃｅパケットを処理することができる。
ＳＴＣ時間軸の同期により、ＳＴＣ  Ｃｏｕｎｔｅｒ３ａ，ｃは、同一の時刻を計時すれば、２つのＴＳを１つのＴＳとして処理することができる。再生装置におけるデコーダは、１つのＳＴＣ時間軸で動くため、通常のプライマリＴＳだけの再生時と変わることなく、ＳＴＣ時間の管理を共通化することができる。ビデオデコーダ４、ＩＧデコーダ１１、ＰＧデコーダ１３、システムデコーダ１５ｃ，１６ｃ、オーディオデコーダ９の全てが同一のＳＴＣ時間軸で動かせることは、再生装置開発の観点からすると、ＢＤ−ＲＯＭの再生のみを行う通常の再生装置と、制御が一切変わらないため望ましい制限となる。更にオーサリング時においては、１つのＴＳの入力タイミングを制御して、バッファ状態を観測すればよいので、オーサリング時の検証も容易になる。【０１２９】  ビデオデコーダ４は、ＰＩＤ  Ｆｉｌｔｅｒ３ｂから出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込むものであり、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ、Ｍｕｌｔｉｐｌｅｘｅｄ  Ｂｕｆｆｅｒ４ｂ、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ４ｃ、デコーダ４ｄ、Ｒｅ−ｏｒｄｅｒ  Ｂｕｆｆｅｒ４ｅ、スィッチ４ｆから構成される。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）４ａは、ビデオストリームに帰属するＴＳパケットがＰＩＤ  Ｆｉｌｔｅｒ３ｂから出力された際、一旦蓄積されるバッファである。【０１３０】  Ｍｕｌｔｉｐｌｅｘｅｄ  Ｂｕｆｆｅｒ（ＭＢ）４ｂは、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａからＥｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ４ｃにビデオストリームを出力するにあたって、一旦ＰＥＳパケットを蓄積しておくためのバッファである。
Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ（ＥＢ）４ｃは、符号化状態にあるピクチャ（Ｉピクチャ、Ｂピクチャ、Ｐピクチャ）が格納されるバッファである。【０１３１】  デコーダ（ＤＥＣ．）４ｄは、ビデオエレメンタリストリームの個々のフレーム画像を所定の復号時刻（ＤＴＳ）ごとにデコードすることにより複数フレーム画像を得て、ビデオプレーン５に書き込む。
Ｒｅ−ｏｒｄｅｒ  Ｂｕｆｆｅｒ４ｅは、復号されたピクチャの順序を、符号化順序から表示順序に入れ替えるためのバッファである。【０１３２】  スイッチ４ｆは、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。【０１３３】  オーディオデコーダ９は、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ７、デコーダ８から構成され、オーディオストリームのデコードを行う。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６は、ＰＩＤ  Ｆｉｌｔｅｒ３ｂから出力されたＴＳパケットを、先入れ先だし式に格納して、オーディオデコーダ８に供する。
Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ７は、ＰＩＤ  Ｆｉｌｔｅｒ３ｂから出力されたＴＳパケットのうち再生されるべきオーディオストリームのＰＩＤを有するＴＳパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８に供する。【０１３４】  デコーダ８は、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６に格納されたＴＳパケットをＰＥＳパケットに変換して、このＰＥＳパケットに対しデコード処理を行い、非圧縮状態のＬＰＣＭ状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
スイッチ１０ａは、ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージ２００から読み出されたＴＳパケットのどちらかを、選択的にビデオデコーダ４に供給する。【０１３５】  スイッチ１０ｂは、ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージ２００から読み出されたＴＳパケットのどちらかを、選択的にＩｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１に供給する。
スイッチ１０ｃは、ＢＤ−ＲＯＭから読み出されたＴＳパケット、ローカルストレージから読み出されたＴＳパケットのどちらかを、選択的にＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３に供給する。【０１３６】  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓ（ＩＧ）デコーダ１１は、ＢＤ−ＲＯＭ１００又はローカルストレージ２００から読み出されたＩＧストリームをデコードして、非圧縮グラフィクスをＩＧプレーン１２に書き込むものであり、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１１ａ、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１１ｂ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１１ｃ、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１１ｄ、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１１ｅ、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ（Ｃｔｒｌ）１１ｆから構成される。【０１３７】  Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１１ａは、ＩＧストリームに帰属するＴＳパケットが一旦蓄積されるバッファである。
Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１１ｂは、ＩＧストリームを構成するＰＥＳパケットが格納されるバッファである。
Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１１ｃは、グラフィクスデータを格納したＰＥＳパケットをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１１ｄに書き込む。【０１３８】  Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１１ｄは、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１１ｃのデコードにより得られたグラフィクスオブジェクトが配置される。
Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１１ｅは、グラフィクスデータ描画のための制御情報が配置されるメモリである。
Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ（Ｃｔｒｌ）１１ｆは、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１１ｅに配置された制御情報を解読して、解読結果に基づく制御をする。【０１３９】  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓ（ＩＧ）プレーン１２は、ＩＧデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。
Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓ（ＰＧ）デコーダ１３は、ＢＤ−ＲＯＭ又はローカルストレージ２００から読み出されたＰＧストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１４に書き込む。ＰＧデコーダ１３は、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１３ａ、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１３ｂ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１３ｃ、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ（ＯＢ）１３ｄ、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ（ＣＢ）１３ｅ、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ（Ｃｔｒｌ）１３ｆから構成される。【０１４０】  Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ（ＴＢ）１３ａは、ＰＧストリームに帰属するＴＳパケットがＰＩＤフィルタ４から出力された際、一旦蓄積されるバッファである。
Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ（ＣＤＢ）１３ｂは、ＰＧストリームを構成するＰＥＳパケットが格納されるバッファである。
Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ（ＳＧＰ）１３ｃは、グラフィクスデータを格納したＰＥＳパケット（ＯＤＳ）をデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態のビットマップをグラフィクスオブジェクトとしてＯｂｊｅｃｔＢｕｆｆｅｒ１３ｄに書き込む。【０１４１】  Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ（ＯＢ）１３ｄは、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１３ｃのデコードにより得られたグラフィクスオブジェクトが配置される。
Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ（ＣＢ）１３ｅは、グラフィクスデータ描画のための制御情報（ＰＣＳ）が配置されるメモリである。
Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ（Ｃｔｒｌ）１３ｆは、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１３ｅに配置されたＰＣＳを解読して、解読結果に基づく制御をする。【０１４２】  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓ（ＰＧ）プレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
システムデコーダ１５は、セカンダリＴＳにおけるシステム制御パケット（ＰＡＴやＰＭＴ）を処理しデコーダ全体を制御する。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ１５ａは、プライマリＴＳに存在するシステム制御パケット（ＰＡＴやＰＭＴ）を格納する。【０１４３】  Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１５ｂは、システム制御パケットをデコーダ１５ｃに供する。
デコーダ１５ｃは、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１５ｂに格納されたシステム制御パケットを、デコードする。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ１６ａは、セカンダリＴＳに存在するシステム制御パケットを格納する。【０１４４】  Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１６ｂは、セカンダリＴＳにおけるシステム制御パケットをデコーダ１６ｃに供する。
デコーダ１６ｃは、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ１６ｂに格納されたシステム制御パケットを、デコードする。
メモリ２１は、カレントのＰｌａｙＬｉｓｔ情報やカレントのＣｌｉｐ情報を格納しておくためのメモリである。カレントＰｌａｙＬｉｓｔ情報とは、ＢＤ−ＲＯＭに記録されている複数ＰｌａｙＬｉｓｔ情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭ／ローカルストレージに記録されている複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。【０１４５】  コントローラ２２は、プレイリスト再生（カレントＰｌａｙＬｉｓｔ情報に従った再生制御のことである）を実行することで、ＢＤ−ＲＯＭの再生制御を実現する。また上述のようなＡＴＳ、ＳＴＣの制御も行なう。この制御にあたってコントローラ２２は、１秒という時間的範囲において、ＢＤ−ＲＯＭ、ローカルストレージ内のＳｏｕｒｃｅパケットを、デコーダ内のバッファに先読みしておく。このような先読みを行うのは、上述したウィンドゥの制限により、アンダーフロー又はオーバーフローが生じないとの保障があるからである。【０１４６】  ＰＳＲセット２３は、再生装置に内蔵されるレジスタであり、６４個のＰｌａｙｅｒ  Ｓｅｔｔｉｎｇ／Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒ（ＰＳＲ）と、４０９６個のＧｅｎｅｒａｌ  Ｐｕｒｐｏｓｅ  Ｒｅｇｉｓｔｅｒ（ＧＰＲ）とからなる。Ｐｌａｙｅｒ  Ｓｅｔｔｉｎｇ／Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。
ＰＩＤ変換部２４は、ＰＳＲセット２３に格納されているオーディオストリーム、オーディオストリームのストリーム番号を、ＳＴＮ＿Ｔａｂｌｅに基づき、ＰＩＤ参照値に変換して、変換結果たるＰＩＤ参照値をＰＩＤ  Ｆｉｌｔｅｒ３ｂ、ＰＩＤ  Ｆｉｌｔｅｒ３ｄに指示する。【０１４７】  ネットワーク部２５は、本再生装置における通信機能を実現するものであり、ＵＲＬ指定が与えられれば、そのＵＲＬにあたるｗｅｂサイトとのＴＣＰコネクション、ＦＴＰコネクション等を確立する。かかるコネクション確立によりｗｅｂサイトからのダウンロードを実行する。
操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作を示すＵｓｅｒ  Ｏｐｅｒａｔｉｏｎ情報をコントローラ２２に通知する。【０１４８】  以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ２２の実装について説明する。コントローラ２２は、図３１、図３２に示したフローチャートの処理手順をＣＰＵに実行させるプログラムを作成して命令ＲＯＭに書き込み、ＣＰＵに供することで再生装置に実装することができる。
図３１は、ＰｌａｙＬｉｓｔ情報に基づく再生手順のフローチャートである。本フローチャートは、ＰｌａｙＬｉｓｔ情報を構成する．ｍｐｌｓファイルを読み込み（ステップＳ１１）、ＰｌａｙＬｉｓｔ情報における先頭のＰｌａｙＩｔｅｍをカレントＰｌａｙＩｔｅｍにした上で（ステップＳ１２）、このカレントＰｌａｙＩｔｅｍに対して、ステップＳ１３〜ステップＳ２５の処理を繰り返すループ構造になっている。このループ構造は、ステップＳ２３を終了条件としたものであり、カレントＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅに対応するＡｃｃｅｓｓ  Ｕｎｉｔから、カレントＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅに対応するＡｃｃｅｓｓ  Ｕｎｉｔまでを読み出しをＢＤ−ＲＯＭドライブに命じ（ステップＳ１３）、カレントＰｌａｙＩｔｅｍにｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが存在するか否かを判定して（ステップＳ１４）、判定結果に応じて、ステップＳ１５の処理、ステップＳ１６〜ステップＳ２１の処理を選択的に実行する。具体的には、カレントＰｌａｙＩｔｅｍにｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍがなければ（ステップＳ１４でＮｏ）、ＰｌａｙＩｔｅｍ＿Ｉｎ＿ＴｉｍｅからＰｌａｙＩｔｅｍ＿Ｏｕｔ＿Ｔｉｍｅまでの再生をデコーダに命じる（ステップＳ１５）。【０１４９】  カレントＰｌａｙＩｔｅｍにｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍがあれば（ステップＳ１４でＹｅｓ）、カレントＰｌａｙＩｔｅｍがＣＣ＝５であるか否かを判定し（ステップＳ１６）、ＣＣ＝５であるなら（ステップＳ１６でＹｅｓ）、ステップＳ１７〜ステップＳ２０の処理を行う。
上述したｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが存在する場合、プライマリＴＳにおけるＡＴＣ＿Ｓｅｑｕｅｎｃｅが切り替わることになる。この切替において、ＡＴＣ＿ｄｅｌｔａ１と呼ばれるプライマリＴＳのためのオフセット値を算出し（ステップＳ１７）、それまでのＡＴＣ＿ＳｅｑｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）に、ＡＴＣ＿ｄｅｌｔａ１を加算することにより、新しいＡＴＣ＿ＳｅｑｕｅｎｃｅのＡＴＣ値（ＡＴＣ２）を得る（ステップＳ１８）。【０１５０】  また、上述した、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが存在する場合、プライマリＴＳにおけるＳＴＣ＿Ｓｅｑｕｅｎｃｅが切り替わることになる。この切り替えにおいて、ＳＴＣ＿ｄｅｌｔａ１と呼ばれるオフセット値を求めて（ステップＳ１９）、それまでのＳＴＣ＿ＳｅｑｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）に、ＳＴＣ＿ｄｅｌｔａ１を加算することにより（ステップＳ２０）、新しいＳＴＣ＿ＳｅｑｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）を求める。
そしてＡｕｄｉｏ  Ｏｖｅｒｒａｐのミュートをオーディオデコーダ９に指示した上で、ＰｌａｙＩｔｅｍ＿Ｉｎ＿ＴｉｍｅからＰｌａｙＩｔｅｍ＿Ｏｕｔ＿Ｔｉｍｅまでの再生をデコーダに命じる（ステップＳ２１）。カレントＰｌａｙＩｔｅｍがＣＣ＝５でないなら、ＣＣ＝１、ＣＣ＝６の処理を行う。【０１５１】  ステップＳ１５、ステップＳ１６〜ステップＳ２１のどちらかの処理を実行すればステップＳ２５の処理を実行する。ステップＳ２５は、カレントＰｌａｙＩｔｅｍと同期再生すべきＳｕｂＰｌａｙＩｔｅｍが存在するかどうかをサーチする処理である。ここでＳｕｂＰａｔｈ情報を構成する各ＳｕｂＰｌａｙＩｔｅｍは、Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄという情報を有しており、カレントＰｌａｙＩｔｅｍと同期再生すべきＳｕｂＰｌａｙＩｔｅｍは、このＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄが、カレントＰｌａｙＩｔｅｍに設定されている。そこでステップＳ２５では、カレントＰｌａｙＩｔｅｍをＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄに指定したＳｕｂＰｌａｙＩｔｅｍが、ＳｕｂＰａｔｈ情報を構成する複数のＳｕｂＰｌａｙＩｔｅｍの中に存在するかどうかをサーチする。【０１５２】  もし存在しない場合、ステップＳ２２に移行する。ステップＳ２２は、ＡＶＣｌｉｐ時間軸における現在の再生時点（カレントＰＴＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ  ＴｉＭｅ））がカレントＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅに到達したかどうかを判定する（ステップＳ２２）。到達すれば、ステップＳ２３に移行する。ステップＳ２３は、カレントＰｌａｙＩｔｅｍがＰｌａｙＬｉｓｔ情報における最後のＰｌａｙＩｔｅｍになったか否かの判定であり、最後のＰｌａｙＩｔｅｍでなければ、ＰｌａｙＬｉｓｔ情報における次のＰｌａｙＩｔｅｍを、カレントＰｌａｙＩｔｅｍにして（ステップＳ２４）、ステップＳ１３に移行する。以上の処理により、ＰｌａｙＬｉｓｔ情報における全てのＰｌａｙＩｔｅｍに対して、ステップＳ１３〜ステップＳ２４の処理が施されることになる。【０１５３】  図３２は、ＳｕｂＰｌａｙＩｔｅｍにおけるシームレス接続を示すフローチャートである。
ステップＳ２５においてカレントＰｌａｙＩｔｅｍをＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄに指定したＳｕｂＰｌａｙＩｔｅｍが存在すると判定された場合、そのＳｕｂＰｌａｙＩｔｅｍをカレントＳｕｂＰｌａｙＩｔｅｍに設定して（ステップＳ３１）、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅに相当するＡｃｃｅｓｓ  Ｕｎｉｔから、Ｏｕｔ＿Ｔｉｍｅに相当するＡｃｃｅｓｓ  Ｕｎｉｔまでの読み出しをローカルストレージ２００に命じる（ステップＳ３２）。そしてカレントＰｌａｙＩｔｅｍにＰｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍが存在するか否かを判定して（ステップＳ３３）、判定結果に応じて、ステップＳ３４、ステップＳ３５の処理、ステップＳ３６〜ステップＳ４１の処理を選択的に実行する。具体的には、カレントＰｌａｙＩｔｅｍにＰｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍがなければ（ステップＳ３３でＮｏ）、カレントＰＴＭが、Ｓｙｎｃ＿Ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍに到達するのを待ち（ステップＳ３４）、到達すれば、ＳｕｂＰｌａｙＩｔｅｍ＿Ｉｎ＿ＴｉｍｅからＳｕｂＰｌａｙＩｔｅｍ＿Ｏｕｔ＿Ｔｉｍｅまでの再生をデコーダに命じる（ステップＳ３５）。【０１５４】  カレントＰｌａｙＩｔｅｍにＰｒｅｖｉｏｕｓ  ＳｕｂＰｌａｙＩｔｅｍがあれば（ステップＳ３３でＹｅｓ）、カレントＰｌａｙＩｔｅｍがＳＰ＿ＣＣ＝５であるか否かを判定し（ステップＳ３６）、ＳＰ＿ＣＣ＝５であるなら（ステップＳ３６でＹｅｓ）、ステップＳ３７〜ステップＳ４１の処理を行う。
上述した、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが存在する場合、ＡＴＣ＿Ｓｅｑｕｅｎｃｅが切り替わることになる。この切替において、ＡＴＣ＿ｄｅｌｔａ２と呼ばれるセカンダリＴＳのためのオフセット値を算出し（ステップＳ３７）、それまでのＡＴＣ＿ＳｅｑｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）に、ＡＴＣ＿ｄｅｌｔａ２を加算することにより、新しいＡＴＣ＿ＳｅｑｕｅｎｃｅのＡＴＣ値（ＡＴＣ２）を得る（ステップＳ３８）。【０１５５】  ＡＴＣ＿ｄｅｌｔａとは、これまで読み出されているトランスポートストリーム（ＴＳ１）の最後のＴＳパケットの入力時点Ｔ１から、新たに読み出されたトランスポートストリーム（ＴＳ２）の最初のＴＳパケットの入力時点Ｔ２までのオフセット値をいい、“ＡＴＣ＿ｄｅｌｔａ≧Ｎ１／ＴＳ＿ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ”という計算式で与えられる。ここでＮ１は、ＴＳ１の最後のビデオＰＥＳパケットに後続する、ＴＳパケットのパケット数である。【０１５６】  また、上述した、ｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍが存在する場合、ＳＴＣ＿Ｓｅｑｕｅｎｃｅも切り替わることになる。この切り替えにおいて、ＳＴＣ＿ｄｅｌｔａ２を求めて（ステップＳ３９）、それまでのＳＴＣ＿ＳｅｑｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）に、ＳＴＣ＿ｄｅｌｔａ２を加算することにより（ステップＳ４０）、新しいＳＴＣ＿ＳｅｑｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）を求める。
先行ＳＴＣ＿Ｓｅｑｕｅｎｃｅにおいて最後に再生されるピクチャの表示開始時刻をＰＴＳ１（１ｓｔＥＮＤ）、ピクチャの表示期間をＴｐｐとし、後続ＳＴＣ＿Ｓｅｑｕｅｎｃｅにおいて最初に表示されるピクチャの開始時刻をＰＴＳ２（２ｎｄＳＴＡＲＴ）とした場合、ＣＣ＝５では、ＰＴＳ１（１ｓｔＥＮＤ）＋Ｔｐｐの時刻と、ＰＴＳ２（２ｎｄＳＴＡＲＴ）の時刻とを一致させる必要があるから、ＳＴＣ＿ｄｅｌｔａ２は、
ＳＴＣ＿ｄｅｌｔａ２＝ＰＴＳ１（１ｓｔＥＮＤ）＋Ｔｐｐ−ＰＴＳ２（２ｎｄＳＴＡＲＴ）
との計算式から算出される。
そしてＡｕｄｉｏ  Ｏｖｅｒｒａｐのミュートをオーディオデコーダ９に指示した上で、ＰｌａｙＩｔｅｍ＿Ｉｎ＿ＴｉｍｅからＰｌａｙＩｔｅｍ＿Ｏｕｔ＿Ｔｉｍｅまでの再生をデコーダに命じる（ステップＳ４１）。【０１５７】  コントローラ２２は、上述したように、ＳＴＣの変更処理を行うが、再生装置の一般的な実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。フリーラン状態とは、デコーダがＳＴＣとの同期制御を行っていない状態をいう。その後、ＳＴＣ時間軸が設定できる状態まで、ＳＴＣが復帰すれば、デコーダは、フリーラン状態から、ＳＴＣとの同期制御へと移行する。一方、ステップＳ３６においてカレントＰｌａｙＩｔｅｍがＣＣ＝５でないと判定されたなら（ステップＳ３６でＮｏ）、ＣＣ＝１、ＣＣ＝６の処理を行う。【０１５８】  以上のように本実施形態によれば、Ｗｉｎｄｏｗと呼ばれる１秒当たりの転送許容量は、４８Ｍｂｉｔ以下に制限されているので、この１秒という期間において、転送許容量が局所的に９６Ｍｂｉｔまであがったとしても、９６Ｍｂｉｔ×０．５秒のサイズのＴＳパケットを、デコーダに先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローすることはない。デジタルストリームにおけるどの期間であっても、データ量は「９６Ｍｂｉｔ×０．５秒」以下であり、アンダーフロー又はオーバーフローが生じることなく、ＴＳパケットを供給することができるので、ビデオ又はオーディオの欠落を避けることができる。これによりＯｕｔ−ｏｆ−ＭＵＸフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。【０１５９】  また、ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとが一致していて、ＰｌａｙＩｔｅｍ側の接続状態がＣＣ＝５であるなら、ＳｕｂＰｌａｙＩｔｅｍ側の接続状態もＳＰ＿ＣＣ＝５になるので、ＰｌａｙＩｔｅｍが切り替えられたとしても、多重分離部を再設定することなく、ＰｌａｙＩｔｅｍからＰｌａｙＩｔｅｍへの切り替えと、ＳｕｂＰｌａｙＩｔｅｍからＳｕｂＰｌａｙＩｔｅｍへの切り替えとを同時に実行することができる。多重分離部が参照するＳＴＣ時間軸を同期させつつ、ＰｌａｙＬｉｓｔ情報に基づく再生処理を進行させてゆくことができる。【０１６０】  （第２実施形態）
本実施形態では、先の実施形態で述べた、ＢＤ−ＲＯＭの製作について、詳しく説明する。先の実施形態に係るＢＤ−ＲＯＭは、以下の工程を順次実行することにより、作ることができる。＜ＢＤ−ＲＯＭの記録工程＞
先ず初めに、ＢＤ−ＲＯＭをどのような筋書きで再生させるかを決めるかを企画して（企画工程）、動画収録、音声収録等の素材作成を行い（素材作成工程）、企画工程において作成された筋書きから、ボリューム構成情報を作成する（シナリオ作成工程）。【０１６１】  ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る（素材エンコード工程）。その後、複数のエレメンタリストリームの多重化を行う（多重化工程）。【０１６２】  こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、ＢＤ−ＲＯＭの応用層フォーマットに適合させる作業を行い、ＢＤ−ＲＯＭのボリューム領域に記録すべきデータの全体像（一般にボリュームデータという）を得る（フォーマッティング工程）。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、ＢＤ−ＲＯＭ規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、Ｃｌｉｐ情報，ＰｌａｙＬｉｓｔ情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のｆｏｒ文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、ｉｆ文を用いて定義することができる。【０１６３】  こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う（エミュレーション工程）。このエミュレーション工程では、ＢＤ−ＲＯＭプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、ＢＤ−ＲＯＭを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。【０１６４】  以上の工程を経て、各実施形態に示した記録媒体（ＢＤ−ＲＯＭ）を作ることができる。
＜追加コンテンツの作成工程＞
映画作品を、ＢＤ−ＲＯＭコンテンツと、追加コンテンツとで構成する場合は、上述した企画工程からフォーマッティング工程までを実行する。そうして、１つのボリュームデータを構成するＡＶＣｌｉｐ、Ｃｌｉｐ情報、ＰｌａｙＬｉｓｔ情報が得られれば、これらのうち、既にＢＤ−ＲＯＭにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバプログラム等で１つのファイルにまとめる。こうした処理を経て、追加コンテンツが得られれば、かかる追加コンテンツをＷＷＷサーバーに供し、再生装置からの要求に応じて、再生装置に送出する。【０１６５】  先の実施形態で述べたベリファイは、ＡＶＣｌｉｐ、Ｃｌｉｐ情報、ＰｌａｙＬｉｓｔ情報が完成し、ＰｌａｙＬｉｓｔ情報内のＳＴＮ＿ｔａｂｌｅにより、再生すべきエレメンタリストリームが確定した段階、つまり、フォーマッティング工程で実行される。以降、かかるアプリケーションフォーマットを作成するオーサリングシステムについて説明する。
＜オーサリングシステム＞
図３３は、第２実施形態にかかるオーサリングシステムの内部構成を示す図である。本図に示すようにオーサリングシステムは、入力装置５１、エンコード装置５２、サーバ装置５３、素材ストレージ５４、ＢＤ構成情報ストレージ５５、クライアント装置５６〜５８、マルチプレクサ６０、ＢＤシナリオコンバータ６１、フォーマッタ６２、Ｖｅｒｉｆｉｅｒ６３から構成される。【０１６６】  入力装置５１は、ＨＤ画像、ＳＤ画像が収められたビデオカセットを装填し、このビデオカセットを再生して再生信号をエンコード装置５２に出力する。
エンコード装置５２は、入力装置５１から出力された再生信号をエンコードして、ビデオストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得られたエレメンタリストリームは、ＬＡＮを通じてサーバ装置５３に出力され、サーバ装置５３内の素材ストレージ５４に書き込まれる。【０１６７】  サーバ装置５３は、素材ストレージ５４、ＢＤ構成情報ストレージ５５という２つのドライブ装置からなる。
素材ストレージ５４は、サーバ装置５３の内蔵ディスク装置であり、エンコード装置５２のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ５４は、ＨＤｓｔｒｅａｍディレクトリ、ＳＤｓｔｒｅａｍディレクトリといった２つのディレクトリをもち、ＨＤ画像をエンコードすることにより得られたエレメンタリストリームはＨＤｓｔｒｅａｍディレクトリに書き込まれる。【０１６８】  ＢＤ構成情報ストレージ５５は、ＢＤボリューム構成情報が格納されるドライブ装置である。
マルチプレクサ６０は、素材ストレージ５４内のＨＤｓｔｒｅａｍディレクトリ、ＳＤｓｔｒｅａｍディレクトリに格納されているエレメンタリストリームのうち、ＢＤボリューム構成情報により指定されているものを読み出し、これをＢＤボリューム構成情報に従い多重化することで、多重化ストリームであるＡＶＣｌｉｐを得る。【０１６９】  ＢＤシナリオコンバータ６１は、ＢＤ構成情報ストレージ５５に格納されているＢＤボリューム構成情報をＢＤ−ＲＯＭアプリケーションフォーマットに変換することによりＢＤシナリオを得る。
フォーマッタ６２は、マルチプレクサ６０によりえられたＣｌｉｐ、ＢＤシナリオコンバータ６１により得られたＢＤシナリオを、ＢＤ−ＲＯＭの応用層フォーマットに適応させる。こうして適応されらＢＤシナリオから、ＢＤ−ＲＯＭの原盤や、ローカルストレージに格納されるべきダウンロード用コンテンツが得られる。【０１７０】  ベリファイ部６３は、シナリオコンバータ６１が生成したＰｌａｙＬｉｓｔ情報内のＳＴＮ＿ｔａｂｌｅを参照して、マルチプレクサ６０が得たＢＤ−ＲＯＭ用のプライマリＴＳ、ローカルストレージ用のセカンダリＴＳが、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現するため制限を満たすかどうかを判定する。
以上が、オーサリングシステムの内部構成である。以降、オーサリングシステムおけるベリファイ部６３の実装について説明する。【０１７１】  ＜ベリファイ部６３実装のための処理手順＞
ベリファイ部６３は、図３４、図３５に示したフローチャートの処理手順をＣＰＵに実行させるプログラムを作成して命令ＲＯＭに書き込み、ＣＰＵに供することでオーサリングシステム内に実装することができる。
図３４は、プライマリＴＳ、セカンダリＴＳに対するベリファイ手順を示すフローチャートである。本フローチャートは、ステップＳ１において、Ｓｏｕｒｃｅパケット列における最初のＳｏｕｒｃｅパケットのＡＴＳを、カレントＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅに設定した上で、ステップＳ２〜ステップＳ７の処理を繰り返すループ構造を有している。このループ構造は、カレントＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅから１秒以降に存在するＡＴＳを、カレントＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅに設定して（ステップＳ２）、カレントＷｉｎｄｏｗのＩｎ＿ＴｉｍｅからＯｕｔ＿Ｔｉｍｅまでに存在するＴＳパケット数をカウントし（ステップＳ３）、Ｉｎ＿ＴｉｍｅからカレントＷｉｎｄｏｗにおけるビット数を算出して（ステップＳ４）、そのビット値が４８Ｍｂｉｔ以下であるかを判定する処理（ステップＳ５）を、ステップＳ６がＹｅｓと判定されるまで繰り返すものである。このステップＳ６は、カレントＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅが、ＡＴＣ時間軸における最後のＳｏｕｒｃｅパケットに到達したかどうかの判定であり、もしステップＳ６がＮｏであるなら、Ｓｏｕｒｃｅパケット列における次のＡＴＳを、カレントＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅにして（ステップＳ７）、ステップＳ２〜ステップＳ６の処理を繰り返す。どれかのＷｉｎｄｏｗで、ステップＳ５がＮｏと判定されたなら、ＢＤ−ＲＯＭ規格に違反していると判定される（ステップＳ９）。全てのＷｉｎｄｏｗでステップＳ５がＹｅｓと判定され、ステップＳ６がＹｅｓと判定されたなら、ＢＤ−ＲＯＭ規格に適合していると判定される（ステップＳ８）。【０１７２】  プライマリＴＳ、セカンダリＴＳは、以上のベリファイを経ているので、プライマリＴＳ、セカンダリＴＳがそれぞれＢＤ−ＲＯＭ、ローカルストレージから供給される場合でも、上述したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、ＰＧストリーム、ＩＧストリームのそれぞれに、同種のエレメンタリストリームが複数存在する場合、図３５の手順で、ベリファイを行うのが望ましい。図３５に示すベリファイ手順は、図３４におけるステップＳ３〜ステップＳ４を、ステップＳ８１〜ステップＳ８３に置き換えたものである。【０１７３】  このステップＳ８１〜ステップＳ８３は、カレントＷｉｎｄｏｗが１つ決定される度に、ＳＴＮ＿ｔａｂｌｅにおいて、再生が許可されているエレメンタリストリームを構成するＴＳパケットのうち、カレントＷｉｎｄｏｗに属するもののビットレートを、エレメンタリストリーム毎に算出して（ステップＳ８１）、複数のビデオストリーム、複数のオーディオストリーム、複数のＰＧストリーム、複数のＩＧストリームのうち、算出されたビットレートが最も高いものを選び（ステップＳ８２）、ビデオストリームのビットレートの最大値、オーディオストリームのビットレートの最大値、ＰＧストリームのビットレートの最大値、ＩＧストリームのビットレートの最大値を合計して（ステップＳ８３）、その合計量が４８Ｍｂｉｔ以下であるかを判定する（ステップＳ５）ものである。【０１７４】  同種のエレメンタリストリームは、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションでは、必ず排他的に選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下の通りである。【０１７５】  （１）ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅが指し示すＴＳパケットの先頭
（２）ＷｉｎｄｏｗのＩｎ＿Ｔｉｍｅが指し示すＴＳパケットの終了
（３）ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅが指し示すＴＳパケットの先頭
（４）ＷｉｎｄｏｗのＯｕｔ＿Ｔｉｍｅが指し示すＴＳパケットの終了
かかる箇所におけるビット量を重点的にチェックすることで、オーサリングでのベリファイ作業を、より簡略化することができる。【０１７６】  以上のように本実施形態によれば、セカンダリＴＳの再生を許可したＳＴＮ＿ｔａｂｌｅを作成した際、そのＳＴＮ＿ｔａｂｌｅに基づく再生処理で、アンダーフロー又はオーバーフローが生じるかどうかを、オーサリングの段階で、あらかじめ検証しておくことができる。
（第３実施形態）
本実施形態は、ＰｌａｙＩｔｅｍ間、ＳｕｂＰｌａｙＩｔｅｍ間の接続に、ＣＣ＝６という新たな類型を設ける実施形態である。【０１７７】  ＣＣ＝６とは、Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報を構成する複数のＰｌａｙＩｔｅｍ情報間の接続状態を規定する。Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報とは、ストリーミングを前提にして再生されるべき複数のＡＶＣｌｉｐを、１つの再生経路として指定してゆくためのプレイリスト情報である。
＜Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報＞
Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報は、ダウンロード／ストリーミングするセカンダリＴＳを細切れのファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウンロードを待たずに、再生を開始することができる利便がある。【０１７８】  ストリーミングを前提にしたコンテンツは、短い長さの多くのＡＶＣｌｉｐにて規定されているので、Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報は、これら複数ＡＶＣｌｉｐのそれぞれに対応する、多くのＰｌａｙＩｔｅｍ情報から構成される。一方、細かい単位に分割されたＡＶＣｌｉｐは、ストリーミングのために分割されたのであって、ＳＴＣ、ＡＴＣに不連続点が存在している訳ではない。そのため、ＣＣ＝５ではない別の状態として、かかるＡＶＣｌｉｐ間の接続状態を規定しておく必要がある。こうして規定された接続状態を、ＣＣ＝６という。
＜ＣＣ＝６において満たすべき条件＞
ＣＣ＝６である場合、２つのＰｌａｙＩｔｅｍから指定されるＴＳ１、ＴＳ２と、２つのＳｕｂＰｌａｙＩｔｅｍから指定されるＴＳ１、ＴＳ２とは、以下の条件を満たす必要がある。【０１７９】  １）ＴＳ２におけるビデオストリームは、ＧＯＰから始まらなければならない。
２）ＴＳ２のオーディオストリームと同じＰＩＤをもつＴＳ１のオーディオストリームとにおいて、接続点におけるＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ列に、ギャップが存在しない。
ＴＳ１のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そして、ＴＳ２における同じＰＩＤをもつオーディオストリームは、不完全なＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔから始まってもよい。複数のＰｌａｙＩｔｅｍ、複数のＳｕｂＰｌａｙＩｔｅｍに基づき、これらのＴＳ１、ＴＳ２を再生させてゆけば、２つのＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔから、１つの完結したＡｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔが得られる。【０１８０】  ＣＣ＝６では実際にはストリームが連続しているため、ＣＣ＝５の時のようなビデオだけがシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするようなことはなく、全てのエレメンタリストリームがシームレスに接続される。
以上のようにＣＣ＝６は、論理的に連続しているストリームを、ストリーミングの都合から、複数の部分に分割した場合の分割境界を意味する。ただし、ＢＤ−ＲＯＭに記録されるべきストリームは３２個のＳｏｕｒｃｅパケットから構成される必要があるので、１つのＳｕｂＰｌａｙＩｔｅｍを構成する１つのストリームファイルは、全て、６ＫＢｙｔｅの倍数になっている必要がある。【０１８１】  ＜ＣＣ＝６の詳細＞
図３６は、ＣＣ＝６の詳細な説明を示す図である。第１段目は、１本の連続したＡＴＣ／ＳＴＣ時間を有し、符号化方式も連続しているストリームを格納したファイル（２００００．ｍ２ｔｓ）を示す。第２段目は、３つのストリームを格納した格納した３つのファイル（２０００１．ｍ２ｔｓ，２０００２．ｍ２ｔ，２０００３．ｍ２ｔｓ）を示す。これらの３つのファイルは、第１段目における１本のストリームを、アラインドユニット（６ＫＢｙｔｅ）単位で区切ることで得られた、３つのプライマリＴＳを格納している。【０１８２】  図３７は、ＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの相関を示した図である。第１段目は、ＰｌａｙＬｉｓｔ情報における３つのＰｌａｙＩｔｅｍ（ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２、ＰｌａｙＩｔｅｍ情報＃３）を示す。これら３つのＰｌａｙＩｔｅｍはプライマリＴＳを指定しており、ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２間はＣＣ＝１に設定され、ＰｌａｙＩｔｅｍ情報＃２、ＰｌａｙＩｔｅｍ情報＃３間は、ＣＣ＝５に設定されている。第２段目は、ＰｌａｙＬｉｓｔ情報における３つのＳｕｂＰｌａｙＩｔｅｍ（ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３）を示す。これら３つのＳｕｂＰｌａｙＩｔｅｍはセカンダリＴＳを指定しており、ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２間はＣＣ＝１に設定され、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３間は、ＣＣ＝５に設定されている。第３段目は、Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報における９つのＳｕｂＰｌａｙＩｔｅｍ（ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３〜ＳｕｂＰｌａｙＩｔｅｍ＃９）を示す。これら９つのＳｕｂＰｌａｙＩｔｅｍはセカンダリＴＳを指定しており、ＳｕｂＰｌａｙＩｔｅｍ＃３、ＳｕｂＰｌａｙＩｔｅｍ＃４間はＣＣ＝１に設定され、ＳｕｂＰｌａｙＩｔｅｍ＃６、ＳｕｂＰｌａｙＩｔｅｍ＃７間は、ＣＣ＝５に設定され、それ以外は、ＣＣ＝６に設定されている。Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔのＳｕｂＰｌａｙＩｔｅｍは、ＣＣ＝６で接続されるが、ＰｌａｙＩｔｅｍがＣＣ＝１、ＣＣ＝５で接続されるタイミングでは、ＰｌａｙＩｔｅｍと同様にＣＣ＝１、ＣＣ＝５の条件を満たしながら接続される。【０１８３】  以上のように本実施形態によれば、ＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍにおける接続状態に、ＣＣ＝６という新たな類型を導入することで、Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報を構成するＡＶＣｌｉｐを短く区切って、ストリームングで供給するという処理を実現することができる。
（第４実施形態）
第１実施形態では、各Ｗｉｎｄｏｗにおけるビット量を、どのように制限するかについて説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えばよいかを提案する。【０１８４】  ＜ビデオ＋オーディオの多重化＞
図３８は、プライマリＴＳを構成するオーディオが、セカンダリＴＳを構成するオーディオに入れ替えられる場合、プライマリＴＳを構成する複数のＴＳパケットと、セカンダリＴＳを構成する複数のＴＳパケットとが、どのように多重化されるかを模式的に示す図である。
図３８は、ＡＴＣ時間軸に存在する複数のＴＳパケットが、どのように多重化されるかを模式的に示す図である。第１段目は、プライマリＴＳを示す。プライマリＴＳはＶ、Ａ１、Ａ２（ビデオ１本、オーディオ２本）を格納したＴＳパケットである。これらのＴＳパケットは、２種類３本のエレメンタリストリームを多重化して得たものである。【０１８５】  第２段目は、セカンダリＴＳを示す。セカンダリＴＳは、１種類２本のオーディオＡ３、Ａ４を格納したＴＳパケットからなる。これらセカンダリＴＳのＴＳパケットが多重化される時間帯ｐ３は、デコーダへの入力時間軸を示すＡＴＣ時間軸上で、プライマリＴＳのオーディオパケットが多重化された時間帯ｐ１と、プライマリＴＳを構成するＴＳパケットが転送されてない時間帯ｐ２とからなる。【０１８６】  このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されてもデコードすべきエレメンタリストリームのビットレートの和がプライマリＴＳの許容最大ビットレート（４８Ｍｂｐｓ）を超えない保証ができる。図３８の上述した一例は、一番簡単な例で、セカンダリＴＳにオーディオしかない場合である。
＜ビデオ＋オーディオ＋ＰＧストリーム＋ＩＧストリームの多重化＞
図３９は、オーディオに加えて、字幕（ＰＧストリーム）やメニュー（ＩＧストリーム）も入れ替えられる場合、プライマリＴＳを構成する複数のＴＳパケットと、セカンダリＴＳを構成する複数のＴＳパケットとが、どのように多重化されるかを模式的に示す図である。【０１８７】  本図において、セカンダリＴＳのパケットの転送が許可される時間帯ｋ３は、
１）プライマリＴＳにおける同種のパケットの転送時間帯ｋ１
２）プライマリＴＳの無転送時間帯ｋ２
の和である。
セカンダリＴＳに格納されている他ストリーム種別（Ｖｉｄｅｏ、ＩＧ、ＰＧ等）についても上記１）、２）のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類のストリームの転送時間帯でセカンダリＴＳ内に多重化が可能か判断され、これで不足する場合には、２）のプライマリＴＳの無転送時間帯を利用して多重化されることが効率的である。【０１８８】  ＜マルチプレクサ６０の処理＞
本実施形態にかかるマルチプレクサ６０の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ６０は、デコーダモデルにおいて、プライマリＴＳを再生する際のバッファ状態をシミュレートし、プライマリＴＳにおける各パケットの転送時間帯や、プライマリＴＳの無転送時間帯を検出する。これらの時間帯を検出すれば、セカンダリＴＳを構成する各ＰＥＳパケットが、同種のパケットの転送時間帯や、無転送時間帯に転送されるよう、セカンダリＴＳを構成する各ＰＥＳパケットをＴＳパケットに変換して、各ＴＳパケットに、かかるＡＴＳを付す。こうして付されたＡＴＳは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリＴＳを構成する各ＰＥＳパケットは、図３９に示したように、プライマリＴＳにおける同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。【０１８９】  ＜ＤＶＤによる供給＞
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム形式ではなく、プログラムストリーム形式にする場合、マルチプレクサ６０は、エレメンタリストリームを構成するＰＥＳパケットを、パックに変換して、各パックのＴＳヘッダにＳＣＲ（Ｓｙｓｔｅｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）を付す。こうして付されたＳＣＲも、ＡＴＳ同様、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリＰＳ（ローカルストレージから供給されるプログラムストリーム）を構成する各ＰＥＳパケットは、図３９に示したように、プライマリＰＳ（ＢＤ−ＲＯＭから供給されるプログラムストリーム）における同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレージから供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種のパケットの転送時間帯や、無転送時間帯を、パック（ＰＥＳパケット）という大きな時間単位で表現するので、オーサリング時における負担は格段に小さく、実現が容易となる。これは、ＤＶＤ再生装置において、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現するにあたっての、利点となる。【０１９０】  以上のように本実施形態によれば、プライマリＴＳにおける同種のパケットの転送期間、プライマリＴＳにおける無転送期間を、セカンダリＴＳを構成するパケットの入力期間に選び多重化を行うので、第１実施形態に示したビット量制限を満たしやすくなる。かかる多重化を第２実施形態に示したオーサリングシステム上で実現することにより、Ｏｕｔ＿ｏｆ＿ＭＵＸアプリケーションを実現するような映画作品を製作しやすくなる。これにより、再生時のオーバフローが生じないような保障をオーサリングの段階で、容易に行うことができる。
（第５実施形態）
本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本アプリケーションは、１つの種別につき、１つのエレメンタリストリームというＯｕｔ＿ｏｆ＿ＭＵＸの規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシングアプリケーションはプライマリＴＳにあたるオーディオストリームと、セカンダリＴＳにあたるオーディオストリームとを同時に選択し、プライマリＴＳの音声とセカンダリＴＳの音声の２つの音声を同時にデコードする点が例外となる。【０１９１】  図４０は、オーディオミキシングアプリケーションを構成するプライマリＴＳ、セカンダリＴＳが、ＢＤ−ＲＯＭ再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、ＢＤ−ＲＯＭ再生装置の内部構成のうち、ＢＤ−ＲＯＭドライブ１ａ、ローカルストレージ２００、ネットワーク部２５を左側に示し、各デコーダを右側に示す。真ん中に、ストリームの多重分離を行うＰＩＤ  Ｆｉｌｔｅｒを示す。そして本図におけるプライマリＴＳ（Ｖｉｄｅｏ１，Ａｕｄｉｏ１（Ｅｎｇｌｉｓｈ），Ａｕｄｉｏ２（Ｓｐａｎｉｓｈ），ＰＧ１（Ｅｎｇｌｉｓｈ  Ｓｕｂｔｉｔｌｅ），ＩＧ１（Ｅｎｇｌｉｓｈ  Ｍｅｎｕ））、セカンダリＴＳ（Ａｕｄｉｏ３（Ｃｏｍｍｅｎｔａｒｙ），ＰＧ２（Ｊａｐａｎｅｓｅ  Ｓｕｂｔｉｔｌｅ），ＰＧ３（Ｋｏｒｅａｎ  Ｓｕｂｔｉｔｌｅ），ＰＧ４（Ｃｈｉｎｅｓｅ  Ｓｕｂｔｉｔｌｅ），ＩＧ２（Ｅｎｇｌｉｓｈ  Ｍｅｎｕ））は、それぞれＢＤ−ＲＯＭ、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Ａｕｄｉｏ  １）とスペイン語（Ａｕｄｉｏ  ２）しか記録されていないため、映画監督のコメンタリ音声は、このディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供するＡｕｄｉｏ  ３（Ｃｏｍｍｎｅｔａｒｙ）の入ったセカンダリＴＳを、ローカルストレージにダウンロードすれば、英語音声（Ａｕｄｉｏ  １）と、Ａｕｄｉｏ  ３（Ｃｏｍｍｅｎｔｒｙ）とを、デコーダに送り込むことができる。これらの英語音声（Ａｕｄｉｏ  １）と、Ａｕｄｉｏ  ３（Ｃｏｍｍｅｎｔｒｙ）とを、デコーダがミキシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像（Ｖｉｄｅｏ１）と共に再生させることができる。【０１９２】  Ｏｕｔ−ｏｆ−ＭＵＸアプリケーションとの相違は２つのオーディオストリームを同時にデコードする点のみである。如何なるプライマリＴＳに対しても、ディスク発売後に監督のコメンタリ音声を付加するなどといったことが想定されるため、プライマリＴＳへのビットレート制限などは好ましくなく、Ｏｕｔ−ｏｆ−ＭＵＸと同様にセカンダリＴＳへの制限を導入する。オーディオミキシングでは、各エレメンタリストリーム（ビデオ、オーディオ、字幕、メニュー）に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソースを２つ必須とする。【０１９３】  ＜プライマリ、セカンダリオーディオストリームの構成＞
オーディオミキシングアプリケーションを実現するにあたって、プライマリＴＳにおける属することになるオーディオストリームを、プライマリオーディオストリームといい、セカンダリＴＳに属することになるオーディオストリームをセカンダリオーディオストリームという。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて説明する。【０１９４】  プライマリオーディオストリームは、３２本存在し、それらは０ｘ１１００から０ｘ１１１ＦまでのＰＩＤをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリーム同様、３２本存在し、０ｘ１Ａ００から０ｘ１Ａ１ＦまでのＰＩＤをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカンダリオーディオストリームのオーディオフレームに、“ダウンミキシング情報”と、“ゲイン制御情報”とからなるメタデータを含む点である。【０１９５】  “ダウンミキシング情報”は、ダウンミキシングのための情報である。ダウンミキシングとは、音声の再生チャネル数を符号化チャンネル数よりも少なくする変換であり、ダウンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、このダウンミキシングを再生装置に行わせる。５．１ｃｈの音声ストリームを２ｃｈで再生することなどがダウンミキシングの一例である。【０１９６】  “ゲイン制御情報”とは、プライマリオーディオストリーム側の音声出力時のゲインを上げ下げする情報であるが、ここでは下げるだけでよい。このようにセカンダリオーディオストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出力をリアルタイムに下げることができる。ＰｒｉｍａｒｙオーディオとＳｅｃｏｎｄａｒｙオーディオを重畳する場合には、あらかじめミキシングされるＰｒｉｍａｒｙオーディオとＳｅｃｏｎｄａｒｙオーディオの対が分かっているため、２本のオーディオのゲインをリアルタイムに制御する必要は無く、Ｐｒｉｍａｒｙオーディオのゲインだけを下げてＳｅｃｏｎｄａｒｙオーディオのゲインはそのままにミキシング（重畳）することで十分である。かかるメタデータを配置することで、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避けることができる。以上が、本実施形態におけるオーディオストリームについての説明である。続いて、本実施形態におけるＰｌａｙＬｉｓｔ情報における改良について説明する。【０１９７】  ＜オーディオミキシングアプリケーションを実現するためのＳＴＮ＿ｔａｂｌｅ＞
同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、本実施形態におけるＰｌａｙＬｉｓｔ情報には、再生が許可されている複数プライマリオーディオストリーム、複数セカンダリオーディオストリームの組合せが、各ＰｌａｙＩｔｅｍのＳＴＮ＿ｔａｂｌｅに示されている。【０１９８】  以降、本実施形態におけるＳＴＮ＿ｔａｂｌｅについて説明する。オーディオミキシングアプリケーションを実現するため、ＳＴＮ＿ｔａｂｌｅには、セカンダリオーディオストリームにおけるＳｔｒｅａｍ＿ｅｎｔｒｙと、Ｓｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅとの組みが、プライマリオーディオストリームにおけるＳｔｒｅａｍ＿ｅｎｔｒｙと、Ｓｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅとの組みとは別に存在する。そして、セカンダリオーディオストリームにおけるＳｔｒｅａｍ＿ｅｎｔｒｙと、Ｓｔｒｅａｍ＿ａｔｔｒｉｂｕｔｅとの組みが、Ｃｏｍｂ＿ｉｎｆｏ＿Ｓｅｃｏｎｄａｒｙ＿ａｕｄｉｏ＿Ｐｒｉｍａｒｙ＿ａｕｄｉｏと対応付けられている。【０１９９】  （Ｃｏｍｂ＿ｉｎｆｏ＿Ｓｅｃｏｎｄａｒｙ＿ａｕｄｉｏ＿Ｐｒｉｍａｒｙ＿ａｕｄｉｏ）
Ｃｏｍｂ＿ｉｎｆｏ＿Ｓｅｃｏｎｄａｒｙ＿ａｕｄｉｏ＿Ｐｒｉｍａｒｙ＿ａｕｄｉｏは、そのセカンダリオーディオストリームの再生出力をミキシングすることができる１つ以上のプライマリオーディオストリームを一意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ以外の属性を有しているようなプライマリオーディオストリームの再生時においてのみ、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミキシングの可否を、オーサリング時に設定しておくことができる。【０２００】  （ｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報）
またＰｌａｙＬｉｓｔ情報において、ＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報は、ＰｌａｙＩｔｅｍ情報のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報と同じ値に設定される。よってＰｌａｙＩｔｅｍ情報のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”であるなら、ＳｕｂＰｌａｙＩｔｅｍ情報のｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報もＳＰ＿ＣＣ＝５に設定される。またＳｕｂＰｌａｙＩｔｅｍ情報のＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＰｌａｙＩｔｅｍ情報のＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと同じ時点を指し示す。【０２０１】  以上が本実施形態における記録媒体の改良である。続いて本実施形態に係る再生装置の内部構成について説明する。
＜再生装置の内部構成＞
図４１は、第５実施形態に係る再生装置の内部構成を示す図である。本図に示すように、ＴＢ６、ＥＢ７、オーディオデコーダ８は、Ａｕｄｉｏ  Ｍｉｘｉｎｇ  Ｐｒｏｃｅｓｓｏｒ（点線で囲まれた部分）に置き換えられている。このＡｕｄｉｏ  Ｍｉｘｉｎｇ  Ｐｒｏｃｅｓｓｏｒは、プライマリＴＳとセカンダリＴＳから２本の音声ストリームを入力し、同時にデコードしてミキシングするものである。その他の構成はＯｕｔ−ｏｆ−ＭＵＸアプリケーションを実現するための内部構成と同様である。以降、Ａｕｄｉｏ  Ｍｉｘｉｎｇ  Ｐｒｏｃｅｓｓｏｒについて説明する。Ａｕｄｉｏ  Ｍｉｘｉｎｇ  Ｐｒｏｃｅｓｓｏｒは、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６ａ、６ｂ、ＥＢ７ａ、７ｂ、プリロードバッファ７ｃ、オーディオデコーダ８ａ、８ｂ、ミキサ９ａ、９ｂから構成される。【０２０２】  Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６ａは、ＰＩＤ  Ｆｉｌｔｅｒ３ｂから出力された、オーディオストリームのＰＩＤを有するＴＳパケットを、先入れ先だし式に格納して、オーディオデコーダ８ａに供する。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ６ｂは、ＰＩＤ  Ｆｉｌｔｅｒ３ｄから出力された、オーディオストリームのＰＩＤを有するＴＳパケットのみを、先入れ先だし式に格納して、オーディオデコーダ８ｂに供する。【０２０３】  ＥＢ７ａは、バッファ６ａに格納されたＴＳパケットを変換することで得られる、ＰＥＳパケットを格納するバッファである。
ＥＢ７ｂは、バッファ６ａに格納されたＴＳパケットを変換することで得られる、ＰＥＳパケットを格納するバッファである。
プリロードバッファ７ｃは、ＢＤ−ＲＯＭ／ローカルストレージから読み出されたファイルｓｏｕｎｄ．ｂｄｍｖをプリロードしておくためのメモリである。ファイルｓｏｕｎｄ．ｂｄｍｖとは、メニューに対する操作に出力すべきオーディオデータを格納したファイルである。【０２０４】  オーディオデコーダ８ａは、プライマリＴＳを構成するＰＥＳパケットに対しデコード処理を行い、非圧縮状態のＬＰＣＭ状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。
オーディオデコーダ８ｂは、セカンダリＴＳを構成するＰＥＳパケットに対しデコード処理を行い、非圧縮状態のＬＰＣＭ状態のオーディオデータを得て出力する。これによりオーディオストリームにおけるデジタル出力がなされる。【０２０５】  ミキサ９ａは、オーディオデコーダ８ａから出力されるＬＰＣＭ状態のデジタルオーディオと、オーディオデコーダ８ｂから出力されるＬＰＣＭ状態のデジタルオーディオとをミキシングする。
ミキサ９ｂは、ミキサ９ａから出力されるＬＰＣＭ状態のデジタルオーディオと、バッファ７ｃに格納されているサウンドデータとをミキシングする。このサウンドミキサ９ｂによるミキシングは、クリック音の発音を意図したようなナビゲーションコマンドを、コントローラ２２が解読することでなされる。【０２０６】  以上が、本実施形態にかかる再生装置についての説明である。
＜オーディオミキシングアプリケーションに対するベリファイ＞
上述したように、オーディオミキシングアプリケーションはプライマリオーディオストリーム、セカンダリオーディオストリームから構成されるので、第２実施形態に示したようなベリファイは、プライマリオーディオストリーム、セカンダリオーディオストリームが同時に読み出された場合を想定して実行される。具体的にいうと、ＭａｉｎＣｌｉｐ、ＳｕｂＣｌｉｐが基準としているＡＴＣ時間軸において、１ずつＷｉｎｄｏｗを、シフトさせてゆく。このシフトの手順は、図３５のフローチャートに示したものと同じである。そしてＡＴＳに示されるＡＴＣ時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のＰＧストリーム、複数のＩＧストリームのうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、ＰＧストリームのビットレートの最大値、ＩＧストリームのビットレートの最大値を合計して、その合計量が４８Ｍｂｉｔ以下であるかを判定する。４８Ｍｂｉｔを越えていれば、ＢＤ−ＲＯＭ規格に違反していると判定結果を下す。【０２０７】  以上のように本実施形態によれば、ＢＤ−ＲＯＭ、ローカルストレージの双方からプライマリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマリオーディオストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに供給する場合でも、１秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、オーディオミキシングアプリケーションを、効率的に作成することができる。そのため、オーディオミキシングアプリケーションを実現するような追加コンテンツを、ローカルストレージにダウンロードして、ローカルストレージからデコーダに供給するという供給態様が可能になるので、ＢＤ−ＲＯＭの出荷後に、コメンタリを追加するような供給法を容易に実現することができる。【０２０８】  （第６実施形態）
第１実施形態では、ＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍにおけるＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとを一致させることで、ＰｌａｙＩｔｅｍ間の接続点、及び、ＳｕｂＰｌａｙＩｔｅｍの接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この接続点の一致を要求せず、ある程度の時間差を認める。【０２０９】  この時間差を認める場合、別の制限が必要になる。ＰｌａｙＩｔｅｍ、ＳｕｂＰｌａｙＩｔｅｍ間のシームレス接続において、上述したＳＴＣの変更処理を行うが、この変更処理は、デコーダがフリーラン状態にある場合になされる。この場合、シームレス接続ではＳＴＣが復帰するまで、デコーダは、同期制御に移ることができないので、ＳＴＣ変更を伴うシームレス接続は実装の都合上、頻繁には受け入れられない。したがって、ＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの両方において連続するＣＣ＝５の接続点は所定の時間間隔（例えば３秒程度）を置いて起こるように制限されるべきである。【０２１０】  図４２は、オーディオミキシングを示すプレイリストにて指定されるＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの相関を示した図である。図４２の第１段目は、ＰｌａｙＬｉｓｔ情報における３つのＰｌａｙＩｔｅｍ（ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２、ＰｌａｙＩｔｅｍ情報＃３）を示す。これら３つのＰｌａｙＩｔｅｍはプライマリＴＳを指定しており、ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２間はＣＣ＝１に設定され、ＰｌａｙＩｔｅｍ情報＃２、ＰｌａｙＩｔｅｍ情報＃３間は、ＣＣ＝５に設定されている。図４２の第２段目は、ＰｌａｙＬｉｓｔ情報における３つのＳｕｂＰｌａｙＩｔｅｍ（ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３）を示す。これら３つのＳｕｂＰｌａｙＩｔｅｍはセカンダリＴＳを指定しており、ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２間はＣＣ＝１に設定され、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３間は、ＳＰ＿ＣＣ＝５に設定されている。図４２の第３段目は、Ｐｒｏｇｒｅｓｓｉｖｅ  ＰｌａｙＬｉｓｔ情報における９つのＳｕｂＰｌａｙＩｔｅｍ（ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３〜ＳｕｂＰｌａｙＩｔｅｍ＃９）を示す。これら９つのＳｕｂＰｌａｙＩｔｅｍはセカンダリＴＳを指定しており、ＳｕｂＰｌａｙＩｔｅｍ＃３、ＳｕｂＰｌａｙＩｔｅｍ＃４間はＳＰ＿ＣＣ＝１に設定され、ＳｕｂＰｌａｙＩｔｅｍ＃４、ＳｕｂＰｌａｙＩｔｅｍ＃５間は、ＳＰ＿ＣＣ＝５に設定され、それ以外は、ＳＣ＝６に設定されている。【０２１１】  本図において、第２段目のＳｕｂＰｌａｙＩｔｅｍ＃３の開始は、第１段目におけるＰｌａｙＩｔｅｍ＃３の開始点より３秒前である。同様に、第３段目のＳｕｂＰｌａｙＩｔｅｍ＃５の開始点は、第１段目におけるＰｌａｙＩｔｅｍ＃３の開始点より３秒前である。
ＰｌａｙＩｔｅｍと、ＳｕｂＰｌａｙＩｔｅｍとのＳＴＣ時間軸切り替えのための時間間隔は、３秒になっているので、ＳＴＣ時間軸の変更が頻繁になり過ぎることはない。【０２１２】  またＣＣ＝１のタイミングはＰｌａｙＩｔｅｍに合わせてＳＰ＿ＣＣ＝１で接続される。これはＣＣ＝１のノンシームレス接続時にＳｕｂＰｌａｙＩｔｅｍだけが再生を連続して継続した場合に、ＰｌａｙＩｔｅｍとＳｕｂＰｌａｙＩｔｅｍの同期再生がずれていくことを防ぐためでもある。
ＰｌａｙＩｔｅｍの途中でＳｕｂＰｌａｙＩｔｅｍをＳＰ＿ＣＣ＝５で接続するという接続形態は、一枚のディスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。【０２１３】  図４３の第１段目は、劇場公開版とディレクターズカットの両方を構成するＰｌａｙＬｉｓｔ情報の一例を示す。このＰｌａｙＬｉｓｔ情報のうち、ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２、ＰｌａｙＩｔｅｍ＃４から構成されるがディレクターズカットであり、ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃３、ＰｌａｙＩｔｅｍ＃４から構成されるのが劇場公開版である。このように、ＰｌａｙＩｔｅｍ＃１とＰｌａｙＩｔｅｍ＃４はどちらのバージョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えることができる。図４３の第２段目は、同図の第１段目におけるＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２、ＰｌａｙＩｔｅｍ＃４に対応するコメンタリを１つのＳｕｂＰｌａｙＩｔｅｍとして定義し、ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃３、ＰｌａｙＩｔｅｍ＃４に対応するコメンタリとを、別のＳｕｂＰｌａｙＩｔｅｍとして定義する一例を示す。この場合、２つのＳｕｂＰｌａｙＩｔｅｍのそれぞれにおいて、ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃４に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。【０２１４】  図４３の第３段目は、ＰｌａｙＩｔｅｍ情報＃１、ＰｌａｙＩｔｅｍ情報＃２、ＰｌａｙＩｔｅｍ情報＃３、ＰｌａｙＩｔｅｍ情報＃４のそれぞれに対応するＳｕｂＰｌａｙＩｔｅｍ（ＳｕｂＰｌａｙＩｔｅｍ＃１、ＳｕｂＰｌａｙＩｔｅｍ＃２、ＳｕｂＰｌａｙＩｔｅｍ＃３、ＳｕｂＰｌａｙＩｔｅｍ＃４）を定義する一例を示す。そしてＳｕｂＰｌａｙＩｔｅｍ＃１と、ＳｕｂＰｌａｙＩｔｅｍ＃２及びＳｕｂＰｌａｙＩｔｅｍ＃３との間、ＳｕｂＰｌａｙＩｔｅｍ＃２及びＳｕｂＰｌａｙＩｔｅｍ＃３と、ＳｕｂＰｌａｙＩｔｅｍ＃４との間は、ＣＣ＝５で接続するものとする。これらの接続点は、ＰｌａｙＩｔｅｍにおける接続点と、３秒の時間間隔を設ける。つまりＰｌａｙＩｔｅｍ＃１が終わる３秒前にコメンタリの方はＳｕｂＰｌａｙＩｔｅｍ＃２とＳｕｂＰｌａｙＩｔｅｍ＃３にＣＣ＝５（もしくはＣＣ＝６）を使って分岐させている。【０２１５】  また、ＰｌａｙＩｔｅｍ＃２、ＰｌａｙＩｔｅｍ＃３が終わった３秒後にＣＣ＝５（もしくはＣＣ＝６）を使ってＳｕｂＰｌａｙＩｔｅｍ＃４に分岐している。ＳｕｂＰｌａｙＩｔｅｍ＃２とＳｕｂＰｌａｙＩｔｅｍ＃３の開始、及び、ＳｕｂＰｌａｙＩｔｅｍ＃４の開始は、ＰｌａｙＩｔｅｍ＃２とＰｌａｙＩｔｅｍ＃３の開始、及び、ＰｌａｙＩｔｅｍ＃４の開始から、３秒の時間間隔を置いている。以上の時間間隔を置くことにより、ＳＴＣ時間軸の変更が頻繁になり過ぎることはない。【０２１６】  厳密には、ＣＣ＝５は、ＳｕｂＰｌａｙＩｔｅｍ＃３からＳｕｂＰｌａｙＩｔｅｍ＃４への復帰の時だけ（ＡＴＣ／ＳＴＣ時間軸がリセットされるシームレス接続）必要であり、その他はＣＣ＝６で代用が可能である。
以上のように本実施形態によれば、ＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと、ＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅとが一致していないので、ＡＴＣ  Ｃｏｕｎｔｅｒ２ａと２ｃ、およびＳＴＣ  Ｃｏｕｎｔｅｒ３ａとＳＴＣ  Ｃｏｕｎｔｅｒ３ｃの同期は不要となり、再生装置の設計の余地を広げることができる。【０２１７】  （第７実施形態）
第６実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリームをＢＤ−ＲＯＭ、ローカルストレージから同時に読み出しデコーダに供給する場合、プライマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象としたが、本実施形態では、Ｐｉｃｔｕｒｅ  ｉｎ  Ｐｉｃｔｕｒｅ（ＰｉＰ）再生アプリケーションを実現する場合におけるビット量制限について説明する。【０２１８】  ＰｉＰ再生とは、ＰｌａｙＬｉｓｔ情報のＭａｉｎＰａｔｈ情報により、動画像を構成するＭａｉｎＣｌｉｐが指定されており、ＰｌａｙＬｉｓｔ情報のＳｕｂＰｌａｙＩｔｅｍ情報により、別の動画像を構成するＳｕｂＣｌｉｐが指定されている場合、前者の動画像（Ｐｒｉｍａｒｙ  Ｖｉｄｅｏ）と、後者の動画像（Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏ）とを、同じ画面内に表示するこという。ここでＰｒｉｍａｒｙ  ＶｉｄｅｏはＨＤ画像から構成され、Ｓｅｃｏｎｄａｒｙ  ＶｉｄｅｏはＳＤ画像から構成される。ＨＤ画像は、１９２０×１０８０という解像度を有し、フィルム素材同様、３７５０（もしくは３７５３か３７５４）クロックのフレーム間隔を有する。ＳＤ画像は、７２０×４８０という解像度を有し、ＮＴＳＣ素材同様、１５０１クロックの表示間隔、又は、ＰＡＬ素材同様、１８００クロックのフレーム間隔を有する。【０２１９】  ＳＤ画像の解像度は、ＨＤ画像の解像度の約１／４程度なので、ＨＤ画像たるＰｒｉｍａｒｙ  Ｖｉｄｅｏと、ＳＤ画像たるＳｅｃｏｎｄａｒｙ  Ｖｉｄｅｏとを同じ画面上に表示すると、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏは、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏに対し、約１／４程度の大きさになる。
ここでＳｅｃｏｎｄａｒｙ  Ｖｉｄｅｏは、監督や出演者のみが登場している動画像であり、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏにおける映像内容を指さすような演技を行っているものとする。かかる動画像がＳｅｃｏｎｄａｒｙ  Ｖｉｄｅｏであるなら、かかるＳｅｃｏｎｄａｒｙ  Ｖｉｄｅｏの映像内容を、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏの映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や出演者が指さして、解説しているような、楽しい画面演出を実現することができる。【０２２０】  ＜本実施形態におけるＰｌａｙＬｉｓｔ情報＞
Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏのためのビデオストリーム（セカンダリビデオストリーム）は、ＰｌａｙＬｉｓｔ情報のＳｕｂＰａｔｈ情報における複数のＳｕｂＰｌａｙＩｔｅｍ情報にて指定される。かかるＳｕｂＰｌａｙＩｔｅｍ情報には、ＰｉＰ＿Ｐｏｓｉｔｉｏｎ、ＰｉＰ＿Ｓｉｚｅという情報要素が新規に追加される。
“ＰｉＰ  Ｐｏｓｉｔｉｏｎ”は、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏ再生のための画面プレーン上のＸ座標、Ｙ座標を用いて、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏの再生映像が配置されるべき位置を示す。【０２２１】  “ＰｉＰ＿Ｓｉｚｅ”は、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏ再生映像の縦サイズ、横サイズを示す。
また、本実施形態においてＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”に設定されているということは、カレントＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐに多重化されているセカンダリビデオストリームと、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍ側のＳｕｂＣｌｉｐに多重化されているセカンダリビデオストリームとがシームレス接続される保証があることを意味する。かかるＳｕｂＰｌａｙＩｔｅｍのｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報は、ＰｌａｙＩｔｅｍ情報のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報と同じ値に設定されるので、ＰｌａｙＩｔｅｍ情報のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報が“＝５”であるなら、ＳｕｂＰｌａｙＩｔｅｍ情報のｓｐ＿ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ情報も“＝５”に設定されねばならない。つまりＰｌａｙＩｔｅｍ側のプライマリビデオストリームがシームレス接続されるなら、ＳｕｂＰｌａｙＩｔｅｍ側のセカンダリビデオストリームもシームレス接続されねばならない。またＳｕｂＰｌａｙＩｔｅｍ情報のＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅは、ＰｌａｙＩｔｅｍ情報のＩｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅと同じ時点を指し示さねばならない。【０２２２】  以上が、本実施形態における記録媒体の改良である。
＜本実施形態における再生装置の改良＞
続いて、再生装置の改良について説明する。Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏストリームのデコードを行うべく、本実施形態に係る再生装置のハードウェア構成には、ビデオストリームをデコードするための構成要素がもう一組、追加されている。ここでビデオストリームをデコードするための構成要素とは、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ、Ｍｕｌｔｉｐｌｅｘｅｄ  Ｂｕｆｆｅｒ、Ｅｌｅｍｅｎｔａｒｙ  Ｂｕｆｆｅｒ、デコーダ、Ｖｉｄｅｏプレーンであり、これらはセカンダリビデオストリームをデコードする。その他、本実施形態に係る再生装置には、以下のＳｃａｌｌｅｒ、合成部が追加されている。【０２２３】  Ｓｃａｌｌｅｒは、ＳｕｂＰｌａｙＩｔｅｍ情報のＰｉＰ＿Ｓｉｚｅに示される縦・横の大きさに基づき、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、Ｓｃａｌｌｅｒによりされた拡大又は縮小された再生映像と、ビデオデコーダにより得られた再生映像とを合成することでＰｉＰ再生を実現する。合成部によるＰｒｉｍａｒｙ  Ｖｉｄｅｏの再生映像と、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏの再生映像との合成は、ＳｕｂＰｌａｙＩｔｅｍ情報にて規定されている、ＰｉＰ＿Ｐｏｓｉｔｉｏｎに従ってなされる。こうすることにより、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏの再生映像と、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏの再生映像とが合成された合成映像が再生されることになる。この合成部による合成では、クロマキー合成、レイヤ合成等が可能であり、Ｓｅｃｏｎｄａｒｙ  Ｖｉｄｅｏにおける背景を取り除き、人物部分を抜き出した上で、Ｐｒｉｍａｒｙ  Ｖｉｄｅｏの再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置についての説明である。【０２２４】  ＜ＰｉＰアプリケーションに対するベリファイ＞
ＰｉＰ再生の実現にあたって、プライマリＴＳたるビデオストリーム（プライマリビデオストリーム）、セカンダリＴＳたるビデオストリーム（セカンダリビデオストリーム）を同時に読み出し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリームを、ビット量を制限するためのベリファイの対象とする。【０２２５】  具体的にいうとＡＴＣ時間軸においてＷｉｎｄｏｗをシフトさせた際、ＡＴＳに示されるＡＴＣ時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のＰＧストリーム、複数のＩＧストリームのうち、算出されたビットレートが最も高いものを選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、ＰＧストリームのビットレートの最大値、ＩＧストリームのビットレートの最大値を合計して、その合計量が４８Ｍｂｉｔ以下であるかを判定する。【０２２６】  以上のように本実施形態によれば、ＢＤ−ＲＯＭ、ローカルストレージの双方からプライマリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応するデコーダに供給する場合でも、１秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、ＰｉＰアプリケーションを、効率的に作成することができる。【０２２７】  （備考）
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的
であり、実施する者の主観によることは留意されたい。【０２２８】  （Ｉｎ＿Ｔｉｍｅ、Ｏｕｔ＿Ｔｉｍｅ）
図２７では、ＴＳ１の最後のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔをｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅとして選び、ＴＳ２の最初のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔをｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍ、ｐｒｅｖｉｏｕｓＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅとして選んだが、ＴＳ１の途中のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔをｐｒｅｖｉｏｕｓＰｌａｙＩｔｅｍのＯｕｔ＿Ｔｉｍｅとして選び、ＴＳ２の途中のＶｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  ＵｎｉｔをカレントＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍのＩｎ＿Ｔｉｍｅとして選んでもよい。この場合、ＰｌａｙＩｔｅｍ、カレントＳｕｂＰｌａｙＩｔｅｍは、シームレスに接続することができず、ＣＣ＝１，ＳＰ＿ＣＣ＝１として接続せねばならない。【０２２９】  （ＰｌａｙＬｉｓｔ情報全体）
２つのＰｌａｙＩｔｅｍ間をＣＣ＝５で接続しようとする場合、１つのＰｌａｙＬｉｓｔ情報に属する全てのＰｌａｙＩｔｅｍ情報、全てのＳｕｂＰｌａｙＩｔｅｍ情報は、ＣＣ＝５として接続せねばならない。
（デコーダへのデータ供給量）
Ｏｕｔ＿ｏｆ＿ＭＵＸにおいて、デコーダへのデータ供給量は必ずしも大きくなる訳ではない。例えば、プライマリオーディオストリームがＭａｉｎＣｌｉｐであり、ＣＢＲのＤＤ（Ｄｏｌｂｙ  Ｄｉｇｉｔａｌ）と、ＶＢＲのＭＬＰとから構成されていて、このＭＬＰが、ローカルストレージから供給されたＣＢＲのＤＤに置き換えられるものとする。この場合、デコーダへのデータ供給量はかえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。【０２３０】  （再生時間差）
ＣＣ＝５、ＳＰ＿ＣＣ＝５を実現するにあたって、１つのＰｌａｙＩｔｅｍの中での各ビデオストリーム／オーディオストリームの再生時間差も小さいことが望ましい。この差もビデオ１フレーム分（１／６０〜１／２５秒）としても良いし、１秒以下などとしても良いし、全体の再生時間に対する割合（１％以下など）であっても良いし、これら２つを組み合わせたものであっても良い。１つのＳｕｂＰｌａｙＩｔｅｍの中での各ビデオ／オーディオエレメンタリストリームの再生時間差も同様である。【０２３１】  １つのＰＩＤに、２つのエレメンタリストリームを格納するケースにおいては、同一ＰＩＤで格納される２つのストリームの再生時間長の差は、どちらか再生時間が短いストリームの方の最小再生単位（１フレーム）の再生時間長未満であることが望ましい。かかるケースに該当するのは、Ｄｏｌｂｙ  Ｄｉｇｉｔａｌ（ＡＣ−３）と、ＭＬＰ（Ｍｅｒｉｄｉａｎ  Ｌｏｓｓｌｅｓｓ  Ｐａｃｋｉｎｇ）とが、１つのエレメンタリストリームに格納されて、ＢＤ−ＲＯＭに記録される場合である。【０２３２】  （追加コンテンツに対する処理）
ローカルストレージ２００にダウンロードされた追加コンテンツは、何ヶ月、何年か経過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
（ＰＩＤの代用）
オーディオミキシングアプリケーションの実現時において、プライマリオーディオストリーム、セカンダリオーディオストリームの区別にＰＩＤを用いたが、ＭＰＥＧ２−ＰＳを使う場合には、ＰＥＳパケットヘッダのｓｔｒｅａｍ＿ｉｄをそれぞれ異なるものにするのが望ましい。【０２３３】  またプライマリオーディオストリーム、セカンダリオーディオストリームは、２つの音声ストリームが１つのデマルチプレクサでも弁別可能なように、システムストリームレベルにおいて区別されていればよい。もしくは、２つのストリームを１つに束ねる前に、片方の
ＰＩＤを重複しないように付け替えておくだけでもよい。【０２３４】  （プリロード）
クリック音のためのオーディオデータ（ファイルｓｏｕｎｄ．ｂｄｍｖ）のプリロードは、ＢＤ−ＲＯＭのローディング時やタイトル切替時に行うことが望ましい。何故なら、ＡＶＣｌｉｐの再生中にファイルｓｏｕｎｄ．ｂｄｍｖを読み出そうとすると、ＡＶＣｌｉｐとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、ＢＤ−ＲＯＭの装填時やタイトル切替時には、ＡＶＣｌｉｐの再生が継続していることは希なので、かかるタイミングにファイルｓｏｕｎｄ．ｂｄｍｖを読み出すことにより、機器の応答性を高めＡＶＣｌｉｐ再生が途切れにくくすることができる。【０２３５】  （Ｊａｖａ（ＴＭ）プラットフォーム）
各実施形態にかかる再生装置に、Ｊａｖａ（ＴＭ）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）Ｐｅｒｓｏｎａｌ  Ｂａｓｉｓ  Ｐｒｏｆｉｌｅ（ＰＢＰ  １．０）と、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ  ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ１．０．２）ｆｏｒ  ｐａｃｋａｇｅ  ｍｅｄｉａ  ｔａｒｇｅｔｓとをフル実装することでＪａｖａ（ＴＭ）プラットフォームを構成し、ＢＤ−Ｊアプリケーションを再生装置に実行させてもよい。そしてこのアプリケーションの実行にあたって、Ｏｕｔ＿ｏｆ＿ＭＵＸフレームワークを再生装置に実行させてもよい。【０２３６】  （タイトル）
ＢＤ−ＲＯＭの装填やユーザ操作、装置の状態に応じてタイトルを選択する“モジュールマネージャ”を再生装置に設けるのが望ましい。ＢＤ−ＲＯＭ再生装置内のデコーダは、この“モジュールマネージャ”によるタイトル選択に応じて、プレイリスト情報に基づくＡＶＣｌｉｐの再生を行う。【０２３７】  アプリケーションマネージャは、“モジュールマネージャ”がタイトルの選択を行った際、前のタイトルに対応するアプリケーション管理テーブル（ＡＭＴ）と、カレントタイトルに対応するＡＭＴとを用いてシグナリングを実行する。このシグナリングは、前のタイトルに対応するＡＭＴには記載されているが、カレントタイトルに対応するＡＭＴには記載されていないアプリケーションの動作を終了させ、前のタイトルに対応するＡＭＴには記載されておらず、カレントタイトルに対応するＡＭＴには記載されているアプリケーションの動作を開始させるという制御を行う。【０２３８】  （ローカルストレージ内のディレクトリ構成）
各実施形態に示したローカルストレージ内の各領域は、ＢＤ−ＲＯＭにおけるディスクルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、このＢＤ−ＲＯＭを作成した作成者が、ルート認証局から配布を受けたルート証明書を、ＢＤ−ＲＯＭに割り当てたものである。ディスクルート証明書はたとえばＸ．５０９の形式で符号されている。Ｘ．５０９の仕様は国際電信電話諮問委員会より発行されており、ＣＣＩＴＴ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｘ．５０９（１９８８），″Ｔｈｅ  Ｄｉｒｅｃｔｏｒｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ″に記載されている。【０２３９】  また、ＢＤ−ＲＯＭ、ローカルストレージの記録内容は、Ａｄｖａｎｃｅｎｄ  Ａｃｃｅｓｓ  Ｃｏｎｔｅｎｔ  Ｓｙｓｔｅｍ（ＡＡＣＳ）にて暗号化され、署名情報が付されて、利用権限が、パーミッションファイルに規定されているのが望ましい。
（実装すべきパッケージ）
ＢＤ−ＲＯＭ再生装置を、Ｊａｖａ（ＴＭ）プラットフォームとして実施するにあたっては、以下のＢＤ−Ｊ  Ｅｘｔｅｎｔｉｏｎを再生装置に実装するのが望ましい。ＢＤ−Ｊ  Ｅｘｔｅｎｔｉｏｎは、ＧＥＭ［１．０．２］を越えた機能を、Ｊａｖａ（ＴＭ）プラットフォームに与えるために特化された、様々なパッケージを含んでいる。ＢＤ−Ｊ  Ｅｘｔｅｎｔｉｏｎにて供給されるパッケージには、以下のものがある。
・ｏｒｇ．ｂｌｕｒａｙ．ｍｅｄｉａ
このパッケージは、Ｊａｖａ（ＴＭ）Ｍｅｄｉａ  ＦｒａｍｅＷｏｒｋに追加すべき、特殊機能を提供する。アングル、音声、字幕の選択についての制御が、このパッケージに追加される。
・ｏｒｇ．ｂｌｕｒａｙ．ｔｉ
このパッケージは、ＧＥＭ［１．０．２］における“サービス”を“タイトル”にマップして動作するためのＡＰＩや、ＢＤ−ＲＯＭからタイトル情報を問い合わせる機構や新たなタイトルを選択する機構を含む。
・ｏｒｇ．ｂｌｕｒａｙ．ａｐｐｌｉｃａｔｉｏｎ
このパッケージは、アプリケーションの生存区間を管理するためのＡＰＩを含む。また、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問い合わせるＡＰＩを含む。
・ｏｒｇ．ｂｌｕｒａｙ．ｕｉ
このパッケージは、ＢＤ−ＲＯＭに特化されたキーイベントのための定数を定義し、映像再生との同期を実現するようなクラスを含む。
・ｏｒｇ．ｂｌｕｒａｙ．ｖｆｓ
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、ＢＤ−ＲＯＭに記録されたコンテンツ（ｏｎ−ｄｉｓｃコンテンツ）と、ＢＤ−ＲＯＭに記録されていないＬｏｃａｌ  Ｓｔｏｒａｇｅ上のコンテンツ（ｏｆｆ−ｄｉｓｃコンテンツ）とをバインドする機構（Ｂｉｎｄｉｎｇ  Ｓｃｈｅｍｅ）を提供する。【０２４０】  Ｂｉｎｄｉｎｇ  Ｓｃｈｅｍｅとは、ＢＤ−ＲＯＭ上のコンテンツ（ＡＶＣｌｉｐ、字幕、ＢＤ−Ｊアプリケーション）と、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ上の関連コンテンツとを関連付けるものである。このＢｉｎｄｉｎｇ  Ｓｃｈｅｍｅは、コンテンツの所在に拘らず、シームレス再生を実現する。
（Ｖｉｒｔｕａｌ  Ｐａｃｋａｇｅ）
Ｖｉｒｔｕａｌ  Ｐａｃｋａｇｅを生成させるような処理をＢＤ−ＲＯＭ再生装置に行わせてもよい。これは、再生装置がＶｉｒｔｕａｌ  Ｐａｃｋａｇｅ情報を生成することでなされる。Ｖｉｒｔｕａｌ  Ｐａｃｋａｇｅ情報とは、ＢＤ−ＲＯＭにおけるボリューム管理情報を拡張した情報である。ここでボリューム管理情報は、ある記録媒体上に存在するディレクトリ−ファイル構造を規定する情報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管理情報とからなる。Ｖｉｒｔｕａｌ  Ｐａｃｋａｇｅ情報とは、ＢＤ−ＲＯＭのディレクトリ−ファイル構造を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、ＢＤ−ＲＯＭにおけるディレクトリ−ファイル構造の拡張を図ったものである。【０２４１】  （制御手順の実現）
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。【０２４２】  ・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム（オブジェクトプログラム）であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような１つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、ＪＡＶＡ（ＴＭ）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、１つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているＲＩＳＣプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。【０２４３】  本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。【０２４４】  記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。【０２４５】  オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。【０２４６】  本発明に係るプログラムは、以下のようにして使用することができる。本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム（ＢＩＯＳ）や、様々なミドルウェア（オペレーションシステム）と共に、命令ＲＯＭに書き込む。こうした命令ＲＯＭを、制御部に組み込み、ＣＰＵに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。【０２４７】  再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム（ＢＩＯＳ）が命令ＲＯＭに組み込まれており、様々なミドルウェア（オペレーションシステム）が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートＲＯＭが、再生装置に設けられている。この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、１つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートＲＯＭによるブートストラップを行い、オペレーションシステムを起動した上で、１つのアプリケーションとして、当該アプリケーションをＣＰＵに実行させ、本発明に係るプログラムを使用する。【０２４８】  ハードディスクモデルの再生装置では、本発明のプログラムを１つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
（コントローラ２２）
コントローラ２２は、一個のシステムＬＳＩとして実現することができる。【０２４９】  システムＬＳＩとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも１つのＬＳＩのような外形構造を複数個のベアチップに持たせたものも、システムＬＳＩに含まれる（このようなシステムＬＳＩは、マルチチップモジュールと呼ばれる。）。
ここでパッケージの種別に着目するとシステムＬＳＩには、ＱＦＰ（クッドフラッドアレイ）、ＰＧＡ（ピン  グリッドアレイ）という種別がある。ＱＦＰは、パッケージの四側面にピンが取り付けられたシステムＬＳＩである。ＰＧＡは、底面全体に、多くのピンが取り付けられたシステムＬＳＩである。【０２５０】  これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムＬＳＩにおけるピンには、こうしたインターフェイスの役割が存在するので、システムＬＳＩにおけるこれらのピンに、他の回路を接続することにより、システムＬＳＩは、再生装置の中核としての役割を果たす。
システムＬＳＩにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。【０２５１】  各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ＲＯＭには、プログラムにあたるロードモジュールや、基本入出力プログラム（ＢＩＯＳ）、様々なミドルウェア（オペレーションシステム）が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ＲＯＭを、ベアチップとしてパッケージングすることにより、本発明に係るシステムＬＳＩは生産することができる。【０２５２】  具体的な実装については、ＳｏＣ実装やＳｉＰ実装を用いることが望ましい。ＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ｃｈｉｐ）実装とは、１チップ上に複数の回路を焼き付ける技術である。ＳｉＰ（Ｓｙｓｔｅｍ  ｉｎ  Ｐａｃｋａｇｅ）実装とは、複数チップを樹脂等で１パッケージにする技術である。以上の過程を経て、本発明に係るシステムＬＳＩは、各実施形態に示した再生装置の内部構成図を基に作ることができる。【０２５３】  尚、上述のようにして生成される集積回路は、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
さらに、各記録再生装置の構成要素の一部又は全てを１つのチップとして構成してもよい。集積回路化は、上述したＳｏＣ実装，ＳｉＰ実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。
【産業上の利用可能性】
【０２５４】  本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
【図１】
2006109716.tif 000002
【図２】
2006109716.tif 000003
【図３】
2006109716.tif 000004
【図４】
2006109716.tif 000005
【図５】
2006109716.tif 000006
【図６】
2006109716.tif 000007
【図７】
2006109716.tif 000008
【図８】
2006109716.tif 000009
【図９】
2006109716.tif 000010
【図１０】
2006109716.tif 000011
【図１１】
2006109716.tif 000012
【図１２】
2006109716.tif 000013
【図１３】
2006109716.tif 000014
【図１４】
2006109716.tif 000015
【図１５】
2006109716.tif 000016
【図１６】
2006109716.tif 000017
【図１７】
2006109716.tif 000018
【図１８】
2006109716.tif 000019
【図１９】
2006109716.tif 000020
【図２０】
2006109716.tif 000021
【図２１】
2006109716.tif 000022
【図２２】
2006109716.tif 000023
【図２３】
2006109716.tif 000024
【図２４】
2006109716.tif 000025
【図２５】
2006109716.tif 000026
【図２６】
2006109716.tif 000027
【図２７】
2006109716.tif 000028
【図２８】
2006109716.tif 000029
【図２９】
2006109716.tif 000030
【図３０】
2006109716.tif 000031
【図３１】
2006109716.tif 000032
【図３２】
2006109716.tif 000033
【図３３】
2006109716.tif 000034
【図３４】
2006109716.tif 000035
【図３５】
2006109716.tif 000036
【図３６】
2006109716.tif 000037
【図３７】
2006109716.tif 000038
【図３８】
2006109716.tif 000039
【図３９】
2006109716.tif 000040
【図４０】
2006109716.tif 000041
【図４１】
2006109716.tif 000042
【図４２】
2006109716.tif 000043
【図４３】
2006109716.tif 000044
【手続補正書】
【提出日】平成19年10月2日(2007.10.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プレイリスト情報が記録された記録媒体であって、
前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
前記プレイリスト情報はストリームテーブルを含み、
前記ストリームテーブルは、
メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームの組みの単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする記録媒体。
【請求項２】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
前記エレメンタリストリームの種別は、プライマリオーディオストリームを含み、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリオーディオストリームの種別から選ばれる
ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記エレメンタリストリームの種別は、プライマリビデオストリームを含み、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリームの種別から選ばれる
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生装置であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するパケットを、メインパス情報に従って読み出す第１読出部と、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケットを、サブパス情報に従って読み出す第２読出部と、
デコーダと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パケットを得て、デコーダに供給する多重分離部とを備え、
多重分離部からデコーダに供給されるパケットの、単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする再生装置。  
【請求項６】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項５記載の再生装置。
【請求項７】
前記エレメンタリストリームの種別は、プライマリオーディオストリームを含み、
前記デコーダは、
プライマリオーディオストリームをデコードする第１デコーダと、及び、セカンダリオーディオストリームをデコードする第２デコーダと、第１、第２デコーダによるデコード結果を合成する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリオーディオストリームの種別から選ばれる
ことを特徴とする請求項６記載の再生装置。
【請求項８】
前記エレメンタリストリームの種別は、プライマリビデオストリームを含み、
前記デコーダは、
プライマリビデオストリームをデコードする第１デコーダと、及び、セカンダリビデオストリームをデコードする第２デコーダと、第１、第２デコーダによるデコード結果を合成する合成部とを備え、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリームの種別から選ばれる
ことを特徴とする請求項６記載の再生装置。
【請求項９】
アプリケーションデータを記録媒体に記録する記録方法であって、
アプリケーションデータを生成するステップ、
アプリケーションデータに対するベリファイを行うステップ
ベリファイ結果が正当であるアプリケーションデータが書き込まれた記録媒体を得るステップを備え、
アプリケーションデータは、プレイリスト情報と、デジタルストリームとを含み、
前記プレイリスト情報は、メインパス情報、サブパス情報を含み、
前記メインパス情報は、
複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、
複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、
前記プレイリスト情報はストリームテーブルを含み、
前記ストリームテーブルは、
メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、
前記ベリファイのステップは、
ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームの組みの単位時間当たりの総データサイズは、所定値以下であることを確認する
ことを特徴とする記録方法。
【請求項１０】
メインストリーム及びサブストリームに同種のエレメンタリストリームが複数存在する場合、
同種のエレメンタリストリームのうち、ビットレートが最も高いもののビット量の合計値が、所定値以下になる
ことを特徴とする請求項９記載の記録方法。
【請求項１１】
前記エレメンタリストリームの種別は、プライマリオーディオストリームを含み、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリオーディオストリームの種別から選ばれる
ことを特徴とする請求項１０記載の記録方法。
【請求項１２】
前記エレメンタリストリームの種別は、プライマリビデオストリームを含み、
前記ビットレートが最も高いエレメンタリストリームは、
プライマリビデオストリームの種別から選ばれる
ことを特徴とする請求項１０記載の記録方法。
【請求項１３】
ストリームは、複数のパケットから構成され、各パケットには、アライバルタイムスタンプが付与されており、
前記記録方法は、
複数アライバルタイムスタンプの基準となる時間軸上に、前記単位時間の長さをもつウィンドゥを定義し、アライバルタイムスタンプに示される座標に従い、当該ウィンドゥを、この時間軸上でシフトさせてゆくステップを含み、
前記ベリファイステップにおける総データサイズの確認は、
ウィンドゥが1回するシフトする毎に、行われる
ことを特徴とする請求項９記載の記録方法。
【請求項１４】
プレイリスト情報に従って、主たる再生区間が定義されたメインストリームと、従たる再生区間が定義されたサブストリームとを、再生する再生方法であって、
前記プレイリスト情報は、複数デジタルストリームのそれぞれに対し、再生区間を定義する情報であり、メインパス情報、サブパス情報を含み、
メインストリームのうち、主たる再生区間として定義されている部分を構成するパケットを、メインパス情報に従って読み出す第１読出ステップと、
サブストリームのうち、従たる再生区間として定義されている部分を構成するパケットを、サブパス情報に従って読み出す第２読出ステップと、
サブストリームのうち、主たる再生区間として定義されている部分、及び、サブストリームのうち、従たる再生区間として定義されている部分に対して多重分離を行い、パケットを得て、デコーダに供給する多重分離ステップとを備え、
多重分離部からデコーダに供給されるパケットの、単位時間当たりの総データサイズは、所定値以下である
ことを特徴とする再生方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Out-of-MUXフレームワークの技術分野に属する発明である。
【背景技術】
【０００２】
Out-of-MUXフレームワークとは、BD-ROM等のリードオンリー型の記録媒体に記録されているデジタルストリームと、リライタブル型の記録媒体である、ローカルストレージに記録されているデジタルストリームとを同時に読み出して、デコーダに供給し、同期再生させる技術である。
ここでBD-ROMに記録されているデジタルストリームが、映画作品の本編を構成するものであり、ローカルストレージに記録されているデジタルストリームが、映画監督のコメンタリを構成する場合、上述したOut-of-MUXフレームワークを実現することにより、BD-ROM上の本編と、ローカルストレージ上のコメンタリとを再生に供して、BD-ROMの内容拡充を図ることができる。尚、リードオンリー型記録媒体の先行技術としては、以下の特許文献に記載されているものがある。
【特許文献１】特願平８ー８３４７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで上述したOut-of-MUXフレームワークでは、BD-ROMに記録されたストリームと、ローカルストレージに記録されたストリームとを同時に読み出して、それらのストリームを構成するTSパケットを、デコーダに供給せねばならない。このデコーダへの供給にどれだけの帯域が必要であるかを検討すると、これらBD-ROMからの供給ビットレートが48Mbps、ローカルストレージからの供給ビットレートが48Mbpsである場合、ワーストケースにおいて、96Mbit(48Mbit＋48Mbit)ものデータ供給が、上述した同時読み出しの期間内において発生する可能性がある。かかるワーストケースの発生が考えられるなら、96MbpsというビットレートでTSパケットを供給できるよう装置内の帯域を上げねばならない。またそれが不可能であるならば、デコーダ内に大きなバッファを設けておき、当該供給が一時点に集中しないように、TSパケットの先読みをデコーダに行わせる必要がある。しかし上述した同時読み出しの期間が、短ければいざしらず、2時間という映画再生のオーダであれば、バッファの容量が不足し、充分な先読みが行えない。
【０００４】
充分な先読みが行えないため、先読みのためのバッファにアンダーフローが生じると、ビデオ又はオーディオの欠落が発生するため再生品質が著しく低下する。かといって、高いビットレートでのデータ供給が必要になるなら、再生装置の低価格化を大きく妨げる結果となる。
本発明の目的は、高い帯域を必要とせずとも、別々の記録媒体から供給されたデジタルストリームを、デコーダに供給することができる、記録媒体を提供することである。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明にかかる記録媒体は、プレイリスト情報が記録され、前記プレイリスト情報は、メインパス情報、サブパス情報を含み、前記メインパス情報は、複数デジタルストリームの1つを、メインストリームとして指定して、そのメインストリームに対し、主たる再生区間を定義する情報であり、
前記サブパス情報は、複数デジタルストリームのうち他のものを、サブストリームとして指定して、そのサブストリームに対し、前記主たる再生区間と同期すべき、従たる再生区間を定義する情報であり、前記プレイリスト情報はストリームテーブルを含み、前記ストリームテーブルは、メインストリームに多重化された少なくとも1つのエレメンタリストリーム、及び、サブストリームに多重化された少なくとも1つのエレメンタリストリームのうち、同時に再生することが許可されている組み合わせを１つ以上示し、ストリームテーブルにおいて同時に再生することが許可されているエレメンタリストリームの組みの単位時間当たりの総データサイズは、所定値以下である
【発明の効果】
【０００６】
ストリームテーブルにおいて再生が許可されている複数エレメンタリストリームの単位時間当たりの総データサイズは、所定値以下であり、ワーストケースにおいても、単位時間当たりに転送すべきTSパケットの量は、所定の上限値を上回ることはない。
例えば単位時間が1秒であり、所定の上限値が48Mbitである場合、ストリームの同時読み出しのため、TSパケットの供給量が局所的に96Mbitにまであがったとしても、“1秒当たりのビット量が48Mbit以下”に制限されるため、ワーストケースにあたる96Mbitのデータ供給量は、0.5秒以上継続することはない。
【０００７】
ストリームの再生時間軸上のどの時点においても「ワーストケースが0.5秒以上継続しない」との保障があるので、96Mbit×0.5秒のサイズのTSパケットを、常に先読みしてデコーダに供給するように、再生装置を構成しておけば、デコーダ内のバッファのアンダーフローを回避することができる。
「96Mbit×0.5秒」を上限値とした先読みにより、アンダーフローを生じさせることなく、TSパケットを安定的にデコーダに供給することができるので、Out-of-MUXフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。  バンド幅を高めるなくことなく、BD-ROMのみを対象としたような再生装置において、Out-of-MUXフレームワークを実現することができるので、Out-of-MUXフレームワークを実現するような再生装置を、低価格で、市場に供給することができる。
【０００８】
また「1秒当たり48Mbps以下」との制限があるので、再生装置は、上述したような“常に先読みを行う”という単純な制御を実行していれば、ワーストケースとなるデータ供給が発生したとしてもアンダーフローの発生を避けることができる。ワーストケースとなるデータ供給がいつ発生するかを予測する予測処理等の実装を省略することができるので、再生装置を、容易に開発することができる。
【発明を実施するための最良の形態】
【０００９】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ローカルストレージ２００である。ローカルストレージ２００は、再生装置３００、テレビ４００、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の応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。この第1段目においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
【００１３】
このBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリと呼ばれる3つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls)がある。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi)がある。
【００１４】
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts)がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図３は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts)は、AVClipを格納している。AVClipはMPEG2-TransportStream形式のデジタルストリームである。このデジタルストリームは、デジタル化された映像、デジタル化された音声を(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１段目、下２段目)、TSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００１５】
以降、これらのビデオストリーム、オーディオストリーム、PGストリーム、IGストリームについて説明する。
＜ビデオストリーム＞
ビデオストリームは、映画作品の動画像を構成するストリームであり、SD画像、HD画像であるピクチャデータから構成される。ビデオストリームには、VC-1のビデオストリーム、MPEG4-AVCのビデオストリーム、MPEG2-Videoのビデオストリームといった形式が存在する。MPEG4-AVCのビデオストリームでは、IDRピクチャ,Iピクチャ,Pピクチャ,Bピクチャに、PTS、DTSといったタイムスタンプが付され、このピクチャの単位で、再生制御がなされる。このように、PTS、DTSが付されて、再生制御の単位となる、ビデオストリームの一単位を“VideoPresentation Unit”という。
＜オーディオストリーム＞
オーディオストリームは、映画作品の音声を表すストリームであり、LPCMオーディオストリーム、DTS-HDオーディオストリーム、DD/DD+オーディオストリームやDD/MLPオーディオストリームといった形式が存在する。オーディオストリームにおけるオーディオフレームに、タイムスタンプが付され、このオーディオフレームの単位で、再生制御がなされる。このように、タイムスタンプが付されて、再生制御の単位となる、オーディオストリームの一単位を“AudioPresentation Unit”という。
＜PGストリーム＞
PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。PGストリームは、PCS(PresentationControl Segment)、PDS(Pallet Define Segment)、WDS(Window Define Segment)、ODS(ObjectDefine Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。
【００１６】
WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトのビット量を定義する機能セグメントであり、PDS(PalletDefine Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(PresentationControl Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、ColorChange、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。
【００１７】
＜IGストリーム＞
IGストリームは、対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(InteractiveComposition Segment)、PDS(Palette Difinition Segment)、ODS(Object DefinitionSegment)と呼ばれる機能セグメントからなる。ODS(Object Definition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(PaletteDifinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(InteractiveComposition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。
【００１８】
ここでAVClipは、1つ以上の“STC＿Sequence”から構成される。“STC＿Sequence”とは、AVストリームのシステム基準時刻であるSTC(SystemTime Clock)の不連続点(system time-base discontinuity)が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR(ProgramClock Reference)を運ぶPCRパケットの不連続情報(discontinuity＿indicator)がONである点である。
【００１９】
図４は、PESパケット列に、ビデオストリーム及びオーディオストリームがどのように格納されるかを更に詳しく示している。本図における第1段目は、ビデオストリームを示し、第3段目はオーディオストリームを示す。第2段目は、PESパケット列を示す。本図の矢印yy1,yy2,yy3,yy4に示すように、ビデオストリームにおける複数のVideoPresentation UnitであるIDR、Bピクチャ、Pピクチャは、複数に分割され、個々の分割部分が、PESパケットのペイロード(図中のV＃1,V＃2,V＃3,V＃4)に格納されることがわかる。またオーディオストリームを構成するAudioPresentation Unitであるオーディオフレームは、矢印aa1,aa2に示すように、個々の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パケットは１つのフレーム、もしくはペアとなる２つのフィールドを格納するのが一般的である。
【００２１】
図６は、トランスポートストリームの詳細を示す図である。本図における第1段目は、MPEG２トランスポートストリームを構成する複数のTSパケット列であり、第2段目はTSパケットの内部構成を示す。この第2段目に示すように、１つのTSパケットは、“ヘッダ”と、“適用フィールド（adaptationfield）”と、“ペイロード”とから構成される。引き出し線th1は、TSパケットヘッダの構成をクローズアップしている。このこの引き出し線に示すように、TSパケットヘッダには、PESパケットの先頭を格納していることを示す「ユニット開始表示（payload＿unit＿start＿indicator）」、トランスポートストリームに多重化されるエレメンタリストリームの種別を示す「PID（PacketIdentifier）」、TSパケットに適用フィールドが存在しているか否かを示す「適用フィールド制御」などが存在する。
【００２２】
引き出し線th2は、適用フィールドの内部構成をクローズアップしている。適用フィールドはTSパケットヘッダの適用フィールド制御が“1”に設定されている場合に、TSパケットに対して与えられる。具体的には、ビデオ、オーディオのフレーム先頭であり、エントリーポイントであることを示す「ランダムアクセス表示（random＿access＿indicator）」、T-STD（TransportSystem Target Decoder）のSTC（System Time Clock）を与える「PCR（Program Clock Reference）」などが、この適用フィールドに格納される。
【００２３】
図７は、PAT、PMTパケットの内部構成を示す図である。これらのパケットは、トランスポートストリームのプログラム構成を記述するものである。
本図における引き出し線hm1は、トランスポートストリームに存在するPID=0のTSパケットの構成をクローズアップしている。かかるTSパケットは、PAT（ProgramAssociation Table）パケットと呼ばれ、トランスポートストリーム全体の番組構成を示す。PATパケットのPIDは常に“0”である。PATパケットには、PAS（ProgramAssociation Section）が格納される。引き出し線hm2は、PASの内部構成をクローズアップしている。この引き出し線に示すようにPASは、program＿number(番組番号)と、programmap table(PMTのPID)とを対応付けて示している。引き出し線hm3は、トランスポートストリームに存在するPID=0x100のTSパケットの構成をクローズアップしている。かかるTSパケットは、PMTパケットと呼ばれる。引き出し線hm4に示すように、PMTパケットのPMSは、そのPMSに対応する番組に含まれるストリーム種別を示す「stream＿type」と、そのストリームのPIDである「elementary＿PID」とを含む。本図の例では、番組番号＃1の番組は、PID=0x100のPMTを有しており、PID=0x200と0x201とを有するMPEG２ビデオと、ADTSオーディオとが、この番組番号＃1の番組を構成していることがわかる。このようにして、常にPID=0であるPATからPMTのPIDを取得し、このPMTのPIDからPMTパケットを取得して、PMSを参照することで、トランスポートストリーム中の番組と、その構成ストリームのPIDやストリームタイプとを知得することができる。
【００２４】
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図８は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS＿extra＿header(図中のハッチング部)、が付されて、192バイト長のSourceパケットになる。このTS＿extra＿headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival＿Time＿Stampを含む。ATSヘッダをTSパケットごとに付与してストリームを形成する理由は、TSパケットごとにデコーダ（STD）への入力時刻を与えるためである。デジタル放送ではトランスポートストリームは固定ビットレートとして扱われる。そのため、NULLパケットと呼ばれるダミーのTSパケットを多重化して固定ビットレートとしたトランスポートストリームを放送している。光ディスクのような限られた記録容量の記録媒体にストリームを記録するときに固定ビットレートの記録方式は無駄に容量を消費するので不都合である。そのためBD-ROMではNULLパケットを記録することはしない。そして、可変ビットレートの記録方式に対応するため、個々のTSパケットにATSを付与した上でトランスポートストリームを記録する。このATSを用いることで、TSパケットごとにデコーダ入力時刻を復元することができ、可変ビットレートの記録方式に対応することができる。以降、ATSヘッダとTSパケットの１組をソースパケット（SourcePacket）と呼ぶ。
【００２５】
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC＿Sequence”を構成する。“ATC＿Sequence”とは、Sourceパケットの配列であって、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival＿Time＿Stampが参照しているArrival＿Time＿Clockに、連続性が存在するSourceパケット列を“ATC＿Sequence”という。
【００２６】
かかるATC＿SequenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳextent以上のデータ長を有する。
【００２７】
AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentを検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Ｔjump＝Ｔaccess+Ｔoverhead
で与えられる。
Ｔaccessは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時間である。
BD-ROMから読み出されたTSパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Rudというビットレートで行われ、ECCブロックにおけるセクタ数をSeccとした場合、
Ｔoverheadは、
Ｔoverhead≦(2×Secc×8)／Rud＝20m秒
という計算で与えられる。
BD-ROMから読み出されたTSパケットは、Sourceパケットの状態でリードバッファに格納された上、TS＿Recording＿rateという転送レートで、デコーダに供給される。
【００２８】
TS＿Recording＿rateという転送レートでの、デコーダへのTSパケット供給が跡絶えさせないためには、Ｔjumpの間、リードバッファからデコーダへのTSパケット出力が継続している必要がある。ここでリードバッファからの出力は、TSパケットではなく、Sourceパケットの状態でなされるので、TSパケットのSourceパケットとのサイズ比を192/188とした場合、Ｔjumpの間、(192/188×TS＿Recording＿rate)という転送レートにより、リードバッファからのSourceパケット出力が継続している必要がある。
従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Ｂoccupied≧(Tjump/1000×8)×((192/188)×TS＿Recording＿rate)
となる。
リードバッファへの入力レートはRud、リードバッファからの出力レートはTS＿Recording＿rate×(192/188)であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、(Rud−TS＿Recording＿rate×(192/188))になる。
【００２９】
このＢoccupiedを、リードバッファに蓄積するのに要する時間Txは、
Tx＝Ｂoccupied/(Rud−TS＿Recording＿rate×(192/188))
になる。
BD-ROMからの読み出しには、この時間TxにおいてRudでのTSパケット入力を継続する必要があるので、AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentは、
Ｓextent＝Rud×Tx
＝Rud×Ｂoccupied/(Rud−TS＿Recording＿rate×(192/188))
≧Rud×(Tjump/1000×8)×((192/188)×TS＿Recording＿rate)
/(Rud−TS＿Recording＿rate×(192/188))
≧(Rud×Tjump/1000×8)×
×TS＿Recording＿rate×192/(Rud×188−TS＿Recording＿rate×192)
になる。
よって
Ｓextent≧
(Tjump×Rud/1000×8)×
（TS＿Recording＿rate×192/(Rud×188−TS＿Recording＿rate×192))
になる。
AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさないように算出されたＳextent以上のデータ長をもつことにより、AVClipを構成する各ファイルエクステントが、BD-ROM上において離散的に位置されたとしても、再生時においてデコーダへのTSパケット供給が途絶えさせることなく、連続的に読み出されることになる。
【００３０】
上述したファイルエクステントは、Sourceパケット32個集めたアラインドユニット（Aligned Unit、6KByteのデータサイズ）を最小単位として構成されている。したがって、BDでのストリームファイル（XXXXX.AVClip）のファイルサイズは常に6KByteの倍数となる。
図９は、Aligned Unitの内部構成を示す図である。Aligned Unitは、32個のSourceパケットから構成され、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。BD-ROMにおけるセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAlignedUnitの単位でBD-ROMをアクセスする限り、32個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。BD-ROMに記録され、高画質なビデオストリームが多重化されているAVClipを、以下“MainClip”と呼ぶ。これに対し、ローカルストレージに記録され、MainClipと同時に再生されるAVClipを、“SubClip”とよぶ。
【００３１】
BD-ROMに記録されているMainClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。このパーシャルトランスポートストリームは、個々のエレメンタリストリームに対応するものである。MainClipを多重分離することで得られるパーシャルトランスポートストリームであって、1つのエレメンタリストリームに対応するものを“プライマリTS”という。
＜BD-ROMの構成その２.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.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に含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。
【００３４】
Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramSequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSD画像からHD画像に変化している点等をいう。
続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP＿map＿for＿one＿stream＿PID(EP＿map＿for＿one＿stream＿PID[0]〜EP＿map＿for＿one＿stream＿PID[Ne-1])からなる。これらEP＿map＿for＿one＿stream＿PIDは、AVClipに属する個々のエレメンタリストリームについてのEP＿mapである。EP＿mapは、1つのエレメンタリストリーム上において、AccessUnitが存在するエントリー位置のパケット番号(SPN＿EP＿start)を、エントリー時刻(PTS＿EP＿start)と対応づけて示す情報である。図中の引き出し線cu3は、EP＿map＿for＿one＿stream＿PIDの内部構成をクローズアップしている。
【００３５】
これによると、EP＿map＿for＿one＿stream＿PIDは、Nc個のEP＿High(EP＿High(0)〜EP＿High(Nc-1))と、Nf個のEP＿Low(EP＿Low(0)〜EP＿Low(Nf-1))とからなることがわかる。ここでEP＿Highは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN＿EP＿start及びPTS＿EP＿startの上位ビットを表す役割をもち、EP＿Lowは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN＿EP＿start及びPTS＿EP＿startの下位ビットを示す役割をもつ。
【００３６】
図中の引き出し線cu4は、EP＿Highの内部構成をクローズアップしている。この引き出し線に示すように、EP＿High(i)は、EP＿Lowに対する参照値である『ref＿to＿EP＿Low＿id[i]』と、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS＿EP＿High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN＿EP＿High[i]』とからなる。ここでiとは、任意のEP＿Highを識別するための識別子である。
【００３７】
図中の引き出し線cu5は、EP＿Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP＿Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is＿angle＿change＿point(EP＿Low＿id)』と、対応するAccessUnitのサイズを示す『I＿end＿position＿offset(EP＿Low＿id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS＿EP＿Low(EP＿Low＿id)』と、対応するAccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN＿EP＿Low(EP＿Low＿id)』とからなる。ここでEP＿Low＿idとは、任意のEP＿Lowを識別するための識別子である。
【００３８】
＜Clip情報の説明その２.EP＿map＞
以下、具体例を通じて、EP＿mapについて説明する。図１１は、映画のビデオストリームに対するEP＿map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP＿mapの設定を示す。
【００３９】
第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP＿mapは、t1〜t7をエントリー時刻(PTS＿EP＿start)として示し、これに対応づけてエントリー位置(SPN＿EP＿start)を示すよう、設定される。  
＜PlayList情報＞
続いて、PlayList情報について説明する。拡張子“mpls”が付与されたファイル(00001.mpls)は、PlayList(PL)情報を格納したファイルである。
【００４０】
図１２は、PlayList情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())を含む。
＜PlayList情報の説明その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
【００４１】
MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip＿Information＿file＿name』と、AVClipの符号化方式を示す『Clip＿codec＿identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is＿multi＿angle』と、このPlayItem(カレントPlayItem)と、その1つ前のPlayItem(previousPlayItem)との接続状態を示す『connection＿condition』と、このPlayItemが対象としているSTC＿Sequenceを一意に示す『ref＿to＿STC＿id[0]』と、再生区間の始点を示す時間情報『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情報との関係を示す図である。第1段目は、PlayList情報がもつ時間軸(PlayList時間軸)を示す。第2段目から第5段目は、EP＿mapにて参照されているビデオストリームを示す。
PlayList情報は、PlayItem情報＃1,＃2という2つのPlayItem情報を含んでおり、これらPlayItem情報＃1,＃2のIn＿time,Out＿timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。  
【００４３】
以上が、BD-ROM１００についての説明である。
＜ローカルストレージ２００＞
続いて、本発明にかかる記録媒体である、ローカルストレージ２００について説明する。図１４は、ローカルストレージ２００の内部構成を示す図である。本図に示すように、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。
【００４４】
本図の第４段目にローカルストレージ２００を示し、第３段目にローカルストレージ２００上のトラックを示す。本図のトラックは、ローカルストレージ２００の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてローカルストレージ２００の応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第1段目のようになる。
【００４５】
本図のディレクトリ構造においてROOTディレクトリの配下には、「organization＃1」というサブディレクトリがあり、その配下に、「disc＃1」というサブディレクトリがある。ディレクトリ「organization＃1」とは、映画作品の特定のプロバイダに割り当てられたディレクトリである。「disc＃1」は、そのプロバイダが提供したBD-ROMのそれぞれに割り当てられたディレクトリである。
【００４６】
特定のプロバイダに対応するディレクトリに、各BD-ROMに対応するディレクトリを設けることにより、各BD-ROMについてのダウンロードデータが個別に格納される。このサブディレクトリの配下に、BD-ROMに格納されていたのと同様、PlayList情報(00002.mpls)、Clip情報(00003.clpi,00004.clpi)、AVClip(00003.m2ts,00004.m2ts)が格納されている。  
続いて、ローカルストレージ２００の構成要素となる、PlayList情報、Clip情報、AVClipについての説明する。
【００４７】
＜ローカルストレージ２００の構成その１.AVClip＞
ローカルストレージ２００上のAVClip(00003.m2ts,00004.m2ts)は、SubClipを構成する。このSubClipに対して、多重分離を行うことで、パーシャルトランスポートストリームが得られる。SubClipを多重分離することで得られるパーシャルトランスポートストリームを“セカンダリTS”という。かかるセカンダリTSは、Out＿of＿MUXアプリケーションを構成するものである。以降、Out＿of＿MUXアプリケーションについて説明する。
（Out-of-MUXアプリケーション）
Out-of-MUXアプリケーションとは、例えば、BD-ROM上のプライマリTSと、ネットワークなどを介して取得して、ローカルストレージに記録されたセカンダリTSの２つのTSを同時に再生選択することで、この２本のTS間で様々なエレメンタリストリームの組み合わせを可能とするアプリケーションである。
【００４８】
図１５は、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ装置、ローカルストレージ、ネットワーク部を左側に示し、デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPIDFilterを示す。そして本図におけるプライマリTS(Video1,Audio1(English),Audio2(Spanish),PG1(EnglishSubtitle),IG1(English Menu))、セカンダリTS(Audio2(Japanese),Audio3(Korean),PG2(JapaneseSubtitle),PG3(Korean Subtitle),IG2(Japanese Menu),IG3(Korean Menu))は、それぞれBD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio1）とスペイン語（Audio 2）しか記録されていないため、日本語吹き替えなどをこのディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供する日本語吹き替え（Audio2）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、日本語吹き替え音声（Audio 2）と、日本語字幕（PG 2）と、日本語メニュー画面（IG2）とを、デコーダに送り込むことができる。こうすることでユーザーは、日本語吹き替え音声（Audio 2）と、日本語字幕（PG 2）とを、日本語メニュー画面（IG2）から選択して、映像(Video1)と共に再生することができる。
【００４９】
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情報＞
ローカルストレージ上に存在するClip情報(00003.clpi,00004.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のオーディオが選択されればSourceDe-packetizerからデコーダ内のバッファまでが、プライマリTS用のビットレートに設定され、セカンダリTSのオーディオが選択されるとSource  De-packetizerからデコーダ内のバッファまでが、セカンダリTSのためのビットレートが設定されることになり、再生装置モデルの処理や検証が煩雑になってしまうからである。
＜ローカルストレージ２００の構成その２.PlayList情報＞
続いて、ローカルストレージ２００上のPlayList情報について説明する。拡張子“mpls”が付与されたファイル(00002.mpls)は、MainPath、Subpathと呼ばれる2種類の再生経路を束ねたものをPlaylist(PL)として定義する情報である。図１６は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())と、Subpathを定義するSubpath情報(Subpath())とからなる。かかるPlayList情報の内部構成、及び、PlayItem情報の内部構成は、BD-ROMのものと同じであり、説明を省略する。以降、Subpath情報について説明する。
＜PlayList情報の説明その１.Subpath情報＞
MainPathが、主映像たるMainClipに定義される再生経路であるのに対し、Subpathは、MainPathと同期すべきSubClipに対して定義される再生経路である。
【００５３】
図１７は、Subpath情報の内部構成をクローズアップして示す図である。本図における矢印hc0に示すようにSubpath情報は、SubClipの類型を示すSubPath＿typeと、1つ以上のSubPlayItem情報(・・・SubPlayItem()・・・)とを含む。
図中の引き出し線hc1は、SubPlayItem情報の構成をクローズアップしている。SubPlayItem情報は、図中の矢印hc1に示すように『Clip＿information＿file＿name』、『Clip＿codec＿identifier』、『SP＿connection＿condition』、『ref＿to＿STC＿id[0]』、『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)と、その1つ前のSubPlayItem(previousSubPlayItem)との接続状態を示す。
【００５５】
『ref＿to＿STC＿id[0]』は、この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で指定されたPlay Itemの再生時間軸上において、SubPlayItem＿In＿timeで指定されたSubPlayItemの始点が、どこに存在するかを示す。
【００５７】
＜SubPath情報についての詳細その２.三者の関係＞
ここでの三者とは、ローカルストレージ２００上のSubClip、ローカルストレージ２００上のPlayList情報、BD-ROM上のMainClipの三者をいう。
図１８は、ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。本図において第1段目は、ローカルストレージ２００上に存在するSubClipを示す。この第1段目に示すように、ローカルストレージ２００上のSubClip内のセカンダリTSには、オーディオストリーム、PGストリーム、IGストリームといった種別がある。これらのうち何れかが、SubPathとして同期再生に供されることになる。
【００５８】
第2段目は、PlayList情報により定義される2つの時間軸を示す。第2段目のうち下側の時間軸は、PlayItem情報により定義されるPlayList時間軸を示し、上側の時間軸はSubPlayItemにより定義されるSubPlayItem時間軸を示す。
本図に示すように、SubPlayItem情報のSubPlayItem＿Clip＿information＿file＿nameは、SubClipを格納した.m2tsファイルのうち、どれを再生区間の対象として選ぶかという、SubClip選択の役割を果たしていることがわかる。
【００５９】
そしてSubPlayItem.IN＿time、SubPlayItem.Out＿timeは、SubClip上の、再生区間の始点及び終点を定義するという役割を果たしていることがわかる。
矢印Sync＿PlayItem＿Idは、どのPlayItemとの同期を意図しているかという同期指定の役割を果たし、sync＿start＿PTS＿of＿PlayItemは、PlayList時間軸上におけるSubPlayItem＿In＿timeの位置を決める役割を果たす。
【００６０】
以上が、SubPath情報についての説明である。
＜STN＿table＞
このローカルストレージ２００上の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と対応付けることで構成される。
図１９（ａ）は、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の詳細について説明する。
【００６３】
図１９（ｂ）は、ビデオストリームに対応したStream＿attributeを示す図である。
ビデオストリームにおけるStream＿attributeは、ビデオストリームの表示方式を示す『Video＿format』と、ビデオストリームの表示周波数を示す『frame＿rate』等を含む。
図１９（ｃ）は、オーディオストリームに対応したStream＿attributeを示す図である。
【００６４】
オーディオストリームにおけるStream＿attributeは、オーディオストリームの符号化方式を示す『stream＿coding＿type』と、対応するオーディオストリームのチャネル構成を示す『audio＿presentation＿type』と、対応するオーディオストリームのサンプリング周波数を示す対応する『Sampling＿frequency』と、オーディオストリームの言語属性を示す『audio＿languagecode』からなる。
【００６５】
図１９（ｄ）は、ビデオストリームにおけるStream＿entryを示す図である。本図に示すように、ビデオストリームのStream＿entryは、ビデオストリームの多重分離に用いられるPIDを示す「ref＿to＿Stream＿PID＿of＿Main＿Clip」を含む。
MainClipにて多重化されているオーディオストリーム、IGストリーム、PGストリームのStream＿attributeは、この図１９（ｄ）の形式になっている。
【００６６】
＜再生が許可されているエレメンタリストリームのデータ量制限＞
STN＿tableは、BD-ROMから読み出されるエレメンタリストリーム、ローカルストレージから読み出されるエレメンタリストリームのうち、再生が許可されているものを示すが、かかるSTN＿tableが、無制限に、エレメンタリストリームの再生を許可しているとなると、デコーダシステムの破綻を招く恐れがある。
【００６７】
その理由は、以下の通りである。MPEG2のデコーダシステム標準によると、1つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。これは、デコーダシステムにおいて正しくデコード処理を行わせるための基本原則である。一方、BD-ROMにおけるストリームの再生が許可されると共に、ローカルストレージにおけるストリームの再生が許可されており、BD-ROMからのAVClip再生と、ローカルストレージからのAVClip再生とを同時に実行する場合、BD-ROMからのTSパケットと、ローカルストレージからのTSパケットとにオーバーラップが生じてしまう。
【００６８】
そこで本実施形態では、デコードエレメンタリストリームに、以下のような制限を課している。
デコードエレメンタリストリームとは、STN＿tableにおいて再生が許可されていて、一緒に再生するため、選択されたビデオストリーム、オーディオストリーム、PGストリーム、IGストリームである。デコードエレメンタリストリームには、ローカルストレージからの読み出されるものと、BD-ROMから読み出されるものの両者がある。
【００６９】
デコードエレメンタリストリームに課される制限とは、STN＿tableにおいて同時に再生することが許可されているエレメンタリストリームを含み、再生が許可されていないエレメンタリストリームを含まないAVClip(MainClip,SubClip)を構成するTSパケット(DecodingTSパケット)の、1秒当たりのビット量は48Mbit以下になるというものである。
この1秒という単位時間は、“Window”と呼ばれ、ATC Sequenceの時間軸上の任意の位置に置かれる。つまり、デコードエレメンタリストリームにおけるビット量は、どのような1秒の期間においても、この48Mbit以下という条件を満たす必要がある。
【００７０】
図２０は、BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。本図の第1段目は、BD-ROMから読み出された複数のTSパケット、第3段目は、ローカルストレージから読み出された複数のTSパケットを示す。これら第1段目、第3段目のTSパケットのうち、ハッチングが付されたものがデコードエレメンタリストリームを構成するTSパケット(DecodingTSパケット)である。本図における第2段目は、第1段目に示したDecoding TSパケット、第3段目に示したDecoding TSパケットのうち、1秒という期間に属すものを示す。上述したように、MPEG2のデコーダシステム標準によると、1つのトランスポートストリームにおけるATC時間軸のTSパケット間には、オーバーラップが存在してはならない。しかし、本図によると、ATC時間軸において、TSパケット間のオーバーラップrp1,rp2,rp3が発生していることがわかる。このように、Windowという単位時間において、TSパケット動作のオーバーラップが許容されているのである。しかし、MPEG2のデコーダシステム標準にはない別の要件が課されている。それが上述した、1Window当たり48Mbit以下という制限である。第4段目は、この第2段目に示す、DecodingTSパケットが満たすべき条件を数式で表している。この数式の意味は、上述したDecoding TSパケットの個数を、ビット数に換算した値(TSパケットのバイト数である188をかけ、ビット数8で表した値)が、48Mbit以下になるというものである。
【００７１】
任意の1秒という期間において、Decoding TSパケットに以上のような条件を課すのが、本実施形態におけるビット量の制限である。Out＿of＿MUXアプリケーションのためのオーサリング時には、Sourceパケット列において、かかるWindowを、1パケットずつシフトさせつつ、1秒という期間内の、DecodingTSパケットのビット数が、48Mbit以下という制限を満たすかどうかをチェックする。もし、制限を満たせば、次のTSパケットにWindowをシフトさせ、制限を満たさねば、BD-ROM規格に違反していると断定する。そして、かかるシフトを繰り返した結果、WindowのOut＿Timeが、最後のSourceパケットに達すれば、当該Sourceパケットは、BD-ROM規格に整合しているとの判定を下す。
【００７２】
＜Windowのシフト＞
TSパケットのそれぞれには、27MHzの時間精度をもつATSが付与されている。ATC時間軸上の座標は、1/27,000,000秒という時間精度をもつが、このATC時間軸上の各座標に、ATSが存在するとは限らない。ATC時間軸には、ATSがまったく存在しない期間や、ATSが存在する期間が不規則に現れる。ATSの出現にバラツキがあるので、Windowをシフトするにあたって、In＿Timeから1秒後にATSが存在しない場合、WindowのOut＿Timeをどのように調整するかが問題になる。
【００７３】
WindowのOut＿Timeは、原則としてIn＿Timeの1秒として設定される。ここでATC時間軸において、In＿Timeの1秒後にあたる座標にATSが存在すれば、In＿Time＋1秒の座標を、Out＿Timeとする。もしIn＿Timeの1秒後にあたる座標にATSが存在しなければ、In＿Time＋1秒以降であって、ATSが初めて現れるATC時間軸の座標を、Out＿Timeとする。ATSの空白期間を考慮しながらOut＿Timeを調整しつつ、Windowをシフトしてゆくので、Windowがシフトする度に、異なるビット値が算出される。In＿Timeを1TSパケットずつシフトしてゆき、これに伴いOut＿Timeを調整することで、ATC時間軸におけるビット値の遷移を緻密に計算してゆくことができる。
【００７４】
図２１は、Windowのシフトを示す図である。（ａ）〜（ｄ）のそれぞれのうち、上段はベリファイの対象となるSourceパケット列を示し、下段は、WindowのIn＿Time、Out＿Timeを示す。同図（ａ）では、WindowのIn＿Timeは、Sourceパケット＃iを指定している。このWindowのIn＿Timeから1秒後に存在するTSパケット＃jが、WindowのOut＿Timeに設定される。
【００７５】
同図（ｂ）では、WindowのIn＿Timeは、Sourceパケット＃i+1を指定している。一方、このWindowのIn＿Timeから1秒後において、Sourceパケット＃j+1にあたる座標には、SourceパケットのATSが存在しない。この（ｂ）におけるWindowのOut＿Timeは、TSパケット＃jを越えたものになるが、TSパケット＃jの直後に、Sourceパケットが存在しないため、（ｂ）のWindowにおけるビットレートは、（ａ）のWindowにおけるビットレートより少なくなってしまう。これでは、（ｂ）のWindowは、チェックに値しなくなる。そこで、Out＿Timeの調整により、WindowのIn＿Timeから1秒以降に初めて現れるTSパケット＃j+2を、WindowのOut＿Timeにする。Out＿Timeをこのように設定すれば、（ｂ）のWindowは、チェックに値するものとなる。
【００７６】
同図（ｃ）では、WindowのIn＿Timeは、Sourceパケット＃i+2を指定している。一方、このWindowのIn＿Timeから1秒後には、Sourceパケット＃j+2が位置している。この（ｃ）のWindowは、TSパケットの数が、（ｂ）のWindowにおける数と変わらず、チェックに値しない。故に、この（ｃ）では、チェックが行われず、更にWindowのIn＿Timeを進める。
同図（ｄ）では、WindowのIn＿Timeは、Sourceパケット＃i+3を指定している。一方、このWindow＿In＿Timeから1秒後において、Sourceパケット＃j+3にあたる位置には、Sourceパケットが存在しない。そこで上述したようなOut＿Timeの調整を行い、WindowのIn＿Timeから1秒以降に初めて現れるTSパケット＃j+4を、WindowのOut＿Timeとする。こうすることで、Window内のTSパケット数は、（ｂ）と違うものとなり、チェックに値する。
【００７７】
以上のようなWindowシフトを伴う、ビット量チェックをオーサリング時に実行することで、ローカルストレージ及びBD-ROMからTSパケットが読み出され、デコーダに供給されたとしても、アンダーフロー又はオーバーフローを招かないことは保障される。
以上のWindowシフトによる保障を、図２２〜図２６の具体例を参照しながら説明する。
図２２の第1段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。横軸は時間軸であり、縦軸は時間軸上の各時点における転送量を示す。このグラフにおいて、BD-ROM及びローカルストレージからの読み出し時のビット量は、破線の曲線のように推移する。
【００７８】
図２２の第2段目は、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのうち、デコーダに供給されるものの合計のデータ量を示す。合計転送量の時間的推移は、実線の曲線に示す通りになる。この合計のデータ量は、STN＿tableで許可されたストリームに属するTSパケットの合計量となる。ワーストケースにおいては、合計の転送量が96Mbit近くになり、このデータ量のTSパケットが供給されると考えられる。グラフの時間軸を、７つのWindowに分割して、個々のWindowにおける供給量と、Window毎の転送許容量とを対比する。
【００７９】
図２２の第3段目は、この図２２の第2段目におけるグラフを1秒という期間で区切ったものであり、図２３（ａ）（ｂ）は、各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。Windowにおける転送許容量は、1秒当たり48Mbitであり、0.5秒に換算すれば96Mbitとなる。図中のパターンpn1のハッチングは、デコーダへのデータ供給量を示す。図中のパターンpn2のハッチングは、Window毎の転送許容量を示す。パターンpn1のハッチングが付された部分の面積が、何れのWindowにおいても、パターンpn2のハッチングが付された部分の面積以下になっている。これは、BD-ROM及びローカルストレージからのデータ供給量が、どのWindowにおいても、Windowにおける転送許容量以下に抑えられていることを意味する。
【００８０】
ATC時間軸上のどの時点においても、1秒当たりのデコーダへの転送許容量は、48Mbit以下になるので、たとえ局所的に、デコーダへの転送許容量が96Mbit近くになったとしても、48Mbit＝96Mbit×0.5秒の計算により、かかる96Mbitでの転送が0.5秒継続することはありえない。従ってデコーダが、このピークが到来する前に、BD-ROM、ローカルストレージからデコーダへの先読みを行えば、デコーダ内バッファのアンダーフロー又はオーバーフローが生じることはない。
【００８１】
Windowにおける転送許容量、つまり、1秒当たり48Mbitという数値は、MPEGに準拠したデコーダが、バッファに先読みできる数値を、目安にして定めたものである。バッファに先読みできるデータ量が、もっと大きい場合は、1秒当たりのデータ量を更に大きくしたり、またWindowの時間長を更に長くすることができる。このことから、本発明にかかる数値範囲は、1秒当たり48Mbitというものに、限定されるべきでない。
【００８２】
以上が、STN＿tableにおいて再生が許可されているセカンダリTSにおけるデータ量制限についての説明である。
＜connection＿condition情報、sp＿connection＿condition情報の設定＞
次に、Out＿of＿MUXアプリケーションを実現する場合の、PlayItemにおけるconnection＿condition情報、及び、SubPlayItemにおけるsp＿connection＿condition情報の設定について説明する。connection＿condition情報のフィールドの値、sp＿connection＿condition情報のフィールドの値は“1”,“5”,“6”の値を取る事ができ、それぞれ以下のような意味を持つ。
【００８３】
connection＿condition=1(CC=1)：  このPlayItem(カレントPlayItem)と直前のPlayItem(previousPlayItem)とはシームレス接続される保証がない。つまり、フリーズして再生が途切れることが許容された接続形態（ノンシームレス接続）である。
connection＿condition=5(CC=5)：  カレントPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームと、previousPlayItem側のMainClipに多重化されているビデオストリーム、PGストリーム、IGストリームとがシームレス接続される保証がある。一方、MainClipに多重化されているオーディオストリームについてはこの限りではない。
【００８４】
connection＿condition=6(CC=6)：  カレントPlayItemとpreviousPlayItemに属するそれぞれのTSストリームは論理的に連続であり（時間軸が連続しており、符号化方式も連続している）、オーディオストリーム、ビデオストリームともにシームレス接続される保証がある。
SubPlayItem＃n内に記述されたsp＿connection＿condition情報は、次のように定義ができる。
【００８５】
sp＿connection＿condition情報(SP＿CC=1)：  このSubPlayItem(カレントSubPlayItem)と直前のSubPlayItem(previousSubPlayItem)とはシームレス接続される保証がない
sp＿connection＿condition情報(SP＿CC=5)：カレントSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームと、previousSubPlayItem側のSubClipに多重化されているPGストリーム、IGストリームとがシームレス接続される保証がある。一方、SubClipに多重化されているオーディオストリームについてはこの限りではない。
【００８６】
sp＿connection＿condition情報(SP＿CC=6)：  カレントSubPlayItemと、previousSubPlayItemとに属するそれぞれのTSストリームは論理的に連続しており（時間軸が連続しており、符号化方式も連続している）、シームレス接続される保証がある。
Out＿of＿MUXアプリケーションを実現するPlayItemに対して設定されるべきSubPlayItemは、SubPlayItem内のビデオストリームやオーディオストリーム、またはPGストリームやIGストリームがPlayItem内にあったとしても不整合を起こさないようにすべきである。そのため、全く同一の接続条件となる。つまりPlayItem＃１、PlayItem＃２がCC=１で接続されるならば、それに対応するSubPlayItem＃１、SubPlayItem＃２もCC=１で接続される。同様に、PlayItem＃１、PlayItem＃２がCC=５で接続されるならば、それに対応するSubPlayItem＃１、SubPlayItem＃２もCC=５の条件を満たしながら接続される。
以下、図２４、図２５、図２６を参照しながら、Out＿of＿MUXアプリケーションを構成するPlayItem、SubPlayItemのIn＿Time、Out＿Timeの関係と、connection＿condition情報の詳細について説明する。
【００８７】
＜In＿Time、Out＿Timeの関係＞
図２４は、Out＿of＿MUXを構成するPlayItem、SubPlayItemの接続状態を示す図である。本図における第1段目は、SubClip時間軸であり、第2段目、第3段目は、SubPlayItem時間軸、PlayList時間軸である。第4段目は、MainClip時間軸である。本図において、PlayItem側のconnection＿condition情報が“＝5”である場合、SubPlayItem側のconnection＿condition情報も、SP＿CC＝5になる。
【００８８】
図２５は、図２４に示した、PlayItemのconnection＿condition情報、SubPlayItemのsp＿connection＿condition情報が“＝5”に設定されている場合の、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとの関係を示す図である。第1段目、第4段目は図２４と同じである。図２４に示した2つのPlayItem(PlayItem情報＃1、PlayItem情報＃2)のうち、PlayItem情報＃1のIn＿Timeは、時刻t1を表し、Out＿Timeは、時刻t2を表す。PlayItem情報＃2のIn＿Timeは時刻t3、PlayItem情報＃2のOut＿Timeは、時刻t4を表す。
【００８９】
PlayItem側の接続状態がCC＝5に設定されていると、SubPlayItemにおけるSync＿Start＿Pts＿of＿PlayItemは、PlayItemのIn＿Timeと同じ時点を示す。そしてSubPlayItemにおけるIn＿Time、Out＿Timeは、PlayItemのIn＿Time、Out＿Timeと同じ時刻を表す。このように、PlayItemのconnection＿condition情報が“＝5”である場合、SubPlayItemのsp＿connection＿condition情報も“＝5”に設定され、尚且つ、PlayItemのIn＿Time、Out＿Timeは、SubPlayItemのIn＿Time、Out＿Timeと同一時点を表す。
【００９０】
PlayItemのIn＿Time、Out＿Time、SubPlayItemのIn＿Time、Out＿Timeは、それぞれVideo PresentationUnit、Audio Presentation UnitのPTSを参照している。PlayItemのIn＿Time、Out＿Timeと、SubPlayItemのIn＿Time、Out＿Timeとが一致しているということは、PlayItemのIn＿Time、Out＿Timeで参照されるVideoPresentation Unit、Audio Presentation UnitのPTS値が、SubPlayItemのIn＿Time、Out＿Timeで参照されるVideoPresentation Unit、Audio Presentation UnitのPTS値と同じであることを意味する。そうすると、プライマリTS、セカンダリTSは、時間長が同じで、オーサリング時においてVideoPresentation Unit、Audio Presentation UnitのPTSが、同じになるよう、エンコードされる必要がある。このようにプライマリTS、セカンダリTSを作成しておくことも、CC＝5、SP＿CC=5を実現するにあたっての条件になる。
【００９１】
＜同期再生するにあたって、参照すべきSTC値＞
図２６は、PlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値を示す。第2段目、第3段目は、前図に示したものと同じである。第1段目は、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第4段目も、PlayItemのIn＿TimeからOut＿Timeまでに存在する部分を再生する場合に、参照されるべきSTC値をグラフ形式で示している。第1段目における横軸は時間軸であり、縦軸は時間軸上の各時点におけるSTC値を表す。第1段目におけるSTC値は、SubPlayItem情報＃1のIn＿TimeからOut＿Timeまでの期間における単調増加zk1と、SubPlayItem情報＃2のIn＿TimeからOut＿Timeまでの期間における単調増加zk2とからなる。第4段目におけるSTC値は、PlayItem情報＃1のIn＿TimeからOut＿Timeまでの期間における単調増加zk3と、PlayItem情報＃2のIn＿TimeからOut＿Timeまでの期間における単調増加zk4とからなる。
【００９２】
PlayItemのIn＿Timeは、SubPlayItemのIn＿Timeと同じ時点を表すので、上述したグラフにおいて、STCの初期値は同じであり、途中の時点においても同じなる。つまり、PlayItemのIn＿TimeからOut＿Timeまでに存在する任意の時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC2(i)は、SubPlayItemのIn＿TimeからOut＿Timeまでに存在する同じ時点iのSourceパケットをデコーダに供給する際、参照すべきSTC値であるSTC1(i)と同じになる。STC値が同じであると、装置内のSTCカウンタは、同一のクロック値を生成して、多重分離部に供給すればよいので、再生装置における制御が簡略化される。
【００９３】
仮に、上述した図２５、図２６の制限に反し、１つのPlayItemに対して2つ以上のSubPlayItemを準備した場合、そのSubPlayItemの境界において、映像や音声が途切れてしまい、PlayItemの途中で再生が一時停止するなどの不便が生じる。また、Out-of-MUXアプリケーションにおいて、プライマリTSをセカンダリTSに入れ換えるという処理を実現する場合、この入れ替えの前後で、STC時間軸を切り替える必要があるので、再生装置における同期制御が複雑化する。一方、PlayItem、もしくはSubPlayItemのIn＿Time、Out＿Timeを共に、一連続なSTC時間軸に定義した場合、上述したような途切れやトランスポートストリーム入れ替えの不都合を避けることができる。こうした事情から、１つのPlayItemに対して同一の開始点、同一の終了点をSubPlayItemにもたせるのである。
【００９４】
＜In＿Time、Out＿Timeの誤差＞
ここでPlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとの一致は、完全に一致していることを要求するのではなく、多少の誤差を許容する趣旨である。このIn＿Time、Out＿Time間の誤差について説明する。
PlayItemのIn＿Time、Out＿TimeとなるSTC時刻は、PlayItemがビデオフレームに対して設定される。これに対し、SubPlayItemではオーディオフレームに対して設定されることとなる。何故なら、SubPlayItemは、コメンタリが主用途でビデオストリームが多重化されないことが多いからである。この場合、厳密にはそれぞれのプレゼンテーションユニットの再生時間長の違いから、開始/終了時刻が合わない。したがって、最低でも、1フレーム未満の誤差を認める必要がある。PlayItem＃nとSubPlayItem＃nの開始/終了時刻に関して、どちらも同一のSTC時間軸に対して、
| (PlayItem＃n.Out-PlayItem＃n.In) - (SubPlayItem＃n.Out＿time-SubPlayItem＃n.In＿time)| ≦ PlayItem＃nの中で最小の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間 ≦ 1/60秒
としても規定する。上記左辺の値は、PlayItem＃nの中で最大の再生時間を持つビデオの１プログレッシブフレームもしくは２インターレースフィールドの再生時間（≦1/25秒）としても良いし、１秒以下などとしても良い。
以上が、PlayItem、SubPlayItemにおけるIn＿Time、Out＿Timeの関係についての説明である。
【００９５】
次に、connection＿condition情報、sp＿connection＿condition情報について詳しく説明する。CC＝5、SP＿CC=5の条件を満たすには、AVストリームのレベル、トランスポートストリームのレベル、VideoPresentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおいて、以下に述べる条件を満たす必要がある。
＜AVストリームのレベル＞
Current PlayItemのconnection＿condition情報、及び、sp＿connection＿condition情報が“5”に設定されていることは、PreviousPlayItemで再生されるAVストリームの終了点と、Current PlayItemで再生されるAVストリームの開始点との間に、“Clean Break”が存在することを意味する。
【００９６】
Clean Breakを実現するには、Previous PlayItemで再生されるAVClipと、Current PlayItemで再生されるAVストリームとが、以下の要件を満たさねばならない。
(1)Previous PlayItemで指定されているMainClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccessUnitが、Previous PlayItemのOut＿Time以降から排除されていること。
【００９７】
同様に、Previous SubPlayItemで指定されているSubClipの終了点に、不必要なAccess Unitが存在せず、PTSを有する不要なAccessUnitが、Previous SubPlayItemのOut＿Time以降から排除されていること。
(2)Current PlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、CurrentPlayItemのIn＿Timeの前から取り除かれていること。そして、MainClipの最初のAudio Presentation Unitが、STC時間軸のIn＿Timeで再生されるSampleを含んでいること。
【００９８】
同様に、Current SubPlayItemにて指定されるAVストリームの開始点において、PTSをもつ不要なAccess Unitが、CurrentSubPlayItemのIn＿Timeの前から取り除かれていること。そして、SubClipの最初のAudio Presentation Unitが、STC時間軸のIn＿Timeで再生されるSampleを含んでいること。
(3)Previous PlayItemにて指定されるMainClipを構成する全てのSourceパケットが、Current PlayItemにて指定されるMainClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
【００９９】
同様に、Previous SubPlayItemにて指定されるSubClipの全データが、Current SubPlayItemにて指定されるSubClipの先頭パケットが送り込まれる前に、デコーダシステムに取り込まれるように、多重化されること。
以上が、AVストリームにおいて満たすべき条件についての説明である。続いて、トランスポートストリームのレベルにおいて満たすべき条件について説明する。
＜トランスポートストリームのレベル＞
ここでCC＝5においてシームレス接続の対象となる2つのプライマリTSを、プライマリTS1、プライマリTS2と呼ぶ。SP＿CC=5においてシームレス接続の対象となる2つのプライマリTSを、セカンダリTS１、セカンダリTS２と呼ぶ。
【０１００】
図２７は、previousPlayItem、previousSubPlayItemにて参照されているAVClip、カレントPlayItem、カレントSubPlayItemにて参照されているAVClipにおいて、TS1、TS2がどのように特定されるかを示す図である。本図における第4段目は、プライマリTS1、プライマリTS2を示し、第3段目は、previousPlayItem側のMainClip1、カレントPlayItem側のMainClip2を示す。第1段目は、セカンダリTS１、セカンダリTS２を示し、第2段目は、previousSubPlayItem側のSubClip1、カレントSubPlayItem側のSubClip2を示す。
【０１０１】
プライマリTS１は、MainClip1において、ハッチングが付されたデータから構成される。MainClip1におけるハッチングが付されたデータは、PreviousPlayItemにおけるIn＿Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In＿Timeが参照しているVideoPresentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、MainClip1の最後のパケットで終わる。
【０１０２】
プライマリTS２は、MainClip2においてハッチングが付されたデータから構成される。MainClip2においてハッチングが付されたデータは、MainClip2の最初のSourceパケットから始まる。そしてMainClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、CurrentPlayItemのOut＿Timeで参照されるVideo Presentation Unit,Audio Presentation Unitの末尾に位置するSourceパケットである。
【０１０３】
セカンダリTS１は、SubClip1において、ハッチングが付されたデータから構成される。SubClip1におけるハッチングが付されたデータは、previousSubPlayItemにおけるIn＿Timeに対するデコードを開始することができるSourceパケットから始まる。かかるSourceパケットは、In＿Timeが参照しているVideoPresentation Unit及びAudio Presentation Unit先頭に位置するものである。そしてハッチングが付されたデータは、SubClip1の最後のパケットで終わる。
【０１０４】
セカンダリTS２は、SubClip2においてハッチングが付されたデータから構成される。SubClip2においてハッチングが付されたデータは、SubClip2の最初のSourceパケットから始まる。そしてSubClipにおいてハッチングが付されたデータは、カレントPlayItemに対するデコードを終了するSourceパケットで終わる。かかるSourceパケットは、カレントSubPlayItemのOut＿Timeで参照されるVideoPresentation Unit,Audio Presentation Unitの末尾に位置するSourceパケットである。
【０１０５】
以上の説明から、CC＝5、SP＿CC=5において、接続すべき2つのトランスポートストリームが、MainClip、SubClip内に、どのように配置されるかがわかる。previousPlayItem側のMainClipは、previousPlayItemのOut＿Timeで参照されるVideoPresentation Unit、Audio Presentation Unitで終わっていなければならず、カレントPlayItem側のMainClipも、カレントPlayItemのIn＿Timeで参照されるVideoPresentation Unit、Audio Presentation Unitで始まらなければならない。この関係は、previousSubPlayItemの同様であり、previousSubPlayItem側のSubClipは、previousSubPlayItemのOut＿Timeで参照されるAudioPresentation Unitで終わっていなければならず、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのIn＿Timeで参照されるAudioPresentation Unitで始まらなければならない。これは上述したように、previousSubPlayItemのOut＿Timeから参照されるVideoPresentation Unit、Audio Presentation Unit以降に、余分なAudio Presentation Unitは存在してはならないからである。一方、previousSubPlayItem側のSubClipは、previousSubPlayItemのIn＿Timeで参照されるAudioPresentation Unitで始まる必要はなく、カレントSubPlayItem側のSubClipも、カレントSubPlayItemのOut＿Timeで参照されるAudioPresentation Unitで終わる必要はない。
【０１０６】
以上の図２４、図２７から、プライマリTS、セカンダリTSは、同じ時間長に構成され、Video Presentation Unit、AudioPresentation UnitのPTS値が同一値になるように作成されねばならない。更にpreviousPlayItem側のMainClip、previousPlayItem側のSubClipは、Out＿TimeにあたるVideoPresentation Unit、Audio Presentation Unitで終わるよう、多重化されねばならず、カレントPlayItem側のMainClip、カレントPlayItem側のSubClipは、In＿TimeにあたるVideoPresentation Unit、Audio Presentation Unitで開始するよう、多重化されねばならない。
【０１０７】
そして、これらトランスポートストリームは、以下の条件を満たす必要がある。
・TS1とTS2におけるプログラム数が1つであること
・ビデオストリームの数が1つであること
・オーディオストリーム数が同じであること
・Previous PlayItemにおけるSTN＿tableと、Current PlayItemにおけるSTN＿tableとは同じ内容になること
・個々のPlayItemにおけるトランスポートストリームの再生期間は3秒
以上が、CC＝5、SP＿CC=5で2つのストリームを接続するにあたってトランスポートストリームのレベルで満たすべき条件である。続いて、VideoPresentation Unit、Audio Presentation Unitのレベルで満たすべき条件について説明する。
＜Video Presentation Unit、Audio Presentation Unitのレベル＞
CC＝5とは、本来、別々である筈のプライマリTS1たるビデオストリームの最後のVideo Presentation Unitの開始時刻と、プライマリTS2たるビデオストリームの最初のVideoPresentation Unitの終了時刻とを一致させることをいう。Video Presentation Unitの終了時刻・開始時刻を一致させようとすると、かかるVideoPresentation Unitと同期再生すべきAudio Presentation Unitの扱いが問題になる。何故なら、ビデオと、オーディオとではサンプリング周波数が異なり、VideoPresentation Unit、Audio Presentation Unitの時間長は一致しないからである。
【０１０８】
図２８は、CC＝5、及び、SP＿CC＝5の詳細を示す図である。第1段目〜第3段目は、SubPlayItemにおけるconnection＿conditionを示し、第4段目〜第7段目は、PlayItemにおけるsp＿connection＿conditionを示す。第4段目は、TS1、TS2における複数のVideoPresentation Unitを示し、第5段目は、TS1におけるAudio Presentation Unit、TS2におけるAudioPresentation Unitを示す。第6段目は、MainClipにおけるSTCの値を示す。第7段目は、MainClipにおけSourceパケット列を示す。
【０１０９】
本図において、ハッチングが付されているのは、TS1側のVideo Presentation Unit、Audio Presentation Unit、Sourceパケットであり、ハッチングが付されていないのは、TS2側のVideoPresentation Unit、Audio Presentation Unit、Sourceパケットである。
本図においてCC＝5とは、Video Presentation Unit境界を一致させるものの(第4段目)、MainClipのATCにおいてギャップがあり(第7段目)、MainClipのAudioPresentation Unitでオーバラップが存在する(第5段目)状態をいう。SP＿CC=5とは、SubClipのATCにおいてギャップがあり(第1段目)、SubClipのAudioPresentation Unitでオーバラップが存在する(第2段目)状態をいう。
【０１１０】
上述したVideo Presentation Unitの境界とは、TS1側から見ればと、第4段目における最後のVideo Presentation Unitの終了点PTS1(1stEnd)+Tppにあたり、TS2側から見れば、第4段目におけるVideoPresentation Unitの開始点PTS2(2ndSTART)にあたる。
TS1のうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5a、TS2のうち、時点T4に一致するAudioPresentation Unitの開始点をT3aとした場合、MainClipにおけるオーバラップは、Audio Presentation UnitはT3aからT5aにまでとなる。
【０１１１】
また本図において、SubClipのAudio Presentation Unitは、MainClipのAudio Presentation Unitより長くなっている。これは、SubClipにおけるオーディオストリームはネットワークを通じて、供給される都合上、サンプリング周波数は低く設定されており、そのためAudioPresentation Unit1つ当たりの時間長が長くなるからである。この第1段目におけるSourceパケット列においても、第7段目同様のギャップが存在し、第2段目におけるAudioPresentation Unitにおいても、第4段目と同様のオーバーラップが存在している。SubClipのTS1におけるAudio PresentationUnitのうち、境界時点T4に一致するAudio Presentation Unitの終了点をT5b、SubClipのTS2におけるAudioPresentation Unitのうち、時点T4に一致するAudio Presentation Unitの開始点をT3bとした場合、オーバラップはT3bからT5bまでとなる。
【０１１２】
この図から、CC＝5、SP＿CC=5を実現するには、Video Presentation Unit、Audio Presentation Unit、パケットのレベルにおいて、以下の４つの条件を満たさねばならないことがわかる。
(1)TS1におけるオーディオストリームの最後のAudio Presentation Unitは、previousPlayItem、previousSubPlayItemにて指定されるTS1における最後のビデオのピクチャの表示期間の終期に等しい再生時刻をもつサンプルを含む。
【０１１３】
(2)TS2におけるオーディオストリームの、最初のAudio Presentation Unitは、カレントPlayItem、カレントSubPlayItemにて指定されるTS2の最初のピクチャの表示期間の先頭と等しい再生時刻をもつサンプルを含む。
(3)接続点のAudio Presentation Unit列において、ギャップが存在しない。これは接続点において、Audio PresentationUnit列のオーバーラップが発生してもよいことを意味する。しかしかかるオーバーラップは、2つのオーディオフレーム再生期間より短い大きさでなければならない。
【０１１４】
(4)TS2の最初のパケットは、PATを含み、1つ以上のPMTがその直後に後続してもよい。PMTがTSパケットのペイロードより大きければ、PMTは、2パケット以上になることもある。PMTを格納したTSパケットには、PCRやSITが存在してもよい。
＜In＿Time、Out＿TimeとVideo Presentation Unitとの関係＞
図２９は、previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudioPresentation Unitと、STC時間軸との関係を示す図である。第1段目は、previousPlayItemが参照しているTS1に帰属する複数のVideoPresentation Unitと、カレントPlayItemが参照しているTS2に帰属する複数のVideo Presentation Unitとを示し、第2段目はpreviousSubPlayItemが参照しているタイムスタンプに帰属している複数のAudioPresentation Unitと、カレントSubPlayItemが参照しているTS2に帰属する複数のAudio Presentation Unitとを示す。第3段目は、previousSubPlayItemのTS1におけるSTC時間軸と、カレントSubPlayItemのTS2におけるSTC時間軸とを示す。第2段目に示すTS1におけるAudioPresentation Unit、TS2におけるAudio Presentation Unitのうち、TS2に属するAudio PresentationUnitの開始点T3bから、TS2に該当するAudio Presentation Unitの終了時刻T5bまでがオーバラップになるのは、図２８に示した通りである。そしてカレントSubPlayItemのIn＿Time、previousSubPlayItemのOut＿Timeは、それぞれ、VideoPresentation Unitの境界である時点T4を指定している。カレントPlayItemのIn＿Time、SubPlayItemのOut＿Timeもまた、VideoPresentation Unitの境界である時点T4を指定しているので、PlayItemのIn＿Time、Out＿Timeは、SubPlayItemのIn＿Time、Out＿Timeと一致していることになる。このようにpreviousSubPlayItemのIn＿Time、カレントSubPlayItemのOut＿Timeは、BD-ROMとは異なる記録媒体に記録されているにも拘らず、MainClipにおけるVideoPresentation Unitの境界と一致しており、更にまた、previousPlayItemのOut＿Time、カレントPlayItemのIn＿Timeと一致していることがわかる。
【０１１５】
以上がVideo Presentation Unit、Audio Presentation Unitレベルの条件についての詳細である。
＜エレメンタリストリームのレベル＞
次に、CC＝5、SP＿CC=5実現のための、エレメンタリストリームレベルでの符号化条件について説明する。
【０１１６】
個々のエレメンタリストリームのレベルでは、以下の符号化条件を満たす必要がある。
(1)ビデオストリーム
・シームレス接続の前後で、ビデオの解像度やフレームレートが変わらないこと、
・シームレス接続の直前のビデオストリームは、sequence＿end＿code(MPEG-2 Video時)、end＿of＿sequence＿rbsp(MPEG-4AVC時)で完了すること、
(2)オーディオストリーム
・同一のPIDをもつオーディオストリームの符号化方式が変わらないこと、
サンプリング周波数や量子化ビット数、チャンネル数などが変わらないこと、
(3)PGストリーム
a)TS1及びTS2におけるPGストリームの数が同一である。
【０１１７】
b)TS1におけるPGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c)TS1における最後のPCSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut＿Timeにあたる再生時刻より早い時点を示す。
d)TS2のPGストリームは、Epoch Start,Epoch ContinueタイプのDisplay Setから始まらねばならない。
【０１１８】
e)TS2における最初のPCSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn＿Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f)TS2からのSourceパケットが続く、TS1からのSourceパケットの取り出しは、同じシステム時間軸の、STC1、STC2として定義することができ、これらのDTS値/PTS値には重複が存在しない。
(4)IGストリーム
a)TS1及びTS2におけるIGストリームの数が同一である。
【０１１９】
b)TS1におけるIGストリームは、End of Display Setと呼ばれる機能セグメントで終了していること
c)TS1における最後のICSを運ぶPESパケットのPTSは、previousPlayItem、previousSubPlayItemのOut＿Timeにあたる再生時刻より早い時点を示す。
d)TS2のIGストリームは、Epoch Start,Epoch ContinueタイプのDisplay Setから始まらねばならない。
【０１２０】
e)TS2における最初のICSを運ぶPESパケットのPTSは、カレントPlayItem、カレントSubPlayItemのIn＿Timeにあたる再生時刻と等しいか、より遅い時点を示す。
f)TS2からのSourceパケットが続く、TS1からのSourceパケットの取り出しは、同じシステム時間軸の、STC1、STC2として定義することができ、これらのDTS値/PTS値には重複が存在しない。
previousPlayItemと、カレントPlayItemとをCC＝5で接続し、previousSubPlayItemと、カレントSubPlayItemとをSP＿CC=5で接続するには、以上のAVストリームのレベル、トランスポートストリームのレベル、VideoPresentation Unit及びAudio Presentation Unitのレベル、エレメンタリストリームのレベルの全てにおける、条件を満たさねばならない。
【０１２１】
以上がローカルストレージ２００の構成たるPlayList情報についての説明である。
以上で本発明にかかる記録媒体についての説明を終える。続いて本発明に係る再生装置について説明する。
図３０は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１a、リードバッファ１b,c、ATCカウンタ２a,c,SourceDepacketizer２b,d、ATCカウンタ２c,d、STCカウンタ３a,c、PID Filter３b,d、ビデオデコーダ４、TransportBuffer(TB)４a、Multiplexed Buffer(MB)４b、Coded Picture Buffer(CPB)４c、ビデオデコーダ４d、Re-orderBuffer４e、スィッチ４f、ビデオプレーン５、オーディオデコーダ９、Transport Buffer６、Elementary Buffer７、デコーダ８、スイッチ１０a,b,c,d、InteractiveGraphicsデコーダ１１、Transport Buffer(TB)１１a、Coded Data Buffer(CDB)１１b、StreamGraphics Processor(SGP)１１c、Object Buffer１１d、Composition Buffer１１e、GraphicsController１１f、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、TransportBuffer(TB)１３a、Coded Data Buffer(CDB)１３b、Stream Graphics Processor(SGP)１３c、ObjectBuffer１３d、Composition Buffer１３e、Graphics Controller１３f、Presentation Graphicsプレーン１４、Transport Buffer１５a、Elementary Buffer１５b、デコーダ１５c、Transport Buffer１６a、ElementaryBuffer１６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に応じてデコーダへの入力時刻を調整する。具体的には、ATCCounter２aが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS＿Recording＿Rateで、そのTSパケットだけをPIDFilter３bに転送する。
【０１２４】
ATC Counter２cは、セカンダリTSを構成するSourceパケットのうち、再生区間の最初に位置するもののATSを用いてリセットされ、以降ソースデパケッタイザ２dにATCを出力してゆく。
ソースデパケッタイザ(Source  De-packetizer)２dは、セカンダリTSを構成するSourceパケットからTSパケットを取り出して、送出する。この送出にあたって、ATSに応じてデコーダへの入力時刻を調整する。具体的には、ATCCounter２cが生成するATCの値と、SourceパケットのATS値とが同一になった瞬間にTS＿Recording＿Rateで、そのTSパケットだけをPIDFilter３dに転送する。
【０１２５】
STC Counter３aは、プライマリTSのPCRによってリセットされ、STCを出力する。
PID Filter３bは、MainClip用の多重分離部であり、ソースデパケッタイザ２bから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々ビデオデコーダ４、オーディオデコーダ９、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。各デコーダは、PID Filter３bを経由したエレメンタリストリームを受け取って、プライマリTSのPCR（STC１時間軸）に従いデコードから再生の処理を行う。このようにPIDFilter３bを通過して各デコーダに入力されるエレメンタリストリームは、プライマリTSのPCRに従って、デコード及び再生に供されることになる。
【０１２６】
STC Counter３cは、セカンダリTSのPCRによってリセットされ、STCを出力する。PIDフィルタ３dは、このSTCを参照して、多重分離を行う。  
PID Filter３dは、SubClip用の多重分離部であり、ソースデパケッタイザ２dから出力されたSourceパケットのうち、PID変換部２４から通知されたPID参照値をもつものを、夫々オーディオデコーダ９、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３に出力する。このようにPID Filter３dを通過して各デコーダに入力されるエレメンタリストリームは、セカンダリTSのPCRに従って、デコード及び再生に供されることになる。
【０１２７】
記録媒体の説明で述べたように、PlayItemにおけるIn＿Time、Out＿Timeは、SubPlayItemにおけるIn＿Time、Out＿Timeと一致しているので、ATCCounter２aとATC  Counter２cとが同一の値（時刻）を刻めば、プライマリTSとセカンダリTSの両方の時間軸が揃うことになり、Out-of-MUXアプリケーションを構成するプライマリTS、セカンダリTSを１本のストリームとして扱うことができる。そしてデコーダへの入力時刻を表すATC時間軸と、デコーダ基準時間軸を表すSTC時間軸とを同期させることができる。
【０１２８】
ATC時間軸の同期により、上述した2つのSource  De-packetizerは、それぞれ、BD-ROMからから読み出されたSourceパケット、ローカルストレージからから読み出されたSourceパケットを処理することができる。
STC時間軸の同期により、STC Counter３a,cは、同一の時刻を計時すれば、２つのTSを１つのTSとして処理することができる。再生装置におけるデコーダは、１つのSTC時間軸で動くため、通常のプライマリTSだけの再生時と変わることなく、STC時間の管理を共通化することができる。ビデオデコーダ４、IGデコーダ１１、PGデコーダ１３、システムデコーダ１５c,１６c、オーディオデコーダ９の全てが同一のSTC時間軸で動かせることは、再生装置開発の観点からすると、BD-ROMの再生のみを行う通常の再生装置と、制御が一切変わらないため望ましい制限となる。更にオーサリング時においては、1つのTSの入力タイミングを制御して、バッファ状態を観測すればよいので、オーサリング時の検証も容易になる。
【０１２９】
ビデオデコーダ４は、PID Filter３bから出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込むものであり、TransportBuffer４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は、符号化順序から表示順序へと、ピクチャの順序を入れ替えを実現するスイッチである。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットの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パケットのどちらかを、選択的にInteractiveGraphicsデコーダ１１に供給する。
スイッチ１０cは、BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのどちらかを、選択的にPresentationGraphicsデコーダ１３に供給する。
【０１３６】
Interactive Graphics(IG)デコーダ１１は、BD-ROM１００又はローカルストレージ２００から読み出されたIGストリームをデコードして、非圧縮グラフィクスをIGプレーン１２に書き込むものであり、TransportBuffer(TB)１１a、Coded Data Buffer(CDB)１１b、Stream Graphics Processor(SGP)１１c、ObjectBuffer１１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ストリームをデコードして、非圧縮グラフィクスをPresentationGraphicsプレーン１４に書き込む。PGデコーダ１３は、Transport Buffer(TB)１３a、Coded Data Buffer(CDB)１３b、StreamGraphics Processor(SGP)１３c、Object Buffer(OB)１３d、Composition Buffer(CB)１３e、GraphicsController(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の制御も行なう。この制御にあたってコントローラ２２は、1秒という時間的範囲において、BD-ROM、ローカルストレージ内のSourceパケットを、デコーダ内のバッファに先読みしておく。このような先読みを行うのは、上述したウィンドゥの制限により、アンダーフロー又はオーバーフローが生じないとの保障があるからである。
【０１４６】
PSRセット２３は、再生装置に内蔵されるレジスタであり、64個のPlayer Setting/Status Register(PSR)と、4096個のGeneralPurpose Register（GPR)とからなる。Player Setting/Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
PID変換部２４は、PSRセット２３に格納されているオーディオストリーム、オーディオストリームのストリーム番号を、STN＿Tableに基づき、PID参照値に変換して、変換結果たるPID参照値をPIDFilter３b、PID Filter３dに指示する。
【０１４７】
ネットワーク部２５は、本再生装置における通信機能を実現するものであり、URL指定が与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードを実行する。
操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作を示すUser Operation情報をコントローラ２２に通知する。
【０１４８】
以上が、再生装置の内部構成である。以降、再生装置におけるコントローラ２２の実装について説明する。コントローラ２２は、図３１、図３２に示したフローチャートの処理手順をCPUに実行させるプログラムを作成して命令ROMに書き込み、CPUに供することで再生装置に実装することができる。
図３１は、PlayList情報に基づく再生手順のフローチャートである。本フローチャートは、PlayList情報を構成する.mplsファイルを読み込み(ステップＳ１１)、PlayList情報における先頭のPlayItemをカレントPlayItemにした上で(ステップＳ１２)、このカレントPlayItemに対して、ステップＳ１３〜ステップＳ２５の処理を繰り返すループ構造になっている。このループ構造は、ステップＳ２３を終了条件としたものであり、カレントPlayItemのIn＿Timeに対応するAccessUnitから、カレントPlayItemのOut＿Timeに対応するAccess Unitまでを読み出しをBD-ROMドライブに命じ(ステップＳ１３)、カレントPlayItemにpreviousPlayItemが存在するか否かを判定して(ステップＳ１４)、判定結果に応じて、ステップＳ１５の処理、ステップＳ１６〜ステップＳ２１の処理を選択的に実行する。具体的には、カレントPlayItemにpreviousPlayItemがなければ(ステップＳ１４でNo)、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ１５)。
【０１４９】
カレントPlayItemにpreviousPlayItemがあれば(ステップＳ１４でYes)、カレントPlayItemがCC＝5であるか否かを判定し(ステップＳ１６)、CC＝5であるなら(ステップＳ１６でYes)、ステップＳ１７〜ステップＳ２０の処理を行う。
上述したpreviousPlayItemが存在する場合、プライマリTSにおけるATC＿Sequenceが切り替わることになる。この切替において、ATC＿delta1と呼ばれるプライマリTSのためのオフセット値を算出し(ステップＳ１７)、それまでのATC＿SequenceにおけるATC値(ATC1)に、ATC＿delta1を加算することにより、新しいATC＿SequenceのATC値(ATC2)を得る(ステップＳ１８)。
【０１５０】
また、上述した、previousPlayItemが存在する場合、プライマリTSにおけるSTC＿Sequenceが切り替わることになる。この切り替えにおいて、STC＿delta1と呼ばれるオフセット値を求めて(ステップＳ１９)、それまでのSTC＿SequenceにおけるSTC値(STC1)に、STC＿delta1を加算することにより(ステップＳ２０)、新しいSTC＿SequenceのSTC値(STC2)を求める。
【０１５１】
そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ２１）。カレントPlayItemがCC＝5でないなら、CC=1、CC=6の処理を行う。
ステップＳ１５、ステップＳ１６〜ステップＳ２１のどちらかの処理を実行すればステップＳ２５の処理を実行する。ステップＳ２５は、カレントPlayItemと同期再生すべきSubPlayItemが存在するかどうかをサーチする処理である。ここでSubPath情報を構成する各SubPlayItemは、Sync＿PlayItem＿Idという情報を有しており、カレントPlayItemと同期再生すべきSubPlayItemは、このSync＿PlayItem＿Idが、カレントPlayItemに設定されている。そこでステップＳ２５では、カレントPlayItemをSync＿PlayItem＿Idに指定したSubPlayItemが、SubPath情報を構成する複数のSubPlayItemの中に存在するかどうかをサーチする。
【０１５２】
もし存在しない場合、ステップＳ２２に移行する。ステップＳ２２は、AVClip時間軸における現在の再生時点(カレントPTM(PresentationTiMe))がカレントPlayItemのOut＿Timeに到達したかどうかを判定する(ステップＳ２２) 。到達すれば、ステップＳ２３に移行する。ステップＳ２３は、カレントPlayItemがPlayList情報における最後のPlayItemになったか否かの判定であり、最後のPlayItemでなければ、PlayList情報における次のPlayItemを、カレントPlayItemにして(ステップＳ２４）、ステップＳ１３に移行する。以上の処理により、PlayList情報における全てのPlayItemに対して、ステップＳ１３〜ステップＳ２４の処理が施されることになる。
【０１５３】
図３２は、SubPlayItemにおけるシームレス接続を示すフローチャートである。
ステップＳ２５においてカレントPlayItemをSync＿PlayItem＿Idに指定したSubPlayItemが存在すると判定された場合、そのSubPlayItemをカレントSubPlayItemに設定して(ステップＳ３１)、SubPlayItemのIn＿Timeに相当するAccessUnitから、Out＿Timeに相当するAccess Unitまでの読み出しをローカルストレージ２００に命じる(ステップＳ３２)。そしてカレントPlayItemにPreviousSubPlayItemが存在するか否かを判定して(ステップＳ３３)、判定結果に応じて、ステップＳ３４、ステップＳ３５の処理、ステップＳ３６〜ステップＳ４１の処理を選択的に実行する。具体的には、カレントPlayItemにPreviousSubPlayItemがなければ(ステップＳ３３でNo)、カレントPTMが、Sync＿Start＿Pts＿of＿PlayItemに到達するのを待ち(ステップＳ３４)、到達すれば、SubPlayItem＿In＿TimeからSubPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ３５)。
【０１５４】
カレントPlayItemにPrevious SubPlayItemがあれば(ステップＳ３３でYes)、カレントPlayItemがSP＿CC=5であるか否かを判定し(ステップＳ３６)、SP＿CC=5であるなら(ステップＳ３６でYes)、ステップＳ３７〜ステップＳ４１の処理を行う。
上述した、previousPlayItemが存在する場合、ATC＿Sequenceが切り替わることになる。この切替において、ATC＿delta2と呼ばれるセカンダリTSのためのオフセット値を算出し(ステップＳ３７)、それまでのATC＿SequenceにおけるATC値(ATC1)に、ATC＿delta2を加算することにより、新しいATC＿SequenceのATC値(ATC2)を得る(ステップＳ３８)。
【０１５５】
ATC＿deltaとは、これまで読み出されているトランスポートストリーム(TS1)の最後のTSパケットの入力時点T1から、新たに読み出されたトランスポートストリーム(TS2)の最初のTSパケットの入力時点T2までのオフセット値をいい、“ATC＿delta≧N1/TS＿recording＿rate”という計算式で与えられる。ここでN1は、TS1の最後のビデオPESパケットに後続する、TSパケットのパケット数である。
【０１５６】
また、上述した、previousPlayItemが存在する場合、STC＿Sequenceも切り替わることになる。この切り替えにおいて、STC＿delta2を求めて(ステップＳ３９)、それまでのSTC＿SequenceにおけるSTC値(STC1)に、STC＿delta2を加算することにより(ステップＳ４０)、新しいSTC＿SequenceのSTC値(STC2)を求める。
先行STC＿Sequenceにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STC＿Sequenceにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、CC＝5では、PTS1(1stEND)＋Tppの時刻と、PTS2(2ndSTART)の時刻とを一致させる必要があるから、STC＿delta2は、
STC＿delta2＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)
との計算式から算出される。
そしてAudio Overrapのミュートをオーディオデコーダ９に指示した上で、PlayItem＿In＿TimeからPlayItem＿Out＿Timeまでの再生をデコーダに命じる(ステップＳ４１）。
【０１５７】
コントローラ２２は、上述したように、STCの変更処理を行うが、再生装置の一般的な実装において、この変更処理は、デコーダがフリーラン状態にある場合になされる。フリーラン状態とは、デコーダがSTCとの同期制御を行っていない状態をいう。その後、STC時間軸が設定できる状態まで、STCが復帰すれば、デコーダは、フリーラン状態から、STCとの同期制御へと移行する。一方、ステップＳ３６においてカレントPlayItemがCC＝5でないと判定されたなら(ステップＳ３６でNo)、CC=1、CC=6の処理を行う。
【０１５８】
以上のように本実施形態によれば、Windowと呼ばれる1秒当たりの転送許容量は、48Mbit以下に制限されているので、この1秒という期間において、転送許容量が局所的に96Mbitまであがったとしても、96Mbit×0.5秒のサイズのTSパケットを、デコーダに先読みしておけば、デコーダ内のバッファがアンダーフロー又はオーバーフローすることはない。デジタルストリームにおけるどの期間であっても、データ量は「96Mbit×0.5秒」以下であり、アンダーフロー又はオーバーフローが生じることなく、TSパケットを供給することができるので、ビデオ又はオーディオの欠落を避けることができる。これによりOut-of-MUXフレームワーク実現のための同時読み出しが、品質上の問題に波及する恐れはなくなる。
【０１５９】
また、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとが一致していて、PlayItem側の接続状態がCC＝5であるなら、SubPlayItem側の接続状態もSP＿CC=5になるので、PlayItemが切り替えられたとしても、多重分離部を再設定することなく、PlayItemからPlayItemへの切り替えと、SubPlayItemからSubPlayItemへの切り替えとを同時に実行することができる。多重分離部が参照するSTC時間軸を同期させつつ、PlayList情報に基づく再生処理を進行させてゆくことができる。
【０１６０】
(第２実施形態)
本実施形態では、先の実施形態で述べた、BD-ROMの製作について、詳しく説明する。先の実施形態に係るBD-ROMは、以下の工程を順次実行することにより、作ることができる。  ＜BD-ROMの記録工程＞
先ず初めに、BD-ROMをどのような筋書きで再生させるかを決めるかを企画して(企画工程)、動画収録、音声収録等の素材作成を行い(素材作成工程)、企画工程において作成された筋書きから、ボリューム構成情報を作成する(シナリオ作成工程)。
【０１６１】
ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る(素材エンコード工程)。その後、複数のエレメンタリストリームの多重化を行う(多重化工程)。
【０１６２】
こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、BD-ROMの応用層フォーマットに適合させる作業を行い、BD-ROMのボリューム領域に記録すべきデータの全体像(一般にボリュームデータという)を得る(フォーマッティング工程)。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、BD-ROM規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、Clip情報,PlayList情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のfor文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、if文を用いて定義することができる。
【０１６３】
こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う(エミュレーション工程)。このエミュレーション工程では、BD-ROMプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、BD-ROMを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。
【０１６４】
以上の工程を経て、各実施形態に示した記録媒体(BD-ROM)を作ることができる。
＜追加コンテンツの作成工程＞
映画作品を、BD-ROMコンテンツと、追加コンテンツとで構成する場合は、上述した企画工程からフォーマッティング工程までを実行する。そうして、1つのボリュームデータを構成するAVClip、Clip情報、PlayList情報が得られれば、これらのうち、既にBD-ROMにて供給すべきものを除外し、残ったものを、追加コンテンツとして、アーカイバプログラム等で1つのファイルにまとめる。こうした処理を経て、追加コンテンツが得られれば、かかる追加コンテンツをWWWサーバーに供し、再生装置からの要求に応じて、再生装置に送出する。
【０１６５】
先の実施形態で述べたベリファイは、AVClip、Clip情報、PlayList情報が完成し、PlayList情報内のSTN＿tableにより、再生すべきエレメンタリストリームが確定した段階、つまり、フォーマッティング工程で実行される。以降、かかるアプリケーションフォーマットを作成するオーサリングシステムについて説明する。
＜オーサリングシステム＞
図３３は、第２実施形態にかかるオーサリングシステムの内部構成を示す図である。本図に示すようにオーサリングシステムは、入力装置５１、エンコード装置５２、サーバ装置５３、素材ストレージ５４、BD構成情報ストレージ５５、クライアント装置５６〜５８、マルチプレクサ６０、BDシナリオコンバータ６１、フォーマッタ６２、Verifier６３から構成される。
【０１６６】
入力装置５１は、HD画像、SD画像が収められたビデオカセットを装填し、このビデオカセットを再生して再生信号をエンコード装置５２に出力する。
エンコード装置５２は、入力装置５１から出力された再生信号をエンコードして、ビデオストリーム、オーディオストリームといったエレメンタリストリームを得る。こうして得られたエレメンタリストリームは、LANを通じてサーバ装置５３に出力され、サーバ装置５３内の素材ストレージ５４に書き込まれる。
【０１６７】
サーバ装置５３は、素材ストレージ５４、BD構成情報ストレージ５５という2つのドライブ装置からなる。
素材ストレージ５４は、サーバ装置５３の内蔵ディスク装置であり、エンコード装置５２のエンコードにより得られたエレメンタリストリームを順次格納する。素材ストレージ５４は、HDstreamディレクトリ、SDstreamディレクトリといった2つのディレクトリをもち、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に対するベリファイ手順を示すフローチャートである。本フローチャートは、ステップＳ１において、Sourceパケット列における最初のSourceパケットのATSを、カレントWindowのIn＿Timeに設定した上で、ステップＳ２〜ステップＳ７の処理を繰り返すループ構造を有している。このループ構造は、カレントWindowのIn＿Timeから1秒以降に存在するATSを、カレントWindowのOut＿Timeに設定して(ステップＳ２)、カレントWindowのIn＿TimeからOut＿Timeまでに存在するTSパケット数をカウントし(ステップＳ３)、In＿TimeからカレントWindowにおけるビット数を算出して(ステップＳ４)、そのビット値が48Mbit以下であるかを判定する処理(ステップＳ５)を、ステップＳ６がYesと判定されるまで繰り返すものである。このステップＳ６は、カレントWindowのOut＿Timeが、ATC時間軸における最後のSourceパケットに到達したかどうかの判定であり、もしステップＳ６がNoであるなら、Sourceパケット列における次のATSを、カレントWindowのIn＿Timeにして(ステップＳ７)、ステップＳ２〜ステップＳ６の処理を繰り返す。どれかのWindowで、ステップＳ５がNoと判定されたなら、BD-ROM規格に違反していると判定される(ステップＳ９)。全てのWindowでステップＳ５がYesと判定され、ステップＳ６がYesと判定されたなら、BD-ROM規格に適合していると判定される(ステップＳ８)。
【０１７２】
プライマリTS、セカンダリTSは、以上のベリファイを経ているので、プライマリTS、セカンダリTSがそれぞれBD-ROM、ローカルストレージから供給される場合でも、上述したような制限が常に満たされることになる。
ビデオストリーム、オーディオストリーム、PGストリーム、IGストリームのそれぞれに、同種のエレメンタリストリームが複数存在する場合、図３５の手順で、ベリファイを行うのが望ましい。図３５に示すベリファイ手順は、図３４におけるステップＳ３〜ステップＳ４を、ステップＳ８１〜ステップＳ８３に置き換えたものである。
【０１７３】
このステップＳ８１〜ステップＳ８３は、カレントWindowが1つ決定される度に、STN＿tableにおいて、再生が許可されているエレメンタリストリームを構成するTSパケットのうち、カレントWindowに属するもののビットレートを、エレメンタリストリーム毎に算出して(ステップＳ８１)、複数のビデオストリーム、複数のオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び(ステップＳ８２)、ビデオストリームのビットレートの最大値、オーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して(ステップＳ８３)、その合計量が48Mbit以下であるかを判定する(ステップＳ５)ものである。
【０１７４】
同種のエレメンタリストリームは、Out＿of＿MUXアプリケーションでは、必ず排他的に選択されるため、上述した判定でベリファイを行うのがより合理的である。
ベリファイは、ビットレートが局所的に高く箇所、つまり、ローカルピークの出現箇所におけるビット値をチェックすることも有効である。ローカルピークの出現箇所は以下の通りである。
【０１７５】
(1)WindowのIn＿Timeが指し示すTSパケットの先頭
(2)WindowのIn＿Timeが指し示すTSパケットの終了
(3)WindowのOut＿Timeが指し示すTSパケットの先頭
(4)WindowのOut＿Timeが指し示すTSパケットの終了
かかる箇所におけるビット量を重点的にチェックすることで、オーサリングでのベリファイ作業を、より簡略化することができる。
【０１７６】
以上のように本実施形態によれば、セカンダリTSの再生を許可したSTN＿tableを作成した際、そのSTN＿tableに基づく再生処理で、アンダーフロー又はオーバーフローが生じるかどうかを、オーサリングの段階で、あらかじめ検証しておくことができる。
(第３実施形態)
本実施形態は、PlayItem間、SubPlayItem間の接続に、CC=6という新たな類型を設ける実施形態である。
【０１７７】
CC=6とは、Progressive PlayList情報を構成する複数のPlayItem情報間の接続状態を規定する。ProgressivePlayList情報とは、ストリーミングを前提にして再生されるべき複数のAVClipを、1つの再生経路として指定してゆくためのプレイリスト情報である。
＜Progressive  PlayList情報＞
Progressive  PlayList情報は、ダウンロード/ストリーミングするセカンダリTSを細切れのファイルに分割することで、キャッシュサイズを小さくしたり、全てのファイルのダウンロードを待たずに、再生を開始することができる利便がある。
【０１７８】
ストリーミングを前提にしたコンテンツは、短い長さの多くのAVClipにて規定されているので、Progressive PlayList情報は、これら複数AVClipのそれぞれに対応する、多くのPlayItem情報から構成される。一方、細かい単位に分割されたAVClipは、ストリーミングのために分割されたのであって、STC、ATCに不連続点が存在している訳ではない。そのため、CC＝5ではない別の状態として、かかるAVClip間の接続状態を規定しておく必要がある。こうして規定された接続状態を、CC=6という。
＜CC=6において満たすべき条件＞
CC=6である場合、2つのPlayItemから指定されるTS1、TS2と、2つのSubPlayItemから指定されるTS1、TS2とは、以下の条件を満たす必要がある。
【０１７９】
1)TS2におけるビデオストリームは、GOPから始まらなければならない。
2)TS2のオーディオストリームと同じPIDをもつTS1のオーディオストリームとにおいて、接続点におけるAudio Presentation Unit列に、ギャップが存在しない。
TS1のオーディオストリームは、不完全なオーディオストリームで終わってもよい。そして、TS2における同じPIDをもつオーディオストリームは、不完全なAudioPresentation Unitから始まってもよい。複数のPlayItem、複数のSubPlayItemに基づき、これらのTS1、TS2を再生させてゆけば、2つのAudioPresentation Unitから、1つの完結したAudio Presentation Unitが得られる。
【０１８０】
CC=6では実際にはストリームが連続しているため、CC=５の時のようなビデオだけがシームレス接続され、オーディオが不連続に繋がれたり、ミュートされたりするようなことはなく、全てのエレメンタリストリームがシームレスに接続される。
以上のようにCC=6は、論理的に連続しているストリームを、ストリーミングの都合から、複数の部分に分割した場合の分割境界を意味する。ただし、BD-ROMに記録されるべきストリームは32個のSourceパケットから構成される必要があるので、１つのSubPlayItemを構成する１つのストリームファイルは、全て、6KByteの倍数になっている必要がある。
【０１８１】
＜CC=6の詳細＞
図３６は、CC=6の詳細な説明を示す図である。第1段目は、１本の連続したATC/STC時間を有し、符号化方式も連続しているストリームを格納したファイル(20000.m2ts)を示す。第2段目は、3つのストリームを格納した格納した3つのファイル(20001.m2ts,20002.m2t,20003.m2ts)を示す。これらの3つのファイルは、第1段目における1本のストリームを、アラインドユニット（6KByte）単位で区切ることで得られた、3つのプライマリTSを格納している。
【０１８２】
図３７は、PlayItemとSubPlayItemの相関を示した図である。第1段目は、PlayList情報における3つのPlayItem(PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3)を示す。これら3つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC＝1に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC＝5に設定されている。第2段目は、PlayList情報における3つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3)を示す。これら3つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC＝1に設定され、SubPlayItem＃2、SubPlayItem＃3間は、CC＝5に設定されている。第3段目は、ProgressivePlayList情報における9つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9)を示す。これら9つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はCC=1に設定され、SubPlayItem＃6、SubPlayItem＃7間は、CC＝5に設定され、それ以外は、CC=6に設定されている。Progressive  PlayListのSubPlayItemは、CC=6で接続されるが、PlayItemがCC=１、CC=５で接続されるタイミングでは、PlayItemと同様にCC=１、CC=５の条件を満たしながら接続される。
【０１８３】
以上のように本実施形態によれば、PlayItem、SubPlayItemにおける接続状態に、CC=6という新たな類型を導入することで、ProgressivePlayList情報を構成するAVClipを短く区切って、ストリームングで供給するという処理を実現することができる。
(第４実施形態)
第１実施形態では、各Windowにおけるビット量を、どのように制限するかについて説明したが、本実施形態では、かかる制限を満たすため、どのように多重化を行えばよいかを提案する。
【０１８４】
＜ビデオ＋オーディオの多重化＞
図３８は、プライマリTSを構成するオーディオが、セカンダリTSを構成するオーディオに入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
図３８は、ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的に示す図である。第1段目は、プライマリTSを示す。プライマリTSはV、A1、A2（ビデオ１本、オーディオ２本）を格納したTSパケットである。これらのTSパケットは、２種類３本のエレメンタリストリームを多重化して得たものである。
【０１８５】
第2段目は、セカンダリTSを示す。セカンダリTSは、１種類２本のオーディオA３、A４を格納したTSパケットからなる。これらセカンダリTSのTSパケットが多重化される時間帯p3は、デコーダへの入力時間軸を示すATC時間軸上で、プライマリTSのオーディオパケットが多重化された時間帯p1と、プライマリTSを構成するTSパケットが転送されてない時間帯p2とからなる。
【０１８６】
このように多重化されれば、各種のエレメンタリストリームのうち、どれが選択されてもデコードすべきエレメンタリストリームのビットレートの和がプライマリTSの許容最大ビットレート（４８Mbps）を超えない保証ができる。図３８の上述した一例は、一番簡単な例で、セカンダリTSにオーディオしかない場合である。
＜ビデオ＋オーディオ＋PGストリーム＋IGストリームの多重化＞
図３９は、オーディオに加えて、字幕（PGストリーム）やメニュー（IGストリーム）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
【０１８７】
本図において、セカンダリTSのパケットの転送が許可される時間帯k3は、
1) プライマリTSにおける同種のパケットの転送時間帯k1
2) プライマリTSの無転送時間帯k2
の和である。
セカンダリTSに格納されている他ストリーム種別（Video、IG、PG等）についても上記1)、2)のルールは同様に適用されるため、各ストリームとも最初には自らと同じ種類のストリームの転送時間帯でセカンダリTS内に多重化が可能か判断され、これで不足する場合には、2)のプライマリTSの無転送時間帯を利用して多重化されることが効率的である。
【０１８８】
＜マルチプレクサ６０の処理＞
本実施形態にかかるマルチプレクサ６０の処理について具体的に説明する。
上述したような多重化を実現するにあたってマルチプレクサ６０は、デコーダモデルにおいて、プライマリTSを再生する際のバッファ状態をシミュレートし、プライマリTSにおける各パケットの転送時間帯や、プライマリTSの無転送時間帯を検出する。これらの時間帯を検出すれば、セカンダリTSを構成する各PESパケットが、同種のパケットの転送時間帯や、無転送時間帯に転送されるよう、セカンダリTSを構成する各PESパケットをTSパケットに変換して、各TSパケットに、かかるATSを付す。こうして付されたATSは、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリTSを構成する各PESパケットは、図３９に示したように、プライマリTSにおける同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。
【０１８９】
＜DVDによる供給＞
ローカルストレージから供給されるエレメンタリストリームを、トランスポートストリーム形式ではなく、プログラムストリーム形式にする場合、マルチプレクサ６０は、エレメンタリストリームを構成するPESパケットを、パックに変換して、各パックのTSヘッダにSCR(SystemClock Reference)を付す。こうして付されたSCRも、ATS同様、同種のパケットの転送時間帯や、無転送時間帯を示すので、セカンダリPS(ローカルストレージから供給されるプログラムストリーム)を構成する各PESパケットは、図３９に示したように、プライマリPS(BD-ROMから供給されるプログラムストリーム)における同種のパケットの転送時間帯や、無転送時間帯にデコーダに送り込まれることになる。ローカルストレージから供給されるエレメンタリストリームをプログラムストリーム形式にする場合、同種のパケットの転送時間帯や、無転送時間帯を、パック（PESパケット）という大きな時間単位で表現するので、オーサリング時における負担は格段に小さく、実現が容易となる。これは、DVD再生装置において、Out＿of＿MUXアプリケーションを実現するにあたっての、利点となる。
【０１９０】
以上のように本実施形態によれば、プライマリTSにおける同種のパケットの転送期間、プライマリTSにおける無転送期間を、セカンダリTSを構成するパケットの入力期間に選び多重化を行うので、第１実施形態に示したビット量制限を満たしやすくなる。かかる多重化を第２実施形態に示したオーサリングシステム上で実現することにより、Out＿of＿MUXアプリケーションを実現するような映画作品を製作しやすくなる。これにより、再生時のオーバフローが生じないような保障をオーサリングの段階で、容易に行うことができる。
（第５実施形態）
本実施形態では、オーディオミキシングアプリケーションの詳細な説明を行う。本アプリケーションは、1つの種別につき、1つのエレメンタリストリームというOut＿of＿MUXの規定の例外になるアプリケーションである。どの点が例外かというと、オーディオミキシングアプリケーションはプライマリTSにあたるオーディオストリームと、セカンダリTSにあたるオーディオストリームとを同時に選択し、プライマリTSの音声とセカンダリTSの音声の２つの音声を同時にデコードする点が例外となる。
【０１９１】
図４０は、オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。本図では、BD-ROM再生装置の内部構成のうち、BD-ROMドライブ１a、ローカルストレージ２００、ネットワーク部２５を左側に示し、各デコーダを右側に示す。真ん中に、ストリームの多重分離を行うPIDFilterを示す。そして本図におけるプライマリTS(Video1,Audio1(English),Audio2(Spanish),PG1(EnglishSubtitle),IG1(English Menu))、セカンダリTS(Audio3(Commentary),PG2(JapaneseSubtitle),PG3(Korean Subtitle),PG4(Chinese Subtitle),IG2(English Menu))は、それぞれBD-ROM、ローカルストレージから供給されるトランスポートストリームを示す。ディスク単体には英語（Audio1）とスペイン語（Audio 2）しか記録されていないため、映画監督のコメンタリ音声は、このディスクから選択することはできない。しかしながら、コンテンツプロバイダが提供するAudio3(Commnetary）の入ったセカンダリTSを、ローカルストレージにダウンロードすれば、英語音声（Audio 1）と、Audio 3(Commentry）とを、デコーダに送り込むことができる。これらの英語音声（Audio1）と、Audio 3(Commentry）とを、デコーダがミキシングして出力すれば、コメンタリが付された英語音声を、ユーザは、映像(Video1)と共に再生させることができる。
【０１９２】
Out-of-MUXアプリケーションとの相違は２つのオーディオストリームを同時にデコードする点のみである。如何なるプライマリTSに対しても、ディスク発売後に監督のコメンタリ音声を付加するなどといったことが想定されるため、プライマリTSへのビットレート制限などは好ましくなく、Out-of-MUXと同様にセカンダリTSへの制限を導入する。オーディオミキシングでは、各エレメンタリストリーム（ビデオ、オーディオ、字幕、メニュー）に加えてオーディオをデコードする必要があるため、オーディオデコーダのリソースを2つ必須とする。
【０１９３】
＜プライマリ、セカンダリオーディオストリームの構成＞
オーディオミキシングアプリケーションを実現するにあたって、プライマリTSにおける属することになるオーディオストリームを、プライマリオーディオストリームといい、セカンダリTSに属することになるオーディオストリームをセカンダリオーディオストリームという。これら、プライマリオーディオストリーム、セカンダリオーディオストリームについて説明する。
【０１９４】
プライマリオーディオストリームは、32本存在し、それらは0x1100から0x111FまでのPIDをもつ。一方、セカンダリオーディオストリームもまた、プライマリオーディオストリーム同様、32本存在し、0x1A00から0x1A1FまでのPIDをもつ。
セカンダリオーディオストリームがプライマリオーディオストリームと異なるのは、セカンダリオーディオストリームのオーディオフレームに、“ダウンミキシング情報”と、“ゲイン制御情報”とからなるメタデータを含む点である。
【０１９５】
“ダウンミキシング情報”は、ダウンミキシングのための情報である。ダウンミキシングとは、音声の再生チャネル数を符号化チャンネル数よりも少なくする変換であり、ダウンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、このダウンミキシングを再生装置に行わせる。5.1chの音声ストリームを2chで再生することなどがダウンミキシングの一例である。
【０１９６】
“ゲイン制御情報”とは、プライマリオーディオストリーム側の音声出力時のゲインを上げ下げする情報であるが、ここでは下げるだけでよい。このようにセカンダリオーディオストリームのメタデータは、同時に再生されるプライマリオーディオストリームの出力をリアルタイムに下げることができる。PrimaryオーディオとSecondaryオーディオを重畳する場合には、あらかじめミキシングされるPrimaryオーディオとSecondaryオーディオの対が分かっているため、2本のオーディオのゲインをリアルタイムに制御する必要は無く、Primaryオーディオのゲインだけを下げてSecondaryオーディオのゲインはそのままにミキシング(重畳)することで十分である。かかるメタデータを配置することで、プライマリオーディオストリームとの再生出力の音量と、セカンダリオーディオストリームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避けることができる。以上が、本実施形態におけるオーディオストリームについての説明である。続いて、本実施形態におけるPlayList情報における改良について説明する。
【０１９７】
＜オーディオミキシングアプリケーションを実現するためのSTN＿table＞
同種のエレメンタリストリームを、同時にデコーダにデコードさせることになるので、本実施形態における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は、そのセカンダリオーディオストリームの再生出力をミキシングすることができる1つ以上のプライマリオーディオストリームを一意に指定する。これにより、所定の属性を有しているようなプライマリオーディオストリームの再生時においては、セカンダリオーディオストリームをミキシングさせず、それ以外の属性を有しているようなプライマリオーディオストリームの再生時においてのみ、セカンダリオーディオストリームをミキシングするというような、音声属性に応じた、ミキシングの可否を、オーサリング時に設定しておくことができる。
【０１９９】
（sp＿connection＿condition情報）
またPlayList情報において、SubPlayItemのsp＿connection＿condition情報は、PlayItem情報のconnection＿condition情報と同じ値に設定される。よってPlayItem情報のconnection＿condition情報が“＝5”であるなら、SubPlayItem情報のsp＿connection＿condition情報もSP＿CC=5に設定される。また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は、TransportBuffer６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時間軸において、1ずつWindowを、シフトさせてゆく。このシフトの手順は、図３５のフローチャートに示したものと同じである。そしてATSに示されるATC時間軸の各座標において、ビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、ビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が48Mbit以下であるかを判定する。48Mbitを越えていれば、BD-ROM規格に違反していると判定結果を下す。
【０２０６】
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリオーディオストリーム、セカンダリオーディオストリームを同時に読み出し、プライマリオーディオストリーム用のデコーダ、セカンダリオーディオストリーム用のデコーダに供給する場合でも、1秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、オーディオミキシングアプリケーションを、効率的に作成することができる。そのため、オーディオミキシングアプリケーションを実現するような追加コンテンツを、ローカルストレージにダウンロードして、ローカルストレージからデコーダに供給するという供給態様が可能になるので、BD-ROMの出荷後に、コメンタリを追加するような供給法を容易に実現することができる。
【０２０７】
（第６実施形態）
第１実施形態では、PlayItemにおけるIn＿Time、Out＿Timeと、SubPlayItemにおけるIn＿Time、Out＿Timeとを一致させることで、PlayItem間の接続点、及び、SubPlayItemの接続点を一致させたが、本実施形態は、オーディオミキシングを実現するため、この接続点の一致を要求せず、ある程度の時間差を認める。
【０２０８】
この時間差を認める場合、別の制限が必要になる。PlayItem、SubPlayItem間のシームレス接続において、上述したSTCの変更処理を行うが、この変更処理は、デコーダがフリーラン状態にある場合になされる。この場合、シームレス接続ではSTCが復帰するまで、デコーダは、同期制御に移ることができないので、STC変更を伴うシームレス接続は実装の都合上、頻繁には受け入れられない。したがって、PlayItemとSubPlayItemの両方において連続するCC=５の接続点は所定の時間間隔（例えば3秒程度)を置いて起こるように制限されるべきである。
【０２０９】
図４２は、オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。図４２の第1段目は、PlayList情報における3つのPlayItem(PlayItem情報＃1、PlayItem情報＃2、PlayItem情報＃3)を示す。これら3つのPlayItemはプライマリTSを指定しており、PlayItem情報＃1、PlayItem情報＃2間はCC=1に設定され、PlayItem情報＃2、PlayItem情報＃3間は、CC＝5に設定されている。図４２の第2段目は、PlayList情報における3つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3)を示す。これら3つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃1、SubPlayItem＃2間はCC=1に設定され、SubPlayItem＃2、SubPlayItem＃3間は、SP＿CC＝5に設定されている。図４２の第3段目は、ProgressivePlayList情報における9つのSubPlayItem(SubPlayItem＃1、SubPlayItem＃2、SubPlayItem＃3〜SubPlayItem＃9)を示す。これら9つのSubPlayItemはセカンダリTSを指定しており、SubPlayItem＃3、SubPlayItem＃4間はSP＿CC=1に設定され、SubPlayItem＃4、SubPlayItem＃5間は、SP＿CC=5に設定され、それ以外は、SC=6に設定されている。
【０２１０】
本図において、第2段目のSubPlayItem＃3の開始は、第1段目におけるPlayItem＃3の開始点より3秒前である。同様に、第3段目のSubPlayItem＃5の開始点は、第1段目におけるPlayItem＃3の開始点より3秒前である。
PlayItemと、SubPlayItemとのSTC時間軸切り替えのための時間間隔は、3秒になっているので、STC時間軸の変更が頻繁になり過ぎることはない。
【０２１１】
またCC=１のタイミングはPlayItemに合わせてSP＿CC=１で接続される。これはCC=１のノンシームレス接続時にSubPlayItemだけが再生を連続して継続した場合に、PlayItemとSubPlayItemの同期再生がずれていくことを防ぐためでもある。
PlayItemの途中でSubPlayItemをSP＿CC=５で接続するという接続形態は、一枚のディスクに劇場公開版とディレクターズカットの両方を収録する際に有益となる。
【０２１２】
図４３の第1段目は、劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す。このPlayList情報のうち、PlayItem＃１、PlayItem＃２、PlayItem＃４から構成されるがディレクターズカットであり、PlayItem＃１、PlayItem＃３、PlayItem＃４から構成されるのが劇場公開版である。このように、PlayItem＃１とPlayItem＃４はどちらのバージョンでも共有可能であるため効果的にタイトルを作成することができる。お互いに異なる映像が全体に比べて短いため、効果的にディスク全体のデータ容量を抑えることができる。図４３の第2段目は、同図の第1段目におけるPlayItem＃１、PlayItem＃２、PlayItem＃４に対応するコメンタリを1つのSubPlayItemとして定義し、PlayItem＃１、PlayItem＃３、PlayItem＃４に対応するコメンタリとを、別のSubPlayItemとして定義する一例を示す。この場合、2つのSubPlayItemのそれぞれにおいて、PlayItem情報＃1、PlayItem情報＃4に対応するコメンタリを、用意しておく必要があり、データ容量の点で難が多い。
【０２１３】
図４３の第3段目は、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＝5で接続するものとする。これらの接続点は、PlayItemにおける接続点と、3秒の時間間隔を設ける。つまりPlayItem＃１が終わる3秒前にコメンタリの方はSubPlayItem＃２とSubPlayItem＃３にCC=５（もしくはCC=6）を使って分岐させている。
【０２１４】
また、PlayItem＃２、PlayItem＃３が終わった3秒後にCC=５（もしくはCC=6）を使ってSubPlayItem＃４に分岐している。SubPlayItem＃２とSubPlayItem＃３の開始、及び、SubPlayItem＃４の開始は、PlayItem＃２とPlayItem＃３の開始、及び、PlayItem＃４の開始から、3秒の時間間隔を置いている。以上の時間間隔を置くことにより、STC時間軸の変更が頻繁になり過ぎることはない。
【０２１５】
厳密には、CC=５は、SubPlayItem＃３からSubPlayItem＃４への復帰の時だけ（ATC/STC時間軸がリセットされるシームレス接続）必要であり、その他はCC=6で代用が可能である。
以上のように本実施形態によれば、PlayItemのIn＿Time、Out＿Timeと、SubPlayItemのIn＿Time、Out＿Timeとが一致していないので、ATCCounter２aと２c、およびSTC Counter３aとSTC Counter３cの同期は不要となり、再生装置の設計の余地を広げることができる。
【０２１６】
(第７実施形態)
第６実施形態では、プライマリオーディオストリーム、セカンダリオーディオストリームをBD-ROM、ローカルストレージから同時に読み出しデコーダに供給する場合、プライマリオーディオストリーム、セカンダリオーディオストリームを、ビット量制限の対象としたが、本実施形態では、Picturein Picture(PiP)再生アプリケーションを実現する場合におけるビット量制限について説明する。
【０２１７】
PiP再生とは、PlayList情報のMainPath情報により、動画像を構成するMainClipが指定されており、PlayList情報のSubPlayItem情報により、別の動画像を構成するSubClipが指定されている場合、前者の動画像(PrimaryVideo)と、後者の動画像(Secondary Video)とを、同じ画面内に表示するこという。ここでPrimary VideoはHD画像から構成され、SecondaryVideoはSD画像から構成される。HD画像は、1920×1080という解像度を有し、フィルム素材同様、3750（もしくは3753か3754）クロックのフレーム間隔を有する。SD画像は、720×480という解像度を有し、NTSC素材同様、1501クロックの表示間隔、又は、PAL素材同様、1800クロックのフレーム間隔を有する。
【０２１８】
SD画像の解像度は、HD画像の解像度の約1/4程度なので、HD画像たるPrimary Videoと、SD画像たるSecondary Videoとを同じ画面上に表示すると、SecondaryVideoは、Primary Videoに対し、約1/4程度の大きさになる。
ここでSecondary Videoは、監督や出演者のみが登場している動画像であり、Primary Videoにおける映像内容を指さすような演技を行っているものとする。かかる動画像がSecondaryVideoであるなら、かかるSecondary Videoの映像内容を、Primary Videoの映像内容と組み合わせることにより、映画作品本編の再生映像の中身を、監督や出演者が指さして、解説しているような、楽しい画面演出を実現することができる。
【０２１９】
＜本実施形態におけるPlayList情報＞
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情報が“=5”に設定されているということは、カレントSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームと、previousSubPlayItem側のSubClipに多重化されているセカンダリビデオストリームとがシームレス接続される保証があることを意味する。かかるSubPlayItemのsp＿connection＿condition情報は、PlayItem情報のconnection＿condition情報と同じ値に設定されるので、PlayItem情報のconnection＿condition情報が“＝5”であるなら、SubPlayItem情報のsp＿connection＿condition情報も“＝5”に設定されねばならない。つまりPlayItem側のプライマリビデオストリームがシームレス接続されるなら、SubPlayItem側のセカンダリビデオストリームもシームレス接続されねばならない。またSubPlayItem情報のIn＿Time、Out＿Timeは、PlayItem情報のIn＿Time、Out＿Timeと同じ時点を指し示さねばならない。
【０２２１】
以上が、本実施形態における記録媒体の改良である。
＜本実施形態における再生装置の改良＞
続いて、再生装置の改良について説明する。Secondary Videoストリームのデコードを行うべく、本実施形態に係る再生装置のハードウェア構成には、ビデオストリームをデコードするための構成要素がもう一組、追加されている。ここでビデオストリームをデコードするための構成要素とは、TransportBuffer、Multiplexed Buffer、Elementary Buffer、デコーダ、Videoプレーンであり、これらはセカンダリビデオストリームをデコードする。その他、本実施形態に係る再生装置には、以下のScaller、合成部が追加されている。
【０２２２】
Scallerは、SubPlayItem情報のPiP＿Sizeに示される縦・横の大きさに基づき、Secondary Videoプレーン上に得られた再生映像を拡大又は縮小する。
合成部は、Scallerによりされた拡大又は縮小された再生映像と、ビデオデコーダにより得られた再生映像とを合成することでPiP再生を実現する。合成部によるPrimaryVideoの再生映像と、Secondary Videoの再生映像との合成は、SubPlayItem情報にて規定されている、PiP＿Positionに従ってなされる。こうすることにより、PrimaryVideoの再生映像と、Secondary Videoの再生映像とが合成された合成映像が再生されることになる。この合成部による合成では、クロマキー合成、レイヤ合成等が可能であり、SecondaryVideoにおける背景を取り除き、人物部分を抜き出した上で、Primary Videoの再生映像に合成することも可能である。以上が、本実施形態に係る、再生装置についての説明である。
【０２２３】
＜PiPアプリケーションに対するベリファイ＞  
PiP再生の実現にあたって、プライマリTSたるビデオストリーム(プライマリビデオストリーム)、セカンダリTSたるビデオストリーム(セカンダリビデオストリーム)を同時に読み出し、デコーダに供給する場合、プライマリビデオストリーム、セカンダリビデオストリームを、ビット量を制限するためのベリファイの対象とする。
【０２２４】
具体的にいうとATC時間軸においてWindowをシフトさせた際、ATSに示されるATC時間軸の各座標において、プライマリビデオストリーム、セカンダリビデオストリーム、複数のプライマリオーディオストリーム、複数のセカンダリオーディオストリーム、複数のPGストリーム、複数のIGストリームのうち、算出されたビットレートが最も高いものを選び、プライマリビデオストリームのビットレートの最大値、セカンダリビデオストリームのビットレートの最大値、プライマリオーディオストリームのビットレートの最大値、セカンダリオーディオストリームのビットレートの最大値、PGストリームのビットレートの最大値、IGストリームのビットレートの最大値を合計して、その合計量が48Mbit以下であるかを判定する。
【０２２５】
以上のように本実施形態によれば、BD-ROM、ローカルストレージの双方からプライマリビデオストリーム、セカンダリビデオストリームを同時に読み出し、それぞれに対応するデコーダに供給する場合でも、1秒当たりのビット量が、所定の上限を越えないという保障を施すことができる。かかる保障を与えるので、PiPアプリケーションを、効率的に作成することができる。  
【０２２６】
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的
であり、実施する者の主観によることは留意されたい。
【０２２７】
(In＿Time、Out＿Time)
図２７では、TS1の最後のVideo Presentation UnitをpreviousPlayItemのOut＿Timeとして選び、TS2の最初のVideoPresentation UnitをpreviousPlayItem、previousSubPlayItemのIn＿Timeとして選んだが、TS1の途中のVideoPresentation UnitをpreviousPlayItemのOut＿Timeとして選び、TS2の途中のVideo Presentation UnitをカレントPlayItem、カレントSubPlayItemのIn＿Timeとして選んでもよい。この場合、PlayItem、カレントSubPlayItemは、シームレスに接続することができず、CC=1,SP＿CC=1として接続せねばならない。
【０２２８】
(PlayList情報全体)
2つのPlayItem間をCC＝5で接続しようとする場合、1つのPlayList情報に属する全てのPlayItem情報、全てのSubPlayItem情報は、CC＝5として接続せねばならない。
(デコーダへのデータ供給量)
Out＿of＿MUXにおいて、デコーダへのデータ供給量は必ずしも大きくなる訳ではない。例えば、プライマリオーディオストリームがMainClipであり、CBRのDD(DolbyDigital)と、VBRのMLPとから構成されていて、このMLPが、ローカルストレージから供給されたCBRのDDに置き換えられるものとする。この場合、デコーダへのデータ供給量はかえって低下する。このようなことが明らかであれば、ベリファイを省略してもよい。
【０２２９】
(再生時間差)
CC＝5、SP＿CC=5を実現するにあたって、１つのPlayItemの中での各ビデオストリーム/オーディオストリームの再生時間差も小さいことが望ましい。この差もビデオ１フレーム分（1/60〜1/25秒）としても良いし、１秒以下などとしても良いし、全体の再生時間に対する割合（１％以下など）であっても良いし、これら２つを組み合わせたものであっても良い。１つのSubPlayItemの中での各ビデオ/オーディオエレメンタリストリームの再生時間差も同様である。
【０２３０】
１つのPIDに、2つのエレメンタリストリームを格納するケースにおいては、同一PIDで格納される２つのストリームの再生時間長の差は、どちらか再生時間が短いストリームの方の最小再生単位（１フレーム）の再生時間長未満であることが望ましい。かかるケースに該当するのは、Dolby  Digital（AC-3）と、MLP（MeridianLossless Packing）とが、1つのエレメンタリストリームに格納されて、BD-ROMに記録される場合である。
【０２３１】
(追加コンテンツに対する処理)
ローカルストレージ２００にダウンロードされた追加コンテンツは、何ヶ月、何年か経過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
（PIDの代用）
オーディオミキシングアプリケーションの実現時において、プライマリオーディオストリーム、セカンダリオーディオストリームの区別にPIDを用いたが、MPEG2-PSを使う場合には、PESパケットヘッダのstream＿idをそれぞれ異なるものにするのが望ましい。
【０２３２】
またプライマリオーディオストリーム、セカンダリオーディオストリームは、２つの音声ストリームが１つのデマルチプレクサでも弁別可能なように、システムストリームレベルにおいて区別されていればよい。もしくは、２つのストリームを１つに束ねる前に、片方の
PIDを重複しないように付け替えておくだけでもよい。
【０２３３】
（プリロード）
クリック音のためのオーディオデータ（ファイルsound.bdmv）のプリロードは、BD-ROMのローディング時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、機器の応答性を高めAVClip再生が途切れにくくすることができる。
【０２３４】
(Java（登録商標）プラットフォーム)
各実施形態にかかる再生装置に、JAVA（登録商標）2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、GloballyExecutable MHP specification(GEM1.0.2)for package media targetsとをフル実装することでJava（登録商標）プラットフォームを構成し、BD-Jアプリケーションを再生装置に実行させてもよい。そしてこのアプリケーションの実行にあたって、Out＿of＿MUXフレームワークを再生装置に実行させてもよい。
【０２３５】
（タイトル）
BD-ROMの装填やユーザ操作、装置の状態に応じてタイトルを選択する“モジュールマネージャ”を再生装置に設けるのが望ましい。BD-ROM再生装置内のデコーダは、この“モジュールマネージャ”によるタイトル選択に応じて、プレイリスト情報に基づくAVClipの再生を行う。
【０２３６】
アプリケーションマネージャは、“モジュールマネージャ”がタイトルの選択を行った際、前のタイトルに対応するアプリケーション管理テーブル(AMT)と、カレントタイトルに対応するAMTとを用いてシグナリングを実行する。このシグナリングは、前のタイトルに対応するAMTには記載されているが、カレントタイトルに対応するAMTには記載されていないアプリケーションの動作を終了させ、前のタイトルに対応するAMTには記載されておらず、カレントタイトルに対応するAMTには記載されているアプリケーションの動作を開始させるという制御を行う。
【０２３７】
(ローカルストレージ内のディレクトリ構成)
各実施形態に示したローカルストレージ内の各領域は、BD-ROMにおけるディスクルート証明書に対応するディレクトリの配下に設けるのが望ましい。
ディスクルート証明書とは、このBD-ROMを作成した作成者が、ルート認証局から配布を受けたルート証明書を、BD-ROMに割り当てたものである。ディスクルート証明書はたとえばX.509の形式で符号されている。X.509の仕様は国際電信電話諮問委員会より発行されており、CCITTRecommendation X.509 (1988), "The Directory -  AuthenticationFramework"に記載されている。
【０２３８】
また、BD-ROM、ローカルストレージの記録内容は、Advancend Access Content System(AACS)にて暗号化され、署名情報が付されて、利用権限が、パーミッションファイルに規定されているのが望ましい。
（実装すべきパッケージ）
BD-ROM再生装置を、Java（登録商標）プラットフォームとして実施するにあたっては、以下のBD-J Extentionを再生装置に実装するのが望ましい。BD-JExtentionは、GEM[1.0.2]を越えた機能を、Java（登録商標）プラットフォームに与えるために特化された、様々なパッケージを含んでいる。BD-JExtentionにて供給されるパッケージには、以下のものがある。
・org.bluray.media
このパッケージは、Java（登録商標） Media FrameWorkに追加すべき、特殊機能を提供する。アングル、音声、字幕の選択についての制御が、このパッケージに追加される。
・org.bluray.ti
このパッケージは、GEM[1.0.2]における“サービス”を“タイトル”にマップして動作するためのAPIや、BD-ROMからタイトル情報を問い合わせる機構や新たなタイトルを選択する機構を含む。
・org.bluray.application
このパッケージは、アプリケーションの生存区間を管理するためのAPIを含む。また、アプリケーションを実行させるにあたってのシグナリングに必要な情報を問い合わせるAPIを含む。
・org.bluray.ui
このパッケージは、BD-ROMに特化されたキーイベントのための定数を定義し、映像再生との同期を実現するようなクラスを含む。
・org.bluray.vfs
このパッケージは、データの所在に拘らず、データをシームレスに再生するため、BD-ROMに記録されたコンテンツ(on-discコンテンツ)と、BD-ROMに記録されていないLocalStorage上のコンテンツ(off-discコンテンツ)とをバインドする機構(Binding Scheme)を提供する。
【０２３９】
Binding Schemeとは、BD-ROM上のコンテンツ(AVClip、字幕、BD-Jアプリケーション)と、Local Storage上の関連コンテンツとを関連付けるものである。このBindingSchemeは、コンテンツの所在に拘らず、シームレス再生を実現する。
（Virtual Package）
Virtual Packageを生成させるような処理をBD-ROM再生装置に行わせてもよい。これは、再生装置がVirtual Package情報を生成することでなされる。VirtualPackage情報とは、BD-ROMにおけるボリューム管理情報を拡張した情報である。ここでボリューム管理情報は、ある記録媒体上に存在するディレクトリ−ファイル構造を規定する情報であり、ディレクトリについてのディレクトリ管理情報、ファイルについてのファイル管理情報とからなる。VirtualPackage情報とは、BD-ROMのディレクトリ−ファイル構造を示すボリューム管理情報に、新たなファイル管理情報を追加することにより、BD-ROMにおけるディレクトリ−ファイル構造の拡張を図ったものである。
【０２４０】
(制御手順の実現)
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。
【０２４１】
・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。
【０２４２】
本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２４３】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０２４４】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み出しを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
【０２４５】
本発明に係るプログラムは、以下のようにして使用することができる。本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム(BIOS)や、様々なミドルウェア(オペレーションシステム)と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。
【０２４６】
再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム(BIOS)が命令ROMに組み込まれており、様々なミドルウェア(オペレーションシステム)が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、再生装置に設けられている。この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、1つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、1つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。
【０２４７】
ハードディスクモデルの再生装置では、本発明のプログラムを1つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
(コントローラ２２)
コントローラ２２は、一個のシステムLSIとして実現することができる。
【０２４８】
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
【０２４９】
これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
システムLSIにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。
【０２５０】
各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。
【０２５１】
具体的な実装については、SoC実装やSiP実装を用いることが望ましい。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(Systemin Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
【０２５２】
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
さらに、各記録再生装置の構成要素の一部又は全てを1つのチップとして構成してもよい。集積回路化は、上述したSoC実装,SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（FieldProgrammable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。
【産業上の利用可能性】
【０２５３】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
【図面の簡単な説明】
【０２５４】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】BD-ROMの内部構成を示す図である。
【図３】拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。
【図４】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との対応を示す図である。
【図１９】（ａ）STN＿tableの内部構成を示す図である。  （ｂ）ビデオストリームに対応したStream＿attributeを示す図である。  （ｃ）オーディオストリームに対応したStream＿attributeを示す図である。  （ｄ）ビデオストリームにおけるStream＿entryを示す図である。
【図２０】BD-ROMから読み出されたTSパケットと、ローカルストレージから読み出されたTSパケットとを示し、これらのTSパケットのうち、デコーダに供給されるものを示す。
【図２１】（ａ）〜（ｄ）Windowのシフトを示す図である。
【図２２】BD-ROMから読み出されたTSパケット、ローカルストレージから読み出されたTSパケットのデータ量の時間的推移を示すグラフである。
【図２３】（ａ）（ｂ）各Windowの転送許容量と、Windowにおけるデコーダへの供給量とを対比して示す図である。
【図２４】Out＿of＿MUXアプリケーションを構成するPlayItem、SubPlayItemの接続状態を示す図である。
【図２５】図２４に示した、PlayItemのconnection＿condition情報、SubPlayItemのsp＿connection＿condition情報が“＝5”に設定されている場合の、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において、TS1、TS2がどのように特定されるかを示す図である。
【図２８】CC＝5、及び、SP＿CC＝5の詳細を示す図である。
【図２９】previousPlayItem及びカレントPlayItemにて指定される複数のVideo Presentation Unitと、複数のAudioPresentation Unitと、STC時間軸との関係を示す図である。
【図３０】本発明に係る再生装置の内部構成を示す図である。
【図３１】PlayList情報に基づく再生手順のフローチャートである。
【図３２】SubPlayItemにおけるシームレス接続を示すフローチャートである。
【図３３】第２実施形態にかかるオーサリングシステムの内部構成を示す図である。
【図３４】プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。
【図３５】同種のエレメンタリストリームが複数存在する場合の、プライマリTS、セカンダリTSに対するベリファイ手順を示すフローチャートである。
【図３６】CC=6の詳細な説明を示す図である。
【図３７】PlayItemとSubPlayItemの相関を示した図である。
【図３８】ATC時間軸に存在する複数のTSパケットが、どのように多重化されるかを模式的に示す図である。
【図３９】オーディオに加えて、字幕（PG）やメニュー（IG）も入れ替えられる場合、プライマリTSを構成する複数のTSパケットと、セカンダリTSを構成する複数のTSパケットとが、どのように多重化されるかを模式的に示す図である。
【図４０】オーディオミキシングアプリケーションを構成するプライマリTS、セカンダリTSが、BD-ROM再生装置の内部構成において、デコーダにどのように供給されるかを示す図である。
【図４１】第５実施形態に係る再生装置の内部構成を示す図である。
【図４２】オーディオミキシングを示すプレイリストにて指定されるPlayItemとSubPlayItemの相関を示した図である。
【図４３】劇場公開版とディレクターズカットの両方を構成するPlayList情報の一例を示す図である。
【符号の説明】
【０２５５】
１a      BD-ROMドライブ
１b,c    リードバッファ
１b,a,c  ATCカウンタ
２a,d  Source Depacketizer
２c,d  ATCカウンタ
３a,c  STCカウンタ
３b,d  PID Filter
４  ビデオデコーダ
５  ビデオプレーン
６  Transport Buffer
７  Elementary Buffer
８  オーディオデコーダ
１０a,b,c,d  スイッチ
１１  Interactive Graphicsデコーダ
１２  Interactive Graphicsプレーン
１３  Presentation Graphicsデコーダ
１４  Presentation Graphicsプレーン 
１７  合成部
２１  メモリ
２２  コントローラ
２３  PSRセット
２４  PID変換部
２５  ネットワーク部
２６  操作受付部
１００  BD-ROM
２００  ローカルストレージ
３００  再生装置
４００  テレビ
５００  AVアンプ
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006109716.tif 000045
【図２】
2006109716.tif 000046
【図３】
2006109716.tif 000047
【図４】
2006109716.tif 000048
【図５】
2006109716.tif 000049
【図６】
2006109716.tif 000050
【図７】
2006109716.tif 000051
【図８】
2006109716.tif 000052
【図９】
2006109716.tif 000053
【図１０】
2006109716.tif 000054
【図１１】
2006109716.tif 000055
【図１２】
2006109716.tif 000056
【図１３】
2006109716.tif 000057
【図１４】
2006109716.tif 000058
【図１５】
2006109716.tif 000059
【図１６】
2006109716.tif 000060
【図１７】
2006109716.tif 000061
【図１８】
2006109716.tif 000062
【図１９】
2006109716.tif 000063
【図２０】
2006109716.tif 000064
【図２１】
2006109716.tif 000065
【図２２】
2006109716.tif 000066
【図２３】
2006109716.tif 000067
【図２４】
2006109716.tif 000068
【図２５】
2006109716.tif 000069
【図２６】
2006109716.tif 000070
【図２７】
2006109716.tif 000071
【図２８】
2006109716.tif 000072
【図２９】
2006109716.tif 000073
【図３０】
2006109716.tif 000074
【図３１】
2006109716.tif 000075
【図３２】
2006109716.tif 000076
【図３３】
2006109716.tif 000077
【図３４】
2006109716.tif 000078
【図３５】
2006109716.tif 000079
【図３６】
2006109716.tif 000080
【図３７】
2006109716.tif 000081
【図３８】
2006109716.tif 000082
【図３９】
2006109716.tif 000083
【図４０】
2006109716.tif 000084
【図４１】
2006109716.tif 000085
【図４２】
2006109716.tif 000086
【図４３】
2006109716.tif 000087
【国際調査報告】
2006109716.tif 000088
2006109716.tif 000089
2006109716.tif 000090