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

Abstract

【課題】ランダムアクセス可能なＤＶＤ−ＲＡＭを利用したストリーマを構築する上で、ＴＳストームデータの効率の良い管理を可能とする。
【解決手段】ＤＶＤ録再システムにおいては、セットトップボックス部ＳＴＢ８３では、複数のトランスポートパケットからなるＭＰＥＧトランスポートストリームを受信し、トランスポートパケットに含まれる管理情報に所定の項目があるか否かを示すサポート情報がフォーマッタ部９０で取りだされる。管理領域およびデータ領域を有する記録媒体にデータを記録するドライブ部５１は、このサポート情報を前記管理領域に記録している。
【選択図】 図１４

Description

この発明は、デジタルビデオのデータストリームを記録するシステムの改良に関する。とくに、デジタル放送されるＭＰＥＧトランスポートストリームを効率よく記録できるシステムに関する。さらには、ＭＰＥＧトランスポートストリームのサポート情報を管理領域に記録するシステムに関する。

近年、ＴＶ放送はデジタル放送の時代に突入しつつあり、そのために、デジタルＴＶ放送のストリーマ（デジタルデータをそのままの形で保存する装置）の必要性が要望されている。

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

このデジタル放送データを記録するストリーマとして、たとえばＤ−ＶＨＳ（デジタルＶＨＳ）がある（特許文献１のディジタルＶＴＲ参照）。

デジタルＴＶ放送は、放送局より通信衛星を通して放送される。放送されたデジタルデータは、各家庭に設置されたセットトップボックス（Set Top Box；以下、ＳＴＢと略記する）で受信され、ＴＶモニタ上に表示される。このＳＴＢは、放送局から配給されるキーコードを元に、スクランブルされたデジタルデータを解除して再生する装置である。

データがスクランブルされる理由は、放送局と契約していないユーザにより不正に受信され、盗視聴されることを防ぐためである。

受信されたデータがそのまま再生される場合には、ＳＴＢ内で、受信されたデータのスクランブルが解除される。そして、ＳＴＢ内で、スクランブル解除されたデータがＭＰＥＧデコーダでデコードされ、ビデオエンコーダでＴＶ信号に変換されて、ＴＶモニタ上に表示される。

放送データを録画する場合には、ＩＥＥＥ１３９４デジタル・インターフェースを介して、チューナで受信されたデジタルデータがＤ−ＶＨＳレコーダに記録される。

ここで、ＩＥＥＥ１３９４は標準的なインターフェースの規格で、コマンドの授受、データの送受信を実行する規格である。

また、録画された放送データを再生する場合には、Ｄ−ＶＨＳレコーダから記録データが読み取られ、ＳＴＢ内のデータ伸張部に送られて、再生される。

ここで、Ｄ−ＶＨＳレコーダに記録されるデジタルデータは、一般に次のような構造を有している。

すなわち、記録されるデジタルデータは、６トラックが１ＥＣＣブロックとして取り扱われ、主データ領域の同期ブロック（Ｓｙｎｃ Ｂｌｏｃｋ）内に、主データとして記録される。この場合、トランスポートストリーム（ＴＳ）パケットにはヘッダが付加されて記録される。

このようなＤ−ＶＨＳストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、このテープには、複数の番組が多重化されて記録されることになる。

従って、最初から再生する場合でも途中から再生する場合でも、再生時には、そのまま全てのデータが送り出される。ＳＴＢでは、送り出されたデータから希望の番組のみが選択されて再生されることとなる。

このようなシステムでは、記録にテープメディアを使用するために、ランダムアクセス性能が極めて悪い。そのため、ある番組中においてユーザが所望する箇所に素早くジャンプしてその再生場面を再生したいと思ってもそれが実行困難である。

一方、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアにおいても、ストリーマの記録については、問題がある。このようなＤＶＤシステムでは、ランダムアクセス或いは特殊再生などを考慮すると、必然的に、管理データを放送データと共に記録することが要求される。

このようなＤＶＤシステムでは、ＤＶＤビデオのフォーマットに準じて、データが管理され、またフォーマットされることも必要とされる。

しかしながら、ＤＶＤビデオでは、衛星放送を想定してフォーマットが定められていないことから、そのままでは、特殊再生などに対応できない問題がある。

たとえば特願平１０−０４０８７６では、ＤＶＤビデオフォーマットを元に、家庭用録再機を想定したフォーマットの提案がされている。しかしながら、このフォーマットでも、デジタル放送に関しては、全く考慮されていないのが現状である。

特開平９−２４７６１９号公報

以上のように、デジタルＴＶ放送対応のストリーマシステムに於いて、ランダムアクセスの可能なＤＶＤ−ＲＡＭ、すなわち、リード／ライト（Ｒ／Ｗ）ディスクを利用したストリーマを構築する上でＴＳストリームデータを効率の良く管理できない問題がある。

この発明の目的は、ランダムアクセス可能なメディア（ＤＶＤ−ＲＡＭ等）を利用したストリーマを構築するにあたって、トランスポートパケットを効率よく記録できるシステムを提供することである。

また、この発明の他の目的は、ＤＶＤビデオフォーマットにストリーマ機能を付加することである。

この発明のさらに他の目的は、デジタルＴＶ放送を想定した新たなフォーマットを提案することにより、デジタルＴＶ放送データの効率の良い管理を可能とすることである。

この発明の一実施の形態では、ストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ光ディスクにおいて、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成される。ここで、前記ストリームデータはＭＰＥＧのＩピクチャ情報を含んでおり、このＩピクチャ情報へのアクセス単位（ＡＵ）に関するデータをアクセスユニットデータ（ＡＵＤ）としたときに、このアクセスユニットデータが存在するか否かを示す情報（ＡＵＤ＿ＦＬＡＧＳ）が前記管理エリアに記録される。

デジタルＴＶ放送等のストリームデータを効率良く管理できる。

ＭＰＥＧにおけるＴＳストリームのフォーマットを示す説明図。 この発明のＤＶＤ記録再生システムで記録再生されるオブジェクトセットのフォーマットを示す説明図。 図２に示すＴＳパックのフォーマット構造を示す説明図。 図３に示したパック構造に最適なＶＯＢＵの構造を示す説明図。 図３に示すＴＳパックの変形例に係る構造を示す説明図。 再生対象としてのビデオオブジェクトセット（図２）を管理するための管理情報のフォーマットの一例を示す説明図。 図６に示したＰＧＣＩの記述内容を示すテーブル図。 図６に示したＣ＿ＰＢＩの記述内容を示すテーブル図。 再生対象としてのビデオオブジェクト（図２）を管理するための管理情報のフォーマットの他の例を示す説明図。 図９に示されたＶＯＢＵＩの記述内容を示すテーブル図。 図６に示されたＶＯＢＵ或いはセルのフォーマット構造の例を示す説明図。 図６に示されたセル或いはＰＧＣのフォーマット構造の例を示す説明図。 図６に示されたセルフォーマット構造を利用した編集作業を説明するための図。 この発明の一実施の形態に係るＤＶＤ記録再生システムの全体を示すブロック図。 図９に示されたフォーマット構造における録画処理を説明するためのフローチャート図。 図９に示されたフォーマット構造における録画処理を説明するためのフローチャート図。 図９に示されたフォーマット構造における再生処理を説明するためのフローチャート図。 図９に示されたフォーマット構造における再生処理を説明するためのフローチャート図。 図９に示されたフォーマット構造におけるＦＦ処理を説明するためのフローチャート図。 図９に示されたフォーマット構造におけるＦＦ処理を説明するためのフローチャート図。 図９に示されたフォーマット構造におけるＦＦ処理を説明するためのフローチャート図。 図２０および図２１に示したフローにおける割り込み処理について説明するフローチャート図。 図２０に示されたフォーマット構造におけるＰＡＴ処理を説明するためのフローチャート図。 ストリームデータ（図１のＭＰＥＧ２トランスポートストリームに対応）のデータ構造を説明する図。 図２４に示されたストリームブロックヘッダの内部構造を説明する図。 図２４に示されたセクタデータヘッダの内部構造を説明する図。 ストリームオブジェクト（ＳＯＢ）に対するＭＰＥＧ規格上の制約を説明する図。 ＤＶＤストリーマ情報（ＳＴＲＩ）内のナビゲーションデータ（図９の制御情報２５に対応）の構造を説明する図。 図２８に示されたストリームファイル情報テーブル（ＳＦＩＴ）の構造を説明する図。 図２９に示されたストリームファイル情報（ＳＦＩ）の構造を説明する図。 図３０に示されたストリームファイル一般情報（ＳＦ＿ＧＩ）の内容を説明する図。 図３０に示されたストリームオブジェクト情報（ＳＯＢＩ＃）の構造を説明する図。 図３２に示されたストリームオブジェクト情報一般情報（ＳＯＢＩ＿ＧＩ）の内容を説明する図。 図３２に示されたアクセスユニットデータ（ＡＵＤ）の構造を説明する図。 図３４に示されたアクセスユニット一般情報（ＡＵ＿ＧＩ）の内容を説明する図。 アクセスユニット開始マップ（ＡＵＳＭ；図８、図１０参照）とストリームオブジェクトユニット（ＳＯＢＵ；図２、図４、図１１参照）との対応関係を例示する図。 アクセスユニット開始マップ（ＡＵＳＭ；図８、図１０参照）およびアクセスユニット終了マップ（ＡＵＥＭ；図８、図１０参照）とストリームオブジェクトユニット（ＳＯＢＵ；図２、図４、図１１参照）との対応関係を例示する図。 ストリームパック（図２〜図４のＴＳパックに対応）の構造を説明する図。 図３８に示されるストリームＰＥＳパケット内のストリームデータエリアの構造を説明する図。 図３９に示されたストリームデータエリア先頭のアプリケーションヘッダの内容を説明する図。

以下図面を参照してこの発明の一実施の形態に係るＤＶＤ録再器並びにその書き込み可能な光ディスクのフォーマットについて説明する。

始めにフォーマットの用語について簡単に説明する。光ディスクには、通常のファイル形式でデータが保存されている。タイトルは、たとえば映画の一本分に相当し、一枚のディスクに、このタイトルが複数収納されている。このタイトルが集まったものをタイトルセットと称し、このタイトルセットは、複数のファイルで構成されている。また、１枚のディスクには、このディスクを管理するための情報としてビデオマネージャ（Ｖｉｄｅｏ Ｍａｎａｇｅｒ；以降ＶＭＧと称する）と称するファイルが存在する。

さらに、タイトルセットでは、このタイトルセットを管理するための情報が、ビデオタイトルセット情報（Ｖｉｄｅｏ Ｔｉｔｌｅ Ｓｅｔ Ｉｎｆｏｒｍａｔｉｏｎ、以降ＶＴＳＩと略記する）の管理情報ファイルとビデオデータで構成されているビデオファイルとＶＴＳＩのバックアップファイルとで構成されている。

前記ビデオファイルは、階層構造となっており、１つのファイルは複数のプログラムチェーンで構成され、１つのプログラムチェーンは、複数のプログラムで構成されており、１つのプログラムは、複数のセルで構成され、１つのセルは、複数のビデオオブジェクトユニット（以降ＶＯＢＵと略記する）で構成されている。また、ＶＯＢＵは、複数の様々な種類のデータからなるパックによって構成されている。パックは１つ以上のパケットとパックヘッダで構成されている。パックは、データ転送処理を行う最小単位となっている。さらに、論理上の処理を行う最小単位はセル単位で、論理上の処理はこのセル単位で行われる。

次に、トランスポート（ＴＳ）ストリームについて説明する。一般に、デジタルＴＶ放送などやインターネットなどの有線を使用した放送などの圧縮動画を放送（配信）する方式おいては、共通の基本フォーマットであるＴＳストリームがＭＰＥＧ２の規格として定められている。

このＴＳストリームは、図１（ａ）に示すように多数のＴＳパケット３８から構成され、各ＴＳパケット３８は、図１（ｂ）から図１（ｄ）に示す構造を有し、図１（ｂ）に示すようにパケットの管理データ部分４１およびペイロード４２とから構成される。ペイロード４２には、再生されるべき対象のデータがスクランブルされた状態で格納されている。

ペイロード４２に格納される再生対象としては、ＭＰＥＧビデオデータ、Ｄｏｌｂｙ ＡＣ３ オーディオデータ或いはＭＰＥＧオーディオデータ等があり、また、直接、再生対象以外の情報として、再生する上で必要なプログラムアソシエーションテーブル（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ；以下ＰＡＴと略記する）、プログラムマップテーブル（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ；以下ＰＭＴと略記する）等の情報、さらに、電子番組情報（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ；以下ＥＰＧと略記する）等がある。

ＰＡＴには、番組毎のＰＭＴのパケット識別情報（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ；以下ＰＩＤと略記する）が含まれており、さらに、ＰＭＴには、ビデオデータ或いはオーディオデータ等のＰＩＤが記録されている。

これにより、ＳＴＢ部の通常の再生手順としては、ＥＰＧ情報により、ユーザが番組を決定すると、目的の番組の開始時間に、ＰＡＴを読み込み、そのデータを基に希望の番組のＰＭＴのＰＩＤを決定し、目的のＰＭＴを読み出し、そこに含まれる再生すべきビデオ、オーディオパケットのＰＩＤを決定し、ビデオ、オーディオデータをＰＩＤに従って、切り出されて再生がなされる。ここで、ＰＡＴは、途中再生にも使用するために、数１００ｍｓ毎に送信されている。

これらＴＳストリームのデータを、ＤＶＤーＲＷ（リード／ライト）ディスク等のディスクメディアに記録する場合には、これらのデータをそのまま、デジタルデータとして記録することが好ましい。ただし、現在、ＤＶＤ−ＲＡＭの最高ビットレートが１０．０８Ｍｂｐｓであるため、全チャンネルを多重化された衛星放送（２０Ｍｂｐｓ以上）そのものを記録することはできない。そのため、記録する場合には、１つの番組を選んで、記録する必要がある。

さらに、ディスクメディアに記録すると、ユーザが希望の番組の希望の時間より再生を開始したいとか、早送りを行いたいなどの希望を満たすためには、記録したデータを管理するためのデータが必要となる。しかしながら、再生するデータ自身には、スクランブルが掛かっているため、再生するデータ自身から、その管理データを作成することは困難である。

そのため、ＴＳストリームパケット内のコントロールデータであるパケットヘッダ内のデータや、ＴＳストリームのＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）データであるＰＡＴパケット、或いは、ＰＭＴパケットのデータを利用して、管理データを作成することが好ましい。

