JP3806017B2 - Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus - Google Patents
Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus Download PDFInfo
- Publication number
- JP3806017B2 JP3806017B2 JP2001325395A JP2001325395A JP3806017B2 JP 3806017 B2 JP3806017 B2 JP 3806017B2 JP 2001325395 A JP2001325395 A JP 2001325395A JP 2001325395 A JP2001325395 A JP 2001325395A JP 3806017 B2 JP3806017 B2 JP 3806017B2
- 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
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
- Management Or Editing Of Information On Record Carriers (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データ単位のタイムスタンプの位置を示す情報が記録される。また、前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ、前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、前記管理情報に前記ストリームデータの前記Iピクチャ部分に対応した時間関係情報が記録されるように構成される。
【0018】
なお、前記ストリームデータは、一定サイズのデータユニット(例えば64kBのSOBU)で構成することができる。
【0019】
【発明の実施の形態】
以下、図面を参照して、この発明の一実施の形態に係るストリームデータ記憶媒体、この媒体に記録されるストリームデータに関する管理情報のデータ構造、およびこの管理情報の記録方法と再生方法その他を説明する。
【0020】
図1は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。図1を用いて情報記憶媒体上に記録されたストリームデータのデータ構造について説明する。
【0021】
DVD−RAMディスク等の情報記憶媒体(図3その他の201)上に記録されるストリームデータ(STREAM.VRO)106(図1(a))は、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(以下、適宜SOBと略記する)としてまとめられている。つまり、各SOBは、1つのリアルタイムな連続記録により得られたストリームデータにより形成される。
【0022】
情報記憶媒体上に記録されるストリームデータは、図1(b)に示されるように、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト(SOB)#A・298、#B・299としてまとまって記録されている。
【0023】
図1(b)〜(k)は、複数あるストリームオブジェクト(SOB#A、#B、…)のうち、1個のSOB#A・298について内容を詳細に示している。
【0024】
DVD−RAMディスクにトリームデータ(STREAM.VRO)106が記録される場合には、各々が2048バイトのセクタを最小単位として記録される。さらに、16個のセクタをまとめて1個のECCブロックとし、同一ECCブロック内でインターリーブ(データ配列順序の並び替え)とエラー訂正用の訂正コードの付加が行われる。
【0025】
この実施の形態では、1個または複数(代表的には2個)のECCブロックを単位としてストリームブロック(あるいはストリームオブジェクトユニットSOBU)が構成され、このストリームブロック単位(あるいはSOBU単位)でストリーム情報の記録、部分消去、編集その他が行われる。
【0026】
この実施の形態では、何個のECCブロックでストリームブロックが構成されるかは、転送されるストリームデータ(STREAM.VRO)106の転送レートに応じて決めることができる。
【0027】
たとえば、図1(c)(d)の例では、ストリームブロック#1は2つのECCブロック#α、#βで構成され、ストリームブロック#2は3つのECCブロック#γ、#δ、#εで構成されている。DVDストリーマでは、2個のECCブロック(32セクタ)で1つのストリームブロック(またはSOBU)が構成される。
【0028】
各ECCブロックは、図1(e)に示すように、16セクタで構成される。したがって、図1(c)〜(e)から分かるように、2ECCブロックで構成されるストリームブロック(あるいはSOBU)#1は、32セクタ(セクタNo.0〜セクタNo.31)に相当する。
【0029】
つまり、1セクタ=2kバイトとすれば、ストリームブロック(SOBU)は、64kバイト(32セクタ)の固定サイズとして、この発明を実施することができる。
【0030】
ストリームデータ(STREAM.VRO)106は、図1(g)に示すようにタイムスタンプとトランスポートパケットを組にして、情報記憶媒体に記録される。
【0031】
その際、各セクタの先頭には、図1(f)に示すように、システムクロック情報(システムクロックリファレンスSCR)等が記録されたパックヘッダ11、12とPESヘッダ13、14が配置される。PESヘッダ14の直後にはセクタデータヘッダ17が記録されるが、各ストリームブロック(またはSOBU)先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ16が記録される。
【0032】
なお、ストリームブロックヘッダ16あるいはセクタデータヘッダ17は、後述するアプリケーションヘッダに対応する内容を持つことができるようになっている(図9あるいは図10参照)。
【0033】
図1(f)のセクタデータヘッダ17は、データエリア22、23内のデータ配列情報を示している。
【0034】
図1(f)のデータエリア21、22(あるいは23)には、図1(g)に示すように、タイムスタンプ(図20、図29その他に示したATSに対応)およびトランスポートパケット(図22または図23のパケット、あるいは図29のアプリケーションパケットAPに対応)が逐次詰め込まれる。
【0035】
図1(g)の例では、1個のトランスポートパケットdが複数のセクタ(No.0とNo.1)に跨って記録される場合が例示されている。このようなトランスポートパケットdは、図22または図23の部分パケットに対応する。
【0036】
ところで、デジタル放送では、トランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式が採用されており、1個のトランスポートパケットのサイズは188バイト(または183バイト)の場合が多い。
【0037】
一方、前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても、1個のデータエリア21、22、23(図1(f))内には、デジタル放送用のトランスポートパケットを10個前後記録できる。
【0038】
トランスポートパケット内は、図1(h)に示すように、トランスポートパケットヘッダ61〜64(後述する図23(b)の511に対応)とデータが記録されているペイロード71〜75(後述する図23(b)の512に対応)とで構成されている。
【0039】
ペイロード71〜75には、図1(i)に示すように、MPEGエンコードされたIピクチャ情報31、Bピクチャ情報33、34、およびPピクチャ情報32が記録される。
【0040】
Iピクチャ情報31が記録されている最初のトランスポートパケットでは、ランダムアクセスインジケータ503(図23(a)参照)に”1”のフラグが立ち、各B、Pピクチャ情報32〜34の最初のトランスポートパケットにはペイロードユニット開始インジケータ501(図23(a)参照)に”1”のフラグが立つ。
【0041】
ペイロード71〜75内に分割記録されている各ピクチャ情報31〜34には、図1(j)に示すように、それぞれの先頭に、ピクチャヘッダ情報41と、実質的なピクチャ情報であるピクチャ圧縮情報42(Iピクチャ情報31に対してはIピクチャ圧縮情報42)とが記録されている。
【0042】
また、それぞれのピクチャヘッダ情報41内には、図1(k)に示すように、ヘッダ識別情報51、それぞれのI、B、Pピクチャの識別を可能とするピクチャ識別情報52、デコーダ出力の表示タイミングを示すPTS(プレゼンテーションタイムスタンプ)情報53、およびデコーダがデコード開始を行うためのタイミングを示すDTS(デコードタイムスタンプ)情報54が記録されている。これらのピクチャヘッダ情報41は、デジタル放送の受信情報内に予め含まれている。
【0043】
情報記憶媒体上に記録されたストリームデータ内では、図1(k)に示すピクチャ識別情報52を用いて特定のピクチャ位置を同定できる。
【0044】
あるいは、図1(j)(k)に示すようにピクチャヘッダ情報41内にPTS情報53が記録されているので、この値を用いてデコーダが表示を開始することも可能である。
【0045】
図2は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。図2を用いて、この発明の一実施の形態に係る情報記憶媒体上に記録される情報の内容(ファイル構造)について説明する。
【0046】
DVDーRAMディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、DVD_RTRディレクトリ(またはDVD_RTAV)102と言う名のサブディレクトリ101内に入っている。
【0047】
DVD_RTR(DVD_RTAV)ディレクトリ102内には、以下の内容のデータファイル103が格納される。
【0048】
すなわち、管理情報(ナビゲーションデータ)のグループとして、RTR.IFO(またはVR_MANGR.IFO)104と、STREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、SR_PRIVT.DAT/SR_PRIVT.BUP105aとが格納される。
【0049】
また、データ本体(コンテンツ情報)として、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とが格納される。
【0050】
上記データファイル103を含むサブディレクトリ101の上位階層にあるルートディレクトリ100には、その他の情報を格納するサブディレクトリ110を設けることができる。
【0051】
このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットVIDEO_TS111、オーディオプログラムを収めたオーディオタイトルセットAUDIO_TS112、コンピュータデータ保存用のサブディレクトリ113等がある。
【0052】
有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。
【0053】
そのストリームデータそのものはSTREAM.VRO(またはSR_TRANS.SRO)106と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、STREAM.IFO(またはSR_MANGR.IFOとそのバックアップファイルSR_MANGR.BUP)105である。
【0054】
また、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である。
【0055】
図3は、この発明の一実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに管理情報の構造)を説明する図である。
【0056】
図3(a)の情報記憶媒体201の内周方向202の端部と外周方向203の端部とで挟まれた領域には、図3(b)に示すように、リードインエリア204と、ファイルシステム情報が記録されているボリューム&ファイル構造情報206と、データエリア207と、リードアウトエリア205が存在する。リードインエリア204はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア205は書替可能データゾーンで構成されている。データエリア207も書替可能データゾーンで構成されている。
【0057】
データエリア207内は、図3(c)に示すように、コンピュータデータとオーディオ&ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア208およびコンピュータデータエリア209の間に、オーディオ&ビデオデータエリア210が、挟まれる形態となっている。
【0058】
オーディオ&ビデオデータエリア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とが記録される。
【0059】
同じく図3(e)に示すように、ストリーム記録エリア222には、図2に示された、ストリーマのナビゲーションデータSTREAM.IFO(SR_MANGR.IFO/SR_MANGR.BUP)105と、トランスポートビットストリームデータSTREAM.VRO(SR_TRANS.VRO)106とが記録される。
【0060】
なお、図3(d)(e)では図示しないが、ストリーム記録エリア222には、図2に示したアプリケーション固有のナビゲーションデータSR_PRIVT,DAT/SR_PRIVT.BUP105aを記録することもできる。
【0061】
このSR_PRIVT,DAT105aは、ストリーマに接続(供給)された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。
【0062】
ストリームデータに関する管理情報であるSTREAM.IFO(またはSR_MANGR.IFO)105は、図3(f)〜(i)に示すようなデータ構造を有している。
【0063】
すなわち、図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とで構成されている。
【0064】
図3(f)のストリームファイル情報テーブル(SFIT)232は、図3(g)に示すように、ストリームファイル情報テーブル情報(SFITI)241と、1以上のストリームオブジェクト情報(SOBI)#A・242、#B・243、………と、オリジナルPGC情報一般情報271と、1以上のオリジナルセル情報#1・272、#2・273………とを含むことができるようになっている。
【0065】
図3(g)の各ストリームオブジェクト情報(たとえばSOBI#A・242)は、図3(h)に示すように、ストリームオブジェクト一般情報(SOBI_GI)251、タイムマップ情報252、その他を含むことができる。
【0066】
また、図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とを含むことができる。
【0067】
ここで、PTSオフセット9とは、オリジナルセル(オリジナルセルの詳細は後述する)の表示開始ピクチャのPTS(プレゼンテーションタイムスタンプ)値とその直前にあるIピクチャのPTS値との差分をいう(詳細は図20を参照して後述)。
【0068】
図3(g)のSOBI#Aに含まれる図3(h)のタイムマップ情報252は、図3(i)に示すように、ストリームブロック番号261、第1ストリームブロックサイズ262、第1ストリームブロック時間差263、第2ストリームブロックサイズ264、第2ストリームブロック時間差265、………を含むことができる。タイムマップ情報252を構成する各ストリームブロック時間差の内容については、図5を参照して後述する。
【0069】
図4は、この発明の一実施の形態におけるストリームオブジェクト(SOB)、セル、プログラムチェーン(PGC)等の間の関係を説明する図である。以下、図4の例示を用いてSOBとPGCの関係を説明する。
【0070】
ストリームデータ(STREAM.VROまたはSR_TRANS.SRO)106内に記録されたストリームデータは、1個以上のECCブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理等がなされる。このストリームデータは、記録する情報の内容毎(たとえばデジタル放送での番組毎)にストリームオブジェクトと言うまとまりを作る。
【0071】
STREAM.VRO(SR_TRANS.SRO)106内に記録されたストリームオブジェクト(SOB#A、SOB#B)毎の管理情報(オリジナルPGC情報233、ユーザ定義PGC情報テーブル234等)は、ナビゲーションデータSTREAM.IFO(SR_MANGR.IFO)105(図4の最下部および図3(e)(f)参照)内に記録されている。
【0072】
図4の各ストリームオブジェクト#A・298、#B・299毎の管理情報(STREAM.IFO105)は、図3(f)(g)に示すように、ストリームファイル情報テーブル(SFIT)232内のストリームオブジェクト情報(SOBI)#A・242、#B・243として記録されている。
【0073】
ストリームオブジェクト情報(SOBI)#A・242、(SOBI)#B・243それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報252を含んでいる。
【0074】
ストリームデータの再生時には、1個以上のセルの連続で構成されるプログラムチェーン(PGC)の情報(後述する図14のPGCI#iに対応)が利用される。このPGCを構成するセルの設定順にしたがって、ストリームデータを再生することができる。
【0075】
PGCには、STREAM.VRO(SR_TRANS.SRO)106に記録された全ストリームデータを連続して再生することのできるオリジナルPGC290(図3(f)ではORG_PGCI・233)と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義PGC#a・293、#b・296(図3(f)ではUD_PGCIT・234の中身に対応)の2種類が存在する。
【0076】
オリジナルPGC290を構成するオリジナルセル#1・291、#2・292は、基本的にストリームオブジェクト#A・298、#B・299と一対一に対応して存在する。
【0077】
それに対して、ユーザ定義PGCを構成するユーザ定義セル#11・294、#12・295、#31・297は、1個のストリームオブジェクト#A・298または#B・299の範囲内では任意の位置を設定することができる。
【0078】
なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図4のストリームブロック#1のように、2ECCブロック(32セクタ)で一定サイズ(64kバイト)のストリームオブジェクトユニット(SOBU)を、ストリームブロックとして採用するとよい。
【0079】
このようにストリームブロックを一定サイズ(たとえば2ECCブロック=32セクタ=64kバイト)のSOBUに固定すれば、次の利点が得られる:
(01)SOBU単位でストリームデータの消去あるいは書替を行っても、そのSOBUのECCブロックが、消去あるいは書替対象以外のSOBUのECCブロックに影響しない。そのため、消去あるいは書替に伴う(消去あるいは書替の対象でないSOBUに対する)ECCのデインターリーブ/インターリーブのやり直しが、生じない;
(02)任意のSOBU内部の記録情報に対するアクセス位置を、セクタ数(あるいはセクタ数に対応した他のパラメータ;たとえば後述する図10のストリームパックおよびその内部のアプリケーションパケット群の情報)で特定できる。たとえば、あるSOBU#kの中間位置にアクセスする場合は、SOBU#kー1とSOBU#kとの境界から16セクタ目(あるいは16セクタ目に対応するアプリケーションパケットの位置)を指定すればよい。
【0080】
図5は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図5を用いてタイムマップ情報252内の各データの内容について説明する。
【0081】
図5(f)(g)(h)に例示するように、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1、#2で構成されている。
【0082】
図5(f)(h)の例では、SOB#A・298を構成するストリームブロック#1のデータサイズは2ECCブロック(#α、#β)で構成され、32セクタ分(図5(e)(i))のサイズを持っている。すなわち、タイムマップ情報252(図5(a)(k))内の第1ストリームブロックサイズ262(図5(j))は、32セクタ(64kバイト)となる。
【0083】
SOB#A・298(図5(g))の先頭にあるストリームブロック#1(図5(f))はその先頭にセクタNo.0(図5(e))を持ち、セクタNo.0に含まれるデータエリア21(図5(d))の先頭にはタイムスタンプa(図5(c))が記録されている。
【0084】
また、SOB#A・298(図5(g))の後続ストリームブロック#2(図5(f))はその先頭にセクタNo.32(図5(e))を持ち、セクタNo.32に含まれるデータエリア311(図5(d))の先頭にはタイムスタンプp(図5(c))が記録されている。
【0085】
図5(c)に示すように、ストリームブロック#1の最初のストリームデータのタイムスタンプ値はタイムスタンプaであり、次のストリームブロック#2の最初のストリームデータのタイムスタンプ値はタイムスタンプpとなっている。
【0086】
図5(b)の第1ストリームブロック時間差263(図3(i)のストリームブロック時間差263に対応)の値は、上記タイムスタンプpとタイムスタンプaとの差分値([タイムスタンプp]−[タイムスタンプa])で与えられる。
【0087】
なお、図5(a)のタイムマップ情報252は、図15を参照して後述するストリームオブジェクト情報SOBI内のアクセスデータユニットAUDも含むものとして、取り扱うことができる。このAUDに含まれる情報(アクセスユニット開始マップAUSM等)により、アクセスしたい情報を含むSOBUを特定できる。
【0088】
図6は、オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図である。それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。
【0089】
具体的には、ストリームデータの録画直後のオリジナルセルにおける該当セルの開始時間283および該当セルの終了時間284(図6(b))の時間として、該当するストリームオブジェクト#A・298(図6(f))内の最初のタイムスタンプaの値および最後のタイムスタンプz(図6(c))の値が使用される。
【0090】
それに対して、ユーザ定義セル#12・295(図6(k))での時間範囲指定は、任意時刻を指定できる。たとえば、図6(i)(j)に示すように指定されたトランスポートパケットd、nに対応したタイムスタンプd、nの値を、該当セルの開始時間331と該当セルの終了時間332の値として設定することができる。
【0091】
図6(f)は、ストリームオブジェクト(SOB)#A・298は2つのストリームブロック#1および#2で構成されている場合を例示している。
【0092】
図6(e)(g)の例では、ストリームブロック#1は32セクタ(セクタNo.0〜No.31)で構成され、ストリームブロック#2は48セクタ(セクタNo.32〜No.79)で構成されている。
【0093】
ストリームブロック#1の先頭セクタNo.0は、図6(e)(d)に示すように、パックヘッダ1、PESヘッダ6、ストリームブロックヘッダ11、データエリア21等で構成されている。
【0094】
また、ストリームブロック#2の後方セクタNo.78は、図6(e)(d)に示すように、パックヘッダ3、PESヘッダ8、セクタデータヘッダ13、データエリア24等で構成されている。
【0095】
さらに、図6(g)のセクタNo.1には図6(h)に示すようにパックヘッダ2、セクタデータヘッダ12、データエリア22その他が記録され、図6(g)のセクタNo.33には図6(h)に示すようにセクタデータヘッダ321、データエリア312その他が記録されている。
【0096】
図6(d)(h)のデータエリア21には、図6(c)(i)に示すように、タイムスタンプaとトランスポートパケットaとのペアないしタイムスタンプdとトランスポートパケットdとのペアが記録されている。
【0097】
また、図6(d)のデータエリア24の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプz+トランスポートパケットzのペアの後に続くエンドコード32と、パディングエリア37が記録されている。
【0098】
さらに、図6(h)のデータエリア22には、図6(i)に示すように、データエリア21のトランスポートパケットdの後続内容を含むトランスポートパケットdが含まれている。つまり、この例では、トランスポートパケットdの内容が、データエリア21とデータエリア22とで分断されて記録されている。
【0099】
図6(i)のトランスポートパケットdの前半部分(データエリア21側)は、後述する図23(f)の末尾側部分パケットに対応し、図6(i)のトランスポートパケットdの後半部分(データエリア22側)は、後述する図23(g)の先頭側部分パケットに対応している。
【0100】
さらに、図6(h)のデータエリア312には、図6(i)に示すように、タイムスタンプnとトランスポートパケットnとのペアおよびその他の同様なペアが記録されている。
【0101】
ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間331(図6(j))は、データエリア21および22に分断された2つのトランスポートパケットd全体に対するタイムスタンプd(図6(i))により指定される。
【0102】
トランスポートパケットをアプリケーションパケット(AP)と読み替え、アプリケーションパケット到着時間をAPATとした場合に、上記セル開始時間331は、セル開始APATとして表現できる。
【0103】
また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間332(図6(j))は、データエリア312のトランスポートパケットnに対するタイムスタンプn(図6(i))により指定される。このセル終了時間332は、セル終了APATとして表現できる。
【0104】
以上のセル開始時間(セル開始APAT)331およびセル終了時間(セル終了APAT)332は、図6(k)に示すように、ユーザ定義セル情報#12・295内部に記録できる。
【0105】
このユーザ定義セル情報#12・295は、図3(f)または図4下段に示すユーザ定義PGC情報テーブル234内に記録することができる。
【0106】
以上はユーザ定義セル情報(ユーザ定義PGCの情報)に関するセル開始/終了時間情報についてであるが、オリジナルセル情報(オリジナルセルの情報)に関するセル開始/終了時間情報については、次のような例示ができる。
【0107】
すなわち、図6(c)の先頭側タイムスタンプaにより図6(b)の該当セルの開始時間283を示すことができ、末尾側タイムスタンプzにより該当セルの終了時間284を示すことができる。
【0108】
図6(b)の該当セルの開始時間283は、セル開始APAT(ストリームセル開始APAT(SC_S_APAT)または消去開始APAT(ERA_S_APAT)も含む)に対応させることができる。
【0109】
また、図6(b)の該当セルの終了時間284は、セル終了APAT(ストリームセル終了APAT(SC_E_APAT)または消去終了APAT(ERA_E_APAT)も含む)に対応させることができる。
【0110】
以上のセル開始時間(セル開始APAT)283およびセル終了時間(セル終了APAT)284は、図6(a)に示すように、オリジナルセル情報#1・272内部に記録される。
【0111】
このオリジナルセル情報#1・272は、図3(f)または図4下段に示すオリジナルPGC情報233内に記録することができる。
【0112】
図7は、この発明の他の実施の形態に係る情報媒体(DVD録再ディスク)上の記録データ構造(とくに再生終了位置情報/レジューム情報、VMGI管理情報/記録時間情報等の構造)を説明する図である。
【0113】
図7(a)〜(f)のデータ構成は、図3(a)〜(f)と同じなので、その説明は省略する。
【0114】
図7(f)のビデオマネージャ(STR_VMGI)231は、図7(g)に示すように、再生終了位置情報(レジューム情報)6110、ビデオマネージャ管理情報(VMGI_MAT)6111その他を含んでいる。
【0115】
再生終了位置情報(レジューム情報)6110は、図7(h)に示すように、オリジナルPGC番号6210、オリジナルセル番号6220、再生終了位置時刻(レジューム時刻)情報6230等を含んでいる。
【0116】
また、ビデオマネージャ管理情報(VMGI_MAT)6111は、タイムゾーン(TM_ZONE)6240を含んでいる。
【0117】
記録済みのストリームブロック(またはオリジナルセル)の再生が終了した段階で、再生終了位置情報6110をレジューム情報として図7(e)の管理情報記録領域(STREAM.IFO)内のビデオマネージャ情報231中に記録することができる。
【0118】
なお、再生終了位置情報6110に含まれる時刻情報6230はタイムスタンプ(ATS)値で記録されているが、それに限らずPTS値(あるいはセル再生先頭位置からの通算フィールド数)を時刻情報6230として記録することもできる。
【0119】
タイムゾーン(TM_ZONE)6240は、図7(i)に示すように、記録時間(REC_TM)の情報を含む。
【0120】
記録時間(REC_TM)の情報は、REC_TMがユニバーサル・タイム・コオーディネート(UTC)によるものか特定のローカルタイムによるものかを識別するタイムゾーンタイプ(TZ_TY)と、UTCからのREC_TMのタイムオフセットの日時を分単位で記述したタイムゾーンオフセット(TZ_OFFSET)とを含んでいる。
【0121】
上記記録時間(REC_TM)は、図6(b)等で示したセル開始時間(SC_S_APAT)の形式あるいはそのセルの再生時刻(プレゼンテーションタイムPTM)の形式で記述してもよい。
【0122】
この記録時間(REC_TM)には2種類ある。第1はストリームオブジェクト記録時間(SOB_REC_TM)であり、第2はプレイリスト作成時間(PL_CREATE_TM)である。
【0123】
ここで、オリジナルセルに対応するストリームオブジェクト(SOB)が記録された時間が、SOB_REC_TMにより示される。
【0124】
また、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。このようなプレイリストが作成された時間が、PL_CREATE_TMにより示される。
【0125】
図8は、図1その他に示されたPESヘッダの内部構造を説明する図である。
【0126】
図8(a)のPESヘッダ601は、図8(b)に示すように、パケット開始コードプリフィックス602、ストリームID603、再生タイムスタンプ604等を含んでいる。このPESヘッダ601は、図1(f)、図5(d)、図6(d)等のPESヘッダに対応している。
【0127】
また、図8(d)のストリームPESヘッダは、図8(c)に示すように、パケット開始コードプリフィックス、ストリームID(プライベートストリーム2)、PESパケット長、サブストリームID等を含んでいる。このストリームPESヘッダは、後述する図22のストリームPESヘッダと同じもので、図8(a)のPESヘッダ601に対応する内容を持つ。
【0128】
図1(f)のPESヘッダが図8(a)に示すPESヘッダ601の内部構造を持つときは、MPEGの規格では、このPESヘッダのストリームID603(図8(b))が”10111110”のときに、このPESヘッダを持つパケットを、パディングパケット(後述する図12(g)参照)にすると定義されている。
【0129】
一方、ストリームID603(図8(c)のサブストリームID)が”00000010”のときは、そのPESパケットの付いたパケットは、ストリーム記録データを含むことになる。
【0130】
図1(c)のストリームブロック#1では、最後のトランスポートパケットg(図1(g))がセクタNo.0〜No.31(図1(e))内に存在している。しかし、ストリームブロック#2(図1(e)(g))では、ユーザ等により途中で録画が終了されると、最後のトランスポートパケット(図示せず)が最後のセクタより前のセクタに配置され、最後のセクタ(図示せず)内はストリームデータが記録されていない空き領域となることがある。この場合、最後のセクタには、上記パディングパケット(後述する図12(g)のパディングパケット40)が記録される。
【0131】
図9は、図1に示されたストリームブロックヘッダの内部構造を説明する図である。
【0132】
ストリームブロックヘッダ11は、図9(a)に示すように、サブストリームID、アプリケーションヘッダ、アプリケーションヘッダエクステンション、スタッフィングバイト等に対応した内容を持つ。
【0133】
1バイトのアプリケーションヘッダエクステンション(オプション)には、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが、記述される。
【0134】
AU_STARTが”1”にセットされると、関連するアプリケーションパケット(たとえば図29のAP)が、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。
【0135】
AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【0136】
COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0137】
ストリームブロックヘッダ11は、図9(b)に示すように、トランスポートパケット情報611、ストリームブロック情報612、セクタデータヘッダ情報613等を含んでいる。
【0138】
図9(b)のトランスポートパケット情報611は図9(c)のトランスポートパケット情報611と同じものを指す。
【0139】
ストリームブロック全体に関する情報が記録されている図9(b)のストリームブロック情報612は、図9(c)の記録時間622(情報記憶媒体201に記録した年月日と時刻情報)、トランスポートパケット属性623(トランスポートパケットに関する属性情報)、ストリームブロックサイズ624(該当するストリームブロックのデータサイズ(たとえばECCブロック数で記載できる))、ストリームブロック時間差625等に対応する。
【0140】
ここで、図5(b)を例にとれば、該当ストリームブロック内の時間範囲情報は、[ストリームブロック時間差]=[ストリームブロック#2内の最初にくるタイムスタンプ値]−[タイムスタンプaの値]として計算される。この[ストリームブロック時間差]が、ストリームブロック時間差625となる。
【0141】
また、図9(b)のセクタデータヘッダ情報613は、図9(c)のファーストアクセスポイント626およびトランスポートパケット接続フラグ627に対応する。このセクタデータヘッダ情報613は、後述する図10のセクタデータヘッダ12と同様な情報を含んでいる。
【0142】
図9(c)のトランスポートパケット情報611は、図9(d)に示すように、トランスポートパケットの数(アプリケーションパケットの数)631、トランスポートパケットマッピングテーブル632等を含んでいる。
【0143】
なお、図9(d)のアプリケーションパケットの数は、後述する図10(c)または図11のパケット数AP_Nsに対応している。
【0144】
図9(d)のトランスポートパケット(アプリケーションパケット)の数631は、図9(e)に示すように、Iピクチャマッピングテーブル641、B,Pピクチャマッピングテーブル642等を含むことができる。
【0145】
また、図9(d)のトランスポートパケットマッピングテーブル632は、ビデオパケットマッピングテーブル643、オーディオパケットマッピングテーブル644、プログラム固有情報マッピングテーブル645等を含むことができる。
【0146】
トランスポートパケットマッピングテーブル632内の各マッピングテーブル(図9(e))は、ビットマップ形式で構成されている。
【0147】
たとえば、1個のストリームブロック内にn個のトランスポートパケット(アプリケーションパケット)が記録されている場合には、図9(d)のトランスポートパケット数(アプリケーションパケット数)631の値は”n”となる。
【0148】
さらに、各マッピングテーブル643〜645は”nビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット(アプリケーションパケット)に対してそれぞれ1ビットずつが割り当てられている。
【0149】
図10は、図1に示されたセクタデータヘッダの内部構造を説明する図である。
【0150】
たとえば図1(f)のセクタデータヘッダ17は、データエリア22、23内のデータ配列情報を示すもので、図10(a)のセクタデータヘッダ(図10(d)のアプリケーションヘッダに対応)12に相当する。
【0151】
セクタデータヘッダ12は、図10(b)に示すように、ファーストアクセスポイント651およびトランスポートパケット接続フラグ652を含む内部構造を持っている。
【0152】
ところで、図10(d)に示すように、1セクタと同じく2048バイトのサイズを持つ1つのストリームパックは、パックヘッダおよびストリームPESヘッダで構成されている。そして、このストリームPESパケット内に、図10(a)のセクタデータヘッダ12あるいは図9(a)のストリームブロックヘッダ11の一部に対応した、アプリケーションパケットヘッダが含まれている。
【0153】
このアプリケーションパケットヘッダは、図10(c)に示すように、以下のものを含んでいる:
*アプリケーションパケットヘッダ形式のバージョン記載;
*該当ストリームパック内で開始するアプリケーションパケット(トランスポートパケット)の数AP_Ns;
*該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置FIRST_AP_OFFSET;
*ヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報EXTENSION_HEADER_IFO;
*該当ストリームを生成したサービスの識別子SERVICE_ID。
【0154】
上記図10(d)のアプリケーションパケットに含まれるFIRST_AP_OFFSETは、図10(a)のセクタデータヘッダ12に含まれるファーストアクセスポイント651に対応する。
【0155】
図1(g)に示すように、トランスポートパケットdは2個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ652が”1”に設定される。
【0156】
また図1(g)の例では、次のセクタへ跨ったトランスポートパケットdの次にくるタイムスタンプ先頭位置のデータエリア22内のアドレスが、ファーストアクセスポイント651内に記録(ビット単位の表現)されている。
【0157】
図1(e)に示すセクタNo.1(またはその対応ストリームパック)のファーストアクセスポイント値を、セクタNo.1のデータエリア22(図1(f))のサイズよりも大きな値に設定することができる。そうすることにより、セクタNo.1内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。
【0158】
この発明の一実施の形態では、ファーストアクセスポイント651の値としてデータエリア21、22、23のサイズよりも大きな値を指定可能にすることで、セクタサイズ(あるいはストリームパックサイズ=2048バイト)よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。
【0159】
たとえば、図1のデータ構造において、1個のパケットがセクタNo.0からセクタNo.2まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタNo.0のデータエリア21内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタNo.2のデータエリア内のTビット目に配置されている場合を考える。
【0160】
この場合、セクタNo.0のファーストアクセスポイントの値は”0”、セクタNo.1のファーストアクセスポイントの値は”セクタNo.1のデータエリア22サイズ+T”、セクタNo.2のファーストアクセスポイントの値は”T”となる。
【0161】
図11は、この発明の一実施の形態におけるタイムマップ情報252の他例を説明する図である。
【0162】
このタイムマップ情報252は、図3(h)(i)のタイムマップ情報252とは別の例であり、各ストリームブロック(最初のストリームブロック、2番目のストリームブロック、…)毎に、ストリームブロックサイズとストリームブロック時間差とパケット数(AP_Ns)とを記述したテーブル情報である。
【0163】
図11のタイムマップ情報252を用い、所定の画面(ピクチャ)にアクセスするため(STB側から)通算トランスポートパケット数(または通算アプリケーションパケット数AP_Ns)が指定されたとする。すると、(ディスク装置側は)図11の最初のストリームブロックから順次トランスポートパケット数(AP_Ns)を加算して行き、指定された値に達した時点でのストリームブロックへアクセスする。
【0164】
図12は、ストリームブロック(SOBU)を構成するセクタの内部構成(アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック)の一例を説明する図である。
【0165】
図12(d)のストリームオブジェクト(SOB)#A・298は、図12(c)(e)に示すように、複数のストリームブロック#1、#2、…で構成されている。
【0166】
各ストリームブロック#1、#2、…は全て、2ECCブロックサイズ(=32セクタ=64kバイト)のストリームオブジェクトユニット(SOBU)で構成される。
【0167】
このようにすると、たとえばストリームブロック(SOBU)#2を削除しても、ストリームブロック(SOBU)#1のECCブロックはこの削除に影響されない。
【0168】
SOB#A・298の先頭ストリームブロック(SOBU)#1は、図12(b)に示すように、セクタNo.0〜セクタNo.31(32セクタ/64kバイト)で構成されている。
【0169】
ストリームブロック(SOBU)#1の各セクタは、同様なデータ構造を持っている。、たとえばセクタNo.0についていうと、図12(a)に示すようになっている。
【0170】
すなわち、セクタNo.0は2048バイト(2kバイト)のストリームパックにより構成される。このストリームパックは、14バイトのパックヘッダと、2034バイトのストリームPESパケットとで構成される。
【0171】
ストリームPESパケットは、6バイトのPESヘッダと、1バイトのサブストリームIDと、2027バイトのストリームデータエリアとで構成される。
【0172】
ストリームデータエリアは、9バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、アプリケーションパケットエリアとで構成される。
【0173】
アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ(ATS)を先頭に持つアプリケーションパケット群で構成される。
【0174】
たとえば188バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、10個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。
【0175】
ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ(たとえば2048バイト)を持つものとして扱うことができる。
【0176】
図12(a)のスタッフィングバイトは、ストリームパックを常に所定長(2048バイト)に保つために利用できる。
【0177】
図12(a)のパックヘッダは、図示しないが、パック開始コードの情報、SCRベースの情報、SCRエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。
【0178】
SCRベースは32ビットで構成され、その32ビット目はゼロとされる。また、プログラム最大レートとしては、10.08Mbpsが採用される。
【0179】
図12(a)のPESヘッダおよびサブストリームIDは、図8(c)に示したような内容を持っている。
【0180】
図12(a)のアプリケーションヘッダは、図10(c)に示したように、バージョン情報、アプリケーションパケット数AP_Ns、先頭アプリケーションパケットのタイムスタンプ位置FIRST_AP_OFFSET、エクステンションヘッダ情報EXTENSION_HEADER_IFO、サービスID等を含んでいる。
【0181】
ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。
【0182】
アプリケーションヘッダのAP_Nsは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にATSの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。
【0183】
FIRST_AP_OFFSETには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、FIRST_AP_OFFSETには「0」が記述される。
【0184】
EXTENSION_HEADER_INFOには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび/またはスタッフィングバイトが存在するか否かが、記述される。
【0185】
EXTENSION_HEADER_INFOの内容が00bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。
【0186】
EXTENSION_HEADER_INFOの内容が10bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。
【0187】
EXTENSION_HEADER_INFOの内容が11bの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。
【0188】
EXTENSION_HEADER_INFOの内容が01bとなることは禁止されている。
【0189】
アプリケーションパケットエリアの前のスタッフィングバイト(オプション)は、「EXTENSION_HEADER_INFO=11b」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。
【0190】
SERVICE_IDには、ストリームを生成するサービスのIDが記述される。このサービスが未知のものであれば、SERVICE_IDに0x0000が記述される。
【0191】
図12(a)のアプリケーションパケットエリアは、後述する図22の下段に示したと同様に構成できる(図22のパケットを図12ではアプリケーションパケットに読み替える)。
【0192】
すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプATSとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。
【0193】
別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。
【0194】
各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ(ATS)は32ビット(4バイト)で構成される。このATSは、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0195】
図12(a)において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。
【0196】
それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを(前述したEXTENSION_HEADER_INFOにおいて)記述できるように定義されいる。
【0197】
ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプATSの先頭バイトは、ストリームオブジェクトSOBの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。
【0198】
一方、SOB内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割(スプリット)されてもよい。
【0199】
後述する図22あるいは図23(f)(g)に示した部分アプリケーションパケットは、この分割(スプリット)により生じたアプリケーションパケットを示している。
【0200】
ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。
【0201】
こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。
【0202】
すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。
【0203】
アプリケーションヘッダエクステンション(オプション)はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する1バイト長の1エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。
【0204】
なお、1バイトのアプリケーションヘッダエクステンション(オプション)には、1ビットのAU_STARTと、1ビットのAU_ENDと、2ビットのCOPYRIGHTとが、記述される。
【0205】
AU_STARTが”1”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント(ランダムアクセスユニットの開始)を含むことが示される。
【0206】
AU_ENDが”1”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。
【0207】
COPYRIGHTには、関連アプリケーションパケットの著作権の状態が記述される。
【0208】
図12(a)のパケット構造は、SOB#A・298の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。
【0209】
たとえば、SOB#A・298の末尾が図12(f)のセクタNo.63であり、このセクタが図12(g)に示すようにパディングパケット40で構成されるときは、そのパディングエリア38(図12(h))の内容が、図12(a)と違ったものになる。
【0210】
すなわち、図12(i)に示すように、パディングパケット40としてのスタッフィングパケットは、14バイトのパックヘッダと、6バイトのPESヘッダと、1バイトのサブストリームIDと、9バイトのアプリケーションヘッダと、2018バイトのアプリケーションパケットエリアとで構成される。
【0211】
スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、4バイトのアプリケーションタイムスタンプATSおよび2014バイト分のゼロバイトデータ(実質的な記録内容を持たないデータ)で構成される。
【0212】
一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、2018バイト分のゼロバイトデータ(ATSなし)で構成される。
【0213】
ところで、ビットレートが極めて低い記録がなされる場合、タイムマップ情報(図3(h)の252;あるいは後述する図15のSOBI内MAPL)の回復(再生)を確実にするために、スタッフィングが必要になる。図12(i)のスタッフィングパケットは、そのための概念的な単位として定義されている。
【0214】
このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のSOBUが少なくとも1つのATS値を含むようにすることで、達成される。
【0215】
スタッフィングパケットには、以下の条件が付く:
*1または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する;
*1または複数のスタッフィングパケットは、1つの4バイトATSと、該当SOBUの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ(ATSの後に続く)とで構成される。いま、SOBU1個あたりのセクタ数をSOBU_SIZとしたときに、0≦n≦SOBU_SIZー1とすれば、スタッフィングパケットの全長は、「4+2014+n×2018」バイトとなる。
【0216】
スタッフィングパケットのATSは、次のように設定される:
*少なくとも1個のパックが実際のアプリケーションパケットデータを含んでいるSOBU内では、スタッフィングパケットのATSは、スタッフィングパケットに先行するアプリケーションパケットのATSに設定される;
*実際のアプリケーションパケットデータを含まないSOBU内では、スタッフィングパケットのATSはタイムマップ情報等の内容に応じて決定される。
【0217】
スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される:
*パックヘッダの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)とする。
【0218】
図13は、ストリーマの管理情報(図2のSTREAM.IFOまたはSR_MANGR.IFOに対応)の内部データ構造を説明する図である。
【0219】
図2あるいは図3(e)に示した管理情報(ナビゲーションデータ)であるSTREAM.IFO(SR_MANGR.IFO)105は、図13に示すように、ストリーマ情報STRIを含んでいる。
【0220】
このストリーマ情報STRIは、図3(f)あるいは図13に示すように、ストリーマビデオマネージャ情報STR_VMGIと、ストリームファイル情報テーブルSFITと、オリジナルPGC情報ORG_PGCI(より一般的に表現すればPGC情報PGCI#i)と、ユーザ定義PGC情報テーブルUD_PGCITと、テキストデータマネージャTXTDT_MGと、アプリケーションプライベートデータマネージャAPDT_MGとで、構成されている。
【0221】
ストリーマビデオマネージャ情報STR_VMGIは、図13に示すように、STRI、STR_VMGIに関する管理情報等が記述されたビデオマネージャ情報管理情報VTSI_MATと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル(PL_SRPT)とを含んでいる。
【0222】
ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、(プログラムの内容に対して)任意の再生シーケンスをユーザが定義できる。
【0223】
ストリームファイル情報テーブルSFITは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルSFITの詳細については、図15を参照して後述する。
【0224】
オリジナルPGC情報ORG_PGCIは、オリジナルPGC(ORG_PGC)に関する情報を記述した部分である。ORG_PGCはプログラムセットを記述したナビゲーションデータを示す。ORG_PGCはプログラムの連なり(チェーン)であり、図2または後述する図18の「.SRO」ファイル(図2ではSR_TRANS.SRO106)内に記録されたストリームデータを含む。
【0225】
ここで、プログラムセットとは、情報記憶媒体201の記録内容全体(全てのプログラム)を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルPGC(ORG_PGC)と呼ばれるデータ構造に対応している。
【0226】
また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、1以上のオリジナルセルにより構成される。プログラムはオリジナルPGC内でのみ定義されるものである。
【0227】
さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義PGC内のセルは「ユーザ定義セル」と呼ばれる。
【0228】
プログラムセット内の各々のプログラムは、少なくとも1個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも1個のユーザ定義セルで構成される。
【0229】
一方、ストリーマでは、ストリームセル(SC)だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。
【0230】
なお、プログラムチェーン(PGC)とは、上位概念的な単位を示す。オリジナルPGCでは、PGCはプログラムセットに対応したプログラムの連なり(チェーン)を指す。また、ユーザ定義PGCでは、PGCはプレイリストに対応するプログラムの一部の連なり(チェーン)を指す。
【0231】
また、プログラムの一部のチェーンを指すユーザ定義PGCは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルPGCに属するストリームデータを参照するようになっている。
【0232】
図13のユーザ定義PGC情報テーブルUD_PGCITは、ユーザ定義PGC情報テーブル情報UD_PGCITIと、1以上のユーザ定義PGCサーチポインタUD_PGC_SRP#nと、1以上のユーザ定義PGC情報UD_PGCI#nとを含むことができる。
【0233】
ユーザ定義PGC情報テーブル情報UD_PGCITIは、図示しないが、ユーザ定義PGCサーチポインタUD_PGC_SRPの数を示すUD_PGC_SRP_Nsと、ユーザ定義PGC情報テーブルUD_PGCITの終了アドレスを示すUD_PGCIT_EAとを含む。
【0234】
UD_PGC_SRP_Nsが示すUD_PGC_SRPの数は、ユーザ定義PGC情報(UD_PGCI)の数と同じであり、ユーザ定義PGC(UD_PGC)の数とも同じである。この数は、最大「99」まで許されている。
【0235】
UD_PGCIT_EAは、該当UD_PGCITの終了アドレスを、そのUD_PGCITの先頭バイトからの相対バイト数(F_RBN)で記述したものである。
【0236】
ここで、F_RBNとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。
【0237】
オリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したPGCI#iについては、図14を参照して後述する。
【0238】
図13のテキストデータマネージャTXTDT_MGは、補足的なテキスト情報である。このTXTDT_MGは、図14のプライマリテキスト情報PRM_TXTIとともに、プレイリストおよびプログラム内に格納できる。
【0239】
図13のアプリケーションプライベートデータマネージャAPDT_Mは、図示しないが、アプリケーションプライベートデータマネージャ一般情報APDT_GIと、1以上のAPDTサーチポインタAPDT_SRP#nと、1以上のAPDTエリアAPADTA#nとを含むことができる。
【0240】
ここで、アプリケーションプライベートデータAPDTとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報(リアルタイムストリームデータに加えさらに望まれる情報)を格納できるような概念上のエリアである。
【0241】
図14は、PGC情報(図3のORG_PGCI/UD_PGCITまたは図13のPGCI#i)の内部データ構造を説明する図である。
【0242】
図14のPGC情報PGCI#iは、図13のオリジナルPGC情報ORG_PGCIあるいはユーザ定義PGC情報テーブルUD_PGCIT内のユーザ定義PGC情報UD_PGCIを一般的に表現したものである。
【0243】
図14に示すように、PGC情報PGCI#iは、PGC一般情報PGC_GIと、1以上のプログラム情報PGI#mと、1以上のストリームセル情報サーチポインタSCI_SRP#nと、1以上のストリームセル情報SCI#nとで構成されている。
【0244】
PGC一般情報PGC_GIは、プログラムの数PG_Nsと、ストリームセル情報サーチポインタSCI_SRPの数SCI_SRP_Nsとを含んでいる。
【0245】
各プログラム情報PGI(たとえばPGI#1)は、プログラムタイプPG_TYと、該当プログラム内のセルの数C_Nsと、該当プログラムのプライマリテキスト情報PRM_TXTIと、アイテムテキストのサーチポインタ番号IT_TXT_SRPNとを含んでいる。
【0246】
ここで、プログラムタイプPG_TYは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。
【0247】
このプロテクトフラグが「0b」のときは該当プログラムは保護されておらず、「1b」のときは保護された状態にある。
【0248】
セルの数C_Nsは、該当プログラム内のセルの数を示す。PGCの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに(暗黙のうちに)付随している。
【0249】
たとえば、PGC内でプログラム#1がC_Ns=1を持ち、プログラム#2がC_Ns=2を持つとすれば、そのPGCの最初のストリームセル情報SCIはプログラム#1に付随するものとなり、第2、第3のSCIはプログラム#2に付随するものとなる。
【0250】
プライマリテキスト情報PRM_TXTIは、情報記憶媒体(DVD−RAMディスク)201を世界中で利用可能とするために、1つの共通キャラクタセット(ISO/IEC646:1983(ASCIIコード))を持ったテキスト情報を記述したものである。
【0251】
アイテムテキストのサーチポインタ番号IT_TXT_SRPNは、アイテムテキスト(該当プログラムに対応するテキストデータ)IT_TXTに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、IT_TXT_SRPNは「0000h」にセットされる。
【0252】
各ストリームセル情報サーチポインタSCI_SRP(たとえばSCI_SRP#1)は、対応ストリームセル情報SCIの開始アドレスを示すSCI_SAを含んでいる。このSCI_SAは、PGCIの先頭バイトからの相対バイト数(F_RBN)で記述される。
【0253】
各ストリームセル情報SCI(たとえばSCI#1)は、ストリームセル一般情報SC_GIと、1以上のストリームセルエントリポイント情報SC_EPI#nとで構成される。
【0254】
ストリームセル一般情報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)とを含んでいる。
【0255】
セルタイプC_TYは、該当ストリームセルの形式およびその仮消去状態を記述するものである。
【0256】
すなわち、セルの形式C_TY1=「010b」は全てのストリームセルの形式に記述される(このC_TY1=「010b」によりストリームセルとそれ以外のセルの区別ができる)。
【0257】
一方、フラグTEが「00b」であれば該当セルは通常の状態にあることが示され、フラグTEが「01b」あるいは「10b」であれば該当セルは仮消去の状態にあることが示される。
【0258】
フラグTE=「01b」は、該当セル(仮消去状態にあるセル)が、SOBU内で開始する最初のアプリケーションパケットの後から開始し、同じSOBU内の最終アプリケーションパケットの前で終了する場合を示す。
【0259】
また、フラグTE=「10b」は、該当セル(仮消去状態にあるセル)が、少なくとも1つのSOBU境界(先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのSOBU内で開始する)を含む場合を示す。
【0260】
なお、プログラムのプロテクトフラグと、そのプログラム内のセルのTEフラグとは、同時に設定できないようになっている。それゆえ、
(a)プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず;
(b)仮消去状態にあるセルを1以上含むプログラムはプロテクト状態に設定できない。
【0261】
ストリームセルのエントリポイント情報の数SC_EPI_Nsは、該当ストリームセル情報SCI内に含まれるストリームセルエントリポイント情報の数を記述したものである。
【0262】
図14の各ストリームセルエントリポイント情報SC_EPI(たとえばSC_EPI#1)は、2種類(タイプAとタイプB)存在する。
【0263】
タイプAのSC_EPIは、エントリポイントタイプEP_TYとエントリポイントのアプリケーションパケット到着時間EP_APATとを含む。タイプAは、エントリポイントタイプEP_TY1=「00b」により示される。
【0264】
タイプBのSC_EPIは、タイプAのEP_TYおよびEP_APATの他に、プライマリテキスト情報PRM_TXTIを含む。タイプBは、エントリポイントタイプEP_TY1=「01b」により示される。
【0265】
任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間(APAT)により特定できる。このAPATにより、どこからデータ出力が開始されるのかを特定できる。
【0266】
ストリームオブジェクト番号SOB_Nは、該当セルが参照するSOBの番号を記述したものである。
【0267】
ストリームセル開始APAT(SC_S_APAT)は、該当セルの開始APATを記述したものである。
【0268】
ストリームセル終了APAT(SC_E_APAT)は、該当セルの終了APATを記述したものである。
【0269】
消去開始APAT(ERA_S_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、この仮消去セルに先頭が含まれる最初のSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0270】
消去終了APAT(ERA_E_APAT)は、少なくとも1個のSOBU境界を含む仮消去セル(そのC_TYのTEフィールドが「10b」)において、仮消去セルのすぐ後に続くアプリケーションパケットを含むSOBU内で開始する最初のアプリケーションパケットの到着時間(APAT)を記述したものである。
【0271】
図15は、ストリームファイル情報テーブル(SFIT)の内部データ構造を説明する図である。
【0272】
図15に示すように、ストリームファイル情報テーブルSFITは、ストリームファイル情報テーブル情報SFITIと、1以上のストリームオブジェクトストリーム情報SOB_STI#nと、ストリームファイル情報SFIとで構成される。
【0273】
ストリームファイル情報テーブル情報SFITIは、情報記憶媒体(DVD−RAMディスク)201上のストリームファイル情報の数SFI_Nsと、SFITIに続くストリームオブジェクトストリーム情報の数SOB_STI_Nsと、SFITの終了アドレスSFIT_EAと、SFIの開始アドレスSFI_SAとで構成される。
【0274】
SFIT_EAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFITの終了アドレスを記述したものである。
【0275】
また、SFI_SAは、SFITの先頭バイトからの相対バイト数(F_RBN)でSFIの開始アドレスを記述したものである。
【0276】
各ストリームオブジェクトストリーム情報SOB_STIは、3種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、SOB_STIは、ストリームオブジェクト情報(SOBI)のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト(SOB)が同じSOB_STIを共有する(つまり同じSOB_STIをポイントする)ことが認められている。したがって、通常は、SOBの数よりもSOB_STIの数の方が少なくなる。
【0277】
図15の各ストリームオブジェクトストリーム情報SOB_STI(たとえばSOB_STI#1)は、アプリケーションパケットサイズAP_SIZと、サービスIDの数SERV_ID_Nsと、サービスID(SERV_IDs)と、アプリケーションパケットデバイスユニークID(AP_DEV_UID)とを含んでいる。
【0278】
AP_SIZは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。
【0279】
なお、DVDストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため、各々の中断のない記録中において、アプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト(現SOB)はそこで終了され、新たなストリームオブジェクト(新SOB)が、新たなAP_SIZを伴って開始される。その際、現SOBおよび新SOBの双方は、オリジナルPGC情報(ORG_PGCI)内の同じプログラムに属するものとなる。
【0280】
SERV_ID_Nsは、後続パラメータに含まれるサービスIDの数を記述したものである。
【0281】
SERV_IDsは、サービスIDのリストを任意の順序で記述したものである。
【0282】
AP_DEV_UIDは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスIDを記述したものである。
【0283】
ストリームファイル情報SFIは、図15に示すように、ストリームファイル一般情報SF_GIと、1以上のストリームオブジェクト情報(SOB情報)サーチポインタ(SOBI_SRP)#nと、1以上のSOB情報(SOBI)#nとで構成されている。
【0284】
ストリームファイル一般情報SF_GIは、SOBIの数SOBI_Nsと、SOBU1個あたりのセクタ数SOBU_SIZと、タイムマップ情報の一種であるMTU_SHFTとを含んでいる。
【0285】
ここで、SOBU_SIZは、SOBUのサイズをセクタ数で記述したもので、このサイズは32(32セクタ=64kバイト)で一定となっている。このことは、各タイムマップ情報(MAPL)内において、最初のエントリが、SOBの最初の32セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、2番目のエントリは、次の32セクタに含まれるアプリケーションパケットに関係する。3番目以降のエントリについても以下同様である。
【0286】
各SOB情報サーチポインタ(たとえばSOBI_SRP#1)は、SOBIの開始アドレスSOBI_SAを含んでいる。このSOBI_SAは、ストリームファイル情報SFIの先頭バイトから相対バイト数(F_RBN)でもって関連SOBIの開始アドレスを記述したものである。
【0287】
各SOB情報(たとえばSOBI#1)は、ストリームオブジェクト一般情報SOB_GIと、タイムマップ情報MAPLと、アクセスユニットデータAUD(オプション)とで構成される。
【0288】
ストリームオブジェクト一般情報SOB_GIは、ストリームオブジェクトのタイプSOB_TYと、ストリームオブジェクト記録時間SOB_REC_TMと、ストリームオブジェクトのストリーム情報番号SOB_STI_Nと、アクセスユニットデータフラグAUD_FLAGSと、ストリームオブジェクトの開始アプリケーションパケット到着時間SOB_S_APATと、ストリームオブジェクトの終了アプリケーションパケット到着時間SOB_E_APATと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットSOB_S_SOBUと、タイムマップ情報のエントリ数MAPL_ENT_Nsとを含んでいる。
【0289】
ストリームオブジェクトのタイプSOB_TYは、仮消去状態(TE状態)を示すビットおよび/またはコピー世代管理システムのビットを記述できる部分である。
【0290】
ストリームオブジェクト記録時間SOB_REC_TMは、関連ストリームオブジェクト(SOB)の記録時間を記述したものである。
【0291】
ストリームオブジェクトのストリーム情報番号SOB_STI_Nは、該当ストリームオブジェクトに対して有効なSOB_STIのインデックスを記述したものである。
【0292】
アクセスユニットデータフラグAUD_FLAGSは、該当ストリームオブジェクトに対してアクセスユニットデータ(AUD)が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。
【0293】
アクセスユニットデータ(AUD)が存在する場合は、AUD_FLAGSにより、AUDの幾つかの特性が記述される。
【0294】
アクセスユニットデータ(AUD)自体は、図15に示すように、アクセスユニット一般情報AU_GIと、アクセスユニットエンドマップAUEMと、再生タイムスタンプリストPTSLとで構成される。
【0295】
アクセスユニット一般情報AU_GIは、該当SOBに対して記述されたアクセスユニットの数を示すAU_Nsと、該当SOBに属するSOBUのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップAUSMとを含んでいる。
【0296】
アクセスユニットエンドマップAUEMは、(もし存在するときは)AUSMと同じ長さのビットアレイであり、該当SOBのアクセスユニットに付随するビットストリームセグメントの終端をどのSOBUが含むのかを示す。
【0297】
再生タイムスタンプリストPTSLは、該当SOBに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる1つのPTSLエレメントは、対応アクセスユニットの再生タイムスタンプ(PTS)の値を含む。
【0298】
なお、アクセスユニット(AU)とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、MPEGのIピクチャに対応する部分となる。
【0299】
ここで再びSOB_GIの内容説明に戻る。
【0300】
AUD_FLAGSは、フラグRTAU_FLGと、フラグAUD_FLGと、フラグAUEM_FLGと、フラグPTSL_FLGとを含んでいる。
【0301】
フラグRTAU_FLGが0bのときは、該当SOBのリアルタイムデータ内にアクセスユニットフラグはないことが示される。
【0302】
フラグRTAU_FLGが1bのときは、図9(a)または図12(a)のアプリケーションヘッダエクステンション内に記述されるAUフラグ(AU_START、AU_END)が、該当SOBのリアルタイムデータ内に存在可能なことが示される。この状態は、下記AUD_FLGが0bの場合にも許される。
【0303】
フラグAUD_FLGが0bのときは、該当SOBに対してアクセスユニットデータ(AUD)がないことが示される。
【0304】
フラグAUD_FLGが1bのときは、該当SOBに対してアクセスユニットデータ(AUD)が存在し得ることが示される。
【0305】
フラグAUEM_FLGが0bのときは、該当SOBにAUEMが存在しないことが示される。
【0306】
フラグAUEM_FLGが1bのときは、該当SOBにAUEMが存在することが示される。
【0307】
フラグPTSL_FLGが0bのときは、該当SOBにPTSLが存在しないことが示される。
【0308】
フラグPTSL_FLGが1bのときは、該当SOBにPTSLが存在することが示される。
【0309】
SOB_S_APATは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、SOB_S_APATにより、該当SOBに属する最初のアプリケーションパケット到着時間が示される。
【0310】
このパケット到着時間(PAT)は、2つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は90kHzユニット値と呼ばれる部分であり、拡張部分は27MHzで測った細かい値(less significant value)を示す。
【0311】
SOB_E_APATは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、SOB_E_APATにより、該当SOBに属する最後のアプリケーションパケット到着時間が示される。
【0312】
SOB_S_SOBUは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、SOB_S_SOBUにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むSOBUが示される。
【0313】
MAPL_ENT_Nsは、SOBI_GIの後に続くタイムマップ情報(MAPL)のエントリ数を記述したものである。
【0314】
タイムマップ情報MAPLは、図3(h)のタイムマップ情報252に対応する内容を持つ。
【0315】
図13および図15の内容の関連性の1つについて纏めると、次のようになる:
管理情報105に含まれるストリーマ情報STRIは、ストリームデータの内容の一部を構成するストリームオブジェクトSOBを管理するストリームファイル情報テーブルSFITを含む。このSFITは、SOBを管理するストリームオブジェクト情報SOBIを含む。このSOBIが、管理情報(アクセスユニット開始マップAUSM)を含むアクセスユニット一般情報AU_GIと、管理情報(PTSL)とを含む。
【0316】
ここで、管理情報(ATSまたはAUSM)がストリームデータの転送時に使用される情報を含み、管理情報(PTSまたはSC_S_APAT)が前記ストリームデータを表示するときに使用される情報を含む。
【0317】
図16は、アクセスユニット開始マップ(AUSM;図15参照)とストリームオブジェクトユニット(SOBU;図1、図4〜図6、図12参照)との対応関係を例示する図である。
【0318】
図示するように、AUSMのうちビット”1”の部分が、対応SOBUにアクセスユニット(AU)が含まれることを示している。
【0319】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)としてみる。すると、アクセスユニットAUの位置は次のようになる。
【0320】
(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内に配置されたものである。
【0321】
(2)AUは、このAU開始後に最初に現れるAU_ENDマークで終了し、かつ、AUは、(もしAUEMが存在するなら)割り当てられたAUEMエレメントにより示される最後のSOBUで終了する。
【0322】
なお、いずれのアクセスユニットデータにおいても、SOBの各SOBU1個当たりに、2以上のアクセス可能なアクセスユニットを記述することはできない。
【0323】
図17は、アクセスユニット開始マップ(AUSM;図15参照)およびアクセスユニット終了マップ(AUEM;図15参照)とストリームオブジェクトユニット(SOBU;図2、図4、図11参照)との対応関係を例示する図である。
【0324】
AUEMは、(もし存在するなら)AUSMと同じ長さのビットアレイである。AUEMのビットは、該当SOBのアクセスユニットに付随するビットストリームセグメントの末尾がどのSOBUに含まれるのかを、示している。
【0325】
AUEM内にセットされたビットの数はAUSM内にセットされたビットの数に一致する。すなわち、AUSM内の各設定ビットは、AUEM内に対応してセットされたビットを持つ。
【0326】
いま、AUSM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUSM_pos(i)とし、AUEM内でビットがセットされたi番目(1≦i≦AU_Ns)のビット位置をAUEM_pos(i)としてみる。この場合、以下の関係がある。
【0327】
(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)。
【0328】
図18は、オリジナルPGCあるいはユーザ定義PGCで指定されるセルと、これらのセルに対応するSOBUとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。
【0329】
ユーザ定義PGCは自身のSOBを含まないが、オリジナルPGC内のSOBを参照する。それゆえ、ユーザ定義PGCはPGC情報を用いることのみで記述できる。このことは、SOBデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。
【0330】
ユーザ定義PGCはまた、プログラムを含まず、オリジナルPGC内のプログラムの一部に対応したセルの連なり(チェーン)で構成される。
【0331】
このようなユーザ定義PGCの一例が、図18に示されている。この例は、PGC内のセルがオリジナルPGC内のSOBを参照するようにユーザ定義PGC#nが作成されている場合を示す。
【0332】
図18において、PGC#nは4つのセル#1〜#4を持っている。そのうち2つはSOB#1を参照し、残りの2つがSOB#2を参照している。
【0333】
ユーザ定義PGC内のセルからオリジナルPGCへ(SOBIのタイムマップ情報へ)の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義PGC内のセル再生順序は、オリジナルPGCにおける再生順序と全く異なってもよい。
【0334】
任意のSOBおよびそのSOBUの再生は、図18の開始APAT(S_APAT)および終了APAT(E_APAT)により特定される。
【0335】
SOBあるいはSOBUのS_APATは、該当SOBのストリームパックのペイロード(図1(h)、図22、図23参照)内に記録されたタイムスタンプに関係して定義される。
【0336】
SOBの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間(APAT)である。
【0337】
SOBの先頭アプリケーションパケットのAPATはSOB_S_APATとして記憶される。全てのAPATの4最下位バイト(4 least significant bytes)は、「〜.SRO」ファイル内の対応アプリケーションパケット用に予め固定されている。
【0338】
SOBあるいはSOBUのデータを再生するために、ストリーマ内部のリファレンスクロックはSCR値にセットされ、その後クロックが自動的にカウントされる。このSCR値は、再生が始まる最初のストリームパック内(パックヘッダ内)に記述されている。このクロックに基づいて、SOBあるいはSOBUからの全ての後続アプリケーションパケットの再生・出力が、実行される。
【0339】
任意のストリームセル(SC)が、そのSCがポイントするSOBのSOB_S_APATとSOB_E_APATとの間の任意の値を持つストリームセル開始APAT(SC_S_APAT)を規定しているときは、所望のAPATを伴うアプリケーションパケットを含んだSOBUを見つけるためのアドレスが必要となる。
【0340】
SOBU1個あたりのストリームパックの数は一定であるが、各SOBUにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各SOBは、該当SOBのSOBUの到着時間間隔が記述されたタイムマップ情報(MAPL)を持つ。つまり、タイムマップ情報(MAPL)により実現されるアドレス方式は、任意のAPATをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるSOBUをポイントする。
【0341】
図19は、この発明の一実施の形態に係るストリームデータ記録再生システム(光ディスク装置/ストリーマ、STB装置)の構成を説明する図である。この実施の形態では、情報記憶媒体201として、DVD−RAMディスクのような記録/再生可能光ディスクを想定している。
【0342】
以下、図19を用いて、この発明の一実施の形態に係るストリームデータ記録再生装置の内部構造を説明する。
【0343】
このストリームデータ記録再生装置は、光ディスク装置415、STB装置416およびその周辺機器から構成される。
【0344】
周辺機器としては、ビデオミキシング部405、フレームメモリ部406、外部スピーカ433、パーソナルコンピュータ(PC)435、モニタTV437、D/Aコンバータ432、436、I/F部431、434等がある。
【0345】
光ディスク装置415は、ディスクドライブを含む記録再生部409と、記録再生部409へのストリームデータ(あるいは記録再生部409からのストリームデータ)を処理するデータプロセサ部(以下D−PRO部と略記する)410と、D−PRO部410からオーバーフローしてきたストリームデータを一時記憶する一時記憶部411と、記録再生部409およびD−PRO部410の動作を制御する光ディスク装置制御部412とを備えている。
【0346】
光ディスク装置415はさらに、STB装置416からIEEE1394等を介して送られてきたストリームデータを受ける(あるいはIEEE1394等を介してSTB装置416へストリームデータを送る)データ転送インターフェース部414と、データ転送インターフェース部414で受けたストリームデータを情報記憶媒体(RAMディスク)201に記録する信号形式に変換する(あるいは媒体201から再生されたストリームデータをIEEE1394等の信号形式に変換する)フォーマッタ/デフォーマッタ部413とを備えている。
【0347】
具体的には、データ転送インターフェース部414のIEEE1394受信側は、基準クロック発生器(システムタイムカウンタSTC)440のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。
【0348】
上記時間情報に基づいて、ストリームデータをストリームブロック毎(あるいはSOBU毎)に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはPGCの切り分け情報を作成する。
【0349】
フォーマッタ/デフォーマッタ部413は、STB装置416から送られてきたストリームデータをストリームパックの列(図12(a)、図23(h)等を参照)に変換し、変換されたストリームパック列をD−PRO部410へ入力する。入力されたストリームパックはセクタと同じ2048バイトの一定サイズを持っている。D−PRO部410は、入力されたストリームパックを16セクタ毎にまとめてECCブロックにして、記録再生部409へ送る。
【0350】
ここで、記録再生部409において媒体201への記録準備ができていない場合には、D−PRO部410は、記録データを一時記憶部411に転送して一時保存し、記録再生部409においてデータ記録準備ができるまで待つ。
【0351】
記録再生部409において記録準備ができた段階で、D−PRO部410は一時記憶部411に保存されたデータを記録再生部409に転送する。これにより、媒体201への記録が開始される。一時記憶部411に保存されたデータの記録が済むと、その続きのデータはフォーマッタ/デフォーマッタ部413からD−PRO部410へシームレスに転送されるようになっている。
【0352】
ここで、一時記憶部411は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。
【0353】
なお、フォーマッタ/デフォーマッタ部413を介して記録ビットストリームに付されるタイムスタンプ情報は、基準クロック発生器(STC)440から得ることができる。
【0354】
また、フォーマッタ/デフォーマッタ部413を介して再生ビットストリームから取り出されたタイムスタンプ情報(SCR)は、STC440にセットすることができる。
【0355】
情報記憶媒体201に記録されたストリームデータ内のパックヘッダには、基準クロック(システムクロックリファレンスSCR)が記録されている。この媒体201に記録されたストリームデータ(SOBまたはSOBU)を再生する場合において、基準クロック発生器(STC)440は、媒体201から再生された基準クロック(SCR)に適合される(SCRの値がSTC440にセットされる)。
【0356】
つまり、SOBあるいはSOBUのデータを再生するために、ストリーマ(光ディスク装置415)内の基準クロック(STC440)を、再生が開始される最初のストリームパック内に記述されたシステムクロックリファレンスSCRに合わせる。その後は、STC440のカウントアップは自動的に行われる。
【0357】
STB部416は、衛星アンテナ421で受信したデジタル放送電波の内容を復調し、1以上の番組が多重化された復調データ(ストリームデータ)を提供するデモジュレータ422と、デモジュレータ422で復調されたデータから(ユーザが希望する)特定番組の情報(後述する図23を例に採れば、番組2のトランスポートパケット)を選択する受信情報セレクタ部423とを備えている。
【0358】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を情報記憶媒体201に記録する場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、データ転送インターフェイス部20を介して、IEEE1394転送により、光ディスク装置415のデータ転送インターフェイス部414に送る。
【0359】
受信情報セレクタ部423で選択された特定番組の情報(トランスポートパケット)を記録することなく単に視聴するだけの場合は、STB制御部404の指示にしたがい、セレクタ部423は特定番組のトランスポートパケットだけを含むストリームデータを、デコーダ部402の多重化情報分離部425に送る。
【0360】
一方、情報記憶媒体201に記録された番組を再生する場合は、IEEE1394のシリアルバスを介して光ディスク装置415からSTB装置416に送られてきたストリームデータは、セレクタ部423を介してデコーダ部402の多重化情報分離部425に送られる。
【0361】
多重化情報分離部425は、セレクタ部423から送られてきたストリームデータに含まれる各種パケット(ビデオパケット、オーディオパケット、サブピクチャパケット)を、内部メモリ部426上で、各パケットのIDにより区分けする。そして、区分けされたパケットを、それぞれ該当するデコード部(ビデオデコード部428、サブピクチャデコード部429、オーディオデコード部430に分配する。
【0362】
ビデオデコード部428は、多重化情報分離部425から送られてきた(MPEGエンコードされた)ビデオパケットをデコードして、動画データを生成する。その際、MPEGビデオデータ中のIピクチャから記録内容を代表する縮小画像(サムネールピクチャ)を生成する機能を持たせるために、ビデオデコード部428は、代表画像(サムネール)生成部439を内蔵している。
【0363】
ビデオデコード部428でデコードされた動画(および/または生成部439で生成された代表画像)と、サブピクチャデコード部429でデコードされたサブピクチャ(字幕、メニュー等の情報)と、オーディオデコード部430でデコードされた音声とは、ビデオプロセサ部438を介してビデオミキシング部405へ送出される。
【0364】
ビデオミキシング部405は、フレームメモリ部406を利用して、動画に字幕等を重ねたデジタル映像を作り出す。このデジタル映像は、D/A変換器436を介してアナログ映像化され、モニタTV437に送られる。
【0365】
また、ビデオミキシング部405からのデジタル映像は、I/F部434およびIEEE194等の信号ラインを介して、パーソナルコンピュータ435に適宜取り込まれる。
【0366】
一方、オーディオデコード部430でデコードされたデジタルオーディオ情報は、D/A変換器432および図示しないオーディオアンプを介して、外部スピーカ433に送られる。また、デコードされたオーディオ情報は、I/F部431を介して外部にデジタル出力される。
【0367】
なお、STB装置416内の動作タイミングは、システムタイムカウンタ(STC)部424からのクロックにより決定される。
【0368】
上述したSTB制御部404による指示等(STB装置416の内部構成各々の動作制御)は、プログラムメモリ部404aに格納された制御プログラムにより実行される。その際、STB制御部404による制御過程においてワークメモリ部407が適宜利用される。
【0369】
このSTB制御部404およびデコーダ部402を含めSTB装置416の内部動作のタイミングは、STC部424からのクロックで規制できる。また、光ディスク装置415のSTC440とSTB装置416のSTC部424を同期させることで、光ディスク装置415およびSTB装置416を含めたストリーマシステム全体の動作タイミングを規制できる。
【0370】
STC440とSTC部424を同期させる方法としては、データ転送インターフェース部414とデータ転送インターフェース部420との間で受け渡されるストリームデータ中の基準クロック(SCR)により、STC440およびSTC部424をセットする方法がある。
【0371】
図19の装置構成を機能別にみると、STB装置416内は、「受信時刻管理部」と、「ストリームデータ内容解析部」と、「ストリームデータ転送部」と、「時間関連情報生成部」とに分割/分類できる。
【0372】
ここで、「受信時刻管理部」は、デモジュレータ(復調部)422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等で構成される。この「受信時刻管理部」は、衛星アンテナ421でデジタルTV放送を受信し、受信した放送情報内の各トランスポートパケット毎の受信時刻を記録する。
【0373】
「ストリームデータ内容解析部」は、多重化情報分離部425、STB制御部404等で構成される。この「ストリームデータ内容解析部」は、受信したストリームデータの中身を解析し、I,B,Pの各ピクチャ位置および/またはPTS値を抽出する。
【0374】
「ストリームデータ転送部」は、多重化情報分離部425、受信情報セレクタ部423、STB制御部404、データ転送インターフェース部420等で構成される。この「ストリームデータ転送部」は、各トランスポートパケット毎の差分受信時刻間隔を保持したままストリームデータを光ディスク装置415へ転送する。
【0375】
「時間関連情報生成部」は、多重化情報分離部425、STB制御部404、データ転送インターフェース部420等で構成される。この「時間関連情報生成部」は、「受信時刻管理部」で記録した受信時刻(タイムスタンプ)情報と「ストリームデータ内容解析部」で抽出した表示時刻情報(PTS値および/またはフィールド数)との間の関係情報を作成する。
【0376】
図20は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。図20を用いてこの発明の基本的特徴について説明する。
【0377】
TVの表示方式の1つであるNTSC方式では、1秒間に30枚の画面/ピクチャ(フレーム)を映像信号としてTVのモニタスクリーンに表示している。通常のTVでは、インターレース方式を用いているので、1画面の全走査線に対して始めに1本おきに画面を走査して表示し、その後で1本ずらした画像を1本おきに走査することで直前の画面の間を埋めて1枚の画面(ピクチャ)の表示を行う。この1本おきに表示する画像をフィールドと呼ぶ。
【0378】
NTSC方式では、毎秒30フレーム/60フィールドを表示している。このNTSC方式は主に日本とアメリカで採用されている表示方式である。それに対して、主に欧州で採用されているPAL方式では、毎秒25フレーム/50フィールドの表示を行っている。
【0379】
図20(a)は、毎秒30枚変化する画面/ピクチャ(フレーム)を表示時刻(プレゼンテーションタイム;または再生時間)1に沿って並べた図である。
【0380】
画面/ピクチャの表示時刻(再生時間)1を表す情報としては、
(a)”ある特定の画面(ピクチャ)からの差分フィールド枚数”で表す方法と;
(b)”PTS(プレゼンテーションタイムスタンプ;または再生タイムスタンプ)”で表す方法がある。
【0381】
PTSは、27MHzおよび/または90kHzの基準クロックを利用し、常にインクリメント(カウンタの値が1ずつ増加)するカウンタの値で表示時刻を表す方法で用いることができる。たとえば、27MHz(または90kHz)の基準クロックでインクリメントするカウンタで各画面/ピクチャ(フレーム)を示すときのカウンタの値が、PTSの値として用いられる。
【0382】
デジタルTVでの受信信号情報内には、各ピクチャ毎のPTS値がピクチャヘッダ情報41(図1(j)参照)内に含まれている。
【0383】
図20(a)では、Iピクチャaの表示時刻がPTSNo.1で表わされ、Iピクチャiおよびqの表示時刻がPTSNo.2およびPTSNo.3で表わされている。
【0384】
いま、例えばユーザから、Iピクチャa表示の何時間何分何秒後の画面(ピクチャ)を表示するように指示を受けたとする。すると、上記指定時間間隔(何時間何分何秒後)が27MHzおよび/または90kHzのカウント値に換算される。そして、この換算値とIピクチャa表示のPTS値(PTSNo.1)との加算結果を計算して、ユーザから指示された「表示すべき画面(ピクチャ)」を検索することができる。
【0385】
情報記憶媒体201上に記録されたストリームデータは、図1(g)その他に示したように各トランスポートパケット毎にタイムスタンプを付加して記録されているので、このタイムスタンプ情報を利用してストリームデータに対する時間管理を行っている。
【0386】
しかし、このタイムスタンプ情報はユーザには認知できないため、ユーザは表示時刻(再生時間)1を用いて、見たい画面(ピクチャ)を指定することになる。
【0387】
この場合、ストリームデータを時間管理するためのタイムスタンプ情報とユーザが指定可能な表示時刻(再生時間)1情報との間の関係を示す情報が必要になる。この関係を示す情報が、図20(b)に示す時間関係テーブル2(あるいは図15の再生タイムスタンプリストPTSL)である。
【0388】
図20(b)に例示するように、時間関係テーブル2には、各PTS値(PTSNo.1、PTSNo.2、PTSNo.3、…)毎に、対応するデータ転送時刻情報(Iピクチャ転送開始時刻4)、データ転送時刻情報(Iピクチャ転送終了時刻5)、セル先頭から目的のIピクチャまでの通算パケット数10が記述されている。
【0389】
たとえば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」となる。
【0390】
同様に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以後についても同様である。
【0391】
図20(b)に示すような時間関係テーブル2を、ストリームデータ(図1(a)、図20(c)その他のSTREAM.VRO106)に関する管理情報(図15のSFIT)が記録されている領域に記録し、この時間関係テーブルを利用して、ユーザにとってピクチャ単位の画面位置指定ができるようにした所に、この発明の大きな特徴がある。
【0392】
ここで、上記時間関係テーブル2と図15に示した再生タイムスタンプリストPTSLとの対応関係について、説明しておく。
【0393】
図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に対応することになる。
【0394】
よって、再生タイムスタンプリストPTSLは、AU(Iピクチャ)の開始時刻(SC_S_APAT)と、ビットストリームに含まれるパケットのタイムスタンプATSとの関係(再生時間に関する関係)を示す情報(PTSの値)を含む「時間関係テーブル(図20(b))」であると言える。
【0395】
あるいは、PTSL(時間関係テーブル)は、PTSの値とATSとの対応関係を示す情報であるとも言える。
【0396】
ところで、BピクチャあるいはPピクチャを表示するためには、必ずIピクチャの表示(デコード)から開始する必要がある。このため、図20(b)に示す時間関係テーブル2は、Iピクチャ位置でのタイムスタンプと対応する表示時刻情報を一覧表として示してある。
【0397】
ここでは、表示時刻情報として、”PTS情報(PTSの値)”、”特定基準画面(ピクチャ)からの差分フィールド数”、”年月日時刻情報”等を用いることができる。
【0398】
なお、表示時刻情報として図20(b)に示すような絶対値表示を行う代わりに、各Iピクチャ間の差分情報(例えば各Iピクチャ間に挿入されるフィールド数情報)を使用することも可能である。(フィールド数を利用した時間関係テーブルについては、図28を参照して後述する。)
また、図20(b)では表示時刻情報として”PTS情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面(ピクチャ)からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。
【0399】
図20(b)に示す時間関係テーブル2では、各Iピクチャ毎の転送開始時刻4の値がタイムスタンプ(ATS)#1、#3、#5として一覧表に記録されているだけでなく、Iピクチャの転送終了時刻5の値もタイムスタンプ(ATS)#2、#4、#6として記録されている。
【0400】
このため、早送り再生(ファーストフォワードFF)あるいは早戻し再生(ファーストリバースFRなどの特殊再生を行う場合には、”タイムスタンプ(ATS)#1から#2まで”、”タイムスタンプ(ATS)#3から#4まで”、”タイムスタンプ(ATS)#5から#6まで”というように、再生するIピクチャのトランスポートパケット位置(またはアプリケーションパケット位置)を指定することで、情報記憶媒体201から、Iピクチャ情報(またはアクセスユニットAU情報)のみを再生し、デコードし、表示することが可能となる。
【0401】
図20(a)の実施の形態では、オリジナルセル(図4参照)の表示開始ピクチャ位置(Bピクチャfの位置)を基準に採っている。このオリジナルセルの表示開始ピクチャのPTS値(PTSNo.5)とその直前にあるIピクチャaのPTS値(PTSNo.1)との差分が、PTSオフセット9である。このPTSオフセット値9は、図3(h)に示したように、オリジナルセル情報272内に記録される。
【0402】
具体的には、図20(a)に示すように、オリジナルセルの表示開始ピクチャをBピクチャfとし、その時のPTS値をPTSNo.5とする。その直前のIピクチャaの表示時刻をPTSNo.1とすると、PTSオフセット9の値は、”PTSNo.5 − PTSNo.1”で求まる。
【0403】
ユーザが特定画面(特定のピクチャフレーム)を指定する場合、オリジナルセルの表示開始位置からの差分表示時間で指定する場合が多い。この差分表示時間を27MHzおよび/または90kHzのカウンタ数に換算後、PTSオフセット9の値を加算することで、ユーザが指定した画面(ピクチャフレーム)のPTS値を算出できる。
【0404】
図20(b)に示すように、時間関係テーブル2には、各Iピクチャ毎のPTS値一覧が記録されている。このテーブルを参照し、算出したPTS値よりも小さく、しかも算出したPTS値に最も近いIピクチャ位置のPTS値を探し、そこに対応したIピクチャ転送開始時刻4のタイムスタンプ(ATS)値を指定して、情報記憶媒体201へのアクセスを開始する。
【0405】
図20(b)に示すように、時間関係テーブル2には、タイムスタンプと並行して、オリジナルセル先頭位置から該当するIピクチャまでの通算トランスポートパケット数10(アクセス位置情報)も記録されている。
【0406】
したがって、図20の実施の形態によれば、タイムスタンプ(ATS)の代わりにオリジナルセル先頭位置からのトランスポートパケット数(またはアプリケーションパケット数AP_Ns)を指定して、所望のストリームデータ位置へアクセスすることも可能である。
【0407】
図20(c)のストリームデータ(STREAM.VRO)106が図3等に示す情報記憶媒体201に記録される場合、ストリームデータ106の内容(SOBまたはSOBU)は、所定のデータ記録単位(トランスポートパケットまたはアプリケーションパケット)で、媒体201のデータ領域(STREAM.VRO/SR_TRANS.SRO)に記録される。その際、ストリームデータ106に関する管理情報(STRI)も、媒体201の管理領域(STREAM.IFO/SR_MANGR.IFO)に記録される。
【0408】
この管理情報(STRI)に、ストリームデータ106のアクセス(Iピクチャ情報またはアクセスユニットAUへのアクセス)に利用される第1の管理情報(Iピクチャ転送開始時刻に対応したATS;またはAUSM)と;第1の管理情報(AUSM)とは異なるものであって、この第1の管理情報と前記ストリームデータのアクセスに利用される第2の管理情報(PTS;またはSC_S_APAT)との間の関係を示す第3の管理情報(時間関係テーブル;またはPTSL)が記録される。
【0409】
ここで、ストリームデータ106はMPEG規格に基づき圧縮されたビットストリームであり、前記第2の管理情報はストリームデータの再生時間(PTS)に対応する。
【0410】
図21は、この発明の一実施の形態において、表示時刻とデータ転送時刻との間の関係を説明する図である。
【0411】
情報記憶媒体201上に記録されたストリームデータ(図1、図2その他のSTREAM.VRO106)内のデータ構造に関し、図21を用いて、各ピクチャ情報6010〜6030の記録位置とストリームブロック(SOBU)との間の配置関係を説明する。
【0412】
この実施の形態では、ストリームデータはストリームブロック(SOBU)単位で記録され、所定画像(ピクチャ)へのアクセス指定にはタイムスタンプ情報が利用される。
【0413】
図19のSTB装置416から再生開始位置としてタイムスタンプ値が指定された場合において、指定されたタイムスタンプ値に対応するストリームブロック(SOBU)を算出するための情報が、図3(h)のタイムマップ情報252(あるいは図15のタイムマップ情報MAPL、もしくは図18のタイムマップ情報)である。
【0414】
図3(h)の例では、タイムマップ情報252は、ストリームデータに対する管理情報記録領域であるSTREAM.IFO105内のストリームオブジェクト情報(SOBI)242の一部として記録されている。図15の例でも、タイムマップ情報MAPLはSOBIの一部として記録されている。
【0415】
図3(i)に示すタイムマップ情報252内では、各ストリームブロック毎のタイムスタンプ差分時間情報しか記録されていない。この場合は、各ストリームオブジェクト情報(SOBI)242、243毎に、タイムマップ情報252内の各ストリームブロックの時間差263、265の値を逐次加算する。そして、この逐次加算値が、STB装置416側により指定されたタイムスタンプ時刻に到達したか否か比較する必要がある。その比較結果を元に、STB装置416側により指定された時刻がどのストリームオブジェクト(SOB)内の何番目のストリームブロック(SOBU)の中に含まれるタイムスタンプ値と一致するかが割り出される。
【0416】
図21(c)に示すように各ピクチャ情報6010〜6030の境界位置とストリームブロック(SOBU)の境界位置とは必ずしも一致しない。
【0417】
この場合、例えば図21(a)で示すように、PTSの値がPTSNo.6であるPピクチャoの位置から再生を開始しようとするなら、次のような処理が必要になる。
【0418】
すなわち、図21(b)の時間関係テーブル2(内部構成は図20(b)と同様)からその直前にあるIピクチャiのPTSNo.2の値を割り出し、Iピクチャi情報6010が記録されている先頭のトランスポートパケット#2が含まれるストリームブロック(SOBU)#A先頭位置から、再生を開始する必要がある。
【0419】
ただし、ストリームブロック(SOBU)#A先頭位置から所望のPピクチャoの位置まで再生が進むまで、その間の画像情報(図21(a)ではピクチャiからピクチャnまで)は外部モニタ(TV)に出力されない。
【0420】
図22は、MPEGにおける映像情報圧縮方法とトランスポートパケットとの関係、およびMPEGにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。
【0421】
図22に示すように、デジタルTVでの放送信号情報にはMPEG2と呼ばれる信号圧縮方法が採用されている。MPEGによる信号圧縮方法では、TV表示用の各画面(ピクチャ)は時間差分情報を含まないIピクチャ551と時間差分情報を含むBピクチャ553、554とPピクチャ552に分類される。
【0422】
Iピクチャは前後の画面(ピクチャ)情報の影響を受けることなく単体で存在し、1枚の画面(ピクチャ)に対してDCT変換後、量子化した情報がIピクチャ圧縮情報561となり、Iピクチャ情報31として記録される。Pピクチャ552はIピクチャ551に対する差分情報562のみがPピクチャ情報32として記録され、Bピクチャ553、554はIピクチャ551とPピクチャ552に対する差分情報がBピクチャ情報33、34として記録される。
【0423】
従って、映像再生時にはPピクチャ552やBピクチャ553、554単体では画面を生成することができず、必ずIピクチャ551画面を生成した後に初めて各ピクチャ画面を生成できる。各ピクチャ情報31〜34は1個または複数のトランスポートパケット内のペイロードに分割記録されている。この時、各ピクチャ情報31〜34の境界位置とトランスポートパケット間の境界位置は常に一致するように記録されている。
【0424】
図22のトランスポートパケットがストリーマ(図19の光ディスク装置415)に記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ(ATS)というタイムスタンプ付きのパケット(アプリケーションパケット)に移し替えられる。
【0425】
そして、ATS付きアプリケーションパケットの一群(通常10パケット前後)がストリームPESパケット内のアプリケーションパケットエリアに格納される。
【0426】
このストリームPESパケットにパックヘッダを付したものが1つのストリームパックになる。
【0427】
ストリームPESパケットは、PESヘッダと、サブストリームIDと、アプリケーションヘッダと、アプリケーションヘッダエクステンション(オプション)と、スタッフィングバイト(オプション)と、上記ATS付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。
【0428】
図23は、デジタル放送のコンテンツとIEEE1394における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。
【0429】
デジタル放送では、MPEG2規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図23(b)に示すように、トランスポートパケットヘッダ511と、記録情報のデータ本体が記録されているペイロード512とで構成されている。
【0430】
トランスポートパケットヘッダ511は、図23(a)に示すように、ペイロードユニット開始インジケータ501、パケットID(PID)502、ランダムアクセスインジケータ503、プログラムクロックリファレンス504等で構成されている。
【0431】
MPEG圧縮された映像情報は、Iピクチャ情報、Bピクチャ情報、およびPピクチャ情報を含んでいる。Iピクチャ情報が記録されている最初のトランスポートパケットには、図23(a)のランダムアクセスインジケータ503に”1”のフラグが立つ。また、各B、Pピクチャ情報の最初のトランスポートパケットには、図23(a)のペイロードユニット開始インジケータ501に”1”のフラグが立つ。
【0432】
これらのランダムアクセスインジケータ503およびペイロードユニット開始インジケータ501の情報を利用して、Iピクチャマッピングテーブル(図9(e)の641)およびB、Pピクチャ開始位置マッピングテーブル(図9(e)の642)の情報が作成される。
【0433】
たとえば、図23(a)に示したペイロードユニット開始インジケータ501に”1”のフラグが立ったトランスポートパケットに対して、B、Pピクチャ開始位置マッピングテーブル(図9(e)の642)内の該当個所のビットが”1”になる。
【0434】
デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図23(a)のパケットID(PID)502で識別される。このPID502の情報を用いて、ビデオパケットマッピングテーブル(図9(e)の643)とオーディオパケットマッピングテーブル(図9(e)の644)が作成される。
【0435】
図23(c)に示すように、デジタル放送では、1個のトランスポンダに複数の番組(この例では番組1〜番組3)がパケット化された形で時分割されて転送されてくる。
【0436】
たとえば、図23(b)のトランスポートパケットヘッダ511およびペイロード(記録情報)512の情報は、図23(c)に示される番組2のトランスポートパケットb・522、e・525により転送される。
【0437】
ユーザが例えば図23(c)の第2の番組を情報記憶媒体201に記録しようとする場合には、図19に示すSTB装置416内の受信情報セレクタ部423において、番組2のトランスポートパケットb、eのみが抽出される。
【0438】
そのとき、STB装置416では、図23(d)に示すように、各トランスポートパケット b522、e525を受信した時刻情報をタイムスタンプ531、532の形で付加する。
【0439】
その後、IEEE1394の転送方式を用いて図19のフォーマッタ/デフォーマッタ部413にデータを転送する場合には、図23(e)に示すように、タイムスタンプとトランスポートパケットの組が細かく分割されて転送されることになる。
【0440】
図19のフォーマッタ/デフォーマッタ部413では、STB装置416からIEEE1394で転送されてきたストリームデータが、図23(d)の形(図1(g)の形に相当)に一旦戻される。そして、図23(d)の形式のビットストリーム(図23(h)のストリームパック列)が、情報記憶媒体201に記録される。
【0441】
具体的には、この発明の一実施の形態においては、各セクタの先頭には、システムクロック情報などが記録されたパックヘッダとPESヘッダが配置される(図23(h)等参照)。
【0442】
データエリア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つがある。
【0443】
この特徴を生かしたデータ構造を用いることにより、セクタサイズ(例えば2048バイト)よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。
【0444】
デジタル放送では図23(c)に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、1個のトランスポートパケットb・522のサイズが188バイト(または183バイト)の場合が多い。
【0445】
前述したように1セクタサイズは2048バイトであり、各種ヘッダサイズを差し引いても1個のデータエリア21、22、23(図1(f))内にはデジタル放送用のトランスポートパケットが10個前後記録できる。
【0446】
それに対して、ISDNなどのデジタル通信網では1パケットサイズが4096バイトある大きなロングパケットが転送される場合がある。
【0447】
デジタル放送などのように1個のデータエリア21、22、23(図1(f))内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造(1パケットのデータを複数パケットに跨って記録できる特徴)を用いることにより、1個のパケットを複数のデータエリア21、22、23に連続して跨るように記録する。
【0448】
そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。
【0449】
また、通常のパケットにはタイムスタンプが付いているが、図23(g)に示すように、部分パケットではタイムスタンプを省略することができる。
【0450】
このようにすると、2つの隣接ストリームパック(図23(h))の境界で分断された部分パケット(パケット1つあたり188バイトとすれば部分パケットのサイズは1〜187バイト;平均して100バイト弱)を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分(タイムスタンプ1つあたり例えば4バイト)、媒体201に対する記憶容量を増やすことができる。
【0451】
なお、図23(g)の先頭部分パケットの直後にくるタイムスタンプの位置は、図10(b)のファーストアクセスポイント625あるいは図10(c)のFIRST_AP_OFFSETにより、特定することができる。
【0452】
図19の光ディスク装置415(ストリーマ)では、タイムスタンプとトランスポートパケットとの組(図23(f)(g))をそのままの形で情報記憶媒体201上に記録する。
【0453】
図24は、この発明の一実施の形態に係るストリームデータの記録手順を説明するフローチャート図である。図24を用いて、ストリームデータ録画時の処理について説明する。この処理は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0454】
図23(c)に示すように、1個のトランスポンダ内には複数番組情報が時分割多重化されている。
【0455】
図19の受信情報セレクタ部423内で、この時分割多重化された複数番組情報のパケット列から、特定番組のみのトランスポートパケットが抽出される(ステップS01)。
【0456】
「受信時刻管理部(図19の復調部422、受信情報セレクタ部423、多重化情報分離部425、STB制御部404等)」では、必要な番組情報が、多重化情報分離部425のメモリ部426内に、一時保管される(ステップS02)。
【0457】
それと同時に、各トランスポートパケット毎の受信時刻が計測され、その計測値が、図23(d)に示すように、タイムスタンプ(ATS)として各トランスポートパケット(またはアプリケーションパケット)毎に付加される。こうして付加されたタイムスタンプ情報は、メモリ部426内に記録される(ステップS03)。
【0458】
次に、「ストリームデータ内容解析部(図19の多重化情報分離部425、STB制御部404等)」において、メモリ部426内に記録されたトランスポートパケット(アプリケーションパケット)内の情報が解析される。
【0459】
具体的には、トランスポートパケット(アプリケーションパケット)列から各ピクチャ境界位置の切り出しが行われるとともに、各パケット毎のピクチャヘッダ情報41からPTS情報(まあは対応フィールド枚数情報)の抽出が行なわれる(ステップS04)。
【0460】
ここで、各ピクチャ境界位置の切り出し方法には2通りの方法が存在し、いずれの方法を選択するかはストリームデータの内容による。
【0461】
第1のピクチャ境界位置切出方法は、トランスポートパケットヘッダ511(図23(b))内のランダムアクセスインジケータ503(図23(a))のフラグを検出してIピクチャ位置を検出し、ペイロードユニット開始インジケータ501(図23(a))のフラグ検出からBまたはPピクチャ位置を検出する方法である。
【0462】
第2のピクチャ境界位置切出方法は、ピクチャヘッダ情報41(図1(j))内にあるピクチャ識別情報52(図1(k))およびPTS情報53(図1(k))を抽出する方法である。
【0463】
上記の処理(ステップS01〜S04)を経た後、「時間関連情報生成部(図19の多重化情報分離部425、STB制御部404、データ転送インターフェース部420等)」では、タイムスタンプ(ATS)とPTS値との間の関係を示す一覧表として、図20(b)に示すような時間関係テーブル2(あるいは図15の再生タイムスタンプリストPTSL)を作成し、STB制御部404内のワークメモリ部407に記録する(ステップS05)。
【0464】
その後、STB装置416および光ディスク装置415における受信時刻間隔を保持しながら(つまり図19のSTC440のカウント値変化とSTC424のカウント値変化との間の関係を一定に保ちながら)、多重化情報分離部425のメモリ部426に一時保管されたパケットデータ(ストリームデータ)が、光ディスク装置415に転送される(ステップS06)。
【0465】
こうして、光ディスク装置415により、メモリ部426に一時保管されたストリームデータが、情報記憶媒体201上に記録される(ステップS07)。
【0466】
光ディスク装置415へのストリームデータ転送が完了するまでは(ステップS08ノー)、ステップS06〜S07の処理が反復される。
【0467】
光ディスク装置415へのストリームデータ転送が済みその録画処理が完了すると(ステップS08イエス)、STB制御部404のワークメモリ部407内に一時記録されていた時間関係テーブル2(あるいは再生タイムスタンプリストPTSL)の情報が、光ディスク装置415へ転送される(ステップS10)。
【0468】
そして、時間関係テーブル2(あるいは再生タイムスタンプリストPTSL)の情報が、情報記憶媒体201の管理情報記録領域(STREAM.IFO)105に記録される(ステップS11)。
【0469】
なお、上記ステップS11の処理時に、録画されたストリームデータの内容であるストリームオブジェクトの記録時間(図7(i)のSOB_REC_TM)を、管理情報記録領域(STREAM.IFO)105内のタイムゾーン(TM_ZONE)6240(図7(h)に記録することができる。
【0470】
ところで、ストリームデータ録画時にコンテンツプロバイダの著作権保護を目的として暗号化されたストリームデータを記録する場合がある。このように暗号化がなされるときは、全てのトランスポートパケットが暗号化されるとともに、STB装置416と光ディスク装置415との間のタイムスタンプ転送処理が禁止される。この場合には、情報記憶媒体201への(暗号化された)ストリームデータ記録時に、光ディスク装置415側で独自にタイムスタンプを付加する必要が生じる。
【0471】
図19のSTB装置416側では、トランスポートパケット(アプリケーションパケット)毎の受信時刻管理を行っている。この場合、STB装置416側と光ディスク装置415側との間で、基準クロック周波数のずれに対する対策(具体的には基準クロックの同期化)が重要課題となる。そこで、以下、暗号化されたストリームデータに対する録画処理について説明する。
【0472】
図25は、この発明の一実施の形態に係る、暗号化されたストリームデータの記録手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0473】
まず、図19のSTB制御部404のワークメモリ407内に時間関係テーブル2(図20(b))あるいは再生タイムスタンプリストPTSL(図15)があるかどうか、チェックされる(ステップS50)。
【0474】
時間関係テーブル(あるいはPTSL)がない場合は(ステップS50ノー)、図24のステップS04〜S05と同様な処理で、時間関係テーブル(あるいはPTSL)が作成される(ステップS52)。
【0475】
こうして時間関係テーブル(あるいはPTSL)が作成されたあと、あるいは既に時間関係テーブル(あるいはPTSL)がSTB制御部404のワークメモリ407内にあるときは(ステップS50イエス)、STB装置416から光ディスク装置415へ(暗号化された)ストリームデータが転送され、このストリームデータが情報記憶媒体201に記録される(ステップS51)。
【0476】
この(暗号化された)ストリームデータの記録が完了するまで(ステップS53ノー)、ステップS51の処理が継続される。このストリームデータ記録ステップS51は、図24のステップS01〜S03、S06と同様な処理内容である。
【0477】
なお、ステップS52の処理は、ステップS51の処理中にこれと並行して実行されてもよい。
【0478】
こうして(暗号化された)ストリームデータの記録が完了すると(ステップS53イエス)、STB装置416と光ディスク装置415との間で基準クロックの同期化処理が実行される(ステップS54)。
【0479】
この基準クロックの同期化処理は、たとえば以下のようにして行なうことができる。
【0480】
すなわち、ストリームデータ転送時に、トランスポートパケット(アプリケーションパケット)を特定個数(例えば1万個あるいは10万個)送信/受信する毎にその送信/受信時刻をSTB装置416と光ディスク装置415でそれぞれワークメモリ部407と一時記憶部411に記録しておく。
【0481】
その後、STB装置416側から光ディスク装置415側へトランスポートパケット(アプリケーションパケット)を特定個数送信する毎に送信時刻一覧表を送付する。そして、光ディスク装置415側において、送付された一覧表と光ディスク装置415側で事前に作成した一覧表とを比較することで、両者間の基準クロック同期ずれ量を算出する。
【0482】
その後、STB装置416から光ディスク装置415へ、時間関係テーブル2(あるいはPTSL)が転送される(ステップS55)。
【0483】
こうしてSTB装置416から光ディスク装置415へ転送された時間関係テーブル2(あるいはPTSL)は、ステップS54の基準クロックの同期化処理で算出した基準クロック同期ずれ量の情報を基に、修正される(ステップS56)。
【0484】
こうして基準クロック同期ずれ量分修正された時間関係テーブル2(あるいはPTSL)が、情報記憶媒体201の管理情報領域(図3(e)のSTREAM.IFO105;あるいは図15のSFIT)内に記録される(ステップS57)。
【0485】
以上のようにすれば、(暗号化された状態の)ストリームデータの記録/再生が可能になる。
【0486】
上記のような「暗号化されたストリームデータに対する基準クロック同期のずれ補正」方法の代わりに、他の方法として、次のようにしてもよい。
【0487】
すなわち、図20(b)に示すように、各Iピクチャ間に転送されるトランスポートパケット数を時間関係テーブル2に記録する。そして、(ピクチャ指定方法として)再生開始の画面のタイムスタンプ値を指定する代わりに、セル先頭からの通算トランスポートパケット(またはアプリケーションパケット)数を指定する。
【0488】
この場合には、タイムマップ情報252内の情報として、図3(i)に示したデータ構造の代わりに、図11に示すように、ストリームブロック毎に含まれるトランスポートパケット数(またはアプリケーションパケット数AP_Ns)633を持たせる。
【0489】
所定の画面(ピクチャ)にアクセスするためSTB装置416側から通算トランスポートパケット数(通算アプリケーションパケット数)が指定されると、光ディスク装置415側では、図11に示すの最初のストリームブロックから順次トランスポートパケット(アプリケーションパケット)数633が加算されて行き、加算結果が指定された値に達した時点でのストリームブロック(またはSOBU)へ、アクセスが行われる。
【0490】
図26は、この発明の一実施の形態に係るストリームデータの再生手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。以下、図26を用いてストリームデータの再生ステップについて説明する。
【0491】
ユーザは、希望する再生開始時刻および/または再生終了時刻を、「指定したオリジナルセルの表示開始時刻を基準とした差分時間(何時間何分何秒)」の形で指定することができる。こうして指定された、たとえば特定の再生開始時刻および再生終了時刻を、STB装置416内のSTB制御部404が受け取る(ステップS21)。
【0492】
STB制御部404内では、その受け取った再生開始時刻および再生終了時刻の時間情報を、27MHzおよび/または90kHzのクロックカウント値に換算して、オリジナルセルの表示開始時刻からの差分PTS値を算出する。
【0493】
STB制御部404は、光ディスク装置415をコントロールしてストリームデータ管理情報記録領域(STREAM.IFO105)内に記録された時間関係テーブル2(またはPTSL)を読み取り、ワークメモリ部407内に一時記録する(ステップS22)。
【0494】
また、STB制御部404は、光ディスク装置415をコントロールしてストリームデータ管理情報記録領域(STREAM.IFO105)内に記録されたタイムマップ情報252(またはMAPL)の情報を読み取り、ワークメモリ部407内に一時記録する(ステップS23)。
【0495】
次に、図3(h)および図20(a)に示したPTSオフセット9の値を読み取り、該当するオリジナルセル(図20(a)ではBピクチャfに該当)の表示開始時刻とその直前のIピクチャaの表示時刻との差(図20(a)ではPTSNo.5−PTSNo.1)を調べる(ステップS24)。
【0496】
さらに、図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)。
【0497】
次に、ユーザが指定した再生開始場所の直前のIピクチャiのPTS値とタイムスタンプ#2の値を、時間関係テーブル2を利用して調べ(ステップS26)、光ディスク装置415に通知する。
【0498】
光ディスク装置は、図3(h)に示したタイムマップ情報252のデータ(図3(i))から、そのIピクチャi情報6010(図21(c))の先頭位置が含まれるストリームブロック(SOBU)#Aの先頭のタイムスタンプ(ATS)#1の値を調べるとともに、アクセスすべき先頭セクタ#αの場所(アドレス)を割り出す(ステップS27)。
【0499】
こうして割り出されたアドレスに基づいて、光ディスク装置415は、図21(c)のトランスポートパケット(AP)#1からの情報を、情報記憶媒体201から再生する(ステップS28)。
【0500】
次に、図19のSTB制御部404は、デコーダ部402へ、ステップS28で再生を開始した情報の表示開始時刻を示すPTS値(図21(a)のPTSNo.6)を通知する(ステップS29)。
【0501】
この通知とともに、光ディスク装置415はSTB装置416側に、ステップS28で再生を開始した情報を転送する(ステップS30)。
【0502】
続いて、STB制御部404は、デコーダ部402内のメモリ426からピクチャ識別情報52(図1(k))を読み取り、入力されたIピクチャ(光ディスク装置415から転送されてきた情報の一部)より前のデータを破棄(あるいは無視)する(ステップS31)。
【0503】
次に、図19のビデオデコード部428は、ステップS31で入力されたIピクチャ(図21(a)ではIピクチャi)の先頭位置からデコードを開始し、ステップS29の通知により指定されたPTS値(図21(a)のPTSNo.6)のところから、表示(ビデオ出力)を開始する(ステップS32)。
【0504】
以下、ステップS24〜S28と同様な処理を反復し、再生終了時刻に対応した情報記憶媒体201上のアドレスを調べ、再生終了時刻に対応した終了アドレスまで再生を継続する(ステップS33)。
【0505】
上記の一連の再生が終了した段階で、図7(g)に示す再生終了位置情報6110を、レジューム情報として、管理情報記録領域(図7(e)に示すSTREAM.IFO105)内のビデオマネージャ情報231(図7(F))中に記録することができる。
【0506】
この再生終了位置情報6110のデータ内容としては、図7(h)に示すように該当するPGC番号6210とその中のセル番号6220、再生終了位置時刻情報6230が記録される。
【0507】
この時刻情報6230はタイムスタンプ値で記録されているが、PTS値(あるいはセル再生先頭位置からの通算フィールド数)を時刻情報6230として記録することもできる。
【0508】
再度この再生終了位置情報を(レジューム)情報6110の位置から再生開始する場合には、後述する図27の処理により再生開始位置を求めることができる。
【0509】
図26を参照して上述したような標準再生時には、STB装置416内の基準クロック作成部であるSTC部424のカウント値が、図1(k)に示すDTS(デコードタイムスタンプ)情報54の値に一致した時から、デコーダ部402内のデコードが開始される。
【0510】
図27は、この発明の一実施の形態に係るストリームデータの特殊再生の手順を説明するフローチャートである。この処理手順は、図19に示すSTB制御部404のプログラムメモリ部404a内に格納された処理プログラムにより実行できる。
【0511】
早送り再生(ファーストフォワードFF)あるいは早戻し再生(ファーストリバースFR)などの特殊再生を行う場合には、情報記憶媒体201上に記録されたIピクチャ情報のみを抽出再生し、デコード表示する。
【0512】
この場合、STC部424(図19)とDTS情報54(図1(k))と間の同期をはずし、フリーモードでデコードするように、デコーダ部402に対して「特殊再生モードの設定」を行う(ステップS41)。
【0513】
特殊再生時にも、時間関係テーブル2とタイムマップ情報252の情報を情報記憶媒体201の管理情報記録領域(STRAM.IFO)105から読み取り、STB制御部404のワークメモリ部407内に記録する(ステップS42)。
【0514】
次に、該当する再生開始場所に対応したストリームオブジェクト情報(SOBI)242のタイムマップ情報252を読み取り、STB制御部404内のワークメモリ部407に一時記録する(ステップS43)。
【0515】
次に、時間関係テーブル2から、各Iピクチャ位置(図16の例では各AU#の位置)での開始時刻/終了時刻のタイムスタンプ値を抽出する(ステップS44)。
【0516】
次に、タイムマップ情報252から、該当するIピクチャのタイムスタンプ値が含まれるストリームブロック(SOBU)を調べ、その先頭セクタのアドレスを調べる(ステップS45)。
【0517】
たとえば、特殊再生時には、後述する図28(b)のIピクチャ情報6010〜6050のみがデコードされて表示される。このIピクチャ情報6010〜6050の位置は、時間関係テーブル2およびタイムマップ情報252の情報を利用して、求めることができる。
【0518】
次に、光ディスク装置415は、情報記憶媒体201上の各Iピクチャが含まれる禅ストリームブロック(SOBU)内の情報を再生し、再生した情報を多重化情報分離部425内のメモリ部426に転送する(ステップS46)。
【0519】
次に、図19のデコーダ部402内において、多重化情報分離部425のメモリ部426に転送されたデータ内のピクチャ識別情報52(図1(k))を読み取り、この情報52を基にIピクチャ以外のデータを破棄する(ステップS47)。
【0520】
つまり、ステップS47においては、再生・転送されたストリームデータの中から、ピクチャ識別情報52を用いてIピクチャ情報のみが抽出され、ビデオデコード部428において抽出されたIピクチャ情報のみがデコードされる。
【0521】
次に、デコーダ部402内の多重化情報分離部425のメモリ部426内部で選別された(つまり破棄されなかった)Iピクチャデータを、フレームメモリ部406に転送する(ステップS48)。
【0522】
こうしてフレームメモリ部406に転送されたIピクチャのデータが、TV(あるいはビデオモニタ)437の表示スクリーン上で、逐次表示される(ステップS49)。
【0523】
図28は、この発明の他の実施の形態において、表示時刻とデータ転送時刻との間の関係を示す時間関係テーブルを説明する図である。
【0524】
図20の実施の形態では、表示時刻情報として図20(b)に示すように絶対値表示を行なっているが、その代わりに各Iピクチャ間の差分情報(例えば各Iピクチャ間に挿入されるフィールド数情報)を使用することも可能である。
【0525】
また、図20(b)では表示時刻情報として”PTS情報”を使用しているが、種々可能なこの発明の実施の形態では、この方法に限らず、その代わりに、”特定基準画面(ピクチャ)からの差分フィールド数”あるいは”年月日時刻情報”等を使用することができる。この場合の例が、図28の時間関係テーブル6である。
【0526】
図28(b)に示すように、各グループオブピクチャ(GOP)は、あるIピクチャ位置を先頭とし、そのIピクチャから次のIピクチャの直前までのピクチャ群を示す。図28(c)に示した時間関係テーブル6のデータ構造では、表示時間情報として、各GOP毎の表示フィールド枚数が記録されている。
【0527】
また、時間関係テーブル6内に、GOP毎に占有しているストリームブロック(SOBU)の個数も記載している。こうすることで、図3(h)に示したタイムマップ情報252を使用せずに、与えられた表示時間情報から、直接、Iピクチャ情報の先頭位置が記録してあるストリームブロック(SOBU)へのアクセスか可能となる。
【0528】
図28(b)の例におけるGOP#2とGOP#3の境界位置では、GOPの切り替わり位置とストリームブロック(SOBU)の切り替わり位置が一致している。このように隣接GOPの境界と隣接SOBUの境界とが一致する場合に、図28(c)に示した時間関係テーブル6内のGOP終端マッチングフラグが”1”に設定される。こうすることにより、Iピクチャ情報先頭位置が含まれるストリームブロック位置(SOBU位置)の同定精度を向上させている。
【0529】
また、前述したFFあるいはFR等の特殊再生時においてはIピクチャ情報の後端位置を使用するので、図28(c)の時間関係テーブル6には各GOP内のIピクチャサイズ情報も持たせている。
【0530】
図29は、この発明の一実施の形態において、ストリームデータ(SOBU)内のパケット(AP)がどのように再生されるかを説明する図である。
【0531】
図29は、図1(c)のストリームブロック##1、#2、…を、全て一定サイズ(2ECCブロックサイズ)のSOBU#1、#2、…で構成した場合を例示している。
【0532】
図29(f)は、SOBU#1の先頭セクタNo.0(図29(e))のデータ構造と、SOBU#1に隣接するSOBU#2の末尾セクタNo.63(図29(e))のデータ構造を示している。図示しないが、セクタNo.0〜セクタNo.62も同様な構想を持つ。
【0533】
図29(f)に示すように、セクタNo.0に対応するストリームパックのパックヘッダにはシステムクロックリファレンスSCRが記録され、セクタNo.63に対応するストリームパックのパックヘッダにもシステムクロックリファレンスSCRが記録されている。
【0534】
いま、再生しようとするピクチャ(ユーザが再生時間で指定したピクチャ)がSOBU#2の中間(図16では、たとえばAU#1が示す位置)に存在するとする。ユーザが再生時間で指定したピクチャは、セル開始アプリケーションパケット到着時間SC_S_APATに対応する。
【0535】
この場合、図19の記録再生部409に含まれるディスクドライブ(図示せず)は、SOBU#2の中間に直接アクセスすることはできず、SOBU#1とSOBU#2との境界位置にアクセスする。そして、図29(a)のストリームデータ(STREAM.VRO)106の再生は、SOBU#1とSOBU#2との境界位置から始まる。
【0536】
SOBU#1とSOBU#2との境界位置から再生開始位置(SC_S_APATに対応する位置)までの間隔は、図20(a)で説明したPTSオフセット9に対応する。
【0537】
SOBU#1とSOBU#2との境界位置から再生開始位置(SC_S_APATに対応する位置)までの間に存在するアプリケーションパケットは、デコードはされているが、再生出力はされない(画面表示されない)。これは、図26のステップS31の処理に対応している。
【0538】
図29(g)は、PTSの情報(PTS値あるいはPTSオフセット)と再生しようとするアプリケーションパケットAPとが、図20(a)の時間関係テーブル2によって関係付けられていることを図解したものである。
【0539】
ここで、上記時間関係テーブルと図15に示した再生タイムスタンプリストPTSLとの関係について、改めて整理しておく。
【0540】
図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に対応する。
【0541】
よって、再生タイムスタンプリストPTSLは、AU(Iピクチャ)の開始時刻(SC_S_APAT)と、ビットストリームに含まれるパケットのタイムスタンプATSとの関係(再生時間に関する関係)を示す情報(PTSの値)を含む「時間関係テーブル(図20(b))」である。
【0542】
あるいは、PTSL(時間関係テーブル)は、PTSの値とATSとの対応関係を示す情報であるとも言える。
【0543】
最後に、各実施の形態の説明中で用いた一部の用語の意味について纏めておく:
*ストリームオブジェクト(SOB)は、記録済みビットストリームのデータを示す。SR_TRANS.SROファイル内には、最大999個のSOBを記録できる。
【0544】
*ストリームオブジェクトユニット(SOBU)は、SOB内にオーガナイズされる基本単位である。つまり、各SOBは、SOBUの連なり(チェーン)からなる。なお、とくに編集後は、SOBの先頭および/または末尾のSOBUは、そのSOBの有効部分に属していないデータを含むことがある。
【0545】
SOBUは、再生時間あるいは再生順序により特徴付けられるのではなく、一定サイズ(32セクタ分のサイズあるいは2ECCブロック分のサイズ)により特徴付けられる。
【0546】
*アクセスユニット(AU)は、個別の再生に適した記録済みビットストリームにおける、任意の単一連続部分を指す。このAUは、MPEGエンコードされたビットストリームにおいては、通常はIピクチャに対応する。
【0547】
*アクセスユニット開始マップ(AUSM)は、該当SOBのどのSOBUがAUを含むのかを示すものである。
【0548】
*アプリケーションパケット(AP)は、記録中にアプリケーションデバイスからやってくるビットストリームの一部である。あるいは、APは、再生中にアプリケーションデバイスへ行くビットストリームの一部である。これらのAPは、多重化トランスポートに含まれ、記録中は一定サイズ(最大64574バイト)を持つ。
【0549】
*アプリケーションタイムスタンプ(ATS)は、各APの前に配置され、32ビット(4バイト)で構成される。ATSは、90kHzの基本部分と27MHzの拡張部分とで構成されている。
【0550】
*セル(あるいはストリームセルSC)は、プログラムの一部を示すデータ構造である。オリジナルPGC内のセルはオリジナルセルと呼ばれ、ユーザ定義PGC内のセルはユーザ定義セルと呼ばれる。プログラムセット中の各プログラムは、少なくとも1つのオリジナルセルからなる。夫々のプレイリスト内のプログラムの各部分は、少なくとも1つのユーザ定義セルからなる。ストリーマにおいて、単にセルという場合は、ストリームセル(SC)のことをいう。各SCは記録済みビットストリームの一部を参照するものである。
【0551】
*セル番号(CN)は、PGC内のセルに割り振られた番号(1〜999)である。
【0552】
*ストリームセルエントリポイント情報(SC_EPI)は、記録の一部をスキップするための道具として用いるもので、任意のストリームセル(SC)内に存在できる。
【0553】
*ストリームオブジェクトの開始アプリケーションパケット到着時間(SOB_S_APAT)は、該当SOBに属する最初のAPの到着時間を指す。この到着時間は、90kHzの基本部分と27MHzの拡張部分とで構成されている。
【0554】
*ストリームオブジェクトの終了アプリケーションパケット到着時間(SOB_E_APAT)は、該当SOBに属する最後のAPの到着時間を指す。
【0555】
*ストリームセルの開始アプリケーションパケット到着時間(SC_S_APAT)は、該当SCに属する最初のAPの到着時間を指す。
【0556】
*ストリームセルの終了アプリケーションパケット到着時間(SC_E_APAT)は、該当SCに属する最後のAPの到着時間を指す。
【0557】
*ナビゲーションデータは、ビットストリーム(SOB)に対する、記録、再生、および編集の制御をする際に用いられるデータである。
【0558】
*プレイリスト(PL)は、ユーザが再生シーケンスを任意に定義できるプログラム部分のリストである。PLは、ユーザ定義PGCとして記述される。
【0559】
*プログラム(PG)は、ユーザにより認識されあるいは定義されるところの、記録内容の論理単位である。プログラムセット内のプログラムは、1以上のオリジナルセルからなる。プログラムは、オリジナルPGC内でのみ定義される。
【0560】
*プログラムチェーン(PGC)は、上位概念的な単位である。オリジナルPGCの場合、PGCはプログラムセットに対応するプログラムの連なり(チェーン)を示すものである。一方、ユーザ定義PGCの場合は、PGCはプレイリストに対応するものであってプログラムの一部の連なり(チェーン)を示すものである。
【0561】
*プログラムチェーン情報(PGCI)は、PGCの全体的な再生を示すデータ構造である。PGCIはオリジナルPGCおよびユーザ定義PGCのいずれでも使用される。ユーザ定義PGCはPGCIだけで構成され、そのセルはオリジナルPGC内のSOBを参照するようになっている。
【0562】
*プログラムチェーン番号(PGCN)は、ユーザ定義PGCに割り振られた連続番号(1〜99)である。
【0563】
*プログラム番号(PGN)は、オリジナルPGC内のプログラムに割り振られた連続番号(1〜99)である。
【0564】
*プログラムセットは、全てのプログラムで構成されるディスク(記録媒体)の記録内容全体を指す。オリジナルの記録に対して再生順序が変わるような編集がどのプログラムに対してもなされていないなら、プログラムセットの再生にあたっては、プログラムの記録順序と同じ再生順序が用いられる。
【0565】
*リアルタイム記録とは、バッファメモリサイズが限られている場合において、制限された転送レートでコード化された任意のストリームデータを制限された転送レートで転送している限り、バッファメモリがオーバーフローすることなく、そのストリームデータをディスク(記録媒体)に記録できるような記録をいう。
【0566】
この発明に係る各実施の形態における効果をまとめると以下のようになる:
1.ストリームデータ内に記録されたタイムスタンプデータ(ATS)とユーザに対する表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブルあるいはPTSL)を管理情報(SFIT)の一部に持たせることにより、高い精度で、ユーザが指定した表示時刻から、再生/画面表示を開始させることが可能となる。
【0567】
2.ユーザは、編集時に、記録済みのストリームデータの部分消去範囲または並び替えの指定範囲を、モニタTV上での表示時刻で指定する。
【0568】
上記「1.」のように、ストリームデータ内に、管理情報(SFIT)の一部として、タイムスタンプデータと表示時刻情報との間の関係を示す時間関係テーブル(あるいはPTSL)を持たせる。これにより、この時間関係テーブル(あるいはPTSL)を用いて、正確に編集点位置(部分消去範囲あるいは並び替えの指定範囲)を設定することが可能となる。その結果、ストリームデータに対する時間管理をタイムスタンプデータ(ATS)を用いて行うことができ、かつユーザリクエストに応じた正確な編集処理を保証できる。
【0569】
3.上記「1.」のように、ストリームデータ内に時間関係テーブル(あるいはPTSL)を持たせてあるので、タイムスタンプデータ(ATS)あるいは表示時刻情報(PTS)のいずれか一方の情報を再生終了位置情報(レジューム情報)として記載するだけで、ストリーマ再起動時の再生開始位置(レジューム再生開始位置)を、正確に設定できる。
【0570】
4.再生終了位置情報(レジューム情報)をタイムスタンプデータ(ATS)で記録することにより、情報記憶媒体上の特定位置にアクセスする場合、タイムマップ情報252を用いてアクセスすべきアドレスを、素早く知ることができる。
【0571】
5.MPEGによる圧縮データは必ずIピクチャからの再生開始が必要となる。各Iピクチャ開始位置(あるいはアクセスユニットAUの開始位置)でのタイムスタンプデータ(ATS)と表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブル)を記録することにより、所望のIピクチャ(所望のAU)へのアクセス制御を、タイムマップ情報252を用いて高速に行える。
【0572】
6.各Iピクチャ開始位置(各AUの開始位置)でのタイムスタンプデータ(ATS)と表示時刻情報(PTSあるいはフィールド情報)との間の関係を示す情報(時間関係テーブル)を記録することにより、タイムマップ情報252との組み合わせで、Iピクチャ(AU)を含むストリームブロック(あるいはSOBU)位置のアドレスが分かる。このため、Iピクチャのみの再生・表示を行うファーストフォワードFFあるいはファーストリバースFRなどの特殊再生処理が可能となる。
【0573】
なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。
【0574】
さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から1または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも1つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。
【0575】
【発明の効果】
以上述べたように、この発明によれば、ストリーム情報記録の処理に関する改善を図ることができる。
【図面の簡単な説明】
【図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装置。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information storage medium for recording video data transmitted by digital broadcasting or the like or stream data transmitted with a packet structure, a data structure of management information relating to stream data recorded on the medium, and recording of the management information Method and playback method.
[0002]
[Prior art]
In recent years, TV broadcasting has entered the era of digital broadcasting. Along with this, there has been a demand for an apparatus for storing digital TV broadcast digital data as it is regardless of the content, so-called streamer.
[0003]
An MPEG transport stream is employed in the currently broadcast digital TV broadcast. In the future, MPEG transport streams will be used as standard in the field of digital broadcasting using moving images.
[0004]
In this digital broadcasting, the content to be broadcast (mainly video information) is time-divided into a set of data of a predetermined size (for example, 188 bytes) called a transport packet, and broadcast data is transmitted for each transport packet. The
[0005]
As a streamer for recording this digital broadcast data, there are digital VCRs for home use such as D-VHS (digital VHS). In the streamer using this D-VHS, the broadcast bit stream is recorded on the tape as it is. Therefore, a plurality of programs are multiplexed and recorded on the video tape.
[0006]
At the time of reproduction, all data is sent as it is from the VCR to a set top box (receiver of digital TV: hereinafter abbreviated as STB) even when reproducing from the beginning or from the middle. In this STB, a desired program is selected from the transmitted data by a user operation or the like. The selected program information is transferred from the STB to a digital TV receiver or the like and played back (playback of video + audio etc.).
[0007]
In this D-VHS streamer, since a tape is used as a recording medium, quick random access cannot be realized, and it is difficult to quickly jump to a desired position of a desired program for reproduction.
[0008]
A streamliner using a large capacity disk medium such as a DVD-RAM can be considered as a promising candidate that can eliminate the drawbacks of such tapes (difficult random access). In that case, when random access and special reproduction are considered, it is inevitably necessary to record management data together with broadcast data.
[0009]
Here, between a STB which is a receiver of a digital TV and a streamer using a large-capacity disk medium such as a DVD-RAM, or a streamer using this large-capacity disk medium and another streamer using D-VHS or the like. A digital interface conforming to IEEE 1394 or the like can be used for data transfer to and from.
[0010]
In this digital interface, video data / stream data is transferred for each transport packet received by digital broadcasting.
[0011]
For example, in a digital interface using IEEE 1394, in order to guarantee real-time transfer of digital broadcast reception data, time stamp data representing reception time is added to each transport packet, and transfer is performed. Yes.
[0012]
In addition, in order to guarantee continuous playback in STB real time with respect to the received data of the digital broadcast recorded on an information storage medium such as a DVD-RAM, together with each transport packet data on the information storage medium The time stamp data is also recorded at the same time.
[0013]
[Problems to be solved by the invention]
In the above case, time stamp data is added and recorded for each transport packet as stream data to be recorded on an information storage medium using a large capacity disk medium such as a DVD-RAM. For this reason, time management is performed using this time stamp data.
[0014]
In digital TV, video data is broadcast in a compressed form using a digital compression method called MPEG2. According to the MPEG2 system, P picture information has only difference information for I pictures, and B picture information has only difference information for I pictures and P pictures. Therefore, a B picture or a P picture cannot be reproduced independently, and reproduction from an I picture is necessary to reproduce these.
[0015]
Here, the video reproduction time viewed from the user indicated by the display time of each picture of I, B, and P is different from the time stamp time. For this reason, when the time management for the stream data recorded on the information storage medium is performed using only the time stamp data, there arises a problem that the display time (video reproduction time) cannot be accurately controlled for the user.
[0016]
The present invention has been made in view of the above circumstances, and an object thereof is to improve the stream information recording process.
[0017]
[Means for Solving the Problems]
An information storage medium according to an embodiment of the present invention has a data area for recording stream data including MPEG-encoded I picture information and including a transport stream, and a management area for recording management information of the stream data. . In this information storage medium, a data packet called a transport packet or an application packet is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and object data called a stream object is expressed as a third data unit. When expressed as a data unit, the stream object of the third data unit configured to include one or more of the second data units including one or more of the first data units is recorded in the data area. Stream data is formed. The data packet group of the first data unit that arrives during recording of the third data unit has header information, and the data packet that arrives during recording of the third data unit has information of packet arrival time. Configured to be time stamped. In addition, the second data unit includes the header information, and the header information includes information regarding the time of the first data unit. Here, as the information about the time of the first data unit, information about the packet arrival time attached to the specific data packet of the data packet group is recorded, or as the information about the time of the first data unit, Information indicating the position of the time stamp of the first data unit is recorded. In addition, the header information including information related to the time is configured to be recorded in the data area different from the management area, and real-time video object data different from the stream data is recorded in the data area. The management information file for managing the stream data including the transport stream and the real-time video object data is stored in a single directory, and the management information includes the stream data Time-related information corresponding to the I picture portion is recorded. .
[0018]
The stream data can be composed of data units of a certain size (for example, 64 kB SOBU).
[0019]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, with reference to the drawings, a stream data storage medium according to an embodiment of the present invention, a data structure of management information related to stream data recorded on the medium, a method for recording and reproducing the management information, and the like will be described. To do.
[0020]
FIG. 1 is a view for explaining the data structure of stream data according to an embodiment of the present invention. The data structure of stream data recorded on the information storage medium will be described with reference to FIG.
[0021]
Stream data (STREAM.VRO) 106 (FIG. 1A) recorded on an information storage medium such as a DVD-RAM disk (FIG. 3 and others 201) is a stream object for each content of video information in the stream data. (Hereinafter abbreviated as SOB as appropriate). That is, each SOB is formed by stream data obtained by one real-time continuous recording.
[0022]
As shown in FIG. 1B, the stream data recorded on the information storage medium is grouped as stream objects (SOB) # A · 298 and # B · 299 for each content of video information in the stream data. It is recorded.
[0023]
FIGS. 1B to 1K show details of one SOB # A · 298 among a plurality of stream objects (SOB # A, #B,...).
[0024]
When the stream data (STREAM.VRO) 106 is recorded on the DVD-RAM disk, each is recorded with a sector of 2048 bytes as a minimum unit. Further, the 16 sectors are combined into one ECC block, and interleaving (rearranging the data arrangement order) and addition of a correction code for error correction are performed within the same ECC block.
[0025]
In this embodiment, a stream block (or stream object unit SOBU) is configured with one or a plurality of (typically two) ECC blocks as a unit, and stream information in stream units (or SOBU units). Recording, partial erasure, editing, etc. are performed.
[0026]
In this embodiment, how many ECC blocks form a stream block can be determined according to the transfer rate of the stream data (STREAM.VRO) 106 to be transferred.
[0027]
For example, in the example of FIGS. 1C and 1D, the
[0028]
Each ECC block is composed of 16 sectors as shown in FIG. Therefore, as can be seen from FIGS. 1C to 1E, the stream block (or SOBU) # 1 composed of 2 ECC blocks corresponds to 32 sectors (sector No. 0 to sector No. 31).
[0029]
That is, if 1 sector = 2 kbytes, the stream block (SOBU) can be implemented with a fixed size of 64 kbytes (32 sectors).
[0030]
The stream data (STREAM.VRO) 106 is recorded on the information storage medium as a set of a time stamp and a transport packet as shown in FIG.
[0031]
At that time,
[0032]
The
[0033]
The
[0034]
In the
[0035]
In the example of FIG. 1G, a case where one transport packet d is recorded across a plurality of sectors (No. 0 and No. 1) is illustrated. Such a transport packet d corresponds to the partial packet of FIG. 22 or FIG.
[0036]
By the way, in digital broadcasting, a multiplexing / demultiplexing system corresponding to a multi-program called a transport stream is adopted, and the size of one transport packet is often 188 bytes (or 183 bytes).
[0037]
On the other hand, as described above, one sector size is 2048 bytes, and even if various header sizes are subtracted, one
[0038]
In the transport packet, as shown in FIG. 1H,
[0039]
In the
[0040]
In the first transport packet in which the I picture
[0041]
As shown in FIG. 1 (j), each piece of
[0042]
Further, in each picture header information 41, as shown in FIG. 1 (k), header identification information 51,
[0043]
In the stream data recorded on the information storage medium, a specific picture position can be identified using the
[0044]
Alternatively, since the PTS information 53 is recorded in the picture header information 41 as shown in FIGS. 1 (j) and (k), the decoder can also start displaying using this value.
[0045]
FIG. 2 is a view for explaining the directory structure of the data file according to the embodiment of the present invention. The contents (file structure) of information recorded on the information storage medium according to the embodiment of the present invention will be described with reference to FIG.
[0046]
Information recorded on an information storage medium such as a DVD-RAM disk has a hierarchical file structure for each piece of information. The video information and stream data information described in this embodiment are contained in a subdirectory 101 named DVD_RTR directory (or DVD_RTAV) 102.
[0047]
In the DVD_RTR (DVD_RTAV) directory 102, a data file 103 having the following contents is stored.
[0048]
That is, as a group of management information (navigation data), RTR. IFO (or VR_MANGR.IFO) 104 and STREAM. IFO (SR_MANGR.IFO / SR_MANGR.BUP) 105 and SR_PRIVT. DAT / SR_PRIVT. BUP 105a is stored.
[0049]
As the data body (content information), the STREAM. VRO (or SR_TRANS.SRO) 106 and RTR_MOV. VRO (VR_MOVIE.VRO) 107 and RTR_STO. VRO (or VR_STILL.VRO) 108 and RTR_STA. VRO (or VR_AUDIO.VRO) 109 is stored.
[0050]
The root directory 100 in the upper hierarchy of the subdirectory 101 including the data file 103 can be provided with a subdirectory 110 for storing other information.
[0051]
The contents of this subdirectory include a video title set VIDEO_TS111 containing a video program, an audio title set AUDIO_TS112 containing an audio program, a subdirectory 113 for storing computer data, and the like.
[0052]
Data recorded in an information storage medium while retaining the packet structure with respect to data transmitted in the form of a packet structure on a wired or wireless data communication path is referred to as “stream data”.
[0053]
The stream data itself is STREAM. A file name VRO (or SR_TRANS.SRO) 106 is recorded together. A file in which management information for the stream data is recorded is STREAM. IFO (or SR_MANGR.IFO and its backup file SR_MANGR.BUP) 105.
[0054]
A file recorded by digitally compressing analog video information handled by a VCR (VTR) or a conventional TV based on the MPEG2 standard is RTR_MOV. VRO (or VR_MOVIE.VRO) 107, and a file that collects still image information including after-recording audio or background audio is RTR_STO.VRO. VRO (or VR_STILL.VRO) 108, and the post-record audio information file is RTR_STA.VRO. VRO (or VR_AUDIO.VRO) 109.
[0055]
FIG. 3 is a view for explaining the recording data structure (particularly the structure of management information) on the information medium (DVD recording / reproducing disc) according to the embodiment of the present invention.
[0056]
As shown in FIG. 3 (b), the area between the end portion in the inner peripheral direction 202 and the end portion in the outer peripheral direction 203 of the
[0057]
In the data area 207, as shown in FIG. 3C, computer data and audio & video data can be recorded together. In this example, an audio & video data area 210 is sandwiched between a
[0058]
In the audio & video data area 210, a real time video recording area 221 and a stream recording area 222 can be mixedly recorded as shown in FIG. (It is also possible to use only one of the real-time video recording area 221 and the stream recording area 222.)
As shown in FIG. 3 (e), the real-time video recording area 221 includes the RTR navigation data RTR. IFO (VR_MANGR.IFO) 104 and movie real-time video object RTR_MOV. VRO (VR_MOVIE.VRO) 107 and a still picture real-time video object RTR_STO. VRO (VR_STILL.VRO) 108 and an audio object RTR_STA. VRO (VR_AUDIO.VRO) 109 is recorded.
[0059]
Similarly, as shown in FIG. 3E, the stream recording area 222 has streamer navigation data STREAM. IFO (SR_MANGR.IFO / SR_MANGR.BUP) 105 and transport bit stream data STREAM. VRO (SR_TRANS.VRO) 106 is recorded.
[0060]
Although not shown in FIGS. 3D and 3E, the stream recording area 222 includes application-specific navigation data SR_PRIVT, DAT / SR_PRIVT. The BUP 105a can also be recorded.
[0061]
This SR_PRIVT, DAT 105a is navigation data unique to each application connected (supplied) to the streamer, and is data that does not need to be recognized by the streamer.
[0062]
STREAM., Which is management information related to stream data. The IFO (or SR_MANGR.IFO) 105 has a data structure as shown in FIGS.
[0063]
That is, as shown in FIG. The IFO (or SR_MANGR.IFO) 105 includes a video manager (VMGI or STR_VMGI) 231, a stream file information table (SFIT) 232, original PGC information (ORG_PGCI) 233, a user-defined PGC information table (UD_PGCIT) 234, A text data manager (TXTDT_MG) 235 and a manufacturer information table (MNFIT) or application-specific navigation data SR_PRIVT. It comprises an application private data manager (APDT_MG) 236 that manages the DAT 105a.
[0064]
As shown in FIG. 3G, the stream file information table (SFIT) 232 in FIG. 3F includes stream file information table information (SFITI) 241 and one or more stream object information (SOBI) # A · 242. , # B · 243,..., Original PGC information
[0065]
Each stream object information (for example, SOBI # A · 242) in FIG. 3G can include stream object general information (SOBI_GI) 251,
[0066]
Further, each original cell information (for example, # 1 and 272; corresponding to SCI shown in FIG. 14 which will be described later) in FIG. 3G is the cell type 281 (which will be described later) as shown in FIG. 14 corresponds to C_TY shown in FIG. 14,
[0067]
Here, the PTS offset 9 refers to a difference between the PTS (presentation time stamp) value of the display start picture of the original cell (details of the original cell will be described later) and the PTS value of the I picture immediately before (see details) This will be described later with reference to FIG.
[0068]
The
[0069]
FIG. 4 is a diagram for explaining the relationship among stream objects (SOB), cells, program chains (PGC), and the like according to an embodiment of the present invention. Hereinafter, the relationship between SOB and PGC will be described with reference to the example of FIG.
[0070]
Stream data recorded in the stream data (STREAM.VRO or SR_TRANS.SRO) 106 constitutes a stream block as a collection of one or more ECC blocks, and recording, partial erasure processing, etc. are performed in units of this stream block. . This stream data creates a group called a stream object for each content of information to be recorded (for example, for each program in digital broadcasting).
[0071]
STREAM. Management information (
[0072]
The management information (STREAM.IFO 105) for each stream object # A · 298, # B · 299 in FIG. 4 is the stream in the stream file information table (SFIT) 232 as shown in FIGS. Object information (SOBI) # A.242 and # B.243 are recorded.
[0073]
Each of the stream object information (SOBI) # A • 242 and (SOBI) # B • 243 includes
[0074]
When reproducing stream data, program chain (PGC) information (corresponding to PGCI # i in FIG. 14 described later) composed of a series of one or more cells is used. Stream data can be reproduced according to the setting order of the cells constituting the PGC.
[0075]
PGC includes STREAM. An original PGC 290 (
[0076]
[0077]
On the other hand, user-defined
[0078]
Although the sector size of each stream block can be set variously, as a preferred embodiment, a stream of a fixed size (64 kbytes) is composed of 2 ECC blocks (32 sectors) as in
[0079]
If the stream block is fixed to the SOBU of a certain size (for example, 2 ECC block = 32 sectors = 64 kbytes) in this way, the following advantages are obtained:
(01) Even when stream data is erased or rewritten in units of SOBU, the ECC block of the SOBU does not affect the ECC block of SOBUs other than those to be erased or rewritten. Therefore, there is no ECC deinterleaving / releaving (for SOBU that is not subject to erasure or rewriting) associated with erasure or rewriting;
(02) An access position for recording information in an arbitrary SOBU can be specified by the number of sectors (or other parameters corresponding to the number of sectors; for example, information on a stream pack and an application packet group in FIG. 10 described later). For example, when accessing an intermediate position of a certain SOBU # k, the 16th sector (or the position of the application packet corresponding to the 16th sector) from the boundary between SOBU # k-1 and SOBU # k may be specified.
[0080]
FIG. 5 is a diagram for explaining the contents of the stream block size and the stream block time difference in the time map information. Hereinafter, the contents of each data in the
[0081]
As illustrated in FIGS. 5F, 5G, and 5H, the stream object (SOB) # A · 298 is composed of two
[0082]
In the examples of FIGS. 5F and 5H, the data size of the
[0083]
The stream block # 1 (FIG. 5 (f)) at the head of SOB # A.298 (FIG. 5 (g)) has a sector No. 0 (FIG. 5 (e)) and sector no. A time stamp a (FIG. 5C) is recorded at the head of the
[0084]
The succeeding stream block # 2 (FIG. 5 (f)) of SOB # A.298 (FIG. 5 (g)) has a sector No. 32 (FIG. 5 (e)) and sector no. 32, a time stamp p (FIG. 5C) is recorded at the head of the data area 311 included in FIG.
[0085]
As shown in FIG. 5C, the time stamp value of the first stream data of the
[0086]
The value of the first stream
[0087]
Note that the
[0088]
FIG. 6 is a diagram for explaining a cell range designation method in the original cell and the user-defined cell. Each cell range can be specified by specifying the start time and end time.
[0089]
Specifically, as the time of the
[0090]
On the other hand, the time range designation in the user-defined
[0091]
FIG. 6F illustrates a case where the stream object (SOB) # A · 298 is composed of two
[0092]
6E and 6G, the
[0093]
The first sector number of
[0094]
Also, the rear sector No. of
[0095]
Further, the sector number of FIG. 1 is recorded with a
[0096]
In the
[0097]
Further, the area of the
[0098]
Further, the
[0099]
The first half (
[0100]
Further, in the data area 312 of FIG. 6 (h), as shown in FIG. 6 (i), a pair of the time stamp n and the transport packet n and other similar pairs are recorded.
[0101]
Here, the start time 331 (FIG. 6 (j)) of the cell corresponding to the location where the user or the like has specified the playback start time is the time stamp d for the entire two transport packets d divided into the
[0102]
When the transport packet is read as an application packet (AP) and the application packet arrival time is APAT, the cell start time 331 can be expressed as a cell start APAT.
[0103]
Further, the end time 332 (FIG. 6 (j)) of the cell corresponding to the location where the user or the like has specified the playback end time is specified by the time stamp n (FIG. 6 (i)) for the transport packet n in the data area 312. Is done. This cell end time 332 can be expressed as cell end APAT.
[0104]
The cell start time (cell start APAT) 331 and cell end time (cell end APAT) 332 can be recorded in the user-defined
[0105]
The user-defined
[0106]
The above is cell start / end time information related to user-defined cell information (user-defined PGC information), but cell start / end time information related to original cell information (original cell information) is exemplified as follows. it can.
[0107]
That is, the
[0108]
The
[0109]
Further, the end time 284 of the corresponding cell in FIG. 6B can correspond to cell end APAT (including stream cell end APAT (SC_E_APAT) or erasure end APAT (ERA_E_APAT)).
[0110]
The above cell start time (cell start APAT) 283 and cell end time (cell end APAT) 284 are recorded in the original
[0111]
The original
[0112]
FIG. 7 illustrates the recording data structure (particularly the structure of reproduction end position information / resume information, VMGI management information / recording time information, etc.) on an information medium (DVD recording / reproducing disc) according to another embodiment of the present invention. It is a figure to do.
[0113]
Since the data configuration of FIGS. 7A to 7F is the same as that of FIGS. 3A to 3F, description thereof will be omitted.
[0114]
The video manager (STR_VMGI) 231 in FIG. 7F includes reproduction end position information (resume information) 6110, video manager management information (VMGI_MAT) 6111 and others, as shown in FIG.
[0115]
The reproduction end position information (resume information) 6110 includes original PGC number 6210, original cell number 6220, reproduction end position time (resume time) information 6230, and the like, as shown in FIG. 7 (h).
[0116]
The video manager management information (VMGI_MAT) 6111 includes a time zone (TM_ZONE) 6240.
[0117]
At the stage where the reproduction of the recorded stream block (or original cell) is completed, the reproduction end position information 6110 is used as resume information in the
[0118]
The time information 6230 included in the reproduction end position information 6110 is recorded as a time stamp (ATS) value. However, the time information 6230 is not limited thereto, and the PTS value (or the total number of fields from the cell reproduction start position) is recorded as the time information 6230. You can also
[0119]
The time zone (TM_ZONE) 6240 includes information on the recording time (REC_TM) as shown in FIG.
[0120]
The recording time (REC_TM) information includes a time zone type (TZ_TY) that identifies whether the REC_TM is due to Universal Time Coordinate (UTC) or a specific local time, and the time offset of the REC_TM from the UTC. And a time zone offset (TZ_OFFSET) that describes the date and time in minutes.
[0121]
The recording time (REC_TM) may be described in the cell start time (SC_S_APAT) format shown in FIG. 6B or the like, or the cell playback time (presentation time PTM) format.
[0122]
There are two types of recording time (REC_TM). The first is the stream object recording time (SOB_REC_TM), and the second is the playlist creation time (PL_CREATE_TM).
[0123]
Here, the time when the stream object (SOB) corresponding to the original cell was recorded is indicated by SOB_REC_TM.
[0124]
A playlist is a partial list of programs. This playlist allows the user to define any playback sequence (relative to the program content). The time when such a playlist is created is indicated by PL_CREATE_TM.
[0125]
FIG. 8 is a diagram for explaining the internal structure of the PES header shown in FIG. 1 and others.
[0126]
As shown in FIG. 8B, the PES header 601 in FIG. 8A includes a packet start code prefix 602, a
[0127]
Also, the stream PES header of FIG. 8D includes a packet start code prefix, a stream ID (private stream 2), a PES packet length, a substream ID, and the like, as shown in FIG. 8C. This stream PES header is the same as the stream PES header of FIG. 22 described later, and has contents corresponding to the PES header 601 of FIG.
[0128]
When the PES header in FIG. 1 (f) has the internal structure of the PES header 601 shown in FIG. 8 (a), in the MPEG standard, the stream ID 603 (FIG. 8 (b)) of this PES header is “10111110”. Sometimes, it is defined that a packet having this PES header is a padding packet (see FIG. 12G described later).
[0129]
On the other hand, when the stream ID 603 (substream ID in FIG. 8C) is “00000010”, the packet with the PES packet includes stream recording data.
[0130]
In the
[0131]
FIG. 9 is a diagram for explaining the internal structure of the stream block header shown in FIG.
[0132]
As shown in FIG. 9A, the
[0133]
In the 1-byte application header extension (option), 1-bit AU_START, 1-bit AU_END, and 2-bit COPYRIGHT are described.
[0134]
When AU_START is set to “1”, it indicates that the associated application packet (eg, AP in FIG. 29) includes a random access entry point (start of random access unit) in the stream.
[0135]
When AU_END is set to “1”, it indicates that the associated application packet is the final packet of the random access unit.
[0136]
COPYRIGHT describes the copyright status of the related application packet.
[0137]
As shown in FIG. 9B, the
[0138]
The transport packet information 611 in FIG. 9B indicates the same as the transport packet information 611 in FIG. 9C.
[0139]
The stream block information 612 in FIG. 9B, in which information about the entire stream block is recorded, is the recording time 622 (date and time information recorded in the information storage medium 201) in FIG. It corresponds to an attribute 623 (attribute information related to the transport packet), a stream block size 624 (data size of the corresponding stream block (for example, can be described by the number of ECC blocks)), a stream
[0140]
Here, taking FIG. 5B as an example, the time range information in the corresponding stream block is [stream block time difference] = [first time stamp value in stream block # 2] − [time stamp a Value]. This [stream block time difference] becomes the stream
[0141]
Also, the sector data header information 613 in FIG. 9B corresponds to the first access point 626 and the transport
[0142]
The transport packet information 611 in FIG. 9C includes the number of transport packets (the number of application packets) 631, the transport packet mapping table 632, and the like, as shown in FIG. 9D.
[0143]
Note that the number of application packets in FIG. 9D corresponds to the number of packets AP_Ns in FIG.
[0144]
The number 631 of transport packets (application packets) in FIG. 9D can include an I picture mapping table 641, a B, P picture mapping table 642, etc., as shown in FIG. 9E.
[0145]
Also, the transport packet mapping table 632 in FIG. 9D can include a video packet mapping table 643, an audio packet mapping table 644, a program specific information mapping table 645, and the like.
[0146]
Each mapping table (FIG. 9E) in the transport packet mapping table 632 is configured in a bitmap format.
[0147]
For example, when n transport packets (application packets) are recorded in one stream block, the value of the number of transport packets (number of application packets) 631 in FIG. 9D is “n”. It becomes.
[0148]
Further, each mapping table 643 to 645 is composed of “n-bit data”, and one bit is assigned to each transport packet (application packet) arranged in the stream block from the front.
[0149]
FIG. 10 is a diagram for explaining the internal structure of the sector data header shown in FIG.
[0150]
For example, the
[0151]
The
[0152]
By the way, as shown in FIG. 10D, one stream pack having a size of 2048 bytes as well as one sector is composed of a pack header and a stream PES header. In this stream PES packet, an application packet header corresponding to a part of the
[0153]
The application packet header includes the following as shown in FIG. 10 (c):
* Application packet header format version description;
* Number of application packets (transport packets) that start in the corresponding stream pack AP_Ns;
* First application packet time stamp position FIRST_AP_OFFSET describing the position of the time stamp of the first application packet starting in the stream pack as a relative value from the first byte of the stream pack;
* Extension header information EXTENSION_HEADER_IFO indicating whether a header extension and / or stuffing byte is present;
* Service identifier of the service that generated the corresponding stream.
[0154]
The FIRST_AP_OFFSET included in the application packet in FIG. 10D corresponds to the
[0155]
As shown in FIG. 1G, the transport packet d is recorded across two sectors. Here, when the last time stamp in the sector or the transport packet straddles the next sector, the transport packet connection flag 652 is set to “1”.
[0156]
In the example of FIG. 1G, the address in the
[0157]
Sector No. 1 shown in FIG. 1 (or the corresponding stream pack) is assigned the sector No. A value larger than the size of one data area 22 (FIG. 1 (f)) can be set. By doing so, sector no. It is shown that the position of the time stamp corresponding to the packet next to the packet recorded in 1 exists in the next and subsequent sectors.
[0158]
In one embodiment of the present invention, a value larger than the size of the
[0159]
For example, in the data structure of FIG. 0 to sector no. It is assumed that the recording has been performed up to two. Further, the time stamp for the packet is sector no. 0 is recorded at the first position in the
[0160]
In this case, sector no. The value of the first access point of “0” is “0” and the sector No. The value of the first access point of “1” is “
[0161]
FIG. 11 is a diagram illustrating another example of the
[0162]
This
[0163]
Assume that the total number of transport packets (or the total number of application packets AP_Ns) is designated to access a predetermined screen (picture) using the
[0164]
FIG. 12 is a diagram for explaining an example of the internal configuration of a sector constituting a stream block (SOBU) (a stream pack including an application packet and a stream pack including a stuffing packet).
[0165]
As shown in FIGS. 12C and 12E, the stream object (SOB) # A · 298 in FIG. 12D is composed of a plurality of
[0166]
Each
[0167]
In this way, for example, even if stream block (SOBU) # 2 is deleted, the ECC block of stream block (SOBU) # 1 is not affected by this deletion.
[0168]
As shown in FIG. 12B, the first stream block (SOBU) # 1 of SOB # A. 0 to sector no. 31 (32 sectors / 64 kbytes).
[0169]
Each sector of the stream block (SOBU) # 1 has a similar data structure. For example, sector no. As for 0, it is as shown in FIG.
[0170]
That is, sector no. 0 is composed of a stream pack of 2048 bytes (2 kbytes). This stream pack is composed of a 14-byte pack header and a 2034-byte stream PES packet.
[0171]
The stream PES packet is composed of a 6-byte PES header, a 1-byte substream ID, and a 2027-byte stream data area.
[0172]
The stream data area includes a 9-byte application header, an application header extension (option), a stuffing byte (option), and an application packet area.
[0173]
The application packet area is composed of a group of application packets each having an application time stamp (ATS) at the head.
[0174]
For example, when a transport packet having a size of 188 bytes is stored in the application packet area as an application packet, about 10 application packets can be stored in the application packet area.
[0175]
In stream recording, an application that generates recording contents performs stuffing by itself so that it is not necessary to separately adjust the pack length. For this reason, in stream recording, a stream pack can always be handled as having a required length (for example, 2048 bytes).
[0176]
The stuffing byte of FIG. 12A can be used to always keep the stream pack at a predetermined length (2048 bytes).
[0177]
Although not shown, the pack header in FIG. 12A includes pack start code information, SCR base information, SCR extension information, program maximum rate information, marker bits, pack stuffing length information, and the like.
[0178]
The SCR base is composed of 32 bits, and the 32nd bit is set to zero. Further, 10.08 Mbps is adopted as the program maximum rate.
[0179]
The PES header and substream ID shown in FIG. 12A have the contents shown in FIG.
[0180]
As shown in FIG. 10C, the application header in FIG. 12A includes version information, the number of application packets AP_Ns, the time stamp position FIRST_AP_OFFSET of the first application packet, extension header information EXTENSION_HEADER_IFO, a service ID, and the like. .
[0181]
Here, the version describes the version number of the application header format.
[0182]
AP_Ns in the application header describes the number of application packets that start in the corresponding stream pack. When the first byte of ATS is stored in the corresponding stream pack, it can be considered that the application packet starts in this stream pack.
[0183]
In FIRST_AP_OFFSET, the time stamp position of the first application packet started in the corresponding stream packet is described in byte units as a relative value from the first byte of this stream packet. If there is no application packet to start in the stream packet, “0” is described in FIRST_AP_OFFSET.
[0184]
EXTENSION_HEADER_INFO describes whether an application header extension and / or stuffing byte is present in the corresponding stream packet.
[0185]
When the content of EXTENSION_HEADER_INFO is 00b, it indicates that neither an application header extension nor a stuffing byte exists after the application header.
[0186]
When the content of EXTENSION_HEADER_INFO is 10b, it indicates that there is an application header extension after the application header, but there is no stuffing byte.
[0187]
When the content of EXTENSION_HEADER_INFO is 11b, it is indicated that an application header extension exists after the application header, and a stuffing byte also exists after the application header extension.
[0188]
It is prohibited for the content of EXTENSION_HEADER_INFO to be 01b.
[0189]
The stuffing byte (option) in front of the application packet area is activated by “EXTENSION_HEADER_INFO = 11b”. By doing so, it is possible to prevent a “packing paradox” from occurring when there is a contradiction between the number of bytes in the application header extension and the number of application packets that can be stored in the application packet area.
[0190]
SERVICE_ID describes the ID of the service that generates the stream. If this service is unknown, 0x0000 is described in SERVICE_ID.
[0191]
The application packet area in FIG. 12A can be configured in the same manner as shown in the lower part of FIG. 22 described later (the packet in FIG. 22 is replaced with the application packet in FIG. 12).
[0192]
That is, a partial application packet is recorded at the beginning of the application packet area, and thereafter, a plurality of pairs of application time stamp ATS and application packet are sequentially recorded, and a partial application packet is recorded at the end.
[0193]
In other words, a partial application packet can exist at the start position of the application packet area. At the end position of the application packet area, a partial application packet or a reserved stuffing area can exist.
[0194]
An application time stamp (ATS) arranged in front of each application packet is composed of 32 bits (4 bytes). This ATS is divided into two parts: a basic part and an extended part. The basic part is a part called 90 kHz unit value, and the extended part shows a less significant value measured at 27 MHz.
[0195]
In FIG. 12A, the application header extension can be used to store information that may differ between application packets and application packets. Such information is not necessary for all applications.
[0196]
Therefore, the data field of the application header is defined so as to describe (in the above-described EXTENSION_HEADER_INFO) that an optional application header extension exists in the stream data area.
[0197]
At the time of recording the stream, the first byte of the application time stamp ATS of the first application packet needs to be aligned with the start position of the application packet area in the first stream packet at the beginning of the stream object SOB.
[0198]
On the other hand, for subsequent stream packets in the SOB, application packets may be divided (split) at adjacent stream packet boundaries.
[0199]
The partial application packet shown in FIG. 22 or FIGS. 23 (f) and 23 (g) described later indicates an application packet generated by this division (split).
[0200]
The byte offset of the first application timestamp that starts in the stream packet and the number of application packets that start in the stream packet are described in the application header.
[0201]
By doing so, stuffing before the first application time stamp and after the last application packet is automatically performed in a stream packet.
[0202]
That is, “the application performs stuffing by itself” is realized by the automatic mechanism. This automatic stuffing ensures that the stream packet always has the required length.
[0203]
The application header extension (optional) consists of a list of entries. Here, there is one entry of 1 byte length for each application packet starting in the corresponding stream packet. The bytes of these entries can be used to store information that can vary from application packet to application packet.
[0204]
The 1-byte application header extension (option) describes 1-bit AU_START, 1-bit AU_END, and 2-bit COPYRIGHT.
[0205]
When AU_START is set to “1”, it indicates that the associated application packet includes a random access entry point (start of random access unit) in the stream.
[0206]
When AU_END is set to “1”, it indicates that the associated application packet is the final packet of the random access unit.
[0207]
COPYRIGHT describes the copyright status of the related application packet.
[0208]
The packet structure of FIG. 12A can be applied to other than the last sector of SOB # A · 298, but is not necessarily applied to the last sector.
[0209]
For example, the end of SOB # A.298 is the sector number of FIG. When this sector is composed of the padding packet 40 as shown in FIG. 12 (g), the contents of the padding area 38 (FIG. 12 (h)) are different from those in FIG. 12 (a). become.
[0210]
That is, as shown in FIG. 12 (i), the stuffing packet as the padding packet 40 includes a 14-byte pack header, a 6-byte PES header, a 1-byte substream ID, a 9-byte application header, It consists of a 2018-byte application packet area.
[0211]
In the pack including the head of the stuffing packet, the application packet area is composed of a 4-byte application time stamp ATS and zero-byte data for 2014 bytes (data having no substantial recording content).
[0212]
On the other hand, in the pack including the subsequent stuffing packet, the application packet area is composed of 2018 byte zero byte data (no ATS).
[0213]
By the way, when recording is performed at a very low bit rate, stuffing is necessary to ensure recovery (reproduction) of time map information (252 in FIG. 3H; or MAPL in SOBI in FIG. 15 described later). become. The stuffing packet in FIG. 12 (i) is defined as a conceptual unit for that purpose.
[0214]
The purpose of this stuffing packet is achieved by ensuring that each SOBU, including the stuffing area, contains at least one ATS value.
[0215]
Stuffing packets have the following conditions:
* One or more stuffing packets always start from the application packet area of the pack after the pack containing the actual application packet data;
* One or more stuffing packets are composed of one 4-byte ATS and as many zero-byte data (following ATS) as are necessary to fill the application data area of the remaining pack of the SOBU. Now, assuming that the number of sectors per SOBU is SOBU_SIZ, if 0 ≦ n ≦ SOBU_SIZ−1, the total length of the stuffing packet is “4 + 2014 + n × 2018” bytes.
[0216]
The ATS of the stuffing packet is set as follows:
* In an SOBU where at least one pack contains actual application packet data, the ATS of the stuffing packet is set to the ATS of the application packet preceding the stuffing packet;
* In an SOBU that does not include actual application packet data, the ATS of the stuffing packet is determined according to the contents of time map information and the like.
[0217]
All packs that contain stuffing packets or parts of stuffing packets are structured as follows:
* The SCR of the pack header is obtained by adding “2048 × 8 bits ÷ 10.08 Mbps” to the SCR of the preceding pack;
* The PES packet header and substream ID are the same as for all other PES packets;
* In the application header (see FIGS. 10C and 10D), AP_Ns = 0, FIRST_AP_OFFSET = 0, EXTENSION_HEADER_IFO = 00b, and SERVICE_ID = 0 (other parameters in the application header are also 0).
[0218]
13 is a diagram for explaining an internal data structure of streamer management information (corresponding to STREAM.IFO or SR_MANGR.IFO in FIG. 2).
[0219]
The management information (navigation data) shown in FIG. 2 or FIG. The IFO (SR_MANGR.IFO) 105 includes streamer information STRI as shown in FIG.
[0220]
As shown in FIG. 3 (f) or FIG. 13, this streamer information STRI includes streamer video manager information STR_VMGI, stream file information table SFIT, original PGC information ORG_PGCI (more generally, PGC information PGCI # i ), A user-defined PGC information table UD_PGCIT, a text data manager TXTDT_MG, and an application private data manager APDT_MG.
[0221]
As shown in FIG. 13, the streamer video manager information STR_VMGI includes video manager information management information VTSI_MAT in which management information about STR and STR_VMGI is described, and a play in which a search pointer for searching a playlist in the stream is described. A list search pointer table (PL_SRPT).
[0222]
Here, the play list is a list of a part of the program. This playlist allows the user to define any playback sequence (relative to the program content).
[0223]
The stream file information table SFIT includes all navigation data directly related to the streamer operation. Details of the stream file information table SFIT will be described later with reference to FIG.
[0224]
The original PGC information ORG_PGCI is a part describing information related to the original PGC (ORG_PGC). ORG_PGC indicates navigation data describing a program set. ORG_PGC is a series (chain) of programs, and includes stream data recorded in the “.SRO” file (
[0225]
Here, the program set indicates the entire recorded contents (all programs) of the
[0226]
A program is a logical unit of recorded content that is recognized by a user or defined by a user. A program in the program set is composed of one or more original cells. The program is defined only in the original PGC.
[0227]
Furthermore, the cell is a data structure indicating a part of the program. The cells in the original PGC are called “original cells”, and the cells in the user-defined PGC described later are called “user-defined cells”.
[0228]
Each program in the program set consists of at least one original cell. In addition, each part of the program in each playlist is composed of at least one user-defined cell.
[0229]
On the other hand, in the streamer, only the stream cell (SC) is defined. Each stream cell refers to a part of the recorded bit stream. In the embodiment of the present invention, “cell” means “stream cell” unless otherwise specified.
[0230]
Note that the program chain (PGC) represents a superordinate conceptual unit. In the original PGC, the PGC indicates a chain of programs corresponding to the program set. In the user-defined PGC, the PGC indicates a series (chain) of a part of the program corresponding to the playlist.
[0231]
In addition, the user-defined PGC that points to a part of the program chain includes only navigation data. A part of each program refers to stream data belonging to the original PGC.
[0232]
The user-defined PGC information table UD_PGCIT in FIG. 13 may include user-defined PGC information table information UD_PGCITI, one or more user-defined PGC search pointers UD_PGC_SRP # n, and one or more user-defined PGC information UD_PGCI # n.
[0233]
Although not shown, the user-defined PGC information table information UD_PGCITI includes UD_PGC_SRP_Ns indicating the number of user-defined PGC search pointers UD_PGC_SRP and UD_PGCIT_EA indicating the end address of the user-defined PGC information table UD_PGCIT.
[0234]
The number of UD_PGC_SRPs indicated by UD_PGC_SRP_Ns is the same as the number of user-defined PGC information (UD_PGCI) and the same as the number of user-defined PGCs (UD_PGC). This number is allowed up to a maximum of “99”.
[0235]
UD_PGCIT_EA describes the end address of the corresponding UD_PGCIT by the relative number of bytes (F_RBN) from the first byte of the UD_PGCIT.
[0236]
Here, F_RBN indicates the relative number of bytes from the first byte of the defined field in the file, and starts from zero.
[0237]
PGCI # i that generally represents the original PGC information ORG_PGCI or the user-defined PGC information UD_PGCI in the user-defined PGC information table UD_PGCIT will be described later with reference to FIG.
[0238]
The text data manager TXTDT_MG in FIG. 13 is supplementary text information. This TXTDT_MG can be stored in the playlist and program together with the primary text information PRM_TXTI of FIG.
[0239]
The application private data manager APDT_M of FIG. 13 may include application private data manager general information APDT_GI, one or more APDT search pointers APDT_SRP # n, and one or more APDT areas APADTA # n, which are not shown.
[0240]
Here, the application private data APDT is a conceptual area where an application device connected to the streamer can store arbitrary non-real time information (information desired in addition to the real time stream data).
[0241]
FIG. 14 is a diagram illustrating an internal data structure of PGC information (ORG_PGCI / UD_PGCIT in FIG. 3 or PGCI # i in FIG. 13).
[0242]
The PGC information PGCI # i in FIG. 14 generally represents the original PGC information ORG_PGCI in FIG. 13 or the user-defined PGC information UD_PGCI in the user-defined PGC information table UD_PGCIT.
[0243]
As shown in FIG. 14, PGC information PGCI # i includes PGC general information PGC_GI, one or more program information PGI # m, one or more stream cell information search pointers SCI_SRP # n, and one or more stream cell information SCI. #N.
[0244]
The PGC general information PGC_GI includes the number of programs PG_Ns and the number of stream cell information search pointers SCI_SRP SCI_SRP_Ns.
[0245]
Each program information PGI (for example, PGI # 1) includes a program type PG_TY, the number C_Ns of cells in the program, primary text information PRM_TXTI of the program, and an item text search pointer number IT_TXT_SRPN.
[0246]
Here, the program type PG_TY includes information indicating the state of the corresponding program. In particular, a flag indicating whether or not the program is protected from erroneous erasure, that is, a protect flag is included.
[0247]
When the protect flag is “0b”, the corresponding program is not protected, and when it is “1b”, it is in a protected state.
[0248]
The number of cells C_Ns indicates the number of cells in the program. Throughout all PGC programs and all cells, cells are associated (implicitly) with the program according to their ascending order.
[0249]
For example, if the
[0250]
The primary text information PRM_TXTI describes text information having one common character set (ISO / IEC646: 1983 (ASCII code)) so that the information storage medium (DVD-RAM disk) 201 can be used all over the world. It is what.
[0251]
The item text search pointer number IT_TXT_SRPN describes the search pointer number for the item text (text data corresponding to the corresponding program) IT_TXT. When the corresponding program has no item text, IT_TXT_SRPN is set to “0000h”.
[0252]
Each stream cell information search pointer SCI_SRP (for example, SCI_SRP # 1) includes SCI_SA indicating the start address of the corresponding stream cell information SCI. This SCI_SA is described by the relative number of bytes (F_RBN) from the first byte of PGCI.
[0253]
Each stream cell information SCI (for example, SCI # 1) includes stream cell general information SC_GI and one or more stream cell entry point information SC_EPI # n.
[0254]
The stream cell general information SC_GI includes a cell type C_TY including a flag TE indicating a temporary erase (temporary erase; TE) state, the number SC_EPI_Ns of stream cell entry point information, a stream object number SOB_N, a stream cell start APAT (FIG. 6 SC_S_APAT shown in others, stream cell end APAT (SC_E_APAT shown in FIG. 6 others), and erase start APAT indicating the start APAT of the temporary erase cell when the cell is in the temporary erase state (TE = 10b) (ERA_S_APAT shown in FIG. 6 and others) and erase end APAT (ERA_E_APAT shown in FIG. 6 and others) indicating the end APAT of the temporary erase cell when the cell is in the temporary erase state (TE = 10b) Yes.
[0255]
The cell type C_TY describes the format of the corresponding stream cell and its temporary erase state.
[0256]
That is, the cell format C_TY1 = “010b” is described in the format of all stream cells (the C_TY1 = “010b” can distinguish the stream cell from the other cells).
[0257]
On the other hand, if the flag TE is “00b”, it indicates that the corresponding cell is in a normal state, and if the flag TE is “01b” or “10b”, it indicates that the corresponding cell is in a temporary erase state. .
[0258]
The flag TE = “01b” indicates a case where the corresponding cell (a cell in the temporarily erased state) starts after the first application packet that starts in the SOBU and ends before the last application packet in the same SOBU. .
[0259]
The flag TE = “10b” indicates a case where the corresponding cell (a cell in the temporarily erased state) includes at least one SOBU boundary (the first application packet or the last application packet starts within the SOBU).
[0260]
Note that the protect flag of the program and the TE flag of the cells in the program cannot be set at the same time. therefore,
(A) None of the cells in the program in the protected state can be set to the temporary erase state;
(B) A program including one or more cells in the temporary erase state cannot be set to the protected state.
[0261]
The number of stream cell entry point information SC_EPI_Ns describes the number of stream cell entry point information included in the corresponding stream cell information SCI.
[0262]
Each stream cell entry point information SC_EPI (for example, SC_EPI # 1) in FIG. 14 has two types (type A and type B).
[0263]
Type A SC_EPI includes an entry point type EP_TY and an entry point application packet arrival time EP_APAT. Type A is indicated by entry point type EP_TY1 = “00b”.
[0264]
Type B SC_EPI includes primary text information PRM_TXTI in addition to type A EP_TY and EP_APAT. Type B is indicated by entry point type EP_TY1 = “01b”.
[0265]
In any stream cell, an entry point can be used as a tool for skipping a part of the recorded contents. All entry points can be identified by application packet arrival time (APAT). With this APAT, it can be specified where data output is started.
[0266]
The stream object number SOB_N describes the number of the SOB referred to by the corresponding cell.
[0267]
Stream cell start APAT (SC_S_APAT) describes the start APAT of the cell.
[0268]
Stream cell end APAT (SC_E_APAT) describes the end APAT of the cell.
[0269]
The erase start APAT (ERA_S_APAT) is the first start in the first SOBU including the head of the temporary erase cell in the temporary erase cell (the TE field of the C_TY is “10b”) including at least one SOBU boundary. It describes the arrival time (APAT) of the application packet.
[0270]
The erase end APAT (ERA_E_APAT) is the first start in the SOBU containing the application packet immediately following the temporary erase cell in the temporary erase cell (the TE field of its C_TY is “10b”) including at least one SOBU boundary. It describes the arrival time (APAT) of the application packet.
[0271]
FIG. 15 is a diagram for explaining the internal data structure of the stream file information table (SFIT).
[0272]
As shown in FIG. 15, the stream file information table SFIT is composed of stream file information table information SFITI, one or more stream object stream information SOB_STI # n, and stream file information SFI.
[0273]
The stream file information table information SFITI includes the number SFI_Ns of stream file information on the information storage medium (DVD-RAM disk) 201, the number SOB_STI_Ns of stream object stream information following SFITI, the end address SFIT_EA of SFIT, and the start of SFI. It consists of an address SFI_SA.
[0274]
SFIT_EA describes the end address of SFIT by the relative number of bytes (F_RBN) from the first byte of SFIT.
[0275]
SFI_SA describes the start address of SFI by the relative number of bytes (F_RBN) from the first byte of SFIT.
[0276]
Each stream object stream information SOB_STI includes three types of parameters. Each parameter can have a unique value for each bitstream recording. However, usually these parameter sets can be equal in many bitstream recordings. Therefore, SOB_STI is stored in a table different from the stream object information (SOBI) table, and it is recognized that several stream objects (SOBs) share the same SOB_STI (ie, point to the same SOB_STI). Yes. Therefore, normally, the number of SOB_STIs is smaller than the number of SOBs.
[0277]
Each stream object stream information SOB_STI (eg, SOB_STI # 1) in FIG. 15 includes an application packet size AP_SIZ, a service ID number SERV_ID_Ns, a service ID (SERV_IDs), and an application packet device unique ID (AP_DEV_UID). .
[0278]
AP_SIZ describes the application packet size as the byte length of the packet in the bit stream transferred from the application device to the streamer.
[0279]
In the DVD streamer, the application packet size is fixed in each bit stream recording. Therefore, if the application packet size may change during each uninterrupted recording, the current stream object (current SOB) is terminated there, and the new stream object (new SOB) is replaced with the new AP_SIZ. It starts with. At that time, both the current SOB and the new SOB belong to the same program in the original PGC information (ORG_PGCI).
[0280]
SERV_ID_Ns describes the number of service IDs included in the subsequent parameters.
[0281]
SERV_IDs describes a list of service IDs in an arbitrary order.
[0282]
AP_DEV_UID describes a unique device ID that is unique to the application device that supplied the recorded bitstream.
[0283]
As shown in FIG. 15, the stream file information SFI includes stream file general information SF_GI, one or more stream object information (SOB information) search pointers (SOBI_SRP) #n, one or more SOB information (SOBI) #n, It consists of
[0284]
The stream file general information SF_GI includes the number of SOBIs SOBI_Ns, the number of sectors SOBU_SIZ per SOBU, and MTU_SHFT which is a type of time map information.
[0285]
Here, SOBU_SIZ describes the SOBU size in terms of the number of sectors, and this size is constant at 32 (32 sectors = 64 kbytes). This means that in each time map information (MAPL), the first entry relates to an application packet contained in the first 32 sectors of the SOB. Similarly, the second entry relates to an application packet included in the next 32 sectors. The same applies to the third and subsequent entries.
[0286]
Each SOB information search pointer (for example, SOBI_SRP # 1) includes the SOBI start address SOBI_SA. This SOBI_SA describes the start address of the related SOBI with the relative number of bytes (F_RBN) from the first byte of the stream file information SFI.
[0287]
Each SOB information (for example, SOBI # 1) includes stream object general information SOB_GI, time map information MAPL, and access unit data AUD (option).
[0288]
The stream object general information SOB_GI includes a stream object type SOB_TY, a stream object recording time SOB_REC_TM, a stream object stream information number SOB_STI_N, an access unit data flag AUD_FLAGS, a stream object start application packet arrival time SOB_S_APAT, and a stream object. End application packet arrival time SOB_E_APAT, the first stream object unit SOB_S_SOBU of the corresponding stream object, and the number of entries of time map information MAPL_ENT_Ns.
[0289]
The stream object type SOB_TY is a part that can describe a bit indicating a temporary erase state (TE state) and / or a bit of a copy generation management system.
[0290]
The stream object recording time SOB_REC_TM describes the recording time of the related stream object (SOB).
[0291]
The stream information number SOB_STI_N of the stream object describes an SOB_STI index that is valid for the stream object.
[0292]
The access unit data flag AUD_FLAGS describes whether or not access unit data (AUD) exists for the corresponding stream object, and what kind of access unit data if there is.
[0293]
If access unit data (AUD) is present, AUD_FLAGS describes some characteristics of the AUD.
[0294]
As shown in FIG. 15, the access unit data (AUD) itself includes access unit general information AU_GI, an access unit end map AUEM, and a reproduction time stamp list PTSL.
[0295]
The access unit general information AU_GI includes AU_Ns indicating the number of access units described for the SOB, and an access unit start map AUSM indicating which SOBUs belonging to the SOB include access units.
[0296]
The access unit end map AUEM is a bit array of the same length as AUSM (if any) and indicates which SOBU contains the end of the bitstream segment associated with the access unit of that SOB.
[0297]
The reproduction time stamp list PTSL is a list of reproduction time stamps of all access units belonging to the corresponding SOB. One PTSL element included in this list includes the playback time stamp (PTS) value of the corresponding access unit.
[0298]
The access unit (AU) refers to an arbitrary single continuous portion of the recorded bit stream, and is configured to be suitable for individual reproduction. For example, in an audio / video bit stream, an access unit is usually a portion corresponding to an MPEG I picture.
[0299]
Here, the description returns to the contents of SOB_GI.
[0300]
AUD_FLAGS includes a flag RTAU_FLG, a flag AUD_FLG, a flag AUEM_FLG, and a flag PTSL_FLG.
[0301]
When the flag RTAU_FLG is 0b, it indicates that there is no access unit flag in the real-time data of the SOB.
[0302]
When the flag RTAU_FLG is 1b, it indicates that the AU flags (AU_START, AU_END) described in the application header extension of FIG. 9A or 12A can exist in the real-time data of the corresponding SOB. It is. This state is allowed even when the following AUD_FLG is 0b.
[0303]
When the flag AUD_FLG is 0b, it indicates that there is no access unit data (AUD) for the corresponding SOB.
[0304]
When the flag AUD_FLG is 1b, it indicates that access unit data (AUD) may exist for the corresponding SOB.
[0305]
When the flag AUEM_FLG is 0b, it indicates that no AUEM exists in the corresponding SOB.
[0306]
When the flag AUEM_FLG is 1b, it indicates that the AUEM exists in the corresponding SOB.
[0307]
When the flag PTSL_FLG is 0b, it indicates that there is no PTSL in the SOB.
[0308]
When the flag PTSL_FLG is 1b, it indicates that PTSL exists in the corresponding SOB.
[0309]
SOB_S_APAT describes the start application packet arrival time of the stream object. That is, the first application packet arrival time belonging to the SOB is indicated by SOB_S_APAT.
[0310]
This packet arrival time (PAT) is divided into two parts: a basic part and an extended part. The basic part is a part called 90 kHz unit value, and the extended part shows a less significant value measured at 27 MHz.
[0311]
SOB_E_APAT describes the end application packet arrival time of the stream object. That is, SOB_E_APAT indicates the arrival time of the last application packet belonging to the SOB.
[0312]
SOB_S_SOBU describes the first stream object unit of the corresponding stream object. In other words, SOBU_S_SOBU indicates the SOBU including the start portion of the first application packet of the stream object.
[0313]
MAPL_ENT_Ns describes the number of entries of time map information (MAPL) following SOBI_GI.
[0314]
The time map information MAPL has contents corresponding to the
[0315]
Summarizing one of the relevance of the contents of FIGS. 13 and 15 is as follows:
The streamer information STRI included in the
[0316]
Here, the management information (ATS or AUSM) includes information used when transferring stream data, and the management information (PTS or SC_S_APAT) includes information used when displaying the stream data.
[0317]
FIG. 16 is a diagram illustrating a correspondence relationship between an access unit start map (AUSM; see FIG. 15) and a stream object unit (SOBU; see FIGS. 1, 4 to 6, and 12).
[0318]
As shown in the drawing, the bit “1” portion of the AUSM indicates that the corresponding SOBU includes an access unit (AU).
[0319]
Now, the i-th (1 ≦ i ≦ AU_Ns) bit position where the bit is set in AUSM is considered as AUSM_pos (i). Then, the position of the access unit AU is as follows.
[0320]
(1) If SOBU # i indicated by AUSM_pos (i) contains one or more starting AUs (this is described by AU_START and AU_END marks, if any) in the stream, then AUSM_pos (i) is , Assigned to the first AU starting in SOBU # i. Here, SOBU # i is arranged in SOBUs described by AUSM_pos (i) and AUEM_pos (i) (if AUEM exists).
[0321]
(2) The AU ends with the first AU_END mark that appears after this AU starts, and the AU ends with the last SOBU indicated by the assigned AUEM element (if AUEM exists).
[0322]
In any access unit data, two or more accessible access units cannot be described for each SOBU of SOB.
[0323]
FIG. 17 illustrates the correspondence relationship between the access unit start map (AUSM; see FIG. 15) and the access unit end map (AUUM; see FIG. 15) and the stream object unit (SOBU; see FIGS. 2, 4, and 11). It is a figure to do.
[0324]
AUEM is a bit array of the same length as AUSM (if present). The AUEM bit indicates in which SOBU the end of the bit stream segment attached to the access unit of the SOB is included.
[0325]
The number of bits set in AUEM matches the number of bits set in AUSM. That is, each setting bit in AUSM has a bit set correspondingly in AUEM.
[0326]
Now, the i-th (1 ≦ i ≦ AU_Ns) bit position where the bit is set in AUSM is AUSM_pos (i), and the i-th (1 ≦ i ≦ AU_Ns) bit position is set in AUEM. View as AUEM_pos (i). In this case, there is the following relationship.
[0327]
(1) 1 ≦ AUSM_pos (i) ≦ AUEM_pos (i) ≦ MAPL_ENT_Ns;
(2) AUSM_pos (i + 1)> AUEM_pos (i);
(3) If i == AU_Ns or AUSM_pos (i + 1)> 1 + AUEM_pos (i), AU # i ends with SOBU # [AUUM_pos (i)] (1 ≦ i ≦ AU_Ns);
(4) If AUSM_pos (i + 1) == 1 + AUEM_pos (i), AU # i ends with SOBU # [AUUM_pos (i)]. Or
End at SOBU # [1 + AUEM_pos (i)] == SOBU # [AuSM_pos (i + 1)]. That is, AU # i ends at the start of AU # i + 1 in SOBU (1 ≦ i ≦ AU_Ns).
[0328]
FIG. 18 is a diagram illustrating how cells specified by an original PGC or user-defined PGC and SOBUs corresponding to these cells are related by time map information.
[0329]
The user-defined PGC does not include its own SOB, but refers to the SOB in the original PGC. Therefore, the user-defined PGC can be described only by using PGC information. This means that an arbitrary reproduction sequence can be realized without changing the SOB data.
[0330]
The user-defined PGC also includes a series of cells (chain) corresponding to a part of the program in the original PGC without including a program.
[0331]
An example of such a user-defined PGC is shown in FIG. This example shows a case where a user-defined PGC # n is created so that a cell in the PGC refers to the SOB in the original PGC.
[0332]
In FIG. 18, PGC # n has four
[0333]
The solid line arrow from the cell in the user-defined PGC to the original PGC (to the SOBI time map information) indicates the playback period for the corresponding cell. The cell playback order in the user-defined PGC may be completely different from the playback order in the original PGC.
[0334]
The playback of an arbitrary SOB and its SOBU is specified by the start APAT (S_APAT) and the end APAT (E_APAT) in FIG.
[0335]
The SO_APAT of the SOB or SOBU is defined in relation to the time stamp recorded in the payload (see FIGS. 1 (h), 22 and 23) of the stream pack of the SOB.
[0336]
During SOB recording, each incoming application packet is time stamped by a local clock reference in the streamer. This is the application packet arrival time (APAT).
[0337]
The APAT of the first application packet of SOB is stored as SOB_S_APAT. The 4 least significant bytes of all APATs are fixed in advance for the corresponding application packet in the “˜.SRO” file.
[0338]
In order to reproduce the SOB or SOBU data, the reference clock inside the streamer is set to the SCR value, and then the clock is automatically counted. This SCR value is described in the first stream pack (pack header) where reproduction starts. Based on this clock, reproduction / output of all subsequent application packets from the SOB or SOBU is executed.
[0339]
An application packet with the desired APAT when any stream cell (SC) defines a stream cell start APAT (SC_S_APAT) with an arbitrary value between the SOB_S_APAT and SOB_E_APAT of the SOB that the SC points to An address is required to find the SOBU that contains.
[0340]
Although the number of stream packs per SOBU is constant, the interval between arrival times captured by each SOBU is flexible. Therefore, each SOB has time map information (MAPL) in which the arrival time interval of SOBU of the SOB is described. That is, the address system realized by the time map information (MAPL) points to an SOBU that can find a desired application packet by converting an arbitrary APAT into a relative logical block address in a file.
[0341]
FIG. 19 is a diagram for explaining the configuration of a stream data recording / reproducing system (optical disc apparatus / streamer, STB apparatus) according to an embodiment of the present invention. In this embodiment, it is assumed that the
[0342]
The internal structure of the stream data recording / reproducing apparatus according to an embodiment of the present invention will be described below with reference to FIG.
[0343]
This stream data recording / reproducing apparatus includes an optical disk device 415, an STB device 416, and peripheral devices.
[0344]
Peripheral devices include a video mixing unit 405, a frame memory unit 406, an
[0345]
The optical disk device 415 includes a recording /
[0346]
The optical disk device 415 further receives a stream data sent from the STB device 416 via the
[0347]
Specifically, the
[0348]
Based on the time information, segment information for segmenting stream data for each stream block (or for each SOBU) is created, and cell segment information and program segment information corresponding to the segment information, and also PGC segmentation. Create information.
[0349]
The formatter /
[0350]
If the recording /
[0351]
When the recording /
[0352]
Here, the
[0353]
Note that the time stamp information attached to the recording bitstream via the formatter /
[0354]
Further, the time stamp information (SCR) extracted from the reproduction bit stream via the formatter /
[0355]
A reference clock (system clock reference SCR) is recorded in the pack header in the stream data recorded in the
[0356]
That is, in order to reproduce SOB or SOBU data, the reference clock (STC 440) in the streamer (optical disc apparatus 415) is set to the system clock reference SCR described in the first stream pack from which reproduction is started. Thereafter, the
[0357]
The STB unit 416 demodulates the contents of the digital broadcast radio wave received by the
[0358]
When the information (transport packet) of the specific program selected by the reception
[0359]
When the information (transport packet) of the specific program selected by the reception
[0360]
On the other hand, when the program recorded in the
[0361]
The multiplexed information demultiplexing unit 425 classifies various packets (video packet, audio packet, sub-picture packet) included in the stream data sent from the
[0362]
The video decoding unit 428 decodes the video packet (MPEG-encoded) sent from the multiplexed information separation unit 425 to generate moving image data. At that time, the video decoding unit 428 has a built-in representative image (thumbnail) generation unit 439 in order to have a function of generating a reduced image (thumbnail picture) representing the recorded contents from the I picture in the MPEG video data. Yes.
[0363]
The video decoded by the video decoding unit 428 (and / or the representative image generated by the generating unit 439), the sub picture (information such as subtitles and menus) decoded by the sub picture decoding unit 429, and the audio decoding unit 430 The audio decoded in step S1 is sent to the video mixing unit 405 via the video processor unit 438.
[0364]
The video mixing unit 405 uses the frame memory unit 406 to create a digital image in which captions are superimposed on a moving image. This digital video is converted into an analog video via the D /
[0365]
The digital video from the video mixing unit 405 is appropriately taken into the personal computer 435 via signal lines such as the I /
[0366]
On the other hand, the digital audio information decoded by the audio decoding unit 430 is sent to the
[0367]
The operation timing in the STB device 416 is determined by the clock from the system time counter (STC)
[0368]
The above-described instruction or the like by the STB control unit 404 (operation control of each internal configuration of the STB device 416) is executed by a control program stored in the program memory unit 404a. At that time, the
[0369]
The timing of internal operations of the STB device 416 including the STB control unit 404 and the decoder unit 402 can be regulated by a clock from the
[0370]
As a method of synchronizing the
[0371]
Looking at the device configuration of FIG. 19 by function, the STB device 416 includes a “reception time management unit”, a “stream data content analysis unit”, a “stream data transfer unit”, and a “time related information generation unit”. Can be divided / classified.
[0372]
Here, the “reception time management unit” includes a demodulator (demodulation unit) 422, a reception
[0373]
The “stream data content analysis unit” includes a multiplexed information separation unit 425, an STB control unit 404, and the like. This “stream data content analysis unit” analyzes the contents of the received stream data, and extracts the I, B, and P picture positions and / or PTS values.
[0374]
The “stream data transfer unit” includes a multiplexed information separation unit 425, a reception
[0375]
The “time related information generation unit” includes a multiplexed information separation unit 425, an STB control unit 404, a data transfer interface unit 420, and the like. The “time-related information generation unit” includes reception time (time stamp) information recorded by the “reception time management unit”, display time information (PTS value and / or number of fields) extracted by the “stream data content analysis unit”, and Create relationship information between.
[0376]
FIG. 20 is a diagram illustrating a time relationship table showing the relationship between the display time and the data transfer time in one embodiment of the present invention. The basic features of the present invention will be described with reference to FIG.
[0377]
In the NTSC system, which is one of the TV display systems, 30 screens / pictures (frames) are displayed as video signals on the TV monitor screen per second. Since a normal TV uses an interlace method, the screen is scanned and displayed every other scanning line for all the scanning lines of one screen, and then every other shifted image is scanned. In this way, a single screen (picture) is displayed by filling the space between the previous screens. This image displayed every other line is called a field.
[0378]
In the NTSC system, 30 frames / 60 fields per second are displayed. This NTSC system is a display system mainly used in Japan and the United States. On the other hand, the PAL system mainly employed in Europe displays 25 frames / 50 fields per second.
[0379]
FIG. 20A is a diagram in which screens / pictures (frames) that change at 30 sheets per second are arranged along display time (presentation time; or reproduction time) 1.
[0380]
As information indicating the display time (reproduction time) 1 of the screen / picture,
(A) a method represented by “the number of difference fields from a specific screen (picture)”;
(B) There is a method represented by “PTS (presentation time stamp; or reproduction time stamp)”.
[0381]
The PTS can be used in such a manner that a display time is represented by a counter value that is always incremented (a counter value is incremented by 1) using a reference clock of 27 MHz and / or 90 kHz. For example, the value of the counter when each screen / picture (frame) is indicated by a counter that is incremented by a reference clock of 27 MHz (or 90 kHz) is used as the value of PTS.
[0382]
In the received signal information in the digital TV, the PTS value for each picture is included in the picture header information 41 (see FIG. 1 (j)).
[0383]
In FIG. 20A, the display time of the I picture a is PTSNo. 1 and the display times of I pictures i and q are PTSNo. 2 and PTSNo. It is represented by 3.
[0384]
Now, for example, it is assumed that an instruction is received from the user to display a screen (picture) after hours, minutes and seconds of I picture a display. Then, the specified time interval (hours, minutes, seconds) is converted into a count value of 27 MHz and / or 90 kHz. Then, the addition result of the converted value and the PTS value (PTS No. 1) of the I picture a display can be calculated to search for a “screen to be displayed (picture)” instructed by the user.
[0385]
Since the stream data recorded on the
[0386]
However, since this time stamp information cannot be recognized by the user, the user designates a screen (picture) to be viewed using the display time (reproduction time) 1.
[0387]
In this case, information indicating the relationship between the time stamp information for time management of the stream data and the display time (reproduction time) 1 information that can be specified by the user is required. Information indicating this relationship is the time relationship table 2 shown in FIG. 20B (or the reproduction time stamp list PTSL in FIG. 15).
[0388]
As illustrated in FIG. 20B, the time relationship table 2 includes data transfer time information (I picture transfer start) for each PTS value (PTSNo.1, PTSNo.2, PTSNo.3,...). Time 4), data transfer time information (I picture transfer end time 5), and the total number of
[0389]
For example, PTSNo. As for I picture a of 1, the time stamp (ATS) # 1 of the row of the data transfer time information (I picture transfer start time 4) is the leading packet (AP) of the I picture a
[0390]
Similarly, PTSNo. As for I picture i of 2, the time stamp (ATS) # 3 of the row of the data transfer time information (I picture transfer start time 4) is the leading packet (AP) of the I picture i
[0390]
An area in which management information (SFIT in FIG. 15) relating to stream data (FIG. 1 (a), FIG. 20 (c) and other STREAM.VRO 106) is recorded in the time relationship table 2 as shown in FIG. 20 (b). The feature of the present invention is that the user can specify the screen position in units of pictures for the user by using the time relation table.
[0392]
Here, the correspondence between the time relationship table 2 and the reproduction time stamp list PTSL shown in FIG. 15 will be described.
[0393]
When the time stamp shown in FIG. 1 (g) and others is ATS, the PTS value included in the reproduction time stamp list PTSL in FIG. 15 and the ATS have the following relationship:
(1) A cell (stream cell) refers to a part of a recorded bit stream;
(2) AU (normal I picture) is a continuous part of the recorded bitstream (AU corresponds to part of the cell);
(3) Which SOBU includes an AU (I picture corresponding to a part of a cell) is indicated by the access unit start map AUSM in FIG. 15 (see FIG. 16);
(4) The PTS value is the playback time (display time; or presentation time PTM) of the corresponding AU (the PTS value corresponding to the AU corresponds to a part of the cell with respect to the playback time);
(5) Cell start APAT (SC_S_APAT) is the arrival time of the transport packet or application packet AP of the cell (SC_S_APAT corresponds to the value of PTS with respect to playback time);
(6) A transport packet or application packet AP is accompanied by a time stamp ATS (see FIG. 22, FIG. 29 (g), etc.);
(7) The value of PTS is included in PTSL (see FIG. 15);
(8) From (3) to (7) above, the value of PTS included in PTSL corresponds to ATS through AUSM, SC_S_APAT, and the like.
[0394]
Therefore, the reproduction time stamp list PTSL includes information (PTS value) indicating the relationship between the start time (SC_S_APAT) of the AU (I picture) and the time stamp ATS of the packet included in the bitstream (relationship regarding the reproduction time). It can be said that this is a “time relationship table (FIG. 20B)”.
[0395]
Alternatively, it can be said that PTSL (time relationship table) is information indicating the correspondence between the value of PTS and ATS.
[0396]
By the way, in order to display a B picture or a P picture, it is necessary to always start from the display (decode) of an I picture. For this reason, the time relationship table 2 shown in FIG. 20B shows the display time information corresponding to the time stamp at the I picture position as a list.
[0397]
Here, “PTS information (PTS value)”, “number of difference fields from a specific reference screen (picture)”, “year / month / day / time information”, and the like can be used as the display time information.
[0398]
As display time information, instead of performing absolute value display as shown in FIG. 20B, difference information between I pictures (for example, information on the number of fields inserted between I pictures) can be used. It is. (The time relationship table using the number of fields will be described later with reference to FIG. 28.)
In FIG. 20B, “PTS information” is used as display time information. However, in various possible embodiments of the present invention, the present invention is not limited to this method. Instead, “specific reference screen (picture The number of difference fields from “)” or “date information” can be used.
[0399]
In the time relationship table 2 shown in FIG. 20B, not only the value of the transfer start
[0400]
Therefore, when performing special playback such as fast forward playback (fast forward FF) or fast reverse playback (fast reverse FR), “time stamp (ATS) # 1 to # 2”, “time stamp (ATS) # 3 From the
[0401]
In the embodiment of FIG. 20A, the display start picture position (position of B picture f) of the original cell (see FIG. 4) is used as a reference. A difference between the PTS value (PTS No. 5) of the display start picture of the original cell and the PTS value (PTS No. 1) of the I picture a immediately before is the PTS offset 9. The PTS offset
[0402]
Specifically, as shown in FIG. 20A, the display start picture of the original cell is B picture f, and the PTS value at that time is PTSNo. 5 The display time of the I picture a immediately before is set to PTSNo. If it is 1, the value of the PTS offset 9 is obtained by “PTS No. 5−PTS No. 1”.
[0403]
When the user designates a specific screen (specific picture frame), it is often designated by a difference display time from the display start position of the original cell. After converting this difference display time into a counter number of 27 MHz and / or 90 kHz, by adding the value of PTS offset 9, the PTS value of the screen (picture frame) designated by the user can be calculated.
[0404]
As shown in FIG. 20B, the time relation table 2 records a list of PTS values for each I picture. With reference to this table, a PTS value at an I picture position that is smaller than the calculated PTS value and closest to the calculated PTS value is searched for, and a corresponding time stamp (ATS) value at the I picture transfer start
[0405]
As shown in FIG. 20B, in the time relation table 2, the total number of transport packets 10 (access position information) from the original cell head position to the corresponding I picture is also recorded in parallel with the time stamp. Yes.
[0406]
Therefore, according to the embodiment of FIG. 20, the number of transport packets (or the number of application packets AP_Ns) from the original cell head position is specified instead of the time stamp (ATS), and a desired stream data position is accessed. It is also possible.
[0407]
When the stream data (STREAM.VRO) 106 in FIG. 20C is recorded on the
[0408]
First management information (ATS corresponding to the I picture transfer start time; or AUSM) used for accessing the stream data 106 (accessing to the I picture information or the access unit AU) is included in this management information (STRI); This is different from the first management information (AUSM), and indicates the relationship between the first management information and the second management information (PTS; or SC_S_APAT) used for accessing the stream data. Third management information (time relationship table; or PTSL) is recorded.
[0409]
Here, the
[0410]
FIG. 21 is a diagram illustrating the relationship between the display time and the data transfer time in one embodiment of the present invention.
[0411]
Regarding the data structure in the stream data (FIG. 1, FIG. 2 and other STREAM.VRO 106) recorded on the
[0412]
In this embodiment, stream data is recorded in units of stream blocks (SOBU), and time stamp information is used to specify access to a predetermined image (picture).
[0413]
When the time stamp value is designated as the playback start position from the STB device 416 in FIG. 19, information for calculating the stream block (SOBU) corresponding to the designated time stamp value is the time in FIG. This is map information 252 (or time map information MAPL in FIG. 15 or time map information in FIG. 18).
[0414]
In the example of FIG. 3 (h), the
[0415]
In the
[0416]
As shown in FIG. 21C, the boundary positions of the
[0417]
In this case, for example, as shown in FIG. If playback is to be started from the position of P picture o, which is 6, the following processing is required.
[0418]
That is, from the time relationship table 2 in FIG. 21B (the internal configuration is the same as in FIG. 20B), the PTSNo. It is necessary to determine the value of 2 and to start playback from the head position of the stream block (SOBU) #A including the head
[0419]
However, until reproduction proceeds from the start position of the stream block (SOBU) #A to the position of the desired P picture o, the image information during that period (from picture i to picture n in FIG. 21A) is transferred to the external monitor (TV). Not output.
[0420]
FIG. 22 is a diagram for explaining the relationship between the video information compression method in MPEG and the transport packet, and the relationship between the transport packet in MPEG and the application packet in the streamer.
[0421]
As shown in FIG. 22, a signal compression method called MPEG2 is adopted for broadcast signal information on a digital TV. In the signal compression method based on MPEG, each screen (picture) for TV display is classified into an I picture 551 that does not include time difference information, a
[0422]
The I picture exists alone without being affected by the preceding and following screen (picture) information, and after DCT conversion is performed on one screen (picture), the quantized information becomes the I
[0423]
Therefore, at the time of video reproduction, a screen cannot be generated with the
[0424]
When the transport packet of FIG. 22 is recorded on the streamer (the optical disk device 415 of FIG. 19), the content of the transport packet is transferred to a packet with a time stamp (application packet) called an application time stamp (ATS).
[0425]
A group of application packets with ATS (usually around 10 packets) is stored in the application packet area in the stream PES packet.
[0426]
The stream PES packet with a pack header is one stream pack.
[0427]
A stream PES packet is composed of a PES header, a substream ID, an application header, an application header extension (option), a stuffing byte (option), and an application packet area for storing the application packet group with the ATS. The
[0428]
FIG. 23 is a diagram for explaining the correspondence between digital broadcast content, video data transfer form in
[0429]
In digital broadcasting, video information compressed in accordance with the MPEG2 standard is transferred on transport packets. As shown in FIG. 23B, the transport packet includes a transport packet header 511 and a payload 512 in which a data body of recording information is recorded.
[0430]
As shown in FIG. 23A, the transport packet header 511 includes a payload
[0431]
The MPEG-compressed video information includes I picture information, B picture information, and P picture information. In the first transport packet in which the I picture information is recorded, a flag “1” is set in the
[0432]
Using the information of the
[0433]
For example, for the transport packet in which the payload
[0434]
In digital broadcasting, video information and audio information are transferred in different transport packets. Each information is identified by a packet ID (PID) 502 in FIG. Using this
[0435]
As shown in FIG. 23 (c), in digital broadcasting, a plurality of programs (in this example,
[0436]
For example, the information of the transport packet header 511 and the payload (recording information) 512 of FIG. 23B is transferred by the transport packets b · 522 and e · 525 of the
[0437]
For example, when the user intends to record the second program shown in FIG. 23 (c) in the
[0438]
At that time, as shown in FIG. 23D, the STB device 416 adds the time information when the transport packets b522 and e525 are received in the form of
[0439]
After that, when data is transferred to the formatter /
[0440]
In the formatter /
[0441]
Specifically, in one embodiment of the present invention, a pack header in which system clock information and the like are recorded and a PES header are arranged at the head of each sector (see FIG. 23 (h) and the like).
[0442]
A plurality of time stamps and transport packets (FIG. 1 (g)) are sequentially packed in the
[0443]
By using a data structure that makes use of this feature, a packet having a size larger than the sector size (for example, 2048 bytes) can be recorded. This point will be further described.
[0444]
In digital broadcasting, as shown in FIG. 23 (c), a multiplexing / demultiplexing method corresponding to a multi-program called a transport stream is adopted, and the size of one transport packet b · 522 is 188 bytes (or 183 bytes). In many cases.
[0445]
As described above, the size of one sector is 2048 bytes, and even if various header sizes are subtracted, 10 transport packets for digital broadcasting are included in one
[0446]
On the other hand, in a digital communication network such as ISDN, a large long packet having a packet size of 4096 bytes may be transferred.
[0447]
In the case of a packet having a large packet size such as a long packet as well as recording a plurality of transport packets in one
[0448]
By doing so, transport packets for digital broadcasting, long packets for digital communication, and the like can be recorded without any fraction in the stream block without depending on the packet size.
[0449]
In addition, time stamps are attached to normal packets, but time stamps can be omitted from partial packets as shown in FIG.
[0450]
In this way, the partial packet divided at the boundary between two adjacent stream packs (FIG. 23 (h)) (if the packet is 188 bytes, the size of the partial packet is 1 to 187 bytes; on average, 100 bytes Can be used effectively for information recording. In addition, the storage capacity for the medium 201 can be increased by the time stamp omitted for the partial packet (for example, 4 bytes per time stamp).
[0451]
Note that the position of the time stamp immediately after the first partial packet in FIG. 23G can be specified by the
[0452]
In the optical disk device 415 (streamer) of FIG. 19, a set of time stamps and transport packets (FIGS. 23 (f) and (g)) is recorded on the
[0453]
FIG. 24 is a flowchart for explaining a stream data recording procedure according to one embodiment of the present invention. The processing at the time of recording stream data will be described with reference to FIG. This processing can be executed by a processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.
[0454]
As shown in FIG. 23 (c), a plurality of program information is time-division multiplexed in one transponder.
[0455]
In the reception
[0456]
In the “reception time management unit (
[0457]
At the same time, the reception time for each transport packet is measured, and the measured value is added to each transport packet (or application packet) as a time stamp (ATS) as shown in FIG. . The time stamp information added in this way is recorded in the memory unit 426 (step S03).
[0458]
Next, in the “stream data content analysis unit (multiplexed information separation unit 425, STB control unit 404, etc. in FIG. 19)”, the information in the transport packet (application packet) recorded in the memory unit 426 is analyzed. The
[0459]
Specifically, each picture boundary position is cut out from the transport packet (application packet) sequence, and PTS information (or corresponding field number information) is extracted from the picture header information 41 for each packet ( Step S04).
[0460]
Here, there are two methods for extracting each picture boundary position, and which method is selected depends on the contents of the stream data.
[0461]
The first picture boundary position extraction method detects the I picture position by detecting the flag of the random access indicator 503 (FIG. 23A) in the transport packet header 511 (FIG. 23B), and the payload. This is a method of detecting the B or P picture position from the flag detection of the unit start indicator 501 (FIG. 23A).
[0462]
The second picture boundary position extraction method extracts the picture identification information 52 (FIG. 1 (k)) and the PTS information 53 (FIG. 1 (k)) in the picture header information 41 (FIG. 1 (j)). Is the method.
[0463]
After the above processing (steps S01 to S04), the “time-related information generation unit (multiplexed information separation unit 425, STB control unit 404, data transfer interface unit 420, etc. in FIG. 19)” uses a time stamp (ATS). As a list showing the relationship between the PTS value and the PTS value, the time relationship table 2 as shown in FIG. 20B (or the reproduction time stamp list PTSL in FIG. 15) is created, and the work memory in the STB control unit 404 is created. This is recorded in the unit 407 (step S05).
[0464]
Thereafter, while maintaining the reception time interval in the STB device 416 and the optical disc device 415 (that is, keeping the relationship between the change in the count value of the
[0465]
Thus, the stream data temporarily stored in the memory unit 426 is recorded on the
[0466]
Until the stream data transfer to the optical disc apparatus 415 is completed (NO in step S08), the processes in steps S06 to S07 are repeated.
[0467]
When the stream data transfer to the optical disk device 415 is completed and the recording process is completed (Yes in step S08), the time relation table 2 (or the reproduction time stamp list PTSL) temporarily recorded in the
[0468]
Then, the information of the time relation table 2 (or the reproduction time stamp list PTSL) is recorded in the management information recording area (STREAM.IFO) 105 of the information storage medium 201 (step S11).
[0469]
During the processing of step S11, the recording time of the stream object that is the content of the recorded stream data (SOB_REC_TM in FIG. 7 (i)) is used as the time zone (TM_ZONE) in the management information recording area (STREAM.IFO) 105. 6240 (can be recorded in FIG. 7H).
[0470]
By the way, there are cases where encrypted stream data is recorded for the purpose of protecting the copyright of the content provider when recording the stream data. When encryption is performed in this way, all transport packets are encrypted and time stamp transfer processing between the STB device 416 and the optical disk device 415 is prohibited. In this case, when recording (encrypted) stream data on the
[0471]
The STB device 416 side in FIG. 19 performs reception time management for each transport packet (application packet). In this case, a countermeasure against the deviation of the reference clock frequency (specifically, synchronization of the reference clock) is an important issue between the STB device 416 side and the optical disc device 415 side. Therefore, a recording process for encrypted stream data will be described below.
[0472]
FIG. 25 is a flowchart for explaining a recording procedure of encrypted stream data according to one embodiment of the present invention. This processing procedure can be executed by a processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.
[0473]
First, it is checked whether the time relationship table 2 (FIG. 20B) or the reproduction time stamp list PTSL (FIG. 15) exists in the
[0474]
If there is no time relationship table (or PTSL) (NO in step S50), a time relationship table (or PTSL) is created by the same processing as steps S04 to S05 in FIG. 24 (step S52).
[0475]
After the time relationship table (or PTSL) is created in this way, or when the time relationship table (or PTSL) is already in the
[0476]
Until the recording of the (encrypted) stream data is completed (No at Step S53), the process at Step S51 is continued. This stream data recording step S51 has the same processing contents as steps S01 to S03 and S06 in FIG.
[0477]
Note that the process of step S52 may be executed in parallel with the process of step S51.
[0478]
When the recording of the (encrypted) stream data is completed (Yes in step S53), a reference clock synchronization process is executed between the STB device 416 and the optical disk device 415 (step S54).
[0479]
This reference clock synchronization processing can be performed, for example, as follows.
[0480]
That is, every time a specific number (for example, 10,000 or 100,000) transport packets (application packets) are transmitted / received at the time of stream data transfer, the transmission / reception times of the STB device 416 and the optical disk device 415 are used as work memories.
[0481]
Thereafter, a transmission time list is sent each time a specific number of transport packets (application packets) are transmitted from the STB device 416 side to the optical disc device 415 side. Then, on the optical disc apparatus 415 side, the sent list is compared with the list created in advance on the optical disc apparatus 415 side, thereby calculating the reference clock synchronization deviation amount between them.
[0482]
Thereafter, the time relationship table 2 (or PTSL) is transferred from the STB device 416 to the optical disk device 415 (step S55).
[0483]
The time relationship table 2 (or PTSL) thus transferred from the STB device 416 to the optical disk device 415 is corrected based on the reference clock synchronization shift amount information calculated in the reference clock synchronization processing in step S54 (step S54). S56).
[0484]
The time relationship table 2 (or PTSL) thus corrected by the amount of reference clock synchronization deviation is recorded in the management information area (
[0485]
By doing so, it becomes possible to record / reproduce stream data (in an encrypted state).
[0486]
Instead of the above-described “correction of reference clock synchronization deviation with respect to encrypted stream data” method, the following method may be used as another method.
[0487]
That is, as shown in FIG. 20B, the number of transport packets transferred between each I picture is recorded in the time relation table 2. Then, instead of designating the time stamp value of the playback start screen (as a picture designation method), the total number of transport packets (or application packets) from the beginning of the cell is designated.
[0488]
In this case, as information in the
[0489]
When the total number of transport packets (total number of application packets) is specified from the STB device 416 side to access a predetermined screen (picture), the optical disk device 415 sequentially transfers from the first stream block shown in FIG. The number of port packets (application packets) 633 is incremented, and access is made to the stream block (or SOBU) at the time when the addition result reaches a designated value.
[0490]
FIG. 26 is a flowchart for explaining a stream data reproduction procedure according to an embodiment of the present invention. This processing procedure can be executed by a processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG. Hereinafter, the reproduction step of stream data will be described with reference to FIG.
[0491]
The user can specify the desired playback start time and / or playback end time in the form of “difference time (how many hours and minutes and seconds) based on the display start time of the specified original cell”. The STB control unit 404 in the STB device 416 receives the specified playback start time and playback end time, for example, specified in this way (step S21).
[0492]
In the STB control unit 404, the received time information of the reproduction start time and the reproduction end time is converted into a clock count value of 27 MHz and / or 90 kHz, and a differential PTS value from the display start time of the original cell is calculated. .
[0493]
The STB control unit 404 controls the optical disk device 415 to read the time relationship table 2 (or PTSL) recorded in the stream data management information recording area (STREAM.IFO 105) and temporarily record it in the work memory unit 407 ( Step S22).
[0494]
Further, the STB control unit 404 controls the optical disc device 415 to read the information of the time map information 252 (or MAPL) recorded in the stream data management information recording area (STREAM.IFO 105), and stores it in the
[0495]
Next, the value of the PTS offset 9 shown in FIGS. 3 (h) and 20 (a) is read, and the display start time of the corresponding original cell (corresponding to B picture f in FIG. 20 (a)) and the immediately preceding time are displayed. The difference from the display time of the I picture a (PTS No. 5 -PTS No. 1 in FIG. 20A) is examined (step S24).
[0496]
Further, the value of the PTS offset 9 shown in FIGS. 3 (h) and 20 (a) is read,
(A) the value (PTS offset 9);
(B) PTS value (PTS No. 1) at the I picture-a position immediately before the display start time of the original cell (PTS No. 1) (As shown in FIG. 20A, the display start picture f of the original cell is immediately after the I picture a. If)
(C) The differential PTS value (PTS No. 5 -PTS No. 1) checked in step S24
And the PTS values of the reproduction start time and reproduction end time designated by the user are calculated (step S25).
[0497]
Next, the PTS value of the I picture i immediately before the reproduction start location designated by the user and the value of the
[0498]
The optical disc apparatus starts from the data of the
[0499]
Based on the address thus determined, the optical disc apparatus 415 reproduces information from the transport packet (AP) # 1 in FIG. 21C from the information storage medium 201 (step S28).
[0500]
Next, the STB control unit 404 in FIG. 19 notifies the decoder unit 402 of the PTS value (PTS No. 6 in FIG. 21A) indicating the display start time of the information started to be reproduced in step S28 (step S29). ).
[0501]
Along with this notification, the optical disc apparatus 415 transfers the information that has been reproduced in step S28 to the STB apparatus 416 side (step S30).
[0502]
Subsequently, the STB control unit 404 reads the picture identification information 52 (FIG. 1 (k)) from the memory 426 in the decoder unit 402, and inputs the I picture (part of the information transferred from the optical disc device 415). The previous data is discarded (or ignored) (step S31).
[0503]
Next, the video decoding unit 428 in FIG. 19 starts decoding from the head position of the I picture (I picture i in FIG. 21A) input in step S31, and the PTS value designated by the notification in step S29. Display (video output) is started from (PTS No. 6 in FIG. 21A) (step S32).
[0504]
Thereafter, the same processing as steps S24 to S28 is repeated, the address on the
[0505]
At the stage where the above-described series of playback is completed, the video manager information in the management information recording area (
[0506]
As the data content of the reproduction end position information 6110, as shown in FIG. 7 (h), the corresponding PGC number 6210, the cell number 6220 therein, and the reproduction end position time information 6230 are recorded.
[0507]
Although the time information 6230 is recorded as a time stamp value, the PTS value (or the total number of fields from the cell playback head position) can also be recorded as the time information 6230.
[0508]
When the reproduction end position information is started again from the position of the (resume) information 6110, the reproduction start position can be obtained by the process shown in FIG.
[0509]
At the time of standard reproduction as described above with reference to FIG. 26, the count value of the
[0510]
FIG. 27 is a flowchart for explaining the special reproduction procedure of stream data according to the embodiment of the present invention. This processing procedure can be executed by a processing program stored in the program memory unit 404a of the STB control unit 404 shown in FIG.
[0511]
When special playback such as fast forward playback (fast forward FF) or fast reverse playback (fast reverse FR) is performed, only I picture information recorded on the
[0512]
In this case, “special playback mode setting” is set to the decoder unit 402 so that the STC unit 424 (FIG. 19) and the DTS information 54 (FIG. 1 (k)) are out of synchronization and decoded in the free mode. This is performed (step S41).
[0513]
Also during special playback, the information of the time relationship table 2 and the
[0514]
Next, the
[0515]
Next, the time stamp value of the start time / end time at each I picture position (position of each AU # in the example of FIG. 16) is extracted from the time relation table 2 (step S44).
[0516]
Next, the stream block (SOBU) including the time stamp value of the corresponding I picture is checked from the
[0517]
For example, during special playback, only I picture
[0518]
Next, the optical disc device 415 reproduces information in the Zen stream block (SOBU) including each I picture on the
[0519]
Next, in the decoder unit 402 of FIG. 19, the picture identification information 52 (FIG. 1 (k)) in the data transferred to the memory unit 426 of the multiplexed information demultiplexing unit 425 is read. Data other than pictures is discarded (step S47).
[0520]
That is, in step S47, only I picture information is extracted from the reproduced / transferred stream data using the
[0521]
Next, the I picture data selected (that is, not discarded) in the memory unit 426 of the multiplexed information separation unit 425 in the decoder unit 402 is transferred to the frame memory unit 406 (step S48).
[0522]
The I picture data thus transferred to the frame memory unit 406 is sequentially displayed on the display screen of the TV (or video monitor) 437 (step S49).
[0523]
FIG. 28 is a diagram for explaining a time relationship table showing the relationship between the display time and the data transfer time in another embodiment of the present invention.
[0524]
In the embodiment of FIG. 20, the absolute value is displayed as the display time information as shown in FIG. 20B, but instead, the difference information between each I picture (for example, inserted between each I picture) It is also possible to use field number information).
[0525]
In FIG. 20B, “PTS information” is used as display time information. However, in various possible embodiments of the present invention, the present invention is not limited to this method. Instead, “specific reference screen (picture The number of difference fields from “)” or “date information” can be used. An example of this case is the time relationship table 6 of FIG.
[0526]
As shown in FIG. 28B, each group of pictures (GOP) indicates a group of pictures from a certain I picture position to the head of the next I picture. In the data structure of the time relationship table 6 shown in FIG. 28C, the number of display fields for each GOP is recorded as display time information.
[0527]
Also, the number of stream blocks (SOBU) occupied for each GOP is described in the time relationship table 6. By doing so, without using the
[0528]
At the boundary position between
[0529]
Further, since the rear end position of the I picture information is used at the time of the special reproduction such as FF or FR described above, the time relation table 6 in FIG. 28C also includes I picture size information in each GOP. Yes.
[0530]
FIG. 29 is a diagram for explaining how a packet (AP) in stream data (SOBU) is reproduced in an embodiment of the present invention.
[0531]
29 exemplifies a case where the stream blocks ## 1, # 2,... In FIG. 1C are all configured with
[0532]
FIG. 29 (f) shows the first sector No. of
[0533]
As shown in FIG. The system clock reference SCR is recorded in the pack header of the stream pack corresponding to 0, and the sector number. The system clock reference SCR is also recorded in the pack header of the stream pack corresponding to 63.
[0534]
Now, it is assumed that a picture to be reproduced (a picture designated by the user with a reproduction time) exists in the middle of SOBU # 2 (in FIG. 16, for example, the position indicated by AU # 1). The picture specified by the user in the playback time corresponds to the cell start application packet arrival time SC_S_APAT.
[0535]
In this case, the disk drive (not shown) included in the recording /
[0536]
The interval from the boundary position between
[0537]
The application packet existing between the boundary position between
[0538]
FIG. 29 (g) illustrates that the PTS information (PTS value or PTS offset) and the application packet AP to be reproduced are related by the time relationship table 2 of FIG. 20 (a). is there.
[0539]
Here, the relationship between the time relationship table and the reproduction time stamp list PTSL shown in FIG. 15 is organized again.
[0540]
When the time stamp shown in FIG. 1 (g) and others is ATS, the PTS value included in the reproduction time stamp list PTSL in FIG. 15 and the ATS have the following relationship:
(1) A stream cell refers to a part of a recorded bit stream;
(2) AU (normal I picture) is a continuous part of the recorded bitstream (AU corresponds to part of the cell);
(3) Which SOBU includes an AU (I picture corresponding to a part of a cell) is indicated by AUSM (see FIG. 16);
(4) The PTS value is the playback time (display time; or presentation time PTM) of the corresponding AU (the PTS value corresponding to the AU corresponds to a part of the cell with respect to the playback time);
(5) The cell start APAT (SC_S_APAT) is the arrival time of the application packet AP of the corresponding cell (SC_S_APAT corresponds to the value of PTS with respect to the playback time);
(6) The application packet AP is accompanied by a time stamp ATS (see FIG. 29 (g), etc.);
(7) The value of PTS is included in PTSL (see FIG. 15);
(8) From the above, the value of PTS included in PTSL corresponds to ATS through AUSM, SC_S_APAT, and the like.
[0541]
Therefore, the reproduction time stamp list PTSL includes information (PTS value) indicating the relationship between the start time (SC_S_APAT) of the AU (I picture) and the time stamp ATS of the packet included in the bitstream (relationship regarding the reproduction time). It includes a “time relationship table (FIG. 20B)”.
[0542]
Alternatively, it can be said that PTSL (time relationship table) is information indicating the correspondence between the value of PTS and ATS.
[0543]
Finally, the meaning of some terms used in the description of each embodiment is summarized:
* Stream object (SOB) indicates data of a recorded bit stream. SR_TRANS. A maximum of 999 SOBs can be recorded in the SRO file.
[0544]
* A stream object unit (SOBU) is a basic unit organized in an SOB. That is, each SOB consists of a series (chain) of SOBUs. In particular, after editing, the SOBU at the beginning and / or end of the SOB may include data that does not belong to the valid portion of the SOB.
[0545]
The SOBU is not characterized by playback time or playback order, but by a fixed size (size for 32 sectors or size for 2 ECC blocks).
[0546]
* Access unit (AU) refers to any single continuous portion of a recorded bitstream suitable for individual playback. This AU usually corresponds to an I picture in an MPEG encoded bit stream.
[0547]
* The access unit start map (AUSM) indicates which SOBU of the SOB includes AU.
[0548]
* An application packet (AP) is a part of a bit stream coming from an application device during recording. Alternatively, the AP is part of a bitstream that goes to the application device during playback. These APs are included in the multiplexed transport and have a certain size (maximum 64574 bytes) during recording.
[0549]
* The application time stamp (ATS) is arranged in front of each AP and is composed of 32 bits (4 bytes). The ATS is composed of a basic part of 90 kHz and an extended part of 27 MHz.
[0550]
* A cell (or stream cell SC) is a data structure indicating a part of a program. Cells in the original PGC are called original cells, and cells in the user-defined PGC are called user-defined cells. Each program in the program set consists of at least one original cell. Each part of the program in each playlist consists of at least one user-defined cell. In the streamer, the simple cell means a stream cell (SC). Each SC refers to a part of the recorded bit stream.
[0551]
* The cell number (CN) is a number (1 to 999) assigned to a cell in the PGC.
[0552]
* Stream cell entry point information (SC_EPI) is used as a tool for skipping a part of the recording, and can exist in any stream cell (SC).
[0553]
* The start application packet arrival time (SOB_S_APAT) of the stream object indicates the arrival time of the first AP belonging to the SOB. This arrival time is composed of a basic part of 90 kHz and an extended part of 27 MHz.
[0554]
* The end application packet arrival time (SOB_E_APAT) of the stream object indicates the arrival time of the last AP belonging to the SOB.
[0555]
* The start application packet arrival time (SC_S_APAT) of the stream cell indicates the arrival time of the first AP belonging to the corresponding SC.
[0556]
* The end application packet arrival time (SC_E_APAT) of the stream cell indicates the arrival time of the last AP belonging to the corresponding SC.
[0557]
* Navigation data is data used when controlling recording, reproduction, and editing for a bit stream (SOB).
[0558]
* Playlist (PL) is a list of program parts in which the user can arbitrarily define the playback sequence. PL is described as a user-defined PGC.
[0559]
* A program (PG) is a logical unit of recorded content that is recognized or defined by the user. A program in a program set consists of one or more original cells. The program is defined only in the original PGC.
[0560]
* The program chain (PGC) is a superordinate conceptual unit. In the case of the original PGC, the PGC indicates a chain (chain) of programs corresponding to the program set. On the other hand, in the case of a user-defined PGC, the PGC corresponds to a playlist and indicates a series (chain) of a part of the program.
[0561]
* Program chain information (PGCI) is a data structure indicating the overall reproduction of PGC. PGCI is used for both original PGC and user-defined PGC. The user-defined PGC is composed only of PGCI, and its cell refers to the SOB in the original PGC.
[0562]
* The program chain number (PGCN) is a serial number (1 to 99) assigned to the user-defined PGC.
[0563]
* The program number (PGN) is a serial number (1 to 99) assigned to the program in the original PGC.
[0564]
* The program set refers to the entire recorded contents of a disc (recording medium) composed of all programs. If editing is not performed for any program that changes the playback order with respect to the original recording, the same playback order as the recording order of the program is used for playback of the program set.
[0565]
* Real-time recording means that if the buffer memory size is limited, the buffer memory will overflow as long as any stream data encoded at the limited transfer rate is transferred at the limited transfer rate. The recording means that the stream data can be recorded on a disc (recording medium).
[0566]
The effects of each embodiment according to the present invention are summarized as follows:
1. Information (time relationship table or PTSL) indicating the relationship between the time stamp data (ATS) recorded in the stream data and the display time information (PTS or field information) for the user is part of the management information (SFIT). By providing this, reproduction / screen display can be started from the display time designated by the user with high accuracy.
[0567]
2. At the time of editing, the user designates a partial deletion range or rearrangement designation range of recorded stream data by a display time on the monitor TV.
[0568]
As described in “1.”, the stream data has a time relationship table (or PTSL) indicating the relationship between the time stamp data and the display time information as part of the management information (SFIT). This makes it possible to accurately set the edit point position (partial deletion range or rearrangement designation range) using this time relationship table (or PTSL). As a result, time management for stream data can be performed using time stamp data (ATS), and accurate editing processing according to a user request can be guaranteed.
[0569]
3. As described in “1.” above, since the time-related table (or PTSL) is provided in the stream data, either the time stamp data (ATS) or the display time information (PTS) is used as the reproduction end position. By simply describing it as information (resume information), it is possible to accurately set the playback start position (resume playback start position) when the streamer is restarted.
[0570]
4). By recording the playback end position information (resume information) as time stamp data (ATS), when accessing a specific position on the information storage medium, the
[0571]
5). The compressed data by MPEG always needs to start reproduction from the I picture. By recording information (time relationship table) indicating the relationship between time stamp data (ATS) and display time information (PTS or field information) at the start position of each I picture (or the start position of the access unit AU) The access control to the desired I picture (desired AU) can be performed at high speed using the
[0572]
6). By recording information (time relationship table) indicating the relationship between time stamp data (ATS) and display time information (PTS or field information) at each I picture start position (start position of each AU), time is recorded. In combination with the
[0573]
The present invention is not limited to the above-described embodiments, and various modifications and changes can be made without departing from the scope of the invention at the stage of implementation. In addition, the embodiments may be implemented in appropriate combination as much as possible, and in that case, the effect of the combination can be obtained.
[0574]
Further, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of constituent elements disclosed in this application. For example, even if one or more constituent requirements are deleted from all the constituent requirements shown in the embodiment, when at least one of the effects of the present invention or the effects associated with the implementation of the present invention is obtained, The deleted configuration can be extracted as an invention.
[0575]
【The invention's effect】
As described above, according to the present invention, it is possible to improve the stream information recording process.
[Brief description of the drawings]
FIG. 1 is a view for explaining the data structure of stream data according to an embodiment of the invention.
FIG. 2 is a view for explaining the directory structure of a data file according to one embodiment of the present invention.
FIG. 3 is a view for explaining a recording data structure (especially a structure of management information) on an information medium (DVD recording / reproducing disc) according to an embodiment of the present invention;
FIG. 4 is a diagram for explaining a relationship among stream objects (SOB), cells, program chains (PGC), and the like according to the present invention.
FIG. 5 is a diagram for explaining the stream block size, the contents of the stream block time difference, and others in the time map information.
FIG. 6 is a diagram for explaining a cell range designation method in an original cell and a user-defined cell.
FIG. 7 illustrates a recording data structure (particularly a structure of reproduction end position information / resume information, VMGI management information / recording time information, etc.) on an information medium (DVD recording / reproducing disc) according to another embodiment of the present invention. To do.
FIG. 8 is a diagram for explaining the internal structure of the PES header shown in FIG. 1 and others;
FIG. 9 is a view for explaining the internal structure of the stream block header shown in FIG. 1;
FIG. 10 is a diagram for explaining the internal structure of the sector data header shown in FIG. 1;
FIG. 11 is a diagram illustrating another example of time map information according to the embodiment of the present invention.
FIG. 12 is a diagram for explaining an example of an internal configuration of a sector constituting a stream block (SOBU) (a stream pack including an application packet and a stream pack including a stuffing packet).
13 is a diagram for explaining an internal data structure of streamer management information (corresponding to STREAM.IFO or SR_MANGR.IFO in FIG. 2).
14 is a diagram illustrating an internal data structure of PGC information (ORG_PGCI / UD_PGCIT in FIG. 3 or PGCI # i in FIG. 13).
FIG. 15 is a diagram illustrating an internal data structure of a stream file information table (SFIT).
FIG. 16 is a diagram illustrating a correspondence relationship between an access unit start map (AUSM) and a stream object unit (SOBU).
FIG. 17 is a diagram illustrating a correspondence relationship between an access unit start map (AUSM) and an access unit end map (AUUM) and a stream object unit (SOBU).
FIG. 18 is a diagram exemplifying how cells specified by an original PGC or user-defined PGC and SOBUs corresponding to these cells are related by time map information;
FIG. 19 is a diagram for explaining the configuration of a stream data recording / reproducing system (optical disc apparatus / streamer, STB apparatus) according to an embodiment of the present invention.
FIG. 20 is a diagram for explaining a time relationship table showing the relationship between the display time and the data transfer time in the embodiment of the present invention.
FIG. 21 is a diagram for explaining the relationship between the display time and the data transfer time in the embodiment of the invention.
FIG. 22 is a diagram for explaining a relationship between a video information compression method in MPEG and a transport packet, and a relationship between a transport packet in MPEG and an application packet in a streamer.
FIG. 23 is a diagram for explaining the correspondence between digital broadcast content, video data transfer form in
FIG. 24 is a flowchart for explaining a stream data recording procedure according to one embodiment of the present invention;
FIG. 25 is a flowchart for explaining a recording procedure of encrypted stream data according to one embodiment of the present invention.
FIG. 26 is a flowchart for explaining a stream data reproduction procedure according to an embodiment of the present invention.
FIG. 27 is a flowchart for explaining a special reproduction procedure for stream data according to one embodiment of the present invention.
FIG. 28 is a diagram for explaining a time relationship table showing the relationship between display time and data transfer time in another embodiment of the present invention.
FIG. 29 is a diagram for explaining how a packet (AP) in stream data (SOBU) is reproduced in an embodiment of the present invention;
[Explanation of symbols]
201: Information medium, 415: Optical disk device, 416: STB device.
Claims (5)
トランスポートパケットあるいはアプリケーションパケットというデータパケットを第1データ単位として表現し、ストリームブロックあるいはストリームオブジェクトユニットというデータ単位を第2データ単位として表現し、ストリームオブジェクトというオブジェクトデータを第3データ単位として表現したときに、
1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータが形成され、
前記第3データ単位の記録中に到来する前記第1データ単位のデータパケット群にはヘッダ情報があり、
前記第3データ単位の記録中に到来する前記データパケットにはパケット到着時間の情報を持つタイムスタンプが付されるように構成され、
前記第2データ単位は前記ヘッダ情報を含み、
前記ヘッダ情報が前記第1データ単位の時間に関する情報を含み、
前記第1データ単位の時間に関する情報として前記データパケット群の特定データパケットに付随している前記パケット到着時間に関する情報が記録され、または前記第1データ単位の時間に関する情報として前記第1データ単位のタイムスタンプの位置を示す情報が記録され、
前記時間に関する情報を含む前記ヘッダ情報が前記管理エリアとは異なる前記データエリアに記録されるように構成され、かつ前記ストリームデータと異なるリアルタイムビデオオブジェクトデータが前記データエリアに記録されるように構成され、
前記トランスポートストリームを含むストリームデータおよび前記リアルタイムビデオオブジェクトデータを管理する前記管理情報のファイルが単一のディレクトリに格納されるように構成され、さらに、
前記管理情報に前記ストリームデータの前記Iピクチャ部分に対応した時間関係情報が記録された情報記憶媒体。 It is those having a management area for recording data area and management information of the stream data for recording stream data including MPEG-encoded transport stream has information of I-picture,
When a data packet called a transport packet or application packet is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and an object data called a stream object is expressed as a third data unit In addition,
The stream data recorded on the said front Symbol data area Ri by the stream object of a second the third data unit consists of data units 1 or comprise include one or more of the first data unit is formed,
The data packets of the first data unit arrives during the recording of said third data unit has F header information,
Wherein the said data packets arriving during the recording of the third data unit is configured to timestamp with information packet arrival time is assigned,
The second data unit includes the header information;
Wherein the header information includes information on time before Symbol first data unit,
Information is recorded relating to the packet arrival times that are associated with a particular data packet before Symbol data packets as the information about the time of the first data unit, or prior to the information about the time before Symbol first data unit Information indicating the position of the time stamp of the first data unit is recorded,
So that the header information containing information on the time is configured to be recorded in said different data areas from the previous SL management area, Do One prior Symbol stream data different from real-time video object data is recorded in the data area Composed of
Said file of the management information for managing the stream data and the real-time video object data including a transport stream is configured to be stored in a single directory, further,
The I information storage medium time relation information corresponding to the picture portion is recorded before the SL stream data to the management information.
1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータを形成し、
前記第2データ単位内に、前記第1データ単位の時間に関する情報を含むヘッダ情報を格納し、
前記時間に関する情報を含む前記ヘッダ情報を含めて、前記ストリームデータを前記データエリアに記録し、
前記リアルタイムビデオオブジェクトデータを前記データエリアに記録し、
前記管理情報を前記管理エリアに記録するとともに前記管理情報のファイルを前記情報記憶媒体に記録するように構成された記録方法。A data packet called a transport packet or an application packet, which has a data area for recording stream data including MPEG-encoded I picture information and including a transport stream, and a management area for recording management information of the stream data Is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and object data called a stream object is expressed as a third data unit. The stream data to be recorded in the data area is formed by the stream object of the third data unit including at least one second data unit including the unit, The data packet group of the first data unit that arrives during the recording of the third data unit has header information, and the data packet that arrives during the recording of the third data unit has a time having packet arrival time information The second data unit includes the header information, the header information includes information about the time of the first data unit, and the data as information about the time of the first data unit. Information related to the packet arrival time associated with a specific data packet of the packet group is recorded, or information indicating a time stamp position of the first data unit is recorded as information related to the time of the first data unit, The header information including information about time is recorded in the data area different from the management area. And the management information file for managing the stream data including the transport stream and the real-time video object data is configured such that real-time video object data different from the stream data is recorded in the data area. In a recording method using an information storage medium configured to be stored in a single directory and further configured to record time-related information corresponding to the I picture portion of the stream data in the management information ,
Forming the stream data recorded in the data area by the stream object of the third data unit configured to include one or more of the second data units including one or more of the first data units;
In the second data unit, storing header information including information on the time of the first data unit,
Including the header information including information about the time, the stream data is recorded in the data area,
Recording the real-time video object data in the data area;
A recording method configured to record the management information in the management area and to record the management information file in the information storage medium.
前記管理エリアから前記管理情報を読み取り、
前記データエリアから前記第2データ単位で前記ストリームデータを読み取るように構成された再生方法。A data packet called a transport packet or an application packet, which has a data area for recording stream data including MPEG-encoded I picture information and including a transport stream, and a management area for recording management information of the stream data Is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and object data called a stream object is expressed as a third data unit. The stream data to be recorded in the data area is formed by the stream object of the third data unit including at least one second data unit including the unit, The data packet group of the first data unit that arrives during the recording of the third data unit has header information, and the data packet that arrives during the recording of the third data unit has a time having packet arrival time information The second data unit includes the header information, the header information includes information about the time of the first data unit, and the data as information about the time of the first data unit. Information related to the packet arrival time associated with a specific data packet of the packet group is recorded, or information indicating a time stamp position of the first data unit is recorded as information related to the time of the first data unit, The header information including information about time is recorded in the data area different from the management area. And the management information file for managing the stream data including the transport stream and the real-time video object data is configured such that real-time video object data different from the stream data is recorded in the data area. In a reproduction method using an information storage medium configured to be stored in a single directory, and further recorded in the management information is time-related information corresponding to the I picture portion of the stream data,
Read the management information from the management area,
A reproduction method configured to read the stream data in the second data unit from the data area.
1以上の前記第1データ単位を含む前記第2データ単位を1以上含んで構成される前記第3データ単位の前記ストリームオブジェクトにより前記データエリアに記録される前記ストリームデータを形成し、前記第2データ単位内に前記第1データ単位の時間に関する情報を含むヘッダ情報を格納する手段と、
前記時間に関する情報を含む前記ヘッダ情報を含めて、前記ストリームデータを前記データエリアに記録する手段と、
前記リアルタイムビデオオブジェクトデータを前記データエリアに記録する手段と、
前記管理情報を前記管理エリアに記録する手段と、
前記管理情報のファイルを前記情報記憶媒体に記録する手段
を具備した記録装置。A data packet called a transport packet or an application packet, which has a data area for recording stream data including MPEG-encoded I picture information and including a transport stream, and a management area for recording management information of the stream data Is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and object data called a stream object is expressed as a third data unit. The stream data to be recorded in the data area is formed by the stream object of the third data unit including at least one second data unit including the unit, The data packet group of the first data unit that arrives during the recording of the third data unit has header information, and the data packet that arrives during the recording of the third data unit has a time having packet arrival time information The second data unit includes the header information, the header information includes information about the time of the first data unit, and the data as information about the time of the first data unit. Information related to the packet arrival time associated with a specific data packet of the packet group is recorded, or information indicating a time stamp position of the first data unit is recorded as information related to the time of the first data unit, The header information including information about time is recorded in the data area different from the management area. And the management information file for managing the stream data including the transport stream and the real-time video object data is configured such that real-time video object data different from the stream data is recorded in the data area. In a recording apparatus using an information storage medium configured to be stored in a single directory and further configured to record time-related information corresponding to the I picture portion of the stream data in the management information ,
Forming the stream data to be recorded in the data area by the stream object of the third data unit including one or more of the second data units including one or more of the first data units; Means for storing header information including information about the time of the first data unit in a data unit;
Means for recording the stream data in the data area, including the header information including information about the time;
Means for recording the real-time video object data in the data area;
Means for recording the management information in the management area;
A recording apparatus comprising: means for recording the management information file on the information storage medium.
前記管理エリアから前記管理情報を読み取る手段と、
前記データエリアから前記第2データ単位で前記ストリームデータを読み取る手段
を具備した再生装置。A data packet called a transport packet or an application packet, which has a data area for recording stream data including MPEG-encoded I picture information and including a transport stream, and a management area for recording management information of the stream data Is expressed as a first data unit, a data unit called a stream block or stream object unit is expressed as a second data unit, and object data called a stream object is expressed as a third data unit. The stream data to be recorded in the data area is formed by the stream object of the third data unit including at least one second data unit including the unit, The data packet group of the first data unit that arrives during the recording of the third data unit has header information, and the data packet that arrives during the recording of the third data unit has a time having packet arrival time information The second data unit includes the header information, the header information includes information about the time of the first data unit, and the data as information about the time of the first data unit. Information related to the packet arrival time associated with a specific data packet of the packet group is recorded, or information indicating a time stamp position of the first data unit is recorded as information related to the time of the first data unit, The header information including information about time is recorded in the data area different from the management area. And the management information file for managing the stream data including the transport stream and the real-time video object data is configured such that real-time video object data different from the stream data is recorded in the data area. In a playback apparatus using an information storage medium configured to be stored in a single directory, and further storing time-related information corresponding to the I picture portion of the stream data in the management information,
Means for reading the management information from the management area;
A playback device comprising: means for reading the stream data from the data area in units of the second data.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001325395A JP3806017B2 (en) | 1999-02-18 | 2001-10-23 | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP11-39461 | 1999-02-18 | ||
JP3946199 | 1999-02-18 | ||
JP2001325395A JP3806017B2 (en) | 1999-02-18 | 2001-10-23 | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000600426A Division JP3805985B2 (en) | 1999-02-18 | 2000-02-18 | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002197806A JP2002197806A (en) | 2002-07-12 |
JP3806017B2 true JP3806017B2 (en) | 2006-08-09 |
Family
ID=26378858
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001325395A Expired - Fee Related JP3806017B2 (en) | 1999-02-18 | 2001-10-23 | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3806017B2 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7613383B2 (en) | 2004-12-02 | 2009-11-03 | Hitachi, Ltd. | Editing method and recording and reproducing device |
JP4719454B2 (en) * | 2004-12-02 | 2011-07-06 | 株式会社日立製作所 | Recording method and recording apparatus |
JP4786299B2 (en) * | 2005-10-31 | 2011-10-05 | シャープ株式会社 | VIDEO REPRODUCTION DEVICE, VIDEO REPRODUCTION METHOD, VIDEO REPRODUCTION PROGRAM, AND RECORDING MEDIUM CONTAINING VIDEO REPRODUCTION PROGRAM |
JP5263308B2 (en) * | 2011-01-28 | 2013-08-14 | 株式会社日立製作所 | Recording / reproducing apparatus and recording medium |
-
2001
- 2001-10-23 JP JP2001325395A patent/JP3806017B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002197806A (en) | 2002-07-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3805985B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP5159969B2 (en) | Information storage medium for recording stream data, recording method, reproducing method, and reproducing apparatus | |
JP3715533B2 (en) | Information storage medium for stream information, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3806020B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3806017B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3806019B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP4138774B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3806018B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3927010B2 (en) | Stream data recording method, reproducing method, recording apparatus and reproducing apparatus | |
JP3615174B2 (en) | Information medium used for stream information recording, information recording method, information reproducing method, and information reproducing apparatus | |
JP3655570B2 (en) | Stream data storage medium, recording method and reproducing method using the medium, and recording apparatus and reproducing apparatus using the medium | |
JP4138776B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP4203042B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP4138775B2 (en) | Stream data information storage medium, recording method, reproducing method, recording apparatus, and reproducing apparatus | |
JP3896130B2 (en) | Information medium for recording stream data of MPEG transport stream and management information thereof, and recording method, playback method, recording apparatus, and playback apparatus using MPEG transport stream stream data and management information thereof | |
JP2002175683A (en) | Method of recording stream data and data structure for the same | |
JP3930503B2 (en) | Information medium for recording stream data of MPEG transport stream and management information thereof, and recording method, playback method, recording apparatus, and playback apparatus using MPEG transport stream stream data and management information thereof | |
JP4528749B2 (en) | Information medium used for stream information recording, information recording method, information reproducing method, and information reproducing apparatus | |
JP2002170337A (en) | Method for recording stream data and its data structure | |
JP2007294104A (en) | Information medium for recording stream data, recording method, reproducing method, and reproducing device | |
JP2005045830A (en) | Information medium for recording stream data, recording method, reproducing method, and reproducing apparatus | |
JP2007080509A (en) | Recording method, reproducing method, and reproducing apparatus of stream data |
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 |