(57)【要約】ＢＤ−ＲＯＭには、動画ストリームとグラフィクスストリームとを多重化することにより得られたＡＶＣｌｉｐが記録されている。  グラフィクスストリームは、ＰＥＳパケットの配列であり、ＰＥＳパケットには、グラフィクスデータを格納したＯＤＳ（Ｏｂｊｅｃｔ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）と、制御情報を格納したＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  ＣｏｎｔｒｏｌＳｅｇｍｅｎｔ）とがある。ＰＣＳは、ＰＥＳパケット列において自身より前方に存在するＯＤＳ内のグラフィクスデータを、所定のタイミングで動画ストリームと合成して表示する旨を示す。ＰＣＳ、ＯＤＳは、それぞれ別々のＤｉｓｐｌａｙ  Ｓｅｔに属しており、このＯＤＳは同じＤｉｓｐｌａｙＳｅｔ内のＰＣＳからは参照されていない、非参照グラフィクスデータであってもよい。
2005002220.tif 000002
【特許請求の範囲】
【請求項１】
動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されている記録媒体であって、
グラフィクスストリームは、パケットの配列であり、
パケットには、グラフィクスデータを格納したものと、制御情報を格納したものとがあり、
制御情報は、パケット列において自身より前方に存在するグラフィクスデータを、所定のタイミングで動画ストリームと合成して表示する旨を示す、ことを特徴とする記録媒体。
【請求項２】
グラフィクスストリームにおけるパケットは、複数のディスプレイセットの何れかに分類されており、個々のディスプレイセットは、グラフィクス表示を実現する一個のデータの集合であり、
前記グラフィクスデータ及び制御情報は、
別々のディスプレイセットに属しており、
前記グラフィクスデータは、同じディスプレイセットに属する制御情報からは参照されていない、非参照グラフィクスデータである
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
制御情報は、完結した状態でパケットに格納されており、
前記所望のタイミングは、前記パケットのタイムスタンプに示されている、ことを特徴とする請求項１記載の記録媒体。
【請求項４】
前記制御情報は、パレットデータと組みになって記録媒体に記録されており、
前記制御情報による表示は、パレットデータを用いたグラフィクスデータの色変換を、再生装置に命じる旨を示す、ことを特徴とする請求項１記載の記録媒体。
【請求項５】
制御情報により示される表示は、グラフィクスデータの２回目以降の表示であり、
制御情報は、更新フラグを有し、
更新フラグは、色変換に用いるパレットデータのみを用いて表示更新を行う旨を示す、ことを特徴とする請求項４記載の記録媒体。
【請求項６】
前記グラフィクスストリームはウィンドゥ情報を含み、
ウィンドゥ情報は、グラフィクス表示のための描画領域を特定する情報であり、動画ストリームと合成する際の画面上でのウィンドゥの位置、縦幅、横幅を示し、
前記制御情報による表示位置は、
前記グラフィクス表示がウィンドゥに収まるように規定されている
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームを再生する再生装置であって、
ビデオストリームをデコードして動画像を得るビデオデコーダと、
グラフィクスストリームをデコードしてグラフィクスを得て、動画像に合成するグラフィクスデコーダとを備え、
グラフィクスデコーダは、
記録媒体から新たな制御情報が記録媒体から読み込まれれば、その制御情報に基づき、前もって送り込まれたグラフィクスデータを表示する
ことを特徴とする再生装置。
【請求項８】
グラフィクスストリームはグラフィクス表示を実現するデータの集合であるディスプレイセットを複数含み、
コントローラは、
１つのディスプレイセットが記録媒体から読み出されれば、そのディスプレイセットに属するグラフィクスデータであって、同じディスプレイセットに属する制御情報からは参照されていない、非参照グラフィクスデータをオブジェクトバッファに格納しておき、
前記前もって送り込まれたグラフィクスデータは、オブジェクトバッファに格納されている非参照グラフィクスデータである
ことを特徴とする請求項７記載の再生装置。
【請求項９】
記録媒体から新たに読み出される制御情報は、完結した状態でパケットに格納されており、
前記グラフィクスデコーダによる表示は、
ビデオストリームの再生が、パケットのタイムスタンプに示されている時点に到達した際に行われる
ことを特徴とする請求項７記載の再生装置。
【請求項１０】
前記デコードにより得られた非圧縮グラフィクスは、コード値を用いて表現され、
前記再生装置は、
グラフィクスを表すコード値を、画素値に変換するルックアップテーブル部を備え、
制御情報は、パレットデータと組みになって、記録媒体から読み出され、
前記グラフィクスデコーダによる表示とは、
記録媒体から読み出されたパレットデータを、ルックアップテーブル部に設定し、そのパレットデータを用いた画素値変換を、ルックアップテーブル部に命じることである
ことを特徴とする請求項７記載の再生装置。
【請求項１１】
グラフィクスデコーダによる表示は、既に表示されているグラフィクスの更新であり、
制御情報は、更新フラグを有し、
更新フラグが所定の値であるなら、ルックアップテーブル部に対するパレットデータの設定のみを行うことで、グラフィクスの更新を行う、ことを特徴とする請求項１０記載の再生装置。
【請求項１２】
前記グラフィクスストリームはウィンドゥ情報を有し、
ウィンドゥ情報は、各ピクチャを表示するための画面の一部を、グラフィクス表示用のウィンドゥとして指定する情報であり、
グラフィクスデコーダによるグラフィクス描画は、
画面においてウィンドゥ情報に示されるウィンドゥをクリアする処理、及び、画面におけるウィンドゥに対しグラフィクスを書き込む処理を含むことでなされる、請求項７記載の再生装置。
【請求項１３】
記録媒体の記録方法であって、
アプリケーションデータを作成するステップと、
作成したデータを記録媒体に記録するステップとを有し、
前記アプリケーションデータは、
動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームを含み、
グラフィクスストリームは、パケットの配列であり、
パケットには、グラフィクスデータを格納したものと、制御情報を格納したものとがあり、
制御情報は、パケット列において自身より前方に存在するグラフィクスデータを、所定のタイミングで動画ストリームと合成して表示する旨を示す、
ことを特徴とする記録方法。
【請求項１４】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生をコンピュータに行わせるプログラムであって、
ビデオストリームをデコードして動画像を得るステップと、
グラフィクスストリームをデコードしてグラフィクスを得て、動画像に合成するステップとを備え、
グラフィクスを得るステップは、
記録媒体から新たな制御情報が記録媒体から読み込まれれば、その制御情報に基づき、前もって送り込まれたグラフィクスデータを表示する
処理をコンピュータに行わせることを特徴とするプログラム。
【請求項１５】
ビデオストリーム、グラフィクスストリームが多重化されたデジタルストリームの再生をコンピュータに行わせる再生方法であって、
ビデオストリームをデコードして動画像を得るステップと、
グラフィクスストリームをデコードしてグラフィクスを得て、動画像に合成するステップとを備え、
グラフィクスを得るステップは、
記録媒体から新たな制御情報が記録媒体から読み込まれれば、その制御情報に基づき、前もって送り込まれたグラフィクスデータを表示する
ことを特徴とする再生方法。
【発明の詳細な説明】
【技術分野】  本発明は、動画ストリーム及びグラフィクスストリームが多重化されたデジタルストリームが記録されている記録媒体と、そのデジタルストリームを再生する再生装置とに関し、特に動画ストリーム及びグラフィクスストリームを再生装置が別個にデコードし、そのデコードにより得られた映像−グラフィクスを合成することで、再生映像を得る技術に関する。
【背景技術】  上述した合成技術は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択して表示することもできる。また必要に応じてグラフィクスを表示したり、消したりという選択も可能である。これらの選択が可能なので、かかる技術は、ＤＶＤ−Ｖｉｄｅｏ規格やＥＴＳＩ  ＥＮ  ３００  ７４３標準規格のプレーヤモデルに採用されている。上記規格技術においてグラフィクスストリームは、ＰＥＳパケットの配列であり、ＰＥＳパケットには、制御情報を格納したもの、グラフィクス本体たるグラフィクスデータを格納したものの２種類がある。制御情報は、グラフィクスデータより前に配置されており、制御情報及びグラフィクスデータの一対で一個のグラフィクス表示を実現する。具体的にいうと、再生装置は制御情報及びグラフィクスデータが順次読み込み、制御情報を解読すると共に、グラフィクスデータをデコードし、デコードにより得られた非圧縮グラフィクスを、制御情報の解読結果に従い、所望の表示タイミングで表示する。
以上のようなグラフィクス表示にあたっては、グラフィクス表示の度に、グラフィクスデータのデコードを行う必要があるので、１つのグラフィクス表示から、次のグラフィクス表示までの間隔は、グラフィクスデータのデコード期間に依存したものとなる。ここでグラフィクスの解像度が高く、デコード期間が長ければ長いほど、グラフィクスの更新間隔も長くなってしまう。
映画における字幕のように、グラフィクスが２〜３秒という時間間隔で更新されるのであれば、多少、グラフィクスの解像度が高く、デコード期間が長くなったとしても問題はない。しかし、アミューズメントの用途にグラフィクスを使用しようとする場合、グラフィクスの表示間隔をもっと短くしたいという要望がでてくる。
ここでアミューズメントの用途とは、登場人物の台詞を示すグラフィクスに、独特の動きを与えて、視聴者の注意をひいたり、色彩を派手に変化させることで、視聴者の意表を突くというものである。かかるグラフィクス表示の実現は、バラエティ色が濃い映像コンテンツの制作現場からの要望が特に強い。
しかしグラフィクスの滑らかな動きを実現するには、グラフィクスをデコードし、表示するという処理を、ディスプレィの一表示期間（ＮＴＳＣ方式の場合は１／２９．９７ｓｅｃ）という僅かな期間が経過する毎に、行う必要がある。ディスプレィの一表示期間が経過する度に、グラフィクスのデコード−表示を繰り返すというのは、多大な負荷であり、低コストでの普及を想定しているような再生装置のハードウェアスペックでは実現が困難である。
無論、上述したようなグラフィクス動きや色彩変化は、動画像の一コマ一コマにグラフィクスを予め合成しておき、各コマの絵柄の一部としてグラフィクスを取り扱うことで実現可能である。しかし一コマ一コマに、グラフィクスを予め合成しておくといく方法は、再生装置における言語設定やディスプレィ設定に応じて、グラフィクスを選択的に表示するという、融通性を欠く。そのため、かかる方法を採用している限り、将来への展望は見えてこない。
【発明の開示】
本発明の目的は、グラフィクスを、動画のような滑らかさで動かすことができる記録媒体を提供することである。
上記目的は、動画ストリームとグラフィクスストリームとを多重化することにより得られたデジタルストリームが記録されており、グラフィクスストリームは、パケットの配列であり、パケットには、グラフィクスデータを格納したものと、制御情報を格納したものとがあり、制御情報は、パケット列において自身より前方に存在するグラフィクスデータを、所定のタイミングで動画ストリームと合成して表示する旨を示す、ことを特徴とする記録媒体により達成される。
制御情報は、自身より前方に存在するグラフィクスデータを用いた表示を行う旨を示している。そのため、新たな座標を示す制御情報のみを再生装置に送り込むだけでグラフィクスの表示位置を変えたり、グラフィクスの色彩を変化させるという制御を再生装置に行わせることができる。
制御情報を送り込むだけで、グラフィクス表示を更新することができるので、グラフィクスの頭出し位置と、動画との同期が容易になる。
ここでグラフィクスの表示位置を変化させる場合、グラフィクスそのものの絵柄の変化は必要でないことが多い。人間の目は、動く対象をそれ程鮮明に捉えることができないからである。同じグラフィクスを、高速に位置を変えながら表示するという処理に適した技術が、本発明の本質である。
【図面の簡単な説明】  図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。
図２は、ＢＤ−ＲＯＭの構成を示す図である。
図３は、ＡＶＣｌｉｐがどのように構成されているかを模式的に示す図である。
図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。
図４（ｂ）は、機能セグメントを変換することで得られるＰＥＳパケットを示す図である。
図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。
図６は、字幕の表示位置と、Ｅｐｏｃｈとの関係を示す図である。
図７（ａ）は、ＯＤＳによるグラフィクスオブジェクトの定義を示す図である。
図７（ｂ）は、ＰＤＳのデータ構造を示す図である。
図８（ａ）は、ＷＤＳのデータ構造を示す図である。
図８（ｂ）は、ＰＣＳのデータ構造で構成される。
図９は、字幕表示を実現するためのＤｉｓｐｌａｙ  Ｓｅｔの記述例である。
図１０は、ＤＳ１におけるＷＤＳ、ＰＣＳの記述例を示す図である。
図１１は、ＤＳ２におけるＰＣＳの記述例を示す図である。
図１２は、ＤＳ３におけるＰＣＳの記述例を示す図である。
図１３は、図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。
図１４は、ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎの計算アルゴリズムの一例を示す図である。
図１５は、図１４のプログラムのアルゴリズムを図式化したフローチャートである。
図１６（ａ）（ｂ）は、図１４のプログラムのアルゴリズムを図式化したフローチャートである。
図１７（ａ）は、１つのｗｉｎｄｏｗに１つのＯＤＳが存在するケースを想定した図である。
図１７（ｂ）（ｃ）は、図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
図１８（ａ）は、１つのｗｉｎｄｏｗに２つのＯＤＳが存在するケースを想定した図である。
図１８（ｂ）（ｃ）は、図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。
図１９（ａ）は、２つのｗｉｎｄｏｗのそれぞれに、ＯＤＳが１つずつ存在するケースを想定したタイミングチャートである。
図１９（ｂ）は、デコード期間（２）がクリア期間（１）＋書込期間（３１）より長くなるケースを示すタイミングチャートである。
図１９（ｃ）は、クリア期間（１）＋書込期間（３１）がデコード期間（２）より長くなるケースを示すタイミングチャートである。
図２０は、前方参照を行うＰＣＳを描いた図である。
図２１（ａ）は、グラフィクスが画面内を動き回るという表示効果を実現するＥｐｏｃｈを示す図である。
図２１（ｂ）は、ＤＳ１〜ＤＳ８に含まれるＰＣＳの内容と、ＰＴＳ値とを示す図である。  図２２（ａ）は、ＤＳ０内のＯＤＳを示す図である。
図２２（ｂ）は、座標（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）が、ウィンドゥの座標系のどこに存在するかを示す図である。
図２３は、各Ｄｉｓｐｌａｙ  Ｓｅｔに属する各機能セグメントのタイムスタンプに対する設定を示す図である。
図２４は、アップデートの、時間的変遷の具体例を示す図である。
図２５は、Ｐａｌｌｅｔ  Ｏｎｌｙ  Ｕｐｄａｔｅを実現する一連のＤｉｓｐｌａｙ  Ｓｅｔを示す図である。
図２６（ａ）は、ＤＳ０内のＰＤＳ及び各Ｄｉｓｐｌａｙ  ＳｅｔのＰＣＳがどのような内容であるかを示す図である。
図２６（ｂ）は、ＤＳ０〜ＤＳ３内のＰＣＳを示す図である。
図２７は、４つのＤｉｓｐｌａｙ  Ｓｅｔが読み込ませることで実現される、表示効果を現した図である。
図２８は、本発明に係る再生装置の内部構成を示す図である。
図２９は、書込レートＲｘ，Ｒｃ，Ｒｄ、グラフィクスプレーン８、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６のサイズを示す図である。
図３０は、再生装置によるパイプライン処理を示すタイミングチャートである。
図３１は、ＯＤＳのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。
図３２は、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｄｅｄ  Ｄａｔａバッファ１３、グラフィクスプレーン８における蓄積量の時間的遷移を示すタイミングチャートである。
図３３は、機能セグメントのロード処理の処理手順を示すフローチャートである。
図３４は、多重化の一例を示す図である。
図３５は、ＤＳ１０が再生装置のＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードされる様子を示す図である。
図３６は、通常再生が行われる場合を示す図である。
図３７は、図３６のように通常再生が行われた場合のＤＳ１，１０，２０のロードを示す図である。
図３８は、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理手順を示すフローチャートである。
図３９は、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理手順を示すフローチャートである。
図４０は、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理手順を示すフローチャートである。
図４１は、第１実施形態に示したＰＣＳが記録されたＢＤ−ＲＯＭを製造するための製造工程を示す図である。
【発明を実施するための最良の形態】  （第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ＢＤ−ＲＯＭ１００である。このＢＤ−ＲＯＭ１００は、再生装置２００、テレビ３００、リモコン４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の実施行為のうち、生産行為についての形態について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭの応用層に対する改良により実施することができる。図２は、ＢＤ−ＲＯＭの構成を示す図である。
本図の第４段目にＢＤ−ＲＯＭを示し、第３段目にＢＤ−ＲＯＭ上のトラックを示す。本図のトラックは、ＢＤ−ＲＯＭの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット（アプリケーションフォーマット）を表現すると、図中の第１段目のようになる。本図に示すようにＢＤ−ＲＯＭには、ＲＯＯＴディレクトリの下にＢＤＭＶディレクトリがあり、ＢＤＭＶディレクトリの配下には、ＡＶＣｌｉｐを格納したファイル（ＸＸＸ．Ｍ２ＴＳ）、ＡＶＣｌｉｐの管理情報を格納したファイル（ＸＸＸ．ＣＬＰＩ），ＡＶＣｌｉｐにおける論理的な再生経路（ＰＬ）を定義したファイル（ＹＹＹ．ＭＰＬＳ）が存在する。本図に示すようなアプリケーションフォーマットを作成することにより、本発明に係る記録媒体は生産される。尚、ＸＸＸ．Ｍ２ＴＳ、ＸＸＸ．ＣＬＰＩ，ＹＹＹ．ＭＰＬＳといったファイルが、それぞれ複数存在する場合は、ＢＤＭＶディレクトリの配下に、ＳＴＲＥＡＭディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＰＬＡＹＬＩＳＴディレクトリという３つのディレクトリを設け、ＳＴＲＥＡＭディレクトリにＸＸＸ．Ｍ２ＴＳと同じ種別のファイルを、ＣＬＩＰＩＮＦディレクトリにＸＸＸ．ＣＬＰＩと同じ種別のファイルを、ＰＬＡＹＬＩＳＴディレクトリにＹＹＹ．ＭＰＬＳと同じ種別のファイルを格納することが望ましい。
このアプリケーションフォーマットにおけるＡＶＣｌｉｐ（ＸＸＸ．Ｍ２ＴＳ）について説明する。
ＡＶＣｌｉｐ（ＸＸＸ．Ｍ２ＴＳ）は、ＭＰＥＧ−ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）形式のデジタルストリームであり、ビデオストリーム、１つ以上のオーディオストリーム、プレゼンテーショングラフィクスストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、プレゼンテーショングラフィクスストリームは、映画の字幕をそれぞれ示している。図３は、ＡＶＣｌｉｐがどのように構成されているかを模式的に示す図である。
ＡＶＣｌｉｐは（中段）、複数のビデオフレーム（ピクチャｐｊ１，２，３）からなるビデオストリーム、複数のオーディオフレームからなるオーディオストリームを（上１段目）、ＰＥＳパケット列に変換し（上２段目）、更にＴＳパケットに変換し（上３段目）、同じくプレゼンテーショングラフィクスストリーム（下１段目）を、ＰＥＳパケット列に変換し（下２段目）、更にＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。
本図において多重されるプレゼンテーショングラフィクスストリームは１つであるが、ＢＤ−ＲＯＭが多言語対応型である場合、その言語毎のプレゼンテーショングラフィクスストリームがＡＶＣｌｉｐに多重される。かかる過程を経て生成されたＡＶＣｌｉｐは、通常のコンピュータファイル同様、複数のエクステントに分割され、ＢＤ−ＲＯＭ上の領域に記録される。
続いてプレゼンテーショングラフィクスストリームについて説明する。図４（ａ）は、プレゼンテーショングラフィクスストリームの構成を示す図である。第１段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。第２段目は、グラフィクスストリームを構成するＰＥＳパケット列を示す。第２段目におけるＰＥＳパケット列は、第１段目におけるＴＳパケットのうち、所定のＰＩＤをもつＴＳパケットからペイロードを取り出して、連結することにより構成される。
第３段目は、グラフィクスストリームの構成を示す。グラフィクスストリームは、ＰＣＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｃｏｍｐｏｓｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）、ＷＤＳ（Ｗｉｎｄｏｗ  Ｄｅｆｉｎｅ  Ｓｅｇｍｅｎｔ）、ＰＤＳ（Ｐａｌｅｔｔｅ  Ｄｉｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ）、ＯＤＳ（Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ）、ＥＮＤ（ＥＮＤ  ｏｆ  Ｄｉｓｐｌａｙ  Ｓｅｔ  Ｓｅｇｍｅｎｔ）と呼ばれる機能セグメントからなる。これらの機能セグメントのうち、ＰＣＳは、画面構成セグメントと呼ばれ、ＷＤＳ，ＰＤＳ，ＯＤＳ，ＥＮＤは定義セグメントと呼ばれる。ＰＥＳパケットと機能セグメントとの対応関係は、１対１の関係、１対多の関係である。つまり機能セグメントは、１つのＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録されるか、又は、フラグメント化され、複数ＰＥＳパケットに変換されてＢＤ−ＲＯＭに記録される。
図４（ｂ）は、機能セグメントを変換することで得られるＰＥＳパケットを示す図である。図４（ｂ）に示すようにＰＥＳパケットは、パケットヘッダと、ペイロードとからなり、このペイロードが機能セグメント実体にあたる。またパケットヘッダには、この機能セグメントに対応するＤＴＳ、ＰＴＳが存在する。尚以降の説明では、機能セグメントが格納されるＰＥＳパケットのヘッダ内に存在するＤＴＳ及びＰＴＳを、機能セグメントのＤＴＳ及びＰＴＳとして扱う。
これら様々な種別の機能セグメントは、図５のような論理構造を構築する。図５は、様々な種別の機能セグメントにて構成される論理構造を示す図である。本図は第３段目に機能セグメントを、第２段目にＤｉｓｐｌａｙ  Ｓｅｔを、第１段目にＥｐｏｃｈをそれぞれ示す。
第２段目のＤｉｓｐｌａｙ  Ｓｅｔ（ＤＳと略す）とは、グラフィクスストリームを構成する複数機能セグメントのうち、一画面分のグラフィクスを構成するものの集合をいう。図中の破線は、第３段目の機能セグメントが、どのＤＳに帰属しているかという帰属関係を示す。
ＰＣＳ−ＷＤＳ−ＰＤＳ−ＯＤＳ−ＥＮＤという一連の機能セグメントが、１つのＤＳを構成していることがわかる。再生装置は、このＤＳを構成する複数機能セグメントをＢＤ−ＲＯＭから読み出せば、一画面分のグラフィクスを構成することができる。
第１段目のＥｐｏｃｈとは、ＡＶＣｌｉｐの再生時間軸上においてメモリ管理の連続性をもっている一つの期間、及び、この期間に割り当てられたデータ群をいう。ここで想定しているメモリとは、一画面分のグラフィクスを格納しておくためのグラフィクスプレーン、伸長された状態のグラフィクスデータを格納しておくためのオブジェクトバッファである。これらについてのメモリ管理に、連続性があるというのは、このＥｐｏｃｈにあたる期間を通じてこれらグラフィクスプレーン及びオブジェクトバッファのフラッシュは発生せず、グラフィックスプレーン内のある決められた矩形領域内でのみ、グラフィクスの消去及び再描画が行われることをいう（※ここでフラッシュとは、プレーン及びバッファの格納内容を全部クリアしてしまうことである。）。この矩形領域の縦横の大きさ及び位置は、Ｅｐｏｃｈにあたる期間において、終始固定されている。グラフィックスプレーンにおいて、この固定化された領域内で、グラフィクスの消去及び再描画を行っている限り、映像とグラフィクスとの同期が保障される。つまりＥｐｏｃｈは、映像−グラフィクスの同期の保障が可能な再生時間軸上の一単位ということができる。グラフィックスプレーンにおいて、グラフィクスの消去・再描画を行うべき領域を変更したい場合は、再生時間軸上においてその変更時点を定義し、その変更時点以降を、新たなＥｐｏｃｈにせねばならない。この場合、２つのＥｐｏｃｈの境界では、映像−グラフィクスの同期は保証されない。
Ｅｐｏｃｈにおける字幕の位置関係にたとえれば、再生時間軸上において、画面上のある決まった矩形領域内に字幕が出現している期間が、Ｅｐｏｃｈということができる。図６は、字幕の表示位置と、Ｅｐｏｃｈとの関係を示す図である。本図では、動画の各ピクチャの絵柄に応じて字幕の位置を変更するという配慮がなされている。つまり５つの字幕「本当は」「ウソだった」「ごめん」「あれから」「３年がたった」のうち、３つの字幕「本当は」「ウソだった」「ごめん」は画面の下側に、「あれから」「３年がたった」は画面の上側に配置されている。これは画面の見易さを考え、画面中の余白にあたる位置に字幕を配置することを意図している。かかる時間的な変動がある場合、ＡＶＣｌｉｐの再生時間軸において、下側の余白に字幕が出現している期間が１つのＥｐｏｃｈ１、上側の余白に字幕が出現している期間が別のＥｐｏｃｈ２になる。これら２つのＥｐｏｃｈは、それぞれ独自の字幕の描画領域をもつことになる。Ｅｐｏｃｈ１では、画面の下側の余白が字幕の描画領域（ｗｉｎｄｏｗ１）になる。一方Ｅｐｏｃｈ２では、画面の上側の余白が字幕の描画領域（ｗｉｎｄｏｗ２）になる。これらのＥｐｏｃｈ１，２において、バッファ・プレーンにおけるメモリ管理の連続性は保証されているので、上述した余白での字幕表示はシームレスに行われる。以上がＥｐｏｃｈについての説明である。続いてＤｉｓｐｌａｙ  Ｓｅｔについて説明する。
図５における破線ｈｋ１，２は、第２段目の機能セグメントが、どのＥｐｏｃｈに帰属しているかという帰属関係を示す。Ｅｐｏｃｈ  Ｓｔａｒｔ，Ａｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔ，Ｎｏｒｍａｌ  Ｃａｓｅという一連のＤＳは、第１段目のＥｐｏｃｈを構成していることがわかる。『Ｅｐｏｃｈ  Ｓｔａｒｔ』、『Ａｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔ』、『Ｎｏｒｍａｌ  Ｃａｓｅ』は、ＤＳの類型である。本図におけるＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔ、Ｎｏｒｍａｌ  Ｃａｓｅの順序は、一例にすぎず、どちらが先であってもよい。
『Ｅｐｏｃｈ  Ｓｔａｒｔ』は、”新表示”という表示効果をもたらすＤＳであり、新たなＥｐｏｃｈの開始を示す。そのためＥｐｏｃｈ  Ｓｔａｒｔは、次の画面合成に必要な全ての機能セグメントを含んでいる。Ｅｐｏｃｈ  Ｓｔａｒｔは、映画作品におけるチャプター等、頭出しがなされることが判明している位置に配置される。
『Ａｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔ』は、”表示リフレッシュ”という表示効果をもたらすＤｉｓｐｌａｙ  Ｓｅｔであり、先行するＥｐｏｃｈ  Ｓｔａｒｔと全く同じＤｉｓｐｌａｙ  Ｓｅｔをいう。Ａｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔたるＤＳは、Ｅｐｏｃｈの開始時点ではないが、次の画面合成に必要な全ての機能セグメントを含んでいるので、Ａｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔたるＤＳから頭出しを行えば、グラフィックス表示を確実に実現することができる。つまりＡｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔたるＤＳは、Ｅｐｏｃｈの途中からの画面構成を可能するという役割をもつ。
Ａｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔたるＤｉｓｐｌａｙ  Ｓｅｔは、頭出し先になり得る位置に組み込まれる。そのような位置には、タイムサーチにより指定され得る位置がある。タイムサーチとは、何分何秒という時間入力をユーザから受け付けて、その時間入力に相当する再生時点から頭出しを行う操作である。かかる時間入力は、１０分単位、１０秒単位というように、大まかな単位でなされるので、１０分間隔の再生位置、１０秒間隔の再生位置がタイムサーチにより指定され得る位置になる。このようにタイムサーチにより指定され得る位置にＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔを設けておくことにより、タイムサーチ時のグラフィクスストリーム再生を好適に行うことができる。
『Ｎｏｒｍａｌ  Ｃａｓｅ』は、”表示アップデート”という表示効果をもたらすＤＳであり、前の画面合成からの差分のみを含む。例えば、あるＤＳｖの字幕は、先行するＤＳｕと同じ内容であるが、画面構成が、この先行するＤＳｕとは異なる場合、ＰＣＳと、ＥＮＤのみのＤＳｖを設けてこのＤＳｖをＮｏｒｍａｌ  ＣａｓｅのＤＳにする。こうすれば、重複するＯＤＳを設ける必要はなくなるので、ＢＤ−ＲＯＭにおける容量削減に寄与することができる。一方、Ｎｏｒｍａｌ  ＣａｓｅのＤＳは、差分にすぎないので、Ｎｏｒｍａｌ  Ｃａｓｅ単独では画面構成は行えない。
続いてＤｅｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ（ＯＤＳ，ＷＤＳ，ＰＤＳ）について説明する。
『Ｏｂｊｅｃｔ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｓｅｇｍｅｎｔ』は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトについて以下説明する。ＢＤ−ＲＯＭに記録されているＡＶＣｌｉｐは、ハイビジョン並みの高画質をセールスポイントにしているため、グラフィクスオブジェクトの解像度も、１９２０×１０８０画素という高精細な大きさに設定されている。１９２０×１０８０という解像度があるので、ＢＤ−ＲＯＭでは、劇場上映用の字幕の字体、つまり、手書きの味わい深い字体の字幕表示を鮮やかに再現できる。グラフィクスオブジェクトは複数のランレングスデータからなる。ランレングスデータとは、画素値を示すＰｉｘｅｌ  Ｃｏｄｅと、画素値の連続長とにより、画素列を表現したデータである。Ｐｉｘｅｌ  Ｃｏｄｅは、８ビットの値であり、１〜２５５の値をとる。ランレングスデータでは、このＰｉｘｅｌ  Ｃｏｄｅによりフルカラーの１６，７７７，２１６色から任意の２５６色を選んで画素の色として設定することができる。尚、字幕として表示される場合、グラフィクスオブジェクトは、透明色の背景に、文字列を配置することで描画せねばならない。
ＯＤＳによるグラフィクスオブジェクトの定義は、図７（ａ）に示すようなデータ構造をもってなされる。ＯＤＳは、図７（ａ）に示すように自身がＯＤＳであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、ＯＤＳのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、ＥｐｏｃｈにおいてこのＯＤＳに対応するグラフィクスオブジェクトを一意に識別する『ｏｂｊｅｃｔ＿ｉｄ』と、ＥｐｏｃｈにおけるＯＤＳのバージョンを示す『ｏｂｊｅｃｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、『ｌａｓｔ＿ｉｎ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇ』と、グラフィクスオブジェクトの一部又は全部である連続バイト長データ『ｏｂｊｅｃｔ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』とからなる。
『ｏｂｊｅｃｔ＿ｉｄ』は、ＯＤＳはデコードされて対応するグラフィクスオブジェクトがオブジェクトバッファ上に読み出された場合、このグラフィクスオブジェクトと、オブジェクトバッファにおいてこのグラフィクスオブジェクトが占有している領域とを一意に識別する識別子である。１つ以上のグラフィクスオブジェクトが格納された状態において、オブジェクトバッファのメモリ空間における個々の領域は、このｏｂｊｅｃｔ＿ｉｄにより識別されることになる。仮にあるｏｂｊｅｃｔ＿ｉｄが２つ以上のＤｉｓｐｌａｙ  Ｓｅｔに付加されている場合、先行するＯＤＳに対応するグラフィクスオブジェクトは、オブジェクトバッファに格納された後、同じｏｂｊｅｃｔ＿ｉｄを有する後続のグラフィクスオブジェクトにより上書きされることになる。かようなアップデートは、空き領域の虫食い状の発生や、グラフィクスオブジェクトの離散配置を避けるとの配慮である。その理由は以下の通りである。グラフィクス表示を行うため、オブジェクトバッファ上のグラフィクスオブジェクトは絶えずグラフィックスプレーンに転送されることになる。オブジェクトバッファ内に空き領域が虫食い状に発生したり、また同じｏｂｊｅｃｔ＿ｉｄをもったグラフィクスオブジェクトがバラバラにされて離散的に配置されると、グラフィクスオブジェクトを読み出すためのオーバヘッドが発生し、オブジェクトバッファ→グラフィックスプレーンの転送時にあたっての転送効率が落ちる。この効率低下は、グラフィクス−動画の同期表示に悪影響を及ぼしかねない。かかる事情から、オブジェクトバッファ上においてあるｏｂｊｅｃｔ＿ｉｄで識別されるグラフィクスオブジェクトが共有している領域は、同じ大きさと同じｏｂｊｅｃｔ＿ｉｄとをもったグラフィクスオブジェクトでのみ上書きできるとしている。
グラフィクスオブジェクト上書きにあたって、後続するグラフィクスオブジェクトのサイズは、先行するものと同じサイズでなければならない。先行するグラフィクスオブジェクトにより小さすぎてもいけないし、大き過ぎてもいけない。アップデートにあたってグラフィクスオブジェクトのサイズが同じになるようにグラフィクスオブジェクトを作成しておくというのは、オーサリング担当者にとっての責務になる。同じＩＤをもつグラフィクスオブジェクトの縦横サイズを同じにするとの制限は、１つのＥｐｏｃｈ内の制限に過ぎない。あるＥｐｏｃｈに属するグラフィクスオブジェクトと、次のＥｐｏｃｈに属するグラフィクスオブジェクトとでは縦横のサイズが変わっても良い。
『ｌａｓｔ＿ｉｎ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇ』、『ｏｂｊｅｃｔ＿ｄａｔａ＿ｆｒａｇｍｅｎｔ』について説明する。ＰＥＳパケットのペイロードの制限から、字幕を構成する非圧縮グラフィクスが１つのＯＤＳでは格納できない場合がある。そのような場合、グラフィクスを分割することにより得られた１部分（フラグメント）がｏｂｊｅｃｔ＿ｄａｔａ＿ｆｒａｇｍｅｎｔに設定される。１つのグラフィクスオブジェクトを複数ＯＤＳで格納する場合、最後のフラグメントを除く全てのフラグメントは同じサイズになる。つまり最後のフラグメントは、それ以前のフラグメントサイズ以下となる。これらフラグメントを格納したＯＤＳは、ＤＳにおいて同じ順序で出現する。グラフィクスオブジェクトの最後は、ｌａｓｔ＿ｉｎ＿ｓｅｑｕｅｎｃｅ＿ｆｌａｇをもつＯＤＳにより指示される。上述したＯＤＳのデータ構造は、前のＰＥＳパケットからフラグメントを詰めてゆく格納法を前提にしているが、各ＰＥＳパケットに空きが生じるように、詰めてゆくという格納法であっても良い。以上がＯＤＳの説明である。
『Ｐａｌｅｔｔｅ  Ｄｉｆｉｎｉｔｉｏｎ  Ｓｅｇｍｅｎｔ（ＰＤＳ）』は、色変換用のパレットを定義する情報である。パレットとは、１〜２５５のＰｉｘｅｌ  Ｃｏｄｅと、画素値との組合せを示すデータである。ここで画素値は、赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分（Ｙ値），透明度（Ｔ値）から構成される。各ランレングスデータが有するＰｉｘｅｌ  Ｃｏｄｅを、パレットに示される画素値に置き換えることで、ランレングスデータは発色されることになる。ＰＤＳのデータ構造を図７（ｂ）に示す。図７（ｂ）に示すようにＰＤＳは、自身がＰＤＳであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』、ＰＤＳのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』、このＰＤＳに含まれるパレットを一意に識別する『ｐａｌｌｅｔ＿ｉｄ』、ＥｐｏｃｈにおけるＥｐｏｃｈのＰＤＳのバージョンを示す『ｐａｌｌｅｔ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』、各エントリーについての情報『ｐａｌｌｅｔ＿ｅｎｔｒｙ』からなる。『ｐａｌｌｅｔ＿ｅｎｔｒｙ』は、各エントリーにおける赤色差成分（Ｃｒ値），青色差成分（Ｃｂ値），輝度成分Ｙ値，透明度（Ｔ値）を示す。
続いてＷＤＳについて説明する。
『ｗｉｎｄｏｗ＿ｄｅｆｉｎｉｔｉｏｎ＿ｓｅｇｍｅｎｔ』は、グラフィックスプレーンの矩形領域を定義するための機能セグメントである。Ｅｐｏｃｈでは、クリア及び再描画が、グラフィックスプレーンにおけるある矩形領域内で行われている場合のみ、メモリ管理に連続性が生ずることは既に述べている。このグラフィックスプレーンにおける矩形領域は”ｗｉｎｄｏｗ”と呼ばれ、このＷＤＳで定義される。図８（ａ）は、ＷＤＳのデータ構造を示す図である。本図に示すようにＷＤＳは、グラフィックスプレーンにおいてウィンドゥを一意に識別する『ｗｉｎｄｏｗ＿ｉｄ』と、グラフィックスプレーンにおける左上画素の水平位置を示す『ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおける左上画素の垂直位置を示す『ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』と、グラフィックスプレーンにおけるウィンドゥの横幅を示す『ｗｉｎｄｏｗ＿ｗｉｄｔｈ』と、グラフィックスプレーンにおける縦幅を示す『ｗｉｎｄｏｗ＿ｈｅｉｇｈｔ』とを用いて表現される。
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔがとりうる値について説明する。これらが想定している座標系は、グラフィックスプレーンの内部領域であり、このグラフィックスプレーンは、縦：ｖｉｄｅｏ＿ｈｅｉｇｈｔ、横：ｖｉｄｅｏ＿ｗｉｄｔｈという二次元状の大きさをもつ。
ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の水平アドレスであるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈの値をとり、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおける左上画素の垂直アドレスであるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔの値をとる。
ｗｉｎｄｏｗ＿ｗｉｄｔｈは、グラフィックスプレーンにおけるウィンドゥの横幅であるので、１〜ｖｉｄｅｏ＿ｗｉｄｔｈ−ｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎの値をとり、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、グラフィックスプレーンにおける縦幅であるので１〜ｖｉｄｅｏ＿ｈｅｉｇｈｔ−ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎの値をとる。
ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔにより、グラフィックスプレーンの何処にウィンドゥを配置するか、ウィンドゥの大きさをどれだけにするかをＥｐｏｃｈ毎に規定することができる。そのため、あるＥｐｏｃｈに属するピクチャが表示されている期間において、ピクチャ内の絵柄の邪魔にならないように、ピクチャ上の余白にあたる位置に、ウィンドゥが現れるようオーサリング時に調整しておくことができる。これによりグラフィクスによる字幕表示を見易くすることができる。ＷＤＳはＥｐｏｃｈ毎に定義可能なので、ピクチャの絵柄に時間的な変動があっても、その変動に応じて、グラフィクスを見易く表示することができる。そのため、結果として、字幕を映像本体に組み込むのと同じレベルにまで映画作品の品質を高めることができる。
続いて『ＥＮＤ  ｏｆ  Ｄｉｓｐｌａｙ  Ｓｅｔ  Ｓｅｇｍｅｎｔ』について説明する。ＥＮＤ  ｏｆ  Ｄｉｓｐｌａｙ  Ｓｅｔ  Ｓｅｇｍｅｎｔは、Ｄｉｓｐｌａｙ  Ｓｅｔの伝送の終わりを示す指標であり、Ｄｉｓｐｌａｙ  Ｓｅｔにおける機能セグメントのうち、最後のＯＤＳの直後に配置される。このＥＮＤ  ｏｆ  Ｄｉｓｐｌａｙ  ＳｅｔＳｅｇｍｅｎｔの内部構成は、自身がＥＮＤ  ｏｆ  Ｄｉｓｐｌａｙ  ＳｅｔＳｅｇｍｅｎｔであることを示す『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、当該機能セグメントのデータ長を示す『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』とからなり、これといって説明が必要な構成要素はない。故に図示は省略する。
以上がＯＤＳ、ＰＤＳ、ＷＤＳ、ＥＮＤについての説明である。続いてＰＣＳについて説明する。
ＰＣＳは、対話的な画面を構成する機能セグメントである。ＰＣＳは、図８（ｂ）に示すデータ構造で構成される。本図に示すようにＰＣＳは、『ｓｅｇｍｅｎｔ＿ｔｙｐｅ』と、『ｓｅｇｍｅｎｔ＿ｌｅｎｇｔｈ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』と、『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』と、『ｐａｌｌｅｔ＿ｉｄ』と、『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（１）〜（ｍ）』とから構成される。
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒ』は、０から１５までの数値を用いてＤｉｓｐｌａｙ  Ｓｅｔにおけるグラフィクスアップデートを識別する。どのように識別するかというと、Ｅｐｏｃｈの先頭から本ＰＣＳまでにグラフィクスアップデートが存在すれば、それらグラフィクスアップデートを経由する度に、インクリメントされるというルールでｃｏｍｐｏｓｉｔｉｏｎ＿ｎｕｍｂｅｒは設定される。
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ』は、本ＰＣＳから始まるＤｉｓｐｌａｙ  Ｓｅｔが、Ｎｏｒｍａｌ  Ｃａｓｅであるか、ＡＣｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔであるか、Ｅｐｏｃｈ  Ｓｔａｒｔであるかを示す。
『ｐａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇ』は、本ＰＣＳにおいてＰａｌｌｅｔＯｎｌｙ  Ｄｉｓｐｌｅｙ  Ｕｐｄａｔｅがなされているかどうかを示す。ＰａｌｌｅｔＯｎｌｙ  Ｄｉｓｐｌｅｙ  Ｕｐｄａｔｅとは、直前のパレットのみを新たなものに切り換えることでなされるアップデートをいう。本ＰＣＳでかかるアップデートがなされれば、本フィールドは”１”に設定される。
『ｐａｌｌｅｔ＿ｉｄ』は、ＰａｌｌｅｔＯｎｌｙ  Ｄｉｓｐｌｅｙ  Ｕｐｄａｔｅに用いられるべきパレットを示す。
『ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（１）・・・（ｎ）』は、このＰＣＳが属するＤｉｓｐｌａｙ  Ｓｅｔにおける画面構成を実現するための制御情報である。図８（ｂ）の破線ｗｄ１は、任意のｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）の内部構成をクローズアップしている。この破線ｗｄ１に示すように、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）は、『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』、『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』、『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』、『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』からなる。
『ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ』は、グラフィクスオブジェクト識別子（ｏｂｊｅｃｔ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、用いるべきグラフィクスオブジェクトの識別子を意味する。
『ｗｉｎｄｏｗ＿ｉｄ＿ｒｅｆ』は、ウィンドゥ識別子（ｗｉｎｄｏｗ＿ｉｄ）の参照値である。この参照値は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｏｂｊｅｃｔ（ｉ）に対応する画面構成を実現するにあたって、どのウィンドゥに、グラフィクスオブジェクトを表示させるべきかを示す。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』は、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトを表示するか、グラフィクスオブジェクトを非表示とするかを切り換えるフラグである。”１”と設定された場合、オブジェクトバッファにおいてクロップされたグラフィクスオブジェクトが表示され、”０”と設定された場合、グラフィクスオブジェクトは非表示となる。
『ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるグラフィクスオブジェクトの左上画素の水平位置を示す。
『ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおける左上画素の垂直位置を示す。
『ｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（１）（２）・・・・・（ｎ）』は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇ』が１に設定されている場合に有効となる情報要素である。破線ｗｄ２は、任意のｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）の内部構成をクローズアップしている。この破線に示すようにｃｒｏｐｐｉｎｇ＿ｒｅｃｔａｎｇｌｅ情報（ｉ）は、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ａｄｄｒｅｓｓ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』、『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』からなる。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の水平位置を示す。クロップ矩形は、グラフィクスオブジェクトの一部を切り出すための枠であり、ＥＴＳＩ  ＥＮ  ３００  ７４３標準規格における”Ｒｅｇｉｏｎ”に相当する。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ａｄｄｒｅｓｓ』は、グラフィックスプレーンにおけるクロップ矩形の左上画素の垂直位置を示す。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ』は、グラフィックスプレーンにおけるクロップ矩形の横幅を示す。
『ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ』は、グラフィックスプレーンにおけるクロップ矩形の縦幅を示す。
以上がＰＣＳのデータ構造である。続いてＰＣＳの具体的な記述について説明する。この具体例は、図６に示した字幕の表示、つまり動画の再生進行に伴い、三回のグラフィックスプレーンへの書き込みで『ほんとは』『ウソだった』『ごめん』というように徐々に表示させるというものである。図９は、かかる字幕表示を実現するための記述例である。本図におけるＥｐｏｃｈは、ＤＳ１（Ｅｐｏｃｈ  Ｓｔａｒｔ）、ＤＳ２（Ｎｏｒｍａｌ  Ｃａｓｅ）、ＤＳ３（Ｎｏｒｍａｌ  Ｃａｓｅ）を有する。ＤＳ１は、字幕の表示枠となるｗｉｎｄｏｗを定義するＷＤＳ、台詞『ほんとは  ウソだった  ごめん』を表すＯＤＳ、１つ目のＰＣＳを備える。ＤＳ２（Ｎｏｒｍａｌ  Ｃａｓｅ）は、２つ目のＰＣＳを有する。ＤＳ３（Ｎｏｒｍａｌ  Ｃａｓｅ）は３つ目のＰＣＳを有する。
次に個々のＰＣＳをどのように記述するかについて説明する。Ｄｉｓｐｌａｙ  Ｓｅｔに属するＷＤＳ、ＰＣＳの記述例を図１０〜図１２に示す。図１０は、ＤＳ１におけるＰＣＳの記述例を示す図である。
図１０において、ＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、グラフィックスプレーンにおけるウィンドゥの左上座標ＬＰ１を、ｗｉｎｄｏｗ＿ｗｉｄｔｈ，ｗｉｎｄｏｗ＿ｈｅｉｇｈｔは、ウィンドゥの表示枠の横幅、縦幅を示す。
図１０におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎは、オブジェクトバッファにおけるグラフィクスオブジェクトの左上座標を原点とした座標系においてクロップ範囲の基準ＳＴ１を示している。そして基準点からｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに示される範囲（図中の太枠部分）がクロップ範囲になる。クロップされたグラフィクスオブジェクトは、グラフィックスプレーンの座標系においてｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎを基準点（左上）とした破線の範囲ｃｐ１に配置される。こうすることにより、『本当は』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『本当は』は動画像と合成され表示される。
図１１（ａ）は、ＤＳ２におけるＰＣＳの記述例を示す図である。本図におけるＷＤＳの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１（ａ）におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ，は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ウソだった』の左上座標を示し、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈは、『ウソだった』の横幅、縦幅を示す。こうすることにより、『ウソだった』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ウソだった』は動画像と合成され表示される。
図１１（ｂ）は、ＤＳ３におけるＰＣＳの記述例を示す図である。本図におけるＷＤＳの記述は、図１０と同じなので説明を省略する。クロップ情報の記述は、図１０と異なる。図１１（ｂ）におけるクロップ情報のｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ，は、オブジェクトバッファ上の字幕『本当はウソだった。ごめん』のうち、『ごめん』の左上座標を示し、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈは、『ごめん』の横幅、縦幅を示す。こうすることにより、『ごめん』がグラフィックスプレーンにおけるウィンドゥ内に書き込まれる。これにより字幕『ごめん』は動画像と合成され表示される。  図１３は、図１０〜図１２に示すようなグラフィクスアップデートを実現するにあたっての、オブジェクトバッファにおけるメモリ空間を示す図である。本図に示すようにオブジェクトバッファは、縦幅、横幅、位置が固定された格納領域Ａ，Ｂ，Ｃ，Ｄが４つあり、このうち格納領域Ａに、図１１に示した字幕が格納される。これら４つの格納領域Ａ，Ｂ，Ｃ，Ｄのそれぞれには、格納されているグラフィクスオブジェクトに対応するｏｂｊｅｃｔ＿ｉｄにより識別される。つまりｏｂｊｅｃｔ＿ｉｄ＝１により格納領域Ａが、ｏｂｊｅｃｔ＿ｉｄ＝２により格納領域Ｂが、ｏｂｊｅｃｔ＿ｉｄ＝３により格納領域Ｃがそれぞれ識別されるのである。グラフィックスプレーンへの転送効率を維持するため、これら格納領域の縦幅、横幅は終始固定されている。同じｏｂｊｅｃｔ＿ｉｄをもったグラフィクスオブジェクトがデコードにより新たに得られれば、それらの格納領域はその新たに得られたグラフィクスオブジェクトにより上書きされる。例えば、図１０に示した字幕と同じ位置に、同じ大きさで字幕を表示させたい場合、後続するＤｉｓｐｌａｙ  Ｓｅｔにおいて、同じｏｂｊｅｃｔ＿ｉｄを付加したＯＤＳを設ければよい。このように同じｏｂｊｅｃｔ＿ｉｄを付加するだけで、オブジェクトバッファ上に存在するグラフィクスオブジェクトは、新たなグラフィクスオブジェクトで上書きされ、その新たなグラフィクスオブジェクトは、先のグラフィクスオブジェクトと同じ大きさ・同じ位置で表示されることになる。
表示効果実現にあたっての制約について説明する。なめらかな表示効果の実現には、ウィンドゥクリアと、ウィンドゥ再描画とが必要になる。ウィンドゥクリアと、ウィンドゥ再描画とをビデオフレームの時間間隔で実現する場合、オブジェクトバッファと、グラフィックスプレーンとの間の転送レートはどれだけ必要であろうか。
ここでウィンドゥをどれだけの大きさとするかの制限について検討する。オブジェクトバッファ−グラフィックスプレーン間の転送レートをＲｃとすると、ワーストケースでは、この転送レートＲｃでウィンドゥクリアと、ウィンドゥ再描画とを行わねばならない。そうするとウィンドゥクリア、ウィンドゥ再描画のそれぞれをＲｃの半分の転送レート（Ｒｃ／２）で実現せねばならない。
これらウィンドゥクリア−ウィンドゥ再描画をビデオフレームと同期させるには、
ウィンドゥサイズ×フレームレート≒Ｒｃ／２
を満たす必要がある。このフレームレートが２９．９７であるなら、
Ｒｃは、ウィンドゥサイズ×２×２９．９７になる。
字幕の表示にあたっては、グラフィックスプレーン全体に対し、最低でも２５％〜３３％程度の大きさが必要となる。ここでグラフィックスプレーンの総画素数は１９２０×１０８０であり、一画素当たりのインデックスのビット長を８ビットとすると、グラフィックスプレーンの総容量は２Ｍバイト（≒１９２０×１０８０×８）になる。
この総容量の１／４をウィンドゥサイズとすると、５００ｋバイト（＝２Ｍバイト／４）になる。これを上述した式に代入してＲｃを導けば、Ｒｃは２５６Ｍｂｐｓ（５００Ｋバイト×２×２９．９７）と算出することができる。
この２５％〜３３％という大きさであれば、２５６Ｍｂｐｓという転送レートで字幕の表示を行っている限り、如何なる表示効果を実現する場合であっても、動画との同期を維持することができる。
仮に、ウィンドゥクリア及び再描画のレートがビデオフレームのフレームレートの１／２，１／４でよいなら、Ｒｃがたとえ同じであってもウィンドゥサイズを２倍，４倍にすることができる。以上がｗｉｎｄｏｗの大きさについての説明である。続いて、ｗｉｎｄｏｗの位置、範囲について説明する。上述したように、Ｅｐｏｃｈにおいてウィンドゥの位置、範囲は一貫している。
Ｅｐｏｃｈにおいてウィンドゥの位置、範囲を一貫させておくのは以下の理由による。ウィンドゥの位置・範囲を変えれば、グラフィックスプレーンに対する書込先アドレスを変えねばならず、オーバーヘッドが発生するので、かかるオーバーヘッドによりオブジェクトバッファからグラフィックスプレーンへの転送レートが低下するからである。
ウィンドゥには、グラフィクスオブジェクトの個数が制限されている。この個数制限は、デコードされたグラフィクスオブジェクトの転送にあたってのオーバーヘッドを低減する目的で設けられている。ここでのオーバーヘッドは、グラフィクスオブジェクトのエッジ部分のアドレスを設定する際に発生する。そうすれば、エッジの部分が多く存在する程、オーバーヘッドの発生回数が多くなる。
ウィンドゥにおけるグラフィクスオブジェクトの数に制限がないと、グラフィクス転送にあたって発生するオーバーヘッド数が未知数になり、転送負荷の増減が激しくなる。一方、ウィンドゥにおけるグラフィクスの個数が２つまでであると、最悪４つのオーバーヘッドが発生すると見込んで転送レートを設定すればよいので、ミニマムスタンダードたる転送レートを数値化し易くなる。
以上がウィンドゥについての説明である。続いてこれらＰＣＳ、ＯＤＳを有したＤｉｓｐｌａｙ  Ｓｅｔが、ＡＶＣｌｉｐの再生時間軸上にどのように割り当てられるかについて説明する。Ｅｐｏｃｈは、再生時間軸上においてメモリ管理が連続する期間であり、Ｅｐｏｃｈは１つ以上のＤｉｓｐｌａｙ  Ｓｅｔから構成されるので、Ｄｉｓｐｌａｙ  ＳｅｔをどうやってＡＶＣｌｉｐの再生時間軸に割り当てるかが問題になる。ここでＡＶＣｌｉｐの再生時間軸とは、ＡＶＣｌｉｐに多重されたビデオストリームを構成する個々のピクチャデータのデコードタイミング、再生タイミングを規定するために想定される時間軸をいう。この再生時間軸においてデコードタイミング、再生タイミングは、９０ＫＨｚの時間精度で表現される。Ｄｉｓｐｌａｙ  Ｓｅｔ内のＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳは、この再生時間軸において同期制御を実現すべきタイミングを示す。このＰＣＳ、ＯＤＳに付加されたＤＴＳ、ＰＴＳを用いて同期制御を行うことが、再生時間軸へのＤｉｓｐｌａｙ  Ｓｅｔの割り当てである。
先ず、ＯＤＳに付加されたＤＴＳ、ＰＴＳにより、どのような同期制御がなされるかについて説明する。
ＤＴＳは、ＯＤＳのデコードを開始すべき時間を９０ＫＨｚの時間精度で示しており、ＰＴＳはデコード終了時刻を示す。
ＯＤＳのデコードは、瞬時には完了せず、時間的な長さをもっている。このデコード期間の開始点・終了点を明らかにしたいとの要望から、ＯＤＳについてのＤＴＳ、ＰＴＳはデコード開始時刻、デコード終了時刻を示している。
ＰＴＳの値はデッドラインであるので、ＰＴＳに示される時刻までにＯＤＳのデコードがなされて、非圧縮状態のグラフィックオブジェクトが、再生装置上のオブジェクトバッファに得られなければならない。
ＤＳｎに属する任意のＯＤＳｊのデコード開始時刻は、９０ＫＨｚの時間精度でＤＴＳ（ＤＳｎ［ＯＤＳｊ］）に示されるので、これにデコードを要する最長時間を加えた時刻が、Ｄｉｓｐｌａｙ  ＳｅｔのＯＤＳｊのデコード終了時刻になる。
ＯＤＳｊのサイズを”ＳＩＺＥ（ＤＳｎ［ＯＤＳｊ］）”、ＯＤＳのデコードレートを”Ｒｄ”とすると、デコードに要する最長時間（秒）は、”ＳＩＺＥ（ＤＳｎ［ＯＤＳｊ］）／／Ｒｄ”になる。ここで”／／”は、小数点以下切り上げの割り算を示す演算子である。
この最長時間を９０ＫＨｚの時間精度に変換し、ＯＤＳｊのＤＴＳに加算することにより、ＰＴＳで示されるべきデコード終了時刻（９０ＫＨｚ）は算出される。
ＤＳｎに属するＯＤＳｊのＰＴＳを、数式で表すと、以下の式のようになる。
ＰＴＳ（ＤＳ［ＯＤＳｊ］）＝ＤＴＳ（ＤＳｎ［ＯＤＳｊ］）＋９０，０００×（ＳＩＺＥ（ＤＳｎ［ＯＤＳｊ］）／／Ｒｄ）
そして互いに隣接する２つのＯＤＳ（ＯＤＳｊ，ＯＤＳｊ＋１）との間では、以下の関係を満たす必要がある。
ＰＴＳ（ＤＳｎ［ＯＤＳｊ］）≦ＤＴＳ（ＤＳｎ［ＯＤＳｊ＋１］）
またＤＳｎに属するＥＮＤは、ＤＳｎの終わりを示すものだから、ＤＳｎに属する最後のＯＤＳ（ＯＤＳｌａｓｔ）のデコード終了時刻を示せばよい。このデコード終了時刻は、ＯＤＳ２（ＯＤＳｌａｓｔ）のＰＴＳ（ＰＴＳ（ＤＳｎ［ＯＤＳｌａｓｔ］））に示されているので、ＥＮＤのＰＴＳは、以下の式に示される値に設定される。
ＰＴＳ（ＤＳｎ［ＥＮＤ］）＝ＰＴＳ（ＤＳｎ［ＯＤＳｌａｓｔ］）
続いてＰＣＳのＤＴＳ、ＰＴＳの設定について説明する。
ＰＣＳのＤＴＳ値は、ＤＳｎにおける最初のＯＤＳ（ＯＤＳ１）のデコード開始時点か、それ以前の時点を示す。何故ならＰＣＳは、ＤＳｎにおける最初のＯＤＳ（ＯＤＳ１）のデコード開始時点（ＤＴＳ（ＤＳｎ［ＯＤＳ１］））、及び、ＤＳｎにおける最初のＰＤＳ（ＰＤＳ１）が有効になる時点（ＰＴＳ（ＤＳｎ［ＰＤＳ１］））と同時か、又はそれ以前に、再生装置上のバッファにロードされねばならないからである。よって以下の式の関係を満たす値に、設定されねばならない。
］ＤＴＳ（ＤＳｎ［ＰＣＳ］）≦ＤＴＳ（ＤＳｎ［ＯＤＳ１］）
ＤＴＳ（ＤＳｎ［ＰＣＳ］）≦ＰＴＳ（ＤＳｎ［ＰＤＳ１］）
そしてＤＳｎにおけるＰＣＳのＰＴＳは、以下の数式から算出される。
ＰＴＳ（ＤＳｎ［ＰＣＳ］）≧ＤＴＳ（ＤＳｎ［ＰＣＳ］）＋ｄｅｃｏｄｅｄｕｒａｔｉｏｎ（ＤＳｎ）
ここでｄｅｃｏｄｅｄｕｒａｔｉｏｎ（ＤＳｎ）は、ＰＣＳのアップデートに用いられる全グラフィクスオブジェクトのデコード及び表示に要する時間である。このデコード時間は、固定値ではない。しかし各再生装置の状態や再生装置の実装により変動するものでもない。本ＤＳｎ．ＰＣＳｎの画面合成に用いられるオブジェクトをＤＳｎ．ＰＣＳｎ．ＯＢＪ［ｊ］とした場合、ｄｅｃｏｄｅｄｕｒａｔｉｏｎ（ＤＳｎ）は、ウィンドゥクリアに要する時間（ｉ）、ＤＳｎ．ＰＣＳｎ．ＯＢＪのデコード期間（ｉｉ）、ＤＳｎ．ＰＣＳｎ．ＯＢＪの書き込みに要する時間（ｉｉｉ）により変動を受ける値になる。Ｒｄ，Ｒｃさえ予め定められていれば、どのような実装の再生装置であっても、同じ値になる。そのためオーサリング時にあたっては、これらの期間の長さを算出して、この値からＰＴＳを計算している。
ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎの計算は、図１４のプログラムに基づき行われる。また図１５、図１６（ａ）（ｂ）は、このプログラムのアルゴリズムを図式化したフローチャートである。以降、これらの図を参照しながらｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎの算出について説明する。図１５のフローチャートにおいて、先ず初めに、ＰＬＡＮＥＩＮＩＴＩＡＬＩＺＡＴＩＮＴＩＭＥ関数を呼び出し、戻り値をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加算する（図１５のステップＳ１）。ＰＬＡＮＥＩＮＩＴＩＡＬＩＺＡＴＩＮＴＩＭＥ関数（図１６（ａ））は、Ｄｉｓｐｌａｙ  Ｓｅｔを表示するにあたってグラフィックスプレーンの初期化に要する時間を求める関数を呼出すための関数であり、図１５のステップＳ１では、ＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［０］，ｄｅｃｏｄｅ＿ｄｕｒｔａｔｉｏｎを引数に設定して、この関数を呼び出す。
続いて図１６（ａ）を参照しながらＰＬＡＮＥＩＮＩＴＩＡＬＩＺＡＴＩＮＴＩＭＥ関数について説明する。図１６（ａ）においてｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎとは、ＰＬＡＮＥＩＮＩＴＩＡＬＩＺＡＴＩＮＴＩＭＥ関数の戻り値を示す変数である。
図１６のステップＳ２は、ＤＳｎのＰＣＳにおけるｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＥｐｏｃｈ  Ｓｔａｒｔかどうかにより、処理を切り換えるｉｆ文である。もしｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＥｐｏｃｈ  Ｓｔａｒｔであるなら（図１４のＤＳｎ．ＰＣＳ．ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅ＝＝ＥＰＯＣＨ＿ＳＴＡＲＴ、ステップＳ２＝Ｙｅｓ）、グラフィックスプレーンのクリアに要する時間をｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎに設定する（ステップＳ３）。
オブジェクトバッファ−グラフィックスプレーン間の転送レートＲｃを上述したように２５６，０００，０００とし、グラフィックスプレーンの総サイズをｖｉｄｅｏ＿ｗｉｄｔｈ＊ｖｉｄｅｏ＿ｈｅｉｇｈｔとすると、クリアに要する時間（秒）は、「ｖｉｄｅｏ＿ｗｉｄｔｈ＊ｖｉｄｅｏ＿ｈｅｉｇｈｔ／／２５６，０００，０００」になる。これに、９０，０００Ｈｚを乗じＰＴＳの時間精度で表現すれば、グラフィックスプレーンのクリアに要する時間は「９００００×ｖｉｄｅｏ＿ｗｉｄｔｈ＊ｖｉｄｅｏ＿ｈｅｉｇｈｔ／／２５６，０００，０００」になる。この時間を、ｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎに加えて、ｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎを戻り値としてリターンする。
もしｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＥｐｏｃｈ  Ｓｔａｒｔでないなら（ステップＳ２＝Ｎｏ）、ＷＤＳにて定義されるｗｉｎｄｏｗ［ｉ］のクリアに要する時間をｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎに加えるという処理を全てのｗｉｎｄｏｗについて繰り返す（ステップＳ４）。オブジェクトバッファ−グラフィックスプレーン間の転送レートＲｃを上述したように２５６，０００，０００とし、ＷＤＳに属するウィンドゥ［ｉ］の総サイズをΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）とすると、クリアに要する時間（秒）は、「ΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）／／２５６，０００，０００」になる。これに、９０，０００Ｈｚを乗じＰＴＳの時間精度で表現すれば、ＷＤＳに属する全ウィンドゥのクリアに要する時間は「９００００×ΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］））／／２５６，０００，０００」になる。この時間を、ｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎに加えて、ｉｎｉｔｉａｌｉｚｅ＿ｄｕｒａｔｉｏｎを戻り値としてリターンする。以上がＰＬＡＮＥＩＮＩＴＩＡＬＩＺＡＴＩＮＴＩＭＥ関数である。
図１５のステップＳ５は、ＤＳｎに属するグラフィクスオブジェクトの数が２であるか、１であるかで処理を切り換えるものであり（図１４のｉｆ（ＤＳｎ．ＰＣＳ．ｎｕｍ＿ｏｆ＿ｏｂｊｅｃｔ＝＝２），ｉｆ（ＤＳｎ．ＰＣＳ．ｎｕｍ＿ｏｆ＿ｏｂｊｅｃｔ＝＝１））、もし”１”であるなら（ステップＳ５＝１）、グラフィクスオブジェクトのデコードを行うための待ち時間をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加える（ステップＳ６）。この待ち時間の算出は、ＷＡＩＴ関数の呼出（図１４のｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎ＋＝ＷＡＩＴ（ＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［０］，ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎ））で実現される。この関数呼出にあたっての引数はＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［０］，ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎであり、待ち時間を示すｗａｉｔ＿ｄｕｒａｔｉｏｎが戻り値として返される。
図１６（ｂ）は、ＷＡＩＴ関数の処理手順を示すフローチャートである。
このＷＡＩＴ関数においてｃｕｒｒｅｎｔ＿ｄｕｒａｔｉｏｎとは、呼出元のｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎが設定される。ｏｂｊｅｃｔ＿ｄｅｆｉｎｅ＿ｒｅａｄｙ＿ｔｉｍｅは、Ｄｉｓｐｌａｙ  Ｓｅｔのグラフィクスオブジェクト［ｉ］のＰＴＳが設定される変数である。
ｃｕｒｒｅｎｔ＿ｔｉｍｅとは、ＤＳｎのＰＣＳのＤＴＳに、ｃｕｒｒｅｎｔ＿ｄｕｒａｔｉｏｎを足した値が設定される変数である。このｃｕｒｒｅｎｔ＿ｔｉｍｅよりｏｂｊｅｃｔ＿ｄｅｆｉｎｅ＿ｒｅａｄｙ＿ｔｉｍｅが大きい場合（ステップＳ７がＹｅｓ、ｉｆ（ｃｕｒｒｅｎｔ＿ｔｉｍｅ〈ｏｂｊｅｃｔ＿ｄｅｆｉｎｅ＿ｒｅａｄｙ＿ｔｉｍｅ））、戻り値たるｗａｉｔ＿ｄｕｒａｔｉｏｎは、ｏｂｊｅｃｔ＿ｄｅｆｉｎｅ＿ｒｅａｄｙ＿ｔｉｍｅとｃｕｒｒｅｎｔ＿ｔｉｍｅとの差分が設定されることになる（ステップＳ８、ｗａｉｔ＿ｄｕｒａｔｉｏｎ＋＝ｏｂｊｅｃｔ＿ｄｅｆｉｎｅ＿ｒｅａｄｙ＿ｔｉｍｅ−ｃｕｒｒｅｎｔ＿ｔｉｍｅ）。以上がＷａｉｔ関数である。ステップＳ６においてｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎには、このｗａｉｔ関数の戻り値と、ＯＢＪ［０］をｗｉｎｄｏｗに描画するのに必要な時間を足し合わせた時間（９０，０００＊（ＳＩＺＥ（ＤＳｎ．ＷＤＳ．ＷＩＮ［０］））／／２５６，０００，０００）が設定されることになる（ステップＳ９）。
以上はＤＳｎのグラフィクスオブジェクトが１つである場合の処理である。図１５のステップＳ５は、グラフィクスオブジェクトの数が２であるかどうかを判定している。ＤＳｎのグラフィクスオブジェクトが２以上であれば（図１４のｉｆ（ＤＳｎ．ＰＣＳ．ｎｕｍ＿ｏｆ＿ｏｂｊｅｃｔ＝＝２））、ＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［０］，ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎを引数として、ｗａｉｔ関数を呼び出し、その戻り値をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加算する（ステップＳ１０）。
続くステップＳ１１は、ＤＳｎのＯＢＪ［０］が属するｗｉｎｄｏｗが、グラフィクスオブジェクト［１］が属するｗｉｎｄｏｗと同一かどうかの判定であり（ｉｆ（ＤＳｎ．ＰＣＳ．ＯＢＪ［０］．ｗｉｎｄｏｗ＿ｉｄ＝＝ＤＳｎ．ＰＣＳ．ＯＢＪ［１］．ｗｉｎｄｏｗ＿ｉｄ）、もし同一であるなら、ＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［１］，ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎを引数にしてｗａｉｔ関数を呼び出し、その戻り値ｗａｉｔ＿ｄｕｒａｔｉｏｎを、ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加算する（ステップＳ１２）。ＯＢＪ［０］が属するｗｉｎｄｏｗの再描画に必要な時間（９０，０００＊（ＳＩＺＥ（ＤＳｎ．ＷＤＳ．ＯＢＪ［０］．ｗｉｎｄｏｗ＿ｉｄ）／／２５６，０００，０００）をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加える（ステップＳ１３）。
もし属するｗｉｎｄｏｗが異なるなら（ステップＳ１１で”異なる”）、ＯＢＪ［０］が属するｗｉｎｄｏｗの再描画に必要な時間（９０，０００＊（ＳＩＺＥ（ＤＳｎ．ＷＤＳ．ＯＢＪ［０］．ｗｉｎｄｏｗ＿ｉｄ）／／２５６，０００，０００）をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加える（ステップＳ１５）。
ＤＳｎ，ＤＳｎ．ＰＣＳ．ＯＢＪ［１］，ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎを引数にしてｗａｉｔ関数を呼び出し、その戻り値ｗａｉｔ＿ｄｕｒａｔｉｏｎを、ｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加算する（ステップＳ１６）。その後、ＯＢＪ［１］が属するｗｉｎｄｏｗの再描画に必要な時間（９０，０００＊（ＳＩＺＥ（ＤＳｎ．ＷＤＳ．ＯＢＪ［１］．ｗｉｎｄｏｗ＿ｉｄ）／／２５６，０００，０００）をｄｅｃｏｄｅ＿ｄｕｒａｔｉｏｎに加える（ステップＳ１７）。
以上のアルゴリズムにより、Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎは算出される。このＰＣＳのＰＴＳが、具体的にどのように設定されるかについて説明する。
図１７（ａ）は、１つのｗｉｎｄｏｗに１つのＯＤＳが存在するケースを想定した図である。図１７（ｂ）（ｃ）は、図１４で引用した各数値の時間的な前後関係を示すタイミングチャートである。本チャートには３つの段があり、これらの段のうち、”グラフィックスプレーンアクセス”の段、”ＯＤＳデコード”の段は、再生時にパラレルになされる２つの処理を示す。上述したアルゴリズムは、これらの２つの処理のパラレル実行を想定している。
グラフィックスプレーンアクセスは、クリア期間（１）、書き込み期間（３）からなる。このクリア期間（１）は、グラフィックスプレーン全体のクリアに要する期間（９０，０００×（グラフィックスプレーンのサイズ／／２５６，０００，０００））、グラフィックスプレーンにおける全ｗｉｎｄｏｗのクリアに要する時間（Σ（９０，０００×（ｗｉｎｄｏｗ［ｉ］のサイズ／／２５６，０００，０００）））のどちらかを意味する。
書き込み期間（３）は、ｗｉｎｄｏｗ全体描画に要する期間（９０，０００×（ｗｉｎｄｏｗサイズ／／２５６，０００，０００））を意味する。
一方、デコード期間（２）は、ＯＤＳのＤＴＳからＰＴＳまでに示される期間を意味する。  これらクリア期間（１）〜書き込み期間（３）は、クリアすべき範囲、デコードすべきＯＤＳのサイズ、グラフィックスプレーンに書き込むべきグラフィクスオブジェクトのサイズにより変化し得る。本図では、説明の簡略化のため、ＯＤＳのデコード期間（２）の始点は、クリア期間（１）の始点と同一であると仮定している。
図１７（ｂ）はデコード期間（２）が長くなるケースであり、Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはデコード期間（２）＋書き込み期間（３）になる。
図１７（ｃ）は、クリア期間（１）が長くなるケースであり、Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはクリア期間（１）＋書き込み期間（３）の期間がＤｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎになる。
図１８（ａ）〜（ｃ）は、１つのｗｉｎｄｏｗに２つのＯＤＳが存在するケースを想定した図である。本図（ｂ）（ｃ）におけるデコード期間（２）は、２つのグラフィクスのデコードに要する期間の総和を意味する。グラフィクス書込期間（３）も、２つのグラフィクスをグラフィックスプレーンに書き込む期間の総和を意味する。ＯＤＳが２つになっているものの、図１７と同様に考えればＤｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎを算出することができる。２つのＯＤＳをデコードするためのデコード期間（２）が長い場合は、図１８（ｂ）に示すようにＤｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはデコード期間（２）＋書き込み期間（３）に算出されることになる。
クリア期間（１）が長い場合は、図１８（ｃ）に示すように、Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはクリア期間（１）＋書き込み期間（３）となる。
図１９（ａ）は、２つのｗｉｎｄｏｗのそれぞれに、ＯＤＳが１つずつ存在するケースを想定している。この場合でもクリア期間（１）が、２つのＯＤＳをデコードするための総デコード期間（２）より長い場合、Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはクリア期間（１）＋書き込み期間（３）になる。問題は、クリア期間（１）がデコード期間（２）より短くなるケースである。この場合デコード期間（２）の経過を待たずに、１つ目のｗｉｎｄｏｗへの書き込みは可能になる。そのためクリア期間（１）＋書き込み期間（３）、デコード期間（２）＋書き込み期間（３）の長さにはならない。ここで１つ目のＯＤＳのデコードに要する期間を書込期間（３１）、２つ目のＯＤＳのデコードに要する期間を書込期間（３２）とする。図１９（ｂ）は、デコード期間（２）がクリア期間（１）＋書込期間（３１）より長くなるケースを示す。この場合Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎは、デコード期間（２）＋書込期間（３２）になる。
図１９（ｃ）は、クリア期間（１）＋書込期間（３１）がデコード期間（２）より長くなるケースを示す。この場合Ｄｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎはクリア期間（１）＋書込期間（３１）＋書込期間（３２）になる。
グラフィックスプレーンのサイズは、プレーヤモデルから予め判明しており、またｗｉｎｄｏｗのサイズ、ＯＤＳのサイズ、個数もオーサリングの段階で判明しているので、これらからＤｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎがクリア期間（１）＋書き込み期間（３）、デコード期間（２）＋書き込み期間（３）、デコード期間（２）＋書込期間（３２）、クリア期間（１）＋書込期間（３１）＋書込期間（３２）のどれかになる。こうしたＤｅｃｏｄｅ＿Ｄｕｒａｔｉｏｎ算出を基にＰＣＳのＰＴＳを設定すれば、ピクチャデータとの同期表示を高い時間精度で実現することができる。このような高精度な同期制御は、ｗｉｎｄｏｗを定義し、クリア・再描画する範囲を、このｗｉｎｄｏｗに限定することで成り立っているので、オーサリングの環境に、このｗｉｎｄｏｗの概念を導入したことの意義は大きい。
続いてＤＳｎにおけるＷＤＳのＤＴＳ、ＰＴＳの設定について説明する。ＷＤＳのＤＴＳは、以下の数式を満たすように設定すればよい。
ＤＴＳ（ＤＳｎ［ＷＤＳ］）≧ＤＴＳ（ＤＳｎ［ＰＣＳ］）
一方、ＤＳｎにおけるＷＤＳのＰＴＳは、グラフィックスプレーンに対する書き込みを開始すべきデッドラインを示す。グラフィックスプレーンへの書き込みは、ウィンドゥだけで足りるので、ＰＣＳのＰＴＳに示される時刻から、ＷＤＳの書き込みに要する期間を差し引けば、グラフィックスプレーンへの書き込みを開始すべき時刻は定まる。ＷＤＳの総サイズをΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）とすれば、これのクリア及び再描画に要する時間は、『ΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）／／２５６，０００，０００』になる。そして、これを９０．０００ＫＨｚの時間精度で表現すると『９００００×ΣＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）／／２５６，０００，０００』になる。
故に以下の数式から、ＷＤＳのＰＴＳを算出すればよい。
ＰＴＳ（ＤＳｎ［ＷＤＳ］）＝ＰＴＳ（ＤＳｎ［ＰＣＳ］）−９００００×Σ
ＳＩＺＥ（ＷＤＳ．ＷＩＮ［ｉ］）／／２５６，０００，０００
このＷＤＳに示されるＰＴＳはデッドラインなので、これより早い時点からグラフィックスプレーンの書き込みを開始してもよい。つまり図１９に示すように、２つのウィンドゥのうち、１つのウィンドゥに表示させるべきＯＤＳのデコードが完了したなら、その時点からデコードにより得られたグラフィクスオブジェクトの書き込みを開始してもよい。
このようにＷＤＳに付加されたＤＴＳ、ＰＴＳを用いてＡＶＣｌｉｐの再生時間軸の任意の時点に、ウィンドゥを割り当てることができる。
以上がＰＣＳ、ＷＤＳのＤＴＳ、ＰＴＳの説明である。
続いてＰＣＳによる前方参照について説明する。前方参照とは、前もって再生装置のメモリに読み込まれたグラフィクスオブジェクトを参照した再生制御をいう。図２０は、前方参照を行うＰＣＳを描いた図である。本図では、ＤＳｎ、ＤＳｎ＋１、ＤＳｎ＋２という３つのＤｉｓｐｌａｙ  Ｓｅｔが描かれている。この中でＤＳｎ＋１、ＤＳｎ＋２に属するＰＣＳが「前方参照を行うＰＣＳ」である。本図の矢印ｙｙ１，ｙｙ２は、ＰＣＳにおける前方参照を象徴的に示す。かかる前方参照において参照先になっているグラフィクスオブジェクトは、ＤＳｎ内のＯＤＳ＃１〜＃ｖにより定義されるグラフィクスオブジェクトである。ここでＤＳｎは、ＯＤＳ＃１〜＃ｕ、ＯＤＳ＃ｕ＋１〜＃ｖという複数のグラフィクスオブジェクトを含む。このうちＤＳｎ内のＰＣＳにより参照されているのは、ＯＤＳ＃１〜＃ｕであり、ＯＤＳ＃ｕ＋１〜＃ｖは参照されていない。つまりＤＳｎ内の非参照グラフィクスオブジェクトが前方参照されているのである。
以上のような前方参照では、ＰＣＳにより参照されているグラフィクスオブジェクトが前もって再生装置に読み込まれているので、同じＤｉｓｐｌａｙ  Ｓｅｔに属するＯＤＳのデコードを待つ必要が無い。ＰＣＳを新たに送り込むだけで、そのＰＣＳに基づく表示制御を再生装置に実行させることができる。ＰＣＳの読み込みに即応した表示制御が可能であるため、既に表示されているグラフィクスを、新たなグラフィクスを用いて更新するというグラフィクス更新を短い時間間隔で実行することができる。そして短い時間間隔でのグラフィクス更新を繰り返せば、動画像の再生進行と共にグラフィクスを滑らかに動かすという表示制御が可能になる。前方参照型のＰＣＳにおける２つの記述例について説明する。
先ず初めに、画面上でグラフィクスが動きまわるような表示効果を実現するにあたってのＰＣＳの記述について説明する。図２１（ａ）は、かかる表示効果を実現するＥｐｏｃｈを示す図である。本Ｅｐｏｃｈは、９つのＤｉｓｐｌａｙ  Ｓｅｔ（ＤＳ０〜ＤＳ８）からなり、先頭のＤＳ０は、ＰＣＳ、ＰＤＳ、ＯＤＳを含む。ＤＳ０内のＯＤＳは、図２２（ａ）に示すような字幕「心が揺れる」を定義するものであり、ｏｂｊｅｃｔ＿ｉｄ＝１が付されている。後続するＤＳ１〜ＤＳ８は、ＰＣＳのみを含む。
図２１（ｂ）は、ＤＳ１〜ＤＳ８に含まれるＰＣＳの内容と、ＰＴＳ値とを示す図である。本図に示すようにＤＳ１〜ＤＳ８に属するＰＣＳ内の内容は、ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ＝１のグラフィクスオブジェクトを座標（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）に表示するよう、ｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｖｃａｌ＿ｐｏｓｉｔｉｏｎの位置決めがなされている。これら座標（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）が、ウィンドゥの座標系のどこに存在するかを、具体的に示したのが図２２（ｂ）である。図２２（ｂ）において座標（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）は、波形を表す曲線上に存在していることがわかる。これら（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）という座標値は、ＷＤＳにて定義されるウィンドゥ内に、グラフィクスが収まるように規定されている。ウィンドゥ内に、グラフィクスが収まらないと、ビデオストリームにおける動画表示との同期を確立することができないからである。
図２１（ｂ）におけるＰＣＳのＰＴＳ値は、座標（ｘ１，ｙ１）（ｘ２，ｙ２）（ｘ３，ｙ３）・・・（ｘ８，ｙ８）に対する表示を、再生時間軸上の時点ｔ１，ｔ２，ｔ３・・・・ｔ８のタイミングで命じるものである。
以上のように、ＰＣＳの内容が規定されたＤＳ０〜ＤＳ８を順次再生装置に読み込んでゆくことにより、グラフィクスは、図２３のような表示効果をなす。動画ストリームの再生時間軸における時点ｔ１において、再生装置にはＤＳ１が読み込まれるので、ウィンドゥ内の座標（ｘ１，ｙ１）にグラフィクスが表示される。時点ｔ４において再生装置にはＤＳ４が読み込まれるので座標（ｘ４，ｙ４）にグラフィクスが表示されることになる。一方時点ｔ６では、ＤＳ６が読み込まれるので座標（ｘ６，ｙ６）に、時点ｔ８ではＤＳ８が読み込まれるので座標（ｘ８，ｙ８）にグラフィクスが表示されることになる。これらの座標（ｘ１，ｙ１），（ｘ４，ｙ４），（ｘ６，ｙ６），（ｘ８，ｙ８）は、波形の曲線上に存在するので、かかる座標に表示位置の位置決めがなされたＰＣＳにより、グラフィクスは、図２４に示すように波形の軌道を描くことになる。
以上のようにｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｖｃａｌ＿ｐｏｓｉｔｉｏｎが規定されたＰＣＳを含むＤｉｓｐｌａｙ  Ｓｅｔを順次再生装置に読み込ませれば、再生装置はＢＤ−ＲＯＭから読み出されてくるＤＳ１、ＤＳ２、ＤＳ３内のＰＣＳに従い、既にオブジェクトバッファに格納されているグラフィクスオブジェクトを、表示させることができる。制御情報の送り込みのみで、グラフィクスの位置を変化させることができるので、グラフィクスを目まぐるしく動かすという制御に適している。
個々のＤｉｓｐｌａｙ  Ｓｅｔの読み出し時において、それまで参照していたＰＣＳを、新たなＰＣＳで上書きするとの動作を行えば、たとえ読み出すべきＰＣＳが何十個、何百個あったとしても、そのうち最も新しいもののみ、再生装置に格納しておけばよい。滑らかな動きを実現するため、表示座標を示すＰＣＳが、何十個、何百個必要であっても、そのうち最新のもののみ、再生装置に常駐させておけばよいので、再生装置におけるメモリ占有量を必要最低限にすることができる。
続いてＰＣＳの第２の記述例としてＰａｌｌｅｔ  Ｏｎｌｙ  Ｕｐｄａｔｅについて説明する。図２５は、Ｐａｌｌｅｔ  Ｏｎｌｙ  Ｕｐｄａｔｅを実現する一連のＤｉｓｐｌａｙ  Ｓｅｔを示す図である。本図の第１段目は、Ｐａｌｌｅｔ  Ｏｎｌｙ  Ｕｐｄａｔｅを実現する一連のＤｉｓｐｌａｙ  Ｓｅｔ（ＤＳ０、ＤＳ１、ＤＳ２、ＤＳ３）を示す。このうちＤＳ０は、ＰＣＳと、３つのＰＤＳ０，１，２，３と、ＯＤＳとを含む。以降のＤＳ２、ＤＳ３、ＤＳ４は、ＰＣＳのみからなる。
ＤＳ０内のＯＤＳは、引き出し線ｈｖｌに示すように、文字列「忘れない」を定義するものである。これら文字「忘」「れ」「な」「い」は、それぞれ複数のＲｕｎ  Ｌｅｎｇｔｈ（図中の白抜きの四角形）から構成される。このうち文字「忘」を構成するＲｕｎ  Ｌｅｎｇｔｈは、ＰｉｘｅｌＣｏｄｅ０をもっているものとする。文字「れ」，「な」，「い」を構成するＲｕｎ  Ｌｅｎｇｔｈは、ＰｉｘｅｌＣｏｄｅ１，ＰｉｘｅｌＣｏｄｅ２，ＰｉｘｅｌＣｏｄｅ３をもっているものとする。
図２６（ａ）は、ＤＳ０内のＰＤＳ及び各Ｄｉｓｐｌａｙ  ＳｅｔのＰＣＳがどのような内容であるかを示す図である。
４つのＰＤＳのうち、１つ目のＰＤＳ０は（第１段目）、ｐａｌｌｅｔ＿ｉｄ＝０が付加されており、ＰｉｘｅｌＣｏｄｅ１に赤色を、ＰｉｘｅｌＣｏｄｅ２以降に白色を割り当てるものである。
２つ目のＰＤＳ１は（第２段目）、ｐａｌｌｅｔ＿ｉｄ＝１が付加されており、１，２のＰｉｘｅｌＣｏｄｅに赤色を、３以降のＰｉｘｅｌＣｏｄｅに白色を割り当てるものである。
３つ目のＰＤＳ２は（第３段目）、ｐａｌｌｅｔ＿ｉｄ＝２が付加されており、１，２，３のＰｉｘｅｌＣｏｄｅに赤色を、４のＰｉｘｅｌ  Ｃｏｄｅに白色を割り当てるものである。
４つ目のＰＤＳ３は（第４段目）、ｐａｌｌｅｔ＿ｉｄ＝３が付加されており、１〜４のＰｉｘｅｌＣｏｄｅに赤色を割り当てるものである。
図２６（ｂ）は、ＤＳ０〜ＤＳ３内のＰＣＳを示す図である。
本図においてＤＳ０内のＰＣＳは（第１段目）、ｏｂｊｅｃｔ＿ｉｄ＝１のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてＰａｌｌｅｔ＿ｏｎｌｙ＿ｕｐｄａｔｅが０に設定され、Ｐａｌｌｅｔ＿ｉｄが０に設定されている。これによりＤＳ０のＯＤＳは、Ｐａｌｌｅｔ＿ｉｄ＝０で指示されるＰＤＳを用いて、表示されることになる。
ＤＳ１内のＰＣＳは（第２段目）、ｏｂｊｅｃｔ＿ｉｄ＝１のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてＰａｌｌｅｔ＿ｏｎｌｙ＿ｕｐｄａｔｅが１に設定され、Ｐａｌｌｅｔ＿ｉｄが１に設定されている。これは、ＤＳ１の読み込み時において、Ｐａｌｌｅｔ＿ｉｄ＝１で指示されるＰＤＳを用いて、グラフィクス表示の更新を行う旨を示す。
ＤＳ２内のＰＣＳは（第３段目）、ｏｂｊｅｃｔ＿ｉｄ＝１のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてＰａｌｌｅｔ＿ｏｎｌｙ＿ｕｐｄａｔｅが１に設定され、Ｐａｌｌｅｔ＿ｉｄが２に設定されている。これは、ＤＳ２の読み込み時において、Ｐａｌｌｅｔ＿ｉｄ＝２で指示されるＰＤＳを用いて、グラフィクス表示の更新を行う旨を示す。］
ＤＳ３内のＰＣＳは（第４段目）、ｏｂｊｅｃｔ＿ｉｄ＝１のグラフィクスオブジェクトを参照した表示制御を行う旨を示す。そしてＰａｌｌｅｔ＿ｏｎｌｙ＿ｕｐｄａｔｅが１に設定され、Ｐａｌｌｅｔ＿ｉｄが３に設定されている。これは、ＤＳ３の読み込み時において、Ｐａｌｌｅｔ＿ｉｄ＝３で指示されるＰＤＳを用いて、グラフィクス表示の更新を行う旨を示す。ＤＳ２〜ＤＳ３に属するＰＣＳは、以上のように設定されているので、ＤＳ０に属するグラフィクスオブジェクトは、それぞれ別々のパレットデータを用いて、更新されてゆくことになる。
図２７は、これら４つのＤｉｓｐｌａｙ  Ｓｅｔが読み込ませることで実現される、表示効果を現した図である。ＤＳ０に属するグラフィクスオブジェクトが再生装置に投入された段階で、字幕「忘れない」が表示され、それを構成する文字のうち、文字「忘」が赤色になる。次にＤＳ１を投入した段階において、字幕「忘れない」を構成する文字のうち、文字「忘」，「れ」が赤色に、ＤＳ２を投入した段階で、文字「忘」，「れ」，「な」が赤色になる。そしてＤＳ３を投入した段階で、全ての文字が赤色になる。Ｄｉｓｐｌａｙ  Ｓｅｔが投入される毎に、字幕を構成する文字は、左に位置するものから順に、白色から赤色に変わってゆくので、音声の進行と共に、文字の色彩を代えてゆく表示効果を実現することができる。
これまでに説明したＤｉｓｐｌａｙ  Ｓｅｔ（ＰＣＳ，ＷＤＳ，ＰＤＳ，ＯＤＳ）のデータ構造は、プログラミング言語で記述されたクラス構造体のインスタンスであり、オーサリングを行う制作者は、Ｂｌｕ−ｒａｙ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｆｏｒｍａｔに規定された構文に従い、クラス構造体を記述することで、ＢＤ−ＲＯＭ上のこれらのデータ構造を得ることができる。  以上が本発明に係る記録媒体の実施形態である。続いて本発明に係る再生装置の実施形態について説明する。図２８は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置、マイコンシステムという３つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤドライブ１、Ｒｅａｄ  Ｂｕｆｆｅｒ２、ＰＩＤフィルタ３、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃ、周辺回路４ｄ、ビデオデコーダ５、ビデオプレーン６、オーディオデコーダ７、グラフィクスプレーン８、ＣＬＵＴ部９、加算器１０、グラフィクスデコーダ１２、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７から構成される。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／リード／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
Ｒｅａｄ  Ｂｕｆｆｅｒ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。
ＰＩＤフィルタ３は、Ｒｅａｄ  Ｂｕｆｆｅｒ  ２から出力される複数ＴＳパケットに対してフィルタリングを施す。ＰＩＤフィルタ３によるフィルタリングは、ＴＳパケットのうち、所望のＰＩＤをもつもののみをＴｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃに書き込むことでなされる。ＰＩＤフィルタ３によるフィルタリングでは、バッファリングは必要ではない。従って、ＰＩＤフィルタ３に入力されたＴＳパケットは、時間遅延なく、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃに書き込まれる。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃは、ＰＩＤフィルタ３から出力されたＴＳパケットを先入れ先出し式に格納しておくメモリである。このＴｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａからＴＳパケットが取り出される速度を速度Ｒｘとする
周辺回路４ｄは、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃから読み出されたＴＳパケットを、機能セグメントに変換する処理を行うワイアロジックである。変換により得られた機能セグメントはＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３に格納される。
ビデオデコーダ５は、ＰＩＤフィルタ３から出力された複数ＴＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン６に書き込む。
ビデオプレーン６は、動画用のプレーンメモリである。
オーディオデコーダ７は、ＰＩＤフィルタ３から出力されたＴＳパケットを復号して、非圧縮形式のオーディオデータを出力する。
グラフィクスプレーン８は、一画面分の領域をもったプレーンメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
ＣＬＵＴ部９は、グラフィクスプレーン８に格納された非圧縮グラフィクスにおけるインデックスカラーを、ＰＤＳに示されるＹ，Ｃｒ，Ｃｂ値に基づき変換する。
加算器１０は、ＣＬＵＴ部９により色変換された非圧縮グラフィクスに、ＰＤＳに示されるＴ値（透過率）を乗じて、ビデオプレーン６に格納された非圧縮状態のピクチャデータと画素毎に加算し、合成画像を得て出力する。
グラフィクスデコーダ１２は、グラフィクスストリームをデコードして、非圧縮グラフィクスを得て、これをグラフィクスオブジェクトとしてグラフィクスプレーン８に書き込む。グラフィクスストリームのデコードにより、字幕やメニューが画面上に現れることになる。
グラフィクスデコーダ１２によるパイプラインは、ＤＳｎに属するグラフィクスオブジェクトをＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５に書き込む処理、ＤＳｎ＋１に属するグラフィクスオブジェクトをＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５から読み出す処理を同時に実行することでパイプラインは実行される。
このグラフィクスデコーダ１２は、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３、周辺回路１３ａ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７から構成される。
Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３は、機能セグメントがＤＴＳ、ＰＴＳと共に格納されるバッファである。かかる機能セグメントは、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃに格納されたトランスポートストリームの各ＴＳパケットから、ＴＳパケットヘッダ、ＰＥＳパケットヘッダを取り除き、ペイロードをシーケンシャルに配列することにより得られたものである。取り除かれたＴＳパケットヘッダ、ＰＥＳパケットヘッダのうち、ＰＴＳ／ＤＴＳは、ＰＥＳパケットと対応付けて格納される。
周辺回路１３ａは、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３−Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４間の転送、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３−Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６間の転送を実現するワイヤロジックである。この転送処理において現在時点がＯＤＳのＤＴＳに示される時刻になれば、ＯＤＳを、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３からＳｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４に転送する。また現在時刻がＰＣＳ、ＰＤＳのＤＴＳに示される時刻になれば、ＰＣＳ、ＰＤＳをＣｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６に転送するという処理を行う。
Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４は、ＯＤＳをデコードして、デコードにより得られたインデックスカラーからなる非圧縮状態の非圧縮グラフィクスをグラフィクスオブジェクトとしてＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５に書き込む。Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時に行われ、デコードによりグラフィクスオブジェクトをＳｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４は一時的に保持する。Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードは瞬時になされるが、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４からＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への書き込みは、瞬時には終わらない。ＢＤ−ＲＯＭ規格のプレーヤモデルでは、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への書き込みは、１２８Ｍｂｐｓという転送レートでなされるからである。Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への書き込み完了時点は、ＥＮＤセグメントのＰＴＳに示されているので、このＥＮＤセグメントのＰＴＳに示される時点が経過するまで、次のＤＳに対する処理を待つことになる。各ＯＤＳをデコードすることにより得られたグラフィクスオブジェクトの書き込みは、そのＯＤＳに関連付けられたＤＴＳの時刻に開始し、ＯＤＳに関連付けられたＰＴＳに示されるデコード終了時刻までに終了する。
書き込み時にあたってＤＳｎ側のグラフィックスデータと、ＤＳｎ＋１側のグラフィックスデータとに割り当てられているｏｂｊｅｃｔ＿ｉｄが別々の場合、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４はＤＳｎ側のグラフィックスデータと、ＤＳｎ＋１側のグラフィックスデータとを、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５における別々の領域に書き込む。これによりＤＳｎのＰＣＳにより参照されるグラフィクスオブジェクトは、ＤＳｎ＋１に属するグラフィクスオブジェクトにより上書きされることなく、パイプラインで表示に供される。両グラフィクスオブジェクトに割り当てられているｏｂｊｅｃｔ＿ｉｄが同じである場合、前記Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４は、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５において先行ＤＳ側のグラフィックスデータが格納されている領域と同じ領域に、後続ＤＳ側のグラフィックスデータを上書きする。かかる場合、パイプラインは行わない。またＤＳに属するグラフィクスオブジェクトには、同一ＤＳのＰＣＳにより参照されているものと、参照されていないものとがある。Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４は、ＰＣＳにより参照されているグラフィクスオブジェクトだけでなく、参照されてないグラフィクスオブジェクトを逐次デコードして、デコードにより得られたグラフィクスをＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５に格納する。
Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５は、ＥＴＳＩ  ＥＮ  ３００  ７４３標準規格におけるピクセルバッファに相当するバッファであり、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４のデコードにより得られたグラフィクスオブジェクトが配置される。Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５は、グラフィクスプレーン８の２倍／４倍の大きさに設定せねばならない。何故ならＳｃｒｏｌｌｉｎｇを実現する場合を考えると、グラフィクスプレーン８の２倍、４倍のグラフィクスオブジェクトを格納しておかねばならないからである。
Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６は、ＰＣＳ、ＰＤＳが配置されるメモリである。−−処理すべきＤｉｓｐｌａｙ  Ｓｅｔが２つあり、これらの有効区間が重複している場合、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６には処理すべきＰＣＳが複数格納される。
Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７は、Ｇｒａｐｈｉｃａｌコントローラ１７はＰＣＳの解読を行い、ＰＣＳの解読結果に従って、グラフィクスオブジェクトのＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への書き込み、及び、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５からのグラフィクスオブジェクトの読み出し、グラフィクスオブジェクトの表示を実行する。Ｇｒａｐｈｉｃａｌコントローラ１７による表示は、ＰＣＳを格納したＰＥＳパケットのＰＴＳに示される時点において実行される。
オブジェクトＣによる画面構成を実行するにあたって、Ｇｒａｐｈｉｃｓコントローラ１７は以下の処理を行う。Ｇｒａｐｈｉｃｓコントローラ１７は、オブジェクトＣに記述されたグラフィクスオブジェクト識別子の参照値（ｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆ）を読み取り、そのｏｂｊｅｃｔ＿ｉｄ＿ｒｅｆにより指示されるグラフィクスオブジェクトのうち、Ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎから、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに示されるクロップ範囲を切り出して、グラフィックスプレーンのｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎにより示される位置に書き込む。この参照値が、オブジェクトＣと同じＤｉｓｐｌａｙ  Ｓｅｔに属するグラフィクスオブジェクトを表している場合、同じＤｉｓｐｌａｙ  Ｓｅｔに属するＯＤＳがデコードされた後でないと、上述したグラフィックスプレーンへの書き込みは行えない。
一方、オブジェクトＣが属するＤｉｓｐｌａｙ  ＳｅｔのＣｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＮｏｒｍａｌ  Ｃａｓｅである場合、デコードにより得られたグラフィクスオブジェクトが、前もってオブジェクトバッファ内に格納されているので、ＯＤＳのデコードを待つことなく、上述したグラフィックスプレーンへの書き込みを行うことができる。
ＰａｌｌｅｔＯｎｌｙ  Ｄｉｓｐｌｅｙ  Ｕｐｄａｔｅ時におけるＧｒａｐｈｉｃｓコントローラ１７の読み出し処理は以下の通りである。Ｄｉｓｐｌａｙ  Ｓｅｔが、ＢＤ−ＲＯＭから読み出された場合、Ｇｒａｐｈｉｃｓコントローラ１７は、ＰＣＳのＰａｌｌｅｔｔｅ＿ｕｐｄａｔｅ＿ｆｌａｇが、”１”であるか否かを判定する。もし１であるなら、ＰＣＳのｐａｌｌｅｔ＿ｉｄに記述されているパレットデータを用いた画素値変換を、ＣＬＵＴ部９に命じた上で、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５からグラフィクスオブジェクトを読み出し、グラフィクスプレーン８に格納させてゆく。ＣＬＵＴ部９に対するパレットデータの設定のみを行うことで、グラフィクスの更新を行うのである。
続いて、ＰＩＤフィルタ３、Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃ、グラフィクスプレーン８、ＣＬＵＴ部９、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３〜Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７を構成するための、転送レート、バッファサイズの推奨値について説明する。図２９は、書込レートＲｘ，Ｒｃ，Ｒｄ、グラフィクスプレーン８、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６のサイズを示す図である。
Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５−グラフィクスプレーン８間の転送レートＲｃは、本装置において最も高い転送レートであり、ウィンドゥサイズ、フレームレートから２５６Ｍｂｐｓ（＝５００Ｋバイト×２９．９７×２）と算出される。
Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４−Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５間の転送レートＲｄ（Ｐｉｘｅｌ  Ｄｅｃｏｄｉｎｇ  Ｒａｔｅ）は、Ｒｃとは異なり、ビデオフレームの周期によるアップデートは要求されずＲｃの１／２，１／４でよい。故に１２８Ｍｂｐｓ，６４Ｍｂｐｓになる。
Ｔｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ４ａ，ｂ，ｃ−Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３間のＴｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ  ＬｅａｋレートＲｘは、圧縮状態たるＯＤＳの転送レートである。従ってＴｒａｎｓｐｏｒｔ  Ｂｕｆｆｅｒ  Ｌｅａｋレートは、Ｒｄに圧縮率を乗じた転送レートでよい。ＯＤＳの圧縮率を２５％と仮定すれば、１６Ｍｂｐｓ（＝６４Ｍｂｐｓ×２５％）で足りる。
この図に示す転送レート、バッファ規模はあくまでもミニマムスタンダードであり、これより大きい値での実装を否定している訳ではない。
以上のように構成された再生装置において、各構成要素はパイプライン式にデコード処理を行うことができる。
図３０は、再生装置によるパイプライン処理を示すタイミングチャートである。第５段目は、ＢＤ−ＲＯＭにおけるＤｉｓｐｌａｙ  Ｓｅｔを示し、第４段目は、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３へのＰＣＳ、ＷＤＳ、ＰＤＳ、ＯＤＳの読出期間を示す。第３段目は、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４による各ＯＤＳのデコード期間を、第２段目はＣｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６の格納内容を、第１段目はＧｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理内容を示す。
ＯＤＳ１，２に付与されたＤＴＳ（デコード開始時刻）は、図中のｔ３１，ｔ３２の時点を示している。デコード開始時刻がＤＴＳに規定されているので、各ＯＤＳは、自身のＤＴＳに示される時刻までにＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３に読み出されなければならない。そのためＯＤＳ１の読み出しは、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３へのＯＤＳ１のデコード期間ｄｐ１の直前までに完了している。Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３へのＯＤＳ２の読み出しは、ＯＤＳ２のデコード期間ｄｐ２の直前までに完了している。
一方、ＯＤＳ１，２に付与されたＰＴＳ（デコード終了時刻）は、図中のｔ３２，ｔ３３の時点を示している。Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４によるＯＤＳ１のデコードはｔ３２までに完了し、ＯＤＳ２のデコードは、ｔ３３に示される時刻までに完了する。以上のように、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４は、各ＯＤＳのＤＴＳに示される時刻までに、ＯＤＳをＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３に読み出し、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３に読み出されたＯＤＳを、各ＯＤＳのＰＴＳに示される時刻までに、デコードしてＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５に書き込む。
本図の第１段目における期間ｃｄ１は、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ１７がグラフィクスプレーン８をクリアするのに要する期間である。また期間ｔｄ１は、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５上にえられたグラフィクスオブジェクトを、グラフィクスプレーン８に書き込むのに要する期間である。ＷＤＳのＰＴＳは、この書き込みの開始にあたってのデッドラインを示し、ＰＣＳのＰＴＳはこの書き込みの終了時点及び表示タイミングを示す。このＰＣＳのＰＴＳに示される時点になれば、対話画面を構成する非圧縮グラフィクスがグラフィクスプレーン８上に得られることになる。この非圧縮グラフィクスの色変換をＣＬＵＴ部９に行わせ、ビデオプレーン６に格納されている非圧縮ピクチャとの合成を加算器１０に行わせれば、合成画像が得られることになる。
グラフィクスデコーダ１２において、Ｇｒａｐｈｉｃｓ  Ｃｏｎｔｒｏｌｌｅｒ１７がグラフィクスプレーン８のクリアを実行している間においても、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｏｒ１４のデコードは継続して行われる。以上のようなパイプライン処理により、グラフィクスの表示を迅速に実施することができる。
図３０では、グラフィックスプレーンのクリアが、ＯＤＳのデコードより早く終わる場合を想定したが、図３１は、ＯＤＳのデコードが、グラフィックスプレーンのクリアより早く終わる場合を想定したパイプライン処理を示すタイミングチャートである。この場合、ＯＤＳのデコードが完了した段階では、グラフィックスプレーンへの書き込みを実行することができず、グラフィックスプレーンのクリアが完了した時点で、デコードにより得られたグラフィクスをグラフィックスプレーンに書き込むことができる。
再生装置におけるバッファ占有量の時間的遷移について図３２を参照しながら説明する。図３２は、図２８におけるＣｏｍｐｏｓｉｔｉｏｎバッファ１６、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｄｅｄ  Ｄａｔａバッファ１３、グラフィクスプレーン８の時間的遷移を示すタイミングチャートである。本図は、第１段目から第４段目までに、グラフィクスプレーン８、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｄｅｄ  Ｄａｔａバッファ１３、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６における占有量の時間的遷移を示している。この占有量の時間的遷移は、横軸を時間軸とし、縦軸を占有量とした折れ線グラフの表記で表現している。
図３２の第４段目は、Ｃｏｍｐｏｓｉｔｉｏｎバッファ１６における占有量の時間的遷移を示す。本図に示すようにＣｏｍｐｏｓｉｔｉｏｎバッファ１６の時間的遷移は、Ｃｏｄｅｄ  Ｄａｔａバッファ１３から出力されＰＣＳが格納されることによる単調増加ｖｆ０を含む。
第３段目は、Ｃｏｄｅｄ  Ｄａｔａバッファ１３における占有量の時間的遷移を示す。本図に示すようにＣｏｄｅｄ  Ｄａｔａバッファ１３の時間的遷移は、ＯＤＳが格納されることによる単調増加Ｖｆ１，Ｖｆ２と、格納されたＯＤＳが順次Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４により取り出されることによる単調減少Ｖｇ１，Ｖｇ２とを含む。単調増加Ｖｆ１，Ｖｆ２の傾きは、Ｔｒａｎｓｐｏｒｔバッファ４ａ，ｂ，ｃからＣｏｄｅｄ  Ｄａｔａバッファ１３への出力レートＲｘに基づき、単調減少Ｖｇ１，Ｖｇ２の傾きは、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４によるデコードであり、瞬時に実行される。つまりＯＤＳに対するデコードは瞬時に行われ、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４は、デコードにより得られた非圧縮グラフィクスを保持する。Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４からＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への伝送路の書込レートは１２８Ｍｂｐｓであるため、この書込レートにより、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５の占有量は増加する。
第２段目は、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５における占有量の時間的遷移を示す。本図に示すようにＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５の時間的遷移は、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４から出力されたＯＤＳが格納されることによる単調増加Ｖｈ１，Ｖｈ２を含む。単調増加Ｖｈ１，Ｖｈ２の傾きは、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４からＯｂｊｅｃｔ  Ｂｕｆｆｅｒ１５への転送レートＲｄに基づく。第３段目の単調減少が生じる期間及びの第２段目の単調増加が生ずる期間が、デコード期間である。このデコード期間の始期は、ＯＤＳのＤＴＳに示されており、デコード期間の終期は、ＯＤＳのＰＴＳに示されている。このＯＤＳのＰＴＳに示される期間までに、非圧縮のグラフィクスがｏｂｊｅｃｔ  ｂｕｆｆｅｒ１５に格納されれば、ＯＤＳに対するデコードは完了したことになる。ＯＤＳのＰＴＳに示される期間までに、非圧縮のグラフィクスがｏｂｊｅｃｔ  ｂｕｆｆｅｒ１５に格納されることが、必須の要件であり、このデコード期間における単調増加、単調減少はどのようなものであってもよい。
第１段目は、グラフィクスプレーン８における占有量の時間的遷移を示す。本図に示すようにグラフィクスプレーン８の時間的遷移は、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５から出力されたデコード済みＯＤＳが格納されることによる単調増加Ｖｆ３を含む。単調増加Ｖｆ３の傾きは、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５からグラフィクスプレーン８への転送レートＲｃに基づく。この単調増加の終期は、ＰＣＳのＰＴＳに示されている。
ＯＤＳに付与されたＤＴＳ、ＰＴＳ、ＩＣＳに付与されたＤＴＳ、ＰＴＳ、そして図２９に示した各バッファのサイズ、転送レートを用いれば、本図のようなグラフを作図することにより、ＢＤ−ＲＯＭにて供給すべきＡＶＣｌｉｐの再生時において、各バッファの状態がどのように変化するかが、オーサリングの段階で明らかになる。
このバッファ状態の遷移は、ＤＴＳ、ＰＴＳに示される値を書き換えることで、調整することが可能なので、再生装置側のデコーダのスペックを越えるような復号負荷の発生を回避したり、再生にあたってのバッファオーバーフローの回避することができる。そのため再生装置の開発にあたってのハードウェア、ソフトウェアの実装が簡易になる。
以上が再生装置の内部構成である。続いてグラフィクスデコーダ１２を、どのようにして実装するかについて説明する。グラフィクスデコーダ１２は、図３３の処理手順を行うプログラムを作成し、ＣＰＵに実行させることにより実装可能である。以降、図３３を参照しながら、制御部２０の処理手順について説明する。
図３３は、機能セグメントのロード処理の処理手順を示すフローチャートである。本フローチャートにおいてＳｅｇｍｅｎｔＫとは、ＡＶＣｌｉｐの再生時において、読み出されたＳｅｇｍｅｎｔ（ＰＣＳ，ＷＤＳ，ＰＤＳ，ＯＤＳ）のそれぞれを意味する変数であり、無視フラグは、このＳｅｇｍｅｎｔＫを無視するかロードするかを切り換えるフラグである。本フローチャートは、無視フラグを０に初期化した上で、ステップＳ２１〜Ｓ２４、ステップＳ２７〜Ｓ３１の処理を全てのＳｅｇｍｅｎｔＫについて繰り返すループ構造を有している（ステップＳ２５、ステップＳ２６）。
ステップＳ２１は、ＳｅｇｍｅｎｔＫがＰＣＳであるか否かの判定であり、もしＳｅｇｍｅｎｔＫがＰＣＳであれば、ステップＳ２７、ステップＳ２８の判定を行う。
ステップＳ２２は、無視フラグが１かどうかの判定である。無視フラグが０であるならステップＳ２３に移行し、１であるならステップＳ２４に移行する。無視フラグが１であれば（ステップＳ２２でＮｏ）、ステップＳ２３においてＳｅｇｍｅｎｔＫをＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードする。
無視フラグが０に設定されていれば（ステップＳ２２がＮｏ）、ステップＳ２４においてＳｅｇｍｅｎｔＫが無視される。これによりＤＳに属する機能セグメントは全て、ステップＳ２２がＮｏになって、無視されることになる（ステップＳ２４）。
このように、ＳｅｇｍｅｎｔＫが無視されるか、ロードされるかは、無視フラグの設定により決まる。ステップＳ２７〜Ｓ３１、Ｓ３４、Ｓ３５は、この無視フラグを設定する処理である。
ステップＳ２７は、ＰＣＳにおけるｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔであるか否かの判定である。ＳｅｇｍｅｎｔＫがＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔであるなら、ステップＳ２８に移行し、ＳｅｇｍｅｎｔＫがもしＥｐｏｃｈ  ＳｔａｒｔかＮｏｒｍａｌ  Ｃａｓｅであるなら、ステップＳ３１に移行する。
ステップＳ２８は、先行するＤＳがグラフィクスデコーダ１２内のどれかのバッファ（Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３、Ｓｔｒｅａｍ  Ｇｒａｐｈｉｃｓプロセッサ１４、Ｏｂｊｅｃｔ  Ｂｕｆｆｅｒ１５、Ｃｏｍｐｏｓｉｔｉｏｎ  Ｂｕｆｆｅｒ１６）に存在するかどうかの判定であり、ステップＳ２７がＹｅｓである場合に実行される。グラフィクスデコーダ１２内にＤＳが存在しないケースとは、頭出しがなされたケースをいう。この場合、Ａｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔたるＤＳから、表示を開始せねばならないので、ステップＳ３０に移行する（ステップＳ２８でＮｏ）。
ステップＳ３０は、無視フラグを０に設定し、ステップＳ２２に移行する。
グラフィクスデコーダ１２内にＤＳが存在するケースとは、通常再生がなされたケースをいう。この場合、ステップＳ２９に移行する（ステップＳ２８でＹｅｓ）。ステップＳ２９は、無視フラグを１に設定し、ステップＳ２２に移行する。
ステップＳ３１は、ＰＣＳにおけるｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＮｏｒｍａｌ  Ｃａｓｅであるか否かの判定である。もしＮｏｒｍａｌ  Ｃａｓｅであるなら、ステップＳ３４に移行する。ＳｅｇｍｅｎｔＫがＥｐｏｃｈ  Ｓｔａｒｔであるなら、ステップＳ３０において無視フラグを０に設定する。  ステップＳ３４は、ステップＳ２８と同じであり、先行するＤＳがグラフィクスデコーダ１２内に存在するかどうかの判定を行う。もし存在するなら、無視フラグを０に設定する（ステップＳ３０）。存在しないなら、元々、対話画面を構成する充分な機能セグメントが得られないため、無視フラグを１に設定する（ステップＳ３５）。かかるフラグ設定により、先行するＤＳがグラフィクスデコーダ１２に存在しない場合、Ｎｏｒｍａｌ  Ｃａｓｅを構成する機能セグメントは無視されることになる。
ＤＳが、図３４のように多重化されている場合を想定して、ＤＳの読み出しがどのように行われるかを説明する。図３４の一例では、３つのＤＳが動画と多重化されている。この３つのＤＳのうち、初めのＤＳ１は、ｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＥｐｏｃｈ＿Ｓｔａｒｔ、ＤＳ１０はＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔ、ＤＳ２０は、Ｎｏｒｍａｌ  Ｃａｓｅである。
かかる３つのＤＳが、動画と多重化されているＡＶＣｌｉｐにおいて、ピクチャデータｐｔ１０からの頭出しが矢印ａｍ１に示すように行われたものとする。この場合、頭出し位置に最も近いＤＳ１０が、図３３のフローチャートの対象となる。ステップＳ２７においてｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅはＡｃｑｕｉｓｉｔｉｏｎ  Ｐｏｉｎｔと判定されるが、先行するＤＳはＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３上に存在しないため、無視フラグは０に設定され、このＤＳ１０が図３５の矢印ｍｄ１に示すように再生装置のＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードされる。一方、頭出し位置がＤＳ１０の存在位置より後である場合（図３４の矢印ａｍ２）、ＤＳ２０は、Ｎｏｒｍａｌ  ＣａｓｅのＤｉｓｐｌａｙ  Ｓｅｔであり、先行するＤＳ２０はＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３に存在しないので、このＤｉｓｐｌａｙ  Ｓｅｔは、無視されることになる（図３５の矢印ｍｄ２）。
図３６のように通常再生が行われた場合のＤＳ１，１０，２０のロードは、図３６に示すものとなる。３つのＤＳのうち、ＰＣＳのｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＥｐｏｃｈ  ＳｔａｒｔであるＤＳ１は、そのままＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードされるが（ステップＳ２３）、ＰＣＳのｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅがＡｃｑｕｉｓｉｔｉｏｎ  ＰｏｉｎｔであるＤＳ１０については、無視フラグが１に設定されるため（ステップＳ２９）、これを構成する機能セグメントはＣｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードされず無視される（図３７の矢印ｒｄ２，ステップＳ２４）。またＤＳ２０については、ＰＣＳのｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅはＮｏｒｍａｌ  Ｃａｓｅなので、Ｃｏｄｅｄ  Ｄａｔａ  Ｂｕｆｆｅｒ１３にロードされる（図３７の矢印ｒｄ３）。
続いてＧｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理手順について説明する。図３８〜図４０は、Ｇｒａｐｈｉｃａｌ  Ｃｏｎｔｒｏｌｌｅｒ１７の処理手順を示すフローチャートである。
ステップＳ４１〜ステップＳ４４は、本フローチャートのメインルーチンであり、ステップＳ４１〜ステップＳ４４に規定した何れかの事象の成立を待つ。
ステップＳ４１は、現在の再生時点がＰＣＳのＤＴＳ時刻になっているか否かの判定であり、もしなっていれば、ステップＳ４５〜ステップＳ５３の処理を行う。
ステップＳ４５は、ＰＣＳのｃｏｍｐｏｓｉｔｉｏｎ＿ｓｔａｔｅが、Ｅｐｏｃｈ＿Ｓｔａｒｔであるか否かの判定であり、もしＥｐｏｃｈ  Ｓｔａｒｔであるなら、ステップＳ４６においてグラフィクスプレーン８を全クリアする。それ以外であるなら、ステップＳ４７においてＷＤＳのｗｉｎｄｏｗ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎ、ｗｉｎｄｏｗ＿ｗｉｄｔｈ、ｗｉｎｄｏｗ＿ｈｅｉｇｈｔに示されるｗｉｎｄｏｗをクリアする。
ステップＳ４８は、ステップＳ４６又はステップＳ４７でのクリア後の実行されるステップであり、任意のＯＤＳｘのＰＴＳ時刻が既に経過しているか否かの判定である。つまり、グラフィクスプレーン８全体のクリアにあたっては、そのクリア時間に長時間を費するので、あるＯＤＳ（ＯＤＳｘ）のデコードが既に完了していることもある。ステップＳ４８はその可能性を検証している。もし経過していないなら、メインルーチンにリターンする。どれかのＯＤＳのデコード時刻を経過しているなら、ステップＳ４９〜ステップＳ５１を実行する。ステップＳ４９は、ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇが０を示しているか否かの判定であり、もし０を示しているなら、グラフィクスオブジェクトを非表示とする（ステップＳ５０）。
もし０を示していないなら、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎ、ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のｗｉｎｄｏｗにおいてＯｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎに示される位置に書き込む（ステップＳ５１）。以上の処理により、ウィンドゥに１つ以上のグラフィクスオブジェクトが描かれることになる。
ステップＳ５２は、別のＯＤＳｙのＰＴＳ時刻が経過しているか否かの判定である。ＯＤＳｘをグラフィクスプレーン８に書き込んでいる際、別のＯＤＳのデコードが既に完了していれば、このＯＤＳｙをＯＤＳｘにして（ステップＳ５３）、ステップＳ４９に移行する。これにより、別のＯＤＳに対しても、ステップＳ４９〜Ｓ５１の処理が繰り返し行われる。
次に図３９を参照して、ステップＳ４２、ステップＳ５４〜ステップＳ５９について説明する。
ステップＳ４２は、現在の再生時点がＷＤＳのＰＴＳであるか否かの判定であり、もしＷＤＳのＰＴＳであるなら、ステップＳ５４においてウィンドゥが１つであるか否かを判定し、もし２つであれば、メインルーチンにリターンする。ウィンドゥが１つであるなら、ステップＳ５５〜ステップＳ５９のループ処理を行う。このループ処理は、ウィンドゥに表示される２つのグラフィクスオブジェクトのそれぞれについて、ステップＳ５７〜ステップＳ５９を実行するというものである。ステップＳ５７は、ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇが０を示しているか否かの判定であり、もし０を示しているなら、グラフィクスオブジェクトを非表示とする（ステップＳ５８）。
もし０を示していないなら、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎ、ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のｗｉｎｄｏｗにおいてｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎに示される位置に書き込む（ステップＳ５９）。以上の処理を繰り返せば、ウィンドゥに１つ以上のグラフィクスオブジェクトが描かれることになる。
ステップＳ４４は、現在の再生時点がＰＣＳのＰＴＳに示される時点であるかの判定であり、もしそうであるなら、ステップＳ６０においてＰａｌｌｅｔ＿ｕｐｄａｔｅ＿ｆｌａｇが１を示しているか否かを判定する。もし１を示しているなら、ｐａｌｌｅｔ＿ｉｄに示されるＰＤＳをＣＬＵＴ部に設定する（ステップＳ６１）。０を示しているなら、ステップＳ６１をスキップする。
その後、グラフィクスプレーン８におけるグラフィクスオブジェクトの色変換をＣＬＵＴ部に行わせて、動画像と合成する（ステップＳ６２）。
次に図４０を参照して、ステップＳ４３、ステップＳ６４〜ステップＳ６６について説明する。
ステップＳ４３は、現在の再生時点がＯＤＳのＰＴＳであるか否かの判定であり、もしＯＤＳのＰＴＳであるなら、ステップＳ６３においてウィンドゥが２つであるか否かを判定する。もし１つであれば、メインルーチンにリターンする。
ステップＳ４３及びステップＳ６３の判定は以下の意味をもつ。つまりウィンドゥが２つある場合、それぞれのウィンドゥには、１つずつグラフィクスオブジェクトが表示される。そうすると、それぞれのＯＤＳのデコードが完了する度に、デコードにより得られたグラフィクスオブジェクトを、グラフィックスプレーンに書き込んでゆく処理が必要になる（例：図１９（ｂ）のケース）。そこで現在時点がＯＤＳのＰＴＳに示される時点であり、ウィンドゥが２つであるなら、個々のグラフィクスオブジェクトをグラフィックスプレーンに書き込むべく、ステップＳ６４〜ステップＳ６６を実行する。ステップＳ６４は、ｏｂｊｅｃｔ＿ｃｒｏｐｐｅｄ＿ｆｌａｇが０を示しているか否かの判定であり、もし示しているなら、グラフィクスオブジェクトを非表示とする（ステップＳ６５）。
もし０を示していないなら、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ、ｏｂｊｅｃｔ＿ｃｒｏｐｐｉｎｇ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎ、ｃｒｏｐｐｉｎｇ＿ｗｉｄｔｈ、ｃｒｏｐｐｉｎｇ＿ｈｅｉｇｈｔに基づきクロップされたグラフィクスオブジェクトを、グラフィクスプレーン８のｗｉｎｄｏｗにおいてｏｂｊｅｃｔ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ，ｏｂｊｅｃｔ＿ｖｅｒｔｉｖａｌ＿ｐｏｓｉｔｉｏｎに示される位置に書き込む（ステップＳ６６）。以上の処理を繰り返せば、各ウィンドゥにグラフィクスオブジェクトが描かれることになる。
（第２実施形態）
本実施形態は、ＢＤ−ＲＯＭの製造工程に関する実施形態である。図４１は、第１実施形態に示したＰＣＳを作成するための製造工程を示す図である。
ＢＤ−ＲＯＭの制作工程は、動画収録、音声収録等の素材作成を行う素材制作工程Ｓ２０１、オーサリング装置を用いて、アプリケーションフォーマットを生成するオーサリング工程Ｓ２０２、ＢＤ−ＲＯＭの原盤を作成し、プレス・貼り合わせを行って、ＢＤ−ＲＯＭを完成させるプレス工程Ｓ２０３を含む。
これらの工程のうち、ＢＤ−ＲＯＭを対象としたオーサリング工程は、以下のステップＳ２０４〜ステップＳ２１０を含む。
ステップＳ２０４において制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを記述し、ステップＳ２０５では、制御情報、ウィンドゥ定義情報、パレット定義情報、グラフィクスを機能セグメントに変換する。そしてステップＳ２０６において同期したいピクチャが出現するタイミングに基づき、ＰＣＳのＰＴＳを設定し、ステップＳ２０７では、ＰＴＳ［ＰＣＳ］の値に基づき、ＤＴＳ［ＯＤＳ］，ＰＴＳ［ＯＤＳ］を設定する。ステップＳ２０８において、ＤＴＳ［ＯＤＳ］の値に基づき、ＤＴＳ［ＰＣＳ］，ＰＴＳ［ＰＤＳ］，ＤＴＳ［ＷＤＳ］，ＰＴＳ［ＷＤＳ］を設定し、ステップＳ２０９では、プレーヤモデルにおける各バッファの占有量の時間的遷移をグラフ化する。ステップＳ２１０では、グラフ化された時間的遷移がプレーヤモデルの制約を満たすか否かを判定し、もし満たさないなら、ステップＳ２１１において各機能セグメントのＤＴＳ、ＰＴＳを書き換える。もし満たすならステップＳ２１２においてグラフィクスストリームを生成し、ステップＳ２１３においてグラフィクスストリームを別途生成されたビデオストリーム、オーディオストリームと多重してＡＶＣｌｉｐを得る。以降、ＡＶＣｌｉｐをＢＤ−ＲＯＭのフォーマットに適合させることにより、アプリケーションフォーマットが完成する。
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
（Ａ）全ての実施形態では、本発明に係る記録媒体をＢＤ−ＲＯＭとして実施したが、本発明の記録媒体は、記録されるグラフィクスストリームに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。グラフィクスストリームを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュカード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレシキブルディスク、ＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなすシステムＬＳＩ（集積回路）のみを、実施としてもよい。これらの再生装置及び集積回路は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、第１実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。第１実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
（Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、第１実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
（Ｄ）各フローチャートにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフローチャートによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフローチャートの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
（Ｅ）ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ−ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケット（以下ＥＸ付きＴＳパケットと略す）は、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＥＸ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。３個のセクタに収められた３２個のＥＸ付きＴＳパケットを”Ａｌｉｇｎｅｄ  Ｕｎｉｔ”という。
ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置は、以下のような送信処理にてＡｌｉｇｎｅｄ  Ｕｎｉｔの送信を行う。つまり送り手側の機器は、Ａｌｉｇｎｅｄ  Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
（Ｆ）各実施形態におけるデジタルストリームは、ＢＤ−ＲＯＭ規格のＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ  Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、ｄｔｓ方式であってもよい。
（Ｇ）各実施形態における映画作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
（Ｈ）第１実施形態〜第２実施形態に示したグラフィックスオブジェクトは、ランレングス符号化されたラスタデータである。グラフィックスオブジェクトの圧縮・符号化方式にランレングス符号方式を採用したのは、ランレングス符号化は字幕の圧縮・伸長に最も適しているためである。字幕には、同じ画素値の水平方向の連続長が比較的長くなるという特性があり、ランレングス符号化による圧縮を行えば、高い圧縮率を得ることができる。また伸長のための負荷も軽く、復号処理のソフトウェア化に向いているからである。しかし、グラフィックスオブジェクトにランレングス符号化方式を採用したというのは、本発明の必須事項ではなく、グラフィックスオブジェクトはＰＮＧデータであってもよい。またラスタデータではなくベクタデータであってもよい、更に透明な絵柄であってもよい。
（Ｉ）ＰＣＳによる表示効果の対象は、装置側の言語設定に応じて選ばれた字幕のグラフィクスであってもよい。これにより、現状のＤＶＤにおいて動画像本体で表現していたような文字を用いた表示効果を、装置側の言語設定に応じて表示された字幕グラフィクスで実現することができるので、実用上の価値は大きい。
またＰＣＳによる表示効果の対象は、装置側のディスプレイ設定に応じて選ばれた字幕グラフィクスであってもよい。つまり、ワイドビジョン、パンスキャン、レターボックス用といった様々な表示モード用のグラフィクスがＢＤ−ＲＯＭに記録されており、装置側は自身に接続されたテレビの設定に応じてこれらの何れかを選んで表示する。この場合、そうして表示された字幕グラフィクスに対し、ＰＣＳに基づく表示効果をほどこすので、見栄えがよくなる。これにより、動画像本体で表現していたような文字を用いた表示効果を、装置側のディスプレイ設定に応じて表示された字幕で実現することができるので、実用上の価値は大きい。
（Ｊ）第１実施形態ではグラフィックスプレーンへの書込レートＲｃは、１ビデオフレーム内にグラフィックスプレーンクリア及び再描画が可能になるよう、ｗｉｎｄｏｗのサイズを全体の２５％に定めたが、これらクリア・再描画が垂直帰線期間に完遂するよう、Ｒｃを定めても良い。垂直帰線期間は１／２９．９３秒の２５％と仮定すると、Ｒｃは１Ｇｂｐｓになる。Ｒｃをこのように設定することでグラフィクス表示はスムーズになされるので、実用上の効果は大きい。
また垂直帰線期間での書き込みに加え、ラインスキャンに同期した書き込みを併用してもよい。これにより、Ｒｃ＝２５６Ｍｂｐｓの書込レートであっても、スムーズな表示の実現が可能になる。
（Ｋ）各実施形態において再生装置には、グラフィックスプレーンを実装したが、このグラフィックスプレーンに代えて、一ライン分の非圧縮画素を格納するラインバッファを具備してもよい。映像信号への変換は水平行（ライン）毎に行われるので、このラインバッファさえ具備していれば、この映像信号への変換は行なえるからである。
（Ｌ）グラフィクスたる字幕は、映画の台詞を表す文字列であるとして説明を進めたが、動画と緻密に同期して表示されるものであればなんであってもよい。例えばイラストや絵柄、キャラクタ、シンボルマークを描いたものであってもよい。商標を構成するような図形，文字，色彩の組合せや、国の紋章，旗章，記章，国家が採用する監督／証明用の公の記号・印章、政府間国際機関の紋章，旗章，記章，特定商品の原産地表示を含んでいてもよい。
（Ｍ）第１実施形態では、字幕を画面の上側、下側に横書きで表示するものとして、ウィンドゥをグラフィックスプレーンの上側、下側に定義したが、字幕を画面の右側、左側に表示するものとして、ウィンドゥをグラフィックスプレーンの右側、左側に定義してもよい。こうすることにより、日本語字幕を縦書きで表示することができる。
（Ｏ）グラフィクスデコーダ１２が、ＤＳｎ及びＤＳｎ＋１に対する処理をパイプライン式に行うのは、ＤＳｎ及びＤＳｎ＋１が、グラフィクスストリームにおける同じＥｐｏｃｈに帰属している場合であり、前記ＤＳｎ及びＤＳｎ＋１が、互いに異なるＥｐｏｃｈに属している場合、ＤＳｎにおけるグラフィクス表示を開始した後に、ＤＳｎ＋１に対する処理を開始する。
またグラフィクスストリームには、動画との同期を主たる目的としたプレゼンテーション系のものと、対話的な表示を主目的としたインタラクティブ系のものとがあり、前記グラフィクスデコーダは、グラフィクスストリームがプレゼンテーション系である場合に、２つのＤＳに対するパイプライン式を行い、グラフィクスストリームがインタラクティブ系である場合、２つのＤＳに対するパイプライン式を行わない。
（Ｐ）Ｄｉｓｐｌａｙ  Ｓｅｔ内にグラフィクスデータを配列させるにあたって、図２０では、同じＤｉｓｐｌａｙ  Ｓｅｔ内のＰＣＳにより参照されるグラフィクスデータを、参照されないグラフィクスデータの前に配列したが、複数の参照グラフィクスデータ、及び、複数の非参照グラフィクスデータを、それぞれ、ｏｂｊｅｃｔ＿ｉｄにより指示される識別番号順に配列してもよい。また複数の参照グラフィクスデータは、スキャンライン順に配列してもよい。スキャンラインとは、ディスプレイでの表示時において、走査される順番を表す。通常ディスプレイにおける走査は、左上→右下方向に向けてなされるから、表示座標が左上にあるグラフィクスデータを前に、表示座標が右下にあるグラフィクスデータを後に配置するのである。こうすることで、グラフィクスデータ表示の迅速化を図ることができる。
上述した変更実施は可能であるものの、請求項に係る各発明は、従来技術の技術的課題を解決するための手段を反映したものであるから、請求項に係る各発明の技術範囲は、従来技術の技術的課題解決が当業者により認識される技術範囲を超えることはない。故に、本願の請求項に係る各発明は、詳細説明の記載と、実質的な対応関係を有する。
【産業上の利用可能性】  本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき工業的に量産することが可能なので、資質において工業上用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上利用可能性を有する。
【図１】
2005002220.tif 000003
【図２】
2005002220.tif 000004
【図３】
2005002220.tif 000005
【図４】
2005002220.tif 000006
【図５】
2005002220.tif 000007
【図６】
2005002220.tif 000008
【図７】
2005002220.tif 000009
【図８】
2005002220.tif 000010
【図９】
2005002220.tif 000011
【図１０】
2005002220.tif 000012
【図１１】
2005002220.tif 000013
【図１２】
2005002220.tif 000014
【図１３】
2005002220.tif 000015
【図１４】
2005002220.tif 000016
【図１５】
2005002220.tif 000017
【図１６】
2005002220.tif 000018
【図１７】
2005002220.tif 000019
【図１８】
2005002220.tif 000020
【図１９】
2005002220.tif 000021
【図２０】
2005002220.tif 000022
【図２１】
2005002220.tif 000023
【図２２】
2005002220.tif 000024
【図２３】
2005002220.tif 000025
【図２４】
2005002220.tif 000026
【図２５】
2005002220.tif 000027
【図２６】
2005002220.tif 000028
【図２７】
2005002220.tif 000029
【図２８】
2005002220.tif 000030
【図２９】
2005002220.tif 000031
【図３０】
2005002220.tif 000032
【図３１】
2005002220.tif 000033
【図３２】
2005002220.tif 000034
【図３３】
2005002220.tif 000035
【図３４】
2005002220.tif 000036
【図３５】
2005002220.tif 000037
【図３６】
2005002220.tif 000038
【図３７】
2005002220.tif 000039
【図３８】
2005002220.tif 000040
【図３９】
2005002220.tif 000041
【図４０】
2005002220.tif 000042
【図４１】
2005002220.tif 000043
【国際調査報告】
2005002220.tif 000044
2005002220.tif 000045