ここで注意すべきは、衛星放送の種類などにより、これらパケットヘッダの内容のなかで、サポートされていない情報がある場合があり、さらに、ＰＡＴおよびＰＭＴさえも使用していない場合があることである。そのため、前記のような方法でいきなり管理データを作成しようとすると、衛星放送毎に、管理データが作れずに、記録できない場合がある。

そこで、録画時に、管理情報内に衛星放送の使用するパケットヘッダの情報、ＰＡＴ或いはＰＭＴがあるかどうかを示す情報を保存し、サポートされている情報に従って管理データを作成し、再生時には、そのサポート情報によりサービス内容を変更し、可能なサービスのみを提供するようにすることが好ましい。

まず、サポート情報を検出する方法としては、次の２通りの方法がある。

第１の方法には、サポート情報をＳＴＢ部より受け取る方法である。ＳＴＢ部は、受信する衛星放送毎に異なり、専用機となっている。そのため、サポートに関する情報を前もって（ＳＴＢの出荷時に）把握しているはずである。そこで、録画開始時に、ＳＴＢ部からそのサポート情報を取り込む。

第２の方法は、録画中に、ＳＴＢ部より、ＴＳストリームストリームデータを受け取った際に、使用する各データをチェックし、アクティブである場合に、その情報がサポートされていると判定し、サポート情報を蓄積すると共に、そのサポートされた情報を基に管理データを作成し、記録終了時に、蓄積したサポート情報を管理データとして光ディスクの管理領域に記録することである。

次に、管理データにサポート情報が含まれるフォーマットについて説明する。第１の実例は、既にフォーマットの規格が統一化されたＤＶＤ―ビデオのフォーマットに準拠するデータを管理する管理データについて始めに説明する。

現ＤＶＤ−ビデオでは、衛星放送などを想定してフォーマットされていない。従って、衛星放送を録画してその後、録画データを特殊再生する場合には、現状では、対応できないものである。従って、現ＤＶＤ−ビデオに準拠して録再の規格を提唱する場合には、次のようなフォーマットが最適なものとなる。

現ＤＶＤ−ビデオでは、再生対象としてのビデオオブジェクトセット３０（ＶＯＢＳ）は、図２（ａ）〜（ｄ）に示すような構造を有している。

すなわち、図２（ａ）に示されるＶＯＢＳ３０は、図２（ｂ）に示すように１または、多数のビデオオブジェクト（ＶＯＢ）３１の集合に定められ、ＶＯＢ３１は、また、図２（ｃ）に示すように１または、多数のセル（Ｃｅｌｌ）３２の集合に定められている。さらに、このセル３２は、図２（ｄ）に示すように１または、多数のビデオオブジェクトユニット（ＶＯＢＵ）３３の集合に定められている。そして、ＶＯＢＵ３３が図２（ｅ）に示すように１または、多数のＴＳパック３４で構成される。

なお、ストリーマでは、上記ＶＯＢに対応するものとしてストリーマオブジェクト（ＳＯＢ）が定義され、上記ＶＯＢＵに対応するものとしてストリーマオブジェクトユニット（ＳＯＢＵ）が定義されている。

以下の説明において、ＶＯＢあるいはＶＯＢＵに関する説明は、適宜ＳＯＢあるいはＳＯＢＵに置き換えて解釈できる。

ここで、ＶＯＢＵ３３の構造に関しては、２種類のフォーマット方式を提唱することができる。

第１の方式では、１ＶＯＢＵ３３が、トランスポートストリーム（ＴＳストリーム）を記録した１または複数のＴＳパック３４で構成される。図３（ａ）に示す１ＴＳパック３４は、図３（ｂ）に示すようにパックヘッダ３５、パケットヘッダ３６、サブストリームＩＤ３７およびトランスポートパケット（ＴＳパケット）３８で構成されている。１ＴＳパック３４は、そのサイズが２０４８バイトに定められ、２０４８バイトに満たない場合には、パディングパケット３９が挿入されてそのサイズが調整される。

ＴＳパック３８は、１０個のＴＳパケットで構成され、パケットヘッダ３６は、ＭＰＥＧ２におけるプライベートストリームである旨を示す０ｘｂｄが記述されるストリームＩＤを含み、また、パケット内のデータがトランスポートストリームである旨を特定するサブストリームＩＤには、０ｘｆ０が記述される。

なお、各ＴＳパケットの先頭には、図３（ｂ）に示すように、タイムスタンプ（ＡＴＳ）を配置することができる。

また、第２の方式では、図３（ｃ）に示すように図３（ｂ）のパケット構造においてサブストリームＩＤ３７の後に２バイトのパケットアクセスポインタ４０が設けられる構造を有している。そのパケットアクセスポインタ４０は、パック３４内にある最初のパケット３８の先頭アドレスを示している。

例えば、図３（ｃ）においては、パック３４内の最初のパケット３８は、パケットアクセスポインタ４０の直後にあるため相対アドレスで示せばアドレスは０となる。この図３（ｃ）に示すパック３４では、最終パケット３９は、他のパケット３８が１８８バイトであるに対して１４２バイトしかないためその残余の４６バイトが図３（ｄ）に示す次のパック３４に格納される。

図３（ｄ）に示す次のパック３４では、パケットアクセスポインタ４０の直後には、残余の４６バイトがあるためにその残余の４６バイトに続いて最終パケット３９が位置されることとなる。従って、最終パケット３９のアドレスを示す０ｘ２ｅが次のパック３４のパケットアクセスポインタ４０に記述される。

このパケットアクセスポインタ４０により、第一の方式では、パディングで未使用であった部分も、パケットデータの格納領域として利用できるようになる。このとき、パケットアクセスポインタが０ｘｆｆｆｆの場合には、１パック内にパケットの先頭が存在しない場合を意味している。

ただし、この場合、ＶＯＢＵ３３の先頭のパックは、図３（ｃ）に示す例のように必ずパケットの先頭がパケットアクセスポインタ４０後尾にアラインされるものとする。これにより、ＶＯＢＵ単位でパケットを管理でき、しかも、パケットのサイズが１パックに入りきらない場合に対応できることとなる。

なお、図３（ｃ）および図３（ｄ）に示されるトランスポートストリームパケット（ＴＳパケット）の一部は、以下の場合に該当する。

すなわち、ＴＳパケットの記録において、１パケットが２セクタに跨って記録される場合に、第１のセクタに記録されるものおよび第１のセクタに記録されるものそれぞれが、ＴＳパケットの一部に該当する。

このようにすると、１パケットが２セクタに跨って記録される場合にパディングデータを挿入する必要がないので、その分高密度記録できる。

その際、パケットヘッダに、「各セクタの最初に来るＴＳ開始位置が基準位置から何バイト目か」の位置情報を記録しておくことができる。ここで、基準位置としては、たとえばパケットヘッダの位置、あるいはＴＳパケットの先頭位置、またはＴＳパケットの終了位置、若しくは連続するＴＳパケットの隣接境界位置を用いることができる。

基準位置としてＴＳパケットの先頭位置を用いる場合は、図３（ｃ）のパケットアクセスポインタ＝０を、上記位置情報として用いることができる。

また、基準位置としてＴＳパケットの終了位置（または隣接境界位置）を用いる場合は、図３（ｄ）のパケットアクセスポインタ＝０ｘ２ｅを、上記位置情報として用いることができる。

既に説明した第２の方式の例を図４を参照してより詳細に説明する。図４は、ＶＯＢＵ（またはＳＯＢＵ）の構造並びにＴＳパケットの構造の詳細を示している。図４（ａ）に示すＶＯＢＵ（ＳＯＢＵ）３３は、整数個のＴＳパック３４から構成され、ＶＯＢＵ（ＳＯＢＵ）３３内の先頭のＴＳパック３４は、図４（ｃ）に示す構造を有している。

すなわち、常にＴＳパック３４内のパケットアクセスポインタ４０の次には、ＴＳパケット３８の先頭部分がアラインされ、パケットアクセスポインタ４０の相対アドレスは、ゼロとなる。従って、ＶＯＢＵ（ＳＯＢＵ）３３をアクセスしてそのパケットと取り出せば常にその先頭がＴＳパケット３８の先頭に一致し、ＴＳパケット３８を切り離して即座に転送可能となる。このＶＯＢＵ（ＳＯＢＵ）３３内の先頭のＴＳパック３４に続いてＴＳパケット３４が配置されるが、２０４８バイトの１パックに格納されないＴＳパケット３８の残余の部分は、図４（ｃ）に示すように次のＴＳパック３４のパケット３８に収納される。

このように次々にＶＯＢＵ（ＳＯＢＵ）３３内には、ＴＳパック３４が配置される。が、そのＶＯＢＵ（ＳＯＢＵ）３３内の最後のＴＳパック３４は、図５（ｃ）に示すように、他のＴＳパック３４と異なり、そのパック内の最後の部分に１ＴＳパケット３８が入りきらないことがある。

このような場合には、その最後の部分に、パッディングパケット３９を適宜挿入することができる。このパッディングパケットを挿入することによって、次のＶＯＢＵ（ＳＯＢＵ）３３内の先頭ＴＳパック３４は、ＴＳパケット３８の先頭から始まるパケットのデータ部を有することとなる。

なお、上記パディングなしで対処する方法（ＴＳパケットの記録において、１パケットが２セクタに跨って記録される場合）もあり、それについては前述した。

図３並びに図４に示した例では、パケットアクセスポインタ４０でそのパック３４内の最初のＴＳパケット３８のアドレスが指定され、このパケットアクセスポインタ４０でそのパック３４が指定された際にそのパック３４内で最初に取り出されるＴＳパケット３８を特定することができる。

このパケットアクセスポインタ４０に代えて図５に示す続きパケットフラグで次のＴＳパック３４の構造を特定するようにしても良い。

すなわち、図５（ａ）に示すようにＴＳパック３４内には、パケットヘッダ３６に続いてＴＳパケットである旨を特定するサブストリームＩＤ３６が設けられ、このサブストリームＩＤに続いて続きパケットフラグ４１が設けられている。この続きパケットフラグ４１は、これが含まれるＴＳパック３４に続くＴＳパック３４には、ＴＳパケット３９の一部が収納されている否かを示している。

すなわち、続きパケットフラグ４１が１であれば、そのＴＳパック３４の最後には、ＴＳパケット３９の一部が収納され、そのＴＳパケット３９の残余が次のＴＳパック３４の続きパケットフラグ４１に続いて配置されている。

ＴＳパック３４内の最後にＴＳパック３９がアラインされて配置され、残余が次のパック３９に格納されない場合には、続きパケットフラグ４１は、ゼロとなる。このことは、続きパケットフラグ４１がゼロであるＴＳパケット３９を獲得すれば、続きパケットフラグ４１に続くＴＳパケット３９を再生すればスムーズな再生処理が可能となる。

次に、上述のようなデータ構造における管理データの構造について説明する。

管理データは、光ディスクの内周側のリードイン領域に続く管理領域に記録され、この管理領域は、図６（ａ）に示すようにビデオタイトルセット情報（ＶＴＳＩ）あるいはストリーマ制御情報（ＳＴＲ＿ＶＭＧＩ）のテーブルを含む。このＳＴＲ＿ＶＭＧＩは、ストリーマの管理情報（ＳＴＲＩ）に含まれている。このＳＴＲＩはＶＴＳＩに対応した機能を持っている。

このＶＴＳＩ（ＳＴＲ＿ＶＭＧＩ）は、図６（ａ）に示すように、ＶＴＳＩ（ＳＴＲ＿ＶＭＧＩ）に関する管理情報が記述されたＶＴＳＩの管理テーブル（ＶＴＳＩ＿ＭＡＴ）；ＶＴＳ（ビデオタイトルセット）あるいはストリーム内のプレイリストをサーチするためのサーチポインタが記述されたＶＴＳタイトルサーチポインタテーブル（ＶＴＳ＿ＴＴ＿ＳＲＰＴ）あるいはプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）；セルの再生順序が規定されているプログラムチェーンを定めるＶＴＳプログラムチェーン情報テーブル（ＶＴＳ＿ＰＧＣＩＴ）あるいはユーザが定義したプログラムチェーン情報のテーブル（ＵＤ＿ＰＧＣＩＴ）；ＶＴＳメニューのためのプログラムチェーン情報ユニットテーブル（ＶＴＳＭ＿ＰＧＣＩ＿ＵＴ）；ＶＴＳタイムマップテーブル（ＶＴＳ＿ＴＭＡＰＴ）；ＶＴＳメニューのためのセルアドレステーブル（ＶＴＳＭ＿Ｃ＿ＡＤＴ）；ＶＴＳメニューのためのＶＯＢＵアドレスマップテーブル（ＶＴＳＭ＿ＶＯＢＵ＿ＡＤＭＡＰ）；ＶＴＳのセルアドレステーブル（ＶＴＳ＿Ｃ＿ＡＤＴ）およびＶＴＳのＶＯＢＵアドレスマップテーブル（ＶＴＳ＿ＶＯＢＵ＿ＡＤＭＡＰ）から構成されている。

なお、上記ＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報（ＵＤ＿ＰＧＣＩ）は、ユーザにより定義されたプログラムパーツのシーケンスを定義している。また、上記プレイリストは、プログラムパーツの再生シーケンスをユーザが自由に定めたものである。

ＶＴＳ＿ＰＧＣＩＴ（ＵＤ＿ＰＧＣＩＴ）は、図６（ｂ）に示すように、ＶＴＳ＿ＰＧＣＩＴの情報（ＶＴＳ＿ＰＧＣＩＴＩ）（またはＵＤ＿ＰＧＣＩＴＩ）、再生順序に配置された各プログラムチェーンをサーチするためのＶＴＳプログラムチェーンサーチポインタ（ＶＴＳ＿ＰＧＣ＿ＳＲＰ＃ｎ）（またはＵＤ＿ＰＧＣ＿ＳＲＰ＃ｎ）およびこのサーチポインタで指定される各ＶＴＳプログラムチェーンの情報（ＶＴＳ＿ＰＧＣＩ＃ｎ）（またはＵＤ＿ＰＧＣＩ＃ｎ）から構成されている。

ＶＴＳ＿ＰＧＣＩ＃ｎ（またはＵＤ＿ＰＧＣＩ＃ｎ）は、図６（ｃ）に示すようにプログラムチェーン（ＰＧＣ）の一般情報（ＰＧＣ＿ＧＩ）あるいはストリームセル一般情報（ＳＣ＿ＧＩ）；ＰＧＣプログラムマップ（ＰＧＣ＿ＰＧＭＡＰ）あるいはプログラム情報（ＰＧＩ＃ｍ）；セルの再生に関する情報が記述されたセル再生情報テーブル（Ｃ＿ＰＢＩＴ）あるいはストリームセル情報（ＳＣＩ＃ｎ）；セルの位置情報、すなわち、アドレス情報が記述されたセル位置情報テーブル（Ｃ＿ＰＯＳＩＴ）あるいはストリームセル情報サーチポインタ（ＳＣＩ＿ＳＲＰ＃ｎ）から構成されている。Ｃ＿ＰＢＩＴ（ＳＣＩ＃ｎ）は、図６（ｄ）に示すように、セルの再生順に配置された多数のセルの再生情報（Ｃ＿ＰＢＩ＃ｊ）あるいはストリームセルのエントリポイント情報（ＳＣ＿ＥＰＩ＃ｎ）から構成されている。

ＰＧＣ一般情報（ＰＧＣ＿ＧＩ）は、図７（ａ）に示すように構成できる。すなわち、プログラム数およびセル数等のＰＧＣの内容（ＰＧＣ＿ＣＮＴ）が記述され；１ＰＧＣの記録時間を記述したＰＧＣ記録時間（ＰＧＣ＿ＴＲＳ＿ＴＭ： ＰＧＣ Ｔｒａｎｓｐｏｒｔ Ｔｉｍｅ）が記述され；サポート情報（Ｓｕｐｐｏｒｔ Ｉｎｆoｒｍａｔｉｏｎ）が記述され；ＰＧＣプログラムマップ（ＰＧＣ＿ＰＧＭＡＰ）の先頭アドレス（ＰＧＣ＿ＰＧＭＡＰ＿ＳＡ）が記述され；セル再生情報テーブル（Ｃ＿ＰＢＩＴ）の先頭アドレス（Ｃ＿ＰＢＩＴ＿ＳＡ）が記述され；セル位置情報テーブル（Ｃ＿ＰＯＳＩＴ）の先頭アドレス（Ｃ＿ＰＯＳＩＴ＿ＳＡ）が記述され；そして、消去禁止フラッグ（ＡＲＣＨＩＶＥ Ｆｌａｇ）が記述されている。

ＳＣ＿ＧＩの場合は、ＡＲＣＨＩＶＥ Ｆｌａｇの代わりに、セルタイプ（Ｃ＿ＴＹ＝０１０ｂ）および一時消去（ＴＥ）フラグが記述され、さらに以下のものが記述される：
＊ＳＣＩに含まれるエントリポイント情報の数を記述したＳＣ＿ＥＰＩ＿Ｎｓ；
＊セルが参照するＳＯＢの数を記述したＳＯＢ＿Ｎ；
＊ＤＶＤストリーム記録ＰＡＴ記述フォーマットによりセルの開始アプリケーションパケット到着時間（開始ＡＰＡＴ）を記述したＳＣ＿Ｓ＿ＡＰＡＴ；
＊ＤＶＤストリーム記録ＰＡＴ記述フォーマットによりセルの終了アプリケーションパケット到着時間（終了ＡＰＡＴ）を記述したＳＣ＿Ｅ＿ＡＰＡＴ（この終了ＡＰＡＴは該当セルに属する最後のアプリケーションパケットのＡＰＡＴである）；
＊少なくとも１つのＳＯＢＵ境界（該当セルタイプＣ＿ＴＹのＴＥフィールドが「１０ｂ」）を含む「仮消去」状態のセルに対して、最初のＳＯＢＵ（その始まりが仮消去状態セルに含まれるもの）の最初のアプリケーションパケットのＡＰＡＴを記述したＥＲＡ＿Ｓ＿ＡＰＡＴ；
＊少なくとも１つのＳＯＢＵ境界（該当セルタイプＣ＿ＴＹのＴＥフィールドが「１０ｂ」）を含む「仮消去」状態のセルに対して、該当ＳＯＢＵ（仮消去状態セルのすぐ後に続くアプリケーションパケットを含むもの）の最初のアプリケーションパケットのＡＰＡＴを記述したＥＲＡ＿Ｅ＿ＡＰＡＴ。

記録時の信号の流れは、ＳＴＢ部で受け取ったＴＳパケットデータは、フォーマッタ部で、パック化されて記録される。このとき、各情報の有無を検知し、ワークＲＡＭに保存し、記録終了時に、管理情報として記録する。

サポート情報（Ｓｕｐｐｏｒｔ Ｉｎｆoｒｍａｔｉｏｎ）には、図７（ｂ）に示すように、ビットｂ０にランダムアクセスを許可するか否かを示すランダムアクセスインジケータサポートフラグが記録され、ビットｂ１にはユニット単位でスタートを許可するか否かを示すユニットスタートインジケータサポートが記録される。また、ビットｂ２にはＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）およびＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）がサポートされているか否を示すＰＡＴ・ＰＭＴサポートが記録され、ビットｂ３には再生クロックリファレンスＰＣＲがサポートされているか否を示すＰＣＲサポートが記録され、ビットｂ４にはスプライスカウントダウンＳＣＤがサポートされているか否を示すＳＣＤサポートが記録され、ビットｂ５からｂ７には、記録したＳＴ部の識別コードが記録されている。

識別コードには、例えば、ＢＳデジタル放送のＳＴＢ（００１）、ディレクトＴＶのＶｅｒ２のＳＴＢ（０１０）およびスカイパーフェクトＴＶのＶｅｒ１のＳＴＢ（０１１）がある。

また、再生時は、ディスクから読み出したパックデータを分離部で解析し、ＴＳパケットが入っているパックの場合には、ＴＳパケット転送部へ送る。ＴＳパケット転送部は、ＳＴＢ部からのリクエストに従って、ＳＴＢ部へＴＳパケットのみを転送する。

図８に示されるように各セル再生情報（Ｃ＿ＰＢＩ）（またはストリームセル情報ＳＣＩ）にさらにサポート情報が記述されることが好ましい。

すなわち、図８に示すように、相対バイト位置（Relative Byte Position ＲＰＢ）による表現でセル再生情報（Ｃ＿ＰＢＩ）の０バイト目トには、セルタイプ等のセルカテゴリ（Ｃ＿ＣＡＴ）（またはセルタイプＣ＿ＴＹ）が記録され；ＲＢＰで１から４バイト目には当該セルの先頭記録時のＳＴＣの値或いはＰＣＲが記述されるセル到着時間（Ｃ＿ＡＲＬ＿ＴＭ： Ｃｅｌｌ Ａｒｒｉｖａｌ Ｔｉｍｅ）が記録され；ＲＢＰで５から８バイト目にはセル内の最初のＶＯＢＵの先頭アドレス（Ｃ＿ＦＶＯＢＵ＿ＳＡ）が記述され；ＲＢＰで９から１２バイト目にはセル内の最後のＶＯＢＵの先頭アドレス（Ｃ＿ＬＶＯＢＵ＿ＳＡ）が記述され；ＲＢＰで１３から１６バイト目にはセル内の最後のＶＯＢＵの終了アドレス（Ｃ＿ＬＶＯＢＵ＿ＥＡ）が記述されている。

また、ＲＢＰで１７から１８バイト目にはトランスポートストリームパケット（ＴＳパケット）の長さを示すＴＳパケット長（ＴＳ Ｐａｃｋｅｔ Ｌｅｎｇｔｈ）が記述されている。

また、このセル再生情報（またはＳＣＩ）には、ＲＢＰで１９から２２バイト目にサポート情報としてＩピクチャの数（ＲＥＦＰＩＣ＿Ｎｓ）（またはアクセスユニット数ＡＵ＿Ｎｓ）が記録されている。

さらに、このセル再生情報（またはＳＣＩ）には、ＲＢＰで２３バイト目以降に、Ｉピクチャの先頭アドレス（ＲＥＦＰＩＣ＿ＳＡ＃１〜＃ｎ）（またはアクセスユニット開始マップＡＵＳＭ）およびＩピクチャの最後のアドレス（ＲＥＦＰＩＣ＿ＥＡ＃１〜＃ｎ）（またはアクセスユニット終了マップＡＵＥＭ）が次々と記録されている。

上記ＲＥＦＰＩＣ＿ＳＡ＃（Ｉピクチャ開始位置）は後述するＡＵＳＭ（Access Unit Start Map）に対応している。このＡＵＳＭは、ストリーマオブジェクト（ＳＯＢ）のデータユニット（ＳＯＢＵ）のどれがアクセスユニット（ＡＵ）を含んでいるかを示している。

また、上記ＲＥＦＰＩＣ＿ＥＡ＃（Ｉピクチャ終了位置）は後述するＡＵＥＭ（Access Unit End Map）に対応している。このＡＵＥＭは、ＡＵＳＭと同じ長さのビットアレイである。このＡＵＥＭ内のbitsは、どのＳＯＢＵが該当ＳＯＢのアクセスユニットに伴うビットストリームセグメントの末尾を含むのかを示している。

なお、上記ＳＯＢおよびＳＯＢＵはストリーマにおいて用いられる名称であり、ＤＶＤビデオ（ＤＶＤ＿ＲＴＲ）で用いられるＶＯＢおよびＶＯＢＵという名称に対応する立場にある。

ストリーマは送られてくるビットストリームをそのまま記録するもので、その内容には関知しない（つまりストリーマは記録内容を知らない）。

ストリーマで記録されるビットストリームがＭＰＥＧ２のトランスポートストリームの場合、Ｉピクチャ位置からデコードが開始される。この場合、あるＩピクチャと次のＩピクチャとの間の位置にタイムサーチされると（つまりタイムスタンプのみでアクセスすると）、その位置にはＩピクチャがないので、その後のＩピクチャが検出されるまでデコード開始が遅れてしまう（つまり、出画タイミングが遅れる）。

一方、ストリーマにおけるアクセス単位としてデータユニット（ＳＯＢＵ）を用いると、ＳＯＢＵ単位でＩピクチャの先頭位置／終了位置が分かる（ＡＵＳＭとＡＵＥＭで分かる）ので、ＭＰＥＧトランスポートストリームを用いたタイムサーチにおいてＩピクチャ位置がすぐに分かる。

すなわち、ＳＯＢＵをアクセス単位に用いれば、タイムサーチにおいてＩピクチャ位置がすぐに分かるので、デコード開始を素早くでき、かつスムースな早送り（ファーストフォワードＦＦ）および早戻し（ファーストリバースＦＲ）も可能となる。

図８では、ＴＳパケット長が記述されているが、常に１８８バイトのＴＳパケットが次々に転送されている場合には、このＴＳパケット長が判らなくても問題はない。しかしながら、放送局の都合でストリーマに送られるＴＳパケットが１８８バイト以上のパケットが送られてくる可能性がある。この実施の形態では、このような特別な場合をも考慮してパケット長を設定できるようにしている。

すなわち、ディスクからデータを読み出した後にパック内のデータパケットをこのＴＳパケット長で切り分けることにより、各パケットに切り分けることができるようにしている。

なお、ＭＰＥＧのトランスポートストリームにおけるＴＳパケットサイズ（１８８バイト）、ＤＶＤビデオ（ＤＶＤ＿ＲＴＲ）のプログラムストリームおけるパケットサイズ（２０４８バイト）、その他のパケットサイズ（ｎバイト／パケット）に対応したものをストリーマの記録対象として考える場合には、アプリケーションストリームという上位概念的なビットストリームを用いる。

次に他の例として、現在提唱されている録再ビデオフォーマットにおいてサポート情報を管理情報に記録する場合の例について説明する。

図９は、そのフォーマットの概略を示す。符号５０は記録消去再生可能なＲＡＭビデオであり、図９（ａ）に示すディスクの記録領域は、図９（ｂ）に示すように、リードイン２０およびリードアウト２１との間に定められている。その領域には、ボリュームおよびファイル管理情報領域２２およびデータ領域２３が設けられている。

データ領域２３は、図９（ｃ）に示すように複数のＤＶＤ領域２４に区分され、各ＤＶＤ領域２４は、図９（ｄ）に示すように制御情報２５並びに図２に示す構造を有するビデオオブジェクト３１から構成されている。制御情報２５は、図９（ｅ）に示すようにＶＯＢ一般情報（ＶＯＢ＿ＧＩ）（またはストリームファイル一般情報ＳＦ＿ＧＩ）２７並びに多数のＶＯＢＵ情報（ＶＯＢＵＩ）（またはストリームオブジェクト情報ＳＯＢＩ）２９を含むＶＯＢＵ情報テーブル（またはストリームファイル情報ＳＦＩ）２８から構成されている。

ＶＯＢ一般情報（ＶＯＢ＿ＧＩ）（またはＳＦ＿ＧＩ）２７には、図９（ｆ）に示されるように、ＶＯＢＵ＿Ｎｓ（またはＳＯＢＩ＿Ｎｓ）、ＶＯＢＩエンドアドレス（またはＳＯＢＵ＿ＳＩＺ）、サポート情報、その他が記録される領域が設けられている。

すなわち、ＲＢＰで０から３バイト目にはＶＯＢＵの数（ＶＯＢＵ＿Ｎｓ）またはＳＯＢＩの数（ＳＯＢＩ＿Ｎｓ）が記録され；ＲＢＰで４から７バイト目にはＶＯＢＩのエンドアドレス或いはＶＯＢＩのサイズすなわち長さが記録され；ＲＢＰで８バイト目には図７（ｂ）に示したと同様のサポート情報が記録される。さらに、ＲＢＰで９バイト目には消去禁止フラグ（ＡＲＣＨＩＶＥ Ｆｌａｇ）を記録することができる。

図９（ｅ）に示されるＶＯＢＵＩ（またはＳＯＢＩ）２９には、図１０に示されるサポート情報を記録できる。

すなわち、ＲＢＰでＶＯＢＵＩ（ＳＯＢＩ）２９の０から３バイト目にはＶＯＢＵのスタートアドレスが記録され；ＲＢＰで４から７バイト目にはＶＯＢＵのエンドアドレス或いはその長さが記録される。

また、ＲＢＰで８から１１バイト目には当該ＶＯＢＵの先頭が記録される際のシステムタイムクロックＳＴＣ或いはプログラムクロックリファレンス（ＰＣＲ：Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）がＶＯＢＵ＿ＲＥＣＴＭとして記録され；ＲＢＰで１２から１３バイト目にはＴＳパケットの長さを示すＴＳパケット長（ＴＳ Ｐａｃｋｅｔ Ｌｅｎｇｔｈ）が記述されている。

