JP2006261860A - 情報再生方法及び情報再生装置 - Google Patents

Abstract

【課題】ＤＶＤビデオディスクのコンテンツを、Markup言語などにより実現される再生制御情報を用いて再生できる。ライフ期間が過ぎたリソースもキャッシュメモリに保存できるようにし、リソースの再利用を可能にしている。
【解決手段】データアクセスマネージャと、数のリソース一時保存するファイルキャッシュと、前記ファイルキャッシュに保存される複数のファイルを管理するための管理情報の処理、及び前記データアクセスマネージャの制御を行うナビゲーションマネージャ（ファイルキャッシュマネージャを含む）とを有する。ファイルキャッシュマネージャは、ローディングされたリソースが、ライフ期間内であれば、第１のリストに登録し、前記ライフ期間が経過しているリソースであれば第２のリストに登録して管理する。
【選択図】 図１９

Description

この発明は、情報再生方法及び情報再生装置に関するもので、光ディスク等の情報記憶媒体から情報を再生する装置及び方法、さらには情報管理方法に及ぶものである。

近年、高画質・高機能を有するＤＶＤビデオディスク及びそのディスクを再生するビデオプレーヤの普及が進んでいる。また、上記高画質の実現以外にも、インタラクティブ性の向上、コンテンツ内容の拡充、コンテンツの提供環境の融通性が、コンテンツ供給者及びユーザからも望まれている。また、ユーザの撮影した静止画イメージデータやインターネット接続などにより入手した字幕テキスト等を、再生位置、再生領域、あるいは再生時間をユーザが自由に指定して再生できるような、再生環境が望まれている。
特開平１０−５００３６号公報

上記したように、高画質、高機能化したＤＶＤビデオディスク及びそのプレーヤのシステムに対しては、さらなる機能アップ、融通性を求める要望がある。

そこで、この発明の一実施形態による情報再生方法、情報再生装置及び情報管理方法の目的は、記録媒体である例えばＤＶＤビデオディスクに記録されたコンテンツを、Markup言語などにより実現される再生制御情報を用いて再生できるようにする。そして、ビデオオブジェクトやその他の付加情報の再生順序の自由な設定を実現し、再生順序の融通性を拡大できる環境を提供するものである。また、その再生されるコンテンツあるいはファイルをキャッシュメモリに一時保存できるようにし、データアクセスを簡略化できるようにする。

この発明の一実施の形態は、上記の目的を達成するために、データアクセスマネージャと、前記データアクセスマネージャが取得した複数のリソース（アーカイブデータ又はファイル）を一時保存するファイルキャッシュと、前記ファイルキャッシュに保存される複数のファイルを管理するための管理情報の処理、及び前記データアクセスマネージャの制御を行うナビゲーションマネージャとを有し、タイムラインが定義され、前記管理情報内には、前記複数のリソースを前記タイムライン上にマッピングするためのプレイリスト情報が含まれている。ここで、前記ナビゲーションマネージャ（ファイルキャッシュマネージャを含む）は、前記プレイリスト情報に応じて、前記ファイルキャッシュに前記複数のファイルをそれぞれローディングしかつマッピングし、また、ファイルキャッシュマネージャが、ローディングされたリソースがライフ期間内であれば、前記ライフ期間内のリソースを特定した情報を、第１のリストに登録し、前記ライフ期間が経過しているリソースであればこのリソースを特定した情報を、第２のリストに登録して管理することを特徴とする。

上記のようにファイルキャッシュマネージャが、前記ライフ期間内のリソースの特定情報を、第１のリストに登録し、前記ライフ期間が経過しているリソースであってもその特定情報を、第２のリストに登録するようにした。このため、ファイルキャッシュの記憶容量が許す限り、ライフ期間が過ぎたリソースを、ファイルキャッシュに保持することができる。つまり、ライフ期間が過ぎたリソースであっても、再度再生する必要が生じたときは、改めて記憶媒体から読み出す必要がない。

以下、図面を参照してこの発明の実施の形態を説明する。まず、この発明に係わるコンテンツ、管理情報、およびスクリプト等と、その再生環境について説明する。通常のＤＶＤビデオディスク（ＲＯＭ系ディスク）においては、プログラムチェーン（Program Chain：略してＰＧＣ）情報をもとに、再生するビデオオブジェクト（ＶＯＢまたはＥＶＯＢと呼ばれる）の再生順序を決定していた。ＰＧＣは、コンテンツ制作者が決定し、予めディスク上に記録されている。したがって、再生するビデオオブジェクトやその再生順序は、ディスクを製作したときに確定してしまい、ディスクを製作した後にこれを変更することができなかった。コンテンツ制作者としては、前述の再生するビデオオブジェクトやその再生順序を変更したいときは、新たにＤＶＤビデオディスクの管理情報を作り直して、変更したＰＧＣを新たなディスクに記録する必要がある。ユーザは、変更されたＰＧＣが記録されたＤＶＤビデオディスクを買いなおす必要があった。

そこで、この発明に係る技術では、ＤＶＤビデオディスクに記録されたコンテンツに対し、Markup言語などにより実現される再生制御情報を用いて、再生するビデオオブジェクトやその再生順序の制御を任意実現するようにしている。別の言い方をすると、ＤＶＤビデオディスク等の再生専用情報記憶媒体に記録されたコンテンツに対し、再生シーケンスの自由度を拡張できる環境を提供している。また、ＤＶＤビデオディスクに記録されたコンテンツを多様に利用できる環境を提供している。

図１は、この発明の一実施の形態に係るディスク状情報記憶媒体に記録される情報内容を説明する図である。図１（ａ）に示す情報記憶媒体１は、例えば波長６５０ｎｍの赤色レーザないし４０５ｎｍ（あるいはそれ以下）の青色レーザを用いる高密度光ディスク（High Density またはHigh Definition のDigital Versatile Disc：略してＨＤ＿ＤＶＤ）で構成できる。

図１（ｂ）に示すように、情報記憶媒体１は、内周側からリードイン領域１０、データ領域１２、およびリードアウト領域１３を含んで構成されている。この情報記憶媒体１では、ファイルシステムにＩＳＯ９６６０とＵＤＦのブリッジ構造を採用し、データ領域１２のリードイン側にＩＳＯ９６６０とＵＤＦのボリューム／ファイル構造情報領域１１を持っている。

データ領域１２内は、図１（ｃ）に示すように、ＤＶＤビデオコンテンツ（スタンダードコンテンツまたはＳＤコンテンツとも呼ぶ）を記録するためのビデオデータ記録領域２０、他のビデオデータ記録領域（アドバンスドコンテンツを記録するためのアドバンスドコンテンツ記録領域）２１、および一般のコンピュータ情報記録領域２２の混在配置が許されている。（ここで、コンテンツという複数表現はコンテントという単数表現の内容も含んでいる。また、コンテントはコンテンツの代表単数という意味も含んでいる。）
ビデオデータ記録領域２０内は、図１（ｄ）に示すように、ビデオデータ記録領域２０内に記録されたＨＤ＿ＤＶＤビデオコンテンツ全体に関する管理情報が記録されたＨＤビデオマネージャ（ＨＤＶＭＧ：High Definition対応のVideo Maneger）記録領域３０と、各タイトル毎にまとめられ、各タイトル毎の管理情報と映像情報（ビデオオブジェクト）がまとめて記録されたＨＤビデオタイトルセット（ＨＤＶＴＳ：High Definition対応のVideo Title Set：スタンダードＶＴＳとも呼ぶ）記録領域４０と、アドバンスドＨＤビデオタイトルセット（ＡＨＤＶＴＳ：アドバンスドＶＴＳとも呼ぶ）記録領域５０を含んで構成されている。

