システムＬＳＩ
【課題】再生切り換えの前後での字幕・メニューの途切れを防止する。
【解決手段】記録媒体であるＢＤ−ＲＯＭには、ビデオストリームと、グラフィクスストリームとが多重化されたＡＶ−Ｃｌｉｐが記録されている。ビデオストリームは、動画像を構成するものであり、グラフィクスストリームは、動画像上にグラフィクスを合成するものであり、ＰＣＳ，ＩＣＳと呼ばれる制御情報を含む。制御情報は、前記ＡＶＣｌｉｐの再生が、他のデジタルストリームの再生と連続して行われる場合、グラフィクスデコーダ内のメモリの管理を、再生装置に継続させる旨を示す。
【解決手段】記録媒体であるＢＤ−ＲＯＭには、ビデオストリームと、グラフィクスストリームとが多重化されたＡＶ−Ｃｌｉｐが記録されている。ビデオストリームは、動画像を構成するものであり、グラフィクスストリームは、動画像上にグラフィクスを合成するものであり、ＰＣＳ，ＩＣＳと呼ばれる制御情報を含む。制御情報は、前記ＡＶＣｌｉｐの再生が、他のデジタルストリームの再生と連続して行われる場合、グラフィクスデコーダ内のメモリの管理を、再生装置に継続させる旨を示す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シームレス再生の技術分野に属する発明であり、ＢＤ−ＲＯＭ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＤＶＤ−Ｖｉｄｅｏ等の記録媒体、民生用の再生装置に、かかるＧＵＩ技術を応用する場合の改良に関する。
【背景技術】
【０００２】
シームレス再生とは、複数のデジタルストリームを順次再生してゆく場合、これらのデジタルストリームの切り換わり時の途切れをなくす技術である。ユーザ操作や装置の状態（例えば装置に対するレーティングレベルの設定）に応じてストーリ展開が変わるマルチストーリ型の映画作品は、このシームレス再生の技術を基盤にして実現される。シームレス再生技術の応用により映画作品の付加価値を高め、流通市場におけるメガヒットを生みだしたいとの思惑は、多くの映画関係者が抱いているところである。
【０００３】
上述したデジタルストリームは、動画像を構成するビデオストリーム、音声を構成するオーディオストリーム、字幕やメニューを構成するグラフィクスストリームといった複数種類のエレメンタリストリームを多重化したものである。複数のデジタルストリームに多重されているビデオストリームをシームレスに再生させる技術は、例えば以下の特許文献１、２に記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開公報ＷＯ９７／１３３６７
【特許文献２】国際公開公報ＷＯ９７／１３３６３
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで映画作品が複数のデジタルストリームから構成されている場合、それぞれのデジタルストリームは、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとがある。従来のＤＶＤ再生装置に内蔵されているビデオデコーダ（ビデオストリームデコードのためのデコーダ）は、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとを明確に区別して、メモリ管理を継続することにより、シームレス再生を実現することができる。しかし、従来のＤＶＤ再生装置に内蔵されているグラフィクスデコーダ（グラフィクスストリームデコードのためのデコーダ）は、あるデジタルストリームから別のデジタルストリームへの切り換え時において、内蔵されているメモリを一律リセットするとの措置をとっている。これは、たとえビデオストリームがシームレスに再生されるとしても、グラフィクスストリームは先行するデジタルストリーム内のグラフィクスストリームと独立していない場合があり、グラフィクスストリームが独立しているのか、独立していないのかを再生装置内の・メニュー等のグラフィクスは、消去されるので、再生切り換えの前後では字幕・メニューの途切れが生じる。
【０００６】
デジタルストリームの境目では字幕・メニューの途切れが生じるため、オーサリング担当者は台詞がないシーン等、字幕等が出現し得ないシーンを選び、そこをデジタルストリームの分割境界に選ぶという手間を払っている。台詞がない位置をデジタルストリームの分割境界として選ぶ必要があるので、従来技術では、１つの映画作品を複数のデジタルストリームに分割するにあたっての、分割の自由度が足りないという問題点がある。
【０００７】
その結果、マルチストーリ型の映画作品を制作したとしても、思うようなストーリ展開で、再生を進行させてゆくことができないことがある。
本発明の目的は、デジタルストリームを分割するにあたっての自由度を高めることにより、再生経路をもった映画作品の制作を容易にすることができる記録媒体を提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明に係る記録媒体は、ビデオストリームと、グラフィクスストリームとが多重化されたデジタルストリームが記録されており、ビデオストリームは、動画像を構成するものであり、グラフィクスストリームは、動画像上に合成されるべきグラフィクス表示を構成するものであり、状態情報を含み、前記状態情報は、前記デジタルストリームの再生が、他のデジタルストリームの再生後、連続して行われる場合、グラフィクス表示を得るための再生装置上のメモリ管理を、継続させる旨を示すことを特徴としている。
【発明の効果】
【０００９】
上記構成によれば、状態情報は、先に再生されるべきデジタルストリームと、後に再生されるべきデジタルストリームとの間で、メモリ管理を継続させる旨を再生装置に指示するので、たとえデジタルストリーム間の再生切り換えが発生したとしても、グラフィクスデコーダを再生装置がリセットすることはない。メモリ管理を継続させることにより、メニューや字幕があるような位置を、デジタルストリームの分割境界に選ぶことができるので、デジタルストリームの分割境界の選択の自由度を高めることができる。これにより、マルチストーリ型映画作品の制作にあたって、思うようなストーリ展開で、再生を進行させてゆくことができる。
【図面の簡単な説明】
【００１０】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現した図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトのデータ構造を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造を示す図である。
【図９】字幕表示を実現するための記述例を示す図である。
【図１０】DS1におけるPCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図１３】（ａ）2つのAVClip間で連続性をもつようなEpochを示す図である。 （ｂ）Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。
【図１４】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【図１５】DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。
【図１６】AVClipの境界前後で2つに分断されたEpochを示す図である。
【図１７】1つのAVClIP(AVClIP＃1)に対して後続AVClip(AVClIP＃2、AVClIP＃3)が2つ有り、分岐点になっている場合のEpoch Continueの扱いを示す図である。
【図１８】1つのAVClIP(AVClIP＃2)が2つの先行AVClIP(AVClIP＃1、AVClIP＃4)の合流点になっている場合のEpoch Continueの扱いを示す図である。
【図１９】clpi”が付与されたファイル、及び、拡張子”mpls”が付与されたファイルを示す図である。
【図２０】PL情報の構成を示す図である。
【図２１】2つのAVClipを1つのPlayListとして取り扱う場合のPL情報の一例を示す図である。
【図２２】各PlayItem(AVClip)に属するDisplay Setと、各PlayItemにおけるconnection_conditionとを示す図である。
【図２３】PlayItem＃2(後続AVClIP)の先頭にあたるDSm+1と、PlayItem＃1(先行AVClip)の最後にあたるDSmとが属する同一のEpochを示す図である。
【図２４】本発明に係る再生装置の内部構成を示す図である。
【図２５】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図２６】図１４に示した2つのAVClipを再生するにあたってのDisplay Set読み出しがどのように行われるかを示す図である。
【図２７】図１４に示したAVClIP＃2への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す図である。
【図２８】先行AVClIPに属するビデオストリームのPTS値と、後続AVClIPに属するビデオストリームのPTS値とを対比して示す図である。
【図２９】（ａ）インタラクティブグラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することにより得られるPESパケットを示す図である。
【図３０】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図３１】（ａ）（ｂ）ICSとInteractive_compositionとの対応関係を示す図である。
【図３２】ICSの内部構成を示す図である。
【図３３】1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。
【図３４】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３５】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３６】DSx.Page情報(y)により構成されるページと、DSx+1.Page情報(y)により構成されるページとを対比して示す図である。
【図３７】IGストリーム内に、Epoch ContinueタイプのDisplay Setが存在する場合の、Graphicsコントローラ１７による処理手順を示す図である。
【図３８】第１実施形態〜第３実施形態に示したBD-ROMを作成するための製造工程を示す図である。
【発明を実施するための形態】
【００１１】
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ＢＤ−ＲＯＭ１００である。このＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００１２】
以上が本発明に係る記録媒体の使用形態についての説明である。続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭの応用層に対する改良により実施することができる。
図２は、ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット（アプリケーションフォーマット）を表現した図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。
【００１３】
ＢＤＭＶディレクトリの配下には、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＪＡディレクトリと呼ばれる４つのサブディレクトリが存在する。
ＳＴＲＥＡＭディレクトリは、いわばデジタルストリーム本体となるファイル群を格納しているディレクトリであり、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）が存在する。
【００１４】
ＰＬＡＹＬＩＳＴディレクトリは、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）が存在する。
ＣＬＩＰＩＮＦディレクトリは、ＰＬＡＹＬＩＳＴディレクトリ同様、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）が存在する。
【００１５】
本図において拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐには、ＭａｉｎＣＬｉｐ、ＳｕｂＣｌｉｐといった種別がある。ＭａｉｎＣＬｉｐは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム（ＰＧストリーム）、メニューを構成するインタラクティブグラフィクスストリーム（ＩＧストリーム）というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００１６】
図３は、ＡＶＣｌｉｐがどのように構成されているかを模式的に示す図である。
ＡＶＣｌｉｐは（中段）、複数のビデオフレーム（ピクチャｐｊ１，２，３）からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを（上１段目）、ＰＥＳパケット列に変換し（上２段目）、更にＴＳパケットに変換し（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（ＰＧストリーム）及び対話系のインタラクティブグラフィクスストリーム（ＩＧストリーム）を（下１段目）を、ＰＥＳパケット列に変換し（下２段目）、更にＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。
【００１７】
ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておく。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットは、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致するからである。３個のセクタに収められた３２個のＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットを”Ａｌｉｇｎｅｄ Ｕｎｉｔ”という。
【００１８】
以上がＡＶＣｌｉｐについての説明である。続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。第２段目は、グラフィクスストリームを構成するＰＥＳパケット列を示す。第２段目におけるＰＥＳパケット列は、第１段目におけるＴＳパケットのうち、所定のＰＩＤをもつＴＳパケットからペイロードを取り出して、連結することにより構成される。
【００１９】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＷＤＳ（Ｗｉｎｄｏｗ Ｄｅｆｉｎｅ Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ）、ＥＮＤ（ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ＰＣＳは、画面構成セグメントと呼ばれ、ＷＤＳ，ＰＤＳ，ＯＤＳ，ＥＮＤは定義セグメントと呼ばれる。ＰＥＳパケットと機能セグメントとの対応関係は、１対１の関係、１対多の関係である。つまり機能セグメントは、１つのＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録されるか、又は、フラグメント化され、複数ＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録される。
【００２０】
図４（ｂ）は、機能セグメントを変換することで得られるＰＥＳパケットを示す図である。図４（ｂ）に示すようにＰＥＳパケットは、『パケットヘッダ』と、『ペイロード』とからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するＤＴＳ、ＰＴＳが存在する。尚以降の説明では、機能セグメントが格納されるＰＥＳパケットのヘッダ内に存在するＤＴＳ及びＰＴＳを、機能セグメントのＤＴＳ及びＰＴＳとして扱う。
【００２１】
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にＤｉｓｐｌａｙ Ｓｅｔを、第１段目にＥｐｏｃｈをそれぞれ示す。
第２段目のＤｉｓｐｌａｙ Ｓｅｔ（ＤＳと略す）とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線ｋｚ１は、第３段目の機能セグメントが、どのＤＳに帰属しているかという帰属関係を示す。ＰＣＳ−ＷＤＳ−ＰＤＳ−ＯＤＳ−ＥＮＤという一連の機能セグメントが、１つのＤＳを構成していることがわかる。再生装置は、このＤＳを構成する複数機能セグメントをＢＤ−ＲＯＭから読み出せば、一画面分のグラフィクスを構成することができる。
【００２２】
第１段目のＥｐｏｃｈとは、ＡＶＣｌｉｐの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このＥｐｏｃｈにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう（※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。）。この矩形領域の縦横の大きさ及び位置は、Ｅｐｏｃｈにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりＥｐｏｃｈは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなＥｐｏｃｈにせねばならない。この場合、２つのＥｐｏｃｈの境界では、映像−グラフィクスの同期は保証されない。
【００２３】
Ｅｐｏｃｈにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Ｅｐｏｃｈということができる。図６は、字幕の表示位置と、Ｅｐｏｃｈとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり５つの字幕「本当に」「ごめん」「あれから」「３年がたった」のうち、２つの字幕「本当に」「ごめん」は画面の下側に、「あれから」「３年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、ＡＶＣｌｉｐの再生時間軸において、下側の余白に字幕が出現している期間が１つのＥｐｏｃｈ１、上側の余白に字幕が出現している期間が別のＥｐｏｃｈ２になる。これら２つのＥｐｏｃｈは、それぞれ独自の字幕の描画領域をもつことになる。Ｅｐｏｃｈ１では、画面の下側の余白が字幕の描画領域（ｗｉｎｄｏｗ１）になる。一方Ｅｐｏｃｈ２では、画面の上側の余白が字幕の描画領域（ｗｉｎｄｏｗ２）になる。これらのＥｐｏｃｈ１，２において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がＥｐｏｃｈについての説明である。続いてＤｉｓｐｌａｙ Ｓｅｔについて説明する。
【００２４】
図５における破線ｈｋ１，２は、第２段目の機能セグメントが、どのＥｐｏｃｈに帰属しているかという帰属関係を示す。Ｅｐｏｃｈ Ｓｔａｒｔ，Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ，Ｎｏｒｍａｌ Ｃａｓｅという一連のＤＳは、第１段目のＥｐｏｃｈを構成していることがわかる。『Ｅｐｏｃｈ Ｓｔａｒｔ』、『Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ』、『Ｎｏｒｍａｌ Ｃａｓｅ』は、ＤＳの類型である。本図におけるＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｎｏｒｍａｌ Ｃａｓｅの順序は、一例にすぎず、どちらが先であってもよい。
【００２５】
『Ｅｐｏｃｈ Ｓｔａｒｔ』は、新たなＥｐｏｃｈの開始を示す。そのためＥｐｏｃｈ Ｓｔａｒｔは、次の画面合成に必要な全ての機能セグメントを含んでいる。Ｅｐｏｃｈ Ｓｔａｒｔは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ』は、Ｅｐｏｃｈの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるＤｉｓｐｌａｙ Ｓｅｔである。Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤＳから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりＡｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤＳは、Ｅｐｏｃｈの途中からの画面構成を可能するという役割をもつ。Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤｉｓｐｌａｙ Ｓｅｔは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、１０分単位、１０秒単位というように、大まかな単位でなされるので、１０分間隔の再生位置、１０秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【００２６】
『Ｎｏｒｍａｌ Ｃａｓｅ』は、前のＤｉｓｐｌａｙ Ｓｅｔからの差分のみを含む。例えば、あるＤＳｖの字幕は、先行するＤＳｕと同じ内容であるが、画面構成が、この先行するＤＳｕとは異なる場合、ＰＣＳと、ＥＮＤのみのＤＳｖを設けてこのＤＳｖをＮｏｒｍａｌ ＣａｓｅのＤＳにする。こうすれば、重複するＯＤＳを設ける必要はなくなるので、ＢＤ−ＲＯＭにおける容量削減に寄与することができる。一方、Ｎｏｒｍａｌ ＣａｓｅのＤＳは、差分にすぎないので、Ｎｏｍａｌ Ｃａｓｅ単独では画面構成は行えない。
【００２７】
続いてＤｅｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＯＤＳ，ＷＤＳ，ＰＤＳ）について説明する。
『Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。ＢＤ−ＲＯＭに記録されているＡＶＣｌｉｐは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、１９２０×１０８０画素という高精細な大きさに設定されている。１９２０×１０８０という解像度があるので、ＢＤ−ＲＯＭでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すＰｉｘｅｌ Ｃｏｄｅと、画素値の連続長とにより、画素列を表現したデータである。Ｐｉｘｅｌ Ｃｏｄｅは、８ビットの値であり、１〜２５５の値をとる。ランレングスデータでは、このＰｉｘｅｌ Ｃｏｄｅによりフルカラーの１６，７７７，２１６色から任意の２５６色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
【００２８】
ＯＤＳによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ＯＤＳは、図７（ａ）に示すように自身がＯＤＳであることを示す『Ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、ＯＤＳのデータ長を示す『Ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、ＥｐｏｃｈにおいてこのＯＤＳに対応するグラフィクスオブジェクトを一意に識別する『ｏｂｊｅｃｔ＿ｉｄ』と、ＥｐｏｃｈにおけるＯＤＳのバージョンを示す『ｏｂｊｅｃｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、『ｌａｓｔ＿ｉｎ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇ』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『Ｏｂｊｅｃｔ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』とからなる。
【００２９】
『Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＰＤＳ）』は、パレットデータを格納する機能セグメントである。パレットデータとは、１〜２５５のＰｉｘｅｌ Ｃｏｄｅと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分（Ｙ値），透明度（Ｔ値）から構成される。各ランレングスデータが有するＰｉｘｅｌ Ｃｏｄｅを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。ＰＤＳのデータ構造を図７（ｂ）に示す。図７（ｂ）に示すようにＰＤＳは、自身がＰＤＳであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』、ＰＤＳのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』、このＰＤＳに含まれるパレットを一意に識別する『ｐａｌｌｅｔ＿ｉｄ』、ＥｐｏｃｈにおけるＥｐｏｃｈのＰＤＳのバージョンを示す『ｐａｌｌｅｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』、各エントリーについての情報『ｐａｌｌｅｔ＿ｅｎｔｒｙ』からなる。『ｐａｌｌｅｔ＿ｅｎｔｒｙ』は、各エントリーにおける赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分Ｙ値，透明度（Ｔ値）を示す。
【００３０】
続いてＷＤＳについて説明する。
『ｗｉｎｄｏｗ＿ｄｅｆｉｎｉｔｉｏｎ＿ｓｅｇｍｅｎｔ』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Ｅｐｏｃｈでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”ｗｉｎｄｏｗ”と呼ばれ、このＷＤＳで定義される。図８（ａ）は、ＷＤＳのデータ構造を示す図である。本図に示すようにＷＤＳは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『ｗｉｎｄｏｗ＿ｉｄ』と、グラフィックスプレーンにおける左上画素の水平位置を示す『ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『ｗｉｎｄｏｗ＿ｗｉｄｔｈ』と、グラフィックスプレーンにおける縦幅を示す『ｗｉｎｄｏｗ＿ｈｅｉｇｈｔ』とを用いて表現される。
【００３１】
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦：ｖｉｄｅｏ＿ｈｅｉｇｈｔ、横：ｖｉｄｅｏ＿ｗｉｄｔｈという二次元状の大きさをもつ。
【００３２】
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈの値をとり、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔの値をとる。
ｗｉｎｄｏｗ＿ｗｉｄｔｈは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈ−ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎの値をとり、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、グラフィックスプレーンにおける縦幅であるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔ−ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎの値をとる。
【００３３】
ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをＥｐｏｃｈ毎に規定することができる。そのため、あるＥｐｏｃｈに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。ＷＤＳはＥｐｏｃｈ毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【００３４】
続いて『ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ』について説明する。ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔは、Ｄｉｓｐｌａｙ Ｓｅｔの伝送の終わりを示す指標であり、Ｄｉｓｐｌａｙ Ｓｅｔにおける機能セグメントのうち、最後のＯＤＳの直後に配置される。このＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔの内部構成は、自身がＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、当該機能セグメントのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
【００３５】
以上がＯＤＳ、ＰＤＳ、ＷＤＳ、ＥＮＤについての説明である。続いてＰＣＳについて説明する。
ＰＣＳは、対話的な画面を構成する機能セグメントである。ＰＣＳは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにＰＣＳは、『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』と、『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』と、『ｐａｌｌｅｔ＿ｉｄ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｌ）〜（ｍ）』とから構成される。
【００３６】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』は、０から１５までの数値を用いてＤｉｓｐｌａｙ Ｓｅｔにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Ｅｐｏｃｈの先頭から本ＰＣＳまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒは設定される。
【００３７】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』は、本ＰＣＳから始まるＤｉｓｐｌａｙ Ｓｅｔが、Ｎｏｒｍａｌ Ｃａｓｅであるか、ＡＣｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔであるか、Ｅｐｏｃｈ Ｓｔａｒｔであるかを示す。
『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』は、本ＰＣＳにおいてＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅがなされているかどうかを示す。ＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本ＰＣＳでかかるアップデートがなされれば、本フィールドは”１”に設定される。
【００３８】
『ｐａｌｌｅｔ＿ｉｄ』は、本ＰＣＳにおいてＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅがなされているかどうかを示す。ＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅとは、直前のＤｉｓｐｌａｙ Ｓｅｔから、パレットのみを新たなものに切り換えることでなされるアップデートをいう。本ＰＣＳでかかるアップデートがなされる場合、本フィールドは”１”に設定される。
【００３９】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（１）・・・（ｎ）』は、このＰＣＳが属するＤｉｓｐｌａｙ Ｓｅｔにおける画面構成を実現するための制御情報である。図８（ｂ）の破線ｗｄ１は、任意のｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）の内部構成をクローズアップしている。この破線ｗｄ１に示すように、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）は、『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』、『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』、『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』、『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』からなる。
【００４０】
『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』は、グラフィクスオブジェクト識別子（ｏｂｊｅｃｔ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』は、ウィンドゥ識別子（ｗｉｎｄｏｗ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【００４１】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”１”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”０”と設定された場合、グラフィクスオブジェクトは非表示となる。
【００４２】
『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』が１に設定されている場合に有効となる情報要素である。破線ｗｄ２は、任意のｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）の内部構成をクローズアップしている。この破線に示すようにｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』からなる。
【００４３】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ＥＴＳＩ ＥＮ ３００ ７４３標準規格における”Ｒｅｇｉｏｎ”に相当する。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４４】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がＰＣＳのデータ構造である。続いてＰＣＳの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとに』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるＥｐｏｃｈは、ＤＳ１（Ｅｐｏｃｈ Ｓｔａｒｔ）、ＤＳ２（Ｎｏｒｍａｌ Ｃａｓｅ）を有する。ＤＳ１は、字幕の表示枠となるｗｉｎｄｏｗを定義するＷＤＳ、台詞『ほんとに ごめん』を表すＯＤＳ、１つ目のＰＣＳを備える。ＤＳ２（Ｎｏｒｍａｌ Ｃａｓｅ）は、２つ目のＰＣＳを有する。
【００４５】
次に個々のＰＣＳをどのように記述するかについて説明する。Ｄｉｓｐｌａｙ Ｓｅｔに属するＷＤＳ、ＰＣＳの記述例を図１０〜図１２に示す。図１０は、ＤＳ１におけるＰＣＳの記述例を示す図である。
図１０において、ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおけるウィンドゥの左上座標ＬＰ１を、ｗｉｎｄｏｗ＿ｗｉｄｔｈ，ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、ウィンドゥの表示枠の横幅、縦幅を示す。
【００４６】
図１０におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ＳＴ１を示している。そして基準点からｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに示される範囲（図中の太枠部分）がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎを基準点（左上）とした破線の範囲ｃｐ１に配置される。こうすることにより、『本当に』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当に』は動画像と合成され表示される。
【００４７】
図１１は、ＤＳ２におけるＰＣＳの記述例を示す図である。本図におけるＷＤＳの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ，は、オブジェクトバッファ上の字幕『本当にごめん』のうち、『こめん』の左上座標を示し、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈは、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。
【００４８】
以上が機能セグメントについての説明である。続いてこれらＰＣＳ、ＯＤＳを有したＤｉｓｐｌａｙ Ｓｅｔが、ＡＶＣｌｉｐの再生時間軸上にどのように割り当てられるかについて説明する。Ｅｐｏｃｈは、再生時間軸上においてメモリ管理が連続する期間であり、Ｅｐｏｃｈは１つ以上のＤｉｓｐｌａｙ Ｓｅｔから構成されるので、Ｄｉｓｐｌａｙ ＳｅｔをどうやってＡＶＣｌｉｐの再生時間軸に割り当てるかが問題になる。ここでＡＶＣｌｉｐの再生時間軸とは、ＡＶＣｌｉｐに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、９０ＫＨｚの時間精度で表現される。Ｄｉｓｐｌａｙ Ｓｅｔ内のＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳは、この再生時間軸において同期制御を実現すべきタイミングを示す。このＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳを用いて同期制御を行うことが、再生時間軸へのＤｉｓｐｌａｙ Ｓｅｔの割り当でである。
【００４９】
Ｅｐｏｃｈに属するＤｉｓｐｌａｙ Ｓｅｔのうち、任意のＤｉｓｐｌａｙ ＳｅｔをＤＳｎとすると、ＤＳｎは、図１２に示すようなＤＴＳ、ＰＴＳ設定によりＡＶＣｌｉｐの再生時間軸に割り当てられる。図１２は、ＤＳｎが割り当てられた、ＡＶＣｌｉｐの再生時間軸を示す図である。本図においてＤＳｎの始期は、ＤＳｎに属するＰＣＳのＤＴＳ値（ＤＴＳ（ＤＳｎ［ＰＣＳ］））により示されており、終期は、ＤＳｎに属するＰＣＳのＰＴＳ値（ＰＴＳ（ＤＳｎ［ＰＣＳ］））により示されている。そしてＤＳｎにおいて最初の表示が行われるタイミングも、ＰＣＳのＰＴＳ値（ＰＴＳ（ＤＳｎ［ＰＣＳ］））に示されている。ＡＶＣｌｉｐ再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、ＰＴＳ（ＤＳｎ［ＰＣＳ］）とを一致させれば、ＤＳｎの最初の表示は、そのビデオストリームと同期することになる。
【００５０】
ＰＴＳ（ＤＳｎ［ＰＣＳ］）は、ＤＴＳ（ＤＳｎ［ＰＣＳ］）に、ＯＤＳのデコードに要する期間（ＤＥＣＯＤＥＤＵＲＡＴＩＯＮ）を足し合わせた値である。
最初の表示に必要なＯＤＳのデコードは、このＤＥＣＯＤＥＤＵＲＡＴＩＯＮ内に行われることになる。図６の期間ｍｃ１は、ＤＳｎに属する任意のＯＤＳ（ＯＤＳｍ）のデコードがなされる期間を示す。このデコード期間の開始点は、ＤＴＳ（ＯＤＳｎ［ＯＤＳｍ］）により示され、このデコードの終了点は、ＰＴＳ（ＯＤＳｎ［ＯＤＳｍ］）により示される。
【００５１】
以上のような再生時間軸への割り付けを、Ｅｐｏｃｈに属する全てのＯＤＳに対して行うことで、Ｅｐｏｃｈは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
Ｅｐｏｃｈは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら１つのＡＶＣｌｉｐ内でＥｐｏｃｈは完結していなければならない。しかし２つのＡＶＣｌｉｐが順次再生される場合であって、所定の３つの条件が満たされるような場合、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈを定義することができる。
【００５２】
図１３（ａ）は、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈを示す図である。本図における第１段目は、連続して再生される２つのＡＶＣｌｉｐを示し、第２段目は、２つのＡＶＣｌｉｐ間で連続性をもつＥｐｏｃｈを示す。第３段目は、第２段目のＥｐｏｃｈに属するＤｉｓｐｌａｙ Ｓｅｔを示す。第２段目におけるＥｐｏｃｈは、ＡＶＣｌｉｐにより分断されない。しかし第３段目におけるＤｉｓｐｌａｙ Ｓｅｔは、このＡＶＣｌｉｐ境界の前後で２つのＤｉｓｐｌａｙ Ｓｅｔに分断されている。本図において注目すべきは、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、”Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅタイプ”になっていることである。
【００５３】
”Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅ”とは、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型であり、所定の３つの条件が満たされる場合、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われる。この３つの条件のうち、１つでも欠落があれば、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われる。
図１３（ｂ）は、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔがどのように取り扱われるかを示す図である。本図に示すように、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、後続ＡＶＣｌｉｐからの飛び込み再生が行われる場合、”Ｅｐｏｃｈ Ｓｔａｒｔ”として取り扱われ、先行ＡＶＣｌｉｐから連続再生が行われる場合、”Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ”として取り扱われることがわかる。
【００５４】
図１４は、２つのＡＶＣｌｉｐ間で連続性をもつための３つの条件を示す図である。本図における第１段目は、連続して再生される２つのＡＶＣｌｉｐを示し、第２段目は、３つのＥｐｏｃｈを示す。この３つのＥｐｏｃｈのうち、真ん中のＥｐｏｃｈが、２つのＡＶＣｌｉｐ間でメモリ管理の連続性をもつＥｐｏｃｈである。第３段目は、３つのＥｐｏｃｈのそれぞれに属するＤｉｓｐｌａｙ Ｓｅｔを示す。第２段目におけるＥｐｏｃｈは、ＡＶＣｌｉｐにより分断されることはなかったが、第３段目におけるＤｉｓｐｌａｙ Ｓｅｔは、このＡＶＣｌｉｐ境界の前後で２つのＤｉｓｐｌａｙ Ｓｅｔに分断されている。第４段目は、各Ｄｉｓｐｌａｙ Ｓｅｔに属する機能セグメントを示す。この第４段目における機能セグメント群は、図５の第４段目に示したものと同じである。図中の◎１，◎２，◎３が、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈの成立条件を示す。１つ目の条件は、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、第３段目に示すようにＥｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていることである。
【００５５】
２つ目の条件は、ＤＳｍ＋１に属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、１つ前のＤＳｍに属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒ（＝Ａ）と同じであること、つまりグラフィクス表示の内容が、ＡＶＣｌｉｐ境界の前後で同じであることを意味する。Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは、Ｄｉｓｐｌａｙ Ｓｅｔによる画面構成を意味するものである。このＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが同じであるということは、画面構成で得られるグラフィクスの内容が、ＤＳｍと、ＤＳｍ＋１とで同じであることを意味する。図１５は、ＤＳｍにおける画面構成と、ＤＳｍ＋１における画面構成とを対比して示す図である。本図に示すように、ＤＳｍによるグラフィクスの内容は『３年たった』であり、ＤＳｍ＋１によるグラフィクスの内容は『３年たった』であるので、２つのＤｉｓｐｌａｙ Ｓｅｔ間でグラフィクスの内容は同じであり、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが同一値になっていることがわかる。また、ビデオストリームの再生もシームレス接続になされているので、ＤＳｍ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることがわかる。
【００５６】
３つ目の条件は、先行ＡＶＣｌＩＰの再生と、後続ＡＶＣｌＩＰの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
（ｉ）ビデオ属性情報に示されているビデオストリームの表示方式（ＮＴＳＣ、ＰＡＬ等）が、２つのＡＶＣｌｉｐ間で同一である。
（ｉｉ）オーディオ属性情報に示されているオーディオストリームのエンコード方式（ＡＣ−３、ＭＰＥＧ、ＬＰＣＭ等）が、２つのＡＶＣｌｉｐ間で同一である。
【００５７】
以上の（ｉ）〜（ｉｉ）においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。
例えば、連続して再生すべき２つのオーディオストリームにおいて、一方の符号化方式がＡＣ−３方式であり、他方がＭＰＥＧ規格である場合、ストリームがＡＣ−３からＭＰＥＧへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
【００５８】
これら（ｉ）〜（ｉｉ）の関係が全て満たされた場合のみ、シームレス接続がなされる。（ｉ）〜（ｉｉ）の関係のうち、１つでも満たされない場合、シームレス接続はなされない。
かかる３つの条件が満たされれば、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤＳｍ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。つまりＤｉｓｐｌａｙ Ｓｅｔ１〜ｍ、Ｄｉｓｐｌａｙ Ｓｅｔｍ＋１〜ｎ間は１つのＥｐｏｃｈを形成することになり、２つのＡＶＣｌｉｐの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
【００５９】
仮にＤＳｍ＋１の類型がＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであったとしても、残り２つの条件のうち、１つの欠落があれば、Ｅｐｏｃｈは、図１６に示すように、ＡＶＣｌｉｐの境界前後で２つに分断されることになる。以上のことからＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、上述したように３つの条件が全て満たされた場合にＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱われる。１つの条件が欠けた場合は、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われることになる。図１７は、１つのＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃１）に対して後続ＡＶＣｌｉｐ（ＡＶＣｌＩＰ＃２、ＡＶＣｌＩＰ＃３）が２つ有り、先行ＡＶＣｌＩＰが分岐点になっている場合のＥｐｏｃｈ Ｃｏｎｔｉｎｕｅの扱いを示す。２つの先行ＡＶＣｌＩＰのうち、ＡＶＣｌＩＰ＃１は図１４と同じであり、後続ＡＶＣｌｉｐの１つであるＡＶＣｌＩＰ＃２も、図１４と同じである。そのためＡＶＣｌＩＰ＃１、ＡＶＣｌＩＰ＃２は３つの条件を全て満たす。そのためＡＶＣｌＩＰ＃１から再生がなされた場合、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳｍ＋１）はＥｐｏｃｈ Ｃｏｎｔｉｎｕｅとして取り扱われることになる。もう一方の後続ＡＶＣｌｉｐであるＡＶＣｌＩＰ＃３はグラフィクス表示の内容が全く同じであり、ＡＶＣｌｉｐ＃１の最後のＤＳ（ＤＳｎ）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、ＡＶＣｌＩＰ＃３の最初のＤＳ（ＤＳ１）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致している。そのため、ＡＶＣｌＩＰ＃１→ＡＶＣｌＩＰ＃３の再生時には、３つの条件が全て満たされることになり、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔはＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。
【００６０】
図１８は、１つのＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃２）が２つの先行ＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃１、ＡＶＣｌＩＰ＃４）の合流点になっている場合のＥｐｏｃｈ Ｃｏｎｔｉｎｕｅの扱いを示す。２つの先行ＡＶＣｌＩＰのうち、ＡＶＣｌＩＰ＃１は図１４と同じであり、ＡＶＣｌＩＰ＃２も図１４と同一であり、３つの条件を全て満たす。そのためＡＶＣｌＩＰ＃１から再生がなされた場合、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳ１）はＥｐｏｃｈ Ｃｏｎｔｉｎｕｅとして取り扱われることになる。一方、ＡＶＣｌＩＰ＃４もグラフィクス表示の内容が全く同じであり、ＡＶＣｌＩＰ＃４の最後のＤＳ（ＤＳｍ）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳ１）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致している。そのため、ＡＶＣｌＩＰ＃４→ＡＶＣｌＩＰ＃２の再生時には、３つの条件が全て満たされることになり、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔはＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。
【００６１】
以上がＡＶＣｌｉｐについての説明である。続いて拡張子”ｃｌｐｉ”が付与されたファイル、及び、拡張子”ｍｐｌｓ”が付与されたファイルについて説明する。図１９は、ｃｌｐｉ”が付与されたファイル、及び、拡張子”ｍｐｌｓ”が付与されたファイルを示す図である。
拡張子”ｃｌｐｉ”が付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、ＡＶＣｌｉｐのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐ、ＡＴＣ＿ｄｅｌｔａをもっている。ＡＴＣ＿ｄｅｌｔａのＡＴＣ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋ）とは、ＡＴＳの基準となるＣｌｏｃｋであり、ＡＴＣ＿ｄｅｌｔａは、先に再生されるＡＶＣｌｉｐのＡＴＣと、後に再生されるＡＶＣｌｉｐのＡＴＣとの間の差分を意味する。
【００６２】
拡張子”ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３．ｍｐｌｓ・・・・・）は、ＰＬ情報を格納したファイルである。ＰＬ情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。図２０は、ＰＬ情報の構成を示す図であり、本図の左側に示すように、ＰＬ情報は、破線の矢印ｍｐ１に示すように複数のＰｌａｙＩｔｅｍ情報（ＰｌａｙＩｔｅｍ（））からなる。ＰｌａｙＩｔｅｍとは、１つ以上のＡＶＣｌｉｐ時間軸上において、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで定義される再生区間である。ＰｌａｙＩｔｅｍ情報を複数配置させることで、複数再生区間からなるプレイリスト（ＰＬ）が定義される。図中の破線ｍｐ２は、ＰｌａｙＩｔｅｍ情報の内部構成をクローズアップしている。本図に示すようにＰｌａｙＩｔｅｍ情報は、対応するＡＶＣｌｉｐを示す『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』と、『ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』とからなる。
【００６３】
２つのＡＶＣｌｉｐを１つのＰｌａｙＬｉｓｔとして取り扱う場合のＰＬ情報の設定について図２１を参照しながら説明する。図２１の第１段目は、図１５に示した２つのＡＶＣｌｉｐを示し、図２１の第２段目は、ＰＬ情報により定義されるＰｌａｙＬｉｓｔ時間軸を示す。ＰＬ情報が２つのＰｌａｙＩｔｅｍ情報を含んでおり（ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２）、ＰｌａｙＩｔｅｍ＃１のＩｎ＿ｔｉｍｅ、Ｏｕｔ＿ｔｉｍｅがＡＶＣｌｉｐの始点、終点を指し示していて、ＰｌａｙＩｔｅｍ＃２のＩｎ＿ｔｉｍｅ、Ｏｕｔ＿ｔｉｍｅがＡＶＣｌｉｐの始点、終点を指し示している場合、これら先行ＡＶＣｌＩＰ及び後続ＡＶＣｌＩＰは、１つのＰｌａｙＬｉｓｔとして取り扱われることになる。図２１の第２段目は、ＰＬ情報により定義されるＰｌａｙＬｉｓｔの再生時間軸（ＰＬ再生時間軸）を示す。このようにＰｌａｙＬｉｓｔを定義すると、ＡＶＣｌｉｐはいわばＰｌａｙＬｉｓｔの部分区間として取り扱われることになる。ＰｌａｙＬｉｓｔの部分区間はＰｌａｙＩｔｅｍと呼ばれる。つまりＰｌａｙＩｔｅｍ＝ＡＶＣｌｉｐの関係が成り立つ。
【００６４】
ＰｌａｙＩｔｅｍを定義するＰｌａｙＩｔｅｍ情報には、ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎというフィールドがあり、先行するＰｌａｙＩｔｅｍ（ＡＶＣｌｉｐ）との再生がシームレスになされるか否かを示す。
図２２は、各ＰｌａｙＩｔｅｍ（ＡＶＣｌｉｐ）に属するＤｉｓｐｌａｙ Ｓｅｔと、各ＰｌａｙＩｔｅｍにおけるｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎとを示す図である。ここでＰｌａｙＩｔｅｍ＃２に属するＤｉｓｐｌａｙ Ｓｅｔのうち、先頭のもの（ＤＳｍ＋１）のＳｅｇｍｅｎｔ ＴｙｐｅがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであり、ＰｌａｙＩｔｅｍ＃２のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎがシームレス接続を示しているなら、ＰｌａｙＩｔｅｍ＃２（後続ＡＶＣｌＩＰ）の先頭にあたるＤＳｍ＋１と、ＰｌａｙＩｔｅｍ＃１（先行ＡＶＣｌｉｐ）の最後にあたるＤＳｍとは同一のＥｐｏｃｈに属することになる。図２３は、ＰｌａｙＩｔｅｍ＃２（後続ＡＶＣｌＩＰ）の先頭にあたるＤＳｍ＋１と、ＰｌａｙＩｔｅｍ＃１（先行ＡＶＣｌｉｐ）の最後にあたるＤＳｍとが属する同一のＥｐｏｃｈを示す図である。先行ＡＶＣｌｉｐにおける最後のＤｉｓｐｌａｙ Ｓｅｔと、後続ＡＶＣｌｉｐにおける最初のＤｉｓｐｌａｙ Ｓｅｔとが同一のＥｐｏｃｈに帰属するので、これら２つのＤｉｓｐｌａｙ Ｓｅｔによるグラフィクス表示は連続してなされることになる。
【００６５】
これまでに説明したＤｉｓｐｌａｙ Ｓｅｔ（ＰＣＳ，ＷＤＳ，ＰＤＳ，ＯＤＳ）のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｆｏｒｍａｔに規定された構文に従い、クラス構造体を記述することで、ＢＤ−ＲＯＭ上のこれらのデータ構造を得ることができる。以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２４は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置、マイコンシステムという３つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤドライブ１、Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａ、Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂ、ＰＩＤフィルタ３、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃ、周辺回路４ｄ、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、ＣＬＵＴ部９、加算器１０、グラフィクスデコーダ１２、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌコントローラ１７から構成される。
【００６６】
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行して、３２個のセクタからなるＡｌｉｇｎｅｄ ＵｎｉｔをＢＤ−ＲＯＭから読み出す。
Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａは、２７ＭＨｚの水晶発振器（２７ＭＨｚ Ｘ−ｔａｌ）に基づき、Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋを生成する。Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋとは、ＴＳパケットに付与されたＡＴＳの基準となる時間軸を規定するクロック信号である。
【００６７】
Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂは、ＢＤ−ＲＯＭから３２個のセクタからなるＡｌｉｇｎｅｄ Ｕｎｉｔが読み出されれば、Ａｌｉｇｎｅｄ Ｕｎｉｔを構成するそれぞれのＴＳパケットから、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外して、ＴＳパケットのみをＰＩＤフィルタ３に出力する。Ｓｏｕｒｃｅ ｄｅ−Ｐａｃｋｅｔｉｚｅｒ２ｂによるＰＩＤフィルタ３への出力は、Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａが経時している時刻が、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒに示されるＡＴＳになったタイミングになされる。ＰＩＤフィルタ３への出力は、ＡＴＳに従いなされるので、たとえＢＤ−ＲＯＭからの読み出しに１倍速、２倍速といった速度差があっても、ＰＩＤフィルタ３へのＴＳパケット出力は、Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋが経時する現在時間に従いなされることになる。２つのＡＶＣｌｉｐを連続再生しようとする場合、Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂは、Ｃｌｉｐ情報中に存在するＡＴＣ＿Ｄｅｌｔａを用いて、２つのＡＶＣｌｉｐにおけるＡＴＣのズレを調整する。
【００６８】
ＰＩＤ Ｆｉｌｔｅｒ３は、ＴＳパケットに付加されているＰＩＤを参照することにより、ＴＳパケットが、ビデオストリーム、ＰＧストリーム、ＩＧストリームの何れに帰属するのかを判定して、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃのどれかに出力する。
Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃは、ＰＩＤフィルタ３から出力されたＴＳパケットを先入れ先出し式に格納しておくメモリである。
【００６９】
周辺回路４ｄは、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃから読み出されたＴＳパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはＣｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３に格納される。
ビデオデコーダ５は、ＰＩＤフィルタ３から出力された複数ＴＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
【００７０】
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、ＰＩＤフィルタ３から出力されたＴＳパケットを復号して、非圧縮形式のオーディオデータを出力する。
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
【００７１】
ＣＬＵＴ部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、ＰＤＳに示されるＹ，Ｃｒ，Ｃｂ値に基づき変換する。
加算器１０は、ＣＬＵＴ部９により色変換された非圧縮グラフィクスに、ＰＤＳに示されるＴ値（透過率）を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
【００７２】
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
このグラフィクスデコーダ１２は、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌコントローラ１７から構成される。
【００７３】
Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３は、機能セグメントがＤＴＳ、ＰＴＳと共に格納されるバッファである。かかる機能セグメントは、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃに格納されたトランスポートストリームの各ＴＳパケットから、ＴＳパケットヘッダ、ＰＥＳパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたＴＳパケットヘッダ、ＰＥＳパケットヘッダのうち、ＰＴＳ／ＤＴＳは、ＰＥＳパケットと対応付けて格納される。
【００７４】
周辺回路１３ａは、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３−Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４間の転送、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３−Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がＯＤＳのＤＴＳに示される時刻になれば、ＯＤＳを、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３からＳｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４に転送する。また現在時刻がＰＣＳ、ＰＤＳのＤＴＳに示される時刻になれば、ＰＣＳ、ＰＤＳをＣｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６に転送するという処理を行う。
【００７５】
Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４は、ＯＤＳをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５に書き込む。Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４は一時的に保持する。Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時になされるが、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４からＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込みは、瞬時には終わらない。ＢＤ−ＲＯＭ規格のプレーヤモデルでは、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込みは、１２８Ｍｂｐｓという転送レートでなされるからである。Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込み完了時点は、ＥＮＤセグメントのＰＴＳに示されているので、このＥＮＤセグメントのＰＴＳに示される時点が経過するまで、次のＤＳに対する処理を待つことになる。各ＯＤＳをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのＯＤＳに関連付けられたＤＴＳの時刻に開始し、ＯＤＳに関連付けられたＰＴＳに示されるデコード終了時刻までに終了する。
【００７６】
Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５は、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４のデコードにより得られたグラフィクスオブジェクトが配置されるバッファである。Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５は、グラフィクスプレーン８の２倍／４倍の大きさに設定せねばならない。何故ならＳｃｒｏｌｌｉｎｇを実現する場合を考えると、グラフィクスプレーン８の２倍、４倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【００７７】
Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６は、ＰＣＳ、ＰＤＳが配置されるメモリである。――処理すべきＤｉｓｐｌａｙ Ｓｅｔが２つあり、これらのＰＣＳのアクティブ期間が重複している場合、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６には処理すべきＰＣＳが複数格納される。
Ｇｒａｐｈｉｃａｌコントローラ１７は、Ｇｒａｐｈｉｃａｌコントローラ１７はＰＣＳの解読を行い、ＰＣＳの解読結果に従って、グラフィクスオブジェクトのＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込み、及び、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Ｇｒａｐｈｉｃａｌコントローラ１７による表示は、ＰＣＳを格納したＰＥＳパケットのＰＴＳに示される時点において実行される。Ｇｒａｐｈｉｃａｌコントローラ１７によるＤＳｎに属するグラフィクスオブジェクトの表示から、ＤＳｎ＋１に属するグラフィクスオブジェクトの表示までの間隔は上述した通りである。
【００７８】
図２５は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてＳｅｇｍｅｎｔＫとは、ＡＶＣｌｉｐの再生時において、読み出されたＳｅｇｍｅｎｔ（ＩＣＳ，ＰＤＳ，ＯＤＳ）のそれぞれを意味する変数であり、無視フラグは、このＳｅｇｍｅｎｔＫを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを０に初期化した上で（ステップＳ１）、ステップＳ２〜Ｓ１３の処理を全てのＳｅｇｍｅｎｔについて繰り返すループ構造を有している（ステップＳ１４、ステップＳ１５）。
【００７９】
ループ構造をもつステップＳ２〜ステップＳ１５の処理は、無視フラグが１かどうかを判定して（ステップＳ３）、無視フラグが０であるなら、対象となる機能セグメントをＣｏｄｅｄ Ｄａｔａバッファ１３からＣｏｍｐｏｓｉｔｉｏｎバッファ１６、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４のどれかに転送し（ステップＳ４）、無視フラグが１であるならかかる転送を行わずＣｏｄｅｄ Ｄａｔａバッファ１３上で、対象となる機能セグメントを削除する（ステップＳ５）という処理を、機能セグメントの読み出しが継続している限り繰り返すものである。
【００８０】
ＳｅｇｍｅｎｔＫが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ９、Ｓ１０は、この無視フラグを設定する処理である。
ステップＳ６は、ＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであるか否かの判定である。ＳｅｇｍｅｎｔＫがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであるなら、ステップＳ７〜ステップＳ９が実行され、ＳｅｇｍｅｎｔＫがもしＥｐｏｃｈ ＳｔａｒｔかＮｏｒｍａｌ Ｃａｓｅであるなら、ステップＳ１０〜ステップＳ１２が実行される。
【００８１】
ステップＳ７〜ステップＳ９は、ステップＳ７、ステップＳ８という２回の判定を行い、これらの判定が両方ともＹｅｓであった場合のみ、無視フラグを１に設定する（ステップＳ９）。
ステップＳ７は、ＰＣＳが属するＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎが”＝５（シームレス接続）”であるか否かの判定である。ステップＳ８は、新たに読み出されたＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６上にあるＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと同一であるか否かの判定である。
【００８２】
これらのステップＳ７、ステップＳ８のどちらかがＮｏであれば、ステップＳ１０に移行して、無視フラグを０に設定する。ステップＳ７、ステップＳ８の双方がＹｅｓであれば、無視フラグは１に設定されることになる（ステップＳ９）。
ステップＳ１１は、新たに読み出されたＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＮｏｒｍａｌ Ｃａｓｅであるか否かの判定であるか、Ｅｐｏｃｈ Ｓｔａｒｔであるかの判定である。もしＥｐｏｃｈ Ｓｔａｒｔであるなら、無視フラグを０に設定する（ステップＳ１０）。
【００８３】
ステップＳ１１は、ＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＮｏｒｍａｌ Ｃａｓｅであるか否かの判定である。もしＮｏｒｍａｌ Ｃａｓｅであるなら、追加のチェックとしてステップＳ１２を実行する。ステップＳ１２は、グラフィクスオブジェクトがＯｂｊｅｃｔ Ｂｕｆｆｅｒに存在しており、ＰＣＳ，ＰＤＳ，ＷＤＳがＣｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６に存在するかの判定である。もし、存在すれば無視フラグを０に設定する（ステップＳ１０）。存在しなければ、ステップＳ９に移行する。
【００８４】
Ｏｂｊｅｃｔ Ｂｕｆｆｅｒにグラフィクスオブジェクトが存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないという理由による。
図２６は、図１４に示した２つのＡＶＣｌｉｐを再生するにあたってのＤｉｓｐｌａｙ Ｓｅｔ読み出しがどのように行われるかを示す図である。第３段目は、ＡＶＣｌｉｐに多重化されているＤｉｓｐｌａｙ Ｓｅｔを示し、第２段目は、ビデオストリームを構成する複数のピクチャを、第１段目はグラフィクスデコーダにおける状態を示す。
【００８５】
Ｅｐｏｃｈの先頭に位置するＤＳ１の読み出し時には、グラフィクスデコーダに対するリセットがなされ、ＤＳ１を構成するＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳがＣｏｄｅｄ Ｄａｔａバッファ１３に順次読み出されることになる。そしてＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送され、ＯＤＳはＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることになる。
【００８６】
矢印ｍｒ１は、ＤＳｍの読み出し時を示す。ＤＳｍを構成するＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳがＣｏｄｅｄ Ｄａｔａバッファ１３に順次読み出されることになる。このＤＳｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎは、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔなので、ＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送されることなく廃棄される。一方、ＯＤＳもＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることなく廃棄される。
【００８７】
矢印ｍｒ２は、ＤＳｍ＋１の読み出し時を示す。この場合グラフィクスデコーダは、３つの条件が満たされるか否かを判定する。ＤＳｍ＋１のＣｈａｎｇｅ ｓｔｒｅａｍがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅを示しており、ビデオストリームの再生がシームレスになされ、そしてＤＳｍ＋１のＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６上のＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致していれば、これら３つの条件が満たされることになり、ＤＳｍ＋１をＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱う。これにより再生装置は、グラフィクスデコーダをリセットせず、Ｃｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳ、ＷＤＳ、ＰＤＳをＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送することなく廃棄する。一方、ＯＤＳもＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力することなく廃棄する。こうすることで、グラフィクスデコーダの状態は継続することになる。
【００８８】
以上が通常再生時における処理であるが、チャプタージャンプやチャプターサーチによりＡＶＣｌＩＰへの飛び込み再生がなされた場合、この飛び込みの指示と同時に、グラフィクスデコーダのリセットがなされることになる。これによりグラフィクスデコーダ上で管理されているカレントＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは、新たに再生されようとする先行ＡＶＣｌＩＰにおけるＤＳｍ＋１のＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致することはない。このためＤＳｍ＋１は、飛び込み再生時において、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われることになる。
【００８９】
図２７は、図１４に示したＡＶＣｌＩＰ＃２への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す。第１段目〜第３段目の意味内容は、図２６と同じであり、矢印の意味合いも図と同じである。ただ、グラフィクスの表示内容が図２６と違っているため、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは違う値になっている。後続ＡＶＣｌｉｐの再生が開始され、ＤＳｍ＋１がＣｏｄｅｄ Ｄａｔａバッファ１３に読み出されると、グラフィクスデコーダはＣｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳを解読してＤＳｍ＋１におけるＣｈａｎｇｅ ｓｔｒｅａｍが何であるかを判定する。Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅであれば残る２つの条件を判定する。ここでビデオストリームの再生がシームレスに行われたとしても、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが先行ＡＶＣｌＩＰから変化しているためグラフィクスデコーダはＤＳｍ＋１をＥｐｏｃｈ Ｓｔａｒｔとして扱う。これによりグラフィクスデコーダはリセットされ、Ｃｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送され、ＯＤＳはＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることになる。
【００９０】
（第２実施形態）
第２実施形態は、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅを実現するためのＰＴＳ設定に関する実施形態である。２つのＡＶＣｌｉｐを順次再生しようとする場合、これらが基準としているクロックが異なることを考慮せねばならない。オーサリング時においてＡＶＣｌｉｐは、それぞれ別々の機会にエンコードされるから、２つのＡＶＣｌｉｐは、別々のクロック信号を基準にして生成される。ＡＶＣｌｉｐ生成時にあたって、エンコードの基準に用いられるクロックをＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）という。かかるＳＴＣは、再生装置の再生時においてもデコード処理の基準になる。
【００９１】
ＳＴＣが異なる２つのＡＶＣｌｉｐを連続して再生させるため、再生装置は、ＳＴＣのズレ量（ＳＴＣ＿ｄｅｌｔａ）を算出して、自身が内蔵しているクロックの計数値に、このＳＴＣ＿ｄｅｌｔａを加算することにより、かかるＳＴＣの違いを吸収する。図２８は、先行ＡＶＣｌＩＰに属するビデオストリームのＰＴＳ値と、後続ＡＶＣｌＩＰに属するビデオストリームのＰＴＳ値とを対比して示す図である。先行ＡＶＣｌＩＰにおいて最後に再生される再生装置の表示開始時刻をＰＴＳ（１ｓｔＥＮＤ）、ピクチャの表示期間をＴｐｐとし、後続ＡＶＣｌＩＰにおいて最初に表示されるピクチャの開始時刻をＰＴＳ（２ｎｄＳＴＡＲＴ）とした場合、ＳＴＣ＿ｄｅｌｔａは
ＳＴＣ＿ｄｅｌｔａ＝ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐ−ＰＴＳ（２ｎｄＳＴＡＲＴ）
として表現される。これは、２つのＡＶＣｌｉｐを順次再生する際、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐと、ＰＴＳ（２ｎｄＳＴＡＲＴ）とは本来一致するべきであり、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐと、ＰＴＳ（２ｎｄＳＴＡＲＴ）との違いがＳＴＣの違いであると考えることができるという理由による。
【００９２】
２つのＡＶＣｌｉｐを連続して再生しようとする場合、ＰＴＳ（１ｓｔＥＮＤ）、ＰＴＳ（２ｎｄＳＴＡＲＴ）をそれぞれ検出して、これらからＳＴＣ＿ｄｅｌｔａを算出する。そして再生装置に内蔵されているクロックの計数値にＳＴＣ＿ｄｅｌｔａを足し合わせて、ＳＴＣ＿ｄｅｌｔａが足し合わされたクロックの計数値をビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２のそれぞれに出力する。このようにＳＴＣ＿ｄｅｌｔａが足し合わされたクロック計数値を基準することで、ビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２は、２つのＡＶＣｌｉｐに属するビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリームを途切れなく再生してゆくことができる。
【００９３】
かかる処理を円滑に行うため、後続ＡＶＣｌＩＰに属するプレゼンテーショングラフィクスストリームにおいて、先頭に位置するＤＳｍ＋１のＰＴＳ（ＤＳｍ＋１［ＰＣＳ］）の値を調整しておく。どのように調整するかというと、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐ及びＰＴＳ（２ｎｄＳＴＡＲＴ）と同じ時刻を指すように、調整しておくのである。これは以下の理由による。再生装置は、先行ＡＶＣｌＩＰにおける最後のグラフィクス表示が行われてから。後続ＡＶＣｌＩＰにおける最初の表示が行われるまでの間隔が長いと、一旦グラフィクスデコーダをリセットしてしまうことがある。ＢＤ−ＲＯＭにおける複数ＡＶＣｌｉｐは、それぞれ別々のファイルに格納されているため、２つのファイルを連続して読み出すにはタイムラグがあり、２つのＡＶＣｌｉｐの読み出しが遅れた場合は、リセットがなされる確率がますます高くなる。そこで後続ＡＶＣｌＩＰの先頭に位置するＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、ビデオストリームの最初のピクチャが表示されるのと同じタイミングで、グラフィクス表示が行われるよう、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐの値と、同じ時刻を示すように、ＰＴＳ（ＤＳｍ＋１［ＰＣＳ］）の値を設定しておく。
【００９４】
こうすることで、先行ＡＶＣｌＩＰの読み出しの完了後から後続ＡＶＣｌＩＰの読み出し開始までのタイムラグが長くなったとしても、先行ＡＶＣｌＩＰにおける最後のグラフィクス表示が行われてから、後続ＡＶＣｌＩＰにおける最初の表示が行われるまでの間隔は最短にしておくことができる。こうすることにより再生装置はグラフィクスデコーダをリセットすることはないので、そのままメモリ状態を継続させることができる。
【００９５】
（第３実施形態）
第１実施形態では、ＰＧストリームについて説明を行ったが、第３実施形態はＩＧストリームについての実施形態である。続いてインタラクティブグラフィクスストリームについて説明する。図２９（ａ）は、インタラクティブグラフィクスストリームの構成を示す図である。第１段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。第２段目は、グラフィクスストリームを構成するＰＥＳパケット列を示す。第２段目におけるＰＥＳパケット列は、第１段目におけるＴＳパケットのうち、所定のＰＩＤをもつＴＳパケットからペイロードを取り出して、連結することにより構成される。尚、プレゼンテーショングラフィクスストリームについては、本願の主眼ではないので説明は行わない。
【００９６】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ＩＣＳ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ）、ＥＮＤ（ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ＩＣＳは、画面構成セグメントと呼ばれ、ＰＤＳ、ＯＤＳ、ＥＮＤは定義セグメントと呼ばれる。ＰＥＳパケットと機能セグメントとの対応関係は、１対１の関係、１対多の関係である。つまり機能セグメントは、１つのＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録されるか、又は、フラグメント化され、複数ＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録される。図２９（ｂ）は、機能セグメントを変換することにより得られるＰＥＳパケットを示す図である。
【００９７】
以降、各機能セグメントについて説明する。
『Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＩＣＳ）』は、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。対話的な画面構成の１つとして、本実施形態のＩＣＳは、マルチページメニューを実現するものとする。
【００９８】
これら様々な種別の機能セグメントは、図３０のような論理構造を構築する。図３０は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にＥｐｏｃｈを、第２段目にＤｉｓｐｌａｙ Ｓｅｔを、第３段目にＤｉｓｐｌａｙ Ｓｅｔの類型をそれぞれ示す。図２９（ａ）の第３段目に示した機能セグメントは第４段目に描かれている。ＩＧストリームにも、Ｅｐｏｃｈ Ｓｔａｒｔ、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅという類型があるが、ＰＣＳと異なるのは、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔという類型においてページ毎のバージョンアップが可能になることである。
【００９９】
ＩＧストリームは、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための新規な構成は、ＩＣＳ内のＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎに存在する。以降ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの内部構成について以下説明する。
【０１００】
図３１（ａ）（ｂ）は、ＩＣＳとＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎとの対応関係を示す図である。ＩＣＳとＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎとの対応関係には、図７（ａ）に示すような１対１のものと、図３１（ｂ）に示すような１対多のものとがある。
対応関係が１対１になるのは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズが小さく、１つのＩＣＳ内にＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが収まる場合である。
【０１０１】
１対多の対応関係になるのは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズが大きく、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎがフラグメント化され、複数ＩＣＳに格納される場合である。複数ＩＣＳへの格納が可能なので、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎサイズには制限がなく、５１２Ｋバイトであろうと、１Ｍバイトであろうと、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズを大きくすることができる。ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎには１対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの対応関係は、１対１であるとする。
【０１０２】
図３２は、ＩＣＳの内部構成を示す図である。ＩＣＳには、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎの全体、又は、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎをフラグメント化することで得られた一部が格納されている。図８の左側に示すように、ＩＣＳは、自身がＩＣＳであることを示す『ｓｅｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ』と、本ＩＣＳが想定している縦横の画素数、フレームレートを示す『ｖｉｄｅｏ＿ｄｅｓｃｒｉｐｔｏｒ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』と、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎの全体、又は、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎをフラグメント化することで得られた一部である『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』とからなる。
【０１０３】
図３２中の矢印ｃｕ１は、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』の内部構成をクローズアップして示す。この矢印ｃｕ１に示すように『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』は、本ＩＣＳが属するＤｉｓｐｌａｙ Ｓｅｔが、Ｎｏｒｍａｌ Ｃａｓｅ、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｅｐｏｃｈ Ｓｔａｒｔ、Ｅｆｆｅｃｔ＿Ｓｅｑｕｅｎｃｅの何れであるかを示す『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』と、画面合成の回数を示す『Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｎｕｍｂｅｒ』とを含む。
【０１０４】
図３２の矢印ｃｕ２は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの内部構成をクローズアップしている。この矢印に示すようにＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎは、『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｌｅｎｇｔｈ』，『Ｓｔｒｅａｍ＿ｍｏｄｅｌ』，『ｕｓｅｒ＿ｉｎｔｅｒｆａｃｅ＿ｍｏｄｅｌ』，『ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』，『ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』，『ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｒａｔｉｏｎ』、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報（１）（２）・・・（ｉ）・・・（ｎｕｍｂｅｒ＿ｏｆ＿ｐａｇｅ−１）』を含む。
【０１０５】
『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｌｅｎｇｔｈ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのデータ長を示す。
『Ｓｔｒｅａｍ＿ｍｏｄｅｌ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが想定しているストリームモデルのタイプを示す。ストリームモデルとは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎがどのような形態でＢＤ−ＲＯＭに記録されて、再生装置におけるコンポジションバッファ上でどのように扱われるかを示すものであり、Ｓｔｒｅａｍ＿ｍｏｄｅｌは、グラフィクスストリームがＡＶＣｌｉｐから多重分離されてコンポジションバッファ上にロードされたものであるか（ｉ）、ＳｕｂＣｌｉｐとして、コンポジションバッファにプリロードされたものであるか（ｉｉ）を示す。
【０１０６】
『ｕｓｅｒ＿ｉｎｔｅｒｆａｃｅ＿ｍｏｄｅｌ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが想定しているユーザインターフェイスモデルが、Ａｌｗａｙｓ−ｏｎＵ／ＩであるかＰｏｐ−ｕｐＵ／Ｉであるかを示す。Ａｌｗａｙｓ−ｏｎＵ／Ｉとは、ＡＶＣｌｉｐの再生進行に伴ってメニューの表示・消去がなされるユーザインターフェイスであり、ポップアップＵ／Ｉとは、ユーザによる操作をトリガにしてメニューの表示・消去がなされるユーザインターフェイスである。
【０１０７】
『Ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』は、ＩＣＳが帰属するＥｐｏｃｈの終期（Ｅｐｏｃｈ ＥＮＤ）を示す。ＩＣＳによる対話制御は、このＥｐｏｃｈ終期（Ｅｐｏｃｈ ＥＮＤ）においてもはや不可能となるので、このｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓに示される時点が、対話制御の終期を意味する。
『ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』は、セレクテッド状態にあるボタンを自動的にアクティベートするためのタイムアウト時刻を示す。ボタンとは、マルチページメニューにおける個々の選択項目であり、かかるボタンの状態をアクティブ状態に変化させる時間を規定しているのがこのｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓである。
【０１０８】
図中のＩＦ文（ｉｆ（Ｓｔｒｅａｍ＿ｍｏｄｅｌ＝＝’０ｂ’））は、上述したｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ及びｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓが、Ｓｔｒｅａｍ＿ｍｏｄｅｌ＝Ｍｕｌｔｉｐｌｅｘｅｄの際、出現する任意の情報要素であることを示してる。ＩＣＳが想定しているストリームモデルがプリロードである場合、これらｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ、ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓは存在しない。
【０１０９】
『ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎ』は、ユーザ操作により表示され得るページを消去するためのタイムアウト時刻を示す。Ａｌｗａｙｓ−ｏｎＵ／Ｉでは、２ｎｄＰａｇｅ以降のＰａｇｅ（ＳｕｂＰａｇｅという）がユーザ操作により表示されるので、このｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎのタイムアウトにより、ＳｕｂＰａｇｅのみが消去され、１ｓｔＰａｇｅのみとなる。Ｐｏｐ−ｕｐＵ／Ｉでは、ＳｕｂＰａｇｅだけではなく、マルチページメニュー全体がユーザ操作により表示されるので、ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎのタイムアウトにより、全てのページが消去され何も表示されない状態（Ｎｏ Ｍｅｎｕ Ｄｉｓｐｌａｙ）になる。
【０１１０】
図３３は、１つのＤｉｓｐｌａｙ Ｓｅｔにおけるｘ番目のＤｉｓｐｌａｙ Ｓｅｔに属する複数ページのうち、任意のもの（ｙ枚目のページ）についてのページ情報の内部構成を示す図である。この図３３の右側に示すようにＰａｇｅ情報（ｙ）は、
ｉ）Ｐａｇｅ（ｙ）を一意に識別する『ｐａｇｅ＿ｉｄ』、
ｉｉ）Ｐａｇｅ情報（ｙ）により運搬されるデータ構造の中身にあたる，『ＵＯ＿Ｍａｓｋ＿Ｔａｂｌｅ』、『ｉｎ＿ｅｆｆｅｃｔ』，『ｏｕｔ＿ｅｆｆｅｃｔ』，『ａｎｉｍａｔｉｏｎ＿ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ』，『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』、『ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』，『ｐａｌｌｅｔ＿ｉｄ＿ｒｅｆ』，『ボタン情報（１）（２）・・・・・（ｎｕｍｂｅｒ＿ｏｆ＿ｂｕｔｔｏｎｓ−１）』、
ｉｉｉ）Ｐａｇｅ情報（ｙ）の中身のバージョンを示す『Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ』から構成される。
【０１１１】
先ず初めに、Ｐａｇｅ情報（ｙ）により運搬されるデータ構造を構成する各フィールドについて説明する。
『ＵＯ＿Ｍａｓｋ＿Ｔａｂｌｅ』は、Ｐａｇｅ（ｙ）におけるユーザ操作の許可／不許可が設定されるテーブルである。
『ｉｎ＿ｅｆｆｅｃｔ』は、Ｐａｇｅ（ｙ）の表示開始時あたって再生すべき表示効果を示す。『ｏｕｔ＿ｅｆｆｅｃｔ』は、Ｐａｇｅ（ｙ）の表示終了時あたって再生すべき表示効果を示す。
【０１１２】
『ａｎｉｍａｔｉｏｎ＿ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ』は、Ｐａｇｅ（ｙ）にアニメーション表示を適用する際、適用すべきフレームレートを記述する。
『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』は、Ｐａｇｅ（ｙ）の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”ＯｘＦＦ”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ（Ｐｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒ（ＰＳＲ））の設定値が優先的に解釈され、ＰＳＲに示されるボタンがセレクテッド状態になる。本フィールドが０ｘＦＦでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』に規定されたボタン番号でＰＳＲを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。
【０１１３】
『ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』は、ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。
ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆが”ＦＦ”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆが００であれば、自動選択はなされない。００，ＦＦ以外の値であれば本フィールドは、有効なボタン番号として解釈される。
【０１１４】
『ｐａｌｌｅｔ＿ｉｄ＿ｒｅｆ』は、Ｐａｇｅ（ｙ）において、ＣＬＵＴ部に設定すべきパレットのｉｄを示す。
『ボタン情報（Ｂｕｔｔｏｎ＿ｉｎｆｏ）』は、Ｐａｇｅ（ｙ）上に表示される各ボタンを定義する情報である。以上のフィールドにより、マルチページメニューにおける個々のページの中身は特定される。
【０１１５】
『Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ』は、ＥｐｏｃｈにおいてＰａｇｅ情報（ｙ）のデータ構造により運搬される中身のバージョンを示すフィールドである。このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは本願の主眼となるものであるので、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒについて詳しく説明する。ページ情報（ｙ）のバージョンとは、ページ情報で運搬されるデータ構造の中身が、何回目のアップデートを経たものであるかを示す。Ｐａｇｅ情報（ｙ）のデータ構造において、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ直後のフィールドのうち、どれかの値が変化した場合、又は、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ直後の各フィールドに何等かの変化があった場合、Ｐａｇｅ情報（ｙ）は、アップデートされたとみなされる。
【０１１６】
Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒによるバージョンは、１つのＥｐｏｃｈにおける通し番号で表現される。そのため、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値は、ページ情報が１つのＥｐｏｃｈにおいてどのＤｉｓｐｌａｙ Ｓｅｔに属するかによって変わる。１つのＥｐｏｃｈにおいてＥｐｏｃｈ Ｓｔａｒｔに属するページ情報では、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは初期値（＝０）に設定される。一方、２つ目以降のＤｉｓｐｌａｙ Ｓｅｔのうち、アップデートをもたらすもの（Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｎｏｒｍａｌ Ｃａｓｅ）に属するＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒには、アップデート回数を示す１〜２５５の値が設定される。
【０１１７】
以降図３４の具体例を交えてこのＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒについて詳しく説明する。
図３４は、連続する２つのＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｘ＋１、ＤＳｘ）におけるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ設定を示す図である。ＤＳｘ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔであり、このＤｉｓｐｌａｙ Ｓｅｔの任意のページ情報（ｙ）を着眼する。このＤＳｘ＋１のＰａｇｅ情報（ｙ）の中身が、ＤＳｘと全く同一であれば、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは、ＤＳｘ．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒと同じ値に設定される。このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒを参照することにより再生装置は、ＤＳｘ、ＤＳｘ＋１の間において、Ｐａｇｅ情報（ｙ）の中身から変わっていないと判断することができる。これに対し図３５では、ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）の中身は、ＤＳｘにおけるＰａｇｅ情報（ｙ）のそれから変わっている。この場合、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは、ＤＳｘ．Ｐａｇｅ情報（ｙ）の値に１を加えた値（＝Ａ＋１）になっている。かかるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値を参照することで再生装置は、ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）が、ＤＳｘのＰａｇｅ情報（ｙ）から変化していることを知ることができる。
【０１１８】
図３６は、ＤＳｘ．Ｐａｇｅ情報（ｙ）により構成されるページと、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）により構成されるページとを対比して示す図である。
ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）により構成されるページは、３つのボタン（Ａ，Ｂ，Ｃ）をボタンＢ→ボタンＣ→ボタンＡの順に配置するものである。
一方、ＤＳｘにおけるＰａｇｅ情報（ｙ）により構成されるページは、３つのボタン（ボタンＡ、ボタンＢ、ボタンＣ）を、ボタンＡ→ボタンＢ→ボタンＣの順に配置するものである。２枚のページの違いは、ボタンの順序がボタンＡ→ボタンＢ→ボタンＣからボタンＢ→ボタンＣ→ボタンＡに変化している点に過ぎない。たとえ変化が僅かなものであったとしても、ＤＳｘ＋１のＰａｇｅ情報（ｙ）におけるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値は、ＤＳｘより増えた値になる。Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒをこのように設定しておくことでＰａｇｅ情報（ｙ）における些細な変化を、再生装置にシグナリングすることができる。
【０１１９】
これまでの説明は、Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔＤｉｓｐｌａｙ ＳｅｔにおけるＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎをアップデートする一例であったが、Ｎｏｒｍａｌ Ｃａｓｅに属するＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎにおいても、ページ情報毎にＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが存在する。そしてページ情報毎の内容変化を、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒに示させておくことができる。
【０１２０】
第１実施形態同様、先行ＡＶＣｌＩＰと、後続ＡＶＣｌＩＰとの間で３つの条件が満たされている場合は、後続ＡＶＣｌＩＰにおけるＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔをＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱うことができる。更にＡｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔタイプのＤｉｓｐｌａｙ Ｓｅｔでは、ｐａｇｅ情報毎にＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒをインクリメントすることができるので、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔに属するＩＣＳにおいて、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが増えたページ情報があれば、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６に格納されているＩＣＳ内のページ情報のうち、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが増えたページ情報のみを更新することができる。
【０１２１】
以上が本実施形態に係る記録媒体についての改良である。続いて本実施形態に係る再生装置について説明する。上述したようにＩＧストリームは、ＰＧストリーム同様の構成を有しているため、図２４の内部構成をもつ再生装置により、再生を行うことができる。
ＩＧストリーム内に、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔが存在するため、本実施形態に係るＧｒａｐｈｉｃｓコントローラ１７は、図３７のフローチャートに従って処理を行う。本フローチャートは、図２５のフローチャートにおけるＰＣＳという表記を、ＩＣＳという表記に置き換えたものである。この置き換えに加え、ステップＳ２１、ステップＳ２２が追加されている点が新規である。ステップＳ２１は、ステップＳ７−ステップＳ８がどちらもＹｅｓと判定され、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして処理する場合に、実行されるステップである。ステップＳ２１では、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが変化したページ情報が存在するかどうかの判定を行い、もし存在すれば、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６に存在するＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎにおけるページ情報のうち、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが変化したもののみを、新たなページ情報に置き換える。こうすることで、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔを、ページ情報毎にアップデートしてゆくことができる。
【０１２２】
以上のように本実施形態によれば、メニュー表示実現のためのＤｉｓｐｌａｙ Ｓｅｔにおいても、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅという類型があるので、２つのＡＶＣｌｉｐを順次再生しようとする場合でもメニュー表示を途切れないようにすることができる。
（第４実施形態）
本実施形態は、ＢＤ−ＲＯＭの製造工程に関する実施形態である。図３８は、第１実施形態〜第３実施形態に示したＢＤ−ＲＯＭを作成するための製造工程を示す図である。
【０１２３】
ＢＤ−ＲＯＭの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、ＢＤ−ＲＯＭの原盤を作成し、プレス・貼り合わせを行って、ＢＤ−ＲＯＭを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、ＢＤ−ＲＯＭを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１３を含む。
【０１２４】
以降ステップＳ２０４〜ステップＳ２１３について説明する。ステップＳ２０４において制御情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５において、制御情報、パレット定義情報、グラフィクスを機能セグメントに変換する。ステップＳ２０６では、同期したいピクチャが出現するタイミングに基づき、ＩＣＳのＰＴＳを設定する。そしてステップＳ２０７では、ＰＴＳ［ＩＣＳ］の値に基づき、ＤＴＳ［ＯＤＳ］，ＰＴＳ［ＯＤＳ］を設定し、ステップＳ２０８においてＤＴＳ［ＯＤＳ］の値に基づき、ＤＴＳ［ＩＣＳ］，ＰＴＳ［ＰＤＳ］を設定する。
【０１２５】
ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのＤＴＳ、ＰＴＳを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してＡＶＣｌｉｐを得る。以降、ＡＶＣｌｉｐをＢＤ−ＲＯＭのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
【０１２６】
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
【０１２７】
（Ａ）全ての実施形態では、本発明に係る記録媒体をＢＤ−ＲＯＭとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレキシブルＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバブルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
【０１２８】
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムＬＳＩ（集積回路）のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１２９】
（Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムが使用される行為の形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
【０１３０】
（Ｄ）各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１３１】
（Ｅ）ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてＡｌｉｇｎｅｄ Ｕｎｉｔの送信を行ってもよい。つまり送り手側の機器は、Ａｌｉｇｎｅｄ Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
【０１３２】
（Ｆ）各実施形態におけるデジタルストリームは、ＢＤ−ＲＯＭ規格のＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、ｄｔｓ方式であってもよい。
【０１３３】
（Ｇ）各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１３４】
（Ｈ）各実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いている。デコードを実現する装置構成を、字幕−グラフィックスオブジェクト間で共通化する目的で、字幕と同じ圧縮・伸長方式をグラフィックスオブジェクトに採用している。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはＰＮＧデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１３５】
（Ｉ）グラフィックスプレーンクリア及び再描画が垂直帰線期間に完遂するよう、Ｒｃを定めても良い。垂直帰線期間は１／２９．９３秒の２５％と仮定すると、Ｒｃは１Ｇｂｐｓになる。Ｒｃをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Ｒｃ＝２５６Ｍｂｐｓの転送レートであっても、スムーズな表示の実現が可能になる。
【０１３６】
（Ｊ）各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行（ライン）毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
（Ｋ）各実施形態におけるグラフィックスプレーンは、ダブルバッファとして構成することが望ましい。グラフィックスプレーンをダブルバッファで構成すれば数フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯にメニューを表示する場合に有意義である。
【０１３７】
（Ｌ）Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅのＤｉｓｐｌａｙ Ｓｅｔを、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱うには、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていること（第１の条件）、ＤＳｍ＋１に属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、１つ前のＤＳｍに属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと同じであること（第２の条件）、先行ＡＶＣｌＩＰの再生と、後続ＡＶＣｌＩＰの再生とがシームレス接続されること（第３の条件）という３つの条件があった。このうち、第２の条件又は第３の条件は、必須の条件ではなく、第１の条件が満たされていれば、つまり、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていれば、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅのＤｉｓｐｌａｙ Ｓｅｔを、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱ってもよい。
【産業上の利用可能性】
【０１３８】
本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【符号の説明】
【０１３９】
１００ BD-ROM
２００ 再生装置
３００ リモコン
４００、テレビ
【技術分野】
【０００１】
本発明は、シームレス再生の技術分野に属する発明であり、ＢＤ−ＲＯＭ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＤＶＤ−Ｖｉｄｅｏ等の記録媒体、民生用の再生装置に、かかるＧＵＩ技術を応用する場合の改良に関する。
【背景技術】
【０００２】
シームレス再生とは、複数のデジタルストリームを順次再生してゆく場合、これらのデジタルストリームの切り換わり時の途切れをなくす技術である。ユーザ操作や装置の状態（例えば装置に対するレーティングレベルの設定）に応じてストーリ展開が変わるマルチストーリ型の映画作品は、このシームレス再生の技術を基盤にして実現される。シームレス再生技術の応用により映画作品の付加価値を高め、流通市場におけるメガヒットを生みだしたいとの思惑は、多くの映画関係者が抱いているところである。
【０００３】
上述したデジタルストリームは、動画像を構成するビデオストリーム、音声を構成するオーディオストリーム、字幕やメニューを構成するグラフィクスストリームといった複数種類のエレメンタリストリームを多重化したものである。複数のデジタルストリームに多重されているビデオストリームをシームレスに再生させる技術は、例えば以下の特許文献１、２に記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開公報ＷＯ９７／１３３６７
【特許文献２】国際公開公報ＷＯ９７／１３３６３
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで映画作品が複数のデジタルストリームから構成されている場合、それぞれのデジタルストリームは、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとがある。従来のＤＶＤ再生装置に内蔵されているビデオデコーダ（ビデオストリームデコードのためのデコーダ）は、他のデジタルストリームから連続再生されるケースと、単独で再生されるケースとを明確に区別して、メモリ管理を継続することにより、シームレス再生を実現することができる。しかし、従来のＤＶＤ再生装置に内蔵されているグラフィクスデコーダ（グラフィクスストリームデコードのためのデコーダ）は、あるデジタルストリームから別のデジタルストリームへの切り換え時において、内蔵されているメモリを一律リセットするとの措置をとっている。これは、たとえビデオストリームがシームレスに再生されるとしても、グラフィクスストリームは先行するデジタルストリーム内のグラフィクスストリームと独立していない場合があり、グラフィクスストリームが独立しているのか、独立していないのかを再生装置内の・メニュー等のグラフィクスは、消去されるので、再生切り換えの前後では字幕・メニューの途切れが生じる。
【０００６】
デジタルストリームの境目では字幕・メニューの途切れが生じるため、オーサリング担当者は台詞がないシーン等、字幕等が出現し得ないシーンを選び、そこをデジタルストリームの分割境界に選ぶという手間を払っている。台詞がない位置をデジタルストリームの分割境界として選ぶ必要があるので、従来技術では、１つの映画作品を複数のデジタルストリームに分割するにあたっての、分割の自由度が足りないという問題点がある。
【０００７】
その結果、マルチストーリ型の映画作品を制作したとしても、思うようなストーリ展開で、再生を進行させてゆくことができないことがある。
本発明の目的は、デジタルストリームを分割するにあたっての自由度を高めることにより、再生経路をもった映画作品の制作を容易にすることができる記録媒体を提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明に係る記録媒体は、ビデオストリームと、グラフィクスストリームとが多重化されたデジタルストリームが記録されており、ビデオストリームは、動画像を構成するものであり、グラフィクスストリームは、動画像上に合成されるべきグラフィクス表示を構成するものであり、状態情報を含み、前記状態情報は、前記デジタルストリームの再生が、他のデジタルストリームの再生後、連続して行われる場合、グラフィクス表示を得るための再生装置上のメモリ管理を、継続させる旨を示すことを特徴としている。
【発明の効果】
【０００９】
上記構成によれば、状態情報は、先に再生されるべきデジタルストリームと、後に再生されるべきデジタルストリームとの間で、メモリ管理を継続させる旨を再生装置に指示するので、たとえデジタルストリーム間の再生切り換えが発生したとしても、グラフィクスデコーダを再生装置がリセットすることはない。メモリ管理を継続させることにより、メニューや字幕があるような位置を、デジタルストリームの分割境界に選ぶことができるので、デジタルストリームの分割境界の選択の自由度を高めることができる。これにより、マルチストーリ型映画作品の制作にあたって、思うようなストーリ展開で、再生を進行させてゆくことができる。
【図面の簡単な説明】
【００１０】
【図１】本発明に係る記録媒体の、使用行為についての形態を示す図である。
【図２】ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現した図である。
【図３】AVClipがどのように構成されているかを模式的に示す図である。
【図４】（ａ）プレゼンテーショングラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することで得られるPESパケットを示す図である。
【図５】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図６】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図７】（ａ）ODSによるグラフィクスオブジェクトのデータ構造を示す図である。 （ｂ）PDSのデータ構造を示す図である。
【図８】（ａ）WDSのデータ構造を示す図である。 （ｂ）PCSのデータ構造を示す図である。
【図９】字幕表示を実現するための記述例を示す図である。
【図１０】DS1におけるPCSの記述例を示す図である。
【図１１】DS2におけるPCSの記述例を示す図である。
【図１２】DSnが割り当てられた、AVClipの再生時間軸を示す図である。
【図１３】（ａ）2つのAVClip間で連続性をもつようなEpochを示す図である。 （ｂ）Epoch ContinueタイプのDisplay Setがどのように取り扱われるかを示す図である。
【図１４】2つのAVClip間で連続性をもつための3つの条件を示す図である。
【図１５】DSmにおける画面構成と、DSm+1における画面構成とを対比して示す図である。
【図１６】AVClipの境界前後で2つに分断されたEpochを示す図である。
【図１７】1つのAVClIP(AVClIP＃1)に対して後続AVClip(AVClIP＃2、AVClIP＃3)が2つ有り、分岐点になっている場合のEpoch Continueの扱いを示す図である。
【図１８】1つのAVClIP(AVClIP＃2)が2つの先行AVClIP(AVClIP＃1、AVClIP＃4)の合流点になっている場合のEpoch Continueの扱いを示す図である。
【図１９】clpi”が付与されたファイル、及び、拡張子”mpls”が付与されたファイルを示す図である。
【図２０】PL情報の構成を示す図である。
【図２１】2つのAVClipを1つのPlayListとして取り扱う場合のPL情報の一例を示す図である。
【図２２】各PlayItem(AVClip)に属するDisplay Setと、各PlayItemにおけるconnection_conditionとを示す図である。
【図２３】PlayItem＃2(後続AVClIP)の先頭にあたるDSm+1と、PlayItem＃1(先行AVClip)の最後にあたるDSmとが属する同一のEpochを示す図である。
【図２４】本発明に係る再生装置の内部構成を示す図である。
【図２５】機能セグメントのロード処理の処理手順を示すフローチャートである。
【図２６】図１４に示した2つのAVClipを再生するにあたってのDisplay Set読み出しがどのように行われるかを示す図である。
【図２７】図１４に示したAVClIP＃2への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す図である。
【図２８】先行AVClIPに属するビデオストリームのPTS値と、後続AVClIPに属するビデオストリームのPTS値とを対比して示す図である。
【図２９】（ａ）インタラクティブグラフィクスストリームの構成を示す図である。 （ｂ）機能セグメントを変換することにより得られるPESパケットを示す図である。
【図３０】様々な種別の機能セグメントにて構成される論理構造を示す図である。
【図３１】（ａ）（ｂ）ICSとInteractive_compositionとの対応関係を示す図である。
【図３２】ICSの内部構成を示す図である。
【図３３】1つのDisplay Setにおけるx番目のDisplay Setに属する複数ページのうち、任意のもの(y枚目のページ)についてのページ情報の内部構成を示す図である。
【図３４】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３５】連続する2つのDisplay Set(DSx+1、DSx)におけるPage_Version_Number設定を示す図である。
【図３６】DSx.Page情報(y)により構成されるページと、DSx+1.Page情報(y)により構成されるページとを対比して示す図である。
【図３７】IGストリーム内に、Epoch ContinueタイプのDisplay Setが存在する場合の、Graphicsコントローラ１７による処理手順を示す図である。
【図３８】第１実施形態〜第３実施形態に示したBD-ROMを作成するための製造工程を示す図である。
【発明を実施するための形態】
【００１１】
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ＢＤ−ＲＯＭ１００である。このＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
【００１２】
以上が本発明に係る記録媒体の使用形態についての説明である。続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭの応用層に対する改良により実施することができる。
図２は、ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット（アプリケーションフォーマット）を表現した図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。
【００１３】
ＢＤＭＶディレクトリの配下には、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＪＡディレクトリと呼ばれる４つのサブディレクトリが存在する。
ＳＴＲＥＡＭディレクトリは、いわばデジタルストリーム本体となるファイル群を格納しているディレクトリであり、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）が存在する。
【００１４】
ＰＬＡＹＬＩＳＴディレクトリは、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）が存在する。
ＣＬＩＰＩＮＦディレクトリは、ＰＬＡＹＬＩＳＴディレクトリ同様、静的シナリオを構成するファイル群を格納したディレクトリであり、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）が存在する。
【００１５】
本図において拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐには、ＭａｉｎＣＬｉｐ、ＳｕｂＣｌｉｐといった種別がある。ＭａｉｎＣＬｉｐは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム（ＰＧストリーム）、メニューを構成するインタラクティブグラフィクスストリーム（ＩＧストリーム）というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００１６】
図３は、ＡＶＣｌｉｐがどのように構成されているかを模式的に示す図である。
ＡＶＣｌｉｐは（中段）、複数のビデオフレーム（ピクチャｐｊ１，２，３）からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを（上１段目）、ＰＥＳパケット列に変換し（上２段目）、更にＴＳパケットに変換し（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（ＰＧストリーム）及び対話系のインタラクティブグラフィクスストリーム（ＩＧストリーム）を（下１段目）を、ＰＥＳパケット列に変換し（下２段目）、更にＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。
【００１７】
ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておく。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットは、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致するからである。３個のセクタに収められた３２個のＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケットを”Ａｌｉｇｎｅｄ Ｕｎｉｔ”という。
【００１８】
以上がＡＶＣｌｉｐについての説明である。続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。第２段目は、グラフィクスストリームを構成するＰＥＳパケット列を示す。第２段目におけるＰＥＳパケット列は、第１段目におけるＴＳパケットのうち、所定のＰＩＤをもつＴＳパケットからペイロードを取り出して、連結することにより構成される。
【００１９】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＷＤＳ（Ｗｉｎｄｏｗ Ｄｅｆｉｎｅ Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ）、ＥＮＤ（ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ＰＣＳは、画面構成セグメントと呼ばれ、ＷＤＳ，ＰＤＳ，ＯＤＳ，ＥＮＤは定義セグメントと呼ばれる。ＰＥＳパケットと機能セグメントとの対応関係は、１対１の関係、１対多の関係である。つまり機能セグメントは、１つのＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録されるか、又は、フラグメント化され、複数ＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録される。
【００２０】
図４（ｂ）は、機能セグメントを変換することで得られるＰＥＳパケットを示す図である。図４（ｂ）に示すようにＰＥＳパケットは、『パケットヘッダ』と、『ペイロード』とからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するＤＴＳ、ＰＴＳが存在する。尚以降の説明では、機能セグメントが格納されるＰＥＳパケットのヘッダ内に存在するＤＴＳ及びＰＴＳを、機能セグメントのＤＴＳ及びＰＴＳとして扱う。
【００２１】
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にＤｉｓｐｌａｙ Ｓｅｔを、第１段目にＥｐｏｃｈをそれぞれ示す。
第２段目のＤｉｓｐｌａｙ Ｓｅｔ（ＤＳと略す）とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線ｋｚ１は、第３段目の機能セグメントが、どのＤＳに帰属しているかという帰属関係を示す。ＰＣＳ−ＷＤＳ−ＰＤＳ−ＯＤＳ−ＥＮＤという一連の機能セグメントが、１つのＤＳを構成していることがわかる。再生装置は、このＤＳを構成する複数機能セグメントをＢＤ−ＲＯＭから読み出せば、一画面分のグラフィクスを構成することができる。
【００２２】
第１段目のＥｐｏｃｈとは、ＡＶＣｌｉｐの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このＥｐｏｃｈにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう（※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。）。この矩形領域の縦横の大きさ及び位置は、Ｅｐｏｃｈにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりＥｐｏｃｈは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなＥｐｏｃｈにせねばならない。この場合、２つのＥｐｏｃｈの境界では、映像−グラフィクスの同期は保証されない。
【００２３】
Ｅｐｏｃｈにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Ｅｐｏｃｈということができる。図６は、字幕の表示位置と、Ｅｐｏｃｈとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり５つの字幕「本当に」「ごめん」「あれから」「３年がたった」のうち、２つの字幕「本当に」「ごめん」は画面の下側に、「あれから」「３年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、ＡＶＣｌｉｐの再生時間軸において、下側の余白に字幕が出現している期間が１つのＥｐｏｃｈ１、上側の余白に字幕が出現している期間が別のＥｐｏｃｈ２になる。これら２つのＥｐｏｃｈは、それぞれ独自の字幕の描画領域をもつことになる。Ｅｐｏｃｈ１では、画面の下側の余白が字幕の描画領域（ｗｉｎｄｏｗ１）になる。一方Ｅｐｏｃｈ２では、画面の上側の余白が字幕の描画領域（ｗｉｎｄｏｗ２）になる。これらのＥｐｏｃｈ１，２において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がＥｐｏｃｈについての説明である。続いてＤｉｓｐｌａｙ Ｓｅｔについて説明する。
【００２４】
図５における破線ｈｋ１，２は、第２段目の機能セグメントが、どのＥｐｏｃｈに帰属しているかという帰属関係を示す。Ｅｐｏｃｈ Ｓｔａｒｔ，Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ，Ｎｏｒｍａｌ Ｃａｓｅという一連のＤＳは、第１段目のＥｐｏｃｈを構成していることがわかる。『Ｅｐｏｃｈ Ｓｔａｒｔ』、『Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ』、『Ｎｏｒｍａｌ Ｃａｓｅ』は、ＤＳの類型である。本図におけるＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｎｏｒｍａｌ Ｃａｓｅの順序は、一例にすぎず、どちらが先であってもよい。
【００２５】
『Ｅｐｏｃｈ Ｓｔａｒｔ』は、新たなＥｐｏｃｈの開始を示す。そのためＥｐｏｃｈ Ｓｔａｒｔは、次の画面合成に必要な全ての機能セグメントを含んでいる。Ｅｐｏｃｈ Ｓｔａｒｔは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ』は、Ｅｐｏｃｈの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるＤｉｓｐｌａｙ Ｓｅｔである。Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤＳから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりＡｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤＳは、Ｅｐｏｃｈの途中からの画面構成を可能するという役割をもつ。Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔたるＤｉｓｐｌａｙ Ｓｅｔは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、１０分単位、１０秒単位というように、大まかな単位でなされるので、１０分間隔の再生位置、１０秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
【００２６】
『Ｎｏｒｍａｌ Ｃａｓｅ』は、前のＤｉｓｐｌａｙ Ｓｅｔからの差分のみを含む。例えば、あるＤＳｖの字幕は、先行するＤＳｕと同じ内容であるが、画面構成が、この先行するＤＳｕとは異なる場合、ＰＣＳと、ＥＮＤのみのＤＳｖを設けてこのＤＳｖをＮｏｒｍａｌ ＣａｓｅのＤＳにする。こうすれば、重複するＯＤＳを設ける必要はなくなるので、ＢＤ−ＲＯＭにおける容量削減に寄与することができる。一方、Ｎｏｒｍａｌ ＣａｓｅのＤＳは、差分にすぎないので、Ｎｏｍａｌ Ｃａｓｅ単独では画面構成は行えない。
【００２７】
続いてＤｅｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＯＤＳ，ＷＤＳ，ＰＤＳ）について説明する。
『Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。ＢＤ−ＲＯＭに記録されているＡＶＣｌｉｐは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、１９２０×１０８０画素という高精細な大きさに設定されている。１９２０×１０８０という解像度があるので、ＢＤ−ＲＯＭでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すＰｉｘｅｌ Ｃｏｄｅと、画素値の連続長とにより、画素列を表現したデータである。Ｐｉｘｅｌ Ｃｏｄｅは、８ビットの値であり、１〜２５５の値をとる。ランレングスデータでは、このＰｉｘｅｌ Ｃｏｄｅによりフルカラーの１６，７７７，２１６色から任意の２５６色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
【００２８】
ＯＤＳによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ＯＤＳは、図７（ａ）に示すように自身がＯＤＳであることを示す『Ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、ＯＤＳのデータ長を示す『Ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、ＥｐｏｃｈにおいてこのＯＤＳに対応するグラフィクスオブジェクトを一意に識別する『ｏｂｊｅｃｔ＿ｉｄ』と、ＥｐｏｃｈにおけるＯＤＳのバージョンを示す『ｏｂｊｅｃｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、『ｌａｓｔ＿ｉｎ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇ』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『Ｏｂｊｅｃｔ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』とからなる。
【００２９】
『Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＰＤＳ）』は、パレットデータを格納する機能セグメントである。パレットデータとは、１〜２５５のＰｉｘｅｌ Ｃｏｄｅと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分（Ｙ値），透明度（Ｔ値）から構成される。各ランレングスデータが有するＰｉｘｅｌ Ｃｏｄｅを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。ＰＤＳのデータ構造を図７（ｂ）に示す。図７（ｂ）に示すようにＰＤＳは、自身がＰＤＳであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』、ＰＤＳのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』、このＰＤＳに含まれるパレットを一意に識別する『ｐａｌｌｅｔ＿ｉｄ』、ＥｐｏｃｈにおけるＥｐｏｃｈのＰＤＳのバージョンを示す『ｐａｌｌｅｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』、各エントリーについての情報『ｐａｌｌｅｔ＿ｅｎｔｒｙ』からなる。『ｐａｌｌｅｔ＿ｅｎｔｒｙ』は、各エントリーにおける赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分Ｙ値，透明度（Ｔ値）を示す。
【００３０】
続いてＷＤＳについて説明する。
『ｗｉｎｄｏｗ＿ｄｅｆｉｎｉｔｉｏｎ＿ｓｅｇｍｅｎｔ』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Ｅｐｏｃｈでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”ｗｉｎｄｏｗ”と呼ばれ、このＷＤＳで定義される。図８（ａ）は、ＷＤＳのデータ構造を示す図である。本図に示すようにＷＤＳは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『ｗｉｎｄｏｗ＿ｉｄ』と、グラフィックスプレーンにおける左上画素の水平位置を示す『ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『ｗｉｎｄｏｗ＿ｗｉｄｔｈ』と、グラフィックスプレーンにおける縦幅を示す『ｗｉｎｄｏｗ＿ｈｅｉｇｈｔ』とを用いて表現される。
【００３１】
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦：ｖｉｄｅｏ＿ｈｅｉｇｈｔ、横：ｖｉｄｅｏ＿ｗｉｄｔｈという二次元状の大きさをもつ。
【００３２】
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈの値をとり、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔの値をとる。
ｗｉｎｄｏｗ＿ｗｉｄｔｈは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈ−ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎの値をとり、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、グラフィックスプレーンにおける縦幅であるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔ−ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎの値をとる。
【００３３】
ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをＥｐｏｃｈ毎に規定することができる。そのため、あるＥｐｏｃｈに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。ＷＤＳはＥｐｏｃｈ毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
【００３４】
続いて『ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ』について説明する。ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔは、Ｄｉｓｐｌａｙ Ｓｅｔの伝送の終わりを示す指標であり、Ｄｉｓｐｌａｙ Ｓｅｔにおける機能セグメントのうち、最後のＯＤＳの直後に配置される。このＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔの内部構成は、自身がＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、当該機能セグメントのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
【００３５】
以上がＯＤＳ、ＰＤＳ、ＷＤＳ、ＥＮＤについての説明である。続いてＰＣＳについて説明する。
ＰＣＳは、対話的な画面を構成する機能セグメントである。ＰＣＳは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにＰＣＳは、『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』と、『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』と、『ｐａｌｌｅｔ＿ｉｄ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｌ）〜（ｍ）』とから構成される。
【００３６】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』は、０から１５までの数値を用いてＤｉｓｐｌａｙ Ｓｅｔにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Ｅｐｏｃｈの先頭から本ＰＣＳまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒは設定される。
【００３７】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』は、本ＰＣＳから始まるＤｉｓｐｌａｙ Ｓｅｔが、Ｎｏｒｍａｌ Ｃａｓｅであるか、ＡＣｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔであるか、Ｅｐｏｃｈ Ｓｔａｒｔであるかを示す。
『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』は、本ＰＣＳにおいてＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅがなされているかどうかを示す。ＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本ＰＣＳでかかるアップデートがなされれば、本フィールドは”１”に設定される。
【００３８】
『ｐａｌｌｅｔ＿ｉｄ』は、本ＰＣＳにおいてＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅがなされているかどうかを示す。ＰａｌｌｅｔＯｎｌｙ Ｄｉｓｐｌｅｙ Ｕｐｄａｔｅとは、直前のＤｉｓｐｌａｙ Ｓｅｔから、パレットのみを新たなものに切り換えることでなされるアップデートをいう。本ＰＣＳでかかるアップデートがなされる場合、本フィールドは”１”に設定される。
【００３９】
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（１）・・・（ｎ）』は、このＰＣＳが属するＤｉｓｐｌａｙ Ｓｅｔにおける画面構成を実現するための制御情報である。図８（ｂ）の破線ｗｄ１は、任意のｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）の内部構成をクローズアップしている。この破線ｗｄ１に示すように、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）は、『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』、『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』、『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』、『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』からなる。
【００４０】
『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』は、グラフィクスオブジェクト識別子（ｏｂｊｅｃｔ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』は、ウィンドゥ識別子（ｗｉｎｄｏｗ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
【００４１】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”１”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”０”と設定された場合、グラフィクスオブジェクトは非表示となる。
【００４２】
『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』が１に設定されている場合に有効となる情報要素である。破線ｗｄ２は、任意のｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）の内部構成をクローズアップしている。この破線に示すようにｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』からなる。
【００４３】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ＥＴＳＩ ＥＮ ３００ ７４３標準規格における”Ｒｅｇｉｏｎ”に相当する。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
【００４４】
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がＰＣＳのデータ構造である。続いてＰＣＳの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとに』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるＥｐｏｃｈは、ＤＳ１（Ｅｐｏｃｈ Ｓｔａｒｔ）、ＤＳ２（Ｎｏｒｍａｌ Ｃａｓｅ）を有する。ＤＳ１は、字幕の表示枠となるｗｉｎｄｏｗを定義するＷＤＳ、台詞『ほんとに ごめん』を表すＯＤＳ、１つ目のＰＣＳを備える。ＤＳ２（Ｎｏｒｍａｌ Ｃａｓｅ）は、２つ目のＰＣＳを有する。
【００４５】
次に個々のＰＣＳをどのように記述するかについて説明する。Ｄｉｓｐｌａｙ Ｓｅｔに属するＷＤＳ、ＰＣＳの記述例を図１０〜図１２に示す。図１０は、ＤＳ１におけるＰＣＳの記述例を示す図である。
図１０において、ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおけるウィンドゥの左上座標ＬＰ１を、ｗｉｎｄｏｗ＿ｗｉｄｔｈ，ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、ウィンドゥの表示枠の横幅、縦幅を示す。
【００４６】
図１０におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ＳＴ１を示している。そして基準点からｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに示される範囲（図中の太枠部分）がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎを基準点（左上）とした破線の範囲ｃｐ１に配置される。こうすることにより、『本当に』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当に』は動画像と合成され表示される。
【００４７】
図１１は、ＤＳ２におけるＰＣＳの記述例を示す図である。本図におけるＷＤＳの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ，は、オブジェクトバッファ上の字幕『本当にごめん』のうち、『こめん』の左上座標を示し、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈは、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。
【００４８】
以上が機能セグメントについての説明である。続いてこれらＰＣＳ、ＯＤＳを有したＤｉｓｐｌａｙ Ｓｅｔが、ＡＶＣｌｉｐの再生時間軸上にどのように割り当てられるかについて説明する。Ｅｐｏｃｈは、再生時間軸上においてメモリ管理が連続する期間であり、Ｅｐｏｃｈは１つ以上のＤｉｓｐｌａｙ Ｓｅｔから構成されるので、Ｄｉｓｐｌａｙ ＳｅｔをどうやってＡＶＣｌｉｐの再生時間軸に割り当てるかが問題になる。ここでＡＶＣｌｉｐの再生時間軸とは、ＡＶＣｌｉｐに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、９０ＫＨｚの時間精度で表現される。Ｄｉｓｐｌａｙ Ｓｅｔ内のＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳは、この再生時間軸において同期制御を実現すべきタイミングを示す。このＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳを用いて同期制御を行うことが、再生時間軸へのＤｉｓｐｌａｙ Ｓｅｔの割り当でである。
【００４９】
Ｅｐｏｃｈに属するＤｉｓｐｌａｙ Ｓｅｔのうち、任意のＤｉｓｐｌａｙ ＳｅｔをＤＳｎとすると、ＤＳｎは、図１２に示すようなＤＴＳ、ＰＴＳ設定によりＡＶＣｌｉｐの再生時間軸に割り当てられる。図１２は、ＤＳｎが割り当てられた、ＡＶＣｌｉｐの再生時間軸を示す図である。本図においてＤＳｎの始期は、ＤＳｎに属するＰＣＳのＤＴＳ値（ＤＴＳ（ＤＳｎ［ＰＣＳ］））により示されており、終期は、ＤＳｎに属するＰＣＳのＰＴＳ値（ＰＴＳ（ＤＳｎ［ＰＣＳ］））により示されている。そしてＤＳｎにおいて最初の表示が行われるタイミングも、ＰＣＳのＰＴＳ値（ＰＴＳ（ＤＳｎ［ＰＣＳ］））に示されている。ＡＶＣｌｉｐ再生時間軸において、ビデオストリームの所望のピクチャが出現するタイミングと、ＰＴＳ（ＤＳｎ［ＰＣＳ］）とを一致させれば、ＤＳｎの最初の表示は、そのビデオストリームと同期することになる。
【００５０】
ＰＴＳ（ＤＳｎ［ＰＣＳ］）は、ＤＴＳ（ＤＳｎ［ＰＣＳ］）に、ＯＤＳのデコードに要する期間（ＤＥＣＯＤＥＤＵＲＡＴＩＯＮ）を足し合わせた値である。
最初の表示に必要なＯＤＳのデコードは、このＤＥＣＯＤＥＤＵＲＡＴＩＯＮ内に行われることになる。図６の期間ｍｃ１は、ＤＳｎに属する任意のＯＤＳ（ＯＤＳｍ）のデコードがなされる期間を示す。このデコード期間の開始点は、ＤＴＳ（ＯＤＳｎ［ＯＤＳｍ］）により示され、このデコードの終了点は、ＰＴＳ（ＯＤＳｎ［ＯＤＳｍ］）により示される。
【００５１】
以上のような再生時間軸への割り付けを、Ｅｐｏｃｈに属する全てのＯＤＳに対して行うことで、Ｅｐｏｃｈは規定されることになる。以上が再生時間軸に対する割り付けについての説明である。
Ｅｐｏｃｈは、グラフィクスデコーダにおけるメモリ管理が連続している単位であるので、本来なら１つのＡＶＣｌｉｐ内でＥｐｏｃｈは完結していなければならない。しかし２つのＡＶＣｌｉｐが順次再生される場合であって、所定の３つの条件が満たされるような場合、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈを定義することができる。
【００５２】
図１３（ａ）は、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈを示す図である。本図における第１段目は、連続して再生される２つのＡＶＣｌｉｐを示し、第２段目は、２つのＡＶＣｌｉｐ間で連続性をもつＥｐｏｃｈを示す。第３段目は、第２段目のＥｐｏｃｈに属するＤｉｓｐｌａｙ Ｓｅｔを示す。第２段目におけるＥｐｏｃｈは、ＡＶＣｌｉｐにより分断されない。しかし第３段目におけるＤｉｓｐｌａｙ Ｓｅｔは、このＡＶＣｌｉｐ境界の前後で２つのＤｉｓｐｌａｙ Ｓｅｔに分断されている。本図において注目すべきは、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、”Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅタイプ”になっていることである。
【００５３】
”Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅ”とは、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型であり、所定の３つの条件が満たされる場合、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われる。この３つの条件のうち、１つでも欠落があれば、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われる。
図１３（ｂ）は、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔがどのように取り扱われるかを示す図である。本図に示すように、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、後続ＡＶＣｌｉｐからの飛び込み再生が行われる場合、”Ｅｐｏｃｈ Ｓｔａｒｔ”として取り扱われ、先行ＡＶＣｌｉｐから連続再生が行われる場合、”Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ”として取り扱われることがわかる。
【００５４】
図１４は、２つのＡＶＣｌｉｐ間で連続性をもつための３つの条件を示す図である。本図における第１段目は、連続して再生される２つのＡＶＣｌｉｐを示し、第２段目は、３つのＥｐｏｃｈを示す。この３つのＥｐｏｃｈのうち、真ん中のＥｐｏｃｈが、２つのＡＶＣｌｉｐ間でメモリ管理の連続性をもつＥｐｏｃｈである。第３段目は、３つのＥｐｏｃｈのそれぞれに属するＤｉｓｐｌａｙ Ｓｅｔを示す。第２段目におけるＥｐｏｃｈは、ＡＶＣｌｉｐにより分断されることはなかったが、第３段目におけるＤｉｓｐｌａｙ Ｓｅｔは、このＡＶＣｌｉｐ境界の前後で２つのＤｉｓｐｌａｙ Ｓｅｔに分断されている。第４段目は、各Ｄｉｓｐｌａｙ Ｓｅｔに属する機能セグメントを示す。この第４段目における機能セグメント群は、図５の第４段目に示したものと同じである。図中の◎１，◎２，◎３が、２つのＡＶＣｌｉｐ間で連続性をもつようなＥｐｏｃｈの成立条件を示す。１つ目の条件は、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、第３段目に示すようにＥｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていることである。
【００５５】
２つ目の条件は、ＤＳｍ＋１に属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、１つ前のＤＳｍに属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒ（＝Ａ）と同じであること、つまりグラフィクス表示の内容が、ＡＶＣｌｉｐ境界の前後で同じであることを意味する。Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは、Ｄｉｓｐｌａｙ Ｓｅｔによる画面構成を意味するものである。このＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが同じであるということは、画面構成で得られるグラフィクスの内容が、ＤＳｍと、ＤＳｍ＋１とで同じであることを意味する。図１５は、ＤＳｍにおける画面構成と、ＤＳｍ＋１における画面構成とを対比して示す図である。本図に示すように、ＤＳｍによるグラフィクスの内容は『３年たった』であり、ＤＳｍ＋１によるグラフィクスの内容は『３年たった』であるので、２つのＤｉｓｐｌａｙ Ｓｅｔ間でグラフィクスの内容は同じであり、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが同一値になっていることがわかる。また、ビデオストリームの再生もシームレス接続になされているので、ＤＳｍ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることがわかる。
【００５６】
３つ目の条件は、先行ＡＶＣｌＩＰの再生と、後続ＡＶＣｌＩＰの再生とがシームレス接続されることである。このシームレス接続の条件には以下のものがある。
（ｉ）ビデオ属性情報に示されているビデオストリームの表示方式（ＮＴＳＣ、ＰＡＬ等）が、２つのＡＶＣｌｉｐ間で同一である。
（ｉｉ）オーディオ属性情報に示されているオーディオストリームのエンコード方式（ＡＣ−３、ＭＰＥＧ、ＬＰＣＭ等）が、２つのＡＶＣｌｉｐ間で同一である。
【００５７】
以上の（ｉ）〜（ｉｉ）においてシームレス再生が不可能となるのは、ビデオストリーム、オーディオストリームの表示方式、エンコード方式が異なる場合、ビデオデコーダ、オーディオデコーダが表示方式、エンコード方式、ビットレートの切り換えのためにその動作を停止してしまうからである。
例えば、連続して再生すべき２つのオーディオストリームにおいて、一方の符号化方式がＡＣ−３方式であり、他方がＭＰＥＧ規格である場合、ストリームがＡＣ−３からＭＰＥＧへ変化する際に、オーディオデコーダは、その内部でストリーム属性の切り替えを行うため、この間デコードが停止してしまう。ビデオストリームの属性が変わる場合も同様である。
【００５８】
これら（ｉ）〜（ｉｉ）の関係が全て満たされた場合のみ、シームレス接続がなされる。（ｉ）〜（ｉｉ）の関係のうち、１つでも満たされない場合、シームレス接続はなされない。
かかる３つの条件が満たされれば、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤＳｍ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。つまりＤｉｓｐｌａｙ Ｓｅｔ１〜ｍ、Ｄｉｓｐｌａｙ Ｓｅｔｍ＋１〜ｎ間は１つのＥｐｏｃｈを形成することになり、２つのＡＶＣｌｉｐの再生が順次行われたとしても、グラフィクスデコーダにおけるバッファの状態は維持される。
【００５９】
仮にＤＳｍ＋１の類型がＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであったとしても、残り２つの条件のうち、１つの欠落があれば、Ｅｐｏｃｈは、図１６に示すように、ＡＶＣｌｉｐの境界前後で２つに分断されることになる。以上のことからＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、上述したように３つの条件が全て満たされた場合にＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱われる。１つの条件が欠けた場合は、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われることになる。図１７は、１つのＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃１）に対して後続ＡＶＣｌｉｐ（ＡＶＣｌＩＰ＃２、ＡＶＣｌＩＰ＃３）が２つ有り、先行ＡＶＣｌＩＰが分岐点になっている場合のＥｐｏｃｈ Ｃｏｎｔｉｎｕｅの扱いを示す。２つの先行ＡＶＣｌＩＰのうち、ＡＶＣｌＩＰ＃１は図１４と同じであり、後続ＡＶＣｌｉｐの１つであるＡＶＣｌＩＰ＃２も、図１４と同じである。そのためＡＶＣｌＩＰ＃１、ＡＶＣｌＩＰ＃２は３つの条件を全て満たす。そのためＡＶＣｌＩＰ＃１から再生がなされた場合、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳｍ＋１）はＥｐｏｃｈ Ｃｏｎｔｉｎｕｅとして取り扱われることになる。もう一方の後続ＡＶＣｌｉｐであるＡＶＣｌＩＰ＃３はグラフィクス表示の内容が全く同じであり、ＡＶＣｌｉｐ＃１の最後のＤＳ（ＤＳｎ）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、ＡＶＣｌＩＰ＃３の最初のＤＳ（ＤＳ１）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致している。そのため、ＡＶＣｌＩＰ＃１→ＡＶＣｌＩＰ＃３の再生時には、３つの条件が全て満たされることになり、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔはＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。
【００６０】
図１８は、１つのＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃２）が２つの先行ＡＶＣｌＩＰ（ＡＶＣｌＩＰ＃１、ＡＶＣｌＩＰ＃４）の合流点になっている場合のＥｐｏｃｈ Ｃｏｎｔｉｎｕｅの扱いを示す。２つの先行ＡＶＣｌＩＰのうち、ＡＶＣｌＩＰ＃１は図１４と同じであり、ＡＶＣｌＩＰ＃２も図１４と同一であり、３つの条件を全て満たす。そのためＡＶＣｌＩＰ＃１から再生がなされた場合、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳ１）はＥｐｏｃｈ Ｃｏｎｔｉｎｕｅとして取り扱われることになる。一方、ＡＶＣｌＩＰ＃４もグラフィクス表示の内容が全く同じであり、ＡＶＣｌＩＰ＃４の最後のＤＳ（ＤＳｍ）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、ＡＶＣｌＩＰ＃２の最初のＤＳ（ＤＳ１）におけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致している。そのため、ＡＶＣｌＩＰ＃４→ＡＶＣｌＩＰ＃２の再生時には、３つの条件が全て満たされることになり、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔはＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして取り扱われることになる。
【００６１】
以上がＡＶＣｌｉｐについての説明である。続いて拡張子”ｃｌｐｉ”が付与されたファイル、及び、拡張子”ｍｐｌｓ”が付与されたファイルについて説明する。図１９は、ｃｌｐｉ”が付与されたファイル、及び、拡張子”ｍｐｌｓ”が付与されたファイルを示す図である。
拡張子”ｃｌｐｉ”が付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、ＡＶＣｌｉｐのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐ、ＡＴＣ＿ｄｅｌｔａをもっている。ＡＴＣ＿ｄｅｌｔａのＡＴＣ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋ）とは、ＡＴＳの基準となるＣｌｏｃｋであり、ＡＴＣ＿ｄｅｌｔａは、先に再生されるＡＶＣｌｉｐのＡＴＣと、後に再生されるＡＶＣｌｉｐのＡＴＣとの間の差分を意味する。
【００６２】
拡張子”ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３．ｍｐｌｓ・・・・・）は、ＰＬ情報を格納したファイルである。ＰＬ情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。図２０は、ＰＬ情報の構成を示す図であり、本図の左側に示すように、ＰＬ情報は、破線の矢印ｍｐ１に示すように複数のＰｌａｙＩｔｅｍ情報（ＰｌａｙＩｔｅｍ（））からなる。ＰｌａｙＩｔｅｍとは、１つ以上のＡＶＣｌｉｐ時間軸上において、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで定義される再生区間である。ＰｌａｙＩｔｅｍ情報を複数配置させることで、複数再生区間からなるプレイリスト（ＰＬ）が定義される。図中の破線ｍｐ２は、ＰｌａｙＩｔｅｍ情報の内部構成をクローズアップしている。本図に示すようにＰｌａｙＩｔｅｍ情報は、対応するＡＶＣｌｉｐを示す『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』と、『ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』とからなる。
【００６３】
２つのＡＶＣｌｉｐを１つのＰｌａｙＬｉｓｔとして取り扱う場合のＰＬ情報の設定について図２１を参照しながら説明する。図２１の第１段目は、図１５に示した２つのＡＶＣｌｉｐを示し、図２１の第２段目は、ＰＬ情報により定義されるＰｌａｙＬｉｓｔ時間軸を示す。ＰＬ情報が２つのＰｌａｙＩｔｅｍ情報を含んでおり（ＰｌａｙＩｔｅｍ＃１、ＰｌａｙＩｔｅｍ＃２）、ＰｌａｙＩｔｅｍ＃１のＩｎ＿ｔｉｍｅ、Ｏｕｔ＿ｔｉｍｅがＡＶＣｌｉｐの始点、終点を指し示していて、ＰｌａｙＩｔｅｍ＃２のＩｎ＿ｔｉｍｅ、Ｏｕｔ＿ｔｉｍｅがＡＶＣｌｉｐの始点、終点を指し示している場合、これら先行ＡＶＣｌＩＰ及び後続ＡＶＣｌＩＰは、１つのＰｌａｙＬｉｓｔとして取り扱われることになる。図２１の第２段目は、ＰＬ情報により定義されるＰｌａｙＬｉｓｔの再生時間軸（ＰＬ再生時間軸）を示す。このようにＰｌａｙＬｉｓｔを定義すると、ＡＶＣｌｉｐはいわばＰｌａｙＬｉｓｔの部分区間として取り扱われることになる。ＰｌａｙＬｉｓｔの部分区間はＰｌａｙＩｔｅｍと呼ばれる。つまりＰｌａｙＩｔｅｍ＝ＡＶＣｌｉｐの関係が成り立つ。
【００６４】
ＰｌａｙＩｔｅｍを定義するＰｌａｙＩｔｅｍ情報には、ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎというフィールドがあり、先行するＰｌａｙＩｔｅｍ（ＡＶＣｌｉｐ）との再生がシームレスになされるか否かを示す。
図２２は、各ＰｌａｙＩｔｅｍ（ＡＶＣｌｉｐ）に属するＤｉｓｐｌａｙ Ｓｅｔと、各ＰｌａｙＩｔｅｍにおけるｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎとを示す図である。ここでＰｌａｙＩｔｅｍ＃２に属するＤｉｓｐｌａｙ Ｓｅｔのうち、先頭のもの（ＤＳｍ＋１）のＳｅｇｍｅｎｔ ＴｙｐｅがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであり、ＰｌａｙＩｔｅｍ＃２のｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎがシームレス接続を示しているなら、ＰｌａｙＩｔｅｍ＃２（後続ＡＶＣｌＩＰ）の先頭にあたるＤＳｍ＋１と、ＰｌａｙＩｔｅｍ＃１（先行ＡＶＣｌｉｐ）の最後にあたるＤＳｍとは同一のＥｐｏｃｈに属することになる。図２３は、ＰｌａｙＩｔｅｍ＃２（後続ＡＶＣｌＩＰ）の先頭にあたるＤＳｍ＋１と、ＰｌａｙＩｔｅｍ＃１（先行ＡＶＣｌｉｐ）の最後にあたるＤＳｍとが属する同一のＥｐｏｃｈを示す図である。先行ＡＶＣｌｉｐにおける最後のＤｉｓｐｌａｙ Ｓｅｔと、後続ＡＶＣｌｉｐにおける最初のＤｉｓｐｌａｙ Ｓｅｔとが同一のＥｐｏｃｈに帰属するので、これら２つのＤｉｓｐｌａｙ Ｓｅｔによるグラフィクス表示は連続してなされることになる。
【００６５】
これまでに説明したＤｉｓｐｌａｙ Ｓｅｔ（ＰＣＳ，ＷＤＳ，ＰＤＳ，ＯＤＳ）のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｆｏｒｍａｔに規定された構文に従い、クラス構造体を記述することで、ＢＤ−ＲＯＭ上のこれらのデータ構造を得ることができる。以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２４は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置、マイコンシステムという３つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤドライブ１、Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａ、Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂ、ＰＩＤフィルタ３、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃ、周辺回路４ｄ、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、ＣＬＵＴ部９、加算器１０、グラフィクスデコーダ１２、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌコントローラ１７から構成される。
【００６６】
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行して、３２個のセクタからなるＡｌｉｇｎｅｄ ＵｎｉｔをＢＤ−ＲＯＭから読み出す。
Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａは、２７ＭＨｚの水晶発振器（２７ＭＨｚ Ｘ−ｔａｌ）に基づき、Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋを生成する。Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋとは、ＴＳパケットに付与されたＡＴＳの基準となる時間軸を規定するクロック信号である。
【００６７】
Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂは、ＢＤ−ＲＯＭから３２個のセクタからなるＡｌｉｇｎｅｄ Ｕｎｉｔが読み出されれば、Ａｌｉｇｎｅｄ Ｕｎｉｔを構成するそれぞれのＴＳパケットから、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外して、ＴＳパケットのみをＰＩＤフィルタ３に出力する。Ｓｏｕｒｃｅ ｄｅ−Ｐａｃｋｅｔｉｚｅｒ２ｂによるＰＩＤフィルタ３への出力は、Ａｒｒｉｖａｌ ｔｉｍｅ Ｃｌｏｃｋ Ｃｏｕｎｔｅｒ２ａが経時している時刻が、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒに示されるＡＴＳになったタイミングになされる。ＰＩＤフィルタ３への出力は、ＡＴＳに従いなされるので、たとえＢＤ−ＲＯＭからの読み出しに１倍速、２倍速といった速度差があっても、ＰＩＤフィルタ３へのＴＳパケット出力は、Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋが経時する現在時間に従いなされることになる。２つのＡＶＣｌｉｐを連続再生しようとする場合、Ｓｏｕｒｃｅ ｄｅ−ｐａｃｋｅｔｅｔｉｚｅｒ２ｂは、Ｃｌｉｐ情報中に存在するＡＴＣ＿Ｄｅｌｔａを用いて、２つのＡＶＣｌｉｐにおけるＡＴＣのズレを調整する。
【００６８】
ＰＩＤ Ｆｉｌｔｅｒ３は、ＴＳパケットに付加されているＰＩＤを参照することにより、ＴＳパケットが、ビデオストリーム、ＰＧストリーム、ＩＧストリームの何れに帰属するのかを判定して、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃのどれかに出力する。
Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃは、ＰＩＤフィルタ３から出力されたＴＳパケットを先入れ先出し式に格納しておくメモリである。
【００６９】
周辺回路４ｄは、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃから読み出されたＴＳパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはＣｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３に格納される。
ビデオデコーダ５は、ＰＩＤフィルタ３から出力された複数ＴＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
【００７０】
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、ＰＩＤフィルタ３から出力されたＴＳパケットを復号して、非圧縮形式のオーディオデータを出力する。
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
【００７１】
ＣＬＵＴ部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、ＰＤＳに示されるＹ，Ｃｒ，Ｃｂ値に基づき変換する。
加算器１０は、ＣＬＵＴ部９により色変換された非圧縮グラフィクスに、ＰＤＳに示されるＴ値（透過率）を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
【００７２】
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
このグラフィクスデコーダ１２は、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌコントローラ１７から構成される。
【００７３】
Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３は、機能セグメントがＤＴＳ、ＰＴＳと共に格納されるバッファである。かかる機能セグメントは、Ｔｒａｎｓｐｏｒｔ Ｂｕｆｆｅｒ４ａ，ｂ，ｃに格納されたトランスポートストリームの各ＴＳパケットから、ＴＳパケットヘッダ、ＰＥＳパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたＴＳパケットヘッダ、ＰＥＳパケットヘッダのうち、ＰＴＳ／ＤＴＳは、ＰＥＳパケットと対応付けて格納される。
【００７４】
周辺回路１３ａは、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３−Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４間の転送、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３−Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がＯＤＳのＤＴＳに示される時刻になれば、ＯＤＳを、Ｃｏｄｅｄ Ｄａｔａ Ｂｕｆｆｅｒ１３からＳｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４に転送する。また現在時刻がＰＣＳ、ＰＤＳのＤＴＳに示される時刻になれば、ＰＣＳ、ＰＤＳをＣｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６に転送するという処理を行う。
【００７５】
Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４は、ＯＤＳをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５に書き込む。Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４は一時的に保持する。Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時になされるが、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４からＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込みは、瞬時には終わらない。ＢＤ−ＲＯＭ規格のプレーヤモデルでは、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込みは、１２８Ｍｂｐｓという転送レートでなされるからである。Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込み完了時点は、ＥＮＤセグメントのＰＴＳに示されているので、このＥＮＤセグメントのＰＴＳに示される時点が経過するまで、次のＤＳに対する処理を待つことになる。各ＯＤＳをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのＯＤＳに関連付けられたＤＴＳの時刻に開始し、ＯＤＳに関連付けられたＰＴＳに示されるデコード終了時刻までに終了する。
【００７６】
Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５は、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｏｒ１４のデコードにより得られたグラフィクスオブジェクトが配置されるバッファである。Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５は、グラフィクスプレーン８の２倍／４倍の大きさに設定せねばならない。何故ならＳｃｒｏｌｌｉｎｇを実現する場合を考えると、グラフィクスプレーン８の２倍、４倍のグラフィクスオブジェクトを格納しておかねばならないからである。
【００７７】
Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６は、ＰＣＳ、ＰＤＳが配置されるメモリである。――処理すべきＤｉｓｐｌａｙ Ｓｅｔが２つあり、これらのＰＣＳのアクティブ期間が重複している場合、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６には処理すべきＰＣＳが複数格納される。
Ｇｒａｐｈｉｃａｌコントローラ１７は、Ｇｒａｐｈｉｃａｌコントローラ１７はＰＣＳの解読を行い、ＰＣＳの解読結果に従って、グラフィクスオブジェクトのＯｂｊｅｃｔ Ｂｕｆｆｅｒ１５への書き込み、及び、Ｏｂｊｅｃｔ Ｂｕｆｆｅｒ１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Ｇｒａｐｈｉｃａｌコントローラ１７による表示は、ＰＣＳを格納したＰＥＳパケットのＰＴＳに示される時点において実行される。Ｇｒａｐｈｉｃａｌコントローラ１７によるＤＳｎに属するグラフィクスオブジェクトの表示から、ＤＳｎ＋１に属するグラフィクスオブジェクトの表示までの間隔は上述した通りである。
【００７８】
図２５は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてＳｅｇｍｅｎｔＫとは、ＡＶＣｌｉｐの再生時において、読み出されたＳｅｇｍｅｎｔ（ＩＣＳ，ＰＤＳ，ＯＤＳ）のそれぞれを意味する変数であり、無視フラグは、このＳｅｇｍｅｎｔＫを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを０に初期化した上で（ステップＳ１）、ステップＳ２〜Ｓ１３の処理を全てのＳｅｇｍｅｎｔについて繰り返すループ構造を有している（ステップＳ１４、ステップＳ１５）。
【００７９】
ループ構造をもつステップＳ２〜ステップＳ１５の処理は、無視フラグが１かどうかを判定して（ステップＳ３）、無視フラグが０であるなら、対象となる機能セグメントをＣｏｄｅｄ Ｄａｔａバッファ１３からＣｏｍｐｏｓｉｔｉｏｎバッファ１６、Ｓｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサ１４のどれかに転送し（ステップＳ４）、無視フラグが１であるならかかる転送を行わずＣｏｄｅｄ Ｄａｔａバッファ１３上で、対象となる機能セグメントを削除する（ステップＳ５）という処理を、機能セグメントの読み出しが継続している限り繰り返すものである。
【００８０】
ＳｅｇｍｅｎｔＫが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ９、Ｓ１０は、この無視フラグを設定する処理である。
ステップＳ６は、ＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであるか否かの判定である。ＳｅｇｍｅｎｔＫがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅであるなら、ステップＳ７〜ステップＳ９が実行され、ＳｅｇｍｅｎｔＫがもしＥｐｏｃｈ ＳｔａｒｔかＮｏｒｍａｌ Ｃａｓｅであるなら、ステップＳ１０〜ステップＳ１２が実行される。
【００８１】
ステップＳ７〜ステップＳ９は、ステップＳ７、ステップＳ８という２回の判定を行い、これらの判定が両方ともＹｅｓであった場合のみ、無視フラグを１に設定する（ステップＳ９）。
ステップＳ７は、ＰＣＳが属するＰｌａｙＩｔｅｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎが”＝５（シームレス接続）”であるか否かの判定である。ステップＳ８は、新たに読み出されたＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６上にあるＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと同一であるか否かの判定である。
【００８２】
これらのステップＳ７、ステップＳ８のどちらかがＮｏであれば、ステップＳ１０に移行して、無視フラグを０に設定する。ステップＳ７、ステップＳ８の双方がＹｅｓであれば、無視フラグは１に設定されることになる（ステップＳ９）。
ステップＳ１１は、新たに読み出されたＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＮｏｒｍａｌ Ｃａｓｅであるか否かの判定であるか、Ｅｐｏｃｈ Ｓｔａｒｔであるかの判定である。もしＥｐｏｃｈ Ｓｔａｒｔであるなら、無視フラグを０に設定する（ステップＳ１０）。
【００８３】
ステップＳ１１は、ＰＣＳにおけるＣｏｍｐｏｓｉｔｉｏｎ＿ＳｔａｔｅがＮｏｒｍａｌ Ｃａｓｅであるか否かの判定である。もしＮｏｒｍａｌ Ｃａｓｅであるなら、追加のチェックとしてステップＳ１２を実行する。ステップＳ１２は、グラフィクスオブジェクトがＯｂｊｅｃｔ Ｂｕｆｆｅｒに存在しており、ＰＣＳ，ＰＤＳ，ＷＤＳがＣｏｍｐｏｓｉｔｉｏｎ Ｂｕｆｆｅｒ１６に存在するかの判定である。もし、存在すれば無視フラグを０に設定する（ステップＳ１０）。存在しなければ、ステップＳ９に移行する。
【００８４】
Ｏｂｊｅｃｔ Ｂｕｆｆｅｒにグラフィクスオブジェクトが存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないという理由による。
図２６は、図１４に示した２つのＡＶＣｌｉｐを再生するにあたってのＤｉｓｐｌａｙ Ｓｅｔ読み出しがどのように行われるかを示す図である。第３段目は、ＡＶＣｌｉｐに多重化されているＤｉｓｐｌａｙ Ｓｅｔを示し、第２段目は、ビデオストリームを構成する複数のピクチャを、第１段目はグラフィクスデコーダにおける状態を示す。
【００８５】
Ｅｐｏｃｈの先頭に位置するＤＳ１の読み出し時には、グラフィクスデコーダに対するリセットがなされ、ＤＳ１を構成するＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳがＣｏｄｅｄ Ｄａｔａバッファ１３に順次読み出されることになる。そしてＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送され、ＯＤＳはＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることになる。
【００８６】
矢印ｍｒ１は、ＤＳｍの読み出し時を示す。ＤＳｍを構成するＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳがＣｏｄｅｄ Ｄａｔａバッファ１３に順次読み出されることになる。このＤＳｍのｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎは、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔなので、ＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送されることなく廃棄される。一方、ＯＤＳもＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることなく廃棄される。
【００８７】
矢印ｍｒ２は、ＤＳｍ＋１の読み出し時を示す。この場合グラフィクスデコーダは、３つの条件が満たされるか否かを判定する。ＤＳｍ＋１のＣｈａｎｇｅ ｓｔｒｅａｍがＥｐｏｃｈ Ｃｏｎｔｉｎｕｅを示しており、ビデオストリームの再生がシームレスになされ、そしてＤＳｍ＋１のＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６上のＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致していれば、これら３つの条件が満たされることになり、ＤＳｍ＋１をＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱う。これにより再生装置は、グラフィクスデコーダをリセットせず、Ｃｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳ、ＷＤＳ、ＰＤＳをＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送することなく廃棄する。一方、ＯＤＳもＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力することなく廃棄する。こうすることで、グラフィクスデコーダの状態は継続することになる。
【００８８】
以上が通常再生時における処理であるが、チャプタージャンプやチャプターサーチによりＡＶＣｌＩＰへの飛び込み再生がなされた場合、この飛び込みの指示と同時に、グラフィクスデコーダのリセットがなされることになる。これによりグラフィクスデコーダ上で管理されているカレントＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは、新たに再生されようとする先行ＡＶＣｌＩＰにおけるＤＳｍ＋１のＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと一致することはない。このためＤＳｍ＋１は、飛び込み再生時において、Ｅｐｏｃｈ Ｓｔａｒｔとして取り扱われることになる。
【００８９】
図２７は、図１４に示したＡＶＣｌＩＰ＃２への飛び込み再生が順次なされる場合のグラフィクスデコーダへの読み出しを示す。第１段目〜第３段目の意味内容は、図２６と同じであり、矢印の意味合いも図と同じである。ただ、グラフィクスの表示内容が図２６と違っているため、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒは違う値になっている。後続ＡＶＣｌｉｐの再生が開始され、ＤＳｍ＋１がＣｏｄｅｄ Ｄａｔａバッファ１３に読み出されると、グラフィクスデコーダはＣｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳを解読してＤＳｍ＋１におけるＣｈａｎｇｅ ｓｔｒｅａｍが何であるかを判定する。Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅであれば残る２つの条件を判定する。ここでビデオストリームの再生がシームレスに行われたとしても、Ｃｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが先行ＡＶＣｌＩＰから変化しているためグラフィクスデコーダはＤＳｍ＋１をＥｐｏｃｈ Ｓｔａｒｔとして扱う。これによりグラフィクスデコーダはリセットされ、Ｃｏｄｅｄ Ｄａｔａバッファ１３に読み出されたＰＣＳ、ＷＤＳ、ＰＤＳはＣｏｍｐｏｓｉｔｉｏｎバッファ１６に転送され、ＯＤＳはＳｔｒｅａｍ Ｇｒａｐｈｉｃｓプロセッサに出力されることになる。
【００９０】
（第２実施形態）
第２実施形態は、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅを実現するためのＰＴＳ設定に関する実施形態である。２つのＡＶＣｌｉｐを順次再生しようとする場合、これらが基準としているクロックが異なることを考慮せねばならない。オーサリング時においてＡＶＣｌｉｐは、それぞれ別々の機会にエンコードされるから、２つのＡＶＣｌｉｐは、別々のクロック信号を基準にして生成される。ＡＶＣｌｉｐ生成時にあたって、エンコードの基準に用いられるクロックをＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）という。かかるＳＴＣは、再生装置の再生時においてもデコード処理の基準になる。
【００９１】
ＳＴＣが異なる２つのＡＶＣｌｉｐを連続して再生させるため、再生装置は、ＳＴＣのズレ量（ＳＴＣ＿ｄｅｌｔａ）を算出して、自身が内蔵しているクロックの計数値に、このＳＴＣ＿ｄｅｌｔａを加算することにより、かかるＳＴＣの違いを吸収する。図２８は、先行ＡＶＣｌＩＰに属するビデオストリームのＰＴＳ値と、後続ＡＶＣｌＩＰに属するビデオストリームのＰＴＳ値とを対比して示す図である。先行ＡＶＣｌＩＰにおいて最後に再生される再生装置の表示開始時刻をＰＴＳ（１ｓｔＥＮＤ）、ピクチャの表示期間をＴｐｐとし、後続ＡＶＣｌＩＰにおいて最初に表示されるピクチャの開始時刻をＰＴＳ（２ｎｄＳＴＡＲＴ）とした場合、ＳＴＣ＿ｄｅｌｔａは
ＳＴＣ＿ｄｅｌｔａ＝ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐ−ＰＴＳ（２ｎｄＳＴＡＲＴ）
として表現される。これは、２つのＡＶＣｌｉｐを順次再生する際、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐと、ＰＴＳ（２ｎｄＳＴＡＲＴ）とは本来一致するべきであり、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐと、ＰＴＳ（２ｎｄＳＴＡＲＴ）との違いがＳＴＣの違いであると考えることができるという理由による。
【００９２】
２つのＡＶＣｌｉｐを連続して再生しようとする場合、ＰＴＳ（１ｓｔＥＮＤ）、ＰＴＳ（２ｎｄＳＴＡＲＴ）をそれぞれ検出して、これらからＳＴＣ＿ｄｅｌｔａを算出する。そして再生装置に内蔵されているクロックの計数値にＳＴＣ＿ｄｅｌｔａを足し合わせて、ＳＴＣ＿ｄｅｌｔａが足し合わされたクロックの計数値をビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２のそれぞれに出力する。このようにＳＴＣ＿ｄｅｌｔａが足し合わされたクロック計数値を基準することで、ビデオデコーダ５、オーディオデコーダ７、グラフィクスデコーダ１２は、２つのＡＶＣｌｉｐに属するビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリームを途切れなく再生してゆくことができる。
【００９３】
かかる処理を円滑に行うため、後続ＡＶＣｌＩＰに属するプレゼンテーショングラフィクスストリームにおいて、先頭に位置するＤＳｍ＋１のＰＴＳ（ＤＳｍ＋１［ＰＣＳ］）の値を調整しておく。どのように調整するかというと、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐ及びＰＴＳ（２ｎｄＳＴＡＲＴ）と同じ時刻を指すように、調整しておくのである。これは以下の理由による。再生装置は、先行ＡＶＣｌＩＰにおける最後のグラフィクス表示が行われてから。後続ＡＶＣｌＩＰにおける最初の表示が行われるまでの間隔が長いと、一旦グラフィクスデコーダをリセットしてしまうことがある。ＢＤ−ＲＯＭにおける複数ＡＶＣｌｉｐは、それぞれ別々のファイルに格納されているため、２つのファイルを連続して読み出すにはタイムラグがあり、２つのＡＶＣｌｉｐの読み出しが遅れた場合は、リセットがなされる確率がますます高くなる。そこで後続ＡＶＣｌＩＰの先頭に位置するＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔは、ビデオストリームの最初のピクチャが表示されるのと同じタイミングで、グラフィクス表示が行われるよう、ＰＴＳ（１ｓｔＥＮＤ）＋Ｔｐｐの値と、同じ時刻を示すように、ＰＴＳ（ＤＳｍ＋１［ＰＣＳ］）の値を設定しておく。
【００９４】
こうすることで、先行ＡＶＣｌＩＰの読み出しの完了後から後続ＡＶＣｌＩＰの読み出し開始までのタイムラグが長くなったとしても、先行ＡＶＣｌＩＰにおける最後のグラフィクス表示が行われてから、後続ＡＶＣｌＩＰにおける最初の表示が行われるまでの間隔は最短にしておくことができる。こうすることにより再生装置はグラフィクスデコーダをリセットすることはないので、そのままメモリ状態を継続させることができる。
【００９５】
（第３実施形態）
第１実施形態では、ＰＧストリームについて説明を行ったが、第３実施形態はＩＧストリームについての実施形態である。続いてインタラクティブグラフィクスストリームについて説明する。図２９（ａ）は、インタラクティブグラフィクスストリームの構成を示す図である。第１段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。第２段目は、グラフィクスストリームを構成するＰＥＳパケット列を示す。第２段目におけるＰＥＳパケット列は、第１段目におけるＴＳパケットのうち、所定のＰＩＤをもつＴＳパケットからペイロードを取り出して、連結することにより構成される。尚、プレゼンテーショングラフィクスストリームについては、本願の主眼ではないので説明は行わない。
【００９６】
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ＩＣＳ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ Ｄｉｆｉｎｉｔｉｏｎ Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ）、ＥＮＤ（ＥＮＤ ｏｆ Ｄｉｓｐｌａｙ Ｓｅｔ Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ＩＣＳは、画面構成セグメントと呼ばれ、ＰＤＳ、ＯＤＳ、ＥＮＤは定義セグメントと呼ばれる。ＰＥＳパケットと機能セグメントとの対応関係は、１対１の関係、１対多の関係である。つまり機能セグメントは、１つのＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録されるか、又は、フラグメント化され、複数ＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録される。図２９（ｂ）は、機能セグメントを変換することにより得られるＰＥＳパケットを示す図である。
【００９７】
以降、各機能セグメントについて説明する。
『Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｍｐｏｓｉｔｉｏｎ Ｓｅｇｍｅｎｔ（ＩＣＳ）』は、対話的なグラフィクスオブジェクトの画面構成を制御する機能セグメントである。対話的な画面構成の１つとして、本実施形態のＩＣＳは、マルチページメニューを実現するものとする。
【００９８】
これら様々な種別の機能セグメントは、図３０のような論理構造を構築する。図３０は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第１段目にＥｐｏｃｈを、第２段目にＤｉｓｐｌａｙ Ｓｅｔを、第３段目にＤｉｓｐｌａｙ Ｓｅｔの類型をそれぞれ示す。図２９（ａ）の第３段目に示した機能セグメントは第４段目に描かれている。ＩＧストリームにも、Ｅｐｏｃｈ Ｓｔａｒｔ、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅという類型があるが、ＰＣＳと異なるのは、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔという類型においてページ毎のバージョンアップが可能になることである。
【００９９】
ＩＧストリームは、上述した再生時間軸における動画の再生進行に応じて、マルチページメニューの挙動を制御することを特徴としている。この特徴を実現するための新規な構成は、ＩＣＳ内のＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎに存在する。以降ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの内部構成について以下説明する。
【０１００】
図３１（ａ）（ｂ）は、ＩＣＳとＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎとの対応関係を示す図である。ＩＣＳとＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎとの対応関係には、図７（ａ）に示すような１対１のものと、図３１（ｂ）に示すような１対多のものとがある。
対応関係が１対１になるのは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズが小さく、１つのＩＣＳ内にＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが収まる場合である。
【０１０１】
１対多の対応関係になるのは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズが大きく、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎがフラグメント化され、複数ＩＣＳに格納される場合である。複数ＩＣＳへの格納が可能なので、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎサイズには制限がなく、５１２Ｋバイトであろうと、１Ｍバイトであろうと、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのサイズを大きくすることができる。ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎには１対多の対応関係もあり得るが、簡単を期するため、以降の説明では、ＩＣＳ、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの対応関係は、１対１であるとする。
【０１０２】
図３２は、ＩＣＳの内部構成を示す図である。ＩＣＳには、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎの全体、又は、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎをフラグメント化することで得られた一部が格納されている。図８の左側に示すように、ＩＣＳは、自身がＩＣＳであることを示す『ｓｅｇｍｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ』と、本ＩＣＳが想定している縦横の画素数、フレームレートを示す『ｖｉｄｅｏ＿ｄｅｓｃｒｉｐｔｏｒ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』と、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎの全体、又は、Ｉｎｔｅｒａｃｔｉｖｅ＿Ｃｏｍｐｏｓｉｔｉｏｎをフラグメント化することで得られた一部である『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』とからなる。
【０１０３】
図３２中の矢印ｃｕ１は、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』の内部構成をクローズアップして示す。この矢印ｃｕ１に示すように『ｃｏｍｐｏｓｉｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ』は、本ＩＣＳが属するＤｉｓｐｌａｙ Ｓｅｔが、Ｎｏｒｍａｌ Ｃａｓｅ、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｅｐｏｃｈ Ｓｔａｒｔ、Ｅｆｆｅｃｔ＿Ｓｅｑｕｅｎｃｅの何れであるかを示す『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』と、画面合成の回数を示す『Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｎｕｍｂｅｒ』とを含む。
【０１０４】
図３２の矢印ｃｕ２は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎの内部構成をクローズアップしている。この矢印に示すようにＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎは、『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｌｅｎｇｔｈ』，『Ｓｔｒｅａｍ＿ｍｏｄｅｌ』，『ｕｓｅｒ＿ｉｎｔｅｒｆａｃｅ＿ｍｏｄｅｌ』，『ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』，『ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』，『ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｒａｔｉｏｎ』、マルチページメニューにおいて表示可能な複数ページのそれぞれに対応する『ページ情報（１）（２）・・・（ｉ）・・・（ｎｕｍｂｅｒ＿ｏｆ＿ｐａｇｅ−１）』を含む。
【０１０５】
『Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｌｅｎｇｔｈ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎのデータ長を示す。
『Ｓｔｒｅａｍ＿ｍｏｄｅｌ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが想定しているストリームモデルのタイプを示す。ストリームモデルとは、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎがどのような形態でＢＤ−ＲＯＭに記録されて、再生装置におけるコンポジションバッファ上でどのように扱われるかを示すものであり、Ｓｔｒｅａｍ＿ｍｏｄｅｌは、グラフィクスストリームがＡＶＣｌｉｐから多重分離されてコンポジションバッファ上にロードされたものであるか（ｉ）、ＳｕｂＣｌｉｐとして、コンポジションバッファにプリロードされたものであるか（ｉｉ）を示す。
【０１０６】
『ｕｓｅｒ＿ｉｎｔｅｒｆａｃｅ＿ｍｏｄｅｌ』は、Ｉｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎが想定しているユーザインターフェイスモデルが、Ａｌｗａｙｓ−ｏｎＵ／ＩであるかＰｏｐ−ｕｐＵ／Ｉであるかを示す。Ａｌｗａｙｓ−ｏｎＵ／Ｉとは、ＡＶＣｌｉｐの再生進行に伴ってメニューの表示・消去がなされるユーザインターフェイスであり、ポップアップＵ／Ｉとは、ユーザによる操作をトリガにしてメニューの表示・消去がなされるユーザインターフェイスである。
【０１０７】
『Ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』は、ＩＣＳが帰属するＥｐｏｃｈの終期（Ｅｐｏｃｈ ＥＮＤ）を示す。ＩＣＳによる対話制御は、このＥｐｏｃｈ終期（Ｅｐｏｃｈ ＥＮＤ）においてもはや不可能となるので、このｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓに示される時点が、対話制御の終期を意味する。
『ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ』は、セレクテッド状態にあるボタンを自動的にアクティベートするためのタイムアウト時刻を示す。ボタンとは、マルチページメニューにおける個々の選択項目であり、かかるボタンの状態をアクティブ状態に変化させる時間を規定しているのがこのｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓである。
【０１０８】
図中のＩＦ文（ｉｆ（Ｓｔｒｅａｍ＿ｍｏｄｅｌ＝＝’０ｂ’））は、上述したｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ及びｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓが、Ｓｔｒｅａｍ＿ｍｏｄｅｌ＝Ｍｕｌｔｉｐｌｅｘｅｄの際、出現する任意の情報要素であることを示してる。ＩＣＳが想定しているストリームモデルがプリロードである場合、これらｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓ、ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓは存在しない。
【０１０９】
『ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎ』は、ユーザ操作により表示され得るページを消去するためのタイムアウト時刻を示す。Ａｌｗａｙｓ−ｏｎＵ／Ｉでは、２ｎｄＰａｇｅ以降のＰａｇｅ（ＳｕｂＰａｇｅという）がユーザ操作により表示されるので、このｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎのタイムアウトにより、ＳｕｂＰａｇｅのみが消去され、１ｓｔＰａｇｅのみとなる。Ｐｏｐ−ｕｐＵ／Ｉでは、ＳｕｂＰａｇｅだけではなく、マルチページメニュー全体がユーザ操作により表示されるので、ｕｓｅｒ＿ｔｉｍｅ＿ｏｕｔ＿ｄｕｔｒａｔｉｏｎのタイムアウトにより、全てのページが消去され何も表示されない状態（Ｎｏ Ｍｅｎｕ Ｄｉｓｐｌａｙ）になる。
【０１１０】
図３３は、１つのＤｉｓｐｌａｙ Ｓｅｔにおけるｘ番目のＤｉｓｐｌａｙ Ｓｅｔに属する複数ページのうち、任意のもの（ｙ枚目のページ）についてのページ情報の内部構成を示す図である。この図３３の右側に示すようにＰａｇｅ情報（ｙ）は、
ｉ）Ｐａｇｅ（ｙ）を一意に識別する『ｐａｇｅ＿ｉｄ』、
ｉｉ）Ｐａｇｅ情報（ｙ）により運搬されるデータ構造の中身にあたる，『ＵＯ＿Ｍａｓｋ＿Ｔａｂｌｅ』、『ｉｎ＿ｅｆｆｅｃｔ』，『ｏｕｔ＿ｅｆｆｅｃｔ』，『ａｎｉｍａｔｉｏｎ＿ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ』，『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』、『ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』，『ｐａｌｌｅｔ＿ｉｄ＿ｒｅｆ』，『ボタン情報（１）（２）・・・・・（ｎｕｍｂｅｒ＿ｏｆ＿ｂｕｔｔｏｎｓ−１）』、
ｉｉｉ）Ｐａｇｅ情報（ｙ）の中身のバージョンを示す『Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ』から構成される。
【０１１１】
先ず初めに、Ｐａｇｅ情報（ｙ）により運搬されるデータ構造を構成する各フィールドについて説明する。
『ＵＯ＿Ｍａｓｋ＿Ｔａｂｌｅ』は、Ｐａｇｅ（ｙ）におけるユーザ操作の許可／不許可が設定されるテーブルである。
『ｉｎ＿ｅｆｆｅｃｔ』は、Ｐａｇｅ（ｙ）の表示開始時あたって再生すべき表示効果を示す。『ｏｕｔ＿ｅｆｆｅｃｔ』は、Ｐａｇｅ（ｙ）の表示終了時あたって再生すべき表示効果を示す。
【０１１２】
『ａｎｉｍａｔｉｏｎ＿ｆｒａｍｅ＿ｒａｔｅ＿ｃｏｄｅ』は、Ｐａｇｅ（ｙ）にアニメーション表示を適用する際、適用すべきフレームレートを記述する。
『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』は、Ｐａｇｅ（ｙ）の表示が始まったとき、デフォルトでセレクテッド状態に設定すべきボタンを動的に定めるか、静的に定めるかを示す。本フィールドが”ＯｘＦＦ”であれば、デフォルトでセレクテッド状態に設定すべきボタンを動的に定める旨を示す。動的に定める場合、再生装置における状態レジスタ（Ｐｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒ（ＰＳＲ））の設定値が優先的に解釈され、ＰＳＲに示されるボタンがセレクテッド状態になる。本フィールドが０ｘＦＦでなければ、デフォルトでセレクテッド状態に設定すべきボタンを静的に定める旨を示す。この場合、『ｄｅｆａｕｌｔ＿ｓｅｌｅｃｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』に規定されたボタン番号でＰＳＲを上書きし、本フィールドで指示されるボタンをセレクテッド状態にする。
【０１１３】
『ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆ』は、ｓｅｌｅｃｔｉｏｎ＿ｔｉｍｅ＿ｏｕｔ＿ｐｔｓに示される時点に達した際、自動的にアクティブ状態に設定されるボタンを示す。
ｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆが”ＦＦ”であれば、所定のタイムアウト時刻において、現在セレクテッド状態になっているボタンが自動的に選択される。このｄｅｆａｕｌｔ＿ａｃｔｉｖａｔｅｄ＿ｂｕｔｔｏｎ＿ｉｄ＿ｒｅｆが００であれば、自動選択はなされない。００，ＦＦ以外の値であれば本フィールドは、有効なボタン番号として解釈される。
【０１１４】
『ｐａｌｌｅｔ＿ｉｄ＿ｒｅｆ』は、Ｐａｇｅ（ｙ）において、ＣＬＵＴ部に設定すべきパレットのｉｄを示す。
『ボタン情報（Ｂｕｔｔｏｎ＿ｉｎｆｏ）』は、Ｐａｇｅ（ｙ）上に表示される各ボタンを定義する情報である。以上のフィールドにより、マルチページメニューにおける個々のページの中身は特定される。
【０１１５】
『Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ』は、ＥｐｏｃｈにおいてＰａｇｅ情報（ｙ）のデータ構造により運搬される中身のバージョンを示すフィールドである。このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは本願の主眼となるものであるので、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒについて詳しく説明する。ページ情報（ｙ）のバージョンとは、ページ情報で運搬されるデータ構造の中身が、何回目のアップデートを経たものであるかを示す。Ｐａｇｅ情報（ｙ）のデータ構造において、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ直後のフィールドのうち、どれかの値が変化した場合、又は、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ直後の各フィールドに何等かの変化があった場合、Ｐａｇｅ情報（ｙ）は、アップデートされたとみなされる。
【０１１６】
Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒによるバージョンは、１つのＥｐｏｃｈにおける通し番号で表現される。そのため、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値は、ページ情報が１つのＥｐｏｃｈにおいてどのＤｉｓｐｌａｙ Ｓｅｔに属するかによって変わる。１つのＥｐｏｃｈにおいてＥｐｏｃｈ Ｓｔａｒｔに属するページ情報では、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは初期値（＝０）に設定される。一方、２つ目以降のＤｉｓｐｌａｙ Ｓｅｔのうち、アップデートをもたらすもの（Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔ、Ｎｏｒｍａｌ Ｃａｓｅ）に属するＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒには、アップデート回数を示す１〜２５５の値が設定される。
【０１１７】
以降図３４の具体例を交えてこのＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒについて詳しく説明する。
図３４は、連続する２つのＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｘ＋１、ＤＳｘ）におけるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒ設定を示す図である。ＤＳｘ＋１はＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔであり、このＤｉｓｐｌａｙ Ｓｅｔの任意のページ情報（ｙ）を着眼する。このＤＳｘ＋１のＰａｇｅ情報（ｙ）の中身が、ＤＳｘと全く同一であれば、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは、ＤＳｘ．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒと同じ値に設定される。このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒを参照することにより再生装置は、ＤＳｘ、ＤＳｘ＋１の間において、Ｐａｇｅ情報（ｙ）の中身から変わっていないと判断することができる。これに対し図３５では、ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）の中身は、ＤＳｘにおけるＰａｇｅ情報（ｙ）のそれから変わっている。この場合、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）のＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒは、ＤＳｘ．Ｐａｇｅ情報（ｙ）の値に１を加えた値（＝Ａ＋１）になっている。かかるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値を参照することで再生装置は、ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）が、ＤＳｘのＰａｇｅ情報（ｙ）から変化していることを知ることができる。
【０１１８】
図３６は、ＤＳｘ．Ｐａｇｅ情報（ｙ）により構成されるページと、ＤＳｘ＋１．Ｐａｇｅ情報（ｙ）により構成されるページとを対比して示す図である。
ＤＳｘ＋１におけるＰａｇｅ情報（ｙ）により構成されるページは、３つのボタン（Ａ，Ｂ，Ｃ）をボタンＢ→ボタンＣ→ボタンＡの順に配置するものである。
一方、ＤＳｘにおけるＰａｇｅ情報（ｙ）により構成されるページは、３つのボタン（ボタンＡ、ボタンＢ、ボタンＣ）を、ボタンＡ→ボタンＢ→ボタンＣの順に配置するものである。２枚のページの違いは、ボタンの順序がボタンＡ→ボタンＢ→ボタンＣからボタンＢ→ボタンＣ→ボタンＡに変化している点に過ぎない。たとえ変化が僅かなものであったとしても、ＤＳｘ＋１のＰａｇｅ情報（ｙ）におけるＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒの値は、ＤＳｘより増えた値になる。Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒをこのように設定しておくことでＰａｇｅ情報（ｙ）における些細な変化を、再生装置にシグナリングすることができる。
【０１１９】
これまでの説明は、Ａｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔＤｉｓｐｌａｙ ＳｅｔにおけるＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎをアップデートする一例であったが、Ｎｏｒｍａｌ Ｃａｓｅに属するＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎにおいても、ページ情報毎にＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが存在する。そしてページ情報毎の内容変化を、このＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒに示させておくことができる。
【０１２０】
第１実施形態同様、先行ＡＶＣｌＩＰと、後続ＡＶＣｌＩＰとの間で３つの条件が満たされている場合は、後続ＡＶＣｌＩＰにおけるＥｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ ＳｅｔをＡｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱うことができる。更にＡｃｑｕｉｓｉｔｉｏｎ ＰｏｉｎｔタイプのＤｉｓｐｌａｙ Ｓｅｔでは、ｐａｇｅ情報毎にＰａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒをインクリメントすることができるので、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔに属するＩＣＳにおいて、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが増えたページ情報があれば、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６に格納されているＩＣＳ内のページ情報のうち、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが増えたページ情報のみを更新することができる。
【０１２１】
以上が本実施形態に係る記録媒体についての改良である。続いて本実施形態に係る再生装置について説明する。上述したようにＩＧストリームは、ＰＧストリーム同様の構成を有しているため、図２４の内部構成をもつ再生装置により、再生を行うことができる。
ＩＧストリーム内に、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔが存在するため、本実施形態に係るＧｒａｐｈｉｃｓコントローラ１７は、図３７のフローチャートに従って処理を行う。本フローチャートは、図２５のフローチャートにおけるＰＣＳという表記を、ＩＣＳという表記に置き換えたものである。この置き換えに加え、ステップＳ２１、ステップＳ２２が追加されている点が新規である。ステップＳ２１は、ステップＳ７−ステップＳ８がどちらもＹｅｓと判定され、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして処理する場合に、実行されるステップである。ステップＳ２１では、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが変化したページ情報が存在するかどうかの判定を行い、もし存在すれば、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６に存在するＩｎｔｅｒａｃｔｉｖｅ＿ｃｏｍｐｏｓｉｔｉｏｎにおけるページ情報のうち、Ｐａｇｅ＿Ｖｅｒｓｉｏｎ＿Ｎｕｍｂｅｒが変化したもののみを、新たなページ情報に置き換える。こうすることで、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅタイプのＤｉｓｐｌａｙ Ｓｅｔを、ページ情報毎にアップデートしてゆくことができる。
【０１２２】
以上のように本実施形態によれば、メニュー表示実現のためのＤｉｓｐｌａｙ Ｓｅｔにおいても、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅという類型があるので、２つのＡＶＣｌｉｐを順次再生しようとする場合でもメニュー表示を途切れないようにすることができる。
（第４実施形態）
本実施形態は、ＢＤ−ＲＯＭの製造工程に関する実施形態である。図３８は、第１実施形態〜第３実施形態に示したＢＤ−ＲＯＭを作成するための製造工程を示す図である。
【０１２３】
ＢＤ−ＲＯＭの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、ＢＤ−ＲＯＭの原盤を作成し、プレス・貼り合わせを行って、ＢＤ−ＲＯＭを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、ＢＤ−ＲＯＭを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１３を含む。
【０１２４】
以降ステップＳ２０４〜ステップＳ２１３について説明する。ステップＳ２０４において制御情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５において、制御情報、パレット定義情報、グラフィクスを機能セグメントに変換する。ステップＳ２０６では、同期したいピクチャが出現するタイミングに基づき、ＩＣＳのＰＴＳを設定する。そしてステップＳ２０７では、ＰＴＳ［ＩＣＳ］の値に基づき、ＤＴＳ［ＯＤＳ］，ＰＴＳ［ＯＤＳ］を設定し、ステップＳ２０８においてＤＴＳ［ＯＤＳ］の値に基づき、ＤＴＳ［ＩＣＳ］，ＰＴＳ［ＰＤＳ］を設定する。
【０１２５】
ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのＤＴＳ、ＰＴＳを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してＡＶＣｌｉｐを得る。以降、ＡＶＣｌｉｐをＢＤ−ＲＯＭのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
【０１２６】
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
【０１２７】
（Ａ）全ての実施形態では、本発明に係る記録媒体をＢＤ−ＲＯＭとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレキシブルＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバブルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
【０１２８】
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムＬＳＩ（集積回路）のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１２９】
（Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムが使用される行為の形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
【０１３０】
（Ｄ）各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１３１】
（Ｅ）ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてＡｌｉｇｎｅｄ Ｕｎｉｔの送信を行ってもよい。つまり送り手側の機器は、Ａｌｉｇｎｅｄ Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
【０１３２】
（Ｆ）各実施形態におけるデジタルストリームは、ＢＤ−ＲＯＭ規格のＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、ｄｔｓ方式であってもよい。
【０１３３】
（Ｇ）各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１３４】
（Ｈ）各実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いている。デコードを実現する装置構成を、字幕−グラフィックスオブジェクト間で共通化する目的で、字幕と同じ圧縮・伸長方式をグラフィックスオブジェクトに採用している。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはＰＮＧデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
【０１３５】
（Ｉ）グラフィックスプレーンクリア及び再描画が垂直帰線期間に完遂するよう、Ｒｃを定めても良い。垂直帰線期間は１／２９．９３秒の２５％と仮定すると、Ｒｃは１Ｇｂｐｓになる。Ｒｃをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Ｒｃ＝２５６Ｍｂｐｓの転送レートであっても、スムーズな表示の実現が可能になる。
【０１３６】
（Ｊ）各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行（ライン）毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
（Ｋ）各実施形態におけるグラフィックスプレーンは、ダブルバッファとして構成することが望ましい。グラフィックスプレーンをダブルバッファで構成すれば数フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯にメニューを表示する場合に有意義である。
【０１３７】
（Ｌ）Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅのＤｉｓｐｌａｙ Ｓｅｔを、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱うには、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていること（第１の条件）、ＤＳｍ＋１に属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒが、１つ前のＤＳｍに属するＰＣＳのＣｏｍｐｏｓｉｔｉｏｎ Ｎｕｍｂｅｒと同じであること（第２の条件）、先行ＡＶＣｌＩＰの再生と、後続ＡＶＣｌＩＰの再生とがシームレス接続されること（第３の条件）という３つの条件があった。このうち、第２の条件又は第３の条件は、必須の条件ではなく、第１の条件が満たされていれば、つまり、ＡＶＣｌｉｐ境界の直後に位置するＤｉｓｐｌａｙ Ｓｅｔ（ＤＳｍ＋１）の類型が、Ｅｐｏｃｈ Ｃｏｎｔｉｎｕｅになっていれば、Ｅｐｏｃｈ ＣｏｎｔｉｎｕｅのＤｉｓｐｌａｙ Ｓｅｔを、Ａｃｑｕｉｓｉｔｉｏｎ Ｐｏｉｎｔとして扱ってもよい。
【産業上の利用可能性】
【０１３８】
本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【符号の説明】
【０１３９】
１００ BD-ROM
２００ 再生装置
３００ リモコン
４００、テレビ
【特許請求の範囲】
【請求項１】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生処理を再生装置に行わせるシステムＬＳＩであって、
前記ビデオストリームをデコードして動画像を得るビデオデコーダと、
前記グラフィクスストリームをデコードすることにより、前記動画像に合成されるべきグラフィクス表示を得るグラフィクスデコーダとを備え、
前記グラフィクスストリームは、状態情報を有し、
前記グラフィクスデコーダは、
複数のメモリと、コントローラとを備え、
前記メモリには、グラフィクス表示のための管理データが存在しており、
前記コントローラは、
2つのデジタルストリームの再生をシームレスに行う場合、後のデジタルストリーム内のグラフィクスストリームに含まれる状態情報が、所定のタイプを示しているか否かの判定を行い、判定結果が肯定的である場合、前記メモリにおける管理データの存在を、そのまま維持する、ことを特徴とするシステムＬＳＩ。
【請求項１】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生処理を再生装置に行わせるシステムＬＳＩであって、
前記ビデオストリームをデコードして動画像を得るビデオデコーダと、
前記グラフィクスストリームをデコードすることにより、前記動画像に合成されるべきグラフィクス表示を得るグラフィクスデコーダとを備え、
前記グラフィクスストリームは、状態情報を有し、
前記グラフィクスデコーダは、
複数のメモリと、コントローラとを備え、
前記メモリには、グラフィクス表示のための管理データが存在しており、
前記コントローラは、
2つのデジタルストリームの再生をシームレスに行う場合、後のデジタルストリーム内のグラフィクスストリームに含まれる状態情報が、所定のタイプを示しているか否かの判定を行い、判定結果が肯定的である場合、前記メモリにおける管理データの存在を、そのまま維持する、ことを特徴とするシステムＬＳＩ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【公開番号】特開２００９−２８３１２４（Ｐ２００９−２８３１２４Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００９−１７７２１６（Ｐ２００９−１７７２１６）
【出願日】平成２１年７月３０日（２００９．７．３０）
【分割の表示】特願２００５−５１８０５６（Ｐ２００５−５１８０５６）の分割
【原出願日】平成１７年２月１７日（２００５．２．１７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願日】平成２１年７月３０日（２００９．７．３０）
【分割の表示】特願２００５−５１８０５６（Ｐ２００５−５１８０５６）の分割
【原出願日】平成１７年２月１７日（２００５．２．１７）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]