また、ＲＢＰで１４から１７バイト目には、Ｉピクチャの数（ＲＥＦＰＩＣ＿Ｎｓ）が記録されている。

さらに、ＲＢＰで１８バイト目以降には、次々に、Ｉピクチャの先頭アドレス（ＲＥＦＰＩＣ＿ＳＡ）および最後のアドレス（ＲＥＦＰＩＣ＿ＥＡ）が記録されている。

ここで、Ｉピクチャが常に先頭に配置されるようにＶＯＢＵが複数のＴＳパケットの集合に区分される場合には、ＶＯＢＵの区分する際に、Ｉピクチャのアドレスが用いられる。

図１０の上記ＲＥＦＰＩＣ＿ＳＡ＃は前述したＡＵＳＭ（Access Unit Start Map）に対応し、上記ＲＥＦＰＩＣ＿ＥＡ＃は前述したＡＵＥＭ（Access Unit End Map）に対応している。

このようにＶＯＢＵ内でＩピクチャが常に先頭に配置される例では、Ｉピクチャのスタートアドレスは、記述する必要が無く、Ｉピクチャのエンドアドレスのみが記述されればよいこととなる。

次に、上述したＴＳパケットに含まれる管理データを上述したテーブルに記録する場合の例として、次の５つの情報について説明する。

第１の情報は、図１（ｃ）に示されるＴＳパケットヘッダ内に含まれるランダムアクセス表示（ランダムアクセスインジケータ）で、これは、Ｉピクチャの先頭のデータが含まれるＴＳパケットの場合にアクティブとなる。

このフラグにより、Ｉピクチャの先頭の位置が特定できる。これをフォーマットに反映する場合には、二つの方法がある。

第１の方法は、図１１（ａ）に示すように、ＶＯＢＵ（またはＳＯＢＵ）３３に区分する際にこの情報を使用してフォーマットする場合である。

これにより、ＶＯＢＵ（ＳＯＢＵ）の先頭が常にＩピクチャの先頭と一致するため、ＶＯＢＵ（ＳＯＢＵ）毎の再生が容易にできることになる。この場合、図１１（ａ）に示すように常にＩピクチャのデータをＶＯＢＵ（ＳＯＢＵ）内の先頭に位置させるために、必要に応じてパディングパケットがＶＯＢＵ（ＳＯＢＵ）内に挿入される。

また、第２の方法として、図８および図１０に示すように各Ｉピクチャの先頭位置を管理領域に記録することにより、後に説明するＦＦ或いはＦＲ等の特殊再生等に利用できる。

実際のシステムでは、Ｉのスタートアドレスだけでは、ＳＴＢ部からのＩデコード終了割り込みを利用する必要があることから、ＳＴＢ部へ余分なデータが流れてしまい、効率が悪い。

そこで、さらに、第２の情報として、図１（ｂ）に示すユニット開始表示（ユニットスタートインジケータ）をサポートする。

すると、Ｉピクチャのエンドアドレスが特定できるため、さらに、無駄なデータの読み出しをしないファーストフォワードＦＦ或いはファーストリワインドＦＲ等の特殊再生を実現することができる。

このユニットスタートインジケータによって各ピクチャのスタートアドレスが特定できる。Ｉピクチャのエンドアドレスは、図８および図９に示すように管理情報として書き込まれる。

また、ここで、本実施の形態では、アドレス情報として、論理ブロックアドレスを使用している。これは、エラー情報などにより、実際の物理アドレスとは、スキッピングなどを行うため、一致しない。特にＤＶＤ−ＲＡＭなどの場合には、傷や指紋などの汚れによっても、エラーは発生するため、さらに違ってくる。そのため、論理ブロックアドレスはファイルシステムなどにより、物理アドレスへと変換される。

また、アドレス情報として考えられるものとしては、論理ブロックアドレスだけでなく、例えば、転送時間で示し、その時間情報から対応表を用いて、論理ブロックアドレスに変換し、さらに、物理アドレスに変換する方法なども考えられる。つまり、アドレス情報とは、対応表などを参照して、または、計算などを介して、物理アドレスに変換でき得る情報を指す。

第３の情報は、図１（ｄ）、図１１（ｃ）、図１３（ａ）〜（ｃ）に示されるＴＳパケットヘッダ内に含まれるスプライスカウントダウン（ＳＣＤ： Ｓｐｌｉｃｅ ＣｏｕｎｔＤｏｗｎ）で、これにより、編集可能な位置を特定できる。つまり、この単位で、論理的な最小単位（ＤＶＤでは、ＣＥＬＬが該当する。）を区切れば、そこからの編集に利用できる。

そのため、図１２（ａ）および図１３（ａ）に示すように、ＳＣＤ＝０のＴＳパケットを先頭にしたＴＳパックがセルの先頭にくるように調整する。こうしてセルをアラインすることにより、図１３（ｂ）に示すようにセル単位での編集が可能となり、さらに、図１３（ｃ）に示すように編集後でも、セル間でのシームレス再生が可能となる。

第４の情報は、図１（ｄ）に示されるＰＣＲを利用して、図８および図１０に示すようにセルまたはＶＯＢＵの再生時間を表示する方法である。

ここで、ＰＣＲはＴＳパケットの転送到着リファレンス時間を示しており、毎ＴＳパケットについているわけではない。が、ＴＳストリームは、リアルタイムに再生されるべきデータであるため、再生時間とほぼ同じ時間を示す可能性が高い。しかしながら、再生時間に関しては、ペイロードに含まれているために、スクランブルを解かない限り利用できないため、録再ＤＶＤストリーマでは、利用できない。

このため、ＰＣＲ情報とその時間データを取り込むＳＴＣを利用して、再生時の表示を行う。これにより、だいたいの再生時間が表示できるようになる。ただし、ＰＣＲをサポートしていない場合には、再生を開始した時をＳＴＣ＝０とし、その後カウントを開始してその時々のＳＴＣの値を再生時間とする。

第５の情報は、図１１（ｂ）、図１２（ａ）〜（ｃ）のＰＡＴ、ＰＭＴパケットで、これらのパケットには、番組を再生すべき各データのＰＩＤが記録されている。これらは、数１００ｍｓ〜数ｓ間隔で挿入されており、番組を途中から再生する場合には、このデータにより再生が開始される。

そのため、これを利用して、図１１（ｂ）、図１２（ａ）〜（ｃ）に示すように、データの区切りとして使うことができる。

ここで、ＤＶＤ―ビデオフォーマットに合わせて考えると、次の４種類の切り分けに利用できる。

まず、第１に、図１１（ｂ）に示すように、ＶＯＢＵ（またはＳＯＢＵ）の先頭をＰＡＴパケットの先頭と合わせることにより、ＶＯＢＵ（ＳＯＢＵ）毎の途中再生が可能となる。ただし、ここで、問題なのは、ＰＡＴの後のビデオデータが必ずしもＩピクチャから始まっているとは限らないため、Ｉピクチャを見つけるまで、若干のタイムラグ生じる可能性がある。そのため、ＶＯＢＵ（ＳＯＢＵ）に関しては、前記Ｉピクチャでの切り分けの方が望ましいと考えられる。

第２に、図１２（ａ）に示すように、セルの先頭をＰＡＴパケットの先頭と合わせることにより、セルの区切りとする。ただし、ＰＡＴの出現頻度が、数１００ｍｓ〜数ｓオーダーであるため、数ＰＡＴおきにセルの区切れを設定することになる。しかしながら、この方法では、編集点を基準にしていないため、編集などを行うと、連続性を損なわれ、シームレスな再生は保証できなくなる。そのため、前記のＳＣＤによるセルの切り分けの方が望ましい。

第３に、図１２（ｂ）で示すように、プログラムの切り分けをＰＡＴにより、行うことが考えられる。これにより、ＰＧジャンプ、ＰＧＳＫＩＰなどが対応できるようになる。ただし、ＰＡＴの出現頻度が、数１００ｍｓ〜数ｓオーダーであるため、数十〜数百ＰＡＴおきにプログラムの区切れを設定することになる。

第４に、図１２（ｃ）で示すように、ＰＧＣの切り分けをＰＡＴにより、行うことが考えられる。これにより、ＰＧＣジャンプ、ＰＧＣＳＫＩＰなどが対応できるようになる。ただし、ＰＡＴの出現頻度が、数１００ｍｓ〜数ｓオーダーであるため、数百〜数千ＰＡＴおきにＰＧＣの区切れを設定することになる。

また、ＳＴＢ部の識別コードは、接続されているＳＴＢ部の受信できるデジタル放送の種類を示している。これにより、再生時に、接続しているＳＴＢ部を調べ、記録時と同じＳＴＢ部を選択して再生することができる。さらに、このコードで、再生時間の表示に関する動作を代えることもできる。

ＳＴＢ部が再生時間をレコーダに出力する命令をサポートしている場合には、定期的に再生時間をＳＴＢ部より取り込み、表示する。この値が再生時間としては一番、正しいことになる。

次に、図１４を参照して衛生放送に対応可能なＤＶＤ録再機のシステム構成について説明する。

図１４において、符号５０は、ＲＡＭディスクであり、このＲＡＭディスク５０は、ディスクドライブ部５１で駆動され、また、ディスクドライブ部５１によってデータプロセッサ（Ｄ−ＰＲＯ）５２との間でデータが授受される。データプロセッサ５２には、データを一時的に保存する一時記憶部５３が接続されている。

図１４の録再機は、ＭＰＥＧのビットストリームおよび／または通常ビデオ信号を、記録／再生できるように構成されている。これらのビットストリームおよびビデオ信号は、単独で、あるいは混在して記録可能となっている。

図１４のシステムのデコーダ部５９は、メモリを有する分離部６０を含み、この分離部６０には、データプロセッサ５２から再生データが転送される。

再生データは、分離部６０でビデオデータ、副映像データおよびオーディオデータ（いずれもパケットデータ）に分離され、ビデオデータは、縮小画像（サムネールピクチャ）生成部６２を有するビデオデコード部６１に転送され、副映像データおよびオーディオデータは、副映像デコーダ６３およびオーディオデコーダ６４にそれぞれ転送される。

これらビデオデコード部６１および副映像デコーダ６３でデコードされたビデオデジタル信号および副映像デジタル信号は、ビデオプロセッサ（Ｖ−ＰＲＯ）部６５で合成されてビデオミキシング部６６に供給される。ビデオミキシング部６６は、ビデオデジタル信号をフレーム毎に一時的に記憶するフレームメモリ７３に接続され、外部から供給されたテキストデータ等がビデオフレーム中に合成処理されてビデオデジタル信号がＤ／Ａ変換器６７に供給され、Ｄ／Ａ変換されたビデオ信号がＴＶモニタ６８に出力される。ビデオデジタル信号は、インターフェース６９を介して外部に取り出すことができる。

また、オーディオデコーダ６４からのオーディオデジタル信号は、Ｄ／Ａ変換器７０に供給され、Ｄ／Ａ変換されたオーディオ信号がスピーカ７２に出力される。オーディオデジタル信号は、同様にインターフェース７１を介して外部に取り出すことができる。

なお、ビデオデコード部６１の縮小画像（サムネールピクチャ）生成部６２は、主ＭＰＵ８０からの縮小ＯＮの命令に基づいて転送されたビデオデータの縮小画像のビデオ信号を生成し、これをビデオプロセッサ部６５に供給してＴＶモニタ６８に縮小画像を表示することができる。主ＭＰＵ８０には、外部から指令、例えば、再生（ＰＬＡＹ）、停止（ＳＴＰ）、記録位置に関するマークを付すマーカ等の指示をするためのキーを備えたキー入力部１０３および表示部１０４が接続されている。

図１４に示されたシステムのエンコーダ部７９には、外部のＡＶ機器８１或いはＴＶチューナ８２からＡＶ入力が可能であり、また、ＳＴＢ部８３からデジタル放送データが入力可能である。ＳＴＢ部８３には、デジタル放送データを受信する衛星放送アンテナが接続されている。

外部のＡＶ機器８１或いはＴＶチューナ８２からのＡＶ信号は、Ａ／Ｄ変換器８４でデジタル化され、デジタルオーディオ信号は、オーディオエンコーダ部８６に供給され、デジタルビデオ信号は、セレクタ８５を介してビデオエンコーダ８７に供給され、ＭＰＥＧ圧縮される。

文字情報等の字幕情報がＴＶチューナ８２から出力されている場合には、この字幕情報は、副映像エンコーダ８８に供給され、ランレングス圧縮される。

エンコーダ部８６、８７、８８でエンコードされたデータは、バッファメモリ部９１が接続されているフォーマッタ部９０に供給され、このフォーマッタ部９０でパケットヘッダが付されたビデオパケット、オーディオパケット並びに副映像パケットに格納され、さらにパックヘッダが付されてパック構造に変換される。

これらパックは、図２（ｄ）に示すようにＶＯＢＵ（ＳＯＢＵ）単位にまとめられ、さらに、多数のＶＯＢＵ（ＳＯＢＵ）でセルに構成され、セルの集合としてのビデオオブジェクトＶＯＢ（ＳＯＢ）に、また、必要であれば、ビデオオブジェクトセットが定められる。

これらのフォーマットの過程で、ＴＶチューナ８２で発生される切り分け情報を参照して、管理情報がフォーマッタ部９０で生成される。例えば、切り分け情報を参照してＰＧＣ情報が作成される。

生成された管理情報およびパックデータは、データプロセッサ部５２に送られ、データプロセッサ部５２において主ＭＰＵ８０の管理データ作成部８０Ｂで作成され、この管理データ作成部８０Ｂから与えられた管理データテーブルに生成された管理情報が格納され、ディスクドライブ部５１を介して光ディスク５０に管理データと共にパックデータが記録される。

ＳＴＢ部８３からは、選択した番組、すなわちタイトルに相当するＭＰＥＧ２トランスポートストリームが直接フォーマッタ部９０に供給され、図１に示すようにフォーマットされると共に管理情報が生成され、データプロセッサ部５２において管理情報が所定の管理データテーブル内に格納され、この管理データテーブル並びにトランスポートパケットは、同様にディスクドライブ部５１を介して光ディスク５０に記録される。

ＳＴＢ部８３は、デコーダを内臓し、ＴＳパケット内のＡＶデータがデコードされてそれぞれオーディオ信号並びにビデオ信号に変換され、オーディオ信号並びにビデオ信号は、それぞれＤ／Ａ変換器７０、６７を介してスピーカ７２およびＴＶモニタ６８に供給される。