ＨＤビデオマネージャ（ＨＤＶＭＧ）記録領域３０の中は、図１（ｅ）に示すように、ビデオデータ記録領域２０全体に関わる管理情報を示すＨＤビデオマネージャ情報（ＨＤＶＭＧＩ：High Definition対応のVideo Manager Informaiton）領域３１と、そのバックアップ用としてＨＤビデオマネージャ情報領域３１と全く同じ情報が記録されたＨＤビデオマネージャ情報バックアップ（ＨＤＶＭＧＩ＿ＢＵＰ）領域３４と、ビデオデータ記録領域２０全体を示すトップメニュー画面が記録されたメニュー用ビデオオブジェクト（ＨＤＶＭＧＭ＿ＶＯＢＳ）領域３２を含んで構成されている。

この発明の一実施の形態では、ＨＤビデオマネージャ記録領域３０内に、メニュー表示時に並行して出力する音声情報が記録されるメニュー用オーディオオブジェクト（ＨＤＭＥＮＵ＿ＡＯＢＳ）領域３３を新たに設けている。さらに、この発明の一実施の形態では、ディスク（情報記憶媒体）１がディスクドライブに装填された直後の最初のアクセスで実行されるファーストプレイＰＧＣ用の言語選択メニューＶＯＢＳ（ＦＰ＿ＰＧＣＭ＿ＶＯＢＳ）３５の領域に、メニュー記述言語コード等が設定できる画面を記録可能に構成している。

各タイトル毎の管理情報と映像情報（ビデオオブジェクト）がまとめて記録された１個のＨＤビデオタイトルセット（ＨＤＶＴＳ）記録領域４０の内部は、ＨＤビデオタイトルセット記録領域４０内の全コンテンツに対する管理情報が記録されているＨＤビデオタイトルセット情報（ＨＤＶＴＳＩ）領域４１と、そのバックアップデータとしてＨＤビデオタイトルセット情報領域４１と全く同じ情報が記録されたＨＤビデオタイトルセット情報バックアップ（ＨＤＶＴＳＩ＿ＢＵＰ）領域４４と、ビデオタイトルセット単位でのメニュー画面の情報が記録されたメニュー用ビデオオブジェクト領域（ＨＤＶＴＳＭ＿ＶＯＢＳ）４２と、このビデオタイトルセット内でのビデオオブジェクトデータ（タイトルの映像情報）が記録されているタイトル用ビデオオブジェクト（ＨＤＶＴＳＴＴ＿ＶＯＢＳ）領域４３を含んで構成されている。

図２は、この発明の一実施の形態に係るディスク状情報記憶媒体に記録されるコンテンツを管理するファイルシステムの一例を説明する図である。図１の各領域（３０、４０）は、ＩＳＯ９６６０とＵＤＦのブリッジ構造を持ったファイルシステムではそれぞれ別々のファイルを構成することになる。従来の（スタンダードＳＤの）ＤＶＤビデオコンテンツは“ＶＩＤＥＯ_ＴＳ”と言う名のディレクトリ下にまとめて配置されている。一方、この発明の一実施の形態に係るファイルは、図２に例示されるように、ルートディレクトリ下に、高精細（High Definition）ビデオを扱う情報ファイルを格納するＨＶＤＶＤ＿ＴＳディレクトリと、アドバンスドオブジェクトを扱う情報ファイルを格納するＡＤＶ＿ＯＢＪディレクトリとが配置される構成を有している。

上記ＨＶＤＶＤ＿ＴＳディレクトリ内には、大別して、メニュー用に利用されるメニューグループに属するファイル群と、タイトル用に利用されるタイトルセットグループに属するファイル群とが存在する。メニューグループに属するファイル群には、ディスク全体を管理する情報を有するビデオマネージャ用の情報ファイル（HVI00001.IFO）と、そのバックアップファイル（HVI00001.BUP）と、メニューの背景画面として利用されるメニュー用拡張ビデオオブジェクトセットの再生データファイル（HVM00001.EVO〜HVM00003.EVO）とが格納される。

タイトルセット＃ｎのグループ（タイトルセット＃１グループ等）に属するファイル群には、タイトルセット＃ｎを管理する情報を有するビデオタイトルセット用の情報ファイル（HVIxxx01.IFO：xxx＝００１〜９９９）と、そのバックアップファイル（HVIxxx01.BUP：xxx＝００１〜９９９）と、タイトルとして利用されるタイトルセット＃ｎ用拡張ビデオオブジェクトセットの再生データファイル（HVTxxxyy.EVO：xxx＝００１〜９９９、yy＝０１〜９９）とが格納される。

さらに、アドバンスドタイトルセットのグループに属するファイル群には、アドバンスドタイトルセットを管理する情報を有するビデオタイトルセット用の情報ファイル（HVIA0001.IFO）と、そのバックアップファイル（HVIA0001.BUP）と、タイトルとして利用されるアドバンスドタイトルセット用拡張ビデオオブジェクトセットの再生データファイル（HVTAxxyy.EVO：xx＝０１〜９９、yy＝０１〜９９）と、アドバンスドタイトルセット用タイムマップ情報ファイル（HVMAxxxx.MAP：xxxx＝０００１〜９９９９）と、そのバックアップファイル（HVMAxxxx.BUP：xxxx＝０００１〜９９９９、図示せず）等が格納される。

また、前記ＡＤＶ＿ＯＢＪディレクトリ内には、スタートアップ情報ファイル（STARTUP.XML）、ローディング情報ファイル（LOAD001.XML）、再生シーケンス情報ファイル（PBSEQ001.XML）、マークアップ言語ファイル（PAGE001.XML）、動画データ、アニメーションデータ、静止画データファイル、音声データファイル、フォントデータファイル等が格納される。ここで、スタートアップ情報ファイルの内容は、例えば、動画データ、アニメーションデータ、静止画データ、音声データ、フォントデータ、更にはこれらのデータの再生を制御するためのマークアップ言語等のデータの起動情報となる。また、ローディング情報ファイルには、再生装置内にあるバッファにロードすべきファイルに関する情報が記述されているローディング情報（これはMarkup言語/Script言語/StyleSheetなどで記述できる）などが記録される。

再生シーケンス情報ファイル（PBSEQ001.XML）には、アドバンスドタイトルセットグループ内のアドバンスドタイトルセット用拡張ビデオオブジェクトセットの再生データファイルのどの区間を再生するかを定義する再生シーケンス情報（これもMarkup言語等で記述できる）等が記録される。

ここで、マークアップ言語（Markup言語）とは、文字の属性をあらかじめ定義されたコマンドに沿って記述する言語のことで、文字列に対して、書体の種類やサイズ、色などを属性として与えることができる。別の言い方をすると、マークアップ言語とは、文書の一部を「タグ」と呼ばれる特別な文字列で囲うことにより、文章の構造（見出しやハイパーリンクなど）や、修飾情報（文字の大きさや組版の状態など）を、文章中に記述していく記述言語である。

マークアップ言語を使用して書かれた文書は、テキストファイルになるため、テキストエディタを使って人間が普通に読むことが可能で、もちろん編集もできる。代表的なマークアップ言語としては、ＳＧＭＬ（Standard Generalized Markup Language）、ＳＧＭＬから発展したＨＴＭＬ（HyperText Markup Language）、ＴｅＸなどがある。

図３は、この発明の他の実施の形態に係るディスク状情報記憶媒体（光ディスク等）１に記録される情報内容のうち、アドバンスドコンテンツ記録領域の記録内容の一例を説明する図である。図３（ｃ）のアドバンスドコンテンツ記録領域２１は、図３（ｄ）に示すとおり、動画データを記録する動画記録領域２１Ｂ、アニメーションデータや静止画データを記録するアニメーション・静止画記録領域２１Ｃ、音声データを記録する音声記録領域２１Ｄ、フォントデータを記録するフォント記録領域２１Ｅ、およびこれらの再生を制御するための情報（これはMarkup言語/Script言語/StyleSheetなどで構成されている）を記録するMarkup/Script言語記録領域２１Ａを含むように構成される（これらの領域の記録順は図示のように領域２１Ａが先頭）。

この再生を制御するための情報（領域２１Ａの記録内容）には、アドバンスドコンテンツ（音声、静止画、フォント・テキスト、動画、アニメーション等を含んで構成される）および／またはＤＶＤビデオコンテンツの再生方法（表示方法、再生手順、再生切換手順、再生対象の選択等）がMarkup言語、Script言語、スタイルシート（StyleSheet）を用いて記述されてる。例えば、Markup言語として、ＨＴＭＬ（Hyper Text Markup Language）／ＸＨＴＭＬ（eXtensible Hyper Text Markup Language）やＳＭＩＬ（Synchronized Multimedia Integration Language）、Script言語として、ＥＣＭＡ（European Computer Manufacturers Association）ScriptやJavaScript（Javaは登録商標）のようなScript言語、ＣＳＳ（Cascading Style Sheet）といったStyleSheetなどを組み合わせながら用いることができる。

また、Makrup/Script言語記録領域２１Ａは、起動情報を記録するスタートアップ記録領域２１０Ａ、再生装置内のバッファにロードするファイルの情報を記録するローディング情報記録領域２１１Ａ、Markup言語やScript言語を用いてアドバンスドタイトルセットの拡張ビデオオブジェクトセットに格納されたＨＤ＿ＤＶＤ映像を再生する際の映像再生順序を定義するための再生シーケンス情報記録領域２１５Ａ、前述のMarkup言語を記録するMarkup記録領域２１２Ａ、前述のScript言語を記録するScript記録領域２１３Ａ、および前述のStyleSheetを記録するStyleSheet記録領域２１４Ａを含んで構成される。

なお、図３（ｅ）のローディング情報記録領域２１１Ａおよび再生シーケンス情報記録領域２１５Ａは、プレイリストの情報を格納する領域として利用できるようになっている。

図４は、この発明の他の実施の形態に係るディスク状情報記憶媒体（光ディスク等）１に記録される情報内容のうち、アドバンスドＨＤビデオタイトルセット記録領域の記録内容の一例を説明する図である。図４（ｄ）に示すアドバンスドＨＤビデオタイトルセット（ＡＨＤＶＴＳ：アドバンスドＶＴＳ）は、前述のアドバンスドコンテンツの１つであるMakrup言語から参照されることに特化されたビデオオブジェクトである。

アドバンスドＨＤビデオタイトルセット（ＡＨＤＶＴＳ）記録領域５０の内部は、図４（ｅ）に示すように、アドバンスドＨＤビデオタイトルセット記録領域５０内の全コンテンツに対する管理情報が記録されているアドバンスドＨＤビデオタイトルセット情報（ＡＨＤＶＴＳＩ）領域５１と、そのバックアップデータでアドバンスドＨＤビデオタイトルセット情報領域５１と全く同じ情報が記録されたアドバンスドＨＤビデオタイトルセット情報バックアップ領域（ＡＨＤＶＴＳＩ＿ＢＵＰ）５４と、アドバンスドＨＤビデオタイトルセット内でのビデオオブジェクト（タイトルの映像情報）データが記録されているアドバンスドタイトル用ビデオオブジェクト領域（ＡＨＤＶＴＳＴＴ＿ＶＯＢＳ）５３を含んで構成される。

図２に示したHVIA0001.IFO（あるいは図示しないVTSA0100.IFO）ファイル内にまとめて記録され、図４（e）に示したアドバンスドＨＤビデオタイトルセット情報（ＡＨＤＶＴＳＩ）領域５１の内部は、図示しないが、アドバンスドＨＤビデオタイトルセット情報管理テーブル（ＡＨＤＶＴＳＩ＿ＭＡＴ）、アドバンスドＨＤビデオタイトルセットＰＴＴサーチポインタテーブル（ＡＨＤＶＴＳ＿ＰＴＴ＿ＳＲＰＴ）、アドバンスドＨＤビデオタイトルセットプログラムチェーン情報テーブル（ＡＨＤＶＴＳ＿ＰＧＣＩＴ）、アドバンスドＨＤビデオタイトルセットセルアドレステーブル（ＡＨＤＶＴＳ＿Ｃ＿ＡＤＴ）、およびタイムマップ情報テーブル（ＴＭＡＰＩＴ）の各領域（管理情報グループ）に分かれている。

ここで、タイムマップ情報テーブル（ＴＭＡＰＩＴ）は、アドバンスドＨＤビデオタイトルセット情報（ＡＨＤＶＴＳＩ）領域５１の一部ではあるが、アドバンスドＨＤビデオタイトルセット情報領域５１と同じファイル（図２におけるHVIA0001.IFO）として記録することも可能であり、アドバンスドＨＤビデオタイトルセット情報領域５１と独立したファイル（例えばHVM00000.MAP）として記録することも可能である。

アドバンスドＨＤビデオタイトルセット情報管理テーブル（ＡＨＤＶＴＳＩ＿ＭＡＴ）には、該当するビデオタイトルセットに共通する管理情報が記録されている。この共通する管理情報をアドバンスドＨＤビデオタイトルセット情報（ＡＨＤＶＴＳＩ）領域５１の中で最初の領域（管理情報グループ）に配置する事で、即座にビデオタイトルセット内の共通管理情報を読み込めるので、情報再生装置の再生制御処理の簡素化と制御処理時間の短縮化が図れる。

アドバンスドＨＤビデオタイトルセット情報管理テーブル（ＡＨＤＶＴＳＩ＿ＭＡＴ）は、ビデオタイトルセット内の共通管理情報として、以下の情報を格納できるようになっている。すなわち、アドバンスドＨＤビデオタイトルセット情報管理テーブル内は、アドバンスドＨＤビデオタイトルセット識別子（ＡＨＤＶＴＳ＿ＩＤ）、アドバンスドＨＤＶＴＳの終了アドレス（ＡＨＤＶＴＳ＿ＥＡ）、アドバンスドＨＤＶＴＳＩの終了アドレス（ＡＨＤＶＴＳＩ＿ＥＡ）、ＨＤ＿ＤＶＤビデオ規格のバージョン番号（ＶＥＲＮ）、AＨＤＶＴＳカテゴリタイプ（ＡＨＤＶＴＳ＿ＣＡＴ）、AＨＤＶＴＳＩ＿ＭＡＴの終了アドレス（ＡＨＤＶＴＳＩ＿ＭＡＴ＿ＥＡ）、AＨＤＶＴＳＴＴ＿ＶＯＢＳの先頭アドレス（ＡＨＤＶＴＳＴＴ＿ＶＯＢＳ＿ＳＡ）、AＨＤＶＴＳ＿ＰＴＴ＿ＳＲＰＴの先頭アドレス（ＡＨＤＶＴＳ＿ＰＴＴ＿ＳＲＰＴ＿ＳＡ）、AＨＤＶＴＳ＿ＰＧＣＩＴの先頭アドレス（ＡＨＤＶＴＳ＿ＰＧＣＩＴ＿ＳＡ）、AＨＤＶＴＳ＿Ｃ＿ＡＤＴの先頭アドレス（ＡＨＤＶＴＳ＿Ｃ＿ＡＤＴ＿ＳＡ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのアングル数（ＡＴＲ１＿ＡＧＬ＿Ｎｓ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのビデオ属性（ＡＴＲ１＿Ｖ＿ＡＴＲ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのオーディオストリーム数（ＡＴＲ１＿ＡＳＴ＿Ｎｓ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのオーディオストリーム属性テーブル（ＡＴＲ１＿ＡＳＴ＿ＡＴＲＴ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのサブピクチャストリーム数（ＡＴＲ１＿ＳＰＳＴ＿Ｎｓ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのサブピクチャストリーム属性テーブル（ＡＴＲ１＿ＳＰＳＴ＿ＡＴＲＴ）、属性情報１（ＡＴＲ１）をもつビデオオブジェクトのマルチチャネルオーディオストリーム属性テーブル（ＡＴＲ１＿ＭＵ＿ＡＳＴ＿ＡＴＲＴ）（以下、属性情報２、属性情報３が続く）の各種情報が格納可能に構成されている。

