JP4138776B2 - ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置 - Google Patents

Description

この発明は、デジタル放送などで伝送される映像データあるいはパケット構造をもって伝送されるストリームデータを記録する情報記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法に関する。

近年、ＴＶ放送はデジタル放送の時代に突入してきた。それに伴い、デジタルＴＶ放送のデジタルデータをその内容を問わずデジタルデータのままで保存する装置、いわゆるストリーマが要望されるようになってきた。

現在放送されているデジタルＴＶ放送では、ＭＰＥＧのトランスポートストリームが採用されている。今後も、動画を使用したデジタル放送の分野では、ＭＰＥＧトランスポートストリームが標準的に用いられると考えられる。

このデジタル放送では、放送される内容（主に映像情報）が、トランスポートパケットと呼ばれる所定サイズ（例えば１８８バイト）毎のデータのまとまりに時間分割され、このトランスポートパケット毎に放送データが伝送される。

このデジタル放送データを記録するストリーマとして、現在市販されているものとしては、Ｄ−ＶＨＳ（デジタルＶＨＳ）などの家庭用デジタルＶＣＲがある。このＤ−ＶＨＳを利用したストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、ビデオテープには、複数の番組が多重されて記録されることになる。

再生時には、最初から再生する場合、あるいは途中から再生する場合にも、そのまま全てのデータが、ＶＣＲからセットトップボックス（デジタルＴＶの受信装置：以下ＳＴＢと略記する）に送り出される。このＳＴＢにおいて、ユーザ操作等により、送り出されたデータ内から所望の番組が選択される。選択された番組情報は、ＳＴＢからデジタルＴＶ受像機等に転送されて、再生（ビデオ＋オーディオ等の再生）がなされる。

このＤ−ＶＨＳストリーマでは、記録媒体にテープが用いられるため、素早いランダムアクセスが実現できず、所望の番組の希望位置に素早くジャンプして再生することが困難となる。

このようなテープの欠点（ランダムアクセスの困難性）を解消できる有力な候補として、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用したストリーマが考えられる。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性が出てくる。

ここで、デジタルＴＶの受信装置であるＳＴＢとＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用したストリーマとの間、あるいはこの大容量ディスクメディアを利用したストリーマとＤ−ＶＨＳ等を利用した他のストリーマとの間のデータ転送には、ＩＥＥＥ１３９４等に準拠したデジタルインターフェースを利用できる。

このデジタルインターフェースでは、デジタル放送で受信したトランスポートパケット毎に映像データ／ストリームデータが転送される。

たとえばＩＥＥＥ１３９４を用いたデジタルインターフェースでは、デジタル放送の受信データに対して実時間での転送を保証するため、各トランスポートパケット毎に受信時刻を表すタイムスタンプデータが付加されて、転送が行なわれている。

また、ＤＶＤ−ＲＡＭなどの情報記憶媒体に記録された上記デジタル放送の受信データに対してＳＴＢでの実時間による間断の無い再生を保証するため、情報記憶媒体上に、各トランスポートパケットデータとともに上記タイムスタンプデータも同時に記録される。

上記の場合、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用した情報記憶媒体に記録するストリームデータとして、トランスポートパケット毎にタイムスタンプデータが付加されて記録されている。このため、このタイムスタンプデータを利用して時間管理を行うことになる。

デジタルＴＶでは、映像データはＭＰＥＧ２と呼ばれるデジタル圧縮方式を用いて情報圧縮された形で放送される。このＭＰＥＧ２方式によると、Ｐピクチャ情報はＩピクチャに対する差分情報しか持たず、またＢピクチャ情報はＩピクチャとＰピクチャに対する差分情報しか持っていない。したがって、ＢピクチャあるいはＰピクチャは単独で再生することができず、これらを再生するためにはＩピクチャからの再生が必要となる。

ここで、Ｉ、Ｂ、Ｐの各ピクチャの表示時刻で示されるユーザから見た映像再生時間と、前記タイムスタンプ時間とは異なる。このため、情報記憶媒体上に記録したストリームデータに対する時間管理をタイムスタンプデータのみで行った場合には、ユーザに対する表示時刻（映像再生時間）の制御が正確に行えないという問題が生じる。

この発明は上記事情に鑑みなされたもので、その目的は、ストリーム情報記録の処理に関する改善を図ることである。

上記目的を達成するために、この発明の実施の形態では、ストリームデータを記録するように構成されたデータエリア（ＳＴＲＥＡＭ．ＶＲＯ）と、このストリームデータに関する管理情報（ＳＴＲＩ）を記録するように構成された管理エリア（ＳＴＲＥＡＭ．ＩＦＯ）とを持つ情報媒体（２０１）が用いられる。ここで、前記管理情報（図１３のＳＴＲＩ／図１５のＳＦＩＴ）が、前記ストリームデータの特定部分（図１６〜図１７のＡＵ）に対応した時間情報（図１５のＰＴＳＬ）を含むように構成される。

なお、前記ストリームデータは、一定サイズのデータユニット（例えば６４ｋＢのＳＯＢＵ）で構成することができる。

ストリーム情報記録の処理に関する改善を図ることができる。

以下、図面を参照して、この発明の一実施の形態に係るストリームデータ記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法その他を説明する。

図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図１を用いて情報記憶媒体上に記録されたストリームデータのデータ構造について説明する。

ＤＶＤ−ＲＡＭディスク等の情報記憶媒体（図３その他の２０１）上に記録されるストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６（図１（ａ））は、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（以下、適宜ＳＯＢと略記する）としてまとめられている。つまり、各ＳＯＢは、１つのリアルタイムな連続記録により得られたストリームデータにより形成される。

情報記憶媒体上に記録されるストリームデータは、図１（ｂ）に示されるように、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（ＳＯＢ）＃Ａ・２９８、＃Ｂ・２９９としてまとまって記録されている。

図１（ｂ）〜（ｋ）は、複数あるストリームオブジェクト（ＳＯＢ＃Ａ、＃Ｂ、…）のうち、１個のＳＯＢ＃Ａ・２９８について内容を詳細に示している。

ＤＶＤ−ＲＡＭディスクにトリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６が記録される場合には、各々が２０４８バイトのセクタを最小単位として記録される。さらに、１６個のセクタをまとめて１個のＥＣＣブロックとし、同一ＥＣＣブロック内でインターリーブ（データ配列順序の並び替え）とエラー訂正用の訂正コードの付加が行われる。

この実施の形態では、１個または複数（代表的には２個）のＥＣＣブロックを単位としてストリームブロック（あるいはストリームオブジェクトユニットＳＯＢＵ）が構成され、このストリームブロック単位（あるいはＳＯＢＵ単位）でストリーム情報の記録、部分消去、編集その他が行われる。

この実施の形態では、何個のＥＣＣブロックでストリームブロックが構成されるかは、転送されるストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６の転送レートに応じて決めることができる。

たとえば、図１（ｃ）（ｄ）の例では、ストリームブロック＃１は２つのＥＣＣブロック＃α、＃βで構成され、ストリームブロック＃２は３つのＥＣＣブロック＃γ、＃δ、＃εで構成されている。ＤＶＤストリーマでは、２個のＥＣＣブロック（３２セクタ）で１つのストリームブロック（またはＳＯＢＵ）が構成される。

各ＥＣＣブロックは、図１（ｅ）に示すように、１６セクタで構成される。したがって、図１（ｃ）〜（ｅ）から分かるように、２ＥＣＣブロックで構成されるストリームブロック（あるいはＳＯＢＵ）＃１は、３２セクタ（セクタＮｏ．０〜セクタＮｏ．３１）に相当する。

つまり、１セクタ＝２ｋバイトとすれば、ストリームブロック（ＳＯＢＵ）は、６４ｋバイト（３２セクタ）の固定サイズとして、この発明を実施することができる。

ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６は、図１（ｇ）に示すようにタイムスタンプとトランスポートパケットを組にして、情報記憶媒体に記録される。

その際、各セクタの先頭には、図１（ｆ）に示すように、システムクロック情報（システムクロックリファレンスＳＣＲ）等が記録されたパックヘッダ１１、１２とＰＥＳヘッダ１３、１４が配置される。ＰＥＳヘッダ１４の直後にはセクタデータヘッダ１７が記録されるが、各ストリームブロック（またはＳＯＢＵ）先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ１６が記録される。

なお、ストリームブロックヘッダ１６あるいはセクタデータヘッダ１７は、後述するアプリケーションヘッダに対応する内容を持つことができるようになっている（図９あるいは図１０参照）。

図１（ｆ）のセクタデータヘッダ１７は、データエリア２２、２３内のデータ配列情報を示している。

図１（ｆ）のデータエリア２１、２２（あるいは２３）には、図１（ｇ）に示すように、タイムスタンプ（図２０、図２９その他に示したＡＴＳに対応）およびトランスポートパケット（図２２または図２３のパケット、あるいは図２９のアプリケーションパケットＡＰに対応）が逐次詰め込まれる。

図１（ｇ）の例では、１個のトランスポートパケットｄが複数のセクタ（Ｎｏ．０とＮｏ．１）に跨って記録される場合が例示されている。このようなトランスポートパケットｄは、図２２または図２３の部分パケットに対応する。

ところで、デジタル放送では、トランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式が採用されており、１個のトランスポートパケットのサイズは１８８バイト（または１８３バイト）の場合が多い。

一方、前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても、１個のデータエリア２１、２２、２３（図１（ｆ））内には、デジタル放送用のトランスポートパケットを１０個前後記録できる。

トランスポートパケット内は、図１（ｈ）に示すように、トランスポートパケットヘッダ６１〜６４（後述する図２３（ｂ）の５１１に対応）とデータが記録されているペイロード７１〜７５（後述する図２３（ｂ）の５１２に対応）とで構成されている。

ペイロード７１〜７５には、図１（ｉ）に示すように、ＭＰＥＧエンコードされたＩピクチャ情報３１、Ｂピクチャ情報３３、３４、およびＰピクチャ情報３２が記録される。

Ｉピクチャ情報３１が記録されている最初のトランスポートパケットでは、ランダムアクセスインジケータ５０３（図２３（ａ）参照）に”１”のフラグが立ち、各Ｂ、Ｐピクチャ情報３２〜３４の最初のトランスポートパケットにはペイロードユニット開始インジケータ５０１（図２３（ａ）参照）に”１”のフラグが立つ。

ペイロード７１〜７５内に分割記録されている各ピクチャ情報３１〜３４には、図１（ｊ）に示すように、それぞれの先頭に、ピクチャヘッダ情報４１と、実質的なピクチャ情報であるピクチャ圧縮情報４２（Ｉピクチャ情報３１に対してはＩピクチャ圧縮情報４２）とが記録されている。

また、それぞれのピクチャヘッダ情報４１内には、図１（ｋ）に示すように、ヘッダ識別情報５１、それぞれのＩ、Ｂ、Ｐピクチャの識別を可能とするピクチャ識別情報５２、デコーダ出力の表示タイミングを示すＰＴＳ（プレゼンテーションタイムスタンプ）情報５３、およびデコーダがデコード開始を行うためのタイミングを示すＤＴＳ（デコードタイムスタンプ）情報５４が記録されている。これらのピクチャヘッダ情報４１は、デジタル放送の受信情報内に予め含まれている。

情報記憶媒体上に記録されたストリームデータ内では、図１（ｋ）に示すピクチャ識別情報５２を用いて特定のピクチャ位置を同定できる。

あるいは、図１（ｊ）（ｋ）に示すようにピクチャヘッダ情報４１内にＰＴＳ情報５３が記録されているので、この値を用いてデコーダが表示を開始することも可能である。

図２は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図２を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容（ファイル構造）について説明する。

ＤＶＤーＲＡＭディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、ＤＶＤ＿ＲＴＲディレクトリ（またはＤＶＤ＿ＲＴＡＶ）１０２と言う名のサブディレクトリ１０１内に入っている。

ＤＶＤ＿ＲＴＲ（ＤＶＤ＿ＲＴＡＶ）ディレクトリ１０２内には、以下の内容のデータファイル１０３が格納される。

すなわち、管理情報（ナビゲーションデータ）のグループとして、ＲＴＲ．ＩＦＯ（またはＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、ＳＲ＿ＰＲＩＶＴ．ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａとが格納される。

また、データ本体（コンテンツ情報）として、ＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と、ＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、ＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、ＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが格納される。

上記データファイル１０３を含むサブディレクトリ１０１の上位階層にあるルートディレクトリ１００には、その他の情報を格納するサブディレクトリ１１０を設けることができる。

このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットＶＩＤＥＯ＿ＴＳ１１１、オーディオプログラムを収めたオーディオタイトルセットＡＵＤＩＯ＿ＴＳ１１２、コンピュータデータ保存用のサブディレクトリ１１３等がある。

有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。

そのストリームデータそのものはＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯとそのバックアップファイルＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５である。

また、ＶＣＲ（ＶＴＲ）あるいは従来ＴＶなどで扱われるアナログ映像情報をＭＰＥＧ２規格に基づきデジタル圧縮して記録されたファイルが、ＲＴＲ＿ＭＯＶ．ＶＲＯ（またはＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７であり、アフターレコーディング音声あるいはバックグランド音声等を含む静止画像情報を集めたファイルがＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８であり、そのアフレコ音声情報ファイルがＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９である。

図３は、この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図である。

図３（ａ）の情報記憶媒体２０１の内周方向２０２の端部と外周方向２０３の端部とで挟まれた領域には、図３（ｂ）に示すように、リードインエリア２０４と、ファイルシステム情報が記録されているボリューム＆ファイル構造情報２０６と、データエリア２０７と、リードアウトエリア２０５が存在する。リードインエリア２０４はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア２０５は書替可能データゾーンで構成されている。データエリア２０７も書替可能データゾーンで構成されている。

データエリア２０７内は、図３（ｃ）に示すように、コンピュータデータとオーディオ＆ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア２０８およびコンピュータデータエリア２０９の間に、オーディオ＆ビデオデータエリア２１０が、挟まれる形態となっている。

オーディオ＆ビデオデータエリア２１０内は、図３（ｄ）に示すように、リアルタイムビデオ記録エリア２２１およびストリーム記録エリア２２２の混在記録が可能となっている。（リアルタイムビデオ記録エリア２２１あるいはストリーム記録エリア２２２の一方だけを使用することも可能である。）
図３（ｅ）に示すように、リアルタイムビデオ記録エリア２２１には、図２に示された、ＲＴＲのナビゲーションデータＲＴＲ．ＩＦＯ（ＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ムービーリアルタイムビデオオブジェクトＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、スチルピクチャリアルタイムビデオオブジェクトＲＴＲ＿ＳＴＯ．ＶＲＯ（ＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、アフターレコーディング等のオーディオオブジェクトＲＴＲ＿ＳＴＡ．ＶＲＯ（ＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが記録される。

同じく図３（ｅ）に示すように、ストリーム記録エリア２２２には、図２に示された、ストリーマのナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、トランスポートビットストリームデータＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＶＲＯ）１０６とが記録される。

なお、図３（ｄ）（ｅ）では図示しないが、ストリーム記録エリア２２２には、図２に示したアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ，ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａを記録することもできる。

このＳＲ＿ＰＲＩＶＴ，ＤＡＴ１０５ａは、ストリーマに接続（供給）された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。

ストリームデータに関する管理情報であるＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図３（ｆ）〜（ｉ）に示すようなデータ構造を有している。

すなわち、図３（ｆ）に示すように、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、ビデオマネージャ（ＶＭＧＩまたはＳＴＲ＿ＶＭＧＩ）２３１と、ストリームファイル情報テーブル（ＳＦＩＴ）２３２と、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）２３３と、ユーザ定義ＰＧＣ情報テーブル（ＵＤ＿ＰＧＣＩＴ）２３４と、テキストデータマネージャ（ＴＸＴＤＴ＿ＭＧ）２３５と、製造者情報テーブル（ＭＮＦＩＴ）またはアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ．ＤＡＴ１０５ａを管理するアプリケーションプライベートデータマネージャ（ＡＰＤＴ＿ＭＧ）２３６とで構成されている。

図３（ｆ）のストリームファイル情報テーブル（ＳＦＩＴ）２３２は、図３（ｇ）に示すように、ストリームファイル情報テーブル情報（ＳＦＩＴＩ）２４１と、１以上のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３、………と、オリジナルＰＧＣ情報一般情報２７１と、１以上のオリジナルセル情報＃１・２７２、＃２・２７３………とを含むことができるようになっている。

図３（ｇ）の各ストリームオブジェクト情報（たとえばＳＯＢＩ＃Ａ・２４２）は、図３（ｈ）に示すように、ストリームオブジェクト一般情報（ＳＯＢＩ＿ＧＩ）２５１、タイムマップ情報２５２、その他を含むことができる。

また、図３（ｇ）の各オリジナルセル情報（たとえば＃１・２７２；後述するが図１４で示されるＳＣＩに対応）は、図３（ｈ）に示すように、セルタイプ２８１（後述するが図１４で示されるＣ＿ＴＹに対応）と、セルＩＤ２８２と、該当セル開始時間（後述する図６（ｂ）、図１４その他で示されるＳＣ＿Ｓ＿ＡＰＡＴに対応）２８３と、該当セル終了時間（後述する図６（ｂ）、図１４その他で示されるＳＣ＿Ｅ＿ＡＰＡＴに対応）２８４と、ＰＴＳオフセット９と、時間関係テーブル２とを含むことができる。

ここで、ＰＴＳオフセット９とは、オリジナルセル（オリジナルセルの詳細は後述する）の表示開始ピクチャのＰＴＳ（プレゼンテーションタイムスタンプ）値とその直前にあるＩピクチャのＰＴＳ値との差分をいう（詳細は図２０を参照して後述）。

図３（ｇ）のＳＯＢＩ＃Ａに含まれる図３（ｈ）のタイムマップ情報２５２は、図３（ｉ）に示すように、ストリームブロック番号２６１、第１ストリームブロックサイズ２６２、第１ストリームブロック時間差２６３、第２ストリームブロックサイズ２６４、第２ストリームブロック時間差２６５、………を含むことができる。タイムマップ情報２５２を構成する各ストリームブロック時間差の内容については、図５を参照して後述する。

図４は、この発明の一実施の形態におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図である。以下、図４の例示を用いてＳＯＢとＰＧＣの関係を説明する。

ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯまたはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームデータは、１個以上のＥＣＣブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等がなされる。このストリームデータは、記録する情報の内容毎（たとえばデジタル放送での番組毎）にストリームオブジェクトと言うまとまりを作る。

ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームオブジェクト（ＳＯＢ＃Ａ、ＳＯＢ＃Ｂ）毎の管理情報（オリジナルＰＧＣ情報２３３、ユーザ定義ＰＧＣ情報テーブル２３４等）は、ナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５（図４の最下部および図３（ｅ）（ｆ）参照）内に記録されている。

