JP5306531B2 - ストリームデータを記録する情報記憶媒体、記録方法、再生方法、および再生装置 - Google Patents

Description

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

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

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

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

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

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

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

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

特開平８−２３５８３２号公報

情報記憶媒体としてＤＶＤ−ＲＡＭディスクを用いた場合には、２０４８バイト毎に纏められたセクタ単位でデータが記録される。一方、デジタルＴＶ放送ではＭＰＥＧのトランスポートストリームが採用されており、映像情報が入ったストリームデータは、トランスポートストリームの最小単位として１８８バイトのトランスポートパケット毎に纏まって送信される。このトランスポートパケットのサイズはデジタルＴＶ放送局により異なり、たとえば１３０バイト単位として送信するデジタルＴＶ放送局もある。この受信したトランスポートパケットそのままをＤＶＤ−ＲＡＭディスクなどの情報記憶媒体にセクタ単位で記録した場合、以下のような問題が生じる。すなわち、
１．セクタサイズの２０４８バイトがトランスポートパケットサイズ（たとえば１８８バイト）の整数倍でないため、セクタ内へのトランスポートパケットの記録方法が問題となる。

具体的には、あるセクタ内へトランスポートパケットを先頭から順次配置し、このセクタ内で生じた余りの端数分をパディングエリア扱いとした場合には、各セクタ毎に無駄なパディングエリアが多数発生する。このため、情報記憶媒体上に記録できるストリームデータ量が、セクタ毎のパディングエリアの分、減少する。その結果、情報記憶媒体の実質的な記録容量が少なくなる。

２．ＭＰＥＧ規格に従って映像圧縮されているストリームデータは、情報記憶媒体から再生した後デコーダでデコードされる必要があるが、各トランスポートパケット毎のデコーダに転送される時間間隔はデジタルＴＶ放送局から受信した直後の時間間隔を保持する必要がある。そのため、各トランスポートパケット毎のデコーダへ転送される時間間隔情報が必要となる。

３．情報記憶媒体上に記録される各トランスポートパケットは、それぞれのトランスポートパケットを個々に識別する識別情報を持たないため、検索（サーチ）または編集時に特定のトランスポートパケットを指定する手段がない。

４．情報記憶媒体としてＤＶＤ−ＲＡＭディスクを用いた場合には、２０４８バイト毎のセクタ単位で記録されるため、トランスポートパケット単位での部分的な消去処理が難しい。

５．デジタルＴＶ放送で送信するストリームデータは、ＭＰＥＧ規格に従って映像圧縮されているため、Ｉピクチャ位置からデコードを開始する必要がある。従って、特定の映像位置で部分消去する場合は、実質的にはその先頭にあるＩピクチャ開始位置を境界位置として部分消去する必要がある。しかし、トランスポートパケットをセクタ内に順次記録しただけの情報では、Ｉピクチャ開始位置を上記境界位置とした部分消去処理は難しい。

この発明は上記事情に鑑みなされたもので、その目的は、ストリームデータを効率よく記録できる記録方法を提供することである。

この発明の他の目的は、ストリームデータを効率よく管理できるデータ構造を提供することである。

この発明の一実施の形態に係る情報記憶媒体は、ストリームパケットを用いてＭＰＥＧのＩピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する。この情報記憶媒体では、前記ストリームパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データ領域に記録される前記ストリームデータが形成される。ここで、前記管理情報の一部が、前記ストリームデータの特定部分を参照してその特定部分の再生を管理する第１再生管理情報を含むとともに、前記ストリームデータの前記特定部分を参照してその特定部分の再生を管理する第２再生管理情報を含む。そして、前記Ｉピクチャ情報へのアクセス単位に関するデータをアクセスユニットデータとしたときに、このアクセスユニットデータが存在することを示す第２の情報が前記ストリームデータに関する管理情報の他部に含まれ、前記ストリームパケットが映像データに関する２ビットの著作権情報をそのパケット単位で含む。

ストリームデータを効率よく記録できるようになる。

図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。 この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。 この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図である。 この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図である。 デジタル放送、ＩＥＥＥ１３９４、およびストリーマにおける映像データ転送形態の関係を説明する図である。 ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。 ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係を説明する図である。 図１その他で示されるタイムマップ情報の設定方法をを説明する図である。 記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。 図５その他に示されるストリームパックのデータ構造を説明する図である。 この発明の一実施の形態に係るストリームデータ記録再生システム（光ディスク装置／ストリーマ、ＳＴＢ装置）の構成を説明する図である。 図１１のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。 ストリーマの管理情報（図２または図３のＳＴＲＥＡＭ．ＩＦＯに対応）の内部データ構造を説明する図である。 ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１３のＰＧＣＩ＃ｉ）の内部データ構造を説明する図である。 ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図である。 アクセスユニット開始マップ（ＡＵＳＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図である。 アクセスユニット開始マップ（ＡＵＳＭ）およびアクセスユニット終了マップ（ＡＵＥＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図である。 オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。 この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。

以下、図面を参照してこの発明の一実施の形態に係るストリームデータの記録方法およびそのデータ構造などについて説明をする。

図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。

情報媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎あるいは一回の映像録画単位毎にストリームオブジェクトとして纏められて記録されている。

図１（ｈ）は、ＤＶＤ−ＲＡＭディスク等の情報媒体上に記録されたストリームオブジェクトを例示している。ここでは、ストリームオブジェクト＃Ａ２９８の最後の部分と、それに続いて記録されているストリームオブジェクト＃Ｂ２９９を示している。

ＤＶＤ−ＲＡＭディスク等にこのストリームデータを記録する場合には、図１（ｄ）に示すように、２０４８ｋバイト毎のセクタを最小単位として記録される。各セクタ毎には、図１（ｃ）（ｅ）に示すように、パックヘッダ（あるいはパケットヘッダ）１１〜１５の記録領域とストリームデータを記録するデータエリアに分かれている。

各データエリアには、図１（ｆ）（ｇ）に示すように、タイムスタンプおよびトランスポートパケットが逐次詰め込まれる。これは、以下のように行うことができる。すなわち、
１．タイムスタンプとトランスポートパケットをセクタ内のパックヘッダ１１〜１５以外の場所に順次めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録する。

具体的には、図１（ｇ）では、データエリアＮｏ．１内にタイムスタンプとトランスポートパケットを順次詰め込むと、トランスポートパケット１ｋの所でデータエリアＮｏ．１に入り切れず、トランスポートパケット１ｋの一部がデータエリアＮｏ．１からはみ出してしまう。このトランスポートパケット１ｋの中で、データエリアＮｏ．１からはみ出した部分を、次のセクタＮｏ．２内のデータエリアＮｏ．２の先頭位置に継続して記録する。

２．ユーザ等が行う一回の映像録画の纏まり、もしくは１番組などの同一コンテンツの纏まりをストリームオブジェクトと定義する。そして、情報記憶媒体上に記録されたストリームオブジェクトの最後のトランスポートパケット位置がセクタの境界位置とは異なる場合には、該当するセクタ内に限りこの最後のトランスポートパケット位置以降をパディングエリアとする。

具体的には、図１（ｋ）の例では、トランスポートパケット３２１ａで映像録画が終了し、ここがストリームオブジェクト＃Ｂ２９９の実質的な最終位置になる。その際、このトランスポートパケット３２１ａが図１（ｊ）のデータエリアＮｏ．３２１の途中に配置されている場合には、データエリアＮｏ．３２１に限り、それ以降をパディングエリア２１とする。

以上のようなデータ構造を用いることにより、セクタサイズよりも大きなサイズを持つパケットを効率よく記録することができる。

図１はまた、タイムマップ情報に関係したデータ構造も示している。以下、図１を用いてタイムマップ情報２５２内の各データの内容について説明する。

図１（ｈ）（ｉ）に例示するように、ストリームオブジェクト（ＳＯＢ）＃Ｂ・２９９は複数のストリームブロック（ＳＯＢＵ）＃α〜＃γで構成されている。

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

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

また、ＳＯＢ＃Ｂ・２９９（図１（ｈ））の後続ストリームブロック（ＳＯＢＵ）＃β（図１（ｉ））はデータエリアＮｏ．３３（図１（ｊ））を持ち、データエリアＮｏ．３３にはタイムスタンプ３３ａを伴うトランスポートパケット３３ａ（図１（ｋ））が記録されている。

図１（ｋ）に示すように、ストリームブロック（ＳＯＢＵ）＃αの最初のストリームデータ（トランスポートパケット１ａ）のタイムスタンプ値［０］はタイムスタンプ１ａであり、次のストリームブロック（ＳＯＢＵ）＃β内のストリームデータ（トランスポートパケット３３ａ）のタイムスタンプ値［２８］はタイムスタンプ３３ａとなっている。

図１（ｌ）の第１ストリームブロック時間差２６６の値［３０］は、上記タイムスタンプ３３ａとタイムスタンプ１ａとの差分値（［２８］−［０］）を所定の有効桁数（ここでは有効１桁）で丸める（切り上げる）ことで与えられる（［２８］−［０］≒［３０］）。

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

図１の表記方法では、ストリームオブジェクト＃Ｂ２９９の先頭セクタのセクタ番号を１とし、順次セクタ番号を増加させている。セクタ番号とデータエリア番号は一致させ、それに合わせてタイムスタンプ番号とトランスポートパケット番号を設定している。すなわち３３番目のセクタ内のデータエリア内に配置された最初のタイムスタンプとトランスポートパケットの組を”３３ａ”とし、同一データエリア内の次の組を順次”３３ｂ”、”３３ｃ”、………と番号を設定する。ここで、トランスポートパケット３２ｊ、３２０ｋのように直前のデータエリアに入り切らずに次のデータエリアに跨ったタイムスタンプまたはトランスポートパケットの番号は、直前のデータエリア番号に合わせて表示している。また図１（ｋ）の鍵括弧［］内はタイムスタンプの実際の値を例示している。

図１（ａ）〜（ｃ）に示すように、パックヘッダ（またはパケットヘッダ）１１〜１５内の情報において、セクタ内共通情報４１としては、パックヘッダサイズ５１、タイムスタンプデータサイズ５２、トランスポートパケットサイズ５３が記載されている。

ここで、図１（ｄ）のセクタＮｏ．１の例を取れば、図１（ｂ）の検索情報４２の中でセクタ内の最初のタイムスタンプ値５４とは、図１（ｋ）のタイムスタンプ１ａ［＝０］の値を意味する。また、検索情報４２の中でセクタ内の最後のタイムスタンプ値５５とは、タイムスタンプ１ｋ（図示せず）の値を意味している。

ところで、多くの辞書では各ページ毎に脚注もしくはヘッダ位置に該当ページ最初と最後の単語を記載して、検索を容易にしている。それと同様に、上記２個の情報（図１（ａ）に示す最初のタイムスタンプ値５４と最後のタイムスタンプ値５５）により、ストリームデータの検索を容易にしている。

同一のタイムスタンプあるいはトランスポートパケットが隣接するセクタを跨いで配置され得るため、各セクタ毎に単独でアクセスした場合には、最初のタイムスタンプ位置情報が必要となる。図１（ａ）に示したファーストアクセスポイント５６は、パケットヘッダ直後から数えた最初のタイムスタンプ位置までのビット数を意味している。しかし、この実施の形態ではそれに限らず、例えば最初のトランスポートパケット先頭位置までのビット数を（ファーストアクセスポイント５６相当の）情報として持っても良い。

この実施の形態では、ファーストアクセスポイント５６の値としてデータエリアのサイズよりも大きな値を指定可能にすることで、セクタサイズよりも大きなサイズを有するパケットに対してもタイムスタンプ先頭位置を指定することができるようになっている。

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

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

セクタＮｏ．１のファーストアクセスポイント５６の値としてセクタＮｏ．１のデータエリアのサイズよりも大きな値に設定することにより、セクタＮｏ．１内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が次以降のセクタに存在することが示される。

セクタ単位での部分消去（図９参照）を行った場合には、次のセクタに跨らない実質的に有効なタイムスタンプとトランスポートパケットの組の最終位置情報５７（図１（ａ））が必要となる。

この実施の形態においては、完全な形で記録されている（他セクタへ跨って配置されない）タイムスタンプとトランスポートパケットの組数で記載されているが、それに限らず、例えば最終位置アドレスなどの情報を（最終位置情報５７として）記録することも可能である。

図１（ａ）（ｂ）に示すように、箇々のトランスポートパケットに関するビットマップ情報４３は、Ｉピクチャ位置フラグ５８と、ピクチャ先頭位置フラグ５９と、暗号情報６０を含んでいる。図１（ａ）のＩピクチャ位置フラグ５８およびピクチャ先頭位置フラグ５９の情報は、図５を参照して後述するランダムアクセスインジケータ３０３およびペイロードユニット開始インジケータ３０１の情報を利用して作成できる。また、暗号情報６０には、コピープロテクトに利用される情報が適宜記録される。

図１（ｂ）のセクタ内共通情報４１および検索情報４２から、該当セクタ内のトランスポートパケット数が分かる。その各トランスポートパケット毎に配列順に１ビットずつ対応させ、条件に該当したトランスポートパケットに対して”１”のフラグを立てることができる。このフラグを立てた個々のトランスポートパケットに関するビットマップ情報４３も、図１（ｂ）（ｃ）に示すように、パックヘッダ内に記録されている。

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

前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個のデータエリア内にはデジタル放送用のトランスポートパケットが１０個前後記録できる。それに対してＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトもある大きなロングパケットが転送される場合がある。

図１のデータ構造を採用すれば、デジタル放送などのように１個のデータエリア内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、１個のパケットを複数のデータエリアに連続して跨るように記録できる。デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック（図１（ｉ）のＳＯＢＵ）内に端数なく記録することができる。

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

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

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

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

上記データファイル１０３を含むサブディレクトリ１０１の上位階層にあるルートディレクトリ１００には、その他の情報を格納するサブディレクトリ１１０を設けることができる。このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットＶＩＤＥＯ＿ＴＳ１１１、オーディオプログラムを収めたオーディオタイトルセットＡＵＤＩＯ＿ＴＳ１１２、コンピュータデータ保存用のサブディレクトリ１１３等がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エントリポイント情報（ＳＣ＿ＥＰＩ）２８５は、記録内容を部分的にスキップする道具として利用できる情報である。このエントリポイント情報（ＳＣ＿ＥＰＩ）２８５には、図１４に示すように、プライマリテキスト情報（ＰＲＭ＿ＴＸＴＩ）の有無によって２つの形式（タイプＡとタイプＢ）がある。

ここで、エントリポイントとは、オリジナルＰＧＣの場合はプログラム内に入る位置、またユーザ定義ＰＧＣの場合はプログラムの一部に入る位置を示すものである。各ＰＧＣは、自身のエントリポイントセットを持つことができる。これらのエントリポイントはセル情報（ＳＣＩ）の一部として記録される。記録内容の再生時に記録内容の一部をスキップする場合に、これらのエントリポイントを用いることができる。

全てのエントリポイントは、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間（ＡＰＡＴ）により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図１４のＥＰ＿ＡＰＡＴにより示される。

図３（ｇ）のＳＯＢＩ＃Ｂに含まれる図３（ｈ）のタイムマップ情報２５２は、図３（ｉ）に示すように、ストリームブロック番号２６０、第１ストリームブロックサイズ２６１、第２ストリームブロックサイズ２６２、…と、第１ストリームブロック時間差２６６、第２ストリームブロック時間差２６７、…とを含むことができる。

タイムマップ情報２５２を構成するストリームブロック時間差２６６の具体例については、図１（ｌ）に示されている。タイムマップ情報２５２を構成する各ストリームブロック時間差の内容については、図８を参照して後述する。

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

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

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

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

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

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

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

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

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

それぞれのセルの指定範囲は、開始時刻と終了時刻の時間指定により行うことができる。すなわち、部分消去あるいは編集がなされる前（ストリームデータの録画直後）のオリジナルセル＃２・２９２の該当セルの開始時間２８３および該当セルの終了時間２８４（図３（ｈ））の時間には、図１（ｋ）の例に従えば、該当するストリームオブジェクト＃Ｂ２９９内の最初のタイムスタンプ１ａの値と最後のタイムスタンプ３２１ａの値が使用される。

それに対して、図４のユーザ定義セル＃１１・２９４での時間範囲指定は任意時刻を指定でき、指定されたトランスポートパケットに対応したタイムスタンプの値が、該当セルの開始時間および該当セルの終了時間の値に設定される。

ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法としては、この実施の形態では
（１）各ストリームオブジェクトの記録開始位置からの累計記録データ量でアクセスする方法と；
（２）ＭＰＥＧ方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識してアクセスする方法と
の２通りが可能となっている。

図１（ｇ）から明らかなように全トランスポートパケットにはタイムスタンプ情報が付属記録されており、このタイムスタンプ情報を利用して各トランスポートパケットに対してアクセス可能となっている。

情報記憶媒体としてＤＶＤ−ＲＡＭディスクを用いた場合には、それぞれ１６セクタ毎にＥＣＣブロックが構成されている。そこで、この発明の実施の形態ではＥＣＣブロックの整数倍（例えば２倍）毎にストリームデータをグループ化し、各グループ毎の経過時間のテーブルを持つことで、上記（１）の「累計記録データ量でアクセスする」方法を可能にしている。上記（２）の「デコードタイミングを意識してアクセスする」方法については、図１１の説明において詳述する。

この発明の実施の形態では、各グループ毎の経過時間のテーブルをタイムマップ情報２５２としている。このタイムマップ情報２５２は、図３（ｇ）（ｈ）に示すように、それぞれのストリームオブジェクトに対応するストリームオブジェクト情報（＃Ａ・２４２；＃Ｂ・２４３）の一部に記録されている。

また、この発明の実施の形態では上記グループ（２ＥＣＣブロック毎にグループ化されたセクタ）をストリームブロック（あるいはＳＯＢＵというデータユニット）と呼ぶ（図４上段、あるいは図１（ｉ）参照）。

各ストリームブロック（ＳＯＢＵ）の先頭に配置されているセクタの開始位置には、タイムスタンプが配置されていない場合がある。この場合は、各ストリームブロック（ＳＯＢＵ）毎の経過時間の定義が難しい。

その対応策としては、以下のものがある。

Ａ）各ストリームブロック毎の特定位置に配置されているタイムスタンプ値を、それぞれのストリームブロック固有時間とする。

具体的には各ストリームブロック毎の最初に配置されている（しかも前のセクタから跨って記録されてない）タイムスタンプの値をそれぞれのストリームブロックの開始時刻とする。

Ｂ）各ストリームブロック毎の固有時間（例えば開始時刻）間の差分時間を、各ストリームブロック毎の経過時間と定義する。

Ｃ）上記経過時間（差分時間）情報をタイムマップ情報２５２に記録する。

上記差分時間（経過時間）で表示する方がデータ量が少なくなるメリットがある。しかしこの発明の実施の形態ではそれに限らず、それぞれのストリームブロック固有時間をタイムマップ情報２５２に記録することも可能である。

