以下、図面を参照して、この発明の一実施の形態に係るストリームデータの生成方法、その記録方法、および記録されたストリームデータの部分消去処理方法その他を説明する。
図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。
DVD−RAMディスク等の情報記憶媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(以下、適宜SOBと略記する)としてまとめられている。各SOBは、1つのリアルタイムな連続記録により得られたストリームデータにより形成される。
図1(f)は、1以上あるストリームオブジェクトのうち1個のSOB#A・298について示している。DVD−RAMディスクにこのストリームデータが記録される場合には、各々が2048kバイトのセクタを最小単位として記録される。さらに、16個のセクタをまとめて1個のECCブロックとし、同一ECCブロック内でインターリーブ(データ配列順序の並び替え)とエラー訂正用の訂正コードの付加が行われる。
この実施の形態では、1個または複数のECCブロックを単位としてストリームブロックが構成され、このストリームブロック単位でストリーム情報の記録あるいは部分消去が行われる。ここにこの発明の特徴がある。
この実施の形態では、何個のECCブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて決めることができる。たとえば、図1(e)の例では、ストリームブロック#1は2つのECCブロック#α、#βで構成され、ストリームブロック#2は3つのECCブロック#γ、#δ、#εで構成されている。DVDストリーマでは、2個のECCブロック(32セクタ)で1つのストリームブロック(ストリームオブジェクトユニットSOBU)が構成される。
各ECCブロックは、図1(d)に示すように、16セクタで構成される。したがって、図1(d)(e)から分かるように、2ECCブロックで構成されるストリームブロック(あるいはSOBU)#1は、32セクタ(セクタNo.0〜セクタNo.31)に相当する。
つまり、1セクタ=2kバイトとすれば、ストリームブロック(SOBU)は、64kバイト(32セクタ)の固定サイズとして、この発明を実施することができる。
各セクタの内容はストリームパック(詳細は図9等を参照して後述)に対応している。そして、たとえばセクタNo.0(図1(d))に対応するストリームパックは、図1(c)に示すように、パックヘッダ1と、PESヘッダ6と、ストリームブロックヘッダ(図11を参照して後述)11と、データエリア21とを含んでいる。また、セクタNo.1(図(d))に対応するストリームパックは、図1(c)に示すように、パックヘッダ2と、PESヘッダ7と、セクタデータヘッダ(図12を参照して後述)12と、データエリア22とを含んでいる。
なお、図1(c)のPESヘッダ6、7の内部構成例は、図10を参照して後述する。
図1(c)のデータエリア21は、図1(b)に示すように、タイムスタンプとトランスポートパケットとのペアの配列(タイムスタンプa、トランスポートパケットa、タイムスタンプb、………トランスポートパケットd)を含んでいる。同様に、データエリア22は、タイムスタンプとトランスポートパケットとのペアの別配列を含んでいる。一方、後方のデータエリア23は、図1(b)に示すように、トランスポートパケットf、エンドコード31、およびパディングエリア36を含んでいる。
図1(b)のタイムスタンプとトランスポートパケットの複数ペアは、図1(a)に示すような配列のビットストリームとなる。
SOB#A・298(図1(f))の前方のストリームブロック#1(図1(e))のデータ構造は図1(d)〜(b)のようになるが、SOB#A・298の後方のストリームブロック#2(図1(g))のデータ構造は、次のようになる。
すなわち、ストリームブロック#2の末尾ECCブロック#εの後方セクタNo.78(図1(h))は、図1(i)に示すように、パックヘッダ3と、PESヘッダ8と、セクタデータヘッダ13と、データエリア24とを含んでいる。また、ECCブロック#εの最終セクタNo.79(図1(h))は、図1(i)に示すように、パックヘッダ4とパディングパケット40を含んでいる。
セクタNo.78のデータエリア24は、図1(j)に示すように、トランスポートパケットzと、エンドコード32と、パディングエリア37とを含んでいる。また、最終セクタNo.79のパディングパケット40は、図1(j)に示すように、PESヘッダ9とパディングエリア38を含んでいる。
なお、パディングエリア38の内容については、図26を参照して後述する。
図2は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。
DVDーRAMディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、DVD_RTRディレクトリ(またはDVD_RTAV)102と言う名のサブディレクトリ101内に入っている。
DVD_RTR(DVD_RTAV)ディレクトリ102内には、以下の内容のデータファイル103が格納される。
すなわち、管理情報(ナビゲーションデータ)のグループとして、RTR.IFO(またはVR_MANGR.IFO)104と、STREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、SR_PRIVT.DAT/SR_PRIVT.BUP105aとが格納される。
また、データ本体(コンテンツ情報)として、STREAM.VRO(またはSR_TRANS.SRO)106と、RTR_MOV.VRO(VR_MOVIE.VRO)107と、RTR_STO.VRO(またはVR_STILL.VRO)108と、RTR_STA.VRO(またはVR_AUDIO.VRO)109とが格納される。
上記データファイル103を含むサブディレクトリ101の上位階層にあるルートディレクトリ100には、その他の情報を格納するサブディレクトリ110を設けることができる。
このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットVIDEO_TS111、オーディオプログラムを収めたオーディオタイトルセットAUDIO_TS112、コンピュータデータ保存用のサブディレクトリ113等がある。
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
そのストリームデータそのものはSTREAM.VRO(またはSR_TRANS.SRO)106と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、STREAM.IFO(またはSR_MANGR.IFOとそのバックアップファイルSR_MANGR.BUP)105である。
また、VCR(VTR)あるいは従来TVなどで扱われるアナログ映像情報をMPEG2規格に基づきデジタル圧縮して記録されたファイルが、RTR_MOV.VRO(またはVR_MOVIE.VRO)107であり、アフターレコーディング音声あるいはバックグランド音声等を含む静止画像情報を集めたファイルがRTR_STO.VRO(またはVR_STILL.VRO)108であり、そのアフレコ音声情報ファイルがRTR_STA.VRO(またはVR_AUDIO.VRO)109である。
図3は、この発明の一実施の形態に係る情報媒体、たとえばDVDーRAMディスク等の録再可能光ディスク201上の記録データ構造を説明する図である。
図3(a)の情報記憶媒体201の内周方向202の端部と外周方向203の端部とで挟まれた領域には、図3(b)に示すように、リードインエリア204と、ファイルシステム情報が記録されているボリューム&ファイル構造情報206と、データエリア207と、リードアウトエリア205が存在する。リードインエリア204はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア205は書替可能データゾーンで構成されている。データエリア207も書替可能データゾーンで構成されている。
データエリア207内は、図3(c)に示すように、コンピュータデータとオーディオ&ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア208およびコンピュータデータエリア209の間に、オーディオ&ビデオデータエリア210が、挟まれる形態となっている。
オーディオ&ビデオデータエリア210内は、図3(d)に示すように、リアルタイムビデオ記録エリア221およびストリーム記録エリア222の混在記録が可能となっている。(リアルタイムビデオ記録エリア221あるいはストリーム記録エリア222の一方だけを使用することも可能である。)
図3(e)に示すように、リアルタイムビデオ記録エリア221には、図2に示された、RTRのナビゲーションデータRTR.IFO(VR_MANGR.IFO)104と、ムービーリアルタイムビデオオブジェクトRTR_MOV.VRO(VR_MOVIE.VRO)107と、スチルピクチャリアルタイムビデオオブジェクトRTR_STO.VRO(VR_STILL.VRO)108と、アフターレコーディング等のオーディオオブジェクトRTR_STA.VRO(VR_AUDIO.VRO)109とが記録される。
同じく図3(e)に示すように、ストリーム記録エリア222には、図2に示された、ストリーマのナビゲーションデータSTREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、トランスポートビットストリームデータSTREAM.VRO(SR_TRANS.VRO)106とが記録される。
なお、図3(d)(e)では図示しないが、ストリーム記録エリア222には、図2に示したアプリケーション固有のナビゲーションデータSR_PRIVT,DAT/SR_PRIVT.BUP105aを記録することもできる。
このSR_PRIVT,DAT105aは、ストリーマに接続(供給)された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
ストリームデータに関する管理情報であるSTREAM.IFO(またはSR_MANGR.IFO)105は、図3(f)〜(i)に示すようなデータ構造を有している。
すなわち、図3(f)に示すように、STREAM.IFO(またはSR_MANGR.IFO)105は、ビデオマネージャ(VMGIまたはSTR_VMGI)231と、ストリームファイル情報テーブル(SFIT)232と、オリジナルPGC情報(ORG_PGCI)233と、ユーザ定義PGC情報テーブル(UD_PGCIT)234と、テキストデータマネージャ(TXTDT_MG)235と、製造者情報テーブル(MNFIT)またはアプリケーション固有のナビゲーションデータSR_PRIVT.DAT105aを管理するアプリケーションプライベートデータマネージャ(APDT_MG)236とで構成されている。
図3(f)のストリームファイル情報テーブル(SFIT)232は、図3(g)に示すように、ストリームファイル情報テーブル情報(SFITI)241と、1以上のストリームオブジェクト情報(SOBI)#A・242、#B・243、………と、オリジナルPGC情報一般情報271と、1以上のオリジナルセル情報#1・272、#2・273………とを含むことができるようになっている。
図3(f)の各ストリームオブジェクト情報(たとえばSOBI#A・242)は、図3(h)に示すように、ストリームオブジェクト一般情報(SOBI_GI)251、タイムマップ情報252、その他を含むことができる。
また、図3(f)の各オリジナルセル情報(たとえば#1・272;後述するが図28で示されるSCIに対応)は、図3(h)に示すように、セルタイプ281(後述するが図28で示されるC_TYに対応)と、セルID282と、該当セル開始時間(後述する図15(l)、図28その他で示されるSC_S_APATに対応)283と、該当セル終了時間(後述する図15(l)、図28その他で示されるSC_E_APATに対応)284とを含むことができる。
なお、図3(f)の情報内容については、図27を参照して後述する。
図3(g)のSOBI#Aに含まれる図3(h)のタイムマップ情報252は、図3(i)に示すように、ストリームブロック番号261、第1ストリームブロックサイズ262、第1ストリームブロック時間差263、第2ストリームブロックサイズ264、第2ストリームブロック時間差265、………を含むことができる。タイムマップ情報252を構成する各ストリームブロック時間差の内容については、図5を参照して後述する。
図4は、この発明におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。以下、図4の例示を用いてこの発明におけるSOBとPGCの関係について説明する。
ストリームデータ(STREAM.VROまたはSR_TRANS.SRO)106内に記録されたストリームデータは、1個以上のECCブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理がなされる。このストリームデータは、記録する情報の内容毎(たとえばデジタル放送での番組毎)にストリームオブジェクトと言うまとまりを作る。
このSTREAM.VRO(SR_TRANS.SRO)106内に記録されたストリームオブジェクト(SOB#A、SOB#B)毎の管理情報(オリジナルPGC情報233、ユーザ定義PGC情報テーブル234等)は、ナビゲーションデータSTREAM.IFO(SR_MANGR.IFO)105(図4の最下部および図3(e)(f)参照)内に記録されている。
図4の各ストリームオブジェクト#A・298、#B・299毎の管理情報(STREAM.IFO105)は、図3(f)(g)に示すように、ストリームファイル情報テーブル(SFIT)232内のストリームオブジェクト情報(SOBI)#A・242、#B・243として記録されている。
ストリームオブジェクト情報(SOBI)#A・242、(SOBI)#B・243それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報252を含んでいる。
ストリームデータの再生時には、1個以上のセルの連続で構成されるプログラムチェーン(PGC)の情報(後述する図28のPGCI#iに対応)が利用される。このPGCを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
PGCには、STREAM.VRO(SR_TRANS.SRO)106に記録された全ストリームデータを連続して再生することのできるオリジナルPGC290(図3(f)ではORG_PGCI・233)と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義PGC#a・293、#b・296(図3(f)ではUD_PGCIT・234の中身に対応)の2種類が存在する。
オリジナルPGC290を構成するオリジナルセル#1・291、#2・292は、基本的にストリームオブジェクト#A・298、#B・299と一対一に対応して存在する。
それに対して、ユーザ定義PGCを構成するユーザ定義セル#11・294、#12・295、#31・297は、1個のストリームオブジェクト#A・298または#B・299の範囲内では任意の位置を設定することができる。
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図4のストリームブロック#1のように、2ECCブロック(32セクタ)で一定サイズ(64kバイト)のストリームオブジェクトユニット(SOBU)を、ストリームブロックとして採用するとよい。
このようにストリームブロックを一定サイズ(たとえば2ECCブロック=32セクタ=64kバイト)のSOBUに固定すれば、次の利点が得られる:
(01)SOBU単位でストリームデータの消去あるいは書替を行っても、そのSOBUのECCブロックが、消去あるいは書替対象以外のSOBUのECCブロックに影響しない。そのため、消去あるいは書替に伴う(消去あるいは書替の対象でないSOBUに対する)ECCのデインターリーブ/インターリーブのやり直しが、生じない;
(02)任意のSOBU内部の記録情報に対するアクセス位置を、セクタ数(あるいはセクタ数に対応した他のパラメータ;たとえば後述する図9のストリームパックおよびその内部のアプリケーションパケット群の情報)で特定できる。たとえば、あるSOBU#kの中間位置にアクセスする場合は、SOBU#kー1とSOBU#kとの境界から16セクタ目(あるいは16セクタ目に対応するアプリケーションパケットの位置)を指定すればよい。
図5は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図5を用いてタイムマップ情報252内の各データの内容について説明する。
図5(f)(g)(h)に例示するように、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1、#2で構成されている。
図5(f)(h)の例では、SOB#A・298を構成するストリームブロック#1のデータサイズは2ECCブロック(#α、#β)で構成され、32セクタ分(図5(e)(i))のサイズを持っている。すなわち、タイムマップ情報252(図5(a)(k))内の第1ストリームブロックサイズ262(図5(j))は、32セクタ(64kバイト)となる。
SOB#A・298(図5(g))の先頭にあるストリームブロック#1(図5(f))はその先頭にセクタNo.0(図5(e))を持ち、セクタNo.0に含まれるデータエリア21(図5(d))の先頭にはタイムスタンプaが記録されている。
また、SOB#A・298(図5(g))の後続ストリームブロック#2(図5(f))はその先頭にセクタNo.32(図5(e))を持ち、セクタNo.32に含まれるデータエリア311(図5(d))の先頭にはタイムスタンプpが記録されている。
図5(c)に示すように、ストリームブロック#1の最初のストリームデータのタイムスタンプ値はタイムスタンプaであり、次のストリームブロック#2の最初のストリームデータのタイムスタンプ値はタイムスタンプpとなっている。
図5(b)(図3(i)のストリームブロック時間差263に対応)の第1ストリームブロック時間差263の値は、上記タイムスタンプpとタイムスタンプaとの差分値([タイムスタンプp]−[タイムスタンプa])で与えられる。
なお、図5(a)のタイムマップ情報252は、図29を参照して後述するストリームオブジェクト情報SOBI内のアクセスデータユニットAUDも含むものとして、取り扱うことができる。このAUDに含まれる情報(アクセスユニット開始マップAUSM等)により、アクセスしたい情報を含むSOBUを特定できる。
図6は、オリジナルセルおよびユーザ定義セルにおけるセルの範囲指定方法を説明する図である。
それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。
具体的には、図15以降を参照して後述する部分消去の実行前(ストリームデータの録画直後)のオリジナルセルにおける該当セルの開始時間283および該当セルの終了時間284(図6(b))の時間として、該当するストリームオブジェクト#A・298(図6(f))内の最初のタイムスタンプaの値および最後のタイムスタンプz(図6(c))の値が使用される。
それに対して、ユーザ定義セル#12・295(図6(k))での時間範囲指定は、任意時刻を指定できる。たとえば、図6(i)(j)に示すように指定されたトランスポートパケットd、nに対応したタイムスタンプd、nの値を、該当セルの開始時間331と該当セルの終了時間332の値として設定することができる。
図6(f)は、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1および#2で構成されている場合を例示している。
図6(e)(g)の例では、ストリームブロック#1は32セクタ(セクタNo.0〜No.31)で構成され、ストリームブロック#2は48セクタ(セクタNo.32〜No.79)で構成されている。
ストリームブロック#1の先頭セクタNo.0は、図6(e)(d)に示すように、パックヘッダ1、PESヘッダ6、ストリームブロックヘッダ11、データエリア21等で構成されている。
また、ストリームブロック#2の後方セクタNo.78は、図6(e)(d)に示すように、パックヘッダ3、PESヘッダ8、セクタデータヘッダ13、データエリア24等で構成されている。
さらに、図6(g)のセクタNo.1には図6(h)に示すようにパックヘッダ2、セクタデータヘッダ12、データエリア22その他が記録され、図6(g)のセクタNo.33には図6(h)に示すようにセクタデータヘッダ321、データエリア312その他が記録されている。
図6(d)(h)のデータエリア21には、図6(c)(i)に示すように、タイムスタンプaとトランスポートパケットaとのペアないしタイムスタンプdとトランスポートパケットdとのペアが記録されている。
また、図6(d)のデータエリア24の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプz+トランスポートパケットzのペアの後に続くエンドコード32と、パディングエリア37(図1(j)のパディングエリア37に対応)が記録されている。
また、図6(h)のデータエリア22には、図6(i)に示すように、データエリア21のトランスポートパケットdの後続内容を含むトランスポートパケットdが含まれている。つまり、この例では、トランスポートパケットdの内容が、データエリア21とデータエリア22とで分断されて記録されている。
図6(i)のトランスポートパケットdの前半部分(データエリア21側)は、後述する図8(f)の末尾側部分パケットに対応し、図6(i)のトランスポートパケットdの後半部分(データエリア22側)は、後述する図8(g)の先頭側部分パケットに対応している。
さらに、図6(h)のデータエリア312には、図6(i)に示すように、タイムスタンプnとトランスポートパケットnとのペアおよびその他の同様なペアが記録されている。
ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間331(図6(j))は、データエリア21および22に分断された2つのトランスポートパケットd全体に対するタイムスタンプd(図6(i))により指定される。
トランスポートパケットをアプリケーションパケットと読み替え、アプリケーションパケット到着時間をAPATとした場合に、上記セル開始時間331は、セル開始APATとして表現できる。
また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間332(図6(j))は、データエリア312のトランスポートパケットnに対するタイムスタンプn(図6(i))により指定される。このセル終了時間332は、セル終了APATとして表現できる。
以上のセル開始時間(セル開始APAT)331およびセル終了時間(セル終了APAT)332は、図6(k)に示すように、ユーザ定義セル情報#12・295内部に記録される。
このユーザ定義セル情報#12・295は、図3(f)または図4下段に示すユーザ定義PGC情報テーブル234内に記録することができる。
以上はユーザ定義セル情報(ユーザ定義PGCの情報)に関するセル開始/終了時間情報についてであるが、オリジナルセル情報(オリジナルセルの情報)に関するセル開始/終了時間情報については、次のような例示ができる。
すなわち、図6(c)の先頭側タイムスタンプaにより図6(b)の該当セルの開始時間283を示すことができ、末尾側タイムスタンプzにより該当セルの終了時間284を示すことができる。
図6(b)の該当セルの開始時間283は、セル開始APAT(後述するストリームセル開始APAT(SC_S_APAT)または消去開始APAT(ERA_S_APAT)も含む)に対応させることができる。
また、図6(b)の該当セルの終了時間284は、セル終了APAT(後述するストリームセル終了APAT(SC_E_APAT)または消去終了APAT(ERA_E_APAT)も含む)に対応させることができる。
以上のセル開始時間(セル開始APAT)283およびセル終了時間(セル終了APAT)284は、図6(a)に示すように、オリジナルセル情報#1・272内部に記録される。
このオリジナルセル情報#1・272は、図3(f)または図4下段に示すオリジナルPGC情報233内に記録することができる。
なお、上記セル開始APATおよびセル終了APATについては、後述する図18〜図21、図30〜図33の説明において具体例を示す。
図7は、この発明の一実施の形態に係るストリームデータ記録再生装置(ストリーマ)の構成を説明する図である。
以下、図7を用いて、この発明の好ましい実施形態としてのストリームデータ記録再生装置(ストリーマ)の内部構造の説明を行う。
この実施の形態におけるストリームデータ記録再生装置は、エンコーダ部401、デコーダ部402、STB部403、主MPU部404、V(ビデオ)ミキシング部405、フレームメモリ部406、キー入力部407、表示部408、DVD−RAMディスク201に対して情報記録あるいは情報再生を行なうディスクドライブ部409、データプロセサ(D−PRO)部410、一時記憶部411、A/V(オーディオ・ビデオ)入力部412、TVチューナ部413を備えている。
このストリームデータ記録再生装置はさらに、STB部403に接続された衛星アンテナ421、システムタイムカウンタ(STC)部424、Vミキシング部405からパーソナルコンピュータ(PC)435へデジタルビデオ信号を送るインターフェイス(I/F)434、アナログTV437用D/A変換部436を備えている。
ここで、Vミキシング部405は、デコード部402のV−PRO部438からのデジタルビデオ信号と、STB部403からのデジタルビデオ信号423とを、適宜ミキシングする機能を持っている。このミキシング機能により、たとえばTV437の表示画面の左側にSTB部403からの放送画像を表示し、TV437の表示画面の右側にディスク201から再生した画像を表示することができる。
あるいは、STB部403からの放送画像とディスク201からの再生画像とを、PC435のモニタ画面において、オーバーラッピングウインドウに重ねて表示することもできる。
以上の構成において、エンコーダ部401内は、ビデオおよびオーディオ用のA/D変換部414、A/D変換部414からのデジタルビデオ信号またはSTB分03からのデジタルビデオ信号423を選択してビデオエンコード部416に送るセレクタ415、セレクタ415からのビデオ信号をエンコードするビデオエンコード部416、A/D変換部414からのオーディオ信号をエンコードするオーディオエンコード部417、TVチューナ部413からのクローズドキャプション(cc)信号あるいは文字放送信号等を副映像(SP)にエンコードするSPエンコード部418、フォーマッタ部419、バッファメモリ部420より構成される。
一方、デコード部402内は、メモリ426を内蔵する分離部425、縮小画像(サムネールピクチャ)生成部439を内蔵するビデオデコード部428、SPデコード部429、オーディオデコード部430、TSパケット転送部427、ビデオプロセサ(V−PRO)部438、オーディオ用D/A変換部432より構成されている。
デコード部430でデコードされたデジタルオーディオ信号は、インターフェイス(I/F)431を介して外部出力可能となっている。また、このデジタルオーディオ信号をD/A変換部432でアナログ化したアナログオーディオ信号により、外部のオーディオアンプ(図示せず)を介してスピーカ433が駆動されるようになっている。
なお、D/A変換部432は、オーディオデコード部430からのデジタルオーディオ信号のみならず、STB部403からのデジタルオーディオ信号422のD/A変換もできるように構成される。
なお、ディスク201からの再生データをSTB部403に転送する場合は、TSパケット転送部427において分離部425からの再生データ(ビットストリーム)をトランスポートパケット(TSパケット)に変更し、STC424からの時間情報に転送時間を合わせて、TSパケットをSTB部403に送ればよい。
図7の主MPU部404は、作業用メモリとしてのワークRAM404aと、ストリームデータ作成制御部404bという名の制御プログラムと、ストリームデータ再生制御部404cという名の制御プログラムと、ストリームデータの部分消去/仮消去制御部404dという名の制御プログラム等を含んでいる。
ここで、ファイルの管理領域(図2あるいは図3(e)のナビゲーションRTR.IFO104、STREAM.IFO105)などを読み書きするために、主MPU部404は、D−PRO部410に、専用のマイクロコンピュータバスを介して接続されている。
ストリームデータ記録再生装置における録画時の制御は、上記制御プログラム(シーケンシャルな制御プログラム)を用い主MPU部404により行われる。
まず、図7の装置における録画時のビデオ信号の流れについて説明をする。録画時には、主MPU部404内のストリームデータ作成制御部404bという名のシーケンシャルプログラムにしたがって、一連の処理が行われる。
すなわち、IEEE1394規格に準拠した伝送経路経由してSTB部403からエンコード部401へ送出されたストリームデータは、まずフォーマッタ部419に転送される。
フォーマッタ部419のIEEE1394受信側は、STC424のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。読み込んだ時間情報は、管理情報として主MPU部404へ送られ、ワークRAM部404aに保存される。
主MPU部404は、上記時間情報に基づいて、ストリームデータをストリームブロック毎(リアルタイムRTRレコーダではVOBU毎、ストリーマではSOBU毎)に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはPGCの切り分け情報を作成し、主MPU部404内のワークRAM部404aに逐次記録する。
フォーマッタ部419は、主MPU部404のストリームデータ作成制御部404bからの指示にしたがって、図1(a)の形でSTB部403から送られてきたストリームデータを図1(c)(i)の形(後述する図8(h)のストリームパックの列)に変換し、変換されたストリームパック列をD−PRO部410へ入力する。入力されたストリームパックはセクタと同じ2048バイトの一定サイズを持っている。D−PRO部410は、入力されたストリームパックを16セクタ毎にまとめてECCブロックにして、ディスクドライブ部409へ送る。
ここで、ディスクドライブ部409においてRAMディスク(情報記憶媒体)201への記録準備ができていない場合には、D−PRO部410は、記録データを一時記憶部411に転送して一時保存し、ディスクドライブ部409においてデータ記録準備ができるまで待つ。
ディスクドライブ部409において記録準備ができた段階で、D−PRO部410は一時記憶部411に保存されたデータをディスクドライブ部409に転送する。これにより、ディスク201への記録が開始される。一時記憶部411に保存されたデータの記録が済むと、その続きのデータはフォーマッタ部419からD−PRO部410へシームレスに転送されるようになっている。
ここで、一時記憶部411は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
次に、再生時のデータ処理について説明する。ストリームデータ記録再生装置における再生時の制御は、ストリームデータ再生制御部404cという名のシーケンシャルプログラムにしたがい、主MPU部404によって、一連の処理が行われる。
まず、ディスクドライブ部409により、RAMディスク(情報記憶媒体)201からストリームデータが再生される。再生されたストリームデータは、D−PRO部409を経由してデコーダ部402に転送される。
デコーダ部402内部では、再生されたストリームデータ中のトランスポートパケットを分離部425が受け取る。
分離部425は、図10を参照して後述するストリームID603およびサブストリームIDに従って、ビデオパケットデータ(MPEGビデオデータ)はビデオデコード部428へ転送し、オーディオパケットデータはオーディオデコード部430へ転送し、副映像パケットデータはSPデコード部429へ転送する。
ビデオデコード部428でデコードされたビデオデータは、Vミキシング部405およびD/A変換部436を介してアナログTV信号に変換され、TV437に転送されて画像表示される。
同時に、オーディオデコード部430でデコードされたオーディオ信号もD/A変換部432へ送られ、デジタル音声データに変換される。変換されたデジタル音声データは、I/F431を介して外部オーディオ機器(図示せず)のデジタル入力に転送される。あるいは、変換されたデジタル音声データは、D/A変換部432によりアナログ音声信号に変換され、図示しないオーディオアンプを介して、スピーカ433に送られる。
以上この発明の実施の形態におけるストリームデータ記録再生装置(ストリーマ)内での信号の流れを説明した。
以上説明したように、DVD−RAMディスク(情報記憶媒体)201へ記録するストリームデータは、フォーマッタ部419内で図1(c)(i)の構造に変換される。この変換プロセスを中心にしたストリームデータ録画手順は、図13のフローチャートを参照して後述する。
また、ストリームデータの再生手順については、図14のフローチャートを参照して後述する。
図8は、デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
デジタル放送では、MPEG2規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図8(b)に示すように、トランスポートパケットヘッダ511と、記録情報のデータ本体が記録されているペイロード512とで構成されている。
トランスポートパケットヘッダ511は、図8(a)に示すように、ペイロードユニット開始インジケータ501、パケットID(PID)502、ランダムアクセスインジケータ503、プログラムクロックリファレンス504等で構成されている。
MPEG圧縮された映像情報は、Iピクチャ情報、Bピクチャ情報、およびPピクチャ情報を含んでいる。Iピクチャ情報(後述する図9の571)が記録されている最初のトランスポートパケットには、図8(a)のランダムアクセスインジケータ503に”1”のフラグが立つ。また、各B、Pピクチャ情報(後述する図9の573、574、572)の最初のトランスポートパケットには、図8(a)のペイロードユニット開始インジケータ501に”1”のフラグが立つ。
これらのランダムアクセスインジケータ503およびペイロードユニット開始インジケータ501の情報を利用して、I−ピクチャマッピングテーブル(後述する図11の641)およびB、P−ピクチャ開始位置マッピングテーブル(後述する図11の642)の情報が作成される。
たとえば、図8(a)に示したペイロードユニット開始インジケータ501に”1”のフラグが立ったトランスポートパケットに対して、B、P−ピクチャ開始位置マッピングテーブル(図11の642)内の該当個所のビットが”1”になる。
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図8(a)のパケットID(PID)502で識別される。このPID502の情報を用いて、ビデオパケットマッピングテーブル(後述する図11の643)とオーディオパケットマッピングテーブル(後述する図11の644)が作成される。
図8(c)に示すように、デジタル放送では、1個のトランスポンダに複数の番組(この例では番組1〜番組3)がパケット化された形で時分割されて転送されてくる。
たとえば、図8(b)のトランスポートパケットヘッダ511およびペイロード(記録情報)512の情報は、図8(c)に示される番組2のトランスポートパケットb・522、e・525により転送される。
いま、たとえばデジタル放送受信者(図7のSTBのユーザ等)の操作により、図8(c)に示される番組2が、図3または図7の情報記憶媒体201に記録される場合を想定してみる。この場合、図7のSTB部403において、図8(c)の番組2のトランスポートパケットb、eのみが抽出される。
そのとき、STB部403では、図8(d)に示すように、各トランスポートパケットb・522、e・525を受信した時刻情報がタイムスタンプ531、532の形で付加される。
その後、IEEE1394の転送方式によって図7のSTB部403からフォーマッタ部419へデータを転送する場合には、図8(e)に示すように、上記タイムスタンプ531とトランスポートパケット522との組が細かく分割されて転送されることになる。
図7のフォーマッタ部419では、STB部403からIEEE1394で転送されてきたストリームデータが、図8(d)の形(図1(a)の形あるいは図8(f)(g)(h)の形に相当)に一旦戻される。そして、図1(a)あるいは図8(f)(g)(h)の形式のビットストリーム(図8(h)のストリームパック列)が、情報記憶媒体201に記録される。
具体的には、この発明の一実施の形態においては、各セクタ(図1(d)(h))の先頭には、システムクロック情報などが記録されたパックヘッダ1、2、3、4とPESヘッダ6、7、8、9が配置される(図1(c)(i)、図6(d)参照)。その直後には、セクタデータヘッダ12、13(図1(c)(i)、図6(d))が記録されるが、各ストリームブロック先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ11が記録される(図1(c)、図6(d))。
データエリア21、22、23、24(図1(c)(i))には複数のタイムスタンプおよびトランスポートパケット(図1(a))が逐次詰め込まれるが、1個のトランスポートパケット(図1(b)ではパケットd;図8(e)ではパケットb)が複数のセクタ(図1(d)ではNo.0とNo.1;図8(f)(g)では部分パケット)に跨って記録される。ここに、この発明の特徴の1つがある。
この特徴を生かしたデータ構造を用いることにより、セクタサイズ(例えば2048バイト)よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
デジタル放送では図8(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb・522のサイズが188バイト(または183バイト)の場合が多い。
前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア21、22、23、24(図1(c)(i))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。
それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。
デジタル放送などのように1個のデータエリア21、22、23、24(図1(c)(i))内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリア21、22、23、24に連続して跨るように記録する。
そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
また、通常のパケットにはタイムスタンプが付いているが、図8(g)に示すように、部分パケットではタイムスタンプを省略することができる。
このようにすると、2つの隣接ストリームパック(図8(h))の境界で分断された部分パケット(パケット1つあたり188バイトとすれば部分パケットのサイズは1〜187バイト;平均して100バイト弱)を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分(タイムスタンプ1つあたり例えば4バイト)、媒体201に対する記憶容量を増やすことができる。
なお、図8(g)の先頭部分パケットの直後にくるタイムスタンプの位置は、後述する図12(b)のファーストアクセスポイント625あるいは図12(c)のFIRST_AP_OFFSETにより、特定することができる。
ところで、ストリームブロック内に余り部分が生じた場合には、パディングデータ(データが未記録である領域と認識できる情報)が記録される。たとえば、図1(b)のようにストリームブロック#1内の最後のトランスポートパケットfの後ろにはエンドコード31が配置され、残りの部分はパディングエリア36としている。図1(j)のパディングエリア37、38も同様なパディングデータ用のエリアである。
なお、パディングエリアの具体的な内部データ構造については、図26を参照して後述する。
図9は、MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
前述したように、デジタル放送では、映像情報はMPEG2の規格に従って圧縮された情報が転送されてくる。
図9に示すように、Iピクチャ551の圧縮情報561はIピクチャ情報571としてトランスポートパケットa、b、…に記録される。Bピクチャ553の差分情報563、564はBピクチャ情報573としてトランスポートパケットd、…に記録される。また、Bピクチャ554の差分情報565、566はBピクチャ情報573、574としてトランスポートパケットd、f、…に記録される。そして、Pピクチャ552の差分情報562がPピクチャ情報572としてトランスポートパケットh、…に記録される。
このように各I、B、Pピクチャ情報は異なるトランスポートパケットに記録されている。
このようなトランスポートパケットがストリーマに記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ(ATS)というタイムスタンプ付きのパケット(アプリケーションパケット)に移し替えられる。
そして、ATS付きアプリケーションパケットの一群(通常10パケット前後)がストリームPESパケット内のアプリケーションパケットエリアに格納される。
このストリームPESパケットにパックヘッダを付したものが図8(h)で例示した1つのストリームパックになる。
ストリームPESパケットは、PESヘッダと、サブストリームIDと、アプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、上記ATS付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。
なお、PESヘッダ(ストリームPESパケットヘッダ)の内容については、図10を参照して後述する。また、アプリケーションヘッダ(ストリームブロックヘッダ11またはセクタデータヘッダ12に対応)については、図11および図12を参照して、後述する。
図10は、図1、図8、図9等に示されたPESヘッダの内部構造を説明する図である。
図10(a)のPESヘッダ601は、図10(b)に示すように、パケット開始コードプリフィックス602、ストリームID603、再生タイムスタンプ604等を含んでいる。このPESヘッダ601は、図1(c)(i)(j)のPESヘッダ6〜9、図8(h)のPESヘッダ6〜7、図9のPESヘッダ6等に対応している。
また、図10(d)のストリームPESヘッダは、パケット開始コードプリフィックス、ストリームID(プライベートストリーム2)、PESパケット長、サブストリームID等を含んでいる。このストリームPESヘッダは、図9のストリームPESヘッダと同じもので、図10(a)のPESヘッダ601に対応する内容を持つ。
図1(j)のPESヘッダ9が図10(a)に示すPESヘッダ601の内部構造を持つときは、MPEGの規格では、このPESヘッダのストリームID603(図10(b))が”10111110”のときに、このPESヘッダを持つパケットを、パディングパケット40(図1(i)にすると定義されている。
一方、ストリームID603(図10(c)のサブストリームID)が”00000010”のときは、そのPESパケットの付いたパケットは、ストリーム記録データを含むことになる。
図1(e)のストリームブロック#1では、最後のトランスポートパケットf(図1(a))が最後のセクタNo.31(図1(d))内に存在している。しかし、ストリームブロック#2(図1(e)(g))では、ユーザ等により途中で録画が終了されたために、最後のトランスポートパケットz(図1(j))がセクタNo.78(図1(h))に配置され、セクタNo.79(図1(h))内はストリームデータが記録されいない空き領域となっている。このため、セクタNo.79は、パディングパケット40(図1(i))として記録されている。
図11は、図1(c)に示されたストリームブロックヘッダの内部構造を説明する図である。
ストリームブロックヘッダ11は、図11(a)に示すように、図9下段のサブストリームID、アプリケーションヘッダ、スタッフィングバイト等に対応した内容を持つ。
ストリームブロックヘッダ11は、図11(b)に示すように、トランスポートパケット情報611、ストリームブロック情報612、セクタデータヘッダ情報613等を含んでいる。
図11(b)のトランスポートパケット情報611は図11(c)のトランスポートパケット情報611とおなじものを指す。
ストリームブロック全体に関する情報が記録されている図11(b)のストリームブロック情報612は、図11(c)の記録時間622(情報記憶媒体201に記録した年月日と時刻情報)、トランスポートパケット属性623(トランスポートパケットに関する属性情報)、ストリームブロックサイズ624(該当するストリームブロックのデータサイズ(たとえばECCブロック数で記載できる))、ストリームブロック時間差625等に対応する。
ここで、図1(b)を例にとれば、該当ストリームブロック内の時間範囲情報は、[ストリームブロック時間差]=[ストリームブロック#2内の最初にくるタイムスタンプ値]−[タイムスタンプaの値]として計算される。この[ストリームブロック時間差]が、ストリームブロック時間差625となる。
また、図11(b)のセクタデータヘッダ情報613は、図11(c)のファーストアクセスポイント626およびトランスポートパケット接続フラグ627に対応する。このセクタデータヘッダ情報613は、後述する図12のセクタデータヘッダ12と同様な情報を含んでいる。
図11(c)のトランスポートパケット情報611は、図11(d)に示すように、トランスポートパケットの数(アプリケーションパケットの数)631、トランスポートパケットマッピングテーブル632等を含んでいる(図11(dのアプリケーションパケットの数は、後述する図12(c)のAP_Nsに対応する)。
図11(d)のトランスポートパケット(アプリケーションパケット)の数631は、図11(e)に示すように、Iピクチャマッピングテーブル641、B,Pピクチャマッピングテーブル642等を含むことができる。
また、図11(d)のトランスポートパケットマッピングテーブル632は、ビデオパケットマッピングテーブル643、オーディオパケットマッピングテーブル644、プログラム固有情報マッピングテーブル645等を含むことができる。
トランスポートパケットマッピングテーブル632内の各マッピングテーブル(図11(e))は、ビットマップ形式で構成されている。
たとえば、1個のストリームブロック内にn個のトランスポートパケット(アプリケーションパケット)が記録されている場合には、図11(d)のトランスポートパケット数(アプリケーションパケット数)631の値は”n”となる。
さらに、各マッピングテーブル643〜645は”nビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット(アプリケーションパケット)に対してそれぞれ1ビットずつが割り当てられている。
図12は、図1に示されたセクタデータヘッダの内部構造を説明する図である。
図1(c)(i)のセクタデータヘッダ12、13は、データエリア21、22、23、24内のデータ配列情報を示し、図12に示すように、ファーストアクセスポイント651およびトランスポートパケット接続フラグ652を含む内部構造を持っている。
ところで、図12(d)(および図9下段)に示すように、1セクタと同じく2048バイトのサイズを持つ1つのストリームパックは、パックヘッダおよびストリームPESヘッダで構成されている。そして、このストリームPESパケット内に、図12(a)のセクタデータヘッダ12あるいは図11(a)のストリームブロックヘッダ11の一部に対応した、アプリケーションパケットヘッダが含まれている。
このアプリケーションパケットヘッダは、図12(c)に示すように、以下のものを含んでいる:
*アプリケーションパケットヘッダ形式のバージョン記載;
*該当ストリームパック内で開始するアプリケーションパケット(トランスポートパケット)の数AP_Ns;
*該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置FIRST_AP_OFFSET;
*ヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報EXTENSION_HEADER_IFO;
*該当ストリームを生成したサービスの識別子SERVICE_ID。
上記図12(d)のアプリケーションパケットに含まれるFIRST_AP_OFFSETは、図12(a)のセクタデータヘッダ12に含まれるファーストアクセスポイント651に対応する。
図1(b)に示すように、トランスポートパケットdは2個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ652が”1”に設定される。また図1(b)の例では、次のセクタへ跨ったトランスポートパケットdの次にくるタイムスタンプ先頭位置のデータエリア22内のアドレスが、ファーストアクセスポイント651内に記録(ビット単位の表現)されている。
図1(d)に示すセクタNo.1(またはその対応ストリームパック)のファーストアクセスポイント値を、セクタNo.1のデータエリア22(図1(c))のサイズよりも大きな値に設定することができる。そうすることにより、セクタNo.1内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。
この発明の一実施の形態では、ファーストアクセスポイント651の値としてデータエリア21、22、23、24のサイズよりも大きな値を指定可能にすることで、セクタサイズ(あるいはストリームパックサイズ=2048バイト)よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。
たとえば、図1(d)のデータ構造において、1個のパケットがセクタNo.0からセクタNo.2まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタNo.0のデータエリア21内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタNo.2のデータエリア内のTビット目に配置されている場合を考える。
この場合、セクタNo.0のファーストアクセスポイントの値は”0”、セクタNo.1のファーストアクセスポイントの値は”セクタNo.1のデータエリア22サイズ+T”、セクタNo.2のファーストアクセスポイントの値は”T”となる。
図13は、この発明の一実施の形態に係るストリームデータのエンコード手順および録画手順を説明するフローチャートである。
まず、図7のエンコード部401において、パケット化されたデータが、タイムスタンプ(図1(b)、図8(f)等のタイムスタンプ、あるいは図9のATS)と一緒に、バッファメモリ部420に一時記憶される(ステップS01)。
別の言い方をすると、ステップS01において、図7の装置(ストリーマ)により、連続するストリームブロック(SOBU)のセクタに格納される再生データのエリアが、タイムスタンプ(ATS)付きトランスポートパケット(アプリケーションパケット)により埋められる。ここで付加されるタイムスタンプには、図7のSTC部424から得たローカルクロック値が用いられる。
次に、バッファメモリ部420に一時記憶されたタイムスタンプとパケットデータとのビット列が、ストリームブロック(あるいはSOBU)毎に切り分けられる(ステップS02)。
この実施の形態では、図1(b)に示すように同一のトランスポートパケット(d)が異なるストリームブロック(#1、#2)に跨って記録されることを禁止できる。この場合、図7のバッファメモリ部420に一時記録されたタイムスタンプとパケットデータをストリームブロック毎に切り分けるS02のステップでは、タイムスタンプとトランスポートパケットの組が完全に1個のストリームブロック内に収まるように切り分けを行なう必要がある。
切り分けられた各ストリームブロック(SOBU)内のデータ末尾には、エンドコード(図1(j))と、必要に応じてパディングエリアが追記される(ステップS03)。
こうしてバッファメモリ部420内でストリームブロック(SOBU)毎に切り分けられたタイムスタンプとパケットデータのビット列の内部が、さらに、セクタ毎(あるいは2048バイトのストリームパック毎)に分割される(ステップS04)。
この実施の形態では、同一のトランスポートパケット(d)を、異なるセクタ(図1(d)のNo.0とNo.1)に跨って記録させることもできる。この場合は、セクタ毎に分割するS04のステップでは、各データエリア21、22、23、24に割り当てられた所定サイズに従って、無造作に分割が行われる。
その後、バッファメモリ部420内で各セクタ(ストリームパック)の先頭位置に、図1(c)、図9その他に示すような、パックヘッダおよびPESヘッダの情報が挿入される(ステップS05)。
なお、ステップS05において挿入されるパックヘッダおよびPESヘッダの情報は、トランスポートパケット(アプリケーションパケット)を生成したデバイス(アプリケーションデバイス)が任意に出力するシーケンスヘッダの情報でもある。
次に、ストリームブロック(SOBU)内の最後にあるパディングエリアサイズがセクタ記録サイズ(ストリームパックサイズ2048バイト)より大きいかどうかチェックされる(ステップS06)。
たとえば図1(f)のストリームオブジェクト#A・298の最後のストリームブロック#2では、ユーザ等により任意の位置での録画終了処理が行われる可能性がある。そのため、ストリームブロック#2内の記録可能領域のサイズに対して記録すべきストリームデータのサイズの方が大幅に小さい場合が生じる。
この場合には、ステップS06の判定結果として、トータルのパディングエリアサイズがセクタ記録サイズより大きい状況になる。(図1(f)〜(j)の例では、ストリームデータはセクタNo.78の途中まで記録され、セクタNo.79内は実質的に記録されない状態になっている。この場合、図1(j)のパディングエリア37、38のトータルサイズがセクタNo.79内サイズより大きくなる。)
この場合(ステップS06イエス)には、図10(b)のストリームID603の値が前述したように”10111110”に設定され、セクタNo.79(全てがパディングエリアで埋められるセクタ)がパディングパケット40に変換される(ステップS07)。
ステップS06においてパディングエリアサイズがセクタ記録サイズ以下と判定されれば(ステップST06ノー)、あるいはステップS07においてパディングパケットへの変換処理が済めば、バッファメモリ部420に記録されているストリームブロック(SOBU)内のパケットデータ列が解析される。この解析結果から、トランスポートパケット情報の関連情報(図11(b)〜(e)、図12(b)〜(d))が作成される。そして、ストリームブロック内で最初のセクタのPESヘッダの直後に図11(a)のストリームブロック11が挿入される(ステップS08)。
あるいは、ストリームブロック(SOBU)内で最初のセクタ(最初のストリームパック)のPESヘッダの後に図9、図11その他で示したアプリケーションヘッダが挿入される(ステップS08)。
さらに、ストリームブロック内の先頭セクタとパディングパケットを除いた全てのセクタに対して、そのPESヘッダの直後に図12(a)のセクタデータヘッダ12が挿入される(ステップS09)。
あるいは、ストリームブロック(SOBU)内の先頭セクタ(最初のストリームパック)とパディングエリアを除いた全てのセクタ(ストリームパック)に対して、そのPESヘッダの後に図9、図12その他で示したアプリケーションヘッダが挿入される(ステップS09)。
上記ステップS08およびステップS09でのヘッダ挿入は、バッファメモリ部420内で行われる。
以上の工程(ステップS01〜ステップS09)によりエンコードされたビットストリーム(バッファメモリ部420上で作成したデータ構造を持つストリーム情報)が、図7の装置により、DVD−RAMディスク等の情報記憶媒体(図3または図7の201)に記録される。
なお、ステップS08では、ストリームブロック(SOBU)内の全トランスポートパケットヘッダ511(図8(b))を検索し、図8(a)のペイロードユニット開始インジケータ501、PID502、ランダムアクセスインジケータ503の値を利用して、図11(e)のトランスポートパケットマッピングテーブル632内の各データを作成することができる。
また、次のストリームブロック(SOBU)内の最初にくるタイムスタンプの値と現行のストリームブロック(SOBU)内の最初にくるタイムスタンプの値との差を計算して、図8(c)のストリームブロック時間差625の値を求めることもできる。
図14は、この発明の一実施の形態に係るストリームデータのデコード手順および再生手順を説明するフローチャートである。
以下、図1(c)(i)あるいは図8(h)の構造で情報記憶媒体(DVD−RAMディスク)201上に記録されたストリーム情報から、図7の分離部425内部でトランスポートパケットを抽出するプロセスを中心に、ストリームデータの再生手順を説明する。
ユーザ等からは再生すべき範囲が時間情報で指定される。この場合の再生時には、指定された時間情報に対応する、再生すべきストリームブロック(またはSOBU)を探す処理が必要となる。
まず、図13で例示した方法で情報記録がなされたRAMディスク(図3あるいは図7の情報記憶媒体)201が、図7のディスクドライブ部409に装填される。その後、例えば装置ユーザが、希望する再生範囲を、「再生開始時間」と「再生終了時間」で指定したとする。この指定がなされたあと図7のキー入力部407(あるいは図示しないリモートコントローラ)のプレイキー(再生ボタン)が押されたとする。
すると、図7の主MPU部404は、制御プログラム「ストリームデータ再生制御部404c」に従い図3(f)のストリームファイル情報テーブル(SFIT)232にアクセスして、図3(h)のタイムマップ情報252の内容を読み取る。読み取られた情報内容から、主MPU部404は、指定された「再生開始時間」の位置(再生開始時刻位置)が含まれるストリームブロック(SOBU)の番号とそのストリームブロック(SOBU)の先頭位置アドレスを割り出す(ステップS11)。
ここで、図3(i)の実施の形態では、タイムマップ情報252内には各ストリームブロック毎の差分時間情報しか記録されていない。この場合、主MPU部404内のストリームデータ再生制御部(再生制御プログラム)では、各ストリームオブジェクト情報(SOBI)242、243(図3(g))毎にタイムマップ情報252内の各ストリームブロックの時間差(図5(b)参照)263、265の値を逐次加算し、ユーザが指定した時刻に到達するか比較する。その比較結果を元に、ユーザが指定した時刻はどのストリームオブジェクト(SOB)内の何番目のストリームブロック(SOBU)の中に含まれるタイムスタンプ値と一致するかを割り出す。これにより、アクセスしようとするストリームブロック(SOBU)の先頭位置アドレスを割り出すことができる。
あるいは、後述する図29に示すようなデータ構造を持つストリームオブジェクト情報(SOBI)が用いられるときは、このSOBIに含まれる情報(タイムマップ情報MAPL、MAPLのエントリ数MAPL_ENT_Ns等)を用いて、アクセスしようとするストリームブロック(SOBU)の先頭位置アドレスを割り出すことができる。
ステップS11で割り出された先頭位置アドレスは、ディスクドライブ部409に通知される。こうしてアクセス先のアドレス情報を得たデスクドライブ部409は、このアドレス情報に対応する所定のストリームブロック(SOBU)の先頭位置にアクセスする。そして、このストリームブロック(SOBU)の先頭を起点として、ディスクドライブ部409は、装填されたディスク201から、ストリームブロック(SOBU)単位で、記録済みのストリームデータを読み込む(ステップS12)。
ステップS12の処理により、パケット到着時間(またはアプリケーションパケット到着時間APAT)を伴う個別のトランスポートパケット(またはアプリケーションパケット)が検索され、検索されたパケットの回収(その記録内容の再生)が可能になる。
こうして読み込まれたストリームデータは、D−PRO部410を介して、ディスクドライブ部409からデコード部402内の分離部425へ転送される。転送されたストリームデータは、分離部425の内部メモリ426に一時的に保管される(ステップS13)。
分離部425の内部メモリ426に保管されたストリームデータが一定量を越えると、そこからパディングエリア(図1(j)の37、38等)のパケットが自動的に検索される。パディングパケットであるかどうかは、図10(c)のサブストリームIDをチェックすることで分かる。
分離部425の内部メモリ426上でパディングパケットが見つかると、パディングパケットが含まれるパディングエリアが、分離部425の内部メモリ426上で消去される(ステップS14)。
こうしてパディングパケットが除かれたストリームデータから、分離部425の内部メモリ426上で、各種ヘッダ(パックヘッダ、PESヘッダ、ストリームブロックヘッダ、セクタデータヘッダ、その他)が消去される。こうして、分離部425の内部メモリ426上のストリームデータが、タイムスタンプ(ATS)およびパケットデータだけの列情報(ビットストリーム)に変換される(ステップS15)。
次に、変換されたビットストリームデータを、通信回線(IEEE1394シリアルバス等)を用いて外部装置(図7のSTB部403等)に転送する必要があるかどうか、チェックされる(ステップS16)。
ステップS16のチェックは、例えば次のような方法で行なうことができる。すなわち、図7の装置ユーザが装置の初期設定において「再生したビットストリームを外部装置に転送しますか?…イエス/ノー」という設定画面(図示せず)でイエスを選択している場合に、そのイエスのフラグが立っているかどうかで判定できる。
情報記憶媒体201から再生したストリームデータを図7のSTB部403に送る必要がある場合には(ステップS16イエス)、各トランスポートストリームに付いているタイムスタンプのタイミングに同期させて、再生したストリームデータをSTB部403へ逐次転送する(ステップS17)。このSTB部403への転送手段としてIEEE1394が利用される場合は、再生したストリームデータは図8(e)に示すようなデータ構造に変換されて転送される。
上記IEEE1394転送が不要なら(ステップS16ノー)、あるいは上記IEEE1394転送が実施されたあと、分離部425の内部メモリ426上で、ステップS15で変換されたビットストリームからタイムスタンプ(ATS)が消去され、パケットデータのみのデータ列に変換される(ステップS18)。
こうして変換されたデータ列中のパケットデータには、記録時の内容に応じて、ビデオパケット、副映像(SP)パケット、オーディオパケット等が含まれている。これらのパケットを含むデータパックはパックヘッダを持ち、そのパックヘッダ内のストリームID(図示せず)により、データの種類(ビデオか副映像かオーディオか等)が区別できるようになっている。
このストリームIDの内容を参照することで、ビデオパケットは図7のビデオデコード部428に転送され、副映像パケットはSPデコード部429に転送され、オーディオパケットはオーディオデコード部430に転送される。こうして、各デコード部(428〜430)において、該当する記録内容が、それぞれ個別にデコードされる(ステップS19)。
以上のようにして記録された各種情報(ビデオ、副映像、オーディオ等)のデコードが個別に開始されると、図7のSTC(システムタイムカウンタ)424にセットされた再生タイムスタンプに基づいて、ビデオ情報、副映像情報、および/またはオーディオ情報等が、所定のタイミングで再生される(モニタTVに画面表示されあるいはスピーカから音声再生される)(ステップS20)。
ここで、ステップS20の再生タイムスタンプは、図1、図10その他に例示されたPESヘッダに格納されたもの(図10(b)では604)を用いることができる。
あるいは、ステップS20の再生タイムスタンプとして、図8(h)その他に例示されたパックヘッダ内のSCR(システムクロックリファレンス)ベース(図示せず)を用いることも可能である。
図15および図16は、この発明の一実施の形態に係るストリームデータの部分消去方法を説明する図である。
図15は部分消去後の見かけ上の前半残存領域743について詳細を示しており、図16は部分消去後の見かけ上の後半残存領域744について詳細を示している。
また、図22および図24は、この発明の他実施の形態に係るストリームデータの部分消去方法を説明するもので、各ストリームブロックが一定サイズ(32セクタ64kバイト)のストリームオブジェクトユニットSOBUで構成される場合を示している。
図22は部分消去後の見かけ上の前半残存領域743について詳細を示しており、図24は部分消去後の見かけ上の後半残存領域744について詳細を示している。
さらに、図23および図25は、この発明の他実施の形態に係るストリームデータの仮消去方法を説明するもので、各ストリームブロックが一定サイズ(32セクタ64kバイト)のストリームオブジェクトユニットSOBUで構成される場合を示している。
図23は、図22(g)(h)の消去領域(741、742)が仮消去領域(747、748)である場合のデータ構造を例示している。また、図25は、図24(g)(h)の消去領域(741、742)が仮消去領域(747、748)である場合のデータ構造を例示している。
以下では、図3または図7の情報記憶媒体201上に既に記録してあるストリームデータの一部を部分的に消去する場合(あるいは仮消去する場合)について説明を行う。
ストリームデータの記録再生装置(ストリーマ)では、部分消去処理(仮消去処理)は、図7の主MPU部404の制御プログラム「ストリームデータ部分消去/仮消去制御部」404dにより実行される。
この発明の一実施の形態では、データ消去(あるいは仮消去)は常にストリームブロック単位(あるいはSOBU単位)で行なわれる。さらに、オリジナルセル範囲を指定した時間情報(セル開始APAT(SC_S_APAT/ERA_S_APAT);セル終了APAT(SC_E_APAT/ERA_E_APAT))を利用して、細かい部分消去範囲(あるいは仮消去範囲)をユーザが指定できるようにしている。ここにもこの発明の特徴がある。
この発明の一実施の形態では、図1(b)(j)に示すようにストリームブロック(あるいはSOBU)の最後をパディングエリア36、38とし、同一のトランスポートパケットが異なるストリームブロック(SOBU)を跨って記録できないような構造になっている。
このようにすると、常にトランスポートパケットの切れ目とストリームブロック(SOBU)の切れ目が一致するため、ストリームブロック(SOBU)単位での部分消去が容易に実行可能になる。
図17は、この発明の一実施の形態に係るストリームデータの部分消去の手順(記録情報の一部を完全消去する手順)を説明するフローチャートである。このフローチャートを利用して仮消去の手順(記録情報の一部があたかも消去されたかの如く管理情報を変更するが、情報本体そのものは消去されずに残す手順)についても説明する。
図17では図示を省いているが、図7の主MPU部404により「ストリームデータ部分消去/仮消去制御部」404dという制御プログラムがスタートすると、まず、図7のディスクドライブ部409に装填された情報記憶媒体201から、ストリームデータに関する管理情報が記載されているSTREAM.IFO105(図2、図3(e)等参照)の情報が読み込まれる。読み込まれた管理情報は、主MPU部404内のワークRAM部404aに一時保管される。
図7のディスクドライブ部409に装填された情報記憶媒体201には、消去前(あるいは仮消去前)の状態として、ストリームオブジェクト(SOB)#B・299が記録されている。このSOB#Bは、ストリームブロック(またはSOBU)#3〜#5から構成され、その中に記録されている全トランスポートパケット(あるいはアプリケーションパケット)が再生可能な状態になっている場合を考える。
この場合の消去処理では、SOB#B・299に対応するオリジナルセル情報#2・273(図3(g);このオリジナルセル情報は、ワークRAM部404aに一時保管された管理情報STREAM.IFO105の一部に含まれる)の指定範囲として、以下の指定がなされる:
(1a)該当セルの開始時間751(図15(l)または図22(l))の時刻をトランスポートパケットr(図15(k)または図22(k))に対応したタイムスタンプrの時刻(トランスポートパケットrの到着時刻を表す)に指定し、
(2a)該当セルの終了時間756(図16(l)または図24(l))の時刻をトランスポートパケットw(図16(k)または図24(k))に対応したタイムスタンプwの時刻(トランスポートパケットwの到着時刻を表す)に指定する。
一方、仮消去処理の場合には、SOB#B・299に対応するオリジナルセル情報#2・273(図3(g);STREAM.IFO105の一部)の指定範囲として、以下の指定がなされる:
(1b)該当セルの開始時間752(図23(l))の時刻をトランスポートパケットrr(図23(k))に対応したタイムスタンプrrの時刻(トランスポートパケットrrの到着時刻を表す)に指定し、
(2b)該当セルの終了時間758(図25(l))の時刻をトランスポートパケットj(図25(k))に対応したタイムスタンプjの時刻(トランスポートパケットjの到着時刻を表す)に指定する。
以下の部分消去手順(または仮消去手順)の説明において、部分消去前後(仮消去前後)で図2のSTREAM.IFO105およびSTREAM.VRO106の内容がどのように変化するかを、図15、図16および図22〜図25を適宜参照しながら説明する。
初めは、部分消去の場合を説明し、その後に仮消去の場合を説明する。
[部分消去の場合]
いま、図15(f)、図16(f)、図22(f)あるいは図24(f)に示すストリームオブジェクト(SOB)#B・299の中央部を部分消去するものとし、図15(g)、図16(g)、図22(g)あるいは図24(g)に示すように見かけ上の消去領域741が設定される場合を想定して、図17のフローチャートの説明に入る。
まず、ユーザ等により、部分消去範囲が、時間情報(部分消去の開始時刻と部分消去の終了時刻)等により指定される(ステップS21)。
この指定により、図15(g)等に示した「見かけ上の消去領域741」の範囲が特定される。この消去範囲指定操作後は、図15(f)等のSOB#B・299内に、見かけ上の前半残存領域743および見かけ上の後半残存領域744が残る(図15(g)、図16(g)、図22(g)あるいは図24(g)参照)。
上記ステップS21により「見かけ上の消去領域741」の範囲が特定されると、図7のストリームデータ部分消去/仮消去制御部404dを実行する主MPU部404により、タイムマップ情報(図3(h)の252あるいは後述する図29のSOBI)が読み出される。読み出されたタイムマップ情報の内容に基づいて、ユーザが指定した部分消去の範囲に完全に含まれるストリームブロック(1または複数のSOBUあるいは1以上のSOBUを含んだSOB;代表的にはストリームブロック=SOBU)が、検索される。そして、検索されたストリームブロック(換言すると該当SOBに含まれるトランスポートパケットあるいはアプリケーションパケットのうち消去終了位置より前の全てのパケット)が消去される(ステップS22)。
こうして消去されたストリームブロック(あるいはSOBU)は、図2の管理情報(STREAM.IFO/SR_MANGR.IFO)105により、ファイルSTREAM.VRO106にないものとして扱われる(つまり、ファイルシステムは、消去されたストリームブロック/SOBUを無視する)。
なお、消去されたストリームブロック/SOBUの情報が記録されていた情報記憶媒体201上の物理アドレス位置には、図2のDVD_RTRディレクトリ102以外のディレクトリ(管理情報105が関与できないところ、たとえば図2のコンピュータデータ保存用サブディレクトリ113)の下に存在する別ファイルを記録することもできる。この場合も、サブディレクトリ113の下に存在する別ファイルを記録した情報記憶媒体201上の物理的な記録場所は、ファイルシステム上は、ファイルSTREAM.VRO106から外される。
次に、図15(g)等に示す部分消去範囲に対する前半残存領域743と後半残存領域744とでストリームオブジェクト(SOB)を分割する。続いて、この分割により生じた新たなストリームオブジェクト(図15(h)等のSOB#B*745、SOB#C・746)に対するSOB情報(SOBI)が作成され、作成されたSOBIが図7の主MPU部404内のワークRAM部404aに一時記憶される。その際、分割前のSOB#Bに対して記録されていたタイムマップ情報252内の該当個所を転記する形で、新たなSOB#B*745およびSOB#C・746に対するタイムマップ情報も作成される(ステップS23)。
上記タイムマップ情報の内容変更(転記・作成)の具体的な対象は、たとえば図3(i)に示す各種情報(261〜265)、あるいは図29に示すストリームオブジェクト情報(SOBI)の内容(MAPL、MAPL_ENT_Ns等)である。
なお、部分消去によりタイムマップ情報(MAPL)が短くなったときは、短くなったタイムマップ情報(MAPL)を含むSOBIの後にくる「1以上の後続SOBIおよび全ての後続情報テーブル」は、変更された(短くなった)SOBIにアラインされる。こうすることで、隣接SOBI間にギャップが生じることを防止できる。
その場合、図29のSOBI_SRP#、SFITの一部、図3(f)または図27のSTR_VMGI(SFIT以降の情報テーブルの開始アドレス全て)等も、上記SOBIアラインに対応して修正される。
上記ステップS23の処理内容について、さらに説明する。
図7の主MPU部404は、ストリームデータ部分消去/仮消去制御部404dに関するシーケンシャルプログラムに従って処理を実行し、ディスクドライブ部409に対してデータ読み出しの指示を出す。これにより、情報記憶媒体201上でストリームデータが記録されているファイルSTREAM.VRO(またはSR_TRANS.SRO)106(図2)内から、ストリームブロック#5のデータ(図16または図24の(i)〜(l))が再生され、そのデータが主MPU部404内のワークRAM部404aに一時保管される。
次に、主MPU部404は、その一時保管したデータ内を検索し、図16(g)または図24(g)で示す見かけ上の後半残存エリア744の開始時刻に最も近い値を持つタイムスタンプの値を、検索する。
その検索結果が図16(i)〜(k)で示すようにセクタNo.112内にあるタイムスタンプk(あるいは図24(i)〜(k)で示すようにセクタNo.144内にあるタイムスタンプk)の値と一致しあるいは近似していた場合には、このタイムスタンプkの値が、オリジナルセル情報#3・762の該当セルの開始時間752の値に設定される。
こうして設定された該当セルの開始時間(SC_S_ATAP等)752が、主MPU部404内のワークRAM部404aに一時保管された、ストリームデータの管理情報STREAM.IFO(またはSR_MANGR.IFO)105内に追記される。
同様に、オリジナルセル情報#3・762の該当セルの終了時間(SC_E_ATAP等)756の値としては、部分消去前のオリジナルセル情報#2・273の該当セルの終了時間756の値が転記される。
ところで、図15、図16、図22あるいは図24の実施の形態では、ストリームブロック#4が部分消去の範囲内に完全に含まれるので、その部分が実質上の消去領域742として実質的に消去される。
このとき、ストリームブロック#3とストリームブロック#5は実質的には消去されずにそのまま残存するが、図15、図16、図22あるいは図24の(e)〜(g)に示すように、ストリームブロック#3の末尾側およびストリームブロック#5の先頭側の一部は、ユーザ等により指定された見かけ上の消去領域741に含まれている。
この発明の一実施の形態では、部分消去の範囲741に対する前半残存エリア743および後半残存エリア744において、ストリームオブジェクト(SOB#B)が分割・分離されるとともに、それに対応してオリジナルセル範囲も分割・分離される。
この分割・分離に対応して、図15、図16、図22あるいは図24の実施の形態では、ストリームブロック#5の位置を新たにストリームオブジェクト#C・746と定義される。
一方、消去前のストリームオブジェクト(SOB)#B・299に対応するストリームオブジェクト情報(SOBI)#B・243(図3(g))内に記載されたタイムマップ情報(その内容は図3(i)と同様であり、図29のSOBIの内容に対応する)の中で、ストリームブロック#5に対するストリームブロックサイズおよびストリームブロック時間差の値は、部分消去前後で変化しない。
そこで、図17のステップS23に示すように、このタイムマップ情報がそっくりそのまま、STREAM.IFO105内に新規に作成されるストリームオブジェクト#C・746(図16(h)、図24(h)等)に対応するストリームオブジェクト情報#C内のタイムマップ情報として、転記される。
この新たに定義されたストリームオブジェクト#C・746に対応した部分消去後のオリジナルセル情報#3・762(図16(m)または図24(m))が指定する表示範囲は、ユーザが指定した見かけ上の後半残存エリア744の範囲と一致する。
ステップS23の処理によりタイムマップ情報の作成が済むと、新たに定義されたSOB(SOB##B*、SOB#C)に対するオリジナルセル情報が作成される(ステップS24)。
このオリジナルセル情報の作成において、対応オリジナルセル#3・762(図16(m)、図24(m))の指定範囲が設定される。
この設定は、ユーザ等により指定された部分消去終了時刻に該当セルの開始時刻を合わせることで、(あるいはユーザ等により指定された部分消去開始時刻に該当セルの終了時刻を合わせることで)行われる。
具体的には、後述する図31下段の図解を例に採れば、完全消去後(部分消去が完全に実行された後)の新たなSOBのセル#k+1(完全消去前はセル#k+2)の開始時刻(SC_S_APATk+1)を、ユーザ等により指定された消去終了時刻(完全消去前のセル#k+1のSC_E_APATk+1)に合わせることになる。
あるいは、完全消去後のSOBのセル#k(完全消去前もセル#k)の終了時刻(SC_E_APATk)を、ユーザ等により指定された消去開始時刻(完全消去前のセル#k+1のSC_S_APATk+1)に合わせてもよい。
なお、図31下段の図解例において、完全消去の前後で変更のないセル#kについては、その開始時刻(SC_S_APATk)および終了時刻(SC_E_APATk)に変更はない。
上記ステップS24の処理により、前述した「SOBIアライン」がなされる(これにより隣接SOBI間にギャップが生じることを防止できる)。
次に、元の(消去前の)ストリームオブジェクト情報(SOBI)#B・243(図3(g))に関する情報(タイムマップ情報等)が書き替えられる(ステップS25)。
具体的には、実質上の消去領域742(図16(h)、図24(h))の部分および新たに定義されたSOB領域746(図16(h)、図24(h))の部分を元のタイムマップ情報から除去した内容に、タイムマップ情報が書き替えられる。
そうする理由は、部分消去後にはSOB#B*745(図15(h)、図22(h))を構成するストリームブロックは#3のみとなったので、部分消去前のSOBI#B・243内のタイムマップ情報から、実質的に消去されたストリームブロック#4の部分、および別のストリームオブジェクト(SOB#C)の所属になったストリームブロック#5の情報を削除する必要があるからである。
この情報削除がステップS25の情報書替処理である。この削除処理は、図7の主MPU部404内のワークRAM部404aに一時保管された管理情報(STREAM.IFO/SR_MANGR.IFO)105に対してなされる。
このステップS25における情報(タイムマップ情報等)の書き替えにおいても、前述した「SOBIアライン」がなされる(これにより隣接SOBI間にギャップが生じることを防止できる)。
次に消去前のオリジナルセル情報#2・273に関する情報内容の変更処理が行なわれる。ここでは、ステップS24におけるオリジナルセル情報#3・762の作成と同様な処理が実行される。
まず、タイムマップ情報が書き替えられたSOBに対応したオリジナルセルの時刻範囲が変更される(ステップS26)。
この変更は、ユーザ等により指定された部分消去開始時刻に該当セルの終了時刻を合わせることで、(あるいはユーザ等により指定された部分消去終了時刻に該当セルの開始時刻を合わせることで)行われる。
具体的には、後述する図31下段の図解を例に採れば、セル#k(完全消去前もセル#k)の終了時刻(SC_E_APATk)を、ユーザ等により指定された消去開始時刻(完全消去前のセル#k+1のSC_S_APATk+1)に合わせることになる。
あるいは、完全消去後のセル#k+1(完全消去前はセル#k+2)の開始時刻(SC_S_APATk+1)を、ユーザ等により指定された消去終了時刻(完全消去前のセル#k+1のSC_E_APATk+1)に合わせてもよい。
次に、図7の主MPU部404は、ストリームデータ部分消去/仮消去制御部404dに関するシーケンシャルプログラムに従って処理を実行し、ディスクドライブ部409に対してデータ読み出しの指示を出す。これにより、情報記憶媒体201上でストリームデータが記録されているファイルSTREAM.VRO(またはSR_TRANS.SRO)106(図2)内から、ストリームブロック#3のデータ(図15または図22の(i)〜(l))が再生され、そのデータが主MPU部404内のワークRAM部404aに一時保管される。
主MPU部404は、その一時保管したデータ内を検索し、図15(g)または図22(g)で示される見かけ上の前半残存エリア743の終了時刻にもっとも近い値を持つタイムスタンプの値を、検索する。
その検索結果が図15または図22の(i)〜(k)で示すようにセクタNo.90内にあるタイムスタンプvの値と一致しあるいは近似していた場合には、このタイムスタンプvの値が、部分消去後のオリジナルセル情報#2・761(図15(m)、図22(m))の該当セルの終了時間757(図15(l)、図22(l))の値として設定される。
こうして設定された値が、主MPU部404内のワークRAM部404a内に一時保管された管理情報(STREAM.IFO/SR_MANGR.IFO)105に追記される。
なお、部分消去後のオリジナルセル情報#2・761の該当セルの開始時間751の値(SC_S_APAT)は、部分消去前のオリジナルセル情報#2・273の該当セルの開始時間751の値(SC_S_APAT)と同じなので、変更されずにそのままの値が管理情報(STREAM.IFO/SR_MANGR.IFO)105内に残される。
以上一連の処理が終了すると、図7のワークRAM部404a内で変更されたストリームデータの管理情報(STREAM.IFO/SR_MANGR.IFO)105の情報を元に、主MPU部404からディスクドライブ部409へ指示が出される。
これにより、情報記憶媒体201上のSTREAM.IFO/SR_MANGR.IFO105の情報が書き替えられる(ステップS27)。
この情報書き替えの結果、削除されたストリームブロック(SOBU)は図2のファイルシステム(DVD_RTAVのファイルシステム)から無視されるようになる。
最後に、S28で情報記憶媒体201上に記録されたボリューム&ファイル構造情報206(図3(b))の情報が書き替えられて、ファイルシステム情報が更新される(ステップS28)。
ストリームブロック毎のデータサイズと時間情報(時間差)が記録されているストリームオブジェクト情報(SOBI)による指定範囲に対して、この指定範囲に対応した再生範囲を示すオリジナルセル情報の指定範囲を、等しいかあるいは狭くすることができる(図15、図16、図22あるいは図24の(f)〜(h)参照)。このようにすれば、ユーザは、見かけ上、ストリームブロックよりも細かな任意の範囲で、記録済みSOB情報の部分消去が可能となる。
なお、各ストリームブロック毎のデータサイズを加算することで、特定のストリームブロックが記録されている位置(=アドレス情報)を算出することができる。
上記のように部分消去処理を行った後に情報記憶媒体201から再生が行われると、図4に示すように1個のオリジナルPGC290ではオリジナルセル#2とオリジナルセル#3が連続して再生される。
つまり、部分消去処理が実行された情報記憶媒体201からユーザ等により再生が行われる場合には、オリジナルセル情報#2・761(図15(m)等)内の該当セルの開始時間751から該当セルの終了時間757の時刻まで再生された直後に、オリジナルセル情報#3・762(図16(m)等)内の該当セルの開始時間752の位置から、続けて(通常はシームレスに)再生が始まる。
[仮消去の場合]
DVDストリーマでは、2種類の消去が可能となっている。第1は上述したストリームの一部を完全に消去するものであり、第2は以下に述べるストリームの一部を仮に消去する(仮消去またはテンポラリ・イレーズ;これを適宜TEと略記する)ものである。
仮消去に関しては:
(11)ストリームの仮消去部分は完全に構成し直すことができる;
(12)仮消去部分の開始位置および終了位置は、アプリケーションパケット到着時間(APAT)の精度で、時間情報によりマークできる(ストリーマのユーザは、SOB、SOBU、SOBI/MAPL等の内部情報を認識できないが、記録時間は認識できる。そこで、仮消去の範囲、すなわち仮消去部分の開始位置および終了位置を、ユーザが時間ベースでマークできるようにしている。);
(13)記録中、ストリーマのフォーマットは、ストリーム内に配慮せず、仮消去部分を完全消去状態にすることができる(これにより、仮消去部分をリアルタイムでリサイクル利用できるようになる)。
上記(11)〜(13)は、図3(f)、図4、図27または図32に示すオリジナルPGC(ユーザ定義PGCに非ず)内のストリームセル情報SCI(図28)に含まれるプロテクトフラグTE(図28)を利用して、実現できる。このTEフラグは仮消去されたセルを示すものである。
次に、図23(f)あるいは図25(f)に示すストリームオブジェクト(SOB)#B・299の中央部を仮消去するものとし、図23(g)あるいは図25(g)に示すように見かけ上の仮消去領域747が設定される場合を想定して、図17のフローチャートの説明に入る。
仮消去の処理においては、図17のステップS21〜S23の「部分消去範囲」あるいは「消去範囲」を「仮消去範囲」と読み替えれば、処理内容の手順は同様である。また、図17のステップS27〜S28も、処理手順としては、部分消去の場合も仮消去の場合も変わらない。
以下では、図17のステップS24〜S26に関して、仮消去の場合の手順を、図23および図25を参照しながら、説明する。
ステップS23の処理によりタイムマップ情報の作成が済むと、新たに定義されたSOB(SOB##B*、SOB#C)に対するオリジナルセル情報が作成される(ステップS24)。
このオリジナルセル情報の作成において、対応オリジナルセルの指定範囲が設定される。
具体的には、後述する図30(b)の図解を例に採れば、仮消去フラグTEが”10b”に設定されたセル#k+1の開始時刻は、ユーザ等により指定された仮消去開始時刻(ERA_S_APAT;仮消去の開始マーク)となる。また、仮消去フラグTEが”10b”に設定されたセル#k+1の終了時刻は、ユーザ等により指定された仮消去終了時刻(ERA_E_APAT;仮消去の終了マーク)となる。
あるいは、後述する図31上段の図解を例に採れば、仮消去フラグTEが”10b”に設定されたセル#k+1の開始時刻はSC_S_APATk+1となり、このセル#k+1の終了時刻はSC_E_APATk+1となる。
次に、元の(仮消去前の)ストリームオブジェクト情報(SOBI)に関する情報(タイムマップ情報等)が、前述した部分消去と同様な方法で書き替えられる(ステップS25)。
この仮消去では、仮消去対象のデータ自体が消去されるのではなく、消去対象のデータの管理情報が「仮消去」状態に書き替えられるだけである。しかし、仮消去対象のデータ(図30(b)あるいは図31上段の例ではセル#k+1のデータ)が完全消去されると、以下の処理がなされる。
まず、タイムマップ情報が書き替えられたSOBに対応したオリジナルセルの時刻範囲が変更される(ステップS26)。
具体的には、後述する図30の図解を例に採れば、図30(b)の仮消去セル#k+1の開始時刻(ERA_S_APAT)が図30(c)の完全消去後のセル#kの終了時刻(SC_E_APAT)に合わせられ、図30(b)の仮消去セル#k+1の終了時刻(ERA_E_APAT)が図30(c)の完全消去後のセル#k+1(完全消去前はセル#K+2)の開始時刻(SC_S_APAT)に合わせられることになる。
以上の仮消去処理の要点を纏めると、次のようになる。
(a)仮消去の開始時刻(ERA_S_APAT)および仮消去の終了時刻(ERA_E_APAT)によって、ストリームオブジェクト(SOB)に含まれるビットストリーム情報の一部(図23または図25の仮消去領域747)に対する仮の消去範囲が指定される(ステップS21において、「部分消去範囲」を「仮消去範囲」に読み替える)。
開始時刻(SC_S_APAT)がストリームブロック(SOBU)内で開始するトランスポートパケット(アプリケーションパケット)の先頭に一致するときに、開始時刻(SC_S_APAT)を伴うトランスポートパケット(アプリケーションパケット)を含むところのストリームブロック(SOBU)内で開始するトランスポートパケット(アプリケーションパケット)のうちの最初のものの開始時刻(SC_S_APAT)に、仮消去の開始時刻(ERA_S_APAT)を合わせる(ステップS26において、「部分消去」を「仮消去」に読み替える)。そして、ストリーマ情報(STREAM.IFO/STRI)を書き替える(ステップS27)。
(b)あるいは、仮消去の開始時刻(ERA_S_APAT)および仮消去の終了時刻(ERA_E_APAT)によって、ストリームオブジェクト(SOB)に含まれるビットストリーム情報の一部(図23または図25の仮消去領域747)に対する仮の消去範囲が指定される(ステップS21において、「部分消去範囲」を「仮消去範囲」に読み替える)。
仮の消去範囲が指定された部分に相当するセル(TEセル)がストリームオブジェクト(SOB)の先頭を含むときに、開始時刻(SC_S_APAT)を伴うトランスポートパケット(アプリケーションパケット)を含むところのストリームブロック(SOBU)内で開始するトランスポートパケット(アプリケーションパケット)のうちの最初のものの開始時刻(SC_S_APAT)に、仮消去の開始時刻(ERA_S_APAT)を合わせる(ステップS26において、「部分消去」を「仮消去」に読み替える)。そして、ストリーマ情報(STREAM.IFO/STRI)を書き替える(ステップS27)。
(c)あるいは、仮消去の開始時刻(ERA_S_APAT)および仮消去の終了時刻(ERA_E_APAT)によって、ストリームオブジェクト(SOB)に含まれるビットストリーム情報の一部(図23または図25の仮消去領域747)に対する仮の消去範囲が指定される(ステップS21において、「部分消去範囲」を「仮消去範囲」に読み替える)。
開始時刻(SC_S_APAT)を伴うトランスポートパケット(アプリケーションパケット)を含むところのストリームブロック(図30(b)のSOBU#3)が直後に続く他のストリームブロック(図30(b)のSOBU#2)内で開始するトランスポートパケット(アプリケーションパケット)のうちの最初のものの開始時刻(SC_S_APAT)に、仮消去の開始時刻(ERA_S_APAT)を合わせる(ステップS26において、「部分消去」を「仮消去」に読み替える)。そして、ストリーマ情報(STREAM.IFO/STRI)を書き替える(ステップS27)。
(d)あるいは、仮消去の開始時刻(ERA_S_APAT)および仮消去の終了時刻(ERA_E_APAT)によって、ストリームオブジェクト(SOB)に含まれるビットストリーム情報の一部(図23または図25の仮消去領域747)に対する仮の消去範囲が指定される(ステップS21において、「部分消去範囲」を「仮消去範囲」に読み替える)。
仮の消去範囲が指定された部分に相当するセル(TEセル)の直後に続くトランスポートパケット(アプリケーションパケット)を含むところのストリームブロック(図30(c)のセル#k+1のSOBU#1)内で開始するトランスポートパケット(アプリケーションパケット)のうちの最初のものの開始時刻(SC_S_APAT)に、仮消去の終了時刻(ERA_E_APAT)を合わせる(ステップS26において、「部分消去」を「仮消去」に読み替える)。そして、ストリーマ情報(STREAM.IFO/STRI)を書き替える(ステップS27)。
図18は、MPEGエンコードされた映像データ(部分消去前あるいは仮消去前)に対する時間管理情報設定方法を説明する図である。
また、図19は、図18の映像データに対応したオリジナルセル情報(部分消去前あるいは仮消去前)における時間情報とフィールド情報との関係を説明する図である。
前述した実施の形態では、特定のデータサイズ(たとえば32セクタ/64kバイト)毎に分割したストリームブロック(SOBU)毎に実質的な部分消去を行い、詳細な見かけ上の部分消去範囲を、オリジナルセル範囲で定義できるようになっている。
しかし、この発明はそれだけに限られない。映像データなどの特定のデータをユニットもしくはブロックに分割管理し、そのユニットもしくはブロック単位で消去を行なうとともに、再生情報(セルなど)の範囲指定により「ユーザによる詳細な再生範囲を指定できる」あらゆる方法に対して、この発明を適用することができる。
たとえば、MPEG2により記録された映像情報を管理する管理情報ファイルであるRTR.IFO104(図2)では、図18に示すようにMPEG2の動画圧縮に特有なIピクチャから次のIピクチャの手前までがユニット化されて取り扱われる。このユニットは、ビデオオブジェクトユニット(VOBU)と呼ばれる。このVOBUは、ストリームオブジェクトユニット(SOBU)に対応させて考えることができる。
NTSCのTV規格では、1秒間に約30枚の画像(フレーム)を表示している。各画像をピクチャと呼び、インターレース方式では1枚のピクチャ(フレーム)を2回のフィールド走査(奇数フィールド走査と偶数フィールド走査)で表現している。
ストリーマでは、ストリームデータが受信機に到達した時刻情報が記録されているタイムスタンプ情報を、時間(時刻)情報として利用している。しかし、この発明の一実施の形態においては、映像情報に対しては、図18に示す最初のIピクチャaから数えたフィールド数で、時間(時刻)情報を表わすことも可能としている。
この実施の形態でのタイムマップ情報は、VOBU(あるいはSOBU)毎のユニットとして管理される。たとえば、図3(i)のストリームブロックサイズ262に対しては、1個のVOBU(あるいはSOBU)のデータサイズが対応する。また、ストリームブロック時間差263に対応する時間情報としては、1個の対応するVOBU(あるいはSOBU)内に含まれるフィールド数が当てはまる。
このとき、オリジナルセル#1の情報(図28のSCI)763(図19)における該当セルの開始時間(SC_S_APATあるいはERA_S_APAT)753および該当セルの終了時間(SC_E_APATあるいはERA_E_APAT)758の情報は、図18の先頭Iピクチャaから数えたフィールド数で表現できる。
たとえば、図18のn枚目のピクチャの時間情報は、2n番目のフィールドとして表現できる。
図20は、MPEGエンコードされた映像データ(部分消去後あるいは仮消去後)に対する時間管理情報設定方法を説明する図である。
また、図21は、図20の映像データに対応したオリジナルセル情報(部分消去後あるいは仮消去後)における時間情報とフィールド情報との関係を説明する図である。
図18の映像情報に対して部分消去の処理を行った場合には、図20に示すように、VOBU#2(SOBU#2)のみが実質的に部分消去される。ユーザ等が指定した細かい部分消去の範囲は、図15その他を参照して説明したストリームデータの部分消去の場合と同様、セルの範囲設定で規定できる。
すなわち、図20において、ユーザ等がBピクチャfからBピクチャsまで部分消去を指定した場合、部分消去指定範囲に完全に含まれるVOBU#2(SOBU#2)は完全に消去される。このとき、一部のみ部分消去の指定範囲に含まれるVOBU#1(SOBU#1)およびVOBU#3(SOBU#3)は、VOBU単位(SOBU単位)で実質的に残存する。
ストリームデータの場合と同様に、部分消去した部分の前後でVOB(あるいはSOB)が分割されてVOB#1(SOB#1)とVOB#2(SOB#2)になる。これに対応して、部分消去前のセルは、オリジナルセル#1とオリジナルセル#2に分かれる。
このとき、図21に示すように、オリジナルセル#1の情報(SCI)764の該当セルの終了時間(SC_E_APATあるいはERA_E_APAT)759としてBピクチャfに対応した2f番目のフィールドを指定し、オリジナルセル#2の情報(SCI)765の該当セルの開始時間(SC_S_APATあるいはERA_S_APAT)754としてBピクチャsに対応した2(s―q)番目のフィールドを指定することができる。
たとえば、図20のf枚目のピクチャの時間情報は、2f番目のフィールドとして表現できる。
図20、図21の実施の形態では、フィールド数は、必ずVOB(SOB)毎にVOBの先頭ピクチャから数えたフィールド数で表わしている。さらに、セル情報(SCI)内で、フィールド数により、対応するVOB(SOB)を指定できるようにしている。ここにこの実施の形態の特徴がある。
図26は、ストリームブロック(SOBU)を構成するセクタの内部構成(アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック)の一例を説明する図である。
図26(d)のストリームオブジェクト(SOB)#A・298は、図26(c)(e)に示すように、複数のストリームブロック#1、#2、…で構成されている。
各ストリームブロック#1、#2、…は全て、2ECCブロックサイズ(=32セクタ=64kバイト)のストリームオブジェクトユニット(SOBU)で構成される。
このようにすると、たとえばストリームブロック(SOBU)#2を削除しても、ストリームブロック(SOBU)#1のECCブロックはこの削除に影響されない。
SOB#A・298の先頭ストリームブロック(SOBU)#1は、図26(b)に示すように、セクタNo.0〜セクタNo.31(32セクタ/64kバイト)で構成されている。
ストリームブロック(SOBU)#1の各セクタは、同様なデータ構造を持っている。、たとえばセクタNo.0についていうと、図26(a)に示すようになっている。
すなわち、セクタNo.0は2048バイト(2kバイト)のストリームパックにより構成される。このストリームパックは、14バイトのパックヘッダと、2034バイトのストリームPESパケットとで構成される。
ストリームPESパケットは、6バイトのPESヘッダと、1バイトのサブストリームIDと、2027バイトのストリームデータエリアとで構成される。
ストリームデータエリアは、9バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、アプリケーションパケットエリアとで構成される。
アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ(ATS)を先頭に持つアプリケーションパケット群で構成される。
たとえば188バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、10個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ(たとえば2048バイト)を持つものとして扱うことができる。
図26(a)のスタッフィングバイトは、ストリームパックを常に所定長(2048バイト)に保つために利用できる。
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。図9の下段に例示した部分パケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。
こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
図26(a)のパックヘッダは、図示しないが、パック開始コードの情報、SCRベースの情報、SCRエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。
SCRベースは32ビットで構成され、その32ビット目はゼロとされる。また、プログラム最大レートとしては、10.08Mbpsが採用される。
図26(a)のPESヘッダおよびサブストリームIDは、図10(c)に示したような内容を持っている。
図26(a)のアプリケーションヘッダは、図12(c)に示したように、バージョン情報、アプリケーションパケット数AP_Ns、先頭アプリケーションパケットのタイムスタンプ位置FIRST_AP_OFFSET、エクステンションヘッダ情報EXTENSION_HEADER_IFO、サービスID等を含んでいる。
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
アプリケーションヘッダのAP_Nsは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にATSの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
FIRST_AP_OFFSETには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、FIRST_AP_OFFSETには「0」が記述される。
EXTENSION_HEADER_INFOには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かが、記述される。
EXTENSION_HEADER_INFOの内容が00bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
EXTENSION_HEADER_INFOの内容が10bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
EXTENSION_HEADER_INFOの内容が11bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
EXTENSION_HEADER_INFOの内容が01bとなることは禁止されている。
アプリケーションパケットエリアの前のスタッフィングバイト(オプション)は、「EXTENSION_HEADER_INFO=11b」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
SERVICE_IDには、ストリームを生成するサービスのIDが記述される。このサービスが未知のものであれば、SERVICE_IDに0x0000が記述される。
図26(a)のアプリケーションパケットエリアは、図9の下段に示したと同様に構成できる(図9のパケットを図26ではアプリケーションパケットに読み替える)。
すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプATSとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ(ATS)は32ビット(4バイト)で構成される。このATSは、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
図26(a)において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。
それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを(前述したEXTENSION_HEADER_INFOにおいて)記述できるように定義されいる。
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。図8(f)(g)あるいは図9に示した部分アプリケーションパケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。
こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
アプリケーションヘッダエクステンション(オプション)はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する1バイト長の1エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
なお、1バイトのアプリケーションヘッダエクステンション(オプション)には、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが、記述される。
AU_STARTが”1”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。
AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
図26(a)のパケット構造は、SOB#A・298の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。
たとえば、SOB#A・298の末尾が図26(f)のセクタNo.63であり、このセクタが図26(g)に示すようにパディングパケット40(図1(i)参照)で構成されるときは、そのパディングエリア38(図26(h))の内容が、図26(a)と違ったものになる。
すなわち、図26(i)に示すように、パディングパケット40としてのスタッフィングパケットは、14バイトのパックヘッダと、6バイトのPESヘッダと、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、2018バイトのアプリケーションパケットエリアとで構成される。
スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、4バイトのアプリケーションタイムスタンプATSおよび2014バイト分のゼロバイトデータ(実質的な記録内容を持たないデータ)で構成される。
一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、2018バイト分のゼロバイトデータ(ATSなし)で構成される。
ビットレートが極めて低い記録がなされる場合、タイムマップ情報(図3(h)の252;あるいは図29のSOBI内MAPL)の回復(再生)を確実にするためにスタッフィングが必要になる。図26(i)のスタッフィングパケットは、そのための概念的な単位として定義されている。このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。
スタッフィングパケットには、以下の条件が付く:
*1または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する;
*1または複数のスタッフィングパケットは、1つの4バイトATSと、該当SOBUの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ(ATSの後に続く)とで構成される。いま、SOBU1個あたりのセクタ数をSOBU_SIZとしたときに、0≦n≦SOBU_SIZー1とすれば、スタッフィングパケットの全長は、「4+2014+n×2018」バイトとなる。
スタッフィングパケットのATSは、次のように設定される:
*少なくとも1個のパックが実際のアプリケーションパケットデータを含んでいるSOBU内では、スタッフィングパケットのATSは、スタッフィングパケットに先行するアプリケーションパケットのATSに設定される;
*実際のアプリケーションパケットデータを含まないSOBU内では、スタッフィングパケットのATSはタイムマップ情報等の内容に応じて決定される。
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される:
*パックヘッダのSCRは、先行パックのSCRに「2048×8ビット÷10.08Mbps」を加えたものとする;
*PESパケットヘッダおよびサブストリームIDは、他の全てのPESパケットに対するものと同じにする;
*アプリケーションヘッダ(図12(c)(d)参照)内において、AP_Ns=0、FIRST_AP_OFFSET=0、EXTENSION_HEADER_IFO=00b、SERVICE_ID=0(アプリケーションヘッダ内のその他のパラメータも0)とする。
図27は、ストリーマの管理情報(図2のSTREAM.IFOまたはSR_MANGR.IFOに対応)の内部データ構造を説明する図である。
図2あるいは図3(e)に示した管理情報(ナビゲーションデータ)であるSTREAM.IFO(SR_MANGR.IFO)105は、図27に示すように、ストリーマ情報STRIを含んでいる。
このストリーマ情報STRIは、図3(f)あるいは図27に示すように、ストリーマビデオマネージャ情報STR_VMGIと、ストリームファイル情報テーブルSFITと、オリジナルPGC情報ORG_PGCI(より一般的に表現すればPGC情報PGCI#i)と、ユーザ定義PGC情報テーブルUD_PGCITと、テキストデータマネージャTXTDT_MGと、アプリケーションプライベートデータマネージャAPDT_MGとで、構成されている。
ストリーマビデオマネージャ情報STR_VMGIは、図27に示すように、STRI、STR_VMGIに関する管理情報等が記述されたビデオマネージャ情報管理情報VTSI_MATと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル(PL_SRPT)とを含んでいる。
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。
ストリームファイル情報テーブルSFITは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルSFITの詳細については、図29を参照して後述する。
オリジナルPGC情報ORG_PGCIは、オリジナルPGC(ORG_PGC)に関する情報を記述した部分である。ORG_PGCはプログラムセットを記述したナビゲーションデータを示す。ORG_PGCはプログラムの連なり(チェーン)であり、図2または図32の「.SRO」ファイル(図2ではSR_TRANS.SRO106)内に記録されたストリームデータを含む。
ここで、プログラムセットとは、情報記憶媒体201の記録内容全体(全てのプログラム)を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルPGC(ORG_PGC)と呼ばれるデータ構造に対応している。
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、1以上のオリジナルセルにより構成される。プログラムはオリジナルPGC内でのみ定義されるものである。
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義PGC内のセルは「ユーザ定義セル」と呼ばれる。
プログラムセット内の各々のプログラムは、少なくとも1個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも1個のユーザ定義セルで構成される。
一方、ストリーマでは、ストリームセル(SC)だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
なお、プログラムチェーン(PGC)とは、上位概念的な単位を示す。オリジナルPGCでは、PGCはプログラムセットに対応したプログラムの連なり(チェーン)を指す。また、ユーザ定義PGCでは、PGCはプレイリストに対応するプログラムの一部の連なり(チェーン)を指す。
また、プログラムの一部のチェーンを指すユーザ定義PGCは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルPGCに属するストリームデータを参照するようになっている。
図27のユーザ定義PGC情報テーブルUD_PGCITは、ユーザ定義PGC情報テーブル情報UD_PGCITIと、1以上のユーザ定義PGCサーチポインタUD_PGC_SRP#nと、1以上のユーザ定義PGC情報UD_PGCI#nとを含むことができる。
ユーザ定義PGC情報テーブル情報UD_PGCITIは、ユーザ定義PGCサーチポインタUD_PGC_SRPの数を示すUD_PGC_SRP_Nsと、ユーザ定義PGC情報テーブルUD_PGCITの終了アドレスを示すUD_PGCIT_EAとを含む。
UD_PGC_SRP_Nsが示すUD_PGC_SRPの数は、ユーザ定義PGC情報(UD_PGCI)の数と同じであり、ユーザ定義PGC(UD_PGC)の数とも同じである。この数は、最大「99」まで許されている。
UD_PGCIT_EAは、該当UD_PGCITの終了アドレスを、そのUD_PGCITの先頭バイトからの相対バイト数(F_RBN)で記述したものである。
ここで、F_RBNとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
オリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したPGCI#iについては、図28を参照して後述する。
図27のテキストデータマネージャTXTDT_MGは、補足的なテキスト情報である。このTXTDT_MGは、図28のプライマリテキスト情報PRM_TXTIとともに、プレイリストおよびプログラム内に格納できる。
図27のアプリケーションプライベートデータマネージャAPDT_Mは、図示しないが、アプリケーションプライベートデータマネージャ一般情報APDT_GIと、1以上のAPDTサーチポインタAPDT_SRP#nと、1以上のAPDTエリアAPADTA#nとを含むことができる。
ここで、アプリケーションプライベートデータAPDTとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報(リアルタイムストリームデータに加えさらに望まれる情報)を格納できるような概念上のエリアである。
図28は、PGC情報(図3のORG_PGCI/UD_PGCITまたは図27のPGCI#i)の内部データ構造を説明する図である。
図28のPGC情報PGCI#iは、図27のオリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したものである。
図28に示すように、PGC情報PGCI#iは、PGC一般情報PGC_GIと、1以上のプログラム情報PGI#mと、1以上のストリームセル情報サーチポインタSCI_SRP#nと、1以上のストリームセル情報SCI#nとで構成されている。
PGC一般情報PGC_GIは、プログラムの数PG_Nsと、ストリームセル情報サーチポインタSCI_SRPの数SCI_SRP_Nsとを含んでいる。
各プログラム情報PGI(たとえばPGI#1)は、プログラムタイプPG_TYと、該当プログラム内のセルの数C_Nsと、該当プログラムのプライマリテキスト情報PRM_TXTIと、アイテムテキストのサーチポインタ番号IT_TXT_SRPNとを含んでいる。
ここで、プログラムタイプPG_TYは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
このプロテクトフラグが「0b」のときは該当プログラムは保護されておらず、「1b」のときは保護された状態にある。
セルの数C_Nsは、該当プログラム内のセルの数を示す。PGCの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに(暗黙のうちに)付随している。
たとえば、PGC内でプログラム#1がC_Ns=1を持ち、プログラム#2がC_Ns=2を持つとすれば、そのPGCの最初のストリームセル情報SCIはプログラム#1に付随するものとなり、第2、第3のSCIはプログラム#2に付随するものとなる。
プライマリテキスト情報PRM_TXTIは、情報記憶媒体(DVD−RAMディスク)201を世界中で利用可能とするために、1つの共通キャラクタセット(ISO/IEC646:1983(ASCIIコード))を持ったテキスト情報を記述したものである。
アイテムテキストのサーチポインタ番号IT_TXT_SRPNは、アイテムテキスト(該当プログラムに対応するテキストデータ)IT_TXTに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、IT_TXT_SRPNは「0000h」にセットされる。
各ストリームセル情報サーチポインタSCI_SRP(たとえばSCI_SRP#1)は、対応ストリームセル情報SCIの開始アドレスを示すSCI_SAを含んでいる。このSCI_SAは、PGCIの先頭バイトからの相対バイト数(F_RBN)で記述される。
各ストリームセル情報SCI(たとえばSCI#1)は、ストリームセル一般情報SC_GIと、1以上のストリームセルエントリポイント情報SC_EPI#nとで構成される。
ストリームセル一般情報SC_GIは、仮消去(テンポラリイレーズ;TE)状態を示すフラグTEを含むセルタイプC_TYと、ストリームセルのエントリポイント情報の数SC_EPI_Nsと、ストリームオブジェクト番号SOB_Nと、ストリームセル開始APAT(図6他で示したSC_S_APAT)と、ストリームセル終了APAT(図6他で示したSC_E_APAT)と、セルが仮消去状態(TE=01b)にあるときにその仮消去セルの開始APATを示す消去開始APAT(図6他で示したERA_S_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの終了APATを示す消去終了APAT(図6他で示したERA_E_APAT)とを含んでいる。
セルタイプC_TYは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
すなわち、セルの形式C_TY1=「010b」は全てのストリームセルの形式に記述される(このC_TY1=「010b」によりストリームセルとそれ以外のセルの区別ができる)。
一方、フラグTEが「00b」であれば該当セルは通常の状態にあることが示され、フラグTEが「01b」あるいは「10b」であれば該当セルは仮消去の状態にあることが示される。
フラグTE=「01b」は、該当セル(仮消去状態にあるセル)が、SOBU内で開始する最初のアプリケーションパケットの後から開始し、同じSOBU内の最終アプリケーションパケットの前で終了する場合を示す。
また、フラグTE=「10b」は、該当セル(仮消去状態にあるセル)が、少なくとも1つのSOBU境界(先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのSOBU内で開始する)を含む場合を示す。
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのTEフラグとは、同時に設定できないようになっている。それゆえ、
(a)プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず;
(b)仮消去状態にあるセルを1以上含むプログラムはプロテクト状態に設定できない。
ストリームセルのエントリポイント情報の数SC_EPI_Nsは、該当ストリームセル情報SCI内に含まれるストリームセルエントリポイント情報の数を記述したものである。
図28の各ストリームセルエントリポイント情報SC_EPI(たとえばSC_EPI#1)は、2種類(タイプAとタイプB)存在する。
タイプAのSC_EPIは、エントリポイントタイプEP_TYとエントリポイントのアプリケーションパケット到着時間EP_APATとを含む。タイプAは、エントリポイントタイプEP_TY1=「00b」により示される。
タイプBのSC_EPIは、タイプAのEP_TYおよびEP_APATの他に、プライマリテキスト情報PRM_TXTIを含む。タイプBは、エントリポイントタイプEP_TY1=「01b」により示される。
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間(APAT)により特定できる。このAPATにより、どこからデータ出力が開始されるのかを特定できる。
ストリームオブジェクト番号SOB_Nは、該当セルが参照するSOBの番号を記述したものである。
ストリームセル開始APAT(SC_S_APAT)は、該当セルの開始APATを記述したものである。
ストリームセル終了APAT(SC_E_APAT)は、該当セルの終了APATを記述したものである。
消去開始APAT(ERA_S_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、この仮消去セルに先頭が含まれる最初のSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
消去終了APAT(ERA_E_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、仮消去セルのすぐ後に続くアプリケーションパケットを含むSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
図29は、ストリームファイル情報テーブル(図3(f)または図27のSFIT)の内部データ構造を説明する図である。
図29に示すように、ストリームファイル情報テーブルSFITは、ストリームファイル情報テーブル情報SFITIと、1以上のストリームオブジェクトストリーム情報SOB_STI#nと、ストリームファイル情報SFIとで構成される。
ストリームファイル情報テーブル情報SFITIは、情報記憶媒体(DVD−RAMディスク)201上のストリームファイル情報の数SFI_Nsと、SFITIに続くストリームオブジェクトストリーム情報の数SOB_STI_Nsと、SFITの終了アドレスSFIT_EAと、SFIの開始アドレスSFI_SAとで構成される。
SFIT_EAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFITの終了アドレスを記述したものである。
また、SFI_SAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFIの開始アドレスを記述したものである。
ストリームオブジェクトストリーム情報SOB_STIは、3種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、SOB_STIは、ストリームオブジェクト情報(SOBI)のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト(SOB)が同じSOB_STIを共有する(つまり同じSOB_STIをポイントする)ことが認められている。したがって、通常は、SOBの数よりもそB_STIの数の方が少なくなる。
図27の各ストリームオブジェクトストリーム情報SOB_STI(たとえばSOB_STI#1)は、アプリケーションパケットサイズAP_SIZと、サービスIDの数SERV_ID_Nsと、サービスID(SERV_IDs)と、アプリケーションパケットデバイスユニークID(AP_DEV_UID)とを含んでいる。
AP_SIZは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
なお、DVDストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため各々の中断のない記録中においてアプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト(現SOB)はそこで終了され、新たなストリームオブジェクト(新SOB)が、新たなAP_SIZを伴って開始される。その際、現SOBおよび新SOBの双方は、オリジナルPGC情報(ORG_PGCI)内の同じプログラムに属するものとなる。
SERV_ID_Nsは、後続パラメータに含まれるサービスIDの数を記述したものである。
SERV_IDsは、サービスIDのリストを任意の順序で記述したものである。
AP_DEV_UIDは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスIDを記述したものである。
ストリームファイル情報SFIは、図29に示すように、ストリームファイル一般情報SF_GIと、1以上のストリームオブジェクト情報(SOB情報)サーチポインタ(SOBI_SRP)#nと、1以上のSOB情報(SOBI)#nとで構成されている。
ストリームファイル一般情報SF_GIは、SOBIの数SOBI_Nsと、SOBU1個あたりのセクタ数SOBU_SIZと、タイムマップ情報の一種であるMTU_SHFTとを含んでいる。
ここで、SOBU_SIZは、SOBUのサイズをセクタ数で記述したもので、このサイズは32(32セクタ=64kバイト)で一定となっている。このことは、各タイムマップ情報(MAPL)内において、最初のエントリが、SOBの最初の32セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、2番目のエントリは、次の32セクタに含まれるアプリケーションパケットに関係する。3番目以降のエントリについても以下同様である。
各SOB情報サーチポインタ(たとえばSOBI_SRP#1)は、SOBIの開始アドレスSOBI_SAを含んでいる。このSOBI_SAは、ストリームファイル情報SFIの先頭バイトから相対バイト数(F_RBN)でもって関連SOBIの開始アドレスを記述したものである。
各SOB情報(たとえばSOBI#1)は、ストリームオブジェクト一般情報SOB_GIと、タイムマップ情報MAPLと、アクセスユニットデータAUD(オプション)とで構成される。
ストリームオブジェクト一般情報SOB_GIは、ストリームオブジェクトのタイプSOB_TYと、ストリームオブジェクト記録時間SOB_REC_TMと、ストリームオブジェクトのストリーム情報番号SOB_STI_Nと、アクセスユニットデータフラグAUD_FLAGSと、ストリームオブジェクトの開始アプリケーションパケット到着時間SOB_S_APATと、ストリームオブジェクトの終了アプリケーションパケット到着時間SOB_E_APATと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットSOB_S_SOBUと、タイムマップ情報のエントリ数MAPL_ENT_Nsとを含んでいる。
ストリームオブジェクトのタイプSOB_TYは、仮消去状態(TE状態)を示すビットおよび/またはコピー世代管理システムのビットを記述できる部分である。
ストリームオブジェクト記録時間SOB_REC_TMは、関連ストリームオブジェクト(SOB)の記録時間を記述したものである。
ストリームオブジェクトのストリーム情報番号SOB_STI_Nは、該当ストリームオブジェクトに対して有効なSOB_STIのインデックスを記述したものである。
アクセスユニットデータフラグAUD_FLAGSは、該当ストリームオブジェクトにたいしてアクセスユニットデータ(AUD)が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
アクセスユニットデータ(AUD)が存在する場合は、AUD_FLAGSにより、AUDの幾つかの特性が記述される。
アクセスユニットデータ(AUD)自体は、図29に示すように、アクセスユニット一般情報AU_GIと、アクセスユニットエンドマップAUEMと、再生タイムスタンプリストPTSLとで構成される。
アクセスユニット一般情報AU_GIは、該当SOBに対して記述されたアクセスユニットの数を示すAU_Nsと、該当SOBに属するSOBUのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップAUSMとを含んでいる。
アクセスユニットエンドマップAUEMは、(もし存在するときは)AUSMと同じ長さのビットアレイであり、該当SOBのアクセスユニットに付随するビットストリームセグメントの終端をどのSOBUが含むのかを示す。
再生タイムスタンプリストPTSLは、該当SOBに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる1つのPTSLエレメントは、対応アクセスユニットの再生タイムスタンプ(PTS)を含む。
なお、アクセスユニット(AU)とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、MPEGのIピクチャに対応する部分となる。
ここで再びSOB_GIの内容説明に戻る。
AUD_FLAGSは、フラグRTAU_FLGと、フラグAUD_FLGと、フラグAUEM_FLGと、フラグPTSL_FLGとを含んでいる。
フラグRTAU_FLGが0bのときは、該当SOBのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
フラグRTAU_FLGが1bのときは、図26(a)のアプリケーションヘッダエクステンション内に記述されるAUフラグ(AU_START、AU_END)が、該当SOBのリアルタイムデータ内に存在可能なことが示される。この状態は、下記AUD_FLGが0bの場合にも許される。
フラグAUD_FLGが0bのときは、該当SOBに対してアクセスユニットデータ(AUD)がないことが示される。
フラグAUD_FLGが1bのときは、該当SOBに対してアクセスユニットデータ(AUD)が存在し得ることが示される。
フラグAUEM_FLGが0bのときは、該当SOBにAUEMが存在しないことが示される。
フラグAUEM_FLGが1bのときは、該当SOBにAUEMが存在することが示される。
フラグPTSL_FLGが0bのときは、該当SOBにPTSLが存在しないことが示される。
フラグPTSL_FLGが1bのときは、該当SOBにPTSLが存在することが示される。
SOB_S_APATは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、SOB_S_APATにより、該当SOBに属する最初のアプリケーションパケット到着時間が示される。
このパケット到着時間(PAT)は、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
SOB_E_APATは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、SOB_E_APATにより、該当SOBに属する最後のアプリケーションパケット到着時間が示される。
SOB_S_SOBUは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、SOB_S_SOBUにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むSOBUが示される。
MAPL_ENT_Nsは、SOBI_GIの後に続くタイムマップ情報(MAPL)のエントリ数を記述したものである。
タイムマップ情報MAPLは、図3(h)のタイムマップ情報252に対応する内容を持つ。
図30は、あるプログラム#jの一部が部分的に消去(仮消去および本消去)された場合における、セルと対応時間情報(SC_S_APAT/SC_E_APAT;ERA_S_APAT/ERA_E_APAT)との関係例(その1)を説明する図である。
この発明の一実施の形態に係るストリーマは、図17のところで前述したように、ストリームの一部を完全に消去する部分消去と、ストリームの一部を仮に消去(テンポラリイレーズ;TE)する仮消去とを扱うことができる。
いま、図30(a)に示すようにオリジナルプログラム(SOB#nに対応)のプログラム#jがセル#kで構成され、このセル#kがSOBU#1〜SOBU#6で構成されているとする。このとき、セル#kの開始時間がSC_S_APATで示され、その終了時間がSC_E_APATで示されている。
このようなプログラム#jにおいて、ストリーマのユーザが、図30(b)に示すように、SOBU#3〜SOBU#4を完全に含むエリア(SC_S_APATから始まりSC_E_APATで終わる)を仮消去セル#k+1として設定したとする。このとき、セル#k+1の仮消去フラグTEは「10b」となる。
この場合、仮消去前(図30(a))のセル#kのSOBU#1〜SOBU#2に対応する部分は、仮消去後(図30(b))も変わらずセル#kとなる。また、仮消去セル(TEセル)#k+1に含まれるSOBU#3〜SOBU#4の後のSOBU#5〜SOBU#6に対応する部分は、仮消去後(図30(b))のセル#k+2となる。
図30(b)に示すように、仮消去セル(TEセル)#k+1は、SOBU#3とSOBU#4との間にできるSOBU境界を含んでいる。この場合、SOBU#3内で開始する先頭アプリケーションパケットのアプリケーションパケット到着時間が、TEセル#k+1のERA_S_APATで示される。また、TEセル#k+1の直ぐ後に続くアプリケーションパケットを含むSOBU#5内で開始する先頭アプリケーションパケットのアプリケーションパケット到着時間が、TEセル#k+1のERA_E_APATで示されている。
図30(b)のプログラム#jからTEセル#k+1が本当に消去(完全消去)されると、オリジナルプログラム(図30(a))ではSOB#nに属していたプログラム#jは、図30(c)に示すように、SOB#nとSOB#n+1とに分かれる。
この場合、完全消去後のセル#kのSC_E_APATを、TEセル#k+1のERA_S_APATに合わせることができる。また、完全消去後のセル#k+1のSC_S_APATは、TEセル#k+1のERA_E_APATに合わせることができる。
このようにSC_S_APATおよびSC_E_APATだけでなくERA_S_APATおよびERA_E_APATも用いる理由を以下に述べる。
TEセルは、2種類の特別なAPAT、すなわちSC_S_APAT/SC_E_APATとERA_S_APAT/ERA_E_APATを持つことができる。それは、TEセル内のSOBU(図30(b)ではSOBU#3〜SOBU#4)を、記録中に再利用できるようにするためである。
換言すれば、記録中に媒体(DVD−RAMディスク)201が満杯になってしまったとき、ストリーマは、TEセルを完全消去することにより新たな未記録状態のSOBU(図30(b)ではSOBU#3〜SOBU#4)を獲得し、このSOBUを用いて記録を中断なく継続する。
この「新たな未記録状態のSOBUの獲得」という目的に対しては、TEセルのSC_S_APATおよびSC_E_APATだけでは不十分である。というのも、タイムマップ情報(MAPL)を介した検索において、割り当てられたSOBUには2つの可能な検索位置ができてしまうためである。しかし、ERA_S_APATおよびERA_E_APATを用いれば、ストリームに何ら関与することなく正確なSOBU位置を特定できるようになる。
図31は、あるプログラム#jの一部が部分的に消去(仮消去および本消去)された場合における、セルと対応時間情報(SC_S_APAT/SC_E_APAT)との関係例(その2)を説明する図である。
図31において、オリジナル記録のプログラム#jは、TEフラグが「00b」のセル#k(開始時間はSC_S_APAT;終了時間はSC_E_APAT)で構成されている。
ここでは、仮消去セルがSOBU境界を含まない場合(ERA_S_APAT/ERA_E_APATを)を想定している。
このプログラム#jの途中の一部(APAT=AからAPAT=Bまでの範囲)に対して仮消去が実行されると、オリジナル記録のセル#kは、セル#k(TEフラグが「00b」;開始時間はSC_S_APATk;終了時間はSC_E_APATk)と、セル#k+1(TEフラグが「10b」;開始時間はSC_S_APATk+1;終了時間はSC_E_APATk+1)と、セル#k+2(TEフラグが「00b」;開始時間はSC_S_APATk+2;終了時間はSC_E_APATk+2)に3分割される。
仮消去(TE)実行後、オリジナルセルを再編成すると、図31の中段に示すように、プログラム#jは再びTEフラグが「00b」のセル#k(開始時間はSC_S_APAT;終了時間はSC_E_APAT)となる。
ここで、仮消去(TE)動作はオリジナルPGC情報の内容には影響せず、ストリームファイル情報SFIの内容は変更されず残される。
一方、ユーザ定義PGC情報は、変更されないか、あるいはユーザ定義セルがTEセルを参照しないように修正できる。
仮消去の主な動作は、プログラム#j内で実行される。仮消去は、プログラム#jのセルを、通常のストリーム部(消去されていない部分)および仮消去部をカバーする部分に分割することで実行される。
ユーザ定義PGC情報の内容を変更せずにそのままにしておく場合は、TE動作の再構成後も、ナビゲーションデータは仮消去前の状態と全く変わらない。
情報記憶媒体201の未記録領域を使いきり記録スペースが不足すると、仮消去セル#k+1は完全消去される。すると、図31の下段に示すように、仮消去時のセル#kは完全消去後にも変更されずセル#kとなるが、仮消去時のセル#k+2は完全消去後にセル#k+1となる。
図32は、オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
ユーザ定義PGCは自身のSOBを含まないが、オリジナルPGC内のSOBを参照する。それゆえ、ユーザ定義PGCはPGC情報を用いることのみで記述できる。このことは、SOBデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
ユーザ定義PGCはまた、プログラムを含まず、オリジナルPGC内のプログラムの一部に対応したセルの連なり(チェーン)で構成される。
このようなユーザ定義PGCの一例が、図32に示されている。この例は、PGC内のセルがオリジナルPGC内のSOBを参照するようにユーザ定義PGC#nが作成されている場合を示す。
図32において、PGC#nは4つのセル#1〜#4を持っている。そのうち2つはSOB#1を参照し、残りの2つがSOB#2を参照している。
ユーザ定義PGC内のセルからオリジナルPGCへ(SOBIのタイムマップ情報へ)の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義PGC内のセル再生順序は、オリジナルPGCにおける再生順序と全く異なってもよい。
任意のSOBおよびそのSOBUの再生は、図32の開始APAT(S_APAT)および終了APAT(E_APAT)により特定される。
SOBあるいはSOBUのS_APATは、該当SOBのストリームパックのペイロード(図8(b)参照)内に記録されたタイムスタンプに関係して定義される。SOBの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間(APAT)である。
SOBの先頭アプリケーションパケットのAPATはSOB_S_APATとして記憶される。全てのAPATの4最下位バイト(4 least significant bytes)は、〜.SROファイル内の対応アプリケーションパケット用に予め固定されている。
SOBあるいはSOBUのデータを再生するために、ストリーマ内部のリファレンスクロックはSCR値にセットされ、その後クロックが自動的にカウントされる。このSCR値は、再生が始まる最初のストリームパック内(パックヘッダ内)に記述されている。このクロックに基づいて、SOBあるいはSOBUからの全ての後続アプリケーションパケットの再生・出力が、実行される。
任意のストリームセル(SC)が、そのSCがポイントするSOBのSOB_S_APATとSOB_E_APATとの間の任意の値を持つストリームセル開始APAT(SC_S_APAT)を規定しているときは、所望のAPATを伴うアプリケーションパケットを含んだSOBUを見つけるためのアドレスが必要となる。
SOBU1個あたりのストリームパックの数は一定であるが、各SOBUにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各SOBは、該当SOBのSOBUの到着時間間隔が記述されたタイムマップ情報(MAPL)を持つ。つまり、タイムマップ情報(MAPL)により実現されるアドレス方式は、任意のAPATをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるSOBUをポイントする。
図33は、各ストリームオブジェクト(SOB)を構成するSOBUの内容が、図3のデータエリア207(図1ではデータエリア21〜23)にどのように記録されるかを例示する図である。ここでは、SOBが記録されるときにSOBをどのようにアロケートするかを説明する。
情報記憶媒体(DVD−RAMディスク)201のフリースペースを有効活用するため、図33に示すように、媒体(ディスク)全体に分散したデータエリア内にSOBをアロケートすることができる。
このようなSOBを媒体(ディスク)から読み取るときは、あるデータエリアから次のデータエリアにジャンプする間、媒体(ディスク)からのデータ供給が中断する。このような場合でもSOBデータの連続供給を保証するためには、SOBデータのアロケーションは次のような条件で行なう。
すなわち、SOBは連続データエリア(以下適宜CDAと略記する)のチェーン内にアロケートする。CDAは基本的には媒体(ディスク)内の連続物理セクタのシーケンスとなる。
DCAの最小長およびCDA内のデータアロケーションは、各SOBを連続再生できるような再生装置モデルにより制限を受ける。
連続データエリア(CDA)は媒体(ディスク)内の連続物理セクタである。CDAは複数のECCブロックからなる。CDA内では、CDA内で幾つかの物理セクタが記録時にスキップするような場合を除き、SOBデータが連続的にアロケートされる。
SOBデータがCDA内に記録される際の制限としては、以下のものがある:
(21)SOBデータとその他のデータは、同じECCブロック内に記録しない;
(22)SOBデータの記録中に欠陥セクタに出くわしたとしても、交替処理(リニアリプレイスメント)は用いない。
ここで、複数アプリケーションパケットを含むあるSOBU内にセル開始APATがある場合の再生について、説明を補足しておく。
セルは、SOBU境界に一致しないセル開始APATあるいはセル終了APATを持つことができる。いま、2つの連続SOBU#K−1およびSOBU#kがあり、SOBU#k内の中間部分にセル開始APATがある場合を考えてみる。
上記セル開始APATにより特定されるアプリケーションパケットから一連のアプリケーションパケットの再生を開始する場合には、まず、目的のアプリケーションパケット(所望のAPATに対応)を含むSOBU#kにアクセスする必要がある。いきなり目的のアプリケーションパケットにアクセスしないのは、タイムマップ情報(MAPL)によるアドレス方式がSOBUの開始アドレスしか与えない場合を想定しているからである。
所望のAPATを見つけるためには、上記SOBU#k内の全てのアプリケーションパケットを初め(SOBU#k−1とSOBU#kとの境界)からスキャンしなければならない。このスキャンにより所望のAPATが見つかれば、見つかった位置から以後のアプリケーションパケットの再生出力が、それらのアプリケーションパケットのタイムスタンプ(ATS)にしたがって開始される。
以上説明したように、この発明の実施の形態における効果をまとめると、以下のようになる。
1.情報記憶媒体上に記録するストリームデータを所定サイズのストリームブロック単位(あるいはSOBU単位)で構成し、そのストリームブロック単位で記録・消去するため、ストリームブロック先頭位置のアドレス割り出しが非常に容易となり、再生時のアクセス制御がしやすくなる。(図14のS12に示すように再生時には、ストリームブロック先頭位置から再生を開始する。)
2.情報記憶媒体上に記録するストリームデータを所定サイズ(たとえば32セクタ64kバイト)のストリームブロックで構成し、同一ストリームブロック内ではタイムスタンプやデータパケット(トランスポートパケット)が異なるセクタを跨いで記録できるため、セクタサイズ(2048kバイト)よりも大きなサイズのデータパケット(トランスポートパケット)を記録することができる。
3.情報記憶媒体としてDVD−RAMディスクが用いられる場合には、16セクタ毎にECCブロックが構成され、そのECCブロック内ではデータのインターリーブ(並び替え)とエラー訂正用コードが付加されている。そのため、ECCブロック内の特定のセクタのみを消去し、あるいは書き換え、もしくは追記するためには、一度ECCブロック内の全データを読み取り(リード)、バッファメモリ内で再並び替え(デインターリーブ)を行った後、特定セクタ分のデータを消去あるいは書き換え、追記を行い(モディファイ)、再度インターリーブ(並び替え)とエラー訂正用コードを付加して記録する(リード・モディファイ・ライト)と言う処理が必要となる。この処理は非常に時間が掛かりストリームデータの記録や部分消去が実時間で行えないと言う問題がある。
それに対してストリームブロックサイズをECCブロックサイズの整数倍(たとえばSOBU=2ECCブロックサイズ)にして、ストリームブロック単位(SOBU単位)で記録、部分消去を行う。このため、リード・モディファイ・ライト処理が不要となり、直接ECCブロック単位で情報記憶媒体上に上書きが可能となる。その結果、ストリームデータの記録あるいは部分消去の処理が高速で行え、実時間処理(リアルタイム処理)が可能となる。
4.ストリームブロック毎に独自のヘッダ情報(ストリームブロックヘッダあるいはアプリケーションヘッダ)を持たせることにより、ストリームデータ再生時にはストリームブロック先頭位置から再生を開始することが可能となる。そのため、ストリームデータ記録再生装置(ストリーマ)では早い時期にストリームブロックヘッダを読み取ることで再生したストリームデータ処理を容易にすることができる。
5.上述したように基本的にストリームブロック先頭位置から再生を開始するが、希なケースとしてストリームブロック内の2番目以降のECCブロック先頭位置から再生を開始する場合があり得る。
図1において同一のトランスポートパケットdが2個のセクタ(セクタNo.0とセクタNo.1)に跨って記録されている例に示すように、2番目以降のECCブロック先頭位置から再生を開始した場合には、何処に次のタイムスタンプ情報が記録されているかを知る必要がある。
各セクタの先頭位置に独自のヘッダ情報(セクタデータヘッダあるいはアプリケーションヘッダ)を配置させ、その中にファーストアクセスポイント651(あるいは図12(c)のFIRST_AP_OFFSET)を記録することで、ストリームブロック内の2番目以降のECCブロックの先頭位置から再生開始を容易にすることができる。
6.図1(j)に示すように、ストリームブロック#2内に記録するストリームデータの最後にはエンドコード32が付けられている。しかし、情報記憶媒体からのデータ再生時にECCブロック毎のエラー訂正ミスあるいはストリームデータ記録再生装置内でのデータ転送エラーによりエンドコード32が読めない場合、パディングエリア38内にもストリームデータが記録されていると誤解釈されて間違った映像が表示される危険性がある。
図10のPESヘッダ601(あるいはストリームPESパケットヘッダ)のストリームID603(あるいはサブストリームID)を”10111110”にしてセクタNo.79をパディングパケット40とした場合には、パディングエリア38内にもストリームデータが記録されていると誤解釈されてデータ転送された場合でもエンコード部(ビデオエンコード部416、オーディオエンコード部417、SPエンコード部418)でパディングパケット40と理解され、読み飛ばしてくれる。
以上のようにパディングパケット40(あるいは図26(i)のスタッフィングパケット)を設定することで、エンドコード32が読めずにパディングエリア38を誤認識した場合でも間違った映像を表示する危険性を大幅に低下させることができる。
7.オリジナルセルで指定される領域範囲を、ストリームオブジェクトで指定される領域範囲と等しいか、それより小さくする。このように部分消去後の残存したストリームオブジェクト内の再生範囲を指定することで、ユーザは、見かけ上、任意の範囲を、精度良く、部分消去の範囲として設定できる。
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から1または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも1つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。