図４の各ストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９毎の管理情報（ＳＴＲＥＡＭ．ＩＦＯ１０５）は、図３（ｆ）（ｇ）に示すように、ストリームファイル情報テーブル（ＳＦＩＴ）２３２内のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３として記録されている。

ストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、（ＳＯＢＩ）＃Ｂ・２４３それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報２５２を含んでいる。

ストリームデータの再生時には、１個以上のセルの連続で構成されるプログラムチェーン（ＰＧＣ）の情報（後述する図１４のＰＧＣＩ＃ｉに対応）が利用される。このＰＧＣを構成するセルの設定順にしたがって、ストリームデータを再生することができる。

ＰＧＣには、ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６に記録された全ストリームデータを連続して再生することのできるオリジナルＰＧＣ２９０（図３（ｆ）ではＯＲＧ＿ＰＧＣＩ・２３３）と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義ＰＧＣ＃ａ・２９３、＃ｂ・２９６（図３（ｆ）ではＵＤ＿ＰＧＣＩＴ・２３４の中身に対応）の２種類が存在する。

オリジナルＰＧＣ２９０を構成するオリジナルセル＃１・２９１、＃２・２９２は、基本的にストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９と一対一に対応して存在する。

それに対して、ユーザ定義ＰＧＣを構成するユーザ定義セル＃１１・２９４、＃１２・２９５、＃３１・２９７は、１個のストリームオブジェクト＃Ａ・２９８または＃Ｂ・２９９の範囲内では任意の位置を設定することができる。

なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図４のストリームブロック＃１のように、２ＥＣＣブロック（３２セクタ）で一定サイズ（６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）を、ストリームブロックとして採用するとよい。

このようにストリームブロックを一定サイズ（たとえば２ＥＣＣブロック＝３２セクタ＝６４ｋバイト）のＳＯＢＵに固定すれば、次の利点が得られる：
（０１）ＳＯＢＵ単位でストリームデータの消去あるいは書替を行っても、そのＳＯＢＵのＥＣＣブロックが、消去あるいは書替対象以外のＳＯＢＵのＥＣＣブロックに影響しない。そのため、消去あるいは書替に伴う（消去あるいは書替の対象でないＳＯＢＵに対する）ＥＣＣのデインターリーブ／インターリーブのやり直しが、生じない；
（０２）任意のＳＯＢＵ内部の記録情報に対するアクセス位置を、セクタ数（あるいはセクタ数に対応した他のパラメータ；たとえば後述する図１０のストリームパックおよびその内部のアプリケーションパケット群の情報）で特定できる。たとえば、あるＳＯＢＵ＃ｋの中間位置にアクセスする場合は、ＳＯＢＵ＃ｋー１とＳＯＢＵ＃ｋとの境界から１６セクタ目（あるいは１６セクタ目に対応するアプリケーションパケットの位置）を指定すればよい。

図５は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図５を用いてタイムマップ情報２５２内の各データの内容について説明する。

図５（ｆ）（ｇ）（ｈ）に例示するように、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１、＃２で構成されている。

図５（ｆ）（ｈ）の例では、ＳＯＢ＃Ａ・２９８を構成するストリームブロック＃１のデータサイズは２ＥＣＣブロック（＃α、＃β）で構成され、３２セクタ分（図５（ｅ）（ｉ））のサイズを持っている。すなわち、タイムマップ情報２５２（図５（ａ）（ｋ））内の第１ストリームブロックサイズ２６２（図５（ｊ））は、３２セクタ（６４ｋバイト）となる。

ＳＯＢ＃Ａ・２９８（図５（ｇ））の先頭にあるストリームブロック＃１（図５（ｆ））はその先頭にセクタＮｏ．０（図５（ｅ））を持ち、セクタＮｏ．０に含まれるデータエリア２１（図５（ｄ））の先頭にはタイムスタンプａ（図５（ｃ））が記録されている。

また、ＳＯＢ＃Ａ・２９８（図５（ｇ））の後続ストリームブロック＃２（図５（ｆ））はその先頭にセクタＮｏ．３２（図５（ｅ））を持ち、セクタＮｏ．３２に含まれるデータエリア３１１（図５（ｄ））の先頭にはタイムスタンプｐ（図５（ｃ））が記録されている。

図５（ｃ）に示すように、ストリームブロック＃１の最初のストリームデータのタイムスタンプ値はタイムスタンプａであり、次のストリームブロック＃２の最初のストリームデータのタイムスタンプ値はタイムスタンプｐとなっている。

図５（ｂ）の第１ストリームブロック時間差２６３（図３（ｉ）のストリームブロック時間差２６３に対応）の値は、上記タイムスタンプｐとタイムスタンプａとの差分値（［タイムスタンプｐ］−［タイムスタンプａ］）で与えられる。

なお、図５（ａ）のタイムマップ情報２５２は、図１５を参照して後述するストリームオブジェクト情報ＳＯＢＩ内のアクセスデータユニットＡＵＤも含むものとして、取り扱うことができる。このＡＵＤに含まれる情報（アクセスユニット開始マップＡＵＳＭ等）により、アクセスしたい情報を含むＳＯＢＵを特定できる。

図６は、オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図である。それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。

具体的には、ストリームデータの録画直後のオリジナルセルにおける該当セルの開始時間２８３および該当セルの終了時間２８４（図６（ｂ））の時間として、該当するストリームオブジェクト＃Ａ・２９８（図６（ｆ））内の最初のタイムスタンプａの値および最後のタイムスタンプｚ（図６（ｃ））の値が使用される。

それに対して、ユーザ定義セル＃１２・２９５（図６（ｋ））での時間範囲指定は、任意時刻を指定できる。たとえば、図６（ｉ）（ｊ）に示すように指定されたトランスポートパケットｄ、ｎに対応したタイムスタンプｄ、ｎの値を、該当セルの開始時間３３１と該当セルの終了時間３３２の値として設定することができる。

図６（ｆ）は、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１および＃２で構成されている場合を例示している。

図６（ｅ）（ｇ）の例では、ストリームブロック＃１は３２セクタ（セクタＮｏ．０〜Ｎｏ．３１）で構成され、ストリームブロック＃２は４８セクタ（セクタＮｏ．３２〜Ｎｏ．７９）で構成されている。

ストリームブロック＃１の先頭セクタＮｏ．０は、図６（ｅ）（ｄ）に示すように、パックヘッダ１、ＰＥＳヘッダ６、ストリームブロックヘッダ１１、データエリア２１等で構成されている。

また、ストリームブロック＃２の後方セクタＮｏ．７８は、図６（ｅ）（ｄ）に示すように、パックヘッダ３、ＰＥＳヘッダ８、セクタデータヘッダ１３、データエリア２４等で構成されている。

さらに、図６（ｇ）のセクタＮｏ．１には図６（ｈ）に示すようにパックヘッダ２、セクタデータヘッダ１２、データエリア２２その他が記録され、図６（ｇ）のセクタＮｏ．３３には図６（ｈ）に示すようにセクタデータヘッダ３２１、データエリア３１２その他が記録されている。

図６（ｄ）（ｈ）のデータエリア２１には、図６（ｃ）（ｉ）に示すように、タイムスタンプａとトランスポートパケットａとのペアないしタイムスタンプｄとトランスポートパケットｄとのペアが記録されている。

また、図６（ｄ）のデータエリア２４の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプｚ＋トランスポートパケットｚのペアの後に続くエンドコード３２と、パディングエリア３７が記録されている。

さらに、図６（ｈ）のデータエリア２２には、図６（ｉ）に示すように、データエリア２１のトランスポートパケットｄの後続内容を含むトランスポートパケットｄが含まれている。つまり、この例では、トランスポートパケットｄの内容が、データエリア２１とデータエリア２２とで分断されて記録されている。

図６（ｉ）のトランスポートパケットｄの前半部分（データエリア２１側）は、後述する図２３（ｆ）の末尾側部分パケットに対応し、図６（ｉ）のトランスポートパケットｄの後半部分（データエリア２２側）は、後述する図２３（ｇ）の先頭側部分パケットに対応している。

さらに、図６（ｈ）のデータエリア３１２には、図６（ｉ）に示すように、タイムスタンプｎとトランスポートパケットｎとのペアおよびその他の同様なペアが記録されている。

ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間３３１（図６（ｊ））は、データエリア２１および２２に分断された２つのトランスポートパケットｄ全体に対するタイムスタンプｄ（図６（ｉ））により指定される。

トランスポートパケットをアプリケーションパケット（ＡＰ）と読み替え、アプリケーションパケット到着時間をＡＰＡＴとした場合に、上記セル開始時間３３１は、セル開始ＡＰＡＴとして表現できる。

また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間３３２（図６（ｊ））は、データエリア３１２のトランスポートパケットｎに対するタイムスタンプｎ（図６（ｉ））により指定される。このセル終了時間３３２は、セル終了ＡＰＡＴとして表現できる。

以上のセル開始時間（セル開始ＡＰＡＴ）３３１およびセル終了時間（セル終了ＡＰＡＴ）３３２は、図６（ｋ）に示すように、ユーザ定義セル情報＃１２・２９５内部に記録できる。

このユーザ定義セル情報＃１２・２９５は、図３（ｆ）または図４下段に示すユーザ定義ＰＧＣ情報テーブル２３４内に記録することができる。

以上はユーザ定義セル情報（ユーザ定義ＰＧＣの情報）に関するセル開始／終了時間情報についてであるが、オリジナルセル情報（オリジナルセルの情報）に関するセル開始／終了時間情報については、次のような例示ができる。

すなわち、図６（ｃ）の先頭側タイムスタンプａにより図６（ｂ）の該当セルの開始時間２８３を示すことができ、末尾側タイムスタンプｚにより該当セルの終了時間２８４を示すことができる。

図６（ｂ）の該当セルの開始時間２８３は、セル開始ＡＰＡＴ（ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）または消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）も含む）に対応させることができる。

また、図６（ｂ）の該当セルの終了時間２８４は、セル終了ＡＰＡＴ（ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）または消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）も含む）に対応させることができる。

以上のセル開始時間（セル開始ＡＰＡＴ）２８３およびセル終了時間（セル終了ＡＰＡＴ）２８４は、図６（ａ）に示すように、オリジナルセル情報＃１・２７２内部に記録される。

このオリジナルセル情報＃１・２７２は、図３（ｆ）または図４下段に示すオリジナルＰＧＣ情報２３３内に記録することができる。

図７は、この発明の他の実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに再生終了位置情報／レジューム情報、ＶＭＧＩ管理情報／記録時間情報等の構造）を説明する図である。

図７（ａ）〜（ｆ）のデータ構成は、図３（ａ）〜（ｆ）と同じなので、その説明は省略する。

図７（ｆ）のビデオマネージャ（ＳＴＲ＿ＶＭＧＩ）２３１は、図７（ｇ）に示すように、再生終了位置情報（レジューム情報）６１１０、ビデオマネージャ管理情報（ＶＭＧＩ＿ＭＡＴ）６１１１その他を含んでいる。

再生終了位置情報（レジューム情報）６１１０は、図７（ｈ）に示すように、オリジナルＰＧＣ番号６２１０、オリジナルセル番号６２２０、再生終了位置時刻（レジューム時刻）情報６２３０等を含んでいる。

また、ビデオマネージャ管理情報（ＶＭＧＩ＿ＭＡＴ）６１１１は、タイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０を含んでいる。

記録済みのストリームブロック（またはオリジナルセル）の再生が終了した段階で、再生終了位置情報６１１０をレジューム情報として図７（ｅ）の管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）内のビデオマネージャ情報２３１中に記録することができる。

なお、再生終了位置情報６１１０に含まれる時刻情報６２３０はタイムスタンプ（ＡＴＳ）値で記録されているが、それに限らずＰＴＳ値（あるいはセル再生先頭位置からの通算フィールド数）を時刻情報６２３０として記録することもできる。

タイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０は、図７（ｉ）に示すように、記録時間（ＲＥＣ＿ＴＭ）の情報を含む。

記録時間（ＲＥＣ＿ＴＭ）の情報は、ＲＥＣ＿ＴＭがユニバーサル・タイム・コオーディネート（ＵＴＣ）によるものか特定のローカルタイムによるものかを識別するタイムゾーンタイプ（ＴＺ＿ＴＹ）と、ＵＴＣからのＲＥＣ＿ＴＭのタイムオフセットの日時を分単位で記述したタイムゾーンオフセット（ＴＺ＿ＯＦＦＳＥＴ）とを含んでいる。

上記記録時間（ＲＥＣ＿ＴＭ）は、図６（ｂ）等で示したセル開始時間（ＳＣ＿Ｓ＿ＡＰＡＴ）の形式あるいはそのセルの再生時刻（プレゼンテーションタイムＰＴＭ）の形式で記述してもよい。

この記録時間（ＲＥＣ＿ＴＭ）には２種類ある。第１はストリームオブジェクト記録時間（ＳＯＢ＿ＲＥＣ＿ＴＭ）であり、第２はプレイリスト作成時間（ＰＬ＿ＣＲＥＡＴＥ＿ＴＭ）である。

ここで、オリジナルセルに対応するストリームオブジェクト（ＳＯＢ）が記録された時間が、ＳＯＢ＿ＲＥＣ＿ＴＭにより示される。

また、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。このようなプレイリストが作成された時間が、ＰＬ＿ＣＲＥＡＴＥ＿ＴＭにより示される。

図８は、図１その他に示されたＰＥＳヘッダの内部構造を説明する図である。

図８（ａ）のＰＥＳヘッダ６０１は、図８（ｂ）に示すように、パケット開始コードプリフィックス６０２、ストリームＩＤ６０３、再生タイムスタンプ６０４等を含んでいる。このＰＥＳヘッダ６０１は、図１（ｆ）、図５（ｄ）、図６（ｄ）等のＰＥＳヘッダに対応している。

また、図８（ｄ）のストリームＰＥＳヘッダは、図８（ｃ）に示すように、パケット開始コードプリフィックス、ストリームＩＤ（プライベートストリーム２）、ＰＥＳパケット長、サブストリームＩＤ等を含んでいる。このストリームＰＥＳヘッダは、後述する図２２のストリームＰＥＳヘッダと同じもので、図８（ａ）のＰＥＳヘッダ６０１に対応する内容を持つ。

図１（ｆ）のＰＥＳヘッダが図８（ａ）に示すＰＥＳヘッダ６０１の内部構造を持つときは、ＭＰＥＧの規格では、このＰＥＳヘッダのストリームＩＤ６０３（図８（ｂ））が”１０１１１１１０”のときに、このＰＥＳヘッダを持つパケットを、パディングパケット（後述する図１２（ｇ）参照）にすると定義されている。

一方、ストリームＩＤ６０３（図８（ｃ）のサブストリームＩＤ）が”００００００１０”のときは、そのＰＥＳパケットの付いたパケットは、ストリーム記録データを含むことになる。

図１（ｃ）のストリームブロック＃１では、最後のトランスポートパケットｇ（図１（ｇ））がセクタＮｏ．０〜Ｎｏ．３１（図１（ｅ））内に存在している。しかし、ストリームブロック＃２（図１（ｅ）（ｇ））では、ユーザ等により途中で録画が終了されると、最後のトランスポートパケット（図示せず）が最後のセクタより前のセクタに配置され、最後のセクタ（図示せず）内はストリームデータが記録されていない空き領域となることがある。この場合、最後のセクタには、上記パディングパケット（後述する図１２（ｇ）のパディングパケット４０）が記録される。

図９は、図１に示されたストリームブロックヘッダの内部構造を説明する図である。

ストリームブロックヘッダ１１は、図９（ａ）に示すように、サブストリームＩＤ、アプリケーションヘッダ、アプリケーションヘッダエクステンション、スタッフィングバイト等に対応した内容を持つ。

１バイトのアプリケーションヘッダエクステンション（オプション）には、１ビットのＡＵ＿ＳＴＡＲＴと、１ビットのＡＵ＿ＥＮＤと、２ビットのＣＯＰＹＲＩＧＨＴとが、記述される。

ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連するアプリケーションパケット（たとえば図２９のＡＰ）が、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。

ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。

ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。

ストリームブロックヘッダ１１は、図９（ｂ）に示すように、トランスポートパケット情報６１１、ストリームブロック情報６１２、セクタデータヘッダ情報６１３等を含んでいる。

図９（ｂ）のトランスポートパケット情報６１１は図９（ｃ）のトランスポートパケット情報６１１と同じものを指す。

ストリームブロック全体に関する情報が記録されている図９（ｂ）のストリームブロック情報６１２は、図９（ｃ）の記録時間６２２（情報記憶媒体２０１に記録した年月日と時刻情報）、トランスポートパケット属性６２３（トランスポートパケットに関する属性情報）、ストリームブロックサイズ６２４（該当するストリームブロックのデータサイズ（たとえばＥＣＣブロック数で記載できる））、ストリームブロック時間差６２５等に対応する。

ここで、図５（ｂ）を例にとれば、該当ストリームブロック内の時間範囲情報は、［ストリームブロック時間差］＝［ストリームブロック＃２内の最初にくるタイムスタンプ値］−［タイムスタンプａの値］として計算される。この［ストリームブロック時間差］が、ストリームブロック時間差６２５となる。

また、図９（ｂ）のセクタデータヘッダ情報６１３は、図９（ｃ）のファーストアクセスポイント６２６およびトランスポートパケット接続フラグ６２７に対応する。このセクタデータヘッダ情報６１３は、後述する図１０のセクタデータヘッダ１２と同様な情報を含んでいる。

図９（ｃ）のトランスポートパケット情報６１１は、図９（ｄ）に示すように、トランスポートパケットの数（アプリケーションパケットの数）６３１、トランスポートパケットマッピングテーブル６３２等を含んでいる。

なお、図９（ｄ）のアプリケーションパケットの数は、後述する図１０（ｃ）または図１１のパケット数ＡＰ＿Ｎｓに対応している。

図９（ｄ）のトランスポートパケット（アプリケーションパケット）の数６３１は、図９（ｅ）に示すように、Ｉピクチャマッピングテーブル６４１、Ｂ，Ｐピクチャマッピングテーブル６４２等を含むことができる。

また、図９（ｄ）のトランスポートパケットマッピングテーブル６３２は、ビデオパケットマッピングテーブル６４３、オーディオパケットマッピングテーブル６４４、プログラム固有情報マッピングテーブル６４５等を含むことができる。

トランスポートパケットマッピングテーブル６３２内の各マッピングテーブル（図９（ｅ））は、ビットマップ形式で構成されている。

たとえば、１個のストリームブロック内にｎ個のトランスポートパケット（アプリケーションパケット）が記録されている場合には、図９（ｄ）のトランスポートパケット数（アプリケーションパケット数）６３１の値は”ｎ”となる。