Ｄ）上記経過時間（差分時間）情報の丸め値をタイムマップ情報２５２に記録する。

経過時間（差分時間）情報の計算結果を丸める（桁数の低い値を切り上げまたは四捨五入する）ことで桁数の低い値を省略し、この丸め値をタイムマップ情報２５２に記録することで、データサイズを少なくできる。

Ｅ）部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つ。

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

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

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

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

このトランスポートパケット内は、図５（ｂ）に示すように、トランスポートパケットヘッダ３１１と、記録情報のデータ本体が記録されているペイロード３１２とで構成されている。

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

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

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

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

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

図５（ｃ）に示すように、デジタル放送では、１個のトランスポンダに複数の番組（この例では番組１〜番組３）がパケット化された形で時分割されて転送されてくる。たとえば、図５（ｂ）のトランスポートパケットヘッダ３１１およびペイロード（記録情報）３１２の情報は、図５（ｃ）に示される番組２のトランスポートパケットｂ３２２、トランスポートパケットｅ３２５により転送される。

ＩＥＥＥ１３９４では、図５（ｅ）（ｆ）に示すように、各ＩＥＥＥアイソクロナスパケットヘッダ３４３、３４４は、アイソクロナスパケットヘッダ３５１およびコモン・アイソクロナスパケットヘッダ３５２を含む。このコモン・アイソクロナスパケットヘッダ３５２内には、フォーマット依存のリザーブ領域が設定されている。

この発明の実施の形態では、図５（ｇ）に示すように、コモン・アイソクロナスパケットヘッダ３５２内のフォーマット依存のリザーブ領域に、ソースＩＤ３６１と、データブロックサイズ情報３６２と、Ｉピクチャ開始位置フラグ３６３が格納される。このようにフォーマット依存のリザーブ領域にＩピクチャ開始位置フラグ３６３を設定することで、ストリームデータをアイソクロナス・モードで転送する時に同時にリアルタイムでストリームデータ内のＩピクチャ位置指定（すなわちＩピクチャの開始位置に該当するトランスポートパケットの指定）も行えるようにしている。ここに、この実施の形態の大きな特徴がある。

なお、図５（ｈ）において、アプリケーションパケットエリアの末尾に番組２のトランスポートパケットｂの前半部３４６が記録されるのではなく、このアプリケーションパケットエリアの末尾が余白となる場合もある。この場合は、アプリケーションパケットエリアの末尾は部分パケットではなく、予約バイト数のスタッフィングエリア（その先頭にタイムスタンプはない）となる。

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

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

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

図６は、ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。

図６（ａ）〜（ｄ）は、図１（ｈ）〜（ｋ）に相当する内容を示している。図６の例では、全てのストリームブロック（ＳＯＢＵ）＃α〜＃γが一定サイズ（３２セクタ／２ＥＣＣブロック＝６４ｋバイト）で構成されている。そのうち、ストリームブロック（ＳＯＢＵ）＃γの最終セクタＮｏ．ｎ、およびその１つ手前のセクタＮｏ．ｎー１（図６（ｅ））を構成するパック構造が、図６（ｆ）〜（ｊ）に例示されている。

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

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

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

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

図６（ｆ）のアプリケーションパケットエリアは、図５（ｈ）（ｉ）に示したものと同様に構成できる（図５（ｈ）（ｉ）のパケットを図６ではアプリケーションパケットに読み替える）。

アプリケーションパケットエリアは、各々が（図５（ｈ）のスタッフィングエリアおよび図５（ｉ）の部分パケットを除き）アプリケーションタイムスタンプ（ＡＴＳ）を先頭に持つアプリケーションパケット群で構成される。たとえば１８８バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、１０個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。

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

ストリームブロック（ＳＯＢＵ）＃γの最終セクタＮｏ．ｎは、図６（ｇ）〜（ｊ）に示すようになっている。すなわち、図６（ｇ）に示すように最終セクタＮｏ．ｎはパックヘッダおよびパディングパケットにより構成される。このパディングパケットは、図６（ｈ）に示すように、そのアプリケーションパケットエリアにパディングエリア２１（図１（ｋ）のパディングエリア２１に対応）を含む。

パディングエリア２１内で最初のアプリケーションパケットエリア（先頭スタッフィングパケット）の場合は、図６（ｉ）に示すように、アプリケーションタイムスタンプ（ＡＴＳ）付きのスタッフィングパケット（実質的な記録内容を持たないゼロバイトデータ）で埋められる。もしパディングエリア２１が複数セクタ分の長さを持つときは、パディングエリア２１内で２番目以降のアプリケーションパケットエリア（後続スタッフィングパケット）は、図６（Ｊ）に示すように、ＡＴＳなしのスタッフィングパケット（ゼロバイトデータ）で埋められる。

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

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

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

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

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

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

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

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

図７に示すように、Ｉピクチャ５０１の圧縮情報５１１はＩピクチャ情報５２１としてトランスポートパケット１ａ、１ｂ、…に記録され、Ｂピクチャの差分情報５１３、５１４はＢピクチャ情報５２３としてトランスポートパケット３３ａ、…に記録され、Ｂピクチャの差分情報５１５、５１６はＢピクチャ情報５２４としてトランスポートパケット４１ｄ、…に記録され、Ｐピクチャ差分情報５１２はＰピクチャ情報５２２としてトランスポートパケット（ＴＰ）４８ｈ〜２９８ｇに記録される。このように各Ｉ、Ｂ、Ｐピクチャ情報は異なるトランスポートパケットに記録されている。

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

Ｉピクチャ情報５２１が記録されている最初のトランスポートパケット１ａには、そのランダムアクセスインジケータ３０３（図５（ａ））に”１”のフラグが立つ。また、各Ｂ、Ｐピクチャ情報５２３、５２４、５２２の最初のトランスポートパケット３３ａ、４１ｄ、４８ｈには、そのペイロードユニット開始インジケータ３０１（図５（ａ））に”１”のフラグが立つ。このランダムアクセスインジケータ３０３とペイロードユニット開始インジケータ３０１の情報を利用して、図１（ａ）のＩピクチャ位置フラグ５８とピクチャ先頭位置フラグ５９の情報が作成される。同様に、個々のトランスポートパケットに関するビットマップ情報４３（図１（ｂ））としてコピープロテクトに利用する暗号情報６０などの情報も記録される。

図７のＩピクチャ（５０１）の位置情報（Ｉピクチャ位置情報）は、図３（ｇ）（ｈ）に示すようにオリジナルセル情報（ＳＣＩ）（＃１・２７２等）内にエントリポイント情報（ＳＣ＿ＥＰＩ）２８５として記録されている。

エントリポイント情報２８５内のデータ構造は、図７（ａ）（ｂ）に示すように、同一ストリームオブジェクト内に存在する個々のＩピクチャ位置情報を示すエントリポイント位置（第１エントリポイント位置（ＥＰ＿ＡＰＡＴ）５３１、第２エントリポイント位置５３２、第３エントリポイント位置５３３、…、最終エントリポイント位置５３５）の情報の羅列記載形式になっている。

またエントリポイント位置（ＥＰ＿ＡＰＡＴ）５３１の情報内容としては、図７（ａ）に示すように、Ｉピクチャ情報５２１の最初の情報が記録されているトランスポートパケット１ａに対応したタイムスタンプ１ａの値が記録されている。個々のエントリポイント位置（ＥＰ＿ＡＰＡＴ）５３２、５３３、５３５の情報内容も、同様に、それぞれの対応Ｉピクチャ情報の最初の情報が記録されているトランスポートパケットに対応したタイムスタンプ８７ｆ、１８３ｄ、２９８ｇの値が記録される。

図４に示した例えばユーザ定義セル＃１１・２９４に対する該当セルの開始時間および／または該当セルの終了時間の情報は、図３（ｆ）のユーザ定義ＰＧＣ情報テーブル２３４内に記録されている。この場合に、図７のＢピクチャ情報５２４から再生したい場合には、該当セルの開始時間としてタイムスタンプ４１ｄを設定することができる。このように、該当セルの開始時間あるいは該当セルの終了時間の情報は、Ｉピクチャ位置に関わりなく任意のタイムスタンプ情報で設定できる。

一方、この実施の形態におけるストリームオブジェクトの開始／終了時刻は、Ｉピクチャ位置を意識して設定される。すなわち、図３（ｈ）および図７（ｄ）に示したストリームオブジェクト情報一般情報２５１の情報内容としては、図７（ｃ）に示すように、録画開始時間を示す記録時間（ＳＯＢ＿ＲＥＣ＿ＴＭ）５４１と、ストリームオブジェクト開始時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）５４２と、ストリームオブジェクト終了時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）５４３が記録されている。

このストリームオブジェクト開始時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）５４２は、必ず、Ｉピクチャ情報５２１の先頭が記録されているトランスポートパケット１ａに対応したタイムスタンプ１ａの値に設定される必要がある。同様に、ストリームオブジェクト終了時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）５４３は、Ｉピクチャ情報の直前のトランスポートパケット２９８ｇに対応したタイムスタンプ２９８ｇの値に設定される必要がある。

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

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

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

図８は、図１その他で示されるタイムマップ情報２５２の設定方法を説明する図である。

図１（ｇ）あるいは図８（ｂ）に示したようにタイムスタンプ（ＴＭＳ）およびトランスポートパケット（ＴＰ）（またはアプリケーションパケットＡＰ）を順次詰めて記録してあるストリームデータに対して、図８（ａ）のように例えば２ＥＣＣブロック（３２セクタ）毎に区切って、ストリームブロック（ＳＯＢＵ）＃α、＃β、＃γ、〜＃λを構成する。