光ディスク５０に供給されたＴＳパック３４は、データプロセッサ部５２およびディスクドライブ部５１を介してデコーダ部５９の分離部６０に供給され、分離部６０では、ストリームＩＤ並びにサブストリームＩＤを参照してその内のパケットデータがＴＳパケットデータである旨を検知し、そのＴＳパケットをＴＳパケット転送部１００に分配することとなる。

ＴＳパケット転送部１００は、ＴＳパケット３８をＳＴＢ部８３に所定の転送タイミングを供給することとなる。このＴＳパケット内のデータは、ＳＴＢ部８３でデコードされ、デコードされたオーディオ信号並びにビデオ信号は、それぞれＤ／Ａ変換器７０、６７を介してスピーカ７２およびＴＶモニタ６８に供給される。

なお、上述した記録再生動作は、デコーダ部５９並びにエンコーダ部７９は、システムタイムクロック１０２の管理下でデータの転送等が実行される。

次に、録画処理および再生処理について図１５から図２３を参照して説明する。

始めに録画時のデータ処理について図１５、図１６および図１７に示すフローチャートを参照して説明する。

まず、ステップＳ１０でＭＰＵ部８０がキー入力部１０３から録画命令受けると、録画処理が開始される。

ステップＳ１１でドライブ部５１によって光ディスク５０から管理データが読み込まれ、ステップＳ１２で示すように空き容量があるかがチェックされる。空き容量がない場合には、ステップＳ１３に示すように空き容量がない旨の表示が表示部１０３に表示され、ステップＳ１４に示すように処理が終了する。

空き容量がある場合には、ステップＳ１５に示すように空き容量に相当する領域中に書き込み領域を決定する。すなわち、書き込みアドレスが決定される。次に、決定された領域に録画データを書き込むために管理領域にそのアドレスを書き込み、ビデオデータの書き込みスタートアドレスをドライブ部５１に設定し、データを記録する準備を行う。次に、ステップＳ１６に示すようにＳＴＢ部８３からＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）を読み出す命令を出す。

ＭＰＵ部８０からの要求に応じてＳＴＢ部８３は、そのときの最新のＥＰＧを用意する。すなわち、ＳＴＢ部８３は、最新のＥＰＧを受信し、ワークメモリに保存する。受信した、或いは、ＳＴＢ部８３内のワークメモリに保存してあるＥＰＧデータは、ＭＰＵ部８０に返信される。

ＭＰＵ部８０は、ステップＳ１７に示すようにそのＥＰＧデータを表示してユーザに記録する番組を選ばせることとなる。その後、記録する番組が決定されると、ステップＳ１８に示すようにＭＰＵ部８０は、ＳＴＢ部８３に対してサポート情報を出力する命令を出し、ＳＴＢ部８３からサポート情報がＭＰＵ部８０に取り込まれる。また、この時にサポート情報とともにＳＴＢ識別コードもＳＴＢ部８３からＭＰＵ部８０に取り込まれる。サポート情報は、ＭＰＵ部８０内のサポート管理情報検出部８０Ｃで検出される。

このとき、サポート情報がＳＴＢ部８３内に無い場合には、録画中に、該当の情報があるかどうかがチェックされて、該当情報がその代用となる。ＭＰＵ部８０は、ＳＴＢ部８３へ録画する目的の番組を指定し、受信を開始させる。

ＭＰＵ部８０は、ステップＳ１９に示すように光ディスク５０の管理領域に管理情報を書き込む指示をする。すなわち、ＶＭＧＩにＶＴＳを登録し、ビデオタイトルセットのための管理データテーブルとしてのＶＴＳＩが作成されてこれにサポート情報が書き込まれる。あるいは、ステップＳ１９において、図６のＳＴＲ＿ＶＭＧＩが作成される。

なお、ＤＶＤ＿ＲＴＲ（アナログビデオを内部でＭＰＥＧデータに変換してリアルタイムレコーディングを行なうシステム）では、上記ＶＭＧＩおよびＶＴＳＩの役割は、ＲＴＲビデオマネージャ情報（ＲＴＲ＿ＶＭＧＩ）に統合されている。よって、ＤＶＤ＿ＲＴＲレコーダをストリーマとして利用するときは、ＶＭＧＩおよびＶＴＳＩ（またはＳＴＲ＿ＶＭＧＩ）を、適宜ＲＴＲ＿ＶＭＧＩに読み変えればよい。

ＭＰＵ部８０は、ステップＳ２０に示すように録画のための初期設定としてＳＴＣ部１０２の時間をリセットする。ここで、ＳＴＣ部１０２はシステムのタイマーでこの値を基準に録画並びに再生が実行される。また、ファイルシステムにＶＭＧおよびＶＴＳファイルのデータを書き込み、ＶＭＧＩおよびＶＴＳＩに必要な情報を書き込む。

このとき、サポート情報が判明している場合には、その判明しているサポート情報が書き込まれる。さらに、各部へ録画設定を行う。このとき、フォーマッタ部に図１１から図１３を参照して説明したような各データの区切りを設定し、また、ＴＳパケットを受け取る設定がなされる。

録画を開始する際には、図１６のステップＳ２１に示すように録画開始の設定が各部になされる。具体的には、フォーマッタ部９０に録画開始の命令が与えられ、フォーマッタ部９０で録画開始されて録画データのフォーマット作業が開始される。

録画が開始されると、フォーマッタ部のバッファＲＡＭが一杯になる前に定期的にＭＰＵ部８０は、ステップＳ２２に示すように切り分け情報、すなわち、図１１から図１３を参照して説明したデータの区分け情報の更新の入力があるかをチェックし、ある場合には、ステップＳ２３に示すようその切り分け情報がＭＰＵ部９０のワークＲＡＭ９０Ａに保存される。

切り分け情報の保存後、或いは、切り分け情報の更新がない場合には、ステップＳ２４ー１において録画終了のキー入力があったかがチェックされる。録画終了のキー入力がある場合には、ステップＳ２８の録画終了の処理が実行される。録画終了のキー入力がない場合には、ステップＳ２４ー２に示すように光ディスク５０中の空き領域の容量がチェックされ、残り容量が算出される。

この残り容量が所定の値以下になったかがステップＳ２５においてチェックされる。所定値に以下となっていない場合には、再びステップＳ２４に戻され、定期的に残り容量がチェックされる。残り容量が所定値以下になった場合には、ステップＳ２６において残り残り容量が少ない処理がなされる。

その後、ステップＳ２７において録画可能容量がないかがチェックされる。録画可能容量が十分であれば、再びステップＳ２２に戻され、ステップＳ２２からＳ２６が繰り返される。

録画可能容量がない場合には、ステップＳ２８に示す録画終了処理が実行される。この録画終了処理においては、フォーマッタ部９０から残ったデータに対する切り分け情報が取り込まれ、その情報がワークＲＡＭ８０Ａに追加され、それらのデータが管理データ（ＶＭＧＩ、ＶＴＳＩ；またはＲＴＲ＿ＶＭＧＩ；もしくはＳＴＲ＿ＶＭＧＩ）に記録されるとともにファイルシステムに記録したデータに対する情報が記録される。その後、ステップＳ２９に示すように録画動作が終了される。

図１４に示したシステムにおける録画動作におけるビデオ信号の流れについて詳述すれば、次のようになる。

まず、ＳＴＢ部８３から入力されたＴＳパケットがフォーマッタ部に入力される。ここで、ＳＴＣの値から、転送開始からの時間を読み込み、その時間を管理情報として、バッファＲＡＭ９１に保存される。この情報は、切り分け情報と共に、ＭＰＵ部８０に送られ、管理情報に記録される。また、切り分け情報としてＶＯＢＵ（またはＳＯＢＵ）の切り分け情報、セルの切り分け情報、プログラムの切り分け情報、ＰＧＣの切り分け情報が作成され、定期的に、ＭＰＵ部８０に送られる。

ここで、ＶＯＢＵ（ＳＯＢＵ）の切り分け情報としては、ＶＯＢＵ（ＳＯＢＵ）の先頭アドレス、ＶＯＢＵ（ＳＯＢＵ）の再生時間、Ｉピクチャのスタートアドレスおよびエンドアドレスがある。Ｉピクチャのスタートアドレスには、ＴＳパケット内のランダムアクセスインジケータがアクティブになっているＴＳパケットが記録されているパックのアドレスが設定される。

Ｉピクチャのエンドアドレスには、ランダムアクセスインジケータがアクティブになった後に、ＴＳパケット内のユニットスタートインジケータがアクティブになっているＴＳパケットの直前のビデオデータが格納されるＴＳパケットがＩピクチャのエンドパケットであるのでこのＴＳパケットが記録されているパックのアドレスが設定される。

また、ＶＯＢＵ（ＳＯＢＵ）の再生時間には、ＶＯＢＵ（ＳＯＢＵ）の転送開始から転送終了までの時間で代用される。

フォーマッタ部９０は、バッファメモリ部９１にＴＳパケットデータを一時保存し、その後、入力されたＴＳパケットデータをパック化して、図２（ｅ）に示すようなパック列になるようにフォーマットして、Ｄ−ＰＲＯ部５２に入力する。

Ｄ−ＰＲＯ部５２は、１６パック毎にまとめてＥＣＣグループとして、エラー訂正データを付加してドライブ部５１へ送る。ただし、ドライブ部５１がディスクへの記録準備ができていない場合には、一時記憶部５３に転送し、データを記録する準備ができるまで待ち、用意ができた段階で記録を開始する。ここで、一時記憶部５３は、高速アクセスで数分以上の記録データを保持するため、大容量メモリが想定される。

ただし、マイコンは、ファイルの管理領域などを読み書きするために、Ｄ−ＰＲＯ部５２へマイコンバスを通して、読み書きすることができる。

ここで、録画終了時に、消去禁止フラグ（プロテクトフラグあるいはアーカイブフラグ）をクリアし、消去許可とする。つまり、記録初期時には、消去を可能としている。

次に、再生時のデータ処理について図１７および図１８を参照して説明する。

ＭＰＵ部８０が再生命令を受けると、ステップＳ３０に示すように再生処理が開始される。ステップＳ３１に示すようにディスク５０がディスクドライブ部５１で検索されてディスク５０のチェックが実行される。

ディスク５０のチェックにおいて、ディスク５０に欠陥等がある場合には、ステップＳ３２でエラー処理が施されてステップＳ３３に示すように再生が終了される。

ディスク５０に問題がなければ、ステップＳ３４に示すように接続されているＳＴＢ部８３がチェックされ、その識別コードが取り込まれる。その後、ステップＳ３５に示すようにディスク５０の管理領域がディスクドライブ部５１で検索されてＤ−ＰＲＯ部５２を介してその管理情報（ＶＭＧＩ、またはＳＴＲ＿ＶＭＧＩを含むＳＴＲＩ）が読み込まれ、ステップＳ３６に示すように再生するタイトルセット（または１以上のＰＧＣ）を選択することが可能となる。

ステップＳ３６で再生するタイトルセット（ＰＧＣ）がユーザによって決定されてそのアドレスが決定されると、ＭＰＵ部８０は、次にドライブ部５１に決定されアドレスのリード命令を送ることとなる。従って、ステップＳ３７に示すように決定されたタイトルセット（ＰＧＣ）のＶＴＳＩ（またはＳＴＲ＿ＶＭＧＩ）が読み込まれ、その内のＰＧＣＩ（またはプレイリストサーチポインタ）がワークＲＡＭ８０Ａに保存される。

ここで、ステップＳ３８に示すように選択されたタイトルセット中から接続されているＳＴＢ部８３に対応するタイトル、或いは、ＰＧＣ（プログラムＰＧでも良い。）の全てが表示される。この表示に基づいて、ユーザは、ステップＳ３９に示すように再生するタイトル、或いは、ＰＧＣ（または、プログラム）を選択し、決定することとなる。

その後、ステップＳ４０に示すように図７または図９に示される管理情報内のサポート情報が読み出され、サポート情報に基づく各部のセットが実行される。すなわち、ステップＳ４１に示すようにランダムアクセスインジケータがサポートされているかが確認され、サポートされていれば、ステップＳ４２に示すようにＩピクチャに基づくＦＦおよびＦＲの特殊再生を許可する旨のフラグがセットされる。

ランダムアクセスインジケータがサポートされていない場合には、ステップＳ４３に示すようにＰＡＴがサポートされているかが確認される。ＰＡＴがサポートされていれば、ステップＳ４４に示すようにＰＡＴに基づくＦＦおよびＦＲの特殊再生を許可する旨のフラグがセットされる。ＰＡＴもサポートされていない場合には、ステップＳ４５に示すようにＦＦおよびＦＲの特殊再生を禁止する旨のフラグがセットされる。

サポート情報に基づくセットが終了すると、ステップＳ４６に示すように再生を開始するプログラム番号およびセル番号が決定される。ＭＰＵ部８０は、ＳＴＢ部８３に対して内部バスを介してＴＳパケットを再生する命令を送ることとなる。また、ＭＰＵ部８０は、分離部６０に対してＴＳパケットをＳＴＢ部８３に送る初期設定を実行するとともにＶミキシング部６６に対してＳＴＢ部８３から送られるビデオ信号を表示処理可能に設定する（図１８のステップＳ４７）。

ドライブ部５１は、ＭＰＵ部８０から送られた命令に従って、すなわち、決定されたプログラム番号およびセル番号に従って、ディスク５０からセクタデータが読み出される。そして、Ｄ−ＰＲＯ部５２において読み出されたデータのエラーが訂正され、パックデータとしてデコーダ部５９に出力される。

デコーダ部５９においては、分離部６０は、そのストリームＩＤ並びにサブストリームＩＤからＴＳパケットである旨を判断してＴＳパケットをＴＳパケット転送部１００に送り、ＴＳパケットは、ＳＴＢ部８３に転送される（ステップＳ４７）。

ここで、ＳＴＢ部８３は、送られたＴＳパケットをデコードすることになる。通常放送受信の場合には、送られたデータをそのまま書き込んでいたが、内部バスによるデータの受け渡し時には、ＲＥＣ信号、ＡＣＫ信号を用いて、次のようにする。すなわち、ＳＴＢ部８３が消費するバッファが空いた際にＲＥＣ信号をアクティブにする。そして、分離部６０でデータの転送の用意ができたら、バスにデータを流す毎にＡＣＫ信号をアクティブにする。こうすることで、ＳＴＢ部８３よりデータ転送の要求があった際に、データを転送するようにしている。

