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

ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置 Download PDF

Info

Publication number
JP3806020B2
JP3806020B2 JP2001325399A JP2001325399A JP3806020B2 JP 3806020 B2 JP3806020 B2 JP 3806020B2 JP 2001325399 A JP2001325399 A JP 2001325399A JP 2001325399 A JP2001325399 A JP 2001325399A JP 3806020 B2 JP3806020 B2 JP 3806020B2
Authority
JP
Japan
Prior art keywords
data
information
stream
time
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001325399A
Other languages
English (en)
Other versions
JP2002197808A (ja
Inventor
秀夫 安東
和之 宇山
雄司 伊藤
伸一 菊地
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Toshiba Development and Engineering Corp
Original Assignee
Toshiba Corp
Toshiba Digital Media Engineering Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp, Toshiba Digital Media Engineering Corp filed Critical Toshiba Corp
Priority to JP2001325399A priority Critical patent/JP3806020B2/ja
Publication of JP2002197808A publication Critical patent/JP2002197808A/ja
Application granted granted Critical
Publication of JP3806020B2 publication Critical patent/JP3806020B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Television Signal Processing For Recording (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Description

【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などの大容量ディスクメディアを利用したストリーマが考えられる。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性が出てくる。
【0009】
ここで、デジタルTVの受信装置であるSTBとDVD−RAMなどの大容量ディスクメディアを利用したストリーマとの間、あるいはこの大容量ディスクメディアを利用したストリーマとD−VHS等を利用した他のストリーマとの間のデータ転送には、IEEE1394等に準拠したデジタルインターフェースを利用できる。
【0010】
このデジタルインターフェースでは、デジタル放送で受信したトランスポートパケット毎に映像データ/ストリームデータが転送される。
【0011】
たとえばIEEE1394を用いたデジタルインターフェースでは、デジタル放送の受信データに対して実時間での転送を保証するため、各トランスポートパケット毎に受信時刻を表すタイムスタンプデータが付加されて、転送が行なわれている。
【0012】
また、DVD−RAMなどの情報記憶媒体に記録された上記デジタル放送の受信データに対してSTBでの実時間による間断の無い再生を保証するため、情報記憶媒体上に、各トランスポートパケットデータとともに上記タイムスタンプデータも同時に記録される。
【0013】
【発明が解決しようとする課題】
上記の場合、DVD−RAMなどの大容量ディスクメディアを利用した情報記憶媒体に記録するストリームデータとして、トランスポートパケット毎にタイムスタンプデータが付加されて記録されている。このため、このタイムスタンプデータを利用して時間管理を行うことになる。
【0014】
デジタルTVでは、映像データはMPEG2と呼ばれるデジタル圧縮方式を用いて情報圧縮された形で放送される。このMPEG2方式によると、Pピクチャ情報はIピクチャに対する差分情報しか持たず、またBピクチャ情報はIピクチャとPピクチャに対する差分情報しか持っていない。したがって、BピクチャあるいはPピクチャは単独で再生することができず、これらを再生するためにはIピクチャからの再生が必要となる。
【0015】
ここで、I、B、Pの各ピクチャの表示時刻で示されるユーザから見た映像再生時間と、前記タイムスタンプ時間とは異なる。このため、情報記憶媒体上に記録したストリームデータに対する時間管理をタイムスタンプデータのみで行った場合には、ユーザに対する表示時刻(映像再生時間)の制御が正確に行えないという問題が生じる。
【0016】
この発明は上記事情に鑑みなされたもので、その目的は、ストリーム情報記録の処理に関する改善を図ることである。
【0017】
【課題を解決するための手段】
この発明の一実施の形態に係る情報記憶媒体は、MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つ。この情報記憶媒体において、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより、前記データエリアに記録される前記ストリームデータが形成される。前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成される。また、前記第2データ単位は前記ヘッダ情報を含み、前記ヘッダ情報が前記第1データ単位の時間に関する情報を含む。ここで、前記第1データ単位の時間に関する情報として、前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または、前記第1データ単位の時間に関する情報として、前記第1データ単位のタイムスタンプの位置を示す情報が記録される。また、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ、前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録されるように構成される
【0018】
【発明の実施の形態】
以下、図面を参照して、この発明の一実施の形態に係るストリームデータ記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法その他を説明する。
【0019】
図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図1を用いて情報記憶媒体上に記録されたストリームデータのデータ構造について説明する。
【0020】
DVD−RAMディスク等の情報記憶媒体(図3その他の201)上に記録されるストリームデータ(STREAM.VRO)106(図1(a))は、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(以下、適宜SOBと略記する)としてまとめられている。つまり、各SOBは、1つのリアルタイムな連続記録により得られたストリームデータにより形成される。
【0021】
情報記憶媒体上に記録されるストリームデータは、図1(b)に示されるように、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(SOB)#A・298、#B・299としてまとまって記録されている。
【0022】
図1(b)〜(k)は、複数あるストリームオブジェクト(SOB#A、#B、…)のうち、1個のSOB#A・298について内容を詳細に示している。
【0023】
DVD−RAMディスクにトリームデータ(STREAM.VRO)106が記録される場合には、各々が2048バイトのセクタを最小単位として記録される。さらに、16個のセクタをまとめて1個のECCブロックとし、同一ECCブロック内でインターリーブ(データ配列順序の並び替え)とエラー訂正用の訂正コードの付加が行われる。
【0024】
この実施の形態では、1個または複数(代表的には2個)のECCブロックを単位としてストリームブロック(あるいはストリームオブジェクトユニットSOBU)が構成され、このストリームブロック単位(あるいはSOBU単位)でストリーム情報の記録、部分消去、編集その他が行われる。
【0025】
この実施の形態では、何個のECCブロックでストリームブロックが構成されるかは、転送されるストリームデータ(STREAM.VRO)106の転送レートに応じて決めることができる。
【0026】
たとえば、図1(c)(d)の例では、ストリームブロック#1は2つのECCブロック#α、#βで構成され、ストリームブロック#2は3つのECCブロック#γ、#δ、#εで構成されている。DVDストリーマでは、2個のECCブロック(32セクタ)で1つのストリームブロック(またはSOBU)が構成される。
【0027】
各ECCブロックは、図1(e)に示すように、16セクタで構成される。したがって、図1(c)〜(e)から分かるように、2ECCブロックで構成されるストリームブロック(あるいはSOBU)#1は、32セクタ(セクタNo.0〜セクタNo.31)に相当する。
【0028】
つまり、1セクタ=2kバイトとすれば、ストリームブロック(SOBU)は、64kバイト(32セクタ)の固定サイズとして、この発明を実施することができる。
【0029】
ストリームデータ(STREAM.VRO)106は、図1(g)に示すようにタイムスタンプとトランスポートパケットを組にして、情報記憶媒体に記録される。
【0030】
その際、各セクタの先頭には、図1(f)に示すように、システムクロック情報(システムクロックリファレンスSCR)等が記録されたパックヘッダ11、12とPESヘッダ13、14が配置される。PESヘッダ14の直後にはセクタデータヘッダ17が記録されるが、各ストリームブロック(またはSOBU)先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ16が記録される。
【0031】
なお、ストリームブロックヘッダ16あるいはセクタデータヘッダ17は、後述するアプリケーションヘッダに対応する内容を持つことができるようになっている(図9あるいは図10参照)。
【0032】
図1(f)のセクタデータヘッダ17は、データエリア22、23内のデータ配列情報を示している。
【0033】
図1(f)のデータエリア21、22(あるいは23)には、図1(g)に示すように、タイムスタンプ(図20、図29その他に示したATSに対応)およびトランスポートパケット(図22または図23のパケット、あるいは図29のアプリケーションパケットAPに対応)が逐次詰め込まれる。
【0034】
図1(g)の例では、1個のトランスポートパケットdが複数のセクタ(No.0とNo.1)に跨って記録される場合が例示されている。このようなトランスポートパケットdは、図22または図23の部分パケットに対応する。
【0035】
ところで、デジタル放送では、トランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式が採用されており、1個のトランスポートパケットのサイズは188バイト(または183バイト)の場合が多い。
【0036】
一方、前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても、1個のデータエリア21、22、23(図1(f))内には、デジタル放送用のトランスポートパケットを10個前後記録できる。
【0037】
トランスポートパケット内は、図1(h)に示すように、トランスポートパケットヘッダ61〜64(後述する図23(b)の511に対応)とデータが記録されているペイロード71〜75(後述する図23(b)の512に対応)とで構成されている。
【0038】
ペイロード71〜75には、図1(i)に示すように、MPEGエンコードされたIピクチャ情報31、Bピクチャ情報33、34、およびPピクチャ情報32が記録される。
【0039】
Iピクチャ情報31が記録されている最初のトランスポートパケットでは、ランダムアクセスインジケータ503(図23(a)参照)に”1”のフラグが立ち、各B、Pピクチャ情報32〜34の最初のトランスポートパケットにはペイロードユニット開始インジケータ501(図23(a)参照)に”1”のフラグが立つ。
【0040】
ペイロード71〜75内に分割記録されている各ピクチャ情報31〜34には、図1(j)に示すように、それぞれの先頭に、ピクチャヘッダ情報41と、実質的なピクチャ情報であるピクチャ圧縮情報42(Iピクチャ情報31に対してはIピクチャ圧縮情報42)とが記録されている。
【0041】
また、それぞれのピクチャヘッダ情報41内には、図1(k)に示すように、ヘッダ識別情報51、それぞれのI、B、Pピクチャの識別を可能とするピクチャ識別情報52、デコーダ出力の表示タイミングを示すPTS(プレゼンテーションタイムスタンプ)情報53、およびデコーダがデコード開始を行うためのタイミングを示すDTS(デコードタイムスタンプ)情報54が記録されている。これらのピクチャヘッダ情報41は、デジタル放送の受信情報内に予め含まれている。
【0042】
情報記憶媒体上に記録されたストリームデータ内では、図1(k)に示すピクチャ識別情報52を用いて特定のピクチャ位置を同定できる。
【0043】
あるいは、図1(j)(k)に示すようにピクチャヘッダ情報41内にPTS情報53が記録されているので、この値を用いてデコーダが表示を開始することも可能である。
【0044】
図2は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図2を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容(ファイル構造)について説明する。
【0045】
DVDーRAMディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、DVD_RTRディレクトリ(またはDVD_RTAV)102と言う名のサブディレクトリ101内に入っている。
【0046】
DVD_RTR(DVD_RTAV)ディレクトリ102内には、以下の内容のデータファイル103が格納される。
【0047】
すなわち、管理情報(ナビゲーションデータ)のグループとして、RTR.IFO(またはVR_MANGR.IFO)104と、STREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、SR_PRIVT.DAT/SR_PRIVT.BUP105aとが格納される。
【0048】
また、データ本体(コンテンツ情報)として、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とが格納される。
【0049】
上記データファイル103を含むサブディレクトリ101の上位階層にあるルートディレクトリ100には、その他の情報を格納するサブディレクトリ110を設けることができる。
【0050】
このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットVIDEO_TS111、オーディオプログラムを収めたオーディオタイトルセットAUDIO_TS112、コンピュータデータ保存用のサブディレクトリ113等がある。
【0051】
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
【0052】
そのストリームデータそのものはSTREAM.VRO(またはSR_TRANS.SRO)106と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、STREAM.IFO(またはSR_MANGR.IFOとそのバックアップファイルSR_MANGR.BUP)105である。
【0053】
また、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である。
【0054】
図3は、この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【0055】
図3(a)の情報記憶媒体201の内周方向202の端部と外周方向203の端部とで挟まれた領域には、図3(b)に示すように、リードインエリア204と、ファイルシステム情報が記録されているボリューム&ファイル構造情報206と、データエリア207と、リードアウトエリア205が存在する。リードインエリア204はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア205は書替可能データゾーンで構成されている。データエリア207も書替可能データゾーンで構成されている。
【0056】
データエリア207内は、図3(c)に示すように、コンピュータデータとオーディオ&ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア208およびコンピュータデータエリア209の間に、オーディオ&ビデオデータエリア210が、挟まれる形態となっている。
【0057】
オーディオ&ビデオデータエリア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とが記録される。
【0058】
同じく図3(e)に示すように、ストリーム記録エリア222には、図2に示された、ストリーマのナビゲーションデータSTREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、トランスポートビットストリームデータSTREAM.VRO(SR_TRANS.VRO)106とが記録される。
【0059】
なお、図3(d)(e)では図示しないが、ストリーム記録エリア222には、図2に示したアプリケーション固有のナビゲーションデータSR_PRIVT,DAT/SR_PRIVT.BUP105aを記録することもできる。
【0060】
このSR_PRIVT,DAT105aは、ストリーマに接続(供給)された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
【0061】
ストリームデータに関する管理情報であるSTREAM.IFO(またはSR_MANGR.IFO)105は、図3(f)〜(i)に示すようなデータ構造を有している。
【0062】
すなわち、図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とで構成されている。
【0063】
図3(f)のストリームファイル情報テーブル(SFIT)232は、図3(g)に示すように、ストリームファイル情報テーブル情報(SFITI)241と、1以上のストリームオブジェクト情報(SOBI)#A・242、#B・243、………と、オリジナルPGC情報一般情報271と、1以上のオリジナルセル情報#1・272、#2・273………とを含むことができるようになっている。
【0064】
図3(g)の各ストリームオブジェクト情報(たとえばSOBI#A・242)は、図3(h)に示すように、ストリームオブジェクト一般情報(SOBI_GI)251、タイムマップ情報252、その他を含むことができる。
【0065】
また、図3(g)の各オリジナルセル情報(たとえば#1・272;後述するが図14で示されるSCIに対応)は、図3(h)に示すように、セルタイプ281(後述するが図14で示されるC_TYに対応)と、セルID282と、該当セル開始時間(後述する図6(b)、図14その他で示されるSC_S_APATに対応)283と、該当セル終了時間(後述する図6(b)、図14その他で示されるSC_E_APATに対応)284と、PTSオフセット9と、時間関係テーブル2とを含むことができる。
【0066】
ここで、PTSオフセット9とは、オリジナルセル(オリジナルセルの詳細は後述する)の表示開始ピクチャのPTS(プレゼンテーションタイムスタンプ)値とその直前にあるIピクチャのPTS値との差分をいう(詳細は図20を参照して後述)。
【0067】
図3(g)のSOBI#Aに含まれる図3(h)のタイムマップ情報252は、図3(i)に示すように、ストリームブロック番号261、第1ストリームブロックサイズ262、第1ストリームブロック時間差263、第2ストリームブロックサイズ264、第2ストリームブロック時間差265、………を含むことができる。タイムマップ情報252を構成する各ストリームブロック時間差の内容については、図5を参照して後述する。
【0068】
図4は、この発明の一実施の形態におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。以下、図4の例示を用いてSOBとPGCの関係を説明する。
【0069】
ストリームデータ(STREAM.VROまたはSR_TRANS.SRO)106内に記録されたストリームデータは、1個以上のECCブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等がなされる。このストリームデータは、記録する情報の内容毎(たとえばデジタル放送での番組毎)にストリームオブジェクトと言うまとまりを作る。
【0070】
STREAM.VRO(SR_TRANS.SRO)106内に記録されたストリームオブジェクト(SOB#A、SOB#B)毎の管理情報(オリジナルPGC情報233、ユーザ定義PGC情報テーブル234等)は、ナビゲーションデータSTREAM.IFO(SR_MANGR.IFO)105(図4の最下部および図3(e)(f)参照)内に記録されている。
【0071】
図4の各ストリームオブジェクト#A・298、#B・299毎の管理情報(STREAM.IFO105)は、図3(f)(g)に示すように、ストリームファイル情報テーブル(SFIT)232内のストリームオブジェクト情報(SOBI)#A・242、#B・243として記録されている。
【0072】
ストリームオブジェクト情報(SOBI)#A・242、(SOBI)#B・243それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報252を含んでいる。
【0073】
ストリームデータの再生時には、1個以上のセルの連続で構成されるプログラムチェーン(PGC)の情報(後述する図14のPGCI#iに対応)が利用される。このPGCを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
【0074】
PGCには、STREAM.VRO(SR_TRANS.SRO)106に記録された全ストリームデータを連続して再生することのできるオリジナルPGC290(図3(f)ではORG_PGCI・233)と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義PGC#a・293、#b・296(図3(f)ではUD_PGCIT・234の中身に対応)の2種類が存在する。
【0075】
オリジナルPGC290を構成するオリジナルセル#1・291、#2・292は、基本的にストリームオブジェクト#A・298、#B・299と一対一に対応して存在する。
【0076】
それに対して、ユーザ定義PGCを構成するユーザ定義セル#11・294、#12・295、#31・297は、1個のストリームオブジェクト#A・298または#B・299の範囲内では任意の位置を設定することができる。
【0077】
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図4のストリームブロック#1のように、2ECCブロック(32セクタ)で一定サイズ(64kバイト)のストリームオブジェクトユニット(SOBU)を、ストリームブロックとして採用するとよい。
【0078】
このようにストリームブロックを一定サイズ(たとえば2ECCブロック=32セクタ=64kバイト)のSOBUに固定すれば、次の利点が得られる:
(01)SOBU単位でストリームデータの消去あるいは書替を行っても、そのSOBUのECCブロックが、消去あるいは書替対象以外のSOBUのECCブロックに影響しない。そのため、消去あるいは書替に伴う(消去あるいは書替の対象でないSOBUに対する)ECCのデインターリーブ/インターリーブのやり直しが、生じない;
(02)任意のSOBU内部の記録情報に対するアクセス位置を、セクタ数(あるいはセクタ数に対応した他のパラメータ;たとえば後述する図10のストリームパックおよびその内部のアプリケーションパケット群の情報)で特定できる。たとえば、あるSOBU#kの中間位置にアクセスする場合は、SOBU#kー1とSOBU#kとの境界から16セクタ目(あるいは16セクタ目に対応するアプリケーションパケットの位置)を指定すればよい。
【0079】
図5は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図5を用いてタイムマップ情報252内の各データの内容について説明する。
【0080】
図5(f)(g)(h)に例示するように、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1、#2で構成されている。
【0081】
図5(f)(h)の例では、SOB#A・298を構成するストリームブロック#1のデータサイズは2ECCブロック(#α、#β)で構成され、32セクタ分(図5(e)(i))のサイズを持っている。すなわち、タイムマップ情報252(図5(a)(k))内の第1ストリームブロックサイズ262(図5(j))は、32セクタ(64kバイト)となる。
【0082】
SOB#A・298(図5(g))の先頭にあるストリームブロック#1(図5(f))はその先頭にセクタNo.0(図5(e))を持ち、セクタNo.0に含まれるデータエリア21(図5(d))の先頭にはタイムスタンプa(図5(c))が記録されている。
【0083】
また、SOB#A・298(図5(g))の後続ストリームブロック#2(図5(f))はその先頭にセクタNo.32(図5(e))を持ち、セクタNo.32に含まれるデータエリア311(図5(d))の先頭にはタイムスタンプp(図5(c))が記録されている。
【0084】
図5(c)に示すように、ストリームブロック#1の最初のストリームデータのタイムスタンプ値はタイムスタンプaであり、次のストリームブロック#2の最初のストリームデータのタイムスタンプ値はタイムスタンプpとなっている。
【0085】
図5(b)の第1ストリームブロック時間差263(図3(i)のストリームブロック時間差263に対応)の値は、上記タイムスタンプpとタイムスタンプaとの差分値([タイムスタンプp]−[タイムスタンプa])で与えられる。
【0086】
なお、図5(a)のタイムマップ情報252は、図15を参照して後述するストリームオブジェクト情報SOBI内のアクセスデータユニットAUDも含むものとして、取り扱うことができる。このAUDに含まれる情報(アクセスユニット開始マップAUSM等)により、アクセスしたい情報を含むSOBUを特定できる。
【0087】
図6は、オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図である。それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。
【0088】
具体的には、ストリームデータの録画直後のオリジナルセルにおける該当セルの開始時間283および該当セルの終了時間284(図6(b))の時間として、該当するストリームオブジェクト#A・298(図6(f))内の最初のタイムスタンプaの値および最後のタイムスタンプz(図6(c))の値が使用される。
【0089】
それに対して、ユーザ定義セル#12・295(図6(k))での時間範囲指定は、任意時刻を指定できる。たとえば、図6(i)(j)に示すように指定されたトランスポートパケットd、nに対応したタイムスタンプd、nの値を、該当セルの開始時間331と該当セルの終了時間332の値として設定することができる。
【0090】
図6(f)は、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1および#2で構成されている場合を例示している。
【0091】
図6(e)(g)の例では、ストリームブロック#1は32セクタ(セクタNo.0〜No.31)で構成され、ストリームブロック#2は48セクタ(セクタNo.32〜No.79)で構成されている。
【0092】
ストリームブロック#1の先頭セクタNo.0は、図6(e)(d)に示すように、パックヘッダ1、PESヘッダ6、ストリームブロックヘッダ11、データエリア21等で構成されている。
【0093】
また、ストリームブロック#2の後方セクタNo.78は、図6(e)(d)に示すように、パックヘッダ3、PESヘッダ8、セクタデータヘッダ13、データエリア24等で構成されている。
【0094】
さらに、図6(g)のセクタNo.1には図6(h)に示すようにパックヘッダ2、セクタデータヘッダ12、データエリア22その他が記録され、図6(g)のセクタNo.33には図6(h)に示すようにセクタデータヘッダ321、データエリア312その他が記録されている。
【0095】
図6(d)(h)のデータエリア21には、図6(c)(i)に示すように、タイムスタンプaとトランスポートパケットaとのペアないしタイムスタンプdとトランスポートパケットdとのペアが記録されている。
【0096】
また、図6(d)のデータエリア24の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプz+トランスポートパケットzのペアの後に続くエンドコード32と、パディングエリア37が記録されている。
【0097】
さらに、図6(h)のデータエリア22には、図6(i)に示すように、データエリア21のトランスポートパケットdの後続内容を含むトランスポートパケットdが含まれている。つまり、この例では、トランスポートパケットdの内容が、データエリア21とデータエリア22とで分断されて記録されている。
【0098】
図6(i)のトランスポートパケットdの前半部分(データエリア21側)は、後述する図23(f)の末尾側部分パケットに対応し、図6(i)のトランスポートパケットdの後半部分(データエリア22側)は、後述する図23(g)の先頭側部分パケットに対応している。
【0099】
さらに、図6(h)のデータエリア312には、図6(i)に示すように、タイムスタンプnとトランスポートパケットnとのペアおよびその他の同様なペアが記録されている。
【0100】
ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間331(図6(j))は、データエリア21および22に分断された2つのトランスポートパケットd全体に対するタイムスタンプd(図6(i))により指定される。
【0101】
トランスポートパケットをアプリケーションパケット(AP)と読み替え、アプリケーションパケット到着時間をAPATとした場合に、上記セル開始時間331は、セル開始APATとして表現できる。
【0102】
また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間332(図6(j))は、データエリア312のトランスポートパケットnに対するタイムスタンプn(図6(i))により指定される。このセル終了時間332は、セル終了APATとして表現できる。
【0103】
以上のセル開始時間(セル開始APAT)331およびセル終了時間(セル終了APAT)332は、図6(k)に示すように、ユーザ定義セル情報#12・295内部に記録できる。
【0104】
このユーザ定義セル情報#12・295は、図3(f)または図4下段に示すユーザ定義PGC情報テーブル234内に記録することができる。
【0105】
以上はユーザ定義セル情報(ユーザ定義PGCの情報)に関するセル開始/終了時間情報についてであるが、オリジナルセル情報(オリジナルセルの情報)に関するセル開始/終了時間情報については、次のような例示ができる。
【0106】
すなわち、図6(c)の先頭側タイムスタンプaにより図6(b)の該当セルの開始時間283を示すことができ、末尾側タイムスタンプzにより該当セルの終了時間284を示すことができる。
【0107】
図6(b)の該当セルの開始時間283は、セル開始APAT(ストリームセル開始APAT(SC_S_APAT)または消去開始APAT(ERA_S_APAT)も含む)に対応させることができる。
【0108】
また、図6(b)の該当セルの終了時間284は、セル終了APAT(ストリームセル終了APAT(SC_E_APAT)または消去終了APAT(ERA_E_APAT)も含む)に対応させることができる。
【0109】
以上のセル開始時間(セル開始APAT)283およびセル終了時間(セル終了APAT)284は、図6(a)に示すように、オリジナルセル情報#1・272内部に記録される。
【0110】
このオリジナルセル情報#1・272は、図3(f)または図4下段に示すオリジナルPGC情報233内に記録することができる。
【0111】
図7は、この発明の他の実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに再生終了位置情報/レジューム情報、VMGI管理情報/記録時間情報等の構造)を説明する図である。
【0112】
図7(a)〜(f)のデータ構成は、図3(a)〜(f)と同じなので、その説明は省略する。
【0113】
図7(f)のビデオマネージャ(STR_VMGI)231は、図7(g)に示すように、再生終了位置情報(レジューム情報)6110、ビデオマネージャ管理情報(VMGI_MAT)6111その他を含んでいる。
【0114】
再生終了位置情報(レジューム情報)6110は、図7(h)に示すように、オリジナルPGC番号6210、オリジナルセル番号6220、再生終了位置時刻(レジューム時刻)情報6230等を含んでいる。
【0115】
また、ビデオマネージャ管理情報(VMGI_MAT)6111は、タイムゾーン(TM_ZONE)6240を含んでいる。
【0116】
記録済みのストリームブロック(またはオリジナルセル)の再生が終了した段階で、再生終了位置情報6110をレジューム情報として図7(e)の管理情報記録領域(STREAM.IFO)内のビデオマネージャ情報231中に記録することができる。
【0117】
なお、再生終了位置情報6110に含まれる時刻情報6230はタイムスタンプ(ATS)値で記録されているが、それに限らずPTS値(あるいはセル再生先頭位置からの通算フィールド数)を時刻情報6230として記録することもできる。
【0118】
タイムゾーン(TM_ZONE)6240は、図7(i)に示すように、記録時間(REC_TM)の情報を含む。
【0119】
記録時間(REC_TM)の情報は、REC_TMがユニバーサル・タイム・コオーディネート(UTC)によるものか特定のローカルタイムによるものかを識別するタイムゾーンタイプ(TZ_TY)と、UTCからのREC_TMのタイムオフセットの日時を分単位で記述したタイムゾーンオフセット(TZ_OFFSET)とを含んでいる。
【0120】
上記記録時間(REC_TM)は、図6(b)等で示したセル開始時間(SC_S_APAT)の形式あるいはそのセルの再生時刻(プレゼンテーションタイムPTM)の形式で記述してもよい。
【0121】
この記録時間(REC_TM)には2種類ある。第1はストリームオブジェクト記録時間(SOB_REC_TM)であり、第2はプレイリスト作成時間(PL_CREATE_TM)である。
【0122】
ここで、オリジナルセルに対応するストリームオブジェクト(SOB)が記録された時間が、SOB_REC_TMにより示される。
【0123】
また、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。このようなプレイリストが作成された時間が、PL_CREATE_TMにより示される。
【0124】
図8は、図1その他に示されたPESヘッダの内部構造を説明する図である。
【0125】
図8(a)のPESヘッダ601は、図8(b)に示すように、パケット開始コードプリフィックス602、ストリームID603、再生タイムスタンプ604等を含んでいる。このPESヘッダ601は、図1(f)、図5(d)、図6(d)等のPESヘッダに対応している。
【0126】
また、図8(d)のストリームPESヘッダは、図8(c)に示すように、パケット開始コードプリフィックス、ストリームID(プライベートストリーム2)、PESパケット長、サブストリームID等を含んでいる。このストリームPESヘッダは、後述する図22のストリームPESヘッダと同じもので、図8(a)のPESヘッダ601に対応する内容を持つ。
【0127】
図1(f)のPESヘッダが図8(a)に示すPESヘッダ601の内部構造を持つときは、MPEGの規格では、このPESヘッダのストリームID603(図8(b))が”10111110”のときに、このPESヘッダを持つパケットを、パディングパケット(後述する図12(g)参照)にすると定義されている。
【0128】
一方、ストリームID603(図8(c)のサブストリームID)が”00000010”のときは、そのPESパケットの付いたパケットは、ストリーム記録データを含むことになる。
【0129】
図1(c)のストリームブロック#1では、最後のトランスポートパケットg(図1(g))がセクタNo.0〜No.31(図1(e))内に存在している。しかし、ストリームブロック#2(図1(e)(g))では、ユーザ等により途中で録画が終了されると、最後のトランスポートパケット(図示せず)が最後のセクタより前のセクタに配置され、最後のセクタ(図示せず)内はストリームデータが記録されていない空き領域となることがある。この場合、最後のセクタには、上記パディングパケット(後述する図12(g)のパディングパケット40)が記録される。
【0130】
図9は、図1に示されたストリームブロックヘッダの内部構造を説明する図である。
【0131】
ストリームブロックヘッダ11は、図9(a)に示すように、サブストリームID、アプリケーションヘッダ、アプリケーションヘッダエクステンション、スタッフィングバイト等に対応した内容を持つ。
【0132】
1バイトのアプリケーションヘッダエクステンション(オプション)には、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが、記述される。
【0133】
AU_STARTが”1”にセットされると、関連するアプリケーションパケット(たとえば図29のAP)が、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。
【0134】
AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【0135】
COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0136】
ストリームブロックヘッダ11は、図9(b)に示すように、トランスポートパケット情報611、ストリームブロック情報612、セクタデータヘッダ情報613等を含んでいる。
【0137】
図9(b)のトランスポートパケット情報611は図9(c)のトランスポートパケット情報611と同じものを指す。
【0138】
ストリームブロック全体に関する情報が記録されている図9(b)のストリームブロック情報612は、図9(c)の記録時間622(情報記憶媒体201に記録した年月日と時刻情報)、トランスポートパケット属性623(トランスポートパケットに関する属性情報)、ストリームブロックサイズ624(該当するストリームブロックのデータサイズ(たとえばECCブロック数で記載できる))、ストリームブロック時間差625等に対応する。
【0139】
ここで、図5(b)を例にとれば、該当ストリームブロック内の時間範囲情報は、[ストリームブロック時間差]=[ストリームブロック#2内の最初にくるタイムスタンプ値]−[タイムスタンプaの値]として計算される。この[ストリームブロック時間差]が、ストリームブロック時間差625となる。
【0140】
また、図9(b)のセクタデータヘッダ情報613は、図9(c)のファーストアクセスポイント626およびトランスポートパケット接続フラグ627に対応する。このセクタデータヘッダ情報613は、後述する図10のセクタデータヘッダ12と同様な情報を含んでいる。
【0141】
図9(c)のトランスポートパケット情報611は、図9(d)に示すように、トランスポートパケットの数(アプリケーションパケットの数)631、トランスポートパケットマッピングテーブル632等を含んでいる。
【0142】
なお、図9(d)のアプリケーションパケットの数は、後述する図10(c)または図11のパケット数AP_Nsに対応している。
【0143】
図9(d)のトランスポートパケット(アプリケーションパケット)の数631は、図9(e)に示すように、Iピクチャマッピングテーブル641、B,Pピクチャマッピングテーブル642等を含むことができる。
【0144】
また、図9(d)のトランスポートパケットマッピングテーブル632は、ビデオパケットマッピングテーブル643、オーディオパケットマッピングテーブル644、プログラム固有情報マッピングテーブル645等を含むことができる。
【0145】
トランスポートパケットマッピングテーブル632内の各マッピングテーブル(図9(e))は、ビットマップ形式で構成されている。
【0146】
たとえば、1個のストリームブロック内にn個のトランスポートパケット(アプリケーションパケット)が記録されている場合には、図9(d)のトランスポートパケット数(アプリケーションパケット数)631の値は”n”となる。
【0147】
さらに、各マッピングテーブル643〜645は”nビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット(アプリケーションパケット)に対してそれぞれ1ビットずつが割り当てられている。
【0148】
図10は、図1に示されたセクタデータヘッダの内部構造を説明する図である。
【0149】
たとえば図1(f)のセクタデータヘッダ17は、データエリア22、23内のデータ配列情報を示すもので、図10(a)のセクタデータヘッダ(図10(d)のアプリケーションヘッダに対応)12に相当する。
【0150】
セクタデータヘッダ12は、図10(b)に示すように、ファーストアクセスポイント651およびトランスポートパケット接続フラグ652を含む内部構造を持っている。
【0151】
ところで、図10(d)に示すように、1セクタと同じく2048バイトのサイズを持つ1つのストリームパックは、パックヘッダおよびストリームPESヘッダで構成されている。そして、このストリームPESパケット内に、図10(a)のセクタデータヘッダ12あるいは図9(a)のストリームブロックヘッダ11の一部に対応した、アプリケーションパケットヘッダが含まれている。
【0152】
このアプリケーションパケットヘッダは、図10(c)に示すように、以下のものを含んでいる:
*アプリケーションパケットヘッダ形式のバージョン記載;
*該当ストリームパック内で開始するアプリケーションパケット(トランスポートパケット)の数AP_Ns;
*該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置FIRST_AP_OFFSET;
*ヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報EXTENSION_HEADER_IFO;
*該当ストリームを生成したサービスの識別子SERVICE_ID。
【0153】
上記図10(d)のアプリケーションパケットに含まれるFIRST_AP_OFFSETは、図10(a)のセクタデータヘッダ12に含まれるファーストアクセスポイント651に対応する。
【0154】
図1(g)に示すように、トランスポートパケットdは2個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ652が”1”に設定される。
【0155】
また図1(g)の例では、次のセクタへ跨ったトランスポートパケットdの次にくるタイムスタンプ先頭位置のデータエリア22内のアドレスが、ファーストアクセスポイント651内に記録(ビット単位の表現)されている。
【0156】
図1(e)に示すセクタNo.1(またはその対応ストリームパック)のファーストアクセスポイント値を、セクタNo.1のデータエリア22(図1(f))のサイズよりも大きな値に設定することができる。そうすることにより、セクタNo.1内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。
【0157】
この発明の一実施の形態では、ファーストアクセスポイント651の値としてデータエリア21、22、23のサイズよりも大きな値を指定可能にすることで、セクタサイズ(あるいはストリームパックサイズ=2048バイト)よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。
【0158】
たとえば、図1のデータ構造において、1個のパケットがセクタNo.0からセクタNo.2まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタNo.0のデータエリア21内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタNo.2のデータエリア内のTビット目に配置されている場合を考える。
【0159】
この場合、セクタNo.0のファーストアクセスポイントの値は”0”、セクタNo.1のファーストアクセスポイントの値は”セクタNo.1のデータエリア22サイズ+T”、セクタNo.2のファーストアクセスポイントの値は”T”となる。
【0160】
図11は、この発明の一実施の形態におけるタイムマップ情報252の他例を説明する図である。
【0161】
このタイムマップ情報252は、図3(h)(i)のタイムマップ情報252とは別の例であり、各ストリームブロック(最初のストリームブロック、2番目のストリームブロック、…)毎に、ストリームブロックサイズとストリームブロック時間差とパケット数(AP_Ns)とを記述したテーブル情報である。
【0162】
図11のタイムマップ情報252を用い、所定の画面(ピクチャ)にアクセスするため(STB側から)通算トランスポートパケット数(または通算アプリケーションパケット数AP_Ns)が指定されたとする。すると、(ディスク装置側は)図11の最初のストリームブロックから順次トランスポートパケット数(AP_Ns)を加算して行き、指定された値に達した時点でのストリームブロックへアクセスする。
【0163】
図12は、ストリームブロック(SOBU)を構成するセクタの内部構成(アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック)の一例を説明する図である。
【0164】
図12(d)のストリームオブジェクト(SOB)#A・298は、図12(c)(e)に示すように、複数のストリームブロック#1、#2、…で構成されている。
【0165】
各ストリームブロック#1、#2、…は全て、2ECCブロックサイズ(=32セクタ=64kバイト)のストリームオブジェクトユニット(SOBU)で構成される。
【0166】
このようにすると、たとえばストリームブロック(SOBU)#2を削除しても、ストリームブロック(SOBU)#1のECCブロックはこの削除に影響されない。
【0167】
SOB#A・298の先頭ストリームブロック(SOBU)#1は、図12(b)に示すように、セクタNo.0〜セクタNo.31(32セクタ/64kバイト)で構成されている。
【0168】
ストリームブロック(SOBU)#1の各セクタは、同様なデータ構造を持っている。、たとえばセクタNo.0についていうと、図12(a)に示すようになっている。
【0169】
すなわち、セクタNo.0は2048バイト(2kバイト)のストリームパックにより構成される。このストリームパックは、14バイトのパックヘッダと、2034バイトのストリームPESパケットとで構成される。
【0170】
ストリームPESパケットは、6バイトのPESヘッダと、1バイトのサブストリームIDと、2027バイトのストリームデータエリアとで構成される。
【0171】
ストリームデータエリアは、9バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、アプリケーションパケットエリアとで構成される。
【0172】
アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ(ATS)を先頭に持つアプリケーションパケット群で構成される。
【0173】
たとえば188バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、10個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
【0174】
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ(たとえば2048バイト)を持つものとして扱うことができる。
【0175】
図12(a)のスタッフィングバイトは、ストリームパックを常に所定長(2048バイト)に保つために利用できる。
【0176】
図12(a)のパックヘッダは、図示しないが、パック開始コードの情報、SCRベースの情報、SCRエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。
【0177】
SCRベースは32ビットで構成され、その32ビット目はゼロとされる。また、プログラム最大レートとしては、10.08Mbpsが採用される。
【0178】
図12(a)のPESヘッダおよびサブストリームIDは、図8(c)に示したような内容を持っている。
【0179】
図12(a)のアプリケーションヘッダは、図10(c)に示したように、バージョン情報、アプリケーションパケット数AP_Ns、先頭アプリケーションパケットのタイムスタンプ位置FIRST_AP_OFFSET、エクステンションヘッダ情報EXTENSION_HEADER_IFO、サービスID等を含んでいる。
【0180】
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
【0181】
アプリケーションヘッダのAP_Nsは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にATSの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
【0182】
FIRST_AP_OFFSETには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、FIRST_AP_OFFSETには「0」が記述される。
【0183】
EXTENSION_HEADER_INFOには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かが、記述される。
【0184】
EXTENSION_HEADER_INFOの内容が00bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
【0185】
EXTENSION_HEADER_INFOの内容が10bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
【0186】
EXTENSION_HEADER_INFOの内容が11bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
【0187】
EXTENSION_HEADER_INFOの内容が01bとなることは禁止されている。
【0188】
アプリケーションパケットエリアの前のスタッフィングバイト(オプション)は、「EXTENSION_HEADER_INFO=11b」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
【0189】
SERVICE_IDには、ストリームを生成するサービスのIDが記述される。このサービスが未知のものであれば、SERVICE_IDに0x0000が記述される。
【0190】
図12(a)のアプリケーションパケットエリアは、後述する図22の下段に示したと同様に構成できる(図22のパケットを図12ではアプリケーションパケットに読み替える)。
【0191】
すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプATSとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。
【0192】
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
【0193】
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ(ATS)は32ビット(4バイト)で構成される。このATSは、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0194】
図12(a)において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。
【0195】
それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを(前述したEXTENSION_HEADER_INFOにおいて)記述できるように定義されいる。
【0196】
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
【0197】
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。
【0198】
後述する図22あるいは図23(f)(g)に示した部分アプリケーションパケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
【0199】
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。
【0200】
こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
【0201】
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
【0202】
アプリケーションヘッダエクステンション(オプション)はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する1バイト長の1エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
【0203】
なお、1バイトのアプリケーションヘッダエクステンション(オプション)には、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが、記述される。
【0204】
AU_STARTが”1”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。
【0205】
AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【0206】
COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0207】
図12(a)のパケット構造は、SOB#A・298の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。
【0208】
たとえば、SOB#A・298の末尾が図12(f)のセクタNo.63であり、このセクタが図12(g)に示すようにパディングパケット40で構成されるときは、そのパディングエリア38(図12(h))の内容が、図12(a)と違ったものになる。
【0209】
すなわち、図12(i)に示すように、パディングパケット40としてのスタッフィングパケットは、14バイトのパックヘッダと、6バイトのPESヘッダと、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、2018バイトのアプリケーションパケットエリアとで構成される。
【0210】
スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、4バイトのアプリケーションタイムスタンプATSおよび2014バイト分のゼロバイトデータ(実質的な記録内容を持たないデータ)で構成される。
【0211】
一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、2018バイト分のゼロバイトデータ(ATSなし)で構成される。
【0212】
ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報(図3(h)の252;あるいは後述する図15のSOBI内MAPL)の回復(再生)を確実にするために、スタッフィングが必要になる。図12(i)のスタッフィングパケットは、そのための概念的な単位として定義されている。
【0213】
このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。
【0214】
スタッフィングパケットには、以下の条件が付く:
*1または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する;
*1または複数のスタッフィングパケットは、1つの4バイトATSと、該当SOBUの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ(ATSの後に続く)とで構成される。いま、SOBU1個あたりのセクタ数をSOBU_SIZとしたときに、0≦n≦SOBU_SIZー1とすれば、スタッフィングパケットの全長は、「4+2014+n×2018」バイトとなる。
【0215】
スタッフィングパケットのATSは、次のように設定される:
*少なくとも1個のパックが実際のアプリケーションパケットデータを含んでいるSOBU内では、スタッフィングパケットのATSは、スタッフィングパケットに先行するアプリケーションパケットのATSに設定される;
*実際のアプリケーションパケットデータを含まないSOBU内では、スタッフィングパケットのATSはタイムマップ情報等の内容に応じて決定される。
【0216】
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される:
*パックヘッダの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)とする。
【0217】
図13は、ストリーマの管理情報(図2のSTREAM.IFOまたはSR_MANGR.IFOに対応)の内部データ構造を説明する図である。
【0218】
図2あるいは図3(e)に示した管理情報(ナビゲーションデータ)であるSTREAM.IFO(SR_MANGR.IFO)105は、図13に示すように、ストリーマ情報STRIを含んでいる。
【0219】
このストリーマ情報STRIは、図3(f)あるいは図13に示すように、ストリーマビデオマネージャ情報STR_VMGIと、ストリームファイル情報テーブルSFITと、オリジナルPGC情報ORG_PGCI(より一般的に表現すればPGC情報PGCI#i)と、ユーザ定義PGC情報テーブルUD_PGCITと、テキストデータマネージャTXTDT_MGと、アプリケーションプライベートデータマネージャAPDT_MGとで、構成されている。
【0220】
ストリーマビデオマネージャ情報STR_VMGIは、図13に示すように、STRI、STR_VMGIに関する管理情報等が記述されたビデオマネージャ情報管理情報VTSI_MATと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル(PL_SRPT)とを含んでいる。
【0221】
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。
【0222】
ストリームファイル情報テーブルSFITは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルSFITの詳細については、図15を参照して後述する。
【0223】
オリジナルPGC情報ORG_PGCIは、オリジナルPGC(ORG_PGC)に関する情報を記述した部分である。ORG_PGCはプログラムセットを記述したナビゲーションデータを示す。ORG_PGCはプログラムの連なり(チェーン)であり、図2または後述する図18の「.SRO」ファイル(図2ではSR_TRANS.SRO106)内に記録されたストリームデータを含む。
【0224】
ここで、プログラムセットとは、情報記憶媒体201の記録内容全体(全てのプログラム)を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルPGC(ORG_PGC)と呼ばれるデータ構造に対応している。
【0225】
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、1以上のオリジナルセルにより構成される。プログラムはオリジナルPGC内でのみ定義されるものである。
【0226】
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義PGC内のセルは「ユーザ定義セル」と呼ばれる。
【0227】
プログラムセット内の各々のプログラムは、少なくとも1個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも1個のユーザ定義セルで構成される。
【0228】
一方、ストリーマでは、ストリームセル(SC)だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
【0229】
なお、プログラムチェーン(PGC)とは、上位概念的な単位を示す。オリジナルPGCでは、PGCはプログラムセットに対応したプログラムの連なり(チェーン)を指す。また、ユーザ定義PGCでは、PGCはプレイリストに対応するプログラムの一部の連なり(チェーン)を指す。
【0230】
また、プログラムの一部のチェーンを指すユーザ定義PGCは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルPGCに属するストリームデータを参照するようになっている。
【0231】
図13のユーザ定義PGC情報テーブルUD_PGCITは、ユーザ定義PGC情報テーブル情報UD_PGCITIと、1以上のユーザ定義PGCサーチポインタUD_PGC_SRP#nと、1以上のユーザ定義PGC情報UD_PGCI#nとを含むことができる。
【0232】
ユーザ定義PGC情報テーブル情報UD_PGCITIは、図示しないが、ユーザ定義PGCサーチポインタUD_PGC_SRPの数を示すUD_PGC_SRP_Nsと、ユーザ定義PGC情報テーブルUD_PGCITの終了アドレスを示すUD_PGCIT_EAとを含む。
【0233】
UD_PGC_SRP_Nsが示すUD_PGC_SRPの数は、ユーザ定義PGC情報(UD_PGCI)の数と同じであり、ユーザ定義PGC(UD_PGC)の数とも同じである。この数は、最大「99」まで許されている。
【0234】
UD_PGCIT_EAは、該当UD_PGCITの終了アドレスを、そのUD_PGCITの先頭バイトからの相対バイト数(F_RBN)で記述したものである。
【0235】
ここで、F_RBNとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
【0236】
オリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したPGCI#iについては、図14を参照して後述する。
【0237】
図13のテキストデータマネージャTXTDT_MGは、補足的なテキスト情報である。このTXTDT_MGは、図14のプライマリテキスト情報PRM_TXTIとともに、プレイリストおよびプログラム内に格納できる。
【0238】
図13のアプリケーションプライベートデータマネージャAPDT_Mは、図示しないが、アプリケーションプライベートデータマネージャ一般情報APDT_GIと、1以上のAPDTサーチポインタAPDT_SRP#nと、1以上のAPDTエリアAPADTA#nとを含むことができる。
【0239】
ここで、アプリケーションプライベートデータAPDTとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報(リアルタイムストリームデータに加えさらに望まれる情報)を格納できるような概念上のエリアである。
【0240】
図14は、PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。
【0241】
図14のPGC情報PGCI#iは、図13のオリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したものである。
【0242】
図14に示すように、PGC情報PGCI#iは、PGC一般情報PGC_GIと、1以上のプログラム情報PGI#mと、1以上のストリームセル情報サーチポインタSCI_SRP#nと、1以上のストリームセル情報SCI#nとで構成されている。
【0243】
PGC一般情報PGC_GIは、プログラムの数PG_Nsと、ストリームセル情報サーチポインタSCI_SRPの数SCI_SRP_Nsとを含んでいる。
【0244】
各プログラム情報PGI(たとえばPGI#1)は、プログラムタイプPG_TYと、該当プログラム内のセルの数C_Nsと、該当プログラムのプライマリテキスト情報PRM_TXTIと、アイテムテキストのサーチポインタ番号IT_TXT_SRPNとを含んでいる。
【0245】
ここで、プログラムタイプPG_TYは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
【0246】
このプロテクトフラグが「0b」のときは該当プログラムは保護されておらず、「1b」のときは保護された状態にある。
【0247】
セルの数C_Nsは、該当プログラム内のセルの数を示す。PGCの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに(暗黙のうちに)付随している。
【0248】
たとえば、PGC内でプログラム#1がC_Ns=1を持ち、プログラム#2がC_Ns=2を持つとすれば、そのPGCの最初のストリームセル情報SCIはプログラム#1に付随するものとなり、第2、第3のSCIはプログラム#2に付随するものとなる。
【0249】
プライマリテキスト情報PRM_TXTIは、情報記憶媒体(DVD−RAMディスク)201を世界中で利用可能とするために、1つの共通キャラクタセット(ISO/IEC646:1983(ASCIIコード))を持ったテキスト情報を記述したものである。
【0250】
アイテムテキストのサーチポインタ番号IT_TXT_SRPNは、アイテムテキスト(該当プログラムに対応するテキストデータ)IT_TXTに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、IT_TXT_SRPNは「0000h」にセットされる。
【0251】
各ストリームセル情報サーチポインタSCI_SRP(たとえばSCI_SRP#1)は、対応ストリームセル情報SCIの開始アドレスを示すSCI_SAを含んでいる。このSCI_SAは、PGCIの先頭バイトからの相対バイト数(F_RBN)で記述される。
【0252】
各ストリームセル情報SCI(たとえばSCI#1)は、ストリームセル一般情報SC_GIと、1以上のストリームセルエントリポイント情報SC_EPI#nとで構成される。
【0253】
ストリームセル一般情報SC_GIは、仮消去(テンポラリイレーズ;TE)状態を示すフラグTEを含むセルタイプC_TYと、ストリームセルのエントリポイント情報の数SC_EPI_Nsと、ストリームオブジェクト番号SOB_Nと、ストリームセル開始APAT(図6他で示したSC_S_APAT)と、ストリームセル終了APAT(図6他で示したSC_E_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの開始APATを示す消去開始APAT(図6他で示したERA_S_APAT)と、セルが仮消去状態(TE=10b)にあるときにその仮消去セルの終了APATを示す消去終了APAT(図6他で示したERA_E_APAT)とを含んでいる。
【0254】
セルタイプC_TYは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
【0255】
すなわち、セルの形式C_TY1=「010b」は全てのストリームセルの形式に記述される(このC_TY1=「010b」によりストリームセルとそれ以外のセルの区別ができる)。
【0256】
一方、フラグTEが「00b」であれば該当セルは通常の状態にあることが示され、フラグTEが「01b」あるいは「10b」であれば該当セルは仮消去の状態にあることが示される。
【0257】
フラグTE=「01b」は、該当セル(仮消去状態にあるセル)が、SOBU内で開始する最初のアプリケーションパケットの後から開始し、同じSOBU内の最終アプリケーションパケットの前で終了する場合を示す。
【0258】
また、フラグTE=「10b」は、該当セル(仮消去状態にあるセル)が、少なくとも1つのSOBU境界(先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのSOBU内で開始する)を含む場合を示す。
【0259】
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのTEフラグとは、同時に設定できないようになっている。それゆえ、
(a)プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず;
(b)仮消去状態にあるセルを1以上含むプログラムはプロテクト状態に設定できない。
【0260】
ストリームセルのエントリポイント情報の数SC_EPI_Nsは、該当ストリームセル情報SCI内に含まれるストリームセルエントリポイント情報の数を記述したものである。
【0261】
図14の各ストリームセルエントリポイント情報SC_EPI(たとえばSC_EPI#1)は、2種類(タイプAとタイプB)存在する。
【0262】
タイプAのSC_EPIは、エントリポイントタイプEP_TYとエントリポイントのアプリケーションパケット到着時間EP_APATとを含む。タイプAは、エントリポイントタイプEP_TY1=「00b」により示される。
【0263】
タイプBのSC_EPIは、タイプAのEP_TYおよびEP_APATの他に、プライマリテキスト情報PRM_TXTIを含む。タイプBは、エントリポイントタイプEP_TY1=「01b」により示される。
【0264】
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間(APAT)により特定できる。このAPATにより、どこからデータ出力が開始されるのかを特定できる。
【0265】
ストリームオブジェクト番号SOB_Nは、該当セルが参照するSOBの番号を記述したものである。
【0266】
ストリームセル開始APAT(SC_S_APAT)は、該当セルの開始APATを記述したものである。
【0267】
ストリームセル終了APAT(SC_E_APAT)は、該当セルの終了APATを記述したものである。
【0268】
消去開始APAT(ERA_S_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、この仮消去セルに先頭が含まれる最初のSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0269】
消去終了APAT(ERA_E_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、仮消去セルのすぐ後に続くアプリケーションパケットを含むSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0270】
図15は、ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【0271】
図15に示すように、ストリームファイル情報テーブルSFITは、ストリームファイル情報テーブル情報SFITIと、1以上のストリームオブジェクトストリーム情報SOB_STI#nと、ストリームファイル情報SFIとで構成される。
【0272】
ストリームファイル情報テーブル情報SFITIは、情報記憶媒体(DVD−RAMディスク)201上のストリームファイル情報の数SFI_Nsと、SFITIに続くストリームオブジェクトストリーム情報の数SOB_STI_Nsと、SFITの終了アドレスSFIT_EAと、SFIの開始アドレスSFI_SAとで構成される。
【0273】
SFIT_EAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFITの終了アドレスを記述したものである。
【0274】
また、SFI_SAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFIの開始アドレスを記述したものである。
【0275】
各ストリームオブジェクトストリーム情報SOB_STIは、3種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、SOB_STIは、ストリームオブジェクト情報(SOBI)のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト(SOB)が同じSOB_STIを共有する(つまり同じSOB_STIをポイントする)ことが認められている。したがって、通常は、SOBの数よりもSOB_STIの数の方が少なくなる。
【0276】
図15の各ストリームオブジェクトストリーム情報SOB_STI(たとえばSOB_STI#1)は、アプリケーションパケットサイズAP_SIZと、サービスIDの数SERV_ID_Nsと、サービスID(SERV_IDs)と、アプリケーションパケットデバイスユニークID(AP_DEV_UID)とを含んでいる。
【0277】
AP_SIZは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
【0278】
なお、DVDストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト(現SOB)はそこで終了され、新たなストリームオブジェクト(新SOB)が、新たなAP_SIZを伴って開始される。その際、現SOBおよび新SOBの双方は、オリジナルPGC情報(ORG_PGCI)内の同じプログラムに属するものとなる。
【0279】
SERV_ID_Nsは、後続パラメータに含まれるサービスIDの数を記述したものである。
【0280】
SERV_IDsは、サービスIDのリストを任意の順序で記述したものである。
【0281】
AP_DEV_UIDは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスIDを記述したものである。
【0282】
ストリームファイル情報SFIは、図15に示すように、ストリームファイル一般情報SF_GIと、1以上のストリームオブジェクト情報(SOB情報)サーチポインタ(SOBI_SRP)#nと、1以上のSOB情報(SOBI)#nとで構成されている。
【0283】
ストリームファイル一般情報SF_GIは、SOBIの数SOBI_Nsと、SOBU1個あたりのセクタ数SOBU_SIZと、タイムマップ情報の一種であるMTU_SHFTとを含んでいる。
【0284】
ここで、SOBU_SIZは、SOBUのサイズをセクタ数で記述したもので、このサイズは32(32セクタ=64kバイト)で一定となっている。このことは、各タイムマップ情報(MAPL)内において、最初のエントリが、SOBの最初の32セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、2番目のエントリは、次の32セクタに含まれるアプリケーションパケットに関係する。3番目以降のエントリについても以下同様である。
【0285】
各SOB情報サーチポインタ(たとえばSOBI_SRP#1)は、SOBIの開始アドレスSOBI_SAを含んでいる。このSOBI_SAは、ストリームファイル情報SFIの先頭バイトから相対バイト数(F_RBN)でもって関連SOBIの開始アドレスを記述したものである。
【0286】
各SOB情報(たとえばSOBI#1)は、ストリームオブジェクト一般情報SOB_GIと、タイムマップ情報MAPLと、アクセスユニットデータAUD(オプション)とで構成される。
【0287】
ストリームオブジェクト一般情報SOB_GIは、ストリームオブジェクトのタイプSOB_TYと、ストリームオブジェクト記録時間SOB_REC_TMと、ストリームオブジェクトのストリーム情報番号SOB_STI_Nと、アクセスユニットデータフラグAUD_FLAGSと、ストリームオブジェクトの開始アプリケーションパケット到着時間SOB_S_APATと、ストリームオブジェクトの終了アプリケーションパケット到着時間SOB_E_APATと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットSOB_S_SOBUと、タイムマップ情報のエントリ数MAPL_ENT_Nsとを含んでいる。
【0288】
ストリームオブジェクトのタイプSOB_TYは、仮消去状態(TE状態)を示すビットおよび/またはコピー世代管理システムのビットを記述できる部分である。
【0289】
ストリームオブジェクト記録時間SOB_REC_TMは、関連ストリームオブジェクト(SOB)の記録時間を記述したものである。
【0290】
ストリームオブジェクトのストリーム情報番号SOB_STI_Nは、該当ストリームオブジェクトに対して有効なSOB_STIのインデックスを記述したものである。
【0291】
アクセスユニットデータフラグAUD_FLAGSは、該当ストリームオブジェクトに対してアクセスユニットデータ(AUD)が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
【0292】
アクセスユニットデータ(AUD)が存在する場合は、AUD_FLAGSにより、AUDの幾つかの特性が記述される。
【0293】
アクセスユニットデータ(AUD)自体は、図15に示すように、アクセスユニット一般情報AU_GIと、アクセスユニットエンドマップAUEMと、再生タイムスタンプリストPTSLとで構成される。
【0294】
アクセスユニット一般情報AU_GIは、該当SOBに対して記述されたアクセスユニットの数を示すAU_Nsと、該当SOBに属するSOBUのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップAUSMとを含んでいる。
【0295】
アクセスユニットエンドマップAUEMは、(もし存在するときは)AUSMと同じ長さのビットアレイであり、該当SOBのアクセスユニットに付随するビットストリームセグメントの終端をどのSOBUが含むのかを示す。
【0296】
再生タイムスタンプリストPTSLは、該当SOBに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる1つのPTSLエレメントは、対応アクセスユニットの再生タイムスタンプ(PTS)の値を含む。
【0297】
なお、アクセスユニット(AU)とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、MPEGのIピクチャに対応する部分となる。
【0298】
ここで再びSOB_GIの内容説明に戻る。
【0299】
AUD_FLAGSは、フラグRTAU_FLGと、フラグAUD_FLGと、フラグAUEM_FLGと、フラグPTSL_FLGとを含んでいる。
【0300】
フラグRTAU_FLGが0bのときは、該当SOBのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
【0301】
フラグRTAU_FLGが1bのときは、図9(a)または図12(a)のアプリケーションヘッダエクステンション内に記述されるAUフラグ(AU_START、AU_END)が、該当SOBのリアルタイムデータ内に存在可能なことが示される。この状態は、下記AUD_FLGが0bの場合にも許される。
【0302】
フラグAUD_FLGが0bのときは、該当SOBに対してアクセスユニットデータ(AUD)がないことが示される。
【0303】
フラグAUD_FLGが1bのときは、該当SOBに対してアクセスユニットデータ(AUD)が存在し得ることが示される。
【0304】
フラグAUEM_FLGが0bのときは、該当SOBにAUEMが存在しないことが示される。
【0305】
フラグAUEM_FLGが1bのときは、該当SOBにAUEMが存在することが示される。
【0306】
フラグPTSL_FLGが0bのときは、該当SOBにPTSLが存在しないことが示される。
【0307】
フラグPTSL_FLGが1bのときは、該当SOBにPTSLが存在することが示される。
【0308】
SOB_S_APATは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、SOB_S_APATにより、該当SOBに属する最初のアプリケーションパケット到着時間が示される。
【0309】
このパケット到着時間(PAT)は、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0310】
SOB_E_APATは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、SOB_E_APATにより、該当SOBに属する最後のアプリケーションパケット到着時間が示される。
【0311】
SOB_S_SOBUは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、SOB_S_SOBUにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むSOBUが示される。
【0312】
MAPL_ENT_Nsは、SOBI_GIの後に続くタイムマップ情報(MAPL)のエントリ数を記述したものである。
【0313】
タイムマップ情報MAPLは、図3(h)のタイムマップ情報252に対応する内容を持つ。
【0314】
図13および図15の内容の関連性の1つについて纏めると、次のようになる:
管理情報105に含まれるストリーマ情報STRIは、ストリームデータの内容の一部を構成するストリームオブジェクトSOBを管理するストリームファイル情報テーブルSFITを含む。このSFITは、SOBを管理するストリームオブジェクト情報SOBIを含む。このSOBIが、管理情報(アクセスユニット開始マップAUSM)を含むアクセスユニット一般情報AU_GIと、管理情報(PTSL)とを含む。
【0315】
ここで、管理情報(ATSまたはAUSM)がストリームデータの転送時に使用される情報を含み、管理情報(PTSまたはSC_S_APAT)が前記ストリームデータを表示するときに使用される情報を含む。
【0316】
図16は、アクセスユニット開始マップ(AUSM;図15参照)とストリームオブジェクトユニット(SOBU;図1、図4〜図6、図12参照)との対応関係を例示する図である。
【0317】
図示するように、AUSMのうちビット”1”の部分が、対応SOBUにアクセスユニット(AU)が含まれることを示している。
【0318】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)としてみる。すると、アクセスユニットAUの位置は次のようになる。
【0319】
(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内に配置されたものである。
【0320】
(2)AUは、このAU開始後に最初に現れるAU_ENDマークで終了し、かつ、AUは、(もしAUEMが存在するなら)割り当てられたAUEMエレメントにより示される最後のSOBUで終了する。
【0321】
なお、いずれのアクセスユニットデータにおいても、SOBの各SOBU1個当たりに、2以上のアクセス可能なアクセスユニットを記述することはできない。
【0322】
図17は、アクセスユニット開始マップ(AUSM;図15参照)およびアクセスユニット終了マップ(AUEM;図15参照)とストリームオブジェクトユニット(SOBU;図2、図4、図11参照)との対応関係を例示する図である。
【0323】
AUEMは、(もし存在するなら)AUSMと同じ長さのビットアレイである。AUEMのビットは、該当SOBのアクセスユニットに付随するビットストリームセグメントの末尾がどのSOBUに含まれるのかを、示している。
【0324】
AUEM内にセットされたビットの数はAUSM内にセットされたビットの数に一致する。すなわち、AUSM内の各設定ビットは、AUEM内に対応してセットされたビットを持つ。
【0325】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)とし、AUEM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUEM_pos(i)としてみる。この場合、以下の関係がある。
【0326】
(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)。
【0327】
図18は、オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【0328】
ユーザ定義PGCは自身のSOBを含まないが、オリジナルPGC内のSOBを参照する。それゆえ、ユーザ定義PGCはPGC情報を用いることのみで記述できる。このことは、SOBデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
【0329】
ユーザ定義PGCはまた、プログラムを含まず、オリジナルPGC内のプログラムの一部に対応したセルの連なり(チェーン)で構成される。
【0330】
このようなユーザ定義PGCの一例が、図18に示されている。この例は、PGC内のセルがオリジナルPGC内のSOBを参照するようにユーザ定義PGC#nが作成されている場合を示す。
【0331】
図18において、PGC#nは4つのセル#1〜#4を持っている。そのうち2つはSOB#1を参照し、残りの2つがSOB#2を参照している。
【0332】
ユーザ定義PGC内のセルからオリジナルPGCへ(SOBIのタイムマップ情報へ)の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義PGC内のセル再生順序は、オリジナルPGCにおける再生順序と全く異なってもよい。
【0333】
任意のSOBおよびそのSOBUの再生は、図18の開始APAT(S_APAT)および終了APAT(E_APAT)により特定される。
【0334】
SOBあるいはSOBUのS_APATは、該当SOBのストリームパックのペイロード(図1(h)、図22、図23参照)内に記録されたタイムスタンプに関係して定義される。
【0335】
SOBの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間(APAT)である。
【0336】
SOBの先頭アプリケーションパケットのAPATはSOB_S_APATとして記憶される。全てのAPATの4最下位バイト(4 least significant bytes)は、「〜.SRO」ファイル内の対応アプリケーションパケット用に予め固定されている。
【0337】
SOBあるいはSOBUのデータを再生するために、ストリーマ内部のリファレンスクロックはSCR値にセットされ、その後クロックが自動的にカウントされる。このSCR値は、再生が始まる最初のストリームパック内(パックヘッダ内)に記述されている。このクロックに基づいて、SOBあるいはSOBUからの全ての後続アプリケーションパケットの再生・出力が、実行される。
【0338】
任意のストリームセル(SC)が、そのSCがポイントするSOBのSOB_S_APATとSOB_E_APATとの間の任意の値を持つストリームセル開始APAT(SC_S_APAT)を規定しているときは、所望のAPATを伴うアプリケーションパケットを含んだSOBUを見つけるためのアドレスが必要となる。
【0339】
SOBU1個あたりのストリームパックの数は一定であるが、各SOBUにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各SOBは、該当SOBのSOBUの到着時間間隔が記述されたタイムマップ情報(MAPL)を持つ。つまり、タイムマップ情報(MAPL)により実現されるアドレス方式は、任意のAPATをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるSOBUをポイントする。
【0340】
図19は、この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。この実施の形態では、情報記憶媒体201として、DVD−RAMディスクのような記録/再生可能光ディスクを想定している。
【0341】
以下、図19を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。
【0342】
このストリームデータ記録再生装置は、光ディスク装置415、STB装置416およびその周辺機器から構成される。
【0343】
周辺機器としては、ビデオミキシング部405、フレームメモリ部406、外部スピーカ433、パーソナルコンピュータ(PC)435、モニタTV437、D/Aコンバータ432、436、I/F部431、434等がある。
【0344】
光ディスク装置415は、ディスクドライブを含む記録再生部409と、記録再生部409へのストリームデータ(あるいは記録再生部409からのストリームデータ)を処理するデータプロセサ部(以下D−PRO部と略記する)410と、D−PRO部410からオーバーフローしてきたストリームデータを一時記憶する一時記憶部411と、記録再生部409およびD−PRO部410の動作を制御する光ディスク装置制御部412とを備えている。
【0345】
光ディスク装置415はさらに、STB装置416からIEEE1394等を介して送られてきたストリームデータを受ける(あるいはIEEE1394等を介してSTB装置416へストリームデータを送る)データ転送インターフェース部414と、データ転送インターフェース部414で受けたストリームデータを情報記憶媒体(RAMディスク)201に記録する信号形式に変換する(あるいは媒体201から再生されたストリームデータをIEEE1394等の信号形式に変換する)フォーマッタ/デフォーマッタ部413とを備えている。
【0346】
具体的には、データ転送インターフェース部414のIEEE1394受信側は、基準クロック発生器(システムタイムカウンタSTC)440のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。
【0347】
上記時間情報に基づいて、ストリームデータをストリームブロック毎(あるいはSOBU毎)に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはPGCの切り分け情報を作成する。
【0348】
フォーマッタ/デフォーマッタ部413は、STB装置416から送られてきたストリームデータをストリームパックの列(図12(a)、図23(h)等を参照)に変換し、変換されたストリームパック列をD−PRO部410へ入力する。入力されたストリームパックはセクタと同じ2048バイトの一定サイズを持っている。D−PRO部410は、入力されたストリームパックを16セクタ毎にまとめてECCブロックにして、記録再生部409へ送る。
【0349】
ここで、記録再生部409において媒体201への記録準備ができていない場合には、D−PRO部410は、記録データを一時記憶部411に転送して一時保存し、記録再生部409においてデータ記録準備ができるまで待つ。
【0350】
記録再生部409において記録準備ができた段階で、D−PRO部410は一時記憶部411に保存されたデータを記録再生部409に転送する。これにより、媒体201への記録が開始される。一時記憶部411に保存されたデータの記録が済むと、その続きのデータはフォーマッタ/デフォーマッタ部413からD−PRO部410へシームレスに転送されるようになっている。
【0351】
ここで、一時記憶部411は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
【0352】
なお、フォーマッタ/デフォーマッタ部413を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器(STC)440から得ることができる。
【0353】
また、フォーマッタ/デフォーマッタ部413を介して再生ビットストリームから取り出されたタイムスタンプ情報(SCR)は、STC440にセットすることができる。
【0354】
情報記憶媒体201に記録されたストリームデータ内のパックヘッダには、基準クロック(システムクロックリファレンスSCR)が記録されている。この媒体201に記録されたストリームデータ(SOBまたはSOBU)を再生する場合において、基準クロック発生器(STC)440は、媒体201から再生された基準クロック(SCR)に適合される(SCRの値がSTC440にセットされる)。
【0355】
つまり、SOBあるいはSOBUのデータを再生するために、ストリーマ(光ディスク装置415)内の基準クロック(STC440)を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスSCRに合わせる。その後は、STC440のカウントアップは自動的に行われる。
【0356】
STB部416は、衛星アンテナ421で受信したデジタル放送電波の内容を復調し、1以上の番組が多重化された復調データ(ストリームデータ)を提供するデモジュレータ422と、デモジュレータ422で復調されたデータから(ユーザが希望する)特定番組の情報(後述する図23を例に採れば、番組2のトランスポートパケット)を選択する受信情報セレクタ部423とを備えている。
【0357】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を情報記憶媒体201に記録する場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部20を介して、IEEE1394転送により、光ディスク装置415のデータ転送インターフェイス部414に送る。
【0358】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を記録することなく単に視聴するだけの場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部402の多重化情報分離部425に送る。
【0359】
一方、情報記憶媒体201に記録された番組を再生する場合は、IEEE1394のシリアルバスを介して光ディスク装置415からSTB装置416に送られてきたストリームデータは、セレクタ部423を介してデコーダ部402の多重化情報分離部425に送られる。
【0360】
多重化情報分離部425は、セレクタ部423から送られてきたストリームデータに含まれる各種パケット(ビデオパケット、オーディオパケット、サブピクチャパケット)を、内部メモリ部426上で、各パケットのIDにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部(ビデオデコード部428、サブピクチャデコード部429、オーディオデコード部430に分配する。
【0361】
ビデオデコード部428は、多重化情報分離部425から送られてきた(MPEGエンコードされた)ビデオパケットをデコードして、動画データを生成する。その際、MPEGビデオデータ中のIピクチャから記録内容を代表する縮小画像(サムネールピクチャ)を生成する機能を持たせるために、ビデオデコード部428は、代表画像(サムネール)生成部439を内蔵している。
【0362】
ビデオデコード部428でデコードされた動画(および/または生成部439で生成された代表画像)と、サブピクチャデコード部429でデコードされたサブピクチャ(字幕、メニュー等の情報)と、オーディオデコード部430でデコードされた音声とは、ビデオプロセサ部438を介してビデオミキシング部405へ送出される。
【0363】
ビデオミキシング部405は、フレームメモリ部406を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、D/A変換器436を介してアナログ映像化され、モニタTV437に送られる。
【0364】
また、ビデオミキシング部405からのデジタル映像は、I/F部434およびIEEE194等の信号ラインを介して、パーソナルコンピュータ435に適宜取り込まれる。
【0365】
一方、オーディオデコード部430でデコードされたデジタルオーディオ情報は、D/A変換器432および図示しないオーディオアンプを介して、外部スピーカ433に送られる。また、デコードされたオーディオ情報は、I/F部431を介して外部にデジタル出力される。
【0366】
なお、STB装置416内の動作タイミングは、システムタイムカウンタ(STC)部424からのクロックにより決定される。
【0367】
上述したSTB制御部404による指示等(STB装置416の内部構成各々の動作制御)は、プログラムメモリ部404aに格納された制御プログラムにより実行される。その際、STB制御部404による制御過程においてワークメモリ部407が適宜利用される。
【0368】
このSTB制御部404およびデコーダ部402を含めSTB装置416の内部動作のタイミングは、STC部424からのクロックで規制できる。また、光ディスク装置415のSTC440とSTB装置416のSTC部424を同期させることで、光ディスク装置415およびSTB装置416を含めたストリーマシステム全体の動作タイミングを規制できる。
【0369】
STC440とSTC部424を同期させる方法としては、データ転送インターフェース部414とデータ転送インターフェース部420との間で受け渡されるストリームデータ中の基準クロック(SCR)により、STC440およびSTC部424をセットする方法がある。
【0370】
図19の装置構成を機能別にみると、STB装置416内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割/分類できる。
【0371】
ここで、「受信時刻管理部」は、デモジュレータ(復調部)422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等で構成される。この「受信時刻管理部」は、衛星アンテナ421でデジタルTV放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。
【0372】
「ストリームデータ内容解析部」は、多重化情報分離部425、STB制御部404等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、I,B,Pの各ピクチャ位置および/またはPTS値を抽出する。
【0373】
「ストリームデータ転送部」は、多重化情報分離部425、受信情報セレクタ部423、STB制御部404、データ転送インターフェース部420等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置415へ転送する。
【0374】
「時間関連情報生成部」は、多重化情報分離部425、STB制御部404、データ転送インターフェース部420等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻(タイムスタンプ)情報と「ストリームデータ内容解析部」で抽出した表示時刻情報(PTS値および/またはフィールド数)との間の関係情報を作成する。
【0375】
図20は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。図20を用いてこの発明の基本的特徴について説明する。
【0376】
TVの表示方式の1つであるNTSC方式では、1秒間に30枚の画面/ピクチャ(フレーム)を映像信号としてTVのモニタスクリーンに表示している。通常のTVでは、インターレース方式を用いているので、1画面の全走査線に対して始めに1本おきに画面を走査して表示し、その後で1本ずらした画像を1本おきに走査することで直前の画面の間を埋めて1枚の画面(ピクチャ)の表示を行う。この1本おきに表示する画像をフィールドと呼ぶ。
【0377】
NTSC方式では、毎秒30フレーム/60フィールドを表示している。このNTSC方式は主に日本とアメリカで採用されている表示方式である。それに対して、主に欧州で採用されているPAL方式では、毎秒25フレーム/50フィールドの表示を行っている。
【0378】
図20(a)は、毎秒30枚変化する画面/ピクチャ(フレーム)を表示時刻(プレゼンテーションタイム;または再生時間)1に沿って並べた図である。
【0379】
画面/ピクチャの表示時刻(再生時間)1を表す情報としては、
(a)”ある特定の画面(ピクチャ)からの差分フィールド枚数”で表す方法と;
(b)”PTS(プレゼンテーションタイムスタンプ;または再生タイムスタンプ)”で表す方法がある。
【0380】
PTSは、27MHzおよび/または90kHzの基準クロックを利用し、常にインクリメント(カウンタの値が1ずつ増加)するカウンタの値で表示時刻を表す方法で用いることができる。たとえば、27MHz(または90kHz)の基準クロックでインクリメントするカウンタで各画面/ピクチャ(フレーム)を示すときのカウンタの値が、PTSの値として用いられる。
【0381】
デジタルTVでの受信信号情報内には、各ピクチャ毎のPTS値がピクチャヘッダ情報41(図1(j)参照)内に含まれている。
【0382】
図20(a)では、Iピクチャaの表示時刻がPTSNo.1で表わされ、Iピクチャiおよびqの表示時刻がPTSNo.2およびPTSNo.3で表わされている。
【0383】
いま、例えばユーザから、Iピクチャa表示の何時間何分何秒後の画面(ピクチャ)を表示するように指示を受けたとする。すると、上記指定時間間隔(何時間何分何秒後)が27MHzおよび/または90kHzのカウント値に換算される。そして、この換算値とIピクチャa表示のPTS値(PTSNo.1)との加算結果を計算して、ユーザから指示された「表示すべき画面(ピクチャ)」を検索することができる。
【0384】
情報記憶媒体201上に記録されたストリームデータは、図1(g)その他に示したように各トランスポートパケット毎にタイムスタンプを付加して記録されているので、このタイムスタンプ情報を利用してストリームデータに対する時間管理を行っている。
【0385】
しかし、このタイムスタンプ情報はユーザには認知できないため、ユーザは表示時刻(再生時間)1を用いて、見たい画面(ピクチャ)を指定することになる。
【0386】
この場合、ストリームデータを時間管理するためのタイムスタンプ情報とユーザが指定可能な表示時刻(再生時間)1情報との間の関係を示す情報が必要になる。この関係を示す情報が、図20(b)に示す時間関係テーブル2(あるいは図15の再生タイムスタンプリストPTSL)である。
【0387】
図20(b)に例示するように、時間関係テーブル2には、各PTS値(PTSNo.1、PTSNo.2、PTSNo.3、…)毎に、対応するデータ転送時刻情報(Iピクチャ転送開始時刻4)、データ転送時刻情報(Iピクチャ転送終了時刻5)、セル先頭から目的のIピクチャまでの通算パケット数10が記述されている。
【0388】
たとえばPTSNo.1のIピクチャaについてみると、データ転送時刻情報(Iピクチャ転送開始時刻4)の行のタイムスタンプ(ATS)#1は図2(c)のIピクチャa情報7の先頭側パケット(AP)#1のタイムスタンプ(ATS)#1に対応し、データ転送時刻情報(Iピクチャ転送終了時刻5)の行のタイムスタンプ(ATS)#2は図2(c)のIピクチャa情報7の末尾側パケット(AP)#2のタイムスタンプ(ATS)#2に対応している。ここではIピクチャaが最初のピクチャなので、PTSNo.1のIピクチャaに対する通算パケット数10は、図20(b)に示すように「1」となる。
【0389】
同様にPTSNo.2のIピクチャiについてみると、データ転送時刻情報(Iピクチャ転送開始時刻4)の行のタイムスタンプ(ATS)#3は図2(c)のIピクチャi情報8の先頭側パケット(AP)#3のタイムスタンプ(ATS)#3に対応し、データ転送時刻情報(Iピクチャ転送終了時刻5)の行のタイムスタンプ(ATS)#4は図2(c)のIピクチャi情報8の末尾側パケット(AP)#4のタイムスタンプ(ATS)#4に対応している。ここではIピクチャiが最初のIピクチャaから85100枚後としているので、PTSNo.2のIピクチャiに対する通算パケット数10は、図20(b)に示すように「85101」となる。PTSNo.3以後についても同様である。
【0390】
図20(b)に示すような時間関係テーブル2を、ストリームデータ(図1(a)、図20(c)その他のSTREAM.VRO106)に関する管理情報(図15のSFIT)が記録されている領域に記録し、この時間関係テーブルを利用して、ユーザにとってピクチャ単位の画面位置指定ができるようにした所に、この発明の大きな特徴がある。
【0391】
ここで、上記時間関係テーブル2と図15に示した再生タイムスタンプリストPTSLとの対応関係について、説明しておく。
【0392】
図1(g)その他に示されたタイムスタンプをATSとしたとき、図15の再生タイムスタンプリストPTSLに含まれるPTSの値とATSとは、以下のような関係を持つ:
(1)セル(ストリームセル)は記録されたビットストリームの一部を参照するものである;
(2)AU(通常Iピクチャ)は記録されたビットストリームの連続した一部である(AUはセルの一部に対応する);
(3)AU(セルの一部に対応するIピクチャ)がどのSOBUに含まれるかは、図15のアクセスユニット開始マップAUSMにより示される(図16参照);
(4)PTSの値は対応AUの再生時間(表示時刻;あるいはプレゼンテーションタイムPTM)である(AUに対応するPTSの値は、再生時間に関して、セルの一部に対応する);
(5)セル開始APAT(SC_S_APAT)は該当セルのトランスポートパケットまたはアプリケーションパケットAPの到着時間である(SC_S_APATは、再生時間に関して、PTSの値に対応する);
(6)トランスポートパケットまたはアプリケーションパケットAPは、その先頭にタイムスタンプATSを伴う(図22、図29(g)等参照);
(7)PTSの値は、PTSLに含まれる(図15参照);
(8)上記(3)〜(7)から、PTSLに含まれるPTSの値は、AUSM、SC_S_APAT等を仲介して、ATSに対応することになる。
【0393】
よって、再生タイムスタンプリストPTSLは、AU(Iピクチャ)の開始時刻(SC_S_APAT)と、ビットストリームに含まれるパケットのタイムスタンプATSとの関係(再生時間に関する関係)を示す情報(PTSの値)を含む「時間関係テーブル(図20(b))」であると言える。
【0394】
あるいは、PTSL(時間関係テーブル)は、PTSの値とATSとの対応関係を示す情報であるとも言える。
【0395】
ところで、BピクチャあるいはPピクチャを表示するためには、必ずIピクチャの表示(デコード)から開始する必要がある。このため、図20(b)に示す時間関係テーブル2は、Iピクチャ位置でのタイムスタンプと対応する表示時刻情報を一覧表として示してある。
【0396】
ここでは、表示時刻情報として、”PTS情報(PTSの値)”、”特定基準画面(ピクチャ)からの差分フィールド数”、”年月日時刻情報”等を用いることができる。
【0397】
なお、表示時刻情報として図20(b)に示すような絶対値表示を行う代わりに、各Iピクチャ間の差分情報(例えば各Iピクチャ間に挿入されるフィールド数情報)を使用することも可能である。(フィールド数を利用した時間関係テーブルについては、図28を参照して後述する。)
また、図20(b)では表示時刻情報として”PTS情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面(ピクチャ)からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。
【0398】
図20(b)に示す時間関係テーブル2では、各Iピクチャ毎の転送開始時刻4の値がタイムスタンプ(ATS)#1、#3、#5として一覧表に記録されているだけでなく、Iピクチャの転送終了時刻5の値もタイムスタンプ(ATS)#2、#4、#6として記録されている。
【0399】
このため、早送り再生(ファーストフォワードFF)あるいは早戻し再生(ファーストリバースFRなどの特殊再生を行う場合には、”タイムスタンプ(ATS)#1から#2まで”、”タイムスタンプ(ATS)#3から#4まで”、”タイムスタンプ(ATS)#5から#6まで”というように、再生するIピクチャのトランスポートパケット位置(またはアプリケーションパケット位置)を指定することで、情報記憶媒体201から、Iピクチャ情報(またはアクセスユニットAU情報)のみを再生し、デコードし、表示することが可能となる。
【0400】
図20(a)の実施の形態では、オリジナルセル(図4参照)の表示開始ピクチャ位置(Bピクチャfの位置)を基準に採っている。このオリジナルセルの表示開始ピクチャのPTS値(PTSNo.5)とその直前にあるIピクチャaのPTS値(PTSNo.1)との差分が、PTSオフセット9である。このPTSオフセット値9は、図3(h)に示したように、オリジナルセル情報272内に記録される。
【0401】
具体的には、図20(a)に示すように、オリジナルセルの表示開始ピクチャをBピクチャfとし、その時のPTS値をPTSNo.5とする。その直前のIピクチャaの表示時刻をPTSNo.1とすると、PTSオフセット9の値は、”PTSNo.5 − PTSNo.1”で求まる。
【0402】
ユーザが特定画面(特定のピクチャフレーム)を指定する場合、オリジナルセルの表示開始位置からの差分表示時間で指定する場合が多い。この差分表示時間を27MHzおよび/または90kHzのカウンタ数に換算後、PTSオフセット9の値を加算することで、ユーザが指定した画面(ピクチャフレーム)のPTS値を算出できる。
【0403】
図20(b)に示すように、時間関係テーブル2には、各Iピクチャ毎のPTS値一覧が記録されている。このテーブルを参照し、算出したPTS値よりも小さく、しかも算出したPTS値に最も近いIピクチャ位置のPTS値を探し、そこに対応したIピクチャ転送開始時刻4のタイムスタンプ(ATS)値を指定して、情報記憶媒体201へのアクセスを開始する。
【0404】
図20(b)に示すように、時間関係テーブル2には、タイムスタンプと並行して、オリジナルセル先頭位置から該当するIピクチャまでの通算トランスポートパケット数10(アクセス位置情報)も記録されている。
【0405】
したがって、図20の実施の形態によれば、タイムスタンプ(ATS)の代わりにオリジナルセル先頭位置からのトランスポートパケット数(またはアプリケーションパケット数AP_Ns)を指定して、所望のストリームデータ位置へアクセスすることも可能である。
【0406】
図20(c)のストリームデータ(STREAM.VRO)106が図3等に示す情報記憶媒体201に記録される場合、ストリームデータ106の内容(SOBまたはSOBU)は、所定のデータ記録単位(トランスポートパケットまたはアプリケーションパケット)で、媒体201のデータ領域(STREAM.VRO/SR_TRANS.SRO)に記録される。その際、ストリームデータ106に関する管理情報(STRI)も、媒体201の管理領域(STREAM.IFO/SR_MANGR.IFO)に記録される。
【0407】
この管理情報(STRI)に、ストリームデータ106のアクセス(Iピクチャ情報またはアクセスユニットAUへのアクセス)に利用される第1の管理情報(Iピクチャ転送開始時刻に対応したATS;またはAUSM)と;第1の管理情報(AUSM)とは異なるものであって、この第1の管理情報と前記ストリームデータのアクセスに利用される第2の管理情報(PTS;またはSC_S_APAT)との間の関係を示す第3の管理情報(時間関係テーブル;またはPTSL)が記録される。
【0408】
ここで、ストリームデータ106はMPEG規格に基づき圧縮されたビットストリームであり、前記第2の管理情報はストリームデータの再生時間(PTS)に対応する。
【0409】
図21は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図である。
【0410】
情報記憶媒体201上に記録されたストリームデータ(図1、図2その他のSTREAM.VRO106)内のデータ構造に関し、図21を用いて、各ピクチャ情報6010〜6030の記録位置とストリームブロック(SOBU)との間の配置関係を説明する。
【0411】
この実施の形態では、ストリームデータはストリームブロック(SOBU)単位で記録され、所定画像(ピクチャ)へのアクセス指定にはタイムスタンプ情報が利用される。
【0412】
図19のSTB装置416から再生開始位置としてタイムスタンプ値が指定された場合において、指定されたタイムスタンプ値に対応するストリームブロック(SOBU)を算出するための情報が、図3(h)のタイムマップ情報252(あるいは図15のタイムマップ情報MAPL、もしくは図18のタイムマップ情報)である。
【0413】
図3(h)の例では、タイムマップ情報252は、ストリームデータに対する管理情報記録領域であるSTREAM.IFO105内のストリームオブジェクト情報(SOBI)242の一部として記録されている。図15の例でも、タイムマップ情報MAPLはSOBIの一部として記録されている。
【0414】
図3(i)に示すタイムマップ情報252内では、各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。この場合は、各ストリームオブジェクト情報(SOBI)242、243毎に、タイムマップ情報252内の各ストリームブロックの時間差263、265の値を逐次加算する。そして、この逐次加算値が、STB装置416側により指定されたタイムスタンプ時刻に到達したか否か比較する必要がある。その比較結果を元に、STB装置416側により指定された時刻がどのストリームオブジェクト(SOB)内の何番目のストリームブロック(SOBU)の中に含まれるタイムスタンプ値と一致するかが割り出される。
【0415】
図21(c)に示すように各ピクチャ情報6010〜6030の境界位置とストリームブロック(SOBU)の境界位置とは必ずしも一致しない。
【0416】
この場合、例えば図21(a)で示すように、PTSの値がPTSNo.6であるPピクチャoの位置から再生を開始しようとするなら、次のような処理が必要になる。
【0417】
すなわち、図21(b)の時間関係テーブル2(内部構成は図20(b)と同様)からその直前にあるIピクチャiのPTSNo.2の値を割り出し、Iピクチャi情報6010が記録されている先頭のトランスポートパケット#2が含まれるストリームブロック(SOBU)#A先頭位置から、再生を開始する必要がある。
【0418】
ただし、ストリームブロック(SOBU)#A先頭位置から所望のPピクチャoの位置まで再生が進むまで、その間の画像情報(図21(a)ではピクチャiからピクチャnまで)は外部モニタ(TV)に出力されない。
【0419】
図22は、MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
【0420】
図22に示すように、デジタルTVでの放送信号情報にはMPEG2と呼ばれる信号圧縮方法が採用されている。MPEGによる信号圧縮方法では、TV表示用の各画面(ピクチャ)は時間差分情報を含まないIピクチャ551と時間差分情報を含むBピクチャ553、554とPピクチャ552に分類される。
【0421】
Iピクチャは前後の画面(ピクチャ)情報の影響を受けることなく単体で存在し、1枚の画面(ピクチャ)に対してDCT変換後、量子化した情報がIピクチャ圧縮情報561となり、Iピクチャ情報31として記録される。Pピクチャ552はIピクチャ551に対する差分情報562のみがPピクチャ情報32として記録され、Bピクチャ553、554はIピクチャ551とPピクチャ552に対する差分情報がBピクチャ情報33、34として記録される。
【0422】
従って、映像再生時にはPピクチャ552やBピクチャ553、554単体では画面を生成することができず、必ずIピクチャ551画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報31〜34は1個または複数のトランスポートパケット内のペイロードに分割記録されている。この時、各ピクチャ情報31〜34の境界位置とトランスポートパケット間の境界位置は常に一致するように記録されている。
【0423】
図22のトランスポートパケットがストリーマ(図19の光ディスク装置415)に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ(ATS)というタイムスタンプ付きのパケット(アプリケーションパケット)に移し替えられる。
【0424】
そして、ATS付きアプリケーションパケットの一群(通常10パケット前後)がストリームPESパケット内のアプリケーションパケットエリアに格納される。
【0425】
このストリームPESパケットにパックヘッダを付したものが1つのストリームパックになる。
【0426】
ストリームPESパケットは、PESヘッダと、サブストリームIDと、アプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、上記ATS付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。
【0427】
図23は、デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
【0428】
デジタル放送では、MPEG2規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図23(b)に示すように、トランスポートパケットヘッダ511と、記録情報のデータ本体が記録されているペイロード512とで構成されている。
【0429】
トランスポートパケットヘッダ511は、図23(a)に示すように、ペイロードユニット開始インジケータ501、パケットID(PID)502、ランダムアクセスインジケータ503、プログラムクロックリファレンス504等で構成されている。
【0430】
MPEG圧縮された映像情報は、Iピクチャ情報、Bピクチャ情報、およびPピクチャ情報を含んでいる。Iピクチャ情報が記録されている最初のトランスポートパケットには、図23(a)のランダムアクセスインジケータ503に”1”のフラグが立つ。また、各B、Pピクチャ情報の最初のトランスポートパケットには、図23(a)のペイロードユニット開始インジケータ501に”1”のフラグが立つ。
【0431】
これらのランダムアクセスインジケータ503およびペイロードユニット開始インジケータ501の情報を利用して、Iピクチャマッピングテーブル(図9(e)の641)およびB、Pピクチャ開始位置マッピングテーブル(図9(e)の642)の情報が作成される。
【0432】
たとえば、図23(a)に示したペイロードユニット開始インジケータ501に”1”のフラグが立ったトランスポートパケットに対して、B、Pピクチャ開始位置マッピングテーブル(図9(e)の642)内の該当個所のビットが”1”になる。
【0433】
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図23(a)のパケットID(PID)502で識別される。このPID502の情報を用いて、ビデオパケットマッピングテーブル(図9(e)の643)とオーディオパケットマッピングテーブル(図9(e)の644)が作成される。
【0434】
図23(c)に示すように、デジタル放送では、1個のトランスポンダに複数の番組(この例では番組1〜番組3)がパケット化された形で時分割されて転送されてくる。
【0435】
たとえば、図23(b)のトランスポートパケットヘッダ511およびペイロード(記録情報)512の情報は、図23(c)に示される番組2のトランスポートパケットb・522、e・525により転送される。
【0436】
ユーザが例えば図23(c)の第2の番組を情報記憶媒体201に記録しようとする場合には、図19に示すSTB装置416内の受信情報セレクタ部423において、番組2のトランスポートパケットb、eのみが抽出される。
【0437】
そのとき、STB装置416では、図23(d)に示すように、各トランスポートパケット b522、e525を受信した時刻情報をタイムスタンプ531、532の形で付加する。
【0438】
その後、IEEE1394の転送方式を用いて図19のフォーマッタ/デフォーマッタ部413にデータを転送する場合には、図23(e)に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。
【0439】
図19のフォーマッタ/デフォーマッタ部413では、STB装置416からIEEE1394で転送されてきたストリームデータが、図23(d)の形(図1(g)の形に相当)に一旦戻される。そして、図23(d)の形式のビットストリーム(図23(h)のストリームパック列)が、情報記憶媒体201に記録される。
【0440】
具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとPESヘッダが配置される(図23(h)等参照)。
【0441】
データエリア21、22、23(図1(f))には複数のタイムスタンプおよびトランスポートパケット(図1(g))が逐次詰め込まれるが、1個のトランスポートパケット(図1(g)ではパケットd;図23(d)では番組2のパケットb)が複数のセクタ(図1(e)ではNo.0とNo.1;図23(f)(g)では部分パケット)に跨って記録される。ここに、この発明の特徴の1つがある。
【0442】
この特徴を生かしたデータ構造を用いることにより、セクタサイズ(例えば2048バイト)よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
【0443】
デジタル放送では図23(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb・522のサイズが188バイト(または183バイト)の場合が多い。
【0444】
前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア21、22、23(図1(f))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。
【0445】
それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。
【0446】
デジタル放送などのように1個のデータエリア21、22、23(図1(f))内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリア21、22、23に連続して跨るように記録する。
【0447】
そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
【0448】
また、通常のパケットにはタイムスタンプが付いているが、図23(g)に示すように、部分パケットではタイムスタンプを省略することができる。
【0449】
このようにすると、2つの隣接ストリームパック(図23(h))の境界で分断された部分パケット(パケット1つあたり188バイトとすれば部分パケットのサイズは1〜187バイト;平均して100バイト弱)を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分(タイムスタンプ1つあたり例えば4バイト)、媒体201に対する記憶容量を増やすことができる。
【0450】
なお、図23(g)の先頭部分パケットの直後にくるタイムスタンプの位置は、図10(b)のファーストアクセスポイント625あるいは図10(c)のFIRST_AP_OFFSETにより、特定することができる。
【0451】
図19の光ディスク装置415(ストリーマ)では、タイムスタンプとトランスポートパケットとの組(図23(f)(g))をそのままの形で情報記憶媒体201上に記録する。
【0452】
図24は、この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図である。図24を用いて、ストリームデータ録画時の処理について説明する。この処理は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0453】
図23(c)に示すように、1個のトランスポンダ内には複数番組情報が時分割多重化されている。
【0454】
図19の受信情報セレクタ部423内で、この時分割多重化された複数番組情報のパケット列から、特定番組のみのトランスポートパケットが抽出される(ステップS01)。
【0455】
「受信時刻管理部(図19の復調部422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等)」では、必要な番組情報が、多重化情報分離部425のメモリ部426内に、一時保管される(ステップS02)。
【0456】
それと同時に、各トランスポートパケット毎の受信時刻が計測され、その計測値が、図23(d)に示すように、タイムスタンプ(ATS)として各トランスポートパケット(またはアプリケーションパケット)毎に付加される。こうして付加されたタイムスタンプ情報は、メモリ部426内に記録される(ステップS03)。
【0457】
次に、「ストリームデータ内容解析部(図19の多重化情報分離部425、STB制御部404等)」において、メモリ部426内に記録されたトランスポートパケット(アプリケーションパケット)内の情報が解析される。
【0458】
具体的には、トランスポートパケット(アプリケーションパケット)列から各ピクチャ境界位置の切り出しが行われるとともに、各パケット毎のピクチャヘッダ情報41からPTS情報(まあは対応フィールド枚数情報)の抽出が行なわれる(ステップS04)。
【0459】
ここで、各ピクチャ境界位置の切り出し方法には2通りの方法が存在し、いずれの方法を選択するかはストリームデータの内容による。
【0460】
第1のピクチャ境界位置切出方法は、トランスポートパケットヘッダ511(図23(b))内のランダムアクセスインジケータ503(図23(a))のフラグを検出してIピクチャ位置を検出し、ペイロードユニット開始インジケータ501(図23(a))のフラグ検出からBまたはPピクチャ位置を検出する方法である。
【0461】
第2のピクチャ境界位置切出方法は、ピクチャヘッダ情報41(図1(j))内にあるピクチャ識別情報52(図1(k))およびPTS情報53(図1(k))を抽出する方法である。
【0462】
上記の処理(ステップS01〜S04)を経た後、「時間関連情報生成部(図19の多重化情報分離部425、STB制御部404、データ転送インターフェース部420等)」では、タイムスタンプ(ATS)とPTS値との間の関係を示す一覧表として、図20(b)に示すような時間関係テーブル2(あるいは図15の再生タイムスタンプリストPTSL)を作成し、STB制御部404内のワークメモリ部407に記録する(ステップS05)。
【0463】
その後、STB装置416および光ディスク装置415における受信時刻間隔を保持しながら(つまり図19のSTC440のカウント値変化とSTC424のカウント値変化との間の関係を一定に保ちながら)、多重化情報分離部425のメモリ部426に一時保管されたパケットデータ(ストリームデータ)が、光ディスク装置415に転送される(ステップS06)。
【0464】
こうして、光ディスク装置415により、メモリ部426に一時保管されたストリームデータが、情報記憶媒体201上に記録される(ステップS07)。
【0465】
光ディスク装置415へのストリームデータ転送が完了するまでは(ステップS08ノー)、ステップS06〜S07の処理が反復される。
【0466】
光ディスク装置415へのストリームデータ転送が済みその録画処理が完了すると(ステップS08イエス)、STB制御部404のワークメモリ部407内に一時記録されていた時間関係テーブル2(あるいは再生タイムスタンプリストPTSL)の情報が、光ディスク装置415へ転送される(ステップS10)。
【0467】
そして、時間関係テーブル2(あるいは再生タイムスタンプリストPTSL)の情報が、情報記憶媒体201の管理情報記録領域(STREAM.IFO)105に記録される(ステップS11)。
【0468】
なお、上記ステップS11の処理時に、録画されたストリームデータの内容であるストリームオブジェクトの記録時間(図7(i)のSOB_REC_TM)を、管理情報記録領域(STREAM.IFO)105内のタイムゾーン(TM_ZONE)6240(図7(h)に記録することができる。
【0469】
ところで、ストリームデータ録画時にコンテンツプロバイダの著作権保護を目的として暗号化されたストリームデータを記録する場合がある。このように暗号化がなされるときは、全てのトランスポートパケットが暗号化されるとともに、STB装置416と光ディスク装置415との間のタイムスタンプ転送処理が禁止される。この場合には、情報記憶媒体201への(暗号化された)ストリームデータ記録時に、光ディスク装置415側で独自にタイムスタンプを付加する必要が生じる。
【0470】
図19のSTB装置416側では、トランスポートパケット(アプリケーションパケット)毎の受信時刻管理を行っている。この場合、STB装置416側と光ディスク装置415側との間で、基準クロック周波数のずれに対する対策(具体的には基準クロックの同期化)が重要課題となる。そこで、以下、暗号化されたストリームデータに対する録画処理について説明する。
【0471】
図25は、この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0472】
まず、図19のSTB制御部404のワークメモリ407内に時間関係テーブル2(図20(b))あるいは再生タイムスタンプリストPTSL(図15)があるかどうか、チェックされる(ステップS50)。
【0473】
時間関係テーブル(あるいはPTSL)がない場合は(ステップS50ノー)、図24のステップS04〜S05と同様な処理で、時間関係テーブル(あるいはPTSL)が作成される(ステップS52)。
【0474】
こうして時間関係テーブル(あるいはPTSL)が作成されたあと、あるいは既に時間関係テーブル(あるいはPTSL)がSTB制御部404のワークメモリ407内にあるときは(ステップS50イエス)、STB装置416から光ディスク装置415へ(暗号化された)ストリームデータが転送され、このストリームデータが情報記憶媒体201に記録される(ステップS51)。
【0475】
この(暗号化された)ストリームデータの記録が完了するまで(ステップS53ノー)、ステップS51の処理が継続される。このストリームデータ記録ステップS51は、図24のステップS01〜S03、S06と同様な処理内容である。
【0476】
なお、ステップS52の処理は、ステップS51の処理中にこれと並行して実行されてもよい。
【0477】
こうして(暗号化された)ストリームデータの記録が完了すると(ステップS53イエス)、STB装置416と光ディスク装置415との間で基準クロックの同期化処理が実行される(ステップS54)。
【0478】
この基準クロックの同期化処理は、たとえば以下のようにして行なうことができる。
【0479】
すなわち、ストリームデータ転送時に、トランスポートパケット(アプリケーションパケット)を特定個数(例えば1万個あるいは10万個)送信/受信する毎にその送信/受信時刻をSTB装置416と光ディスク装置415でそれぞれワークメモリ部407と一時記憶部411に記録しておく。
【0480】
その後、STB装置416側から光ディスク装置415側へトランスポートパケット(アプリケーションパケット)を特定個数送信する毎に送信時刻一覧表を送付する。そして、光ディスク装置415側において、送付された一覧表と光ディスク装置415側で事前に作成した一覧表とを比較することで、両者間の基準クロック同期ずれ量を算出する。
【0481】
その後、STB装置416から光ディスク装置415へ、時間関係テーブル2(あるいはPTSL)が転送される(ステップS55)。
【0482】
こうしてSTB装置416から光ディスク装置415へ転送された時間関係テーブル2(あるいはPTSL)は、ステップS54の基準クロックの同期化処理で算出した基準クロック同期ずれ量の情報を基に、修正される(ステップS56)。
【0483】
こうして基準クロック同期ずれ量分修正された時間関係テーブル2(あるいはPTSL)が、情報記憶媒体201の管理情報領域(図3(e)のSTREAM.IFO105;あるいは図15のSFIT)内に記録される(ステップS57)。
【0484】
以上のようにすれば、(暗号化された状態の)ストリームデータの記録/再生が可能になる。
【0485】
上記のような「暗号化されたストリームデータに対する基準クロック同期のずれ補正」方法の代わりに、他の方法として、次のようにしてもよい。
【0486】
すなわち、図20(b)に示すように、各Iピクチャ間に転送されるトランスポートパケット数を時間関係テーブル2に記録する。そして、(ピクチャ指定方法として)再生開始の画面のタイムスタンプ値を指定する代わりに、セル先頭からの通算トランスポートパケット(またはアプリケーションパケット)数を指定する。
【0487】
この場合には、タイムマップ情報252内の情報として、図3(i)に示したデータ構造の代わりに、図11に示すように、ストリームブロック毎に含まれるトランスポートパケット数(またはアプリケーションパケット数AP_Ns)633を持たせる。
【0488】
所定の画面(ピクチャ)にアクセスするためSTB装置416側から通算トランスポートパケット数(通算アプリケーションパケット数)が指定されると、光ディスク装置415側では、図11に示すの最初のストリームブロックから順次トランスポートパケット(アプリケーションパケット)数633が加算されて行き、加算結果が指定された値に達した時点でのストリームブロック(またはSOBU)へ、アクセスが行われる。
【0489】
図26は、この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。以下、図26を用いてストリームデータの再生ステップについて説明する。
【0490】
ユーザは、希望する再生開始時刻および/または再生終了時刻を、「指定したオリジナルセルの表示開始時刻を基準とした差分時間(何時間何分何秒)」の形で指定することができる。こうして指定された、たとえば特定の再生開始時刻および再生終了時刻を、STB装置416内のSTB制御部404が受け取る(ステップS21)。
【0491】
STB制御部404内では、その受け取った再生開始時刻および再生終了時刻の時間情報を、27MHzおよび/または90kHzのクロックカウント値に換算して、オリジナルセルの表示開始時刻からの差分PTS値を算出する。
【0492】
STB制御部404は、光ディスク装置415をコントロールしてストリームデータ管理情報記録領域(STREAM.IFO105)内に記録された時間関係テーブル2(またはPTSL)を読み取り、ワークメモリ部407内に一時記録する(ステップS22)。
【0493】
また、STB制御部404は、光ディスク装置415をコントロールしてストリームデータ管理情報記録領域(STREAM.IFO105)内に記録されたタイムマップ情報252(またはMAPL)の情報を読み取り、ワークメモリ部407内に一時記録する(ステップS23)。
【0494】
次に、図3(h)および図20(a)に示したPTSオフセット9の値を読み取り、該当するオリジナルセル(図20(a)ではBピクチャfに該当)の表示開始時刻とその直前のIピクチャaの表示時刻との差(図20(a)ではPTSNo.5−PTSNo.1)を調べる(ステップS24)。
【0495】
さらに、図3(h)および図20(a)に示したPTSオフセット9の値を読み取り、
(イ)その値(PTSオフセット9)と、
(ロ)オリジナルセルの表示開始時刻の直前のIピクチャ−a位置でのPTS値(PTSNo.1)(図20(a)のようにオリジナルセルの表示開始ピクチャfがIピクチャaの直後にある場合)と、
(ハ)ステップS24で調べた差分PTS値(PTSNo.5−PTSNo.1)と
を加算し、ユーザが指定した再生開始時刻と再生終了時刻のPTS値を算出する(ステップS25)。
【0496】
次に、ユーザが指定した再生開始場所の直前のIピクチャiのPTS値とタイムスタンプ#2の値を、時間関係テーブル2を利用して調べ(ステップS26)、光ディスク装置415に通知する。
【0497】
光ディスク装置は、図3(h)に示したタイムマップ情報252のデータ(図3(i))から、そのIピクチャi情報6010(図21(c))の先頭位置が含まれるストリームブロック(SOBU)#Aの先頭のタイムスタンプ(ATS)#1の値を調べるとともに、アクセスすべき先頭セクタ#αの場所(アドレス)を割り出す(ステップS27)。
【0498】
こうして割り出されたアドレスに基づいて、光ディスク装置415は、図21(c)のトランスポートパケット(AP)#1からの情報を、情報記憶媒体201から再生する(ステップS28)。
【0499】
次に、図19のSTB制御部404は、デコーダ部402へ、ステップS28で再生を開始した情報の表示開始時刻を示すPTS値(図21(a)のPTSNo.6)を通知する(ステップS29)。
【0500】
この通知とともに、光ディスク装置415はSTB装置416側に、ステップS28で再生を開始した情報を転送する(ステップS30)。
【0501】
続いて、STB制御部404は、デコーダ部402内のメモリ426からピクチャ識別情報52(図1(k))を読み取り、入力されたIピクチャ(光ディスク装置415から転送されてきた情報の一部)より前のデータを破棄(あるいは無視)する(ステップS31)。
【0502】
次に、図19のビデオデコード部428は、ステップS31で入力されたIピクチャ(図21(a)ではIピクチャi)の先頭位置からデコードを開始し、ステップS29の通知により指定されたPTS値(図21(a)のPTSNo.6)のところから、表示(ビデオ出力)を開始する(ステップS32)。
【0503】
以下、ステップS24〜S28と同様な処理を反復し、再生終了時刻に対応した情報記憶媒体201上のアドレスを調べ、再生終了時刻に対応した終了アドレスまで再生を継続する(ステップS33)。
【0504】
上記の一連の再生が終了した段階で、図7(g)に示す再生終了位置情報6110を、レジューム情報として、管理情報記録領域(図7(e)に示すSTREAM.IFO105)内のビデオマネージャ情報231(図7(F))中に記録することができる。
【0505】
この再生終了位置情報6110のデータ内容としては、図7(h)に示すように該当するPGC番号6210とその中のセル番号6220、再生終了位置時刻情報6230が記録される。
【0506】
この時刻情報6230はタイムスタンプ値で記録されているが、PTS値(あるいはセル再生先頭位置からの通算フィールド数)を時刻情報6230として記録することもできる。
【0507】
再度この再生終了位置情報を(レジューム)情報6110の位置から再生開始する場合には、後述する図27の処理により再生開始位置を求めることができる。
【0508】
図26を参照して上述したような標準再生時には、STB装置416内の基準クロック作成部であるSTC部424のカウント値が、図1(k)に示すDTS(デコードタイムスタンプ)情報54の値に一致した時から、デコーダ部402内のデコードが開始される。
【0509】
図27は、この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0510】
早送り再生(ファーストフォワードFF)あるいは早戻し再生(ファーストリバースFR)などの特殊再生を行う場合には、情報記憶媒体201上に記録されたIピクチャ情報のみを抽出再生し、デコード表示する。
【0511】
この場合、STC部424(図19)とDTS情報54(図1(k))と間の同期をはずし、フリーモードでデコードするように、デコーダ部402に対して「特殊再生モードの設定」を行う(ステップS41)。
【0512】
特殊再生時にも、時間関係テーブル2とタイムマップ情報252の情報を情報記憶媒体201の管理情報記録領域(STRAM.IFO)105から読み取り、STB制御部404のワークメモリ部407内に記録する(ステップS42)。
【0513】
次に、該当する再生開始場所に対応したストリームオブジェクト情報(SOBI)242のタイムマップ情報252を読み取り、STB制御部404内のワークメモリ部407に一時記録する(ステップS43)。
【0514】
次に、時間関係テーブル2から、各Iピクチャ位置(図16の例では各AU#の位置)での開始時刻/終了時刻のタイムスタンプ値を抽出する(ステップS44)。
【0515】
次に、タイムマップ情報252から、該当するIピクチャのタイムスタンプ値が含まれるストリームブロック(SOBU)を調べ、その先頭セクタのアドレスを調べる(ステップS45)。
【0516】
たとえば、特殊再生時には、後述する図28(b)のIピクチャ情報6010〜6050のみがデコードされて表示される。このIピクチャ情報6010〜6050の位置は、時間関係テーブル2およびタイムマップ情報252の情報を利用して、求めることができる。
【0517】
次に、光ディスク装置415は、情報記憶媒体201上の各Iピクチャが含まれる禅ストリームブロック(SOBU)内の情報を再生し、再生した情報を多重化情報分離部425内のメモリ部426に転送する(ステップS46)。
【0518】
次に、図19のデコーダ部402内において、多重化情報分離部425のメモリ部426に転送されたデータ内のピクチャ識別情報52(図1(k))を読み取り、この情報52を基にIピクチャ以外のデータを破棄する(ステップS47)。
【0519】
つまり、ステップS47においては、再生・転送されたストリームデータの中から、ピクチャ識別情報52を用いてIピクチャ情報のみが抽出され、ビデオデコード部428において抽出されたIピクチャ情報のみがデコードされる。
【0520】
次に、デコーダ部402内の多重化情報分離部425のメモリ部426内部で選別された(つまり破棄されなかった)Iピクチャデータを、フレームメモリ部406に転送する(ステップS48)。
【0521】
こうしてフレームメモリ部406に転送されたIピクチャのデータが、TV(あるいはビデオモニタ)437の表示スクリーン上で、逐次表示される(ステップS49)。
【0522】
図28は、この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。
【0523】
図20の実施の形態では、表示時刻情報として図20(b)に示すように絶対値表示を行なっているが、その代わりに各Iピクチャ間の差分情報(例えば各Iピクチャ間に挿入されるフィールド数情報)を使用することも可能である。
【0524】
また、図20(b)では表示時刻情報として”PTS情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面(ピクチャ)からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。この場合の例が、図28の時間関係テーブル6である。
【0525】
図28(b)に示すように、各グループオブピクチャ(GOP)は、あるIピクチャ位置を先頭とし、そのIピクチャから次のIピクチャの直前までのピクチャ群を示す。図28(c)に示した時間関係テーブル6のデータ構造では、表示時間情報として、各GOP毎の表示フィールド枚数が記録されている。
【0526】
また、時間関係テーブル6内に、GOP毎に占有しているストリームブロック(SOBU)の個数も記載している。こうすることで、図3(h)に示したタイムマップ情報252を使用せずに、与えられた表示時間情報から、直接、Iピクチャ情報の先頭位置が記録してあるストリームブロック(SOBU)へのアクセスか可能となる。
【0527】
図28(b)の例におけるGOP#2とGOP#3の境界位置では、GOPの切り替わり位置とストリームブロック(SOBU)の切り替わり位置が一致している。このように隣接GOPの境界と隣接SOBUの境界とが一致する場合に、図28(c)に示した時間関係テーブル6内のGOP終端マッチングフラグが”1”に設定される。こうすることにより、Iピクチャ情報先頭位置が含まれるストリームブロック位置(SOBU位置)の同定精度を向上させている。
【0528】
また、前述したFFあるいはFR等の特殊再生時においてはIピクチャ情報の後端位置を使用するので、図28(c)の時間関係テーブル6には各GOP内のIピクチャサイズ情報も持たせている。
【0529】
図29は、この発明の一実施の形態において、ストリームデータ(SOBU)内のパケット(AP)がどのように再生されるかを説明する図である。
【0530】
図29は、図1(c)のストリームブロック##1、#2、…を、全て一定サイズ(2ECCブロックサイズ)のSOBU#1、#2、…で構成した場合を例示している。
【0531】
図29(f)は、SOBU#1の先頭セクタNo.0(図29(e))のデータ構造と、SOBU#1に隣接するSOBU#2の末尾セクタNo.63(図29(e))のデータ構造を示している。図示しないが、セクタNo.0〜セクタNo.62も同様な構想を持つ。
【0532】
図29(f)に示すように、セクタNo.0に対応するストリームパックのパックヘッダにはシステムクロックリファレンスSCRが記録され、セクタNo.63に対応するストリームパックのパックヘッダにもシステムクロックリファレンスSCRが記録されている。
【0533】
いま、再生しようとするピクチャ(ユーザが再生時間で指定したピクチャ)がSOBU#2の中間(図16では、たとえばAU#1が示す位置)に存在するとする。ユーザが再生時間で指定したピクチャは、セル開始アプリケーションパケット到着時間SC_S_APATに対応する。
【0534】
この場合、図19の記録再生部409に含まれるディスクドライブ(図示せず)は、SOBU#2の中間に直接アクセスすることはできず、SOBU#1とSOBU#2との境界位置にアクセスする。そして、図29(a)のストリームデータ(STREAM.VRO)106の再生は、SOBU#1とSOBU#2との境界位置から始まる。
【0535】
SOBU#1とSOBU#2との境界位置から再生開始位置(SC_S_APATに対応する位置)までの間隔は、図20(a)で説明したPTSオフセット9に対応する。
【0536】
SOBU#1とSOBU#2との境界位置から再生開始位置(SC_S_APATに対応する位置)までの間に存在するアプリケーションパケットは、デコードはされているが、再生出力はされない(画面表示されない)。これは、図26のステップS31の処理に対応している。
【0537】
図29(g)は、PTSの情報(PTS値あるいはPTSオフセット)と再生しようとするアプリケーションパケットAPとが、図20(a)の時間関係テーブル2によって関係付けられていることを図解したものである。
【0538】
ここで、上記時間関係テーブルと図15に示した再生タイムスタンプリストPTSLとの関係について、改めて整理しておく。
【0539】
図1(g)その他に示されたタイムスタンプをATSとしたとき、図15の再生タイムスタンプリストPTSLに含まれるPTSの値とATSとは、以下のような関係を持つ:
(1)ストリームセルは記録されたビットストリームの一部を参照するものである;
(2)AU(通常Iピクチャ)は記録されたビットストリームの連続した一部である(AUはセルの一部に対応する);
(3)AU(セルの一部に対応するIピクチャ)がどのSOBUに含まれるかは、AUSMにより示される(図16参照);
(4)PTSの値は対応AUの再生時間(表示時刻;あるいはプレゼンテーションタイムPTM)である(AUに対応するPTSの値は、再生時間に関して、セルの一部に対応する);
(5)セル開始APAT(SC_S_APAT)は該当セルのアプリケーションパケットAPの到着時間である(SC_S_APATは、再生時間に関して、PTSの値に対応する);
(6)アプリケーションパケットAPは、その先頭にタイムスタンプATSを伴う(図29(g)等参照);
(7)PTSの値は、PTSLに含まれる(図15参照);
(8)上記から、PTSLに含まれるPTSの値は、AUSM、SC_S_APAT等を仲介して、ATSに対応する。
【0540】
よって、再生タイムスタンプリストPTSLは、AU(Iピクチャ)の開始時刻(SC_S_APAT)と、ビットストリームに含まれるパケットのタイムスタンプATSとの関係(再生時間に関する関係)を示す情報(PTSの値)を含む「時間関係テーブル(図20(b))」である。
【0541】
あるいは、PTSL(時間関係テーブル)は、PTSの値とATSとの対応関係を示す情報であるとも言える。
【0542】
最後に、各実施の形態の説明中で用いた一部の用語の意味について纏めておく:
*ストリームオブジェクト(SOB)は、記録済みビットストリームのデータを示す。SR_TRANS.SROファイル内には、最大999個のSOBを記録できる。
【0543】
*ストリームオブジェクトユニット(SOBU)は、SOB内にオーガナイズされる基本単位である。つまり、各SOBは、SOBUの連なり(チェーン)からなる。なお、とくに編集後は、SOBの先頭および/または末尾のSOBUは、そのSOBの有効部分に属していないデータを含むことがある。
【0544】
SOBUは、再生時間あるいは再生順序により特徴付けられるのではなく、一定サイズ(32セクタ分のサイズあるいは2ECCブロック分のサイズ)により特徴付けられる。
【0545】
*アクセスユニット(AU)は、個別の再生に適した記録済みビットストリームにおける、任意の単一連続部分を指す。このAUは、MPEGエンコードされたビットストリームにおいては、通常はIピクチャに対応する。
【0546】
*アクセスユニット開始マップ(AUSM)は、該当SOBのどのSOBUがAUを含むのかを示すものである。
【0547】
*アプリケーションパケット(AP)は、記録中にアプリケーションデバイスからやってくるビットストリームの一部である。あるいは、APは、再生中にアプリケーションデバイスへ行くビットストリームの一部である。これらのAPは、多重化トランスポートに含まれ、記録中は一定サイズ(最大64574バイト)を持つ。
【0548】
*アプリケーションタイムスタンプ(ATS)は、各APの前に配置され、32ビット(4バイト)で構成される。ATSは、90kHzの基本部分と27MHzの拡張部分とで構成されている。
【0549】
*セル(あるいはストリームセルSC)は、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルはオリジナルセルと呼ばれ、ユーザ定義PGC内のセルはユーザ定義セルと呼ばれる。プログラムセット中の各プログラムは、少なくとも1つのオリジナルセルからなる。夫々のプレイリスト内のプログラムの各部分は、少なくとも1つのユーザ定義セルからなる。ストリーマにおいて、単にセルという場合は、ストリームセル(SC)のことをいう。各SCは記録済みビットストリームの一部を参照するものである。
【0550】
*セル番号(CN)は、PGC内のセルに割り振られた番号(1〜999)である。
【0551】
*ストリームセルエントリポイント情報(SC_EPI)は、記録の一部をスキップするための道具として用いるもので、任意のストリームセル(SC)内に存在できる。
【0552】
*ストリームオブジェクトの開始アプリケーションパケット到着時間(SOB_S_APAT)は、該当SOBに属する最初のAPの到着時間を指す。この到着時間は、90kHzの基本部分と27MHzの拡張部分とで構成されている。
【0553】
*ストリームオブジェクトの終了アプリケーションパケット到着時間(SOB_E_APAT)は、該当SOBに属する最後のAPの到着時間を指す。
【0554】
*ストリームセルの開始アプリケーションパケット到着時間(SC_S_APAT)は、該当SCに属する最初のAPの到着時間を指す。
【0555】
*ストリームセルの終了アプリケーションパケット到着時間(SC_E_APAT)は、該当SCに属する最後のAPの到着時間を指す。
【0556】
*ナビゲーションデータは、ビットストリーム(SOB)に対する、記録、再生、および編集の制御をする際に用いられるデータである。
【0557】
*プレイリスト(PL)は、ユーザが再生シーケンスを任意に定義できるプログラム部分のリストである。PLは、ユーザ定義PGCとして記述される。
【0558】
*プログラム(PG)は、ユーザにより認識されあるいは定義されるところの、記録内容の論理単位である。プログラムセット内のプログラムは、1以上のオリジナルセルからなる。プログラムは、オリジナルPGC内でのみ定義される。
【0559】
*プログラムチェーン(PGC)は、上位概念的な単位である。オリジナルPGCの場合、PGCはプログラムセットに対応するプログラムの連なり(チェーン)を示すものである。一方、ユーザ定義PGCの場合は、PGCはプレイリストに対応するものであってプログラムの一部の連なり(チェーン)を示すものである。
【0560】
*プログラムチェーン情報(PGCI)は、PGCの全体的な再生を示すデータ構造である。PGCIはオリジナルPGCおよびユーザ定義PGCのいずれでも使用される。ユーザ定義PGCはPGCIだけで構成され、そのセルはオリジナルPGC内のSOBを参照するようになっている。
【0561】
*プログラムチェーン番号(PGCN)は、ユーザ定義PGCに割り振られた連続番号(1〜99)である。
【0562】
*プログラム番号(PGN)は、オリジナルPGC内のプログラムに割り振られた連続番号(1〜99)である。
【0563】
*プログラムセットは、全てのプログラムで構成されるディスク(記録媒体)の記録内容全体を指す。オリジナルの記録に対して再生順序が変わるような編集がどのプログラムに対してもなされていないなら、プログラムセットの再生にあたっては、プログラムの記録順序と同じ再生順序が用いられる。
【0564】
*リアルタイム記録とは、バッファメモリサイズが限られている場合において、制限された転送レートでコード化された任意のストリームデータを制限された転送レートで転送している限り、バッファメモリがオーバーフローすることなく、そのストリームデータをディスク(記録媒体)に記録できるような記録をいう。
【0565】
この発明に係る各実施の形態における効果をまとめると以下のようになる:
1.ストリームデータ内に記録されたタイムスタンプデータ(ATS)とユーザに対する表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブルあるいはPTSL)を管理情報(SFIT)の一部に持たせることにより、高い精度で、ユーザが指定した表示時刻から、再生/画面表示を開始させることが可能となる。
【0566】
2.ユーザは、編集時に、記録済みのストリームデータの部分消去範囲または並び替えの指定範囲を、モニタTV上での表示時刻で指定する。
【0567】
上記「1.」のように、ストリームデータ内に、管理情報(SFIT)の一部として、タイムスタンプデータと表示時刻情報との間の関係を示す時間関係テーブル(あるいはPTSL)を持たせる。これにより、この時間関係テーブル(あるいはPTSL)を用いて、正確に編集点位置(部分消去範囲あるいは並び替えの指定範囲)を設定することが可能となる。その結果、ストリームデータに対する時間管理をタイムスタンプデータ(ATS)を用いて行うことができ、かつユーザリクエストに応じた正確な編集処理を保証できる。
【0568】
3.上記「1.」のように、ストリームデータ内に時間関係テーブル(あるいはPTSL)を持たせてあるので、タイムスタンプデータ(ATS)あるいは表示時刻情報(PTS)のいずれか一方の情報を再生終了位置情報(レジューム情報)として記載するだけで、ストリーマ再起動時の再生開始位置(レジューム再生開始位置)を、正確に設定できる。
【0569】
4.再生終了位置情報(レジューム情報)をタイムスタンプデータ(ATS)で記録することにより、情報記憶媒体上の特定位置にアクセスする場合、タイムマップ情報252を用いてアクセスすべきアドレスを、素早く知ることができる。
【0570】
5.MPEGによる圧縮データは必ずIピクチャからの再生開始が必要となる。各Iピクチャ開始位置(あるいはアクセスユニットAUの開始位置)でのタイムスタンプデータ(ATS)と表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブル)を記録することにより、所望のIピクチャ(所望のAU)へのアクセス制御を、タイムマップ情報252を用いて高速に行える。
【0571】
6.各Iピクチャ開始位置(各AUの開始位置)でのタイムスタンプデータ(ATS)と表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブル)を記録することにより、タイムマップ情報252との組み合わせで、Iピクチャ(AU)を含むストリームブロック(あるいはSOBU)位置のアドレスが分かる。このため、Iピクチャのみの再生・表示を行うファーストフォワードFFあるいはファーストリバースFRなどの特殊再生処理が可能となる。
【0572】
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
【0573】
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から1または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも1つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。
【0574】
【発明の効果】
以上述べたように、この発明によれば、ストリーム情報記録の処理に関する改善を図ることができる。
【図面の簡単な説明】
【図1】この発明の一実施の形態に係るストリームデータのデータ構造を説明する図。
【図2】この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図。
【図3】この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図。
【図4】この発明におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図。
【図5】タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容その他を説明する図。
【図6】オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図。
【図7】この発明の他の実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに再生終了位置情報/レジューム情報、VMGI管理情報/記録時間情報等の構造)を説明する図。
【図8】図1その他に示されたPESヘッダの内部構造を説明する図。
【図9】図1に示されたストリームブロックヘッダの内部構造を説明する図。
【図10】図1に示されたセクタデータヘッダの内部構造を説明する図。
【図11】この発明の一実施の形態におけるタイムマップ情報の他例を説明する図。
【図12】ストリームブロック(SOBU)を構成するセクタの内部構成(アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック)の一例を説明する図。
【図13】ストリーマの管理情報(図2のSTREAM.IFOまたはSR_MANGR.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】この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図。
【図20】この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。
【図21】この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図。
【図22】MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図。
【図23】デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図。
【図24】この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図。
【図25】この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャート図。
【図26】この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャート図
【図27】この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャート図。
【図28】この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図。
【図29】この発明の一実施の形態において、ストリームデータ(SOBU)内のパケット(AP)がどのように再生されるかを説明する図。
【符号の説明】
201…情報媒体、415…光ディスク装置、416…STB装置。

Claims (5)

  1. MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって
    トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、
    1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前ストリームデータが形成され、
    前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、
    前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、
    前記第2データ単位は前記ヘッダ情報を含み、
    前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、
    前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、
    前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、
    前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、
    前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録された情報記憶媒体。
  2. MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、前記第2データ単位は前記ヘッダ情報を含み、前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録されるように構成された情報記憶媒体を用いる記録方法において、
    1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータを形成し、
    前記第2データ単位内に、前記第1データ単位の時間に関する情報を含むヘッダ情報を格納し、
    前記時間に関する情報を含む前記ヘッダ情報を含めて、前記ストリームデータを前記データエリアに記録し、
    前記リアルタイムビデオオブジェクトデータを前記データエリアに記録し、
    前記管理情報を前記管理エリアに記録するとともに前記管理情報のファイルを前記情報記憶媒体に記録するように構成された記録方法。
  3. MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、前記第2データ単位は前記ヘッダ情報を含み、前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録された情報記憶媒体を用いる再生方法において、
    前記管理エリアから前記管理情報を読み取り、
    前記データエリアから前記第2データ単位で前記ストリームデータを読み取るように構成された再生方法。
  4. MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、前記第2データ単位は前記ヘッダ情報を含み、前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録されるように構成された情報記憶媒体を用いる記録装置において、
    1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータを形成し、前記第2データ単位内に前記第1データ単位の時間に関する情報を含むヘッダ情報を格納する手段と、
    前記時間に関する情報を含む前記ヘッダ情報を含めて、前記ストリームデータを前記データエリアに記録する手段と、
    前記リアルタイムビデオオブジェクトデータを前記データエリアに記録する手段と、
    前記管理情報を前記管理エリアに記録する手段と、
    前記管理情報のファイルを前記情報記憶媒体に記録する手段
    を具備した記録装置。
  5. MPEGエンコードされIピクチャの情報を有しトランスポートストリームを含むストリームデータを記録するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、前記第2データ単位は前記ヘッダ情報を含み、前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの再生終了位置に関する情報が記録された情報記憶媒体を用いる再生装置において、
    前記管理エリアから前記管理情報を読み取る手段と、
    前記データエリアから前記第2データ単位で前記ストリームデータを読み取る手段
    を具備した再生装置。
JP2001325399A 1999-02-18 2001-10-23 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置 Expired - Fee Related JP3806020B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001325399A JP3806020B2 (ja) 1999-02-18 2001-10-23 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP11-39461 1999-02-18
JP3946199 1999-02-18
JP2001325399A JP3806020B2 (ja) 1999-02-18 2001-10-23 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2000600426A Division JP3805985B2 (ja) 1999-02-18 2000-02-18 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置

Publications (2)

Publication Number Publication Date
JP2002197808A JP2002197808A (ja) 2002-07-12
JP3806020B2 true JP3806020B2 (ja) 2006-08-09

Family

ID=26378862

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001325399A Expired - Fee Related JP3806020B2 (ja) 1999-02-18 2001-10-23 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置

Country Status (1)

Country Link
JP (1) JP3806020B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3805985B2 (ja) 1999-02-18 2006-08-09 株式会社東芝 ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
AU2003280705A1 (en) * 2002-11-05 2004-06-07 Matsushita Electric Industrial Co., Ltd. Data processing device
WO2004045207A1 (ja) * 2002-11-12 2004-05-27 Matsushita Electric Industrial Co., Ltd. 記録再生装置および方法
JP4311570B2 (ja) * 2005-07-01 2009-08-12 株式会社ソニー・コンピュータエンタテインメント 再生装置、ビデオ復号装置および同期再生方法
KR101346735B1 (ko) 2007-07-13 2014-01-03 삼성전자주식회사 전송 스트림 저장장치 및 방법

Also Published As

Publication number Publication date
JP2002197808A (ja) 2002-07-12

Similar Documents

Publication Publication Date Title
JP3805985B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP5159969B2 (ja) ストリームデータを記録する情報記憶媒体、記録方法、再生方法、および再生装置
JP3715533B2 (ja) ストリーム情報の情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3806020B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3806019B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3806017B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP4138774B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3806018B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3927010B2 (ja) ストリームデータの記録方法、再生方法、記録装置および再生装置
JP3615174B2 (ja) ストリーム情報記録に用いる情報媒体、情報記録方法、情報再生方法、および情報再生装置
JP3655570B2 (ja) ストリームデータの記憶媒体、この媒体を用いる記録方法と再生方法、およびこの媒体を用いる記録装置と再生装置
JP4138776B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP4203042B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP4138775B2 (ja) ストリームデータの情報記憶媒体、その記録方法、再生方法、記録装置および再生装置
JP3896130B2 (ja) Mpegトランスポートストリームのストリームデータおよびその管理情報を記録する情報媒体と、mpegトランスポートストリームのストリームデータおよびその管理情報を記録する情報媒体を用いる記録方法、再生方法、記録装置、および再生装置
JP2002175683A (ja) ストリームデータの記録方法およびそのデータ構造
JP3930503B2 (ja) Mpegトランスポートストリームのストリームデータおよびその管理情報を記録する情報媒体と、mpegトランスポートストリームのストリームデータおよびその管理情報を記録する情報媒体を用いる記録方法、再生方法、記録装置、および再生装置
JP4528749B2 (ja) ストリーム情報記録に用いる情報媒体、情報記録方法、情報再生方法、および情報再生装置
JP3917614B2 (ja) ストリームデータの情報媒体、記録方法、再生方法および再生装置
JP2002170337A (ja) ストリームデータの記録方法およびそのデータ構造
JP2007294104A (ja) ストリームデータを記録する情報媒体、記録方法、再生方法、および再生装置
JP2005045830A (ja) ストリームデータを記録する情報媒体、記録方法、再生方法、および再生装置
JP2007080509A (ja) ストリームデータの記録方法、再生方法および再生装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050104

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050208

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050411

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20051011

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051212

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060124

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060327

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20060509

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060511

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090519

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100519

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110519

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110519

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120519

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120519

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130519

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130519

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140519

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees