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

Description

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

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

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

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

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

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

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

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

デジタルＴＶ放送では、映像情報を含むストリームデータの伝送方式としてＭＰＥＧのトランスポートストリームが採用されており、映像情報はたとえば１８８バイト毎のアプリケーションパケット毎に纏められて伝送されてくる。それに対して、ＤＶＤ−ＲＡＭディスクなどＤＶＤファミリの記録メディアを用いた場合には、最小記録単位が２０４８バイトであるセクタ毎に記録を行なう必要がある。しかしながら、
（１）たとえば１８８バイト毎のアプリケーションパケットの情報を２０４８バイトのセクタ毎に効率良く情報媒体に記録する方法が未だ決まっていない；
（２）情報媒体上に記録したストリームデータをデジタルＴＶ放送で受信したときのタイミングを保持したまま再生する方法が未だ決まっていない；
と言う問題がある。

さらに、デジタルＴＶ放送以外に、ローカルエリアネットワーク（ＬＡＮ）あるいはＩＳＤＮ等のデジタル電話回線においてパケット構造を持って転送されるデジタルデータも、ストリーマを用いて記録したいというニーズがある。

しかしながら、
（３）デジタルＴＶ以外のデジタルデータも記録できる汎用性のある記録方法が存在しないと言う問題もある。

この発明は上記事情に鑑みなされたもので、その目的は、効率良くストリームデータを情報媒体に記録するとともに、デジタルＴＶ放送で受信したときの各アプリケーションパケット間の転送タイミングを保持したまま情報媒体からストリームデータを再生できるような情報媒体上のデータ構造（記録フォーマット）およびこのデータ構造を利用して記録あるいは再生が行われる情報媒体を提供することである。

この発明の他の目的は、上記データ構造を用いてストリームデータを記録する方法を提供することである。

この発明のさらに他の目的は、上記データ構造により記録されたストリームデータを再生する方法を提供することである。

この発明の一実施の形態に係るデータ構造では、記録されたビットストリームに対する再生データを表すストリームオブジェクト（ＳＯＢ）が１以上集まってストリームデータが構成され、前記ストリームオブジェクト（ＳＯＢ）が１以上のストリームパック（Ｓ＿ＰＣＫ）で構成され、前記ストリームパック（Ｓ＿ＰＣＫ）はパックヘッダとストリームパケット（Ｓ＿ＰＫＴ）とで構成される。前記パックヘッダは所定の時間情報（ＳＣＲ）を含み、前記ストリームパケット（Ｓ＿ＰＫＴ）は所定のタイムスタンプ（ＡＴＳ）が付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）を１以上含む。そして、前記ストリームオブジェクト（ＳＯＢ）の記録中に（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が、前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプ（図１４のモディファイドタイムスタンプ；図１５のＡＴＳ）される。

この発明の他の実施の形態に係る記録方法では、記録されたビットストリームに対する再生データを表すストリームオブジェクト（ＳＯＢ）が１以上集まってストリームデータが構成され、前記ストリームオブジェクト（ＳＯＢ）が１以上のストリームパック（Ｓ＿ＰＣＫ）で構成され、前記ストリームパック（Ｓ＿ＰＣＫ）はパックヘッダとストリームパケット（Ｓ＿ＰＫＴ）とで構成される。前記パックヘッダは所定の時間情報（ＳＣＲ）を含み、前記ストリームパケット（Ｓ＿ＰＫＴ）は所定のタイムスタンプ（ＡＴＳ）が付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）を１以上含む。そして、前記ストリームオブジェクト（ＳＯＢ）を情報媒体（２０１）に記録するときに（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が、前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプ（図１０のＳ４のモディファイドタイムスタンプ；図２１〜図２３ではＳＴ１０６、ＳＴ２１２、ＳＴ３１２のタイムスタンプ）される。

この発明の他の実施の形態に係る再生方法では、記録されたビットストリームに対する再生データを表すストリームオブジェクト（ＳＯＢ）が１以上集まってストリームデータが構成され、前記ストリームオブジェクト（ＳＯＢ）が１以上のストリームパック（Ｓ＿ＰＣＫ）で構成され、前記ストリームパック（Ｓ＿ＰＣＫ）がパックヘッダとストリームパケット（Ｓ＿ＰＫＴ）とで構成され、前記パックヘッダが所定の時間情報（ＳＣＲ）を含み、前記ストリームパケット（Ｓ＿ＰＫＴ）が所定のタイムスタンプ（ＡＴＳ）が付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）を１以上含み、（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプされて前記ストリームオブジェクト（ＳＯＢ）が記録された情報媒体（２０１）を用いる。この媒体から記録情報を再生するとき、前記情報媒体（２０１）から再生された前記ローカル基準クロック（図５のＳＣＲ３０３、図１５のＳＣＲベース）に基づいて再生用の基準クロックが設定され（図１１のＳ３７）、前記設定された再生用の基準クロック（ＳＣＲ）に基づいて、前記情報媒体（２０１）から前記ビットストリームの内容が再生される。

この発明によれば、効率良くストリームデータを記録できる。

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

図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図１には、情報媒体（たとえば相変化記録方式、光磁気記録方式などを利用した光ディスク）上に記録するストリームデータのデータ構造（階層構造）と、その構築経過を示している。

情報媒体上に記録されるストリームデータ（図１（ｆ）のＳＴＲＥＡＭ．ＶＲＯ１０６）は、ストリームデータ内の映像情報のコンテンツ毎に、ストリームオブジェクト（ＳＯＢと略記される）としてまとまって記録されている。図１では、そのうちの２個のストリームオブジェクトについて詳細に示され、それらはストリームオブジェクト＃Ａ（ＳＯＢ＃Ａ）２９８とストリームオブジェクト＃Ｂ（ＳＯＢ＃Ｂ）２９９で表現されている。図１には、ＳＴＲＥＡＭ．ＶＲＯ１０６（ＳＯＢ＃Ａ・２９８、ＳＯＢ＃Ｂ・２９９、…）を構成するデータと、それが構築されるまでの途中のデータ構造が示されている。

ＳＯＢ＃Ａ・２９８は、図１（ｅ）（ｇ）に示すように、ストリームオブジェクトユニット（ＳＯＢＵと略記される）５１、５２、…で構成される。同様に、ＳＯＢ＃Ｂ・２９９は、ＳＯＢＵ５４、…、ＳＯＢＵ５７、…で構成される。

各ＳＯＢＵは、図１（ｄ）（ｈ）に示すように、複数のストリームパックで構成されている。ここでは、ＳＯＢ＃Ａ・２９８のＳＯＢＵ５１がストリームパックＮｏ．０、Ｎｏ．１、…Ｎｏ．３１で構成され、ＳＯＢ＃Ａ・２９８のＳＯＢＵ５２がストリームパックＮｏ．３２、Ｎｏ．３３、…Ｎｏ．３２ｎ−１で構成された例を示している。

ストリームパックＮｏ．０は、図１（ｃ）に示すように、パックヘッダ１と、ＰＥＳヘッダ＆サブストリームＩＤ６と、ロングアプリケーションヘッダ１１と、データエリア２１とで構成されている。他のストリームパックも同様に構成される。ここで、ロングアプリケーションヘッダ１１は記録媒体に記録が行われるときに付加されるものである。記録時には、図１（ｂ）に示すように、データエリア２１にはモディファイドタイムスタンプ（あるいはアプリケーションタイムスタンプ）およびアプリケーションパケットの組が１以上含まれる。

図１（ｂ）のモディファイドタイムスタンプは、デジタル放送で送られてきたオリジナルタイムスタンプ（図１（ａ））を、記録装置用として付け直したものである。オリジナルタイムスタンプは、ＩＥＥＥ１３９４の規格に基いて送信するときのタイムスタンプである。図１（ｂ）のアプリケーションパケットは、デジタル放送により送られてきたパケットそのものである。

次に、ストリームオブジェクト＃Ｂ（ＳＯＢ＃Ｂ）２９９側について説明する。ＳＯＢ＃Ｂ・２９９のＳＯＢＵ５４は、図１（ｇ）（ｈ）に示すように、ストリームパックＮｏ．３２ｎ、Ｎｏ．３２ｎ＋１、…Ｎｏ．３２ｎ＋１５で構成され、ＳＯＢ＃Ｂ・２９９のＳＯＢＵ５７はストリームパックＮｏ．３２ｎ＋１６、…Ｎｏ．３２ｎ＋１６ｍー２、パディングパック４０で構成されている。

ストリームパックＮｏ．３２ｎは、図１（ｉ）に示すように、パックヘッダ３と、ＰＥＳヘッダ＆サブストリームＩＤ８と、アプリケーションヘッダ（ショートアプリケーションヘッダ）１３と、データエリア２４とで構成されている。他のストリームパックも同様に構成できる。データエリア２４には、図１（ｊ）に示すように、タイムスタンプとアプリケーションパケットの組が１以上含まれる。

ＤＶＤ−ＲＡＭディスクなどの記録媒体にストリームデータを記録する場合には、２０４８ｋバイト毎のセクタを最小単位として、記録が行われる。ストリームデータの記録フォーマット（データ構造）では、図１（ｄ）、（ｈ）に示すように、セクタ毎にストリームパックを構成している。ストリームパックは、図１（ｃ）または図１（ｉ）に示すように、パックヘッダ、ＰＥＳヘッダ＆サブストリームＩＤと、ロングアプリケーションヘッダまたはショートアプリケーションヘッダと、データエリアとで構成される。

つまり、各ストリームパックの先頭位置には、パックヘッダ１、２、３、４とそれに続くＰＥＳヘッダ＆サブストリームＩＤ６、７、８、９が配置されている。また、実際のストリームデータが記録されているデータエリア２１〜２６と上記ＰＥＳヘッダ＆サブストリームＩＤ６〜９との間には、アプリケーションヘッダが配置されている。この発明の一実施の形態では、記録されるストリームデータの情報内容に応じて、このアプリケーションヘッダとして、ロングアプリケーションヘッダ１１、１２とショートアプリケーションヘッダ１３、１４との使い分けを行っている。

また、この発明の一実施の形態では、同一のストリームオブジェクト（ＳＯＢ＃Ａ・２９８またはＳＯＢ＃Ｂ・２９９）内では、全てのストリームパック内のアプリケーションヘッダのタイプ（ロングアプリケーションヘッダかショートアプリケーションヘッダか）が同一となっている。すなわち、図１（ｃ）に示すようにＳＯＢ＃Ａ・２９８内では全てロングアプリケーションヘッダ１１、１２が使用され、図１（ｉ）に示すようにＳＯＢ＃Ｂ・２９９内では全てショートアプリケーションヘッダ１３、１４が使用されている。

ロングアプリケーションヘッダ１１およびショートアプリケーションヘッダ１３の詳細については、図７および図８を参照して後述する。

図１に戻って説明を続ける。図１（ｂ）に示すように、デジタルＴＶ放送を受信したときに得られたアプリケーションパケットｄを情報媒体上に記録する場合、２個のストリームパックに分割記録することがある。これは、情報媒体の記録エリアを効率的に利用するためである。このときのアプリケーションパケットを部分アプリケーションパケットとして示している。この場合にはストリームパックＮｏ．１のデータエリア２２の開始位置には、部分アプリケーションパケットｄ２が配置記録される。

ストリームデータ再生時にストリームパックＮｏ．１（図１（ｄ））の情報から再生を開始する場合には、図示しないが、この部分アプリケーションパケットｄ２直後のモディファイドタイムスタンプ位置から再生開始する必要がある。したがって、再生装置の再生手段がこのモディファイドタイムスタンプに直接アクセス可能なように、ストリームパック内の最初に配置されたモディファイドタイムスタンプの先頭位置情報が、ロングアプリケーションヘッダ１１あるいはショートアプリケーションヘッダ１３内のフィールド３２５（図７、図８参照）に、バイト数で記録される。

この情報（ストリームパック内の最初に配置されたモディファイドタイムスタンプの先頭位置情報）と、モディファイドタイムスタンプのデータ長（図７、図８のフィールド３２２）の情報と、アプリケーションパケットのデータ長（図７、図８のフィールド３２３）の情報とから、図１（ｃ）のデータエリア２１内に記録されている所定番号のアプリケーションパケット位置を求めることができる。

図１（ｅ）（ｇ）に示すように、複数のストリームパックをまとめてストリームオブジェクトユニットＳＯＢＵ５１〜５７が形成されている。図１に示した実施の形態では、ＳＯＢ＃Ａ・２９８内の１個のＳＯＢＵ５１またはＳＯＢＵ５２は３２個のストリームパック（セクタ）から構成され、ＳＯＢ＃Ｂ・２９９内の１個のＳＯＢＵ５４またはＳＯＢＵ５７は１６個のストリームパック（セクタ）から構成されている。

最後のストリームパック内の最後に記録されたアプリケーションパケットｆ、ｚ（図１（ａ）（ｊ））の後ろには、図１（ｂ）（ｊ）に示すように、エンドコード３１、３２が記録される。これらのエンドコードの後ろには、全てが“１”または全てが“０”のデータで埋められたパディングエリア３６、３７が適宜設けられる。

ストリーム情報が最後に記録された最後のストリームパックがＳＯＢＵ５７の中央部に位置している場合には、同一ＳＯＢＵ５７内でそれ以降のセクタは図１（ｈ）に示すパディングパック４０になる。

ＳＯＢ＃Ｂ・２９９内でストリームデータが記録されている範囲を示すため、ＳＯＢ＃Ｂ・２９９の開始／終了アプリケーションパケットがストリームパック内に存在することを示すフラグが、ショートアプリケーションヘッダ１３内のフィールド３２７＊、３２８＊（図８参照）内に設けられる。

情報媒体上に記録されたアプリケーションパケットに対する検索情報としてモディファイドタイムスタンプ情報を用いて検索することができる。特に録画経過時間を利用して検索する場合、アプリケーションヘッダ内のフィールド３２９（図７、図８参照）に記述されているモディファイドタイムスタンプの基準クロック周波数の値が重要となる。そのため、この基準クロック周波数情報も、ロングアプリケーションヘッダ１１およびショートアプリケーションヘッダ１３内に記録されている。

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

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

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

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

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

有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報媒体に記録したデータを、「ストリームデータ」と呼ぶ。そのストリームデータそのものはＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯとそのバックアップファイルＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５である。

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

図３は、この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図である。図３（ａ）の情報媒体２０１の内周方向２０２の端部と外周方向２０３の端部とで挟まれた領域には、図３（ｂ）に示すように、リードインエリア２０４と、ファイルシステム情報が記録されているボリューム＆ファイル構造情報２０６と、データエリア２０７と、リードアウトエリア２０５が存在する。リードインエリア２０４はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア２０５は書替可能データゾーンで構成されている。データエリア２０７も書替可能データゾーンで構成されている。

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

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

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

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

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

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

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

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

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

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

ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯまたはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームデータは、１個以上のＥＣＣブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等がなされる。このストリームデータは、記録する情報の内容毎（たとえばデジタル放送での番組毎）にストリームオブジェクトと言うまとまりを作る。ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームオブジェクト（ＳＯＢ＃Ａ、ＳＯＢ＃Ｂ）毎の管理情報（オリジナルＰＧＣ情報２３３、ユーザ定義ＰＧＣ情報テーブル２３４等）は、ナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５（図４の最下部および図３（ｅ）（ｆ）参照）内に記録されている。

図４の各ストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９毎の管理情報（ＳＴＲＥＡＭ．ＩＦＯ１０５）は、図３（ｆ）（ｇ）に示すように、ストリームファイル情報テーブル（ＳＦＩＴ）２３２内のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３として記録されている。ストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、（ＳＯＢＩ）＃Ｂ・２４３それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報２５２を含んでいる。

ストリームデータの再生時には、１個以上のセルの連続で構成されるプログラムチェーン（ＰＧＣ）の情報（後述する図１７のＰＧＣＩ＃ｉに対応）が利用される。このＰＧＣを構成するセルの設定順にしたがって、ストリームデータを再生することができる。ＰＧＣには、ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６に記録された全ストリームデータを連続して再生することのできるオリジナルＰＧＣ２９０（図３（ｆ）ではＯＲＧ＿ＰＧＣＩ・２３３）と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義ＰＧＣ＃ａ・２９３、＃ｂ・２９６（図３（ｆ）ではＵＤ＿ＰＧＣＩＴ・２３４の中身に対応）の２種類が存在する。

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

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

図５は、図１に示されるパックヘッダの内部構造を例示する図である。パックヘッダ１は例えば１４バイトで構成されており、ここにはパック開始コード３０１、”０１”コード、システムクロックリファレンスＳＣＲ３０３、多重化レート（例えば８Ｍｂｐｓ）３０４、スタッフィング長３０５、およびスタッフィングバイト３０６のフィールドがあり、それぞれのフィールドに該当情報が記述されている。

ところで、ストリームオブジェクトＳＯＢの記録中にストリーマに入ってくるアプリケーションパケットＡＰ＿ＰＫＴは、ストリーマ内部のローカル基準クロックによりタイムスタンプされる。このタイムスタンプで示される時間がアプリケーションパケット到着時間ＡＰＡＴである。ＳＯＢ内の最初のパックに対しては、ストリーマ内部のローカル基準クロック（図５のＳＣＲ３０３または後述する図１５のＳＣＲベースに対応）は、そのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに等しくなる。

図６は、図１に示されるＰＥＳヘッダ＆サブストリームＩＤの内部構造を例示する図である。ＰＥＳヘッダ＆サブストリームＩＤ６は例えば６バイトで構成されており、ここにはパケット開始コード３１１、ストリームＩＤ３１２、”１１”コード３１３、ＰＥＳ・ＣＲＣフラグ３１４、ＰＥＳ拡張フラグ３１６、ＰＥＳヘッダ長３１６、サブストリームＩＤ３１７の各記述フィールドが存在する。

次に、ロングアプリケーションヘッダ１１とショートアプリケーションヘッダ１３の詳細について説明する。図７は、図１（ｃ）に示されるロングアプリケーションヘッダ１１（または１２）の内部構造を例示する図である。また、図８は、図１（ｉ）に示されるアプリケーションヘッダ／ショートアプリケーションヘッダ１３（または１４）の内部構造を例示する図である。

図７および図８の図示から分かるように、ロングアプリケーションヘッダ１１内のデータ内容の一部がショートアプリケーションヘッダ１３のデータ内容になっている。ストリームデータの内容に依存しない共通に必要な情報がショートアプリケーションヘッダ１３内に含まれており、全てのストリームデータを情報媒体上に記録するときにストリームデータと一緒にこのショートアプリケーションヘッダ１３の内容が記録される。

ところで、デジタルＴＶ放送の映像情報は、一般にＭＰＥＧ２を用いて情報圧縮されている。したがって、ストリームデータとしてデジタルＴＶ映像情報を情報媒体上に記録した場合、再生時にはＭＰＥＧ２固有の情報が必要となる。そこで、全てのストリームデータに共通なショートアプリケーションヘッダ１３の情報にデジタルＴＶ放送（ＭＰＥＧ２）の再生に必要な情報を付加した情報を、ロングアプリケーションヘッダ１１に持たせている。

以下、図７および図８を参照して、ロングアプリケーションヘッダ１１の情報内容およびショートアプリケーションヘッダ１３内の情報内容について、具体的に説明する。以下の説明において、特に断りがない限り、同じ参照番号のフィールドは、ロングアプリケーションヘッダ１１とショートアプリケーションヘッダ１３との間で共通である。

アプリケーションヘッダ１１、１３は、その内部にロングアプリケーションヘッダ１１の識別フラグを格納する１ビットフィールド３２６を持つ。この識別フラグが“１”のときはロングアプリケーションヘッダであることが示され、“０”のときはショートアプリケーションヘッダであることが示される。また、アプリケーションヘッダ１１、１３は、個々のストリームデータに対応したサービスＩＤ情報を格納するフィールド３３０も持つ。このＩＤ情報と別の場所に記録してあるサービス情報とのリンクをとることで、各ストリームデータ毎の固有のサービス情報を得ることができる。また、将来アプリケーションヘッダの情報内容を変更できるように、アプリケーションヘッダのバージョン番号がフィールド３２１に記録されている。

さらに、アプリケーションヘッダ１１、１３内には、モディファイドタイムスタンプのデータ長（バイト数）がフィールド３２２に記述される。またアプリケーションパケットのデータ長（バイト数）がフィールド３２３にバイト数で記述される。さらにストリームパケット内に存在するアプリケーションパケットの数がフィールド３２４に記述される。このアプリケーションパケット数は、ストリームパック内の最初に配置されたモディファイドタイムスタンプが指し示すアプリケーションパケットから数えた数である。さらにストリームパック内の最初に配置されたモディファイドタイムスタンプの先頭位置情報がフィールド３２５にバイト数で記述される。フィールド３２６には、ロングアプリケーションヘッダの識別フラグが記述される。

ここで、図８のフィールド３２７＊にはＳＯＢ＃Ｂ・２９９の開始アプリケーションパケットがストリームパック内に存在することを示すフラグが記述され、図８のフィールド３２８＊にはＳＯＢ＃Ｂ・２９９の終了アプリケーションパケットがストリームパック内に存在することを示すフラグが記述される。

同様に、図７のフィールド３２７にはＳＯＢ＃Ａ・２９８の開始アプリケーションパケットがストリームパック内に存在することを示すフラグが記述され、図７のフィールド３２８にはＳＯＢ＃Ａ・２９８の終了アプリケーションパケットがストリームパック内に存在することを示すフラグが記述される。

アプリケーションヘッダ１１、１３内のフィールド３２９には、モディファイドタイムスタンプの基準クロック周波数情報が記述される。

さらに、図７に示すロングアプリケーションヘッダ１１内のフィールド３３１には、最大ビットレート情報が記述される。これはデータ溢れ量を制御するモデルのための出力ビットレートパラメータである。また、ロングアプリケーションヘッダ１１内のフィールド３３２には、スムーズバッファサイズが記述される。これはデータ溢れ量を制御するモデル（ストリーマのスムージングバッファモデル）のためのバッファサイズパラメータ（バイト）である。

図７、図８ではモディファイドタイムスタンプ（図１（ｂ）参照）のデータ長（フィールド３２２）、モディファイドタイムスタンプの基準クロック周波数（フィールド３２９）を例示したが、それに限らず、この発明の実施の形態によっては、タイムスタンプの付け直しを行わず、受信直後のタイムスタンプをそのまま情報媒体上に記録することも可能である。その場合には、通常のタイムスタンプのデータ長（フィールド３２２）および／または通常のタイムスタンプの基準クロック周波数（フィールド３２９）の情報を用いることができる。

上記スムージングバッファモデルとは、ＳＯＢ内に記録されるアプリケーションデータの平均ビットレートおよび瞬間的な途切れを制限するために定義されたものである。パケットヘッダ、ＰＥＳヘッダ、アプリケーションヘッダ、アプリケーションタイムスタンプ、およびスタッフィングを含む完全なパックデータは、このモデルのスムージングバッファに入る。このスムージングバッファからアプリケーションパケットを取り除くに際しては、該当アプリケーションパケットの先頭バイトと先行アプリケーションパケットの最終バイトとの間に格納された全てのデータバイトが、スムージングバッファから瞬間的に削除される。

ＭＰＥＧ２プログラムストリームをスムージングバッファに導入でき、かつアプリケーションタイムスタンプにより規定され正しく再構成された再生タイミングに基づいてその全てのアプリケーションパケットをスムージングバッファから取り除くことができるようにＳＯＢが媒体（ＤＶＤ−ＲＡＭディスクなど）に記録されるなら、それはストリーマのスムージングバッファモデルにより与えられた制限に従うものと解釈される。この制限は、スムージングバッファのサイズおよびＭＰＥＧ２プログラムストリームの最大プログラム多重化レート（図５の３０４あるいは図１５（ｅ）のプログラム多重化レート）の最大値（１０．０８Ｍｂｐｓ）に応じて定めることができる。

記録（録画）中に、パックを形成するに十分なアプリケーションデータがスムージングバッファ内に貯まれば、直ちに、パックをスムージングバッファからトラックバッファに転送できる。そのための条件は、（１）パックがアプリケーションパケットにより完全に埋められるか、（２）システムクロックリファレンスＳＣＲとローカルクロック（２７ＭＨｚ）とのずれが所定のしきい値（秒数で表される時間値）を越えるかしたときに、満足される。

いま、先行パックのＳＣＲをＳＣＲ＿ｐｒｅｖとしてみる。この場合、アプリケーションパケットの開始が含まれない後続パックに対しては、”ＳＣＲ＝ＳＣＲ＿ｐｒｅｖ＋２０４８×８ビット／１０．０８ＭＨｚ”の関係から、それらパックのＳＣＲを求めることができる。

一方、アプリケーションパケットの開始を少なくとも１つ含む後続パックに対しては、”ＳＣＲ＝（ＳＣＲ＿ｐｒｅｖ＋２０４８×８ビット／１０．０８ＭＨｚ；あるいはＡＰＡＴ［４０…０］）の最大値”から、それらパックのＳＣＲを求めることができる。ここで、ＡＰＡＴとは、該当パック内で開始する先頭アプリケーションパケットの到着時間を指す。

ＳＯＢ内の最初のパックに対して、そのＳＣＲはそのパック内で開始する先頭アプリケーションパケットのＡＰＡＴと同じになる。このことを具体的に例示すれば、”ＳＣＲ［４０…０］＝ＡＰＡＴ［４０…０］”となる。このＳＣＲ［４０…０］の次のＳＣＲ［４１］はゼロとなる。なお、ＳＣＲ［４０…０］の［４０…０］はこのＳＣＲを構成する情報ビット（４０）〜（０）の内容を示し、ＡＰＡＴ［４０…０］の［４０…０］はこのＡＰＡＴを構成する情報ビット（４０）〜（０）の内容を示す。同様に、ＳＣＲ［４１］の［４１］はこのＳＣＲを構成する情報ビット（４１）の内容を示す。

ファームウエアのプログラミングで例示すれば、上述したことは、以下のように表現できる：
if (APAT[40...0] > (SCR_prev + 2048*8bits/10.08Mbps)), then
SCR[40...0] = APAT[40...0]
SCR[41] = 0
else
SCR[40...0] = (SCR_prev + 2048*8bits/10.08Mbps)[40...0]
SCR[41] = 0
endif
なお、再生中にスムージングバッファが満杯になれば、アプリケーションパケットを出力する処理を直ちに開始することができる。

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

このストリームデータ記録再生装置は、光ディスク装置（ストリーマ）４１５、ＳＴＢ装置４１６およびその周辺機器から構成される。周辺機器としては、ビデオミキシング部４０５、フレームメモリ部４０６、外部スピーカ４３３、パーソナルコンピュータ（ＰＣ）４３５、モニタＴＶ４３７、Ｄ／Ａコンバータ４３２、４３６、Ｉ／Ｆ部４３１、４３４等がある。

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

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

具体的には、データ転送インターフェイス部４１４のＩＥＥＥ１３９４受信側は、基準クロック発生部（ローカルクロック）４４０のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。このタイムカウント値（時間情報）に基づいて、ストリームデータをストリームブロック毎（あるいはＳＯＢＵ毎）に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはＰＧＣの切り分け情報を作成する。

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

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

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

情報媒体２０１に記録されたストリームデータ内のパックヘッダには、基準クロック（システムクロックリファレンスＳＣＲ）が記録されている。この媒体２０１に記録されたストリームデータ（ＳＯＢまたはＳＯＢＵ）を再生する場合において、基準クロック発生部４４０は、媒体２０１から再生された基準クロック（ＳＣＲ）に適合される（ＳＣＲの値が基準クロック発生部４４０にセットされる）。つまり、ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ（光ディスク装置４１５）内の基準クロック（基準クロック発生部４４０）を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスＳＣＲに合わせる。その後は、基準クロック発生部４４０のカウントアップは自動的に行われる。

ＳＴＢ部４１６は、衛星アンテナ４２１で受信したデジタル放送電波の内容を復調し、１以上の番組が多重化された復調データ（ストリームデータ）を提供するデモジュレータ４２２と、デモジュレータ４２２で復調されたデータから（ユーザが希望する）特定番組の情報を選択する受信情報セレクタ部４２３とを備えている。受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を情報媒体２０１に記録する場合は、ＳＴＢ制御部４０４の指示に従い、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部４２０を介して、ＩＥＥＥ１３９４転送により、光ディスク装置４１５のデータ転送インターフェイス部４１４に送る。受信情報セレクタ部４２３で選択された特定番組の情報（トランスポートパケット）を記録することなく単に視聴するだけの場合は、ＳＴＢ制御部４０４の指示に従い、セレクタ部４２３は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部４０２の多重化情報分離部４２５に送る。

一方、情報媒体２０１に記録された番組を再生する場合は、ＩＥＥＥ１３９４のシリアルバスを介して光ディスク装置４１５からＳＴＢ装置４１６に送られてきたストリームデータは、セレクタ部４２３を介してデコーダ部４０２の多重化情報分離部４２５に送られる。多重化情報分離部４２５は、セレクタ部４２３から送られてきたストリームデータに含まれる各種パケット（ビデオパケット、オーディオパケット、サブピクチャパケット等）を、内部メモリ部４２６上で、各パケットのＩＤにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部（ビデオデコード部４２８、サブピクチャデコード部４２９、オーディオデコード部４３０に分配する。

ビデオデコード部４２８は、多重化情報分離部４２５から送られてきた（ＭＰＥＧエンコードされた）ビデオパケットをデコードして、動画データを生成する。その際、ＭＰＥＧビデオデータ中のＩピクチャから記録内容を代表する縮小画像（サムネールピクチャ）を生成する機能を持たせるために、ビデオデコード部４２８は、代表画像（サムネール）生成部４３９を内蔵している。ビデオデコード部４２８でデコードされた動画（および／または生成部４３９で生成された代表画像）と、サブピクチャデコード部４２９でデコードされたサブピクチャ（字幕、メニュー等の情報）と、オーディオデコード部４３０でデコードされた音声とは、ビデオプロセサ部４３８を介してビデオミキシング部４０５へ送出される。

ビデオミキシング部４０５は、フレームメモリ部４０６を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、Ｄ／Ａ変換器４３６を介してアナログ映像化され、モニタＴＶ４３７に送られる。また、ビデオミキシング部４０５からのデジタル映像は、Ｉ／Ｆ部４３４およびＩＥＥＥ１９４等の信号ラインを介して、パーソナルコンピュータ４３５に適宜取り込まれる。一方、オーディオデコード部４３０でデコードされたデジタルオーディオ情報は、Ｄ／Ａ変換器４３２および図示しないオーディオアンプを介して、外部スピーカ４３３に送られる。また、デコードされたオーディオ情報は、Ｉ／Ｆ部４３１を介して外部にデジタル出力される。なお、ＳＴＢ装置４１６内の動作タイミングは、システムタイムカウンタ（ＳＴＣ）部４２４からのクロックにより決定される。

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

図９に示すストリームデータ記録再生装置では光ディスク装置４１５とＳＴＢ装置４１６との間でデータ転送インターフェイス部４１４、４２０を介してストリームデータの転送処理が行われる。ＭＰＥＧ２の形式で圧縮されたデジタルＴＶの映像情報が間欠なく連続して転送されるために必要な情報として、データ転送インターフェイス部４１４と４２０間で情報転送するときの最大ビットレート（情報の最大転送速度）の情報がロングアプリケーションヘッダ１１のフィールド３２７（図７）に記録されている。また、光ディスク装置４１５およびＳＴＢ装置４１６のデータ転送インターフェイス部４１４、４２０間でＭＰＥＧ２映像情報のリアルタイム連続転送を保証するために必要な情報、すなわちデータ転送インターフェイス部４１４、４２０内部で持つ必要のあるメモリサイズが、スムーズバッファサイズとして、図７のフィールド３３２に記録されている。

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

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

具体的には、ＳＴＢ装置４１６から光ディスク装置（ストリーマ）４１５に送られてくるストリームデータに含まれるＳＯＢ内の最初のパックに対して、ストリーマ４１５内部のローカル基準クロック（４４０）を、そのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに設定することになる。

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

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

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

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

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

この発明の一実施の形態では、ＳＴＢ装置４１６で取り込まれたアプリケーションパケット（トランスポートパケット）間の時間間隔を保持したままディスク２０１に記録可能とし、受信時の各パケット間の時間間隔を保持したまま再生（ＳＴＢ装置へ光ディスク装置から送信）可能としている。ただし、この場合、ＳＴＢ装置４１６内の基準クロック周波数（ＳＴＣ４２４）と、光ディスク装置４１５内の基準クロック周波数（ローカルクロック４４０）とが異なるために、光ディスク装置４１５で記録する前にタイムスタンプの付け直しを行い、光ディスク装置４１５内のクロックをパックヘッダに記録するようにしている。これにより、再生時には、受信時の各パケット間の時間間隔を保持したまま光ディスク装置４１５からＳＴＢ装置４１６へアプリケーションパケットを送信することが可能となる。その結果、ＳＴＢ装置４１６では、データ転送インターフェイス部４２０および受信情報セレクタ部４２３を通して多重化情報分離部４２５に取り込まれたアプリケーションパケットは、衛星アンテナ４２１を通じて取り込まれたときと同様な処理でデコード可能となる。

すなわち、先に説明した「受信時刻管理部」が機能し、アプリケーションパケットの受信時刻（取り込み時刻）およびアプリケーションパケットが多重情報分離部４２５のメモリ部４２６に取り込まれる。次に「ストリームデータ内容解析部」ではメモリ部４２６に記憶されているアプリケーションパケット内の情報を解析し、そのヘッダであるトランスポートパケットヘッダ、ペイロードを認識する（図１４参照）。ペイロードの種類としては、ピクチャ情報、オーディオ情報、副映像情報、さらにはデータ、テキスト情報なども含まれる。それぞれの情報には、ＰＴＳ（プレゼンテーションタイムスタンプまたは再生タイムスタンプ）が付加されている。トランスポートパケットヘッダには、追随するペイロードがどのようなデータであるかの識別情報や各種の属性情報が含まれているので、この情報にしたがって、ピクチャ情報、オーディオ情報、副映像情報などの切り出し、それぞれの情報に対応するＰＴＳの抽出が行われる。

各情報は、それぞれ対応するビデオデコード部４２８、オーディオデコード部４３０、サブピクチャデコード部４２９に入力されデコードされる。ビデオデコード部４２８からのビデオ信号と、サブピクチャデコード部４２９からの副映像信号とは、ビデオプロセッサ部４３８に入力される。ビデオプロセッサ部４３８では、デコードされたビデオ信号と副映像信号との合成処理、その他ビデオ信号に必要な処理が行なわれる。ビデオプロセッサ部４３８からの出力ビデオ信号は、ビデオミキシング部４０５を介してデジタルアナログ変換部４３６に入力され、ここでアナログ信号となり、テレビジョン受像機４３７でモニタされる。

ビデオミキシング部４０５には、フレームメモリ部４０６が接続されており、ミキシング処理のときの一時保管部として利用される。またミキシング部４０５のデジタル出力（映像、副映像、オーディオを含む）は、インターフェイス４３４を介してパーソナルコンピュータ４３５に与えることもできる。オーディオデコード部４３０の出力は、インターフェイス部４３１を介してデジタル出力として取り出すことができる。またオーディオデータは、デジタルアナログ変換部４３２を介してアナログ信号に変換されスピーカ４３３に入力される。

上述したように、図９の装置では、受信時の各パケット間の時間間隔を保持したまま再生（光ディスク装置からＳＴＢ装置への送信）可能としている。このことは、しかしながら、記録媒体２０１に対する物理的記録箇所が間欠的にならないことを意味するものではない。場合によっては、物理的な記録箇所が間隔を有することもあるが、基本的には連続的に記録される。しかし、上述したようにパケット間には時間間隔が時間情報上で存在するので、記録媒体からのデータ再生量がＳＴＢ装置の単位時間当たりのデータ処理量よりも多くなることがある。この場合には、光ディスク装置のキックバック機能が働くようになっており、取り込んだ再生データの一部を破棄し、再度、記憶媒体２０１から読み取るようになっている。これにより、アプリケーションパケットは、アンテナより受信したときと同様なタイミングでＳＴＢ装置へ伝送される。

図１０は、この発明の一実施の形態に係るストリームデータ記録手順を説明するフローチャート図である。まず、図９のＳＴＢ装置４１６においてデジタルＴＶ放送の映像情報が受信される（ステップＳ１）。一般にデジタルＴＶ放送での受信情報は、１個のトランスポンダ内に複数番組情報が時分割多重化されている。その情報に対して、受信情報セレクタ部４２３内で、特定番組のみのアプリケーションパケットが抽出される。