ストリームブロック（ＳＯＢＵ）＃αの先頭位置には、タイムスタンプ（ＴＭＳ）１ａが配置されている。このタイムスタンプ１ａは、ＳＯＢＵ＃αの先頭パケットの到着時間（ＳＯＢＵ＿Ｓ＿ＡＰＡＴ）を示している。このタイムスタンプ１ａの値［０］が、ＳＯＢＵ＃αの開始時刻になる。

他のストリームブロック（ＳＯＢＵ＃β〜ＳＯＢＵ＃λ）に対しては、前のセクタから跨って記録されないという条件の下で、最初に配置されたタイムスタンプ３３ａ、６５ａ、９８ａ、…３２１ａの値（［２８］、［６３］、［９８］、［２９７］）が、各ストリームブロック（ＳＯＢＵ＃β〜ＳＯＢＵ＃λ）の開始時刻とされる。

各ストリームブロック、たとえば最後のＳＯＢＵ＃λの、最終パケットの直前にある最後のタイムスタンプ３００ａは、ＳＯＢＵ＃λの最終パケットの到着時間（ＳＯＢＵ＿Ｅ＿ＡＰＡＴ）を示している。このタイムスタンプ３００ａの値［３００］が、ＳＯＢＵ＃λの終了時刻になる。

なお、最後のＳＯＢＵ＃λの末尾に余白が生じるときは、この余白は実データのないパディングエリア２１（図１（ｋ）あるいは図６（ｈ）〜（ｊ）参照）とされる。

図８（ｂ）に示すように、各ストリームブロック（ＳＯＢＵ＃α〜ＳＯＢＵ＃λ）それぞれの開始時刻を、０、２８、６３、９８、…２９７とする。これらの時刻は、（ａ）秒単位、（ｂ）フィールドあるいはフレーム／ピクチャ数（例えばＮＴＳＣでは３０ピクチャ／秒、６０フィールド／秒、ＰＡＬでは２５ピクチャ／秒、５０フィールド／秒）、および（ｃ）２７ＭＨｚあるいは９０ｋＨｚの基準クロックによるカウント数のうちの、いずれかで表示できる。

図８（ａ）（ｂ）の例示では、最初のストリームブロック（ＳＯＢＵ＃α）の経過時間は［２８］−［０］＝［２８］（有効数２桁）であるが、この経過時間の表現はもっと粗くても実用性は損なわれないので、この経過時間値［２８］の
１桁目を丸め（切り上げ）て、［３０］としている。

２番目のストリームブロック（ＳＯＢＵ＃β）の経過時間は、上記丸め計算結果［３０］を用いると［６３］−［３０］となるが、同様に１桁目を丸め（切り上げ）て［４０］とする。以下同様に後続ストリームブロック（ＳＯＢＵ＃γ〜ＳＯＢＵ＃λ）の経過時間は有効数１桁に丸めた（切り上げた）数値で表現される。

なお、ストリームブロック（ＳＯＢＵ＃λ）以降へはアクセスしないので、図８（ｃ）のように、最後のストリームブロックに対する時間差値をあえてブランクにしている。

以上の丸め計算の結果とタイムマップ情報２５２との関係は、図８（ｃ）に示されている。

ところで、ストリームブロック（ＳＯＢＵ＃λ）以降のストリームブロックは存在しないので、他のストリームブロックと同様な差分時間計算は行えない。そこで、この実施の形態では、最後のストリームブロック（ＳＯＢＵ＃λ）だけは、その中で最後に記録されたタイムスタンプの値（図８（ｂ）の例ではタイムスタンプ３００ａの値［３００］）と最後のストリームブロック（ＳＯＢＵ＃λ）内で最初に記録されたタイムスタンプの値（図８（ｂ）の例ではタイムスタンプ３２１ａの値［２９７］）との間の差分を計算し、切り上げした値を時間差値に設定する方法も可能にしている。これを図８（ｄ）に示す。

なお、図８（ｄ）の最後のＳＯＢＵ＃λの時間差値計算方法は、２つの考え方が可能である。第１は、最後のタイムスタンプ３００ａ（ＳＯＢＵ＃λのＳＯＢＵ＿Ｅ＿ＡＰＡＴ）の丸める前の値［３００］と最初のタイムスタンプ３２１ａの丸める前の値［２９７］を用い、その差分結果［３］を切り上げ丸めして時間差値［１０］を求める方法である。第２は、最後のタイムスタンプ３００ａの丸め値［３００］と最初のタイムスタンプ３２１ａの丸め値［３００］を用い、その差分結果［０］に丸め誤差分［１０］を加えて時間差値［１０］を求める方法である。

第２の方法では、全ての数値の末尾１桁にある「０」を取り除いた有効桁数１で数値を纏め、丸め誤差分を［１］とし、その他の数値の末尾１桁をそれぞれ削除して考えることもできる。

図９は、記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。

前述した一連の情報記載方法は、部分消去されたストリームオブジェクトに対しても適応できる。図９（ｋ）は部分消去前の状態であり、録画直後のストリームオブジェクト（図１（ｈ）その他のＳＯＢ＃Ｂ・２９９）に関するストリームデータ構造およびオリジナルセル範囲、ストリームオブジェクト範囲は、図９（ａ）〜（ｅ）に示すようになっている。

以下、実表示範囲としてタイムスタンプ９７ｃからタイムスタンプ２２４ｋまでの範囲を除いて、その範囲の前後を部分消去した後の処理を説明する。

この実施の形態においては、セクタ単位で部分消去が行なわれる。しかし部分消去後のストリームオブジェクトの再生を行った直後に別のストリームオブジェクトの再生を行い、しかもそれらのストリームオブジェクトの繋ぎ目で画面の乱れを生じさせることなくシームレス再生を可能にするには、ＭＰＥＧビットストリームのＧＯＰ境界位置を保持したまま部分削除を行う必要がある。

タイムスタンプ９７ｃに対応したトランスポートパケット９７ｃの直前のＩピクチャ先頭位置が図７（ａ）の第２エントリポイント位置５３２に示すようにトランスポートパケット８７ｆに存在するとする。この場合、トランスポートパケット８７ｆを含むセクタＮｏ．８７を残し、その前のセクタ以前の全セクタを部分消去し、このタイムスタンプ８７ｆの値を部分消去後のストリームオブジェクトのストリームオブジェクト開始時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）５４２とする（図９（ｌ）参照）。

その結果、たとえば元には３２セクタあったストリームブロック＃γのサイズが３０セクタに減少する。

同時に、それに対応してタイムマップ情報２５２内に記載されるストリームブロック時間差の値も、たとえば４０から３０へと減少する。ストリームブロック＃δ〜＃ηの境界位置は部分消去前後で不変に保たれるので、その部分に関係したタイムマップ情報２５２内情報は変化しない。

図７では省略したがＩピクチャ先頭位置がトランスポートパケット２２５ｅから始まるとすれば、トランスポートパケット２２５ｄを含む図９（ｉ）のセクタＮｏ．２２５まで残し、それ以降の全セクタを消去する。

図９（ｊ）のストリームオブジェクト終了時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）５４３は、上記トランスポートパケット２２５ｄのタイムスタンプ２２５ｄにより設定できる。

部分消去後の該当セルの開始時間（ＳＣ＿Ｓ＿ＡＰＡＴ）２８３／終了時間（ＳＣ＿Ｅ＿ＡＰＡＴ）２８４は、図９（ｉ）に示すように、部分消去の実指定範囲に合わせて、タイムスタンプ９７ｃ、タイムスタンプ２２４ｋとされる。

このような方法でタイムマップ情報（あるいはストリームオブジェクト情報ＳＯＢＩ／オリジナルセル情報ＳＣＩ）が作成される所にこの実施の形態の特徴がある。

なお、部分消去前後で開始時間および／または終了時間は変化するが、ＳＯＢＵサイズは不変（たとえば３２セクタ分６４ｋバイト一定）に保たれる。

部分消去時はＳＯＢＵ単位の消去を行なうことも可能であり、この場合は、オリジナルセル内で最初の（または最後の）タイムスタンプＴＭＳは、必ず、ＳＯＢ内最初の（または最後の）ＳＯＢＵ内に含まれるようになる。

図１０は、図５その他に示されるストリームパックのデータ構造を説明する図である。

各ストリームパックは、図１０（ｄ）に示すようなデータ構造を持っている。すなわち、１４バイトのパックヘッダ１１と、６バイトのＰＥＳヘッダ６０１と、１バイトのサブストリームＩＤと、９バイトのアプリケーションヘッダと、必要に応じて用いられるオプションのアプリケーションヘッダエクステンションと、必要に応じて用いられるオプションのスタッフィングバイトと、アプリケーションタイムスタンプＡＴＳが付されたアプリケーションパケットを１以上含むアプリケーションパケット群とで、１つのストリームパックが構成される（図６（ｆ）参照）。

パックヘッダ１１は、図１０（ｇ）に示すように、パック開始コードの情報、システムクロックリファレンス（ＳＣＲ）ベースの情報、ＳＣＲエクステンションの情報、プログラム多重化レートの情報、パックスタッフィング長の情報等を含んでいる。ＳＣＲベースは３２ビットで構成され、その３２ビット目はゼロとされる。また、プログラム多重化レートとしては、たとえば１０．０８Ｍｂｐｓが採用される。

ＰＥＳヘッダは、図１０（ｆ）に示すように、パケット開始コードプリフィックスの情報、ストリームＩＤ（プライベートストリーム２）の情報、ＰＥＳパケット長の情報を含んでいる。