送られたＴＳパケットデータは、ＳＴＢ部８３で再生され、ビデオデータは、Ｖミキシング部６６を経由してＴＶ信号に変換され、ＴＶモニタ６８に表示される。オーディオ信号もＤ／Ａ部９０に送られ、音声に変換され、スピーカ７２から再生される。

再生中、定期的にＰＣＲのデータがＳＴＣにセットされ、ＳＴＣの内容が再生時間として表示される。また、ＳＴＢ部８３から再生時間を転送することができる場合には、定期的に再生時間データが転送され、表示される。ただし、ＳＴＢ部８３で、ビデオデータ内のＰＴＳを基に再生時間を表示できる場合には、その再生時間が表示に使用される。

再生時には、図１８のステップＳ４８に示すようにセルを単位として処理される。ＭＰＵ部８０は、セル再生処理後エラー等が原因でドライブ部５１が停止していないかどうかを、常にチェックしている（ステップＳ４９）。ドライブが停止されている場合には、ステップＳ５０に示すようにその再生動作が終了される。

ドライブ部５１が動作している間は、常に最終セルか否かがチェックされ（ステップＳ５１）、最終セルでない場合には、セル番号がステップＳ５２に示すようにカウントアップされてステップＳ４８に示すセル再生処理に戻される。

ステップＳ５１において最終セルに達すると、再生終了かがステップＳ５３においてチェックされ、再生終了でない場合には、再度ステップＳ４８に戻され、他のプログラム（または他のプレイリスト）或いはＰＧＣのセルの再生が開始される。

ステップＳ５３において、再生終了である場合には、再生終了に伴う処理がステップＳ５４で実行され、その後、ステップＳ５５に示すように再生動作を終了する。

次に、図１８に示したセル再生時の処理の詳細について図１９を参照して説明する。

始めに、図１８のステップＳ４８に相当するセル再生時の処理が図１９のステップＳ６０に示すように開始されると、ステップＳ６１に示すようにセルの再生処理開始の要求があるかがチェックされる。セル再生処理の要求がない場合には、ステップＳ６２でＶＯＢＵ（またはＳＯＢＵ）が連続しているか否かがチェックされる。

ＶＯＢＵ（ＳＯＢＵ）が連続している場合には、ステップＳ６５に示すようにＦＦキーが入力されたかがチェックされる。

ＶＯＢＵ（ＳＯＢＵ）が連続していない場合には、ステップＳ６３に示すようにＰＧＣＩ（または図１０のＳＯＢＩ）が参照されて再生開始アドレス（論理ブロック番号ＬＢＮ）が決定される。そして、ステップＳ６４に示すように、このアドレスでドライブ部５１にデータ読み出しの命令が出され、ドライブ部５１が検索を開始することとなる。

その後、再生開始アドレスからセルの再生が開始され、再生中において同様にステップＳ６５に示すようにＦＦ再生キーが入力されたかがチェックされる。

ステップＳ６５においてＦＦ再生キーが入力されている場合には、ステップＳ６６においてＦＦ再生が許可されているかが確認される。ＦＦ再生が許可されていない場合には、ステップＳ６７に示すように「放送局の都合によりＦＦ再生ができません。」の表示がなされ、ステップＳ７１に移行される。ここで、ＦＦ動作の禁止として画面に「放送局の都合によりＦＦできません」との表示が出される場合とは、サポート情報にＩピクチャの特定もまたＰＡＴのサポートもない場合が該当する。

ＦＦ再生が許可されている場合には、ステップＳ６８に示すようにＦＦの処理が実行される。ＦＦ処理の実行中にエラー等が原因でドライブ５１が停止したか否かがチェックされ（ステップＳ６９）、ドライブ５１が停止された場合には、ステップＳ７０に示すようにＦＦ処理並びに再生処理が終了される。

ステップＳ６５においてＦＦ再生キーが入力されていない場合には、また、ステップＳ６７においてＦＦ不可の表示がなされた場合には、あるいはステップＳ６９においてドライブ５１が停止していない場合は、ステップＳ７１に示すようにＳＴＢ部８３が再生時間を出力するタイプであるかがチェックされる。

ＳＴＢ部８３が再生時間を出力するのであれば、ステップＳ７２に示すようにＳＴＢ部８３から出力される再生時間が表示される。ＳＴＢ部８３が再生時間を出力しない場合には、ステップＳ７３に示すようにサポート情報を参照して転送されてくるＴＳパケットの管理データ中に時刻情報が記述されたＰＣＲがあるかが確認される。

ＰＣＲ対応であれば、ステップＳ７５に示すようにそのＴＳパケットの管理データ内のＰＣＲの値が表示されてステップＳ７６に移行される。ＰＣＲ対応でなければ、ＳＴＣ部１０２の時刻が表示（ステップＳ７４）されてステップＳ７６に移行される。

ステップＳ７６においては、セルが最後に相当するかが確認され、最後のセルでない場合には、再びステップＳ６５に戻されて再びステップＳ６５からステップＳ７５が実行される。

セルが最後に相当する場合には、ステップＳ７７に示すようにそのセル内のＶＯＢＵ（またはＳＯＢＵ）の再生が終了するのを待つこととなり、その後、ＶＯＢＵ（ＳＯＢＵ）の再生が終了すると、ステップＳ７８に示すように、既に説明した図１８のステップＳ５４に移行される。

さらに、特殊再生を図２０から図２３を参照して説明する。この特殊再生の実例では、ＦＦ再生に関して説明するが、ＦＲ再生に関しても同様であるので、その説明は、ＦＦ再生と同様として省略する。

ステップＳ６８に示すＦＦ再生処理は、図２０および図２１に示すフローが実行される。

すなわち、ＦＦ処理がステップＳ８０で開始されると、ＳＴＢ部８３にＩピクチャのみ再生の命令が出される（ステップＳ８１）。ステップＳ８２に示すようにＴＳパケットがランダムアクセスインジケータをサポートしているか否かがサポート情報を参照して確認され、サポートしていない場合には、ステップＳ８４に示すようにＰＡＴによるＦＦ処理に移行される。このＰＡＴによるＦＦ処理については、図２３を参照して後に説明する。

ＴＳパケットがランダムアクセスインジケータをサポートしている場合には、ステップＳ８３に示すように転送中のＶＯＢＵ（ＳＯＢＵ）がセル中における最後のＶＯＢＵ（ＳＯＢＵ）に相当するかが確認される。最後のＶＯＢＵ（ＳＯＢＵ）の場合には、ステップＳ８６に示すように次のＶＯＢＵ（ＳＯＢＵ）中の先頭Ｉピクチャアドレスを読み出してステップＳ８７に移行される。ＶＯＢＵ（ＳＯＢＵ）が最後のＶＯＢＵ（ＳＯＢＵ）に相当しない場合には、２つ先のＩピクチャスタートアドレスを読み出して（ステップＳ８５）、ステップＳ８７に移行される。

ステップＳ８７においては、ユニットスタートインジケータがサポートされているかが調べられる。

サポートしている場合（ステップＳ８７イエス）には、ステップＳ９１に示すように転送割り込みフラッグがクリアされ、次のＩピクチャエンドアドレスが読み出される。そして、ステップＳ９２に示すようにドライブ部５１にＩピクチャのスタートアドレスおよびエンドアドレスを指定して読み込み命令が与えられてＩピクチャスタートアドレスおよびＩピクチャエンドアドレスでＩピクチャデータが読み出される。

ステップＳ９３において、ドライブ部５１に、データの転送終了割り込み、すなわち、ドライブ部５１からの割り込みを待ち、そのＩピクチャデータの転送が終了したか否かが確認される。

転送が終了している場合には、ステップＳ９１に戻されて次のＩピクチャを再生するために再びステップＳ９１およびステップＳ９２が実行される。Ｉピクチャデータの転送が終了していない場合には、ステップＳ９４に示すようにストップ（ＳＴＯＰ）キー或いはプレー（ＰＬＡＹ）キーが押されたかが確認される。

これらキーが押されていない場合には、再びステップＳ９３に戻されてＩピクチャデータの転送を待つこととなる。ステップＳ９４において、キーが押さた場合には、図２１に示すステップＳ９５に移行される。

ステップＳ８７において、ユニットスタートインジケータがサポートされていない場合（ステップＳ８７ノー）には、ステップＳ８８に示すように始めにＩピクチャ再生割り込みフラグがクリアされ、ドライブ部５１にＩピクチャのスタートアドレス、連続読みだしを指定して読み込み命令が出される。

その後、ステップＳ８９に示すようにＩピクチャのデコード終了割り込み、すなわち、ＳＴＢ部８３からの割り込みを待ち、割り込みがある場合には、ステップＳ８８に戻され、再びステップＳ８８およびステップＳ８９が実行される。

割り込みがない場合には、ステップＳ９０に示すようにストップ（ＳＴＯＰ）キー或いはプレー（ＰＬＡＹ）キーが押されたかが確認される。これらキーが押されていない場合には、再びステップＳ８９に戻されてＳＴＢ部８３からの割り込みを待つこととなる。ステップＳ９０において、キーが押さた場合には、図２１に示すステップＳ９５に移行される。

ここで、割り込み処理（図２０のステップＳ８９）については、図２２に示すように実行される。すなわち、ステップＳ１２０に示すように割り込み処理が開始されると、ステップＳ１２１において割り込みの要因がチェックされる。

この要因がドライブ部５１からの転送終了割り込み処理であれば、ステップＳ１２２に示すように転送終了割り込みフラグがセットされ、ＳＴＢ部８３からのＩピクチャ再生割り込み処理であれば、Ｉピクチャ再生割り込みフラグがセットされる。また、タイマー割り込み処理であり、ＳＴＢ部８３が再生時間出力対応のタイプであれば、ＳＴＢ部８３から再生時間が取り込まれ、ワークＲＡＭにセットされる。これらセットの後に対応するステップが実行される。

図２１のステップＳ９５において、入力されたキーが停止の場合には、ステップＳ９６に示すように停止命令がセットされて、ステップＳ９７に示すように、再生終了時の処理（図１８のステップＳ５４）がされて再生が終了される。

ステップＳ９５において、ＰＬＡＹキーが押されている場合には、ステップＳ９８に示すように次のＶＯＢＵ（ＳＯＢＵ）のＩピクチャスタートアドレスで読み出し命令がそれぞれドライブ部５１に与えられ、ステップＳ９９に示すようにそのアドレスでデータの読み出しが開始され、次々にデータが読み出される。その後、ステップＳ１００に示すように処理フローが図１８のステップＳ４８に戻され、ＦＦ再生の処理が終了する。

なお、ＦＲ再生に関しては、取り出すＩピクチャの位置がＦＦとは逆方向になっただけであり、図２０および図２１のフローを援用することができる。また、ＴＳパケットの構造がパケットアクセスポインタを備える構造においては、特殊再生時に以下のような処理がなされる。

ＶＯＢＵ（ＳＯＢＵ）がＩピクチャ毎に区分されている場合には、ＴＳパケットがＶＯＢＵ（ＳＯＢＵ）毎にアラインされているのでパケットアクセスポインタはなくてもよい。しかしＶＯＢＵ（ＳＯＢＵ）がＩピクチャ毎に区分されていない場合には、ランダムアクセスポインタを利用して再生を実行する場合に問題が生じる。

すなわち、Ｉピクチャのスタートアドレスによってパックを読み出そうとする場合には、ＩピクチャがＶＯＢＵ（ＳＯＢＵ）の先頭に位置されているとは限らないことから、パックのデータ領域のスタート位置とＴＳパケットの区分け（スプリット）開始位置とが一致していない恐れがある。その場合には、このパケットアクセスポインタ（たとえば図３（ｄ）の０ｘ２ｅ）により、ＴＳパケットの区分け（スプリット）開始場所が決定される。

図２０に示したステップＳ８４におけるＰＡＴ（プログラムアソシエーションテーブル）によるＦＦ処理は、図２３に示すように処理される。

ＰＡＴによるＦＦ処理がステップＳ１０１で開始されると、ステップＳ１０２に示すように転送されたＶＯＢＵ（ＳＯＢＵ）がセル中の最後のＶＯＢＵ（ＳＯＢＵ）かどうかが判断される。最後のＶＯＢＵ（ＳＯＢＵ）の場合には、ステップＳ１０４に示すように次のセルの先頭のＶＯＢＵ（ＳＯＢＵ）のスタートアドレスが読み出される。転送されたＶＯＢＵ（ＳＯＢＵ）が最後のＶＯＢＵ（ＳＯＢＵ）でない場合には、ステップＳ１０３に示すように２つ先のＶＯＢＵ（ＳＯＢＵ）のスタートアドレスが読み出される。

次に、ステップＳ１０５に示すようにＩピクチャ再生割り込みフラグがクリアされ、ドライブ部５１にＶＯＢＵ（ＳＯＢＵ）のスタートアドレスおよびエンドアドレスを指定して読み込み命令を出し、Ｉピクチャのデコード終了割り込み、すなわち、ＳＴＢ部からの割り込みを待つこととなる。

ステップＳ１０６において、Ｉピクチャ再生の割り込みがある場合には、再びステップＳ１０５に戻されることとなる。Ｉピクチャ再生の割り込みがなく、転送が終了した後は、ステップＳ１０７に示すようにストップ或いはプレーのキー入力があったか否かがチェックされる。キー入力がない場合には、ステップＳ１０６に戻される。

ステップＳ１０８において、入力されたキーがストップ（ＳＴＯＰ）か否かが確認される。ストップの場合には、ステップＳ１０９においてドライブ部５１に停止命令が与えられて、ステップＳ１１０に示すように、再生終了の処理（図１８のステップＳ５４）がなされる。

入力されたキーがプレー（ＰＬＡＹ）の場合には、ステップＳ１１１に示すように次のＶＯＢＵ（ＳＯＢＵ）のＩピクチャスタートアドレスで読み出し命令がそれぞれドライブ部５１に与えられ、ステップＳ１１２に示すようにそのアドレスでデータの読み出しがが開始され、次々にデータが読み出される。その後ステップＳ１１３に示すように図１８のステップＳ４８に戻され、ＦＦ再生の処理が終了される。

次に、この発明の一実施の形態に係るストリームデータについて説明をする。

図２４は、ストリームデータ（図１のＭＰＥＧ２トランスポートストリームに対応）のデータ構造を説明する図である。

ストリームデータは、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（ＳＯＢ）としてまとまって記録されている。図２４（ｆ）ではその内の１個のＳＯＢについて示され、ＳＯＢ＃Ａ２９８で表現されている。

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