図９の説明で述べた「受信時刻管理部」では、必要な番組情報が多重化情報分離部４２５内のメモリ部４２６内に一時保管される。これと同時に、「受信時刻管理部」では各アプリケーションパケット毎の受信時刻が計測され、その計測値が、図１（ａ）に示したようなオリジナルタイムスタンプとして各アプリケーションパケット毎に付加される（ステップＳ２）。ここで、オリジナルタイムスタンプは、ＩＥＥＥ１３９４の規格に基いてデータ伝送するとき（各アプリケーションパケットを伝送するとき）のタイムスタンプである。このように付加されたオリジナルタイムスタンプ情報は、メモリ部４２６内に記録される。

次に、図９の説明で述べた「ストリームデータ内容解析部」では、メモリ部４２６内に記録されたアプリケーションパケット内の情報が解析される。具体的には、アプリケーションパケット列から各ピクチャ境界位置を切り出す処理と、ＰＴＳ（プレゼンテーションタイムスタンプ）情報の抽出処理とが行なわれる。また、「ストリームデータ内容解析部」では、ストリームデータ内容からデジタルＴＶ放送の映像情報であるか否かの判定も行なわれる。以上の処理が行なわれたあと、オリジナルタイムスタンプのタイミングに合わせてストリームデータがデータ転送インターフェイス部４２０に転送される。

データ転送インターフェイス部４１４とデータ転送インターフェイス部４２０との間でストリームデータを転送するとき、このデータ転送と同時に、データ転送インターフェイス部４１４内部で発生させたデジタルＴＶ映像情報識別フラグが添付されて転送される（ステップＳ３）。

光ディスク装置４１５側では、データ転送インターフェイス部４１４から出力された各アプリケーションパケットに対して、装置内部の基準クロック発生部４４０で生成する基準クロックに合わせて、タイムスタンプの付け替え（モディファイドタイムスタンプの付け直し）が行なわれる（ステップＳ４）。

このタイムスタンプの付け替えにより、ＳＴＢ装置４１６から光ディスク装置（ストリーマ）４１５に送られてくるストリームデータに含まれるストリームオブジェクトＳＯＢ内の最初のパックに対して、ストリーマ４１５内部のローカル基準クロック（４４０）を、そのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに設定することになる。換言すれば、ＳＯＢの記録中にストリーマに入ってくるアプリケーションパケットＡＰ＿ＰＫＴは、ストリーマ内部のローカル基準クロックによりタイムスタンプされ（このタイムスタンプで示される時間がアプリケーションパケット到着時間ＡＰＡＴ）、ＳＯＢ内の最初のパックに対しては、ストリーマ内部のローカル基準クロック（図５のＳＣＲ３０３または後述する図１５のＳＣＲベースに対応）は、そのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに等しくなる。

上記ステップＳ４のタイムスタンプ付け替え処理と並行して、光ディスク装置制御部４１５ではデジタルＴＶ映像情報識別フラグが認識され、図１（ｃ）または図７で示されたロングアプリケーションヘッダ１１の設定が行なわれる（ステップＳ５）。

ストリームデータを情報媒体２０１上に記録する処理においては、図９のＤ−ＰＲＯ（デジタルプロセッサ）部４１０がデータ制御を行い、記録再生部４０９が動作する（ステップＳ６〜ステップＳ９）。このときは、図１（ｃ）に示すように、各セクタ毎に、順次パックヘッダ１、ＰＥＳヘッダ＆サブストリームＩＤ６、ロングアプリケーションヘッダ１１が記録され、データエリア２１内では順次モディファイドタイムスタンプおよびアプリケーションパケットが記録されて行く。

ここで、パックヘッダ１には図５に示すＳＣＲ３０３（後述する図１５のＳＣＲベースに対応）が記録されている。情報媒体２０１にストリームデータを記録するときの時刻情報として基準クロック発生部４４０から出力されたクロックのカウント値が、このＳＣＲ情報として記録される。

ステップＳ６〜ステップＳ９の中身をより具体的に説明すると、まずＤ−ＰＲＯ部４１０を介して記録再生部４０９でストリームパック（セクタ）毎にパックヘッダが情報媒体に記録される（ステップＳ６）。次に、Ｄ−ＰＲＯ部４１０を介して記録再生部４０９でストリームパック（セクタ）毎にＰＥＳヘッダ＆サブストリームＩＤが情報媒体に記録される（ステップＳ７）。続いて、Ｄ−ＰＲＯ部４１０を介して記録再生部４０９でストリームパック（セクタ）毎にロングアプリケーションヘッダが情報媒体に記録される（ステップＳ８）。そして、Ｄ−ＰＲＯ部４１０を介して記録再生部４０９でストリームパック（セクタ）毎にモディファイドタイムスタンプおよびアプリケーションパケットが情報媒体に記録される（ステップＳ７）。

以上の処理により、図９の光ディスク装置（またはストリーマ）４１５内では、基準クロック発生部４４０からの基準クロックを用いて作成した時間情報（モディファイドタイムスタンプ／ＳＣＲ）を、データの送出／転送のタイミングを得るための情報として利用できるようになる。

以上の処理を別の言葉で表現すると、以下のようになる。すなわち、情報媒体上にストリームデータを記録する場合において、前記ストリームデータを記録する第１の記録単位（ストリームパック／セクタ）および第２の記録単位（アプリケーションパケット）が用意される。そして、前記第１の記録単位（ストリームパック／セクタ）毎に第１のヘッダ（パックヘッダ）情報が記録され、前記第２の記録単位（アプリケーションパケット）毎に時間情報（タイムスタンプ）が記録され、前記第２の記録単位（アプリケーションパケット）毎に前記ストリームデータが記録される。また、前記第１のヘッダ（パックヘッダ）情報内に所定のシステムクロック情報が記録されるとともに、前記第２の記録単位（アプリケーションパケット）毎に記録される前記時間情報（タイムスタンプ）が、前記所定のシステムクロックの値に連動して設定される（ステップＳ４）。

図１１は、この発明の一実施の形態に係るストリームデータ再生手順を説明するフローチャート図である。この再生手順において、まずパックヘッダ１から再生が開始される（ステップＳ３１）。

パックヘッダ１にはストリームデータを記録するときの時刻情報として基準クロック発生部４４０から出力されたクロックのカウント値が記録されており、その値に合わせて基準クロック発生部４４０の初期値の再設定が行なわれる（ステップＳ３２）。

その直後に、図９の情報再生部４０９で、情報媒体２０１上に記録されたタイムスタンプおよびアプリケーションパケットが再生され、その再生データが一時記憶部４１１に一時保管される（ステップＳ３３）。

情報媒体２０１に記録されたモディファイドタイムスタンプは、前述したＳＣＲ３０３に連動して設定されている。このことから、基準クロック発生部４４０から発生した基準クロックのカウント値がモディファイドタイムスタンプの値に一致したときに、一時記憶部４１１内に一時記録されたモディファイドタイムスタンプとそれに関連したアプリケーションパケットがデータ転送インターフェイス部４１４に転送される（ステップＳ３４）。

データ転送インターフェイス部４１４内部では、その内部に持っている基準クロックに合わせてタイムスタンプ値が付け直されて、一時記憶部４１１から転送されてきた情報がデータ転送インターフェイス部４２０に転送される。

ところで、情報媒体２０１上に点在記録されたストリームデータを記録再生部４０９内の光学ヘッド（図示せず）がアクセスして再生する場合、モディファイドタイムスタンプの連続性が崩れる。そこで、情報媒体２０１上に点在記録されたストリームデータに光学ヘッドがアクセスし（ステップＳ３５）、情報媒体上の大きく離れた位置で再生開始する場合には、次のような処理が行われる。すなわち、図９の記録再生部４０９で情報媒体２０１上に記録されたパックヘッダからＳＣＲ３０３が再生され（ステップＳ３６）、再生されたＳＣＲの値に合わせて基準クロック発生部４４０の値が再設定される（ステップＳ３７）。

このような処理により、基準クロック発生部４４０から得られるＳＣＲの値が、再生されるパケットのタイムスタンプに同期可能な関係になる。この同期関係が確立されてから、情報再生部４０９において、情報媒体上に記録されたタイムスタンプおよびアプリケーションパケットが再生される（ステップＳ３８）。最後に、基準クロック発生部４４０から発生した基準クロックのカウント値がモディファイドタイムスタンプの値に一致したときに、一時記憶部４１１内に一時記録されたモディファイドタイムスタンプとそれに関連したアプリケーションパケットがデータ転送インターフェイス部４１４に転送される（ステップＳ３９）。

データ転送インターフェイス部４１４に転送された再生情報はＩＥＥＥ１３９４ライン等を介してＳＴＢ装置４１６に送られ、そこで必要なデコードが行われる。デコードされた情報（媒体２０１上の記録コンテンツ）は、図９のＴＶ４３７、スピーカ４３３等により再生される。

以上の処理を別の言葉で表現すると、以下のようになる。すなわち、記録されたビットストリームに対する再生データを表すストリームオブジェクト（ＳＯＢ）が１以上集まってストリームデータが構成され、前記ストリームオブジェクト（ＳＯＢ）が１以上のストリームパック（Ｓ＿ＰＣＫ）で構成され、前記ストリームパック（Ｓ＿ＰＣＫ）はパックヘッダとストリームパケット（Ｓ＿ＰＫＴ）とで構成され、前記パックヘッダが所定の時間情報（ＳＣＲ）を含み、前記ストリームパケット（Ｓ＿ＰＫＴ）が所定のタイムスタンプ（ＡＴＳ）が付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）を１以上含み、（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプされ、前記タイムスタンプの情報が前記ストリームパック（Ｓ＿ＰＣＫ）内に記録された形式で前記ストリームオブジェクト（ＳＯＢ）が記録された情報媒体（２０１）から記録情報を再生する場合において、
前記情報媒体（２０１）から再生された前記ローカル基準クロック（図５のＳＣＲ３０３、図１５のＳＣＲベース）に基づいて再生用の基準クロックが設定され（ステップＳ３７）、前記設定された再生用の基準クロック（ＳＣＲ）に基づいて、前記情報媒体（２０１）から前記ビットストリームの内容が再される。

以上の処理をさらに別の言葉で表現すると、以下のようになる。すなわち、第１の記録単位（ストリームパック／セクタ）毎にシステムクロック情報が記録されている第１のヘッダ（パックヘッダ）情報と、第２の記録単位（アプリケーションパケット）毎に記録されているストリームデータと、前記第２の記録単位（アプリケーションパケット）毎に記録されている時間情報（タイムスタンプ）とを有したビットストリーム情報が記録された媒体から記録情報を再生する場合において、
前記第１のヘッダ（パックヘッダ）情報内から前記システムクロック情報が再生され（ステップＳ３６）、前記再生したシステムクロック情報から基準クロックが再設定され（ステップＳ３７）、前記第２の記録単位（アプリケーションパケット）毎に記録されている時間情報（タイムスタンプ）が再生され（ステップＳ３８）、前記再設定した基準クロックを基に前記再生した時間情報（タイムスタンプ）に応じて前記媒体に記録されたビットストリーム情報の内容が出力される（ステップＳ３９）。

図１２は、この発明の他の実施の形態に係る記録再生システム（光ディスク装置とＳＴＢ装置とが一体化されたストリームデータ記録再生装置）の構成を説明する図である。

この実施の形態におけるストリームデータ記録再生装置は、エンコーダ部４０１、デコーダ部４０２、ＳＴＢ部４０３、メインＭＰＵ４０４、Ｖ（ビデオ）ミキシング部４０５、フレームメモリ部４０６、キー入力部４５７、表示部４５８、情報媒体（ＤＶＤ−ＲＡＭディスク等）２０１に対して情報記録あるいは情報再生を行なう記録再生部（ディスクドライブ部）４０９、データプロセサ（Ｄ−ＰＲＯ）部４１０、一時記憶部４１１、Ａ／Ｖ（オーディオ・ビデオ）入力部４４２、ＴＶチューナ部４４３を備えている。また、デジタルＴＶの映像情報以外に、例えばＭＰＥＧ４で圧縮されたＴＶ電話の映像情報あるいはＭＤ（ミディディスク）もしくはＣＤ（コンパクトディスク）などのデジタルオーディオ情報などを入力し、ストリームデータとして情報媒体２０１上に記録することも可能とするために、デジタル信号入力部４４１を備えている。