さらに、各マッピングテーブル６４３〜６４５は”ｎビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット（アプリケーションパケット）に対してそれぞれ１ビットずつが割り当てられている。

図１０は、図１に示されたセクタデータヘッダの内部構造を説明する図である。

たとえば図１（ｆ）のセクタデータヘッダ１７は、データエリア２２、２３内のデータ配列情報を示すもので、図１０（ａ）のセクタデータヘッダ（図１０（ｄ）のアプリケーションヘッダに対応）１２に相当する。

セクタデータヘッダ１２は、図１０（ｂ）に示すように、ファーストアクセスポイント６５１およびトランスポートパケット接続フラグ６５２を含む内部構造を持っている。

ところで、図１０（ｄ）に示すように、１セクタと同じく２０４８バイトのサイズを持つ１つのストリームパックは、パックヘッダおよびストリームＰＥＳヘッダで構成されている。そして、このストリームＰＥＳパケット内に、図１０（ａ）のセクタデータヘッダ１２あるいは図９（ａ）のストリームブロックヘッダ１１の一部に対応した、アプリケーションパケットヘッダが含まれている。

このアプリケーションパケットヘッダは、図１０（ｃ）に示すように、以下のものを含んでいる：
＊アプリケーションパケットヘッダ形式のバージョン記載；
＊該当ストリームパック内で開始するアプリケーションパケット（トランスポートパケット）の数ＡＰ＿Ｎｓ；
＊該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ；
＊ヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ；
＊該当ストリームを生成したサービスの識別子ＳＥＲＶＩＣＥ＿ＩＤ。

上記図１０（ｄ）のアプリケーションパケットに含まれるＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴは、図１０（ａ）のセクタデータヘッダ１２に含まれるファーストアクセスポイント６５１に対応する。

図１（ｇ）に示すように、トランスポートパケットｄは２個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ６５２が”１”に設定される。

また図１（ｇ）の例では、次のセクタへ跨ったトランスポートパケットｄの次にくるタイムスタンプ先頭位置のデータエリア２２内のアドレスが、ファーストアクセスポイント６５１内に記録（ビット単位の表現）されている。

図１（ｅ）に示すセクタＮｏ．１（またはその対応ストリームパック）のファーストアクセスポイント値を、セクタＮｏ．１のデータエリア２２（図１（ｆ））のサイズよりも大きな値に設定することができる。そうすることにより、セクタＮｏ．１内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。

この発明の一実施の形態では、ファーストアクセスポイント６５１の値としてデータエリア２１、２２、２３のサイズよりも大きな値を指定可能にすることで、セクタサイズ（あるいはストリームパックサイズ＝２０４８バイト）よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。

たとえば、図１のデータ構造において、１個のパケットがセクタＮｏ．０からセクタＮｏ．２まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタＮｏ．０のデータエリア２１内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタＮｏ．２のデータエリア内のＴビット目に配置されている場合を考える。

この場合、セクタＮｏ．０のファーストアクセスポイントの値は”０”、セクタＮｏ．１のファーストアクセスポイントの値は”セクタＮｏ．１のデータエリア２２サイズ＋Ｔ”、セクタＮｏ．２のファーストアクセスポイントの値は”Ｔ”となる。

図１１は、この発明の一実施の形態におけるタイムマップ情報２５２の他例を説明する図である。

このタイムマップ情報２５２は、図３（ｈ）（ｉ）のタイムマップ情報２５２とは別の例であり、各ストリームブロック（最初のストリームブロック、２番目のストリームブロック、…）毎に、ストリームブロックサイズとストリームブロック時間差とパケット数（ＡＰ＿Ｎｓ）とを記述したテーブル情報である。

図１１のタイムマップ情報２５２を用い、所定の画面（ピクチャ）にアクセスするため（ＳＴＢ側から）通算トランスポートパケット数（または通算アプリケーションパケット数ＡＰ＿Ｎｓ）が指定されたとする。すると、（ディスク装置側は）図１１の最初のストリームブロックから順次トランスポートパケット数（ＡＰ＿Ｎｓ）を加算して行き、指定された値に達した時点でのストリームブロックへアクセスする。

図１２は、ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図である。

図１２（ｄ）のストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は、図１２（ｃ）（ｅ）に示すように、複数のストリームブロック＃１、＃２、…で構成されている。

各ストリームブロック＃１、＃２、…は全て、２ＥＣＣブロックサイズ（＝３２セクタ＝６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）で構成される。

このようにすると、たとえばストリームブロック（ＳＯＢＵ）＃２を削除しても、ストリームブロック（ＳＯＢＵ）＃１のＥＣＣブロックはこの削除に影響されない。

ＳＯＢ＃Ａ・２９８の先頭ストリームブロック（ＳＯＢＵ）＃１は、図１２（ｂ）に示すように、セクタＮｏ．０〜セクタＮｏ．３１（３２セクタ／６４ｋバイト）で構成されている。

ストリームブロック（ＳＯＢＵ）＃１の各セクタは、同様なデータ構造を持っている。、たとえばセクタＮｏ．０についていうと、図１２（ａ）に示すようになっている。

すなわち、セクタＮｏ．０は２０４８バイト（２ｋバイト）のストリームパックにより構成される。このストリームパックは、１４バイトのパックヘッダと、２０３４バイトのストリームＰＥＳパケットとで構成される。

ストリームＰＥＳパケットは、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、２０２７バイトのストリームデータエリアとで構成される。

ストリームデータエリアは、９バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、アプリケーションパケットエリアとで構成される。

アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ（ＡＴＳ）を先頭に持つアプリケーションパケット群で構成される。

たとえば１８８バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、１０個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。

ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ（たとえば２０４８バイト）を持つものとして扱うことができる。

図１２（ａ）のスタッフィングバイトは、ストリームパックを常に所定長（２０４８バイト）に保つために利用できる。

図１２（ａ）のパックヘッダは、図示しないが、パック開始コードの情報、ＳＣＲベースの情報、ＳＣＲエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。

ＳＣＲベースは３２ビットで構成され、その３２ビット目はゼロとされる。また、プログラム最大レートとしては、１０．０８Ｍｂｐｓが採用される。

図１２（ａ）のＰＥＳヘッダおよびサブストリームＩＤは、図８（ｃ）に示したような内容を持っている。

図１２（ａ）のアプリケーションヘッダは、図１０（ｃ）に示したように、バージョン情報、アプリケーションパケット数ＡＰ＿Ｎｓ、先頭アプリケーションパケットのタイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ、エクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ、サービスＩＤ等を含んでいる。

ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。

アプリケーションヘッダのＡＰ＿Ｎｓは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にＡＴＳの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。

ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには「０」が記述される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かが、記述される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が００ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１０ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１１ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が０１ｂとなることは禁止されている。

アプリケーションパケットエリアの前のスタッフィングバイト（オプション）は、「ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯ＝１１ｂ」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。

ＳＥＲＶＩＣＥ＿ＩＤには、ストリームを生成するサービスのＩＤが記述される。このサービスが未知のものであれば、ＳＥＲＶＩＣＥ＿ＩＤに０ｘ００００が記述される。

図１２（ａ）のアプリケーションパケットエリアは、後述する図２２の下段に示したと同様に構成できる（図２２のパケットを図１２ではアプリケーションパケットに読み替える）。

すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。

別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。

各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ（ＡＴＳ）は３２ビット（４バイト）で構成される。このＡＴＳは、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。

図１２（ａ）において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。

それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを（前述したＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯにおいて）記述できるように定義されいる。

ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプＡＴＳの先頭バイトは、ストリームオブジェクトＳＯＢの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。

一方、ＳＯＢ内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割（スプリット）されてもよい。

後述する図２２あるいは図２３（ｆ）（ｇ）に示した部分アプリケーションパケットは、この分割（スプリット）により生じたアプリケーションパケットを示している。

ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。

こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。

すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。

アプリケーションヘッダエクステンション（オプション）はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する１バイト長の１エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。

なお、１バイトのアプリケーションヘッダエクステンション（オプション）には、１ビットのＡＵ＿ＳＴＡＲＴと、１ビットのＡＵ＿ＥＮＤと、２ビットのＣＯＰＹＲＩＧＨＴとが、記述される。

ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。

ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。

ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。

図１２（ａ）のパケット構造は、ＳＯＢ＃Ａ・２９８の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。

たとえば、ＳＯＢ＃Ａ・２９８の末尾が図１２（ｆ）のセクタＮｏ．６３であり、このセクタが図１２（ｇ）に示すようにパディングパケット４０で構成されるときは、そのパディングエリア３８（図１２（ｈ））の内容が、図１２（ａ）と違ったものになる。

すなわち、図１２（ｉ）に示すように、パディングパケット４０としてのスタッフィングパケットは、１４バイトのパックヘッダと、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、９バイトのアプリケーションヘッダと、２０１８バイトのアプリケーションパケットエリアとで構成される。

スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、４バイトのアプリケーションタイムスタンプＡＴＳおよび２０１４バイト分のゼロバイトデータ（実質的な記録内容を持たないデータ）で構成される。

一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、２０１８バイト分のゼロバイトデータ（ＡＴＳなし）で構成される。

ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報（図３（ｈ）の２５２；あるいは後述する図１５のＳＯＢＩ内ＭＡＰＬ）の回復（再生）を確実にするために、スタッフィングが必要になる。図１２（ｉ）のスタッフィングパケットは、そのための概念的な単位として定義されている。

このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のＳＯＢＵが少なくとも１つのＡＴＳ値を含むようにすることで、達成される。

スタッフィングパケットには、以下の条件が付く：
＊１または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する；
＊１または複数のスタッフィングパケットは、１つの４バイトＡＴＳと、該当ＳＯＢＵの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ（ＡＴＳの後に続く）とで構成される。いま、ＳＯＢＵ１個あたりのセクタ数をＳＯＢＵ＿ＳＩＺとしたときに、０≦ｎ≦ＳＯＢＵ＿ＳＩＺー１とすれば、スタッフィングパケットの全長は、「４＋２０１４＋ｎ×２０１８」バイトとなる。

スタッフィングパケットのＡＴＳは、次のように設定される：
＊少なくとも１個のパックが実際のアプリケーションパケットデータを含んでいるＳＯＢＵ内では、スタッフィングパケットのＡＴＳは、スタッフィングパケットに先行するアプリケーションパケットのＡＴＳに設定される；
＊実際のアプリケーションパケットデータを含まないＳＯＢＵ内では、スタッフィングパケットのＡＴＳはタイムマップ情報等の内容に応じて決定される。

スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される：
＊パックヘッダのＳＣＲは、先行パックのＳＣＲに「２０４８×８ビット÷１０．０８Ｍｂｐｓ」を加えたものとする；
＊ＰＥＳパケットヘッダおよびサブストリームＩＤは、他の全てのＰＥＳパケットに対するものと同じにする；
＊アプリケーションヘッダ（図１０（ｃ）（ｄ）参照）内において、ＡＰ＿Ｎｓ＝０、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ＝０、ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ＝００ｂ、ＳＥＲＶＩＣＥ＿ＩＤ＝０（アプリケーションヘッダ内のその他のパラメータも０）とする。

図１３は、ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図である。

図２あるいは図３（ｅ）に示した管理情報（ナビゲーションデータ）であるＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図１３に示すように、ストリーマ情報ＳＴＲＩを含んでいる。

このストリーマ情報ＳＴＲＩは、図３（ｆ）あるいは図１３に示すように、ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩと、ストリームファイル情報テーブルＳＦＩＴと、オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩ（より一般的に表現すればＰＧＣ情報ＰＧＣＩ＃ｉ）と、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴと、テキストデータマネージャＴＸＴＤＴ＿ＭＧと、アプリケーションプライベートデータマネージャＡＰＤＴ＿ＭＧとで、構成されている。

ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩは、図１３に示すように、ＳＴＲＩ、ＳＴＲ＿ＶＭＧＩに関する管理情報等が記述されたビデオマネージャ情報管理情報ＶＴＳＩ＿ＭＡＴと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）とを含んでいる。

ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。

ストリームファイル情報テーブルＳＦＩＴは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルＳＦＩＴの詳細については、図１５を参照して後述する。

オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）に関する情報を記述した部分である。ＯＲＧ＿ＰＧＣはプログラムセットを記述したナビゲーションデータを示す。ＯＲＧ＿ＰＧＣはプログラムの連なり（チェーン）であり、図２または後述する図１８の「．ＳＲＯ」ファイル（図２ではＳＲ＿ＴＲＡＮＳ．ＳＲＯ１０６）内に記録されたストリームデータを含む。

ここで、プログラムセットとは、情報記憶媒体２０１の記録内容全体（全てのプログラム）を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）と呼ばれるデータ構造に対応している。

また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、１以上のオリジナルセルにより構成される。プログラムはオリジナルＰＧＣ内でのみ定義されるものである。

さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義ＰＧＣ内のセルは「ユーザ定義セル」と呼ばれる。

プログラムセット内の各々のプログラムは、少なくとも１個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも１個のユーザ定義セルで構成される。

一方、ストリーマでは、ストリームセル（ＳＣ）だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。

なお、プログラムチェーン（ＰＧＣ）とは、上位概念的な単位を示す。オリジナルＰＧＣでは、ＰＧＣはプログラムセットに対応したプログラムの連なり（チェーン）を指す。また、ユーザ定義ＰＧＣでは、ＰＧＣはプレイリストに対応するプログラムの一部の連なり（チェーン）を指す。

また、プログラムの一部のチェーンを指すユーザ定義ＰＧＣは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルＰＧＣに属するストリームデータを参照するようになっている。

図１３のユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴは、ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩと、１以上のユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰ＃ｎと、１以上のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩ＃ｎとを含むことができる。

ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩは、図示しないが、ユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰの数を示すＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓと、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴの終了アドレスを示すＵＤ＿ＰＧＣＩＴ＿ＥＡとを含む。

ＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓが示すＵＤ＿ＰＧＣ＿ＳＲＰの数は、ユーザ定義ＰＧＣ情報（ＵＤ＿ＰＧＣＩ）の数と同じであり、ユーザ定義ＰＧＣ（ＵＤ＿ＰＧＣ）の数とも同じである。この数は、最大「９９」まで許されている。

ＵＤ＿ＰＧＣＩＴ＿ＥＡは、該当ＵＤ＿ＰＧＣＩＴの終了アドレスを、そのＵＤ＿ＰＧＣＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述したものである。

ここで、Ｆ＿ＲＢＮとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。

オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したＰＧＣＩ＃ｉについては、図１４を参照して後述する。

図１３のテキストデータマネージャＴＸＴＤＴ＿ＭＧは、補足的なテキスト情報である。このＴＸＴＤＴ＿ＭＧは、図１４のプライマリテキスト情報ＰＲＭ＿ＴＸＴＩとともに、プレイリストおよびプログラム内に格納できる。

図１３のアプリケーションプライベートデータマネージャＡＰＤＴ＿Ｍは、図示しないが、アプリケーションプライベートデータマネージャ一般情報ＡＰＤＴ＿ＧＩと、１以上のＡＰＤＴサーチポインタＡＰＤＴ＿ＳＲＰ＃ｎと、１以上のＡＰＤＴエリアＡＰＡＤＴＡ＃ｎとを含むことができる。

ここで、アプリケーションプライベートデータＡＰＤＴとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報（リアルタイムストリームデータに加えさらに望まれる情報）を格納できるような概念上のエリアである。

図１４は、ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１３のＰＧＣＩ＃ｉ）の内部データ構造を説明する図である。

図１４のＰＧＣ情報ＰＧＣＩ＃ｉは、図１３のオリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したものである。

図１４に示すように、ＰＧＣ情報ＰＧＣＩ＃ｉは、ＰＧＣ一般情報ＰＧＣ＿ＧＩと、１以上のプログラム情報ＰＧＩ＃ｍと、１以上のストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ＃ｎと、１以上のストリームセル情報ＳＣＩ＃ｎとで構成されている。

ＰＧＣ一般情報ＰＧＣ＿ＧＩは、プログラムの数ＰＧ＿Ｎｓと、ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰの数ＳＣＩ＿ＳＲＰ＿Ｎｓとを含んでいる。

各プログラム情報ＰＧＩ（たとえばＰＧＩ＃１）は、プログラムタイプＰＧ＿ＴＹと、該当プログラム内のセルの数Ｃ＿Ｎｓと、該当プログラムのプライマリテキスト情報ＰＲＭ＿ＴＸＴＩと、アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮとを含んでいる。

ここで、プログラムタイプＰＧ＿ＴＹは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。

このプロテクトフラグが「０ｂ」のときは該当プログラムは保護されておらず、「１ｂ」のときは保護された状態にある。

セルの数Ｃ＿Ｎｓは、該当プログラム内のセルの数を示す。ＰＧＣの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに（暗黙のうちに）付随している。

たとえば、ＰＧＣ内でプログラム＃１がＣ＿Ｎｓ＝１を持ち、プログラム＃２がＣ＿Ｎｓ＝２を持つとすれば、そのＰＧＣの最初のストリームセル情報ＳＣＩはプログラム＃１に付随するものとなり、第２、第３のＳＣＩはプログラム＃２に付随するものとなる。

プライマリテキスト情報ＰＲＭ＿ＴＸＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１を世界中で利用可能とするために、１つの共通キャラクタセット（ＩＳＯ／ＩＥＣ６４６：１９８３（ＡＳＣＩＩコード））を持ったテキスト情報を記述したものである。

アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮは、アイテムテキスト（該当プログラムに対応するテキストデータ）ＩＴ＿ＴＸＴに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、ＩＴ＿ＴＸＴ＿ＳＲＰＮは「００００ｈ」にセットされる。

各ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ（たとえばＳＣＩ＿ＳＲＰ＃１）は、対応ストリームセル情報ＳＣＩの開始アドレスを示すＳＣＩ＿ＳＡを含んでいる。このＳＣＩ＿ＳＡは、ＰＧＣＩの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述される。

各ストリームセル情報ＳＣＩ（たとえばＳＣＩ＃１）は、ストリームセル一般情報ＳＣ＿ＧＩと、１以上のストリームセルエントリポイント情報ＳＣ＿ＥＰＩ＃ｎとで構成される。

ストリームセル一般情報ＳＣ＿ＧＩは、仮消去（テンポラリイレーズ；ＴＥ）状態を示すフラグＴＥを含むセルタイプＣ＿ＴＹと、ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓと、ストリームオブジェクト番号ＳＯＢ＿Ｎと、ストリームセル開始ＡＰＡＴ（図６他で示したＳＣ＿Ｓ＿ＡＰＡＴ）と、ストリームセル終了ＡＰＡＴ（図６他で示したＳＣ＿Ｅ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝１０ｂ）にあるときにその仮消去セルの開始ＡＰＡＴを示す消去開始ＡＰＡＴ（図６他で示したＥＲＡ＿Ｓ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝１０ｂ）にあるときにその仮消去セルの終了ＡＰＡＴを示す消去終了ＡＰＡＴ（図６他で示したＥＲＡ＿Ｅ＿ＡＰＡＴ）とを含んでいる。