この実施の形態では、１個もしくは複数のＥＣＣブロック単位でストリームブロックが構成される。そして、このストリームブロック単位で、ストリーム情報の記録および／または部分消去が行なわれる。この実施の形態では、何個のＥＣＣブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて変わる。

デジタル放送では、１個のトランスポンダに、複数の番組がパケット化された形で時分割されて転送されてくる。例えば第２の番組を情報記憶媒体に記録する場合には、図１４のＳＴＢ部８３で番組２のトランスポートパケット（図３のＴＳパケット）のみが抽出される。その時、ＳＴＢ部８３では、各トランスポートパケットを受信した時刻情報を、タイムスタンプ（図３のＡＴＳ）の形で付加する。

その後、ＩＥＥＥ１３９４の転送方式によって図１４のフォーマッタ部９０にデータを転送する場合には、上記タイムスタンプ（ＡＴＳ）とトランスポートパケット（ＴＳパケット）の組が細かく分割（segmented）されて転送される。このフォーマッタ部９０では、ＩＥＥＥ１３９４で転送されてきたストリームデータが図２４（ａ）の形に一旦戻されて、図１４の情報記憶媒体５０に記録される。

すなわち、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダおよびＰＥＳヘッダが配置される（図２４（ｃ）、図３９参照）。各ストリームブロック先頭のセクタのみ、ＰＥＳヘッダの直後にストリームブロックヘッダ１１が記録される。各ストリームブロックの２番目以降のセクタでは、ＰＥＳヘッダの直後に、ストリームブロックヘッダではなく、セクタデータヘッダ１２、１３が記録される。

図２４（ｃ）（ｉ）のデータエリア２１、２２、２３、２４には、図２４（ａ）に示したタイムスタンプ（ＡＴＳ）、トランスポートパケットが逐次詰め込まれる。

ただし、図２４（ｂ）の例では、１個のトランスポートパケットｄが２つのセクタ（Ｎｏ．０とＮｏ．１）に跨って記録されている。

このように１つのトランスポートパケットを複数セクタに分けて記録することにより、１個のセクタサイズよりも大きなサイズを持つパケットを記録できるようになる。

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

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

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

この発明では、１個のパケットを、複数のデータエリアに連続して跨るように記録できるようになっている。こうすることで、デジタル放送などのように１個のデータエリア内に複数個のトランスポートパケットが記録される場合だけでなく、ＩＳＤＮのロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるようになる。

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

ストリームブロック内に余り部分が生じた場合には、パディングデータ（データが未記録である領域と認識できる情報）が記録される。すなわち図２４（ｂ）（ｅ）のように、ストリームブロック＃１内の最後のトランスポートパケットｆの後ろにエンドコード３１が配置され、残りの部分がパディングエリア３６とされる。

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

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

上記セクタデータヘッダと同様な情報が、ストリームブロックヘッダ１１内のセクタデータヘッダ情報６１３（図２５）にも記録されている。

ストリームブロック全体に関する情報が記録されているストリームブロック情報６１２内の情報は、以下のものから構成されている：
＊レコードタイム６２２（情報記憶媒体に記録した年月日と時刻情報）；
＊トランスポートパケット属性６２３（トランスポートパケットに関する属性情報）；
＊ストリームブロックサイズ６２４（該当するストリームブロックのデータサイズ（ＥＣＣブロック数で記載））；
＊ストリームブロック時間差６２５（該当するストリームブロック内の時間範囲情報）。

このストリームブロック時間差は、図２４（ｂ）を例にとれば、
［ストリームブロック時間差］＝［ストリームブロック＃２内で最初にくるタイムスタンプ値］−［タイムスタンプａの値］
で計算される。

図１４のフォーマッタ部９０は、図２４（ａ）の形で入力されたストリームデータを、図２４（ｃ）（ｉ）の形に変換して、Ｄ−ＰＲＯ部５２へ入力する。

Ｄ−ＰＲＯ部５２は、１６セクタ毎に入力データをまとめてＥＣＣブロックにして、ディスクドライブ部５１へ送る。

ただし、ディスクドライブ部５１において記録準備ができていない場合には、送られてきたＥＣＣブロックデータを一時記憶部５３へ転送して一時記憶し、記録準備ができるまで待つ。ディスクドライブ部５１において記録準備ができた段階で、一時記憶部５３に一時記憶されたデータが読み出しされて、情報記憶媒体への記録が開始される。ここで、一時記憶部５３は高速アクセスで数分以上の記録データを保持できるように、大容量メモリになっている。

この発明の一実施形態におけるストリームデータ記録再生装置（図１４）内での信号の流れは、以上のようになっている。

上記の説明で示したように情報記憶媒体５０に記録されるストリームデータはフォーマッタ部９０内で図２４（ｃ）（ｉ）の構造に変換される。

この発明の一実施形態では、同一のトランスポートパケットが異なるストリームブロックに跨って記録されることが禁止される場合、バッファメモリに一時記録されたタイムスタンプとパケットデータをストリームブロック毎に切り分ける際に、タイムスタンプとトランスポートパケットの組が完全に１個のストリームブロック内に収まるようにする必要がある。

一方、この発明の一実施形態では、同一のトランスポートパケットを、異なるセクタ（例えば図２４（ｄ）のＮｏ．０とＮｏ．１）に跨って記録することができる。その場合、セクタ毎に分割する処理では、各データエリア２１、２２、２３、２４に割り当てられた所定サイズに従って、無造作に分割が行われる。

デジタル放送では、映像情報はＭＰＥＧ２規格に従って圧縮され、そのＩ、Ｂ、Ｐピクチャー情報が、異なるトランスポートパケットに記録されて転送されてくる。

トランスポートパケット内は、トランスポートパケットヘッダおよびペイロードで構成されている。

Ｉピクチャー情報が記録されている最初のトランスポートパケットでは、ランダムアクセスインジケータ（図１（ｃ）のＡＵＳＭ対応）に”１”のフラグが立つ。また、Ｂ、Ｐピクチャー情報が記録されている最初のトランスポートパケットには、ペイロード単位開始インジケータに”１”のフラグが立つ。

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

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

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

この場合、図２５（ｅ）の各マッピングテーブルは「ｎビットデータ」からなる。そして、ストリームブロック内に前から並んでいる個々のトランスポートパケットに対して、この「ｎビットデータ」それぞれの１ビットずつが割り当てられている。

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

図２４（ｃ）（ｉ）のセクタデータヘッダ１２、１３は、データエリア２１、２２、２３、２４内のデータ配列情報を示す。

これらのセクタデータヘッダは、図２６に示すように、最初のアクセスポイント６５１およびトランスポートパケット接続フラグ６５２で構成されている。

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

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

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

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

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

この発明の一実施の形態では、基本的にストリームブロック先頭位置から再生は開始される。が、希なケースとして、ストリームブロック内の２番目以降のＥＣＣブロック先頭位置から再生が開始される場合もあり得る。

図２４において同一のトランスポートパケットｄが２個のセクタ（セクタＮｏ．０とセクタＮｏ．１）に跨って記録されている例に示すように、２番目以降のＥＣＣブロック先頭位置から再生を開始した場合には、何処に次のタイムスタンプ情報が記録されているかを知る必要がある。

そのために、各セクタの先頭位置に独自のヘッダー情報（図２６（ａ）のセクタデータヘッダ）を配置させる。その独自ヘッダー情報中に最初のアクセスポイント６５１を記録することで、ストリームブロック内の２番目以降のＥＣＣブロックの先頭位置から、容易に再生を開始することができる。

ＳＯＢとは、オリジナルＰＧＣに属するストリームデータである。ＳＯＢのデータ構造は、「動画および関連オーディオの一般的な符号化システム（ＩＳＯ／ＩＥＣ１３８１８ー１）」に記述されたプログラムストリームに従っている。ＳＯＢは１種類のデータ、すなわちストリームデータのみで構成されている。

ＳＯＢのデータ構造は、ストリームパックのシーケンスで定義される。このストリームパックは、一定サイズ（２０４８バイト）を持っている。このサイズはＤＶＤディスクファミリの論理ブロックサイズと同じである。各ストリームパックは論理ブロック内に記録される。

図２７は、ストリームオブジェクト（ＳＯＢ）に対するＭＰＥＧ規格上の制約を説明する図である。

すなわち、（１）ＳＯＢはシステムヘッダを持たず、（２）ＳＯＢの最初のパック内のシステムクロックリファレンス（ＳＣＲ）は任意の値を取ることができ、（３）ＭＰＥＧのプログラムエンドコードは持たず、（４）ストリームｉｄは全てのＰＥＳパケット内においてＢＦｈ（プライベートストリーム２）に等しい。

ナビゲーションデータとは、任意のビットストリームに対する記録、再生および編集の制御を行なうためのデータである。ＤＶＤストリーム記録においては、ナビゲーションデータは「ストリーマ情報（ＳＴＲＩ）」と呼ばれる。

図２８は、ＤＶＤストリーマ情報（ＳＴＲＩ）内のナビゲーションデータ（図９の制御情報２５に対応）の構造を説明する図である。図２８に示すように、ストリーマ情報ＳＴＲＩは、以下の情報で構成されている。

すなわち、（１）ストリーマビデオマネージャ情報（ＳＴＲ＿ＶＭＧＩ）と、（２）ストリームファイル情報テーブル（ＳＦＩＴ）と、（３）オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）と、（４）ユーザ定義ＰＧＣ情報テーブル（ＵＤ＿ＰＧＣＩＴ）と、（５）テキストデータマネージャ（ＴＸＴＤＴ＿ＭＧ）と、（６）アプリケーションプライベートデータマネージャ（ＡＰＤＴ＿ＭＧ）とによって、ＳＴＲＩは構成されている。

図２８のＳＴＲ＿ＶＭＧＩ、ＳＦＩＴ、ＯＲＧ＿ＰＧＣＩ、ＵＤ＿ＰＧＣＩＴ、およびＴＸＴＤＴ＿ＭＧは、その順で、ＳＲ＿ＭＡＮＧＲ．ＩＦＯという名のファイルに記録される。

一方、図２８のＡＰＤＴ＿ＭＧは、ＳＲ＿ＡＤＡＴＡ．ＤＡＴという名のファイルに記録される。

図２８のＳＴＲＩのサイズが５１２ｋバイトを越えない限りは、”００ｈ”等で符号化されたスタッフィングを上記（１）〜（６）の情報テーブル間に挿入するしないは自由である。ただし、このようなスタッフィングを（１）〜（６）の情報テーブル内に挿入することはできない。

なお、ＳＲ＿ＭＡＮＧＲ．ＩＦＯというファイルに記述された情報の多くは、ストリーマ装置（図１４等）のシステムメモリに格納されることが想定されている。

図２８のストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩは、ビデオマネージャ情報管理テーブル（ＶＭＧＩ＿ＭＡＴ）およびプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）により構成されている。

図２９は、図２８に示されたストリームファイル情報テーブル（ＳＦＩＴ）の構造を説明する図である。

ストリームファイル情報テーブルＳＦＩＴは、ストリーマの動作に直接関与する全てのナビゲーションデータを含んでいる。すなわち、（１）ストリームファイル情報テーブル情報（ＳＦＩＴＩ）と、（２）１以上（ｎ個）のＳＯＢストリーム情報（ＳＯＢ＿ＳＴＩ＃ｎ）と、（３）ストリームファイル情報（ＳＦＩ）とによって、ＳＦＩＴは構成されている。

上記ストリームファイル情報テーブル情報ＳＦＩＴＩは、ストリームファイルの数を示すＳＦＩ＿Ｎｓと、ＳＯＢストリーム情報の数を示すＳＯＢ＿ＳＴＩ＿Ｎｓと、ＳＦＩＴの終了アドレスを示すＳＦＩＴ＿ＥＡと、ＳＦＩの開始アドレスを示すＳＦＩ＿ＳＡとを含んでいる。

図３０は、図２９に示されたストリームファイル情報（ＳＦＩ）の構造を説明する図である。

ストリームファイル情報ＳＦＩは、（１）ストリームファイル一般情報（ＳＦ＿ＧＩ）と、（２）１以上（ｎ個）のＳＯＢ情報サーチポインタ（ＳＯＢＩ＿ＳＲＰ＃ｎ）と、（３）１以上（ｎ個）のＳＯＢ情報（ＳＯＢＩ＃ｎ）とで、構成されている。

図３１は、図３０に示されたストリームファイル一般情報（ＳＦ＿ＧＩ）の内容を説明する図である。

ストリームファイル一般情報ＳＦ＿ＧＩは、ＳＯＢ情報の数を示すＳＯＢＩ＿Ｎｓと、ＳＯＢＵ１個あたりのセクタ数によりＳＯＢＵのサイズを示すＳＯＢＵ＿ＳＩＺと、マッピング時間単位シフトを示すＭＴＵ＿ＳＨＦＴとを含んでいる。

ＳＯＢＵ＿ＳＩＺはＳＯＢＵのサイズをセクタ数で記述したもので、固定値（３２）を持つ。このことは、各マッピングリストにおける最初のエントリが、ＳＯＢの最初の３２セクタ内に含まれるアプリケーションパケットに関係していることを、意味する。また、各マッピングリストにおける２番目のエントリは次の３２セクタ内に含まれるアプリケーションパケットに関係している。以下同様である。

上記マッピング時間単位シフトＭＴＵ＿ＳＨＦＴは、ＰＡＴ記述フォーマットに対するマッピングリストエントリのＬＳＢ（リーストシグニフィカントビット）の重み付けを記述したものである。このＭＴＵ＿ＳＨＦＴは１８と記述される。

図３２は、図３０に示されたストリームオブジェクト情報（ＳＯＢＩ＃）の構造を説明する図である。

図３２に示すように、各ストリームオブジェクト情報ＳＯＢＩは、（１）ＳＯＢＩ一般情報（ＳＯＢＩ＿ＧＩ）と、（２）マッピングリスト（ＭＡＰＬ）と、（３）アクセスユニットデータ（ＡＵＤ）とで構成される（ＡＵＤはオプション）。

図３３は、図３２に示されたストリームオブジェクト情報一般情報（ＳＯＢＩ＿ＧＩ）の内容を説明する図である。