このストリームデータ記録再生装置はさらに、ＳＴＢ部４０３に接続された衛星アンテナ４２１、システムタイムカウンタ（ＳＴＣ）部４２４、ビデオミキシング部（Ｖミキシング部）４０５からパーソナルコンピュータ（ＰＣ）４３５へデジタルビデオ信号を送るインターフェイス（Ｉ／Ｆ）４３４、アナログＴＶ４３７用Ｄ／Ａ変換部４３６を備えている。

ここで、Ｖミキシング部４０５は、デコーダ部４０２のＶ−ＰＲＯ部４３８からのデジタルビデオ信号と、ＳＴＢ部４０３からのデジタルビデオ信号４５３とを、適宜ミキシングする機能を持っている。このミキシング機能により、たとえばＴＶ４３７の表示画面の左側にＳＴＢ部４０３からの放送画像を表示し、ＴＶ４３７の表示画面の右側にディスク２０１から再生した画像を表示することができる。あるいは、ＳＴＢ部４０３からの放送画像とディスク２０１からの再生画像とを、ＰＣ４３５のモニタ画面において、オーバーラッピングウインドウに重ねて表示することもできる。

以上の構成において、エンコーダ部４０１内は、ビデオおよびオーディオ用のＡ／Ｄ変換部４４４、Ａ／Ｄ変換部４４４からのデジタルビデオ信号、ＳＴＢ部４０３からのデジタルビデオ信号４５３あるいはデジタル信号入力部４４１からのデジタル信号を選択してビデオエンコード部４４６に送るセレクタ４４５、セレクタ４４５からのビデオ信号をエンコードするビデオエンコード部４４６、Ａ／Ｄ変換部４４４からのオーディオ信号をエンコードするオーディオエンコード部４４７、ＴＶチューナ部４４３からのクローズドキャプション（ｃｃ）信号あるいは文字放送信号等を副映像（ＳＰ）にエンコードするＳＰエンコード部４４８、フォーマッタ部４４９、一時的にデータを格納するためのバッファメモリ部４５０より構成される。

一方、デコーダ部４０２内は、メモリ４２６を内蔵する分離部４２５、縮小画像（サムネールピクチャ）生成部４３９を内蔵するビデオデコード部４２８、ＳＰデコード部４２９、オーディオデコード部４３０、ＴＳパケット（トランスポートパケット）転送部４２７、ビデオプロセサ（Ｖ−ＰＲＯ）部４３８、オーディオ用Ｄ／Ａ変換部４３２より構成されている。

オーディオデコード部４３０でデコードされたデジタルオーディオ信号は、インターフェイス（Ｉ／Ｆ）４３１を介して外部出力可能となっている。また、このデジタルオーディオ信号をＤ／Ａ変換部４３２でアナログ化したアナログオーディオ信号により、外部のオーディオアンプ（図示せず）を介してスピーカ４３３が駆動されるようになっている。Ｄ／Ａ変換部４３２は、オーディオデコード部４３０からのデジタルオーディオ信号のみならず、ＳＴＢ部４０３からのデジタルオーディオ信号４５２のＤ／Ａ変換もできるように構成される。

なお、ディスク２０１からの再生データをＳＴＢ部４０３に転送する場合は、ＴＳパケット転送部４２７において分離部４２５からの再生データ（ビットストリーム）をトランスポートパケット（ＴＳパケット）に変更し、ＳＴＣ４２４からの時間情報に転送時間を合わせて、ＴＳパケットをＳＴＢ部４０３に送ればよい。

図１２のメインＭＰＵ４０４は、作業用メモリとしてのワークＲＡＭ４５４ａと、ストリームデータ作成制御部４５４ｂという名の制御プログラムと、ストリームデータ再生制御部４５４ｃという名の制御プログラムと、ストリームデータの部分消去／仮消去制御部４５４ｄという名の制御プログラム等を含んでいる。ストリームデータ記録再生装置における録画時の制御は、上記制御プログラム（シーケンシャルな制御プログラム）を用いメインＭＰＵ４０４により行われる。

ここで、ファイルの管理領域（図２あるいは図３（ｅ）のナビゲーションＲＴＲ．ＩＦＯ１０４、ＳＴＲＥＡＭ．ＩＦＯ１０５）などを読み書きするために、メインＭＰＵ４０４は、Ｄ−ＰＲＯ部４１０に、専用のマイクロコンピュータバスを介して接続されている。

まず、図１２の装置における録画時のビデオ信号の流れについて説明をする。録画時には、メインＭＰＵ４０４内のストリームデータ作成制御部４５４ｂという名のシーケンシャルプログラムにしたがって、一連の処理が行われる。すなわち、ＩＥＥＥ１３９４規格に準拠した伝送経路経由してＳＴＢ部４０３からエンコーダ部４０１へ送出されたストリームデータは、まずフォーマッタ部４４９に転送される。フォーマッタ部４４９のＩＥＥＥ１３９４受信側は、ＳＴＣ４２４のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。読み込んだ時間情報は、管理情報としてメインＭＰＵ４０４へ送られ、ワークＲＡＭ部４５４ａに保存される。

メインＭＰＵ４０４は、上記時間情報に基づいて、ストリームデータをストリームブロック毎（ビデオレコーダではＶＯＢＵ毎、ストリーマではＳＯＢＵ毎）に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはＰＧＣの切り分け情報を作成し、メインＭＰＵ４０４内のワークＲＡＭ部４５４ａに逐次記録する。

フォーマッタ部４４９は、メインＭＰＵ４０４のストリームデータ作成制御部４５４ｂからの指示にしたがって、ＳＴＢ部４０３から送られてきたストリームデータをストリームパックの列に変換し、変換されたストリームパック列をＤ−ＰＲＯ部４１０へ入力する。入力されたストリームパックはセクタと同じ２０４８バイトの一定サイズを持っている。Ｄ−ＰＲＯ部４１０は、入力されたストリームパックを１６セクタ毎にまとめてＥＣＣブロックにして、ディスクドライブ部４０９へ送る。ディスクドライブ部４０９では、データ記録を行なうに適した変調処理が施され、図示しない光学ヘッドを介して媒体２０１へ記録が行われるようになっている。

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

次に、再生時のデータ処理について説明する。ストリームデータ記録再生装置における再生時の制御は、ストリームデータ再生制御部４５４ｃという名のシーケンシャルプログラムにしたがい、メインＭＰＵ４０４によって、一連の処理が行われる。まず、ディスクドライブ部４０９により、ＲＡＭディスク（情報媒体）２０１からストリームデータが再生される。再生されたストリームデータは、Ｄ−ＰＲＯ部４０９を経由してデコーダ部４０２に転送される。

デコーダ部４０２内部では、再生されたストリームデータ中のトランスポートパケットを分離部４２５が受け取る。分離部４２５は、ストリームＩＤ／サブストリームＩＤに従って、ビデオパケットデータ（ＭＰＥＧビデオデータ）はビデオデコード部４２８へ転送し、オーディオパケットデータはオーディオデコード部４３０へ転送し、副映像パケットデータはＳＰデコード部４２９へ転送する。

ビデオデコード部４２８でデコードされたビデオデータは、Ｖミキシング部４０５およびＤ／Ａ変換部４３６を介してアナログＴＶ信号に変換され、ＴＶ４３７に転送されて画像表示される。同時に、オーディオデコード部４３０でデコードされたオーディオ信号もＤ／Ａ変換部４３２へ送られ、デジタル音声データに変換される。変換されたデジタル音声データは、Ｉ／Ｆ４３１を介して外部オーディオ機器（図示せず）のデジタル入力に転送される。あるいは、変換されたデジタル音声データは、Ｄ／Ａ変換部４３２によりアナログ音声信号に変換され、図示しないオーディオアンプを介して、スピーカ４３３に送られる。

図１２に示したストリームデータ記録再生装置では、ディスクドライブ部４０９とＳＴＢ部４０３とが一体化された構成を採っているため、図９のようなデータ転送インターフェイス部４１４、４２０を持たない。また、ＳＴＣ部４２４というシステム全体に共通の基準クロック発生部を持っているため、モディファイドタイムスタンプで示されるようなタイムスタンプの付け替え処理が不要となる。またデジタル信号入力部４４１を持っているため、デジタルＴＶの映像情報以外の例えばＭＰＥＧ４で圧縮されたＴＶ電話の映像情報やＭＤ（ミディディスク）やＣＤ（コンパクトディスク）などのＰＣＭオーディオ情報などを入力し、ストリームデータとして情報媒体２０１上に記録することもできる。

なお、モディファイドタイムスタンプで示されるようなタイムスタンプの付け替え処理が不要とはいっても、ストリーム記録時において、「ＳＯＢ内の最初のパックに対してストリーマ内部のローカル基準クロックをそのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに等しくする」ことは必要である。

図１２の装置において、再生が行われる場合には、図示しない光学ヘッドを介して情報媒体２０１の記録データが読み取られる。記録再生部４０９ではその復調処理が行われ、復調されたデータはＤ−ＰＲＯ部４１０に入力され、エラー訂正処理等が施される。復調されたデータは、多重化情報分離部４２５に入力される。この多重化情報分離部４２５では、図９で説明したのと同様な信号処理が行われる。ビデオデコード部４２８には、縮小画面生成部４３９（図９では代表画像生成部と称した）が設備されているが、これは、例えば編集用や見出し用の画像を生成する部分である。

図１３は、この発明の他の実施の形態に係るストリームデータ記録手順（ショートアプリケーションヘッダ利用）を説明するフローチャート図である。たとえば図１２のデジタル信号入力部４４１からデジタルストリームデータが入力される（ステップＳ１１）。入力されたストリームデータに対して、図１２のフォーマッタ部４４９において、ＳＴＣ４２４が発生する基準クロックに合わせて、アプリケーションパケット毎に、タイムスタンプが生成される（ステップＳ１２）。この処理と並行して、メインＭＰＵ部４５４により、入力されたストリームデータの内容が判別され（ステップＳ１３）、判別された内容に応じてショートアプリケーションヘッダの設定が行なわれる（ステップＳ１４）。

ステップＳ１２で生成されるタイムスタンプが示す時間は、前述したアプリケーションパケット到着時間ＡＰＡＴに相当する。つまり、ＳＯＢ内の最初のパックに対して、ストリーマ内部のローカル基準クロック（図５のＳＣＲ３０３または後述する図１５のＳＣＲベースに対応）が、そのパック内で開始する最初のアプリケーションパケットのＡＰＡＴに等しくなる。

図１３のその後の処理（ステップＳ１５〜ステップＳ１８）は、ステップＳＴ１７で記録されるアプリケーションヘッダがショートアプリケーションヘッダであることを除き、図１０を参照して説明したステップＳ６〜ステップＳ９の処理と同様である。

図１４は、この発明の一実施の形態に係るデータ構造において、とくにデータエリア内のデータ構造を説明する図である。図１４には、図１（ｃ）のデータエリア（２１〜２３）に配置されるデータの構成がさらに詳しく例示されている。

図１４の最上段に示すデータエリアには、図１４の２段目に示すように、モディファイドタイムスタンプとアプリケーションパケットとの組が複数存在する。このアプリケーションパケット内には、図１４の３段目に示すように、アプリケーションパケットヘッダとペイロードとの組が複数格納される。複数のペイロードからデータを集めると、図１４の４段目に例示するように、Ｉピクチャ、Ｂピクチャ、Ｐピクチャのデータ集合体となる。ここで、Ｉピクチャのデータ部を見ると、図１４の５段目に示すように、ピクチャヘッダ、圧縮情報等が存在する。また、ピクチャヘッダの内部を見ると、図１４の最下段に示すように、ヘッダＩＤ、ピクチャＩＤなどが存在する。

なお、図示しないが、プレゼンテーションタイムスタンプＰＴＳは、図９のメモリ部４２６からビデオデコード部４２８へパケットを送るタイミングを示している。システムタイムカウンタ（システムクロック）ＳＴＣ部４２４の値がＰＴＳの値に一致したとき、または所定の大きな値となったときに、図１４のＩピクチャ情報がビデオデコード部４２８に送られ、ビデオデコード部４２８は図示しないデコードタイムスタンプＤＴＳのタイミングで、送られてきたＩピクチャ情報のデコードを開始するようになっている。

ここで、たとえば図９の光ディスク装置４１５とＳＴＢ装置４１６との間で同期ずれがあると、ＰＴＳに基いてメモリ部４２６からビデオデコード部４２８へ送られるデータ転送量と、光ディスク装置４１５からメモリ部４２６へ送られてくるデータ量の不整合（アンマッチング）が生じる。このような不具合を取り除くために、図９の装置では、次のような機能が設けられている。

たとえばアプリケーションパケットの特定個数（例えば1万個、あるいは10万個）を送信／受信する毎に、光ディスク装置とＳＴＢ装置側とで、その送信時刻／受信時刻を一時記憶部４１１、ワークＲＡＭメモリ部４０７に記憶する。これにより、両者には、アプリケーションパケットを特定個数を送信／受信する毎の時刻情報テーブルを作成することができる。ここで、適当な時間間隔たとえば10分、あるいは30分間隔（この時間間隔は任意に修正できるようにしてもよい）で、ＳＴＢ装置側から、光ディスク装置側へ時刻情報テーブルを転送する。光ディスク装置側では、両者の時刻情報テーブルを比較し、時刻のずれ情報を把握する。そうすれば、アプリケーションパケットの特定個数毎に、双方の装置間でどのくらいの時間ずれ（同期ずれ）が生じているのかを把握することができる。この同期ずれ量に応じて、光ディスク装置４１５側のデータ再生速度あるいは、データの転送タイミングの調整を行なうことができる。

データの転送タイミングを制御する手段の例としては、前述したモディファイドタイムスタンプを、実際に使用する前に図示しない変換テーブルを通して使用する方法がある。時間調整手段としては、その調整量に応じて各種の方法が可能である。この調整手段は、情報媒体２０１に対するデータ記録が、別の光ディスク装置によってなされている場合に有効である。実際にデータを再生する装置の基準クロックと実際にデータ記録した装置の基準クロックとの間に周波数ずれがあると、再生されたモディファイドタイムスタンプの値が、再生する装置の予期しているモディファイドタイムスタンプの値とずれている場合があるからである。

以上説明したこの発明の実施の形態における効果をまとめると以下のようになる。

＊情報媒体に記録するストリームデータの内容（種類）に応じて最適なアプリケーションヘッダタイプ（ロングかショートか）を選択するため、アプリケーションヘッダ情報として不要な情報を記録する必要がない。その結果、情報媒体上に記録する情報の記録効率を向上させ、情報媒体に対する実質的な有効記録容量を増加させることができる。

＊ＩＥＥＥ１３９４などで転送されてくるストリームデータに対して、ストリーマ内部の基準クロックでタイムスタンプを付け直し、さらにその基準クロックに基づき各ストリームパック先頭位置での時刻情報をシステムクロック（ＳＣＲ）としてストリームパック内に記録することができる。こうすることで、
（ａ）ストリームデータを読み飛ばしながら再生する場合にストリームパック内に記録されたシステムクロック（ＳＣＲ）に合わせてストリーマの基準クロックをリセットし、そのリセットしたストリーマ内の基準クロックを基準にしてタイムスタンプ情報のタイミングに合わせて各アプリケーションパケットを出力することができる。このようにストリームパック内に記録されたシステムクロック（ＳＣＲ）で常にリセットすると、情報媒体上に点在するストリームデータをランダムかつ断続的に再生しても安定に各アプリケーションパケット間の出力タイミングを保持できる。

（ｂ）タイムスタンプの値を用いて情報媒体上に記録されたストリームデータを検索する場合、いちいちタイムスタンプまで再生せずにストリームパック内に記録されたシステムクロック（ＳＣＲ）の値を再生するだけで（見出しとして活用して）粗いアクセスを行うことができる。

（ｃ）再生時にストリームパック内に記録されたシステムクロック（ＳＣＲ）の値とタイムスタンプの値を比較することで、現在再生中のストリームデータが本来再生したいデータであるかどうかの確認を、リアルタイムで行うことができる。

＊光ディスク装置からＳＴＢ装置側へ転送されるデータが適切な量となるように、装置間の同期を管理することができる。

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

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

図１５（ｂ）のＰＥＳヘッダは、図１５（ｄ）に示すように、パケット開始コードプリフィックスの情報、ストリームＩＤ（プライベートストリーム２）の情報、ＰＥＳパケット長の情報を含んでいる。このサブストリームＩＤは、図１５（ｄ）に示すように、ストリーム記録データを特定する内容を持つ。具体的には、サブストリームＩＤ＝”００００００１０ｂ”によって、そのストリームパックに格納されたデータがストリーム記録データであることが示される。このストリームＩＤが”１０１１１１１０ｂ”のときは、そのストリームパックがパディングパケットに用いられるものであることが示される。

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

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

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

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

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かが、記述される。ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が００ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１０ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１１ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が０１ｂとなることは禁止されている。

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

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

図１５（ｂ）のスタッフィングバイトおよびアプリケーションパケット群は、アプリケーションパケットエリアを構成している。このアプリケーションパケットエリアの先頭部分は、図１５（ｂ）のストリームパケットに対して先行するストリームパケットから跨るアプリケーションパケットの一部（部分パケット）を適宜含むことができる。その後に、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録できる。そして、アプリケーションパケットエリアの末尾部分は、図１５（ｂ）のストリームパケットに対して後続するストリームパケットへ跨るアプリケーションパケットの一部（部分パケット）、あるいは予約されたバイト数のスタッフィングエリアを適宜含むことができる。

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

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

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

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

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

ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。

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

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

図１５のパケット構造は、該当ストリームオブジェクト（ＳＯＢ）の最終セクタ以外に適用できるが、その最終セクタには必ずしも適用されない。ＳＯＢの情報記録が行われないような最終セクタに対しては、アプリケーションパケットエリアが１つのＡＴＳとゼロバイトで埋められたスタッフィングパケット（先頭のスタッフィングパケット）、あるいはアプリケーションパケットエリアがゼロバイトで埋められたスタッフィングパケット（後続のスタッフィングパケット）が適用される。

図１５のデータ構造の特徴を纏めると、たとえば次のようになる。すなわち、記録されたビットストリームに対する再生データを表すストリームオブジェクト（ＳＯＢ）が１以上集まってストリームデータが構成される。前記ストリームオブジェクト（ＳＯＢ）が１以上のストリームパック（Ｓ＿ＰＣＫ）で構成される。前記ストリームパック（Ｓ＿ＰＣＫ）はパックヘッダとストリームパケット（Ｓ＿ＰＫＴ）とで構成される。前記パックヘッダは所定の時間情報（ＳＣＲ）を含む。前記ストリームパケット（Ｓ＿ＰＫＴ）は所定のタイムスタンプ（ＡＴＳ）が付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）を１以上含む。そして、前記ストリームオブジェクト（ＳＯＢ）の記録中に（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が、前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプされ（図１４のモディファイドタイムスタンプ；図１５のＡＴＳ）、前記タイムスタンプの情報が前記ストリームパック（Ｓ＿ＰＣＫ）内に記録される。

前記ストリームパケットはアプリケーションヘッダを持ち、前記ストリームパケット内の最初に記録されているタイムスタンプの位置情報（ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ）が前記アプリケーションヘッダ内に含まれる。

前記ストリームオブジェクト（ＳＯＢ）を情報媒体（２０１）に記録するときは、（ストリーマに）入ってくる前記アプリケーションパケット（ＡＰ＿ＰＫＴ）が、前記所定の時間情報（ＳＣＲ）に対応した（ストリーマ内部の）ローカル基準クロック（図９の４４０）によりタイムスタンプされ（図１０のＳ４のモディファイドタイムスタンプ；図２１〜図２３ではＳＴ１０６、ＳＴ２１２、ＳＴ３１２のタイムスタンプ）、前記タイムスタンプの情報が前記ストリームパック（Ｓ＿ＰＣＫ）内に記録される。

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

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

ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩは、図１６に示すように、ＳＴＲＩ、ＳＴＲ＿ＶＭＧＩに関する管理情報等が記述されたビデオマネージャ情報管理情報ＶＴＳＩ＿ＭＡＴと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）とを含んでいる。ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。ストリームファイル情報テーブルＳＦＩＴは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルＳＦＩＴの詳細については、図１８を参照して後述する。

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

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

また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、１以上のオリジナルセルにより構成される。プログラムはオリジナルＰＧＣ内でのみ定義されるものである。さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義ＰＧＣ内のセルは「ユーザ定義セル」と呼ばれる。プログラムセット内の各々のプログラムは、少なくとも１個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも１個のユーザ定義セルで構成される。

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

なお、プログラムチェーン（ＰＧＣ）とは、上位概念的な単位を示す。オリジナルＰＧＣでは、ＰＧＣはプログラムセットに対応したプログラムの連なり（チェーン）を指す。また、ユーザ定義ＰＧＣでは、ＰＧＣはプレイリストに対応するプログラムの一部の連なり（チェーン）を指す。また、プログラムの一部のチェーンを指すユーザ定義ＰＧＣは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルＰＧＣに属するストリームデータを参照するようになっている。

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

ＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓが示すＵＤ＿ＰＧＣ＿ＳＲＰの数は、ユーザ定義ＰＧＣ情報（ＵＤ＿ＰＧＣＩ）の数と同じであり、ユーザ定義ＰＧＣ（ＵＤ＿ＰＧＣ）の数とも同じである。この数は、最大「９９」まで許されている。ＵＤ＿ＰＧＣＩＴ＿ＥＡは、該当ＵＤ＿ＰＧＣＩＴの終了アドレスを、そのＵＤ＿ＰＧＣＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述したものである。ここで、Ｆ＿ＲＢＮとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。

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

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

図１６のアプリケーションプライベートデータマネージャＡＰＤＴ＿Ｍは、図示しないが、アプリケーションプライベートデータマネージャ一般情報ＡＰＤＴ＿ＧＩと、１以上のＡＰＤＴサーチポインタＡＰＤＴ＿ＳＲＰ＃ｎと、１以上のＡＰＤＴエリアＡＰＡＤＴＡ＃ｎとを含むことができる。ここで、アプリケーションプライベートデータＡＰＤＴとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報（リアルタイムストリームデータに加えさらに望まれる情報）を格納できるような概念上のエリアである。

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

図１７に示すように、ＰＧＣ情報ＰＧＣＩ＃ｉは、ＰＧＣ一般情報ＰＧＣ＿ＧＩと、１以上のプログラム情報ＰＧＩ＃ｍと、１以上のストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ＃ｎと、１以上のストリームセル情報ＳＣＩ＃ｎとで構成されている。ＰＧＣ一般情報ＰＧＣ＿ＧＩは、プログラムの数ＰＧ＿Ｎｓと、ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰの数ＳＣＩ＿ＳＲＰ＿Ｎｓとを含んでいる。各プログラム情報ＰＧＩ（たとえばＰＧＩ＃１）は、プログラムタイプＰＧ＿ＴＹと、該当プログラム内のセルの数Ｃ＿Ｎｓと、該当プログラムのプライマリテキスト情報ＰＲＭ＿ＴＸＴＩと、アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮとを含んでいる。

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

セルの数Ｃ＿Ｎｓは、該当プログラム内のセルの数を示す。ＰＧＣの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに（暗黙のうちに）付随している。たとえば、ＰＧＣ内でプログラム＃１がＣ＿Ｎｓ＝１を持ち、プログラム＃２がＣ＿Ｎｓ＝２を持つとすれば、そのＰＧＣの最初のストリームセル情報ＳＣＩはプログラム＃１に付随するものとなり、第２、第３のＳＣＩはプログラム＃２に付随するものとなる。

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

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

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

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

セルタイプＣ＿ＴＹは、該当ストリームセルの形式およびその仮消去状態を記述するものである。すなわち、セルの形式Ｃ＿ＴＹ１＝「０１０ｂ」は全てのストリームセルの形式に記述される（このＣ＿ＴＹ１＝「０１０ｂ」によりストリームセルとそれ以外のセルの区別ができる）。

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

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

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