セルタイプＣ＿ＴＹは、該当ストリームセルの形式およびその仮消去状態を記述するものである。

すなわち、セルの形式Ｃ＿ＴＹ１＝「０１０ｂ」は全てのストリームセルの形式に記述される（このＣ＿ＴＹ１＝「０１０ｂ」によりストリームセルとそれ以外のセルの区別ができる）。

一方、フラグＴＥが「００ｂ」であれば該当セルは通常の状態にあることが示され、フラグＴＥが「０１ｂ」あるいは「１０ｂ」であれば該当セルは仮消去の状態にあることが示される。

フラグＴＥ＝「０１ｂ」は、該当セル（仮消去状態にあるセル）が、ＳＯＢＵ内で開始する最初のアプリケーションパケットの後から開始し、同じＳＯＢＵ内の最終アプリケーションパケットの前で終了する場合を示す。

また、フラグＴＥ＝「１０ｂ」は、該当セル（仮消去状態にあるセル）が、少なくとも１つのＳＯＢＵ境界（先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのＳＯＢＵ内で開始する）を含む場合を示す。

なお、プログラムのプロテクトフラグと、そのプログラム内のセルのＴＥフラグとは、同時に設定できないようになっている。それゆえ、
（ａ）プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず；
（ｂ）仮消去状態にあるセルを１以上含むプログラムはプロテクト状態に設定できない。

ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓは、該当ストリームセル情報ＳＣＩ内に含まれるストリームセルエントリポイント情報の数を記述したものである。

図１４の各ストリームセルエントリポイント情報ＳＣ＿ＥＰＩ（たとえばＳＣ＿ＥＰＩ＃１）は、２種類（タイプＡとタイプＢ）存在する。

タイプＡのＳＣ＿ＥＰＩは、エントリポイントタイプＥＰ＿ＴＹとエントリポイントのアプリケーションパケット到着時間ＥＰ＿ＡＰＡＴとを含む。タイプＡは、エントリポイントタイプＥＰ＿ＴＹ１＝「００ｂ」により示される。

タイプＢのＳＣ＿ＥＰＩは、タイプＡのＥＰ＿ＴＹおよびＥＰ＿ＡＰＡＴの他に、プライマリテキスト情報ＰＲＭ＿ＴＸＴＩを含む。タイプＢは、エントリポイントタイプＥＰ＿ＴＹ１＝「０１ｂ」により示される。

任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間（ＡＰＡＴ）により特定できる。このＡＰＡＴにより、どこからデータ出力が開始されるのかを特定できる。

ストリームオブジェクト番号ＳＯＢ＿Ｎは、該当セルが参照するＳＯＢの番号を記述したものである。

ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当セルの開始ＡＰＡＴを記述したものである。

ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当セルの終了ＡＰＡＴを記述したものである。

消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、この仮消去セルに先頭が含まれる最初のＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。

消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、仮消去セルのすぐ後に続くアプリケーションパケットを含むＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。

図１５は、ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図である。

図１５に示すように、ストリームファイル情報テーブルＳＦＩＴは、ストリームファイル情報テーブル情報ＳＦＩＴＩと、１以上のストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ＃ｎと、ストリームファイル情報ＳＦＩとで構成される。

ストリームファイル情報テーブル情報ＳＦＩＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１上のストリームファイル情報の数ＳＦＩ＿Ｎｓと、ＳＦＩＴＩに続くストリームオブジェクトストリーム情報の数ＳＯＢ＿ＳＴＩ＿Ｎｓと、ＳＦＩＴの終了アドレスＳＦＩＴ＿ＥＡと、ＳＦＩの開始アドレスＳＦＩ＿ＳＡとで構成される。

ＳＦＩＴ＿ＥＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩＴの終了アドレスを記述したものである。

また、ＳＦＩ＿ＳＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩの開始アドレスを記述したものである。

各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩは、３種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、ＳＯＢ＿ＳＴＩは、ストリームオブジェクト情報（ＳＯＢＩ）のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト（ＳＯＢ）が同じＳＯＢ＿ＳＴＩを共有する（つまり同じＳＯＢ＿ＳＴＩをポイントする）ことが認められている。したがって、通常は、ＳＯＢの数よりもＳＯＢ＿ＳＴＩの数の方が少なくなる。

図１５の各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ（たとえばＳＯＢ＿ＳＴＩ＃１）は、アプリケーションパケットサイズＡＰ＿ＳＩＺと、サービスＩＤの数ＳＥＲＶ＿ＩＤ＿Ｎｓと、サービスＩＤ（ＳＥＲＶ＿ＩＤｓ）と、アプリケーションパケットデバイスユニークＩＤ（ＡＰ＿ＤＥＶ＿ＵＩＤ）とを含んでいる。

ＡＰ＿ＳＩＺは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。

なお、ＤＶＤストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト（現ＳＯＢ）はそこで終了され、新たなストリームオブジェクト（新ＳＯＢ）が、新たなＡＰ＿ＳＩＺを伴って開始される。その際、現ＳＯＢおよび新ＳＯＢの双方は、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）内の同じプログラムに属するものとなる。

ＳＥＲＶ＿ＩＤ＿Ｎｓは、後続パラメータに含まれるサービスＩＤの数を記述したものである。

ＳＥＲＶ＿ＩＤｓは、サービスＩＤのリストを任意の順序で記述したものである。

ＡＰ＿ＤＥＶ＿ＵＩＤは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスＩＤを記述したものである。

ストリームファイル情報ＳＦＩは、図１５に示すように、ストリームファイル一般情報ＳＦ＿ＧＩと、１以上のストリームオブジェクト情報（ＳＯＢ情報）サーチポインタ（ＳＯＢＩ＿ＳＲＰ）＃ｎと、１以上のＳＯＢ情報（ＳＯＢＩ）＃ｎとで構成されている。

ストリームファイル一般情報ＳＦ＿ＧＩは、ＳＯＢＩの数ＳＯＢＩ＿Ｎｓと、ＳＯＢＵ１個あたりのセクタ数ＳＯＢＵ＿ＳＩＺと、タイムマップ情報の一種であるＭＴＵ＿ＳＨＦＴとを含んでいる。

ここで、ＳＯＢＵ＿ＳＩＺは、ＳＯＢＵのサイズをセクタ数で記述したもので、このサイズは３２（３２セクタ＝６４ｋバイト）で一定となっている。このことは、各タイムマップ情報（ＭＡＰＬ）内において、最初のエントリが、ＳＯＢの最初の３２セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、２番目のエントリは、次の３２セクタに含まれるアプリケーションパケットに関係する。３番目以降のエントリについても以下同様である。

各ＳＯＢ情報サーチポインタ（たとえばＳＯＢＩ＿ＳＲＰ＃１）は、ＳＯＢＩの開始アドレスＳＯＢＩ＿ＳＡを含んでいる。このＳＯＢＩ＿ＳＡは、ストリームファイル情報ＳＦＩの先頭バイトから相対バイト数（Ｆ＿ＲＢＮ）でもって関連ＳＯＢＩの開始アドレスを記述したものである。

各ＳＯＢ情報（たとえばＳＯＢＩ＃１）は、ストリームオブジェクト一般情報ＳＯＢ＿ＧＩと、タイムマップ情報ＭＡＰＬと、アクセスユニットデータＡＵＤ（オプション）とで構成される。

ストリームオブジェクト一般情報ＳＯＢ＿ＧＩは、ストリームオブジェクトのタイプＳＯＢ＿ＴＹと、ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭと、ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎと、アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳと、ストリームオブジェクトの開始アプリケーションパケット到着時間ＳＯＢ＿Ｓ＿ＡＰＡＴと、ストリームオブジェクトの終了アプリケーションパケット到着時間ＳＯＢ＿Ｅ＿ＡＰＡＴと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットＳＯＢ＿Ｓ＿ＳＯＢＵと、タイムマップ情報のエントリ数ＭＡＰＬ＿ＥＮＴ＿Ｎｓとを含んでいる。

ストリームオブジェクトのタイプＳＯＢ＿ＴＹは、仮消去状態（ＴＥ状態）を示すビットおよび／またはコピー世代管理システムのビットを記述できる部分である。

ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭは、関連ストリームオブジェクト（ＳＯＢ）の記録時間を記述したものである。

ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎは、該当ストリームオブジェクトに対して有効なＳＯＢ＿ＳＴＩのインデックスを記述したものである。

アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳは、該当ストリームオブジェクトに対してアクセスユニットデータ（ＡＵＤ）が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。

アクセスユニットデータ（ＡＵＤ）が存在する場合は、ＡＵＤ＿ＦＬＡＧＳにより、ＡＵＤの幾つかの特性が記述される。

アクセスユニットデータ（ＡＵＤ）自体は、図１５に示すように、アクセスユニット一般情報ＡＵ＿ＧＩと、アクセスユニットエンドマップＡＵＥＭと、再生タイムスタンプリストＰＴＳＬとで構成される。

アクセスユニット一般情報ＡＵ＿ＧＩは、該当ＳＯＢに対して記述されたアクセスユニットの数を示すＡＵ＿Ｎｓと、該当ＳＯＢに属するＳＯＢＵのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップＡＵＳＭとを含んでいる。

アクセスユニットエンドマップＡＵＥＭは、（もし存在するときは）ＡＵＳＭと同じ長さのビットアレイであり、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの終端をどのＳＯＢＵが含むのかを示す。

再生タイムスタンプリストＰＴＳＬは、該当ＳＯＢに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる１つのＰＴＳＬエレメントは、対応アクセスユニットの再生タイムスタンプ（ＰＴＳ）の値を含む。

なお、アクセスユニット（ＡＵ）とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、ＭＰＥＧのＩピクチャに対応する部分となる。

ここで再びＳＯＢ＿ＧＩの内容説明に戻る。

ＡＵＤ＿ＦＬＡＧＳは、フラグＲＴＡＵ＿ＦＬＧと、フラグＡＵＤ＿ＦＬＧと、フラグＡＵＥＭ＿ＦＬＧと、フラグＰＴＳＬ＿ＦＬＧとを含んでいる。

フラグＲＴＡＵ＿ＦＬＧが０ｂのときは、該当ＳＯＢのリアルタイムデータ内にアクセスユニットフラグはないことが示される。

フラグＲＴＡＵ＿ＦＬＧが１ｂのときは、図９（ａ）または図１２（ａ）のアプリケーションヘッダエクステンション内に記述されるＡＵフラグ（ＡＵ＿ＳＴＡＲＴ、ＡＵ＿ＥＮＤ）が、該当ＳＯＢのリアルタイムデータ内に存在可能なことが示される。この状態は、下記ＡＵＤ＿ＦＬＧが０ｂの場合にも許される。

フラグＡＵＤ＿ＦＬＧが０ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）がないことが示される。

フラグＡＵＤ＿ＦＬＧが１ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）が存在し得ることが示される。

フラグＡＵＥＭ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＡＵＥＭが存在しないことが示される。

フラグＡＵＥＭ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＡＵＥＭが存在することが示される。

フラグＰＴＳＬ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＰＴＳＬが存在しないことが示される。

フラグＰＴＳＬ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＰＴＳＬが存在することが示される。

ＳＯＢ＿Ｓ＿ＡＰＡＴは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｓ＿ＡＰＡＴにより、該当ＳＯＢに属する最初のアプリケーションパケット到着時間が示される。

このパケット到着時間（ＰＡＴ）は、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。

ＳＯＢ＿Ｅ＿ＡＰＡＴは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｅ＿ＡＰＡＴにより、該当ＳＯＢに属する最後のアプリケーションパケット到着時間が示される。

ＳＯＢ＿Ｓ＿ＳＯＢＵは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、ＳＯＢ＿Ｓ＿ＳＯＢＵにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むＳＯＢＵが示される。

ＭＡＰＬ＿ＥＮＴ＿Ｎｓは、ＳＯＢＩ＿ＧＩの後に続くタイムマップ情報（ＭＡＰＬ）のエントリ数を記述したものである。

タイムマップ情報ＭＡＰＬは、図３（ｈ）のタイムマップ情報２５２に対応する内容を持つ。

図１３および図１５の内容の関連性の１つについて纏めると、次のようになる：
管理情報１０５に含まれるストリーマ情報ＳＴＲＩは、ストリームデータの内容の一部を構成するストリームオブジェクトＳＯＢを管理するストリームファイル情報テーブルＳＦＩＴを含む。このＳＦＩＴは、ＳＯＢを管理するストリームオブジェクト情報ＳＯＢＩを含む。このＳＯＢＩが、管理情報（アクセスユニット開始マップＡＵＳＭ）を含むアクセスユニット一般情報ＡＵ＿ＧＩと、管理情報（ＰＴＳＬ）とを含む。

ここで、管理情報（ＡＴＳまたはＡＵＳＭ）がストリームデータの転送時に使用される情報を含み、管理情報（ＰＴＳまたはＳＣ＿Ｓ＿ＡＰＡＴ）が前記ストリームデータを表示するときに使用される情報を含む。

図１６は、アクセスユニット開始マップ（ＡＵＳＭ；図１５参照）とストリームオブジェクトユニット（ＳＯＢＵ；図１、図４〜図６、図１２参照）との対応関係を例示する図である。

図示するように、ＡＵＳＭのうちビット”１”の部分が、対応ＳＯＢＵにアクセスユニット（ＡＵ）が含まれることを示している。

いま、ＡＵＳＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＳＭ＿ｐｏｓ（ｉ）としてみる。すると、アクセスユニットＡＵの位置は次のようになる。

（１）もしＡＵＳＭ＿ｐｏｓ（ｉ）により示されるＳＯＢＵ＃ｉが１以上の開始ＡＵ（これはストリーム内で（もしあるなら）ＡＵ＿ＳＴＡＲＴマークおよびＡＵ＿ＥＮＤマークにより記述される）を含むなら、ＡＵＳＭ＿ｐｏｓ（ｉ）は、ＳＯＢＵ＃ｉ内で開始する最初のＡＵに割り当てられる。ここで、ＳＯＢＵ＃ｉは、ＡＵＳＭ＿ｐｏｓ（ｉ）および（ＡＵＥＭが存在するなら）ＡＵＥＭ＿ｐｏｓ（ｉ）により記述されたＳＯＢＵｓ内に配置されたものである。

（２）ＡＵは、このＡＵ開始後に最初に現れるＡＵ＿ＥＮＤマークで終了し、かつ、ＡＵは、（もしＡＵＥＭが存在するなら）割り当てられたＡＵＥＭエレメントにより示される最後のＳＯＢＵで終了する。

なお、いずれのアクセスユニットデータにおいても、ＳＯＢの各ＳＯＢＵ１個当たりに、２以上のアクセス可能なアクセスユニットを記述することはできない。

図１７は、アクセスユニット開始マップ（ＡＵＳＭ；図１５参照）およびアクセスユニット終了マップ（ＡＵＥＭ；図１５参照）とストリームオブジェクトユニット（ＳＯＢＵ；図２、図４、図１１参照）との対応関係を例示する図である。

ＡＵＥＭは、（もし存在するなら）ＡＵＳＭと同じ長さのビットアレイである。ＡＵＥＭのビットは、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの末尾がどのＳＯＢＵに含まれるのかを、示している。

ＡＵＥＭ内にセットされたビットの数はＡＵＳＭ内にセットされたビットの数に一致する。すなわち、ＡＵＳＭ内の各設定ビットは、ＡＵＥＭ内に対応してセットされたビットを持つ。

いま、ＡＵＳＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＳＭ＿ｐｏｓ（ｉ）とし、ＡＵＥＭ内でビットがセットされたｉ番目（１≦ｉ≦ＡＵ＿Ｎｓ）のビット位置をＡＵＥＭ＿ｐｏｓ（ｉ）としてみる。この場合、以下の関係がある。

（１）１≦ＡＵＳＭ＿ｐｏｓ（ｉ）≦ＡＵＥＭ＿ｐｏｓ（ｉ）≦ＭＡＰＬ＿ＥＮＴ＿Ｎｓ；
（２）ＡＵＳＭ＿ｐｏｓ（ｉ＋１）＞ＡＵＥＭ＿ｐｏｓ（ｉ）；
（３）もしｉ＝＝ＡＵ＿ＮｓあるいはＡＵＳＭ＿ｐｏｓ（ｉ＋１）＞１＋ＡＵＥＭ＿ｐｏｓ（ｉ）なら、ＡＵ＃ｉは、ＳＯＢＵ＃［ＡＵＥＭ＿ｐｏｓ（ｉ）］で終了する（１≦ｉ≦ＡＵ＿Ｎｓ）；
（４）もしＡＵＳＭ＿ｐｏｓ（ｉ＋１）＝＝１＋ＡＵＥＭ＿ｐｏｓ（ｉ）なら、ＡＵ＃ｉは、ＳＯＢＵ＃［ＡＵＥＭ＿ｐｏｓ（ｉ）］で終了する。あるいは
ＳＯＢＵ＃［１＋ＡＵＥＭ＿ｐｏｓ（ｉ）］＝＝ＳＯＢＵ＃［ＡｕＳＭ＿ｐｏｓ（ｉ＋１）］のところで終了する。つまり、ＡＵ＃ｉは、ＳＯＢＵ内においてＡＵ＃ｉ＋１が開始するところで終了する（１≦ｉ≦ＡＵ＿Ｎｓ）。

図１８は、オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。

ユーザ定義ＰＧＣは自身のＳＯＢを含まないが、オリジナルＰＧＣ内のＳＯＢを参照する。それゆえ、ユーザ定義ＰＧＣはＰＧＣ情報を用いることのみで記述できる。このことは、ＳＯＢデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。

ユーザ定義ＰＧＣはまた、プログラムを含まず、オリジナルＰＧＣ内のプログラムの一部に対応したセルの連なり（チェーン）で構成される。

このようなユーザ定義ＰＧＣの一例が、図１８に示されている。この例は、ＰＧＣ内のセルがオリジナルＰＧＣ内のＳＯＢを参照するようにユーザ定義ＰＧＣ＃ｎが作成されている場合を示す。

図１８において、ＰＧＣ＃ｎは４つのセル＃１〜＃４を持っている。そのうち２つはＳＯＢ＃１を参照し、残りの２つがＳＯＢ＃２を参照している。

ユーザ定義ＰＧＣ内のセルからオリジナルＰＧＣへ（ＳＯＢＩのタイムマップ情報へ）の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義ＰＧＣ内のセル再生順序は、オリジナルＰＧＣにおける再生順序と全く異なってもよい。

任意のＳＯＢおよびそのＳＯＢＵの再生は、図１８の開始ＡＰＡＴ（Ｓ＿ＡＰＡＴ）および終了ＡＰＡＴ（Ｅ＿ＡＰＡＴ）により特定される。

