グラフィクスデータと、矩形領域を示すウインドウ定義情報と、を含むグラフィクスストリームを記憶媒体から読み取る、読み取り手段と、前記グラフィクスデータをデコードする、プロセッサと、前記デコードされたグラフィクスデータを記憶する、オブジェクトバッファと、プレーンメモリと、前記オブジェクトバッファに記憶されているデコードされたグラフィクスデータを、前記プレーンメモリで描画し、前記矩形領域が前記プレーンメモリの一部を示す場合には、前記オブジェクトバッファに記憶されているデコードされたグラフィクスデータを前記矩形領域内で描画処理し、前記矩形領域外では描画処理しない、コントローラと、を備え、前記矩形領域の位置とサイズは、Epochの先頭で指定され、前記矩形領域は、前記Epochで固定されており、前記Epochは、前記オブジェクトバッファ及び前記プレーンメモリがクリアされてから再度クリアされるまでの期間である、ことを特徴とする集積回路。ところで従来のETSIEN300743標準規格には、グラフィックスプレーンに対する書き込み負荷が大きい場合に、グラフィクスの表示と、ピクチャの表示との同期をどのように保証するかという考えが全くなかった。グラフィックスプレーンには、非圧縮状態のグラフィクスが書き込まれるので、グラフィクスの解像度が高ければ高い程、書き込み負荷が大きくなる。例えば、BDROMが予定しているグラフィクスを描画しようとすると、グラフィックスプレーンに書き込むべきグラフィクスのサイズは最大2Mバイトになる。このような、多大なサイズをもつグラフィクスを、ピクチャの表示と同期させるには、グラフィックスプレーンへの書き込みに多大なバンド幅が必要となる。しかしグラフィックスプレーンへの書き込みに、高いバンド幅を要求することは、再生装置の低コスト化の妨げになる。仮に再生装置が常に合理的な書き込みを行うなら、グラフィックスプレーン書き込み時のバンド幅を低下させることができる。ここで合理的な書き込みとは、前回の表示内容との差分のみ、グラフィックスプレーンに書き込んでゆくという書き込みをいう。しかし、再生装置に常に合理的書き込み手法を要求するのも、ソフトウェアの実装の自由度を奪う結果になる。このように、グラフィックスプレーンへの書き込み負荷が多大であると、高いバンド幅での動作や、合理的な手法での書き込みを再生装置に強いることになり、再生装置の製品開発を著しく阻害することになる。本発明の目的は、グラフィックスプレーンに書き込むべきデータ量が多大であっても、ピクチャの表示と同期したグラフィクスのアップデートを実現することができる集積回路を提供することである。上記目的を達成するため、本発明に係る集積回路は、グラフィクスデータと、矩形領域を示すウインドウ定義情報と、を含むグラフィクスストリームを記憶媒体から読み取る、読み取り手段と、前記グラフィクスデータをデコードする、プロセッサと、前記デコードされたグラフィクスデータを記憶する、オブジェクトバッファと、プレーンメモリと、前記オブジェクトバッファに記憶されているデコードされたグラフィクスデータを、前記プレーンメモリで描画し、前記矩形領域が前記プレーンメモリの一部を示す場合には、前記オブジェクトバッファに記憶されているデコードされたグラフィクスデータを前記矩形領域内で描画処理し、前記矩形領域外では描画処理しない、コントローラと、を備え、前記矩形領域の位置とサイズは、Epochの先頭で指定され、前記矩形領域は、前記Epochで固定されており、前記Epochは、前記オブジェクトバッファ及び前記プレーンメモリがクリアされてから再度クリアされるまでの期間である、ことを特徴としている。ピクチャに対応する平面の一部をグラフィクスの表示のためのウィンドゥとして指定するので、集積回路におけるコントローラは、プレーン全体のグラフィクス描画を行う必要はない。ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。表示用の平面のうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、オーサリングを行う制作者は、あらゆる再生装置での同期保証を実現することができる。またウィンドゥ情報によりウィンドゥの位置や大きさを規定できるので、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。ピクチャ内の絵柄の邪魔にならないように、グラフィクスを表示させることができるので、ピクチャの絵柄に時間的な変動があっても、グラフィクスの見易すさを維持することができる。これにより映画作品の品質を高めることができる。ここでワーストケースでのアップデートとは、全クリア再描画という最も効率が悪い処理でグラフィックスがアップデートされることをいう。ワーストケースを想定して、ウィンドゥの大きさを決める場合、前記ウィンドゥの縦幅、横幅は、ピクチャに対応する平面の1xの大きさになるように定め、xは、ウィンドゥのアップデートレートと、ピクチャの表示レートとの比率に基づく実数とすることが望ましい。このようにウィンドゥの大きさを定めれば、再生装置において、グラフィックスプレーンへの書き込みに必要なバンド幅は、ある決まった値になる。ミニマムスタンダードとして、このバンド幅を満たすよう、再生装置を構成すれば、ソフトウェアの実装がどのようなものであっても、ピクチャとの同期を実現することができる。このように再生装置構成のためのミニマムスタンダードを提供することができるので、かかる転送レートというミニマムスタンダードさえ満たせば、その他の実装は、開発者が自由に定めることができるので、再生装置の開発にあたっての自由度が高まる。以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図1は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図1において、本発明に係る記録媒体は、BDROM100である。このBDROM100は、再生装置200、テレビ300、リモコン400により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。以上が本発明に係る記録媒体の使用形態についての説明である。続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、BDROMの応用層に対する改良により実施することができる。図2は、BDROMの構成を示す図である。本図の第4段目にBDROMを示し、第3段目にBDROM上のトラックを示す。本図のトラックは、BDROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBDROMの応用層フォーマットを表現すると、図中の第1段目のようになる。本図に示すようにBDROMには、ROOTディレクトリの下にBDMVディレクトリがあり、BDMVディレクトリの配下には、AVClipを格納したファイル、AVClipの管理情報を格納したファイルAVClipにおける論理的な再生経路を定義したファイルが存在する。本図に示すようなアプリケーションフォーマットを作成することにより、本発明に係る記録媒体は生産される。尚、XXXM2TS、XXXCLPIYYYMPLSといったファイルが、それぞれ複数存在する場合は、BDMVディレクトリの配下に、STREAMディレクトリ、CLIPINFディレクトリ、PLAYLISTディレクトリという3つのディレクトリを設け、STREAMディレクトリにXXXM2TSと同じ種別のファイルを、CLIPINFディレクトリにXXXCLPIと同じ種別のファイルを、PLAYLISTディレクトリにYYYMPLSと同じ種別のファイルを格納することが望ましい。このアプリケーションフォーマットにおけるAVClipについて説明する。AVClipは、MPEGTS形式のデジタルストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、プレゼンテーショングラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、プレゼンテーショングラフィクスストリームは、映画の字幕をそれぞれ示している。図3は、AVClipがどのように構成されているかを模式的に示す図である。AVClipは、複数のビデオフレームからなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを、PESパケット列に変換し、更にTSパケットに変換し、同じくプレゼンテーショングラフィクスストリームを、PESパケット列に変換し、更にTSパケットに変換して、これらを多重化することで構成される。本図において多重されるプレゼンテーショングラフィクスストリームは1つであるが、BDROMが多言語対応型である場合、その言語毎のプレゼンテーショングラフィクスストリームがAVClipに多重される。かかる過程を経て生成されたAVClipは、通常のコンピュータファイル同様、複数のエクステントに分割され、BDROM上の領域に記録される。続いてプレゼンテーショングラフィクスストリームについて説明する。図4aは、プレゼンテーショングラフィクスストリームの構成を示す図である。第1段目は、AVClipを構成するTSパケット列を示す。第2段目は、グラフィクスストリームを構成するPESパケット列を示す。第2段目におけるPESパケット列は、第1段目におけるTSパケットのうち、所定のPIDをもつTSパケットからペイロードを取り出して、連結することにより構成される。第3段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、PCS、PDS、ODS、ENDと呼ばれる機能セグメントからなる。これらの機能セグメントのうち、PCSは、画面構成セグメントと呼ばれ、WDSPDSODSENDは定義セグメントと呼ばれる。PESパケットと機能セグメントとの対応関係は、1対1の関係、1対多の関係である。つまり機能セグメントは、1つのPESパケットに変換されてBDROMに記録されるか、又は、フラグメント化され、複数PESパケットに変換されてBDROMに記録される。図4bは、機能セグメントを変換することで得られるPESパケットを示す図である。図4bに示すようにPESパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するDTS、PTSが存在する。尚以降の説明では、機能セグメントが格納されるPESパケットのヘッダ内に存在するDTS及びPTSを、機能セグメントのDTS及びPTSとして扱う。これら様々な種別の機能セグメントは、図5のような論理構造を構築する。図5は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第3段目に機能セグメントを、第2段目にDisplaySetを、第1段目にEpochをそれぞれ示す。第2段目のDisplaySetとは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線は、第3段目の機能セグメントが、どのDSに帰属しているかという帰属関係を示す。PCSWDSPDSODSENDという一連の機能セグメントが、1つのDSを構成していることがわかる。再生装置は、このDSを構成する複数機能セグメントをBDROMから読み出せば、一画面分のグラフィクスを構成することができる。第1段目のEpochとは、AVClipの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のクラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このEpochにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう。この矩形領域の縦横の大きさ及び位置は、Epochにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりEpochは、映像-グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなEpochにせねばならない。この場合、2つのEpochの境界では、映像-グラフィクスの同期は保証されない。Epochにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Epochということができる。図6は、字幕の表示位置と、Epochとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり5つの字幕本当はウソだったあなたがずっとすきだったのうち、3つの字幕本当はウソだったあなたがは画面の下側に、ずっとすきだったは画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、AVClipの再生時間軸において、下側の余白に字幕が出現している期間が1つのEpoch1、上側の余白に字幕が出現している期間が別のEpoch2になる。これら2つのEpochは、それぞれ独自の字幕の描画領域をもつことになる。Epoch1では、画面の下側の余白が字幕の描画領域になる。一方Epoch2では、画面の上側の余白が字幕の描画領域になる。これらのEpoch12において、バッファプレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がEpochについての説明である。続いてDisplaySetについて説明する。図5における破線hk12は、第2段目の機能セグメントが、どのEpochに帰属しているかという帰属関係を示す。EpochStartAcquisitionPointNormalCaseという一連のDSは、第1段目のEpochを構成していることがわかる。EpochStart、AcquisitionPoint、NormalCaseは、DSの類型である。本図におけるAcquisitionPoint、NormalCaseの順序は、一例にすぎず、どちらが先であってもよい。EpochStartは、新表示という表示効果をもたらすDSであり、新たなEpochの開始を示す。そのためEpochStartは、次の画面合成に必要な全ての機能セグメントを含んでいる。EpochStartは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。AcquisitionPointは、表示リフレッシュという表示効果をもたらすDisplaySetであり、先行するEpochStartと全く同じDisplaySetをいう。AcquisitionPointたるDSは、Epochの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、AcquisitionPointたるDSから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりAcquisitionPointたるDSは、Epochの途中からの画面構成を可能するという役割をもつ。AcquisitionPointたるDisplaySetは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、10分単位、10秒単位というように、大まかな単位でなされるので、10分間隔の再生位置、10秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にAcquisitionPointを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。NormalCaseは、表示アップデートという表示効果をもたらすDSであり、前の画面合成からの差分のみを含む。例えば、あるDSvの字幕は、先行するDSuと同じ内容であるが、画面構成が、この先行するDSuとは異なる場合、PCSのみのDSv、又は、PCSのみのDSvを設けてこのDSvをNormalCaseのDSにする。こうすれば、重複するODSを設ける必要はなくなるので、BDROMにおける容量削減に寄与することができる。一方、NormalCaseのDSは、差分にすぎないので、NormalCase単独では画面構成は行えない。続いてDefinitionSegmentについて説明する。ObjectDefinitionSegmentは、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。BDROMに記録されているAVClipは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、1920×1080画素という高精細な大きさに設定されている。1920×1080という解像度があるので、BDROMでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。画素の色にあたっては、一画素当たりのインデックス値青色差成分輝度成分Y値透明度のビット長が8ビットになっており、これによりフルカラーの16777216色から任意の256色を選んで画素の色として設定することができる。グラフィクスオブジェクトによる字幕は、透明色の背景に、文字列を配置することで描画される。ODSによるグラフィクスオブジェクトの定義は、図7aに示すようなデータ構造をもってなされる。ODSは、図7aに示すように自身がODSであることを示すsegmenttypeと、ODSのデータ長を示すsegmentlengthと、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別するobjectidと、EpochにおけるODSのバージョンを示すobjectversionnumberと、lastinsequenceflagと、グラフィクスオブジェクトの一部又は全部である連続バイト長データobjectdatafragmentとからなる。objectidは、EpochにおいてこのODSに対応するグラフィクスオブジェクトを一意に識別する。グラフィクスストリームのEpochには、同じIDをもつODSが複数含まれる。同じIDをもつ複数のODSは縦横のサイズが同じであり、オブジェクトバッファの共通の領域が割り当てられる。同じIDをもつ複数ODSのうち1つが、この領域に読み出されれば、オブジェクトバッファにおけるODSは、同じIDをもつ後続のODSにより上書きされる。このように、ビデオストリームの再生進行に伴い、オブジェクトバッファ上のODSが、同じ識別子をもつ後続のODSにて上書きされることにより、ODSにおける絵柄は、時間的な変遷を遂げる。同じIDをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、1つのEpoch内の制限に過ぎない。あるEpochに属するグラフィクスオブジェクトと、次のEpochに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。lastinsequenceflag、objectdatafragmentについて説明する。PESパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが1つのODSでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた1部分がobjectdatafragmentに設定される。1つのグラフィクスオブジェクトを複数ODSで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したODSは、DSにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、lastsequenceflagをもつODSにより指示される。上述したODSのデータ構造は、前のPESパケットからフラグメントを詰めてゆく格納法を前提にしているが、各PESパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がODSの説明である。PaletteDifinitionSegmentは、色変換用のパレットを定義する情報である。PDSのデータ構造を図7bに示す。図7bに示すようにPDSは、自身がPDSであることを示すsegmenttype、PDSのデータ長を示すsegmentlength、このPDSに含まれるパレットを一意に識別するpalletid、EpochにおけるEpochのPDSのバージョンを示すpalletversionnumber、各エントリーについての情報palletentryからなる。palletentryは、各エントリーにおける赤色差成分青色差成分輝度成分Y値透明度を示す。続いてWDSについて説明する。windowdefinitionsegmentは、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Epochでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域はwindowと呼ばれ、このWDSで定義される。図8aは、WDSのデータ構造を示す図である。本図に示すようにWDSは、グラフィックスプレーンにおいてウィンドゥを一意に識別するwindowidと、グラフィックスプレーンにおける左上画素の水平位置を示すwindowhorizontalpositionと、グラフィックスプレーンにおける左上画素の垂直位置を示すwindowverticalpositionと、グラフィックスプレーンにおけるウィンドゥの横幅を示すwindowwidthと、グラフィックスプレーンにおける縦幅を示すwindowheightとを用いて表現される。windowhorizontalposition、windowverticalposition、windowwidth、windowheightがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンの内部領域においてウィンドゥは、縦videoheight、横videowidthという二次元状の大きさをもつ。windowhorizontalpositionは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、0~videowidth1の値をとり、windowverticalpositionは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので0~videoheight1の値をとる。windowwidthは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、0~videowidthwindowhorizontalposition1の値をとり、windowheightは、グラフィックスプレーンにおける縦幅であるので0~videoheightwindowverticalposition1の値をとる。WDSのwindowhorizontalposition、windowverticalposition、windowwidth、windowheightにより、グラフィックプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをEpoch毎に規定することができる。そのため、あるEpochに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。WDSはEpoch毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。続いてENDofDisplaySetSegmentについて説明する。ENDofDisplaySetSegmentは、DisplaySetの伝送の終わりを示す指標であり、DisplaySetにおける機能セグメントのうち、最後のODSの直後に配置される。このENDofDisplaySetSegmentの内部構成は、自身がENDofDisplaySetSegmentであることを示すsegmenttypeと、当該機能セグメントのデータ長を示すsegmentlengthとからなり、これといって説明が必要な構成要素はない。故に図示は省略する。以上がODS、PDS、WDS、ENDについての説明である。続いてPCSについて説明する。PCSは、対話的な画面を構成する機能セグメントである。PCSは、図8bに示すデータ構造で構成される。本図に示すようにPCSは、segmenttypeと、segmentlengthと、compositionnumberと、compositionstateと、palletupdateflagと、palletidと、window情報~とから構成される。compositionnumberは、0から15までの数値を用いてDisplaySetにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Epochの先頭から本PCSまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでcompositionnumberは設定される。compositionstateは、本PCSから始まるDisplaySetが、NormalCaseであるか、ACquisitionPointであるか、EpochStartであるかを示す。palletupdateflagは、本PCSにおいてPalletOnlyDispleyUpdateがなされているかどうかを示す。PalletOnlyDispleyUpdateとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本PCSでかかるアップデートがなされれば、本フィールドは1に設定される。palletidは、PalletOnlyDispleyUpdateに用いられるべきパレットを示す。window情報は、このPCSが属するDisplaySet内の、個々のウィンドゥをどのように制御するかを示す情報である。図8bの破線wd1は、任意のwindow情報の内部構成をクローズアップしている。この破線wd1に示すように、window情報は、objectid、windowid、objectcroppedflag、objecthorizontalposition、objectverticalposition、croppingrectangle情報からなる。objectidは、window情報に対応するウィンドゥ内に存在するODSの識別子を示す。windowidは、本PCSにおいて、グラフィクスオブジェクトに割り当てられるべきウィンドゥを示す。1つのウィンドゥには最大2つのグラフィクスオブジェクトが割り当てられる。objectcroppedflagは、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。1と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、0と設定された場合、グラフィクスオブジェクトは非表示となる。objecthorizontalpositionは、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。objectverticalpositionは、グラフィックスプレーンにおける左上画素の垂直位置を示す。croppingrectangle情報は、objectcroppedflagが1に設定されている場合に有効となる情報要素である。破線wd2は、任意のcroppingrectangle情報の内部構成をクローズアップしている。この破線に示すようにcroppingrectangle情報は、objectcroppinghorizontalposition、objectcroppingverticaladdress、objectcroppingwidth、objectcroppingheightからなる。objectcroppinghorizontalpositionは、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ETSIEN300743標準規格におけるRegionに相当する。objectcroppingverticaladdressは、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。objectcroppingwidthは、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。objectcroppingheightは、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。以上がPCSのデータ構造である。続いてPCSの具体的な記述について説明する。この具体例は、図6に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みでほんとはウソだったあなたがというように徐々に表示させるというものである。図9は、かかる字幕表示を実現するための記述例である。本図におけるEpochは、DS1、DS2、DS3を有する。DS1は、字幕の表示枠となるwindowを定義するWDS、台詞ほんとはウソだったあなたがを表すODS、1つ目のPCSを備える。DS2は、2つ目のPCSを有する。DS3は3つ目のPCSを有する。次に個々のPCSをどのように記述するかについて説明する。DisplaySetに属するWDS、PCSの記述例を図10~図12に示す。図10は、DS1におけるPCSの記述例を示す図である。図10において、WDSのwindowhorizontalposition、windowverticalpositionは、グラフィックスプレーンにおけるウィンドゥの左上座標LP1を、windowwidthwindowheightは、ウィンドゥの表示枠の横幅、縦幅を示す。図10におけるクロップ情報のobjectcroppinghorizontalpositionobjectcroppingverticalpositionは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ST1を示している。そして基準点からobjectcroppingwidth、objectcroppingheightに示される範囲がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてobjecthorizontalpositionobjectverticalpositionを基準点とした破線の範囲cp1に配置される。こうすることにより、本当はがグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕本当はは動画像と合成され表示される。図11は、DS2におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図10と同じなので説明を省略する。クロップ情報の記述は、図10と異なる。図11におけるクロップ情報のobjectcroppinghorizontalpositionobjectcroppingverticalpositionは、オブジェクトバッファ上の字幕本当はウソだった。あなたがのうち、ウソだったの左上座標を示し、objectcroppingheightobjectcroppingwidthは、ウソだったの横幅、縦幅を示す。こうすることにより、ウソだったがグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕ウソだったは動画像と合成され表示される。図12は、DS3におけるPCSの記述例を示す図である。本図におけるWDSの記述は、図10と同じなので説明を省略する。クロップ情報の記述は、図10と異なる。図12におけるクロップ情報のobjectcroppinghorizontalpositionobjectcroppingverticalpositionは、オブジェクトバッファ上の字幕本当はウソだった。あなたがのうち、あなたがの左上座標を示し、objectcroppingheightobjectcroppingwidthは、あなたがの横幅、縦幅を示す。こうすることにより、あなたががグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕あなたがは動画像と合成され表示される。DS123のPCSを以上のように記述することで、字幕の表示効果を実現することができる。その他の表示効果を実現するにあたっての、PCSの記述作法について説明する。先ず初めにCutInOutの記述作法について説明する。図13は、時間軸に沿った連続写真的な表記で、CutInOutを実行する際のDisplaySetの記述例を示す図である。本図におけるwindowにおけるxyは、windowverticalposition、windowhorizontalpositionの値であり、uvは、windowwidth、windowheightの値を示す。また本図のCroppingRectangleにおけるabは、objectcroppingverticalposition、objectcroppinghorizontalpositionの値であり、cdはobjectcroppingwidth、objectcroppingheightの値である。本図の再生時間軸の時点t11t12t13には、DS11DS12DS13が存在している。時点t11に存在するDS11は、CompositionStateがEpochStartに設定され、ObjectCroppedFlagが0に設定されたPCS0、グラフィックスプレーンのの位置に、横700×縦500のwindowを宣言するWDS0、PDS0、字幕Creditを表すODS0、ENDを有する。時点t12に存在しているDS12は、CompositionStateがNormalCaseであり、オブジェクトバッファのから横600×縦400の範囲でクロップを行い、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標に配置するという手順を示すPCS1を含む。時点t13に存在しているDS13は、CompositionStateがNormalCaseであり、クロップされたグラフィクスオブジェクトを消すよう、objectcroppedflagが0に設定されたPCS2を含む。以上のDisplaySetにより、t11では字幕Creditは非表示になっているが、t12で表示され、t13で再び非表示になる。これによりCutInCutOutという表示効果が実現される。続いてFadeInOutという表示効果を実現する際の、DisplaySetの記述作法について説明する。図14は、時間軸に沿った連続写真的な表記で、FadeInOutを実行する際のDisplaySetの記述例を示す図である。本図の時点t21t22t23t24には、DS21DS22DS23DS24が存在している。時点t21に存在するDS21は、CompositionStateがEpochStartに設定され、オブジェクトバッファのから横600×縦400の範囲でクロップを行い、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標に配置するという手順を示すPCS0、グラフィックスプレーンのの位置に、横700×縦500のwindowを宣言するWDS0、PDS0、字幕Finを表すODS0、ENDを有する。時点t22に存在しているDS22は、CompositionStateがNormalCaseであるPCS1と、PDS1とを含む。このPDS1は、PDS0と同じ色彩の赤色差、青色差を示しておりながら、高い輝度値をもっているものとする。時点t23に存在しているDS23は、CompositionStateがNormalCaseであるPCS3とPDS2とENDとを含む。このPDS2は、PDS0と同じ色彩の赤色差、青色差を示しておりながら、低い輝度値をもっているものとする。時点t24に存在するDS24は、CompositionStateがNormalCaseに設定され、ObjectCroppedFlagが0に設定されたPCS、ENDを有する。これら一連のDisplaySetは、1つ前のDisplaySetと異なるPDSを指定しているため、Epoch内の複数PCSにおいて表示されるグラフィクスオブジェクトは、徐々に輝度値が高められたり、弱められることになる。これによりFadeInOutという表示効果の実現が可能になる。続いてScrollingの記述作法について説明する。図15は、時間軸に沿った連続写真的な表記で、Scrollingがどのように行われるかを記述した図である。本図における表記は、図13の一例に準ずる。AVClip再生時間軸の時点t31に存在するDS31は、CompositionStateがEpochStartに設定され、ObjectCroppedFlagが0に設定されたPCS0、グラフィックスプレーンのの位置に、横700×縦500のwindowを宣言するWDS0、PDS0、字幕CreditCompanyを表すODS0、ENDを有する。時点t32に存在するDS32は、CompositionStateがNormalCaseであり、オブジェクトバッファにおけるから横600×縦400の範囲でクロップを行い、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標に配置するという手順を示すPCS1を含む。オブジェクトバッファにおいてから横600×縦400の範囲には、CreditCompanyという2段表記の字幕のうちCreditが存在するので、このCreditがグラフィックスプレーンに出現することになる。時点t33に存在するDS33は、CompositionStateがNormalCaseであり、オブジェクトバッファ上の座標から横600×縦400の範囲を切り出し、ウィンドゥにおける座標に配置するという手順を示すPCS2を含む。オブジェクトバッファ上の座標から横600×縦400の範囲には、CreditCompanyという2段表記の字幕のうち、Creditの下半分と、Companyの上半分とが存在するので、これらの部分がグラフィックスプレーンに出現することになる。時点t34に存在するDS34は、CompositionStateがNormalCaseであり、オブジェクトバッファの座標から横600×縦400の範囲を切り出し、ウィンドゥにおける座標に配置するという手順を示すPCS3を含む。オブジェクトバッファ上の座標から横600×縦400の範囲には、CreditCompanyという2段表記の字幕のうち、Companyが存在するので、2段表記の字幕のうちCompanyの部分が画面上に現れることになる。以上のPCSの記述により、CreditCompanyという2段表記の字幕の下スクロールがなされることになる。続いてWipeInOutの記述作法について説明する。図16は、時間軸に沿った連続写真的な表記で、WipeInOutがどのように行われるかを記述した図である。本図における表記は、図13の一例に準ずる。本図の時点t51に存在するDS51は、CompositionStateがEpochStartに設定され、ObjectCroppedFlagが0に設定されたPCS0、グラフィックスプレーンのの位置に、横700×縦500のwindowを宣言するWDS0、PDS0、字幕Finを表すODS0、ENDを有する。時点t52に存在するDS52は、CompositionStateがNormalCaseであり、オブジェクトバッファのから横600×縦400の範囲でクロップを行い、クロップされたグラフィクスオブジェクトをグラフィックスプレーンの座標に配置するという手順を示すPCS1を含む。から横600縦400の範囲には、Finという字幕が存在するので、このFinがグラフィックスプレーンに出現することになる。時点t53に存在するDS53は、CompositionStateがNormalCaseであり、オブジェクトバッファにおけるから縦400×横400の範囲でクロップを行い、座標を基準にして、表示を行わせるPCS2を含む。そうすると、~が表示範囲内になり、~は、非表示範囲になる。時点t54に存在するDS54は、CompositionStateがNormalCaseであり、オブジェクトバッファにおけるグラフィクスオブジェクトのから横200×縦400の範囲でクロップを行い、座標を基準にして、ウィンドゥの表示を行わせるPCS3を含む。そうすると、~は、非表示範囲になる。グラフィックスプレーンの非表示範囲が広がるに伴い、表示範囲が狭まるのでWipeInOutが実現されることになる。このようにPCSの記述次第でCutInOutFadeInOutWipeInOutScrollというような多様な表示効果を実現することができるので、字幕描画に様々な工夫を凝らすことができる。かかる表示効果実現にあたっての制約について説明する。図13~図16の表示効果のうち、Scrollingの実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。図15のt32-t33間で考えれば、Scrollingの実現のためには、t32におけるCreditなるグラフィクスオブジェクトをグラフィックスプレーンから消し去るというウィンドゥクリアと、Creditの下半分、Companyの上半分をグラフィックスプレーンに書き込むというウィンドゥ再描画とをt32-t33の時間間隔で実現せねばならない。この時間間隔がビデオフレームの時間間隔である場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ-グラフィックスプレーン間の転送レートをRcとすると、ワーストケースでは、この転送レートRcでウィンドゥクリアと、ウィンドゥ再描画とを行わねばならない。そうするとウィンドゥクリア、ウィンドゥ再描画のそれぞれをRcの半分の転送レートで実現せねばならない。これらウィンドゥクリア-ウィンドゥ再描画をビデオフレームと同期させるには、ウィンドゥサイズ×フレームレート≒Rc2を満たす必要がある。このフレームレートが2997であるなら、Rcは、ウィンドゥサイズ×2×2997になる。字幕の表示にあたっては、グラフィックスプレーン全体に対し、最低でも25~33程度の大きさが必要となる。ここでグラフィックスプレーンの総画素数は1920×1080であり、一画素当たりのインデックスのビット長を8ビットとすると、グラフィックスプレーンの総容量は2Mバイトになる。この総容量の14をウィンドゥサイズとすると、500kバイトになる。これを上述した式に代入してRcを導けば、Rcは256Mbpsと算出することができる。この25~33という大きさであれば、256Mbpsという転送レートで字幕の表示を行っている限り、如何なる表示効果を実現する場合であっても、動画との同期を維持することができる。仮に、ウィンドゥクリア及び再描画のレートがビデオフレームのフレームレートの1214でよいなら、Rcがたとえ同じであってもウィンドゥサイズを2倍4倍にすることができる。以上がwindowの大きさについての説明である。続いて、windowの位置、範囲について説明する。上述したように、Epochにおいてウィンドゥの位置、範囲は一貫している。Epochにおいてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。図17は、ウィンドゥ内にグラフィクスオブジェクトが4つ存在する場合と、2つの存在する場合とを対比して示す図である。グラフィクスオブジェクトが4つ存在する場合、エッジの数は8つになるのでグラフィクスオブジェクトが2つ存在する場合と比べると、エッジの数は2倍になっている。ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が2つまでであると、最悪4つのオーバーヘッドが発生すると見込んで転送レートを設定すればよいので、ミニマムスタンダードたる転送レートを数値化し易くなる。以上がウィンドゥについての説明である。続いてこれらPCS、ODSを有したDisplaySetが、AVClipの再生時間軸上にどのように割り当てられるかについて説明する。Epochは、再生時間軸上においてメモリ管理が連続する期間であり、Epochは1つ以上のDisplaySetから構成されるので、DisplaySetをどうやってAVClipの再生時間軸に割り当てるかが問題になる。ここでAVClipの再生時間軸とは、AVClipに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するための想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、90KHzの時間精度で表現される。DisplaySet内のPCS、ODSに付加されたDTS、PTSは、この再生時間軸において同期制御を実現すべきタイミングを示す。このPCS、ODSに付加されたDTS、PTSを用いて同期制御を行うことが、再生時間軸へのDisplaySetの割り当てである。先ず、ODSに付加されたDTS、PTSにより、どのような同期制御がなされるかについて説明する。DTSは、ODSのデコードを開始すべき時間を90KHzの時間精度で示しており、PTSはデコード終了時刻を示す。ODSのデコードは、瞬時には完了せず、時間的な長さをもっている。このデコード期間の開始点終了点を明らかにしたいとの要望から、ODSについてのDTS、PTSはデコード開始時刻、デコード終了時刻を示している。PTSの値はデッドラインであるので、PTSに示される時刻までにODSのデコードがなされて、非圧縮状態のグラフィックオブジェクトが、再生装置上のオブジェクトバッファに得られなければならない。DSnに属する任意のODSjのデコード開始時刻は、90KHzの時間精度でDTSに示されるので、これにデコードを要する最長時間を加えた時刻が、DisplaySetのODSjのデコード終了時刻になる。ODSjのサイズをSIZE、ODSのデコードレートをRdとすると、デコードに要する最長時間は、SIZERdになる。ここでは、小数点以下切り上げの割り算を示す演算子である。この最長時間を90KHzの時間精度に変換し、ODSjのDTSに加算することにより、PTSで示されるべきデコード終了時刻は算出される。DSnに属するODSjのPTSを、数式で表すと、以下の式のようになる。PTSDTS90000×Rdそして互いに隣接する2つのODSとの間では、以下の関係を満たす必要がある。PTS≦DTS続いてPCSのDTS、PTSの設定について説明する。PCSは、DSnにおける最初のODSのデコード開始時点以前、及び、DSnにおける最初のPDSが有効になる時点以前に、再生装置上のバッファにロードされねばならない。よって以下の式の関係を満たす値に、設定されねばならない。DTS≦DTSDTS≦PTSそしてDSnにおけるPCSのPTSは、以下の数式から算出される。PTS≧DTSdecodedurationここでdecodedurationは、PCSのアップデートに用いられる全グラフィクスオブジェクトのデコード時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本DSnPCSnの画面合成に用いられるオブジェクトをDSnPCSnOBJjとした場合、decodedurationは、ウィンドゥクリアに要する時間、DSnPCSnOBJのデコード期間、DSnPCSnOBJの書き込みに要する時間により変動を受ける値になる。RdRcさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からPTSを計算している。decodedurationの計算は、図18のプログラムに基づき行われる。また図19、図20abは、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらdecodedurationの算出について説明する。図19のフローチャートにおいて、先ず初めに、PLANEINITIALIZATINTIME関数を呼び出し、戻り値をdecodedurationに加算する。PLANEINITIALIZATINTIME関数は、DisplaySetを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図19のステップS1では、DSnDSnPCSOBJ0decodedurtationを引数に設定して、この関数を呼び出す。続いて図20aを参照しながらPLANEINITIALIZATINTIME関数について説明する。図20aにおいてinitializedurationとは、PLANEINITIALIZATINTIME関数の戻り値を示す変数である。図20のステップS2は、DSnのPCSにおけるcompositionstateがEpochStartかどうかにより、処理を切り換えるif文である。もしcompositionstateがEpochStartであるなら、グラフィックスプレーンのクリアに要する時間をinitializedurationに設定する。オブジェクトバッファ-グラフィックスプレーン間の転送レートRcを上述したように256000000とし、グラフィックスプレーンの総サイズをvideowidthvideoheightとすると、クリアに要する時間は、videowidthvideoheight256000000になる。これに、90000Hzを乗じPTSの時間精度で表現すれば、グラフィックスプレーンのクリアに要する時間は90000×videowidthvideoheight256000000になる。この時間を、initializedurationに加えて、initializedurationを戻り値としてリターンする。もしcompositionstateがEpochStartでないなら、WDSにて定義されるwindowiのクリアに要する時間をinitializedurationに加えるという処理を全てのwindowについて繰り返す。オブジェクトバッファ-グラフィックスプレーン間の転送レートRcを上述したように256000000とし、WDSに属するウィンドゥiの総サイズをΣSIZEとすると、クリアに要する時間は、ΣSIZE256000000になる。これに、90000Hzを乗じPTSの時間精度で表現すれば、WDSに属する全ウィンドゥのクリアに要する時間は90000×ΣSIZE256000000になる。この時間を、initializedurationに加えて、initializedurationを戻り値としてリターンする。以上がPLANEINITIALIZATINTIME関数である。図19のステップS5は、DSnに属するグラフィクスオブジェクトの数が2であるか、1であるかで処理を切り換えるものでありif、もし1であるなら、グラフィクスオブジェクトのデコードを行うための待ち時間をdecodedurationに加える。この待ち時間の算出は、WAIT関数の呼出で実現される。この関数呼出にあたっての引数はDSnDSnPCSOBJ0decodedurationであり、待ち時間を示すwaitdurationが戻り値として返される。図20bは、WAIT関数の処理手順を示すフローチャートである。このWAIT関数においてcurrentdurationとは、呼出元のdecodedurationが設定される。objectdefinereadytimeは、DisplaySetのグラフィクスオブジェクトiのPTSが設定される変数である。currenttimeとは、DSnのPCSのDTSに、currentdurationを足した値が設定される変数である。このcurrenttimeよりobjectdefinereadytimeが大きい場合、戻り値たるwaitdurationは、objectdefinereadytimeとcurrenttimeとの差分が設定されることになる。以上がWait関数である。ステップS6においてdecodedurationには、このwait関数の戻り値と、window再描画に必要な時間を足し合わせた時間256000000が設定されることになる。以上はDSnのグラフィクスオブジェクトが1つである場合の処理である。図19のステップS5は、グラフィクスオブジェクトの数が2であるかどうかを判定している。DSnのグラフィクスオブジェクトが2以上であれば、PCSにおけるOBJ0を引数として、wait関数を呼び出し、その戻り値をdecodedurationに加算する。続くステップS11は、DSnのOBJ0が属するwindowが、グラフィクスオブジェクト1が属するwindowと同一かどうかの判定であり、もし同一であるなら、OBJ1を引数にしてwait関数を呼び出し、その戻り値waitdurationを、decodedurationに加算する。OBJ0が属するwindowの再描画に必要な時間256000000をdecodedurationに加える。もし属するwindowが異なるなら、OBJ0が属するwindowの再描画に必要な時間256000000をdecodedurationに加える。OBJ1を引数にしてwait関数を呼び出し、その戻り値waitdurationを、decodedurationに加算する。その後、OBJ1が属するwindowの再描画に必要な時間256000000をdecodedurationに加える。以上のアルゴリズムにより、DecodeDurationは算出される。このPCSのPTSが、具体的にどのように設定されるかについて説明する。図21aは、1つのwindowに1つのODSが存在するケースを想定した図である。図21bcは、図18で引用した各数値の時間的な前後関係を示すタイミングチャートである。本チャートには3つの段があり、これらの段のうち、グラフィックスプレーンアクセスの段、ODSデコードの段は、再生時にパラレルになされる2つの処理を示す。上述したアルゴリズムは、これらの2つの処理のパラレル実行を想定している。グラフィックスプレーンアクセスは、クリア期間、書き込み期間からなる。このクリア期間は、グラフィックスプレーン全体のクリアに要する期間、グラフィックスプレーンにおける全windowのクリアに要する時間のどちらかを意味する。書き込み期間は、window全体描画に要する期間を意味する。一方、デコード期間は、ODSのDTSからPTSまでに示される期間を意味する。これらクリア期間~書き込み期間は、クリアすべき範囲、デコードすべきODSのサイズ、グラフィックスプレーンに書き込むべきグラフィクスオブジェクトのサイズにより変化し得る。本図では、説明の簡略化のため、ODSのデコード期間の始点は、クリア期間の始点と同一であると仮定している。図21bはデコード期間が長くなるケースであり、DecodeDurationはデコード期間書き込み期間になる。図21cは、クリア期間が長くなるケースであり、DecodeDurationはクリア期間書き込み期間の期間がDecodeDurationになる。図22a~cは、1つのwindowに2つのODSが存在するケースを想定した図である。本図bcにおけるデコード期間は、2つのグラフィクスのデコードに要する期間の総和を意味する。グラフィクス書込期間も、2つのグラフィクスをグラフィックプレーンに書き込む期間の総和を意味する。ODSが2つになっているものの、図21と同様に考えればDecodeDurationを算出することができる。2つのODSをデコードするためのデコード期間が長い場合は、図22bに示すようにDecodeDurationはデコード期間書き込み期間に算出されることになる。クリア期間が長い場合は、図22cに示すように、DecodeDurationはクリア期間書き込み期間となる。図23aは、2つのwindowのそれぞれに、ODSが1つずつ存在するケースを想定している。この場合でもクリア期間が、2つのODSをデコードするための総デコード期間よリ長い場合、DecodeDurationはクリア期間デコード期間になる。問題は、クリア期間がデコード期間より短くなるケースである。この場合デコード期間の経過を待たずに、1つ目のwindowへの書き込みは可能になる。そのためクリア期間書き込み期間、デコード期間書き込み期間の長さにはならない。ここで1つ目のODSのデコードに要する期間を書込期間、2つ目のODSのデコードに要する期間を書込期間とする。図23bは、デコード期間がクリア期間書込期間より長くなるケースを示す。この場合DecodeDurationは、デコード期間書込期間になる。図23cは、クリア期間書込期間がデコード期間より長くなるケースを示す。この場合DecodeDurationはクリア期間書込期間書込期間になる。グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またwindowのサイズ、ODSのサイズ、個数もオーサリングの段階で判明しているので、これらからDecodeDurationがクリア期間書き込み期間、デコード期間書き込み期間、デコード期間書込期間、クリア期間書込期間書込期間のどれかになる。こうしたDecodeDuration算出を基にPCSのPTSを設定すれば、ピクチャデータとの同期表示を高い時間精度で実現することができる。このような高精度な同期制御は、windowを定義し、クリア再描画する範囲を、このwindowに限定することで成り立っているので、オーサリングの環境に、このwindowの概念を導入したことの意義は大きい。続いてDSnにおけるWDSのDTS、PTSの設定について説明する。WDSのDTSは、以下の数式を満たすように設定すればよい。DTS≧DTS一方、DSnにおけるWDSのPTSは、グラフィックスプレーンに対する書き込みを開始すべきデッドラインを示す。グラフィックスプレーンへの書き込みは、ウィンドゥだけで足りるので、PCSのPTSに示される時刻から、WDSの書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。WDSの総サイズをΣSIZEとすれば、これのクリア及び再描画に要する時間は、ΣSIZE256000000になる。そして、これを90000KHzの時間精度で表現すると90000×ΣSIZE256000000になる。故に以下の数式から、WDSのPTSを算出すればよい。PTSPTS90000×ΣSIZE256000000このWDSに示されるPTSはデッドラインなので、これより早い時点からグラフィックスプレーンの書き込みを開始してもよい。つまり図23に示すように、2つのウィンドゥのうち、1つのウィンドゥに表示させるべきODSのデコードが完了したなら、その時点からデコードにより得られたグラフィクスオブジェクトの書き込みを開始してもよい。このようにWDSに付加されたDTS、PTSを用いてAVClipの再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。以上が再生時間軸に対するDisplaySetの割り当てについての説明である。DisplaySetに対するDTS、PTSの設定について、図24~図25の具体例を交えながら説明する。図24は、4回のグラフィックスプレーンへの書き込みにより字幕を表示することを想定した具体例である。この具体例は、2つの字幕whatisbluray、blurayiseverywhereを1つずつ表示させるというアップデートを想定している。図24は、本具体例が想定しているアップデートの、時間的変遷がどのようなものであるかを示す図である。時点t1ではwhatまでを表示し、続く時点t2ではwhatisまで、時点t3ではwhatisbluray全体を表示させる。字幕の全貌を明らかにした上で時点t4において別の字幕blurayiseverywhereを表示させるのである。図25aは、かかるアップデートを実現するため、記述された4つのDisplaySetを示す図である。DS1は、時点t1におけるアップデートを制御するPCS12と、彩色のためのPDS1と、字幕whatisblurayに相当するODS1と、DS1の終了コードであるENDとからなる。DS2は、時点t2におけるアップデートを制御するPCS12と、ENDとからなる。DS3は、時点t3におけるアップデートを制御するPCS13と、ENDとからなる。DS4は、時点t2のアップデートを制御するためのPCS2と、色変換のためのPDS2と、字幕blurayiseverywhereに相当するODS2と、ENDとからなる。これら4つのDisplaySetに属する各機能セグメントのDTS、PTSをどのように設定するかを、図25bのタイミングチャートを参照して説明する。このタイミングチャートの再生時間軸は、図24の再生時間軸と同じものである。このタイミングチャートにおいて、PTS、PTS、PTS、PTSは、それぞれwhatの表示時点t1whatisの表示時点t2whatisblurayの表示時点t3blurayiseverywhereの表示時点t4を示すよう設定される。これは、それぞれの字幕の表示時点において各PCSに記述された制御を実行する必要があるからである。PTSPTSは、PTS及びPTSの時点からDecodeDurationを差し引いた時点を示すよう設定されている。PTSは、数式PTS≧DTSdecodedurationを満たすよう設定する必要があるからである。図25bでは、時点t4より手前の時点t5を示すよう、PTSは設定されており、時点t1より手前の時点t0を示すよう、PTSは設定されている。DTSDTSは、PTS及びPTSの時点からデコード期間を差し引いた時点を示すよう設定されている。DTSは、数式PTSDTS90000×Rdを満たすよう設定する必要があるからである。図25bでは、時点t5より手前の時点t0を示すよう、PTSは設定されており、時点t0より手前の時点を示すよう、PTSは設定されている。ここでDTSPTSの関係が満たされことがわかる。これにより再生装置の実装によっては、ODS1がオブジェクトバッファに読み出された後、このオブジェクトバッファ上のODS1を上書きする形で、ODS2を読み出すことができる。あるODSのPTSを、先に表示すべきODSのPTSに設定しておけば、古いODSを上書きする形で、新しいODSをメモリに読み出すという動作を再生装置が行うことにより、小メモリ規模での再生処理を実現することができる。かかる再生処理の実現により、再生装置におけるメモリ規模の選択の幅は広がる。PCS11のDTSは、DTS=DTSになるように設定されている。これは、PCS11のDTS値は、DTSにより示される時点以前であるなら、どの時点でもよいからである。ODS1のPTS値、ODS2のDTS値、PCS12、PCS13、PCS2のPTS値は、PTS=DTS=PTS=PTS=DTSの関係を満たすよう、何れも時点t0に設定されている。これは、PCS12、PCS13のDTS値は、PTS、PTS以前であれば、どの時点でもよく、またPCS2のDTS値も、DTS以前であれば、どの時点でもよいという自由度があるからである。これにより、複数のPCSをまとめて読み出しておき、前のPCSによるアップデートの実行が終われば続くPCSによるアップデートを即座に実行することができる。PCSのDTSPTS、ODSのDTSPCSは、上述の数式で示したような不等号の関係さえ最低限満たせばよいので、DTSPTSになるように設定したり、PTS=DTS=PTS=PTS=DTSになるように設定することも可能になる。こうしたタイムスタンプの設定により、デコード負荷が発生する期間やバッファの占有量が増える期間を、調整することができる。かかる調整が可能になるので、再生時になしえる再生制御の幅が広がり、オーサリングを行う技術者及び再生装置を製造する技術者にとってのメリットは大きい。これで、DTSPTS設定の具体例の説明を終える。以上説明したDisplaySetのデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、BlurayDiscPrerecordingFormatに規定された構文に従い、クラス構造体を記述することで、BDROM上のこれらのデータ構造を得ることができる。以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図26は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置、マイコンシステムという3つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BDドライブ1、ReadBuffer2、PIDフィルタ3、TransportBuffer4abc、周辺回路4d、ビデオデコーダ5、ビデオプレーン6、オーディオデコーダ7、グラフィクスプレーン8、CLUT部9、加算器10、グラフィクスデコーダ12、CodedDataBuffer13、周辺回路13a、StreamGraphicsProcessor14、ObjectBuffer15、CompositionBuffer16、GraphicalController17から構成される。BDROMドライブ1は、BDROMのローディング/リード/イジェクトを行い、BDROMに対するアクセスを実行する。ReadBuffer2は、FIFOメモリであり、BDROMから読み出されたTSパケットが先入れ先出し式に格納される。PIDフィルタ3は、ReadBuffer2から出力される複数TSパケットに対してフィルタリングを施す。PIDフィルタ3によるフィルタリングは、TSパケットのうち、所望のPIDをもつもののみをTransportBuffer4abcに書き込むことでなされる。PIDフィルタ3によるフィルタリングでは、バッファリングは必要ではない。従って、PIDフィルタ3に入力されたTSパケットは、時間遅延なく、TransportBuffer4abcに書き込まれる。TransportBuffer4abcは、PIDフィルタ3から出力されたTSパケットを先入れ先出し式に格納しておくメモリである。このTransportBuffer4abcからTSパケットが取り出される速度を速度Rxとする周辺回路4dは、TransportBuffer4abcから読み出されたTSパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはCodedDataBuffer13に格納される。ビデオデコーダ5は、PIDフィルタ3から出力された複数TSパケットを復号して非圧縮形式のピクチャを得てビデオプレーン6に書き込む。ビデオプレーン6は、動画用のプレーンメモリである。オーディオデコーダ7は、PIDフィルタ3から出力されたTSパケットを復号して、非圧縮形式のオーディオデータを出力する。グラフィクスプレーン8は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。CLUT部9は、グラフィクスプレーン8に格納された非圧縮グラフィクスにおけるインデックスカラーを、PDSに示されるYCrCb値に基づき変換する。加算器10は、CLUT部9により色変換された非圧縮グラフィクスに、PDSに示されるT値を乗じて、ビデオプレーン6に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。グラフィクスデコーダ12は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン8に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。このグラフィクスデコーダ12は、CodedDataBuffer13、周辺回路13a、StreamGraphicsProcessor14、ObjectBuffer15、CompositionBuffer16、GraphicalController17から構成される。CodedDataBuffer13は、機能セグメントがDTS、PTSと共に格納されるバッファである。かかる機能セグメントは、TransportBuffer4abcに格納されたトランスポートストリームの各TSパケットから、TSパケットヘッダ、PESパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたTSパケットヘッダ、PESパケットヘッダのうち、PTS/DTSは、PESパケットと対応付けて格納される。周辺回路13aは、CodedDataBuffer13-StreamGraphicsProcessor14間の転送、CodedDataBuffer13-CompositionBuffer16間の転送を実現するワイヤロジックである。この転送処理において現在時点がODSのDTSに示される時刻になれば、ODSを、CodedDataBuffer13からStreamGraphicsProcessor14に転送する。また現在時刻がPCS、PDSのDTSに示される時刻になれば、PCS、PDSをCompositionBuffer16に転送するという処理を行う。StreamGraphicsProcessor14は、ODSをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてObjectBuffer15に書き込む。このStreamGraphicsProcessor14によるデコードは、ODSに関連付けられたDTSの時刻に開始し、ODSに関連付けられたPTSに示されるデコード終了時刻までに終了する。上述したグラフィックオブジェクトのデコードレートRdは、このStreamGraphicsProcessor14の出力レートである。ObjectBuffer15は、ETSIEN300743標準規格におけるピクセルバッファに相当するバッファであり、StreamGraphicsProcessor14のデコードにより得られたグラフィクスオブジェクトが配置される。ObjectBuffer15は、グラフィクスプレーン8の2倍/4倍の大きさに設定せねばならない。何故ならScrollingを実現する場合を考えると、グラフィクスプレーン8の2倍、4倍のグラフィクスオブジェクトを格納しておかねばならないからである。CompositionBuffer16は、PCS、PDSが配置されるメモリである。GraphicalController17は、CompositionBuffer16に配置されたPCSを解読して、PCSに基づく制御をする。この制御の実行タイミングは、PCSに付加されたPTSの値に基づく。以上が再生装置の構成要素である。続いて、PIDフィルタ3、TransportBuffer4abc、グラフィクスプレーン8、CLUT部9、CodedDataBuffer13~GraphicalController17を構成するための、転送レート、バッファサイズの推奨値について説明する。図27は、書込レートRxRcRd、グラフィクスプレーン8、CodedDataBuffer13、ObjectBuffer15、CompositionBuffer16のサイズを示す図である。ObjectBuffer15-グラフィクスプレーン8間の転送レートRcは、本装置において最も高い転送レートであり、ウィンドゥサイズ、フレームレートから256Mbpsと算出される。StreamGraphicsProcessor14-ObjectBuffer15間の転送レートRdは、Rcとは異なり、ビデオフレームの周期によるアップデートは要求されずRcの1214でよい。故に128Mbps64Mbpsになる。TransportBuffer4abc-CodedDataBuffer13間のTransportBufferLeakレートRxは、圧縮状態たるODSの転送レートである。従ってTransportBufferLeakレートは、Rdに圧縮率を乗じた転送レートでよい。ODSの圧縮率を25と仮定すれば、16Mbpsで足りる。この図に示す転送レート、バッファ規模はあくまでもミニマムスタンダードであり、これより大きい値での実装を否定している訳ではない。以上のように構成された再生装置において、各構成要素はパイプライン式にデコード処理を行うことができる。図28は、再生装置によるパイプライン処理を示すタイミングチャートである。第5段目は、BDROMにおけるDisplaySetを示し、第4段目は、CodedDataBuffer13へのPCS、WDS、PDS、ODSの読出期間を示す。第3段目は、StreamGraphicsProcessor14による各ODSのデコード期間を、第2段目はCompositionBuffer16の格納内容を、第1段目はGraphicalController17の処理内容を示す。ODS12に付与されたDTSは、図中のt31t32の時点を示している。デコード開始時刻がDTSに規定されているので、各ODSは、自身のDTSに示される時刻までにCodedDataBuffer13に読み出されなければならない。そのためODS1の読み出しは、CodedDataBuffer13へのODS1のデコード期間dp1の直前までに完了している。CodedDataBuffer13へのODS2の読み出しは、ODS2のデコード期間dp2の直前までに完了している。一方、ODS12に付与されたPTSは、図中のt32t33の時点を示している。StreamGraphicsProcessor14によるODS1のデコードはt32までに完了し、ODS2のデコードは、t33に示される時刻までに完了する。以上のように、StreamGraphicsProcessor14は、各ODSのDTSに示される時刻までに、ODSをCodedDataBuffer13に読み出し、CodedDataBuffer13に読み出されたODSを、各ODSのPTSに示される時刻までに、デコードしてObjectBuffer15に書き込む。本図の第1段目における期間cd1は、GraphicsController17がグラフィクスプレーン8をクリアするのに要する期間である。また期間td1は、ObjectBuffer15上にえられたグラフィクスオブジェクトを、グラフィクスプレーン8に書き込むのに要する期間である。WDSのPTSは、この書き込みの開始にあたってのデッドラインを示し、PCSのPTSはこの書き込みの終了時点及び表示タイミングを示す。このPCSのPTSに示される時点になれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン8上に得られることになる。この非圧縮グラフィクスの色変換をCLUT部9に行わせ、ビデオプレーン6に格納されている非圧縮ピクチャとの合成を加算器10に行わせれば、合成画像が得られることになる。グラフィクスデコーダ12において、GraphicsController17がグラフィクスプレーン8のクリアを実行している間においても、StreamGraphicsProcessor14のデコードは継続して行われる。以上のようなパイプライン処理により、グラフィクスの表示を迅速に実施することができる。図28では、グラフィックスプレーンのクリアが、ODSのデコードより早く終わる場合を想定したが、図29は、ODSのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。この場合、ODSのデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。以上が再生装置の内部構成である。続いて制御部20及びグラフィクスデコーダ12を、どのようにして実装するかについて説明する。制御部20は、図30の処理手順を行うプログラムを作成し、汎用CPUに実行させることにより実装可能である。以降、図30を参照しながら、制御部20の処理手順について説明する。図30は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてSegmentKとは、AVClipの再生時において、読み出されたSegmentのそれぞれを意味する変数であり、無視フラグは、このSegmentKを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを0に初期化した上で、ステップS21~S24、ステップS27~S31の処理を全てのSegmentKについて繰り返すループ構造を有している。ステップS21は、SegmentKがPCSであるか否かの判定であり、もしSegmentKがPCSであれば、ステップS27、ステップS28の判定を行う。ステップS22は、無視フラグが1かどうかの判定である。無視フラグが0であるならステップS23に移行し、1であるならステップS24に移行する。無視フラグが1であれば、ステップS23においてSegmentKをCodedDataBuffer13にロードする。無視フラグが0に設定されていれば、ステップS24においてSegmentKが無視される。これによりDSに属する機能セグメントは全て、ステップS22がNoになって、無視されることになる。このように、SegmentKが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップS27~S31、S34、S35は、この無視フラグを設定する処理である。ステップS27は、PCSにおけるsegmenttypeがAcquisitionPointであるか否かの判定である。SegmentKがAcquisitionPointであるなら、ステップS28に移行し、SegmentKがもしEpochStartかNormalCaseであるなら、ステップS31に移行する。ステップS28は、先行するDSがグラフィクスデコーダ12内のどれかのバッファに存在するかどうかの判定であり、ステップS27がYesである場合に実行される。グラフィクスデコーダ12内にDSが存在しないケースとは、頭出しがなされたケースをいう。この場合、AcquisitionPointたるDSから、表示を開始せねばならないので、ステップS30に移行する。ステップS30は、無視フラグを0に設定し、ステップS22に移行する。グラフィクスデコーダ12内にDSが存在するケースとは、通常再生がなされたケースをいう。この場合、ステップS29に移行する。ステップS29は、無視フラグを1に設定し、ステップS22に移行する。ステップS31は、PCSにおけるsegmenttypeがNormalCaseであるか否かの判定である。もしNormalCaseであるなら、ステップS34に移行する。SegmentKがEpochStartであるなら、ステップS30において無視フラグを0に設定する。ステップS34は、ステップS28と同じであり、先行するDSがグラフィクスデコーダ12内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを0に設定する。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを1に設定する。かかるフラグ設定により、先行するDSがグラフィクスデコーダ12に存在しない場合、NormalCaseを構成する機能セグメントは無視されることになる。DSが、図31のように多重化されている場合を想定して、DSの読み出しがどのように行われるかを説明する。図31の一例では、3つのDSが動画と多重化されている。この3つのDSのうち、初めのDS1は、segmenttypeがEpochStart、DS10はAcquisitionPoint、DS20は、NormalCaseである。かかる3つのDSが、動画と多重化されているAVClipにおいて、ピクチャデータpt10からの頭出しが矢印am1に示すように行われたものとする。この場合、頭出し位置に最も近いDS10が、図30のフローチャートの対象となる。ステップS27においてsegmenttypeはAcquisitionPointと判定されるが、先行するDSはCodedDataBuffer13上に存在しないため、無視フラグは0に設定され、このDS10が図32の矢印md1に示すように再生装置のCodedDataBuffer13にロードされる。一方、頭出し位置がDS10の存在位置より後である場合、DS20は、NormalCaseのDisplaySetであり、先行するDS20はCodedDataBuffer13に存在しないので、このDisplaySetは、無視されることになる。図33のように通常再生が行われた場合のDS11020のロードは、図33に示すものとなる。3つのDSのうち、PCSのsegmenttypeがEpochStartであるDS1は、そのままCodedDataBuffer13にロードされるが、PCSのsegmenttypeがAcquisitionPointであるDS10については、無視フラグが1に設定されるため、これを構成する機能セグメントはCodedDataBuffer13にロードされず無視される。またDS20については、PCSのsegmenttypeはNormalCaseなので、CodedDataBuffer13にロードされる。続いてGraphicalController17の処理手順について説明する。図35~図37は、GraphicalController17の処理手順を示すフローチャートである。ステップS41~ステップS44は、本フローチャートのメインルーチンであり、ステップS41~ステップS44に規定した何れかの事象の成立を待つ。ステップS41は、現在の再生時点がPCSのDTS時刻になっているか否かの判定であり、もしなっていれば、ステップS45~ステップS53の処理を行う。ステップS45は、PCSのcompositionstateが、EpochStartであるか否かの判定であり、もしEpochStartであるなら、ステップS46においてグラフィクスプレーン8を全クリアする。それ以外であるなら、ステップS47においてWDSのwindowhorizontalposition、windowvertivalposition、windowwidth、windowheightに示されるwindowをクリアする。ステップS48は、ステップS46又はステップS47でのクリア後の実行されるステップであり、任意のODSxのPTS時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン8全体のクリアにあたっては、そのクリア時間に長時間を費するので、あるODSのデコードが既に完了していることもある。ステップS48はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかのODSのデコード時刻を経過しているなら、ステップS49~ステップS51を実行する。ステップS49は、objectcropflagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする。もし0を示していないなら、objectcroppinghorizontalposition、objectcroppingvertivalposition、croppingwidth、croppingheightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいてobjectcroppinghorizontalpositionobjectcroppingvertivalpositionに示される位置に書き込む。以上の処理により、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。ステップS52は、別のODSyのPTS時刻が経過しているか否かの判定である。ODSxをグラフィクスプレーン8に書き込んでいる際、別のODSのデコードが既に完了していれば、このODSyをODSxにして、ステップS49に移行する。これにより、別のODSに対しても、ステップS49~S51の処理が繰り返し行われる。次に図36を参照して、ステップS42、ステップS54~ステップS59について説明する。ステップS42は、現在の再生時点がWDSのPTSであるか否かの判定であり、もしWDSのPTSであるなら、ステップS54においてウィンドゥが1つであるか否かを判定し、もし2つであれば、メインルーチンにリターンする。ウィンドゥが1つであるなら、ステップS55~ステップS59のループ処理を行う。このループ処理は、ウィンドゥに表示される2つのグラフィクスオブジェクトのそれぞれについて、ステップS57~ステップS59を実行するというものである。ステップS57は、objectcropflagが0を示しているか否かの判定であり、もし0を示しているなら、グラフィクスオブジェクトを非表示とする。もし0を示していないなら、objectcroppinghorizontalposition、objectcroppingvertivalposition、croppingwidth、croppingheightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいてobjectcroppinghorizontalpositionobjectcroppingvertivalpositionに示される位置に書き込む。以上の処理を繰り返せば、ウィンドゥに1つ以上のグラフィクスオブジェクトが描かれることになる。ステップS44は、現在の再生時点がPDSのPTSに示される時点であるかの判定であり、もしそうであるなら、ステップS60においてPalletupdateflagが1を示しているか否かを判定する。もし1を示しているなら、palletidに示されるPDSをCLUT部に設定する。0を示しているなら、ステップS61をスキップする。その後、グラフィクスプレーン8におけるグラフィクスオブジェクトの色変換をCLUT部に行わせて、動画像と合成する。次に図37を参照して、ステップS43、ステップS64~ステップS66について説明する。ステップS43は、現在の再生時点がODSのPTSであるか否かの判定であり、もしODSのPTSであるなら、ステップS63においてウィンドゥが2つであるか否かを判定し、もし1つであれば、メインルーチンにリターンする。ウィンドゥが2つであるなら、ステップS64~ステップS66を行う。ステップS64は、objectcropflagが0を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする。もし0を示していないなら、objectcroppinghorizontalposition、objectcroppingvertivalposition、croppingwidth、croppingheightに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン8のwindowにおいてobjectcroppinghorizontalpositionobjectcroppingvertivalpositionに示される位置に書き込む。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。以上、DSnに属するPCSのDTSPTSODSのDTS、PTSの設定について説明したが、PDSのDTS、PTS、ENDのDTS、PTSについては説明していない。先ず、DSnに属する各PDSのDTSPTSの設定について説明する。DSnに属する各PDSは、PCSがCompositionBuffer16にロードされる時点から、最初のODSのデコード開始時点までに、CLUT部9において、有効になればよい。このことからDSnに属する各PDSのPTS値は、以下の関係を満たす値に、設定されねばならない。DTS≦PTSPTS≦PTS≦PTSPTS≦DTS尚、PDSにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。以上の関係を満たすようDTS、PDSが設定された場合、再生装置のパイプラインにおいてこれらDTS、PTSがどのような役割をもつかについて説明する。図38はPDSにおけるPTSに基づく、再生装置におけるパイプラインを示す図である。この図38は、図28をベースにして作図されている。図38において第1段目は、CLUT部9へのPDS設定を示している。以降の段は、図28の第1~第5段目と同じである。PDS1~lastのCLUT部9への設定は、PCSWDSの転送後、ODS1のデコードより前になされるので、矢印up2up3に示すようにODS1のDTSに示される時点より前に設定されている。以上のようにPDSの設定は、ODSのデコードの先立ちなされることがわかる。続いてDSnに属するENDofDisplaySetSegmentのPTSの設定について説明する。DSnに属するENDは、DSnの終わりを示すものだから、ODS2のデコード終了時刻を示せばよい。このデコード終了時刻は、ODS2のPTSに示されているので、ENDのPTSは、以下の式に示される値に設定されねばならない。PTSPTSDSnDSn1に属するPCSとの関係で考えれば、DSnにおけるPCSは、最初のODSのロード時刻以前に、CompositionBuffer16にロードされるから、ENDのPTSは、DSnに属するPCSのロード時刻以降、DSn1に属するPCSのロード時刻以前でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。DTS≦PTS≦DTS一方、最初のODSのロード時刻は、最後のPDSのロード時刻以前であるから、ENDのPTSは、DSnに属するPDSのロード時刻以降でなければならない。そのためENDのPTSは、以下の式の関係を満たす必要がある。PTS≦PTS続いて再生装置のパイプラインにおいて、ENDのPTSが、どのような意味合いをなすのかについて説明する。図39は、再生装置のパイプライン動作時における、ENDの意味合いを示す図である。本図は、図28の第2段目以降をベースに作図しており、第2段以降の意味合いは図28と同一である。また本図では、DSnDSn1という2つのDisplaySetを描いている。DSnにおいてODSlastになるのは、AODSsの最後のODSnであるので、ENDのPTSは、このODSnのPTSを示すよう設定されている。そして、このENDのPTSに示される時点は、DSn1のPCSのDTSにより示される時点より早いものになっている。このENDのPTSにより、再生時にあたっては、DSnについてのODSのロードが、どの時点で完了するのかを知得することができる。尚、ENDにおいてDTSは再生時に参照されないが、MPEG2規格を満たすため、PDSのDTSは、そのPTSと同じ値に設定される。以上のように本実施形態によれば、グラフィックプレーンの一部をグラフィクスの表示のためのウィンドゥとして指定するので、再生装置は、プレーン全体のグラフィクス描画を行う必要はない。グラフィックプレーンの25~33など、ある限られた大きさのウィンドゥに対してのみ、グラフィクス描画を行えばよい。グラフィックプレーンのうち、ウィンドゥ以外の部分の描画を省くことができるので、再生装置側のソフトウェアの負担は遥かに軽くなる。グラフィックプレーンの14等、グラフィクスのアップデートがワーストケースで行われる場合であっても、ピクチャとの同期が保証されるような大きさにウィンドゥを定めておけば、再生装置は、256Mbps等、ある決まった転送レートでグラフィックプレーンの書き込みを行いさえすれば、ピクチャとの同期を実現することができる。同期保証が容易になるので、高い解像度での字幕表示を多くの再生装置において実現することができる。第1実施形態では、ビデオフレーム毎にグラフィクスをアップデートできるように、ウィンドゥの大きさをグラフィックスプレーン全体の14とし、グラフィックスプレーンへの書込レートRcを256Mbpsとした。またアップデートレートを、ビデオフレームレートの1214とすることにより、大きなサイズのグラフィクスのアップデートの実現も可能とした。しかしアップデートレートをビデオフレームレートの1214とした場合、グラフィックスプレーンへの書き込みは、24ビデオフレームを要する。そしてグラフィックスプレーンが1つであれば、この書き込みに費やされる24フレームの間、グラフィクスが書き込まれる過程がユーザに見えてしまう。そうすると、あるグラフィクスから大きなグラフィクスへと瞬時に切り換わるような表示効果は実現できない。そこで第2実施形態ではグラフィックスプレーンを2つ設ける。図40は、第2実施形態に係る再生装置の内部構成を示す図である。本図が図26、図27と比較して新規なのは、グラフィックスプレーンが2つ有り、この2つのグラフィックスプレーンがダブルバッファを構成している点である。そのため、2つのグラフィックスプレーンのうち一方からの読み出しが行われている間、他方のグラフィックスプレーンへの書き込みは可能になる。そして第2実施形態に係るGraphicalController17は、この読出対象の切り換えをPCSに付与されているPTSの時点に実行する。図41は、ダブルバッファによるグラフィックスプレーン読み出し/書き込みを模式的に示す図である。本図の縦軸方向は、グラフィクスプレーン81、グラフィクスプレーン82の格納内容を、横軸方向は、1フレーム目、2フレーム目、345フレーム目のグラフィックスプレーンの格納内容を示している。そしてグラフィクスプレーン81、グラフィクスプレーン82の格納内容のうち、太い枠で囲まれているものが、読み出しの対象になっている。本図では、グラフィクスプレーン81に顔マークが格納されており、これを太陽マークに置き換えることを意図している。太陽マークはObjectBuffer15に存在しており、4MByteのサイズをもつ。この4MByteのサイズは、ObjectBuffer15の目一杯のサイズである。太陽マークを、グラフィクスプレーンへの書込レートで書き込むなら、グラフィクスプレーン82への書き込み完遂に4フレームがかかる。そしてこの書き込みに費やされる4フレームという期間において、1フレーム目では太陽マークのグラフィクスは14だけ、2フレーム目では24、3フレーム目では34だけ書き込みがなされる。しかし1フレームから4フレーム目までは、グラフィクスプレーン81、グラフィクスプレーン82のうち、読出対象がグラフィクスプレーン81なので、これら太陽マークがグラフィックスプレーンに書き込まれている過程は、ユーザには見えない。5フレーム目においてグラフィックスプレーンの読出対象がグラフィクスプレーン82に移った段階で、グラフィクスプレーン82の格納内容はユーザに見える。これにより顔マークから太陽マークへの切り換わり時になされる。以上のように本実施形態によれば、4フレームをかけて大きなサイズのグラフィクスをグラフィックスプレーンに書き込む場合でも、瞬時に画面切り換えを実現することができるので、画面一杯に映画制作者、制作スタッフ、出演者の氏名のクレジットを表示する場合や、映画のあらすじ、警告文を、瞬時に表示する場合に有意義である。本実施形態は、BDROMの製造工程に関する実施形態である。図42は、第3施形態に係るBDROMの製造工程を示すフローチャートである。BDROMの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程S201、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程S202、BDROMの原盤を作成し、プレス貼り合わせを行って、BDROMを完成させるプレス工程S203を含む。これらの工程のうち、BDROMを対象としたオーサリング工程は、以下のステップS204~ステップS209を含む。ステップS204において、字幕の表示範囲となるwindowを定義するようWDSを記述し、ステップS205では、windowが同じになる再生区間をEpochとし、個々のEpochにおけるPCSを記述する。こうしてPCSが得られれば、ステップS206において字幕素材たるグラフィクスをODSに変換しこれをPCS、WDS、PDSを組み合わせることでDisplaySetを得る。その後、ステップS207では、DisplaySetにおける各機能セグメントをPESパケット化し、タイムスタンプを付与することによりグラフィクスストリームを得る。最後に、ステップS208では、グラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重することでAVClipを生成する。AVClipが得られれば、AVClipをBDROMのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。しかし請求項に係る各発明は、従来技術の技術的課題を解決するための手段を反映したものであるから、請求項に係る各発明の技術範囲は、従来技術の技術的課題解決が当業者により認識される技術範囲を超えることはない。故に、本願の請求項に係る各発明は、詳細説明の記載と、実質的な対応関係を有する。全ての実施形態では、本発明に係る記録媒体をBDROMとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、BDROMの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVDROMDVDRAMDVDRWDVDRDVDRWDVDRCDRCDRW等の光ディスク、PDMO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ登録商標カード、スマートメディア、メモリスティック、マルチメディアカード、PCMCIAカード等の半導体メモリカードであってもよい。フレシキブルディスク、SuperDiskZipClik等の磁気記録ディスク、ORBJazSparQSyJetEZFleyマイクロドライブ等のリムーバルハードディスクドライブであってもよい。更に、機器内蔵型のハードディスクであってもよい。全ての実施形態における再生装置は、BDROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBDROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムLSIのみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、第1実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第1実施形態に示した再生装置の有償無償による譲渡、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、第1実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為や、有償無償によりプログラムを譲渡する行為、貸与する行為、輸入する行為、双方向の電子通信回線を介して公衆に提供する行為、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為がある。各フロ-チャ-トにおいて時系列に実行される各ステップの時の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ-チャ-トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ-チャ-トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。BDROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TPextraheaderと呼ばれ、ArribvalTimeStampと、copypermissionindicatorとを含み4バイトのデータ長を有する。TPextraheader付きTSパケットは、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイトであり、これは3個のセクタサイズ6144バイトと一致する。3個のセクタに収められた32個のEX付きTSパケットをAlignedUnitという。IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてAlignedUnitの送信を行う。つまり送り手側の機器は、AlignedUnitに含まれる32個のEX付きTSパケットのそれぞれからTPextraheaderを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TPextraheaderのArribvalTimeStampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置はDTCPDescriptorを出力する。DTCPDescriptorは、TPextraheaderにおけるコピー許否設定を示す。ここでコピー禁止を示すようDTCPDescriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。各実施形態におけるデジタルストリームは、BDROM規格のAVClipであったが、DVDVideo規格、DVDVideoRecording規格のVOBであってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISOIEC138181規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、LinearPCM方式、DolbyAC3方式、MP3方式、MPEGAAC方式、dts方式であってもよい。各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。またビデオテープに記録されているアナログ/デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ/デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。第1実施形態~第2実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いている。デコードを実現する装置構成を、字幕-グラフィックスオブジェクト間で共通化する目的で、字幕と同じ圧縮伸長方式をグラフィックスオブジェクトに採用している。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはPNGデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。PCSによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のDVDにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。PCSによる表示効果の対象は、装置側のディスプレィ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがBDROMに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、PCSに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレィ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。第1実施形態ではグラフィックスプレーンへの書込レートRcは、1ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、windowのサイズを全体の25に定めたが、これらクリア再描画が垂直帰線期間に完遂するよう、Rcを定めても良い。垂直帰線期間は12993秒の25と仮定すると、Rcは1Gbpsになる。Rcをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Rc256Mbpsの書込レートであっても、スムーズな表示の実現が可能になる。各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、商標を構成するような図形文字色彩の組合せや、国の紋章旗章記章国家が採用する監督証明用の公の記号印章、政府間国際機関の紋章旗章記章特定商品の原産地表示を含んでいてもよい。第1実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。各実施形態におけるAVClipは、映画作品を構成するものであったが、AVClipはカラオケを実現するものであってもよい、そしてこの場合、PCSは歌の進行に応じて、字幕の色を変えるという表示効果を実現してもよい。