(57)【要約】【課題】ストリーム情報記録に関する改善。【解決手段】ストリームデータを記録するように構成されたデータエリアと、前記ストリームデータに関する管理情報を記録するように構成された管理エリアとを持つ情報媒体が用いられる。ここで、前記管理情報（ＳＦＩＴ／ＳＦＩ／ＳＯＢＩ）が、前記ストリームデータの特定部分に対応した時間情報（ＰＴＳＬ）を含むように構成される。【選択図】      図１５
2005293835.tif 000002
【特許請求の範囲】
【請求項１】
ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、
トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、
１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、
前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが記録されるように構成された情報記憶媒体。
【請求項２】
ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが記録されるように構成された情報記憶媒体を用いる記録方法において、
前記データエリアに前記ストリームデータを記録し、
前記管理エリアに前記管理情報を記録するように構成された記録方法。
【請求項３】
ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが記録された情報記憶媒体を用いる再生方法において、
前記管理エリアから前記管理情報を読み取り、
前記データエリアから前記ストリームデータを読み取るように構成された再生方法。
【請求項４】
ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが記録されるように構成された情報記憶媒体を用いる記録装置において、
前記データエリアに前記ストリームデータを記録する手段と、
前記管理エリアに前記管理情報を記録する手段とを備えた記録装置。
【請求項５】
ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが記録された情報記憶媒体を用いる再生装置において、
前記管理エリアから前記管理情報を読み取る手段と、
前記データエリアから前記ストリームデータを読み取る手段とを具備した再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、デジタル放送などで伝送される映像データあるいはパケット構造をもって伝送されるストリームデータを記録する情報記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法に関する。
【背景技術】
【０００２】
近年、ＴＶ放送はデジタル放送の時代に突入してきた。それに伴い、デジタルＴＶ放送のデジタルデータをその内容を問わずデジタルデータのままで保存する装置、いわゆるストリーマが要望されるようになってきた。
【０００３】
現在放送されているデジタルＴＶ放送では、ＭＰＥＧのトランスポートストリームが採用されている。今後も、動画を使用したデジタル放送の分野では、ＭＰＥＧトランスポートストリームが標準的に用いられると考えられる。
【０００４】
このデジタル放送では、放送される内容（主に映像情報）が、トランスポートパケットと呼ばれる所定サイズ（例えば１８８バイト）毎のデータのまとまりに時間分割され、このトランスポートパケット毎に放送データが伝送される。
【０００５】
このデジタル放送データを記録するストリーマとして、現在市販されているものとしては、Ｄ−ＶＨＳ（デジタルＶＨＳ）などの家庭用デジタルＶＣＲがある。このＤ−ＶＨＳを利用したストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、ビデオテープには、複数の番組が多重されて記録されることになる。
【０００６】
再生時には、最初から再生する場合、あるいは途中から再生する場合にも、そのまま全てのデータが、ＶＣＲからセットトップボックス（デジタルＴＶの受信装置：以下ＳＴＢと略記する）に送り出される。このＳＴＢにおいて、ユーザ操作等により、送り出されたデータ内から所望の番組が選択される。選択された番組情報は、ＳＴＢからデジタルＴＶ受像機等に転送されて、再生（ビデオ＋オーディオ等の再生）がなされる。
【０００７】
このＤ−ＶＨＳストリーマでは、記録媒体にテープが用いられるため、素早いランダムアクセスが実現できず、所望の番組の希望位置に素早くジャンプして再生することが困難となる。
【０００８】
このようなテープの欠点（ランダムアクセスの困難性）を解消できる有力な候補として、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用したストリーマが考えられる。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性が出てくる。
【０００９】
ここで、デジタルＴＶの受信装置であるＳＴＢとＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用したストリーマとの間、あるいはこの大容量ディスクメディアを利用したストリーマとＤ−ＶＨＳ等を利用した他のストリーマとの間のデータ転送には、ＩＥＥＥ１３９４等に準拠したデジタルインターフェースを利用できる。
【００１０】
このデジタルインターフェースでは、デジタル放送で受信したトランスポートパケット毎に映像データ／ストリームデータが転送される。
【００１１】
たとえばＩＥＥＥ１３９４を用いたデジタルインターフェースでは、デジタル放送の受信データに対して実時間での転送を保証するため、各トランスポートパケット毎に受信時刻を表すタイムスタンプデータが付加されて、転送が行なわれている。
【００１２】
また、ＤＶＤ−ＲＡＭなどの情報記憶媒体に記録された上記デジタル放送の受信データに対してＳＴＢでの実時間による間断の無い再生を保証するため、情報記憶媒体上に、各トランスポートパケットデータとともに上記タイムスタンプデータも同時に記録される。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記の場合、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用した情報記憶媒体に記録するストリームデータとして、トランスポートパケット毎にタイムスタンプデータが付加されて記録されている。このため、このタイムスタンプデータを利用して時間管理を行うことになる。
【００１４】
デジタルＴＶでは、映像データはＭＰＥＧ２と呼ばれるデジタル圧縮方式を用いて情報圧縮された形で放送される。このＭＰＥＧ２方式によると、Ｐピクチャ情報はＩピクチャに対する差分情報しか持たず、またＢピクチャ情報はＩピクチャとＰピクチャに対する差分情報しか持っていない。したがって、ＢピクチャあるいはＰピクチャは単独で再生することができず、これらを再生するためにはＩピクチャからの再生が必要となる。
【００１５】
ここで、Ｉ、Ｂ、Ｐの各ピクチャの表示時刻で示されるユーザから見た映像再生時間と、前記タイムスタンプ時間とは異なる。このため、情報記憶媒体上に記録したストリームデータに対する時間管理をタイムスタンプデータのみで行った場合には、ユーザに対する表示時刻（映像再生時間）の制御が正確に行えないという問題が生じる。
【００１６】
この発明は上記事情に鑑みなされたもので、その目的は、ストリーム情報記録の処理に関する改善を図ることである。
【課題を解決するための手段】
【００１７】
上記目的を達成するために、この発明の実施の形態では、ストリームデータを記録するように構成されたデータエリア（ＳＴＲＥＡＭ．ＶＲＯ）と、このストリームデータに関する管理情報（ＳＴＲＩ）を記録するように構成された管理エリア（ＳＴＲＥＡＭ．ＩＦＯ）とを持つ情報媒体（２０１）が用いられる。ここで、前記管理情報（図１３のＳＴＲＩ／図１５のＳＦＩＴ）が、前記ストリームデータの特定部分（図１６〜図１７のＡＵ）に対応した時間情報（図１５のＰＴＳＬ）を含むように構成される。
【００１８】
なお、前記ストリームデータは、一定サイズのデータユニット（例えば６４ｋＢのＳＯＢＵ）で構成することができる。
【発明の効果】
【００１９】
ストリーム情報記録の処理に関する改善を図ることができる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照して、この発明の一実施の形態に係るストリームデータ記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法その他を説明する。
【００２１】
図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図１を用いて情報記憶媒体上に記録されたストリームデータのデータ構造について説明する。
【００２２】
ＤＶＤ−ＲＡＭディスク等の情報記憶媒体（図３その他の２０１）上に記録されるストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６（図１（ａ））は、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（以下、適宜ＳＯＢと略記する）としてまとめられている。つまり、各ＳＯＢは、１つのリアルタイムな連続記録により得られたストリームデータにより形成される。
【００２３】
情報記憶媒体上に記録されるストリームデータは、図１（ｂ）に示されるように、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（ＳＯＢ）＃Ａ・２９８、＃Ｂ・２９９としてまとまって記録されている。
【００２４】
図１（ｂ）〜（ｋ）は、複数あるストリームオブジェクト（ＳＯＢ＃Ａ、＃Ｂ、…）のうち、１個のＳＯＢ＃Ａ・２９８について内容を詳細に示している。
【００２５】
ＤＶＤ−ＲＡＭディスクにトリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６が記録される場合には、各々が２０４８バイトのセクタを最小単位として記録される。さらに、１６個のセクタをまとめて１個のＥＣＣブロックとし、同一ＥＣＣブロック内でインターリーブ（データ配列順序の並び替え）とエラー訂正用の訂正コードの付加が行われる。
【００２６】
この実施の形態では、１個または複数（代表的には２個）のＥＣＣブロックを単位としてストリームブロック（あるいはストリームオブジェクトユニットＳＯＢＵ）が構成され、このストリームブロック単位（あるいはＳＯＢＵ単位）でストリーム情報の記録、部分消去、編集その他が行われる。
【００２７】
この実施の形態では、何個のＥＣＣブロックでストリームブロックが構成されるかは、転送されるストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６の転送レートに応じて決めることができる。
【００２８】
たとえば、図１（ｃ）（ｄ）の例では、ストリームブロック＃１は２つのＥＣＣブロック＃α、＃βで構成され、ストリームブロック＃２は３つのＥＣＣブロック＃γ、＃δ、＃εで構成されている。ＤＶＤストリーマでは、２個のＥＣＣブロック（３２セクタ）で１つのストリームブロック（またはＳＯＢＵ）が構成される。
【００２９】
各ＥＣＣブロックは、図１（ｅ）に示すように、１６セクタで構成される。したがって、図１（ｃ）〜（ｅ）から分かるように、２ＥＣＣブロックで構成されるストリームブロック（あるいはＳＯＢＵ）＃１は、３２セクタ（セクタＮｏ．０〜セクタＮｏ．３１）に相当する。
【００３０】
つまり、１セクタ＝２ｋバイトとすれば、ストリームブロック（ＳＯＢＵ）は、６４ｋバイト（３２セクタ）の固定サイズとして、この発明を実施することができる。
【００３１】
ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６は、図１（ｇ）に示すようにタイムスタンプとトランスポートパケットを組にして、情報記憶媒体に記録される。
【００３２】
その際、各セクタの先頭には、図１（ｆ）に示すように、システムクロック情報（システムクロックリファレンスＳＣＲ）等が記録されたパックヘッダ１１、１２とＰＥＳヘッダ１３、１４が配置される。ＰＥＳヘッダ１４の直後にはセクタデータヘッダ１７が記録されるが、各ストリームブロック（またはＳＯＢＵ）先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ１６が記録される。
【００３３】
なお、ストリームブロックヘッダ１６あるいはセクタデータヘッダ１７は、後述するアプリケーションヘッダに対応する内容を持つことができるようになっている（図９あるいは図１０参照）。
【００３４】
図１（ｆ）のセクタデータヘッダ１７は、データエリア２２、２３内のデータ配列情報を示している。
【００３５】
図１（ｆ）のデータエリア２１、２２（あるいは２３）には、図１（ｇ）に示すように、タイムスタンプ（図２０、図２９その他に示したＡＴＳに対応）およびトランスポートパケット（図２２または図２３のパケット、あるいは図２９のアプリケーションパケットＡＰに対応）が逐次詰め込まれる。
【００３６】
図１（ｇ）の例では、１個のトランスポートパケットｄが複数のセクタ（Ｎｏ．０とＮｏ．１）に跨って記録される場合が例示されている。このようなトランスポートパケットｄは、図２２または図２３の部分パケットに対応する。
【００３７】
ところで、デジタル放送では、トランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式が採用されており、１個のトランスポートパケットのサイズは１８８バイト（または１８３バイト）の場合が多い。
【００３８】
一方、前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても、１個のデータエリア２１、２２、２３（図１（ｆ））内には、デジタル放送用のトランスポートパケットを１０個前後記録できる。
【００３９】
トランスポートパケット内は、図１（ｈ）に示すように、トランスポートパケットヘッダ６１〜６４（後述する図２３（ｂ）の５１１に対応）とデータが記録されているペイロード７１〜７５（後述する図２３（ｂ）の５１２に対応）とで構成されている。
【００４０】
ペイロード７１〜７５には、図１（ｉ）に示すように、ＭＰＥＧエンコードされたＩピクチャ情報３１、Ｂピクチャ情報３３、３４、およびＰピクチャ情報３２が記録される。
【００４１】
Ｉピクチャ情報３１が記録されている最初のトランスポートパケットでは、ランダムアクセスインジケータ５０３（図２３（ａ）参照）に”１”のフラグが立ち、各Ｂ、Ｐピクチャ情報３２〜３４の最初のトランスポートパケットにはペイロードユニット開始インジケータ５０１（図２３（ａ）参照）に”１”のフラグが立つ。
【００４２】
ペイロード７１〜７５内に分割記録されている各ピクチャ情報３１〜３４には、図１（ｊ）に示すように、それぞれの先頭に、ピクチャヘッダ情報４１と、実質的なピクチャ情報であるピクチャ圧縮情報４２（Ｉピクチャ情報３１に対してはＩピクチャ圧縮情報４２）とが記録されている。
【００４３】
また、それぞれのピクチャヘッダ情報４１内には、図１（ｋ）に示すように、ヘッダ識別情報５１、それぞれのＩ、Ｂ、Ｐピクチャの識別を可能とするピクチャ識別情報５２、デコーダ出力の表示タイミングを示すＰＴＳ（プレゼンテーションタイムスタンプ）情報５３、およびデコーダがデコード開始を行うためのタイミングを示すＤＴＳ（デコードタイムスタンプ）情報５４が記録されている。これらのピクチャヘッダ情報４１は、デジタル放送の受信情報内に予め含まれている。
【００４４】
情報記憶媒体上に記録されたストリームデータ内では、図１（ｋ）に示すピクチャ識別情報５２を用いて特定のピクチャ位置を同定できる。
【００４５】
あるいは、図１（ｊ）（ｋ）に示すようにピクチャヘッダ情報４１内にＰＴＳ情報５３が記録されているので、この値を用いてデコーダが表示を開始することも可能である。
【００４６】
図２は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図２を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容（ファイル構造）について説明する。
【００４７】
ＤＶＤーＲＡＭディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、ＤＶＤ＿ＲＴＲディレクトリ（またはＤＶＤ＿ＲＴＡＶ）１０２と言う名のサブディレクトリ１０１内に入っている。
【００４８】
ＤＶＤ＿ＲＴＲ（ＤＶＤ＿ＲＴＡＶ）ディレクトリ１０２内には、以下の内容のデータファイル１０３が格納される。
【００４９】
すなわち、管理情報（ナビゲーションデータ）のグループとして、ＲＴＲ．ＩＦＯ（またはＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、ＳＲ＿ＰＲＩＶＴ．ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａとが格納される。
【００５０】
また、データ本体（コンテンツ情報）として、ＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と、ＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、ＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、ＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが格納される。
【００５１】
上記データファイル１０３を含むサブディレクトリ１０１の上位階層にあるルートディレクトリ１００には、その他の情報を格納するサブディレクトリ１１０を設けることができる。
【００５２】
このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットＶＩＤＥＯ＿ＴＳ１１１、オーディオプログラムを収めたオーディオタイトルセットＡＵＤＩＯ＿ＴＳ１１２、コンピュータデータ保存用のサブディレクトリ１１３等がある。
【００５３】
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
【００５４】
そのストリームデータそのものはＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯとそのバックアップファイルＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５である。
【００５５】
また、ＶＣＲ（ＶＴＲ）あるいは従来ＴＶなどで扱われるアナログ映像情報をＭＰＥＧ２規格に基づきデジタル圧縮して記録されたファイルが、ＲＴＲ＿ＭＯＶ．ＶＲＯ（またはＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７であり、アフターレコーディング音声あるいはバックグランド音声等を含む静止画像情報を集めたファイルがＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８であり、そのアフレコ音声情報ファイルがＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９である。
【００５６】
図３は、この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図である。
【００５７】
図３（ａ）の情報記憶媒体２０１の内周方向２０２の端部と外周方向２０３の端部とで挟まれた領域には、図３（ｂ）に示すように、リードインエリア２０４と、ファイルシステム情報が記録されているボリューム＆ファイル構造情報２０６と、データエリア２０７と、リードアウトエリア２０５が存在する。リードインエリア２０４はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア２０５は書替可能データゾーンで構成されている。データエリア２０７も書替可能データゾーンで構成されている。
【００５８】
データエリア２０７内は、図３（ｃ）に示すように、コンピュータデータとオーディオ＆ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア２０８およびコンピュータデータエリア２０９の間に、オーディオ＆ビデオデータエリア２１０が、挟まれる形態となっている。
【００５９】
オーディオ＆ビデオデータエリア２１０内は、図３（ｄ）に示すように、リアルタイムビデオ記録エリア２２１およびストリーム記録エリア２２２の混在記録が可能となっている。（リアルタイムビデオ記録エリア２２１あるいはストリーム記録エリア２２２の一方だけを使用することも可能である。）
図３（ｅ）に示すように、リアルタイムビデオ記録エリア２２１には、図２に示された、ＲＴＲのナビゲーションデータＲＴＲ．ＩＦＯ（ＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ムービーリアルタイムビデオオブジェクトＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、スチルピクチャリアルタイムビデオオブジェクトＲＴＲ＿ＳＴＯ．ＶＲＯ（ＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、アフターレコーディング等のオーディオオブジェクトＲＴＲ＿ＳＴＡ．ＶＲＯ（ＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが記録される。
【００６０】
同じく図３（ｅ）に示すように、ストリーム記録エリア２２２には、図２に示された、ストリーマのナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、トランスポートビットストリームデータＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＶＲＯ）１０６とが記録される。
【００６１】
なお、図３（ｄ）（ｅ）では図示しないが、ストリーム記録エリア２２２には、図２に示したアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ，ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａを記録することもできる。
【００６２】
このＳＲ＿ＰＲＩＶＴ，ＤＡＴ１０５ａは、ストリーマに接続（供給）された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
【００６３】
ストリームデータに関する管理情報であるＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図３（ｆ）〜（ｉ）に示すようなデータ構造を有している。
【００６４】
すなわち、図３（ｆ）に示すように、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、ビデオマネージャ（ＶＭＧＩまたはＳＴＲ＿ＶＭＧＩ）２３１と、ストリームファイル情報テーブル（ＳＦＩＴ）２３２と、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）２３３と、ユーザ定義ＰＧＣ情報テーブル（ＵＤ＿ＰＧＣＩＴ）２３４と、テキストデータマネージャ（ＴＸＴＤＴ＿ＭＧ）２３５と、製造者情報テーブル（ＭＮＦＩＴ）またはアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ．ＤＡＴ１０５ａを管理するアプリケーションプライベートデータマネージャ（ＡＰＤＴ＿ＭＧ）２３６とで構成されている。
【００６５】
図３（ｆ）のストリームファイル情報テーブル（ＳＦＩＴ）２３２は、図３（ｇ）に示すように、ストリームファイル情報テーブル情報（ＳＦＩＴＩ）２４１と、１以上のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３、………と、オリジナルＰＧＣ情報一般情報２７１と、１以上のオリジナルセル情報＃１・２７２、＃２・２７３………とを含むことができるようになっている。
【００６６】
図３（ｇ）の各ストリームオブジェクト情報（たとえばＳＯＢＩ＃Ａ・２４２）は、図３（ｈ）に示すように、ストリームオブジェクト一般情報（ＳＯＢＩ＿ＧＩ）２５１、タイムマップ情報２５２、その他を含むことができる。
【００６７】
また、図３（ｇ）の各オリジナルセル情報（たとえば＃１・２７２；後述するが図１４で示されるＳＣＩに対応）は、図３（ｈ）に示すように、セルタイプ２８１（後述するが図１４で示されるＣ＿ＴＹに対応）と、セルＩＤ２８２と、該当セル開始時間（後述する図６（ｂ）、図１４その他で示されるＳＣ＿Ｓ＿ＡＰＡＴに対応）２８３と、該当セル終了時間（後述する図６（ｂ）、図１４その他で示されるＳＣ＿Ｅ＿ＡＰＡＴに対応）２８４と、ＰＴＳオフセット９と、時間関係テーブル２とを含むことができる。
【００６８】
ここで、ＰＴＳオフセット９とは、オリジナルセル（オリジナルセルの詳細は後述する）の表示開始ピクチャのＰＴＳ（プレゼンテーションタイムスタンプ）値とその直前にあるＩピクチャのＰＴＳ値との差分をいう（詳細は図２０を参照して後述）。
【００６９】
図３（ｇ）のＳＯＢＩ＃Ａに含まれる図３（ｈ）のタイムマップ情報２５２は、図３（ｉ）に示すように、ストリームブロック番号２６１、第１ストリームブロックサイズ２６２、第１ストリームブロック時間差２６３、第２ストリームブロックサイズ２６４、第２ストリームブロック時間差２６５、………を含むことができる。タイムマップ情報２５２を構成する各ストリームブロック時間差の内容については、図５を参照して後述する。
【００７０】
図４は、この発明の一実施の形態におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図である。以下、図４の例示を用いてＳＯＢとＰＧＣの関係を説明する。
【００７１】
ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯまたはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームデータは、１個以上のＥＣＣブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等がなされる。このストリームデータは、記録する情報の内容毎（たとえばデジタル放送での番組毎）にストリームオブジェクトと言うまとまりを作る。
【００７２】
ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームオブジェクト（ＳＯＢ＃Ａ、ＳＯＢ＃Ｂ）毎の管理情報（オリジナルＰＧＣ情報２３３、ユーザ定義ＰＧＣ情報テーブル２３４等）は、ナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５（図４の最下部および図３（ｅ）（ｆ）参照）内に記録されている。
【００７３】
図４の各ストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９毎の管理情報（ＳＴＲＥＡＭ．ＩＦＯ１０５）は、図３（ｆ）（ｇ）に示すように、ストリームファイル情報テーブル（ＳＦＩＴ）２３２内のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３として記録されている。
【００７４】
ストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、（ＳＯＢＩ）＃Ｂ・２４３それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報２５２を含んでいる。
【００７５】
ストリームデータの再生時には、１個以上のセルの連続で構成されるプログラムチェーン（ＰＧＣ）の情報（後述する図１４のＰＧＣＩ＃ｉに対応）が利用される。このＰＧＣを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
【００７６】
ＰＧＣには、ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６に記録された全ストリームデータを連続して再生することのできるオリジナルＰＧＣ２９０（図３（ｆ）ではＯＲＧ＿ＰＧＣＩ・２３３）と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義ＰＧＣ＃ａ・２９３、＃ｂ・２９６（図３（ｆ）ではＵＤ＿ＰＧＣＩＴ・２３４の中身に対応）の２種類が存在する。
【００７７】
オリジナルＰＧＣ２９０を構成するオリジナルセル＃１・２９１、＃２・２９２は、基本的にストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９と一対一に対応して存在する。
【００７８】
それに対して、ユーザ定義ＰＧＣを構成するユーザ定義セル＃１１・２９４、＃１２・２９５、＃３１・２９７は、１個のストリームオブジェクト＃Ａ・２９８または＃Ｂ・２９９の範囲内では任意の位置を設定することができる。
【００７９】
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図４のストリームブロック＃１のように、２ＥＣＣブロック（３２セクタ）で一定サイズ（６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）を、ストリームブロックとして採用するとよい。
【００８０】
このようにストリームブロックを一定サイズ（たとえば２ＥＣＣブロック＝３２セクタ＝６４ｋバイト）のＳＯＢＵに固定すれば、次の利点が得られる：
（０１）ＳＯＢＵ単位でストリームデータの消去あるいは書替を行っても、そのＳＯＢＵのＥＣＣブロックが、消去あるいは書替対象以外のＳＯＢＵのＥＣＣブロックに影響しない。そのため、消去あるいは書替に伴う（消去あるいは書替の対象でないＳＯＢＵに対する）ＥＣＣのデインターリーブ／インターリーブのやり直しが、生じない；
（０２）任意のＳＯＢＵ内部の記録情報に対するアクセス位置を、セクタ数（あるいはセクタ数に対応した他のパラメータ；たとえば後述する図１０のストリームパックおよびその内部のアプリケーションパケット群の情報）で特定できる。たとえば、あるＳＯＢＵ＃ｋの中間位置にアクセスする場合は、ＳＯＢＵ＃ｋー１とＳＯＢＵ＃ｋとの境界から１６セクタ目（あるいは１６セクタ目に対応するアプリケーションパケットの位置）を指定すればよい。
【００８１】
図５は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図５を用いてタイムマップ情報２５２内の各データの内容について説明する。
【００８２】
図５（ｆ）（ｇ）（ｈ）に例示するように、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１、＃２で構成されている。
【００８３】
図５（ｆ）（ｈ）の例では、ＳＯＢ＃Ａ・２９８を構成するストリームブロック＃１のデータサイズは２ＥＣＣブロック（＃α、＃β）で構成され、３２セクタ分（図５（ｅ）（ｉ））のサイズを持っている。すなわち、タイムマップ情報２５２（図５（ａ）（ｋ））内の第１ストリームブロックサイズ２６２（図５（ｊ））は、３２セクタ（６４ｋバイト）となる。
【００８４】
ＳＯＢ＃Ａ・２９８（図５（ｇ））の先頭にあるストリームブロック＃１（図５（ｆ））はその先頭にセクタＮｏ．０（図５（ｅ））を持ち、セクタＮｏ．０に含まれるデータエリア２１（図５（ｄ））の先頭にはタイムスタンプａ（図５（ｃ））が記録されている。
【００８５】
また、ＳＯＢ＃Ａ・２９８（図５（ｇ））の後続ストリームブロック＃２（図５（ｆ））はその先頭にセクタＮｏ．３２（図５（ｅ））を持ち、セクタＮｏ．３２に含まれるデータエリア３１１（図５（ｄ））の先頭にはタイムスタンプｐ（図５（ｃ））が記録されている。
【００８６】
図５（ｃ）に示すように、ストリームブロック＃１の最初のストリームデータのタイムスタンプ値はタイムスタンプａであり、次のストリームブロック＃２の最初のストリームデータのタイムスタンプ値はタイムスタンプｐとなっている。
【００８７】
図５（ｂ）の第１ストリームブロック時間差２６３（図３（ｉ）のストリームブロック時間差２６３に対応）の値は、上記タイムスタンプｐとタイムスタンプａとの差分値（［タイムスタンプｐ］−［タイムスタンプａ］）で与えられる。
【００８８】
なお、図５（ａ）のタイムマップ情報２５２は、図１５を参照して後述するストリームオブジェクト情報ＳＯＢＩ内のアクセスデータユニットＡＵＤも含むものとして、取り扱うことができる。このＡＵＤに含まれる情報（アクセスユニット開始マップＡＵＳＭ等）により、アクセスしたい情報を含むＳＯＢＵを特定できる。
【００８９】
図６は、オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図である。それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。
【００９０】
具体的には、ストリームデータの録画直後のオリジナルセルにおける該当セルの開始時間２８３および該当セルの終了時間２８４（図６（ｂ））の時間として、該当するストリームオブジェクト＃Ａ・２９８（図６（ｆ））内の最初のタイムスタンプａの値および最後のタイムスタンプｚ（図６（ｃ））の値が使用される。
【００９１】
それに対して、ユーザ定義セル＃１２・２９５（図６（ｋ））での時間範囲指定は、任意時刻を指定できる。たとえば、図６（ｉ）（ｊ）に示すように指定されたトランスポートパケットｄ、ｎに対応したタイムスタンプｄ、ｎの値を、該当セルの開始時間３３１と該当セルの終了時間３３２の値として設定することができる。
【００９２】
図６（ｆ）は、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１および＃２で構成されている場合を例示している。
【００９３】
図６（ｅ）（ｇ）の例では、ストリームブロック＃１は３２セクタ（セクタＮｏ．０〜Ｎｏ．３１）で構成され、ストリームブロック＃２は４８セクタ（セクタＮｏ．３２〜Ｎｏ．７９）で構成されている。
【００９４】
ストリームブロック＃１の先頭セクタＮｏ．０は、図６（ｅ）（ｄ）に示すように、パックヘッダ１、ＰＥＳヘッダ６、ストリームブロックヘッダ１１、データエリア２１等で構成されている。
【００９５】
また、ストリームブロック＃２の後方セクタＮｏ．７８は、図６（ｅ）（ｄ）に示すように、パックヘッダ３、ＰＥＳヘッダ８、セクタデータヘッダ１３、データエリア２４等で構成されている。
【００９６】
さらに、図６（ｇ）のセクタＮｏ．１には図６（ｈ）に示すようにパックヘッダ２、セクタデータヘッダ１２、データエリア２２その他が記録され、図６（ｇ）のセクタＮｏ．３３には図６（ｈ）に示すようにセクタデータヘッダ３２１、データエリア３１２その他が記録されている。
【００９７】
図６（ｄ）（ｈ）のデータエリア２１には、図６（ｃ）（ｉ）に示すように、タイムスタンプａとトランスポートパケットａとのペアないしタイムスタンプｄとトランスポートパケットｄとのペアが記録されている。
【００９８】
また、図６（ｄ）のデータエリア２４の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプｚ＋トランスポートパケットｚのペアの後に続くエンドコード３２と、パディングエリア３７が記録されている。
【００９９】
さらに、図６（ｈ）のデータエリア２２には、図６（ｉ）に示すように、データエリア２１のトランスポートパケットｄの後続内容を含むトランスポートパケットｄが含まれている。つまり、この例では、トランスポートパケットｄの内容が、データエリア２１とデータエリア２２とで分断されて記録されている。
【０１００】
図６（ｉ）のトランスポートパケットｄの前半部分（データエリア２１側）は、後述する図２３（ｆ）の末尾側部分パケットに対応し、図６（ｉ）のトランスポートパケットｄの後半部分（データエリア２２側）は、後述する図２３（ｇ）の先頭側部分パケットに対応している。
【０１０１】
さらに、図６（ｈ）のデータエリア３１２には、図６（ｉ）に示すように、タイムスタンプｎとトランスポートパケットｎとのペアおよびその他の同様なペアが記録されている。
【０１０２】
ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間３３１（図６（ｊ））は、データエリア２１および２２に分断された２つのトランスポートパケットｄ全体に対するタイムスタンプｄ（図６（ｉ））により指定される。
【０１０３】
トランスポートパケットをアプリケーションパケット（ＡＰ）と読み替え、アプリケーションパケット到着時間をＡＰＡＴとした場合に、上記セル開始時間３３１は、セル開始ＡＰＡＴとして表現できる。
【０１０４】
また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間３３２（図６（ｊ））は、データエリア３１２のトランスポートパケットｎに対するタイムスタンプｎ（図６（ｉ））により指定される。このセル終了時間３３２は、セル終了ＡＰＡＴとして表現できる。
【０１０５】
以上のセル開始時間（セル開始ＡＰＡＴ）３３１およびセル終了時間（セル終了ＡＰＡＴ）３３２は、図６（ｋ）に示すように、ユーザ定義セル情報＃１２・２９５内部に記録できる。
【０１０６】
このユーザ定義セル情報＃１２・２９５は、図３（ｆ）または図４下段に示すユーザ定義ＰＧＣ情報テーブル２３４内に記録することができる。
【０１０７】
以上はユーザ定義セル情報（ユーザ定義ＰＧＣの情報）に関するセル開始／終了時間情報についてであるが、オリジナルセル情報（オリジナルセルの情報）に関するセル開始／終了時間情報については、次のような例示ができる。
【０１０８】
すなわち、図６（ｃ）の先頭側タイムスタンプａにより図６（ｂ）の該当セルの開始時間２８３を示すことができ、末尾側タイムスタンプｚにより該当セルの終了時間２８４を示すことができる。
【０１０９】
図６（ｂ）の該当セルの開始時間２８３は、セル開始ＡＰＡＴ（ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）または消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）も含む）に対応させることができる。
【０１１０】
また、図６（ｂ）の該当セルの終了時間２８４は、セル終了ＡＰＡＴ（ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）または消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）も含む）に対応させることができる。
【０１１１】
以上のセル開始時間（セル開始ＡＰＡＴ）２８３およびセル終了時間（セル終了ＡＰＡＴ）２８４は、図６（ａ）に示すように、オリジナルセル情報＃１・２７２内部に記録される。
【０１１２】
このオリジナルセル情報＃１・２７２は、図３（ｆ）または図４下段に示すオリジナルＰＧＣ情報２３３内に記録することができる。
【０１１３】
図７は、この発明の他の実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに再生終了位置情報／レジューム情報、ＶＭＧＩ管理情報／記録時間情報等の構造）を説明する図である。
【０１１４】
図７（ａ）〜（ｆ）のデータ構成は、図３（ａ）〜（ｆ）と同じなので、その説明は省略する。
【０１１５】
図７（ｆ）のビデオマネージャ（ＳＴＲ＿ＶＭＧＩ）２３１は、図７（ｇ）に示すように、再生終了位置情報（レジューム情報）６１１０、ビデオマネージャ管理情報（ＶＭＧＩ＿ＭＡＴ）６１１１その他を含んでいる。
【０１１６】
再生終了位置情報（レジューム情報）６１１０は、図７（ｈ）に示すように、オリジナルＰＧＣ番号６２１０、オリジナルセル番号６２２０、再生終了位置時刻（レジューム時刻）情報６２３０等を含んでいる。
【０１１７】
また、ビデオマネージャ管理情報（ＶＭＧＩ＿ＭＡＴ）６１１１は、タイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０を含んでいる。
【０１１８】
記録済みのストリームブロック（またはオリジナルセル）の再生が終了した段階で、再生終了位置情報６１１０をレジューム情報として図７（ｅ）の管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）内のビデオマネージャ情報２３１中に記録することができる。
【０１１９】
なお、再生終了位置情報６１１０に含まれる時刻情報６２３０はタイムスタンプ（ＡＴＳ）値で記録されているが、それに限らずＰＴＳ値（あるいはセル再生先頭位置からの通算フィールド数）を時刻情報６２３０として記録することもできる。
【０１２０】
タイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０は、図７（ｉ）に示すように、記録時間（ＲＥＣ＿ＴＭ）の情報を含む。
【０１２１】
記録時間（ＲＥＣ＿ＴＭ）の情報は、ＲＥＣ＿ＴＭがユニバーサル・タイム・コオーディネート（ＵＴＣ）によるものか特定のローカルタイムによるものかを識別するタイムゾーンタイプ（ＴＺ＿ＴＹ）と、ＵＴＣからのＲＥＣ＿ＴＭのタイムオフセットの日時を分単位で記述したタイムゾーンオフセット（ＴＺ＿ＯＦＦＳＥＴ）とを含んでいる。
【０１２２】
上記記録時間（ＲＥＣ＿ＴＭ）は、図６（ｂ）等で示したセル開始時間（ＳＣ＿Ｓ＿ＡＰＡＴ）の形式あるいはそのセルの再生時刻（プレゼンテーションタイムＰＴＭ）の形式で記述してもよい。
【０１２３】
この記録時間（ＲＥＣ＿ＴＭ）には２種類ある。第１はストリームオブジェクト記録時間（ＳＯＢ＿ＲＥＣ＿ＴＭ）であり、第２はプレイリスト作成時間（ＰＬ＿ＣＲＥＡＴＥ＿ＴＭ）である。
【０１２４】
ここで、オリジナルセルに対応するストリームオブジェクト（ＳＯＢ）が記録された時間が、ＳＯＢ＿ＲＥＣ＿ＴＭにより示される。
【０１２５】
また、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。このようなプレイリストが作成された時間が、ＰＬ＿ＣＲＥＡＴＥ＿ＴＭにより示される。
【０１２６】
図８は、図１その他に示されたＰＥＳヘッダの内部構造を説明する図である。
【０１２７】
図８（ａ）のＰＥＳヘッダ６０１は、図８（ｂ）に示すように、パケット開始コードプリフィックス６０２、ストリームＩＤ６０３、再生タイムスタンプ６０４等を含んでいる。このＰＥＳヘッダ６０１は、図１（ｆ）、図５（ｄ）、図６（ｄ）等のＰＥＳヘッダに対応している。
【０１２８】
また、図８（ｄ）のストリームＰＥＳヘッダは、図８（ｃ）に示すように、パケット開始コードプリフィックス、ストリームＩＤ（プライベートストリーム２）、ＰＥＳパケット長、サブストリームＩＤ等を含んでいる。このストリームＰＥＳヘッダは、後述する図２２のストリームＰＥＳヘッダと同じもので、図８（ａ）のＰＥＳヘッダ６０１に対応する内容を持つ。
【０１２９】
図１（ｆ）のＰＥＳヘッダが図８（ａ）に示すＰＥＳヘッダ６０１の内部構造を持つときは、ＭＰＥＧの規格では、このＰＥＳヘッダのストリームＩＤ６０３（図８（ｂ））が”１０１１１１１０”のときに、このＰＥＳヘッダを持つパケットを、パディングパケット（後述する図１２（ｇ）参照）にすると定義されている。
【０１３０】
一方、ストリームＩＤ６０３（図８（ｃ）のサブストリームＩＤ）が”００００００１０”のときは、そのＰＥＳパケットの付いたパケットは、ストリーム記録データを含むことになる。
【０１３１】
図１（ｃ）のストリームブロック＃１では、最後のトランスポートパケットｇ（図１（ｇ））がセクタＮｏ．０〜Ｎｏ．３１（図１（ｅ））内に存在している。しかし、ストリームブロック＃２（図１（ｅ）（ｇ））では、ユーザ等により途中で録画が終了されると、最後のトランスポートパケット（図示せず）が最後のセクタより前のセクタに配置され、最後のセクタ（図示せず）内はストリームデータが記録されていない空き領域となることがある。この場合、最後のセクタには、上記パディングパケット（後述する図１２（ｇ）のパディングパケット４０）が記録される。
【０１３２】
図９は、図１に示されたストリームブロックヘッダの内部構造を説明する図である。
【０１３３】
ストリームブロックヘッダ１１は、図９（ａ）に示すように、サブストリームＩＤ、アプリケーションヘッダ、アプリケーションヘッダエクステンション、スタッフィングバイト等に対応した内容を持つ。
【０１３４】
１バイトのアプリケーションヘッダエクステンション（オプション）には、１ビットのＡＵ＿ＳＴＡＲＴと、１ビットのＡＵ＿ＥＮＤと、２ビットのＣＯＰＹＲＩＧＨＴとが、記述される。
【０１３５】
ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連するアプリケーションパケット（たとえば図２９のＡＰ）が、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。
【０１３６】
ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【０１３７】
ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。
【０１３８】
ストリームブロックヘッダ１１は、図９（ｂ）に示すように、トランスポートパケット情報６１１、ストリームブロック情報６１２、セクタデータヘッダ情報６１３等を含んでいる。
【０１３９】
図９（ｂ）のトランスポートパケット情報６１１は図９（ｃ）のトランスポートパケット情報６１１と同じものを指す。
【０１４０】
ストリームブロック全体に関する情報が記録されている図９（ｂ）のストリームブロック情報６１２は、図９（ｃ）の記録時間６２２（情報記憶媒体２０１に記録した年月日と時刻情報）、トランスポートパケット属性６２３（トランスポートパケットに関する属性情報）、ストリームブロックサイズ６２４（該当するストリームブロックのデータサイズ（たとえばＥＣＣブロック数で記載できる））、ストリームブロック時間差６２５等に対応する。
【０１４１】
ここで、図５（ｂ）を例にとれば、該当ストリームブロック内の時間範囲情報は、［ストリームブロック時間差］＝［ストリームブロック＃２内の最初にくるタイムスタンプ値］−［タイムスタンプａの値］として計算される。この［ストリームブロック時間差］が、ストリームブロック時間差６２５となる。
【０１４２】
また、図９（ｂ）のセクタデータヘッダ情報６１３は、図９（ｃ）のファーストアクセスポイント６２６およびトランスポートパケット接続フラグ６２７に対応する。このセクタデータヘッダ情報６１３は、後述する図１０のセクタデータヘッダ１２と同様な情報を含んでいる。
【０１４３】
図９（ｃ）のトランスポートパケット情報６１１は、図９（ｄ）に示すように、トランスポートパケットの数（アプリケーションパケットの数）６３１、トランスポートパケットマッピングテーブル６３２等を含んでいる。
【０１４４】
なお、図９（ｄ）のアプリケーションパケットの数は、後述する図１０（ｃ）または図１１のパケット数ＡＰ＿Ｎｓに対応している。
【０１４５】
図９（ｄ）のトランスポートパケット（アプリケーションパケット）の数６３１は、図９（ｅ）に示すように、Ｉピクチャマッピングテーブル６４１、Ｂ，Ｐピクチャマッピングテーブル６４２等を含むことができる。
【０１４６】
また、図９（ｄ）のトランスポートパケットマッピングテーブル６３２は、ビデオパケットマッピングテーブル６４３、オーディオパケットマッピングテーブル６４４、プログラム固有情報マッピングテーブル６４５等を含むことができる。
【０１４７】
トランスポートパケットマッピングテーブル６３２内の各マッピングテーブル（図９（ｅ））は、ビットマップ形式で構成されている。
【０１４８】
たとえば、１個のストリームブロック内にｎ個のトランスポートパケット（アプリケーションパケット）が記録されている場合には、図９（ｄ）のトランスポートパケット数（アプリケーションパケット数）６３１の値は”ｎ”となる。
【０１４９】
さらに、各マッピングテーブル６４３〜６４５は”ｎビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット（アプリケーションパケット）に対してそれぞれ１ビットずつが割り当てられている。
【０１５０】
図１０は、図１に示されたセクタデータヘッダの内部構造を説明する図である。
【０１５１】
たとえば図１（ｆ）のセクタデータヘッダ１７は、データエリア２２、２３内のデータ配列情報を示すもので、図１０（ａ）のセクタデータヘッダ（図１０（ｄ）のアプリケーションヘッダに対応）１２に相当する。
【０１５２】
セクタデータヘッダ１２は、図１０（ｂ）に示すように、ファーストアクセスポイント６５１およびトランスポートパケット接続フラグ６５２を含む内部構造を持っている。
【０１５３】
ところで、図１０（ｄ）に示すように、１セクタと同じく２０４８バイトのサイズを持つ１つのストリームパックは、パックヘッダおよびストリームＰＥＳヘッダで構成されている。そして、このストリームＰＥＳパケット内に、図１０（ａ）のセクタデータヘッダ１２あるいは図９（ａ）のストリームブロックヘッダ１１の一部に対応した、アプリケーションパケットヘッダが含まれている。
【０１５４】
このアプリケーションパケットヘッダは、図１０（ｃ）に示すように、以下のものを含んでいる：
＊アプリケーションパケットヘッダ形式のバージョン記載；
＊該当ストリームパック内で開始するアプリケーションパケット（トランスポートパケット）の数ＡＰ＿Ｎｓ；
＊該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ；
＊ヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ；
＊該当ストリームを生成したサービスの識別子ＳＥＲＶＩＣＥ＿ＩＤ。
【０１５５】
上記図１０（ｄ）のアプリケーションパケットに含まれるＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴは、図１０（ａ）のセクタデータヘッダ１２に含まれるファーストアクセスポイント６５１に対応する。
【０１５６】
図１（ｇ）に示すように、トランスポートパケットｄは２個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ６５２が”１”に設定される。
【０１５７】
また図１（ｇ）の例では、次のセクタへ跨ったトランスポートパケットｄの次にくるタイムスタンプ先頭位置のデータエリア２２内のアドレスが、ファーストアクセスポイント６５１内に記録（ビット単位の表現）されている。
【０１５８】
図１（ｅ）に示すセクタＮｏ．１（またはその対応ストリームパック）のファーストアクセスポイント値を、セクタＮｏ．１のデータエリア２２（図１（ｆ））のサイズよりも大きな値に設定することができる。そうすることにより、セクタＮｏ．１内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。
【０１５９】
この発明の一実施の形態では、ファーストアクセスポイント６５１の値としてデータエリア２１、２２、２３のサイズよりも大きな値を指定可能にすることで、セクタサイズ（あるいはストリームパックサイズ＝２０４８バイト）よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。
【０１６０】
たとえば、図１のデータ構造において、１個のパケットがセクタＮｏ．０からセクタＮｏ．２まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタＮｏ．０のデータエリア２１内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタＮｏ．２のデータエリア内のＴビット目に配置されている場合を考える。
【０１６１】
この場合、セクタＮｏ．０のファーストアクセスポイントの値は”０”、セクタＮｏ．１のファーストアクセスポイントの値は”セクタＮｏ．１のデータエリア２２サイズ＋Ｔ”、セクタＮｏ．２のファーストアクセスポイントの値は”Ｔ”となる。
【０１６２】
図１１は、この発明の一実施の形態におけるタイムマップ情報２５２の他例を説明する図である。
【０１６３】
このタイムマップ情報２５２は、図３（ｈ）（ｉ）のタイムマップ情報２５２とは別の例であり、各ストリームブロック（最初のストリームブロック、２番目のストリームブロック、…）毎に、ストリームブロックサイズとストリームブロック時間差とパケット数（ＡＰ＿Ｎｓ）とを記述したテーブル情報である。
【０１６４】
図１１のタイムマップ情報２５２を用い、所定の画面（ピクチャ）にアクセスするため（ＳＴＢ側から）通算トランスポートパケット数（または通算アプリケーションパケット数ＡＰ＿Ｎｓ）が指定されたとする。すると、（ディスク装置側は）図１１の最初のストリームブロックから順次トランスポートパケット数（ＡＰ＿Ｎｓ）を加算して行き、指定された値に達した時点でのストリームブロックへアクセスする。
【０１６５】
図１２は、ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図である。
【０１６６】
図１２（ｄ）のストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は、図１２（ｃ）（ｅ）に示すように、複数のストリームブロック＃１、＃２、…で構成されている。
【０１６７】
各ストリームブロック＃１、＃２、…は全て、２ＥＣＣブロックサイズ（＝３２セクタ＝６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）で構成される。
【０１６８】
このようにすると、たとえばストリームブロック（ＳＯＢＵ）＃２を削除しても、ストリームブロック（ＳＯＢＵ）＃１のＥＣＣブロックはこの削除に影響されない。
【０１６９】
ＳＯＢ＃Ａ・２９８の先頭ストリームブロック（ＳＯＢＵ）＃１は、図１２（ｂ）に示すように、セクタＮｏ．０〜セクタＮｏ．３１（３２セクタ／６４ｋバイト）で構成されている。
【０１７０】
ストリームブロック（ＳＯＢＵ）＃１の各セクタは、同様なデータ構造を持っている。、たとえばセクタＮｏ．０についていうと、図１２（ａ）に示すようになっている。
【０１７１】
すなわち、セクタＮｏ．０は２０４８バイト（２ｋバイト）のストリームパックにより構成される。このストリームパックは、１４バイトのパックヘッダと、２０３４バイトのストリームＰＥＳパケットとで構成される。
【０１７２】
ストリームＰＥＳパケットは、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、２０２７バイトのストリームデータエリアとで構成される。
【０１７３】
ストリームデータエリアは、９バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、アプリケーションパケットエリアとで構成される。
【０１７４】
アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ（ＡＴＳ）を先頭に持つアプリケーションパケット群で構成される。
【０１７５】
たとえば１８８バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、１０個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
【０１７６】
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ（たとえば２０４８バイト）を持つものとして扱うことができる。
【０１７７】
図１２（ａ）のスタッフィングバイトは、ストリームパックを常に所定長（２０４８バイト）に保つために利用できる。
【０１７８】
図１２（ａ）のパックヘッダは、図示しないが、パック開始コードの情報、ＳＣＲベースの情報、ＳＣＲエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。
【０１７９】
ＳＣＲベースは３２ビットで構成され、その３２ビット目はゼロとされる。また、プログラム最大レートとしては、１０．０８Ｍｂｐｓが採用される。
【０１８０】
図１２（ａ）のＰＥＳヘッダおよびサブストリームＩＤは、図８（ｃ）に示したような内容を持っている。
【０１８１】
図１２（ａ）のアプリケーションヘッダは、図１０（ｃ）に示したように、バージョン情報、アプリケーションパケット数ＡＰ＿Ｎｓ、先頭アプリケーションパケットのタイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ、エクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ、サービスＩＤ等を含んでいる。
【０１８２】
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
【０１８３】
アプリケーションヘッダのＡＰ＿Ｎｓは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にＡＴＳの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
【０１８４】
ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには「０」が記述される。
【０１８５】
ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かが、記述される。
【０１８６】
ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が００ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
【０１８７】
ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１０ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
【０１８８】
ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１１ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
【０１８９】
ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が０１ｂとなることは禁止されている。
【０１９０】
アプリケーションパケットエリアの前のスタッフィングバイト（オプション）は、「ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯ＝１１ｂ」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
【０１９１】
ＳＥＲＶＩＣＥ＿ＩＤには、ストリームを生成するサービスのＩＤが記述される。このサービスが未知のものであれば、ＳＥＲＶＩＣＥ＿ＩＤに０ｘ００００が記述される。
【０１９２】
図１２（ａ）のアプリケーションパケットエリアは、後述する図２２の下段に示したと同様に構成できる（図２２のパケットを図１２ではアプリケーションパケットに読み替える）。
【０１９３】
すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。
【０１９４】
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
【０１９５】
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ（ＡＴＳ）は３２ビット（４バイト）で構成される。このＡＴＳは、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。
【０１９６】
図１２（ａ）において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。
【０１９７】
それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを（前述したＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯにおいて）記述できるように定義されいる。
【０１９８】
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプＡＴＳの先頭バイトは、ストリームオブジェクトＳＯＢの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
【０１９９】
一方、ＳＯＢ内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割（スプリット）されてもよい。
【０２００】
後述する図２２あるいは図２３（ｆ）（ｇ）に示した部分アプリケーションパケットは、この分割（スプリット）により生じたアプリケーションパケットを示している。
【０２０１】
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。
【０２０２】
こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
【０２０３】
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
【０２０４】
アプリケーションヘッダエクステンション（オプション）はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する１バイト長の１エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
【０２０５】
なお、１バイトのアプリケーションヘッダエクステンション（オプション）には、１ビットのＡＵ＿ＳＴＡＲＴと、１ビットのＡＵ＿ＥＮＤと、２ビットのＣＯＰＹＲＩＧＨＴとが、記述される。
【０２０６】
ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。
【０２０７】
ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【０２０８】
ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。
【０２０９】
図１２（ａ）のパケット構造は、ＳＯＢ＃Ａ・２９８の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。
【０２１０】
たとえば、ＳＯＢ＃Ａ・２９８の末尾が図１２（ｆ）のセクタＮｏ．６３であり、このセクタが図１２（ｇ）に示すようにパディングパケット４０で構成されるときは、そのパディングエリア３８（図１２（ｈ））の内容が、図１２（ａ）と違ったものになる。
【０２１１】
すなわち、図１２（ｉ）に示すように、パディングパケット４０としてのスタッフィングパケットは、１４バイトのパックヘッダと、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、９バイトのアプリケーションヘッダと、２０１８バイトのアプリケーションパケットエリアとで構成される。
【０２１２】
スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、４バイトのアプリケーションタイムスタンプＡＴＳおよび２０１４バイト分のゼロバイトデータ（実質的な記録内容を持たないデータ）で構成される。
【０２１３】
一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、２０１８バイト分のゼロバイトデータ（ＡＴＳなし）で構成される。
【０２１４】
ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報（図３（ｈ）の２５２；あるいは後述する図１５のＳＯＢＩ内ＭＡＰＬ）の回復（再生）を確実にするために、スタッフィングが必要になる。図１２（ｉ）のスタッフィングパケットは、そのための概念的な単位として定義されている。
【０２１５】
このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のＳＯＢＵが少なくとも１つのＡＴＳ値を含むようにすることで、達成される。
【０２１６】
スタッフィングパケットには、以下の条件が付く：
＊１または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する；
＊１または複数のスタッフィングパケットは、１つの４バイトＡＴＳと、該当ＳＯＢＵの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ（ＡＴＳの後に続く）とで構成される。いま、ＳＯＢＵ１個あたりのセクタ数をＳＯＢＵ＿ＳＩＺとしたときに、０≦ｎ≦ＳＯＢＵ＿ＳＩＺー１とすれば、スタッフィングパケットの全長は、「４＋２０１４＋ｎ×２０１８」バイトとなる。
【０２１７】
スタッフィングパケットのＡＴＳは、次のように設定される：
＊少なくとも１個のパックが実際のアプリケーションパケットデータを含んでいるＳＯＢＵ内では、スタッフィングパケットのＡＴＳは、スタッフィングパケットに先行するアプリケーションパケットのＡＴＳに設定される；
＊実際のアプリケーションパケットデータを含まないＳＯＢＵ内では、スタッフィングパケットのＡＴＳはタイムマップ情報等の内容に応じて決定される。
【０２１８】
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される：
＊パックヘッダのＳＣＲは、先行パックのＳＣＲに「２０４８×８ビット÷１０．０８Ｍｂｐｓ」を加えたものとする；
＊ＰＥＳパケットヘッダおよびサブストリームＩＤは、他の全てのＰＥＳパケットに対するものと同じにする；
＊アプリケーションヘッダ（図１０（ｃ）（ｄ）参照）内において、ＡＰ＿Ｎｓ＝０、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ＝０、ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ＝００ｂ、ＳＥＲＶＩＣＥ＿ＩＤ＝０（アプリケーションヘッダ内のその他のパラメータも０）とする。
【０２１９】
図１３は、ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図である。
【０２２０】
図２あるいは図３（ｅ）に示した管理情報（ナビゲーションデータ）であるＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図１３に示すように、ストリーマ情報ＳＴＲＩを含んでいる。
【０２２１】
このストリーマ情報ＳＴＲＩは、図３（ｆ）あるいは図１３に示すように、ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩと、ストリームファイル情報テーブルＳＦＩＴと、オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩ（より一般的に表現すればＰＧＣ情報ＰＧＣＩ＃ｉ）と、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴと、テキストデータマネージャＴＸＴＤＴ＿ＭＧと、アプリケーションプライベートデータマネージャＡＰＤＴ＿ＭＧとで、構成されている。
【０２２２】
ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩは、図１３に示すように、ＳＴＲＩ、ＳＴＲ＿ＶＭＧＩに関する管理情報等が記述されたビデオマネージャ情報管理情報ＶＴＳＩ＿ＭＡＴと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）とを含んでいる。
【０２２３】
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。
【０２２４】
ストリームファイル情報テーブルＳＦＩＴは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルＳＦＩＴの詳細については、図１５を参照して後述する。
【０２２５】
オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）に関する情報を記述した部分である。ＯＲＧ＿ＰＧＣはプログラムセットを記述したナビゲーションデータを示す。ＯＲＧ＿ＰＧＣはプログラムの連なり（チェーン）であり、図２または後述する図１８の「．ＳＲＯ」ファイル（図２ではＳＲ＿ＴＲＡＮＳ．ＳＲＯ１０６）内に記録されたストリームデータを含む。
【０２２６】
ここで、プログラムセットとは、情報記憶媒体２０１の記録内容全体（全てのプログラム）を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）と呼ばれるデータ構造に対応している。
【０２２７】
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、１以上のオリジナルセルにより構成される。プログラムはオリジナルＰＧＣ内でのみ定義されるものである。
【０２２８】
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義ＰＧＣ内のセルは「ユーザ定義セル」と呼ばれる。
【０２２９】
プログラムセット内の各々のプログラムは、少なくとも１個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも１個のユーザ定義セルで構成される。
【０２３０】
一方、ストリーマでは、ストリームセル（ＳＣ）だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
【０２３１】
なお、プログラムチェーン（ＰＧＣ）とは、上位概念的な単位を示す。オリジナルＰＧＣでは、ＰＧＣはプログラムセットに対応したプログラムの連なり（チェーン）を指す。また、ユーザ定義ＰＧＣでは、ＰＧＣはプレイリストに対応するプログラムの一部の連なり（チェーン）を指す。
【０２３２】
また、プログラムの一部のチェーンを指すユーザ定義ＰＧＣは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルＰＧＣに属するストリームデータを参照するようになっている。
【０２３３】
図１３のユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴは、ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩと、１以上のユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰ＃ｎと、１以上のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩ＃ｎとを含むことができる。
【０２３４】
ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩは、図示しないが、ユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰの数を示すＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓと、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴの終了アドレスを示すＵＤ＿ＰＧＣＩＴ＿ＥＡとを含む。
【０２３５】
ＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓが示すＵＤ＿ＰＧＣ＿ＳＲＰの数は、ユーザ定義ＰＧＣ情報（ＵＤ＿ＰＧＣＩ）の数と同じであり、ユーザ定義ＰＧＣ（ＵＤ＿ＰＧＣ）の数とも同じである。この数は、最大「９９」まで許されている。
【０２３６】
ＵＤ＿ＰＧＣＩＴ＿ＥＡは、該当ＵＤ＿ＰＧＣＩＴの終了アドレスを、そのＵＤ＿ＰＧＣＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述したものである。
【０２３７】
ここで、Ｆ＿ＲＢＮとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
【０２３８】
オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したＰＧＣＩ＃ｉについては、図１４を参照して後述する。
【０２３９】
図１３のテキストデータマネージャＴＸＴＤＴ＿ＭＧは、補足的なテキスト情報である。このＴＸＴＤＴ＿ＭＧは、図１４のプライマリテキスト情報ＰＲＭ＿ＴＸＴＩとともに、プレイリストおよびプログラム内に格納できる。
【０２４０】
図１３のアプリケーションプライベートデータマネージャＡＰＤＴ＿Ｍは、図示しないが、アプリケーションプライベートデータマネージャ一般情報ＡＰＤＴ＿ＧＩと、１以上のＡＰＤＴサーチポインタＡＰＤＴ＿ＳＲＰ＃ｎと、１以上のＡＰＤＴエリアＡＰＡＤＴＡ＃ｎとを含むことができる。
【０２４１】
ここで、アプリケーションプライベートデータＡＰＤＴとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報（リアルタイムストリームデータに加えさらに望まれる情報）を格納できるような概念上のエリアである。
【０２４２】
図１４は、ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１３のＰＧＣＩ＃ｉ）の内部データ構造を説明する図である。
【０２４３】
図１４のＰＧＣ情報ＰＧＣＩ＃ｉは、図１３のオリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したものである。
【０２４４】
図１４に示すように、ＰＧＣ情報ＰＧＣＩ＃ｉは、ＰＧＣ一般情報ＰＧＣ＿ＧＩと、１以上のプログラム情報ＰＧＩ＃ｍと、１以上のストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ＃ｎと、１以上のストリームセル情報ＳＣＩ＃ｎとで構成されている。
【０２４５】
ＰＧＣ一般情報ＰＧＣ＿ＧＩは、プログラムの数ＰＧ＿Ｎｓと、ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰの数ＳＣＩ＿ＳＲＰ＿Ｎｓとを含んでいる。
【０２４６】
各プログラム情報ＰＧＩ（たとえばＰＧＩ＃１）は、プログラムタイプＰＧ＿ＴＹと、該当プログラム内のセルの数Ｃ＿Ｎｓと、該当プログラムのプライマリテキスト情報ＰＲＭ＿ＴＸＴＩと、アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮとを含んでいる。
【０２４７】
ここで、プログラムタイプＰＧ＿ＴＹは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
【０２４８】
このプロテクトフラグが「０ｂ」のときは該当プログラムは保護されておらず、「１ｂ」のときは保護された状態にある。
【０２４９】
セルの数Ｃ＿Ｎｓは、該当プログラム内のセルの数を示す。ＰＧＣの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに（暗黙のうちに）付随している。
【０２５０】
たとえば、ＰＧＣ内でプログラム＃１がＣ＿Ｎｓ＝１を持ち、プログラム＃２がＣ＿Ｎｓ＝２を持つとすれば、そのＰＧＣの最初のストリームセル情報ＳＣＩはプログラム＃１に付随するものとなり、第２、第３のＳＣＩはプログラム＃２に付随するものとなる。
【０２５１】
プライマリテキスト情報ＰＲＭ＿ＴＸＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１を世界中で利用可能とするために、１つの共通キャラクタセット（ＩＳＯ／ＩＥＣ６４６：１９８３（ＡＳＣＩＩコード））を持ったテキスト情報を記述したものである。
【０２５２】
アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮは、アイテムテキスト（該当プログラムに対応するテキストデータ）ＩＴ＿ＴＸＴに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、ＩＴ＿ＴＸＴ＿ＳＲＰＮは「００００ｈ」にセットされる。
【０２５３】
各ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ（たとえばＳＣＩ＿ＳＲＰ＃１）は、対応ストリームセル情報ＳＣＩの開始アドレスを示すＳＣＩ＿ＳＡを含んでいる。このＳＣＩ＿ＳＡは、ＰＧＣＩの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述される。
【０２５４】
各ストリームセル情報ＳＣＩ（たとえばＳＣＩ＃１）は、ストリームセル一般情報ＳＣ＿ＧＩと、１以上のストリームセルエントリポイント情報ＳＣ＿ＥＰＩ＃ｎとで構成される。
【０２５５】
ストリームセル一般情報ＳＣ＿ＧＩは、仮消去（テンポラリイレーズ；ＴＥ）状態を示すフラグＴＥを含むセルタイプＣ＿ＴＹと、ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓと、ストリームオブジェクト番号ＳＯＢ＿Ｎと、ストリームセル開始ＡＰＡＴ（図６他で示したＳＣ＿Ｓ＿ＡＰＡＴ）と、ストリームセル終了ＡＰＡＴ（図６他で示したＳＣ＿Ｅ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝１０ｂ）にあるときにその仮消去セルの開始ＡＰＡＴを示す消去開始ＡＰＡＴ（図６他で示したＥＲＡ＿Ｓ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝１０ｂ）にあるときにその仮消去セルの終了ＡＰＡＴを示す消去終了ＡＰＡＴ（図６他で示したＥＲＡ＿Ｅ＿ＡＰＡＴ）とを含んでいる。
【０２５６】
セルタイプＣ＿ＴＹは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
【０２５７】
すなわち、セルの形式Ｃ＿ＴＹ１＝「０１０ｂ」は全てのストリームセルの形式に記述される（このＣ＿ＴＹ１＝「０１０ｂ」によりストリームセルとそれ以外のセルの区別ができる）。
【０２５８】
一方、フラグＴＥが「００ｂ」であれば該当セルは通常の状態にあることが示され、フラグＴＥが「０１ｂ」あるいは「１０ｂ」であれば該当セルは仮消去の状態にあることが示される。
【０２５９】
フラグＴＥ＝「０１ｂ」は、該当セル（仮消去状態にあるセル）が、ＳＯＢＵ内で開始する最初のアプリケーションパケットの後から開始し、同じＳＯＢＵ内の最終アプリケーションパケットの前で終了する場合を示す。
【０２６０】
また、フラグＴＥ＝「１０ｂ」は、該当セル（仮消去状態にあるセル）が、少なくとも１つのＳＯＢＵ境界（先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのＳＯＢＵ内で開始する）を含む場合を示す。
【０２６１】
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのＴＥフラグとは、同時に設定できないようになっている。それゆえ、
（ａ）プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず；
（ｂ）仮消去状態にあるセルを１以上含むプログラムはプロテクト状態に設定できない。
【０２６２】
ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓは、該当ストリームセル情報ＳＣＩ内に含まれるストリームセルエントリポイント情報の数を記述したものである。
【０２６３】
図１４の各ストリームセルエントリポイント情報ＳＣ＿ＥＰＩ（たとえばＳＣ＿ＥＰＩ＃１）は、２種類（タイプＡとタイプＢ）存在する。
【０２６４】
タイプＡのＳＣ＿ＥＰＩは、エントリポイントタイプＥＰ＿ＴＹとエントリポイントのアプリケーションパケット到着時間ＥＰ＿ＡＰＡＴとを含む。タイプＡは、エントリポイントタイプＥＰ＿ＴＹ１＝「００ｂ」により示される。
【０２６５】
タイプＢのＳＣ＿ＥＰＩは、タイプＡのＥＰ＿ＴＹおよびＥＰ＿ＡＰＡＴの他に、プライマリテキスト情報ＰＲＭ＿ＴＸＴＩを含む。タイプＢは、エントリポイントタイプＥＰ＿ＴＹ１＝「０１ｂ」により示される。
【０２６６】
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間（ＡＰＡＴ）により特定できる。このＡＰＡＴにより、どこからデータ出力が開始されるのかを特定できる。
【０２６７】
ストリームオブジェクト番号ＳＯＢ＿Ｎは、該当セルが参照するＳＯＢの番号を記述したものである。
【０２６８】
ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当セルの開始ＡＰＡＴを記述したものである。
【０２６９】
ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当セルの終了ＡＰＡＴを記述したものである。
【０２７０】
消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、この仮消去セルに先頭が含まれる最初のＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。
【０２７１】
消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、仮消去セルのすぐ後に続くアプリケーションパケットを含むＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。
【０２７２】
図１５は、ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図である。
【０２７３】
図１５に示すように、ストリームファイル情報テーブルＳＦＩＴは、ストリームファイル情報テーブル情報ＳＦＩＴＩと、１以上のストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ＃ｎと、ストリームファイル情報ＳＦＩとで構成される。
【０２７４】
ストリームファイル情報テーブル情報ＳＦＩＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１上のストリームファイル情報の数ＳＦＩ＿Ｎｓと、ＳＦＩＴＩに続くストリームオブジェクトストリーム情報の数ＳＯＢ＿ＳＴＩ＿Ｎｓと、ＳＦＩＴの終了アドレスＳＦＩＴ＿ＥＡと、ＳＦＩの開始アドレスＳＦＩ＿ＳＡとで構成される。
【０２７５】
ＳＦＩＴ＿ＥＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩＴの終了アドレスを記述したものである。
【０２７６】
また、ＳＦＩ＿ＳＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩの開始アドレスを記述したものである。
【０２７７】
各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩは、３種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、ＳＯＢ＿ＳＴＩは、ストリームオブジェクト情報（ＳＯＢＩ）のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト（ＳＯＢ）が同じＳＯＢ＿ＳＴＩを共有する（つまり同じＳＯＢ＿ＳＴＩをポイントする）ことが認められている。したがって、通常は、ＳＯＢの数よりもＳＯＢ＿ＳＴＩの数の方が少なくなる。
【０２７８】
図１５の各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ（たとえばＳＯＢ＿ＳＴＩ＃１）は、アプリケーションパケットサイズＡＰ＿ＳＩＺと、サービスＩＤの数ＳＥＲＶ＿ＩＤ＿Ｎｓと、サービスＩＤ（ＳＥＲＶ＿ＩＤｓ）と、アプリケーションパケットデバイスユニークＩＤ（ＡＰ＿ＤＥＶ＿ＵＩＤ）とを含んでいる。
【０２７９】
ＡＰ＿ＳＩＺは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
【０２８０】
なお、ＤＶＤストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト（現ＳＯＢ）はそこで終了され、新たなストリームオブジェクト（新ＳＯＢ）が、新たなＡＰ＿ＳＩＺを伴って開始される。その際、現ＳＯＢおよび新ＳＯＢの双方は、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）内の同じプログラムに属するものとなる。
【０２８１】
ＳＥＲＶ＿ＩＤ＿Ｎｓは、後続パラメータに含まれるサービスＩＤの数を記述したものである。
【０２８２】
ＳＥＲＶ＿ＩＤｓは、サービスＩＤのリストを任意の順序で記述したものである。
【０２８３】
ＡＰ＿ＤＥＶ＿ＵＩＤは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスＩＤを記述したものである。
【０２８４】
ストリームファイル情報ＳＦＩは、図１５に示すように、ストリームファイル一般情報ＳＦ＿ＧＩと、１以上のストリームオブジェクト情報（ＳＯＢ情報）サーチポインタ（ＳＯＢＩ＿ＳＲＰ）＃ｎと、１以上のＳＯＢ情報（ＳＯＢＩ）＃ｎとで構成されている。
【０２８５】
ストリームファイル一般情報ＳＦ＿ＧＩは、ＳＯＢＩの数ＳＯＢＩ＿Ｎｓと、ＳＯＢＵ１個あたりのセクタ数ＳＯＢＵ＿ＳＩＺと、タイムマップ情報の一種であるＭＴＵ＿ＳＨＦＴとを含んでいる。
【０２８６】
ここで、ＳＯＢＵ＿ＳＩＺは、ＳＯＢＵのサイズをセクタ数で記述したもので、このサイズは３２（３２セクタ＝６４ｋバイト）で一定となっている。このことは、各タイムマップ情報（ＭＡＰＬ）内において、最初のエントリが、ＳＯＢの最初の３２セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、２番目のエントリは、次の３２セクタに含まれるアプリケーションパケットに関係する。３番目以降のエントリについても以下同様である。
【０２８７】
各ＳＯＢ情報サーチポインタ（たとえばＳＯＢＩ＿ＳＲＰ＃１）は、ＳＯＢＩの開始アドレスＳＯＢＩ＿ＳＡを含んでいる。このＳＯＢＩ＿ＳＡは、ストリームファイル情報ＳＦＩの先頭バイトから相対バイト数（Ｆ＿ＲＢＮ）でもって関連ＳＯＢＩの開始アドレスを記述したものである。
【０２８８】
各ＳＯＢ情報（たとえばＳＯＢＩ＃１）は、ストリームオブジェクト一般情報ＳＯＢ＿ＧＩと、タイムマップ情報ＭＡＰＬと、アクセスユニットデータＡＵＤ（オプション）とで構成される。
【０２８９】
ストリームオブジェクト一般情報ＳＯＢ＿ＧＩは、ストリームオブジェクトのタイプＳＯＢ＿ＴＹと、ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭと、ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎと、アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳと、ストリームオブジェクトの開始アプリケーションパケット到着時間ＳＯＢ＿Ｓ＿ＡＰＡＴと、ストリームオブジェクトの終了アプリケーションパケット到着時間ＳＯＢ＿Ｅ＿ＡＰＡＴと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットＳＯＢ＿Ｓ＿ＳＯＢＵと、タイムマップ情報のエントリ数ＭＡＰＬ＿ＥＮＴ＿Ｎｓとを含んでいる。
【０２９０】
ストリームオブジェクトのタイプＳＯＢ＿ＴＹは、仮消去状態（ＴＥ状態）を示すビットおよび／またはコピー世代管理システムのビットを記述できる部分である。
【０２９１】
ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭは、関連ストリームオブジェクト（ＳＯＢ）の記録時間を記述したものである。
【０２９２】
ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎは、該当ストリームオブジェクトに対して有効なＳＯＢ＿ＳＴＩのインデックスを記述したものである。
【０２９３】
アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳは、該当ストリームオブジェクトに対してアクセスユニットデータ（ＡＵＤ）が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
【０２９４】
アクセスユニットデータ（ＡＵＤ）が存在する場合は、ＡＵＤ＿ＦＬＡＧＳにより、ＡＵＤの幾つかの特性が記述される。
【０２９５】
アクセスユニットデータ（ＡＵＤ）自体は、図１５に示すように、アクセスユニット一般情報ＡＵ＿ＧＩと、アクセスユニットエンドマップＡＵＥＭと、再生タイムスタンプリストＰＴＳＬとで構成される。
【０２９６】
アクセスユニット一般情報ＡＵ＿ＧＩは、該当ＳＯＢに対して記述されたアクセスユニットの数を示すＡＵ＿Ｎｓと、該当ＳＯＢに属するＳＯＢＵのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップＡＵＳＭとを含んでいる。
【０２９７】
アクセスユニットエンドマップＡＵＥＭは、（もし存在するときは）ＡＵＳＭと同じ長さのビットアレイであり、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの終端をどのＳＯＢＵが含むのかを示す。
【０２９８】
再生タイムスタンプリストＰＴＳＬは、該当ＳＯＢに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる１つのＰＴＳＬエレメントは、対応アクセスユニットの再生タイムスタンプ（ＰＴＳ）の値を含む。
【０２９９】
なお、アクセスユニット（ＡＵ）とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、ＭＰＥＧのＩピクチャに対応する部分となる。
【０３００】
ここで再びＳＯＢ＿ＧＩの内容説明に戻る。
【０３０１】
ＡＵＤ＿ＦＬＡＧＳは、フラグＲＴＡＵ＿ＦＬＧと、フラグＡＵＤ＿ＦＬＧと、フラグＡＵＥＭ＿ＦＬＧと、フラグＰＴＳＬ＿ＦＬＧとを含んでいる。
【０３０２】
フラグＲＴＡＵ＿ＦＬＧが０ｂのときは、該当ＳＯＢのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
【０３０３】
フラグＲＴＡＵ＿ＦＬＧが１ｂのときは、図９（ａ）または図１２（ａ）のアプリケーションヘッダエクステンション内に記述されるＡＵフラグ（ＡＵ＿ＳＴＡＲＴ、ＡＵ＿ＥＮＤ）が、該当ＳＯＢのリアルタイムデータ内に存在可能なことが示される。この状態は、下記ＡＵＤ＿ＦＬＧが０ｂの場合にも許される。
【０３０４】
フラグＡＵＤ＿ＦＬＧが０ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）がないことが示される。
【０３０５】
フラグＡＵＤ＿ＦＬＧが１ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）が存在し得ることが示される。
【０３０６】
フラグＡＵＥＭ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＡＵＥＭが存在しないことが示される。
【０３０７】
フラグＡＵＥＭ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＡＵＥＭが存在することが示される。
【０３０８】
フラグＰＴＳＬ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＰＴＳＬが存在しないことが示される。
【０３０９】
フラグＰＴＳＬ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＰＴＳＬが存在することが示される。
【０３１０】
ＳＯＢ＿Ｓ＿ＡＰＡＴは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｓ＿ＡＰＡＴにより、該当ＳＯＢに属する最初のアプリケーションパケット到着時間が示される。
【０３１１】
このパケット到着時間（ＰＡＴ）は、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。
【０３１２】
ＳＯＢ＿Ｅ＿ＡＰＡＴは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｅ＿ＡＰＡＴにより、該当ＳＯＢに属する最後のアプリケーションパケット到着時間が示される。
【０３１３】
ＳＯＢ＿Ｓ＿ＳＯＢＵは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、ＳＯＢ＿Ｓ＿ＳＯＢＵにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むＳＯＢＵが示される。
【０３１４】
ＭＡＰＬ＿ＥＮＴ＿Ｎｓは、ＳＯＢＩ＿ＧＩの後に続くタイムマップ情報（ＭＡＰＬ）のエントリ数を記述したものである。
【０３１５】
タイムマップ情報ＭＡＰＬは、図３（ｈ）のタイムマップ情報２５２に対応する内容を持つ。
【０３１６】
図１３および図１５の内容の関連性の１つについて纏めると、次のようになる：
管理情報１０５に含まれるストリーマ情報ＳＴＲＩは、ストリームデータの内容の一部を構成するストリームオブジェクトＳＯＢを管理するストリームファイル情報テーブルＳＦＩＴを含む。このＳＦＩＴは、ＳＯＢを管理するストリームオブジェクト情報ＳＯＢＩを含む。このＳＯＢＩが、管理情報（アクセスユニット開始マップＡＵＳＭ）を含むアクセスユニット一般情報ＡＵ＿ＧＩと、管理情報（ＰＴＳＬ）とを含む。
【０３１７】
ここで、管理情報（ＡＴＳまたはＡＵＳＭ）がストリームデータの転送時に使用される情報を含み、管理情報（ＰＴＳまたはＳＣ＿Ｓ＿ＡＰＡＴ）が前記ストリームデータを表示するときに使用される情報を含む。
【０３１８】
図１６は、アクセスユニット開始マップ（ＡＵＳＭ；図１５参照）とストリームオブジェクトユニット（ＳＯＢＵ；図１、図４〜図６、図１２参照）との対応関係を例示する図である。
【０３１９】
図示するように、ＡＵＳＭのうちビット”１”の部分が、対応ＳＯＢＵにアクセスユニット（ＡＵ）が含まれることを示している。
【０３２０】
いま、ＡＵＳＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＳＭ＿ｐｏｓ（ｉ）としてみる。すると、アクセスユニットＡＵの位置は次のようになる。
【０３２１】
（１）もしＡＵＳＭ＿ｐｏｓ（ｉ）により示されるＳＯＢＵ＃ｉが１以上の開始ＡＵ（これはストリーム内で（もしあるなら）ＡＵ＿ＳＴＡＲＴマークおよびＡＵ＿ＥＮＤマークにより記述される）を含むなら、ＡＵＳＭ＿ｐｏｓ（ｉ）は、ＳＯＢＵ＃ｉ内で開始する最初のＡＵに割り当てられる。ここで、ＳＯＢＵ＃ｉは、ＡＵＳＭ＿ｐｏｓ（ｉ）および（ＡＵＥＭが存在するなら）ＡＵＥＭ＿ｐｏｓ（ｉ）により記述されたＳＯＢＵｓ内に配置されたものである。
【０３２２】
（２）ＡＵは、このＡＵ開始後に最初に現れるＡＵ＿ＥＮＤマークで終了し、かつ、ＡＵは、（もしＡＵＥＭが存在するなら）割り当てられたＡＵＥＭエレメントにより示される最後のＳＯＢＵで終了する。
【０３２３】
なお、いずれのアクセスユニットデータにおいても、ＳＯＢの各ＳＯＢＵ１個当たりに、２以上のアクセス可能なアクセスユニットを記述することはできない。
【０３２４】
図１７は、アクセスユニット開始マップ（ＡＵＳＭ；図１５参照）およびアクセスユニット終了マップ（ＡＵＥＭ；図１５参照）とストリームオブジェクトユニット（ＳＯＢＵ；図２、図４、図１１参照）との対応関係を例示する図である。
【０３２５】
ＡＵＥＭは、（もし存在するなら）ＡＵＳＭと同じ長さのビットアレイである。ＡＵＥＭのビットは、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの末尾がどのＳＯＢＵに含まれるのかを、示している。
【０３２６】
ＡＵＥＭ内にセットされたビットの数はＡＵＳＭ内にセットされたビットの数に一致する。すなわち、ＡＵＳＭ内の各設定ビットは、ＡＵＥＭ内に対応してセットされたビットを持つ。
【０３２７】
いま、ＡＵＳＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＳＭ＿ｐｏｓ（ｉ）とし、ＡＵＥＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＥＭ＿ｐｏｓ（ｉ）としてみる。この場合、以下の関係がある。
【０３２８】
（１）１≦ＡＵＳＭ＿ｐｏｓ（ｉ）≦ＡＵＥＭ＿ｐｏｓ（ｉ）≦ＭＡＰＬ＿ＥＮＴ＿Ｎｓ；
（２）ＡＵＳＭ＿ｐｏｓ（ｉ＋１）＞ＡＵＥＭ＿ｐｏｓ（ｉ）；
（３）もしｉ＝＝ＡＵ＿ＮｓあるいはＡＵＳＭ＿ｐｏｓ（ｉ＋１）＞１＋ＡＵＥＭ＿ｐｏｓ（ｉ）なら、ＡＵ＃ｉは、ＳＯＢＵ＃［ＡＵＥＭ＿ｐｏｓ（ｉ）］で終了する（１≦ｉ≦ＡＵ＿Ｎｓ）；
（４）もしＡＵＳＭ＿ｐｏｓ（ｉ＋１）＝＝１＋ＡＵＥＭ＿ｐｏｓ（ｉ）なら、ＡＵ＃ｉは、ＳＯＢＵ＃［ＡＵＥＭ＿ｐｏｓ（ｉ）］で終了する。あるいは
ＳＯＢＵ＃［１＋ＡＵＥＭ＿ｐｏｓ（ｉ）］＝＝ＳＯＢＵ＃［ＡｕＳＭ＿ｐｏｓ（ｉ＋１）］のところで終了する。つまり、ＡＵ＃ｉは、ＳＯＢＵ内においてＡＵ＃ｉ＋１が開始するところで終了する（１≦ｉ≦ＡＵ＿Ｎｓ）。
【０３２９】
図１８は、オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【０３３０】
ユーザ定義ＰＧＣは自身のＳＯＢを含まないが、オリジナルＰＧＣ内のＳＯＢを参照する。それゆえ、ユーザ定義ＰＧＣはＰＧＣ情報を用いることのみで記述できる。このことは、ＳＯＢデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
【０３３１】
ユーザ定義ＰＧＣはまた、プログラムを含まず、オリジナルＰＧＣ内のプログラムの一部に対応したセルの連なり（チェーン）で構成される。
【０３３２】
このようなユーザ定義ＰＧＣの一例が、図１８に示されている。この例は、ＰＧＣ内のセルがオリジナルＰＧＣ内のＳＯＢを参照するようにユーザ定義ＰＧＣ＃ｎが作成されている場合を示す。
【０３３３】
図１８において、ＰＧＣ＃ｎは４つのセル＃１〜＃４を持っている。そのうち２つはＳＯＢ＃１を参照し、残りの２つがＳＯＢ＃２を参照している。
【０３３４】
ユーザ定義ＰＧＣ内のセルからオリジナルＰＧＣへ（ＳＯＢＩのタイムマップ情報へ）の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義ＰＧＣ内のセル再生順序は、オリジナルＰＧＣにおける再生順序と全く異なってもよい。
【０３３５】
任意のＳＯＢおよびそのＳＯＢＵの再生は、図１８の開始ＡＰＡＴ（Ｓ＿ＡＰＡＴ）および終了ＡＰＡＴ（Ｅ＿ＡＰＡＴ）により特定される。
【０３３６】
ＳＯＢあるいはＳＯＢＵのＳ＿ＡＰＡＴは、該当ＳＯＢのストリームパックのペイロード（図１（ｈ）、図２２、図２３参照）内に記録されたタイムスタンプに関係して定義される。
【０３３７】
ＳＯＢの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間（ＡＰＡＴ）である。
【０３３８】
ＳＯＢの先頭アプリケーションパケットのＡＰＡＴはＳＯＢ＿Ｓ＿ＡＰＡＴとして記憶される。全てのＡＰＡＴの４最下位バイト（4 least significant bytes）は、「〜．ＳＲＯ」ファイル内の対応アプリケーションパケット用に予め固定されている。
【０３３９】
ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ内部のリファレンスクロックはＳＣＲ値にセットされ、その後クロックが自動的にカウントされる。このＳＣＲ値は、再生が始まる最初のストリームパック内（パックヘッダ内）に記述されている。このクロックに基づいて、ＳＯＢあるいはＳＯＢＵからの全ての後続アプリケーションパケットの再生・出力が、実行される。
【０３４０】
任意のストリームセル（ＳＣ）が、そのＳＣがポイントするＳＯＢのＳＯＢ＿Ｓ＿ＡＰＡＴとＳＯＢ＿Ｅ＿ＡＰＡＴとの間の任意の値を持つストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）を規定しているときは、所望のＡＰＡＴを伴うアプリケーションパケットを含んだＳＯＢＵを見つけるためのアドレスが必要となる。
【０３４１】
ＳＯＢＵ１個あたりのストリームパックの数は一定であるが、各ＳＯＢＵにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各ＳＯＢは、該当ＳＯＢのＳＯＢＵの到着時間間隔が記述されたタイムマップ情報（ＭＡＰＬ）を持つ。つまり、タイムマップ情報（ＭＡＰＬ）により実現されるアドレス方式は、任意のＡＰＡＴをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるＳＯＢＵをポイントする。
【０３４２】
図１９は、この発明の一実施の形態に係るストリームデータ記録再生システム（光ディスク装置／ストリーマ、ＳＴＢ装置）の構成を説明する図である。この実施の形態では、情報記憶媒体２０１として、ＤＶＤ−ＲＡＭディスクのような記録／再生可能光ディスクを想定している。
【０３４３】
以下、図１９を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。
【０３４４】
このストリームデータ記録再生装置は、光ディスク装置４１５、ＳＴＢ装置４１６およびその周辺機器から構成される。
【０３４５】
周辺機器としては、ビデオミキシング部４０５、フレームメモリ部４０６、外部スピーカ４３３、パーソナルコンピュータ（ＰＣ）４３５、モニタＴＶ４３７、Ｄ／Ａコンバータ４３２、４３６、Ｉ／Ｆ部４３１、４３４等がある。
【０３４６】
光ディスク装置４１５は、ディスクドライブを含む記録再生部４０９と、記録再生部４０９へのストリームデータ（あるいは記録再生部４０９からのストリームデータ）を処理するデータプロセサ部（以下Ｄ−ＰＲＯ部と略記する）４１０と、Ｄ−ＰＲＯ部４１０からオーバーフローしてきたストリームデータを一時記憶する一時記憶部４１１と、記録再生部４０９およびＤ−ＰＲＯ部４１０の動作を制御する光ディスク装置制御部４１２とを備えている。
【０３４７】
光ディスク装置４１５はさらに、ＳＴＢ装置４１６からＩＥＥＥ１３９４等を介して送られてきたストリームデータを受ける（あるいはＩＥＥＥ１３９４等を介してＳＴＢ装置４１６へストリームデータを送る）データ転送インターフェース部４１４と、データ転送インターフェース部４１４で受けたストリームデータを情報記憶媒体（ＲＡＭディスク）２０１に記録する信号形式に変換する（あるいは媒体２０１から再生されたストリームデータをＩＥＥＥ１３９４等の信号形式に変換する）フォーマッタ／デフォーマッタ部４１３とを備えている。
【０３４８】
具体的には、データ転送インターフェース部４１４のＩＥＥＥ１３９４受信側は、基準クロック発生器（システムタイムカウンタＳＴＣ）４４０のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。
【０３４９】
上記時間情報に基づいて、ストリームデータをストリームブロック毎（あるいはＳＯＢＵ毎）に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはＰＧＣの切り分け情報を作成する。
【０３５０】
フォーマッタ／デフォーマッタ部４１３は、ＳＴＢ装置４１６から送られてきたストリームデータをストリームパックの列（図１２（ａ）、図２３（ｈ）等を参照）に変換し、変換されたストリームパック列をＤ−ＰＲＯ部４１０へ入力する。入力されたストリームパックはセクタと同じ２０４８バイトの一定サイズを持っている。Ｄ−ＰＲＯ部４１０は、入力されたストリームパックを１６セクタ毎にまとめてＥＣＣブロックにして、記録再生部４０９へ送る。
【０３５１】
ここで、記録再生部４０９において媒体２０１への記録準備ができていない場合には、Ｄ−ＰＲＯ部４１０は、記録データを一時記憶部４１１に転送して一時保存し、記録再生部４０９においてデータ記録準備ができるまで待つ。
【０３５２】
記録再生部４０９において記録準備ができた段階で、Ｄ−ＰＲＯ部４１０は一時記憶部４１１に保存されたデータを記録再生部４０９に転送する。これにより、媒体２０１への記録が開始される。一時記憶部４１１に保存されたデータの記録が済むと、その続きのデータはフォーマッタ／デフォーマッタ部４１３からＤ−ＰＲＯ部４１０へシームレスに転送されるようになっている。
【０３５３】
ここで、一時記憶部４１１は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
【０３５４】
なお、フォーマッタ／デフォーマッタ部４１３を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器（ＳＴＣ）４４０から得ることができる。
【０３５５】
また、フォーマッタ／デフォーマッタ部４１３を介して再生ビットストリームから取り出されたタイムスタンプ情報（ＳＣＲ）は、ＳＴＣ４４０にセットすることができる。
【０３５６】
情報記憶媒体２０１に記録されたストリームデータ内のパックヘッダには、基準クロック（システムクロックリファレンスＳＣＲ）が記録されている。この媒体２０１に記録されたストリームデータ（ＳＯＢまたはＳＯＢＵ）を再生する場合において、基準クロック発生器（ＳＴＣ）４４０は、媒体２０１から再生された基準クロック（ＳＣＲ）に適合される（ＳＣＲの値がＳＴＣ４４０にセットされる）。
【０３５７】
つまり、ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ（光ディスク装置４１５）内の基準クロック（ＳＴＣ４４０）を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスＳＣＲに合わせる。その後は、ＳＴＣ４４０のカウントアップは自動的に行われる。
【０３５８】
ＳＴＢ部４１６は、衛星アンテナ４２１で受信したデジタル放送電波の内容を復調し、１以上の番組が多重化された復調データ（ストリームデータ）を提供するデモジュレータ４２２と、デモジュレータ４２２で復調されたデータから（ユーザが希望する）特定番組の情報（後述する図２３を例に採れば、番組２のトランスポートパケット）を選択する受信情報セレクタ部４２３とを備えている。
【０３５９】
受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を情報記憶媒体２０１に記録する場合は、ＳＴＢ制御部４０４の指示にしたがい、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部２０を介して、ＩＥＥＥ１３９４転送により、光ディスク装置４１５のデータ転送インターフェイス部４１４に送る。
【０３６０】
受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を記録することなく単に視聴するだけの場合は、ＳＴＢ制御部４０４の指示にしたがい、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部４０２の多重化情報分離部４２５に送る。
【０３６１】
一方、情報記憶媒体２０１に記録された番組を再生する場合は、ＩＥＥＥ１３９４のシリアルバスを介して光ディスク装置４１５からＳＴＢ装置４１６に送られてきたストリームデータは、セレクタ部４２３を介してデコーダ部４０２の多重化情報分離部４２５に送られる。
【０３６２】
多重化情報分離部４２５は、セレクタ部４２３から送られてきたストリームデータに含まれる各種パケット（ビデオパケット、オーディオパケット、サブピクチャパケット）を、内部メモリ部４２６上で、各パケットのＩＤにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部（ビデオデコード部４２８、サブピクチャデコード部４２９、オーディオデコード部４３０に分配する。
【０３６３】
ビデオデコード部４２８は、多重化情報分離部４２５から送られてきた（ＭＰＥＧエンコードされた）ビデオパケットをデコードして、動画データを生成する。その際、ＭＰＥＧビデオデータ中のＩピクチャから記録内容を代表する縮小画像（サムネールピクチャ）を生成する機能を持たせるために、ビデオデコード部４２８は、代表画像（サムネール）生成部４３９を内蔵している。
【０３６４】
ビデオデコード部４２８でデコードされた動画（および／または生成部４３９で生成された代表画像）と、サブピクチャデコード部４２９でデコードされたサブピクチャ（字幕、メニュー等の情報）と、オーディオデコード部４３０でデコードされた音声とは、ビデオプロセサ部４３８を介してビデオミキシング部４０５へ送出される。
【０３６５】
ビデオミキシング部４０５は、フレームメモリ部４０６を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、Ｄ／Ａ変換器４３６を介してアナログ映像化され、モニタＴＶ４３７に送られる。
【０３６６】
また、ビデオミキシング部４０５からのデジタル映像は、Ｉ／Ｆ部４３４およびＩＥＥＥ１９４等の信号ラインを介して、パーソナルコンピュータ４３５に適宜取り込まれる。
【０３６７】
一方、オーディオデコード部４３０でデコードされたデジタルオーディオ情報は、Ｄ／Ａ変換器４３２および図示しないオーディオアンプを介して、外部スピーカ４３３に送られる。また、デコードされたオーディオ情報は、Ｉ／Ｆ部４３１を介して外部にデジタル出力される。
【０３６８】
なお、ＳＴＢ装置４１６内の動作タイミングは、システムタイムカウンタ（ＳＴＣ）部４２４からのクロックにより決定される。
【０３６９】
上述したＳＴＢ制御部４０４による指示等（ＳＴＢ装置４１６の内部構成各々の動作制御）は、プログラムメモリ部４０４ａに格納された制御プログラムにより実行される。その際、ＳＴＢ制御部４０４による制御過程においてワークメモリ部４０７が適宜利用される。
【０３７０】
このＳＴＢ制御部４０４およびデコーダ部４０２を含めＳＴＢ装置４１６の内部動作のタイミングは、ＳＴＣ部４２４からのクロックで規制できる。また、光ディスク装置４１５のＳＴＣ４４０とＳＴＢ装置４１６のＳＴＣ部４２４を同期させることで、光ディスク装置４１５およびＳＴＢ装置４１６を含めたストリーマシステム全体の動作タイミングを規制できる。
【０３７１】
ＳＴＣ４４０とＳＴＣ部４２４を同期させる方法としては、データ転送インターフェース部４１４とデータ転送インターフェース部４２０との間で受け渡されるストリームデータ中の基準クロック（ＳＣＲ）により、ＳＴＣ４４０およびＳＴＣ部４２４をセットする方法がある。
【０３７２】
図１９の装置構成を機能別にみると、ＳＴＢ装置４１６内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割／分類できる。
【０３７３】
ここで、「受信時刻管理部」は、デモジュレータ（復調部）４２２、受信情報セレクタ部４２３、多重化情報分離部４２５、ＳＴＢ制御部４０４等で構成される。この「受信時刻管理部」は、衛星アンテナ４２１でデジタルＴＶ放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。
【０３７４】
「ストリームデータ内容解析部」は、多重化情報分離部４２５、ＳＴＢ制御部４０４等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、Ｉ，Ｂ，Ｐの各ピクチャ位置および／またはＰＴＳ値を抽出する。
【０３７５】
「ストリームデータ転送部」は、多重化情報分離部４２５、受信情報セレクタ部４２３、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置４１５へ転送する。
【０３７６】
「時間関連情報生成部」は、多重化情報分離部４２５、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻（タイムスタンプ）情報と「ストリームデータ内容解析部」で抽出した表示時刻情報（ＰＴＳ値および／またはフィールド数）との間の関係情報を作成する。
【０３７７】
図２０は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。図２０を用いてこの発明の基本的特徴について説明する。
【０３７８】
ＴＶの表示方式の１つであるＮＴＳＣ方式では、１秒間に３０枚の画面／ピクチャ（フレーム）を映像信号としてＴＶのモニタスクリーンに表示している。通常のＴＶでは、インターレース方式を用いているので、１画面の全走査線に対して始めに１本おきに画面を走査して表示し、その後で１本ずらした画像を１本おきに走査することで直前の画面の間を埋めて１枚の画面（ピクチャ）の表示を行う。この１本おきに表示する画像をフィールドと呼ぶ。
【０３７９】
ＮＴＳＣ方式では、毎秒３０フレーム／６０フィールドを表示している。このＮＴＳＣ方式は主に日本とアメリカで採用されている表示方式である。それに対して、主に欧州で採用されているＰＡＬ方式では、毎秒２５フレーム／５０フィールドの表示を行っている。
【０３８０】
図２０（ａ）は、毎秒３０枚変化する画面／ピクチャ（フレーム）を表示時刻（プレゼンテーションタイム；または再生時間）１に沿って並べた図である。
【０３８１】
画面／ピクチャの表示時刻（再生時間）１を表す情報としては、
（ａ）”ある特定の画面（ピクチャ）からの差分フィールド枚数”で表す方法と；
（ｂ）”ＰＴＳ（プレゼンテーションタイムスタンプ；または再生タイムスタンプ）”で表す方法がある。
【０３８２】
ＰＴＳは、２７ＭＨｚおよび／または９０ｋＨｚの基準クロックを利用し、常にインクリメント（カウンタの値が１ずつ増加）するカウンタの値で表示時刻を表す方法で用いることができる。たとえば、２７ＭＨｚ（または９０ｋＨｚ）の基準クロックでインクリメントするカウンタで各画面／ピクチャ（フレーム）を示すときのカウンタの値が、ＰＴＳの値として用いられる。
【０３８３】
デジタルＴＶでの受信信号情報内には、各ピクチャ毎のＰＴＳ値がピクチャヘッダ情報４１（図１（ｊ）参照）内に含まれている。
【０３８４】
図２０（ａ）では、Ｉピクチャａの表示時刻がＰＴＳＮｏ．１で表わされ、Ｉピクチャｉおよびｑの表示時刻がＰＴＳＮｏ．２およびＰＴＳＮｏ．３で表わされている。
【０３８５】
いま、例えばユーザから、Ｉピクチャａ表示の何時間何分何秒後の画面（ピクチャ）を表示するように指示を受けたとする。すると、上記指定時間間隔（何時間何分何秒後）が２７ＭＨｚおよび／または９０ｋＨｚのカウント値に換算される。そして、この換算値とＩピクチャａ表示のＰＴＳ値（ＰＴＳＮｏ．１）との加算結果を計算して、ユーザから指示された「表示すべき画面（ピクチャ）」を検索することができる。
【０３８６】
情報記憶媒体２０１上に記録されたストリームデータは、図１（ｇ）その他に示したように各トランスポートパケット毎にタイムスタンプを付加して記録されているので、このタイムスタンプ情報を利用してストリームデータに対する時間管理を行っている。
【０３８７】
しかし、このタイムスタンプ情報はユーザには認知できないため、ユーザは表示時刻（再生時間）１を用いて、見たい画面（ピクチャ）を指定することになる。
【０３８８】
この場合、ストリームデータを時間管理するためのタイムスタンプ情報とユーザが指定可能な表示時刻（再生時間）１情報との間の関係を示す情報が必要になる。この関係を示す情報が、図２０（ｂ）に示す時間関係テーブル２（あるいは図１５の再生タイムスタンプリストＰＴＳＬ）である。
【０３８９】
図２０（ｂ）に例示するように、時間関係テーブル２には、各ＰＴＳ値（ＰＴＳＮｏ．１、ＰＴＳＮｏ．２、ＰＴＳＮｏ．３、…）毎に、対応するデータ転送時刻情報（Ｉピクチャ転送開始時刻４）、データ転送時刻情報（Ｉピクチャ転送終了時刻５）、セル先頭から目的のＩピクチャまでの通算パケット数１０が記述されている。
【０３９０】
たとえばＰＴＳＮｏ．１のＩピクチャａについてみると、データ転送時刻情報（Ｉピクチャ転送開始時刻４）の行のタイムスタンプ（ＡＴＳ）＃１は図２（ｃ）のＩピクチャａ情報７の先頭側パケット（ＡＰ）＃１のタイムスタンプ（ＡＴＳ）＃１に対応し、データ転送時刻情報（Ｉピクチャ転送終了時刻５）の行のタイムスタンプ（ＡＴＳ）＃２は図２（ｃ）のＩピクチャａ情報７の末尾側パケット（ＡＰ）＃２のタイムスタンプ（ＡＴＳ）＃２に対応している。ここではＩピクチャａが最初のピクチャなので、ＰＴＳＮｏ．１のＩピクチャａに対する通算パケット数１０は、図２０（ｂ）に示すように「１」となる。
【０３９１】
同様にＰＴＳＮｏ．２のＩピクチャｉについてみると、データ転送時刻情報（Ｉピクチャ転送開始時刻４）の行のタイムスタンプ（ＡＴＳ）＃３は図２（ｃ）のＩピクチャｉ情報８の先頭側パケット（ＡＰ）＃３のタイムスタンプ（ＡＴＳ）＃３に対応し、データ転送時刻情報（Ｉピクチャ転送終了時刻５）の行のタイムスタンプ（ＡＴＳ）＃４は図２（ｃ）のＩピクチャｉ情報８の末尾側パケット（ＡＰ）＃４のタイムスタンプ（ＡＴＳ）＃４に対応している。ここではＩピクチャｉが最初のＩピクチャａから８５１００枚後としているので、ＰＴＳＮｏ．２のＩピクチャｉに対する通算パケット数１０は、図２０（ｂ）に示すように「８５１０１」となる。ＰＴＳＮｏ．３以後についても同様である。
【０３９２】
図２０（ｂ）に示すような時間関係テーブル２を、ストリームデータ（図１（ａ）、図２０（ｃ）その他のＳＴＲＥＡＭ．ＶＲＯ１０６）に関する管理情報（図１５のＳＦＩＴ）が記録されている領域に記録し、この時間関係テーブルを利用して、ユーザにとってピクチャ単位の画面位置指定ができるようにした所に、この発明の大きな特徴がある。
【０３９３】
ここで、上記時間関係テーブル２と図１５に示した再生タイムスタンプリストＰＴＳＬとの対応関係について、説明しておく。
【０３９４】
図１（ｇ）その他に示されたタイムスタンプをＡＴＳとしたとき、図１５の再生タイムスタンプリストＰＴＳＬに含まれるＰＴＳの値とＡＴＳとは、以下のような関係を持つ：
（１）セル（ストリームセル）は記録されたビットストリームの一部を参照するものである；
（２）ＡＵ（通常Ｉピクチャ）は記録されたビットストリームの連続した一部である（ＡＵはセルの一部に対応する）；
（３）ＡＵ（セルの一部に対応するＩピクチャ）がどのＳＯＢＵに含まれるかは、図１５のアクセスユニット開始マップＡＵＳＭにより示される（図１６参照）；
（４）ＰＴＳの値は対応ＡＵの再生時間（表示時刻；あるいはプレゼンテーションタイムＰＴＭ）である（ＡＵに対応するＰＴＳの値は、再生時間に関して、セルの一部に対応する）；
（５）セル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は該当セルのトランスポートパケットまたはアプリケーションパケットＡＰの到着時間である（ＳＣ＿Ｓ＿ＡＰＡＴは、再生時間に関して、ＰＴＳの値に対応する）；
（６）トランスポートパケットまたはアプリケーションパケットＡＰは、その先頭にタイムスタンプＡＴＳを伴う（図２２、図２９（ｇ）等参照）；
（７）ＰＴＳの値は、ＰＴＳＬに含まれる（図１５参照）；
（８）上記（３）〜（７）から、ＰＴＳＬに含まれるＰＴＳの値は、ＡＵＳＭ、ＳＣ＿Ｓ＿ＡＰＡＴ等を仲介して、ＡＴＳに対応することになる。
【０３９５】
よって、再生タイムスタンプリストＰＴＳＬは、ＡＵ（Ｉピクチャ）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）と、ビットストリームに含まれるパケットのタイムスタンプＡＴＳとの関係（再生時間に関する関係）を示す情報（ＰＴＳの値）を含む「時間関係テーブル（図２０（ｂ））」であると言える。
【０３９６】
あるいは、ＰＴＳＬ（時間関係テーブル）は、ＰＴＳの値とＡＴＳとの対応関係を示す情報であるとも言える。
【０３９７】
ところで、ＢピクチャあるいはＰピクチャを表示するためには、必ずＩピクチャの表示（デコード）から開始する必要がある。このため、図２０（ｂ）に示す時間関係テーブル２は、Ｉピクチャ位置でのタイムスタンプと対応する表示時刻情報を一覧表として示してある。
【０３９８】
ここでは、表示時刻情報として、”ＰＴＳ情報（ＰＴＳの値）”、”特定基準画面（ピクチャ）からの差分フィールド数”、”年月日時刻情報”等を用いることができる。
【０３９９】
なお、表示時刻情報として図２０（ｂ）に示すような絶対値表示を行う代わりに、各Ｉピクチャ間の差分情報（例えば各Ｉピクチャ間に挿入されるフィールド数情報）を使用することも可能である。（フィールド数を利用した時間関係テーブルについては、図２８を参照して後述する。）
また、図２０（ｂ）では表示時刻情報として”ＰＴＳ情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面（ピクチャ）からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。
【０４００】
図２０（ｂ）に示す時間関係テーブル２では、各Ｉピクチャ毎の転送開始時刻４の値がタイムスタンプ（ＡＴＳ）＃１、＃３、＃５として一覧表に記録されているだけでなく、Ｉピクチャの転送終了時刻５の値もタイムスタンプ（ＡＴＳ）＃２、＃４、＃６として記録されている。
【０４０１】
このため、早送り再生（ファーストフォワードＦＦ）あるいは早戻し再生（ファーストリバースＦＲなどの特殊再生を行う場合には、”タイムスタンプ（ＡＴＳ）＃１から＃２まで”、”タイムスタンプ（ＡＴＳ）＃３から＃４まで”、”タイムスタンプ（ＡＴＳ）＃５から＃６まで”というように、再生するＩピクチャのトランスポートパケット位置（またはアプリケーションパケット位置）を指定することで、情報記憶媒体２０１から、Ｉピクチャ情報（またはアクセスユニットＡＵ情報）のみを再生し、デコードし、表示することが可能となる。
【０４０２】
図２０（ａ）の実施の形態では、オリジナルセル（図４参照）の表示開始ピクチャ位置（Ｂピクチャｆの位置）を基準に採っている。このオリジナルセルの表示開始ピクチャのＰＴＳ値（ＰＴＳＮｏ．５）とその直前にあるＩピクチャａのＰＴＳ値（ＰＴＳＮｏ．１）との差分が、ＰＴＳオフセット９である。このＰＴＳオフセット値９は、図３（ｈ）に示したように、オリジナルセル情報２７２内に記録される。
【０４０３】
具体的には、図２０（ａ）に示すように、オリジナルセルの表示開始ピクチャをＢピクチャｆとし、その時のＰＴＳ値をＰＴＳＮｏ．５とする。その直前のＩピクチャａの表示時刻をＰＴＳＮｏ．１とすると、ＰＴＳオフセット９の値は、”ＰＴＳＮｏ．５  −  ＰＴＳＮｏ．１”で求まる。
【０４０４】
ユーザが特定画面（特定のピクチャフレーム）を指定する場合、オリジナルセルの表示開始位置からの差分表示時間で指定する場合が多い。この差分表示時間を２７ＭＨｚおよび／または９０ｋＨｚのカウンタ数に換算後、ＰＴＳオフセット９の値を加算することで、ユーザが指定した画面（ピクチャフレーム）のＰＴＳ値を算出できる。
【０４０５】
図２０（ｂ）に示すように、時間関係テーブル２には、各Ｉピクチャ毎のＰＴＳ値一覧が記録されている。このテーブルを参照し、算出したＰＴＳ値よりも小さく、しかも算出したＰＴＳ値に最も近いＩピクチャ位置のＰＴＳ値を探し、そこに対応したＩピクチャ転送開始時刻４のタイムスタンプ（ＡＴＳ）値を指定して、情報記憶媒体２０１へのアクセスを開始する。
【０４０６】
図２０（ｂ）に示すように、時間関係テーブル２には、タイムスタンプと並行して、オリジナルセル先頭位置から該当するＩピクチャまでの通算トランスポートパケット数１０（アクセス位置情報）も記録されている。
【０４０７】
したがって、図２０の実施の形態によれば、タイムスタンプ（ＡＴＳ）の代わりにオリジナルセル先頭位置からのトランスポートパケット数（またはアプリケーションパケット数ＡＰ＿Ｎｓ）を指定して、所望のストリームデータ位置へアクセスすることも可能である。
【０４０８】
図２０（ｃ）のストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６が図３等に示す情報記憶媒体２０１に記録される場合、ストリームデータ１０６の内容（ＳＯＢまたはＳＯＢＵ）は、所定のデータ記録単位（トランスポートパケットまたはアプリケーションパケット）で、媒体２０１のデータ領域（ＳＴＲＥＡＭ．ＶＲＯ／ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）に記録される。その際、ストリームデータ１０６に関する管理情報（ＳＴＲＩ）も、媒体２０１の管理領域（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）に記録される。
【０４０９】
この管理情報（ＳＴＲＩ）に、ストリームデータ１０６のアクセス（Ｉピクチャ情報またはアクセスユニットＡＵへのアクセス）に利用される第１の管理情報（Ｉピクチャ転送開始時刻に対応したＡＴＳ；またはＡＵＳＭ）と；第１の管理情報（ＡＵＳＭ）とは異なるものであって、この第１の管理情報と前記ストリームデータのアクセスに利用される第２の管理情報（ＰＴＳ；またはＳＣ＿Ｓ＿ＡＰＡＴ）との間の関係を示す第３の管理情報（時間関係テーブル；またはＰＴＳＬ）が記録される。
【０４１０】
ここで、ストリームデータ１０６はＭＰＥＧ規格に基づき圧縮されたビットストリームであり、前記第２の管理情報はストリームデータの再生時間（ＰＴＳ）に対応する。
【０４１１】
図２１は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図である。
【０４１２】
情報記憶媒体２０１上に記録されたストリームデータ（図１、図２その他のＳＴＲＥＡＭ．ＶＲＯ１０６）内のデータ構造に関し、図２１を用いて、各ピクチャ情報６０１０〜６０３０の記録位置とストリームブロック（ＳＯＢＵ）との間の配置関係を説明する。
【０４１３】
この実施の形態では、ストリームデータはストリームブロック（ＳＯＢＵ）単位で記録され、所定画像（ピクチャ）へのアクセス指定にはタイムスタンプ情報が利用される。
【０４１４】
図１９のＳＴＢ装置４１６から再生開始位置としてタイムスタンプ値が指定された場合において、指定されたタイムスタンプ値に対応するストリームブロック（ＳＯＢＵ）を算出するための情報が、図３（ｈ）のタイムマップ情報２５２（あるいは図１５のタイムマップ情報ＭＡＰＬ、もしくは図１８のタイムマップ情報）である。
【０４１５】
図３（ｈ）の例では、タイムマップ情報２５２は、ストリームデータに対する管理情報記録領域であるＳＴＲＥＡＭ．ＩＦＯ１０５内のストリームオブジェクト情報（ＳＯＢＩ）２４２の一部として記録されている。図１５の例でも、タイムマップ情報ＭＡＰＬはＳＯＢＩの一部として記録されている。
【０４１６】
図３（ｉ）に示すタイムマップ情報２５２内では、各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。この場合は、各ストリームオブジェクト情報（ＳＯＢＩ）２４２、２４３毎に、タイムマップ情報２５２内の各ストリームブロックの時間差２６３、２６５の値を逐次加算する。そして、この逐次加算値が、ＳＴＢ装置４１６側により指定されたタイムスタンプ時刻に到達したか否か比較する必要がある。その比較結果を元に、ＳＴＢ装置４１６側により指定された時刻がどのストリームオブジェクト（ＳＯＢ）内の何番目のストリームブロック（ＳＯＢＵ）の中に含まれるタイムスタンプ値と一致するかが割り出される。
【０４１７】
図２１（ｃ）に示すように各ピクチャ情報６０１０〜６０３０の境界位置とストリームブロック（ＳＯＢＵ）の境界位置とは必ずしも一致しない。
【０４１８】
この場合、例えば図２１（ａ）で示すように、ＰＴＳの値がＰＴＳＮｏ．６であるＰピクチャｏの位置から再生を開始しようとするなら、次のような処理が必要になる。
【０４１９】
すなわち、図２１（ｂ）の時間関係テーブル２（内部構成は図２０（ｂ）と同様）からその直前にあるＩピクチャｉのＰＴＳＮｏ．２の値を割り出し、Ｉピクチャｉ情報６０１０が記録されている先頭のトランスポートパケット＃２が含まれるストリームブロック（ＳＯＢＵ）＃Ａ先頭位置から、再生を開始する必要がある。
【０４２０】
ただし、ストリームブロック（ＳＯＢＵ）＃Ａ先頭位置から所望のＰピクチャｏの位置まで再生が進むまで、その間の画像情報（図２１（ａ）ではピクチャｉからピクチャｎまで）は外部モニタ（ＴＶ）に出力されない。
【０４２１】
図２２は、ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
【０４２２】
図２２に示すように、デジタルＴＶでの放送信号情報にはＭＰＥＧ２と呼ばれる信号圧縮方法が採用されている。ＭＰＥＧによる信号圧縮方法では、ＴＶ表示用の各画面（ピクチャ）は時間差分情報を含まないＩピクチャ５５１と時間差分情報を含むＢピクチャ５５３、５５４とＰピクチャ５５２に分類される。
【０４２３】
Ｉピクチャは前後の画面（ピクチャ）情報の影響を受けることなく単体で存在し、１枚の画面（ピクチャ）に対してＤＣＴ変換後、量子化した情報がＩピクチャ圧縮情報５６１となり、Ｉピクチャ情報３１として記録される。Ｐピクチャ５５２はＩピクチャ５５１に対する差分情報５６２のみがＰピクチャ情報３２として記録され、Ｂピクチャ５５３、５５４はＩピクチャ５５１とＰピクチャ５５２に対する差分情報がＢピクチャ情報３３、３４として記録される。
【０４２４】
従って、映像再生時にはＰピクチャ５５２やＢピクチャ５５３、５５４単体では画面を生成することができず、必ずＩピクチャ５５１画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報３１〜３４は１個または複数のトランスポートパケット内のペイロードに分割記録されている。この時、各ピクチャ情報３１〜３４の境界位置とトランスポートパケット間の境界位置は常に一致するように記録されている。
【０４２５】
図２２のトランスポートパケットがストリーマ（図１９の光ディスク装置４１５）に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ（ＡＴＳ）というタイムスタンプ付きのパケット（アプリケーションパケット）に移し替えられる。
【０４２６】
そして、ＡＴＳ付きアプリケーションパケットの一群（通常１０パケット前後）がストリームＰＥＳパケット内のアプリケーションパケットエリアに格納される。
【０４２７】
このストリームＰＥＳパケットにパックヘッダを付したものが１つのストリームパックになる。
【０４２８】
ストリームＰＥＳパケットは、ＰＥＳヘッダと、サブストリームＩＤと、アプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、上記ＡＴＳ付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。
【０４２９】
図２３は、デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
【０４３０】
デジタル放送では、ＭＰＥＧ２規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図２３（ｂ）に示すように、トランスポートパケットヘッダ５１１と、記録情報のデータ本体が記録されているペイロード５１２とで構成されている。
【０４３１】
トランスポートパケットヘッダ５１１は、図２３（ａ）に示すように、ペイロードユニット開始インジケータ５０１、パケットＩＤ（ＰＩＤ）５０２、ランダムアクセスインジケータ５０３、プログラムクロックリファレンス５０４等で構成されている。
【０４３２】
ＭＰＥＧ圧縮された映像情報は、Ｉピクチャ情報、Ｂピクチャ情報、およびＰピクチャ情報を含んでいる。Ｉピクチャ情報が記録されている最初のトランスポートパケットには、図２３（ａ）のランダムアクセスインジケータ５０３に”１”のフラグが立つ。また、各Ｂ、Ｐピクチャ情報の最初のトランスポートパケットには、図２３（ａ）のペイロードユニット開始インジケータ５０１に”１”のフラグが立つ。
【０４３３】
これらのランダムアクセスインジケータ５０３およびペイロードユニット開始インジケータ５０１の情報を利用して、Ｉピクチャマッピングテーブル（図９（ｅ）の６４１）およびＢ、Ｐピクチャ開始位置マッピングテーブル（図９（ｅ）の６４２）の情報が作成される。
【０４３４】
たとえば、図２３（ａ）に示したペイロードユニット開始インジケータ５０１に”１”のフラグが立ったトランスポートパケットに対して、Ｂ、Ｐピクチャ開始位置マッピングテーブル（図９（ｅ）の６４２）内の該当個所のビットが”１”になる。
【０４３５】
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図２３（ａ）のパケットＩＤ（ＰＩＤ）５０２で識別される。このＰＩＤ５０２の情報を用いて、ビデオパケットマッピングテーブル（図９（ｅ）の６４３）とオーディオパケットマッピングテーブル（図９（ｅ）の６４４）が作成される。
【０４３６】
図２３（ｃ）に示すように、デジタル放送では、１個のトランスポンダに複数の番組（この例では番組１〜番組３）がパケット化された形で時分割されて転送されてくる。
【０４３７】
たとえば、図２３（ｂ）のトランスポートパケットヘッダ５１１およびペイロード（記録情報）５１２の情報は、図２３（ｃ）に示される番組２のトランスポートパケットｂ・５２２、ｅ・５２５により転送される。
【０４３８】
ユーザが例えば図２３（ｃ）の第２の番組を情報記憶媒体２０１に記録しようとする場合には、図１９に示すＳＴＢ装置４１６内の受信情報セレクタ部４２３において、番組２のトランスポートパケットｂ、ｅのみが抽出される。
【０４３９】
そのとき、ＳＴＢ装置４１６では、図２３（ｄ）に示すように、各トランスポートパケット  ｂ５２２、ｅ５２５を受信した時刻情報をタイムスタンプ５３１、５３２の形で付加する。
【０４４０】
その後、ＩＥＥＥ１３９４の転送方式を用いて図１９のフォーマッタ／デフォーマッタ部４１３にデータを転送する場合には、図２３（ｅ）に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。
【０４４１】
図１９のフォーマッタ／デフォーマッタ部４１３では、ＳＴＢ装置４１６からＩＥＥＥ１３９４で転送されてきたストリームデータが、図２３（ｄ）の形（図１（ｇ）の形に相当）に一旦戻される。そして、図２３（ｄ）の形式のビットストリーム（図２３（ｈ）のストリームパック列）が、情報記憶媒体２０１に記録される。
【０４４２】
具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとＰＥＳヘッダが配置される（図２３（ｈ）等参照）。
【０４４３】
データエリア２１、２２、２３（図１（ｆ））には複数のタイムスタンプおよびトランスポートパケット（図１（ｇ））が逐次詰め込まれるが、１個のトランスポートパケット（図１（ｇ）ではパケットｄ；図２３（ｄ）では番組２のパケットｂ）が複数のセクタ（図１（ｅ）ではＮｏ．０とＮｏ．１；図２３（ｆ）（ｇ）では部分パケット）に跨って記録される。ここに、この発明の特徴の１つがある。
【０４４４】
この特徴を生かしたデータ構造を用いることにより、セクタサイズ（例えば２０４８バイト）よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
【０４４５】
デジタル放送では図２３（ｃ）に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、１個のトランスポートパケットｂ・５２２のサイズが１８８バイト（または１８３バイト）の場合が多い。
【０４４６】
前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個のデータエリア２１、２２、２３（図１（ｆ））内にはデジタル放送用のトランスポートパケットが１０個前後記録できる。
【０４４７】
それに対して、ＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトある大きなロングパケットが転送される場合がある。
【０４４８】
デジタル放送などのように１個のデータエリア２１、２２、２３（図１（ｆ））内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造（１パケットのデータを複数パケットに跨って記録できる特徴）を用いることにより、１個のパケットを複数のデータエリア２１、２２、２３に連続して跨るように記録する。
【０４４９】
そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
【０４５０】
また、通常のパケットにはタイムスタンプが付いているが、図２３（ｇ）に示すように、部分パケットではタイムスタンプを省略することができる。
【０４５１】
このようにすると、２つの隣接ストリームパック（図２３（ｈ））の境界で分断された部分パケット（パケット１つあたり１８８バイトとすれば部分パケットのサイズは１〜１８７バイト；平均して１００バイト弱）を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分（タイムスタンプ１つあたり例えば４バイト）、媒体２０１に対する記憶容量を増やすことができる。
【０４５２】
なお、図２３（ｇ）の先頭部分パケットの直後にくるタイムスタンプの位置は、図１０（ｂ）のファーストアクセスポイント６２５あるいは図１０（ｃ）のＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴにより、特定することができる。
【０４５３】
図１９の光ディスク装置４１５（ストリーマ）では、タイムスタンプとトランスポートパケットとの組（図２３（ｆ）（ｇ））をそのままの形で情報記憶媒体２０１上に記録する。
【０４５４】
図２４は、この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図である。図２４を用いて、ストリームデータ録画時の処理について説明する。この処理は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。
【０４５５】
図２３（ｃ）に示すように、１個のトランスポンダ内には複数番組情報が時分割多重化されている。
【０４５６】
図１９の受信情報セレクタ部４２３内で、この時分割多重化された複数番組情報のパケット列から、特定番組のみのトランスポートパケットが抽出される（ステップＳ０１）。
【０４５７】
「受信時刻管理部（図１９の復調部４２２、受信情報セレクタ部４２３、多重化情報分離部４２５、ＳＴＢ制御部４０４等）」では、必要な番組情報が、多重化情報分離部４２５のメモリ部４２６内に、一時保管される（ステップＳ０２）。
【０４５８】
それと同時に、各トランスポートパケット毎の受信時刻が計測され、その計測値が、図２３（ｄ）に示すように、タイムスタンプ（ＡＴＳ）として各トランスポートパケット（またはアプリケーションパケット）毎に付加される。こうして付加されたタイムスタンプ情報は、メモリ部４２６内に記録される（ステップＳ０３）。
【０４５９】
次に、「ストリームデータ内容解析部（図１９の多重化情報分離部４２５、ＳＴＢ制御部４０４等）」において、メモリ部４２６内に記録されたトランスポートパケット（アプリケーションパケット）内の情報が解析される。
【０４６０】
具体的には、トランスポートパケット（アプリケーションパケット）列から各ピクチャ境界位置の切り出しが行われるとともに、各パケット毎のピクチャヘッダ情報４１からＰＴＳ情報（まあは対応フィールド枚数情報）の抽出が行なわれる（ステップＳ０４）。
【０４６１】
ここで、各ピクチャ境界位置の切り出し方法には２通りの方法が存在し、いずれの方法を選択するかはストリームデータの内容による。
【０４６２】
第１のピクチャ境界位置切出方法は、トランスポートパケットヘッダ５１１（図２３（ｂ））内のランダムアクセスインジケータ５０３（図２３（ａ））のフラグを検出してＩピクチャ位置を検出し、ペイロードユニット開始インジケータ５０１（図２３（ａ））のフラグ検出からＢまたはＰピクチャ位置を検出する方法である。
【０４６３】
第２のピクチャ境界位置切出方法は、ピクチャヘッダ情報４１（図１（ｊ））内にあるピクチャ識別情報５２（図１（ｋ））およびＰＴＳ情報５３（図１（ｋ））を抽出する方法である。
【０４６４】
上記の処理（ステップＳ０１〜Ｓ０４）を経た後、「時間関連情報生成部（図１９の多重化情報分離部４２５、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等）」では、タイムスタンプ（ＡＴＳ）とＰＴＳ値との間の関係を示す一覧表として、図２０（ｂ）に示すような時間関係テーブル２（あるいは図１５の再生タイムスタンプリストＰＴＳＬ）を作成し、ＳＴＢ制御部４０４内のワークメモリ部４０７に記録する（ステップＳ０５）。
【０４６５】
その後、ＳＴＢ装置４１６および光ディスク装置４１５における受信時刻間隔を保持しながら（つまり図１９のＳＴＣ４４０のカウント値変化とＳＴＣ４２４のカウント値変化との間の関係を一定に保ちながら）、多重化情報分離部４２５のメモリ部４２６に一時保管されたパケットデータ（ストリームデータ）が、光ディスク装置４１５に転送される（ステップＳ０６）。
【０４６６】
こうして、光ディスク装置４１５により、メモリ部４２６に一時保管されたストリームデータが、情報記憶媒体２０１上に記録される（ステップＳ０７）。
【０４６７】
光ディスク装置４１５へのストリームデータ転送が完了するまでは（ステップＳ０８ノー）、ステップＳ０６〜Ｓ０７の処理が反復される。
【０４６８】
光ディスク装置４１５へのストリームデータ転送が済みその録画処理が完了すると（ステップＳ０８イエス）、ＳＴＢ制御部４０４のワークメモリ部４０７内に一時記録されていた時間関係テーブル２（あるいは再生タイムスタンプリストＰＴＳＬ）の情報が、光ディスク装置４１５へ転送される（ステップＳ１０）。
【０４６９】
そして、時間関係テーブル２（あるいは再生タイムスタンプリストＰＴＳＬ）の情報が、情報記憶媒体２０１の管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）１０５に記録される（ステップＳ１１）。
【０４７０】
なお、上記ステップＳ１１の処理時に、録画されたストリームデータの内容であるストリームオブジェクトの記録時間（図７（ｉ）のＳＯＢ＿ＲＥＣ＿ＴＭ）を、管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）１０５内のタイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０（図７（ｈ）に記録することができる。
【０４７１】
ところで、ストリームデータ録画時にコンテンツプロバイダの著作権保護を目的として暗号化されたストリームデータを記録する場合がある。このように暗号化がなされるときは、全てのトランスポートパケットが暗号化されるとともに、ＳＴＢ装置４１６と光ディスク装置４１５との間のタイムスタンプ転送処理が禁止される。この場合には、情報記憶媒体２０１への（暗号化された）ストリームデータ記録時に、光ディスク装置４１５側で独自にタイムスタンプを付加する必要が生じる。
【０４７２】
図１９のＳＴＢ装置４１６側では、トランスポートパケット（アプリケーションパケット）毎の受信時刻管理を行っている。この場合、ＳＴＢ装置４１６側と光ディスク装置４１５側との間で、基準クロック周波数のずれに対する対策（具体的には基準クロックの同期化）が重要課題となる。そこで、以下、暗号化されたストリームデータに対する録画処理について説明する。
【０４７３】
図２５は、この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。
【０４７４】
まず、図１９のＳＴＢ制御部４０４のワークメモリ４０７内に時間関係テーブル２（図２０（ｂ））あるいは再生タイムスタンプリストＰＴＳＬ（図１５）があるかどうか、チェックされる（ステップＳ５０）。
【０４７５】
時間関係テーブル（あるいはＰＴＳＬ）がない場合は（ステップＳ５０ノー）、図２４のステップＳ０４〜Ｓ０５と同様な処理で、時間関係テーブル（あるいはＰＴＳＬ）が作成される（ステップＳ５２）。
【０４７６】
こうして時間関係テーブル（あるいはＰＴＳＬ）が作成されたあと、あるいは既に時間関係テーブル（あるいはＰＴＳＬ）がＳＴＢ制御部４０４のワークメモリ４０７内にあるときは（ステップＳ５０イエス）、ＳＴＢ装置４１６から光ディスク装置４１５へ（暗号化された）ストリームデータが転送され、このストリームデータが情報記憶媒体２０１に記録される（ステップＳ５１）。
【０４７７】
この（暗号化された）ストリームデータの記録が完了するまで（ステップＳ５３ノー）、ステップＳ５１の処理が継続される。このストリームデータ記録ステップＳ５１は、図２４のステップＳ０１〜Ｓ０３、Ｓ０６と同様な処理内容である。
【０４７８】
なお、ステップＳ５２の処理は、ステップＳ５１の処理中にこれと並行して実行されてもよい。
【０４７９】
こうして（暗号化された）ストリームデータの記録が完了すると（ステップＳ５３イエス）、ＳＴＢ装置４１６と光ディスク装置４１５との間で基準クロックの同期化処理が実行される（ステップＳ５４）。
【０４８０】
この基準クロックの同期化処理は、たとえば以下のようにして行なうことができる。
【０４８１】
すなわち、ストリームデータ転送時に、トランスポートパケット（アプリケーションパケット）を特定個数（例えば１万個あるいは１０万個）送信／受信する毎にその送信／受信時刻をＳＴＢ装置４１６と光ディスク装置４１５でそれぞれワークメモリ部４０７と一時記憶部４１１に記録しておく。
【０４８２】
その後、ＳＴＢ装置４１６側から光ディスク装置４１５側へトランスポートパケット（アプリケーションパケット）を特定個数送信する毎に送信時刻一覧表を送付する。そして、光ディスク装置４１５側において、送付された一覧表と光ディスク装置４１５側で事前に作成した一覧表とを比較することで、両者間の基準クロック同期ずれ量を算出する。
【０４８３】
その後、ＳＴＢ装置４１６から光ディスク装置４１５へ、時間関係テーブル２（あるいはＰＴＳＬ）が転送される（ステップＳ５５）。
【０４８４】
こうしてＳＴＢ装置４１６から光ディスク装置４１５へ転送された時間関係テーブル２（あるいはＰＴＳＬ）は、ステップＳ５４の基準クロックの同期化処理で算出した基準クロック同期ずれ量の情報を基に、修正される（ステップＳ５６）。
【０４８５】
こうして基準クロック同期ずれ量分修正された時間関係テーブル２（あるいはＰＴＳＬ）が、情報記憶媒体２０１の管理情報領域（図３（ｅ）のＳＴＲＥＡＭ．ＩＦＯ１０５；あるいは図１５のＳＦＩＴ）内に記録される（ステップＳ５７）。
【０４８６】
以上のようにすれば、（暗号化された状態の）ストリームデータの記録／再生が可能になる。
【０４８７】
上記のような「暗号化されたストリームデータに対する基準クロック同期のずれ補正」方法の代わりに、他の方法として、次のようにしてもよい。
【０４８８】
すなわち、図２０（ｂ）に示すように、各Ｉピクチャ間に転送されるトランスポートパケット数を時間関係テーブル２に記録する。そして、（ピクチャ指定方法として）再生開始の画面のタイムスタンプ値を指定する代わりに、セル先頭からの通算トランスポートパケット（またはアプリケーションパケット）数を指定する。
【０４８９】
この場合には、タイムマップ情報２５２内の情報として、図３（ｉ）に示したデータ構造の代わりに、図１１に示すように、ストリームブロック毎に含まれるトランスポートパケット数（またはアプリケーションパケット数ＡＰ＿Ｎｓ）６３３を持たせる。
【０４９０】
所定の画面（ピクチャ）にアクセスするためＳＴＢ装置４１６側から通算トランスポートパケット数（通算アプリケーションパケット数）が指定されると、光ディスク装置４１５側では、図１１に示すの最初のストリームブロックから順次トランスポートパケット（アプリケーションパケット）数６３３が加算されて行き、加算結果が指定された値に達した時点でのストリームブロック（またはＳＯＢＵ）へ、アクセスが行われる。
【０４９１】
図２６は、この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。以下、図２６を用いてストリームデータの再生ステップについて説明する。
【０４９２】
ユーザは、希望する再生開始時刻および／または再生終了時刻を、「指定したオリジナルセルの表示開始時刻を基準とした差分時間（何時間何分何秒）」の形で指定することができる。こうして指定された、たとえば特定の再生開始時刻および再生終了時刻を、ＳＴＢ装置４１６内のＳＴＢ制御部４０４が受け取る（ステップＳ２１）。
【０４９３】
ＳＴＢ制御部４０４内では、その受け取った再生開始時刻および再生終了時刻の時間情報を、２７ＭＨｚおよび／または９０ｋＨｚのクロックカウント値に換算して、オリジナルセルの表示開始時刻からの差分ＰＴＳ値を算出する。
【０４９４】
ＳＴＢ制御部４０４は、光ディスク装置４１５をコントロールしてストリームデータ管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ１０５）内に記録された時間関係テーブル２（またはＰＴＳＬ）を読み取り、ワークメモリ部４０７内に一時記録する（ステップＳ２２）。
【０４９５】
また、ＳＴＢ制御部４０４は、光ディスク装置４１５をコントロールしてストリームデータ管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ１０５）内に記録されたタイムマップ情報２５２（またはＭＡＰＬ）の情報を読み取り、ワークメモリ部４０７内に一時記録する（ステップＳ２３）。
【０４９６】
次に、図３（ｈ）および図２０（ａ）に示したＰＴＳオフセット９の値を読み取り、該当するオリジナルセル（図２０（ａ）ではＢピクチャｆに該当）の表示開始時刻とその直前のＩピクチャａの表示時刻との差（図２０（ａ）ではＰＴＳＮｏ．５−ＰＴＳＮｏ．１）を調べる（ステップＳ２４）。
【０４９７】
さらに、図３（ｈ）および図２０（ａ）に示したＰＴＳオフセット９の値を読み取り、
（イ）その値（ＰＴＳオフセット９）と、
（ロ）オリジナルセルの表示開始時刻の直前のＩピクチャ−ａ位置でのＰＴＳ値（ＰＴＳＮｏ．１）（図２０（ａ）のようにオリジナルセルの表示開始ピクチャｆがＩピクチャａの直後にある場合）と、
（ハ）ステップＳ２４で調べた差分ＰＴＳ値（ＰＴＳＮｏ．５−ＰＴＳＮｏ．１）と
を加算し、ユーザが指定した再生開始時刻と再生終了時刻のＰＴＳ値を算出する（ステップＳ２５）。
【０４９８】
次に、ユーザが指定した再生開始場所の直前のＩピクチャｉのＰＴＳ値とタイムスタンプ＃２の値を、時間関係テーブル２を利用して調べ（ステップＳ２６）、光ディスク装置４１５に通知する。
【０４９９】
光ディスク装置は、図３（ｈ）に示したタイムマップ情報２５２のデータ（図３（ｉ））から、そのＩピクチャｉ情報６０１０（図２１（ｃ））の先頭位置が含まれるストリームブロック（ＳＯＢＵ）＃Ａの先頭のタイムスタンプ（ＡＴＳ）＃１の値を調べるとともに、アクセスすべき先頭セクタ＃αの場所（アドレス）を割り出す（ステップＳ２７）。
【０５００】
こうして割り出されたアドレスに基づいて、光ディスク装置４１５は、図２１（ｃ）のトランスポートパケット（ＡＰ）＃１からの情報を、情報記憶媒体２０１から再生する（ステップＳ２８）。
【０５０１】
次に、図１９のＳＴＢ制御部４０４は、デコーダ部４０２へ、ステップＳ２８で再生を開始した情報の表示開始時刻を示すＰＴＳ値（図２１（ａ）のＰＴＳＮｏ．６）を通知する（ステップＳ２９）。
【０５０２】
この通知とともに、光ディスク装置４１５はＳＴＢ装置４１６側に、ステップＳ２８で再生を開始した情報を転送する（ステップＳ３０）。
【０５０３】
続いて、ＳＴＢ制御部４０４は、デコーダ部４０２内のメモリ４２６からピクチャ識別情報５２（図１（ｋ））を読み取り、入力されたＩピクチャ（光ディスク装置４１５から転送されてきた情報の一部）より前のデータを破棄（あるいは無視）する（ステップＳ３１）。
【０５０４】
次に、図１９のビデオデコード部４２８は、ステップＳ３１で入力されたＩピクチャ（図２１（ａ）ではＩピクチャｉ）の先頭位置からデコードを開始し、ステップＳ２９の通知により指定されたＰＴＳ値（図２１（ａ）のＰＴＳＮｏ．６）のところから、表示（ビデオ出力）を開始する（ステップＳ３２）。
【０５０５】
以下、ステップＳ２４〜Ｓ２８と同様な処理を反復し、再生終了時刻に対応した情報記憶媒体２０１上のアドレスを調べ、再生終了時刻に対応した終了アドレスまで再生を継続する（ステップＳ３３）。
【０５０６】
上記の一連の再生が終了した段階で、図７（ｇ）に示す再生終了位置情報６１１０を、レジューム情報として、管理情報記録領域（図７（ｅ）に示すＳＴＲＥＡＭ．ＩＦＯ１０５）内のビデオマネージャ情報２３１（図７（Ｆ））中に記録することができる。
【０５０７】
この再生終了位置情報６１１０のデータ内容としては、図７（ｈ）に示すように該当するＰＧＣ番号６２１０とその中のセル番号６２２０、再生終了位置時刻情報６２３０が記録される。
【０５０８】
この時刻情報６２３０はタイムスタンプ値で記録されているが、ＰＴＳ値（あるいはセル再生先頭位置からの通算フィールド数）を時刻情報６２３０として記録することもできる。
【０５０９】
再度この再生終了位置情報を（レジューム）情報６１１０の位置から再生開始する場合には、後述する図２７の処理により再生開始位置を求めることができる。
【０５１０】
図２６を参照して上述したような標準再生時には、ＳＴＢ装置４１６内の基準クロック作成部であるＳＴＣ部４２４のカウント値が、図１（ｋ）に示すＤＴＳ（デコードタイムスタンプ）情報５４の値に一致した時から、デコーダ部４０２内のデコードが開始される。
【０５１１】
図２７は、この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。
【０５１２】
早送り再生（ファーストフォワードＦＦ）あるいは早戻し再生（ファーストリバースＦＲ）などの特殊再生を行う場合には、情報記憶媒体２０１上に記録されたＩピクチャ情報のみを抽出再生し、デコード表示する。
【０５１３】
この場合、ＳＴＣ部４２４（図１９）とＤＴＳ情報５４（図１（ｋ））と間の同期をはずし、フリーモードでデコードするように、デコーダ部４０２に対して「特殊再生モードの設定」を行う（ステップＳ４１）。
【０５１４】
特殊再生時にも、時間関係テーブル２とタイムマップ情報２５２の情報を情報記憶媒体２０１の管理情報記録領域（ＳＴＲＡＭ．ＩＦＯ）１０５から読み取り、ＳＴＢ制御部４０４のワークメモリ部４０７内に記録する（ステップＳ４２）。
【０５１５】
次に、該当する再生開始場所に対応したストリームオブジェクト情報（ＳＯＢＩ）２４２のタイムマップ情報２５２を読み取り、ＳＴＢ制御部４０４内のワークメモリ部４０７に一時記録する（ステップＳ４３）。
【０５１６】
次に、時間関係テーブル２から、各Ｉピクチャ位置（図１６の例では各ＡＵ＃の位置）での開始時刻／終了時刻のタイムスタンプ値を抽出する（ステップＳ４４）。
【０５１７】
次に、タイムマップ情報２５２から、該当するＩピクチャのタイムスタンプ値が含まれるストリームブロック（ＳＯＢＵ）を調べ、その先頭セクタのアドレスを調べる（ステップＳ４５）。
【０５１８】
たとえば、特殊再生時には、後述する図２８（ｂ）のＩピクチャ情報６０１０〜６０５０のみがデコードされて表示される。このＩピクチャ情報６０１０〜６０５０の位置は、時間関係テーブル２およびタイムマップ情報２５２の情報を利用して、求めることができる。
【０５１９】
次に、光ディスク装置４１５は、情報記憶媒体２０１上の各Ｉピクチャが含まれる禅ストリームブロック（ＳＯＢＵ）内の情報を再生し、再生した情報を多重化情報分離部４２５内のメモリ部４２６に転送する（ステップＳ４６）。
【０５２０】
次に、図１９のデコーダ部４０２内において、多重化情報分離部４２５のメモリ部４２６に転送されたデータ内のピクチャ識別情報５２（図１（ｋ））を読み取り、この情報５２を基にＩピクチャ以外のデータを破棄する（ステップＳ４７）。
【０５２１】
つまり、ステップＳ４７においては、再生・転送されたストリームデータの中から、ピクチャ識別情報５２を用いてＩピクチャ情報のみが抽出され、ビデオデコード部４２８において抽出されたＩピクチャ情報のみがデコードされる。
【０５２２】
次に、デコーダ部４０２内の多重化情報分離部４２５のメモリ部４２６内部で選別された（つまり破棄されなかった）Ｉピクチャデータを、フレームメモリ部４０６に転送する（ステップＳ４８）。
【０５２３】
こうしてフレームメモリ部４０６に転送されたＩピクチャのデータが、ＴＶ（あるいはビデオモニタ）４３７の表示スクリーン上で、逐次表示される（ステップＳ４９）。
【０５２４】
図２８は、この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。
【０５２５】
図２０の実施の形態では、表示時刻情報として図２０（ｂ）に示すように絶対値表示を行なっているが、その代わりに各Ｉピクチャ間の差分情報（例えば各Ｉピクチャ間に挿入されるフィールド数情報）を使用することも可能である。
【０５２６】
また、図２０（ｂ）では表示時刻情報として”ＰＴＳ情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面（ピクチャ）からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。この場合の例が、図２８の時間関係テーブル６である。
【０５２７】
図２８（ｂ）に示すように、各グループオブピクチャ（ＧＯＰ）は、あるＩピクチャ位置を先頭とし、そのＩピクチャから次のＩピクチャの直前までのピクチャ群を示す。図２８（ｃ）に示した時間関係テーブル６のデータ構造では、表示時間情報として、各ＧＯＰ毎の表示フィールド枚数が記録されている。
【０５２８】
また、時間関係テーブル６内に、ＧＯＰ毎に占有しているストリームブロック（ＳＯＢＵ）の個数も記載している。こうすることで、図３（ｈ）に示したタイムマップ情報２５２を使用せずに、与えられた表示時間情報から、直接、Ｉピクチャ情報の先頭位置が記録してあるストリームブロック（ＳＯＢＵ）へのアクセスか可能となる。
【０５２９】
図２８（ｂ）の例におけるＧＯＰ＃２とＧＯＰ＃３の境界位置では、ＧＯＰの切り替わり位置とストリームブロック（ＳＯＢＵ）の切り替わり位置が一致している。このように隣接ＧＯＰの境界と隣接ＳＯＢＵの境界とが一致する場合に、図２８（ｃ）に示した時間関係テーブル６内のＧＯＰ終端マッチングフラグが”１”に設定される。こうすることにより、Ｉピクチャ情報先頭位置が含まれるストリームブロック位置（ＳＯＢＵ位置）の同定精度を向上させている。
【０５３０】
また、前述したＦＦあるいはＦＲ等の特殊再生時においてはＩピクチャ情報の後端位置を使用するので、図２８（ｃ）の時間関係テーブル６には各ＧＯＰ内のＩピクチャサイズ情報も持たせている。
【０５３１】
図２９は、この発明の一実施の形態において、ストリームデータ（ＳＯＢＵ）内のパケット（ＡＰ）がどのように再生されるかを説明する図である。
【０５３２】
図２９は、図１（ｃ）のストリームブロック＃＃１、＃２、…を、全て一定サイズ（２ＥＣＣブロックサイズ）のＳＯＢＵ＃１、＃２、…で構成した場合を例示している。
【０５３３】
図２９（ｆ）は、ＳＯＢＵ＃１の先頭セクタＮｏ．０（図２９（ｅ））のデータ構造と、ＳＯＢＵ＃１に隣接するＳＯＢＵ＃２の末尾セクタＮｏ．６３（図２９（ｅ））のデータ構造を示している。図示しないが、セクタＮｏ．０〜セクタＮｏ．６２も同様な構想を持つ。
【０５３４】
図２９（ｆ）に示すように、セクタＮｏ．０に対応するストリームパックのパックヘッダにはシステムクロックリファレンスＳＣＲが記録され、セクタＮｏ．６３に対応するストリームパックのパックヘッダにもシステムクロックリファレンスＳＣＲが記録されている。
【０５３５】
いま、再生しようとするピクチャ（ユーザが再生時間で指定したピクチャ）がＳＯＢＵ＃２の中間（図１６では、たとえばＡＵ＃１が示す位置）に存在するとする。ユーザが再生時間で指定したピクチャは、セル開始アプリケーションパケット到着時間ＳＣ＿Ｓ＿ＡＰＡＴに対応する。
【０５３６】
この場合、図１９の記録再生部４０９に含まれるディスクドライブ（図示せず）は、ＳＯＢＵ＃２の中間に直接アクセスすることはできず、ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置にアクセスする。そして、図２９（ａ）のストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６の再生は、ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から始まる。
【０５３７】
ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から再生開始位置（ＳＣ＿Ｓ＿ＡＰＡＴに対応する位置）までの間隔は、図２０（ａ）で説明したＰＴＳオフセット９に対応する。
【０５３８】
ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から再生開始位置（ＳＣ＿Ｓ＿ＡＰＡＴに対応する位置）までの間に存在するアプリケーションパケットは、デコードはされているが、再生出力はされない（画面表示されない）。これは、図２６のステップＳ３１の処理に対応している。
【０５３９】
図２９（ｇ）は、ＰＴＳの情報（ＰＴＳ値あるいはＰＴＳオフセット）と再生しようとするアプリケーションパケットＡＰとが、図２０（ａ）の時間関係テーブル２によって関係付けられていることを図解したものである。
【０５４０】
ここで、上記時間関係テーブルと図１５に示した再生タイムスタンプリストＰＴＳＬとの関係について、改めて整理しておく。
【０５４１】
図１（ｇ）その他に示されたタイムスタンプをＡＴＳとしたとき、図１５の再生タイムスタンプリストＰＴＳＬに含まれるＰＴＳの値とＡＴＳとは、以下のような関係を持つ：
（１）ストリームセルは記録されたビットストリームの一部を参照するものである；
（２）ＡＵ（通常Ｉピクチャ）は記録されたビットストリームの連続した一部である（ＡＵはセルの一部に対応する）；
（３）ＡＵ（セルの一部に対応するＩピクチャ）がどのＳＯＢＵに含まれるかは、ＡＵＳＭにより示される（図１６参照）；
（４）ＰＴＳの値は対応ＡＵの再生時間（表示時刻；あるいはプレゼンテーションタイムＰＴＭ）である（ＡＵに対応するＰＴＳの値は、再生時間に関して、セルの一部に対応する）；
（５）セル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は該当セルのアプリケーションパケットＡＰの到着時間である（ＳＣ＿Ｓ＿ＡＰＡＴは、再生時間に関して、ＰＴＳの値に対応する）；
（６）アプリケーションパケットＡＰは、その先頭にタイムスタンプＡＴＳを伴う（図２９（ｇ）等参照）；
（７）ＰＴＳの値は、ＰＴＳＬに含まれる（図１５参照）；
（８）上記から、ＰＴＳＬに含まれるＰＴＳの値は、ＡＵＳＭ、ＳＣ＿Ｓ＿ＡＰＡＴ等を仲介して、ＡＴＳに対応する。
【０５４２】
よって、再生タイムスタンプリストＰＴＳＬは、ＡＵ（Ｉピクチャ）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）と、ビットストリームに含まれるパケットのタイムスタンプＡＴＳとの関係（再生時間に関する関係）を示す情報（ＰＴＳの値）を含む「時間関係テーブル（図２０（ｂ））」である。
【０５４３】
あるいは、ＰＴＳＬ（時間関係テーブル）は、ＰＴＳの値とＡＴＳとの対応関係を示す情報であるとも言える。
【０５４４】
最後に、各実施の形態の説明中で用いた一部の用語の意味について纏めておく：
＊ストリームオブジェクト（ＳＯＢ）は、記録済みビットストリームのデータを示す。ＳＲ＿ＴＲＡＮＳ．ＳＲＯファイル内には、最大９９９個のＳＯＢを記録できる。
【０５４５】
＊ストリームオブジェクトユニット（ＳＯＢＵ）は、ＳＯＢ内にオーガナイズされる基本単位である。つまり、各ＳＯＢは、ＳＯＢＵの連なり（チェーン）からなる。なお、とくに編集後は、ＳＯＢの先頭および／または末尾のＳＯＢＵは、そのＳＯＢの有効部分に属していないデータを含むことがある。
【０５４６】
ＳＯＢＵは、再生時間あるいは再生順序により特徴付けられるのではなく、一定サイズ（３２セクタ分のサイズあるいは２ＥＣＣブロック分のサイズ）により特徴付けられる。
【０５４７】
＊アクセスユニット（ＡＵ）は、個別の再生に適した記録済みビットストリームにおける、任意の単一連続部分を指す。このＡＵは、ＭＰＥＧエンコードされたビットストリームにおいては、通常はＩピクチャに対応する。
【０５４８】
＊アクセスユニット開始マップ（ＡＵＳＭ）は、該当ＳＯＢのどのＳＯＢＵがＡＵを含むのかを示すものである。
【０５４９】
＊アプリケーションパケット（ＡＰ）は、記録中にアプリケーションデバイスからやってくるビットストリームの一部である。あるいは、ＡＰは、再生中にアプリケーションデバイスへ行くビットストリームの一部である。これらのＡＰは、多重化トランスポートに含まれ、記録中は一定サイズ（最大６４５７４バイト）を持つ。
【０５５０】
＊アプリケーションタイムスタンプ（ＡＴＳ）は、各ＡＰの前に配置され、３２ビット（４バイト）で構成される。ＡＴＳは、９０ｋＨｚの基本部分と２７ＭＨｚの拡張部分とで構成されている。
【０５５１】
＊セル（あるいはストリームセルＳＣ）は、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルはオリジナルセルと呼ばれ、ユーザ定義ＰＧＣ内のセルはユーザ定義セルと呼ばれる。プログラムセット中の各プログラムは、少なくとも１つのオリジナルセルからなる。夫々のプレイリスト内のプログラムの各部分は、少なくとも１つのユーザ定義セルからなる。ストリーマにおいて、単にセルという場合は、ストリームセル（ＳＣ）のことをいう。各ＳＣは記録済みビットストリームの一部を参照するものである。
【０５５２】
＊セル番号（ＣＮ）は、ＰＧＣ内のセルに割り振られた番号（１〜９９９）である。
【０５５３】
＊ストリームセルエントリポイント情報（ＳＣ＿ＥＰＩ）は、記録の一部をスキップするための道具として用いるもので、任意のストリームセル（ＳＣ）内に存在できる。
【０５５４】
＊ストリームオブジェクトの開始アプリケーションパケット到着時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）は、該当ＳＯＢに属する最初のＡＰの到着時間を指す。この到着時間は、９０ｋＨｚの基本部分と２７ＭＨｚの拡張部分とで構成されている。
【０５５５】
＊ストリームオブジェクトの終了アプリケーションパケット到着時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）は、該当ＳＯＢに属する最後のＡＰの到着時間を指す。
【０５５６】
＊ストリームセルの開始アプリケーションパケット到着時間（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当ＳＣに属する最初のＡＰの到着時間を指す。
【０５５７】
＊ストリームセルの終了アプリケーションパケット到着時間（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当ＳＣに属する最後のＡＰの到着時間を指す。
【０５５８】
＊ナビゲーションデータは、ビットストリーム（ＳＯＢ）に対する、記録、再生、および編集の制御をする際に用いられるデータである。
【０５５９】
＊プレイリスト（ＰＬ）は、ユーザが再生シーケンスを任意に定義できるプログラム部分のリストである。ＰＬは、ユーザ定義ＰＧＣとして記述される。
【０５６０】
＊プログラム（ＰＧ）は、ユーザにより認識されあるいは定義されるところの、記録内容の論理単位である。プログラムセット内のプログラムは、１以上のオリジナルセルからなる。プログラムは、オリジナルＰＧＣ内でのみ定義される。
【０５６１】
＊プログラムチェーン（ＰＧＣ）は、上位概念的な単位である。オリジナルＰＧＣの場合、ＰＧＣはプログラムセットに対応するプログラムの連なり（チェーン）を示すものである。一方、ユーザ定義ＰＧＣの場合は、ＰＧＣはプレイリストに対応するものであってプログラムの一部の連なり（チェーン）を示すものである。
【０５６２】
＊プログラムチェーン情報（ＰＧＣＩ）は、ＰＧＣの全体的な再生を示すデータ構造である。ＰＧＣＩはオリジナルＰＧＣおよびユーザ定義ＰＧＣのいずれでも使用される。ユーザ定義ＰＧＣはＰＧＣＩだけで構成され、そのセルはオリジナルＰＧＣ内のＳＯＢを参照するようになっている。
【０５６３】
＊プログラムチェーン番号（ＰＧＣＮ）は、ユーザ定義ＰＧＣに割り振られた連続番号（１〜９９）である。
【０５６４】
＊プログラム番号（ＰＧＮ）は、オリジナルＰＧＣ内のプログラムに割り振られた連続番号（１〜９９）である。
【０５６５】
＊プログラムセットは、全てのプログラムで構成されるディスク（記録媒体）の記録内容全体を指す。オリジナルの記録に対して再生順序が変わるような編集がどのプログラムに対してもなされていないなら、プログラムセットの再生にあたっては、プログラムの記録順序と同じ再生順序が用いられる。
【０５６６】
＊リアルタイム記録とは、バッファメモリサイズが限られている場合において、制限された転送レートでコード化された任意のストリームデータを制限された転送レートで転送している限り、バッファメモリがオーバーフローすることなく、そのストリームデータをディスク（記録媒体）に記録できるような記録をいう。
【０５６７】
この発明に係る各実施の形態における効果をまとめると以下のようになる：
１．ストリームデータ内に記録されたタイムスタンプデータ（ＡＴＳ）とユーザに対する表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブルあるいはＰＴＳＬ）を管理情報（ＳＦＩＴ）の一部に持たせることにより、高い精度で、ユーザが指定した表示時刻から、再生／画面表示を開始させることが可能となる。
【０５６８】
２．ユーザは、編集時に、記録済みのストリームデータの部分消去範囲または並び替えの指定範囲を、モニタＴＶ上での表示時刻で指定する。
【０５６９】
上記「１．」のように、ストリームデータ内に、管理情報（ＳＦＩＴ）の一部として、タイムスタンプデータと表示時刻情報との間の関係を示す時間関係テーブル（あるいはＰＴＳＬ）を持たせる。これにより、この時間関係テーブル（あるいはＰＴＳＬ）を用いて、正確に編集点位置（部分消去範囲あるいは並び替えの指定範囲）を設定することが可能となる。その結果、ストリームデータに対する時間管理をタイムスタンプデータ（ＡＴＳ）を用いて行うことができ、かつユーザリクエストに応じた正確な編集処理を保証できる。
【０５７０】
３．上記「１．」のように、ストリームデータ内に時間関係テーブル（あるいはＰＴＳＬ）を持たせてあるので、タイムスタンプデータ（ＡＴＳ）あるいは表示時刻情報（ＰＴＳ）のいずれか一方の情報を再生終了位置情報（レジューム情報）として記載するだけで、ストリーマ再起動時の再生開始位置（レジューム再生開始位置）を、正確に設定できる。
【０５７１】
４．再生終了位置情報（レジューム情報）をタイムスタンプデータ（ＡＴＳ）で記録することにより、情報記憶媒体上の特定位置にアクセスする場合、タイムマップ情報２５２を用いてアクセスすべきアドレスを、素早く知ることができる。
【０５７２】
５．ＭＰＥＧによる圧縮データは必ずＩピクチャからの再生開始が必要となる。各Ｉピクチャ開始位置（あるいはアクセスユニットＡＵの開始位置）でのタイムスタンプデータ（ＡＴＳ）と表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブル）を記録することにより、所望のＩピクチャ（所望のＡＵ）へのアクセス制御を、タイムマップ情報２５２を用いて高速に行える。
【０５７３】
６．各Ｉピクチャ開始位置（各ＡＵの開始位置）でのタイムスタンプデータ（ＡＴＳ）と表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブル）を記録することにより、タイムマップ情報２５２との組み合わせで、Ｉピクチャ（ＡＵ）を含むストリームブロック（あるいはＳＯＢＵ）位置のアドレスが分かる。このため、Ｉピクチャのみの再生・表示を行うファーストフォワードＦＦあるいはファーストリバースＦＲなどの特殊再生処理が可能となる。
【０５７４】
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
【０５７５】
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から１または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも１つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。
【図面の簡単な説明】
【０５７６】
【図１】この発明の一実施の形態に係るストリームデータのデータ構造を説明する図。
【図２】この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図。
【図３】この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図。
【図４】この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図。
【図５】タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容その他を説明する図。
【図６】オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図。
【図７】この発明の他の実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに再生終了位置情報／レジューム情報、ＶＭＧＩ管理情報／記録時間情報等の構造）を説明する図。
【図８】図１その他に示されたＰＥＳヘッダの内部構造を説明する図。
【図９】図１に示されたストリームブロックヘッダの内部構造を説明する図。
【図１０】図１に示されたセクタデータヘッダの内部構造を説明する図。
【図１１】この発明の一実施の形態におけるタイムマップ情報の他例を説明する図。
【図１２】ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図。
【図１３】ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図。
【図１４】ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１３のＰＧＣＩ＃ｉ）の内部データ構造を説明する図。
【図１５】ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図。
【図１６】アクセスユニット開始マップ（ＡＵＳＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。
【図１７】アクセスユニット開始マップ（ＡＵＳＭ）およびアクセスユニット終了マップ（ＡＵＥＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。
【図１８】オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図。
【図１９】この発明の一実施の形態に係るストリームデータ記録再生システム（光ディスク装置／ストリーマ、ＳＴＢ装置）の構成を説明する図。
【図２０】この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。
【図２１】この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図。
【図２２】ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図。
【図２３】デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図。
【図２４】この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図。
【図２５】この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャート図。
【図２６】この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャート図
【図２７】この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャート図。
【図２８】この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。
【図２９】この発明の一実施の形態において、ストリームデータ（ＳＯＢＵ）内のパケット（ＡＰ）がどのように再生されるかを説明する図。
【符号の説明】
【０５７７】
２０１…情報媒体、４１５…光ディスク装置、４１６…ＳＴＢ装置。
【図１】
2005293835.tif 000003
【図２】
2005293835.tif 000004
【図３】
2005293835.tif 000005
【図４】
2005293835.tif 000006
【図５】
2005293835.tif 000007
【図６】
2005293835.tif 000008
【図７】
2005293835.tif 000009
【図８】
2005293835.tif 000010
【図９】
2005293835.tif 000011
【図１０】
2005293835.tif 000012
【図１１】
2005293835.tif 000013
【図１２】
2005293835.tif 000014
【図１３】
2005293835.tif 000015
【図１４】
2005293835.tif 000016
【図１５】
2005293835.tif 000017
【図１６】
2005293835.tif 000018
【図１７】
2005293835.tif 000019
【図１８】
2005293835.tif 000020
【図１９】
2005293835.tif 000021
【図２０】
2005293835.tif 000022
【図２１】
2005293835.tif 000023
【図２２】
2005293835.tif 000024
【図２３】
2005293835.tif 000025
【図２４】
2005293835.tif 000026
【図２５】
2005293835.tif 000027
【図２６】
2005293835.tif 000028
【図２７】
2005293835.tif 000029
【図２８】
2005293835.tif 000030
【図２９】
2005293835.tif 000031