ＳＯＢあるいはＳＯＢＵのＳ＿ＡＰＡＴは、該当ＳＯＢのストリームパックのペイロード（図１（ｈ）、図２２、図２３参照）内に記録されたタイムスタンプに関係して定義される。

ＳＯＢの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間（ＡＰＡＴ）である。

ＳＯＢの先頭アプリケーションパケットのＡＰＡＴはＳＯＢ＿Ｓ＿ＡＰＡＴとして記憶される。全てのＡＰＡＴの４最下位バイト（4 least significant bytes）は、「〜．ＳＲＯ」ファイル内の対応アプリケーションパケット用に予め固定されている。

ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ内部のリファレンスクロックはＳＣＲ値にセットされ、その後クロックが自動的にカウントされる。このＳＣＲ値は、再生が始まる最初のストリームパック内（パックヘッダ内）に記述されている。このクロックに基づいて、ＳＯＢあるいはＳＯＢＵからの全ての後続アプリケーションパケットの再生・出力が、実行される。

任意のストリームセル（ＳＣ）が、そのＳＣがポイントするＳＯＢのＳＯＢ＿Ｓ＿ＡＰＡＴとＳＯＢ＿Ｅ＿ＡＰＡＴとの間の任意の値を持つストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）を規定しているときは、所望のＡＰＡＴを伴うアプリケーションパケットを含んだＳＯＢＵを見つけるためのアドレスが必要となる。

ＳＯＢＵ１個あたりのストリームパックの数は一定であるが、各ＳＯＢＵにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各ＳＯＢは、該当ＳＯＢのＳＯＢＵの到着時間間隔が記述されたタイムマップ情報（ＭＡＰＬ）を持つ。つまり、タイムマップ情報（ＭＡＰＬ）により実現されるアドレス方式は、任意のＡＰＡＴをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるＳＯＢＵをポイントする。

図１９は、この発明の一実施の形態に係るストリームデータ記録再生システム（光ディスク装置／ストリーマ、ＳＴＢ装置）の構成を説明する図である。この実施の形態では、情報記憶媒体２０１として、ＤＶＤ−ＲＡＭディスクのような記録／再生可能光ディスクを想定している。

以下、図１９を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。

このストリームデータ記録再生装置は、光ディスク装置４１５、ＳＴＢ装置４１６およびその周辺機器から構成される。

周辺機器としては、ビデオミキシング部４０５、フレームメモリ部４０６、外部スピーカ４３３、パーソナルコンピュータ（ＰＣ）４３５、モニタＴＶ４３７、Ｄ／Ａコンバータ４３２、４３６、Ｉ／Ｆ部４３１、４３４等がある。

光ディスク装置４１５は、ディスクドライブを含む記録再生部４０９と、記録再生部４０９へのストリームデータ（あるいは記録再生部４０９からのストリームデータ）を処理するデータプロセサ部（以下Ｄ−ＰＲＯ部と略記する）４１０と、Ｄ−ＰＲＯ部４１０からオーバーフローしてきたストリームデータを一時記憶する一時記憶部４１１と、記録再生部４０９およびＤ−ＰＲＯ部４１０の動作を制御する光ディスク装置制御部４１２とを備えている。

光ディスク装置４１５はさらに、ＳＴＢ装置４１６からＩＥＥＥ１３９４等を介して送られてきたストリームデータを受ける（あるいはＩＥＥＥ１３９４等を介してＳＴＢ装置４１６へストリームデータを送る）データ転送インターフェース部４１４と、データ転送インターフェース部４１４で受けたストリームデータを情報記憶媒体（ＲＡＭディスク）２０１に記録する信号形式に変換する（あるいは媒体２０１から再生されたストリームデータをＩＥＥＥ１３９４等の信号形式に変換する）フォーマッタ／デフォーマッタ部４１３とを備えている。

具体的には、データ転送インターフェース部４１４のＩＥＥＥ１３９４受信側は、基準クロック発生器（システムタイムカウンタＳＴＣ）４４０のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。

上記時間情報に基づいて、ストリームデータをストリームブロック毎（あるいはＳＯＢＵ毎）に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはＰＧＣの切り分け情報を作成する。

フォーマッタ／デフォーマッタ部４１３は、ＳＴＢ装置４１６から送られてきたストリームデータをストリームパックの列（図１２（ａ）、図２３（ｈ）等を参照）に変換し、変換されたストリームパック列をＤ−ＰＲＯ部４１０へ入力する。入力されたストリームパックはセクタと同じ２０４８バイトの一定サイズを持っている。Ｄ−ＰＲＯ部４１０は、入力されたストリームパックを１６セクタ毎にまとめてＥＣＣブロックにして、記録再生部４０９へ送る。

ここで、記録再生部４０９において媒体２０１への記録準備ができていない場合には、Ｄ−ＰＲＯ部４１０は、記録データを一時記憶部４１１に転送して一時保存し、記録再生部４０９においてデータ記録準備ができるまで待つ。

記録再生部４０９において記録準備ができた段階で、Ｄ−ＰＲＯ部４１０は一時記憶部４１１に保存されたデータを記録再生部４０９に転送する。これにより、媒体２０１への記録が開始される。一時記憶部４１１に保存されたデータの記録が済むと、その続きのデータはフォーマッタ／デフォーマッタ部４１３からＤ−ＰＲＯ部４１０へシームレスに転送されるようになっている。

ここで、一時記憶部４１１は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。

なお、フォーマッタ／デフォーマッタ部４１３を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器（ＳＴＣ）４４０から得ることができる。

また、フォーマッタ／デフォーマッタ部４１３を介して再生ビットストリームから取り出されたタイムスタンプ情報（ＳＣＲ）は、ＳＴＣ４４０にセットすることができる。

情報記憶媒体２０１に記録されたストリームデータ内のパックヘッダには、基準クロック（システムクロックリファレンスＳＣＲ）が記録されている。この媒体２０１に記録されたストリームデータ（ＳＯＢまたはＳＯＢＵ）を再生する場合において、基準クロック発生器（ＳＴＣ）４４０は、媒体２０１から再生された基準クロック（ＳＣＲ）に適合される（ＳＣＲの値がＳＴＣ４４０にセットされる）。

つまり、ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ（光ディスク装置４１５）内の基準クロック（ＳＴＣ４４０）を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスＳＣＲに合わせる。その後は、ＳＴＣ４４０のカウントアップは自動的に行われる。

ＳＴＢ部４１６は、衛星アンテナ４２１で受信したデジタル放送電波の内容を復調し、１以上の番組が多重化された復調データ（ストリームデータ）を提供するデモジュレータ４２２と、デモジュレータ４２２で復調されたデータから（ユーザが希望する）特定番組の情報（後述する図２３を例に採れば、番組２のトランスポートパケット）を選択する受信情報セレクタ部４２３とを備えている。

受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を情報記憶媒体２０１に記録する場合は、ＳＴＢ制御部４０４の指示にしたがい、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部２０を介して、ＩＥＥＥ１３９４転送により、光ディスク装置４１５のデータ転送インターフェイス部４１４に送る。

受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を記録することなく単に視聴するだけの場合は、ＳＴＢ制御部４０４の指示にしたがい、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部４０２の多重化情報分離部４２５に送る。

一方、情報記憶媒体２０１に記録された番組を再生する場合は、ＩＥＥＥ１３９４のシリアルバスを介して光ディスク装置４１５からＳＴＢ装置４１６に送られてきたストリームデータは、セレクタ部４２３を介してデコーダ部４０２の多重化情報分離部４２５に送られる。

多重化情報分離部４２５は、セレクタ部４２３から送られてきたストリームデータに含まれる各種パケット（ビデオパケット、オーディオパケット、サブピクチャパケット）を、内部メモリ部４２６上で、各パケットのＩＤにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部（ビデオデコード部４２８、サブピクチャデコード部４２９、オーディオデコード部４３０に分配する。

ビデオデコード部４２８は、多重化情報分離部４２５から送られてきた（ＭＰＥＧエンコードされた）ビデオパケットをデコードして、動画データを生成する。その際、ＭＰＥＧビデオデータ中のＩピクチャから記録内容を代表する縮小画像（サムネールピクチャ）を生成する機能を持たせるために、ビデオデコード部４２８は、代表画像（サムネール）生成部４３９を内蔵している。

ビデオデコード部４２８でデコードされた動画（および／または生成部４３９で生成された代表画像）と、サブピクチャデコード部４２９でデコードされたサブピクチャ（字幕、メニュー等の情報）と、オーディオデコード部４３０でデコードされた音声とは、ビデオプロセサ部４３８を介してビデオミキシング部４０５へ送出される。

ビデオミキシング部４０５は、フレームメモリ部４０６を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、Ｄ／Ａ変換器４３６を介してアナログ映像化され、モニタＴＶ４３７に送られる。

また、ビデオミキシング部４０５からのデジタル映像は、Ｉ／Ｆ部４３４およびＩＥＥＥ１９４等の信号ラインを介して、パーソナルコンピュータ４３５に適宜取り込まれる。

一方、オーディオデコード部４３０でデコードされたデジタルオーディオ情報は、Ｄ／Ａ変換器４３２および図示しないオーディオアンプを介して、外部スピーカ４３３に送られる。また、デコードされたオーディオ情報は、Ｉ／Ｆ部４３１を介して外部にデジタル出力される。

なお、ＳＴＢ装置４１６内の動作タイミングは、システムタイムカウンタ（ＳＴＣ）部４２４からのクロックにより決定される。

上述したＳＴＢ制御部４０４による指示等（ＳＴＢ装置４１６の内部構成各々の動作制御）は、プログラムメモリ部４０４ａに格納された制御プログラムにより実行される。その際、ＳＴＢ制御部４０４による制御過程においてワークメモリ部４０７が適宜利用される。

このＳＴＢ制御部４０４およびデコーダ部４０２を含めＳＴＢ装置４１６の内部動作のタイミングは、ＳＴＣ部４２４からのクロックで規制できる。また、光ディスク装置４１５のＳＴＣ４４０とＳＴＢ装置４１６のＳＴＣ部４２４を同期させることで、光ディスク装置４１５およびＳＴＢ装置４１６を含めたストリーマシステム全体の動作タイミングを規制できる。

ＳＴＣ４４０とＳＴＣ部４２４を同期させる方法としては、データ転送インターフェース部４１４とデータ転送インターフェース部４２０との間で受け渡されるストリームデータ中の基準クロック（ＳＣＲ）により、ＳＴＣ４４０およびＳＴＣ部４２４をセットする方法がある。

図１９の装置構成を機能別にみると、ＳＴＢ装置４１６内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割／分類できる。

ここで、「受信時刻管理部」は、デモジュレータ（復調部）４２２、受信情報セレクタ部４２３、多重化情報分離部４２５、ＳＴＢ制御部４０４等で構成される。この「受信時刻管理部」は、衛星アンテナ４２１でデジタルＴＶ放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。

「ストリームデータ内容解析部」は、多重化情報分離部４２５、ＳＴＢ制御部４０４等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、Ｉ，Ｂ，Ｐの各ピクチャ位置および／またはＰＴＳ値を抽出する。

「ストリームデータ転送部」は、多重化情報分離部４２５、受信情報セレクタ部４２３、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置４１５へ転送する。

「時間関連情報生成部」は、多重化情報分離部４２５、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻（タイムスタンプ）情報と「ストリームデータ内容解析部」で抽出した表示時刻情報（ＰＴＳ値および／またはフィールド数）との間の関係情報を作成する。

図２０は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。図２０を用いてこの発明の基本的特徴について説明する。

ＴＶの表示方式の１つであるＮＴＳＣ方式では、１秒間に３０枚の画面／ピクチャ（フレーム）を映像信号としてＴＶのモニタスクリーンに表示している。通常のＴＶでは、インターレース方式を用いているので、１画面の全走査線に対して始めに１本おきに画面を走査して表示し、その後で１本ずらした画像を１本おきに走査することで直前の画面の間を埋めて１枚の画面（ピクチャ）の表示を行う。この１本おきに表示する画像をフィールドと呼ぶ。

ＮＴＳＣ方式では、毎秒３０フレーム／６０フィールドを表示している。このＮＴＳＣ方式は主に日本とアメリカで採用されている表示方式である。それに対して、主に欧州で採用されているＰＡＬ方式では、毎秒２５フレーム／５０フィールドの表示を行っている。

図２０（ａ）は、毎秒３０枚変化する画面／ピクチャ（フレーム）を表示時刻（プレゼンテーションタイム；または再生時間）１に沿って並べた図である。

画面／ピクチャの表示時刻（再生時間）１を表す情報としては、
（ａ）”ある特定の画面（ピクチャ）からの差分フィールド枚数”で表す方法と；
（ｂ）”ＰＴＳ（プレゼンテーションタイムスタンプ；または再生タイムスタンプ）”で表す方法がある。

ＰＴＳは、２７ＭＨｚおよび／または９０ｋＨｚの基準クロックを利用し、常にインクリメント（カウンタの値が１ずつ増加）するカウンタの値で表示時刻を表す方法で用いることができる。たとえば、２７ＭＨｚ（または９０ｋＨｚ）の基準クロックでインクリメントするカウンタで各画面／ピクチャ（フレーム）を示すときのカウンタの値が、ＰＴＳの値として用いられる。

デジタルＴＶでの受信信号情報内には、各ピクチャ毎のＰＴＳ値がピクチャヘッダ情報４１（図１（ｊ）参照）内に含まれている。

図２０（ａ）では、Ｉピクチャａの表示時刻がＰＴＳＮｏ．１で表わされ、Ｉピクチャｉおよびｑの表示時刻がＰＴＳＮｏ．２およびＰＴＳＮｏ．３で表わされている。

いま、例えばユーザから、Ｉピクチャａ表示の何時間何分何秒後の画面（ピクチャ）を表示するように指示を受けたとする。すると、上記指定時間間隔（何時間何分何秒後）が２７ＭＨｚおよび／または９０ｋＨｚのカウント値に換算される。そして、この換算値とＩピクチャａ表示のＰＴＳ値（ＰＴＳＮｏ．１）との加算結果を計算して、ユーザから指示された「表示すべき画面（ピクチャ）」を検索することができる。

情報記憶媒体２０１上に記録されたストリームデータは、図１（ｇ）その他に示したように各トランスポートパケット毎にタイムスタンプを付加して記録されているので、このタイムスタンプ情報を利用してストリームデータに対する時間管理を行っている。

しかし、このタイムスタンプ情報はユーザには認知できないため、ユーザは表示時刻（再生時間）１を用いて、見たい画面（ピクチャ）を指定することになる。

この場合、ストリームデータを時間管理するためのタイムスタンプ情報とユーザが指定可能な表示時刻（再生時間）１情報との間の関係を示す情報が必要になる。この関係を示す情報が、図２０（ｂ）に示す時間関係テーブル２（あるいは図１５の再生タイムスタンプリストＰＴＳＬ）である。

図２０（ｂ）に例示するように、時間関係テーブル２には、各ＰＴＳ値（ＰＴＳＮｏ．１、ＰＴＳＮｏ．２、ＰＴＳＮｏ．３、…）毎に、対応するデータ転送時刻情報（Ｉピクチャ転送開始時刻４）、データ転送時刻情報（Ｉピクチャ転送終了時刻５）、セル先頭から目的のＩピクチャまでの通算パケット数１０が記述されている。

たとえばＰＴＳＮｏ．１のＩピクチャａについてみると、データ転送時刻情報（Ｉピクチャ転送開始時刻４）の行のタイムスタンプ（ＡＴＳ）＃１は図２（ｃ）のＩピクチャａ情報７の先頭側パケット（ＡＰ）＃１のタイムスタンプ（ＡＴＳ）＃１に対応し、データ転送時刻情報（Ｉピクチャ転送終了時刻５）の行のタイムスタンプ（ＡＴＳ）＃２は図２（ｃ）のＩピクチャａ情報７の末尾側パケット（ＡＰ）＃２のタイムスタンプ（ＡＴＳ）＃２に対応している。ここではＩピクチャａが最初のピクチャなので、ＰＴＳＮｏ．１のＩピクチャａに対する通算パケット数１０は、図２０（ｂ）に示すように「１」となる。

同様にＰＴＳＮｏ．２のＩピクチャｉについてみると、データ転送時刻情報（Ｉピクチャ転送開始時刻４）の行のタイムスタンプ（ＡＴＳ）＃３は図２（ｃ）のＩピクチャｉ情報８の先頭側パケット（ＡＰ）＃３のタイムスタンプ（ＡＴＳ）＃３に対応し、データ転送時刻情報（Ｉピクチャ転送終了時刻５）の行のタイムスタンプ（ＡＴＳ）＃４は図２（ｃ）のＩピクチャｉ情報８の末尾側パケット（ＡＰ）＃４のタイムスタンプ（ＡＴＳ）＃４に対応している。ここではＩピクチャｉが最初のＩピクチャａから８５１００枚後としているので、ＰＴＳＮｏ．２のＩピクチャｉに対する通算パケット数１０は、図２０（ｂ）に示すように「８５１０１」となる。ＰＴＳＮｏ．３以後についても同様である。

図２０（ｂ）に示すような時間関係テーブル２を、ストリームデータ（図１（ａ）、図２０（ｃ）その他のＳＴＲＥＡＭ．ＶＲＯ１０６）に関する管理情報（図１５のＳＦＩＴ）が記録されている領域に記録し、この時間関係テーブルを利用して、ユーザにとってピクチャ単位の画面位置指定ができるようにした所に、この発明の大きな特徴がある。

ここで、上記時間関係テーブル２と図１５に示した再生タイムスタンプリストＰＴＳＬとの対応関係について、説明しておく。

図１（ｇ）その他に示されたタイムスタンプをＡＴＳとしたとき、図１５の再生タイムスタンプリストＰＴＳＬに含まれるＰＴＳの値とＡＴＳとは、以下のような関係を持つ：
（１）セル（ストリームセル）は記録されたビットストリームの一部を参照するものである；
（２）ＡＵ（通常Ｉピクチャ）は記録されたビットストリームの連続した一部である（ＡＵはセルの一部に対応する）；
（３）ＡＵ（セルの一部に対応するＩピクチャ）がどのＳＯＢＵに含まれるかは、図１５のアクセスユニット開始マップＡＵＳＭにより示される（図１６参照）；
（４）ＰＴＳの値は対応ＡＵの再生時間（表示時刻；あるいはプレゼンテーションタイムＰＴＭ）である（ＡＵに対応するＰＴＳの値は、再生時間に関して、セルの一部に対応する）；
（５）セル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は該当セルのトランスポートパケットまたはアプリケーションパケットＡＰの到着時間である（ＳＣ＿Ｓ＿ＡＰＡＴは、再生時間に関して、ＰＴＳの値に対応する）；
（６）トランスポートパケットまたはアプリケーションパケットＡＰは、その先頭にタイムスタンプＡＴＳを伴う（図２２、図２９（ｇ）等参照）；
（７）ＰＴＳの値は、ＰＴＳＬに含まれる（図１５参照）；
（８）上記（３）〜（７）から、ＰＴＳＬに含まれるＰＴＳの値は、ＡＵＳＭ、ＳＣ＿Ｓ＿ＡＰＡＴ等を仲介して、ＡＴＳに対応することになる。