なお、アドバンスドＨＤビデオタイトルセット情報管理テーブル（ＡＨＤＶＴＳＩ＿ＭＡＴ）に格納可能な情報のうち、スタンダードＶＴＳに存在したＨＤＶＴＳＭ＿ＶＯＢＳの先頭アドレス（ＨＤＶＴＳＭ＿ＶＯＢＳ＿ＳＡ）は、アドバンスドＶＴＳにおいてはＨＤＶＴＳＭ＿ＶＯＢＳがないため、存在しなくてもよい（もしくは予約領域とすることができる）。また、スタンダードＶＴＳに存在したＨＤＶＴＳＭ＿ＰＧＣＩ＿ＵＴの先頭アドレス（ＨＤＶＴＳＭ＿ＰＧＣＩ＿ＵＴ＿ＳＡ）はアドバンスドＶＴＳにおいてはＨＤＶＴＳＭ＿ＶＯＢＳがないため存在しなくてもよい（もしくは予約領域とすることができる）。また、スタンダードＶＴＳにおいて存在したＨＤＶＴＳＭ＿Ｃ＿ＡＤＴの先頭アドレス（ＨＤＶＴＳＭ＿Ｃ＿ＡＤＴ＿ＳＡ）はアドバンスドＶＴＳにおいてはＨＤＶＴＳＭがないため存在しなくてもよい（もしくは予約領域とすることができる）。また、スタンダードＶＴＳにおいて存在したＨＤＶＴＳＭ＿ＶＯＢＵ＿ＡＤＭＡＰの先頭アドレス（ＨＤＶＴＳＭ＿ＶＯＢＵ＿ＡＤＭＡＰ＿ＳＡ）はアドバンスドＶＴＳにおいてはＨＤＶＴＳＭがないため存在しなくてもよい（もしくは予約領域とすることができる）。さらに、スタンダードＶＴＳに存在したＨＤＶＴＳ＿ＶＯＢＵ＿ＡＤＭＡＰの先頭アドレス（ＨＤＶＴＳ＿ＶＯＢＵ＿ＡＤＭＡＰ＿ＳＡ）は、アドバンスドＶＴＳにおいては、代わりのタイムマップ情報テーブルがあるため存在しなくてもよい（もしくは予約領域とすることができる）。

ここで、アドバンスドＨＤビデオタイトルセット情報管理テーブル（ＡＨＤＶＴＳＩ＿ＭＡＴ）内に格納されるアドバンスドＶＴＳのカテゴリを示す情報（ＡＨＤＶＴＳ＿ＣＡＴ）は、下記のとおり定義できる：
ＡＨＤＶＴＳ＿ＣＡＴ＝0000b：ＡＨＤＶＴＳのカテゴリを特定せず
ＡＨＤＶＴＳ＿ＣＡＴ＝0001b：予約
ＡＨＤＶＴＳ＿ＣＡＴ＝0010b：アドバンスドコンテンツを伴ったアドバンスドＶＴＳ
ＡＨＤＶＴＳ＿ＣＡＴ＝0011b：アドバンスドコンテンツを伴わないアドバンスドＶＴＳ
ＡＨＤＶＴＳ＿ＣＡＴ＝その他：予約。

ここで、“ＡＨＤＶＴＳ＿ＣＡＴ＝0010b”でカテゴリが示される「アドバンスドコンテンツを伴ったアドバンスドＶＴＳ」は、基本的にMarkup言語を伴って構成されるアドバンスドＶＴＳを示す。つまり、このカテゴリではコンテンツ制作者が「Markup言語により制御されるアドバンスドＶＴＳ」を想定しており、Markup言語の制御に従ってのみ再生することが許され、アドバンスドＶＴＳ単体で再生することは許されない。例えば、コンテンツ制作者が特定の条件の下でのみ、ある区間のアドバンスドＶＴＳの再生を許すようなMarkup言語を記述した場合、アドバンスドＶＴＳ単体での再生を許してしまうと、この区間が特定の条件以外でも再生ができてしまうことになる。“ＡＨＤＶＴＳ＿ＣＡＴ＝0010b”のカテゴリのアドバンスドＶＴＳではこのような再生が禁止される。

“ＡＨＤＶＴＳ＿ＣＡＴ＝0011b”でカテゴリが示される「アドバンスドコンテンツを伴わないアドバンスドＶＴＳ」は、基本的にMarkup言語を伴わずアドバンスドＶＴＳのみで再生が行えるアドバンスドＶＴＳを示す。これは、例えばＤＶＤ−ＶＲ／ＨＤＤＶＤ−ＶＲといった他のレコーディング規格（ＶＲ規格と呼ぶ）とこの発明の実施の形態における再生専用規格（ビデオ規格と呼ぶ）の再生互換を保つためのアドバンスドＶＴＳを想定している。ビデオ規格とＶＲ規格はそれぞれの用途の相違のため（ビデオ規格はインタラクティブ性に重点をおき、ＶＲ規格は編集機能に重点をおく）ため規格が異なっている。ここで、構造的に単純化されたアドバンスドＶＴＳを２つの規格において共通化することにより、目的のことなる２つの規格においても再生互換をとることが可能となる。例えば、ＶＲ規格に則った記録機器において、アドバンスドＶＴＳモードにおいて記録した情報記憶媒体は、すべての再生装置において再生することが可能となる。

図５は、この発明の一実施の形態に係るＨＤ＿ＤＶＤプレーヤの再生システムモデルを大きな単位の機能モジュールで示した図である。“Data Source”は、このＨＤ＿ＤＶＤプレーヤが再生を行う際にアクセスし得るデータ格納場所を指す。“Data Source（データソース）”には、“Disc”、“Persistent Storage”、“Network Server”等があり得る。“Disc”は図１〜図４のディスク１に相当する。

ホームネットワーク上に存在するＮＡＳ（Network Attached Storage）等もパーシスタントストレージ（Persistent Storage）の範疇に含まれる。“Network Server”はインターネット上に存在するサーバを指し、一般にはＤＶＤディスクを提供する映画会社等が運営するものが想定される。

“Advanced Content Player（アドバンスドコンテンツプレーヤ）”は、ＨＤ＿ＤＶＤプレーヤの再生システムモデル全体を指すものであり、大きなモジュールとして、“Data Access Manager（データアクセスマネージャ）”、“Data Cache（データキャッシュ）”、“Navigation Manager（ナビゲーションマネージャ）”、“Presentation Engine（プレゼンテーションエンジン）”、“User Interface Controller（ユーザインターフェースコントローラ）”、“AV Renderer（ＡＶレンダラー）”等で構成される。

“Data Access Manager”は、“Advanced Content Player”内のモジュールと“Data Source”との間でデータのやり取りを管理する。“Data Cache”は、“Navigation Manager”や“Presentation Engine”が再生に必要とするデータを一時的に蓄えておくデータ格納装置である。

“Navigation Manager”は、“Advanced Navigation”を読み込み、解釈し、“Presentation Engine”や“AV Renderer”等を制御して、コンテンツタイプ２または３ディスクの再生制御を管理する。またディスク挿入時には、ディスク上に格納された“Startup File”を読み込み、再生制御に必要なＨＤ＿ＤＶＤプレーヤの設定を行う。

“Presentation Engine”は、“Advanced Navigation”の再生制御情報に従って“Navigation Manager”が発行する制御コマンドや信号に基づいて、“Primary Video Set”、“Secondary Video Set”、“Advanced Element”データを“Data Access Manger”を利用して“Data Source”から読み込みしたり、“Data Cache”から読み込みを行い、再生を行い、その出力を“AV Renderer”に送る。