図１７の各ストリームセルエントリポイント情報ＳＣ＿ＥＰＩ（たとえばＳＣ＿ＥＰＩ＃１）は、２種類（タイプＡとタイプＢ）存在する。タイプＡのＳＣ＿ＥＰＩは、エントリポイントタイプＥＰ＿ＴＹとエントリポイントのアプリケーションパケット到着時間ＥＰ＿ＡＰＡＴとを含む。タイプＡは、エントリポイントタイプＥＰ＿ＴＹ１＝「００ｂ」により示される。タイプＢのＳＣ＿ＥＰＩは、タイプＡのＥＰ＿ＴＹおよびＥＰ＿ＡＰＡＴの他に、プライマリテキスト情報ＰＲＭ＿ＴＸＴＩを含む。タイプＢは、エントリポイントタイプＥＰ＿ＴＹ１＝「０１ｂ」により示される。

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

ストリームオブジェクト番号ＳＯＢ＿Ｎは、該当セルが参照するＳＯＢの番号を記述したものである。ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当セルの開始ＡＰＡＴを記述したものである。ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当セルの終了ＡＰＡＴを記述したものである。

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

図１７のデータ構造の特徴を纏めると、たとえば次のようになる。すなわち、前記ストリームオブジェクト（ＳＯＢ）はストリームセル（ＳＣ）の情報を含む。前記ストリームセルに対する前記アプリケーションパケット（ＡＰ＿ＰＫＴ）の到着時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ）は、前記ストリームパック（Ｓ＿ＰＣＫ）内に記録された前記タイムスタンプの情報の値と連動する。そして、前記タイムスタンプ情報値が、前記ストリームパック（Ｓ＿ＰＣＫ）内の前記時間情報（ＳＣＲ）に対応して設定される。

図１８は、ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図である。図示するように、ストリームファイル情報テーブルＳＦＩＴは、ストリームファイル情報テーブル情報ＳＦＩＴＩと、１以上のストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ＃ｎと、ストリームファイル情報ＳＦＩとで構成される。

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

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

図１８の各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ（たとえばＳＯＢ＿ＳＴＩ＃１）は、アプリケーションパケットサイズＡＰ＿ＳＩＺと、サービスＩＤの数ＳＥＲＶ＿ＩＤ＿Ｎｓと、サービスＩＤ（ＳＥＲＶ＿ＩＤｓ）と、アプリケーションパケットデバイスユニークＩＤ（ＡＰ＿ＤＥＶ＿ＵＩＤ）とを含んでいる。ＡＰ＿ＳＩＺは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。

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

ＳＥＲＶ＿ＩＤ＿Ｎｓは、後続パラメータに含まれるサービスＩＤの数を記述したものである。ＳＥＲＶ＿ＩＤｓは、サービスＩＤのリストを任意の順序で記述したものである。ＡＰ＿ＤＥＶ＿ＵＩＤは、記録されたビットストリームを供給したアプリケーションデバイスに固有のユニークなデバイスＩＤを記述したものである。

ストリームファイル情報ＳＦＩは、図１８に示すように、ストリームファイル一般情報ＳＦ＿ＧＩと、１以上のストリームオブジェクト情報（ＳＯＢ情報）サーチポインタ（ＳＯＢＩ＿ＳＲＰ）＃ｎと、１以上のＳＯＢ情報（ＳＯＢＩ）＃ｎとで構成されている。ストリームファイル一般情報ＳＦ＿ＧＩは、ＳＯＢＩの数ＳＯＢＩ＿Ｎｓと、ＳＯＢＵ１個あたりのセクタ数ＳＯＢＵ＿ＳＩＺとを含んでいる。

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

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

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

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

ストリームオブジェクトのタイプＳＯＢ＿ＴＹは、仮消去状態（ＴＥ状態）を示すビットおよび／またはコピー世代管理システムのビットを記述できる部分である。ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭは、関連ストリームオブジェクト（ＳＯＢ）の記録時間を記述したものである。ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎは、該当ストリームオブジェクトに対して有効なＳＯＢ＿ＳＴＩのインデックスを記述したものである。

アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳは、該当ストリームオブジェクトに対してアクセスユニットデータ（ＡＵＤ）が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。アクセスユニットデータ（ＡＵＤ）が存在する場合は、ＡＵＤ＿ＦＬＡＧＳにより、ＡＵＤの幾つかの特性が記述される。アクセスユニットデータ（ＡＵＤ）自体は、図１８に示すように、アクセスユニット一般情報ＡＵ＿ＧＩと、アクセスユニットエンドマップＡＵＥＭと、再生タイムスタンプリストＰＴＳＬとで構成される。

アクセスユニット一般情報ＡＵ＿ＧＩは、該当ＳＯＢに対して記述されたアクセスユニットの数を示すＡＵ＿Ｎｓと、該当ＳＯＢに属するＳＯＢＵのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップＡＵＳＭとを含んでいる。アクセスユニットエンドマップＡＵＥＭは、（もし存在するときは）ＡＵＳＭと同じ長さのビットアレイであり、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの終端をどのＳＯＢＵが含むのかを示す。再生タイムスタンプリストＰＴＳＬは、該当ＳＯＢに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる１つのＰＴＳＬエレメントは、対応アクセスユニットの再生タイムスタンプ（ＰＴＳ）の値を含む。

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

ここで再びＳＯＢ＿ＧＩの内容説明に戻る。ＡＵＤ＿ＦＬＡＧＳは、フラグＲＴＡＵ＿ＦＬＧと、フラグＡＵＤ＿ＦＬＧと、フラグＡＵＥＭ＿ＦＬＧと、フラグＰＴＳＬ＿ＦＬＧとを含んでいる。フラグＲＴＡＵ＿ＦＬＧが０ｂのときは、該当ＳＯＢのリアルタイムデータ内にアクセスユニットフラグはないことが示される。フラグＲＴＡＵ＿ＦＬＧが１ｂのときは、図１５（ｂ）のアプリケーションヘッダエクステンション内に記述されるＡＵフラグ（ＡＵ＿ＳＴＡＲＴ、ＡＵ＿ＥＮＤ）が該当ＳＯＢのリアルタイムデータ内に存在可能なことが示される。この状態は、下記ＡＵＤ＿ＦＬＧが０ｂの場合にも許される。

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

図１８のＳＯＢ＿ＧＩ内に含まれるＳＯＢ＿Ｓ＿ＡＰＡＴは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｓ＿ＡＰＡＴにより、該当ＳＯＢに属する最初のアプリケーションパケット到着時間が示される。このパケット到着時間（ＰＡＴ）は、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。ＳＯＢ＿Ｅ＿ＡＰＡＴは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｅ＿ＡＰＡＴにより、該当ＳＯＢに属する最後のアプリケーションパケット到着時間が示される。

ＳＯＢ＿Ｓ＿ＳＯＢＵは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、ＳＯＢ＿Ｓ＿ＳＯＢＵにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むＳＯＢＵが示される。ＭＡＰＬ＿ＥＮＴ＿Ｎｓは、ＳＯＢＩ＿ＧＩの後に続くタイムマップ情報（ＭＡＰＬ）のエントリ数を記述したものである。タイムマップ情報ＭＡＰＬは、図３（ｈ）のタイムマップ情報２５２に対応する内容を持つ。

図１６および図１８の内容の関連性の１つについて纏めると、次のようになる。すなわち、図２または図３（ｅ）の管理情報１０５に含まれるストリーマ情報（ＳＴＲＩ）は、ストリームデータの内容の一部を構成するストリームオブジェクトＳＯＢを管理するストリームファイル情報テーブルＳＦＩＴを含む。このＳＦＩＴは、ＳＯＢを管理するストリームオブジェクト情報ＳＯＢＩを含む。このＳＯＢＩが、管理情報（アクセスユニット開始マップＡＵＳＭ）を含むアクセスユニット一般情報ＡＵ＿ＧＩと、管理情報（ＰＴＳＬ）とを含む。ここで、管理情報（ＡＴＳまたはＡＵＳＭ）がストリームデータの転送時に使用される情報を含み、管理情報（ＰＴＳまたはＳＣ＿Ｓ＿ＡＰＡＴ）が前記ストリームデータを表示するときに使用される情報を含む。

図１８のデータ構造の特徴を纏めると、たとえば次のようになる。すなわち、前記ストリームオブジェクト（ＳＯＢ）に対する前記アプリケーションパケット（ＡＰ＿ＰＫＴ）の到着時間情報（ＳＯＢ＿Ｓ＿ＡＰＡＴ／ＳＯＢ＿Ｅ＿ＡＰＡＴ）は、前記ストリームパック（Ｓ＿ＰＣＫ）内に記録された前記タイムスタンプの情報の値と連動する。そして、前記タイムスタンプ情報値が、前記ストリームパック（Ｓ＿ＰＣＫ）内の前記時間情報（ＳＣＲ）に対応して設定される。

図１９は、アクセスユニット開始マップ（ＡＵＳＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図である。図示するように、ＡＵＳＭのうちビット”１”の部分が、対応ＳＯＢＵにアクセスユニット（ＡＵ）が含まれることを示している。

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

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

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

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

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

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

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

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

図２１は、この発明の他の実施の形態に係るストリームデータ記録手順を説明するフローチャート図である。まず、アプリケーションデバイス（ＳＴＢなど）がデジタルＩ／Ｆ上にパケットを出力する（ステップＳＴ１００）。すると、ストリーマにおいて記録が開始される（ステップＳＴ１０２）。以下はストリーマ側の処理となる。

記録が開始されると、ストリーマは、ローカルクロックをｔ０＝０にリセットする（ステップＳＴ１０４）。その後、ストリーマは、最初のＳＯＢＵのセクタ０〜３１に、ローカルクロック値ｔ０、ｔ１、ｔ２、…を付けて、アプリケーションパケットを詰め込む（ステップＳＴ１０６）。ステップＳＴ１０４〜ＳＴ１０６の処理（図１０のステップＳ４、あるいは図１３のステップＳ１２に対応）により、ＳＯＢ内最初のパックに対してストリーマ内部のローカル基準クロックがそのパック内で開始する最初のアプリケーションパケットの到着時間ＡＰＡＴに等しくなる。そして、最初のＳＯＢＵのセクタ０〜３１をプレゼンテーションデータ（再生データ）として情報媒体（ディスク）に書き込む（ステップＳＴ１０８）。

ストリーマは、２番目のＳＯＢＵの先頭パックを受け、最初のタイムマップエントリを生成して、生成したタイムマップエントリをナビゲーションデータとしてメモリに保存する（ステップＳＴ１１０）。以後、ローカルクロックのタイムスタンプを付けてパケットを２番目以降のＳＯＢＵに詰め込み、２番目以降のＳＯＢＵのセクタを再生データとしてディスクに書き込み、その後のタイムマップエントリを生成し、生成したタイムマップエントリをナビゲーションデータとしてメモリに保存する（ステップＳＴ１１２）。ステップＳＴ１１０〜ＳＴ１１２の処理（図１０のステップＳ９、あるいは図１３のステップＳ１８に対応）は、記録が終了するまで反復される。

記録が終了すれば（ステップＳＴ１１４イエス）、最後のＳＯＢＵにパケットと適宜スタッフィングを詰め込み、最後のＳＯＢＵのセクタを再生データとしてディスクに書き込む（ステップＳＴ１１６）。最後に、最後のタイムマップエントリ、ＳＯＢＵストリーム情報（ＳＯＢ＿ＳＴＩ）、ＳＯＢ情報（ＳＯＢＩ）、および１セルのオリジナルＰＧＣを、ナビゲーションデータとしてメモリ内に生成し、生成したナビゲーションデータをディスクに書き込む（ステップＳＴ１１８）。

図２１の処理により、ローカル基準クロックのタイムスタンプが付されたアプリケーションパケット（ＡＰ＿ＰＫＴ）が記録される（ＳＴ１０６）とともに、所定のタイムマップエントリがナビゲーションデータとして生成される（ＳＴ１１０〜ＳＴ１１２）。

図２２は、この発明のさらに他の実施の形態に係るストリームデータ記録手順（デジタルビデオ放送サービス）を説明するフローチャート図である。まず、アプリケーションデバイス（ＡＤ）において、記録が開始される（ステップＳＴ２００）。この記録は、図示しないデバイスの記録ボタンが押され、あるいは図示しないユーザインターフェイスからの操作が生じたときに、開始される。

記録が開始されると、アプリケーションデバイスは、適正なバンド幅のアイソクロナスデジタルＩ／Ｆ（ＤＩＦ）チャネルを確立し、ビットストリーム中にＩピクチャの開始が生じるまで待機する（ステップＳＴ２０２）。