よって、再生タイムスタンプリストＰＴＳＬは、ＡＵ（Ｉピクチャ）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）と、ビットストリームに含まれるパケットのタイムスタンプＡＴＳとの関係（再生時間に関する関係）を示す情報（ＰＴＳの値）を含む「時間関係テーブル（図２０（ｂ））」であると言える。

あるいは、ＰＴＳＬ（時間関係テーブル）は、ＰＴＳの値とＡＴＳとの対応関係を示す情報であるとも言える。

ところで、ＢピクチャあるいはＰピクチャを表示するためには、必ずＩピクチャの表示（デコード）から開始する必要がある。このため、図２０（ｂ）に示す時間関係テーブル２は、Ｉピクチャ位置でのタイムスタンプと対応する表示時刻情報を一覧表として示してある。

ここでは、表示時刻情報として、”ＰＴＳ情報（ＰＴＳの値）”、”特定基準画面（ピクチャ）からの差分フィールド数”、”年月日時刻情報”等を用いることができる。

なお、表示時刻情報として図２０（ｂ）に示すような絶対値表示を行う代わりに、各Ｉピクチャ間の差分情報（例えば各Ｉピクチャ間に挿入されるフィールド数情報）を使用することも可能である。（フィールド数を利用した時間関係テーブルについては、図２８を参照して後述する。）
また、図２０（ｂ）では表示時刻情報として”ＰＴＳ情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面（ピクチャ）からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。

図２０（ｂ）に示す時間関係テーブル２では、各Ｉピクチャ毎の転送開始時刻４の値がタイムスタンプ（ＡＴＳ）＃１、＃３、＃５として一覧表に記録されているだけでなく、Ｉピクチャの転送終了時刻５の値もタイムスタンプ（ＡＴＳ）＃２、＃４、＃６として記録されている。

このため、早送り再生（ファーストフォワードＦＦ）あるいは早戻し再生（ファーストリバースＦＲなどの特殊再生を行う場合には、”タイムスタンプ（ＡＴＳ）＃１から＃２まで”、”タイムスタンプ（ＡＴＳ）＃３から＃４まで”、”タイムスタンプ（ＡＴＳ）＃５から＃６まで”というように、再生するＩピクチャのトランスポートパケット位置（またはアプリケーションパケット位置）を指定することで、情報記憶媒体２０１から、Ｉピクチャ情報（またはアクセスユニットＡＵ情報）のみを再生し、デコードし、表示することが可能となる。

図２０（ａ）の実施の形態では、オリジナルセル（図４参照）の表示開始ピクチャ位置（Ｂピクチャｆの位置）を基準に採っている。このオリジナルセルの表示開始ピクチャのＰＴＳ値（ＰＴＳＮｏ．５）とその直前にあるＩピクチャａのＰＴＳ値（ＰＴＳＮｏ．１）との差分が、ＰＴＳオフセット９である。このＰＴＳオフセット値９は、図３（ｈ）に示したように、オリジナルセル情報２７２内に記録される。

具体的には、図２０（ａ）に示すように、オリジナルセルの表示開始ピクチャをＢピクチャｆとし、その時のＰＴＳ値をＰＴＳＮｏ．５とする。その直前のＩピクチャａの表示時刻をＰＴＳＮｏ．１とすると、ＰＴＳオフセット９の値は、”ＰＴＳＮｏ．５ − ＰＴＳＮｏ．１”で求まる。

ユーザが特定画面（特定のピクチャフレーム）を指定する場合、オリジナルセルの表示開始位置からの差分表示時間で指定する場合が多い。この差分表示時間を２７ＭＨｚおよび／または９０ｋＨｚのカウンタ数に換算後、ＰＴＳオフセット９の値を加算することで、ユーザが指定した画面（ピクチャフレーム）のＰＴＳ値を算出できる。

図２０（ｂ）に示すように、時間関係テーブル２には、各Ｉピクチャ毎のＰＴＳ値一覧が記録されている。このテーブルを参照し、算出したＰＴＳ値よりも小さく、しかも算出したＰＴＳ値に最も近いＩピクチャ位置のＰＴＳ値を探し、そこに対応したＩピクチャ転送開始時刻４のタイムスタンプ（ＡＴＳ）値を指定して、情報記憶媒体２０１へのアクセスを開始する。

図２０（ｂ）に示すように、時間関係テーブル２には、タイムスタンプと並行して、オリジナルセル先頭位置から該当するＩピクチャまでの通算トランスポートパケット数１０（アクセス位置情報）も記録されている。

したがって、図２０の実施の形態によれば、タイムスタンプ（ＡＴＳ）の代わりにオリジナルセル先頭位置からのトランスポートパケット数（またはアプリケーションパケット数ＡＰ＿Ｎｓ）を指定して、所望のストリームデータ位置へアクセスすることも可能である。

図２０（ｃ）のストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６が図３等に示す情報記憶媒体２０１に記録される場合、ストリームデータ１０６の内容（ＳＯＢまたはＳＯＢＵ）は、所定のデータ記録単位（トランスポートパケットまたはアプリケーションパケット）で、媒体２０１のデータ領域（ＳＴＲＥＡＭ．ＶＲＯ／ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）に記録される。その際、ストリームデータ１０６に関する管理情報（ＳＴＲＩ）も、媒体２０１の管理領域（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）に記録される。

この管理情報（ＳＴＲＩ）に、ストリームデータ１０６のアクセス（Ｉピクチャ情報またはアクセスユニットＡＵへのアクセス）に利用される第１の管理情報（Ｉピクチャ転送開始時刻に対応したＡＴＳ；またはＡＵＳＭ）と；第１の管理情報（ＡＵＳＭ）とは異なるものであって、この第１の管理情報と前記ストリームデータのアクセスに利用される第２の管理情報（ＰＴＳ；またはＳＣ＿Ｓ＿ＡＰＡＴ）との間の関係を示す第３の管理情報（時間関係テーブル；またはＰＴＳＬ）が記録される。

ここで、ストリームデータ１０６はＭＰＥＧ規格に基づき圧縮されたビットストリームであり、前記第２の管理情報はストリームデータの再生時間（ＰＴＳ）に対応する。

図２１は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図である。

情報記憶媒体２０１上に記録されたストリームデータ（図１、図２その他のＳＴＲＥＡＭ．ＶＲＯ１０６）内のデータ構造に関し、図２１を用いて、各ピクチャ情報６０１０〜６０３０の記録位置とストリームブロック（ＳＯＢＵ）との間の配置関係を説明する。

この実施の形態では、ストリームデータはストリームブロック（ＳＯＢＵ）単位で記録され、所定画像（ピクチャ）へのアクセス指定にはタイムスタンプ情報が利用される。

図１９のＳＴＢ装置４１６から再生開始位置としてタイムスタンプ値が指定された場合において、指定されたタイムスタンプ値に対応するストリームブロック（ＳＯＢＵ）を算出するための情報が、図３（ｈ）のタイムマップ情報２５２（あるいは図１５のタイムマップ情報ＭＡＰＬ、もしくは図１８のタイムマップ情報）である。

図３（ｈ）の例では、タイムマップ情報２５２は、ストリームデータに対する管理情報記録領域であるＳＴＲＥＡＭ．ＩＦＯ１０５内のストリームオブジェクト情報（ＳＯＢＩ）２４２の一部として記録されている。図１５の例でも、タイムマップ情報ＭＡＰＬはＳＯＢＩの一部として記録されている。

図３（ｉ）に示すタイムマップ情報２５２内では、各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。この場合は、各ストリームオブジェクト情報（ＳＯＢＩ）２４２、２４３毎に、タイムマップ情報２５２内の各ストリームブロックの時間差２６３、２６５の値を逐次加算する。そして、この逐次加算値が、ＳＴＢ装置４１６側により指定されたタイムスタンプ時刻に到達したか否か比較する必要がある。その比較結果を元に、ＳＴＢ装置４１６側により指定された時刻がどのストリームオブジェクト（ＳＯＢ）内の何番目のストリームブロック（ＳＯＢＵ）の中に含まれるタイムスタンプ値と一致するかが割り出される。

図２１（ｃ）に示すように各ピクチャ情報６０１０〜６０３０の境界位置とストリームブロック（ＳＯＢＵ）の境界位置とは必ずしも一致しない。

この場合、例えば図２１（ａ）で示すように、ＰＴＳの値がＰＴＳＮｏ．６であるＰピクチャｏの位置から再生を開始しようとするなら、次のような処理が必要になる。

すなわち、図２１（ｂ）の時間関係テーブル２（内部構成は図２０（ｂ）と同様）からその直前にあるＩピクチャｉのＰＴＳＮｏ．２の値を割り出し、Ｉピクチャｉ情報６０１０が記録されている先頭のトランスポートパケット＃２が含まれるストリームブロック（ＳＯＢＵ）＃Ａ先頭位置から、再生を開始する必要がある。

ただし、ストリームブロック（ＳＯＢＵ）＃Ａ先頭位置から所望のＰピクチャｏの位置まで再生が進むまで、その間の画像情報（図２１（ａ）ではピクチャｉからピクチャｎまで）は外部モニタ（ＴＶ）に出力されない。

図２２は、ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。

図２２に示すように、デジタルＴＶでの放送信号情報にはＭＰＥＧ２と呼ばれる信号圧縮方法が採用されている。ＭＰＥＧによる信号圧縮方法では、ＴＶ表示用の各画面（ピクチャ）は時間差分情報を含まないＩピクチャ５５１と時間差分情報を含むＢピクチャ５５３、５５４とＰピクチャ５５２に分類される。

Ｉピクチャは前後の画面（ピクチャ）情報の影響を受けることなく単体で存在し、１枚の画面（ピクチャ）に対してＤＣＴ変換後、量子化した情報がＩピクチャ圧縮情報５６１となり、Ｉピクチャ情報３１として記録される。Ｐピクチャ５５２はＩピクチャ５５１に対する差分情報５６２のみがＰピクチャ情報３２として記録され、Ｂピクチャ５５３、５５４はＩピクチャ５５１とＰピクチャ５５２に対する差分情報がＢピクチャ情報３３、３４として記録される。

従って、映像再生時にはＰピクチャ５５２やＢピクチャ５５３、５５４単体では画面を生成することができず、必ずＩピクチャ５５１画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報３１〜３４は１個または複数のトランスポートパケット内のペイロードに分割記録されている。この時、各ピクチャ情報３１〜３４の境界位置とトランスポートパケット間の境界位置は常に一致するように記録されている。

図２２のトランスポートパケットがストリーマ（図１９の光ディスク装置４１５）に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ（ＡＴＳ）というタイムスタンプ付きのパケット（アプリケーションパケット）に移し替えられる。

そして、ＡＴＳ付きアプリケーションパケットの一群（通常１０パケット前後）がストリームＰＥＳパケット内のアプリケーションパケットエリアに格納される。

このストリームＰＥＳパケットにパックヘッダを付したものが１つのストリームパックになる。

ストリームＰＥＳパケットは、ＰＥＳヘッダと、サブストリームＩＤと、アプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、上記ＡＴＳ付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。

図２３は、デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。

デジタル放送では、ＭＰＥＧ２規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図２３（ｂ）に示すように、トランスポートパケットヘッダ５１１と、記録情報のデータ本体が記録されているペイロード５１２とで構成されている。

トランスポートパケットヘッダ５１１は、図２３（ａ）に示すように、ペイロードユニット開始インジケータ５０１、パケットＩＤ（ＰＩＤ）５０２、ランダムアクセスインジケータ５０３、プログラムクロックリファレンス５０４等で構成されている。

ＭＰＥＧ圧縮された映像情報は、Ｉピクチャ情報、Ｂピクチャ情報、およびＰピクチャ情報を含んでいる。Ｉピクチャ情報が記録されている最初のトランスポートパケットには、図２３（ａ）のランダムアクセスインジケータ５０３に”１”のフラグが立つ。また、各Ｂ、Ｐピクチャ情報の最初のトランスポートパケットには、図２３（ａ）のペイロードユニット開始インジケータ５０１に”１”のフラグが立つ。

これらのランダムアクセスインジケータ５０３およびペイロードユニット開始インジケータ５０１の情報を利用して、Ｉピクチャマッピングテーブル（図９（ｅ）の６４１）およびＢ、Ｐピクチャ開始位置マッピングテーブル（図９（ｅ）の６４２）の情報が作成される。

たとえば、図２３（ａ）に示したペイロードユニット開始インジケータ５０１に”１”のフラグが立ったトランスポートパケットに対して、Ｂ、Ｐピクチャ開始位置マッピングテーブル（図９（ｅ）の６４２）内の該当個所のビットが”１”になる。

デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図２３（ａ）のパケットＩＤ（ＰＩＤ）５０２で識別される。このＰＩＤ５０２の情報を用いて、ビデオパケットマッピングテーブル（図９（ｅ）の６４３）とオーディオパケットマッピングテーブル（図９（ｅ）の６４４）が作成される。

図２３（ｃ）に示すように、デジタル放送では、１個のトランスポンダに複数の番組（この例では番組１〜番組３）がパケット化された形で時分割されて転送されてくる。

たとえば、図２３（ｂ）のトランスポートパケットヘッダ５１１およびペイロード（記録情報）５１２の情報は、図２３（ｃ）に示される番組２のトランスポートパケットｂ・５２２、ｅ・５２５により転送される。

ユーザが例えば図２３（ｃ）の第２の番組を情報記憶媒体２０１に記録しようとする場合には、図１９に示すＳＴＢ装置４１６内の受信情報セレクタ部４２３において、番組２のトランスポートパケットｂ、ｅのみが抽出される。

そのとき、ＳＴＢ装置４１６では、図２３（ｄ）に示すように、各トランスポートパケット ｂ５２２、ｅ５２５を受信した時刻情報をタイムスタンプ５３１、５３２の形で付加する。

その後、ＩＥＥＥ１３９４の転送方式を用いて図１９のフォーマッタ／デフォーマッタ部４１３にデータを転送する場合には、図２３（ｅ）に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。

図１９のフォーマッタ／デフォーマッタ部４１３では、ＳＴＢ装置４１６からＩＥＥＥ１３９４で転送されてきたストリームデータが、図２３（ｄ）の形（図１（ｇ）の形に相当）に一旦戻される。そして、図２３（ｄ）の形式のビットストリーム（図２３（ｈ）のストリームパック列）が、情報記憶媒体２０１に記録される。

具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとＰＥＳヘッダが配置される（図２３（ｈ）等参照）。

データエリア２１、２２、２３（図１（ｆ））には複数のタイムスタンプおよびトランスポートパケット（図１（ｇ））が逐次詰め込まれるが、１個のトランスポートパケット（図１（ｇ）ではパケットｄ；図２３（ｄ）では番組２のパケットｂ）が複数のセクタ（図１（ｅ）ではＮｏ．０とＮｏ．１；図２３（ｆ）（ｇ）では部分パケット）に跨って記録される。ここに、この発明の特徴の１つがある。

この特徴を生かしたデータ構造を用いることにより、セクタサイズ（例えば２０４８バイト）よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。

デジタル放送では図２３（ｃ）に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、１個のトランスポートパケットｂ・５２２のサイズが１８８バイト（または１８３バイト）の場合が多い。

前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個のデータエリア２１、２２、２３（図１（ｆ））内にはデジタル放送用のトランスポートパケットが１０個前後記録できる。

それに対して、ＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトある大きなロングパケットが転送される場合がある。

デジタル放送などのように１個のデータエリア２１、２２、２３（図１（ｆ））内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造（１パケットのデータを複数パケットに跨って記録できる特徴）を用いることにより、１個のパケットを複数のデータエリア２１、２２、２３に連続して跨るように記録する。

そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。

また、通常のパケットにはタイムスタンプが付いているが、図２３（ｇ）に示すように、部分パケットではタイムスタンプを省略することができる。

このようにすると、２つの隣接ストリームパック（図２３（ｈ））の境界で分断された部分パケット（パケット１つあたり１８８バイトとすれば部分パケットのサイズは１〜１８７バイト；平均して１００バイト弱）を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分（タイムスタンプ１つあたり例えば４バイト）、媒体２０１に対する記憶容量を増やすことができる。

なお、図２３（ｇ）の先頭部分パケットの直後にくるタイムスタンプの位置は、図１０（ｂ）のファーストアクセスポイント６２５あるいは図１０（ｃ）のＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴにより、特定することができる。

図１９の光ディスク装置４１５（ストリーマ）では、タイムスタンプとトランスポートパケットとの組（図２３（ｆ）（ｇ））をそのままの形で情報記憶媒体２０１上に記録する。

図２４は、この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図である。図２４を用いて、ストリームデータ録画時の処理について説明する。この処理は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。

図２３（ｃ）に示すように、１個のトランスポンダ内には複数番組情報が時分割多重化されている。

図１９の受信情報セレクタ部４２３内で、この時分割多重化された複数番組情報のパケット列から、特定番組のみのトランスポートパケットが抽出される（ステップＳ０１）。

「受信時刻管理部（図１９の復調部４２２、受信情報セレクタ部４２３、多重化情報分離部４２５、ＳＴＢ制御部４０４等）」では、必要な番組情報が、多重化情報分離部４２５のメモリ部４２６内に、一時保管される（ステップＳ０２）。

それと同時に、各トランスポートパケット毎の受信時刻が計測され、その計測値が、図２３（ｄ）に示すように、タイムスタンプ（ＡＴＳ）として各トランスポートパケット（またはアプリケーションパケット）毎に付加される。こうして付加されたタイムスタンプ情報は、メモリ部４２６内に記録される（ステップＳ０３）。

次に、「ストリームデータ内容解析部（図１９の多重化情報分離部４２５、ＳＴＢ制御部４０４等）」において、メモリ部４２６内に記録されたトランスポートパケット（アプリケーションパケット）内の情報が解析される。

具体的には、トランスポートパケット（アプリケーションパケット）列から各ピクチャ境界位置の切り出しが行われるとともに、各パケット毎のピクチャヘッダ情報４１からＰＴＳ情報（まあは対応フィールド枚数情報）の抽出が行なわれる（ステップＳ０４）。

ここで、各ピクチャ境界位置の切り出し方法には２通りの方法が存在し、いずれの方法を選択するかはストリームデータの内容による。