“AV Renderer”は、“Advanced Navigation”の再生制御情報に従って“Navigation Manger”が発行する制御コマンドや信号に基づいて、“Presentation Engine”が出力する映像データや音声データのαブレンディングやミックス制御を行い、最終的なＨＤ＿ＤＶＤプレーヤから外部のTVモニタやスピーカへの信号出力を実施する。

“User Interface Controller”は、フロントパネルやリモコン、マウスなどのユーザインタフェースからの入力信号をイベントとしてNavigation Managerに伝える。またマウスカーソルの表示制御を実施する。

図６は、図５をデータの流れの観点から詳細化した図である。“Persistent Storage”や“Network Manager”には、“Advanced Navigation”の再生制御の結果、データを格納する容量が許す限りあらゆる種類のデータを格納し、ＨＤ＿ＤＶＤプレーヤによって読み込むことも、書き込むことも可能である。一般に“Advanced Content Player”が読み込んで再生に用いるデータとしては、先にあげた“Advanced Navigation”、“Advanced Element”、“Secondary Video Set”があり得る。“Primary Video Set”はDisc上にのみ格納されており、“Persistent Storage”や“Network Server”には格納されない。

“Disc”に格納されるデータとしては、“Advanced Navigation”、“Advanced Element”、“Primary Video Set”、“Secondary Video Set”があり得る。“Disc”は、読み込み専用メディアであり、“Advanced Navigation”の再生制御によってなんらかのデータが書き込まれることは無い。

“Data Access Manager”は“Persistent Storage Manager”、“Network Manager”、“Disc Manager”を内包している。一般にそれぞれ、“Persistent Storage”、“Network Server”、“Disc”からのデータアクセスを管理するが、“Persistent Storage”に含まれる“NAS （Network Attached Storage）”に関しては、“Persistent Storage Manager”が“Network Manager”の機能を利用してデータアクセスを管理すると考えてもよい。

“Disc Manager”から“Navigation Manager”に向かう線は、ディスク挿入時に、所定のディスクタイプの判別処理の後、“Advanced Navigation”に含まれる“Startup File”を“Navigation Manager”が読み込む流れを示す。Disc ManagerからPrimary Video Playerに向かう線は“Primary Video Set”のデータの流れを示す。“Disc Manager”から“Secondary Video Player”に向かう線はDisc上の“Multiplexed Data Structure”内にインターリーブ（Interleave）された“Secondary Video Set”のデータの流れを示す。

“Disc Manager”から“File Cache Manager”に向かう線は、“Disc”上の“Multiplexed Data Structure”内にInterleaveされたAdvanced Elementのデータの流れを示す。“Disc Manager”から“File Cache”に向かう線は、“Disc”上の“Multiplexed Data Structure”に含まれない、“Advanced Navigation”、“Advanced Element”、“Secondary Video Set”のデータの流れを示す。

Persistent StorageやNetwork ServerからFile Cacheに向かう線は、Advanced Navigation、Advanced Element、Secondary Video Setの流れとその逆の流れを示す。Persistent StorageやNetwork ServerからStreaming Bufferに向かう線は、Secondary Video Setの流れを示す。

File CacheからNavigation Managerに向かう線は、主にAdvanced NavigationをNavigation Managerが読み込む流れを示す。File Cache ManagerからFile Cacheに向かう線は、Disc ManagerからFile Cacheに送られたAdvanced Elementのデータをファイル単位でFile Cacheに書き込む流れを示す。File CacheからAdvanced Element Presentation Engineに向かう線は、Advanced Elementの流れを示す。File CacheからSecondary Video Playerに向かう線は、Secondary Video SetのＴＭＡＰやＳ−ＥＶＯＢを一旦File Cacheにファイルデータとして格納したものを再生する際のデータの流れを示す。

Streaming BufferからSecondary Video Playerに向かう線は、Persistent StorageやNetwork Serverに格納されている大きなSecondary Video Setを少しずつ一旦Streaming Bufferに読み込み、その後、Secondary Video Playerに供給する流れを示す。これは、一般にネットワークのようにデータの読み込み速度が一定でないData Sourceからのデータ供給を行う場合に、データの読み込み速度の揺らぎを吸収して、Secondary Video Setの再生を途切れにくくするための施策である。

Advanced NavigationからPresentation EngineとAV Rendererに向かう点線は制御信号を示すが、Presentation Engineに向かう線の場合、Markup/Scriptで構成されるAdvanced Navigationデータ内に格納されている、テキストサブタイトルのデータを供給する場合もあり得る。

したがって上記のモデルによると、プレイリスト（複数種類を作成しておくことが可能）により、データキャッシュに読み込まれたファイル或いはアーカイブデータを、他の外部から取り込んだデータとともに組み合わせて利用再生できるようにセットすることができる。ディスクに記録されているリソースのコンテンツが１種類であったとしても、プレイリストを複数記述しておくことで、リソースを複数種のシーケンスで再生することが可能となる。また操作入力、ネットワークから取り込んだグラフィックス映像などと組み合わせて再生ことも可能となる。さらに、外部から取り込む情報は、バージョンアップ可能であるために、リソース及びプレイリストを設計するとき、将来の利用形態を見込んで設計することも可能である。

図７から図１４は、プレイリスト（Playlist）に関する説明である。

このPlaylistには再生時間が記述されるとともにロード時間が記述される。つまりこの発明の一実施の形態では、Playlistの情報内に読み込みの時間を記述することでData Cacheの使用量を測定（または検出）可能に構成する。これにより、 Data Cache使用量の測定（検出）結果を利用することでオーサリング時には効率的なコンテンツ作成を可能にし、また削除しなくても良いObjectをData Cacheに保持しておくことでPlayerのパフォーマンスを向上させるように構成することができる。以下はその説明である。

図７はTimeLine上の各オブジェクトの再生時間及びLoad開始時間を例示した図である。図中の直線で表した現在時刻から点線で表したところへjumpした場合、Object3およびObject6はすでに再生が終わっている時刻のため、考慮する必要はない。

また、Object5はまだLoad開始時刻が来ていないためこちらも考慮する必要がない。Object1は現在時刻ではLoadが始まっていたが、終了はしておらず、jump先では再生途中のObjectであるので、別ファイルで持っているObject1と同様のコンテンツをLoadして再生する。Object2はLoad途中へjumpしているため、こちらも少なくともLoad開始時刻からjump先の分だけloadが完了してから再生が開始される。

Object4についてはLaodは完了している時刻からjumpしているのでData cach内を検索して存在を確認し、存在が確認されたら再生を行なう。これはPlaylistの記述にLoadstart属性（図９または図１１参照）を付加することで実現できる。

図８は上記の処理に対応したフローチャートである。jump動作を行なった場合、Playlist内の記述をチェックし（ステップＳＴ２００）、Data Cache内にObjectが格納されているかどうかのサーチを行う（ステップＳＴ２０２）。Data Cache内にObjectが格納されている場合は（ステップＳＴ２０４イエス）、それを使用して再生を行なう。

Data Cache内にObjectが格納されていない場合は（ステップＳＴ２０４ノー）、Data Cacheに格納する余裕があるかどうかをチェックする（ステップＳＴ２０６）。Data Cacheが一杯の場合は（ステップＳＴ２０６イエス）、不要なObjectの削除を行い（ステップＳＴ２０８）、必要Dataを、用意されたファイルからData Cacheに読み込み（ステップＳＴ２１０）、再生を行なう。