また、サブストリームＩＤは、図１０（ｆ）に示すように、ストリーム記録データを特定する内容を持つ。具体的には、サブストリームＩＤ＝”００００００１０ｂ”によって、そのストリームパックに格納されたデータがストリーム記録データであることが示される。このストリームＩＤが”１０１１１１１０ｂ”のときは、そのストリームパックがパディングパケット（図６（ｇ）参照）に用いられるものであることが示される。

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

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

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

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

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

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

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

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

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

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

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

図１０（ｃ）のＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴは、図１０（ｂ）あるいは図１（ａ）のファーストアクセスポイント５６に相当する。このファーストアクセスポイント５６は、図１０（ａ）に示すように、パックヘッダ（またはアプリケーションヘッダ）内の検索情報４２（図１（ｂ）参照）内に格納される。

図１０（ｄ）のスタッフィングバイトおよびアプリケーションパケット群は、図６（ｆ）で示したように、アプリケーションパケットエリアを構成している。ここで、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録される。

アプリケーションパケットエリアの終了位置には、予約されたバイト数のスタッフィングエリアが存在できる。

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

図１０（ｄ）において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを（前述したＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯにおいて）記述できるように定義されている。

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

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

図１（ｇ）に示した２つのトランスポートパケット１ｋは、この分割（スプリット）により生じたアプリケーションパケットを示している。

ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。

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

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

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

ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。

図１０のパケット構造は、該当ストリームオブジェクト（ＳＯＢ）の最終セクタ以外に適用できるが、その最終セクタには必ずしも適用されない。最終セクタに対しては、図６（ｉ）（ｊ）のパケット構造が適用される。

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

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

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

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

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

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

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

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

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

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

記録再生部４０９において記録準備ができた段階で、Ｄ−ＰＲＯ部４１０は、一時記憶部４１１に保存されたデータを記録再生部４０９に転送する。これにより、媒体２０１への記録が開始される。一時記憶部４１１に保存されたデータの記録が済むと、その続きのデータはフォーマッタ／デフォーマッタ部４１３からＤ−ＰＲＯ部４１０へシームレスに転送されるようになっている。ここで、一時記憶部４１１は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。

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

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

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

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

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

光ディスク装置４１５内のデータ転送インターフェイス部４１４では、ＩＥＥＥ１３９４で転送されてきたストリームデータが図５（ｄ）の形に一旦戻され、図５（ｄ）の形のタイムスタンプとトランスポートパケットの組が、情報記憶媒体２０１上に順次詰めて記録される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１１のフォーマッタ／デフォーマッタ部４１３では、ＳＴＢ装置４１６からＩＥＥＥ１３９４で転送されてきたストリームデータが、図５（ｄ）の形（図１（ｇ）の形に相当）に一旦戻される。そして、図５（ｄ）の形式のビットストリーム（図５（ｊ）のストリームパック列）が、情報記憶媒体２０１に記録される。具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとＰＥＳヘッダが配置される（図５（ｊ）等参照）。

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

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

デジタル放送では図５（ｃ）に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、１個のトランスポートパケットｂ・５２２のサイズが１８８バイト（または１８３バイト）の場合が多い。前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個のデータエリア（図１（ｆ））内にはデジタル放送用のトランスポートパケットが１０個前後記録できる。それに対して、ＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトある大きなロングパケットが転送される場合がある。

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

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

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

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

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

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

次に、図１１の装置におけるストリームデータ録画時の処理について説明する。図５（ｃ）に示すように、デジタル放送では１個のトランスポンダ内に複数番組情報が時分割多重化されている。その情報に対して受信情報セレクタ部４２３内で図５（ｄ）に示すように特定番組のみのトランスポートパケットを抽出する

前記「受信時刻管理部」では、必要な番組情報を多重化情報分離部４２５内のメモリ部４２６内に一時保管すると同時に各トランスポートパケット毎の受信時刻を測定し、その値を図５（ｄ）のようにタイムスタンプとして各トランスポートパケット毎に付加する。この付加したタイムスタンプ情報はメモリ部４２６内に記録される。

前記「ストリームデータ内容解析部」では、メモリ部４２６内に記録されたトランスポートパケット内の情報が解析される。具体的には、トランスポートパケット列から、各ピクチャ境界位置の切り出しと、再生タイムスタンプ（ＰＴＳ）情報の抽出が行なわれる。各ピクチャ境界位置の切り出し方法は前述したように２通り存在し、ストリームデータ内容に応じて選択する。次にメモリ部４２６に一時保管されたストリームデータを情報記憶媒体２０１上に記録する。

ＳＴＢ装置４１６から再生開始位置としてタイムスタンプ値が指定された場合、対応するストリームブロックを算出するための情報がタイムマップ情報２５２である。このタイムマップ情報２５２は、図３（ｅ）〜（ｈ）に示すように、ストリームデータに対する管理情報記録領域であるＳＴＲＥＡＭ．ＩＦＯ１０５内のストリームオブジェクト情報２４３の一部として記録されている。

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

次に、既に情報記憶媒体２０１上に記録してあるストリームデータの部分消去に関する実施例の説明を行う。

ストリームデータの記録再生装置では、前述した部分消去処理はＳＴＢ制御部４０４により制御され、その中でも特にストリームデータ部分消去制御部と言う名のシーケンシャルプログラムが中心となり処理実行が行なわれる。

図１１のＳＴＢ制御部４０４では、部分消去が行われる前に、ストリームデータに関する管理情報（ＳＴＲＩ）が記載されているＳＴＲＥＡＭ．ＩＦＯ１０５の情報が読み込みまれ、ワークＲＡＭメモリ部４０７に一時保管されている。部分消去処理が完了すると、部分消去対象のセクタが図２のＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６から外される。その後、管理情報（ＳＯＢＩおよびＳＣＩを含むＳＴＲＩ）が図９（ｌ）に示した内容に変更され、図２のＳＴＲＥＡＭ．ＩＦＯ１０５内のデータが書き替えられる。

次に、ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法として、「ＭＰＥＧ方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識した」アクセス方法について説明する。

この発明の実施の形態では、ＳＴＢ装置４１６からアイソクロナス・モードでストリームデータが転送されると同時に、リアルタイムでＩピクチャ情報が転送され、その情報が図１（ａ）のようにストリームデータを記録するＳＴＲＥＡＭ．ＶＲＯ１０６ファイル内に記録される。また、この発明の実施の形態では、この情報は、ストリームデータの管理情報が記録されているＳＴＲＥＡＭ．ＩＦＯ１０５内にも記録される。

図１１に示すＳＴＢ装置４１６側で、例えば図７のＢピクチャ情報５０４を再生表示したい場合には、その直前に存在するＩピクチャ情報５０１の先頭に位置するトランスポートパケット１ａに対応したタイムスタンプ１ａの値を、光ディスク装置４１５に通知する。

光ディスク装置４１５では、図１あるいは図３に示した構造を有するタイムマップ情報２５２の情報を用いて再生開始するセクタ位置を割り出し、情報記憶媒体２０１上の所定位置へアクセスし、再生したいストリームデータをＳＴＢ装置４１６へ転送する。すると、ＳＴＢ装置４１６のデコーダ部４０２では、Ｉピクチャ情報５０１からデコードを開始し、指定されたＢピクチャ情報５０４から表示を開始する。

Ｂピクチャ情報５０４の開始情報が記録されているトランスポートパケット４１ｄ（図７）には、図５（ａ）（ｂ）に示すように、そのトランスポートパケットヘッダ３１１内に表示開始時刻を示す再生タイムスタンプ（プレゼンテーションタイムスタンプ）ＰＴＳ３０５の情報が記録されている。デコーダ部４０２では、このＰＴＳ３０５を読み取って、再生開始時刻を設定する。

図１１のデコーダ部４０２でＩピクチャ位置を抽出する方法に付いて前述した。しかしデジタルＴＶ放送局によっては送信の段階で各ピクチャ位置情報を送信する場合もある。送信の段階で既に記録されている各ピクチャ位置情報について、以下に説明する。

この発明の実施の形態では、部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つとともに、部分消去部分を境界として残存部分を新たなストリームオブジェクトに定義し直すようにしている。この場合、ストリームオブジェクト内の最初と最後のストリームブロックのサイズが他のストリームブロックのサイズより小さくなることがある。そのため、図１（ｌ）あるいは図３（ｉ）に示すようにタイムマップ情報２５２では個々のストリームブロックサイズ情報も記録してある。

この実施の形態においては、上記に限らず、例えば最初と最後のストリームブロックサイズ情報のみ持ち、他にはそれ以外の共通のストリームブロックサイズ情報のみ記録することも可能である。

図１２は、図１１のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。

図１１の光ディスク装置（ストリーマ）４１５において、記録するビットストリーム（トランスポートパケットの内容）が、ストリームパック内のアプリケーションパケットエリアに分配される（ステップＳＴ１０）。

最初のアプリケーションパケットのアプリケーションタイムスタンプ（ＡＴＳ）の先頭バイト（これをＡとする）と、ビットストリームが記録されるストリームオブジェクト（ＳＯＢ）の開始部分にくる最初のストリームパケット内のアプリケーションパケットエリアの開始部分（これをＢとする）とが比較される（ステップＳＴ１２）。

ＡＴＳの先頭バイト（Ａ）と最初のストリームパケット内のアプリケーションパケットエリアの開始部分（Ｂ）とが一致しないときは（ステップＳＴ１４ノー）、たとえば必要バイト数のスタッフィングバイトをストリームパケット内に設けて、先頭バイト（Ａ）と開始部分（Ｂ）とを一致（アライン）させる（ステップＳＴ１６）。