第１のピクチャ境界位置切出方法は、トランスポートパケットヘッダ５１１（図２３（ｂ））内のランダムアクセスインジケータ５０３（図２３（ａ））のフラグを検出してＩピクチャ位置を検出し、ペイロードユニット開始インジケータ５０１（図２３（ａ））のフラグ検出からＢまたはＰピクチャ位置を検出する方法である。

第２のピクチャ境界位置切出方法は、ピクチャヘッダ情報４１（図１（ｊ））内にあるピクチャ識別情報５２（図１（ｋ））およびＰＴＳ情報５３（図１（ｋ））を抽出する方法である。

上記の処理（ステップＳ０１〜Ｓ０４）を経た後、「時間関連情報生成部（図１９の多重化情報分離部４２５、ＳＴＢ制御部４０４、データ転送インターフェース部４２０等）」では、タイムスタンプ（ＡＴＳ）とＰＴＳ値との間の関係を示す一覧表として、図２０（ｂ）に示すような時間関係テーブル２（あるいは図１５の再生タイムスタンプリストＰＴＳＬ）を作成し、ＳＴＢ制御部４０４内のワークメモリ部４０７に記録する（ステップＳ０５）。

その後、ＳＴＢ装置４１６および光ディスク装置４１５における受信時刻間隔を保持しながら（つまり図１９のＳＴＣ４４０のカウント値変化とＳＴＣ４２４のカウント値変化との間の関係を一定に保ちながら）、多重化情報分離部４２５のメモリ部４２６に一時保管されたパケットデータ（ストリームデータ）が、光ディスク装置４１５に転送される（ステップＳ０６）。

こうして、光ディスク装置４１５により、メモリ部４２６に一時保管されたストリームデータが、情報記憶媒体２０１上に記録される（ステップＳ０７）。

光ディスク装置４１５へのストリームデータ転送が完了するまでは（ステップＳ０８ノー）、ステップＳ０６〜Ｓ０７の処理が反復される。

光ディスク装置４１５へのストリームデータ転送が済みその録画処理が完了すると（ステップＳ０８イエス）、ＳＴＢ制御部４０４のワークメモリ部４０７内に一時記録されていた時間関係テーブル２（あるいは再生タイムスタンプリストＰＴＳＬ）の情報が、光ディスク装置４１５へ転送される（ステップＳ１０）。

そして、時間関係テーブル２（あるいは再生タイムスタンプリストＰＴＳＬ）の情報が、情報記憶媒体２０１の管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）１０５に記録される（ステップＳ１１）。

なお、上記ステップＳ１１の処理時に、録画されたストリームデータの内容であるストリームオブジェクトの記録時間（図７（ｉ）のＳＯＢ＿ＲＥＣ＿ＴＭ）を、管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ）１０５内のタイムゾーン（ＴＭ＿ＺＯＮＥ）６２４０（図７（ｈ）に記録することができる。

ところで、ストリームデータ録画時にコンテンツプロバイダの著作権保護を目的として暗号化されたストリームデータを記録する場合がある。このように暗号化がなされるときは、全てのトランスポートパケットが暗号化されるとともに、ＳＴＢ装置４１６と光ディスク装置４１５との間のタイムスタンプ転送処理が禁止される。この場合には、情報記憶媒体２０１への（暗号化された）ストリームデータ記録時に、光ディスク装置４１５側で独自にタイムスタンプを付加する必要が生じる。

図１９のＳＴＢ装置４１６側では、トランスポートパケット（アプリケーションパケット）毎の受信時刻管理を行っている。この場合、ＳＴＢ装置４１６側と光ディスク装置４１５側との間で、基準クロック周波数のずれに対する対策（具体的には基準クロックの同期化）が重要課題となる。そこで、以下、暗号化されたストリームデータに対する録画処理について説明する。

図２５は、この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。

まず、図１９のＳＴＢ制御部４０４のワークメモリ４０７内に時間関係テーブル２（図２０（ｂ））あるいは再生タイムスタンプリストＰＴＳＬ（図１５）があるかどうか、チェックされる（ステップＳ５０）。

時間関係テーブル（あるいはＰＴＳＬ）がない場合は（ステップＳ５０ノー）、図２４のステップＳ０４〜Ｓ０５と同様な処理で、時間関係テーブル（あるいはＰＴＳＬ）が作成される（ステップＳ５２）。

こうして時間関係テーブル（あるいはＰＴＳＬ）が作成されたあと、あるいは既に時間関係テーブル（あるいはＰＴＳＬ）がＳＴＢ制御部４０４のワークメモリ４０７内にあるときは（ステップＳ５０イエス）、ＳＴＢ装置４１６から光ディスク装置４１５へ（暗号化された）ストリームデータが転送され、このストリームデータが情報記憶媒体２０１に記録される（ステップＳ５１）。

この（暗号化された）ストリームデータの記録が完了するまで（ステップＳ５３ノー）、ステップＳ５１の処理が継続される。このストリームデータ記録ステップＳ５１は、図２４のステップＳ０１〜Ｓ０３、Ｓ０６と同様な処理内容である。

なお、ステップＳ５２の処理は、ステップＳ５１の処理中にこれと並行して実行されてもよい。

こうして（暗号化された）ストリームデータの記録が完了すると（ステップＳ５３イエス）、ＳＴＢ装置４１６と光ディスク装置４１５との間で基準クロックの同期化処理が実行される（ステップＳ５４）。

この基準クロックの同期化処理は、たとえば以下のようにして行なうことができる。

すなわち、ストリームデータ転送時に、トランスポートパケット（アプリケーションパケット）を特定個数（例えば１万個あるいは１０万個）送信／受信する毎にその送信／受信時刻をＳＴＢ装置４１６と光ディスク装置４１５でそれぞれワークメモリ部４０７と一時記憶部４１１に記録しておく。

その後、ＳＴＢ装置４１６側から光ディスク装置４１５側へトランスポートパケット（アプリケーションパケット）を特定個数送信する毎に送信時刻一覧表を送付する。そして、光ディスク装置４１５側において、送付された一覧表と光ディスク装置４１５側で事前に作成した一覧表とを比較することで、両者間の基準クロック同期ずれ量を算出する。

その後、ＳＴＢ装置４１６から光ディスク装置４１５へ、時間関係テーブル２（あるいはＰＴＳＬ）が転送される（ステップＳ５５）。

こうしてＳＴＢ装置４１６から光ディスク装置４１５へ転送された時間関係テーブル２（あるいはＰＴＳＬ）は、ステップＳ５４の基準クロックの同期化処理で算出した基準クロック同期ずれ量の情報を基に、修正される（ステップＳ５６）。

こうして基準クロック同期ずれ量分修正された時間関係テーブル２（あるいはＰＴＳＬ）が、情報記憶媒体２０１の管理情報領域（図３（ｅ）のＳＴＲＥＡＭ．ＩＦＯ１０５；あるいは図１５のＳＦＩＴ）内に記録される（ステップＳ５７）。

以上のようにすれば、（暗号化された状態の）ストリームデータの記録／再生が可能になる。

上記のような「暗号化されたストリームデータに対する基準クロック同期のずれ補正」方法の代わりに、他の方法として、次のようにしてもよい。

すなわち、図２０（ｂ）に示すように、各Ｉピクチャ間に転送されるトランスポートパケット数を時間関係テーブル２に記録する。そして、（ピクチャ指定方法として）再生開始の画面のタイムスタンプ値を指定する代わりに、セル先頭からの通算トランスポートパケット（またはアプリケーションパケット）数を指定する。

この場合には、タイムマップ情報２５２内の情報として、図３（ｉ）に示したデータ構造の代わりに、図１１に示すように、ストリームブロック毎に含まれるトランスポートパケット数（またはアプリケーションパケット数ＡＰ＿Ｎｓ）６３３を持たせる。

所定の画面（ピクチャ）にアクセスするためＳＴＢ装置４１６側から通算トランスポートパケット数（通算アプリケーションパケット数）が指定されると、光ディスク装置４１５側では、図１１に示すの最初のストリームブロックから順次トランスポートパケット（アプリケーションパケット）数６３３が加算されて行き、加算結果が指定された値に達した時点でのストリームブロック（またはＳＯＢＵ）へ、アクセスが行われる。

図２６は、この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。以下、図２６を用いてストリームデータの再生ステップについて説明する。

ユーザは、希望する再生開始時刻および／または再生終了時刻を、「指定したオリジナルセルの表示開始時刻を基準とした差分時間（何時間何分何秒）」の形で指定することができる。こうして指定された、たとえば特定の再生開始時刻および再生終了時刻を、ＳＴＢ装置４１６内のＳＴＢ制御部４０４が受け取る（ステップＳ２１）。

ＳＴＢ制御部４０４内では、その受け取った再生開始時刻および再生終了時刻の時間情報を、２７ＭＨｚおよび／または９０ｋＨｚのクロックカウント値に換算して、オリジナルセルの表示開始時刻からの差分ＰＴＳ値を算出する。

ＳＴＢ制御部４０４は、光ディスク装置４１５をコントロールしてストリームデータ管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ１０５）内に記録された時間関係テーブル２（またはＰＴＳＬ）を読み取り、ワークメモリ部４０７内に一時記録する（ステップＳ２２）。

また、ＳＴＢ制御部４０４は、光ディスク装置４１５をコントロールしてストリームデータ管理情報記録領域（ＳＴＲＥＡＭ．ＩＦＯ１０５）内に記録されたタイムマップ情報２５２（またはＭＡＰＬ）の情報を読み取り、ワークメモリ部４０７内に一時記録する（ステップＳ２３）。

次に、図３（ｈ）および図２０（ａ）に示したＰＴＳオフセット９の値を読み取り、該当するオリジナルセル（図２０（ａ）ではＢピクチャｆに該当）の表示開始時刻とその直前のＩピクチャａの表示時刻との差（図２０（ａ）ではＰＴＳＮｏ．５−ＰＴＳＮｏ．１）を調べる（ステップＳ２４）。

さらに、図３（ｈ）および図２０（ａ）に示したＰＴＳオフセット９の値を読み取り、
（イ）その値（ＰＴＳオフセット９）と、
（ロ）オリジナルセルの表示開始時刻の直前のＩピクチャ−ａ位置でのＰＴＳ値（ＰＴＳＮｏ．１）（図２０（ａ）のようにオリジナルセルの表示開始ピクチャｆがＩピクチャａの直後にある場合）と、
（ハ）ステップＳ２４で調べた差分ＰＴＳ値（ＰＴＳＮｏ．５−ＰＴＳＮｏ．１）と
を加算し、ユーザが指定した再生開始時刻と再生終了時刻のＰＴＳ値を算出する（ステップＳ２５）。

次に、ユーザが指定した再生開始場所の直前のＩピクチャｉのＰＴＳ値とタイムスタンプ＃２の値を、時間関係テーブル２を利用して調べ（ステップＳ２６）、光ディスク装置４１５に通知する。

光ディスク装置は、図３（ｈ）に示したタイムマップ情報２５２のデータ（図３（ｉ））から、そのＩピクチャｉ情報６０１０（図２１（ｃ））の先頭位置が含まれるストリームブロック（ＳＯＢＵ）＃Ａの先頭のタイムスタンプ（ＡＴＳ）＃１の値を調べるとともに、アクセスすべき先頭セクタ＃αの場所（アドレス）を割り出す（ステップＳ２７）。

こうして割り出されたアドレスに基づいて、光ディスク装置４１５は、図２１（ｃ）のトランスポートパケット（ＡＰ）＃１からの情報を、情報記憶媒体２０１から再生する（ステップＳ２８）。

次に、図１９のＳＴＢ制御部４０４は、デコーダ部４０２へ、ステップＳ２８で再生を開始した情報の表示開始時刻を示すＰＴＳ値（図２１（ａ）のＰＴＳＮｏ．６）を通知する（ステップＳ２９）。

この通知とともに、光ディスク装置４１５はＳＴＢ装置４１６側に、ステップＳ２８で再生を開始した情報を転送する（ステップＳ３０）。

続いて、ＳＴＢ制御部４０４は、デコーダ部４０２内のメモリ４２６からピクチャ識別情報５２（図１（ｋ））を読み取り、入力されたＩピクチャ（光ディスク装置４１５から転送されてきた情報の一部）より前のデータを破棄（あるいは無視）する（ステップＳ３１）。

次に、図１９のビデオデコード部４２８は、ステップＳ３１で入力されたＩピクチャ（図２１（ａ）ではＩピクチャｉ）の先頭位置からデコードを開始し、ステップＳ２９の通知により指定されたＰＴＳ値（図２１（ａ）のＰＴＳＮｏ．６）のところから、表示（ビデオ出力）を開始する（ステップＳ３２）。

以下、ステップＳ２４〜Ｓ２８と同様な処理を反復し、再生終了時刻に対応した情報記憶媒体２０１上のアドレスを調べ、再生終了時刻に対応した終了アドレスまで再生を継続する（ステップＳ３３）。

上記の一連の再生が終了した段階で、図７（ｇ）に示す再生終了位置情報６１１０を、レジューム情報として、管理情報記録領域（図７（ｅ）に示すＳＴＲＥＡＭ．ＩＦＯ１０５）内のビデオマネージャ情報２３１（図７（Ｆ））中に記録することができる。

この再生終了位置情報６１１０のデータ内容としては、図７（ｈ）に示すように該当するＰＧＣ番号６２１０とその中のセル番号６２２０、再生終了位置時刻情報６２３０が記録される。

この時刻情報６２３０はタイムスタンプ値で記録されているが、ＰＴＳ値（あるいはセル再生先頭位置からの通算フィールド数）を時刻情報６２３０として記録することもできる。

再度この再生終了位置情報を（レジューム）情報６１１０の位置から再生開始する場合には、後述する図２７の処理により再生開始位置を求めることができる。

図２６を参照して上述したような標準再生時には、ＳＴＢ装置４１６内の基準クロック作成部であるＳＴＣ部４２４のカウント値が、図１（ｋ）に示すＤＴＳ（デコードタイムスタンプ）情報５４の値に一致した時から、デコーダ部４０２内のデコードが開始される。

図２７は、この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャートである。この処理手順は、図１９に示すＳＴＢ制御部４０４のプログラムメモリ部４０４ａ内に格納された処理プログラムにより実行できる。

早送り再生（ファーストフォワードＦＦ）あるいは早戻し再生（ファーストリバースＦＲ）などの特殊再生を行う場合には、情報記憶媒体２０１上に記録されたＩピクチャ情報のみを抽出再生し、デコード表示する。

この場合、ＳＴＣ部４２４（図１９）とＤＴＳ情報５４（図１（ｋ））と間の同期をはずし、フリーモードでデコードするように、デコーダ部４０２に対して「特殊再生モードの設定」を行う（ステップＳ４１）。

特殊再生時にも、時間関係テーブル２とタイムマップ情報２５２の情報を情報記憶媒体２０１の管理情報記録領域（ＳＴＲＡＭ．ＩＦＯ）１０５から読み取り、ＳＴＢ制御部４０４のワークメモリ部４０７内に記録する（ステップＳ４２）。

次に、該当する再生開始場所に対応したストリームオブジェクト情報（ＳＯＢＩ）２４２のタイムマップ情報２５２を読み取り、ＳＴＢ制御部４０４内のワークメモリ部４０７に一時記録する（ステップＳ４３）。

次に、時間関係テーブル２から、各Ｉピクチャ位置（図１６の例では各ＡＵ＃の位置）での開始時刻／終了時刻のタイムスタンプ値を抽出する（ステップＳ４４）。

次に、タイムマップ情報２５２から、該当するＩピクチャのタイムスタンプ値が含まれるストリームブロック（ＳＯＢＵ）を調べ、その先頭セクタのアドレスを調べる（ステップＳ４５）。

たとえば、特殊再生時には、後述する図２８（ｂ）のＩピクチャ情報６０１０〜６０５０のみがデコードされて表示される。このＩピクチャ情報６０１０〜６０５０の位置は、時間関係テーブル２およびタイムマップ情報２５２の情報を利用して、求めることができる。

次に、光ディスク装置４１５は、情報記憶媒体２０１上の各Ｉピクチャが含まれる禅ストリームブロック（ＳＯＢＵ）内の情報を再生し、再生した情報を多重化情報分離部４２５内のメモリ部４２６に転送する（ステップＳ４６）。

次に、図１９のデコーダ部４０２内において、多重化情報分離部４２５のメモリ部４２６に転送されたデータ内のピクチャ識別情報５２（図１（ｋ））を読み取り、この情報５２を基にＩピクチャ以外のデータを破棄する（ステップＳ４７）。

つまり、ステップＳ４７においては、再生・転送されたストリームデータの中から、ピクチャ識別情報５２を用いてＩピクチャ情報のみが抽出され、ビデオデコード部４２８において抽出されたＩピクチャ情報のみがデコードされる。

次に、デコーダ部４０２内の多重化情報分離部４２５のメモリ部４２６内部で選別された（つまり破棄されなかった）Ｉピクチャデータを、フレームメモリ部４０６に転送する（ステップＳ４８）。

こうしてフレームメモリ部４０６に転送されたＩピクチャのデータが、ＴＶ（あるいはビデオモニタ）４３７の表示スクリーン上で、逐次表示される（ステップＳ４９）。

図２８は、この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。

図２０の実施の形態では、表示時刻情報として図２０（ｂ）に示すように絶対値表示を行なっているが、その代わりに各Ｉピクチャ間の差分情報（例えば各Ｉピクチャ間に挿入されるフィールド数情報）を使用することも可能である。

また、図２０（ｂ）では表示時刻情報として”ＰＴＳ情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面（ピクチャ）からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。この場合の例が、図２８の時間関係テーブル６である。

図２８（ｂ）に示すように、各グループオブピクチャ（ＧＯＰ）は、あるＩピクチャ位置を先頭とし、そのＩピクチャから次のＩピクチャの直前までのピクチャ群を示す。図２８（ｃ）に示した時間関係テーブル６のデータ構造では、表示時間情報として、各ＧＯＰ毎の表示フィールド枚数が記録されている。

また、時間関係テーブル６内に、ＧＯＰ毎に占有しているストリームブロック（ＳＯＢＵ）の個数も記載している。こうすることで、図３（ｈ）に示したタイムマップ情報２５２を使用せずに、与えられた表示時間情報から、直接、Ｉピクチャ情報の先頭位置が記録してあるストリームブロック（ＳＯＢＵ）へのアクセスか可能となる。

図２８（ｂ）の例におけるＧＯＰ＃２とＧＯＰ＃３の境界位置では、ＧＯＰの切り替わり位置とストリームブロック（ＳＯＢＵ）の切り替わり位置が一致している。このように隣接ＧＯＰの境界と隣接ＳＯＢＵの境界とが一致する場合に、図２８（ｃ）に示した時間関係テーブル６内のＧＯＰ終端マッチングフラグが”１”に設定される。こうすることにより、Ｉピクチャ情報先頭位置が含まれるストリームブロック位置（ＳＯＢＵ位置）の同定精度を向上させている。