Data Cacheに余裕がある場合には（ステップＳＴ２０６ノー） Data CacheからのObject削除は行なわず、 Data Cacheへ必要Dataの読み込みを行い（ステップＳＴ２１０）、再生する。これによって、同時に使用できるData Cacheのsizeが規定されていても、機器毎にそれ以上のData Cacheを持ち、格納したコンテンツの削除を行なわないことによって、jumpなどで再度コンテンツが必要となった場合にData Cache内に格納されたコンテンツを検索して使用することが可能となる。このためData Cacheの容量を充分大きく持つことでPlayerの能力を向上させることができる。これによって機器間の差別化が図れる。

さらに、（PlaylistにLoadstart属性を付加することで）ある時刻毎のData Cacheの使用量が計算できるようになるため、コンテンツ作成時にData Cacheの容量に余裕のある場所にさらに別のObjectを設定することが可能となり、効率的なコンテンツ作成が可能になる。

図９および図１１は、PlaylistにLoadstart属性を付加した上記Playlistの具体例である。図９、図１０はLoadStartの時間を大きくApplicationの単位で用意した場合を例示している。この場合、各Application内に使用されるObjectはLoad開始時刻（図９のLoadstart‘0’、Loadstart‘100’、Loadstart‘400’、Loadstart‘1200’等）から同じタイミングでData CacheへLoadされる。なお、Application1のLoadstartは‘0’からなので、（Loadstart‘0’はデフォルトとして）省略することも考えられる。

図１１は各Object毎にLoad開始時刻（Loadstart‘200’、Loadstart‘100’、Loadstart‘500’、Loadstart‘400’等）を設定した例である。このように記述すれば（図９のApplication毎の例よりも）細かい制御が可能になるが、object毎に読み込みや削除の処理を行なうことが必要になるため、再生系の処理は複雑になる。また、各object毎にLoad開始時刻を設定した場合、単純な例では読み込みが早かったものから順番に削除していくことになるが、特別な例を考えた場合、削除の順序を規定しても良い。例えばある程度容量の小さいものは削除せずにData Cache内に残しておくことや、再生時に複数回割り当てられるものは削除しないなどの規定を設けることもできる。また、明示的に新たに（Data Cacheからの削除可否を指定するための）属性を設けても良い。

図１２はシステムモデル例である。この例では、Disc上のPVS（Primary Video Set）はMain VideoのAngleが９本、Main Audioが８本以下、SP (Sub-picture) Streamが３２以下、Sub Videoが１つ以下、Sub Audioが８以下含まれている。また、Network上、あるいはDisc上、あるいはPersistent Storage上などに存在するSVS（Secondary Video Set）は、それぞれ用途に応じて、Substitute AudioVideo（Main Video、Main Audio、SP Streamの追加）、Substitute Audio、（Main Audioの追加）、Substitute Subtitle（SPの追加）、Substitute SubAudioVideo（Sub Video、Sub Audioの追加）の４つが使用される。それぞれ設定できるStreamの数は、図１２中カッコ内に例示されている。

Main Videoの場合、PVSのMain VideoとSubstitute AudioVideoのMain Videoが両方存在した場合、どちらか一方をDecoderへ入力することとし、同時には使用しない。Angleが複数存在する時も同様（同時使用せず）で、切り替えて表示することになる。SP、Main Audioについても同様に選択してDecodeを行なう。これらは再生途中で切り替わっても良い。Advanced SubtitleについてはAdv TT PlayerでDecodeした後、SP Streamが存在している場合にはどちらかを選択してSP Plane（副映像表示プレーン）へ表示する。そのほかMainとSubのAudioはMixingしてSpeakerへ、Main VideoはMain Video Plane（メインビデオ表示プレーン）へ、Sub VideoはSub Video Plane（サブビデオ表示プレーン）へそれぞれ入力し、再生を行なう。

図１３はこれらを実現するためのPlaylistの例である。ルート要素直下のTitleタグでこのTitleのidと設定するTitle TimeLineの長さ800を定義している。そしてその子要素に前述のPVSやSVSの設定を行なう。まず始めはPrimaryVideoSetClipでPVSを定義している。これはTitle TimeLine上の100から200の時間に設定され、TMAP1.tmpファイルで参照される。このPVSはVideoに2つのアングルを持ち、Angle1をtrack1にAngle2をtrack2に設定している。またAudioはstream-number1，2，3をそれぞれtrack1, 2, 3へ設定しそれぞれEN、JA、ZHのlangcodeを設定している。Subtitleも同様にstream-number1, 2, 3をtrackの1, 2, 3に設定しlangcodeもEN:1、JA:1、EN:2としている。Sub videoはtrack1に、Sub Audioはstreamnumber1, 2をそれぞれtrack1, 2に設定している。

同様にTitle TimeLine上400から600にPrimaryVideoSet、700から800にSubstituteAudioVideo、400から600にSubstituteSubAudioVideoとSubstitute Audioが２つ、0から600にAdvancedSubtitleが設定されている。またApplicationは0から800にapp2.xmlとapp3.xmlの2種類が設定されている。

ここで、再生機器はApplicationのlangcodeを用いてそれと同じlangcodeを持つtrackをデフォルトの再生trackとしても良い。当てはまるものがない場合は、例えばtrack番号の一番小さいものをデフォルトとすることで矛盾なく再生することができる。

図１４はこの例をTitle TimeLine上に配置した時の図である。それぞれのClipにはそれぞれのTypeに応じてstreamが含まれる。ここで、Title TimeLine 400〜600に配置されたPVS2と２つのSVSのAudioについて、trackに異なる番号を設定（この例ではPVSには1、2；SVSにはそれぞれ3と4）することで、ユーザにPVS、SVSを意識させずにstreamの切り替えを行なうことができるようにしている。

また、PVSにストリームが存在してもPlaylist内にTrackとして記述しなければユーザには選択ができなくなり、さらにSVSにTrack Numberを割り当てることで置き換えが可能になる。こうすることで、PlaylistのScriptで条件が揃った場合にのみ再生を許したり、Playlistを変える事で（Streamの変更をしなくても）再生可能なコンテンツを制御することができるようになる。

上記のプレイリストの管理は、Navigation Manager （図６参照）内のPlaylist Managerにより行われている。

ここで、図６に示したFile Cache Manager には、ファイルシステム（File System)が用意されている。このFile System は、Playlist に呼応して、File Cache に格納されたファイル（File）又はアーカイブファイル(Archived file or Archived Data)を管理する。つまり、Navigation Manager, Presentation Engine, Advanced Element Engine, Data Access Manager からの要求によって、File cache のファイルの書込み・読出しを制御する。File Cache は、データキャッシュの一部であり、ファイルを一時的に保存する場所として利用される。

まず、File Cache は、最低６４ＭＢ（メガバイト）の記憶領域を持つように定義されている。File Cache の最低容量が定義されることで、プロバイダは、記録媒体のコンテンツ及び管理情報の容量の設計が可能となる。また、File Cache は、１つのメモリブロックのサイズが５１２バイトに設定されている。このブロックサイズは、消費単位として決められており、たとえ１バイトのファイルが書き込まれたとしても、５１２バイトが割り当てられて、消費される。５１２バイト単位でアクセスすることで、容易で高速なアクセスが可能である。またアドレス管理も用意である。

File Cache では、複数ファイルがアーカイブされたデータ（Archived Data)とアーカイブされていないファイルを扱うことができる。Archived Dataの名前は、ファイル名が８文字で表され、拡張子が３文字で表され、ディスク内においては、ユニークなファイル名である。またArchived Dataの中のファイルの名前は、３２バイト（拡張子を含む）で表される。また最大のファイルサイズは、６４ＭＢである。さらに、最大のファイル数は、ディスク上では２０００個、アーカイブ内では２０００個と取り決めされている。

リソース（Resource)の管理は次の情報に基づいて管理される。即ち、Playlsit Manager (プレイリストマネージャ)が管理するResource Information（リソース情報）に記述されたTitle Timeline （タイトル時間軸）上のmapping（マッピング） 情報と、File Cache Manager（ファイルキャッシュマネージャ）の管理するResource Management Table （リソースマネジメントテーブル）に記述されるFile list（ファイルリスト） とDelete List（削除リスト）がある。