図３３に示すように、ストリームオブジェクト情報一般情報ＳＯＢＩ＿ＧＩは、（１）ＳＯＢ形式を示すＳＯＢ＿ＴＹと、（２）ＳＯＢ記録時間を示すＳＯＢ＿ＲＥＣ＿ＴＭと、（３）ＳＯＢストリーム情報番号を示すＳＯＢ＿ＳＴＩ＿Ｎと、（４）アクセスユニットデータフラグを示すＡＵＤ＿ＦＬＡＧＳと、（５）ＳＯＢ開始ＡＰＡＴを示すＳＯＢ＿Ｓ＿ＡＰＡＴと、（６）ＳＯＢ終了ＡＰＡＴを示すＳＯＢ＿Ｅ＿ＡＰＡＴと、（７）該当ＳＯＢの最初のＳＯＢＵを示すＳＯＢ＿Ｓ＿ＳＯＢＵと、（８）マッピングリストエントリの数を示すＭＡＰＬ＿ＥＮＴ＿Ｎｓとを含んでいる。

上記ＳＯＢ＿ＴＹは、一時消去（ＴＥ）状態を記述したビットおよびコピー世代管理システムを記述したビットを含むことができる。

上記ＳＯＢ＿ＲＥＣ＿ＴＭは、ＤＶＤストリーム記録の日時記述フォーマットにより関連ＳＯＢの記録時間を記述したものである。

上記ＳＯＢ＿ＳＴＩ＿Ｎは、該当ＳＯＢに対して有効なＳＯＢ＿ＳＴＩのインデックスを記述したものである。

上記ＡＵＤ＿ＦＬＡＧＳは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）が存在するかどうか、また存在するならどんな種類のＡＵＤが存在するのかを記述したものである。ＡＵＤが存在する場合は、ＡＵＤ＿ＦＬＡＧＳにより、ＡＵＤの特性の幾つかが記述される。

ＡＵＤ自体は、テーブル（ＡＵＳＭ）を含む一般情報（ＡＵ＿ＧＩ）、およびオプションテーブル（ＡＵＥＭ、ＰＴＳＬ）からなっている（図３４参照）。

上記ＳＯＢ＿Ｓ＿ＡＰＡＴは、ＳＯＢの開始アプリケーションパケット到着時間を記述したものである。すなわち、そのＳＯＢに属する最初のパケットのパケット到着時間が、ＳＯＢ＿Ｓ＿ＡＰＡＴにより記述される。ＳＯＢ＿Ｓ＿ＡＰＡＴは、ＤＶＤストリーム記録のＰＡＴ記述フォーマットにより記述される。

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

上記ＳＯＢ＿Ｅ＿ＡＰＡＴは、ＳＯＢの終了アプリケーションパケット到着時間を記述したものである。すなわち、そのＳＯＢに属する最後のパケットのパケット到着時間が、ＳＯＢ＿Ｅ＿ＡＰＡＴにより記述される。ＳＯＢ＿Ｅ＿ＡＰＡＴは、ＤＶＤストリーム記録のＰＡＴ記述フォーマットにより記述される。

上記ＳＯＢ＿Ｓ＿ＳＯＢＵは、開始ＳＯＢＵの数、つまりＳＯＢの最初のアプリケーションパケットに含まれるＳＯＢＵの数を記述したものである。

上記ＭＡＰＬ＿ＥＮＴ＿Ｎｓは、ＳＯＢＩ＿ＧＩに続くマッピングリストエントリの数を記述したものである。

図３４は、図３２に示されたアクセスユニットデータ（ＡＵＤ）の構造を説明する図である。

アクセスユニットデータＡＵＤ（オプション）は、（１）アクセスユニット一般情報（ＡＵ＿ＧＩ）と、（２）アクセスユニット終了マップ（ＡＵＥＭ）と、（３）再生タイムスタンプリスト（ＰＴＳＬ）とを含むことができる。これらのパーツのどれが存在するかは、ＳＯＢＩ＿ＧＩのＡＵＤ＿ＦＬＡＧＳにより示すことができる。

前述したＳＯＢＩ＿ＧＩのＡＵＤ＿ＦＬＡＧＳ（図３３）がアクセスユニットデータの存在を示すときは、ＡＵ＿ＧＩだけが存在する。

図３５は、図３４に示されたアクセスユニット一般情報（ＡＵ＿ＧＩ）の内容を説明する図である。

アクセスユニット一般情報ＡＵ＿ＧＩは、アクセスユニットの数を示すＡＵ＿Ｎｓと、アクセスユニット開始マップを示すＡＵＳＭとを含んでいる。

上記ＡＵ＿Ｎｓは、該当ＳＯＢに対するアクセスユニット数を記述したものである。同時に、ＡＵＳＭがアクセスユニットの存在を示す場合において、このＡＵ＿Ｎｓは、（アクセスユニットの）ロケーションの数も記述している。

上記アクセスユニット開始マップＡＵＳＭは、該当ＳＯＢのどのＳＯＢＵがアクセスユニットを含むのかを示すものである。ＳＯＢの各ＳＯＢＵに対しては、ＡＵＳＭのエレメントは１個だけ存在する。それゆえ、ＡＵＳＭはマップリストエントリ数（ＭＡＰＬ＿ＥＮＴ＿Ｎｓ）のエレメントで構成されるとも言える。

各ＡＵＳＭエレメントは、対応ＳＯＢＵ内（あるいはその後のＳＯＢＵ内）の何処かで始まるアクセス可能なアクセスユニットを示している。ＡＵ＿Ｎｓアクセスユニットは、ＡＵＳＭにより厳密に示されるもので、ビット”１”となっているＡＵＳＭのＡＵ＿Ｎｓビットに等しい。

ＡＵＳＭはバイトアラインされている必要がある。もし連鎖状のＡＵＳＭエレメントが８の整数倍のビット数でない（バイトアラインされていない）ときは、このＡＵＳＭの最終バイトの残りのＬＳＢ（１または複数のＬＳＢ）にビット”０”のパッドを当てて、連鎖状のＡＵＳＭエレメントが８の整数倍のビット数となる（バイトアラインされてる）ようにする。

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

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

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

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

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

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

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

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

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

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

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

図３８は、ストリームパック（図２〜図４のＴＳパックに対応）の構造を説明する図である。

図示するように、１つのストリームパック（２０４８バイト）は、パックヘッダ（１４バイト）とストリームＰＥＳパケット（２０３４バイト）とで構成されている。

ストリームパックのパックヘッダは１４バイトで構成される。このパックヘッダには、最初の４バイト（０００００１ＢＡｈ）にパックスタートコードが記録され；次の６バイトに、プロバイダが定義した、システムクロックリファレンスＳＣＲの基準（トータル３２ビットのＳＣＲ＿ｂａｓｅ）、複数のマーカビットおよびシステムクロックリファレンスＳＣＲの拡張（９ビットのＳＣＲ＿ｅｘｔｅｎｓｉｏｎ）が記録され；次の３バイト（０１８９Ｃ３ｈ）にプログラム多重化レート（２２ビットのｐｒｏｇｒａｍ＿ｍｕｘ＿ｒａｔｅ）と複数のマーカビットが記録され；最後の１バイト（Ｆ８ｈ）には、パックスタッフィング長（３ビットのｐａｃｋ＿ｓｔｕｆｆｉｎｇ＿ｌｅｎｇｔｈ）が記録され、さらに５ビットの予約エリアが設けられている。

ここで、ＳＣＲ＿ｂａｓｅの３２ビット目はゼロにセットされる。また、ｐｒｏｇｒａｍ＿ｍｕｘ＿ｒａｔｅは１０．０８Ｍｂｐｓにセットされる。

なおストリーム記録ではアプリケーションが自分でスタッフィングを行なう（図３９を参照して後述）ので、ＤＶＤＲＯＭビデオあるいはＤＶＤビデオレコーダ（ＤＶＤ−ＶＲ）のようにパック長の調整を行なう必要はない。すなわち、ストリーム記録においては、ストリームパケットが常に必要な長さを持っていると想定してよい。

一方、ストリームパックのストリームＰＥＳパケットは、次のようなデータ構造を持っている。

図３９は、図３８に示されるストリームＰＥＳパケット内のストリームデータエリアの構造を説明する図である。

図示するように、１つのストリームＰＥＳパケット（２０３４バイト）は、ＰＥＳヘッダ（６バイト）と、サブストリームＩＤ（１バイト）と、ストリームデータエリア（２０２７バイト）とで構成されている。

ストリームＰＥＳパケットのＰＥＳパケットヘッダには、最初の３バイト（０００００１ｈ）にパケットスタートコードプリフィックス（２４ビットのｐａｃｋｅｔ＿ｓｔａｒｔ＿ｃｏｄｅ＿ｐｒｅｆｉｘ）が記録され；次の１バイトにストリームＩＤ（８ビットのｓｔｒｅａｍ＿ｉｄ＝１０１１１１１１ｂ；プライベートストリーム２を示す）が記録され；次の２バイト（０７ＥＣｈ）にＰＥＳパケット長（ＰＥＳ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈ）が記録され；最後の１バイトにサブストリームＩＤ（８ビットのｓｕｂ＿ｓｔｒｅａｍ＿ｉｄ＝００００００１０ｂ；ストリーム記録データを示す）が記録される。

図３９に示すストリームパケット内のストリームデータエリア（２０２７バイト）は、アプリケーションヘッダ（９バイト）と、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、アプリケーションパケットエリアとで構成されている。

図３９のアプリケーションパケットエリアは、アプリケーションタイムスタンプ（図３あるいは図２４のＡＴＳに対応）をそれぞれが持つ１以上のアプリケーションパケットで構成される。

このアプリケーションパケットエリアは、図３（ｄ）と同様に構成できる（図３のＴＳパケットを図３９ではアプリケーションパケットに読み替える）。すなわち、アプリケーションパケットエリアの先頭にパーシャルアプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾にパーシャルアプリケーションパケットが記録される。

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

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

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

それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを記述するように定義されいる。

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

一方、ＳＯＢ内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割（スプリット）されてもよい。図３９のパーシャルアプリケーションパケットは、この分割（スプリット）により生じたアプリケーションパケットを示している。

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

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

すなわち、上記自動化メカニズムが、図３８の説明の所で述べた「アプリケーションが自分でスタッフィングを行なう」ことに対応する。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。

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

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

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

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

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

図４０は、図３９に示されたストリームデータエリア先頭のアプリケーションヘッダの内容を説明する図である。

このアプリケーションヘッダは、１バイトのＶＥＲＳＩＯＮ（０１ｈ）と、１バイトのＡＰ＿Ｎｓと、２バイトのＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴと、２ビットのＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯ（００ｂ、１０ｂ、あるいは１１ｂ）と、１ビットのＣＣＩ＿ＥＳＣ用予約エリアと、５ビットの予約エリアと、２バイトのＳＥＲＶＩＣＥ＿ＩＤと、１バイトのＭＡＸ＿ＢＲ＿ＬＯＧ２と、１バイトのＳＭＯ＿ＢＳ＿ＬＯＧ２とを、含んでいる。

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

ＡＰ＿Ｎｓには、該当ストリームパケット内で開始されるアプリケーションパケットの数が記述される。もしアプリケーションタイムスタンプの最初のバイトがストリームパケット内に格納されているなら、アプリケーションパケットはそのストリームパケット内で開始されると考えてよい。

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

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

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

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

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

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

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

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

ＭＡＸ＿ＢＲ＿ＬＯＧ２には、「ｌｅａｋｙ ｂｕｃｋｅｔ ｆｌｏｗ ｃｏｎｔｒｏｌ ｍｏｄｅｌ」における出力ビットレートパラメータのバイナリアルゴリズムが記述される。

ＳＭＯ＿ＢＳ＿ＬＯＧ２には、「ｌｅａｋｙ ｂｕｃｋｅｔ ｆｌｏｗ ｃｏｎｔｒｏｌ ｍｏｄｅｌ」におけるバッファサイズパラメータのバイナリアルゴリズムが記述される。

以上説明したようにこの発明によれば、ＡＵＳＭ、ＡＵＥＭ、および／またはサポート情報を記録することができ、それにより、よりユーザフレンドリーなデータ管理ができる。

なお、この発明は前述した実施の形態に限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、この構成要件が削除された構成が発明として抽出され得る。

２５…制御情報；２７…ＶＯＢ一般情報（ＳＦ＿ＧＩ）；２８…ＶＯＢＵ情報テーブル（ＳＦＩ）；２９…ＶＯＢＵ情報（ＳＯＢＩ）；３１…ＶＯＢ（ＳＯＢ）；３２…セル；３３…ＶＯＢＵ（ＳＯＢＵ）；３４…ＴＳパック（ストリームパケット）；３８…ＴＳパケット（アプリケーションパケット）；３９…ＴＳパケットの一部（パーシャルアプリケーションパケット）；５０…ＲＡＭディスク（記録媒体）；５１…ディスクドライブ部；５９…デコーダ部；７９…エンコーダ部；８０…主ＭＰＵ；８０Ａ…ワークＲＡＭ部；８０Ｂ…管理データ作成部；８０Ｃ…サポート情報検出部；８０Ｄ…サポート情報追加部；８３…ＳＴＢ部；９０…フォーマッタ部。

Claims (5)

1. ストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、
   トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、
   １以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、
   前記ストリームデータはＭＰＥＧのＩピクチャ情報を含んでおり、
   前記管理情報が、前記Ｉピクチャ情報の先頭に関するデータを含む情報媒体。
2. ストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、前記ストリームデータはＭＰＥＧのＩピクチャ情報を含んでおり、前記管理情報が、前記Ｉピクチャ情報の先頭に関するデータを含む情報媒体を用いる記録方法において、
   前記データ領域に前記ストリームデータを記録し、前記管理領域に前記管理情報を記録する記録方法。
3. ストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、前記ストリームデータはＭＰＥＧのＩピクチャ情報を含んでおり、前記管理情報が、前記Ｉピクチャ情報の先頭に関するデータを含む情報媒体を用いる再生方法において、
   前記管理領域から前記管理情報を再生し、前記データ領域から前記ストリームデータを再生する再生方法。
4. ストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ情報記憶媒体において、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第１データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第２データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第３データ単位として表現したときに、１以上の前記第１データ単位を含む前記第２データ単位を１以上含んで構成される前記第３データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成され、前記ストリームデータはＭＰＥＧのＩピクチャ情報を含んでおり、前記管理情報が、前記Ｉピクチャ情報の先頭に関するデータを含む情報媒体を用いる再生装置において、
   前記管理領域から前記管理情報を再生する手段と、前記データ領域から前記ストリームデータを再生する手段を具備した再生装置。
5. 前記ストリームデータがＭＰＥＧストリームを含む請求項５に記載の情報媒体。

Images