JP2002170337A - ストリームデータの記録方法およびそのデータ構造 - Google Patents

Abstract

(57)【要約】 【課題】ストリームデータを効率よく記録する。 【解決手段】ストリームデータ（ＳＯＢ）が記録される
データ領域と、ストリームデータに関する管理情報（Ｓ
ＴＲＩ）が記録される管理領域とを有する情報媒体が利
用される。複数のストリームパックのうち、第１のスト
リームパックが第１のストリームデータエリア（図５
（ｊ）左側）を含むストリームパケットを含み、前記複
数のストリームパックのうち、前記第１のストリームパ
ックに後続する第２のストリームパックが第２のストリ
ームデータエリア（図５（ｊ）右側）を含むストリーム
パケットを含む。前記ストリームデータ（ＳＯＢ）の一
部のデータ（図５（ｄ）の３２２）は、前記第１のスト
リームデータエリア（図５（ｊ）左側）と前記第２のス
トリームデータエリア（図５（ｊ）右側）とに跨って記
録できる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

【０００９】

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

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

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

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

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

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

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

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

【００１７】

【課題を解決するための手段】上記目的を達成するため
に、この発明の実施の形態に係る記録方法では、データ
パケットとこのデータパケットより大きなデータユニッ
ト（ＳＯＢＵ）とによりストリームデータ（ＳＯＢ）が
記録されるデータ領域（ＳＴＲＥＡＭ．ＶＲＯ／ＳＲ＿
ＴＲＡＮＳ．ＳＲＯ）と、前記ストリームデータ（ＳＯ
Ｂ）に関する管理情報（ＳＴＲＩ）が記録される管理領
域（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦ
Ｏ）とを有する情報媒体（図３の２０１）が用いられ
る。この媒体に情報記録を行なうときは、前記データパ
ケットを１以上含むストリームパックが複数用いられ、
これら複数のストリームパックに前記ストリームデータ
が分配されて記録される。ここで、前記複数のストリー
ムパックのうち、第１のストリームパックが第１のスト
リームデータエリア（図５（ｊ）左側）を含むストリー
ムパケットを含み、前記複数のストリームパックのう
ち、前記第１のストリームパックに後続する第２のスト
リームパックが第２のストリームデータエリア（図５
（ｊ）右側）を含むストリームパケットを含む。そし
て、前記ストリームデータ（ＳＯＢ）の一部のデータ
（図５（ｄ）の３２２）が前記第１のストリームデータ
エリア（図５（ｊ）左側）と前記第２のストリームデー
タエリア（図５（ｊ）右側）とに跨って記録される場合
において、前記一部のデータ（３２２）の前半部（図５
（ｅ）の３４６）は前記第１のストリームデータエリア
（図５（ｊ）左側）の末尾側に記録され、前記一部のデ
ータ（３２２）の後半部（図５（ｅ）の３４７）は前記
第２のストリームデータエリア（図５（ｊ）右側）の先
頭側に記録される。

【００１８】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００９４】その対応策としては、以下のものがある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１９５】図１０（ｄ）のスタッフィングバイトおよ
びアプリケーションパケット群は、図６（ｆ）で示した
ように、アプリケーションパケットエリアを構成してい
る。このアプリケーションパケットエリアの先頭に部分
アプリケーションパケットが記録される。その後に、ア
プリケーションタイムスタンプＡＴＳとアプリケーショ
ンパケットとのペアが複数ペア、シーケンシャルに記録
される。そして、図５（ｈ）で示したように、アプリケ
ーションパケットエリアの末尾に、部分アプリケーショ
ンパケット（または予約バイトのスタッフィングエリ
ア）が記録される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０３６０】ここで再びＳＯＢ＿ＧＩの内容説明に戻
る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０４６２】

【発明の効果】以上述べたように、この発明によれば、
ストリームデータを効率よく記録できるようになる。

【図面の簡単な説明】

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

【図２】この発明の一実施の形態に係るデータファイル
のディレクトリ構造を説明する図である。

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