アプリケーションプログラミングインターフェース（ＡＰＩ）からのアクセスは、プレイリストマネージャ管理下のデータは読出し専用である。ＡＰＩ用のディレクトリとして用意されるテンポラリーディレクトリー（Temp ディレクトリ）内ファイルは、読み取り、書込みが可能である。

図１５には、上記したFile Cache 内に格納されたファイル或いはアーカイブデータのイメージを示している。図１６には、アーカイブデータ(Archived Data)の構成例を示している。ファイルヘッダ（File Header）、リソースサーチポインタ（Resource Search Pointer）があり、続いて順次リソースデータ(Resource Data #1,#2…)が配置されている。Archived Data内の最大のファイル数は２０４７個に制限されている。ファイルヘッダには、ファイル識別子（ＦＩＬＥ＿ＩＤ）、バージョン番号（ＶＥＮ）、ファイルタイプ（Ｆｉｌｅ＿ＴＹ)、エンコーディングタイプ（ＥＮＣ＿ＴＹ）、サーチポインタ数（ＳＲＰ＿Ｎｓ）、このファイルの終了アドレス、などが含まれる。リソースサーチポインタ内には、リソースデータのスタートアドレス、データサイズ、このデータのコレクションコード（ＣＲＣ）、このデータのマインタイプ（ファイルのタイプ）、このデータのファイル名などが含まれる。

図１７には、アーカイブデータをアクセスする場合、例えばファイルキャッシュから読み出す場合の指定方法を示している。指定データは、ＵＲＩで記述される。この場合の先頭（左端）は、”file”と記述される。図１７においてＸＸＸは、第１のパスセグメント（First path segment)と称され、ここの記述は、ファイルキャッシュにキャッシュするファイルが格納されている場所を示している。例えば"dvddisc"（ディスクに格納されている場合）, "filecache"（ファイルキャッシュに格納されている場合）, "removable"（メモリ媒体など）,"fixed"（内蔵のメモリなど）などが利用される。ｙｙｙ・ｙｙｙは、ディレクトリーセグメントと称される領域であり、読み出したいリソースを含むアーカイブファイルの名前である。アーカイブファイルのファイル名は、先に説明した８文字、拡張子３文字のルールが適用される。次のＺＺＺ．ＺＺＺは、フィアイル名セグメントと称されるものである。ここには、読み出したいリソースの名前と同一のファイル名が記述される。ファイル名は３２バイトでありここには拡張子を含む。

上記のＵＲＩ情報（リソース指定情報と仮に呼ぶ）による指定方法によって、アーカイブデータの中に含まれる、所望のファイルだけでもアクセスして読み出すことができる。つまり、アーカイブデータのリソースサーチポインタと、上記リソース指定情報を用いる。そして、リソース指定情報により指定されたファイルがアーカイブデータ内に含まれるときは、リソース指定情報に対応するサーチポインタでサーチして、所望のファイルを読み出すことができる。

上記したＵＲＩで、ファイルキャッシュ内の領域をアクセスする領域は２種類ある。１つは、読出しのみ可能な領域である。また他の１つは読出し、書込み可能な領域である。読出しのみ可能な領域は、プレイリストマネージャによりファイルのライフ期間が管理されている領域である。この場合は、例えばfile:///filecache/yyy.yyy/zzz.zzzのように記述される。読出し、書込み可能な領域は、テンポラリーディレクトリー以下の領域である。この場合は、例えばfile:///filecache/temp/zzz.zzz（temp以下にファイルが直接有る場合）と記述される。さらには、file:///filecache/temp/yyy.yyy/zzz.zzzと記述される（temp以下にアーカイブデータがあり、その中にファイルが有る場合）。Tempの記述があるファイルは、例えば何らかのイベントのあった後に不要になると、消去可能なファイルである。例えばゲームなどでユーザ操作入力に応じてイベントが生じることがある。このイベントで使われた一時的なファイルは消去されてもよいので、このようなファイルの指定情報には、tempが使用される。

図１８（Ａ）には、ファイルキャッシュマネージャがリソース情報を作成する際に用いられる情報の例を示している。ファイルキャッシュへのリソースの読み込み及び消去は、プレイリストマネージャで把握され、そしてリソースの読み込み及び消去は、タイムライン上のローディング期間（Loading Period）のスタート及びエンド期間（Start/End Time）、ライフ期間（Life Period）のスタート及びエンド期間（Start/End Time）に基づいて行われる。図１８（Ｂ）には、アーカイブファイルのタイムライン上でのローディング期間とライフ期間の例を示している。

図１９は、プレイリストマネージャ（Playlist Manager）と、ファイルキャッシュマネージャ（Filecache Manager）において管理されているリソース情報(Resource Information)の説明図である。リソース情報は、タイトルタイムライン（Title Time line）上に複数のファイルを管理している。いま、ファイルＡは、ローディング期間がｔ０１−Ｔ１に設定され、ライフ期間がｔ１１−ｔ２４に設定されているものとする。またファイルＢは、ローディング期間がｔ０２−ｔ１２に設定され、ライフ期間がｔ２２−ｔ３２に設定されているものとする。さらにファイルＣは、ローディング期間がｔ２１−ｔ２３に設定され、ライフ期間がｔ３１−Ｔ４に設定されているものとする。

すると、リソースマネジメントインフォメーション上では、時点Ｔ１では、ファイルリストにファイルＡ（ファイルＡはローディングが完了しているから）が登録されている。

時点Ｔ２では、ファイルリストにファイルＡ、Ｂ（ファイルＡ、Ｂはローディングが完了しているから）が登録されている。時点Ｔ３では、ファイルリストにファイルＢ，Ｃ（ファイルＢ，Ｃはローディングが完了しているから）が登録され、削除リスト（Delete List）にファイルＡ（ファイルＡはライフ期間が過ぎているから）が登録されている。時点Ｔ４では、消去リスト（Delete List）にファイルＡ、Ｂ，Ｃ（ファイルＡ、Ｂ，Ｃはライフ期間が過ぎているから）が登録されている。

上記のようにリソースマネジメント情報は、ファイルリストと、削除リストの記述エリアを含む。このために、ライフ期間が過ぎたファイルであっても、再利用することが可能である。つまり、逆送り再生、繰り返し再生などで利用するファイルを、ファイルキャッシュに保存しておくことができる。つまり、ライフ期間は過ぎたのであるが、ファイルリストから削除リストに登録し直すだけで、登録されたファイルは実態が残っている。

これにより記録媒体のアクセス回数を低減することができる。また、放送メディアから取得したデータは、一度破棄すると、再度放送されない限り取得することができない。しかし上記した方法によりデータ或いはファイルを管理することにより、放送メディアで送られて来たデータを何回も利用することができる。利用するデータは、音声やビデオデータ、グラフィックデータ、スクリプト、アプリケーションなど多種である。ジャンプ或いは再利用により必要となったファイルは、削除リストからファイルリストに登録しなおされる。これらの更新のタイミングは、ローディングが終了した時点と、ライフ期間が終了したときに設定されている。タイトルタイムラインは、例えば、装置内の基準となるタイマーの時間を利用している。勿論、タイマーは、逆送りや高速再生、ジャンプがあったときは、再スタート時に適切な時間にプリセットされる。

ファイルキャッシュが、６４ＭＢよりも大きければ、大きいほど、保存データ量を多くすることができる。

削除リストに登録するファイル数は、ファイルキャッシュの容量と、ファイルキャッシュがデータ占有されている量によって、限界が決まる。ファイルキャッシュマネージャは、ファイルキャッシュの容量消費量を把握している。そして、残りが所定量を以下になった場合は、例えば古い削除リストに登録されているファイルから順次削除してもよい。この削除手段もファイルキャッシュマネージャに含まれており、削除するファイル及び削除タイミングの設定は、アーカイブファイルなどを設定する製作者側の設定によって決まる。

