(57)【特許請求の範囲】
【請求項１】
デジタルフォーマットの別個の連続したデータパケットに配列された情報を表す情報信号の実質的にリアルタイムなストリームを、前記データパケットのサイズより大きな所定サイズの記録の単位を持つディスク状記録担体上に記憶する方法であって、
前記情報信号の直列ストリームを受信するステップと、
前記情報信号の直列ストリームにおける前記データパケットを検出するステップと、
基準タイムベースカウンタに対する前記データパケットの到来時間に対応したアプリケーションパケット到来時間（APAT）を確立するステップであって、該アプリケーションパケット到来時間（APAT）が、各ビットが所定の時間間隔に対応した複数のビットを有するステップと、
前記アプリケーションパケット到来時間（APAT）のビットを選択して、アプリケーションタイムスタンプ（TM-APP）を導出するステップと、
データパケットと、該データパケットに関連するアプリケーションタイムスタンプ（TM-APP）とをソースパケットに収集すると共に、複数のソースパケットをパックヘッダを持つストリームパック（S_PCK）に収集するステップであって、前記ストリームパック（S_PCK）のサイズが前記ディスク状記録担体の前記記録の単位の前記所定サイズに対応するようなステップと、
前記ストリームパック（S_PCK）にソースパケット検索情報を記憶するステップと、
前記パックヘッダに前記アプリケーションタイムスタンプ（TM-APP）に関する情報を記憶して、基準タイムベースの導出を可能にするステップと、
を有することを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記ストリームパック（S_PCK）が、２０４８バイトなる固定サイズを有していることを特徴とする方法。
【請求項３】
請求項２に記載の方法において、前記パックヘッダが３バイトの開始コード領域（Start_code_prefix）で開始し、該領域には直に１バイトのストリーム識別領域（Stream_id）が続くことを特徴とする方法。
【請求項４】
請求項３に記載の方法において、前記ストリーム識別領域が、ＭＰＥＧ符号化フォーマットに従う私用ストリーム２（private_stream_2）を識別する識別情報を有していることを特徴とする方法。
【請求項５】
請求項４に記載の方法において、前記ソースパケット検索情報が、対応するストリームパック（S_PCK）におけるソースパケットの開始の数（Number_of_start）と、前記対応するストリームパック（S_PCK）における第１ソースパケットの第１バイトの位置に関する情報（Start_offset_first_packet）とを有していることを特徴とする方法。
【請求項６】
デジタルフォーマットの別個の連続したデータパケットに配列された情報を表す情報信号の実質的にリアルタイムなストリームを、前記データパケットのサイズより大きな所定サイズの記録の単位を持つディスク状記録担体上に記憶するシステムであって、
前記情報信号の直列ストリームを受信する受信手段と、
前記受信手段に接続されて、前記受信された情報信号をディスク状記録担体上に記録するためにストリーム化する手段と、
を有し、該ストリーム化手段が、
基準タイムベースカウンタに対する前記データパケットの到来時間に対応したアプリケーションパケット到来時間（APAT）を確立すると共に、各ビットが所定の時間間隔に対応した複数のビットを有する該アプリケーションパケット到来時間（APAT）のビットを選択して、アプリケーションタイムスタンプ（TM-APP）を導出する局部クロック基準手段及びタイムスタンプ発生手段と、
を有し、前記ストリーム化手段が、更に、
受信されたデータパケットと該データパケットに関連するアプリケーションタイムスタンプ（TM-APP）とをソースパケットに収集すると共に、複数のソースパケットをパックヘッダを持つストリームパックに収集する収集手段であって、前記ストリームパック（S_PCK）のサイズが前記ディスク状記録担体の前記記録の単位の前記所定サイズに対応し、前記収集手段が前記ストリームパック（S_PCK）にソースパケット検索情報を記憶すると共に、前記パックヘッダに前記アプリケーションタイムスタンプ（TM-APP）に関する情報を記憶して、基準タイムベースの導出を可能にするように構成された収集手段と、
前記ストリームパック（S_PCK）をディスク状記録担体上に記録する記録手段と、
を有することを特徴とするシステム。
【請求項７】
請求項６に記載のシステムにおいて、前記ストリームパック（S_PCK）が、２０４８バイトなる固定サイズを有していることを特徴とするシステム。
【請求項８】
請求項７に記載のシステムにおいて、前記パックヘッダが３バイトの開始コード領域（Start_code_prefix）で開始し、該領域には直に１バイトのストリーム識別領域（Stream_id）が続くことを特徴とするシステム。
【請求項９】
請求項８に記載のシステムにおいて、前記ストリーム識別領域が、ＭＰＥＧ符号化フォーマットに従う私用ストリーム２（private_stream_2）を識別する識別情報を有していることを特徴とするシステム。
【請求項１０】
請求項９に記載のシステムにおいて、前記ソースパケット検索情報が、対応するストリームパック（S_PCK）におけるソースパケットの開始の数（Number_of_start）と、前記対応するストリームパック（S_PCK）における第１ソースパケットの第１バイトの位置に関する情報（Start_offset_first_packet）とを有していることを特徴とするシステム。
【請求項１１】
デジタルフォーマットの別個の連続したデータパケットに配列された情報を表す情報信号の実質的にリアルタイムなストリームを再生するシステムであって、該システムが、
ディスク状記録担体から、ディスク状記録担体上の記録の単位に対応するストリームパック（S_PCK）を読み取る読取手段であって、前記ストリームパック（S_PCK）が前記データパケットのサイズより大きなサイズを有し、ストリームパック（S_PCK）は、各々が対応するアプリケーションタイムスタンプ（TM-APP）と共にソースパケットに配列された複数のデータパケットを有し、該ストリームパック（S_PCK）がソースパケット検索情報及び基準タイムベースの導出を可能にするための前記アプリケーションタイムスタンプ（TM-APP）に関する情報を持つパックヘッダを有するような読取手段、
を有し、前記読取手段が、
ストリームパック（S_PCK）から、前記ソースパケット検索情報に対応して前記ソースパケットを回復するように構成された回復手段と、
対応する前記アプリケーションタイムスタンプ（TM-APP）に基づいて、基準タイムベースを導出すると共に前記データパケットを実質的にリアルタイムなストリームとして出力するように構成されたタイミング回復手段と、
を有していることを特徴とするシステム。
【請求項１２】
請求項１１に記載のシステムにおいて、前記ストリームパック（S_PCK）が、２０４８バイトなる固定サイズを有していることを特徴とするシステム。
【請求項１３】
請求項１２に記載のシステムにおいて、前記パックヘッダが３バイトの開始コード領域（Start_code_prefix）で開始し、該領域には直に１バイトのストリーム識別領域（Stream_id）が続くことを特徴とするシステム。
【請求項１４】
請求項１３に記載のシステムにおいて、前記ストリーム識別領域が、ＭＰＥＧ符号化フォーマットに従う私用ストリーム２（private_stream_2）を識別する識別情報を有していることを特徴とするシステム。
【請求項１５】
請求項１３に記載のシステムにおいて、前記ソースパケット検索情報が、対応するストリームパック（S_PCK）におけるソースパケットの開始の数（Number_of_start）と、前記対応するストリームパック（S_PCK）における第１ソースパケットの第１バイトの位置に関する情報（Start_offset_first_packet）とを有していることを特徴とするシステム。
【発明の詳細な説明】
【０００１】
【技術分野】
本発明は、請求項１の前置部に記載したような情報信号の略リアルタイムなストリームを記憶する方法、及び請求項６の前置部に記載したような該方法を実施するシステムに関する。
【０００２】
【背景技術】
ＭＰＥＧ符号化ビデオ情報信号のようなリアルタイム情報信号を記録担体上に記録する装置は、例えば、米国特許第5,579,183号（出願人整理番号：PHN14818）から既知である。該文献における記録担体は、長尺形状のものである。ディスク状記録担体に関しては、情報信号を記録するためのフォーマットがヨーロッパ特許出願公開第EP-A814475号から既知である。ＤＶＤフォーマットと呼ぶこのフォーマットは、プログラム要素ストリームパケットを記憶するためのプログラムストリームフォーマットを使用している。プログラムストリームは、プログラムストリームヘッダ、プログラム要素ストリームヘッダ、アプリケーションヘッダ及び１９４８バイトのパケットペイロードを有している。例えばＭＰＥＧストリームにおける伝送パケットのような、情報信号のリアルタイムストリームにおけるアプリケーションパケットは、プログラムストリームパケットのパケットペイロードに記憶することができる。斯様な伝送パケットは１８８バイト長であるので、所要の追加のタイムスタンプが４バイトの場合、１９４８バイトの１パケットペイロードには１９２バイトの１０倍しか記憶することができず、２８バイトは未使用のまま残る。加えて、上記プログラムストリームヘッダ及びプログラム要素ストリームヘッダは、ＭＰＥＧにおいては必須である追加のタイムスタンプ（各々、ＳＣＲ及びＰＴＳ）を含んでいる。これは、複雑さ及び記憶に対して効率の低下に繋がる。更に、デジタルビデオ（ＤＶ）の場合におけるアプリケーションパケットは４８０バイト長である。上記パケットペイロードには４つの斯様なアプリケーションパケットしか記憶することができず、これも未使用バイトに繋がる。他の種類のアプリケーションパケットが、例えば、ＡＴＭフォーマットに見られる。従って、プログラムストリームのパケットペイロードへのアプリケーションパケットの記憶は、通常、効率の低下に繋がる。
【０００３】
本発明の目的は、上記の不利な点を克服し、もっと一般的には、リアルタイムストリームからのアプリケーションパケットをディスク状記録担体に記憶する問題を克服することにある。
【０００４】
【発明の開示】
本発明は、上述したもののような種々の要件を可能にする手段を設けることを目指すものである。本発明によれば、上記方法は請求項１に記載したように構成される。
【０００５】
ソースパケット検索情報の挿入は、データパケットのサイズとは独立に、ストリームパックへのデータパケットの柔軟性のある記憶を可能にする。これは、構成情報を許容しないようなIEC/ISO13818-1及びIEC/ISO138180-2に指定されているＭＰＥＧフォーマットに従うプログラムストリームのパケットペイロードへのデータパケットの記憶と比較して、斯かるデータパケットを記憶するための一層効率的な方法を可能にする。
【０００６】
好ましいサイズのストリームパックは２０４８バイトであり、CD-R/RW、DVD-R/RWのような記録可能な又は再書込可能な光ディスク型記録担体の記録の単位である。
【０００７】
有利な方法は、ストリームパックの第１バイトを請求項３に従って規定することにより得ることができる。この規定は、許容される所謂私用ストリーム用のＭＰＥＧフォーマットによる必須バイトに対応する。これらの私用ストリームに関しては、通常のＭＰＥＧプログラムストリームと比較して、より少ないバイトしか必須とならない。私用ストリームを用いてＭＰＥＧシステムフォーマットに適応化させることは、DVD-R/RWのような光ディスク用の現在の規格化されたフォーマットとの互換性の点で利点を有している。
【０００８】
他の有利な方法が、請求項４に従う方法により得られる。ＭＰＥＧフォーマットの私用ストリーム２は、私用ストリーム１よりも制限に拘束されることが少なく、データパケットの記憶に利用可能な一層多くの空間を残存させる。
【０００９】
ソースパケット検索情報を記憶する有利な方法が、請求項５に従う方法により得られる。最初の新ソースパケットの開始をストリームパック内でずらすことは、先行するストリームパック内の最終ソースパケットの残部を記憶することを可能にする。
【００１０】
本発明の、これら及び他の特徴は、以下の説明における実施例から明らかとなり、及び斯かる実施例を参照して解説されるであろう。
【００１１】
【発明を実施するための最良の形態】
図１は、情報信号のリアルタイムストリームをディスク状記録担体上にストリーム化する装置を示す。デジタル放送を受信するセットトップボックス（ＳＴＢ）は、リアルタイム情報信号源の単なる一例である。他の情報源は、例えば、ＤＶＤ再生装置である。
【００１２】
ストリーマにおけるアプリケーション処理は、アプリケーションパケットのタイムスタンプ処理（必須）、アプリケーションパケットのセクタ上へのマッピング（必須）、STREAMER.IFOファイルの生成及び処理（必須）、入力ストリームの構文解析及び提示タイミングの導出（オプション）、入力ストリームのサービス情報の処理（オプション）、並びにエントリポイント、テキスト、情報（info）等の編集（オプション）からなることができる。
【００１３】
ファイルシステムは、記録の間に入力ファイルをビットエンジンの論理アドレス空間上にマップし、当該ディスクからデータを取り出す。
【００１４】
図２は、ディスク上のストリーマデータ及びナビゲーションデータの構成を示す。特に、ストリーマファイルは、ＤＶＤフォーマットに従いユーザ定義プログラムチェーン（UD-PGC）及びオリジナルプログラムチェーン（ORG-PGC）を用いてデータの構成に関連して示される。セル情報（Cells Info）は、どのストリームオブジェクト（ＳＯＢ）が再生されるべきかを示し（再生リスト）、一方、ストリームオブジェクト情報（SOBI）は各ストリームオブジェクトのアドレスを含む。ビデオ又はオーディオ情報自体はストリームオブジェクト（ＳＯＢ）内に含まれる。
【００１５】
アプリケーションレイヤの入力信号は、リアルタイムデータストリーム（例えば、部分的伝送ストリーム）である。該アプリケーションレイヤの上記ファイルシステムへの出力信号は、２つのファイルであり（RTRWシステムにおけるのと同様に）、一方はストリームデータ（STREAMER.SOBファイル）を含み、他方はナビゲーションデータ（STREAMER.IFOファイル）を含む。
【００１６】
図３は、基準タイムベースカウンタのフォーマットを示す。全ての使用されるタイムスタンプ処理方法は、６バイトの基準タイムベースカウンタからのビットを使用する。クロック周波数は２７ＭＨｚである。先ず、この２７ＭＨｚが３００により分割される。これらビットは、TM-Ext b0〜b8（９ビット）で表される。ビットb8は９０ｋＨｚのクロック周波数を表す。この９０ｋＨｚのクロック周波数が次のカウンタで使用される。ここで、ビットTM-Base b9〜b47が決定される。このカウンタは、〜７０日の期間の範囲となる。
【００１７】
図４における表は、時間軸上のタイムスタンプ用の最も重要なビットの重みを与える。ここで、MPEG2においては、ＰＣＲ、ＳＣＲ、ＰＴＳ及びＤＴＳが：
ＰＣＲ＝＞b41〜b0  （４２ビット）
ＳＣＲ＝＞b41〜b0  （４２ビット）
ＰＴＳ＝＞b41〜b9  （３３ビット）
ＤＴＳ＝＞b41〜b9  （３３ビット）
を用いて、このフォーマットで表されることを付記する。
【００１８】
当該ストリーマ装置の入力端及び出力端においては、ストリーマデータは多数のアプリケーションパケットからなり、これらパケットはパケット間の不規則な間隔で到来する。アプリケーションパケットの到来時間（APAT）は、上記基準カウンタの６バイトで表される。
【００１９】
図５Ａは、MPEG2伝送ストリームの場合のストリームデータの例を示している。これらパケットの幾つかはＰＣＲタイムスタンプを有し、これらパケットの幾つかは対応するアクセス単位（ビデオ、オーディオ、副画像）用の提示タイムスタンプ（ＰＴＳ）又は復号タイムスタンプ（ＤＴＳ）を有する。ＰＣＲは上記２７ＭＨｚのシステムクロック（ＰＣＲにＰＬＬロックされた）を導出するのに使用することができる。
【００２０】
当該ストリーマ装置の出力端において、アプリケーションパケットの相対位置は回復されねばならない。この目的のため、全てのアプリケーションパケットの前にはタイムスタンプが挿入される。図５Ｂに示すように、APATビットの全てが該タイムスタンプ（TM-APP）に使用されるのではない。該タイムスタンプが４バイトの大きさである（MPEG2-TS記録用として提案されているように）場合は、ビットb0〜b31が使用される。４バイトを用いると、〜９０秒の期間を表すことができる。
【００２１】
図６は、上記ストリーマにおけるタイミング回復の一例を示している。記録の間において、タイムスタンプは２７ＭＨｚカウンタのカウンタ位置から導出される。MPEG2-TSの場合は、好ましくは、クロック周波数はＴＳのＰＣＲにロックされる。再生の間においては、カウンタ値がタイムスタンプ値と比較される。両者が等しくなるやいなや、アプリケーションパケットは出力端に出力される。トラックバッファには常に充分なデータが存在しなければならない。
【００２２】
連続的に記録された全てのアプリケーションパケットは、ストリームオブジェクト（ＳＯＢ）に編成される。ＳＯＢ内で、タイムスタンプを導出する６バイト基準カウンタが、如何なるリセット及び／又は循環（ラップアラウンド）も無しに連続的に計数する。ＳＯＢのアプリケーションパケットは、S_PCK又はセクタと呼ばれる“ストリームパック”の系列に詰め込まれる。これが図７に示されている。該ストリームパックの長さは、２０４８バイトである。ストリームパックは１４バイトのヘッダと、２０３４バイトのペイロードとを有している。該ペイロードは、ソースパケットと、必要なら、幾つかの埋め込みバイトとからなっている。
【００２３】
図８は、ソースパケットのフォーマットを示している。ソースパケットは、MPEG TSパケットの場合、前に（もしあるなら）４バイトのタイムスタンプ（TM-APP）を伴う、１８８バイトのアプリケーションパケットからなる。全ソースパケット長は１９２バイトとなる。
【００２４】
図９は、S_PCK上へのアプリケーションパケットのマッピング及びMAPU上へのS_PCKのマッピングを示している。ディスク上のＥＣＣブロック内で多数のS_PCKが収集される。ＥＣＣブロックの大きさは、マッピング単位（MAPU）の単位として使用される。ソースパケットはMAPU内の最初のS_PCKに位置合わせされる。S_PCK内への埋め込みが許容され、時には必要とされる。ディスク上の情報へのアクセスはＥＣＣブロックに基づくものであることに注意すべきである。ＥＣＣブロックのディスク上へのマッピングは、前記ファイルシステムにより実行される。アプリケーションレイヤにおいては、１つのＥＣＣブロック内にどのS_PCKが集められるかが分かる。ＥＣＣブロック当たりのセクタ数はドライブに依存し、DVD-R/RWの場合はＥＣＣブロック当たり１６セクタ、DVD-RAMの場合はＥＣＣブロック当たり１６バイト、及びDVD+RWの場合はＥＣＣブロック当たり１６セクタである。次世代においては、ＥＣＣブロックのサイズは増加されることが期待される。
【００２５】
図１０は、S_PCKをソースパケットで満たす例を示している。MAPUはＮ個のS_PCKを含んでいる。埋め込みビットは、S_PCKの終了部にあってもよく（第２行）、開始部にあってもよく（第３行）、並びに開始部及び終了部の両方にあってもよい（第４行）。また、S_PCKが埋め込みビットのみを含んでいてもよい（第５行）。最初のS_PCKは、常に、新たなソースパケットで開始する（第１行）。更に、S_PCKは不完全なソースパケットで終了してもよい（第１及び第３行）。埋め込みビットの後には、常に、新たなソースパケットが続く。埋め込みは、MPEG TS及びMAPU当たり３２S_PCKの場合は必要ではないことに注意されたい。その場合、正確に３３９個のＴＳパケットが１つのMAPUにはまる。埋め込みは、ソースパケットがMAPUの最終S_PCKに又はＳＯＢの最後に最早はまらない場合に適用される。ＳＯＢは完全なMAPUで終了される。１以上のS_PCKを埋め込みバイトで満たすことができる。
【００２６】
図１１はパックヘッダの内容を示している。該ヘッダの幾つかのフィールドを以下に説明する。
【００２７】
開始コード接頭語（Start_code_prefix）は000001hである。MPEG装置はＰＳヘッダの最初の４バイトのみを識別する一方、完全なＤＶＤヘッダは１４バイトを含むことに注意されたい。
【００２８】
ストリーマフォーマット用のストリームid（Stream_id）が定義されるべきである。このストリームidは、フォーマッティングがストリーマ仕様に従うことを示す。ストリームidには２つの可能性がある：
ａ）1111 1110 => データストリーム用に確保された数［1111 XXX0］
ｂ）1011 1111 => 私用ストリーム２（Private_Stream_2）
私用ストリーム１（Private_Stream_1）は私用ストリーム２に反して一層多くの制限を受ける。例えば、MPEGの場合、私用ストリーム１内の全てのストリームＩＤが既に定義されている。
【００２９】
アプリケーションid（Application_id）は、どの型式のビットストリームが記録されるかを示す。図１２参照。最終的に、このＩＤはSOB-GI内に代替え的に存在し得る。
【００３０】
ソースパケット長（Source_packet_length）は、その長さをソースパケットのバイトの数（タイムスタンプを含む）で指定する。数０は許容されない。これは、代わりにSOB-GIで特定される。
【００３１】
タイムスタンプ長（Timestamp_length）は、その長さをタイムスタンプのバイトの数で特定する。該タイムスタンプの位置は、対応するパケットの前である。ここでも、パケットヘッダの代わりに、これをSOB_GI内で特定することができる。
【００３２】
長さ０は、タイムスタンプが存在しないことを示す。
【００３３】
タイムスタンプクロック周波数（Timestamp_clock_frequency）は、タイムスタンプの基準クロック周波数を特定する。図１３に示す表が使用される。
【００３４】
開始オフセット第１パケット（Start_offset_first_packet）はS_PCKにおける第１アプリケーションパケットの最初のバイトの位置を示す。該バイト位置は、S_PCKの第１バイトの０で開始するバイトの数で与えられる。ソースパケットは、S_PCKと位置合わせされる必要はない。開始位置は、S_PCKの開始部に対してバイトで与えられる。開始オフセット（Start-offset）＝１４は、ソースパケットがペイロードの開始部で開始することを意味し、開始オフセット＝０〜１３は、ソースパケットの開始部がないことを意味する。
【００３５】
埋め込み位置（Padding_position）はS_PCK内の埋め込みバイトの位置を示す。例として、埋め込みがS_PCKの開始部で許される場合：
0000 => 埋め込み無し
0001 => S_PCKの開始部における埋め込み
0010 => S_PCKの終了部における埋め込み
0011 => S_PCKの開始部及び終了部の両方における埋め込み
0100 => このS_PCKには埋め込みのみ
となる。厳密に言うと、上記0100状態は必要ではない（開始及び終了の両方における埋め込みであって、開始ソースパケットの数（Number_of_Start_Source_packets）＝０は、当該セクタ内には埋め込みビットのみしか発生しないことを意味する）。
【００３６】
開始ソースパケットの数は、S_PCK内のソースパケットの開始部の数を示す。オフセット開始位置（offset_start_position）、開始部の数（number_of_starts）及びソースパケット長（Length_Source_packets）を用いれば、埋め込みバイトの開始位置を導出するのは簡単である。
【００３７】
タイムスタンプクロック周波数（Timestamp_clock_freq.）、開始オフセット第１パケット（Start_offset_first_packet）、埋め込み位置（Padding_position）及び開始の数（Number_of_Start）のフィールドは各セクタに対して固有であり得るので、パックヘッダ内に存在しなければならない。
【００３８】
DEMI（ディスク暗号モード指示子）は、5C-DTDGの提案からの更新されたＥＭＩビットを表す。注意：非認知ストリーマはIEEE1394バスからのＥＭＩビットしかコピー制御に関して考慮しない。これらのビット（新たな状況に更新された）は記憶されねばならない。
【００３９】
図１４は、SOBUの作成を示している。ＳＯＢにおいては、アプリケーションパケットがS_PCK上にマップされる。SOBIテーブルにおいては、時間軸をＳＯＢ内の相対位置にマップするマッピングテーブルが使用される。この目的のため、ＳＯＢはストリームオブジェクト単位（SOBU）に副分割される。該SOBUはRTRW仕様におけるVOBUと比肩することができる。VOBUにおいては、データファイル内のＧＯＰの位置を計算することができる。SOBIテーブルを用いれば、STREAMER.SOBファイル内のSOBUの位置、及びそれらのＳＯＢの開始部に対する相対タイミングを再現することができる。SOBUは整数個のMAPUを含んでいる。各SOBUがアプリケーションパケットのタイムスタンプで開始することに注意されたい。SOBU当たりのセクタの最大数は６４である。SOBU当たりのMAPUの最大数は、MAPUのサイズが１６セクタの場合は４であり、MAPUのサイズが３２セクタの場合は２である。SOBUはＥＣＣブロックの整数量に等しいことに注意されたい。
【００４０】
SOBI内のSOBUマッピングテーブルから、再生時間とSTREAMER.SOBファイルにおけるデータの位置との間の関係を見付けることができる。図１５に示すように、SOBI#kテーブルは以下の構造を有している。SOBU-MAPLは、基準時間軸上へのアプリケーションパケットの到来時間（TM-SOBU、エントリの最初の１０バイト）のマッピングを含んでいる。SOBU内ではセクタの数は一定であるので、アプリケーションパケットの到来時間とストリームファイル内の位置（TM-Sector、エントリの最後の６バイト）との関係を導出するのは簡単である。PRES-MAPL（オプションである）においては、アクセス単位の提示時間は、対応するSOBU番号を指す。このようにして、提示時間とストリームファイル内の位置との間の関係を見付けることができる。上記のオプションのPRES-MAPLはMPEGの場合に有利である。MPEGストリームにはＰＴＳが存在しないので、例えばトリック再生に関しては提示に遅延が生じるであろう。PRES-MAPLテーブルを用いれば、これを防止することができる。
【００４１】
SOBI#kの一般情報（General Information）は、全SOB#kに対して一定のパラメータを含んでいる。SOBI#kの一般情報は、MAPUサイズ（例えば、１６又は３２等のセクタで）及びSOBUサイズ（例えば１６又は３２等のMAPUで）を含んでいる。
【００４２】
各SOBU-MAPLのエントリは２つのフィールド、即ちTM-SOBU（１０ビット）及びTM-Sector（６ビット）、からなる。
【００４３】
SOBUタイムスタンプ（TM-SOBU）は、SOBUからの第１アプリケーションパケットのAPATの一部である。これが、図１６Ａに図示されている。ＴＭＵシフト（TMU-shift）はＳＯＢにおける各SOBUに対して一定である。ＴＭＵシフトは、SOBU-MAPLの一般情報において記述される。ＴＭＵシフトは、
−  TM-SOBUの循環間隔は、SOBUの最大間隔よりも大きい。さもなければ、曖昧な値になる。
−  ＴＭＵシフト＜２３。TM-APPと一緒に、APATのビットは失われない（ＭＳＳを除く）。これは、絶対時間基準を復元するために要する。
−  時間軸上の分解能が充分に高い。TM-SOBUに対する同一番号の後続のSOBUは許されない。
のように選択されねばならない。
【００４４】
図１６Ｂは、絶対時間軸をどのように構成するかを示している。図１７は、TM-Sectorを示している。TM-SOBUにおいて、第１アプリケーションパケットのAPATの一部が記述される。前のSOBUには、同一のTM-SOBUが有効な幾つかのアプリケーションパケットが存在する可能性がある。ＳＯＢにおける、このSOBUの位置の分解能は、SOBUエントリにおける第２フィールドを使用することにより、同一のTM-SOBUが導出されるようなアプリケーションパケットを含む、この及び前のSOBUにおけるセクタの数でもって改善される。これは、アクセス時間を改善する。
【００４５】
SOBU-MAPL用の一般情報は、ＴＭＵシフト、開始APAT、終了APAT、ADR-OFS、第１SOBUにおけるMAPUの数、最終SOBUにおけるMAPUの数及びエントリの数を含む。これが、図１８に示され、以下に簡単に説明する。
【００４６】
開始APAT：ＳＯＢに関係する第１アプリケーションパケットのAPAT。ＳＯＢの部分的削除の後では、該ＳＯＢの第１アプリケーションパケットはSOBUの開始部にある必要はない。
【００４７】
終了APAT：ＳＯＢに関係する最終アプリケーションパケットのAPAT。ＳＯＢの最終SOBUは、MAPUのSOBUサイズ（SOBU-size）を有する必要はない。データはMAPUに記録される。最終MAPUは多数の埋め込みセクタを有する可能性がある。
【００４８】
ADR-OFS：前のＳＯＢのセクタ数。
【００４９】
第１SOBUにおけるMAPUの数。部分的削除の後では、第１SOBUはSOBUサイズで示されるよりも少ないMAPUを有するかもしれない。
【００５０】
最終SOBUにおけるMAPUの数。最終SOBUはSOBUサイズに示されるよりも少ないMAPUを有する可能性がある。
【００５１】
提示タイムスタンプ（TM-PTS）を、MPEG2伝送ストリームを図示する図１９を参照して説明する。
【００５２】
MPEGデコーダにおいては、ＴＳにおけるＰＣＲが該デコーダの基準タイムベース（TM-base＋TM-ext）を導出するために使用される。PTSvは、このＰＴＳにより示されるビデオアクセス単位が提示されるべき時点を示す。該ＰＴＳを含むＴＳパケットの到来時間と、このアプリケーションパケットが復号されるべき時点との間には遅延が存在するであろう。ＰＴＳは常に未来を指している。最大遅延は〜１秒である。
【００５３】
幾つかのフィーチャ（編集、トリック再生、…）に関しては、１秒は充分ではない。これが、マッピングテーブルに別のエントリが作成される理由である。この副テーブルには、提示時間のマッピングが掲載される。MPEG2 TSが構文解析される。Ｉ画像からのＰＴＳを伴うＴＳパケット（ＧＯＰの開始部）が検索される。PRES-MAPLテーブルには、これらＰＴＳの値及び対応するSOBUへのポインタが掲載される。
【００５４】
PRES-MAPLテーブルは、下記のフィールドを含む。提示時間（TM-PRES）、対応するSOBU番号（SOBU-PRES）、SOBUにおける対応するセクタ（Sector-PRES）及びＩ画像のセクタ数（Sector-Iframe）である。
【００５５】
提示マッピングリストのタイムスタンプ（TM-PRES）が、図２０に示されている。
【００５６】
TM-PRES-fineの分解能は、画像のフレーム期間より小さくなくてはならない。TM-presの循環は＞１秒（到来時間とＰＴＳとの間の最大遅延）でなければならない。TM-PRESの分解能は２２msecにとられる（TM-base b20）。基準カウンタからb20〜b27が使用される。上記循環は＞５.６秒であり、これは、もし多数のＧＯＰが該リストでスキップされたとしても、充分である。
【００５７】
SOBU-PRESは１０ビットで表される。PRES-MAPLにおけるSOBU用の循環番号付けは１０２４である。
【００５８】
Sector-PRES（６ビット）は、ＰＴＳを含むSOBU内のセクタ数を与える。
【００５９】
Sector-Iframe（８ビット）は、対応するＰＴＳからのIフレームデータを含むセクタの数を与える。
【００６０】
SOBI#kにおけるPRES-MAPL用の一般情報は、ＰＴＳ第１アプリケーションパケット及びSOBU番号付けのオフセットを含む。ＰＴＳ値は基準カウンタにおける開始オフセットを見付けるために使用される。PRES-MAPLにおいては、SOBU番号に対しては絶対数が使用される。部分的削除の後に、該番号はオフセットを得る。この番号は、このテーブルに対する一般情報に記述される。
【００６１】
図２１は、STREAMER.IFOテーブルの内容を示している。全ての関係のないフィールド（ナビゲーション用）は削除してある。ストリームファイル情報テーブル（SFIT）のみが説明される。イタリック体の項目のみがデータエントリを表している。
【００６２】
次ぎに、伝送ストリーム[MP&ML]部分的ＴＳの放送記録用デフォルト設定の一例を説明する。
−  伝送ストリーム（アプリケーション）パケットのサイズは１８８バイトである。
−  平均ビットレートは、多分、〜６Mbpsである。（平均間隔、〜０.５秒）
−  MAPUのサイズ：１つのＥＣＣブロックに１６のS_PCKがマップされる。
−  SOBUのサイズ：４MAPU（１SOBU＝１２８ｋバイト）
−  ６Mbps => SOBU間隔は〜１６６msecである。
−  ディスク（４.７ＧＢ）当たりのSOBUエントリの数 => 40,000
−  MTU-shift＝１０
−  タイムスタンプ（TM-SOBU）カウンタの分解能は１１msecである。
−  循環時間間隔は１１.６秒である。
【００６３】
メモリにSOBIデータを読み込む間に完全なAPATを再現することは簡単であることに注意されたい。開始APATはSOBI一般情報で与えられ、循環を検出することができる。３時間記録の場合、１０００の循環があるのみである。
−  最大ビットレートは、１１msec内での１２８ｋバイトに相当し、これは〜１００Mbpsとなる。
−  最小ビットレートは、１１秒内での１２８ｋバイトに相当し、これは〜１００kbpsとなる。
【００６４】
PRES-MALに関しては：
−  ４.７ＧＢのディスク及び６Mbpsの入力レートに対する再生時間：約１０４分（６２５１秒）
−  ＧＯＰ長（仮定）０.４秒。テーブルへのエントリの数１５６２８
【００６５】
入力及び出力においては、SOBUの持続期間＞１００msecであることに注意されたい。このSOBUは１００msec未満でディスクから読み取ることができる。これは、〜１秒のジャンプ時間及びAPATに対するＰＴＳの最大遅延（１秒）に関して許容されるであろう。
【００６６】
高速アクセスに対しては、PRES-MAPLが使用されるべきである。このマッピングは正確である（セクタ番号）。高速アクセスが必要であるがPRES-MAPLが無い場合は、ＳＯＢサイズは２MAPU（又は１MAPU）とされる。
【００６７】
次ぎに、DRAMに追加のテーブルを記憶することにより如何にしてアクセス時間を改善することができるかを例示する。該テーブルは、絶対SOBU番号と全提示時間とを含んでいる。この追加のテーブル（PRES-MAPL-Courseと呼ばれる）は２つのエントリを有している。即ち、TM-PRES-Course（１６ビット）及びSOBU-PRES-Course（３２ビット）である。
【００６８】
図２２は、TM-PRESコース（TM-PRES-course）を図示している。循環TM-PRESコースは、プログラムの持続期間より大きくなくてはならない。TM-PRESコースの分解能はTM-PRESエントリにおける循環より小さくなくてはならない。
【００６９】
ディスク上のSOBUの数は非常に大きい可能性がある。SOUBの最小のサイズは１６セクタであり、ディスク（４.７ＧＢ）当たりのセクタの最大数は２.４Ｍであり、ディスク当たりのSOBUの数は１５０ｋである。ディスク上の特定のSOBUを指すには１８ビットが必要である。SOBU-PRESコース（SOBU-PRES-course）に対しては、３２ビットが確保される。
【００７０】
SOBU-PRES番号における各循環（１０２４SOBU毎）に対して、エントリが存在すべきである。４.７ＧバイトのディスクにおけるMPEG TS記録に対しては、ディスク上に３７６００のSOBUが存在する。従って、該テーブルには４０のエントリしか必要とされない。このテーブルのサイズは無視することができる（〜２４０バイト）。
【００７１】
図２３は、上記テーブルのサイズを示す。SOBU-MAPLテーブルに関しては、SOBUサイズに対するデフォルト値は６４セクタ（１２８ｋバイト）である。４.７Ｇバイトのディスク上には３７６００のSOBUがはまり、その場合、SOBU-MAPLのサイズは〜８０ｋバイトである。
【００７２】
PRES-MAPLテーブルに関しては、ディスク上の３時間の再生時間及び０.５秒のＧＯＰ持続時間を期待すると、該テーブルのエントリの数は２１６００となる。この場合、PRES-MAPLファイン（PRES-MAPL-fine）のサイズは〜８０ｋバイトとなる。
【００７３】
次ぎに、完全なＳＯＢの削除を説明する。ストリーマＳＯＢファイルにおいてＳＯＢが除去されると、これは当該ファイルからＳＯＢを除去した後、大きな番号を持つ他のＳＯＢにおける全てのアドレス指定が修正されることを意味する。前記ファイルシステムが、論理アドレス空間に対するマッピングを変更する。図２４Ａは削除前のストリーマＳＯＢファイルを図示する一方、図２４Ｂは削除後のストリーマＳＯＢファイルを図示している。
【００７４】
SOBI#2（削除前のSOBI#3）において、SOBI#2一般情報でADR_OFSが変更される。該SOBIテーブルにおける他の全ての情報は、同一に維持される。ファイルシステムは、STREAMER.SOBファイル（SOB#2は前のSOB#3である）の最終部分が論理アドレス空間内で正しいロケーションを指すようにしなければならない。
【００７５】
先ず、STREAMER.IFOデータのみを使用する第１方法を、図２５Ａ（ＳＯＢの部分的削除前の状態を示している）及び図２５Ｂを参照して説明する。
【００７６】
ＳＯＢの開始部が削除される。当該ストリーマのアプリケーションレイヤにおいて、該部分的に削除されたＳＯＢの開始部から開始すべきかが判断される。ストリームデータを調べない場合、アプリケーションレイヤはSOBUの開始部に関する情報しか有していない。開始位置がマッピングテーブルにおける２つのエントリポイントの間にある場合は、新たなＳＯＢは最も小さな番号のSOBUで開始する。より小さなAPATを持つ全てのエントリポイントは該テーブルから削除される。
【００７７】
同様の方法が、ＳＯＢの終了部を削除する場合にも使用される。
【００７８】
次ぎに、STREAMER.IFOデータ＋STREAMER.SOBを使用する第２方法を、図２６Ａ（ＳＯＢの部分的削除前の状態を示す）及び２６Ｂ（ＳＯＢの部分的削除後の状態を示す）を参照して説明する。
【００７９】
新たな開始／終了点を持つSOBUがメモリに読み込まれる。TM-APPが読み取られＲＧＢ、どのセクタに該新たな開始／終了点があるべきかを決定する。該新たな開始点APATがSOBU#2におけるMAPU#2のセクタ#7に位置すると仮定する。SOBU-MAPLにおいて、SOBUエントリ#0とエントリ#1とが削除され、全ての他のものは１つの位置づつ下方にシフトされる。このＳＯＢのADR-OFSは変更されない（大きな番号を持つＳＯＢのオフセットは、削除されたセクタの数で減少される）。SOBU#2からのMAPU#0及びMAPU#1は空きにされる。削除後では、SOBU#0は前記一般情報のSOBUサイズフィールドに記述されるよりも少ないMAPUを含む。SOB#kの第１（及び最後の）SOBUにおけるMAPUの数は、SOBU-MAPLの一般情報内に記述される。SOBU#0の第１MAPUにおける第１アプリケーションパケットのAPATは、TM-SOBU#0エントリに掲載される（前の例と同様に）。PRES-MAPLの一般情報においては、SOBU番号付けのオフセットは２に設定される。
【００８０】
次ぎに、PRES-MAPLの部分的削除を図２７Ａ（削除前の状況を示す）及び図２７Ｂ（削除後の状況を示す）を用いて簡単に解説する。TM-SOBU#0に対して、TM-SOBU#2の以前の値がとられる。SOB-StartのAPATはTM-SOBU#0に等しくされ、SOB-StartのＰＴＳが新たなＰＴＳ値となる。
【００８１】
データの検索を、図２８を参照して以下に説明する。読み取りはAPAT＝xxxで開始され、その際にSOBU#xエントリが見つかる（この場合、SOBU#j）。TMU-shift＝１０の場合、TM-SOBUのＬＳＢの重みは１１msecである。８Mbpsの平均ビットレートの場合、TM-Sectorsでの数は〜５とある。該APATがTM-SOBU内にある場合は、SOBU#j-1から最後のMAPU及びSOBU#jの最初のMAPUを読むだけで充分である。
【００８２】
最後に、上述したタイムスタンプの概要が図２９に示されている。
【００８３】
本発明は、各及び全ての新規な特徴又は斯かる特徴の組み合わせに存する。本発明の範囲は上記実施例に限定されるものではなく、如何なる参照符号も請求項の範囲を限定するものではない。また、本発明はハードウェア及びソフトウェアの両方により実施化することが可能であり、幾つかの“手段”は同一のハードウェア品目により表すことができる。更に、“有する”なる用語は、請求項に記載されたもの以外の要素又はステップを除外するものではない。
【図面の簡単な説明】
【図１】  図１は、情報信号のリアルタイムストリームをディスク状記録担体上にストリーム化する装置を示す。
【図２】  図２は、ディスク上におけるストリーマデータ及びナビゲーションデータの構成を示す。
【図３】  図３は、基準タイムベースカウンタのフォーマットを示す。
【図４】  図４は、上記基準タイムベースカウンタのビットの重みを与える表を示す。
【図５Ａ】  図５Ａは、MPEG-2TSの場合におけるストリームデータの一例を示す。
【図５Ｂ】  図５Ｂは、アプリケーションパケットのタイムスタンプ処理の一例を示す。
【図６】  図６は、ストリーマにおけるタイムスタンプ処理及び回復の一例を示す。
【図７】  図７は、ストリームパケット（S_PCK）の構造を示す。
【図８】  図８は、ソースパケットの構造を示す。
【図９】  図９は、アプリケーションパケットのストリームパケット上へのマッピング及びストリームパケットのマッピング単位（MAPU）上へのマッピングを示す。
【図１０】  図１０は、ストリームパケットをソースパケットで満たす例を示す。
【図１１】  図１１は、パックヘッダの内容を示す。
【図１２】  図１２は、ビットストリームの型式の例を示す。
【図１３】  図１３は、クロック周波数を指定するビット値を示す。
【図１４】  図１４は、ストリームオブジェクト単位（SOBU）の作成を示す。
【図１５】  図１５は、ストリームオブジェクト情報（SOBI）の内容を示す。
【図１６Ａ】  図６Ａは、ストリームオブジェクト単位のタイムスタンプ（TM-SOUB）を示す。
【図１６Ｂ】  図６Ｂも、ストリームオブジェクト単位のタイムスタンプ（TM-SOUB）を示す。
【図１７】  図１７は、セクタのタイムスタンプ（TM-Sector）を示す。
【図１８】  図１８は、ストリームオブジェクト単位マッピングテーブル（SOBU_MAPL）用の一般情報の内容を示す。
【図１９】  図１９は、提示用のタイムスタンプ（TM-PS）を示す。
【図２０】  図２０は、提示マッピングリストのタイムスタンプ（TM-PRES）を示す。
【図２１】  図２１は、STREAMER.IFOテーブルの内容を示す。
【図２２】  図２２は、提示マッピングリストのコースタイムスタンプ（TM-PRES-Course）を示す。
【図２３】  図２３は、ストリームオブジェクト単位及び提示のマッピングリストテーブル（SOBU-MAPL及びPRES-MAPL）のサイズを示す。
【図２４Ａ】  図２４Ａは、完全なストリーマオブジェクトの削除を示す。
【図２４Ｂ】  図２４Ｂも、完全なストリーマオブジェクトの削除を示す。
【図２５Ａ】  図２５Ａは、STREAMER.IFOのみを用いたストリーマオブジェクトの一部の削除を示す。
【図２５Ｂ】  図２５Ｂも、STREAMER.IFOのみを用いたストリーマオブジェクトの一部の削除を示す。
【図２６Ａ】  図２６Ａは、STREAMER.IFO及びSTREAMER.SOBを用いたストリーマオブジェクトの一部の削除を示す。
【図２６Ｂ】  図２６Ｂも、STREAMER.IFO及びSTREAMER.SOBを用いたストリーマオブジェクトの一部の削除を示す。
【図２７Ａ】  図２７Ａは、提示マッピングリスト（PRES-MAPL）を用いたストリーマオブジェクトの一部の削除を示す。
【図２７Ｂ】  図２７Ｂも、提示マッピングリスト（PRES-MAPL）を用いたストリーマオブジェクトの一部の削除を示す。
【図２８】  図２８は、データの検索を示す。
【図２９】  図２９は、幾つかのタイムスタンプを示す。
【符号の説明】
ＳＯＢ…ストリームオブジェクト
SOBI…ストリームオブジェクト情報
APAT…アプリケーションパケットの到来時間
ＰＴＳ…提示タイムスタンプ
S_PCK…ストリームパック
MAPU…マッピング単位
Stream_id…ストリームｉｄ
Private_Stream_2…私用ストリーム２
Start_offset…開始オフセット
SOBU…ストリームオブジェクト単位
【図１】
0004763892.tif 000002
【図２】
0004763892.tif 000003
【図３】
0004763892.tif 000004
【図４】
0004763892.tif 000005
【図５Ａ】
0004763892.tif 000006
【図５Ｂ】
0004763892.tif 000007
【図６】
0004763892.tif 000008
【図７】
0004763892.tif 000009
【図８】
0004763892.tif 000010
【図９】
0004763892.tif 000011
【図１０】
0004763892.tif 000012
【図１１】
0004763892.tif 000013
【図１２】
0004763892.tif 000014
【図１３】
0004763892.tif 000015
【図１４】
0004763892.tif 000016
【図１５】
0004763892.tif 000017
【図１６Ａ】
0004763892.tif 000018
【図１６Ｂ】
0004763892.tif 000019
【図１７】
0004763892.tif 000020
【図１８】
0004763892.tif 000021
【図１９】
0004763892.tif 000022
【図２０】
0004763892.tif 000023
【図２１】
0004763892.tif 000024
【図２２】
0004763892.tif 000025
【図２３】
0004763892.tif 000026
【図２４Ａ】
0004763892.tif 000027
【図２４Ｂ】
0004763892.tif 000028
【図２５Ａ】
0004763892.tif 000029
【図２５Ｂ】
0004763892.tif 000030
【図２６Ａ】
0004763892.tif 000031
【図２６Ｂ】
0004763892.tif 000032
【図２７Ａ】
0004763892.tif 000033
【図２７Ｂ】
0004763892.tif 000034
【図２８】
0004763892.tif 000035
【図２９】
0004763892.tif 000036