ＡＴＳの先頭バイト（Ａ）と最初のストリームパケット内のアプリケーションパケットエリアの開始部分（Ｂ）とが一致するとき（ステップＳＴ１４イエス）、あるいは先頭バイト（Ａ）と開始部分（Ｂ）とを一致（アライン）させたあと、記録するビットストリームの実際のデータを含む最終アプリケーションパケット（これをＣとする）の末尾と、ビットストリームが記録されるＳＯＢの末尾（これをＤとする）との間に、１ストリームパケット分（１セクタ分）以上の余白があるかどうかチェックされる（ステップＳＴ１８）。

アプリケーションパケット（Ｃ）の末尾とＳＯＢの末尾（Ｄ）との間に１ストリームパケット分（１セクタ分）以上の余白があるときは（ステップＳＴ１８イエス）、この余白は、１つのＡＴＳを含む１以上のスタッフィングパケットで埋められる（ステップＳＴ２０）。

アプリケーションパケット（Ｃ）の末尾とＳＯＢの末尾（Ｄ）との間に余白がないとき（ステップＳＴ１８ノー）、あるいはアプリケーションパケット（Ｃ）の末尾とＳＯＢの末尾（Ｄ）との間の余白がスタッフィングパケットで埋められたあと、記録するビットストリームの内容を含む１以上のアプリケーションパケット群（適宜スタッフィングパケットあるいはスタッフィングエリアバイトを含み得る）が、情報媒体２０１に記録される（ステップＳＴ２２）。

その後、記録情報に対応して管理情報（ＳＴＲＩ）に書き込みが行われる（ステップＳＴ２４）。

上記記録ステップＳＴ２２においては、以下の処理が適宜行なわれる。

（１０）アプリケーションパケットエリアの末尾に余白部分があるときは、この余白部分に（タイムスタンプがなく）所定バイト数のスタッフィングエリア（図５（ｈ）または図１９（ｊ）のパディングエリア３７）を設ける。

また、上記記録ステップＳＴ２２〜ＳＴ２４においては、以下の処理が適宜行なわれる。

（１１）複数のデータユニット（図８（ａ）のＳＯＢＵ＃α…＃λ）によりストリームデータ（ＳＯＢ）を構成し、
所定のタイムスタンプ（ＴＭＳ）情報が内部に記録されている１以上の前記データパケット（図８（ｂ）のＴＰ／ＡＰ）により各々の前記データユニット（ＳＯＢＵ＃α…＃λ）を構成し、
複数の前記データユニット（ＳＯＢＵ＃α…＃λ）のうち、少なくとも、第１のデータユニット（ＳＯＢＵ＃α）内に記録された第１タイムスタンプ（ＴＭＳ１ａ）と、第２のデータユニット（ＳＯＢＵ＃β）内に記録された第２タイムスタンプ（ＴＭＳ３３ａ）との差分に対応した時間差値（図８（ｃ）（ｄ）の切り上げ丸め値）を、管理領域（ＳＴＲＩまたはＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）内に記録する。

（１２）ストリームデータ（ＳＯＢ）に、１以上のセル（図１８）の情報を記録し、
管理領域（ＳＴＲＩまたはＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）に、１以上のセルの集まりを記述したプログラムチェーン（ＰＧＣ）の情報（図３（ｆ）または図１３のＰＧＣＩ）を記録し、
前記ストリームデータ（ＳＯＢ）の記録内容の一部を再生時にスキップする際に、そのスキップ位置の目印として利用できるエントリポイント（ＥＰ）の情報（ＳＣ＿ＥＰＩ）を、前記管理情報（ＳＴＲＩ）に記録する。

（１３）管理情報（ＳＴＲＩ）に、ストリームデータ（ＳＯＢ）の記録時間情報（ＳＯＢ＿ＲＥＣ＿ＴＭ）、前記ストリームデータ（ＳＯＢ）の始まり部分のデータパケット到着時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ）、および前記ストリームデータ（ＳＯＢ）の終わり部分のデータパケット到着時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ）のうち、少なくとも１つを含むストリームオブジェクト情報一般情報（図７（ｄ）のＳＯＢＩ＿ＧＩ）を書き込む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１８に例示された各エントリポイント（ＥＰ＃ｉ、ＥＰ＃ｋ）は、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間（ＡＰＡＴ）により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図１４のＥＰ＿ＡＰＡＴにより示される。

このエントリポイントを用いることにより、例えばセル＃１のＳＯＢＵ＃１からの再生時において、ＳＯＢＵ＃２〜ＳＯＢＵ＃（ｉ−１）をスキップして、ＳＯＢＵ＃ｉの指定位置（エントリポイントＥＰ＃ｉ）から再生を開始することができる。

図１９は、この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。

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

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

この実施の形態では、１個または複数のＥＣＣブロックを単位としてストリームブロックが構成され、このストリームブロック単位でストリーム情報の記録あるいは部分消去が行われる。

この実施の形態では、何個のＥＣＣブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて決めることができる。たとえば、図１９（ｅ）の例では、ストリームブロック＃１は２つのＥＣＣブロック＃α、＃βで構成され、ストリームブロック＃２は３つのＥＣＣブロック＃γ、＃δ、＃εで構成されている。ＤＶＤストリーマでは、２個のＥＣＣブロック（３２セクタ）で１つのストリームブロック（ストリームオブジェクトユニットＳＯＢＵ）が構成される。

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

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

各セクタの内容はストリームパック（詳細は図５、図６、図１０参照）に対応している。そして、たとえばセクタＮｏ．０（図１９（ｄ））に対応するストリームパックは、図１９（ｃ）に示すように、パックヘッダ１ｘと、ＰＥＳヘッダ６ｘと、ストリームブロックヘッダ１１ｘと、データエリア２１ｘとを含んでいる。また、セクタＮｏ．１（図１９（ｄ））に対応するストリームパックは、図１９（ｃ）に示すように、パックヘッダ２ｘと、ＰＥＳヘッダ７ｘと、セクタデータヘッダ１２ｘと、データエリア２２ｘとを含んでいる。

図１９（ｃ）のデータエリア２１ｘは、図１９（ｂ）に示すように、タイムスタンプとトランスポートパケットとのペアの配列（タイムスタンプａ、トランスポートパケットａ、タイムスタンプｂ、………トランスポートパケットｄ）を含んでいる。同様に、データエリア２２ｘは、タイムスタンプとトランスポートパケットとのペアの別配列を含んでいる。一方、後方のデータエリア２３ｘは、図１９（ｂ）に示すように、トランスポートパケットｆ、エンドコード３１ｘ、およびパディングエリア３６ｘを含んでいる。

図１９（ｂ）のタイムスタンプとトランスポートパケットの複数ペアは、図１９（ａ）に示すような配列のビットストリームとなる。

ＳＯＢ＃Ａ・２９８（図１９（ｆ））の前方のストリームブロック＃１（図１９（ｅ））のデータ構造は図１９（ｄ）〜（ｂ）のようになるが、ＳＯＢ＃Ａ・２９８の後方のストリームブロック＃２（図１９（ｇ））のデータ構造は、次のようになる。

すなわち、ストリームブロック＃２の末尾ＥＣＣブロック＃εの後方セクタＮｏ．７８（図１９（ｈ））は、図１９（ｉ）に示すように、パックヘッダ３ｘと、ＰＥＳヘッダ８ｘと、セクタデータヘッダ１３ｘと、データエリア２４ｘとを含んでいる。また、ＥＣＣブロック＃εの最終セクタＮｏ．７９（図１９（ｈ））は、図１９（ｉ）に示すように、パックヘッダ４ｘとパディングパケット４０ｘを含んでいる。

セクタＮｏ．７８のデータエリア２４ｘは、図１９（ｊ）に示すように、トランスポートパケットｚと、エンドコード３２ｘと、パディングエリア３７ｘとを含んでいる。また、最終セクタＮｏ．７９のパディングパケット４０ｘは、図１９（ｊ）に示すように、ＰＥＳヘッダ９ｘとパディングエリア３８ｘを含んでいる。

なお、パディングエリア３７ｘの内容は、図５（ｈ）に示すように、１以上のタイムスタンプとパケットとのペアと、予約バイトのスタッフィングエリア（スタッフィングエリアにタイムスタンプは付かない）とで構成できる。この場合、スタッフィングエリアにはストリームデータの記録はなされない。

一方、パディングエリア３８の内容は、図６（ｉ）（ｊ）に示すように、スタッフィングパケット（先頭だけアプリケーションタイムスタンプＡＴＳが付く）を含むアプリケーションパケットエリアで構成できる。

この発明では、以下のような特徴を持つデータ構造を採用することもできる：
Ａ）各セクタ／ストリームパック毎にパックヘッダ／パケットヘッダを設け、セクタ／ストリームパック毎に必要な情報をパックヘッダ／パケットヘッダ内に記録するデータ構造（図１（ａ）〜（ｃ）、図５（ａ）〜（ｂ）、図１０（ａ）〜（ｇ）参照）。

Ｂ）各トランスポートパケット／アプリケーションパケットがデコーダに転送される時間間隔に関係した時間情報を、タイムスタンプ情報として、各トランスポートパケット／アプリケーションパケットと一緒に情報記憶媒体上に記録するデータ構造（図１（ｋ）〜（ｍ）、図５〜図１０参照）。

Ｃ）タイムスタンプとトランスポートパケット／アプリケーションパケットをセクタ／ストリームパック内のパックヘッダ／パケットヘッダ以外の場所に順次詰めて記録するデータ構造。そして、タイムスタンプの切れ目またはトランスポートパケット／アプリケーションパケット毎に記録されるストリームデータの切れ目がセクタ／ストリームパックの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケット／アプリケーションパケットのどちらかを、隣のセクタ／ストリームパックに跨って配置記録するデータ構造（図１（ｄ）〜（ｇ）、図５（ｅ）〜（ｊ）参照）。