また、前述したＦＦあるいはＦＲ等の特殊再生時においてはＩピクチャ情報の後端位置を使用するので、図２８（ｃ）の時間関係テーブル６には各ＧＯＰ内のＩピクチャサイズ情報も持たせている。

図２９は、この発明の一実施の形態において、ストリームデータ（ＳＯＢＵ）内のパケット（ＡＰ）がどのように再生されるかを説明する図である。

図２９は、図１（ｃ）のストリームブロック＃＃１、＃２、…を、全て一定サイズ（２ＥＣＣブロックサイズ）のＳＯＢＵ＃１、＃２、…で構成した場合を例示している。

図２９（ｆ）は、ＳＯＢＵ＃１の先頭セクタＮｏ．０（図２９（ｅ））のデータ構造と、ＳＯＢＵ＃１に隣接するＳＯＢＵ＃２の末尾セクタＮｏ．６３（図２９（ｅ））のデータ構造を示している。図示しないが、セクタＮｏ．０〜セクタＮｏ．６２も同様な構想を持つ。

図２９（ｆ）に示すように、セクタＮｏ．０に対応するストリームパックのパックヘッダにはシステムクロックリファレンスＳＣＲが記録され、セクタＮｏ．６３に対応するストリームパックのパックヘッダにもシステムクロックリファレンスＳＣＲが記録されている。

いま、再生しようとするピクチャ（ユーザが再生時間で指定したピクチャ）がＳＯＢＵ＃２の中間（図１６では、たとえばＡＵ＃１が示す位置）に存在するとする。ユーザが再生時間で指定したピクチャは、セル開始アプリケーションパケット到着時間ＳＣ＿Ｓ＿ＡＰＡＴに対応する。

この場合、図１９の記録再生部４０９に含まれるディスクドライブ（図示せず）は、ＳＯＢＵ＃２の中間に直接アクセスすることはできず、ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置にアクセスする。そして、図２９（ａ）のストリームデータ（ＳＴＲＥＡＭ．ＶＲＯ）１０６の再生は、ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から始まる。

ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から再生開始位置（ＳＣ＿Ｓ＿ＡＰＡＴに対応する位置）までの間隔は、図２０（ａ）で説明したＰＴＳオフセット９に対応する。

ＳＯＢＵ＃１とＳＯＢＵ＃２との境界位置から再生開始位置（ＳＣ＿Ｓ＿ＡＰＡＴに対応する位置）までの間に存在するアプリケーションパケットは、デコードはされているが、再生出力はされない（画面表示されない）。これは、図２６のステップＳ３１の処理に対応している。

図２９（ｇ）は、ＰＴＳの情報（ＰＴＳ値あるいはＰＴＳオフセット）と再生しようとするアプリケーションパケットＡＰとが、図２０（ａ）の時間関係テーブル２によって関係付けられていることを図解したものである。

ここで、上記時間関係テーブルと図１５に示した再生タイムスタンプリストＰＴＳＬとの関係について、改めて整理しておく。

図１（ｇ）その他に示されたタイムスタンプをＡＴＳとしたとき、図１５の再生タイムスタンプリストＰＴＳＬに含まれるＰＴＳの値とＡＴＳとは、以下のような関係を持つ：
（１）ストリームセルは記録されたビットストリームの一部を参照するものである；
（２）ＡＵ（通常Ｉピクチャ）は記録されたビットストリームの連続した一部である（ＡＵはセルの一部に対応する）；
（３）ＡＵ（セルの一部に対応するＩピクチャ）がどのＳＯＢＵに含まれるかは、ＡＵＳＭにより示される（図１６参照）；
（４）ＰＴＳの値は対応ＡＵの再生時間（表示時刻；あるいはプレゼンテーションタイムＰＴＭ）である（ＡＵに対応するＰＴＳの値は、再生時間に関して、セルの一部に対応する）；
（５）セル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は該当セルのアプリケーションパケットＡＰの到着時間である（ＳＣ＿Ｓ＿ＡＰＡＴは、再生時間に関して、ＰＴＳの値に対応する）；
（６）アプリケーションパケットＡＰは、その先頭にタイムスタンプＡＴＳを伴う（図２９（ｇ）等参照）；
（７）ＰＴＳの値は、ＰＴＳＬに含まれる（図１５参照）；
（８）上記から、ＰＴＳＬに含まれるＰＴＳの値は、ＡＵＳＭ、ＳＣ＿Ｓ＿ＡＰＡＴ等を仲介して、ＡＴＳに対応する。

よって、再生タイムスタンプリストＰＴＳＬは、ＡＵ（Ｉピクチャ）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）と、ビットストリームに含まれるパケットのタイムスタンプＡＴＳとの関係（再生時間に関する関係）を示す情報（ＰＴＳの値）を含む「時間関係テーブル（図２０（ｂ））」である。

あるいは、ＰＴＳＬ（時間関係テーブル）は、ＰＴＳの値とＡＴＳとの対応関係を示す情報であるとも言える。

最後に、各実施の形態の説明中で用いた一部の用語の意味について纏めておく：
＊ストリームオブジェクト（ＳＯＢ）は、記録済みビットストリームのデータを示す。ＳＲ＿ＴＲＡＮＳ．ＳＲＯファイル内には、最大９９９個のＳＯＢを記録できる。

＊ストリームオブジェクトユニット（ＳＯＢＵ）は、ＳＯＢ内にオーガナイズされる基本単位である。つまり、各ＳＯＢは、ＳＯＢＵの連なり（チェーン）からなる。なお、とくに編集後は、ＳＯＢの先頭および／または末尾のＳＯＢＵは、そのＳＯＢの有効部分に属していないデータを含むことがある。

ＳＯＢＵは、再生時間あるいは再生順序により特徴付けられるのではなく、一定サイズ（３２セクタ分のサイズあるいは２ＥＣＣブロック分のサイズ）により特徴付けられる。

＊アクセスユニット（ＡＵ）は、個別の再生に適した記録済みビットストリームにおける、任意の単一連続部分を指す。このＡＵは、ＭＰＥＧエンコードされたビットストリームにおいては、通常はＩピクチャに対応する。

＊アクセスユニット開始マップ（ＡＵＳＭ）は、該当ＳＯＢのどのＳＯＢＵがＡＵを含むのかを示すものである。

＊アプリケーションパケット（ＡＰ）は、記録中にアプリケーションデバイスからやってくるビットストリームの一部である。あるいは、ＡＰは、再生中にアプリケーションデバイスへ行くビットストリームの一部である。これらのＡＰは、多重化トランスポートに含まれ、記録中は一定サイズ（最大６４５７４バイト）を持つ。

＊アプリケーションタイムスタンプ（ＡＴＳ）は、各ＡＰの前に配置され、３２ビット（４バイト）で構成される。ＡＴＳは、９０ｋＨｚの基本部分と２７ＭＨｚの拡張部分とで構成されている。

＊セル（あるいはストリームセルＳＣ）は、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルはオリジナルセルと呼ばれ、ユーザ定義ＰＧＣ内のセルはユーザ定義セルと呼ばれる。プログラムセット中の各プログラムは、少なくとも１つのオリジナルセルからなる。夫々のプレイリスト内のプログラムの各部分は、少なくとも１つのユーザ定義セルからなる。ストリーマにおいて、単にセルという場合は、ストリームセル（ＳＣ）のことをいう。各ＳＣは記録済みビットストリームの一部を参照するものである。

＊セル番号（ＣＮ）は、ＰＧＣ内のセルに割り振られた番号（１〜９９９）である。

＊ストリームセルエントリポイント情報（ＳＣ＿ＥＰＩ）は、記録の一部をスキップするための道具として用いるもので、任意のストリームセル（ＳＣ）内に存在できる。

＊ストリームオブジェクトの開始アプリケーションパケット到着時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）は、該当ＳＯＢに属する最初のＡＰの到着時間を指す。この到着時間は、９０ｋＨｚの基本部分と２７ＭＨｚの拡張部分とで構成されている。

＊ストリームオブジェクトの終了アプリケーションパケット到着時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）は、該当ＳＯＢに属する最後のＡＰの到着時間を指す。

＊ストリームセルの開始アプリケーションパケット到着時間（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当ＳＣに属する最初のＡＰの到着時間を指す。

＊ストリームセルの終了アプリケーションパケット到着時間（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当ＳＣに属する最後のＡＰの到着時間を指す。

＊ナビゲーションデータは、ビットストリーム（ＳＯＢ）に対する、記録、再生、および編集の制御をする際に用いられるデータである。

＊プレイリスト（ＰＬ）は、ユーザが再生シーケンスを任意に定義できるプログラム部分のリストである。ＰＬは、ユーザ定義ＰＧＣとして記述される。

＊プログラム（ＰＧ）は、ユーザにより認識されあるいは定義されるところの、記録内容の論理単位である。プログラムセット内のプログラムは、１以上のオリジナルセルからなる。プログラムは、オリジナルＰＧＣ内でのみ定義される。

＊プログラムチェーン（ＰＧＣ）は、上位概念的な単位である。オリジナルＰＧＣの場合、ＰＧＣはプログラムセットに対応するプログラムの連なり（チェーン）を示すものである。一方、ユーザ定義ＰＧＣの場合は、ＰＧＣはプレイリストに対応するものであってプログラムの一部の連なり（チェーン）を示すものである。

＊プログラムチェーン情報（ＰＧＣＩ）は、ＰＧＣの全体的な再生を示すデータ構造である。ＰＧＣＩはオリジナルＰＧＣおよびユーザ定義ＰＧＣのいずれでも使用される。ユーザ定義ＰＧＣはＰＧＣＩだけで構成され、そのセルはオリジナルＰＧＣ内のＳＯＢを参照するようになっている。

＊プログラムチェーン番号（ＰＧＣＮ）は、ユーザ定義ＰＧＣに割り振られた連続番号（１〜９９）である。

＊プログラム番号（ＰＧＮ）は、オリジナルＰＧＣ内のプログラムに割り振られた連続番号（１〜９９）である。

＊プログラムセットは、全てのプログラムで構成されるディスク（記録媒体）の記録内容全体を指す。オリジナルの記録に対して再生順序が変わるような編集がどのプログラムに対してもなされていないなら、プログラムセットの再生にあたっては、プログラムの記録順序と同じ再生順序が用いられる。

＊リアルタイム記録とは、バッファメモリサイズが限られている場合において、制限された転送レートでコード化された任意のストリームデータを制限された転送レートで転送している限り、バッファメモリがオーバーフローすることなく、そのストリームデータをディスク（記録媒体）に記録できるような記録をいう。

この発明に係る各実施の形態における効果をまとめると以下のようになる：
１．ストリームデータ内に記録されたタイムスタンプデータ（ＡＴＳ）とユーザに対する表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブルあるいはＰＴＳＬ）を管理情報（ＳＦＩＴ）の一部に持たせることにより、高い精度で、ユーザが指定した表示時刻から、再生／画面表示を開始させることが可能となる。

２．ユーザは、編集時に、記録済みのストリームデータの部分消去範囲または並び替えの指定範囲を、モニタＴＶ上での表示時刻で指定する。

上記「１．」のように、ストリームデータ内に、管理情報（ＳＦＩＴ）の一部として、タイムスタンプデータと表示時刻情報との間の関係を示す時間関係テーブル（あるいはＰＴＳＬ）を持たせる。これにより、この時間関係テーブル（あるいはＰＴＳＬ）を用いて、正確に編集点位置（部分消去範囲あるいは並び替えの指定範囲）を設定することが可能となる。その結果、ストリームデータに対する時間管理をタイムスタンプデータ（ＡＴＳ）を用いて行うことができ、かつユーザリクエストに応じた正確な編集処理を保証できる。

３．上記「１．」のように、ストリームデータ内に時間関係テーブル（あるいはＰＴＳＬ）を持たせてあるので、タイムスタンプデータ（ＡＴＳ）あるいは表示時刻情報（ＰＴＳ）のいずれか一方の情報を再生終了位置情報（レジューム情報）として記載するだけで、ストリーマ再起動時の再生開始位置（レジューム再生開始位置）を、正確に設定できる。

４．再生終了位置情報（レジューム情報）をタイムスタンプデータ（ＡＴＳ）で記録することにより、情報記憶媒体上の特定位置にアクセスする場合、タイムマップ情報２５２を用いてアクセスすべきアドレスを、素早く知ることができる。

５．ＭＰＥＧによる圧縮データは必ずＩピクチャからの再生開始が必要となる。各Ｉピクチャ開始位置（あるいはアクセスユニットＡＵの開始位置）でのタイムスタンプデータ（ＡＴＳ）と表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブル）を記録することにより、所望のＩピクチャ（所望のＡＵ）へのアクセス制御を、タイムマップ情報２５２を用いて高速に行える。

６．各Ｉピクチャ開始位置（各ＡＵの開始位置）でのタイムスタンプデータ（ＡＴＳ）と表示時刻情報（ＰＴＳあるいはフィールド情報）との間の関係を示す情報（時間関係テーブル）を記録することにより、タイムマップ情報２５２との組み合わせで、Ｉピクチャ（ＡＵ）を含むストリームブロック（あるいはＳＯＢＵ）位置のアドレスが分かる。このため、Ｉピクチャのみの再生・表示を行うファーストフォワードＦＦあるいはファーストリバースＦＲなどの特殊再生処理が可能となる。

なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。

さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から１または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも１つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。

この発明の一実施の形態に係るストリームデータのデータ構造を説明する図。 この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図。 この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図。 この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図。 タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容その他を説明する図。 オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図。 この発明の他の実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに再生終了位置情報／レジューム情報、ＶＭＧＩ管理情報／記録時間情報等の構造）を説明する図。 図１その他に示されたＰＥＳヘッダの内部構造を説明する図。 図１に示されたストリームブロックヘッダの内部構造を説明する図。 図１に示されたセクタデータヘッダの内部構造を説明する図。 この発明の一実施の形態におけるタイムマップ情報の他例を説明する図。 ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図。 ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図。 ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１３のＰＧＣＩ＃ｉ）の内部データ構造を説明する図。 ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図。 アクセスユニット開始マップ（ＡＵＳＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。 アクセスユニット開始マップ（ＡＵＳＭ）およびアクセスユニット終了マップ（ＡＵＥＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。 オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図。 この発明の一実施の形態に係るストリームデータ記録再生システム（光ディスク装置／ストリーマ、ＳＴＢ装置）の構成を説明する図。 この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。 この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図。 ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図。 デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図。 この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図。 この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャート図。 この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャート図 この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャート図。 この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。 この発明の一実施の形態において、ストリームデータ（ＳＯＢＵ）内のパケット（ＡＰ）がどのように再生されるかを説明する図。

符号の説明

２０１…情報媒体、４１５…光ディスク装置、４１６…ＳＴＢ装置。

Claims (7)

1. ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、
   トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、
   １以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、
   前記第２データ単位は前記データパケットとタイムスタンプとの組を１以上含んで構成されるとともに、この第２データ単位がヘッダ情報を含み、
   前記ヘッダ情報が前記第１データ単位の時間に関する情報を含み、
   前記第１データ単位の時間に関する情報として前記データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第１データ単位の時間に関する情報として前記第１データ単位のタイムスタンプの位置を示す情報が記録され、
   前記ヘッダ情報が、前記管理エリアとは異なる前記データエリアに記録され、かつ
   前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが設けられた情報記憶媒体。
2. ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位は前記データパケットとタイムスタンプとの組を１以上含んで構成されるとともにこの第２データ単位がヘッダ情報を含み、前記ヘッダ情報が前記第１データ単位の時間に関する情報を含み、前記第１データ単位の時間に関する情報として前記データパケットに付随している前記パケット到着時間に関する情報が記録されまたは前記第１データ単位の時間に関する情報として前記第１データ単位のタイムスタンプの位置を示す情報が記録され、前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録され、かつ前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが設けられるように構成された情報記憶媒体を用いる記録方法において、
   前記データエリアに前記ストリームデータを記録し、
   前記管理エリアに前記管理情報を記録するように構成された記録方法。
3. ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位は前記データパケットとタイムスタンプとの組を１以上含んで構成されるとともにこの第２データ単位がヘッダ情報を含み、前記ヘッダ情報が前記第１データ単位の時間に関する情報を含み、前記第１データ単位の時間に関する情報として前記データパケットに付随している前記パケット到着時間に関する情報が記録されまたは前記第１データ単位の時間に関する情報として前記第１データ単位のタイムスタンプの位置を示す情報が記録され、前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録され、かつ前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが設けられた情報記憶媒体を用いる再生方法において、
   前記管理エリアから前記管理情報を読み取り、
   前記データエリアから前記ストリームデータを読み取るように構成された再生方法。
4. ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位は前記データパケットとタイムスタンプとの組を１以上含んで構成されるとともにこの第２データ単位がヘッダ情報を含み、前記ヘッダ情報が前記第１データ単位の時間に関する情報を含み、前記第１データ単位の時間に関する情報として前記データパケットに付随している前記パケット到着時間に関する情報が記録されまたは前記第１データ単位の時間に関する情報として前記第１データ単位のタイムスタンプの位置を示す情報が記録され、前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録され、かつ前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが設けられるように構成された情報記憶媒体を用いる記録装置において、
   前記データエリアに前記ストリームデータを記録する手段と、
   前記管理エリアに前記管理情報を記録する手段とを備えた記録装置。
5. ＭＰＥＧエンコードされたトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第２データ単位は前記データパケットとタイムスタンプとの組を１以上含んで構成されるとともにこの第２データ単位がヘッダ情報を含み、前記ヘッダ情報が前記第１データ単位の時間に関する情報を含み、前記第１データ単位の時間に関する情報として前記データパケットに付随している前記パケット到着時間に関する情報が記録されまたは前記第１データ単位の時間に関する情報として前記第１データ単位のタイムスタンプの位置を示す情報が記録され、前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録され、かつ前記第２データ単位に含まれる前記データパケットの集まりが１以上のＧＯＰに対応するように構成され、この第２データ単位の末尾部分にパディングパケット用のパディングエリアが設けられた情報記憶媒体を用いる再生装置において、
   前記管理エリアから前記管理情報を読み取る手段と、
   前記データエリアから前記ストリームデータを読み取る手段とを具備した再生装置。
6. 前記ヘッダ情報に前記データパケットの著作権の状態を示す管理情報が記録された請求項１に記載の情報記憶媒体。
7. 前記ストリームデータのうちの任意の単一連続部分あるいはＩピクチャに対応する部分がアクセス単位に対応するものとしたときに、前記管理エリアに、前記アクセス単位とその再生時間との間の関係を記述する情報が記録された請求項１に記載の情報記憶媒体。

Images