アプリケーションデバイスがストリーマに記録開始を通知すると、ストリーマはローカルクロックをリセットする（ｔ０＝０）（ステップＳＴ２０４）。この処理は、図１３のステップＳ１２に対応する。

次に、アプリケーションデバイスは、デジタルＩ／Ｆへオプションでシーケンスヘッダを出力し、その後、デジタルＩ／Ｆにパケットを出力する（ステップＳＴ２０６）。この処理は、図１３のステップＳ１５、Ｓ１６に対応する。

続いて、ストリーマにおいて、ローカルクロック値でタイムスタンプしたアプリケーションパケットを連続したＳＯＢＵのセクタに詰め込み、連続ＳＯＢＵのセクタを再生データとしてディスクに書き込み、連続したタイムマップエントリをナビゲーションデータとしてメモリ内に生成する（ステップＳＴ２１２）。このステップＳＴ２１２の処理は、アプリケーションデバイスにおいて記録終了の指示があるまで続く。

アプリケーションデバイスにおいて記録終了の指示が出ると（ステップＳＴ２１４イエス）、アプリケーションデバイスは、ビットストリームが現フレームの末尾に到達するまで待ち、デジタルＩ／Ｆのコマンドチャネルを介してストリーマに記録停止を通知する（ステップＳＴ２１５）。

すると、ストリーマは、最後のＳＯＢＵにパケットと適宜スタッフィングを詰め込み、最後のＳＯＢＵのセクタを再生データとしてディスクに書き込む（ステップＳＴ２１６）。

そして、ストリーマは、最後のタイムマップエントリ、ＳＯＢストリーム情報、ＳＯＢ情報および１セルのオリジナルＰＧＣをナビゲーションデータとしてメモリ内に生成し、生成したナビゲーションデータをディスクに書き込む（ステップＳＴ２１８）。

図２２の処理により、ローカル基準クロックのタイムスタンプ情報に基づいてＳＯＢに対するアプリケーションパケット（ＡＰ＿ＰＫＴ）の到着時間情報（ＳＯＢ＿Ｓ＿ＡＰＡＴ／ＳＯＢ＿Ｅ＿ＡＰＡＴ）が算出され、算出された到着時間情報（ＳＯＢ＿Ｓ＿ＡＰＡＴ／ＳＯＢ＿Ｅ＿ＡＰＡＴ）がナビゲーションデータとして記録される（ＳＴ２１８）。

図２３は、この発明のさらに他の実施の形態に係るストリームデータ記録手順（記録済み媒体に新たなストリームオブジェクトを追記する場合）を説明するフローチャート図である。まず、アプリケーションデバイスがデジタルＩ／Ｆにパケットを出力する（ステップＳＴ３００）。すると、ストリーマにおいて記録が開始される（ステップＳＴ３０２）。以下はストリーマ側の処理となる。

記録が開始されると、ストリーマは、ローカルクロックをｔ０＝０にリセットする（ステップＳＴ３０４）。この処理は図１３のステップＳ１２に対応する。

その後、ストリーマにおいて、ローカルクロック値でタイムスタンプされたアプリケーションパケットが連続した新ＳＯＢＵに詰め込まれ、連続した新ＳＯＢＵのセクタが再生データとしてディスクに書き込まれ、連続した新タイムマップエントリがナビゲーションデータとしてメモリ内に生成される（ステップＳＴ３１２）。この処理は図１３のステップＳ１２に対応する。このステップＳＴ３１２の処理は、記録が終了されるまで続く。

記録が終了すると（ステップＳＴ３１４イエス）、最後の新ＳＯＢＵにパケットと適宜スタッフィングを詰め込み、最後の新ＳＯＢＵのセクタを再生データとしてディスクに書き込む（ステップＳＴ３１６）。

そして、ストリーマは、最後の新タイムマップエントリ、ＳＯＢストリーム情報（記録パラメータが先行記録に対して変更された場合のみ）およびＳＯＢ情報を生成し、メモリ内のナビゲーションデータのオリジナルＰＧＣへ新たな１つのセルを追加し、その結果得られたナビゲーションデータをディスクに記録する（ステップＳＴ３１８）。この処理は図１３のステップＳ１８に対応する。

図２３の処理により、ストリームセルに対するアプリケーションパケット（ＡＰ＿ＰＫＴ）の到着時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ）が算出され、算出された到着時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ）がナビゲーションデータとして記録される（ＳＴ３１８）。

以上説明したように、この発明の実施の形態によれば、たとえばデジタルＴＶ放送で受信したときの各アプリケーションパケット間の転送タイミングを保持したまま情報媒体からストリームデータを再生できるような媒体上のデータ構造（記録フォーマット）を提供することができる。また、このデータ構造を利用して情報媒体にストリームデータを記録する方法を提供することができる。さらに、デジタルＴＶ放送のデータ以外にパケット構造を持って転送されるデジタルデータも記録可能な汎用性のあるデータ構造（記録フォーマット）を提供することもできる。また、このデータ構造を利用して情報媒体にストリームデータを記録する方法を提供することができる。

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

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

以上述べたように、この発明によれば、効率良くストリームデータを記録できるとともに、デジタルＴＶ放送で受信したときの各アプリケーションパケット間の転送タイミングを保持したままストリームデータを再生できるようなデータ構造（記録フォーマット）、およびこのデータ構造を利用して記録あるいは再生が行われる情報媒体を提供することができる。また、このデータ構造を用いてストリームデータを記録する方法を提供することができる。さらに、このデータ構造により記録されたストリームデータを再生する方法を提供することができる。

この発明の一実施の形態に係るストリームデータのデータ構造を説明する図。 この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図。 この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造（とくに管理情報の構造）を説明する図。 この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図。 図１に示されるパックヘッダの内部構造を例示する図。 図１に示されるＰＥＳヘッダおよびサブストリームＩＤの内部構造を例示する図。 図１に示されるロングアプリケーションヘッダの内部構造を例示する図。 図１に示されるアプリケーションヘッダ（ショートアプリケーションヘッダ）の内部構造を例示する図。 この発明の一実施の形態に係る記録再生システム（光ディスク装置／ストリーマとＳＴＢ装置）の構成を説明する図。 この発明の一実施の形態に係るストリームデータ記録手順を説明するフローチャート図。 この発明の一実施の形態に係るストリームデータ再生手順を説明するフローチャート図。 この発明の他の実施の形態に係る記録再生システム（光ディスク装置とＳＴＢ装置とが一体化されたシステム）の構成を説明する図。 この発明の他の実施の形態に係るストリームデータ記録手順（ショートアプリケーションヘッダ利用）を説明するフローチャート図。 この発明の一実施の形態に係るデータ構造において、とくにデータエリア内のデータ構造を説明する図。 ストリームパックのデータ構造を説明する図。 ストリーマの管理情報（図２または図３のＳＴＲＥＡＭ．ＩＦＯに対応）の内部データ構造を説明する図。 ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図１６のＰＧＣＩ＃ｉ）の内部データ構造を説明する図。 ストリームファイル情報テーブル（ＳＦＩＴ）の内部データ構造を説明する図。 アクセスユニット開始マップ（ＡＵＳＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。 アクセスユニット開始マップ（ＡＵＳＭ）およびアクセスユニット終了マップ（ＡＵＥＭ）とストリームオブジェクトユニット（ＳＯＢＵ）との対応関係を例示する図。 この発明の他の実施の形態に係るストリームデータ記録手順を説明するフローチャート図。 この発明のさらに他の実施の形態に係るストリームデータ記録手順（デジタルビデオ放送サービス）を説明するフローチャート図。 この発明のさらに他の実施の形態に係るストリームデータ記録手順（記録済み媒体に新たなストリームオブジェクトを追記する場合）を説明するフローチャート図。

符号の説明

２０１…記録／再生可能光ディスク（情報媒体）；４０１…エンコード部；４０２…デコード部；４０３…セットトップボックス；４４０…基準クロック（ローカルクロック）発生部；４２４…システムタイムカウンタ（ＳＴＣ）。

Claims (4)

1. ストリームオブジェクトが１以上集まってストリームデータが構成され、前記ストリームオブジェクトが所定のタイムスタンプが付されたパケットを１以上含むパケット群を含むように構成されたデータ構造を用いて情報記録あるいは記録情報の再生を行うものであって、
   前記ストリームデータおよびこのストリームデータと異なるリアルタイムビデオオブジェクトデータが混在記録可能なデータエリアと、前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータをファイル管理するファイルシステム情報を記録するエリアと、前記ストリームデータの管理情報を記録する管理エリアを持つ情報媒体において、
   前記ファイルシステム情報によりファイル管理される前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータのファイルが、単一のディレクトリに格納されるように構成され、
   前記ストリームデータの再生順にしたがって並んだセルがあるときに、前記ストリームデータの管理情報が、前記セルの開始時間情報および前記セルの終了時間情報を含み、
   前記セルの開始時間情報および前記セルの終了時間情報が、前記パケットの到着時間でもって表現されるように構成された情報媒体。
2. ストリームオブジェクトが１以上集まってストリームデータが構成され前記ストリームオブジェクトが所定のタイムスタンプが付されたパケットを１以上含むパケット群を含むように構成されたデータ構造を用いて情報記録あるいは記録情報の再生を行うものであって、前記ストリームデータおよびこのストリームデータと異なるリアルタイムビデオオブジェクトデータが混在記録可能なデータエリアと前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータをファイル管理するファイルシステム情報を記録するエリアと前記ストリームデータの管理情報を記録する管理エリアを持ち、前記ファイルシステム情報によりファイル管理される前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータのファイルが単一のディレクトリに格納されるように構成され、前記ストリームデータの再生順にしたがって並んだセルがあるときに前記ストリームデータの管理情報が前記セルの開始時間情報および前記セルの終了時間情報を含み、前記セルの開始時間情報および前記セルの終了時間情報が前記パケットの到着時間でもって表現されるように構成された情報記憶媒体を用いる記録方法において、
   前記情報媒体に前記ストリームオブジェクトを記録するともに、記録されたストリームオブジェクトに関する管理情報を記録するように構成された記録方法。
3. ストリームオブジェクトが１以上集まってストリームデータが構成され前記ストリームオブジェクトが所定のタイムスタンプが付されたパケットを１以上含むパケット群を含むように構成されたデータ構造を用いて情報記録あるいは記録情報の再生を行うものであって、前記ストリームデータおよびこのストリームデータと異なるリアルタイムビデオオブジェクトデータが混在記録可能なデータエリアと前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータをファイル管理するファイルシステム情報を記録するエリアと前記ストリームデータの管理情報を記録する管理エリアを持ち、前記ファイルシステム情報によりファイル管理される前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータのファイルが単一のディレクトリに格納されるように構成され、前記ストリームデータの再生順にしたがって並んだセルがあるときに前記ストリームデータの管理情報が前記セルの開始時間情報および前記セルの終了時間情報を含み、前記セルの開始時間情報および前記セルの終了時間情報が前記パケットの到着時間でもって表現されるように構成された情報記憶媒体を用いる再生方法において、
   前記情報媒体から前記管理情報を再生するするともに、前記ストリームオブジェクトを再生するように構成された再生方法。
4. ストリームオブジェクトが１以上集まってストリームデータが構成され前記ストリームオブジェクトが所定のタイムスタンプが付されたパケットを１以上含むパケット群を含むように構成されたデータ構造を用いて情報記録あるいは記録情報の再生を行うものであって、前記ストリームデータおよびこのストリームデータと異なるリアルタイムビデオオブジェクトデータが混在記録可能なデータエリアと前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータをファイル管理するファイルシステム情報を記録するエリアと前記ストリームデータの管理情報を記録する管理エリアを持ち、前記ファイルシステム情報によりファイル管理される前記ストリームデータおよび前記リアルタイムビデオオブジェクトデータのファイルが単一のディレクトリに格納されるように構成され、前記ストリームデータの再生順にしたがって並んだセルがあるときに前記ストリームデータの管理情報が前記セルの開始時間情報および前記セルの終了時間情報を含み、前記セルの開始時間情報および前記セルの終了時間情報が前記パケットの到着時間でもって表現されるように構成された情報記憶媒体を用いる再生装置において、
   前記情報媒体から前記管理情報を再生する手段と、前記ストリームオブジェクトを再生する手段とを具備した再生装置。

Images