Ｄ）ユーザ等が行う一回の録画映像の纏まりをストリームオブジェクト（ＳＯＢ）とし、一回の映像録画において情報記憶媒体上に記録された最後のトランスポートパケット／アプリケーションパケット位置（１個のストリームオブジェクト内の最後のトランスポートパケット／アプリケーションパケット位置）がセクタ／ストリームパックの境界位置とは異なる場合には、該当するセクタ／ストリームパック内に限りこの最後のトランスポートパケット／アプリケーションパケット位置以降をパディングエリアとするデータ構造（図１（ｇ）（ｋ）、図６（ｇ）〜（ｊ）、図１９（ｊ）参照）。

Ｅ）情報記憶媒体上にストリームデータを記録するファイル（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）とは別に、そのファイル内のストリームデータを管理する管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）を設けてストリームデータの検索および／または編集を容易とするデータ構造。

Ｆ）ストリームデータを管理する管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内では、ＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイル内に記録してあるタイムスタンプの値を、個々のトランスポートパケット／アプリケーションパケット毎の識別／指定に利用するデータ構造（図８（ｂ）〜（ｄ）参照）。

Ｇ）タイムサーチを容易にするため、複数セクタを纏めてストリームブロックという単位（あるいはストリームオブジェクトユニットＳＯＢＵというデータユニット）を管理ファイル上で構成し、このストリームブロック（ＳＯＢＵ）毎の時間情報を持ったタイムマップ情報を、この管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内に持たせるデータ構造（図８（ａ）〜（ｄ）参照）。

なお、少なくともストリームオブジェクト内の最初と最後のストリームブロック（ＳＯＢＵ）のデータサイズを、管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内のタイムマップ情報に記録するようにしてもよい（図３（ｉ）参照）。

Ｈ）各ストリームブロック（ＳＯＢＵ）内の最初に配置されたタイムスタンプ（前のストリームブロックから跨って記録されたタイムスタンプを除く）の値を各ストリームブロック（ＳＯＢＵ）先頭時刻として管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内で管理するデータ構造（図８（ａ）〜（ｄ）参照）。

具体的には、管理ファイル内のタイムマップ情報に各ストリームブロック（ＳＯＢＵ）内で最初に配置されたタイムスタンプ（たとえば図８（ｂ）のＴＭＳ１ａ）の値を記録する。

この発明に係るストリームデータ記録方法では、第１の記録単位（セクタまたはストリームパック）毎に情報記録を行える情報記憶媒体を用い、第２の記録単位（トランスポートパケット／アプリケーションパケット）に分割されたストリームデータが記録される。

上記第２の記録単位（トランスポートパケット／アプリケーションパケット）でストリームデータが記録される第１の記録領域（図３（ｄ）のストリーム記録エリア２２２）内に、上記第１記録単位（セクタ／ストリームパック）毎に付与するパケットヘッダ（あるいはパックヘッダ）情報と、上記第２の記録単位（トランスポートパケット／アプリケーションパケット）のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第２の記録単位（トランスポートパケット／アプリケーションパケット）毎のストリームデータとが記録される。

上記タイムスタンプ情報の切れ目もしくは上記第２の記録単位（トランスポートパケット／アプリケーションパケット）毎に記録されるストリームデータの切れ目が上記第１の記録単位（セクタ／ストリームパック）の境界位置とは異なる場合には、上記タイムスタンプ情報または上記第２の記録単位（トランスポートパケット／アプリケーションパケット）毎に記録されるストリームデータが複数の上記第１の記録単位（セクタ／ストリームパック）に跨って配置されるように記録される（図５（ｅ）の番組２のトランスポートパケットｂの前半部３４６と後半部３４７、および図５（ｈ）〜（ｊ）参照）。

情報記憶媒体上に最後に記録されたストリームデータにおいて、上記第２の記録単位（トランスポートパケット／アプリケーションパケット）の最終位置が上記第１の記録単位（セクタ／ストリームパック）の境界位置とは異なる場合には、最後に記録された上記第１の記録単位（セクタ／ストリームパック）または上記第２の記録単位（トランスポートパケット／アプリケーションパケット）の最終位置以降に、パディングエリア（図１（ｋ）あるいは図６（ｈ）の２１）として、所定のデータ（たとえば、オール１ビットあるいはオール０ビット）が記録される（図６（ｉ）（ｊ）参照）。

上記第１の記録領域（ストリーム記録エリア２２２）内に記録されたデータに関する管理情報を格納する第２の記録領域（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）が記録される（図３（ｄ）（ｅ）参照）。

上記第１の記録領域（ストリーム記録エリア２２２）に関する時間情報が記録された第３の記録領域（ストリームファイル情報）に対して、上記第１の記録単位（セクタ／ストリームパック）を複数集めて第３の記録単位（ストリームブロック／ＳＯＢＵ）が構成される（図６（ｂ）〜（ｅ）、図８（ａ）〜（ｂ）参照）。

上記第１の記録領域（ストリーム記録エリア２２２）内に記録されたストリームデータに対する上記第３の記録単位（ストリームブロック／ＳＯＢＵ）毎の先頭に配置されたタイムスタンプ情報間の差分値が、タイムマップ情報として記録される（図１（ｉ）〜（ｍ）、図８（ａ）〜（ｄ）参照）。

また上記の方法でストリームデータが記録されたデータ構造を有する情報記憶媒体も、この発明の特徴となっている。

さらにＩピクチャ開始位置を意識しながらトランスポートパケット単位での部分消去を可能とする方法として、以下のものがある。

Ｉ）部分消去場所前後で新たにストリームオブジェクトを分割する。

Ｊ）ストリームデータが記録されているＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルに関する情報を記載するストリームファイル情報の情報と、ストリームデータの再生時に使用する再生単位情報（セル情報）を、管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内に持つ。

Ｋ）ストリームデータが記録されているＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルに対してはセクタ単位で部分消去処理を行う。

Ｌ）管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）上ではＩピクチャ開始位置に従ってストリームオブジェクトを分割する。

具体的には、ストリームファイル情報（図７（ｄ）のＳＯＢＩ＿ＧＩ・２５１）内にストリームオブジェクト開始時間の情報（図７（Ｃ）のＳＯＢ＿Ｓ＿ＡＰＡＴ５４２）とストリームオブジェクト終了時間の情報（図７（Ｃ）のＳＯＢ＿Ｅ＿ＡＰＡＴ５４３）を持たせ、部分消去後はＩピクチャ開始位置が記録されているトランスポートパケット（図７の１ａ）に対応したタイムスタンプ（図７の１ａ）の値をストリームオブジェクト開始時間（ＳＯＢ＿Ｓ＿ＡＰＡＴ５４２）の値に変更（あるいは追記）し、部分消去境界位置を含むストリームデータの直後に来るＩピクチャ開始位置が記録されているトランスポートパケットの１個前のトランスポートパケット（図７のＴＰ２９８ｇ）に対応したタイムスタンプ（図７のＴＭＳ２９８ｇ）の値をストリームオブジェクト終了時間（ＳＯＢ＿Ｅ＿ＡＰＡＴ５４３）の値に変更（あるいは追記）する。

Ｍ）管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）上では部分消去指定したトランスポートパケットに対応してセル情報内の開始／終了位置を設定する。

具体的には、部分消去の範囲をトランスポートパケット単位で指定し、その指定範囲に対して残存したトランスポートパケットのうち、先頭のトランスポートパケットに対応したタイムスタンプ（図９（ｊ）のＴＭＳ９７ｃ）の値を新たなオリジナルセルの該当セルの開始時間（図９（ｌ）のＳＣ＿Ｓ＿ＡＰＡＴ２８３）とし、最後のトランスポートパケットに対応したタイムスタンプ（図９（ｊ）のＴＭＳ２２４ｋ）の値を新たなオリジナルセルの該当セルの終了時間（図９（ｌ）のＳＣ＿Ｅ＿ＡＰＡＴ２８４）として管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内に変更（あるいは追記）する。

上述した部分消去方法を適用できる情報媒体は、第１の記録単位（セクタ）毎に情報の記録が行える媒体である。この媒体は、ストリームデータが記録される第１の記録領域（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）と、上記第１の記録領域内に記録されたデータに関する管理情報を記録した第２の記録領域（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）とを持つ。上記第１の記録領域（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）内に、上記第１記録単位（セクタ）毎に付与するパケットヘッダ情報と、上記第２の記録単位（トランスポートパケット）のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第２の記録単位（トランスポートパケット）毎のストリームデータが詰めて記録される。上記第１の記録単位（セクタ）を複数集めて第３の記録単位（ストリームブロック）が構成される。そして、複数の前記第３の記録単位（ストリームブロック）から構成されストリームデータに対する大きなデータのまとまりを示す第４の記録単位（ストリームオブジェクト）が構成される。上記第２の記録領域（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内に、上記第３の記録単位（ストリームブロック）毎の時間情報（タイムマップ情報）と上記第４の記録単位（ストリームオブジェクト）の開始と終了位置での上記第３の記録単位（ストリームブロック）のデータサイズ情報が記録される。

上記第１の記録領域（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）内に記録されたストリームデータは、上記第１の記録単位（セクタ）で部分消去できる。そして、部分消去後は新たなサイズを持った第４の記録単位（ストリームオブジェクト）が形成され、かつ上記新たなサイズを持った第４の記録単位（ストリームオブジェクト）における開始位置もしくは終了位置での上記第３の記録単位（ストリームブロック）でのデータサイズと時間情報の内の少なくともいずれかの情報が、上記第２の記録領域（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内で書き換えられるか、または新規記録される。

