ストリームデータを記録する情報媒体、記録方法、再生方法、および再生装置
【課題】ストリームデータを効率よく記録する。
【解決手段】ストリームパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されるデータ領域と、前記ストリームデータに関する管理情報が記録される管理領域とを有する。ここで、前記Iピクチャ情報とこのIピクチャ情報に隣接する情報との境界は、前記ストリームデータのうちこの境界に該当する部分の開始時間情報(SOB_S_APAT)またはその終了時間情報(SOB_E_APAT)により示される。
【解決手段】ストリームパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されるデータ領域と、前記ストリームデータに関する管理情報が記録される管理領域とを有する。ここで、前記Iピクチャ情報とこのIピクチャ情報に隣接する情報との境界は、前記ストリームデータのうちこの境界に該当する部分の開始時間情報(SOB_S_APAT)またはその終了時間情報(SOB_E_APAT)により示される。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、デジタル放送などで伝送される映像データあるいはパケット構造をもって伝送されるストリームデータを記録する方法、この記録方法に適したストリームデータのデータ構造、およびこのデータ構造を用いて情報記録がなされる情報媒体に関する。
【背景技術】
【0002】
近年、TV放送はデジタル放送の時代に突入してきた。それに伴い、デジタルTV放送のデジタルデータをその内容を問わずデジタルデータのままで保存する装置、いわゆるストリーマが要望されるようになってきた。
【0003】
現在放送されているデジタルTV放送では、MPEGのトランスポートストリームが採用されている。今後も、動画を使用したデジタル放送の分野では、MPEGトランスポートストリームが標準的に用いられると考えられる。
【0004】
このデジタル放送では、放送される内容(主に映像情報)が、トランスポートパケットと呼ばれる所定サイズ(たとえば188バイト)毎のデータの纏まりに時間分割され、このトランスポートパケット毎に放送データが伝送される。
【0005】
このデジタル放送データを記録するストリーマとして、現在市販されているものとしては、D−VHS(デジタルVHS)などの家庭用デジタルVCRがある。このD−VHSを利用したストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、ビデオテープには、複数の番組が多重されて記録されることになる。
【0006】
再生時には、最初から再生する場合、あるいは途中から再生する場合にも、そのまま全てのデータが、VCRからセットトップボックス(デジタルTVの受信装置:以下STBと略記する)に送り出される。このSTBにおいて、ユーザ操作等により、送り出されたデータ内から所望の番組が選択される。選択された番組情報は、STBからデジタルTV受像機等に転送されて、再生(ビデオ+オーディオ等の再生)がなされる。
【0007】
このD−VHSストリーマでは、記録媒体にテープが用いられるため、素早いランダムアクセスが実現できず、所望の番組の希望位置に素早くジャンプして再生することが困難となる。
【0008】
このようなテープの欠点(ランダムアクセスの困難性)を解消できる有力な候補として、DVD−RAMなどの大容量ディスクメディアを利用したストリーマが考えられる(特許文献1の段落0001、0018等参照)。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性がでてくる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開平8−235832号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
情報記憶媒体としてDVD−RAMディスクを用いた場合には、2048バイト毎に纏められたセクタ単位でデータが記録される。一方、デジタルTV放送ではMPEGのトランスポートストリームが採用されており、映像情報が入ったストリームデータは、トランスポートストリームの最小単位として188バイトのトランスポートパケット毎に纏まって送信される。このトランスポートパケットのサイズはデジタルTV放送局により異なり、たとえば130バイト単位として送信するデジタルTV放送局もある。この受信したトランスポートパケットそのままをDVD−RAMディスクなどの情報記憶媒体にセクタ単位で記録した場合、以下のような問題が生じる。すなわち、
1.セクタサイズの2048バイトがトランスポートパケットサイズ(たとえば188バイト)の整数倍でないため、セクタ内へのトランスポートパケットの記録方法が問題となる。
【0011】
具体的には、あるセクタ内へトランスポートパケットを先頭から順次配置し、このセクタ内で生じた余りの端数分をパディングエリア扱いとした場合には、各セクタ毎に無駄なパディングエリアが多数発生する。このため、情報記憶媒体上に記録できるストリームデータ量が、セクタ毎のパディングエリアの分、減少する。その結果、情報記憶媒体の実質的な記録容量が少なくなる。
【0012】
2.MPEG規格に従って映像圧縮されているストリームデータは、情報記憶媒体から再生した後デコーダでデコードされる必要があるが、各トランスポートパケット毎のデコーダに転送される時間間隔はデジタルTV放送局から受信した直後の時間間隔を保持する必要がある。そのため、各トランスポートパケット毎のデコーダへ転送される時間間隔情報が必要となる。
【0013】
3.情報記憶媒体上に記録される各トランスポートパケットは、それぞれのトランスポートパケットを個々に識別する識別情報を持たないため、検索(サーチ)または編集時に特定のトランスポートパケットを指定する手段がない。
【0014】
4.情報記憶媒体としてDVD−RAMディスクを用いた場合には、2048バイト毎のセクタ単位で記録されるため、トランスポートパケット単位での部分的な消去処理が難しい。
【0015】
5.デジタルTV放送で送信するストリームデータは、MPEG規格に従って映像圧縮されているため、Iピクチャ位置からデコードを開始する必要がある。従って、特定の映像位置で部分消去する場合は、実質的にはその先頭にあるIピクチャ開始位置を境界位置として部分消去する必要がある。しかし、トランスポートパケットをセクタ内に順次記録しただけの情報では、Iピクチャ開始位置を上記境界位置とした部分消去処理は難しい。
【0016】
この発明は上記事情に鑑みなされたもので、その目的は、ストリームデータを効率よく記録できる記録方法を提供することである。
【0017】
この発明の他の目的は、ストリームデータを効率よく管理できるデータ構造を提供することである。
【課題を解決するための手段】
【0018】
この発明の一実施の形態に係る情報媒体は、ストリームパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されるデータ領域と、前記ストリームデータに関する管理情報が記録される管理領域とを有する。ここで、前記Iピクチャ情報とこのIピクチャ情報に隣接する情報との境界は、前記ストリームデータのうちこの境界に該当する部分の開始時間情報(SOB_S_APAT)またはその終了時間情報(SOB_E_APAT)により示すことができる。
【発明の効果】
【0019】
ストリームデータを効率よく記録できるようになる。
【図面の簡単な説明】
【0020】
【図1】図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。
【図2】この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。
【図3】この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【図4】この発明におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。
【図5】デジタル放送、IEEE1394、およびストリーマにおける映像データ転送形態の関係を説明する図である。
【図6】ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。
【図7】MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係を説明する図である。
【図8】図1その他で示されるタイムマップ情報の設定方法を説明する図である。
【図9】記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。
【図10】図5その他に示されるストリームパックのデータ構造を説明する図である。
【図11】この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。
【図12】図11のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。
【図13】ストリーマの管理情報(図2または図3のSTREAM.IFOに対応)の内部データ構造を説明する図である。
【図14】PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。
【図15】ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【図16】アクセスユニット開始マップ(AUSM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【図17】アクセスユニット開始マップ(AUSM)およびアクセスユニット終了マップ(AUEM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【図18】オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【図19】この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。
【発明を実施するための形態】
【0021】
以下、図面を参照してこの発明の一実施の形態に係るストリームデータの記録方法およびそのデータ構造などについて説明をする。
【0022】
図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。
【0023】
情報媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎あるいは一回の映像録画単位毎にストリームオブジェクトとして纏められて記録されている。
【0024】
図1(h)は、DVD−RAMディスク等の情報媒体上に記録されたストリームオブジェクトを例示している。ここでは、ストリームオブジェクト#A298の最後の部分と、それに続いて記録されているストリームオブジェクト#B299を示している。
【0025】
DVD−RAMディスク等にこのストリームデータを記録する場合には、図1(d)に示すように、2048kバイト毎のセクタを最小単位として記録される。各セクタ毎には、図1(c)(e)に示すように、パックヘッダ(あるいはパケットヘッダ)11〜15の記録領域とストリームデータを記録するデータエリアに分かれている。
【0026】
各データエリアには、図1(f)(g)に示すように、タイムスタンプおよびトランスポートパケットが逐次詰め込まれる。これは、以下のように行うことができる。すなわち、
1.タイムスタンプとトランスポートパケットをセクタ内のパックヘッダ11〜15以外の場所に順次めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録する。
【0027】
具体的には、図1(g)では、データエリアNo.1内にタイムスタンプとトランスポートパケットを順次詰め込むと、トランスポートパケット1kの所でデータエリアNo.1に入り切れず、トランスポートパケット1kの一部がデータエリアNo.1からはみ出してしまう。このトランスポートパケット1kの中で、データエリアNo.1からはみ出した部分を、次のセクタNo.2内のデータエリアNo.2の先頭位置に継続して記録する。
【0028】
2.ユーザ等が行う一回の映像録画の纏まり、もしくは1番組などの同一コンテンツの纏まりをストリームオブジェクトと定義する。そして、情報記憶媒体上に記録されたストリームオブジェクトの最後のトランスポートパケット位置がセクタの境界位置とは異なる場合には、該当するセクタ内に限りこの最後のトランスポートパケット位置以降をパディングエリアとする。
【0029】
具体的には、図1(k)の例では、トランスポートパケット321aで映像録画が終了し、ここがストリームオブジェクト#B299の実質的な最終位置になる。その際、このトランスポートパケット321aが図1(j)のデータエリアNo.321の途中に配置されている場合には、データエリアNo.321に限り、それ以降をパディングエリア21とする。
【0030】
以上のようなデータ構造を用いることにより、セクタサイズよりも大きなサイズを持つパケットを効率よく記録することができる。
【0031】
図1はまた、タイムマップ情報に関係したデータ構造も示している。以下、図1を用いてタイムマップ情報252内の各データの内容について説明する。
【0032】
図1(h)(i)に例示するように、ストリームオブジェクト(SOB)#B・299は複数のストリームブロック(SOBU)#α〜#γで構成されている。
【0033】
図1(h)(i)の例では、SOB#B・299を構成するストリームブロック(SOBU)#α〜#γ各々のデータサイズは2ECCブロックで構成され、32セクタ分のサイズを持っている。すなわち、タイムマップ情報252(図1(m))内の第1ストリームブロックサイズ261〜264(図1(l))は、それぞれ32セクタ(64kバイト)となる。
【0034】
SOB#B・299(図1(h))の先頭にあるストリームブロック(SOBU)#α(図1(i))はその先頭にセクタNo.1(図1(d))を持ち、セクタNo.1に含まれるデータエリアNo.1(図1(e)(f)(j))の先頭にはタイムスタンプ1a(図1(g)(k))が記録されている。
【0035】
また、SOB#B・299(図1(h))の後続ストリームブロック(SOBU)#β(図1(i))はデータエリアNo.33(図1(j))を持ち、データエリアNo.33にはタイムスタンプ33aを伴うトランスポートパケット33a(図1(k))が記録されている。
【0036】
図1(k)に示すように、ストリームブロック(SOBU)#αの最初のストリームデータ(トランスポートパケット1a)のタイムスタンプ値[0]はタイムスタンプ1aであり、次のストリームブロック(SOBU)#β内のストリームデータ(トランスポートパケット33a)のタイムスタンプ値[28]はタイムスタンプ33aとなっている。
【0037】
図1(l)の第1ストリームブロック時間差266の値[30]は、上記タイムスタンプ33aとタイムスタンプ1aとの差分値([28]−[0])を所定の有効桁数(ここでは有効1桁)で丸める(切り上げる)ことで与えられる([28]−[0]≒[30])。
【0038】
なお、図1(m)のタイムマップ情報252は、図15を参照して後述するストリームオブジェクト情報SOBI内のアクセスデータユニットAUDも含むものとして、取り扱かわれてもよい。このAUDに含まれる情報(アクセスユニット開始マップAUSM等)により、アクセスしたい情報(所望のIピクチャ情報など)を含むSOBUを特定できる。
【0039】
図1の表記方法では、ストリームオブジェクト#B299の先頭セクタのセクタ番号を1とし、順次セクタ番号を増加させている。セクタ番号とデータエリア番号は一致させ、それに合わせてタイムスタンプ番号とトランスポートパケット番号を設定している。すなわち33番目のセクタ内のデータエリア内に配置された最初のタイムスタンプとトランスポートパケットの組を”33a”とし、同一データエリア内の次の組を順次”33b”、”33c”、………と番号を設定する。ここで、トランスポートパケット32j、320kのように直前のデータエリアに入り切らずに次のデータエリアに跨ったタイムスタンプまたはトランスポートパケットの番号は、直前のデータエリア番号に合わせて表示している。また図1(k)の鍵括弧[]内はタイムスタンプの実際の値を例示している。
【0040】
図1(a)〜(c)に示すように、パックヘッダ(またはパケットヘッダ)11〜15内の情報において、セクタ内共通情報41としては、パックヘッダサイズ51、タイムスタンプサイズ52、トランスポートパケットサイズ53が記載されている。
【0041】
ここで、図1(d)のセクタNo.1の例を取れば、図1(b)の検索情報42の中でセクタ内の最初のタイムスタンプ値54とは、図1(k)のタイムスタンプ1a[=0]の値を意味する。また、検索情報42の中でセクタ内の最後のタイムスタンプ値55とは、タイムスタンプ1k(図示せず)の値を意味している。
【0042】
ところで、多くの辞書では各ページ毎に脚注もしくはヘッダ位置に該当ページ最初と最後の単語を記載して、検索を容易にしている。それと同様に、上記2個の情報(図1(a)に示す最初のタイムスタンプ値54と最後のタイムスタンプ値55)により、ストリームデータの検索を容易にしている。
【0043】
同一のタイムスタンプあるいはトランスポートパケットが隣接するセクタを跨いで配置され得るため、各セクタ毎に単独でアクセスした場合には、最初のタイムスタンプ位置情報が必要となる。図1(a)に示したファーストアクセスポイント56は、パケットヘッダ直後から数えた最初のタイムスタンプ位置までのビット数を意味している。しかし、この実施の形態ではそれに限らず、例えば最初のトランスポートパケット先頭位置までのビット数を(ファーストアクセスポイント56相当の)情報として持っても良い。
【0044】
この実施の形態では、ファーストアクセスポイント56の値としてデータエリアのサイズよりも大きな値を指定可能にすることで、セクタサイズよりも大きなサイズを有するパケットに対してもタイムスタンプ先頭位置を指定することができるようになっている。
【0045】
たとえば図1(d)〜(g)のデータ構造において、1個のパケットがセクタNo.1からセクタNo.2まで跨って記録され、そのパケットに対するタイムスタンプがNo.1のデータエリア内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタNo.2のデータエリア内のTビット目に配置されている場合を考える。
【0046】
この場合、セクタNo.1のファーストアクセスポイント56の値は”セクタNo.1のデータエリアサイズ+T”、セクタNo.2のファーストアクセスポイントの値は”T”となる。
【0047】
セクタNo.1のファーストアクセスポイント56の値としてセクタNo.1のデータエリアのサイズよりも大きな値に設定することにより、セクタNo.1内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が次以降のセクタに存在することが示される。
【0048】
セクタ単位での部分消去(図9参照)を行った場合には、次のセクタに跨らない実質的に有効なタイムスタンプとトランスポートパケットの組の最終位置情報57(図1(a))が必要となる。
【0049】
この実施の形態においては、完全な形で記録されている(他セクタへ跨って配置されない)タイムスタンプとトランスポートパケットの組数で記載されているが、それに限らず、例えば最終位置アドレスなどの情報を(最終位置情報57として)記録することも可能である。
【0050】
図1(a)(b)に示すように、箇々のトランスポートパケットに関するビットマップ情報43は、Iピクチャ位置フラグ58と、ピクチャ先頭位置フラグ59と、暗号情報60を含んでいる。図1(a)のIピクチャ位置フラグ58およびピクチャ先頭位置フラグ59の情報は、図5を参照して後述するランダムアクセスインジケータ303およびペイロードユニット開始インジケータ301の情報を利用して作成できる。また、暗号情報60には、コピープロテクトに利用される情報が適宜記録される。
【0051】
図1(b)のセクタ内共通情報41および検索情報42から、該当セクタ内のトランスポートパケット数が分かる。その各トランスポートパケット毎に配列順に1ビットずつ対応させ、条件に該当したトランスポートパケットに対して”1”のフラグを立てることができる。このフラグを立てた個々のトランスポートパケットに関するビットマップ情報43も、図1(b)(c)に示すように、パックヘッダ内に記録されている。
【0052】
デジタル放送では、映像情報はMPEG2の規格に従って圧縮された情報が転送されてくる。デジタル放送では図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb322のサイズが188バイト(または183バイト)の場合が多い。
【0053】
前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア内にはデジタル放送用のトランスポートパケットが10個前後記録できる。それに対してISDNなどのデジタル通信網では1パケットサイズが4096バイトもある大きなロングパケットが転送される場合がある。
【0054】
図1のデータ構造を採用すれば、デジタル放送などのように1個のデータエリア内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、1個のパケットを複数のデータエリアに連続して跨るように記録できる。デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック(図1(i)のSOBU)内に端数なく記録することができる。
【0055】
図2は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図2を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容(ファイル構造)について説明する。
【0056】
DVDーRAMディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、DVD_RTRディレクトリ(またはDVD_RTAV)102と言う名のサブディレクトリ101内に入っている。
【0057】
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とが格納される。
【0058】
また、データ本体(コンテンツ情報)として、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とが格納される。
【0059】
上記データファイル103を含むサブディレクトリ101の上位階層にあるルートディレクトリ100には、その他の情報を格納するサブディレクトリ110を設けることができる。このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットVIDEO_TS111、オーディオプログラムを収めたオーディオタイトルセットAUDIO_TS112、コンピュータデータ保存用のサブディレクトリ113等がある。
【0060】
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
【0061】
そのストリームデータそのものはSTREAM.VRO(またはSR_TRANS.SRO)106と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、STREAM.IFO(またはSR_MANGR.IFOとそのバックアップファイルSR_MANGR.BUP)105である。
【0062】
また、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である。
【0063】
図3は、この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【0064】
図3(a)の情報記憶媒体201の内周方向202の端部と外周方向203の端部とで挟まれた領域には、図3(b)に示すように、リードインエリア204と、ファイルシステム情報が記録されているボリューム&ファイル構造情報206と、データエリア207と、リードアウトエリア205が存在する。リードインエリア204はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア205は書替可能データゾーンで構成されている。データエリア207も書替可能データゾーンで構成されている。
【0065】
データエリア207内は、図3(c)に示すように、コンピュータデータとオーディオ&ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア208およびコンピュータデータエリア209の間に、オーディオ&ビデオデータエリア210が、挟まれる形態となっている。
【0066】
オーディオ&ビデオデータエリア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とが記録される。
【0067】
同じく図3(e)に示すように、ストリーム記録エリア222には、図2に示された、ストリーマのナビゲーションデータSTREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、トランスポートビットストリームデータSTREAM.VRO(SR_TRANS.VRO)106とが記録される。
【0068】
なお、図3(d)(e)では図示しないが、ストリーム記録エリア222には、図2に示したアプリケーション固有のナビゲーションデータSR_PRIVT,DAT/SR_PRIVT.BUP105aを記録することもできる。
【0069】
このSR_PRIVT,DAT105aは、ストリーマに接続(供給)された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
【0070】
ストリームデータに関する管理情報であるSTREAM.IFO(またはSR_MANGR.IFO)105は、図3(f)〜(i)に示すようなデータ構造を有している。
【0071】
すなわち、図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とで構成されている。
【0072】
図3(f)のストリームファイル情報テーブル(SFIT)232は、図3(g)に示すように、ストリームファイル情報テーブル情報(SFITI)241と、1以上のストリームオブジェクト情報(SOBI)#A・242、#B・243、………と、オリジナルPGC情報一般情報271と、1以上のオリジナルセル情報#1・272、#2・273、………とを含むことができるようになっている。
【0073】
図3(g)の各ストリームオブジェクト情報(たとえばSOBI#B・243)は、図3(h)に示すように、ストリームオブジェクト一般情報(SOBI_GI)251、タイムマップ情報252、その他を含むことができる。
【0074】
また、図3(g)の各オリジナルセル情報(たとえば#1・272;後述するが図14で示されるSCIに対応)は、図3(h)に示すように、セルタイプ281(後述するが図14で示されるC_TYに対応)と、セルID282と、該当セル開始時間(後述する図9(k)(l)、図14で示されるSC_S_APATに対応)283と、該当セル終了時間(後述する図9(k)(l)、図14で示されるSC_E_APATに対応)284と、エントリポイント情報(SC_EPI)285を含むことができる。
【0075】
エントリポイント情報(SC_EPI)285は、記録内容を部分的にスキップする道具として利用できる情報である。このエントリポイント情報(SC_EPI)285には、図14に示すように、プライマリテキスト情報(PRM_TXTI)の有無によって2つの形式(タイプAとタイプB)がある。
【0076】
ここで、エントリポイントとは、オリジナルPGCの場合はプログラム内に入る位置、またユーザ定義PGCの場合はプログラムの一部に入る位置を示すものである。各PGCは、自身のエントリポイントセットを持つことができる。これらのエントリポイントはセル情報(SCI)の一部として記録される。記録内容の再生時に記録内容の一部をスキップする場合に、これらのエントリポイントを用いることができる。
【0077】
全てのエントリポイントは、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間(APAT)により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図14のEP_APATにより示される。
【0078】
図3(g)のSOBI#Bに含まれる図3(h)のタイムマップ情報252は、図3(i)に示すように、ストリームブロック番号260、第1ストリームブロックサイズ261、第2ストリームブロックサイズ262、…と、第1ストリームブロック時間差266、第2ストリームブロック時間差267、…とを含むことができる。
【0079】
タイムマップ情報252を構成するストリームブロック時間差266の具体例については、図1(l)に示されている。タイムマップ情報252を構成する各ストリームブロック時間差の内容については、図8を参照して後述する。
【0080】
図4は、この発明の一実施の形態におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。以下、図4の例示を用いてSOBとPGCの関係を説明する。
【0081】
ストリームデータ(STREAM.VROまたはSR_TRANS.SRO)106内に記録されたストリームデータは、1個以上のECCブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等を行うことができる。このストリームデータは、記録する情報の内容毎(たとえばデジタル放送での番組毎)にストリームオブジェクトという纏まりを作る。
【0082】
STREAM.VRO(SR_TRANS.SRO)106内に記録されたストリームオブジェクト(SOB#A、SOB#B)毎の管理情報(オリジナルPGC情報233、ユーザ定義PGC情報テーブル234等)は、ナビゲーションデータSTREAM.IFO(SR_MANGR.IFO)105内に記録されている(図4の最下部および図3(e)(f)参照)。
【0083】
図4の各ストリームオブジェクト#A・298、#B・299毎の管理情報(STREAM.IFO105)は、図3(f)(g)に示したように、ストリームファイル情報テーブル(SFIT)232内のストリームオブジェクト情報(SOBI)#A・242、#B・243として記録されている。
【0084】
ストリームオブジェクト情報(SOBI)#A・242、(SOBI)#B・243それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報252を含んでいる。
【0085】
ストリームデータの再生時には、1個以上のセルの連続で構成されるプログラムチェーン(PGC)の情報(後述する図14のPGCI#iに対応)が利用される。このPGCを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
【0086】
PGCには、STREAM.VRO(SR_TRANS.SRO)106に記録された全ストリームデータを連続して再生することのできるオリジナルPGC290(図3(f)ではORG_PGCI・233)と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義PGC#a・293、#b・296(図3(f)ではUD_PGCIT・234の中身に対応)の2種類が存在する。
【0087】
オリジナルPGC290を構成するオリジナルセル#1・291、#2・292は、基本的にストリームオブジェクト#A・298、#B・299と一対一に対応して存在する。
【0088】
それに対して、ユーザ定義PGCを構成するユーザ定義セル#11・294、#12・295、#31・297は、1個のストリームオブジェクト#A・298または#B・299の範囲内では任意の位置を設定することができる。
【0089】
それぞれのセルの指定範囲は、開始時刻と終了時刻の時間指定により行うことができる。すなわち、部分消去あるいは編集がなされる前(ストリームデータの録画直後)のオリジナルセル#2・292の該当セルの開始時間283および該当セルの終了時間284(図3(h))の時間には、図1(k)の例に従えば、該当するストリームオブジェクト#B299内の最初のタイムスタンプ1aの値と最後のタイムスタンプ321aの値が使用される。
【0090】
それに対して、図4のユーザ定義セル#11・294での時間範囲指定は任意時刻を指定でき、指定されたトランスポートパケットに対応したタイムスタンプの値が、該当セルの開始時間および該当セルの終了時間の値に設定される。
【0091】
ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法としては、この実施の形態では
(1)各ストリームオブジェクトの記録開始位置からの累計記録データ量でアクセスする方法と;
(2)MPEG方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識してアクセスする方法と
の2通りが可能となっている。
【0092】
図1(g)から明らかなように全トランスポートパケットにはタイムスタンプ情報が付属記録されており、このタイムスタンプ情報を利用して各トランスポートパケットに対してアクセス可能となっている。
【0093】
情報記憶媒体としてDVD−RAMディスクを用いた場合には、それぞれ16セクタ毎にECCブロックが構成されている。そこで、この発明の実施の形態ではECCブロックの整数倍(例えば2倍)毎にストリームデータをグループ化し、各グループ毎の経過時間のテーブルを持つことで、上記(1)の「累計記録データ量でアクセスする」方法を可能にしている。上記(2)の「デコードタイミングを意識してアクセスする」方法については、図11の説明において詳述する。
【0094】
この発明の実施の形態では、各グループ毎の経過時間のテーブルをタイムマップ情報252としている。このタイムマップ情報252は、図3(g)(h)に示すように、それぞれのストリームオブジェクトに対応するストリームオブジェクト情報(#A・242;#B・243)の一部に記録されている。
【0095】
また、この発明の実施の形態では上記グループ(2ECCブロック毎にグループ化されたセクタ)をストリームブロック(あるいはSOBUというデータユニット)と呼ぶ(図4上段、あるいは図1(i)参照)。
【0096】
各ストリームブロック(SOBU)の先頭に配置されているセクタの開始位置には、タイムスタンプが配置されていない場合がある。この場合は、各ストリームブロック(SOBU)毎の経過時間の定義が難しい。
【0097】
その対応策としては、以下のものがある。
【0098】
A)各ストリームブロック毎の特定位置に配置されているタイムスタンプ値を、それぞれのストリームブロック固有時間とする。
【0099】
具体的には各ストリームブロック毎の最初に配置されている(しかも前のセクタから跨って記録されてない)タイムスタンプの値をそれぞれのストリームブロックの開始時刻とする。
【0100】
B)各ストリームブロック毎の固有時間(例えば開始時刻)間の差分時間を、各ストリームブロック毎の経過時間と定義する。
【0101】
C)上記経過時間(差分時間)情報をタイムマップ情報252に記録する。
【0102】
上記差分時間(経過時間)で表示する方がデータ量が少なくなるメリットがある。しかしこの発明の実施の形態ではそれに限らず、それぞれのストリームブロック固有時間をタイムマップ情報252に記録することも可能である。
【0103】
D)上記経過時間(差分時間)情報の丸め値をタイムマップ情報252に記録する。
【0104】
経過時間(差分時間)情報の計算結果を丸める(桁数の低い値を切り上げまたは四捨五入する)ことで桁数の低い値を省略し、この丸め値をタイムマップ情報252に記録することで、データサイズを少なくできる。
【0105】
E)部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つ。
【0106】
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図4のストリームブロック#μのように、2ECCブロック(32セクタ)で一定サイズ(64kバイト)のストリームオブジェクトユニット(SOBU)を、ストリームブロックとして採用するとよい。
【0107】
このようにストリームブロックを一定サイズ(たとえば2ECCブロック=32セクタ=64kバイト)のSOBUに固定すれば、次の利点が得られる:
(01)SOBU単位でストリームデータの消去あるいは書替を行っても、そのSOBUのECCブロックが、消去あるいは書替対象以外のSOBUのECCブロックに影響しない。そのため、消去あるいは書替に伴う(消去あるいは書替の対象でないSOBUに対する)ECCのデインターリーブ/インターリーブのやり直しが、生じない;
(02)任意のSOBU内部の記録情報に対するアクセス位置を、セクタ数(あるいはセクタ数に対応した他のパラメータ;たとえばストリームパックおよびその内部のアプリケーションパケット群の情報)で特定できる。たとえば、あるSOBU#k(図示せず)の中間位置にアクセスする場合は、SOBU#kー1とSOBU#kとの境界から16セクタ目(あるいは16セクタ目に対応するアプリケーションパケットの位置)を指定すればよい。
【0108】
図5は、デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
【0109】
デジタル放送では、MPEG2規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。デジタル放送では、図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb322のサイズが188バイト(または183バイト)の場合が多い。
【0110】
このトランスポートパケット内は、図5(b)に示すように、トランスポートパケットヘッダ311と、記録情報のデータ本体が記録されているペイロード312とで構成されている。
【0111】
トランスポートパケットヘッダ311は、図5(a)に示すように、ペイロードユニット開始インジケータ301、パケットID(PID)302、ランダムアクセスインジケータ303、プログラムクロックリファレンス504、再生タイムスタンプ(PTS)305等で構成されている。
【0112】
MPEG圧縮された映像情報は、Iピクチャ情報、Bピクチャ情報、およびPピクチャ情報を含んでいる。Iピクチャ情報が記録されている最初のトランスポートパケットには、図5(a)のランダムアクセスインジケータ303に”1”のフラグが立つ。また、各B、Pピクチャ情報の最初のトランスポートパケットには、図5(a)のペイロードユニット開始インジケータ301に”1”のフラグが立つ。
【0113】
これらのランダムアクセスインジケータ303およびペイロードユニット開始インジケータ301の情報を利用して、IピクチャマッピングテーブルおよびB、Pピクチャ開始位置マッピングテーブルの情報を作成することができる。
【0114】
たとえば、図5(a)に示したペイロードユニット開始インジケータ301に”1”のフラグが立ったトランスポートパケットに対して、B、Pピクチャ開始位置マッピングテーブル内の該当個所のビットが”1”になる。
【0115】
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図5(a)のパケットID(PID)302で識別される。このPID302の情報を用いて、ビデオパケットマッピングテーブルとオーディオパケットマッピングテーブルを作成することができる。
【0116】
図5(c)に示すように、デジタル放送では、1個のトランスポンダに複数の番組(この例では番組1〜番組3)がパケット化された形で時分割されて転送されてくる。たとえば、図5(b)のトランスポートパケットヘッダ311およびペイロード(記録情報)312の情報は、図5(c)に示される番組2のトランスポートパケットb322、トランスポートパケットe325により転送される。
【0117】
IEEE1394では、図5(e)(f)に示すように、各IEEEアイソクロナス・ヘッダ343、344は、アイソクロナスパケットヘッダ351およびコモン・アイソクロナスパケットヘッダ352を含む。このコモン・アイソクロナスパケットヘッダ352内には、フォーマット依存のリザーブ領域が設定されている。
【0118】
この発明の実施の形態では、図5(g)に示すように、コモン・アイソクロナスパケットヘッダ352内のフォーマット依存のリザーブ領域に、ソースID361と、データブロックサイズ情報362と、Iピクチャ開始位置フラグ363が格納される。このようにフォーマット依存のリザーブ領域にIピクチャ開始位置フラグ363を設定することで、ストリームデータをアイソクロナス・モードで転送する時に同時にリアルタイムでストリームデータ内のIピクチャ位置指定(すなわちIピクチャの開始位置に該当するトランスポートパケットの指定)も行えるようにしている。ここに、この実施の形態の大きな特徴がある。
【0119】
なお、図5(h)において、アプリケーションパケットエリアの末尾に番組2のトランスポートパケットbの前半部346が記録されるのではなく、このアプリケーションパケットエリアの末尾が余白となる場合もある。この場合は、アプリケーションパケットエリアの末尾は部分パケットではなく、予約バイト数のスタッフィングエリア(その先頭にタイムスタンプはない)となる。
【0120】
また、通常のパケットにはタイムスタンプが付いているが、図5(i)に示すように、部分パケットではタイムスタンプを省略することができる。
【0121】
このようにすると、2つの隣接ストリームパック(図5(j))の境界で分断された部分パケット(パケット1つあたり188バイトとすれば部分パケットのサイズは1〜187バイト;平均して100バイト弱)を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分(タイムスタンプ1つあたり例えば4バイト)、媒体201に対する記憶容量を増やすことができる。
【0122】
また、図5(i)の先頭部分パケットの直後にくるタイムスタンプの位置は、図1(a)のファーストアクセスポイント56、あるいは図10(c)のFIRST_AP_OFFSETにより、特定することができる。
【0123】
図6は、ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。
【0124】
図6(a)〜(d)は、図1(h)〜(k)に相当する内容を示している。図6の例では、全てのストリームブロック(SOBU)#α〜#γが一定サイズ(32セクタ/2ECCブロック=64kバイト)で構成されている。そのうち、ストリームブロック(SOBU)#γの最終セクタNo.n、およびその1つ手前のセクタNo.nー1(図6(e))を構成するパック構造が、図6(f)〜(j)に例示されている。
【0125】
ストリームブロック(SOBU)#γの各セクタは、最終セクタNo.nを除き、同様なデータ構造を持っている。たとえばセクタNo.nー1についていうと、図6(f)に示すようになっている。
【0126】
すなわち、セクタNo.nー1は2048バイト(2kバイト)のストリームパックにより構成される。このストリームパックは、14バイトのパックヘッダと、2034バイトのストリームPESパケットとで構成される。
【0127】
ストリームPESパケットは、6バイトのPESヘッダと、1バイトのサブストリームIDと、2027バイトのストリームデータエリアとで構成される。
【0128】
ストリームデータエリアは、9バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、アプリケーションパケットエリアとで構成される。
【0129】
図6(f)のアプリケーションパケットエリアは、図5(h)(i)に示したものと同様に構成できる(図5(h)(i)のパケットを図6ではアプリケーションパケットに読み替える)。
【0130】
アプリケーションパケットエリアは、各々が(図5(h)のスタッフィングエリアおよび図5(i)の部分パケットを除き)アプリケーションタイムスタンプ(ATS)を先頭に持つアプリケーションパケット群で構成される。たとえば188バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、10個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
【0131】
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ(たとえば2048バイト)を持つものとして扱うことができる。図6(f)のスタッフィングバイトは、ストリームパックを常に所定長(2048バイト)に保つために利用できる。
【0132】
ストリームブロック(SOBU)#γの最終セクタNo.nは、図6(g)〜(j)に示すようになっている。すなわち、図6(g)に示すように最終セクタNo.nはパックヘッダおよびパディングパケットにより構成される。このパディングパケットは、図6(h)に示すように、そのアプリケーションパケットエリアにパディングエリア21(図1(k)のパディングエリア21に対応)を含む。
【0133】
パディングエリア21内で最初のアプリケーションパケットエリア(先頭スタッフィングパケット)の場合は、図6(i)に示すように、アプリケーションタイムスタンプ(ATS)付きのスタッフィングパケット(実質的な記録内容を持たないゼロバイトデータ)で埋められる。もしパディングエリア21が複数セクタ分の長さを持つときは、パディングエリア21内で2番目以降のアプリケーションパケットエリア(後続スタッフィングパケット)は、図6(J)に示すように、ATSなしのスタッフィングパケット(ゼロバイトデータ)で埋められる。
【0134】
ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報(図3(h)の252;あるいは後述する図15のSOBI内MAPL)の回復(再生)を確実にするために、スタッフィングが必要になる。図6(i)(j)のスタッフィングパケットは、そのための概念的な単位として定義されている。
【0135】
このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。
【0136】
スタッフィングパケットには、以下の条件が付く:
*1または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する;
*1または複数のスタッフィングパケットは、1つの4バイトATSと、該当SOBUの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ(ATSの後に続く)とで構成される。いま、SOBU1個あたりのセクタ数をSOBU_SIZとしたときに、0≦n≦SOBU_SIZー1とすれば、スタッフィングパケットの全長は、「4+2014+n×2018」バイトとなる。
【0137】
スタッフィングパケットのATSは、次のように設定される:
*少なくとも1個のパックが実際のアプリケーションパケットデータを含んでいるSOBU内では、スタッフィングパケットのATSは、スタッフィングパケットに先行するアプリケーションパケットのATSに設定される;
*実際のアプリケーションパケットデータを含まないSOBU内では、スタッフィングパケットのATSはタイムマップ情報等の内容に応じて決定される。
【0138】
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される:
*パックヘッダのSCRは、先行パックのSCRに「2048×8ビット÷10.08Mbps」を加えたものとする;
*PESパケットヘッダおよびサブストリームIDは、他の全てのPESパケットに対するものと同じにする;
*アプリケーションヘッダ(図10(c)(d)参照)内において、AP_Ns=0、FIRST_AP_OFFSET=0、EXTENSION_HEADER_IFO=00b、SERVICE_ID=0(アプリケーションヘッダ内のその他のパラメータも0)とする。
【0139】
図7は、MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
【0140】
図7に示すように、デジタルTVでの放送信号情報にはMPEG2と呼ばれる信号圧縮方法が採用されている。MPEGによる信号圧縮方法では、TV表示用の各画面(ピクチャ)は時間差分情報を含まないIピクチャ501と時間差分情報を含むBピクチャ503、504およびPピクチャ502に分類される。
【0141】
Iピクチャは前後の画面(ピクチャ)情報の影響を受けることなく単体で存在し、1枚の画面(ピクチャ)に対してDCT変換後、量子化した情報がIピクチャ圧縮情報511となり、Iピクチャ情報521として記録される。Pピクチャ502はIピクチャ501に対する差分情報512のみがPピクチャ情報522として記録される。また、Bピクチャ503はIピクチャ501とPピクチャ502に対する差分情報513、514がBピクチャ情報523として記録され、Bピクチャ504はIピクチャ501とPピクチャ502に対する差分情報515、516がBピクチャ情報524として記録される。
【0142】
図7に示すように、Iピクチャ501の圧縮情報511はIピクチャ情報521としてトランスポートパケット1a、1b、…に記録され、Bピクチャの差分情報513、514はBピクチャ情報523としてトランスポートパケット33a、…に記録され、Bピクチャの差分情報515、516はBピクチャ情報524としてトランスポートパケット41d、…に記録され、Pピクチャ差分情報512はPピクチャ情報522としてトランスポートパケット(TP)48h〜298gに記録される。このように各I、B、Pピクチャ情報は異なるトランスポートパケットに記録されている。
【0143】
映像再生時には、Pピクチャ502あるいはBピクチャ503、504単体では画面を生成することができず、必ずIピクチャ501画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報521〜524は1個または複数のトランスポートパケット内のペイロードに分割記録されている。このとき、各ピクチャ情報521〜524の境界位置とトランスポートパケット間の境界位置は、図7に示されるように、常に一致するように記録される。
【0144】
Iピクチャ情報521が記録されている最初のトランスポートパケット1aには、そのランダムアクセスインジケータ303(図5(a))に”1”のフラグが立つ。また、各B、Pピクチャ情報523、524、522の最初のトランスポートパケット33a、41d、48hには、そのペイロードユニット開始インジケータ301(図5(a))に”1”のフラグが立つ。このランダムアクセスインジケータ303とペイロードユニット開始インジケータ301の情報を利用して、図1(a)のIピクチャ位置フラグ58とピクチャ先頭位置フラグ59の情報が作成される。同様に、個々のトランスポートパケットに関するビットマップ情報43(図5(b))としてコピープロテクトに利用する暗号情報60などの情報も記録される。
【0145】
図7のIピクチャ(501)の位置情報(Iピクチャ位置情報)は、図3(g)(h)に示すようにオリジナルセル情報(SCI)(#1・272等)内にエントリポイント情報(SC_EPI)285として記録されている。
【0146】
エントリポイント情報285内のデータ構造は、図7(a)(b)に示すように、同一ストリームオブジェクト内に存在する個々のIピクチャ位置情報を示すエントリポイント位置(第1エントリポイント位置(EP_APAT)531、第2エントリポイント位置532、第3エントリポイント位置533、…、最終エントリポイント位置535)の情報の羅列記載形式になっている。
【0147】
またエントリポイント位置(EP_APAT)531の情報内容としては、図7(a)に示すように、Iピクチャ情報521の最初の情報が記録されているトランスポートパケット1aに対応したタイムスタンプ1aの値が記録されている。個々のエントリポイント位置(EP_APAT)532、533、535の情報内容も、同様に、それぞれの対応Iピクチャ情報の最初の情報が記録されているトランスポートパケットに対応したタイムスタンプ87f、183d、298gの値が記録される。
【0148】
図4に示した例えばユーザ定義セル#11・294に対する該当セルの開始時間および/または該当セルの終了時間の情報は、図3(f)のユーザ定義PGC情報テーブル234内に記録されている。この場合に、図7のBピクチャ情報524から再生したい場合には、該当セルの開始時間としてタイムスタンプ41dを設定することができる。このように、該当セルの開始時間あるいは該当セルの終了時間の情報は、Iピクチャ位置に関わりなく任意のタイムスタンプ情報で設定できる。
【0149】
一方、この実施の形態におけるストリームオブジェクトの開始/終了時刻は、Iピクチャ位置を意識して設定される。すなわち、図3(h)および図7(d)に示したストリームオブジェクト一般情報251の情報内容としては、図7(c)に示すように、録画開始時間を示す記録時間(SOB_REC_TM)541と、ストリームオブジェクト開始時間(SOB_S_APAT)542と、ストリームオブジェクト終了時間(SOB_E_APAT)543が記録されている。
【0150】
このストリームオブジェクト開始時間(SOB_S_APAT)542は、必ず、Iピクチャ情報521の先頭が記録されているトランスポートパケット1aに対応したタイムスタンプ1aの値に設定される必要がある。同様に、ストリームオブジェクト終了時間(SOB_E_APAT)543は、Iピクチャ情報の直前のトランスポートパケット298gに対応したタイムスタンプ298gの値に設定される必要がある。
【0151】
図7のトランスポートパケットがストリーマ(後述する図11の光ディスク装置415)に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ(ATS)というタイムスタンプ付きのパケット(アプリケーションパケット)に移し替えられる。
【0152】
そして、ATS付きアプリケーションパケットの一群(通常10パケット前後)がストリームPESパケット内のアプリケーションパケットエリアに格納される。
【0153】
このストリームPESパケットにパックヘッダを付したものが、1つのストリームパックになる。ストリームPESパケットは、PESヘッダと、サブストリームIDと、アプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、上記ATS付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで構成される。
【0154】
図8は、図1その他で示されるタイムマップ情報252の設定方法を説明する図である。
【0155】
図1(g)あるいは図8(b)に示したようにタイムスタンプ(TMS)およびトランスポートパケット(TP)(またはアプリケーションパケットAP)を順次詰めて記録してあるストリームデータに対して、図8(a)のように例えば2ECCブロック(32セクタ)毎に区切って、ストリームブロック(SOBU)#α、#β、#γ、〜#λを構成する。
【0156】
ストリームブロック(SOBU)#αの先頭位置には、タイムスタンプ(TMS)1aが配置されている。このタイムスタンプ1aは、SOBU#αの先頭パケットの到着時間(SOBU_S_APAT)を示している。このタイムスタンプ1aの値[0]が、SOBU#αの開始時刻になる。
【0157】
他のストリームブロック(SOBU#β〜SOBU#λ)に対しては、前のセクタから跨って記録されないという条件の下で、最初に配置されたタイムスタンプ33a、65a、98a、…321aの値([28]、[63]、[98]、[297])が、各ストリームブロック(SOBU#β〜SOBU#λ)の開始時刻とされる。
【0158】
各ストリームブロック、たとえば最後のSOBU#λの、最終パケットの直前にある最後のタイムスタンプ300aは、SOBU#λの最終パケットの到着時間(SOBU_E_APAT)を示している。このタイムスタンプ300aの値[300]が、SOBU#λの終了時刻になる。
【0159】
なお、最後のSOBU#λの末尾に余白が生じるときは、この余白は実データのないパディングエリア21(図1(k)あるいは図6(h)〜(j)参照)とされる。
【0160】
図8(b)に示すように、各ストリームブロック(SOBU#α〜SOBU#λ)それぞれの開始時刻を、0、28、63、98、…297とする。これらの時刻は、(a)秒単位、(b)フィールドあるいはフレーム/ピクチャ数(例えばNTSCでは30ピクチャ/秒、60フィールド/秒、PALでは25ピクチャ/秒、50フィールド/秒)、および(c)27MHzあるいは90kHzの基準クロックによるカウント数のうちの、いずれかで表示できる。
【0161】
図8(a)(b)の例示では、最初のストリームブロック(SOBU#α)の経過時間は[28]−[0]=[28](有効数2桁)であるが、この経過時間の表現はもっと粗くても実用性は損なわれないので、この経過時間値[28]の
1桁目を丸め(切り上げ)て、[30]としている。
【0162】
2番目のストリームブロック(SOBU#β)の経過時間は、上記丸め計算結果[30]を用いると[63]−[30]となるが、同様に1桁目を丸め(切り上げ)て[40]とする。以下同様に後続ストリームブロック(SOBU#γ〜SOBU#λ)の経過時間は有効数1桁に丸めた(切り上げた)数値で表現される。
【0163】
なお、ストリームブロック(SOBU#λ)以降へはアクセスしないので、図8(c)のように、最後のストリームブロックに対する時間差値をあえてブランクにしている。
【0164】
以上の丸め計算の結果とタイムマップ情報252との関係は、図8(c)に示されている。
【0165】
ところで、ストリームブロック(SOBU#λ)以降のストリームブロックは存在しないので、他のストリームブロックと同様な差分時間計算は行えない。そこで、この実施の形態では、最後のストリームブロック(SOBU#λ)だけは、その中で最後に記録されたタイムスタンプの値(図8(b)の例ではタイムスタンプ300aの値[300])と最後のストリームブロック(SOBU#λ)内で最初に記録されたタイムスタンプの値(図8(b)の例ではタイムスタンプ321aの値[297])との間の差分を計算し、切り上げした値を時間差値に設定する方法も可能にしている。これを図8(d)に示す。
【0166】
なお、図8(d)の最後のSOBU#λの時間差値計算方法は、2つの考え方が可能である。第1は、最後のタイムスタンプ300a(SOBU#λのSOBU_E_APAT)の丸める前の値[300]と最初のタイムスタンプ321aの丸める前の値[297]を用い、その差分結果[3]を切り上げ丸めして時間差値[10]を求める方法である。第2は、最後のタイムスタンプ300aの丸め値[300]と最初のタイムスタンプ321aの丸め値[300]を用い、その差分結果[0]に丸め誤差分[10]を加えて時間差値[10]を求める方法である。
【0167】
第2の方法では、全ての数値の末尾1桁にある「0」を取り除いた有効桁数1で数値を纏め、丸め誤差分を[1]とし、その他の数値の末尾1桁をそれぞれ削除して考えることもできる。
【0168】
図9は、記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。
【0169】
前述した一連の情報記載方法は、部分消去されたストリームオブジェクトに対しても適応できる。図9(k)は部分消去前の状態であり、録画直後のストリームオブジェクト(図1(h)その他のSOB#B・299)に関するストリームデータ構造およびオリジナルセル範囲、ストリームオブジェクト範囲は、図9(a)〜(e)に示すようになっている。
【0170】
以下、実表示範囲としてタイムスタンプ97cからタイムスタンプ224kまでの範囲を除いて、その範囲の前後を部分消去した後の処理を説明する。
【0171】
この実施の形態においては、セクタ単位で部分消去が行なわれる。しかし部分消去後のストリームオブジェクトの再生を行った直後に別のストリームオブジェクトの再生を行い、しかもそれらのストリームオブジェクトの繋ぎ目で画面の乱れを生じさせることなくシームレス再生を可能にするには、MPEGビットストリームのGOP境界位置を保持したまま部分削除を行う必要がある。
【0172】
タイムスタンプ97cに対応したトランスポートパケット97cの直前のIピクチャ先頭位置が図7(a)の第2エントリポイント位置532に示すようにトランスポートパケット87fに存在するとする。この場合、トランスポートパケット87fを含むセクタNo.87を残し、その前のセクタ以前の全セクタを部分消去し、このタイムスタンプ87fの値を部分消去後のストリームオブジェクトのストリームオブジェクト開始時間(SOB_S_APAT)542とする(図9(l)参照)。
【0173】
その結果、たとえば元には32セクタあったストリームブロック#γのサイズが30セクタに減少する。
【0174】
同時に、それに対応してタイムマップ情報252内に記載されるストリームブロック時間差の値も、たとえば40から30へと減少する。ストリームブロック#δ〜#ηの境界位置は部分消去前後で不変に保たれるので、その部分に関係したタイムマップ情報252内情報は変化しない。
【0175】
図7では省略したがIピクチャ先頭位置がトランスポートパケット225eから始まるとすれば、トランスポートパケット225dを含む図9(i)のセクタNo.225まで残し、それ以降の全セクタを消去する。
【0176】
図9(j)のストリームオブジェクト終了時間(SOB_E_APAT)543は、上記トランスポートパケット225dのタイムスタンプ225dにより設定できる。
【0177】
部分消去後の該当セルの開始時間(SC_S_APAT)283/終了時間(SC_E_APAT)284は、図9(i)に示すように、部分消去の実指定範囲に合わせて、タイムスタンプ97c、タイムスタンプ224kとされる。
【0178】
このような方法でタイムマップ情報(あるいはストリームオブジェクト情報SOBI/オリジナルセル情報SCI)が作成される所にこの実施の形態の特徴がある。
【0179】
なお、部分消去前後で開始時間および/または終了時間は変化するが、SOBUサイズは不変(たとえば32セクタ分64kバイト一定)に保たれる。
【0180】
部分消去時はSOBU単位の消去を行なうことも可能であり、この場合は、オリジナルセル内で最初の(または最後の)タイムスタンプTMSは、必ず、SOB内最初の(または最後の)SOBU内に含まれるようになる。
【0181】
図10は、図5その他に示されるストリームパックのデータ構造を説明する図である。
【0182】
各ストリームパックは、図10(d)に示すようなデータ構造を持っている。すなわち、14バイトのパックヘッダ11と、6バイトのPESヘッダ601と、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、必要に応じて用いられるオプションのアプリケーションヘッダエクステンションと、必要に応じて用いられるオプションのスタッフィングバイトと、アプリケーションタイムスタンプATSが付されたアプリケーションパケットを1以上含むアプリケーションパケット群とで、1つのストリームパックが構成される(図6(f)参照)。
【0183】
パックヘッダ11は、図10(g)に示すように、パック開始コードの情報、システムクロックリファレンス(SCR)ベースの情報、SCRエクステンションの情報、プログラム多重化レートの情報、パックスタッフィング長の情報等を含んでいる。SCRベースは32ビットで構成され、その32ビット目はゼロとされる。また、プログラム多重化レートとしては、たとえば10.08Mbpsが採用される。
【0184】
PESヘッダは、図8(f)に示すように、パケット開始コードプリフィックスの情報、ストリームID(プライベートストリーム2)の情報、PESパケット長の情報を含んでいる。
【0185】
また、サブストリームIDは、図8(f)に示すように、ストリーム記録データを特定する内容を持つ。具体的には、サブストリームID=”00000010b”によって、そのストリームパックに格納されたデータがストリーム記録データであることが示される。このストリームIDが”10111110b”のときは、そのストリームパックがパディングパケット(図6(g)参照)に用いられるものであることが示される。
【0186】
図10(d)のアプリケーションヘッダは、図10(c)に示すように、バージョン情報、アプリケーションパケット数AP_Ns、先頭アプリケーションパケットのタイムスタンプ位置FIRST_AP_OFFSET、エクステンションヘッダ情報EXTENSION_HEADER_IFO、サービスID等を含んでいる。
【0187】
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
【0188】
アプリケーションヘッダのAP_Nsは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にATSの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
【0189】
FIRST_AP_OFFSETには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、FIRST_AP_OFFSETには「0」が記述される。
【0190】
EXTENSION_HEADER_INFOには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かが、記述される。
【0191】
EXTENSION_HEADER_INFOの内容が00bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
【0192】
EXTENSION_HEADER_INFOの内容が10bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
【0193】
EXTENSION_HEADER_INFOの内容が11bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
【0194】
EXTENSION_HEADER_INFOの内容が01bとなることは禁止されている。
【0195】
アプリケーションパケットエリアの前のスタッフィングバイト(オプション)は、「EXTENSION_HEADER_INFO=11b」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
【0196】
SERVICE_IDには、ストリームを生成するサービスのIDが記述される。このサービスが未知のものであれば、SERVICE_IDに0x0000が記述される。
【0197】
図10(c)のFIRST_AP_OFFSETは、図10(b)あるいは図1(a)のファーストアクセスポイント56に相当する。このファーストアクセスポイント56は、図10(a)に示すように、パックヘッダ(またはアプリケーションヘッダ)内の検索情報42(図1(b)参照)内に格納される。
【0198】
図10(d)のスタッフィングバイトおよびアプリケーションパケット群は、図6(f)で示したように、アプリケーションパケットエリアを構成している。このアプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録される。その後に、アプリケーションタイムスタンプATSとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録される。そして、図5(h)で示したように、アプリケーションパケットエリアの末尾に、部分アプリケーションパケット(または予約バイトのスタッフィングエリア)が記録される。
【0199】
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在でき、アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
【0200】
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ(ATS)は、32ビット(4バイト)で構成される。このATSは、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0201】
図10(d)において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを(前述したEXTENSION_HEADER_INFOにおいて)記述できるように定義されいる。
【0202】
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
【0203】
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。
【0204】
図1(g)に示した2つのトランスポートパケット1k、あるいは図5(h)(i)に示した部分アプリケーションパケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
【0205】
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
【0206】
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
【0207】
アプリケーションヘッダエクステンション(オプション)はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する1バイト長の1エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
【0208】
なお、1バイトのアプリケーションヘッダエクステンション(オプション)には、図10(e)に示すように、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが記述される。
【0209】
AU_STARTが”1”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0210】
図10のパケット構造は、該当ストリームオブジェクト(SOB)の最終セクタ以外に適用できるが、その最終セクタには必ずしも適用されない。最終セクタに対しては、図6(i)(j)のパケット構造が適用される。
【0211】
図11は、この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。この実施の形態では、情報記憶媒体201として、DVD−RAMディスクのような記録/再生可能光ディスクを想定している。
【0212】
以下、図11を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。
【0213】
このストリームデータ記録再生装置は、光ディスク装置415、STB装置416およびその周辺機器から構成される。
【0214】
周辺機器としては、ビデオミキシング部405、フレームメモリ部406、外部スピーカ433、パーソナルコンピュータ(PC)435、モニタTV437、D/Aコンバータ432、436、I/F部431、434等がある。
【0215】
光ディスク装置415は、ディスクドライブを含む記録再生部409と、記録再生部409へのストリームデータ(あるいは記録再生部409からのストリームデータ)を処理するデータプロセサ部(以下D−PRO部と略記する)410と、D−PRO部410からオーバーフローしてきたストリームデータを一時記憶する一時記憶部411と、記録再生部409およびD−PRO部410の動作を制御する光ディスク装置制御部412とを備えている。
【0216】
光ディスク装置415はさらに、STB装置416からIEEE1394等を介して送られてきたストリームデータを受ける(あるいはIEEE1394等を介してSTB装置416へストリームデータを送る)データ転送インターフェース部414と、データ転送インターフェース部414で受けたストリームデータを情報記憶媒体(RAMディスク)201に記録する信号形式に変換する(あるいは媒体201から再生されたストリームデータをIEEE1394等の信号形式に変換する)フォーマッタ/デフォーマッタ部413とを備えている。
【0217】
データ転送インターフェース部414のIEEE1394受信側は、基準クロック発生器(システムタイムカウンタSTC)440のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。
【0218】
上記時間情報に基づいて、ストリームデータをストリームブロック毎(あるいはSOBU毎)に切り分ける区切り情報が作成されるとともに、この区切り情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはPGCの切り分け情報が作成される。
【0219】
フォーマッタ/デフォーマッタ部413は、STB装置416から送られてきたストリームデータをストリームパックの列(図5(j)等参照)に変換し、変換されたストリームパック列をD−PRO部410へ入力する。入力されたストリームパックは、セクタと同じ2048バイトの一定サイズを持っている。D−PRO部410は、入力されたストリームパックを16セクタ毎にまとめてECCブロックにして、記録再生部409へ送る。
【0220】
ここで、記録再生部409において媒体201への記録準備ができていない場合には、D−PRO部410は、記録データを一時記憶部411に転送して一時保存し、記録再生部409においてデータ記録準備ができるまで待つ。
【0221】
記録再生部409において記録準備ができた段階で、D−PRO部410は、一時記憶部411に保存されたデータを記録再生部409に転送する。これにより、媒体201への記録が開始される。一時記憶部411に保存されたデータの記録が済むと、その続きのデータはフォーマッタ/デフォーマッタ部413からD−PRO部410へシームレスに転送されるようになっている。ここで、一時記憶部411は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
【0222】
なお、フォーマッタ/デフォーマッタ部413を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器(STC)440から得ることができる。また、フォーマッタ/デフォーマッタ部413を介して再生ビットストリームから取り出されたタイムスタンプ情報(SCR)は、STC440にセットすることができる。
【0223】
情報記憶媒体201に記録されたストリームデータ内のパックヘッダには、基準クロック(システムクロックリファレンスSCR)が記録されている。この媒体201に記録されたストリームデータ(SOBまたはSOBU)を再生する場合において、基準クロック発生器(STC)440は、媒体201から再生された基準クロック(SCR)に適合される(SCRの値がSTC440にセットされる)。
【0224】
つまり、SOBあるいはSOBUのデータを再生するために、ストリーマ(光ディスク装置415)内の基準クロック(STC440)を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスSCRに合わせる。その後は、STC440のカウントアップが自動的に行われる。
【0225】
STB部416は、衛星アンテナ421で受信したデジタル放送電波の内容を復調し、1以上の番組が多重化された復調データ(ストリームデータ)を提供するデモジュレータ422と、デモジュレータ422で復調されたデータから(ユーザが希望する)特定番組の情報(図5を例に採れば、番組2のトランスポートパケット)を選択する受信情報セレクタ部423とを備えている。
【0226】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を情報記憶媒体201に記録する場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部420を介して、IEEE1394転送により、光ディスク装置415のデータ転送インターフェイス部414に送る。
【0227】
光ディスク装置415内のデータ転送インターフェイス部414では、IEEE1394で転送されてきたストリームデータが図5(d)の形に一旦戻され、図5(d)の形のタイムスタンプとトランスポートパケットの組が、情報記憶媒体201上に順次詰めて記録される。
【0228】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を記録することなく単に視聴するだけの場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部402の多重化情報分離部425に送る。
【0229】
一方、情報記憶媒体201に記録された番組を再生する場合、IEEE1394のシリアルバスを介して光ディスク装置415からSTB装置416に送られてきたストリームデータは、セレクタ部423を介してデコーダ部402の多重化情報分離部425に送られる。
【0230】
多重化情報分離部425は、セレクタ部423から送られてきたストリームデータに含まれる各種パケット(ビデオパケット、オーディオパケット、サブピクチャパケット)を、内部メモリ部426上で、各パケットのIDにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部(ビデオデコード部428、サブピクチャデコード部429、オーディオデコード部430に分配する。
【0231】
ビデオデコード部428は、多重化情報分離部425から送られてきた(MPEGエンコードされた)ビデオパケットをデコードして、動画データを生成する。その際、MPEGビデオデータ中のIピクチャから記録内容を代表する縮小画像(サムネールピクチャ)を生成する機能を持たせるために、ビデオデコード部428は、代表画像(サムネール)生成部439を内蔵している。
【0232】
ビデオデコード部428でデコードされた動画(および/または生成部439で生成された代表画像)と、サブピクチャデコード部429でデコードされたサブピクチャ(字幕、メニュー等の情報)と、オーディオデコード部430でデコードされた音声とは、ビデオプロセサ部438を介してビデオミキシング部405へ送出される。
【0233】
ビデオミキシング部405は、フレームメモリ部406を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、D/A変換器436を介してアナログ映像化され、モニタTV437に送られる。
【0234】
また、ビデオミキシング部405からのデジタル映像は、I/F部434およびIEEE194等の信号ラインを介して、パーソナルコンピュータ435等に取り込むことができるようになっている。
【0235】
一方、オーディオデコード部430でデコードされたデジタルオーディオ情報は、D/A変換器432および図示しないオーディオアンプを介して、外部スピーカ433に送られる。また、デコードされたオーディオ情報は、I/F部431を介して外部にデジタル出力される。
【0236】
なお、STB装置416内の動作タイミングは、システムタイムカウンタ(STC)部424からのクロックにより決定される。
【0237】
上述したSTB制御部404による指示等(STB装置416の内部構成各々の動作制御)は、プログラムメモリ部404aに格納された制御プログラムにより実行される。その際、STB制御部404による制御過程においてワークメモリ部407が適宜利用される。
【0238】
このSTB制御部404およびデコーダ部402を含めSTB装置416の内部動作のタイミングは、STC部424からのクロックで規制できる。また、光ディスク装置415のSTC440とSTB装置416のSTC部424を同期させることで、光ディスク装置415およびSTB装置416を含めたストリーマシステム全体の動作タイミングを規制できる。
【0239】
STC440とSTC部424を同期させる方法としては、データ転送インターフェース部414とデータ転送インターフェース部420との間で受け渡されるストリームデータ中の基準クロック(SCR)により、STC440およびSTC部424をセットする方法がある。
【0240】
図11の光ディスク装置415(ストリーマ)では、タイムスタンプとトランスポートパケットとの組(図5(h)(i))がそのままの形で情報記憶媒体201上に記録される。
【0241】
ユーザが例えば図5(c)の第2の番組を情報記憶媒体(図3(a)の201)に記録しようとする場合には、図11に示すSTB装置416内の受信情報セレクタ部423において、番組2のトランスポートパケットb、eのみが抽出される。そのとき、STB装置416では、図5(d)に示すように、各トランスポートパケットb522、e525を受信した時刻情報がタイムスタンプ331、332の形で付加される。
【0242】
その後、IEEE1394の転送方式を用いて図11のフォーマッタ/デフォーマッタ部413にデータを転送する場合には、図5(e)に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。
【0243】
図11のフォーマッタ/デフォーマッタ部413では、STB装置416からIEEE1394で転送されてきたストリームデータが、図5(d)の形(図1(g)の形に相当)に一旦戻される。そして、図5(d)の形式のビットストリーム(図5(j)のストリームパック列)が、情報記憶媒体201に記録される。具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとPESヘッダが配置される(図5(j)等参照)。
【0244】
データエリア(図1(f))には複数のタイムスタンプおよびトランスポートパケット(図1(g))が逐次詰め込まれるが、1個のトランスポートパケット(図1(g)ではパケット1k;図5(d)では番組2のパケットb)が複数のセクタ(図1(e)ではNo.1とNo.2;図5(h)(i)では部分パケット)に跨って記録されことも可能になっている。ここに特徴の1つがある。
【0245】
この特徴を生かしたデータ構造を用いることにより、セクタサイズ(例えば2048バイト)よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
【0246】
デジタル放送では図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb・522のサイズが188バイト(または183バイト)の場合が多い。前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア(図1(f))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。
【0247】
デジタル放送などのように1個のデータエリア(図1(f))内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリアに連続して跨るように記録する。そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
【0248】
図11の装置構成を機能別にみると、STB装置416内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割/分類できる。
【0249】
ここで、「受信時刻管理部」は、デモジュレータ(復調部)422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等で構成される。この「受信時刻管理部」は、衛星アンテナ421でデジタルTV放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。
【0250】
「ストリームデータ内容解析部」は、多重化情報分離部425、STB制御部404等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、I,B,Pの各ピクチャ位置および/またはPTS値を抽出する。
【0251】
「ストリームデータ転送部」は、多重化情報分離部425、受信情報セレクタ部423、STB制御部404、データ転送インターフェース部420等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置415へ転送する。
【0252】
「時間関連情報生成部」は、多重化情報分離部425、STB制御部404、データ転送インターフェース部420等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻(タイムスタンプ)情報と「ストリームデータ内容解析部」で抽出した表示時刻情報(PTS値および/またはフィールド数)との間の関係情報を作成する。
【0253】
次に、図11の装置におけるストリームデータ録画時の処理について説明する。図5(c)に示すように、デジタル放送では1個のトランスポンダ内に複数番組情報が時分割多重化されている。その情報に対して受信情報セレクター部423内で図5(d)に示すように特定番組のみのトランスポートパケットを抽出する。
【0254】
前記「受信時刻管理部」では、必要な番組情報を多重化情報分離部425内のメモリ部426内に一時保管すると同時に各トランスポートパケット毎の受信時刻を測定し、その値を図5(d)のようにタイムスタンプとして各トランスポートパケット毎に付加する。この付加したタイムスタンプ情報はメモリ部426内に記録される。
【0255】
前記「ストリームデータ内容解析部」では、メモリ部426内に記録されたトランスポートパケット内の情報が解析される。具体的には、トランスポートパケット列から、各ピクチャ境界位置の切り出しと、再生タイムスタンプ(PTS)情報の抽出が行なわれる。各ピクチャ境界位置の切り出し方法は前述したように2通り存在し、ストリームデータ内容に応じて選択する。同様にピクチャヘッダ情報41内にあるPTS情報53を抽出する。次にメモリ部426に一時保管されたストリームデータを情報記憶媒体201上に記録する。
【0256】
STB装置416から再生開始位置としてタイムスタンプ値が指定された場合、対応するストリームブロックを算出するための情報がタイムマップ情報252である。このタイムマップ情報252は、図3(e)〜(h)に示すように、ストリームデータに対する管理情報記録領域であるSTREAM.IFO105内のストリームオブジェクト情報243の一部として記録されている。
【0257】
図3(i)に示すように、タイムマップ情報252内には各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。従って、各ストリームオブジェクト情報242、243毎にタイムマップ情報252内の各ストリームブロックの時間差の値を逐次加算し、その逐次加算値がSTB装置416側で指定したタイムスタンプ時刻に到達するかどうか比較する必要がある。その比較結果を元に、STB装置416側が指定した時刻はどのストリームオブジェクト内の何番目のストリームブロックの中に含まれるタイムスタンプ値と一致するかが、割り出される。
【0258】
次に、既に情報記憶媒体201上に記録してあるストリームデータの部分消去に関する実施例の説明を行う。
【0259】
ストリームデータの記録再生装置では、前述した部分消去処理はSTB制御部404により制御され、その中でも特にストリームデータ部分消去制御部と言う名のシーケンシャルプログラムが中心となり処理実行が行なわれる。
【0260】
図11のSTB制御部404では、部分消去が行われる前に、ストリームデータに関する管理情報(STRI)が記載されているSTREAM.IFO105の情報が読み込みまれ、ワークRAMメモリ部407に一時保管されている。部分消去処理が完了すると、部分消去対象のセクタが図2のSTREAM.VRO(またはSR_TRANS.SRO)106から外される。その後、管理情報(SOBIおよびSCIを含むSTRI)が図9(l)に示した内容に変更され、図2のSTREAM.IFO105内のデータが書き替えられる。
【0261】
次に、ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法として、「MPEG方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識した」アクセス方法について説明する。
【0262】
この発明の実施の形態では、STB装置416からアイソクロナス・モードでストリームデータが転送されると同時に、リアルタイムでIピクチャ情報が転送され、その情報が図1(a)のようにストリームデータを記録するSTREAM.VRO106ファイル内に記録される。また、この発明の実施の形態では、この情報は、ストリームデータの管理情報が記録されているSTREAM.IFO105内にも記録される。
【0263】
図11に示すSTB装置416側で、例えば図7のBピクチャ情報504を再生表示したい場合には、その直前に存在するIピクチャ情報501の先頭に位置するトランスポートパケット1aに対応したタイムスタンプ1aの値を、光ディスク装置415に通知する。
【0264】
光ディスク装置415では、図1あるいは図3に示した構造を有するタイムマップ情報252の情報を用いて再生開始するセクタ位置を割り出し、情報記憶媒体201上の所定位置へアクセスし、再生したいストリームデータをSTB装置416へ転送する。すると、STB装置416のデコーダ部402では、Iピクチャ情報501からデコードを開始し、指定されたBピクチャ情報504から表示を開始する。
【0265】
Bピクチャ情報504の開始情報が記録されているトランスポートパケット41d(図7)には、図5(a)(b)に示すように、そのトランスポートパケットヘッダ311内に表示開始時刻を示す再生タイムスタンプ(プレゼンテーションタイムスタンプ)PTS305の情報が記録されている。デコーダ部402では、このPTS305を読み取って、再生開始時刻を設定する。
【0266】
図11のデコーダ部402でIピクチャ位置を抽出する方法に付いて前述した。しかしデジタルTV放送局によっては送信の段階で各ピクチャ位置情報を送信する場合もある。送信の段階で既に記録されている各ピクチャ位置情報について、以下に説明する。
【0267】
この発明の実施の形態では、部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つとともに、部分消去部分を境界として残存部分を新たなストリームオブジェクトに定義し直すようにしている。この場合、ストリームオブジェクト内の最初と最後のストリームブロックのサイズが他のストリームブロックのサイズより小さくなることがある。そのため、図1(l)あるいは図3(i)に示すようにタイムマップ情報252では個々のストリームブロックサイズ情報も記録してある。
【0268】
この実施の形態においては、上記に限らず、例えば最初と最後のストリームブロックサイズ情報のみ持ち、他にはそれ以外の共通のストリームブロックサイズ情報のみ記録することも可能である。
【0269】
図12は、図11のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。
【0270】
図11の光ディスク装置(ストリーマ)415において、記録するビットストリーム(トランスポートパケットの内容)が、スタッフィングパケット内のアプリケーションパケットエリアに分配される(ステップST10)。
【0271】
最初のアプリケーションパケットのアプリケーションタイムスタンプ(ATS)の先頭バイト(これをAとする)と、ビットストリームが記録されるストリームオブジェクト(SOB)の開始部分にくる最初のストリームパケット内のアプリケーションパケットエリアの開始部分(これをBとする)とが比較される(ステップST12)。
【0272】
ATSの先頭バイト(A)と最初のストリームパケット内のアプリケーションパケットエリアの開始部分(B)とが一致しないときは(ステップST14ノー)、たとえば必要バイト数のスタッフィングバイトをストリームパケット内に設けて、先頭バイト(A)と開始部分(B)とを一致(アライン)させる(ステップST16)。
【0273】
ATSの先頭バイト(A)と最初のストリームパケット内のアプリケーションパケットエリアの開始部分(B)とが一致するとき(ステップST14イエス)、あるいは先頭バイト(A)と開始部分(B)とを一致(アライン)させたあと、記録するビットストリームの実際のデータを含む最終アプリケーションパケット(これをCとする)の末尾と、ビットストリームが記録されるSOBの末尾(これをDとする)との間に、1ストリームパケット分(1セクタ分)以上の余白があるかどうかチェックされる(ステップST18)。
【0274】
アプリケーションパケット(C)の末尾とSOBの末尾(D)との間に1ストリームパケット分(1セクタ分)以上の余白があるときは(ステップST18イエス)、この余白は、1つのATSを含む1以上のスタッフィングパケットで埋められる(ステップST20)。
【0275】
アプリケーションパケット(C)の末尾とSOBの末尾(D)との間に余白がないとき(ステップST18ノー)、あるいはアプリケーションパケット(C)の末尾とSOBの末尾(D)との間の余白がスタッフィングパケットで埋められたあと、記録するビットストリームの内容を含む1以上のアプリケーションパケット群(適宜スタッフィングパケットあるいはスタッフィングエリアバイトを含み得る)が、情報媒体201に記録される(ステップST22)。
【0276】
その後、記録情報に対応して管理情報(STRI)に書き込みが行われる(ステップST24)。
【0277】
上記記録ステップST22においては、以下の処理が適宜行なわれる。
【0278】
(10)アプリケーションパケットエリアの末尾に余白部分があるときは、この余白部分に(タイムスタンプがなく)所定バイト数のスタッフィングエリア(図5(h)または図19(j)のパディングエリア37)を設ける。
【0279】
また、上記記録ステップST22〜ST24においては、以下の処理が適宜行なわれる。
【0280】
(11)複数のデータユニット(図8(a)のSOBU#α…#λ)によりストリームデータ(SOB)を構成し、
所定のタイムスタンプ(TMS)情報が内部に記録されている1以上の前記データパケット(図8(b)のTP/AP)により各々の前記データユニット(SOBU#α…#λ)を構成し、
複数の前記データユニット(SOBU#α…#λ)のうち、少なくとも、第1のデータユニット(SOBU#α)内に記録された第1タイムスタンプ(TMS1a)と、第2のデータユニット(SOBU#β)内に記録された第2タイムスタンプ(TMS33a)との差分に対応した時間差値(図8(c)(d)の切り上げ丸め値)を、管理領域(STRIまたはSTREAM.IFO/SR_MANGR.IFO)内に記録する。
【0281】
(12)ストリームデータ(SOB)に、1以上のセル(図18)の情報を記録し、
管理領域(STRIまたはSTREAM.IFO/SR_MANGR.IFO)に、1以上のセルの集まりを記述したプログラムチェーン(PGC)の情報(図3(f)または図13のPGCI)を記録し、
前記ストリームデータ(SOB)の記録内容の一部を再生時にスキップする際に、そのスキップ位置の目印として利用できるエントリポイント(EP)の情報(SC_EPI)を、前記管理情報(STRI)に記録する。
【0282】
(13)管理情報(STRI)に、ストリームデータ(SOB)の記録時間情報(SOB_REC_TM)、前記ストリームデータ(SOB)の始まり部分のデータパケット到着時間(SOB_S_APAT)、および前記ストリームデータ(SOB)の終わり部分のデータパケット到着時間(SOB_E_APAT)のうち、少なくとも1つを含むストリームオブジェクト一般情報(図7(d)または図15のSOBI_GI)を書き込む。
【0283】
図13は、ストリーマの管理情報(図2または図3のSTREAM.IFOに対応)の内部データ構造を説明する図である。
【0284】
図2あるいは図3(e)に示した管理情報(ナビゲーションデータ)であるSTREAM.IFO(SR_MANGR.IFO)105は、図13に示すように、ストリーマ情報STRIを含んでいる。
【0285】
このストリーマ情報STRIは、図3(f)あるいは図13に示すように、ストリーマビデオマネージャ情報STR_VMGIと、ストリームファイル情報テーブルSFITと、オリジナルPGC情報ORG_PGCI(より一般的に表現すればPGC情報PGCI#i)と、ユーザ定義PGC情報テーブルUD_PGCITと、テキストデータマネージャTXTDT_MGと、アプリケーションプライベートデータマネージャAPDT_MGとで、構成されている。
【0286】
ストリーマビデオマネージャ情報STR_VMGIは、図13に示すように、STRI、STR_VMGIに関する管理情報等が記述されたビデオマネージャ情報管理情報VTSI_MATと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル(PL_SRPT)とを含んでいる。
【0287】
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。
【0288】
ストリームファイル情報テーブルSFITは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルSFITの詳細については、図15を参照して後述する。
【0289】
オリジナルPGC情報ORG_PGCIは、オリジナルPGC(ORG_PGC)に関する情報を記述した部分である。ORG_PGCはプログラムセットを記述したナビゲーションデータを示す。ORG_PGCはプログラムの連なり(チェーン)であり、図2または後述する図18の「.SRO」ファイル(図2ではSR_TRANS.SRO106)内に記録されたストリームデータを含む。
【0290】
ここで、プログラムセットとは、情報記憶媒体201の記録内容全体(全てのプログラム)を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルPGC(ORG_PGC)と呼ばれるデータ構造に対応している。
【0291】
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、1以上のオリジナルセルにより構成される。プログラムはオリジナルPGC内でのみ定義されるものである。
【0292】
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義PGC内のセルは「ユーザ定義セル」と呼ばれる。
【0293】
プログラムセット内の各々のプログラムは、少なくとも1個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも1個のユーザ定義セルで構成される。
【0294】
一方、ストリーマでは、ストリームセル(SC)だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
【0295】
なお、プログラムチェーン(PGC)とは、上位概念的な単位を示す。オリジナルPGCでは、PGCはプログラムセットに対応したプログラムの連なり(チェーン)を指す。また、ユーザ定義PGCでは、PGCはプレイリストに対応するプログラムの一部の連なり(チェーン)を指す。
【0296】
また、プログラムの一部のチェーンを指すユーザ定義PGCは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルPGCに属するストリームデータを参照するようになっている。
【0297】
図13のユーザ定義PGC情報テーブルUD_PGCITは、ユーザ定義PGC情報テーブル情報UD_PGCITIと、1以上のユーザ定義PGCサーチポインタUD_PGC_SRP#nと、1以上のユーザ定義PGC情報UD_PGCI#nとを含むことができる。
【0298】
ユーザ定義PGC情報テーブル情報UD_PGCITIは、図示しないが、ユーザ定義PGCサーチポインタUD_PGC_SRPの数を示すUD_PGC_SRP_Nsと、ユーザ定義PGC情報テーブルUD_PGCITの終了アドレスを示すUD_PGCIT_EAとを含む。
【0299】
UD_PGC_SRP_Nsが示すUD_PGC_SRPの数は、ユーザ定義PGC情報(UD_PGCI)の数と同じであり、ユーザ定義PGC(UD_PGC)の数とも同じである。この数は、最大「99」まで許されている。
【0300】
UD_PGCIT_EAは、該当UD_PGCITの終了アドレスを、そのUD_PGCITの先頭バイトからの相対バイト数(F_RBN)で記述したものである。
【0301】
ここで、F_RBNとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
【0302】
オリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したPGCI#iについては、図14を参照して後述する。
【0303】
図13のテキストデータマネージャTXTDT_MGは、補足的なテキスト情報である。このTXTDT_MGは、図14のプライマリテキスト情報PRM_TXTIとともに、プレイリストおよびプログラム内に格納できる。
【0304】
図13のアプリケーションプライベートデータマネージャAPDT_Mは、図示しないが、アプリケーションプライベートデータマネージャ一般情報APDT_GIと、1以上のAPDTサーチポインタAPDT_SRP#nと、1以上のAPDTエリアAPADTA#nとを含むことができる。
【0305】
ここで、アプリケーションプライベートデータAPDTとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報(リアルタイムストリームデータに加えさらに望まれる情報)を格納できるような概念上のエリアである。
【0306】
図14は、PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。図14のPGC情報PGCI#iは、図13のオリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したものである。
【0307】
図14に示すように、PGC情報PGCI#iは、PGC一般情報PGC_GIと、1以上のプログラム情報PGI#mと、1以上のストリームセル情報サーチポインタSCI_SRP#nと、1以上のストリームセル情報SCI#nとで構成されている。
【0308】
PGC一般情報PGC_GIは、プログラムの数PG_Nsと、ストリームセル情報サーチポインタSCI_SRPの数SCI_SRP_Nsとを含んでいる。
【0309】
各プログラム情報PGI(たとえばPGI#1)は、プログラムタイプPG_TYと、該当プログラム内のセルの数C_Nsと、該当プログラムのプライマリテキスト情報PRM_TXTIと、アイテムテキストのサーチポインタ番号IT_TXT_SRPNとを含んでいる。
【0310】
ここで、プログラムタイプPG_TYは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
【0311】
このプロテクトフラグが「0b」のときは該当プログラムは保護されておらず、「1b」のときは保護された状態にある。
【0312】
セルの数C_Nsは、該当プログラム内のセルの数を示す。PGCの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに(暗黙のうちに)付随している。
【0313】
たとえば、PGC内でプログラム#1がC_Ns=1を持ち、プログラム#2がC_Ns=2を持つとすれば、そのPGCの最初のストリームセル情報SCIはプログラム#1に付随するものとなり、第2、第3のSCIはプログラム#2に付随するものとなる。
【0314】
プライマリテキスト情報PRM_TXTIは、情報記憶媒体(DVD−RAMディスク)201を世界中で利用可能とするために、1つの共通キャラクタセット(ISO/IEC646:1983(ASCIIコード))を持ったテキスト情報を記述したものである。
【0315】
アイテムテキストのサーチポインタ番号IT_TXT_SRPNは、アイテムテキスト(該当プログラムに対応するテキストデータ)IT_TXTに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、IT_TXT_SRPNは「0000h」にセットされる。
【0316】
各ストリームセル情報サーチポインタSCI_SRP(たとえばSCI_SRP#1)は、対応ストリームセル情報SCIの開始アドレスを示すSCI_SAを含んでいる。このSCI_SAは、PGCIの先頭バイトからの相対バイト数(F_RBN)で記述される。
【0317】
各ストリームセル情報SCI(たとえばSCI#1)は、ストリームセル一般情報SC_GIと、1以上のストリームセルエントリポイント情報SC_EPI#nとで構成される。
【0318】
ストリームセル一般情報SC_GIは、仮消去(テンポラリイレーズ;TE)状態を示すフラグTEを含むセルタイプC_TYと、ストリームセルのエントリポイント情報の数SC_EPI_Nsと、ストリームオブジェクト番号SOB_Nと、ストリームセル開始APAT(図9で示したSC_S_APAT)と、ストリームセル終了APAT(図9で示したSC_E_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの開始APATを示す消去開始APAT(ERA_S_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの終了APATを示す消去終了APAT(ERA_E_APAT)とを含んでいる。
【0319】
セルタイプC_TYは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
【0320】
すなわち、セルの形式C_TY1=「010b」は全てのストリームセルの形式に記述される(このC_TY1=「010b」によりストリームセルとそれ以外のセルの区別ができる)。
【0321】
一方、フラグTEが「00b」であれば該当セルは通常の状態にあることが示され、フラグTEが「01b」あるいは「10b」であれば該当セルは仮消去の状態にあることが示される。
【0322】
フラグTE=「01b」は、該当セル(仮消去状態にあるセル)が、SOBU内で開始する最初のアプリケーションパケットの後から開始し、同じSOBU内の最終アプリケーションパケットの前で終了する場合を示す。
【0323】
また、フラグTE=「10b」は、該当セル(仮消去状態にあるセル)が、少なくとも1つのSOBU境界(先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのSOBU内で開始する)を含む場合を示す。
【0324】
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのTEフラグとは、同時に設定できないようになっている。それゆえ、
(a)プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず;
(b)仮消去状態にあるセルを1以上含むプログラムはプロテクト状態に設定できない。
【0325】
ストリームセルのエントリポイント情報の数SC_EPI_Nsは、該当ストリームセル情報SCI内に含まれるストリームセルエントリポイント情報の数を記述したものである。
【0326】
図14の各ストリームセルエントリポイント情報SC_EPI(たとえばSC_EPI#1)は、2種類(タイプAとタイプB)存在する。
【0327】
タイプAのSC_EPIは、エントリポイントタイプEP_TYとエントリポイントのアプリケーションパケット到着時間EP_APATとを含む。タイプAは、エントリポイントタイプEP_TY1=「00b」により示される。
【0328】
タイプBのSC_EPIは、タイプAのEP_TYおよびEP_APATの他に、プライマリテキスト情報PRM_TXTIを含む。タイプBは、エントリポイントタイプEP_TY1=「01b」により示される。
【0329】
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間(APAT)により特定できる。このAPATにより、どこからデータ出力が開始されるのかを特定できる。
【0330】
ストリームオブジェクト番号SOB_Nは、該当セルが参照するSOBの番号を記述したものである。
【0331】
ストリームセル開始APAT(SC_S_APAT)は、該当セルの開始APATを記述したものである。
【0332】
ストリームセル終了APAT(SC_E_APAT)は、該当セルの終了APATを記述したものである。
【0333】
消去開始APAT(ERA_S_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、この仮消去セルに先頭が含まれる最初のSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0334】
消去終了APAT(ERA_E_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、仮消去セルのすぐ後に続くアプリケーションパケットを含むSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0335】
図15は、ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【0336】
図15に示すように、ストリームファイル情報テーブルSFITは、ストリームファイル情報テーブル情報SFITIと、1以上のストリームオブジェクトストリーム情報SOB_STI#nと、ストリームファイル情報SFIとで構成される。
【0337】
ストリームファイル情報テーブル情報SFITIは、情報記憶媒体(DVD−RAMディスク)201上のストリームファイル情報の数SFI_Nsと、SFITIに続くストリームオブジェクトストリーム情報の数SOB_STI_Nsと、SFITの終了アドレスSFIT_EAと、SFIの開始アドレスSFI_SAとで構成される。
【0338】
SFIT_EAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFITの終了アドレスを記述したものである。
【0339】
また、SFI_SAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFIの開始アドレスを記述したものである。
【0340】
各ストリームオブジェクトストリーム情報SOB_STIは、3種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、SOB_STIは、ストリームオブジェクト情報(SOBI)のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト(SOB)が同じSOB_STIを共有する(つまり同じSOB_STIをポイントする)ことが認められている。したがって、通常は、SOBの数よりもSOB_STIの数の方が少なくなる。
【0341】
図15の各ストリームオブジェクトストリーム情報SOB_STI(たとえばSOB_STI#1)は、アプリケーションパケットサイズAP_SIZと、サービスIDの数SERV_ID_Nsと、サービスID(SERV_IDs)と、アプリケーションパケットデバイスユニークID(AP_DEV_UID)とを含んでいる。
【0342】
AP_SIZは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
【0343】
なお、DVDストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト(現SOB)はそこで終了され、新たなストリームオブジェクト(新SOB)が、新たなAP_SIZを伴って開始される。その際、現SOBおよび新SOBの双方は、オリジナルPGC情報(ORG_PGCI)内の同じプログラムに属するものとなる。
【0344】
SERV_ID_Nsは、後続パラメータに含まれるサービスIDの数を記述したものである。
【0345】
SERV_IDsは、サービスIDのリストを任意の順序で記述したものである。
【0346】
AP_DEV_UIDは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスIDを記述したものである。
【0347】
ストリームファイル情報SFIは、図15に示すように、ストリームファイル一般情報SF_GIと、1以上のストリームオブジェクト情報(SOB情報)サーチポインタ(SOBI_SRP)#nと、1以上のSOB情報(SOBI)#nとで構成されている。
【0348】
ストリームファイル一般情報SF_GIは、SOBIの数SOBI_Nsと、SOBU1個あたりのセクタ数SOBU_SIZとを含んでいる。
【0349】
ここで、SOBU_SIZは、SOBUのサイズをセクタ数で記述したもので、このサイズは32(32セクタ=64kバイト)で一定となっている。このことは、各タイムマップ情報(MAPL)内において、最初のエントリが、SOBの最初の32セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、2番目のエントリは、次の32セクタに含まれるアプリケーションパケットに関係する。3番目以降のエントリについても以下同様である。
【0350】
各SOB情報サーチポインタ(たとえばSOBI_SRP#1)は、SOBIの開始アドレスSOBI_SAを含んでいる。このSOBI_SAは、ストリームファイル情報SFIの先頭バイトから相対バイト数(F_RBN)でもって関連SOBIの開始アドレスを記述したものである。
【0351】
各SOB情報(たとえばSOBI#1)は、ストリームオブジェクト一般情報SOB_GIと、タイムマップ情報MAPLと、アクセスユニットデータAUD(オプション)とで構成される。
【0352】
ストリームオブジェクト一般情報SOB_GIは、ストリームオブジェクトのタイプSOB_TYと、ストリームオブジェクト記録時間SOB_REC_TMと、ストリームオブジェクトのストリーム情報番号SOB_STI_Nと、アクセスユニットデータフラグAUD_FLAGSと、ストリームオブジェクトの開始アプリケーションパケット到着時間SOB_S_APATと、ストリームオブジェクトの終了アプリケーションパケット到着時間SOB_E_APATと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットSOB_S_SOBUと、タイムマップ情報のエントリ数MAPL_ENT_Nsとを含んでいる。
【0353】
ストリームオブジェクトのタイプSOB_TYは、仮消去状態(TE状態)を示すビットおよび/またはコピー世代管理システムのビットを記述できる部分である。
【0354】
ストリームオブジェクト記録時間SOB_REC_TMは、関連ストリームオブジェクト(SOB)の記録時間を記述したものである。
【0355】
ストリームオブジェクトのストリーム情報番号SOB_STI_Nは、該当ストリームオブジェクトに対して有効なSOB_STIのインデックスを記述したものである。
【0356】
アクセスユニットデータフラグAUD_FLAGSは、該当ストリームオブジェクトに対してアクセスユニットデータ(AUD)が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
【0357】
アクセスユニットデータ(AUD)が存在する場合は、AUD_FLAGSにより、AUDの幾つかの特性が記述される。
【0358】
アクセスユニットデータ(AUD)自体は、図15に示すように、アクセスユニット一般情報AU_GIと、アクセスユニットエンドマップAUEMと、再生タイムスタンプリストPTSLとで構成される。
【0359】
アクセスユニット一般情報AU_GIは、該当SOBに対して記述されたアクセスユニットの数を示すAU_Nsと、該当SOBに属するSOBUのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップAUSMとを含んでいる。
【0360】
アクセスユニットエンドマップAUEMは、(もし存在するときは)AUSMと同じ長さのビットアレイであり、該当SOBのアクセスユニットに付随するビットストリームセグメントの終端をどのSOBUが含むのかを示す。
【0361】
再生タイムスタンプリストPTSLは、該当SOBに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる1つのPTSLエレメントは、対応アクセスユニットの再生タイムスタンプ(PTS)の値を含む。
【0362】
なお、アクセスユニット(AU)とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、MPEGのIピクチャに対応する部分となる。
【0363】
ここで再びSOB_GIの内容説明に戻る。
【0364】
AUD_FLAGSは、フラグRTAU_FLGと、フラグAUD_FLGと、フラグAUEM_FLGと、フラグPTSL_FLGとを含んでいる。
【0365】
フラグRTAU_FLGが0bのときは、該当SOBのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
【0366】
フラグRTAU_FLGが1bのときは、図10(d)のアプリケーションヘッダエクステンション内に記述されるAUフラグ(AU_START、AU_END)が、該当SOBのリアルタイムデータ内に存在可能なことが示される。この状態は、下記AUD_FLGが0bの場合にも許される。
【0367】
フラグAUD_FLGが0bのときは、該当SOBに対してアクセスユニットデータ(AUD)がないことが示される。
【0368】
フラグAUD_FLGが1bのときは、該当SOBに対してアクセスユニットデータ(AUD)が存在し得ることが示される。
【0369】
フラグAUEM_FLGが0bのときは、該当SOBにAUEMが存在しないことが示される。
【0370】
フラグAUEM_FLGが1bのときは、該当SOBにAUEMが存在することが示される。
【0371】
フラグPTSL_FLGが0bのときは、該当SOBにPTSLが存在しないことが示される。
【0372】
フラグPTSL_FLGが1bのときは、該当SOBにPTSLが存在することが示される。
【0373】
SOB_S_APATは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、SOB_S_APATにより、該当SOBに属する最初のアプリケーションパケット到着時間が示される。
【0374】
このパケット到着時間(PAT)は、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0375】
SOB_E_APATは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、SOB_E_APATにより、該当SOBに属する最後のアプリケーションパケット到着時間が示される。
【0376】
SOB_S_SOBUは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、SOB_S_SOBUにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むSOBUが示される。
【0377】
MAPL_ENT_Nsは、SOBI_GIの後に続くタイムマップ情報(MAPL)のエントリ数を記述したものである。
【0378】
タイムマップ情報MAPLは、図3(h)のタイムマップ情報252に対応する内容を持つ。
【0379】
図13および図15の内容の関連性の1つについて纏めると、次のようになる:
管理情報105に含まれるストリーマ情報STRIは、ストリームデータの内容の一部を構成するストリームオブジェクトSOBを管理するストリームファイル情報テーブルSFITを含む。このSFITは、SOBを管理するストリームオブジェクト情報SOBIを含む。このSOBIが、管理情報(アクセスユニット開始マップAUSM)を含むアクセスユニット一般情報AU_GIと、管理情報(PTSL)とを含む。
【0380】
ここで、管理情報(ATSまたはAUSM)がストリームデータの転送時に使用される情報を含み、管理情報(PTSまたはSC_S_APAT)が前記ストリームデータを表示するときに使用される情報を含む。
【0381】
図16は、アクセスユニット開始マップ(AUSM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【0382】
図示するように、AUSMのうちビット”1”の部分が、対応SOBUにアクセスユニット(AU)が含まれることを示している。
【0383】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)としてみる。すると、アクセスユニットAUの位置は次のようになる。
【0384】
(1)もしAUSM_pos(i)により示されるSOBU#iが1以上の開始AU(これはストリーム内で(もしあるなら)AU_STARTマークおよびAU_ENDマークにより記述される)を含むなら、AUSM_pos(i)は、SOBU#i内で開始する最初のAUに割り当てられる。ここで、SOBU#iは、AUSM_pos(i)および(AUEMが存在するなら)AUEM_pos(i)により記述されたSOBUs内に配置されたものである。
【0385】
(2)AUは、このAU開始後に最初に現れるAU_ENDマークで終了し、かつ、AUは、(もしAUEMが存在するなら)割り当てられたAUEMエレメントにより示される最後のSOBUで終了する。
【0386】
なお、いずれのアクセスユニットデータにおいても、SOBの各SOBU1個当たりに、2以上のアクセス可能なアクセスユニットを記述することはできない。
【0387】
図17は、アクセスユニット開始マップ(AUSM)およびアクセスユニット終了マップ(AUEM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【0388】
AUEMは、(もし存在するなら)AUSMと同じ長さのビットアレイである。AUEMのビットは、該当SOBのアクセスユニットに付随するビットストリームセグメントの末尾がどのSOBUに含まれるのかを、示している。
【0389】
AUEM内にセットされたビットの数はAUSM内にセットされたビットの数に一致する。すなわち、AUSM内の各設定ビットは、AUEM内に対応してセットされたビットを持つ。
【0390】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)とし、AUEM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUEM_pos(i)としてみる。この場合、以下の関係がある。
【0391】
(1)1≦AUSM_pos(i)≦AUEM_pos(i)≦MAPL_ENT_Ns;
(2)AUSM_pos(i+1)>AUEM_pos(i);
(3)もしi==AU_NsあるいはAUSM_pos(i+1)>1+AUEM_pos(i)なら、AU#iは、SOBU#[AUEM_pos(i)]で終了する(1≦i≦AU_Ns);
(4)もしAUSM_pos(i+1)==1+AUEM_pos(i)なら、AU#iは、SOBU#[AUEM_pos(i)]で終了する。あるいは
SOBU#[1+AUEM_pos(i)]==SOBU#[AuSM_pos(i+1)]のところで終了する。つまり、AU#iは、SOBU内においてAU#i+1が開始するところで終了する(1≦i≦AU_Ns)。
【0392】
図18は、オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【0393】
ユーザ定義PGCは自身のSOBを含まないが、オリジナルPGC内のSOBを参照する。それゆえ、ユーザ定義PGCはPGC情報を用いることのみで記述できる。このことは、SOBデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
【0394】
ユーザ定義PGCはまた、プログラムを含まず、オリジナルPGC内のプログラムの一部に対応したセルの連なり(チェーン)で構成される。
【0395】
このようなユーザ定義PGCの一例が、図18に示されている。この例は、PGC内のセルがオリジナルPGC内のSOBを参照するようにユーザ定義PGC#nが作成されている場合を示す。
【0396】
図18において、PGC#nは4つのセル#1〜#4を持っている。そのうち2つはSOB#1を参照し、残りの2つがSOB#2を参照している。
【0397】
ユーザ定義PGC内のセルからオリジナルPGCへ(SOBIのタイムマップ情報へ)の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義PGC内のセル再生順序は、オリジナルPGCにおける再生順序と全く異なってもよい。
【0398】
任意のSOBおよびそのSOBUの再生は、図18の開始APAT(S_APAT)および終了APAT(E_APAT)により特定される。
【0399】
SOBあるいはSOBUのS_APATは、該当SOBのストリームパックのペイロード(図5(b)参照)内に記録されたタイムスタンプに関係して定義される。
【0400】
SOBの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間(APAT)である。
【0401】
SOBの先頭アプリケーションパケットのAPATはSOB_S_APATとして記憶される。全てのAPATの4最下位バイト(4 least significant bytes)は、「〜.SRO」ファイル内の対応アプリケーションパケット用に予め固定されている。
【0402】
SOBあるいはSOBUのデータを再生するために、ストリーマ内部のリファレンスクロックはSCR値にセットされ、その後クロックが自動的にカウントされる。このSCR値は、再生が始まる最初のストリームパック内(パックヘッダ内)に記述されている。このクロックに基づいて、SOBあるいはSOBUからの全ての後続アプリケーションパケットの再生・出力が、実行される。
【0403】
任意のストリームセル(SC)が、そのSCがポイントするSOBのSOB_S_APATとSOB_E_APATとの間の任意の値を持つストリームセル開始APAT(SC_S_APAT)を規定しているときは、所望のAPATを伴うアプリケーションパケットを含んだSOBUを見つけるためのアドレスが必要となる。
【0404】
SOBU1個あたりのストリームパックの数は一定であるが、各SOBUにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各SOBは、該当SOBのSOBUの到着時間間隔が記述されたタイムマップ情報を持つ。つまり、タイムマップ情報により実現されるアドレス方式は、任意のAPATをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるSOBUをポイントする。
【0405】
図18に例示された各エントリポイント(EP#i、EP#k)は、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間(APAT)により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図14のEP_APATにより示される。
【0406】
このエントリポイントを用いることにより、例えばセル#1のSOBU#1からの再生時において、SOBU#2〜SOBU#(i−1)をスキップして、SOBU#iの指定位置(エントリポイントEP#i)から再生を開始することができる。
【0407】
図19は、この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。
【0408】
DVD−RAMディスク等の情報記憶媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(SOB)としてまとめられている。各SOBは、1つのリアルタイムな連続記録により得られたストリームデータにより形成される。
【0409】
図19(f)は、1以上あるストリームオブジェクトのうち1個のSOB#A・298について示している。DVD−RAMディスクにこのストリームデータが記録される場合には、各々が2048kバイトのセクタを最小単位として記録される。さらに、16個のセクタをまとめて1個のECCブロックとし、同一ECCブロック内でインターリーブ(データ配列順序の並び替え)とエラー訂正用の訂正コードの付加が行われる。
【0410】
この実施の形態では、1個または複数のECCブロックを単位としてストリームブロックが構成され、このストリームブロック単位でストリーム情報の記録あるいは部分消去が行われる。
【0411】
この実施の形態では、何個のECCブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて決めることができる。たとえば、図19(e)の例では、ストリームブロック#1は2つのECCブロック#α、#βで構成され、ストリームブロック#2は3つのECCブロック#γ、#δ、#εで構成されている。DVDストリーマでは、2個のECCブロック(32セクタ)で1つのストリームブロック(ストリームオブジェクトユニットSOBU)が構成される。
【0412】
各ECCブロックは、図19(d)に示すように、16セクタで構成される。したがって、図19(d)(e)から分かるように、2ECCブロックで構成されるストリームブロック(あるいはSOBU)#1は、32セクタ(セクタNo.0〜セクタNo.31)に相当する。
【0413】
つまり、1セクタ=2kバイトとすれば、ストリームブロック(SOBU)は、64kバイト(32セクタ)の固定サイズとして、この発明を実施することができる。
【0414】
各セクタの内容はストリームパック(詳細は図5、図6、図10参照)に対応している。そして、たとえばセクタNo.0(図19(d))に対応するストリームパックは、図19(c)に示すように、パックヘッダ1xと、PESヘッダ6xと、ストリームブロックヘッダ11xと、データエリア21xとを含んでいる。また、セクタNo.1(図19(d))に対応するストリームパックは、図19(c)に示すように、パックヘッダ2xと、PESヘッダ7xと、セクタデータヘッダ12xと、データエリア22xとを含んでいる。
【0415】
図19(c)のデータエリア21xは、図19(b)に示すように、タイムスタンプとトランスポートパケットとのペアの配列(タイムスタンプa、トランスポートパケットa、タイムスタンプb、………トランスポートパケットd)を含んでいる。同様に、データエリア22xは、タイムスタンプとトランスポートパケットとのペアの別配列を含んでいる。一方、後方のデータエリア23xは、図19(b)に示すように、トランスポートパケットf、エンドコード31x、およびパディングエリア36xを含んでいる。
【0416】
図19(b)のタイムスタンプとトランスポートパケットの複数ペアは、図19(a)に示すような配列のビットストリームとなる。
【0417】
SOB#A・298(図19(f))の前方のストリームブロック#1(図19(e))のデータ構造は図19(d)〜(b)のようになるが、SOB#A・298の後方のストリームブロック#2(図19(g))のデータ構造は、次のようになる。
【0418】
すなわち、ストリームブロック#2の末尾ECCブロック#εの後方セクタNo.78(図19(h))は、図19(i)に示すように、パックヘッダ3xと、PESヘッダ8xと、セクタデータヘッダ13xと、データエリア24xとを含んでいる。また、ECCブロック#εの最終セクタNo.79(図19(h))は、図19(i)に示すように、パックヘッダ4xとパディングパケット40xを含んでいる。
【0419】
セクタNo.78のデータエリア24xは、図19(j)に示すように、トランスポートパケットzと、エンドコード32xと、パディングエリア37xとを含んでいる。また、最終セクタNo.79のパディングパケット40xは、図19(j)に示すように、PESヘッダ9xとパディングエリア38xを含んでいる。
【0420】
なお、パディングエリア37xの内容は、図5(h)に示すように、1以上のタイムスタンプとパケットとのペアと、予約バイトのスタッフィングエリア(スタッフィングエリアにタイムスタンプは付かない)とで構成できる。この場合、スタッフィングエリアにはストリームデータの記録はなされない。
【0421】
一方、パディングエリア38の内容は、図6(i)(j)に示すように、スタッフィングパケット(先頭だけアプリケーションタイムスタンプATSが付く)を含むアプリケーションパケットエリアで構成できる。
【0422】
この発明では、以下のような特徴を持つデータ構造を採用することもできる:
A)各セクタ/ストリームパック毎にパックヘッダ/パケットヘッダを設け、セクタ/ストリームパック毎に必要な情報をパックヘッダ/パケットヘッダ内に記録するデータ構造(図1(a)〜(c)、図5(a)〜(b)、図10(a)〜(g)参照)。
【0423】
B)各トランスポートパケット/アプリケーションパケットがデコーダに転送される時間間隔に関係した時間情報を、タイムスタンプ情報として、各トランスポートパケット/アプリケーションパケットと一緒に情報記憶媒体上に記録するデータ構造(図1(k)〜(m)、図5〜図10参照)。
【0424】
C)タイムスタンプとトランスポートパケット/アプリケーションパケットをセクタ/ストリームパック内のパックヘッダ/パケットヘッダ以外の場所に順次詰めて記録するデータ構造。そして、タイムスタンプの切れ目またはトランスポートパケット/アプリケーションパケット毎に記録されるストリームデータの切れ目がセクタ/ストリームパックの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケット/アプリケーションパケットのどちらかを、隣のセクタ/ストリームパックに跨って配置記録するデータ構造(図1(d)〜(g)、図5(e)〜(j)参照)。
【0425】
D)ユーザ等が行う一回の録画映像の纏まりをストリームオブジェクト(SOB)とし、一回の映像録画において情報記憶媒体上に記録された最後のトランスポートパケット/アプリケーションパケット位置(1個のストリームオブジェクト内の最後のトランスポートパケット/アプリケーションパケット位置)がセクタ/ストリームパックの境界位置とは異なる場合には、該当するセクタ/ストリームパック内に限りこの最後のトランスポートパケット/アプリケーションパケット位置以降をパディングエリアとするデータ構造(図1(g)(k)、図6(g)〜(j)、図19(j)参照)。
【0426】
E)情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設けてストリームデータの検索および/または編集を容易とするデータ構造。
【0427】
F)ストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)内では、STREAM.VROファイルあるいはRTR_MOV.VROファイル内に記録してあるタイムスタンプの値を、個々のトランスポートパケット/アプリケーションパケット毎の識別/指定に利用するデータ構造(図8(b)〜(d)参照)。
【0428】
G)タイムサーチを容易にするため、複数セクタを纏めてストリームブロックという単位(あるいはストリームオブジェクトユニットSOBUというデータユニット)を管理ファイル上で構成し、このストリームブロック(SOBU)毎の時間情報を持ったタイムマップ情報を、この管理ファイル(STREAM.IFOあるいはRTR.IFO)内に持たせるデータ構造(図8(a)〜(d)参照)。
【0429】
なお、少なくともストリームオブジェクト内の最初と最後のストリームブロック(SOBU)のデータサイズを、管理ファイル(STREAM.IFOあるいはRTR.IFO)内のタイムマップ情報に記録するようにしてもよい(図3(i)参照)。
【0430】
H)各ストリームブロック(SOBU)内の最初に配置されたタイムスタンプ(前のストリームブロックから跨って記録されたタイムスタンプを除く)の値を各ストリームブロック(SOBU)先頭時刻として管理ファイル(STREAM.IFOあるいはRTR.IFO)内で管理するデータ構造(図8(a)〜(d)参照)。
【0431】
具体的には、管理ファイル内のタイムマップ情報に各ストリームブロック(SOBU)内で最初に配置されたタイムスタンプ(たとえば図8(b)のTMS1a)の値を記録する。
【0432】
この発明に係るストリームデータ記録方法では、第1の記録単位(セクタまたはストリームパック)毎に情報記録を行える情報記憶媒体を用い、第2の記録単位(トランスポートパケット/アプリケーションパケット)に分割されたストリームデータが記録される。
【0433】
上記第2の記録単位(トランスポートパケット/アプリケーションパケット)でストリームデータが記録される第1の記録領域(図3(d)のストリーム記録エリア222)内に、上記第1記録単位(セクタ/ストリームパック)毎に付与するパケットヘッダ(あるいはパックヘッダ)情報と、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎のストリームデータとが記録される。
【0434】
上記タイムスタンプ情報の切れ目もしくは上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎に記録されるストリームデータの切れ目が上記第1の記録単位(セクタ/ストリームパック)の境界位置とは異なる場合には、上記タイムスタンプ情報または上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎に記録されるストリームデータが複数の上記第1の記録単位(セクタ/ストリームパック)に跨って配置されるように記録される(図5(e)の番組2のトランスポートパケットbの前半部346と後半部347、および図5(h)〜(j)参照)。
【0435】
情報記憶媒体上に最後に記録されたストリームデータにおいて、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)の最終位置が上記第1の記録単位(セクタ/ストリームパック)の境界位置とは異なる場合には、最後に記録された上記第1の記録単位(セクタ/ストリームパック)または上記第2の記録単位(トランスポートパケット/アプリケーションパケット)の最終位置以降に、パディングエリア(図1(k)あるいは図6(h)の21)として、所定のデータ(たとえば、オール1ビットあるいはオール0ビット)が記録される(図6(i)(j)参照)。
【0436】
上記第1の記録領域(ストリーム記録エリア222)内に記録されたデータに関する管理情報を格納する第2の記録領域(STREAM.IFOあるいはRTR.IFO)が記録される(図3(d)(e)参照)。
【0437】
上記第1の記録領域(ストリーム記録エリア222)に関する時間情報が記録された第3の記録領域(ストリームファイル情報)に対して、上記第1の記録単位(セクタ/ストリームパック)を複数集めて第3の記録単位(ストリームブロック/SOBU)が構成される(図6(b)〜(e)、図8(a)〜(b)参照)。
【0438】
上記第1の記録領域(ストリーム記録エリア222)内に記録されたストリームデータに対する上記第3の記録単位(ストリームブロック/SOBU)毎の先頭に配置されたタイムスタンプ情報間の差分値が、タイムマップ情報として記録される(図1(i)〜(m)、図8(a)〜(d)参照)。
【0439】
また上記の方法でストリームデータが記録されたデータ構造を有する情報記憶媒体も、この発明の特徴となっている。
【0440】
さらにIピクチャ開始位置を意識しながらトランスポートパケット単位での部分消去を可能とする方法として、以下のものがある。
【0441】
I)部分消去場所前後で新たにストリームオブジェクトを分割する。
【0442】
J)ストリームデータが記録されているSTREAM.VROファイルあるいはRTR_MOV.VROファイルに関する情報を記載するストリームファイル情報の情報と、ストリームデータの再生時に使用する再生単位情報(セル情報)を、管理ファイル(STREAM.IFOあるいはRTR.IFO)内に持つ。
【0443】
K)ストリームデータが記録されているSTREAM.VROファイルあるいはRTR_MOV.VROファイルに対してはセクタ単位で部分消去処理を行う。
【0444】
L)管理ファイル(STREAM.IFOあるいはRTR.IFO)上ではIピクチャ開始位置に従ってストリームオブジェクトを分割する。
【0445】
具体的には、ストリームファイル情報(図7(d)のSOBI_GI・251)内にストリームオブジェクト開始時間の情報(図7(C)のSOB_S_APAT542)とストリームオブジェクト終了時間の情報(図7(C)のSOB_E_APAT543)を持たせ、部分消去後はIピクチャ開始位置が記録されているトランスポートパケット(図7の1a)に対応したタイムスタンプ(図7の1a)の値をストリームオブジェクト開始時間(SOB_S_APAT542)の値に変更(あるいは追記)し、部分消去境界位置を含むストリームデータの直後に来るIピクチャ開始位置が記録されているトランスポートパケットの1個前のトランスポートパケット(図7のTP298g)に対応したタイムスタンプ(図7のTMS298g)の値をストリームオブジェクト終了時間(SOB_E_APAT543)の値に変更(あるいは追記)する。
【0446】
M)管理ファイル(STREAM.IFOあるいはRTR.IFO)上では部分消去指定したトランスポートパケットに対応してセル情報内の開始/終了位置を設定する。
【0447】
具体的には、部分消去の範囲をトランスポートパケット単位で指定し、その指定範囲に対して残存したトランスポートパケットのうち、先頭のトランスポートパケットに対応したタイムスタンプ(図9(j)のTMS97c)の値を新たなオリジナルセルの該当セルの開始時間(図9(l)のSC_S_APAT283)とし、最後のトランスポートパケットに対応したタイムスタンプ(図9(j)のTMS224k)の値を新たなオリジナルセルの該当セルの終了時間(図9(l)のSC_E_APAT284)として管理ファイル(STREAM.IFOあるいはRTR.IFO)内に変更(あるいは追記)する。
【0448】
上述した部分消去方法を適用できる情報媒体は、第1の記録単位(セクタ)毎に情報の記録が行える媒体である。この媒体は、ストリームデータが記録される第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)と、上記第1の記録領域内に記録されたデータに関する管理情報を記録した第2の記録領域(STREAM.IFOあるいはRTR.IFO)とを持つ。上記第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)内に、上記第1記録単位(セクタ)毎に付与するパケットヘッダ情報と、上記第2の記録単位(トランスポートパケット)のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第2の記録単位(トランスポートパケット)毎のストリームデータが詰めて記録される。上記第1の記録単位(セクタ)を複数集めて第3の記録単位(ストリームブロック)が構成される。そして、複数の前記第3の記録単位(ストリームブロック)から構成されストリームデータに対する大きなデータのまとまりを示す第4の記録単位(ストリームオブジェクト)が構成される。上記第2の記録領域(STREAM.IFOあるいはRTR.IFO)内に、上記第3の記録単位(ストリームブロック)毎の時間情報(タイムマップ情報)と上記第4の記録単位(ストリームオブジェクト)の開始と終了位置での上記第3の記録単位(ストリームブロック)のデータサイズ情報が記録される。
【0449】
上記第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)内に記録されたストリームデータは、上記第1の記録単位(セクタ)で部分消去できる。そして、部分消去後は新たなサイズを持った第4の記録単位(ストリームオブジェクト)が形成され、かつ上記新たなサイズを持った第4の記録単位(ストリームオブジェクト)における開始位置もしくは終了位置での上記第3の記録単位(ストリームブロック)でのデータサイズと時間情報の内の少なくともいずれかの情報が、上記第2の記録領域(STREAM.IFOあるいはRTR.IFO)内で書き換えられるか、または新規記録される。
【0450】
この発明の実施により得られる効果をまとめると以下のようになる。
【0451】
1.各トランスポートパケット毎の時間情報をタイムスタンプ情報として各トランスポートパケットとともに一緒に情報記憶媒体上に記録するため、
a)そのタイムスタンプ値に合わせてSTBへトランスポートパケットを転送するタイミングが分かる。
【0452】
b)そのタイムスタンプ値に合わせたタイミングでデコーダへトランスポートパケットを転送できるため、デコーダ側にバッファーがなくても破綻なく安定にデコードと画面表示が行える。
【0453】
c)そのタイムスタンプ値を用いて個々のトランスポートパケットを識別・分別できるため、アクセス時の到着位置指定や編集時の範囲指定が容易となる。
【0454】
2.セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置(ストリームオブジェクトの最後の位置)のセクタ内にのみパディングエリアを設定する。このため、効率良く情報記憶媒体上にストリームデータを記録できる。その結果、トランスポートパケット毎に分割されたストリームデータの録画記録時には情報記憶媒体の実行容量をほとんど低下させずに記録できる。
【0455】
3.セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置(ストリームオブジェクトの最後の位置)のセクタ内にのみパディングエリアを設定する。このため、セクタサイズ(2048kバイト)よりも大きなサイズのトランスポートパケットを記録することができる。
【0456】
4.この発明の実施の形態に従えば、各セクタ内でパケットヘッダ直後にタイムスタンプがくるとは限らない。従って、各ストリームブロック毎の時間情報の抽出方法として、この発明の実施の形態では、各ストリームブロック内の最初に配置されたタイムスタンプ(前のストリームブロックから跨って記録されたタイムスタンプを除く)の値を各ストリームブロック先頭時刻として取り扱うことにより、管理ファイル(STREAM.IFOあるいはRTR.IFO)内のタイムマップ情報の作成を可能としている。そうすると、このタイムマップ情報を用いた所定のトランスポートパケットに対するアクセスが容易となる。
【0457】
5.STREAM.VROファイルあるいはRTR_MOV.VROファイル内のストリームデータに対してセクタ単位での部分消去を可能にすると、DVD−RAMなどの情報記憶媒体に対する記録最小単位(セクタ単位)でのSTREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放が可能となる。その結果、STREAM.VROファイルあるいはRTR_MOV.VROファイルから開放されたセクタに対して後でコンピュータデータを記録する等の有効利用が可能となる。
【0458】
なお、上記内容と異なった部分消去単位として、例えばストリームブロック(SOBU)単位でしか部分消去(STREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放)しない場合には、ユーザがセクタサイズ程度の細かい範囲での部分消去を指定しても部分消去範囲が狭いために実質的にSTREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放が生じない。その結果、ユーザが指定した細かい範囲での部分消去の指定領域を他のデータ記録に利用できず、実質的には情報記憶媒体上に情報が記録されない無駄領域が増える危険性がある。とはいえ、この発明はSOBU単位での部分消去の利用を排除するものではない。
【0459】
6.情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設け、その管理ファイル内にストリームデータの再生時の再生単位を表すセルに関する情報を記録したセル情報を記録する。そのセルに関する開始/終了位置情報をタイムスタンプに対応した時間情報で持たせることにより、タイムスタンプ値で代表されるトランスポートパケットが指定できる。このようにセルの開始/終了位置情報を時間情報で記述させることで、部分消去後の再生範囲を実質的にトランスポートパケット単位で細かく指定できる。
【0460】
7.情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設け、さらにその管理ファイル内存在するストリームファイル情報内にストリームオブジェクト開始時間とストリームオブジェクト終了時間情報を持たせる。そして、部分消去後はIピクチャ開始位置が記録されているトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト開始時間の値に設定し直し、あるいは部分消去境界位置を含むストリームデータの直後にくるIピクチャ開始位置が記録されているトランスポートパケットの1個前のトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト終了時間の値に設定し直すことでIピクチャ開始位置を境界位置としたストリームデータの部分消去(分割)が可能となる。その結果、
a)デコーダが常にIピクチャ位置からデコード開始できるので、フレーム単位の任意位置から表示開始が可能となる。
【0461】
b)管理ファイル(STREAM.IFOあるいはRTR.IFO)の情報から常にIピクチャ位置が分かり、Iピクチャ開始位置を区切りにストリームデータが分割されているので異なる複数のストリームオブジェクトを連続して再生する場合に、ストリームオブジェクトの切れ目(変わり目)で画面が乱れることなくシームレスに連続して映像再生が行える。
【0462】
8.アイソクロナスパケットヘッダ343、344にIピクチャ位置を示すフラグを設けることで、STB装置416から光ディスク装置415に対してストリームデータ(トランスポートパケット)の転送と同時にIピクチャ位置情報をリアルタイムで通知できる。その結果、容易にストリームデータ記録ファイル(STREAM.VROあるいはRTR_MOV.VRO)内にIピクチャ位置情報をリアルタイムで記録できるとともに、管理ファイル(STREAM.IFOあるいはRTR.IFO)内にも容易にIピクチャ位置情報を記録できる。
【0463】
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
【0464】
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から1または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも1つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。
【符号の説明】
【0465】
201…情報記憶媒体/情報記憶媒体(DVD−RAMディスク等);415…光ディスク装置;416…セットトップボックス装置。
【技術分野】
【0001】
この発明は、デジタル放送などで伝送される映像データあるいはパケット構造をもって伝送されるストリームデータを記録する方法、この記録方法に適したストリームデータのデータ構造、およびこのデータ構造を用いて情報記録がなされる情報媒体に関する。
【背景技術】
【0002】
近年、TV放送はデジタル放送の時代に突入してきた。それに伴い、デジタルTV放送のデジタルデータをその内容を問わずデジタルデータのままで保存する装置、いわゆるストリーマが要望されるようになってきた。
【0003】
現在放送されているデジタルTV放送では、MPEGのトランスポートストリームが採用されている。今後も、動画を使用したデジタル放送の分野では、MPEGトランスポートストリームが標準的に用いられると考えられる。
【0004】
このデジタル放送では、放送される内容(主に映像情報)が、トランスポートパケットと呼ばれる所定サイズ(たとえば188バイト)毎のデータの纏まりに時間分割され、このトランスポートパケット毎に放送データが伝送される。
【0005】
このデジタル放送データを記録するストリーマとして、現在市販されているものとしては、D−VHS(デジタルVHS)などの家庭用デジタルVCRがある。このD−VHSを利用したストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、ビデオテープには、複数の番組が多重されて記録されることになる。
【0006】
再生時には、最初から再生する場合、あるいは途中から再生する場合にも、そのまま全てのデータが、VCRからセットトップボックス(デジタルTVの受信装置:以下STBと略記する)に送り出される。このSTBにおいて、ユーザ操作等により、送り出されたデータ内から所望の番組が選択される。選択された番組情報は、STBからデジタルTV受像機等に転送されて、再生(ビデオ+オーディオ等の再生)がなされる。
【0007】
このD−VHSストリーマでは、記録媒体にテープが用いられるため、素早いランダムアクセスが実現できず、所望の番組の希望位置に素早くジャンプして再生することが困難となる。
【0008】
このようなテープの欠点(ランダムアクセスの困難性)を解消できる有力な候補として、DVD−RAMなどの大容量ディスクメディアを利用したストリーマが考えられる(特許文献1の段落0001、0018等参照)。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性がでてくる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開平8−235832号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
情報記憶媒体としてDVD−RAMディスクを用いた場合には、2048バイト毎に纏められたセクタ単位でデータが記録される。一方、デジタルTV放送ではMPEGのトランスポートストリームが採用されており、映像情報が入ったストリームデータは、トランスポートストリームの最小単位として188バイトのトランスポートパケット毎に纏まって送信される。このトランスポートパケットのサイズはデジタルTV放送局により異なり、たとえば130バイト単位として送信するデジタルTV放送局もある。この受信したトランスポートパケットそのままをDVD−RAMディスクなどの情報記憶媒体にセクタ単位で記録した場合、以下のような問題が生じる。すなわち、
1.セクタサイズの2048バイトがトランスポートパケットサイズ(たとえば188バイト)の整数倍でないため、セクタ内へのトランスポートパケットの記録方法が問題となる。
【0011】
具体的には、あるセクタ内へトランスポートパケットを先頭から順次配置し、このセクタ内で生じた余りの端数分をパディングエリア扱いとした場合には、各セクタ毎に無駄なパディングエリアが多数発生する。このため、情報記憶媒体上に記録できるストリームデータ量が、セクタ毎のパディングエリアの分、減少する。その結果、情報記憶媒体の実質的な記録容量が少なくなる。
【0012】
2.MPEG規格に従って映像圧縮されているストリームデータは、情報記憶媒体から再生した後デコーダでデコードされる必要があるが、各トランスポートパケット毎のデコーダに転送される時間間隔はデジタルTV放送局から受信した直後の時間間隔を保持する必要がある。そのため、各トランスポートパケット毎のデコーダへ転送される時間間隔情報が必要となる。
【0013】
3.情報記憶媒体上に記録される各トランスポートパケットは、それぞれのトランスポートパケットを個々に識別する識別情報を持たないため、検索(サーチ)または編集時に特定のトランスポートパケットを指定する手段がない。
【0014】
4.情報記憶媒体としてDVD−RAMディスクを用いた場合には、2048バイト毎のセクタ単位で記録されるため、トランスポートパケット単位での部分的な消去処理が難しい。
【0015】
5.デジタルTV放送で送信するストリームデータは、MPEG規格に従って映像圧縮されているため、Iピクチャ位置からデコードを開始する必要がある。従って、特定の映像位置で部分消去する場合は、実質的にはその先頭にあるIピクチャ開始位置を境界位置として部分消去する必要がある。しかし、トランスポートパケットをセクタ内に順次記録しただけの情報では、Iピクチャ開始位置を上記境界位置とした部分消去処理は難しい。
【0016】
この発明は上記事情に鑑みなされたもので、その目的は、ストリームデータを効率よく記録できる記録方法を提供することである。
【0017】
この発明の他の目的は、ストリームデータを効率よく管理できるデータ構造を提供することである。
【課題を解決するための手段】
【0018】
この発明の一実施の形態に係る情報媒体は、ストリームパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されるデータ領域と、前記ストリームデータに関する管理情報が記録される管理領域とを有する。ここで、前記Iピクチャ情報とこのIピクチャ情報に隣接する情報との境界は、前記ストリームデータのうちこの境界に該当する部分の開始時間情報(SOB_S_APAT)またはその終了時間情報(SOB_E_APAT)により示すことができる。
【発明の効果】
【0019】
ストリームデータを効率よく記録できるようになる。
【図面の簡単な説明】
【0020】
【図1】図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。
【図2】この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。
【図3】この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【図4】この発明におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。
【図5】デジタル放送、IEEE1394、およびストリーマにおける映像データ転送形態の関係を説明する図である。
【図6】ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。
【図7】MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係を説明する図である。
【図8】図1その他で示されるタイムマップ情報の設定方法を説明する図である。
【図9】記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。
【図10】図5その他に示されるストリームパックのデータ構造を説明する図である。
【図11】この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。
【図12】図11のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。
【図13】ストリーマの管理情報(図2または図3のSTREAM.IFOに対応)の内部データ構造を説明する図である。
【図14】PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。
【図15】ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【図16】アクセスユニット開始マップ(AUSM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【図17】アクセスユニット開始マップ(AUSM)およびアクセスユニット終了マップ(AUEM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【図18】オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【図19】この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。
【発明を実施するための形態】
【0021】
以下、図面を参照してこの発明の一実施の形態に係るストリームデータの記録方法およびそのデータ構造などについて説明をする。
【0022】
図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。
【0023】
情報媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎あるいは一回の映像録画単位毎にストリームオブジェクトとして纏められて記録されている。
【0024】
図1(h)は、DVD−RAMディスク等の情報媒体上に記録されたストリームオブジェクトを例示している。ここでは、ストリームオブジェクト#A298の最後の部分と、それに続いて記録されているストリームオブジェクト#B299を示している。
【0025】
DVD−RAMディスク等にこのストリームデータを記録する場合には、図1(d)に示すように、2048kバイト毎のセクタを最小単位として記録される。各セクタ毎には、図1(c)(e)に示すように、パックヘッダ(あるいはパケットヘッダ)11〜15の記録領域とストリームデータを記録するデータエリアに分かれている。
【0026】
各データエリアには、図1(f)(g)に示すように、タイムスタンプおよびトランスポートパケットが逐次詰め込まれる。これは、以下のように行うことができる。すなわち、
1.タイムスタンプとトランスポートパケットをセクタ内のパックヘッダ11〜15以外の場所に順次めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録する。
【0027】
具体的には、図1(g)では、データエリアNo.1内にタイムスタンプとトランスポートパケットを順次詰め込むと、トランスポートパケット1kの所でデータエリアNo.1に入り切れず、トランスポートパケット1kの一部がデータエリアNo.1からはみ出してしまう。このトランスポートパケット1kの中で、データエリアNo.1からはみ出した部分を、次のセクタNo.2内のデータエリアNo.2の先頭位置に継続して記録する。
【0028】
2.ユーザ等が行う一回の映像録画の纏まり、もしくは1番組などの同一コンテンツの纏まりをストリームオブジェクトと定義する。そして、情報記憶媒体上に記録されたストリームオブジェクトの最後のトランスポートパケット位置がセクタの境界位置とは異なる場合には、該当するセクタ内に限りこの最後のトランスポートパケット位置以降をパディングエリアとする。
【0029】
具体的には、図1(k)の例では、トランスポートパケット321aで映像録画が終了し、ここがストリームオブジェクト#B299の実質的な最終位置になる。その際、このトランスポートパケット321aが図1(j)のデータエリアNo.321の途中に配置されている場合には、データエリアNo.321に限り、それ以降をパディングエリア21とする。
【0030】
以上のようなデータ構造を用いることにより、セクタサイズよりも大きなサイズを持つパケットを効率よく記録することができる。
【0031】
図1はまた、タイムマップ情報に関係したデータ構造も示している。以下、図1を用いてタイムマップ情報252内の各データの内容について説明する。
【0032】
図1(h)(i)に例示するように、ストリームオブジェクト(SOB)#B・299は複数のストリームブロック(SOBU)#α〜#γで構成されている。
【0033】
図1(h)(i)の例では、SOB#B・299を構成するストリームブロック(SOBU)#α〜#γ各々のデータサイズは2ECCブロックで構成され、32セクタ分のサイズを持っている。すなわち、タイムマップ情報252(図1(m))内の第1ストリームブロックサイズ261〜264(図1(l))は、それぞれ32セクタ(64kバイト)となる。
【0034】
SOB#B・299(図1(h))の先頭にあるストリームブロック(SOBU)#α(図1(i))はその先頭にセクタNo.1(図1(d))を持ち、セクタNo.1に含まれるデータエリアNo.1(図1(e)(f)(j))の先頭にはタイムスタンプ1a(図1(g)(k))が記録されている。
【0035】
また、SOB#B・299(図1(h))の後続ストリームブロック(SOBU)#β(図1(i))はデータエリアNo.33(図1(j))を持ち、データエリアNo.33にはタイムスタンプ33aを伴うトランスポートパケット33a(図1(k))が記録されている。
【0036】
図1(k)に示すように、ストリームブロック(SOBU)#αの最初のストリームデータ(トランスポートパケット1a)のタイムスタンプ値[0]はタイムスタンプ1aであり、次のストリームブロック(SOBU)#β内のストリームデータ(トランスポートパケット33a)のタイムスタンプ値[28]はタイムスタンプ33aとなっている。
【0037】
図1(l)の第1ストリームブロック時間差266の値[30]は、上記タイムスタンプ33aとタイムスタンプ1aとの差分値([28]−[0])を所定の有効桁数(ここでは有効1桁)で丸める(切り上げる)ことで与えられる([28]−[0]≒[30])。
【0038】
なお、図1(m)のタイムマップ情報252は、図15を参照して後述するストリームオブジェクト情報SOBI内のアクセスデータユニットAUDも含むものとして、取り扱かわれてもよい。このAUDに含まれる情報(アクセスユニット開始マップAUSM等)により、アクセスしたい情報(所望のIピクチャ情報など)を含むSOBUを特定できる。
【0039】
図1の表記方法では、ストリームオブジェクト#B299の先頭セクタのセクタ番号を1とし、順次セクタ番号を増加させている。セクタ番号とデータエリア番号は一致させ、それに合わせてタイムスタンプ番号とトランスポートパケット番号を設定している。すなわち33番目のセクタ内のデータエリア内に配置された最初のタイムスタンプとトランスポートパケットの組を”33a”とし、同一データエリア内の次の組を順次”33b”、”33c”、………と番号を設定する。ここで、トランスポートパケット32j、320kのように直前のデータエリアに入り切らずに次のデータエリアに跨ったタイムスタンプまたはトランスポートパケットの番号は、直前のデータエリア番号に合わせて表示している。また図1(k)の鍵括弧[]内はタイムスタンプの実際の値を例示している。
【0040】
図1(a)〜(c)に示すように、パックヘッダ(またはパケットヘッダ)11〜15内の情報において、セクタ内共通情報41としては、パックヘッダサイズ51、タイムスタンプサイズ52、トランスポートパケットサイズ53が記載されている。
【0041】
ここで、図1(d)のセクタNo.1の例を取れば、図1(b)の検索情報42の中でセクタ内の最初のタイムスタンプ値54とは、図1(k)のタイムスタンプ1a[=0]の値を意味する。また、検索情報42の中でセクタ内の最後のタイムスタンプ値55とは、タイムスタンプ1k(図示せず)の値を意味している。
【0042】
ところで、多くの辞書では各ページ毎に脚注もしくはヘッダ位置に該当ページ最初と最後の単語を記載して、検索を容易にしている。それと同様に、上記2個の情報(図1(a)に示す最初のタイムスタンプ値54と最後のタイムスタンプ値55)により、ストリームデータの検索を容易にしている。
【0043】
同一のタイムスタンプあるいはトランスポートパケットが隣接するセクタを跨いで配置され得るため、各セクタ毎に単独でアクセスした場合には、最初のタイムスタンプ位置情報が必要となる。図1(a)に示したファーストアクセスポイント56は、パケットヘッダ直後から数えた最初のタイムスタンプ位置までのビット数を意味している。しかし、この実施の形態ではそれに限らず、例えば最初のトランスポートパケット先頭位置までのビット数を(ファーストアクセスポイント56相当の)情報として持っても良い。
【0044】
この実施の形態では、ファーストアクセスポイント56の値としてデータエリアのサイズよりも大きな値を指定可能にすることで、セクタサイズよりも大きなサイズを有するパケットに対してもタイムスタンプ先頭位置を指定することができるようになっている。
【0045】
たとえば図1(d)〜(g)のデータ構造において、1個のパケットがセクタNo.1からセクタNo.2まで跨って記録され、そのパケットに対するタイムスタンプがNo.1のデータエリア内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタNo.2のデータエリア内のTビット目に配置されている場合を考える。
【0046】
この場合、セクタNo.1のファーストアクセスポイント56の値は”セクタNo.1のデータエリアサイズ+T”、セクタNo.2のファーストアクセスポイントの値は”T”となる。
【0047】
セクタNo.1のファーストアクセスポイント56の値としてセクタNo.1のデータエリアのサイズよりも大きな値に設定することにより、セクタNo.1内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が次以降のセクタに存在することが示される。
【0048】
セクタ単位での部分消去(図9参照)を行った場合には、次のセクタに跨らない実質的に有効なタイムスタンプとトランスポートパケットの組の最終位置情報57(図1(a))が必要となる。
【0049】
この実施の形態においては、完全な形で記録されている(他セクタへ跨って配置されない)タイムスタンプとトランスポートパケットの組数で記載されているが、それに限らず、例えば最終位置アドレスなどの情報を(最終位置情報57として)記録することも可能である。
【0050】
図1(a)(b)に示すように、箇々のトランスポートパケットに関するビットマップ情報43は、Iピクチャ位置フラグ58と、ピクチャ先頭位置フラグ59と、暗号情報60を含んでいる。図1(a)のIピクチャ位置フラグ58およびピクチャ先頭位置フラグ59の情報は、図5を参照して後述するランダムアクセスインジケータ303およびペイロードユニット開始インジケータ301の情報を利用して作成できる。また、暗号情報60には、コピープロテクトに利用される情報が適宜記録される。
【0051】
図1(b)のセクタ内共通情報41および検索情報42から、該当セクタ内のトランスポートパケット数が分かる。その各トランスポートパケット毎に配列順に1ビットずつ対応させ、条件に該当したトランスポートパケットに対して”1”のフラグを立てることができる。このフラグを立てた個々のトランスポートパケットに関するビットマップ情報43も、図1(b)(c)に示すように、パックヘッダ内に記録されている。
【0052】
デジタル放送では、映像情報はMPEG2の規格に従って圧縮された情報が転送されてくる。デジタル放送では図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb322のサイズが188バイト(または183バイト)の場合が多い。
【0053】
前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア内にはデジタル放送用のトランスポートパケットが10個前後記録できる。それに対してISDNなどのデジタル通信網では1パケットサイズが4096バイトもある大きなロングパケットが転送される場合がある。
【0054】
図1のデータ構造を採用すれば、デジタル放送などのように1個のデータエリア内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、1個のパケットを複数のデータエリアに連続して跨るように記録できる。デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック(図1(i)のSOBU)内に端数なく記録することができる。
【0055】
図2は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図2を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容(ファイル構造)について説明する。
【0056】
DVDーRAMディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、DVD_RTRディレクトリ(またはDVD_RTAV)102と言う名のサブディレクトリ101内に入っている。
【0057】
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とが格納される。
【0058】
また、データ本体(コンテンツ情報)として、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とが格納される。
【0059】
上記データファイル103を含むサブディレクトリ101の上位階層にあるルートディレクトリ100には、その他の情報を格納するサブディレクトリ110を設けることができる。このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットVIDEO_TS111、オーディオプログラムを収めたオーディオタイトルセットAUDIO_TS112、コンピュータデータ保存用のサブディレクトリ113等がある。
【0060】
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
【0061】
そのストリームデータそのものはSTREAM.VRO(またはSR_TRANS.SRO)106と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、STREAM.IFO(またはSR_MANGR.IFOとそのバックアップファイルSR_MANGR.BUP)105である。
【0062】
また、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である。
【0063】
図3は、この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【0064】
図3(a)の情報記憶媒体201の内周方向202の端部と外周方向203の端部とで挟まれた領域には、図3(b)に示すように、リードインエリア204と、ファイルシステム情報が記録されているボリューム&ファイル構造情報206と、データエリア207と、リードアウトエリア205が存在する。リードインエリア204はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア205は書替可能データゾーンで構成されている。データエリア207も書替可能データゾーンで構成されている。
【0065】
データエリア207内は、図3(c)に示すように、コンピュータデータとオーディオ&ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア208およびコンピュータデータエリア209の間に、オーディオ&ビデオデータエリア210が、挟まれる形態となっている。
【0066】
オーディオ&ビデオデータエリア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とが記録される。
【0067】
同じく図3(e)に示すように、ストリーム記録エリア222には、図2に示された、ストリーマのナビゲーションデータSTREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、トランスポートビットストリームデータSTREAM.VRO(SR_TRANS.VRO)106とが記録される。
【0068】
なお、図3(d)(e)では図示しないが、ストリーム記録エリア222には、図2に示したアプリケーション固有のナビゲーションデータSR_PRIVT,DAT/SR_PRIVT.BUP105aを記録することもできる。
【0069】
このSR_PRIVT,DAT105aは、ストリーマに接続(供給)された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
【0070】
ストリームデータに関する管理情報であるSTREAM.IFO(またはSR_MANGR.IFO)105は、図3(f)〜(i)に示すようなデータ構造を有している。
【0071】
すなわち、図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とで構成されている。
【0072】
図3(f)のストリームファイル情報テーブル(SFIT)232は、図3(g)に示すように、ストリームファイル情報テーブル情報(SFITI)241と、1以上のストリームオブジェクト情報(SOBI)#A・242、#B・243、………と、オリジナルPGC情報一般情報271と、1以上のオリジナルセル情報#1・272、#2・273、………とを含むことができるようになっている。
【0073】
図3(g)の各ストリームオブジェクト情報(たとえばSOBI#B・243)は、図3(h)に示すように、ストリームオブジェクト一般情報(SOBI_GI)251、タイムマップ情報252、その他を含むことができる。
【0074】
また、図3(g)の各オリジナルセル情報(たとえば#1・272;後述するが図14で示されるSCIに対応)は、図3(h)に示すように、セルタイプ281(後述するが図14で示されるC_TYに対応)と、セルID282と、該当セル開始時間(後述する図9(k)(l)、図14で示されるSC_S_APATに対応)283と、該当セル終了時間(後述する図9(k)(l)、図14で示されるSC_E_APATに対応)284と、エントリポイント情報(SC_EPI)285を含むことができる。
【0075】
エントリポイント情報(SC_EPI)285は、記録内容を部分的にスキップする道具として利用できる情報である。このエントリポイント情報(SC_EPI)285には、図14に示すように、プライマリテキスト情報(PRM_TXTI)の有無によって2つの形式(タイプAとタイプB)がある。
【0076】
ここで、エントリポイントとは、オリジナルPGCの場合はプログラム内に入る位置、またユーザ定義PGCの場合はプログラムの一部に入る位置を示すものである。各PGCは、自身のエントリポイントセットを持つことができる。これらのエントリポイントはセル情報(SCI)の一部として記録される。記録内容の再生時に記録内容の一部をスキップする場合に、これらのエントリポイントを用いることができる。
【0077】
全てのエントリポイントは、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間(APAT)により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図14のEP_APATにより示される。
【0078】
図3(g)のSOBI#Bに含まれる図3(h)のタイムマップ情報252は、図3(i)に示すように、ストリームブロック番号260、第1ストリームブロックサイズ261、第2ストリームブロックサイズ262、…と、第1ストリームブロック時間差266、第2ストリームブロック時間差267、…とを含むことができる。
【0079】
タイムマップ情報252を構成するストリームブロック時間差266の具体例については、図1(l)に示されている。タイムマップ情報252を構成する各ストリームブロック時間差の内容については、図8を参照して後述する。
【0080】
図4は、この発明の一実施の形態におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。以下、図4の例示を用いてSOBとPGCの関係を説明する。
【0081】
ストリームデータ(STREAM.VROまたはSR_TRANS.SRO)106内に記録されたストリームデータは、1個以上のECCブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等を行うことができる。このストリームデータは、記録する情報の内容毎(たとえばデジタル放送での番組毎)にストリームオブジェクトという纏まりを作る。
【0082】
STREAM.VRO(SR_TRANS.SRO)106内に記録されたストリームオブジェクト(SOB#A、SOB#B)毎の管理情報(オリジナルPGC情報233、ユーザ定義PGC情報テーブル234等)は、ナビゲーションデータSTREAM.IFO(SR_MANGR.IFO)105内に記録されている(図4の最下部および図3(e)(f)参照)。
【0083】
図4の各ストリームオブジェクト#A・298、#B・299毎の管理情報(STREAM.IFO105)は、図3(f)(g)に示したように、ストリームファイル情報テーブル(SFIT)232内のストリームオブジェクト情報(SOBI)#A・242、#B・243として記録されている。
【0084】
ストリームオブジェクト情報(SOBI)#A・242、(SOBI)#B・243それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報252を含んでいる。
【0085】
ストリームデータの再生時には、1個以上のセルの連続で構成されるプログラムチェーン(PGC)の情報(後述する図14のPGCI#iに対応)が利用される。このPGCを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
【0086】
PGCには、STREAM.VRO(SR_TRANS.SRO)106に記録された全ストリームデータを連続して再生することのできるオリジナルPGC290(図3(f)ではORG_PGCI・233)と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義PGC#a・293、#b・296(図3(f)ではUD_PGCIT・234の中身に対応)の2種類が存在する。
【0087】
オリジナルPGC290を構成するオリジナルセル#1・291、#2・292は、基本的にストリームオブジェクト#A・298、#B・299と一対一に対応して存在する。
【0088】
それに対して、ユーザ定義PGCを構成するユーザ定義セル#11・294、#12・295、#31・297は、1個のストリームオブジェクト#A・298または#B・299の範囲内では任意の位置を設定することができる。
【0089】
それぞれのセルの指定範囲は、開始時刻と終了時刻の時間指定により行うことができる。すなわち、部分消去あるいは編集がなされる前(ストリームデータの録画直後)のオリジナルセル#2・292の該当セルの開始時間283および該当セルの終了時間284(図3(h))の時間には、図1(k)の例に従えば、該当するストリームオブジェクト#B299内の最初のタイムスタンプ1aの値と最後のタイムスタンプ321aの値が使用される。
【0090】
それに対して、図4のユーザ定義セル#11・294での時間範囲指定は任意時刻を指定でき、指定されたトランスポートパケットに対応したタイムスタンプの値が、該当セルの開始時間および該当セルの終了時間の値に設定される。
【0091】
ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法としては、この実施の形態では
(1)各ストリームオブジェクトの記録開始位置からの累計記録データ量でアクセスする方法と;
(2)MPEG方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識してアクセスする方法と
の2通りが可能となっている。
【0092】
図1(g)から明らかなように全トランスポートパケットにはタイムスタンプ情報が付属記録されており、このタイムスタンプ情報を利用して各トランスポートパケットに対してアクセス可能となっている。
【0093】
情報記憶媒体としてDVD−RAMディスクを用いた場合には、それぞれ16セクタ毎にECCブロックが構成されている。そこで、この発明の実施の形態ではECCブロックの整数倍(例えば2倍)毎にストリームデータをグループ化し、各グループ毎の経過時間のテーブルを持つことで、上記(1)の「累計記録データ量でアクセスする」方法を可能にしている。上記(2)の「デコードタイミングを意識してアクセスする」方法については、図11の説明において詳述する。
【0094】
この発明の実施の形態では、各グループ毎の経過時間のテーブルをタイムマップ情報252としている。このタイムマップ情報252は、図3(g)(h)に示すように、それぞれのストリームオブジェクトに対応するストリームオブジェクト情報(#A・242;#B・243)の一部に記録されている。
【0095】
また、この発明の実施の形態では上記グループ(2ECCブロック毎にグループ化されたセクタ)をストリームブロック(あるいはSOBUというデータユニット)と呼ぶ(図4上段、あるいは図1(i)参照)。
【0096】
各ストリームブロック(SOBU)の先頭に配置されているセクタの開始位置には、タイムスタンプが配置されていない場合がある。この場合は、各ストリームブロック(SOBU)毎の経過時間の定義が難しい。
【0097】
その対応策としては、以下のものがある。
【0098】
A)各ストリームブロック毎の特定位置に配置されているタイムスタンプ値を、それぞれのストリームブロック固有時間とする。
【0099】
具体的には各ストリームブロック毎の最初に配置されている(しかも前のセクタから跨って記録されてない)タイムスタンプの値をそれぞれのストリームブロックの開始時刻とする。
【0100】
B)各ストリームブロック毎の固有時間(例えば開始時刻)間の差分時間を、各ストリームブロック毎の経過時間と定義する。
【0101】
C)上記経過時間(差分時間)情報をタイムマップ情報252に記録する。
【0102】
上記差分時間(経過時間)で表示する方がデータ量が少なくなるメリットがある。しかしこの発明の実施の形態ではそれに限らず、それぞれのストリームブロック固有時間をタイムマップ情報252に記録することも可能である。
【0103】
D)上記経過時間(差分時間)情報の丸め値をタイムマップ情報252に記録する。
【0104】
経過時間(差分時間)情報の計算結果を丸める(桁数の低い値を切り上げまたは四捨五入する)ことで桁数の低い値を省略し、この丸め値をタイムマップ情報252に記録することで、データサイズを少なくできる。
【0105】
E)部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つ。
【0106】
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図4のストリームブロック#μのように、2ECCブロック(32セクタ)で一定サイズ(64kバイト)のストリームオブジェクトユニット(SOBU)を、ストリームブロックとして採用するとよい。
【0107】
このようにストリームブロックを一定サイズ(たとえば2ECCブロック=32セクタ=64kバイト)のSOBUに固定すれば、次の利点が得られる:
(01)SOBU単位でストリームデータの消去あるいは書替を行っても、そのSOBUのECCブロックが、消去あるいは書替対象以外のSOBUのECCブロックに影響しない。そのため、消去あるいは書替に伴う(消去あるいは書替の対象でないSOBUに対する)ECCのデインターリーブ/インターリーブのやり直しが、生じない;
(02)任意のSOBU内部の記録情報に対するアクセス位置を、セクタ数(あるいはセクタ数に対応した他のパラメータ;たとえばストリームパックおよびその内部のアプリケーションパケット群の情報)で特定できる。たとえば、あるSOBU#k(図示せず)の中間位置にアクセスする場合は、SOBU#kー1とSOBU#kとの境界から16セクタ目(あるいは16セクタ目に対応するアプリケーションパケットの位置)を指定すればよい。
【0108】
図5は、デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
【0109】
デジタル放送では、MPEG2規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。デジタル放送では、図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb322のサイズが188バイト(または183バイト)の場合が多い。
【0110】
このトランスポートパケット内は、図5(b)に示すように、トランスポートパケットヘッダ311と、記録情報のデータ本体が記録されているペイロード312とで構成されている。
【0111】
トランスポートパケットヘッダ311は、図5(a)に示すように、ペイロードユニット開始インジケータ301、パケットID(PID)302、ランダムアクセスインジケータ303、プログラムクロックリファレンス504、再生タイムスタンプ(PTS)305等で構成されている。
【0112】
MPEG圧縮された映像情報は、Iピクチャ情報、Bピクチャ情報、およびPピクチャ情報を含んでいる。Iピクチャ情報が記録されている最初のトランスポートパケットには、図5(a)のランダムアクセスインジケータ303に”1”のフラグが立つ。また、各B、Pピクチャ情報の最初のトランスポートパケットには、図5(a)のペイロードユニット開始インジケータ301に”1”のフラグが立つ。
【0113】
これらのランダムアクセスインジケータ303およびペイロードユニット開始インジケータ301の情報を利用して、IピクチャマッピングテーブルおよびB、Pピクチャ開始位置マッピングテーブルの情報を作成することができる。
【0114】
たとえば、図5(a)に示したペイロードユニット開始インジケータ301に”1”のフラグが立ったトランスポートパケットに対して、B、Pピクチャ開始位置マッピングテーブル内の該当個所のビットが”1”になる。
【0115】
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図5(a)のパケットID(PID)302で識別される。このPID302の情報を用いて、ビデオパケットマッピングテーブルとオーディオパケットマッピングテーブルを作成することができる。
【0116】
図5(c)に示すように、デジタル放送では、1個のトランスポンダに複数の番組(この例では番組1〜番組3)がパケット化された形で時分割されて転送されてくる。たとえば、図5(b)のトランスポートパケットヘッダ311およびペイロード(記録情報)312の情報は、図5(c)に示される番組2のトランスポートパケットb322、トランスポートパケットe325により転送される。
【0117】
IEEE1394では、図5(e)(f)に示すように、各IEEEアイソクロナス・ヘッダ343、344は、アイソクロナスパケットヘッダ351およびコモン・アイソクロナスパケットヘッダ352を含む。このコモン・アイソクロナスパケットヘッダ352内には、フォーマット依存のリザーブ領域が設定されている。
【0118】
この発明の実施の形態では、図5(g)に示すように、コモン・アイソクロナスパケットヘッダ352内のフォーマット依存のリザーブ領域に、ソースID361と、データブロックサイズ情報362と、Iピクチャ開始位置フラグ363が格納される。このようにフォーマット依存のリザーブ領域にIピクチャ開始位置フラグ363を設定することで、ストリームデータをアイソクロナス・モードで転送する時に同時にリアルタイムでストリームデータ内のIピクチャ位置指定(すなわちIピクチャの開始位置に該当するトランスポートパケットの指定)も行えるようにしている。ここに、この実施の形態の大きな特徴がある。
【0119】
なお、図5(h)において、アプリケーションパケットエリアの末尾に番組2のトランスポートパケットbの前半部346が記録されるのではなく、このアプリケーションパケットエリアの末尾が余白となる場合もある。この場合は、アプリケーションパケットエリアの末尾は部分パケットではなく、予約バイト数のスタッフィングエリア(その先頭にタイムスタンプはない)となる。
【0120】
また、通常のパケットにはタイムスタンプが付いているが、図5(i)に示すように、部分パケットではタイムスタンプを省略することができる。
【0121】
このようにすると、2つの隣接ストリームパック(図5(j))の境界で分断された部分パケット(パケット1つあたり188バイトとすれば部分パケットのサイズは1〜187バイト;平均して100バイト弱)を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分(タイムスタンプ1つあたり例えば4バイト)、媒体201に対する記憶容量を増やすことができる。
【0122】
また、図5(i)の先頭部分パケットの直後にくるタイムスタンプの位置は、図1(a)のファーストアクセスポイント56、あるいは図10(c)のFIRST_AP_OFFSETにより、特定することができる。
【0123】
図6は、ストリームオブジェクトのデータを格納するセクタ構造を説明する図である。
【0124】
図6(a)〜(d)は、図1(h)〜(k)に相当する内容を示している。図6の例では、全てのストリームブロック(SOBU)#α〜#γが一定サイズ(32セクタ/2ECCブロック=64kバイト)で構成されている。そのうち、ストリームブロック(SOBU)#γの最終セクタNo.n、およびその1つ手前のセクタNo.nー1(図6(e))を構成するパック構造が、図6(f)〜(j)に例示されている。
【0125】
ストリームブロック(SOBU)#γの各セクタは、最終セクタNo.nを除き、同様なデータ構造を持っている。たとえばセクタNo.nー1についていうと、図6(f)に示すようになっている。
【0126】
すなわち、セクタNo.nー1は2048バイト(2kバイト)のストリームパックにより構成される。このストリームパックは、14バイトのパックヘッダと、2034バイトのストリームPESパケットとで構成される。
【0127】
ストリームPESパケットは、6バイトのPESヘッダと、1バイトのサブストリームIDと、2027バイトのストリームデータエリアとで構成される。
【0128】
ストリームデータエリアは、9バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、アプリケーションパケットエリアとで構成される。
【0129】
図6(f)のアプリケーションパケットエリアは、図5(h)(i)に示したものと同様に構成できる(図5(h)(i)のパケットを図6ではアプリケーションパケットに読み替える)。
【0130】
アプリケーションパケットエリアは、各々が(図5(h)のスタッフィングエリアおよび図5(i)の部分パケットを除き)アプリケーションタイムスタンプ(ATS)を先頭に持つアプリケーションパケット群で構成される。たとえば188バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、10個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
【0131】
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ(たとえば2048バイト)を持つものとして扱うことができる。図6(f)のスタッフィングバイトは、ストリームパックを常に所定長(2048バイト)に保つために利用できる。
【0132】
ストリームブロック(SOBU)#γの最終セクタNo.nは、図6(g)〜(j)に示すようになっている。すなわち、図6(g)に示すように最終セクタNo.nはパックヘッダおよびパディングパケットにより構成される。このパディングパケットは、図6(h)に示すように、そのアプリケーションパケットエリアにパディングエリア21(図1(k)のパディングエリア21に対応)を含む。
【0133】
パディングエリア21内で最初のアプリケーションパケットエリア(先頭スタッフィングパケット)の場合は、図6(i)に示すように、アプリケーションタイムスタンプ(ATS)付きのスタッフィングパケット(実質的な記録内容を持たないゼロバイトデータ)で埋められる。もしパディングエリア21が複数セクタ分の長さを持つときは、パディングエリア21内で2番目以降のアプリケーションパケットエリア(後続スタッフィングパケット)は、図6(J)に示すように、ATSなしのスタッフィングパケット(ゼロバイトデータ)で埋められる。
【0134】
ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報(図3(h)の252;あるいは後述する図15のSOBI内MAPL)の回復(再生)を確実にするために、スタッフィングが必要になる。図6(i)(j)のスタッフィングパケットは、そのための概念的な単位として定義されている。
【0135】
このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。
【0136】
スタッフィングパケットには、以下の条件が付く:
*1または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する;
*1または複数のスタッフィングパケットは、1つの4バイトATSと、該当SOBUの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ(ATSの後に続く)とで構成される。いま、SOBU1個あたりのセクタ数をSOBU_SIZとしたときに、0≦n≦SOBU_SIZー1とすれば、スタッフィングパケットの全長は、「4+2014+n×2018」バイトとなる。
【0137】
スタッフィングパケットのATSは、次のように設定される:
*少なくとも1個のパックが実際のアプリケーションパケットデータを含んでいるSOBU内では、スタッフィングパケットのATSは、スタッフィングパケットに先行するアプリケーションパケットのATSに設定される;
*実際のアプリケーションパケットデータを含まないSOBU内では、スタッフィングパケットのATSはタイムマップ情報等の内容に応じて決定される。
【0138】
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される:
*パックヘッダのSCRは、先行パックのSCRに「2048×8ビット÷10.08Mbps」を加えたものとする;
*PESパケットヘッダおよびサブストリームIDは、他の全てのPESパケットに対するものと同じにする;
*アプリケーションヘッダ(図10(c)(d)参照)内において、AP_Ns=0、FIRST_AP_OFFSET=0、EXTENSION_HEADER_IFO=00b、SERVICE_ID=0(アプリケーションヘッダ内のその他のパラメータも0)とする。
【0139】
図7は、MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
【0140】
図7に示すように、デジタルTVでの放送信号情報にはMPEG2と呼ばれる信号圧縮方法が採用されている。MPEGによる信号圧縮方法では、TV表示用の各画面(ピクチャ)は時間差分情報を含まないIピクチャ501と時間差分情報を含むBピクチャ503、504およびPピクチャ502に分類される。
【0141】
Iピクチャは前後の画面(ピクチャ)情報の影響を受けることなく単体で存在し、1枚の画面(ピクチャ)に対してDCT変換後、量子化した情報がIピクチャ圧縮情報511となり、Iピクチャ情報521として記録される。Pピクチャ502はIピクチャ501に対する差分情報512のみがPピクチャ情報522として記録される。また、Bピクチャ503はIピクチャ501とPピクチャ502に対する差分情報513、514がBピクチャ情報523として記録され、Bピクチャ504はIピクチャ501とPピクチャ502に対する差分情報515、516がBピクチャ情報524として記録される。
【0142】
図7に示すように、Iピクチャ501の圧縮情報511はIピクチャ情報521としてトランスポートパケット1a、1b、…に記録され、Bピクチャの差分情報513、514はBピクチャ情報523としてトランスポートパケット33a、…に記録され、Bピクチャの差分情報515、516はBピクチャ情報524としてトランスポートパケット41d、…に記録され、Pピクチャ差分情報512はPピクチャ情報522としてトランスポートパケット(TP)48h〜298gに記録される。このように各I、B、Pピクチャ情報は異なるトランスポートパケットに記録されている。
【0143】
映像再生時には、Pピクチャ502あるいはBピクチャ503、504単体では画面を生成することができず、必ずIピクチャ501画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報521〜524は1個または複数のトランスポートパケット内のペイロードに分割記録されている。このとき、各ピクチャ情報521〜524の境界位置とトランスポートパケット間の境界位置は、図7に示されるように、常に一致するように記録される。
【0144】
Iピクチャ情報521が記録されている最初のトランスポートパケット1aには、そのランダムアクセスインジケータ303(図5(a))に”1”のフラグが立つ。また、各B、Pピクチャ情報523、524、522の最初のトランスポートパケット33a、41d、48hには、そのペイロードユニット開始インジケータ301(図5(a))に”1”のフラグが立つ。このランダムアクセスインジケータ303とペイロードユニット開始インジケータ301の情報を利用して、図1(a)のIピクチャ位置フラグ58とピクチャ先頭位置フラグ59の情報が作成される。同様に、個々のトランスポートパケットに関するビットマップ情報43(図5(b))としてコピープロテクトに利用する暗号情報60などの情報も記録される。
【0145】
図7のIピクチャ(501)の位置情報(Iピクチャ位置情報)は、図3(g)(h)に示すようにオリジナルセル情報(SCI)(#1・272等)内にエントリポイント情報(SC_EPI)285として記録されている。
【0146】
エントリポイント情報285内のデータ構造は、図7(a)(b)に示すように、同一ストリームオブジェクト内に存在する個々のIピクチャ位置情報を示すエントリポイント位置(第1エントリポイント位置(EP_APAT)531、第2エントリポイント位置532、第3エントリポイント位置533、…、最終エントリポイント位置535)の情報の羅列記載形式になっている。
【0147】
またエントリポイント位置(EP_APAT)531の情報内容としては、図7(a)に示すように、Iピクチャ情報521の最初の情報が記録されているトランスポートパケット1aに対応したタイムスタンプ1aの値が記録されている。個々のエントリポイント位置(EP_APAT)532、533、535の情報内容も、同様に、それぞれの対応Iピクチャ情報の最初の情報が記録されているトランスポートパケットに対応したタイムスタンプ87f、183d、298gの値が記録される。
【0148】
図4に示した例えばユーザ定義セル#11・294に対する該当セルの開始時間および/または該当セルの終了時間の情報は、図3(f)のユーザ定義PGC情報テーブル234内に記録されている。この場合に、図7のBピクチャ情報524から再生したい場合には、該当セルの開始時間としてタイムスタンプ41dを設定することができる。このように、該当セルの開始時間あるいは該当セルの終了時間の情報は、Iピクチャ位置に関わりなく任意のタイムスタンプ情報で設定できる。
【0149】
一方、この実施の形態におけるストリームオブジェクトの開始/終了時刻は、Iピクチャ位置を意識して設定される。すなわち、図3(h)および図7(d)に示したストリームオブジェクト一般情報251の情報内容としては、図7(c)に示すように、録画開始時間を示す記録時間(SOB_REC_TM)541と、ストリームオブジェクト開始時間(SOB_S_APAT)542と、ストリームオブジェクト終了時間(SOB_E_APAT)543が記録されている。
【0150】
このストリームオブジェクト開始時間(SOB_S_APAT)542は、必ず、Iピクチャ情報521の先頭が記録されているトランスポートパケット1aに対応したタイムスタンプ1aの値に設定される必要がある。同様に、ストリームオブジェクト終了時間(SOB_E_APAT)543は、Iピクチャ情報の直前のトランスポートパケット298gに対応したタイムスタンプ298gの値に設定される必要がある。
【0151】
図7のトランスポートパケットがストリーマ(後述する図11の光ディスク装置415)に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ(ATS)というタイムスタンプ付きのパケット(アプリケーションパケット)に移し替えられる。
【0152】
そして、ATS付きアプリケーションパケットの一群(通常10パケット前後)がストリームPESパケット内のアプリケーションパケットエリアに格納される。
【0153】
このストリームPESパケットにパックヘッダを付したものが、1つのストリームパックになる。ストリームPESパケットは、PESヘッダと、サブストリームIDと、アプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、上記ATS付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで構成される。
【0154】
図8は、図1その他で示されるタイムマップ情報252の設定方法を説明する図である。
【0155】
図1(g)あるいは図8(b)に示したようにタイムスタンプ(TMS)およびトランスポートパケット(TP)(またはアプリケーションパケットAP)を順次詰めて記録してあるストリームデータに対して、図8(a)のように例えば2ECCブロック(32セクタ)毎に区切って、ストリームブロック(SOBU)#α、#β、#γ、〜#λを構成する。
【0156】
ストリームブロック(SOBU)#αの先頭位置には、タイムスタンプ(TMS)1aが配置されている。このタイムスタンプ1aは、SOBU#αの先頭パケットの到着時間(SOBU_S_APAT)を示している。このタイムスタンプ1aの値[0]が、SOBU#αの開始時刻になる。
【0157】
他のストリームブロック(SOBU#β〜SOBU#λ)に対しては、前のセクタから跨って記録されないという条件の下で、最初に配置されたタイムスタンプ33a、65a、98a、…321aの値([28]、[63]、[98]、[297])が、各ストリームブロック(SOBU#β〜SOBU#λ)の開始時刻とされる。
【0158】
各ストリームブロック、たとえば最後のSOBU#λの、最終パケットの直前にある最後のタイムスタンプ300aは、SOBU#λの最終パケットの到着時間(SOBU_E_APAT)を示している。このタイムスタンプ300aの値[300]が、SOBU#λの終了時刻になる。
【0159】
なお、最後のSOBU#λの末尾に余白が生じるときは、この余白は実データのないパディングエリア21(図1(k)あるいは図6(h)〜(j)参照)とされる。
【0160】
図8(b)に示すように、各ストリームブロック(SOBU#α〜SOBU#λ)それぞれの開始時刻を、0、28、63、98、…297とする。これらの時刻は、(a)秒単位、(b)フィールドあるいはフレーム/ピクチャ数(例えばNTSCでは30ピクチャ/秒、60フィールド/秒、PALでは25ピクチャ/秒、50フィールド/秒)、および(c)27MHzあるいは90kHzの基準クロックによるカウント数のうちの、いずれかで表示できる。
【0161】
図8(a)(b)の例示では、最初のストリームブロック(SOBU#α)の経過時間は[28]−[0]=[28](有効数2桁)であるが、この経過時間の表現はもっと粗くても実用性は損なわれないので、この経過時間値[28]の
1桁目を丸め(切り上げ)て、[30]としている。
【0162】
2番目のストリームブロック(SOBU#β)の経過時間は、上記丸め計算結果[30]を用いると[63]−[30]となるが、同様に1桁目を丸め(切り上げ)て[40]とする。以下同様に後続ストリームブロック(SOBU#γ〜SOBU#λ)の経過時間は有効数1桁に丸めた(切り上げた)数値で表現される。
【0163】
なお、ストリームブロック(SOBU#λ)以降へはアクセスしないので、図8(c)のように、最後のストリームブロックに対する時間差値をあえてブランクにしている。
【0164】
以上の丸め計算の結果とタイムマップ情報252との関係は、図8(c)に示されている。
【0165】
ところで、ストリームブロック(SOBU#λ)以降のストリームブロックは存在しないので、他のストリームブロックと同様な差分時間計算は行えない。そこで、この実施の形態では、最後のストリームブロック(SOBU#λ)だけは、その中で最後に記録されたタイムスタンプの値(図8(b)の例ではタイムスタンプ300aの値[300])と最後のストリームブロック(SOBU#λ)内で最初に記録されたタイムスタンプの値(図8(b)の例ではタイムスタンプ321aの値[297])との間の差分を計算し、切り上げした値を時間差値に設定する方法も可能にしている。これを図8(d)に示す。
【0166】
なお、図8(d)の最後のSOBU#λの時間差値計算方法は、2つの考え方が可能である。第1は、最後のタイムスタンプ300a(SOBU#λのSOBU_E_APAT)の丸める前の値[300]と最初のタイムスタンプ321aの丸める前の値[297]を用い、その差分結果[3]を切り上げ丸めして時間差値[10]を求める方法である。第2は、最後のタイムスタンプ300aの丸め値[300]と最初のタイムスタンプ321aの丸め値[300]を用い、その差分結果[0]に丸め誤差分[10]を加えて時間差値[10]を求める方法である。
【0167】
第2の方法では、全ての数値の末尾1桁にある「0」を取り除いた有効桁数1で数値を纏め、丸め誤差分を[1]とし、その他の数値の末尾1桁をそれぞれ削除して考えることもできる。
【0168】
図9は、記録済みのストリームオブジェクトの一部を部分的に消去した場合において、消去前後で、ストリームオブジェクト情報およびオリジナルセル情報がどのように変化するかを説明する図である。
【0169】
前述した一連の情報記載方法は、部分消去されたストリームオブジェクトに対しても適応できる。図9(k)は部分消去前の状態であり、録画直後のストリームオブジェクト(図1(h)その他のSOB#B・299)に関するストリームデータ構造およびオリジナルセル範囲、ストリームオブジェクト範囲は、図9(a)〜(e)に示すようになっている。
【0170】
以下、実表示範囲としてタイムスタンプ97cからタイムスタンプ224kまでの範囲を除いて、その範囲の前後を部分消去した後の処理を説明する。
【0171】
この実施の形態においては、セクタ単位で部分消去が行なわれる。しかし部分消去後のストリームオブジェクトの再生を行った直後に別のストリームオブジェクトの再生を行い、しかもそれらのストリームオブジェクトの繋ぎ目で画面の乱れを生じさせることなくシームレス再生を可能にするには、MPEGビットストリームのGOP境界位置を保持したまま部分削除を行う必要がある。
【0172】
タイムスタンプ97cに対応したトランスポートパケット97cの直前のIピクチャ先頭位置が図7(a)の第2エントリポイント位置532に示すようにトランスポートパケット87fに存在するとする。この場合、トランスポートパケット87fを含むセクタNo.87を残し、その前のセクタ以前の全セクタを部分消去し、このタイムスタンプ87fの値を部分消去後のストリームオブジェクトのストリームオブジェクト開始時間(SOB_S_APAT)542とする(図9(l)参照)。
【0173】
その結果、たとえば元には32セクタあったストリームブロック#γのサイズが30セクタに減少する。
【0174】
同時に、それに対応してタイムマップ情報252内に記載されるストリームブロック時間差の値も、たとえば40から30へと減少する。ストリームブロック#δ〜#ηの境界位置は部分消去前後で不変に保たれるので、その部分に関係したタイムマップ情報252内情報は変化しない。
【0175】
図7では省略したがIピクチャ先頭位置がトランスポートパケット225eから始まるとすれば、トランスポートパケット225dを含む図9(i)のセクタNo.225まで残し、それ以降の全セクタを消去する。
【0176】
図9(j)のストリームオブジェクト終了時間(SOB_E_APAT)543は、上記トランスポートパケット225dのタイムスタンプ225dにより設定できる。
【0177】
部分消去後の該当セルの開始時間(SC_S_APAT)283/終了時間(SC_E_APAT)284は、図9(i)に示すように、部分消去の実指定範囲に合わせて、タイムスタンプ97c、タイムスタンプ224kとされる。
【0178】
このような方法でタイムマップ情報(あるいはストリームオブジェクト情報SOBI/オリジナルセル情報SCI)が作成される所にこの実施の形態の特徴がある。
【0179】
なお、部分消去前後で開始時間および/または終了時間は変化するが、SOBUサイズは不変(たとえば32セクタ分64kバイト一定)に保たれる。
【0180】
部分消去時はSOBU単位の消去を行なうことも可能であり、この場合は、オリジナルセル内で最初の(または最後の)タイムスタンプTMSは、必ず、SOB内最初の(または最後の)SOBU内に含まれるようになる。
【0181】
図10は、図5その他に示されるストリームパックのデータ構造を説明する図である。
【0182】
各ストリームパックは、図10(d)に示すようなデータ構造を持っている。すなわち、14バイトのパックヘッダ11と、6バイトのPESヘッダ601と、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、必要に応じて用いられるオプションのアプリケーションヘッダエクステンションと、必要に応じて用いられるオプションのスタッフィングバイトと、アプリケーションタイムスタンプATSが付されたアプリケーションパケットを1以上含むアプリケーションパケット群とで、1つのストリームパックが構成される(図6(f)参照)。
【0183】
パックヘッダ11は、図10(g)に示すように、パック開始コードの情報、システムクロックリファレンス(SCR)ベースの情報、SCRエクステンションの情報、プログラム多重化レートの情報、パックスタッフィング長の情報等を含んでいる。SCRベースは32ビットで構成され、その32ビット目はゼロとされる。また、プログラム多重化レートとしては、たとえば10.08Mbpsが採用される。
【0184】
PESヘッダは、図8(f)に示すように、パケット開始コードプリフィックスの情報、ストリームID(プライベートストリーム2)の情報、PESパケット長の情報を含んでいる。
【0185】
また、サブストリームIDは、図8(f)に示すように、ストリーム記録データを特定する内容を持つ。具体的には、サブストリームID=”00000010b”によって、そのストリームパックに格納されたデータがストリーム記録データであることが示される。このストリームIDが”10111110b”のときは、そのストリームパックがパディングパケット(図6(g)参照)に用いられるものであることが示される。
【0186】
図10(d)のアプリケーションヘッダは、図10(c)に示すように、バージョン情報、アプリケーションパケット数AP_Ns、先頭アプリケーションパケットのタイムスタンプ位置FIRST_AP_OFFSET、エクステンションヘッダ情報EXTENSION_HEADER_IFO、サービスID等を含んでいる。
【0187】
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
【0188】
アプリケーションヘッダのAP_Nsは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にATSの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
【0189】
FIRST_AP_OFFSETには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、FIRST_AP_OFFSETには「0」が記述される。
【0190】
EXTENSION_HEADER_INFOには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かが、記述される。
【0191】
EXTENSION_HEADER_INFOの内容が00bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
【0192】
EXTENSION_HEADER_INFOの内容が10bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
【0193】
EXTENSION_HEADER_INFOの内容が11bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
【0194】
EXTENSION_HEADER_INFOの内容が01bとなることは禁止されている。
【0195】
アプリケーションパケットエリアの前のスタッフィングバイト(オプション)は、「EXTENSION_HEADER_INFO=11b」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
【0196】
SERVICE_IDには、ストリームを生成するサービスのIDが記述される。このサービスが未知のものであれば、SERVICE_IDに0x0000が記述される。
【0197】
図10(c)のFIRST_AP_OFFSETは、図10(b)あるいは図1(a)のファーストアクセスポイント56に相当する。このファーストアクセスポイント56は、図10(a)に示すように、パックヘッダ(またはアプリケーションヘッダ)内の検索情報42(図1(b)参照)内に格納される。
【0198】
図10(d)のスタッフィングバイトおよびアプリケーションパケット群は、図6(f)で示したように、アプリケーションパケットエリアを構成している。このアプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録される。その後に、アプリケーションタイムスタンプATSとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録される。そして、図5(h)で示したように、アプリケーションパケットエリアの末尾に、部分アプリケーションパケット(または予約バイトのスタッフィングエリア)が記録される。
【0199】
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在でき、アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
【0200】
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ(ATS)は、32ビット(4バイト)で構成される。このATSは、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0201】
図10(d)において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを(前述したEXTENSION_HEADER_INFOにおいて)記述できるように定義されいる。
【0202】
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
【0203】
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。
【0204】
図1(g)に示した2つのトランスポートパケット1k、あるいは図5(h)(i)に示した部分アプリケーションパケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
【0205】
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
【0206】
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
【0207】
アプリケーションヘッダエクステンション(オプション)はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する1バイト長の1エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
【0208】
なお、1バイトのアプリケーションヘッダエクステンション(オプション)には、図10(e)に示すように、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが記述される。
【0209】
AU_STARTが”1”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0210】
図10のパケット構造は、該当ストリームオブジェクト(SOB)の最終セクタ以外に適用できるが、その最終セクタには必ずしも適用されない。最終セクタに対しては、図6(i)(j)のパケット構造が適用される。
【0211】
図11は、この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。この実施の形態では、情報記憶媒体201として、DVD−RAMディスクのような記録/再生可能光ディスクを想定している。
【0212】
以下、図11を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。
【0213】
このストリームデータ記録再生装置は、光ディスク装置415、STB装置416およびその周辺機器から構成される。
【0214】
周辺機器としては、ビデオミキシング部405、フレームメモリ部406、外部スピーカ433、パーソナルコンピュータ(PC)435、モニタTV437、D/Aコンバータ432、436、I/F部431、434等がある。
【0215】
光ディスク装置415は、ディスクドライブを含む記録再生部409と、記録再生部409へのストリームデータ(あるいは記録再生部409からのストリームデータ)を処理するデータプロセサ部(以下D−PRO部と略記する)410と、D−PRO部410からオーバーフローしてきたストリームデータを一時記憶する一時記憶部411と、記録再生部409およびD−PRO部410の動作を制御する光ディスク装置制御部412とを備えている。
【0216】
光ディスク装置415はさらに、STB装置416からIEEE1394等を介して送られてきたストリームデータを受ける(あるいはIEEE1394等を介してSTB装置416へストリームデータを送る)データ転送インターフェース部414と、データ転送インターフェース部414で受けたストリームデータを情報記憶媒体(RAMディスク)201に記録する信号形式に変換する(あるいは媒体201から再生されたストリームデータをIEEE1394等の信号形式に変換する)フォーマッタ/デフォーマッタ部413とを備えている。
【0217】
データ転送インターフェース部414のIEEE1394受信側は、基準クロック発生器(システムタイムカウンタSTC)440のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。
【0218】
上記時間情報に基づいて、ストリームデータをストリームブロック毎(あるいはSOBU毎)に切り分ける区切り情報が作成されるとともに、この区切り情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはPGCの切り分け情報が作成される。
【0219】
フォーマッタ/デフォーマッタ部413は、STB装置416から送られてきたストリームデータをストリームパックの列(図5(j)等参照)に変換し、変換されたストリームパック列をD−PRO部410へ入力する。入力されたストリームパックは、セクタと同じ2048バイトの一定サイズを持っている。D−PRO部410は、入力されたストリームパックを16セクタ毎にまとめてECCブロックにして、記録再生部409へ送る。
【0220】
ここで、記録再生部409において媒体201への記録準備ができていない場合には、D−PRO部410は、記録データを一時記憶部411に転送して一時保存し、記録再生部409においてデータ記録準備ができるまで待つ。
【0221】
記録再生部409において記録準備ができた段階で、D−PRO部410は、一時記憶部411に保存されたデータを記録再生部409に転送する。これにより、媒体201への記録が開始される。一時記憶部411に保存されたデータの記録が済むと、その続きのデータはフォーマッタ/デフォーマッタ部413からD−PRO部410へシームレスに転送されるようになっている。ここで、一時記憶部411は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
【0222】
なお、フォーマッタ/デフォーマッタ部413を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器(STC)440から得ることができる。また、フォーマッタ/デフォーマッタ部413を介して再生ビットストリームから取り出されたタイムスタンプ情報(SCR)は、STC440にセットすることができる。
【0223】
情報記憶媒体201に記録されたストリームデータ内のパックヘッダには、基準クロック(システムクロックリファレンスSCR)が記録されている。この媒体201に記録されたストリームデータ(SOBまたはSOBU)を再生する場合において、基準クロック発生器(STC)440は、媒体201から再生された基準クロック(SCR)に適合される(SCRの値がSTC440にセットされる)。
【0224】
つまり、SOBあるいはSOBUのデータを再生するために、ストリーマ(光ディスク装置415)内の基準クロック(STC440)を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスSCRに合わせる。その後は、STC440のカウントアップが自動的に行われる。
【0225】
STB部416は、衛星アンテナ421で受信したデジタル放送電波の内容を復調し、1以上の番組が多重化された復調データ(ストリームデータ)を提供するデモジュレータ422と、デモジュレータ422で復調されたデータから(ユーザが希望する)特定番組の情報(図5を例に採れば、番組2のトランスポートパケット)を選択する受信情報セレクタ部423とを備えている。
【0226】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を情報記憶媒体201に記録する場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部420を介して、IEEE1394転送により、光ディスク装置415のデータ転送インターフェイス部414に送る。
【0227】
光ディスク装置415内のデータ転送インターフェイス部414では、IEEE1394で転送されてきたストリームデータが図5(d)の形に一旦戻され、図5(d)の形のタイムスタンプとトランスポートパケットの組が、情報記憶媒体201上に順次詰めて記録される。
【0228】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を記録することなく単に視聴するだけの場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部402の多重化情報分離部425に送る。
【0229】
一方、情報記憶媒体201に記録された番組を再生する場合、IEEE1394のシリアルバスを介して光ディスク装置415からSTB装置416に送られてきたストリームデータは、セレクタ部423を介してデコーダ部402の多重化情報分離部425に送られる。
【0230】
多重化情報分離部425は、セレクタ部423から送られてきたストリームデータに含まれる各種パケット(ビデオパケット、オーディオパケット、サブピクチャパケット)を、内部メモリ部426上で、各パケットのIDにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部(ビデオデコード部428、サブピクチャデコード部429、オーディオデコード部430に分配する。
【0231】
ビデオデコード部428は、多重化情報分離部425から送られてきた(MPEGエンコードされた)ビデオパケットをデコードして、動画データを生成する。その際、MPEGビデオデータ中のIピクチャから記録内容を代表する縮小画像(サムネールピクチャ)を生成する機能を持たせるために、ビデオデコード部428は、代表画像(サムネール)生成部439を内蔵している。
【0232】
ビデオデコード部428でデコードされた動画(および/または生成部439で生成された代表画像)と、サブピクチャデコード部429でデコードされたサブピクチャ(字幕、メニュー等の情報)と、オーディオデコード部430でデコードされた音声とは、ビデオプロセサ部438を介してビデオミキシング部405へ送出される。
【0233】
ビデオミキシング部405は、フレームメモリ部406を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、D/A変換器436を介してアナログ映像化され、モニタTV437に送られる。
【0234】
また、ビデオミキシング部405からのデジタル映像は、I/F部434およびIEEE194等の信号ラインを介して、パーソナルコンピュータ435等に取り込むことができるようになっている。
【0235】
一方、オーディオデコード部430でデコードされたデジタルオーディオ情報は、D/A変換器432および図示しないオーディオアンプを介して、外部スピーカ433に送られる。また、デコードされたオーディオ情報は、I/F部431を介して外部にデジタル出力される。
【0236】
なお、STB装置416内の動作タイミングは、システムタイムカウンタ(STC)部424からのクロックにより決定される。
【0237】
上述したSTB制御部404による指示等(STB装置416の内部構成各々の動作制御)は、プログラムメモリ部404aに格納された制御プログラムにより実行される。その際、STB制御部404による制御過程においてワークメモリ部407が適宜利用される。
【0238】
このSTB制御部404およびデコーダ部402を含めSTB装置416の内部動作のタイミングは、STC部424からのクロックで規制できる。また、光ディスク装置415のSTC440とSTB装置416のSTC部424を同期させることで、光ディスク装置415およびSTB装置416を含めたストリーマシステム全体の動作タイミングを規制できる。
【0239】
STC440とSTC部424を同期させる方法としては、データ転送インターフェース部414とデータ転送インターフェース部420との間で受け渡されるストリームデータ中の基準クロック(SCR)により、STC440およびSTC部424をセットする方法がある。
【0240】
図11の光ディスク装置415(ストリーマ)では、タイムスタンプとトランスポートパケットとの組(図5(h)(i))がそのままの形で情報記憶媒体201上に記録される。
【0241】
ユーザが例えば図5(c)の第2の番組を情報記憶媒体(図3(a)の201)に記録しようとする場合には、図11に示すSTB装置416内の受信情報セレクタ部423において、番組2のトランスポートパケットb、eのみが抽出される。そのとき、STB装置416では、図5(d)に示すように、各トランスポートパケットb522、e525を受信した時刻情報がタイムスタンプ331、332の形で付加される。
【0242】
その後、IEEE1394の転送方式を用いて図11のフォーマッタ/デフォーマッタ部413にデータを転送する場合には、図5(e)に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。
【0243】
図11のフォーマッタ/デフォーマッタ部413では、STB装置416からIEEE1394で転送されてきたストリームデータが、図5(d)の形(図1(g)の形に相当)に一旦戻される。そして、図5(d)の形式のビットストリーム(図5(j)のストリームパック列)が、情報記憶媒体201に記録される。具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとPESヘッダが配置される(図5(j)等参照)。
【0244】
データエリア(図1(f))には複数のタイムスタンプおよびトランスポートパケット(図1(g))が逐次詰め込まれるが、1個のトランスポートパケット(図1(g)ではパケット1k;図5(d)では番組2のパケットb)が複数のセクタ(図1(e)ではNo.1とNo.2;図5(h)(i)では部分パケット)に跨って記録されことも可能になっている。ここに特徴の1つがある。
【0245】
この特徴を生かしたデータ構造を用いることにより、セクタサイズ(例えば2048バイト)よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
【0246】
デジタル放送では図5(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb・522のサイズが188バイト(または183バイト)の場合が多い。前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア(図1(f))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。
【0247】
デジタル放送などのように1個のデータエリア(図1(f))内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリアに連続して跨るように記録する。そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
【0248】
図11の装置構成を機能別にみると、STB装置416内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割/分類できる。
【0249】
ここで、「受信時刻管理部」は、デモジュレータ(復調部)422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等で構成される。この「受信時刻管理部」は、衛星アンテナ421でデジタルTV放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。
【0250】
「ストリームデータ内容解析部」は、多重化情報分離部425、STB制御部404等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、I,B,Pの各ピクチャ位置および/またはPTS値を抽出する。
【0251】
「ストリームデータ転送部」は、多重化情報分離部425、受信情報セレクタ部423、STB制御部404、データ転送インターフェース部420等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置415へ転送する。
【0252】
「時間関連情報生成部」は、多重化情報分離部425、STB制御部404、データ転送インターフェース部420等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻(タイムスタンプ)情報と「ストリームデータ内容解析部」で抽出した表示時刻情報(PTS値および/またはフィールド数)との間の関係情報を作成する。
【0253】
次に、図11の装置におけるストリームデータ録画時の処理について説明する。図5(c)に示すように、デジタル放送では1個のトランスポンダ内に複数番組情報が時分割多重化されている。その情報に対して受信情報セレクター部423内で図5(d)に示すように特定番組のみのトランスポートパケットを抽出する。
【0254】
前記「受信時刻管理部」では、必要な番組情報を多重化情報分離部425内のメモリ部426内に一時保管すると同時に各トランスポートパケット毎の受信時刻を測定し、その値を図5(d)のようにタイムスタンプとして各トランスポートパケット毎に付加する。この付加したタイムスタンプ情報はメモリ部426内に記録される。
【0255】
前記「ストリームデータ内容解析部」では、メモリ部426内に記録されたトランスポートパケット内の情報が解析される。具体的には、トランスポートパケット列から、各ピクチャ境界位置の切り出しと、再生タイムスタンプ(PTS)情報の抽出が行なわれる。各ピクチャ境界位置の切り出し方法は前述したように2通り存在し、ストリームデータ内容に応じて選択する。同様にピクチャヘッダ情報41内にあるPTS情報53を抽出する。次にメモリ部426に一時保管されたストリームデータを情報記憶媒体201上に記録する。
【0256】
STB装置416から再生開始位置としてタイムスタンプ値が指定された場合、対応するストリームブロックを算出するための情報がタイムマップ情報252である。このタイムマップ情報252は、図3(e)〜(h)に示すように、ストリームデータに対する管理情報記録領域であるSTREAM.IFO105内のストリームオブジェクト情報243の一部として記録されている。
【0257】
図3(i)に示すように、タイムマップ情報252内には各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。従って、各ストリームオブジェクト情報242、243毎にタイムマップ情報252内の各ストリームブロックの時間差の値を逐次加算し、その逐次加算値がSTB装置416側で指定したタイムスタンプ時刻に到達するかどうか比較する必要がある。その比較結果を元に、STB装置416側が指定した時刻はどのストリームオブジェクト内の何番目のストリームブロックの中に含まれるタイムスタンプ値と一致するかが、割り出される。
【0258】
次に、既に情報記憶媒体201上に記録してあるストリームデータの部分消去に関する実施例の説明を行う。
【0259】
ストリームデータの記録再生装置では、前述した部分消去処理はSTB制御部404により制御され、その中でも特にストリームデータ部分消去制御部と言う名のシーケンシャルプログラムが中心となり処理実行が行なわれる。
【0260】
図11のSTB制御部404では、部分消去が行われる前に、ストリームデータに関する管理情報(STRI)が記載されているSTREAM.IFO105の情報が読み込みまれ、ワークRAMメモリ部407に一時保管されている。部分消去処理が完了すると、部分消去対象のセクタが図2のSTREAM.VRO(またはSR_TRANS.SRO)106から外される。その後、管理情報(SOBIおよびSCIを含むSTRI)が図9(l)に示した内容に変更され、図2のSTREAM.IFO105内のデータが書き替えられる。
【0261】
次に、ストリームオブジェクト内の再生開始したいストリームデータへのアクセス方法として、「MPEG方式による映像圧縮に対応し、デコーダによるデコードタイミングを意識した」アクセス方法について説明する。
【0262】
この発明の実施の形態では、STB装置416からアイソクロナス・モードでストリームデータが転送されると同時に、リアルタイムでIピクチャ情報が転送され、その情報が図1(a)のようにストリームデータを記録するSTREAM.VRO106ファイル内に記録される。また、この発明の実施の形態では、この情報は、ストリームデータの管理情報が記録されているSTREAM.IFO105内にも記録される。
【0263】
図11に示すSTB装置416側で、例えば図7のBピクチャ情報504を再生表示したい場合には、その直前に存在するIピクチャ情報501の先頭に位置するトランスポートパケット1aに対応したタイムスタンプ1aの値を、光ディスク装置415に通知する。
【0264】
光ディスク装置415では、図1あるいは図3に示した構造を有するタイムマップ情報252の情報を用いて再生開始するセクタ位置を割り出し、情報記憶媒体201上の所定位置へアクセスし、再生したいストリームデータをSTB装置416へ転送する。すると、STB装置416のデコーダ部402では、Iピクチャ情報501からデコードを開始し、指定されたBピクチャ情報504から表示を開始する。
【0265】
Bピクチャ情報504の開始情報が記録されているトランスポートパケット41d(図7)には、図5(a)(b)に示すように、そのトランスポートパケットヘッダ311内に表示開始時刻を示す再生タイムスタンプ(プレゼンテーションタイムスタンプ)PTS305の情報が記録されている。デコーダ部402では、このPTS305を読み取って、再生開始時刻を設定する。
【0266】
図11のデコーダ部402でIピクチャ位置を抽出する方法に付いて前述した。しかしデジタルTV放送局によっては送信の段階で各ピクチャ位置情報を送信する場合もある。送信の段階で既に記録されている各ピクチャ位置情報について、以下に説明する。
【0267】
この発明の実施の形態では、部分消去後のストリームデータに対しても初期記録時に設定したストリームブロック境界位置を不変に保つとともに、部分消去部分を境界として残存部分を新たなストリームオブジェクトに定義し直すようにしている。この場合、ストリームオブジェクト内の最初と最後のストリームブロックのサイズが他のストリームブロックのサイズより小さくなることがある。そのため、図1(l)あるいは図3(i)に示すようにタイムマップ情報252では個々のストリームブロックサイズ情報も記録してある。
【0268】
この実施の形態においては、上記に限らず、例えば最初と最後のストリームブロックサイズ情報のみ持ち、他にはそれ以外の共通のストリームブロックサイズ情報のみ記録することも可能である。
【0269】
図12は、図11のシステムによりビットストリームの情報記録を行なう場合において、アプリケーションパケットとストリームオブジェクトとの位置合わせ、およびストリームオブジェクト末尾のパディング処理がどのように行われるかを説明するフローチャート図である。
【0270】
図11の光ディスク装置(ストリーマ)415において、記録するビットストリーム(トランスポートパケットの内容)が、スタッフィングパケット内のアプリケーションパケットエリアに分配される(ステップST10)。
【0271】
最初のアプリケーションパケットのアプリケーションタイムスタンプ(ATS)の先頭バイト(これをAとする)と、ビットストリームが記録されるストリームオブジェクト(SOB)の開始部分にくる最初のストリームパケット内のアプリケーションパケットエリアの開始部分(これをBとする)とが比較される(ステップST12)。
【0272】
ATSの先頭バイト(A)と最初のストリームパケット内のアプリケーションパケットエリアの開始部分(B)とが一致しないときは(ステップST14ノー)、たとえば必要バイト数のスタッフィングバイトをストリームパケット内に設けて、先頭バイト(A)と開始部分(B)とを一致(アライン)させる(ステップST16)。
【0273】
ATSの先頭バイト(A)と最初のストリームパケット内のアプリケーションパケットエリアの開始部分(B)とが一致するとき(ステップST14イエス)、あるいは先頭バイト(A)と開始部分(B)とを一致(アライン)させたあと、記録するビットストリームの実際のデータを含む最終アプリケーションパケット(これをCとする)の末尾と、ビットストリームが記録されるSOBの末尾(これをDとする)との間に、1ストリームパケット分(1セクタ分)以上の余白があるかどうかチェックされる(ステップST18)。
【0274】
アプリケーションパケット(C)の末尾とSOBの末尾(D)との間に1ストリームパケット分(1セクタ分)以上の余白があるときは(ステップST18イエス)、この余白は、1つのATSを含む1以上のスタッフィングパケットで埋められる(ステップST20)。
【0275】
アプリケーションパケット(C)の末尾とSOBの末尾(D)との間に余白がないとき(ステップST18ノー)、あるいはアプリケーションパケット(C)の末尾とSOBの末尾(D)との間の余白がスタッフィングパケットで埋められたあと、記録するビットストリームの内容を含む1以上のアプリケーションパケット群(適宜スタッフィングパケットあるいはスタッフィングエリアバイトを含み得る)が、情報媒体201に記録される(ステップST22)。
【0276】
その後、記録情報に対応して管理情報(STRI)に書き込みが行われる(ステップST24)。
【0277】
上記記録ステップST22においては、以下の処理が適宜行なわれる。
【0278】
(10)アプリケーションパケットエリアの末尾に余白部分があるときは、この余白部分に(タイムスタンプがなく)所定バイト数のスタッフィングエリア(図5(h)または図19(j)のパディングエリア37)を設ける。
【0279】
また、上記記録ステップST22〜ST24においては、以下の処理が適宜行なわれる。
【0280】
(11)複数のデータユニット(図8(a)のSOBU#α…#λ)によりストリームデータ(SOB)を構成し、
所定のタイムスタンプ(TMS)情報が内部に記録されている1以上の前記データパケット(図8(b)のTP/AP)により各々の前記データユニット(SOBU#α…#λ)を構成し、
複数の前記データユニット(SOBU#α…#λ)のうち、少なくとも、第1のデータユニット(SOBU#α)内に記録された第1タイムスタンプ(TMS1a)と、第2のデータユニット(SOBU#β)内に記録された第2タイムスタンプ(TMS33a)との差分に対応した時間差値(図8(c)(d)の切り上げ丸め値)を、管理領域(STRIまたはSTREAM.IFO/SR_MANGR.IFO)内に記録する。
【0281】
(12)ストリームデータ(SOB)に、1以上のセル(図18)の情報を記録し、
管理領域(STRIまたはSTREAM.IFO/SR_MANGR.IFO)に、1以上のセルの集まりを記述したプログラムチェーン(PGC)の情報(図3(f)または図13のPGCI)を記録し、
前記ストリームデータ(SOB)の記録内容の一部を再生時にスキップする際に、そのスキップ位置の目印として利用できるエントリポイント(EP)の情報(SC_EPI)を、前記管理情報(STRI)に記録する。
【0282】
(13)管理情報(STRI)に、ストリームデータ(SOB)の記録時間情報(SOB_REC_TM)、前記ストリームデータ(SOB)の始まり部分のデータパケット到着時間(SOB_S_APAT)、および前記ストリームデータ(SOB)の終わり部分のデータパケット到着時間(SOB_E_APAT)のうち、少なくとも1つを含むストリームオブジェクト一般情報(図7(d)または図15のSOBI_GI)を書き込む。
【0283】
図13は、ストリーマの管理情報(図2または図3のSTREAM.IFOに対応)の内部データ構造を説明する図である。
【0284】
図2あるいは図3(e)に示した管理情報(ナビゲーションデータ)であるSTREAM.IFO(SR_MANGR.IFO)105は、図13に示すように、ストリーマ情報STRIを含んでいる。
【0285】
このストリーマ情報STRIは、図3(f)あるいは図13に示すように、ストリーマビデオマネージャ情報STR_VMGIと、ストリームファイル情報テーブルSFITと、オリジナルPGC情報ORG_PGCI(より一般的に表現すればPGC情報PGCI#i)と、ユーザ定義PGC情報テーブルUD_PGCITと、テキストデータマネージャTXTDT_MGと、アプリケーションプライベートデータマネージャAPDT_MGとで、構成されている。
【0286】
ストリーマビデオマネージャ情報STR_VMGIは、図13に示すように、STRI、STR_VMGIに関する管理情報等が記述されたビデオマネージャ情報管理情報VTSI_MATと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル(PL_SRPT)とを含んでいる。
【0287】
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。
【0288】
ストリームファイル情報テーブルSFITは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルSFITの詳細については、図15を参照して後述する。
【0289】
オリジナルPGC情報ORG_PGCIは、オリジナルPGC(ORG_PGC)に関する情報を記述した部分である。ORG_PGCはプログラムセットを記述したナビゲーションデータを示す。ORG_PGCはプログラムの連なり(チェーン)であり、図2または後述する図18の「.SRO」ファイル(図2ではSR_TRANS.SRO106)内に記録されたストリームデータを含む。
【0290】
ここで、プログラムセットとは、情報記憶媒体201の記録内容全体(全てのプログラム)を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルPGC(ORG_PGC)と呼ばれるデータ構造に対応している。
【0291】
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、1以上のオリジナルセルにより構成される。プログラムはオリジナルPGC内でのみ定義されるものである。
【0292】
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義PGC内のセルは「ユーザ定義セル」と呼ばれる。
【0293】
プログラムセット内の各々のプログラムは、少なくとも1個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも1個のユーザ定義セルで構成される。
【0294】
一方、ストリーマでは、ストリームセル(SC)だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
【0295】
なお、プログラムチェーン(PGC)とは、上位概念的な単位を示す。オリジナルPGCでは、PGCはプログラムセットに対応したプログラムの連なり(チェーン)を指す。また、ユーザ定義PGCでは、PGCはプレイリストに対応するプログラムの一部の連なり(チェーン)を指す。
【0296】
また、プログラムの一部のチェーンを指すユーザ定義PGCは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルPGCに属するストリームデータを参照するようになっている。
【0297】
図13のユーザ定義PGC情報テーブルUD_PGCITは、ユーザ定義PGC情報テーブル情報UD_PGCITIと、1以上のユーザ定義PGCサーチポインタUD_PGC_SRP#nと、1以上のユーザ定義PGC情報UD_PGCI#nとを含むことができる。
【0298】
ユーザ定義PGC情報テーブル情報UD_PGCITIは、図示しないが、ユーザ定義PGCサーチポインタUD_PGC_SRPの数を示すUD_PGC_SRP_Nsと、ユーザ定義PGC情報テーブルUD_PGCITの終了アドレスを示すUD_PGCIT_EAとを含む。
【0299】
UD_PGC_SRP_Nsが示すUD_PGC_SRPの数は、ユーザ定義PGC情報(UD_PGCI)の数と同じであり、ユーザ定義PGC(UD_PGC)の数とも同じである。この数は、最大「99」まで許されている。
【0300】
UD_PGCIT_EAは、該当UD_PGCITの終了アドレスを、そのUD_PGCITの先頭バイトからの相対バイト数(F_RBN)で記述したものである。
【0301】
ここで、F_RBNとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
【0302】
オリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したPGCI#iについては、図14を参照して後述する。
【0303】
図13のテキストデータマネージャTXTDT_MGは、補足的なテキスト情報である。このTXTDT_MGは、図14のプライマリテキスト情報PRM_TXTIとともに、プレイリストおよびプログラム内に格納できる。
【0304】
図13のアプリケーションプライベートデータマネージャAPDT_Mは、図示しないが、アプリケーションプライベートデータマネージャ一般情報APDT_GIと、1以上のAPDTサーチポインタAPDT_SRP#nと、1以上のAPDTエリアAPADTA#nとを含むことができる。
【0305】
ここで、アプリケーションプライベートデータAPDTとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報(リアルタイムストリームデータに加えさらに望まれる情報)を格納できるような概念上のエリアである。
【0306】
図14は、PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。図14のPGC情報PGCI#iは、図13のオリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したものである。
【0307】
図14に示すように、PGC情報PGCI#iは、PGC一般情報PGC_GIと、1以上のプログラム情報PGI#mと、1以上のストリームセル情報サーチポインタSCI_SRP#nと、1以上のストリームセル情報SCI#nとで構成されている。
【0308】
PGC一般情報PGC_GIは、プログラムの数PG_Nsと、ストリームセル情報サーチポインタSCI_SRPの数SCI_SRP_Nsとを含んでいる。
【0309】
各プログラム情報PGI(たとえばPGI#1)は、プログラムタイプPG_TYと、該当プログラム内のセルの数C_Nsと、該当プログラムのプライマリテキスト情報PRM_TXTIと、アイテムテキストのサーチポインタ番号IT_TXT_SRPNとを含んでいる。
【0310】
ここで、プログラムタイプPG_TYは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
【0311】
このプロテクトフラグが「0b」のときは該当プログラムは保護されておらず、「1b」のときは保護された状態にある。
【0312】
セルの数C_Nsは、該当プログラム内のセルの数を示す。PGCの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに(暗黙のうちに)付随している。
【0313】
たとえば、PGC内でプログラム#1がC_Ns=1を持ち、プログラム#2がC_Ns=2を持つとすれば、そのPGCの最初のストリームセル情報SCIはプログラム#1に付随するものとなり、第2、第3のSCIはプログラム#2に付随するものとなる。
【0314】
プライマリテキスト情報PRM_TXTIは、情報記憶媒体(DVD−RAMディスク)201を世界中で利用可能とするために、1つの共通キャラクタセット(ISO/IEC646:1983(ASCIIコード))を持ったテキスト情報を記述したものである。
【0315】
アイテムテキストのサーチポインタ番号IT_TXT_SRPNは、アイテムテキスト(該当プログラムに対応するテキストデータ)IT_TXTに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、IT_TXT_SRPNは「0000h」にセットされる。
【0316】
各ストリームセル情報サーチポインタSCI_SRP(たとえばSCI_SRP#1)は、対応ストリームセル情報SCIの開始アドレスを示すSCI_SAを含んでいる。このSCI_SAは、PGCIの先頭バイトからの相対バイト数(F_RBN)で記述される。
【0317】
各ストリームセル情報SCI(たとえばSCI#1)は、ストリームセル一般情報SC_GIと、1以上のストリームセルエントリポイント情報SC_EPI#nとで構成される。
【0318】
ストリームセル一般情報SC_GIは、仮消去(テンポラリイレーズ;TE)状態を示すフラグTEを含むセルタイプC_TYと、ストリームセルのエントリポイント情報の数SC_EPI_Nsと、ストリームオブジェクト番号SOB_Nと、ストリームセル開始APAT(図9で示したSC_S_APAT)と、ストリームセル終了APAT(図9で示したSC_E_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの開始APATを示す消去開始APAT(ERA_S_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの終了APATを示す消去終了APAT(ERA_E_APAT)とを含んでいる。
【0319】
セルタイプC_TYは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
【0320】
すなわち、セルの形式C_TY1=「010b」は全てのストリームセルの形式に記述される(このC_TY1=「010b」によりストリームセルとそれ以外のセルの区別ができる)。
【0321】
一方、フラグTEが「00b」であれば該当セルは通常の状態にあることが示され、フラグTEが「01b」あるいは「10b」であれば該当セルは仮消去の状態にあることが示される。
【0322】
フラグTE=「01b」は、該当セル(仮消去状態にあるセル)が、SOBU内で開始する最初のアプリケーションパケットの後から開始し、同じSOBU内の最終アプリケーションパケットの前で終了する場合を示す。
【0323】
また、フラグTE=「10b」は、該当セル(仮消去状態にあるセル)が、少なくとも1つのSOBU境界(先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのSOBU内で開始する)を含む場合を示す。
【0324】
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのTEフラグとは、同時に設定できないようになっている。それゆえ、
(a)プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず;
(b)仮消去状態にあるセルを1以上含むプログラムはプロテクト状態に設定できない。
【0325】
ストリームセルのエントリポイント情報の数SC_EPI_Nsは、該当ストリームセル情報SCI内に含まれるストリームセルエントリポイント情報の数を記述したものである。
【0326】
図14の各ストリームセルエントリポイント情報SC_EPI(たとえばSC_EPI#1)は、2種類(タイプAとタイプB)存在する。
【0327】
タイプAのSC_EPIは、エントリポイントタイプEP_TYとエントリポイントのアプリケーションパケット到着時間EP_APATとを含む。タイプAは、エントリポイントタイプEP_TY1=「00b」により示される。
【0328】
タイプBのSC_EPIは、タイプAのEP_TYおよびEP_APATの他に、プライマリテキスト情報PRM_TXTIを含む。タイプBは、エントリポイントタイプEP_TY1=「01b」により示される。
【0329】
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間(APAT)により特定できる。このAPATにより、どこからデータ出力が開始されるのかを特定できる。
【0330】
ストリームオブジェクト番号SOB_Nは、該当セルが参照するSOBの番号を記述したものである。
【0331】
ストリームセル開始APAT(SC_S_APAT)は、該当セルの開始APATを記述したものである。
【0332】
ストリームセル終了APAT(SC_E_APAT)は、該当セルの終了APATを記述したものである。
【0333】
消去開始APAT(ERA_S_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、この仮消去セルに先頭が含まれる最初のSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0334】
消去終了APAT(ERA_E_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、仮消去セルのすぐ後に続くアプリケーションパケットを含むSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0335】
図15は、ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【0336】
図15に示すように、ストリームファイル情報テーブルSFITは、ストリームファイル情報テーブル情報SFITIと、1以上のストリームオブジェクトストリーム情報SOB_STI#nと、ストリームファイル情報SFIとで構成される。
【0337】
ストリームファイル情報テーブル情報SFITIは、情報記憶媒体(DVD−RAMディスク)201上のストリームファイル情報の数SFI_Nsと、SFITIに続くストリームオブジェクトストリーム情報の数SOB_STI_Nsと、SFITの終了アドレスSFIT_EAと、SFIの開始アドレスSFI_SAとで構成される。
【0338】
SFIT_EAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFITの終了アドレスを記述したものである。
【0339】
また、SFI_SAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFIの開始アドレスを記述したものである。
【0340】
各ストリームオブジェクトストリーム情報SOB_STIは、3種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、SOB_STIは、ストリームオブジェクト情報(SOBI)のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト(SOB)が同じSOB_STIを共有する(つまり同じSOB_STIをポイントする)ことが認められている。したがって、通常は、SOBの数よりもSOB_STIの数の方が少なくなる。
【0341】
図15の各ストリームオブジェクトストリーム情報SOB_STI(たとえばSOB_STI#1)は、アプリケーションパケットサイズAP_SIZと、サービスIDの数SERV_ID_Nsと、サービスID(SERV_IDs)と、アプリケーションパケットデバイスユニークID(AP_DEV_UID)とを含んでいる。
【0342】
AP_SIZは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
【0343】
なお、DVDストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト(現SOB)はそこで終了され、新たなストリームオブジェクト(新SOB)が、新たなAP_SIZを伴って開始される。その際、現SOBおよび新SOBの双方は、オリジナルPGC情報(ORG_PGCI)内の同じプログラムに属するものとなる。
【0344】
SERV_ID_Nsは、後続パラメータに含まれるサービスIDの数を記述したものである。
【0345】
SERV_IDsは、サービスIDのリストを任意の順序で記述したものである。
【0346】
AP_DEV_UIDは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスIDを記述したものである。
【0347】
ストリームファイル情報SFIは、図15に示すように、ストリームファイル一般情報SF_GIと、1以上のストリームオブジェクト情報(SOB情報)サーチポインタ(SOBI_SRP)#nと、1以上のSOB情報(SOBI)#nとで構成されている。
【0348】
ストリームファイル一般情報SF_GIは、SOBIの数SOBI_Nsと、SOBU1個あたりのセクタ数SOBU_SIZとを含んでいる。
【0349】
ここで、SOBU_SIZは、SOBUのサイズをセクタ数で記述したもので、このサイズは32(32セクタ=64kバイト)で一定となっている。このことは、各タイムマップ情報(MAPL)内において、最初のエントリが、SOBの最初の32セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、2番目のエントリは、次の32セクタに含まれるアプリケーションパケットに関係する。3番目以降のエントリについても以下同様である。
【0350】
各SOB情報サーチポインタ(たとえばSOBI_SRP#1)は、SOBIの開始アドレスSOBI_SAを含んでいる。このSOBI_SAは、ストリームファイル情報SFIの先頭バイトから相対バイト数(F_RBN)でもって関連SOBIの開始アドレスを記述したものである。
【0351】
各SOB情報(たとえばSOBI#1)は、ストリームオブジェクト一般情報SOB_GIと、タイムマップ情報MAPLと、アクセスユニットデータAUD(オプション)とで構成される。
【0352】
ストリームオブジェクト一般情報SOB_GIは、ストリームオブジェクトのタイプSOB_TYと、ストリームオブジェクト記録時間SOB_REC_TMと、ストリームオブジェクトのストリーム情報番号SOB_STI_Nと、アクセスユニットデータフラグAUD_FLAGSと、ストリームオブジェクトの開始アプリケーションパケット到着時間SOB_S_APATと、ストリームオブジェクトの終了アプリケーションパケット到着時間SOB_E_APATと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットSOB_S_SOBUと、タイムマップ情報のエントリ数MAPL_ENT_Nsとを含んでいる。
【0353】
ストリームオブジェクトのタイプSOB_TYは、仮消去状態(TE状態)を示すビットおよび/またはコピー世代管理システムのビットを記述できる部分である。
【0354】
ストリームオブジェクト記録時間SOB_REC_TMは、関連ストリームオブジェクト(SOB)の記録時間を記述したものである。
【0355】
ストリームオブジェクトのストリーム情報番号SOB_STI_Nは、該当ストリームオブジェクトに対して有効なSOB_STIのインデックスを記述したものである。
【0356】
アクセスユニットデータフラグAUD_FLAGSは、該当ストリームオブジェクトに対してアクセスユニットデータ(AUD)が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
【0357】
アクセスユニットデータ(AUD)が存在する場合は、AUD_FLAGSにより、AUDの幾つかの特性が記述される。
【0358】
アクセスユニットデータ(AUD)自体は、図15に示すように、アクセスユニット一般情報AU_GIと、アクセスユニットエンドマップAUEMと、再生タイムスタンプリストPTSLとで構成される。
【0359】
アクセスユニット一般情報AU_GIは、該当SOBに対して記述されたアクセスユニットの数を示すAU_Nsと、該当SOBに属するSOBUのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップAUSMとを含んでいる。
【0360】
アクセスユニットエンドマップAUEMは、(もし存在するときは)AUSMと同じ長さのビットアレイであり、該当SOBのアクセスユニットに付随するビットストリームセグメントの終端をどのSOBUが含むのかを示す。
【0361】
再生タイムスタンプリストPTSLは、該当SOBに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる1つのPTSLエレメントは、対応アクセスユニットの再生タイムスタンプ(PTS)の値を含む。
【0362】
なお、アクセスユニット(AU)とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、MPEGのIピクチャに対応する部分となる。
【0363】
ここで再びSOB_GIの内容説明に戻る。
【0364】
AUD_FLAGSは、フラグRTAU_FLGと、フラグAUD_FLGと、フラグAUEM_FLGと、フラグPTSL_FLGとを含んでいる。
【0365】
フラグRTAU_FLGが0bのときは、該当SOBのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
【0366】
フラグRTAU_FLGが1bのときは、図10(d)のアプリケーションヘッダエクステンション内に記述されるAUフラグ(AU_START、AU_END)が、該当SOBのリアルタイムデータ内に存在可能なことが示される。この状態は、下記AUD_FLGが0bの場合にも許される。
【0367】
フラグAUD_FLGが0bのときは、該当SOBに対してアクセスユニットデータ(AUD)がないことが示される。
【0368】
フラグAUD_FLGが1bのときは、該当SOBに対してアクセスユニットデータ(AUD)が存在し得ることが示される。
【0369】
フラグAUEM_FLGが0bのときは、該当SOBにAUEMが存在しないことが示される。
【0370】
フラグAUEM_FLGが1bのときは、該当SOBにAUEMが存在することが示される。
【0371】
フラグPTSL_FLGが0bのときは、該当SOBにPTSLが存在しないことが示される。
【0372】
フラグPTSL_FLGが1bのときは、該当SOBにPTSLが存在することが示される。
【0373】
SOB_S_APATは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、SOB_S_APATにより、該当SOBに属する最初のアプリケーションパケット到着時間が示される。
【0374】
このパケット到着時間(PAT)は、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0375】
SOB_E_APATは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、SOB_E_APATにより、該当SOBに属する最後のアプリケーションパケット到着時間が示される。
【0376】
SOB_S_SOBUは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、SOB_S_SOBUにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むSOBUが示される。
【0377】
MAPL_ENT_Nsは、SOBI_GIの後に続くタイムマップ情報(MAPL)のエントリ数を記述したものである。
【0378】
タイムマップ情報MAPLは、図3(h)のタイムマップ情報252に対応する内容を持つ。
【0379】
図13および図15の内容の関連性の1つについて纏めると、次のようになる:
管理情報105に含まれるストリーマ情報STRIは、ストリームデータの内容の一部を構成するストリームオブジェクトSOBを管理するストリームファイル情報テーブルSFITを含む。このSFITは、SOBを管理するストリームオブジェクト情報SOBIを含む。このSOBIが、管理情報(アクセスユニット開始マップAUSM)を含むアクセスユニット一般情報AU_GIと、管理情報(PTSL)とを含む。
【0380】
ここで、管理情報(ATSまたはAUSM)がストリームデータの転送時に使用される情報を含み、管理情報(PTSまたはSC_S_APAT)が前記ストリームデータを表示するときに使用される情報を含む。
【0381】
図16は、アクセスユニット開始マップ(AUSM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【0382】
図示するように、AUSMのうちビット”1”の部分が、対応SOBUにアクセスユニット(AU)が含まれることを示している。
【0383】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)としてみる。すると、アクセスユニットAUの位置は次のようになる。
【0384】
(1)もしAUSM_pos(i)により示されるSOBU#iが1以上の開始AU(これはストリーム内で(もしあるなら)AU_STARTマークおよびAU_ENDマークにより記述される)を含むなら、AUSM_pos(i)は、SOBU#i内で開始する最初のAUに割り当てられる。ここで、SOBU#iは、AUSM_pos(i)および(AUEMが存在するなら)AUEM_pos(i)により記述されたSOBUs内に配置されたものである。
【0385】
(2)AUは、このAU開始後に最初に現れるAU_ENDマークで終了し、かつ、AUは、(もしAUEMが存在するなら)割り当てられたAUEMエレメントにより示される最後のSOBUで終了する。
【0386】
なお、いずれのアクセスユニットデータにおいても、SOBの各SOBU1個当たりに、2以上のアクセス可能なアクセスユニットを記述することはできない。
【0387】
図17は、アクセスユニット開始マップ(AUSM)およびアクセスユニット終了マップ(AUEM)とストリームオブジェクトユニット(SOBU)との対応関係を例示する図である。
【0388】
AUEMは、(もし存在するなら)AUSMと同じ長さのビットアレイである。AUEMのビットは、該当SOBのアクセスユニットに付随するビットストリームセグメントの末尾がどのSOBUに含まれるのかを、示している。
【0389】
AUEM内にセットされたビットの数はAUSM内にセットされたビットの数に一致する。すなわち、AUSM内の各設定ビットは、AUEM内に対応してセットされたビットを持つ。
【0390】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)とし、AUEM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUEM_pos(i)としてみる。この場合、以下の関係がある。
【0391】
(1)1≦AUSM_pos(i)≦AUEM_pos(i)≦MAPL_ENT_Ns;
(2)AUSM_pos(i+1)>AUEM_pos(i);
(3)もしi==AU_NsあるいはAUSM_pos(i+1)>1+AUEM_pos(i)なら、AU#iは、SOBU#[AUEM_pos(i)]で終了する(1≦i≦AU_Ns);
(4)もしAUSM_pos(i+1)==1+AUEM_pos(i)なら、AU#iは、SOBU#[AUEM_pos(i)]で終了する。あるいは
SOBU#[1+AUEM_pos(i)]==SOBU#[AuSM_pos(i+1)]のところで終了する。つまり、AU#iは、SOBU内においてAU#i+1が開始するところで終了する(1≦i≦AU_Ns)。
【0392】
図18は、オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【0393】
ユーザ定義PGCは自身のSOBを含まないが、オリジナルPGC内のSOBを参照する。それゆえ、ユーザ定義PGCはPGC情報を用いることのみで記述できる。このことは、SOBデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
【0394】
ユーザ定義PGCはまた、プログラムを含まず、オリジナルPGC内のプログラムの一部に対応したセルの連なり(チェーン)で構成される。
【0395】
このようなユーザ定義PGCの一例が、図18に示されている。この例は、PGC内のセルがオリジナルPGC内のSOBを参照するようにユーザ定義PGC#nが作成されている場合を示す。
【0396】
図18において、PGC#nは4つのセル#1〜#4を持っている。そのうち2つはSOB#1を参照し、残りの2つがSOB#2を参照している。
【0397】
ユーザ定義PGC内のセルからオリジナルPGCへ(SOBIのタイムマップ情報へ)の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義PGC内のセル再生順序は、オリジナルPGCにおける再生順序と全く異なってもよい。
【0398】
任意のSOBおよびそのSOBUの再生は、図18の開始APAT(S_APAT)および終了APAT(E_APAT)により特定される。
【0399】
SOBあるいはSOBUのS_APATは、該当SOBのストリームパックのペイロード(図5(b)参照)内に記録されたタイムスタンプに関係して定義される。
【0400】
SOBの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間(APAT)である。
【0401】
SOBの先頭アプリケーションパケットのAPATはSOB_S_APATとして記憶される。全てのAPATの4最下位バイト(4 least significant bytes)は、「〜.SRO」ファイル内の対応アプリケーションパケット用に予め固定されている。
【0402】
SOBあるいはSOBUのデータを再生するために、ストリーマ内部のリファレンスクロックはSCR値にセットされ、その後クロックが自動的にカウントされる。このSCR値は、再生が始まる最初のストリームパック内(パックヘッダ内)に記述されている。このクロックに基づいて、SOBあるいはSOBUからの全ての後続アプリケーションパケットの再生・出力が、実行される。
【0403】
任意のストリームセル(SC)が、そのSCがポイントするSOBのSOB_S_APATとSOB_E_APATとの間の任意の値を持つストリームセル開始APAT(SC_S_APAT)を規定しているときは、所望のAPATを伴うアプリケーションパケットを含んだSOBUを見つけるためのアドレスが必要となる。
【0404】
SOBU1個あたりのストリームパックの数は一定であるが、各SOBUにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各SOBは、該当SOBのSOBUの到着時間間隔が記述されたタイムマップ情報を持つ。つまり、タイムマップ情報により実現されるアドレス方式は、任意のAPATをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるSOBUをポイントする。
【0405】
図18に例示された各エントリポイント(EP#i、EP#k)は、どこからデータ出力を開始するのかを示すアプリケーションパケット到着時間(APAT)により特定できる。このエントリポイントのアプリケーションパケット到着時間は、図14のEP_APATにより示される。
【0406】
このエントリポイントを用いることにより、例えばセル#1のSOBU#1からの再生時において、SOBU#2〜SOBU#(i−1)をスキップして、SOBU#iの指定位置(エントリポイントEP#i)から再生を開始することができる。
【0407】
図19は、この発明の他の実施の形態に係るストリームデータのデータ構造を説明する図である。
【0408】
DVD−RAMディスク等の情報記憶媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(SOB)としてまとめられている。各SOBは、1つのリアルタイムな連続記録により得られたストリームデータにより形成される。
【0409】
図19(f)は、1以上あるストリームオブジェクトのうち1個のSOB#A・298について示している。DVD−RAMディスクにこのストリームデータが記録される場合には、各々が2048kバイトのセクタを最小単位として記録される。さらに、16個のセクタをまとめて1個のECCブロックとし、同一ECCブロック内でインターリーブ(データ配列順序の並び替え)とエラー訂正用の訂正コードの付加が行われる。
【0410】
この実施の形態では、1個または複数のECCブロックを単位としてストリームブロックが構成され、このストリームブロック単位でストリーム情報の記録あるいは部分消去が行われる。
【0411】
この実施の形態では、何個のECCブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて決めることができる。たとえば、図19(e)の例では、ストリームブロック#1は2つのECCブロック#α、#βで構成され、ストリームブロック#2は3つのECCブロック#γ、#δ、#εで構成されている。DVDストリーマでは、2個のECCブロック(32セクタ)で1つのストリームブロック(ストリームオブジェクトユニットSOBU)が構成される。
【0412】
各ECCブロックは、図19(d)に示すように、16セクタで構成される。したがって、図19(d)(e)から分かるように、2ECCブロックで構成されるストリームブロック(あるいはSOBU)#1は、32セクタ(セクタNo.0〜セクタNo.31)に相当する。
【0413】
つまり、1セクタ=2kバイトとすれば、ストリームブロック(SOBU)は、64kバイト(32セクタ)の固定サイズとして、この発明を実施することができる。
【0414】
各セクタの内容はストリームパック(詳細は図5、図6、図10参照)に対応している。そして、たとえばセクタNo.0(図19(d))に対応するストリームパックは、図19(c)に示すように、パックヘッダ1xと、PESヘッダ6xと、ストリームブロックヘッダ11xと、データエリア21xとを含んでいる。また、セクタNo.1(図19(d))に対応するストリームパックは、図19(c)に示すように、パックヘッダ2xと、PESヘッダ7xと、セクタデータヘッダ12xと、データエリア22xとを含んでいる。
【0415】
図19(c)のデータエリア21xは、図19(b)に示すように、タイムスタンプとトランスポートパケットとのペアの配列(タイムスタンプa、トランスポートパケットa、タイムスタンプb、………トランスポートパケットd)を含んでいる。同様に、データエリア22xは、タイムスタンプとトランスポートパケットとのペアの別配列を含んでいる。一方、後方のデータエリア23xは、図19(b)に示すように、トランスポートパケットf、エンドコード31x、およびパディングエリア36xを含んでいる。
【0416】
図19(b)のタイムスタンプとトランスポートパケットの複数ペアは、図19(a)に示すような配列のビットストリームとなる。
【0417】
SOB#A・298(図19(f))の前方のストリームブロック#1(図19(e))のデータ構造は図19(d)〜(b)のようになるが、SOB#A・298の後方のストリームブロック#2(図19(g))のデータ構造は、次のようになる。
【0418】
すなわち、ストリームブロック#2の末尾ECCブロック#εの後方セクタNo.78(図19(h))は、図19(i)に示すように、パックヘッダ3xと、PESヘッダ8xと、セクタデータヘッダ13xと、データエリア24xとを含んでいる。また、ECCブロック#εの最終セクタNo.79(図19(h))は、図19(i)に示すように、パックヘッダ4xとパディングパケット40xを含んでいる。
【0419】
セクタNo.78のデータエリア24xは、図19(j)に示すように、トランスポートパケットzと、エンドコード32xと、パディングエリア37xとを含んでいる。また、最終セクタNo.79のパディングパケット40xは、図19(j)に示すように、PESヘッダ9xとパディングエリア38xを含んでいる。
【0420】
なお、パディングエリア37xの内容は、図5(h)に示すように、1以上のタイムスタンプとパケットとのペアと、予約バイトのスタッフィングエリア(スタッフィングエリアにタイムスタンプは付かない)とで構成できる。この場合、スタッフィングエリアにはストリームデータの記録はなされない。
【0421】
一方、パディングエリア38の内容は、図6(i)(j)に示すように、スタッフィングパケット(先頭だけアプリケーションタイムスタンプATSが付く)を含むアプリケーションパケットエリアで構成できる。
【0422】
この発明では、以下のような特徴を持つデータ構造を採用することもできる:
A)各セクタ/ストリームパック毎にパックヘッダ/パケットヘッダを設け、セクタ/ストリームパック毎に必要な情報をパックヘッダ/パケットヘッダ内に記録するデータ構造(図1(a)〜(c)、図5(a)〜(b)、図10(a)〜(g)参照)。
【0423】
B)各トランスポートパケット/アプリケーションパケットがデコーダに転送される時間間隔に関係した時間情報を、タイムスタンプ情報として、各トランスポートパケット/アプリケーションパケットと一緒に情報記憶媒体上に記録するデータ構造(図1(k)〜(m)、図5〜図10参照)。
【0424】
C)タイムスタンプとトランスポートパケット/アプリケーションパケットをセクタ/ストリームパック内のパックヘッダ/パケットヘッダ以外の場所に順次詰めて記録するデータ構造。そして、タイムスタンプの切れ目またはトランスポートパケット/アプリケーションパケット毎に記録されるストリームデータの切れ目がセクタ/ストリームパックの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケット/アプリケーションパケットのどちらかを、隣のセクタ/ストリームパックに跨って配置記録するデータ構造(図1(d)〜(g)、図5(e)〜(j)参照)。
【0425】
D)ユーザ等が行う一回の録画映像の纏まりをストリームオブジェクト(SOB)とし、一回の映像録画において情報記憶媒体上に記録された最後のトランスポートパケット/アプリケーションパケット位置(1個のストリームオブジェクト内の最後のトランスポートパケット/アプリケーションパケット位置)がセクタ/ストリームパックの境界位置とは異なる場合には、該当するセクタ/ストリームパック内に限りこの最後のトランスポートパケット/アプリケーションパケット位置以降をパディングエリアとするデータ構造(図1(g)(k)、図6(g)〜(j)、図19(j)参照)。
【0426】
E)情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設けてストリームデータの検索および/または編集を容易とするデータ構造。
【0427】
F)ストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)内では、STREAM.VROファイルあるいはRTR_MOV.VROファイル内に記録してあるタイムスタンプの値を、個々のトランスポートパケット/アプリケーションパケット毎の識別/指定に利用するデータ構造(図8(b)〜(d)参照)。
【0428】
G)タイムサーチを容易にするため、複数セクタを纏めてストリームブロックという単位(あるいはストリームオブジェクトユニットSOBUというデータユニット)を管理ファイル上で構成し、このストリームブロック(SOBU)毎の時間情報を持ったタイムマップ情報を、この管理ファイル(STREAM.IFOあるいはRTR.IFO)内に持たせるデータ構造(図8(a)〜(d)参照)。
【0429】
なお、少なくともストリームオブジェクト内の最初と最後のストリームブロック(SOBU)のデータサイズを、管理ファイル(STREAM.IFOあるいはRTR.IFO)内のタイムマップ情報に記録するようにしてもよい(図3(i)参照)。
【0430】
H)各ストリームブロック(SOBU)内の最初に配置されたタイムスタンプ(前のストリームブロックから跨って記録されたタイムスタンプを除く)の値を各ストリームブロック(SOBU)先頭時刻として管理ファイル(STREAM.IFOあるいはRTR.IFO)内で管理するデータ構造(図8(a)〜(d)参照)。
【0431】
具体的には、管理ファイル内のタイムマップ情報に各ストリームブロック(SOBU)内で最初に配置されたタイムスタンプ(たとえば図8(b)のTMS1a)の値を記録する。
【0432】
この発明に係るストリームデータ記録方法では、第1の記録単位(セクタまたはストリームパック)毎に情報記録を行える情報記憶媒体を用い、第2の記録単位(トランスポートパケット/アプリケーションパケット)に分割されたストリームデータが記録される。
【0433】
上記第2の記録単位(トランスポートパケット/アプリケーションパケット)でストリームデータが記録される第1の記録領域(図3(d)のストリーム記録エリア222)内に、上記第1記録単位(セクタ/ストリームパック)毎に付与するパケットヘッダ(あるいはパックヘッダ)情報と、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎のストリームデータとが記録される。
【0434】
上記タイムスタンプ情報の切れ目もしくは上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎に記録されるストリームデータの切れ目が上記第1の記録単位(セクタ/ストリームパック)の境界位置とは異なる場合には、上記タイムスタンプ情報または上記第2の記録単位(トランスポートパケット/アプリケーションパケット)毎に記録されるストリームデータが複数の上記第1の記録単位(セクタ/ストリームパック)に跨って配置されるように記録される(図5(e)の番組2のトランスポートパケットbの前半部346と後半部347、および図5(h)〜(j)参照)。
【0435】
情報記憶媒体上に最後に記録されたストリームデータにおいて、上記第2の記録単位(トランスポートパケット/アプリケーションパケット)の最終位置が上記第1の記録単位(セクタ/ストリームパック)の境界位置とは異なる場合には、最後に記録された上記第1の記録単位(セクタ/ストリームパック)または上記第2の記録単位(トランスポートパケット/アプリケーションパケット)の最終位置以降に、パディングエリア(図1(k)あるいは図6(h)の21)として、所定のデータ(たとえば、オール1ビットあるいはオール0ビット)が記録される(図6(i)(j)参照)。
【0436】
上記第1の記録領域(ストリーム記録エリア222)内に記録されたデータに関する管理情報を格納する第2の記録領域(STREAM.IFOあるいはRTR.IFO)が記録される(図3(d)(e)参照)。
【0437】
上記第1の記録領域(ストリーム記録エリア222)に関する時間情報が記録された第3の記録領域(ストリームファイル情報)に対して、上記第1の記録単位(セクタ/ストリームパック)を複数集めて第3の記録単位(ストリームブロック/SOBU)が構成される(図6(b)〜(e)、図8(a)〜(b)参照)。
【0438】
上記第1の記録領域(ストリーム記録エリア222)内に記録されたストリームデータに対する上記第3の記録単位(ストリームブロック/SOBU)毎の先頭に配置されたタイムスタンプ情報間の差分値が、タイムマップ情報として記録される(図1(i)〜(m)、図8(a)〜(d)参照)。
【0439】
また上記の方法でストリームデータが記録されたデータ構造を有する情報記憶媒体も、この発明の特徴となっている。
【0440】
さらにIピクチャ開始位置を意識しながらトランスポートパケット単位での部分消去を可能とする方法として、以下のものがある。
【0441】
I)部分消去場所前後で新たにストリームオブジェクトを分割する。
【0442】
J)ストリームデータが記録されているSTREAM.VROファイルあるいはRTR_MOV.VROファイルに関する情報を記載するストリームファイル情報の情報と、ストリームデータの再生時に使用する再生単位情報(セル情報)を、管理ファイル(STREAM.IFOあるいはRTR.IFO)内に持つ。
【0443】
K)ストリームデータが記録されているSTREAM.VROファイルあるいはRTR_MOV.VROファイルに対してはセクタ単位で部分消去処理を行う。
【0444】
L)管理ファイル(STREAM.IFOあるいはRTR.IFO)上ではIピクチャ開始位置に従ってストリームオブジェクトを分割する。
【0445】
具体的には、ストリームファイル情報(図7(d)のSOBI_GI・251)内にストリームオブジェクト開始時間の情報(図7(C)のSOB_S_APAT542)とストリームオブジェクト終了時間の情報(図7(C)のSOB_E_APAT543)を持たせ、部分消去後はIピクチャ開始位置が記録されているトランスポートパケット(図7の1a)に対応したタイムスタンプ(図7の1a)の値をストリームオブジェクト開始時間(SOB_S_APAT542)の値に変更(あるいは追記)し、部分消去境界位置を含むストリームデータの直後に来るIピクチャ開始位置が記録されているトランスポートパケットの1個前のトランスポートパケット(図7のTP298g)に対応したタイムスタンプ(図7のTMS298g)の値をストリームオブジェクト終了時間(SOB_E_APAT543)の値に変更(あるいは追記)する。
【0446】
M)管理ファイル(STREAM.IFOあるいはRTR.IFO)上では部分消去指定したトランスポートパケットに対応してセル情報内の開始/終了位置を設定する。
【0447】
具体的には、部分消去の範囲をトランスポートパケット単位で指定し、その指定範囲に対して残存したトランスポートパケットのうち、先頭のトランスポートパケットに対応したタイムスタンプ(図9(j)のTMS97c)の値を新たなオリジナルセルの該当セルの開始時間(図9(l)のSC_S_APAT283)とし、最後のトランスポートパケットに対応したタイムスタンプ(図9(j)のTMS224k)の値を新たなオリジナルセルの該当セルの終了時間(図9(l)のSC_E_APAT284)として管理ファイル(STREAM.IFOあるいはRTR.IFO)内に変更(あるいは追記)する。
【0448】
上述した部分消去方法を適用できる情報媒体は、第1の記録単位(セクタ)毎に情報の記録が行える媒体である。この媒体は、ストリームデータが記録される第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)と、上記第1の記録領域内に記録されたデータに関する管理情報を記録した第2の記録領域(STREAM.IFOあるいはRTR.IFO)とを持つ。上記第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)内に、上記第1記録単位(セクタ)毎に付与するパケットヘッダ情報と、上記第2の記録単位(トランスポートパケット)のストリームデータに関係する時間情報を有するタイムスタンプ情報と、上記第2の記録単位(トランスポートパケット)毎のストリームデータが詰めて記録される。上記第1の記録単位(セクタ)を複数集めて第3の記録単位(ストリームブロック)が構成される。そして、複数の前記第3の記録単位(ストリームブロック)から構成されストリームデータに対する大きなデータのまとまりを示す第4の記録単位(ストリームオブジェクト)が構成される。上記第2の記録領域(STREAM.IFOあるいはRTR.IFO)内に、上記第3の記録単位(ストリームブロック)毎の時間情報(タイムマップ情報)と上記第4の記録単位(ストリームオブジェクト)の開始と終了位置での上記第3の記録単位(ストリームブロック)のデータサイズ情報が記録される。
【0449】
上記第1の記録領域(STREAM.VROあるいはRTR_MOV.VRO)内に記録されたストリームデータは、上記第1の記録単位(セクタ)で部分消去できる。そして、部分消去後は新たなサイズを持った第4の記録単位(ストリームオブジェクト)が形成され、かつ上記新たなサイズを持った第4の記録単位(ストリームオブジェクト)における開始位置もしくは終了位置での上記第3の記録単位(ストリームブロック)でのデータサイズと時間情報の内の少なくともいずれかの情報が、上記第2の記録領域(STREAM.IFOあるいはRTR.IFO)内で書き換えられるか、または新規記録される。
【0450】
この発明の実施により得られる効果をまとめると以下のようになる。
【0451】
1.各トランスポートパケット毎の時間情報をタイムスタンプ情報として各トランスポートパケットとともに一緒に情報記憶媒体上に記録するため、
a)そのタイムスタンプ値に合わせてSTBへトランスポートパケットを転送するタイミングが分かる。
【0452】
b)そのタイムスタンプ値に合わせたタイミングでデコーダへトランスポートパケットを転送できるため、デコーダ側にバッファーがなくても破綻なく安定にデコードと画面表示が行える。
【0453】
c)そのタイムスタンプ値を用いて個々のトランスポートパケットを識別・分別できるため、アクセス時の到着位置指定や編集時の範囲指定が容易となる。
【0454】
2.セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置(ストリームオブジェクトの最後の位置)のセクタ内にのみパディングエリアを設定する。このため、効率良く情報記憶媒体上にストリームデータを記録できる。その結果、トランスポートパケット毎に分割されたストリームデータの録画記録時には情報記憶媒体の実行容量をほとんど低下させずに記録できる。
【0455】
3.セクタ内のパケットヘッダを除いた残りの部分にタイムスタンプとトランスポートパケットを順次詰めて記録し、タイムスタンプの切れ目またはトランスポートパケット毎に記録されるストリームデータの切れ目がセクタの境界位置とは異なる場合には、タイムスタンプまたはトランスポートパケットのどちらかを隣のセクタに跨って配置記録し、映像の録画終了位置(ストリームオブジェクトの最後の位置)のセクタ内にのみパディングエリアを設定する。このため、セクタサイズ(2048kバイト)よりも大きなサイズのトランスポートパケットを記録することができる。
【0456】
4.この発明の実施の形態に従えば、各セクタ内でパケットヘッダ直後にタイムスタンプがくるとは限らない。従って、各ストリームブロック毎の時間情報の抽出方法として、この発明の実施の形態では、各ストリームブロック内の最初に配置されたタイムスタンプ(前のストリームブロックから跨って記録されたタイムスタンプを除く)の値を各ストリームブロック先頭時刻として取り扱うことにより、管理ファイル(STREAM.IFOあるいはRTR.IFO)内のタイムマップ情報の作成を可能としている。そうすると、このタイムマップ情報を用いた所定のトランスポートパケットに対するアクセスが容易となる。
【0457】
5.STREAM.VROファイルあるいはRTR_MOV.VROファイル内のストリームデータに対してセクタ単位での部分消去を可能にすると、DVD−RAMなどの情報記憶媒体に対する記録最小単位(セクタ単位)でのSTREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放が可能となる。その結果、STREAM.VROファイルあるいはRTR_MOV.VROファイルから開放されたセクタに対して後でコンピュータデータを記録する等の有効利用が可能となる。
【0458】
なお、上記内容と異なった部分消去単位として、例えばストリームブロック(SOBU)単位でしか部分消去(STREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放)しない場合には、ユーザがセクタサイズ程度の細かい範囲での部分消去を指定しても部分消去範囲が狭いために実質的にSTREAM.VROファイルあるいはRTR_MOV.VROファイルの部分開放が生じない。その結果、ユーザが指定した細かい範囲での部分消去の指定領域を他のデータ記録に利用できず、実質的には情報記憶媒体上に情報が記録されない無駄領域が増える危険性がある。とはいえ、この発明はSOBU単位での部分消去の利用を排除するものではない。
【0459】
6.情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設け、その管理ファイル内にストリームデータの再生時の再生単位を表すセルに関する情報を記録したセル情報を記録する。そのセルに関する開始/終了位置情報をタイムスタンプに対応した時間情報で持たせることにより、タイムスタンプ値で代表されるトランスポートパケットが指定できる。このようにセルの開始/終了位置情報を時間情報で記述させることで、部分消去後の再生範囲を実質的にトランスポートパケット単位で細かく指定できる。
【0460】
7.情報記憶媒体上にストリームデータを記録するファイル(STREAM.VROあるいはRTR_MOV.VRO)とは別に、そのファイル内のストリームデータを管理する管理ファイル(STREAM.IFOあるいはRTR.IFO)を設け、さらにその管理ファイル内存在するストリームファイル情報内にストリームオブジェクト開始時間とストリームオブジェクト終了時間情報を持たせる。そして、部分消去後はIピクチャ開始位置が記録されているトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト開始時間の値に設定し直し、あるいは部分消去境界位置を含むストリームデータの直後にくるIピクチャ開始位置が記録されているトランスポートパケットの1個前のトランスポートパケットに対応したタイムスタンプ値をストリームオブジェクト終了時間の値に設定し直すことでIピクチャ開始位置を境界位置としたストリームデータの部分消去(分割)が可能となる。その結果、
a)デコーダが常にIピクチャ位置からデコード開始できるので、フレーム単位の任意位置から表示開始が可能となる。
【0461】
b)管理ファイル(STREAM.IFOあるいはRTR.IFO)の情報から常にIピクチャ位置が分かり、Iピクチャ開始位置を区切りにストリームデータが分割されているので異なる複数のストリームオブジェクトを連続して再生する場合に、ストリームオブジェクトの切れ目(変わり目)で画面が乱れることなくシームレスに連続して映像再生が行える。
【0462】
8.アイソクロナスパケットヘッダ343、344にIピクチャ位置を示すフラグを設けることで、STB装置416から光ディスク装置415に対してストリームデータ(トランスポートパケット)の転送と同時にIピクチャ位置情報をリアルタイムで通知できる。その結果、容易にストリームデータ記録ファイル(STREAM.VROあるいはRTR_MOV.VRO)内にIピクチャ位置情報をリアルタイムで記録できるとともに、管理ファイル(STREAM.IFOあるいはRTR.IFO)内にも容易にIピクチャ位置情報を記録できる。
【0463】
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
【0464】
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から1または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも1つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。
【符号の説明】
【0465】
201…情報記憶媒体/情報記憶媒体(DVD−RAMディスク等);415…光ディスク装置;416…セットトップボックス装置。
【特許請求の範囲】
【請求項1】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、
前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、
1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、
前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、
前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体。
【請求項2】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる記録方法において、
前記データ領域に前記ストリームデータを記録し、前記管理領域に前記管理情報を記録する記録方法。
【請求項3】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる再生方法において、
前記管理領域から前記管理情報を再生し、前記データ領域から前記ストリームデータを再生する再生方法。
【請求項4】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる再生装置において、
前記管理領域から前記管理情報を再生する手段と、前記データ領域から前記ストリームデータを再生する手段を具備した再生装置。
【請求項5】
前記ストリームデータがMPEGストリームを含む請求項5に記載の情報媒体。
【請求項1】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、
前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、
1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、
前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、
前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体。
【請求項2】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる記録方法において、
前記データ領域に前記ストリームデータを記録し、前記管理領域に前記管理情報を記録する記録方法。
【請求項3】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる再生方法において、
前記管理領域から前記管理情報を再生し、前記データ領域から前記ストリームデータを再生する再生方法。
【請求項4】
トランスポートパケットを用いてMPEGのIピクチャ情報を含むストリームデータが記録されたデータ領域と、前記ストリームデータに関する管理情報が記録された管理領域とを有する情報媒体であって、前記トランスポートパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現したときに、1以上の前記第1データ単位を含む1以上の前記第2データ単位により前記データ領域に記録される前記ストリームデータが形成され、前記第2データ単位は前記トランスポートパケットの到着時間に基づく単位であり、前記管理情報が、前記ストリームデータの一部または第2データ単位のエントリ数に関する情報を含むタイムマップ情報と、前記ストリームデータの記録順序に対応した再生順序を示すオリジナル管理情報と、前記ストリームデータの記録順序と異なることができる再生順序を示すユーザ定義管理情報を備えた情報媒体を用いる再生装置において、
前記管理領域から前記管理情報を再生する手段と、前記データ領域から前記ストリームデータを再生する手段を具備した再生装置。
【請求項5】
前記ストリームデータがMPEGストリームを含む請求項5に記載の情報媒体。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【公開番号】特開2009−295271(P2009−295271A)
【公開日】平成21年12月17日(2009.12.17)
【国際特許分類】
【出願番号】特願2009−208875(P2009−208875)
【出願日】平成21年9月10日(2009.9.10)
【分割の表示】特願2009−146823(P2009−146823)の分割
【原出願日】平成12年3月17日(2000.3.17)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(390010308)東芝デジタルメディアエンジニアリング株式会社 (192)
【Fターム(参考)】
【公開日】平成21年12月17日(2009.12.17)
【国際特許分類】
【出願日】平成21年9月10日(2009.9.10)
【分割の表示】特願2009−146823(P2009−146823)の分割
【原出願日】平成12年3月17日(2000.3.17)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(390010308)東芝デジタルメディアエンジニアリング株式会社 (192)
【Fターム(参考)】
[ Back to top ]