図２０には、ファイルキャッシュ内のディレクトリ構造の例を示している。このディレクトリでは、大きく分けると、システムマネッジドリソース（system managed resource）と、アプリケーションマネッジドリソース（application managed resource）が管理される。アプリケーションマネッジドリソースは、主として、前述した“temp”が含まれるリソース指定情報(URI)で指定される。上記のようにシステムマネッジドリソース（system managed resource）と、アプリケーションマネッジドリソース（application managed resource）を別々のルートディレクトリに配置することで、ファイルキャッシュ内の領域使用状況を把握しやすくなる。アプリケーションマネッジドリソース（application managed resource）の場合、使用後は削除してもよいものが多い。また、データ量も少ないファイルが多いので、ファイルキャッシュに読み書きする時間も少なくてよい。したがって、ファイルキャッシュのメモリ空間を有効に利用する場合、使用済みのアプリケーションマネッジドリソース（application managed resource）の削除は、比較的安易に行うことが可能である。またtemを利用してディレクトリを分けて管理しているように示したが、これは、あくまでＡＰＩなどからアクセスしやすく名前をつけているだけである。実際には、システムマネッジドとアプリケーションマネッジドとは、区別はなく、ファイルキャッシュ内に格納されるようにしてもよい。

なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

この発明の一実施の形態に係るディスク状情報記憶媒体（光ディスク等）１に記録される情報内容を説明する図。 この発明の一実施の形態に係るディスク状情報記憶媒体に記録されるコンテンツを管理するファイルシステムの一例を説明する図。 この発明の他の実施の形態に係るディスク状情報記憶媒体（光ディスク等）１に記録される情報内容のうち、アドバンスドコンテンツ記録領域の記録内容の一例を説明する図。 この発明の他の実施の形態に係るディスク状情報記憶媒体（光ディスク等）１に記録される情報内容のうち、アドバンスドＨＤビデオタイトルセット（ＡＨＤＶＴＳ）記録領域の記録内容の一例を説明する図。 アドバンスドコンテントの再生システムモデルの概要を例示する図。 アドバンスドコンテントの再生システムモデルにおけるデータの流れの一例を説明する図。 タイムライン上の各オブジェクトの再生時間及びロード開始時間の一例を説明する図。 図７の例に対応した再生系の処理例を説明するフローチャート図。 オブジェクトマッピング情報の記述例（アプリケーション毎の例）を説明ずる図。 タイムラインとプレイリストとの関係の一例を示す図。 オブジェクトマッピング情報の記述例（オブジェクト毎の例）を説明ずる図。 この発明の一実施の形態に係る再生系のシステムモデルを説明する図。 図１２のシステムモデルにおける再生動作を実現するプレイリストの一例を説明する図。 図１３の例をタイムライン上に配置した場合を説明する図。 本発明に係るファイルキャッシュにおけるデータ格納状態を示し説明図。 本発明に係るアーカイブデータのフォーマットを示す説明図。 この発明に係るアーカイブデータを読み出す際に利用される指定情報の例を示す説明図。 ファイルキャッシュマネージャがリソース情報を作成する際に用いられる情報の例と、アーカイブファイルのタイムライン上でのローディング期間とライフ期間の指定例を示す説明図。 この発明に係るリソース情報とリソースマネジメント情報との関係を説明するために示した説明図。 この発明に係るファイルキャッシュにおけるディレクトリ構造の例を示す説明図。

符号の説明

１…情報記憶媒体（再生専用または記録再生可能な光ディスク）；１０…リードイン領域；１１…ボリューム／ファイル構造情報領域（ファイル情報領域）；１２…データ領域；１３…リードアウト領域；２０…ビデオデータ記録領域；２１…アドバンスドコンテンツ記録領域；２１Ａ…Markup/Script言語記録領域；２１Ｂ…動画記録領域；２１Ｃ…アニメーション・静止画記録領域；２１Ｄ…音声記録領域；２１Ｅ…フォント記録領域；２２…一般コンピュータ情報記録領域；３０…High Definitionビデオマネージャ記録領域（ＨＤＶＭＧ）；３１…High Definitionビデオマネージャ情報記録領域（ＨＤＶＭＧＩ）；３４…High Definitionビデオマネージャ情報バックアップ領域（ＨＤＶＭＧＩ＿ＢＵＰ）；4０…High Definitionビデオタイトルセット記録領域（ＨＤＶＴＳ＃１〜＃ｎ）；５０…アドバンスドHigh Definitionビデオタイトルセット記録領域（ＡＨＤＶＴＳ）。

Claims (7)

1. データアクセスマネージャと、前記データアクセスマネージャが取得した複数のリソースを一時保存するファイルキャッシュと、前記ファイルキャッシュに保存される複数のファイルを管理するための管理情報の処理、及び前記データアクセスマネージャの制御を行うナビゲーションマネージャとを有し、
   タイムラインが定義され、前記管理情報内には、前記複数のリソースを前記タイムライン上にマッピングするためのプレイリスト情報が含まれており、
   前記ナビゲーションマネージャは、
   前記プレイリスト情報に応じて、前記ファイルキャッシュに前記複数のファイルをそれぞれローディングしかつマッピングし、
   また、ローディングされたリソースが、ライフ期間内であれば、前記ライフ期間内のリソースを特定する情報を、第１のリストに登録し、前記ライフ期間が経過しているリソースであればこのリソースを特定する情報を、第２のリストに登録して管理することを特徴とする情報再生方法。
2. 前記ナビゲーションマネージャは、プレイリストマネージャ及びファイルキャッシュマネージャを含み、
   前記プレイリストマネージャが、前記複数のリソースのローディング期間、ライフ期間情報をリソース情報として管理し、
   前記ファイルキャッシュマネージャが、前記第１と第２のリストを管理している
   請求項１記載の情報再生方法。
3. 前記リソースは、タイプが異なる複数のファイルを含むアーカイブデータである
   請求項２記載の情報再生方法。
4. データアクセスマネージャと、前記データアクセスマネージャが取得した複数のリソースを一時保存するファイルキャッシュと、前記ファイルキャッシュに保存される複数のリソースを管理するための管理情報の処理、及び前記データアクセスマネージャの制御を行うナビゲーションマネージャとを有し、
   タイムラインが定義され、前記管理情報内には、前記複数のリソースを前記タイムライン上にマッピングするためのプレイリスト情報が含まれており、
   前記ナビゲーションマネージャは、
   前記プレイリスト情報に応じて、前記ファイルキャッシュに前記複数のリソースをそれぞれローディングしかつマッピングする手段と、
   また、ローディングされたリソースが、ライフ期間内であれば、前記ライフ期間内のリソースを特定する情報を、第１のリストに登録し、前記ライフ期間が経過しているリソースであればこのリソースを特定する情報を、第２のリストに登録して管理する手段を有することを特徴とする情報再生装置。
5. 前記ナビゲーションマネージャは、プレイリストマネージャ及びファイルキャッシュマネージャを含み、
   前記プレイリストマネージャが、前記複数のファイルのローディング期間、ライフ期間情報をリソース情報として管理する手段を有し、
   前記ファイルキャッシュマネージャが、前記第１と第２のリストを管理する手段を有する請求項４記載の情報再生装置。
6. 前記ファイルキャッシュの最低容量が予め規定され、前記ファイルキャッシュマネージャによる管理情報を設計の目安を分かりやすくしている請求項５記載の情報再生装置。
7. 前記ファイルキャッシュのメモリ使用単位は、所定のブロック単位が予め規定され、前記ファイルキャッシュマネージャによるファイルキャッシュへのアクセスを容易にしている請求項５記載の情報再生装置。
   

Images