この発明の実施により得られる効果をまとめると以下のようになる。

１．各トランスポートパケット毎の時間情報をタイムスタンプ情報として各トランスポートパケットとともに一緒に情報記憶媒体上に記録するため、
ａ）そのタイムスタンプ値に合わせてＳＴＢへトランスポートパケットを転送するタイミングが分かる。

ｂ）そのタイムスタンプ値に合わせたタイミングでデコーダへトランスポートパケットを転送できるため、デコーダ側にバッファーがなくても破綻なく安定にデコードと画面表示が行える。

ｃ）そのタイムスタンプ値を用いて個々のトランスポートパケットを識別・分別できるため、アクセス時の到着位置指定や編集時の範囲指定が容易となる。

２．セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置（ストリームオブジェクトの最後の位置）のセクタ内にのみパディングエリアを設定する。このため、効率良く情報記憶媒体上にストリームデータを記録できる。その結果、トランスポートパケット毎に分割されたストリームデータの録画記録時には情報記憶媒体の実行容量をほとんど低下させずに記録できる。

３．セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置（ストリームオブジェクトの最後の位置）のセクタ内にのみパディングエリアを設定する。このため、セクタサイズ（２０４８ｋバイト）よりも大きなサイズのトランスポートパケットを記録することができる。

４．この発明の実施の形態に従えば、各セクタ内でパケットヘッダ直後にタイムスタンプがくるとは限らない。従って、各ストリームブロック毎の時間情報の抽出方法として、この発明の実施の形態では、各ストリームブロック内の最初に配置されたタイムスタンプ（前のストリームブロックから跨って記録されたタイムスタンプを除く）の値を各ストリームブロック先頭時刻として取り扱うことにより、管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内のタイムマップ情報の作成を可能としている。そうすると、このタイムマップ情報を用いた所定のトランスポートパケットに対するアクセスが容易となる。

５．ＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイル内のストリームデータに対してセクタ単位での部分消去を可能にすると、ＤＶＤ−ＲＡＭなどの情報記憶媒体に対する記録最小単位（セクタ単位）でのＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルの部分開放が可能となる。その結果、ＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルから開放されたセクタに対して後でコンピュータデータを記録する等の有効利用が可能となる。

なお、上記内容と異なった部分消去単位として、例えばストリームブロック（ＳＯＢＵ）単位でしか部分消去（ＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルの部分開放）しない場合には、ユーザがセクタサイズ程度の細かい範囲での部分消去を指定しても部分消去範囲が狭いために実質的にＳＴＲＥＡＭ．ＶＲＯファイルあるいはＲＴＲ＿ＭＯＶ．ＶＲＯファイルの部分開放が生じない。その結果、ユーザが指定した細かい範囲での部分消去の指定領域を他のデータ記録に利用できず、実質的には情報記憶媒体上に情報が記録されない無駄領域が増える危険性がある。とはいえ、この発明はＳＯＢＵ単位での部分消去の利用を排除するものではない。

６．情報記憶媒体上にストリームデータを記録するファイル（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）とは別に、そのファイル内のストリームデータを管理する管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）を設け、その管理ファイル内にストリームデータの再生時の再生単位を表すセルに関する情報を記録したセル情報を記録する。そのセルに関する開始／終了位置情報をタイムスタンプに対応した時間情報で持たせることにより、タイムスタンプ値で代表されるトランスポートパケットが指定できる。このようにセルの開始／終了位置情報を時間情報で記述させることで、部分消去後の再生範囲を実質的にトランスポートパケット単位で細かく指定できる。

７．情報記憶媒体上にストリームデータを記録するファイル（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）とは別に、そのファイル内のストリームデータを管理する管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）を設け、さらにその管理ファイル内存在するストリームファイル情報内にストリームオブジェクト開始時間とストリームオブジェクト終了時間情報を持たせる。そして、部分消去後はＩピクチャ開始位置が記録されているトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト開始時間の値に設定し直し、あるいは部分消去境界位置を含むストリームデータの直後にくるＩピクチャ開始位置が記録されているトランスポートパケットの１個前のトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト終了時間の値に設定し直すことでＩピクチャ開始位置を境界位置としたストリームデータの部分消去（分割）が可能となる。その結果、
ａ）デコーダが常にＩピクチャ位置からデコード開始できるので、フレーム単位の任意位置から表示開始が可能となる。

ｂ）管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）の情報から常にＩピクチャ位置が分かり、Ｉピクチャ開始位置を区切りにストリームデータが分割されているので異なる複数のストリームオブジェクトを連続して再生する場合に、ストリームオブジェクトの切れ目（変わり目）で画面が乱れることなくシームレスに連続して映像再生が行える。

８．アイソクロナスパケットヘッダ３４３、３４４にＩピクチャ位置を示すフラグを設けることで、ＳＴＢ装置４１６から光ディスク装置４１５に対してストリームデータ（トランスポートパケット）の転送と同時にＩピクチャ位置情報をリアルタイムで通知できる。その結果、容易にストリームデータ記録ファイル（ＳＴＲＥＡＭ．ＶＲＯあるいはＲＴＲ＿ＭＯＶ．ＶＲＯ）内にＩピクチャ位置情報をリアルタイムで記録できるとともに、管理ファイル（ＳＴＲＥＡＭ．ＩＦＯあるいはＲＴＲ．ＩＦＯ）内にも容易にＩピクチャ位置情報を記録できる。

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

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

２０１…情報記憶媒体／情報記憶媒体（ＤＶＤ−ＲＡＭディスク等）；４１５…光ディスク装置；４１６…セットトップボックス装置。

Claims (4)

1. ストリームパケットを用いて、ＭＰＥＧのＩピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報記憶媒体であって、
   前記ストリームパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、
   １以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データ領域に記録される前記ストリームデータが形成され、
   前記管理情報の一部が、前記ストリームデータの特定部分を参照してその特定部分の再生を管理する第１再生管理情報を含むとともに、前記ストリームデータの前記特定部分を参照してその特定部分の再生を管理する第２再生管理情報を含み、
   前記Ｉピクチャ情報へのアクセス単位に関するデータをアクセスユニットデータとしたときに、このアクセスユニットデータが存在することを示す第２の情報が前記ストリームデータに関する管理情報の他部に含まれ、前記ストリームパケットが映像データに関する２ビットの著作権情報をそのパケット単位で含む情報記憶媒体。
2. ストリームパケットを用いてＭＰＥＧのＩピクチャ情報を含むストリームデータが記録されるデータ領域と前記ストリームデータに関する管理情報が記録される管理領域とを有する情報記憶媒体であって、前記ストリームパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データ領域に記録される前記ストリームデータが形成され、前記管理情報の一部が前記ストリームデータの特定部分を参照してその特定部分の再生を管理する第１再生管理情報を含むとともに前記ストリームデータの前記特定部分を参照してその特定部分の再生を管理する第２再生管理情報を含み、前記Ｉピクチャ情報へのアクセス単位に関するデータをアクセスユニットデータとしたときにこのアクセスユニットデータが存在することを示す第２の情報が前記ストリームデータに関する管理情報の他部に含まれ、前記ストリームパケットが映像データに関する２ビットの著作権情報をそのパケット単位で含むように構成された情報記憶媒体を用いる記録方法において、
   前記データ領域に前記ストリームデータを記録し、前記管理領域に前記管理情報を記録する記録方法。
3. ストリームパケットを用いてＭＰＥＧのＩピクチャ情報を含むストリームデータが記録されたデータ領域と前記ストリームデータに関する管理情報が記録された管理領域とを有する情報記憶媒体であって、前記ストリームパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データ領域に記録される前記ストリームデータが形成され、前記管理情報の一部が前記ストリームデータの特定部分を参照してその特定部分の再生を管理する第１再生管理情報を含むとともに前記ストリームデータの前記特定部分を参照してその特定部分の再生を管理する第２再生管理情報を含み、前記Ｉピクチャ情報へのアクセス単位に関するデータをアクセスユニットデータとしたときにこのアクセスユニットデータが存在することを示す第２の情報が前記ストリームデータに関する管理情報の他部に含まれ、前記ストリームパケットが映像データに関する２ビットの著作権情報をそのパケット単位で含む情報記憶媒体を用いる再生方法において、
   前記管理領域から前記管理情報を再生し、前記データ領域から前記ストリームデータを再生する再生方法。
4. ストリームパケットを用いてＭＰＥＧのＩピクチャ情報を含むストリームデータが記録されたデータ領域と前記ストリームデータに関する管理情報が記録された管理領域とを有する情報記憶媒体であって、前記ストリームパケットを第１データ単位として表現しストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現しストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより前記データ領域に記録される前記ストリームデータが形成され、前記管理情報の一部が前記ストリームデータの特定部分を参照してその特定部分の再生を管理する第１再生管理情報を含むとともに前記ストリームデータの前記特定部分を参照してその特定部分の再生を管理する第２再生管理情報を含み、前記Ｉピクチャ情報へのアクセス単位に関するデータをアクセスユニットデータとしたときにこのアクセスユニットデータが存在することを示す第２の情報が前記ストリームデータに関する管理情報の他部に含まれ、前記ストリームパケットが映像データに関する２ビットの著作権情報をそのパケット単位で含む情報記憶媒体を用いる再生装置において、
   前記管理領域から前記管理情報を再生する手段と、前記データ領域から前記ストリームデータを再生する手段を具備した再生装置。

Images