【図４】この発明におけるストリームオブジェクト（Ｓ
ＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の
関係を説明する図である。

【図５】デジタル放送、ＩＥＥＥ１３９４、およびスト
リーマにおける映像データ転送形態の関係を説明する図
である。

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

【図７】ＭＰＥＧにおける映像情報圧縮方法とトランス
ポートパケットとの関係を説明する図である。

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

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

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

【図１１】この発明の一実施の形態に係るストリームデ
ータ記録再生システム（光ディスク装置／ストリーマ、
ＳＴＢ装置）の構成を説明する図である。

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

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

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

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

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

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

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

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

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

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｎ 5/92 Ｈ０４Ｎ 5/92 Ｈ (72)発明者 宇山 和之 埼玉県熊谷市美土里町２丁目199 ＬＭ301 号 (72)発明者 伊藤 雄司 東京都大田区中央５−22−１−302号 (72)発明者 菊地 伸一 神奈川県横浜市磯子区洋光台４−23−１ ショックビラヨーコーＶ−202号 Ｆターム(参考） 5C052 AA04 AB03 AB04 AB09 CC06 DD04 5C053 FA20 FA25 GB05 GB06 5D044 AB05 AB07 BC06 CC04 DE02 DE03 DE17 DE48 GK07 5D110 AA19 BB06 DA03 DA11 DA12 DA17 DB02 EA07

Claims (10)

【特許請求の範囲】
1. 【請求項１】タイムスタンプ付アプリケーションパケッ
   トを１以上持つアプリケーションパケットエリアを含む
   ストリームパックを用いてストリームデータが記録され
   るデータ領域と、前記ストリームデータに関する管理情
   報が記録される管理領域とを有する情報媒体に情報記録
   を行なう方法において、 複数の前記ストリームパック内の前記アプリケーション
   パケットエリアに前記ストリームデータが分配されて記
   録され、 上記記録の結果、前記ストリームパック１つ分以上の余
   白が残る場合は、この余白部分埋めるスタッフィングデ
   ータが記録されるように構成したことを特徴とする情報
   記録方法。
2. 【請求項２】タイムスタンプ付アプリケーションパケッ
   トを１以上持つアプリケーションパケットエリアを含む
   ストリームパックを用いてストリームデータが記録され
   るデータ領域と、前記ストリームデータに関する管理情
   報が記録される管理領域とを有する情報媒体に情報記録
   を行なう方法において、 複数の前記ストリームパック内の前記アプリケーション
   パケットエリアに前記ストリームデータが分配されて記
   録され、 上記記録の結果、前記ストリームデータを実際に含む最
   後の前記ストリームパックの末尾と前記ストリームデー
   タが記録される領域の末尾との間に前記ストリームパッ
   ク１つ分以上の余白がある場合は、この余白部分埋める
   スタッフィングパケットが記録されるように構成したこ
   とを特徴とする情報記録方法。
3. 【請求項３】データパケットとこのデータパケットより
   大きなデータユニットとによりストリームデータが記録
   されるデータ領域と、前記ストリームデータに関する管
   理情報が記録される管理領域とを有する情報媒体に情報
   記録を行なう方法において、 前記データパケットを１以上含むストリームパックが複
   数用いられ、これら複数のストリームパックに前記スト
   リームデータが分配されて記録され、 前記複数のストリームパックのうち、第１のストリーム
   パックが第１のストリームデータエリアを含むストリー
   ムパケットを含み、 前記複数のストリームパックのうち、前記第１のストリ
   ームパックに後続する第２のストリームパックが第２の
   ストリームデータエリアを含むストリームパケットを含
   み、 前記ストリームデータの一部のデータが前記第１のスト
   リームデータエリアと前記第２のストリームデータエリ
   アとに跨って記録される場合において、前記一部のデー
   タの前半部が前記第１のストリームデータエリアの末尾
   側に記録され、前記一部のデータの後半部が前記第２の
   ストリームデータエリアの先頭側に記録されるように構
   成したことを特徴とする情報記録方法。
4. 【請求項４】タイムスタンプ付アプリケーションパケッ
   トを１以上持つアプリケーションパケットエリアを含む
   ストリームパックを用いてストリームデータが記録され
   るデータ領域と、前記ストリームデータに関する管理情
   報が記録される管理領域とを有する情報媒体への情報記
   録に用いられるデータ構造において、 複数の前記ストリームパック内の前記アプリケーション
   パケットエリアに前記ストリームデータが分配されて記
   録されるように構成され、 上記記録の結果、前記ストリームパック１つ分以上の余
   白が残る場合は、この余白部分埋めるスタッフィングデ
   ータが記録されるように構成されたことを特徴とするデ
   ータ構造。
5. 【請求項５】タイムスタンプ付アプリケーションパケッ
   トを１以上持つアプリケーションパケットエリアを含む
   ストリームパックを用いてストリームデータが記録され
   るデータ領域と、前記ストリームデータに関する管理情
   報が記録される管理領域とを有する情報媒体への情報記
   録に用いられるデータ構造において、 複数の前記ストリームパック内の前記アプリケーション
   パケットエリアに前記ストリームデータが分配されて記
   録されるように構成され、 上記記録の結果、前記ストリームデータを実際に含む最
   後の前記ストリームパックの末尾と前記ストリームデー
   タが記録される領域の末尾との間に前記ストリームパッ
   ク１つ分以上の余白がある場合は、この余白部分埋める
   スタッフィングパケットが記録されるように構成された
   ことを特徴とするデータ構造。
6. 【請求項６】データパケットとこのデータパケットより
   大きなデータユニットとによりストリームデータが記録
   されるデータ領域と、前記ストリームデータに関する管
   理情報が記録される管理領域とを有する情報媒体への情
   報記録に用いられるデータ構造において、 前記データパケットを１以上含むストリームパックが複
   数用いられ、これら複数のストリームパックに前記スト
   リームデータが分配されて記録されるように構成され、 前記複数のストリームパックのうち、第１のストリーム
   パックが第１のストリームデータエリアを含むストリー
   ムパケットを含むように構成され、 前記複数のストリームパックのうち、前記第１のストリ
   ームパックに後続する第２のストリームパックが第２の
   ストリームデータエリアを含むストリームパケットとを
   含むように構成され、 前記ストリームデータの一部のデータが前記第１のスト
   リームデータエリアと前記第２のストリームデータエリ
   アとに跨って記録される場合において、前記一部のデー
   タの前半部が前記第１のストリームデータエリアの末尾
   側に記録され、前記一部のデータの後半部が前記第２の
   ストリームデータエリアの先頭側に記録されるように構
   成されたことを特徴とするデータ構造。
7. 【請求項７】ストリームデータが記録されるデータ領域
   と、前記ストリームデータに関する管理情報が記録され
   る管理領域とを有する情報媒体への情報記録に用いられ
   るデータ構造において、 前記管理情報が前記ストリームデータに対応するファイ
   ル情報を管理する情報テーブルを含むように構成され、 前記情報テーブルが前記ストリームデータの記録時間に
   関する情報を含むように構成されたことを特徴とするデ
   ータ構造。
8. 【請求項８】 前記情報テーブルが、前記ストリームデ
   ータの開始時間に関する情報および／または前記ストリ
   ームデータの終了時間に関する情報を含むように構成さ
   れたことを特徴とする請求項７に記載のデータ構造。
9. 【請求項９】 請求項４ないし請求項８のいずれか１項
   に記載のデータ構造を用いて情報記録あるいは記録情報
   の再生を行うように構成されたことを特徴とする情報媒
   体。
10. 【請求項１０】 請求項９に記載の媒体を用いて情報記
    録あるいは記録情報の再生を行うように構成されたこと
    を特徴とする装置あるいはシステム。